From 83d6655c65482c899568051ed4eeb973dd45c314 Mon Sep 17 00:00:00 2001 From: sofastack <> Date: Mon, 14 Oct 2024 03:49:16 +0000 Subject: [PATCH] Update from https://github.com/sofastack/sofastack.tech/commit/20dc55a0e39e5850eda05fa91b506ecb3af204af --- activities/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- activities/page/2/index.html | 8 +- activities/page/3/index.html | 8 +- activities/page/4/index.html | 8 +- activities/page/5/index.html | 8 +- activities/page/6/index.html | 8 +- activities/page/7/index.html | 8 +- activities/service-mesh-meetup-8/index.html | 8 +- activities/service-mesh-meetup-9/index.html | 8 +- activities/service-mesh-webinar-1/index.html | 8 +- activities/service-mesh-webinar-2/index.html | 8 +- activities/sofa-6th-anniversary/index.html | 8 +- activities/sofa-anniversary-5/index.html | 8 +- activities/sofa-ark-lab/index.html | 8 +- activities/sofa-boot-lab/index.html | 8 +- activities/sofa-channel-1/index.html | 8 +- activities/sofa-channel-10/index.html | 8 +- activities/sofa-channel-11/index.html | 8 +- activities/sofa-channel-12/index.html | 8 +- activities/sofa-channel-13/index.html | 8 +- activities/sofa-channel-14/index.html | 8 +- activities/sofa-channel-15/index.html | 8 +- activities/sofa-channel-16/index.html | 8 +- activities/sofa-channel-17/index.html | 8 +- activities/sofa-channel-2/index.html | 8 +- activities/sofa-channel-20/index.html | 8 +- activities/sofa-channel-21-1/index.html | 8 +- activities/sofa-channel-22/index.html | 8 +- activities/sofa-channel-23/index.html | 8 +- activities/sofa-channel-24/index.html | 8 +- activities/sofa-channel-25/index.html | 8 +- activities/sofa-channel-26/index.html | 8 +- activities/sofa-channel-27/index.html | 8 +- activities/sofa-channel-28/index.html | 8 +- activities/sofa-channel-29/index.html | 8 +- activities/sofa-channel-3/index.html | 8 +- activities/sofa-channel-30/index.html | 8 +- activities/sofa-channel-32/index.html | 8 +- activities/sofa-channel-33/index.html | 8 +- activities/sofa-channel-34/index.html | 8 +- activities/sofa-channel-35/index.html | 8 +- activities/sofa-channel-4/index.html | 8 +- activities/sofa-channel-5/index.html | 8 +- activities/sofa-channel-6/index.html | 12 +- activities/sofa-channel-7/index.html | 12 +- activities/sofa-channel-8/index.html | 8 +- activities/sofa-channel-9/index.html | 8 +- activities/sofa-meetup-1/index.html | 8 +- activities/sofa-meetup-10/index.html | 8 +- activities/sofa-meetup-12/index.html | 8 +- activities/sofa-meetup-13/index.html | 8 +- activities/sofa-meetup-14/index.html | 8 +- activities/sofa-meetup-15/index.html | 8 +- activities/sofa-meetup-16/index.html | 8 +- activities/sofa-meetup-17/index.html | 8 +- activities/sofa-meetup-2/index.html | 8 +- activities/sofa-meetup-3/index.html | 8 +- activities/sofa-meetup-4/index.html | 8 +- activities/sofa-meetup-5/index.html | 8 +- activities/sofa-meetup-6/index.html | 8 +- activities/sofa-meetup-7/index.html | 12 +- activities/sofa-meetup-8/index.html | 8 +- activities/sofa-registry-lab/index.html | 8 +- activities/sofa-talk-1/index.html | 8 +- activities/sofachannel-31/index.html | 8 +- activities/sofachannel-32/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- algolia.json | 2 +- .../index.html | 8 +- .../index.html | 8 +- blog/20220920/index.html | 8 +- blog/20220929/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/ant-financial-happy-1024/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/ant-intelligent-monitoring/index.html | 8 +- .../index.html | 12 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/antfin-zsearch-vector-search/index.html | 8 +- .../index.html | 8 +- blog/antgroup-kubernetes-high-slo/index.html | 8 +- blog/antgroup-serverless-task/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/build-subset-optimization/index.html | 8 +- .../20221008/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/container-image-basics/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/dragonfly-v-2-1-0-release/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/end-to-end-ai-system-sqlflow/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/five-years-to-ali-p8/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/go-sql-driver-amazing-bug/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/k8s-1.14-release-note/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/kubernetes-the-next-gen-os/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/mecha-carry-mesh-to-the-end/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/microservices-service-mesh/index.html | 8 +- .../index.html | 8 +- .../index.html | 12 +- .../index.html | 8 +- .../index.html | 10 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/mosn-istio-service-mesh/index.html | 8 +- .../index.html | 8 +- .../index.html | 14 +- .../mosn-reverse-channel-explained/index.html | 12 +- .../index.html | 12 +- blog/mosn-transparent-hijacking/index.html | 8 +- blog/my-new-name-is-tongsuo/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/nudus-20230131/index.html | 12 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../nydus-mirror-scan-acceleration/index.html | 8 +- .../index.html | 8 +- .../index.html | 12 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 12 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/page/10/index.html | 8 +- blog/page/11/index.html | 8 +- blog/page/12/index.html | 8 +- blog/page/13/index.html | 8 +- blog/page/14/index.html | 8 +- blog/page/15/index.html | 8 +- blog/page/16/index.html | 8 +- blog/page/17/index.html | 8 +- blog/page/18/index.html | 8 +- blog/page/19/index.html | 8 +- blog/page/2/index.html | 8 +- blog/page/20/index.html | 8 +- blog/page/21/index.html | 8 +- blog/page/22/index.html | 8 +- blog/page/23/index.html | 8 +- blog/page/24/index.html | 8 +- blog/page/25/index.html | 8 +- blog/page/26/index.html | 8 +- blog/page/27/index.html | 8 +- blog/page/28/index.html | 8 +- blog/page/29/index.html | 8 +- blog/page/3/index.html | 8 +- blog/page/30/index.html | 8 +- blog/page/31/index.html | 8 +- blog/page/32/index.html | 8 +- blog/page/33/index.html | 8 +- blog/page/34/index.html | 8 +- blog/page/35/index.html | 8 +- blog/page/36/index.html | 8 +- blog/page/37/index.html | 8 +- blog/page/38/index.html | 8 +- blog/page/39/index.html | 8 +- blog/page/4/index.html | 8 +- blog/page/40/index.html | 8 +- blog/page/41/index.html | 8 +- blog/page/42/index.html | 8 +- blog/page/43/index.html | 8 +- blog/page/44/index.html | 8 +- blog/page/45/index.html | 8 +- blog/page/46/index.html | 8 +- blog/page/47/index.html | 8 +- blog/page/48/index.html | 8 +- blog/page/49/index.html | 8 +- blog/page/5/index.html | 8 +- blog/page/50/index.html | 8 +- blog/page/6/index.html | 8 +- blog/page/7/index.html | 8 +- blog/page/8/index.html | 8 +- blog/page/9/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 10 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 12 +- .../index.html | 8 +- .../seata-php-semi-annual-planning/index.html | 12 +- .../index.html | 8 +- .../index.html | 8 +- blog/seata-server-deep-analysis/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/serverless-knative-giac/index.html | 8 +- blog/serverless-market-challenge/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/service-mesh-giac-2018/index.html | 8 +- blog/service-mesh-giac-2019/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/sidacar-kubecon-na2019/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/sofa-ark-0.6.0/index.html | 8 +- .../index.html | 8 +- blog/sofa-ark-overview/index.html | 8 +- .../index.html | 8 +- blog/sofa-bolt-codec-deep-dive/index.html | 8 +- blog/sofa-bolt-framework-deep-dive/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/sofa-boot-extension-practice/index.html | 8 +- blog/sofa-boot-log-isolation/index.html | 8 +- blog/sofa-boot-modular-development/index.html | 8 +- blog/sofa-boot-overview/index.html | 8 +- .../index.html | 8 +- blog/sofa-channel-1-retrospect/index.html | 8 +- blog/sofa-channel-10-retrospect/index.html | 8 +- blog/sofa-channel-11-retrospect/index.html | 8 +- blog/sofa-channel-12-retrospect/index.html | 8 +- blog/sofa-channel-13-retrospect/index.html | 8 +- blog/sofa-channel-14-retrospect/index.html | 8 +- blog/sofa-channel-15-retrospect/index.html | 8 +- blog/sofa-channel-16-retrospect/index.html | 8 +- blog/sofa-channel-17-retrospect/index.html | 8 +- blog/sofa-channel-18-retrospect/index.html | 8 +- blog/sofa-channel-2-retrospect/index.html | 8 +- blog/sofa-channel-3-retrospect/index.html | 8 +- blog/sofa-channel-4-retrospect/index.html | 8 +- blog/sofa-channel-5-retrospect/index.html | 8 +- blog/sofa-channel-6-retrospect/index.html | 12 +- blog/sofa-channel-7-retrospect/index.html | 8 +- blog/sofa-channel-8-retrospect/index.html | 8 +- blog/sofa-dashboard-open-source/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/sofa-jraft-deep-dive/index.html | 8 +- blog/sofa-jraft-election-mechanism/index.html | 8 +- .../index.html | 8 +- blog/sofa-jraft-pipeline-principle/index.html | 8 +- blog/sofa-jraft-priority-election/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/sofa-jraft-rheakv/index.html | 8 +- .../index.html | 8 +- blog/sofa-jraft-user-china-mobile/index.html | 8 +- .../index.html | 8 +- blog/sofa-meetup-1-jraft/index.html | 8 +- blog/sofa-meetup-1-registry/index.html | 8 +- blog/sofa-meetup-1-seata/index.html | 8 +- blog/sofa-meetup-2-1-retrospect/index.html | 8 +- blog/sofa-meetup-2-2-retrospect/index.html | 8 +- .../index.html | 8 +- .../sofa-meetup-3-seata-retrospect/index.html | 8 +- blog/sofa-mesh-cnutcon-2018/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../sofa-registry-data-consistency/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/sofa-registry-deep-dive/index.html | 8 +- blog/sofa-registry-introduction/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/sofa-registry-session-storage/index.html | 8 +- blog/sofa-rpc-annotation-support/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/sofa-rpc-data-transmission/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/sofa-rpc-graceful-exit/index.html | 8 +- blog/sofa-rpc-link-tracking/index.html | 8 +- .../index.html | 8 +- .../index.html | 12 +- .../index.html | 8 +- .../index.html | 8 +- blog/sofa-rpc-threading-model/index.html | 8 +- .../index.html | 8 +- blog/sofa-special-weekly/index.html | 8 +- blog/sofa-star-is-recruiting/index.html | 8 +- .../index.html | 8 +- blog/sofa-tracer-overview/index.html | 8 +- .../sofa-tracer-response-mechanism/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../sofa-trcaer-disruptor-practice/index.html | 8 +- blog/sofa-weekly-0327/index.html | 8 +- blog/sofa-weekly-0421/index.html | 8 +- blog/sofa-weekly-0430/index.html | 8 +- blog/sofa-weekly-0505/index.html | 8 +- blog/sofa-weekly-0611/index.html | 8 +- blog/sofa-weekly-1006/index.html | 8 +- blog/sofa-weekly-20190719/index.html | 8 +- blog/sofa-weekly-20190726/index.html | 8 +- blog/sofa-weekly-20190802/index.html | 8 +- blog/sofa-weekly-20190809/index.html | 8 +- blog/sofa-weekly-20190816/index.html | 8 +- blog/sofa-weekly-20190823/index.html | 8 +- blog/sofa-weekly-20190830/index.html | 8 +- blog/sofa-weekly-20190906/index.html | 8 +- blog/sofa-weekly-20190913/index.html | 8 +- blog/sofa-weekly-20190920/index.html | 8 +- blog/sofa-weekly-20190927/index.html | 8 +- blog/sofa-weekly-20191004/index.html | 8 +- blog/sofa-weekly-20191011/index.html | 8 +- blog/sofa-weekly-20191018/index.html | 8 +- blog/sofa-weekly-20191025/index.html | 8 +- blog/sofa-weekly-20191101/index.html | 8 +- blog/sofa-weekly-20191108/index.html | 8 +- blog/sofa-weekly-20191115/index.html | 8 +- blog/sofa-weekly-20191122/index.html | 8 +- blog/sofa-weekly-20191129/index.html | 8 +- blog/sofa-weekly-20191206/index.html | 8 +- blog/sofa-weekly-20191213/index.html | 8 +- blog/sofa-weekly-20191220/index.html | 8 +- blog/sofa-weekly-20191227/index.html | 8 +- blog/sofa-weekly-20200103/index.html | 8 +- blog/sofa-weekly-20200110/index.html | 8 +- blog/sofa-weekly-20200117/index.html | 8 +- blog/sofa-weekly-20200207/index.html | 8 +- blog/sofa-weekly-20200214/index.html | 8 +- blog/sofa-weekly-20200221/index.html | 8 +- blog/sofa-weekly-20200228/index.html | 8 +- blog/sofa-weekly-20200306/index.html | 8 +- blog/sofa-weekly-20200313/index.html | 8 +- blog/sofa-weekly-20200320/index.html | 8 +- blog/sofa-weekly-20200403/index.html | 8 +- blog/sofa-weekly-20200410/index.html | 8 +- blog/sofa-weekly-20200417/index.html | 8 +- blog/sofa-weekly-20200424/index.html | 8 +- blog/sofa-weekly-20200508/index.html | 8 +- blog/sofa-weekly-20200515/index.html | 8 +- blog/sofa-weekly-20200522/index.html | 8 +- blog/sofa-weekly-20200528/index.html | 8 +- blog/sofa-weekly-20200529/index.html | 8 +- blog/sofa-weekly-20200605/index.html | 8 +- blog/sofa-weekly-20200612/index.html | 8 +- blog/sofa-weekly-20200619/index.html | 8 +- blog/sofa-weekly-20200703/index.html | 8 +- blog/sofa-weekly-20200710/index.html | 8 +- blog/sofa-weekly-20200717/index.html | 8 +- blog/sofa-weekly-20200724/index.html | 8 +- blog/sofa-weekly-20200731/index.html | 8 +- blog/sofa-weekly-20200807/index.html | 8 +- blog/sofa-weekly-20200814/index.html | 8 +- blog/sofa-weekly-20200821/index.html | 8 +- blog/sofa-weekly-20200828/index.html | 8 +- blog/sofa-weekly-20200911/index.html | 8 +- blog/sofa-weekly-20200918/index.html | 8 +- blog/sofa-weekly-20200925/index.html | 8 +- blog/sofa-weekly-20201002/index.html | 8 +- blog/sofa-weekly-20201009/index.html | 8 +- blog/sofa-weekly-20201016/index.html | 8 +- blog/sofa-weekly-20201023/index.html | 8 +- blog/sofa-weekly-20201030/index.html | 8 +- blog/sofa-weekly-20201106/index.html | 8 +- blog/sofa-weekly-20201113/index.html | 8 +- blog/sofa-weekly-20201120/index.html | 8 +- blog/sofa-weekly-20201127/index.html | 8 +- blog/sofa-weekly-20201204/index.html | 8 +- blog/sofa-weekly-20201211/index.html | 8 +- blog/sofa-weekly-20201218/index.html | 8 +- blog/sofa-weekly-20201225/index.html | 8 +- blog/sofa-weekly-20201231/index.html | 8 +- blog/sofa-weekly-20210108/index.html | 8 +- blog/sofa-weekly-20210115/index.html | 8 +- blog/sofa-weekly-20210122/index.html | 8 +- blog/sofa-weekly-20210129/index.html | 8 +- blog/sofa-weekly-20210205/index.html | 8 +- blog/sofa-weekly-20210212/index.html | 8 +- blog/sofa-weekly-20210219/index.html | 8 +- blog/sofa-weekly-20210305/index.html | 8 +- blog/sofa-weekly-20210312/index.html | 8 +- blog/sofa-weekly-20210319/index.html | 8 +- blog/sofa-weekly-20210326/index.html | 8 +- blog/sofa-weekly-20210402/index.html | 8 +- blog/sofa-weekly-20210409/index.html | 8 +- blog/sofa-weekly-20210416/index.html | 8 +- blog/sofa-weekly-20210422/index.html | 8 +- blog/sofa-weekly-20210423/index.html | 8 +- blog/sofa-weekly-20210507/index.html | 8 +- blog/sofa-weekly-20210514/index.html | 8 +- blog/sofa-weekly-20210521/index.html | 8 +- blog/sofa-weekly-20210604/index.html | 8 +- blog/sofa-weekly-20210618/index.html | 8 +- blog/sofa-weekly-20210625/index.html | 8 +- blog/sofa-weekly-20210702/index.html | 8 +- blog/sofa-weekly-20210716/index.html | 8 +- blog/sofa-weekly-20210723/index.html | 8 +- blog/sofa-weekly-20210730/index.html | 8 +- blog/sofa-weekly-20210806/index.html | 8 +- blog/sofa-weekly-20210813/index.html | 8 +- blog/sofa-weekly-20210820/index.html | 8 +- blog/sofa-weekly-20210903/index.html | 8 +- blog/sofa-weekly-20210910/index.html | 8 +- blog/sofa-weekly-20210917/index.html | 8 +- blog/sofa-weekly-20210924/index.html | 8 +- blog/sofa-weekly-20211001/index.html | 8 +- blog/sofa-weekly-20211008/index.html | 8 +- blog/sofa-weekly-20211015/index.html | 8 +- blog/sofa-weekly-20211029/index.html | 8 +- blog/sofa-weekly-20211105/index.html | 8 +- blog/sofa-weekly-20211112/index.html | 8 +- blog/sofa-weekly-20211119/index.html | 8 +- blog/sofa-weekly-20211126/index.html | 8 +- blog/sofa-weekly-20211203/index.html | 8 +- blog/sofa-weekly-20211210/index.html | 8 +- blog/sofa-weekly-20211217/index.html | 8 +- blog/sofa-weekly-20211224/index.html | 8 +- blog/sofa-weekly-20211231/index.html | 8 +- blog/sofa-weekly-20220107/index.html | 8 +- blog/sofa-weekly-20220113/index.html | 8 +- blog/sofa-weekly-20220114/index.html | 8 +- blog/sofa-weekly-20220121/index.html | 8 +- blog/sofa-weekly-20220129/index.html | 8 +- blog/sofa-weekly-20220204/index.html | 8 +- blog/sofa-weekly-20220211/index.html | 8 +- blog/sofa-weekly-20220218/index.html | 8 +- blog/sofa-weekly-20220228/index.html | 8 +- blog/sofa-weekly-20220304/index.html | 8 +- blog/sofa-weekly-20220311/index.html | 8 +- blog/sofa-weekly-20220318/index.html | 8 +- blog/sofa-weekly-20220329/index.html | 8 +- blog/sofa-weekly-20220401/index.html | 8 +- blog/sofa-weekly-20220408/index.html | 8 +- blog/sofa-weekly-20220506/index.html | 8 +- blog/sofa-weekly-20220513/index.html | 8 +- blog/sofa-weekly-20220520/index.html | 8 +- blog/sofa-weekly-20220527/index.html | 8 +- blog/sofa-weekly-20220610/index.html | 8 +- blog/sofa-weekly-20220617/index.html | 8 +- blog/sofa-weekly-20220624/index.html | 8 +- blog/sofa-weekly-20220708/index.html | 8 +- blog/sofa-weekly-20220715/index.html | 8 +- blog/sofa-weekly-20220722/index.html | 8 +- blog/sofa-weekly-20220729/index.html | 8 +- blog/sofa-weekly-20220805/index.html | 8 +- blog/sofa-weekly-20220812/index.html | 8 +- blog/sofa-weekly-20220819/index.html | 8 +- blog/sofa-weekly-20220826/index.html | 8 +- blog/sofa-weekly-20220909/index.html | 8 +- blog/sofa-weekly-20220916/index.html | 8 +- blog/sofa-weekly-20221007/index.html | 8 +- blog/sofa-weekly-20221104/index.html | 8 +- blog/sofa-weekly-20221111/index.html | 8 +- blog/sofa-weekly-20221122/index.html | 8 +- blog/sofa-weekly-202211223/index.html | 8 +- blog/sofa-weekly-20221209/index.html | 8 +- blog/sofa-weekly-20221216/index.html | 8 +- blog/sofa-weekly-20221230/index.html | 8 +- blog/sofa-weekly-20230127/index.html | 8 +- blog/sofa-weekly-20230203/index.html | 8 +- blog/sofa-weekly-20230210/index.html | 8 +- blog/sofa-weekly-20230217/index.html | 8 +- blog/sofa-weekly-20230303/index.html | 12 +- blog/sofa-weekly-20230310/index.html | 8 +- blog/sofa-weekly-20230324/index.html | 8 +- blog/sofa-weekly-20230331/index.html | 8 +- blog/sofa-weekly-20230407/index.html | 8 +- blog/sofa-weekly-20230414/index.html | 8 +- blog/sofa-weekly-20230428/index.html | 8 +- blog/sofa-weekly-20230623/index.html | 8 +- blog/sofa-weekly-20230818/index.html | 8 +- blog/sofa-weekly-20230825/index.html | 8 +- blog/sofa-weekly-20230901/index.html | 8 +- blog/sofa-weekly-20230915/index.html | 8 +- blog/sofa-weekly-20230929/index.html | 8 +- blog/sofa-weekly-230317/index.html | 8 +- blog/sofa-weekly-230512/index.html | 8 +- blog/sofa-weekly-230519/index.html | 8 +- blog/sofa-weekly-230526/index.html | 8 +- blog/sofa-weekly-230609/index.html | 8 +- blog/sofa-weekly-230616/index.html | 8 +- blog/sofa-weekly/20220923/index.html | 8 +- blog/sofa-weekly/20221028/index.html | 8 +- blog/sofa-weekly20210226/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 10 +- .../index.html | 8 +- .../20221103/index.html | 8 +- .../index.html | 8 +- blog/sofarpc-5.5.x-nacos-hystrix/index.html | 8 +- .../index.html | 8 +- blog/sofastack-2019-oscar/index.html | 8 +- blog/sofastack-anniversary-1/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/sofastack-independent-droup/index.html | 8 +- blog/sofastack-linux-china/index.html | 8 +- blog/sofastack-modular-isolation/index.html | 8 +- blog/sofastack-open-source-doubles/index.html | 8 +- blog/sofastack-oschina-2018/index.html | 8 +- .../index.html | 8 +- blog/sofastack-user-yimi/index.html | 8 +- blog/sofastack20220927/index.html | 8 +- .../index.html | 8 +- blog/sofaweekly-20230106/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- blog/sqlflow-open-source/index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 12 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 12 +- blog/the-secret-of-anolisos/index.html | 12 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../index.html | 8 +- .../we-made-a-distributed-registry/index.html | 8 +- .../index.html | 10 +- .../20220927/index.html | 8 +- categories/1024/index.html | 8 +- categories/cafedeployment/index.html | 8 +- categories/elasticdl/index.html | 8 +- categories/kata-container/index.html | 8 +- categories/kata-containers/index.html | 8 +- categories/kubernetes/index.html | 8 +- categories/mosn/index.html | 8 +- categories/occlum/index.html | 8 +- categories/seata/index.html | 8 +- categories/serverless/index.html | 8 +- categories/service-mesh/index.html | 8 +- categories/service-mesh/page/2/index.html | 8 +- categories/service-mesh/page/3/index.html | 8 +- categories/service-mesh/page/4/index.html | 8 +- categories/sofa-weekly/index.html | 8 +- categories/sofa-weekly/page/10/index.html | 8 +- categories/sofa-weekly/page/11/index.html | 8 +- categories/sofa-weekly/page/12/index.html | 8 +- categories/sofa-weekly/page/13/index.html | 8 +- categories/sofa-weekly/page/14/index.html | 8 +- categories/sofa-weekly/page/15/index.html | 8 +- categories/sofa-weekly/page/16/index.html | 8 +- categories/sofa-weekly/page/17/index.html | 8 +- categories/sofa-weekly/page/18/index.html | 8 +- categories/sofa-weekly/page/19/index.html | 8 +- categories/sofa-weekly/page/2/index.html | 8 +- categories/sofa-weekly/page/20/index.html | 8 +- categories/sofa-weekly/page/3/index.html | 8 +- categories/sofa-weekly/page/4/index.html | 8 +- categories/sofa-weekly/page/5/index.html | 8 +- categories/sofa-weekly/page/6/index.html | 8 +- categories/sofa-weekly/page/7/index.html | 8 +- categories/sofa-weekly/page/8/index.html | 8 +- categories/sofa-weekly/page/9/index.html | 8 +- categories/sofa/index.html | 8 +- categories/sofaacts/index.html | 8 +- categories/sofaark/index.html | 8 +- categories/sofabolt/index.html | 8 +- categories/sofaboot/index.html | 8 +- categories/sofachannel/index.html | 8 +- categories/sofachannel/page/2/index.html | 8 +- categories/sofachannel/page/3/index.html | 8 +- categories/sofachannel/page/4/index.html | 8 +- categories/sofadashboard/index.html | 8 +- categories/sofaenclave/index.html | 8 +- categories/sofagw/index.html | 8 +- categories/sofajraft/index.html | 8 +- categories/sofajraft/page/2/index.html | 8 +- categories/sofalab/index.html | 8 +- categories/sofalookout/index.html | 8 +- categories/sofameetup/index.html | 8 +- categories/sofameetup/page/2/index.html | 8 +- categories/sofamesh/index.html | 8 +- categories/sofaregistry/index.html | 8 +- categories/sofaregistry/page/2/index.html | 8 +- categories/sofarpc/index.html | 8 +- categories/sofarpc/page/2/index.html | 8 +- categories/sofastack/index.html | 8 +- categories/sofastack/page/10/index.html | 8 +- categories/sofastack/page/11/index.html | 8 +- categories/sofastack/page/12/index.html | 8 +- categories/sofastack/page/13/index.html | 8 +- categories/sofastack/page/14/index.html | 8 +- categories/sofastack/page/15/index.html | 8 +- categories/sofastack/page/16/index.html | 8 +- categories/sofastack/page/17/index.html | 8 +- categories/sofastack/page/2/index.html | 8 +- categories/sofastack/page/3/index.html | 8 +- categories/sofastack/page/4/index.html | 8 +- categories/sofastack/page/5/index.html | 8 +- categories/sofastack/page/6/index.html | 8 +- categories/sofastack/page/7/index.html | 8 +- categories/sofastack/page/8/index.html | 8 +- categories/sofastack/page/9/index.html | 8 +- categories/sofatalk/index.html | 8 +- categories/sofatracer/index.html | 8 +- categories/sqlflow/index.html | 8 +- categories/summer-2021/index.html | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../\351\225\234\345\203\217/index.html" | 8 +- en/algolia.json | 2 +- .../sofa-boot/sofa-ark-readme/index.html | 7 +- en/sitemap.xml | 506 ++--- index.xml | 2 +- projects/sofa-boot/index.xml | 2 +- .../index.html | 42 +- .../sofa-ark-migration-guide/index.html | 32 +- projects/sofa-boot/sofa-ark-readme/index.html | 14 +- sitemap.xml | 4 +- tags/1024/index.html | 8 +- tags/api-gateway/index.html | 8 +- tags/cafedeployment/index.html | 8 +- tags/cafedeployment/index.xml | 4 +- tags/cloud-native/index.html | 8 +- tags/cncf/index.html | 8 +- tags/db-mesh/index.html | 8 +- tags/dragonfly/index.html | 8 +- tags/elasticdl/index.html | 8 +- tags/http/3/index.html | 8 +- tags/http/quic/index.html | 8 +- tags/kata-container/index.html | 8 +- tags/kata-containers/index.html | 8 +- tags/knative/index.html | 8 +- tags/kubecon/index.html | 8 +- tags/kubernetes/index.html | 8 +- tags/meetup/index.html | 8 +- tags/mosn/index.html | 8 +- tags/mosn/page/2/index.html | 8 +- tags/nydus/index.html | 8 +- tags/occlum/index.html | 8 +- .../index.html" | 8 +- tags/seata/index.html | 8 +- tags/seata/index.xml | 4 +- tags/seata/page/2/index.html | 8 +- tags/serverless/index.html | 8 +- tags/serverlesstask/index.html | 8 +- tags/service-mesh-meetup/index.html | 8 +- tags/service-mesh-virtual-meetup/index.html | 8 +- tags/service-mesh-webinar/index.html | 8 +- .../index.html" | 8 +- .../page/2/index.html" | 8 +- tags/service-mesh/index.html | 8 +- tags/service-mesh/page/2/index.html | 8 +- tags/service-mesh/page/3/index.html | 8 +- tags/service-mesh/page/4/index.html | 8 +- tags/service-mesh/page/5/index.html | 8 +- .../index.html" | 8 +- tags/sofa-weekly/index.html | 8 +- tags/sofa-weekly/page/10/index.html | 8 +- tags/sofa-weekly/page/11/index.html | 8 +- tags/sofa-weekly/page/12/index.html | 8 +- tags/sofa-weekly/page/13/index.html | 8 +- tags/sofa-weekly/page/14/index.html | 8 +- tags/sofa-weekly/page/15/index.html | 8 +- tags/sofa-weekly/page/16/index.html | 8 +- tags/sofa-weekly/page/17/index.html | 8 +- tags/sofa-weekly/page/18/index.html | 8 +- tags/sofa-weekly/page/19/index.html | 8 +- tags/sofa-weekly/page/2/index.html | 8 +- tags/sofa-weekly/page/3/index.html | 8 +- tags/sofa-weekly/page/4/index.html | 8 +- tags/sofa-weekly/page/5/index.html | 8 +- tags/sofa-weekly/page/6/index.html | 8 +- tags/sofa-weekly/page/7/index.html | 8 +- tags/sofa-weekly/page/8/index.html | 8 +- tags/sofa-weekly/page/9/index.html | 8 +- tags/sofa/index.html | 8 +- tags/sofaacts/index.html | 8 +- tags/sofaark/index.html | 8 +- tags/sofaark/page/2/index.html | 8 +- tags/sofaarklab/index.html | 8 +- tags/sofabolt/index.html | 8 +- tags/sofaboot/index.html | 8 +- tags/sofachannel/index.html | 8 +- tags/sofachannel/page/2/index.html | 8 +- tags/sofachannel/page/3/index.html | 8 +- tags/sofachannel/page/4/index.html | 8 +- tags/sofachannel/page/5/index.html | 8 +- tags/sofadashboard/index.html | 8 +- tags/sofaenclave/index.html | 8 +- .../index.html" | 8 +- tags/sofajraft/index.html | 8 +- tags/sofajraft/page/2/index.html | 8 +- tags/sofalab/index.html | 8 +- tags/sofalab/page/2/index.html | 8 +- tags/sofalab/page/3/index.html | 8 +- tags/sofalab/page/4/index.html | 8 +- tags/sofalab/page/5/index.html | 8 +- tags/sofalookout/index.html | 8 +- tags/sofameetup/index.html | 8 +- tags/sofameetup/page/2/index.html | 8 +- tags/sofamesh/index.html | 8 +- tags/sofaregistry/index.html | 8 +- tags/sofaregistry/page/2/index.html | 8 +- tags/sofarpc/index.html | 8 +- tags/sofarpc/page/2/index.html | 8 +- tags/sofarpc/page/3/index.html | 8 +- .../index.html" | 8 +- tags/sofastack/index.html | 8 +- tags/sofastack/page/10/index.html | 8 +- tags/sofastack/page/11/index.html | 8 +- tags/sofastack/page/12/index.html | 8 +- tags/sofastack/page/13/index.html | 8 +- tags/sofastack/page/14/index.html | 8 +- tags/sofastack/page/15/index.html | 8 +- tags/sofastack/page/16/index.html | 8 +- tags/sofastack/page/2/index.html | 8 +- tags/sofastack/page/3/index.html | 8 +- tags/sofastack/page/4/index.html | 8 +- tags/sofastack/page/5/index.html | 8 +- tags/sofastack/page/6/index.html | 8 +- tags/sofastack/page/7/index.html | 8 +- tags/sofastack/page/8/index.html | 8 +- tags/sofastack/page/9/index.html | 8 +- tags/sofastak/index.html | 8 +- tags/sofatalk/index.html | 8 +- tags/sofatracer/index.html | 8 +- tags/springboot/index.html | 8 +- tags/sqlflow/index.html | 8 +- tags/summer-2021/index.html | 8 +- tags/workshop/index.html | 8 +- tags/zsearch/index.html | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.xml" | 4 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../page/2/index.html" | 8 +- .../index.html" | 8 +- "tags/\345\256\236\350\267\265/index.html" | 8 +- "tags/\345\274\200\346\272\220/index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.html" | 8 +- .../index.xml" | 4 +- .../page/2/index.html" | 8 +- .../index.html" | 8 +- "tags/\351\225\234\345\203\217/index.html" | 8 +- zh/sitemap.xml | 1976 ++++++++--------- 863 files changed, 4756 insertions(+), 4719 deletions(-) diff --git a/activities/index.html b/activities/index.html index 1f6ee84c..b6e53317 100644 --- a/activities/index.html +++ b/activities/index.html @@ -538,7 +538,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -574,7 +574,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -660,7 +660,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -698,7 +698,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/index.html b/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/index.html index 3216b427..4eb0829c 100644 --- a/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/index.html +++ b/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/index.html @@ -389,7 +389,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -425,7 +425,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -511,7 +511,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -549,7 +549,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/index.html b/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/index.html index 3564cb89..fe417f9d 100644 --- a/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/index.html +++ b/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/index.html @@ -422,7 +422,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -458,7 +458,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -544,7 +544,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -582,7 +582,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/page/2/index.html b/activities/page/2/index.html index 88fde8c8..8a920d22 100644 --- a/activities/page/2/index.html +++ b/activities/page/2/index.html @@ -550,7 +550,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -586,7 +586,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -672,7 +672,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -710,7 +710,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/page/3/index.html b/activities/page/3/index.html index bb17afcd..57cebd28 100644 --- a/activities/page/3/index.html +++ b/activities/page/3/index.html @@ -538,7 +538,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -574,7 +574,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -660,7 +660,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -698,7 +698,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/page/4/index.html b/activities/page/4/index.html index f25400a7..e13b42f1 100644 --- a/activities/page/4/index.html +++ b/activities/page/4/index.html @@ -534,7 +534,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -570,7 +570,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -656,7 +656,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -694,7 +694,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/page/5/index.html b/activities/page/5/index.html index 9a4d6996..241439e6 100644 --- a/activities/page/5/index.html +++ b/activities/page/5/index.html @@ -546,7 +546,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -582,7 +582,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -668,7 +668,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -706,7 +706,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/page/6/index.html b/activities/page/6/index.html index 67d1c6e1..916e14e5 100644 --- a/activities/page/6/index.html +++ b/activities/page/6/index.html @@ -560,7 +560,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -596,7 +596,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -682,7 +682,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -720,7 +720,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/page/7/index.html b/activities/page/7/index.html index 21e2803f..2d285a21 100644 --- a/activities/page/7/index.html +++ b/activities/page/7/index.html @@ -403,7 +403,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -439,7 +439,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -525,7 +525,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -563,7 +563,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/service-mesh-meetup-8/index.html b/activities/service-mesh-meetup-8/index.html index 7185eb56..fcc0d1fc 100644 --- a/activities/service-mesh-meetup-8/index.html +++ b/activities/service-mesh-meetup-8/index.html @@ -401,7 +401,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -437,7 +437,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -523,7 +523,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -561,7 +561,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/service-mesh-meetup-9/index.html b/activities/service-mesh-meetup-9/index.html index d088bf57..5edfdf39 100644 --- a/activities/service-mesh-meetup-9/index.html +++ b/activities/service-mesh-meetup-9/index.html @@ -427,7 +427,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -463,7 +463,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -549,7 +549,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -587,7 +587,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/service-mesh-webinar-1/index.html b/activities/service-mesh-webinar-1/index.html index f2682d3a..43c2224b 100644 --- a/activities/service-mesh-webinar-1/index.html +++ b/activities/service-mesh-webinar-1/index.html @@ -349,7 +349,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -385,7 +385,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -471,7 +471,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -509,7 +509,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/service-mesh-webinar-2/index.html b/activities/service-mesh-webinar-2/index.html index 7c01cc22..0e3dc810 100644 --- a/activities/service-mesh-webinar-2/index.html +++ b/activities/service-mesh-webinar-2/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-6th-anniversary/index.html b/activities/sofa-6th-anniversary/index.html index fc205c2c..3e160bd0 100644 --- a/activities/sofa-6th-anniversary/index.html +++ b/activities/sofa-6th-anniversary/index.html @@ -350,7 +350,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -386,7 +386,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -472,7 +472,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -510,7 +510,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-anniversary-5/index.html b/activities/sofa-anniversary-5/index.html index 7667f0d2..1dcbaae7 100644 --- a/activities/sofa-anniversary-5/index.html +++ b/activities/sofa-anniversary-5/index.html @@ -349,7 +349,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -385,7 +385,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -471,7 +471,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -509,7 +509,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-ark-lab/index.html b/activities/sofa-ark-lab/index.html index 1baefe2a..a08cbb48 100644 --- a/activities/sofa-ark-lab/index.html +++ b/activities/sofa-ark-lab/index.html @@ -323,7 +323,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -359,7 +359,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -445,7 +445,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -483,7 +483,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-boot-lab/index.html b/activities/sofa-boot-lab/index.html index bb830246..e9aec496 100644 --- a/activities/sofa-boot-lab/index.html +++ b/activities/sofa-boot-lab/index.html @@ -320,7 +320,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -356,7 +356,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -442,7 +442,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -480,7 +480,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-1/index.html b/activities/sofa-channel-1/index.html index 8bdbb6c8..4209e9ce 100644 --- a/activities/sofa-channel-1/index.html +++ b/activities/sofa-channel-1/index.html @@ -316,7 +316,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -352,7 +352,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -438,7 +438,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -476,7 +476,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-10/index.html b/activities/sofa-channel-10/index.html index 6f0df90e..a6e3430b 100644 --- a/activities/sofa-channel-10/index.html +++ b/activities/sofa-channel-10/index.html @@ -341,7 +341,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -377,7 +377,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -463,7 +463,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -501,7 +501,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-11/index.html b/activities/sofa-channel-11/index.html index b91d012c..df8bc1bf 100644 --- a/activities/sofa-channel-11/index.html +++ b/activities/sofa-channel-11/index.html @@ -350,7 +350,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -386,7 +386,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -472,7 +472,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -510,7 +510,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-12/index.html b/activities/sofa-channel-12/index.html index c2422a35..9b9105dd 100644 --- a/activities/sofa-channel-12/index.html +++ b/activities/sofa-channel-12/index.html @@ -348,7 +348,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -384,7 +384,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -470,7 +470,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -508,7 +508,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-13/index.html b/activities/sofa-channel-13/index.html index 9971d7b9..980cd9b7 100644 --- a/activities/sofa-channel-13/index.html +++ b/activities/sofa-channel-13/index.html @@ -341,7 +341,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -377,7 +377,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -463,7 +463,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -501,7 +501,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-14/index.html b/activities/sofa-channel-14/index.html index 75f89b00..73fdfb20 100644 --- a/activities/sofa-channel-14/index.html +++ b/activities/sofa-channel-14/index.html @@ -352,7 +352,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -388,7 +388,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -474,7 +474,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -512,7 +512,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-15/index.html b/activities/sofa-channel-15/index.html index 68fd00de..479e52b9 100644 --- a/activities/sofa-channel-15/index.html +++ b/activities/sofa-channel-15/index.html @@ -336,7 +336,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -372,7 +372,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -458,7 +458,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -496,7 +496,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-16/index.html b/activities/sofa-channel-16/index.html index a07892a7..424bc190 100644 --- a/activities/sofa-channel-16/index.html +++ b/activities/sofa-channel-16/index.html @@ -343,7 +343,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -379,7 +379,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -465,7 +465,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -503,7 +503,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-17/index.html b/activities/sofa-channel-17/index.html index 73628e69..89813e11 100644 --- a/activities/sofa-channel-17/index.html +++ b/activities/sofa-channel-17/index.html @@ -338,7 +338,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -374,7 +374,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -460,7 +460,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -498,7 +498,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-2/index.html b/activities/sofa-channel-2/index.html index b85fd96a..73434b32 100644 --- a/activities/sofa-channel-2/index.html +++ b/activities/sofa-channel-2/index.html @@ -327,7 +327,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -363,7 +363,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -449,7 +449,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -487,7 +487,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-20/index.html b/activities/sofa-channel-20/index.html index 56575c57..1577c176 100644 --- a/activities/sofa-channel-20/index.html +++ b/activities/sofa-channel-20/index.html @@ -341,7 +341,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -377,7 +377,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -463,7 +463,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -501,7 +501,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-21-1/index.html b/activities/sofa-channel-21-1/index.html index 3112c124..3024e5ba 100644 --- a/activities/sofa-channel-21-1/index.html +++ b/activities/sofa-channel-21-1/index.html @@ -339,7 +339,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -375,7 +375,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -461,7 +461,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -499,7 +499,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-22/index.html b/activities/sofa-channel-22/index.html index 8c35a3b0..c207fda1 100644 --- a/activities/sofa-channel-22/index.html +++ b/activities/sofa-channel-22/index.html @@ -340,7 +340,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -376,7 +376,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -462,7 +462,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -500,7 +500,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-23/index.html b/activities/sofa-channel-23/index.html index 240059d7..3f5446eb 100644 --- a/activities/sofa-channel-23/index.html +++ b/activities/sofa-channel-23/index.html @@ -350,7 +350,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -386,7 +386,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -472,7 +472,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -510,7 +510,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-24/index.html b/activities/sofa-channel-24/index.html index 66b3a58d..8e30fbef 100644 --- a/activities/sofa-channel-24/index.html +++ b/activities/sofa-channel-24/index.html @@ -350,7 +350,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -386,7 +386,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -472,7 +472,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -510,7 +510,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-25/index.html b/activities/sofa-channel-25/index.html index a42f93c8..80478609 100644 --- a/activities/sofa-channel-25/index.html +++ b/activities/sofa-channel-25/index.html @@ -349,7 +349,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -385,7 +385,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -471,7 +471,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -509,7 +509,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-26/index.html b/activities/sofa-channel-26/index.html index d004a7fe..8b4423db 100644 --- a/activities/sofa-channel-26/index.html +++ b/activities/sofa-channel-26/index.html @@ -355,7 +355,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -391,7 +391,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -477,7 +477,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -515,7 +515,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-27/index.html b/activities/sofa-channel-27/index.html index 4cb4a5fa..1fbea2a5 100644 --- a/activities/sofa-channel-27/index.html +++ b/activities/sofa-channel-27/index.html @@ -339,7 +339,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -375,7 +375,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -461,7 +461,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -499,7 +499,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-28/index.html b/activities/sofa-channel-28/index.html index dbd837d0..4be0fa59 100644 --- a/activities/sofa-channel-28/index.html +++ b/activities/sofa-channel-28/index.html @@ -339,7 +339,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -375,7 +375,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -461,7 +461,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -499,7 +499,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-29/index.html b/activities/sofa-channel-29/index.html index e0aa44aa..f39d45ca 100644 --- a/activities/sofa-channel-29/index.html +++ b/activities/sofa-channel-29/index.html @@ -341,7 +341,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -377,7 +377,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -463,7 +463,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -501,7 +501,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-3/index.html b/activities/sofa-channel-3/index.html index 3455310d..97eec428 100644 --- a/activities/sofa-channel-3/index.html +++ b/activities/sofa-channel-3/index.html @@ -327,7 +327,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -363,7 +363,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -449,7 +449,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -487,7 +487,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-30/index.html b/activities/sofa-channel-30/index.html index ed11d569..0ec307e5 100644 --- a/activities/sofa-channel-30/index.html +++ b/activities/sofa-channel-30/index.html @@ -339,7 +339,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -375,7 +375,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -461,7 +461,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -499,7 +499,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-32/index.html b/activities/sofa-channel-32/index.html index 5e323bc3..c90707fa 100644 --- a/activities/sofa-channel-32/index.html +++ b/activities/sofa-channel-32/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-33/index.html b/activities/sofa-channel-33/index.html index b9f43b69..5735023f 100644 --- a/activities/sofa-channel-33/index.html +++ b/activities/sofa-channel-33/index.html @@ -330,7 +330,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -366,7 +366,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -452,7 +452,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -490,7 +490,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-34/index.html b/activities/sofa-channel-34/index.html index cd5dbe9f..5b318c0e 100644 --- a/activities/sofa-channel-34/index.html +++ b/activities/sofa-channel-34/index.html @@ -331,7 +331,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -367,7 +367,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -453,7 +453,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -491,7 +491,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-35/index.html b/activities/sofa-channel-35/index.html index e40e6248..bed846bd 100644 --- a/activities/sofa-channel-35/index.html +++ b/activities/sofa-channel-35/index.html @@ -344,7 +344,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -380,7 +380,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -466,7 +466,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -504,7 +504,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-4/index.html b/activities/sofa-channel-4/index.html index b8510beb..67fb53e7 100644 --- a/activities/sofa-channel-4/index.html +++ b/activities/sofa-channel-4/index.html @@ -348,7 +348,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -384,7 +384,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -470,7 +470,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -508,7 +508,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-5/index.html b/activities/sofa-channel-5/index.html index c15ff7a6..2ca79cdd 100644 --- a/activities/sofa-channel-5/index.html +++ b/activities/sofa-channel-5/index.html @@ -344,7 +344,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -380,7 +380,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -466,7 +466,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -504,7 +504,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-6/index.html b/activities/sofa-channel-6/index.html index a2121475..1fcbab8f 100644 --- a/activities/sofa-channel-6/index.html +++ b/activities/sofa-channel-6/index.html @@ -327,10 +327,10 @@

  • SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs
    • -
  • 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理
    • -
  • 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理
    • +
  • 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理
    • +
  • SOFAChannel#4：分布式事务 Seata TCC 模式深度解析
    • @@ -348,7 +348,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -384,7 +384,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -470,7 +470,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -508,7 +508,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-7/index.html b/activities/sofa-channel-7/index.html index c53d1866..294b7229 100644 --- a/activities/sofa-channel-7/index.html +++ b/activities/sofa-channel-7/index.html @@ -327,10 +327,10 @@

  • SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs
    • -
  • 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理
    • -
  • 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理
    • +
  • 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理
    • + @@ -346,7 +346,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -382,7 +382,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -468,7 +468,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -506,7 +506,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-8/index.html b/activities/sofa-channel-8/index.html index 97a57e30..25a21cff 100644 --- a/activities/sofa-channel-8/index.html +++ b/activities/sofa-channel-8/index.html @@ -341,7 +341,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -377,7 +377,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -463,7 +463,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -501,7 +501,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-channel-9/index.html b/activities/sofa-channel-9/index.html index b6e623cc..98a8b69f 100644 --- a/activities/sofa-channel-9/index.html +++ b/activities/sofa-channel-9/index.html @@ -340,7 +340,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -376,7 +376,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -462,7 +462,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -500,7 +500,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-1/index.html b/activities/sofa-meetup-1/index.html index eac8ac25..d85fd740 100644 --- a/activities/sofa-meetup-1/index.html +++ b/activities/sofa-meetup-1/index.html @@ -376,7 +376,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -412,7 +412,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -498,7 +498,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -536,7 +536,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-10/index.html b/activities/sofa-meetup-10/index.html index b812a745..8110a301 100644 --- a/activities/sofa-meetup-10/index.html +++ b/activities/sofa-meetup-10/index.html @@ -392,7 +392,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -428,7 +428,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -514,7 +514,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -552,7 +552,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-12/index.html b/activities/sofa-meetup-12/index.html index 76acc804..3610cf35 100644 --- a/activities/sofa-meetup-12/index.html +++ b/activities/sofa-meetup-12/index.html @@ -318,7 +318,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -354,7 +354,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -440,7 +440,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -478,7 +478,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-13/index.html b/activities/sofa-meetup-13/index.html index 1a28bdce..dd9a04ea 100644 --- a/activities/sofa-meetup-13/index.html +++ b/activities/sofa-meetup-13/index.html @@ -389,7 +389,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -425,7 +425,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -511,7 +511,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -549,7 +549,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-14/index.html b/activities/sofa-meetup-14/index.html index 30b66e52..07a731c2 100644 --- a/activities/sofa-meetup-14/index.html +++ b/activities/sofa-meetup-14/index.html @@ -428,7 +428,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -464,7 +464,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -550,7 +550,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -588,7 +588,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-15/index.html b/activities/sofa-meetup-15/index.html index 85f885eb..c1facd31 100644 --- a/activities/sofa-meetup-15/index.html +++ b/activities/sofa-meetup-15/index.html @@ -311,7 +311,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -347,7 +347,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -433,7 +433,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -471,7 +471,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-16/index.html b/activities/sofa-meetup-16/index.html index da8238b0..2be130af 100644 --- a/activities/sofa-meetup-16/index.html +++ b/activities/sofa-meetup-16/index.html @@ -321,7 +321,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -357,7 +357,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -443,7 +443,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -481,7 +481,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-17/index.html b/activities/sofa-meetup-17/index.html index af5938e4..539e85fe 100644 --- a/activities/sofa-meetup-17/index.html +++ b/activities/sofa-meetup-17/index.html @@ -314,7 +314,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -350,7 +350,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -436,7 +436,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -474,7 +474,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-2/index.html b/activities/sofa-meetup-2/index.html index 04cd23c7..dfbe76ed 100644 --- a/activities/sofa-meetup-2/index.html +++ b/activities/sofa-meetup-2/index.html @@ -383,7 +383,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -419,7 +419,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -505,7 +505,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -543,7 +543,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-3/index.html b/activities/sofa-meetup-3/index.html index b01a76b9..f652357b 100644 --- a/activities/sofa-meetup-3/index.html +++ b/activities/sofa-meetup-3/index.html @@ -368,7 +368,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -404,7 +404,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -490,7 +490,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -528,7 +528,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-4/index.html b/activities/sofa-meetup-4/index.html index 8d07dc80..7e06eed3 100644 --- a/activities/sofa-meetup-4/index.html +++ b/activities/sofa-meetup-4/index.html @@ -399,7 +399,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -435,7 +435,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -521,7 +521,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -559,7 +559,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-5/index.html b/activities/sofa-meetup-5/index.html index a25d3092..12f4aa40 100644 --- a/activities/sofa-meetup-5/index.html +++ b/activities/sofa-meetup-5/index.html @@ -428,7 +428,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -464,7 +464,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -550,7 +550,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -588,7 +588,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-6/index.html b/activities/sofa-meetup-6/index.html index b448f71b..8089ddb4 100644 --- a/activities/sofa-meetup-6/index.html +++ b/activities/sofa-meetup-6/index.html @@ -393,7 +393,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -429,7 +429,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -515,7 +515,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -553,7 +553,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-7/index.html b/activities/sofa-meetup-7/index.html index 0847c897..e77f2b5d 100644 --- a/activities/sofa-meetup-7/index.html +++ b/activities/sofa-meetup-7/index.html @@ -291,10 +291,10 @@

  • 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了
    • -
  • 用安全计算保护关键业务
    • -
  • 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案
    • +
  • 用安全计算保护关键业务
    • +
  • 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海
  • 带你走进云原生技术：云原生开放运维体系探索和实践
    • @@ -314,7 +314,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -350,7 +350,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -436,7 +436,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -474,7 +474,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-meetup-8/index.html b/activities/sofa-meetup-8/index.html index c7c36b45..609b1f30 100644 --- a/activities/sofa-meetup-8/index.html +++ b/activities/sofa-meetup-8/index.html @@ -426,7 +426,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -462,7 +462,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -548,7 +548,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -586,7 +586,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-registry-lab/index.html b/activities/sofa-registry-lab/index.html index d95eb985..f3a2c6d3 100644 --- a/activities/sofa-registry-lab/index.html +++ b/activities/sofa-registry-lab/index.html @@ -315,7 +315,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -351,7 +351,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -437,7 +437,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -475,7 +475,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofa-talk-1/index.html b/activities/sofa-talk-1/index.html index 85b77548..56db4200 100644 --- a/activities/sofa-talk-1/index.html +++ b/activities/sofa-talk-1/index.html @@ -326,7 +326,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -362,7 +362,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -448,7 +448,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -486,7 +486,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofachannel-31/index.html b/activities/sofachannel-31/index.html index 15402dd1..dd4bafae 100644 --- a/activities/sofachannel-31/index.html +++ b/activities/sofachannel-31/index.html @@ -339,7 +339,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -375,7 +375,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -461,7 +461,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -499,7 +499,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofachannel-32/index.html b/activities/sofachannel-32/index.html index c6132a9d..ae314a40 100644 --- a/activities/sofachannel-32/index.html +++ b/activities/sofachannel-32/index.html @@ -335,7 +335,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -371,7 +371,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -457,7 +457,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -495,7 +495,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofastack-cloud-native-workshop/index.html b/activities/sofastack-cloud-native-workshop/index.html index 930bf215..75c7e86e 100644 --- a/activities/sofastack-cloud-native-workshop/index.html +++ b/activities/sofastack-cloud-native-workshop/index.html @@ -328,7 +328,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -364,7 +364,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -450,7 +450,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -488,7 +488,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/sofastack-four-years-of-open-source/index.html b/activities/sofastack-four-years-of-open-source/index.html index 1d229a90..5fd25fa6 100644 --- a/activities/sofastack-four-years-of-open-source/index.html +++ b/activities/sofastack-four-years-of-open-source/index.html @@ -363,7 +363,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -399,7 +399,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -485,7 +485,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -523,7 +523,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/summer-2021-of-open-source-promotion-plan/index.html b/activities/summer-2021-of-open-source-promotion-plan/index.html index f00c28b8..a7dd22ed 100644 --- a/activities/summer-2021-of-open-source-promotion-plan/index.html +++ b/activities/summer-2021-of-open-source-promotion-plan/index.html @@ -319,7 +319,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -355,7 +355,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -441,7 +441,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -479,7 +479,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/index.html b/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/index.html index cbcf844a..96314440 100644 --- a/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/index.html +++ b/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/index.html @@ -404,7 +404,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -440,7 +440,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -526,7 +526,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -564,7 +564,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/algolia.json b/algolia.json index 2665059a..7220c783 100644 --- a/algolia.json +++ b/algolia.json @@ -1 +1 @@ -[{"author":null,"categories":["SOFAStack"],"content":" \nSOFAStack™ (Scalable Open Financial Architecture Stack) is a collection of cloud native middleware components, which are designed to build distributed systems with high performance and reliability, and have been fully validated by mission-critical financial business scenarios.\nLinks Home Page: https://www.sofastack.tech\nSource Code: https://github.com/sofastack\nProjects SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, log space isolation and asynchronous initialization of bean. SOFARPC is a high-performance, high-extensibility, production-level Java RPC framework. SOFAMesh SOFAMesh is a large-scale implementation solution for Service Mesh which is improved and extended based on Istio. SOFAMosn SOFAMosn(Modular Observable Smart Network) is a powerful proxy acting as Service Mesh\u0026amp;rsquo;s data plane written in Go. SOFATracer SOFATracer is a distributed link tracing system based onOpenTracing specification. SOFALookout SOFALookout is a lightweight and open source middleware service that solves the metrics and monitoring issues of the system. SOFABolt SOFABolt is a network communication framework implemented based on Netty. SOFAArk SOFAArk is a light-weight, java based classloader isolation framework. SOFAJarslink Is a dynamic modules and merged deployments solution based on SOFAArk. SOFAActs ACTS (AntCoreTest) is a white-box testing framework that is based on the accumulation of testing practices for financial-grade distributed architectures. SOFAJraft SOFAJRaft is a production-grade, high-performance Java implementation based on the RAFT consensus algorithm. SOFARegistry SOFARegistry is a production ready, high efficient, highly available service registry. SOFADashboard Is a one-stop console of SOFAStack. More projects in: github/sofastack\nCommunity Github\n WeChat\n Official Account：Antfin_SOFA is a technology exchange platform dedicated to building first-class distributed technologies in financial scenario applications, focusing on the most cutting-edge, reference-oriented technical solutions and implementation routes in the financial technology industry. WeChat Groups：We have ten groups and more than four thousand developers, Add ant-techfin02 as your friend, and reply SOFA will invite to joining into the group. DingTalk\n DingTalk Group:\n 「SOFAStack 1」 No: 23127468 Group is Full\n 「SOFAStack 2」 No: 23195297 Group is Full\n 「SOFAStack 3」 No: 23390449 Group is Full\n 「SOFAStack 4」 No: 23372465 Group is Full\n 「SOFAStack 5」 No: 30315793\n DingTalk Group:「SOFAStack Online service」, If you have used any SOFAStack related components in a production environment, please let us know, and we will invite you to join this group for faster communication and more efficient use of problem support online. Weibo\n SegmentFault\n juejin.im\n ","date":1524135415,"description":"Say hello to SOFAStack!","dir":"blog/hello-sofastack/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"26e249e6b2d0e482eb4404b76dabaec4","permalink":"https://sofastack.github.io/sofastack.tech/en/blog/hello-sofastack/","publishdate":"2018-04-19T11:56:55+01:00","readingtime":2,"relpermalink":"/sofastack.tech/en/blog/hello-sofastack/","summary":"SOFAStack™ (Scalable Open Financial Architecture Stack) is a collection of cloud native middleware components, which are designed to build distributed systems with high performance and reliability, and have been fully validated by mission-critical financial business scenarios.\nLinks Home Page: https://www.sofastack.tech\nSource Code: https://github.com/sofastack\nProjects SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, log space isolation and asynchronous initialization of bean.","tags":["SOFAStack"],"title":"Hello SOFAStack!","type":"blog","url":"/sofastack.tech/en/blog/hello-sofastack/","wordcount":383},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFA 六周年，Hello SOFA World！\n 活动时间：04 月 20 日 13:30\u0026amp;ndash;18:00\n 活动形式：线下 Meetup + 线上直播\n 资料下载：\n Apache Seata(incubating) 新征程\n探索微服务下一站，Koupleless 模块化研发框架与运维调度系统\n开源：除了代码之外还需要做哪些事？\n厚积薄发 - MOSN 社区开启新征程\nSOFABoot - 新一代研发框架\nEnvoy 网关基于 MOE 架构的落地与实践\n介绍 2024 年 4 月 20 日，\nSOFAStack 社区在上海 S 空间与社区小伙伴一起庆祝的第 6 个生日。\n大家一起进入到「SOFA 世界」\n非正式会议+室内露营的活动形式\n让 SOFAer 的技术交流更为轻松自在，现场的开源技术探索氛围十分浓厚。\n现场回顾 点击👉 云相册 进行查看\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 王特（花名：亦夏），Apache Seata(incubating) 社区 PPMC\n 赵真灵（花名：有济），Koupleless 社区负责人\n 马振军（花名：古今），Layotto 社区负责人\n 朱德江（花名：人德），MOSN 开源负责人\n 胡子杰（花名：致节），SOFABoot 社区 PMC\n 杜鑫，中国电子云技术专家、MOSN 社区开发者\n 议程 了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1713596400,"description":"2024 年 4 月 20 日，我们在上海一起庆祝了 SOFA 社区的六岁生日。","dir":"activities/sofa-6th-anniversary/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5711a60fad8f2916fe1fd7bbd9f07242","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-6th-anniversary/","publishdate":"2024-04-20T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-6th-anniversary/","summary":"概要 活动主题：SOFA 六周年，Hello SOFA World！ 活动时间：04 月 20 日 13:30\u0026ndash;18:00 活动形式：线下 Meetup + 线上直播 资料下载： Apache Seata(incubating) 新征程 探索微服务下一站，","tags":["SOFAStack","开源六周年"],"title":"SOFA 六周年，Hello SOFA World","type":"activities","url":"/sofastack.tech/activities/sofa-6th-anniversary/","wordcount":497},{"author":"呈铭","categories":"SOFAStack","content":" 王程铭（呈铭）\n蚂蚁集团技术工程师，Apache Committer\n专注 RPC、Service Mesh 和云原生等领域。\n本文 7368 字，预计阅读 15 分钟\n前言 MOSN（Modular Open Smart Network）是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并经过了双十一大促几十万容器的生产级验证。\nMOSN 为服务提供多协议、模块化、智能化、安全的代理能力，融合了大量云原生通用组件，同时也可以集成 Envoy 作为网络库，具备高性能、易扩展的特点。MOSN 可以和 Istio 集成构建 Service Mesh，也可以作为独立的四、七层负载均衡，API Gateway、云原生 Ingress 等使用。\nMOSN 作为数据面，整体由 NET/IO、Protocol、Stream、Proxy 四个层次组成，其中：\n NET/IO 用于底层的字节流传输\n Protocol 用于协议的 decode/encode\n Stream 用于封装请求和响应，在一个 conn 上做连接复用\n Proxy 做 downstream 和 upstream 之间 stream 的转发\n 那么 MOSN 是如何工作的呢？下图展示的是使用 Sidecar 方式部署运行 MOSN 的示意图，服务和 MOSN 分别部署在同机部署的 Pod 上， 您可以在配置文件中设置 MOSN 的上游和下游协议，协议可以在 HTTP、HTTP2.0 以及 SOFARPC 等中选择。\n以上内容来自官网 https://mosn.io\nRPC 场景下 MOSN 的工作机制 RPC 场景下，MOSN 的工作机制示意图如下：\n我们简单理解一下上面这张图的意义：\n Server 端 MOSN 会将自身 ingress 的协议端口写入到注册中心；\n Client 端 MOSN 会从注册中心订阅地址列表，第一次订阅也会返回全量地址列表，端口号是 Server 端 ingress 绑定的端口号；\n 注册中心会实时推送地址列表变更到 Client 端（全量）；\n Client 端发起 rpc 调用时，请求会被 SDK 打到本地 Client 端 MOSN 的 egress 端口上；\n Client 端 MOSN 将 RPC 请求通过网络转发，将流量通过负载均衡转发到某一台 Server 端 MOSN 的 ingress 端口处理；\n 最终到了 Server 端 ingress listener，会转发给本地 Server 应用；\n 最终会根据原来的 TCP 链路返回。\n 全局视野下的 MOSN 工作流程 现在我们已经了解了 MOSN 的工作机制，那么 MOSN 作为 MESH 的数据面，是怎么进行流量拦截并且将响应原路返回的呢？\n为了方便大家理解，我将以上时序图内容进行拆分，我们一一攻破。\n3.1 建立连接 MOSN 在启动期间，会暴露本地 egress 端口接收 Client 的请求。MOSN 会开启 2 个协程，分别死循环去对 TCP 进行读取和写处理。MOSN 会通过读协程获取到请求字节流，进入 MOSN 的协议层处理。\n// 代码路径 mosn.io/mosn/pkg/network/connection.go func (c *connection) Start(lctx context.Context) { // udp downstream connection do not use read/write loop if c.network == \u0026amp;quot;udp\u0026amp;quot; \u0026amp;amp;\u0026amp;amp; c.rawConnection.RemoteAddr() == nil { return } c.startOnce.Do(func() { // UseNetpollMode = false if UseNetpollMode { c.attachEventLoop(lctx) } else { // 启动读/写循环 c.startRWLoop(lctx) } }) } func (c *connection) startRWLoop(lctx context.Context) { // 标记读循环已经启动 c.internalLoopStarted = true utils.GoWithRecover(func() { // 开始读操作 c.startReadLoop() }, func(r interface{}) { c.Close(api.NoFlush, api.LocalClose) }) // 省略。。。 } 3.2 Protocol 处理 Protocol 作为多协议引擎层，对数据包进行检测，并使用对应协议做 decode/encode 处理。MOSN 会循环解码，一旦收到完整的报文就会创建与其关联的 xstream，用于保持 tcp 连接用于后续响应。\n// 代码路径 mosn.io/mosn/pkg/stream/xprotocol/conn.go func (sc *streamConn) Dispatch(buf types.IoBuffer) { // decode frames for { // 协议 decode，比如 dubbo、bolt 协议等 frame, err := sc.protocol.Decode(streamCtx, buf) if frame != nil { // 创建和请求 frame 关联的 xstream，用于保持 tcp 连接用于后续响应 sc.handleFrame(streamCtx, xframe) } } } func (sc *streamConn) handleFrame(ctx context.Context, frame api.XFrame) { switch frame.GetStreamType() { case api.Request: // 创建和请求 frame 关联的 xstream，用于保持 tcp 连接用于后续响应，之后进入 proxy 层 sc.handleRequest(ctx, frame, false) } } func (sc *streamConn) handleRequest(ctx context.Context, frame api.XFrame, oneway bool) { // 创建和请求 frame 关联的 xstream serverStream := sc.newServerStream(ctx, frame) // 进入 proxy 层并创建 downstream serverStream.receiver = sc.serverCallbacks.NewStreamDetect(serverStream.ctx, sender, span) serverStream.receiver.OnReceive(serverStream.ctx, frame.GetHeader(), frame.GetData(), nil) } 3.3 Proxy …","date":1711436400,"description":"从一次 RPC 请求，探索 MOSN 的工作流程","dir":"blog/explore-the-workflow-of-mosn-from-an-rpc-request/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9993f1cea8de40427d6ef6d8345f9d0c","permalink":"https://sofastack.github.io/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","publishdate":"2024-03-26T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","summary":"王程铭（呈铭） 蚂蚁集团技术工程师，Apache Committer 专注 RPC、Service Mesh 和云原生等领域。 本文 7368 字，预计阅读 15 分钟 前言 MOSN（Modul","tags":["SOFAStack"],"title":"从一次 RPC 请求，探索 MOSN 的工作流程","type":"blog","url":"/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","wordcount":2760},{"author":null,"categories":"SOFAStack","content":" 梁栎鹏（立蓬）\n蚂蚁集团技术工程师,云原生领域工程师\n就职于蚂蚁集团中间件团队，参与维护与建设蚂蚁 SOFAArk 和 Koupleless 开源项目，参与内部 SOFAServerless 产品的研发和实践。\n本文 4603 字，预计阅读 10 分钟\nbackground-你的企业应用协作效率低吗？ 明明只改一行，但代码编译加部署要十分钟？\n多人开发一套代码库，调试却频频遇到资源抢占和相互覆盖，需求上线也因此相互等待？\n当项目代码逐渐膨胀，业务逐渐发展，代码耦合、发布耦合以及资源耦合的问题日益加重，开发效率一降再降。\n如何解决？来试试把单个 Spring Boot 应用拆分为多个 Spring Boot 应用吧！拆出后，多个 Spring Boot 应用并行开发，互不干扰。在 Koupleless 模式下，业务可以将 Spring Boot 应用拆分成一个基座和多个 Koupleless 模块（Koupleless 模块也是 Spring Boot 应用）。\n🙌拉到「Koupleless 拆分插件解决方案」部分，可直接查看单体应用拆分的插件演示视频！\n关键挑战 从单个 Spring Boot 应用拆出多个 Spring Boot 应用有三大关键挑战：\n一是拆子应用前，复杂单体应用中代码耦合高、依赖关系复杂、项目结构复杂，难以分析各文件间的耦合性，更难从中拆出子应用，因此需要解决拆分前复杂单体应用中的文件依赖分析问题。\n二是拆子应用时，拆出操作繁琐、耗时长、用户需要一边分析依赖关系、一边拆出，对用户要求极高，因此需要降低拆分时用户交互成本。\n三是拆子应用后，单体应用演进为多应用共存，其编码模式会发生改变。Bean 调用方式由单应用调用演进为跨应用调用，特殊的多应用编码模式也需根据框架文档调整，比如在 Koupleless 中，为了减少模块的数据源连接，模块会按照某种方式使用基座的数据源，其学习成本与调整成本极高，因此需要解决拆分后多应用编码模式演进问题。\nKoupleless 拆分插件解决方案 针对以上三大关键挑战，Koupleless IntelliJ IDEA 插件将解决方案分为 3 个部分：分析、交互和自动化拆出，提供依赖分析、友好交互和自动化拆出能力，如下图：\n在分析中，分析项目中的依赖关系，包括类依赖和 Bean 依赖分析，解决拆分前复杂单体应用中的文件依赖分析问题；\n在交互中，可视化类文件之间的依赖关系，帮助用户梳理关系。同时，可视化模块目录结构，让用户以拖拽的方式决定要拆分的模块文件，降低拆分时的用户交互成本；\n在自动化拆出中，插件将构建模块，并根据特殊的多应用编码修改代码，解决拆分后多应用编码模式演进问题。\n🙌 Koupleless 半自动拆分演示视频，带你更直观了解插件如何在分析、交互、自动化拆出中提供帮助。\n一个示例，秒懂 Koupleless 解决方案优势 假设某业务需要将与 system 相关的代码都拆出到模块，让通用能力保留在基座。这里我们以 system 的入口服务 QuartzJobController 为例。\n步骤一：分析项目文件依赖关系 首先，我们会分析 QuartzJobController 依赖了哪些类和 Bean。\n 方式一：使用 Idea 专业版，对 Controller 做 Bean 分析和类分析，得到以下 Bean 依赖图和类依赖关系图 优势：借助 IDEA 专业版，分析全面\n劣势：需要对每个类文件都做一次分析，Bean 依赖图可读性不强。\n 方式二：凭借脑力分析 当 A 类依赖了B、C、D、\u0026amp;hellip;、N类，在拆出时需要分析每一个类有没有被其它类依赖，能不能够拆出到模块应用。\n优势：直观\n劣势：当 A 的依赖类众多，需要层层脑力递归。\n 方式三：使用 Koupleless 辅助工具，轻松分析！ 选择你想要分析的任意类文件，点击“分析依赖”，插件帮你分析～ 不仅帮你分析类文件依赖的类和 Bean，还提示你哪些类可以拆出，哪些类不能拆出。\n以 QuartzJobController 为例，当选定的模块中有 QuartzJobController, QuartzJobService 和 QuartzJobServiceImpl 时，QuartzJobController 依赖的类和 Bean 关系如下图所示：\nQuartzJobController 的依赖类/Bean 分为四类：已在模块、可移入模块、建议分析被依赖关系和不建议移入模块：\n 如果在模块中，则被标记为绿色“已在模块”，如：QuartzJobService 和 QuartzJobServiceImpl；\n 如果只被模块类依赖，那么被标记为蓝色“可移入模块”，如 JobQueryCriteria；\n 如果只被一个非模块类依赖，那么被标记为黄色“建议分析被依赖关系”，如 QuartLog；\n 如果被大量非模块类依赖，那么被标记为红色“不建议移入模块”，如 BadRequestException。\n 当使用插件对 QuartzJobController 和 JobQueryCriteria 进行分析时，依赖树和被依赖树如下，与上述分析对应：\n优势：直观、操作便捷、提示友好\n劣势：插件只支持分析常见的 Bean 定义和类引用\n步骤二：拆出到模块\u0026amp;amp;修改单应用编码为多应用编码模式\n选择相关的类文件拆出到模块。\n 方式一：复制粘贴每个文件、脑力分析所有模块基座之间的 Bean 调用、根据多应用编码模式修改代码。 在拆出时不可避免会面临这些问题：刚拆到哪儿了？这文件在没在模块里？我要不要重构这些包名？Bean 调用跨应用吗？多应用编码的文档在哪？\n优势：可以处理插件无法处理的多应用编码模式\n劣势：用户不仅需要分析跨应用 Bean 依赖关系，还需要学习多应用编码方式，人工成本较高。\n 方式二：使用 Koupleless 辅助工具，轻松拆出！ 根据你想要的模块目录结构，拖拽需要拆出的文件至面板。点击“拆出”，插件帮你分析，帮你根据 Koupleless 多应用编码模式修改～\n优势：直观、交互方便、插件自动修改跨应用 Bean 调用方式和部分特殊的多应用编码模式\n劣势：插件只能根据部分多应用编码模式修改代码，因此用户需要了解插件能力的范围\n技术方案 在上文中我们已经知道，插件将整体流程分为 3 个阶段：分析阶段、交互阶段和自动化拆出阶段，整体流程如下图所示：\n 在分析阶段中，分析项目中的依赖关系，包括类依赖、Bean 依赖和特殊的多应用编码分析，如：MyBatis 配置依赖；\n 在交互阶段，可视化类文件之间的依赖关系和模块目录结构；\n 在自动化拆出阶段，插件首先将构建模块并整合配置，然后根据用户需要重构包名，接着修改模块基座 Bean 调用方式，并根据特殊的多应用编码修改代码，如：自动复用基座数据源。\n 接下来，我们将分别简单介绍分析阶段、交互阶段和自动化拆出阶段中用到的主要技术。\n分析阶段 插件分别使用 JavaParser 和 commons-configuration2 扫描项目中的 Java 文件和配置文件。\n类依赖分析 为了准确地分析出项目的类依赖关系，插件需要完整分 …","date":1710831600,"description":"单体应用协作开发太难？Koupleless 带来拆分插件，帮你抽丝剥茧提高协作开发效率！","dir":"blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"31cd46eb078e59933c6f2c5cf7b32bc8","permalink":"https://sofastack.github.io/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","publishdate":"2024-03-19T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","summary":"梁栎鹏（立蓬） 蚂蚁集团技术工程师,云原生领域工程师 就职于蚂蚁集团中间件团队，参与维护与建设蚂蚁 SOFAArk 和 Koupleless 开源项目，参与内部 SOFAServerless 产品的研发和实践。 本","tags":["SOFAStack"],"title":"单体应用协作开发太难？Koupleless 带来拆分插件，帮你抽丝剥茧提高协作开发效率！","type":"blog","url":"/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","wordcount":3944},{"author":null,"categories":"SOFAStack","content":" 文｜祁晓波\n南京爱福路汽车科技基础设施负责人\n主要研究微服务、可观测、稳定性、研发效能、Java 中间件等领域。\n本文 4812 字 阅读 12 分钟\nKoupleless *（原 SOFAServerless）* 自 2023 年开源以来已经落地了若干企业，这些企业也见证了从 SOFAServerless 到 Koupleless 的品牌\u0026amp;amp;技术能力迭代升级。随着 Koupleless 1.0 的重磅发布，一些企业已经在内部取得了不错的效果，例如南京爱福路汽车科技有限公司。\n南京爱福路汽车科技有限公司和大多数科技企业一样，在企业生产开发过程遇到了微服务的一些问题，例如资源成本过高、启动慢等问题。在看到 Koupleless 项目正不断开源出实实在在的能力和案例，在解决很实际的微服务痛点问题，决定采用 Koupleless 进行尝试，并随着 Koupleless 一路走来，已经将 6 个应用合并成 1 个应用大幅降低资源成本，取得了不错的效果。\n1｜背景 南京爱福路汽车科技有限公司 *（以下简称爱福路）* 作为行业 top 的汽车后市场解决方案提供商，为维修门店提供智慧管理系统、为行业提供维修应用大数据，致力于成为汽车后市场数智化构建者。\n随着其服务的企业增多，爱福路也越来越多地接触到了各类体量的企业。\n这就对爱福路的服务提供形式提出了较多不同的诉求： 除了单纯的公有云 SAAS 之外，还包括私有化部署等解决方案的诉求。\n2｜问题提出 我们知道，随着微服务和云原生技术的普及，应用数量急剧膨胀。\n如此多的应用也带来了比较大的成本问题。\n爱福路在为海量公域客户提供服务的时候，更关注稳定、弹性。\n但是在为某个客户提供独立部署方案时，爱福路发现如此多的服务在部署到 K8s 时所带来的服务器成本非常高 *（通常来说，独立部署服务面向的客户群体比之公域客户少了 1-2 个数量级）*，而单个客户也很难有足够的预算负担整个部署方案。这就大大阻塞了爱福路后续持续拓展私有化部署客户的进度。\n举个例子：一个应用在进行 K8s 交付时，最少会提供两个副本；而大量这样的 Java 应用存在对于整体的集群利用率不高，继而造成较高的成本。\n因此爱福路面临着如下的课题： 当进行私有化交付时，如何能够更便捷地、低成本地交付我们现有的产物？\n其中，低成本至少应该包含如下几个角度：\n 既存代码的低成本改造； 新的交付方式低成本的维护； 运行产物低成本的 IT 成本。 3｜问题探索和推导 爱福路基于当前的微服务架构和云原生方式进行了思考和探索： 是否到了爱福路微服务架构进一步升级的时候了？\n在当前整体降本增效的大环境趋势中，在保持服务稳定的前提下对于服务器有更加极致的使用。\n从业务视角来看，服务单店的整体服务器成本越低，爱福路的竞争力就越强。\n那么，有没有可能在保持 Java 的生态环境下，低成本的同时能够保证爱福路继续享受云原生的红利？爱福路做了如下推导：\n通过上述的推导，爱福路判断也许「模块化+Serverless」将是一种解法。\n因此一款来自蚂蚁的开源框架成为他们重点的关注，那就是 Koupleless。（阅读原文可跳转官网地址：https://koupleless.io/user-cases/ant-group/）\n当然一个重要原因是蚂蚁开源一直做得不错，社区也比较活跃。除了社区群和 GitHub 之外，PMC 有济也积极地建立了独享的 VIP 群进行专门对接。\n4｜Koupleless（原 SOFAServerless） Koupleless 技术体系是在业务发展、研发运维的复杂性和成本不断增加的情况下，蚂蚁集团为帮助应用又快又稳地迭代而决定研发，从细化研发运维粒度和屏蔽基础设施的角度出发，演进出的一套低成本接入的「模块化+Serverless」解决方案。\n核心方式是通过类隔离和热部署技术，将应用从代码结构和开发者阵型拆分为两个层次：业务模块和基座，基座为业务模块提供计算环境并屏蔽基础设施，模块开发者不感知机器、容量、中间件等基础设施，专注于业务研发帮助业务快速向前发展。\n合并部署降成本 在企业中， “80%” 的长尾应用仅服务 “20%” 的流量，蚂蚁集团也不例外。\n在蚂蚁集团存在大量长尾应用，每个长尾应用至少需要 预发布、灰度、生产 3 个环境，每个环境最少需要部署 3 个机房，每个机房又必须保持 2 台机器高可用，因此大量长尾应用 CPU 使用率不足 10%。\n通过使用 Koupleless，蚂蚁集团对长尾应用进行了服务器裁撤，借助类委托隔离、资源监控、日志监控等技术，在保证稳定性的前提下，实现了多应用的合并部署，极大降低了业务的运维成本和资源成本。\n此外，采用这种模式，小应用可以不走应用申请上线流程，也不需要申请机器，可以直接部署到业务通用基座之上，从而帮助小流量业务实现了快速创新。\n2023 年底 SOFAServerless 品牌全新升级为 Koupleless（GitHub页面：https://github.com/koupleless/koupleless）。\n企业里不同业务有不同的发展阶段，因此应用也拥有自己的生命周期。\n  * 初创期：一个初创的应用一般会先采用单体架构。 * 增长期：随着业务增长，应用开发者也随之增加。此时您可能不确定业务的未来前景，也不希望过早把业务拆分成多个应用以避免不必要的维护、治理和资源成本，那么您可以用 Koupleless 低成本地将应用拆分为一个基座和多个功能模块，不同功能模块之间可以并行研发运维独立迭代，从而提高应用在此阶段的研发协作和需求交付效率。 * 成熟期：随着业务进一步增长，您可以使用 Koupleless 低成本地将部分或全部功能模块拆分成独立应用去研发运维。 * 长尾期：部分业务在经历增长期或者成熟期后，也可能慢慢步入到低活状态或者长尾状态，此时您可以用 Koupleless 低成本地将这些应用一键改回模块，合并部署到一起实现降本增效。\n 应用生命周期演进\n可以看到 Koupleless 主要通过将应用模块化来降低整个服务的运行成本，更值得称道的是支持模块和应用的来回切换，可以更低成本地接入，支持平滑演进。\n5｜架构适配尝试 Spring Boot 1「可行性确认」 爱福路的存量应用中，九成使用的是 Spring Boot 1，RPC 主要依赖 Dubbo 2.6。这点和社区是有一定出入的，社区仅仅支持 SpringBoot 2。\n为此爱福路需要尝试对于 Spring Boot 1 的支持，也因此提出了相应的 issue👇\nhttps://github.com/sofastack/sofa-ark/issues/268\n通过和社区沟通协调确认，爱福路发现只是社区没能够完全覆盖到这块，企业自身可以通过部分扩展进行支持。\n当时社区同学认为这个是比较重要的变更，可以进一步覆盖更多的社区用户，为此还特地调整了中央仓库的发版频次：加速 review、加速发 snapshot。\n正是这些细节让爱福路更加信任 Koupleless 团队👍，也坚定了此次方案能够实际落地的信心。\n应用合并 当 Spring Boot 1 得到支持之后，爱福路可以快速地将原来的 …","date":1709017200,"description":"高效降本｜深度案例解读 Koupleless 在南京爱福路的落地实践","dir":"blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0c6483ccd63328d158a35bc8b5b81940","permalink":"https://sofastack.github.io/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","publishdate":"2024-02-27T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","summary":"文｜祁晓波 南京爱福路汽车科技基础设施负责人 主要研究微服务、可观测、稳定性、研发效能、Java 中间件等领域。 本文 4812 字 阅读 12 分钟 Koupleless *（原 SOFA","tags":["SOFAStack"],"title":"高效降本｜深度案例解读 Koupleless 在南京爱福路的落地实践","type":"blog","url":"/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","wordcount":3555},{"author":null,"categories":"SOFAStack","content":" 如果你是企业经营者，在为企业降本增效而发愁； 如果你是企业的开发、运维或架构同学，在日常工作中被开发效率、交付问题等困扰…… 欢迎来了解 Koupleless *（原 SOFAServerless）*！\n现在，Koupleless 重磅发布了1.0 版本！（👈点击查看 release note）\n那么，Koupleless 是什么？又将如何为你解决以上问题？除了以上这几种情境，Koupleless 还有哪些能力呢？欢迎你来社区探索发现。\nKoupleless 是什么？ Koupleless 由 SOFAServerless 品牌升级而来，是一款模块化研发框架与运维调度平台。它从应用架构角度出发，帮助应用解决从需求、到研发、到交付再到运维的全生命周期痛点问题。其最核心的架构图如下👇。如果想了解更详细的原理介绍也可以查看官网页面：https://koupleless.gitee.io/docs/introduction/architecture/arch-principle/。\n它能帮助解决的问题包括：\n 应用拆分过度，机器成本和长期维护成本高； 应用拆分不够，多人协作互相阻塞； 应用构建、启动与部署耗时久，应用迭代效率不高； SDK 版本碎片化严重，升级成本高周期长； 平台、中台搭建成本高，业务资产沉淀与架构约束困难； 微服务链路过长，调用性能不高； 微服务拆分、演进成本高； 如果你也被以上问题所困扰，那么欢迎来了解 Koupleless 给出的解决方案。 本模式在蚂蚁集团内部历经 4-5 年时间孵化而成，当前已经帮助 70W 核业务量完成 10 倍级降本增效，可以帮助应用做到秒级启动，只占 20M 内存。\n性能对比示例如下图👇。\n根据我们的模块化应用架构模型，可以看到我们是将传统应用从纵向和横向切分演变而来的。\n所以我们将 SOFAServerless 进行品牌升级成为 Koupleless，取自 Couple + less，寓意通过对应用进行拆分解耦，实现更好的职责分工，帮助业务降本增效。\n我们为什么开源？ 关注应用架构领域的同学，应该知道微服务很好地解决了组织分布式协作难题，但同时也带来了一些问题，并且这些问题正日益获得更多关注。 有人说，2023 年是微服务的转折年[1]，其中一些科技巨头*（如 Amazon 和 Google ）*已经开始尝试去解决和完善微服务带来的问题，例如 service weaver[2]，amazon prime video[3]的架构改造，甚至直接回归单体。\n而蚂蚁内部在 4-5 年前就开始着手解决微服务问题，并为此打造了 Koupleless 应用研发模式。 根据蚂蚁这些年的实践经验，我们相信模块化架构是一种有潜力的架构，真正能够较好地解决微服务问题；我们也希望通过模块化架构给行业内部提供一种新的解决方案，帮助更多企业降本增效。\n开源提供了哪些能力？ 自 2023 年下半年开源以来，经过这半年时间和社区的共同努力，我们已经开放了内部完整的能力，包括研发工具、框架、运维调度平台等；也沉淀了一些常用组件最佳实践和 samples 用例（具体查看 release note：https://github.com/koupleless/koupleless/releases/tag/v1.0.0）。 具备了线上接入使用的能力，一些企业也已经可以按照官网和文档自主接入使用了。\n 研发工具 Arkctl一键构建、部署和发布模块，方便用于本地开发测试验证。 Arklet、SOFAArk 和 Runtime 组件为多种研发框架如 Spring Boot、SOFABoot、Dubbo 提供多模块运行容器环境，适配 30+ 组件，沉淀 25+ samples 用例。 控制面组件 ModuleControllerModuleDeployment，提供模块发布与运维能力； ModuleScheduler，提供模块基础调度能力； ModuleScaler，提供模块扩缩容能力。 有了这些组件之后，从开发验证 -\u0026amp;gt; 交付上线 -\u0026amp;gt; 日常运维全流程的基本能力已经具备，1.0 版本实现生产可用级别。\n挑战与亮点 这套模式最大的挑战来自于将多个应用或代码片段合并在一起，在隔离与共享上如何找到最佳的平衡点，使得在存量应用低成本接入的同时，能享受到隔离的带来稳定可靠的好处，也能享受到共享的高性能、低资源消耗的收益。\n隔离可以确保运行时的稳定可靠，但带来了性能的下降、资源利用率的损失；共享提升了性能和资源利用率，但也带来了运行时的一些问题，例如 static 变量可能带来互相影响的问题。我们采用了模块化技术来解决这类问题。在 Java 领域模块化技术并不是我们首创的，20 年前就有了 OSGl 技术，那为什么我们的模块化技术能在蚂蚁内部规模化落地呢？我们是做了哪些工作来解决存量应用低成本接入和共享后的一些问题的呢？\n要解决这类问题，我们并没有太多可参考的行业案例，相当于是在无人区里摸索，除了解决隔离与共享的核心问题外，还要解决配套设施的建设、用户心智的培养等，这些都需要一个笃定的心力和持续的过程，这些问题就是这套模式的挑战所在。 好在最终，我们拨云见日探索了出来。我们在隔离和共享之间找到了一个最佳的平衡点，并且能让存量业务低成本的接入，这也是我们最自豪的地方。我们在蚂蚁集团用事实证明了模块化技术并不是停留在设计稿里的技术，或者小部分人才能使用的技术，它的问题和挑战并不可怕，是有固定模式的，可以通过工具和流程逐步治理、收敛的，现在将此模式进行开源分享，是希望可以帮助其他企业少走弯路，和社区一起把这套模式心智在行业里树立起来。\nKoupleless 已接入 15+ 企业 当前在统计内的，有 15+ 企业在使用 Koupleless 接入线上或者用于交付，还有 17+ 企业正在试用或者接入中，还有一些因为信息缺失未统计到的。详细企业接入列表可以查看官网信息[4]。 很高兴 Koupleless 能帮助到他们，也十分欢迎这些企业探索的更多使用场景，也欢迎更多企业开发者一起参与社区建设，推广这套技术。\nKoupleless 未来的规划 我们希望能让模块化架构成为应用架构领域里的新模式，并能在行业里推广开来。这不仅是我们作为技术人的技术追求，也是我们做开源的持续动力来源。 当前我们虽然发布了 1.0 版本，但开源工作才只是刚刚开始，还有更多规划。比如，我们希望未来能把模块化技术做得更加完善，将我们想要做到的效果完整地提供出来：\nSpeed as you need, Pay as you need， Deploy as you need， Evolve as you need 。 需要的能力包括支持各种框架、运行时组件、中间件服务，还有非常多相关的配套设施；也希望这套模式能在更多语言里发挥出效果，例如 Go 语言，以此和更多的小伙伴们一起探索出微服务领域的下一站。\n这里感谢所有参与贡献 Koupleless 1.0 的 51 位开发者： @QilingZhang @lvjing2 @glmapper @yuanyuancin @lylingzhen @yuanyuan2021 …","date":1707202800,"description":"成倍降本增效，提升企业竞争力！SOFAServerless 品牌升级为 Koupleless，重磅发布 1.0 版本","dir":"blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bf0d878bbdb545204ab25a89a7c592ac","permalink":"https://sofastack.github.io/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","publishdate":"2024-02-06T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","summary":"如果你是企业经营者，在为企业降本增效而发愁； 如果你是企业的开发、运维或架构同学，在日常工作中被开发效率、交付问题等困扰…… 欢迎来了解 Koupleless *（原","tags":["SOFAStack"],"title":"成倍降本增效，提升企业竞争力！SOFAServerless 品牌升级为 Koupleless，重磅发布 1.0 版本","type":"blog","url":"/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","wordcount":2620},{"author":null,"categories":"SOFAStack","content":" 今天 SOFAStack 邀请到了开源之夏 2023 Layotto 社区的中选学生陈亦昺同学！在本项目中，他负责可插拔式组件的开发。希望他分享的这段经历，能让更多人了解到 Layotto 开源社区，感受开源的魅力～\n项目链接：https://summer-ospp.ac.cn/org/prodetail/23f080194?list=org\u0026amp;amp;navpage=org\n项目名称 Layotto support pluggable components\n项目导师 王文学\n项目背景描述 Layotto 是一款基于云原生的应用运行时，旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，比如状态管理、配置管理、事件发布订阅等能力，以简化应用的开发。同时，它以 MOSN 项目为底座，在提供分布式能力以外，还提供了 Service Mesh 的流量管控能力。\nLayotto 对用户程序暴露 API，用户程序可以通过 API 调度对应的运行时服务。例如 Layotto 支持 config 服务，其内部会使用含有各种 component (如 Nacos，Apollo，Etcd 等) 的 SDK 来提供 config API 能力。\n当前 Layotto 的 component 都是实现在 Layotto 的工程里面的。这也就使得用户在想要使用新的 component 时，必须使用 Golang 语言开发，同时必须在 Layotto 工程中实现，再进行统一编译。这种体验对于多语言用户来说非常不友好。\n因此 Layotto 需要提供 pluggable components 的能力，允许用户通过任何语言实现自己的 component，而 Layotto 则通过 gRPC 协议和外部的 component 进行通信。\n项目实现思路 方案 基于 UDS（Unix Domain Socket）实现本地跨语言组件服务发现，降低通信开销。\n 基于 proto 实现组件跨语言实现能力。\n 数据流架构 组件发现 如上图所示，用户自定义组件启动 socket 服务，并将 socket 文件放到指定目录中。Layotto 启动时，会读取该目录中的所有 socket 文件（跳过文件夹），并建立 socket 连接。\n目前，Layotto 向 Dapr 对齐，不负责用户组件的生命周期。这就意味着在服务期间，用户组件下线后不会进行重连，则该组件服务无法使用。后面会根据社区使用情况，来决定 Layotto 是否需要支持进程管理模块，或是使用一个单独的服务来管理。\n由于 Windows 对于 UDS 的支持还不是很完善，且 Layotto 本身取消了对 Windows 的兼容，所以新特性采用的 UDS 发现模式未对 Windows 系统做兼容。\n组件注册 如上面的数据流架构图所示，用户注册的组件需要实现 pluggable proto 定义的 gRPC 服务。Layotto 会根据 gRPC 接口，实现 Go interface 接口，这里对应于数据流图中的 wrapper component。wrapper component 与 built-in component 对 Layotto Runtime 来说没有任何区别，用户也不会有特殊的感知。\nLayotto 通过 gRPC reflect 库，获取到用户提供服务实现了哪些组件，然后注册到全局的组件注册中心，以供用户使用。\n开源之夏个人随访 自我介绍 大家好，我是陈亦昺，目前就读于杭州电子科技大学，大三学生。自从大二开始，我对开源产生了浓厚的兴趣，特别是在云原生和微服务领域。\n起初，我主要为我个人感兴趣的项目提供使用案例和文档支持，随后逐渐开始贡献一些简单的功能。例如，我为 Kratos 贡献了一个简单的 toml 配置文件解析器，并向 go-zero 提供了一些建议，改进了它的优雅关闭（Graceful Shutdown）功能。\n之后，我接触到了服务网格领域，认识了 MOSN 社区，并开始为其中的子项目 Layotto 做开源贡献：我修复了一些 makefile 脚本使用中的 bug、编写了 Go SDK 的使用文档、并尝试对 Nacos 组件进行封装。\n申请本社区项目的原因 SOFAStack 是一个金融级的云原生架构，内部孵化了许多吸引我的微服务项目。接触 SOFAStack 社区以来，我发现他们对开源贡献十分重视，仓库中有丰富的文档来帮助用户了解项目的背景、功能、代码模块等。\n👉SOFAStack 仓库地址：https://github.com/sofastack\nMOSN 项目也组织过源码阅读活动，将 MOSN 核心组件的代码设计整理成文档；仓库所有者也会为新人提供适合入手的 issue 作为开始。所以在 OSPP 活动开始之前，我其实就先认识了 SOFAStack 社区，并对其新兴项目 Layotto 做了一定的贡献。OSPP 开始后，我很快与导师取得联系，并得知可以参考 Layotto 对标项目 Dapr 的设计实现。于是，我翻阅了 Dapr 的相关文档、该功能实现时的 issues，阅读了该块功能的源码，最终得出适合移植到 Layotto 的方案。\n如何克服项目过程中的困难与挑战？ 在项目开发的初期阶段，导师会引导我了解项目的愿景、业务背景和代码结构；当我在开发过程中遇到困难时，导师为我提供了很多实质性的建议和改进方向；此外，社区每周三定期举行社区会议，让我们可以同步项目开发进度、讨论遇到的问题，共同寻求解决方案。\n在开发过程中我其实遇到了不少问题，其中一个让我印象深刻的是 Go 依赖冲突问题。早期，Layotto 参考了 Dapr 的一些组件接口设计，并直接引入了 Dapr 仓库的代码，这样直接复用了 Dapr 组件的功能，也避免了重复劳动。但是早期的 Dapr 并没有实现可插拔组件的功能，为了让新功能与 Dapr 组件保持兼容，我必须将 Dapr 升级到能够实现该功能的版本。\n然而，这两个版本之间存在许多不兼容的变化（尽管对外提供的服务接口并没有改变），所以一旦我升级了依赖，Layotto 就会出现大量错误。最终在与导师的沟通中，我们一致认为这部分兼容性工作的收益不大，只需实现新的接口供用户使用即可。\n你眼中的社区印象 SOFAStack 是一个充满开源精神的、热情的社区，欢迎并鼓励学生和开源爱好者积极参与其中。同时，SOFAStack 社区也是专业的，它专注于云原生和金融领域的技术创新和解决方案，旨在帮助开发者快速构建和管理云原生应用，提高应用的可伸缩性、弹性以及可靠性。\n一些收获 参加这次开源之夏项目使我获益匪浅。我对云原生有了进一步的深刻理解，并在实际业务操作中积累了宝贵的经验。同时，参加这个活动还扩展了我的知识技能，激发了我对开源项目做出贡献的热情。\n通过与导师和社区的合作，我学会了如何与其他开发者协作、如何提出和解决问题，并且还掌握了使用开源工具和资源的技巧。通过阅读 Layotto 和 Dapr 的源代码，我掌握了许多关于程序设计的经验，例如编写可测试的代码、命名规范、如何构建单元测试用例等等。这 …","date":1700550000,"description":"开源之夏经验分享｜Layotto 社区 陈亦昺：保持热情、全力以赴！","dir":"blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e50c0aaf2bd1fc9a639cb47390aa1839","permalink":"https://sofastack.github.io/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","publishdate":"2023-11-21T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","summary":"今天 SOFAStack 邀请到了开源之夏 2023 Layotto 社区的中选学生陈亦昺同学！在本项目中，他负责可插拔式组件的开发。希望他分享的这段经历，能让更多人了解到 Layotto 开源社区，","tags":["SOFAStack"],"title":"开源之夏经验分享｜Layotto 社区 陈亦昺：保持热情、全力以赴！","type":"blog","url":"/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","wordcount":2488},{"author":null,"categories":"SOFAStack","content":" 北京时间 2023 年 10 月 29 日，分布式事务开源项目 Seata 通过 Apache 基金会的投票决议，以全票通过的优秀表现正式成为 Apache 孵化器项目！\n根据 Apache基金会邮件列表显示，包含 13 个约束性投票（binding votes）和 6 个无约束性投票（non-binding votes）的投票全部持赞同意见，无弃权票和反对票，投票顺利通过。\n“Welcome Seata to the ASF incubator.”\n项目历史 早在 2007 年\n蚂蚁集团和阿里巴巴就在内部开发了分布式事务中间件，用于解决电商、支付、物流等业务场景中应用数据的一致性问题。内部项目分别被称为 XTS（eXtended Transaction Service）/TXC（Taobao Transaction Constructor），该项目几乎在每笔订单的交易支付链路几乎都有使用。\n自 2013 年以来\n蚂蚁集团在金融云上向企业客户发布了分布式事务云服务产品 DTX（Distributed Transaction-eXtended），阿里巴巴在阿里云上发布 GTS（global transaction service），两者均在各个行业领域积累了大量用户。\n2019 年 1 月\n阿里巴巴集团正式开源了该项目，项目命名为 Fescar（Fast \u0026amp;amp; Easy Commit and Rollback）。项目开源以来，它受到了众多开发人员的热烈欢迎和赞扬，开源一周收获了超 3k star，曾一度蝉联 GitHub Trending 排行榜第一。\n2019 年 4 月\n蚂蚁集团数据中间件团队加入了 Fescar 社区。为了创建一个更加开放和中立的社区，Fescar 改名为 Seata（Simple Extensible Autonomous Transaction Architecture），代码仓库从 Alibaba organization 迁移到其独立的 Seata organization。\n2019 年 12 月\nSeata 开源项目正式发布 1.0.0 GA 版本，标志着项目已基本可生产使用。\n2023 年 10 月\n为了更好地通过社区驱动技术的演进，蚂蚁集团和阿里巴巴携手，正式将 Seata 捐赠给 Apache 基金会，提案通过了 Apache 基金会的投票决议。\n项目现状 Seata 开源 4 年来，主项目在 GitHub 累计收获 star 超 24k，累计发布版本超 40 次，参与代码贡献人数超 300 人。\n Seata 被各领域企业/组织广泛应用于解决分布式事务问题，在 GitHub「Used by」拥有超过 3.1k 的仓库依赖，金融领域企业纷纷试点使用。\n Seata 对于市面上主流的关系数据库、RPC 框架做了广泛的支持，同时被许多第三方社区做了主动和被动集成。\n 项目特性 提供 AT、TCC、Saga 和 XA 事务模式，支持事务模式的混用，以满足不同业务场景的数据一致性需求。\n 提供 Java、Golang 等多语言 SDK 支持。\n 支持了 Apache Dubbo、Spring Cloud Alibaba、gRPC、Motan、SOFARPC、HttpClient 等服务调用框架。\n 提供了 MySQL、MariaDB、Oracle、PostgreSQL、OceanBase、TiDB、SQLServer、PolarDB、Dameng 等关系数据库无侵入 AT 事务模式的支持。\n 支持基于多种关系数据库、Redis 存储的存算分离的集群模式，支持基于 Raft 的存算不分离集群模式，满足不同运维场景下的集群高可用需求。\n 支持了市面上主流的注册中心和配置中心。\n 提供了丰富的插件化扩展机制，支持用户自定义 SDK 侧 30 多个扩展点。\n 致谢 感谢所有曾经参与到社区建设中来的贡献者。\n特别感谢愿意为 Seata 提供指导的 Champion 和 Mentors:\nChampion：\nSheng Wu（wusheng @apache.org）\nMentors：\nSheng Wu(wusheng @apache.org）\nJustin Mclean(justin @classsoftware.com）\nHuxing Zhang(huxing @apache.org）\nHeng Du(duhengforever @apache.org）\n我们坚信，将 Seata 引入 ASF 可以推动开源社区向着更强大、更多元化发展。我们将努力践行 Apache Way，同时欢迎更多的公司和个人加入到开发队伍中来，让 Seata 社区更加健康、茁壮地成长，让更多人享受开源带来的技术红利！\n项目寄语 四年前，我们秉持开源开放的理念，在社区写下了第一行代码。回顾过去四年，Seata 开源社区的技术演进和社区运营就像一次创业旅程。这四年我们取得了不菲的成绩，Seata 的出现快速占领了开发者的心智，成为了分布式事务领域的事实标准，在理论实践中我们牵头推动了行业标准的建立。Seata 捐赠给 ASF 是我们迈向更多元化社区治理和全球化发展的重要里程碑。\n\u0026amp;ndash; 季敏（Seata 开源社区创始人）\n恭喜 Seata 全票通过进入 Apache 孵化器！2019 年，蚂蚁集团和阿里集团携手一起开源了分布式事务框架 Seata，各自贡献了内部分布式事务的最佳实践。经过了四年的发展，Seata 早已成为一个被社区广泛认可的分布式事务项目，大量的贡献者在 Seata 里面贡献代码，丰富了 Seata 的各种功能，很多用户在自己的环境中使用 Seata，给 Seata 带来了大量的实践落地案例。Seata 进入 Apache 孵化器不是终点，而是新的起点，期待 Seata 后面能够持续按照 The Apache Way 的方式运作，以更加中立的姿态，吸引更多的贡献者和用户，走向更加宽阔的未来。\n\u0026amp;ndash; 黄挺（蚂蚁集团中间件负责人）\n非常高兴 Seata 这个阿里和蚂蚁合作多年的开源项目进入 Apache 基金会进行孵化，相信 Apache Way 会帮助项目更加社区化、服务更多人，也期待 Apache 的 Seata 能为社区带来更多微小而美好的改变。对于蚂蚁开源来说，Seata 进入 Apache 孵化也是一个重要的里程碑，希望未来有更多蚂蚁团队发起的项目能走上 Apache 之路。\n\u0026amp;ndash; 王旭（蚂蚁开源技术委员会副主席）\n分布式事务是微服务架构最复杂，技术水位最深的部分。阿里\u0026amp;amp;蚂蚁在开源捐献之前申请了数十个专利，开源之后在社区推动下高速发展，吸收 70%+外部开发者，大幅降低分布式的复杂度，扩展了分布式事务的生态；未来随着微服务高速发展，随着数据一致性要求越来越高，相信分布式事务会发挥越来越大的作用！\n\u0026amp;ndash;李艳林（阿里云微服务团队负责人）\nSeata 是一款由阿里巴巴和蚂蚁集团共同参与开发的分布式事务解决方案，广泛应用于两家公司的内部系统。它的突出特点在于高性能和简单易用，为微服务架构下的分布式事务处理提供了高效且可靠的解 …","date":1700118000,"description":"携手开源，共同见证｜Seata 进入 Apache 孵化器","dir":"blog/open-source-together-seata-enters-apache-incubator/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bc69512b849467987dfe2349cb824154","permalink":"https://sofastack.github.io/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","publishdate":"2023-11-16T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","summary":"北京时间 2023 年 10 月 29 日，分布式事务开源项目 Seata 通过 Apache 基金会的投票决议，以全票通过的优秀表现正式成为 Apache 孵化器项目！ 根据 Apache基金会邮件列表显","tags":["SOFAStack"],"title":"携手开源，共同见证｜Seata 进入 Apache 孵化器","type":"blog","url":"/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","wordcount":4740},{"author":null,"categories":"SOFAStack","content":" 文｜王连平（花名：烨川)\n蚂蚁集团容器团队专家\n本文 3441 字 阅读 9 分钟\n技术背景 Kubernetes 是容器编排的标杆平台，其标准化、插件化特性促使其拥有巨大的生态体系。众所周知，Kubernetes 是由其众多管控组件共同驱动容器交付的，但这种特性可会给开发人员和 SRE 在开发和运维过程中带来更高复杂性。\n当容器在交付过程出现错误，通常会使用 Kubectl 命令行工具查看 Pod 相关的事件，进而查看相关组件的日志定位具体的错误。这种方式存在效率低、信息少的缺点，导致问题排查耗时耗力。另外，容器在交付过程中会经历诸多阶段，比如调度、IP 分配、挂卷、容器创建和启动等，当此过程变得很慢时，需要精准定位到哪里是瓶颈点，最直接的方法是在所有管控组件做埋点，然后逐阶段分析问题。这种埋点方式带来了巨大的工作量，不易推进实施。\n针对这些问题，蚂蚁集团围绕 Kubernetes 平台构建了一套综合的容器观测服务——Lunettes。它利用 Kubernetes 多维度的交付信息（例如 API Server 请求、Audit 审计）构建了一套容器交付全生命周期观测服务，可以跟踪和诊断容器交付过程，并且基于诊断能力提供容器交付 SLI/SLO 服务，实现了数字化方式监控和管理 Kubernetes 容器服务。\n整体方案 在 Kubernetes 系统中，大量的管控组件在容器交付的过程中分工协作，为交付出来一个正常运行的容器不断的重试调和，过程中会产出大量的中间请求动作、日志等信息，Kubernetes 系统这种异步终态特性是容器交付可观测服务的一个关键挑战。那么在此类系统中观测容器交付过程，应该具备哪些特性呢？\n我们希望 Lunettes 应该具备：\n 提供多维度的容器交付信息，并且能优雅处理面向终态的机制\n 提供便捷的组件接入方式，尽可能小的侵入组件代码\n 提供较灵活的定制化或者配置方式\n 给用户提供简单易用的交互接口\n Lunettes 基于上述特性的考虑，整体采用旁路数据采集、数据分析和数据服务思路，围绕 Kubernetes 的审计日志做容器交付相关业务的分析，包括 Pod 基本信息、Pod 交付关键生命周期、Pod 交付诊断、Pod 交付跟踪和 Pod 交付 SLO 共 5 部分的交付数据。在数据分析链路上抽象出多个通用的模型，让用户灵活定制容器交付 Trace 及 SLO 诊断能力。同时，向上提供了 OpenAPI 和 Grafana UI 两种用户交互接口，便于用户信息消费。\n系统架构 上图示意了 Lunettes 系统的系统架构和数据链路，除了 Kubernetes API Server 审计数据源、数据采集和数据存储组件外，Lunettes 整体包括用户接口层和数据处理层两部分，其中数据处理层是 Lunettes 的核心业务逻辑所在。其处理流程如下：\n 从数据流向看，Filebeat 从 Kubernetes API Server 采集审计日志后，存储到 Elastic Search 中，在审计采集过程中使用 Filebeat Processor 进行冗余信息过滤，在数据存储 Elastic Search 时使用 Pipeline 增加必要时间序列，如此使得存储到 ES 中的数据量小而丰富。\n Lunettes 会近实时从 ES 拉取审计数据，审计进入 Lunettes 后首先会被 Share Processor 处理，这里处理主要分为 Pod 元数据信息提取、超事件（HyperEvent）抽象、以及并发反序列化审计请求中的 Raw Data，前置反序列化是为了减少后续 SLO、Trace 等业务处理时重复处理，提升性能。\n 数据经过 Share Processor之后，进入核心的交付分析模块，核心包括交付生命周期 Trace、交付 SLO 分析、交付原因分析及容器基础信息搜集，数据在模块之前按照需求做依赖 DAG，最终将产出 OTel、ES Table、Metrics 三种数据写入相关的数据服务。\n 存储到 ES、jaeger 和 prometheus 的数据，会被 Lunettes Rest API 和 Grafana di 处理，转换为 OpenAPI 数据接口和 Grafana Portal 上的数据进行展示。Grafana Portal 中一站式集成了 Lunettes 所有的功能，用户使用更便捷。\n Lunettes 核心能力 交付 SLO 交付 SLO 目的是基于 Kubernetes 交付链路能力对用户承诺交付保障。那么“交付 SLO”是什么呢？可以概括为：在一定时间内保障用户的容器可以成功交付。这个时间就是给用户的承诺，自然地 SLO 时间如何来定是非常关键的。Lunettes 主要从 Pod Spec 中获取资源规格、资源亲和配置等属性，计算出 Pod 的 SLO 时间。另外，Lunettes 也会根据 Pod 选择的不同交付链路（可以简单的理解为高速交付链路和普通低速链路）来给出保障时间。\n有了 SLO 超时计算标准，另一个挑战是如何计算 SLO 时间。如前文所述，容器交付链路中包含了多个阶段，Lunettes 将其区分为 Kubernetes 平台自身耗时和用户耗时两大类，通过 overlay 时间轴，去除用户时间后作为整体 SLO 时间保障。如此，对外承诺的 SLO 时间不会因为用户错误行为（配置、代码 bug 等）导致承诺失败。\n交付诊断 交付过程中出错是必然的，从庞大的 Kubernetes 系统快速定位容器交付过程中的问题是用户非常关心的。Lunettes 另一个重要的能力是从大量的容器交付行为信息中分析出容器交付的错误原因，用户通过 Portal 或者 OpenAPI 可以轻松获取容器交付的结果，如下图所示，Lunettes 在诊断结果中积累沉淀了 30 余种错误类型，帮用户快速定位问题。\n诊断过程中，Lunettes 采用回放审计日志技术，通过模拟容器交付过程抽象定义出原因分析 DAG 框架。审计日志回放输入 DAG 诊断框架后，各模块将分析自己阶段的交付是否完成，如果出错则抛出异常。最终，经过回放分析给出 Pod 出错位置，当然各分析模块是面向终态的分析过程。DAG 的框架既保证了分析过程行为的正确性，也提升了诊断流程的可扩展性。\n交付 Trace 交付 Trace 核心目的是跟踪每个 Pod 的交付过程，记录 Pod 交付过程中各阶段的耗时，以及对出错的阶段进行日志记录。一般地，在微服务系统中面向请求的 Trace 都是打桩，正如前文所述 Kubernetes 这种终态异步系统中，打桩每个管控组件是非常大的一个工程量，而且在组件之间异步分布式传递 Trace Context 很有挑战性。Lunettes 另辟蹊径，基于审计日志，抽象出 HyperEvent 概念，其包含了 Pod 交付过程中发生在 Pod 身上所有的 Verb 和 Event 两类信息，比如 Patch 一个 Condition 表示某个交付阶段完成，透出一个 Event 表示某个阶段结束。这两种信息被进一步用于定义交付 Trace 过程中每个阶段的开始和 …","date":1699945200,"description":"告别复杂性！用正确的工具轻松应对 K8s 管理挑战","dir":"blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"55bbf8c8afe1ee0fec5d19b4e8176065","permalink":"https://sofastack.github.io/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","publishdate":"2023-11-14T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","summary":"文｜王连平（花名：烨川) 蚂蚁集团容器团队专家 本文 3441 字 阅读 9 分钟 技术背景 Kubernetes 是容器编排的标杆平台，其标准化、插件化特性促使其拥有巨大的生态体系。","tags":["SOFAStack"],"title":"告别复杂性！用正确的工具轻松应对 K8s 管理挑战","type":"blog","url":"/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","wordcount":2785},{"author":null,"categories":"SOFAStack","content":" 今天，我们邀请到了开源之夏 2023 活动 Dragonfly 社区的中选学生李从旺同学，他此次承担的项目是——「PyTorch Serve 基于 Dragonfly P2P 技术分发模型」。希望通过他的开源故事，能让更多人了解到开源的魅力，也可以从不同的视角去认识 Dragonfly 项目。\n关于 Dragonfly Dragonfly 提供高效、稳定、安全的基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为孵化级别的托管项目。Dragonfly 在解决大规模文件分发场景下有着无可比拟的优势。P2P 技术在 AI 推理服务分发大模型场景现阶段应用较少，并且 P2P 技术经过证实也可以真正解决大文件分发过程中的性能瓶颈。在 AI 推理服务分发大模型场景，通过集成 Dragonfly P2P 技术减少源站压力，并且提高模型分发效率。结合 AI 推理领域生态拓展 Dragonfly 应用场景，服务 AI 领域并且成为重要基础设施。\n项目信息 项目名称：PyTorch Serve 基于 Dragonfly P2P 技术分发模型\n项目导师：戚文博\n项目描述：本项目是在 PyTorch Serve 分发过程中解决推理模型拉取时，可能会存在性能带宽瓶颈的问题，所以本项目需要 Dragonfly 通过 P2P 能力提高 PyTorch Serve 模型拉取速度，主要供过 Plugin 方式将 Dragonfly P2P 能力集成到 PyTorch Serve 中。\n项目链接：https://github.com/dragonflyoss/dragonfly-endpoint\n项目实现思路 无论你是需要安装或是升级，对 Dragonfly 各个组件的理解很重要，这是后期顺利进行性能测试的一个前提。\n Manager: 维护各 P2P 集群之间的关系，动态配置管理和 RBAC。它还包括一个前端控制台，方便用户直观地操作集群。 Scheduler: 为下载对等体选择最优的下载父对等体。异常控制 Dfdaemon 的返回源。 Seed Peer：Dfdaemon 开启的种子节点模式，可以作为 P2P 集群中的背向源下载节点，它是整个集群中下载的根节点。 Peer: 与 Dfdaemon 一起部署，基于 C/S 架构，提供 dfget 命令下载工具，dfget 守护进程运行守护进程提供任务下载功能。 架构 TorchServe 通过集成 Dragonfly Endpoint 插件，发送模型下载请求到 Dragonfly ，Dragonfly 作为代理去对应的 Object Storage 下载模型并返回。\n模型下载步骤：\n1、TorchServe 发起模型下载请求到 Dragonfly Peer。 2、Dragonfly Peer 会到 Dragonfly Scheduler 注册任务。 3、返回拥有资源的候选的父节点。 - Scheduler 服务发现本地 Cache 对这个任务是缓存未命中状态，就触发从 Seed Peer 进行文件下载。 - Seed Peer 如果对于任务也是缓存未命中状态，就会触发回源下载，即到对应的对象存储下载模型文件。 4、到对应的候选的父节点进行分片下载文件。 5、模型下载返回后，TorchServe 会进行模型注册。\n在性能测试的步骤中，会对模型下载的几种情况分别进行测试，而结果显示下载性能在命中缓存的情况下确实有极大的提升。\n开源之夏个人随访 自我介绍 大家好，我叫李从旺，是佐治亚理工学院电子与计算机工程专业研二的学生。去年就曾参加过开源之夏的活动，当时的任务是为 Apache APISIX 网关做插件。\n参加活动的原因 我之前参与过开源之夏，发现这个活动非常适合学生去了解以及深入参与到开源社区。众多的开源项目与技术发现可以让我们了解到行业中的最新动态，比如去年的云原生和今年的 AI 基础设施、大模型等。\n同时这种实践搭配的任务难度，在导师与社区的热心帮助之下，无论是为了磨练技术、建立社区连接，还是作为新手开源入门的起点都非常合适。对我来说，第二次参与活动的主要目的是了解并学习新技术。\n申请本社区项目的原因 主要是我对 Dragonfly 的 P2P 技术很感兴趣，并且它也符合我的技术栈。我提前了解过 Dragonfly 在业界的使用情况与热度，得知它作为实用的基础设施广泛被各个公司使用，且仍然在迭代新功能，于是便有了申请的想法。其次就是我对于插件的编写比较有经验，上手本次的项目会更加顺利。\n如何克服项目过程中的困难与挑战？ 主要的困难在于，之前我没想到 TorchServe 官方对于前端的插件支持较少，因此在调研初期，花费了较多时间去了解 TorchServe 的架构细节与插件的实现机制等。在插件的设计方案上也踩了不少坑：比如起初只考虑增加模型加速下载的部分，而官方 API 模型的下载与注册却是同时进行的；同时官方的代码设计中许多内部方法是不对外开放的，这样一来插件编写的方案也会有限制。这一问题的克服方法主要是反复查看官方代码、文档以及和导师沟通，不合理的方案不断地被导师淘汰，最终我找到了代码侵入最小的实现方式。\n还有开源项目从零开始搭建的困难，包括目录设计、工作流的设计、测试用例、文档编写（需要不断打磨）等工作。这些非 coding 的部分往往会占据更多的时间。我的建议是——积极参考社区优秀活跃的开源项目和直接询问导师，这样效率会比用搜索引擎快得多。因为很多规范是会随时间变化的，新项目当然要符合最新的规范。\n困难还出现在测试环节！整个插件的使用涉及到不同的对象存储、Dragonfly 以及 TorchServe 等多个组件；多种环境的部署以及不同的配置细节也需要付出额外的关注。当然，最大的挑战是由我硬件资源不足的电脑带来的，解决的办法主要是详细地记录步骤以及利用一些云计算资源，这对后期使用文档的撰写也非常有帮助。\n导师与社区带来的帮助 在整个开发的过程中，包括前期调研环节，导师给予我的帮助是巨大的。耐心、细心、负责是 Dragonfly 社区以及我的导师给我的最大感受了。他们不仅在技术上给出指导，在文档编写乃至后期的技术交流方面也都非常用心。开发周期内的每周例会和平时的信息反馈也都非常及时，我作为学生，体验也非常好。\n你眼中的 Dragonfly 社区印象 Dragonfly 致力于提供高效、稳定、安全的基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。目前社区还在不断壮大发展中，欢迎大家一起来参与开源共建。\n超出预期的收获 在调研中，我学习到了 Dragonfly P2P 的实现原理以及 TorchServe 各个模块的实现方案。在每周例会中，也有许多来自其他社区的同学或嘉宾， …","date":1699340400,"description":"开源之夏经验分享｜Dragonfly 社区 李从旺：社区贡献也是一种影响力","dir":"blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f093077c7b660418d01cdd971f144de1","permalink":"https://sofastack.github.io/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","publishdate":"2023-11-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","summary":"今天，我们邀请到了开源之夏 2023 活动 Dragonfly 社区的中选学生李从旺同学，他此次承担的项目是——「PyTorch Serve 基于 Dragonfly P2P 技术分发模型」。希望通过他的开源","tags":["SOFAStack"],"title":"开源之夏经验分享｜Dragonfly 社区 李从旺：社区贡献也是一种影响力","type":"blog","url":"/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","wordcount":2622},{"author":null,"categories":"SOFAStack","content":" 文｜谭崇康（*花名：见云*）\n蚂蚁集团高级技术专家\n本文 3781 字 阅读 10 分钟\n问题：K8s 服务运营需要更好的可观测能力 云原生系统以 Kubernetes*（K8s）*为基石，业界很多公司的基础设施也构建在 K8s 平台之上。作为公司的关键基础设施，K8s 平台的运营效率直接影响业务的稳定与效率。\n然而，将 K8s 作为服务运营与单纯的使用 K8s 存在很大的区别。在使用 K8s 时，我们关注是形形色色的功能，而在 K8s 服务运营过程中我们将更加聚焦 K8s 服务的质量以及效率。运营一个 K8s 服务需要关注的典型问题例如：\n 问题诊断及其效率：K8s 链路长、组件多、概念丰富、状态复杂等，如何快速诊断日常失败问题原因是一个很关键的能力； 服务质量衡量问题：如何衡量 K8s 平台服务整体资源交付效率以及调度、镜像拉取、IP 分配等各个环节的服务质量，进而引导服务能力的提升； 链路性能问题：如何发现、定位集群中的性能瓶颈，提升集群的资源交付吞吐； 运营体系化问题：当前社区的可观测服务更多关注的还是某些孤立的功能点，服务运营需要的是数字化、性能、效率、体系化等。 Lunettes：K8s 平台运营可观测工作空间 K8s 集群构成的容器服务平台，并努力提升平台服务的质量。在这个过程中，我们沉淀了很多运营工具以及相关的运营经验。基于这些工具及经验，我们构建了容器可观测服务 Lunettes，希望帮助大家更简单地运营 Kuberntes 服务。Lunettes 项目代码已经在 GitHub 平台开放，欢迎大家参与！\n项目链接：https://github.com/alipay/container-observability-service\nLunettes 服务提供的一些特性，包括：\n 定义了 K8s 资源交付效率的 SLO，并基于 SLO 产出了成功率相关的可观测数据，用户基于 SLO 衡量 K8s 整体及子服务的质量，同时发现服务能力受损等问题； 提供了容器一键诊断能力，Lunettes 分析 K8s 资源交付过程的各个阶段，产出当前运维过程中的问题，帮助用户快速定位及解决问题； 建设了一套无侵入的资源交付 Trace 能力，基于 Lunettes 分析的 HyperEvent 事件，用户可以看到资源交付链路中各个子阶段的耗时及错误，及时发现性能瓶颈点。 其他的一些易用特性包括：\n 统一的操作界面，支持多集群管理，一站式服务体验； 多维信息的聚合能力，提供日志、监控、Trace 等多维数据融合的能力。 Lunettes 是一个一站式的 K8s 容器可观测服务，能够为原生的 K8s 集群构建一个为服务运营打造的可观测工作空间，大幅降低了 K8s 服务运营的难度：\n 基于可扩展的多维可观测数据构建：Lunettes 将不同维度的可观测数据抽象为 HyperEvent，并在 HyperEvent 之上构建其他服务能力。我们可以方便地通过配置化封装能力将新的可观测数据维度封装成 HyperEvent 从而扩展 Lunettes 的数据聚合能力。 面向原生 K8s 集群，一键拉起：Lunettes 各个核心功能都具备灵活的配置能力，并且默认配置为原生 K8s 版本设计。Lunettes 可以采用普通 YAML 或 helm charts 部署，用户可以方便地在 K8s 集群一键拉起 Lunettes 服务。 构建 K8s 运营的完整的可观测工作空间*（workspace）*：Lunettes 提供了包含资源交付 SLO、容器生命周期诊断、容器生命周期 Trace、多维数据融合等常用的功能，为 K8s 集群提供一站式运营工作空间。 软件架构 Lunettes 服务的软件架构分为四层，分别为：\n 用户接口层 *（User-Portal）*：图形化交互基于 Grafana 构建，此外我们也提供 OpenAPI 接口； 可观测服务层 *（Observability-Services）*：包含阶段耗时分析、资源交付 SLO、资源交付诊断、资源交付 Trace 等多个可观测特性； 数据处理层 *（Data- Processing）*：Lunettes 具有可观测数据源扩展能力，支持 Operations、Events 等多种可观测数据，并将可观测数据统一封装为 HyperEvent，经由上层的 SharedProcessor 统一处理。在 Lunettes 中，可观测数据的处理是高度可配置化的，ConfigCenter 负责配置的管理。 存储层 *（Storage）*：Lunettes 的存储层支持多种存储服务，包含 Prometheus、ElasticSearch、SLS 等。 基础功能介绍 资源交付 SLO K8s 的核心功能是将资源以容器的形式交付出去。如何定义容器平台的资源交付质量是一个核心的话题。Lunettes 首先根据可观测数据定义容器生命周期中的各个阶段，区分基础设施阶段以及用户应用阶段，从而统计容器平台容器交付所花费的时间。进一步，Lunettes 根据容器交付的时间定义资源交付 SLO。下图中展示了集群的 1 分钟级以及 1 小时级 Pod 创建成功率的 SLO 数据。\n容器生命周期诊断 Lunettes 将诊断 Pod 创建流程中各个阶段的错误，形成典型容器创建错误码，例如 FailedScheduling 对应调度失败、FailedPullImage 对应镜像拉取失败等。典型的错误码将具备以下功能：\n 错误信息形成一个标准的错误集合，每个错误类型以可理解的方式代表特定的一类错误，给用户提供当前交付失败的诊断结果； 形成标准的 ErrorCode，作为上下游问题传递的依据，构建端到端的诊断链路； 当集群故障时，诊断结果作为聚合信息，当大量错误聚合时，方便我们快速定位到集群中的错误组件及错误原因。 在诊断过程中，Lunettes 将从底层的可观测数据中抽取生命周期中的关键事件，涵盖了 Operation、Events 等，帮助用户根据关键事件快速定位容器生命周期中的各种问题。\n资源交付 Trace Lunettes 设计了一套无侵入的资源交付*（创建、删除等）*过程 Trace 体系，基于 Lunettes 分析的 HyperEvent 事件，以用户可理解的方式分析资源交付过程中的各个阶段，例如 IP 分配、镜像拉取、Volume 绑定等，并基于这些分析构建了资源交付 Trace。通过资源交付 Trace，用户可以方便地找到资源交付过程中各个阶段的耗时及错误，从而掌握整个资源交付过程中的热点问题。Trace 与 Log、Event 等关联，帮助用户快速找到问题的根因。\n多维信息聚合能力 基于我们在过去多年积累的 K8s 运营经验，Lunettes 为日常运营活动中的多个典型场景设计，聚合了 YAML 信息、Event 信息、审计信息、Trace 信息、SLO 信息等多维度的可观测信息，为用户提供一个完整的 K8s 运营可观测工作空间。\n实践：几个典型的使用场景 Case1：诊断 Pod 创建失败 以镜像拉取失败为例，我们来看一下在 Lunettes 中， …","date":1698735600,"description":"Lunettes - 让 Kubernetes 服务运营更简单","dir":"blog/lunettes-makes-kubernetes-service-operations-easier/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"edc4c98af54696e29b070cc6ce02dea6","permalink":"https://sofastack.github.io/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","publishdate":"2023-10-31T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","summary":"文｜谭崇康（*花名：见云*） 蚂蚁集团高级技术专家 本文 3781 字 阅读 10 分钟 问题：K8s 服务运营需要更好的可观测能力 云原生系统以 Kubernetes*","tags":["SOFAStack"],"title":"Lunettes - 让 Kubernetes 服务运营更简单","type":"blog","url":"/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","wordcount":3487},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack GitHub issue 精选 本周各项目回复 issue 精选 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n1.@MOSN #2347\n@huayangchan\n 我们目前在调研阶段，想用 envoy 做来做流量代理，但是考虑到研发效能，所以想用 MOE 的方案看看。因为涉及到 L4 的流量处理，顺便再确认下，那对于企业内部自定义的 RPC 协议，涉及到四层的流量 filter 操作，基于目前开源版 MOSN 是做不‍到哈？只能基于原生 envoy 的 L4 extension 来做么？\n A：这个我们内部的做法就是 MOSN 的 xprotocol 框架支持多协议，然后再用 L4 MOE 嫁接到 envoy 上。收益还是很可观，没有链接的常驻协程。如果直接用 envoy 的 L4 的话，你其实还是需要用 Go 搞一套 proxy 框架出来的。你可以先用纯 MOSN 支持你们的 RPC 协议，然后再用 MOE 移植到 envoy 上。\n「MOSN」：https://github.com/mosn/mosn/issues/2347\n2.@SOFABolt #332\n@tongtaodragonfly\n 在我们的环境中，连接事件日志文件中出现警告消息，如下所示：\n未知协议代码：[ProtocolVersion{version=[3]}] 在 ProtocolDecoder 中解码时。] 为什么会报告此警告消息？什么样的情况可能会触发此警告消息？\n A：协议版本是应用层网络帧的第一个字节。通常为 1*（对于 BoltV1）*和 2*（对于 BoltV2 协议）*。如果第一个字节是 3，bolt 找不到对应的协议，所以你会看到这个错误。\n此问题可能有两个常见原因：\n 一些未知的客户端向您的端口发送错误的数据包； 解码器没有消耗掉一个数据包中的所有数据，因此存中留下了一些错误的数据。Decoder 下次消费数据时，读取到了错误的数据。 「SOFARPC」：https://github.com/sofastack/sofa-registry/issues/332\n3.@SOFAArk #741\n@jgslvwy\n 请问下 SOFAArk 子应用支持用 spring-boot-maven-plugin 吗？为什么示例里面子应用还用的 sofa-ark-maven-plugin？\n A：子应用使用 sofa-ark-maven-plugin 构建产物是可以热部署到基座的 Jar 包，你要用 spring-boot-maven-plugin 也是可以，子应用本身也是独立的 Spring Boot，只是不能热部署到基座 JVM 上而已。\n「MOSN」：https://github.com/sofastack/sofa-ark/issues/741\n本周推荐阅读 MoE 系列（六）｜Envoy Go 扩展之并发安全\nSeata Saga 模式快速入门和最佳实践\nGo 语言，如何做逆向类型推导?\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\n","date":1696575600,"description":"SOFA 聊天室、issue 精选","dir":"blog/sofa-weekly-1006/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0dd36b93af4616c470c2dacf6b00830c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-1006/","publishdate":"2023-10-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-1006/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 聊天室、issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-1006/","wordcount":1117},{"author":null,"categories":"SOFAStack","content":" 文｜梁仕威（花名：栖川）\n蚂蚁集团算法专家\n方略平台技术负责人，专注于分布式计算领域，主要负责蚂蚁基础算法的分布式设计与开发。\n本文 3419 字，阅读 9 分钟\n在类似安全风控这种对抗性的场景中，由于欺诈者作案手法的频繁变化，使得训练数据并不总会包含足够的信息给算法自动挖掘出优质的拦截规则，这种场景下高质量拦截规则的挖掘需要结合专家领域知识。如何将算法和专家领域知识相结合成为了业界一个值得探索的课题。蚂蚁集团 AI Infra 团队针对上述问题，构建了一个交互式的规则研发系统——方略，提供了一种在规则研发过程中高效融入专家领域知识的解决方案。\n描述该系统的 Demonstration Paper 《Fanglue: An Interactive System for Decision Rule Crafting》 近期已经被数据库领域的重要会议 International Conference on Very Large Data Bases （VLDB2023） 所接收。VLDB 是中国计算机学会 （CCF） 推荐的 A 类会议，每年都会吸引国内外各大高校和科技公司的投稿。\n1｜背景 决策规则由于其直观可解释的 If-Then 结构，被广泛应用于欺诈预防等金融科技领域至关重要的任务中。标准的决策规则由两部分构成：一系列条件和预测值。 条件是由特征、操作符、值构成的三元组结构，例如 age\u0026amp;lt;50。当规则中的所有条件都被满足时，规则会输出预测值。\n目前大多数现有的规则挖掘系统都是以端到端形式运行的，即给定训练集后，专家设定规则挖掘算法的优化指标和超参数，然后等待算法运行结束就可以获得一组规则。在这种方式下，设置超参数和优化指标是融入专家领域知识的唯一途径，一旦规则挖掘过程开始，专家就没有其他方法能够干预规则的生成。但是在如风控这种对抗性的场景中，由于作案手法的频繁变化，训练数据里并不总会包含足够的信息给算法自动挖掘出优质的规则。在这种情况下，专家必须将领域知识更深入地融合到规则生成过程中才能获得有意义的结果。\n举个例子，假设支付宝的一位风控专家，想要编辑规则来拦截一种新型欺诈行为。由于该欺诈行为是最近才出现的，他准备的数据集中只有少数关于这种欺诈行为的黑样本。假设这种欺诈行为的一个关键步骤是要求受害者向欺诈者发送多个付款码，因此短时间内付款码刷新的次数是识别这种欺诈活动的重要特征。然而风控专家发现挖掘算法返回的规则中没有使用该特征，大多数规则都使用了交易金额来区分欺诈行为和正常行为，因为数据集中的交易金额巧合地将这两种行为区分开了。但是随着新型欺诈行为的普及，交易金额就不能继续作为识别这种欺诈行为的有力依据了。这种现象在反欺诈场景中并不罕见，当黑样本太少时，无关的特征也能够区分出输入数据中的黑白样本。虽然付款码刷新频次确实是规则挖掘过程中一个非常有竞争力的特征 （例如评估指标排名靠前） ，但由于数据中噪声的影响，使得其不能排到最前面，从而不能被算法挖掘出来。这种情况下，将专家领域知识融入进来，让付款码刷新频次这个特征应用到拦截规则中，对阻止新型欺诈行为扩散尤为重要。\n为了能在规则研发过程中高效融入专家领域知识，蚂蚁集团 AI Infra 团队构建了一个交互式的规则研发系统——方略。方略为用户提供了一个 Web 界面来可视化地制定决策规则。用户将数据上传到方略后就可以开始规则研发流程，方略会实时地推荐出规则的候选条件与对应评估指标，并生成数据分析结果，为用户提供有用的定量分析信息。同时方略使用 Ray 作为计算引擎并将数据分布式存储在内存中，以满足在交互式处理大规模数据时的实时响应需求。\n2｜系统架构 （图 1）\n图 1 展示了方略的系统架构。用户通过 Web 界面与方略进行交互。方略的界面上有三个核心模块：条件推荐模块、条件编辑模块和规则评估模块。服务端的 Task Manager 负责接收来自三个核心模块的请求①，并且会启动相应的 Ray 作业②。\n用于计算的数据水平切分后预先加载进 Ray 的一组 Actor 内存里。对于一个特定的计算任务，每个 Actor 都会基于分配到的数据计算出局部统计信息，这些局部统计信息会汇集到 Driver 里进一步处理得到全局统计信息③。然后全局统计信息返回给 Task Manager④，并被传递给 Data Processor。Data Processor 在全局统计信息的基础上进一步处理，例如计算出各个候选条件的评估指标，得到的处理结果会在 Web 界面上展示给用户⑤。然后整个系统会等待用户的下一步操作。\n一旦用户作出某些操作 （例如从候选条件中选择一个加入到当前规则中） 触发相应的核心模块，系统就会重复上述过程。用户编辑好的规则会保存到数据库里⑥。\n3｜技术细节 不同于标准规则，方略采用合取范式 （Conjunctive Normal Form） 的规则表示形式，即同时支持“AND”和“OR”条件。合取范式规则是由一个或多个子句和一个预测值组成的合取式 （AND 连接） ，其中子句是条件的析取式 （OR 连接） ，条件的形式为特征、运算符、值。方略专注于二分类问题，使用训练集和验证集上的精确度、召回率、F1 得分或黑样本覆盖率等指标来评估决策规则。\n方略提供三种实时的条件推荐帮助用户构建规则： “AND”条件推荐、 “OR”条件推荐、近似条件推荐。\n假设我们已经有了一些子句构成的决策规则，需要往这个规则中增加一个“AND”或者“OR”条件，方略会搜索所有可能的三元组 （特征、运算符、值） ，并通过将这些候选条件附加到当前规则里计算评估指标。标准的规则学习算法会选择具有最佳指标的候选条件，而方略会在 Web 界面上展示在验证集上取得 top 评估指标的候选条件列表供用户选择。\n为了快速计算所有候选条件的评估指标，方略使用 Ray 作为计算引擎，每个 Actor 计算出局部统计信息，然后聚合到 Driver 里得到全局统计信息。为了验证系统的效率，我们在一个包含 140 万个样本和 50 个特征的数据集上进行了实验。图 2 对比了在生成“AND”候选条件下，方略的实现与基于 Mars on Ray （基于 DataFrame 运算） 实现的耗时。可以看到方略的实现非常高效，使用 16 个 Actor 就可以在 1 秒内返回结果，满足交互式环境下高响应的需要。\n（图 2）\n在安全风控场景下，当规则中存在一些容易被攻击的条件时 （例如拦截规则里有条件：转账金额\u0026amp;gt;=500，欺诈方只需要使得转账金额小于 500 就可以绕过拦截规则） ，风控专家会希望通过寻找“语义上相似”的条件来增加另一层保护。为了加强规则的鲁棒性，方略提出并引入了近似条件。假设当前的规则是 C1 and C2 and C3，覆盖的样本集为 A，我们希望在 C2 上增加近似条件，那么方略会在 C1 and C3 的基础上遍历所有的候选条件 （特征、运算符、值） ，每个候选条件都会覆盖数据的一个子集，记为 B。一个理想的近似条件应该在 A 和 B 之间具有高重叠度，同时又不引入太多额外的白样本。方略基于图 3 所示的公式衡量条件的相似度，其中表示中带有正标签的子集，表示中带有负标 …","date":1696316400,"description":"VLDB2023｜方略：一个交互式的规则研发系统","dir":"blog/vldb2023-fanglue-an-interactive-rule-development-system/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"310a7da278d5e5a913dc0e0d09ac6c02","permalink":"https://sofastack.github.io/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","publishdate":"2023-10-03T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","summary":"文｜梁仕威（花名：栖川） 蚂蚁集团算法专家 方略平台技术负责人，专注于分布式计算领域，主要负责蚂蚁基础算法的分布式设计与开发。 本文 3419 字，阅读 9 分","tags":["SOFAStack"],"title":"VLDB2023｜方略：一个交互式的规则研发系统","type":"blog","url":"/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","wordcount":3237},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议回顾 SOFAServerless：\n主题：SOFAServerless 社区会议 时间：09 月 27 日 19:30 - 20:30\n会议内容：\n 待跟进事项：\n ModuleController corner case 和多场景验证以及功能打磨\n 0.5 版本补充 ModuleController 和 Arklet 新 feature 使用文档\n 开源中间件排摸继续跟进\n 补充 0.5 版本原理文档\n 0.5 版本待合并收尾，开源之夏结项\n 发布内容：\n SOFAServerless 0.5.0 可试用版本已发布，详细可查看👇\n 试用手册 https://sofaserverless.netlify.app/docs/tutorials/base-create/springboot-and-sofaboot\n 试用样例 https://github.com/sofastack-guides/sofa-ark-spring-guides/tree/master/samples/web/tomcat\n 「SOFAServerless」：https://github.com/sofastack/sofa-serverless/issues/117\nSOFAStack 社区本周贡献 本周推荐阅读 蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata Saga 模式快速入门和最佳实践\n大象转身：支付宝资金技术 Serverless 提效总结\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\n","date":1695970800,"description":"SOFAServerless 社区会议回顾、社区本周贡献、SOFA 亚运特辑","dir":"blog/sofa-weekly-20230929/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5b9c3463eb10dee170d71426e96abb86","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230929/","publishdate":"2023-09-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230929/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议回顾、社区本周贡献、SOFA 亚运特辑","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230929/","wordcount":529},{"author":null,"categories":"SOFAStack","content":" 2023 年 9 月 20 日，KCL 项目通过了全球顶级开源基金会云原生计算基金会 （CNCF） 技术监督委员会评定，正式成为 CNCF 沙盒项目。\n这意味着 KCL 得到了云原生开源社区的认可，保障了项目的中立性，有利于开发者、合作伙伴等共同参与项目建设，协作共赢，并为云原生应用交付带来动态配置管理和自动化能力迈出了重要一步！\n 项目地址：https://github.com/kcl-lang/kcl 项目官网：https://kcl-lang.io 通过进入 CNCF 沙盒，KCL 社区将更多吸引更多开发者和用户参与共建，进一步推动项目在云原生业务场景的成熟应用，此外加入 CNCF 将为 KCL 提供一个增强的协作和创新平台。它提供了与处于云原生技术前沿的多元化开发者、组织和行业专家社区进行交流的机会。我们期待与其他 CNCF 项目进行更多合作，贡献我们的技术专业知识，并探索更多 CNCF 项目集成的可能性。\n什么是 CNCF CNCF，全称 Cloud Native Computing Foundation （云原生计算基金会） ，是 Linux 基金会旗下的子基金会。CNCF 致力于为云原生软件构建可持续生态系统，涉及领域包括存储、计算、编排、调度、CI/CD、DevOps、服务治理、服务网关等。\n比如 Kubernetes 便是 CNCF 最具代表性的项目之一。\n什么是 CNCF 沙盒项目 CNCF 社区将项目分为沙盒项目 （Sandbox） 、孵化项目 （Incubating） 、毕业项目 （Graduated） 。著名的毕业项目有：Kubernetes、Prometheus、Istio、ETCD、Containerd、ArgoCD 和 Helm 等。完整的毕业和孵化项目列表查看地址：https://www.cncf.io/projects/\nSandbox 是 CNCF 创建的，旨在为开源项目提供一个有益的、中立的家园，以促进开源项目的合作与开发。入选沙盒的项目，是被 CNCF TOC 认可的，并值得进行实验和开发的潜力项目。\nSandbox 对应的是 CNCF 社区早期项目，列表为：https://www.cncf.io/sandbox-projects/ 。进入 Sandbox 需要 66% 以上的 TOC （技术委员会） 成员赞成，即全部 11 人 https://github.com/cncf/toc#members 中的 8 人投赞成票。\n什么是 KCL KCL 是一个开源的基于约束的记录及函数语言，期望通过成熟的编程语言技术和实践来改进对大量繁杂配置比如云原生 Kubernetes 配置场景的编写，致力于围绕配置的模块化、扩展性和稳定性，打造更简单的逻辑编写体验，构建更简单的自动化和生态集成路径。\n项目主要里程碑如下：\n 2022 年 5 月，KCL 正式开源； 2023 年 6 月，KCL 正式成为 CNCF Landscape 项目； 2023 年 9 月，KCL 由 CNCF 应用交付 TAG 进行审核并通过 TOC 投票，顺利成为 CNCF Sandbox 项目 - https://github.com/cncf/sandbox/issues/48 为什么需要 KCL 正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在云原生配置和自动化的特定问题域内，我们使用专用配置和策略语言用于编写和管理规模化复杂配置及策略。不同于混合编写范式、混合工程能力的高级通用语言，专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将复杂配置和策略编写思路和方式沉淀到语言特性中。\n此外，KCL 期望通过更现代化的声明式配置语言和工具，在轻量级客户端云原生动态配置领域填补配置语言及工具的空白并解决如下问题：\n 维度爆炸: 大多数静态配置如云原生领域的 Kubernetes YAML 配置需要为每个环境单独进行配置；在最糟糕的情况下，它可能引入涉及环境交叉链接的难以调试的错误，稳定性和扩展性都较差。 配置漂移: 对于不同环境的静态管理应用程序和基础设施配置的方式，往往没有标准的方式去管理这些动态的不同环境的配置，采用非标准化的方法比如脚本和胶水代码的拼盘，会导致复杂度呈指数增长，并导致配置漂移。 认知负担: Kubernetes 等作为构建平台的平台技术手段在底层统一基础架构细节方面出色，但是缺乏更上层的应用软件交付抽象，对于普通开发者认知负担较高，影响了更上层应用开发者的软件交付体验。 针对如上问题，KCL 期望提供如下能力:\n 通过代码抽象等手段屏蔽基础设施和平台的细节和复杂性，降低研发者认知负担； 编辑和校验已有的存量配置或模版，直接解决云原生小配置场景问题如 Helm Chart 配置硬编码问题，但远不止如此； 通过配置语言无副作用地管理跨团队的大规模配置数据，提升团队协作效率。 具体来说，KCL 可以：\n 在代码层面提升配置语义验证的能力，比如 Schema 定义、字段可选/必选、类型、范围等配置检查校验能力； 提供配置分块编写、组合和抽象的能力，比如结构定义、结构继承、约束定义和配置策略合并等能力； 用现代编程语言的方式以编写代码的方式提升配置的灵活度，比如条件语句、循环、函数、包管理等特性提升配置重用的能力； 提供完备的工具链支持，丰富的 IDE 插件、语言和生态工具链支持用以降低上手门槛，提升使用体验； 通过包管理工具和 OCI Registry 使得配置以更简单的方式在不同团队/角色之间分享，传播和交付； 提供高性能的编译器满足规模化配置场景诉求，比如满足由一份基线配置根据部署上下文生成不同环境不同拓扑的配置的渲染性能以及配置自动化修改性能诉求； 通过多语言 SDK，KCL 语言插件等手段提升其自动化集成能力，在发挥配置及策略编写价值的同时显著降低 KCL 的学习成本。 除了语言自身，KCL 还提供了许多额外的工具如格式化，测试、文档等工具帮助您使用、理解和检查编写的配置或策略；通过 VS Code 等 IDE 插件，包管理工具和 Playground 降低配置编写和分享的成本；通过 Rust、Go 和 Python 多语言 SDK 自动化地管理和执行配置。\nKCL 能做什么 动态配置管理 作为一种配置语言，KCL 为应用程序和平台开发人员/SRE 提供的最重要的功能是动态配置管理。通过代码抽象，我们可以构建以应用为中心的模型屏蔽复杂的基础设施和平台概念，为开发人员提供一个以应用程序为中心且易于理解的界面。此外，KCL 还允许平台人员快速扩展和定义自己的模型，并且这些模型可以通过 OCI 注册表进行分享和复用。\n此外，KCL 还支持与 Kubernetes Resource Model (KRM) 规范直接集成，KRM KCL 是一个通用的配置模型规范，用于描述和管理各种云原生资源，如容器、Pod、服务的配置操作和抽象等。KRM KCL 规范提供了一种统一的方式来定义和管理这些资源，使得它们可以在不同的环境中进行移植和复用。它建立在一个完全开放的 Kubernetes 世界当中，几乎不与任何编排/引擎工具 …","date":1695711600,"description":"喜报！CNCF 基金会宣布 KCL 成为沙盒项目！","dir":"blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1b28ec99e654374176191b2a95853377","permalink":"https://sofastack.github.io/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","publishdate":"2023-09-26T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","summary":"2023 年 9 月 20 日，KCL 项目通过了全球顶级开源基金会云原生计算基金会 （CNCF） 技术监督委员会评定，正式成为 CNCF 沙盒项目。 这意味着 KCL 得到了云原生开","tags":["SOFAStack"],"title":"喜报！CNCF 基金会宣布 KCL 成为沙盒项目！","type":"blog","url":"/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","wordcount":4030},{"author":null,"categories":"SOFAStack","content":" 文｜唐荦彦\n深信服高级开发工程师，主要负责 SASE 云化架构以及基础设施建设\n本文 3056 字，阅读 6 分钟\n1｜你将在本文学到什么 多 K8s 集群镜像分发方案 Dragonfly 的理解 Harbor 的预热机制 Dragonfly 的使用以及排障 2｜K8S 多集群镜像分发问题 在边缘云架构的生产环境下，演进过程中，一开始的镜像分发方案如下：\n每个边缘集群都存在节点的 Harbor 仓库，进行缓存操作，当边缘集群集体崩溃重启过程中，不会引发所有 worker 上中心仓拉取镜像。\n带来的问题是：\n 每套环境一个 Harbor，导致部署、维护的困难。 Harbor 的复制策略比较简单，无法单例执行。并且重试非常占用中心仓带宽。 那么面对这种场景存在以下两种方案：\n Harbor 仓库分级复制策略 P2P 镜像分发策略 Harbor 仓库分级复制策略，存在以下问题：\n 如何进行分级划分 升级过程，如果节点所处的是第三级，如何触发复制策略加速缓存 每个节点增加了安全暴露面 节点的不断增加，后续是否需要 3 级、4 级、5 级，维护管理成本指数增加。 所以在项目中，我的选择是 Dragonfly 的 P2P 镜像分发策略。\n3｜Dragonfly 是什么 在理解过程中，首先需要搞懂以下几个问题：\n P2P 是什么？\n 镜像的分层拉取策略。\n 什么是 P2P 此 P2P 不是金融圈里面经常爆雷的，而是 Peer to Peer 网络技术。有几个比较突出的使用：\n 迅雷； 某夭折的播放器（*快 B*）； 国内一些视频网站白嫖用户网络的 P2P CDN。 为什么需要 P2P 网络 P2P 网络对应的就是传统网络传输 C/S 模式。传统模式下，所有的客户端请求数据下载都需要访问服务器，那么服务器的压力会非常大，当客户端多的情况下，网络带宽也存在问题。\n以下来自 WIKI 百科：\n对等式网络（*英语：peer-to-peer，简称 P2P*），又称点对点技术，是去中心化、依靠用户群（*peers*）交换信息的互联网体系。它的作用在于，减低以往网路传输中的节点，以降低资料遗失的风险。与有中心服务器的中央网络系统不同，对等网络的每个用户端既是一个节点，也有服务器的功能，任何一个节点无法直接找到其他节点，必须依靠其户群进行信息交流。\n镜像分层拉取 Docker 镜像通过分层进行资源共享，通过 copy-on-write 完成文件隔离。在执行 Pull 的时候，可以看到：\nc1c792ed5250: Already exists fcac137f6aa5: Already exists c31aa26549dd: Already exists 04699d7e44fb: Pull complete 可以分析得出，在 Docker pull 时，先会判断本地是否存在当前层，如果没有则从远端服务器拉取层。\nDragonfly 架构** 组件包括：\nManager: 多 Dragonfly 调度节点进行管理，提供了 UI 管理界面、镜像预热机制。\nScheduler:\n 基于机器学习的多场景自适应智能 P2P 节点调度，为当前下载节点选择最优父节点； 构建 P2P 下载网络的有向无环图； 根据不同特征值评估节点下载能力, 剔除异常节点； 当下载失败情况，主动通知 Dfdaemon 进行回源下载。 Dfdaemon： （*分为 Peer、Seed Peer*）\n 基于 gRPC 提供下载功能, 并提供多源适配能力； 开启 Seed Peer 模式可以作为 P2P 集群中回源下载节点, 也就是整个集群中下载的根节点； 为镜像仓库或者其他 HTTP 下载任务提供代理服务； 下载任务基于 HTTP 或 HTTPS 或其他自定义协议。 使用场景流程说明如下：（*当需要下载某一层镜像时*）\n Docker 在请求下载镜像时，通过配置 Docker http proxy 代理，将请求转发到 Peer 节点。\n Peer 节点进行本地缓存判断，查看是否存在该层镜像；\n 是，则直接响应。如图： 如果当前 Peer 不存在，将当前请求转发到 Scheduler；\n Scheduler 将判断 Seed Peer 中是否存在：\n 是，则将对应的地址返回，通知 Peer 去指定的 Seed Peer 拉取资源,如图： 否，则通知 Seed Peer 回源拉取，拉取成功后，Peer 再进行拉取。 最长路径：Docker -\u0026amp;gt; Peer -\u0026amp;gt; Seed Peer -\u0026amp;gt; 源站 -\u0026amp;gt; Seed Peer -\u0026amp;gt; Peer -\u0026amp;gt; Docker。\nDragonfly 操作实践（*Docker 版*） 由于 K8s 版本过于简单，封装了 Docker 手动操作部分，这里讲源码版本如何使用。\n源码安装\n从上面已经了解到：Docker pull 通过 http proxy 配置即可通过 Peer 拉取镜像，那么操作就简单了。\n步骤如下：\n 配置 Docker；\n 安装依赖组件：MySQL、Redis、Jaeger（*为了研究操作路径以及代码*）;\n 配置 Manager、Scheduler、Seed Peer、Peer；\n 详细步骤如下：\na.配置 Docker 配置 http proxy  vi /etc/systemd/system/docker.service.d/http-proxy.conf [Service] Environment=\u0026amp;quot;HTTP_PROXY=http://127.0.0.1:65001\u0026amp;quot; Environment=\u0026amp;quot;HTTPS_PROXY=http://127.0.0.1:65001\u0026amp;quot; 私有仓库的话，配置忽略证书 insecure-registries； vi /etc/docker/daemon.json { \u0026amp;quot;insecure-registries\u0026amp;quot;: [\u0026amp;quot;your.private.registry\u0026amp;quot;] } 重启 Docker：systemctl restart docker。\nb.安装依赖 MySQL: docker run -d --name dragonfly-mysql --restart=always -p 3306:3306 \\ --env MARIADB_USER=\u0026amp;quot;dragonfly\u0026amp;quot; \\ --env MARIADB_PASSWORD=\u0026amp;quot;dragonfly\u0026amp;quot; \\ --env MARIADB_DATABASE=\u0026amp;quot;manager\u0026amp;quot; \\ --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=\u0026amp;quot;yes\u0026amp;quot; \\ mariadb:10.6 Redis：\ndocker run -d --name dragonfly-redis --restart=always -p 6379:6379 \\ redis:6-alpine \\ --requirepass …","date":1695106800,"description":"Docker 环境基于 Dragonfly 的 Kubernetes 多集群镜像分发实践","dir":"blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a9c41894dec9bab10278add3e654f859","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","publishdate":"2023-09-19T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","summary":"文｜唐荦彦 深信服高级开发工程师，主要负责 SASE 云化架构以及基础设施建设 本文 3056 字，阅读 6 分钟 1｜你将在本文学到什么 多 K8s 集群镜像分发方案 Dragonfly 的理解 Harbor 的","tags":["SOFAStack"],"title":"Docker 环境基于 Dragonfly 的 Kubernetes 多集群镜像分发实践","type":"blog","url":"/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","wordcount":2798},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题： Layotto 社区会议\n时间： 09 月 20 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入： +02162681677（中国大陆）+057128095818（中国大陆）\n入会链接： https://meeting.dingtalk.com/j/r3Nq5pEd730\n议题：\n Layotto 项目规划和展望 #976 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910 2023 CSDI SUMMIT #987\n add uds support for Java SDK\n 「Layotto」：https://github.com/mosn/layotto/issues/989\nSOAFServerless：\n主题： SOFAServerless 社区会议\n时间： 09 月 19 日 19:30 - 20:30\n入会口令（钉钉）： 909 575 00367\n电话呼入： +02162681677（中国大陆）+057128095818（中国大陆）\n入会链接： https://meeting.dingtalk.com/j/eU7EoXJYiHK\n议题：\n 已完成部分\n 健康状态检查方案 review\n 基座引用的 starter，支持 Spring Boot、SOFABoot，Arklet 版本推到 Maven 中央仓库\n 增加锁控制\n 修复 ModuleController 使用 Arklet 遇到的问题\n 基座 Starter，Arklet 0.4 版本打包发版\n 待迭代事项\n SOFAArk\n 基座模块 1:1 复用\n 支持 SOFABoot 4\n SOFAServerless\n 支持中间件列表与优先级，排摸支持情况，设计评测标准\n 官网搭建\n ModuleController\n 先扩后缩\n 模块回滚\n 模块流量 Service\n 强推基线\n 单测达到 80/60、8+ 集成测试、CI 自动化、开发者指南 #72 #73\n ModuleController 各项参数校验\n replicas = -1 表示对等架构\n Arklet\n 服务的跨 Spring Context 发现与调用\n 健康状态检查方案 review\n 增加影响基座健康状态的能力，查询健康状态指令模块安装支持远程协议\n 【spring-boot-ark-plugin】#74\n 【Arklet】指令耗时统计和资源消耗统计设计 #77\n Arkctl\n Arkctl 增加模块对应实例与状态查询\n Arkctl 增加模块代码初始化能力 #83\n Arkctl 增加模块部署能力 #82\n Arkctl、Arklet、ModuleController 0.5 发版本\n 「SOFAServerless」：https://github.com/sofastack/sofa-serverless/issue/100\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：09 月 13 日 14:00 - 15:00\n会议内容：\n 项目规划方向补充\n Wasm 组件的规划 资源隔离 开源之夏\n Dapr component 升级的讨论 集成 K8s 注入的进度分享和思路讨论 CSDI Summit 社区成员分享同步\n add uds support for Java SDK 的同步\n 「Layotto」：https://github.com/mosn/layotto/issues/989\n「会议回放」：https://www.bilibili.com/video/BV1UF411D77o\nSOFAStack 社区本周贡献 本周推荐阅读 SOFABoot 4.0 正式发布，多项新特性等你来体验！\n蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata-DTX｜分布式事务金融场景案例介绍\nSOFARegistry | 大规模集群优化实践\n","date":1694761200,"description":"SOFA Weekly｜SOFAServerless 社区会议预告、Layotto 社区会议回顾与预告、C 位大咖说","dir":"blog/sofa-weekly-20230915/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa9ec5c3db35fbfd01dcafbf949b707b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230915/","publishdate":"2023-09-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230915/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议预告、Layotto 社区会议回顾与预告、C 位大咖说","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230915/","wordcount":1262},{"author":null,"categories":"SOFAStack","content":" 文｜王勤龙（*花名：长凡*）\n蚂蚁集团 AI 系统工程师\n文｜张吉（*花名：理之*）\n蚂蚁集团 AI 系统工程师\n文｜兰霆峰\n四川大学 20 级计算机系\n本文 5104 字 阅读 13 分钟\n01 背景 如今大语言模型（*LLM*）的分布式训练节点规模越来越大，训练耗时长。比如 OpenAI 在 1024 个 NVIDIA A100 GPU 上训练 GPT-3 大约需要 34 天。训练节点越多，耗时越长，训练期间节点故障概率就越大，况且 A100 GPU 的故障率也相对较高。所以大规模训练作业难免会遇到节点故障。据我们在蚂蚁 GPU 训练集群上观察，一个月内，单卡的故障率约 8%，那么一天单卡的故障率约为 0.27%。常见的故障原因有 Xid、ECC、NVLINK error 和 NCCL error 故障等。对于一个千卡训练作业来说，卡故障导致一天内训练失败的概率高达到 93%。所以训练作业几乎每天都会失败。作业失败后，用户需要手动重启作业，运维成本很高。如果用户重启不及时，中间间隔的时间就会导致 GPU 卡空闲，浪费昂贵的算力资源。\n有些故障会导致机器不可用，从而导致可用节点数量不能达到用户指定的数量。这时，训练就不能启动，用户需要手动减少节点数量后重新提交作业。待故障机修复后，用户又需要手动增加作业的节点数来重启作业。这样增大了用户的运维成本，也导致了新节点无法及时加入训练。\n为此，DLRover 在 Kubernetes 上基于 Torch Elastic 开发了弹性训练功能，实现 PyTorch 分布式训练的自动容错和弹性。具体功能如下：\n 出现故障后，快速执行节点健康检测，定位故障机并将其隔离，然后重启 Pod 来替换故障节点。\n 健康检测通过后，重启训练子进程来自动恢复模型训练，无需重启作业或者所有 Pod。\n 节点故障导致可用机器少于作业配置，自动缩容来继续训练。集群新增机器后，自动扩容来恢复节点数量。\n 优化 FSDP 并行训练的模型 save/load，支持根据实际卡数 reshard 模型参数，缩短 checkpoint 保存和加载时间。\n 在 DLRover 弹性容错应用在蚂蚁大模型训练前，一周内千卡训练运行时间占 60.8%，有效训练时间约 32.9%（*有效训练时间=模型迭代的步数*每步的时间*）。除此之外，训练运行时间还包括 checkpoint 保存时间和训练回退时间等。DLRover 上线后，一周内千卡训练运行时间占比提升至 83.6%，有效训练时间提升至 58.9%。\n02 PyTorch 弹性训练框架 弹性训练是指在训练过程中可以伸缩节点数量。当前支持 PyTroch 弹性训练的框架有 Torch Elastic 和 Elastic Horovod。二者显著的区别在于节点数量变化后是否需要重启训练子进程来恢复训练。Torch Elastic 感知到新节点加入后会立刻重启所有节点的子进程，集合通信组网，然后从 checkpoint 文件里恢复训练状态来继续训练。而 Elastic Horovod 则是每个训练子进程在每个 step 后检查新节点加入，子进程不退出的情况下重新集合通信组网，然后有 rank-0 将模型广播给所有 rank。二者的优劣对比如下：\n通过上述对比可以看出，Torch Elastic 重启训练子进程的方案对用户更加友好，支持更多的分布式训练策略和模型。而 FSDP 和 NCCL 是当前大模型分布式训练使用最为广泛的技术。所以 DLRover 选择使用 Torch Elastic 重启子进程的方案来实现 Kubernetes 集群上分布式训练的弹性容错。\n03 集合通信动态组网 动态组网是指训练进程可以自动根据动态变化的节点数量来组网集合通信，无需固定给各个节点指定集合通信的 rank 和 world size。动态组网是弹性容错训练必须的，因为弹性容错作业中，节点的失败、扩容或者缩容都会导致节点的 rank 和 world size 变化。所以我们无法在作业启动前给节点指定 rank 和 world size。\nTorch Elastic 动态组网 Torch Elastic 启动子进程后，所有子进程需要进行集合通信组网。Torch Elastic 使用 Dynamic Rendezvous 机制来协助子进程组网。每个节点上运行一个 ElasticAgent，ElasticAgent 会从一个共享存储中获取作业节点的 host group，然后将自己的 host 加入 group 并同步到共享存储里。这个共享存储当前默认使用 TCPStore。接着，ElasticAgent 不断从共享存储里获取查询 host group，直到 host group 里的节点数量达到最小节点数量 min_nodes 且一段时间内没有变化，即认为所有节点都准备好了。然后，ElasticAgent 就可以从 host group 里获取自己的节点 rank（*PyTorch 中称为 group rank*）和 world size。这样，ElasticAgent 就可以给拉起的子进程配置 local rank、global rank 和 world size 了。有了这些信息，子进程就可以进程集合通信组网。\n但是使用 Torch Elastic 原生方案中，我们发现一些问题：\n 节点不能容错。TCPStore 在一个训练节点上，如果该节点挂了，重组网就没法继续了。\n 节点 rank 是随机的。ElasticAgent 同步 host 到共享存储的顺序是随机的，导致节点 rank 的随机。在训练代码中，用户一般会将模型迭代信息输出在 rank-0 的日志里，比如 step、loss 和耗时等。用户只能通过进程日志寻找 rank-0 ，对于多节点的作业，这是比较麻烦的。\n Torch Elastic 的动态组网不能控制组网的节点数量。比如 LLM 模型训练中，用户可能会将 4 个节点作为一个数据预处理的组，那么弹性伸缩需要保证节点数量是 4 的整数倍。而 Torch Elastic 只要发现有一个新节点加入就会立刻重启训练。  DLRover 动态组网 针对上面问题，DLRover 重新实现了 PyTorch ElasticAgent 的动态组网模块 RendezvousHandler，利用 ElasticJob 点 Master 来协助 PyTorch 组网。Master 是一个纯 CPU 节点，不参与训练，稳定性比 GPU 节点高很多。\n（DLRover ElasticJob 动态组网）\nDLRover 的 ElasticJob 在启动 Pod 时，会给每个 Pod 一个唯一的编号 Pod ID 并配置到 Pod 的环境变量里。训练节点的 ElasticAgent 的 RendezvousHandler 会将自己的编号 Pod ID 和 GPU 卡数上报给 Master 的 Rendezvous Manager。然后不断从 Master 中请求通信 world，即所有节点的信息。Master 的 Rendezvous Manager …","date":1694502000,"description":"DLRover 在 K8s 上千卡级大模型训练稳定性保障的技术实践","dir":"blog/dlrover's-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9873bd3dccef5853a61dc3c706403d5d","permalink":"https://sofastack.github.io/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","publishdate":"2023-09-12T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","summary":"文｜王勤龙（*花名：长凡*） 蚂蚁集团 AI 系统工程师 文｜张吉（*花名：理之*） 蚂蚁集团 AI 系统工程师 文｜兰霆峰 四川大学 20 级计算机系 本文 5104 字 阅读 13 分","tags":["SOFAStack"],"title":"DLRover 在 K8s 上千卡级大模型训练稳定性保障的技术实践","type":"blog","url":"/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","wordcount":5172},{"author":null,"categories":"SOFAStack","content":" 1. 前言 本文是支付宝资金技术团队在《大象转身-支付宝资金技术交付提效之路》系列总结之一。如果你正在负责一个所支撑的业务面临从平台到场景化创新的发展阶段，希望通过提升交付效率来提升技术团队的竞争力和团队研发幸福感， 那么这篇文章也许会让你有收获：\n Serverless 的技术理念是什么？对业务研发有什么借鉴意义？\n 如何基于 Serverless 驱动研发模式的升级，设计一个能让场景化创新快起来的技术架构，提升全局研发效率？\n 本篇作者：呆莫（代巍）、歆明（何鑫铭）\n文章较长，建议收藏和保存\n为什么写这篇文章 我们做了近两年的 Serverless 研发模式的探索和落地，目前该模式已经承接了大部分资金业务的场景，平台也已经进入推广期，有 20+ 团队经过 SOFAServerless 技术团队的介绍找到我们。未接入 SOFAServerless 的想从业务视角寻求架构选型依据和应用架构设计，已接入 SOFAServerless 的同学来寻找基座治理经验。因此决定写一篇文章，将我们的架构选型、设计和落地经验做一次完整的总结。\n2. 我们遇到的问题 我们的问题：随着场景创新增多，SOFA 应用变臃肿、团队研发人数变多导致研发和运维难度升高，阻碍了业务创新的交付效率，系统需要做重构。\n简单说说背景 资金在这两年时间，肩负了很多业务创新、寻找业务增量的目标。增量时代的创新是残酷的，成功的明星产品背后，是无数次的失败（这三年间，技术支撑了 15+ 个创新产品的建设，包括小程序、行业解决方案）。而支付团队转型做创新也面临着巨大的挑战：动辄 1-2 个月起的研发交付周期，在当时使得技术团队被按在地上摩擦，各种问题接踵而来。\n蚂蚁集团 CTO 苗人凤曾经说过，创新是九死一生，技术就是要帮助业务降低机会成本。\n我们逐渐意识到业务创新的快速发展，一定离不开业务快速交付的新型技术研发模式。如果我们还是沿用平台化的架构思路，在一个庞大的资金平台上写一堆创新场景的代码，在完成业务需求的同时还要思考如何抽象、如何保障增量的代码不影响平台稳定性，那一定快不了。\n2021 年，我们成立“资金场景创新提效项目”，试图通过平台架构升级、研发模式升级解决场景创新效率问题。\n问题定义：资金场景应用变成巨石应用带来一系列问题 试着代入一下案例：\n如果有那么 5 个创新业务迭代在同一个应用发布窗口进行推进，会存在各种各样导致延期的原因:\n1、A 业务验证延后 2 天，那么 5 个迭代都要延后 2 天；\n2、B 业务升级了中间件版本，那整个应用的业务都面临回归成本一样要延后整个发布期；\n3、C 业务想要在预发搭个车微调一些代码，但是由于动作慢没能成功验证，导致污染了主干，进而耽误了整体；\n……\n 在应用架构层面，资金部门早期孵化出了一个“大资金场景层应用”——Fundapplication。Fundapplication 在研发协作方面，从一开始的几个同学，到后来几个业务团队、几十个研发同学，都在一个应用系统上研发，通过多个 bundle 区分不同业务，公共的 bundle 沉淀通用能力和研发工具（*类似于之前的 mng 系统*），如下图：\n这种架构设计在遇到大量的彼此没有复用的业务创新需求时，就逐步沦为了巨石应用，如下图：\n1、研发运维效率低：作为入口系统，mgw 接口无法在本地开发自测，改动任何代码必须发布到联调环境。发布一次需要 10 分钟以上，还要忍受环境不稳定因素带来的额外时间花费。\n2、业务迭代抢占，协同成本高：系统作为创新应用系统，有 10+ 个创新产品，30+ 个正式员工和外包员工也在这个系统上做研发迭代，火车式发布迭代痛点明显——一人晚点，全体延期。\n3、研发时隔离效率低：30+ 研发同学（含外包）在一个系统内研发，经过不到一年的时间，我们的系统就变成 10+ 个 bundle、2w+ 个 Java 文件（*全站均值 4000*）的体量了，因为各种业务的各种依赖的增加，系统启动一次需要 15 分钟。随着创新场景增多会变得更加糟糕，而且很多代码没有办法随着业务的下线而删除。\n4、运行时不隔离：目前我们没有对不同的业务区分不同的机房，业务吃大锅饭，难以做到按产品的资源和稳定性保障。\n如果你的应用也存在上述问题，对业务创新的交付效率产生了一定的影响，那可以继续参考第 3、4 章我们的架构选型和关键设计。\n3. 应用架构的选型 当前蚂蚁基于 SOFABoot 的应用架构，在规模化创新场景研发的交付效率、分工协作模式上存在局限性。从行业的发展趋势分析，云原生等新技术引领的“集装箱”架构模式，有利于促进规模化的生产效率和分工协作方式。借助蚂蚁 SOFAServerless 的孵化，我们决定作为种子用户，使用 Serverless 中 BaaS+FaaS 的理念，重塑创新场景研发的研发模式。\n微服务应用架构的局限性 大应用创新的模式，是在一个应用系统中按照不同 bundle 来隔离创新应用，可复用的代码可能是放到一个公共的 bundle 中。优点当然是复用效率高，运维统一，缺点主要是协作效率、隔离成本和研发效率。大应用变成巨石应用如何解决？这个我们很容易就想到使用分治的思路，将一个大应用拆成多个应用，通过 RPC 来互相调用。\n在蚂蚁当前体系下，微服务系统的 0-1 成本、后续运维成本、硬件机器成本仍然会是一个不小的开销，创新试错还是快不起来。且后端业务创新具有巨大的不确定性，如果因为业务没量了变成长尾系统下线的成本也很高；在性能方面，多个系统间通用能力的调用，会使全链路的调用耗时增加，在业务上不可接受。所以有没有一种技术，可以让业务既能够隔离，又能够降低隔离带来的负向影响：运维成本、能力复用效率、性能？\n行业技术架构的发展趋势 一部分做架构的同学喜欢用“架构隐喻”来介绍架构的理念。近几年容器化、云原生、Serverless 等新技术层出不穷，作为架构师需要在对新技术保持敏感的同时，能够有一双洞察架构本质的眼睛。\n这些底层新技术的出现，本质上是通过抽象定义“集装箱”的方式，规范了构建、部署、运行、运维标准，提升了软件的生产效率。大家可以感受一下这些技术底层理念的相通之处：\n Docker 通过定义容器“集装箱”提升传统虚拟机、基础设施软件构建、运维效率；\n K8s 进一步抽象万物皆可定义为 CRD（*自定义资源*）提升“集装箱”的部署、运维效率；\n 中间件 Mesh 化将“集装箱”理念应用到中间件近端，将中间件近端与业务代码剥离解耦；\n BaaS、FaaS 等 Serverless 技术，将“集装箱”理念范围进一步扩大到可复用的“业务领域插件”。\n 可以这么说，集装箱改变世界航运效率，计算机软件行业的 Docker、K8s 们通过“集装箱”的架构理念改变了基础软件生产效率。而随着 Serverless 的兴起，“集装箱”的架构理念将会自底向上地，重塑对软件交付效率重度依赖的互联网、金融等行业。\n我们来看下，集装箱的理念对我们业务研发的启示：\n过去，业务研发需要关注独立的业务应用，既需要关注业务代码、中间件代码等代码信息，又需要关注 Java 进程、CPU、内存等运维信息，随着这两年蚂蚁 MOSN 等 Service …","date":1693897200,"description":"大象转身：支付宝资金技术 Serverless 提效总结","dir":"blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","fuzzywordcount":12500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d09a365280bac8113c2d8e53309c4911","permalink":"https://sofastack.github.io/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","publishdate":"2023-09-05T15:00:00+08:00","readingtime":25,"relpermalink":"/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","summary":"1. 前言 本文是支付宝资金技术团队在《大象转身-支付宝资金技术交付提效之路》系列总结之一。如果你正在负责一个所支撑的业务面临从平台到场景化创新的","tags":["SOFAStack"],"title":"大象转身：支付宝资金技术 Serverless 提效总结","type":"blog","url":"/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","wordcount":12433},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAChannel#35 预告 SOFABoot 是蚂蚁集团开源的基于 Spring Boot 的研发框架。近期，SOFABoot 更新了 4.0 版本，带来了更多新特性。不仅正式支持了 Spring Boot 3 版本，也同时做出了包括历史功能演进在内的一系列调整优化，使得框架自身更加易用。\n本期 SOFAChannel#35 邀请到了蚂蚁集团技术专家、SOFABoot 项目 Maintainer 胡子杰跟大家分享 《SOFABoot 4.0 — 迈向 JDK 17 新时代》。\nSOFA 社区会议预告 SOFAServerless：\n主题：SOFAServerless 社区会议\n时间：09 月 04 日 19:30 - 20:30\n入会口令（钉钉）：909 575 00367\n电话呼入：+057128095818（中国大陆） +02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/EQzqQVtJoro\n议题：\n 8月回顾\n Arklet 待完成的动作\n 增加影响基座健康状态的能力，查询健康状态指令\n ModuleController 的功能\n 各项参数校验、单测达到 80/60、8+ 集成测试、CI 自动化、开发者指南\n 各组件的发版 release\n ModuleController 0.3\n Arklet 0.3\n SOFAArk 2.2.2\n 9 月迭代规划讨论\n SOFAArk\n 基座模块 1:1 复用 ClassLoader\n 支持 SOFABoot 4\n SOFAServerless\n 支持中间件列表与优先级，排摸支持情况，设计评测标准\n 基座 Starter，Arklet 的打包发布\n ModuleController\n 新扩后缩\n 模块回滚\n 模块流量 Service\n Arklet\n 服务的跨 Spring Context 发现与调用\n Arkctl、Arklet、ModuleController 0.5 发版本\n 「*SOFAServerless*」：https://github.com/sofastack/sofa-serverless/issues/44\nLayotto：\n主题：Layotto 社区会议\n时间：09 月 06 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+02162681677（中国大陆）+057128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/MkM4YQVrEE3\n议题：\n Layotto 项目规划和展望 #976\n 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959\n Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\n Develop a new component for sms API；为“短信 API”开发新的组件 #830\n 「*Layotto*」：https://github.com/mosn/layotto/issues/984\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：08 月 30 日 14:00 - 15:00\n会议内容：\n 下半年规划与展望\n SDK 模式、公有云部署的两个方向明确 开源之夏\n Layotto K8s 集成：关于动态配置注入思路的讨论\n 短信邮件 API：API 适配不同云厂商的组件具体开发\n 「*Layotto*」：https://github.com/mosn/layotto/issues/984\n「*会议回放*」：https://www.bilibili.com/video/BV1bz4y1K7RG\nSOFARPC 5.11.0 版本发布 发布 SOFARPC 5.11.0 版本，主要变更如下:\n 支持 SOFARPC 在 Mac M1 芯片环境编译\n 修复直连调用时，url 拼接错误的问题\n 升级 Hessian 到 3.5.0\n 升级 Bolt 到 1.6.6\n 升级 gRPC 到 1.53.0\n 升级 SOFARegistry 到 6.3.0\n 升级 Dubbo 到 3.1.8\n 升级 Javassist 到 3.29，引入新版 API，支持在 JDK 17 环境下使用\n 解决部分 SOFABoot 4.0 下的兼容性问题，现在 SOFARPC 支持基于 SOFABoot 4.0 运行\n 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.11.0\nSOFAHessian 3.5.0 版本发布 发布 SOFAHessian 3.5.0 版本，主要变更如下:\n 新增了 Currency、 Atomic、Throwable、StackTraceElement 类的定制序列化器，支持在 JDK 17 环境下运行\n 针对内部的反射逻辑做了一定的调整，支持在 JDK 17 环境下运行\n 详细发布报告：https://github.com/sofastack/sofa-hessian/releases/tag/v3.5.0\nSOFAStack 社区本周贡献 本周推荐阅读 SOFABoot 4.0 正式发布，多项新特性等你来体验！\n蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata-DTX｜分布式事务金融场景案例介绍\nSOFARegistry | 大规模集群优化实践\n","date":1693551600,"description":"SOFAChannel#35 直播预告、SOFARPC/SOFAHessian 新版本发布、社区会议","dir":"blog/sofa-weekly-20230901/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4506495f5728921c30461c2adf82271f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230901/","publishdate":"2023-09-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230901/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAChannel#35 直播预告、SOFARPC/SOFAHessian 新版本发布、社区会议","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230901/","wordcount":1753},{"author":null,"categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区 活动时间：09 月 07 日，周四晚 19 点 活动形式：线上直播 资料下载： 点击获取 B 站直播间地址：http://live.bilibili.com/21954520 B 站直播回放：SOFAChannel#35 介绍 | SOFAChannel SOFA:Channel 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\nSOFA:Channel 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\nSOFABoot 项目简介 SOFABoot 是蚂蚁集团开源的基于 Spring Boot 的研发框架，提供了诸如 Readiness Check、模块化和日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\n近期，SOFABoot 更新了 4.0 版本，带来了更多新特性。不仅正式支持了 Spring Boot 3 版本，也同时做出了包括历史功能演进在内的一系列调整优化，使得框架自身更加易用。\n本期 SOFAChannel#35 邀请到了蚂蚁集团技术专家、SOFABoot 项目 Maintainer 胡子杰跟大家分享 《SOFABoot 4.0 — 迈向 JDK 17 新时代》。\n直播介绍 《SOFABoot 4.0—迈向 JDK 17 新时代》\n2023 年 9 月 7 日（周四）\n19：00 - 20：00\n「嘉宾简介」\n胡子杰（*花名：致节*）\n蚂蚁集团技术专家\nSOFABoot Maintainer\n「议题简介」\n本次分享将主要介绍 SOFABoot 4.0 新版本引入的新特性与变化，包括其设计理念与实现方式。再者就是介绍 SOFABoot 3 应用如何升级至 SOFABoot 4.0 版本，并展望 SOFABoot 未来的发展趋势。\n「听众收获」\n SOFABoot 4.0 的新特性与变化； 已有应用如何升级至 SOFABoot 4.0 版本； 一起探讨 SOFABoot 未来发展的趋势。 直播回放 点击查看\n了解更多技术干货 使用钉钉搜索群号：44858463 ，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1693465200,"description":"SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》","dir":"activities/sofa-channel-35/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"94eeffb4d40ce60a8be76d1892342c40","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-35/","publishdate":"2023-08-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-35/","summary":"概要 活动主题：SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区 活动时间：09 月 07 日，周四晚 19 点 活动","tags":["SOFAChannel"],"title":"SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-35/","wordcount":704},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题：Layotto 社区会议\n时间：08 月 30 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+057128095818（中国大陆）+02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/Wv0wyrJyDhA\n议题：\n Layotto 项目规划和展望 #976\n 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959\n Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\n Develop a new component for sms API；为“短信 API” 开发新的组件 #830\n 「*Layotto*」：https://github.com/mosn/layotto/issues/983\nSOFA 社区会议回顾 SOFAServerless：\n主题：SOFAServerless 社区会议\n时间：08 月 21 日 19:30 - 20:30\n会议内容：\n 8月回顾\n Arklet 待完成的动作\n 增加影响基座健康状态的能力，查询健康状态指令\n 健康状态检查方案 review\n 模块安装支持远程协议\n 修复 ModuleController 使用 Arklet 遇到的问题 #17\n 增加锁控制 #39\n 基座引用的 starter，支持 Spring Boot、SOFABoot，推到 Maven 中央仓库\n 9 月迭代规划讨论\n 支持中间件列表与优先级\n 支持 SOFABoot 4.0\n 回滚，先扩后缩，模块流量 Service\n Arkctl Arklet ModuleController 0.5 发版本\n 「*SOFAServerless*」：https://github.com/sofastack/sofa-serverless/issues/38\n「*会议回放*」：https://www.bilibili.com/video/BV19r4y1R761\nLayotto：\n主题：Layotto 社区会议\n时间：08 月 23 日 14:00 - 15:00\n会议内容：\n Layotto 社区下半年规划\n 开源之夏\n 自定义插件：等待同步动作\n 集成 K8s\n 此前遗留问题的讨论、动态配置的思路\n 在 K8s 上已跑通的 demo 分享\n 短信 API\n API 已完成，关闭 issue，将跟进开发各自组件\n 「*Layotto*」：https://github.com/mosn/layotto/issues/983\n「*会议回放*」：https://www.bilibili.com/video/BV15j411q7As\nSOFAStack 社区本周贡献 本周推荐阅读 蚂蚁 SOFAServerless 微服务新架构的探索与实践\n超越边界：FaaS 的应用实践和未来展望\nMoE 系列（七）｜ Envoy Go 扩展之沙箱安全\nSeata-DTX｜分布式事务金融场景案例介绍\n","date":1692946800,"description":"SOFAServerless 社区会议回顾、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-20230825/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"25a1f7a1856d6b2d7c1f7c87dd47da64","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230825/","publishdate":"2023-08-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230825/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议回顾、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230825/","wordcount":1130},{"author":null,"categories":"SOFAStack","content":" 作者简介 赵真灵（有济）\n蚂蚁集团技术专家，Serverless 和微服务领域专家\n曾负责基于 K8s Deployment 的应用发布运维平台建设、K8s 集群的 Node/pod 多级弹性伸缩与产品建设。当前主要负责应用架构演进和 Serverless 相关工作。同时也是 SOFAArk 社区的开发和维护者以及 KNative 社区的贡献者。\n本文 3612 字，预计阅读 12 分钟\n传统微服务架构面临的问题和挑战？ 应用架构从单体应用发展到微服务，结合软件工程从瀑布模式到当前的 DevOps 模式的发展，解决了可扩展、分布式、分工协作等问题，为企业提供较好的敏捷性与执行效率，给企业带来了明显的价值。但该模式发展至今，虽然解决了一些问题，也有微服务自身的问题慢慢暴露出来，在当前已经得到持续关注：\n1、业务开发者需要感知复杂的基础设施，启动慢（*分钟级*），研发效率低，运维负担重：\n对于基础设施的问题，在服务网格和应用运行时的工作已经取得了一定的成果，但是基础设施到业务开发之间还存在业务通用的部分，这里当前没有一个模式来给予支持。\n当前已经有一些开源项目在尝试解决基础设施的问题，例如服务网格、应用运行时，如 Dapr/Layotto，也都在实际应用中得到了不错的效果。但当前服务网格和应用运行时更多的是将中间件以下下沉到 sidecar，而一个应用一般还包括通用的业务逻辑部分，要让更广泛的业务也能享受到无基础设施的体感，也需要让业务以下（*可以把业务层以下的看作基础设施*）都能屏蔽。另外当前对于中小企业来说，使用服务网格和应用运行时的成本还是比较高的。\n2、拆分微服务的资源与维护成本高：\n拆分后每个子应用都包含公共部分（*框架、中间件等*），除了同样存在上述第一个问题之外，还需要独占机器资源成本高，如果部分业务萎缩，会面临长尾应用问题，需要承担长期维护的成本。\n3、拆分微服务的敏捷度与业务、组织发展的敏捷度不一致，导致如何合理地拆分微服务始终是个老大难的问题：\n 拆得多增加了资源和管理成本； 拆得不够造成协作效率问题。有些是应该拆但没拆，有些是因为业务领域已经较为细分不便再拆，特别在一些中小企业里，可能都没有微服务的配套设施。 蚂蚁的解决思路和方案 为了解决这些问题，我们对应用同时做了横向和纵向的拆分。纵向拆分：把应用拆分成基座和模块两层，这两层分别对应两层的组织分工。基座小组与传统应用一样，负责机器维护、通用逻辑沉淀、模块架构治理，并为模块提供运行资源和环境。模块在业务层以下所有的基础设施、应用框架、中间件可以不再关注，聚焦在业务逻辑研发本身；并且采用 jar 包的研发模式，具备秒级的验证能力，让模块开发得到极致的提效。\n这可以理解为这套架构的核心模型，核心的能力有两个：平台化 + 模块化。模块化是 20 年前 OSGI 就已经提出的概念，从 OSGI 到 JPMS 一直未被抛弃，到最近 Spring Modulith、Service Weaver 等行业里又兴起一些开源框架，它一直在发展；平台化从 2017 年出现在技术雷达到 2023 年被 Gartner 列为十大战略趋势之一，到现在国内的平台工程，不断得到重视和发展。而我们实际上在行业还没有对这两个技术方向充分关注的情况下，就在尝试把他们结合起来，并在蚂蚁内部得到规模化验证和落地，给业务带来极致的降本增效效果。\n该模式的另一个特点是可演进、可回滚。这里的模块随着业务发展壮大，可以独立部署成微服务；如果微服务拆分过多，可以低成本改造成模块，合并部署在一起，解决资源成本和长期维护成本。实际上可以理解为我们是在单体应用架构和传统微服务架构中间，增加了一个可以演进过渡的架构。\n总结下来这套新微服务架构可以解决这四个问题：\n1、横向拆分出基座屏蔽业务以下的基础设施、框架、中间件和业务通用逻辑等部分，从而极大降低了业务开发者的认知负荷、提高了开发效率。\n2、一个应用可以低成本改造或拆分出多个模块，模块间可以并行独立迭代，从而解决了多人协作阻塞问题，每个模块不单独占用机器资源，没有拆分的机器成本问题。\n3、存量微服务如果拆分过多，可以低成本改造成模块应用，合并部署在一起，解决拆分过多带来的资源成本和维护成本痛点。\n4、模块可以灵活部署，解决微服务拆分与组织发展灵敏度不一致导致的协作低效与分工不合理问题。应用拆分出多个模块，可以部署在一起，也可以进一步演进成独立微服务，同样如果微服务拆分过多，也可以低成本改回模块合并部署到一起。\n这里卖个关子——为什么这些技术在蚂蚁能规模化落地？存量的业务 owner 在业务迭代进度和升级新架构之间做权衡时，我们做了哪些工作？ 欢迎来到 9 月 3 号 QCon 大会现场获得更详细的信息。\n在采用新的微服务架构模式后的成果 举个当前蚂蚁实际业务采用新模式前后的对比数据：\n可以看到这些数据是十倍级以上的提升，当前蚂蚁所有 BU 都已经接入，将近 40W core 的在线业务，并为两种业务模式：中台模式和轻应用模式的业务都提供秒级研发运维的能力。一个基座上面最多有上百个模块，一个开发同学在研发验证阶段，一下午可以验证上百次，需求的交付效率最快可以到小时级别。\n在当下行情下，新技术落地的挑战与蚂蚁的思路 当前行情下，企业对新技术会更加谨慎，技术人也对新技术采取保守态度。新技术虽然很酷，但投入大落地场景有限。这其实是发展过程的转换，在高速发展的行情下，一方面是历史包袱少，另一方面是乐观态度占据主导，更加相信新技术能较快得到规模化落地，整个社会都对新技术充满热情。而在当下阶段，很多企业已经有一定的历史包袱，时间证明新技术规模化落地需要很长的周期，需要整个体系一起演进才可能达到最初的预想，可能也会带来越来越繁复的基础设施，所以当前行业对新技术更加偏保守也是非常合理的。\n所以蚂蚁在建设这套微服务新架构时，有一个非常关键的设计思路，那就是要接地气或者是可演进，也即是要让存量业务能低成本接入。这也是最初蚂蚁在落地该模式时踩过的最大的坑：一个普通应用转换成基座需要花费上月时间（*包括流量迁移*），模块研发与现有基础设施不匹配导致模块研发成本也很高，这个问题在当时也影响了该模式的生死存亡。后来蚂蚁在这块上投入了很大精力，最终让普通应用在小时内可以成为基座或模块，研发模式也与普通应用基本一致。\n经过这个过程，最终低成本、可演进也成为了该模式的一个核心优势。未来对外开源，我们会把接地气做得更加彻底，不对企业的基础设施程度有预设条件：\n 无需容器化也可以接入； 无需使用 K8s 平台也可接入； 无需具备微服务配套设施可也接入； 无需服务网格化也可接入。 微服务新架构落地实战中遇到的更具体的困难和挑战 我们做的这套模式在行业内没有先例，相当于是在无人区里摸索，因此面临多方面的挑战：\n1、关于模块化技术的质疑：为什么现在模块化技术又开始被关注？为什么我们基于 SOFAArk 的模块化技术能推广？挑战主要集中在如何制定合理的隔离和共享通信策略，我们需要避免 OSGI 之类的复杂度问题，做到可以低成本使用。\n2、模块化技术采用了多 ClassLoader，对于 ClassLoader 的隔离、卸载不干净等问题，我们一步一个脚印，深入并体系化 …","date":1692687600,"description":"蚂蚁 SOFAServerless 微服务新架构的探索与实践","dir":"blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b76d3b366c9f1902b9a16c8792999967","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","publishdate":"2023-08-22T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","summary":"作者简介 赵真灵（有济） 蚂蚁集团技术专家，Serverless 和微服务领域专家 曾负责基于 K8s Deployment 的应用发布运维平台建设、K8s 集群的 Node/pod 多级弹性伸缩","tags":["SOFAStack"],"title":"蚂蚁 SOFAServerless 微服务新架构的探索与实践","type":"blog","url":"/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","wordcount":4058},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题： Layotto 社区会议\n时间： 08 月 23 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入：+057128095818（中国大陆）+02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/KPX3eRflTbk\n议题：\nLayotto 项目规划和展望 #976\n2023 开源之夏-课题汇总 #894\nOSPP | Layotto 支持 Pluggable Component 组件 #959\nSupport Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\nDevelop a new component for sms API；为“短信 API”开发新的组件 #830\nDiscuss: whether the sms API definition needs to be modified；讨论一下是否需要修改 sms API 定义 #966\n「Layotto」：https://github.com/mosn/layotto/issues/981\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：8 月 16 日 14:00 - 15:00\n会议内容：\nLayotto 公有云部署想法、下半年产品演进路线讨论分析；\n开源之夏进展同步：\n可插拔插件初步方案的讨论；\nK8s 集成注入位置确认、Dapr 注入的实现方案讨论；\n短信 API 适应不同场景的设计方案\n「Layotto」：https://github.com/mosn/layotto/issues/981\n「会议回放」：https://www.bilibili.com/video/BV1wX4y1E7KQ/\nSOFAStack 社区本周贡献 本周推荐阅读 超越边界：FaaS 的应用实践和未来展望\nMoE 系列（七）｜ Envoy Go 扩展之沙箱安全\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\nSeata-DTX｜分布式事务金融场景案例介绍\n","date":1692342000,"description":"SOFA Weekly｜Layotto 社区会议回顾与预告、SOFA 茶水间、社区本周贡献","dir":"blog/sofa-weekly-20230818/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f1f84d7ed240f62b5ec5da285c349dd4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230818/","publishdate":"2023-08-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230818/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜Layotto 社区会议回顾与预告、SOFA 茶水间、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230818/","wordcount":828},{"author":null,"categories":"SOFAStack","content":" 作者简介 邢奇（薯片）\n蚂蚁集团技术专家，云原生和 Service Mesh 领域专家\n长期从事服务治理和服务发现等相关领域的研究和实践，在 RPC 框架（*Dubbo、Spring Cloud 和 SOFARPC 等*）方面有源码级的研究和贡献；在 Service Mesh、云原生、容器和 K8s 等方面有深入的研究和实践经验。\n参与了多个开源项目的贡献，包括 MOSN、SOFA、Dubbo 和 Nacos 等。目前担任蚂蚁云开发技术负责人，负责支付宝云开发产品的研发和实践。\n本文 5689 字，预计阅读 16 分钟\n概述 什么是 FaaS ？\n在 ChatGPT 里面输入 FaaS 关键字，得到的结果是：*FaaS 是一种云计算服务模型*。它允许开发者编写和部署函数，而不需要管理底层基础设施的运行，即 Function as a Service。\n同时通过 ChatGPT 可以生成对应的函数代码——\nFaaS 的崛起 FaaS 的理念和函数研发模式，为传统的应用模式解决了许多问题，有着超前的优势。\n传统应用模式的困境 在研发态，不管是单体应用还是微服务应用，亦或是 Mesh 架构或者应用运行时，在研发态，开发者除了要关注业务逻辑本身之外，经常会被中间件所打扰，需要配合去做 SDK 升级改造，性能或者功能优化等。同时在使用云产品或者云服务的时候，需要被迫去感知多云的差异。\n在运维态，开发者面临着更重的运维压力。当一个应用上线，开发者需要对这个业务的未来发展进行一个复杂且不确定的容量评估，再去为这个容量去申请对应的资源，最后经过一个复杂的上线流程进行发布。在发布结束之后，开发者还得时刻关注线上流量的变化，去进行不断的扩容和缩容的调整。\n总而言之，整个中间件和基础设施对开发者的打扰是非常严重的：\n 应用研发模式的代码耦合严重，复杂度高； 运维流程繁琐，效率低； 容量评估一般很难符合真实情况，线上的资源利用率一般都较低，存在着浪费。 于是 FaaS 函数的研发模式应运而生。\n可以很直观地看到，在传统应用和微服务应用的改造和优化的基础之上，FaaS 希望做得更进一步，更面向未来。以函数为编程对象，用户无需关注应用、机器等数据和基础设施信息。\n通过这样的改变，大大提升研发效能，做到快速开发；并且提高运维效率，提供一站式免运维的 Serverless 平台；最后，函数会随着流量进行创建和销毁，最终降低成本和资源的消耗。\nFaaS 使用场景 尽管 FaaS 具有许多优势，但并非所有场景都适合采用函数编程模式。下面介绍一些 FaaS 适用的普遍场景：\n1、BFF 的场景。 即一些胶水代码（*对接多个接口、进行数据的组装和适配等*）。胶水代码的逻辑相对简单，但同时需求变化快、生命周期短。对应的应用场景如运营/营销活动等。活动结束之后，就不再有流量进入，也没有必要再进行代码和机器的维护。\n2、事件驱动的场景。 例如音视频转码，用户上传文件触发任务，或者通过消息触发调度，或者业务上有明显的波峰和波峰的流量特征。\n3、中台型业务。 例如算法平台的算子。算子计算是非常独立的业务逻辑，但是参与的研发人数非常多，逻辑相对来说不可控，需要有更高的隔离能力。\nFaaS 落地面临的技术问题 FaaS 技术产品的落地，可能会面临以下问题和挑战：\n性能问题：\n1、在传统的微服务架构下，开发者会为 RPC 调用性能进行了大量的优化；在 FaaS 的场景，也需要保证函数调用的性能。\n2、弹性扩缩容的反应时效性。很多 FaaS 产品会采用弹性的模型去采集 CPU、QPS 并发等指标，再通过平台去计算指标，进而进行一些扩容和缩容的操作，时效性很低。\n3、函数启动的速度。函数启动的速度在 FaaS 场景中至关重要，函数容器的创建和启动不仅仅是发布态的事情，而是一个数据面流量的依赖。\n安全问题：\n1、想要充分地利用计算资源以降低成本，其必要的前提就是有效地利用和隔离资源。\n2、代码容器。用户的函数代码跑在容器里面，防止容器逃逸就是重中之重。\n3、相较传统的编程模型而言，FaaS 的编程模型到底是如何屏蔽中间件以及云服务的干扰的呢？\n蚂蚁 FaaS 技术架构 蚂蚁在 FaaS 实践之初设定了 3 个 FaaS 技术架构实践的基本原则。\n原则 1：流量模型。 蚂蚁的函数容器是随着流量进行创建和销毁的，而不是通过指标数据进行分析的弹性模型。\n原则 2：函数冷启动。 尽管有 Warm Pool 或者 cache 技术可作选择，但为了最大程度降低成本和利用资源，蚂蚁将目标定为 100ms 以内的极致的冷启动。\n原则 3：安全隔离。 用户的函数都跑在我们的容器里面，因此必须保证高水位的安全隔离特性。\n其实，蚂蚁在实践 FaaS 技术架构时，有一个总的原则就是 one request per instance—极致的情况下，是创建一个函数容器去处理一个请求，类似编程模型创建一个线程去处理一个请求。在这里，创建函数容器就相当于创建一个线程，具有相似的快速、消耗低的优点，同时还有线程所不具备的安全隔离特性。\n架构说明 组件介绍和功能说明 函数网关：负责对函数请求进行转发和控制，并为每一个请求发起一次容器调度任务。\n容器调度引擎：负责对容器进行调度，维护容器的整个生命周期，并且可以对函数容器进行并发度和复用等状态控制，同时也负责管理整个集群的函数 Pod 资源池。（函数 Pod 资源池是函数容器运行的一个环境，一个集群内会有 N 多个 Pod 资源池。 ）\n函数运行时：函数运行时是 OCI 标准的实现，它负责快速地启动函数容器，并对容器的 runtime 进行有效的控制。\n函数容器：函数容器可以理解为是函数运行时+runtime+用户代码的一个运行态，用户的函数代码就跑在函数容器中。\n数据面流量和调度流程说明 从上图可以看到，所有请求都会通过函数网关进入到函数集群，函数网关会发起一次调度任务：通过容器调度引擎 Scheduler 为这一请求快速分配一个 Pod 资源。然后网关就会把这个流量转发给这个 Pod 资源里面的节点网关，节点网关随即缓存对应的请求，并且等待函数容器启动。同时函数节点调度器会并发地创建函数容器并且为容器挂载函数代码。函数容器在启动完成之后，就会立刻作为一个客户端去节点网关上拉取请求，然后进行业务逻辑处理。\n从上述流程中可以看到，蚂蚁 FaaS 场景中的 Serverless 有了第二层含义——no server（*没有 server*）。函数容器永远是作为一个 client 去处理请求。这样的方式从设计上就避免了对基础设施环境的依赖，同时减少了需要去打开一些网络端口、处理网络连接的损耗，也不需要像微服务应用那样去做一些 checkhealth 和 readliness 探针等之后才能进行注册，然后再进行服务发现和调用。\n性能优化实践 函数网关 FaaS 函数网关采用 Go 语言进行编写，网络编程模型是通过一个 go routine 处理一个请求的同步编程，比较符合开发者的习惯。同时由于 Go 语言良好的垃圾回收机制和 GPM 调度模型，网关也有了不错的性能。但是随着业务的不断增长，整个网关在高并发下会出现毛刺现象，P99 长尾也比 …","date":1692082800,"description":"超越边界：FaaS 的应用实践和未来展望","dir":"blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d4e9bc499a9bd2a868c56d990b3f4dc8","permalink":"https://sofastack.github.io/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","publishdate":"2023-08-15T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","summary":"作者简介 邢奇（薯片） 蚂蚁集团技术专家，云原生和 Service Mesh 领域专家 长期从事服务治理和服务发现等相关领域的研究和实践，在 RPC 框架（*Dubbo、Spri","tags":["SOFAStack"],"title":"超越边界：FaaS 的应用实践和未来展望","type":"blog","url":"/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","wordcount":6592},{"author":null,"categories":"SOFAStack","content":" Dragonfly 最新正式版本 v2.1.0 已经发布！ 感谢赵鑫鑫[1]同学帮助重构 Console 代码，并且提供全新的 Console[2]控制台方便用户可视化操作 P2P 集群。欢迎访问 d7y.io[3]网站来了解详情，下面具体介绍 v2.1.0 版本带来了哪些更新。\n功能 Console v1.0.0[4]已经发布，它是一个全新的可视化控制台，方便用户操作 P2P 集群。 新增虚拟网络拓扑探索功能，能够在 P2P 运行时探测节点之间的网络延迟，从而构建一个虚拟网络拓扑结构提供调度使用。 Manager 提供控制 Scheduler 可以提供的服务，例如在 Manager 中设置 Scheduler 不提供预热功能，那么 Scheduler 实例就会拒绝预热请求。 Dfstore 提供 GetObjectMetadatas 和 CopyObject 接口，支持 Dragonfly 作为 JuiceFS 的后端存储。 新增 Personal Access Tokens 功能，用户可以创建自己的 Personal Access Tokens 在调用 Open API 的时候鉴权使用。 Manager REST 服务提供 TLS 配置。 修复当 Dfdaemon 没有可用的 Scheduler 地址时启动失败的现象。 新增 Cluster 资源单位，Cluster 代表一个 P2P 集群，其只包含一个 Scheduler Cluster 和一个 Seed Peer Cluster，并且二者关联。 修复 Dfstore 在 Dfdaemon 并发下载时，可能导致的对象存储下载失败。 Scheduler 新增 Database 配置，并且把之前 Redis 的配置信息移入到 Database 配置中，并且兼容老版本。 在 Dfdaemon 中使用 gRPC 健康检查代替 net.Dial。 修复调度器过滤以及评估过程中 candidateParentLimit 可能影响到调度结果的问题。 修复 Scheduler 中的 Storage 在 bufferSize 为 0 的时候，导致的无法写入下载记录的问题。 日志中隐藏敏感信息，例如 Header 中的一些 Token 信息等。 Manager 中 Scheduler、Seed Peer 等资源删除过程中，不再使用软删除。 Scheduler 数据库表中新增 uk_scheduler 索引，Seed Peer 数据库表中新增 uk_seed_peer 索引。 由于初期功能设计定位不清晰的原因，删除 Security Domain 和 Security 的功能。 Manager 和 Scheduler 新增 Advertise Port 配置，方便用户配置不同的 Advertise Port。 修复 Task 注册阶段状态机状态变更错误的问题。 破坏性变更 不再提供 Scheduler Cluster 和 Seed Peer Cluster 之间 M:N 的关系。提供了 Cluster 的概念，一个 Cluster 即表示一个 P2P 集群，并且一个 Cluster 只包含一个 Scheduler Cluster 和 Seed Peer Cluster，且二者是 1:1 的关联关系。 控制台 更多的关于控制台的内容可以参考官网文档 Manager Console[5]。\nAI 基础设施 Triton Inference Server[6]使用 Dragonfly 下载模型文件，可以参考 #2185[7]。如果有对集成 Triton Inference Server 项目 Drgaonfly Repository Agent[8]感兴趣的同学，可以联系 gaius.qi@gmail.com。 TorchServer[9]使用 Dragonfly 下载模型文件，现正在开发，预计 v2.1.1 版本可以使用，项目仓库在 Dragonfly Endpoint[10]。 Fluid[11]基于 JuiceFS[12]运行时通过 Dragonfly 下载数据，正在开发，预计 v2.1.1 版本可以使用。 Dragonfly 助力火山引擎 AIGC [13]推理业务 P2P 镜像加速。 社区中已经有很多案例，基于 P2P 技术使用 Dragonfly 分发 AI 场景中的文件。在 AI 推理阶段，推理服务并发下载模型可以有效通过 Dragonfly P2P 缓解模型仓库的带宽压力，从而提高整体下载速度。在 KubeCon + CloudNativeCon + Open Source Summit China 2023[14]社区联合快手做一次分享，主题是《Dragonfly: Intro, Updates and AI Model Distribution in the Practice of Kuaishou - Wenbo Qi, Ant Group \u0026amp;amp; Zekun Liu, Kuaishou Technology》[15]，感兴趣的同学可以关注。 维护者 社区新增四位 Maintainer，希望能够帮助更多的 Contributor 参与到社区的工作中。\n 黄逸炀[16]：就职于火山引擎，主要专注于社区代码工程方面。 温满祥[17]：就职于百度，主要专注于社区代码工程方面。 Mohammed Farooq[18]：就职于 Intel，主要专注于社区代码工程方面。 许洲[19]：大连理工大学在读博士，主要专注于智能调度算法方面。 其他 版本更新包含的更多细节可以参考👇 CHANGELOG：https://github.com/dragonflyoss/Dragonfly2/blob/main/CHANGELOG.md\n相关链接 [1].Xinxin Zhao Github：\nhttps://github.com/1zhaoxinxin\n[2].Dragonfly Console Github：\nhttps://github.com/dragonflyoss/console\n[3].Dragonfly 官网： https://d7y.io\n[4].Dragonfly Console Release v1.0.0： https://github.com/dragonflyoss/console/tree/release-1.0.0\n[5].Manager Console 文档： https://d7y.io/docs/reference/manage-console\n[6].Triton Inference Server： https://github.com/triton-inference-server/server\n[7].issue #2185： https://github.com/dragonflyoss/Dragonfly2/issues/2185\n[8].Dragonfly Repository Agent Github： …","date":1691478000,"description":"Dragonfly 发布 v2.1.0 版本！","dir":"blog/dragonfly-v-2-1-0-release/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d4047f2f246c79313ab932a67dc6b444","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-v-2-1-0-release/","publishdate":"2023-08-08T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/dragonfly-v-2-1-0-release/","summary":"Dragonfly 最新正式版本 v2.1.0 已经发布！ 感谢赵鑫鑫[1]同学帮助重构 Console 代码，并且提供全新的 Console[2]控制台方便用户可视化操作 P2P 集群。欢迎访问 d7","tags":["SOFAStack"],"title":"Dragonfly 发布 v2.1.0 版本！","type":"blog","url":"/sofastack.tech/blog/dragonfly-v-2-1-0-release/","wordcount":1667},{"author":null,"categories":"SOFAStack","content":" Dragonfly 项目简介 Dragonfly 是一款基于 P2P 的镜像加速和文件分发系统。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在 AI 数据分发、文件分发、日志分发和镜像分发等领域被大规模使用。在解决大规模文件分发场景下有着无可比拟的优势。\n自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF Sandbox 级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为 Incubating 级别的托管项目。\nSOFAChannel#34 就邀请到了蚂蚁集团技术专家、Dragonfly 项目 Maintainer 戚文博跟大家分享 Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的实践。\n直播介绍 《Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的加速实践》\n2023 年 8 月 9 日（周三）\n19：00 - 20：00\n「嘉宾简介」\n戚文博（花名：百蓦）\n蚂蚁集团技术专家\nDragonfly Maintainer\n「议题简介」\n在 AI 场景下，训练和推理两个过程中，数据的传输往往是关键瓶颈之一。Dragonfly \u0026amp;amp; Nydus 作为 CNCF Incubating 项目，其利用 P2P 技术和按需加载能力，能够大幅度提升数据传输的速度和效率，从而提高 AI 计算的整体效率和性能。这使得 AI 算法的训练和推理过程中数据传输更加高效和可靠，为 AI 技术的应用提供了强有力的支撑。\n「听众收获」\n1、了解并走进 Dragonfly 项目；\n2、镜像加速领域相关技术的分享；\n3、Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的实践。\n直播预约 钉钉搜索：22880028764\n钉钉群同步直播，讲师在线答疑\nB 站直播预约 有机会获得 Dragonfly 精美贴纸～\nhttps://www.bilibili.com/opus/825142485488500792?spm_id_from=444.41.0.0\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1690959600,"description":"Dragonfly \u0026 Nydus 作为 CNCF Incubating 项目，其利用 P2P 技术和按需加载能力，能够大幅度提升数据传输的速度和效率，从而提高 AI 计算的整体效率和性能。","dir":"activities/sofa-channel-34/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0b819934f2ea5ec73a3cbc2f8470a87f","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-34/","publishdate":"2023-08-02T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-34/","summary":"Dragonfly 项目简介 Dragonfly 是一款基于 P2P 的镜像加速和文件分发系统。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在 AI 数据分发、文件分发、日志","tags":["SOFAStack"],"title":"SOFAChannel#34《Dragonfly \u0026 Nydus 在 AI 场景下的加速实践》——Dragonfly 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-34/","wordcount":663},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n*本文* 807 字 阅读 3分钟\n在本系列的第 5 篇《MoE 系列（五）｜Envoy Go 扩展之内存安全》中我们介绍了内存安全如何实现。第 6 篇《MoE 系列（六）｜ Envoy Go 扩展之并发安全》又谈到了并发场景下的内存安全。\n今天，我们来到了安全性的最后一篇：沙箱安全，也是相对来说，最简单的一篇。\n沙箱安全 所谓的沙箱安全，是为了保护 Envoy 这个宿主程序的安全，也就是说，扩展的 Go 代码运行在一个沙箱环境中，即使 Go 代码跑飞了，也不会把 Envoy 搞挂。\n具体到一个场景，也就是当我们使用 Golang 来扩展 Envoy 的时候，不用担心自己的 Go 代码写得不好，而把整个 Envoy 进程搞挂了。\n那么目前 Envoy Go 扩展的沙箱安全做到了什么程度呢？\n简单来说，目前只做到了比较浅层次的沙箱安全。不过，也是实用性比较高的一层。\n严格来说，Envoy Go 扩展加载的是可执行的机器指令，是直接交给 CPU 来运行的，并不像 Wasm 或者 Lua 一样由虚拟机来解释执行。所以，理论上来说，也没办法做到绝对的沙箱安全。\n实现机制 目前实现的沙箱安全机制，依赖的是 Go Runtime 的 recover 机制。\n具体来说，Go 扩展底层框架会自动地，或者（*代码里显示启动的协程*）依赖人工显示地，通过 defer 注入我们的恢复机制。所以，当 Go 代码发生了崩溃的时候，则会执行我们注入的恢复策略，此时的处理策略是，使用 500 错误码结束当前请求，而不会影响其他请求的执行。\n但是这里有一个不太完美的点，有一些异常是 recover 也不能恢复的，比如这几个：\nConcurrent map writes Out of memory Stack memory exhaustion Attempting to launch a nil function as a goroutine All goroutines are asleep - deadlock 好在这几个异常，都是不太容易出现的。唯一一个值得担心的是 Concurrent map writes，不熟悉 Go 的话，还是比较容易踩这个坑的。\n所以，在写 Go 扩展的时候，我们建议还是小心一些，写得不好的话，还是有可能会把 Envoy 搞挂的。\n当然，这个也不是一个很高的要求，毕竟这是 Gopher 写 Go 代码的很常见的基本要求。\n好在大多常见的异常，都是可以 recover 恢复的，这也就是为什么现在的机制，还是比较有实用性。\n未来 那么，对于 recover 恢复不了的，也是有解决的思路：\n比如 recover 恢复不了 Concurrent map writes，是因为 Runtime 认为 map 已经被写坏了，不可逆了。\n那如果我们放弃整个 runtime，重新加载 so 来重建 runtime 呢？那影响面也会小很多，至少 Envoy 还是安全的，不过实现起来还是比较地麻烦。\n眼下比较浅的安全机制，也足够解决大多数的问题了。\n了解更多…\nMOSN Star 一下🌟：\nhttps://github.com/mosn/mosn\n推荐阅读： MoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（四）｜Go 扩展的异步模式\n","date":1690873200,"description":"MoE 系列（七） - Envoy Go 扩展之沙箱安全","dir":"blog/moe-series (7) |envoy-go-extension-sandbox-security/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5f4a7e3872dbe224f8ed9d420af546dc","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","publishdate":"2023-08-01T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 *本文* 807 字 阅读 3分钟 在本","tags":["SOFAStack"],"title":"MoE 系列（七） - Envoy Go 扩展之沙箱安全","type":"blog","url":"/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","wordcount":1055},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 1313 字 阅读 4 分钟\n前一篇介绍了 Envoy Go 扩展的内存安全，相对来说，还是比较好理解的，主要是 Envoy C++ 和 Go GC 都有自己一套的内存对象的生命周期管理。这篇聊的并发安全，则是专注在并发场景下的内存安全，相对来说会复杂一些。\n并发的原因 首先，为什么会有并发呢🤔️\n本质上因为 Go 有自己的抢占式的协程调度，这是 Go 比较重的部分，也是与 Lua 这类嵌入式语言区别很大的点。\n细节的话，这里就不展开了，感兴趣的可以看这篇👉cgo 实现机制 - 从 C 调用 Go\n这里简单交代一下，因为 C 调用 Go，入口的 Go 函数的运行环境是，Goroutine 运行在 Envoy worker 线程上，但是这个时候，如果发生了网络调用这种可能导致 Goroutine 挂起的，则会导致 Envoy worker 线程被挂起。\n所以，解决思路🪄就是像 Go 扩展的异步模式[1]中的示例一样，新起一个 Goroutine，它会运行在普通的 Go 线程上。\n那么此时，对于同一个请求，则会同时有 Envoy worker 线程和 Go 线程，两个线程并发在处理这个请求，这个就是并发的来源。\n但是，我们并不希望用户操心这些细节，而是在底层提供并发安全的 API，把复杂度留在 Envoy Go 扩展的底层实现里。\n并发安全的实现 接下来，我们就针对 Goroutine 运行在普通的 Go 线程上这个并发场景，来聊一聊如何实现并发安全。\n对于 Goroutine 运行在 Envoy 线程上，因为并不存在并发冲突，这里不做介绍。\n写 header 操作 我们先聊一个简单的，比如在 Go 里面通过 header.Set 写一个请求头。\n核心思路是，是通过 dispatcher.post，将写操作当做一个事件派发给 Envoy worker 线程来执行，这样就避免了并发冲突。\n读 header 操作 读 header 则要复杂不少，因为写不需要返回值，可以异步执行，读就不行了，必须得到返回值。\n为此，我们根据 Envoy 流式的处理套路，设计了一个类似于所有权的机制。\nEnvoy 的流式处理，可以看这篇👉 搞懂 http filter 状态码[2]。\n简单来说，我们可以这么理解，当进入 decodeHeaders 的时候，header 所有权就交给 Envoy Go 的 C++ 侧了，然后，当通过 cgo 进入 Go 之后，我们会通过一个简单的状态机，标记所有权在 Go 了。\n通过这套设计/约定，就可以安全地读取 header 了，本质上，还是属于规避并发冲突。\n为什么不通过锁来解决呢？因为 Envoy 并没有对于 header 的锁机制，C++ 侧完全不会有并发冲突。\n读写 data 操作 有了这套所有权机制，data 操作就要简单很多了。\n因为 header 只有一份，并发冲突域很大，需要考虑 Go 代码与 C++ 侧的其他 filter 的竞争。\ndata 则是流式处理，我们在 C++ 侧设计了两个 buffer 对象，一个用于接受 filter manager 的流式数据，一个用于缓存交给 Go 侧的数据。\n这样的话，交给 Go 来处理的数据，Go 代码拥有完整的所有权，不需要考虑 Go 代码与 C++ 侧其他 filter 的竞争，可以安全地读写，也没有并发冲突。\n请求生命周期 另外一个很大的并发冲突，则关乎请求的生命周期，比如 Envoy 随时都有可能提前销毁请求，此时 Goroutine 还在 Go thread 上继续执行，并且随时可能读写请求数据。\n处理的思路是：\n并没有有效的办法，能够立即 kill Goroutine，所以，我们允许 Goroutine 可能在请求被销毁之后继续执行。\n但是，Goroutine 如果读写请求数据，Goroutine 会被终止，panic + recover（*recover 细节我们下一篇会介绍*）。\n那么，我们要做的就是，所有的 API 都检查当前操作的请求是否合法，这里有两个关键：\n每请求有一个内存对象，这个对象只会由 Go 来销毁，并不会在请求结束时，被 Envoy 销毁，但是这个内存对象中保存了一个 weakPtr，可以获取 C++ filter 的状态。\n通过这个机制，Go 可以安全地获取 C++ 侧的 filter，判断请求是否还在。\n同时，我们还会在 onDestroy，也就是 C++ filter 被销毁的 Hook 点；以及 Go thread 读写请求数据，这两个位置都加锁处理，以解决这两个之间的并发冲突。\n最后 对于并发冲突，其实最简单的就是，通过加锁来竞争所有权，但是 Envoy 在这块的底层设计并没有锁，因为它根本不需要锁。\n所以，基于 Envoy 的处理模型，我们设计了一套类似所有权的机制，来避免并发冲突。\n所有权的概念也受到了 Rust 的启发，只是两者工作的层次不一样，Rust 是更底层的语言层面，可以作用于语言层面，我们这里则是更上层的概念，特定于 Envoy 的处理模型，也只能作用于这一个小场景。\n但是某种程度上，解决的问题，以及其中部分思想是一样的。\n了解更多…\nMOSN Star 一下🌟：\nhttps://github.com/mosn/mosn\n参考链接 [1]Go 扩展的异步模式:\nhttps://uncledou.site/2023/moe-extend-envoy-using-golang-4/\n[2]搞懂 http filter 状态码:\nhttps://uncledou.site/2022/envoy-filter-status/\n推荐阅读 MoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（四）｜Go 扩展的异步模式\nMoE 系列（五）｜Envoy Go 扩展之内存安全\n","date":1689663600,"description":"MoE 系列（六）｜Envoy Go 扩展之并发安全","dir":"blog/moe-series（6）｜envoy-go-extensions- concurrency- security/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1689663600,"objectID":"a7747e9132ae0170156edbe2e8b8b0f2","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","publishdate":"2023-07-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 1313 字 阅读 4 分钟 前一篇介","tags":["SOFAStack"],"title":"MoE 系列（六）｜ Envoy Go 扩展之并发安全","type":"blog","url":"/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","wordcount":1822},{"author":null,"categories":"SOFAStack","content":" Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开发。\n二方库升级 SOFABoot 4.0 基于 Spring Boot 3.0 与 Spring Framework 6 构建。在 Spring Boot 3.0 与 Spring Framework 6 引入的二方库升级列表可参考文档👉 Spring Boot 3.0 Release Notes\n在 SOFABoot 4.0 引入的二方库升级列表如下：\n Spring Boot 3.0.5 Spring Cloud 4.0.0 Spring Cloud Stream 3.2.6 SOFA Common tools 2.0.0 SOFATracer 4.0.0 SOFARPC 5.10.0 FastJson 1.2.83 Guava 31.1-jre Grpc 1.51.1 Grpc common protos 2.11.0 Druid 1.2.16 ASM 9.4 Javassist 3.29.2-GA Curator 4.3.0 Dubbo 3.1.8 Nacos 2.0.3 Swagger 1.6.7 Swagger2 2.2.8 基于 Jakarta EE Spring Boot 3.0 中依赖 Jakarta EE 规范的部分已经升级到了 Jakarta EE 10 版本。例如，使用 Servlet 6.0 和 JPA 3.1 规范。因此，部分包的命名空间也进行了替换，例如你应该使用：\n✅jakarta.servlet.Filter\n而不是 javax.servlet.Filter。\n同时，如果你使用了自己的依赖提供 Jakarta EE 规范的 API，需注意进行对应的依赖升级，例如你应该使用：\n✅jakarta.servlet:jakarta.servlet-api\n而不是 javax.servlet:javax.servlet-api。\n可参考文档：Migrate to Jakarta EE 9 来修改 Jakarta 相关的包名以及依赖。\n支持 SOFAArk 2.0 SOFAArk 2.0 模式是 SOFAArk 框架的整体优化版本，相较于 SOFAArk 1.0 模式，它的整体优化思路和原则是 Ark Master Biz 保持和原生 SOFABoot 保持一致，弱化复杂的 Ark Plugin 类管控机制，将 Ark Plugin 与 Master Biz 合并。使得 Ark Master Biz 和原生 SOFABoot 应用的启动方式、类加载方式保持一致，大大降低了 Master Biz 应用的编程难度。\nSOFABoot 4.0 版本不再支持 SOFAArk 1.0 模式，如果你想要在 SOFABoot 应用中使用 SOFAArk 2.0 模式，可以按照以下步骤进行操作：\n1、在项目中引入 SOFAArk 组件依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;ark-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2、添加 Spring Boot 的 Package 插件\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 3、启动应用\n 方式一： IDEA 启动，注意需要添加启动参数：-Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二： 命令行启动，先运行 mvn clean package 命令进行打包，生成 ${bizName}-${bizVersion}-ark-biz.jar 的可执行文件，然后在终端运行以下启动参数：\njava -jar -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName} ${bizName}-${bizVersion}-ark-biz.jar\n支持场景化的按配置加载能力 通常情况下，应用在不同的场景下可能需要开启或者关闭不同的功能，Spring Boot 提供了丰富的 Configuration 动态配置能力[4] 能力以支持应用在不同的场景下加载不同的 Bean。\nSOFABoot 在此基础上，对 org.springframework.context.ApplicationContextInitializer 等扩展点进行了增强，支持通过统一风格的配置定制各类 Bean 以及扩展点的开启与关闭，并提供了定制模版配置的开启方式以降低应用配置项的复杂度。\n 通过： com.alipay.sofa.boot.autoconfigure.condition.ConditionalOnSwitch 注解为 Bean 添加按配置开启能力：\n@Configuration(proxyBeanMethods = false) @ConditionalOnSwitch(id=\u0026amp;quot;sample\u0026amp;quot;) public class SampleConfiguration { @Bean public SampleBean sampleBean() { return new SampleBean(); } } 添加：\nsofa.boot.switch.bean.sample.enabled=false 配置后，SampleConfiguration 配置类将不再加载。\n 通过继承： …","date":1689058800,"description":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","dir":"blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2a9d6f15f257293795df8dec9fbc5130","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","publishdate":"2023-07-11T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","summary":"Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开","tags":["SOFAStak"],"title":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","type":"blog","url":"/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","wordcount":3757},{"author":null,"categories":"SOFAStack","content":" 文｜魏陈豪（花名：无陈 Sam)\n蚂蚁集团 SOFAStack 产品专家\n本文 2966 字 阅读 8 分钟\n序言 今天给大家带来一篇 Seata-DTX[1] 商业版分布式事务在金融行业如何保证事务一致性的实践介绍。从一个全局视角出发看看一致性的保证、分别有哪些节点，事务组件在其中处在一个什么位置、担任什么工作。\n分布式系统下的事务问题阐述 云原生应用以分布式系统为主，应用会被切分到多个分布式的微服务系统下。拆分一般分为水平拆分和垂直拆分，这并不仅仅单指对数据库或者缓存的拆分，主要是表达一种分而治之的思想和逻辑。\n分布式系统的底层无法逃离“CAP 的不可能三角”*（C: Consistency，一致性；A: Availability，可用性；P: Partition Tolerance，分区容忍性）*。CAP 原理证明，任何分布式系统只可同时满足以上两点，无法三者兼顾。而分布式的服务化系统都需要满足分区容忍性，那么必须在一致性和可用性之间进行权衡。\n如果网络发生异常情况，导致分布式系统中部分节点之间的网络延迟不断增大，可能会导致分布式系统出现网络分区。复制操作可能会被延后，如果这时我们的使用方等待复制完成再返回，则可能导致在有限时间内无法返回，就失去了可用性；如果使用方不等待复制完成，而在主分片写完后直接返回，则具有了可用性，但是失去了一致性。\n图 1 CAP 理论\n图片出处：https://lushunjian.github.io/blog/2018/06/20/CAP%E7%90%86%E8%AE%BA/\n金融机构对一致性的诉求 对金融机构而言，架构层面的高可用和业务层面的强一致性，几乎同样重要。这就需要金融级云原生能够很好地平衡“CAP 的不可能三角”，需要尽可能兼顾业务强一致与系统高可用。\n但是“一致性挑战”在分布式系统中绝不仅仅是一个数据库问题，而是一个大的话题。其涵盖分布式系统的各个层面：事务一致性、节点一致性、系统间业务一致性、消息幂等一致性、缓存一致性、跨 IDC 一致性等等。所以也需要云原生架构有一系列技术能够应对金融级对一致性的严苛挑战。\n一致性控制的几个重要维度 这里挑选几个常见的金融场景下需要解决的一致性维度进行阐述。\n事务级：事务级别的一致性控制需要根据不同的金融场景选择合适的分布式事务模式。在我们针对 Seata-DTX 的客户进行调研后，发现大多数客户在平衡成本和性能后，基于 SAGA 和 TCC 是目前金融机构比较常用的两种分布式事务模式。SAGA 模式对应用实现侵入性更小，但基于补偿事务来保障一致性的设计、前后步骤执行过程中不保证事务隔离性；而 TCC 模式能做到比较好的事务隔离性，但需要应用层感知更多的复杂度。\n对于事务流程中部分不需要同步返回结果的节点，为提高执行效率可采用异步消息队列实现，对于一些事务流程较长的场景可明显降低事务实现复杂度、削峰填谷。典型场景如客户购买理财场景简化分为存款账户扣款和理财账户入账两个步骤，若选用 SAGA 模式，存款账户成功扣款后、理财账户入账失败，客户会看到“钱已付、货没到”的中间异常状态，需要系统进行冲正存款账户扣款来保障事务一致性。如选用 TCC 模式，先后完成存款账户扣款、理财账户入账的逻辑处理，各自需要存款系统和理财系统记录逻辑处理的状态，二者均成功后再发起统一提交。\n数据库级：接下来是数据库层面，金融场景下对于数据不丢有着极致的要求：一方面需要在同城、异地多个机房保存多个副本，另一方面需要在多个副本之间实现数据同步，Seata-DTX 的高可用也是依赖数据库之间的数据同步进行保障的。整体作用是以防一个 Seata-DTX 事务集群宕机后，切换到另外一套 Seata-DTX 事务集群后，可以恢复到正在进行中的事务记录，保障同城分布式事务的 RPO 为零、异地 RPO 接近零。数据库同步中，如果使用的是分布式事务库，分布式数据库一般通过对 Paxos 的支持来实现跨多服务器，甚至跨多中心的数据一致性保证。\n机房级：跨机房的路由能力、异常事务的跨机房恢复能力。发生机房故障时，数据库需要能够切到同城/异地的副本、并保障 RPO 为零，配合应用层的交易路由切换，完成机房级容灾切换、恢复业务。期间因机房故障导致的部分交易事务流程中断，分布式事务组件需要具备自动恢复能力，重新启动中断的事务流程按事先设定的业务规则向前完成或向后冲正。\n真实金融客户案例 以某资产规模超过 2 万亿元的省级农信为例，来看一下在核心整体下移的过程中，如何使用事务、配合数据库，机房容灾进行一致性控制。\n首先介绍一下整体的业务架构，在新核心平台中，大致可以分为产品服务层、交易中心层、交易中台层，如图 1 所示。交易中心收口所有的交易流程，对产品服务提供交易能力。最下面是交易原子能力层，主要包含 8 个中台，中台不直接对上提供服务，由交易中心统一处理。整个交易中心的能力，都基于服务编排构建，在编排流程中使用 SAGA 事务进行流程一致性控制。\n图 2 分布式新核心下移平台分层架构\n以贷款产品为例：整体的贷款支取、还款等长流程在信贷产品系统中，由 SAGA 事务进行串联，核心的资金交换部分由 TCC 事务把控一致性，做到对整体长流程里多个应用实现较小的侵入性。但基于补偿事务来保障一致性的设计、前后步骤执行过程中不保证事务隔离性，因此用 TCC 模式来处理对隔离性有较强诉求的核心资金交换服务，如图 3 所示。\n图 3 核心下移智能贷款系统流程\n如下图 4 是上述图 3 信贷产品中的还贷流程 TCC 流程示例。启动 TCC 事务后，使用 try 先尝试锁定客户账户余额，锁定成功后，等待二阶段提交。尝试 try 换贷款利息，锁定成功。整体提交事务，进行二阶段的扣账 confirm，以及还利息 confirm。\n图 4 核心下移智能贷款 TCC 流程\n事务层面的一致性进行了保证后，针对客户的 2 地机房进行事务的高可用部署，如图 5 所示。\n图 5 金融级云原生分布式事务部署架构\nConsole 是分布式事务的配置控制台，用户访问时通过 VIP 路由到不同机房的 console，数据写入到主 DB，主备 DB 数据实时同步。\nSeata-DTX Server 为分布式事务异库模式下的事务控制器和事务恢复器。其主要是记录事务日志，发起二阶段调用以及异常事务的恢复任务。\n业务应用用过 VIP 获取 Seata-DTX Server 对应的 IP。事务发起方发起事务时，事务日志都写入到主 DB 中，数据同步到备 DB。\n当福州 IDC 宕机或者断电时，流量会全部路由到上海 IDC。备数据库中因为有主 DB 的所有事务记录，当控制台查看事务数据和发起恢复事务任务时，仍然能正常执行。（当然可能会有人问这个情况下会不会频繁出现跨机房的分布式事务影响性能，此处负载均衡会基于入口流量的单元信息，自动调拨流量到对应的机房。此处不过多进行阐述。）\n综上可以看出，当前 Seata-DTX 的架构设计中，不单单是在事务层面去控制一致性。当有多个地域，多个副本时，可能需要结合数据库保证事务数据的一致。在多机房的情况下，需要依赖容灾能力，保证交易事务的流程可恢复。 …","date":1687849200,"description":"Seata-DTX｜分布式事务金融场景案例介绍","dir":"blog/seata-dtx｜distributed-transaction-financial-scenario-case-introduction/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1687849200,"objectID":"352eb80ff974af35f8069ba6c958fede","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","publishdate":"2023-06-27T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","summary":"文｜魏陈豪（花名：无陈 Sam) 蚂蚁集团 SOFAStack 产品专家 本文 2966 字 阅读 8 分钟 序言 今天给大家带来一篇 Seata-DTX[1] 商业版分布式事务在金融行业如何保证事务一致性的实践介绍。","tags":["SOFAStack"],"title":"Seata-DTX｜分布式事务金融场景案例介绍","type":"blog","url":"/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","wordcount":2760},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nLayotto：\n主题： Layotto 社区会议\n时间： 06 月 28 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入： +862162681677（中国大陆）+8657128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/NhOf1RUNqwL\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components #888 Support Pod injection to deploy Layotto as a sidecar in Kubernetes #910 Develop a new component for Encryption API #952 「Layotto」：https://github.com/mosn/layotto/issues/953\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 21 日 14:00 - 15:00\n会议内容：\n 本次社区会议预告开源之夏课题审核通过，等待 6 月 26 日 公示； 为 Configure API 开发 Nacos 组件问题，目前已经进入解决的最后阶段； 支持 Pluggable Components 及关于支持 Pod 注入，目前皆已审核通过，等待公示； 新增 Develop a new component for Encryption API 组件，相关任务已发布至社区群，感兴趣同学可留言加入其中。 「Layotto」：https://github.com/mosn/layotto/issues/953\n「会议回放」：https://www.bilibili.com/video/BV1kX4y1i75R/?spm_id_from=333.337.search-card.all.click\u0026amp;amp;vd_source=5dab7f4bd190defb59dcf6e727539b24\nSOFAStack 社区本周贡献\n本周推荐阅读\nSOFAStack 的下一个五年\nMOSN 反向通道详解\nSeata Saga 模式快速入门和最佳实践\n生产环境可用的 Seata-go 1.2.0 来啦！！！\n","date":1687503600,"description":"SOFA Weekly｜Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-20230623/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c0b300d2a38604aa46274b6323f27af1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230623/","publishdate":"2023-06-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230623/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230623/","wordcount":869},{"author":null,"categories":"SOFAStack","content":" 文｜宋顺（GitHub ID：nobodyiam)\nSOFAStack 社区开源负责人\n蚂蚁集团高级技术专家\n本文 3861 字 阅读 11 分钟 01 回顾开源这五年 回想起 2018 年 4 月 19 日 SOFAStack 首次开源，当时的官宣文章中就提到了我们开源的初心：\n期望通过逐步向社区开源 SOFA 中各个组件，从而一方面帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，另一方面也是期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固。\n所以这几年我们也是围绕着这个初心把 SOFAStack 体系的各个产品逐渐开源，包括首批开源的 SOFABoot、SOFARPC、SOFAArk，以及后来的 SOFARegistry、SOFAJRaft、Seata 等。同时我们也孵化了 MOSN 社区，开源了云原生网络代理 MOSN 以及应用运行时 Layotto。这些产品也是代表着 SOFAStack 在金融级云原生领域的沉淀和积累，目前已经在上百家企业中生根发芽。\n图 1 - 产品开源时间线\n我们再来看几个数字，在这 5 年中，我们举办了 18 场 Meetup，开展了 32 场直播分享，目前在 GitHub 组织层面有 438 名贡献者以及 3W 的 Star。\n图 2 - 开源 5 年的几个数字\n除了在项目上收获了不少贡献者和 Star 外，我们也逐渐地对开源有了更为深刻的认识。\n以开源指标为例，我们的初心是为了帮助更多机构和合作伙伴完成金融分布式转型，我们一开始最为关注的指标是用户数；但因开源的特殊性，我们无法直接获取实际的用户数，所以采用了 GitHub 的 Star 作为衡量指标。\n我相信这也是很多开源项目常见的第一反应，后期大家其实也发现了一些问题。举例来说，有些开源项目为了完成指标，采取了点 Star 送礼物等行为。这些虽然没有在我们的项目上发生，我们仍觉得有违开源初心，就放弃了 Star 数作为核心的指标。\n图 3 - Star 数作为衡量指标\n另一个开源项目常用的衡量指标是贡献者数量，很多开源项目是没有商业公司支撑的。为了项目的长期发展，需要持续的吸引新的贡献者加入，从而为社区带来活力。\n我们在放弃 Star 数指标后，把重心放在了贡献者数量上，会为新贡献者提供一些简单的任务，使他们能更快的融入社区，成为潜在的长期贡献者。\n不过和 Star 指标类似，在过程中我们也发现其它社区中出现了一些不好的现象。比如故意留一些明显的 bug，或者提供一些修改错别字的任务来刷贡献者数量，我们认为这些也是有违开源初心的。\n图 4 - Contributor 数作为衡量指标\n那么，我们该如何对待开源呢？\n我脑海中想起了 Envoy 作者 Matt Klein 在 Envoy 开源五周年时说的一句话：成功的开源软件就像创办一个企业。\n图 5 - 成功的开源软件就像创办一个企业\n其实开源项目和创业很类似，首先你需要有一个好的点子，然后去吸引人才一起加入来提升产品能力，再通过一些营销手段对项目做推广来获取客户，而后持续迭代改进。\n对企业而言，员工和客户固然很重要，不过我认为最核心的还是产品，只有一个定位准确、解决实际问题的产品才能受到市场欢迎，从而获取资金维持公司的运营。\n在开源项目上，用户对应着企业的客户，是提供场景的驱动力来源；贡献者对应着企业的员工，属于资源投入，是推动力来源；而产品才是真正能解决用户问题的，是整个开源飞轮中最为核心的部分。所以 Star 数和贡献者数量都只是过程指标，核心还是要提升产品力，不能本末倒置。\n图 6 - 开源飞轮\n02 展望下一个五年 聊完了过去五年的过程和收获，对 SOFAStack 而言，下一个五年的主要方向就比较明确：我们还是会着重放在产品力的提升上，希望能持续解决分布式场景中的核心问题。\n那核心问题究竟是哪些呢？我想起了泛在计算的提出者 Mark Weiser 曾经说过的一句话：最卓越的技术是那些“消失不见的”技术。\n图 7 - 消失不见的技术\n对这个判断，我也是深以为然。在日常生活中，这类案例也是比比皆是：比如电，我们现在都是即插即用，以至于已经不感知电力背后的复杂基础设施，类似的还有水、煤气等。它们背后都有着复杂的基础设施在支撑，经过了数十年的技术发展之后，已经非常稳定可靠，交互也非常简单，所以这些技术就像是“消失不见”一样。\n图 8 - 水电煤随开随用\n然而在我们实际的研发场景中，业务研发对基础设施的感知还远没有达到无感的地步。\n比如在研发态，我们除了要关注业务逻辑之外，还会经常被中间件 SDK 升级所打扰，在使用云产品时还得感知多云的差异。\n在运维态，除了要关注发布时的业务表现，还要时刻去关注资源状况。在其容量不足的时候要申请资源做扩容，在业务低峰的时候要缩容服务来节约成本。\n可以说，技术基础设施的存在感越强，研发运维的效率就越低，无法把精力集中在业务的创新上。\n图 9 - 实际研发场景\n那么，我们该如何才能让技术基础设施也消失不见呢？\n我们知道对微服务而言，可以通过服务网格来解耦业务逻辑和 RPC 通用能力，从而实现独立演进、透明升级。\n图 10 - Service Mesh 演进架构\n项目地址：https://github.com/mosn/mosn\n在实际场景中，除了微服务之外，业务往往还会使用其它的中间件能力。例如动态配置、消息、缓存、数据库等，如何降低这些中间件和业务应用的耦合是一个新的问题。另外，在多语言场景，我们仍然要为每种语言开发一套轻量 SDK 来实现通信协议和编解码逻辑，这部分也有很高的成本。所以我们如何进一步去降低多语言的支持成本是另一个亟待解决的问题。\n为此，我们也是借鉴了 Dapr 的应用运行时思路，基于 MOSN 设计开发了 Layotto，在下层对接了各种基础服务；在上层为应用提供了统一的、具备各种分布式能力的 API。\n开发者不需要再关心底层各种组件的实现差异，只需要关注应用本身需要哪些能力。比如调用 RPC、发送消息，然后通过 gRPC 调用对应的 API 即可。这样就可以彻底和底层基础服务解绑，同时也是极大地降低了多语言的支持成本。\n图 11 - Layotto 架构\n项目地址：https://github.com/mosn/layotto\n通过服务网格和应用运行时，我们解决了研发态对中间件 SDK 升级、多云差异感知等负担，我们再来看下如何通过 Serverless 技术来降低运维态的负担。\n我们知道业务研发一般是从需求到设计、开发、测试，最后发布生产的一个循环过程，其中不少业务还会出现多个迭代并行开发的场景。然而发布生产要求是串行的，就会导致迭代堵车的现象，后一个迭代必须得等前一个迭代发完才能开始发布，整体效率比较低。\n除此之外，随着业务重要性的提升，发布流程也会变重，发布周期短则几个小时，长则几天甚至几周也屡见不鲜。同时，业务逻辑的增加也会导致应用启动变慢，启动一个系统往往需要几十分钟，导致应用扩容等操作响应迟缓。\n图 12 - 研发迭代形式\n我们经过分析，发现不少应用代码本质上是可以分成两层的。一层是公共逻辑和核心模 …","date":1687244400,"description":"SOFAStack 的下一个五年","dir":"blog/the-next-five-years-of-sofastack/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"434c6a58fe31dc8becf81b773891362a","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-next-five-years-of-sofastack/","publishdate":"2023-06-20T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/the-next-five-years-of-sofastack/","summary":"文｜宋顺（GitHub ID：nobodyiam) SOFAStack 社区开源负责人 蚂蚁集团高级技术专家 本文 3861 字 阅读 11 分钟 01 回顾开源这五年 回想起 2018 年 4 月 19 日 SOFAStack 首","tags":["SOFAStack"],"title":"SOFAStack 的下一个五年","type":"blog","url":"/sofastack.tech/blog/the-next-five-years-of-sofastack/","wordcount":3990},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 21 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862162681677（中国大陆）+8657128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/f4KJsKNnxfN\n议题：\n 2023 开源之夏-课题汇总 #894 为 Configure API 开发 Nacos 组件 #921 Support Pluggable Components #888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910 「Layotto」：https://github.com/mosn/layotto/issues/949\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 14 日 14:00 - 15:00\n会议内容：\n本次社区会议预告开源之夏目前已进入社区审核阶段；关于为 Configure API 开发 Nacos 组件问题，根据社区同学在 issue 中的沟通互动，已取得新的进展；支持 Pluggable Components 目前预计已完成审核，月底会有所公示；关于支持 Pod 注入，目前已审核部分，需等待官网公示；网站钉钉群二维码已修复与更新，可正常使用。\n「Layotto」：https://github.com/mosn/layotto/issues/949\n「会议回放」：https://www.bilibili.com/video/BV1wm4y1i7hv/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFARPC 5.10.1 版本发布\n发布 SOFARPC 5.10.1 版本，主要变更如下:\n 支持修改 gRPC Message Size #1333 升级 Hessian 到 3.4.0 以支持部分 java.time 类的序列化 #1338 详细发布报告：https://github.com/sofastack/sofa-rpc/compare/v5.10.0...5.10.1\nSOFAStack 社区本周贡献\n本周推荐阅读\nSeata Saga 模式快速入门和最佳实践\n生产环境可用的 Seata-go 1.2.0 来啦\nMOSN 基于延迟负载均衡算法-走得更快，期待走得更稳\nMoE 系列（五）｜Envoy Go 扩展之内存安全\n","date":1686898800,"description":"SOFA Weekly｜SOFARPC 5.10.1 版本发布、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230616/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cda466451816463410fd13477709f561","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230616/","publishdate":"2023-06-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230616/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFARPC 5.10.1 版本发布、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230616/","wordcount":996},{"author":null,"categories":"SOFAStack","content":" 文｜王特 （花名：亦夏）\nEmail：yixia.wt@antgroup.com\n蚂蚁集团数据中间件核心开发\n本文4927 字 阅读 13 分钟\nSeata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。Seata 为用户提供了 AT、TCC、SAGA、XA 等多种事务模式，帮助解决不同业务场景下的事务一致性问题。\n本文主要介绍 Seata Saga 模式的使用以及最佳实践，围绕三个部分展开，第一部分是 Seata Saga 的简介、第二部分旨在快速介绍 Seata Saga 模式的使用方法并帮助大家入门，最后一部分将会给大家分享一些 Seata Saga 实践中的经验，帮助用户更快、更好得使用 Seata Saga 模式。\n1 Seata Saga 简介 1.1 Saga 模式 Saga 模式是分布式事务的解决方案之一，理念起源于 1987 年 Hector \u0026amp;amp; Kenneth 发表的 Sagas 论文。它将整个分布式事务流程拆分成多个阶段，每个阶段对应我们的子事务，子事务是本地事务执行的，执行完成就会真实提交。\n它是一种基于失败的设计，如上图可以看到，每个活动或者子事务流程，一般都会有对应的补偿服务。如果分布式事务发生异常的话，在 Saga 模式中，就要进行所谓的“恢复”，恢复有两种方式，逆向补偿和正向重试。比如上面的分布式事务执行到 T3 失败，逆向补偿将会依次执行对应的 C3、C2、C1 操作，取消事务活动的“影响”。那正向补偿，它是一往无前的，T3 失败了，会进行不断的重试，然后继续按照流程执行 T4、T5 等。\n根据 Saga 模式的设计，我们可以得到 Saga 事务模式的优缺点。\n优点：\n 子事务 （或流程） ，提交是本地事务级别的，没有所谓的全局锁，在长事务流程下，避免了长时间的资源锁定；另外这种流水线的处理模型天然符合阶段式信号处理模型，能发掘出更高的性能和吞吐。 正向服务和补偿服务都是交给业务开发实现的，所以 Saga 模式和底层数据库协议是无关的。XA/AT 模式可能依赖特定的数据库类型和版本，比如 MySQL 是 5.0 之后才支持的 XA，那么低版本的 MySQL 就不能适用到 XA 模式。 缺点：\n 也是因为正向服务和补偿服务都由业务开发者实现，所以业务上是有开发成本的，侵入性相对 XA/AT 打一个注解的方式会高很多。 因为一阶段子事务活动提交是本地事务级别的，所以 Saga 模式不保证隔离性。提交之后就可能“影响”其他分布式事务、或者被其他分布式事务所“影响”。例如：其他分布式事务读取到了当前未完成分布式事务中子事务的更新，导致脏读；其他分布式事务更新了当前未完成分布式事务子事务更新过的字段，导致当前事物更新丢失；还有不可重复读的场景等。 所以 Saga 模式的使用也需要考虑这些问题带来的“影响”。一般 Saga 模式的使用场景有如下几个：\n 长事务流程，业务上难以接受长时间的资源锁定，Saga 的特性使得它在长事务流程上处理非常容易； 业务性质上，业务可以接受或者解决缺乏隔离性导致的“影响”。例如部分业务只要求最终一致性，对于隔离性要求没有那么严格，其实是可以落地 Saga 模式的； 分布式事务参与者包含其他机构或者三方的服务，数据资源服务不是我们自身维护，无法提供 TCC 模式要求的几个接口。 1.2 Seata Saga 接下来我们来看看 Seata Saga 的实现。Saga 主流的实现分为两种：编排式和协调式。Seata Saga 的实现方式是编排式，是基于状态机引擎实现的。 状态机执行的最小单位是节点：节点可以表示一个服务调用，对应 Saga 事务就是子事务活动或流程，也可以配置其补偿节点，通过链路的串联，编排出一个状态机调用流程。在 Seata 里，调用流程目前使用 JSON 描述，由状态机引擎驱动执行，当异常的时候，我们也可以选择补偿策略，由 Seata 协调者端触发事务补偿。\n有没有感觉像是服务编排，区别于服务编排，Seata Saga 状态机是 Saga+服务编排，支持补偿服务，保证最终一致性。\n我们来看看一个简单的状态机流程定义：\n上方是一个 Name 为 reduceIncentoryAndBalance 的状态机描述，里面定了 ServiceTask 类型的服务调用节点以及对应的补偿节点 CompensateReduceInventory。\n看看几个基本的属性：\n Type：节点类型，Seata Saga 支持多种类型的节点。例如 ServiceTask 是服务调用节点 ServiceName/ServiceMethod：标识 ServiceTask 服务及对应方法 Input/Output：定义输入输出参数，输入输出参数取值目前使用的是 SPEL 表达式 Retry：控制重试流程 Catch/Next：用于流程控制、衔接，串联整个状态机流程 更多类型和语法可以参考 Seata 官方文档[1]，可以看到状态机 JSON 声明还是有些难度的，为了简化状态机 JSON 的编写，我们也提供了可视化的编排界面[2]，如下所示，编排了一个较为复杂的流程。\n话不多说，我们进入下面的实践环节。\n2 Seata Saga 使用入门 2.1 从 Seata 官网新人文档开始 Seata 分 TC、TM 和 RM 三个角色，TC （Server 端） 为单独服务端部署，TM 和 RM （Client 端） 由业务系统集成。\nServer 端存储模式 （store.mode） 现有 file、db、redis 三种 （后续将引入 Raft、MongoDB） ，file 模式无需改动，直接启动即可。\n 部署 Seata Server\n从新人文档，可以看出 Seata 还是传统的 CS 模型。首先我们需要部署 Seata Server 端。Server 端默认的存储模式时 file 模式，无需改动，直接执行 SpringBoot 启动类 main 方法即可启动 Seata Server。为了方便，本次演示就使用 file 模式启动，其他模式的启动方式可以参考新人文档的详细介绍。\n创建 Client 端测试应用\n同时我们需要创建一个客户端的测试应用，这里命名 seata-saga-test，测试应用使用 SpringBoot 框架，配置好 spring 的 aplication.pname 和 port，并且引入 seata-spring-boot-starter 依赖，完成 Client 端应用的搭建。\n2.2 从 Seata Saga 单元测试看起 一般了解一个框架的功能，建议是从入口的单元测试类开始看起。在 Seata 仓库中找到 Seata Saga 的 test 模块，从最外围的测试类 io.seata.saga.engine.StateMachineTests 看起 （一般开源项目最外围的测试类即是入口类） ：\n从上面的截图可以看出，入口测试方法主要分为三个部分：\n【1】处的 spring 配置文件声明了 StateMachineEngine Bean 以及对应的属性，【2】处也引用 …","date":1686726000,"description":"Seata Saga 模式快速入门和最佳实践","dir":"blog/seata-saga-model-quick-start-and-best-practices/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7287981b4eabf6ef5f22582a62cd69ff","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","publishdate":"2023-06-14T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","summary":"文｜王特 （花名：亦夏） Email：yixia.wt@antgroup.com 蚂蚁集团数据中间件核心开发 本文4927 字 阅读 13 分钟 Seata 是一款开源的","tags":["SOFAStack"],"title":"Seata Saga 模式快速入门和最佳实践","type":"blog","url":"/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","wordcount":3753},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n可信基础设施技术分论坛\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：6 月 14 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/f4KJsKNnxfN\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components#888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes#910 How to run layotto with congfig_mongo.json#932 「Layotto」：https://github.com/mosn/layotto/issues/949\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议 时间：06 月 07 日 14:00 - 15:00\n会议内容：\n本次社区会议讨论了开源之夏现阶段导师审核课题的情况，并同步最新进展情况；关于 support pluggable components 与 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes 两个课题，现阶段正常进行中，无风险存在；How to run layotto with congfig_mongo.json 的问题已经解决，具体的解决方案详情可看 issue 或 视频回放。\n「Layotto」：https://github.com/mosn/layotto/issues/937\n「会议回放」：https://www.bilibili.com/video/BV1Pu4y1f7oa/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFAStack 社区本周贡献\n","date":1686294000,"description":"SOFA Weekly｜可信基础设施技术分论坛、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230609/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c2b1e54167604c2f46d7caa6b28da98f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230609/","publishdate":"2023-06-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230609/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜可信基础设施技术分论坛、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230609/","wordcount":781},{"author":null,"categories":"SOFAStack","content":"文｜刘月财（GitHub ID：luky116)\n360 服务端开发专家\nSeata-go 项目负责人\n本文 2752 字 阅读 7 分钟\n发布概览\nSeata-go 1.2.0 版本支持 XA 模式。XA 协议是由 X/Open 组织提出的分布式事务处理规范，其优点是对业务代码无侵入。当前 Seata-go 的 XA 模式支持 MySQL 数据库。至此，Seata-go 已经集齐 AT、TCC、Saga 和 XA 四种事务模式，完成了与 Seata Java 的功能对齐。\nXA 模式的主要功能:\n 支持了 XA 数据源代理\n 支持了 XA 事务模式\n XA 相关的 Samples 可以参考示例：\nhttps://github.com/seata/seata-go-samples/tree/main/xa\n在本版本中还修复了近期大量用户在使用过程中提交的 issue。\n版本的主要更新如下\nFeature：\n[#467] 实现 XA 模式支持 MySQL\nhttps://github.com/seata/seata-go/pull/467\n[#534] 支持 Session 的负载均衡\nhttps://github.com/seata/seata-go/pull/534\nBugfix：\n[#540] 修复初始化 XA 模式的 bug\nhttps://github.com/seata/seata-go/pull/540\n[#545] 修复 XA 模式获取 db 版本号的 bug\nhttps://github.com/seata/seata-go/pull/545\n[#548] 修复启动 XA 时候会失败的 bug\nhttps://github.com/seata/seata-go/pull/548\n[#556] 修复 XA 数据源的 bug\nhttps://github.com/seata/seata-go/pull/556\n[#562] 修复提交 XA 全局事务的 bug\nhttps://github.com/seata/seata-go/pull/562\n[#564] 修复提交 XA 分支事务的 bug\nhttps://github.com/seata/seata-go/pull/564\n[#566] 修复使用 XA 数据源执行本地事务的 bug\nhttps://github.com/seata/seata-go/pull/566\nOptimize：\n[#523] 优化 CI 流程\nhttps://github.com/seata/seata-go/pull/523\n[#525] 将 Jackson 序列化重命名为 JSON\nhttps://github.com/seata/seata-go/pull/525\n[#532] 移除重复的代码\nhttps://github.com/seata/seata-go/pull/532\n[#536] 优化 go import 代码格式\nhttps://github.com/seata/seata-go/pull/536\n[#554] 优化 XA 模式的性能\nhttps://github.com/seata/seata-go/pull/554\n[#561] 优化 XA 模式的日志输出\nhttps://github.com/seata/seata-go/pull/561\nTest:\n[#535] 添加集成测试\nhttps://github.com/seata/seata-go/pull/535\nDoc:\n[#550] 添加 1.2.0 版本的改动日志\nhttps://github.com/seata/seata-go/pull/550\n英文版：https://github.com/seata/seata-go/releases/tag/v1.2.0\n致谢\n非常感谢以下 Contributors 的代码贡献。若有无意遗漏，请报告。\n@georgehao\nhttps://github.com/georgehao\n@luky116\nhttps://github.com/luky116\n@jasondeng1997\nhttps://github.com/jasondeng1997\n@106umao\nhttps://github.com/106umao\n@wang1309\nhttps://github.com/wang1309\n@iSuperCoder\nhttps://github.com/iSuperCoder\n@Charlie17Li\nhttps://github.com/Charlie17Li\n@Code-Fight\nhttps://github.com/Code-Fight\n@Kirhaku\nhttps://github.com/Kirhaku\n@Vaderkai\nhttps://github.com/VaderKai\n同时，我们收到了社区反馈的很多有价值的 issue 和建议，非常感谢大家。\n社区讨论\n加入钉钉群：\nSeata-go 社区群：33069364\nSeata-go 开发群：44816898\n未来展望\nSeata 社区近期与不少国内 Go 语言微服务框架以及 ORM 框架背后的开发社区达成合作，比如 GORM 框架，已经集成到了 Sample 中，后续会将更多的 ORM 框架集成在 Seata-go-samples 项目中。\nSeata-go-samples 集成到 Seata-go GitHub Actions 的集成测试环境，目前已经在进行中，用于测试每个 PR，保证系统的兼容性与稳定性。\nSeata-go 后续的 Saga 模式，计划采用 Temporal 框架来做服务编排，目前正在规划中，期待能给用户带来更实用便利的 Saga 使用体验。\n欢迎对开源感兴趣的朋友加入 Seata 开源建设中来。\n常用链接\nSeata：\nhttp://github.com/seata/seata\nhttps://github.com/seata/seata-php\nhttps://github.com/seata/seata-js\nhttps://github.com/seata/seata-go\nSamples：\nhttps://github.com/seata/seata-samples\nhttps://github.com/seata/seata-go-samples\n官网：\nhttps://seata.io/\n投稿\n欢迎大家将 Seata/Seata-go/Seata-php/Seata-js 相关的实践文章投稿至：https://www.yuque.com/fred-x/ngfgiz/le1h4u5kn0xyhhoh\nSeata Star 一下✨：\nhttps://github.com/seata/seata-go\n","date":1686034800,"description":"生产环境可用的 Seata-go 1.2.0 来啦！！！","dir":"blog/seata-go-1.2.0-available-for-production-environments-is-here/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7df64ba112ba3f76cfa911d05813d383","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","publishdate":"2023-06-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","summary":"文｜刘月财（GitHub ID：luky116) 360 服务端开发专家 Seata-go 项目负责人 本文 2752 字 阅读 7 分钟 发布概览 Seata-go 1.2.0 版本支持 XA 模式。XA 协议是由 X/Open 组织提","tags":["SOFAStack"],"title":"生产环境可用的 Seata-go 1.2.0 来啦！！！","type":"blog","url":"/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","wordcount":920},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区 活动时间：05 月 31 日，周三晚 19 点 活动形式：线上直播 资料下载：点击获取 B 站直播间地址：http://live.bilibili.com/21954520 B 站直播ID：21954520 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》 Occlum 是蚂蚁集团于 2019 年开源的机密计算操作系统，也是 Linux 基金会机密计算联盟官方项目，荣列 2021“科创中国”开源创新榜。2022 年 12 月 10 日，Occlum 正式发布 v1.0 版本。学术成果发表在 ASPLOS\u0026amp;rsquo;20。Occlum 可让复杂应用轻松获得机密计算能力，是目前业界最受欢迎的开源机密计算操作系统。\nSOFAChannel 第 33 期邀请到了 LibOS 项目的 Contributor 惠春阳来做分享，带大家了解机密计算，讲述 Occlum 如何借助 EDMM，获得更高的安全性、易用性和更极致的性能，成为更好的机密计算 Library OS。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 惠春阳（花名：三仟） 蚂蚁集团技术专家 Occlum 机密计算 LibOS 项目 Contributor 议程 直播回放 点击查看\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1685516400,"description":"SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区","dir":"activities/sofa-channel-33/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"eb7a144641c7fa0312314ecca5edb8cb","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-33/","publishdate":"2023-05-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-33/","summary":"概要 活动主题：SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区 活动时间：05 月 31 日","tags":["SOFAStack"],"title":"SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-33/","wordcount":642},{"author":null,"categories":"SOFAStack","content":" 前面几篇介绍了 Envoy Go 扩展的基本用法，接下来几篇将介绍实现机制和原理。\nEnvoy 是 C++ 实现的，那 Envoy Go 扩展，本质上就相当于把 Go 语言嵌入 C++ 里了。\n在 Go 圈里，将 Go 当做嵌入式语言来用的，貌似并不太多见，这里面细节还是比较多的。比如：\n Envoy 有一套自己的内存管理机制，而 Go 又是一门自带 GC 的语言。 Envoy 是基于 libevent 封装的事件驱动，而 Go 又是包含了抢占式的协程调度。 为了降低用户开发时的心智负担，我们提供了三种安全保障。有了这三层保障，用户写 Go 来扩展 Envoy 的时候，就可以像平常写 Go 代码一样简单，而不必关心这些底层细节。\n三种安全 1. 内存安全 用户通过 API 获取到的内存对象，可以当做普通的 Go 对象来使用。\n比如，通过 Headers.Get 得到的字符串，在请求结束之后还可以使用，而不用担心请求已经在 Envoy 侧结束了，导致这个字符串被提前释放了。\n2. 并发安全 当启用协程的时候，我们的 Go 代码将会运行在另外的 Go 线程上，而不是在当前的 Envoy worker 线程上，此时对于同一个请求，则存在 Envoy worker 线程和 Go 线程的并发。\n但是，用户并不需要关心这个细节，我们提供的 API 都是并发安全的，用户可以不感知并发的存在。\n3. 沙箱安全 这一条是针对宿主 Envoy 的保障，因为我们并不希望某一个 Go 扩展的异常，把整个 Envoy 进程搞崩溃。\n目前我们提供的是，Go Runtime 可以 recover 的有限沙箱安全，这通常也足够了。\n更深度的，Runtime 不能 recover 的，比如 Map 并发访问，则只能将 Go So 重载，重建整个 Go Runtime 了，这个后续也可以加上。\n内存安全实现机制 要提供安全的内存机制，最简单的办法，也是*（几乎）*唯一的办法，就是复制。但是，什么时候复制、怎么复制，还是有一些讲究的。这里权衡的目标是降低复制的开销，提升性能。\n这里讲的内存安全，还不涉及并发时的内存安全，只是 Envoy*（C++）*和 Go 这两个语言运行时之间的差异。\nPS：以前用 OpenResty 的时候，也是复制的玩法，只是有一点区别是，Lua String 的 Internal 归一化在大内存场景下，会有相对较大的开销；Go String 则没有这一层开销，只有 Memory Copy + GC 的开销。\n复制时机 首先是复制时机，我们选择了按需复制，比如 Header，Body Data 并不是一开始就复制到 Go 里面，只有在对应的 API 调用时，才会真的去 Envoy 侧获取\u0026amp;amp;复制。\n如果没有被真实需要，则并不会产生复制，这个优化对于 Header 这种常用的，效果倒是不太明显，对于 Body 这种经常不需要获取内容的，效果则会比较的明显。\n复制方式 另一个则是复制方式，比如 Header 获取上，我们采用的是在 Go 侧预先申请内存，在 C++ 侧完成赋值的方式，这样我们只需要一次内存赋值即可完成。\n这里值得一提的是，因为我们在进入 Go 的时候，已经把 Header 的大小传给了 Go，所以我们可以在 Go 侧预先分配好需要的内存。\n不过呢，这个玩法确实有点 tricky，并不是 Go 文档上注明推荐的用法，但是也确实是我们发现的最优的解法了。\n如果按照 Go 常规的玩法，我们可能需要一次半或两次内存拷贝，才能保证安全，这里有个半次的差异，就是我们下回要说的并发造成的。\n另外，在 API 实现上，我们并不是每次获取一个 Header，而是直接一次性把所有的 Header 全复制过来，在 Go 侧缓存了。这是因为大多数场景下，我们需要获取的 Header 数量会有多个，在权衡了 CGO 的调用开销和内存拷贝的开销之后，我们认为一次性全拷贝是更优的选择。\n最后 相对来说，不考虑并发的内存安全，还是比较简单的，只有复制最安全，需要权衡考虑的则更多是优化的事情了。\n比较复杂的还是并发时的安全处理，这个我们下回再聊。\nMOSN Star 一下✨： https://github.com/mosn/mosn\n推荐阅读 MoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\n[MoE 系列（四）｜Go 扩展的异步模式](\n","date":1685430000,"description":"MoE 系列（五）｜Envoy Go 扩展之内存安全","dir":"blog/moe-series (5)｜envoy-go-extensions-memory-security/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1685430000,"objectID":"f5d59dc8bad34c82fb7116161068a117","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","publishdate":"2023-05-30T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","summary":"前面几篇介绍了 Envoy Go 扩展的基本用法，接下来几篇将介绍实现机制和原理。 Envoy 是 C++ 实现的，那 Envoy Go 扩展，本质上就相当于把 Go 语言嵌入 C++ 里了。 在 Go 圈里，将 Go","tags":["SOFAStack"],"title":"MoE 系列（五）｜Envoy Go 扩展之内存安全","type":"blog","url":"/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","wordcount":1443},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAChannel#33 预告\n**Occlum 是蚂蚁集团于 2019 年开源的机密计算操作系统，也是 Linux 基金会机密计算联盟官方项目，荣列 2021“科创中国”开源创新榜。2022 年 12 月 10 日，Occlum 正式发布 v1.0 版本。学术成果发表在 ASPLOS\u0026amp;rsquo;20。Occlum 可让复杂应用轻松获得机密计算能力，是目前业界最受欢迎的开源机密计算操作系统。\nSOFAChannel 第 33 期邀请到了 LibOS 项目的 Contributor 惠春阳来做分享，带大家了解机密计算，讲述 Occlum 如何借助 EDMM，获得更高的安全性、易用性和更极致的性能，成为更好的机密计算 Library OS。\n本期为 SOFAStack 与博文视点联合举办的机密计算专题，直播中也将抽奖送出《机密计算：AI 数据安全和隐私保护》。欢迎所有对 Occlum、机密计算、TEE 感兴趣的小伙伴们一起来听直播！🧸\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 24 日 14:00 - 15:00\n会议内容：\n随着本周社区会议的召开，社区同学讨论了如何为 Configure API 开发 Nacos 组件问题。会议同步了开源之夏的学生招募进展，以及在课题沟通时推进了 Layotto 目前能够解决的问题，并进一步讨论了版本优化的方法。\n「Layotto」：https://github.com/mosn/layotto/issues/931\n「会议回放」：https://www.bilibili.com/video/BV1XM4y1v7A9/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 31 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components#888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes#910 「Layotto」：https://github.com/mosn/layotto/issues/931\nSOFAStack 社区本周贡献\n本周推荐阅读\n直播预告 | SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》\nMOSN 基于延迟负载均衡算法——走得更快，期待走得更稳\nMoE 系列（四）｜Go 扩展的异步模式\nSOFAServerless 体系助力业务极速研发\n","date":1685084400,"description":"SOFA Weekly｜SOFAChannel#33 直播预告、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230526/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6ce1b77204d6ef8dfa8d2dcae4a65d59","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230526/","publishdate":"2023-05-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230526/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAChannel#33 直播预告、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230526/","wordcount":1186},{"author":null,"categories":"SOFAStack","content":" 文｜纪卓志（GitHub ID：jizhuozhi)\n京东高级开发工程师\nMOSN 项目 Committer\n专注于云原生网关研发的相关工作，长期投入在负载均衡和流量控制领域\n前言 这篇文章主要是介绍 MOSN 在 v1.5.0 中新引入的基于延迟的负载均衡算法#2253。首先会对分布式系统中延迟出现的原因进行剖析，之后介绍 MOSN 都通过哪些方法来降低延迟，最后构建与生产环境性能分布相近的测试用例来对算法进行验证。\n在开始聊基于延迟的负载均衡算法之前，我们先介绍下什么是负载均衡。\n什么是负载均衡 Wikipedia中 Load Balancing (Computing) 词条是这样介绍负载均衡的：\n 负载均衡是将一组任务分配到一组资源（计算单元）上的过程，目的是使它们的整体处理更有效率。负载均衡可以优化响应时间，避免负载不均匀导致一些计算节点过载而其他计算节点处于空闲状态\n 负载均衡在大型分布式系统中是关键的组成部分。负载均衡解决了分布式系统中最重要的两个问题：可伸缩性*（Scalability）*和韧性*（Resilience）*。\n 可伸缩性：应用程序部署在多个相同的副本中。当计算资源不足时可以通过部署额外的副本来增加计算资源，而当计算资源大量冗余时可以通过减少副本来节省成本。通过负载均衡可以将请求负载分布到不同的副本中。\n 韧性：分布式系统的故障是部分的。应用程序通过冗余副本的方式，保证在部分组件故障时仍能正常地提供服务。负载均衡通过感知节点的故障，调整流量的分配，将流量更多的分配到那些能够正常提供服务的节点上。\n 走得更快 负载均衡使得现代软件系统具备了可扩展性和韧性。但在分布式系统中还存在不容忽视的问题：延迟。\n延迟来自哪里 现代软件系统通常是多层级结构大型分布式系统，即使是只服务单个终端用户的请求，它背后也有可能经过了上百次的数据访问，这种情况在微服务架构中更是尤为普遍。\n微服务架构（引用自 Microservices Pattern）\n单台性能稳定的服务器中延迟通常由以下几个方面造成：\n 计算任务本身的复杂度 内容的传输过程中的延迟 请求排队等待的延迟 后台任务活动所导的资源竞争 这些服务器之间的延迟将会叠加，任何显著的延迟增加都会影响终端用户的体验。此外，任何来自单个节点的延迟峰值也会直接影响到终端用户体验。同时越来越多地使用公有云部署应用程序也进一步加剧了响应时间的不可预测性。因为在这些环境中存在共享资源*（CPU、内存和 IO）*的争用，应用程序机几乎不可避免地遇到性能影响，而这种影响是随时发生的。\n如何减少延迟 有研究表明，在大型互联网应用中，延迟往往具有长尾特点，P99 比中位数高出几个数量级。如果在应用架构的每层都能够减少这些尾部延迟，那么对终端用户整体的尾部延迟将会显著降低。\n在服务网格中，所有接收和发送的流量都会经过边车代理，通过边车代理可以轻松地控制网格的流量，而无需对服务进行任何修改。如果边车代理在对应用层流量进行转发时，总是通过负载均衡时选择响应时间较短的服务器，那么将会显著降低对终端用户的尾部延迟。\n基于此，我们准备开始为 MOSN 引入基于延迟的负载均衡算法，并进行适当调整来保证能够在大多数使用场景下显著减少延迟。\n性能问题是局部的 前面提到了，每个节点的性能受到多种因素的影响，这些影响因素是动态的，难以准确预测每个节点的性能，因此我们无法精确地选择最好的节点，但是可以避免较差的节点。\n在云环境中，服务器的性能常常是难以预测的，但是我们可以通过对大量的数据进行分析，发现服务器性能的分布大多数情况下是符合正态分布的。因此，尽管有一部分的服务器在性能方面表现比较差，它们的数量通常都是少数的*（3Sigma）*，而绝大部分服务器节点的表现是正常的。\n除了服务器之间的差异，还存在由基础设施导致的动态延迟，这种延迟可能是由于网络拥塞、故障或不断增长的流量所导致。这种延迟通常具有持续性和局部性：持续性则表示延迟会长时间存在，不会在短时间内消失；而局部性指的是延迟往往只出现在某些特定服务器上，而不会在全局发生。\nPeakEWMA 面对这些问题，我们使用 Peak EWMA*（Peak Exponentially Weighted Moving Average）*计算响应时间指标，并根据这个指标来对节点进行负载均衡。\nEWMA 是一种动态权重调整算法，各数值的加权影响力随时间而指数式衰退，越近期的数据加权影响力越重，但较旧的数据也给予一定的加权值。\n它以相对较高的权重考虑了最近响应时间的影响，因此更具有针对性和时效性。加权的程度以常数 𝛼 决定，𝛼 数值介于 0 至 1，它用来控制数据加权影响力衰退的速率。\n作为一种统计学指标，EWMA 的计算过程不需要大量的采样点以及时间窗口的设定，有效地避免了计算资源的浪费，更适合在 MOSN 这样的边车代理中使用。\n由于响应时间是历史指标，当服务器出现性能问题导致长时间未返回时，负载均衡算法会错误地认为这台服务器仍是最优的，而不断地向其发送请求而导致长尾延迟增高。我们使用活跃连接数作为实时变化的指标对响应时间进行加权，表示等待所有活跃的连接都返回所需要的最大时间。\nP2C（Power of Two Choice） 在大规模集群中，如果使用遍历所有服务器选择最好的服务器的方法，虽然可以找到最轻负载的服务器来处理请求，但这种方法通常需要大量的计算资源和时间，因此无法处理大规模的请求。因此，我们使用 P2C 来选择最优节点。相比之下，P2C 算法可以在常数时间内选择两个服务器进行比较，并选择其中负载更轻的服务器来处理请求。P2C 基于概率分配，即不直接基于权重分配，而是根据每个服务器优于其他服务器的概率值来决定请求的分配。\n此外，在多个负载均衡器的情况下，不同负载均衡器可能会有不同的节点视图，这可能导致某些负载均衡器选择的最优节点总是最差的节点。这是因为负载均衡器选择最优节点时基于自己的视图信息，而节点视图随着时间的变化可能会发生变化，因此不同的负载均衡器选择的最优节点也可能不同。P2C 算法通过对随机选择的两个节点进行比较，可以使节点间的负载均衡更加均匀，即使节点视图发生变化，也能提供稳定的负载均衡效果。\n 在 MOSN 的 v1.5.0 版本中，只有节点权重相同时会使用 P2C，当权重不同时会使用 EDF 进行加权选择。后续会提供可配置的选项。\n 模拟流量验证 我们构建了与生产环境性能分布相近的测试用例来对算法进行验证。\n首先我们使用正态分布生成了 10 台服务器的基准性能，其中数学期望为 50ms，标准差为 10ms。接下来，我们将这些基准性能作为数学期望，并以标准差为 5ms 的正态分布随机生成了请求延迟，以模拟真实世界的情况。此外，我们还在其中一台服务器注入了概率为 0.1 的故障，故障发生时会产生 1000ms 的延迟，以测试系统的容错性。\n为了模拟请求倾斜时请求排队等待的延迟，我们限制了每台服务器的最大并发数为 8，当同时处理的最大请求数超过了最大并发数时，将会排队等待。这样能够更加真实地模拟出系统的运行情况。\n最后，我们使用了 Round Robin、Least Request 和 Peak EWMA 三 …","date":1684825200,"description":"MOSN 基于延迟负载均衡算法——走得更快，期待走得更稳","dir":"blog/mosn-delay-based-load-balancing-algorithm-go-faster, expect-to-go-steadier/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4ed40af7694979d98879f50bcaf9093c","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","publishdate":"2023-05-23T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","summary":"文｜纪卓志（GitHub ID：jizhuozhi) 京东高级开发工程师 MOSN 项目 Committer 专注于云原生网关研发的相关工作，长期投入在负载均衡和流量控制领域","tags":["SOFAStack"],"title":"MOSN 基于延迟负载均衡算法——走得更快，期待走得更稳","type":"blog","url":"/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","wordcount":3277},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 大事记\nQCon 是由极客邦科技旗下 InfoQ 中国主办的综合性技术盛会，每年在伦敦、北京、纽约、圣保罗、上海、旧金山召开。自 2007 年 3 月份首次举办以来，已有超万名高级技术人员参加过 QCon 大会。QCon 内容源于实践并面向社区，演讲嘉宾依据热点话题，面向 5 年以上工作经验的技术团队负责人、架构师、工程总监、高级开发人员分享技术创新和典型实践。\n2023 年 5 月 26 日-27 日，QCon 广州站邀请了 MOSN 项目核心开发者、蚂蚁集团技术专家朱德江，将现场分享 《解密 MoE：将 Golang 嵌入 Envoy（C++）》。扫描上图二维码可参与报名。\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 17 日 14:00 - 15:00\n会议内容：\n随着本周社区会议的召开，社区同学进一步探讨了 Layotto 兼容 Dapr 的组件问题，解决思路逐渐清晰；对于如何使 Layotto 提供高性能的通信交互能力，社区同学将此问题与开源之夏的课题进行结合，并确定了版本优化的方向。\n「Layotto」：https://github.com/mosn/layotto/issues/929\n「会议回放」：https://www.bilibili.com/video/BV1Go4y1F7wo/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 24 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题汇总 #894\n Discussion：自建各种 Component #902\n 希望 Layotto 提供高性能的通信交互能力 #867\n 「Layotto」：https://github.com/mosn/layotto/issues/929\nSOFAStack 社区本周贡献\n本周推荐阅读\nMoE 系列（四）｜Go 扩展的异步模式\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\n【开源之夏 2023】欢迎报名 MOSN 社区项目！\n【开源之夏 2023】欢迎报名 SOFAStack 社区项目！\n","date":1684479600,"description":"SOFA Weekly｜SOFA 大事记、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230519/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bd81b1b8854e7bc553af2531bbdbe44a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230519/","publishdate":"2023-05-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230519/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 大事记、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230519/","wordcount":1102},{"author":null,"categories":"SOFAStack","content":"在《MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置》中我们体验了用 Istio 做控制面，给 Go 扩展推送配置，这次我们来体验一下，在 Go 扩展的异步模式下，对 Goroutine 等全部 Go 特性的支持。\n异步模式\n之前，我们实现了一个简单的 Basic Auth[1]，但是，那个实现是同步的，也就是说，Go 扩展会阻塞，直到 Basic Auth 验证完成，才会返回给 Envoy。\n因为 Basic Auth 是一个非常简单的场景，用户名密码已经解析在 Go 内存中了，整个过程只是纯 CPU 计算，所以，这种同步的实现方式是没问题的。\n但是，如果我们要实现一个更复杂的需求，比如，我们要将用户名密码调用远程接口查询，涉及网络操作，这个时候，同步的实现方式就不太合适了。因为同步模式下，如果我们要等待远程接口返回，Go 扩展就会阻塞，Envoy 也就无法处理其他请求了。\n所以，我们需要一种异步模式：\n 我们在 Go 扩展中，启动一个 Goroutine，然后立即返回给 Envoy，当前正在处理的请求会被挂起，Envoy 则可以继续处理其他请求。 Goroutine 在后台异步执行，当 Goroutine 中的任务完成之后，再回调通知 Envoy，挂起的请求可以继续处理了。 注意：虽然 Goroutine 是异步执行，但是 Goroutine 中的代码，与同步模式下的代码，几乎是一样的，并不需要特别的处理。\n为什么需要\n为什么需要支持 Goroutine 等全部 Go 的特性呢？\n有两方面的原因：\n 有了 Full-feature supported Go，我们可以实现非常强大、复杂的扩展。 可以非常方便的集成现有 Go 世界的代码，享受 Go 生态的红利。 如果不支持全部的 Go 特性，那么在集成现有 Go 代码的时候，会有诸多限制，导致需要重写大量的代码，这样，就享受不到 Go 生态的红利了。\n实现\n接下来，我们还是通过一个示例来体验，这次我们实现 Basic Auth 的远程校验版本，关键代码如下：\nfunc (f *filter) DecodeHeaders(header api.RequestHeaderMap, endStream bool) api.StatusType { go func() { // verify 中的代码，可以不需要感知是否异步 // 同时，verify 中是可以使用全部的 Go 特性，比如，http.Post if ok, msg := f.verify(header); !ok { f.callbacks.SendLocalReply(401, msg, map[string]string{}, 0, \u0026amp;quot;bad-request\u0026amp;quot;) return } // 这里是唯一的 API 区别，异步回调，通知 Envoy，可以继续处理当前请求了 f.callbacks.Continue(api.Continue) }() // Running 表示 Go 还在处理中，Envoy 会挂起当前请求，继续处理其他请求 return api.Running } 再来看 verify 的代码，重点是，我们可以在这里使用全部的 Go 特性：\n// 这里使用了 http.Post func checkRemote(config *config, username, password string) bool { body := fmt.Sprintf(`{\u0026amp;quot;username\u0026amp;quot;: \u0026amp;quot;%s\u0026amp;quot;, \u0026amp;quot;password\u0026amp;quot;: \u0026amp;quot;%s\u0026amp;quot;}`, username, password) remoteAddr := \u0026amp;quot;http://\u0026amp;quot; + config.host + \u0026amp;quot;:\u0026amp;quot; + strconv.Itoa(int(config.port)) + \u0026amp;quot;/check\u0026amp;quot; resp, err := http.Post(remoteAddr, \u0026amp;quot;application/json\u0026amp;quot;, strings.NewReader(body)) if err != nil { fmt.Printf(\u0026amp;quot;check error: %v\\n\u0026amp;quot;, err) return false } if resp.StatusCode != 200 { return false } return true } // 这里操作 header 这个 interface，与同步模式完全一样 func (f *filter) verify(header api.RequestHeaderMap) (bool, string) { auth, ok := header.Get(\u0026amp;quot;authorization\u0026amp;quot;) if !ok { return false, \u0026amp;quot;no Authorization\u0026amp;quot; } username, password, ok := parseBasicAuth(auth) if !ok { return false, \u0026amp;quot;invalid Authorization format\u0026amp;quot; } fmt.Printf(\u0026amp;quot;got username: %v, password: %v\\n\u0026amp;quot;, username, password) if ok := checkRemote(f.config, username, password); !ok { return false, \u0026amp;quot;invalid username or password\u0026amp;quot; } return true, \u0026amp;quot;\u0026amp;quot; } 另外，我们还需要实现一个简单的 HTTP 服务，用来校验用户名密码，这里就不展开了，用户名密码还是 foo:bar。\n完整的代码，请移步 Github[2]。\n测试\n老规矩，启动之后，我们使用 curl 来测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; HTTP/1.1 401 Unauthorized # valid foo:bar $ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39; HTTP/1.1 200 OK 依旧符合预期。\n总结\n在同步模式下，Go 代码中常规的异步非阻塞也会变成阻塞执行，这是因为 Go 和 Envoy 是两套事件循环体系。\n而通过异步模式，Go 可以在后台异步执行，不会阻塞 Envoy 的事件循环，这样，就可以用上全部的 Go 特性了。\n由 …","date":1684220400,"description":"MoE 系列（四）｜Go 扩展的异步模式","dir":"blog/moe-series (4)-go-extended-asynchronous-mode/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"34088a54a5896da249c7fab7e02b446e","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","publishdate":"2023-05-16T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","summary":"在《MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置》中我们体验了用 Istio 做控制面，给 Go 扩展推送配置，这次我们来体验一下，在 Go 扩展的异步模式下，对 Goroutine 等","tags":["SOFAStack"],"title":"MoE 系列（四）｜Go 扩展的异步模式","type":"blog","url":"/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","wordcount":1459},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议回顾\nSOFAArk：\n主题：SOFAArk 社区会议（月会）\n时间：5 月 8 日 20:00 - 21:30\n会议内容：\n本次社区会议根据议题介绍了近期 SOFAArk 2.2.0 版本发布计划，更新内容预计包含支持 JDK 17 模式下运行、依据 JarLocation 解析 BUG 修复、Benchmark 的一期建设；会议同步了非迭代 issue 进展，包括搭建 SOFAArk Windows 环境 CI、修复因文件路径不支持跨平台导致的资源加载失败问题；介绍了今年开源之夏 SOFAArk 提交的两个项目，邀请社区同学关注与参与；最后，大家一起讨论了 GPT 在 SOFA 工程领域的探索，目前开发同学正在建设基于 ChatGPT + LangChain 的基础工具链，会议中也邀请了社区同学一起共建。\n「会议纪要」：https://github.com/sofastack/sofa-ark/issues/636\n「会议回放」：https://www.bilibili.com/video/BV1Qs4y1D7Lv/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 2023-05-17 社区会议\n时间：5 月 17 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题:\n 2023 开源之夏-课题汇总#894 Discussion：自建各种 Component#902 希望 Layotto 提供高性能的通信交互能力#867 CLA 机器人问题同步 「Layotto」：https://github.com/mosn/layotto/issues/920\nSOFAStack 社区本周贡献\n本周推荐阅读\n【开源之夏 2023】欢迎报名 SOFAStack 社区项目！\n【开源之夏 2023】欢迎报名 MOSN 社区项目！\nKCL v0.4.6 重磅发布！全新的 IDE 插件，Helm/Kustomize/KPT 工具集成\n恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n","date":1683874800,"description":"SOFA Weekly｜SOFAArk 社区会议回顾、Layotto 社区会议预告、社区本周贡献","dir":"blog/sofa-weekly-230512/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3897039aee7e06226e62c5d248b6a953","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230512/","publishdate":"2023-05-12T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230512/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAArk 社区会议回顾、Layotto 社区会议预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230512/","wordcount":1029},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\nDragonfly 项目介绍\nDragonfly 是一个基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱项目 （Sandbox） 。2020 年 4 月，CNCF 技术监督委员会 （TOC） 投票决定接受 Dragonfly 作为孵化项目 （Incubating） 。经过多年生产实践经验打磨的下一代产品，汲取了 Dragonfly 1.x 的优点并针对已知问题做了大量的优化，在解决大规模文件分发场景下有着无可比拟的优势。基于 P2P 技术的优势，在 AI Inference 分发模型场景可以解决大文件分发过程中的性能瓶颈。并且可以通过集成 Dragonfly P2P 技术减少源站压力，提高模型分发效率。在未来，Dragonfly 会结合 AI 领域生态进行拓展，服务 AI 领域并且成为其重要基础设施。\nKata Containers 项目介绍\n自 2013 年 Docker 问世以来，容器技术立刻让全球的开发者为之着迷，并逐渐成为现代应用程序、构建、发布和运维的主流方式。容器以标准格式对应用程序进行封装，应用程序可从一个计算环境快速、安全地切换到另一个计算环境，这对于想要快速构建、测试和部署软件的开发者而言至关重要。然而传统的以 runC 为代表的容器方案基于共享内核技术，通过 Linux 提供的 Cgroups 和 Namespace 等方案进行隔离和控制，如果某一容器中的恶意程序利用了系统缺陷从容器中逃逸，则会对宿主机系统构成严重威胁。尤其是在公有云环境，这一潜在威胁成为了容器技术普及和落地的一大障碍。如果将不同容器再嵌套放入到不同的虚拟机，通过增加一层相对安全、成熟的隔离技术，就能大大提高系统的安全性，减少系统被攻破的可能。基于这种思想的开源技术也随之出现，代表性的两个项目为 Intel 开源技术中心的 Clear Containers 和 Hyper.sh 的 runV。2017 年，这两个开源项目合并，共同创建了开源项目 Kata Containers，其目标是将虚拟机的安全优势与容器的高速及可管理性相结合，为用户提供标准化、安全、高性能的容器解决方案。Kata Containers 创建的不同 Pod （容器） 运行在不同的虚拟机 （Kernel） 之中，比传统容器提供了更好的隔离性和安全性，同时继承了容器快速启动和标准化等优点。\nNydus 项目介绍\n镜像是容器基础设施中的一个重要部分，目前 OCI 标准镜像的缺陷之一是容器需要等待整个镜像数据下载完成后才能启动，这导致了容器启动时消耗了过多的端到端时间。在大规模集群场景下，这对网络与存储负载的影响尤为明显。Nydus 镜像加速框架提供了容器镜像按需加载的能力，它在生产环境里支撑了每日百万级别的加速镜像容器创建，将容器端到端冷启动时间从分钟级降低到了秒级。Nydus 目前由蚂蚁集团，阿里云，字节跳动联合研发，与内核态 EROFS 做了深度集成，也是 Kata Containers 与 Linux 内核态原生支持的镜像加速方案。目前 Nydus 已经被容器生态主流项目支持，例如 Containerd，Docker，Podman，BuildKit, Nerdctl，Kata Containers。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nDragonfly 社区项目\n项目链接： https://summer-ospp.ac.cn/org/orgdetail/72e6f975-d2b8-4fa3-a377-441c1038db10?lang=zh\nPyTorch Serve 基于 Dragonfly P2P 技术分发模型\n导师： yxxhero\n邮箱： aiopsclub@163.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0132?list=org\u0026amp;amp;navpage=org\nTensorFlow Serving 基于 Dragonfly P2P 技术分发模型\n导师： 崔大钧\n邮箱： bigerous@qq.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0022?list=org\u0026amp;amp;navpage=org\nTriton Inference Server 基于 Dragonfly P2P 技术分发模型\n导师： 戚文博\n邮箱： gaius.qi@gmail.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0001?list=org\u0026amp;amp;navpage=org\nKata Containers 社区项目\n项目链接： https://summer-ospp.ac.cn/org/orgdetail/301597a0-ca46-418a-89d1-13ea3c050ee9?lang=zh\n基于 VSOCK FD Passthrough 对 Container IO Stream 进行重构\n导师： 李福攀\n邮箱： fupan.lfp@antgroup.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010451?list=org\u0026amp;amp;navpage=org\nNydus RAFS v6 guest 内核支持优化\n导师： 李亚南\n邮箱： alex.lyn@antgroup.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010419?list=org\u0026amp;amp;navpage=org\n跨容器 shared-mount 支持\n导师： 彭涛\n邮箱： bergwolf@hyper.sh\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010417?list=org\u0026amp;amp;navpage=org\nNydus 社区项目\n项目链接： …","date":1683788400,"description":"【开源之夏 2023】欢迎报名 Dragonfly、Kata Containers、Nydus 社区项目！","dir":"activities/[Summer-2023-of-open-source-promotion-plan]welcome-to-register-for-dragonfly,kata-containers,and-nydus-community-projects!/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d417195ca31984354ab9fba0f7f2cefe","permalink":"https://sofastack.github.io/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","publishdate":"2023-05-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["开源之夏"],"title":"【开源之夏 2023】欢迎报名 Dragonfly、Kata Containers、Nydus 社区项目！","type":"activities","url":"/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","wordcount":2002},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2023 年，MOSN 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2023”，为大家准备了三个任务，涉及 Go、HTTP、Security、Software-Defined Networking、Container 等多个领域。\nMOSN 项目介绍\nMOSN*（Modular Open Smart Network）*是一款基于 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并在双 11 大促期间经过几十万容器的生产级验证。MOSN 为服务提供多协议、模块化、智能化、安全的代理能力，融合了大量云原生通用组件，同时也可以集成 Envoy 作为网络库，具备高性能、易扩展的特点。另外，MOSN 可以集成 Istio 构建 Service Mesh，也可以作为独立的四、七层负载均衡，API Gateway、云原生 Ingress 等使用。\nLayotto 项目介绍\nLayotto（/leɪˈɒtəʊ/） 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，例如状态管理、配置管理、事件发布订阅等，以简化应用的开发。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nMOSN 社区项目\n项目链接：https://summer-ospp.ac.cn/org/orgdetail/f0813e66-fa19-4302-a3e3-e6f2d210c83d?lang=zh\nMOSN\nGo、HTTP、Security\n项目社区导师：罗泽轩\nspacewanderlzx@gmail.com\n基于 Coraza 和 MOSN on Envoy 开发 Envoy 的 WAF 插件\n项目编号：23f080212\n项目难度：进阶/Advanced\nCoraza 是一个用 Go 实现的 WAF 引擎，我们希望能够借助 MOSN on Envoy 的能力，让 Coraza 运行在 Envoy 当中，并与官方的基于 Wasm 的实现*（https://github.com/corazawaf/coraza-proxy-wasm）*进行比较。\n 实现一个基本可用的 WAF 插件*（需要有详尽的文档+测试）*，并与 Wasm 版本做对比，输出一份比较报告。 了解 MOSN、Envoy 和 WAF，能够用 Go 写代码。 MOSN\nGo、Software-Defined Networking\n项目社区导师：纪卓志\njizhuozhi.george@gmail.com\n为 Envoy Go 扩展建设插件市场\n项目编号：23f080259\n项目难度：进阶/Advanced\nEnvoy 是当前最流行的网络代理之一，Go 扩展是 MOSN 社区为 Envoy 增加的 Go 生态基础，也是 MOSN 社区 MoE 框架的基础。\n受益于 Golang 生态系统，研发可以轻松在 Envoy 实现插件用于更多的长尾场景，其中很多场景都是通用的。\n本项目是为 Envoy Go 扩展构建插件市场。在插件市场中，人们可以在插件市场中分享插件，选用已经存在的插件。通过插件市场，可以让 Envoy、MoE 生态变得更加开放、共享、丰富。\n 提供一个 Envoy Go 插件的内容平台，在这里可以发布经过社区 Review 的优秀插件，需要拥有服务端与前端页面。\n 不自建账号体系，通过 GitHub OAuth2.0 完成用户认证与授权。\n 进阶——对接 GitHub OpenAPI，支持动态获取插件所在仓库信息，包括 README、分支版本以及 Star 数。\n 能够使用 Go 语言*（框架不限）*开发出带前端页面的小型站点。\n 对认证与授权及 OAuth2.0 有基本的了解。\n 熟悉 Git 和 GitHub 工作流程*（分支、版本、合并请求等）*。\n Layotto\nGo、gRPC\n项目社区导师：wenxuwan\nwangwenxue.wwx@antgroup.com\nLayotto Support Pluggable Components\n项目编号：23f080194\n项目难度：进阶/Advanced\n当前 Layotto 的 Components 都是实现在 Layotto 的工程里面的。用户若要想使用新的 Component，就必须使用 Golang 语言开发，同时必须在 Layotto 工程中实现，然后统一编译。对于多语言用户来说非常不友好，因此 Layotto 需要提供 Pluggable Components 的能力，允许用户可以通过任何语言实现自己的 Components，Layotto 通过 gRPC 协议和外部的 Components 进行通信。\n 完成 Pluggable Components 框架设计。\n 提供 Pluggable Components 接入文档和示例。\n 熟悉 Golang 和 gRPC，熟悉 Dapr 和 Layotto 运行时架构。\n 申请资格\n 本活动面向年满 18 周岁在校学生。\n 暑期即将毕业的学生，只要在申请时学生证处在有效期内，就可以提交申请。\n 中国籍学生参与活动需提供身份证、学生证、教育部学籍在线验证报告（学信网）或在读证明。\n 外籍学生参与活动需提供护照，同时提供录取通知书、学生卡、在读证明等文件用于证明学生身份。\n 活动流程\n添加 SOFAGirl 微信\n备注“开源之夏”进群交流\n","date":1683615600,"description":"【开源之夏 2023】欢迎报名 MOSN 社区项目！","dir":"activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project!/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1bdbf9f33dd6670508117cc1e5e907df","permalink":"https://sofastack.github.io/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","publishdate":"2023-05-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["开源之夏"],"title":"【开源之夏 2023】欢迎报名 MOSN 社区项目！","type":"activities","url":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","wordcount":1852},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nSOFAArk：\n主题：SOFAArk 2023-05-08 社区会议\n时间：5 月 8 日（下周一）20:00-21:30\n入会口令（钉钉）：683 550 26227\n电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题：\n 近期版本发布计划和内容 非迭代 issue 处理同步 开源之夏活动介绍 GPT 在 SOFA 工程领域的探索 「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/636\nLayotto：\n主题：Layotto 2023-05-10 社区会议\n时间：5 月 10 日（下周三）14:00-15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题/导师招募 Discussion：自建各种 Component 希望 Layotto 提供高性能的通信交互能力 CLA 机器人问题同步 「Layotto」：https://github.com/mosn/layotto/issues/915\nMOSN 社区：\n 基于 coraza 和 MOSN on Envoy 开发 Envoy 的 WAF 插件 导师：罗泽轩\n联系邮箱：spacewanderlzx@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080212?lang=zh\u0026amp;amp;list=pro\n 为 Envoy Go 扩展建设插件市场 导师：纪卓志\n联系邮箱：jizhuozhi.george@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080259?list=org\u0026amp;amp;navpage=org\nLayotto 社区：\n Layotto 支持自动/手动注入 Pod 部署 导师：刘训灼\n联系邮箱：mixdeers@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/2395a0359?list=org\u0026amp;amp;navpage=org\n Layotto Support Pluggable Components 导师：王文学\n联系邮箱：wangwenxue.wwx@antgroup.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080194?list=org\u0026amp;amp;navpage=org\n社区本周贡献\n本周推荐阅读\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\n如何看待 Dapr、Layotto 这种多运行时架构？\n应用运行时 Layotto 进入 CNCF 云原生全景图\n","date":1683270000,"description":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","dir":"blog/sofa-weekly-0505/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d9d0126ce61dc5e57710e2db403ca34e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0505/","publishdate":"2023-05-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0505/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜开源之夏 MOSN 与 Layotto 项目简介、社区会议预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0505/","wordcount":1039},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2023 年，SOFAStack 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2023”，一共为大家准备了五个任务，涵盖 SOFARPC、SOFAArk、SOFAJRaft 和 Layotto 等核心项目，涉及 Golang、Java、Kubernetes、Cloud Native、Distributed System 等多个领域。\nSOFARPC 项目介绍\nSOFARPC 是由蚂蚁集团开源的一款 Java RPC 框架，具有高可扩展性、高性能和生产级特性。该框架旨在简化应用之间的 RPC 调用，并为应用提供便捷透明、稳定高效的点对点远程服务调用方案。为方便用户和开发者进行功能扩展，SOFARPC 提供了丰富的模型抽象和可扩展接口，包括过滤器、路由、负载均衡等。\nSOFAArk 项目介绍\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，由蚂蚁集团开源贡献。该容器主要提供类隔离和应用（模块）合并部署能力。SOFAArk 提供多种方式来支持多应用（模块）合并部署，包括基于命令行的管控、基于 API 的管控等。\nSOFAJRaft 项目介绍\nSOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，适用于高负载低延迟的场景，支持 MULTI-RAFT-GROUP。使用 SOFAJRaft 可专注于业务领域，由 SOFAJRaft 解决与 RAFT 相关的技术难题。并且 SOFAJRaft 易于使用，可以通过几个示例快速掌握它。\nLayotto 项目介绍\nLayotto(/leɪˈɒtəʊ/) 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，例如状态管理、配置管理、事件发布订阅等，以简化应用的开发。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nSOFAStack 社区项目\n项目链接：https://summer-ospp.ac.cn/org/orgdetail/95a9e459-a200-4a26-bc0a-81074c2d89be?lang=zh\nSOFARPC\nJava、网络通信、RPC\n项目社区导师：EvenLiu\nevenljj@163.com\nSOFARPC 支持 Stream 流式处理方式\n项目编号：2395a0260\n项目难度：进阶/Advanced\nStream 方式是一种异步的流式处理方式，可以在数据传输过程中逐个处理数据，避免一次性传输大量数据造成的性能问题。服务端 Stream 是指服务端在处理请求时，将数据分成多个部分逐个返回给客户端的过程；客户端 Stream 是指客户端在请求服务器时，将请求参数分成多个部分逐个发送给服务器的过程。Stream 方式可以让我们在处理大量数据时更高效地使用资源，提高系统的性能和响应速度。SOFARPC 中需要 Triple、Bolt 协议支持 Stream 方式流式处理。\n SOFARPC 中 Triple 协议支持 Stream 流式处理。\n SOFARPC 中 Bolt 协议支持 Stream 流式处理。\n SOFAArk\nJava、SOFAArk 源代码\n项目社区导师：卫恒\nglmapper_2018@163.com\n开发一个客户端，支持 Biz 模块的热部署和热卸载，初步实现 Serverless 体验\n项目编号：2395a0267\n项目难度：基础/Basic\nSOFAArk 从最初的一个类隔离框架，逐步演进为支持合并部署与热部署的 “Serverless” 运行时框架，尤其在去年我们完成了 SOFAArk1.0 到 2.0 架构的演进。但是为了让开发者真正享受 Serverless 的研发体验，我们还需要建设一个客户端框架，对接 SOFAArk 实现 Biz 模块的热部署和热卸载，并暴露 HTTP API 接口可以让上游系统或者开发者直接使用。\n 设计并开发一个新的 SDK（SOFALet），新的 SDK 也就是 SOFALet 暴露一组 HTTP 接口，底层调用 SOFAArk 原子能力实现模块的热部署和热卸载。SOFALet 未来还会有 Node.js 版，这一期先支持 Java 版也就是对接 SOFAArk。\n 理解 SOFAArk 源代码，尤其是关于 telnet 指令安装和卸载模块的部分。\n SOFAArk\nGo、K8s\n项目社区导师：流铄\nxujinle300@126.com\n开发一个 K8s Operator，编排客户端 API 实现 Biz 模块的热部署，初步达成 Serverless 研发体验\n项目编号：2395a0392\n项目难度：基础/Basic\n为了让开发者真正享受 Serverless 的研发体验，我们需要先建设一个简易的 K8s Operator 和 SOFA Module Deployment、SOFA Module ReplicaSet CRD，对接编排模块热装载和热卸载的客户端，实现模块秒级发布的初步能力，让开发者能初步体验到 Serverless 的发布运维能力。\n 理解 SOFAArk 模块安装和卸载部分的源代码，并且熟悉 K8s CRD 和 Operator 体系的设计与开发。 SOFAJRaft\nJava、网络通信、RPC\n项目社区导师：刘源远\ngege87417376@qq.com\n结合 NWR 实现 Flexible RAFT，用于自定义 Quorum 的大小\n项目编号：2395a0390\n项目难度：进阶/Advanced\nJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，它运行过程分为两个阶段，即 Leader 选举和日志复制。在原始的 RAFT 算法中，Leader 选举和日志复制都需要获得多数派成员的支持。而 NWR 模型则可以在动态调整一致性强度的场景中使用，它需要满足 W+R\u0026amp;gt;N，以保证强一致性。JRaft 将 RAFT 和 NWR 结合起来，使得用户可以根据不同的业务需求来动态调整 Quorum 的数量。例如，在一个写多读少的场景中，用户可以将多数派的数量从 3 调整为 2，以降低达成共识的条件，从而提高写请求的效率。同时，为了保证 RAFT 的正确性，写 Quorum 的调整需要付出代价，即读 Quorum 的数量也需要相应调整。JRaft 支持成员变更，因此用户可以配置 (0,1] 范围内的小数来计算 W 和 R 的具体值。通过使用 JRaft，用户可以根据自己的业务需求来灵活地调整 …","date":1683270000,"description":"【开源之夏 2023】欢迎报名 SOFAStack 社区项目！","dir":"activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"def1ba20e3e6b79b6b9e2c6bae16ba91","permalink":"https://sofastack.github.io/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","publishdate":"2023-05-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["SOFAStack 开源之夏"],"title":"【开源之夏 2023】欢迎报名 SOFAStack 社区项目！","type":"activities","url":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","wordcount":2742},{"author":null,"categories":"SOFAStack","content":"上一篇我们用 Go 扩展实现了 Basic Auth，体验了 Go 扩展从 Envoy 接受配置。\n之所以这么设计，是想复用 Envoy 原有的 xDS 配置推送通道，今天我们就来体验一番，云原生的配置变更。\n前提准备\n这次我们需要一套 K8s 环境，如果你手头没有，推荐使用 Kind 安装一套。具体安装方式，这里就不展开了。\n安装 Istio\n我们直接安装最新版的 Istio：\n# 下载最新版的 istioctl$ export ISTIO_VERSION=1.18.0-alpha.0$ curl -L https://istio.io/downloadIstio | sh - # 将 istioctl 加入 PATH$ cd istio-$ISTIO_VERSION/$ export PATH=$PATH:$(pwd)/bin # 安装，包括 istiod 和 ingressgateway$ istioctl install 是的，由于 Go 扩展已经贡献给了上游官方，Istiod（Pilot）和 Ingress Gateway 都已经默认开启了 Go 扩展，并不需要重新编译。\nIstio 配置 Ingress\n我们先用 Istio 完成标准的 Ingress 场景配置，具体可以看 Istio 的官方文档[1]。\n配置好了之后，简单测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot;HTTP/1.1 200 OKserver: istio-envoydate: Fri, 10 Mar 2023 15:49:37 GMT 基本的 Ingress 已经跑起来了。\n挂载 Golang so\n之前我们介绍过，Go 扩展是单独编译为 so 文件的，所以，我们需要把 so 文件，挂载到 Ingress Gateway 中。\n这里我们把上次 Basic Auth 编译出来的 libgolang.so，通过本地文件挂载进来。简单点搞，直接 edit deployment 加了这些配置：\n# 申明一个 hostPath 的 volumevolumes:- name: golang-so-basic-auth hostPath: path: /data/golang-so/example-basic-auth/libgolang.so type: File # 挂载进来volumeMounts:- mountPath: /etc/golang/basic-auth.so name: golang-so-basic-auth readOnly: true 开启 Basic Auth 认证\nIstio 提供了 EnvoyFilter CRD，所以，用 Istio 来配置 Go 扩展也比较方便，apply 这段配置，Basic Auth 就开启了。\napiVersion: networking.istio.io/v1alpha3kind: EnvoyFiltermetadata: name: golang-filter namespace: istio-systemspec: configPatches: # The first patch adds the lua filter to the listener/http connection manager - applyTo: HTTP_FILTER match: context: GATEWAY listener: filterChain: filter: name: \u0026amp;quot;envoy.filters.network.http_connection_manager\u0026amp;quot; subFilter: name: \u0026amp;quot;envoy.filters.http.router\u0026amp;quot; patch: operation: INSERT_BEFORE value: # golang filter specification name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: \u0026amp;quot;type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config\u0026amp;quot; library_id: example library_path: /etc/golang/basic-auth.so plugin_name: basic-auth plugin_config: \u0026amp;quot;@type\u0026amp;quot;: \u0026amp;quot;type.googleapis.com/xds.type.v3.TypedStruct\u0026amp;quot; type_url: typexx value: username: foo password: bar 虽然有点长，但是，也很明显，配置的用户名密码还是：foo:bar。\n测试\n我们测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot;HTTP/1.1 401 Unauthorized # valid foo:bar$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39;HTTP/1.1 200 OK 符合预期。\n接下来，我们改一下 EnvoyFilter 中的密码，重新 apply，再测试一下：\n# foo:bar not match the new password$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39;HTTP/1.1 401 Unauthorized 此时的 Envoy 并不需要重启，新的配置就立即生效了，云原生的体验就是这么溜~\n总结\n因为 Go 扩展可以利用 Envoy 原有的 xDS 来接受配置，所以，从 Istio 推送配置也变得很顺利。\n不过，Istio 提供的 EnvoyFilter CRD 在使用上，其实并不是那么方便和自然，后面我们找机会试试 Envoy Gateway，看看 K8s Gateway API 的体验如何。\n至此，我们已经体验了整个 Envoy Go 的开发\u0026amp;amp;使用流程，在云原生时代，人均 Golang 的背景下，相信可以很好的完成网关场景的各种定制需求。\n下一篇，我们将介绍，如何在 Go 扩展中使用异步 …","date":1683010800,"description":"MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置","dir":"blog/moe-series (3)｜dynamic-update-of-go-extension-configuration-with-istio/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1683010800,"objectID":"5ff7cec6ed4b29c51c1f65f47b32672c","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","publishdate":"2023-05-02T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","summary":"上一篇我们用 Go 扩展实现了 Basic Auth，体验了 Go 扩展从 Envoy 接受配置。 之所以这么设计，是想复用 Envoy 原有的 xDS 配置推送通道，今天我们就来体验一番，云原生的","tags":["SOFAStack"],"title":"MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置","type":"blog","url":"/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","wordcount":974},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nSOFAArk：\n主题：SOFAArk 社区会议\n时间：5 月 8 日 20:00 - 21:30\n入会口令（钉钉）：683 550 26227\n电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题：\n 近期版本发布计划和内容。 非迭代 issue 处理同步。 开源之夏活动介绍。 GPT 在 SOFA 工程领域的探索。 「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/636\n每月一次的 SOFAArk 社区会议要开啦！有对议题感兴趣的同学不要错过哦～\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：4 月 26 日 14:00 - 15:00\n会议内容：\n本次社区会议根据议题同步了 2023 开源之夏申报的课题，并号召社区同学踊跃参与；对于自建各种组件，会议详细讲解了问题痛点与解决方案；Layotto 在升级 gRPC 版本时出现的前置依赖问题，会议中的同学提出了方案；在会议的最后，同步了 CLA 机器人解决的进展与办法。\n「Layotto」：https://github.com/mosn/layotto/issues/915\n「会议回放」：https://www.bilibili.com/video/BV1Qg4y177dG/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@huayangchan #914\n 下载 Layotto-0.5.0 源码，在本地 Windows 系统编译启动时，报一些函数和变量未定义错误，如 undefined: syscall.GetsockoptIPv 6Mreq，这应该是 Unix 系统才调用的函数，为什么在 Windows 系统运行会调 Unix 系统相关的函数，还说源码只能在 Unix 系统上便已启动?\n A：Layotto 是基于 MOSN 为底座的，用到了 Linux 的系统函数，所以不支持 Windows 上的编译。可以参考：https://github.com/mosn/layotto/issues/801\n「Layotto」：https://github.com/mosn/layotto/issues/914\n2.@shuangchengsun #263\n 图片展示了实例（Client）的上下线过程， 假设这么一个场景，Client1 处于下线过程中，此时它已经和 Session Server 断链，但是 Session Server 在发出同步通知前因为某种原因挂了，此时 Client1 在路由表中的状态是如何维护的？\n A: Data 上有一个定时器去维护每个 Session 相关数据的。如果 Session 挂了，Data 大约 30s 后把挂掉的 Session 的数据清理掉，同时链接挂掉的 Client（除了要下线的那个）会自动重连到其他 Session 上。然后会把数据增长一个 Version 重新注册到 Session，Session 会再次发到那台 Data 上。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/issues/263\n本周推荐阅读\n缘起｜蚂蚁应用级服务发现的实践之路\nSOFARegistry 源码｜数据同步模块解析\nMoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\n","date":1682665200,"description":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","dir":"blog/sofa-weekly-20230428/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f7cd5d7b9340442e111c4dfeaf5a6813","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230428/","publishdate":"2023-04-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230428/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230428/","wordcount":1451},{"author":null,"categories":"SOFAStack","content":"文｜蚂蚁集团 ZOLOZ 团队\n使用全球领先安全科技，为用户和机构提供安全、便捷的安全风控解决方案。\n本文 6386 字 阅读 12 分钟\n背景简介\nZOLOZ[1]是蚂蚁集团旗下的全球安全风控平台，通过业内领先的生物识别、大数据分析和人工智能技术，为用户和机构提供安全又便捷的安全风控解决方案。ZOLOZ 已为中国、印尼、马来西亚、菲律宾等 14 个国家和地区的 70 余家合作伙伴提供数字化转型过程中的安全风控技术支持。目前，已经覆盖金融、保险、证券、信贷、电信、公众服务等领域，累计服务用户超 12 亿。\n随着 Kubernetes 和云原生的大爆发，ZOLOZ 应用开始在公有云上进行大规模容器化部署。ZOLOZ 业务的镜像经过长期维护和更新，无论是镜像层数还是整体大小都达到了一个较大的量级 （数百 MB 或者几个 GB） 。特别是 ZOLOZ AI 算法推理应用的基础镜像大小要远大于一般应用镜像 （Docker Hub 上 PyTorch/PyTorch：1.13.1-CUDA 11.6-cuDNN 8-Runtime 有 4.92GB，同比 CentOS：latest 只有约 234MB） ，对于容器冷启动，即在本地无镜像的情况下，需要先从 Registry 下载镜像才能创建容器，在生产环境中，容器的冷启动往往耗时数分钟，并且随规模扩大会导致 Registry 因集群内网络拥堵而无法快速地下载镜像，如此庞大的镜像给应用的更新和扩容等操作都带来了不少挑战。在公有云上容器化持续推进的当下，ZOLOZ 应用主要遇到了三大挑战：\n 算法镜像大，推送到云上镜像仓库耗时长，开发过程中，在使用测试环境进行测试时，往往希望快速迭代，快速验证，但是每次改完一个分支发布验证都要经过几十分钟，开发效率十分低下。\n 拉取算法镜像耗时长，在集群扩容大量机器拉取镜像文件会容易导致集群网卡被打满，影响业务正常运行。\n 集群机器拉起时间长，难以满足流量突增时，弹性自动扩缩容。\n 虽然也尝试过各种折中的解决方案，但这些方案都有缺陷，现在结合蚂蚁、阿里云、字节跳动等多个技术团队打造了一套更通用的公有云上解决方案，该方案改造成本低，性能好，目前看来是比较理想的方案。\n术语及定义\nOCI：Open Container Initiative，开放容器计划是一个 Linux 基金会项目，由 Docker 在 2015 年 6 月启动，旨在为操作系统级虚拟化 （最重要的是 Linux 容器） 设计开放标准。\nOCI Manifest：遵循 OCI Image Spec 的制品。\nBuildKit：是 Docker 公司出品的一款更高效、Dockerfile 无关、更契合云原生应用的新一代 Docker 构建工具。\n镜像：本文中的镜像指 OCI Manifest，也包括 Helm Chart 等其他 OCI Manifest。\n镜像仓库：遵循 OCI Distribution Spec 实现的制品仓库。\nECS：是一种由 CPU、内存、云盘组成的资源集合，每一种资源都会逻辑对应到数据中心的计算硬件实体。\nACR：阿里云镜像仓库服务。\nACK：阿里云容器服务 Kubernetes 版提供高性能可伸缩的容器应用管理能力，支持企业级容器化应用的全生命周期管理。\nACI：ACI 全称 Ant Continuous Integration （AntCI） ，是蚂蚁集团研发效能旗下一款以流水线 （Pipeline） 为核心的 CI/CD 效能产品。使用智能自动化构建、测试和部署，提供了以代码流为输入的轻量级持续交付解决方案，提高团队研发的工作效率。\nPrivate Zone：基于专有网络 VPC （Virtual Private Cloud） 环境的私有 DNS 服务。该服务允许在自定义的一个或多个 VPC 中将私有域名映射到 IP 地址。\nP2P：点对点技术，当 P2P 网络中某一个 Peer 从 Server 下载数据的时候，下载完数据后也能当作服务端供其他 Peer 下载。当大量节点同时下载的时候，能保证后续下载的数据，可以不用从 Server 端下载。从而减轻 Server 端的压力。\nDragonfly：Dragonfly 是⼀款基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。现在为云原生计算机基金会 （CNCF） 托管作为孵化级项目。\nNydus：Nydus 镜像加速框架是 Dragonfly 的子项目，它提供了容器镜像按需加载的能力，在生产环境支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，端到端数据一致性，内核态支持等方面相比 OCIv1 有巨大优势。\nLifseaOS：面向容器场景，阿里云推出轻量、快速、安全、镜像原子管理的容器优化操作系统，相比传统操作系统软件包数量减少 60%，镜像大小减少 70%，OS 首次启动从传统 OS 的 1min 以上下降到了 2s 左右。支持镜像只读和 OSTree 技术，将 OS 镜像版本化管理，更新操作系统上的软件包、或者固化的配置时，以整个镜像为粒度进行更新。\n方案设计\n解决镜像大的问题\n1. 精简基础 镜像 大小\n基础 OS 从 CentOS 7 改为 AnolisOS 8，精简运维工具的安装，只默认安装一些必须的工具列表 （基础运维工具、运行时通用依赖、日志清理、安全基线等组件） ，并简化安全加固的配置，基础镜像从 1.63GB 减少到 300MB。\nAnolisOS 仓库：https://hub.docker.com/r/openanolis/anolisos/tags\n2. Dockerfile 优化\n通过 Dockerfile 编写约束、镜像检测等手段减少不必要的构建资源和时间。\nDockerfile 最佳实践原则: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/\n3. 并行构建和构建缓存\n蚂蚁构建中心采用 Nydus 社区优化版的 BuildKit[2]，BuildKit 支持 layer 级别缓存，准确引用先前的产出物并进行缓存匹配，使用方法与普通镜像并无区别，对于 Multistage 类型 Dockerfile，BuildKit 可以实现不同 stage 之间的并行执行。\n推送到云上镜像仓库耗时长\n1. 使用 Nydus 镜像进行块级别数据去重\n传统 OCI 镜像，不同镜像之间可以共享的最小单位是镜像中的层，在 deduplication 上的效率是非常低的，层内部存在重复的数据，层与层之间可能存在大量重复的数据，即使有微小的差别，也会被作为不同的层，根据 OCI Image Spec 对删除文件和 Hard Link 的设计，一个镜像内部可能存在已经被上层删除的文件仍然存在于下层中，并包含在镜像中。另外 OCI Image 使用了 tar+gzip 格式来表达镜像中的层，而 tar 格式并不区分 tar archive entries ordering， …","date":1682492400,"description":"蚂蚁安全科技 Nydus 镜像加速实践","dir":"blog/ant-security-technology-nydus-mirror-acceleration-practice/","fuzzywordcount":8700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c89b17510ce48eb33633af0051249102","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","publishdate":"2023-04-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","summary":"文｜蚂蚁集团 ZOLOZ 团队 使用全球领先安全科技，为用户和机构提供安全、便捷的安全风控解决方案。 本文 6386 字 阅读 12 分钟 背景简介 ZOLOZ[1]是蚂蚁集团旗","tags":["SOFAStack"],"title":"蚂蚁安全科技 Nydus 镜像加速实践","type":"blog","url":"/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","wordcount":8656},{"author":null,"categories":"SOFA WEEKLY","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：4 月 19 日 14:00 - 15:00\n会议内容：\n本次社区会议根据议题探讨了 2023 开源之夏申报课题的具体方式和内容，并号召同学踊跃参与报名；对于自建组件问题，方案已经敲定，感兴趣的同学可以尝试；Layotto 在升级 gRPC 版本时出现前置依赖问题，并在会议中同步进展；关于 CLA 机器人出现的问题，社区同学共同讨论了提供解决的思路。\n「Layotto」：https://github.com/mosn/layotto/issues/907\n「会议回放」：https://www.bilibili.com/video/BV1aT411p7cr/?share_source=copy_web\u0026amp;amp;vd_source=802e089175dbc2ea677914f78683b18a\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 2023-04-26 社区会议\n时间：4 月 26 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2344343024\n议题：\n 2023 开源之夏-课题/导师招募#894\n Discussion：自建各种 Component#902\n 希望 Layotto 提供高性能的通信交互能力#867\n 「Layotto」：https://github.com/mosn/layotto/issues/907\nSOFA 五周年资料已上传 SOFAStack 官网\n回复公众号：“SOFA 五周年”\n即可获取链接啦～\n还可戳“阅读原文”跳转哦！\nSOFAStack 社区本周贡献\nSOFARPC 5.10.0 版本发布\n发布 SOFARPC 5.10.0 版本，主要变更如下:\n 重构了自定义序列化器的注册模式，使得主站版可以覆盖开源版的注册#1296\n 修改了反序列化时 Request Header 的处理逻辑#1325\n 更新了 Javassist Proxy 构造 class 时的 API 使之能在 JDK17 环境下运行#1316\n 详细发布报告：https://github.com/sofastack/sofa-rpc/compare/v5.9.2\u0026amp;hellip;v5.10.0\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n @LY1806620741 #1061 com.alipay.sofa.rpc.enable-swagger 是否已经废弃？在 3.16.3\ncom.alipay.sofa.rpc.enable-swagger=true 配置使用了 Objectway 的 ASM，与 Spring Boot 的 ASM 冲突。\n A：可以手动增加一个依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.ow2.asm\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;asm\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;9.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 看起来是 https://github.com/sofastack/sofa-rpc/blob/5.8.3.1/all/pom.xml 少添加了一个 ASM 的依赖，导致出现上面的问题。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n @Estom#642 多 Host 模式下，动态部署，无法启动第二个 Tomcat。需要添加特殊的配置吗？\n A：多 Host 模式配置建议看一下这份文档 https://www.sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/中的“6.多 Host 与单 Host 模式”。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/642\n","date":1682060400,"description":"SOFA Weekly｜SOFARPC 5.10.0 版本发布、SOFA 五周年回顾、Layotto 社区会议回顾与预告","dir":"blog/sofa-weekly-0421/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4477f615201d81a1e6578f20f910a5d2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0421/","publishdate":"2023-04-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0421/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA WEEKLY"],"title":"SOFA Weekly｜SOFARPC 5.10.0 版本发布、SOFA 五周年回顾、Layotto 社区会议回顾与预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0421/","wordcount":1547},{"author":null,"categories":"SOFAStack","content":"文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 1445 字 阅读 5 分钟\n上一篇我们用一个简单的示例，体验了用 Golang 扩展 Envoy 的极速上手。\n这次我们再通过一个示例，来体验 Golang 扩展的一个强大的特性：\n从 Envoy 接收配置。\nBasic Auth\n我们还是从一个小示例来体验，这次我们实现标准的 Basic Auth 的认证，与上一次示例不同的是，这次认证的用户密码信息，需要从 Envoy 传给 Go，不能在 Go 代码中写死了。\n完整的代码可以看 example-basic-auth[1]，下面我们展开介绍一番。\n获取配置\n为了更加灵活，在设计上，Envoy 传给 Go 的配置是 Protobuf 的 Any 类型，也就是说，配置内容对于 Envoy 是透明的，我们在 Go 侧注册一个解析器，来完成这个 Any 配置的解析。\n如下示例：\nfunc init() { // 注册 parser http.RegisterHttpFilterConfigParser(\u0026amp;amp;parser{}) } func (p *parser) Parse(any *anypb.Any) interface{} { configStruct := \u0026amp;amp;xds.TypedStruct{} if err := any.UnmarshalTo(configStruct); err != nil { panic(err) } v := configStruct.Value conf := \u0026amp;amp;config{} if username, ok := v.AsMap()[\u0026amp;quot;username\u0026amp;quot;].(string); ok { conf.username = username } if password, ok := v.AsMap()[\u0026amp;quot;password\u0026amp;quot;].(string); ok { conf.password = password } return conf } 这里为了方便，Any 中的类型是 Envoy 定义的 TypedStruct 类型，这样我们可以直接使用现成的 Go pb 库。\n值得一提的是，这个配置解析，只有在首次加载的时候需要执行，后续在 Go 使用的是解析后的配置，所以，我们解析到一个 Go map 可以拥有更好的运行时性能。\n同时，由于 Envoy 的配置，也是有层级关系的，比如 http-filter, virtual host, router, virtual clusters 这四级，我们也支持这四个层级同时有配置，在 Go 侧来组织 merge。\n当然，这个只有在 Go 侧有复杂的 filter 组织逻辑的时候用得上，后面我们在 MOSN 的上层封装的时候，可以看到这种用法，这里暂时不做展开介绍。\n认证\n具体的 Basic Auth 认证逻辑，我们可以参考 Go 标准 net/http 库中的 Basic Auth 实现。\nfunc (f *filter) verify(header api.RequestHeaderMap) (bool, string) { auth, ok := header.Get(\u0026amp;quot;authorization\u0026amp;quot;) if !ok { return false, \u0026amp;quot;no Authorization\u0026amp;quot; } username, password, ok := parseBasicAuth(auth) if !ok { return false, \u0026amp;quot;invalid Authorization format\u0026amp;quot; } if f.config.username == username \u0026amp;amp;\u0026amp;amp; f.config.password == password { return true, \u0026amp;quot;\u0026amp;quot; } return false, \u0026amp;quot;invalid username or password\u0026amp;quot; } 这里面的 parseBasicAuth 就是从 net/http 库中的实现，是不是很方便呢。\n配置\n简单起见，这次我们使用本地文件的配置方式。如下是关键的配置：\nhttp_filters: - name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config library_id: example library_path: /etc/envoy/libgolang.so plugin_name: basic-auth plugin_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/xds.type.v3.TypedStruct value: username: \u0026amp;quot;foo\u0026amp;quot; password: \u0026amp;quot;bar\u0026amp;quot; 这里我们配置了用户名密码：foo:bar。\n预告一下，下一篇我们会体验通过 Istio 来推送配置，体会一番动态更新配置的全流程。\n测试\n编译，运行，跟上篇一样，我们还是使用 Envoy 官方提供的镜像即可。\n跑起来之后，我们测试一下：\n$ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; HTTP/1.1 401 Unauthorized # invalid username:password $ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;Authorization: basic invalid\u0026#39; HTTP/1.1 401 Unauthorized # valid foo:bar $ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39; HTTP/1.1 200 OK 是不是很简单呢，一个标准的 Basic Auth 扩展就完成了。\n总结\nEnvoy 是面向云原生的架构设计，提供了配置动态变更的机制，Go 扩展可以从 Envoy 接受配置，也就意味着 Go 扩展也可以很好的利用这套机制。\nGo 扩展的开发者，不需要关心配置的动态更新，只需要解析配置即可，非常的方便~\n下一篇我们会介绍，配合 Istio 来动态更新用户名密码，体验一番云原生的配置变更体验。\n后续还有更多 Golang 扩展的特性介绍，原理解析，以及，更上层的 MOSN 集成体验，欢迎持续关注。\n[1]example-basic-auth： …","date":1681801200,"description":"MoE 系列（二）｜Golang 扩展从 Envoy 接收配置","dir":"blog/moe-series (2)｜golang-extensions-receive-configuration-from-envoy/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1681801200,"objectID":"f19954b7d5ae3122eec6e6599e9d1be2","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","publishdate":"2023-04-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 1445 字 阅读 5 分钟 上一篇我","tags":["SOFAStack"],"title":"MoE 系列（二）｜Golang 扩展从 Envoy 接收配置","type":"blog","url":"/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","wordcount":1147},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFA 五周年，Live Long and Prosper！\n 活动时间：04 月 15 日 12:00\u0026amp;ndash;17:00\n 活动形式：线下 Meetup + 线上直播\n 资料下载：\n 《SOFAStack 的下一个五年》\n《京东搜索基于Service Mesh的微服务治理探索与实践》\n《顺丰应用运行时落地实践》\n《Seata发展之路——昨天、今天、明天》\n《蚂蚁注册中心建设的思考与实践》\n B 站直播间地址：http://live.bilibili.com/21954520 介绍 2018 年 4 月 19 日，我们在北京启程，伴随种下希望的种子，举办了 SOFAStack 社区的第一个开放日。\n转眼来到 2023 年，瑞兔送福又逢春暖花开，怀揣着新的愿景，我们于 4 月 15 日回到北京庆祝 SOFA 的五岁生日。🎂\n今年的主题「Live Long and Prosper」相信对于不少“星际迷航”粉丝来说都已经耳熟能详了。这是瓦肯人在举瓦肯手礼的时候会说的祝词，却也非常符合 SOFAStack 开源社区的愿景。\n我们希望无论是 SOFAStack 社区项目，还是 SOFA 的生态伙伴，都能够“Live Long and Prosper”！👽\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 宋顺（花名：齐天），SOFAStack 社区开源负责人\n 王志龙，京东集团架构师、MOSN Contributor\n 杨定朝，顺丰集团高级研发工程师、Layotto 用户\n 李宗杰（花名：白鹰），Seata 蚂蚁开源负责人\n 肖健（花名：昱恒），SOFARegistry Maintainer\n 议程 直播回放 https://www.bilibili.com/video/BV1vL411e78B/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1681542000,"description":"2023 年 4 月 15 日，我们在北京一起庆祝了 SOFA 社区的五岁生日。","dir":"activities/sofa-anniversary-5/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3e1d3b14932e3e3e091b5cbce4868d80","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-anniversary-5/","publishdate":"2023-04-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-anniversary-5/","summary":"概要 活动主题：SOFA 五周年，Live Long and Prosper！ 活动时间：04 月 15 日 12:00\u0026ndash;17:00 活动形式：线下 Meetup + 线上直播 资料下载： 《SOFAStack 的下","tags":["SOFAStack","开源五周年"],"title":"SOFA 五周年，Live Long and Prosper！","type":"activities","url":"/sofastack.tech/activities/sofa-anniversary-5/","wordcount":633},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n**1.@SOFAJRaft **#965 提问：\n@a364176773\n RheaKV 中的 RocksDB 为何不支持选择其他压缩方式和压缩风格？\n貌似可以靠StorageOptionsFactory.registerRocksDBOptions注册进去，这样就不会走 default 了？\n A：是的，可以设置自己的选项。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/965\n2.@SOFARPC#1320\n@Misakami\n Spring Boot 3.1 + JDK 17 SOFARPC 显示发布成功但是客户端获取不到服务。\n A：看上去获取不到服务和 JDK17 并没有直接的联系。可以先确认:\n 服务端是否将自身地址发布到注册中心；\n 客户端是否接收到注册中心的推送。\n 「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1320\n本周推荐阅读\n缘起｜蚂蚁应用级服务发现的实践之路\nSOFARegistry | 聊一聊服务发现的数据一致性\nGo 语言，如何做逆向类型推导\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n","date":1681455600,"description":"SOFA Weekly｜SOFA 开源五周年来自社区家人的祝福、社区本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230414/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4e553c30969c289fec68bf7f78424e0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230414/","publishdate":"2023-04-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230414/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 开源五周年来自社区家人的祝福、社区本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230414/","wordcount":657},{"author":null,"categories":"SOFAStack","content":"文｜肖健（花名：昱恒）\n蚂蚁集团技术专家、SOFARegistry Maintainer\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。\n本文 8339 字 阅读 15 分钟\nPART. 1\n前言\n什么是服务发现？\n我们今天主要聊的话题是“应用级服务发现”的实践，聊这个话题之前，我们先简单介绍一下什么是“服务发现”，然后再聊聊，为什么需要“应用级服务发现”。\n在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信，而这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\n图 1（点击图片查看大图）\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑了蚂蚁庞大的服务集群，具有分布式可支撑海量数据、可云原生部署、推送延迟低、高可用等特点。\nPART. 2\n应用级服务发现的设想\n介绍完什么是服务发现之后，我们来看看什么是“接口级服务发现”，以及与之相对应的“应用级服务发现”。\n从 RPC 框架说起\n根据上述描述，我们先看看业界常用的 RPC 框架，是如何进行服务的发布和订阅的。以 SOFARPC 编程界面为例：\n｜服务发布\npackage com.alipay.rpc.sample; @SofaService(interfaceType = FooService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class FooServiceImpl implements FooService { @Override public String foo(String string) { return string; } } @SofaService(interfaceType = BarService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class BarServiceImpl implements BarService { @Override public String bar(String string) { return string; } } ｜服务使用\n@Service public class SampleClientImpl { @SofaReference(interfaceType = FooService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private FooService fooService; @SofaReference(interfaceType = BarService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private BarService barService; public String foo(String str) { return fooService.foo(str); } public String bar(String str) { return barService.bar(str); } } 上述两个编程界面，完成了两个服务 FooService 和 BarService 的发布、订阅、调用。\n微服务面临的挑战\n上述的服务发布、订阅、调用功能，离不开注册中心的服务发现提供准确的服务地址。将图 1 的服务发现场景进一步展开，此时的工作原理如下图：\n图 2（点击图片查看大图）\n服务发布者\n- 集群内部署了 100 个 pod，IP 分别为：1.1.1.1 ~ 1.1.1.100；\n- 服务发布者的 URL：1.1.1.1:12200?app=applicationB\u0026amp;amp;_SERIALIZETYPE=hessian2\u0026amp;amp;_TIMEOUT=3000\u0026amp;amp;zone=zone1\u0026amp;amp;version=1\u0026amp;amp;_WARMUPTIME=0，12200 端口为 sofarpc-bolt 协议默认的端口。\n服务订阅者：集群内部署了 100 个 pod，IP 分别为：2.1.1.1 ~ 2.1.1.100。\n基于上述的集群部署情况，我们来看看微服务的场景面临的挑战。\n｜挑战 1：注册中心 publisher 存储的挑战\n在上面的集群部署中，可以看到注册中心的数据存储模型，集群内部署了 100 个 provider pod，每个 provider 发布了 2 个服务，即每个 pod 有 2 个 publisher，以 provider1 为例：\n如果在每个 provider 提供更多服务的情况下呢？比如每个 provider 提供了 50 个服务，这样的量级在微服务场景中并不少见，那么此时注册中心对于 provider1，就需要存储 50 个 publisher，分别是：\n可以看到，随着 provider 的扩容，注册中心存储的 publisher 数据量是以 50 倍于 provider 的速度在增长。\n如果您对 SOFARegistry 有过了解，就会知道 SOFARegistry 是支持数据存储分片，可以存储海量数据的。\n但是数据量上涨带来的是 SOFARegistry 本身的服务器数量增涨，如果我们有办法可以降低 SOFARegistry 的数据存储量，那么就能节约 SOFARegistry 本身的服务器成本，同时 SOFARegistry 整个集群的稳定性也会得到提升。\n｜挑战 2：注册中心 subscriber 存储的挑战\n在上述的集群部署中，集群内部署了 100 个 consumer pod，每个 consumer 订阅了 2 个服务，即每个 pod 有 2 个 subscriber，同理于 publisher 的存储挑战，随着 consumer 订阅的接口持续增加，例如 consumer 订阅了 provider 的 10 个 service，此时注册中心存储 consumer1 的 10 个 subscriber 如下：\n随着 consumer 的扩容，注册中心内的 subscriber 存储同样面临着挑战。\n｜挑战 3：服务变更通知的挑战\n随着 publisher 和 subscriber 数量增长，除了对存储的挑战以外，对于数据变更通知同样面临着极大的挑战，让我们来看看如下的场景：provider 下线了 1 台，从 100 台减少到了 99 台，次数集群内发生了哪些变化呢？\n1、首先是在注册中心存储方面，需要将 provide 50 个 service …","date":1681196400,"description":"缘起｜蚂蚁应用级服务发现的实践之路","dir":"blog/origins｜ant's-practical-path-to-application-level-service-discovery/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1681196400,"objectID":"961f22ae0d2c39d1338da028adc43cbb","permalink":"https://sofastack.github.io/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","publishdate":"2023-04-11T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家、SOFARegistry Maintainer 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。 本文 8339 字 阅","tags":["SOFAStack"],"title":"缘起｜蚂蚁应用级服务发现的实践之路","type":"blog","url":"/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","wordcount":3973},{"author":"肖健","categories":["SOFARegistry"],"content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家、SOFARegistry Maintainer\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。\n本文 8339 字阅读 15分钟\nPART. 1\n前言 什么是服务发现？ 我们今天主要聊的话题是“应用级服务发现”的实践，聊这个话题之前，我们先简单介绍一下什么是“服务发现”，然后再聊聊，为什么需要“应用级服务发现”。\n在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信，而这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\n图 1\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑了蚂蚁庞大的服务集群，具有分布式可支撑海量数据、可云原生部署、推送延迟低、高可用等特点。\nPART. 2\n应用级服务发现的设想 介绍完什么是服务发现之后，我们来看看什么是“接口级服务发现”，以及与之相对应的“应用级服务发现”。\n从 RPC 框架说起 根据上述描述，我们先看看业界常用的 RPC 框架，是如何进行服务的发布和订阅的。以 SOFARPC 编程界面[1]为例：\n服务发布 package com.alipay.rpc.sample; @SofaService(interfaceType = FooService.class, bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class FooServiceImpl implements FooService { @Override public String foo(String string) { return string; } } @SofaService(interfaceType = BarService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class BarServiceImpl implements BarService { @Override public String bar(String string) { return string; } } 服务使用 @Service public class SampleClientImpl { @SofaReference(interfaceType = FooService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private FooService fooService; @SofaReference(interfaceType = BarService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private BarService barService; public String foo(String str) { return fooService.foo(str); } public String bar(String str) { return barService.bar(str); } } 上述两个编程界面，完成了两个服务 FooService 和 BarService 的发布、订阅、调用。\n微服务面临的挑战 上述的服务发布、订阅、调用功能，离不开注册中心的服务发现提供准确的服务地址。将图 1 的服务发现场景进一步展开，此时的工作原理如下图：\n图 2（点击图片查看大图）\n服务发布者：\n- 集群内部署了 100 个 pod，IP 分别为：1.1.1.1 ~ 1.1.1.100；\n- 服务发布者的 URL：1.1.1.1:12200?app=applicationB\u0026amp;amp;_SERIALIZETYPE=hessian2\u0026amp;amp;_TIMEOUT=3000\u0026amp;amp;zone=zone1\u0026amp;amp;version=1\u0026amp;amp;_WARMUPTIME=0，12200 端口为 sofarpc-bolt 协议默认的端口。\n服务订阅者：集群内部署了 100 个 pod，IP 分别为：2.1.1.1 ~ 2.1.1.100。\n基于上述的集群部署情况，我们来看看微服务的场景面临的挑战。\n挑战 1：注册中心 publisher 存储的挑战 在上面的集群部署中，可以看到注册中心的数据存储模型，集群内部署了 100 个 provider pod，每个 provider 发布了 2 个服务，即每个 pod 有 2 个 publisher，以 provider1 为例：\n如果在每个 provider 提供更多服务的情况下呢？比如每个 provider 提供了 50 个服务，这样的量级在微服务场景中并不少见，那么此时注册中心对于 provider1，就需要存储 50 个 publisher，分别是：\n可以看到，随着 provider 的扩容，注册中心存储的 publisher 数据量是以 50 倍于 provider 的速度在增长。\n如果您对 SOFARegistry 有过了解，就会知道 SOFARegistry 是支持数据存储分片，可以存储海量数据的。\n但是数据量上涨带来的是 SOFARegistry 本身的服务器数量增涨，如果我们有办法可以降低 SOFARegistry 的数据存储量，那么就能节约 SOFARegistry 本身的服务器成本，同时 SOFARegistry 整个集群的稳定性也会得到提升。\n挑战 2：注册中心 subscriber 存储的挑战 在上述的集群部署中，集群内部署了 100 个 consumer pod，每个 consumer 订阅了 2 个服务，即每个 pod 有 2 个 subscriber，同理于 publisher 的存储挑战，随着 consumer 订阅的接口持续增加，例如 consumer 订阅了 provider 的 10 个 service，此时注册中心存储 consumer1 的 10 个 subscriber 如下：\n随着 consumer 的扩容，注册中心内的 subscriber 存储同样面临着挑战。\n挑战 3：服务变更通知的挑战 随着 publisher 和 subscriber 数量增长，除了对存储的挑战以外，对于数据变更通知同样面临着极大的挑战，让我们来看看如下的场景：provider 下线了 1 台，从 100 台减少到了 99 台，次数集群内发生了哪些变化呢？\n1、首先是在注册中心存储方面，需要将 provide 50 个 service 中的 publishers 列表都减 …","date":1681196400,"description":"缘起｜蚂蚁应用级服务发现的实践之路","dir":"projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c9a51341a37418edfd01dc26b64f56e4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","publishdate":"2023-04-11T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家、SOFARegistry Maintainer 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。 本文 8339 字阅","tags":["SOFAStack","SOFARegistry"],"title":"缘起｜蚂蚁应用级服务发现的实践之路","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","wordcount":4116},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 会议预告\nLayotto：\n主题：Layotto 2023-04-12 社区会议\n时间：4 月 12 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2344343024\n议题：\n- 2023开源之夏-课题/导师招募 #894；\n- Discussion: 自建各种 Component #902；\n- 希望 layotto 提供高性能的通信交互能力 #867。\n「Layotto」：\nhttps://github.com/mosn/layotto/issues/907\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@LSQGUANLIVV #1322\n 从 sofa2.3.5 升级到 3.6.3 的时候，启动应用报错，如下图所示。\n 按照报错的点去找发现是 applicationContext 为 null，这里是需要新增加什么配置吗？还是原来的什么地方需要改呢？\n A：有可能是 sofa-boot / sofa-rpc-starter / sofa-rpc 这三个包的兼容性问题。升级了 sofa-rpc，需要同时升级这三个包。可以通过 pom 依赖看下是否有版本冲突。\n 是用的 sofaboot-enterprise-dependencies 的父依赖的默认的，这个也会冲突吗？\n A：使用默认的一般不会有问题，担心有些配置把默认配置覆盖了。另外商业版需要咨询商业版客服，开源社区这边能提供的帮助有限。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1322\n2.@hanzhihua #956\n readCommittedUserLog 可能获得不到刚写入的数据。我在做 NodeTest 测试过程中，在测试 readCommittedUserLog 方法中，出现了错误。\n 我发现主要是日志写入后，但 lastAppliedIndex 没有原子级别更新，造成了读取不到错误。\n A：因为onApply中是可以回滚的，所以没法去实时更新 lastAppliedIndex，只有确认这一批次没有回滚或者回滚的正确 log index，才能去更新。如果你需要在onApply过程中去 commit，可以调用日志迭代器的Iterator#commit方法，将当前 apply 的 log index 确认提交。然后就可以调用readCommittedUserLog确保可以读取到，代价就是无法回滚到 commit 之前的位置了。\n 问一下，onApply 回滚是什么意思，是指状态机 apply 发生异常，还是获取日志为 null，另外怎么回滚呢？\n A：这个方法：\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/956\n本周推荐阅读\n《MoE 系列（一）｜如何使用 Golang 扩展 Envoy》\n《SOFAJRaft 在同程旅游中的实践》\n《Tongsuo/铜锁｜「开放原子开源基金会」拜访篇》\n《如何看待 Dapr、Layotto 这种多运行时架构？》\n","date":1680850800,"description":"SOFA Weekly｜SOFA 开源五周年活动报名、Layotto 会议预告、社区本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230407/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5deb7a12ba899d85e14ea36b8d21dec4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230407/","publishdate":"2023-04-07T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230407/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 开源五周年活动报名、Layotto 会议预告、社区本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230407/","wordcount":1357},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区会议 SOFAArk 背景：SOFAArk 在社区开源将近 5 年，从最初的一个类隔离框架，逐步演进为支持合并部署与热部署的 “Serverless” 运行时框架。尤其在去年我们完成了 SOFAArk 1.0 到 2.0 架构的演进，在蚂蚁也基于 SOFAArk 2.0 完成了 Serverless 研发模式初步的规模化落地。\n主题：SOFAArk 社区化运作方式 KO（暨第一次月会） 时间：4 月 3 日（下周一）20:00 入会口令（钉钉）：683 550 26227 电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆） 入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题： - SOFAArk 社区化运作计划同步与讨论； - 版本维护策略公告； - 项目 CY23 开源规划（含新人培养计划）； - 本次月会 issue 讨论。\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。\n「SOFAArk」：\nhttps://github.com/sofastack/sofa-ark/issues/635\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@Misakami #1321\n 请问 sofa-rpc 有支持 jdk 17 的计划么？现在虽然能正常使用，但是需要在启动参数加上 \u0026amp;ndash;add-opens java.base/java.lang=ALL-UNNAMED。\n A：有的，近期也正在做兼容 jdk 17 的开发。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1321\n2.@googlefan #939\n jraft-spring-boot-starter || NodeManager 设计目的的作用? 看到 jraft-core 有提供 NodeManage.nodeMap 这个针对 Node 节点进行管理的实例，我以为可以通过 NodeManage.nodeMap 来获取所有集群节点的 RPC 服务，如果是这样的话，这个类的设计的目的是?\n A：NodeManager 是 jraft 内部为了实现单个进程内多个 raft group 共享同一个网络端口设计的，不是给集成着或者用户使用的。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/939\n本周推荐阅读 应用运行时 Layotto 进入 CNCF 云原生全景图\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1680246000,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230331/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a01ecd144b06b6b3399f4474a92ab677","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230331/","publishdate":"2023-03-31T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230331/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230331/","wordcount":1071},{"author":null,"categories":"SOFAStack","content":"本文作为 MoE 系列第一篇，主要介绍用 Golang 扩展 Envoy 的极速开发体验。\n一、背景\nMoE*（MOSN on Envoy）*是 MOSN 团队提出的技术架构，经过近两年的发展，在蚂蚁内部已经得到了很好的验证；并且去年我们也将底层的 Envoy Go 七层扩展贡献了 Envoy 官方，MOSN 也初步支持了使用 Envoy 作为网络底座的能力。\n借此准备写一系列的文章，逐一介绍这里面的技术。本文作为开篇，将重点介绍 MoE 中的基础技术，Envoy Go 扩展。\n二、FAQ\n开始前，先给大家解答下几个基本的问题：\n 1、MoE 与 Envoy Go 扩展有什么区别？\n A：MoE 是技术架构，Envoy Go 扩展是连接 MOSN 和 Envoy 的基础技术。\n 2、Envoy Go 扩展，与用 Go 来编译 Wasm 有什么区别？\n A：Envoy Go 支持 Go 语言的所有特性，包括 Goroutine；Go Wasm 则只能使用少量的 Go 语言特性，尤其是没有 Goroutine 的支持。\n 3、Go 是静态链接到 Envoy 么？\n A：不是的，Go 扩展编译成为 so，Envoy 动态加载 so，不需要重新编译 Envoy\n 4、Envoy Go 支持流式处理么？\n A：支持的。\n由于 Go 扩展提供的是底层的 API，非常的灵活，使用上相对会稍微复杂一些；如果只想简单的使用，可以使用 MOSN 的 filter，后面我们也会介绍。\n三、需求\n我们先实现一个小需求，来实际体会一下：\n对请求需要进行验签，大致是从 URI 上的某些参数，以及私钥计算一个 token，然后和 header 中的 token 进行对比，对不上就返回 403。\n很简单的需求，仅仅作为示例，主要是体验一下过程。\n四、代码实现\n完整的代码可以看 envoy-go-filter-example[1] 这个仓库，这里摘录最核心的两个函数：\nconst secretKey = \u0026amp;quot;secret\u0026amp;quot; func verify(header api.RequestHeaderMap) (bool, string) { token, ok := header.Get(\u0026amp;quot;token\u0026amp;quot;) if ok { return false, \u0026amp;quot;missing token\u0026amp;quot; } path, _ := header.Get(\u0026amp;quot;:path\u0026amp;quot;) hash := md5.Sum([]byte(path + secretKey)) if hex.EncodeToString(hash[:]) != token { return false, \u0026amp;quot;invalid token\u0026amp;quot; } return true, \u0026amp;quot;\u0026amp;quot; } func (f *filter) DecodeHeaders(header api.RequestHeaderMap, endStream bool) api.StatusType { if ok, msg := verify(header); !ok { f.callbacks.SendLocalReply(403, msg, map[string]string{}, 0, \u0026amp;quot;bad-request\u0026amp;quot;) return api.LocalReply } return api.Continue } DecodeHeaders 是扩展 filter 必须实现的方法，我们就是在这个阶段对请求 header 进行校验。\nverify 是校验函数，这里的 RequestHeaderMap 是 Go 扩展提供的 interface，我们可以通过它来读写 header，其他都是常见的 Go 代码写法。\n五、编译\n编译很简单，与常见的 Go 编译一样，这里我们使用 Golang 官方的 docker 镜像来编译：\ndocker run --rm -v `pwd`:/go/src/go-filter -w /go/src/go-filter \\ -e GOPROXY=https://goproxy.cn \\ golang:1.19 \\ go build -v -o libgolang.so -buildmode=c-shared . Go 编译还是很快的，只需要几秒钟，当前目录下，就会产生一个 libgolang.so 的文件。反观 Envoy 的编译速度，一次全量编译动辄几十分钟，或者上小时的，这幸福感提升了不止一个档次。🥰\n六、运行\n我们可以使用 Envoy 官方提供的镜像来运行，如下示例：\ndocker run --rm -v `pwd`/envoy.yaml:/etc/envoy/envoy.yaml \\ -v `pwd`/libgolang.so:/etc/envoy/libgolang.so \\ -p 10000:10000 \\ envoyproxy/envoy:contrib-dev \\ envoy -c /etc/envoy/envoy.yaml 只需要把上一步编译的 libgolang.so 和 envoy.yaml 挂载进去就可以了。\n值得一提的是，我们需要在 envoy.yaml 配置中启用 Go 扩展，具体是这段配置：\nhttp_filters: - name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config library_id: example library_path: /etc/envoy/libgolang.so plugin_name: example-1 跑起来之后，我们测试一下：\n$ curl \u0026#39;http://localhost:10000/\u0026#39; missing token $ curl -s \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;token: c64319d06364528120a9f96af62ea83d\u0026#39; -I HTTP/1.1 200 OK 符合期望，是不是很简单呢？\n七、后续\n什么？这个示例太简单？\n是的，这里主要是体验下开发流程，下篇我们将再介绍更高级的玩法：\nGo 接受来自 Envoy 侧的配置、异步 Goroutine，以及与 Istio 配合的用法。\n｜相关链接｜\n[1]envoy-go-filter-example 仓库：\nhttps://github.com/doujiang24/envoy-go-filter-example/tree/master/example-1\n了解更多…\nMOSN Star 一下✨： https://github.com/mosn/mosn\n","date":1679986800,"description":"MoE 系列（一）｜如何使用 Golang 扩展 Envoy","dir":"blog/moe-series (1)|how-to-extend-envoy-with-golang/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e45d3681cf3bc1ea80ee4b37621b372a","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","publishdate":"2023-03-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","summary":"本文作为 MoE 系列第一篇，主要介绍用 Golang 扩展 Envoy 的极速开发体验。 一、背景 MoE*（MOSN on Envoy）*是 MOSN 团队提出的技术架构，经过近两年的发展，","tags":["SOFAStack"],"title":"MoE 系列（一）｜如何使用 Golang 扩展 Envoy","type":"blog","url":"/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","wordcount":1163},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区会议 Layotto 主题：Layotto 社区会议 时间：3 月 29 号（下周三）下午 14 点 钉钉会议令：688 824 34655 电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆） 钉钉入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2316789049\n议题： - 2023 开源之夏-课题/导师招募 #894 - Discussion: 自建各种 Component #902 - 希望 Layotto 提供高性能的通信交互能力 #867\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。 想要参加社区建设的同学可以关注社区的新手任务列表，总有一个适合你。\n「Layotto」：\nhttps://github.com/mosn/layotto/issues/907\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@kunple-w #916\n SpringBoot 2.2 废弃了 logging.path，2.3 已删除该属性，应使用 logging.file.pat。 Steps to reproduce the behavior： - 使用 SOFA 3.10.0，按照 SOFA guides 配置 logging.path，启动后并没有出现文档中的一些日志文件。 - 降级为 sample 中的 3.2.0 版本，日志文件出现。 截图如下（2个属性同时配置）: A：SOFA 中间件中使用 sofa-common-tools 打印的日志，日志空间和 SOFABoot 应用程序是隔离的。因此可以同时使用 logging.path 以及 logging.file.path 属性分别定义 SOFA 中间件和 SOFABoot 应用程序的日志路径。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n2.@shuangchengsun #263\n 客户端的上下线，Client1 处于下线过程，此时 Client1 在路由表中的状态是如何维护的？ A：data 上有一个定时器去维护每个 Session 相关数据的，如果 Session 挂了，data 大约 30s 后把挂掉的 Session 的数据清理掉，同时链接挂掉的 Session 上的的 Client（除掉了下的 Client） 会自动重新连接到其他 Session 上，然后会把数据增加一个版本重新注册到 Session 上，Session 会再发到那台数据上。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/issues/263\n本周推荐阅读 应用运行时 Layotto 进入 CNCF 云原生全景图\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1679641200,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230324/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"84510ab87fdbaaab0b53efb84b3e8d41","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230324/","publishdate":"2023-03-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230324/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230324/","wordcount":1242},{"author":null,"categories":"SOFAStack","content":"文｜黄逸炀\nDragonfly Maintainer\n字节跳动火山引擎软件工程师\n专注于镜像存储及镜像 P2P 分发\nPART. 0\n背景\n火山引擎镜像仓库 CR 使用 TOS 来存储容器镜像。目前在一定程度上能满足并发大规模的镜像拉取。然而最终拉取的并发量受限于 TOS 的带宽和 QPS。\n这里简单介绍一下目前针对于大规模拉镜像遇到的两个场景的问题：\n1、客户端数量越来越多，镜像越来越大，TOS 带宽最终无法满足需求。 2、如果客户端使用了 Nydus 对镜像格式做转换之后，对 TOS 的请求量会有数量级的增加，TOS API 的 QPS 限制导致无法满足需求。\n不论是镜像仓库服务本身还是背后的存储，最终肯定是有带宽和 QPS 限制的。如果单纯依赖服务端提供的带宽和 QPS，很容易就无法满足需求。因此需要引入 P2P ，减轻服务端压力，进而满足大规模并发拉取镜像的需求。\nPART. 1\n基于 P2P 技术镜像分发系统调研\n目前开源社区有几个 P2P 项目，这里对这些项目进行简单介绍。\nDragonfly\n架构图\n术语\nManager\n1、存储动态配置供 Seed Peer 集群、Scheduler 集群以及 Dfdaemon 消费。\n2、维护 Seed Peer 集群和 Scheduler 集群之间关联关系。\n3、提供统一异步任务管理，用作预热等功能。\n4、监听各模块是否健康运行。\n5、为 Dfdaemon 筛选最优 Scheduler 集群调度使用。\n6、提供可视化控制台，方便用户操作管理 P2P 集群。\nScheduler\n1、基于机器学习的多场景自适应智能 P2P 节点调度, 为当前下载节点选择最优父节点。\n2、构建 P2P 下载网络的有向无环图。\n3、根据不同特征值评估节点下载能力, 剔除异常节点。\n4、当下载失败情况，主动通知 Dfdaemon 进行回源下载。\nDfdaemon\n1、基于 gRPC 提供下载功能, 并提供多源适配能力。\n2、开启 Seed Peer 模式可以作为 P2P 集群中回源下载节点, 也就是整个集群中下载的根节点。\n3、为镜像仓库或者其他 HTTP 下载任务提供代理服务。\n4、下载任务基于 HTTP 或 HTTPS 或其他自定义协议。\nKraken\n架构图\n术语\nAgent\n1、是 P2P 网络中的对等节点，需要在每个节点上部署。\n2、实现了 Docker Registry interface。\n3、通知 tracker 自己拥有的数据。\n4、下载其他 agent 的数据（tracker 会告诉该 agent 需要下载这块数据需要到哪个 agent 上下载）\nOrigin\n1、负责从存储中读取数据做种。\n2、支持不同的存储。\n3、通过 Hash 环的形式保证高可用。\nTracker\n1、P2P 网络中的协调者，追踪谁是 Peer，谁是 Seeder。\n2、追踪 Peer 拥有的数据。\n3、提供有序的 Peer 节点供 Peer 下载数据。\n4、通过 Hash 环的形式保证高可用。\nProxy\n1、实现了 Docker Registry Interface。\n2、将镜像层传给 Origin 组件。\n3、将 Tag 传给 BUILD INDEX 组件。\nBuild-Index\n1、Tag 和 digest 映射，agent 下载对应 Tag 数据时向 Build-Index 获取对应的 Digest 值。\n2、集群之间镜像复制。\n3、保存 Tag 数据在存储中。\n4、通过 Hash 环的形式保证高可用。\nDragonfly vs Kraken\nPART. 2\n方案\n在火山引擎上，主要考虑 VKE 和 VCI 通过 CR 拉取镜像。\n1、VKE 的产品特点是基于 ECS 部署的 K8S，因此十分适合每个节点部署 Dfdaemon，充分利用每个节点的带宽，进而充分利用 P2P 的能力。\n2、VCI 的产品特点是底层有一些资源很充足虚拟节点。上层的服务是以 POD 为载体，因此无法像 VKE 那样每个节点部署 Dfdaemon，所以部署的形式部署几个 Dfdaemon 作为缓存，利用缓存的能力。\n3、VKE 或 VCI 客户端拉取经过 Nydus 格式转化过的镜像。在该场景下，需要使用 Dfdaemon 作为缓存，不宜使用过多的节点，避免对 Scheduler 造成过大的调度压力。\n基于火山引擎对于以上产品的需求，以及结合 Dragonfly 的特点，需要设计一套兼容诸多因素的部署方案。部署 Dagonfly 的方案设计如下。\nPART. 3\n整体架构图\n1、火山引擎上的资源都是归属于主账号下。P2P 控制组件以主账号级别隔离，每个主账号下一套 P2P 控制组件。服务端实现 P2P Manager Controller，通过该 Controller 来管控控制面所有 P2P 控制组件。\n2、P2P 控制组件部署在镜像仓库数据面 VPC，通过 LB 与用户集群打通。\n3、在 VKE 集群上，Dfdaemon 以 DaemonSet 方式部署，每个节点上部署一个 Dfdaemon。\n4、在 VCI 上，Dfdaemon 以 Deployment 方式部署。\n5、ECS 上 Containerd 通过 127.0.0.1:65001 访问本节点上的 Dfdaemon。\n6、通过在用户集群部署一个 controller 组件，基于 PrivateZone 功能，在用户集群生成.p2p.volces.com 域名， controller 会根据一定的规则挑选特定节点*（包括 VKE、VCI）*的 Dfdaemon pod，以 A 记录的形式解析到上述域名。\n ECS 上 Nydusd 通过.p2p.volces.com 域名访问 Dfdaemon。 VCI 上镜像服务客户端和 Nydusd 通过.p2p.volces.com 域名访问 Dfdaemon。 PART. 4\n压测数据\n环境\n镜像仓库：带宽 10Gbit/s。\nECS: 4C8G，挂载本地盘，带宽 6Gbit/s。\n镜像\nNginx (500M)\nTensorFlow (3G)\n组件版本\nDragonfly v2.0.8。\nQuota\nDfdaemon: Limit 2C6G。\nScheduler: 2 Replicas，Request 1C2G，Limit 4C8G。\nManager: 2 Replicas，Request 1C2G，Limit 4C8G。\nPOD 启动时间对比\nNginx Pod 分别并发 50、100、200、500 的所有 Pod 从创建到启动消耗时间。\nTensorFlow Pod 分别并发 50、100、200、500 的所有 Pod 从创建到启动消耗时间。\n在大规模拉镜像的场景下，在使用 Dragonfly 和 Dragonfly \u0026amp;amp; Nydus 场景对比 OCIv1 场景能够节省 90% 以上的容器启动时间。使用 Nydus 之后启动时间更短是因为镜像 lazyload 的特性，只需要拉取很小的一部分元数据 Pod 就能启动。\n存储源端带宽峰值对比\nNginx Pod …","date":1679382000,"description":"火山引擎基于 Dragonfly 加速实践","dir":"blog/volcano-engine-based-on-dragonfly-acceleration-practices/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"21e4e09162503066e2909a462942331d","permalink":"https://sofastack.github.io/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","publishdate":"2023-03-21T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","summary":"文｜黄逸炀 Dragonfly Maintainer 字节跳动火山引擎软件工程师 专注于镜像存储及镜像 P2P 分发 PART. 0 背景 火山引擎镜像仓库 CR 使用 TOS 来存储容器镜像。目前在一定程度上能满足并发","tags":["SOFAStack"],"title":"火山引擎基于 Dragonfly 加速实践","type":"blog","url":"/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","wordcount":3113},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议\nMOSN\n主题：MOSN 2023 社区会议 时间：3 月 23 号（下周四）晚上 19 点 钉钉会议号：689 448 86753 电话呼入：+862759771614（中国大陆） 钉钉入会链接：https://meeting.dingtalk.com/j/vvE0uCA0vQT\n议题： 回顾 MOSN 去年进展及今年的规划。 邀请部分 MOSN 用户来分享落地经验、发展规划。 共商 MOSN 2023 发展大计。\n另外，还邀请了 Higress 社区来互动交流，探讨合作空间。 Service Mesh、Gateway、Envoy、Istio、ztunnel 等等大家关注的话题，也可以在这里交流。欢迎大家参会讨论~\n「 MOSN 」：https://github.com/mosn/mosn\nLayotto\n主题：Layotto 社区会议 时间：3 月 22 号（下周三）下午 14 点 钉钉会议令：688 824 34655 电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆） 钉钉入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2299840541\n议题： Discussion: 自建各种 Component #902 希望 Layotto 提供高性能的通信交互能力 #867\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。 想要参加社区建设的同学可以关注社区的新手任务列表，总有一个适合你。\n「Layotto」： https://github.com/mosn/layotto/issues/902 https://github.com/mosn/layotto/issues/867\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@LY1806620741 #1061\ncom.alipay.sofa.rpc.enable-swagger 在 3.16.3 是否已经废弃\n配置使用了 Objectway 的 asm，与 Springboot 的 asm 冲突。 另外，没有在 SOFABoot 文档上找到所有的属性说明。\n重现该行为的步骤：\n运动单 SOFABoot\n配置 com.alipay.sofa.rpc.enable-swagger=true\n启动并访问*http://localhost:8341/swagger/bolt/api *\ndebug 可以看到找不到 class objectway.classvisitor\n引入 asm.jar 后会与 sping 框架的 asm org.springframework.asm.ClassVisitor 冲突\nA：看起来是 https:/github.com/sofastack/sofa-rpc/blob/5.8.3.1/all/pom.xml 少添加了一个 asm 的依赖，导致出现上面的问题。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n2.@springcoco #589\n关于多部网站代码解析的一些疑问，在多网站这一章节，发现这样说： 我的疑惑是 Spring 是如何判定 ArkTomcatEmbeddedWebappClassLoader 类存在呢？ 在加载 ArkTomcatServletWebServerFactory 的时候，我发现也会加载 Tomcat 默认的 Server Factory，如何最终判定周 WebServer 使用 ArkWebServerFacticServletTomcat 使用 Ark。 A：ArkTomcatEmbeddedWebappClassLoader 作为一个判断条件，如果没有使用 web-ark-plugin，意味着没有 ArkTomcatEmbeddedWebappCl\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/589\nMOSN 1.0 发布，开启新架构演进\n社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析\nMOSN 反向通道详解\n蚂蚁集团境外站点 Seata 实践与探索\n","date":1679036400,"description":"SOFA Weekly | MOSN、Layotto 社区会议通知、Seata 版本发布","dir":"blog/sofa-weekly-230317/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1827a7e4749437ae2082098f18a52e18","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230317/","publishdate":"2023-03-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230317/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、Layotto 社区会议通知、Seata 版本发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230317/","wordcount":1402},{"author":null,"categories":"SOFAStack","content":" 发布概览 Seata-go 1.1.0 版本补齐了 AT 模式下对 Multi Delete、Multi Update、Insert on Update 和 Select for Update 的支持。至此 Seata-go 的 AT 模式与 Seata AT 模式全面对齐。\n此版本给出了在 Dubbo-go/Gin/gRPC 中使用 Seata-go TCC/AT 两种模式的示例。\n示例链接：https://github.com/seata/seata-go-samples/tree/main/at\nAT 模式:\n AT 模式支持并集成了 Multi Delete SQL 语法 AT 模式支持并集成了 Multi Update SQL 语法 AT 模式支持并集成了 Insert on Update SQL 语法 AT 模式支持并集成了 Select for Update SQL 语法 配置文件：\n完善了更多地方读取配置文件功能\n版本的主要更新如下 Feature： [#491] 支持查询全局事务锁 https://github.com/seata/seata-go/pull/491\n[#482] 支持 AT 模式 Multi Delete SQL 执行器 https://github.com/seata/seata-go/pull/482\n[#481] 支持 AT 模式 Multi Update SQL 执行器 https://github.com/seata/seata-go/pull/481\n[#478] 支持 AT 模式 Select for Update SQL 执行器 https://github.com/seata/seata-go/pull/478\n[#477] 支持 Undo Log 的 Json 序列化方式 https://github.com/seata/seata-go/pull/477\n[#456] 支持 AT 模式 Insert on Update SQL 执行器 https://github.com/seata/seata-go/pull/456\n[#444] 支持 BZip 压缩算法 https://github.com/seata/seata-go/pull/444\n[#436] 支持读取 RM 相关的配置文件 https://github.com/seata/seata-go/pull/436\n[#433] 支持 XA 连接管理器 https://github.com/seata/seata-go/pull/433\n[#430] 支持读取 Getty 相关的配置文件 https://github.com/seata/seata-go/pull/430\nBugfix：\n[#509] 修复 AT 模式下执行 Insert on Update 时 Undo Log 的 SQLType 字段的问题 https://github.com/seata/seata-go/pull/509\n[#495] 修复 Undo Log 的 SQLType 字段的问题 https://github.com/seata/seata-go/pull/495\n[#487] 修复 AT 执行时出现的问题 https://github.com/seata/seata-go/pull/487\n[#472] 修复全局事务中上下文丢失值问题 https://github.com/seata/seata-go/pull/472\n[#461] 修复 Error_Code_test 中变量未定义导致的 CI 失败问题 https://github.com/seata/seata-go/pull/461\n[#459] 修复 Error 日志重复打印问题 https://github.com/seata/seata-go/pull/459\n[#452] 修复 AT 模式执行 Insert SQL 时 ID 增的报错问题 https://github.com/seata/seata-go/pull/452\nOptimize：\nSeata-go 的示例项目已经全部迁移到新的仓库：https://github.com/seata/seata-go-samples\n[#507] 优化 AT 模式 Multiple Update SQL 执行器 https://github.com/seata/seata-go/pull/507\n[#505] 优化 AT 模式 Multi SQL 执行器 https://github.com/seata/seata-go/pull/505\n[#453] 优化 Message Type 和 Transaction error Code 枚举值 https://github.com/seata/seata-go/pull/453\n[#447] 优化数据源初始化流程 https://github.com/seata/seata-go/pull/447\n[#466] 优化变量的命名 https://github.com/seata/seata-go/pull/466\nTest:\n[#445] 添加 Transaction error Code 的单元测试 https://github.com/seata/seata-go/pull/445\nDoc:\n[#492] 更新 Readme 文件的已完成功能列表 https://github.com/seata/seata-go/pull/492\n[#489] 添加 1.1.0 版本的 Change Log https://github.com/seata/seata-go/pull/489\n英文版：https://github.com/seata/seata-go/releases/tag/v1.1.0\n致谢\n非常感谢以下 Contributors 的代码贡献。若有无意遗漏，请报告。\n@luky116 https://github.com/luky116\n@georgehao https://github.com/georgehao\n@lxfeng1997 https://github.com/lxfeng1997 @106umao https://github.com/106umao @wang1309 https://github.com/wang1309 @iSuperCoder https://github.com/iSuperCoder @Charlie17Li https://github.com/Charlie17Li @Code-Fight https://github.com/Code-Fight @Kirhaku https://github.com/Kirhaku @Vaderkai https://github.com/VaderKai @springrain https://github.com/springrain @Shaozhou Hu https://github.com/raspberry-hu …","date":1678777200,"description":"Seata-go 1.1.0 发布，补齐 AT 模式支持","dir":"blog/seata-go-1-1-0-released-completes-at-mode-support/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e92a21aaa50425c14c2a8462c1d96e2e","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","publishdate":"2023-03-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","summary":"发布概览 Seata-go 1.1.0 版本补齐了 AT 模式下对 Multi Delete、Multi Update、Insert on Update 和 Select for Update 的支持。至此 Seata-go 的 AT 模式与 Seata AT 模式全面对齐。 此","tags":["SOFAStack"],"title":"Seata-go 1.1.0 发布，补齐 AT 模式支持","type":"blog","url":"/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","wordcount":1353},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@linkoog #602\n 首先我使用了 Ark-Guides 和 Ark-biz 的示例进行操作。 可以正常加载模板，但配置文件加载不到。 Start 是启动模块， Config 是配置的存储释放模块。 试了下面两种方式，都读到不到配置文件 1、直接打包 Config 的 Jar 中 2、在 Start 模板下面放 Conf/Ark/ 环境 沙发方舟版本：2.0.8 JVM 版本（例如 Java -Version ）：1.8.333 操作系统版本（例如 Uname -a ）：macOS 行家版本： 集成开发环境版本\n A：配置文件的配置应和 Spring Boot 应用保持一致，建议把配置文件放至 Resources 目录下。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/602\n2.@SpringLin97 #928\n Jraft 支持 IPV6 组建集群吗？\n A：1.3.5 以后版本支持 IPV6。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/928\n本周推荐阅读 DLRover：蚂蚁开源大规模智能分布式训练系统\nNydus 在约苗平台的容器镜像加速实践\nWasm 原生时代已经来到\nGo 语言，如何做逆向类型推导?\n","date":1678431600,"description":"SOFA Weekly | SOFANews、开源人 \u0026 issue 精选","dir":"blog/sofa-weekly-20230310/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c8fb3a67d5797275149ca3410ab9631e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230310/","publishdate":"2023-03-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230310/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、开源人 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230310/","wordcount":684},{"author":null,"categories":"SOFAStack","content":" 文｜沙剑 蚂蚁集团高级技术专家 专注分布式深度学习领域 主要负责蚂蚁大规模分布式训练引擎的设计和开发\n 本文 4491 字 阅读 12 分钟\n本文整体介绍了 DLRover 的项目动机与核心能力，未来我们会发布一系列文章，来从同步/异步弹性训练，优化策略服务，多种集群和训练框架对接，策略定制开发等多个角度来介绍 DLRover 的更多细节，敬请期待。\n技术背景 2022 年 6 月，蚂蚁集团决定全面引入 ESG 框架，启动并确立了“数字普惠”、“绿色低碳”、“科技创新”、“开放生态”四位一体的可持续发展战略。针对“绿色低碳”，设立了 4 个子议题，包括绿色运营、科技助力产业碳中和、生态保护与修复绿色低碳生活。\n在此背景下，绿色 AI 也成为蚂蚁 AI Infra 团队的一个重要工作方向。作为绿色 AI 的重要板块，工程提效项目致力于打造高性能离在线 AI 工程体系，通过提升算力效率和资源利用率，最终达到节省资源降低碳排放的目的。\n当前，用户提交分布式训练作业的工具有 Yarn 或者 KubeFlow/Training-Operator。在提交作业时，用户需要在作业中指定作业资源，包括不同角色的节点数量和资源规格（CPU 核数、内存、GPU 等）。\n在训练作业提交后，作业可能遇到如下问题： - 集群资源不足以启动作业的所有节点，作业只能等待。 - 训练作业的节点可能会出错，比如被高优任务抢占、机器故障、IO 故障等，导致作业失败。\n出现这些问题后，用户只能修改作业资源来重新提交作业。\n针对这两个问题，蚂蚁集团早期基于 Kubernetes 开源了 ElasticDL 项目来支持 K8s 上 TF 2.x 分布式训练的弹性容错。在项目落地过程中我们又发现了如下问题： - 用户配置的资源可能过少引起 OOM 和训练性能差。 - 用户为了保障作业成功率和速度，通常会配置超额资源导致利用率低。 - 越来越多的用户使用 PyTorch 或其他 TF 之外的框架来开发和训练模型。 - 越来越多的分布式集群开始支持 AI 作业，比如 Ray、Spark 集群，能否适配任意计算集群？ - 在线学习越来越被广泛采用的情况下，如何运用一套系统同时解决兼容离在线训练？\n前两个问题使得集群 CPU 利用率通常只有 20% 上下，同时算法开发人员需要投入很多人工运维成本，为了解决训练端资源提效的需求，支持在不同集群上针对在离线多种训练模式，给不同框架的分布式训练作业自动地寻找最优资源配置。\n蚂蚁 AI Infra 团队基于 ElasticDL 弹性容错的思路，升级扩展并开源了 DLRover，其目标在于提升分布式模型训练的智能性，目前很多公司的训练作业都是跑在混部的集群中，运行环境复杂多变，正如其名，DLRover 作为分布式训练领域的 “路虎”，不管多么崎岖的地形，都可以轻松驾驭。\n整体方案 DLRover 提出了 “ML for System” 的理念来提升分布式训练的智能性，那么这样的系统应该具备哪些能力呢？\n我们认为主要体现在如下几个方面： - 解耦：不和底层训练框架耦合在一起，只依赖接口抽象，遵循依赖倒置原则。（*i.e. Elastic Runtime*） - 资源调度：具备上帝视角的资源调度管控能力。和建立在对作业精准画像的决策能力。 - 数据驱动：同时收集掌握集群资源数据，也掌握训练作业数据。以数据驱动智能。 - 作业交互：以对训练作业以及模型白盒化的理解，动态根据实际情况，对训练作业进行优化调整。超越简单机械的弹性容错！ - 智能：通过对集群以及作业信息的收集，结合算法模型+固定策略产出精准的作业优化策略。\n我们希望设计并实现一个系统，让用户完全摆脱资源配置的束缚，专注于模型训练本身。在没有任何资源配置输入的情况下，DLRover 仍然可以为每个训练作业提供最佳资源配置。考虑到用户可能会以不同的方式运行他们的训练作业，DLRover 除了面向训练平台进行作业统一管理的 Cluster Mode，也提供 Single-Job Mode 方便独立的算法开发者也能享受到弹性容错等基本特性。\n系统架构 DLRover 由四个主要组件组成：ElasticJob、Elastic Trainer、Brain 服务和 Cluster Monitor。\n上图显示了 DLRover 如何在 K8s 集群上管理深度学习训练作业。DLRover 以 ElasticJob CRD 的形式将作业提交到集群。收到 CRD 后，ElasticJob Operator 会拉起一个 Master Pod 作为 Elastic Trainer。其从 Brain 服务中获取初始资源计划。Elastic Trainer 用它来创建 Scale CRD，并应用 Scale CRD 通知 ElasticJob Controller 启动所需的 Pod，每个 Pod 将在其上启动一个 Elastic Agent。\n在训练过程中，Elastic Trainer 的 Training Master 将数据分片分发给 Worker。同时，Cluster Monitor 监控每个作业的运行状态（*i.e.每个节点的 Workload*）和集群状态（*i.e. 资源水位*）。这些数据将定期报告给 Brain，Brain 将数据持久化到数据库中。\n然后 DLRover Brain 根据作业的运行状态，选择合适的算法生成新的资源计划，并通知 Elastic Trainer 开始资源调整。\n总的来讲，DLRover 可以帮助分布式训练作业自动化运行在集群中，可以看作分布式作业的自动驾驶，模型开发者只需要关注模型的算法设计，DLRover 目前开源版则可以为用户提供如下能力： - 自动资源推导：帮助用户自动初始化训练资源，提升资源利用率与作业稳定性。 - 动态训练数据分片：针对不同 Worker 性能不通造成的木桶效应，根据实际消费速度分配训练数据，可配合 Failover 记录消费位点，数据不丢失。 - 单点容错：提供单点容错的能力，不需要完整重启作业。 - 资源弹性：支持运行时 Pod 级和 CPU/Memory 级的资源弹性扩缩容，动态全局优化决策。\nDLRover 能带来什么 1.作业零资源参数配置 用户提交分布式作业时无需提供任何资源信息，DLRover 会自动对作业进行画像，推导出最优的资源配置，同时运行时可以根据实际情况（*集群资源、样本流量、当前利用率、\u0026amp;hellip;*）自动对资源进行调整。下面展示了两种提交脚本的配置对比：\n2.单点容错提升作业稳定性与恢复效率 DLRover 支持单点恢复 Parameter Server 和 Worker 角色的失败退出而不需要整体作业重启，对于非用户代码和数据类型的错误可以实现用户无感的重启。例如集群中，很常见的一类错误是由于用户配置了不足的内存，导致训练 OOM。在 DLRover 的帮助下，我们可以自动拉起一个优化配置的节点来恢复失败的 Node。在真实环境下，DLRover 管理的训练作业，相比基线的 Kubeflow TF-Operator 作业，训练成功率从 84% 提升到了 95% 以上。 …","date":1678172400,"description":"DLRover：蚂蚁开源大规模智能分布式训练系统","dir":"blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d19aa2ffa0b2368819bac80add901dfb","permalink":"https://sofastack.github.io/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","publishdate":"2023-03-07T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","summary":"文｜沙剑 蚂蚁集团高级技术专家 专注分布式深度学习领域 主要负责蚂蚁大规模分布式训练引擎的设计和开发 本文 4491 字 阅读 12 分钟 本文整体介绍了 DLRover 的项目动机与","tags":["SOFAStack"],"title":"DLRover：蚂蚁开源大规模智能分布式训练系统","type":"blog","url":"/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","wordcount":3919},{"author":null,"categories":"SOFAStack","content":" SOFA Weekly｜铜锁探「密」、本周贡献 \u0026amp;amp; issue 精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@ZhengweiHou #1313\n 同一台机器启动两个 SOFA 进程，开启端口自适应（AdaptivePort），但是两个进程服务注册端口一致，但实际生效端口不一致。通过验证端口自适应逻辑发现我的机器上（ServerSocket.bind) 预期结果不一致。详细情况如图所示：\n A：AdaptivePort 的逻辑在 可以看下这块代码。\ncom.alipay.sofa.rpc.server.ServerFactory#resolveServerConfig\n和你理解的应该不太一样。\n「SOFARPC」: https://github.com/sofastack/sofa-rpc/issues/1313\n**2.@hanzhihua ** #934\n 咨询一个问题，Closure Threadpool 使用 SynchronousQueue 而不使用其他的有缓存的 Queue，是怎么考虑的呢？\n A：主要是原因是希望在任务量大 Core Thread 饱和的时候尽快新增线程来更快的处理任务，中间加一个 Queue 会影响到，Java Threadpool 的策略你懂的，需要 Queue 满了后 MaximumThreads 参数的值才发挥作用。\n「SOFAJRaft」： https://github.com/sofastack/sofa-jraft/issues/934\n3.@penglinzhang #612\n 静态合并部署时，为什么宿主应用会把子业务应用中的 Bean 也会扫描注册到自己的 ApplicationContext 中，而不是仅仅把子应用作为一个特殊 Jar 包？\n A：由于你的宿主应用 @ComPonentScan 扫描了 “com.alipay.sofa”，并且你的业务 Bean 也是 com/alipay/sofa 路径下的，你可以尝试将业务包 Spring-Boot-Ark-Biz 的路径改成自定义的。\n「SOFAArk」： https://github.com/sofastack/sofa-ark/issues/612\n本周推荐阅读\nSOFARegistry | 聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1677826800,"description":"","dir":"blog/sofa-weekly-20230303/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1b93b164611c557c53757d288b2e2d77","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230303/","publishdate":"2023-03-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230303/","summary":"SOFA Weekly｜铜锁探「密」、本周贡献 \u0026amp; issue 精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Sta","tags":["SOFAStack"],"title":"SOFA Weekly｜铜锁探「密」、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230303/","wordcount":802},{"author":null,"categories":"SOFAStack","content":" 文 | 向申 约苗平台运维工程师 关注云原生领域\n本文字数 9574 阅读时间 24 分钟\n 本文是来自向申同学的分享，介绍了其在 K8s 生产环境集群部署 Nydus 的相关实践。\nNydus 是蚂蚁集团，阿里云和字节等共建的开源容器镜像加速项目，是 CNCF Dragonfly 的子项目，Nydus 在 OCI Image Spec 基础上重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。详情文档请参考如下地址：\n Nydus 官方网站：https://nydus.dev/\n Nydus Github：https://github.com/dragonflyoss/image-service\n PART.1\n容器镜像的概念 1. 容器镜像 容器镜像有一个官方的类比，\u0026amp;rdquo;生活中常见的集装箱\u0026amp;rdquo;，虽然拥有不同的规格，但箱子本身是不可变的（*Immutable*），只是其中装的内容不同。\n对于镜像来说，不变的部分包含了运行一个应用软件（如 MySQL ）所需要的所有元素。开发者可以使用一些工具（*如 Dockerfile*）构建出自己的容器镜像，签名并上传到互联网上，然后需要运行这些软件的人可以通过指定名称（*如 example.com/my-app*）下载、验证和运行这些容器。\n2. OCI 标准镜像规范 在 OCI 标准镜像规范出台之前，其实有两套广泛使用的镜像规范，分别是 Appc 和 Docker v2.2，但“合久必分，分久必合”，有意思的是两者的内容已经在各自的发展中逐步同化了，所以 OCI 组织顺水推舟地在 Docker v2.2 的基础上推出了 OCI Image Format Spec，规定了对于符合规范的镜像，允许开发者只要对容器打包和签名一次，就可以在所有的容器引擎上运行该容器。\n这份规范给出了 OCI Image 的定义：\nThis specification defines an OCI Image, consisting of a manifest, an Image Index (optional), a set of filesystem layers, and a Configuration.\n3. 容器的工作流程 一个典型的容器工作流程是从由 Developers 制作容器镜像开始的（*Build*），然后上传到镜像存储中心（*Ship*），最后部署在集群中（*RUN*）。\nPART.2\nOCI 镜像格式 通常所说的镜像文件其实指的是一个包含了多个文件的“包”，“包”中的这些文件提供了启动一个容器所需要的所有需要信息，其中包括但不限于，容器所使用的文件系统等数据文件，镜像所适用的平台、数据完整性校验信息等配置文件。当我们使用 Docker pull 或者 Nerdctl pull 从镜像中心拉取镜像时，其实就是在依次拉取该镜像所包含的这些文件。\nNerdctl 依次拉取了一个 Index 文件、一个 Manifest 文件、一个 Config 文件和若干个 Layer 数据文件。实际上，一个标准的 OCI 镜像通常就是由这几部分构成的。\n其中，Layer 文件一般是 tar 包或者压缩后的 tar 包，其包含着镜像具体的数据文件。这些 Layer 文件会共同组成一个完整的文件系统（*也就是从该镜像启动容器后，进入容器中看到的文件系统*） 。\nConfig 文件是一个 JSON 文件。其中包含镜像的一些配置信息，比如镜像时间、修改记录、环境变量、镜像的启动命令等等。\nManifest 文件也是一个 JSON 文件。它可以看作是镜像文件的清单，即说明了该镜像包含了哪些 Layer 文件和哪个 Config 文件。\n下面是一个 Manifest 文件的典型例子：\n\u0026amp;quot;schemaVersion\u0026amp;quot;: 2, \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.manifest.v1+json\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.config.v1+json\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:0584b370e957bf9d09e10f424859a02ab0fda255103f75b3f8c7d410a4e96ed5\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 7636 }, \u0026amp;quot;layers\u0026amp;quot;: [ { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:214ca5fb90323fe769c63a12af092f2572bf1c6b300263e09883909fc865d260\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 31379476 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:50836501937ff210a4ee8eedcb17b49b3b7627c5b7104397b2a6198c569d9231\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 25338790 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:d838e0361e8efc1fb3ec2b7aed16ba935ee9b62b6631c304256b0326c048a330\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 600 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:fcc7a415e354b2e1a2fcf80005278d0439a2f87556e683bb98891414339f9bee\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 893 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: …","date":1677567600,"description":"Nydus 在约苗平台的容器镜像加速实践","dir":"blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7e9b91c041e413e6e7587da7c34f0e22","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","publishdate":"2023-02-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","summary":"文 | 向申 约苗平台运维工程师 关注云原生领域 本文字数 9574 阅读时间 24 分钟 本文是来自向申同学的分享，介绍了其在 K8s 生产环境集群部署 Nydus 的相关实践。 Nydus 是蚂蚁","tags":["SOFAStak"],"title":"Nydus 在约苗平台的容器镜像加速实践","type":"blog","url":"/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","wordcount":4215},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 4 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@linkoog #602\n SOFAArk 2.0 合并部署时，ark-biz 无法读取配置文件\n A：配置文件的配置应该和 Spring Boot 应用保持一致，建议把配置文件放置到 resources 目录下。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.@tdxafpdq #925\n 消息中间件业务场景下，如何使用 Snapshot 服务，以解决磁盘占用持续增长以及全量回放变慢。\n A：消息场景下，还是控制消息的总量，通过 TTL 等机制来及时删除过期的消息，如果是同步数据库的场景，可以使用 Snapshot 来做检查点（Checkpoint），Snapshot 本身可能只做一些数据库状态校验的动作，确保 Snapshot log index 之前的日志都已经同步复制完成，然后 JRaft 就可以释放之前的日志。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 SOFARegistry｜聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1676617200,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230217/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f937156cef65231cd51d07b5c8c4f9c7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230217/","publishdate":"2023-02-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230217/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230217/","wordcount":695},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区\n 活动时间：02 月 25 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：待直播后更新\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#32 你的开源入门指南——Kata Containers 社区 如今“参与开源”已然成为很多技术人追赶的浪潮。但有些人苦于找不到参加途径，有些人畏畏缩缩不敢发声，或者是由于开源项目众多，不知道该如何挑选\u0026amp;hellip;\u0026amp;hellip;在本期 SOFAChannel#32 的节目中，我们邀请到了 Kata Containers 社区新星姚胤楠同学，给大家带来开源入门指南！Kata Containers 是一种基于硬件虚拟化技术、兼容 OCI/CRI 等协议的容器运行时技术，可以完美地运行在 Kubernetes 集群之上。Kata Containers 比传统容器提供了更高的安全性和更强的隔离性，同时具备快速启动和部署的优势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 姚胤楠\n Kata Containers Contributor\n 议程 直播回放 待直播后更新\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1676530800,"description":"2023 年 02 月 25 日 19：00 - 20：00 ，线上直播第 32 期。","dir":"activities/sofa-channel-32/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7ece90c394a1f25d260f0d79aa6a80b0","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-32/","publishdate":"2023-02-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-32/","summary":"概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区 活动时间：02 月 25 日，周四晚 19 点 活动形式：线上直播 资料下载：待","tags":["SOFAChannel","Kata Containers","你的开源入门指南"],"title":"SOFAChannel#32 你的开源入门指南——Kata Containers 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-32/","wordcount":569},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区\n 活动时间：02 月 25 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：待直播后更新\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#32 你的开源入门指南——Kata Containers 社区 如今“参与开源”已然成为很多技术人追赶的浪潮。但有些人苦于找不到参加途径，有些人畏畏缩缩不敢发声，或者是由于开源项目众多，不知道该如何挑选\u0026amp;hellip;\u0026amp;hellip;在本期 SOFAChannel#32 的节目中，我们邀请到了 Kata Containers 社区新星姚胤楠同学，给大家带来开源入门指南！Kata Containers 是一种基于硬件虚拟化技术、兼容 OCI/CRI 等协议的容器运行时技术，可以完美地运行在 Kubernetes 集群之上。Kata Containers 比传统容器提供了更高的安全性和更强的隔离性，同时具备快速启动和部署的优势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 姚胤楠\n Kata Containers Contributor\n 议程 直播回放 待直播后更新\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1676444400,"description":"2023 年 02 月 16 日 19：00 - 20：00 ，线上直播第 32 期。","dir":"activities/sofachannel-32/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f529a5fffabf35600dcecdc9b513fe85","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofachannel-32/","publishdate":"2023-02-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofachannel-32/","summary":"概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区 活动时间：02 月 25 日，周四晚 19 点 活动形式：线上直播 资料下载：待","tags":["SOFAChannel","Kata Containers","你的开源入门指南"],"title":"SOFAChannel#32 你的开源入门指南——Kata Containers 社区","type":"activities","url":"/sofastack.tech/activities/sofachannel-32/","wordcount":569},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者蚂蚁集团技术专家\n专注于云原生网关研发的相关工作。\n本文 224 字 阅读 8 分钟\nPART. 1\n引言 在上回的文章《Go 内存泄漏，pprof 够用了么？》中说到，从一个 core 文件生成内存引用关系火焰图时，虽然可以从 core 文件中读到所有的内存对象，但是并不知道它们的类型信息。\n这是因为 Go 作为静态类型语言，在运行时，内存对象的类型是已知的。也就是说，并不需要想动态类型语言那样，为每个内存对象在内存中存储其类型信息 （有点例外的是 interface） 。\n比如这个 Go 语言例子：\ntype Foo struct { a uint64 b int64} func foo(f *Foo) int64 { return f.b} Foo 函数在使用 f 这个指针时，并不需要判断其类型，直接读一个带偏移量地址就能得到 f.b，也就是一条指令：mov rax, qword ptr [rax + 8]，就是这么简单直接。\n再看 Lua 语言这个例子：\nfunction foo(f) return f.bendfoo({ b = 1 }) Foo 函数在执行的时候，首先得判断 f 的类型，如果是 table，则按照 key 取 b 的值；如果不是，则抛运行时 error。\n能够运行时判断 f 的类型，是因为 Lua 中变量是用 TValue 来表示的，这个 TValue 结构中，就有一个信息用来存储变量类型。\nPART. 2\n逆向类型推导 逆向类型推导的逻辑是：根据已知内存的类型信息，推导被引用的内存对象的类型信息。\n比如这个例子：\ntype Foo struct { a uint64 b int64}type Bar struct { f *Foo}var b Bar 如果我们知道了 b 的类型是 Bar，那么 b 中第一个 field 指向的内存对象，就是 Foo 类型了 （前提是合法的内存对象地址） 。\n既然存在推导，那我们怎么知道一些初始值呢？\n一共有两类来源：\n1.全局变量；\n2.协程中每一帧函数的局部变量。\nPART. 3\n全局变量 Go 在编译的时候，默认会生成一些调试信息，按照 DWARF 标准格式，放在 ELF 文件中 .debug_* 这样的段里。\n这些调试信息中，我们关注两类关键信息：\n 类型信息： 包括了源码中定义的类型，比如某个 struct 的名字、大小、以及各个 field 类型信息；\n 全局变量： 包括变量名、地址、类型，调试信息中的、全局变量的地址、以及其类型信息，也就是构成推导的初始值。\n 函数局部变量，要复杂一些，不过基本原理是类似的，这里就不细说了~\nPART. 4\n推导过程 推导过程，跟 GC-Mark 的过程类似，甚至初始值也跟 GC-Root 一样。\n所以，全部推导完毕之后，GC-Mark 认为是 alive 的内存对象，其类型信息都会被推导出来。\ninterface\nGo 语言中 interface 比较类似动态类型，如下是空接口的内存结构，每个对象都存储了其类型信息：\ntype eface struct { _type *_type data unsafe.Pointer} 按照类型推导，我们能知道一个对象是 interface{}，但是其中 Data 指向对象，是什么类型，我们则需要读取 _type 中的信息了。\n_type 中有两个信息，对我们比较有用：\n1.名字\n不过比较坑的是，只存了 pkg.Name 并没有存完整的 Include Path 这个也合理的，毕竟 Go 运行时并不需要那么精确，也就是异常时，输出错误信息中用一下。不过在类型推导的时候，就容易踩坑了。\n2.指针信息\n具体存储形式有点绕，不过也就是表示这个对象中，有哪些偏移量是指针。\n有了这两个信息之后，就可以从全量的类型中，筛选出符合上面两个信息的类型。\n通常情况下，会选出一个正确的答案，不过有时候选出多个，仅仅根据这两个信息还不能区分出来，一旦一步错了，后面可能就全推导不出来了。\n我们给 Go 官方 Debug 贡献了一个补丁，可以进一步的筛选，有兴趣的可以看 CL 419176[1]。\nunsafe.pointer\n其实，在上面的 interface 示例中，最根源的原因，也就是 data unsafe.pointer，这个指针并没有类型信息，只是 interface 的实现中，有另外的字段来存储类型信息。\n不过，在 Go Runtime 中还有其它的 unsafe.pointer，就没有那么幸运了。\n比如 map 和 sync.map 的实现都有 unsafe.pointer，这种就没有办法像 interface 那样统一来处理了，只能 case-by-case，根据 map/sync.map 的结构特征来逆向写死了\u0026amp;hellip;\n我们给 Go 官方 Debug 贡献了 sync.map 的逆向实现，有兴趣的可以看 CL 419177[2]。\nPART. 5\n隐藏类型 除了源码中显示定义的类型，还有一些隐藏的类型，比如：Method Value、Closure 的实现中，也都是用 struct 来表示的，这些属于不太容易被关注到的“隐藏”类型。\nMethod Value 在逆向推导中，还是比较容易踩坑的，我们给 Go 官方 Debug 贡献了这块的实现，有兴趣的可以看 CL 419179[3]。\n相比 Method Value 这种固定结构的，Closure 这种会更难搞一些，不过幸运的是，我们目前的使用过程中，还没有踩坑的经历。\nPART. 6\n逆向推导风险 这种逆向推导要做到 100% 完备还是挺难的，根本原因还是 unsafe.pointer。\n在 reflect.Value 中也有 unsafe.pointer，据我所知，这个是还没有逆向推导实现的，类似的应该也还有其它未知的。\n甚至，如果是标准库中的类型，我们还是可以一个个按需加上，如果是上层应用代码用到的 unsafe.pointer，那就很难搞了。\n还有一种可能，推导不出来的原因，就是内存泄漏的来源，我们就碰到这样一个例子，以后有机会再分享~\n幸运的是：如果是只是少量的对象没有推导出来，对于全局内存泄漏分析这种场景，通常影响其实也不大。\n另外，对于一个对象，只需要有一个路径可以推导出来也就够了。\n也就是说，如果一条推导线索因为 unsafe.pointer 断了，如果另外有一个线索可以推导到这个对象，那也是不影响的。因为从 GC root 到一个 GC obj 的引用关系链，可能会不止一条。\nPART. 7\n小结 Go 虽然是静态类型语言，不过由于提供了 unsafe.pointer，给逆向类型推导带来了很大的麻烦。好在 Go 对于 unsafe.pointer 的使用还是比较克制，把标准库中常用到的 unsafe.pointer 搞定了，基本也够用了。\n理论上来说，逆向推导这一套也适用于 C 语言，只不过 C 语言这种指针漫天飞的，动不动就来个强制类型转换，就很难搞了。\n｜相关链接｜\n[1]CL …","date":1676358000,"description":"Go 语言，如何做逆向类型推导?","dir":"blog/Go-language-how-to-do-inverse-type-derivation/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"38703e8299b15a8a7e65645ff69c5926","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","publishdate":"2023-02-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者蚂蚁集团技术专家 专注于云原生网关研发的相关工作。 本文 224 字 阅读 8 分钟 PART. 1 引","tags":["MOSN"],"title":"Go 语言，如何做逆向类型推导?","type":"blog","url":"/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","wordcount":2248},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 8 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@shuangchengsun #266\n 我想知道对于 SOFARegistry 这样的系统是如何定义 SLA 的，以及有没有一个参考值。\n A：一般 SLA 的定义和系统的关键指标相关，类似 Registry 的核心就是 Pub Sub 模型，Pub 列表变化后及时推送给 Sub；那么 SLA 的定义就可以从类似 Pub 变更后在多长的周期内能推送给所有的 Sub，这个成功率应该高于多少。参考值这个看系统维护者对这个系统的要求吧，这个没什么标准值。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/\n2.@郑长青 #2197\n 我在宿主应用使用 Ark Biz，采用 Maven 依赖方式静态合并部署，但是通过 biz-a 查看，没有启动业务应用，这个问题遇到过吗？\n A：是打包业务 Biz 的 declared-libraries 赋值问题，所以动态部署和静态部署使用 2.1.0 版本的 sofa-ark-maven-plugin 插件无法正常运行。Bug 修复的 PR 已经合并，预计周五（2 月 10 日）发布新 2.1.1 版本。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/\n本周推荐阅读 Special Weekly | 瑞兔送福，Live Long and Prosper\nSOFARegistry | 大规模集群优化实践\nNydus 加速镜像一致性校验增强\n一个 go-sql-driver 的离奇 bug\n欢迎扫码关注：\n","date":1676012400,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230210/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4c87dfeed2681923e2afaa93b04009bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230210/","publishdate":"2023-02-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230210/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230210/","wordcount":728},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@wwg2017 #5222\n 如果二阶段提交 ：1.服务端没有接收到 TM 请求 report ；2. 服务端请求没有下发下来客户端没有接收到；3.客户端接收到了执行失败了。请问上面三种情况的话，对数据订单影响是什么？\n A：第一种情况会等到超时时间，默认是 60 秒后进行回滚。在 AT 模式下，订单数据由于是一个一阶段提交会有短暂的读未提交问题，这个需要按 @globallock 注解 +select for update 达到分布式下读已提交，但是会被阻塞到事务回滚后才可读到（默认 60s）。后面两种情况都会进行无限间隔 1s 的重试直至成功回滚/提交。\n「Seata」：https://github.com/seata/seata\n2.@antjack #2197\n Allow Setting Cluster Idle Timeout to Zero to Indicate Never Timeout.This issue requests the ability to set an idle_timeout = 0, to indicate the indefinite idle timeout for upstream connection timeout.\n 「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 Special Weekly | 瑞兔送福，Live Long and Prosper\nSOFARegistry | 大规模集群优化实践\nNydus 加速镜像一致性校验增强\n一个 go-sql-driver 的离奇 bug\n欢迎扫码关注：\n","date":1675407600,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230203/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"17cef13c896ee0712ff7fad78ebafe52","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230203/","publishdate":"2023-02-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230203/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230203/","wordcount":656},{"author":null,"categories":"SOFAStack","content":" 导言：\n GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。这是去年（2022）的夏令营活动中，王瑞同学参加 Nydus 开源项目的总结，主要介绍了为 Nydus 支持镜像与文件系统一致性校验所做的相关工作。\n Nydus 简介 Nydus 是 CNCF 孵化项目 Dragonfly 的子项目，它提供了容器镜像，代码包，数据分析按需加载的能力，无需等待整个数据下载完成便可开始服务。\nNydus 在生产环境已经支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，网络带宽效率，端到端数据一致性等方面相比 OCIv1 格式有着巨大优势，并可扩展至例如 NPM 包懒加载等数据分发场景。\n目前 Nydus 由蚂蚁集团，阿里云，字节跳动联合开发，Containerd，Podman 社区接受了 Nydus 运行时作为其社区子项目，也是 KataContainers 以及 Linux v5.19 内核态原生支持的镜像加速方案。\nNydus 架构及原理 OCI 容器镜像是当前容器镜像的实现标准。它采用了分层的设计，每个镜像可包含多个镜像层。新层包含的是在旧层的基础上，新增加或者修改的文件或者被删除的文件。这种设计方式比较简单，不过也有着一定的缺陷。如需要镜像层全部堆叠后才能看到整个文件系统的视图，但不是所有数据都会被读取;同时可能已经删除或者被修改旧层中的文件，但是仍需要完整地下载和解压旧层;文件元数据修改导致整个镜像层被重新存储等。 Nydus 兼容目前的 OCI 生态，旨在通过细粒度的数据分割、去重和按需加载机制加速容器 的启动和分发，同时降低资源的消耗。\nNydus 的整体架构如下图所示。它可以通过 FUSE 给 runc 容器提供运行时的按需加载能力，也可以通过 virtiofs 承载 FUSE 协议，给 Kata Containers 等基于 VM 的容器运行时提供按需加载的能力。它可以从容器 Registry，OSS，NAS，Dragonfly supernode 等多个镜像源拉取镜像，同时内部会有本地的缓存加速容器的创建。\n在用户空间文件系统，Nydus 采用了数据和元数据分离的设计思想，元数据的修改不会导致整个镜像层的更新。原先的镜像层只存储文件的数据部分，同时数据被分块存储。拉取镜像是不需要拉取整层，只需要拉取所需文件对应的数据块即可。这也使得层与层之间，镜像与镜像之间共享数据块更加容易。上图展示了 Nydus 数据和元数据的存储格式。其中元数据以 merkle tree 的形式存储在 bootstrap 中，包含了容器启动所需要的信息。数据以 1MB 分块存储，不同镜像可以共享同一数据块。\nNydus 镜像校验意义及流程 Nydus 镜像在构建完成后，由于网络、磁盘等故障或者镜像被恶意修改，无法保证容器启动前镜像是合法的，所以需要对镜像的格式进行校验。当前的校验使用 nydusify 工具。主要分为三个部分:\n 对 Nydus 镜像的 bootstrap 进行校验，会通过 BootstrapRule 调用 nydus-image 二进制文件。nydus-image 首先检查 bootstrap 的 SuperBlock 格式是否正确，然后会从根结点开始按照文件系统层级结构检查文件或者目录的 inode 是否合法或被修改。\n 对镜像的 manifest 进行校验，会通过 ManifestRule 检验 Nydus 的 manifest 是否合法，ImageConfig 是否与原始 OCI 镜像一致等。\n 对镜像进行文件系统校验，会通过 FilesystemRule 分别挂载原始 OCI 镜像和 Nydus 镜像，然后进行校验。对于原始镜像，会使用 docker pull 拉取镜像，然后指定 lowerdir 和 upperdir，通过 OverlayFS 挂载 Rootfs；对于 Nydus 镜像，会使用 Nydusd 挂载。挂载完成后，会分别遍历两个目录，比较元数据和数据是否一致。\n 目前 Nydus 的校验方式仍有一定的限制，如元数据检查不完全，需要 docker 拉取镜像等。该项目旨在增强 nydusify 和 nydus-image 的校验功能，使校验更加易用和全面。\n文件系统校验方案 该项目当前分为以下三部分:\n 当前 nydusify check 在应用 FilesystemRule 进行校验时，对于文件元数据只检查文件路径、大小、模式和权限位以及 xattrs 是否和原始镜像一致，同时对文件数据用 blake3 计算得到哈希值并进行比较。但是由于校验内容不完整，可能会出现元数据不一致校验通过的情况。故对该结构体添加 dev、rdev、symlink、project id、uid、gid、nlink、ctime 等字段，实现对文件元数据更全面的检查。 当前 nydusify check 在应用 FilesystemRule 进行校验时，需要手动指定 source 和 Backend Type, Backend Config 才能成功应用 Nydusd 挂载并进行文件系统校验，在校验数据时，也会再次检查 Backend Type 是否指定。在大多数情况下，Backend Type 为 Registry，Backend Config 可以通过查看 Registry 的 config 文件获取相关信息，如 http.addr 字段获取地址，auth 字段获取认证信息等获取。因而用户在很多情况下并不需要手动输入上述参数。该任务旨在简化该命令，实现 Backend Type，Backend Config 的自动推断，使得用户更方便地进行校验。 (3) 当前 nydusify check 在应用 FilesystemRule 进行校验时，需要用户安装 docker，因为要使用 docker pull 命令拉取镜像。在没有 docker 的环境下，无法完成校验。可以修改该部分代码，手动下载、解压镜像，并使用 OverlayFS 挂载，从而去除对 docker 的依赖。\n文件系统校验实现细节 增加校验字段 该部分的实现较为简单。首先在原 Node 结构体增加 rdev, symlink, uid, gid, mtime 等字段。\n然后在遍历文件系统时，使用 Readlink 获取文件的软链接，通过 Lstat 系统调用获取 文件更详细的元数据信息（rdev, uid, gid, mtime 等），从而在进行比较时增加对上述字段的校验。值得注意的是 dev 不同是正常的，nlink 由于 OverlayFS 的问题无法进行校验。此外，还需要修改异常错误信息，从而遇到不一致时能够打印完整的文件元数据信息。\n简化校验参数 该部分需要实现 Backend Type 和 Backend Config 的自动推断，即如果镜像存储在 registry 中，用户无需指定上述两个参数即可完成校验。\n首先，我们需要添加上述结构体，即镜像源为 Registry 时的 Backend Config。对 …","date":1675148400,"description":"Nydus 加速镜像一致性校验增强","dir":"blog/nudus-20230131/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"483248448e3baf3c9667fae7d625f0e5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nudus-20230131/","publishdate":"2023-01-31T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/nudus-20230131/","summary":"导言： GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。这是去年（2022）的","tags":["SOFAStack"],"title":"Nydus 加速镜像一致性校验增强","type":"blog","url":"/sofastack.tech/blog/nudus-20230131/","wordcount":3175},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack GitHub issue 精选 本周各项目回复 issue 共计 5 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @fengjiachun #951\n 怎么通过GitHub Action 自动发布新版本 jar 到 maven 库？\n A：把 autoReleaseAfterClose 设置为 true，可以非常方便。\n「SOFAJraft」：https://github.com/sofastack/sofa-jraft/\n2. @canaan-wang #859\n Layotto 为什么要开发 SDK ？SDK 中的功能代码为什么不可以迁移到 Server 端？\n A：对于一些熟悉 gRPC 的用户来说，Client 端直接裸用 gRPC 都可以，但这种方式对于应用开发者是有理解成本的，所以 Layotto 的 SDK 提供的更多的是接口定义，让用户编程的时候不需要直接面向裸漏的 gRPC。举个简单的例子：假设用户可以往 gRPC 的 header 里面塞一个字段 “rpc-remote-address” 该字段用来指定 RPC 访问的远端目标地址，那么如果没 SDK，用户就得知道两件事：字段名和如何塞字段到 gRPC 的 header。但如果有 SDK，你可以提供一个函数 SetRpcTargetAddress（Address String）来直接给用户使用。\n「Layotto」：https://github.com/mosn/layotto/\n本周推荐阅读 WASM 将引领下一代计算范式[译]\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1674802800,"description":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230127/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7f4e9f1a38f28d522bf4684610397dfa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230127/","publishdate":"2023-01-27T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230127/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230127/","wordcount":762},{"author":null,"categories":"SOFA Weekly","content":"送虎迎兔\n各位 SOFAStack 社区的朋友好：\n我是 SOFAStack 社区的负责人鲁直，度过了令人难忘的虎年，我们即将迈入充满希望的兔年，在这里给大家拜个早年，祝大家兔年吉祥。\n虎年虽然有诸多的不便与艰难，但是好在开源本就是倡导异步沟通、在线协作；无论你在世界的哪个角落，只要连上互联网，都可以参与到开源社区中来。在过去的一年中，SOFAStack 社区新增了 100 多位的 Committer；他们有来自腾讯、Shoppee、MiHoYo、华信永道、同程旅行等公司的员工；也有来自高校的学生，这些 Committer 和我们已有的 Committer 一起发布了大量的新 Feature，也修复了很多深藏的 Bug。\n不过，通过线上的协作虽然能够正常进行开源项目的开发，但是联络感情最好的方式一定还是线下的 Meetup。\n在虎年出行各种不便的情况下，我们和各个社区联合，在杭州、成都、广州、合肥和上海举行了 Meetup，不过遗憾的是 SOFAStack 社区开源四周年的活动没有能够在线下举办。\n伴随着兔年的即将到来，SOFAStack 社区的开源也即将迈入第五年，没有了出行的各种限制，SOFAStack 社区的五周年活动也将在线下和大家相见。\n兔年展望\n回望 SOFAStack 社区将近五年的开源时间，一开始我们只是按照自己的粗浅理解来做开源，把代码放到 GitHub 上面去，举办一些 Meetup。\n随着和开源社区朋友们的深入沟通，我们对于开源的理解、对于社区的理解也一步步深入和加强，意识到想要让 SOFAStack 社区长期发展，除了项目本身的优秀想法之外，更需要一个开放的、活跃的社区，只有两者结合一起才能够长久地经营下去。基于此我们设计了完善的社区晋升机制，也和项目的上下游保持良好的沟通和合作关系，融入到更大的开源大家庭中。\n今年我们也会在继续在开放和有趣方面做进一步的深入，包括会把部分的项目推进到基金会孵化，使它们能够更加健康地长期发展，也会把更多有趣的活动带给大家。\n兔年准备做的几件事\nSOFABoot 4.0\nSOFABoot 将会发布 4.0 版本，适配最新发布的 Spring Boot 3.0。回想 2019 年，我们在配套设施并不完善的情况下，尝试了使用 GraalVM 做 SOFABoot 的静态化，初步感受到了 Native 能够带来的启动速度的提升。随着 Spring Boot 3.0 的发布与 Spring 对于 GraalVM 支持的完善，我们终于有机会能够把 SOFABoot 的静态化做地更加完善。\nMOSN 2.0\nMOSN 将会发布 2.0 的版本，MoE 架构将会正式和大家见面。随着我们和 Envoy 社区的重要的合作点Envoy\u0026amp;rsquo;s L7 Go extension API，我们 MOSN 2.0 的开发和测试工作也已经接近尾声，新的架构将会给 MOSN 带来更多的可能性。\nLayotto 1.0\nLayotto 将会发布 1.0 的版本，提供更多的组件支持，并且进一步完善多云与多语言的支持。\nSeata\nSeata 将会继续丰富多语言的支持，也会走向更加开放的社区。\n除了上面的项目之外，SOFAStack 社区其他的一些项目在年后也会陆陆续续公布 RoadMap，期待大家一起加入进来玩。\nLive Long and Prosper\n星际迷航里面的瓦肯人在举瓦肯手礼的时候会说著名的瓦肯祝词：“Live Long and Prosper”，这句话也非常符合 SOFAStack 开源社区的愿景，我们希望无论是 SOFAStack 的项目还是 SOFAStack 的社区，都能够“Live Long and Prosper”。\n期待与大家在兔年线下相见，Let\u0026amp;rsquo;s build the community together! Live long and prosper!\n","date":1674284400,"description":"Special Weekly | 瑞兔送福，Live Long and Prosper","dir":"blog/sofa-special-weekly/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9bce67dda0b127c88ba3f0413516f2f7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-special-weekly/","publishdate":"2023-01-21T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-special-weekly/","summary":"送虎迎兔 各位 SOFAStack 社区的朋友好： 我是 SOFAStack 社区的负责人鲁直，度过了令人难忘的虎年，我们即将迈入充满希望的兔年，在这里给大家拜个早年，祝大家兔年吉祥。","tags":["SOFA Weekly"],"title":"Special Weekly | 瑞兔送福，Live Long and Prosper","type":"blog","url":"/sofastack.tech/blog/sofa-special-weekly/","wordcount":1241},{"author":null,"categories":"SOFAStack","content":" 文｜郝洪范\n京东技术专家\nSeata-go 项目共同发起人\n微服务底层技术的探索与研究。\n本文 3482 字 阅读 7 分钟\n 对于 Go CURD Boy 来说，相信 github.com/go-sql-driver/mysql 这个库都不会陌生。基本上 Go 的 CURD 都离不开这个特别重要的库。我们在开发 Seata-go 时也使用了这个库。不过最近在使用 go-sql-driver/mysql 查询 MySQL 的时候，就出现一个很有意思的 bug, 觉得有必要分享出来，以防止后来者再次踩坑。\n PART. 1 问题详述 为了说明问题，这里不详述 Seata-go 的相关代码，用一个单独的 demo 把问题详细描述清楚。\n1.1 环境准备 在一个 MySQL 实例上准备如下环境：\nCREATE TABLE `Test1` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `create_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, -PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=101 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; 从这个 SQL 语句中可以看出来， create_time 是 timestamp 类型，这里要特别留意 timestamp 这个类型。\n现在插入一条数据，然后查看刚插入的数据的值。\ninsert into Test1 values (1, \u0026#39;2022-01-01 00:00:00\u0026#39;) 查看下 MySQL 当前的时区。请记好相关值，草蛇灰线，伏笔于此。\nshow VARIABLES like \u0026#39;%time_zone%\u0026#39;; 查询结果：\n接下来使用 MySQL unix_timestamp 查看 create_time 的时间戳：\nSELECT unix_timestamp(create_time) from Test1 where id = 1; 查询结果：\n1.2 测试程序 有如下 demo 程序，示例使用 go-sql-driver 读取 create_time 的值：\npackage main import ( \u0026amp;quot;database/sql\u0026amp;quot; \u0026amp;quot;fmt\u0026amp;quot; \u0026amp;quot;time\u0026amp;quot; _ \u0026amp;quot;github.com/go-sql-driver/mysql\u0026amp;quot; ) func main() { var user = \u0026amp;quot;user\u0026amp;quot; var pwd = \u0026amp;quot;password\u0026amp;quot; var dbName = \u0026amp;quot;dbname\u0026amp;quot; dsn := fmt.Sprintf(\u0026amp;quot;%s:%s@tcp(localhost:3306)/%stimeout=100s\u0026amp;amp;parseTime=true\u0026amp;amp;interpolateParams=true\u0026amp;quot;, user, pwd, dbName) db, err := sql.Open(\u0026amp;quot;mysql\u0026amp;quot;, dsn) if err != nil { panic(err) } defer db.Close() rows, err := db.Query(\u0026amp;quot;select create_time from Test1 limit 1\u0026amp;quot;) if err != nil { panic(err) } for rows.Next() { t := time.Time{} rows.Scan(\u0026amp;amp;t) fmt.Println(t) fmt.Println(t.Unix()) }} 我们运行个程序会输出下面的结果:\n2022-01-01 00:00:00 +0000 UTC1640995200 1.3 问题详述 发现问题所在了吗？有图如下，把结果放在一块，可以详细说明问题。\n图中红色箭头指向的两个结果，用 go-sql-driver 读取的结果和在 MySQL 中用 unix_timestamp 获取的结果明显是不一样的。\nPART. 2 问题探案 1.3 小节中最后示图可以看出，数据库中 create_time 的值 2022-01-01 00:00:00 是东八区的时间，也就是北京时间，这个时间对应的时间戳就是 1640966400 。但是 go-sql-driver 示例程序读出来的却是 1640995200 ， 这是什么值？这是 0 时区的 2022-01-01 00:00:00。\n对问题的直白描述就是：MySQL 的 create_time 是 2022-01-01 00:00:00 +008 ，而读取到的是 2022-01-01 00:00:00 +000 ，他俩压根就不是一个值。\n基本能看出来 bug 是如何发生的了。那就需要剖析下 go-sql-driver 源码，追查问题的根源。\n2.1 go-sq-driver 源码分析 这里就不粘贴 \u0026amp;quot;github.com/go-sql-driver/mysql\u0026amp;quot; 的详细源码了，只贴关键的路径。\nDebug 的时候详细关注调用路径中红色的两个方块的内存中的值。\n// https://github.com/go-sql-driver/mysql/blob/master/packets.go#L788- L798 func (rows *textRows) readRow(dest []driver.Value) error { // ... // Parse time field switch rows.rs.columns[i].fieldType { case fieldTypeTimestamp, fieldTypeDateTime, fieldTypeDate, fieldTypeNewDate: if dest[i], err = parseDateTime(dest[i].([]byte), mc.cfg.Loc); err != nil { return err } }} func parseDateTime(b []byte, loc *time.Location) (time.Time, error) { const base = \u0026amp;quot;0000-00-00 00:00:00.000000\u0026amp;quot; switch len(b) { case 10, 19, 21, 22, 23, 24, 25, 26: // up to \u0026amp;quot;YYYY-MM-DD HH:MM:SS.MMMMMM\u0026amp;quot; year, err := parseByteYear(b) month := time.Month(m) day, err := parseByte2Digits(b[8], b[9]) hour, err …","date":1673938800,"description":"一个 go-sql-driver 的离奇 bug","dir":"blog/go-sql-driver-amazing-bug/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d7361909c70b2dd88fad050699609660","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-sql-driver-amazing-bug/","publishdate":"2023-01-17T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/go-sql-driver-amazing-bug/","summary":"文｜郝洪范 京东技术专家 Seata-go 项目共同发起人 微服务底层技术的探索与研究。 本文 3482 字 阅读 7 分钟 对于 Go CURD Boy 来说，相信 github.com/go-sql-driver/mysql 这个库都不会陌生。基本上 Go 的 CURD 都离","tags":["SOFAStack"],"title":"一个 go-sql-driver 的离奇 bug","type":"blog","url":"/sofastack.tech/blog/go-sql-driver-amazing-bug/","wordcount":1881},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 6 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @dengqian #2203\n 是否支持应用级服务发现，若支持能够给提供者和消费者的代号示例吗？\n A：SOFARegistry 本身是比较存粹的服务发布和订阅功能，应用级和接口级的区别在于 Client 发送给 Registry 的是应用级的 Publisher 还是接口级的 Publisher。所以相关的应用级 Publisher 聚合以及应用级 Subscriber 订阅的逻辑主要是在 Mesh 端，而这部分 Mesh 代码暂时还没开源。稍后我们会整理完整的应用级服务上线的过程以及设计方案，发布到社区文档中。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/\n2. @yemoli #1290\n 请问 MOSN 支持增加订阅 xDS 吗？gRPC DeltaAggregatedResources。\n A：xDS 这个块还不支持，不过底层的资源是支持增加更新的，感兴趣的话语，欢迎共建~\n「MOSN」：https://github.com//mosn/mosn/\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1673593200,"description":"SOFA Weekly | 铜锁探「密」、本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20220113/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5558f66f4c819ff525bcb4708fab5700","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220113/","publishdate":"2023-01-13T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220113/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 铜锁探「密」、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220113/","wordcount":715},{"author":null,"categories":"SOFAStack","content":" 文｜李楠（GitHub ID : @loheagn）\n北京航空航天大学 21 级研究生\n云原生底层系统的开发和探索工作。\n本文 6369 字 阅读 16 分钟\nOSPP 开源之夏是由中科院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动。旨在鼓励在校学生积极参与开源软件的开发维护、促进优秀开源软件社区的蓬勃发展、培养和发掘更多优秀的开发者。\n这是去年（2022）的开源活动中，李楠同学参加 Nydus 容器开源生态集成课题的相关工作。\n| 作者有话说 |\n 大家好！我是来自北京航空航天大学的 2021 级研究生李楠，对云原生技术很感兴趣，GitHub ID 是 @loheagn。在今年上半年，我参加了 Linux 基金会的春季实习，完成了 CNCF - Kubevela: Management of Terraform state 项目的工作，并因此培养了对开源工作的兴趣。在开源之夏 2022 开放题目后，我了解到了 Nydus 项目，感觉这是一个很酷的项目，由于我之前对容器和镜像的底层技术并不是很熟悉，觉得这是个很不错的学习机会。于是便尝试投递了简历申请，最终很幸运地通过了筛选，并在严松老师的帮助下顺利完成了题目。\n PART. 1 项目背景 Nerdctl Nerdctl 是一个对标 Docker CLI 和 Docker Compose 的、用于与 Containerd （当下最流行的容器运行时，Docker 的后端也是调用的 Containerd，通常作为守护进程出现） 交互的命令行工具。\n用户可以像使用 Docker CLI 一样使用 Nerdctl 与 Containerd 进行交互，比如使用 nerdctl pull \u0026amp;lt;image_name\u0026amp;gt; 来拉取镜像、使用 nerdctl run \u0026amp;lt;image_name\u0026amp;gt; 来运行容器等等。\n相比于 Containerd 本身提供的 CTR 工具，Nerdctl 默认提供了更友好的用户体验，并尽量保持其使用方式与 Docker 一致。对于从 Docker 迁移到 Containerd 的用户，往往只需要 alias docker=nerdctl 就可以与之前获得一致的使用体验。\nOCI 镜像格式 OCI 镜像格式是 OCI （Open Container Initiative，开放容器计划） 的重要组成部分。它给出了一个厂商无关的镜像格式规范，即一个镜像应该包含哪些部分、每个部分的数据结构是如何的、这些各个部分应该以怎样的方式进行组织等等。\nOCI 镜像格式脱胎于 Docker 镜像格式，它与 Docker 镜像格式有着非常类似的结构；但它比 Docker 镜像格式有更好的兼容性，并得到了各个厂商的普遍认同。\n因此，在这里主要介绍一下 OCI 镜像格式的主要内容。\n通常所说的镜像文件其实指的是一个包含了多个文件的“包”，“包”中的这些文件提供了启动一个容器所需要的所有需要信息，其中包括但不限于，容器所使用的文件系统等数据文件，镜像所适用的平台、数据完整性校验信息等配置文件。当我们使用 docker pull 或 nerdctl pull 从镜像中心拉取镜像时，其实就是在依次拉取该镜像所包含的这些文件。\n例如，当我们使用 nerdctl pull 拉取一个 OCI 镜像时：\n从 Log 中可以清晰地看到，Nerdctl 依次拉取了一个 index 文件、一个 manifest 文件、一个 config 文件和若干个 layer 数据文件。实际上，一个标准的 OCI 镜像通常就是由这几部分构成的。\n其中，layer 文件一般是 tar 包或者压缩后的 tar 包，其包含着镜像具体的数据文件。这些 layer 文件会共同组成一个完整的文件系统（也就是从该镜像启动容器后，进入容器中看到的文件系统） 。\nconfig 文件是一个 JSON 文件。其中包含镜像的一些配置信息，比如镜像时间、修改记录、环境变量、镜像的启动命令等等。\nmanifest 文件也是一个 JSON 文件。它可以看作是镜像文件的清单，即说明了该镜像包含了哪些 layer 文件和哪个 config 文件。\n下面是一个 manifest 文件的典型例子：\n{ \u0026amp;quot;schemaVersion\u0026amp;quot;: 2, \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.manifest.v1+json\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.config.v1+json\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:0584b370e957bf9d09e10f424859a02ab0fda255103f75b3f8c7d410a4e96ed5\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 7636 }, \u0026amp;quot;layers\u0026amp;quot;: [ { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:214ca5fb90323fe769c63a12af092f2572bf1c6b300263e09883909fc865d260\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 31379476 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:50836501937ff210a4ee8eedcb17b49b3b7627c5b7104397b2a6198c569d9231\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 25338790 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:d838e0361e8efc1fb3ec2b7aed16ba935ee9b62b6631c304256b0326c048a330\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 600 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:fcc7a415e354b2e1a2fcf80005278d0439a2f87556e683bb98891414339f9bee\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: …","date":1673334000,"description":"Nerdctl 原生支持 Nydus 加速镜像","dir":"blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ef25c9d4c042e6feeca78cb7919f6fa5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","publishdate":"2023-01-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","summary":"文｜李楠（GitHub ID : @loheagn） 北京航空航天大学 21 级研究生 云原生底层系统的开发和探索工作。 本文 6369 字 阅读 16 分钟 OSPP 开源之夏是由中科院","tags":["SOFAStack"],"title":"Nerdctl 原生支持 Nydus 加速镜像","type":"blog","url":"/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","wordcount":5660},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @dengqian #2203\n Why pprof debug server do not support hot upgrade?\n A：Debug server init here：\nfunc DefaultInitStage(c *v2.MOSNConfig) { InitDefaultPath(c) InitDebugServe(c) InitializePidFile(c) InitializeTracing(c) InitializePlugin(c) InitializeWasm(c) InitializeThirdPartCodec(c) } And started here:\nfunc (m *Mosn) inheritConfig(c *v2.MOSNConfig) (err error) { m.Config = c server.EnableInheritOldMosnconfig(c.InheritOldMosnconfig) // default is graceful mode, turn graceful off by set it to false if !c.DisableUpgrade \u0026amp;amp;\u0026amp;amp; server.IsReconfigure() { m.isFromUpgrade = true if err = m.inheritHandler(); err != nil { return } } log.StartLogger.Infof(\u0026amp;quot;[mosn] [NewMosn] new mosn created\u0026amp;quot;) // start init services if err = store.StartService(nil); err != nil { log.StartLogger.Errorf(\u0026amp;quot;[mosn] [NewMosn] start service failed: %v, exit\u0026amp;quot;, err) } return } 「MOSN」：https://github.com//mosn/mosn/\n2. @yemoli #1290\n SOFARPC 发现了安全漏洞在哪提交呢？\n A：可以邮件给：khotyn.huangt@antgroup.com。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/\n本周推荐阅读 SOFARegistry | 聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1672988400,"description":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","dir":"blog/sofaweekly-20230106/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f7cd3e95e772fe4b498452c1594986a2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaweekly-20230106/","publishdate":"2023-01-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofaweekly-20230106/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofaweekly-20230106/","wordcount":596},{"author":null,"categories":"SOFAStack","content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。\n本文 9492字 阅读 24 分钟\nPART. 1 前言 1.1 什么是服务发现 在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信。这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群；具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n1.2 服务发现的考量 设计和考量一个服务发现系统，可以从下面这些指标展开：\n各个指标之间并不是相互独立的。例如对于数据一致性方案的选型也会影响到数据分区、数据复制、集群容灾、多集群同步等方案的决策，也在很大程度上决定这个服务发现系统的整体架构。\n这篇文章重点分析了各个服务发现系统的数据一致性方案，以及基于这个方案延伸出来的特性，帮助大家初步了解服务发现系统。\nPART. 2 开源产品分析 2.1 为什么需要数据一致性 根据上述描述，数据一致性在服务发现系统中如此重要，甚至会影响到整个服务发现系统的各方面架构考量，那我们到底为什么需要数据一致性呢？\n要回答这个问题，让我们从单点故障说起：早期我们使用的服务，以及服务数据存储，它们往往是部署在单节点上的。但是单节点存在单点故障，一旦单节点宕机就整个服务不可用，对业务影响非常大。随后，为了解决单点问题，软件系统引入了数据复制技术，实现多副本。\n通过数据复制方案，一方面我们可以提高服务可用性，避免单点故障；另一方面，多副本可以提升读吞吐量、甚至就近部署在业务所在的地理位置，降低访问延迟。\n随着多副本的引入，就会涉及到多个副本之间的数据怎样保持一致的问题，于是数据一致性随之而来。\n2.2 开源产品分析\n对于多个副本之间进行数据同步，一致性关系从强到弱依次是：\n 线性一致性 （Linearizability consistency）\n 顺序一致性 （Sequential consistency）\n 因果一致性 （Causal consistency）\n 最终一致性 （Eventual consistency）\n 我们对比一下目前开源的比较典型的服务发现产品，在数据一致性上的方案实现：\nPART. 3 Etcd 数据一致性 3.1 Etcd 读数据流程 1. Client：Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： Client 发送 RPC 请求到了 Server 后，KV Server 基于拦截器记录所有请求的执行耗时及错误码、来源 IP 等，也可控制请求是否允许通过；\n3. Raft： Etcd 收到读请求后，向 Etcd Raft 模块发起 Read Index 读数据请求，返回最新的 ReadState 结构体数据；\n4. MVCC：KV Server 获取到 Read State 数据后，从 MVCC 模块的 Tree Index 读取基于 Key-Version 的唯一标识 Revision；再以 Revision 作为 Key 从 Boltdb 中读取数据。\n3.2 Etcd 写数据流程 1. Client： Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： 通过一系列检查之后，然后向 Raft 模块发起 （Propose） 一个提案 （Proposal） ，提案内容为存储的 value；\n3. Raft：\na.向 Raft 模块发起提案后，KV Server 模块会等待此 put 请求；如果一个请求超时未返回结果，会出现的 EtcdServer：request timed out 错误。\nb.Raft 模块收到提案后，如果当前节点是 Follower，它会转发给 Leader，只有 Leader 才能处理写请求。Leader 收到提案后，通过 Raft 模块将 put 提案消息广播给集群各个节点，同时需要把集群 Leader 任期号、投票信息、已提交索引、提案内容持久化到一个 WAL （Write Ahead Log） 日志文件中，用于保证集群的一致性、可恢复性。\n4. Raft 模块提交 Proposal 完成后，向 MVCC 模块提交写数据。\n3.3 Raft 功能分解 共识算法的祖师爷是 Paxos， 但是由于它过于复杂、难于理解，工程实践上也较难落地，导致在工程界落地较慢。\nStandford 大学的 Diego 提出的 Raft 算法正是为了可理解性、易实现而诞生的，它通过问题分解，将复杂的共识问题拆分成三个子问题，分别是：\n Leader 选举： Leader 故障后集群能快速选出新 Leader；\n 日志复制：集群只有 Leader 能写入日志， Leader 负责复制日志到 Follower 节点，并强制 Follower 节点与自己保持相同；\n 安全性： 一个任期内集群只能产生一个 Leader、已提交的日志条目在发生 Leader 选举时，一定会存在更高任期的新 Leader 日志中、各个节点的状态机应用的任意位置的日志条目内容应一样等。\n 下面以实际场景为案例，分别深入讨论这三个子问题，看看 Raft 是如何解决这三个问题，以及在 Etcd 中的应用实现。\n关于 Raft 的 Leader 选举与日志复制，可以从 *http://www.kailing.pub/raft/index.html* 动画中进一步了解。\n3.4 Etcd 读写一致性 3.4.1 线性一致性写 所有的 Read/Write 都会来到 Leader，Write 会有 Oplog Leader 被序列化，依次顺序往后 commit，并 Apply 然后在返回，那么一旦一个 Write 被 committed，那么其前面的 Write 的 Oplog 一定就被 committed 了。所有的 Write 都是有严格的顺序的，一旦被 committed 就可见了，所以 Raft 是线性一致性写。\n3.4.2 线性一致性读 Etcd 默认的读数据流程是 Linearizability Read，那么怎么样才能读取到 Leader 已经完成提交的数据呢？\n读请求走一遍 Raft 协议\n每个 Read 都生成一个对应的 Oplog，和 Write 一样，都会走一遍一致性协议的流程，会在此 Read Oplog 被 Apply 的时候读，那么这个 Read Oplog 之前的 Write Oplog 肯定也被 Applied 了，那么一定能够被读取到，读到的也一定是最新的。\n 有什么问题?\n 不仅有日志写盘开销，还有日志复制的 RPC 开销，在读比重较大的系统中是无法接受的；\n 还多了一堆的 Raft \u0026amp;lsquo;读日志\u0026amp;rsquo;。 …","date":1672729200,"description":"SOFARegistry | 聊一聊服务发现的数据一致性","dir":"blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","fuzzywordcount":7400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"87d55af6b45db61d5fb44c2096813f0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","publishdate":"2023-01-03T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。 本文 9492字 阅读 24 分钟 PART. 1 前言 1.1 什么是","tags":["SOFAStack"],"title":"SOFARegistry | 聊一聊服务发现的数据一致性","type":"blog","url":"/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","wordcount":7378},{"author":"肖健","categories":["SOFAStack"],"content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。\n本文 9492字 阅读 24 分钟\nPART. 1 前言 1.1 什么是服务发现 在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信。这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群；具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n1.2 服务发现的考量 设计和考量一个服务发现系统，可以从下面这些指标展开：\n各个指标之间并不是相互独立的。例如对于数据一致性方案的选型也会影响到数据分区、数据复制、集群容灾、多集群同步等方案的决策，也在很大程度上决定这个服务发现系统的整体架构。\n这篇文章重点分析了各个服务发现系统的数据一致性方案，以及基于这个方案延伸出来的特性，帮助大家初步了解服务发现系统。\nPART. 2 开源产品分析 2.1 为什么需要数据一致性 根据上述描述，数据一致性在服务发现系统中如此重要，甚至会影响到整个服务发现系统的各方面架构考量，那我们到底为什么需要数据一致性呢？\n要回答这个问题，让我们从单点故障说起：早期我们使用的服务，以及服务数据存储，它们往往是部署在单节点上的。但是单节点存在单点故障，一旦单节点宕机就整个服务不可用，对业务影响非常大。随后，为了解决单点问题，软件系统引入了数据复制技术，实现多副本。\n通过数据复制方案，一方面我们可以提高服务可用性，避免单点故障；另一方面，多副本可以提升读吞吐量、甚至就近部署在业务所在的地理位置，降低访问延迟。\n随着多副本的引入，就会涉及到多个副本之间的数据怎样保持一致的问题，于是数据一致性随之而来。\n2.2 开源产品分析\n对于多个副本之间进行数据同步，一致性关系从强到弱依次是：\n 线性一致性 （Linearizability consistency）\n 顺序一致性 （Sequential consistency）\n 因果一致性 （Causal consistency）\n 最终一致性 （Eventual consistency）\n 我们对比一下目前开源的比较典型的服务发现产品，在数据一致性上的方案实现：\nPART. 3 Etcd 数据一致性 3.1 Etcd 读数据流程 1. Client：Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： Client 发送 RPC 请求到了 Server 后，KV Server 基于拦截器记录所有请求的执行耗时及错误码、来源 IP 等，也可控制请求是否允许通过；\n3. Raft： Etcd 收到读请求后，向 Etcd Raft 模块发起 Read Index 读数据请求，返回最新的 ReadState 结构体数据；\n4. MVCC：KV Server 获取到 Read State 数据后，从 MVCC 模块的 Tree Index 读取基于 Key-Version 的唯一标识 Revision；再以 Revision 作为 Key 从 Boltdb 中读取数据。\n3.2 Etcd 写数据流程 1. Client： Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： 通过一系列检查之后，然后向 Raft 模块发起 （Propose） 一个提案 （Proposal） ，提案内容为存储的 value；\n3. Raft：\na.向 Raft 模块发起提案后，KV Server 模块会等待此 put 请求；如果一个请求超时未返回结果，会出现的 EtcdServer：request timed out 错误。\nb.Raft 模块收到提案后，如果当前节点是 Follower，它会转发给 Leader，只有 Leader 才能处理写请求。Leader 收到提案后，通过 Raft 模块将 put 提案消息广播给集群各个节点，同时需要把集群 Leader 任期号、投票信息、已提交索引、提案内容持久化到一个 WAL （Write Ahead Log） 日志文件中，用于保证集群的一致性、可恢复性。\n4. Raft 模块提交 Proposal 完成后，向 MVCC 模块提交写数据。\n3.3 Raft 功能分解 共识算法的祖师爷是 Paxos， 但是由于它过于复杂、难于理解，工程实践上也较难落地，导致在工程界落地较慢。\nStandford 大学的 Diego 提出的 Raft 算法正是为了可理解性、易实现而诞生的，它通过问题分解，将复杂的共识问题拆分成三个子问题，分别是：\n Leader 选举： Leader 故障后集群能快速选出新 Leader；\n 日志复制：集群只有 Leader 能写入日志， Leader 负责复制日志到 Follower 节点，并强制 Follower 节点与自己保持相同；\n 安全性： 一个任期内集群只能产生一个 Leader、已提交的日志条目在发生 Leader 选举时，一定会存在更高任期的新 Leader 日志中、各个节点的状态机应用的任意位置的日志条目内容应一样等。\n 下面以实际场景为案例，分别深入讨论这三个子问题，看看 Raft 是如何解决这三个问题，以及在 Etcd 中的应用实现。\n关于 Raft 的 Leader 选举与日志复制，可以从 *http://www.kailing.pub/raft/index.html* 动画中进一步了解。\n3.4 Etcd 读写一致性 3.4.1 线性一致性写 所有的 Read/Write 都会来到 Leader，Write 会有 Oplog Leader 被序列化，依次顺序往后 commit，并 Apply 然后在返回，那么一旦一个 Write 被 committed，那么其前面的 Write 的 Oplog 一定就被 committed 了。所有的 Write 都是有严格的顺序的，一旦被 committed 就可见了，所以 Raft 是线性一致性写。\n3.4.2 线性一致性读 Etcd 默认的读数据流程是 Linearizability Read，那么怎么样才能读取到 Leader 已经完成提交的数据呢？\n读请求走一遍 Raft 协议\n每个 Read 都生成一个对应的 Oplog，和 Write 一样，都会走一遍一致性协议的流程，会在此 Read Oplog 被 Apply 的时候读，那么这个 Read Oplog 之前的 Write Oplog 肯定也被 Applied 了，那么一定能够被读取到，读到的也一定是最新的。\n 有什么问题?\n 不仅有日志写盘开销，还有日志复制的 RPC 开销，在读比重较大的系统中是无法接受的；\n 还多了一堆的 Raft \u0026amp;lsquo;读日志\u0026amp;rsquo;。 …","date":1672729200,"description":"SOFARegistry | 聊一聊服务发现的数据一致性","dir":"projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","fuzzywordcount":7400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"27d048a94346192098907dd51a25e4ba","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","publishdate":"2023-01-03T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。 本文 9492字 阅读 24 分钟 PART. 1 前言 1.1 什么是","tags":["SOFAStack","SOFARegistry"],"title":"SOFARegistry | 聊一聊服务发现的数据一致性","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","wordcount":7378},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 小白\n 在蚂蚁内部目前中间件升级采用的是业务方修改 POM 依赖的方式吗？\n A：是以这个方式为主的\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2. 肖文璧 提问\n Unrecognized VM option \u0026amp;lsquo;CMSParallelRemarkEnabled\u0026amp;rsquo; Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.导致 Seata-Server 无法启动是怎么回事？\n A：A：这个是因为使用了高版本的 JDK 导致。高版本的 JDK 取消了 CMS 处理器，转而采用了 ZGC 代替它。 解决方案有两个，选其中之一便可：1、降级 JDK 版本；2、在 Seata 的启动脚本中删除 CMS 的 JDK 命令。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1672383600,"description":"SOFA Weekly | 2023 我们一起加油、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221230/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"75c5a4519ec5c68e190926415dd7e767","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221230/","publishdate":"2022-12-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221230/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 2023 我们一起加油、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221230/","wordcount":607},{"author":null,"categories":"SOFAStack","content":" 文｜余硕\n上海交通大学22届毕业生阿里云开发工程师\n从事云原生底层系统的开发和探索工作。\n本文 6369 字 阅读 16 分钟\n GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。 这是今年的夏令营活动中，余硕同学参加 Nydus 开源项目的总结，主要介绍了 Nydus 为支持镜像扫描与修复所做的研究与相关工作。\n PART. 1 课题背景 Nydus 开源镜像加速框架 Nydus 是 CNCF 孵化项目 Dragonfly 的子项目，它提供了容器镜像，代码包按需加载的能力。Nydus 应用时无需等待全部数据下载完成便可开始服务。\nNydus 在生产环境中已经支撑了每日百万级别的加速镜像容器创建。它在容器启动性能、镜像空间占用、网络带宽效率、端到端数据一致性等方面相比 OCI v1 格式有着巨大优势，并可扩展至其它数据分发场景，比如 NPM 包懒加载等。\n目前 Nydus 由蚂蚁集团、阿里云、字节跳动联合开发。Containerd、Podman 社区已经接受了 Nydus 运行时作为其社区子项目，它也是 Kata Containers 以及 Linux v5.19 内核态原生支持的镜像加速方案。\n有关 Nydus 镜像加速开源项目的详细介绍，可以参考：Nydus——下一代容器镜像的探索实践。\n项目描述 为 Nydus 镜像增加一个扫描和修复的命令行工具，包含以下功能：\n 提供一个 Nydus 镜像 url 和需要替换的文件列表；\n 使用工具拉取镜像 Bootstrap；\n 找到镜像中对应的文件并替换；\n 打包成新的镜像并上传回 Registry。\n 概括来说，原有项目目标是为 Nydus 镜像实现一个扫描和修复的命令行工具，其中这些功能是这个工具或者工具组的实现流程。\n但此项目具有一定的实验性，其核心是为 Nydus 格式的镜像提供扫描和修复的功能或者指引。如果存在更好的方式，项目最终不一定要按照原有项目描述去实现。因此在接下来的课题完成过程中，我们首先对已有镜像扫描/修复的工具与服务进行了调研，来确定此课题方案的最终形态。\n镜像扫描工具及服务 扫描和修复 镜像扫描和修复可以被拆解为两个过程。扫描不更改原有的镜像内容，只需要寻找扫描目标是否存在某种缺陷；镜像修复则需要根据缺陷改动镜像，包括但不限于镜像内容，镜像层级组织等。我们调研发现，当前主流开源镜像扫描引擎包括云厂商镜像安全服务都只涉及镜像扫描的功能， 不会主动添加镜像修复的功能。\n我们分析主要的原因有：\n 直接进行镜像修复可能引入新的安全问题；\n 镜像扫描的内容存在不同种类，很可能需要为不同种类的镜像安全问题设计不同的修复方式；\n 镜像修复功能可以通过重新打包镜像替代。\n 所以，镜像安全服务暂时只是提供扫描结果的安全报告，具体的修复操作由用户自行决定。我们也准备沿用这样的思路：在本课题中，为镜像实现安全扫描的功能，并提供报告作为用户镜像修复的参考依据。\n 我们也探索讨论了镜像修复的支持，或者 Nydus 特性在镜像修复场景下的增强，比如镜像内包替换后的去重与重组等，或许这些可以是未来 Nydus 中增加的功能特性。\n 镜像扫描介绍 镜像扫描的原因与内容 容器镜像是当前容器/软件分发的基础，里面包含了容器隔离环境以及软件执行环境的相关内容。因此保障其安全性变得十分重要。镜像扫描即是要扫描镜像中的所有内容，及时发现可能包含的安全漏洞或者隐私泄露。\n综合来看，镜像扫描需要关注镜像的安全性与健壮性，扫描的内容主要分为三类：\n1. 安全漏洞。 包括系统软件包和应用软件库中可能存在的安全漏洞。可以通过比对镜像中这些库/软件包的来源、版本等与 CVE 数据库中报告的漏洞的包的来源、版本来定位可能存在的安全漏洞。\n2. 配置。 包括镜像运行的环境配置和镜像中相关内容组合可能带来的问题。帮助尽早定位配置错误以及配置错误可能带来的安全风险。\n3. 隐私。 需要扫描的是用户指定的一些隐私信息。比如用户不小心将密钥等信息存入镜像。如果在扫描配置中进行指定，扫描过程可能发现这些隐私信息，避免隐私泄露以及可能带来的安全问题。\n扫描引擎 常见的扫描引擎有 Trivy、Synk 等。Docker 官方使用的是 Synk，但它比较商业化；Trivy 是 CNCF 的项目，开放性较好。\n镜像扫描的使用方式 在我们的调研中，镜像扫描主要应用方式有三种：\n1. 基础使用。 镜像扫描的过程可以直接通过集成了镜像扫描引擎的容器运行时或者镜像扫描引擎命令行触发。比如运行 $ docker scan image-url ，可以扫描镜像，并输出相应的报告。\nsource：https://docs.docker.com/engine/scan/\n2. 流程集成。 镜像扫描的过程可以集成到镜像中心或者 CI/CD 流程中。比如将镜像扫描集成到数据中心，在每次镜像上传到数据中心时触发镜像扫描，可以保证从数据中心下载的镜像总是经过安全扫描的；集成在 CI/CD 流程中，设置触发条件，可以保证镜像生成，镜像部署等过程所使用的镜像的安全性。\nsource: https://www.containiq.com/post/container-image-scanning\n3. 扫描服务。 云厂商提供了镜像安全的服务。它们背后可能是基于前两种使用方式实现，但是还可以有很多种功能的增强。用户想使用镜像扫描的功能也可以直接购买类似的安全服务，并进行灵活的配置。\nsource: https://cloud.google.com/container-analysis/docs/on-demand-scanning-howto\nPART. 2 课题解决思路 基本思路 课题首先要解决的基本思路是，如项目描述一般为 Nydus 实现一个专属的镜像扫描工具；还是复用已有的镜像扫描引擎，在 Nydus 侧实现对接支持，从而完成 Nydus 镜像扫描的功能实现。\n我们最终选择了结合已有镜像扫描引擎的实现思路。尽管为 Nydus 实现一个专属的镜像扫描工具可以更好的利用 Nydus 的特性，但是从镜像功能生态上考虑，这并不是一个很好的方式。复用或者集成到现有的镜像扫描工具，一方面可以直接使用已实现的镜像扫描引擎中全面的内容扫描能力；另一方面，与上层镜像安全服务的对接也不用再重写相关接口。这样也可以减少一些功能定制，减少用户使用的负担。因此此课题选择了后一种实现的基本思路。\n扫描思路：FileSystem vs Image Trivy 扫描功能实现的框架 1. 控制路径。\nTrivy 在镜像扫描上由以下路径控制，每触发一次命令，会由一个 Scanner 控制。其中关键的是 artifact 和 driver 。扫描引擎一般可以支持多种格式的扫描，比如 OCI v1 镜像或者镜像 Rootfs，同时一般也支持本地或者远端存储信息等。这些一般可由 ScannerConfig 配置或者自动解析。\natifact 存储着镜像 (包括文件系统) 元信息，如果已经扫描过其中的内容，还可以存储部分解析后的信息。另外，load …","date":1672124400,"description":"Nydus 镜像扫描加速","dir":"blog/nydus-mirror-scan-acceleration/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c1a6786f703b2475c84aad66b06e85b5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-mirror-scan-acceleration/","publishdate":"2022-12-27T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/nydus-mirror-scan-acceleration/","summary":"文｜余硕 上海交通大学22届毕业生阿里云开发工程师 从事云原生底层系统的开发和探索工作。 本文 6369 字 阅读 16 分钟 GitLink 编程夏令营是在 CCF 中国计算机学会指导下","tags":["SOFAStack"],"title":"Nydus 镜像扫描加速","type":"blog","url":"/sofastack.tech/blog/nydus-mirror-scan-acceleration/","wordcount":5496},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 小白\n SOFAArk 可以把 2 个端口不一样的 Spring Boot 微服务合并到一起部署吗？比如一个是 8080 另一个端口是 8081，2 个服务都有各自的接口， 合并部署后还可以通过对应的端口来进行访问嘛？\n A：不使用 Web-Ark-Plugin 插件，每个模块会启动新的 Tomcat 实例，可以让服务用不同的 port。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2. 肖文璧 提问\n Seata 对 Java17 的版本有支持吗？\n A：A：需要 v1.6.0 版本。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1671778800,"description":"SOFA Weekly | 新年礼包已就位、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-202211223/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"af3eb0769d6765dd7994becf03bd4a1c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-202211223/","publishdate":"2022-12-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-202211223/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 新年礼包已就位、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-202211223/","wordcount":578},{"author":null,"categories":"SOFAStack","content":" 文｜戚文博 （花名：百蓦）\nDragonfly Maintainer蚂蚁集团软件工程师\n主要负责「基于 P2P 的文件以及镜像加速系统」。\n本文 2175 字 阅读 15 分钟\nPART. 1 背景 自 17 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 18 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会 （TOC） 投票决定接受 Dragonfly 作为孵化级别的托管项目。Dragonfly 多年生产实践经验打磨的下一代产品，它汲取了上一代 Dragonfly1.x[1] 的优点并针对已知问题做了大量的优化。\nNydus 作为 Dragonfly 的子项目优化了 OCIv1 镜像格式，并以此设计了一个用户态文件系统，使容器可以按需下载镜像，不再需要下载完整镜像即可启动容器。在最新版本中 Dragonfly 完成了和子项目 Nydus 的集成，让容器启动即可以按需下载镜像，减少下载量。也可以在传输过程中利用 Dragonfly P2P 的传输方式，降低回源流量并且提升下载速度。\nPART. 2 实践 注:如果没有可用的 Kubernetes 集群进行测试，推荐使用 Kind[2]。\n安装 Dragonfly\n基于 Kubernetes cluster 详细安装文档可以参考：\nhttps://d7y.io/docs/next/getting-started/quick-start/kubernetes/ 。\n使用 Kind 安装 Kubernetes 集群\n创建 Kind 多节点集群配置文件 kind-config.yaml ，配置如下:\nkind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker extraPortMappings: - containerPort: 30950 hostPort: 65001 - role: worker 使用配置文件创建 Kind 集群:\nkind create cluster --config kind-config.yaml 切换 Kubectl 的 context 到 Kind 集群:\nkubectl config use-context kind-kind Kind 加载 Dragonfly 镜像\n下载 Dragonfly latest 镜像:\ndocker pull dragonflyoss/scheduler:latest docker pull dragonflyoss/manager:latest docker pull dragonflyoss/dfdaemon:latest Kind 集群加载 Dragonfly latest 镜像:\nkind load docker-image dragonflyoss/scheduler:latest kind load docker-image dragonflyoss/manager:latest kind load docker-image dragonflyoss/dfdaemon:latest 基于 Helm Charts\n创建 Dragonfly P2P 集群\n创建 Helm Charts 配置文件 charts-config.yaml 并且开启 Peer 的预取功能, 配置如下:\nscheduler: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 seedPeer: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 download: prefetch: true dfdaemon: hostNetwork: true config: verbose: true pprofPort: 18066 metrics: :8000 download: prefetch: true proxy: defaultFilter: \u0026#39;Expires\u0026amp;amp;Signature\u0026amp;amp;ns\u0026#39; security: insecure: true tcpListen: listen: 0.0.0.0 port: 65001 registryMirror: dynamic: true url: https://index.docker.io proxies: - regx: blobs/sha256.* manager: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 使用配置文件部署 Dragonfly Helm Charts:\n$ helm repo add dragonfly https://dragonflyoss.github.io/helm-charts/$ helm install --wait --create-namespace --namespace dragonfly-system dragonfly dragonfly/dragonfly -f charts-config.yamlNAME: dragonflyLAST DEPLOYED: Wed Oct 19 04:23:22 2022NAMESPACE: dragonfly-system STATUS: deployedREVISION: 1TEST SUITE: None NOTES: 1. Get the scheduler address by running these commands: export SCHEDULER_POD_NAME=$(kubectl get pods --namespace dragonfly-system -l \u0026amp;quot;app=dragonfly,release=dragonfly,component=scheduler\u0026amp;quot; -o jsonpath={.items[0].metadata.name}) export SCHEDULER_CONTAINER_PORT=$(kubectl get pod --namespace dragonfly-system $SCHEDULER_POD_NAME -o jsonpath=\u0026amp;quot;{.spec.containers[0].ports[0].containerPort}\u0026amp;quot;) kubectl --namespace dragonfly-system port-forward $SCHEDULER_POD_NAME 8002:$SCHEDULER_CONTAINER_PORT echo \u0026amp;quot;Visit http://127.0.0.1:8002 to use your …","date":1671519600,"description":"Dragonfly 和 Nydus Mirror 模式集成实践","dir":"blog/dragonfly-and-nydus-mirror-mode-integration-practice/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"75467253523cbbd18d6aef01e3449eb4","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","publishdate":"2022-12-20T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","summary":"文｜戚文博 （花名：百蓦） Dragonfly Maintainer蚂蚁集团软件工程师 主要负责「基于 P2P 的文件以及镜像加速系统」。 本文 2175 字 阅读 15 分钟 PART. 1 背景 自 17 年开","tags":["SOFAStack"],"title":"Dragonfly 和 Nydus Mirror 模式集成实践","type":"blog","url":"/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","wordcount":2729},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.小白 提问：\n 运行之后我发现和文档写的不一样 biz 和宿主的 Spring Boot 没有隔开，文档上写的是 2.6.6 和 2.5.0 但是实际启动都是 2.6.6，这是怎么回事？\n A：不建议用不同 Spring Boot，多 host 模式只要不使用 Web-Ark-Plugin 是可以的；我用 Sofa-Ark-Spring-Guides 试了一下，可以设置不同的 host。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.吴东梁 提问：\n 保存在内存里的事务信息多久会删除一次，来避免 OOM？\n A：结束就删。\n 那如果在事务结束之后只删内存的数据，不删除数据库里面数据会不会产生问题？\n A：没有内存和数据库共用的版本，不会的。\n「Seata」：https://github.com/seata/seata\nTongsuo 8.3.2 版本发布 主要变更如下：\n1.修复 C90 下的编译问题；\n2.修复 SSL_CTX_dup() 函数的 bug；\n3.修复 NTLS ServerKeyExchange 消息的 RSA 签名问题；\n4.修复 apps/x509 的 SM2 证书签名 bug；\n5.支持新特性 - 添加导出符号前缀。\n下载地址：\nhttps://github.com/Tongsuo-Project/Tongsuo/releases/tag/8.3.2\n本周推荐阅读 Tongsuo 支持半同态加密算法 Paillier\n金融级应用开发｜SOFABoot 框架剖析\nSeata AT 模式代码级详解\nSOFA 飞船 Layotto 星球登陆计划最新进展\n欢迎扫码关注：\n","date":1671174000,"description":"SOFA Weekly | Tongsuo 8.3.2 版本发布、C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221216/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a5844a518eb6396a88e6c0ad05c590bc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221216/","publishdate":"2022-12-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221216/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Tongsuo 8.3.2 版本发布、C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221216/","wordcount":728},{"author":null,"categories":"SOFAStack","content":" 文｜李大元 （花名：达远）\nKusion 项目负责人\n来自蚂蚁集团 PaaS 核心团队，PaaS IaC 基础平台负责人。\n本文 4331 字 阅读 11 分钟\nPART. 1 后云原生时代 距离 Kubernetes 第一个 commit 已经过去八年多了，以其为代表的云原生技术早已不再是什么新技术，而是现代化应用的“标配”。现代化应用依赖的基础服务远不止 Kubernetes 一种，稍微复杂点的应用往往会同时使用到 Kubernetes 生态云原生技术、IaaS 云服务、企业内部自建系统等各种异构基础设施，可能还会有多云、混合云的部署需求，我们已经进入到了 ”后云原生时代”，只针对 Kubernetes 的运维工具早已不能满足我们的诉求。\n更复杂的是，在企业内部，这些服务一般是由不同团队维护的，一次规模化运维需要多个团队的成员互相配合才能完成，但是 App Dev、Platform Dev、SRE 各个团队之间缺少高效的协作方式。技术自身的复杂性加上低效的团队协作，使得 “后云原生时代” 的规模化运维难度有了指数级的提高。\nPART. 2 规模化运维的问题一直都在 复杂异构基础设施的规模化运维，这并不是后云原生时代特有的问题，自分布式系统诞生以来，一直都是一个难题，只是在后云原生时代，这个问题变得更加困难。十多年前业界提出了 DevOps 理念，无数企业基于此理念构建了自己的 DevOps 平台，希望解决此问题，但在实际落地的过程中往往不尽人意，Dev 团队和 Ops 团队之间如何合作？职责如何划分？几十人的平台团队，如何支持几万工程师的运维诉求？底层基础设施复杂多样，能力日新月异，如何快速让一线 Dev 享受到技术红利？这些问题一直没有得到很好的解决，最近又有人提出了 DevOps 已死，Platform Engineering 才是未来的说法。抛开概念定义，无论是 DevOps 还是 Platform Engineering，本质上都是企业规模化运维这同一命题下的不同理念，我们更需要的是一个符合技术发展趋势，能解决当前问题的解决方案。\nPART. 3 传统架构不再适用 在传统的运维思路中，解决上述问题的方法一般是构建一个 PaaS 平台，例如我们早期的蚂蚁 PaaS 平台，他是一个 Web 控制台，有 UI 界面，用户（通常是 App Dev 或 SRE）通过 UI 交互可以完成诸如发布、重启、扩缩容等操作。在技术实现上大体可以分为三部分，一个前端系统，提供用户交互的能力，作为系统入口；中间是一个后端系统，对接各个基础设施；底层是各个基础设的 API。这种架构运行了近十年，一直运行的很好，既有用户友好的交互界面，又可以屏蔽基础设施复杂性，而且各个团队之间还职责分明，但是到了如今后云原生时代，这种架构不再适用，暴露出有两个致命缺点， “费人” 、 “费时” 。\n举一个常见的例子，网络团队为其负责的 Loadbalancer（负载均衡器）开发了一种新的负载算法，需要提供给用户使用。\n在上述架构下，整个工作流程是这个样子：\n1.网络团队开发好能力，提供出 API；\n2.PaaS 后端通过编码对接底层 API，进行互联互通，屏蔽复杂性，提供面向用户的更高级别 API；\n3.PaaS 前端根据新功能修改 UI，利用后端 API 把能力透出给最终用户。\n这里存在一个问题，即使一个再小的功能，也需要 PaaS 后端和前端修改代码，整个流程下来最快也要一周才能上线，而且涉及的基础设施团队越多，效率越低。这个问题在十年前并不算是一个问题，但是在今天就是一个很大的问题，一个后云原生时代的现代化应用，使用三个云原生技术（Kubernetes + Istio + Prometheus），两个云服务（Loadbalancer + Database），一个内部自建服务，已经是一个很常见的形态了，复杂应用只会依赖的更多。如果每个基础设施都由 PaaS 团队硬编码对接一遍，PaaS 团队的人再扩大十倍也不够用。\n“费人”讲完了，我们再看看“费时”的问题。上面例子里的一个小功能，需要进行两次跨团队的协作，一次基础设施和 PaaS 后端，另一次是 PaaS 后端与 PaaS 前端。团队协作是一个很难的问题，有时候比技术本身还要难。应用的架构已经很复杂了，如果要做一次规模化运维，一次运维 100 个应用，这要和多少个团队沟通协作？要花费多少时间？没有好的协作机制，这就变成了一个不可能完成的任务。\nPART. 4 探索与实践 我们在蚂蚁集团内部进行了近两年的探索，kustomize、helm、argoCD、Terraform 这些常见的工具我们都实践过，甚至还为一些工具自研了一些辅助系统，但结果并不尽人意。这些工具要么太局限于 Kubernetes 生态，运维不了其他类型的基础设施，要么就是支持了异构基础设施，但对于 Kubernetes 生态支持的不友好，无法发挥出云原生技术的优势，而且只是运维工具的升级对于团队协作效率几乎没有提升，我们需要一套更加体系化的方案。\n回到问题本身，针对“费人”、“费时”的问题，我们提出两个思路：\n1.能否不让 PaaS 做中转，而是由 App Dev 通过一种高效自助的方式，使用到互联互通的各种基础设施能力？\n2.能否构建一个中心化的协作平台，用技术的手段规范大家的行为，标准化的进行沟通？\n从技术的角度来看，PaaS 平台需要提供灵活的工具链和工作流，基础设施所有能力都通过模块化的方式暴露出来，App Dev 利用这些平台的基本能力，自己组合、编排来解决自己的问题，过程中不需要平台层的参与。并且整个过程中涉及的所有团队，都使用统一的语言和接口进行交流，全程无需人工参与。\nPART. 5 我们的实践 经过在蚂蚁内部 PaaS 平台近两年的探索与实践，沉淀出一套端到端的完整方案， 取名为 KusionStack，目前已经开源。试图从统一异构基础设施运维与团队协作两个角度解决传统 PaaS “费人”、“费时”的问题。\n整个体系主要分为三个部分：\n1.Konfig：Git 大库，是多团队协作的中心化平台，存放着各个团队的运维意图；\n2.KCL：蚂蚁自研的配置策略 DSL，所有团队间交流的工具；\n3.Kusion：KusionStack 引擎，负责所有的运维操作。\nPlatform Dev 通过 KCL 定义好基础能力模型，App Dev 通过 import、mixin 等语言特性在应用配置模型（AppConfig）里复用这些预定义好的能力，快速在 Konfig 里描述运维意图。AppConfig 是一个精心设计过的模型，只暴露 App Dev 需要关心的属性，屏蔽基础设施的复杂性。\n永远不要低估基础设施的专业性与复杂性，即使已经成为云原生技术标准的 Kubernetes，对普通用户来说依然有很高的门槛，一个 Deployment 就有几十个字段，再加上自定义的 labels、annotations 就更多了，普通用户根本无法全部理解。或者说普通 AppDev 不应该去了解 Kubernetes，他们需要的只是发布，甚至不需要关心底层是不是 Kubernetes。\nAppConfig 经过编译 …","date":1671174000,"description":"已来到 “后云原生时代” 的我们，如何规模化运维？","dir":"blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"79ce4a433a89df3cd7edcf19c450a1f0","permalink":"https://sofastack.github.io/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","publishdate":"2022-12-16T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","summary":"文｜李大元 （花名：达远） Kusion 项目负责人 来自蚂蚁集团 PaaS 核心团队，PaaS IaC 基础平台负责人。 本文 4331 字 阅读 11 分钟 PART. 1 后云原生时代 距离 Kubernetes 第一个 commit 已经过","tags":["SOFAStack"],"title":"已来到 “后云原生时代” 的我们，如何规模化运维？","type":"blog","url":"/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","wordcount":3707},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#31:RPC 框架设计的考和量\n 活动时间：12 月 15 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#31 RPC 框架设计的考和量 本议题主要介绍 RPC 相关的概念和知识，和设计一个 RPC 框架需要关注的方面，以及从服务治理角度再谈 RPC 框架的设计，同时介绍 SOFARPC 在这些方面是如何实现的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 刘建军（花名：保义）\n SOFARPC Maintainer\n 蚂蚁集团基础组件研发，SOFARPC 开发者和维护者\n 议程 直播回放 https://www.bilibili.com/video/BV1pD4y187Gh/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1671087600,"description":"2022 年 12 月 15 日 19：00 - 20：00 ，线上直播第 31 期。","dir":"activities/sofachannel-31/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e59afb3aad30a8e2d7bc88251a256b03","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofachannel-31/","publishdate":"2022-12-15T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofachannel-31/","summary":"概要 活动主题：SOFAChannel#31:RPC 框架设计的考和量 活动时间：12 月 15 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播","tags":["SOFAChannel","SOFARPC","RPC 框架设计的考和量"],"title":"SOFAChannel#31 RPC 框架设计的考和量","type":"activities","url":"/sofastack.tech/activities/sofachannel-31/","wordcount":433},{"author":null,"categories":"SOFAStack","content":" 文｜王发康 （花名：毅松 ）\n蚂蚁集团技术专家、MOSN 项目核心开发者\n深耕于高性能网络服务器研发，目前专注于云原生 ServiceMesh、Nginx、MOSN、Envoy、Istio 等相关领域。\n本文 5574 字 阅读 14 分钟\n前言 从单体到分布式，解决了日益增长的业务在单体架构下的系统臃肿问题；从分布式到微服务，解决了服务化后的服务治理问题；从微服务到服务网格，解决了应用和基础设施耦合下的研发效能及稳定性问题。\n从微服务架构的演进历史来看，任何架构都不是一成不变，总是随着应用在不同阶段的痛点以及周边技术的发展而持续演进，而服务网格 （ServiceMesh） 概念从提出到生产落地至今已 6 年多了，那它的下一代架构应该是什么样？对此业界也有不同的声音 Service Mesh 的下一站是 Sidecarless 吗[1] ，本文主要介绍蚂蚁在这方面的探索和实践，最终如何帮业务降本增效，提升安全保障水位。\n一、 问题及挑战 谈起 ServiceMesh，大家的脑海中应该会呈现出下面这幅图，即 ServiceMesh 的 Sidecar 形态，它非常好的解决了应用和基础设施耦合下的系列问题，为业务的提效及稳定性等方面然禹功不可没。\n但是随着 ServiceMesh 的规模化增大，Sidecar 架构也随之暴露了一些劣势，譬如应用和 Sidecar 资源耦合导致相互抢占、生命周期绑定，导致应用扩缩容涉及额外 Sidecar 容器的创建及销毁开销、Sidecar 数量随着应用 Pod 数等比增加，导致其资源无法充分复用等。\n引用 redhat.com/architect/why-when-service-mesh\n1.1 资源耦合 Sidecar 形态虽然从代码维度是解耦了基础设施与应用的耦合，但是在资源方面目前仍然是和应用 Pod 绑定在一起，这就导致其资源管理成为一个难题。对此蚂蚁 ServiceMesh 在 Sidecar 资源管理[2] 进行改善，解决了初期的资源分配及管理。但随着业务的发展也暴露一些隐患，一方面 Sidecar 和应用相互抢占 CPU 可能导致引发时延毛刺问题，另一方面固定的 1\u0026amp;frasl;4 内存资源可能无法满足机房规模增大引发的网络连接数膨胀等系列问题。\n1.2 生命周期绑定 Sidecar 和应用属于同一个 Pod，而 K8s 是以 Pod 为最小单位进行管理的。这导致应用在扩缩容操作时会涉及额外 Sidecar 容器的创建及销毁开销，而 Sidecar 中的进程是基础设施软件本不应该随着应用的销毁而销毁。\n1.3 资源复用不充分 Sidecar 数量随着应用 Pod 数等比增加，而 Sidecar 上运行的都是基础设施通用能力，这将导致 Sidecar 中应用无关逻辑的 CPU 和内存等开销都在每个 Pod 中重复消耗。另外对于一些本能通过软件集中优化或硬件集中卸载的计数也无法充分施展。\n1.4 安全及业务侵入性 Sidecar 同应用同属一个 Pod，这无论对于 Sidecar 还是应用自身都是增大了安全攻击切面，另一方面 Sidecar 形态的服务治理也不算是完全业务无感的，至少要做一次 Sidecar 的注入，然后重启应用 Pod 才生效。\n二、思考及分析 对于上述 Sidecar 形态下的四个痛点：资源耦合、生命周期绑定、资源复用不充分、安全及业务侵入性，其实归根结底还是其架构导致。\n如果将 Sidecar 从应用 Pod 中剥离出来，对于资源耦合、生命周期绑定、安全侵入性问题都会迎刃而解，而资源复用粒度取决于剥离后部署的集中化程度。对于剥离后的集中化程度也并不是越集中越好，因为中心化后会增加交互时延以及能力的完整性缺失，所以在中心化和 Sidecar 化之间做一次折中，即通过 Node 化部署形态来解决，这样既可以做到同 Node 上的 Mesh 资源复用，又可以做到网络交互不跨 Node 的相关优化。\n虽然解决了 Sidecar 形态下的痛点，但是 Node 化后也引入了一些新的 “问题”。对于问题我们需要用辩证的眼光去看待，有时问题的背后可能是一个新机会。\n譬如 Sidecar 形态下的服务发现都是 Pod 级别，随着 Pod 规模的增大其服务条目成倍速增加，如果 Node 化后服务发现使用 Node IP 这样是不是可以成本的缩减服务条目，亦达到网络连接数的复用及收敛。\n- 隔离性、多租户： 多个应用共享 Mesh 后，涉及的一些应用维度的配置、内存、CPU 等资源如何相互隔离，另外对于 Sidecar 中各种基础设施组件如果自身来支持多租户，则改造成本是不可预估的。\n- 服务 pub/sub： 之前 Sidecar 形态下，Sidecar 和 APP 的 IP 是同一个 （Container 网络模式） ，Node 化后 IP 变成 Daemonset 容器的 IP，服务发现应如何管理？以及 Pod 和 Node 之间的流量如何管理。\n- 运维及安全合规\n a. Node 化后涉及到 Daemonset 自身以及应用维度的配置升级发布流程如何管控，同时出现故障时如何缩小爆炸半径；\n b. Node 化后涉及到的安全合规问题如何保证，如网络连通性如何隔离、身份等；\n c. Node 化后，Daemonset 所占用的机器成本如何规划 （超卖？独占？） 以及各个应用的资源消耗如何计算。\n三、方案介绍 将应用 Pod 中的 Sidecar 下沉到 Node，以 Daemonset 方式在每个 Node 部署。我们将该 Daemonset 命名为 NodeSentry，其定位是作为 Node 的网络基础设施，承载网络安全、流量治理、Mesh 下沉、连接收敛等 Node 相关网络治理平台。\n本文主要介绍 NodeSentry 承载 Mesh 下沉相关方案，Node 化后需要数据面 Proxy 能够高效、稳定的承载多个 Pod 的流量治理。这就要求数据面 Proxy 具备高处理性能及高研发效能，为此我们在 2021 年就其做了相关技术布局 MOSN2.0，详细介绍见 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态[3] 。\nMesh 下沉至 NodeSentry 其架构如上图所示，在新的架构下不仅能解决 Sidecar 形态的痛点，同时也具备了如下收益：\n- 资源解耦：解耦应用和基础设施的资源配额，多应用的 Mesh 资源池化、削峰填谷；\n- 资源复用：同 Node 同应用 Mesh 共享，ingress 方向连接收敛 、egress 方向连接共享、Node 级粒度 cache 命中率更高等；\n- Node 服务发现体系：解决注册中心等基础设施服务端压力以及调用端的内存消耗；\n- 提升启动速度：新架构下应用无需每次都启动 Mesh 的容器及镜像下载、SDK 初始化共享等额外操作；\n- 集中优化：云原生 L7 网络协议栈，软硬件结合性能优化，支持 IPV6，蚂蚁卡，RDMA or QUIC 等；\n- 解耦应用和网络： 同 Zero Trust Networking[4] 相关技术结合实现全局调度，有限互通等。 …","date":1670914800,"description":"降本增效：蚂蚁在Sidecarless 的探索和实践","dir":"blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7ece9ce602bb943fa14d61d09a0114a1","permalink":"https://sofastack.github.io/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","publishdate":"2022-12-13T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","summary":"文｜王发康 （花名：毅松 ） 蚂蚁集团技术专家、MOSN 项目核心开发者 深耕于高性能网络服务器研发，目前专注于云原生 ServiceMesh、Ngin","tags":["SOFAStack"],"title":"降本增效：蚂蚁在 Sidecarless 的探索和实践","type":"blog","url":"/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","wordcount":4731},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.小白 提问：\n 这个配置是起到什么作用？true\n A：declaredMode 是指：如果 biz 和宿主 biz 依赖相同的包，biz 会使用宿主 biz 内的包。即：biz 该包设置成 provided 时，安装 biz 至宿主 biz 可以正常使用，从而减小了 biz 的体积。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.肖才稳 提问：\n Seata 的回滚模式，如果数据库被其他应用改了，是不是不能回滚了？Seata 必须保证数据库只有自己一个应用用了是吗？\n A：那你可以用 XA，AT 是要保证所有操作数据库的动作都在 Seata 事务的全局事务覆盖下。也就是说，如果你这个库的这个表被其他应用用了，让这个应用也集成 Seata 就行了。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 cgo 机制 - 从 c 调用 go\nGo 内存泄漏，pprof 够用了么?\nSeata AT 模式代码级详解\nSOFA 飞船 Layotto 星球登陆计划最新进展\n欢迎扫码关注：\n","date":1670569200,"description":"SOFA Weekly | MOSN v1.3.0 版本发布、公众号半自助投稿、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221209/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c276f5a6fa8b10d73ba44cb43b79ea22","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221209/","publishdate":"2022-12-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221209/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.3.0 版本发布、公众号半自助投稿、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221209/","wordcount":664},{"author":null,"categories":"SOFAStack","content":" 文｜田阳 （花名：烈元）\nMOSN Maintainer\n专注云原生等技术领域\n本文3042字 阅读 10 分钟\n1. 背景 Service Mesh 被越来越多的公司认可并实践，在实际落地过程中也遇到了形形色色的问题，同时架构也在持续演进去解决这些问题：有的从初始的 DaemonSet mode 转变为 Sidecar mode，如 Linkerd ；有的从做 CNI 延伸到 Service Mesh 场景， 结合 eBPF 使用 DaemonSet mode，如 Cilium ；如今 Istio 也新增了 Ambient Mesh ，支持 DaemonSet mode 作为其主推模式。\n不难看出一个演进趋势就是围绕着是否需要 Sidecar 而展开，那么 Service Mesh 的下一站将会是 Sidecarless 吗？本文将对目前的社区趋势做一个简要分析， 最后也将介绍蚂蚁在这方面的探索和实践。\n2. 社区趋势 2.1 Cilium Cilium[1] 是目前最火的云原生网络技术之一，基于革命性的内核技术 eBPF，提供、保护和观察容器工作负载之间的网络连接。\n在 6 月份，Cilium 发布了 1.12 版本，其中发布了 Service Mesh 能力、Sidecarless 架构，它提供了两种模式：\n通过图表我们可以发现：针对 L3/L4 的能力，Cilium 使用内核的 eBPF 直接支持；对于 L7 的部分能力，将使用 DaemonSet 部署的 Envoy 来支持。Cilium 认为大部分能力都不需要 L7 的参与，通过 eBPF 就能满足，所以 Cilium 也称自己为内核级服务网格。\n针对于此 Cilium 也有一个解释，结合应用程序 TCPD 最终被合入 linux kernel 发展为 iptables 为例，认为 Mesh 也应该作为基础能力下沉到 linux kernel 作为网络的基础组件，就类似于 TCP，作为 Linux 的一部分透明地提供的服务。\n在当需要 L7 代理能力的时候，会构建 DaemonSet Envoy 处理 L7 的能力。Envoy 也已经有了 Namespace 的初步概念，它们被称为监听器。监听器可以携带单独的配置并独立运行，从而可以支持多租户的配置隔离 (但目前还做不到资源和故障的隔离） 。\nCilium 认为 DaemonSet 相比 Sidecar 最明显的好处就是代理数大大减少，减少资源和管理成本。\n可以看出 Cilium Service Mesh 的发展历程是由下而上，从内核层慢慢向业务层扩展自己的服务边界，由 eBPF 来支持服务网络也是有一定的立场因素。但 eBPF 并不是银弹，DaemonSet mode 也是有一些其他的问题，收益和损失都是相对的。\n2.2 Linkerd 当然，Cilium 这个架构也不乏有挑战者，其中来头最大的就是 Linkerd[2] （Service Mesh 概念的提出者） 的创始人 William Morgan ，比较有意思的是 Linkerd 最开始的架构是 DaemonSet mode ，在后面的版本才换成 Sidecar mode ，对于此，作为逆行者的他应该最有发言权。\n在 William Morgan 的最新文章[3] 中也客观提出了 eBPF 的一些局限性，为了保证 eBPF 的安全执行而不影响 kernel ，需要通过验证器验证是否有不正确的行为，这就导致 eBPF 的编写存在一定的潜规则，比如不能有无界循环；不能超过预设的大小等，代码的复杂性也就受到了一定限制。所以较复杂的逻辑用 eBPF 来实现也是有较高的成本的。\n文章中也提到了 DaemonSet 的一些弊端：\n- 资源管理不可评估：这取决于 K8s 调度多少 Pod 到该 Node；\n- 隔离性：所有应用公用一个 Proxy ，相互影响稳定性；\n- 爆炸半径变大：影响整个 Node 的 Pod 实例；\n- 安全问题更复杂：比如 Proxy 保存有整个 Node 的秘钥。\n简而言之，Sidecar 模式继续贯彻了容器级别的隔离保护 —— 内核可以在容器级别执行所有安全保护和公平的多租户调度。容器的隔离仍然可以完美的运行，而 DaemonSet 模式却破坏了这一切，重新引入了争抢式的多租户隔离问题。\n当然他也认为 eBPF 可以更好的促进 Mesh 的发展，eBPF+Sidecar 的结合是 Mesh 的未来。\n 我们也比较认可他对于 eBPF 的看法， eBPF 就像是一把瑞士军刀，小巧精湛，作为胶水把各种网络数据面连接起来，提供基础网络能力，比如提供访问加速，透明劫持，网络可观察性等能力。但要开发复杂的业务能力，在实操之后，感觉还是有点力不从心。目前我们团队也正在使用 eBPF 开发 K8s Service 和透明拦截等基础网络能力。\n William Morgan 的说法看着也不无道理，我们先不急着站队，再来看看 Istio 是怎么做的，看是否会有新的想法~\n2.3 Istio 在 9 月份，Service Mesh 领域的当家花旦 Istio 毫无征兆的发布了 Ambient Mesh ，并作为自己后续的主推架构，简单来讲就是把数据面从 Sidecar 中剥离出来独立部署，Sidecarless 架构，以彻底解决 Mesh 基础设施和应用部署耦合的问题。\n 比较好奇 Istio 在没有经过社区讨论和落地案例的情况下，是怎样决策笃定这个新的架构方向的呢？\n Istio 认为 Sidecar mode 存在如下三个问题：\n- 侵入性\n必须通过修改应用程序的 Kubernetes pod spec 来将 Sidecar 代理 “注入” 到应用程序中，并且需要将 Pod 中应用的流量重定向到 Sidecar 。因此安装或升级 Sidecar 需要重新启动应用 Pod ，这对工作负载来说可能是破坏性的。\n- 资源利用不足\n由于每个 Sidecar 代理只用于其 Pod 中相关的工作负载，因此必须针对每个 Pod 可能的最坏情况保守地配置 Sidecar 的 CPU 和内存资源。这导致了大量的资源预留，可能导致整个集群的资源利用不足。\n- 流量中断\n流量捕获和 HTTP 处理 通常由 Sidecar 完成，这些操作的计算成本很高，并且可能会破坏一些实现和 HTTP 协议不完全兼容的应用程序。\nEnvoy 的创始人也来凑了个热闹，他对 Sidecar 架构也是颇有微词。\n我们在落地过程中也是遇到了类似的痛点，比如随着机房规模和应用规模的变大，应用的连接数继续膨胀导致 CPU 和 MEM 资源占用也在持续增加，但这一切都不是应用本身想去关心的。\n那么让我们来解开 Ambient Mesh 架构真面目，是怎样来解决 Sidecar mode 的问题， 架构主要提出了分层：\n从图中可以看出，跟 Cilium 有一些类似，这儿的两层数据面都是基于 Envoy 来构建的，Secure Overlay Layer 主要处理 L4 场景，DaemonSet 部署，L7 processing Layer 主要处理 L7 场景， …","date":1669705200,"description":"Service Mesh 的下一站是 Sidecarless 吗？","dir":"blog/is-sidecarless-the-next-stop-for-servicemesh/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"620c3d0c618cffbc58020852e1ed722d","permalink":"https://sofastack.github.io/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","publishdate":"2022-11-29T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","summary":"文｜田阳 （花名：烈元） MOSN Maintainer 专注云原生等技术领域 本文3042字 阅读 10 分钟 1. 背景 Service Mesh 被越来越多的公司认可并实践，在实际落地过程中也遇到了形形色色","tags":["SOFAStack"],"title":"Service Mesh 的下一站是 Sidecarless 吗？","type":"blog","url":"/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","wordcount":3215},{"author":null,"categories":"SOFAStack","content":" 文｜王祖熙（花名：金九 )\n蚂蚁集团开发工程师\n负责国产化密码库 Tongsuo 的开发和维护\n专注于密码学、高性能网络、网络安全等领域\n本文 4316 字 阅读10 分钟\n1. 背景 在《Tongsuo 支持半同态加密算法 EC-ElGamal》中，已经阐述了同态和半同态加密算法的背景和原理，可以移步查阅。总之，同态算法在隐私计算领域有着重要的作用，目前应用比较广泛的是 Paillier 和 EC-ElGamal 半同态加密算法，它们接口类似且只支持加法同态。\n但是它们两者的性能和原理有很大的差异：\n原理方面，Paillier 是基于复合剩余类的困难性问题 （大数分解难题） 的公钥加密算法，有点类似 RSA；而 EC-ElGamal 是基于椭圆曲线数学理论的公钥加密算法，其安全性理论上要比 Paillier 要更好。\n性能方面，EC-ElGamal 的加密和密文加法性能要比 Paillier 好；而 Paillier 的解密和密文标量乘法性能要比起 EC-ElGamal 要更好更稳定 （EC-ElGamal 的解密性能与解密的数字大小有关系，数字越大可能需要解密的时间越长，这与 EC-ElGamal 解密用到的解密表有关系，而 Paillier 的解密就没有这个问题。） 。\n所以这两个产品各有优劣，大家可以根据自己的业务特点选择使用 Paillier 还是 EC-ElGamal。\n2. Paillier 原理 2.1 密钥生成 1.随机选择两个大素数 p、q，满足 ，且满足 p 和 q 的长度相等；\n2.计算以及 ，表示最小公倍数；\n3.随机选择整数，一般 g 的计算公式如下： a. 随机选择整数； b. 计算：，为了简化和提高性能，k 一般选 1，g=1+n；\n4.定义 L 函数：，计算：；\n5.公钥：(n, g)，私钥：(λ, μ)。\n2.2 加密 明文 m，满足 −n\u0026amp;lt;m\u0026amp;lt;n；\n 选择随机数 r，满足 0≤r\u0026amp;lt;n 且 ；\n 计算密文：。\n 2.3 解密\n 密文 c，满足；\n 计算明文：。\n 2.4 密文加法\n 密文：c1 和 c2，，c 就是密文加法的结果。 2.5 密文减法\n 密文：c1 和 c2，计算：，c 就是密文减法的结果。 2.6 密文标量乘法\n 密文：c1，明文标量：a，计算：，c 就是密文标量乘法的结果。 3. 正确性 3.1 加解密正确性 公式推导需要用到 Carmichael 函数和确定合数剩余的公式，下面简单说明一下：\n● Carmichael 函数\na. 设 n=pq，其中：p、q 为大素数；\nb. 欧拉函数：ϕ(n) ，Carmichael 函数：λ(n)；\nc. 当 和时，\n其中：。\n对于任意 ，有如下性质：。\n● 判定合数剩余\na. 判定合数剩余类问题是指 n=pq，其中：p、q 为大素数，任意给定，使得，则说 z 是模 的第 n 次剩余；\nb. 第 n 项剩余的集合是 的一个阶乘法子集；\nc. 每个第 n 项剩余 z 都正好拥有 n 个 n 阶的根，其中只有一个是严格小于 n 的 （即 ） ；d. 第n项剩余都可以写成 的形式。\n● 正确性验证\n解密：\n3.2 密文加法正确性 3.3 密文减法正确性 3.4 密文标量乘法正确性 4. 算法实现 4.1 接口定义 ●对象相关接口\n○公/私钥对象：PAILLIER_KEY ，该对象用来保存 Paillier 公钥和私钥的基本信息，比如 p、q、n、g、λ、μ 等信息，私钥保存所有字段，公钥只保存 n、g，其他字段为空或者 0。相关接口如下：\n// 创建 PAILLIER_KEY 对象 \\PAILLIER_KEY *PAILLIER_KEY_new(void); // 释放 PAILLIER_KEY 对象 void PAILLIER_KEY_free(PAILLIER_KEY *key); // 拷贝 PAILLIER_KEY 对象，将 src 拷贝到 dest 中 PAILLIER_KEY *PAILLIER_KEY_copy(PAILLIER_KEY *dest, PAILLIER_KEY *src); // 复制 PAILLIER_KEY 对象 PAILLIER_KEY *PAILLIER_KEY_dup(PAILLIER_KEY *key); // 将 PAILLIER_KEY 对象引用计数加1，释放 PAILLIER_KEY 对象时若引用计数不为0则不能释放其内存 intPAILLIER_KEY_up_ref(PAILLIER_KEY *key); // 生成 PAILLIER_KEY 对象中的参数，bits 为随机大素数 p、q 的二进制位长度 int PAILLIER_KEY_generate_key(PAILLIER_KEY *key, int bits); // 获取 key 的类型：公钥 or 私钥 // PAILLIER_KEY_TYPE_PUBLIC 为私钥，PAILLIER_KEY_TYPE_PRIVATE 为私钥 int PAILLIER_KEY_type(PAILLIER_KEY *key); ○上下文对象：PAILLIER_CTX，该对象用来保存公私钥对象以及一些其他内部用到的信息，是 Paillier 算法其他接口的第一个参数。相关接口如下：\n// 创建 PAILLIER_CTX 对象，key 为 paillier 公钥或者私钥，threshold 为支持最大的数字阈值，加密场景可设置为 0，解密场景可使用默认值： PAILLIER_MAX_THRESHOLDPAILLIER_CTX *PAILLIER_CTX_new(PAILLIER_KEY *key, int64_t threshold); // 释放 PAILLIER_CTX 对象 void PAILLIER_CTX_free(PAILLIER_CTX *ctx); // 拷贝 PAILLIER_CTX 对象，将 src 拷贝到 dest 中 PAILLIER_CTX *PAILLIER_CTX_copy(PAILLIER_CTX *dest, PAILLIER_CTX *src); // 复制 PAILLIER_CTX 对象 PAILLIER_CTX *PAILLIER_CTX_dup(PAILLIER_CTX *src); ○密文对象： PAILLIER_CIPHERTEXT ，该对象是用来保存 Paillier 加密后的结果信息，用到 PAILLIER_CIPHERTEXT 的地方，可调用如下接口：\n// 创建 PAILLIER_CIPHERTEXT 对象 PAILLIER_CIPHERTEXT *PAILLIER_CIPHERTEXT_new(PAILLIER_CTX *ctx); // 释放 PAILLIER_CIPHERTEXT 对象 void PAILLIER_CIPHERTEXT_free(PAILLIER_CIPHERTEXT *ciphertext); ●加密/解密接口\n// 加密，将明文 m 进行加密，结果保存到 PAILLIER_CIPHERTEXT 对象 …","date":1669100400,"description":"Tongsuo 支持半同态加密算法 Paillier","dir":"blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c3860b700dec4c686121bd9ef3565472","permalink":"https://sofastack.github.io/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","publishdate":"2022-11-22T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","summary":"文｜王祖熙（花名：金九 ) 蚂蚁集团开发工程师 负责国产化密码库 Tongsuo 的开发和维护 专注于密码学、高性能网络、网络安全等领域 本文 4316 字 阅读10 分钟 1. 背景 在","tags":["SOFAStack"],"title":"Tongsuo 支持半同态加密算法 Paillier","type":"blog","url":"/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","wordcount":3758},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.卓俊良 提问：\n Q: 22. AT 模式和 Spring @Transactional 注解连用时需要注意什么 ？\n A：@Transactional 可与 DataSourceTransactionManager 和 JTATransactionManager 连用，分别表示本地事务和 XA 分布式事务，大家常用的是与本地事务结合。当与本地事务结合时， @Transactional 和 @GlobalTransaction 连用，@Transactional 只能位于标注在 @GlobalTransaction 的同一方法层次或者位于 @GlobalTransaction 标注方法的内层。这里分布式事务的概念要大于本地事务，若将 @Transactional 标注在外层会导致分布式事务空提交，当 @Transactional 对应的 connection 提交时会报全局事务正在提交或者全局事务的 xid 不存在。\n 如果要支持 istio1.14 是需要重新适配吗？还是说有其他简化的方式？\n A：是需要适配下的，主要看新增了多少改动。\n「Seata」：https://github.com/seata/seata\n2.快叫我去学习 提问：\n Q: 34.Seata 的 JDK 版本要求是什么？\n A：目前 Seata 支持的 JDK 版本为 JDK8、11。其余版本不确保 100% 兼容。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Dragonfly 中 P2P 传输协议优化\nNydus | 容器镜像基础\nSOFARegistry | 大规模集群优化实践\n开源项目文档社区化！Tongsuo/铜锁实践\n欢迎扫码关注：\n","date":1668754800,"description":"SOFA Weekly |开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221122/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a317262c02b5a9ed70ec67cae8b88892","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221122/","publishdate":"2022-11-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221122/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221122/","wordcount":726},{"author":null,"categories":"SOFAStack","content":" 文｜孙珩珂\n上海交通大学\n本文1987字 阅读 10 分钟\n01 优化背景 此前 Dragonfly 的 P2P 下载采用静态限流策略，相关配置项在 dfget.yaml 配置文件中：\n# 下载服务选项。 download: # 总下载限速。 totalRateLimit: 1024Mi # 单个任务下载限速。 perPeerRateLimit: 512Mi 其中 perPeerRateLimit 为单个任务设置流量上限， totalRateLimit 为单个节点的所有任务设置流量上限。\n静态限流策略的理想情况是： perPeerRateLimit 设置为20M ， totalRateLimit 设置为 100M ，且该节点目前运行了 5 个或更多的 P2P 下载任务，这种情况下可以确保所有任务总带宽不会超过 100M ，且带宽会被有效利用。\n这种限流策略的缺点是：若perPeerRateLimit 设置为 20M ， totalRateLimit 设置为 100M ，并且当前该节点只运行了一个下载任务，那么该任务的最大下载速度为 20M ，和最大带宽 100M 相比，浪费了 80% 的带宽。\n因此，为了最大限度地利用带宽，需要使用动态限流来确保任务数量少时能能充分利用总带宽，而任务数量多时也能公平分配带宽。最终，我们设计出一套根据上下文进行动态限流的算法，其中上下文指各任务在过去一秒内使用的带宽，此外，算法还考虑到了任务数量、任务剩余大小、任务保底带宽等因素，性能相比原来的静态限流算法有显著提升。\n02 相关代码分析 perPeerRateLimit 配置项最终赋值给 peerTaskConductor 的pt.limiter ，由 peerTaskConductor 的 DownloadPiece() 函数里进行限速，pt.waitLimit() 进行实际限流工作，底层调用 Go 自带的限流函数 WaitN() 。\nTotalRateLimit 配置项则在创建 Daemon 时被赋值给 pieceManager 的pm.limiter ，在 pieceManager 的 DownloadPiece() 和 processPieceFromSource() 函数中用到的 pm.limiter ，而这两个函数都会由 peerTaskConductor 调用，也就是说 P2P 下载会先进行总限速，之后再进行每个任务单独限速。\n根据以上分析，Dragonfly 进行任务限速的逻辑为，每个peer task（peerTaskConductor）会有单独的限速 perPeerRateLimit ，同时 pieceManager 会有 TotalRateLimit 的总限速，以此达到单任务单独限流，同时限制所有任务总带宽的效果。\n03 优化方案 为了解决此前静态限流算法总带宽利用率不佳的缺点，需要将其改进为动态限流算法，即总带宽限速仍恒定，但每个任务的单独带宽限速需要根据上下文适度、定期调整，已达到最大化利用总带宽、同时相对公平分配带宽的目的。\n在经过数个改版后，最终我们确定了根据上下文进行限流的 sampling traffic shaper 动态限流算法。具体方案为，每个任务的单任务限流交由 TrafficShaper 组建进行统一管理， TrafficShaper 维护当前正在运行的所有任务，并且定期（每秒）更新这些任务的带宽。\n具体来说，上下文指每个任务在上一秒使用的带宽、每个任务的剩余大小、任务数量、任务保底带宽（不能低于 pieceSize ）等因素， TrafficShaper 会根据这些上下文公平地、效率最大化地为每个任务分配其下一秒的带宽（具体分配方案详见下一小节），实现动态限流的效果。\n04 优化实现 定义 TrafficShaper 接口如下：\n// TrafficShaper allocates bandwidth for running tasks dynamically type TrafficShaper interface { // Start starts the TrafficShaper Start() // Stop stops the TrafficShaper Stop() // AddTask starts managing the new task AddTask(taskID string, ptc *peerTaskConductor) // RemoveTask removes completed task RemoveTask(taskID string) // Record records task\u0026#39;s used bandwidth Record(taskID string, n int) // GetBandwidth gets the total download bandwidth in the past second GetBandwidth() int64 } 该接口有两种实现，第一种是 samplingTrafficShaper 即基于上下文的 traffic shaper ，第二种是 plainTrafficShaper 只记录带宽使用情况，除此之外不做任何动态限流工作，用于和 samplingTrafficShaper 对比性能提升。\n同时，将相关配置项修改为如下内容：\n# 下载服务选项。 download: # 总下载限速。 totalRateLimit: 1024Mi # 单个任务下载限速。 perPeerRateLimit: 512Mi # traffic shaper类型，有sampling和plain两种可选 trafficShaperType: sampling Traffic shaper 的具体运行逻辑为，由peerTaskManager维护trafficShaper，在创建peerTaskManager时，根据配置初始化trafficShaper，并且调用Start()函数，启动trafficShaper，具体来说，新建time.NewTicker，跨度为 1 秒，也即每秒trafficShaper都会调用updateLimit()函数以动态更新所有任务的带宽限流。\nupdateLimit() 函数会遍历所有运行中的任务，得出每个任务上一秒消耗的带宽以及所有任务消耗的总带宽，随后根据任务上一秒使用的带宽、任务剩余大小等因素，按比例分配带宽，具体来说首先根据上一秒该任务使用带宽以及该任务剩余大小的最大值确定下一秒该任务带宽，接着所有任务带宽根据总带宽按比例缩放，得到下一秒的真实带宽；同时需要确保每个任务的带宽不低于该任务的 pieceSize ，以免出现持续饥饿状态。\n在 peerTaskManager 的 getOrCreatePeerTaskConductor() 函数中，若新建任务，需要带宽，那么调用 AddTask() 更新所有任务的带宽，即按照已有任务的平均任务分配带宽，然后再根据总带宽上限将所有任务的带宽等比例进行缩放；根据平均带宽分配新任务带宽的优势为，避免了已经有一个任务占满了所有带 …","date":1668495600,"description":"Dragonfly 中 P2P 传输协议优化","dir":"blog/p2p-transfer-protocol-optimization-in-dragonfly/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9af455951fd545b7e7fa74b3eca908ce","permalink":"https://sofastack.github.io/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","publishdate":"2022-11-15T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","summary":"文｜孙珩珂 上海交通大学 本文1987字 阅读 10 分钟 01 优化背景 此前 Dragonfly 的 P2P 下载采用静态限流策略，相关配置项在 dfget.yaml 配置文件中： # 下载服务选项。 download: # 总下载","tags":["SOFAStack"],"title":"Dragonfly 中 P2P 传输协议优化","type":"blog","url":"/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","wordcount":2220},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. 奇奇 提问：\n Seata 可以用于生产环境吗？\n A：0.4.2 版本之后就可以上生产环境。\n「Seata」：https://github.com/seata/seata\n2. 牛康龙 提问：\n 在使用时遇到了如下图这个问题，请问该如何解决啊？ A：换 Hikari Durid 的 bug 。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读\ncgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\nGo 内存泄漏，pprof 够用了么？\nSeata AT 模式代码级详解\n欢迎扫码关注\n","date":1668150000,"description":"SOFA Weekly |本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221111/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a95c87454a97852938da43731c348498","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221111/","publishdate":"2022-11-11T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221111/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221111/","wordcount":497},{"author":null,"categories":"SOFAStack","content":" 文｜唐斌\n字节跳动基础架构研发工程师\nNydus 与 Nydus snapshotter 社区贡献者，专注存储，云原生技术。\n本文 6964 字 阅读 15 分钟\n1 Nydus 1.1 存在的问题 对于容器镜像使用者\n问题一： 启动容器慢：容器启动慢的情况普遍发生在当用户启动一个很大的容器镜像时，由于在容器准备阶段需要三步（以 overlayfs 为例）：\n- 下载镜像；\n- 解压镜像；\n- 使用 overlayfs 将容器可写层和镜像中的只读层聚合起来提供容器运行环境。\n其中，下载镜像阶段需要下载整个镜像文件，不能实现文件数据按需加载。再加上下载镜像本身受限于网络带宽，当容器镜像达到 GB 级别时，下载时间会较长，破坏了容器原本优秀的用户体验。\n问题二： 较高的本地存储成本：不同镜像之间可以共享的最小单位是镜像中的层，缺点之一是重复数据的处理效率较低。\n原因如下：\n- 首先，层内部存在重复的数据；\n- 其次，层与层之间可能存在大量重复的数据，即使有微小的差别，也会被作为不同的层；\n- 再次，根据 OCI imagespec 对删除文件和 hardlink 的设计，镜像内部已经被上层删除的文件可能仍然存在于下层，并包含在镜像中。\n对于镜像提供者\n这里的提供者主要指容器服务的镜像中心。\n问题一： 巨大的存储资源浪费。\n- 存在大量相似镜像，造成这种情况有两个原因：\n 首先，上面提到的层的缺点，导致在容器镜像中心存在许多相似镜像；\n 其次，OCI image 使用了 tar+gzip 格式来表示镜像中的层，而 tar 格式并不区分 tar archive entries ordering，这带来一个问题，如果用户在不同机器上 build 同一个镜像，最终可能会因为使用了不同的文件系统而得到不同的镜像，用户上传之后，镜像中心中会存在若干不同镜像的实质内容是完全相同的情况。\n - 镜像去重效率低\n虽然镜像中心有垃圾回收机制来实现去重功能，但其仍然以层为单位，所以只能在有完全相同 hash value 的层之间去重。\n问题二： 云原生软件供应链带来的新需求。\n随着时间推移，和软件供应链一起发展的还有对软件供应链环节的多样性攻击手段。安全防护是软件供应链中非常重要的组成，不光体现在对软件本身的安全增强，也体现在对供应链的安全增强。因为应用运行环境被前置到了容器镜像中，所以对容器镜像的安全，包括对镜像的漏洞扫描和签名成为了容器服务提供者的必要能力。\nOCI 镜像规范的缺陷\n主要的缺陷有两点：\n- tar 格式标准\n tar 格式并不区分 tar archive entries ordering，这带来一个问题，即如果用户在不同机器上 ；build 同一个镜像，最终可能会因为使用了不同的文件系统而得到不同的镜像，比如在文件系统 A 上的 order 是 foo 在 bar 之前进入 tar ，在文件系统 B 上的 order 是 bar 在 foo 之前进入tar ，那么这两个镜像是不同的；\n 当 tar 被 gzip 压缩过之后不支持 seek ，导致运行之前必须先下载并解压 targz 的 image layers，而不能实现文件数据按需加载。\n - 以层为镜像的基本单位\n 内容冗余：不同层之间相同信息在传输和存储时都是冗余内容，在不读取内容的时候无法判断到这些冗余的存在；\n 无法并行：每一层是一个整体，对同一个层既无法并行传输，也不能并行提取；\n 无法进行小块数据的校验，只有完整的层下载完成之后，才能对整个层的数据做完整性校验；\n 其他一些问题：比如，跨层数据删除难以完美处理。\n 1.2 Nydus 基础 在容器的生产实践中，偏小的容器镜像能够很快部署启动。当应用的镜像达到 GB 级以上的时候，在节点上下载镜像通常会消耗大量的时间。Dragonfly 通过引入 P2P 网络有效地提升了容器镜像大规模分发的效率。然而，用户必须等待镜像数据完整下载到本地，然后才能创建自己的容器。\nNydus 是在最新的 OCI Image-Spec 基础之上设计的容器镜像加速服务，重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。Nydus 由阿里云和蚂蚁集团的工程师合作开发，并大规模部署在内部的 生产环境中。\nNydus 优化了现有的 OCI 镜像标准格式，并以此设计了一个用户态的文件系统。通过这些优化，Nydus 能够提供这些特性：\n 容器镜像按需下载，用户不再需要下载完整镜像就能启动容器\n 块级别的镜像数据去重，最大限度为用户节省存储资源\n 镜像只有最终可用的数据，不需要保存和下载过期数据\n 端到端的数据一致性校验，为用户提供更好的数据保护\n 兼容 OCI 分发标准和 artifacts 标准，开箱即可用\n 支持不同的镜像存储后端，镜像数据不只可以存放在镜像仓库，还可以放到 NAS 或者类似 S3 的对象存储上\n 与 Dragonfly 的良好集成 1.3 Nydus 架构 Nydus 的架构主要包含两部分内容：\n- 新的镜像格式（Rafs）\n- 负责解析容器镜像的 FUSE 用户态文件系统进程\nNydus 兼容多种文件系统，能够解析 FUSE 和 virtiofs 协议来支持传统的 runc 容器、 Kata容器。对于存储后端，支持使用容器仓库（ Registery ）、OSS 对象存储 、NAS、Dragonfly 的超级节点和 Peer 节点作为 Nydus 的镜像数据存储后端。此外，为了加速启动速度，Nydus 还可以配置一个本地缓存，避免每次启动容器时都从远端数据源拉取数据。\n1.4 Nydus 特性 容器启动速度变快\n用户部署了 Nydus 镜像服务后，由于使用了按需加载镜像数据的特性，容器的启动时间明显缩短。在官网的测试数据中，Nydus 能够把常见镜像的启动时间，从数分钟缩短到数秒钟。理论上来说，容器镜像越大，Nydus 体现出来的效果越明显。\n提供运行时数据一致校验\n在传统的镜像中，镜像数据会先被解压到本地文件系统，再由容器应用去访问使用。解压前，镜像数据是完整校验的。但是解压之后，镜像数据不再能够被校验。这带来的一个问题就是，如果解压后的镜像数据被无意或者恶意地修改， 用户是无法感知的。而 Nydus 镜像不会被解压到本地，同时可以对每一次数据访问进行校验，如果数据被篡改，则可以从远端数据源重新拉取。\n从图中可以看出，对容器镜像数据进行运行时一致性校验是通过对每个数据块计算 SHA 256 实现的，这得益于 Nydus 采用分块的方式管理镜像数据。如果在镜像文件非常大的时候，对整个镜像文件计算哈希值非常不现实。\n1.5 Nydus 镜像格式：RAFS RAFS 是对 EROFS 文件系统的增强，拓展在云原生场景下的能力，使其适应容器镜像存储场景。RAFS v6 是内核态的容器镜像格式，除了将镜像格式下沉到内核态，还在镜像格式上进行了一系列优化，例如块对齐、更加精简的元数据等。\nRAFS v6 镜像格式\n1.6 Nydus -snapshotter Nydus snapshotter 是 containerd 的一个外部插件， …","date":1667977200,"description":"Nydus | 容器镜像基础","dir":"blog/container-image-basics/","fuzzywordcount":6100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa785f9400252d3285438e7ad8a39218","permalink":"https://sofastack.github.io/sofastack.tech/blog/container-image-basics/","publishdate":"2022-11-09T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/container-image-basics/","summary":"文｜唐斌 字节跳动基础架构研发工程师 Nydus 与 Nydus snapshotter 社区贡献者，专注存储，云原生技术。 本文 6964 字 阅读 15 分钟 1 Nydus 1.1 存在的问题 对于容器镜像使用者 问题一： 启动","tags":["SOFAStack"],"title":"Nydus | 容器镜像基础","type":"blog","url":"/sofastack.tech/blog/container-image-basics/","wordcount":6057},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.康政恒 提问：\n MOSN 做链路追踪是否需要 APP 配合传递 traceID、spanID 这些吗? A：链路追踪都需要 APP 配合的，这是业务决定，跟是不是 MOSN 没关系。\n 「MOSN」：https://github.com/mosn/mosn/\n2.康政恒 提问：\n MOSN 是否和 APP 也保持长链接呀，这样可以知道 APP 的存活状态。 A：保持长链接。\n 「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 SOFARegistry | 大规模集群优化实践\ncgo 机制 - 从 c 调用 go\nSeata AT 模式代码级详解\nGo 内存泄漏，pprof 够用了么？\n欢迎扫码关注：\n","date":1667545200,"description":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221104/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"32dcc5c5b6f04360aa073fe5820a4d12","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221104/","publishdate":"2022-11-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221104/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221104/","wordcount":519},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#30:Nydus 开源容器镜像加速服务的演进与未来\n 活动时间：11 月 03 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#30 Nydus 开源容器镜像加速服务的演进与未来 Nydus 在生产环境已经支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，网络带宽效率，端到端数据一致性等方面相比 OCIv1 格式有着巨大优势，并可扩展至例如 NPM 包懒加载等数据分发场景。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 严松（花名：井守）\n Nydus 镜像加速开源项目 Maintainer\n 负责蚂蚁集团基础设施研发，专注于云原生镜像与容器运行时生态。\n 议程 直播回放 https://b23.tv/Gnz9y6D\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1667458800,"description":"2022 年 11 月 03 日 19：00 - 20：00 ，线上直播第 30 期。","dir":"activities/sofa-channel-30/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"51b6ca632e0cf11ccff50820a472a320","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-30/","publishdate":"2022-11-03T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-30/","summary":"概要 活动主题：SOFAChannel#30:Nydus 开源容器镜像加速服务的演进与未来 活动时间：11 月 03 日，周四晚 19 点 活动形式：线上直播 资料","tags":["SOFAChannel","Nydus","开源容器镜像加速服务的演进与未来"],"title":"SOFAChannel#30 Nydus 开源容器镜像加速服务的演进与未来","type":"activities","url":"/sofastack.tech/activities/sofa-channel-30/","wordcount":485},{"author":null,"categories":"SOFARegistry","content":" 文｜李旭东\n专注于 SOFARegistry 及其周边基础设施的开发与优化\n本文 7016 字 阅读 15 分钟\n1 前言 SOFARegistry 在蚂蚁内部迭代升级过程中，每年大促都会引来一些新的挑战，通过不断的优化这些在大规模集群遇到的性能瓶颈，我们总结出一些优化方案，来解决大规模集群遇到的性能问题。\n通过阅读这篇文章，读者可以学习到一些 Java 和 Go 语言系统的优化技巧，在系统遇到瓶颈的时候，能够知道有哪些优化手段针对性的进行优化。\n2 大规模集群的挑战 随着业务的发展，业务的实例数在不断增长，注册中心所需要承载的数据量也在快速的增长 ，以其中 1 个集群为例，2019 年的数据为基准数据，在 2020 年 pub 接近千万级。下图是该集群历年双 11 时的数据对比。 相比 2019 年双 11，2021 年双 11 接口级的 pub 增长 200%，sub 增长 80%。实例数和数据量的增长带来推送量的二次方形式的增长，SOFARegistry 每一年大促都会经历新的挑战。\n比如，在某一年的新机房压测过程中，由于新机房规模特别大（普通机房的 4 倍），导致注册中心的推送压力变大了十倍多，出现了 ：\n- DataServer 的网络被打爆，导致大量数据变更没有及时通知到 Session ，推送延迟飙升；\n- 因为数据包过大， SessionServer 与客户端之间出现了大量的 channel overflow 推送失败，推送延迟飙升；\n- 由于实例数量过多，注册中心的推送包以及内部传输的数据包过大，很容易打满单机的网络处理上限，序列化数据也会占用大量的 CPU ；\n- 由于地址列表扩大了几倍，导致对应推送接收端 MOSN 也出现了问题，大量机器出现 OOM ， 出现大量 CPU 毛刺影响请求延迟；\n- 注册中心常见瞬间大量并发的请求，比如业务大规模重启，很容易导致瞬时注册中心自身处理能不足，如何进行限流，以及如何快速达到数据最终一致。\n3 优化方案 针对上述大规模集群遇到的挑战，我们做了以下的优化方案：\n3.1 横向扩展支撑大规模集群 在大规模集群场景下，单纯采用扩大机器规格的纵向扩展方式往往会遇到瓶颈，单机的配置是有上限的，超大的 heap gc 时也可能产生较高的暂停时间，而且恢复与备份会花费很长时间。\n3.1.1 双层数据架构进行数据分片 双层数据架构: Session (会话层：分散链接)、Data （数据层：分散数据）来实现横线扩展的能力，通过对链接和数据进行分片，SOFARegistry 可以通过横向扩容很容易的支撑更大的集群。单机采用小规格的机器，在容灾以及恢复方面也可以取得很好的效果。\nSOFARegistry 的架构可以参见： https://www.sofastack.tech/blog/explore-sofaregistry-1-infrastructure/\n3.2 应对瞬时大量请求 注册中心存在瞬时处理大量请求的场景，比如当在大量应用同时发生运维或者注册中心自身发生运维的时候，会有大量的注册请求发送到 Session 。\n同时有一些依赖注册中心的基础设施会通过变更发布数据到注册中心来通知到每一个订阅端。为了应对这种不可预见的瞬时大量请求变更，注册中心需要有一定的策略进行削峰。\n3.2.1 队列攒批处理 贴合蚂蚁的业务，为大规模集群而生，在大数据量，高并发写入下提供稳定的推送延迟，通过添加队列并进行攒批处理，提高吞吐量，对瞬间高并发请求进行削峰。\n举例：\n- Session 接收到大量 Publisher ，攒批发请求到 Data [1]\na.利用 BlockingQueue 存储需要发送 的请求，同时会配置最大容量防止 OOM\nb.独立的 Worker 线程从 BlockingQueue 中取出多个请求，创建多个 BlockingQueue 和 Worker 提高并发度\nc.按照分片规则进行分组，打包成一个请求发往不同的 DataServer\n- Session 接收到大量 Subscriber ，聚合去重后创建推送任务 *[2]*\na.Subscriber 存储到 Map的数据结构中，可以进行去重的避免短时间一个实例重复注册创建大量推送任务\nb.定时从 Map 中取出 Subscribers ，进行分组创建推送任务\nc.最大数据量是 Session 单机的所有 Subscriber ，容量可控\n- 用 Map 存储 DataServer 上发生变化数据的 DataInfoId ，聚合通知 Session 进行推送[3]\na.短时间 DataServer 的数据可能变化多次，比如大量 Publisher ，数据修复定时任务等等\nb.对这些数据变化记录 DataInfoId ， 短时间只会对 Session 通知一次变更创建推送任务\nc.最大数据量是 Data 单机全部的 DataInfoId\n- 用 Map 存储 PushTask 进行去重，避免数据连续变化触发大量推送任务[4]\na.添加了 Map size 的检查，过多的推送任务会直接丢弃，防止 OOM\nb.同样的推送任务高版本会替换掉低版本\n3.3 减少网络通讯开销 3.3.1 LocalCache Session 和 Data 之间会有大量的数据通讯，通过添加 LocalCache 可以在不增加代码架构复杂度的前提下大幅度提升系统的性能。\n对于注册中心，服务数据可以通过 dataInfoId + version 唯一标识。Session 在创建推送任务时会从 Data 拉取最新的服务数据，利用 Guava 的 LoadingCache ,大量推送任务被创建时，缓存的利用率会比较高，可以减少很多从 Data 拉取数据的开销。\n- Session 利用 LoadingCache 从 Data 拉取数据[5]\na.会传入创建推送任务时的版本（一般由 Data 的变更通知带过来）对比 Cache 内的数据是否足够新；\nb.如果不够新，清理缓存后利用 LoadingCache 从 Data 拉取一次数据；\nc. LoadingCache 会配置 maximumWeight 防止数据过多导致 OOM 。\n3.3.2 压缩推送 在集群规模比较大的时候，比如有一个应用发布了 100 个接口，每个接口的发布数据有 150B ，该应用有 8000 个实例，每个接口有 2w 订阅方。那么每次变更这个应用的机器造成的全量推送，每个推送包 1MB ， 累积需要发出 200w 个推送包，即使 Session 可以横向扩容到 100 台， Session 单机也需要在 7 秒内发出 20GB 的流量，严重阻塞 Session 的网络队列，也会很快打爆 netty buffer ，造成大量的推送失败，这么多推送包的序列化也会耗费 Session 大量的 CPU 。\n对于 Data ，如果 Session 的数量过多，每次变更需要给每台 Session 返回大量的大数据包，也会产生大量的出口流量，影响其他请求的成功率。\n由于每个实例发布的数据的相似度很高，几乎只有 IP 不一致，所以当采用压缩推送时压缩率会非常高，能压 …","date":1667458800,"description":"SOFARegistry | 大规模集群优化实践","dir":"blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"56b7649b36ba3889527d68dc2214c31d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","publishdate":"2022-11-03T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","summary":"文｜李旭东 专注于 SOFARegistry 及其周边基础设施的开发与优化 本文 7016 字 阅读 15 分钟 1 前言 SOFARegistry 在蚂蚁内部迭代升级过程中，每年大促都会引来一些新的挑战，通过不断的优","tags":["SOFARegistry"],"title":"SOFARegistry | 大规模集群优化实践","type":"blog","url":"/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","wordcount":5846},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.康恒政 提问：\n MOSN 之间是维持长链接的吗，然后像 Spring Cloud、Dubbo、Bolt 协议的数据在这个长链接上面传递吗？\n A：支持的，MOSN 原生就支持 Dubbo，Bolt 协议。\n「MOSN」：https://github.com/mosn/mosn/\n2.康恒政 提问：\n 注册中心是不是可以支持其他种类的，比如 ZooKeeper、Eureka 什么的？\n A：可以的，可以自己扩展，默认支持了 ZK 。\n「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 cgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\n从规模化平台工程实践，我们学到了什么？\n直播预告丨SOFAChannel#30《Nydus 开源容器镜像加速服务的演进与未来》\n欢迎扫码关注：\n","date":1666940400,"description":"SOFA Weekly | MOSN v1.2.0 版本发布、开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly/20221028/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8890ddd864d60166dc508e0ec80d9049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly/20221028/","publishdate":"2022-10-28T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly/20221028/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.2.0 版本发布、开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly/20221028/","wordcount":605},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 4656 字 阅读 12 分钟\n一、前言 去年刚学 go 语言的时候，写了这篇 cgo 实现机制[1] ，介绍了 cgo 的基本情况。主要介绍的是 go=\u0026amp;gt;c 这个调用方式，属于比较浅的层次。随着了解的深入，发现 c=\u0026amp;gt;go 的复杂度又高了一级，所以有了这篇文章。\n二、两个方向 首先，cgo 包含了两个方向， c=\u0026amp;gt;go ，go=\u0026amp;gt;c 。\n相对来说，go=\u0026amp;gt;c 是更简单的，是在 go runtime 创建的线程中，调用执行 c 函数。对 go 调度器而言，调用 c 函数，就相当于系统调用。执行环境还是在本线程，只是调用栈有切换，还多了一个函数调用的 ABI 对齐，对于 go runtime 依赖的 GMP 环境，都是现有的，并没有太大的区别。\n而 c=\u0026amp;gt;go 则复杂很多，是在一个 c 宿主创建的线程上，调用执行 go 函数。这意味着，需要在 c 线程中，准备好 go runtime 所需要的 GMP 环境，才能运行 go 函数。以及，go 和 c 对于线程掌控的不同，主要是信号这块。所以，复杂度又高了一级。\n三、GMP 从哪里来 首先简单解释一下，为什么需要 GMP ，因为在 go 函数运行的时候，总是假设是运行在一个 goroutine 环境中，以及绑定有对应的 M 和 P 。比如，要申请内存的时候，则会先从 P 这一层 cache 的 span 中的获取，如果这些没有的话，go runtime 就没法运行了。\n虽然 M 是线程，但是具体实现上，其实就是一个 M 的数据结构来表示，对于 c 创建的协程，获取的是 extra M ，也就是单独的表示线程的 M 数据结构。\n简单来说，c 线程需要获取的 GMP ，就是三个数据对象。在具体的实现过程中，是分为两步来的：\n1. needm 获取一个 extra M\n开启了 cgo 的情况下，go runtime 会预先创建好额外的 M ，同时还会创建一个 goroutine，跟这个 M 绑定。所以，获取到 M，也就同时得到了 G。\n而且，go runtime 对于 M 并没有限制，可以认为是无限的，也就不存在获取不到 M 的情况。\n2.exitsyscall 获取 P\n是的，这个就是 go=\u0026amp;gt;c 的反向过程。只是 P 资源是有限的，可能会出现抢不到 P 的情况，此时就得看调度机制了。\n四、调度机制 简单情况下，M 和 P 资源都顺利拿到了，这个 c 线程，就可以在 M 绑定的 goroutine 中运行指定的 go 函数了。更进一步，如果 go 函数很简单，只是简单的做点纯 CPU 计算就结束了，那么这期间则不依赖 go 的调度了。\n有两种情况，会发生调度：\n1. exitsyscall 获取不到 P 此时没法继续执行了，只能：\n1.将当前 extra M 上绑定的 g ，放入全局 g 等待队列\n2.将当前 c 线程挂起，等待 g 被唤起执行\n在 g 被唤起执行的时候，因为 g 和 M 是绑定关系：\n1.执行 g 的那个线程，会挂起，让出 P ，唤起等待的 c 线程\n2.c 线程被唤起之后，拿到 P 继续执行\n2. go 函数执行过程中发生了协程挂起 比如，go 函数中发起了网络调用，需要等待网络响应，按照之前介绍的文章，Goroutine 调度 - 网络调用[2] 。当前 g 会挂起，唤醒下一个 g ，继续执行。\n但是，因为 M 和 g 是绑定关系，此时会：\n1. g 放入等待队列\n2.当前 c 线程被挂起，等待 g 被唤醒\n3. P 被释放\n在 g 被唤醒的时候，此时肯定不是在原来的 c 线程上了\n1.当前线程挂起，让出 P，唤醒等待的 c 线程\n2.c 线程被唤醒后，拿到 P，继续执行\n直观来说，也就是在 c 线程上执行的 goroutine，并不像普通的 go 线程一样，参与 go runtime 的调度。对于 go runtime 而言，协程中的网络任务，还是以非阻塞的方式在执行，只是对于 c 线程而言，则完全是以阻塞的方式来执行了。\n为什么需要这样，还是因为线程的调用栈，只有一个，没有办法并发，需要把线程挂起，保护好调用栈。\nPS：这里的执行流程，其实跟上面抢不到 P 的流程，很类似，底层也是同一套函数在跑（核心还是 schedule）。\n五、信号处理 另外一大差异是，信号处理。\n c 语言世界里，把信号处理的权利/责任，完全交给用户了。\n go 语言，则在 runtime 做了一层处理。\n 比如，一个具体的问题，当程序运行过程中，发生了 segfault 信号，此时是应该由 go 来处理，还是 c 来响应信号呢？\n答案是，看发生 segfault 时的上下文：\n1.如果正在运行 go 代码，则交给 go runtime 来处理\n2.如果正在运行 c 代码，则还是 c 来响应\n那具体是怎么实现的呢？信号处理还是比较复杂的，有比较多的细节，这里我们只介绍几个核心点。\n1. sighandler 注册 首先，对于操作系统而言，同一个信号，只能有一个 handler 。再看 go 和 c 发生 sighandler 注册的时机：\n go 编译产生的 so 文件，被加载的时候，会注册 sighandler（仅针对 go 需要用的信号），并且会把原始的 sighandler 保存下来。\n c 可以在任意的时间，注册 sighandler，可以是任意的信号。\n 所以，推荐的做法是，在加载 go so 之前，c 先完成信号注册，在 go so 加载之后，不要再注册 sighandler 了，避免覆盖 go 注册 sighandler。\n2.信号处理 对于最简单的情况，如果一个信号，只有 c 注册了 sighandler，那么还是按照常规 c 信号处理的方式来。\n对于 sigfault 这种，go 也注册了 sighandler 的信号，按照这个流程来：\n1.操作系统触发信号时，会调用 go 注册的 sighandler（最佳实践中，go 的信号注册在后面）；\n2.go sighandler 先判断是否在 c 上下文中（简单的理解，也就是没有 g，实际上还是挺复杂的）；\n3.如果，在 c 上下文中，会调用之前保存的原始 sighandler（没有原始的 sighandler，则会临时恢复 signal 配置，重新触发信号）；\n4.如果，在 go 上下文中，则会执行普通的信号处理流程。\n其中，2 和 3 是最复杂的，因为 cgo 包含了两个方向，以及信号还有 sigmask 等等额外的因素，所以这里细节是非常多的，不过思路方向还是比较清晰的。\n六、优化 上篇 cgo 实现机制[1] ，提过优化一些思路，不过主要针对 go =\u0026amp;gt; c 这个方向。因为 c =\u0026amp;gt; go 的场景中，还有其他更重要的优化点。\n1.复用 extra M 通常情况下，最大的性能消耗点在获取/释放 M。\n1.上面提到，从 c 进入 go，需要通过 needm 来获取 M 。这期间有 5 个信 …","date":1665212400,"description":"cgo 机制 - 从 c 调用 go","dir":"blog/c-go-mechanism-calling-go-from-c/20221008/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a233624b1a608f5d80599295f0599d5b","permalink":"https://sofastack.github.io/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","publishdate":"2022-10-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 4656 字 阅读 12 分钟 一、前言","tags":["SOFAStack"],"title":"cgo 机制 - 从 c 调用 go","type":"blog","url":"/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","wordcount":4794},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. greedying 提问：\n 我发现 MOSN 去 cookie 时候，如果取不到，则返回中横线。这里万一 cookie 值就是中横线怎么办呢？\n A：你用啥接口取的？\n 用变量取的,前缀加 cookie 的 key。 \u0026amp;gt;\u0026amp;gt;MOSN 代码就是这么写的，那个 ValueNotFound 是一个短横，这是一个 feature 还是 bug？\n A：哦 确实，这儿应该返回 error 就行了，不然任何值都有可能不对。 要这样处理才合理，通过 error 来判断了。\n「MOSN」：https://github.com/mosn/mosn\n2. 卿同学 提问：\n 我看 Layotto 也在推动和 Envoy 的融合，这一块现在有进展吗？\n A：今年我们首先会开源 Envoy 的 cgo 插件，然后基于这个插件，可以把 Layotto 跑在 Envoy 上。\n「Layotto」：https://github.com/mosn/layotto\n本周推荐阅读\ncgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\nGo 内存泄漏，pprof 够用了么？\nSeata AT 模式代码级详解\n欢迎扫码关注\n","date":1665126000,"description":"SOFA Weekly | C 位大咖说 \u0026 QA","dir":"blog/sofa-weekly-20221007/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2d8af727a21b1ea54ab966afa87a0c03","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221007/","publishdate":"2022-10-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221007/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说 \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221007/","wordcount":623},{"author":null,"categories":"SOFAStack","content":"文｜杨洋（花名：凯申 )\n铜锁开源密码库创始人蚂蚁集团高级技术专家\n本文 1284 字 阅读 5 分钟\n1 前言\n如大家所见，针对铜锁开源密码库（ *https://github.com/Tongsuo-Project*）的文档，我们正在逐步地进行一些改革。\n其中，最大的一个变化是：我们把原来放在 readthedocs.org（简记 rtfd.io）上的教程和说明文档转移到了语雀上。\n为此有必要和大家解释一下，这其中的原因以及背后的一些想法。\n2 说说历史原因\n铜锁开源项目自诞生以来，其文档管理不是那么的严格和统一。\n铜锁派生自 OpenSSL ，而 OpenSSL 的文档则是以 perldoc 体系为核心，且混合了一部分的纯文本和 markdown 。OpenSSL 的这些文档内容均散落在 OpenSSL 源代码仓库的各个目录中。\n对于 perldoc 所支持的 pod 格式的文件，可以被编译成多种不同最终格式的文档，这其中以 man 手册和 html 文件为主。\n综上所述，所以铜锁项目在早期延续了编写 pod 文件并编译成 html 和 man 手册的这种模式，随着项目的发展，我们发现此模式存在若干不足，例如：\n perldoc 这套体系过于古老，文档的编写依旧停留在“非可视化”的状态。且编译过程较为复杂，和 markdown 等相比不具备优势，也不够通用；\n man 手册也比较古老，是单机的本地模式。查询文档的功能较弱，效率较低，不如 readthedocs 这种可视化的查询文档的方式来得便捷；\n OpenSSL 的文档组织形式更多的是以 API 为出发点，而不是以“教程”为出发点，这对于很多新手用户来说无从下手。\n 3 早前的一些改进\n为了解决这些不足之处，铜锁项目将文档的重心从 API 视角切换到了教程视角，即以教会用户如何通过使用铜锁来完成某种功能为核心目标，重新组织了文档的形态，并以 markdown 写了若干教程类的文档。\n这些文档需要一个呈现平台，因此我们选择了成熟的 readthdocs.org 作为铜锁文档的发布地（https://tongsuo.rtfd.io ），并持续运行了一段时间。\n在这之后，我们又发现了一些问题：\n1.访问不便。readthedocs.org 是海外的文档托管网站，国内会出现访问比较慢甚至无法访问的状况；\n2.不容易交互。更多的是单方面的信息展示，用户真有问题还是要到 Github 上提交 issue，效率比较低。\n4 “文档社区化”的诞生\n前段时间，我机缘巧合的参与了一档播客节目的录制\n*（https://www.ximalaya.com/zhubo/343307074）*。\n在录制过程中，大家也讨论到：是否可以将互动引入到开源社区的文档体系中，将开源项目的文档“社区化”，进而形成除了代码托管平台之外的、更加贴近最终用户的社区交流讨论形式。\n受此启发，我们最后决定尝试将铜锁的全部文档迁移到语雀上，利用语雀的社区化能力，增强铜锁和其用户间的互动。具体来说有如下几点：\n1.新的文档网站地址为：*https://yuque.com/tsdoc* 。目前有两个知识库，铜锁的各种文档均分类到这些知识库中，而且都是对全网公开的，后续我们也会根据需要对知识库去做一些调整；\n2.用户可以在这些文档中进行评论；3.上述知识库的文档会每天同步备份到 Github 的指定仓库中；\n4.现有的 *https://tongsuo.rtfd.io* 将不再更新。\n此外，对于 API ，我们也会重新进行梳理，将铜锁特有的 API 整理后供用户检索查询。希望大家能和我们一起参与这场“文档社区化”的试验，欢迎伙伴们充分发表自己的意见、建议以及想法，一起将这次试验更好地落地。\n本周推荐阅读\n你好，我的新名字叫“铜锁/Tongsuo”\nBabaSSL：支持半同态加密算法 EC-ElGamal\nBabaSSL 发布 8.3.0｜实现相应隐私计算的需求\nSeata AT 模式代码级详解\n","date":1664434800,"description":"开源项目文档社区化！Tongsuo/铜锁实践","dir":"blog/20220929/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8f7a5b72bc271ef963ccea749cb0e888","permalink":"https://sofastack.github.io/sofastack.tech/blog/20220929/","publishdate":"2022-09-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/20220929/","summary":"文｜杨洋（花名：凯申 ) 铜锁开源密码库创始人蚂蚁集团高级技术专家 本文 1284 字 阅读 5 分钟 1 前言 如大家所见，针对铜锁开源密码库（ *https://gi","tags":["SOFAStack"],"title":"开源项目文档社区化！Tongsuo/铜锁实践","type":"blog","url":"/sofastack.tech/blog/20220929/","wordcount":1401},{"author":null,"categories":"SOFAStack","content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。\n本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同；\n- 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。\n平台工程旨在帮助企业构建面向应用研发者的自服务运维体系，尝试通过工程化的技术手段和工作流程解决以下关键问题：\n- 设计合理的抽象层次，帮助应用研发者降低对 Infra 、platform 等技术以及运维、稳定性工作的认知负担；\n- 为应用研发者提供统一的工作界面和空间，避免用户陷入割裂的平台产品界面、复杂的工作流中；\n- 帮助研发者通过有效的工作流程和推荐路径基于 内部工程平台[4] 快速开展工作；\n- 帮助研发者通过配套的 CI 、CD 、CDRA 等产品自服务管理应用生命周期；\n- 帮助平台产品研发团队简单、高效、一致的开放其平台基础能力；\n- 通过培训、布道、运营等手段营造协同工作和分享的文化。\n事实上，不是所有人都应该或者能够成为这个领域的专家，这非常困难！\n实际上平台技术团队的专家通常也仅擅长自己的专业领域而已，特别是在云原生理念和技术广泛应用的今天，面向大量高度开放、可配置的平台技术带来的成百上千的应用配置，PaaS 领域的业务复杂性，以及高稳定性和统一治理的要求，而平台工程的目的正是为了让应用研发者尽可能简单无痛的参与到这样规模化的 DevOps 工作中。\n在蚂蚁的实践中，我们更趋向于以下这种合作状态，在团队架构和工作模式上更靠近 Google 的最佳实践。平台研发者及 SRE 成为 “ Enabler ” 支持应用研发者自服务的完成研发及交付运维，同时应用研发者使其应用可交付运维的工作结果也成为运维人员可以接手应用运维工作的基础。最终 SRE 、应用研发及运维人员把工作过程中的问题和痛点反馈给平台研发者形成正向循环。\n三、专用语言：工程化方式的一极 有什么比一种专用语言更适合开放的、自服务的、面向领域业务的问题定义，同时需要满足自动化、低安全风险、低噪音、易治理的企业内部要求吗？正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在平台工程的特定问题域内，一批配置和策略语言用于编写和管理规模化复杂配置及策略。\n不同于混合编写范式、混合工程能力的高级通用语言，这类专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将规模化复杂配置和策略编写思路和方式沉淀到语言特性中。\n在蚂蚁的平台工程实践中，我们强化了客户端的工作方式，将围绕应用运维生命周期的模型、编排、约束和策略稳定、可扩展的通过专用语言 KCL[5] 编写维护在共享仓库 Konfig[6] 中。\nKCL 是一种面向有编程能力的应用研发者的静态强类型语言，提供现代高级语言的编写体验和围绕领域目的有限功能。在平台工程实践中 KCL 不是一种仅用于编写 K-V 对的语言，而是一种面向平台工程领域的专用语言。应用研发者、 SRE 、平台研发者面向 Konfig 协同研发，通过 KCL 原生功能编写应用配置，以及在 PaaS 领域更为高频和复杂的 模型抽象[7] 、 功能函数[8] 和 约束规则[9] ，即编写稳定、可扩展的业务模型、业务逻辑、防错约束和环境规则。\nKonfig 仓库则成为统一的编程界面，工作空间和业务层载体，而基于 KCL 的安全、低噪音、低副作用、一致的编写范式更有利于长期管理和治理。\n四、分治：解构规模化问题 分治思路是解决规模化问题的钥匙，从 MapReduce 到 Kubernetes 无不体现其功效。在规模化交付运维领域，经典运维平台试图在统一的黑盒平台产品中，以内置的统一模型、编排、 provision 技术来应对全量业务场景。这样的实践可以快速启动，在小范围内奏效，但随着不同业务主体采用率提升引入差异化需求，同时随着持续变化的平台技术逐渐进入疲态。\n在蚂蚁的实践中，Konfig monorepo 是内部工程平台向研发者开放的编程界面和工作空间，帮助应用研发者以统一的编程界面编写围绕应用运维生命周期的配置和策略，从而编排和使用存量和新增的平台基础设施，按需创建管理云原生环境以及基于 RBAC 的权限，并通过 GitOps 方式管理交付过程。\nKonfig monorepo 为不同场景、项目、应用提供了独立的白盒的编程空间，其内生的扩展性来源于：\n- 灵活、可扩展、独立的客户端的 工程结构设计[10] ；\n- 独立配置块自动合并技术[11] 支持任意分块、可扩展的配置块组织；\n- 静态类型系统[12] 技术提供现代编程语言可复用、可扩展的类型化建模和约束功能；\n- 项目粒度的 GitOps CI 工作流程定义支持；\n- 基于 Kusion[13] 引擎的 provision 技术选择。\nKonfig monorepo 提供了分治的、可组合的工程结构设计、代码组织、建模方式、工作流程定义和 provision 技术选择支持，同时又以一致的研发模式和工作流承载了可扩展的业务需求。这样客户端的工作方式在保证灵活性、可扩展性、可移植性的同时也降低了对服务 …","date":1664262000,"description":"从规模化平台工程实践，我们学到了什么？","dir":"blog/sofastack20220927/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa7d711a2d4e1a4f7c4242cbfe473fa2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack20220927/","publishdate":"2022-09-27T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofastack20220927/","summary":"文｜朵晓东（花名：奕杉 ) KusionStack 负责人、蚂蚁集团资深技术专家 在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作 一、摘要 本文尝试从平台","tags":["SOFAStack"],"title":"从规模化平台工程实践，我们学到了什么？","type":"blog","url":"/sofastack.tech/blog/sofastack20220927/","wordcount":6378},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.刘家燕 提问：\n MOSN 现在支持 TCP 服务按照端口灰度么？譬如：应用场景：接入了一个 TCP 服务，分别暴露了三个端口是 60403，60269，60129，每一个端口对应不同的业务来源，调用之后会对应不同的业务处理。目的：现在对其中一个端口例如 60403 逻辑处理做了一些调整，发版验证是否顺利调用。因此，将该服务进行灰度，创建 v1，v2 版本。当监听到 60403 端口调用时，路由到v2 ；其他端口，路由到v1 。\n A：最简单的就是你建两个 listener，不同端口的 listener 的路由对应不同的 cluster，比如 cluster_v1，cluster_v2。\n 意思是给创建灰度的版本各自创建一个 listener 吗？\n A：因为本来就要监听不同的端口，所以不同端口的 listener 配置不同的 router 就行了哦。\n「MOSN」：https://github.com/mosn/mosn/\n2.Lewise Liu \u0026amp;amp; 赵宇 提问：\n 请问，MOSN 可以与新版本 Istio 控制面集成吗？\n A：目前是支持的 1.10 ，新版本的话要做一些适配。\n 具体需要哪些适配？比如 1.14 。\n A：我的理解，主要是新版本的 xDS 会新增一些 feature，如果依赖这些新 feature 的话，就需要做一些对应的适配或许也有一些在新版本里，被废弃或者调整了的（这些应该不多的）。\n「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 Seata AT 模式代码级详解\nGo 内存泄漏，pprof 够用了么？\n社区文章｜MOSN 构建 Subset 优化思路分享\nGo 代码城市上云——KusionStack 实践\n欢迎扫码关注：\n","date":1663916400,"description":"SOFA Weekly |开源人、本周 QA、本周 Contributor","dir":"blog/sofa-weekly/20220923/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0aeda2b5aff95f678add334d82d2e2b0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly/20220923/","publishdate":"2022-09-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly/20220923/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly |开源人、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly/20220923/","wordcount":879},{"author":null,"categories":"SOFAStack","content":" 文｜\n刘月财\nseata-go 项目负责人\n北京小桔科技有限公司【滴滴】开发工程师\n赵新（花名：于雨 )\n蚂蚁集团 Seata 项目开源负责人\n本文5343字 阅读 14分钟\n背景 Seata 四种事务模式中，AT 事务模式是阿里体系独创的事务模式，对业务无侵入，也是 Seata 用户最多的一种事务模式，兼具易用性与高性能。\n目前，Seata 社区正大力推进其多语言版本建设，Go、PHP、JS 和 Python 四个语言版本基本完成了 TCC 事务模式的实现。参照 Seata v1.5.2 版本的 AT 模式的实现，并结合 Seata 官方文档，本文尝试从代码角度详解 Seata AT 事务模式的详细流程，目的是梳理 Seata Java 版本 AT 模式的实现细节后，在多语言版本后续开发中，优先实现 AT 事务模式。\n1、什么是 AT 模式？ AT 模式是一种二阶段提交的分布式事务模式，它采用了本地 undo log 的方式来数据在修改前后的状态，并用它来实现回滚。从性能上来说，AT 模式由于有 undo log 的存在，一阶段执行完可以立即释放锁和连接资源，吞吐量比 XA 模式高。用户在使用 AT 模式的时候，只需要配置好对应的数据源即可，事务提交、回滚的流程都由 Seata 自动完成，对用户业务几乎没有入侵，使用便利。\n2、AT 模式与 ACID 和 CAP 谈论数据库的事务模式，一般都会先谈论事务相关的 ACID 特性，但在分布式场景下，还需要考虑其 CAP 性质。\n2.1 AT 与 ACID 数据库事务要满足原子性、一致性、持久性以及隔离性四个性质，即 ACID 。在分布式事务场景下，一般地，首先保证原子性和持久性，其次保证一致性，隔离性则因为其使用的不同数据库的锁、数据 MVCC 机制以及相关事务模式的差异， 具有多种隔离级别，如 MySQL 自身事务就有读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）、序列化（Serializable）等四种隔离级别。\n2.1.1 AT模式的读隔离 在数据库本地事务隔离级别读已提交（Read Committed） 或以上的基础上，Seata（AT 模式）的默认全局隔离级别是读未提交（Read Uncommitted） 。\n如果应用在特定场景下，必须要求全局的读已提交，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。 SELECT FOR UPDATE 语句的执行会查询全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到全局锁拿到，即读取的相关数据是已提交的，才返回。\n出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。\n详细例子参考 Seata 官网：https://seata.io/zh-cn/docs/dev/mode/at-mode.html\n2.1.2 AT 模式的写隔离 AT 会对写操作的 SQL 进行拦截，提交本地事务前，会向 TC 获取全局锁，未获取到全局锁的情况下，不能进行写，以此来保证不会发生写冲突：\n- 一阶段本地事务提交前，需要确保先拿到全局锁；\n- 拿不到全局锁，不能提交本地事务；\n- 拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。\n详细例子参考 Seata 官网：https://seata.io/zh-cn/docs/dev/mode/at-mode.html\n2.2 AT 与 CAP Seata 所有的事务模式在一般情况下，是需要保证 CP，即一致性和分区容错性，因为分布式事务的核心就是要保证数据的一致性（包括弱一致性）。比如，在一些交易场景下，涉及到多个系统的金额的变化，保证一致性可以避免系统产生资损。\n分布式系统不可避免地会出现服务不可用的情况，如 Seata 的 TC 出现不可用时，用户可能希望通过服务降级，优先保证整个服务的可用性，此时 Seata 需要从 CP 系统转换为一个保证 AP 的系统。\n比如，有一个服务是给用户端提供用户修改信息的功能，假如此时 TC 服务出现问题，为了不影响用户的使用体验，我们希望服务仍然可用，只不过所有的 SQL 的执行降级为不走全局事务，而是当做本地事务执行。\nAT 模式默认优先保证 CP，但提供了配置通道让用户在 CP 和 AP 两种模式下进行切换：\n- 配置文件的 tm.degrade-check 参数，其值为 true 则分支事务保证 AP，反之保证 CP；\n- 手动修改配置中心的 service.disableGlobalTransaction 属性为 true，则关闭全局事务实现 AP。\n3、AT 数据源代理 在 AT 模式中，用户只需要配置好 AT 的代理数据源即可， AT 的所有流程都在代理数据源中完成，对用户无感知。 AT 数据源代理的整体类结构如下图：\n AT 事务数据源代理类结构图【from *https://seata.io/zh-cn/docs/dev/mode/xa-mode.html*】\nAT 的数据源代理中，分别对目标数据库的 DataSource 、 Connection 和 Statement 进行了代理，在执行目标 SQL 动作之前，完成了 RM 资源注册、 undo log 生成、分支事务注册、分支事务提交/回滚等操作，而这些操作对用户并无感知。\n下面的时序图中，展示了 AT 模式在执行过程中，这几个代理类的动作细节：\n注：图片建议在 PC 端查看\n4、AT 模式流程 以下是 AT 模式的整体流程，从这里可以看到分布式事务各个关键动作的执行时机，每个动作细节，我们后面来讨论：\n注：图片建议在 PC 端查看\n4.1 一阶段 在 AT 模式的第一阶段， Seata 会通过代理数据源，拦截用户执行的业务 SQL ，假如用户没有开启事务，会自动开启一个新事务。如果业务 SQL 是写操作（增、删、改操作）类型，会解析业务 SQL 的语法，生成 SELECT SQL 语句，把要被修改的记录查出来，保存为 “before image” 。然后执行业务 SQL ，执行完后用同样的原理，将已经被修改的记录查出来，保存为 “after image” ，至此一个 undo log 记录就完整了。随后 RM 会向 TC 注册分支事务， TC 侧会新加锁记录，锁可以保证 AT 模式的读、写隔离。RM 再将 undo log 和业务 SQL 的本地事务提交，保证业务 SQL 和保存 undo log 记录 SQL 的原子性。\n4.2 二阶段提交 AT 模式的二阶段提交，TC 侧会将该事务的锁删除，然后通知 RM 异步删除 undo log 记录即可。\n4.3 二阶段回滚 如果 AT 模式的二阶段是回滚，那么 RM 侧需要根据一阶段保存的 undo log 数据中的 before image 记录，通过逆向 SQL 的方式，对 …","date":1663657200,"description":"Seata AT 模式代码级详解","dir":"blog/20220920/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6769242244447e5e61c3cd74b1d4fbbb","permalink":"https://sofastack.github.io/sofastack.tech/blog/20220920/","publishdate":"2022-09-20T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/20220920/","summary":"文｜ 刘月财 seata-go 项目负责人 北京小桔科技有限公司【滴滴】开发工程师 赵新（花名：于雨 ) 蚂蚁集团 Seata 项目开源负责人 本文5343字 阅读 14分钟 背景 Seata 四种事","tags":["SOFAStack"],"title":"Seata AT 模式代码级详解","type":"blog","url":"/sofastack.tech/blog/20220920/","wordcount":4292},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.杜鑫 提问：\n 想问下 MOSN 的基于 Go plugin 实现的插件机制，有相关文档介绍嘛，源码大概在哪个部分呀？想接入下试试。\n A：有好几种，有 Go plugin 独立进程的，有 Go so 编译的，我发你文档先看看。\n 这个看啦，我看文档里说 so 的方式还在 beta，没有详细介绍，想了解下 so 方式的介绍。\n A：so 的，我们最近有位同学才分享了，干货满满：https://mp.weixin.qq.com/s/VAYrtYBdzvcAOa7G_cMZRg ，这里有个 demo，https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions 以及一些插件的实现，https://github.com/mosn/extensions/tree/master/go-plugin\n「MOSN」：https://github.com/mosn/mosn/\n2.林楠 提问：\n 有一个问题，动态部署时报找不到 CommonLoggingApplicationListener 类，这个类在基座中有这个类 https://github.com/sofastack/sofa-ark/issues/561\n A：说明这个类没有成功委托给基座加载，可以断下 BizClassLoader.loadClassInternal 方法，看下模块类加载的寻找过程。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 MOSN｜Go 原生插件使用问题全解析\nGo 内存泄漏，pprof 够用了么？\n如何看待 Dapr、Layotto 这种多运行时架构？\nSOFAServerless 助力业务极速研发\n欢迎扫码关注：\n","date":1663311600,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220916/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"810dfae8641310109a14ebe511d3d818","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220916/","publishdate":"2022-09-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220916/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220916/","wordcount":864},{"author":"SOFA 团队","categories":"SOFATalk","content":" 概要 活动主题：SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 活动时间：09 月 14 日，周三晚 19 点 活动形式：线上直播 直播回放：点击观看 资料下载：戳这里 查看文章：SOFARegistry 源码解析｜推送延迟 tracre 介绍 | SOFATalk \u0026amp;lt;SOFA:Talk/\u0026amp;gt; SOFATalk 系列活动是 SOFAStack 社区开展的全新直播栏目，与以往的直播不同的是，SOFATalk 为大家搭建了一个更加自由开放的交流环境，参与者不仅可以在直播间发送弹幕讨论，还能够进入钉钉会议与嘉宾直接连麦讨论！茶余饭后，跟着 SOFA Talk 一下～\n| SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 对于分布式注册中心，整个推送过程涉及到很多的流程和节点。如何计算从发布端变更到广播给全集群所有的订阅方的延迟？以及每个阶段的延迟分别是多少？这对排查集群内部的问题及注册中心的负载具有比较大的价值，因此需要对整个推送过程进行延迟链路跟踪。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n分享嘉宾 张晨\n SOFARegistry Contributor，开源爱好者。\n 嘉宾海报 了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1663138800,"description":"2022 年 9 月 14 日 19：00 - 20：00 ，Talk 第 1 期。","dir":"activities/sofa-talk-1/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7a05d225a66088112646cb4424d8f344","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-talk-1/","publishdate":"2022-09-14T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-talk-1/","summary":"概要 活动主题：SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 活动时间：09 月 14 日，周三晚 19 点 活动形式：线上直播 直播回放：点击观看 资料下载：戳这里","tags":["SOFATalk","SOFARegistry","源码解析"],"title":"SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace","type":"activities","url":"/sofastack.tech/activities/sofa-talk-1/","wordcount":473},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者、蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 2651 字 阅读 8 分钟\nMOSN 是主要使用 Go 语言开发的云原生网络代理平台，在蚂蚁集团有着几十万容器的大规模生产应用。在这种大规模的应用中，经常会遇到各种内存问题，通常情况下 pprof heap profile 可以很好帮助分析问题。不过，有时候 pprof 也不够用，也就需要我们有更合适的工具了。\nPart.1\u0026amp;ndash;出生证 vs 暂住证 首先 pprof 确实很好用，设计实现也都很精巧，有兴趣的可以查看这篇《Go 语言 pprof heap profile 实现机制》[1]。\n用 pprof 来分析内存泄漏，通常情况下是够用了，不过有时候，也会不够用。\n这是为什么呢？因为 pprof 只是记录了内存对象被创建时的调用栈，并没有引用关系。也就是说，没有办法知道，内存对象是因为被谁引用了而导致没有被释放。对此，我的同事\u0026amp;ndash;烈元同学有一个很形象的比喻，pprof 只能看到出生证，却查不了暂住证。\nPart.2\u0026amp;ndash;需要引用关系 有些场景下，我们知道了泄漏的内存是从哪里申请的，但是翻了半天代码，也搞不清楚内存为什么没有释放。比如，内存对象经过复杂的调用传递，或者复杂的内存池复用机制，又或者传给了某个不熟悉的第三方库，在第三方库中有非预期的使用……\n在这些情况下，我们会有一个很直觉的想法是，想看看这些内存对象的引用关系。\nPart.3\u0026amp;ndash;内存引用关系火焰图 内存引用关系火焰图，是一种内存对象引用关系的可视化方式，最早应用于 OpenResty XRay 产品。这个工具确实是内存分析神器，给不少的客户定位过内存问题，感兴趣的可以移步 OpenResty 官方博客[2]。\n下图是由一个 MOSN 服务产生的，自下而上表示的是从 GC root 到 GC object 的引用关系链，宽度表示的是对象大小 （也包括其引用的对象的大小之和） 。\n有了这样的可视化结果，我们就可以直观的看到内存对象的引用关系。\n比如下图最宽的部分，表示的是 MOSN 中 cluster_manager 全局变量中引用的 cluster 内存对象：\nhttps://github.com/mosn/mosn/blob/aecc93c4b2b4801e7992387f245fe9eefa45733d/pkg/upstream/cluster/cluster_manager.go#L82\nPart.4\u0026amp;ndash;实现原理 在生成火焰图之前，首先我们需要提取两个关键信息：\n- 每个内存对象之间的引用关系；\n- 每个内存对象的类型。\n引用关系 获取引用关系比较简单，首先，我们可以在 heap 中找到所有的 GC 对象。然后遍历所有的对象，再结合 bitmap 信息，获取这个对象引用的其他对象。基本原理跟 GC mark 是类似的，虽然实现上很不一样，但因为这个是离线工具，可以简单粗暴的实现。\n类型推导 Go 语言作为编译型静态语言，是不需要为每个内存对象存储类型信息的 （有点例外的是 interface） 。如果是动态类型语言，比如 Lua，则会方便很多，每个 GC 对象都存储了对象的类型。\n所以，要获取每个对象的类型，还是比较麻烦的，也是投入时间最多的一块。当然，还是有解决办法的，简单来说就是做逆向类型推导，根据已知内存的类型信息，推导被引用的内存对象的类型信息。\n这块还是比较复杂的，有兴趣的可以看这篇《Go 语言，如何做逆向类型推导》[3]的介绍。\n生成过程 有了这两个关键信息之后，生成过程如下还是比较清晰的：\n1. 获取所有的内存对象，包括类型、大小，以及他们之间的引用关系，形成一个图；\n2. 从 root 对象出发，按照层次遍历，形成一棵树 （也就是剪枝过程，每个对象只能被引用一次） ；\n3. 将这棵树的完整引用关系，当做 backtrace dump 下来，count 是当前节点的总大小 （包括所有子节点） ，也就是火焰图上的宽度；\n4. 从 bt 文件生成 svg，这一步是 brendangregg 的 FlameGraph 标准工具链。\nPart.5\u0026amp;ndash;使用方式 这个工具是基于 Go 官方的 viewcore 改进来的。不过，鉴于 Go 官方不那么热心维护 viewcore 了，MOSN 社区先 fork 了一份，搞了个 mosn 分支，作为 MOSN 社区维护的主分支。\n之前也给 Go 官方 debug 提交了好几个 bugfix，等后面有空，我们再去提交这个 feature。\n所以，使用方式如下：\n# 编译 mosn 维护的 viewcore git clone git@github.com:mosn/debug.git cd debug/cmd/viewcore go build . # 假设已经有了一个 core 文件（CORE-FILE） # 以及对应的可执行程序文件（BIN-FILE） viewcore CORE-FILE --exe BIN-FILE objref ref.bt # 下载 FlameGraph 工具 git clone git@github.com:brendangregg/FlameGraph.git ../FlameGraph/stackcollapse-stap.pl ref.bt | ../FlameGraph/flamegraph.pl\u0026amp;gt; ref.svg # 浏览器打开 ref.svg 即可看到火焰图 如果使用碰到问题，可以随时联系我们或提交 issue（https://github.com/mosn/mosn/issues）。\n当然，倘若你成功定位了某个问题，也欢迎与我们共同分享，Let\u0026amp;rsquo;s have fun together！\nMOSN 用户钉钉群：33547952\n相关链接 [1] 《Go 语言 pprof heap profile 实现机制》：https://uncledou.site/2022/go-pprof-heap/\n[2] OpenResty 官方博客：https://blog.openresty.com.cn/cn/openresty-xray-case-yundun/\n[3] 《Go 语言，如何做逆向类型推导》：https://uncledou.site/2022/go-type-derivation/\n了解更多… MOSN Star 一下✨： https://github.com/mosn/mosn\n插播一条好消息！🤩\n对 Go 语言开发感兴趣的小伙伴们,欢迎大家参与到近期正热的 GoCity 项目体验\n点击此处查看演示视频，快速入门吧🥳\n本周推荐阅读 MOSN 反向通道详解\nGo 原生插件使用问题全解析\nGo 代码城市上云\u0026amp;ndash;KusionStack 实践\nMOSN 文档使用指南\n欢迎扫码关注：\n","date":1663052400,"description":"Go 内存泄漏，pprof 够用了吗？","dir":"blog/is-pprof-enough-for-go-memory-leak/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c96e193420c2f17fd7653b33766f4296","permalink":"https://sofastack.github.io/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","publishdate":"2022-09-13T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者、蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 2651 字 阅读 8 分钟 MOSN 是主","tags":["SOFAStack"],"title":"Go 内存泄漏，pprof 够用了吗？","type":"blog","url":"/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","wordcount":2059},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过\u0026amp;rdquo;SOFA WEEKLY\u0026amp;rdquo;的形式回复\n1.我是一个小胖子 提问：\n MOSN 现在是已经完整支持 xDS 协议了吗？\n A：支持 istio1.10。\n 如果要支持 istio1.14 是需要重新适配吗？还是说有其他简化的方式？\n A：是需要适配下的，主要看新增了多少改动。\n「MOSN」：https://github.com/mosn/mosn/\n2.林楠 提问：\n 关在 uninstall biz 包的时候，没有从内嵌 Tomcat 卸载掉，接口仍能访问。看到 demo 中的提示是由于未注册 BeforeBizStopEvent，所以不具备动态卸载能力。想问下 SOFAArk 是否有计划做 Tomcat 的动态卸载，如果想自行实现的话，是不是调用 ArkTomcatWebServer 实例的 stop 方法就能够实现动态卸载？\n A：Spring Boot 模块没有动态卸载能力：https://github.com/sofastack/sofa-ark/issues/554#issuecomment-1207183454\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 MOSN｜Go 原生插件使用问题全解析\n社区文章｜MOSN反向通道详解\nMOSN 文档使用指南\nSOFAServerless 助力业务极速研发\n欢迎扫码关注：\n","date":1662706800,"description":"SOFA Weekly | Go 代码城市、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220909/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b48f13a6692060ffac5ff1eeb1886fb2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220909/","publishdate":"2022-09-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220909/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Go 代码城市、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220909/","wordcount":749},{"author":null,"categories":"SOFAStack","content":"导语\nKusionStack 是面向 Kubernetes 云原生场景的 IaC 配置代码化实践的开源一站式可编程协议栈。其基本思想是让「应用方+平台方」的同学能够共同基于 IaC 构建的 Konfig 模型库同一平面进行 DevOps 协同工作。今天我们和大家分享一个好玩的 Go 代码城市应用，以及 KusionStack 是如何一键将其部署到 K8s 云原生环境的。\nKusionStack 项目主仓库：\nhttps://github.com/KusionStack/kusion\nPART. 1\n什么是代码城市（CodeCity）\nCodeCity 代码城市是瑞典工程师 Richard Wettel 开发的创意应用，可以通过类似数字城市的视觉形式展示和度量代码的复杂性。其效果如图：\n在 3D 形式展示的代码城市中的中心地标非常直观——最大、最高的建筑总是容易追踪的焦点。因为这个极具特色的创意，CodeCity 获得了 2008 年的\u0026amp;rdquo;Riconoscimento ated-ICT Ticino\u0026amp;rdquo; 一等奖，同时也可以免费用于非商业的科研和学习用途。\n今天要展示的 GoCity 是 Go 语言版本的代码城市，我们可以通过这种方式评估 KusionStack 等 Go 语言项目的代码复杂度。也可以通过在线的 GoCity 查看 KusionStack/kusion 仓库的展示效果。\nPART. 2\n本地执行 GO 代码城市\n之前的 GoCity 还是在 2021 年 10 月更新的，在最新的 Docker 和 Go1.18 环境有一些小问题，还好 KusionStack 相关同学为其提交了补丁进行了修复（_这也是开源项目的魅力所在，也希望开源社区小伙伴能够参与 KusionStack 的共建_），现在可以执行以下命令安装：go install github.com/rodrigo-brito/gocity@latest。然后通过 gocity open 打开 Github 或本地仓库。\n- 比如打开本地的 KusionStack/kusion 仓库\n- 然后浏览器打开对应页面\n本地执行一切正常！\nPART. 3\nGo 代码城市一键上云\n作为一个类似数字城市的应用，在云原生、元宇宙等背景下，部署上云也是一个自然的需求。同时我们也希望通过 GoCity 展示下 KusionStack 的基本用法。在 GoCity 上云之前，我们先尝试如何本地执行该应用。\n相应的容器镜像已经推送到 Docker Hubhttps://hub.docker.com/r/yuanhao1223/gocity，运行命令如下：\n运行成功后，可打开本地地址http://localhost:4000/查看 Go 项目的数字城市 3D 效果。\n容器化成功后，现在准备上云。从本地执行容器的方式可以看出，想要在 Kubernetes 部署，至少需要 Deployment 和 Service 两种资源。其中 Deployment 用来部署 Go 代码城市，Service 暴露端口，访问无状态应用。\n首先参考安装文档https://kusionstack.io/docs/user_docs/getting-started/install/安装好本地 Kusion 命令，然后通过 kusion init 的在线仓库提供了相应的模板。Kusion 命令支持一键初始化配置：\n输出类似以下信息：\n为了方便展示，Kusion 模板已经内置了 CodeCity 的例子。其中 code-city 模板依赖 konfig 大库中抽象化的前/后端模型，code-city 模板无依赖，可以自闭环。我们选择后者：\n初始化过程中，指定了容器镜像，并且容器端口和 Service 端口均为 4000，现在进入配置目录，目录结构如下：\n- 完整的代码可以参考 ：\nhttps://github.com/KusionStack/kusion-templates/tree/main/code-city-demo\n为了方便本地测试，可以通过 minikube start 本地启动 MiniKube 服务。然后命令行模式切换到 code-city-kcl 目录，然后执行 kusion apply 命令生效配置。到此，开始正式上云： kusion apply main.k\n输出类似于：\n检查 Deployment 的状态：\n输出类似于：\n使用 kubectl 端口转发：\n访问本地地址https://localhost:4000/)，点击 Example 处的链接 “KusionStack/kusion”，可以看到和本地执行一样的效果：\n至此，完成了 Go 代码城市的一键上云。有兴趣的读者，可以基于模型库 Konfig，选择其他模板，探索 KusionStack 支持的其它运维场景，下面我们将探索代码城市内部的原理。\nPART. 4\n认识数字城市中的建筑含义\n说实话代码城市第一眼看上去更像一个电路板，要理解其中的含义需要了解几个基本的参数映射关系，如预览页面的右下角图所示：\n以上的对应关系在其官方文档中也说明，如下图所示：\n其中地面的粉红色表示 Go 包对应的目录（_因为包的依赖关系可能再产生叠加_），灰色表示目录内部的文件，而蓝色表示结构体。其中表示文件的灰色建筑物的大小即文件的大小，表示结构体的蓝色建筑物的高度即方法的数量，建筑物的长宽表示结构体中属性的数量，蓝色颜色的深度表示相关代码行数。\n我们可以选择 DiffOptions 结构体对应建筑物查看其相关的属性参数：\n可以看到该结构体中有 15 个属性、3 个方法、共 156 行代码。通过点击其中的 “Github 链接” 按钮可以跳转到对应的位置：\n因此通过这种方式我们可以很容易查看全局有无特别高大的建筑，从而判断是否存在某些文件和结构体的代码需要改进。可以说 GoCity 是一个很有趣的代码分析工具，甚至可以集成到 Github PR 代码评审流程中。\nPART. 5\n分析 GoCity 的代码架构\nGoCity 代码架构主要分为代码数据提取和前端模型展示两块，如图所示：\n首先 Codebase 表示要展示的代码，通过 Git Service 被拉取，然后通过 Parser 和 Position 服务提取得到对应的参数信息，然后通过前端展示。Go 语言代码主要集中在模型数据提取部分，而前端展示主要为 JS 等实现。前端展示资源文件通过 embed.FS 内嵌到程序中，GoCity 命令启动 Web 服务展示页面。代码架构比较清晰，也是一个比较理想可用于 Go 语言学习的开源项目。\nPART. 6\n展望\n我们通过 KusionStack 的方式，配合少量的 KCL 配置代码，完成了 Go 代码城市一键上云的操作。虽然云上的 Go 代码城市和本地的版本看不出什么区别，但是云上程序的整个生命周期管理将大为不同。在后面的例子中我们将展示如何通过 KusionStack 结合 KCL 配置语言进行 IaC 方式的云原生应用的运维操作。感谢关注🙏\n参考链接\n● …","date":1661842800,"description":"Go 代码城市上云——KusionStack 实践","dir":"blog/go-code-city-cloud-kusionstack-practice/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"577810f0ec8cee7a80e6717647a67bbe","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","publishdate":"2022-08-30T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","summary":"导语 KusionStack 是面向 Kubernetes 云原生场景的 IaC 配置代码化实践的开源一站式可编程协议栈。其基本思想是让「应用方+平台方」的同学能够共同基于 IaC 构建的 Konfig 模型库同一平","tags":["SOFAStack"],"title":"Go 代码城市上云——KusionStack 实践","type":"blog","url":"/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","wordcount":2203},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. 孙春明 提问：\n 请问这个 mosnd 是做什么的？我如果想重新做 mosnio/proxyv2:v1.0.0-1.10.6 镜像，需要怎么处理呢？\n A：这个 mosnd 只是 mosn 的拷贝，可以看下这个文档：https://mosn.io/docs/user-guide/start/istio/#mosn-%E4%B8%8E-istio-%E7%9A%84-proxyv2-%E9%95%9C%E5%83%8F-build-%E6%96%B9%E6%B3%95\n「MOSN」：https://github.com/mosn/mosn\n2. 胡 提问：\n 请问这边有现成用 SOFAStack 搭建的框架包吗，内容涉及 SOFABoot、SOFARegistry、SOFARPC 的？\n A：现成的框架包的话，你可以从 SOFABoot 开始，参考这个：https://www.sofastack.tech/projects/sofa-boot/quick-start/\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n「SOFARegistry」： https://github.com/sofastack/sofa-registry\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nMOSN v1.1.0 版本发布\n发布 MOSN v1.1.0 版本，主要变更如下：\n 支持反向建连，云边互联场景，细节可以参考博客： https://mosn.io/blog/posts/mosn-tunnel/\n 支持自定义 xDS 解析扩展\n trace 支持 zipkin 扩展\n 优化创建 subset 负载均衡的算法，降低内存占用\n 详细发布报告：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md\n本周推荐阅读\nMOSN 构建 Subset 优化思路分享\nMOSN 1.0 发布，开启新架构演进\nMOSN 社区性能分析利器——Holmes 原理浅析\nMOSN 反向通道详解\n欢迎扫码关注\n","date":1661497200,"description":"SOFA Weekly | MOSN v1.1.0 版本发布、C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220826/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"60009aeca74279e2fb1f880466fa50dd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220826/","publishdate":"2022-08-26T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220826/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.1.0 版本发布、C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220826/","wordcount":951},{"author":null,"categories":"SOFAStack","content":"文｜史贵明（花名：莫城)\n蚂蚁集团技术专家\n蚂蚁集团多云配置管理系统技术负责人\n云原生基础设施领域，容器服务、配置管理、IaC、PaC、GitOps 等方向\n本文 2369 字 阅读 7 分钟\n背景\n要讲 Kusion 在蚂蚁集团的实践，我们首先来了解下蚂蚁集团在此之前的配置管理状况。\n如上图所示，图中展示的是在结合 Kusion 之前的应用基线配置管理系统。这里提到的 “应用基线配置” 非应用动态开关，而是注入应用依赖的软件版本、中间件配置、网络数据库等基础设施配置。\n从上图可以看到，应用基线管理系统是标准 BS 架构，对用户提供 Console 和 API，历经 6、7 年发展历史，承担起蚂蚁集团历史上绝大多数应用基线配置需求，功能丰富且拥有极其复杂的配置计算能力。目前已经支撑了 15000+ 应用、近 400 项应用配置、50+ 全局配置。\n在这个架构下，最上层用户通过表单或者集成系统 API 来与系统交互，以 RDBMS 为存储介质，将应用的配置以类 Key-Value 形式存储。能力层主要包含通用的角色管理、认证鉴权、版本与配置审计等通用能力，还提供模板化的方式来计算应用配置，如将 Deployment 模板化，最终将用户的基线配置渲染为 Deployment，同时模板与基线配置都存在非常复杂而又灵活的继承能力，举个例子，可以给应用配置 Zone_（逻辑机房）_级别的基线，也可以配置环境级别的基线，或者应用级别的基线，前者可以继承后者，就像子类和父类的集成关系。\n除了应用本身的基线配置，同时也管理了全局配置，如全局的 DNS 配置、Load Balance、网路配置等等。这个架构非常经典，并且有效支持了历史上各种配置需求及各种 618、双 11 等场景，这些都是毋庸置疑的。但是随着蚂蚁集团云原生化进程的推进，上面的经典架构也逐渐出现一些瓶颈。 不知道大家对于这种架构的配置管理，或者架构有没有遇到这样的问题？我来举几个例子：\n● 灵活性： 业务越来越多，应用的基础设施配置也更加的灵活，各种定制化需求越来越多，原有架构主要解决标准应用的场景和通用场景；\n● 开放性： 基线系统的核心能力主要代码在 PaaS 同学这边负责，对于多种多样的需求需要内部排期支持，开放性不足，无法复用和沉淀强大的 SRE 团队的经验；\n● 透明性： 配置计算黑盒，很多配置的计算逻辑都 hardcoding 在代码中，一个配置的变更最终会影响什么、影响有多大无法确定。比如修改了全局 sidecar 版本，导致线上应用批量异常。\n业界对标\n带着上面这些问题，我们在业界做了一些对标和学习:\n1.在 Google的《The Site Reliability Workbook》这本书中，Google 同学从自身的实践中总结出一些常见问题，其中非常重要的一点是：在做配置管理过程中，没有意识到，大规模配置管理问题的本质是编程语言问题。配置需求的声明、校验都可以通过语言来解决。\n2.从 Google 自身的实践来讲，K8s 是基于 Google 多年大规模集群管理经验贡献的开源产品，但是其内部主要使用的是 Borg，Borg 团队是在 Borg master 之上研发的，Borg 接入的三件套分别是：\n● BCL： 用户通过编写 BCL 代码实现对基础设施需要的配置；\n● Borgcfg： 通过 Borgcfg 将配置执行到 Borg 集群；\n● Webconsole： 通过 Webconsole 查看发布情况。\n经过调研，我们了解到 Google 大量的运维能力、产品、质量生态都是基于上述三件套演进多年。\n基于上述的一些总结，我们推演出类 Borg 的思路来解决蚂蚁集团的基础设施配置管理，我们尝试用语言和工具及服务实现蚂蚁集团下一代配置管理架构。\n下一代配置管理架构\n在这个新的架构下，我们可以看到整体架构不仅仅是一个简单的 BS 架构，配置的用户界面也从浏览器 Form 表单演进为中央开放配置大库。而配置大库所使用的就是 Kusion，Kusion 的用户使用前面的同学已经讲过了，对于配置大库本身的技术细节我不做过多的展开，这里强调的是大库在设计上支持多站点交付的架构。\n新配置管理架构主要分为以下几个特点：\n● 基于配置代码化理念抽象建设统一的应用配置模型，沉淀可重用模型组件，实现配置代码一次编写多站点可迁移。抽象领域模型：Stack 是配置的最小集合，Project 是一组 Stack 的抽象，不仅囊括 App 的应用基线配置, 也支持其他如 DataBase 配置、负载均衡配置，甚至 Network Policy 等非应用配置。\n● 通过策略控制器机制，创建与组织独特的安全性，合规性和治理要求相对应的防护规则。\n● 声明式自动化，持续监控运行状态并确保符合 Git 中定义的期望状态。\n应用发布案例\n接下来结合一个具体产品案例做阐述，在这个案例中以应用迭代发布为例：\n1.用户在业务迭代中，修改业务代码、提交代码、CI 测试、构建镜像，并将构建的镜像推送到远程镜像中心。然后通过配置管理服务层——这里是 auto-image-updater 组件——自动将配置更新到配置大库对应的配置文件中。\n2.触发大库的变更扫描、测试、审核等一些列的质保手段，同时触发一次应用发布流程，应用发布流程是具有风险体系的、可视化的发布流程，包括推进流程要从预发、仿真、灰度逐步推进，最后进入生产环境。\n在每个推进阶段，需要从配置大库获取到配置代码并同时使用配置管理服务层获取 KCL 的编译结果，也就是 Spec 模型，然后通过产品化方式将 Spec 与生产环境中真实的 Runtime 进行“Live Diff”以供参与人更好地识别变更内容和变更范围，然后以分组发布等具有风险防控的手段变更到对应环境，如 apply 到 K8s 集群。\n3.我们看下过程中的具体可视化产品，可以看到发布进度、应用配置的 Diff，以及可以看到历史版本的配置。\n问题与展望\n回顾下我们开始提到的几个问题：\n1. 灵活性： 即对各种灵活定制化需求的支持;\n2. 开放性： 通过 KCL 语言及开放配置大库，用户的基础设施配置通过新的用户界面即可自主完成，不需要等待配置管理平台开发人员进行开发；\n3. 透明性： 变更过程可以通过产品化的“Live Diff”来识别变更风险；\n我们通过上述的一些探索，一定程度上解决了蚂蚁集团在推进云原生进程中的问题，过程中也遇到了方方面面的困难，比如如何从老架构切换到新架构？架构代际演进时新老系统并存问题是必须要解决的，可以通过如双写等方式解决。在新架构下更值得探讨的有如下问题，全局配置如何管理以及如何更好的扩展配置的维度。\n站点的全局配置，在老的基线配置的全局配置不仅仅是简单的 Key-Value， 在使用上是非常复杂的，比如 DNSConfig 配置，按照租户、环境、Zone 等做了不同的优先级编排，对于这些的描述比较复杂，使用 KCL 描述如此复杂的配置很困难。\n针对于配置的继承和扩展，以 APP 基线配置为例，目前更多的是支持应用和应用环境级别的配置，针对 Zone 等细粒度的配置需要在 KCL 代码中通过写 if else 来实现，这对 …","date":1661238000,"description":"KusionStack 在蚂蚁集团的探索实践 (上)","dir":"blog/kusionstack-in-practice-at-ant-group-first/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8bfaea9639af72bb640f142108de2d90","permalink":"https://sofastack.github.io/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","publishdate":"2022-08-23T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","summary":"文｜史贵明（花名：莫城) 蚂蚁集团技术专家 蚂蚁集团多云配置管理系统技术负责人 云原生基础设施领域，容器服务、配置管理、IaC、PaC、GitOp","tags":["SOFAStack"],"title":"KusionStack 在蚂蚁集团的探索实践 (上)","type":"blog","url":"/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","wordcount":2774},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 卿同学 提问：\n 想咨询一下，目前蚂蚁内部使用 MOSN 外有使用到 Envoy 吗？\n A：目前蚂蚁的东西向网关是 MOSN on Envoy 的，Layotto on Envoy 也在试点中，所以没有直接使用 Envoy，不过很多场景是跑在 Envoy 上的。\n 那在 RPC、MQ、DB 流量这块都走 MOSN 流量拦截的方式吗？还是基于 Layotto API 的方式呢？\n A：目前主要是 MOSN，多语言和多云场景在走 Layotto 的方式。\n 我看 Layotto 也在推动和 Envoy 的融合，这一块现在有进展吗？\n A：今年我们首先会开源 Envoy 的 cgo 插件，然后基于这个插件，可以把 Layotto 跑在 Envoy 上。\n「MOSN」：https://github.com/mosn/mosn\n「Layotto」：https://github.com/mosn/layotto\n2. 古寒 提问：\n 咨询下， MOSN 部署有指导文档嘛？\n A：有的，看下这个文档，https://mosn.io/docs/user-guide/start/proxy/\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 社区文章｜MOSN 构建 Subset 优化思路分享\n如何看待 Dapr、Layotto 这种多运行时架构\nMOSN 文档使用指南\nMOSN 社区性能分析利器——Holmes 原理浅析\n欢迎扫码关注：\n","date":1660892400,"description":"SOFA Weekly | C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220819/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"187a873747e511ae312c36058eb71f8c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220819/","publishdate":"2022-08-19T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220819/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220819/","wordcount":758},{"author":null,"categories":"SOFAStack","content":" 文｜\n赵新（花名：于雨)：蚂蚁集团 Seata 项目开源负责人、开放原子开源基金会代码贡献之星\n郭成（花名：星北)：Seata-php 项目共同发起人、蚂蚁集团技术专家\n刘岳健：Seata-php 项目共同发起人、Hyperf 开发组成员、广东快客电子商务有限公司高级后端工程师\n本文 5894 字 阅读 12 分钟\n导语 通俗地讲，seata-php 是 Seata 的 PHP 语言实现，它实现了 Java 和 PHP 之间的互通，让 PHPer 也能使用 seata-php 来实现分布式事务。\nSeata 是一个非常成熟的分布式事务框架，在 Java 领域是事实上的分布式事务技术标准平台。Seata 目前正在构建其多语言体系[1]，整个体系包含了目前常用的五大类语言：Java、Go、Python、JS 和 PHP。目前的态势是后四种语言都依据 Seata Java 版本构建起对应语言的实现。\n除了追求 Seata 多语言体系过程中因为开源价值要求构建 Seata 的 PHP 版本这个原因外，作为构建起 Web 1.0 时代技术基础 LAMP 架构中的要角，PHP 语言在电商和金融交易场景下依然被广泛使用。而这些场景对数据一致性要求非常强烈，这是构建 seata-php 最大的诱因，也是其技术价值所在。\nPART. 1\u0026amp;ndash;Seata 架构与多语言体系 图片来自 Seata 官网\n Seata 总体架构由如下角色构成：\n- 事务协调器 Transaction Coordinator\n简称 TC，维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n- 事务管理器 Transaction Manager\n简称 TM，定义全局事务的范围，提交或者回滚全局事务。\n- 资源管理器 Resource Manager\n简称 RM，和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\n从 C/S 通信架构角度来看，TC 是服务端，TM 和 RM 是客户端。TC 与 TM 以及各个 RM 之间使用 Netty 框架进行长链接通信。具体而言，Seata Java 版本的通信协议是在四层 TCP 协议之上又定义了一套私有的二进制双向通信协议，通信框架使用了 Netty。其他四种语言只要依据 Seata 的通信协议标准实现其通信功能，即可在多语言生态体系内任何语言之间进行通信和服务调用。\n三个角色中，TM 和 RM 以 SDK API 形式供上层 APP 调用，而 TC 是独立进程部署，使用任何语言实现都可以。据说懒惰是程序员的第一美德，在 Seata Java 已经实现了 Java 版本的 TC 的情况下，多语言体系内其他语言就没必要再做重复工作，只需要构建其对应语言的 TM 和 RM 的 SDK API 包，与 Seata Java TC 通信即可。\nPART. 2\u0026amp;ndash;Seata 与 PHP 技术 分布式事务技术是微服务技术体系的一环，构建 Seata PHP 首先需要选择其微服务技术平台，seata-php 目前使用的微服务框架是 Hyperf。\nPHP 在业界以入门门槛低著称，目前常用的微服务框架有 Laravel 以及在其上构建的 Lumen。Laravel 框架的最大优点就是其生态丰富，各种组件应有尽有，如果 Laravel 可以和 Spring 框架类比，Lumen 就是 Spring Boot。但其缺点是性能堪忧，例如在普通的 8C 机器上，空跑一个只运行 echo 逻辑的 HTTP 服务，其吞吐量仅有 1K QPS。\nHyperf 框架是近年内出现的由国人基于 Swoole 开发的一个微服务框架，特点如下：\n1. 类似于 Nginx，Hyperf 以多进程形式常驻内存，每个进程内都有一个弹性线程池。正常情况下 Hyperf 收到调用请求后，可以保证 1ms 之内分配服务线程，而 Lumen 的响应时间常在 10ms 左右；\n2. 因为 Hyperf 服务常驻内存的特点，其稳定性好，资源利用率当然比以 CGI 机制运行的 Lumen 低很多；\n3. Hyperf 的对请求的处理过程借鉴了 Go 语言机制，其 runtime 层面以异步方式执行上层的用户同步调用，相比 Lumen 其吞吐率高而延迟低。例如在同样环境下使用 Hyperf 实现同样的 echo HTTP 服务，可以轻松达到 60K QPS；\n除了 Hyperf 自身稳定性与高性能外，依赖于 Hyperf 服务进程常驻内存的特点，TC 可以很方便的对seata-php 的 RM 发起二阶段事务处理，即作为 Server 的 Java TC 对作为 Client 的 PHP 版本的 RM 发起 RPC 回调。如果使用 Lumen 作为 seata-php 的微服务框架，几乎不可能实现这个技术点。\nPART. 3\u0026amp;ndash;快速入门 seata-php 基于 Hyperf 微服务框架，seata-php 已经实现了 AT 事务模式，并给出了测试用例。本章节的目的是基于现有实现，让对 seata-php 这个项目感兴趣的同学能够快速入门 seata-php。\n3.1\u0026amp;ndash;搭建 PHP 开发环境 使用 Hyperf/Box 这个工具能够快速创建开发环境，并且能够与其他自建开发工具链隔离，避免污染日常的开发环境。\n3.1.1 下载 Hyperf/Box # Mac wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_x86_64_macos -O box # Linux x86_64 wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_x86_64_linux -O box # Linux aarch64 wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_aarch64_linux -O box sudo mv ./box /usr/local/bin/box sudo chmod +x /usr/local/bin/box # 在 https://github.com/settings/tokens/new 创建 token 后，配置到 box 中 box config set github.access-token \u0026amp;lt;Your Token\u0026amp;gt; 注意：\n- 如果你是 Mac 用户首次使用的话，需要在“系统偏好设置”\u0026amp;ndash;\u0026amp;gt;“安全性与隐私”中给 Box 工具进行授权；\n- 已经测试过，X86 的 Box，可以在 M1 版本的 Mac 上使用；\n- 使用 Box 时，创建 GitHub access token 权限需要 repo、workflow。\n3.1.2 配置 PHP 环境 当 Box 下载好后，继续下载 PHP 8.0 版本\n# 下载 php8.0 box get …","date":1660633200,"description":"让 PHPer 也能使用 seata-php 来实现分布式事务","dir":"blog/seata-php-semi-annual-planning/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ee9381666d88165cad305e1b3880d181","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-php-semi-annual-planning/","publishdate":"2022-08-16T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/seata-php-semi-annual-planning/","summary":"文｜ 赵新（花名：于雨)：蚂蚁集团 Seata 项目开源负责人、开放原子开源基金会代码贡献之星 郭成（花名：星北)：Seata-php 项目共同发起人、蚂蚁集","tags":["SOFAStack"],"title":"Seata-php 半年规划","type":"blog","url":"/sofastack.tech/blog/seata-php-semi-annual-planning/","wordcount":4330},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup 合肥站-云原生技术沙龙\n 活动时间：2022 年 08 月 13 日（周六）13:30-17:00\n 活动地点：合肥市高新区创新创业园 D8 栋一楼集思空间\n 活动形式：线下活动\n 资料下载：\n《SOFA Serverless 体系助力业务极速研发》\n《KusionStack 在蚂蚁规模化运维的探索和总结》\n 本次分享涉及的项目地址：\n【SOFAArk】https://github.com/sofastack/sofa-ark\n【KusionStack】https://github.com/kusionstack/kusion\n 活动介绍 活动议程 直播回放 SOFA Serverless 体系助力业务极速研发\nKusionStack 在蚂蚁规模化运维的探索和总结\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1660374000,"description":"SOFA Meetup 合肥站-云原生技术沙龙","dir":"activities/sofa-meetup-17/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"717c5211a439598278a7cbb834d09bb0","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-17/","publishdate":"2022-08-13T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-17/","summary":"概要 活动主题：SOFA Meetup 合肥站-云原生技术沙龙 活动时间：2022 年 08 月 13 日（周六）13:30-17:00 活动地点：合肥市高新区创新创业园 D8 栋","tags":["SOFAMeetup"],"title":"SOFA Meetup 合肥站-云原生技术沙龙","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-17/","wordcount":346},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 信广健 提问：\n 经过十分曲折的故事了解到了 Layotto ， 进群后想看看后续发展，有什么好的文档可以学习下吗？\n A：目前还在活跃开发中，可以看下 https://github.com/mosn/layotto 了解下，相关的文档也在 https://mosn.io/layotto/\n「Layotto」：https://github.com/mosn/layotto\n2. 清源 提问：\n 现在 MOSN 除了适配 XDS 做到动态规则下发之外？有没有其他的动态规则下发办法？\n A：你可以自己实现的，XDS 也是调用 MOSN 的更新 API。\n「MOSN」：https://github.com/mosn/mosn\n3. 樊志超 提问：\n 问一下，MOSN 与业务容器间的信息交互是采用 socket 方式吗？\n A：这个看你怎么用了，自己选择。\n 默认的是哪种方式呢？\n A：TCP、UDS 都可以。\n「MOSN」：https://github.com/mosn/mosn\nSOFARPC 5.8.6 版本发布 SOFARPC 5.8.6 是一个功能优化、Bug 修复版本，建议使用 5.7.10 ~ 5.8.5 版本的用户都升级到 5.8.6。\n主要变更如下：\n- 功能优化：\n1.支持用户自定义 tracer 中 callerAppName\n2.添加 DomainRegistry 订阅域名数据, 支持 direct url 功能\n- BUG 修复：\n1.修复了 Triple 协议在多 classLoader 环境下的序列化问题\n详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.8.6\n本周推荐阅读 蚂蚁开源：开放自研核心基础软件技术，携手探索技术高地\n\nGo 原生插件使用问题全解析\n\nMOSN 反向通道详解\n\n如何看待 Dapr、Layotto 这种多运行时架构\n\n欢迎扫码关注：\n","date":1660287600,"description":"SOFA Weekly | SOFARPC 5.8.6 版本发布、Meetup 合肥站、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220812/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"06f5bddaf802462077c913d20d2f9d15","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220812/","publishdate":"2022-08-12T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220812/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 5.8.6 版本发布、Meetup 合肥站、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220812/","wordcount":861},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup 广州站-云原生技术交流\n 活动时间：2022 年 08 月 06 日（周六）14:00-18:00\n 活动地点：广州市海珠区阅江西路 88 号阿里中心北塔 4F 万松书院\n 活动形式：线下活动\n 资料下载：\n《基于 P2P 的文件和镜像加速系统 Dragonfly》\n《Buildpacks \u0026amp;amp; Argo CD GitOps》\n《KusionStack 实践探秘｜技术、角色与应用场景篇》\n《KubeSphere 在青花瓷的落地实践与展望》\n《Holmes｜Go 应用性能异常诊断定位利器》\n《云原生应用灾备最佳实践》\n 本次分享涉及的项目地址：\n【Dragonfly】https://github.com/dragonflyoss\n【KusionStack】https://github.com/kusionstack/kusion\n【MOSN】https://github.com/mosn/mosn\n 活动介绍 活动议程 直播回放 Dragonfly：基于 P2P 的文件和镜像加速系统\nKusionStack 实践探秘｜技术、角色与应用场景篇\nHolmes｜Go 应用性能异常诊断定位利器\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1659769200,"description":"SOFA Meetup 广州站-云原生技术交流","dir":"activities/sofa-meetup-16/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cc936d9167acee9569070c076ab0da31","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-16/","publishdate":"2022-08-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-meetup-16/","summary":"概要 活动主题：SOFA Meetup 广州站-云原生技术交流 活动时间：2022 年 08 月 06 日（周六）14:00-18:00 活动地点：广州市海珠区阅江西路 88 号阿","tags":["SOFAMeetup"],"title":"SOFA Meetup 广州站-云原生技术交流","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-16/","wordcount":504},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 吴宇奇 提问：\n 请问下，Bolt 协议里面的这个 cmdCode，除了心跳、request、response，还有别的用法吗？ A：举个例子，新增 goaway 扩展。https://github.com/sofastack/sofa-bolt/issues/278\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\n2. bobtthp 提问：\n 大佬们问下动态路由这块，有 example 可以看看嘛？ A：这篇文章就是例子哟，https://mosn.io/blog/posts/how-use-dynamic-metadata/#%E5%8A%A8%E6%80%81%E8%B7%AF%E7%94%B1-cluster ，原理就是 route 的配置是变量，然后 streamfilter 根据业务逻辑修改这个变量的值，很方便试试。\n 好的，这个我有一个疑问。这个变量如何注入进去呢？我理解应该每一个节点的变量都不一样嘛？还有一个疑问是，如果需要和配置中心交互这块是怎么做的，可以借鉴一下吗？\n A：变量就是 streamfilter 模块分配的，然后他来设置这个变量的值，值就是 cluster 的名字；后面那个问题指的是 cluster host 的更新吗？\n 指的是如果需要外部的配置中心那可能需要监听配置的动态变化；第一个这块我好像没理解好，我举个例子：如果是多个应用，那是不是我要设置多个变量？\n A：比如你 A 应用的 cluster 名字是 A，B 应用的 cluster 名字是 B， 那么这个变量只需要一个，只是 value 你可以根据逻辑设置为 A 或者 B。\n这个就是一些复杂的路由场景，用配置不能表达，就可以用代码的方式来做这个事。我们内部的一些复杂路由场景也是这样做的。\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 云原生 Meetup 广州站，等你来！\n\nGo 原生插件使用问题全解析\n\nMOSN 反向通道详解\n\nKusionStack｜Kusion 模型库和工具链的探索实践\n\n欢迎扫码关注公众号：\n","date":1659682800,"description":"SOFA Weekly | Meetup 广州站参会指南、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220805/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"51544dab85fa7fe78001737602f2536b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220805/","publishdate":"2022-08-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220805/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Meetup 广州站参会指南、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220805/","wordcount":1038},{"author":null,"categories":"SOFAStack","content":" 文｜郑泽超（GitHub ID：CodingSinger )\n字节跳动高级工程师\n热衷于微服务和 ServiceMesh 开源社区\n本文 6802 字，阅读 15 分钟\nPart.1\u0026amp;ndash;贡献者前言 说起来非常的抓马，当时和 MOSN 的相遇是在给于雨负责的开源项目 Dubbo-go 贡献代码那阵。在自己顺利当上了 Dubbo 开源社区的 Committer 之后，心想着能更深入的学习 Golang 语言，机缘巧合之下碰到了 MOSN 的老大哥烈元 （也是元总领我进了 MOSN 社区的大门） 。\n作为一款目标对齐 Envoy 的高性能可扩展安全网络代理，MOSN 支持的生态能力更贴近国内互联网公司的技术栈，并且对新功能的响应也很迅速。其次 MOSN 有着很多值得借鉴的巧妙设计和进阶的使用技巧，能充分满足自己在工作之外深入学习 Golang 语言的诉求。\n目前，我在社区里陆续参与了 EDF Scheduler、LAR、WRR 负载均衡、DSL 路由能力、UDS Listener、Plugin 模式的 Filter 扩展以及反向通道等一些比较大的 feature 能力建设。再次感谢雨哥、元总、鹏总、毅松等社区内一众大佬们帮我考究方案并且帮我 Review 代码。\n本文主要介绍之前新合入 master 分支的「反向通道」的使用场景和设计原理，欢迎大家留言探讨。\nMOSN 项目概述 MOSN（Modular Open Smart Network）是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并经过双 11 大促几十万容器的生产级验证，具备高性能、易扩展的特点。MOSN 可以和 Istio 集成构建 Service Mesh，也可以作为独立的四、七层负载均衡、API Gateway、云原生 Ingress 等使用。\nPart.2\u0026amp;ndash;MOSN 的反向通道实现 在云边协同的网络场景，通常都是单向网络，云侧节点无法主动发起连接与边缘节点通讯。这种限制虽然在极大程度上保证了边缘节点的安全，但缺点也很明显，即只允许边缘节点主动发起访问云端节点。\n云边隧道旨在解决云端无法主动访问边缘节点的问题，其本质是一个反向通道 （后文统称为反向通道） 。通过在边缘侧主动发起建连的方式与云端节点之间构建一条专用的全双工连接，用来传输云端节点的请求数据和回传最终的响应结果。\n目前例如 SuperEdge、Yurttunnel 等业界知名云边协同开源框架，对于云边通信的实现方案都是基于反向通道。\n本文将着重介绍 MOSN 之上的反向通道运作流程和原理。总体架构如下所示 (图中箭头表示 TCP 建连反向) ：\n整个运作流程可以简单概括为：\n1. 边缘侧的 MOSN 实例 （后文统称为 Tunnel Agent） 在启动时 Tunnel Agent 相关服务协程。\n2. 通过指定的静态配置或者动态服务发现方式拿到需要反向建连的公有云侧的 MOSN Server 地址列表 （后文统称 Tunnel Server ） ，并且建立反向连接。\n3. 云侧的 Frontend 与 Tunnel Server 侧的转发端口进行数据交互，这部分数据会被托管到之前建立的反向连接进行发送。\n4. 边缘节点接受到请求之后，再将请求转发给实际的后端目标节点，回包过程则远路返回。\nPart.3\u0026amp;ndash;反向通道启动过程 MOSN Agent 通过 ExtendConfig 特性，在 MOSN 启动时加载和完成初始化 Tunnel Agent 的工作。\nExtendConfig 中定义 AgentBootstrapConfig 结构如下：\ntype AgentBootstrapConfig struct { Enable bool `json:\u0026amp;quot;enable\u0026amp;quot;` // The number of connections established between the agent and each server ConnectionNum int `json:\u0026amp;quot;connection_num\u0026amp;quot;` // The cluster of remote server Cluster string `json:\u0026amp;quot;cluster\u0026amp;quot;` // After the connection is established, the data transmission is processed by this listener HostingListener string `json:\u0026amp;quot;hosting_listener\u0026amp;quot;` // Static remote server list StaticServerList []string `json:\u0026amp;quot;server_list\u0026amp;quot;` // DynamicServerListConfig is used to specify dynamic server configuration DynamicServerListConfig struct { DynamicServerLister string `json:\u0026amp;quot;dynamic_server_lister\u0026amp;quot;` } // ConnectRetryTimes ConnectRetryTimes int `json:\u0026amp;quot;connect_retry_times\u0026amp;quot;` // ReconnectBaseDuration ReconnectBaseDurationMs int `json:\u0026amp;quot;reconnect_base_duration_ms\u0026amp;quot;` // ConnectTimeoutDurationMs specifies the timeout for establishing a connection and initializing the agent ConnectTimeoutDurationMs int `json:\u0026amp;quot;connect_timeout_duration_ms\u0026amp;quot;` CredentialPolicy string `json:\u0026amp;quot;credential_policy\u0026amp;quot;` // GracefulCloseMaxWaitDurationMs specifies the maximum waiting time to close conn gracefully GracefulCloseMaxWaitDurationMs int `json:\u0026amp;quot;graceful_close_max_wait_duration_ms\u0026amp;quot;` TLSContext *v2.TLSConfig `json:\u0026amp;quot;tls_context\u0026amp;quot;` } - ConnectionNum：Tunnel Agent 和每个 Tunnel Server 建立的物理连接数量。\n- HostingListener：指定 Agent 建立连接之后托管的 MOSN …","date":1659423600,"description":"本文主要介绍之前新合入 master 分支的「反向通道」的使用场景和设计原理，欢迎大家留言探讨。","dir":"blog/mosn-reverse-channel-explained/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7e5e0314310caad88df4a18ccf8bb436","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-reverse-channel-explained/","publishdate":"2022-08-02T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-reverse-channel-explained/","summary":"文｜郑泽超（GitHub ID：CodingSinger ) 字节跳动高级工程师 热衷于微服务和 ServiceMesh 开源社区 本文 6802 字，阅读 15 分钟 Part.1\u0026ndas","tags":["SOFAStack"],"title":"MOSN 反向通道详解","type":"blog","url":"/sofastack.tech/blog/mosn-reverse-channel-explained/","wordcount":3101},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. bobtthp 提问：\n 请教下 MOSN 转发 HTTP/2 协议，listener filter 和 router match 两个部分要怎么写呀？\n A：就用这个 exmple 就行了。\nhttps://github.com/mosn/mosn/blob/master/configs/mosn_config_dev.json\n「MOSN」：https://github.com/mosn/mosn\n2. 黄大宇 提问：\n Biz 版本更新时，如果不卸载旧版本，安装新版本时会报 webContextPath 冲突异常。比如现在运行 1.0.0，而我要升级到 2.0.0，那么能否先安装 2.0.0，然后再切换，再把 1.0.0 卸载。目前是这一过程出现了 webContextPath 冲突的问题。\n A：有两种解法，一种是让流量走宿主，然后分发给 Biz。另一种是 context path 挂钩版本，调用时带上版本，类似 v1，v2 这样。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n3. 黄润良 提问：\n Cluster Manager 这块配置，如果要实现动态配置，有没有什么最佳实践之类的？MOSN 有开放 API 或者接入配置中心的案例吗？\n A：直接使用 XDS 协议就行了，获取你也可以直接调用 MOSN 的 API，这里有个 ZK 的例子：\nhttps://github.com/mosn/mosn/tree/master/pkg/upstream/servicediscovery/dubbod\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 Go 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\nSOFAServerless 助力业务极速研发\n\nSeata 在蚂蚁国际银行业务落地实践\n\n欢迎扫码关注公众号：\n","date":1659078000,"description":"SOFA Weekly | Meetup 广州站、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220729/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"876d0f78f149dc93f464e53e5474a250","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220729/","publishdate":"2022-07-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220729/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Meetup 广州站、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220729/","wordcount":760},{"author":null,"categories":"SOFAStack","content":" 文｜杨洋（花名：凯申 )\n铜锁开源密码库创始人、蚂蚁集团高级技术专家\n本文 2816 字，阅读 8 分钟\n再见 BabaSSL ，你好 Tongsuo!\n BabaSSL 这个名字由于其历史上的若干特殊原因，导致了其看起来是主要 SSL/TLS 协议的密码学产品，这其实并不符合整个产品的功能特性，名字本身也不够中立，这会让用户产生一定程度的误解。\n目前 BabaSSL 在积极推进向开放原子开源基金会的捐赠行动，并结合社区未来发展的方向，现决定对 BabaSSL 项目进行更名。新名字需要更加中立化，而且需要体现项目的功能特性。基于这些考虑，计划取新名字为：铜锁，对应拉丁字母名称为铜锁的汉语拼音“Tongsuo”。铜锁是在中华文明 5000 年历史的进程中得到了广泛应用的安全设施，且小巧、设计精妙，极具中国传统特色，符合密码库的产品特色和发展目标。\n 一、BabaSSL 从何而来，为何而改？ BabaSSL 于 2019 年诞生在蚂蚁和阿里集团内部，是基于 OpenSSL 1.1.1 版本 fork 而来的一个变种版本。创建 BabaSSL 项目的动机是在蚂蚁和阿里内部得到一个统一的 OpenSSL 变种版本，以便使用此统一版本来支撑蚂蚁和阿里内部的各种业务。这样可以减小各个业务方维护 OpenSSL 的成本，实现密码学能力的统一管理和维护，进而降低潜在的安全风险。\n针对蚂蚁和阿里内部的业务特点，BabaSSL 需要采用和 OpenSSL 完全不同的发展路线。简单来说，BabaSSL 需要覆盖的场景非常的多样化，包括移动端、服务器端、资源受限的嵌入式环境等。而且在算法和密码学特性的支持上，蚂蚁和阿里的业务对前沿的技术存在较大需求，因此要求 BabaSSL 需要采用相对激进的演进策略，但还要确保很高的质量标准以应对蚂蚁和阿里的业务规模。所以我们当年使用 Brisk and Better Assured Cryptography and SSL/TLS toolkit 来命名这个密码学基础库，并缩写为 BabaSSL。\n随着 BabaSSL 项目的发展，我们发现除了蚂蚁和阿里内部的业务对其有着重大的依赖之外，业界也对国密合规和前沿密码学技术存在较大需求。因此在 2020 年 10 月份，我们将 BabaSSL 进行了开源，并维持 BabaSSL 名称不变。随着 BabaSSL 开源社区的发展、用户数量的增多，我们逐渐发现 BabaSSL 这个名称已经无法继续肩负整个社区更大的目标和使命，因此取一个新名字就十分必要。\n二、我的新名字——\u0026amp;rdquo;铜锁/Tongsuo\u0026amp;rdquo; 经过与开源社区小伙伴们共同探讨，并与开放原子开源基金会沟通后，我们最终选定了 “铜锁/Tongsuo” 作为 BabaSSL 开源项目的新名字，其含义如下：\n1. 铜锁的设计形象和密码学的锁形象异曲同工，都是保障安全的技术\n2. 铜锁的历史悠久，应用十分广泛\n3. 铜锁诞生于中国汉代，流行至明清，极具中国特色，代表了中国的传统文化\n4. 铜锁设计精妙、体积小巧，安全性高\n铜锁的这些特点，符合 BabaSSL 的项目定位和发展目标：适应场景最广、性能最好、可靠性最高且监管合规的开源密码学基础库。正如铜锁是中国 5000 年历史长河中为人民生命财产提供保证的最基础元素，“铜锁密码库”作为信息安全领域基础组件、中国网络空间安全和数据安全的核心基础元素，也希望能为中国人民的信息和财产安全贡献力量。\n铜锁的拉丁字母名称则直接采用铜锁的汉语拼音：Tongsuo，除此之外不再赋予其他含义解释，目的是集中体现中国的品牌名称和文化价值。\n三、更名后的一系列操作 我们近期会针对 BabaSSL 开源项目进行如下的更名举措，其中部分举措可能会对用户造成影响，需额外注意：\n「代码库名称变更」\n1. 在 Github 上创建新的 Tongsuo 组织，并将 BabaSSL 代码仓库更名为 Tongsuo 后迁移其下；\n2. BabaSSL 代码仓库的转地址会在 Github 上自动跳转到新的 Tongsuo 仓库地址，方便已有用户访问；\n3. 新的 Tongsuo 代码仓库的 master 分支变更为基于 OpenSSL 3.0 代码基础，并整体迁移为 Apache License 2.0 开源许可证。由此进行相关分支变更如下：\na. 现有的 master 分支更名为 master-babassl，并设置为只读模式，即不再接受新的代码合并，只留做参考用；\nb. 将 master-tongsuo 分支更名为 master，作为下个大版本 tongsuo-8.4.0 的开发分支。由于新的 master 分支和旧的 master 分支之间没有代码提交的逻辑关系，因此需要用户手动重新检出新的master 分支并覆盖本地的旧 master 分支内容。在此过程中如果你的本地 master 分支存在代码修改，请注意保存以免代码修改丢失。\n「网站改名」\n1. 启动 tongsuo.net 网站，并更新网站内容/品牌；\n2. 将对 babassl.cn 网站的访问重定向到 tongsuo.net；\n3. 新增 tongsuo.readthedocs.org 网站，作为铜锁项目的文档库。\n「Release 改名和版本策略」\n1. 在 8.3.x 版本中将沿用 BabaSSL 名称，即 BabaSSL 8.3.1 等后续版本；\n2. 从 8.4.0 开始更名为 Tongsuo。Tongsuo 延续 BabaSSL 的版本编号，不再重新定义编号。主要是考虑软件版本的升级和比较的前后兼容性问题。新的 release 包名称为：tongsuo-a.b.c.tar.gz 或 tongsuo-a.b.c.zip。\n「代码 API 命名修改」\n需要考虑兼容问题，因此 BABASSL_ 开头的 API 还需持续保留，直到 9.0 大版本发布。\n四、期待与你共“铜”成长 经过这一年的努力，铜锁/Tongsuo 开源密码库项目通过了开放原子开源基金会的 TOC 答辩。接下来我们的重心是继续推进铜锁 8.4.0 版本的研发工作，该版本会在半同态加密算法等前沿密码学领域进行相关特性的大力支持，为铜锁的用户带来隐私计算领域的底层密码学原语能力。\n希望能有更多朋友参与进来，与我们共同去完善铜锁/Tongsuo，不论你所处哪一个研究领域，我们都非常期待和欢迎你的加入。此外，我们于近期建立了铜锁 （BabaSSL） 的开源项目钉钉群，方便铜锁密码库的用户们进行沟通交流，期待着能有更多的社区朋友在铜锁 （BabaSSL） 共同成长！\n钉钉用户交流群群号：44810299\n 铜锁（BabaSSL）的更名涉及到较多的现有资产名称变更事宜，例如代码库改名、文档内容名称替换等。具体的相关进展和状态，我们会及时在上述钉钉群中向大家通告。\n 了解更多…\n铜锁/Tongsuo Star 一下✨： https://github.com/BabaSSL/BabaSSL\n本周推荐阅读 BabaSSL：支持半同态加密算法 EC-ElGamal\n\nBabaSSL 发布 8.3.0｜ …","date":1659078000,"description":"再见 BabaSSL ，你好 Tongsuo!","dir":"blog/my-new-name-is-tongsuo/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b06ddb637930e9c54104c4e1f05501d7","permalink":"https://sofastack.github.io/sofastack.tech/blog/my-new-name-is-tongsuo/","publishdate":"2022-07-29T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/my-new-name-is-tongsuo/","summary":"文｜杨洋（花名：凯申 ) 铜锁开源密码库创始人、蚂蚁集团高级技术专家 本文 2816 字，阅读 8 分钟 再见 BabaSSL ，你好 Tongsuo! BabaSSL 这个名字由于其历史上的若干特殊原因，导致","tags":["SOFAStack"],"title":"你好，我的新名字叫“铜锁/Tongsuo”","type":"blog","url":"/sofastack.tech/blog/my-new-name-is-tongsuo/","wordcount":2336},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#29:基于 P2P 的文件和镜像加速系统 Dragonfly\n 活动时间：07 月 28 日，周四晚 19 点\n 活动形式：线上直播\n 直播回放：点击观看\n 资料下载：戳这里\n 推荐阅读：Dragonfly\u0026amp;ndash;基于 P2P 的文件和镜像分发系统\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”等多种形式期待你的参与！\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#29 基于 P2P 的文件和镜像加速系统 Dragonfly Dragonfly 是一款基于 P2P 的智能镜像和文件分发工具。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在应用分发、缓存分发、日志分发和镜像分发等领域被大规模使用。自 17 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 18 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为孵化级别的托管项目。分享主要介绍 Dragonfly 项目，并与大家共同分享开发过程中的设计思想以及最佳实践。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 戚文博（花名：百蓦）\n Dragonfly Maintainer\n 基于 P2P 的文件以及镜像加速系统, 负责 Scheduler 以及 Manager 子模块\n 马金晶（花名：楚贤）\n Dragonfly Maintainer\n 基于 P2P 的文件以及镜像加速系统, 负责 Dfdaemon 子模块\n 议程 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1658818800,"description":"2022 年 7 月 26 日 19：00 - 20：00 ，线上直播第 29 期。","dir":"activities/sofa-channel-29/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d3727242c6f0f12aead78985904e20bb","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-29/","publishdate":"2022-07-26T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-29/","summary":"概要 活动主题：SOFAChannel#29:基于 P2P 的文件和镜像加速系统 Dragonfly 活动时间：07 月 28 日，周四晚 19 点 活动形式：线上直播 直播回放：点击观看","tags":["SOFAChannel","Dragonfly","文件和镜像加速系统"],"title":"SOFAChannel#29 基于 P2P 的文件和镜像加速系统 Dragonfly","type":"activities","url":"/sofastack.tech/activities/sofa-channel-29/","wordcount":623},{"author":null,"categories":"SOFAStack","content":" 文｜李乔（花名：南桥)、李宗杰（花名：白鹰)\n李乔：蚂蚁集团高级开发工程师，负责蚂蚁境外银行支付结算系统开发\n李宗杰：蚂蚁集团技术专家，负责蚂蚁分布式事务中间件研发\n本文 11580 字 阅读 25 分钟\nPART. 1\u0026amp;ndash;背景 蚂蚁国际境外银行业务正在部分迁移至阿里云，原内部使用的 SOFA 技术栈无法在阿里云上得到支持。为了满足银行业务快速发展、简化银行系统技术栈的目标，我们采用了 Spring+Dubbo 等一套开源的技术方案重新构建起了新的技术栈。蚂蚁集团作为金融机构，内部应用采用了微服务架构，数据间的一致性极其重要，但蚂蚁内部原有的分布式事务框架，在阿里云上也无法提供技术支持。\nSeata 是分布式事务解决方案，囊括了阿里集团的 TXC （阿里云版本称为 GTS） 和蚂蚁集团的 TCC/SAGA 等多种模式，是一款经过多年双十一大规模流量验证的金融级分布式事务框架。因此在综合比较各个现有的分布式事务框架之后，我们选择了 Seata。\n本文介绍了蚂蚁集团境外银行技术部在国际站点建设过程中，使用开源的 Seata 1.4.2 版本进行分布式事务管理的详细方案。同时本文也介绍如何在客户端实现对事务悬挂、幂等、空提交以及空回滚等情形的处理方法。\nPART. 2\u0026amp;ndash;调研 Seata 经过四年建设后，已经形成了一个非常庞大的技术体系。但不管其如何演进，Seata 整体保持了架构的稳定性与使用接口的向后兼容性。\n2.1\u0026amp;ndash;Seata 架构 Seata 官网给出了其如下架构图：\n总体由如下角色构成：\n●TC: Transaction Coordinator\n事务协调器：维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n●TM: Transaction Manager\n事务管理器：定义全局事务的范围，提交或者回滚全局事务。\n●RM：Resource Manager\n资源管理器：和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\nTC 与 TM 以及各个 RM 之间使用 netty 框架进行长链接通信，通信协议是在四层 TCP 协议之上自定义的一套二进制双向通信协议，所以 Seata 总体的通信效率非常高。\n2.2\u0026amp;ndash;事务模式 在这套架构之上，Seata 提供了 TCC、AT、SAGA 和 XA 四种事务模式：\nTCC 模式\n参与者需要实现 Prepare/Commit/Rollback 接口，在一阶段实现数据资源的预处理，在二阶段实现提交和回滚逻辑完成两阶段的提交。优点是通过业务逻辑实现数据可见性和隔离性，快速释放本地事务，提高对同一个资源的并发度，缺点是引入了中间数据的预处理过程，增加了业务复杂度。因此 TCC 模式具有很好的性能与隔离性，尤其适合在银行金融场景下同一个账户的并发交易处理。\nAT 模式\n在一阶段时通过解析 SQL，生成二阶段回滚日志：二阶段提交时，删除回滚日志；二阶段回滚时，通过回滚日志来恢复记录到一阶段之前的状态。类似于 TCC 的两阶段，不过二阶段的 Commit/Rollback 由框架自动生成，自动实现了二阶段操作，易用性好于 TCC。但 AT 模式通过全局锁来实现数据的隔离性，因此对于同一个资源的事务处理只能串行操作，所以性能逊于 TCC。当然如果不存在并发使用同一个资源的场景，则 AT 模式可以很好的兼顾性能和隔离性，以及更好的开发效率。\nSAGA 模式\n是一种长事务解决方案，其一阶段正向服务和二阶段补偿服务都由业务开发实现，它在微服务编排领域有大量应用。但其数据隔离性不好，业务数据有被脏写的风险。\nXA 模式\n其使用接口与 AT 模式一致，提供了最严格的隔离性，可以保证了用户不会出现脏读。XA 模式的缺点是其事务范围较长，其性能较低。\n2.3\u0026amp;ndash;小结 Seata 四种模式都是二阶段事务的技术实现。结合 Seata 自身的技术架构，其事务模型总体有如下特点：\nPART. 3\u0026amp;ndash;实践 进行总体技术调研后，我们认为 Seata 的总体技术栈可以满足我们所有金融业务场景的需求。在实施过程中，在不同的业务场景下根据不同的技术需求进行了取舍，我们在发起者本地的交易流水部分使用了 AT 模式，在下游账户相关的服务中使用了 TCC 模式。本章接下来我们将以业务中最经典的账务余额模型为例详述本次实践，包括为了适配相应的事务模型所做的工作。\n3.1\u0026amp;ndash;交易流水使用 AT 模式 为了记录每次的交易流水状态，在发起每笔交易前，我们都要将本次交易流水做记录，交易状态流水简化模型如下：\n在接收到请求时，首先记录初始化状态的交易流水，然后发起分布式事务。本次交易的分布式事务执行成功后，预期该笔交易流水需要是执行成功状态。为了对失败的交易发起重试，我们启动了一个定时任务，定时扫描交易流水状态，扫描到一定时间后未完成的记录需要重新发起重试。\n从上面的场景可以看出，在发起者的交易流水记录的状态变更中，也需要参与到整个分布式事务中。分布式事务成功，则流水状态需要更新为成功，如果分布式事务失败，则需要更新为失败。同时交易流水记录之间是独立的，不存在并发操作的可能，只有异步任务的扫描才会和交易中的事务做抢锁处理。\n针对这个场景，就非常适合使用 AT 模式，无需通过业务代码记录事务执行状态，而是直接在发起者中通过 AT 模式提供的代理数据源执行修改流水状态为“执行成功”状态，由框架自动完成 AT 模式下的一二阶段的提交和回滚，保证交易流水状态和整体分布式事务的状态一致，同时可以保持简洁的代码和更高的开发效率。\n3.2\u0026amp;ndash;账户使用 TCC 模式 从业务原理上来分析，账户的余额是不能凭空增加或者减少的，每个余额变动必须有明细对应。所以账户余额模型应该具备以下几个关键要素：账户 （明确到底是谁的账户）、 余额 （承载的客户资产具体数值）、 账务明细 （记载账户余额变动的数值、时间和原因） 。这三个其实构成了最朴素的账户余额模型。\n根据从业务原理的分析，我们就产生了一个最简单的账户余额基础数据模型：\n账户（ip_account）\n账户模型确定了基本的账户信息：\n●账号：该账号与会员的信息映射在一起，作为会员的余额资产；\n●账户类型：对公 （商户账号） ，对私 （个人账号） ，平台户、营销户、商户待结算账户等类型；\n●余额：记录当前客户资产具体数据的余额；\n●交易状态：控制四种交易方式：流入、流出、充值、提现，这是在账务层做的一个资金安全兜底保障。每一种类型用 T/F 来表示是否可以进行此类交易，T 是可以，F 是不可以 ；\n●核算主体：用于表示当前账号在那个核算主体下面进行核算。\n账户明细（ip_account_log,ip_trans_log）\nip_trans_log 是指账户的交易明细，用于解释为什么这个账户是要发生这笔记账请求。可以理解为业务原始凭证，用于和业务系统数据关联校验。以你用支付宝在便利店买了一瓶矿泉水为例，就是记录的这花 2 元买水的原始信息。\nip_account_log 是指账务明细，用于解释这个账户到底扣减了多少钱，记账的对方账户是谁。仍然以你用支付宝在便利店 …","date":1658818800,"description":"蚂蚁国际境外银行业务正在部分迁移至阿里云，原内部使用的 SOFA 技术栈无法在阿里云上得到支持。为了满足银行业务快速发展、简化银行系统技术栈的目标，我们采用了 Spring+Dubbo 等一套开源的技术方案重新构建起了新的技术栈。","dir":"blog/seata-in-practice-in-ant-international-banking/","fuzzywordcount":9000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8c90a02142b9bb70cfc93d7828e502ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","publishdate":"2022-07-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","summary":"文｜李乔（花名：南桥)、李宗杰（花名：白鹰) 李乔：蚂蚁集团高级开发工程师，负责蚂蚁境外银行支付结算系统开发 李宗杰：蚂蚁集团技术专家，负责蚂蚁","tags":["SOFAStack"],"title":"Seata 在蚂蚁国际银行业务的落地实践","type":"blog","url":"/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","wordcount":8943},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 罗坤 提问：\n 您好，请问一下可以用 SOFATracer 的摘要日志是 result.code 判断交易是否成功来告警么？result.code 有哪些状态？\n A：是可以的，如果是监控，可以用 stat 日志。\n「SOFATracer」： https://github.com/sofastack/sofa-tracer\n2. xiaoyu 提问：\n 咨询一个问题，现在使用 MOSN 作为 Istio 数据面，还是只能使用 Istio 1.10.6 版本吗？\n A：是的，目前支持的这个版本。\n「MOSN」： https://github.com/mosn/mosn\n3. 高岩 提问：\n 请教下， MOSN 官网的集成 Istio 的例子，在 Katacoda 上练习 step 4 的测试 curl productpage 时失败，然后在我本地 Minikube 的环境测试结果也一样，请问下这个 demo 问题怎么排查？\n A：我试了一下，这个 Katacode 上执行 grep 会报错，但是不执行就没问题。\n 好的，我再试一下，感谢。\n A：如果遇到问题，可以看一下 MOSN 的日志。kubectl logs $pod -c istio-proxy 就可以了，还有问题可以建个 issue。\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 Kusion 模型库和工具链的探索实践\n\nSeata 多语言体系建设\n\nGo 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\n欢迎扫码关注：\n","date":1658473200,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220722/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"077f31118a42474e52018a9f6b870b4f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220722/","publishdate":"2022-07-22T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220722/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220722/","wordcount":675},{"author":"梁倍宁","categories":"SOFAStack","content":" 前言 SOFABoot的isle模块为Spring Boot应用提供了上下文隔离的能力以更好的支持模块化开发。借助该能力，可以很好的解决不同模块中的Bean冲突问题，有效的提高了团队协作开发的效率，尽可能的避免因冲突带来的额外时间成本\n SOFABoot的模块隔离能力，也叫做Spring上下文隔离能力，相较于类加载器隔离的实现方式，Spring上下文隔离的实现更为简单。SOFA给每一个模块都提供了一个独立的Spring上下文，这样各模块之间的Bean就无法直接引用，直接引用时通常会出现NoSuchBeanDefinitionException表示当前容器没有指定的Bean，以达到各模块在运行时隔离的效果。\n模块化启动相关类 类名 描述 com.alipay.sofa.isle.stage.PipelineStage 该接口是PipelineContext中一个步骤的描述，SOFA将启动行为抽象成了一条流水线中的各个步骤 com.alipay.sofa.isle.stage.ModelCreatingStage 该类是PipelineStage实现之一，其主要作用是创建模块 com.alipay.sofa.isle.stage.SpringContextInstallStage 该类是PipelineStage实现之一，其主要作用是将SOFA定义的“模块”安装到Spring的上下文中，也是SOFA模块化中最关键的一个步骤 com.alipay.sofa.isle.stage.ModuleLogOutputStage 该类是PipelineStage实现之一，其主要作用只是模块化的相关日志 com.alipay.sofa.isle.spring.SofaModuleContextLifecycle 该类是SOFA模块化核心实现的入口类，实现了SmartLifecycle接口，会在Spring发布ContextRefreshed事件之前调用 主体流程 SofaModuleContextLifecycle SOFABoot的模块化能力主要是基于Spring的Lifecycle来实现的，核心的入口类为com.alipay.sofa.isle.spring.SofaModuleContextLifecycle，该类实现了Spring的org.springframework.context.SmartLifecycle接口，会在ContextRefreshedEvent事件发布之前调用。当Spring的上下文刷新时会触发SOFA模块化的装配流程，其源码如下：\npublic void start() { if (isleRefreshed.compareAndSet(false, true)) { try { pipelineContext.process(); } catch (Throwable t) { SofaLogger.error(ErrorCode.convert(\u0026amp;quot;01-10000\u0026amp;quot;), t); throw new RuntimeException(t); } } } 检查当前状态是否是已经调用，如已调用则直接返回。 如果是Root上下文，则直接调用PipelineContext的process，该调用会顺序执行模块化流水线上的各个步骤ModelCreatingStage、SpringContextInstallStage、ModuleLogOutputStage 接下来我们逐个解析PipelineStage的行为。\nModelCreatingStage 顾名思义模型构造阶段，该阶段会对应用程序构造一个应用模型，用以描述应用的基本属性以及所拥有的模块。ModelCreatingStage的process源码码如下：\nprotected void doProcess() throws Exception { ApplicationRuntimeModel application = new ApplicationRuntimeModel(); application.setAppName(appName); SofaRuntimeManager sofaRuntimeManager = applicationContext .getBean(SofaRuntimeManager.class); application.setSofaRuntimeContext(sofaRuntimeManager.getSofaRuntimeContext()); application.setModuleDeploymentValidator(new DefaultModuleDeploymentValidator()); getAllDeployments(application); applicationContext.getBeanFactory().registerSingleton(SofaBootConstants.APPLICATION, application); } 为应用构造运行时模型ApplicationRuntimeModel\n 为ApplicationRuntimeModel设置应用名，即环境变量中的spring.application.name对应的值\n 为应用模型设置SOFA运行时上下文\n 读取所有的Deployment并装载到ApplicationRuntimeModel中\n 将该ApplicationRuntimeModel注册到应用程序的Root Spring上下文中\n 这里详细说明一下第3步中是如何加载Deployment的，以下是getAllDeployments的代码:\nprotected void getAllDeployments(ApplicationRuntimeModel application) throws IOException, DeploymentException { Enumeration\u0026amp;lt;URL\u0026amp;gt; urls = appClassLoader.getResources(SofaBootConstants.SOFA_MODULE_FILE); if (urls == null || !urls.hasMoreElements()) { return; } while (urls.hasMoreElements()) { URL url = urls.nextElement(); UrlResource urlResource = new UrlResource(url); Properties props = new Properties(); props.load(urlResource.getInputStream()); DeploymentDescriptorConfiguration deploymentDescriptorConfiguration = new DeploymentDescriptorConfiguration( …","date":1658473200,"description":"源码解析｜SOFABoot 上下文隔离机制解析","dir":"projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e980cc3e12470d9a9f803973bb5c1a48","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","publishdate":"2022-07-22T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","summary":"前言 SOFABoot的isle模块为Spring Boot应用提供了上下文隔离的能力以更好的支持模块化开发。借助该能力，可以很好的解决不同模块","tags":["“源码解析”"],"title":"源码解析｜SOFABoot 上下文隔离机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","wordcount":5953},{"author":null,"categories":"SOFAStack","content":" 文｜杨英明（花名：向野)\nKusionStack 核心贡献者、蚂蚁集团高级研发工程师\n在基础设施技术领域深耕，专注 IaC/XaC、GitOps 等方向\n本文 4912 字 阅读 12 分钟\n前言 KusionStack 最早是为了解决蚂蚁内部复杂的运维场景而诞生的解决方案。思路是通过自研的 DSL （KCL） 沉淀运维模型 （Kusion Model） ，将基础设施部分能力的使用方式从白屏转为代码化，同时结合 DevOps 工具链 （Kusion CLI） 实现配置快速验证和生效，以此提升基础设施的开放性和运维效率。\n其中，Kusion Model 就是题中所说的 Kusion 模型库，而 Kusion CLI 就是 Kusion 工具链了。具体概念如下：\nKusion 模型库 Kusion 模型库是基于 KCL 抽象的配置模型。它的特点包括了开箱即用、用户友好、以及业务抽象。其实模型库最初朴素的出发点就是改善 YAML 用户的编写效率和体验，因为目前其实有不少配置是基于 YAML 描述的，比如 Kubernetes 在成为容器编排的事实标准之后，基于 K8s 的声明式配置就越来越多了起来。\n但是由于 K8s 本身的复杂性导致 YAML 配置越来越冗长、复杂。我们希望通过将复杂的配置描述通过 KCL 这门配置语言抽象封装到统一的模型中，从而简化用户侧配置代码的编写。\nKusion 工具链 Kusion 工具链是基于 KCL 的 DevOps 工具集合，它是用来辅助用户在 Kusion 生态里更好的生成、驱动他们的 KCL 配置。\n简单来说，Kusion 模型库是用 KCL 语言沉淀下来的可复用组件，工具链是 Kusion 模型的驱动器。\n本文主要介绍 KusionStack 中 Kusion 模型库和工具链在蚂蚁内部的实践探索和总结，重点阐述了如何利用 KusionStack 提升复杂基础设施的开放性和运维效率，希望对同样面临此类困境的伙伴有所启示。\nPART. 1\u0026amp;ndash;为什么要做 Kusion 模型库和工具链？ 我们可以先来看一张“现象\u0026amp;ndash;问题”图：\n在这张图中，我们列出了一些在内部大规模场景下的实践过程中会遇到的问题。\n举个应用部署的例子，应用 A 有 10+ 组件，内部对于这种非标应用没有提供很好的支持，每次部署需要经历繁多的步骤，比如元数据准备、申请证书、VIP、域名、手动部署 CRD、RBAC、Webhook、监控配置等。这个过程没有自动化，交付部署复杂，定制程度高，其中任何一个步骤出现问题，都需要找对应的研发同学沟通，应用部署的人工成本很高。\n总体来说，当时蚂蚁内部在大规模场景下利用现有基础设施进行运维的困境，主要就是来源于以上列出的这些现象，所以去解决这些现象背后的问题，成了亟待我们去做的事情。\nPART. 2\u0026amp;ndash;困境中的应对思路 经过反复的探讨和一致认同，我们最终摸索出一套解决方案，即通过 Kusion 模型库和工具链，从以下几个方面解决上述复杂基础设施运维困境的问题。\n可读性 面向业务 \u0026amp;amp; 屏蔽底层实现\n我们基于 KCL 抽象了 Kusion 模型库，其中包含一些开箱即用的模型，这些模型针对业务进行了抽象和提炼，面向用户的这层模型界面暴露的都是用户关心的属性，一些实现的细节被屏蔽掉了，所以它是面向业务的，也更容易被用户所接受和上手使用。\n符合工程直觉\nKusion 模型库作为用 KCL 编写的模型集合，更加符合工程直觉。因为 KCL 既然作为一门语言，它支持定义变量，编写条件判断，比如你可以通过 if-else 编写一些差异化的配置。\n解决的问题\n本节介绍的可读性的提升主要分为两个方面。一方面是 KCL 这门 KusionStack 自研的配置语言本身足够强的表达力，使得通过 KCL 描述配置和抽象模型更加丝滑；另一方面，使用 KCL 定义的 Kusion Model 封装了复杂的配置转换逻辑，屏蔽业务细节，抽象出清晰易懂的用户界面。这两方面的带来的可读性的优势可以比较好的解决使用传统配置语言维护困难的问题。\n工程性 前后端模型解耦\n我们对 Kusion 模型库根据功能，区分了前端模型和后端模型。为什么要区分前端模型和后端模型？直接目的是将「用户界面」和「模型实现」进行分离：\n前端模型\n前端模型即「用户界面」。包含平台侧暴露给用户的所有可配置属性，其中省略了一些重复的、可推导的配置，抽象出必要属性暴露给用户。\n用户只需要像实例化一个类 （Class） 一样，传入必要参数构成一份应用的「配置清单」，再经过工具链编译即可得到完整的面向基础设施的配置描述，比如说 K8s 的 YAML；\n后端模型\n后端模型是「模型实现」。后端模型和前端模型不同，是对用户不感知，刚才提到前端模型可以构成用户的配置清单，那么怎么让用户的配置清单生效呢？\n我们将属性的渲染逻辑全部下沉到后端模型中，后端模型中可借助 KCL 编写校验、逻辑判断、代码片段复用等逻辑，提高配置代码复用性和健壮性。\nMixin 复用\nMixin 是 KCL 提供的一种复用代码片段的方式。举个具体的例子，比如说有个模型的属性叫做超卖，开启超卖开关可以将 Pod 调度到可以超卖的机器当中，应用一般在发布线下环境的时候会开启超卖，以充分利用集群的资源。这段超卖配置生效的逻辑可能会被不同的应用运维模型使用，那么就可以借助 Mixin 机制实现一个 OverQuotaMixin，OverQuotaMixin 可以被不同后端模型引用，解决复用性的问题，无需重复造轮子。\nAppConfiguration 沉淀\n我们针对不同应用运维场景或者部署场景抽象为不同的应用运维模型，这些应用运维模型我们叫做 AppConfiguration。\n它们暴露的属性是不一样的，比如适应于标准基础设施的标准应用模型，适应于网络应用的网络应用模型。这些不同的应用运维模型暴露给用户可配置的属性是不同的，这些模型沉淀下来可以描述越来越多场景的应用运维配置，沉淀为在推动配置代码化过程中重要的资产。\n解决的问题\n本节介绍的是团队在建设蚂蚁的 Kusion 模型库过程中形成的一套最佳实践，它是推动建设 Kusion 模型库和工具链的一站式和开放性的基础。\n一站式 全生命周期配置描述 \u0026amp;amp; Single Source of Truth\n我们在完善可读性和工程性的过程中实现了全生命周期配置描述。我们将应用的部署配置、网络配置、监控配置等等和应用生命周期相关的配置尽可能的放到了一个模型中。\n这样做的好处是，将散落在各个系统的配置片段收集到了一起，用户可以在一个统一界面中维护他的应用配置，同时对于第三方系统，也不需要对接不同系统，他只需要运维一份统一的配置即可。\n「全生命周期配置描述」其实在做一件事情，就是业界经常提到的 Single Source of Truth，也就是所谓的“唯一真实来源”。这是实现 IaC 的重要前提之一。\n从下图可以看到，Kusion 模型库中的前后端模型将不同维度的运维能力通过 KCL 模块化，并灵活组织在各种 AppConfiguration 模型中。同时基于 AppConfiguration 实例化出的 …","date":1658214000,"description":"KusionStack 最早是为了解决蚂蚁内部复杂的运维场景而诞生的解决方案。思路是通过自研的 DSL（KCL）沉淀运维模型（Kusion Model），将基础设施部分能力的使用方式从白屏转为代码化，同时结合 DevOps 工具链（Kusion CLI）实现配置快速验证和生效，以此提升基础设施的开放性和运维效率。","dir":"blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e4c34198e41bd1986c646cf6f0ab041b","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","summary":"文｜杨英明（花名：向野) KusionStack 核心贡献者、蚂蚁集团高级研发工程师 在基础设施技术领域深耕，专注 IaC/XaC、GitOps 等方向 本文 4912 字 阅读 12 分钟","tags":["SOFAStack"],"title":"KusionStack 开源｜Kusion 模型库和工具链的探索实践","type":"blog","url":"/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","wordcount":5102},{"author":null,"categories":"SOFAStack","content":" 文｜赵新（花名：于雨 )\n蚂蚁集团可信原生部工程师阿里开源先锋人物、阿里开源大使\n负责蚂蚁可信原生技术部 DB Mesh 系统开发，以及容器和分布式事务开源工作\n本文 3846 字，阅读 10 分钟\n｜引语｜ 分布式事务是微服务技术体系中非常关键的的一个技术节点，当下最流行且经过大规模生产验证的高质量分布式事务实现无疑是 Seata。Seata 社区过去四年长期专注于 Java 语言实现，在 Java 领域是事实上的分布式事务技术标准平台。\n在诸如 gRPC 等微服务体系都在进行多语言建设的当下，分布式事务也应该有多种语言支持。所以在规划 2022 年 Seata Roadmap 时，其中一个非常的关键点就是 Seata 的多语言技术体系建设。在经过半年的准备特别是完成了 Seata v1.5.2 发版后，社区在今年 （2022年） 下半年的重点任务就是全力建设 Seata 的多语言实现。\nPART. 1\u0026amp;ndash;关键技术点 Seata Java 版本经过四年建设后，已经形成了一个非常庞大的技术体系。在进行多语言建设时，想要在半年内让多语言版本 Seata 的功能与 Seata Java 完全对齐，是不可能的。社区需要综合考量当下的实际迫切需求以及未来的发展方向，先找出 Seata 多语言版本的关键技术点。\n1. 事务模式 Seata 提供了 TCC、SAGA、AT 和 XA 四种经典事务模式。下图是四种模式的发布时间。\n各种模式有其各样的特点：\nAT 模式\n算是阿里体系独创的事务模式，其本质属于两阶段事务，其二阶段的 commit/rollback 由框架自动生成，对业务没有侵入，用户友好度高于 TCC 模式，可完美接续 Spring 事务，开发效率也较高，也是当前用户最多的一种模式。在 v1.5.2 已经发版的当下时间节点来看，AT 模式下通过全局锁来实现数据的隔离性，对于同一个资源的事务处理只能串行操作，性能一般。\nTCC 模式\n需要业务层参与者实现 prepare/commit/rollback 接口，其性能在四种模式下最好，数据可见性、隔离性也不错，流行程度仅次于 AT。特别适用于对吞吐、性能、隔离性要求都比较高的金融业务。\nSAGA 模式\n是一种长事务解决方案，其一阶段正向服务和二阶段补偿服务都由业务开发实现，可以很方便地与微服务框架进行结合，其性能仅次于 TCC 模式。因为其方便编排的特点，它在微服务编排领域有大量应用，当然使用时需要用户写 JSON 文件对服务进行编排。但其数据隔离性不好，业务数据有被脏写的风险。社区目前正在进行 SAGA 注解化工作（https://github.com/seata/seata/pull/4577），可进一步提升其性能与易用性。\nXA 模式\n不同于其他三种「补偿型」事务，它提供了最严格的隔离性：可以保证全局视角的数据一致性，即保证了用户不会出现脏读。Seata XA 模式的接口与 AT 模式基本一致，算是对用户比较友好的一种事务模式，它是对 XA 协议的严格实现。XA 模式的缺点是其事务范围比较长，其性能最低。\n四种模式的发版顺序如下：\n每种事务模式在阿里体系内都有各自的业务场景，其出现与演进都是迎合了各自业务场景现有的痛点。AT 和 XA 是不需要理解业务语义的，作用于 DB driver + DB 层面，TCC 和 SAGA 则需要业务层面自实现回滚幂等类逻辑，按照数据面和业务面来切分，依据对业务的入侵程度，四种模式归类如下图。\n分布式事务的基石是通信框架、SQL 解析以及数据库连接驱动实现等。得益于 Java 语言丰富的生态，Seata Java 版本可以很方便地站在这些 “巨人” 肩上展开相应的工作，这也是其他语言无法望其项背的。例如，主流数据库都提供了其 Java 版本的 DB driver。但当把工作背景放到多语言场景下时，就需要考量各个语言相关技术点的实现程度了。\n四种事务模式，AT 模式本质是应用层的事务，需要把数据库层面做过的 Redo/Undo 在应用层再做一遍，其中非常关键的一个技术点是：AT 模式需要介入数据源做 SQL 拦截，对 SQL 进行解析。单单考量 SQL 解析这个单技术点，Java 和 Python 语言有 antlr，Go 语言有 TiDB 提供的可自由使用的 pingcap/parser，但目前很多其他语言在这块都是空白的。\n所以社区在考量现实情况后，除了 Go 和 Python 版本，在进行多语言版本建设时，没有 SQL 解析包的语言版本先不提供 AT 模式的实现。\n2. 通信协议 不论哪种事务模式，都构建在 Seata 独有的架构之上。\n图片来自 seata 官网\nSeata 总体架构由如下角色构成：\n事务协调器 Transaction Coordinator\n简称 TC，维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n事务管理器 Transaction Manager\n简称 TM，定义全局事务的范围，提交或者回滚全局事务。\n资源管理器 Resource Manager\n简称 RM，和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\nTC 与 TM 以及各个 RM 之间使用 netty 框架进行长链接通信。具体而言，Seata Java 版本的通信协议是在四层 TCP 协议之上又定义了一套私有的二进制双向通信协议。其关键点在于 Seata Java 版本站在了 netty 这个巨人肩上。\n回到多语言这个背景下，很多语言并没有提供一套成熟的 TCP 通信框架。譬如 Dubbo 在建设其 Go 版本 dubbo-go 时，为了在 TCP 之上实现与 Dubbo 的私有二进制协议通信，本人前期的工作重点是先实现 TCP 通信框架 getty（https://github.com/apache/dubbo-getty），然后再实现其序列化协议 dubbo-go-hessian2（https://github.com/apache/dubbo-go-hessian2）。如果把语言切换成 JS、PHP 或者 Python，相关通信协议建设需要耗费社区大量精力。\nSeata 2019 年就在 API 层适配了 gRPC 的事务上下文传递，为了方便 Seata 多语言版本的建设，Seata Java 框架本身正在进行一项重要工作：Seata Client （包括 TM 和 RM） 基于 gRPC 与 Seata Server （TC） 集群进行通信。希望借助于 gRPC 的多语言优势，节省多语言版本在通信层面的工作量。\n3. 配置和注册中心 类似于其他微服务框架，Seata 自身除了上一节提到的内部组件外，还依赖于注册中心和配置中心。微服务上层的应用通过配置中心找到注册中心，再通过注册中心发现 Seata 的各个服务组件。一个典型的完备的 Seata 服务架构如下图。\nSeata Java 这套架构可以很方便的嵌入注入 Dubbo、SOFARPC 以及 Spring 等 Java 微服务框架中。其中两种非常重要的外部依赖组件是：\nConfig …","date":1658214000,"description":"在诸如 gRPC 等微服务体系都在进行多语言建设的当下，分布式事务也应该有多种语言支持。所以在规划 2022 年 Seata Roadmap 时，其中一个非常的关键点就是 Seata 的多语言技术体系建设。在经过半年的准备特别是完成了 Seata v1.5.2 发版后，社区在今年 （2022 年） 下半年的重点任务就是全力建设 Seata 的多语言实现。","dir":"blog/seata-multi-programming-language-system-construction/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"60da96ebbdbc644758f505352c5e2d13","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-multi-programming-language-system-construction/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/seata-multi-programming-language-system-construction/","summary":"文｜赵新（花名：于雨 ) 蚂蚁集团可信原生部工程师阿里开源先锋人物、阿里开源大使 负责蚂蚁可信原生技术部 DB Mesh 系统开发，以及容器和分布式事务开源工作","tags":["SOFAStack"],"title":"Seata 多语言体系建设","type":"blog","url":"/sofastack.tech/blog/seata-multi-programming-language-system-construction/","wordcount":4266},{"author":"林楠","categories":"SOFAStack","content":" 前言 SOFABoot 提供两种服务通信能力，一种是 JVM 服务，用于同一应用内不同模块间的通信，一种是 RPC 服务，用于不同应用间的通信。SOFABoot 提供三种方式实现服务的发布和引用，分别是XML 配置文件、注解和 API 的方式，本文从源码角度解析从服务的发布和引用到组件协议 binding 机制的实现原理。\n服务发布与引用 在了解组件协议 binding 机制之前，我们先简单了解一下服务的发布与引用的源码。\nXML 通过 XML 方式发布或引用服务时，使用 sofa:service 发布服务，使用 sofa:reference 引用服务，示例代码如下：\n\u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleJvmService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.isle.sample.SampleJvmService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; \u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleJvmService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.isle.sample.SampleJvmService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 我们可以看到在 xml 中使用 xmlns:sofa，将 sofa 前缀的命名空间定义为 http://sofastack.io/schema/sofaboot ，Spring 在解析 sofa:* 标签时会与该命名空间相关联。对于 xml 的解析，SOFABoot 在 sofa-boot 模块中使用 spring.handlers 配置文件中注册了 sofa 命名空间的 XML 处理器。\nhttp\\://sofastack.io/schema/sofaboot=com.alipay.sofa.boot.spring.namespace.handler.SofaBootNamespaceHandler SofaBootNamespaceHandler 在初始化阶段，基于 SPI 机制查找所有标签解析器，调用 registerTagParser 方法注册标签解析器。\npublic void init() { ServiceLoader\u0026amp;lt;SofaBootTagNameSupport\u0026amp;gt; serviceLoaderSofaBoot = ServiceLoader.load(SofaBootTagNameSupport.class); serviceLoaderSofaBoot.forEach(this::registerTagParser); } 注册标签解析器时，调用解析器的 supportTagName 方法获取标签名，将解析器与标签名关联起来。\nprivate void registerTagParser(SofaBootTagNameSupport tagNameSupport) { if (tagNameSupport instanceof BeanDefinitionParser) { registerBeanDefinitionParser(tagNameSupport.supportTagName(), (BeanDefinitionParser) tagNameSupport); } else if (tagNameSupport instanceof BeanDefinitionDecorator) { registerBeanDefinitionDecoratorForAttribute(tagNameSupport.supportTagName(), (BeanDefinitionDecorator) tagNameSupport); } else { ... } } sofa:service 标签的解析器是 ServiceDefinitionParser，使用 doParseInternal 方法读取 xml 标签属性值，并解析为 bean 定义，根据 getBeanClass 定义的类型，将 sofa:service 标签定义的服务转换为 ServiceFactoryBean，并注册到 Spring 上下文中。\npublic class ServiceDefinitionParser extends AbstractContractDefinitionParser { ... @Override protected void doParseInternal(Element element, ParserContext parserContext, BeanDefinitionBuilder builder) { String ref = element.getAttribute(REF); builder.addPropertyReference(REF, ref); if (element.hasAttribute(\u0026amp;quot;id\u0026amp;quot;)) { String id = element.getAttribute(\u0026amp;quot;id\u0026amp;quot;); builder.addPropertyValue(BEAN_ID, id); } else { builder.addPropertyValue(BEAN_ID, ref); } } @Override protected Class getBeanClass(Element element) { return ServiceFactoryBean.class; } @Override public String supportTagName() { return \u0026amp;quot;service\u0026amp;quot;; } } 根据 Spring 的机制，在注册 bean 时，对 bean 的属性赋值后会调用 bean …","date":1658214000,"description":"源码解析 | SOFABoot 组件协议 binding 机制解析","dir":"projects/sofa-boot/sofaboot-component-protocol-binding/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"acfba7d02af62462b2f1c32fb39c9265","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","summary":"前言 SOFABoot 提供两种服务通信能力，一种是 JVM 服务，用于同一应用内不同模块间的通信，一种是 RPC 服务，用于不同应用间的通信。SOFABoot 提供三种方式实","tags":["“源码解析”"],"title":"源码解析：SOFABoot 组件协议 binding 机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","wordcount":5465},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展\n欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 清源 提问：\n 咨询个问题，MOSN 能做协议转换吗？类似于 API 网关那种功能，像 HTTP 调 Dubbo 的服务。\n A：可以的哈，这里是一个 HTTP 到 SOFA 的例子，\nhttps://github.com/mosn/mosn/tree/master/pkg/filter/stream/transcoder/http2bolt\n 我看了下，例子中并没有对 buf 做编解码，是 Bolt 自动识别 HTTP 的报文吗？\n A：这个 filter 就是把 HTTP 的字段转换为 Bolt 的哟，这还有个 Spring Cloud 到 Dubbo 的转换，MOSN 已经对 buf 解码好了，暴露给你的是 HTTP 解码之后的 header 和 body，\nhttps://www.github.com/mosn/extensions/tree/master/go-plugin%2Fplugins%2Ftranscoders%2Fspringcloud2dubbo%2Fmain\n「MOSN」：\nhttps://github.com/mosn/mosn\n2. 国奇 提问：\n 你好，请问有能用的 SOFARegistry 安装步骤吗？\n A：用 start_dev 启动 integrate 模式，registry-run.sh 是给其他脚本调用的：\n也可以参考下面这个文档，fatjar docker 的部署模式都可以：\n*https://www.sofastack.tech/projects/sofa-registry/deployment/***\n「SOFARegistry」：\nhttps://github.com/sofastack/sofa-registry\n3. 国奇 提问：\n 你好，发现一个问题，比如 A 应用 1.0 升级到 2.0 得改 webContextPath 才可以。也就是说要升级版本，要改版本号，还需要改 webContextPath 对吧？\n A：按这里文章介绍的，不引入 web-ark-plugin 的话，就用不同的端口来部署多个 web 服务。你们可以保留这个使用方式，就不需要改 webContextPath，\nhttps://github.com/WuHang1/sofa-ark/blob/code_analyse_multi_web_deploy/doc/CODE_ANALYSE_MULTI_WEB.md\n 发布就会更改不同的端口号，否则端口号被占用。可不可以，我自己不用改端口号，也不用改 webContextPath？\n A：目前不可以，你可以看下之前介绍 SOFAArk Web 插件的文档，里面介绍了必须要改这两个中的其中一个。如果有方案能做到这点那是挺好的，可以提个 proposal。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 Go 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\n社区文章｜MOSN 构建 Subset 优化思路分享\n\nNydus —— 下一代容器镜像的探索实践\n\n欢迎关注：\n","date":1657868400,"description":"SOFA Weekly | 开源人—牛学蔚、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220715/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f60972f54e7daee19a80b6022c644290","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220715/","publishdate":"2022-07-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220715/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展 欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人—牛学蔚、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220715/","wordcount":912},{"author":null,"categories":"SOFAStack","content":" 文｜丁飞（花名：路德 )\n蚂蚁集团高级工程师\n深耕于 SOFAMesh 产品的商业化落地\n主要方向为基于服务网格技术的系统架构升级方案设计与落地\n本文 4394 字 阅读 10 分钟\n｜前言｜ MOSN 作为蚂蚁集团在 ServiceMesh 解决方案中的数据面组件，从设计之初就考虑到了第三方的扩展开发需求。目前，MOSN 支持通过 gRPC、WASM、以及 Go 原生插件三种机制对其进行扩展。\n我在主导设计和落地基于 Go 原生插件机制的扩展能力时遇到了很多问题，鉴于这方面的相关资料很少，因而就有了这个想法来做一个非常粗浅的总结，希望能对大家有所帮助。\n注：本文只说问题和解决方案，不读代码，文章最后会给出核心源码的 checklist。\nPART. 1\u0026amp;ndash;文章技术背景 一、运行时 通常而言，在计算机编程语言领域，“运行时”的概念和一些需要使用到 VM 的语言相关。程序的运行由两个部分组成：目标代码和“虚拟机”。比如最为典型的 JAVA，即 Java Class + JRE。\n对于一些看似不需要“虚拟机”的编程语言，就不太会有“运行时”的概念，程序的运行只需要一个部分，即目标代码。但事实上，即使是 C/C++，也有“运行时”，即它所运行平台的 OS/Lib。\nGo 也是一样，因为运行 Go 程序不需要前置部署类似于 JRE 的“运行时”，所以它看起来似乎跟“虚拟机”或者“运行时”没啥关系。但事实上，Go 语言的“运行时”被编译器编译成了二进制目标代码的一部分。\n图 1-1. Java 程序、runtime 和 OS 关系\n图 1-2. C/C++ 程序、runtime 和 OS 关系\n图 1-3. Go 程序、runtime 和 OS 关系\n二、Go 原生插件机制 作为一个看起来更贴近 C/C++ 技术栈的 Go 语言来说，支持类似动态链接库的扩展一直是社区中较为强烈的诉求。\n如图 1-5，Go 在标准库中专门提供了一个 plugin 包，作为插件的语言级编程界面，src/plugin 包的本质是使用 cgo 机制调用 unix 的标准接口：dlopen() 和 dlsym() 。因此，它给 C/C++ 背景的程序员一种“这题我会”的错觉。\n图 1-4. C/C++ 程序加载动态链接库\n图 1-5. Go 程序加载动态链接库\nPART. 2\u0026amp;ndash;典型问题解决 很遗憾，与 C/C++ 技术栈相比，Go 的插件的产出物虽然也是一个动态链接库文件，但它对于插件的开发、使用有一系列很复杂的内置约束。更令人头大的是，Go 语言不但没有对这些约束进行系统性的介绍，甚至写了一些比较差的设计和实现，导致插件相关问题的排错非常反人类。\n本章节重点跟大家一起看下，在开发、使用 Go 插件，主要是编译、加载插件的时候，最常见、但必须定位到 Go 标准库 （主要包括编译器、链接器、打包器和运行时部分） 源码才能完全弄明白的几个问题，及对应的解决方法。\n简而言之，Go 的主程序在加载 plugin 时，会在“runtime”里对两者进行一堆约束检查，包括但不限于：\n- go version 一致\n- go path 一致\n- go dependency 的交集一致\n 代码一致 path 一致 - go build 某些 flag 一致\n一、不一致的标准库版本 主程序加载插件时报错：\nplugin was built with a different version of package runtime/internal/sys\n从这个报错的文本可以得知，具体有问题的库是 runtime/internal/sys ，很显然这是一个 go 的内置标准库。看到这里，你可能会有很大的疑惑：我明明用的是同一个本地环境编译主程序和插件，为什么报标准库不是一个版本？\n答案是，Go 的 error 日志描述不准确。而这个报错出现的根本原因可以归结为：主程序和插件的某些关键编译 flag 不一致，跟“版本”没啥关系。\n比如，你使用下面的命令编译插件：\nGO111MODULE=on go build \u0026amp;ndash;buildmode=plugin -mod readonly -o ./codec.so ./codec.go\n但是你使用 goland 的 debug 模式调试主程序，此时，goland 会帮你把 go build 命令按下面的例子组装好：\n注意，goland 组装的编译命令里包含关键的 -gcflags all=-N -l 参数，但是插件编译的命令里没有。此时，你在尝试拉起插件时就会得到一个有关 runtime/internal/sys 的报错。\n图 2-1. 编译 flag 不一致导致的加载失败\n解决这一类标准库版本不一致问题的方案比较简单：尽可能对齐主程序和插件编译的 flag。事实上，有一些 flag 是不影响插件加载的，你可以在具体的实践中慢慢摸索。\n二、不一致的第三方库版本 如果使用 vendor 来管理 Go 的依赖库，那么当解决上一节的问题之后，你 100% 会立即遇到以下这个报错：\nplugin was built with a different version of package xxxxxxxx\n其中，xxxxxxxx 指的是某一个具体的三方库，比如 github.com/stretchr/testify。这个报错有几个非常典型的原因，如果没有相关的排查经验，其中几个可能会烧掉开发人员不少时间。\nCase 1. 版本不一致\n如报错所示，似乎原因很明确，即主程序和插件所共同依赖的某个第三方库版本不一致，报错中会明确告诉你哪一个库有问题。此时，你可以对比排查主程序和插件的 go.mod 文件，分别找到问题库的版本，看看他们是否一致。如果这时候你发现主程和插件确实有 commitid 或 tag 的不一致问题，那解决的方法也很简单：对齐它们。\n但是在很多场景下，你只会用到三方库的一部分：如一个 package，或者只是引了某些 interface。这一部分的代码在不同的版本里可能根本就没有变更，但其他没用到的代码的变更，同样会导致整个三方库版本的变更，进而导致你成为那个“版本不一致”的无辜受害者。\n而且，此时你可能立即会遇到另一个问题：以谁为基准对齐？主程序？还是插件？\n从常理上来说，以主程序为基线进行对齐是一个比较好的策略，毕竟插件是新添加的“附属品”，且主程序与插件通常是“一对多”的关系。但是，如果插件的三方库依赖因为任何原因就是不能和主程序对齐怎么办？在尝试了很久以后，我暂时没有找到一个完美解决这个问题的办法。\n如果版本无法对齐，就只能从根本上放弃走插件这条路。\nGo 语言的这种对三方库的、几乎无脑的强一致性约束，从一方面来说，避免了运行时因为版本不一致带来的潜在问题；从另一方面来说，这种刻意不给程序员灵活度的设计，对插件化、定制化、扩展化开发非常的不友好。\n图 2-2. 共同依赖的三方库版本不一致导致的加载失败\nCase 2. 版本号一致，代码不一致\n当你按照 case 1 的思路排查 go.mod 文件，但是惊讶的发现报错的库版本是一致的时候，事情就会变得复杂起来。你可 …","date":1657609200,"description":"作者在主导设计和落地基于 Go 原生插件机制的扩展能力时遇到了很多问题，鉴于这方面的相关资料很少，因而就有了这个想法来做一个非常粗浅的总结，希望能对大家有所帮助。","dir":"blog/go-native-plug-in-use-problem-full-analysis/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"734cc212a753d53c15717c92d859d34c","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","publishdate":"2022-07-12T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","summary":"文｜丁飞（花名：路德 ) 蚂蚁集团高级工程师 深耕于 SOFAMesh 产品的商业化落地 主要方向为基于服务网格技术的系统架构升级方案设计与落地 本文 4394 字 阅读 10 分钟 ｜前","tags":["SOFAStack"],"title":"Go 原生插件使用问题全解析","type":"blog","url":"/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","wordcount":4545},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 何烨 提问：\n 请问一下这个配置现在支持 Nacos 了吗？\n A：SOFABoot 已经支持 Nacos 了。\n「SOFABoot」： https://github.com/sofastack/sofa-boot\n2. 鲍之知 提问：\n 下图中这个 SOFATracer 日志默认是生成在哪里呀？\n A：~/logs。\n「SOFATracer」： https://github.com/sofastack/sofa-tracer\n3. Philip Guan 提问：\n 请问 biz 可以独立引入 master biz 中没有的依赖吗？例如 Hutool、master biz 没有，希望在 biz 里使用。\n A：可以的，打包完后可以 check 一下是否 /biz/ 里有这个包。如果没有的话，可以在 master biz 里引入这个依赖，在 biz 里引入但设置 为 provided 也可以使用。\n 期望是 master biz 不引入 Hutool 的情况下，在 biz 里使用 Hutool。\n A：可以的。\n「SOFAArk」： https://github.com/sofastack/sofa-ark\n本周推荐阅读 KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境 \n GLCC｜Kata Containers、Nydus、Layotto、KusionStack 中选名单公示！ \n SOFARegistry 源码｜数据同步模块解析 \n 社区文章｜MOSN 构建 Subset 优化思路分享 \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1657263600,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220708/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"897429d0434f7577dd9a8efd3b70056f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220708/","publishdate":"2022-07-08T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220708/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220708/","wordcount":661},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@魏顺利 提问：\n runtime-sofa-boot-starter 和 rpc-sofa-boot-starter 区别是什么？\n A：runtime-sofa-boot-starter 是 SOFA 的核心能力 starter，rpc-sofa-boot-starter 是 SOFARPC 能力的 starter。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n2.@寒鸦少年 提问：\n 请问 Plugin 是一个微服务的概念吗，是否提供 HTTP 接口呢？\n A：Plugin 自己管理的依赖，通过 ark 中提到的 导出机制，将其自己管理的类能够暴露给 biz 使用 （多 biz 可以共享某个 plugin 导出的类） ；plugin 和 biz 之间更多说的是类加载的委托关系，biz 之间是通信。\n 那 biz 的 class loader 的加载逻辑应该很复杂吧，因为它要区分什么类自己加载，什么类委托 plugin 加载。\n A：可以看下这个，https://www.sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/\n「SOFAArk」https://github.com/sofastack/sofa-ark\n本周推荐阅读 社区文章｜MOSN 构建 Subset 优化思路分享 \n SOFA 星球”闯关计划 2.0——Layotto 飞船焕新出发 \n Nydus —— 下一代容器镜像的探索实践 \n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1656054000,"description":"SOFA Weekly | 开源人-于雨、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220624/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bc4cc62919a28554b99dc8a812b88dcc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220624/","publishdate":"2022-06-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220624/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人-于雨、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220624/","wordcount":813},{"author":null,"categories":"SOFAStack","content":" 文｜李旭东（花名：向旭 )\n蚂蚁集团技术专家\n蚂蚁中间件研发，专注于 SOFARegistry 及其周边基础设施的开发与优化\n本文 2098 字 阅读 8 分钟\n｜前言｜ MOSN 使用了 Subset 算法作为其标签匹配路由负载均衡的方式。本文主要介绍 Subset 的原理，包括了在超大规模集群下 MOSN 的 Subset 所遇到的一些性能瓶颈与采用的优化算法。\n首先，为什么要优化 Subset 呢？\n总体而言，性能瓶颈往往会由于集群规模的增大逐渐暴露出来。在蚂蚁的超大规模的集群上，注册中心推送地址列表会对应用造成一定的开销。\n在我所参与过的某一次大规模压测中，核心应用的机器数目非常庞大，当进行发布或者运维的时候，它的地址列表会被推送给所有调用它的应用。\n而 MOSN 会接收这份地址列表重新构建自己的路由。当地址列表非常庞大的时候，MOSN 更新 cluster 的性能瓶颈逐渐地暴露出来，出现了较高的 CPU 毛刺，内存在短时间内出现了上涨，gc 频率也大幅度增加。\n通过下方的火焰图，我们可以看到这次压测期间对某应用的 MOSN 的 pprof：\n- Alloc：\n- CPU：\n从 pprof 可以看到，无论是 CPU 还是 alloc 的开销， 构建 SubsetLoadBalancer 都明显占了大头，所以优化这部分的构建是亟待去做的一件事。\n最终通过探索优化，我们可以减少 SubsetLoadBalancer 构建过程中 95% 的 CPU 开销和 75% 的 alloc 开销。\n下面让我们一起回顾下本次优化的过程与思路。\nPART. 1\u0026amp;ndash;Subset 基本原理介绍 在一个集群里，通常机器会有不同的标签，那么如何将一个请求路由到指定标签的一组机器呢？\nMOSN 的做法是把一个服务下的机器按照机标签组合进行预先分组，形成多个子集。在请求的时候，根据请求中的 metadata 信息可以快速查询到这个请求对应应该匹配到的子集。\n如下图所示，可以看到当前有 4 个节点：\n标签匹配规则会根据 zone 、mosn_aig 、mosn_version 这 3 个字段进行匹配路由，根据这 3 个 key 的排序进行组合得到以下匹配路径：\n相对应的匹配树如下：\n假设需要访问 {zone: zone1, mosn_aig: aig1}，那么经过排序后查找顺序为 mosn_aig:aig1 -\u0026amp;gt; zone:zone1，查找到 [h1, h2]。\n以上就是 Subset 的基本原理介绍。\nPART. 2\u0026amp;ndash;MOSN 对 Subset 的构建 首先需要输入的参数有两个：\n- 带标签的机器列表 hosts，比如 [h1, h2, h3, h4]；\n- 用于匹配的 subSetKeys, 如下图：\n接着我们先带上思路，然后阅读源码来看一下 MOSN 的 SubsetLoadBalancer 是如何构建这棵树的。\n核心思路如下：\n- 遍历每一个 host 的 labels 和 subSetKeys 递归去创建一棵树；\n- 对于树的每一个节点，都会遍历一次 hosts 列表，过滤出匹配这个节点的 kvs 的 subHosts，每个节点创建一个子 load balancer。\n我们来看源码图：\n整体的构建复杂度是 O *(M*NK) (M: Subset 树节点个数，N: Hosts 个数, K: 匹配的 Keys）\nPART. 3\u0026amp;ndash;构建性能瓶颈分析 通过对生产的 profile 分析，我们发现 SubsetLoadBalancer 的 createSubsets 在 CPU 和 alloc 的火焰图中的占比都较高。所以下面我们开始编写 benchmark，来优化这一部分的性能。\n我们的输入参数为：\n- subSetKeys：\n- 8000 个 hosts （每个 hosts 都有 4 个 label, 每个 label 对应 3 种 value） ：\n接着，我们来看 CPU 和 alloc_space 的占用情况。\n- CPU：\n- alloc_space：\n从上面两张火焰图中，我们可以看出 HostMatches 和 setFinalHost 占用了较多的 CPU_time 和 alloc_space。我们首先来看下 HostMatches：\n它的作用是判断一个 host 是不是完全匹配给定的键值对，且判断这个 host 是否匹配这个匹配树节点。\n它的开销主要在于执行次数过多：treeNodes * len(hosts) ，所以在集群变大时，这边的运行开销会大幅度上升。\n然后我们再来看一下 setFinalHost：\n他的主要逻辑是按 IP 进行去重，同时会附带 copy。如果我们在 SubsetLoadBalancer 的顶层进行去重，那么它的任意 Subset 都不需要再次去重。因此，这边可以把它改成不去重。\nPART. 4\u0026amp;ndash;倒排索引优化构建 在 HostMatches 的这么多次匹配中，实际上有很多的重复操作，比如对 host label 中某个 kv 判断 equals，在构建过程中重复的次数相当之多。\n所以优化的思路可以基于避免这部分重复的开销，从预先构建倒排索引出发。具体步骤展开如下：\n1. 输入两项参数:\n- subSetKeys：\n- hosts：\n2. 遍历一次 hosts，针对每个 kv 我们用 bitmap 构建倒排索引：\n3. 根据 subSetKeys 和倒排索引中的 kvs，构建出匹配树，因为索引中是去重的与 hosts 数目无关，这个操作开销占比很低；\n4. 对于树的每个节点，利用倒排索引中的 bitmap 做交集快速得到匹配全部 kv 的 hosts 的索引 bitmap；\n5. 使用 bitmap 中存储的 index 从 hosts 中取出对应 subHosts 构建子 load balancer，同时注意此处不需要使用 setFinalHosts 进行去重。\n基于上述思路过程开发新的 Subset preIndex 构建算法，可以在 MOSN 的对应 Pull Request 页面查看详情：\nhttps://github.com/mosn/mosn/pull/2010\n再分享下添加 benchmark 进行测试的地址：\nhttps://github.com/mosn/mosn/blob/b0da8a69137cea3a60cdc6dfc0784d29c4c2e25a/pkg/upstream/cluster/subset_loadbalancer_test.go#L891\n可以看到相对之前的构建方式，构建速度快了 20 倍，alloc_space 减小了 75% 。同时，alloc 次数出现了少量的上升，这是因为需要额外的构建一次倒排索引所致。\n下面观察一下 gc：\n我们可以发现，相较于之前的构建方式，运行期间的内存更小了，而且 CPU 回收的内存也变少了，同时 gc 并行扫描的时长小幅上涨，STW 时间变的更短。\n最后，测试一下在不同 hosts 数目下的优化程度，可以看到在 hosts …","date":1655708400,"description":"MOSN 使用了 Subset 算法作为其标签匹配路由负载均衡的方式。本文主要介绍 Subset 的原理，包括了在超大规模集群下 MOSN 的 Subset 所遇到的一些性能瓶颈与采用的优化算法。","dir":"blog/build-subset-optimization/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d1475506aa7ef2b35d302df89924b72d","permalink":"https://sofastack.github.io/sofastack.tech/blog/build-subset-optimization/","publishdate":"2022-06-20T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/build-subset-optimization/","summary":"文｜李旭东（花名：向旭 ) 蚂蚁集团技术专家 蚂蚁中间件研发，专注于 SOFARegistry 及其周边基础设施的开发与优化 本文 2098 字 阅读 8 分钟 ｜前言｜ MOSN 使用了 Subset 算法作为其标","tags":["SOFAStack"],"title":"社区文章｜MOSN 构建 Subset 优化思路分享","type":"blog","url":"/sofastack.tech/blog/build-subset-optimization/","wordcount":2243},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@魏顺利 提问：\n 生成的 ark-biz.jar 这个怎么打到 maven 仓库？\n A：加上true配置然后 mvn install/deploy，参考：\nhttps://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.@寒鸦少年 提问：\n 请教个问题，SOFAStack 商业版里面，SOFABoot 在集成中间件的时候，中间件的客户端咱这边有自己封装的版本，还是纯走开源的那些客户端比如 Jedis 之类的。\n A：SOFAStack 有些中间件会有自己的封装，也会有独立的客户端。\n 可以给个列表么，具体有哪些独立的客户端和开源版本的升级点对比之类的？\n A：可以看下这个：\n「SOFABoot」https://github.com/sofastack/sofa-boot\n本周推荐阅读 「开源之夏」SOFASTack \u0026amp;amp; MOSN 社区项目中选结果 \n SOFA 星球”闯关计划 2.0——Layotto 飞船焕新出发 \n Nydus —— 下一代容器镜像的探索实践 \n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1655449200,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220617/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3d55fba6e2019654f9dccb079b67ba5d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220617/","publishdate":"2022-06-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220617/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220617/","wordcount":699},{"author":"吴航","categories":"SOFAStack","content":" 背景 原生springboot-web应用部署流程 两种合并部署模式 支持单Host合并部署的关键点 多Biz共用tomcat实例 多Biz接口区分 总结 背景 SOFAArk基于java类加载机制，为我们提供了一种java进程内多模块隔离的方案。每个业务模块——Ark Biz，都是一个完整的springboot项目，可独立运行；也可作为一个maven依赖或远程jar包，引入被称为Master Biz的基座Biz，随着Master Biz的启动合并部署运行，并由专属的BizClassLoader加载来实现隔离。\n当多个合并部署的Biz为web应用时，则面临着更多的挑战，这里我们可以对比独立tomcat部署多个webapp的实现，其除了各webapp之间的隔离外，还要保证tomcat自身资源的共享和统一管控。SOFAArk从0.6.0开始支持基于springboot embedded tomcat的多web应用合并部署，它是如何做到的，是否可以继续扩展支持其它类型web容器应用，下文将会进行具体分析。\n原生springboot-web应用部署流程 我们先从原生的springboot构建的基于内置tomcat的web应用说起。其在运行main函数初始化时，使用TomcatServletWebServerFactory#getWebServer这一工厂方法，创建了一个实现WebServer接口的TomcatWebServer实例，用来控制一个tomcat服务器，其中包括了一个Catalina Server的实现StandardServer，Server中的Engine、Host、Context容器也都是一个，Context中包含了唯一的contextPath。\nspringboot自身还有jetty、netty等WebServer的实现，同样由其对应的工厂方法创建。对应的工厂bean基于springboot的自动装配机制加载。\n两种合并部署模式 首先我们可以参考非Web的多Biz合并部署，SOFAArk使用不同的类加载器加载不同的Biz，其中Master Biz为LaunchedURLClassLoader加载，非Master Biz有其专属的BizClassLoader加载。对于每个Web Biz，也会使用其类加载器完成上述原生springboot web应用的启动流程，创建自己的Server、Host等。\n这种情况下，为了区分不同Biz的接口，需要为每个Biz配置不同的port。\n这种方式由于一个Jvm进程中包含了多个Server及其Host，因此被称为多Host模式。\n多Host模式的问题首先在于重复创建了tomcat相关的资源，造成资源的浪费；其次是每个Biz有自己的端口，不利于整个Ark包应用整体对外提供服务。因此SOFAArk提供了类似独立tomcat部署多webapp的方式。所有Biz共用同一个Server及Host，每个Biz只创建自己的Context，通过Context中的contextPath将自身接口与其它Biz接口做区分。\n这种方式由于一个Jvm进程中共用一个Server及其Host，因此被称为单Host（多Context）模式。下面将就其实现做重点介绍。\n支持单Host合并部署的关键点 相较于单纯的springboot应用，一个Ark包的复杂之处在于，它可以包含多个Ark Biz，其中每个Ark Biz都是一个完整的springboot项目。因此在使用单个内置tomcat实例部署时会面临以下问题：\n 多个Biz(springboot项目)需要共用tomcat实例；\n 需要像独立tomcat下部署多webapp一样，通过添加前缀的方式区分不同Biz的http接口。\n 因此sofa-ark对springboot的相关实现做了替换，具体如下：\n sofa-ark springboot ArkTomcatServletWebServerFactory TomcatServletWebServerFactory ArkTomcatEmbeddedWebappClassLoader TomcatEmbeddedWebappClassLoader ArkTomcatWebServer TomcatWebServer 并使用其插件机制来扩展，ArkTomcatEmbeddedWebappClassLoader位于web-ark-plugin插件中，当maven依赖该插件时，springboot判断ArkTomcatEmbeddedWebappClassLoader类存在，加载ArkTomcatServletWebServerFactory，该Factory再创建ArkTomcatWebServer，由此使用单Host模式合并部署。\n若未依赖该插件，则ArkTomcatEmbeddedWebappClassLoader不存在，springboot自动加载其原生实现，使用多Host模式合并部署。\n多Biz共用tomcat实例 针对第一个问题——多个Biz要共用tomcat实例，sofa-ark定义了EmbeddedServerService接口，插件web-ark-plugin里包含了接口的实现EmbeddedServerServiceImpl，来持有公共tomcat实例。\npackage com.alipay.sofa.ark.web.embed.tomcat; //作为ark plugin导出 public class EmbeddedServerServiceImpl implements EmbeddedServerService\u0026amp;lt;Tomcat\u0026amp;gt; { //共享tomcat private Tomcat tomcat; private Object lock = new Object(); @Override public Tomcat getEmbedServer() { return tomcat; } @Override public void setEmbedServer(Tomcat tomcat) { if (this.tomcat == null) { //通过加锁，避免多Web Biz并发启动加载时重复创建tomcat实例 synchronized (lock) { if (this.tomcat == null) { this.tomcat = tomcat; } } } } } 如果Biz引入了web-ark-plugin，则在ArkTomcatServletWebServerFactory中注入EmbeddedServerServiceImpl，持有最先初始化的Web Biz创建的Tomcat实例(TomcatWebServer的核心)，并在后续初始化的其它Biz调用getWebServer获取tomcat实例时，返回持有的同一个实例，以此来保证多个Biz运行在同一个tomcat中。\npackage com.alipay.sofa.ark.springboot.web; //每个Web Biz启动中都会创建一 …","date":1655362800,"description":"SOFAArk 源码解析-多 Web 应用合并部署","dir":"projects/sofa-boot/sofa-ark-multi-web-component-deploy/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e279d4b44741b8b88e22bf6420d8b5a6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","publishdate":"2022-06-16T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","summary":"背景 原生springboot-web应用部署流程 两种合并部署模式 支持单Host合并部署的关键点 多Biz共用tomcat实例 多Biz接口区分 总","tags":["“源码解析”"],"title":"SOFAArk 源码解析-多 Web 应用合并部署","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","wordcount":3703},{"author":"林楠","categories":"SOFAStack","content":" 前言 spring-boot-starter-actuator模块为 Spring Boot 应用提供了监控能力，内置一系列健康指标，如数据源、磁盘空间等，并且允许开发者自定义健康指标。Spring Boot 提供 health 端点，将所有健康指标聚合，当应用中有一个组件状态异常，那么应用的整体状态视为down，开发者可以访问 health 端点来了解应用当前的运行状况。\n SOFABoot 基于 actuator 模块扩展了健康指标，为应用提供 SOFA 组件的健康检查能力。同时，在 Spring Boot 原生的健康检查能力基础之上，增加了 Readiness Check 的能力。在这里我们做一个区分，Spring Boot 原生的健康检查称为 Liveness Check，SOFABoot 增加的健康检查称为 Readiness Check。Liveness Check 关注应用运行是否正常，如果 Liveness 状态异常，表示这个应用已经无法对外提供服务；Readiness Check 则关注的是应用有没有启动完成，是否进入“准备就绪”状态，能否对外提供服务。\n Readiness Check 只在应用启动阶段执行一次，通过请求 readiness 端点获取就绪状态，准备就绪后流量将进入应用。Readiness Check 完成后，多次请求 readiness 端点，不会重新发起检查。因此，在运行阶段应使用 Liveness Check 检查应用健康情况。\n 总体流程 在介绍总体流程前，先看一下 SOFABoot 健康检查机制中的一些重要接口：\n 接口类 说明 org.springframework.boot.actuate.health.HealthIndicator Spring Boot 原生的健康检查接口，想要新增一个自定义健康指标，可以直接扩展此接口 com.alipay.sofa.healthcheck.core.HealthChecker SOFABoot 提供的健康检查接口，相比 HealthIndicator 接口，增加了一些扩展参数，如失败重试次数，超时时间等 com.alipay.sofa.boot.health.NonReadinessCheck SOFABoot 默认会将所有 HealthIndicator 和 HealthChecker 纳入 Readiness Check 中，可以实现该接口将指标项标记为不参与 Readiness Check com.alipay.sofa.healthcheck.startup.ReadinessCheckCallback SOFABoot在 Readiness Check 之后会回调这个接口，如果想要在健康检查后做一些处理，可以直接扩展此接口 SOFABoot 的健康检查是基于 Spring 事件机制实现的，核心是 com.alipay.sofa.healthcheck.ReadinessCheckListener。ReadinessCheckListener 类实现了 GenericApplicationListener 接口，并监听 ContextRefreshedEvent事件，当 Spring 上下文刷新时触发健康检查流程：\npublic void onContextRefreshedEvent(ContextRefreshedEvent event) { if (applicationContext.equals(event.getApplicationContext())) { healthCheckerProcessor.init(); healthIndicatorProcessor.init(); afterReadinessCheckCallbackProcessor.init(); readinessHealthCheck(); readinessCheckFinish = true; } } 初始化 HealthCheckerProcessor：在 Spring 上下文中查找所有 HealthChecker 类型的 Bean； 初始化 HealthIndicatorProcessor：在 Spring 上下文中查找所有 HealthIndicator 类型的 Bean，并排除掉不参与 Readiness Check 的Bean。默认会排除 NonReadinessCheck 类型的 Bean，还可以通过参数com.alipay.sofa.boot.excludedIndicators 配置要排除的类型； 初始化 AfterReadinessCheckCallbackProcessor：在 Spring 上下文中查找所有 ReadinessCheckCallback 类型的 Bean ； 执行 Readiness Check 从上文中可以看出，readinessHealthCheck 方法是 Readiness Check 的入口：\npublic void readinessHealthCheck() { ...... healthCheckerStatus = healthCheckerProcessor .readinessHealthCheck(healthCheckerDetails); ...... healthIndicatorStatus = healthIndicatorProcessor .readinessHealthCheck(healthIndicatorDetails); ...... if (healthCheckerStatus \u0026amp;amp;\u0026amp;amp; healthIndicatorStatus) { ...... healthCallbackStatus = afterReadinessCheckCallbackProcessor .afterReadinessCheckCallback(healthCallbackDetails); } determineReadinessState(); } Readiness Check 的主要流程是依次执行 HealthChecker 和 HealthIndicator 的检查，如果所有健康指标状态均正常，才会执行ReadinessCheckCallback 回调。最后聚合所有指标状态，判断应用是否准备就绪。 健康检查的核心逻辑就在三个处理器HealthCheckerProcessor、HealthIndicatorProcessor和AfterReadinessCheckCallbackProcessor中，接下来我们依次分析一下。\nHealthCheckerProcessor 首先看一下 HealthChecker 接口为开发者提了哪些方法：\n 方法签名 说明 Health isHealthy() 指标项检查，返回值标识指标项状态是否正常 String getComponentName() 指标项名称 int getRetryCount() 失败重试次 …","date":1655276400,"description":"源码解析 | SOFABoot HealthCheck 机制解析","dir":"projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"33693ca9474cc5e3a509fca7935b1cbb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","publishdate":"2022-06-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","summary":"前言 spring-boot-starter-actuator模块为 Spring Boot 应用提供了监控能力，内置一系列健康指标，如数据源、磁盘空间等，并且允许","tags":["“源码解析”"],"title":"源码解析：SOFABoot HealthCheck 机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","wordcount":5393},{"author":null,"categories":"SOFAStack","content":" 文｜严松（花名：井守）\nNydus 镜像开源项目 Maintainer蚂蚁集团技术专家\n蚂蚁集团基础设施研发，专注云原生镜像与容器运行时生态\n本文 7060 字 阅读 15 分钟\n｜前言｜ 容器镜像是云原生的基础设施之一，作为容器运行时文件系统视图基础，从它诞生到现在，衍生出了镜像构建、存储、分发到运行时的整个镜像生命周期的各种生态。\n然而，虽然镜像生态众多，但自它诞生以来，镜像设计本身并没有多少改进。这篇文章要探讨的就是对容器镜像未来发展的一些思考，以及 Nydus 容器镜像的探索和实践。\n读完这篇文章，你能够了解到：\n- 容器镜像的基本原理，以及它的组成格式；\n- 目前的镜像设计有哪些问题，应该如何改进；\n- Nydus 容器镜像做了哪些探索，以及怎么实践。\nPART. 1 容器镜像 OCI 容器镜像规范 容器提供给了应用一个快速、轻量且有着基本隔离环境的运行时，而镜像提供给了容器 RootFS，也就是容器内能看到的整个 Filesystem 视图，其中至少包括了文件目录树结构、文件元数据以及数据部分。镜像的特点如下：\n- 易于传输，例如通过网络以 HTTP 的方式从 Registry 上传或下载；\n- 易于存储，例如可以打包成 Tar Gzip 格式，存储在 Registry 上；\n- 具备不可变特性，整个镜像有一个唯一 Hash，只要镜像内容发生变化，镜像 Hash 也会被改变。\n早期的镜像格式是由 Docker 设计的，经历了从 Image Manifest V1[1]、V2 Scheme 1[2]到 V2 Scheme 2[3]的演进。后来出现了诸如 CoreOS 推出的其他容器运行时后，为了避免竞争和生态混乱，OCI 标准化社区成立。它定义了容器在运行时、镜像以及分发相关的实现标准，我们目前用的镜像格式基本都是 OCI 兼容的。\n镜像主要是由镜像层和容器配置两大部分组成的。\n什么是镜像层？\n可以回想下平时写的 Dockerfile 文件：每条 ADD、COPY、RUN 指令都可能会产生新的镜像层，新层包含的是在旧层的基础上，新增加或修改的文件 （包含元数据和数据） ，或被删除的文件 （用称之为  Whiteout **[4] 的特殊文件表示删除） 。\n所以简单来说镜像的每一层存储的是 Lower 与 Upper 之间的 Diff，非常类似 Git Commit。这层 Diff 通常会被压缩成 Tar Gzip 格式后上传到 Registry。\n在运行时，所有 Diff 堆叠起来后，就组成了提供给容器的整个文件系统视图，也就是 RootFS。镜像的另外一部分是容器运行时配置，这部分包含了命令、环境变量、端口等信息。\n镜像层和运行时配置各自有一个唯一 Hash （通常是 SHA256） ，这些 Hash 会被写进一个叫 Manifest[5]的 JSON 文件里，在 Pull 镜像时实际就是先拉取 Manifest 文件，然后再根据 Hash 去 Registry 拉取对应的镜像层/容器运行时配置。\n目前的镜像设计问题 第一，我们注意到镜像层需要全部堆叠后，容器才能看到整个文件系统视图，所以容器需要等到镜像的每一层都下载并解压之后才能启动。有一篇 FAST 论文研究分析[6]说镜像拉取占了大约容器 76% 的启动时间，但却只有 6.4% 的数据是会被容器读取的。这个结果很有趣，它激发了我们可以通过按需加载的方式来提高容器启动速度。另外，在层数较多的情况下，运行时也会有 Overlay 堆叠的开销。\n第二，每层镜像是由元数据和数据组成的，那么这就导致某层镜像中只要有一个文件元数据发生变化，例如修改了权限位，就会导致层的 Hash 发生变化，然后导致整个镜像层需要被重新存储，或重新下载。\n第三，假如某个文件在 Upper 层里被删除或者被修改，旧版本文件依然留存在 Lower 层里不会被删除。在拉取新镜像时，旧版本还是会被下载和解压，但实际上这些文件是容器不再需要的了。当然我们可以认为这是因为镜像优化做的不够好，但在复杂场景下却很难避免出现这样的问题。\n第四，镜像 Hash 能够保证镜像在上传和下载时候的不可变，但在镜像被解压落盘后，很难保证运行时数据不被篡改，这也就意味着运行时的数据是不可信的。\n第五，镜像是以层为基本存储单位，数据去重是通过层的 Hash，这也导致了数据去重的粒度较粗。从整个 Registry 存储上看，镜像中的层与层之间，镜像与镜像之间存在大量重复数据，占用了存储和传输成本。\n镜像设计应该如何改进 我们看到了 OCI 镜像设计的诸多问题，在大规模集群场景下，存储与网络负载压力会被放大，这些问题的影响尤为明显，因此镜像设计急需从格式、构建、分发、运行、安全等各方面做优化。\n首先，我们需要实现按需加载。 在容器启动时，容器内业务 IO 请求了哪些文件的数据，我们再从远端 Registry 拉取这些数据，通过这种方式，可以避免镜像大量数据拉取阻塞容器的启动。\n其次，我们需要用一个索引文件记录某个文件的数据块在层的 Offset 偏移位置。 因为现在的问题是，Tar 格式是不可寻址的，也就是说需要某个文件时，只能从头顺序读取整个 Tar 流才能找到这部分数据，那么我们自然就想到了可以用这种方式来实现。\n接着，我们改造层的格式以支持更简单的寻址。 由于 Tar 是会被 Gzip 压缩的，这导致了就算知道 Offset 也比较难 Unzip。\n我们让原来的镜像层只存储文件的数据部分 （也就是图中的 Blob 层） 。Blob 层存储的是文件数据的切块 （Chunk） ，例如将一个 10MB 的文件，切割成 10 个 1MB 的块。这样的好处是我们可以将 Chunk 的 Offset 记录在一个索引中，容器在请求文件的部分数据时，我们可以只从远端 Registry 拉取需要的一部分 Chunks，如此一来节省不必要的网络开销。\n另外，按 Chunk 切割的另外一个优势是细化了去重粒度，Chunk 级别的去重让层与层之间，镜像与镜像之间共享数据更容易。\n最后，我们将元数据和数据分离 。 这样可以避免出现因元数据更新导致的数据层更新的情况，通过这种方式来节省存储和传输成本。\n元数据和 Chunk 的索引加在一起，就组成了上图中的 Meta 层，它是所有镜像层堆叠后容器能看到的整个 Filesystem 结构，包含目录树结构，文件元数据，Chunk 信息等。\n另外，Meta 层包含了 Hash 树以及 Chunk 数据块的 Hash，以此来保证我们可以在运行时对整颗文件树校验，以及针对某个 Chunk 数据块做校验，并且可以对整个 Meta 层签名，以保证运行时数据被篡改后依然能够被检查出来。\n如上所述，我们在 Nydus 镜像格式中引入了这些特性，总结下来如下：\n- 镜像元数据和数据分离，用户态按需加载与解压；\n- 更细粒度的块级别数据切割与去重；\n- 扁平化元数据层 （移除中间层） ，直接呈现 Filesystem 视图；\n- 端到端的文件系统元数据树与数据校验。\nPART. 2 Nydus 解决方案 镜像加速框架 Nydus 镜像加速框架是 Dragonfly[7] …","date":1655190000,"description":"容器镜像是云原生的基础设施之一，虽然镜像生态众多，但自它诞生以来，镜像设计本身并没有多少改进。这篇文章要探讨的就是对容器镜像未来发展的一些思考，以及 Nydus 容器镜像的探索和实践。","dir":"blog/nydus-exploratory-practice-of-next-generation-container-images/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"66c30936f5c0aa0e2bdf61ffdb88288e","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","publishdate":"2022-06-14T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","summary":"文｜严松（花名：井守） Nydus 镜像开源项目 Maintainer蚂蚁集团技术专家 蚂蚁集团基础设施研发，专注云原生镜像与容器运行时生态 本文 7060 字 阅读 15 分","tags":["SOFAStack"],"title":"Nydus —— 下一代容器镜像的探索实践","type":"blog","url":"/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","wordcount":8779},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@有时候 提问：\n SOFARPC 注册服务和订阅服务用到的 interface，Java 类文件内容是一样的，但如果包路径不是完全一样有问题么？\n A：路径不一样就是不同接口，注册中心不感知到 method 这层。dataid 不一样的，https://www.sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/ 。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n2.@啥也不是 提问：\n 大佬们，在现有协议拓展框架下，在 choose host 以后根据节点信息动态选择上游的协议，实现起来感觉不是很方便，有大佬指点一下吗？\n A：你是上下游协议不一样吗？\n 是的，而且同一个集群里面协议也可能不一样。我们自己的 RPC 协议存在多个版本，上下游的版本我们没办法控制，想着每个版本分别作为一种协议，利用框架能力，让协议版本的选择跟序列化解偶，每个 host 的版本是通过我们自己配置中心获取的。cluster 中 host 协议版本不受我们控制。\n A：Upstream 的协议本来就是在 filter 里面转换，你在 choose host 之后进行 filter 设置就行了。这个是一个协议转换框架 filter，根据配置的协议转换，你可以复用这个，区别就是 upstream 的协议是动态指定的，但没有本质区别：https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ftranscoder\n「MOSN」https://github.com/mosn/mosn\n3.@曹飞 提问：\n 大佬，监控指标可以显示到应用维度吗？ A：Metric 可以自定义输出的。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 ID API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 Wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 蚂蚁集团获得 OpenInfra Superuser 2022 年度大奖！\n KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境\n 如何看待 Dapr、Layotto 这种多运行时架构？\n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers！\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1654844400,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220610/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2b864568ab02c9da5090b213d0ff984a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220610/","publishdate":"2022-06-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220610/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220610/","wordcount":1483},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#28:SOFAArk 类隔离框架设计\n 活动时间：06 月 09 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#28 SOFAArk 类隔离框架设计 SOFAArk 是一款基于 Java 实现的轻量级类隔离框架，主要提供类隔离、动态部署、合并部署能力。本次分享将用 30 分钟的时间，带你深入 SOFAArk 框架，一起剖析其技术背景及设计思想，并展望其未来的发展趋势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 张冯君（花名：远远）\n 蚂蚁集团开发工程师\n 负责蚂蚁集团 SOFAArk 框架方向的相关工作\n 议程 直播回放 https://www.bilibili.com/video/BV1gS4y1i7Fg/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1654758000,"description":"2022 年 6 月 09 日 19：00 - 20：00 ，线上直播第 28 期。","dir":"activities/sofa-channel-28/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bfe5796985a7bfb85eb7b19614b05a57","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-28/","publishdate":"2022-06-09T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-28/","summary":"概要 活动主题：SOFAChannel#28:SOFAArk 类隔离框架设计 活动时间：06 月 09 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B","tags":["SOFAChannel","SOFAArk","类隔离框架"],"title":"SOFAChannel#28 SOFAArk 类隔离框架设计","type":"activities","url":"/sofastack.tech/activities/sofa-channel-28/","wordcount":452},{"author":null,"categories":"SOFAStack","content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团高级技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n本文 2580 字 阅读 6 分钟\n｜前言｜ 本文撰写于 KusionStack 开源前夕，作者有感而发，回顾了团队从 Kusion 项目开发之初到现今成功走上开源之路的艰辛历程。当中既描述了作者及其团队做 Kusion 项目的初心和项目发展至今的成果，也表达了作者自身对团队的由衷感激，字里行间都散发着真情实感。\nKusionStack 是什么？\nKusionStack 是开源的可编程云原生协议栈！\nKusion 一词来源于 fusion （意为融合） ，希望通过一站式的技术栈融合运维体系的多个角色，提升运维基础设施的开放性、扩展性，从整体上降本增效。KusionStack 通过定义云原生可编程接入层，提供包括配置语言 KCL、模型界面、自动化工具、最佳实践在内的一整套解决方案，连通云原生基础设施与业务应用，连接定义和使用基础设施的各个团队，串联应用生命周期的研发、测试、集成、发布各个阶段，服务于云原生自动化系统建设，加速云原生落地。\nPART. 1 为了一个理想的运维体系 2019 年秋，MOSN 的工作已持续了近两年，期间我们逐步完成了在支付宝核心链路的形态验证。整个过程中除了 MOSN 本身面对的种种技术挑战和困难，所谓的云原生技术红利，实际上也已经掣肘于运维系统固化所造成的效率制约。\n有一天主管找我吃饭 （下套） ，期间向我描述了他理想中的运维体系：\n他希望 SRE 能通过一种专用语言来编写需求，通过写代码来定义基础设施的状态，而不是花费极大的精力在检查、发现、修复的循环上。基础设施团队则通过提供开放的可编程语言和工具支撑不同诉求的 SRE 团队，达到更高的整体 ROI。\n我立刻意识到这和 Hashicorp 的 Terraform 神之相似 （后来 Hashicorp 在 2021 年底上市，以超过 150 亿美元的市值成为迄今为止市值最高的一次开源 IPO） 。另一方面，不同于 IaaS 交付场景，蚂蚁面对着大量更规模化、复杂度更高的云原生 PaaS 场景，又让我想到了 Google 内部运用专用语言、工具等技术开放 Borg[1]运维能力的实践[2]，当时感觉这是一个既有意思又有挑战的事[3]。\n饭桌上我们聊了一些思路以及一些还不太确定的挑战，他问我想不想搞一个试试，搞不成也没关系。当时没想太多，饭没吃完就答应了。\nPART. 2 漫长的学习、探索与实践 隔行如隔山。\n没有过语言设计研发的经验，也没有过开放自动化系统设计的经验，项目开展之初，我们就陷入了举步维艰的困境。\n经历了一段漫长时间的学习、摸索和实践的反复循环之后，项目依旧没有大的起色，更困难的是我们不但要面对蚂蚁内部复杂又耦合的场景和问题，还要经受「这种高度工程化的方式在蚂蚁是否有生存土壤」的质疑。\n屋漏偏逢连夜雨，期间又令人惋惜且无奈的经历了一些人事变化，同时由于种种原因，项目一度陷入了各种困境。整个 2020 年，我们在未知、纠结、无奈中度过……\n感谢瓴熙、庭坚和我的主管，感谢你们当时没有放弃这个项目，依然与我一同坚守。\nPART. 3 痛并快乐的孵化之旅 通过持续地布道、交流和沟通，我们逐步在基础设施技术团队和 SRE 团队找到了更多有共识的朋友。\n同时在技术上，我们亦脱离了迷茫，真正意义上地启动了 Kusion 项目，也成功地从 PoC 过渡到了 MVP 的阶段。\n最终，我们以“非标”应用为切入点，开始了痛并快乐着的孵化之旅。\n感谢零执、青河、子波、李丰、毋涯、向野、达远……在这里无法一一列举，感谢你们的坚持让这个想法逐步成为现实。\nPART. 4 突破与进展 略过中间的种种探索和实践，回顾这段历程，在这一年多的时间里我们结合了编译技术、运维及平台技术，成功建立了一个基于 Kusion 可编程技术栈的运维体系。\n在业务场景上，项目覆盖了从 IaaS 到 SaaS 的大量运维场景，截至目前共接入了 800+ 应用，覆盖 9 个 BG，21 个 BU，其中典型案例交付运维提效 90% 以上，这也是蚂蚁内部第一次将大量异构应用纳入到一整套运维技术栈。\n在蚂蚁我们基于云原生容器和微服务技术深入探索了 DevOps、CICD 实践，完善了蚂蚁的云原生技术体系，逐步释放了云原生效率红利，同时形成了一个近 300 人的虚拟运维研发团队。\n不同职能不同团队的参与者凝聚在一起解决各自所面对的问题，贡献了 3W+ commit 和 35W+ 行代码，有一些参与者自发成为 Kusion 的研发者 。我认为这些工程师文化理念和领域知识的积累带来了远超运维业务本身的价值。\n此外，Kusion 也成为了可编程基线产品、云原生运维产品、多云交付产品等新一代运维产品的基础技术，成为蚂蚁运维体系架构升级的一部分。\n不忘初心，我们希望通过技术手段促进与运维参与方的合作关系的合理化、基于开放技术栈的自动化，以及运维数据与知识的沉淀积累，以达到整体协作运维效率的不断提升。\n同时，因蚂蚁内部运维场景较多且链路复杂，每个环节都需要最懂运维业务的 SRE 密切参与，与平台、应用研发协同工作，最终各环节联合在一起形成了一套完整的运维体系，在这样的思路下开放技术也会越来越重要。\n平台研发、SRE、应用研发等多种角色协同编写的代码是一种数据的沉淀，亦是一种业务知识的沉淀，基于这些数据和知识，未来会有更多的可能性。\nPART. 5 走上开源之路 在历经了一段内部探索之后，我们希望把 KusionStack 开源到技术社区。因为我们意识到自身面对的问题，其他公司、团队其实也同样正在面对。借助开源这件事，我们希望团队的这些工作成果能对更多人有所帮助。\n当然，也受限于自身能力以及精力和资源的投入，我们希望能有更多朋友参与进来，与我们共同去完善 KusionStack，不论你是工作在云原生、运维自动化、编程语言或者是编译器中的哪一个领域，我们都非常期待和欢迎你的加入。\nPART. 6 期待与你共成长 这段经历对我来说异常宝贵，不仅仅是在于自身再一次在新的技术领域和蚂蚁的技术升级方面尝试了新的探索并实现了突破，更宝贵的是，自己还拥有了一段与一群人均 95 后的小伙伴一起将想法落地实现的奇幻历程。\n在未来， Kusion 的朋友圈不再局限于蚂蚁内部，面向开源，我们期待着能有更多的社区朋友在 KusionStack 与我们共同成长！\n了解更多\u0026amp;hellip;\nKusionStack Star 一下✨：\nhttps://github.com/KusionStack\nKusionStack 的开源，希望能对大家有所帮助，也希望能跟更多朋友共同完善 KusionStack。欢迎对云原生、运维自动化、编程语言、编译器感兴趣的同学一起参与社区共建，在新的技术领域升级方面进行探索和突破，实现更多新的想法。\n点击文末阅读原文直达项目地址。\n【参考链接】\n[1]《Large-scale cluster management at Google with …","date":1654585200,"description":"KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境","dir":"blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"688d35ea65772596c3a0115a62a63b53","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","publishdate":"2022-06-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","summary":"文｜朵晓东（花名：奕杉 ) KusionStack 负责人、蚂蚁集团高级技术专家 在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作 本文 2580 字 阅读 6 分钟 ｜前","tags":["SOFAStack"],"title":"KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境","type":"blog","url":"/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","wordcount":2772},{"author":"周群力","categories":"SOFAStack","content":" 文｜周群力（花名：仪式 )\nLayotto PMC；Layotto 和 SOFAStack 开源社区的建设，Dapr 贡献者，Dapr sig-api 的 Co-chair\n本文 10963 字 阅读 20 分钟\n2019 年，微软开源了 Dapr 项目。2021 年，蚂蚁参照 Dapr 思想开源了 Layotto 项目。如今，蚂蚁已落地 Layotto，服务了很多应用。从理想落地到现实的过程中，我们遇到了不少问题，也对项目做了很多改变。回过头再看，如何看待 Dapr、Layotto 这种多运行时架构？我们能从中学到什么？\n本次我将从以下几个方面，分享蚂蚁在落地多运行时架构之后的思考：\n1. 如何看待“可移植性”\n2. 多运行时架构能带来哪些价值\n3. 与 Service Mesh、Event Mesh 的区别\n4. 如何看待不同的部署形态\nPART. 1 快速回顾\n如果你熟悉 Multi-Runtime、Dapr 和 Layotto 的概念，可以跳过这一章节，直接进入下一章节。\n快速回顾：什么是 Multi-Runtime 架构？\nMulti-Runtime 是一种服务端架构思路，如果用一句话来概括，就是把应用里的所有中间件挪到 Sidecar 里，使得“业务运行时”和“技术运行时”分离开。\n更详细的解释如下：首先来看 Service Mesh，和传统 RPC 框架相比，Service Mesh 的创新之处在于引入了 Sidecar 模式。Service Mesh 只解决了服务间通讯的需求，而现实中的分布式应用存在更多需求，比如“协议转换”、“状态管理”等。Multi-Runtime 架构提出将各种各样的分布式能力外移到独立 Runtime，最后和应用 Runtime 共同组成微服务，形成所谓的“Multi-Runtime” （多运行时） 架构。\n具体细节可以详阅《Multi-Runtime Microservices Architecture》和《Mecha：将 Mesh 进行到底》。\n哪些项目实现了 Multi-Runtime 架构？\nDapr\nDapr 的全称是“Distributed Application Runtime”，即“分布式应用运行时”，是一个由微软发起的开源项目。\nDapr 项目是业界第一个 Multi-Runtime 实践项目，Dapr 的 Sidecar，除了可以和 Service Mesh 一样支持服务间通讯，还可以支持更多的功能，如 state （状态管理） 、pub-sub （消息通讯） ，resource binding （资源绑定，包括输入和输出） 。Dapr 将每种功能抽象出标准化的 API （如 state API） ，每个 API 都有多种实现，比如用户可以面向 state API 编程，但是可以随意切换存储组件，今年用 Redis，明年改成用 MongoDB，业务代码不用改。\n如果之前没有接触过 Dapr，更详细的介绍可以阅读《Dapr v1.0 展望：从 Service Mesh 到云原生》这篇文章。\nLayotto\nLayotto 是由蚂蚁集团 2021 年开源的一个实现 Multi-Runtime 架构的项目，核心思想是在 Service Mesh 的数据面（MOSN里支持 Dapr API 和 WebAssembly 运行时，实现一个 Sidecar 同时作为 Service Mesh 数据面、多运行时 Runtime、FaaS 运行时。项目地址为：https://github.com/mosn/layotto\n以上是本文背景，接下来是本次主题分享。\nPART. 2 你真的需要这种“可移植性”吗？\n社区比较关注 Dapr API 的“可移植性”，但在落地过程中，我们不禁反思：你真的需要这种“可移植性”吗？\n标准化 API 能满足所有需求吗？\n数据库领域曾出现过一个有趣的讨论：同一个数据库能否适用于所有场景，满足所有需求？ 比如，一个数据库能否同时支持 OLAP+OLTP+ACID 等等需求？\n今天，我们在建设 Dapr API 的过程中也遇到了有趣的问题：在某个产品领域 （比如消息队列） ，能否定义一套“标准 API”同时适用于所有的消息队列？\n当然，这两个问题不能混为一谈：即使是两种不同类型的数据库，比如两个数据库，一个只做 OLAP，另一个只做 OLTP，它们都可以支持 SQL 协议。两个差距那么大的数据库都能用同样的协议，我们有理由相信：在特定领域，设计一个适用于所有产品的“标准 API”是可行的。\n可行，但现在还不完全行。\n现在的 Dapr API 还比较简单，简单场景足以胜任，但在复杂的业务场景下，做不到“帮助应用 Write once,run on any cloud”。对这个问题，敖小剑老师的文章《死生之地不可不察：论 API 标准化对 Dapr 的重要性》有过详细描述，大意是说：\n现在的 Dapr API 比较简单，在生产落地的时候满足不了复杂需求，于是开发者只能添加很多自定义的扩展字段，在 Sidecar 的组件里做特殊处理。比如下面是用 State API 时候的一些自定义扩展字段：\n（图片摘自敖小剑老师的文章）\n这些自定义的扩展字段会破坏可移植性：如果你换一个组件，新组件肯定不认识这些字段，所以你得改代码。\n之所以出现这个问题，背后的根本原因是 Dapr API 的设计哲学。\n社区在设计 Dapr API 时，为了可移植性，设计出的 API 倾向于 “功能交集” 。比如在设计 Configuration API 时，会考察各种配置中心 A、B、C，如果 A、B、C 都有同一个功能，那么这个功能才会出现在 Dapr API 中：\n然而，在现实世界中，人们的需求可能是 A 和 B 的交集，B 和 C 的交集 （如下图红色部分） ，而不是 A、B、C 的交集：\n或者更常见，用户的需求是“B 的所有功能”，其中必然包括一些 B 独有的功能，Dapr API 无法覆盖：\nDapr 提供“标准 API”、“语言 SDK”和“Runtime”，需要应用进行适配 （这意味着老应用需要进行改造） ，侵入性比较大。\n因此 Dapr 更适合新应用开发 （所谓 Green Field） ，对于现有的老应用 （所谓 Brown Field） 则需要付出较高的改造代价。但在付出这些代价之后，Dapr 就可以提供跨云跨平台的可移植性，这是 Dapr 的核心价值之一。\n这些听起来是解决不了的问题。那怎么办？\n跨云部署时，你真的需要从 Redis 换成 Memcached 吗？\n在设计 API 时，常常出现类似的讨论：\nA：嘿，这个功能只有 Redis 和 xxx 有，但是 Memcached 和其他存储系统没有。我们该怎么办，要不要把这个功能纳入 API 规范里？\nB：如果我们把这个功能纳入 API 里，会有什么问题？\nA：那样的话，使用我们 API 的用户就没法从 Redis 迁移到 Memcached 了，这破坏了可移植性！\n等一等……你真的需要从 Redis 换成 Memcached 吗？\n你真的需要这种“可移植性”吗？\n不需要吧！如果 …","date":1653980400,"description":"本文讨论了 Layotto 落地之后，关于 Multi-Runtime 架构“可移植性”、落地价值以及部署形态等方面的思考。","dir":"blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","fuzzywordcount":9200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d0732e32f9b202c205fb1e03b195eb8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","publishdate":"2022-05-31T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","summary":"文｜周群力（花名：仪式 ) Layotto PMC；Layotto 和 SOFAStack 开源社区的建设，Dapr 贡献者，Dapr sig-api 的 Co-chair 本文 10963 字 阅读 20 分钟 2019 年，微软开源了 Dapr 项目。","tags":["SOFAStack"],"title":"如何看待 Dapr、Layotto 这种多运行时架构","type":"blog","url":"/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","wordcount":9182},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@周衡 提问：\n 请问一下，我需要调度 RPC 的上下文是哪一个类？有一些参数想直接通过上下文传递。\n A：RpcInvokeContextv6\n「SOFARegistry」：https://github.com/sofastack/sofa-rpc\n@bobtthp 提问：\n MOSN 对接 dubbo 目前注册中心支持 zk 吗？\n A：FaaS 示例么？那个还没上过生产，还在探索阶段。支持的，可以参考这个文档：https://www.github.com/mosn/mosn/tree/master/pkg%2Fupstream%2Fservicediscovery%2Fdubbod%2Fcommon.go\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n 深入 HTTP/3（2）｜不那么 Boring 的 SSL\n 【2022 开源之夏】欢迎报名 MOSN 社区项目！\n 蚂蚁集团 Service Mesh 进展回顾与展望\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1653634800,"description":"SOFA Weekly | Kusion 开源啦、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220527/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1f1971d6ef1280f9bc0fa21d099dfd99","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220527/","publishdate":"2022-05-27T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220527/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | Kusion 开源啦、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220527/","wordcount":1025},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#27:深入 HTTP/3｜从QUIC-TLS 看协议的安全设计\n 活动时间：05 月 26 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#27 深入 HTTP/3｜从 QUIC-TLS 看协议的安全设计 安全通信是网络技术中绕不开的话题，而 QUIC 作为目前炙手可热的协议技术，在这上面也理所应当的有着非常多的优秀实践，本次分享将用 50 分钟的时间，带你深入 QUIC-TLS，一起剖析其技术背景及设计思想，并展望其未来的发展趋势。\n当然，本次直播也分享一些蚂蚁自己的工程实践经验及相关的产品。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 曾柯（花名：毅丝）\n 蚂蚁集团高级工程师\n 负责蚂蚁集团的接入层建设工作，主要方向为高性能安全网络协议的设计及优化\n 议程 直播回放 https://www.bilibili.com/video/BV1xg411o7Jo/\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1653634800,"description":"2022 年 5 月 26 日 19：00 - 20：00 ，线上直播第 27 期。","dir":"activities/sofa-channel-27/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cdb2bb81c619db029bb9a62a1374b721","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-27/","publishdate":"2022-05-27T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-27/","summary":"概要 活动主题：SOFAChannel#27:深入 HTTP/3｜从QUIC-TLS 看协议的安全设计 活动时间：05 月 26 日，周四晚 19 点 活动形式：线","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#27 深入 HTTP/3｜从 QUIC-TLS 看协议的安全设计","type":"activities","url":"/sofastack.tech/activities/sofa-channel-27/","wordcount":543},{"author":"曾柯","categories":"SOFAStack","content":" 文｜曾柯（花名：毅丝 )\n蚂蚁集团高级工程师*负责蚂蚁集团的接入层建设工作* 主要方向为高性能安全网络协议的设计及优化\n本文 10924 字，阅读 20 分钟\nPART. 1 引言 从前一篇文章《深入 HTTP/3（1）｜从 QUIC 链接的建立与关闭看协议的演进》对于 QUIC 的浅述中我们了解到，QUIC 的优化很大程度上是一种基于 TLS 流程的优化，由此也可见 TLS 对于 QUIC 的重要性，那么今天我们就来聊一聊 QUIC-TLS。为了表述尽量没有歧义，我们先来规范下文章中各个术语的意义。\n本文目前既然已经提到了 SSL、TLS 这两个术语，我们不妨先来简短回顾下安全协议的发展史，这既可以帮我们理清两个术语的关系，也能帮助我们对这项技术的进化有一个简短的概念。\nSSL (Secure Sockets Layer) 协议本身是网景公司为了保证互联网上数据传输的安全性，在 1994 年设计的一套协议。这套协议在当时被广泛使用在各大浏览器上，但 SSL 协议最初的几个版本安全性都非常堪忧，初期的更迭非常频繁，从 1994 年到 1995 年连续迭代了 3 个大版本，而现在大家最耳熟能详的应该就是 SSLv3.0 了。可惜 SSLv3.0 也没有逃脱更迭的厄运，由于硬件算力的迭代，大量 SSLv3.0 中广泛使用的加密算法不再安全，并且协议交互流程也存在不安全之处。1999 年，IETF 正式介入安全协议的设计及开发，并推出了 TLS (Transport Layer Security) 协议的第一个版本 TLS1.0，随后 TLS 协议的发展开始变得迟缓，在 2006 年 IETF 组织推出了 TLS1.1，并在 2008 年再次发布了 TLS1.2，两个版本都是针对一些握手交互过程中的细节的安全提升，握手流程其实是没有大的变化的。\n直到 2013 年，Google 在推出 gquic 的同时，也推出了其设计的安全交互流程 quic-crypto，quic-crypto 是一次交互流程的重大创新，也以此成为了 TLS1.3 的前身。TLS1.3 从某种意义上来说，应该被称作 TLS2.0，因为其革新力度非常大，当然这也导致其标准化流程非常长，TLS1.3 的标准化整整历经了 4 年，直到 2018 年才正式成为 RFC。而 TLS1.3 本身也成为了 IETF-QUIC 的安全交互技术的基础，所以这条时间线里也揉杂了 QUIC-TLS 的设计历程，我们来简单理一下：\n图 1. TLS 发展简史\n当然 DTLS 等相关安全技术的进化也融合在这条时间线中，限于篇幅问题，这里暂时不表。说了这么多废话，我们现在来正式标准化一下我们的名词：\n【SSL、TLS】 ：在本文中都指安全传输协议，后续的文章中只会使用 TLS 作为相关技术的代名词\n【QUIC-crypto】 ：Google quic 中使用的握手流程，本文不对其进行具体分析\n【QUIC-TLS】 ：本文指 IETF-QUIC 使用的安全交互流程，即 RFC9001 中标准化的流程，也是本文详细描述的重点\n【PTO】 ：全称为 Probe Timeout，定义于 RFC9002 中，留待下一篇文章来对其进行详细分析，本文将其理解成一个通信端设置的针对报文的超时重传的时间即可\n【DTLS】 ：全称为 Datagram Transport Layer Security，即面向报文的 TLS 协议，限于篇幅的问题，本文并不详细对其分析，而 DTLS 中存在有很多和 QUIC-TLS 类似思路的设计，感兴趣的同学可以参见 RFC9147\n“make infrastructure boring”是 Google 一直以来的口号，BoringSSL 这个开源产品则是他们在安全通信领域的行动，而文章的标题既然叫“不那么 Boring 的 SSL”，除了蹭一蹭 BoringSSL 和 OpenSSL 这些著名的 SSL 开源项目的热度之外，也是想给文章制造一点悬念：Boring 往往意味着相关技术简单好用到了令人发指的地步，而 QUIC 到底遇见了什么问题，才让本身相对成熟的 TLS 协议用起来不再 Boring？\n本文后续也将围绕这个话题展开，来看看 QUIC-TLS 设计中那些值得玩味的地方。\nPART. 2 浅看 TLS 本着由浅入深的思路，在开始介绍 QUIC-TLS 之前，我们也先浅析一下 TLS，这也非常有助于我们后面对于 QUIC-TLS 的理解。\nTLS 协议从某种程度上来说解决了几个哲学问题：你是谁？你怎么证明你是你？\n当然这些问题的答案还不足以保证整个的安全\u0026amp;hellip;\n1. 我们还需要一种技术来保证中间人无法获取到我们的数据，这也就是我们相对比较熟悉的 「对称加密技术」，比如 AES、SM4 等加密技术；\n2. 为了加密的数据也能证明通信一端的身份，我们引入了 「AEAD 加密即认证的模式」；\n3. 为了协商出这种对称加密的密钥，TLS 引入了 「非对称密钥交换技术」，典型如 ECDHE、RSA 等密钥交换算法；\n4. 为了身份管理的统一及身份的有效携带，TLS 引入了 「数字证书技术」，包括整个 pki 公钥体系及 X509 数字证书标准；\n5. 为了数据的不可篡改，TLS 引入了 「数字签名技术」，典型如 ECDSA、RSA 等签名算法；\n6. 为了各个阶段的加密密钥独立及签名流程的简洁，TLS 引入了 「Hash 算法」，典型如 SHA 系列算法。\n上述的各种机制再整个 TLS 协议中被抽象为两部分协议：\n一层是 Handshake 协议，负责核心密钥的交互及身份认证；一层是 Record 协议，负责数据的安全，完整性及握手完成后数据的可信证明，而 Handshake 协议则坐落于 Record 协议之上，这也就形成了这样的协议栈。\n图 2. TLS 协议栈简图\n简而言之，Handshake 过程中的数据也依赖 Record 层来进行数据加密，而 Record 层加密的 key 则依赖 Handshake 层进行交互得到。这看似是个逻辑死锁，实际上是通过一个层层递进的状态机完成的，抛开繁琐的 TLS 状态机本身，这个流程基本可以用下图来表述：\n图 3. TLS 密钥状态更新流程图\n至于 TLS 的初始阶段使用明文传输的数据，也并不违背这个流程，我们可以将其理解为 TLS 初始阶段对应一个值为空的 key。而从上图中我们也可以看到，实现和虚线部分对应的两个阶段切换，必须有严格的先后顺序，如果发生乱序，一端是无法完成数据的解析的，所以 TLS 协议非常依赖底层传输协议来保证数据的有序到达，而这也是 TLS 的设计区别于 DTLS 和 QUIC-TLS 的最大根因之一。有了这部分知识储备，我们再来看 TLS 的握手 (以 TLS1.3 的 0-RTT 交互场景为例) ，就会清晰很多：\n图 4. TLS 握手流程图\n可以看到，明文\u0026amp;rdquo;()\u0026amp;ldquo;,\u0026amp;rdquo;{}\u0026amp;ldquo;,\u0026amp;rdquo;[]\u0026amp;ldquo;对应的加密状态的切换，和上面的图的流程基本是一致的，而典型如 EndOfEarlyData 这种标 …","date":1653375600,"description":"深入 HTTP/3（2）｜不那么 Boring 的 SSL","dir":"blog/deeperinto-http-3-2-the-not-so-boring-ssl/","fuzzywordcount":9500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e7a8be2c91c093af30cba5045b0b6516","permalink":"https://sofastack.github.io/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","publishdate":"2022-05-24T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","summary":"文｜曾柯（花名：毅丝 ) 蚂蚁集团高级工程师*负责蚂蚁集团的接入层建设工作* 主要方向为高性能安全网络协议的设计及优化 本文 10924 字，阅读 20 分钟 PART. 1 引言","tags":["SOFAStack"],"title":"深入 HTTP/3（2）｜不那么 Boring 的 SSL","type":"blog","url":"/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","wordcount":9435},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@林楠 提问：\n SOFARegistry 使用数据库做存储，未来有没有计划做一个简洁版，不依赖数据库？\n A：v6 使用存储主要是存放元数据而不是服务数据，元数据存储接口未来计划使用 jraft 作为存储。这也是 v5—\u0026amp;gt;v6 的过程中去掉的一个功能，因为在内部，引入 jraft 有一定运维成本，需要 operator 这种非标组件。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@jiaxin shan 提问：\n 想知道 Layotto 的成熟案例，有没有一些大公司进行使用呢？体量是多少？1.miscro-service 方向 2.FaaS 方向也有一些落地实例吗？\n A：目前蚂蚁在生产环境使用，另外也有某大厂准备上测试环境了。官网的 WASM 跑 FaaS 示例么？那个还没上过生产，还在探索阶段。\n 我理解目前像 FaaS、WASM 等更多是从社区角度，开源侧进行牵引，慢慢孵化一些场景？\n A：对，结合 WASM 做 FaaS 是开源社区探索方向；其他的 runtime、service mesh 属于生产需求驱动，更严肃一些。属于蚂蚁发起、社区共建，如果担心独裁，可以关注下 contributor 数、月活跃贡献者数这些指标，现在活跃贡献者有腾讯、同程等公司的朋友，3个 committor 都不是蚂蚁的。我们每周五有社区周会，你感兴趣可以来聊聊。钉钉群码：41585216\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 【2022 开源之夏】欢迎报名 SOFAStack 社区项目！\n 恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n 【2022 开源之夏】欢迎报名 MOSN 社区项目！\n 蚂蚁集团 Service Mesh 进展回顾与展望\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1653030000,"description":"SOFA Weekly | 我是开源人、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220520/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"27d18203e02fa487e39f1f9e1032271d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220520/","publishdate":"2022-05-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220520/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | 我是开源人、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220520/","wordcount":1274},{"author":"石建伟","categories":"SOFAStack","content":" 一、引言 继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么，值此 SOFAStack 开源 4 周年之际，欢迎大家一起进入《蚂蚁集团 Service Mesh 进展回顾与展望》章节探讨交流。\n本次交流将以如下次序展开：\n二、蚂蚁集团 Service Mesh 发展史 2018 年 3 月份蚂蚁集团的 Service Mesh 起步，MOSN 数据面诞生，起步就坚持走核心开源，内部能力走扩展的道路。 2019 年 6.18 我们在三大合并部署应用上接入了 MOSN 并且顺利支撑了 6.18 大促。 2019 年双 11 蚂蚁所有大促应用平稳的度过双大促。 2020 年 MOSN 对内沉稳发展把接入应用覆盖率提升至 90%，对外商业化开始展露头角。蚂蚁集团全站 90% 标准应用完成 Mesh 化接入。在商业版本中，SOFAStack“双模微服务”架构也在江西农信、中信银行等众多大型金融机构成功落地实践。 2021 年随着 Mesh 化的逐步成熟，多语言场景的逐步丰富，Mesh 化的对中间件协议的直接支撑带来的扩展性问题也逐步凸显，Dapr 的应用运行时概念也逐步崛起，这一年我们开源了 Layotto，期望通过对应用运行时 API 的统一来解决应用和后端中间件具体实现耦合的问题，进一步解耦应用和基础设施，解决应用在多云运行时的厂商绑定问题。 2022 年随着 Mesh 化落地的基础设施能力逐步完善，我们开始考虑 Mesh 化如果给业务带来更多价值，在 Mesh 1.0 时代，我们把中间件相关的能力尽可能做了下沉，提升了基础设施的迭代效率，在 Mesh 2.0 时代，我们期望能有一种机制可以让业务侧相对通用的能力，也可以做到按需下沉，并且具备一定的隔离性，避免下沉的能力影响 Mesh 数据代理主链路。这部分将在看未来部分做一些介绍。 图示的方式简诉一下 Service Mesh 架构演进的几个阶段：\n SOA 时代，中间件的客户端均直接集成在业务进程内： Mesh 化阶段一：中间件能力下沉，应用和基础设施实现部分解耦： 应用运行时阶段：将应用和具体基础设施的类型解耦，仅依赖标准 API 编程： 三、东西向流量规模化挑战 Mesh 化后的数据面 MOSN 承载了应用间非常核心的东西向通信链路，目前在蚂蚁集团内部覆盖应用数千，覆盖容器数十W+，海量的规模带来了如长连接膨胀、服务发现数据量巨大、服务治理困难等问题。接下来我们来聊一聊我们在演进的过程中遇到并解决掉的一些经典问题。\n3.1 长连接膨胀问题 在海量规模的应用背后存在着复杂的调用关系，部分基础性服务被大部分应用所依赖，由于调用方全连服务提供方的机制存在，一个基础性服务的单 Pod 需要日常承载近 10W 长连接，单机 QPS 一般还是有上限的，我们以 1000 QPS 的 Pod 举例，10w 长连接的场景下，每条长连接上的 QPS 是非常低的，假设所有连接的请求均等，平均每条长连接每 100s 仅有一次请求产生。\n为了保证长连接的可用性，SOFA RPC 的通信协议 Bolt 有定义心跳包，默认心跳包是 15s 一次，那么一条长连接上的请求分布大概如下图所示：\n在上诉场景中，一条长连接上，心跳包的请求数量远大于业务请求的数量，MOSN 在日常运行中，用于维护长连接可用句柄持有内存的开销，还有心跳包发送的 CPU 开销，在海量规模集群下不可忽视。\n基于以上问题，我们找到了两个解法：\n 在保证连接可用的前提下减少心跳频率 在保证负载均衡的前提下降低应用间的连接数 3.1.1 心跳退避 由于心跳的主要作用是尽可能早的发现长连接是否已不可用，通常我们认为经过 3 次心跳超时即可判定一条长连接不可用，在一条长连接的生命周期里，不可用的场景占比是非常低的，如果我们把长连接的检测周期拉长一倍就可以减少50%的心跳 CPU 损耗。为了保障检测的及时性，当出现心跳异常（如心跳超时等）场景时，再通过降低心跳周期来提高长连接不可用时的判定效率，基于以上思路我们设计了 MOSN 里的长连接心跳退避策略：\n 当长连接上无业务请求且心跳正常响应时，逐步将心跳周期拉长 15s -\u0026amp;gt; 90s 当长连接上出现请求失败或心跳超时的场景时，将心跳周期重置回 15s 当长连接上存在正常业务请求时，降级本次心跳周期内的心跳请求 通过以上心跳退避的手段，MOSN 的常态心跳 CPU 消耗降低至原来的 25%。\n3.1.2 服务列表分片 从心跳退避的优化可以看出，在海量长连接的场景下，单长连接上的请求频率是很低的，那么维护这么多长连接除了对负载均衡比较友好之外，其他的收益并不大，那么我们还有另外一个优化方向，就是减少客户端和服务端之间建立的长连接数量。\nMOSN 使用一致性哈希的策略对服务端机器进行分组：在客户端的内存中，首先将全量的服务端机器列表加入到一致性哈希环中，然后基于配置计算预期分片情况下的机器列表数 N，随后根据客户端机器 IP，从一致性哈希环中获取 N 个机器列表作为本机器的分片列表。每个客户端计算的哈希环都是一样的，不同的机器 IP 使得最终选择的机器分片列表是不同的。实现了不同客户端机器持有不同的服务端集群分片的效果。\n通过对服务列表的分片优化，客户端向服务端建立的长连接数量急剧减小，在 6w 长连接且采用 50% 的负载均衡分片的场景下：单机 CPU 降低约 0.4 Core，内存降低约 500M。\n3.2 海量服务发现问题 MOSN 的服务发现能力没有使用 Pilot，而是在内部直接和 SOFARegistry（服务注册中心） 对接，使用这种架构的原因之一就是 RPC 的接口级服务发现，节点的 Pub、Sub 量巨大，海量应用的频繁运维产生的节点变更推送对 Pilot 的性能和及时性挑战都很大，社区有使用 Pilot 在稍大规模下做 CDS 下发的过程中也发现非常多的性能问题并提交 PR 解决，但对于蚂蚁集团一个机房就有 200W Pub，2000W Sub 的规模下，Pilot 是完全无法承载的。SOFARegistry 的架构是存储和连接层分离，存储为内存分片存储，连接层也可以无限水平扩容，在内部海量节点变更下也能实现秒级变更推送。\n虽然 SOFARegistry 的推送能力没什么问题，不过海量节点变更后产生的推送数据，会导致 MOSN 内有大量的 Cluster 重构，列表下发后到 Cluster 构建成功的过程中，会有大量的临时内存产生，以及 CPU 计算消耗。这些尖刺型内存申请和 CPU 占用，是可能直接影响请求代理链路稳定性的。为了解决这个问题，我们也考虑过两个优化方向：\n SOFARegistry 和 MOSN 之间把全量推送改造为增量推送 服务发现模型从接口级切换为应用级 其中第一点能带来的效果是每次列表推送变化为原推送规模的 1/N，N 取决于应用变更时的分组数。第二点能带来的变化是更加明显的，我们假设一个应用会发布 20个接口，100个应用的 Pod 产生的服 …","date":1652770800,"description":"继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么，值此 SOFAStack 开源 4 周年之际，欢迎大家一起进入《蚂蚁集团 Service Mesh 进展回顾与展望》章节探讨交流。","dir":"blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8c0eeb7a88e858fcfef4b4c9824ebb3f","permalink":"https://sofastack.github.io/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","publishdate":"2022-05-17T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","summary":"一、引言 继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么","tags":["SOFAStack","Service mesh"],"title":"蚂蚁集团 Service Mesh 进展回顾与展望","type":"blog","url":"/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","wordcount":5542},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFAMeetup 成都站-云原生技术交流专场\n 活动时间：2022 年 05 月 14 日（周六）14:00-18:00\n 活动形式：线上直播\n 资料下载：\n 《Nydus-面向下一代的容器镜像》\n《云原生应用配置代码化实践》\n活动回顾 直播回放：\nNydus-面向下一代的容器镜像\n云原生应用配置代码化实践\n活动议程 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1652511600,"description":"SOFAMeetup 成都站-云原生技术交流专场","dir":"activities/sofa-meetup-15/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f637fdc7cae0e17bb6c6cf1302cd7f80","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-15/","publishdate":"2022-05-14T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-15/","summary":"概要 活动主题：SOFAMeetup 成都站-云原生技术交流专场 活动时间：2022 年 05 月 14 日（周六）14:00-18:00 活动形式：线上直播 资料","tags":["SOFA"],"title":"【活动回顾】《SOFAMeetup 成都站-云原生技术交流专场》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-15/","wordcount":211},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@曹飞提问：\n MOSN 集成 prometheus 是怎么使用呢？看到读取相应配置，是在自定义配置里面吗？\n A：你可以自定义收集指标，然后通过 promoetheus 格式输出。在配置加这个 metric 的就行了。https://github.com/mosn/mosn/blob/f3248bf2ed6c5d13635e8ce4af921f665ccdf96c/configs/mosn_config_dev.json#L69\n「MOSN」：https://github.com/mosn\n@沈冰 提问：\n SOFAArk 2.0 怎么创建 ark-plugin? 使用的场景是做类隔离。\n A：当前这个还和 1.0 的使用方式一致的，完全按照 1.0 的方式来。https://developer.aliyun.com/article/625338\n「SOFAArk」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto v0.4.0 版本 发布 Layotto v0.4.0 版本，主要变更如下：\n1.文件能力增加了七牛云 oss、hdfs、腾讯云 oss 的实现；\n同时增加了Java SDK 的实现\n2.支持 API 插件和自定义组件能力\n3.支持 SkyWalking\n4.支持基于内存的和 mongo 的分布式锁和分布式自增 ID\n5.支持 secret 接口\n6.支持 Dapr 的 state、InvokeService、InvokeBinding API\n7.优化了当前 CI 流程\n7.修复及优化若干 bug\n详细发布报告:https://github.com/mosn/layotto/releases/tag/v0.4.0\n本周推荐阅读 【2022 开源之夏】欢迎报名 SOFAStack 社区项目！\n 恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n SOFAServerless 体系助力业务极速研发\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1652425200,"description":"SOFA Weekly | Layotto v0.4.0 版本发布、开源之夏项目讲解、本周 Contributor","dir":"blog/sofa-weekly-20220513/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0d42b166bf83ba9a3cc657d29b0b64b2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220513/","publishdate":"2022-05-13T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220513/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto v0.4.0 版本发布、开源之夏项目讲解、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220513/","wordcount":1311},{"author":"Webster-Yang","categories":"SOFAStack","content":" 背景 SOFARgeistry 分为 Session、Data 和 Meta 三个模块。Session 模块用于 client 交互，可以横向扩容，可以承受大量 client 连接请求；Data 是数据存储模块，利用 slot 分片机制来均衡负载，使用备份来解决高可用问题；Meta 是 Session、Data 的注册中心，采用分布式锁来选举 leader，本文详细阐述 Meta 如何选主。\n基于 MySQL 的分布式锁 MySQL 表\ndrop table if exists distribute_lock; CREATE TABLE distribute_lock ( id bigint(20) NOT NULL AUTO_INCREMENT primary key, data_center varchar(128) NOT NULL, lock_name varchar(1024) NOT NULL, owner varchar(512) NOT NULL, duration bigint(20) NOT NULL, term bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT \u0026#39;任期\u0026#39;, term_duration bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT \u0026#39;租期\u0026#39;, gmt_create timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, gmt_modified timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_data_center_lock` (`data_center`, `lock_name`), KEY `idx_lock_owner` (`owner`) ); 表的增改查等操作\npublic interface DistributeLockMapper { /** * query by dataCenter and lockName * * @param dataCenter * @param lockName * @return */ public DistributeLockDomain queryDistLock( @Param(\u0026amp;quot;dataCenter\u0026amp;quot;) String dataCenter, @Param(\u0026amp;quot;lockName\u0026amp;quot;) String lockName); /** * compete lock, it will throw exception if lockName existed * * @param lock */ public void competeLockOnInsert(DistributeLockDomain lock) throws Exception; /** * compete lock with cas * * @param competeLock * @return */ public void competeLockOnUpdate(FollowCompeteLockDomain competeLock); /** renew lock last update time */ public void ownerHeartbeat(DistributeLockDomain lock); /** force reset owner and duration */ public void forceRefresh(DistributeLockDomain lock); } 整体流程 step1：启动时创建锁记录，\n\u0026amp;lt;insert id=\u0026amp;quot;competeLockOnInsert\u0026amp;quot; parameterType=\u0026amp;quot;com.alipay.sofa.registry.jdbc.domain.DistributeLockDomain\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;![CDATA[ INSERT /*+ QUERY_TIMEOUT(2000000) */ INTO distribute_lock ( data_center, lock_name, owner, duration, gmt_create, gmt_modified, `term`, `term_duration` ) VALUES ( #{dataCenter}, #{lockName}, #{owner}, #{duration}, NOW(3), NOW(3), 1, 0 ) ON DUPLICATE KEY UPDATE lock_name = #{lockName} ]]\u0026amp;gt; \u0026amp;lt;/insert\u0026amp;gt; step2：leader 每秒提交心跳，更新表\n\u0026amp;lt;update id=\u0026amp;quot;ownerHeartbeat\u0026amp;quot; parameterType=\u0026amp;quot;com.alipay.sofa.registry.jdbc.domain.DistributeLockDomain\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;![CDATA[ update /*+ QUERY_TIMEOUT(2000000) */ distribute_lock set owner = #{owner}, gmt_modified = NOW(3), `term_duration` = (`term_duration` + 1) where data_center = #{dataCenter} and lock_name = #{lockName} and owner = #{owner} and term = #{term} and `term_duration` = #{termDuration} and timestampdiff(SECOND, gmt_modified, NOW()) \u0026amp;lt; #{duration}/1000 ]]\u0026amp;gt; \u0026amp;lt;/update\u0026amp;gt; step3：follower 每秒判断锁是否过期，如果过期，则 cas 竞选 leader\npublic DistributeLockDomain onFollowWorking(DistributeLockDomain lock, String myself) { /** as follow, do compete if lock expire */ if (lock.expire()) { LOG.info(\u0026amp;quot;lock expire: {}, meta elector start: {}\u0026amp;quot;, lock, myself); distributeLockMapper.competeLockOnUpdate( new FollowCompeteLockDomain( lock.getDataCenter(), lock.getLockName(), lock.getOwner(), …","date":1652252400,"description":"源码解析｜registry meta选主","dir":"projects/sofa-registry/code-analyze/code-analyze-registry-meta/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1ed6ac5b5251011241bc8ec391f4e720","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","publishdate":"2022-05-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","summary":"背景 SOFARgeistry 分为 Session、Data 和 Meta 三个模块。Session 模块用于 client 交互，可以横向扩容，可以承受大量 client 连接请求；Data 是数据存储模块，","tags":["“源码解析”"],"title":"源码解析｜registry meta 选主","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","wordcount":1236},{"author":"赵真灵、刘晶","categories":"SOFAStack","content":" 文｜赵真灵（花名：有济）蚂蚁集团技术专家、刘晶（花名：飞廉） 蚂蚁集团技术专家\n以下内容整理自 SOFAStack 四周年的分享\n本文 5332 字 阅读 10 分钟\nSOFAServerless 研发运维平台是蚂蚁集团随着业务发展、研发运维的复杂性和成本不断增加的情况下，为帮助应用又快又稳地迭代而研发。从细化研发运维粒度和屏蔽基础设施的角度出发，演进出的一套解决方案。\n核心方式是通过类隔离和热部署技术，将应用从代码结构和开发者阵型拆分为两个层次：业务模块和基座，基座为业务模块提供计算环境并屏蔽基础设施，模块开发者不感知机器、容量等基础设施，专注于业务研发帮助业务快速向前发展。\nPART. 1 背 景 当前 Serverless 的发展有两个演进方向，一个是从面向函数计算的架构往在线应用演进，另一种是面向在线应用的架构往类函数计算方向演进。\nSOFAServerless 体系选择了后者，是从面向应用研发运维过程中遇到的一些问题展开的。在应用架构领域，不可避免的问题是应用随着业务的复杂度不断增加，研发运维的过程中的问题会不断暴露出来。\n首先我们先看一下对于普通应用，研发和运维过程中的流程是什么样的？\n如图所示，从需求到设计、开发、线下测试，再到发布线上的研发运维不断反馈、循环迭代的过程。可以简化为开发同学提交代码到代码仓库，在线下做并行的验证测试，测试通过之后在线上发布，发布过程是串行的，只能够有一个发布窗口，这样的过程在应用体量业务还不太复杂的情况下问题，并不是很明显。\n但当业务复杂度不断增加，普通应用迭代过程在会出现一些新的问题，如下图：\n1.管理成本高：需求管理、代码管理、人员管理\n2.时间成本高：线上验证与发布互相阻塞；单次启动慢\n3.变更风险高： 一次变更涉及所有代码；一次变更涉及所有机器\n4.可扩展性不够\n另外，由于这些问题是因为多业务单元与研发任务耦合在某些单点上导致的，这些研发运维的成本随着业务的复杂度，呈现出指数增长的特点。\nPART. 2 SOFAServerless 研发运维体系 解决方案介绍\n对于这些问题，业界已经发展并演进出了多种应用架构，从单体架构 -\u0026amp;gt; 垂直架构 -\u0026amp;gt; SOA 架构 -\u0026amp;gt; 分布式微服务架构 -\u0026amp;gt; 服务网格架构等，我们分析这些演进过程为解决遇到的研发运维问题提出 SOFAServerless 研发运维体系，主要的核心思路是：\n 研发运维力度的细化 通过细化的方式，让多人协作之间不互相 block；\n迭代的范围变小，速度变快。\n 屏蔽基础设施 屏蔽基础设施，让业务开发同学只关注代码服务和流量。\n对于这两点，我们采用了 SOFAArk ClassLoader 类隔离和热部署能力，将应用拆分成基座和模块。\n基座和模块 从这张图里面可以看到我们拆分的形态，把一个普通的 JVM 应用拆出多个模块，进一步对模块进行了一些分工：基座和模块，对应的研发人员也分为基座开发者和模块开发者。\n基座沉淀通用的逻辑，为模块提供计算和环境，并会模块开发者屏蔽基础设施，让模块开发者不需要关心容量、资源、环境。各个模块是独立的代码仓库，可以进行独立的研发运维，这样研发运维粒度得到细化，并且由于基座为模块屏蔽了环境与基础设施，模块开发者可以专注业务开发，提高整体效率。\n如何共享和通信 应用如果只是做拆分，没有共享和通信能力是不完整的方案也难以解决实际问题。对于共享和通信，基座作为共享的一层，能帮模块预热 RPC 数据库缓存通用类、通用方法、通用逻辑，可以供安装一些模块去复用。这样模块实现的比较轻，所以模块的部署密度也可以做得很高。\n对于模块通信，当前模块之间的通信可以支持任意的通信方式，比如说基座调模块、模块调基座模块和模块之间调用。由于模块通信是 JVM 内跨 ClassLoader 调用，与普通 JVM 内方法调用增加了序列化与反序列化的开销，目前这部分开销已经优化到约等于 JVM 内部的方法调用。\n在这一能力建设之后，可以较大降低模块的接入改造成本并扩大可适用的业务范围。\n如何解决业务痛点 管理成本\n相较于原来的研发模式，研发人员拆分成不同小组，代码仓库也拆分出多个模块仓库，并且可以独立并行的发布到线上，整个 pipelien 都可以做到独立进行。\n如此一来，需求管理、代码管理、人员管理的成本就得到下降了，线上发布过程中也不会再有互相阻塞的问题存在。\n当然这些成本下降不代表这些问题完全没有了，只是从原来的指数增长转变成了这种线性增长。随业务的复杂度不断增加，它的收益会更加的明显。\n时间成本 相对于普通应用的镜像构建需要 3 分钟，发布需要镜像下载、启动、挂载流量大概 3 分钟，总共平均需要 6 分钟；模块构建只需要 10 秒，启动大概 1~10 秒 （模块大小可大可小，对于较小的模块，速度可以做到毫秒级别） 。\n把一次发布耗时从原来的 6 分钟下降到 15 秒，一次迭代从原来 2 周下降到了 2 天，最快可以 5 分钟上线的。\n可扩展性 对于线上集群的部署形态，不同的机器上部署的模块不尽相同。例如对于模块 1，只安装在了第一第二台机器上，那么模块升级时只会涉及到这两台机器本身，变更的机器范围就比较小了。另外，模块 1 如果要扩容的话，可以从集群内筛选出较空闲的机器进行模块热部署即可，一般也就是 10s 级别，所以能做大快速的水平扩展能力。\n变更风险 对于一次模块的升级变更，只会涉及模块自身的代码本身不会设计整个应用代码。模块变更需要更新的机器也只是模块安装过的机器本身，不会涉及到整个集群，所以变更范围大大缩小，变更风险也相较普通应用能得到明显减少。\n高可用和配套能力 SOFAServerless 体系在解决业务研发运维痛点基础上，建设了高可用和配套的能力。\n资源隔离 资源隔离体现在单个 JVM 内部的，这里采用了我们公司内部 AliJDK 多租户隔离能力，每一个模块可以指定自己的资源使用的上限。\n比如说，其中一个模块的逻辑有一些问题，消耗的资源比较大，不会影响到其他的模块，相当于得到了故障的隔离。\n流量隔离能力 对于单个集群内部，我们做了一些精细化的流量路由。主要是因为发服务时能够动态增加 tag，流量路由时能够配一些规则，推送到 MOSN、Layotto 里，能让流量根据对应的 tag 进行一些精细化路由，这样就具备了流量的精细化路由和流量隔离能力。\n可观测性能力与变更防御能力 具备模块粒度的健康检查、资源监控、日志监控还有排障能力，在此基础上建设模块粒度的变更防御。\n一个模块可以同时存在多个版本，可以做一些快速的 A/B 测试、灰度、回滚这些能力。\nPART. 3 业务的落地形态** SOFAServerless 发展到现在，已经在蚂蚁内部接入了 700 多个 Java、nodejs 应用，基本涵盖了蚂蚁所有业务线，支撑了 1 万多次的完整的生产研发迭代。线下可以做到秒级发布，支付宝应用内很多业务就是跑在 SOFAServerless 上的，比如投放展位、公益游戏、营销玩法。\n去年 SOFAServerless 成功支撑了 618、双 12、五福等重量级大促和活动，经受住了大流量高并发场景下的考验，托管在 SOFAServerless 的资 …","date":1652166000,"description":"SOFAServerless 体系助力业务极速研发","dir":"blog/sofaserverless-system-for-speedy-business-development/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"760d9079310bd5202d52c369c1603bec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","publishdate":"2022-05-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","summary":"文｜赵真灵（花名：有济）蚂蚁集团技术专家、刘晶（花名：飞廉） 蚂蚁集团技术专家 以下内容整理自 SOFAStack 四周年的分享 本文 5332 字 阅读 10 分钟 SOFAServerless 研发运维平台是蚂","tags":["SOFAStack"],"title":"SOFAServerless 体系助力业务极速研发","type":"blog","url":"/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","wordcount":5533},{"author":"范明柯","categories":"SOFAStack","content":" 前言 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析\n 一、架构流程图 二、订阅流程 以客户端首次订阅，且服务发布方已注册的场景为例，订阅流程主要分为三步，\n 客户端发起订阅 session server 处理订阅任务，从缓存（或 data server）拉取地址列表 向客户端推送地址列表 2.1 客户端发起订阅 客户端发起订阅的方式是异步的，首先将订阅注册的任务添加到客户端的内存队列中。\n2.2 session server 处理订阅请求 session server 接收到订阅注册任务后，主要是通过 SessionRegistry#regsiter 方法处理的，判断当前是服务消费方，添加到订阅者缓存中； case SUBSCRIBER: Subscriber subscriber = (Subscriber) storeData; // if (!sessionInterests.add(subscriber)) { break; } sessionRegistryStrategy.afterSubscriberRegister(subscriber); break; 触发RegProcessor#fireOnReg方法，将订阅者放入buffer中，参考源码如下： boolean fireOnReg(Subscriber subscriber) { final String dataInfoId = subscriber.getDataInfoId(); // 从若干个BufferWorker数组找到其中一个 BufferWorker worker = indexOf(subscriber.getDataInfoId()); // 将dataInfoId和subscriber存到BufferWorker线程中的subMap中 // subMap的key为dataInfoId，value为SubBuffer SubBuffer buffer = worker.subMap.computeIfAbsent(dataInfoId, k -\u0026amp;gt; new SubBuffer()); return buffer.add(subscriber); } 2.3 session server 拉取地址列表 BufferWorker 线程循环处理 map 缓存中的订阅注册任务，处理流程如下：\n 从 worker 的 subMap 取出所有 dataInfoId 和订阅者列表，并对每个 dataInfoId 分别处理 通过 RegProcessor#processBuffer 方法处理每个 dataInfoId 和对应的订阅者 int processBuffer(Ref ref, int hitSize) { List\u0026amp;lt;Subscriber\u0026amp;gt; subscribers = Lists.newArrayListWithCapacity(hitSize); for (Map.Entry\u0026amp;lt;String, Subscriber\u0026amp;gt; e : ref.subscriberMap.entrySet()) { final Subscriber sub = e.getValue(); // 若订阅者已经推送过，直接忽略 if (!sub.hasPushed()) { subscribers.add(sub); } // 这里因为subscriberMap是引用，没有锁保护，所以sub可能已经被新的subscriber替换掉 // try to remove the sub, but subs maybe changes ref.subscriberMap.remove(sub.getRegisterId(), sub); } if (!subscribers.isEmpty()) { // 从缓存中获取dataInfoId的地址列表，并推送给subscribers regHandler.onReg(ref.dataInfoId, subscribers); } // 返回推送地址列表的订阅者数量 return subscribers.size(); } 通过 FirePushService#getDatum 方法从缓存中获取地址列表。该缓存使用 Guava Cache 的LoadingCache，当缓存中没有 dataInfoId 的地址列表时，会自动从 data server 获取地址列表，并放在缓存中。\n 通过 FirePushService#processPush 方法将地址列表推送给所有订阅者\n 首先通过 firePush 方法将 PushTas k放入 buffer 等待 PushTaskBuffer.BufferWorker 线程异步处理任务 2.4 session server 推送地址列表 PushProcessor 初始化时默认创建 4 个 PushTaskBuffer.BufferWorker 线程； BufferWorker 线程循环执行 watchBuffer 方法，将 worker 中缓存的过期任务删除后进行处理，具体逻辑见下边源码； int watchBuffer(BufferWorker worker) { int bufferedSize = worker.bufferMap.size(); if (bufferedSize \u0026amp;gt;= MAX_BUFFERED_SIZE) { LOGGER.warn(\u0026amp;quot;arrived max buffered size: buffered={}\u0026amp;quot;, bufferedSize); } // 获取推送任务 List\u0026amp;lt;PushTask\u0026amp;gt; pending = worker.transferAndMerge(); int count = 0; for (PushTask task : pending) { // 将任务放进线程池执行 if (task.commit()) { count++; } } if (pending.size() \u0026amp;gt; 0 || count \u0026amp;gt; 0) { LOGGER.info(\u0026amp;quot;buffers={},commits={}\u0026amp;quot;, pending.size(), count); } return count; } 推送地址列表给客户端。 三、发布流程 服务发布流程主要分为下面5步：\n 客户端服务注册 session server 处理服务发布请求 data server 保存服务注册数据，并生成数据变更通知 session server 接收数据变更通知，拉取数据 session server 推送地址列表 3.1 服务注册 客户端进行发布注册，与上面客户端订阅的逻辑一样，都是先将请求放在队列里，等待异步处理，此处不再赘述。\n3.2 session server 处理服务发布请求 SessionRegistry#register 方法判断请求来自服务发布方； …","date":1652079600,"description":"源码解析｜发布订阅推送","dir":"projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","fuzzywordcount":3100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"981d3695a0bbf202fbb64b22687b1f25","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","publishdate":"2022-05-09T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","summary":"前言 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析 一、架构流程图 二、订阅流程 以客户端首次订阅，且服务发布方已注册的场景为例，订阅流程主要分为三步， 客户端发起订","tags":["“源码解析”"],"title":"源码解析｜发布订阅推送","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","wordcount":3020},{"author":null,"categories":"SOFA Weekly","content":" 开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2022 年，SOFAStack 和 MOSN 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2022”，为大家准备了六个任务，涉及 Cloud Native、Micro Service、Distributed System、Kubernetes、Container 等多个领域。\n活动规则 进入：https://summer-ospp.ac.cn/#/homepage\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\n项目任务 1.SOFARegistry 客户端负载均衡\nSOFARegistry 的客户端目前采用长连接与其中一台 Session 相连，随后会用这根链接注册和订阅服务，在注册中心进行运维期间，客户端会断链重连到别的机器上，经过一轮滚动升级，就会造成 Session 上链接分布的不均衡，一是数据不均衡，二是推送压力不均衡，严重的时候会造成单机热点，影响推送的效率。\n由于长连接快速检测节点宕机的机制，主动断链会造成节点数据下线，因此客户端链接的稳定性也是一个很重要的考虑。\n对服务发现来说，发布和订阅对链接稳定性的要求不同：\n 对发布，链接断开会造成服务数据下线\n 对订阅，会造成轻微的数据推送延迟，延迟时间通常是重连间隔\n 项目社区导师：dzdxdzidaxie@gmail.com\n2.增强 layotto-java-sdk 和 layotto-spring-boot\n项目编号：2295a0213\n任务难度：基础/Basic\n1.增强 Layotto 的 java-sdk 的功能，使其与 go-sdk 对齐。现在的 java-sdk 有 file、lock、pubsub、sequencer、state 的 API，缺少 secret、config 等 API。\n 完善 layotto-sdk-springboot, 将 Layotto 的更多功能集成进 spring-boot。layotto-sdk-springboot 的设计目标是帮助 spring-boot 的用户低成本接入 Layotto，比如用户在代码中添加一个 Java 注解后，就能方便的进行消息监听、收到新消息后自动调用方法。\n 在 layotto-sdk-springboot 的基础上，开发 layotto-sdk-sofaboot, 方便 SOFABoot 用户使用 Layotto。\n 项目社区导师：张立斌1098294815@qq.com\n3.Layotto 中实现 ceph 文件系统，同时打通 SOFABoot\n项目编号：2295a0214\n任务难度：基础/Basic\n用 ceph 实现 Layotto 的 file API 组件，并通过 SOFABoot 调通。\n 首先熟悉 Layotto 的架构设计，基于现在的 file 接口实现 ceph 文件系统。（此处需要调研 Layotto 的 file 组件的可移植性以及 ceph 文件系统，判断当前的 Layotto 接口能否满足 ceph 文件系统）\n 通过 SOFABoot 和 Layotto 打通，可以通过 SOFABoot 应用调通 Layotto 的 file 接口。\n 项目社区导师：wenxuwanwangwx_junction@163.com\n4.SOFATracer upgrade opentracing api version \u0026amp;amp; adapter opentelemetry api\n项目编号：2295a0196\n任务难度：进阶/Advanced\nCurrently, sofa-tracer relies on the openTracing version 0.22.0. This version has been out of date for a long time and we need to update to the official recommended stable version. In addition, we need to provide an API layer to accommodate OpentElemetry.\nTasks:\n1、upgrade opentracing version torelease-0.33.0\n2、adapter https://opentelemetry.io/docs/migration/opentracing/\n3、provide intergration doc and guides\n项目社区导师：卫恒（宋国磊）glmapper_2018@163.com\n5.为 MOSN 适配社区 Proxy-Wasm v2 开源规范\n项目编号：22f080190\n任务难度：进阶/Advanced\nWebAssembly(Wasm) 是近几年从 Web 领域诞生，并快速出圈的一项虚拟机指令格式，是一种可移植的、语言无关并兼容 Web 的全新格式，支持在浏览器和非 Web 环境运行不同语言编写的应用程序。\nMOSN 是一款主要使用 Go 语言开发的网络代理 (类似 Envoy、Nginx)，融合了大量云原生通用插件，为服务提供了多协议、模块化、智能化、安全的代理能力。\n如何为这些插件提供一个安全隔离的运行环境，甚至支持不同语言编写的插件，成为了一个非常具有挑战性的课题。Wasm 技术和 Proxy-Wasm 规范的诞生为解决上述问题提供了一种全新的思路。\n本题目将基于 MOSN 中已有的 Wasm 框架，适配开源社区专门为网络代理场景提出的 Proxy-Wasm v2 规范，使 MOSN 具备运行符合 v2 规范的 Wasm 插件的能力。\n项目社区导师：叶永杰yongjie.yyj@antgroup.com\n6.Layotto 集成 Istio\n项目编号：22f080198\n任务难度：进阶/Advanced\n1.Istio 是 ServiceMesh 方向上一个非常火热的解决方案，默认使用 envoy 作为数据面。\n MOSN 作为一个对标 envoy 的另一种数据面实现，也可以跟 Istio 集成，作为 envoy 的一种替代方案。\n Layotto 作为 Application Runtime 的一种实现，基于 MOSN 开发，期望可以结合 Service Mesh 跟 Application Runtime 两种思想。\n 既然 Istio 可以集成 MOSN ，且 Layotto 跟 MOSN 是一体的，因此本次的任务是把 Layotto 作为数据面跟 Istio 进行集成，以服务调用为例，在应用通过 Layotto …","date":1651906800,"description":"【2022 开源之夏】欢迎报名 SOFAStack 社区和 MOSN 社区项目！","dir":"blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"38cfc44c56af96fa7b7700c470ce5931","permalink":"https://sofastack.github.io/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","publishdate":"2022-05-07T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["SOFA Weekly"],"title":"【2022 开源之夏】欢迎报名 SOFAStack 社区和 MOSN 社区项目！","type":"blog","url":"/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","wordcount":2100},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@尚之 提问：\n SOFARegistry 和应用绑定有多深，Serverless 场景下有没有更动态的方案和应用解绑？\n A：其实不需要和应用进行绑定，更准确的说法是节点级的服务发现，就算应用下面每个节点之间发布的服务不一样，应用级的这个方案也是可以支持的。而且目前蚂蚁的 Serverless 的场景实际上已经是应用级了，只是对于业务 owner 没有感知。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@沄澈|che 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?\n A：要看 SerializerFactory 对 Localdatetime 的支持了。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 MOSN 1.0 发布，开启新架构演进\n HAVE FUN | SOFABoot 源码解析活动\n SOFARegistry 源码｜数据分片之核心-路由表 SlotTable 剖析\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1651820400,"description":"SOFA Weekly | 神奇技术、本周贡献者、新手任务","dir":"blog/sofa-weekly-20220506/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d89becc4edace0dc4e93d5a8b39f9e61","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220506/","publishdate":"2022-05-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220506/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 神奇技术、本周贡献者、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220506/","wordcount":1010},{"author":"周书伟","categories":"SOFAStack","content":" 源码解析：无损运维 SOFARegistry 是一个基于内存存储的分布式注册中心，数据是分散存储在各个节点，为了做到注册中心自身运维期间依然能够对外正常提供服务，需要进行节点下线快速感知和数据迁移。\n session 存储 client 发送的发布和订阅数据，由于 client 断连重放的特性，session 单机下线后 client 会重放数据到其他节点。\n data 会接收 session 发送的发布数据，data 单机下线后，meta 会通过 SlotTable 的变更把对应 Slot 的所有权移交其他 data，data 启动后会进行数据同步到达数据完整可对外提供服务的状态。\n session、data下线的过程，如何避免下线期间数据丢失和抖动 SessionServer 和 DataServer 下线的相关代码都位于各自 bootstrap 类的 dostop 方法中。\n首先讨论 SessionServer 的下线过程：\nprivate void doStop() { try { LOGGER.info(\u0026amp;quot;{} Shutting down Session Server..\u0026amp;quot;, new Date().toString()); stopHttpServer(); clientNodeConnectionHandler.stop(); // stop process disconnect event stopServer(); // stop http server and client bolt server before add blacklist // make sure client reconnect to other sessions and data gracefulShutdown(); stopDataSyncServer(); stopConsoleServer(); executorManager.stopScheduler(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Shutting down Session Server error!\u0026amp;quot;, e); } LOGGER.info(\u0026amp;quot;{} Session server is now shutdown...\u0026amp;quot;, new Date().toString()); } 从代码中可以看出，SessionServer 服务在下线时，首先会停掉 HttpServer，HttpServer 提供一系列 REST 接口，用于 dashboard 管理、数据查询等；然后停掉 clientNodeConnectionHandler，clientNodeConnectionHandler 是 Exchange 设置的一系列 ChannelHandler 之一，Exchange 作为 Client / Server 连接的抽象，负责节点之间的连接。gracefulShutdown 方法则是通知 Meta（元数据服务器）将本节点加入 Meta 的黑名单中。HttpServer 和客户端的 bolt Server 是在本节点加入黑名单前关停，以保证 client 已经重连到了其他 session 节点上。这样就保证了运维的 session 节点下线期间，client 的数据不会因为 session 节点的不可用，导致数据丢失和抖动。接下来又依次关停了 DataSyncServer，ConsoleServer。\nDataServer 下线过程的代码如下：\nprivate void doStop() { try { LOGGER.info(\u0026amp;quot;{} Shutting down Data Server..\u0026amp;quot;, new Date().toString()); gracefulShutdown(); stopHttpServer(); stopServer(); stopDataSyncServer(); stopNotifyServer(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Shutting down Data Server error!\u0026amp;quot;, e); } LOGGER.info(\u0026amp;quot;{} Data server is now shutdown...\u0026amp;quot;, new Date().toString()); } DataServer 的下线则和 Session 的下线有些区别，由于 DataServer 数据服务器，负责存储具体的服务数据，而且 Slot 均匀地分配给每个节点上，所以下线前需要检测 DataServer 上的插槽状态，所以 doStop 的方法中，首先调用了如下的优雅下线的方法，其中代码中的主要内容如下：\naddBlacklistRetryer.call( () -\u0026amp;gt; { LOGGER.info(\u0026amp;quot;[GracefulShutdown] add self to blacklist\u0026amp;quot;); metaServerService.addSelfToMetaBlacklist(); return true; }); addBlacklistRetryer.call( () -\u0026amp;gt; { if (fetchStopPushService.isStopPushSwitch()) { return true; } SlotTableStatusResponse statusResponse = metaServerService.getSlotTableStatus(); if (statusResponse.isProtectionMode()) { return true; } LOGGER.info(\u0026amp;quot;[GracefulShutdown] wait no slot\u0026amp;quot;); if (slotManager.hasSlot()) { throw new RuntimeException(\u0026amp;quot;current data server still own slot, waiting...\u0026amp;quot;); } return true; }); LOGGER.info(\u0026amp;quot;add data self to blacklist successfully\u0026amp;quot;); 首先节点通知 Meta 加入黑名单，stopmetaServerService.getSlotTableStatus() 获取节点上 SlotTable 的状态，当 Slot 重新分配给其他节点后，该 Data 节点才会成功加入黑名单，并进行接下来 HttpServer、DataSyncServer、NotifyServer 的下线动作。\n整体流程是 Data 上的 Slot 逐步迁移，期间仍然对外提供服务。\n迁移完成后主动从列表中剔除并设置节点黑名单并下线。\n以下图为例，假设要下线的节点是 DataServer-1： …","date":1651820400,"description":"源码解析｜无损运维","dir":"projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ffe7f76f483d5fbc2827a237b6c48093","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","publishdate":"2022-05-06T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","summary":"源码解析：无损运维 SOFARegistry 是一个基于内存存储的分布式注册中心，数据是分散存储在各个节点，为了做到注册中心自身运维期间依然能够对外正常提供服务，需要","tags":["“源码解析”"],"title":"源码解析｜无损运维","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","wordcount":3684},{"author":"朱德江","categories":"SOFAStack","content":" 文｜朱德江（花名：人德）\n蚂蚁集团技术专家 负责 MOSN 核心开发，关注云原生流量网关的演进\n以下内容整理自 SOFAStack 四周年的分享\n本文 5332字 阅读 10 分钟\nMOSN 1.0 发布 MOSN 是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源，经过双 11 大促几十万容器的生产级验证。\n经过 4 年的蓬勃发展，在 11 位 commiter，100 多个 contributor 和整个社区的共同努力下，经历 27 个小版本的迭代，MOSN 1.0 版本正式发布了。\n一个足够成熟稳定，有开源用户共建、有商业化落地、有社区，拥抱云原生生态的 MOSN 1.0 来了。\n除了在蚂蚁集团的全面落地，MOSN 在业界也有较广泛的应用，比如有工商银行的商业化落地，还有阿里云、去哪儿网、时速云等企业的生产实践。\n同时，随着 1.0 的发布，进入少年期的 MOSN 也将开启新一代 MOE 架构演进，奔向星辰大海。\n发展历史 MOSN 起源于 Service Mesh，原本在微服务之间的调用是通过比较重的 SDK 来完成的，当 SDK 升级的时候，需要应用配合一起升级，有比较强的打扰。\nMOSN 为了解决这一痛点，向着把 SDK 剥离出来的方向演进。在应用所在的 Pod 内，单独有一个运行 MOSN 的 sidecar，那么应用本身只需要跟 MOSN 去通讯，就可以完成整个的服务调用的流程。把 SDK 剥离出来，相当于 MOSN 作为一个独立的组件去演进，其演进过程对应用本身没有打扰。这在蚂蚁内部的收益其实是非常明显的。\n在整个演进的过程中，有两个比较深的体会：一个比较明显的是，有一个独立的 sidecar，可以去跟业务逻辑做解耦；另外一个标准化，在云原生的时代里，控制面和数据面被拆分为两个独立的组件，MOSN 作为数据面的组件，演进过程中要跟很多控制面的服务对接，这期间标准化是一个很重要的。在整个标准化的过程中，它并不像业务解耦那么直观，但是用的时间越长，对其越深有体会。\n现在 MOSN 已经在蚂蚁内部全面的铺开，部署有几十万 Pod，峰值 QPS 千万级。\nMOSN 的演进历程 2018 年： 开始创建；\n2019 年： 在双 11 完成了核心链路的覆盖，在 19 年底的时候，MOSN 开始独立运营；\n2020 年： 7 月份获得 Istio 官方的推荐。同时，MOSN 开启了商业化的探索，年底完成了江西农信的落地；\n2021 年： 对接了 Envoy、Dapr、WASM 生态，和主流的社区合作。同年 12 月份， 在工商银行完成了商业化的落地，树立了业界新标杆。\nMOSN 除了在蚂蚁内部全面铺开，以及商业化的落地实践，还有逐渐完善的社区。MOSN 社区目前有 11 个 Committer，其中超过 70% 是非蚂蚁的 Committer，有 100 多位的 Contributor，经过了 28 个小版本的迭代。MOSN 还有很多开源的用户，他们将 MOSN 在自己公司落地，也对 MOSN 有很多的贡献。\n社区除了在 MOSN 项目的贡献之外，还有对其他项目/社区的贡献，包括Holmes、BabaSSL、Proxy-Wasm 等项目，以及跟其他生态项目的对接。\n总体来说，MOSN 现在足够成熟稳定，有商业化的落地，有社区、有周边、有生态，所以我们选择这个时间点发布 MOSN 1.0 版本。\n1.0 的核心能力以及扩展生态 MOSN 1.0 版本标志性的成果是已经集成了 Istio 的 1.10 版本。\nMOSN 作为网络代理的软件，在核心转发方面已经支持了 TCP、UDP、透明劫持的模式。MOSN 所处在东西向网关场景下，有很多内部的、私有的非标协议，MOSN 除了支持 HTTP 标准协议以外，还有很重要的 XProtocol 框架，可以非常简单、方便支持私有的非标协议，内置的 Bolt、 Dubbo 协议，也是通过 XProtocol 框架来实现的。我们还支持了多协议的自动识别，也是在东西向流量网关里面比较核心的、比较特别的能力支持。\n后端管理和负载均衡是在网络代理情况下，比较基本的常规能力。MOSN 也支持了连接池、主动健康检查、各种各样的负载均衡的策略。\n在核心路由上，MOSN 支持基于 Domain 的 VirtualHost，引入了一个非常强大的变量支持，通过变量做复杂的路由规则，也支持了 Metadata 的分组路由。还有路由级别的超时、重试的配置，以及请求头、响应头的处理。\n简单来说，作为一个网络代理的平台，通用的核心能力 MOSN 都已经完全具备了。\n同时在网络代理的场景，通常需要做很多扩展，MOSN 的扩展生态做到了什么样的程度了呢？\nRPC 协议： 有 Dubbo 和 SOFABolt 的支持，同时基于 BabaSSL 做了国密的支持；\n控制面： MOSN 已经做了 Istio 的支持；\n注册中心： SOFARegistry；\n可观测性：Skywalking 以及 Holmes 针对 Go 运行时期间，资源使用异常的自动分析和诊断。\n在网关场景里，有很多的逻辑是需要做定制的。除了常规的用 Go 写一些 filter 扩展之外，还支持 Go Plugin 这种轻量级的模式，也支持 Proxy-Wasm 标准的 Wasm 扩展运行在 MOSN 中，服务治理方面也对接了 Sentinel。\nIstio 1.10 MOSN 会通过标准的 xDS 协议和 Istio 通讯，这是一个非常标准的使用方式，同时我们也在积极的参与标准的建设。\n我们在标准的制定过程中，积极提案参与讨论，比如说限流的和路由的 proto，也正是我们和 Istio 有非常多的合作，才能够获得 Istio 官方的推荐。\nMOSN 起源于 ServiceMesh 东西向流量的场景，我们经过了四年的努力，选择在今天这个时间点发布 MOSN 1.0 版本，作为一个成熟稳定、有商业化落地、有社区、有生态的一个版本呈现出来，我们欢迎更多的人来使用 MOSN，也欢迎大家一起来共建和成长。\n二、MoE 新架构 做这个的愿景初衷是什么？\n这样做的优势是什么？\nMoE 新架构的探索有什么新的进展？\n首先 Enovy 和 MOSN 是作为目前市面上的两个数据面，它们都各有特点， Enovy 是 C++写的，处理性能会比较高。MOSN 的研发性和效能高，有很好的生态。\nMoE 就是 MOSN 加 Enovy。我们希望能够做把两者的优势给融合起来，相互融合，各取所长，把高性能和高研发效能结合到一起，支持我们做大做强，走得更远。\nMoE 架构在 Enovy 的角度来看，MOSN 作为 Enovy 的一个插件扩展，在所有的 Enovy 的扩展方式里面，做一个横向的对比。\n1.首先第一个是 Lua\n嵌入式的脚本语言有比较强的优势，它操作简单。但是作为相对小众的语言，劣势也很明显——生态不好。我们目的是为了提高研发效能， Lua 无法让我们达到目标。\n2.WASM 是比较诱人的方案\nWASM 在发展初期，有很多东西还只是停留在愿景上。很多的语言支持不友好，以及 runtime 性能不够好，这都是很现实的痛点。\n3. …","date":1650956400,"description":"MOSN 1.0 发布，开启新架构演进","dir":"blog/mosn-1-0-released-starting-a-new-architectural-evolution/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6319d8cdb62702760f6c4d04c3f996a7","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","publishdate":"2022-04-26T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","summary":"文｜朱德江（花名：人德） 蚂蚁集团技术专家 负责 MOSN 核心开发，关注云原生流量网关的演进 以下内容整理自 SOFAStack 四周年的分享 本文 5332字 阅读 10 分钟 MOSN 1.0 发布","tags":["SOFAStack"],"title":"MOSN 1.0 发布，开启新架构演进","type":"blog","url":"/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","wordcount":4640},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@黄昊 提问：\n 同一个网格里，不同的 Pod 可以注入不同版本的 Sidecar 吗？\n A：去改 inject 程序可以实现，相关资料可以搜索：K8s准入控制。\n 利用 webhook，动态匹配返回 sidecar-image 是这个意思吗？看代码，貌似 Istio 里面可以通过sidecar.istio.io/proxyImage 这个 annotation 来指定。\n A：是的。\n「MOSN」：https://github.com/mosn\n@service mesh 提问：\n gateway 有开源计划吗？\n A：有考虑，但是目前还没有具体的时间点，可以看下这个初期的 issue，有个demo.\nhttps://github.com/mosn/mosn/issues/1563\n「MOSN」：https://github.com/mosn\n@Tom 提问：\n Wasm 还有啥好玩的待实现的特性吗？\n A：目前关于 Wasm 主要想尝试两个方向：\n 以 Wasm 作为用户开发函数的载体，可以参考下：https://github.com/mosn/layotto/issues/191\n 以 Wasm 作为开发 Layotto 各个组件的载体，可以参考下：https://github.com/mosn/layotto/issues/476\n 第二个应该需要尝试使用 Rust 为 Layotto 的 API 开发一个组件然后编译成 Wasm。\n「Layotto」：https://github.com/layotto\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 金融级应用开发｜SOFABoot 框架剖析\n “SOFA 星球”闯关计划 ——Layotto 飞船\n HAVE FUN | 飞船计划、源码解析活动最新进展\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1650610800,"description":"SOFA Weekly | 年度优秀 Committer 、本周 Contributor、本周 QA","dir":"blog/sofa-weekly-20210422/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a78268fffd513c90682e116743a482e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210422/","publishdate":"2022-04-22T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210422/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 年度优秀 Committer 、本周 Contributor、本周 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210422/","wordcount":1213},{"author":"顾叶宸","categories":"SOFAStack","content":" 前言 某些场景下 SOFARegistry 需要暂时关闭推送功能，这样集群内的业务可以利用 client 的缓存继续工作，比如说 SOFARegistry 需要进行不兼容升级，需要全集群下线，更新版本后再拉起。\n推送开关的状态存储在数据库中，通过 Meta 修改数据后，Session 可以通过读取到推送开关的变更通知，并在对应的推送流程上进行切断。\n本文将聚焦推送开关功能的三个关键问题：\n meta 如何存储开关配置数据。 session 如何获取到开关配置的变更并触发更新（通知、定时）。 session 关闭推送功能的实现。 总体流程 关闭推送的请求，主要由 StopPushDataResource类下的closePush负责处理。我们来看看它的实现：\npublic Result closePush() { boolean ret; Result result = new Result(); // 1.重设灰度推送开关 ret = resetGrayOpenPushSwitch(); if (!ret) { result.setSuccess(false); return result; } PersistenceData persistenceData = PersistenceDataBuilder.createPersistenceData( ValueConstants.STOP_PUSH_DATA_SWITCH_DATA_ID, \u0026amp;quot;true\u0026amp;quot;); try { // 2.重设全局推送开关 ret = provideDataService.saveProvideData(persistenceData); ...... } catch (Throwable e) { ...... } if (ret) { // 3.发送数据变更通知 fireDataChangeNotify( persistenceData.getVersion(), ValueConstants.STOP_PUSH_DATA_SWITCH_DATA_ID); } result.setSuccess(ret); return result; } 可以看到，closePush函数主要做了三件事：\n 重设灰度推送开关 灰度推送开关中，存储着一个 IP 列表。灰度推送允许 SOFARegistry 即使在全局推送关闭的情况下，仍满足特定 IP 的推送请求。因此想要完全关闭推送功能，需要重设该开关，清空其中的 IP 列表。\n 重设全局推送开关 关闭推送功能，需要重设全局推送开关，保存开关配置为关闭的新数据。\n 发送数据变更通知 数据变更通知将告诉 Session，开关配置已经改变，需要进行更新。\nMeta存储开关配置数据 我们以重设全局推送开关中，开关数据的存储为例：\n meta 首先从内存中读取旧的开关配置版本号，并与当前数据版本号进行比较。  只有确定是更新的数据，才会进行后续存储。\n 存储新的开关配置数据，并更新数据库中该数据的版本号。\n 更新内存中的开关配置数据。\n public boolean saveProvideData(PersistenceData persistenceData, long expectVersion) { // 1.比较版本号 if (persistenceData.getVersion() \u0026amp;lt;= expectVersion) { ...... return false; } // 2.更新数据库 boolean success = provideDataRepository.put(persistenceData, expectVersion); if (success) { lock.writeLock().lock(); try { // 3.更新内存 provideDataCache.put( PersistenceDataBuilder.getDataInfoId(persistenceData), persistenceData); } catch (Throwable t) { ...... return false; } finally { lock.writeLock().unlock(); } } return success; } 重设灰度开关中的步骤与之类似，因此这里不再赘述。\nSession 获取开关配置 通知更新 继续上文，closePush会调用fireDataChangeNotify函数，通知外界开关配置发生了更新。\nprivate void fireDataChangeNotify(Long version, String dataInfoId) { ...... if (TASK_LOGGER.isInfoEnabled()) { ...... } provideDataNotifier.notifyProvideDataChange(provideDataChangeEvent); } 这一通知首先会进行判断，是哪一种事件类型。在本例中，开关配置的更新是与 Session 有关的事件。 public void notifyProvideDataChange(ProvideDataChangeEvent event) { Set\u0026amp;lt;Node.NodeType\u0026amp;gt; notifyTypes = event.getNodeTypes(); // 判断事件类型 if (notifyTypes.contains(Node.NodeType.DATA)) { defaultDataServerService.notifyProvideDataChange(event); } if (notifyTypes.contains(Node.NodeType.SESSION)) { defaultSessionServerService.notifyProvideDataChange(event); } } 随后，通知会被交付给 Session 相关的消息交换类，并进行Request请求。 public void notifyProvideDataChange(ProvideDataChangeEvent event) { new NotifyTemplate\u0026amp;lt;ProvideDataChangeEvent\u0026amp;gt;().broadcast(event); } public void broadcast(E event) { ...... getNodeExchanger().request(new NotifyRequest(event, connection, executors)); ...... } 在消息交换类中，系统使用getClientHandlers得到了负责消息响应的handler。 public Response request(Request request) throws RequestException { final URL url = …","date":1650610800,"description":"源码解析｜推送开关","dir":"projects/sofa-registry/code-analyze/code-analyze-push-switch/","fuzzywordcount":2900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"38175885eb9d257b9f176246010b34b3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","publishdate":"2022-04-22T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","summary":"前言 某些场景下 SOFARegistry 需要暂时关闭推送功能，这样集群内的业务可以利用 client 的缓存继续工作，比如说 SOFARegistry 需要进行不兼容升级，需要全集群下线，更新版本后再拉起","tags":["“源码解析”"],"title":"源码解析｜推送开关","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","wordcount":2840},{"author":"SOFA 团队","categories":"周年庆","content":" 概要 活动主题：见证 SOFAStack 社区开源四周年!\n 活动时间： 2022 年 04 月 16 日 （14:00-17:40）\n 活动形式：线上直播\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | 一、宋顺四周年致辞 点击下载资料\n| 二、《蚂蚁服务发现的大规模实践和展望》 讲师：蚂蚁集团技术专家李旭东（花名：向旭）\n点击下载资料\n议题简介\nnaming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。\n蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。\n本次将会分享蚂蚁内部实践经验，以及 naming 在云原生时代下的发展方向及趋势。\n| 三、《蚂蚁集团 Service Mesh 进展回顾与展望》 讲师：蚂蚁集团高级技术专家 石建伟（花名：卓与）\n点击下载资料\n议题简介\n练内功：内部集群规模化扩张带来的技术挑战，长连接膨胀，服务治理智能化演进和人工介入说再见\n定标准：Mesh 化是终点么？应用运行时标准\n建通路：让业务飞速发展的秘诀\n看未来：云原生运行时的下一个五年\n| 四、《MOSN 1.0 发布，开启新一代架构演进》 讲师：MOSN 核心成员 朱德江（花名：人德）\n点击下载资料\n议题简介\n一、MOSN 1.0 发布\n回顾 MOSN 的发展历史、新版本的特性介绍\n二、新架构演进\n发力南北向网关数据面、整合控制面，开源新产品\n| 五、《Ark Serverless 体系助力业务极速研发》 讲师：蚂蚁集团技术专家 赵真灵（花名：有济）\n讲师：蚂蚁集团技术专家刘晶（花名：飞廉）\n点击下载资料\n议题简介\nArk Serverless 技术体系让用户以开发模块（代码块）的方式快速上线新功能，同时让模块开发者不感知机器、环境与容量等基础设施，助力企业实现业务的快速发展。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1650092400,"description":"见证 SOFAStack 社区开源四周年!","dir":"activities/sofastack-four-years-of-open-source/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"08b0bec521b5328d71dcc39370feb260","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofastack-four-years-of-open-source/","publishdate":"2022-04-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofastack-four-years-of-open-source/","summary":"概要 活动主题：见证 SOFAStack 社区开源四周年! 活动时间： 2022 年 04 月 16 日 （14:00-17:40） 活动形式：线上直播 B 站直播间地址：http://live","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFA 四周年，开源正当时！","type":"activities","url":"/sofastack.tech/activities/sofastack-four-years-of-open-source/","wordcount":827},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@ 尚之 提问：\n SOFARegistry 和应用绑定有多深，Serverless 场景下有没有更动态的方案和应用解绑？\n A：其实不需要和应用进行绑定，更准确的说法是节点级的服务发现，就算应用下面每个节点之间发布的服务不一样，应用级的这个方案也是可以支持的。而且目前蚂蚁的 Serverless 的场景实际上已经是应用级了，只是对于业务 owner 没有感知。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@ 黄润良 提问：\n 两个组合为什么不生效呢？按照时间轮转，就不需要管理日志数量了吗？\n A：按照时间轮转还没有支持这个日志数量。\n 按时间轮转的，轮转后的文件名应该是带日期时间字符串的把，配个定制任务清理一下就可以了吗？\n A：我们也是用的这个库，然后根据时间轮转是我们扩展的，我们是统一平台做这个事，就没在 MOSN 里实现。\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto Java-sdk 本周发布 Layotto Java-sdk 发布 v1.1.0 版本，主要变更如下：\n 支持 File API\n 支持 Sequencer API\n 新增 layotto-springboot\n 「发布报告」：https://github.com/layotto/java-sdk/releases/tag/v1.1.0\n本周推荐阅读 HAVE FUN | Layotto 源码解析\n 异构注册中心机制在中国工商银行的探索实践\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1649401200,"description":"SOFA Weekly |开源新知、本周 QA、Layotto Java-sdk 本周发布","dir":"blog/sofa-weekly-20220408/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c70e2662ec9434d8229f900636d39af1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220408/","publishdate":"2022-04-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220408/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |开源新知、本周 QA、Layotto Java-sdk 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220408/","wordcount":1202},{"author":"行动","categories":"SOFAStack","content":" SOFARegistry 对于服务数据是分片进行存储的，因此每一个 data server 只会承担一部分的服务数据，具体哪份数据存储在哪个 data server 是有一个称为 SlotTable 的路由表提供的，session 可以通过 SlotTable 对对应的 data derver 进行读写服务数据， slot 对应的 data follower 可以通过 SlotTable 寻址 leader 进行数据同步。\n维护 SlotTable 是由 Meta 的 leader 负责的，Meta 会维护 data 的列表，会利用这份列表以及 data 上报的监控数据创建 SlotTable，后续 data 的上下线会触发 Meta 修改 SlotTable， SlotTable 会通过心跳分发给集群中各个节点。\n1. DataServer 更新SlotTable 路由表过程。 如上图所示 session 和 data 节点定时会向 Meta 节点上报心跳、Meta节点维护了 data 以及 session 节点列表信息、并且在心跳请求中将返回 SlotTable 路由表信息、data 节点将路由表 SlotTable 保存在本地中。\n2. SlotTable 更新平衡算法 由前文可知、SOFARegistry 采用了数据分片存储在 DataServer 节点之上、那么随之而来的问题就是数据如何分片呢?\nSOFARegistry 采用预分配的方式。\n传统的一致性 Hash 算法有数据分布范围不固定的特性，该特性使得服务注册数据在服务器节点宕机、下线、扩容之后，需要重新存储排布，这为数据的同步带来了困难。大多数的数据同步操作是利用操作日志记录的内容来进行的，传统的一致性 Hash 算法中，数据的操作日志是以节点分片来划分的，节点变化导致数据分布范围的变化。\n在计算机领域，大多数难题都可以通过增加一个中间层来解决，那么对于数据分布范围不固定所导致的数据同步难题，也可以通过同样的思路来解决。\n这里的问题在于，当节点下线后，若再以当前存活节点 ID 一致性 Hash 值去同步数据，就会导致已失效节点的数据操作日志无法获取到，既然数据存储在会变化的地方无法进行数据同步，那么如果把数据存储在不会变化的地方是否就能保证数据同步的可行性呢？答案是肯定的，这个中间层就是预分片层，通过把数据与预分片这个不会变化的层相互对应就能解决这个数据同步的难题。\n目前业界主要代表项目如 Dynamo、Casandra、Tair、Codis、Redis cluster 等，都采用了预分片机制来实现这个不会变化的层。\n事先将数据存储范围等分为 N 个 slot 槽位，数据直接与 slot 相对应，数据的操作日志与相应的 solt 对应，slot 的数目不会因为节点的上下线而产生变化，由此保证了数据同步的可行性。除此之外，还需要引进“路由表”的概念，如图 13，“路由表”负责存放每个节点和 N 个 slot 的映射关系，并保证尽量把所有 slot 均匀地分配给每个节点。这样，当节点上下线时，只需要修改路由表内容即可。保持 slot 不变，即保证了弹性扩缩容，也大大降低了数据同步的难度。\n实际上上述 Slot 和 **节点 **的映射关系在源码中以 **SlotTable 和 Slot **的方式进行表达。源码如下代码块所示。\npublic final class SlotTable implements Serializable { public static final SlotTable INIT = new SlotTable(-1, Collections.emptyList()); // 最后一次更新的时间 epoch private final long epoch; //保存了 所有的 slot 信息； slotId ---\u0026amp;gt; slot 对象的映射 private final Map\u0026amp;lt;Integer, Slot\u0026amp;gt; slots; } public final class Slot implements Serializable, Cloneable { public enum Role { Leader, Follower, } private final int id; //当前slot的leader节点 private final String leader; //最近更新时间 private final long leaderEpoch; //当前slot的follow节点 private final Set\u0026amp;lt;String\u0026amp;gt; followers; } 由于节点在动态变化中、所以 Slot 和 节点的映射也在时刻变化中、那么我们接下来的重点就是 SlotTable 的变更过程。SlotTable 的变更是在 Meta 节点中触发、当有服务上下线的时候会触发SlotTable 的变更、除此之外也会定期执执行 SlotTable的变更。\nSlotTable的整个同步更新步骤如图所示。\n代码参考 com.alipay.sofa.registry.server.Meta.slot.arrange.ScheduledSlotArranger#arrangeSync.\nSlotTable 的定期变更是通过在初始化 ScheduledSlotArranger 时候实例化守护线程不断的 定期执行 内部任务 Arranger 的 arrangeSync 方法来实现 SlotTable 变更的。大致流程如下所示。\n因为负责 SlotTable 的更新是在 MetaServer 中的主节点更新的。\n所以更新 SlotTable的第一步就是判断是否是主节点。主节点才负责真正的 SlotTable 变更步骤。\n第二步是获取最新的 DataServer 节点，因为 重新分配 SlotTable 本质上是 对 DataServer 节点和 slot 槽位之间的映射关系进行重新分配。所以肯定需要获取到当前正在存活的 DataServer 节点信息，从而方便的对之进行 slot 分配。\n(这里获取正在存活的 DataServer 也就是有和 MetaServer 维持心跳的 DataServer, 底层是从 com.alipay.sofa.registry.server.Meta.lease.impl.SimpleLeaseManager中获取，感兴趣可以查看相关源码) 。\n第三部是分配前置校验，实际上一些边界条件的判断、例如 DataServer 是否为空、 DataServer 的大小是否大于配置的 minDataNodeNum，只有满足这些条件才进行变更。\n第四步 执行 trayArrageSlot 方法、进入到该方法内部之中。\n首先获取进程内部锁、实际上是一个 ReentrantLock，这里主要是为了避免定时任务多次同时执行 SlotTable 的分配工作。\nprivate final Lock lock = new ReentrantLock(); 随后便是根据当前的 Data …","date":1649401200,"description":"源码解析｜SlotTable","dir":"projects/sofa-registry/code-analyze/code-analyze-slottable/","fuzzywordcount":8900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8705a6ead8d88f09270c5c19a3f6e6e6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","publishdate":"2022-04-08T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","summary":"SOFARegistry 对于服务数据是分片进行存储的，因此每一个 data server 只会承担一部分的服务数据，具体哪份数据存储在哪个 data server 是有一个称为 SlotTable 的路由表提供的，sessio","tags":["“源码解析”"],"title":"源码解析｜SlotTable","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","wordcount":8810},{"author":"宋国磊","categories":"SOFAStack","content":" 本篇主要对 SOFARegistry 的数据同步模块进行解析，对于注册中心的概念以及 SOFARegistry 的基础架构不做过多阐述，相关介绍可以见海量数据下的注册中心 - SOFARegistry 架构介绍\n本文主要写作思路大致分为下面 2 个部分：第一部分借助 SOFARegistry 中的角色分类来说明哪些角色之间会进行数据同步，第二部分对数据同步的具体实现进行解析。\nSOFARegistry 的角色分类 如上图，SOFARegistry 包含 4 个角色：\n 角色 说明 Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。 SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。 DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。 MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。 在这 4 个角色中，MetaServer 作为元数据服务器本身不处理实际的业务数据，仅负责维护集群 SessionServer 和 DataServer 的一致列表，不涉及数据同步问题；Client 与 SessionServer 之间的核心动作是订阅和发布，从广义上来说，属于用户侧客户端与 SOFARegistry 集群的数据同步，可以见：https://github.com/sofastack/sofa-registry/issues/195，因此不在本文讨论范畴之内。\nSessionServer 作为会话服务，它主要解决海量客户端连接问题，其次是缓存客户端发布的所有 pub 数据；session 本身不持久化服务数据，而是将数据转写到 DataServer。DataServer 存储服务数据是按照 dataInfoId 进行一致性 Hash 分片存储的，支持多副本备份，保证数据高可用。\n从 SessionServer 和 DataServer 的功能分析中可以得出：\n SessionServer 缓存的服务数据需要与 DataServer 存储的服务数据保持一致 DataServer 支持多副本来保证高可用，因此 DataServer 多副本之间需要保持服务数据一致。 SOFARegistry 中对于上述两个对于数据一致性保证就是通过数据同步机制来实现的。\n数据同步的具体实现 下面主要介绍数据同步的实现细节，主要包括 SessionServer 和 DataServer 之间的数据同步 和 DataServer 多副本之间的数据同步两块。\nSessionServer 和 DataServer 之间的数据同步 SessionServer 和 DataServer 之间的数据同步，是基于推拉结合的机制\n 推：DataServer 在数据有变化时，会主动通知 SessionServer，SessionServer 检查确认需要更新（对比 version） 后主动向 DataServer 获取数据。\n 拉：除了上述的 DataServer 主动推以外，SessionServer 每隔一定的时间间隔，会主动向 DataServer 查询所有 dataInfoId 的 version 信息，然后再与 SessionServer 内存的 version 作比较，若发现 version 有变化，则主动向 DataServer 获取数据。这个“拉”的逻辑，主要是对“推”的一个补充，若在“推”的过程有错漏的情况可以在这个时候及时弥补。\n 关于推和拉两种模式检查的 version 有一些差异，可以详见下面 推模式下的数据同步 和 拉模式下的数据同步 中的具体介绍\n 推模式下的数据同步流程 推模式是通过 SyncingWatchDog 这个守护线程不断 loop 执行来实现数据变更检查和通知发起的。\n// 这里遍历所有的 slot for (SlotState slotState : slotTableStates.slotStates.values()) { try { sync(slotState, syncSessionIntervalMs, syncLeaderIntervalMs, slotTableEpoch); } catch (Throwable e) { SYNC_ERROR_LOGGER.error( \u0026amp;quot;[syncCommit]failed to do sync slot {}, migrated={}\u0026amp;quot;, slotState.slot, slotState.migrated, e); } } 按 slot 分组汇总数据版本。data 与每个 session 的连接都对应一个 SyncSessionTask，SyncSessionTask 负责执行同步数据的任务，核心同步逻辑在com.alipay.sofa.registry.server.data.slot.SlotDiffSyncer#sync\n方法中完成，大致流程如下面时序图所示：\n这上图圈红部分的逻辑第四步，根据 dataInfoId diff 更新 data 内存数据，这里仅处理了被移除的 dataInfoId，对于新增和更新的没有做任务处理，而是通过后面的第 5 -7 步来完成；这么做的主要原因在于避免产生空推送导致一些危险情况发生。\n第 5 步中，比较的是所有变更 dataInfoId 的 pub version，具体比较逻辑参考后面 diffPublisher 小节中的介绍。\n数据变更的事件通知处理 数据变更事件会被收集在 DataChangeEventCenter 的 dataCenter2Changes 缓存中，然后由一个守护线程 ChangeMerger 负责从 dataCenter2Changes 缓存中不断的读取，这些被捞到的事件源会被组装成 ChangeNotifier 任务，提交给一个单独的线程池(notifyExecutor)处理，整个过程全部是异步的。\n拉模式下的数据同步流程 拉模式下，由 SessionServer 负责发起， com.alipay.sofa.registry.server.session.registry.SessionRegistry.VersionWatchDog\n默认情况下每 5 秒扫描一次版本数据，如果版本有发生变更，则主动进行拉取一次，流程大致如下：\n需要注意的是，拉模式对推送流程的补充，这里的 version 是每个 sub …","date":1649228400,"description":"源码解析｜数据同步","dir":"projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b78da7b0c10e92e61edba8aeb05d8bac","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","publishdate":"2022-04-06T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","summary":"本篇主要对 SOFARegistry 的数据同步模块进行解析，对于注册中心的概念以及 SOFARegistry 的基础架构不做过多阐述，相关介绍可以见海量数据下的注册中心 - SOFARegistry 架构介绍 本文主要写","tags":["“源码解析”"],"title":"源码解析｜数据同步","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","wordcount":3696},{"author":"Junlong Liu","categories":"SOFAStack","content":" 文｜Junlong Liu\nShopee Digital Purchase \u0026amp;amp; Local Services Engineering\n本文1743字 阅读 6分钟\n贡献者前言 我是在开发工作过程中了解到 Holmes 的，为了保障系统稳定性需要一个性能排查工具，因此也需要一个保留现场的性能监控工具。当我在网上查询该方面的开源库时，发现可用的并不多。后续找到 MOSN 社区的 Holmes ，发现这个开源库功能基本齐全、扩展性也高，特别是 GCHeapDump 这个业界领先的功能，对解决内存升高的问题十分有用。\n2021 年年末了解到的 Holmes 组件，然后开始了解 Holmes 所在的 MOSN 社区。Holmes 作为性能排查工具，核心功能是及时发现性能指标异常，并对系统进行 Profiling。\n由于 Holmes 还处于萌芽期，除了 Readme 之外的文档资料并不多。还有一些 Holmes 当时不支持的功能，比如动态配置调整与上报。Holmes 当时也还没发布第一个版本，但是自己对这方面也有兴趣和理解，于是在 GitHub 上提了几个 Issue 讨论，社区回复的速度十分快。后续在社区前辈们的指导下提了 PR，也因此通过 Holmes 的代码设计学习到了很多关于开源组件的设计理念。\n因此我决定参与开源社区并贡献代码，以解决实际需求。有了一定的了解和经验之后，通过和人德前辈讨论，总结这样一篇分享文章。\n本文将介绍 Holmes 的使用场景、快速开始案例、多个监控类型、设计原理、扩展功能与如何借助 Holmes 搭建起一套简单的性能排查系统，欢迎大家留言指导。\nHolmes 使用场景 对于系统的性能尖刺问题，我们通常使用 Go 官方内置的 pprof 包进行分析，但是难点是对于一闪而过的“尖刺”，开发人员很难及时保存现场：当你收到告警信息，从被窝中爬起来，打开电脑链接 VPN，系统说不定都已经重启三四趟了。\nMOSN 社区的 Holmes 是一个基于 Golang 实现的轻量级性能监控系统，当应用的性能指标发生了异常波动时，Holmes 会在第一时间保留现场，让你第二天上班可以一边从容地喝着枸杞茶，一边追查问题的根因。\nQuick Start 使用 Holmes 的方式十分简单，只需要在您的系统初始化逻辑内添加以下代码：\n// 配置规则 h, _ := holmes.New( holmes.WithCollectInterval(\u0026amp;quot;5s\u0026amp;quot;), // 指标采集时间间隔 holmes.WithDumpPath(\u0026amp;quot;/tmp\u0026amp;quot;), // profile保存路径 holmes.WithCPUDump(10, 25, 80, 2 * time.Minute), // 配置CPU的性能监控规则 holmes.WithMemDump(30, 25, 80, 2 * time.Minute),// 配置Heap Memory 性能监控规则 holmes.WithGCHeapDump(10, 20, 40, 2 * time.Minute), // 配置基于GC周期的Heap Memory 性能监控规则 holmes.WithGoroutineDump(500, 25, 20000, 100*1000, 2 * time.Minute), //配置Goroutine数量的监控规则 ) // enable all h.EnableCPUDump(). EnableGoroutineDump(). EnableMemDump(). EnableGCHeapDump().Start() 类似于 holmes.WithGoroutineDump(min, diff, abs,max,2 * time.Minute) 的 API 含义为:\n当 Goroutine 指标满足以下条件时，将会触发 Dump 操作。\n当 Goroutine 数大于 Max 时，Holmes 会跳过本次 Dump 操作，因为当 Goroutine 数过大时，Goroutine Dump 操作成本很高。\n2 * time.Minute 是两次 Dump 操作之间最小时间间隔，避免频繁 Profiling 对性能产生的影响。\n更多使用案例见文末的 Holmes 使用案例文档。\nProfile Types Holmes 支持以下五种 Profile 类型，用户可以按需配置。\nMem: 内存分配\nCPU: CPU 使用率\nThread: 线程数\nGoroutine: 协程数\nGCHeap: 基于 GC 周期监控的内存分配\n指标采集 Mem、CPU、Thread、Goroutine 这四种类型是根据用户配置的 CollectInterval，每隔一段时间采集一次应用当前的性能指标，而 gcHeap 时基于 GC 周期采集性能指标。\n本小节会分析一下两种指标。\n根据 CollectInterval 周期采集 Holmes 每隔一段时间采集应用各项指标，并使用一个固定大小的循环链表来存储它们。\n根据 GC 周期采集 在一些场景下，我们无法通过定时的 memory dump 保留到现场。比如应用在一个 CollectInterval 周期内分配了大量内存，又快速回收了它们。此时 Holmes 在周期前后的采集到内存使用率没有产生过大波动，与实际情况不符。\n为了解决这种情况，Holmes 开发了基于 GC 周期的 Profile 类型，它会在堆内存使用率飙高的前后两个 GC 周期内各 Dump 一次 Profile，然后开发人员可以使用 pprof \u0026amp;ndash;base 命令去对比两个时刻堆内存之间的差异。\n根据 GC 周期采集到的数据也会放在循环列表中。\n规则判断 本小节介绍 Holmes 是如何根据规则判断系统出现异常的。\n阈值含义 每个 Profile 都可以配置 min、diff、abs、coolDown 四个指标，含义如下:\n当前指标小于 min 时，不视为异常。\n当前指标大于 (100+diff)100% 历史指标，说明系统此时产生了波动，视为异常。\n当前指标大于 abs (绝对值)时，视为异常。\nCPU 和 Goroutine 这两个 Profile 类型提供 Max 参数配置，基于以下考虑：\nCPU 的 Profiling 操作大约会有 5% 的性能损耗，所以当在 CPU 过高时，不应当进行 Profiling 操作，否则会拖垮系统。\n当 Goroutine 数过大时，Goroutine Dump 操作成本很高，会进行 STW 操作，从而拖垮系统。（详情见文末参考文章）\nWarming up 当 Holmes 启动时，会根据 CollectInterval 周期采集十次各项指标，在这期间内采集到的指标只会存入循环链表中，不会进行规则判断。\n扩展功能 除了基本的监控之外，Holmes 还提供了一些扩展功能：\n事件上报 您可以通过实现 Reporter 来实现以下功能：\n发送告警信息，当 Holmes 触发 Dump 操作时。\n将 Profiles 上传到其他地方，以防实例被销毁，从而导 …","date":1649142000,"description":"社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析","dir":"blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"87409f8ec80db088a42f856f0baf16da","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","publishdate":"2022-04-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","summary":"文｜Junlong Liu Shopee Digital Purchase \u0026amp; Local Services Engineering 本文1743字 阅读 6分钟 贡献者前言 我是在开发工作过程中了解到 Holmes 的，为了保障系统稳定性需要一个性能排查工具，","tags":["SOFAStack"],"title":"社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析","type":"blog","url":"/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","wordcount":2934},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@ 毛晨斌 提问：\n 使用 Layotto 是不是客户端代码需要重新实现，全部调用 Layotto 提供的API？多少正式的项目正在使用 Layotto?\n A：目前蚂蚁的落地用户将客户端 SDK，改成调用 Layotto；现在在搞无侵入方案。\n 开源版服务器端支持哪些中间件，客户端无侵入支持哪些中间件？\n A：1. 已经落地的方案是：将各种中间件的 Java SDK，改成调用 Layotto （比如把 xxx-MQ-sdk 内部逻辑改成调layotto pubsub API，但是对业务代码暴露的接口不变)。业务系统需要升级下 SDK，业务代码不用改。这部分没开源，因为是改内部中间件的 SDK，这些中间件本身没开源。 2. 开源版服务器端支持那些中间件：每类 API 有支持的组件列表。 https://mosn.io/layotto/#/zh/component_specs/sequencer/common 其中 state API、pubsub API 因为复用了 Dapr 的组件，所有 Dapr 组件都支持。https://docs.dapr.io/zh-hans/reference/components-reference/supported-state-stores/\n3.客户端支持哪些：目前有 .net java go 的 Layotto SDK，有个 layotto-springboot 刚合并。SDK 在 https://github.com/layotto\n 关于无侵入方案：后面想把协议转换的事情放到 Layotto 做、让用户接入 Layotto 时不用改客户端 SDK，不过方案还在讨论，最近会写个 proposal。 5.现在还没有现成的客户端无侵入 SDK，老系统接入 Layotto 需要改原来的 SDK。\n「SOFABolt」：https://github.com/sofastack/sofa-boot\n黄润良 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?upstream 的 ip access 日志怎么打印来访日志呢，主要是负载均衡后访问到后段的哪个 IP?\n A：你要在 errorlog 打印吗？你可以配置 accesslog，一个请求一条的。你的 tracelog 也可以打印的。https://github.com/mosn/mosn/blob/master/pkg/log/accesslog.go\n [WARN][downStream]reset stream reason ConnectionTermination[proxy][downstream]processError=downstreamReset proxyld:2204350,reason:ConnectionTermination\n A：downstream 的连接断链了。比如你 curl 访问 MOSN，在 reponse 回复之前 Ctrl+C 终止断链接，MOSN 就会打印这个日志，也就是还没有回复请求，client 就断链了。 然后 client 自己有超时，可能就断链了。\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nHolmes 本周发布 Holmes 发布 v1.0 版本\nHolmes 是 MOSN 社区开源的 go 语言 continous profiling 组件，可以自动发现 cpu、 memory、goroutine 等资源的异常，并自动 dump 异常现场 profile，用于事后分析定位。也支持上传 profile 到自动分析平台，实现自动问题诊断、报警。\n「发布报告」：https://github.com/mosn/holmes/releases/tag/v1.0.0\n「Holmes 原理介绍」：https://mosn.io/blog/posts/mosn-holmes-design/\n本周推荐阅读 HAVE FUN | Layotto 源码解析\n 异构注册中心机制在中国工商银行的探索实践\n Nydus 镜像加速插件迁入 Containerd 旗下\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1648796400,"description":"SOFA Weekly | 开源新知、本周 QA、新手任务","dir":"blog/sofa-weekly-20220401/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b94eecd772ed0839dc842cdafb587990","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220401/","publishdate":"2022-04-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220401/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源新知、本周 QA、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220401/","wordcount":1838},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFAMeetup\u0026amp;amp;木兰技术开放日（云原生专场）\n 活动时间：2022 年 04 月 01 日（周五）09:30-12:00\n 活动形式：线上直播\n 资料下载：\n 《如何建立云原生时代的 DevOps 工具链》\n《在大规模集群中落地 Layotto 这种多运行时架构是一种什么样的体验》\n《云原生多集群治理实践》\n《蚂蚁服务发现的大规模实践与展望》\n活动议程 活动回顾 直播主题：木兰技术开放日\u0026amp;amp;SOFAMeetup（云原生专场）\n直播时间：2022 年 4 月 1 日 上午 9:30\n议题分享：\n《中国木兰社区助力云原生扬帆远航》 王庆 英特尔研发总监、木兰开源社区技术委员会成员\n 嘉宾简介：\n王庆，英特尔软件与先进技术事业部云基础设施软件研发总监、开放基础设施基金会个人独立董事、Linux 基金会下属 SODA 基金会外联委员会主席。木兰开源社区技术委员会成员、中国计算机学会CCF开源发展委员会常务委员。\n曾经参与或领导团队开发 Xen、tboot、Yocto、OpenStack 等开源项目。 目前，他和他的团队正在积极致力于云计算、云原生、边缘计算、网络和存储、以及云性能评估与优化等方向，涵盖 Kubernetes、Containerd、Istio、Envoy、Ceph、Akraino 等等。该团队多年来和业界建立了良好的合作关系，是开源云计算软件的一支中坚力量。\n《如何建立云原生时代的 DevOps 工具链》 刘新 都广科技创始人、建木核心开发者。\n 嘉宾简介：\n刘新，都广科技创始人、建木核心开发者。\n从事软件开发与架构设计工作超过 10 年。 曾在通讯、金融、医疗与云计算等行业担任过首席架构师、技术总监、产品总监和CTO等技术职务。\n个人主要兴趣在分布式架构、DevOps、系统优化、工程质量提升等方面。 目前主要精力在开源建木社区运营并负责后端代码的开发贡献。\n议题简介：\n云原生离不开 DevOps，DevOps 作为云原生架构落地的三驾马车的重要性不言而喻。而 DevOps 的成功实施，往往依赖一组集成化的工具链。那么在当前 DevOps 工具百花齐放的情况下，云原生时代的 DevOps 工具链又应该如何建立呢？\n《在大规模集群中落地 dapr 或 Layotto 这种多运行时架构是什么样的体验》 周群力（目前在蚂蚁集团中间件团队负责 Layotto 项目研发）\n 嘉宾简介：\n周群力（花名：仪式）目前在蚂蚁集团中间件团队负责 Layotto 项目研发\n议题简介：\n随着 Service Mesh 在蚂蚁集团内部的大规模落地，我们逐渐遇到了新的挑战，这让我们迫切的寻找新的解决方案。 Service Mesh 通过引入 sidecar 来简化服务治理，而 dapr 这种“多运行时”项目告诉大家：sidecar 能做的事情远不止于此。\n\u0026amp;ldquo;多运行时\u0026amp;rdquo;这种架构真的有这么好么？会不会太过理想化？\n实际落地时会踩什么坑，怎么解决，最终又能带来什么价值？\n在大规模集群中，落地 dapr或layotto 这种多运行时架构是什么样的体验？\n听众收益：\n了解蚂蚁集团在Service Mesh大规模落地以后遇到的新问题以及对于如何解决这些问题的思考。\n了解“多运行时架构”是什么，解决什么问题 了解目前“多运行时架构”相关开源项目在大规模集群落地时会遇到什么问题，有什么不足，如何解决，以及最终带来什么收益 帮助同样在做“多运行时架构”项目的朋友们躲坑、少走弯路。\n《云原生多集群治理实践》 徐迪 腾讯云技术专家，Clusternet 项目发起人。\n 嘉宾简介：\n腾讯云技术专家，Clusternet 项目发起人。在云原生领域有着丰富的经验，也是国内较早参与 Kubernetes 社区的开发者。热爱开源，拥抱开源，并多次在 KubeCon 各大峰会上发表演讲。\n议题简介：\n在过去的数年里，云计算领域经历了多次巨大的变革，当前越来越多的组织将应用部署在本地和云上的多个基础设施平台上，这些平台可能是两个公共云服务提供商，或者两个私有云，或者多地域的边缘云。新的形态导致基础设施的管理和应用治理的方式发生变化，传统的技术架构与管理方式增加了复杂性和风险，难以满足跨多个平台的应用服务部署和治理的挑战，代表业内最新理念的 Clusternet 项目应运而生。在这次演讲中，你将了解到 Clusternet 的最新进展和先进特性。\n《蚂蚁服务发现的大规模实践与展望》 肖健 目前在蚂蚁集团中间件团队负责 SOFARegistry 项目研发\n 嘉宾简介：肖健（花名：昱恒）目前在蚂蚁集团中间件团队负责 SOFARegistry 项目研发\n议题简介：\nnaming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。\n本次分享将会包含以下内容：\n 蚂蚁内部实践\n naming在云原生时代下的发展方向及趋势\n 总结和展望\n 听众收益：\n 了解蚂蚁集团在SOFARegistry新挑战及云原生时代的思考。\n 了解SOFARegistry实践经验。\n 了解蚂蚁集团对未来naming的思考及naming在云原生方向上的探索。\n 了解未来SOFARegistry的发展和相关的社区动向。\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1648796400,"description":"SOFAMeetup\u0026木兰技术开放日-云原生专场","dir":"activities/sofa-meetup-14/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"89cf0108c9b9e15c842c69bdc4a95876","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-14/","publishdate":"2022-04-01T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-14/","summary":"概要 活动主题：SOFAMeetup\u0026amp;木兰技术开放日（云原生专场） 活动时间：2022 年 04 月 01 日（周五）09:30-12:00 活动形式：","tags":["SOFA"],"title":"【活动回顾】《SOFAMeetup\u0026木兰技术开放日-云原生专场》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-14/","wordcount":2074},{"author":"Carver_007","categories":"SOFAStack","content":" 为了支撑超大规模集群以及大内容传输的支持，增加传输效率，减少网络带宽，考虑对消息进行压缩处理，SOFARegistry的data和session以及session和client (目前只有go支持）添加了对压缩数据传输的支持，同时增加缓存来减少压缩带来的较高的cpu的消耗。\n SOFARegistry 通讯默认支持了哪些压缩算法 目前 SOFARegistry 默认支持了 gzip 和 zstd 两种压缩算法。 gzip 是目前使用最广泛，压缩比较高的一种压缩算法。 zstd 是由 Facebook 的 Yann Collet 开发的一个无损数据压缩算法，Zstandard 在设计上与DEFLATE（.zip、gzip）算法有着差不多的压缩比，但是相比 gzip 有更高的压缩和解压缩速度。\n 两种压缩的基本实现代码如下： 整体结构如下如： CompressUtils 工具类采用静态 Map 对象（compressorMap），以编码方式为 key，以具体编码对应的压缩对象为 value 进行装载，然后待其使用的时候通过编码方式进行获取对应的编码对象实现类。 启动的时候装载到一个 Map 对象，key 为上图的两种编码常量，value 为具体实现类。当需要压缩的时候通过一下 find 方法或者重载方法进行获取具体压缩对象。代码如下：\n缓存的使用 由于压缩和解压缩的对资源的消耗极大，SOFARegistry采用了Google的Guava缓存来提升部分性能，当需要获取压缩的时候首选从缓存中获取，缓存中没有, 才进行压缩操作，同时将压缩结果缓存起来，以便下次获取的时候能直接获取。 具体代码细节参考如下：\n 小注：默认采用hession进行序列化\n 3.数据推送以及通讯两端的数据协商机制 发送端压缩对象的选择由订阅者接收端配置信息决定，所以可以保证发送端和接收端的压缩格式的统一。\n小结： SOFARegistry 是一种定位大型金融级分布式注册中心，数据通信定位偏向于大数据包大流量，因此对于数据传输效率和数据安全较为关注，采用高效的压缩方式，能有效的增加传输效率和使用安全性。目前支持的两种压缩方式都是市面上主流的压缩算法，同时配合这缓存的机制，极好的解决了大数据包带来大流量对网络带宽的压力，因此非常适合大型项目，但是相较于小型项目，这种压缩机制就显得很多余，压缩带来较高的 cpu 压力，因此 SOFARegistry 同时支持关闭压缩传输方式，以支持一些小型项目，具体使用根据业务来定。\n","date":1648623600,"description":"源码解析｜通讯数据压缩","dir":"projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1eea84eb058815d251783d98ba763865","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","publishdate":"2022-03-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","summary":"为了支撑超大规模集群以及大内容传输的支持，增加传输效率，减少网络带宽，考虑对消息进行压缩处理，SOFARegistry的data和sessi","tags":["“源码解析”"],"title":"源码解析｜通讯数据压缩","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","wordcount":901},{"author":"SOFAStack","categories":"SOFAStack","content":" 文｜颜高飞\n【工商银行】金融科技研究院云计算实验室\n本文 2651 字 阅读 5 分钟\n前言 中国工商银行于 2014 年率先启动银行核心业务系统的分布式架构转型探索，自主研发了同业领先的分布式服务平台。\n注册中心为服务平台提供了核心的服务发现功能，其健壮性对服务调用的成功率起着至关重要的作用。近年来，随着服务架构落地范围迅速扩大，注册中心性能容量支撑能力面临更高挑战。\n工商银行结合金融业实际运行场景，对注册中心架构进行了深度定制及优化，不断探索性能容量和高可用能力极限。\nPART. 1 问题及挑战 工商银行分布式服务平台选用 zookeeper 作为分布式服务注册中心。\nzookeeper 在业界分布式系统中使用广泛，具有大规模应用场景，为用户提供高效、稳定的分布式协调服务。zookeeper 支持集群化部署、性能可扩展，可用性也较高，主要表现有：\n1、半数存活即可用特性，使其容灾性能较强\n只要选举节点中有过半节点正常工作，集群即可正常对外提供服务。若集群内个别服务器宕机，客户端会自动切换连接至其他可用服务器。\n2、会话机制，使客户端注册信息保持稳定\n客户端与 zookeeper 服务端之间通过心跳保持会话，默认会话超时 40s。若集群正常对外服务，在会话超时后，zookeeper 服务端将剔除客户端注册信息。而若集群整体不可用，会话不会过期，在注册中心集群恢复后，能自动从快照中重新恢复故障前的会话和注册信息，无需外部干预。\n3、集群提供 observer 机制，实现读写分离、流量隔离\nobserver 节点不参与集群选举，只承担客户端连接和请求，提升整体吞吐量；分担选举节点压力，提升集群稳定性。在实施 observer 分组的情况下，还可实现客户端流量隔离。\n在金融业务实际运行场景中，工商银行搭建了以选举节点为核心、扩展部署 observer 节点的 zookeeper 注册中心集群，并在工商银行稳定运行多年。\n理论上，当 zookeeper 注册中心集群出现故障时，服务调用不会受到影响。\n但在实际混沌工程故障演练过程中，我们发现：偶发场景下，分布式服务平台存在因 zookeeper 系统资源故障或其他问题导致影响业务交易的现象。\n具体问题列举如下：\n 问题一：单服务扩容后提供方节点数过多 触及 zookeeper 推送报文 4M 的上限，从而导致 zookeeper 服务器性能压力过大，未能及时处理其他服务注册请求，影响交易。\n 问题二：zookeeper 集群 leader 服务器内存故障 进程僵死后集群重新选举产生新 leader，但集群内部分服务器未及时感知新 leader，导致部分服务提供方掉线，影响交易。\n 问题三：zookeeper 注册数据大幅增大后 集群故障重新选举后 leader 向其他节点同步的数据量过大，服务器网络到达瓶颈，导致部分服务器未及时加入新集群，影响交易。\n基于以上问题，工商银行一方面对 zookeeper 源码进行了深度定制，另一方面开始着手研究提升服务注册和服务发现高可用能力的机制。\nPART. 2 建设多注册多订阅机制，提升服务调用稳定性 为规避单注册中心集群故障而影响服务调用的问题，工商银行构建了多点接入的高可用注册模型（如图 1 所示）。\n说明：上图中 DC1 和 DC2 为 2 个机房，分别部署有 2 个独立的注册中心集群。DC1 和 DC2 中部署的提供方和消费方均注册、订阅自两个注册中心集群。DC1 中的消费方优先使用 DC1 注册中心推送的提供方列表，DC2 中的消费方优先使用 DC2 注册中心推送的提供方列表。\n在同城双机房内独立部署两个 zookeeper 集群，提供方注册服务至双注册中心，消费方也从双注册中心订阅服务。消费方优先使用与其在同一机房内的注册中心推送的数据，当同机房注册中心集群发生故障时，其他机房的注册中心可接管。注册中心集群故障接管过程中，服务正常调用。\n双注册双订阅机制建成后，分布式服务平台多次完美应对了底层系统资源故障、网络隔离等问题，分布式服务注册和服务发现稳定性显著提升。\n基于双 zookeeper 集群部署的双活架构，因双集群注册中心组件技术栈相同，极小概率下仍存在系统性交易风险——若两个 zookeeper 注册中心集群在同一时刻均出现同一类型故障时（比如同时达到性能瓶颈），业务交易仍然可能会受到影响。\n因此，为规避极小概率的系统性风险，工商银行进一步开展异构注册中心建设，追求极致的服务注册和发现高可用能力。\nPART. 3 建设异构注册中心，规避单一技术栈风险 注册中心异构部署，进一步提升高可用能力\n工商银行开展异构注册中心建设，在部署 zookeeper 集群的同时对等部署一套独立的异构注册中心集群。业务系统同时向 zookeeper 和异构注册中心两个集群注册并进行服务订阅（如图 2 所示）。\n异构注册中心与 zookeeper 协同工作，提升注册中心整体对外服务能力。当 zookeeper 集群与异构注册中心任一集群发生系统性故障时，另一注册中心集群可接管（如图 3 所示数据表结构）。\n说明：上图中 zookeeper 集群故障，异构注册中心正常工作，服务仍可正常注册、订阅及调用。\n提出合并订阅机制，使注册中心故障时迁移更加平滑\n工商银行原有多注册中心订阅机制，消费方优先使用某一注册中心推送的提供方列表，仅当该注册中心上无任一可用提供方，消费方才切换使用下一注册中心推送的数据。此时若优先使用的注册中心因故障推送了不完整的提供方列表，消费方集中调用这些提供方，可能导致“提供方负载不均”、“触发并发限流”等问题。\n为保障建设异构注册中心后注册中心故障时迁移更加平滑，工商银行研究并提出了消费方合并订阅机制：在消费方侧合并 zookeeper 和异构注册中心的订阅视图，各注册中心订阅数据合并后再刷新 invoker 缓存。\n即使某注册中心故障推送了空或者不完整的提供方列表，合并后的数据仍是有效的，提高了消费方筛选提供方的效率，提升交易成功率。\n注册中心异构部署和消费方合并订阅机制建成后，混沌模拟注册中心 CPU 满载、内存高负荷、磁盘故障、网络抖动、网络隔离等故障场景，提供方负载均衡，交易无失败，符合预期。同时，合并订阅机制还能额外降低多注册中心模式下消费方缓存提供方列表所占用的内存。\n基于以上技术储备及基础建设，工商银行于 2020 年开展异构注册中心建设，规避行内注册中心单一技术栈风险，进一步提升了注册中心核心组件在整个分布式体系中的高可用能力。\nPART. 4 未来展望 为满足分布式服务平台金融级高可用的需求，工商银行探索并提出异构注册高可用方案，消除了大规模服务注册场景下单一注册中心存在的系统性风险，保障金融系统的稳健运行。\n未来，工商银行将在异构注册的基础上进一步推动单元化部署运维转型，打破注册中心为全局唯一流量枢纽的现状，实现交易流量在单元内部最大限度完成闭环，辅以单元自动切换实现故障隔离，进一步控制区域性故障场景下的故障爆炸半径，全面提升分布式服务平台流量控制、高可用接管能力，为同业微服务架构规模化应用提供最佳实践和范例。\n本周推荐阅读 “SOFA 星球” …","date":1648537200,"description":"异构注册中心机制在中国工商银行的探索实践","dir":"blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"29e6ac47144c6efb8a23731c2f6351d2","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","publishdate":"2022-03-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","summary":"文｜颜高飞 【工商银行】金融科技研究院云计算实验室 本文 2651 字 阅读 5 分钟 前言 中国工商银行于 2014 年率先启动银行核心业务系统的分布式架构转型探索，自主研","tags":["SOFAStack"],"title":"异构注册中心机制在中国工商银行的探索实践","type":"blog","url":"/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","wordcount":2684},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@韩升 提问：\n 问下 SOFABolt 是否可以单独集成到 Spring Cloud 体系中？不依赖与 SOFABoot？还是直接引用 Bolt 的组件，然后使用原生的方式处理？\n A：直接用 Bolt 自己的 API 就行。\n「SOFABolt」：https://github.com/sofastack/sofa-boot\n**沄澈|che ** 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?\n A：要看 SerializerFactory 对 Localdatetime 的支持了。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nHolmes 本周发布 Holmes 发布 v1.0 版本\nHolmes 是 MOSN 社区开源的 go 语言 continous profiling 组件，可以自动发现 cpu、 memory、goroutine 等资源的异常，并自动 dump 异常现场 profile，用于事后分析定位。也支持上传 profile 到自动分析平台，实现自动问题诊断、报警。\n「发布报告」：https://github.com/mosn/holmes/releases/tag/v1.0.0\n「Holmes 原理介绍」：https://mosn.io/blog/posts/mosn-holmes-design/\n本周推荐阅读 SOFAArk Committer 专访｜看它不爽，就直接动手改！\n “SOFA 星球”闯关计划 ——Layotto 飞船\n 探索 SOFARegistry（一）｜基础架构篇\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1648278000,"description":"SOFA Weekly | 开源新知、Holmes 本周发布、新手任务","dir":"blog/sofa-weekly-20220329/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b4b14b0e38ee5d01c12019bbab406c50","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220329/","publishdate":"2022-03-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220329/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源新知、Holmes 本周发布、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220329/","wordcount":1205},{"author":"kuaile-zc","categories":"SOFAStack","content":" 大致代码流程 推送延迟的计算方式 首次订阅和后续推送延迟计算的区分 如何统计各个阶段的耗时 前言： 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析\n 1、大致代码流转流程 起源于此类 com.alipay.sofa.registry.server.session.push.PushProcessor @PostConstruct 注解由 java 源码提供初始化类会运行此方法，那么就从 init() 函数开始我们今天的故事！\n1.初始化 KeyedThreadPoolExecutor 类（com.alipay.sofa.registry.task.KeyedThreadPoolExecutor）\n2.初始化 initTaskBuffer()\n3.创建针对 push 的 cleaner 者创建过程中会将此线程设置为守护者线程 t.setDaemon(true)\n守护者线程：是指在程序运行的时候在后台提供一种通用服务的线程，比如垃圾回收线程就是一个很称职的守护者，并且这种线程并不属于程序中不可或缺的部分。因此，当所有的非守护线程结束时，程序也就终止了，同时会杀死进程中的所有守护线程。反过来说，只要任何非守护线程还在运行，程序就不会终止。\n源码给的默认值\ncoreSize = OsUtils.getCpuCount() * 3 CPU 数量 * 3\ncoreBufferSize = coreSize * 3000\n让我们来看看初始 KeyedThreadPoolExecutor 会发生的故事。\n1.设置基本参数，添加 Prometheus 监控。\n2.通过配置创建 AbstractWorker[] workers 数组类型。\n3.设置每个 worker 线程为\n让我们来看一下 createWorkers（） 这个方法干了什么事。\n1.创建阻塞队列\n2.创建多个 worker 数量根据 coreSize 并且所以的 worker 都共享所有队列\n阻塞队列被包装了一层详解如下：\n前置知识原生阻塞队列具有以下特性 ArrayBlockingQueue：基于数组的阻塞队列实现，在 ArrayBlockingQueue 内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外， ArrayBlockingQueue 内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。\nLinkedBlockingQueue：基于链表的阻塞队列，同 ArrayListBlockingQueue 类似，其内部也维持着一个数据缓冲队列（该队列由一个链表构成），当生产者往队列中放入一个数据时，队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时（LinkedBlockingQueue 可以通过构造函数指定该值），才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而 LinkedBlockingQueue 之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。\ncom.alipay.sofa.registry.task.BlockingQueues 存储队列的变量是 BlockingQueue[] queues 因为入参 array（false）所以最终生成的是数组类型的 LinkedBlockingQueue 阻塞队列 coreSize 个数组 coreBufferSize 个初始队列大小。\n我们可以看到 WorkerImpl 类的结构如下\n我们用图来解析一下 WorkerImpl 的工作原理\n所以当有服务订阅之后会生成订阅任务 WorkerImpl 将会执行任务，然后在任务执行过程中延迟链路跟踪。整个推送结束之后会有回调函数进行统计。\n2.推送延迟的计算方式 创建推送任务的时候 PushTask（）\nPushProcessor 中的都 push（）开启 push 任务\n1.检查是否是停止的推送任务和是否是灰度推送功能。\n2.task.trace.startPush() 开始任务记录当前开始时间值 PushTrace.pushStartTimestamp\n3.检查 push 任务运行情况 如果没有记录则表示正常， 如果已经有记录则：一种情况超时删除任务第二则是重试\n4.task.createPushData() 创建 Push data\n5.放入 push 记录为了未来重试或者异常情况获取记录做判断\n6.创建回调函数，完成 push 任务之后回调函数生效\n回调函数代码如下\nPushClientCallback.onCallback\n回调函数 PushClientCallback(task) onCallback(Channel channel, Object message) 调用了 this.pushTask.trace.finishPush（）结束了整个 push 链路追踪。\n最后算出大量的数据进行追踪 PushTrace.finish()\n3.首次订阅和后续推送延迟计算的区分 见下表/图统计\n4.如何统计各个阶段的耗时 此图为理解链路追踪过程：\n 字段 字段解释 表达式 根据上图分析步骤 首次订阅和后续推送计算方式是否有区别（默认不填为否） 注解 subRegTimestamp 订阅者订阅请求的时候的时间戳 pushStartTimestamp push 推送开始的时间戳 System.currentTimeMillis() 任务开始获取当前时间戳 pushFinishTimestamp push 推送完成的时间戳 System.currentTimeMillis() 结束之后调用结束方法之后获取当前时间戳 pushCause.triggerPushCtx.firstTraceTimes 第一次通知 seesion 数据变更的时间 lastTriggerSession(pushCause.triggerPushCtx.lastTraceTimes) 最后一次触发session(SOFARegistry 的组件之一）进行变更推送 pushCause.datumTimestamp 主动 pub：那时间就是在 data 端触发修改 datum 的时间如果是主动 sub：那时间就是 sub 注册的当前时间 是 lastPushTimestamp 上一次 push 的时间首次订阅：如果是首次订阅，就是订阅注册的时间，用于后续的过滤，防止重复计算已经推送过的数据的延迟。后续推送：上一次 push 的时间 是 lastPushTimestamp 上一次 push 的时间首次订阅：如果是首次订阅，就是订阅注册的时间，用于后续的过滤，防止重复计算已经推送过的数据的延迟。后续推送：上一次 push …","date":1648018800,"description":"源码解析｜推送延迟 trace","dir":"projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"585ac9eb55d6cd8f21a0fd12a313e8d8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","publishdate":"2022-03-23T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","summary":"大致代码流程 推送延迟的计算方式 首次订阅和后续推送延迟计算的区分 如何统计各个阶段的耗时 前言： 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析 1、大致代码流转流程 起","tags":["“源码解析”"],"title":"源码解析｜推送延迟 trace","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","wordcount":2584},{"author":"行动","categories":"SOFAStack","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁集团开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁集团的业务发展驱动下，近十年间已经演进至第六代。\n 本文为《源码解析｜数据倒排索引》，作者行动，来自高德。\n 《源码解析》系列由 SOFA 团队和源码爱好者们出品。\n GitHub 地址：https://github.com/sofastack/sofa-registry\nSOFARegistry 分层设计 我们知道一个典型的服务发布流程是这样的。\n 图1 服务发布流程\n 如上图、服务注册中心在RPC远程调用中的通常是中间协调者的角色，服务发布者Publisher将服务的发布信息（服务名称、ip、端口号等信息)）发布到注册中心 Registry 中、通常保存在 Registry 内部的数据结构中。服务订阅者在第一次调用服务的时候、会通过 Registry 找到所要调用服务的提供者列表。缓存在本地然后通过负载均衡算法找到一个具体的服务提供者。调用这个具体的服务提供者接口。\n了解了一个典型的 RPC 调用的流程、我们来看看 SOFARegistry 作为一个注册中心内部包含哪几种角色。\n Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\n SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\n DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。\n MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n 图2 SOFARegistry 分层设计 如图 2 所示、在 SOFARegistry 中、客户端 client 直接和 session 通讯，而不是传统意义上的Data节点、这种添加中间一层隔离 DataServer 和客户端的做法。主要是为了处理客户端连接风暴。对这种分层设计。\n感兴趣的可以参考 《海量数据下的注册中心 - SOFARegistry 架构介绍》的 “如何支持海量客户端” 章节，这里不再赘述。文章下面也是主要围绕 Session层展开。\nSessionServer 启动过程 SessionServer 模块的各个 bean 在 JavaConfig 中统一配置，JavaConfig 类为 SessionServerConfiguration，启动入口类为 SessionServerInitializer，该类不由 JavaConfig 管理配置，而是继承了 SmartLifecycle 接口，在启动时由 Spring 框架调用其 start 方法。 该方法中调用了 SessionServerBootstrap#start 方法（图 3），用于启动一系列的初始化服务。 从代码中可以看出，SessionServer 服务在启动时，会启动 SessionServer、SessionSyncServer、HttpServer 三个 bolt 服务。在启动这些 Server 之时，DataServer 注册了一系列 bolt Handler 来处理各类消息。\npublic void start() { try { openSessionSyncServer(); startupRetryer.call( () -\u0026amp;gt; { connectMetaServer(); return true; }); startupRetryer.call( () -\u0026amp;gt; systemPropertyProcessorManager.startFetchPersistenceSystemProperty()); startScheduler(); openHttpServer(); startupRetryer.call( () -\u0026amp;gt; { connectDataServer(); return true; }); sessionRegistryStrategy.start(); configProvideDataWatcher.start(); openSessionServer(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Cannot bootstrap session server :\u0026amp;quot;, e); throw new RuntimeException(\u0026amp;quot;Cannot bootstrap session server :\u0026amp;quot;, e); } } SessionServer 保存了哪些数据 在了解了 SessionServer 的启动过程、明白 SessionServer 作为 DataServer 的代理层、有着非常重要的位置。能够分摊一部分对 DataServer 的压力。那么在 SessionServer 在注册的时候会保存了哪些数据呢?\n SessionCacheService 从名称可以看出是缓存数据，当 Subscriber 注册到 SessionServer 中的时候、我们会给 Client 推送 Client 感兴趣的服务提供者信息列表。但是我们不可能在每次 Client 有变化的时候都去 Data层获取数据、这样对 Data 层的压力会很大。在 SessionServer 上缓存数据服务提供者信息可以对 DataServer 层屏蔽 Client 的变化，从而有效减轻 DataServer 的压力。SessionCacheService 内部的 readWriteCacheMap 缓存了服务提供者列表信息。使用 guava cache 缓存数据。数据有 ttl ，除此之外 Data 层有数据变化也会通知 cache 数据失效。\n Subscriber 和 Publisher 会话缓存信息正排索引信息。 SessionServer 的设计之初就是为了和 Client 直接通讯。通过 SessionServer 来负责与 Client 的连接，将每个 Client 的连接数收敛到 1，每个 SessionServer 负责与若干个 Client 连接，这样当 Client 数量增长时，只需要扩容 SessionServer 集群就可以了。 …","date":1648018800,"description":"源码解析｜数据倒排索引","dir":"projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"40d37578e58543cd340847fbdef907c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","publishdate":"2022-03-23T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["“源码解析”"],"title":"源码解析｜数据倒排索引","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","wordcount":4102},{"author":"葛长伟","categories":"SOFAStack","content":" 文｜葛长伟（花名：川朗 )\n蚂蚁集团技术专家\n负责容器镜像加速项目 Nydus 的开发和维护，专注于容器镜像存储、持久存储和文件系统领域。\n本文 1344 字 阅读 4 分钟\n前言 今年 1 月 ，Containerd 社区通过投票接收 Nydus-snapshotter 成为 Containerd 社区的子项目。这是继 ttrpc-rust 之后，蚂蚁容器团队再次向 Containerd 捐赠子项目。\n此举将方便 Nydus 和 Containerd 的开发协同，减少项目迭代过程中可能出现的不兼容问题，也让用户可以更容易地使用 Nydus 镜像加速服务。\n目前 Nydus 已经将 Nydus-snapshotter 的代码迁移到了 Containerd 组织下的新仓库[1]。\nNydus 简介 Nydus 是蚂蚁集团和阿里云共同开源的容器镜像加速项目，属于 CNCF Dragonfly 项目，是其中的镜像服务部分。\nNydus 是在最新的 OCI Image-Spec 基础之上设计的容器镜像加速服务，重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。\nNydus 设计了一个为镜像优化的文件系统—Rafs。\nNydus 镜像可以推送和保存在标准的容器镜像中心，Nydus 镜像格式完全兼容 OCI Image Spec 和 Distribution Spec。成功转换或者创建镜像后，Nydus 镜像会生成一个元数据文件 Bootstrap、若干个数据文件 blob、manifest.json、config.json。\n目前可以通过 Nydusify 、Acceld 或者 Buildkit 创建 Nydus 加速镜像。\n其中，Acceld[2] 是 Nydus 和 eStargz 的开发者正在合作开发的 Harbor 开源企业级镜像中心的一个子项目，它提供了一个通用的加速镜像转换服务和框架。基于 Acceld，Nydus 和 eStargz 可以方便地从 Harbor 触发加速镜像转换。\n与此同时，Nydus 也在开发 Buildkit 相关的支持，在未来也可以直接通过 Buildkit 从 Dockerfile 直接创建加速镜像。\nNydus-snapshotter 是 Containerd 的 Remote Snapshotter 插件，它是一个独立于 Containerd 的进程。\n当集成 Nydus-snapshotter 到 Containerd 后，Nydus-napshotter 在容器镜像准备阶段，只会将 Nydus 镜像的元数据部分 Bootstrap 从镜像中心下载下来，并且创建了一个新的进程 Nydusd。Nydusd 是处理文件系统操作的用户态进程。通过配置，Nydusd 可以作为基于 Linux FUSE 的用户态文件系统 Virtio-fs Vhost-user Backend，甚至可以是 Linux Fscache 的用户态进程。\nNydusd 负责从镜像中心或者对象存储下载文件数据以响应读文件的请求，并可以将文件数据块缓存在 Host 的本地文件系统。\nNydus 特性 Nydus 有如下重要的特性：\n1、镜像层间块级数据去重，可以减少镜像中心的存储成本，降低数据传输的带宽消耗。\n2、Whiteout 文件不会再被打包进 Nydus 镜像。\n3、端到端的数据完整性校验。\n4、作为 CNCF 孵化项目 Dragonfly 的子项目，Nydus 可以接入 P2P 分发系统，以此降低对镜像中心的压力。\n5、支持数据和元数据分离存储。可以将数据保存在 NAS、阿里云 OSS 或者 AWS S3。\n6、支持文件访问行为记录，这样就可以审计和分析容器内应用的访问行为。增强安全能力、优化镜像数据排布。\n除了以上的关键特性，Nydus 可以灵活地配置成 Linux FUSE 用户态文件系统、基于轻量虚拟化技术容器的 Virtio-fs daemon，或者 Linux 内核磁盘文件系统 EROFS 的用户态 on-demand 数据下载服务：\n1、轻量化地集成到 vm-based 容器运行时。现在 KataContainers 正在考虑原生地支持 Nydus 作为容器镜像加速方案。\n2、Nydus 和 EROFS 紧密合作，期望可以直接使用 EROFS 作为容器镜像的文件系统。相关修改的第一部分已经合并入 Linux Kernel v5.16。\nNydus 部署形态 支持 Runc 时，Nydus 作为 FUSE 用户态文件系统进程：\n支持 KataContainers 时，Nydus 作为 Virtio-fs daemon：\n目前 EROFS 正在尝试联合 Fscache 一起，以内核文件系统 EROFS 直接作为容器 Rootfs：\nNydus 将与 Containerd 社区紧密合作，致力于提供更优秀的容器镜像加速方案，提高镜像的存储和分发效率，提供安全可靠的容器镜像服务。\n求贤若渴： 关于蚂蚁集团可信原生技术部安全容器和存储团队\n在蚂蚁集团内部主要负责公司内部容器运行时和云原生存储技术，是公司数据链路的守护者，运行时环境的看门人。我们团队也是 Kata Containers 的创立者，镜像加速服务 Nydus 的发起者，分布式事务服务 Seata 的维护者，也维护着公司内数据访问组件 ZDal/ZCache/XTS 等产品。\n我们是开源精神的信徒，也是实现开源软件和公司业务双赢的践行者。我们是一个关注业务、关注业界前沿、关注基础设施技术，更关心成员成长的团队。目前我们正在招收 2023 届实习生，有兴趣的可以参考蚂蚁集团2023届实习生招聘。\n联系邮箱：liyuming.lym@antgroup.com\n本周推荐阅读 恭喜 李志强 成为 Layotto committer！\n社区文章｜MOSN 路由框架详解\nHAVE FUN | SOFARegistry 源码解析\nBabaSSL：支持半同态加密算法 EC-ElGamal\n","date":1647932400,"description":"Nydus 镜像加速插件迁入 Containerd 旗下","dir":"blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ad4cca5257474169e5ca87f15437235d","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","publishdate":"2022-03-22T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","summary":"文｜葛长伟（花名：川朗 ) 蚂蚁集团技术专家 负责容器镜像加速项目 Nydus 的开发和维护，专注于容器镜像存储、持久存储和文件系统领域。 本文 1344 字 阅读 4 分钟 前","tags":["SOFAStack"],"title":"Nydus 镜像加速插件迁入 Containerd 旗下","type":"blog","url":"/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","wordcount":1715},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@rust-rust 提问：\n 建议开发各种语言的 API。\n A：Java 和 Python 在设计中，争取注册到 jsse 里。\nBabaSSL：https://github.com/BabaSSL\n@会飞的小胖子 提问：\n tengine 现在可使用 BabaSSL 了吗？\n A：tengine master 已经支持，稳定版还得等等。\nBabaSSL：https://github.com/BabaSSL\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nSOFAJRaft 本周发布 发布 1.3.10 版本，主要变更如下：\nFeatures： 优化 read-index 读，增加 maxReadIndexLag 参数设置快速失败阈值\nLogEntry 增加切片读取 API\n在删除 rocksdb 大 range 数据时，优化空间回收速度\n在节点过载时，将原有的快速失败策略修改为反压策略，依赖于这个特性的用户推荐升级\nBug Fixes： 升级 Log4j 以解决安全漏洞\nsnapshot 文件使用 atomic move 避免文件重新命名是被损坏\n修复 Counter demo 不兼容 gRPC 的问题\n修复对 snapshot 并行压缩/解压的配置项错误\n修复在某种竞争条件下 Replicator 可能停止发送心跳的 bug\n「详细参考」：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.10\n本周推荐阅读 SOFAArk Committer 专访｜看它不爽，就直接动手改！\n HAVE FUN | SOFARegistry 源码解析\n 探索 SOFARegistry（一）｜基础架构篇\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1647586800,"description":"SOFA Weekly | Committer 聊天室、SOFAJRaft 本周发布、新手任务","dir":"blog/sofa-weekly-20220318/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"71d080ef0a61bca724b03bf0f44daa07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220318/","publishdate":"2022-03-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220318/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Committer 聊天室、SOFAJRaft 本周发布、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220318/","wordcount":1155},{"author":"连文湧","categories":"SOFAStack","content":" 数据表结构要求 以应用级服务发现元数据表为例\n param type description data_center String local data center revision String revision app_name String appName client_version String clientVersion base_params String base_params service_params String service_params deleted boolean delete or no gmt_create Date create time gmt_modified Date last update time 写入 写入缓存 cachedExecutor.execute 执行缓存写入操作防止无法瞬间处理大量相同数据写入操作。防止大量节点上报相同的应用级服务发现元数据。\npublic V execute(K key, Callable\u0026amp;lt;V\u0026amp;gt; callable) throws Exception { V v = cache.getIfPresent(key); if (v != null) { //发现元素，命中+1 hitCount.increment(); return v; } return cache.get( key, () -\u0026amp;gt; { //未发现元素，未命中+1 missingCount.increment(); onMiss(key); return callable.call(); }); } 二参数的 execute 统计修订号revision的命中和未命中次数统计 metrics，在通讯数据压缩暴露到 prometheus。\n写入数据 protected void refreshEntryToStorage(AppRevisionDomain entry) { try { cachedExecutor.execute( entry.getRevision(), () -\u0026amp;gt; { //判断是否执行replace写入数据 if (appRevisionMapper.heartbeat(entry.getDataCenter(), entry.getRevision()) == 0) { appRevisionMapper.replace(entry); } //省略日志操作 } } cachedExecutor 默认指定 silentMs=10s，当缓存项在指定的时间段内没有更新就会被回收（移除 key），需要等待获取新值才会返回。10s 内没有更新说明数据量不大，也不需要进行写入缓存的操作。\n通过 hearbeat() 底层通过 update 原子判断数据是否存在。刷新 gmt_modified 字段时间防止被误删。\nupdate app_revision set gmt_modified=CURRENT_TIMESTAMP where data_center = #{dataCenter} and revision=#{revision} and deleted = \u0026#39;0\u0026#39; 当 update 没有命中的时候，使用 replace，保证能生成一个新的 id，用于后续的 watch 方法监听表获取元素更新变化，并刷新 gmt_modified 防止字段超时被删除。\nreplace into app_revision( data_center, revision, app_name, client_version, base_params, service_params, deleted, gmt_create, gmt_modified ) values ( #{dataCenter}, #{revision}, #{appName}, #{clientVersion}, #{baseParams}, #{serviceParams}, #{deleted}, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP ) 获取数据增量改变 Watch 数据库没有提供订阅的操作，watch 方法缓存最新 id 值，增量读取数据库中更新的 id 值并更新最新的 id 值保证 lastLoadId 一直保持最新的状态\nprivate void watch() { syncStart(); try { long start = lastLoadId; if (listStableEntries(start, 1).size() == 0) { return; } logger.info(\u0026amp;quot;start watch from {}\u0026amp;quot;, start); long maxId = listToTail( (T entry) -\u0026amp;gt; { container.onEntry(entry); logger.info(\u0026amp;quot;watch received entry: {}\u0026amp;quot;, entry); }, start, 100); logger.info(\u0026amp;quot;end watch to {}\u0026amp;quot;, maxId); lastLoadId = maxId; } finally { syncEnd(); } } listStableEntries 提供从数据库获取最新数据的 id 值的方法，写入数据的方法底层通过 replace 写入，因此一定会有新的 id 生成。\n机制存在问题：如果数据中间出现不连续的间断，无法得到更新后存在间隔的 id 值。\n此方法主要列出所有创建完成 1s 后更新的元素。\nif (entry.getGmtCreate().getTime() \u0026amp;gt;= now.getTime() - DB_INSERT_DELAY_MS) { break; } 其中 DB_INSERT_DELAY_MS=1s\n为什么是 1s？\n内部是分布式数据库，表内数据会被拆分到多个机器上，每台机器批量获取 id 属性，此时如果大量并发插入，可能产生 id 值高的已经入库，而低 id 还没有完全写入，这时 watch 方式会出现问题，漏掉低 id 值的数据，直到 list 调用才能被重新填入。而这种问题产生的间隔很短，因此 1s 的间隔能保证id值较低的数据已经被填入。\nlistToTail 方法返回当前最大可靠 id 值\nprivate long listToTail(EntryCallable\u0026amp;lt;T\u0026amp;gt; callable, final long start, final int page) { long curStart = start; while (true) { List\u0026amp;lt;T\u0026amp;gt; entries = listStableEntries(curStart, page); if (CollectionUtils.isEmpty(entries)) { break; } for (T entry : …","date":1647586800,"description":"源码解析｜数据表监听","dir":"projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1343a0bf78782bc53e05233bbdcde0cf","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","publishdate":"2022-03-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","summary":"数据表结构要求 以应用级服务发现元数据表为例 param type description data_center String local data center revision String revision app_name String appName client_version String clientVersion base_params String base_params service_params String service_params deleted boolean delete or no gmt_create Date create time gmt_modified Date last update time 写入 写入缓存 cachedExecutor.execute 执行缓存写","tags":["“源码解析”"],"title":"源码解析｜数据表监听","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","wordcount":1597},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展\n 活动时间：03 月 17 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#26 解读 BabaSSL ：项目概况和最新进展 从数据存储到网络通信，从密码合规再到隐私计算，这些场景都离不开密码学算法和协议。\nBabaSSL 密码库作为蚂蚁和阿里的统一基础密码库，广泛的应用在各类蚂蚁和阿里的业务当中，提供了 TLS 通信、数据加密、国密合规等关键的密码学相关能力，确保了各项业务平稳、安全、合规的运行。\nBabaSSL 自 2020 年开源以来，在行业内得到了广大用户的使用和验证。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 张成龙（花名：刻一） -蚂蚁集团技术专家\n-负责蚂蚁 BabaSSL 密码库核心研发\n议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:50 BabaSSL 项目的概况和最新进展 张成龙（花名：刻一），蚂蚁集团技术专家，负责蚂蚁 BabaSSL 密码库核心研发\n你将收获 1.了解 BabaSSL 项目的诞生背景\n2.了解 BabaSSL 密码库的主要功能和技术特点\n3.了解 BabaSSL 8.3.0 新功能\n4.了解 BabaSSL 的未来发展趋势\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1647500400,"description":"03 月 17 日周四晚 19 点，线上直播第 26 期。","dir":"activities/sofa-channel-26/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e998e41cd8ea96210efdbecbb3ae0e95","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-26/","publishdate":"2022-03-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-26/","summary":"概要 活动主题：SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展 活动时间：03 月 17 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展","type":"activities","url":"/sofastack.tech/activities/sofa-channel-26/","wordcount":633},{"author":"曹先胜","categories":"SOFAStack","content":" 文｜曹先胜\ne签宝中间件开发\n负责e签宝中间件开发和维护，包括 MQ、网关、微服务、数据同步、全链路压测等\n贡献者前言 「 开源就是在使用中，共同成长的过程 」\n从 2018 年学习 SOFAStack 的一些开源项目，到如今深入使用 MOSN，伴随着 SOFA 走到四周年。\n因为兴趣也接触了不少的开源社区，唯独对 SOFA 社区的组件体验颇多， 例如 SOFAArk、SOFARPC、MOSN。长年混迹在钉钉群里提问题，都能得到及时回复，这对我们研究 MOSN 有很大的帮助。也因此通过 MOSN 的代码设计，学习到了很多关于 Sidecar 的设计理念。\n我们使用 MOSN 的出发点是公司框架使用了很多的中间件，每个中间件有自己的依赖，这些依赖经常性的会发生冲突。虽然我们使用了类似 Spring Boot 的 Pom 管理机制，但升级框架过程中，如果有同学自行引入了 jar 包，就不可避免的会发生 jar 冲突。为了解决这个问题，我们调研了很多方案，最终认为 Service Mesh 是解决这个问题的一个比较合适的方案。\n同时，也调研了一些其他的开源产品，经过内部讨论和各种取舍，我们选择了MOSN。\n在使用 MOSN 时，因为要对接 Eureka，需要进行动态路由，而官网关于路由的文章不是很多。因此，在自己和烈元老师学习后，总结了这样一篇路由分享文章。\nMOSN 作为网络边缘代理组件，路由功能是核心功能，本文将介绍 MOSN 路由如何使用，以及 MOSN 路由的一些高级使用技巧，欢迎大家留言指导。\n路由基本设计 在 MOSN 的路由设计中，Cluster 和 Route 是高度关联的，说白了 Route 的配置，就是为了表达如何准确找到你想找到的 Cluster，另外一个 Cluster 可以有多个 Host 机器。\n例如一个 Cluster 有 100 台机器，其中有 50 台是 v1 版本，50 台是 v2 版本，如何根据一些特定的规则，准确地把请求路由到 v1 版本或者 v2 版本呢？\n再例如，我想根据 Header 里的某个值，再将这个值和“配置中心”里的某个值进行计算，才能找到 Cluster，那么我该如何配置呢？\n 首先，我们看最简单的路由设置。 上图是一个简单的 Json 配置。其中，Cluster Manager 和 Routers 的配置是路由的关键。我们可以根据 Cluster Manager 配置多个 Cluster，每个 Cluster 配置多个 Host。\n然后在 Routers 配置中，根据一些规则，告诉 MOSN 如何将请求路由到 Cluster 中。\n如下图：\n此配置表示，现在有一个 Rouer 配置名为 Server_Router，有一个虚拟主机，可配置多个域名，这里匹配所有域名。\n同时，这个域名有多个路由配置，这里暂且配置了一个路由配置：前缀匹配，只要是 / 开头的，就转发到 ServerCluster 里的 Host 中，也就是下面的 Cluster Manager 配置里的 ServerCluster。\n这样，就实现了一个简单的 MOSN 路由的配置。\n动态路由 Cluster 大部分情况下，如果我们的路由逻辑很简单，例如根据 Header 里的某个名字，找到对应的 Cluster，代码或者配置就是这么写的：\n、、、java router := v2.Router{ // header 匹配 RouterConfig: v2.RouterConfig{ Match: v2.RouterMatch{ Headers: []v2.HeaderMatcher{ // 这个 header 匹配, 就转发到 app.Name cluster. { Name: \u0026amp;ldquo;X-service-id\u0026amp;rdquo;, Value: app.Name, }, }, }, // cluster 名称匹配. Route: v2.RouteAction{ RouterActionConfig: v2.RouterActionConfig{ ClusterName: app.Name, }, }, }, } r.VirtualHosts[0].Routers = append(r.VirtualHosts[0].Routers, router) 、、、\n上面代码的意思是如果 Header 里有 X-service-id 这个 kv，那么就能找到下面 RouteAction 对应的 Cluster 了。\n那如果是更复杂的逻辑呢？\n比如利用请求里的 Header 和“配置中心”的某个值进行计算，如何才能找到 Cluster呢？\n此时，通过配置已经无法解决这个需求，因为这其中涉及到了计算逻辑，MOSN 通过动态配置可以支持该需求。\n如下图配置：\n我们设置了一个（\u0026amp;rdquo;Cluster_Variable\u0026amp;rdquo;: \u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;） 的 KV 配置。\n同时，我们还需要在 StreamFilter 中，利用变量机制设置 key 为 “My-ClusterVariable” 的 Value ，这个 Value 就是计算出来的 Cluster 名称。\n代码如下：\n、、、Java // 先注册这个 key 到变量表中。 func init() { variable.Register(variable.NewStringVariable(\u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;, nil, nil, variable.DefaultStringSetter, 0)) }\nvar clusterMap = make(map[int]string, 0)\nfunc (f *MyFilter) OnReceive(ctx context.Context, headers api.HeaderMap, buf buffer.IoBuffer, trailers api.HeaderMap) api.StreamFilterStatus { l := len(clusterMap) // 找 Cluster cluster := // 执行一些计算 // 设置到上下文变量中。这个 key 必须和配置文件中保持一致。 variable.SetString(ctx, \u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;, cluster) return api.StreamFilterContinue } 、、、\nMOSN Subset 如上面所述，我们经常有在一个集群里有多个版本，如何根据某些标签将请求路由到指定的版本呢？\n通常，我们会使用 Subset 方案，即“子集合”。可在一个 Cluster 里面，为每个应用打标。同时我们的路由也配置相关的配置（MOSN 称为 Metadata），实现较为复杂的路由。\nMOSN 官方文档中，简单介绍了 Metadata 的使用。\n下面让我们更详细的介绍 Subset 的使用：\n上图中左边是 Cluster Host 配置，右边是 Router 配置。\n这个路由配 …","date":1647327600,"description":"社区文章｜MOSN 路由框架详解","dir":"blog/community-article-mosn-routing-framework-explained/","fuzzywordcount":3100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5de6ebad45acd0c8edc9e9b104c8c333","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","publishdate":"2022-03-15T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","summary":"文｜曹先胜 e签宝中间件开发 负责e签宝中间件开发和维护，包括 MQ、网关、微服务、数据同步、全链路压测等 贡献者前言 「 开源就是在使用中，共同成长的","tags":["SOFAStack"],"title":"社区文章｜MOSN 路由框架详解","type":"blog","url":"/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","wordcount":3087},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@麦兜兜 提问：\n 我这边在 MOSN 上新增了一种私有协议，基本路由功能已经跑通了，其他的流量治理相关配置有样例吗？\n A：治理如果是说的限流限速的话，通常 MOSN 里面的 stream filter 基本上都是和协议无关的，都是可以使用的。\n@张宁 提问：\n snapshot 做起来，打快照后会删除日志的，所以调一下打快照的时间间隔。\n SOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 HAVE FUN | SOFARegistry 源码解析\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\nBabaSSL：支持半同态加密算法 EC-ElGamal\n","date":1646982000,"description":"SOFA Weekly | MOSN 社区会议、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220311/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"58a24de0efaa2ed6d21cbdd80894b214","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220311/","publishdate":"2022-03-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220311/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 社区会议、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220311/","wordcount":697},{"author":"王祖熙","categories":"SOFAStack","content":" 文｜王祖熙（花名：金九 )\n蚂蚁集团开发工程师\n负责蚂蚁 Kubernetes 集群容器交付专注于集群交付能力、交付性能及交付 Trace 等相关领域\n—— 数据不出域、可用不可见\n01背 景 随着大数据与人工智能的快速发展，个人隐私数据泄露和滥用时有发生，隐私安全问题也越来越被重视。\n国家于 2020 年施行密码法、2021 年施行个人信息保护法，对个人隐私数据和数据安全加密有更高的要求。\n因此，隐私计算也不断地被提及和关注，源于其有优秀的数据保护作用，使得『数据不出域、可用不可见』，限定了数据的使用场景，防止了数据的泄露，而引起了业界的热捧。\n隐私计算是指在保护数据本身不对外泄露的前提下，实现数据共享和计算的技术集合，共享数据价值，而非源数据本身，实现数据可用不可见。\n 隐私计算对于个人用户来说，有助于保障个人信息安全；\n 对于企业来说，隐私计算是数据协作过程中履行数据保护义务的关键路径；\n 对于政府来说，隐私计算实现数据价值最大化的重要支撑。\n 隐私计算目前在金融、医疗、电信、政务等领域均在开展应用试验，比如：\n银行和金融机构\n在不泄露各方原始数据的前提下，进行分布式模型训练，可以有效降低信贷、欺诈等风险；\n医疗机构\n无需共享原始数据便可进行联合建模和数据分析，数据使用方在不侵犯用户隐私的情况下，可以使用建模运算结果数据，有效推动医疗行业数据高效利用。\n隐私计算的相关技术有多方安全计算 （MPC） 、可信执行环境 （TEE） 、联邦学习 （FL） 、同态加密 （HE） 、差分隐私 （DP） 、零知识证明 （ZKP） 、区块链 （BC） 等等。\n这些技术各有优缺点，隐私计算的产品或者平台也是由这些技术来搭建。\n其中与密码学明显相关的是同态加密，目前同态加密算法的开源项目各有千秋，用户使用比较复杂。BabaSSL 作为基础密码库，应该提供一套简单易用和高效的同态加密算法实现和接口，让上层应用更方便简单地使用同态加密算法。\n此外，随着隐私计算技术的兴起，蚂蚁集团推出了开箱即用、软硬件结合的隐私计算基础设施，一站式解决方案，即可信原生一体机。\nBabaSSL 作为蚂蚁可信原生一体机中的核心基础软件密码库，将同态加密等隐私计算所需的相关密码学能力整合其中，为可信原生一体机的用户带来更加便捷高效的使用体验。\n02 同态加密 同态加密 （Homomorphic Encryption, HE） 是指满足密文同态运算性质的加密算法，按性质分为加法同态和乘法同态：\n加法同态\n乘法同态\n同态加密后得到密文数据，对密文数据进行同态加法或者乘法得到密文结果，将密文结果同态解密后可以得到原始数据直接加法或者乘法的计算结果。\n如下图：\n根据满足加法和乘法的运算次数又分为：全同态加密和半同态加密。\n全同态加密\n（ Fully Homomorphic Encryption, FHE ）\n1.支持任意次的加法和乘法运算\n2.难实现、性能差 （密钥过大，运行效率低，密文过大）\n3.主流算法：Gentry、BFV、BGV、CKKS\n4.需要实现的接口\n半同态加密\n（Partially Homomorphic Encryption, PHE）\n1.只支持加法或乘法中的一种运算，或者可同时支持有限次数的加法和乘法运算\n2.原理简单、易实现、性能好\n3.主流算法：RSA、ElGamal、Paillier\n4.需要实现的接口：\n*（1）KeyGen()： 密钥生成算法，用于产生加密数据的公钥 PK（* Public Key）和私钥 SK（Secret Key），以及一些公共参数 PP（Public Parameter）。\n*（2）Encrypt()： 加密算法，使用 PK 对用户数据 Data 进行加密，得到密文 CT（Ciphertext）。*\n*（3）Decrypt()： 解密算法，使用 SK 对密文 CT 解密得到数据原文 PT（Plaintext）。*\n*（4）Add()： 密文同态加法，输入两个 CT 进行同态加运算。*\n*（5）Sub()： 密文同态减法，输入两个 CT 进行同态减法算。*\n*（6）ScalaMul() 或者 Mul() ：密文同态标量乘法，输入一个 CT 和一个标量 PT，计算 CT 的标量乘结果。*\nEC-ElGamal 原理\nElGamal 加密算法是基于 Diffie-Hellman 密钥交换的非对称加密算法，EC-ElGamal 是 ECC 的一种，是把 ElGamal 移植到椭圆曲线上来的实现，主要计算有：椭圆曲线点加、点减、点乘、模逆和离散对数。\n以下是 EC-ElGamal 的算法原理：\n公共参数\n1.G：椭圆曲线基点\n2.SK：私钥，SK=d\n（d 是 0 到椭圆曲线的阶 q 之间的随机数）\n3.PK：公钥，PK=dG\n加密\n1.明文 m，随机数 r\n2.计算密文 C：\n（3）明文 m 的取值范围为模 order(G) 的模空间，但实际使用时 m 需限制为较小的数 （例如 32 比特长度） ，否则椭圆曲线离散对数问题 （ECDLP） 无法求解。\n解密\n1.计算 rPK：\n2.计算 mG：\n3.计算 mG 的 ECDLP，获得明文 m。\n密文加法、密文减法\n1.两个密文：\n2 .密文加：\n对 2 个密文的 2 个 ECC 点分别做点加，共 2 个点加，公式如下：\n3.密文减：\n对 2 个密文的 2 个 ECC 点分别做点减，共 2 个点减，公式如下：\n密文标量乘法\n1.密文\n2.对密文的 2 个 ECC 点分别用 𝑚_2 做点乘，共 2 个点乘，公式如下：\n3.如上公式与明文m2m1的同态加密结果一致：\n这里 r=m2r1\n03 算法实现 接口定义\n对象相关接口\n1.上下文对象：\nEC_ELGAMAL_CTX，该对象用来保存公私钥以及一些其他内部用到的信息，是 EC-ElGamal 算法其他接口的第一个参数。\n接口如下：\n//创建 EC_ELGAMAL_CTX 对象，key 为 ECC 公钥或者私钥的 EC_KEY 对象 2.解密表对象：\nEC_ELGAMAL_DECRYPT_TABLE，该对象用来保存解密表的内部信息。椭圆曲线离散对数问题（ECDLP）只有爆力破解的方法可求解，而爆力破解的速度比较慢，通常的做法是使用小步大步算法（Baby-Step，Giant-Step，BSGS）。总体思想是提前将所有可能的明文结果提前运算后，保存到 hash 表中，下次只需要进行少量的运算和 hash 表查找就可以得到结果，大大提高 ECDLP 的解密效率，但解密表的初始化可能比较慢，而且解密表的实现事关解密速度，后面考虑可以开放接口的实现给上层应用，所以这里先定义了一个解密表的对象和默认实现。\n接口如下：\n//创建 EC_ELGAMAL_DECRYPT_TABLE 对象 //decrypt_negative 为 1 时表示该解密表可以解密负数，初始化解密表时将可能的负数运算后插入到 hash 中。 EC_ELGAMAL_DECRYPT_TABLE *EC_ELGAMAL_DECRYPT_TABLE_new(EC_ELGAMAL_CTX *ctx, int32_t …","date":1646809200,"description":"BabaSSL：支持半同态加密算法 EC-ElGamal进","dir":"blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"efc7daaf960e5998f9fee0a1457a986e","permalink":"https://sofastack.github.io/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","publishdate":"2022-03-09T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","summary":"文｜王祖熙（花名：金九 ) 蚂蚁集团开发工程师 负责蚂蚁 Kubernetes 集群容器交付专注于集群交付能力、交付性能及交付 Trace 等相关领域 —— 数据不出域、可用不可见 01","tags":["SOFAStack"],"title":"BabaSSL：支持半同态加密算法 EC-ElGamal","type":"blog","url":"/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","wordcount":3244},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@冷建伟 提问：\n 启动 SOFABoot 报错：Can not found binding converter for binding type bolt。跟到源码发现：bindingTypeBindingConverterMap 只有 jvm，没有 bolt。跟到源码发现 SPI load 的 converter 只有 JVM。版本：runtime-sofa-boot-starter-3.1.4.jar。想问下是不是要升级我的 SOFA SDK 版本 ？\n A：这个引入 rpc starter 即可。\n@leon 提问：\n SOFARegistry 是不需要用 K8s 吗？\n A：SOFARegistry 在内部是基于 K8s 部署的，提供更细粒度更高性能的服务发现。\n 为什么不是想办法优化 K8s 服务发现性能，而是搞代码侵入性的方案？\n A：基于 K8s 的实现的无侵入式服务发现是云原生下的一套较为后期和理想的方案，这也是 SOFARegistry 后续演进的规划之一。\n目前依然采用侵入的发布订阅模式，一是性能的考量，现有的 K8s 很难支撑起数千万级别数量的服务以及稳定推送延迟的要求；二是迁移有一个过程，对大量现有应用进行服务发现的改造是一个很长周期，无侵入式服务发现会采用逐渐接入的方式。\n目前重点还在于如何更好更稳定的支撑起超大规模集群的问题上。\n@来永国 提问：\n SOFATracer 加了 sofa-tracer-rocketmq-plugin 扩展包，还需要做什么配置吗？\n A：需要配置一下 SendMessageHook 和 ConsumeMessageHook 这两个 hook，分别是：SofaTracerSendMessageHook、SofaTracerConsumeMessageHook。\n本周发布 BabaSSL 开源发布 8.3.0 版本，主要更新如下：\n修复 CVE-2021-4160\nopenssl enc 命令支持 wrap 模式\nASYNC: 支持 job 的嵌套\n支持 TLS 证书压缩 (RFC 8879)\n发行版上游 patch 集合合并 [hustliyilin]\n支持 NTLS session ticket\n支持祖冲之消息完整性算法 128-EIA3\n支持 NTLS 客户端认证\n移除 ARIA 算法\n支持国密合规的软随机数生成器\n支持半同态加密算法 EC-ElGamal\n在 NTLS 中支持 RSA_SM4 加密套件\nARM 平台上提供 SM3 和 SM4 的性能优化\nSM4 算法逻辑优化以提升性能 [zzl360]\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nMOSN 本周发布 发布 MOSN V0.26.0 版本，主要变更如下：\n主要更新如下：\n XProtocol 进行了重构，XProtocol 不再是一种协议，而是便于协议扩展实现的框架\n 新增 ip_access filter，基于来源 IP 的 ACL 控制器\n 支持 go plugin 加载协议转化插件，并支持动态选择协议转换插件\n 支持动态设置上游协议，使用 transcoder filter 来替换 Proxy 中的协议转换\n 其他优化与BUG Fix\n 「详细参考」：\nhttps://mosn.io/blog/releases/v0.26.0/\n本周推荐阅读 BabaSSL 发布 8.3.0｜实现相应隐私计算的需求\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1646377200,"description":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","dir":"blog/sofa-weekly-20220304/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9e14d6832e36d94e116c499a9ef62278","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220304/","publishdate":"2022-03-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220304/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |BabaSSL 发布新版本、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220304/","wordcount":1478},{"author":"小蚂蚁","categories":"SOFAStack","content":" 在近日中国科协召开的 2022“科创中国”年度会议上，中国工程院院士周济发布了 2021“科创中国”开源创新榜单。\n蚂蚁集团开发的可信执行环境隐私计算操作系统 Occlum 入选“科创中国”开源创新榜年度优秀开源产品。\n其中，可信执行环境隐私计算操作系统 Occlum 也是该榜单中唯一聚焦隐私计算领域的入选产品。\nOcclum 发展里程 2015 年 蚂蚁集团开始布局隐私计算，成功推出了 TEE 开源操作系统 Occlum。目前，Occlum 也是蚂蚁集团所有隐私计算业务的 TEE 底座，支撑了蚂蚁隐私计算的核心场景。\n2019 年 Occlum 正式开源，是国内第一个面向可信执行环境(Trusted Execution Environments，简称 TEE)的隐私计算操作系统，解决了云端 TEE 技术额外的功能限制和兼容性问题，降低了隐私计算应用开发门槛。\n目 前 Occlum 已捐赠到由微软、谷歌、IBM、阿里巴巴、腾讯等领先科技公司成立的隐私计算联盟(Confidential Computing Consortium,The LinuxFoundation)，是联盟中唯一由中国发起的项目。\n开源隐私计算操作系统 Occlum 还支持了阿里巴巴、微软等公司的云端隐私计算业务场景和大批隐私计算创业公司的隐私计算平台。国际著名开源项目也在使用 Occlum 开源产品，如 Hyperledger Avalon、Inclavare Container 等。\nOcclum 获得了产、学、研多方认可，相关技术成果已在操作系统领域顶级会议 ASPLOS 2020 发表。\n从 1869 项开源产品中被推选出来，Occlum 长期以来在基础技术领域的努力和坚持得到了认可。\n开源路漫漫，我们也很开心地看到，中国开发者正在成为全球开源社区的重要力量。\n对 SOFAStack - Occlum 感兴趣的话\n👏 等你加入我们！\n本周推荐阅读 BabaSSL 发布 8.3.0｜实现相应隐私计算的需求\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n从 generator 的角度看 Rust 异步代码\n","date":1646290800,"description":"Occlum 入选 2021“科创中国”开源创新榜","dir":"blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3d995f09ef72a3b41105b1315cb3c29f","permalink":"https://sofastack.github.io/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","publishdate":"2022-03-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","summary":"在近日中国科协召开的 2022“科创中国”年度会议上，中国工程院院士周济发布了 2021“科创中国”开源创新榜单。 蚂蚁集团开发的可信执行环境隐私","tags":["SOFAStack"],"title":"Occlum 入选 2021“科创中国”开源创新榜","type":"blog","url":"/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","wordcount":723},{"author":"SOFAStack","categories":"SOFAStack","content":" BabaSSL 8.3.0 稳定版本发布！ 密码学开源项目 BabaSSL 近日发布了 8.3.0 稳定版本，该版本中提供了若干 bug 修复以及较多的新特性支持。\n从具体特性角度来看，BabaSSL 8.3.0 版本在国际前沿技术标准、国内密码合规能力以及国密算法的性能优化上均进行了能力的提升。其中：\n前沿技术标准： RFC8879 所定义的 TLS 证书压缩功能为 TLS 握手带来了很大的性能提升、进一步降低了 TLS 加密通信时的延迟，对于提升用户体验起到了很好的增强，可直接降低 TLS 握手带宽 80% 以上。\n国内密码合规能力： 支持 NTLS session ticket、客户端认证以及 RSA_SM4 加密套件，为目前国内各行业也在进行的国密改造提供了功能上的大力支持；\n而对国密合规的软随机数生成器的支持，更是满足了国密改造过程中的合规性要求。\n国密算法性能优化： 此次 BabaSSL 连同 ARM、阿里云对国密 SM3 和 SM4 算法在 ARM v8 架构上进行了特殊硬件指令的优化，使得 BabaSSL 在具备相关指令集的 ARM 架构 CPU 上可以取得更好的 SM3 和 SM4 的计算性能。\n例如，在阿里云倚天 710上，SM3 获得最高 74% 以及 SM4 算法最高 36 倍的性能提升；此外，SM4 算法逻辑的 C 语言优化，也实现了在通用 CPU 上性能的提升。\nBabaSSL 8.3.0 主要存在如下方面的更新： 修复 CVE-2021-4160\n openssl enc 命令支持 wrap 模式\n ASYNC: 支持 job 的嵌套\n 支持 TLS 证书压缩 (RFC 8879)\n 发行版上游 patch 集合合并 [hustliyilin]\n 支持 NTLS session ticket\n 支持祖冲之消息完整性算法 128-EIA3\n 支持 NTLS 客户端认证\n 移除 ARIA 算法\n 支持国密合规的软随机数生成器\n 支持半同态加密算法 EC-ElGamal\n 在 NTLS 中支持 RSA_SM4 加密套件\n ARM 平台上提供 SM3 和 SM4 的性能优化\n SM4 算法逻辑优化以提升性能 [zzl360]\n 值得一提的是，针对数据安全和隐私保护市场的兴起，BabaSSL 8.3.0 中实现了对半同态加密算法 EC-ElGamal 的支持，隐私计算领域的用户可以便捷的使用该算法实现相应隐私计算的需求，并同时利用 BabaSSL 提供的国密能力实现技术合规。\n此外，BabaSSL 目前作为蚂蚁隐私计算一体机中默认集成的软件密码库，为蚂蚁隐私计算一体机的用户提供统一的密码学 API 接口，方便隐私计算应用程序的开发和调试。\n欢迎下载 BabaSSL 8.3.0 版本，下载地址：\nhttps://github.com/BabaSSL/BabaSSL/releases/tag/8.3.0\nBabaSSL 是什么 ？ BabaSSL 是一个提供现代密码学算法和安全通信协议的开源基础密码库，为存储、网络、密钥管理、隐私计算等诸多业务场景提供底层的密码学基础能力。实现数据在传输、使用、存储等过程中的私密性、完整性和可认证性的保证，为数据生命周期中的隐私和安全提供保护能力。\n作为国内稀缺的密码学开源项目，BabaSSL 填补了国内信息基础设施领域相关产品的空白，是我国建设国产密码学大生态、解决密码学技术“卡脖子”问题、发展前沿密码学技术的关键一环。\n除了在国家商用密码算法领域之外，BabaSSL 还在前沿密码学领域进行了支持，包括隐私计算场景下所需的各种密码学算法以及为了应对量子计算而产生的后量子密码学算法等。\nBabaSSL 对国际和国内的新型技术标准采用快速跟进的策略，因此支持的功能十分丰富。同时基于蚂蚁和阿里海量的用户场景，其性能和稳定性也达到了互联网生产级别。\n自 2020 年开源以来，BabaSSL 也在行业内得到了广大用户的使用和验证，并应用到了众多业务场景里。\nBabaSSL 的前世今生 BabaSSL 诞生于蚂蚁集团和阿里集团内部，目前作为蚂蚁和阿里的统一基础密码库，广泛应用在各类蚂蚁和阿里的业务当中，提供了 TLS、数据存储、国密合规等关键的密码学相关能力，确保了各项业务平稳、安全、合规的运行。\n2020 年进行开源以来，BabaSSL 将蚂蚁和阿里内部所积累的密码学技术能力提供给业界使用，同时在申请商用密码产品软件密码模块一级资质，也是首个有望获得商用密码产品型号证书的开源密码学产品。\n从具体场景来看，有如下三个方面，分别是存储、网络和端上的设备。其中网络服务的场景，是 BabaSSL 最大的支撑场景，例如淘宝、天猫、阿里云等各种涉及到链路加密的服务器端。此外移动端 App，例如支付宝手机 App 中集成了 BabaSSL 来实现多种密码学的能力。\n1. 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了 有了基础国密算法支持，我们在 AnolisOS 上构建出一个围绕国密算法展开的基础软件生态，同时它也是一个全栈国密解决方案：从底层固件，内核，到基础密码学库，在主要链路上做国密改造，最终形成一个完整的基于国密的安全信任链条。\n2. RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海 TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。随着 TLS 1.3+ 国密正式成为了国家/国际层面均认可的标准（RFC8998），我们也正式在 BabaSSL 中支持了相关能力并将其开源，并建设了 BabaSSL 社区。\n3. TLS 握手带宽直降 80%，BabaSSL 是怎么做到的 为了保障数据的安全性，通常使用 TLS/SSL 进行加密传输。当客户端访问服务器后台时，客户端会先和服务器进行 TLS 握手。RFC 8879 TLS Certificate Compression 就是为了解决这个问题，在 TLS 1.3 握手时提供证书压缩功能，大大降低数据传输，减少 TLS 握手的带宽消耗呢。\n4. Tengine + BabaSSL ，让国密更易用！ 国内著名 Web 服务器和反向代理开源软件 Tengine 完成了对 BabaSSL的适配工作。Tengine 对 BabaSSL 提供的特殊 API 进行了适配，并增加对 NTLS 相关能力的支持。无需额外的 patch 或者代码改动，从用户使用的角度进一步提升了便利性。\n对密码学、隐私计算感兴趣的话\n等你加入我们！\n本周推荐阅读 Tengine + BabaSSL ，让国密更易用！\nTLS 握手带宽直降 80%，BabaSSL 是怎么做到的\nRFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n","date":1646204400,"description":"BabaSSL 发布 8.3.0｜实现相应隐私计算的需求","dir":"blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f9693f85dce6fd979f0323ae3797b3cc","permalink":"https://sofastack.github.io/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","publishdate":"2022-03-02T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","summary":"BabaSSL 8.3.0 稳定版本发布！ 密码学开源项目 BabaSSL 近日发布了 8.3.0 稳定版本，该版本中提供了若干 bug 修复以及较多的新特性支持。 从具体特性角度来看，BabaSSL 8.3.0 版","tags":["SOFAStack"],"title":"BabaSSL 发布 8.3.0｜实现相应隐私计算的需求","type":"blog","url":"/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","wordcount":2108},{"author":"李旭东","categories":"SOFAStack","content":" 简介 SOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群，具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n蚂蚁生产集群 — SOFARegistry 支撑 1000 万服务发布者、4000 万服务订阅者，在业务应用大规模变更触发千万级别推送量的场景下，推送延迟的 p99 依然能够保持在 7s 以下。\n《认识 SOFARegistry》 这一系列文章将会基于 SOFARegistry 新版本（V6）的代码，讲解注册中心在超大规模集群场景下落地的解析与实践，同时介绍 SOFARegistry 的各项功能，方便业务落地。\n部署架构 SOFARegistry 现有的架构设计：采用双层存储架构，外加一个负责内部元数据管理的 meta 组件。\nSOFARegistry 的角色分为 4 个: client、session、data、meta。\n角色分工如下：\nClient\n提供应用接入服务注册中心的基本 API 能力，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\nSessionServer ｜ 会话服务器\n负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\nDataServer ｜ 数据服务器\n负责存储具体的服务数据，数据按 dataInfoId 进行分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模增长而扩容。\nMetaServer ｜ 元数据服务器\n负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n借助双层数据分片的架构，SOFARegistry 具有了支撑海量数据的基石\n● 支持海量数据：每台 DataServer 只存储一部分的分片数据，随数据规模的增长，只要扩容 DataServer 服务器即可。\n● 支持海量客户端：连接层的 SessionServer 只负责跟 Client 打交道，SessionServer 之间没有任何通信或数据复制，所以随着业务规模的增长，SessionServer 可以较轻量地扩容，不会对集群造成额外负担。\n数据结构 作为注册中心的基础功能，SOFARegistry 提供发布订阅的接口：Subscriber、Publisher。\n在服务发现场景下，Subscriber 需要通过服务名称从注册中心订阅到多个服务方的地址，进行负载均衡的访问。\n当存在服务方机器宕机时，注册中心通知所有的订阅方从服务列表中摘除这个 IP 地址，这样就不会再访问宕机的机器。\n下面给出简化后的发布者和订阅者的字段，贴合上述服务发现的需求。\nclass Subscriber{ String dataId; // 服务名称 String group; // 业务类型，比如RPC、MSG等等 String instanceId; // 租户名称 String zone; // 所在分区，结合scope实现逻辑隔离 ScopeEnum scope; // 订阅范围: zone、dataCenter、global } class Publisher{ String dataId; String group; String instanceId; String zone; List\u0026amp;lt;String\u0026amp;gt; dataList; // 发布的数据, sofarpc 用法中常见url } 常见用法（JAVA SDK）\n发布者\n// 构造发布者注册表 PublisherRegistration registration = new PublisherRegistration(\u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); // 将注册表注册进客户端并发布数据 Publisher publisher = registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); // 如需覆盖上次发布的数据可以使用发布者模型重新发布数据 publisher.republish(\u0026amp;quot;10.10.1.1:12200?xx=zz\u0026amp;quot;); 订阅者\n// 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { @Override public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, global String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); registration.setScopeEnum(ScopeEnum.global); // 将注册表注册进客户端并订阅数据，订阅到的数据会以回调的方式通知 SubscriberDataObserver Subscriber subscriber = registryClient.register(registration); 更详细的用法文档参考官方文档: https://www.sofastack.tech/projects/sofa-registry/java-sdk/\n特点与优势 这是一张 SOFARegistry 和其他注册中心产品的特性对比图，可以看出相比其他产品，SOFARegistry 在功能特性方面还是不足（未来 SOFARegistry 在特性方面会进行完善）。 SOFARegistry 的主要优势还是在于支撑超大规模集 …","date":1646118000,"description":"探索 SOFARegistry（一）｜基础架构篇","dir":"blog/explore-sofaregistry-1-infrastructure/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ae1a4db92cf2dea8d057ba7dede8c440","permalink":"https://sofastack.github.io/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","publishdate":"2022-03-01T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","summary":"简介 SOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群，具有分布式可水平扩容、容量大、推送延迟低、高可","tags":["SOFAStack"],"title":"探索 SOFARegistry（一）｜基础架构篇","type":"blog","url":"/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","wordcount":3704},{"author":"SOFA 团队","categories":"SOFAStack","content":" 2 月 24 日，MOSN 举办了 2022 年首次的社区会议。\nMOSN 社区在会议上提出了新一年的 Roadmap，社区成员分享了 MOSN 在不同场景下落地实践的经验，以及大家一起大开脑洞，探讨了更多我们可以创造的可能性。\nMOSN 社区 Roadmap MOSN 在 2022 年主要的目标是发布 MOSN 1.0，以及开源一个新的开箱即用的产品。同时推动 MOE （ MOSN 2.0 架构）演进，对接更多的生态组件。\n随着 MOSN 的落地用户越来越多，稳定性建设也是今年的重点发展方向，让大家用得放心。\n社区会议分享嘉宾 来自探探科技、阿里云、去哪儿网的用户，在本次会议中都积极分享了自己的使用案例，供大家借鉴参考。\n探探科技 谢正尧同学详细地列出了 MOSN 落地过程中遇到的问题和踩到的坑，给 MOSN 的后续优化提供了很好的思路。\n有不少坑我们都已经安排上了日程，MOSN 的开发者都赶在填坑的路上。\n阿里云 沐沂同学列出了新财年的规划，和大家分享了边缘的跨集群服务发现场景的租户拆分，以及新的部署形式。\n去哪儿网 佳龙同学比较关注 Roadmap 中的 GC 方面，希望可以引入一些高性能的网络框架，对性能优化方面有更多的需求。\n以及很期待 MOSN 社区的 holmes，希望可以解决查问题时的难题。\nQA 回顾 1.Q：MOE 的落地场景、最佳实践的博客有哪些？\nA：具体内容我们会在 Service Mesh Summit 2022 首届服务网格峰会进行分享。今年会有更多的落地场景，在尝试替换接入层网关，也会试点上线的，可以期待一下！\n2.Q：我可不可以理解为——假如 MOE 在 Envoy 被接收后，可以通过 Go 代码去写一个 filter，让它跑在 Envoy 上，之后我的数据链直接用 Envoy 就可以？\nA：是的，就这个意思。现在我们的 demo 就可以玩起来了，只是有些接口还没标准化，现在我们内部落地的 sofagw 就是这个架构。\n「demo文档」⬇️： https://github.com/mosn/mosn/blob/master/pkg/networkextention/README-cn.md\n3.关于 GC 优化方式的讨论\nA：（1）降低 GC 频率确实是有效的，可以减少长期存活对象的重复 mark。（2）不过这种预分配的，其实不是很灵活，最好的还是动态调整 GC Percent，保持 GC goal 在预期的水位。\n本质上是一个内存换 CPU 的方案，在内存够用的时候，提高 GC goal 的水位。\n我们搞 holmes 内存异常捕获的时候，也考虑过这种情况。https://uncledou.site/2022/go-pprof-heap/\n大家在本次会议中畅所欲言，大开脑洞。也正是与使用用户的沟通交流，让 MOSN 的发展规划和用户需求相辅相承。\n感谢大家的积极配合，在你们的帮助下，MOSN 社区会持续推动性能优化、技术落地，与用户共同成长。\n我们之后还会举办社区会议，比如在 MOSN 发布新版本或者有大进展时。听取用户反馈，同步业界动态，期待下次会议啦～\n想要预定下次的社区会议,了解更多 MOSN 社区动态,钉钉搜索:21992058\n本周推荐阅读 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\nMOSN 多协议扩展开发实践\nService Mesh 在中国工商银行的探索与实践\n云原生运行时的下一个五年\n","date":1646031600,"description":"社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进","dir":"blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ee484f870924be25bf5ccddd91840b89","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","publishdate":"2022-02-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","summary":"2 月 24 日，MOSN 举办了 2022 年首次的社区会议。 MOSN 社区在会议上提出了新一年的 Roadmap，社区成员分享了 MOSN 在不同场景下落地实践的经验，以及大家","tags":["SOFAStack"],"title":"社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进","type":"blog","url":"/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","wordcount":1114},{"author":"陈岸琦","categories":"SOFAStack","content":" 文｜陈岸琦（花名：敖清 )\n蚂蚁集团高级开发工程师\n负责蚂蚁 Prometheus 监控原生功能，在蚂蚁集团的落地与产品化建设\n本文 6566 字 阅读 15 分钟\n前 言 日志和指标是监控不可或缺的两种数据源，为应用系统提供完整的可观测性。\nAntMonitor 作为蚂蚁的统一监控平台，是一款主要以日志方式采集监控数据的监控产品。在社区，开源的云原生监控，主要以 Metrics （指标）的方式实现监控，其中以 Prometheus 为代表。\n并且 Prometheus 监控因其强大的用户功能、结合 PromQL 的数据后分析能力，在业界有广泛的用户群体。实际上已成为开源标准，广泛用于开源 Kubernetes 的集群监控。\nPrometheus 本身是一款单机监控产品，在蚂蚁庞大的高可用集群场景落地，具有一定的局限性和困难，包括但不限于：\n Prometheus 没有提供稳定的、长期的数据存储功能，无法满足蚂蚁场景下对历史数据的查询；\n Prometheus 是有损监控，不保证数据的完整性，无法满足蚂蚁场景下对交易笔数等数据的精确性要求；\n Prometheus 不支持日志监控。\n 但是为了满足用户对 Metrics 监控的需求，经过近两年的努力，我们成功地将 Prometheus 的主要功能融合进了 AntMonitor 的现有架构，提供了一套具有蚂蚁场景特色的集群化解决方案。\n今年大促，我们成功地将 Sigma 集群监控（蚂蚁原生的集群管理和资源调度平台）完整迁移至 AntMonitor。配合告警和大盘，实现了 Sigma 监控的覆盖。AntMonitor 凭借 Sigma 监控的迁移，成功孵化了完善的的云原生 Prometheus 监控能力。\n本文简要介绍了AntMonitor 对 Prometheus 监控功能的支持，以及 Sigma 监控的落地实践。\nPART. 1 海量数据下的采集架构 以下是一段 Prometheus metrics 数据的样例：\nMetrics（指标）数据和日志数据拥有较大差别，包括但不限于：\n第一、日志数据写在磁盘上，每条日志都有标准时间戳，而 Prometheus metrics 是存在内存里，采集时间以拉取的时间为准，因此数据的准确性对调度的准确性有较高要求。\n第二、日志的每次采集均采集增量即可，每次采集的数据量有限，但是 Metrics 数据每次采集均要采集全量，数据的文本大小动辄上百 MB，因此 Metrics 数据量巨大，很容易超限。\n第三、日志数据均需要按照某些固定 schema（数据表结构）作切分清洗、计算聚合，但是原生 Metrics 通常存储单机原始数据。\nAntMonitor 现有的数据链路大致为由 agent 采集日志数据缓存于内存，由 Spark 计算集群从 agent 内存中拉取数据，进行聚合，存储于 CeresDB。\n然而 Metrics 数据不同于日志数据，单机明细数据通常具备可观测性，具备完整的信息。因此通常 Metrics 数据，可以跳过计算步骤，直接进行存储。因此，Metrics 数据在保留单机明细数据的情况下，由 agent 内存和 Spark 拉取的方式已经不合时宜，不仅浪费了计算资源，agent 内存也无法支撑住庞大的 Metrics 数据量。\n因此，我们根据用户的业务需求，提供了两条数据链路：\n 在需要保留单机明细数据的情况下，走基于网关的明细数据采集链路；\n 在需要数据聚合的情况下，走基于 Spark 的聚合数据采集。\n 1.1 基于网关的明细数据采集 为了使保留明细数据跳过计算集群直接存储，我们研发上线了一套专门服务 Metrics 数据的中心化采集 + push 存储的链路。\n中心化采集相对于传统的 agent 采集，不再需要依赖于部署在每台物理机，而是只通过 HTTP 请求的方式采集 Metrics 数据。中心化采集对 Metrics 的采集配置进行结构化的下发和调度，以此满足了 Metrics 采集对时间戳调度精确性的要求。并且，中心采集对采集到的数据不存内存，而是直接以 push 的方式推送给 PushGateway，由 gateway 直接存储至底层 CeresDB。\n这套采集方案，满足了 Metrics 对时间精度和存储单机数据的要求。并且将 Metrics 数据采集与现有的日志采集接耦，使二者互不干扰，解放了对 agent 内存和计算资源的高消耗。\n该套方案已经成功用于蚂蚁 Sigma 等多个技术栈和基础设施的 Prometheus 采集，目前每分钟处理上亿条指标数据。\n1.2 基于 Spark 的聚合数据采集 以 Sigma 为代表的基础设施监控，对单机明细数据有较大需求。但是保留明细数据也有较大的缺点，例如：数据量庞大，对存储消耗较高；数据查询时，耗时和数据读取量巨大。\n但是对于一些业务应用用户，对单机明细数据并不关注，只关注于一些维度的聚合数据。例如，以机房维度、集群维度等。因此在这种场景下，存储明细数据，会造成较大的存储浪费，并且在数据查询时，会带来很差的用户体验。因此在这种场景下，我们保留了目前 AntMonitor 传统的日志链路，对采集的 Metrics 单机明细数据进行了聚合进行存储。在业务不关注单机明细数据的场景下，这条链路拥有明显的好处，节省了存储空间，提升了用户查询的速度。\n但是不同于日志监控的数据聚合，必须由用户配置聚合规则，由于 Metrics 数据本身就包含 schema 信息，我们通过自动化的配置项，自动对 Gauge、Counter、Histogram 等 metric type 自动为用户生成了聚合配置，免去了用户手动配置聚合的繁琐：\n下图总结对比了数据聚合与不聚合的区别和优劣：\nPART. 2 维表体系下的元数据统一 原生 Prometheus 提供多种服务发现机制，如 K8s 服务发现通过 apiserver 可以自动获取发现采集的 targets。但是，AntMonitor 作为一个蚂蚁统一监控系统，显然是不能通过 apiserver 自动发现监控目标。\nAntMonitor 在日志监控的现有基础上，建设有一套较为完善的元数据维表体系，包含了 SOFA、Spanner、OB 等多个蚂蚁技术栈元数据。元数据告诉我们去哪里采集监控数据，对应原生的服务发现机制。为了拉齐原生功能，我们对部分维表进行了必要改造，此处我们以 Sigma 监控的落地实践为例，简要介绍下我们的元数据同步流程。\n2.1 Sigma 元数据同步 AntMonitor 进行 Sigma 监控的前提是要获取元数据，元数据告诉我们去哪里采集监控数据。\n为此，我们设计了基于 RMC（蚂蚁的统一元数据平台） 的 “全量同步+增量同步” 元数据同步方案。前者保证元数据齐全可靠，后者基于 AntQ 实现，保证了元数据的实时性。\n从图中可以看到，为了对齐原生的 staleness 功能，Sigma pod 元数据统一添加了下线 (offline) 这个中间状态。\n原生 Prometheus 通过 relabeling 功能实现采集目标过滤等，还可以通过 metric relabeling 对拉取到 …","date":1645772400,"description":"2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践","dir":"blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a8d933b0202e682ad456783714a58ed6","permalink":"https://sofastack.github.io/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","publishdate":"2022-02-25T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","summary":"文｜陈岸琦（花名：敖清 ) 蚂蚁集团高级开发工程师 负责蚂蚁 Prometheus 监控原生功能，在蚂蚁集团的落地与产品化建设 本文 6566 字 阅读 15 分钟 前 言 日志和指标是监控不可","tags":["SOFAStack"],"title":"2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践","type":"blog","url":"/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","wordcount":4491},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@徐豪 提问：\n 想了解 Ark 动态模块，如何在 IDEA 里面进行开发调试？\n A：这个和普通工程基于 idea 调试没有什么区别的，你的 issue 里面提到要调试模块，那就在安装模块的时候，将断点打在你关注的代码行。\n 目前我没有看到相关的 guide，然后自行尝试，先启动容器，再手工启动模块，感觉没成功，不清楚问题出在哪？\n A：～/logs/sofa-ark 看看有日志吗？\n@孙英雄 提问：\n 请问伙伴们有在用 SOFA 技术栈在非金融的项目开发吗？\n A：有的哈，可以看下使用者登记 https://github.com/sofastack/sofa-rpc/issues/375https://github.com/sofastack/sofastack.tech/issues/5\n@来永国 提问：\n 升 SpringBoot to 2.4.x 还有计划吗？\n A：GitHub 上有一些 exmaple，你可以先玩玩。这个今年在规划了，下个 SOFABoot 版本 3.11.0 将会升级到 Spring Boot 2.4.13。\nhttps://www.github.com/mosn/mosn/tree/master/examples%2Fcn_readme%2Fdubbo-examples\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 技术人聊开源：这并不只是用爱发电\n应用运行时 Layotto 进入 CNCF 云原生全景图\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\n","date":1645772400,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220228/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a61ff0d87e7608cc95b2de68338812bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220228/","publishdate":"2022-02-25T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220228/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220228/","wordcount":838},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践\n 活动时间：02 月 24 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践 Kubernetes 已经成为行业内，容器编排的标准。越来越多的企业开始在生产中使用 Kubernetes，拥抱云原生。\nKubernetes 为什么要持续迭代升级？大规模集群下升级过程将面临哪些问题？如何在复杂问题中找到一条无损升级路子？本次分享将用40分钟时间带你一起庖丁解牛 Kubernetes 的升级难题。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 王连平（花名：烨川） 蚂蚁集团高级工程师。 负责蚂蚁 Kubernetes 集群容器交付方面工作，专注于集群交付能力、交付性能及交付Trace等相关领域。 议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:50 蚂蚁大规模 Kubernetes 集群无损升级实践 王连平（花名：烨川），蚂蚁集团高级工程师\n你将收获 了解大规模 Kubernetes 集群升级核心问题 了解核心问题背后的 Kubernetes 设计理念 了解蚂蚁在解决这些问题的一些思路 一起探讨 Kubernetes 这个庞然大物的未来升级之道 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1645686000,"description":"02 月 24 日周四晚 19 点，线上直播第 25 期。","dir":"activities/sofa-channel-25/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4e7019a0dffc50381dc10af4c627eaf6","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-25/","publishdate":"2022-02-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-25/","summary":"概要 活动主题：SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践 活动时间：02 月 24 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践","type":"activities","url":"/sofastack.tech/activities/sofa-channel-25/","wordcount":655},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区获奖啦 SOFAStack 团队在 segmentfault 思否颁布的2021 年中国技术先锋年度评选中，荣获“中国技术品牌影响力企业” 。\n SOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@Nothing 提问：\n 请教个问题，一个服务的订阅者实例数很多的情况下，如果所有订阅者都与 provider 建立连接，provider 的连接数压力大，SOFARegistry 是怎么考虑这种情况的?\n A：目前正在做 host subset 的设计，注册中心端会直接进行分片，减少客户端压力。现在开源版本的 SOFARegistry 还不具备这个的能力，我们内部也是采用全链接。可以了解一下 MOSN ，MOSN 有类似分片功能，内部也有大规模落地。\n@老段 提问：\n 如果启动三个节点的话，停掉一个节点，系统就会一直选举，不再提供服务了；如果启动五个节点的话，停掉两个节点，系统就会一直选举，也不再提供服务了。这个正常么？\n A：不正常，我这边 3 个节点，kill 一个 follower 完全没影响，kill leader 也可以很快选举完成。不会一直选举，服务可以提供，只不过日志里会去找那个挂了的节点。\n@张永欣 提问：\n MOSN 怎么配置 dubbo 连接，支持自发现 dubbo 服务吗？\n A：github 上有一些 exmaple，你可以先玩玩：\nhttps://www.github.com/mosn/mosn/tree/master/examples%2Fcn_readme%2Fdubbo-examples\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 技术人聊开源：这并不只是用爱发电\n应用运行时 Layotto 进入 CNCF 云原生全景图\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\n","date":1645167600,"description":"SOFA Weekly |荣获“中国技术品牌影响力企业”、开发者的搬砖日常、QA 整理","dir":"blog/sofa-weekly-20220218/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ba96ccb01c0806da34a4f846db7ccdec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220218/","publishdate":"2022-02-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220218/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |荣获“中国技术品牌影响力企业”、开发者的搬砖日常、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220218/","wordcount":990},{"author":"金融级分布式架构","categories":"SOFAStack","content":" 2022 年 2 月 10 日，CNCF 发布了最新版本的 Landscape。\nLayotto 正式加入 CNCF 云原生全景图!\n分类在 Serverless framework 板块下，详情见 ：https://l.cncf.io/serverless\n意味着 Layotto 正式成为了CNCF 认可的构建云原生最佳实践中的一环。\nCNCF 简介 云原生计算基金会（CNCF, Cloud Native Computing Foundation）致力于云原生技术的普及和可持续发展。\nCNCF Landscape 意图从云原生的层次结构，以及不同的功能组成上，让用户了解云原生体系的全貌。同时，也受到广大开发者和使用者对该项目的关注和重视。\nLayotto 简介 Layotto(/leɪˈɒtəʊ/) 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。\n它为应用提供了各种分布式能力，比如状态管理、配置管理、事件发布订阅等能力，以简化应用的开发。\n更多关于 Layotto 的内容可以查看：\n云原生运行时的下一个五年\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\nLayotto Star 一下✨： https://github.com/mosn/layotto\n新的一年 Layotto 除了继续优化 service mesh 和 multi-runtime 方面的功能外，也会投入精力融入开源 serverless 生态。\n接下来会和大家分享下 2021 年 Layotto 的落地总结，以及新一年的 roadmap，欢迎关注!\n想要初步接触 Layotto 的技术同学，可以从我们的技术任务入手，欢迎大家一起来玩～\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n想要了解更多关于 Layotto 的最新动态\n👐 欢迎添加微信小助手进群，随时提问 👐\n本周推荐\n云原生运行时的下一个五年\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n","date":1644822000,"description":"应用运行时 Layotto 进入 CNCF 云原生全景图","dir":"blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6521f348ceee0dc3067e03c8209f4a01","permalink":"https://sofastack.github.io/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","publishdate":"2022-02-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","summary":"2022 年 2 月 10 日，CNCF 发布了最新版本的 Landscape。 Layotto 正式加入 CNCF 云原生全景图! 分类在 Serverless framework 板块下，详情见 ：https://l.cncf.","tags":["SOFAStack"],"title":"应用运行时 Layotto 进入 CNCF 云原生全景图","type":"blog","url":"/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","wordcount":742},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@小楼 提问：\n 请问 session 是如何支持 Dubbo 的元数据的？\n A：Registery 的元数据现在不是通用的，只针对 SOFARPC。\n session 之间应该是没有数据同步的吧，跨 session 节点怎么办呢？\n A：现在会同步两个信息，一个是元数据，一个是接口级订阅，接口级订阅是用于兼容没升级的应用。同步的路径是通过存储，类似 K8 的 listwatch 机制，内部落地存储的插件实现是 db，这个块数据比较少，就几千行吧，而且变化很小。\n「SOFARegistery」：https://github.com/sofastack/sofa-registry\n@来永国 提问：\n 为什么我起了 RPC 服务端客户端和注册中心，然后连接调用是可以的，然后我把注册中心关了，它还是跑得通？\n A：client 会有缓存的。\n 获取注册中心的服务有 API 接口吗?\n A：有的，有个从单机 session 获取数据的接口 curl localhost:9603/digest/pub/data/query?dataInfoId=com.test.SimpleService#@#DEFAULT_INSTANCE_ID#@#DEFAULT_GROUP dataInfoId 参数需要进行 url encode 应该还没公开的 API 文档，获取数据的 HTTP 接口也不太易用，我最近会补一下文档还有方便使用的接口。\n 那看样子这个相当于是指定搜索了吗？\n A：是的，目前没有模糊查询的接口， curl localhost:9603/digest/getDataInfoIdList 你可以用这个 API grep 一下。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@东仔 提问：\n SOFABolt 的最新分支是哪个？\n A：https://github.com/sofastack/sofa-bolt master 就是最新分支。\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n","date":1644562800,"description":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220211/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b55336c3e1f02336f659e4eedb771ea7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220211/","publishdate":"2022-02-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220211/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220211/","wordcount":1170},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@来永国 提问：\n 想问下，发现在 SOFA 的 spi 加载扩展的时候，是有做到 getExtensionLoader 遍历 META-INF 的，但是没搞懂是怎么做到的。br/ A：在这个方法里: com.alipay.sofa.rpc.ext.ExtensionLoader#loadFromFile，getResource 这边可以获得多个文件。\n@半个馒头 提问：\n 多次提交 raft 日志会自动触发 jraft 的 leader 转移吗？\n A：不会，可能是其他场景触发的。\n steps down when alive nodes don\u0026amp;rsquo;t satisfy quorum.\n A：是 leader 中发现半数节点在心跳周期内没有心跳了。\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 喜迎虎年｜开源正当时！\n2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n","date":1643958000,"description":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20220204/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b8eaeb7040dab97c5de595df79e1bc7c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220204/","publishdate":"2022-02-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220204/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220204/","wordcount":747},{"author":"金融级分布式架构","categories":"SOFAStack","content":" Awesome SOFAer 👋:\n大家好，\n我是 SOFAStack 社区的负责人——齐天\n虎年伊始，我谨代表 SOFAStack 社区\n祝大家新年快乐！\n在新的一年事事如意，虎虎有生气！\nPart 01 开源正当下！ 回想起 6 年前，在 Github 写下第一行 Apollo 的代码时。\n那时国内的开源社区是这样一番景象：\nDubbo 还没被唤醒、很多现在耳熟能详的项目还在襁褓中、开源社区的贡献者寥寥无几、少量的活跃项目凭着核心个人开发者对技术的热爱维持着。虽然使用开源产品的公司很多，但是做开源产品却是一种非常小众的行为。\n然而最近几年开源却一下子火了起来，成为了技术圈的时髦热词，在各种场合被频频提起。\n究其原因，我想一方面是开源商业化的模式诞生了以 Confluent、GitLab、HashiCorp 为代表的百亿美元上市公司群体，证明了开源的商业价值，吸引到了资本的关注；\n另一方面从政策层面，工业和信息化部印发了《“十四五”软件和信息技术服务业发展规划》，其中提到了要提升关键软件供给能力，加快繁荣开源生态，建设 2-3 个有国际影响力的开源社区。\n在这些因素的刺激影响下，国内的开源行业得到了迅猛的发展，诞生了开放原子基金会以及以木兰社区为代表的诸多综合性开源社区，众多基于开源项目的创业公司也纷纷获得融资，不完全统计列表如下：\n● 2021 年 3 月深圳支流科技 API7 完成 Pre-A 轮（基于 Apache APISIX 项目）\n● 2021 年 4 月上海硅智信息技术 Kyligence 完成 D 轮融资（基于 Apache Kylin 项目）\n● 2021 年 5 月北京思斐软件 SphereEx 完成天使轮融资（基于 Apache ShardingSphere 项目）\n● 2021 年 5 月涛思数据 TaosData 完成 B 轮融资（开源物联网大数据平台 TDengine）\n● 2021 年 10 月 StreamNative 获得 A 轮融资（基于 Apache Pulsar 项目）\n● 2021 年 11 月白鲸开源获得数百万美元种子轮融资（基于 Apache DolphinScheduler）\n● 2021 年 11 月开源数据库结构变更和版本管理 ByteBase 获得三百万美元种子轮融资\n● 2022 年 1 月 SphereEx 又完成了 Pre-A 轮融资\n可以说，「开源正当时！」\nPart 02 如何正确对待开源？ 然而，繁华之下也有隐忧。\n很多企业看到了开源的商业价值，所以纷纷投入大量资源，有了投入自然对回报就有着期待。在这种情形下一个不合理的 KPI 很容易就会让开源动作走样，诸如点 star 拿礼物、大量提交修改错别字的 commit 等行为也屡见不鲜。\n而另一方面有些底层开源项目如 Log4j2 虽然很重要，但是由于没有明显的商业价值，企业没有动力投入资源，以至于只有少数开发者无偿、自愿地进行维护，在曝出严重漏洞后大家才意识到原来开源软件供应链的根基竟是如此脆弱。\n那么，回到我们自身\u0026amp;hellip;\n应该如何正确对待开源呢？ 我的思绪再次拉回到 6 年前，当时的我对开源还懵懵懂懂，把代码贡献到 GitHub 的出发点非常纯粹：作为一名软件工程师，写了一份自己认为还过得去的代码，解决了一些通用问题，就希望让这份代码发挥更大的作用，同时也能通过代码会友，大家一起交流技术、分享心得，岂不乐哉？至于能获得多大的影响力、有多大的商业价值，当时是没有任何概念的。\n现在想来，似乎是有一分盲目和冲动在，一种想把好东西分享出去的冲动。\n当然了，要把开源项目做好，光有一时的冲动是不够的。做过开源项目的朋友基本都有一个共识，那就是做开源项目非常枯燥，日复一日地处理 issue、review pr，时不时还会遇到伸手党不合理的需求，稍有怠慢还会招来无端的指责。\n那到底是什么支撑我投入开源这么多年呢？ 想来想去应该还是兴趣吧\u0026amp;hellip;\n对技术的兴趣让这些重复性的事情显得不那么枯燥，而通过开源又结交了很多志趣相投的朋友，大家在一起既可以聊技术，也可以聊生活，虽然身处五湖四海，甚至素未谋面，但相谈甚欢，正是这样开放、有趣的社区让兴趣得以持续保鲜。\n而这也正是 SOFAStack 的开源理念，我们希望在喧嚣中依然保持乐于分享的初心，打造开放、有趣的技术社区。通过开放让更多的人加入进来，通过有趣让大家留下来并持续分享、交流，相互学习、相互成长。\n比如在开放方面，我们通过 Github、Meetup、直播、公众号、视频号等多种渠道和大家进行技术交流。\n 在社区治理上，我们也是完善了社区的晋升机制，鼓励贡献者以不同形式来影响社区走向，不少项目如 MOSN、Layotto 都有较大比例的外部 Committer。\n 在社区合作方面，我们和包括 Envoy、Dapr、Seata 等国内外社区进行了深度的技术共建，在传播方面也是和云原生社区、字节码联盟的 WAMR 社区等一起联合举办了多场 Meetup，为社区带来了精彩的技术分享。\n 而在有趣方面，虽然我们这些工程师平时看上去都挺严谨的，但其实私下里还都有好玩的一面。所以我们的视频号也是不断尝试新的视频形式，就是希望营造一个比较轻松、有趣的环境来和大家进行技术交流，在快乐中学习和成长。\n虎年准备做的几件事 SOFARegistry V6 虽然 SOFARegistry V5 版本早已在 GitHub 上开源，其性能、容量、稳定性上也都达到了比较高的水平，不过在日常运行中还是存在不少痛点。所以我们对 V6 版本做了大幅重构，在性能、稳定性、可运维性等方面都取得了较大的突破并在生产环境完成全量上线（降本提效！注册中心在蚂蚁集团的蜕变之路），相信不管是一家中小规模的公司还是一家大型企业，SOFARegistry 都会是一个比较靠谱的选项。\n而在研发这个版本的过程中我们也沉淀了针对注册中心场景的混沌测试工具，也将于近期和大家见面，希望能帮大家更好地评估各类开源注册中心的能力极限，以便选择最适合自己的产品。\nMOSN 目前 MOSN 作为 Service Mesh 的数据面在蚂蚁生产环境已经覆盖了数十万容器，切实解决了我们在基础设施独立演进上的痛点，在社区也有将近 20 家公司登记使用。不过总体来看，使用门槛还是比较高。\n所以今年我们会开源一个 MOSN 的管控面产品，从而端到端打通 MOSN 的使用场景，降低使用难度，造福更多的用户。\nLayotto Layotto 作为云原生运行时的下一个五年的重要载体，今年我们会继续投入精力和 Dapr 社区一起推动 API 标准化向前演进，重新定义基础设施的边界。同时也会探索 Layotto on Envoy 的运行方式，从而只需运维一个 Sidecar 即可同时具备 Service Mesh 和应用运行时的能力。\n在函数运行时方面，去年我们在 KubeCon 演示了通过 K8s 标准语义把一个 WASM 模块调度到 Layotto 进程中运行，今年在这个方向也会继续向前探索更多可能性。\n去年 4 月，SOFAStack 社区在北京和大家度过了一个愉快的三周岁生日，也标志着社区逐渐走向成 …","date":1643871600,"description":"喜迎虎年｜开源正当时！","dir":"blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d95d0ce2c5f132fcd207d1701c64c415","permalink":"https://sofastack.github.io/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","publishdate":"2022-02-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","summary":"Awesome SOFAer 👋: 大家好， 我是 SOFAStack 社区的负责人——齐天 虎年伊始，我谨代表 SOFAStack 社区 祝大家新年快乐！ 在新的一年事事如意，虎虎有生气！ Part 01 开源正当下！ 回想起 6 年","tags":["SOFAStack"],"title":"喜迎虎年｜开源正当时！","type":"blog","url":"/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","wordcount":2729},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@李雪涛 提问：\n 请问 MOSN 插件的管理接口应该怎么调用，里面的 IP 和 port，IP 应该指的是 Pod 的 IP 吧，那 port 指的是什么呢?br/ A：通过 admin 得配置。 https://www.github.com/mosn/mosn/tree/master/configs%2Fmosn_config.jso\n「MOSN」：https://github.com/mosn/mosn\n@李雪涛 提问：\n 我的插件参考的： https://github.com/mosn/mosn/blob/istio-1.10/examples/codes/plugin/pluginfilter/pluginfilter.go\n 但是我利用 admin 接口 enable 的时候输出的是插件未注册的错误，能帮我看一下我的插件注册部分哪里写的不对吗？\n插件的 client 的注册相关的代码： https://www.codepile.net/pile/EK6Om3A6\nA：镜像的配置有这个 plugin 吗？或者你先别用那个 Istio，现本地打包测试下，直接二进制启动试试： 1. 看配置，有没有 paper 的 filter 配置 2. MOSN 的 main 文件需要 import 你的 paper 文件，因为注册用的 init 3. 看下启动日志： https://github.com/mosn/mosn/blob/master/cmd/mosn/main/mosn.go\n「MOSN」：https://github.com/mosn/mosn\n@来永国 提问：\n 我把透传写在 SOFARPC 拦截器里，服务端接收不到客户端透传的参数。\n A：确实是这样，baggage 处理在 filter 之前。\n 还有什么更优雅的方式吗？那我非要只在 filter 里加透传要怎么做呢？\n A：非要在 filter 里面处理 baggage 的话,可以直接操作 SOFARequest 对象的 RequestProp. RemotingConstants.RPC_REQUEST_BAGGAGE，可以参考 com.alipay.sofa.rpc.context.BaggageResolver#carryWithRequest 类。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n","date":1643439600,"description":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220129/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"930109d877cef64f3e5441f23528dd16","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220129/","publishdate":"2022-01-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220129/","wordcount":1066},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王辉 提问：\n 那 6.x 版本相比 5.x 版本，缺失了哪些功能，有列表么？\n A：providedata 的功能还在，但通过 session 透出的 watcher 还没有支持，其他的功能没有缺失。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@李雪涛 提问：\n 请问自定义一个 streamfilter，可以在这个 filter 中获取当前请求的目的 IP 吗?\n A：可以的哈，通过变量就可以获取 。\n具体内容可以参考下方文档：\nhttps://www.github.com/mosn/mosn/tree/master/pkg%2Fproxy%2Fvar.go\n「MOSN」：https://github.com/mosn/mosn\n@王宇阳 提问：\n 请教一下 MOSN 做网关会对 HTTP 协议中没有带 content-type 的请求头做处理吗，比如加一个默认的这样？\n A：如果响应 header 没有携带 content-type 的话则默认加一个 “text/plain; charset=utf-8” 的 content-type。\n（注：MOSN 中的 HTTP 解析这块使用的 fasthttp 的库，目前这块会有这个默认操作。）\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 叮，你有一份开发者问卷到了\n一图看懂 SOFAStack 社区的 2021 ｜文末有“彩蛋”\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n","date":1642748400,"description":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220121/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e77bc7011b07dcfa07b22d729631a09d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220121/","publishdate":"2022-01-21T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220121/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220121/","wordcount":971},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#24：漫谈 HTTP/3 进化史\n 活动时间：01 月 20 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#24：漫谈 HTTP/3 进化史 HTTP/3 协议栈可以说是当前 4\u0026amp;frasl;7 层协议的集大成者，它浓缩了大量现有协议的最佳实践及优化技巧。\n那么 HTTP/3 是如何一步一步发展成今天这个样子的呢？它解决了什么样的问题？未来又还会走向何方？\n本次分享将用 50 分钟的时间，带你走近 HTTP/3 的世界，一一解读这些问题\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 曾柯（花名：毅丝） 蚂蚁集团高级工程师。 负责蚂蚁集团的接入层建设工作，主要方向为高性能安全网络协议的设计及优化 议程 18:50-19:00 主持人开场 SOFA 社区小助手-泡椒 主持人\n19:00-19:50 漫谈 HTTP/3 进化史 曾柯（花名：毅丝），蚂蚁集团高级工程师\n你将收获 了解4/7层协议的发展历程 了解HTTP/3解决的问题 一起展望HTTP/3的未来 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1642662000,"description":"01 月 20 日周四晚 19 点，线上直播第 24 期。","dir":"activities/sofa-channel-24/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2f719fc9371adf2f0f5a9de7f21c47cd","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-24/","publishdate":"2022-01-20T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-24/","summary":"概要 活动主题：SOFAChannel#24：漫谈 HTTP/3 进化史 活动时间：01 月 20 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播间地址：h","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#24：漫谈 HTTP/3 进化史","type":"activities","url":"/sofastack.tech/activities/sofa-channel-24/","wordcount":584},{"author":"杜克伟","categories":"SOFAStack","content":" 文｜杜克伟（花名：苏麟 )\n蚂蚁集团高级开发工程师\n负责蚂蚁 Kubernetes 集群的稳定性方面的工作，专注于集群组件变更、稳定性风险保障\n本文 15738 字 阅读 20 分钟\n前 言 为了支撑蚂蚁业务的迭代升级，蚂蚁基础设施今年启动了 Gzone 全面云化项目。要求 Gzone 需与已经云化的 Rzone 合并部署在同一个集群，Sigma 单集群实际管理的节点规模将超过万台，单集群承担的业务也将更加复杂。\n因此我们启动了大规模 Sigma 集群的性能优化方案，在请求延迟上期望能够对齐社区标准，不因规模增长的原因下降。\netcd 作为 Sigma 集群的数据存储数据库，是整个集群的基石，能够直接决定性能天花板。社区建议的单 etcd 集群存储限制是 8G, 而蚂蚁 Sigma 集群的单 etcd 集群存储量早已超过了这个限制，Gzone 上云项目势必会加重 etcd 的负担。\n首先，蚂蚁业务混合了流失计算、离线计算和在线业务，混合大量的生命周期在分钟级甚至是秒级的 Pod，单集群每天的 Pod 创建量也提升到了数十万, 都需要 etcd 来支撑；\n其次，复杂的业务需求催生了大量的 List (list all、list by namespace、list by label)、watch、create、update、delete 请求，针对 etcd 的存储特性，这些请求性能均会随着 etcd 存储规模的增大而严重衰减，甚至导致 etcd OOM，请求超时等异常；\n最后，请求量的增长也加剧了 etcd 由于 compact、defrag 操作对请求 RT P99 的暴涨，甚至请求超时，从而导致集群关键组件调度器、CNI 服务等 Operator 类组件间断性丢失，造成集群不可用。\n根据前人的经验，针对 etcd 集群进行数据水平拆分是一个有效的优化手段，典型的拆分是把 Pod 等重要数据单独 etcd 集群来存储，从而降低单 etcd 存储和请求处理的压力，降低请求处理延迟。但是 Pod 资源数据针对 Kubernetes 集群具有特殊性，具有其他资源没有的高要求，尤其是针对已颇具规模正在服务的 K8s 集群进行拆分更是需要万分谨慎小心。\n本文主要记录了蚂蚁集团在进行 Pod 资源数据拆分过程中一些实践经验和心得。\n抛砖引玉，请大家多多指教！\nPART. 1 面临的挑战 从前人的 Pod 数据拆分经验了解到，Pod 数据拆分是一个高危且复杂的流程，原因来自于 Pod 数据自身的特殊性。\nPod 是一组容器的组合，是 Sigma 集群中可调度的最小单位，是业务 workload 的最终承载体。Sigma 集群的最核心最终的交付资源就是 Pod 资源。\nSigma 集群最核心的 SLO 也是 Pod 的创建删除升级等指标。Pod 资源数据可以说是 Sigma 集群最重要的资源数据。同时 Sigma 集群又是由事件驱动的，面向终态体系设计，所以 Pod 资源数据拆分除了考虑基本的前后数据一致性问题外，还要考虑拆分过程中对其他组件的影响。\n前人的拆分经验流程中最核心的操作是数据完整性校验和关键服务组件停机。数据完整性校验顾名思义是为了保证数据前后的一致性，而关键服务组件停机是为了避免拆分过程中如果组件不停机造成的非预期后果，可能会有 Pod 非预期删除，Pod 状态被破坏等。但是如果照搬这套流程到蚂蚁 Sigma 集群，问题就来了。\n蚂蚁 Sigma 作为蚂蚁集团核心的基础设施，经过 2 年多的发展已经成为拥有 80+ 集群、单集群节点数可达到 1.2w+ 规模的云底座。在如此规模的集群上，运行着蚂蚁内部百万级别的 Pod，其中短运行时长 Pod 每天的创建量在 20w+次。为了满足各种业务发展需求，Sigma 团队与蚂蚁存储、网络、PaaS 等多个云原生团队合作，截止目前 Sigma 共建的第三方组件量已经达到上百个。如果 Pod 拆分要重启组件，需要大量的与业务方的沟通工作，需要多人共同操作。如果操作不慎，梳理不完全漏掉几个组件就有可能造成非预期的后果。\n从蚂蚁 Sigma 集群现状总结一下已有的 Pod 数据拆分经验流程的问题：\n1. 人工操作大量组件重启时间长、易出错 潜在需要重启的组件高达数十个，需要与各个组件 owner 进行沟通确认，梳理出需要重启的组件，需要耗费大量的沟通时间。万一遗漏就可能造成非预期的后果，比如资源残留、脏数据等。\n2. 完全停机持续时间长打破 SLO 数据拆分期间组件完全停机，集群功能完全不可用，且拆分操作极为耗时，根据前人经验，持续时间可能长达 1~2 小时，完全打破了 Sigma 集群对外的 SLO 承诺。\n3. 数据完整性校验手段薄弱 拆分过程中使用 etcd 开源工具 make-mirror 工具来迁移数据，该工具实现比较简单，就是读取一个 etcd 的 key 数据然后重新写到另一个 etcd，不支持断点续传，同时因重新写入 etcd 造成原有 key 的重要字段 revision 被破坏，影响 Pod 数据的 resourceVersion, 可能会造成非预期后果。关于 revision 后文会详细说明。最后的校验手段是检验 keys 的数量是否前后一致，如果中间 key 的数据被破坏，也无法发现。\nPART. 2 问题解析 美好的期望 作为一个懒人，不想和那么多的组件 owner 沟通重启问题，大量组件重启也易造成操作遗漏，造成非预期问题。同时是否有更好的数据完整性校验的手段呢？\n如果组件不重启，那么整个过程后演变为下面的流程，预期将简化流程，同时保障安全性。\n为了达成美好的期望，我们来追本溯源重新 review 整个流程。\n数据拆分是在做什么？ 众所周知，etcd 存储了 Kubernetes 集群中的各种资源数据，如 Pod、Services、Configmaps、Deployment 等等。\nKube-apiserver 默认是所有的资源数据都存储在一套 etcd 集群中，随着存储规模的增长，etcd 集群会面临性能瓶颈。以资源维度进行 etcd 的数据拆分来提升 Kube-apiserver 访问 etcd 的性能是业内所共识的经验优化思路，本质是降低单 etcd 集群的数据规模，减少单 etcd 集群的访问 QPS。\n针对蚂蚁 Sigma 集群自身的规模和需求，需拆分为 4 个独立的 etcd 集群，分别存储 Pods、Leases、event 和其他资源数据，下面分别简要说明这前三类(Pods、Lease、event)需要拆分出去的资源数据。\nEvent 资源 K8s event 资源数据并不是 watch 中的 event，一般是表示关联对象发生的事件，比如 Pod 拉取镜像，容器启动等。在业务上一般是 CI/CD 需要流水式展示状态时间轴，需要频繁拉取 event 资源数据。\nevent 资源数据本身就是有效期的（默认是 2 小时），除了通过 event 观测资源对象生命周期变化外，一般没有重要的业务依赖，所以说 event 数据一般认为是可以丢弃，不需要保障数据前后一致性的。\n因为上述的数据特点，event 的拆分是最为简 …","date":1642489200,"description":"蚂蚁大规模 Sigma 集群 Etcd 拆分实践","dir":"blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d2c7a90fb1f46225bb634988b092d058","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","publishdate":"2022-01-18T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","summary":"文｜杜克伟（花名：苏麟 ) 蚂蚁集团高级开发工程师 负责蚂蚁 Kubernetes 集群的稳定性方面的工作，专注于集群组件变更、稳定性风险保障 本文 15738 字 阅读 20 分钟 前 言 为了","tags":["SOFAStack"],"title":"蚂蚁大规模 Sigma 集群 Etcd 拆分实践","type":"blog","url":"/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","wordcount":8750},{"author":"杨洋","categories":"SOFAStack","content":" 文｜杨洋（花名：凯申 )\n蚂蚁集团高级技术专家\n负责密码学工程能力建设、BabaSSL 开源社区建设\n本文 2366 字 阅读 5 分钟\n近日，国内著名 Web 服务器和反向代理开源软件 TengineBabaSSL 完成了对 BabaSSL的适配工作。\nTengine 对 BabaSSL 提供的特殊 API 进行了适配，并增加对 NTLS 相关能力的支持。\n「详细 Pull Request 请见」：https://github.com/alibaba/tengine/pull/1595\n至此，对我国密码行业相关安全通信协议，有使用需求的用户可以直接使用 Tengine + BabaSSL 的组合。而无需额外的 patch 或者代码改动，从用户使用的角度进一步提升了便利性。\nPART. 1 NTLS 目前，我国密码行业中有两个主要的通信协议相关的技术标准。一个是由信安标委于 2020 年发布的 TLCP 协议，即传输层密码协议；另外一个则是由密标委在 2012 年发布的 GM/T 0024《SSL VPN 技术规范》（以下简称 0024）。\nTLCP 和 0024 的具体内容差别不大，均是从 TLS 协议发展而来，他们的主要特点是将商用密码算法 SM2、SM3 和 SM4 应用到了 TLS 协议中，并使用 SM2 密钥交换机制替换掉了 TLS 协议原有的密钥交换流程。\nTLCP 和 0024 另外一个显著的特点将 TLS 协议中使用的数字证书拆分成了加密和签名两种用途的证书，加密证书和签名证书以及对应私钥均需要进行配置使用，所以 TLCP 和 0024 也俗称“国密双证书”协议。\nBabaSSL 对上述国密双证书协议进行了支持，并统称为 NTLS。\nNTLS 的全名为 National TLS，即我国核准的传输层安全协议，所以也可以叫做国密 TLS。\n由此可见，NTLS 并不是指某一种具体的符合商用密码相关技术标准要求的网络协议，而是多个协议的统称。在 BabaSSL 中代指 TLCP 和 0024 国密双证书协议，因为 NTLS 和标准 TLS 协议存在工作方式的不同，因此 BabaSSL 中增加了一些新的 API 来对其进行支持。而应用程序若想使用 NTLS 功能，就需要调用这些新增 API，给现有基于 OpenSSL API 进行适配的应用程序带来了额外的开发工作量。\nPART. 2 Tengine + BabaSSL Tengine 是由淘宝网发起的 Web 服务器项目，它在 Nginx 的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。\nTengine 的性能和稳定性已经在大型的网站(如淘宝网，天猫商城等)得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的 Web 平台。\nTengine 作为国内知名的开源 Web 服务器软件，在各领域均得到了广泛的使用且享有很高的知名度。\nBabaSSL 是一款轻巧、灵活且靠谱的密码学和 TLS 协议工具集。BabaSSL 是蚂蚁集团和阿里集团的各主要业务中所使用的底层密码库，目前开源出来供业界使用。BabaSSL 广泛的应用在包括网络、存储、移动端 App 等场景中。\nTengine 来源于 Nginx，所以默认使用的是 OpenSSL。此次 Tengine 针对 BabaSSL 中的 NTLS 功能进行了适配，用户如果选择使用 BabaSSL 作为 Tengine 的底层密码库来实现通信加密的能力，则可以无需对 Tengine 进行任何代码改动，原生开启 NTLS 能力。\nPART. 3 Tengine 启用 NTLS 具体来说，此次在 Tengine 中增加了几个新的指令，对 NTLS 进行支持。\n1. 下载 BabaSSL 和 Tengine 前往 👇 下载 BabaSSL 的源代码包: https://github.com/BabaSSL/BabaSSL/releases\n 前往 👇 获取 Tengine 的最新代码: 「git clone」\nhttps://github.com/alibaba/tengine.git\n2. 编译 BabaSSL 和 Tengine 使用如下配置：\n./configure --add-module=modules/ngx_openssl_ntls \\ --with-openssl=../path/to/BabaSSL \\ --with-openssl-opt=\u0026amp;quot;--strict-warnings enable-ntls\u0026amp;quot; \\ --with-http_ssl_module --with-stream \\ --with-stream_ssl_module --with-stream_sni 3. 配置 Tengine 开启 NTLS 一个开启了 NTLS 的 Tengine 配置文件的例子：\nworker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; server { listen 443 ssl; server_name localhost; enable_ntls on; ssl_sign_certificate server_sign.crt; ssl_sign_certificate_key server_sign.key; ssl_enc_certificate server_enc.crt; ssl_enc_certificate_key server_enc.key; location / { return 200 \u0026amp;quot;body $ssl_protocol:$ssl_cipher\u0026amp;quot;; } } } stream { server { listen 8443 ssl; enable_ntls on; ssl_sign_certificate server_sign.crt; ssl_sign_certificate_key server_sign.key; ssl_enc_certificate server_enc.crt; ssl_enc_certificate_key server_enc.key; return \u0026amp;quot;body $ssl_protocol:$ssl_cipher\u0026amp;quot;; } } 4. 测试 NTLS 可以使用 BabaSSL 的 s_client 工具对开启了 NTLS 的 Tengine 进行测试。\n「具体可以参考」：\nhttps://babassl.readthedocs.io/zh/latest/Tutorial/SM/ntls/\nPART. 4 总 结 随着互联网业务的发展，在新时期下，数据成为了影响人们正常生活的核心要素。\n因此数据安全和个人信息保护等问题变得更加需要重视，国家近期也针对数据安全领域进行了相关立法。\n密码学技术作为整个信息安全领域的基础技术能力，对数据安全也存在着很大的影响。同时 …","date":1641884400,"description":"Tengine + BabaSSL ，让国密更易用！","dir":"blog/tengine-babassl-making-state-secrets-easier-to-use/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"45a5b2c753bc2a5c371c606d1177571e","permalink":"https://sofastack.github.io/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","publishdate":"2022-01-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","summary":"文｜杨洋（花名：凯申 ) 蚂蚁集团高级技术专家 负责密码学工程能力建设、BabaSSL 开源社区建设 本文 2366 字 阅读 5 分钟 近日，国内著名 Web 服务器和反向代","tags":["SOFAStack"],"title":"Tengine + BabaSSL ，让国密更易用！","type":"blog","url":"/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","wordcount":1930},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王勇旭 提问：\n com.alipay.sofa.rpc.boot.runtime.adapter.processor.ConsumerConfigProcessor 没有提供注解上的支持，自己实现来处理吗？Cluster 指定 failover、failfast 或者自己实现，这种在 SOFA 中是怎么使用的呢？ A：这种的话，单个注解的 API 是不支持的。不过可以通过调整整体的 RPC 的配置，来实现切换到你想使用的 Cluster 上。具体如何配置可以看代码这里，支持自定义的配置文件，也支持 -D 环境变量的方式传入，key 为 consumer.Cluster。\n 为啥不支持单个 API 的配置啊，是出于某种考虑吗?\n A：单个 API 的话，可以单独通过 ConsumerConfig 的 setCluster(String Cluster)去设置。但是不是通用功能，所以没加到 annotation 上。\n 感觉和 loadbalance 是差不多同一级的，注解上 lD 支持，Cluster 不支持\u0026amp;hellip;\n A：这个功能感觉更偏全局一些，当然也是有单个 API 自定义的需求，之前的设计可能也是基于这个考量。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@崔伟协 提问：\n 所有整个流程里的异常返回（那些没转发到 Upstream/或者转发失败的，直接返回给 client)都会经过这里吗？ https://github.com/mosn/mosn/blob/master/pkg/proxy/downstream.go#L1359\n A：也不一定，你的诉求是啥呢？但是所有请求基本都会走 filter，你可以在 append filter 劫持返回的请求。\n 就是捕获一波没转发的或者转发失败的，不包括已经转发的然后返回失败的。\n A：这个可能还不太好区分，超时也算是转发的了，但超时之后也会调用 hijack。返回的包是不是 Upstream 发过来是可以判断的， 你写一个 append filter，然后判断 types.VarProxyIsDirectResponse 这个变量。\n「MOSN」：https://github.com/mosn/mosn\n@我是一个小胖子 提问：\n 这个统一路由框架，已经 ready，还是在计划中？\n A：https://mosn.io/blog/posts/how-use-dynamic-metadata/\n可以参考这篇文章，是更加灵活的方案。还有一部分没在文档里，就是路由的 match 规则也支持变量和 DSL。\n「MOSN」：https://github.com/mosn/mosn\n@Noob Xu 提问：\n 请问一下，MOSN 的国密 TLS 支持，是不是先用 \u0026amp;ndash;prefix=/usr/local/BabaSSL/linux_BabaSSL_lib 构建 BabaSSL，然后用 CGO_ENABLED=1 go build -tags BabaSSL 构建 MOSN，是不是就支持 TLS 1.3 + 国密单证书了 ？\n A：在/usr/local/BabaSSL/linux_BabaSSL_lib 这个路径下放上 BabaSSL 的 lib，比如/usr/local/BabaSSL/linux_BabaSSL_lib，然后 CGO_ENABLED=1 go build -tags=BabaSSL 之后配置里 TLS 的 CipherSuite 按照 MOSN 支持的几种格式配置，比如 ECDHE-RSA-SM4-SM3 就可以了。在 MOSN 和 MOSN 之间的 TLS 通信就可以走 1.3 和国密了。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 叮，你有一份开发者问卷到了\n一图看懂 SOFAStack 社区的 2021 ｜文末有“彩蛋”\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n","date":1641538800,"description":"SOFA Weekly |SOFA 社区插话小剧场、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220107/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e8f7168b6d3204a6c3f130a563ead237","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220107/","publishdate":"2022-01-07T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220107/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |SOFA 社区插话小剧场、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220107/","wordcount":1625},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@东仔 提问：\n SOFARegistry 的 client、meta、data、session 的四个模块间怎么交互的？\n A：client API 参考 :\nhttps://www.sofastack.tech/projects/sofa-registry/java-sdk/\nmeta、data、session 没有提供 API 文档, 相关介绍可以看下:\nhttps://github.com/sofastack/sofa-registry/releases/tag/v6.1.4\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@刚刚 提问：\n 获取有效链接，这个方法不是每次 new 一个 TCP 链接？\n A：会复用的，为 0 的时候才新建，不为 0 的时候我看是去到一个，直接把那个位置重置为 nil 了。\n 复用是体现在？还是我 down 大代码不是最新的。\n A：用完了会放回这个 avliableclients 的数组里，你的代码不是最新，但大致逻辑也就这样。\n「MOSN」：https://github.com/mosn/mosn\n3、之前有同学问到 OpenKruise 怎么热升级 MOSN，欢迎大家阅读这篇文档试用反馈！\nhttps://mosn.io/blog/posts/mosn-sidecarset-hotupgrade/\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nMOSN 本周发布 发布 MOSN V0.26.0 版本，主要变更如下：\n主要更新如下：\n XProtocol 进行了重构，XProtocol 不再是一种协议，而是便于协议扩展实现的框架\n 新增 ip_access filter，基于来源 IP 的 ACL 控制器\n 支持 go plugin 加载协议转化插件，并支持动态选择协议转换插件\n 支持动态设置上游协议，使用 transcoder filter 来替换 Proxy 中的协议转换\n 其他优化与BUG Fix\n 「详细参考」：\nhttps://mosn.io/blog/releases/v0.26.0/\n本周推荐阅读 一行降低 100000kg 碳排放量的代码！\nSOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1640934000,"description":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","dir":"blog/sofa-weekly-20211231/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1e143008505428e2046bc3c99bd99e51","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211231/","publishdate":"2021-12-31T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211231/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211231/","wordcount":1172},{"author":"张稀虹","categories":"SOFAStack","content":" 文｜张稀虹（花名：止语 )\n蚂蚁集团技术专家\n负责蚂蚁集团云原生架构下的高可用能力的建设 主要技术领域包括 ServiceMesh、Serverless 等\n本文 3631 字 阅读 8 分钟\nPART. 1 故事背景 今年双十一大促后，按照惯例我们对大促期间的系统运行数据进行了详细的分析，对比去年同期的性能数据发现，MOSN 的 CPU 使用率有大约 1% 的上涨。\n为什么增加了？\n是合理的吗？\n可以优化吗？\n是不可避免的熵增，还是人为的浪费？\n带着这一些列灵魂拷问我们对系统进行了分析\nPART. 2 问题定位 我们从监控上发现，这部分额外的开销是在系统空闲时已有，并且不会随着压测流量增加而降低，CPU 总消耗增加 1.2%，其中 0.8% 是由 cpu_sys 带来。\n通过 perf 分析发现新版本的 MOSN 相较于老版本， syscall 有明显的增加。\n经过层层分析，发现其中一部分原因是 MOSN 依赖的 sentinel-golang 中的一个StartTimeTicker 的 func 中的 Sleep 产生了大量的系统调用，这是个什么逻辑？\nPART. 3 理论分析 查看源码发现有一个毫秒级别的时间戳缓存逻辑，设计的目的是为了降低高调用频率下的性能开销，但空闲状态下频繁的获取时间戳和 Sleep 会产生大量的系统调用，导致 cpu sys util 上涨。我们先从理论上分析一下为什么这部分优化在工程上通常是无效的，先来看看 Sentinel 的代码：\npackage util import ( \u0026amp;quot;sync/atomic\u0026amp;quot; \u0026amp;quot;time\u0026amp;quot; ) var nowInMs = uint64(0) // StartTimeTicker starts a background task that caches current timestamp per millisecond, // which may provide better performance in high-concurrency scenarios. func StartTimeTicker() { atomic.StoreUint64(\u0026amp;amp;nowInMs, uint64(time.Now().UnixNano())/UnixTimeUnitOffset) go func() { for { now := uint64(time.Now().UnixNano()) / UnixTimeUnitOffset atomic.StoreUint64(\u0026amp;amp;nowInMs, now) time.Sleep(time.Millisecond) } }() } func CurrentTimeMillsWithTicker() uint64 { return atomic.LoadUint64(\u0026amp;amp;nowInMs) } 从上面的代码可以看到，Sentinel 内部用了一个 goroutine 循环的获取时间戳存到 atomic 变量里，然后调用 Sleep 休眠 1ms，通过这种方式缓存了毫秒级别的时间戳。外部有一个开关控制这段逻辑是否要启用，默认情况下是启用的。从这段代码上看，性能开销最大的应该是 Sleep，因为 Sleep 会产生 syscall，众所周知 syscall 的代价是比较高的。\ntime.Sleep 和 time.Now 对比开销到底大多少呢？ 查证资料（1）后我发现一个反直觉的事实，由于 Golang 特殊的调度机制，在 Golang 中一次 time.Sleep 可能会产生 7 次 syscall，而 time.Now 则是 vDSO 实现的，那么问题来了 vDSO 和 7 次系统调用相比提升应该是多少呢？\n我找到了可以佐证的资料，恰好有一个 Golang 的优化（2），其中提到在老版本的 Golang 中（golang 1.9-)，Linux/386 下没有这个 vDSO 的优化，此时会有 2 次 syscall，新版本经过优化后理论性能提高 5～7x+，可以约等于一次 time.Now \u0026amp;lt;= 0.3 次 syscall 的开销。\nCache 设计的目的是为了减少 time.Now 的调用，所以理论上这里调用量足够大的情况下可能会有收益，按照上面的分析，假设 time.Now 和 Sleep 系统调用的开销比是 0.3:7.3（7+0.3），Sleep 每秒会执行 1000 次（不考虑系统精度损失的情况下），这意味着一秒内 CurrentTimeMillsWithTicker 的调用总次数要超过 2.4W 才会有收益。\n所以我们再分析一下 CurrentTimeMillsWithTicker 的调用次数，我在这个地方加了一个 counter 进行验证，然后模拟请求调用 Sentinel 的 Entry，经过测试发现：\n 当首次创建资源点时，Entry 和 CurrentTimeMillsWithTicker 的放大比为 20，这主要是因为创建底层滑动窗口时需要大量的时间戳计算\n 当相同的 resource 调用 Entry 时，调用的放大比⁰为 5:1\n ｜注 0: 内部使用的 MOSN 版本基于原版 Sentinel 做了一些定制化，社区版本放大比理论上低于该比值。\n考虑到创建资源点是低频的，我们可以近似认为此处调用放大比为 5。所以理论上当单机 QPS 至少超过 4800 以上才可能会取得收益\u0026amp;hellip;\u0026amp;hellip;我们动辄听说什么 C10K、C100K、C1000K 问题，这个值看上去似乎并不很高？但在实际业务系统中，这实际上是一个很高的量。\n我随机抽取了多个日常请求量相对大的应用查看 QPS（这里的 QPS 包含所有类型的资源点，入口/出口调用以及子资源点等，总之就是所有会经过 Sentinel Entry 调用的请求量），日常峰值也未超过 4800QPS，可见实际的业务系统中，单机请求量超过这个值的场景是非常罕见的。¹\n｜注 1: 此处监控为分钟级的数据监控，可能与秒级监控存在一定的出入，仅用于指导日常请求量评估。\n考虑到这个优化还有一个好处，是可以降低同步请求时间戳时的耗时，所以我们可以再对比一下直接从 atomic 变量读取缓存值和通过 time.Now() 读取时间戳的速度。\n可以看到单次直接获取时间戳确实比从内存读取开销大很多，但是仍然是 ns 级别的，这种级别的耗时增长对于一笔请求而言是可以忽略不计的。\n大概是 0.06 微秒，即使乘以 5，也就是 0.3 微秒的增加。在 4000QPS 这个流量档位下我们也可以看一下 MOSN 实际 RT。\n两台机器的 MOSN RT 也没有明显的差异，毕竟只有 0.3 微秒\u0026amp;hellip;\nPART. 4 测试结论 同时我们也找了两台机器，分别禁用/启用这个 Cache 进行测试，测试结果佐证了上述分析的结论。\n从上图的数据可以看出来，启用 Cache 的情况下 cpu sys util 始终比不启用 Cache 的版本要大，随着请求量增加，性能差距在逐步缩小， …","date":1640674800,"description":"一行降低 100000kg 碳排放量的代码！","dir":"blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"93ce5b0bb923a249ebd161465f032ce8","permalink":"https://sofastack.github.io/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","publishdate":"2021-12-28T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","summary":"文｜张稀虹（花名：止语 ) 蚂蚁集团技术专家 负责蚂蚁集团云原生架构下的高可用能力的建设 主要技术领域包括 ServiceMesh、Serverles","tags":["SOFAStack"],"title":"一行降低 100000kg 碳排放量的代码！","type":"blog","url":"/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","wordcount":3103},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@微光 提问：\n 有一个嵌入式分布式 KV 存储需求，JRaft RheaKV 能用在生产吗？\n A：我们的时序数据库集群基于 RheaKV 做元数据存储和集群调度。\n有关内容可以参考这个文件：《\u0026amp;rdquo;使用组件及场景：时序数据库集群基于 RheaKV 做元数据存储和集群调度\u0026amp;rdquo;》\nhttps://github.com/sofastack/sofa-jraft/issues/524\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@微光 提问：\n RheaKV 中这样移除一个节点 Node，好像不行。在 DefaultRheaKVCliService 中是否可以提供动态上线 Node 和下线 Node 的 API？\n A：你提的都支持。所谓动态，不是说 JRaft 决定的，是你的运维系统可以使用 JRaft API 动态执行。\nissue 详细回复：https://github.com/sofastack/sofa-jraft/issues/747\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@苏泽东 提问：\n 哪位老师帮我解答下这个 Endstream 方法?\n A：这个主要是请求发出去后，一直等到收到响应后，记录下 RT 时间等监控数据。\n「MOSN」：https://github.com/mosn/mosn\n@火种 提问：\n 咨询一个问题：看 MOSN 的源码，如果非 netpoll，是通过在 startRWLoop 来实现的，如果是使用 netpoll 的情况下，长链接是怎么迁移的？\n A：https://mp.weixin.qq.com/s/ts_qsUee6mUFv0FpykaOXQ 推荐你看下这个文件。\n startRWloop 会调用 startreadloop 和 startwriteloop，在这两个函数中进行了长链接的数据的交换，但是使用 netpoll 后，代码分支就变成 netpoll 相应的分支了，不会进入上述两个函数了。\n A：没有支持 netpoll 模式的迁移。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n网商双十一基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\n","date":1640329200,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211224/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9977b0cb01909a1c2ef21e4a2026b36b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211224/","publishdate":"2021-12-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211224/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211224/","wordcount":1292},{"author":"马振雄","categories":"SOFAStack","content":" 近几年云计算的发展如火箭般迅猛，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施的统一资源调度带来了极大挑战。\n在越来越复杂的异构基础设施上，存量应用和增量应用应该如何上云？面对大量异构基础设施带来的挑战，企业如何最大化上云价值？\n12 月 15 日，在以“引领分布式云变革，助力湾区数字经济”为主题的全球分布式云大会上，蚂蚁集团数字科技事业部产品总监马振雄分享了分布式云异构基础设施之上，蚂蚁集团在构建分布式云 PaaS 平台 SOFAStack 背后的实践和思考。\nPART. 1 服务网格定义新的应用上云路径 随着云原生的发展，企业在技术升级的过程中伴随着大量的历史包袱，这些历史包袱是所有存量的异构功能，这些异构功能有以下几个特征：技术架构异构、通信协议异构、开发框架异构。\n这些存量的应用如何在异构的基础设施上统一纳管，背后就涉及到了应用的全生命周期，从研发时的应用改造成本，到运行时如何对异构应用做统一服务治理，再到运维时如何对基础设施进行统一元数据管理、统一变更、统一容灾、统一应急以及资金安全，这些都是存在于 PaaS 层的挑战。\n如果说 IaaS 层的统一资源调度以资源为视角和出发点，那么在上层 PaaS 则需要以应用为视角思考整个分布式基础设施的复杂度到底会带来哪些挑战，以及企业应该如何应对。\n企业存在大量的历史包袱，历史包袱五花八门，如果要把这些历史包袱全部改造成分布式应用或者云原生应用，背后需要的代价非常昂贵，很难有一家企业在短时间内愿意负担起这样的时间和成本，彻底将所有的历史包袱云原生化。\n相比于其他上云方式，Service Mesh 能够实现跨平台、跨协议，并且业务代码无侵入改造，从而快速地将应用植入 Sidecar 完成 Mesh 化，获得分布式红利、安全可观测，并且整个架构平滑演进。企业在架构升级过程中可以按部就班、循序渐进，并且实现端到端的安全可信以及全链路可观测能力。\n总体来说网格服务首先降低了传统应用改造成分布式、云原生应用的成本问题；其次是解决了所有企业新老系统的互联互通和统一纳管的问题；第三是让企业应用架构在升级过程变得更平滑；第四是让所有企业保留自己存量系统的技术栈，且保留了企业自身自主可控性要求。\nForrester 长期以来对蚂蚁集团的创新技术保持关注，Forrester 首席分析师、Serving Technology Executives 服务技术决策者戴鲲发布《蚂蚁集团服务网格总体经济影响》，并分享了他对于 Mesh 的研究，\n未来要实现开发的智能化，需要通过微服务来进行智能化进程，不再像以前一样零敲碎打。对传统应用进行定制化，要通过网格服务动态地组装，实现云上开发。\n通过对蚂蚁集团客户的访谈，Forrester 发现无论是传统金融机构还是互联网金融机构，都面临在混合架构下存在的共性挑战，包括基础设施升级换代、应用开发升级、云上云下交互等方方面面。Forrester 发现网格服务从单体应用改造成本节省到运维安全管理效率提升等方面都有明显的收益，通过研究三年数据测算，使用蚂蚁服务网格产品后，客户的投资回报率达到 99%。\nPART. 2 SOFAStack 实现异构统一运维与弹性容灾 基于自身的技术积累和场景打磨，蚂蚁数字科技定义了分布式云 PaaS 平台在运维态的六大能力，包括统一元数据管理、统一集群资源管理、统一变更能力、统一应急能力、统一容灾能力，和统一端到端从业务、应用到基础设施的可观测能力。在此基础上，蚂蚁数字科技重新定义 SRE，实现统一应用运维能力。\n行业一般认为 SRE 中的“R”（Reliability）是可靠性，蚂蚁数字科技结合自身十几年来对业务可用性和连续性的极致追求，经历了十多次双十一大规模验证，对 SRE 进行重新定义，将 SRE 里的 R 从 Reliability 转变为 Risk，意味着蚂蚁自身的保障体系是以风险为核心。最终通过十几年来的技术沉淀，打造了自己的技术风险保障平台 TRaaS。也正是因为这十几年沉淀的精华，才能让蚂蚁做到业务、应用、基础设施的运维无人值守，运维“自动驾驶”。\n蚂蚁的技术风险防控体系从上到下分别代表了三个目标：高可用、资金安全、低成本。三个组织保障：团队、文化、制度。再到需求、研发、发布以及监控的四条防线，最终沉淀出一套完整的技术风险保障体系的平台能力，整个平台由四个能力板块组成，包括了从应急、变更到容量、资金安全。\n应急平台建立起了以风险为核心的事前、事中、事后的故障风险保障体系，分别对应故障风险检测能力、故障定位能力、故障应急和自愈能力，以及故障的回溯能力。变更平台建立起了以变更为核心的事前、事中、事后的变更风险自动分析、防御、阻断能力。容量平台建立起了对于全局数据中心和系统整体瓶颈的自动探测、容量规划和容量保鲜能力。最后的资金平台，通过对业务应用无侵入地建立起了资金核对第二道防线，帮助企业彻底规避资金安全风险，减少资损。\n如果说第一个核心的挑战解决的是研发态和运行态的问题，第二个核心挑战解决运维态问题，第三个核心挑战，要解决的是从整体架构上解决容灾态的问题。\n随着分布式云基础设施的蓬勃发展，企业数据中心从集中化走向离散化，这意味着企业任何一个应用随时随地可以跑在全国的任何一家数据中心机房的任何一个节点。这种变化背后，从应用视角来看，迫切需要整体的系统应用架构，支撑业务突破地域和城市级别的无限可扩展能力。基于蚂蚁对于业务连续性的极致追求，蚂蚁在支撑业务发展过程中，建立起了金融行业超大规模的三地五中心，并沉淀了一套异地多活单元化架构，解决企业在容灾、弹性、灰度方面的三大痛点。\n容灾方面，可以支撑企业的数据中心架构彻底从单活走向同城双活、两地三中心、再走向多地多活。一个业务单元发生故障不会影响到另外一个业务单元，从架构本身原生保障了业务的可靠性和连续性。\n弹性方面，由于灵活部署和快速扩容机制，能够结合灵活的流量调拨机制，支撑企业的数据中心突破城市和地域级别的扩展，做到真正意义上的无限可扩展。\n灰度，结合跨单元的路由分发，可以轻易地做到蓝绿单元这样具有创新的业务灰度方式。\n多地多活的架构非常复杂，从上至下包含了四层，从接入层做路由规则和路由分发，到应用层的中间件路由，再到数据层的数据分片和数据路由，最后到运维层的统一容灾、统一监控、单元拓扑。\n以金融行业为例，大型银行在主机下移过程中，需要面临的重要课题就是如何将核心系统下沉到分布式集群，在分布式集群下移过程中如何匹配主机系统性能和稳定性，背后很重要的能力就是多地多活架构。\n最终，蚂蚁在以上三个核心挑战的实践过程中，沉淀出新一代分布式云 PaaS 平台 SOFAStack。平台在金融行业有非常多的头部客户案例，从原生能力就满足了金融行业远高于其他行业在容量、性能、规模、高可用、合规、降本提效等方面的高标准要求。更重要的是 SOFAStack 来源于金融行业，但不止于金融行业，蚂蚁希望通过 SOFAStack 赋能到更多的行业，完成更多企业的数字化转型。\nPART. 3 SOFAStack 未来演进方向 Mesh 的未来会经历三个重要的发展阶段：\n第一个阶段，不止是 Service …","date":1640242800,"description":"SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验","dir":"blog/the-practice-and-thinking-behind-sofastack/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cb8e3ab2323cb918eeb7a4cb68408c61","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","publishdate":"2021-12-23T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","summary":"近几年云计算的发展如火箭般迅猛，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施","tags":["SOFAStack"],"title":"SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验","type":"blog","url":"/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","wordcount":3335},{"author":"吕冰洁","categories":"SOFAStack","content":" 吕冰洁（花名：尚之）蚂蚁集团技术专家\n我们团队是在做蚂蚁集团内部 Serverless 项目，深度依赖 SOFAArk。SOFAArk 作为 Serverless 项目的核心热部署组件，在无感接入、快速启动方面有很大的诉求。\n因此为 SOFAArk 2.0 提供了最核心的内嵌式运行模式，同时对 1.0 版本存在的一些问题做了较多的性能优化。\n2022 年 03 月 07 日，吕冰洁@zjulbj 被投票选为，SOFAArk Committer。\nBefore 我主要是负责让传统的 SOFABoot 的应用平滑迁移到 SOFAArk 上。\n开始走了很多弯路，接入成本上可能需要半个月到一个月。最初选择了新建应用切流这种比较间接的方案，基于这个方案做迁移过程中的平滑迁移、切流工具。\n但是没解决根本问题，只是通过工具减少了部分工作量。\n过程 我们就尝试通过修改架构把这些问题解掉，推动自己深入了解底层，思考它为什么是这么设计的，为什么导致现在的问题？\n通过研究之后，发现最开始 SOFAArk 是面向终态去设计的，是比较理想化的容器。但实际落地过程中，业务是逐步演进而来的。刚接入就要感知特别大的变化，涉及部署脚本、镜像、测试脚本等一系列的改造，导致业务无法快速享受 SOFAArk 带来的红利。\n我们就借鉴之前的经验，比如 Tomcat 最开始是一个容器，后面往内嵌化发展。我们内部的 CloudEngine 最开始也是一个容器，后面往 SOFABoot 演进也是一个往内嵌化的发展。\nAfter 所以从我们整个迁移和落地的角度，设计了这套方案，修改其中的相关代码。\n从原来需要 2~3 周到现在的一天，降低迁移的成本，省去了大量迁移工作。也为我们后面全站规模化、商业化的一键开启 ark 奠定了基础。\n作为业务研发深入中间件开发底层 Q:如何看待自己作为业务研发的身份接触到开源？\nA:作为业务研发，深入到开源组件的底层设计，不仅对我们自己使用组件有很大的帮助，也能让我们和开源社区的组件同步节奏，不至于脱节。\n另外我们解决了实际问题，其他的使用方肯定也会遇到同样的问题。那我们是不是可以把已有的经验，回馈到开源社区帮助到更多的人。我觉得这是一个良性循环的开源环境，而不是向开发者提一些需求 pr 就结束了。\nQ:你觉得解决这个问题的难点在哪里？\nA:主要的难点还是我以业务研发的身份，参与到整个 SOFAArk 中间件的开发中。\n首先我需要对它的整个设计有清晰的把握，尽管之前有半年的使用经验，也依然花费了一周的时间才搞懂了核心架构。还好 ark 的文档写得很详细，大大降低了我的理解成本。\nQ:在沟通的过程中有没有什么困难的？\nA:沟通没有困难，毕竟大家都是技术，其实都是相通的。只要把自己的使用场景说清楚，中间过程遇到的一些具体问题说清楚。然后结合整个社区的生态，思考一下自己的需求处于什么样的定位，毕竟大家都是基于问题出发。\n也是通过这次深入开发底层，让我们更清晰的认识到大家都是绑在一条船上的，也更理解开发者，毕竟大家初心都是为了共同的目标去努力。\n业务研发和开发者的双重身份是否有可持续性？ Q:这个状态还会一直持续下去吗？\nA:目前我已经成为了 SOFAArk 2.0 的核心开发人员，还会推进 SOFAArk 在蚂蚁主站大规模落地，作为开发的角色维护下去的。本身我们的 Serverless 产品它下面依赖的部署组建就是 SOFAArk，我们要去大规模落地的过程中，涉及到对 ark 的一些支持问题，所以我们可能需要深入到底层去剖析，让组件真正的更易用。\nQ:业务研发深入到中间件底层设计，在开源社区是一个普遍的现象吗？\nA:我理解应该是都有这样的现象，比如说我们用到动态热部署的能力，那我们对启动优化的东西，后面也会把它那个反馈到 SOFABoot、 Spring Boot 社区。\n在我们自己落地过程中遇到的问题，想到的创新解决方案，如果是通用的话，会往各个社区去提 pr、做一些反馈的进行同步。\n比如，我们在 SOFAArk 启动加速这一块，针对 Classloader 做了启动类加载的优化，启动速度平均提升了 50% 左右。\n目前这个已经在 Spring Boot 提了 pr，他们那边正在跟进；\nSOFABoot 这边也有相关的同学在保持跟进，之后我们会在我们主站率先去做一个 backport 的支持。\n业务研发专属经验分享 A:SOFAArk 负责人说你是一个追求细节、追求极致的同学。\nQ:我们团队是做 Serverless 产品的，产品的要求是“更快、更高效、性能更好、体验更好”。\n这就要求了我们在做代码优化的过程中去追求细节、追求极致，也是我们整个团队的风格。\nA:有了这种特殊经历后，有哪些经验可以分享给其他业务研发的吗？\nQ:作为业务研发，最开始我对 ark 也不是很了解的，刚接手 ark 的迁移的东西，也没敢想说去对 ark 做这么大的改造。\n一切基于我们团队的问题出发，一步步深入了解它的原理，去尝试实践自己想法，最终做出了开源的贡献，回过头来看才发现自己做了这么多。\n大部分业务研发不太愿意去参与这种开源贡献，可能就是把它想得比较难了。\n大家不用担心深入底层开发是很有门槛的事情，只要你带着问题出发，其他的都不是问题！\n看他不爽，就直接动手改吧！\n本周推荐阅读 社区文章｜MOSN 路由框架详解\nHAVE FUN | SOFARegistry 源码解析\nBabaSSL：支持半同态加密算法 EC-ElGamal\n恭喜 吕冰洁 成为 SOFAStack committer！\n","date":1640070000,"description":"SOFAArk Committer 专访｜看它不爽，就直接动手改！","dir":"blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"af2c0c99370a29c6e191e9a912277670","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","publishdate":"2021-12-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","summary":"吕冰洁（花名：尚之）蚂蚁集团技术专家 我们团队是在做蚂蚁集团内部 Serverless 项目，深度依赖 SOFAArk。SOFAArk 作为 Serverless 项目的核心热部署组件，在无","tags":["SOFAStack"],"title":"SOFAArk Committer 专访｜看它不爽，就直接动手改！","type":"blog","url":"/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","wordcount":1947},{"author":"曾柯","categories":"SOFAStack","content":" 文｜曾柯（花名：毅丝 )\n蚂蚁集团高级工程师\n负责蚂蚁集团的接入层建设工作,主要方向为高性能安全网络协议的设计及优化\n本文 10279 字 阅读 18 分钟\nPART. 1 引言 作为系列文章的第一篇，引言部分就先稍微繁琐一点，让大家对这个系列文章有一些简单的认知。\n先介绍下这个系列文章的诞生背景。QUIC、HTTP/3 等字眼想来对大家而言并不陌生。从个人的视角来看，大部分开发者其实都已经有了一些背景知识，比如 HTTP/3 的核心是依赖 QUIC 来实现传输层及 TLS 层的能力。而谈及其中细节之时，大家却又知之甚少，相关的文章大多只是浅尝辄止的对一些 HTTP/3 中的机制和特性做了介绍，少有深入的分析，而对于这些机制背后诞生原因，设计思路的分析，就更难得一见了。\n从个人并不大量的 RFC 阅读及 draft 写作经历来看，和撰写论文文献一样，为了保证一份 RFC 的精简以及表述准确，当然也是为了编写过程的简单。在涉及到其他相关协议时，作者往往是通过直接引用的方式来进行表述。这也就意味着直接通过阅读 RFC 来学习和了解网络协议是一个曲线相对比较陡峭的过程，往往读者在阅读到一个关键部分的时候，就不得不跳转到其他文档，然后重复这个令人头痛的过程，而当读者再次回到原始文档时，可能都已经忘了之前的上下文是什么。\n而 HTTP/3，涉及到 QUIC、TLS、HTTP/2、QPACK 等标准文档，而这些标准文档各自又有大量的关联文档，所以学习起来并不是一个容易的事。\n当然，系列文章的立题为“深入 HTTP/3”，而不是“深入 QUIC”，其背后的原因就是 HTTP/3 并不仅仅只是 QUIC 这么一个点，其中还包含有大量现有 HTTP 协议和 QUIC 的有机结合。在系列文章的后续，也会对这一部分做大篇幅的深入分析。\n一个协议的性能优秀与否，除了本身的设计之外，也离不开大量的软硬件优化，架构落地，专项设计等工程实践经验，所以本系列除了会针对 HTTP/3 本身特性进行分享之外，也会针对 HTTP/3 在蚂蚁落地的方案进行分享。\n引言的最后，也是本文的正式开始。\n据统计，人类在学习新的知识时，比较习惯从已有的知识去类比和推断，以产生更深刻的感性和理性认识。我想对大部分同学而言，“TCP 为什么要三次握手以及四次挥手？”这个问题，颇有点经典的不能再经典的味道，所以今天这篇文章也将从 QUIC 链接的建立流程及关闭流程入手，开始我们系列的第一篇文章。\nPART. 2 链接建立 2.1 重温 TCP “TCP 为什么要三次握手？”\n在回答问题之前我们需要了解 TCP 的本质，TCP 协议被设计为一种面向连接的、可靠的、基于字节流的全双工传输层通信协议。\n“可靠”意味着使用 TCP 协议传输数据时，如果 TCP 协议返回发送成功，那么数据一定已经成功的传输到了对端，为了保证数据的“可靠”传输，我们首先需要一个应答机制来确认对端已经收到了数据，而这就是我们熟悉的 ACK 机制。\n“流式”则是一种使用上的抽象(即收发端不用关注底层的传输，只需将数据当作持续不断的字节流去发送和读取就好了)。“流式”的使用方式强依赖于数据的有序传输，为了这种使用上的抽象，我们需要一个机制来保证数据的有序，TCP 协议栈的设计则是给每个发送的字节标示其对应的 seq(实际应用中 seq 是一个范围，但其真实效果就是做到了每个字节都被有序标示)，接收端通过检视当前收到数据的 seq，并与自身记录的对端当前 seq 进行比对，以此确认数据的顺序。\n“全双工”则意味着通信的一端的收发过程都是可靠且流式的，并且收和发是两个完全独立，互不干扰的两个行为。\n可以看到，TCP 的这些特性，都是以 seq 和 ACK 字段作为载体来实现的，而所有 TCP 的交互流程，都是在为了上述特性服务，当然三次握手也不例外，我们再来看 TCP 的三次握手的示意图：\n为了保证通信双方都能确认对端数据的发送顺序，收发端都需要各自记录对端的当前 seq，并确认对端已经同步了自己的 seq 才可以实现，为了保证这个过程，起码需要 3 个 RTT。而实际的实现为了效率考虑，将 seq 和 ACK 放在了一个报文里，这也就形成了我们熟知的三次握手。\n当然，三次握手不仅仅是同步了 seq，还可以用来验证客户端是一个正常的客户端，比如 TCP 可能会面临这些问题：\n(1)有一些 TCP 的攻击请求，只发 syn 请求，但不回数据，浪费 socket 资源；\n(2)已失效的连接请求报文段突然又传送到了服务端，这些数据不再会有后续的响应，如何防止这样的请求浪费资源？\n而这些问题只是三次握手顺手解决的问题，不是专门为了它们设计的三次握手。\n细心的你，可能已经发现了一个问题，如果我们约定好 client 和 server 的 seq 都是从 0(或者某个大家都知道的固定值)开始，是不是就可以不用同步 seq 了呢？这样似乎也就不需要三次握手那么麻烦了？可以直接开始发送数据？\n当然，协议的设计者肯定也想过这个方案，至于为什么没这么实现，我们在下一章来看看 TCP 面临什么样的问题。\n2.2 TCP 面临的问题 2.2.1 seq 攻击 在上一节我们提到，TCP 依赖 seq 和 ACK 来实现可靠，流式以及全双工的传输模式，而实际过程中却需要通过三次握手来同步双端的 seq，如果我们提前约定好通信双方初始 seq，其实是可以避免三次握手的，那么为什么没有这么做呢？答案是安全问题。\n我们知道，TCP 的数据是没有经过任何安全保护的，无论是其 header 还是 payload，对于一个攻击者而言，他可以在世界的任何角落，伪造一个合法 TCP 报文。\n一个典型的例子就是攻击者可以伪造一个 reset 报文强制关闭一条 TCP 链接，而攻击成功的关键则是 TCP 字段里的 seq 及 ACK 字段，只要报文中这两项位于接收者的滑动窗口内，该报文就是合法的，而 TCP 握手采用随机 seq 的方式（不完全随机，而是随着时间流逝而线性增长，到了 2^32 尽头再回滚）来提升攻击者猜测 seq 的难度，以增加安全性。\n为此，TCP 也不得不进行三次握手来同步各自的 seq。当然，这样的方式对于 off-path 的攻击者有一定效果，对于 on-path 的攻击者是完全无效的，一个 on-path 的攻击者仍然可以随意 reset 链接，甚至伪造报文，篡改用户的数据。\n所以，虽然 TCP 为了安全做出过一些努力，但由于其本质上只是一个传输协议，安全并不是其原生的考量，在当前的网络环境中，TCP 会遇到大量的安全问题。\n2.2.2 不可避免的数据安全问题 相信 SSL/TLS/HTTPS 这一类的字眼大家都不陌生，整个 TLS(传输安全层)实际上解决的是 TCP 的 payload 安全问题，当然这也是最紧要的问题。\n比如对一个用户而言，他可能能容忍一次转账失败，但他肯定无法容忍钱被转到攻击者手上去了。TLS 的出现，为用户提供了一种机制来保证中间人无法读取，篡改的 TCP 的 payload 数据，TLS 同时还提供了一套安全的身份认证体系，来防止攻击者冒充 Web 服务提供者。然而 TCP …","date":1640070000,"description":"深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进","dir":"blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","fuzzywordcount":9100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"399aa26268182488b3d65e0618367a35","permalink":"https://sofastack.github.io/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","publishdate":"2021-12-21T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","summary":"文｜曾柯（花名：毅丝 ) 蚂蚁集团高级工程师 负责蚂蚁集团的接入层建设工作,主要方向为高性能安全网络协议的设计及优化 本文 10279 字 阅读 18 分钟 PART. 1 引言 作为","tags":["SOFAStack"],"title":"深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进","type":"blog","url":"/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","wordcount":9072},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFA x 字节码联盟 WAMR 社区「WebAssembly Open Day」\n 活动时间：2021 年 12 月 18 日（周六）13:00-17:00\n 活动形式：线上直播\n 资料下载：\n 《蚂蚁集团 WASM 编译器虚拟机基础能力建设》 \n《WebAssembly Micro Runtime 开源技术解析与展望》\n《Waft: 基于 WebAssembly 的 AIoT 应用框架实践》\n《WASM 中的 GC 遐想》\n《WebAssembly 在区块链中的实践》\n《Wasm \u0026amp;amp; WAMR 在 AIOT 领域的应用》\n活动议程 活动回顾 嘉宾简介：\n《字节码联盟与 WAMR 开源社区进展介绍》\n王鑫 intel 技术经理 任职英特尔公司，关注计算机语言与运行引擎，可信计算和物联网等技术领域。开发与创建开源项目 WebAssembly Micro Runtime，参与推动英特尔、微软、Mozilla 等公司成立字节码联盟（Bytecode-Alliance），任字节码联盟技术管理委员会（TSC）成员。\n杨斌（花名：凯撒） 蚂蚁集团技术总监 任职蚂蚁集团技术总监，关注操作系统，计算机语言与运行引擎等技术领域。\nTill Schneidereit 字节码联盟董事会主席\nRalph Squillace 微软高级总监 字节码联盟董事会成员\n汤伟\n蚂蚁集团资深技术专家\n《蚂蚁集团 WASM 编译器虚拟机基础能力建设》\n嘉宾简介：\n汤伟，一直从事编译器和虚拟机相关工作，2020年11月加入蚂蚁金服，主导webassembly相关工具链的设计与开发。\n议题简介： 作为面向蚂蚁的 wasm 编译器、虚拟机基础平台团队，面向蚂蚁 wasm 用户核心诉求，针对开发效率、性能提升以及生态拓展，确定 wasm 编译器、虚拟机上的技术选型，探索未来编译器、虚拟机协同设计空间。\n听众收益： 了解wasm在蚂蚁的业务场景中的需求和我们的编译器、虚拟机技术能力建设上的一些探索。\n何良\nintel 资深软件工程师\n《WebAssembly Micro Runtime 开源技术解析与展望》\n嘉宾简介：何良，INTEL 资深软件工程师， WAMR开源项目核心开发者\n议题简介：主要介绍 WebAssembly Micro Runtime(WAMR) 的技术特性，发展历程以及路线图。面对嵌入式设备独特的资源条件和使用场景，WAMR进行了有针对性的特性开发，比如选用不同的运行模式适应不同的资源水平，利用XIP在文件系统中直接执行，在RUNTIME中支持 Sensor API 等。此外，WAMR努力打造高效的开发环境，提供源码级调试的功能框架和VSCODE插件。目前，支持高级语言（比如JAVA,KOTLIN等）和SOCKET APIs的功能开发正在有序展开。\n唐兹源\n阿里巴巴前端技术专家\n《Waft: 基于 WebAssembly 的 AIoT 应用框架实践》\n嘉宾简介：\n唐兹源，天猫精灵工程技术前端团队负责人，在智能硬件应用研发领域拥有超过 4 年的经验，专注于 AIoT 体验技术创新\n议题简介：\n本次分享将为大家带来天猫精灵技术团队基于 WAMR 和自研渲染引擎打造的应用框架实践经验，介绍 WebAssembly 在天猫精灵智能音箱以及生态硬件（如电视大屏、投影仪等）的应用场景，以及 Waft 应用框架体系的设计和思考\n听众收益：\n了解 WebAssembly 在智能音箱及电视大屏中的应用场景 了解天猫精灵技术团队如何结合 WAMR 和自研渲染引擎设计动态化容器 了解如何运用 AssemblyScript 设计适合 Web 开发者的应用框架及工具链建设\n臧琳\n腾讯云高级工程师\n《WASM中的GC遐想》\n嘉宾简介：腾讯云编程语言团队高级工程师，OpenJDK committer，专注于编程语言 Runtime 技术在云计算领域的优化与应用。\n议题简介：内存管理及垃圾回收技术是现代高级语言的核心技术之一，也是webassembly承载多语言支持的必经之路， wasm社区已经将GC proposal提上日程，本话题和大家一起进行一次头脑风暴，探讨未来wasm的内存管理及垃圾收集技术可能的发展方向。\n张磊\n蚂蚁集团技术专家\n《WebAssembly在区块链中的实践》\n嘉宾简介：毕业于北京大学，曾就职于华为编译器实验室。目前在蚂蚁链智能合约团队，从事编译器和虚拟机相关研发工作。\n议题简介：Wasm 的安全性、高性能和跨平台等优点，使其天然适合用作区块链智能合约的执行环境。另一方面，区块链对于安全性和确定性的极致要求，也对 Wasm 本身提出了一些技术挑战。本次分享将会结合蚂蚁链的实践经验，介绍 Wasm与区块链之间的各种奇妙“化学反应”。\n听众收益：将会了解到wasm在区块链领域的应用现状和面临的技术挑战。\n黄齐\n小米软件工程师/Vela OS 框架业务技术负责人\n《Wasm \u0026amp;amp; WAMR在AIOT领域的应用》\n嘉宾简介：负责小米Vela OS内核、中间件的研发和在不同架构上的落地，带领团队完成了基于Wasm的应用开发框架的开发和落地，支撑了小米内部多项业务发展\n议题简介：Wasm 作为诞生于浏览器的技术，为何能在 IoT 领域大放异彩？在内存只有数十 KB 级别的运行环境里使用 Wasm，我们将面临怎样的挑战和困难？本次向大家分享小米对 Wasm 技术在 IoT 应用中的实践与思考\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1639810800,"description":"【活动回顾】《WebAssembly Open Day》","dir":"activities/sofa-meetup-13/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6055a6cf6a48ee5bfe63e2c249c2e3d4","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-13/","publishdate":"2021-12-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-13/","summary":"概要 活动主题：SOFA x 字节码联盟 WAMR 社区「WebAssembly Open Day」 活动时间：2021 年 12 月 18 日（周六）13:00-17:00 活动形式","tags":["SOFA"],"title":"【活动回顾】《WebAssembly Open Day》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-13/","wordcount":1931},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@孙军超 提问：\n 请教一下 JRaft 里， Bolt 的 logback 日志怎么关掉 ?\n A：可以参考这个文件。https://github.com/sofastack/sofa-jraft/issues/724\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@超 提问：\n 这种方式运行 Wasm 的时候，Layotto 自身加上运行时部分初始化需要加载 Dapr 组件时间可能总共要 1-2s（还没有实测，因为目前只用过 Dapr，后面会实际运行一下）。这方面冷启动延迟一方面可以精简 Wasm 的 runtime 仅包括 Dapr 或者 Layotto 的 SDK 通过网络来通信；另一方面就是优化运行时的启动时间。作者对这方面问题有想法吗？\n A:这个问题属于 Layotto 自身如何快速初始化，目前我们也在这方面做一些尝试，比如优化调度算法，让某些特征的函数调度到特定的 Layotto 上，这样就可以让 Layotto 提前初始化好资源。不过这只是函数急速调度中的一个环节，实际落地过程中还有调度算法执行耗时，Pod 启动耗时，函数自身启动耗时等等因素，这也是我们目前正在努力的方向。\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Python 或 C++ 、SDK\n开发 Spring-Boot-Layotto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 让用户使用@SofaService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nSOFARegistry 本周发布 SOFARegistry V6 正式发布的第一个版本。\n主要更新如下：\n 运维难度大幅度降低 自身元数据存储插件化，如果不希望引入 raft 运维的复杂性，支持基于 db 实现。meta、session 无状态化，data 弱状态化。\n 性能和可扩展能力大幅提升 横向扩展能力大幅度提升，能够横向扩展至 300+ session 节点，能够承载亿级服务数据。\n「详细参考」：https://github.com/sofastack/sofa-registry/releases/tag/v6.1.4\n网商双十一基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\n降本提效！注册中心在蚂蚁集团的蜕变之路\n","date":1639724400,"description":"开发者的搬砖日常、社区本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211217/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"42ba6063d3d0ebea2b80a70c23e77497","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211217/","publishdate":"2021-12-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211217/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 本周 Contributor、QA 整理、SOFARegistry 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211217/","wordcount":1387},{"author":"张化仁","categories":"SOFAStack","content":" 文｜张化仁（花名：花伦 )\n网商银行基础技术架构部架构师\n校对｜阚广稳(花名：空门)\n本文 4832 字 阅读 10 分钟\n｜引言｜ 微服务架构下，服务之间的调用错综复杂，一个应用可能会承载着多种不同的业务流量。由于运行在同一个应用进程内，多种业务流量之间势必会存在相互影响的情况。\n如果某种业务流量陡增，导致应用进程负载激增，进而请求排队，其它业务流量也势必会受影响。多数时候这种相互影响的情况都是在容忍范围以内或者可以规避的，特定场景下我们可能就需要考虑通过隔离某些业务流量的方式，来消除业务之间相互影响的风险：\n 例如，当后台调度型的流量影响了在线用户请求；\n 再如，当低敏的甚至可失败的业务影响了高敏的需要重保的业务。\n 业务链路隔离的诉求是业内普遍存在的。通常的方案是新创建一个应用，然后将需要隔离的业务迁移到这个新应用上。\n新建应用的方式，研发运维等都需要付出成倍的成本，相关应用还需要配合改造和迁移。对于只有单个应用需要创建的情况或许还能勉强接受，网商银行部分应用例如高保极简网关、高保客户视图等当前就是采用的这种方案。这种方式是非常笨重的，而且当我们期望特定业务关联的整条链路上的多个应用都进行业务隔离的话，这种方案的成本将非线性上升进而变得难以接受。\n云原生架构下，对容器和流量可以进行更精细化的管控，对于上述业务流量隔离的场景，我们有了更简洁、更灵活、更通用的替代方案\u0026amp;ndash;我们称之为「业务单元隔离」，可以在不创建新应用的情况下实现上述诉求。此方案当前已在包括核心链路在内的网商多个业务场景得到应用，也顺利通过了今年双十一大促的考验。\n那么「业务单元隔离」具体是什么？我们是如何借助「业务单元隔离」实现业务链路的隔离呢？本文将和大家细述。\nPART. 1 概念及基本原理 概念及运维模型 「业务单元隔离」是一套流量染色和资源隔离的方案，可以帮助业务相对简单地实现业务链路隔离。在调研和验证的过程我们也提出了优化改进方案并推进落地，最终进一步减轻了业务接入的成本。\n「业务单元隔离」需要结合两个新的概念来阐述：「AIG」和「业务单元」。\nAIG 是某个应用为了支撑某些业务而隔离出来的一组资源。由一个或多个应用的 AIG 组成的、服务与某个或某类特定业务的业务链路我们称为一个业务单元。保证有且只有符合特征的流量引流到某个业务单元，我们称之为「业务单元的隔离部署」。\n主要任务及配套设施 从「业务单元隔离」的概念中我们不难看出：要实现某个业务链路的流量隔离，至少需要做有以下几件事情：\n1.业务单元构建：给链路上的应用分别创建 AIG 组成一个业务单元，且须保证不能有流量流入新建的业务单元。\n2.业务流量识别：需要通过某种方式识别出上游应用流入的特定业务的流量。\n3.特定业务引流：对于识别到的特定业务的流量，需要有机制让这些流量流向新创建的业务单元。\n很显然，上述的这些事情，必然需要基础设施侧和应用侧相互配合才可实现。如下图所示，相关的基础设施及作用如下：\n1.业务单元构建：需要为 AIG 提供完整的研发/运维/监控支持；\n2.流量识别（RPC）：链路中业务单元上游的应用（A）需要接入打标染色 SDK，以便通过染色管控平台下发打标染色规则；\n3.流量识别（调度）：复杂调度（消息触发，应用单 LDC 内自主分发批任务）通过转换成基于 SOFARPC 的流式任务，从而实现染色和隔离。\n4.特定业务引流：MOSN 侧的精细化路由需要支持 AIG，让流量可以流入到新特定的业务单元。\n业务单元构建 业务单元实际是一个相对抽象的概念，对应一条业务链路。\n网商的实践中，为了让业务单元更加具象化，我们规定一个业务单元内的多个应用，其 AIG 名称（appname-aigcode）中的 aigcode 部分必须尽可能一致。\n因此，构建一个特定的业务单元，本质上是要给链路上相关的应用，都创建出服务于特定业务隔离的资源组（AIG）。\n对于单个应用，构建 AIG 包含两部分：\n一是初始化 AIG 元数据；\n其次是围绕此 AIG 的各种运维操作（扩缩容、上下线、重启、sidecar 注入升级等）。\n可以看到要支持 AIG，PaaS 侧几乎所有运维操作都需要适配，工作量非常很大。所以 PaaS 侧在支持 AIG 这件事情上也必须权衡取舍，决定只在终态的 workload 运维模式下支持了 AIG，这也导致 AIG 强依赖应用从现有的 image 的模式迁移到 workload 的模式。\nworkload 运维模式下，PaaS 将发布和运维的内容都编排成 CRD 资源，交给底层 sigma（K8s）做运维。切换到 workload 运维模式有利于集团统一发布运维体系，也可以更好的支持弹性扩缩容、自愈等场景。\n但相比 image 模式，workload 模式对用户使用习惯和体验上冲击很大，初期相关的问题也非常多。因此尽管网商 workload 一直在有序推进，在后续核心业务接入 AIG 的项目中，为了避免强制切换到 workload 运维模式影响核心业务运维应急，我们也给 PaaS 提了支持仅对 AIG 机器开启了 workload 的诉求，并且针对这种情况做了完备的混合运维验证。\nRPC 流量隔离 业务单元创建好之后，如何确保新的业务单元在不引流的情况下默认没有 RPC 流量流入呢？\n应用的机器之所以有 RPC 流量流入，是因为注册中心（SOFARegistry）和跨机房负载均衡（AntVip）中挂载了机器 IP：应用进程启动成功 MOSN 感知到后，MOSN 会将服务信息注册到 SOFARegistry，发布运维过程机器健康检查通过后 PaaS 侧会调用接口往 AntVip 上挂载机器的 IP。\n所以，要确保新的 AIG 机器默认没有流量流入，就需要 MOSN 和 PaaS 侧做出调整。\n整体调整方案如下图所示：\n如何识别特定业务的 RPC 流量呢？\n上游应用接入打标染色 SDK 之后，其在作为服务端被其它应用调用、作为客户端调用其它应用的时候，都可以被 SDK 中的 RPC 拦截器拦截，拦截器对比 RPC 请求和下发的打标染色规则，一旦 match 就会在 RPC Header 中增加业务请求标识。\n最后，就是将流量引流到特定业务单元。\n借助 MOSN 强大的精细化路由能力，我们可以让流量路由到指定的业务单元,并在业务单元内部收敛。业务单元隔离主要用到了 MOSN 的客户端路由能力，在客户端应用发起调用、请求流经当前 Pod 的 MOSN 时，可以按我们下发的路由规则控制流量的走向。\n调度流量隔离 调度本质是消息，简单的调度场景通常也不会有隔离的诉求。很多有隔离诉求的场景当前都是“消息任务+三层分发”的模式，利用调度触发批处理逻辑。\n三层分发协议是基于 tb-remoting 协议分发请求的，不是标准的 SOFARPC 协议，不经过 MOSN，因此 MOSN 也无法控制这种请求的走向。\n为了解决这个问题，AntScheduler 推出了全新的流式调度模式，通过将三层分发模式转变成多次标准 SOFARPC 调用，从而和 MOSN 无缝配合，满足流量隔离的诉求。\n对于希望调度流量直接路由到 AIG 的场 …","date":1639465200,"description":"网商双十一-基于 ServiceMesh 技术的业务链路隔离技术及实践","dir":"blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"472fb3f3bcfec5e7e03683b781646824","permalink":"https://sofastack.github.io/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","publishdate":"2021-12-14T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","summary":"文｜张化仁（花名：花伦 ) 网商银行基础技术架构部架构师 校对｜阚广稳(花名：空门) 本文 4832 字 阅读 10 分钟 ｜引言｜ 微服务架构下，服务之间的调用错综复杂","tags":["SOFAStack"],"title":"网商双十一-基于 ServiceMesh 技术的业务链路隔离技术及实践","type":"blog","url":"/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","wordcount":4521},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@证道者 提问：\n MOSN 的网络性有做新的技术尝试吗?\n A：这个是我们今年在网络性能上的尝试，内部也在网关场景落地，后续也会开源出来。iouringv 之前我们做过测试，在我们的场景提升有限。\nhttps://mp.weixin.qq.com/s/ioewVcwiB5QA8w3A3gaikg\n「MOSN」：https://github.com/mosn/mosn\n@赵一凡 提问：\n 问下 SOFALookout 的客户端可以直接把默认已有度量指标推送到 ES 吗？\n A：一般客户端是上报到 lookout 服务端, 再由服务端决定要写到哪。\n「SOFALookout」：https://github.com/sofastack/sofa-lookout\n@开发者 提问：\n 这个 Test 模块是用来开发者做测试的还是做自动化测试的？\n A：用于 jraft 的 jepsen 验证，参考这个项目：\nhttps://github.com/sofastack/sofa-jraft-jepsen\njraft 每次发版前要确保通过 jepsen 验证。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@小楼 提问：\n 请问 session 是如何支持 Dubbo 的元数据的？\n A：Registery 的元数据现在不是通用的，只针对 SOFARPC。\n session 之间应该是没有数据同步的吧，跨 session 节点怎么办呢？\n A：现在会同步两个信息，一个是元数据，一个是接口级订阅，接口级订阅是用于兼容没升级的应用。同步的路径是通过存储，类似 K8 的 listwatch 机制，内部落地存储的插件实现是 db，这个块数据比较少，就几千行吧，而且变化很小。\n「SOFARegistery」：https://github.com/sofastack/sofa-jraft\n@小楼 提问：\n 是用什么 db 存储的?\n A：蚂蚁内部的 db 普遍都是 ob，不过代码是兼容 mysql 的。\n「SOFARegistery」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API、分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 Service Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\nService Mesh 双十一后的探索和思考(下)\n蚂蚁 Service Mesh 大规模落地实践与展望\n","date":1639119600,"description":"开发者的搬砖日常、社区本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211210/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c8ef24b5957863311a11eff48080bc30","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211210/","publishdate":"2021-12-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211210/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开发者的搬砖日常、社区本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211210/","wordcount":1289},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#23：蚂蚁服务发现的大规模实践与展望\n 活动时间：12 月 09 日，周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#23：蚂蚁服务发现的大规模实践与展望 naming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。本次分享将会包含以下内容：\n 蚂蚁内部实践 naming 在云原生时代下的发展方向及趋势 总结和展望 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 林育智 蚂蚁集团高级技术专家。 目前在蚂蚁集团中间件团队负责 naming 等项目的研发工作 议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:30 蚂蚁服务发现的大规模实践与展望 林育智，蚂蚁集团高级技术专家\n你将收获 了解蚂蚁集团在 SOFARegistry 新挑战及云原生时代的思考。\n了解 SOFARegistry 实践经验。\n了解蚂蚁集团对未来 naming 的思考及 naming 在云原生方向上的探索。\n了解未来 SOFARegistry 的发展和相关的社区动向。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1639033200,"description":"12 月 09 日周三晚 19 点，线上直播第 23 期。","dir":"activities/sofa-channel-23/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"781a397af19af21ad03eef254f28fe69","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-23/","publishdate":"2021-12-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-23/","summary":"概要 活动主题：SOFAChannel#23：蚂蚁服务发现的大规模实践与展望 活动时间：12 月 09 日，周三晚 19 点 活动形式：线上直播 资料下载：戳这里","tags":["SOFAChannel","SOFARegistry"],"title":"SOFAChannel#23：蚂蚁服务发现的大规模实践与展望","type":"activities","url":"/sofastack.tech/activities/sofa-channel-23/","wordcount":709},{"author":"顾欣","categories":"SOFAStack","content":" Service Mesh 是下一代的微服务架构基础。蚂蚁集团从 2018 年初就开始了技术探索并进行了落地试点。目前， Service Mesh 覆盖了蚂蚁数千个应用，实现了核心链路全覆盖。\n蚂蚁集团通过 Service Mesh 的大规模落地，向云原生走出了坚实的一步，验证了可行性，真切看到了基础设施下沉后无论是对业务还是对基础设施团队都带来了研发和运维效率的提升，成本的降低。\n与此同时，蚂蚁也在积极将成熟的技术开放给社会，目前已将自研数据面 MOSN 开源，欢迎开源爱好者一起共建。\nhttps://github.com/mosn/mosn\n｜前言｜ 微服务架构是当今互联网和金融机构渐趋主流的系统架构模式，其核心是集成服务通信、服务治理功能的服务框架，微服务框架在持续演进同时，服务网格（Service Mesh）作为一种新型的微服务架构，因架构灵活、普适性强，被认为具有较好发展前景。\n中国工商银行（后简称工行）主动探索服务网格领域，从 2019 年开始服务网格技术预研工作，通过对服务网格技术深入研究和实践后，于 2021 年建设了服务网格平台。服务网格与现有微服务架构融合发展，助力工行应用架构向分布式、服务化转型，承载未来开放平台核心银行系统。\nPART. 1 业界服务网格发展现状 自 2016 年服务网格技术诞生以来，业界涌现了诸多的开源产品，如 Istio（Google + IBM + Lyft）、Linkerd（Twitter）、Consul（Hashicorp）等。其中以 Istio 社区活跃度和认可度最高，被作为服务网格的标杆开源产品。\n服务网格是一个专门处理服务通讯的基础设施层。它通过在业务 Pod 中注入 Sidecar 容器，接管业务容器的通信流量，同时 Sidecar 容器与网格平台的控制平面对接，基于控制平面下发的策略，对代理流量实施治理和管控，将原有服务框架的治理能力下层到 Sidecar 容器中，从而实现了基础框架能力的下沉，与业务系统解耦。\n图 1：服务网格示意图\nSidecar 容器接管后端服务通信的进出流量后，通过标准协议进行服务间通信，可实现跨语言、跨协议的服务互访。此外，Sidecar 容器可对代理的流量进行管控，如统一的服务路由、安全加密、监控采集等。\n图 2：服务网格请求流转过程示意图\nPART. 2 服务网格技术在工行的 探索与实践 工行从 2015 年开启了 IT 架构转型工程，截止目前分布式体系已覆盖 240 余个关键应用，生产已有约超 48 万个提供方分布式服务节点，日均服务调用量超 127 亿，逐步实现了超越主机性能容量的集群处理能力。工行分布式服务平台在稳定支撑已有业务系统的平稳运行同时，也存在一些业界共性的挑战，诸如：\n（1）跨语言技术栈的互联互通需研发多套基础框架，技术研发和维护成本高。\n（2）多产品线下，各应用使用了不同版本的基础框架，推动各应用升级框架周期较长，生产并行运行多版本的基础框架，兼容压力较大。\n为解决当前痛点，工行积极引入服务网格技术，探索解耦业务系统与基础设施，完善服务治理能力。\n与微服务框架融合发展，构建企业级服务网格平台 服务网格（Service Mesh）平台在建设过程中，集成了原有分布式体系的注册中心、服务监控等基础设施，将原服务框架客户端中最基础的通讯协议编解码能力以轻量级客户端的形式保留在业务系统中，其余服务框架客户端的能力均下沉至 Sidecar 中，可与服务框架兼容发展，平滑过渡。\n目前工行已完成服务网格（Service Mesh）平台的建设，在与分布式服务平台融合发展过程中，打通了异构语言系统的服务治理与监控体系，解耦了业务与中间件系统，丰富了流量治理能力，并已在智能投顾、文字识别等应用完成业务试点。\n图 3：服务网格边车（Sidecar）与微服务 SDK 对比图\n服务网格控制平面包含了配置中心、注册中心、安全中心、管控中心、监控中心、日志中心等模块。数据平面 Sidecar 与原服务框架使用相同的通讯协议（Dubbo/Spring Cloud），支持服务网格系统与原服务框架系统互联互通，平滑迁移。\n图 4：工行服务网格架构图\n探索企业级方案，支持规模化部署和平滑迁移 工行服务网格在大数据、高频联机等服务场景下，对流量代理部署模式、平滑迁移、性能优化等方面开展了落地实践。\n（1）大数据场景下的无侵入流量代理部署模式\n工行应用开发语言主要使用 Java，但在大数据领域 Python 语言也被广泛使用。针对异构语言场景，服务网格平台提供了无侵入透明劫持的流量代理方案，简化了异构语言应用接入难度。无侵入流量代理的核心是通过修改网络 Iptables 规则，强制拦截进出业务容器的流量，并将这部分流量重定向至 Sidecar 容器。\n其具体实现为：在启动业务 Pod 时，通过 Init Container（初始化容器）修改业务 Pod 的网络 Iptables 规则，该规则让进出业务容器的流量都强制重定向至 Sidecar 容器，实现 Sidecar 容器对业务容器的流量接管。\n图 5：透明劫持流量代理示意图\n但是 Iptables 对性能和可维护性都存在较大的挑战，故在联机高频服务场景，我们提供了轻量级客户端与 Sidecar 协作的流量代理方案。\n（2）高频联机场景下的低侵入流量代理部署模式\n在联机高频服务场景，我们通过对业务应用引入轻量级的客户端，该客户端在对业务透明的前提下，改变业务应用的服务注册发现行为，将原往注册中心发起的服务注册与订阅的行为转变为往本地 127.0.0.1 的 Sidecar 地址发起服务注册与订阅，并由 Sidecar 代理向注册中心发起服务注册与订阅。业务容器通过 Sidecar 代理订阅后，本地获取的服务目的地址则为 127.0.0.1 的 Sidecar 地址，后续所有请求将会直接发往 Sidecar，再由 Sidecar 转发至真实的服务目的地址，实现流量代理能力。\n图 6：端口流量代理示意图\n（3）传统部署向网格化部署的平滑迁移\n目前工行微服务主要有基于 Dubbo 和 Spring Cloud 两种服务实例组成，且已在生产环境大规模运行，在引入服务网格系统时需具备与原微服务系统的平滑过渡能力。工行通过服务网格系统同时支持 Dubbo 与 Spring cloud 协议，服务网格实例可与原服务框架实例通过相同协议互相访问。使在同一注册中心下，服务网格系统与原分布式服务系统可融合发展，平滑过渡。\n图 7：平滑迁移示意图\n（4）规模化部署后的性能挑战与优化\n目前工行最大的注册中心集群上有超 48 万提供者的超大规模业务场景，而在开源 Isito 架构中，服务发现的目的地址、配置信息等会通过 Pilot 的 Xds API 进行全量下发。在大量服务实例的情况下，全量下发会影响 Pilot 和 Sidecar 的性能和稳定性。服务网格平台通过引入第三方注册中心与配置中心。由 Sidecar 直接对接注册中心与配置中心，支持按需订阅，配置精准下发，大幅降低 Pilot 和 Sidecar 压力。通过压测，控制平面具备支持百万级实例的性能容量能力。\n图 8：工行控制面组件演进 …","date":1639033200,"description":"Service Mesh 在中国工商银行的探索与实践","dir":"blog/exploration-and-practice-of-service-mesh-in-icbc/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a597abc497eb1d695c4aa838d6cb6545","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","publishdate":"2021-12-09T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","summary":"Service Mesh 是下一代的微服务架构基础。蚂蚁集团从 2018 年初就开始了技术探索并进行了落地试点。目前， Service Mesh 覆盖了蚂蚁数千个应用，实现了核心链路全覆盖。 蚂蚁集","tags":["SOFAStack"],"title":"Service Mesh 在中国工商银行的探索与实践","type":"blog","url":"/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","wordcount":3781},{"author":"马振军","categories":"SOFAStack","content":" 文｜马振军（花名：古今 )\n在基础架构领域耕耘多年\n目前在蚂蚁集团中间件团队\n负责 MOSN、Layotto 等项目的开发工作\n校对｜卓与、齐天\n本文 9053 字 阅读 18 分钟\n｜前言｜ 在过去几年里，蚂蚁集团的基础设施进行了广受瞩目的大规模 Mesh 化改造，成为业内服务网格化的一个标杆。在收获了基础架构团队掌握数据平面带来业务敏捷性的同时，也享受到了将基础设施 SDK 从应用中剥离出来后，带来的应用和基础设施双方更高的易维护性。\n然而服务网格并不是银弹，大规模落地后也面临着新的问题。\n适逢其时，微软牵头的 Dapr 横空出世，把分布式应用运行时的概念带入了大众视野，我们也尝试使用这种思路来解决 Mesh 化后遗留的问题。\n本文通过回顾蚂蚁集团一路从微服务架构到 Service Mesh 再到分布式应用运行时的整个演进历程，结合生产落地过程中遇到的各种问题及思考，尝试探讨一下未来五年，云原生运行时可能的发展方向。\nPART. 1 从 Service Mesh 到应用运行时 2018 年，蚂蚁集团在 Service Mesh 刚刚开始流行的时候，就在这个方向上大力投入，如今已三年有余。Sevice Mesh 早已在公司内大规模落地，支持了生产环境数十万容器的日常运行。\n19 年下半年，Dapr 项目正式开源并持续火爆，应用运行时的概念引起了人们的关注，蚂蚁集团也踏上了从 Service Mesh 到应用运行时的演进道路。\nA、蚂蚁 Service Mesh 实践的收获与遗留问题 在传统的微服务架构下，基础架构团队一般会为应用提供一个封装了各种服务治理能力的 SDK，这种做法虽然保障了应用的正常运行。但缺点也非常明显，每次基础架构团队迭代一个新功能都需要业务方参与升级才能使用，而遇到 bugfix 版本，往往需要强推业务方升级，这里面的痛苦程度基础架构团队的每一个成员都深有体会。\n伴随着升级的困难，随之而来的就是应用使用的 SDK 版本差别非常大。生产环境同时跑着各种版本的 SDK ，这种现象又会让新功能的迭代必须考虑各种兼容，时间一长就会让代码维护非常困难，有些祖传逻辑更是不敢改也不敢删。\n同时这种“重” SDK 的开发模式，导致异构语言的治理能力始终很难对标主语言，各种保障高可用的能力都无法作用于异构语言应用。\n后来有人提出了 Service Mesh 的理念，这种理念旨在把服务治理能力跟业务解耦，让两者通过进程级别的通信方式进行交互。在这种架构下，各种服务治理能力从应用中剥离，运行在独立的进程中，让业务团队跟基础架构团队可以各自进行迭代更新，大幅度提升效率。\n同时 SDK 因为功能减少而变“轻”则降低了异构语言的接入门槛，让这些语言开发的应用有机会对标主语言的治理能力。\n在看到 Service Mesh 理念的巨大潜力之后，蚂蚁集团很快就在这个方向上进行了大力投入，如上图所示，首先是使用 Go 语言自研了可以对标 envoy 的数据面。然后把 RPC 中各种治理能力下沉了到 MOSN 中，这样 RPC 的 SDK 变“轻”，而其他基础设施的 SDK 则依旧维持现状。\n在 RPC 能力完成 Mesh 化改造之后，我们进行了快速推广，如今达到了数千个应用，数十万个容器的生产规模。与此同时，全站升级频率最快可以达到 1~2 次/月，这跟传统微服务架构下 1~2 次/年的升级频率相比达到了一个质的提升。\nB、蚂蚁初步泛 Mesh 化的探索 在 RPC 能力完成 Mesh 化改造并且验证了这种架构的可行性以及体验到 Mesh 化带来的迭代效率大幅度提升的收益以后，我们正式走上了整个基础设施泛 Mesh 化改造的道路。\n如上图所示，在泛 Mesh 化改造的大趋势下，除了 RPC 以外，缓存、消息、配置等一些常用的基础设施能力迅速从应用中剥离，下沉到 MOSN 中，这套架构极大的提高了整个基础架构团队的迭代效率。\n正如软件工程没有银弹说的那样，随着泛 Mesh 化落地规模逐渐扩大，我们逐渐意识到它遗留的问题，如上图所示。\n在这种架构下，虽然应用跟基础设施之间加了一层网络代理，但对于基础设施协议部分的处理依然保留在 SDK 中，这就导致应用本质上还是要面向某个基础设施做开发，比如想使用 Redis 作为缓存实现，那么应用需要引入 Redis 的 SDK，未来如果想切换到 Memcache 等其他缓存实现，则必须对应用进行改造。\n除了替换 SDK 之外，甚至还涉及到调用 API 的调整，因此这种架构完全无法满足当前公司面临的同一个应用在多个平台部署的需求。\n与上述问题类似，泛 Mesh 化改造后，“轻” SDK 的低开发成本让各种异构语言都有机会接入到整个基础设施体系中来，享受多年基础设施建设的红利。\n但由于 SDK 里仍然保留了通信、序列化等协议的处理逻辑，因此随着接入的语言越来越多样化，这里依然存在不能忽视的开发成本。换句话说，泛 Mesh 化改造带来的“轻” SDK 跟传统微服务架构相比虽然降低了异构语言接入基础设施的门槛，但是随着接入语言越来越多样，依赖的中间件能力越来越丰富，我们还需要尝试进一步降低这种门槛。\n如果对上述两个问题做一层抽象，本质上都可以归结为应用跟基础设施之间的边界不够清晰，或者说应用中始终嵌入了某种基础设施实现中特有的处理逻辑，导致两者一直耦合在一起。\n因此如何定义应用跟基础设施之间的边界，让两者彻底解绑是我们当下必须要思考解决的问题。\nPART. 2 重新定义基础设施边界 A、如何看待 Dapr Dapr 项目由微软牵头，于 19 年下半年正式开源，作为分布式应用运行时的一种实现方案登上舞台，引起了广泛关注，它向我们展示了如何定义应用跟基础设施之间的边界。\n上图是 Dapr 官方提供的架构图，跟 Service Mesh 架构类似，Dapr 采用 Sidecar 的模型部署在应用跟基础设施之间。但与之不同的是，Dapr 基于 HTTP/gRPC 这类标准协议向应用提供了一套语义明确、面向能力的 API ，让应用可以不再关心基础设施的实现细节，只需专注业务本身依赖哪些能力即可。\n目前 Dapr 已经提供了较为丰富的 API，包括状态管理、发布订阅、服务调用等常见基础设施能力，基本能够覆盖业务日常开发的需求，并且每种能力都对应了多种具体的基础设施实现，开发者可以按需自由切换且这种切换对应用完全透明。\n除了能力之外，Dapr 官方也给出了 Dapr 跟 Service Mesh 之间的异同点，如上图所示。\n两者虽然有一些交集，但本质不同，Service Mesh 强调的是透明的网络代理，它并不关心数据本身，而 Dapr 强调的是提供能力，是真正站在应用的角度来思考如何降低应用的开发成本。\nDapr 本身的优势非常明显，不过 Service Mesh 所提供的丰富的网络治理能力，也是保障应用生产稳定性的关键点。\n与此同时 Dapr 跟基础设施的交互也无法离不开网络，因此有没有一种解决方案可以让应用运行时跟 Service Mesh 双剑合璧，降低应用开发成本的同时保留丰富的网络治理能力？\nB、Layotto：Servcie Mesh \u0026amp;amp; …","date":1638860400,"description":"云原生运行时的下一个五年","dir":"blog/the-next-five-years-of-cloud-native-runtime/","fuzzywordcount":8100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2498666960b384ded6da40a6158f9535","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","publishdate":"2021-12-07T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","summary":"文｜马振军（花名：古今 ) 在基础架构领域耕耘多年 目前在蚂蚁集团中间件团队 负责 MOSN、Layotto 等项目的开发工作 校对｜卓与、齐天 本文 9053 字 阅","tags":["SOFAStack"],"title":"云原生运行时的下一个五年","type":"blog","url":"/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","wordcount":8008},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@xj 提问：\n 请问在 UseNetpollMode 模式下，for 循环读取链接里面的数据，那么如果遇到链接数据源源不断的情况：比如刚 readOnce 读取完毕所有数据后，再下一个循环，又有数据被写入到链接接收缓冲区里面，那么又会继续读取到。此时会损耗很多时间处理这个链接的 io 事件，影响其他链接的处理。\n A：执行久了这个协程会被 runtime 调度走哟,当然也可以多少次 read 就主动 schedule, 这个可能就要看压测数据了，配置多少合适。最开始 nginx 也是存在类似问题。\nhttps://github.com/nginx/nginx/commit/fac4c7bdf53ee7d8fec6568f1e9fecefcde6feba#diff-8f5c3450fb35200b97b96bb249ca15d6\n「MOSN」：https://github.com/mosn/mosn\n@子旦 提问：\n 请教下群里的大佬，SOFARPC 相较于 Dubbo RPC 的优势在哪？有没有相关资料，求分享～\n A：可以看下 FAQ 里面有描述。\nhttps://www.sofastack.tech/projects/sofa-rpc/faq/\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@福自奇 提问：\n 5 个 jraft 节点，一个节点挂了没及时维修，剩下四个节点两两网络分区，2|2，此时集群是不是不可用了。\n A：是，因为已经多数派不可用了（最多只有 2 个节点可用）。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@福自奇 提问：\n bolt 下面输出的日志，jraft 提供了归档或者自动删除的选项吗？现在发现 bolt 下面的日志占用内存 7g 了，是要自己写脚本定时删除吗？\n A：日志没有自动删，可以自己用脚本删。\n 这个如果没有节点异常，好像不会打？只有节点挂了才会打？\n A：bolt 日志正常都会有，如果想关掉可以看下 GitHub 上最新被 close 的 issue。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy 开发 in-memory 组件\nfail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 降本提效！注册中心在蚂蚁集团的蜕变之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1638514800,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211203/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3866acfa6aee9d270af2995d820dcb64","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211203/","publishdate":"2021-12-03T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211203/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211203/","wordcount":1289},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@洪艺辉 提问：\n 无损迁移 TCP Listener 之后，在新 MOSN 上重新 server.Serve(net.Listener)，老 MOSN 那个 Listenr 能马上死掉的 API?\n A：New MOSN 启动成功之后，就关闭老的。\n「MOSN」：https://github.com/mosn/mosn\n@大白 提问：\n MOSN 借助 FastHTTP 解析，是不是就没考虑大的请求了。这边不做处理的考虑是什么呢？\n A：MOSN 有个地方限制太大的请求，好像还可以配置来着。\n 是的，注意到有限制最大 body 大小，但是遇到一些大请求对 Sidecar 压力会很大吧。\n A：RPC 场景一般没有大包，我们有个 issue 是直接 Stream。FastHTTP 也支持流式，要适配下，有兴趣可以一起来搞搞。\nhttps://github.com/mosn/mosn/issues/1676\n「MOSN」：https://github.com/mosn/mosn\n@xj 提问：\n 咨询下 MOSN 在做 gRPC 代理的时候，如何解决代理识别客户端新增的 proto ？难道客户端多一个 proto 代理也要增加？ 还是说直接在 HTTP2.0 层面做？\n A：就是 HTTP2.0 层面，代理一般不需要识别 body。\n「MOSN」：https://github.com/mosn/mosn\n@TyCoding 提问：\n 请问 SOFARPC 不使用 SOFABoot 的话，就只能用这种方式发布服务和消费吗？那如果多个接口呢?\n A：多个接口，就多个 providerconfig 即可。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@王金鹏 提问：\n 有个问题想请教一下 SOFABoot 和 bolt 之间版本兼容的问题，SOFABoot 版本 2.3.4，bolt 原版本 1.4.2 升级到 1.5.8 会不会有兼容性的问题？\n A：最好不要这么升级，bolt 不同版本 API 可能存在差异，最好直接把 SOFABoot 版本升级上去，对应的依赖都是我们测试过的。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy 开发 in-memory 组件\nfail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 降本提效！注册中心在蚂蚁集团的蜕变之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1637910000,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211126/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"134422b15d1bd92c49604b5b45687076","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211126/","publishdate":"2021-11-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211126/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211126/","wordcount":1331},{"author":"林育智","categories":"SOFAStack","content":" 文｜林育智（花名：源三 )\n蚂蚁集团高级专家 专注微服务/服务发现相关领域\n校对｜李旭东\n本文 8624 字 阅读 18 分钟\n｜引 言｜ 服务发现是构建分布式系统的最重要的依赖之一， 在蚂蚁集团承担该职责的是注册中心和 Antvip，其中注册中心提供机房内的服务发现能力，Antvip 提供跨机房的服务发现能力。\n本文讨论的重点是注册中心和多集群部署形态（IDC 维度），集群和集群之间不涉及到数据同步。\nPART. 1 背 景 回顾注册中心在蚂蚁集团的演进，大概起始于 2007\u0026amp;frasl;2008 年，至今演进超过 13 年。时至今日，无论是业务形态还是自身的能力都发生了巨大的变化。\n简单回顾一下注册中心的历代发展：\nV1：引进淘宝的 configserver V2：横向扩展 从这个版本开始，蚂蚁和阿里开始独立的演进，最主要的差异点是在数据存储的方向选择上。蚂蚁选择了横向扩展，数据分片存储。阿里选择了纵向扩展，加大 data 节点的内存规格。\n这个选择影响到若干年后的 SOFARegistry 和 Nacos 的存储架构。\nV3 / V4：LDC 支持和容灾 V3 支持 LDC 单元化。\nV4 增加了决策机制和运行时列表，解决了单机宕机时需要人工介入处理的问题，一定程度上提升高可用和减少运维成本。\nV5：SOFARegistry 前四个版本是 confreg，17 年启动 V5 项目 SOFARegistry，目标是：\n1.代码可维护性：confreg 代码历史包袱较重\n 少量模块使用 guice 做依赖管理，但大部分模块是静态类交互，不容易分离核心模块和扩展模块，不利于产品开源。\n 客户端与服务端的交互模型嵌套复杂，理解成本极高且对多语言不友好。\n 2.运维痛点：引入 Raft 解决 serverlist 的维护问题，整个集群的运维包括 Raft，通过 operator 来简化。\n3.鲁棒性：在一致性 hash 环增加多节点备份机制（默认 3 副本），2 副本宕机业务无感。\n4.跨集群服务发现：站内跨集群服务发现额外需要 antvip 支撑，希望可以统一 2 套设施的能力，同时商业化场景也有跨机房数据同步的需求。\n这些目标部分实现了，部分实现的还不够好，例如运维痛点还残留一部分，跨集群服务发现在面对主站的大规模数据下稳定性挑战很大。\nV6：SOFARegistry 6.0 2020 年 11 月，SOFARegistry 总结和吸收内部/商业化打磨的经验，同时为了应对未来的挑战，启动了 6.0 版本大规模重构计划。\n历时 10 个月，完成新版本的开发和升级工作，同时铺开了应用级服务发现。\nPART. 2 挑 战 当下面临的问题 集群规模的挑战 数据增长：随着业务的发展，业务的实例数在不断增长，pub/sub 的数量也相应增长。以其中一个集群为例，2019 年的数据为基准数据，在 2020 年 pub 接近千万级。 下图是该集群历年双十一时的数据对比和切换应用级的优化效果。相比 2019 年双十一，2021 年双十一接口级的 pub 增长 200%，sub 增长 80%。\n 故障爆炸半径增长：集群接入的实例越多，故障影响的业务和实例数也就越多，保障业务的稳定是最基础也是优先级最高的要求。\n 考验横向扩展能力：集群达到一定的规模后，是否还具备继续横向扩展的能力，需要集群具备良好的横向扩展能力，从 10 扩到 100 和从 100 扩到 500 是不一样的难度。\n HA 能力：集群实例数多了后，面临的节点总体的硬件故障率也相应增高，各种机器故障集群是否能快速恢复？有运维经验的同学都知道，运维一个小集群和运维一个大集群面临的困难简直是指数级增长。\n 推送性能：大多数服务发现的产品都选择了数据的最终一致性，但是这个最终在不同集群的规模下到底是多久？相关的产品其实都没有给出明确的数据。\n 但是实际上，我们认为这个指标是服务发现产品的核心指标。这个时长对调用有影响：新加的地址没有流量；删除的地址没有及时摘除等。蚂蚁集团的 PaaS 对注册中心的推送时延是有 SLO 约束的：如果变更推送列表延时超过约定值，业务端的地址列表就是错误的。我们历史上也曾发生过因推送不及时导致的故障。\n业务实例规模增加的同时也带来推送的性能压力：发布端 pub 下面的实例数增加；订阅端业务实例数增加；一个简单的估算，pub/sub 增长 2 倍，推送的数据量是 2*2，增长 4 倍，是一个乘积的关系。同时推送的性能也决定了同一时间可以支持的最大运维业务实例数，例如应急场景下，业务大规模重启。如果这个是瓶颈，就会影响故障的恢复时间。\n集群规模可以认为是最有挑战性的，核心的架构决定了它的上限，确定后改造成本非常高。而且往往等到发现瓶颈的时候已经是兵临城下了，我们要选择能拉高产品技术天花板的架构。\n运维的挑战 SOFARegistryX 立项时的一个主要目标是具备比 confreg 更好的运维能力：引入 meta 角色，通过 Raft 选举和存储元信息，提供集群的控制面能力。但是事实证明，我们还是低估了可运维的重要性，正如鲁迅先生说：【程序员的工作只有两件事情，一件是运维，另一件还是运维】。\n三年前的目标放到今天已经严重滞后了。\n 集群数增长：蚂蚁集团内部的业务是分站点部署的（简单理解为每个站点是一块相对比较独立的业务，需要不同级别的隔离），同时一个站点需要部署多套集群：容灾需要分机房部署；开发需要分多环境。部署站点的数目增长超出我们的想像。现在已经达到数百个集群了，还在迅速增长中，增长速度参考最近几年美联储的货币供应量增长速度。以前认为有些运维工作可以苟且，人肉顶一下，集群数增长后，苟且次数太多了，挤占了开发/运维同学的精力，完全没资源去规划诗和远方。 业务打扰：业务的运维是全天候 7*24 的，容量自适应/自愈/MOSN 每月一版本把全站应用犁一遍等等。下图是每分钟运维的机器批数，可以看到，就算是周末和深夜，运维任务也是不断的。 蚂蚁集团的同学对注册中心的运维公告应该是比较熟悉和痛恨的。因为业务的敏感性，注册中心之前一直是停机发布和运维，这个时候需要锁定全站的发布/重启动作。为了尽量少影响业务，注册中心相关的同学只能献祭一头黑发，在深夜低峰期做相关的操作。即使这样，仍然没办法做到对业务零打扰。\n云原生时代 naming 的挑战 云原生的技术时代下，可以观察到一些趋势：\n 微服务/FaaS 的推广导致轻型应用增多：实例数增多，需要能支撑更大的业务规模\n 应用实例的生命周期更短：FaaS 按需使用，autoscale 容量自适应等手段导致实例的涨潮退潮更频繁，注册中心的性能主要体现在实例变更的响应速度上\n 多语言支持：在过去，蚂蚁集团主要的开发体系是 Java，非 Java 语言对接基础设施都是二等公民，随着 AI 和创新性业务的需求，非 Java 体系的场景越来越多。如果按照每种语言一个 SDK，维护成本会是个噩梦，当然 sidecar（MOSN）是个解法，但是自身是否能支持低侵入性的接入方式，甚至 sdk-free 的能力？\n 服务路由：在过去绝大部分的场景都可以认为 endpoint 是平等的，注册中心只提 …","date":1637650800,"description":"降本提效！注册中心在蚂蚁集团的蜕变之路","dir":"blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","fuzzywordcount":7800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f75ce63f7162ca26342a52f74ce577ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","publishdate":"2021-11-23T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","summary":"文｜林育智（花名：源三 ) 蚂蚁集团高级专家 专注微服务/服务发现相关领域 校对｜李旭东 本文 8624 字 阅读 18 分钟 ｜引 言｜ 服务发现是构建分布式系统的最重要的","tags":["SOFAStack"],"title":"降本提效！注册中心在蚂蚁集团的蜕变之路","type":"blog","url":"/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","wordcount":7736},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@黄润良 提问：\n 有什么办法可以获取日志的这两个值吗？\n A：可以参考下图\n MOSN：https://github.com/mosn/mosn\n@爱德华 提问：\n 请教一下，SOFAJRaft 在 leader 晋升后，给每个 follower 发送的探测请求是什么？是 Raft 论文中，为了“提交上一个 term 日志项”，才发送的空请求吗？\n A：是为了探测该 follower 与 leader 的日志差异。找对 nextIndex 对吧？提交上一个 term 要通过 noop 日志。Raft 论文里有个 nextIndex，你可以看看相关内容， 日志复制那个小节。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@Bazingga 提问：\n 源码里面是怎么支持的呀，RheaKV 是使用了这个功能是吧。\n A：可以参考下这个 https://blog.csdn.net/SOFAStack/article/details/91458041\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@爱德华 提问：\n 我请教一下关于 follower 截断日志的问题。leader 拥有日志：101,102,103，它们的 term 为 2；follower 拥有日志：101,102,103,104，它们的 term 为 2；按照正常逻辑，follower 应该截断 104 的日志。根据上面的代码，在探测消息中，这种情况，follower 会返回了 success=true，并携带 lastLogIndex=104。那么 follower 是在什么时候截断 104 的呢？\n A：checkAndResolveConflict 方法。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 在服务注册时，使用枚举值替代字符串硬编码\n优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n开发 spring-boot-laytto\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 rometheus on CeresDB 演进之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1637305200,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211119/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"05f1b91614900f1434b7748905df364b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211119/","publishdate":"2021-11-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211119/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211119/","wordcount":1249},{"author":"刘家财","categories":"SOFAStack","content":" 文｜刘家财（花名：尘香 )\n蚂蚁集团高级开发工程师 专注时序存储领域\n校对｜冯家纯\n本文 7035 字 阅读 10 分钟\nCeresDB 在早期设计时的目标之一就是对接开源协议，目前系统已经支持 OpenTSDB 与 Prometheus 两种协议。Prometheus 协议相比 OpenTSDB 来说，非常灵活性，类似于时序领域的 SQL。\n随着内部使用场景的增加，查询性能、服务稳定性逐渐暴露出一些问题，这篇文章就来回顾一下 CeresDB 在改善 PromQL 查询引擎方面做的一些工作，希望能起到抛砖引玉的作用，不足之处请指出。\nPART. 1 内存控制 对于一个查询引擎来说，大部分情况下性能的瓶颈在 IO 上。为了解决 IO 问题，一般会把数据缓存在内存中，对于 CeresDB 来说，主要包括以下几部分：\n MTSDB：按数据时间维度缓存数据，相应的也是按时间范围进行淘汰\n Column Cache：按时间线维度缓存数据，当内存使用达到指定阈值时，按时间线访问的 LRU 进行淘汰\n Index Cache：按照访问频率做 LRU 淘汰\n 上面这几个部分，内存使用相对来说比较固定，影响内存波动最大的是查询的中间结果。如果控制不好，服务很容易触发 OOM 。\n中间结果的大小可以用两个维度来衡量：横向的时间线和纵向的时间线。\n控制中间结果最简单的方式是限制这两个维度的大小，在构建查询计划时直接拒绝掉，但会影响用户体验。比如在 SLO 场景中，会对指标求月的统计数据，对应的 PromQL 一般类似 sum_over_time(success_reqs[30d]) ，如果不能支持月范围查询，就需要业务层去适配。\n要解决这个问题需要先了解 CeresDB 中数据组织与查询方式，对于一条时间线中的数据，按照三十分钟一个压缩块存放。查询引擎采用了向量化的火山模型，在不同任务间 next 调用时，数据按三十分钟一个批次进行传递。\n在进行上述的 sum_over_time 函数执行时，会先把三十天的数据依次查出来，之后进行解压，再做一个求和操作，这种方式会导致内存使用量随查询区间线性增长。如果能去掉这个线性关系，那么查询数量即使翻倍，内存使用也不会受到太大影响。\n为了达到这个目的，可以针对具备累加性的函数操作，比如 sum/max/min/count 等函数实现流式计算，即每一个压缩块解压后，立即进行函数求值，中间结果用一个临时变量保存起来，在所有数据块计算完成后返回结果。采用这种方式后，之前 GB 级别的中间结果，最终可能只有几 KB。\nPART. 2 函数下推 不同于单机版本的 Prometheus ，CeresDB 是采用 share-nothing 的分布式架构，集群中有主要有三个角色：\n datanode：存储具体 metric 数据，一般会被分配若干分片(sharding)，有状态\n proxy：写入/查询路由，无状态\n meta：存储分片、租户等信息，有状态。\n 一个 PromQL 查询的大概执行流程：\n1.proxy 首先把一个 PromQL 查询语句解析成语法树，同时根据 meta 中的分片信息查出涉及到的 datanode\n2.通过 RPC 把语法树中可以下推执行的节点发送给 datanode\n3.proxy 接受所有 datanode 的返回值，执行语法树中不可下推的计算节点，最终结果返回给客户端\nsum(rate(write_duration_sum[5m])) / sum(rate(write_duration_count[5m])) 的执行示意图如下：\n为了尽可能减少 proxy 与 datanode 之间的 IO 传输，CeresDB 会尽量把语法树中的节点推到 datanode 层中，比如对于查询 sum(rate(http_requests[3m])) ，理想的效果是把 sum、rate 这两个函数都推到 datanode 中执行，这样返回给 proxy 的数据会极大减少，这与传统关系型数据库中的“下推选择”思路是一致的，即减少运算涉及的数据量。\n按照 PromQL 中涉及到的分片数，可以将下推优化分为两类：单分片下推与多分片下推。\n单分片下推 对于单分片来说，数据存在于一台机器中，所以只需把 Prometheus 中的函数在 datanode 层实现后，即可进行下推。这里重点介绍一下 subquery【1】 的下推支持，因为它的下推有别于一般函数，其他不了解其用法的读者可以参考 Subquery Support【2】。\nsubquery 和 query_range【3】 接口（也称为区间查询）类似，主要有 start/end/step 三个参数，表示查询的区间以及数据的步长。对于 instant 查询来说，其 time 参数就是 subquery 中的 end ，没有什么争议，但是对于区间查询来说，它本身也有 start/end/step 这三个参数，怎么和 subquery 中的参数对应呢？\n假设有一个步长为 10s 、查询区间为 1h 的区间查询，查询语句是\n那么对于每一步，都需要计算 3600\u0026amp;frasl;10=360 个数据点，按照一个小时的区间来算，总共会涉及到 360*360=129600 的点，但是由于 subquery 和区间查询的步长一致，所以有一部分点是可以复用的，真正涉及到的点仅为 720 个，即 2h 对应 subquery 的数据量。\n可以看到，对于步长不一致的情况，涉及到的数据会非常大，Prometheus 在 2.3.0 版本后做了个改进，当 subquery 的步长不能整除区间查询的步长时，忽略区间查询的步长，直接复用 subquery 的结果。这里举例分析一下：\n假设区间查询 start 为 t=100，step 为 3s，subquery 的区间是 20s，步长是 5s，对于区间查询，正常来说：\n1.第一步\n需要 t=80, 85, 90, 95, 100 这五个时刻的点\n2.第二步\n需要 t=83, 88, 83, 98, 103 这五个时刻的点\n可以看到每一步都需要错开的点，但是如果忽略区间查询的步长，先计算 subquery ，之后再把 subquery 的结果作为 range vector 传给上一层，区间查询的每一步看到的点都是 t=80, 85, 90, 95, 100, 105…，这样就又和步长一致的逻辑相同了。此外，这么处理后，subquery 和其他的返回 range vector 的函数没有什么区别，在下推时，只需要把它封装为一个 call （即函数）节点来处理，只不过这个 call 节点没有具体的计算，只是重新根据步长来组织数据而已。\ncall: avg_over_time step:3 └─ call: subquery step:5 └─ binary: == ├─ selector: a_gauge └─ literal: 2 在上线该优化前，带有 subquery 的查询无法下推，这样不仅耗时长，而且还会生产大量中间结果，内存波动较大；上线该功能后，不仅有利于内存控制， …","date":1637046000,"description":"Prometheus on CeresDB 演进之路","dir":"blog/prometheus-on-ceresdb-evolutionary-path/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c56a0b61329eb6462295f7bfb16ee6b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","publishdate":"2021-11-16T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","summary":"文｜刘家财（花名：尘香 ) 蚂蚁集团高级开发工程师 专注时序存储领域 校对｜冯家纯 本文 7035 字 阅读 10 分钟 CeresDB 在早期设计时的目标之一就是对接开源协议，目前系","tags":["SOFAStack"],"title":"Prometheus on CeresDB 演进之路","type":"blog","url":"/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","wordcount":4807},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@zjw 提问：\n 请教个 SOFARegistry 的问题，sessionServer 启动后，地址是上报给 Meta 的吗？如果 sessionServer 意外关闭，地址是什么时候怎么摘除的？\n A：session 会定时向 Meta 发送请求对自己的地址进行心跳续约，session 宕机后，Meta 端一段时间接收不到心跳就会摘除宕机的 session，然后广播给所有其他的 session。目前是靠心跳，超时之后 Meta 会把 session 或者 data 剔除。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@滕川 提问：\n 如果 leader 节点挂了，新选举的 leader 节点如何知道各个 follower 节点的 match index。\n A：leader 不需要知道，leader 节点就直接发 appendEtries 即可。如果哪个 follower 还缺更之前的 log，那么它拒绝掉这次 appendEntries 就可以了， leader 会有相应的回退处理逻辑。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@橙橙不是澄澄 提问：\n Raft 里面为什么不要 observer 呢？恰好之前看到 ZooKeeper 里面有这个角色。\n A：Raft 里面可以有类似的角色，叫 learner。learner 不参与选举，只接收 leader 日志，JRaft 也支持 learner。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@邓君武 提问：\n SOFAJRaft 文档中说支持 MULTI-RAFT-GROUP，目前 SOFAJRaft-RheaKV 这个存储组件中用到了。那么如果我想根据 SOFAJRaft 实现一个分布式的业务系统，MULTI-RAFT-GROUP 该怎么用呢？\n A：MULTI-RAFT-GROUP 主要用于解决 SIGLE-RAFT-GROUP 单点瓶颈问题（存储或是吞吐），多个 group 中每个 group 都有一个 leader，可以把 leader 打散到不同的机器上，提高并发度。JRaft 天然支持 MULTI-RAFT-GROUP ，使用的话可以参考 RheaKV。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 在服务引用和发布时，使用枚举值替代字符串硬编码\n优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n升级由 Rust 开发的 Wasm demo\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n 蚂蚁集团技术风险代码化平台实践（MaaS）\n ","date":1636700400,"description":"SOFA WEEKLY | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211112/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"801d338b492a06363ed6a129c2da9774","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211112/","publishdate":"2021-11-12T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211112/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211112/","wordcount":1544},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft\n 活动时间：11月10日,周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft SOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 冯家纯 蚂蚁集团高级技术专家。 蚂蚁集团-智能监控-技术中台（存储）团队技术负责人，团队负责时序数据库相关。 分布式服务框架 Jupiter 作者。 基于 Raft 的分布式共识算法库 SOFAJRaft 开源负责人、核心开发者。 议程 18:50-19:00 主持人开场 小助手-泡椒 主持人\n19:00-19:30 分布式共识：Raft 与 SOFAJRaft 冯家纯，蚂蚁集团高级技术专家\n你将收获 对 Raft 共识算法有所了解，还可以了解到 SOFAJRaft 基于 Raft 算法做了哪些优化，以及实现 Raft 算法的一些好的实践经验。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1636527600,"description":"11 月 10 日周三晚 19 点，线上直播第 22 期。","dir":"activities/sofa-channel-22/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"896e421f2df319f46ec573a77343446c","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-22/","publishdate":"2021-11-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-22/","summary":"概要 活动主题：SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft 活动时间：11月10日,周三晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站","tags":["SOFAChannel","HTTP/3"],"title":"SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft","type":"activities","url":"/sofastack.tech/activities/sofa-channel-22/","wordcount":643},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@玄灭 提问：\n 大佬，关于 downStream 和 upStream，你看看我这个理解对不对哈？一个 MOSN 进程，既会代理当前 pod 的业务进程流量请求，此时 downStream 是当前 pod 进程；同时，这个 MOSN 进程也会代理其他 pod 请求当前 pod 的流量，此时当前 pod 就不能成为 downStream；也就是说，角色会互换。从另一个角度，从 server 端口进来的，都是 downStream，使用 client 向外其他进程发送数据，都是 upStream。 A：一般来说，downStream 就是 server listen 请求，upStream 是 client，发送请求。你说的第一种，一般用 Ingress、Egress 来区分。\n 在 MOSN 里，downStream 永远是 side 进程吗？\n A：MOSN 里面，downStream 就是 server 端，接收请求的。\n MOSN 两个端口的话，server 端可能是 side 进程，也可能是其他 MOSN 进程。所以 downStream 可以是 side 进程的请求，也可以是其他 MOSN 进程的请求。\n A：站在 MOSN 角度，给我发请求的就是 downStream。\n「MOSN」：https://github.com/mosn/mosn\n@zzzZ 提问：\n 怎么将实现的 Eventhandler 注册进容器中，监听容器启动和停止事件？\n A：这里有具体讲解，https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/\n 事件能传播吗？比如 master 传播给子模块内。 A：容器级别的会传播。\n 「SOFABoot」：https://github.com/sofastack/sofa-boot\n@苏千 提问：\n 如何让 Layotto 打印日志，将 metadata 打印出来，我传递了没有生效，想看看是否传递错误。\n A：Layotto 现在默认 log 就是打印的，但没打印 metadata 里面的值，现在 oss 的实现就没传 prefix，所以不生效吧。\n可以试一下这个方法，如果这样的话，你 SDK 测需要适配一下。https://github.com/mosn/layotto/issues/98#issuecomment-957479097\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n升级由 Rust 开发的 Wasm demo\n Hard 集成 Skywalking、Jaeger 等系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 如何在生产环境排查 Rust 内存占用过高问题\n 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1636095600,"description":"SOFA Weekly |Layotto 本周 Contributor、QA 整理、新手任务","dir":"blog/sofa-weekly-20211105/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f2607e9479571a83a8453798866de8f9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211105/","publishdate":"2021-11-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211105/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly |Layotto 本周 Contributor、QA 整理、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211105/","wordcount":1382},{"author":"魏熙凯","categories":"SOFAStack","content":" 📄\n文｜魏熙凯（蚂蚁集团技术专家）\n本文 6320 字 阅读 10 分钟\n▼\n内存安全的 Rust，虽然基本不会出现内存泄漏，但如何合理分配内存，是每个复杂应用都要面临的问题。往往随着业务的不同，相同的代码可能会产生不同的内存占用。因此，有不小的概率会出现内存使用过多、内存逐渐增长不释放的问题。\n本文我想分享一下，我们在实践过程中遇到的关于内存占用过高的问题。对于这些内存问题，在本文中会做出简单的分类，以及提供我们在生产环境下进行排查定位的方法给大家参考。\n 本文最先发表于 RustMagazine 中文月刊\n(https://rustmagazine.github.io/rust_magazine_2021/chapter_5/rust-memory-troubleshootting.html）\n 内存分配器 首先在生产环境中，我们往往不会选择默认的内存分配器（malloc），而是会选择 jemalloc，可以提供更好的多核性能以及更好的避免内存碎片（详细原因可以参考[1]）。Rust 的生态中，对于 jemalloc 的封装有很多优秀的库，这里我们就不纠结于哪一个库更好，我们更关心如何使用 jemalloc 提供的分析能力，帮助我们诊断内存问题。\n阅读 jemalloc 的使用文档，可以知道其提供了基于采样方式的内存 profile 能力，而且可以通过 mallctl 可以设置 prof.active 和 prof.dump 这两个选项，来达到动态控制内存 profile 的开关和输出内存 profile 信息的效果。\n内存快速增长直至 oom 这样的情况一般是相同的代码在面对不同的业务场景时会出现，因为某种特定的输入（往往是大量的数据）引起程序的内存快速增长。\n不过有了上面提到的 memory profiling 功能，快速的内存增长其实一个非常容易解决的情况，为我们可以在快速增长的过程中打开 profile 开关，一段时间后，输出 profile 结果，通过相应的工具进行可视化，就可以清楚地了解到哪些函数被调用，进行了哪些结构的内存分配。\n不过这里分为两种情况：可以复现以及难以复现，对于两种情况的处理手段是不一样的，下面对于这两种情况分别给出可操作的方案。\n**可以复现\n可以复现的场景其实是最容易的解决的问题，因为我们可以在复现期间采用动态打开 profile，在短时间内的获得大量的内存分配信息即可。\n下面给出一个完整的 demo，展示一下在 Rust 应用中如何进行动态的内存 profile。\n本文章，我会采用jemalloc-sys jemallocator jemalloc-ctl 这三个 Rust 库来进行内存的 profile，这三个库的功能主要是：\n```jemallocator```: 实现了 Rust 的 ```GlobalAlloc```，用来替换默认的内存分配器。 ```jemalloc-ctl```: 提供了对于 mallctl 的封装，可以用来进行 tuning、动态配置分配器的配置、以及获取分配器的统计信息等。 下面是 demo 工程的依赖： ``` java [dependencies] jemallocator = \u0026amp;quot;0.3.2\u0026amp;quot; jemalloc-ctl = \u0026amp;quot;0.3.2\u0026amp;quot; [dependencies.jemalloc-sys] version = \u0026amp;quot;0.3.2\u0026amp;quot; features = [\u0026amp;quot;stats\u0026amp;quot;, \u0026amp;quot;profiling\u0026amp;quot;, \u0026amp;quot;unprefixed_malloc_on_supported_platforms\u0026amp;quot;] [profile.release] debug = true 其中比较关键的是jemalloc-sys 的几个 features 需要打开，否则后续的 profile 会遇到失败的情况，另外需要强调的是 demo 的运行环境是在 Linux 环境下运行的。\n然后 demo 的 src/main.rs 的代码如下：\nuse jemallocator; use jemalloc_ctl::{AsName, Access}; use std::collections::HashMap; #[global_allocator] static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc; const PROF_ACTIVE: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;prof.active\\0\u0026amp;quot;; const PROF_DUMP: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;prof.dump\\0\u0026amp;quot;; const PROFILE_OUTPUT: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;profile.out\\0\u0026amp;quot;; fn set_prof_active(active: bool) { let name = PROF_ACTIVE.name(); name.write(active).expect(\u0026amp;quot;Should succeed to set prof\u0026amp;quot;); } fn dump_profile() { let name = PROF_DUMP.name(); name.write(PROFILE_OUTPUT).expect(\u0026amp;quot;Should succeed to dump profile\u0026amp;quot;) } fn main() { set_prof_active(true); let mut buffers: Vec\u0026amp;lt;HashMap\u0026amp;lt;i32, i32\u0026amp;gt;\u0026amp;gt; = Vec::new(); for _ in 0..100 { buffers.push(HashMap::with_capacity(1024)); } set_prof_active(false); dump_profile(); } demo 已经是非常简化的测试用例了，主要做如下的说明：\n编译完成之后，直接运行程序是不行的，需要设置好环境变量（开启内存 profile 功能）： export MALLOC_CONF=prof:true 然后再运行程序，就会输出一份 memory profile 文件，demo 中文件名字已经写死 —— ```profile.out```，这个是一份文本文件，不利于直接观察（没有直观的 symbol）。 通过 jeprof 等工具，可以直接将其转化成可视化的图形： ```jeprof --show_bytes --pdf \u0026amp;lt;path_to_binary\u0026amp;gt; ./profile.out \u0026amp;gt; ./profile.pdf``` 这样就可以将其可视化，从下图中，我们可以清晰地看到所有的内存来源： …","date":1635836400,"description":"如何在生产环境排查 Rust 内存占用过高问题","dir":"blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a2811b69df2016f531d4d42a431a7683","permalink":"https://sofastack.github.io/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","publishdate":"2021-11-02T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","summary":"📄 文｜魏熙凯（蚂蚁集团技术专家） 本文 6320 字 阅读 10 分钟 ▼ 内存安全的 Rust，虽然基本不会出现内存泄漏，但如何合理分配内存，是每个复杂应用都要面临","tags":["SOFAStack"],"title":"如何在生产环境排查 Rust 内存占用过高问题","type":"blog","url":"/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","wordcount":3930},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@崔伟协 提问：\n PingPong 是类似 HTTP 的 req/resp 吗? Multiplex 是类似 HTTP2.0 的没有队头阻塞吗？ A：是的。\n 自己实现的 xprotocol 自定义子协议，要怎么配置 downstream 是 PingPong 还是 Multiplex 呢，PoolMode() api.PoolMode 这个方法似乎只影响 upstream 的 conn pool?\n A：downstream 不用感知，这个访问你的 client 就决定他的行为。\n「MOSN」：https://github.com/mosn/mosn\n2.@玄灭 提问：\n 请教下 MOSN 可以同时支持多个协议吗？比如同时支持 HTTP1.1、rocketmq 协议。\n A：可以的，一个端口都可以。协议可以做自动识别，协议配置就可以配置 Auto。\n「MOSN」：https://github.com/mosn/mosn\n3.@玄灭 提问：\n 业务层的 SDK 用的什么协议呢？比如 mq 用的是私有协议，还是和 RPC 统一是一个协议啊？\n A：我们两种模式，一种是私有协议，一种是统一协议都有再用，统一协议是用 Layotto 支持的。\n 你们的大方向是统一协议，还是私有协议啊？我理解的私有协议对于上游改造成本，会比较小吧；统一协议的话，成本比较大。\n A：私有协议你认为是 Mesh 了，现有业务的支持；统一协议就是类似 Dapr 这种，新业务使用不同场景。\n「MOSN」：https://github.com/mosn/mosn\n4.@晓辰 提问：\n 请问一下 MOSN 有支持 windows 的计划吗？\n A：Go 语言跨平台应该支持的，你提个 pr 看看，是不是有些 Linux 需要跳过？\n「MOSN」：https://github.com/mosn/mosn\n5.@王磊 提问：\n MOSN 目前支持的 Istio 版本是 1.5.2 吗？更高的 Istio 版本支持有计划吗？\n A：这个分支，近期会合到 Master。\nhttps://github.com/mosn/mosn/tree/istio-1.10\n「MOSN」：https://github.com/mosn/mosn\n6.@孙力 提问：\n MOSN 有剔除上游故障节点的功能吗? 比如上游服务有 5 台服务器，访问其中一台总报错，下次就不选这台了。\n https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ffaulttolerance\n 这个 stream_filter 应该是只要上游 host 返回的状态码代表异常就会统计，达到一定比例就会 healthFlag 置为 false。但我们其实想做接口 + host 的，比如访问上游的某个 HTTP 接口总失败，只是针对下次访问这个接口时，才剔除节点，这样是不是需要自己定制一下 InvocationKey ？\n A：还是有区别的，这个是把 host 置为失败了，是全局的，其他接口也会失败。删除了之后，其他访问这个接口请求也不会访问这个 host 了。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n用某种存储实现 File API 组件（例如本地文件系统、hdfs、ftp 等）\n升级由 rust 开发的 wasm demo\nSOFARPC 本周发布 本周 SOFARPC 发布 v5.8.0 版本代码。\n主要更新如下：\n RpcInvokeContext 中增加调用时精细化耗时埋点信息\n Java 集合的使用优化\n 修复 RouterChain 加入不存在的 Router 时 NPE 问题\n 增加泛型修复配置类中类型传递问题\n bolt 版本从 1.5.6 升级到 1.5.9\n hessian 版本从 3.3.7 升级到 3.3.13\n nacos 版本从 1.0.0 升级到 2.0.3\n httpclient 版本从 4.5.11 升级到 4.5.13\n commons-io 版本从 2.4 升级到 2.7\n 「详细参考」：https://github.com/sofastack/sofa-rpc/releases/tag/v5.8.0\n本周推荐阅读 蚂蚁集团技术风险代码化平台实践（MaaS）\n 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1635490800,"description":"SOFA WEEKLY |Layotto 本周 Contributor、QA 整理、 SOFARPC 本周发布","dir":"blog/sofa-weekly-20211029/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dc10182aab6b4170339c958ac73dd2bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211029/","publishdate":"2021-10-29T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211029/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、 SOFARPC 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211029/","wordcount":1667},{"author":"黄章衡","categories":"SOFAStack","content":" 📄\n文｜黄章衡（SOFAJRaft 项目组）\n福州大学 19 级计算机系\n研究方向｜分布式中间件、分布式数据库\nGithub 主页｜https://github.com/hzh0425\n校对｜冯家纯（SOFAJRaft 开源社区负责人）\n本文 9402 字 阅读 18 分钟\n▼\nPART. 1 项目介绍 1.1 SOFAJRaft 介绍 SOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\nGithub 地址：\nhttps://github.com/sofastack/sofa-jraft\n1.2 任务要求 目标：当前 LogStorage 的实现，采用 index 与 data 分离的设计，我们将 key 和 value 的 offset 作为索引写入 rocksdb，同时日志条目（data）写入 Segment Log。因为使用 SOFAJRaft 的用户经常也使用了不同版本的 rocksdb，这就要求用户不得不更换自己的 rocksdb 版本来适应 SOFAJRaft， 所以我们希望做一个改进：移除对 rocksdb 的依赖，构建出一个纯 Java 实现的索引模块。\nPART. 2 前置知识 Log Structured File Systems\n如果学习过类似 Kafka 等消息队列的同学，对日志型系统应该并不陌生。\n如图所示，我们可以在单机磁盘上存储一些日志型文件，这些文件中一般包含了旧文件和新文件的集合。区别在于 Active Data File 一般是映射到内存中的并且正在写入的新文件(基于 mmap 内存映射技术)，而 Older Data File 是已经写完了，并且都 Flush 到磁盘上的旧文件，当一块 Active File 写完之后，就会将其关闭，并打开一个新的 Active File 继续写。\n并且每一次的写入，每个 Log Entry 都会被 Append 到 Active File 的尾部，而 Active File 往往会用 mmap 内存映射技术，将文件映射到 os Page Cache 里，因此每一次的写入都是内存顺序写，性能非常高。\n终上所述，一块 File 无非就是一些 Log Entry 的集合，如图所示:\n同时，仅仅将日志写入到 File 中还不够，因为当需要搜索日志的时候，我们不可能顺序遍历每一块文件去搜索，这样性能就太差了。所以我们还需要构建这些文件的 “目录”，也即索引文件。这里的索引本质上也是一些文件的集合，其存储的索引项一般是固定大小的，并提供了 LogEntry 的元信息，如:\n- File_Id : 其对应的 LogEntry 存储在哪一块 File 中\n- Value_sz : LogEntry 的数据大小\n(注: LogEntry 是被序列化后, 以二进制的方式存储的)\n- Value_pos: 存储在对应 File 中的哪个位置开始\n- 其他的可能还有 crc，时间戳等\u0026amp;hellip;\u0026amp;hellip;\n那么依据索引文件的特性，就能够非常方便的查找 IndexEntry。\n- 日志项 IndexEntry 是固定大小的\n- IndexEntry 存储了 LogEntry 的元信息\n- IndexEntry 具有单调递增的特性\n举例，如果要查找 LogIndex = 4 的日志:\n- 第一步，根据 LogIndex = 4，可以知道索引存储的位置：IndexPos = IndexEntrySize * 4\n- 第二步，根据 IndexPos，去索引文件中，取出对应的索引项 IndexEntry\n- 第三步，根据 IndexEntry 中的元信息，如 File_Id、Pos 等，到对应的 Data File 中搜索\n- 第四步，找到对应的 LogEntry\n内存映射技术 mmap\n上文一直提到了一个技术：将文件映射到内存中，在内存中写 Active 文件，这也是日志型系统的一个关键技术，在 Unix/Linux 系统下读写文件，一般有两种方式。\n传统文件 IO 模型\n一种标准的 IO 流程, 是 Open 一个文件，然后使用 Read 系统调用读取文件的一部分或全部。这个 Read 过程是这样的：内核将文件中的数据从磁盘区域读取到内核页高速缓冲区，再从内核的高速缓冲区读取到用户进程的地址空间。这里就涉及到了数据的两次拷贝：磁盘-\u0026amp;gt;内核，内核-\u0026amp;gt;用户态。\n而且当存在多个进程同时读取同一个文件时，每一个进程中的地址空间都会保存一份副本，这样肯定不是最优方式的，造成了物理内存的浪费，看下图：\n内存映射技术\n第二种方式就是使用内存映射的方式\n具体操作方式是：Open 一个文件，然后调用 mmap 系统调用，将文件内容的全部或一部分直接映射到进程的地址空间(直接将用户进程私有地址空间中的一块区域与文件对象建立映射关系)，映射完成后，进程可以像访问普通内存一样做其他的操作，比如 memcpy 等等。mmap 并不会预先分配物理地址空间，它只是占有进程的虚拟地址空间。\n当第一个进程访问内核中的缓冲区时，因为并没有实际拷贝数据，这时 MMU 在地址映射表中是无法找到与地址空间相对应的物理地址的，也就是 MMU 失败，就会触发缺页中断。内核将文件的这一页数据读入到内核高速缓冲区中，并更新进程的页表，使页表指向内核缓冲中 Page Cache 的这一页。之后有其他的进程再次访问这一页的时候，该页已经在内存中了，内核只需要将进程的页表登记并且指向内核的页高速缓冲区即可，如下图所示：\n对于容量较大的文件来说（文件大小一般需要限制在 1.5~2G 以下），采用 mmap 的方式其读/写的效率和性能都非常高。\n当然，需要如果采用了 mmap 内存映射，此时调用 Write 并不是写入磁盘，而是写入 Page Cache 里。因此，如果想让写入的数据保存到硬盘上，我们还需要考虑在什么时间点 Flush 最合适(后文会讲述)。\nPART. 3 架构设计 3.1 SOFAJRaft 原有日志系统架构 下图是 SOFAJRaft 原有日志系统整体上的设计：\n其中 LogManager 提供了和日志相关的接口，如:\n/** * Append log entry vector and wait until it\u0026#39;s stable (NOT COMMITTED!) * * @param entries log entries * @param done callback */ void appendEntries(final Listentries, StableClosure done); /** * Get the log entry at index. * * @param index the index of log entry * @return the …","date":1635231600,"description":"新一代日志型系统在 SOFAJRaft 中的应用","dir":"blog/a-new-generation-of-log-based-systems-in-sofajraft/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0d3a13e7ed41a72bee7fe7973424e4e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","publishdate":"2021-10-26T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","summary":"📄 文｜黄章衡（SOFAJRaft 项目组） 福州大学 19 级计算机系 研究方向｜分布式中间件、分布式数据库 Github 主页｜https://github.com","tags":["SOFAStack"],"title":"新一代日志型系统在 SOFAJRaft 中的应用","type":"blog","url":"/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","wordcount":5282},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）\n 活动时间：2021 年 10 月 23 日（周六）13:30-17:30\n 活动地点：上海市浦东新区南泉北路 447 号蚂蚁 S 空间 1210 明月台\n 活动形式：线下活动\n 资料下载： 《攀登规模化的高峰蚂蚁集团大规模 Sigma 集 ApiServer 优化实践》\n 活动回顾 《攀登规模化的高峰蚂蚁集团大规模 Sigma 集 ApiServer 优化实践》\n嘉宾介绍\n唐博：蚂蚁集团技术专家，目前主要致力于 Kubernetes 性能和规模化方向，在资源编排调度，以及机器学习平台等领域有所涉猎，是 Kubernetes/istio/volcano 等云原生相关项目的代码贡献者。\n谭崇康：蚂蚁集团高级技术专家，负责大规模 K8s 集群设计、集群性能及 Pod 交付成功率及吞吐保障。长期从事云平台领域的新架构研发工作，研究兴趣包括 Kubernetes 领域的最新技术、操作系统、大数据、AIOps 等。\n议题简介\n 蚂蚁集团运行着全球最大的 Kubernetes（内部称为 Sigma） 集群之一，本次分享将介绍蚂蚁集团构建万级节点的大规模 Kubernetes 集群以及优化 Kubernetes apiserver 的过程当中的挑战和解决方案. 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1634972400,"description":"【活动回顾】SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）","dir":"activities/sofa-meetup-12/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"590a0e1f5b8a6a4035844058f4361490","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-12/","publishdate":"2021-10-23T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-12/","summary":"概要 活动主题：SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day） 活动时间：2021 年 10 月 23 日（周六）13:30-17:30 活","tags":["SOFAMeetup"],"title":"【活动回顾】SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-12/","wordcount":479},{"author":"赵陈","categories":"SOFAStack","content":" 📄\n文｜赵陈（SOFA 开源之夏链路项目组)\n武汉理工大学计算机工程硕士在读\n研究方向：唐卡线稿的自动上色\n校对｜宋国磊（SOFATracer commiter)\n本文 6971 字 阅读 18 分钟\n▼\n背 景 有幸参与开源软件供应链点亮计划——暑期 2021 支持的开源项目，目前 SOFATracer 已经能够将埋点数据上报到 Zipkin 中，本项目的主要目标是将产生的埋点数据上报给 Jaeger 和 SkyWalking 中进行可视化展示。\nPART. 1 SOFATracer SOFATracer 是蚂蚁集团基于 OpenTracing 规范开发的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer 提供了异步落地磁盘的日志打印能力和将链路跟踪数据上报到开源产品 Zipkin 做分布式链路跟踪展示的能力。这次参加开源之夏活动的任务是要把链路跟踪数据上报到 Jaeger 和 SkyWalking 中进行展示。\nSOFATracer 数据上报 上图是 SOFATracer 中的链路上报流程，Span#finish 是 span 生命周期的最后一个执行方法，这是整个数据上报的入口，SOFATracer 的 report span 方法中含有上报链路展示端和日志落盘两个部分。SOFATracer 中没有把上报数据采集器和日志落盘分开只是在日志落盘之前调用 SOFATracer#invokeReporListeners 方法，找到系统中所有实现了 SpanReportListener 接口并加入了 SpanReportListenersHolder 的实例，调用其 onSpanReport 方法完成链路数据上报至数据采集器。下面的代码片段是 invokeReportListeners 方法的具体实现。\nprotected void invokeReportListeners(SofaTracerSpan sofaTracerSpan) { List\u0026amp;lt;SpanReportListener\u0026amp;gt; listeners = SpanReportListenerHolder .getSpanReportListenersHolder(); if (listeners != null \u0026amp;amp;\u0026amp;amp; listeners.size() \u0026amp;gt; 0) { for (SpanReportListener listener : listeners) { listener.onSpanReport(sofaTracerSpan); } } } SpanReportListenerHolder 中的实例在项目启动的时候加入，且分为 Spring Boot 应用和 Spring 应用两种情况：\n 在 Spring Boot 应用中自动配置类 SOFATracerSpanRemoteReporter 会将当前所有 SpanReportListener 类型的 bean 实例保存到 SpanReportListenerHolder 的 List 对象中。SpanReportListener 的实例对象会在各自的 AutoConfiguration 自动配置类中注入到 IOC 容器中。\n 在 Spring 应用中通过实现 Spring 提供的 bean 生命周期接口 InitializingBean，在 afterPropertiesSet 方法中实例化 SpanReportListener 的实例对象并且加入到 SpanReportListenerHolder 中。\n 要实现把 SOFATracer 中的 trace 数据上传到 Jaeger 和 SkyWalking 需要实现 SpanReportListener 接口并在应用启动的时候把对应实例加入到 SpanReportListenersHolder 中。\nPART. 2 Jaeger 数据上报 下图是 Jaeger 中数据上报的部分图示，图中 CommandQueue 中存放的是刷新或添加指令，生产者是采样器和 flush 定时器，消费者是队列处理器。采样器判断一个 span 需要上报后向 CommandQueue 中添加一个 AppendCommand，flush 定时器根据设置的 flushInterval 不断向队列中添加 FlushCommand，队列处理器不断从 CommandQueue 中读取指令判断是 AppendCommand 还是 FlushCommand，如果刷新指令把当前 byteBuffer 中的数据发送到接受端，如果是添加指令把这个 span 添加到 byteBuffer 中暂存。\n在实现上报到 Jaeger 过程中主要工作是 Jaeger Span 和 SOFATracer Span 模型的转换，转换过后利用上面的逻辑发送 span 到后端。\n上图是 Jaeger 中 Sender 的 UML 图，从图中可以看到有两种类型的 Sender 分别是 HTTPSender 和 UDPSender 。分别对应用 HTTP 发送数据和 UDP 发送数据，在实现 SOFATracer 上报 Jaeger 中使用 UDPSender 发送 span 数据到 Jaeger Agent 中，使用 HTTPSender 直接发送数据到 Jaeger-Collector 中。\nJaeger Span 与 SOFATracer Span 模型的转换 模型转换对照 TraceId 和 SpanId 的处理 TraceId 的转换：\n 问题在 SOFATracer 中的 TracerId 的产生规则是：服务器 IP + ID 产生的时间 + 自增序列 + 当前进程号 例如 ：0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，您也可以根据这个规律来查找到请求经过的第一个服务器。后面的 13 位 1403169275002 是产生 TraceId 的时间。之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。——TraceId 和 SpanId 生成规则\n 在 SOFATracer 中 TraceId 是 String 类型，但是在 Jaeger 中 TraceId 是使用的两个 Long 型的整数来构成最终的 TraceId。\n解决方案 在 Jaeger …","date":1634626800,"description":"终于！SOFATracer 完成了它的链路可视化之旅","dir":"blog/sofatracer-completes-its-link-visualisation-journey/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"260c9a0bc64d5f84afc37ee442e347c6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","publishdate":"2021-10-19T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","summary":"📄 文｜赵陈（SOFA 开源之夏链路项目组) 武汉理工大学计算机工程硕士在读 研究方向：唐卡线稿的自动上色 校对｜宋国磊（SOFATracer commiter) 本文 6971","tags":["SOFAStack"],"title":"终于！SOFATracer 完成了它的链路可视化之旅","type":"blog","url":"/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","wordcount":4273},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@崔伟协 提问：\n 我们的项目基于 MOSN，请问这里 panic了，要怎么解决？\n https://github.com/mosn/mosn/blob/master/pkg/proxy/downstream.go#L393-L399\nA：有异常的时候可以直接返回一个异常的数据包，m.receiveHandler.SendHijackReply(api.SuccessCode, m.headers) 在 filter 里面可以直接返回一个包。\n「MOSN」：https://github.com/mosn/mosn\n@玄灭 提问：\n 请问 MOSN 有计划支持 eureka 注册中心吗？\n A：目前没有，欢迎 pr，有个 zk 的例子，实现起来也简单。\nhttps://www.github.com/mosn/mosn/tree/master/pkg%2Fupstream%2Fservicediscovery%2Fdubbod\n「MOSN」：https://github.com/mosn/mosn\n@张昊 提问：\n 仓库中 /jarslink-samples/spring-boot-transform-sample 对照文档启动后，telnet 中 install -b *ark-biz.jar，控制台报错，大家有遇到类似问题嘛？\n A：这个项目不维护了，相关功能已经 merge 到 SOFAArk 里面去了，以后建议直接用 SOFAArk。\nSOFAArk 有相关的适应样例：https://github.com/sofastack-guides\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n@春少 提问：\n 这一段逻辑，是为了避免在执行 add peer 的时候，出现 raft 选举的情况吗？ A：是的，所以这个时候就交给新的 leader 负责继续推进新的成员节点变更。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN : 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n-Easy\n为 Layotto 中的关键模块添加注释（例如限流/分布式锁等模块）\n添加 nodejs sdk\n-Medium\n用某种存储实现 File API 组件（例如本地文件系统、hdfs、ftp 等）\n升级由 rust 开发的 wasm demo\n升级由 AssemblyScript 开发的 wasm demo\n详见： https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n另外最近更新了社区晋升规则，大家贡献 pr 后只要满足条件即可晋升，成为社区的维护者之一。\n详见： https://mosn.io/layotto/#/zh/community/promote\n本周推荐阅读 蚂蚁集团技术风险代码化平台实践（MaaS）\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1634281200,"description":"SOFA Weekly | QA 整理、SOFAStack\u0026MOSN 新手任务","dir":"blog/sofa-weekly-20211015/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"498a7a535dc938be0783eab5c808d792","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211015/","publishdate":"2021-10-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211015/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly | QA 整理、SOFAStack\u0026MOSN 新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211015/","wordcount":1130},{"author":"吴成辉","categories":"SOFAStack","content":" 📄\n文｜吴成辉（花名：清霄 蚂蚁集团高级技术专家)\n校对｜陈真、庄晓丹、冯家纯\n本文 6250 字 阅读 11 分钟\n▼\n我们一起回顾下监控上层业务曾经面临的问题：\n 烟囱式的监控分析重复建设 在技术风险领域，一度有超过 5 个系统在做监控分析的能力建设，大致逻辑基本都是拉监控的 Raw Data，做基础的聚合、分析处理后（类似同环比、阈值类的方式），根据一些当前的场景输入，结合一些算法能力，得出一个结论并触发一系列的 Action。类似这种烟囱式的监控分析场景，都是比较初级的重复建设，缺乏智能化、体系化。\n SRE 经验标准化沉淀的问题 在分析场景里也面临 SRE 经验无法标准化沉淀复用的问题，什么是 SRE 经验？拿交易付款下跌来举例，如果当前交易付款下跌 10%，SRE 通常有这么几个分析路径，首先看下淘宝交易是否下跌（来源），再看交易创建，收银台渲染是不是下跌等，这一类我们称为业务依赖。从全局看是否有大规模的压测、变更等动作，这一类称为变更关联，以及如何根据当前故障情况决策进行切流、限流等恢复措施，我们称为分析后置操作。\n 长尾需求 比如比较常见的，算多数据之间的成功率，流量损耗等等需求，通过产品化解决的成本非常高，而且用户不能快速修改、定制相关能力。\n同时我们看到当前监控系统自身面临的问题：\n 监控的数据使用复杂 包含了几万张数据表、十几万张自定义数据表，数据类型超过 20+，以及跨站点、数据源异构等等问题。\n 监控服务不够开放 如何动态日志清洗计算、如何做分析后的时序存储、监控的时序检测能力如何复用等等。我们需要把监控的数据、能力完全服务化出来。\n 高效的可编程代码化平台缺失 没有一个高效平台帮助 SRE 先沉淀经验、再促进经验的标准化、复用，最后产品化。\n基于上面问题，我们提出了 MaaS 的设想（Monitoring as a Service), 监控能力服务化，开放、融合监控能力到技术风险各个领域，快速完成 SRE 场景建设，沉淀可复用能力，主要包含以下 4 个阶段目标：\n1.开放服务把监控的计算、存储、算法、视图等等能力开放出来。\n2.核心共建几个重点的技术风险领域场景，比如变更防御、压测引流、无损注入、定位应急等等。\n3.促进服务的标准化沉淀，让更多的场景可以复用、共同建设这部分的能力。\n4.解决“监”与“控”之间的链接问题。\n（我们的这里的 AIOPS 更多指的是\n一系列专家经验的集合、沉淀、持续维护优化）\nPART. 1 平台技术概览 能力服务化\n监控的服务化能力整体包含这么几部分，数据服务化、配置服务化、计算、存储服务化、算法服务化、通知、云原生服务化等等，也包括一些外部能力集成比如消息缓存等等。\n我简单举两个服务化的例子来介绍下什么是服务化：\n比如视图服务，当某个变更发起后，这个变更关联的 100 个应用指标、20 个业务指标中的 10 个指标出现了问题，这个时候，我们需要动态为这个 10 个指标创建一个数据视图，来分析业务影响范围，这个时候就会用到我们的视图服务。\n动态计算服务，比如我需要实时计算下某个应用在 A 机房（或某个 ZONE 如：GZXXX）的其中 5 台机器在 11:00~12:00 的接口方法调用情况，动态的计算服务就会派得上用场。\n数据服务化\n能力服务化中非常重要的一环就是数据服务化，因为数据是所有监控分析的基础，数据服务化主要分成两部分。\n 第一步是监控数据模型化 我们从数据的使用视角把数据抽象出数据虚拟表、虚拟表列定义、列关系。以及虚拟表的实现绑定，包含指标数据，也包含关系元数据，最后把这些物理实现映射到监控具体的数据指标或者底层的元数据服务上。\n 第二步是服务模板化 我们把一个数据服务抽象出三类：\n实体查询，比如查询一个应用或者一个 Tbase 的集群；\n数据查询，比如查询一个应用的 Sofa Service 在 APP 聚合维度上的数据；\n关系查询，查询一个实体的关联实体，比如 cif 关联的 Tbase 集群等。\n 最后，我们实现了 5w+ 数据服务自动生成，分钟级别 SDK 更新的能力，我们可以通过非常语义化的访问方式来访问监控的所有数据，我们可以做到只要是监控体系内的数据，都可以通过我们这套能力访问到对应的数据服务，从而达到整个监控数据的服务化开放。 研发效能\n 大库管理，我们设计了一种可以支持服务沉淀、权限隔离（可以独立按目录管理 CR）、逻辑复用的代码结构，比如缓存 Tbase 的研发 + SRE 可以共同在 cache 目录里面定义缓存问题的发现、分析、恢复。同时可以复用到 core-service 里面的比如容器是否健康，网络是否异常等标准服务。平台能够提供一致的多环境调试能力，方便监控分析逻辑可以直接运行在本地 IDE 环境中，我们通过动态代理的模式把本地访问的数据、函数服务代理到服务端，从而达到了本地跟线上完全一致的研发体验。这项能力极大地提高了研发效率，研发过程中可以直接 debug 线上数据，比传统的日志模式的调试方式有非常大的效率提升，一个基础的分析函数基本可以在小时级别内完成。\n 一站式发布运维，传统的 Serverless 发布模式大致要经历这么几个阶段，从工程打包到 Jar 文件，耗时 1min，大概在 100-300MB，从 Jar 文件打包 Build 出镜像，大致 10min，最后做镜像化发布整体耗时约 20min, 整体流程大概耗费半个小时。我们研发了一套基于函数粒度的发布运维模式，以 MaaSFunction 为入口，做跨文件 Linker，如何做 Linker，看这个示意图，我们从 MaasFunction 入口开始解析本类依赖的文件，比如这边依赖的其他函数，到下面的 service，再到 util 层的相互依赖，从而通过这种方式解析出业务代码片段，通过动态编译完 Jar 大小目前最大在 500KB 左右，根据代码大小一般在 5s 内，再通过热加载到目标机器上，整体可以做到 5s 级发布，1s 回滚，其他还有配套的日志、监控等等能力。\n 多语言 Runtime\n我们在初期建设的时候函数是都运行在一个集群里面，经常会遇到例如：死循环、OOM、线程频繁创建等等性能问题，因为业务代码不可控，CR 不能完全杜绝这类问题，这样我们就需要完全隔离的函数运行环境，从图中可以看到，每个函数至少具备 2 个独立的容器（容灾的需要），函数 1OOM（Out Of Memory），不会影响到函数 2。这样我们就可以基本做到函数级别的执行层隔离，我们通过 SLO 的度量，平台稳定性有了非常大的提升。\n当我们按照函数级别隔离的模式大规模上线的时候遇到了成本问题，底层 sigma 支持的 pod 调度的最小规模是 0.5c（底层物理网卡等等限制），如果 2 台容灾，基本上一个函数至少占用 1c 的物理资源，随着函数业务的大规模使用，这块成本是很难持续的。通过我们的观察，绝大多数函数占用实际的 CPU10% 不到，甚至更低。我们同 Serverless Paas 团队一起共建了函数的高密度部署模式，通过 0.5c 的 pod 中隔离 5 个 0.1c 的容器，然后通过容器 IP + 端口的方式绑定 …","date":1634022000,"description":"蚂蚁集团技术风险代码化平台实践（MaaS）","dir":"blog/ant-group-technical-risk-coding-platform-in-practice-maas/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"87ede64d8d98af4c1bf7bf4d51ee9cdf","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","publishdate":"2021-10-12T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","summary":"📄 文｜吴成辉（花名：清霄 蚂蚁集团高级技术专家) 校对｜陈真、庄晓丹、冯家纯 本文 6250 字 阅读 11 分钟 ▼ 我们一起回顾下监控上层业务曾经面临的问题： 烟囱式","tags":["SOFAStack"],"title":"蚂蚁集团技术风险代码化平台实践（MaaS）","type":"blog","url":"/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","wordcount":5838},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@风 提问：\n 麻烦问下 SOFA 中的 consumerConfig 的 uniqueId 和 application 分别起什么作用，有什么区别呀？\n A：发布 RPC 服务的时候做配置，uniqueId 是服务的唯一标识，比如你想同一个 service 类发两个服务，就起两个 uniqueId。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@郑楚齐 提问：\n 我在 K8s 上测试将使用 spring-cloud-feign 的服务接入 MOSN Proxy，但是目前 consumer 端一直访问不到 provider，我还在排查问题，想问一下，如果要调用的话，FeignClient 这边是不是需要直接将 URL 指向代理？ A：不是透明劫持的话，就要直接指向 Proxy 的端口。\n「MOSN」：https://github.com/mosn/mosn\n@东仔 提问：\n MOSN 在 Linux 上的 idea 如何启动？\n A：参考下图，\n 「MOSN」：https://github.com/mosn/mosn\n@王逸飞 提问：\n A -\u0026amp;gt; B, A 没有问题，执行到 B 的更新操作时候， Could not found global transaction xid = 192.168.0.112:8091:1893025023560908，会是什么原因产生的？\n A：debug 到 b 的时候看下 TC 的 global table 里面数据存不存在。可能是服务重试或者网络超时造成，自己看下 tm 的决议是什么?\n java.time.LocalDateTime 序列化失败，这样的情况一般如何解决呢? A：改数据库类型，mkyro + datatime 改为时间戳类型，或者等 1.5。\n「Seata」：https://github.com/seata/seata\n本周发布 Layotto 发布了0.2.0 版本，包括以下功能：\n 支持 File API\n 支持 Binding API\n Tracing 和 metrics\n 为已有 API 添加更多组件\n 修复安全问题以及减少 panic 风险\n 不同组件之间保证数据隔离、代码复用\n WASM 模块支持热加载\n go sdk 添加更多 feature\n 一个简单的 Java sdk\n 添加更多文档、修复文档错误\n 添加社区治理和晋升规则\n 详细参考：\nhttps://github.com/mosn/layotto/releases/tag/v0.2.0\n本周推荐阅读 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁智能监控\n ","date":1633676400,"description":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、Layotto 发布新版本","dir":"blog/sofa-weekly-20211008/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b71750e53df5357dc922e1a7d952c265","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211008/","publishdate":"2021-10-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211008/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、Layotto 发布新版本","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211008/","wordcount":1050},{"author":"金敏、邱见","categories":"SOFAStack","content":" 文｜金敏（蚂蚁集团技术专家)\\邱见（Red Hat)\n校对｜ 冯泳（蚂蚁集团资深技术专家)\n本文 3311 字 阅读 6 分钟\n从最初 Kubernetes 技术问世，业界一遍一遍的质疑它能否能经得住生产级的考验，到今天许多大型企业已经采用 Kubernetes 技术“云化”之前大规模的基础设施，在企业内部创建了数十个甚至数百个集群。\nKubernetes 原生的管理能力目前仍然停留在单集群级别。每一个集群可以稳定地自治运行，但是却缺乏横贯多个集群的统筹管理能力。基础设施的建立者需要协调分散在各处的管理组件，形成一个统一的管理平台。\n通过它，运维管理人员能够获知多集群水位的变化，节点健康状态的震荡等信息；业务应用负责人能够决策如何调配应用服务在各个集群中的部署分布；应用的运维人员能够获知服务状态，下发腾挪的策略。\n与多集群相关的创新正在不断涌现。例如 ClusterAPI 和 Submariner 就是处理特定多集群管理问题比较成功的项目。\n而本文要讨论的是那些试图解决企业在面对多集群管理时遇到的所有问题的技术探索。\n在过去五年中，中国的技术公司蚂蚁集团在多集群管理的思考、使用和实施等方面学习到了很多宝贵的经验。\n蚂蚁集团管理着遍布全球的数十个 Kubernetes 集群，每个集群平均拥有数千个节点（服务器）。他们将应用程序及其所需组件（包括中间件，数据库，负载均衡等等）在架构层面组织成逻辑数据中心（LDC）的弹性逻辑单元中，并将它们规划部署到物理基础设施上。这种架构设计帮助他们实现基础设施运维的两个关键目标：高可用性和事务性。\n 首先，部署在某个 LDC 上的业务应用的可用性在所属 LDC 内能够得到保障。\n 其次，部署在 LDC 内的应用组件可以被验证，并在故障发生时，可以被回滚。\n 蚂蚁集团 PaaS 团队的资深技术专家冯泳表示：\n “蚂蚁集团拥有数十个 Kubernetes 集群、数十万个节点和数千个关键应用的基础设施。在这样的云原生基础设施中，每天都会有数以万计的 Pod 被创建和删除。构建一个高度可用、可扩展且安全的平台来管理这些集群和应用程序是一项挑战。”\n PART. 1 始于 KubeFed 在 Kubernetes 项目生态中，多集群功能主要由与之同名的 SIG-Multicluster 团队处理。这个团队在 2017 年开发了一个集群联邦技术叫做 KubeFed。\n联邦最初被认为是 Kubernetes 的一个内置特性，但很快就遇到了实现以及用户诉求分裂的问题，Federation v1 可以将服务分发到多个 Kubernetes 集群，但不能处理其他类型的对象，也不能真正的以任何方式“管理”集群。一些有相当专业需求的用户——尤其是几个学术实验室——仍在使用它，但该项目已被 Kubernetes 归档，从未成为核心功能。\n然后，Federation v1 很快被一种名为“ KubeFed v2 ”的重构设计所取代，世界各地的运营人员都在使用该设计。它允许单个 Kubernetes 集群将多种对象部署到多个其他 Kubernetes 集群。KubeFed v2 还允许“控制平面”主集群管理其他集群，包括它们的大量资源和策略。这是蚂蚁集团多集群管理平台的第一代方案。\n蚂蚁集团使用多集群联邦的首要任务之一是资源弹性，不止包括节点级别弹性也包括站点级别弹性。通过在需要时添加节点和整个集群起到提高效率和扩展系统的能力。例如年度性的资源弹性，每年 11 月 11 日是中国一年一度的光棍节，蚂蚁集团通常需要快速部署大量额外容量来支持高峰在线购物工作负载。然而，可惜的是正如他们发现的那样 KubeFed 添加新集群的速度很慢，而且在管理大量集群方面效率低下。\n在 KubeFed v2 集群中，一个中枢 Kubernetes 集群会充当所有其他集群的单一“控制平面”。蚂蚁集团发现，在管理托管集群和托管集群中应用程序的时候，中枢集群的资源使用率都非常高。\n在管理仅占蚂蚁集团总量 3% 的应用程序工作负载的测试中，他们发现由中等规模的云实例构成的中枢集群就已经饱和了，并且响应时间很差。因此，他们从未在 KubeFed 上运行全部工作负载。\n第二个限制与 Kubernetes 的扩展功能有关，称为自定义资源定义或 CRD。类似蚂蚁集团这样的“高级用户”往往会开发众多的自定义资源来扩充管理能力。为了要在多集群间分发 CRD，KubeFed 要求为每个 CRD 都创建一个“联合 CRD”。这不仅使集群中的对象数量增加了一倍，也为在集群间维护 CRD 版本和 API 版本一致性方面带来了严重的问题，并且会造成应用程序因为不能兼容不同的 DRD 或者 API 版本而无法顺利升级。\nCRD 的这种数量激增也导致了严重的故障排除问题，同时 CRD 的使用定义不规范/字段变更随意等坏习惯会使 KubeFed 控制面的鲁棒性雪上加霜。在本地集群有自定义资源的地方，联邦控制平面上也有一个代表该本地集群资源的图形聚合视图。但是如果本地集群出现问题，很难从联邦控制平面开始知道问题出在哪里。本地集群上的操作日志和资源事件在联邦级别也是不可见的。\nPART. 2 转向 Open Cluster Management Open Cluster Management 项目（OCM）是由 IBM 最初研发，并由红帽在去年开源。OCM 在蚂蚁集团和其他合作伙伴的经验基础上，改进了多集群管理的方法。它将管理开销从中枢集群下放到每个被管理集群上的代理（Agent）上，让它在整个基础设施中分布式自治并维护稳定。这使得 OCM 理论上能管理的集群数量至少比 KubeFed 多一个数量级。到目前为止，用户已经测试了同时管理多达 1000 个集群。\nOCM 还能够利用 Kubernetes 本身的发展来提高自身的能力。例如，那些以 CRD 封装的能力扩展可以使用 OCM 的 WorkAPI（一个正在向 SIG-Multicluster 提议的子项目）在集群之间分发 Kubernetes 对象。WorkAPI 将本地 Kubernetes 资源的子集嵌入其中，作为要部署的对象的定义，并将其留给代理进行部署。此模型更加灵活，并且最大限度地减少了对任何中央控制平面的部署需求。WorkAPI 可以一起定义一个资源的多个版本，支持应用程序的升级路径。同时 WorkAPI 兼顾了中枢集群和被管理集群网络链接故障时的状态保持问题，并可以在重连的情况下保障资源状态的最终一致性。\n最重要的是，OCM 在集群部署中实现了更多的自动化。在 KubeFed 中，集群的纳管是一个“双向握手”的过程，以中枢集群和被管理集群之间“零信任”作为基础，在此过程中涉及许多手动步骤来保障安全性。新平台能够简化这一过程。例如，因为它在 “PULL” 的基础上运行，不再需要多阶段手动证书注册，也不需要任何明文的 KubeConfig 证书的流通，就可以做到让被管理集群获取中枢集群的管理命令。\n尽管注册的流程注重双向的“信任性”，但是在 OCM 中添加新集群只需要很少的操作；工作人员可以简单地在目标 Kubernetes 集群上部署 “Klusterlet” 代理实现自动纳 …","date":1633330800,"description":"下一个 Kubernetes 前沿：多集群管理","dir":"blog/next-kubernetes-frontier-multi-cluster-management/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7120f96fca72cfca3c6fbfd9ab9e3172","permalink":"https://sofastack.github.io/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","publishdate":"2021-10-04T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","summary":"文｜金敏（蚂蚁集团技术专家)\\邱见（Red Hat) 校对｜ 冯泳（蚂蚁集团资深技术专家) 本文 3311 字 阅读 6 分钟 从最初 Kubernetes 技术问世，业界一遍一遍的质疑它能否能","tags":["SOFAStack"],"title":"下一个 Kubernetes 前沿：多集群管理","type":"blog","url":"/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","wordcount":2933},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周新晋 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@郑楚齐 提问：\n 我们在 Istio 环境下，因为 MOSN 是自动 sidecar 注入的，我怎么控制他读取我的配置文件内容呢？而且我看官方的 Istio 案例也是可以通过 virsual service 进行流量控制的，我们这个 config.json 也是可以进行流量控制的，是不是我理解的 config.json 是在 virsualService.yaml 的功能上进行拓展的功能(比如这种 tag 路由是 virsualService 不能控制的)。\n A：Istio 场景下对应的 sidecar 的静态配置是一些通用的模板（如 pilot 地址渲染等）。关于 service 相关的路由及治理控制都是通过 Istio 定义的 CRD 控制：\nhttps://istio.io/latest/docs/reference/config/networking/\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n MOSN 执行的这个 config.json 是如何使用呢？因为目前 Istio 的这个配置 DestinationRule VirsualService 是不满足需求的，或者说 MOSN 收到我们订制的DestinationRule VirsualService，会自动转为 config.json 供给 MOSN 使用呢？\n A：cluster subset 配置目前 Istio 的 Destination Rule 还不支持，不过目前是可以通过 Envoy Filter 来给对应的 cluster 打 patch 实现（比较麻烦点）。\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n 如果是在 Envoy Filter 打 patch 的话，有没有什么例子吗?\n A：这个就是上面说的 cluster subset 配置。目前 Istio 的 Destination Rule 里面还不支持这个（详细见上面的那个讨论 issue），目前唯一的方法就是使用 Envoy Filter 的这个 CRD 打 patch 实现。\n可参考文档：https://istio.io/latest/docs/reference/config/networking/envoy-filter/#EnvoyFilter-ClusterMatch\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n 看了官方的 EnvoyFilter，不过感觉跟我们 MOSN 的 config.json 里面的内容想对照匹配起来确实很难。\n A：你可以用 xds 动态更新或者扩展用我们的 API 更新，不需要直接用这个配置文件。直接调用 MOSN 自己的 API，xds 其实也是 adapt 到这些 API 接口的，如果你们不用 Istio 的话，自己封装可能更简单，主要就 route 和 cluster 两个 API 就行了。\n这是一个用 zk 更新 Dubbo 的例子：\nhttps://github.com/mosn/mosn/blob/38b3b922b59500acc082e0ac9d705e41944c94ee/pkg/upstream/servicediscovery/dubbod/common.go#L99\nMOSN：https://github.com/mosn/mosn\n@孤若 提问：\n 当空回滚时，如果是因为远程方法调用 try 响应超时，怎么解决终止 try 执行？比如 rollback 执行远比 try 阶段快，rollback 结束 try 还在执行。\n A：我之前有参考这个，有提到 TCC 异常控制：\nhttps://www.infoq.cn/article/g33hcc-qosjplkt4e64e\nSeata：https://github.com/seata/seata\n@林祥标 提问：\n Seata 1.3.0 jdk 1.8 使用 jackson 对 localDateTime 进行序列化时报错，有大佬知道怎么解决吗？\n A：如果数据库用 datetime，实体又是 localdatetime，目前我发现只能 spi、替换序列化方式、依赖等等都没用。通过 spi 定义三个序列化方式就行了：LocalDate、LocalDateTime、LocalTime\u0026amp;hellip;反正如果数据库不是时间戳，目前给的适配方式是无用的(个人用下来的结果)。\nSeata：https://github.com/seata/seata\nSOFAStack：新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nEasy\n为 Layotto 中的关键模块添加注释（例如限流/分布式锁等模块）、添加 nodejs sdk。\nMedium\n用某种存储实现 File API 组件（例如本地文件系统、minio、hdfs、ftp 等）。\n「详见」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁智能监控\n 2021 年云原生技术发展现状及未来趋势\n ","date":1633071600,"description":"SOFA Weekly | Layotto 本周新晋 Contributor、QA 整理、新手任务）","dir":"blog/sofa-weekly-20211001/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8a010b34f9a0dbd849f07463c4b6c9b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211001/","publishdate":"2021-10-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211001/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto 本周新晋 Contributor、QA 整理、新手任务）","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211001/","wordcount":1710},{"author":"唐博、谭崇康","categories":"SOFAStack","content":" 文｜唐博（花名：博易 蚂蚁集团技术专家)\n谭崇康（花名：见云 蚂蚁集团高级技术家)\n本文 10316 字 阅读 18 分钟\n▼\n蚂蚁集团运行着全球最大的 Kubernetes（内部称为 Sigma) 集群之一。Kubernetes 社区官方以 5K node 作为 Kubernetes 规模化的事实标准，而蚂蚁集团在 2019 年的时候，就已经维护着单集群规模超过 1W node 的 Kubernetes 集群。\n这不仅仅是单集群节点量级上的差异，更是业务规模的差异，业务多样化和复杂度上的差异。\n一个形象化的比喻就是，如果官方以及跟着官方的 Kubernetes 使用者能想象到的 Kubernetes 的集群规模是泰山，那么蚂蚁集团在官方的解决方案之上已经实现了一个珠穆朗玛峰。\n蚂蚁集团的 Kubernetes 的演进，从 2018 年至今已经走过了 3 年多的岁月，虽然在 2019 年的时候就构建了万台集群的规模，但时至今日，无论是业务形态还是集群的服务器都发生了巨大的变化。\n 首先，当时的集群万台节点，主要还是偏小规格的服务器，而如今都是大机型，虽然机器的数量也是万台，实际管理的 CPU 数量已经成倍增长。\n 其次是当时集群里面几乎全量是 Long running 的在线业务，Pod 的创建频率每天只有几千个，如今我们的集群上几乎跑满了流式计算和离线计算业务等按需分配的 Pod，因此在 Pod 数量上成倍增长，实际管理的 Pod 数量超过了百万。\n 最后，是 Serverless 的业务快速发展，Serverless Pod 的生命周期基本在分钟级甚至是秒级，集群每天的 Pod 创建量也超过了几十万，伴随着大量的 Kubernetes list watch 和 CRUD 请求，集群的 apiserver 承受了数倍于以往的压力。\n 因此在业务 Serverless 的大背景下，我们在蚂蚁启动了大规模 Sigma 集群的性能优化方案，根据业务的增长趋势，我们设定的目标是，构建 1.4W 个节点规模的集群，同时通过技术优化，期望达成在请求延迟上不会因为规模的原因有所下降，能够对齐社区标准，即 create/update/delete 请求的天级别 P99 RT 在 1s 之内。\n可想而知，挑战是非常巨大的。\nPART. 1 大规模集群的挑战 毋庸置疑，大规模集群带来了很多挑战：\n 随着集群规模增大，故障的爆炸半径也将扩大。Sigma 集群承载了蚂蚁集团诸多重要应用，保障集群的稳定和业务的稳定是最基础也是优先级最高的要求。\n 用户大量的 list 操作，包括 list all，list by namespace，list by label 等，均会随着集群的规模增大而开销变大。这些合理或者不合理的 list 请求，将让 apiserver 的内存在短时间内快速增长，出现 OOM 异常，无法对外响应请求。此外，业务方的 list 请求也会因为 apiserver 无法处理请求而不断重试，造成 apiserver 重启后因过载不可恢复服务能力，影响整个集群的可用性。\n 大量 List 请求透过 apiserver 直接访问 etcd 服务，也会让 etcd 实例的内存剧增而出现 OOM 异常。\n 随着业务量的增长，特别是离线任务的增多，create/update/delete 等请求的数量也迅速增加，导致客户端请求 apiserver 的 RT 极速上升，进而使得调度器和一些控制器因为选主请求超时而丢主。\n 业务量增长将加剧 etcd 由于 compact 等操作自身存在的性能问题，而使 etcd 的 P99 RT 暴涨，进而导致 apiserver 无法响应请求。\n 集群中的控制器服务，包括 Kubernetes 社区自带的控制器例如 service controller，cronjob controller 以及业务的 operator 等，自身存在的性能问题都将在大规模集群面前被进一步放大。这些问题将进一步传导到线上业务，导致业务受损。\n 如计算机学科的古老格言所说：\n「 All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection\u0026amp;hellip; and the performance problems. 」\n大规模集群既是照妖镜，也是试金石。\nPART. 2 大规模集群的收益 诚然，构建一个大规模的 Kubernetes 集群也提供了诸多收益：\n 为运行大型服务提供更为便利的基础设施 ，便于应对业务扩容时大幅飙升的资源需求。例如在双十一等电商大促活动期间，可以通过扩展现有集群而不是新建其它小集群来应对业务的增长。同时集群管理者可以管理更少的集群，并且以此来简化基础架构管理 。\n 为大数据和机器学习的离线计算任务提供更多的资源，为分时复用/分时调度等调度手段提供更大的施展空间，让离线的计算任务在在线业务的低峰期时可以使用更多的资源进行计算，享受极致弹性和极速交付。\n 还有非常重要的一点，在更大的集群中可以通过更加丰富的编排调度手段来更为有效地提升集群整体的资源利用率。\n PART. 3 SigmaApiServer性能优化 Sigma apiserver 组件是 Kubernetes 集群的所有外部请求访问入口，以及 Kubernetes 集群内部所有组件的协作枢纽。apiserver 具备了以下几方面的功能:\n 屏蔽后端数据持久化组件 etcd 的存储细节，并且引入了数据缓存，在此基础上对于数据提供了更多种类的访问机制。\n 通过提供标准 API，使外部访问客户端可以对集群中的资源进行 CRUD 操作。\n 提供了 list-watch 原语，使客户端可以实时获取到资源中资源的状态。\n 我们对于 apiserver 性能提升来说可以从两个层面进行拆解，分别是 apiserver 的启动阶段和 apiserver 的运行阶段。\napiserver 启动阶段 的性能优化有助于：\n 减少升级变更影响时长/故障恢复时长，减少用户可感知的不可用时间，给 Sigma 终端用户提供优质的服务体验（面向业务的整体目标是 Sigma 月度可用性 SLO 达到 99.9%，单次故障不可用时间 \u0026amp;lt; 10min）。\n 减少因为发布时客户端重新 list 全量资源而导致的 apiserver 压力过大情况出现。\n apiserver 运行阶段 的性能优化的意义在于：\n 稳定支持更大规模的 Kubernetes 集群。\n 提高 apiserver 在正常平稳运行的状态中，单位资源的服务能力；即提高可以承受的请求并发和 qps， 降低请求 RT。\n 减少客户端的超时以及超时导致的各种问题；在现有资源下提供更多的流量接入能力；\n 整体优化思路\n构建一个大规模的 Kubernetes 集群以及性能优化不是一件容易的事，如 Google Kubernetes Engine K8s 规模化文章所 …","date":1632812400,"description":"攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践","dir":"blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b6cc47242239f350d5aca9717037f061","permalink":"https://sofastack.github.io/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","publishdate":"2021-09-28T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","summary":"文｜唐博（花名：博易 蚂蚁集团技术专家) 谭崇康（花名：见云 蚂蚁集团高级技术家) 本文 10316 字 阅读 18 分钟 ▼ 蚂蚁集团运行着全球最大的 Kubernetes","tags":["SOFAStack"],"title":"攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践","type":"blog","url":"/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","wordcount":7129},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@证道者 提问：\n MOSN 怎么将 HTTP 转到 Dubbo 的数据,怎么实现新的协议？\n A：这个你要写个 filter ，因为每个 HTTP 字段怎么对应 Dubbo 的字段，是没有固定标准的。\nA：「HTTP 转 SOFA 的例子」 https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ftranscoder%2Fhttp2bolt\nA：这个需要 client 满足这个字段对应规范，所以一般就自己实现了。\n 公司很多这种 RPC 的接口，每一个接口都要写一下 filter 吗？没有通用的转换吗？\n A：一个协议就一个吧，比如 HTTP 的 header：service 对应 Dubbo 的 service。你也可以用其他的 HTTP header 来对应，比如用 dubbo-service，所以没有一个标准，就需要自己简单做个对应关系。\nMOSN：https://github.com/mosn/mosn\n@王夕 提问：\n 咨询一个问题，TCC 的嵌套子事务，如果发生重试的话，如下图中的 2、6，会产生不同的 branch 记录吗？ A：有可能,要么关了重试,要么做幂等\n 也就是说根据 xid 做幂等，而不要根据 branchid 做幂等对吗？\n A：branchid 进来一次就变一次,肯定不行,该分支同入参同 xid 一般就可以作为幂等的校验条件。\nSeata：https://github.com/seata/seata\n@江培泉 提问：\n 请教下，oracle 用户没获取到行信息，导致 undo_log 无法插入，也无法回滚。 主键字段类型和 JAVA 的类型： A：主键的 Long 改成 BigDecimal，Oracle 的 number 长度超过 19 之后，用 Long 的话，setObject 会查不出数据来。\nSeata：https://github.com/seata/seata\n本周推荐阅读 SOFAJRaft 在同程旅游中的实践\n 技术风口上的限流\n 蚂蚁智能监控\n 2021 年云原生技术发展现状及未来趋势\n ","date":1632466800,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210924/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"88a73b7a463bc79a5bcb81ae4e0a4fee","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210924/","publishdate":"2021-09-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210924/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210924/","wordcount":903},{"author":"赵延","categories":"SOFAStack","content":"文｜赵延（SOFAJRaft Committer)\n校对｜冯家纯（SOFAJRaft Committer)\n本文 15717 字 阅读 23 分钟\n▼\n同程艺龙作为对 Raft 研究较早的公司，早在 14 年算法的 paper 刚发布的时候，便已经对其进行了调研。同时也与 paxos 、zab 等算法进行了详细的对比，并在公司内部的计数器、任务调度元信息存储等场景进行试点。\n不过早期对于 Raft 的尝试较多的是在 C++ 技术栈试水，在 Java 技术栈里却很少有涉及。\n近期刚好有基于 etcd 的老项目由于需要自定义的数据结构需要重构，原有的 etcd 无法在底层数据结构层面满足需求，因此决定采用 Java 技术栈结合开源项目 SOFAJRaft 进行底层数据存储的开发，以期解决多节点数据强一致的问题。\n本文假设读者对 Raft 及强一致的概念已经有了较深的理解，详细介绍了公司内部如何使用 *JRaft* 的进行老系统的改造以及使用过程中遇到的工程问题，希望其他对 Raft 有兴趣的同学可以一起讨论。\nPART. 1\n背 景\n公司内部原本存在一个系统 mdb (metadata database)，go 语言编写，用于管理所有的实例元数据信息，元数据的内容就是一个 map。\n该组件提供对元数据增删改查的接口，并且使用 go 语言编写，在检索数据时引入了 K8s selector 的包，使用 K8s selector 的解析规则筛选特定标签的元数据信息。\n数据持久化则是实用了强一致组件 etcd 进行存储，key 为元数据的 ID，保证唯一，value 为具体的元信息，包含各个标签以及对应的值。\n该系统大体架构如图 -1 所示:\n 图-1：原来的架构\n「该架构的弊端」\n 每隔一段时间需要去拉取 etcd 的全量数据，担心单次请求数据量太大的情况，对数据 ID 进行了 hash 分片，依次获取每个分片下个 key，再通过 key 去获取 value，导致 etcd 的查询频率非常高。\n 非 ID 查询条件的一致性查询，和上面的问题一样，也需要做拉取全量数据的操作。\n 更新删除操作也是一样，需要拉取全量数据再操作。\n 分析以上问题可以发现，使用 etcd 作为强一致存储，但 etcd 是基于 KV 存储的组件，并且解析组件 mdb 和 etcd 是分离的，在需要保证数据最新的情况下，必须得去 etcd 拿最新的数据到本地再进行操作。\n而 etcd 基于 KV，就得拿到 etcd 的全量数据都给拉到本地后再做操作。\n如果有一个组件，提供强一致的存储能力，又能直接去解析 K8s selector 的规则，存储的数据结构和元数据信息更加亲和，那么中间的那一层 mdb 就可以直接去掉了，由这个组件来解析对应的 crud 规则，将解析过后的规则直接在本地查询，那么以上问题就能够直接解决了。\nPART. 2\n改 造\n基于以上问题，我们准备自己开发一个强一致存储的组件，能够自己解析 K8s selector 的规则，并且将数据保存在自己本地。\n因为个人对 Java 语言比较了解，并且之前使用 Nacos 时，对 SOFAJRaft 也有一定了解，最终选择了 SOFAJRaft 来构建强一致存储组件，将它命名为 mdb-store。\n主要改造点：\n 使用 SOFAJRaft 编程模型构建业务状态机，业务状态机中根据 Raft log 中的 data 类型，进行 crud 的操作。\n mdb-store 提供与原来 mdb 相同的 api，让改造对用户透明，改造完成后只需要切换域名对应的实例即可。\n 迁移 K8s selector 的解析逻辑，这里用 Java 写了一套和 go 版本 K8s selector 一样解析逻辑的组件 K8s-selector-Java。\n 改造过后的架构如图-2所示:\n 图-2：重构后的架构\n通过改造过后，将 mdb 移除，让用户直接和 mdb-store 进行通信，中间的通信少了一跳，加快了访问效率。将 mdb 和 etcd 也进行了移除，减少了整个系统的组件，降低运维成本。\nPART. 3\nSOFAJRaft 的具体使用\n将写操作转换成 Raft log\n在 SOFAJRaft 中，编程模型和通常的 Spring MVC 的编程模式不太一样。\n在 Spring MVC 中，一个请求到达了后端，通常会通过 Controller -\u0026amp;gt; Service -\u0026amp;gt; Processor 这么几层。Controller 负责本次 http 请求的资源映射， 再由 Controller 去调用特定的 Service 方法，在 Service 层中，对参数进行一些处理和转换，再交由 Processor 层去对请求做真正的处理。\n大体逻辑如图 -3 所示，\n 图-3：通常的编程模型\n在 SOFAJRaft 中，所有的写操作都要通过状态机去执行（读操作不需要经过状态机）。需要将写操作转换成 task，状态机去应用 task 然后再进行业务处理。\ntask 中包含两个属性是需要关注的，一个是 done，一个是 data。\n- done 就是本次 task 被状态机处理完成后的回调，比如在 done 的回调逻辑中，将 response flush 到客户端。\n- data 就是 Raft log 中的具体数据，比如要执行一条插入元数据的命令。data 就会包含本次操作的类型（插入），以及本次操作的具体数据。\nprivate ByteBuffer data = LogEntry.EMPTY_DATA; private Closure done; /// 省略部分代码 } 大体逻辑如图 -4 所示，\n 图-4：SOFAJRaft 的编程模型\n所有的操作都抽象成一个实体 Operation，在 Service 层，就根据业务把参数转换成不同的 Operation，然后再将 Operation 序列化，设置到 Task 中的 data 属性，再由 Node 将 task 提交。\n这里可以将 task 看成是一个 Raft log，一旦 Raft log 被半数的机器给提交。状态机就会应用 Raft log，应用完成之后就会触发 done 中的回调。\n· 抽象过后的实体类\n//操作类型，比如增删改查 int type; //操作的哪个表，某些类型不需要此字段 String table; //具体的操作数据，根据 type 的不同，数据类型也会不同 T params;} · 构建 task 并通过 node 提交给状态机\n//定义回调的逻辑，当该 Raft log 被状态机应用后，会进行回调 task.setDone(new StoreClosure(operation, status -\u0026amp;gt; { StoreStatus storageStatus = (StoreStatus) status; closure.setThrowable(storageStatus.getThrowable()); …","date":1632207600,"description":"SOFAJRaft 在同程旅游中的实践","dir":"blog/sofajraft-in-practice-in-the-same-tour/","fuzzywordcount":7500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7c319b747ce3bc0df7adbd820d690ed3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","publishdate":"2021-09-21T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","summary":"文｜赵延（SOFAJRaft Committer) 校对｜冯家纯（SOFAJRaft Committer) 本文 15717 字 阅读 23 分钟 ▼ 同程艺龙作为对 Raft 研究较早的公司，早在 14 年算法的 paper 刚发布的","tags":["SOFAStack"],"title":"SOFAJRaft 在同程旅游中的实践","type":"blog","url":"/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","wordcount":7461},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@证道者 提问：\n 今天看了文章，好像蚂蚁 MOSN 结合 envoy，性能更好，不知道有没有开源这个？\n A：有开源，有个镜像可以玩。\nhttps://mp.weixin.qq.com/s/ioewVcwiB5QA8w3A3gaikg，\n今年 GopherChina 的文字版, 可以了解下。我们内部已经落地，线上跑飞起来了，适合不同的场景了。目前我们用在南北和网关，比较大规模的场景。这个目前也在跟 envoy 官方共建合作，还有场景就是本来就是 envoy 的用户，也可以更简单的写扩展。\n2、@朱仕智 提问：\n 请问这个限流在开源版本 MOSN 里面吗？\n A：在开源，内部的做了一些业务相关的扩展。\n3、@Glennxu 提问：\n请问下现在统一限流中心能使用么？\n A：现在开源版本还用不了集群限流，自适应限流的实现也和我们的有一些差异,后面我们会考虑移植到开源版本的。\n4、@朱仕智 提问：\n 今天正好在看 kratos 里面限流的文章，那个限流就是自适应限流，这里提到统一限流中心，这个哪里能看到？\n A：这个短期我们估计不会开源的，主要是这部分功能本身比较简单，而我们内部的规则和开源的模型也有所不同，加上现在我们跟自己的基础设施绑定了，不太方便直接开源。\n5、@魏小亮 提问：\n 是不是简单理解为 MOSN 作为 cpp 的动态库，作为一个插件给 envoy 调用？\n A：可以这么简单认为，对于一般用户的话就是用关心 MOSN 就行了，写 MOSN 的 filter，不需要了解底层机制。就像大家用 openresty，也很少去关心 nginx 和 luajit。\n 我以为要实现一个 envoy 的 filter 需要 c++ 代码来实现。\n A：其实 lua 也可以， 比如用 go 你可以启动一个 zk，然后去调用 envoy 的 xds 做服务发现可以做的事情就很多了。\n6、@茄子 提问：\n请教一下，在使用 rheakv 的过程中出现这个问题要怎么排查?\n A：可以看下 bolt 怎么设置写入的高低水位线，这应该是触发了 netty 的 channel 写入水位线。\ncom.alipay.remoting.config.BoltGenericOption#NETTY_BUFFER_HIGH_WATER_MARK com.alipay.remoting.config.BoltGenericOption#NETTY_BUFFER_LOW_WATER_MARK\n刚才找了下，你看些这个类的 options。\n com.alipay.sofa.jraft.rpc.impl.BoltRaftRpcFactory#CHANNEL_WRITE_BUF_LOW_WATER_MARK com.alipay.sofa.jraft.rpc.impl.BoltRaftRpcFactory#CHANNEL_WRITE_BUF_HIGH_WATER_MARK\njraft 也开放了设置。\n本周发布 SOFABoot 开源发布 3.9.0 版本，\\主要更新如下\\：\n SOFABoot 异常日志添加错误码；\n 去除 AbstractContractDefinitionParser 对 Autowire 注解的使用；\n 为 RPC 服务提供方添加开关，可以不注册到服务注册容器中；\n 添加健康检查进度；\n 去除 SOFARuntimeManager 对 Value 注解的使用；\n 优化 Spring 上下文并行启动的线程池配置。\n 详细参考：\nhttps://github.com/sofastack/sofa-boot/releases/tag/v3.9.0\n**SOFARPC 发布 v5.7.10 版本代码，主要更新如下：\n SOFARPC 支持接口中静态方法的使用；\n 使用 TransmittableThreadLocal 解决 RpcInternalContext 中 ThreadLocal 值传递问题；\n 优化超时时间的获取与校；\n 反序列化过程中正确感知 header 变化；\n 修复 RpcInvokeContext 中线程安全问题；\n 修复 ProviderInfo中getAttr 类型转换问题。\n 详细参考：\nhttps://github.com/sofastack/sofa-rpc/releases/tag/v5.7.10\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1631862000,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210917/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"83215c365789c806399a2ca00fc114e9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210917/","publishdate":"2021-09-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210917/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210917/","wordcount":1344},{"author":"张稀虹","categories":"SOFAStack","content":" 站在风口上 要问近两年最火的技术话题是什么？\nService Mesh 一定不会缺席。\n如果用一句话来解释什么是 Service Mesh。\n可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。*\n对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关心服务之间的那些原本通过服务框架实现的事情，只要交给 Service Mesh 就可以了。\nService Mesh 作为 sidecar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在 Serivce Mesh 中实现，这对于限流熔断而言就是一个天然的流量劫持点。\n如今蚂蚁 80% 以上的应用都已经完成了 Mesh 化，Mesh 统一限流熔断的建设自然是水到渠成了。\n服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。\n在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。\n 相较于传统的限流组件，Mesh 限流具备很多优势，在研发效能和研发成本上都取得了明显的收益：\n- MOSN 架构天然的流量劫持让应用无需逐个接入 SDK\n- 也无需为特定语言开发不同版本的限流组件\n- 限流能力的升级也无需业务同步升级\n「背景业务」\n 在 Mesh 统一限流实现前，蚂蚁集团内部存在多个不同的限流产品，分别提供不同的流量控制策略：\n不同类型的流量（SOFARPC、无线网关 RPC、HTTP、消息等）限流配置分散在不同的平台，由不同的团队维护，产品质量和文档质量参差不齐，学习成本高、使用体验差。\n不同的限流策略需要接入不同的 SDK，引入很多间接依赖，安全漏洞引起的升级频繁，维护成本高。\n不仅在开发建设上存在不必要的人力投入，也给业务方使用造成了困扰和不便。\n另一方面，我们的业务规模越来越大，但大量服务仍在使用最简单的单机限流策略。没有通用的自适应限流、热点限流、精细化限流、集群限流等能力。\n因为限流能力缺失、限流漏配、错误的限流配置等问题引起的故障频发。\nMesh 架构下，sidecar 对流量管理具备天然的优势，业务无需在应用中接入或升级限流组件，中间件也无需针对不同的技术栈开发或维护多个版本的限流组件。\n在目前 Service Mesh 蚂蚁内部大规模接入完成的背景下，将多种不同的限流能力统一收口至 MOSN，将所有限流规则配置统一收口至“统一限流中心”，可以进一步提高 MOSN 的流量管理能力，同时大幅降低业务限流接入及配置成本。\n基于这样的背景下，我们在 MOSN 中进行了统一限流能力建设。\n站在巨人肩膀上 在建设统一限流能力的过程中，我们调研了许多成熟的产品，既包括我们自己的 Guardian、Shiva、都江堰等，也包括开源社区的 concurrency-limits 、Hystrix、Sentinel 等产品。\n我们发现阿里巴巴集团开源的 Sentinel 是其中的集大成者。\n之前我们在打造 Shiva 的过程中也与集团 Sentinel 的同学进行过交流学习，他们也正在积极建设 Golang 版本的 sentinel-golang。\nMOSN 作为一款蚂蚁自研的基于 Golang 技术建设的 Mesh 开源框架，如果搭配上 Sentinel 的强大的流控能力和较为出色的社区影响力，简直是强强联合、如虎添翼、珠联璧合、相得益彰\u0026amp;hellip;啊。\n不过 Sentinel 对于我们而言也并不是开箱即用的，我们并不是完全没有历史包袱的全新业务，必须要考虑到蚂蚁的基础设施和历史限流产品的兼容，经过我们调研发现主要存在几个需要投入建设的点：\n 控制面规则下发需要走蚂蚁的基础设施\n *Sentinel-golang 的单机限流、熔断等逻辑，*和我们之前的产品有较大差异\n 集群限流也要用蚂蚁的基础设施实现\n *Sentinel 自适应限流粒度太粗，*蚂蚁有更加精细化的需求\n 日志采集方案需要调整\n 综合考虑后，我们决定基于 Sentinel 做扩展，站在巨人的肩膀上打造蚂蚁自己的 Mesh 限流能力。\n基于 Sentinel 良好的扩展能力，我们对单机限流、服务熔断、集群限流、自适应限流等都做了蚂蚁自己的实现，也将部分通用的改动反哺到了开源社区，同时配套建设了统一的日志监控报警、统一限流中心。\n 最终我们在 MOSN 里将各种能力都完成了建设，下表展示了 MOSN 限流和其他限流组件的能力对比：\n 奥卡姆剃刀 Pluralitas non est ponenda sine necessitate.\n如无必要，勿增实体\n 一个限流策略就配套一个 SDK 和一个管理后台七零八落，交互体验参差不齐，文档和操作手册质量也良莠不齐，交由不同的团队维护和答疑，如果你全都体验过一遍一定会深恶痛绝。\n而 Mesh 统一限流的核心目的之一就是砍掉这些东西，化繁为简，降低业务同学的学习成本和使用成本，降低我们自己的维护成本。\n- 流量控制的能力全部集成到 MOSN 里，取众家之长，去其糟粕\n- 流量控制的管控台全部收口到统一限流中心\n 这应该是我们造的最后一个限流轮子了吧\n青出于蓝而胜于蓝\n上文提到了我们是站在 Sentinel 的肩膀上实现的 Mesh 统一限流，那我们又做了什么 Sentinel 所不具备的能力呢？\n实际上我们对几乎所有的 Sentinel 提供的限流能力都做了一套自己的实现，其中也有不少的亮点和增强。\n下面分享几个我们的技术亮点。\n自适应限流\n- 对于业务同学而言逐个接口做容量评估和压测回归费时费心，有限的精力只能投入到重点的接口保障上，难免会漏配一些小流量接口的限流。\n- 而负责质量和稳定性保障的同学经常在故障复盘时看到各种漏配限流、错配限流、压测故障、线程阻塞等造成的各种故障。\n我们希望即使在系统漏配错配限流的情况下，在系统资源严重不足时 MOSN 能够精准的找到导致系统资源不足的罪魁祸首，并实时根据系统水位自动调节异常流量。\n在此需求背景下我们实现了一套符合成熟云原生定义的自检测、自调节的限流策略。\n 自适应限流的实现原理并不复杂，朴素的解释就是，触发限流后实时检测系统整体水位，同时秒级按比例调节流量。\n核心逻辑如下：\n- 系统资源检测：秒级检测系统资源占用情况，如果连续超过阈值 N 秒（默认 5 秒）则触发基线计算，同时将压测流量阻断腾挪出资源给线上业务使用；\n- 基线计算：将当前所有的接口统计数据遍历一遍，通过一系列算法找出资源消耗大户，再把这些大户里明显上涨的异常流量找出来，把他们当前的资源占用做个快照存入基线数据中；\n- 基线调节器：将上一步骤存入的基线数据根据实际情况进行调整，根据系统资源检测的结果秒级的调整基线值，仍然超过系统阈值则按比例下调基线值，否则按比例恢复基线值，如此反复；\n- 限流决策：\n系统流量不断经过自适应限流模块，会尝试获取该接口的基线数据，如果没有说明 …","date":1631602800,"description":"技术风口上的限流","dir":"blog/restricted-flow-on-the-technology-windfall/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cb0fcdbcc898f63e21810897fcd0a0d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","publishdate":"2021-09-14T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","summary":"站在风口上 要问近两年最火的技术话题是什么？ Service Mesh 一定不会缺席。 如果用一句话来解释什么是 Service Mesh。 可以将它比作是应用程序或者说微服务间的 TCP","tags":["SOFAStack"],"title":"技术风口上的限流","type":"blog","url":"/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","wordcount":4850},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA x Erda Meetup#8 成都站，云原生基础设施建设的现在及未来\n 活动时间：2021 年 09 月 11 日（周六）13:30-17:00\n 活动地点：四川省成都市武侯区蚂蚁 C 空间 101 猎户座\n 活动形式：线下活动\n 资料下载： 《从云原生视角，解读 Erda 微服务观测系统的实现》 《Service Mesh落地之后：为 sidecar 注入灵魂》 《技术风口上的限流—蚂蚁集团的 Mesh 限流落地与实践 》 《Erda 关于云原生数据开发平台的思考和实践》\n 活动议程 活动回顾 《从云原生视角，解读 Erda 微服务观测系统的实现》\n嘉宾介绍\n刘浩杨，Erda 微服务和监控团队负责人，主要负责云原生 PaaS 的架构设计、微服务观测治理平台的产品技术规划等工作，对分布式、可观察性、云原生等方向有深入的研究和实践经验。同时也是开源爱好者，Apache SkyWalking PMC 成员，在 Apache SkyWalking 的多语言生态和社区建设中起到重要作用。\n议题简介\n 在云原生架构下，基于 DevOps、微服务、容器化等云原生的能力，可以帮助业务团队快速、持续、可靠和规模化地交付系统，同时也使得系统的复杂度成倍提升，由此带来了前所未有的运维挑战。 在此背景下，对分布式系统的“可观测性”应运而生，可观察性提供了一套理念来监控、诊断云原生应用系统。和监控相比，可观察性从单一的度量扩展为 Metrics、Tracing、Logging 三大支柱，Erda MSP (MicroService Platform) 中的 APM 系统也在逐渐演进为以可观察性分析诊断为核心的微服务观测平台，本次主题将会解读 Erda 对微服务观测系统的探索和实践。 听众收获\n可快速了解监控和可观测性技术的发展历程，了解云原生场景下可观测性的痛点和解决方案，及获取 Erda 微服务观测平台的功能特性。\n《Service Mesh落地之后：为 sidecar 注入灵魂》\n嘉宾介绍\n周群力（花名：仪式），开源爱好者, co-founder of Layotto，Dapr contributor。目前在蚂蚁中间件团队工作，对SOFAStack和MOSN的开源影响力负责。虽然工作是做云原生基础设施，但业余时间也喜欢折腾前端和数据。\n议题简介\n 随着Service Mesh在蚂蚁集团内部的大规模落地，我们逐渐遇到了新的挑战，这让我们迫切的寻找新的解决方案。 Service Mesh通过引入sidecar来简化服务治理，但是随着探索实践，我们发现 sidecar 能做的事情远不止于此。一方面，给 sidecar 添加 Multi-Runtime 能力可以帮助基础设施团队更好的和业务团队解耦，简化多语言治理；另一方面，中立的 Runtime API 可以抽象基础设施、简化编程，帮助 K8s 生态成为真正的“分布式操作系统”，也帮助应用彻底和厂商解绑，保证多云环境的可移植性；与此同时，在 WebAssembly 日益火爆的当下，WASM 也能帮助 sidecar 实现 FaaS、业务系统 sdk 下沉等功能。 那么，Service Mesh落地之后，架构演进的思路是什么？我们的思路是：为sidecar注入灵魂。 听众收获\n 了解蚂蚁集团在Service Mesh大规模落地以后遇到的新问题以及对于如何解决这些问题的思考。 了解Multi-Runtime解决的问题及实践经验。 了解中立的Runtime API解决什么问题，以及相关实践经验 了解WASM在FaaS等方向的探索。 《技术风口上的限流—蚂蚁集团的 Mesh 限流落地与实践 》\n嘉宾介绍\n张稀虹，蚂蚁集团技术专家，专注于云原生相关技术在业务生产中的落地与实践，开源项目 MOSN 核心成员，目前关注云原生 ServiceMesh、Serverless 等相关领域。\n议题简介\n ServiceMesh 可谓是站在风口上的技术热点，流量控制正是 Mesh 架构下的核心功能。Mesh 的架构优势使得业务可以更低成本的使用上通用的限流熔断能力，本次分享为大家介绍蚂蚁集团的 Mesh 限流能力的建设以及业务落地推广的实践经验。 听众收获\n 了解 Mesh 架构下的限流熔断技术优势 分享蚂蚁集团 Mesh 限流熔断能力建设经验 拓宽思路了解限流熔断未来的探索方向 《Erda 关于云原生数据开发平台的思考和实践》\n嘉宾介绍\n侯璐瑶，高级技术专家，Erda 数据团队负责人，主要负责基于云原生的数据平台的架构设计、负责数据应用产品架构和产品演进，对于大数据领域数据组件和数据应用等方向有比较深入的研究和实践经验。\n议题简介\n 数据 on 云原生是必然的路径，云原生对于数据平台带来了比传统平台更容易的扩展性和便捷性。本次分享主要介绍 Erda 数据开发平台在云原生上的建设和实战经验。 听众收获\n 了解云原生的整体数据架构； 分享 Erda 的落地实践经验。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1631343600,"description":"【活动回顾】SOFAMeetup#8 成都站 云原生基础设施建设的现在及未来","dir":"activities/sofa-meetup-10/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"270d57821d3a01ac4bc85082d157f6d9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-10/","publishdate":"2021-09-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-10/","summary":"概要 活动主题：SOFA x Erda Meetup#8 成都站，云原生基础设施建设的现在及未来 活动时间：2021 年 09 月 11 日（周六）13:30-17:00 活动地点：四川省","tags":["SOFAMeetup"],"title":"【活动回顾】SOFAMeetup#8 成都站 云原生基础设施建设的现在及未来","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-10/","wordcount":1791},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@胡希国 提问：\n 这个 start 函数在父进程执行完 WaitConnectionsDone()之后在哪调用的，新的子进程在迁移长连接的时候监听 conn.sock 等着老进程调 startRWloop 去连接和发送 connfd，看源码一直到 WaitConnectionsDone() 就断了，实在没找到接下来在哪执行的 ReadLoop 和 WriteLoop。\n https://github.com/mosn/mosn/blob/0ea3e3b4b2abfde2a845edc006a3e866ff0b1201/pkg/network/connection.go#L186\nA：迁移连接之后，创建连接最后就会 start 了。\n 2、@胡希国 提问：\n 父进程的每个长连接 connection fd 里面都有一个 readloop 逻辑是吗？一旦 WaitConnectionsDone() 触发了 stopchan 那个条件，就自动做迁移了是吧。\n A：是的，每个连接都有 readloop 的， WaitConnectionsDone 就是等他们迁移完。\nhttps://mosn.io/docs/concept/smooth-upgrade/\n这篇文章里面有写的。\n 3、@汪晓涛 提问：\n 镜像地址有吗？可以对接 dapr 吗？\n A：目前是七层扩展哈，对接 dapr 是四层，这个月底应该就可以支持了。\nhttps://github.com/mosn/mosn/issues/1563\n4、@徐泽唯 提问：\n 大佬帮我看下这是什么问题？xid in change during RPC from 192.168.2.115:8091:178170994535436288 to null。\n A：不影响，直接升级最新的 spring-cloud-starter-alibaba-seata 和最新的 seata-all 或者 seata-spring-boot-starter 即可，只是一个日志警告。\n5、@北京jht 提问：\n 如果想了解一下这个组件对系统带来的开销和性能，可能会出现在哪个问题上。\n A：没有实际的业务场景，结果出入比较大。RPC 开销应该是最大的消耗。\n 咱们这个 Seata-Server 的回查和提交都是异步的吧，会对 RPC 本身的耗时产生影响吗？\n A：你算 RPC 一次 1ms tm begin 1ms rmregisty 1ms 如果有 3 个 rm，就是 4ms。然后 tm 决议发给 tc，5ms。如果是 tcc，那么就是 5ms + tc 下发到 3 个 rm 执行，rm 执行二阶段业务也要时间。\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1631257200,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210910/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e29e1740eb32b19f715b92a21a2dfd02","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210910/","publishdate":"2021-09-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210910/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210910/","wordcount":907},{"author":"向万鹏","categories":"SOFAStack","content":" AntMonitor简介 AntMonitor 是蚂蚁集团的智能监控系统，通过构建面向监控可观测数据的、实时的、稳定的采集、清洗、计算及存储数据链路，为技术风险大脑及体系提供实时、稳定、可靠、丰富的可观测数据与告警服务。\nAntMonitor 日常服务于蚂蚁全站 100+ 业务域，分钟峰值数据清洗量 20TB、数据聚合量 1TB、数据存储量 1.5 亿条，大促期间这些指标更是成倍增长，如此庞大且复杂的系统是如何对自身的稳定性进行保障的，这篇文章将从思考、策略与实现的角度带领大家一探究竟。\n系统构架 系统架构上，AntMonitor 可以分为产品、告警、计算和存储等四个子系统，各个子系统可以独立提供服务，又相互协调配合，承担起了蚂蚁技术风险的数据底盘角色。\n 产品系统 产品系统直接为用户提供各项可视化服务，包括 monitormeta 和 monitorprod 两个组件。\n monitormeta 负责元数据的管理与同步，例如计算配置、告警规则以及各类运维元数据等；\n monitorprod 为产品中台核心服务，对外提供数据服务；对内支持数据模型定义，数据模型抽象，数据模型转换等能力。\n 计算系统 计算系统提供一体化的数据采集、清洗、聚合与数据生命周期管理服务。计算系统内组件较多，可以分为服务层、计算层和采集层进行介绍。\n一、服务层\n tableapi 对外提供标准的数据服务接口；\n dimservice 为列式的元数据缓存服务中心。\n 二、计算层\n global-scheduler（gs） 为全局任务调度组件，负责对注册过来的 compute-space 计算集群进行生命周期管理，并基于配置生成任务拓扑，随后投递到计算集群。\n compute-space（cspace） 为一个抽象的计算能力资源池，负责对gs投递过来的任务拓扑进行解析执行以产出数据，写入存储系统，并将任务状态反馈给 gs ，cspace 并不与具体的数据计算资源池绑定，底层的实现可以是任意计算引擎。当前，一个 cspace 节点的实现为一个 spark 集群。\n三、采集层\n gaea-registry为整个采集侧的管控中心，它将采集配置下发给 agent 和 vessel ，同时也负责维护所有 agent 和 vessel 的健康状态与路由信息等。\n agent为部署在物理机上的采集服务进程，负责对日志、系统指标、事件等原始数据进行读取。\n vessel为数据清洗集群，负责拉群 agent 采集的原始数据进行结构化清洗，并以 rpc 形式返回给 cspace 。\n 告警系统 告警系统基于用户配置的告警规则对计算产出的指标数据进行巡检，产出告警事件并推送给订阅者。告警系统的组件与计算系统有些类似，包括：\n alarm-global-scheduler（alarm-gs）为告警调度组件；\n alarm-compute-space（alarm-cspace）为告警计算资源池；\n alarm-gateway 为告警推送网关。\n 如果将告警系统和计算系统进行类比的话，可以抽象地认为：告警的输入不是采集，而是计算系统产出的数据；告警的输出也不是存储系统，而是告警通知网关 alarm-gateway 。\n存储系统 存储系统（ceresdb）为 AntMonitor 提供时序数据的读写服务。\n ceresdbconsole 为可视化的运维管控组件；\n ceresmeta 为元数据管理组件，负责存储集群的主备切换、扩缩容等协调工作；\n ceresproxy 与 ceresbase 为部署在同一个容器内的两个伴随进程，其中 ceresproxy 为路由层，负责对查询或写入的数据进行汇总，并将结果返回给客户端，同时提供租户校验、流控、黑名单等能力；ceresbase 为数据存储节点，负责时序数据的存储、索引维护等功能。\n 稳定性建设 监控系统在整个蚂蚁的体系架构内是一个特殊的角色，它在承载所有业务系统的可观测与告警能力的同时，还为容量、自愈、故障应急等技术风险其他子域提供着数据服务。\n因此，监控对自身的稳定性要求更加严苛，在诸如大规模宕机、机房网络中断或更极端情况下，监控也需要保障自身是可以稳定运行的。\n针对蚂蚁智能监控自身的稳定性建设，我们主要从两方面进行推进，包括稳定性架构的设计与运行时的稳定性保障，整体如下图所示。\n 稳定性架构 稳定性架构是建设稳定性中最重要的一环，一个经过缜密设计的稳定性架构，可以使我们后期尽可能优雅从容地处理各类稳定性问题，而不是疲于奔命地打地鼠。\n具体来说，在设计稳定性架构之初，我们首先应该意识到系统的运行时环境和输入都不会是稳定的。\n运行时环境的不稳定 ，主要体现在机器的故障宕机、网络的抖动，或者更极端的机房光纤被挖断、城市自然灾害等客观因素影响。处理这类问题通常从两方面出发：\n第一、尽可能地提升系统的容灾等级。\n例如单点、机房级容灾、城市级容灾等，以最基础的去单点来说，我们需要保证所有的调度或同步类节点（例如 monitormeta、gs）都是基于主备架构的，所有的服务类节点（例如 monitorprod、tableapi）都是无状态的，所有的分片节点（例如 gaea-registry、ceresbase）都是存在冗余副本的，所有的工作类节点（例如 cspace、alarm-cspace），宕机后也都是可以自行恢复的。\n第二、所有的数据处理流程都应该面向失败进行设计。\n因为当故障发生后，可能某几个周期的任务已经失败，这时候需要有能力驱动这些任务进行重试，例如 cspace 需要有能力对某一个计算任务的采集失败进行容忍和重试、alarm-gs 需要对告警任务的执行失败进行重新调度等。\n针对系统输入的不确定性 ，我们也分两种情况进行处理：\n第一种情况是入口数据的错乱。\n例如脏配置、脏元数据、不合法的数据类型等，错误的数据流入系统可能会导致不可预期的行为，针对此类问题，我们通常需要在入口处进行校验，拒绝非预期的数据流入系统。\n第二种情况是入口数据量级管控。\n任何系统，其性能都是和容量挂钩的，其设计也都是在一定的性能容量平衡假设下进行的。监控系统的输入通常是业务日志，而且监控配置的定义是直面用户的，那么很可能一个随意定义的配置将导致海量的服务调用明细日志流入监控系统，导致集群崩溃，所以对流量的限制与管控非常重要。在 AntMonitor 中，各个关键的入口例如采集入口、计算入口、存储入口、数据查询入口等都有严格的流量管控校验规则，确保监控系统在预期容量下能够稳定运行，而不会被突发的流量所压垮。\n综上，我们将重点从容灾架构和架构单元化两方面出发来阐述 AntMonitor 稳定性架构的设计思路。\n容灾架构 前文简要提及了架构去单点问题的解决思路，这足以覆盖日常可能发生的节点宕机、网络抖动等小规模故障场景，但是当真正的毁灭性灾难来临时，还需要更高层面的容灾方案来应对。\n目前基于不同租户保障等级的区分以及资源配额等客观因素的权衡，AntMonitor 实施了两套不同等级的容灾策略，即针对常规业务域租户的机房级容灾和针对高保业务域租户的城市级容灾。\n机房级容灾 对于常规的业务域租 …","date":1630998000,"description":"蚂蚁智能监控","dir":"blog/ant-intelligent-monitoring/","fuzzywordcount":6700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3529d1b46b4e16c43414a1cd3e89fb02","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-intelligent-monitoring/","publishdate":"2021-09-07T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/ant-intelligent-monitoring/","summary":"AntMonitor简介 AntMonitor 是蚂蚁集团的智能监控系统，通过构建面向监控可观测数据的、实时的、稳定的采集、清洗、计算及存储数据链路，为技术风险大","tags":["SOFAStack"],"title":"蚂蚁智能监控","type":"blog","url":"/sofastack.tech/blog/ant-intelligent-monitoring/","wordcount":6622},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;ldquo;SOFA WEEKLY\u0026amp;rdquo; 的形式回复\n1、@黄润良 提问：\n 在写 filter 扩展的时候，如何获取一些请求的信息？比如请求 ip 之类的。\n A：*pkg/server/handler.go*，这里面可以看到设置进去的。\n MOSN：https://github.com/mosn/mosn\n2、@黄润良 提问：\n 一些 filter 只能用于某些协议的，但从配置来看，filter 应该是对所有协议都生效的吧？那我在设计 filter 的是需要考虑协议的兼容性吗？\n A：你配置的 listener 块里面有协议，就可以和 filter 对应上了。\n如果你怕别人误用，可以简单处理绕过。比如 dubbofilter 就是 Dubbo 协议自有的，怕其他协议误配置了，可以在代码跳过。\n MOSN：https://github.com/mosn/mosn\n3、@黄润良 提问：\n 目前有方法可以控制 filter 的执行的先后顺序吗？\n A：按照配置的顺序。\n 4、@楼政浩 提问： 往 raft 集群提交数据，都得通过 RPC 吗？ 如果我的 raft 节点的 fsm 又输出了 log，我想往集群提交这个 log，可以通过什么接口？\n A：jraft 通过 raft log 将数据复制到你各个节点的 fsm，fsm 的输入数据全部来自 raft log，你说的 fsm 又输出了 log 如果我没理解错的话，就是说本质上 fsm log 的输入全部来自 raft log，那么你这个所谓 log 就存在你自己的 fsm 就行，本来就是每个节点都会有的，不要再提交。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n5、@陈华洋 提问：\n SOFABoot 的模块化是怎么解决数据库链接的问题。 就是 SOFABoot 模块化之后，我把 mybatis 配置到了公共模块里面，然后其他模块父上下文指定为公共模块，但是其他模块内的 @Mapper 在项目启动的时候都扫描不到。\n A：建议把所有数据库相关的操作都放同一个模块，封装成 dal 层。可以配一个配置,让一个 spring 上下文里的 bean 暴露出来、能给别的 Spring 上下文用。\nSOFABoot：https://github.com/sofastack/sofa-boot\n6、@Z 提问：\n 请问在大数据量操作的时候，配置上有什么建议吗？\n A：把 6000 多条数据的操作在一个本地事务中完成，合并成一个分支注册。\nSeata：https://github.com/seata/seata\n7、@金箍 提问：\n 请问全局事务提交成功或者失败之后，有回调方法可以用吗？\n A：tm 有个 hook，其他没有。源码搜索「transactionlHook」有相关的文档。\nSeata：https://github.com/seata/seata\n8、@仪式 提问：\n 如果事务进行的过程中事务发起者（TM）宕机了，Seata 会怎么做故障处理呀。\n A：超时回滚，如果 TM 是决议提交给了 TC，那么“是”提交，“否”就只能等待超时回滚。TC 里的定时任务来做超时回滚。\nSeata：https://github.com/seata/seata\nSOFAStack \u0026amp;amp; MOSN：新手任务计划\n作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nSOFA-Boot\n设计实现一个新的配置项，用于判断 SOFA-Boot 是否由 IDE 启动。\nhttps://github.com/sofastack/sofa-boot/issues/861\nLayotto\n减少 panic 风险，给所有创建新协程的代码加上 recover。 设计实现 actuator metrics API，用于统计、展示 metrics 指标 WASM 通过 State API 访问存储：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n","date":1630652400,"description":"SOFA WEEKLY | QA 整理，新手计划","dir":"blog/sofa-weekly-20210903/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b8e03b60dc613f8a724cc3f95441bc2e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210903/","publishdate":"2021-09-03T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210903/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理，新手计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210903/","wordcount":1569},{"author":"SOFA 团队","categories":"SOFAStack","content":" 真的吗？真的吗？\nSOFA 志愿者开始招募啦？\n直视他！直视他！\nSOFA 星球在等你加入呀！\n我们正式启动“SOFA 星途者”计划\n只差一个你 即可成团出道\n不要感觉成团困难\n只要我们一起就能所向披靡\n谁是SOFA“星途者” SOFA 星途者是一群对开源宇宙感兴趣，希望在这片“宇宙”其中探索到更多“星辰”的人。SOFA 星途者们能够为千千万万的开发者们，提供丰富的 Meetup 及线上直播等交流平台。\n现在面向一切有理想、有追求的你们进行招募。\n“星”字代表 SOFA 星球，“途”代表在开源宇宙的征途。所以“星途”的意思即 SOFA 星球在开源宇宙的探索与征途。\n那么“星途者”就是加入 SOFA 星球的你们，让我们一起在开源宇宙中驰骋探索。\n“SOFA 星途者，探索开源宇宙中的星辰大海”\n即将进入，SOFA 社区 SOFAStack™（Scalable Open Financial Architecture Stack）是一套用于快速构建金融级云原生架构的中间件，也是在金融场景里锤炼出来的最佳实践，并且具备以下特点：\n开放：技术栈全面开源共建、 保持社区中立、兼容社区、兼容开源生态，组件可插拔， SOFAStack 组件与其它开源组件可相互集成或替换。\n金融级：包含构建金融级云原生架构所需的各个组件，让用户更加专注于业务开发，满足用户场景的现状和未来需求，经历过大规模场景的锤炼，特别是严苛的金融场景。\n云原生：基于 SOFAStack 可快速搭建云原生微服务体系，快速开发更具可靠性和扩展性、更加易于维护的云原生应用。\n开启 SOFA 征途 SOFA 陆续在全国各地组织了多场 Meetup 活动，活动全程直播，线上线下参与人数累计破万。Meetup 为 SOFA 星途者提供面对面沟通探讨的机会，收到了业界人士的一致好评。\n目前在北京、上海、杭州、合肥举办过 Meetup 活动，后续的还会点亮更多城市（成都、深圳、广州、南京等），欢迎你作为 SOFA 星途者加入我们的征途。\n杭州站\n 上海站\n 北京站\n 合肥站\n 召唤装备！ 在 SOFA 星球，大家不仅能够与每个领域的技术大牛面对面交流技术、认识新朋友，更能够收获 SOFA 星途者的周边衣服、杯子、双肩包等……\n最重要的是可以收获 SOFA 社区颁发的专属证书。\nSOFA 星途者的成员在参加 SOFA 的活动时可享受 VIP 通道，也会获得一些特大活动的 VIP 门票赠送～\n如果你是大学生“星途者”，那么你有可能会获得互联网大厂的实习推荐机会，在你感兴趣的星辰领域继续探索成长，有机会获得更多的学习机会。\n想成为一名“星途者”需要做些什么？\n扫描下方二维码\n 勇敢迈出成为“星途者”的第一步\n剩下的九十九步\n我们一起走\n","date":1630393200,"description":"SOFA 星球招募啦～","dir":"blog/sofa-star-is-recruiting/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d889b6b480fa6731f51805443e5ca5db","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-star-is-recruiting/","publishdate":"2021-08-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-star-is-recruiting/","summary":"真的吗？真的吗？ SOFA 志愿者开始招募啦？ 直视他！直视他！ SOFA 星球在等你加入呀！ 我们正式启动“SOFA 星途者”计划 只差一个你 即可成团出道 不要感觉成团","tags":["SOFAStack"],"title":"SOFA 星球招募啦～","type":"blog","url":"/sofastack.tech/blog/sofa-star-is-recruiting/","wordcount":960},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@胡希国 提问：\n 想和大家请教一下 MOSN 的热升级方案，就是我看到 MOSN 也是通过接收到 hup 信号然后 fork 的方式生成的一个新的子进程，（确切来说是 forkexec），和 Envoy 的解决方案应该是相同的，那为什么说和 Nginx 不一样呢？这种也是存在父子进程关系的吧（我看到 Envoy 是存在的），那为什么说没有继承 listenerfd 而需要通过 uds 来传递呢？\n A：Nginx reload 的过程是 master 不会退出，只是新 fork 了子进程。MOSN 是先启动一个 MOSN 进程，然后通过 socket 把 fd 继承过去之后，老的 MOSN 会退出。\nMOSN：https://github.com/mosn/mosn\n2、@鹏程万里 提问：\n FailureHandler 怎么实现自定义类呢？需要做回滚失败的通知。\n A：自己创建一个 Failurehandler bean return 一个实现类。\nSeata：https://github.com/seata/seata\n3、@随风 提问：\n 请问下，如果 A 方法和 B 方法上都有注解 GlobalTransactional，那么 A 方法可以直接调用 B 方法吗？\n A：可以的，用的还是一个 xid。\nSeata：https://github.com/seata/seata\n4、@zero 提问：\n 有分布式数据库了还需要用 Seata 吗？\n A：分布式数据库解决的是单个 connection 中每个 SQL 请求到了不同的库上的事务。一个分布式数据库背后可能有 N 个数据库被操作，内部用 xa 保证了事务。\nSeata：https://github.com/seata/seata\n本周发布 本周 SOFAJRaft 发布 1.3.8v版本。主要更新如下：\n Snapshot 支持并行压缩/解压缩，充分利用多核，加速在 snapshot 较大的时的 load 和 save 速度；\n CliService 提供 learner 到 follower 的转换 API；\n 修复 install snapshot retry 失败的 bug；\n 修复 RheaKV 在成员发生变更时没有刷新路由表的 bug。\n 详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.8\n新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nSOFA-Boot\n 发布服务时 增加 interfaceType 校验；\n 增加 SOFATracer 插件。\n 详见：\nhttps://github.com/sofastack/sofa-boot/issues/841\nLayotto\n 选择喜欢的组件实现分布式锁和分布式自增 id；\n 让 Layotto 能够简单方便的部署在 Kubernetes 上；\n 提供 Dockerfile，以便用户用 docker 部署 Layotto 。\n 详见：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1629442800,"description":"SOFA WEEKLY | SOFAJRaft 发布新版本,QA 整理","dir":"blog/sofa-weekly-20210820/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"60274ff33263cdb109e3d4342c35a45a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210820/","publishdate":"2021-08-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210820/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本,QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210820/","wordcount":1223},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#21：走进下一代互联网：HTTP/3\n 活动时间：08月18日,周三晚19点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#21：走进下一代互联网：HTTP/3 近年来，具备优秀基因的 QUIC 协议成为互联网领域炙手可热的传输技术。基于 QUIC 承载的 HTTP/2 也被正式命名为下一代传输协议： HTTP/3。这次直播会给大家介绍 QUIC，HTTP/3 的核心设计理念，以及在蚂蚁的应用实践。​\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 孔令涛（花名：伯琴） 蚂蚁集团技术专家，主要从事四七层协议优化，网关开发等工作。 议程 19:00-19:05 主持人开场 小助手-泡椒 主持人\n19:05-20:00 用安全计算保护关键业务 伯琴 蚂蚁集团技术专家，主要从事四七层协议优化，网关开发等工作。\n你将收获 你将了解 QUIC/HTTP/3 协议的前世今生、优良特性、落地实践、普及情况、与未来发展趋势等。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1629270000,"description":"8 月 18 日周三晚 19 点，线上直播第 21 期。","dir":"activities/sofa-channel-21-1/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b77dae9fff7d781959845f53872d0eee","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-21-1/","publishdate":"2021-08-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-21-1/","summary":"概要 活动主题：SOFAChannel#21：走进下一代互联网：HTTP/3 活动时间：08月18日,周三晚19点 活动形式：线上直播 资料下载：戳","tags":["SOFAChannel","HTTP/3"],"title":"SOFAChannel#21：走进下一代互联网：HTTP/3","type":"activities","url":"/sofastack.tech/activities/sofa-channel-21-1/","wordcount":588},{"author":"于雨","categories":"SOFAStack","content":" 个人有幸担任了 2021 年 GIAC 会议云原生专场的出品人兼讲师，组织了前后四个场子的演讲，在这个过程中个人同时作为听众从这些同行的演讲中学到了很多非常有用的知识。本文算是对 2021 GIAC 云原生专场的侧记，管中窥豹，以观 2021 年云原生技术发展现状及未来一段时间内的趋势。\n 云原生这个词含义广泛，涉及到资源的高效利用、交付、部署及运维等方方面面。从系统层次分可以区分出云原生基础设置【如存储、网络、管理平台 K8s】、云原生中间件、云原生应用架构以及云原生交付运维体系，本次专场的四个议题也基本涵盖了这四大方向：\n 亚马逊的资深技术专家黄帅的 《一个云原生服务的爆炸半径治理》 快手基础架构中心服务网格负责人姜涛的 《快手中间件 Mesh 化实践》 Tetrate 可观测性工程师柯振旭的 《使用 SkyWalking 监控 Kubernetes 事件》 本人以 Dubbogo 社区负责人出品的《Dubbogo 3.0：Dubbo 在云原生时代的基石》 下面根据个人现场笔记以及个人回忆分别记述各个议题的要点。因时间以及本人能力有限，一些错误难免，还请行家多多指正。\n云原生服务的爆炸半径 个人理解，黄的这个议题属于云原生应用架构范畴。\n其演讲内容首先从亚马逊 AWS 十年前的一个故障说开：AWS 某服务的配置中心是一个 CP 系统，一次人为的网络变更导致配置中心的冗余备份节点被打垮，当运维人员紧急恢复变更后，由于配置中心不可用【有效副本数少于一半】导致了整个存储系统其他数据节点认为配置数据一致性不正确拒绝服务，最终导致整个系统服务崩溃。\n复盘整个事故的直接原因是：CAP 定理对可用性和一致性的定义限定非常严格，并不适合应用于实际的生产系统。因此作为线上控制面的配置中心的数据应该在保证最终一致性的前提下，首先保证可用性。\n更进一步，现代分布式系统的人为操作错误、网络异常、软件 Bug、网络/存储/计算资源耗尽等都是不可避免的，分布式时代的设计人员一般都是通过各种冗余【如多存储分区、多服务副本】手段保证系统的可靠性，在不可靠的软硬件体系之上构建可靠的服务。\n但是这中间有一个误区：有时候一些冗余手段可能因为雪崩效应反而会导致系统可靠性地降低。如上面的事故，人为的配置错误导致了一连串的软件体系故障，且这些故障之间是高度强相关的，最终导致了雪崩效应，可以称之为 “水平扩展的毒药效应”。此时思考的维度就从 “在不可靠软硬件体系上提供可靠服务” 进一步拓展为 “通过各种隔离手段减小事故的爆炸半径”：当不可避免的故障发生时，尽量把故障损失控制到最小，保障在可接受范围内，保证服务可用。\n针对这个思路，黄给出了如下故障隔离手段：\n 服务粒度适中 微服务的服务粒度并不是拆分的越细越好。如果服务粒度过细，会导致服务数量过多，其第一个后果就是导致一个组织内几乎无人能搞清楚服务整体逻辑的来龙去脉，增加维护人员的负担：大家只敢小修小补无人敢做出大幅度的优化改进。\n服务粒度过细的第二个后果是造成整体微服务单元体指数级增加，造成容器编排部署成本上升。适中的服务粒度要兼顾架构体系的进化与部署成本的降低。\n 充分隔离 进行服务编排时，获取数据中心的电源和网络拓扑信息，保证强相关系统之间部署做到 “不远” 且 “不近”。\n“不近”是指同一个服务的副本不在使用同一个电源的同一个机柜部署，也不在使用了同一个网络平面的 Azone 内部署。“不远” 是指部署距离不能太远，例如多副本可以同城多 IDC 部署。使用这两个原则兼顾性能与系统可靠性。\n 随机分区 、所谓的随机分区这块，其实质就是在混合服务请求，保证某个服务的请求可以走多通道【队列】，保证在某些通道挂掉的情况下不影响某个服务的请求处理，应用随机分区技术，将用户打散在多个 Cell 中，大幅度降低爆炸半径。\n与 K8s APF 公平限流算法中的洗牌分片（Shuffle Sharding）颇为相似。\n 混沌工程 通过持续内化的混沌工程实践，提前踩雷，尽量减少 “故障点”，提升系统可靠性。\n使用 SkyWalking 监控 Kubernetes 事件 这个议题虽然被安排在第三场演讲，属于云原生交付运维体系，但是与上个议题关联性比较强，所以先在此记述。\n如何提升 K8s 系统的可观测性，一直是各大云平台的中心技术难题。K8s 系统可观测性的基础数据是 K8s event，这些事件包含了 Pod 等资源从请求到调度以及资源分配的全链路信息。\n SkyWalking 提供了 logging/metrics/tracing 等多维度可观测性能力，原来只是被用于观测微服务系统，今年提供了 skywalking-kubernetes-event-exporter 接口，专门用于监听 K8s 的 event，对事件进行提纯、收集、发送至 SkyWalking 后端进行分析和存储。\n 柯同学在演讲过程中花费了相当多的精力演讲整个系统的可视化效果如何丰富，个人感兴趣的点如下图所示：以类似于大数据流式编程的手段对 event 进行过滤分析。\n 其可视化效果与流式分析手段都是蚂蚁 Kubernetes 平台可借鉴的。\n快手中间件mesh化实践 快手的姜涛在这个议题中主要讲解了快手 Service Mesh 技术的实践。\n 姜把 Service Mesh 分为三个世代。其实划分标准有很多，如何划分都有道理。很明显，姜把 Dapr 划入了第三个世代。\n 上图是快手的 Service Mesh 架构图，很明显借鉴了 Dapr 的思想：下沉基础组件的能力到数据平面，把请求协议和接口标准化。一些具体的工作有：\n 1 统一运维，提高可观测性与稳定性，进行故障注入和流量录制等 2 对 Enovy 等做了二次开发，只传输变更的数据、按需获取，解决单实例服务数过多的问题 3 对协议栈和序列化协议做了大量的优化 4 实施了面向失败设计，Service Mesh 可以 fallback 为直连模式 个人感兴趣的是姜提到了 Service Mesh 技术在快手落地时面临的三个挑战：\n 成本问题：复杂环境下的统一部署与运维。 复杂度问题：规模大、性能要求高、策略复杂。 落地推广：对业务来说不是强需求。 特别是第三个挑战，Service Mesh 一般的直接收益方不在业务端，而是基础架构团队，所以对业务不是强需求，而且快手这种实时业务平台对性能非常敏感，Service Mesh 技术又不可避免地带来了延迟的增加。\n为了推动 Service Mesh 技术的落地，快手的解决手段是：\n 1 首先务必保证系统稳定性，不急于铺开业务量； 2 搭车公司重大项目，积极参与业务架构升级； 3 基于 WASM 扩展性，与业务共建； 4 选取典型落地场景，树立标杆项目。 姜在最后给出了快手下半年的 Service Mesh 工作：\n 很显然这个路线也是深受 Dapr 影响，理论或者架构上创新性不大，更侧重于对开源产品进行标准化并在快手落地。\n在演讲中姜提到了 Serivce Mesh 技术落地的两个标杆：蚂蚁集团和字节跳动。其实他们成功的很重要原因之一就是高层对先进技术的重视以及业务侧的大力配合。 …","date":1629183600,"description":"2021 年云原生技术发展现状及未来趋势","dir":"blog/2021-cloud-native-technology-development-status-and-future-trends/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ee44d71749f600f689656893c5b607af","permalink":"https://sofastack.github.io/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","publishdate":"2021-08-17T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","summary":"个人有幸担任了 2021 年 GIAC 会议云原生专场的出品人兼讲师，组织了前后四个场子的演讲，在这个过程中个人同时作为听众从这些同行的演讲中学到了很多非常有用","tags":["SOFAStack"],"title":"2021 年云原生技术发展现状及未来趋势","type":"blog","url":"/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","wordcount":3976},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙运盛 提问：\n 我想咨询大家一个问题，假如二阶段提交或者回滚的方法里，再发生异常的话，应该如何处理呢？\n A：这个异常后，重新捞取之前没结束的事务，重试就可以了吧，二阶段反正已经不阻塞其它一阶段的流程了。\nSeata：https://github.com/seata/seata\n2、@胡希国 提问：\n 我想请教一个问题，这里 New MOSN 收到 Old MOSN 传来的监听文件描述符之后，利用 filelistener 函数产生一个 listener 的作用是和 bind 一样么？就在 New MOSN 上开始监听了是吗？那这时候 Old MOSN 不也同时在监听么，这里的内部逻辑是什么样的？\n A：跟 bind 不一样，这儿是同一个 fd，两个进程都监听，常规操作。你可以想象成 Nginx 的多个进程都可以监听一个 listen 一样。\nMOSN：https://github.com/mosn/mosn\n3、@胡希国 提问：\n MOSN 的 forkexec 是个怎么样的方式呢？它也和 Envoy 一样有一个独立的 python（envoy）进程来负责产生新的 MOSN 进程么？\n A：MOSN 启动起来之后检查到有 socket 文件，然后和 Old MOSN 通信继承 fd，继承完了通知 Old MOSN 退出，所以你可以直接启动一个 MOSN 来。\nMOSN：https://github.com/mosn/mosn\n4、@胡希国 提问：\n 想请问下 MOSN 实现的过程为什么没有采用直接 fork 父进程的方式呢？\n A：容器间升级是不能 fork 的。\nMOSN：https://github.com/mosn/mosn\n5、@ch 提问：\n 今天发生了一个 rollback status: TimeoutRollbacking 超时问题。 描述: Seata 提示 rollback status: TimeoutRollbacking。 出现原因：全局事务在执行 order 库和 account 库，因为 account 库被 IO 堵死 导致业务超时执行了 70s。 然后 Seata 就报 timeout 导致 order 库回滚了数据 account 没有回滚数据（account 已经被 IO 流撑死,无法读写数据）。 版本：client 1.3.0 server 1.3.0。\n A：account 没有回滚诗句，tc 会重试。回滚事务，只要注册了的事务就一定能回滚，没注册的本地事务就会回滚，所以其实没有任何问题。\nSeata：https://github.com/seata/seata\nSOFAStack \u0026amp;amp; MOSN：新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发，但是不知道从何下手“的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing！\nLayotto 新手任务：\n 支持运行多个 Wasm 模块，以便让 Layotto 成为 FaaS 容器；\n 提供 Dockerfile，以便用户用 docker 部署 Layotto；\n 看懂 Wasm 模块的实现并为 Wasm 模块编写单元测试。\n 详见 ：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1628838000,"description":"SOFA Weekly | SOFAStack \u0026 MOSN：新手任务计划，QA 整理","dir":"blog/sofa-weekly-20210813/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"84929b0bd678bf23739507e3920d0293","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210813/","publishdate":"2021-08-13T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210813/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAStack \u0026 MOSN：新手任务计划，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210813/","wordcount":1357},{"author":"郑志雄（纶珥）","categories":"SOFAStack","content":" 背景 微服务架构带来很多好处的同时也让系统的复杂度提升了，传统的单体应用按照不同的维度拆分成一个一个分布式微服务，不同的微服务甚至可能采用不同的语言编写；此外，服务的部署往往都是分布式的，可能有几千台服务器，横跨多个不同的城市数据中心。下图是一个典型的微服务架构，图中的节点数还比较少，在支付宝，一个线下支付整体交易付款链路，涉及上百个节点。\n 图片来源：https://www.splunk.com/en_us/data-insider/what-is-distributed-tracing.html#benefits-of-distributed-tracing\n微服务化引入了以下几个典型问题：\n 故障定位难，一次请求往往需要涉及到多个服务，排查问题甚至需要拉上多个团队;\n 完整调用链路梳理难，节点调用关系分析;\n 性能分析难，性能短板节点.\n 以上这几个问题其实都是应用的可观测性问题：\n Log；\n Trace；\n Metrics。\n 本文将会专注于 Trace 方面，完整地说是分布式链路跟踪 (Distributed tracing)。2010 年谷歌发表了 Dapper 的论文，分享了他们的解决方案，算是业界比较早的分布式链路追踪系统。之后各大互联网公司纷纷参照 Dapper 的思想推出各自的链路跟踪系统，包括 Twitter 的 Zipkin、阿里的鹰眼，还有 PinPoint，Apache 的 HTrace 和 Uber 的 Jaeger；当然，也有我们的本文的主角：SOFATracer。分布式链路的实现有多种多样，因此也催生了分布式链路追踪的规范：OpenTracing，2019 年 OpenTracing 和 OpenCensus 合并成为了 OpenTelemetry。\nOpenTracing 在深入 SOFATracer 之前先简单解释一下 OpenTracing，因为 SOFATTracer 是基于 OpenTracing 规范（基于 0.22.0 的 OpenTracing，新版的规范 API 有所不同）构建的。一个 Trace 由服务调用生成的 Span 及其之间的引用构成，一个 Span 是一个时间跨度，一次服务调用创建一个新 Span，分为调用 Span 和被调 Span，每个 Span 包含：\n TraceId and SpanId\n 操作名称\n 耗时\n 服务调用结果\n 一个 Trace 链路中一般会有多个服务调用，那么也就会有多个 Span，Span 之间的关系由引用声明，引用从调用者指向服务提供者，OpenTracing 中指定了两个引用类型：\n ChildOf，同步服务调用，客户端需要服务端的结果返回才能进行后续处理；\n FollowsFrom，异步服务调用，客户端不等待服务端结果。\n 一个 Trace 是一个有向无环图，一次调用的拓扑可以如下展示：\n 图中的 SpanContext 是一次请求中会共享的数据，因此叫做 Span 上下文，一个服务节点在上下文中放入的数据对于后续的所有节点都可见，因此可以用来做信息传递。\nSOFATracer TraceId 生成 TraceId 收集一次请求中的所有服务节点。其生成规则需要避免不同 TraceId 之间的冲突，并且开销不能很高，毕竟 Trace 链路的生成是业务逻辑之外的额外开销。SOFATracer 中的 TraceId 生成规则是：服务器 IP + 产生 ID 时候的时间 + 自增序列 + 当前进程号，比如：\n0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，大家也可以根据这个规律来查找到请求经过的第一个服务器。 后面的 13 位 1403169275002 是产生 TraceId 的时间。 之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。 最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。\n 伪代码如下：\nTraceIdStr.append(ip).append(System.currentTimeMillis()) append(getNextId()).append(getPID()); SpanId 生成 SpanId 记录服务调用拓扑，在 SOFATracer 中：\n 点代表调用深度\n 数字代表调用顺序\n SpanId 由客户端创建\n SOFATracer 中 TraceId 和 SpanId 的生成规则参考了阿里的鹰眼组件\n 合并调用 Span 和被调 Span，结合 TraceId 和 SpanId 就能构建完整的服务调用拓扑：\n Trace 埋点 但是，我们如何生成并获取到 Trace 数据呢？这就得 Trace 采集器（Instrumentation Framework）登场了，其负责：\n Trace 数据的生成、传递和上报\n Trace 上下文的解析和注入\n 并且 Trace 采集器还要做到自动、低侵入和低开销等。典型的 Trace 采集器结构如下，其在业务逻辑之前埋点：\n Server Received (SR), 创建一个新的父 Span 或者从上下文中提取\n 调用业务代码\n 业务代码再次发起远程服务调用\n Client Send (CS) 创建一个子 Span，传递 TraceId、SpanId 和透传数据\n Client Received (CR), 结束当前子 Span，记录/上报 Span\n Server Send (SS) 结束父 Span，记录/上报 Span\n 步骤 3-5 可能没有，也可能重复多次。\n埋点逻辑的实现多种多样，目前主流的有如下几种方式：\n Filter，请求过滤器 (dubbo, SOFARPC, Spring MVC)\n AOP 切面 (DataSource, Redis, MongoDB)\n a.Proxy\nb.ByteCode generating\n Hook 机制 (Spring Message, RocketMQ) Java 语言中，SkyWalking 和 PinPoint 都使用 javaagent 方式做到自动、无侵入埋点。典型的，SOFATracer 实现 Spring MVC 的 Trace 埋点如下：\n SOFATracer 的 Span 100% 创建，只是 log/report 支持采样，相对来说，log/report 的 overhead 更高，更容易在大流量/负载下成为性能瓶颈。而其他 Trace 系统，Span 是采样生成的，但为了在调用出错的情况下能 100% 有 Trace，他们采用了逆向采样的策略。\nSOFATracer 默认把 Trace …","date":1628578800,"description":"蚂蚁集团 SOFATracer 原理与实践","dir":"blog/ant-group-sofatracer-principles-and-practices/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"235d67352aa5a94ae53bf00b4e8c1730","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","publishdate":"2021-08-10T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","summary":"背景 微服务架构带来很多好处的同时也让系统的复杂度提升了，传统的单体应用按照不同的维度拆分成一个一个分布式微服务，不同的微服务甚至可能采用不同","tags":["SOFAStack"],"title":"蚂蚁集团 SOFATracer 原理与实践","type":"blog","url":"/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","wordcount":3268},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定 时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@非余 提问：\n 我有个需求，就是我们有自己的配置中心，我的配置加载不想用默认的文件配置，这里如果我要开发的话应该怎么样加会比较漂亮？\n A：把 config.Load 重写成你自己的配置解析，configmanager.RegisterConfigLoadFunc。\nMOSN：https://github.com/mosn/mosn\n@飒 提问：\n 一个方法先 insert 而后另一个方法 update 事物回滚失败怎么解决？\n A：不会，可能你没有保证写函数被 @GlobalTransactional 注解覆盖或建表语句不是最新的导致了你回滚顺序变了。\nSeata：https://github.com/seata/seata\n@飒 提问：\n A 服务使用了 @GlobalTransactional（rollbackFor = Exception.class），调用了 B 服务，B 服务报错了，结果都提交成功，数据库数据也更新了，一般是什么原因？\n A：应该是你被调用的服务，没有加入到全局事务中去（也就是说，被调用的服务没加上 @GlobalTransactional）。\nSeata：https://github.com/seata/seata\n@冯仁彬 提问：\n 被调用的服务也必须添加 @GlobalTransactional?\n A：被调用的服务如果自身不会有任何地方访问自己身的写库方法，那么仅需集成 Seata，如果自身有，那么自身的写库操作全部要被带有 @GlobalTransactional 注解的地方调用，至于这个入库你自己设计。\nSeata：https://github.com/seata/seata\n本周推荐阅读 KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周发布详情如下：\n本周 MOSN 发布了 v0.24.0 版本。主要更新如下：\n 支持 jaeger tracing；\n grpc 框架支持热升级；\n 变量机制支持 interface 类型的变量；\n 路由模块优化，支持端口匹配、支持变量模式；\n 负载均衡模块多处优化；\n 其他优化与 Bug Fix。\n 详细发布报告：https://github.com/mosn/mosn/releases/tag/v0.24.0\n更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1628233200,"description":"SOFA WEEKLY | MOSN 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210806/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"29e513237a11de947612fdc004f8ddde","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210806/","publishdate":"2021-08-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210806/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210806/","wordcount":1125},{"author":"柴树杉","categories":"SOFAStack","content":" 楔子: 以蚂蚁典型的建站场景为例，在接入 Kusion 后，用户侧配置代码减少到 5.5%，用户面对的 4 个平台通过接入统一代码库而消减，在无其他异常的情况下交付时间从 2 天下降到 2 小时……\n注：本文是柴树杉在 2021 GIAC 大会上分享的内容。相关 PPT 内容请点击下方自行下载\n GIAC 大会 PPT 下载：KCL声明式的云原生配置策略语言 \n0. 你好GIAC 大家好，我是来自蚂蚁的同学，很高兴能在GIAC的编程语言新范式板块和大家分享《KCL配置策略语言》。KCL语言是蚂蚁内部的Kusion解决方案中针对云原生基础设施配置代码化自研的DSL语言，目前已经在建站场景等一些场景开始小范围推广试用。\n我们先看一下简单的KCL代码：\nschema GIACInvitation[name: str]: Name: str = name Topic: str = \u0026amp;quot;分享主题\u0026amp;quot; Company?: str = None Type: str = \u0026amp;quot;分享嘉宾\u0026amp;quot; Address: str = \u0026amp;quot;深圳\u0026amp;quot; invitation = GIACInvitation(\u0026amp;quot;姓名\u0026amp;quot;) { Topic: \u0026amp;quot;KCL配置策略语言\u0026amp;quot; Company: \u0026amp;quot;蚂蚁集团\u0026amp;quot; } 这个例子代码先通过 schema 定义了一个 GIACInvitation 结构体：该结构体有一个 str 类型的 name 参数，同时还有一组标注了类型和默认值的属性。然后通过声明式的语法构造了GIACInvitation 的实例 invitation。\n这个例子虽然简单，但是包含了 KCL 最重要的 schema 语言结构。从例子可以看出 KCL 尝试通过声明式的语法、静态类型检查特性来改进配置代码的编写和维护工作。这也是设计 KCL 语言的初衷，我们希望通过编程领域成熟的技术理论来解决云原生领域的配置代码化的问题。\n1. KCL语言的诞生背景 在经典的 Linux/UNIX 操作系统中，我们通过 Shell 和系统内置的各种工具和内核进行交互，同时通过 Shell 脚本来管理更上层的 App。可以说 Shell 语言极大地简化了内核的编程界面，不仅仅提升了操作系统易用性也简化了上层 App 的管理和运维，也提高了生产效率。而 Kubernetes 作为容器管理领域的事实标准，已经成为云计算时代的Linux/UNIX。类比 UNIX 系统，Kubernetes 目前还缺少一种符合其声明式、开放、共享设计理念的交互语言及工具。\n 1.1 为何要设计KCL语言？ K8s已经成为云计算的操作系统，但是目前尚缺少功能完备的SHELL交互界面。目前虽然有很多而且开源方案，但是还没有像UNIX的Shell那种出现比较成熟的方案，特别是尚无法满足头部互联网企业大规模工程化的要求。云原生技术与企业落地之间存在Gap需要填补，这正是云原生工程化要解决的问题，也是设计KCL语言的出发点。\n1.2 目前是一个好时机 云原生的思路是高度的开放化和民主化，结果就是万物可配置，一切配置都是代码。带配置代码面前人人平等，每个用户都可以通过调整配置代码和基础平台设施进行交互。因此对配置的编写和维护正在成为云计算时代软件工程师的必备的技能和需求。基于对云原生配置代码化需求的日益旺盛，硅谷的诸多头部公司已经对这个方向进行了大规模的实践和验证，这些都给了我们大量可以参考的经验。\n因此蚂蚁的 Kusion 项目尝试通过 KCL 配置策略语言正是为了简化云原生技术设施的接入方式设计，其设计目标不仅仅是为了提升蚂蚁基础设施的开放程度及使用效率，同时希望能够优化共享、协同的开发流程，可以说其定位正是云原生时代的 Shell 语言。虽然目前还处于探索和实践阶段，我们通过此文和大家分享下 KCL 语言的设计与实现的一些理念，为云原生的快速到来贡献一点绵薄之力。\n1.3 KCL诞生历史 KCL 语言从2019年开始初期的调研和设计工作。到2020年3月发布kcl-0.1，基于Python定制语法，采用Go版本的Grumpy和AntLR等工具开发。2020年下半年改用Python语言并加快了开发和迭代速度，发布的kcl-0.2.x引入了大量语言特性、增加了Plugin扩展支持、同时支持IDEA插件。2021年上半年开始统一优化和整合语言特性，发布的kcl-0.3优化类型系统、集成单元测试工具、优化执行性能并提供了Go等多语言的API支持、同时通过LSP为VSCode提供支持。2021年下半年开始在建站等常见落地，同时引入静态类型检查和优化性能，完善语言的文档支持。\n2. KCL语言的设计原则 基于蚂蚁践行多年的经典运维中台沉淀的经验和对各种问题利弊的思考，Kusion 项目对如何充分利用云原生技术带来的红利，打造一个开放、透明、声明式、可协同的运维体系进行了探索和思考，提出并实践了基于基础设施代码化的云原生协同开发的模型。而 KCL 语言正是 Kusion 项目为了解决云原生协同开发而设计的声明式的配置编程语言，简单、稳定、高效和工程化是 KCL 语言设计的设计理念。\n 2.1 简单为王 简单不仅仅可以降低学习和沟通的成本，而且可以减少代码出问题的风险。不论是 UNIX 奉行的 KISS 原则还是 Go语言推崇的 Less is more 设计理念，简化易用的界面始终是各种成功产品追求的一个目标。同样从简单原则出发，KCL 语言在参考现代编程语言之上只保留了必要的元素，同时通过类型自动推导、引入受限的控制流和 schema 提供了基础灵活的配置定义编写能力，删减语言特性始终是 KCL 语言设计工作的一个重要目标。\n2.1.1 声明式语法 声明式编程是和命令式编程并列的一种编程范式，声明式编程只告诉你想要的结果，执行引擎负责执行的过程。声明式编程使用更加简单，可以降低命令式拼装造成的复杂性和副作用，保持配置代码清晰可读，而复杂的执行逻辑已经由 Kubernetes 系统提供支持。KCL 语言通过简化对 schema 结构体实例化的语法结构对声明式语法提供支持，通过仅提供少量的语句来减少命令过程式编程带来的复杂性。 围绕 schema 和配置相关的语法，KCL 希望每种配置需求尽可能通过固定的写法完成，使得配置代码尽可能的统一化。\n比如作为 KCL 声明式语法的核心结构 schema 可以采用声明式方式实例化：\nschema Name: firstName: str lastName: str schema Person: name: Name = { firstName: \u0026amp;quot;John\u0026amp;quot; lastName: \u0026amp;quot;default\u0026amp;quot; } JohnDoe = Person { name.lastName: \u0026amp;quot;Doe\u0026amp;quot; } 首先通过schema定义了一个 Name 结构，结构包含2个字符串类型的必填属性。然后在 Person 中复用 Name 类型声明一个name属性，并且给name属性设置了默认值以简化用户使用。最终 …","date":1627974000,"description":"KCL：声明式的云原生配置策略语言","dir":"blog/kcl-a-declarative-cloud-native-configuration-policy-language/","fuzzywordcount":8200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"30b5034f7ce40b32a13a09cfe141b101","permalink":"https://sofastack.github.io/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","publishdate":"2021-08-03T15:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","summary":"楔子: 以蚂蚁典型的建站场景为例，在接入 Kusion 后，用户侧配置代码减少到 5.5%，用户面对的 4 个平台通过接入统一代码库而消减，在无其他异常的情况下交","tags":["SOFAStack"],"title":"KCL：声明式的云原生配置策略语言","type":"blog","url":"/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","wordcount":8120},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张鹏 提问：\n 比如我在新模块中添加 Service 实现，宿主应用没有调用相关的 Service 啊，我其实想实现代码的热部署通过 SOFAArk 可以？\n A：可以动态部署的（所有的 bean 会刷新，服务会发布），跟宿主应用有没有调用没有关系的。\nSOFAArk：https://github.com/sofastack/sofa-ark\n2、@周永平 提问：\n 我想请教下，SOFABoot 如果使用 Spring 的 event，跨模块会被通知到吗？\n A：默认情况下，Spring 事件只在本模块中，不会传递的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@孙力 提问：\n 蚂蚁内部与 MOSN 对应的应该是有统一的控制面吗？其中熔断限流组件是使用的 sentinel 吗？控制面与 MOSN 中的 sentinel-client 对接更新限流规则，使用的 sentienl 的 dynamic-rule，还是 xds 下发的？\n A：我们内部是有统一的控制面的，我们的限流熔断算法是基于 sentinel 去扩展实现的，底层的限流框架是基于 sentinel 的，更新规则时我们用的是我们内部的一套配置管理中间件。\nMOSN：https://github.com/mosn/mosn\n4、@孟晓冬 提问：\n 目前的问题是，Dubbo 应用在注入 MOSN 时，MOSN 启动时，要么报权限问题，要么报各种 not support，想请教一下是什么原因？\n A：你用的 1.7.x 的 Istio 的话，那要用对应分支的 MOSN 版本镜像。\nMOSN：https://github.com/mosn/mosn\n本周发布 本周 Layotto 发布了 v0.1.0\n这是 Layotto 的第一次发布，包含功能：\n 支持 configuration API\n 支持 pubsub API\n 支持 state API\n 支持 distributed lock API\n 支持 sequencer API\n 支持 rpc API\n 支持通过 4 层或者 7 层进行流量治理（例如 dump 流量,限流等功能)\n 支持 Actuator API，用于健康检查和运行时元数据查询\n 支持集成 Istio\n 支持基于 WASM 进行多语言编程\n Go sdk\n 感谢各位贡献者这段时间的付出！\n详细参考：https://github.com/mosn/layotto/\n文章解读： https://mosn.io/layotto/#/zh/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/index\n本周 SOFABoot 发布了 3.8.0 版本。主要更新如下：\n 支持 JDK11\n 添加 proxyBeanMethods=false 字段在 @Configuration 类上\n 调整 SOFARPC 注解的超时优先级\n 修复 Ark 环境处理注解时抛出 TypeNotPresentExceptionProxy 异常的问题\n 详细参考： https://github.com/sofastack/sofa-boot\n本周推荐阅读 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 还在为多集群管理烦恼吗？OCM来啦！\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1627628400,"description":"SOFA Weekly | Layotto、SOFABoot 发布新版本、QA 整理","dir":"blog/sofa-weekly-20210730/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa875b307e883aea56f46eab071f52d0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210730/","publishdate":"2021-07-30T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210730/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto、SOFABoot 发布新版本、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210730/","wordcount":1199},{"author":"祝辰（忘禅）","categories":"SOFAStack","content":" 开篇 这篇文章是基于SOFA Meetup合肥站的分享总结，主要针对于注册中心的定位以及功能介绍，通过对蚂蚁注册中心发展史的分析，带领大家了解，蚂蚁的注册中心是如何一步一步演变为现在的规模和特性的。\n更多深入的技术细节，欢迎大家加入到SOFA和SOFARegistry的社区中，探寻结果。\n注册中心是什么 服务发现 \u0026amp;amp; 服务注册 注册中心简单来说，是为了解决分布式场景下，服务之间互相发现的问题。\n如下图所示，服务A想要调用服务B的时候，需要知道B的地址在哪里，如何解决这个问题？\n 一般来说，分为两个点：\n 服务发现可以有一个中心化的组件或者说是存储，它承载了所有服务的地址，同时提供出来一个可供查询和订阅的能力，服务的消费方可以通过和这个中心化的存储交互，获取服务提供方的地址列表。 服务注册：同样是上文中中心化的组件，但是，这个时候的服务信息可以有两种措施 服务连接注册中心，同时上报自身的服务以及元数据（也是今天本文讲述的重点） 有一个集中的控制面（control plane）将用户定义的服务和IP的映射写入注册中心，例如AWS的CloudMap 调用流程 如上图所示，就是目前一种主流的注册中心模式，SOFARegistry和Nacos都是这种模式。\n 服务A，服务B通过SDK或者REST将自身的服务信息上报给注册中心 服务A需要调用服务B的时候，就对注册中心发起请求，拉取和服务B相关的服务IP列表以及信息 在获取到服务B的列表之后，就可以通过自身定义的负载均衡算法访问服务B 心跳 心跳是注册中心用于解决服务不可用时，及时拉出服务降低影响的默认方式，如下图所示\n 服务B的一个节点断网或是hang住，引发心跳超时；或是宕机、断链直接引发心跳失败 注册中心把问题节点从自身的存储中拉出（这里拉出根据具体实现：有的是直接删除，有的是标记为不健康） 服务A收到注册中心的通知，获取到服务B最新的列表 DUBBO 注册中心 下面通过DUBBO的例子，我们来看一下注册中心是如何使用的，以及流程\n首先，DUBBO在2.7和3.0中的配置略有不同，但是都是简单易懂的，这里都放上来\nDUBBO-2.7\n DUBBO-3.0\n 在RPC客户端只需要配置一个注册中心的地址即可，地址中包含了基础三元素\n protocol（协议类型）比如，zookeeper host port 基于此，dubbo的注册流程如下图所示\n 服务的生产方通过DUBBO客户端向注册中心（Registry）发起注册行为（register） 服务的消费方通过DUBBO客户端订阅信息（subscribe） 注册中心通过通知的方式，下发服务列表给服务消费方 注册中心的本质 通过前文的讲解，以及DUBBO组件的具体例子，我们大概可以归纳注册中心的本质\n“存储” + “可运维”\n 一方面，注册中心需要存储能力去记录服务的信息，比如应用列表 另一方面，注册中心在实践过程中，需要提供必需的运维手段，比如关闭某一服务流量 蚂蚁注册中心编年史 史前时代 史前时代的蚂蚁是相当久远的架构，当时所有的服务部署在同一台物理机上或者JVM上，服务之间不存在有跨机器调用的场景，这里略过不表\n 硬负载时代 后来，为了解决应用之间的耦合带来的部署难，运维难问题，我们对服务进行了拆分，拆分后的服务，遇到了一个问题，就是如何处理服务之间的调用关系，这个时候，蚂蚁用了两种硬负载 F5 或是 LVS。\n通过简单的4层代理，我们可以把服务部署在代理的后面，服务与服务之间通过代理互相访问，达到了跨机调用的目的\n 第一代注册中心 \u0026amp;ndash; 硬负载到软负载的演变 通过硬负载访问的方式，一方面解决了服务之间互相调用的问题，部署架构也简单易懂；另一方面，在业务快速增长之后，却带来了一定的问题：\n 单点的问题（所有调用都走F5的话，F5一旦挂了，很多服务会不可用） 容量问题（F5承载的流量太高，本身会到一个性能瓶颈） 这个时候，蚂蚁引进了阿里集团的一款产品叫ConfigServer，作为注册中心进行使用，这个注册中心的架构就和开头提到的架构很像了，服务之间可以通过IP直接访问，而降低了对负载均衡产品的强依赖，减少了单点风险。\n 第二代注册中心 \u0026amp;ndash; ScaleUp？ScaleOut？It\u0026amp;rsquo;s a problem 但是，问题还在持续，那就是注册中心，本身是一个单点，那么，他就会继续遇到上文中所说的两个问题\n 单点风险（注册中心本身是单机应用） 容量瓶颈（单台注册中心的连接数和存储数据的容量是有限的） 解决的方式有两种\n scale-up（淘宝）：通过增加机器的配置，来增强容量以及扛链接能力；同时，通过主-备这样的架构，来保障可用性 scale-out（蚂蚁）：通过分片机制，将数据和链接均匀分布在多个节点上，做到水平拓展；通过分片之后的备份，做到高可用 蚂蚁和淘宝走了两条不同的路，也推进了蚂蚁后面演进出一套独立的生态系统\n蚂蚁的演进架构如下，产生了两种不同的应用节点\n session节点，专门用来抗链接使用，本身无状态可以快速扩展，单机对资源的占用很小 data节点，专门用来存储数据，通过分片的方式降低单个节点的存储量，控制资源占用 第五代注册中心 \u0026amp;ndash; Meta节点的诞生 上面的架构已经很符合目前主流的分布式架构了，但是在运维过程中，产生了一系列问题，比如\n 所有data都是分布式的，data之间的服务发现需要通过启动时给定一个配置文件，这样就和标准运维脱钩 data节点的上下线需要去及时修改配置文件，否则集群重启会受到影响 分布式存储一致性问题，每次迭代发布，需要锁定paas平台，防止节点变动带来的不一致 所有这些问题的产生，我们发现可以引入一个元数据管理中心（Meta）节点来，解决对data和session管理的问题，data和session通过4层负载或是7层负载对meta访问即可.\n对比业界的解决方案，都有类似的模型，比如HDFS的Name Node、Kafka依赖于ZK，Oceanbase依赖于RootServer 或者 配置中心Apollo依赖于Euraka。\nMeta节点的出现，缓解了手工运维注册中心的瓶颈，但是，依然没有从根本上解决问题，那么问题在哪里？详见下文分析。\n 第六代注册中心 \u0026amp;ndash; 面向运维的注册中心 上文说道，Meta节点的出现，承接了Data以及Session之间服务发现的问题，但是，丛云未测来讲，还是有很多问题解决不了，比如\n Data节点的发布在数据量大的前提下，依然是个痛点 Session节点的新加节点上，可能很久都没有流量 等等，对于这些问题，在SOFARegistry5.x的基础上，我们快速迭代了6.0版本，主要是面向运维的注册中心。\nData节点发布难的问题，说到底是一个影响范围的问题，如何控制单一data节点发布或者挂掉对数据的影响面，是解决问题的本源，这里我们采用了两个措施\n 改进数据存储算法（consistent-hash -\u0026amp;gt; hash-slot） 应用级服务发现 存储算法的演进 之前我们使用了一致性hash的算法，如下图所示， …","date":1627369200,"description":"我们做出了一个分布式注册中心","dir":"blog/we-made-a-distributed-registry/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"991c52c34e8dc2370ae08263b297cbe0","permalink":"https://sofastack.github.io/sofastack.tech/blog/we-made-a-distributed-registry/","publishdate":"2021-07-27T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/we-made-a-distributed-registry/","summary":"开篇 这篇文章是基于SOFA Meetup合肥站的分享总结，主要针对于注册中心的定位以及功能介绍，通过对蚂蚁注册中心发展史的分析，带领大家了解，","tags":["SOFAStack"],"title":"我们做出了一个分布式注册中心","type":"blog","url":"/sofastack.tech/blog/we-made-a-distributed-registry/","wordcount":4390},{"author":"","categories":"SOFAStack","content":" 蚂蚁集团运维着可能是全球最大的 K8s 集群：K8s 官方以 5k node 作为 K8s 规模化的顶峰，而蚂蚁集团事实上运维着规模达到 10k node 规模的 K8s 集群。一个形象的比喻就是，如果官方以及跟着官方的 K8s 使用者能想象到的 K8s 的集群规模是泰山，那么蚂蚁集团在官方的解决方案之上已经实现了一个珠穆朗玛峰，引领了 K8s 规模化技术的提升。\n这个量级的差异，不仅仅是量的差异，更是 K8s 管理维护的质的提升。能维护有如此巨大挑战巨量规模的 K8s 集群，其背后原因是蚂蚁集团付出了远大于 K8s 官方的优化努力。\n所谓万丈高楼平地起，本文着重讨论下蚂蚁集团的在 K8s 的基石 \u0026amp;mdash; etcd 层面做出的高可用建设工作：只有 etcd 这个基石稳当了，K8s 这栋高楼大厦才保持稳定性，有 tidb 大佬黄东旭朋友圈佐证【图片已获黄总授权】。\n 面临的挑战 etcd 首先是 K8s 集群的 KV 数据库。 从数据库的角度来看，K8s 整体集群架构各个角色如下：\n etcd 集群的数据库\n kube-apiserver etcd 的 API 接口代理、数据缓存层\n kubelet 数据的生产者和消费者\n kube-controller-manager 数据的消费者和生产者\n kube-scheduler 数据的消费者和生产者\n etcd 本质是一个 KV 数据库，存储了 K8s 自身资源 、用户自定义的 CRD 以及 K8s 系统的 event 等数据。每种数据的一致性和数据安全性要求不一致，如 event 数据的安全性小于 K8s 自身的资源数据以及 CRD 数据。\nK8s 的早期拥护者在推广 K8s 时，宣称其比 OpenStack 的优势之一是 K8s 没有使用消息队列，其延迟比 OpenStack 低。这其实是一个误解，无论是 etcd 提供的 watch 接口，还是 K8s client 包中的 informer 机制，无不表明 K8s 是把 etcd 当做了消息队列，K8s 消息的载体很多，譬如 K8s event。\n从消息队列的角度来看，K8s 整体集群架构各个角色如下：\n etcd 消息路由器\n kube-apiserver etcd 生产者消息代理和消息广播【或者成为次级消息路由器、消费者代理】\n kubelet 消息的生产者和消费者\n kube-controller-manager 消息的消费者和生产者\n kube-scheduler 消息的消费者和生产者\n etcd 是推模式的消息队列。etcd 是 K8s 集群的 KV 数据库和消息路由器，充当了 OpenStack 集群中的 MySQL 和 MQ 两个角色，这样的实现貌似简化了集群的结构，但其实不然。在 large scale 规模 K8s 集群中，一般经验，首先都会使用一个单独 etcd 集群存储 event 数据：把 KV 数据和一部分 MQ 数据物理隔离开，实现了 KV 和 MQ 角色的部分分离。 如 参考文档 2 中提到美团 “针对 etcd 的运营，通过拆分出独立的 event 集群降低主库的压力”。\n当 K8s 集群规模扩大时，etcd 承载着 KV 数据剧增、event 消息暴增以及消息写放大的三种压力。 为了证明所言非虚，特引用部分数据为佐证：\n etcd KV 数据量级在 100 万以上；\n etcd event 数据量在 10 万以上；\n etcd 读流量压力峰值在 30 万 pqm 以上，其中读 event 在 10k qpm 以上；\n etcd 写流量压力峰值在 20 万 pqm 以上，其中写 event 在 15k qpm 以上；\n etcd CPU 经常性飙升到 900% 以上；\n etcd 内存 RSS 在 60 GiB 以上；\n etcd 磁盘使用量可达 100 GiB 以上；\n etcd 自身的 goroutine 数量 9k 以上；\n etcd 使用的用户态线程达 1.6k 以上；\n etcd gc 单次耗时常态下可达 15ms。\n 使用 Go 语言实现的 etcd 管理这些数据非常吃力，无论是 CPU、内存、gc、goroutine 数量还是线程使用量，基本上都接近 go runtime 管理能力极限：经常在 CPU profile 中观测到 go runtime 和 gc 占用资源超过 50% 以上。\n蚂蚁的 K8s 集群在经历高可用项目维护之前，当集群规模突破 7 千节点规模时，曾出现如下性能瓶颈问题：\n etcd 出现大量的读写延迟，延迟甚至可达分钟级；\n kube-apiserver 查询 pods / nodes / configmap / crd 延时很高，导致 etcd oom；\n etcd list-all pods 时长可达 30 分钟以上；\n 2020 年 etcd 集群曾因 list-all 压力被打垮导致的事故就达好几起；\n 控制器无法及时感知数据变化，如出现 watch 数据延迟可达 30s 以上。\n 如果说这种状况下的 etcd 集群是在刀锋上跳舞， 此时的整个 K8s 集群就是一个活火山：稍不留神就有可能背个 P 级故障， 彼时的整个 K8s master 运维工作大概是整个蚂蚁集团最危险的工种之一。\n高可用策略 实现一个分布式系统高可用能力的提升，大概有如下手段：\n 提升自身稳定性与性能；\n 精细管理上游流量；\n 保证服务下游服务 SLO。\n etcd 经过社区与各方使用者这么多年的锤炼，其自身的稳定性足够。蚂蚁人能做到的，无非是使出周扒皮的本事，提高集群资源整体利用率，scale out 和 scale up 两种技术手段双管齐下，尽可能的提升其性能。\netcd 自身作为 K8s 的基石，其并无下游服务。如果说有，那也是其自身所使用的物理 node 环境了。下面分别从 etcd 集群性能提升、请求流量管理等角度阐述我们在 etcd 层面所做出的高可用能力提升工作。\n文件系统升级 在山窝里飞出金凤凰，诚非易事。让 etcd 跑的更快这件事，没有什么手段比提供一个高性能的机器更短平快地见效了。\n1.使用 NVMe ssd etcd 自身 = etcd 程序 + 其运行环境。早期 etcd 服务器使用的磁盘是 SATA 盘，经过简单地测试发现 etcd 读磁盘速率非常慢，老板豪横地把机器鸟枪换炮 \u0026amp;mdash; 升级到使用了 NVMe SSD 的 f53 规格的机器：etcd 使用 NVMe ssd 存储 boltdb 数据后，随机写速率可提升到 70 MiB/s 以上。\n参考文档 2 中提到美团 “基于高配的 SSD 物理机器部署可以达到日常 5 倍的高流量访问”，可见提升硬件性能是大厂的首选，能折腾机器千万别浪费人力。\n2.使用 tmpfs NVMe ssd 虽好，理论上其读写极限性能跟内存比还是差一个数量级。我们测试发现使用 tmpfs【未禁止 swap out】替换 NVMe ssd 后，etcd 在读写并发的情况下性能仍然能提升 20% 之多。考察 K8s 各种数据类型的特点后，考虑到 event …","date":1627282800,"description":"蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路","dir":"blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"49c1cbed799517497d7760e5717c5843","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","publishdate":"2021-07-26T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","summary":"蚂蚁集团运维着可能是全球最大的 K8s 集群：K8s 官方以 5k node 作为 K8s 规模化的顶峰，而蚂蚁集团事实上运维着规模达到 10k node 规模的 K8s 集群。一个形象的比喻就是","tags":["SOFAStack"],"title":"蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路","type":"blog","url":"/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","wordcount":7144},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践\n 活动时间：2021 年 07 月 24 日（周六）13:30-17:30\n 活动地点：合肥高新区创新产业园D8栋一楼集思空间\n 活动形式：线下活动\n 资料下载： 《蚂蚁注册中心 SOFARegistry 分享》 《基于API 网关的微服务治理演进与架构实践》 《蚂蚁集团分布式链路组件 SOFATracer 原理与实践》 《准实时的日志聚合平台》 《Service Mesh在蚂蚁集团的实践》\n 本次分享涉及的项目地址\n sofa-registry开箱即用计划 https://github.com/sofastack/sofa-registry/projects/5\nsofa-registry深度解析计划 https://github.com/sofastack/sofa-registry/projects/4\n(这两个计划想帮助对参与开源项目感兴趣的同学由浅入深的上手，成为社区的一员)\nsofa-tracer https://github.com/sofastack/sofa-tracer\nmosn https://github.com/mosn/mosn\n活动介绍 活动议程 本期议题以及嘉宾详解 《蚂蚁注册中心 SOFARegistry 分享》\n嘉宾介绍\n祝辰（花名忘禅），蚂蚁集团技术专家，2020年加入蚂蚁集团致力于服务发现领域的技术建设，开源项目sofa-registry、x-pipe核心开发人员。\n议题简介\n大规模微服务场景下的注册中心：SOFARegistry v6 新特性介绍 SOFARegistry 是蚂蚁集团内部在使用的服务注册中心，它支撑起了蚂蚁集团海量规模的业务服务。 但随着蚂蚁集团业务规模的日渐庞大，SOFARegistry 在资源、容量、运维等方面也遇到了一些挑战，针对这一系列的挑战，我们对 SOFARegistry 进行了大量的改造，开发了 v6 版本的 SOFARegistry。\n项目地址\nsofa-registry开箱即用计划 https://github.com/sofastack/sofa-registry/projects/5\nsofa-registry深度解析计划 https://github.com/sofastack/sofa-registry/projects/4\n(这两个计划想帮助对参与开源项目感兴趣的同学由浅入深的上手，成为社区的一员)\n听众收获\n1、全面了解不同注册中心的设计及架构；\n2、深入了解千万级别微服务场景下服务发现的问题和解法。\n《基于API 网关的微服务治理演进与架构实践》\n嘉宾介绍\n王晔倞，现任API7 VP，Apache APISIX Contributor。公众号「头哥侃码」作者，曾在好买财富、大智慧、中通服软件、东方购物任职，21年IT从业经验，对技术管理和架构设计有一定的经验。TGO 鲲鹏会上海理事会成员，腾讯云TVP，QCon北京2017明星讲师，QCon北京2018优秀出品人。\n议题简介\n内容讲述随着业务的发展，规模扩大，服务颗粒越来越细，数量也越来越多。 我们在过程中有过很多经验和探索，并将系统从一个服务于单个业务方的后台系统逐渐改造成为一个支持海量内容，服务多个业务方，业务规则复杂多变的微服务治理架构。 通过API网关，我们有效协调线上运行的各个服务，保障服务的SLA。基于服务调用的性能KPI数据进行容量管理，并通过对技术中台的升级，对故障进行降级、熔断、限流等一系列升级。\n听众收获\n1、微服务治理当前面临的问题；\n2、API网关在微服务治理中的价值；\n3、从“单体“到”微服务“的转型过程中，该如何使用API网关实现微服务治理。\n《蚂蚁集团分布式链路组件 SOFATracer 原理与实践》\n嘉宾介绍\n郑志雄（花名纶珥），SOFABoot 开源负责人，主要负责蚂蚁集团应用研发框架的开发。\n议题简介\n当下的微服务技术架构，应用的各种服务通常都比较复杂、分布在不同的机器上；同时，这些应用可能又构建在不同的软件模块上，这些软件模块有可能是由不同的团队开发，可能使用不同的编程语言来实现、有可能部署了几千台服务器。为了能够分析应用的线上调用行为以及调用性能，蚂蚁金服基于 OpenTracing 规范，提供了分布式链路跟踪 SOFATracer 的解决方案，帮助理解各个应用的调用行为，并可以分析远程调用性能的组件。\n项目地址\nhttps://github.com/sofastack/sofa-tracer\n听众收获\n1、了解微服务场景下分布式链路组件的作用及价值；\n2、了解蚂蚁集团 SOFATracer 组件的基本原理。\n《准实时的日志聚合平台》\n嘉宾介绍\n吕思泉是思科 Webex 产品线 MATS（媒体分析与问题诊断服务）团队的技术专家，热爱开源，热爱分享，热爱生活，在MATS团队主要工作方向为基础技术的研究与应用，在分布式系统和微服务方面有丰富的经验，由其本人编写并开源的jgossip项目解决了MATS分布式Job Engine的水平扩展难题，由其本人研究并实践的基于Loki+Promtail+Grafana的日志平台大幅度提高了MATS团队在分布式系统日志管理与监控方面的效率。\n议题简介\n简要介绍基于 Loki 的日志可视化套件，以及思科内部如何使用该技术进行监控和告警。\n听众收获\n通过讲师介绍，大家可以了解到一种轻巧灵活的日志聚合系统，帮助开发人员快速定位问题以及实时了解系统状况。\n《Service Mesh 在蚂蚁集团的实践》\n嘉宾介绍\n李唯（良恩），蚂蚁集团技术专家。2017 年加入蚂蚁集团中间件团队。参与了 Service Mesh 在蚂蚁的落地建设，目前主要负责 MOSN 在蚂蚁内部的设计开发。\n议题简介\n随着业务发展，越来越多公司选择了微服务架构，它帮助业务解决了很多问题，但是在实践过程中也不免会遇到一些问题。在这些利与弊的权衡之中，Service Mesh 能够帮助到我们什么呢？本次内容分享 Service Mesh 在微服务的实践中解决的一些问题以及其背后的思考。\n项目地址\nhttps://github.com/mosn/mosn\n听众收获\n1、了解 Service Mesh 在微服务中的实践场景和意义；\n2、了解 Service Mesh 在蚂蚁实践中为业务带来的价值。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1627110000,"description":"SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践","dir":"activities/sofa-meetup-8/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4f05d75ae1c87e74010079dc175e3420","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-8/","publishdate":"2021-07-24T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-8/","summary":"概要 活动主题：SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践 活动时间：2021 年 07 月 24 日（周六）13:30-17:30 活动地点","tags":["SOFAMeetup"],"title":"SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-8/","wordcount":2084},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@王辉 提问：\n SOFARegistry 的 data 节点，连接 meta 节点，为什么设计成随机选择一个节点连接，如果 meta 节点 3 个节点，其中有一个节点挂了，而 data 节点又随机选择到这个挂的节点，就启动失败了。\n A：通过 slb 查询到主节点，然后所有的 session 和 data 都连接 meta 主节点。不是随机连接一个 meta。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n2、@刚刚 提问：\n SOFARPC 是通过 MOSN 转发协议？SOFARPC 对外注册的 IP 在 k8 的容器是什么策略？\n A：MOSN 支持 SOFARPC 协议的转发。服务发布订阅没有做啥特殊的，就和原来是一样的。\nMOSN：https://github.com/mosn/mosn\n3、@证道者 提问：\n Layotto 中 wasm 是怎么设置 cpu 和内存的？\n A：目前官方提供的 Wasm 运行时还不支持对 cpu 内存等资源进行限制，不过我们已经在跟 WasmEdge 社区沟通了，他们是可以支持这种场景的，所以后面同时会支持 WasmEdge 作为 Layotto 的 Wasm 运行时。\nLayotto：https://github.com/mosn/layotto\n3、@Q 提问：\n 两个 tc 节点，就有两套 global，branch，lock 表，当一个事物的调用链中，不同的 rm 连接的是不同的 tc 节点时，是不是会在各自 tc 的 branch 表里生成分支事物啊，这个时候怎么保证一致性呢？\n A：tc 集群无状态的，共用一套 db 数据。\nSeata：https://github.com/seata/seata\n本周推荐阅读 RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n 还在为多集群管理烦恼吗？OCM来啦！\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1627023600,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210723/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2d78986f9ca335444ed265e7bfac0648","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210723/","publishdate":"2021-07-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210723/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210723/","wordcount":972},{"author":"","categories":"SOFAStack","content":" 作者简介：冯泳（花名鹿惊），资深技术专家，拥有西北工业大学计算机科学博士学位，在高性能计算，大数据和云计算领域拥有十多年的设计开发经验，专注于调度，资源和应用管理领域。也深度参与相关开源项目的开发和商业化，例如 OpenStack, Mesos, Swarm, Kubernetes, Spark 等，曾在 IBM 领导过相关的开发团队。\n 前言 在云计算领域如果还有人没听过 Kubernetes，就好像有人不知道重庆火锅必须有辣椒。Kubernetes 已经像手机上的 Android，笔记本上的 Windows 一样成为管理数据中心事实上的标准平台了。围绕着 Kubernetes，开源社区构建了丰富的技术生态，无论是 CI/CD、监控运维，还是应用框架、安全反入侵，用户都能找到适合自己的项目和产品。可是，一旦将场景扩展到多集群、混合云环境时，用户能够依赖的开源技术就屈指可数，而且往往都不够成熟、全面。\n为了让开发者、用户在多集群和混合环境下也能像在单个 Kubernetes 集群平台上一样，使用自己熟悉的开源项目和产品轻松开发功能，RedHat 和蚂蚁、阿里云共同发起并开源了 OCM（Open Cluster Management）旨在解决多集群、混合环境下资源、应用、配置、策略等对象的生命周期管理问题。目前，OCM 已向 CNCF TOC 提交 Sandbox 级别项目的孵化申请。\n项目官网：https://open-cluster-management.io/\n 多集群管理发展历史 让我们把时间拉回到几年前，当业界关注/争论的焦点还在 Kubernetes 是否生产级可用的时候，就出现了最早一批登陆“多集群联邦“技术的玩家。它们大都是体量上远超平均水准的 Kubernetes 实践先驱，从最早 Redhat、谷歌入场做了 KubeFed v1 的尝试，再到后来携手 IBM 吸取经验又推出 KubeFed v2。除了这些大型企业在生产实践 Kuberentes 的场景中探索多集群联邦技术，在商业市场上，各个厂商基于 Kubernetes 包装的服务产品也大多经历了从单集群产品服务到多集群形态、混合云场景进化的过程。其实，无论是企业自身还是商业用户都有共性的需求，聚焦在以下几个方面：\n多地域问题：当集群需要在异构基础设施上或者横跨更广地域进行部署\nKubernetes 集群依赖 etcd 作为数据持久层，而 etcd 作为分布式系统对系统中各个成员之间的网络延迟上有要求，对成员的数量也有一些限制，虽然在延迟能够容忍的情况下可以通过调整心跳等参数适配，但是不能满足跨国跨洲的全球性部署需求，也不能保证规模化场景下可用区的数量，于是为了让 etcd 至少可以稳定运行，一般会按地域将 etcd 规划为多个集群。此外，以业务可用和安全性为前提，混合云架构越来越多地被用户接受。跨越云服务提供商很难部署单一 etcd 集群，随之对应的，Kubernetes 集群也被分裂为多个。当集群的数量逐渐增多，管理员疲于应对时，自然就需要一个聚合的管控系统同时管理协调多个集群。\n规模性问题：当单集群规模性遇到瓶颈\n诚然，Kubernetes 开源版本有着明显的规模性瓶颈，然而更糟糕是，我们很难真正量化 Kubernetes 的规模。社区一开始提供了 kubemark 套件去验证集群的性能，可是现实很骨感，kubemark 所做的事情基于局限于在不同节点数量下反复对 Workload 进行扩缩容调度。可是实践中造成 Kubernetes 性能瓶颈的原因复杂、场景众多，kubemark 很难全面客观描述多集群的规模性，只能作为非常粗粒度下的参考方案。后来社区支持以规模性信封来多维度衡量集群容量，再之后有了更高级的集群压测套件 perf-tests。当用户更清晰地认识到规模性的问题之后，就可以根据实际场景（比如 IDC 规模、网络拓扑等）提前规划好多个 Kubernetes 集群的分布，多集群联邦的需求也随之浮出水面。\n容灾/隔离性问题：当出现更多粒度的隔离和容灾需求\n业务应用的容灾通过集群内的调度策略，将应用部署到不同粒度的基础设施可用区来实现。结合网络路由、存储、访问控制等技术，可以解决可用区失效后业务的连续性问题。但是如何解决集群级别，甚至是集群管理控制平台自身的故障呢？\netcd 作为分布式系统可以天然解决大部分节点失败的问题，可是不幸的是实践中 etcd 服务也还是可能出现宕机的状况，可能是管理的操作失误，也可能是出现了网路分区。为了防止 etcd 出现问题时“毁灭世界”，往往通过缩小“爆炸半径”来提供更粒度的容灾策略。比如实践上更倾向于在单个数据中心内部搭建多集群以规避脑裂问题，同时让每集群成为独立的自治系统，即使在出现网络分区或者更上层管控离线的情况下可以完整运行，至少稳定保持现场。这样自然就形成了同时管控多个 Kubernetes 集群的需求。\n另一方面，隔离性需求也来自于集群在多租户能力上的不足，所以直接采取集群级别的隔离策略。顺带一提的好消息是 Kubernetes 的控制面公平性/多租户隔离性正在一砖一瓦建设起来，通过在 1.20 版本进入 Beta 的 APIPriorityAndFairness 特性，可以根据场景主动定制流量软隔离策略，而不是被动的通过类似 ACL 进行流量的惩罚限流。如果在最开始进行集群规划的时候划分为多个集群，那么隔离性的问题自然就解决了，比如我们可以根据业务给大数据分配独占集群，或者特定业务应用分配独占请集群等等。\nOCM 的主要功能和架构 OCM 旨在简化部署在混合环境下的多 Kubernetes 集群的管理工作。可以用来为 Kubernetes 生态圈不同管理工具拓展多集群管理能力。OCM 总结了多集群管理所需的基础概念，认为在多集群管理中，任何管理工具都需要具备以下几点能力：\n1.理解集群的定义；\n2.通过某种调度方式选择一个或多个集群；\n3.分发配置或者工作负载到一个或多个集群；\n4.治理用户对集群的访问控制；\n5.部署管理探针到多个集群中。\nOCM 采用了 hub-agent 的架构，包含了几项多集群管理的原语和基础组件来达到以上的要求：\n●通过 ManagedCluster API 定义被管理的集群，同时 OCM 会安装名为 Klusterlet 的 agent 在每个集群里来完成集群注册，生命周期管理等功能。\n●通过 Placement API 定义如何将配置或工作负载调度到哪些集群中。调度结果会存放在 PlacementDecision API 中。其他的配置管理和应用部署工具可以通过 PlacementDecisiono 决定哪些集群需要进行配置和应用部署。\n●通过 ManifestWork API 定义分发到某个集群的配置和资源信息。\n●通过 ManagedClusterSet API 对集群进行分组，并提供用户访问集群的界限。\n●通过 ManagedClusterAddon API 定义管理探针如何部署到多个集群中以及其如何与 hub 端的控制面进行安全可靠的通信。\n架构如下图所示，其中 registration 负责集群注册、集群生命周期管 …","date":1626764400,"description":"还在为多集群管理烦恼吗？OCM来啦！","dir":"blog/still-worried-about-multi-cluster-management/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"aef61122b990c692c05ed45907471ef8","permalink":"https://sofastack.github.io/sofastack.tech/blog/still-worried-about-multi-cluster-management/","publishdate":"2021-07-20T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/still-worried-about-multi-cluster-management/","summary":"作者简介：冯泳（花名鹿惊），资深技术专家，拥有西北工业大学计算机科学博士学位，在高性能计算，大数据和云计算领域拥有十多年的设计开发经验，专注","tags":["SOFAStack"],"title":"还在为多集群管理烦恼吗？OCM来啦！","type":"blog","url":"/sofastack.tech/blog/still-worried-about-multi-cluster-management/","wordcount":5878},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈拥军 提问：\n 我想求教一个问题，非 Spring 工程中使用 SOFARPC 的泛化调用是否可行？\n A：使用 SOFARPC 的 API 方式构造 泛化 Reference 就可以。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@孙明 提问：\n 请教大家，SOFARPC 可以相互依赖吗？比如 a 依赖 b，同时 b 也依赖 a。\n A：只要不是应用启动期的循环依赖，都是可以的。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n3、@周杰慧 提问：\n 请教个问题，使用 shardingsphere 与 Seata AT 模式结合，我看 Seata 源代码回滚时用主键更新，但对于数据库分片来讲更新时 where 条件需要带上分片的列，这样的话我应该怎么解决这个问题呢？\n A：看他们的 demo 来集成。\nSeata：https://github.com/seata/seata\n4、@Q 提问：\n eureka 做注册中心，TC 高可用时，如何在 TC 端覆盖 eureka 属性？\n A：在 seata\\conf 目录下新增 eureka-client.properties 文件，添加要覆盖的 eureka 属性即可。例如，要覆盖 eureka.instance.lease-renewal-interval-in-seconds 和 eureka.instance.lease-expiration-duration-in-seconds添加如下内容：\neureka.lease.renewalInterval=1\neureka.lease.duration=2\n属性前缀为 eureka，其后的属性名可以参考类 com.netflix.appinfo.PropertyBasedInstanceConfigConstants，也可研究 Seata 源码中的 discovery 模块的 seata-discovery-eureka 工程。\nSeata：https://github.com/seata/seata\n本周推荐阅读 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\n RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1626418800,"description":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210716/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cd4f09022c5b4338855eea46f50d5a9a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210716/","publishdate":"2021-07-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210716/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210716/","wordcount":993},{"author":"曾柯","categories":"SOFAStack","content":" 01 引言-TLS 1.3 协议及 SM 算法 说起 TLS，大家一定不会陌生，TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。自从 2014 年 Heartbleed 漏洞被发现以来，网络安全受人关注的程度越来越高，出于更安全更快捷的需求，TLS 1.3 协议也随之被提出，其相应的 RFC 于 2018 年正式发布。随着网络安全越来越受到重视，安全战略也逐步上升到国家战略的高度，国家密码局在 2010 年底公布了我国自主研制的“椭圆曲线公钥密码算法”（SM2 算法），并随后陆续发布了国密算法 SM1-SM9（SM 代表商密的拼音大写）。今天我们要分享的东西，就和 TLS 1.3 及国密有关。\n首先先让大家对这两者之间的关系有一个基本的概念，我们以一个典型的 TLS 1.2 中的密钥套件为例：\n 对应到我们的国密的算法上，则各个算法对应的套件如下：\n1、密钥交换算法：ECC-SM2，ECDHE-SM2（这里先不详细展开，只简单介绍一下，国密的密钥交换算法基于当前的椭圆曲线算法设计了两种专门的算法，而对应的曲线则是 SM2 曲线）；\n2、数字签名算法：SM2（SM2 既是签名算法的名称，同时在椭圆曲线算法中对应的曲线名也叫 SM2，有的博客文档里也将密钥交换算法称作 SM2，读者请注意不要混淆）；\n3、对称加密算法：SM4；\n4、hash 算法：SM3。\n也就是说，国密局针对安全握手各个阶段所需要的算法都出台了一份自主可控的算法。\n02 why 国密？why not 国密？ 先说说为什么要用国密，国密算法作为国密局的主力产品，肯定是在很多地方有优势的，先来总结下国密的典型优势：\n1、更安全：SM2 作为一种 ECC 算法（256 位）的安全性是要高于 2048 位的 RSA 的。同时 SM3 的摘要长度为 256 bit，安全强度也是要高于当时主流的 MD5 算法及 SHA1 算法的。\n2、更快速：在通讯过程中，256 位的 SM2 算法相比于 2048 位的 RSA 算法（国密算法在设计时，RSA2048 是主流签名算法，所以这里暂不讨论ECDSA等算法），可以传输更少的数据，也就意味着更少的传输时间，并且在理论上来说，SM2 签名算法的计算速度是要快过 RSA2048 不少的。\n3、自主可控：在目前这个国际形势下，这是最最最关键的一点！\n国密听起来像是中国密码的一次革新，但这些年却一直没有大面积推行开来，说明其本身肯定有一些问题的，这里抛开一些细节的小问题，谈一谈国密算法在大规模落地过程中遇到的一些比较棘手的问题：\n1.速度不够快（麻烦指数★★★）\n国密整个 TLS 会话流程中涉及到的几个算法，相对主流国际算法来说，大部分情况下性能均相对弱势，这里针对一些给出一些简单的性能对比表：\n对称加密算法性能对比：\n 签名算法性能对比：\n hash 算法性能对比：\n 从对比中我们可以看到，国密的这些算法目前和国际算法性能常常不在一个量级，无论是对称加密还是非对称加密的部分。究极根本原因，还是由于各种通用的国际算法普及程度太大，在工程上有着相应的多层次的优化（硬件计算和各种软加速手段），以对称加密为例：国密对称加密算法 SM4 对标的算法是 aes-128，从本身的加密原理上来看，SM4 在理论上不会和 aes-128 产生如此大的差距，然而 AES 由于普遍性实在太强，典型的 AES 实现都基于 Intel 的 SIMD 指令集对其进行了并行化加速，而 SM4 目前只有纯软的实现，性能上自然有不小的差距。不仅如此，目前的主流对称加密模式为 GCM 及 CCM 模式，其背后的思想为加密即认证技术（AEAD），而国密算法尚不支持这种模式，在安全性上也存在着一些弱点。\n2.需要双证书（★★★★）\n要把双证书讲清楚首先需要大家理解下 PKI 密钥协商机制，典型的密钥协商算法分为两种：RSA，ECDHE。国密的 ECC-SM2 密钥协商流程和 RSA 比较类似，算法核心的性质在于用公钥加密的数据可以用私钥解密，整个密钥协商流程简化如下图：\n 而 ECDHE-SM2 比较类似 ECDHE 算法，均是基于 DH 和 ECC 的算法，理解起来更加容易，流程简化如下图：\n 我们再来谈双证书这个事情，双证书分为签名证书和加密证书，这套体系的目的是满足国家对于敏感数据强管控诉求，即只要能抓到所有数据包，则管控机构则可以在理论上恢复出所有明文数据，由此催生出了加密证书这个东西，加密证书的私钥需要在专门的机构留底。我们来看 RSA 的密钥交换流程，只要拥有了私钥，则中间的密钥生成的材料（随机数）也就可以在理论上进行导出。而对于 ECDHE-SM2 来说，对称密钥的导出流程不仅仅只由随机数 a/c 来决定，同时也需要加密证书对应的私钥参与到计算中（具体流程比较繁琐，这里不展开，读者可参考 GM/T 0024 标准阅读详细的细节），也就意味着当私钥被监管，则对称密钥可以理论上被导出。\n这套体系很强悍，但难就难在目前所有主流密码库如 openssl，boringssl 都不支持，那么这也就意味着如果要推进这套体系的普适度，要么基于主流密码库开发，并推进开源社区接受，进而慢慢渗透到国内用户把这套体系用起来，要么在尽可能兼容目前密码体系的情况下开发一套新的密码库并强制国内用户替换，每一种办法都存在不小的难度。\n3.需要客户端也持有证书（★★★★★）\n国密在 GM/T 0024 标准里面定义了基于 ECDHE-SM2 算法的密钥交换流程，但这个算法的要求十分苛刻，必须要求 Client 也持有证书，的确这对于安全性有一定提升，但麻烦也就随之而来，支付宝的客户端目前没有证书，如果加上证书会让 App 更重，握手交互的数据更多，极大降低用户体验。这些问题还不够致命，如何管理海量的端上证书，才是真正令人头疼的麻烦。\n也许你会问：不用 ECDHE 不就好了嘛，但从技术的演进趋势来看，高效/安全是我们孜孜不倦的追求，而类 RSA 的握手流程则从根源上限制了国密 ECC 密钥交换流程无法演进到 1-RTT 握手，0-RTT 信息传输。不仅如此，ECHDE 的安全性及性能，也要好很多。在 TLS 1.3 的 1RTT 标准握手流程中，明确定义了废除 RSA 握手，只支持 ECDHE。目前这个情况就造成了一个死锁，想用 TLS 1.3-\u0026amp;gt;需要 ECDHE-\u0026amp;gt;需要 Client 有证书-\u0026amp;gt;没有证书且不想用证书-\u0026amp;gt;问题无解。\n03 重磅推出，TLS 1.3+ 国密算法套件 针对国密落地过程中的这些痛点问题，2019 年 8 月份，由蚂蚁的同学牵头，撰写了一份 TLS 1.3+ 国密算法 draft，并最终成为了一份 IETF 标准文档：\n 整个标准设计的核心思想是：整合目前国密算法优势，全面贴合国际上的安全技术思路，把不好用的东西先暂时剔除掉，提升国密算法在国内及国际上的影响力，从而让更多组织及个人参与到国密算法的使用和建设中来。基于这个思路，我们联合了 360 等公司，经过和国密局的多次沟通，正式推出了相关标准。在整个流程上，我们在 ECDHE 算法上取消了 Client 证书的要求，并暂时放 …","date":1626159600,"description":"RFC8998+BabaSSL---让国密驶向更远的星辰大海","dir":"blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"54dc71c8ea8dcfb0408a430934cb90c3","permalink":"https://sofastack.github.io/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","publishdate":"2021-07-13T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","summary":"01 引言-TLS 1.3 协议及 SM 算法 说起 TLS，大家一定不会陌生，TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。自从 2014 年 Heartbleed 漏洞被发","tags":["SOFAStack"],"title":"RFC8998+BabaSSL---让国密驶向更远的星辰大海","type":"blog","url":"/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","wordcount":3534},{"author":"王发康","categories":"SOFAStack","content":" 注：本文是王发康（毅松）在 2021 GopherChina 上演讲的文字稿，相关分享 PPT 可自行到 MOSN meetup 下载。MOSN meetup 地址；MOSN 官方 Github 地址；GitHub 地址。\n 前言 MOSN 在 Service Mesh 领域作为东西向服务治理网络在蚂蚁集团双 11 、春节红包等活动及开源社区都得到了一定实践。为了能够让社区用户更好的享受到这一技术红利，MOSN 从 2018 年开源以来在社区开发者、用户的共同努力下，使得 MOSN 在云原生演进方面做了很多探索和实践。比如 Istio 下另一个数据面 — MOSN、WebAssembly 在 MOSN 中的探索与实践、MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章、MOSN 基于 Sentinel 的限流实践、MOSN 中玩转 Dubbo-go 等周边生态展开合作。\n2021 年为了更好的为业务提效，MOSN 开启了将云原生进行到底的决心。本文介绍了 MOSN 在网络扩展层的思考和技术选型，以及最终是如何通过使用 Envoy 作为 MOSN 的网络层扩展，从而实现 MOSN 和 Envoy 生态打通。使得网络层具备 C++ 高性能的同时，上层业务治理能力也能借助 GoLang 进行高效的定制化开发。\n 面临的问题及挑战 一、社区生态，如何最大化求同存异 最近几年 Service Mesh 技术在云原生社区也是百花齐放，虽然 MOSN 在开源社区也是备受开发者的关注，但是 Envoy 经过长久的发展其社区的活跃度和用户量的积累这点是不可忽略的。另外选择 MOSN 的用户都是看重其二次开发的便捷性以及 GoLang 的生态丰富，选择 Envoy 的用户主要是看重其高性能的网络处理能力及社区的活跃度。那我们是否能够通过技术的手段将其二者优势融为一体，发挥各自的特长，不要让用户顾此失彼。\n二、单一的 Proxy，无法支撑其架构的演进 在 Proxy 层面，无论是 MOSN 还是 Envoy 都是在各自领域中发挥优势。随着云原生技术的快速发展和成熟以及业务的增长，既要 Proxy 能够具备高研发效能，还要具备高处理性能，而单一的 Proxy 已经无法满足当前业务架构上的持续演进。\n东西向和南北向数据面 Proxy 逐步统一：两套数据面定位不同但功能上存在一定重叠，导致维护成本高，未来需要逐步收敛。这就要求 Proxy 不仅具备易扩展性方便业务方扩展东西向业务上的流量治理能力，而且还要具备抗高并发的能力满足南北向高流量转发。\nService Mesh 部署形态逐步向 Node 化架构演进：Service Mesh 规模化后，由于多出的 Proxy 势必会导致一定资源上的浪费，那在中心化和 Mesh 化之间做一次折中，即通过 Node 化部署形态来解决。Node 化后就要求 Proxy 能够高效、稳定的承载多个 POD 的流量治理。\nService Mesh 需要同时具备 Application Runtime 能力：虽然 Service Mesh 解决了微服务治理的痛点，但在实际业务开发中，缓存、数据库、消息队列、配置管理等，仍然需要维护一套重量级的 SDK 并且侵入应用代码。目前业界的解决方案是在 Service Mesh 的基础上多引入一个 Proxy 如 Dapr 来解决，这就导致应用的 POD 需要维护多个容器，所以如何让 Service Mesh 的 Proxy 具备快速复用 Dapr 能力成为解决该问题的关键。\n我们的思考 针对上述问题分析过后，其实背后的原因是有共性的。比如将其统一为一个 sidecar，如果单纯的从一个数据面改为另一个，那其中的改造成本是巨大的。那是否可以换个思路，为 MOSN 的网络层增加可扩展性，即可以让 MOSN 的网络处理直接下沉至 Envoy，同时将这个能力剥离出来成为 Envoy 在 GoLang 上的一个标准能力，这样就能够让 Envoy 和 MOSN 互相复用已有的能力。二者相互融合，各取所长，使其同时具备高研发效能和处理性能高，自然而然就解决上述“单一的 Proxy，无法支撑架构的演进”和“社区生态，如何最大化求同存异”所面临的问题。相互融合后，不仅融合了各种的优势，而且也能够把两边的生态打通，借此 MOSN 社区和 Envoy 社区能形成双赢的局面。\n 方案调研与分析 知道当前面临问题的原因后，便有了一个宏观的解决方向。于是就对此展开了相关调研，梳理了业界针对此问题的一些解决方案，综合各种方案的优劣势并结合蚂蚁业务现状以及开源社区用户的痛点进行了分析和评估。\n扩展方案调研\n 扩展方案评估\n 通过上述方案优劣势的对比以及评估，MOE（MOSN on Envoy） 相比 ext-proc 无需跨进程 gRPC 通信，性能高，易管理；相比 Envoy WASM 扩展无需网络 IO 操作转换成本；相比 Lua 扩展生态好、能复用现有的 SDK，对于处理上层业务更合适。\n同时我们将 Envoy 中增加 GoLang 扩展的这个方案也在 Envoy 社区进行了讨论，也得到了 Envoy 社区 Maintainer 的赞同。其中依赖的技术 CGO 是 GoLang 官方出品，该技术基本上在 GoLang 每个 release notes 中都有提到，说明也一直在维护的。另外业界也有很多项目在使用这项技术（比如：NanoVisor、Cilium、NginxUnit、Dragonboat、Badger、Go withOpenCV etc）其稳定性已经过一定的考验了，同时我们自己也测试了 CGO 自身的开销在 0.08 ~ 1.626 微秒，而且调用开销也是属于线性增长而非指数增长趋势。\n 所以综合稳定性、性能、改造成本以及社区生态等因素评估，MOE 解决方案无论在当前阶段还是未来都具备一定优势。\n方案介绍 一、整体架构 如下是 MOE 的整体架构图，最下面是各种高性能数据面，目前我们主要适配的是 Envoy。在数据面之上剥离了一层 GoLang L7 extension filter 的抽象，用于和底层的数据面连通；然后在 MOSN 侧通过 GoLang L7 extension SDK 将 MOSN 连通；最后通过 CGO 这个通道将 Envoy 和 MOSN 打通。\n 整体架构如上图所示，其核心包括如下三部分组成：\n1、GoLang L4/L7 extension filter\n使用 C++ 实现的 Envoy 侧的 GoLang L4/L7 filter ，该模块通过 CGO API 来调用 GoLang 实现的 L4/L7 extension filter。\n2、GoLang L4/L7 extension SDK\nGoLang L4/L7 extension SDK 会导出一些 CGO API，用于 Golang L4/L7 extension filter 和 L4/L7 extension GoLang filter 交互。\n3、L4/L7 extension filter via GoLang\nL4/L7 …","date":1625554800,"description":"开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态","dir":"blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e570e9fb3aba7b066d2e3b332ae18dbc","permalink":"https://sofastack.github.io/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","publishdate":"2021-07-06T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","summary":"注：本文是王发康（毅松）在 2021 GopherChina 上演讲的文字稿，相关分享 PPT 可自行到 MOSN meetup 下载。MOSN meetup 地址；MOSN 官方 Github 地址；GitHub 地址。 前言 MOSN 在 Service Mesh","tags":["SOFAStack"],"title":"开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态","type":"blog","url":"/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","wordcount":5977},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@刘世杰 提问：\n 新接触 SOFABoot，有 2 个问题想请教一下： 1.如何根据不同的贡献方选择对应的扩展实现？贡献方有多个的情况下，覆盖了原始的对象，没看到如何根据身份定位具体实现的逻辑，不知道是遗漏了什么说明文档，我看的这个文档：https://www.sofastack.tech/projects/sofa-boot/extension/\n2.如何确保贡献方提供的 jar 包不对服务提供方产生影响？如果多个贡献方提供的 jar 包里间接依赖了不同版本的二三方的 jar 包。在同一个 classloader 下只能加载一个版本的 class，那对某些贡献方的逻辑处理可能会出现 NoClassDefFoundError 类的异常。SOFAArk 是具备了这种隔离的能力的，是否需要引入这种方式？\n A：1.如果有多个扩展点 x 的扩展地方，那么 A 的 registerExtension 就会被调用多次（与被扩展的次数一样，这个方法需要线程安全）；框架无法获知扩展者的身份，这个就需要扩展点提供方自行甄别。\n2.第二种情况，其实不仅限于 SOFABoot 中的扩展点，仅有一个 class loader 的情况下，会出现这种情况。个人认为在没有动态性要求的情况下，优先解决 maven 依赖冲突。\nSOFABoot：https://github.com/sofastack/sofa-boot\n2、@刘世杰 提问：\n 1.按照官网的 Demo，如果有多个贡献方 A、B、C，按照顺序执行了 registerExtension 方法，那 word 的值会以 C 为准吗？意思是不是说在运行时一个扩展点只有一个贡献方？\n2.如果贡献方比较多的话，这个后期的解决冲突的成本会不会比较高。还有些比较隐蔽的实现，可能不是太好测试出来，到生产才发现问题。另外，如果做动态的话在 SOFABoot 的技术栈里是扩展点 +Ark 的方式？\n A：1.这个顺序是没有保证的，SOFABoot 为了启动速度，并行化了上下文刷新的，因此可能是 A、B、C 顺序，也有可能是 C、B、A；运行时可以有多个实现的，这个取决于你的服务类型，以及如何实现的。\n2.可以这么理解，SOFAArk 就是一种动态扩展的方案。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@证道者 提问：\n MOSN mirror 功能是只能转发 Dubbo 的流量么？\n A：不是只能转发 Dubbo，都可以的。\nMOSN：https://github.com/mosn/mosn/\n本周推荐阅读 【感谢有你，SOFAer】一图看懂 SOFAStack 2021 半年报\n MOSN 多协议扩展开发实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1625209200,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210702/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5808aa4a754ad5a4024b619e1d61cba8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210702/","publishdate":"2021-07-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210702/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210702/","wordcount":1290},{"author":"永鹏","categories":"SOFAStack","content":" Service Mesh 是当今云原生的关键部分，蚂蚁已经在生产环境完成了大规模的落地，但是业界整体 Service Mesh 改造程度还不高。其中平稳的进行 Mesh 化改造是可以对已上线的业务进行 Mesh 化改造的前提，在平稳改造过程中，协议的支持又是最基础的部分。MOSN 提供的多协议扩展开发框架旨在降低使用私有协议的场景进行 Mesh 化改造的成本，帮助业务快速落地。\n MOSN 是蚂蚁自研的一款高性能网络代理，主要用于 Service Mesh 的数据面 Sidecar。Service Mesh，是近几年来云原生方向比较热门的话题，其主旨就是构建一个基础设施层，用来负责服务之间的通信。主要就是有一个和服务应用共同部署的 Sidecar 来实现各种中间件的基础能力，实现基础设施的标准化、和业务逻辑解耦，做到业务无感知的基础能力快速演进。目前国内很多公司都开始拥抱 Service Mesh，和蚂蚁合作的一些企业，如中信银行、江西农信等也基于 MOSN 完成了 Mesh 化的改造。\nService Mesh 架构的目的就是为了降低基础设施改造升级对业务造成的影响，但是如何平滑的从传统微服务架构转向 Service Mesh 架构也是一个非常有挑战的工作，这里涉及的细节很多，但是无论如何有一个最基础的问题就是我们在进行灰度 Mesh 化改造的时候，已经 Mesh 化的节点需要能和没有 Mesh 化的节点维持正常通信。而不同的公司选择的通信协议都有所不同，这就直接导致在技术选型的时候，选择的 Sidecar 需要能够支持所使用的协议。一些受到广泛应用的协议可能还会被陆续的支持，而有的协议可能还是公司自己定制的，因此不可避免的是需要基于 Sidecar 的扩展能力，进行二次开发以支持私有的协议。\n 多协议扩展框架 谈到 Service Mesh 的 Sidecar，就不得不提到 Envoy，这是一款被广泛应用的 Service Mesh Sidecar 代理。Envoy 的扩展框架支持开发者进行二次开发扩展，其中 Envoy 目前支持的不少协议就是基于其扩展框架开发实现的。在 Envoy 的扩展框架下，要扩展一个协议可以参考 Envoy 中 HTTP 协议处理的流程，包括 4 层 Filter 实现编解码部分与 Connection Manager 部分，在 Connection Manager 的基础上再实现 7 层的 Filter 用于支持额外的业务扩展、路由的能力、和 Upstream 的连接池能力。可以看到一个协议处理的流程几乎是贯穿了各种模块，实现一个协议扩展成本还是比较高的。\n 再来看一下 MOSN 的框架。MOSN 在一次协议处理上可以划分为四个层次，除开基本的从网络 IO 中获取数据的网络层以外，还可以划分为 protocol 层、stream 层与 proxy 层。其中 protocol 层负责协议解析相关编解码的工作，负责将数据流解析成 MOSN 可以理解的协议帧，或者将协议帧编码成二进制流；stream 层负责的内容就比较多了，包括处理不同的请求类型，初始化请求的上下文，关联事件，响应与请求之间的关联，还有 upstream 连接池相关的处理等，不同的协议处理的细节也会有所不同；proxy 层是一个协议无关的代理转发层，负责请求的路由与负责均衡等能力，同时也具备七层的扩展能力用于不同业务实现的扩展。根据这个架构，可以看到协议处理的核心就在于 protocol 层和 stream 层，相比于 Envoy 的设计来说，路由、七层扩展等部分是具备多协议复用的能力的。但是同时也可以看到 stream 层涉及的细节比较多，实现起来难度也是比较大的，为此 MOSN 在此基础上又提出了一个多协议扩展的框架，用于简化协议的实现。\n MOSN 的多协议框架主要就是针对 stream 层的复用扩展能力，在 MOSN 的协议处理分层设计中， network 层和 proxy 层在设计上就是协议无关可复用的，如果能做到 stream 层也进行复用，那么协议实现就只需要关注 protocol 层的编解码本身，实现难度就会大大降低了。那么 stream 层是不是具备可复用的能力的呢，我们认为对于大部分协议，尤其是 RPC 协议来说是可以的。首先我们对协议进行一个抽象，定义成 XProtocol 接口，表示任意的协议。每个协议实现都是实现一个 XProtocol 接口，它包括基础的编解码接口、一些特殊请求响应的构造接口（如心跳、异常）、还有协议的模型（如类似 HTTP 的 pingpong 模型，常见的 RPC 多路复用模型等），以及协议匹配的接口。所有的 XProtocol 协议实现通过 XProtocol Engine 关联起来，除了通过配置指定使用哪种协议进行处理以外，对于实现了协议匹配接口的协议来说，可以基于请求特征进行自动识别。然后我们对于 XProtocol 解析出的协议帧也进行统一的抽象，包括多路复用相关的接口、协议类型的判断（是请求，还是响应，或者是类似 Goaway 一类的控制帧，请求又可以细分为心跳请求、无响应的 oneway 请求等）、支持对协议帧的数据进行修改（Header/Body 的修改）、还有统一的状态码管理映射等。\n 在 MOSN 的协议处理分层机制下，以及有了以 XProtocol 和 XFrame 的抽象定义为核心的多协议扩展框架以后，我们在 stream 层就可以完全基于接口进行协议的处理，而不同的协议扩展实现者只需要专注于协议编解码本身，以及对编解码后的结果进行简单的接口适配，就可以完成在 MOSN 中的接入，由此获得 MOSN 中各种通用能力的支持，如限流扩展、路由引流等。对比 Envoy 中扩展协议实现部分可以看到是简化了不少的。当然 MOSN 这个多协议框架不能满足所有的协议情况，但是对于目前我们看到的大部分 RPC 协议，在配合上 proxy 层中七层 stream filter 扩展的基础上，都是可以很好的满足的。\n实践案例 下面以 MOSN 在社区合作伙伴中 Dubbo 协议落地的案例来详细的了解 MOSN 的多协议扩展。这里很多代码也是 MOSN 社区的同学贡献的。 在这个案例中，除了要求协议需要支持 Dubbo 以外，还希望使用像限流等这些基础的扩展能力，同时需要蓝绿分组等路由的能力，选择的控制面是 Istio，用于动态配置的下发。那这些需求在 MOSN 中是如何实现的呢？\n首先是协议解析部分，这里采用了基于开源的 dubbo-go 框架做协议实现，基于 dubbo-go 封装出了 MOSN 的 XProtocol 和 XFrame 模型；限流、xDS 等能力直接复用 MOSN 已有的实现，无需额外实现。但是这里有一个问题点就是 Istio 动态下发的路由配置是 HTTP 相关的，HTTP 的路由配置模型与 Dubbo 还是存在一定差异的，而修改 Istio 的成本会比较高，在这里就做了另外一层扩展。基于 MOSN 七层的 StreamFilters，在进行路由匹配之前对 Dubbo 协议进行定制化的处理，用来满足 HTTP 的 …","date":1624950000,"description":"MOSN 多协议扩展开发实践","dir":"blog/mosn-multi-protocol-extension-development-practice/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d5691b6aa90017e49d9726b702475306","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","publishdate":"2021-06-29T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","summary":"Service Mesh 是当今云原生的关键部分，蚂蚁已经在生产环境完成了大规模的落地，但是业界整体 Service Mesh 改造程度还不高。其中平稳的进行 Mesh 化改造是可以对已上线的业务","tags":["SOFAStack"],"title":"MOSN 多协议扩展开发实践","type":"blog","url":"/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","wordcount":4141},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@证道者 提问：\n 应用调用端多语言可以，Layotto 服务能力是不是目前只能 golang 开发，java 可以开发服务能力集成到 Layotto 里吗？还有就是 Layotto 底座是 MOSN 可以不用这个吗？我目前有一个需要处理，就是数据库单表 crud，跨表的 crud，自己分页检索这个能力可以用 Layotto 吗？\n A：如果想用别的语言给 Layotto 做扩展的话，目前感觉可行的方法就是借助 wasm，但具体的方案我们还得调研一下，目前是只能用 golang 开发。 至于你说的这个需求，可应该以作为 Layotto state API 的一种实现组件。\nLayotto：https://github.com/mosn/layotto\n2、@证道者 提问：\n 目前提供 pub/sub 能力，流 stream 能力，状态能力，以后也会将一些通用的业务能力抽象下移到 Layotto 吗？我觉得有点像组件化，面向能力编程。\n A：是的，主要就是希望业务同学可以面向能力编程，比如只需要考虑自己是否需要 pub/sub 能力就行，而不需要管背后是 kafka 还是 rocketMQ 之类的，我们目前在规划的有分布式锁、可观测性能力的下沉，其他的能力会参考社区的反馈。\nLayotto：https://github.com/mosn/layotto\n3、@证道者 提问：\n 所有的都在 Layotto 里面跑，pubsub PRC 不会相互干扰吗?\n A：你指的是资源使用上的互相争抢是吧，目前我们 Service Mesh 落地，Sidecar 也是集成的有 RPC 和 消息能力的，Sidecar 本身主要还是一个转发通道，本身资源占用还是极少的，目前生产上也没有因为同时 Run RPC 和 消息导致互相干扰的现象产生。在 Layotto 这也是类似的场景，大部分业务在单机维度很难跑到极限性能峰值，基本上不会有互相干扰的情况出现。\nLayotto：https://github.com/mosn/layotto\n本周推荐阅读 MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1624604400,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210625/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"edfd61aa9405dccf65be9b8703fa5a1f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210625/","publishdate":"2021-06-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210625/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210625/","wordcount":1070},{"author":"SOFAStack","categories":"SOFAStack","content":" 作者简介： 马振军，花名古今，在基础架构领域耕耘多年，对 Service Mesh 有深度实践经验，目前在蚂蚁集团中间件团队负责 MOSN、Layotto 等项目的开发工作。\n Layotto 官方 GitHub 地址:https://github.com/mosn/layotto\n点击链接即可观看现场视频：https://www.bilibili.com/video/BV1hq4y1L7FY/\nService Mesh 在微服务领域已经非常流行，越来越多的公司开始在内部落地，蚂蚁从 Service Mesh 刚出现的时候开始，就一直在这个方向上大力投入，到目前为止，内部的 Mesh 方案已经覆盖数千个应用、数十万容器并且经过了多次大促考验，Service Mesh 带来的业务解耦，平滑升级等优势大大提高了中间件的迭代效率。\n在大规模落地以后，我们又遇到了新的问题，本文主要对 Service Mesh 在蚂蚁内部落地情况进行回顾总结，并分享对 Service Mesh 落地后遇到的新问题的解决方案。\n一、Service Mesh 回顾与总结 A、Service Mesh 的初衷 在微服务架构下，基础架构团队一般会为应用提供一个封装了各种服务治理能力的 SDK，这种做法虽然保障了应用的正常运行，但缺点也非常明显，每次基础架构团队迭代一个新功能都需要业务方参与升级才能使用，尤其是 bugfix 版本，往往需要强推业务方升级，这里面的痛苦程度每一个基础架构团队成员都深有体会。\n伴随着升级的困难，随之而来的就是应用使用的 SDK 版本差别非常大，生产环境同时跑着各种版本的 SDK，这种现象又会让新功能的迭代必须考虑各种兼容，就好像带着枷锁前进一般，这样随着不断迭代，会让代码维护非常困难，有些祖传逻辑更是一不小心就会掉坑里。\n同时这种“重”SDK 的开发模式，导致异构语言的治理能力非常薄弱，如果想为各种编程语言都提供一个功能完整且能持续迭代的 SDK 其中的成本可想而知。\n18 年的时候，Service Mesh 在国内持续火爆，这种架构理念旨在把服务治理能力跟业务解耦，让两者通过进程级别的通信方式进行交互。在这种架构模式下，服务治理能力从应用中剥离，运行在独立的进程中，迭代升级跟业务进程无关，这就可以让各种服务治理能力快速迭代，并且由于升级成本低，因此每个版本都可以全部升级，解决了历史包袱问题，同时 SDK 变“轻”直接降低了异构语言的治理门槛，再也不用为需要给各个语言开发相同服务治理能力的 SDK 头疼了。\nB、Service Mesh 落地现状 蚂蚁很快意识到了 Service Mesh 的价值，全力投入到这个方向，用 Go 语言开发了 MOSN 这样可以对标 envoy 的优秀数据面，全权负责服务路由，负载均衡，熔断限流等能力的建设，大大加快了公司内部落地 Service Mesh 的进度。\n现在 MOSN 在蚂蚁内部已经覆盖了数千个应用、数十万容器，新创建的应用默认接入 MOSN，形成闭环。而且在大家最关心的资源占用、性能损耗方面 MOSN 也交出了一份让人满意的答卷： 1. RT 小于 0.2ms\n CPU 占用增加 0%~2%\n 内存消耗增长小于 15M\n 由于 Service Mesh 降低了异构语言的服务治理门槛，NodeJS、C++等异构技术栈也在持续接入到 MOSN 中。\n在看到 RPC 能力 Mesh 化带来的巨大收益之后，蚂蚁内部还把 MQ，Cache，Config 等中间件能力都进行了 Mesh 化改造，下沉到 MOSN，提高了中间件产品整体的迭代效率。\nC、新的挑战 应用跟基础设施强绑定 一个现代分布式应用，往往会同时依赖 RPC、Cache、MQ、Config 等各种分布式能力来完成业务逻辑的处理。\n当初看到 RPC 下沉的红利以后，其他各种能力也都快速下沉。初期，大家都会以自己最熟悉的方式来开发，这就导致没有统一的规划管理，如上图所示，应用依赖了各种基础设施的 SDK，而每种 SDK 又以自己特有的方式跟 MOSN 进行交互，使用的往往都是由原生基础设施提供的私有协议，这直接导致了复杂的中间件能力虽然下沉，但应用本质上还是被绑定到了基础设施，比如想把缓存从 Redis 迁移到 Memcache 的话，仍旧需要业务方升级 SDK，这种问题在应用上云的大趋势下表现的更为突出，试想一下，如果一个应用要部署在云上，由于该应用依赖了各种基础设施，势必要先把整个基础设施搬到云上才能让应用顺利部署，这其中的成本可想而知。 因此如何让应用跟基础设施解绑，使其具备可移植能力，能够无感知跨平台部署是我们面临的第一个问题。\n 异构语言接入成本高 事实证明 Service Mesh 确实降低了异构语言的接入门槛，但在越来越多的基础能力下沉到 MOSN 以后，我们逐渐意识到为了让应用跟 MOSN 交互，各种 SDK 里都需要对通信协议，序列化协议进行开发，如果再加上需要对各种异构语言都提供相同的功能，那维护难度就会成倍上涨，\nService Mesh 让重 SDK 成为了历史，但对于现在各种编程语言百花齐放、各种应用又强依赖基础设施的场景来说，我们发现现有的 SDK 还不够薄，异构语言接入的门槛还不够低，如何进一步降低异构语言的接入门槛是我们面临的第二个问题。\n二、Multi Runtime 理论概述 A、什么是 Runtime? 20 年初的时候，Bilgin lbryam 发表了一篇名为 Multi-Runtime Microservices Architecture 的文章，里面对微服务架构下一阶段的形态进行了讨论。\n如上图所示，作者把分布式服务的需求进行了抽象，总共分为了四大类： 1. 生命周期（Lifecycle） 主要指应用的编译、打包、部署等事情，在云原生的大趋势下基本被 docker、kubernetes 承包。\n 网络（Networking） 可靠的网络是微服务之间进行通信的基本保障，Service Mesh 正是在这方面做了尝试，目前 MOSN、envoy 等流行的数据面的稳定性、实用性都已经得到了充分验证。\n 状态（State） 分布式系统需要的服务编排，工作流，分布式单例，调度，幂等性，有状态的错误恢复，缓存等操作都可以统一归为底层的状态管理。\n 绑定（Binding） 在分布式系统中，不仅需要跟其他系统通信，还需要集成各种外部系统，因此对于协议转换，多种交互模型、错误恢复流程等功能也都有强依赖。\n 明确了需求以后，借鉴了 Service Mesh 的思路，作者对分布式服务的架构演进进行了如下总结：\n 第一阶段就是把各种基础设施能力从应用中剥离解耦，通通变成独立 sidecar 模型伴随着应用一起运行。\n第二阶段是把各种 sidecar 提供的能力统一抽象成若干个 Runtime，这样应用从面向基础组件开发就演变成了面向各种分布式能力开发，彻底屏蔽掉了底层实现细节，而且由于是面向能力，除了调用提供各种能力的 API 之外，应用再也不需要依赖各种各样基础设施提供的 SDK 了。\n作者的思路跟我们希望解决的问题一致， …","date":1624258800,"description":"MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章","dir":"blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","fuzzywordcount":7600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4ea3e26c4f2e5422816a186691849af5","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","publishdate":"2021-06-21T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","summary":"作者简介： 马振军，花名古今，在基础架构领域耕耘多年，对 Service Mesh 有深度实践经验，目前在蚂蚁集团中间件团队负责 MOSN、Layotto 等项目的开发工","tags":["SOFAStack"],"title":"MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章","type":"blog","url":"/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","wordcount":7525},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙力 提问：\n 请问和 MOSN 相关的健康检查有什么可行的方案吗？比如如何检查 MOSN 的健康状态，MOSN 检查业务容器健康，检查失败后有什么降级或动作？\n A：MOSN 有获取运行状态的 API ，\nhttps://github.com/mosn/mosn/blob/master/pkg/admin/server/apis.go#L301\n检查业务容器健康通常来说需要自己扩展。\nhttps://github.com/mosn/mosn/blob/9a53d7239d8d5ca987410c15d791e780b5809558/pkg/upstream/healthcheck/factory.go#L53\n健康检查也有回调可以注册，可以实现自己的降级逻辑。\nMOSN：https://github.com/mosn/mosn\n2、@许玉杰 提问：\n AT 模式是怎么做到的空回滚、防悬挂和幂等的啊？\n A：幂等是用户自己做的，防悬挂和空回滚有 undolog，AT 的幂等等于接口幂等，自己的接口保证即可。\nSeata：https://github.com/seata/seata\n3、@jueming 提问：\n Seata 支持 mybatis 的注解开发吗？目前用的 seata1.0 的版本，需要配置代理数据源，但是配置之后，影响了其他 sql 的执行，代理执行了 sql 的方法，打印了相关 sql 语句（数据库里有数据），但是得到的实体却为空。我把代理关闭以后则不影响 sql 的查询，这种情况应该怎么解决？\n A：这里的问题是添加代理数据源的时候，使之前的 datasource 自动失效，没有读取 mybatis 的配置，解决方法是在设置新的 sqlsessionfactory 的时候，把需要配置的属性通过 ibatis 包下的 Configuration 注入进去。\nSeata：https://github.com/seata/seata\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623999600,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210618/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c8d740f2b60544b872580120fd456cde","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210618/","publishdate":"2021-06-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210618/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210618/","wordcount":902},{"author":"SOFAStack","categories":"SOFAStack","content":" GoCN：贵司从什么时候开始用 Go，基于什么原因，还记得第一个用 Go 的项目是什么吗?\n宋顺：早在 2015 年，蚂蚁的基础设施团队就已经使用 Go 来尝试优化资源调度能力，当时还是基于 Docker Swarm 做的一些调度平台，这个时期没有持续太长就逐步切换到了 Kubernetes，蚂蚁内部的版本叫 Sigma，当前 Sigma 已经承担起了蚂蚁内部所有集群的资源调度，并且也在逐年提升资源利用率，为公司节省了不少的成本。\nGoCN：现在有多少人用 Go，或者 Go 开发比例占到多少？\n宋顺：目前 Go 主要用于蚂蚁的基础设施团队，在资源调度、弹性伸缩、安全容器、日志无盘、Service Mesh、Serverless 等场景中广泛应用，Go 的开发人员在基础设施团队内部占比高达 50% 以上，业务团队大部分还是以 Java 为主。\nGoCN：Go 有哪些特性是非常匹配贵司业务和开发需求的，有哪些是让人很抓马的，希望有哪些改进？\n宋顺：Go 的简单易学、安全编码、研发效率、活跃生态等特性是非常符合我们的需求的。抓马的主要还是性能，如大规模下 gc 抖动，调度延迟等。改进方面希望能够有比 channel 更轻量的 Go block/wake 机制，这块我们也在和社区讨论中：https://github.com/golang/go/issues/46431\nGoCN：目前来看 Go 在项目中普及的难度是什么，在招聘方面有困难吗?\n宋顺：在基础设施层面普及没有太大难度，后续如果在业务团队中也能顺畅的使用 Go 还是需要我们的 Service Mesh 体系对多语言体系的支撑更加完善，让业务能更少的感知底层能力从而专注业务开发。我们即将开源的 Layotto 就是希望在 Runtime 层面通过统一的 API 定义，从而可以让各种语言都非常简单的享受到分布式架构的红利，为业务提效。 在招聘方面由于目前 Go 主要用于基础设施，所以我们需要的是对网络、系统内核、高性能有较多经验的人才，不过眼下这类人才还是比较稀缺的。\nGoCN：希望招到具备哪方面能力的 Go 工程师？\n宋顺：有高性能网络编程和性能优化经验，对分布式系统有较深理解，对 Go Runtime 有一定研究的 Gopher 工程师。\nGoCN：对本次大会的期待是什么？\n宋顺：希望了解 Go 在更多公司的实践经验、学习 Go 语言自身的特性演进以及和更多的 Gopher 现场交流。\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623740400,"description":"Gopher China 2021 专访之宋顺：Go 在蚂蚁集团的应用、实践","dir":"blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e6d1f215ee12ebb60c2cc4fda0b64d82","permalink":"https://sofastack.github.io/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","publishdate":"2021-06-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","summary":"GoCN：贵司从什么时候开始用 Go，基于什么原因，还记得第一个用 Go 的项目是什么吗? 宋顺：早在 2015 年，蚂蚁的基础设施团队就已经使用 Go 来尝试优化资","tags":["SOFAStack"],"title":"Gopher China 2021 专访之宋顺：Go 在蚂蚁集团的应用、实践","type":"blog","url":"/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","wordcount":990},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙军超 提问：\n 实际项目中，怎么动态的配置 # 集群列表中所有节点的地址列表initialServerList: 127.0.0.1:8181,127.0.0.1:8182,127.0.0.1:8183比如加一个节点 这个列表怎么自动刷新 。\n A：通过 CliService 动态增上改节点。\nSOFAJraft：https://github.com/sofastack/sofa-jraft\n2、@王国鑫 提问：\n 请教一下，其中一个 follow 机器，在状态机 onApply 里执行任务，有一些异常，这个异常状态如何上报给 leader？\n A：异常分两种，跟上不上报 leader 没什么关系，也不需要上报 leader。leader 只负责感知对应 follower 能不能跟上 raft log， 不论 raft 还是 paxos，都可以理解为分布式日志状态机，你这个异常是你自己的业务状态机里的事情了，raft 只保证 raft log 一致，你自己需要保证相同的 raft log 你要产生相同的结果。\nSOFAJraft：https://github.com/sofastack/sofa-jraft\n3、@陈泽胜 提问：\n 我想问一下我这个是什么问题？ 这是偶发的，两三天会出现一次，有时候一小时内会出现多次。\n Seata：https://github.com/seata/seata\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623394800,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-0611/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"74bd4ee2b575599848e566b632980c07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0611/","publishdate":"2021-06-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0611/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0611/","wordcount":896},{"author":"","categories":"SOFAStack","content":" 主题：从数据库到架构，我们来聊透分布式\n时间：2021年6 月 19 日（周六）13：00 -17：30\n活动地点：北京海淀中关村创业大街 72 号拓荒族众创空间\n报名方式：点击http://hdxu.cn/Iq6Ef 即可报名。\n扫描海报上面的二维码，即可报名。\n【重要提醒】2021 年 6 月 19 日将有惊喜送出，欲知惊喜为何，请待 619 给您分解。\n6月初， OceanBase 诚意开源，正式揭开 300 万 C++ 数据库内核代码的神秘面纱。\n本次线下 Meetup，由 OceanBase \u0026amp;amp; SOFAStack 联合举办，也是 OceanBase 开源之后的首次线下活动。\n本次分享将邀请来自 OceanBase 和 SOFAStack 两个开源项目的四位专家，分别从云原生分布式架构、分布式 HTAP 数据库，以及新发布的时序数据库 CeresDB 来层层解开分布式的魅力。\n 报名方式：\n1、 扫描海报二维码，立即报名；\n2、 点击http://hdxu.cn/Iq6Ef 即可报名。\n在活动现场不仅仅可以和讲师面对面交流\n还有精美礼品发放，快来现场吧~\n","date":1623135600,"description":"【活动报名】SOFAMeetup#6 北京站，从数据库到架构，聊透分布式，玩转 Layotto","dir":"activities/sofa-meetup-7/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"884ed3d8cfc6d7b0784dbda5a27315b1","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-7/","publishdate":"2021-06-08T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-7/","summary":"主题：从数据库到架构，我们来聊透分布式 时间：2021年6 月 19 日（周六）13：00 -17：30 活动地点：北京海淀中关村创业大街 72 号拓荒族众创空","tags":["SOFAStack"],"title":"【活动报名】SOFAMeetup#6 北京站，从数据库到架构，聊透分布式，玩转 Layotto","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-7/","wordcount":371},{"author":"","categories":"SOFAStack","content":" 此文原系 2021 年阿里云开发者大会，开源操作系统社区和生态分论坛，题为《国密技术开发与实践》的分享会后解读。 AnolisOS 国密是社区在 AnolisOS 上做的国密技术解决方案，非常欢迎业界有兴趣的开发者能够参与到 OpenAnolis 社区，为国内的基础软件生态添砖加瓦。\n演讲嘉宾： 杨洋：蚂蚁集团高级技术专家，主导开发了 BabaSSL，也是国内唯一的一个 OpenSSL maintainer，参与起草并推动 RFC8998 标准国际化。 张天佳：阿里云技术专家，主要负责 AnolisOS 上国密技术的开发和应用，参与实现了 libgcrypt 中的国密算法和 linux 内核中的 SM2 算法。\n 让我们穿越回现场： \u0026amp;gt;\u0026amp;gt;缘起 说到密码算法，大家一定很熟悉 MD5，AES，RSA 这些通用的国际标准算法，这也是目前我们普遍采用的密码学算法，它们在数据安全、通信、区块链等众多领域都有着广泛的应用。\n众所周知，这些算法标准都是国外制定的，在某些情况下这会对国内信息安全有不利影响。当下有实力的国家，甚至有些大公司都制定了自己的算法标准。\n顾名思义，国密就是密码算法的国产化，跟其它领域一样，密码算法的国产化已经势不可挡，这也是我们必须要做的事情。中国的国密算法为我们提供了一个新的选择，在必要的场合中可以选择替代那些国际主流算法，尤其是当下国际贸易冲突，技术封锁不可忽视的大环境下，大规模推广和采用国密算法将为国内重要的网络基础设施提供可靠的数据安全保障。\n国密简介 我是谁，从哪里来\n国密是一个口语化的称呼，官方名称是国家商用密码，简称商密，拼音缩写是 SM，这也是国密标准中具体算法名字的来源。国密是用于商用的、不涉及国家秘密的密码技术。\n国密标准完全由中国密码管理局制定，主要的技术实现也基本是国内开发人员完成的，这对摆脱国外的密码技术和产品依赖是非常有利的。\n到哪里去\n自 2012 年以来，SM2/3/4 的国密标准陆续公布，目前国密技术生态基本处于一个正在逐步走向成熟的阶段，但国内密码基础软件在采用国密算法方面仍处于碎片化的状态，比如我们经常可以看到各种个人或组织名义开源的支持国密算法的库；此外这些开源项目的安全更新和社区活跃也都做的不好。国密的推广仍然需要我们中国基础软件的开发者和用户共同努力。\n2020 年 1 月 1 日，《中华人民共和国密码法》正式实施，从法律层面规范了国家商用密码的应用和管理，这也为推广和应用国密提供了必要的法律保障。\n与国际算法的对比\n这里是国密算法和国际通用算法的一个对比，可以直观地看到国密的一个基本情况：\n 针对各种常用的国际能用算法类型，比如对称算法，公钥算法和消息摘要算法，国密标准都定义了对应的相同功能的国密算法，比如 SM4 提供了与 AES 同样的加密强度，并且支持各种加密模式； SM2 是基于椭圆曲线的公钥算法，同时定义了非对称加解密，数字签名和密钥交换标准，相对于 RSA，SM2 的密钥更短，但支持的加密强度却更高；SM3 是国密定义的消息摘要算法标准，摘要长度是固定的 256 位，强度等同于 SHA256。\n除了基础的算法，国密标准也定义了 TLCP 国密双证书协议，用以支持国内的传输层安全协议。这里还有一个好消息，今年三月份，TLS1.3+国密单证书协议正式被国际标准所承认，并且以 RFC8998 标准发布，这意味着我们可以选择在 TLS1.3 协议中使用完整的国密套件，目前我们也在联系正规浏览器厂商支持这个标准的实施和应用。\n同时国密也定义了使用国密算法的 X509 证书，使用 SM3 哈希算法，SM2 算法作为数字签名，证书类型是 SM2-with-SM3。\n对开发者来说，国密提供了一个选择，可以选择从国际通用算法平滑迁移过来。除此之外，国密还有其它一些算法标准，是不太常用的，比如 SM9，ZUC 算法等。\nBabaSSL 前世今生 BabaSSL 是主打国密的密码算法库，与 OpenSSL 1.1.1 保持兼容，作为国密的密码算法解决方案而诞生。\nBabaSSL 是基于之前蚂蚁集团和阿里集团内部的 OpenSSL 版本合并而来，并首次进行了开源。BabaSSL 的含义是：灵巧、轻快且靠谱的密码学和 SSL/TLS 工具库。\nBabaSSL 的绿色商标，是基于阿里的橙色和蚂蚁的蓝色混合而来，也意味着我们希望将 BabaSSL 打造成一个灵活、小巧并且健壮的基础密码学库。\nBabaSSL 目前在阿里集团和蚂蚁集团内部得到了非常广泛的使用。从具体场景来看，有如下三个方面，分别是存储、网络和端上的设备。其中网络服务的场景，是 BabaSSL 最大的支撑场景，例如淘宝、天猫、阿里云等各种涉及到链路加密的服务器端。此外移动端 App，例如支付宝手机 App 中集成了 BabaSSL 来实现多种密码学的能力。\n开源 BabaSSL 已经在去年的 10 月份进行了开源，目前代码是托管在 OpenAnolis 上，当前开源的版本是 8.2.0，也是我们目前最新的稳定版本。\n目前 BabaSSL 在阿里内部使用的版本和开源版本之间存在一定的差异，我们目前正在逐步把内部版本的功能特性迁移到开源版本上进行开源，最终变成一个统一的开源版本，那么届时阿里内部也完全依赖于这个开源的版本，而不会再保留内部的闭源版本。\n特色功能 以下是 BabaSSL 当前最新稳定版本 8.2.0 的主要特色功能特性：\n 基于 OpenSSL 1.1.1，具备 OpenSSL 1.1.1 的全部能力并且保持兼容 支持国密 SM2, SM3 和 SM4，并对 OpenSSL 1.1.1 中所欠缺的 SM2 能力，比如 X509 证书的签发和验证功能进行了补全 GM/T 0024 和 TLCP 国密双证书 TLS 协议 支持 RFC 8998：TLS 1.3+国密单证书 提供了对 IETF 正在标准化过程中的 Delegated Credentials 支持 IETF QUIC API 底层密码学能力 更加完善的 SM2 算法支持，比如 X.509 证书签发、验签的支持 正在申请软件密码模块一级资质 与 OpenSSL 对比 接下来是大家很关心的 BabaSSL 和 OpenSSL 这种老牌的密码算法库之间的区别：\n 从图上可以看到一些主要区别：\n对于一些新的密码学技术标准，BabaSSL 会采取一种相对激进的策略快速跟进，比如在 IETF 中一些正在标准化流程中的技术方案，例如 delegated credentials, compact TLS 等，会进行原型的实现和快速跟进，而 OpenSSL 则是相对保守，因为 OpenSSL 社区的策略是原则上只实现已经发布了的国际标准和国家标准。 在对于国密算法、国密协议、国密的监管合规、云计算厂商的深度集成、以及国产化硬件等方面， BabaSSL 会进行更加深度和广泛的支持，而 OpenSSL 则支持的比较有限。 对于 API 的易用程度，由于没有历史包袱，所以 BabaSSL 可以提供更加简单易用的 API，而OpenSSL 的 API 则相对复杂。对于资源受限的嵌入式设备，BabaSSL 会进行体积裁剪和内 …","date":1623135600,"description":"揭秘 AnolisOS 国密生态，想要看懂这一篇就够了","dir":"blog/the-secret-of-anolisos/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"447fa6eedb1d5ccdea4c37803a2b0dc3","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-secret-of-anolisos/","publishdate":"2021-06-08T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/the-secret-of-anolisos/","summary":"此文原系 2021 年阿里云开发者大会，开源操作系统社区和生态分论坛，题为《国密技术开发与实践》的分享会后解读。 AnolisOS 国密是社区在 AnolisOS 上做的国密技术解决方案","tags":["SOFAStack"],"title":"揭秘 AnolisOS 国密生态，想要看懂这一篇就够了","type":"blog","url":"/sofastack.tech/blog/the-secret-of-anolisos/","wordcount":3702},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@郭晶晶 提问：\n 蚂蚁内部的 SOFAMesh 对 Istio 的 pilot 进行了哪些扩展？是不是内部的 SOFAMesh 才支持 zk 注册中心。\n A：蚂蚁内部用的注册中心是 https://github.com/sofastack/sofa-registry 在服务发现这块是有跟 SOFARegistry 做对接，内部的模块更多还是适应内部的各种配套设置和架构做的一些定制。\nMOSN：https://github.com/mosn/mosn\n2、@王庆振 提问：\n https://github.com/sofastack/sofa-bolt/issuse/257 Connection 对象不应该是对应一个 poolkey（ip:port）吗？为什么 Connection 中还会持有 poolkey 的集合\n A：这个是因为 Bolt 还要服务消息中间件的，消息这边有一个 Connection 对应多个上层对象的场景，poolKey 不是 ip:port 的形式。\nSOFABolt：https://github.com/sofastack/sofa-bolt\n3、@jueming 提问：\n 这一步如果抛出异常，那么是不是不会释放 connection 连接？导致长期占有数据库连接。 A: 会释放，close 是框架层面出现异常自动就会调，如果你自己写 jdbc，你也肯定捕获一次做 rollback close了，这属于框架和业务上的处理，Seata 只不过把异常抛出去。\nSeata：https://github.com/seata/seata\n本周推荐阅读 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案\n 用安全计算保护关键业务\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 本周发布 本周发布详情如下：\n本周发布 MOSN v0.23.0 版本，主要变更如下： 1.新增基于 networkfilter 的 grpc server 扩展实现能力；\n2.新增 TLS 连接的证书缓存，降低内存占用；\n3.修复 HTTP1 协议的 URL 编码与大小写敏感问题；\n4.新增 so plugin 扩展协议实现的示例；\n5.其他 BUG Fix 与优化。\n详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.23.0\n更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1622790000,"description":"SOFA Weekly | MOSN 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210604/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"47a5a019bacbf28f24ea5e9cbad7fc20","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210604/","publishdate":"2021-06-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210604/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210604/","wordcount":951},{"author":"","categories":"SOFAStack","content":" 机器学习（ML）和深度学习（DL）在众多真实的应用场景中愈发重要。这些模型使用已知数据进行训练，并部署在图像分类、内容推荐等场景中进行新数据的处理。总体而言，数据越多，ML/DL 模型就越完善。但囤积和处理海量数据也带来了隐私、安全和监管等风险。 隐私保护机器学习（PPML）有助于化解这些风险。其采用加密技术差分隐私、硬件技术等，旨在处理机器学习任务的同时保护敏感用户数据和训练模型的隐私。 在英特尔® 软件防护扩展（英特尔® SGX）和蚂蚁集团用于英特尔® SGX 的内存安全多进程用户态操作系统 Occlum 的基础上，蚂蚁集团与英特尔合作搭建了 PPML 平台。在本篇博客中，我们将介绍这项运行在 Analytics Zoo 上的解决方案，并展示该解决方案在第三代英特尔® 至强® 可扩展处理器上得到英特尔® 深度学习加速（英特尔® DL Boost）技术助力时的性能优势。\n 英特尔® SGX 是英特尔的受信任执行环境（TEE），它提供基于硬件的内存加密，隔离内存中的特定应用代码和数据。英特尔® SGX 使得用户层代码可以分配内存中的受保护区域，即 “飞地”，这些区域不受更高权限等级程序运行的任何影响（如图一所示）。\n 图一 通过英特尔® SGX 加强防护\n 与同态加密和差分隐私相比，英特尔® SGX 在操作系统、驱动、BIOS、虚拟机管理器或系统管理模型已瘫痪的情况下仍可帮助防御软件攻击。因此，英特尔® SGX 在攻击者完全控制平台的情况下仍可增强对隐私数据和密钥的保护。第三代英特尔® 至强® 可扩展处理器可使 CPU 受信任内存区域增加到 512GB，使得英特尔® SGX 技术能够为隐私保护机器学习解决方案打下坚实的基础。\n2014 年正式成立的蚂蚁集团服务于超 10 亿用户，是全球领先的金融科技企业之一。蚂蚁集团一直积极探索隐私保护机器学习领域，并发起了开源项目 Occlum。Occlum 是用于英特尔® SGX 的内存安全多进程用户态操作系统（LibOS）。使用 Occlum 后，机器学习工作负载等只需修改极少量（甚至无需修改）源代码即可在英特尔® SGX 上运行，以高度透明的方式保护了用户数据的机密性和完整性。用于英特尔® SGX 的 Occlum 架构如图二所示。\n 图二 用于英特尔® SGX 的 Occlum 架构（图片来源：Occlum · GitHub）\n Analytics Zoo 赋能端到端 PPML 解决方案 Analytics Zoo 是面向基于 Apache Spark、Flink 和 Ray 的分布式 TensorFlow、Keras 和 PyTorch 的统一的大数据分析和人工智能平台。使用 Analytics Zoo 后，分析框架、ML/DL 框架和 Python 库可以在 Occlum LibOS 以受保护的方式作为一个整体运行。此外，Analytics Zoo 还提供安全数据访问、安全梯度与参数管理等安全性功能，赋能联邦学习等隐私保护机器学习用例。端到端 Analytics Zoo PPML 解决方案如图三所示。\n 图三 端到端 PPML 解决方案为金融服务、医疗卫生、云服务等应用领域提供安全分布式计算\n 在 Analytics Zoo PPML 平台上，蚂蚁集团与英特尔共同打造了一个更加安全的分布式端到端推理服务流水线（如图四所示）。 该流水线采用 Analytics Zoo Cluster Serving 打造，后者是轻量级分布式实时服务解决方案，支持多种深度学习模型，包括 TensorFlow、PyTorch、Caffe、BigDL 和 OpenVINOTM。 Analytics Zoo Cluster Serving 包括 web 前端、内存数据结构存储 Redis、推理引擎（如面向英特尔® 架构优化的 TensorFlow 或 OpenVINO™ 工具套件），以及分布式流处理框架（如 Apache Flink）。 推理引擎和流处理框架在 Occlum 和英特尔® SGX “飞地” 上运行。web 前端和 Redis 受到传输层安全（TLS）协议加密，因此推理流水线中的数据（包括用户数据和模型）在存储、传输、使用的过程中都受到更多地保护。\n 图四 推理服务流水线\n 共创美好未来：英特尔® DL Boost 加速端到端 PPML 解决方案 1.该解决方案执行如下端到端推理流水线： RESTful http API 接收用户输入，Analytics Zoo pub/sub API 将用户输入转化成输入队列，并由 Redis 管理。用户数据受加密保护。 2.Analytics Zoo 从输入队列中抓取数据。它在分布式流处理框架（如 Apache Flink）上采用推理引擎进行推理。英特尔® SGX 使用 Occlum 来保护推理引擎和分布式流处理框架。英特尔® oneAPI 深度神经网络库（oneDNN）利用支持 Int8 指令集的英特尔® DL Boost 提高分布式推理流水线的性能。 3.Analytics Zoo 从分布式环境中收集推理输出，并送回到由 Redis 管理的输出队列。随后，解决方案使用 RESTful http API 将推理结果作为预测返回给用户。输出队列中的数据和 http 通信内容都被加密。\n性能分析 Analytics Zoo PPML 解决方案的性能进行了验证。\n 表一 测试配置\n 图五为测试结果。与不受英特尔® SGX 保护的推理流水线相比，当推理解决方案受到英特尔® SGX 保护，ResNet50 推理流水线的吞吐量会有少许损失。而采用支持 INT8 指令集的英特尔® DL Boost 后，受英特尔® SGX 保护的推理流水线吞吐量翻了一番。\n 图五 英特尔® SGX、英特尔® DL Boost 和第三代英特尔® 至强® 可扩展处理器提供高性能安全能力\n 基于英特尔® SGX 打造的 Analytics Zoo PPML 解决方案继承了受信任执行环境（TEE）的优点。和其它数据安全解决方案相比，它的安全性和数据效用性十分突出，性能方面仅略逊于纯文本。英特尔® DL Boost 和英特尔® oneDNN 则进一步提升了 Analytics Zoo PPML 推理解决方案的性能。表二总结了该解决方案（TEE）相对于同态加密（HE）、差分隐私（DP）、安全多方计算（MPC）和纯文本的优势。\n 表二 Analytics Zoo PPML 解决方案（TEE）与其他方案的比较\n 总结 在日益复杂的法律和监管环境中，对于企业和组织来说，保护客户数据隐私比以往任何时候都更加重要。在隐私保护机器学习的助力下，企业和组织就能在继续探索强大的人工智能技术的同时，面对大量敏感数据处理降低安全性风险。 Analytics Zoo 隐私保护机器学习解决方案基于 Occlum、英特尔® SGX、英特尔® DL Boost 和 Analytics Zoo 打造，为助力确保数据的安全性和大数据人工智能工作负载性能提供了平台解决方案。蚂蚁集团和英特尔共同打造并验证了这一 PPML 解决方案，并将继续合作探索人工智能和数据安全性领域的最佳实践。\n测试 …","date":1622530800,"description":"助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案","dir":"blog/Helping data security: Ant and Intel work together to create a verified PPML solution/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ccebaadae29c36d85ccb2d8216b6f9b4","permalink":"https://sofastack.github.io/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","publishdate":"2021-06-01T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","summary":"机器学习（ML）和深度学习（DL）在众多真实的应用场景中愈发重要。这些模型使用已知数据进行训练，并部署在图像分类、内容推荐等场景中进行新数据","tags":["SOFAStack"],"title":"助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案","type":"blog","url":"/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","wordcount":2757},{"author":"顾宗敏","categories":"SOFAStack","content":" 什么是安全计算？ Linux 基金会旗下的安全计算联盟对安全计算下了一个定义：\n Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential Computing Consortium\n 在这个定义中强调了这么几点：\n1.安全计算保护的是运算过程中的数据安全;\n2.安全计算需要借助硬件的能力。\n下面就对这两点做一个阐述： 在云计算场景，我们可以把云计算简化为三个部分：数据的传输，数据的运算和数据的存储。\n 这个三个部分的安全解决方案的完整度是有差别的。在数据的传输环节，业界有很完整的安全标准和实现比如 SSL， TLS。在数据存储环节，密码学也提供了非常好的解决方案，我们可以将数据用恰当的方式加密以后保存，防止在存储环节泄密。在数据的运算环节，还没有和其他两个环节那样完整的解决方案。安全计算正是以解决这个问题为目标的。\n安全计算是如何实现的呢？ 我们以英特尔的 SGX 技术为例来看一下具体的技术方案。\n 英特尔的 SGX 技术是将 CPU 作为运算的信任起点，在应用程序中构建安全的运算环境（飞地）。从计算机发明的那一天起，我们就假设 CPU 会按照软件的指令正确地执行，只是没有强调这一点。在软件大发展的今天，各种软件在一台硬件上协作运行，整个生态越来越复杂，恶意软件也出现了。为了防止恶意软件的破坏，CPU 为需要保护的应用隔离出一个独立的飞地环境。飞地外的应用既不能观察也不能修改飞地中的代码和数据，从而保证了飞地中的数据安全。CPU 对飞地的保护非常强，即使是拥有高特权的操作系统和虚拟化管理软件也无法突破这种保护。事实上，不仅仅可以防软件的攻击，哪怕是外围硬件提供者（比如：主板制造者，内存提供者）都无法突破这个保护。\n英特尔 SGX 是目前最成熟的安全计算产品，但并不是唯一的安全计算产品。其他硬件厂商如 AMD，ARM，Nvidia 都在推出安全计算产品。所有这些产品都是软硬件一体的解决方案，总结起来有以下这些特点：\n 在了解了安全计算的概念后，介绍一些安全计算的典型场景：\n 有了安全计算环境，用户可以放心地将应用放到共有云计算环境中，计算中用到的数据和计算的结果都可以加密传输。这样可以统一基础设施的架构，避免复杂的混合云部署方式。\n 云上的数据交易和数据服务也成为了可能。数据拥有方和算法提供方可以分别提供数据和算法至安全计算平台完成计算而不用担心机密泄露的问题。\n 安全计算也可以促成更多的数据合作。各方数据可以在一个安全的环境中做融合运算，让数据产生更大的价值。\n 在边缘计算场景中，计算节点部署在非常复杂的环境中，机器不受控。安全计算可以有效地保护用户数据和隐私。\n安全计算这么多的应用场景，为什么还没有看到大规模部署呢？这是因为安全计算目前还有一个非常大的短板：易用性不强。具体表现为3点：\n应用分割难：将一个现有的应用改造为一个安全计算应用的改造难度很大。需要做代码分割。\n场景部署难：安全计算是要依托于硬件的。在实际部署中需要对应用调度系统做改造。\n安全分析难：一个应用使用了安全计算是不是就一定安全了呢？答案是不确定。这需要对整个应用做非常细致的安全分析。\n针对这些难题，蚂蚁集团和阿里巴巴集团的工程师提出了独到的解决方案。 首先是解决应用分割难的问题。\n 蚂蚁集团开源的 Occlum 项目在飞地中开发了 LibOS 适配层，让 Linux 下的应用可以无修改地运行在 SGX 环境中，彻底解决了应用分割的问题。Occlum 使用 Rust 语言开发，保证内存了安全性；支持多进程和加密文件系统，应用无需修改。 例如：基于蚂蚁集团金融级云原生框架 SOFABoot 开发的应用可以完全无修改的运行在 Occlum 环境中。\n👇网站链接🔗： https://github.com/occlum/occlum/tree/master/demos/sofaboot\n针对部署难的问题，阿里云推出了 Inclavare 开源项目。\n Inclavare 基于 Occlum，为用户提供了安全计算容器。用户只需将关注的重点放在应用本身即可，Inclavare 会将计算调度至合适的计算节点。 针对安全分析难，蚂蚁集团的 MORSE 多方安全计算引擎和 MYTF 区块链计算平台分别为不同的计算场景提供了解决方案。用户无需再承担高昂的安全分析成本。\n 蚂蚁集团在安全计算领域持续投入，用科技的力量来保护数据安全，保护用户隐私，给用户提供更安全的服务。蚂蚁集团开源了 TEE 安全 LibOS Occlum。 用户可以在 https://github.com/occlum/occlum 找到所有的实现代码。用户既可以审查 Occlum 的源代码，以确保整体方案的安全性；也可以参考已有的 demo 来学习 Occlum 的使用方法，快速上手安全计算。\n本周推荐阅读 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 金融级能力成核心竞争力，服务网格驱动企业创新\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1622530800,"description":"用安全计算保护关键业务","dir":"blog/Protecting Critical Operations with Secure Computing/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"800c9227ecb01253319dc8df2eb14d68","permalink":"https://sofastack.github.io/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","publishdate":"2021-06-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","summary":"什么是安全计算？ Linux 基金会旗下的安全计算联盟对安全计算下了一个定义： Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential Computing Consortium 在这个定义中强调了这么几点： 1.安全计","tags":["SOFAStack"],"title":"用安全计算保护关键业务","type":"blog","url":"/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","wordcount":1810},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@非余 提问：\n 对于 Kata 我有些地方还是不太理解，我现在说说我的理解，麻烦你看对不 对，我的理解是 Kata 有两个缓存： 1. virtiofs 需要一个缓存。virtiofsd 和 guest 交互需要缓存做文件系统 buffer ，这个缓存的对应 qemu 的参数就是 memory-backend-file 。（这个缓存和 vhost-user 使用的 vring 是不是同一个？每一个 vm 有自己的缓存空间 ） 在 Kata 配置文件对应的是 default_memory。缓存策略是 virtio_fs_cache。 2. dax 缓存，对应的参数是 virtio_fs_cache_size，没有缓存策略控制。\n A：1、是的；2、dax的缓存控制是依靠guest的文件系统语义实现的。\nSOFAStack：https://github.com/sofastack\n2、@张鹏科 提问：\n SofaReferenceBinding 这个注解有一个属性：serializeType，默认序列化协议使用的是 Hessian2，我想替换成 protobuf，我看文档说这个目前不支持在注解中替换，只能以 xml 的方式。有点蒙，到底支持不支持？\n A：支持。\nSOFAStack：https://github.com/sofastack\n3、@jueming 提问：\n 请问一下 sofa-rpc和 Dubbo 区别在哪呢，是不是可以无缝接入 mosn sidecar？\n A: 核心差别目前主要是在协议上吧，协议的可扩展性双方都有，SOFARPC 的 Bolt 协议是基于最早 HSF 协议的一些痛点做了改良设计，整个协议的请求头是能包含更多信息，比如在 MOSN 里支持 Bolt 协议，整个请求在 MOSN 内只解析 header 就可以拿到足够信息做路由，header 的解析也是类似简单 kv 的方式，Dubbo 使用的协议在 Mosn 或者 Envoy 里需要做 Hessian 反序列化才能拿到足够的信息，性能损耗会稍微大一点，其他方面的扩展性上机制略有不同，但是都有比较强的扩展能力。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n4、@汪辉 提问\n Caused by:io.seata.core.exception.TmTransactionException: TransactionException[begin global request failed. xid=null, msg=Communications link failure. 请问这个 突然没有 xid 是什么情况？\n A：因为是 begin 时的异常，所以没有 xid，begin 成功了才有 Communications link failure。\nSeata：https://github.com/seata/seata\n5、@贾云森 提问\n 常见的就是并没有对 Select 语句进行 forupdate,如果你不开启 forupdate,Seata 默认是遇到并发性竞争锁并不会去尝试重试,导致拿不到 lock 当前事务进行回滚.不影响一致性,如果你想没 forupdate 也开启竞争锁client.rm.lock.retryPolicyBranchRollbackOnConflict 设置为 false（有死锁风险）。 请问是参数开启会出现死锁风险，还是自己手动添加 forupdate ，也会出现死锁风险呢？\n A：不加for update，也会竞争锁。但是因为可能存在二阶段需要回滚的事务，所以retryPolicyBranchRollbackOnConflict 为 true 的时候，优先会给需要回滚的事务进行回滚，所以需要放弃锁，这是 at 模式的一个缺陷。因为 at 就是 2 个锁，1 先获取数据库本地锁，2 获取全局，此事后如果获取全局锁后会释放本地锁，造成了死锁。所以 at 上出现 get global lock fail 是正常的，自己应该在业务上做好重试，当一个全局事务因为获取锁失败的时候，应该重新完整的发起，所谓的完整应该是从 globaltransational 的 tm 端重新发起。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周 sofa-rpc 发布 v5.7.8 版本代码。主要更新如下：\n 支持 Dubbo service version 设置 修复 tracer 采样标志位无法正确透传的问题 修复重试逻辑中丢失最初异常的问题 详细参考： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.8\n","date":1622185200,"description":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20200528/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c1c3882d7e68e5fce4c25a088adaa109","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200528/","publishdate":"2021-05-28T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200528/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200528/","wordcount":1758},{"author":"章耿","categories":"SOFAStack","content":" Mesh 模式的引入是实现应用云原生的关键路径，蚂蚁集团已在内部实现大规模落地。随着 Message、DB、Cache Mesh 等更多的中间件能力的下沉，从 Mesh 演进而来的应用运行时将是中间件技术的未来形态。应用运行时旨在帮助开发人员快速的构建云原生应用，帮助应用和基础设施进一步解耦，而应用运行时最核心是 API 标准，期望社区一起共建。\n 蚂蚁集团 Mesh 化介绍 蚂蚁是一家技术和创新驱动的公司，从最早淘宝里的一个支付应用，到现在服务 全球十二亿用户的大型公司，蚂蚁的技术架构演进大概会分为如下几个阶段：\n2006 之前，最早的支付宝就是一个集中式的单体应用，不同的业务做了模块化的开发。\n2007 年的时候，随着更多场景支付的推广，开始做了一下应用、数据的拆分，做了 SOA 化的一些改造。\n2010 年之后，推出了快捷支付，移动支付，支撑双十一，还有余额宝等现象级产品，用户数到了亿这个级别，蚂蚁的应用数也数量级的增长，蚂蚁自研了很多全套的微服务中间件去支撑蚂蚁的业务；\n2014 年，像借呗花呗、线下支付、更多场景更多业务形态的出现，对蚂蚁的可用性和稳定性提出更高的要求，蚂蚁对微服务中间件进行了 LDC 单元化的支持，支撑业务的异地多活，以及为了支撑双十一超大流量的混合云上的弹性扩缩容。\n2018 年，蚂蚁的业务不仅仅是数字金融，还有数字生活、国际化等一些新战略的出现，促使我们要有更加高效的技术架构能让业务跑得更快更稳，所以蚂蚁结合业界比较流行的云原生的理念，在内部进行了 Service Mesh、Serverless、可信原生方向的一些落地。\n 可以看到蚂蚁的技术架构也是跟随公司的业务创新不断演进的，前面的从集中式到 SOA 再到微服务的过程，相信搞过微服务的同学都深有体会，而从微服务到云原生的实践是蚂蚁近几年自己探索出来的。\n为什么要引入 Service Mesh 蚂蚁既然有一套完整的微服务治理中间件，那为什么还需要引入 Service Mesh 呢？\n 拿蚂蚁自研的服务框架 SOFARPC 为例，它是一个功能强大的 SDK，包含了服务发现、路由、熔断限流等一系列能力。在一个基本的 SOFA(Java) 应用里，业务代码集成了 SOFARPC 的 SDK，两者在一个进程里运行。在蚂蚁的大规模落地微服务之后，我们就面临了如下的一些问题：\n升级成本高：SDK 是需要业务代码引入的，每次的升级都需要应用修改代码进行发布。由于应用规模较大，在一些大的技术变更或者安全问题修复的时候。每次需要数千个应用一起升级，费时费力。 版本碎片化：由于升级成本高，SDK 版本碎片化严重，这就导致我们写代码的时候需要兼容历史逻辑，整体技术演进困难。 跨语言无法治理：蚂蚁的中后台在线应用大多使用 Java 作为技术栈，但是在前台、AI、大数据等领域有很多的跨语言应用，例如 C++/Python/Golang 等等，由于没有对应语言的 SDK，他们的服务治理能力其实是缺失的。\n我们注意到云原生里有 Service Mesh 一些理念开始出现，所以开始往这个方向探索。在 Service Mesh 的理念里，有两个概念，一个是 Control Plane 控制平面，一个是 Data Plane 数据平面。控制面这里暂时不展开，其中数据平面的核心思想就是解耦，将一些业务无需关系的复杂逻辑（如 RPC 调用里的服务发现、服务路由、熔断限流、安全）抽象到一个独立进程里去。只要保持业务和独立进程的通信协议不变，这些能力的演进可以跟随这个独立的进程自主升级，整个 Mesh 就可以做到统一演进。而我们的跨语言应用，只要流量是经过我们的 Data Plane 的，都可以享受到刚才提到的各种服务治理相关的能力，应用对底层的基础设施能力是透明的，真正的云原生的。\n蚂蚁 Mesh 落地过程 所以从 2017 年底开始，蚂蚁就开始探索 Service Mesh 的技术方向，并提出了 基础设施统一，业务无感升级 的愿景。主要的里程碑就是：\n2017 年底开始技术预研 Service Mesh 技术，并确定为未来发展方向；\n2018 年初开始用 Golang 自研 Sidecar MOSN 并开源，主要支持 RPC 在双十一小范围试点；\n2019 年 618，新增 Message Mesh 和 DB Mesh 的形态，覆盖若干核心链路，支撑 618 大促；\n2019 年双十一，覆盖了所有大促核心链路几百个应用，支撑当时的双十一大促；\n2020 年双十一，全站超过 80% 的在线应用接入了 Mesh 化，整套 Mesh 体系也具备了 2 个月从能力开发到全站升级完成的能力。\n蚂蚁 Mesh 落地架构 目前 Mesh 化在蚂蚁落地规模是应用约数千个，容器数十万的级别，这个规模的落地，在业界是数一数二的，根本就没有前人的路可以学习，所以蚂蚁在落地过程中，也建设一套完整的研发运维体系去支撑蚂蚁的 Mesh 化。\n 蚂蚁 Mesh 架构大概如图所示，底下是我们的控制平面，里面部署了服务治理中心、PaaS、监控中心等平台的服务端，都是现有的一些产品。还有就是我们的运维体系，包括研发平台和 PaaS 平台。那中间是我们的主角数据平面 MOSN，里面管理了 RPC、消息、MVC、任务四种流量，还有健康检查、监控、配置、安全、技术风险都下沉的基础能力，同时 MOSN 也屏蔽了业务和基础平台的一些交互。DBMesh 在蚂蚁是一个独立的产品，图里就没画出来。然后最上层是我们的一些应用，目前支持 Java、Nodejs 等多种语言的接入。 对应用来说，Mesh 虽然能做到基础设施解耦，但是接入还是需要一次额外的升级成本，所以为了推进应用的接入，蚂蚁做了整个研发运维流程的打通，包括在现有框架上做最简化的接入，通过分批推进把控风险和进度，让新应用默认接入 Mesh 化等一些事情。\n同时随着下沉能力的越来越多，各个能力之前也面临了研发协作的一些问题，甚至互相影响性能和稳定性的问题，所以对于 Mesh 自身的研发效能，我们也做了一下模块化隔离、新能力动态插拔、自动回归等改进，目前一个下沉能力从开发到全站推广完成可以在 2 个月内完成。\n云原生应用运行时上的探索 大规模落地后的新问题与思考\n蚂蚁 Mesh 大规模落地之后，目前我们遇到了一些新的问题： 跨语言 SDK 的维护成本高：拿 RPC 举例，大部分逻辑已经下沉到了 MOSN 里，但是还有一部分通信编解码协议的逻辑是在 Java 的一个轻量级 SDK 里的，这个 SDK 还是有一定的维护成本的，有多少个语言就有多少个轻量级 SDK，一个团队不可能有精通所有语言的研发，所以这个轻量级 SDK 的代码质量就是一个问题。\n业务兼容不同环境的新场景：蚂蚁的一部分应用是既部署在蚂蚁内部，也对外输出到金融机构的。当它们部署到蚂蚁时，对接的是蚂蚁的控制面，当对接到银行的时候，对接的是银行已有的控制面。目前大多数应用的做法是自己在代码里封装一层，遇到不支持的组件就临时支持对接一下。\n从 Service Mesh 到 Multi-Mesh：蚂蚁最早的场景是 Service Mesh，MOSN 通过网络连接代理的方式进行了 …","date":1621926000,"description":"蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海 ","dir":"blog/Exploration and Practice of AntCloud Native Application Runtime - ArchSummit Shanghai/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"da69750163f92aa73f15821202ee07e6","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","publishdate":"2021-05-25T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","summary":"Mesh 模式的引入是实现应用云原生的关键路径，蚂蚁集团已在内部实现大规模落地。随着 Message、DB、Cache Mesh 等更多的中间件能力的下沉，从 Mesh","tags":["SOFAStack"],"title":"蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海 ","type":"blog","url":"/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","wordcount":4840},{"author":"SOFAStack社区","categories":"Summer 2021","content":"警告警告⚠️暑期即将到来，\n在暑期到来之前你有没有考虑过这样一个问题？\n那就是这个夏天怎么过？\n我相信你读完问题后脑海里浮现出了 N 多个想法，我相信那都是对你有意义的，但是你有没有考虑过让这个夏天过的更有“意义”一些。\n让你在这个夏天不仅可以让还是学生的你参与到知名开源项目，体验开源文化，与开源社区导师一同交流探讨的同时又可以收获一笔不菲的奖金，最重要的是可以获得一份特别亮眼的项目经历！！！\n动没动心？？？❤️\n 2021年的夏天被称为“开源之夏”\n那么什么是“开源之夏”？\n“开源之夏”全名开源软件供应链计划-暑期2021，是由中国科学院软件研究所与 openEuler 社区共同举办的一项面向高校学生的暑期活动，是一项专门面向高校学生的开源项目开发活动，旨在鼓励在校学生积极参与开源软件的开发维护。主办方联合各大开源社区，针对对重要开源软件的开发与维护提供项目任务，学生根据兴趣申请项目，中选后将在社区导师指导下进行开发，并将成果贡献给社区。根据项目的难易程度和完成情况，学生将获得 6000、9000、12000元不等的项目奖金。完成SOFAStack社区项目的优秀贡献者可以获得蚂蚁内推机会（蚂蚁中间件团队很多优秀的工程师都是被挖过来的开源社区贡献者🤫）\n活动官网：https://summer.iscas.ac.cn/\n暑期 2021 项目任务活动自发布以来，众多开源社区踊跃报名，5 月 20 日社区报名截止，共有 109 家海内外社区报名，并上线了 877 个开源项目任务。其中 SOFAStack 社区上线了 9 个项目任务，包含云计算、云原生、分布式系统、微服务中间件、前端等多个方向结合的项目任务，涉及的开源项目包括：JRaft、SOFA-RPC、SOFA-Registry、SOFADashboard、SOFATracer，有中、高等级不同难度的任务以供选择。\nSOFAStack 社区项目任务列表：https://summer.iscas.ac.cn/#/org/orgdetail/s\nsofastack 学生指南：https://summer.iscas.ac.cn/help/student/\n学生如何申请？\n学生申请通道 5 月 24 号正式开放啦！\n申请时间：5 月 24 日\u0026amp;ndash; 6 月 13 日\nSTEP 1 ：查看项目任务列表，你感兴趣的任务。可同步在官网报名系统注册账号进行报名。\n报名系统：\nhttps://portal.summer-ospp.ac.cn/summer/login\n STEP 2：就感兴趣的任务与对应的导师取得联系，沟通清楚项目需求，也可就项目方案和导师讨论。\nSTEP 3：撰写项目申请书，并在报名系统提交项目申请书和个人简历。\nSTEP 4：6 月 30 号公布中选结果，中选学生在导师指导下，按计划在 7-9 月进行开发。\nSTEP 5：完成开发，获得项目奖金和证书。\n详情可进一步阅读暑期 2021 学生指南：https://summer.iscas.ac.cn/help/student/\n暑期 2021 面向人群 本活动面向年满 18 周岁在校学生，不限国籍暑期即将毕业的学生，只要在申请时学生证处在有效期内，就可以提交申请海外学生可提供录取通知书/学生卡/在读证明证明学生身份\n ","date":1621839600,"description":"“开源之夏” SOFAStack 社区 9 个项目任务上线，学生申请正式开始！","dir":"activities/Summer 2021 of Open Source Promotion Plan/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9917f037c993814f23d2049396c438eb","permalink":"https://sofastack.github.io/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","publishdate":"2021-05-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","summary":"警告警告⚠️暑期即将到来， 在暑期到来之前你有没有考虑过这样一个问题？ 那就是这个夏天怎么过？ 我相信你读完问题后脑海里浮现出了 N 多个想法，我相信","tags":["Summer 2021"],"title":"“开源之夏” SOFAStack 社区 9 个项目任务上线，学生申请正式开始！","type":"activities","url":"/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","wordcount":1198},{"author":"朵晓东","categories":"SOFAStack","content":" 本文是云原生开放协同技术探索与实践一阶段的总结和综述。\n蚂蚁基础技术在过去3年多以来持续、深入推进全面的云原生化技术演进，我们将在线、离线计算资源装进了一台计算机，将服务体系通过 mesh 的思路和技术手段进行了下沉解耦，可以说比较充分的拥抱了云原生技术，并获取了其带来的技术红利。\n当完成了资源、服务的云原生化，我们发现在云原生基础能力之上的运维体系与云原生技术开放、共享的思路有较大的距离，在技术体系上也与云原生技术声明式、白盒化的思路相悖，同时由于缺少匹配的技术支撑，历史包袱等问题也成为了云原生运维难以真正代际演进的障碍。今天我要介绍的就是蚂蚁在这样的背景下在云原生运维方向进行的技术探索和实践。\n规模化云原生运维探索 我们先来回顾一下在蚂蚁真实的实践方式和面对的问题。首先，我们来看看蚂蚁践行多年的经典运维中台，这类运维平台一般包括了控制器、业务模型、编排引擎、原子任务及管道，在蚂蚁这样的平台是一系列服务的集合，他们较好的满足了集中式、标准化、低变更频率的应用发布及运维需求。但这种模式在实践中也存在着明显的不足。\n首先对于非标准应用、应用个性化需求、高成本需求、非紧急需求、技改类需求，往往无法较好的满足。在蚂蚁的实践中，非标运维需求、对核心应用模型及运维模型冲击较大的高成本改造需求、大量基础能力或运维功能的透出需求等长期无法得到较好的满足，需求往往是合理的，是难以获得足够的优先级执行落地。在研发阶段，运维平台长期积累了高复杂度的业务逻辑，修改测试涉及跨系统的长改造链路，同时基础能力的透出、运维能力的产品化依赖前端、服务端研发资源。这些问题使得运维平台研发日渐吃力，特别是在产品 GUI、业务模型、编排引擎等变更热点上，受限于扩展机制能力不足，内部实践中甚至出现过线上不断修改代码、发布服务以满足需求的情况。平台上线后，统一的质保和线上全链路功能验证同样面对较大的压力。对于最终的使用者，命令式按钮背后的黑盒计算透明度低，审计难，结果难预测，同时激情操作、操作界面不熟悉等问题也一直影响着线上的稳定性。这些问题长期存在，我们寄希望于代际的技术演进来解决这些问题。 \u0026amp;gt;当云原生基础服务逐渐稳定后，对于自身场景不在运维平台管理范围内的应用，研发同学自发的借助云原生社区工具链解决问题。基于 Kubernetes 生态高度开放、高度可配置的特点，研发者可以自助、灵活、透明的声明式应用运行、运维需求，以应用粒度完成发布、运维操作。\n用户通过 kustomize 等社区技术缩短了对接基础设施的路径，并通过如 velocity 等文本模板技术部分解决了静态 YAML 文件在较多变量时维度爆炸的问题，解决了默认值设定的问题，同时通过 code review 的方式进行多因子变更及评审。由于 Kubernetes 及其生态提供了面向资源、服务、运维、安全的横向能力，使得这种简单的方式可有很好的普遍性和适用性，通过对不同的 Kubernetes 集群 “播放” 这些数据即可完成对基础设施的变更，本质上是一种声明数据的流转。面向 git 仓库的研发方式和 gitops 流程支持对运维产品研发资源的诉求较低，往往可以比较简单的搭建起来，不强依赖产品研发资源投入。相比经典运维中台，这些好处清晰明确，但从工程视角缺点也非常明显。 \u0026amp;gt;首先 Kubernetes API 的设计较为复杂，仅是 Kubernetes 原生提供的 low level API 就暴露了 500 多种模型，2000 多字段，场景上几乎涵盖了基础设施应用层的方方面面，即使是专业同学也很难理解所有细节。其次这种方式的工程化程度很低，违反 DRY 原则，违反各团队职责能力高内聚低耦合的原则，即使在有一定的工具支持的情况下，在内部的典型案例中一个多应用的 infra 项目仍然维护了多达 5 万多行 YAML，同时由于团队边界造成的多个割裂的平台，用户需在多个平台间切换，每个平台的操作方式各异，加上跳板机黑屏命令，完成一次完整的发布需要 2 天时间。\n由于低工程化程度的问题，各团队间协同依赖人肉拉群同步，最终 YAML 由多个团队定义的部分组合而成，其中一大部分属于 Kubernetes 及运维平台团队的定义，这些内容需要持续跟踪同步避免腐化，长期维护成本高。\nKUSION: 云原生开放协同技术栈 以上两种模式各有利弊，优势和问题都比较清晰。那么能不能既要也要呢，能不能在继承经典运维平台优势的情况下，充分利用云原生技术带来的红利，打造一个开放、透明、可协同的运维体系？\n带着这样的问题，我们进行了探索和实践，并创建了基于基础设施代码化思路的云原生可编程技术栈 Kusion。\n大家都知道 Kubernetes 提供了声明式的 low level API，提倡其上生态能力通过 CRD 扩展的方式定义并提供服务，整个生态遵循统一的 API 规范约束，复用 API 技术和工具。Kubernetes API 规范提倡 low level API 对象松耦合、可复用，以支持 high level API 由 low level API “组合” 而成。Kubernetes 自身提供了利于开源传播的极简方案，并不包括 API 之上的技术和方案。\n回到云原生技术的本源，我们回看了 Kubernetes 前身 Borg 的应用技术生态。如下图示，在 BorgMaster 之上，Borg 团队研发了 Borg 接入三件套，即 BCL（Borg Configuration Language），Command-line tools，以及相应的 web service。用户可以通过 BCL 声明式编写需求，通过 Command-line tools 将 BCL 文件执行到 Borg 集群，并通过 web GUI 视图查看任务细节。经过大量的调研，我们了解到 Google 内部的运维能力及产品生态、质量技术生态都依赖这三件套构建而成，在内部也进行了多年的迭代演进。 \u0026amp;gt;这给了我们启发，今天我们有了容器技术、服务体系，有了大量用户和差异化的需求，有了一定数量的自动化运维平台，我们希望能通过云原生专用的语言和工具来链接 Kubernetes 生态、各个运维平台以及大量的用户，通过唯一事实定义消除运维平台孤岛，完成云原生基础设施在应用、运维层面的代际演进，达到 “Fusion on Kubernetes” 的目标。\n带着这样的目标，我们持续地进行做技术探索和实践，目前已经形成了 Kusion 技术栈，并在蚂蚁的生产实践中进行应用。 \u0026amp;gt;Kusion 技术栈基于这样的基础能力而工作，包括如下组成部分：\n云原生配置策略专用语言 KCL (Kusion Configuration Language)\nKCL 解释器及其 Plugin 扩展机制\nKCL 研发工具集: Lint, Format, Doc-Gen，IDE Plugin(IDEA, VsCode)\nKusion Kubernetes 生态工具: OpenAPI-tool, KusionCtl(Srv)\nKonfig 配置代码库，其中包括平台侧及用户侧代码\nOCMP (Open CloudNative Management …","date":1621321200,"description":"带你走进云原生技术：云原生开放运维体系探索和实践","dir":"blog/Take you into cloud-native technology: cloud-native open operation and maintenance system exploration and practice/","fuzzywordcount":10400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"365cd296d63b8ea2fa2e70b06830c734","permalink":"https://sofastack.github.io/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","publishdate":"2021-05-18T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","summary":"本文是云原生开放协同技术探索与实践一阶段的总结和综述。 蚂蚁基础技术在过去3年多以来持续、深入推进全面的云原生化技术演进，我们将在线、离线计算","tags":["SOFAStack"],"title":"带你走进云原生技术：云原生开放运维体系探索和实践","type":"blog","url":"/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","wordcount":10395},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@姚远 提问：\n 请问下 SOFAArk，master-biz 是个 Spring Boot 应用，A-biz 是个普通的Spring，一起打成一个 Executable-Ark 包。那么 Spring 相关的 Jar 是不是就要加载 2 次。 A：如果没有下沉插件的话，是会加载两次。\n SOFAArk：https://github.com/sofastack/sofa-ark\n@colin 提问：\n 内部服务之间的路由策略，是推荐用 service-mesh 来做吗？还是内部服务之间也用服务网关？ A：内部东西向流量推荐走 mesh ，一般来说网关更适合做南北向网络边界上的出入口。\n MOSN：https://github.com/mosn/mosn/\n@colin 提问：\n 这种场景，推荐用网关还是 service-mesh？目前我们是自己的内部网关来做的，网络不隔离，只是 jvm 进程隔离。 A：如果逻辑上也不隔离，互相能够服务发现，互相信任不需要额外鉴权的话，可以认为是内部流量，走 mesh 比走集中式的网关更合适。如果逻辑隔离，那么走网关比较合理。\n MOSN：https://github.com/mosn/mosn/\n@骆伟康 提问：\n 请问一下 这里我使用 dynamic 多数据源 结合 Seata 但是为啥只回滚了主库的数据 另外的库回滚失败？ A：看官网 FAQ，关闭 Seata 的自动代理，mp 的 dynamic 组件你开启他的 Seata 开关他自己会代理的。\n Seata：https://github.com/seata/seata\n@贾云森 提问：\n Could not commit JDBC transaction; nested exception is io.seata.rm.datasource.exec.LockConflictException: get global lock fail, xid:192.168.3.239:8092:138223831620784128, lockKeys:outpat_medical:135231296034705408,135231296034705409,135231296034705410,135231296034705411,135231296034705412,135231296034705413)\u0026amp;ldquo;,\u0026amp;ldquo;code\u0026amp;rdquo;:85550,\u0026amp;ldquo;data\u0026amp;rdquo;:null,\u0026amp;ldquo;time\u0026amp;rdquo;:\u0026amp;ldquo;2021-05-19 10:12:10\u0026amp;rdquo; 想问一下为什么会发生这种异常啊？ A：正常输出，竞争锁没竞争到。\n Seata：https://github.com/seata/seata\n@winyQ 提问：\n 项目里 Seata 用 AT 模式，可以在项目里再集成 JTA 吗，两个并存有没有什么问题？ A：JTA 是 XA ，无法跟 AT 兼容。\n Seata：https://github.com/seata/seata\n本周推荐阅读 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 金融级能力成核心竞争力，服务网格驱动企业创新\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n 本周发布 本周发布详情如下：\n本周 SOFAJRaft 发布 1.3.7 版本，主要更新如下：\n 1.修复 TCP 建连被 block 导致选主超时 2.升级 commons.io 到 2.8.0 以修复安全漏洞\n详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.7\n ","date":1621234800,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210521/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d7be1cbefe37ff9c846ea84f7ad52755","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210521/","publishdate":"2021-05-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210521/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210521/","wordcount":1146},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张思雨提问：\n 我配置中心里加了 transport.threadFactory.clientSelectorThreadSize\u0026amp;hellip;设置了个 100，这个值是不是一般设置成 cpu 核数*2 就够了啊？ 我之前遇到了 tc 调客户端的 commit 超时。我就把这种值都调大了试试效果 ， transport.threadFactory.clientSelectorThreadSize 100 transport.threadFactory.workerThreadSize 3000\n A：线程数这个东西这不该开放出去，很危险，对 netty 了解一点应该也知道 NioEventLoopGroup 的最多应该就核心数的两倍。 Seata：https://github.com/seata/seata\n2、@林南行提问：\n 大家好，请教一个问题：我现在用的 seata-server 的 1.3.0 的版本，客户端用的是 1.4.1 版本。当同时启动 10+个微服务连接 seata-server 的时候，只有 10 个能注册成功，剩余的必须重启后才能重新注册成功，这个是什么问题呢？\n A：试一下把 logSerialization 改成 kyro。 Seata：https://github.com/seata/seata\n3、@林南行提问：\n seata-server-1.3.0 和 seata-server-1.4.2 在配置上有什么区别吗？ 两边的 registry.conf 配置是一样的，但是 1.3.0 能正常启动，1.4.2 就报错，global_table 找不到。\n A：没区别，说明配置有问题，看看 global_table 写了没，写了的话，写的是什么，配置中心是什么，检查清除。 Seata：https://github.com/seata/seata\n4、@潘顾昌提问：\n 请问什么情况这个状态会是 Finished？现在导致这部分数据没有提交，但是也没有报错，正常的数据提交后看到的都是这个。 现在有些情况会返回 Finished，导致没有正常提交。\n A：事务结束了不就是 Finished，自己服务降级了吧，导致没回滚，部分插入部分没插入了。 Seata：https://github.com/seata/seata\n5、@潘顾昌提问：\n Finished 已经插入的数据会回滚丢失吗？我们后台实时监控到，一开始是插入到数据库的，确实是有的，但是结束以后数据就丢失了\n A：seata 没有执行二阶段回滚，不会消失数据，数据丢失要么是本地事务发生异常，你们捕获异常了，用 spring API 来回滚了本地事务，导致异常没抛出去，事务回滚了，要么发生异常，被你们的全局异常捕获器捕获了，导致决议了提交，实际上数据已经被本地事务回滚，seata 在二阶段不是 rollback 相关状态的时候不会干预业务数据。 Seata：https://github.com/seata/seata\n本周推荐阅读\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n Rust 大展拳脚的新兴领域：机密计算\n 开源项目是如何让这个世界更安全的？\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周发布详情如下：\n本周 sofa-registry 发布 V6-alpha 代码，本版本不建议生产使用，正式版本会在近期 release。主要更新如下：\n 支持应用级服务发现 基于 slot 分配的数据分片存储 详细参考：https://github.com/sofastack/sofa-registry/tree/v6-alpha1 文章解读：https://mp.weixin.qq.com/s/-5oK-EuZWpvIATvTzSMRAw\n","date":1620975600,"description":"SOFA WEEKLY | SOFARegistry 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210514/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7c193377953cba7840c05a3ff7d6d4ec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210514/","publishdate":"2021-05-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210514/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARegistry 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210514/","wordcount":1488},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@Chrosing 提问：\n Seata 被锁的 xid 数据 一直卡住的时候， 为啥丢失了一部分 undo_log 语句？导致直接删除 lock_table 的 xid 时候，没有回滚数据回去，当前版本 1.3.0。\n A：不会丢 undolog，只可能回滚了部分，部分因为脏写了导致没法回滚，这部分的 undolog 留着；所以看起来 undolog 少了，其实是分支回滚调了，留着的都是没有回滚的。\nSeata：https://github.com/seata/seata\n2、@洪波森 提问：\n 这算一个 bug 吗，永远跑不进来？\n A：不是，读不到你事务分组对应的值，就是 null。\nSeata：https://github.com/seata/seata\n3、@陈承邦 提问：\n sharding-transaction-base-seata-at 这个包只对 Seata 做了代理，我看了一早上源码，直接用 Seata 包 好像也不影响 分布式事务\n A：Seata 无法找到具体那个 datasource，Seata 只能代理 sharding-jdbc 最外层的 datasource，这个 datasource 里面有 N 个 datasource 来实现分库分表的功能，这个才是真正对数据库的 Seata：https://github.com/seata/seata\n4、@杨政伟 提问：\n 请教一个问题，如果 A 方法调用 B 方法，B 方法启用了事务，并发生异常时，但 B 方法并没有回滚，怎么能实现 B 方法的回滚？\n A：在同一个类里面被其他方法调用，是不能开启事务的，看一下 aop 的机制。a 是个实例 cglib 代理了 a 成为了一个包装了它的实例，此时你直接调了内部的实例，怎么走到它的切面去呢？\nSeata：https://github.com/seata/seata\n本周推荐阅读 下一代机密计算即将到来：性能比肩普通应用\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n Rust 大展拳脚的新兴领域：机密计算\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n ","date":1620370800,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-20210507/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4606adcc9195341f35c6dd05b0e93da1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210507/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210507/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210507/","wordcount":957},{"author":"英花","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#20：用安全计算保护关键业务\n 活动时间：05 月 19 日周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#20：用安全计算保护关键业务 随着全社会对隐私保护越来越关注安全计算也成了近期的热点。蚂蚁做为一家金融科技公司，特别注重用科技的方法来保护用户隐私。这次直播会介绍蚂蚁在安全计算方面的一些方法和实践。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 相和 蚂蚁集团安全计算团队 Occlum 项目负责人 （从事 Intel SGX 相关开发工作十多年，期间设计和主持开发了 Intel SGX SDK） 议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 用安全计算保护关键业务 相和 蚂蚁集团安全计算团队 Occlum 项目负责人\n你将收获 了解Intel SGX 技术和蚂蚁开源的 Occlum 产品。 了解如何用 Occlum 来保护已有的 SOFABoot 应用。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1620370800,"description":"05 月 19 日周三晚 19 点，线上直播第 20 期。","dir":"activities/sofa-channel-20/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f41faefa3f35c17635d73634cf7a50f5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-20/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-20/","summary":"概要 活动主题：SOFAChannel#20：用安全计算保护关键业务 活动时间：05 月 19 日周三晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播间","tags":["SOFAChannel","Occlum"],"title":"SOFAChannel#20：用安全计算保护关键业务","type":"activities","url":"/sofastack.tech/activities/sofa-channel-20/","wordcount":551},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAStack Meetup#5 上海站 容器沙箱专场\n 活动时间：2021 年 05 月 22 日（周六）14:00-17:00\n 活动地点：上海市浦东新区蚂蚁 S 空间 南泉北路 447 号 201\n 活动形式：线下活动\n 资料下载： 《边缘计算中的 Kata Containers\u0026amp;gt; 《快速闪电：Nydus 镜像加速服务》 《WebAssembly Micro Runtime：云原生时代的超轻量级新型沙箱》 《WebAssembly 在 MOSN 中的探索与实践》\n 活动介绍 活动议程 本期议题以及嘉宾详解 《边缘计算中的 Kata Containers》\n嘉宾介绍\n李枫，先后就职于摩托罗拉, 三星等IT公司, 现为独立开发者。在移动平台上积累了十年以上的研发经验, 近几年主要专注于云计算/边缘计算基础设施领域。是《灰帽黑客 第4版：正义黑客的道德规范、渗透测试、攻击方法和漏洞分析技术》和《恶意网络环境下的Linux防御之道 》中文版的主要译者。对技术创新具有浓厚的兴趣和实践能力，热心参与开源社区的各种活动，多次参加各种IT会议并作技术分享。\n议题简介\n Kata Containers 具有的轻量和高安全等特性使它在资源受限和安全性需求的物联网/边缘计算领域有很好的应用前景, 并且可以与其他轻量级解决方案（如 K3S 等）进一步结合使用。本话题包含下列子话题： 1) LF Edge（由 Akraino 和 EdgeX 合并而成）中的 Kata Containers； 2) 打造轻量级 K8S 集群\u0026amp;ndash;Kata-Containers 与 K3S 的结合； 3) 在 ACRN 中运行 Kata Containers； 4) 将 Kata Containers 应用于边缘云。 听众收获\n 了解 Kata Containers 的基本情况 了解 Kata Containers 在边缘计算场景的应用前景 《快速闪电：Nydus 镜像加速服务》\n嘉宾介绍\n彭涛，蚂蚁集团可信原生技术部高级技术专家，Linux 内核和文件系统开发者，近年来主要关注容器运行时相关技术，是 Kata Containers 维护者和架构委员会成员，Dragonfly 镜像服务 nydus 的作者之一，云原生技术浪潮的坚定支持者。\n徐佶辉，蚂蚁集团可信原生技术部技术专家，Dragonfly 镜像服务 nydus 的作者之一，负责 nydus 在蚂蚁的落地。\n议题简介\n 有研究表明，容器镜像拉取占据了容器启动时间的 70%，而容器启动实际上只需要访问容器镜像不到 6% 的数据量。基于此，我们设计实现了可以按需加载容器镜像的 nydus 镜像加速服务，在内部大规模部署，并开源贡献给 Dragonfly 社区。本话题将向大家介绍 nydus 项目的背景，架构和技术细节，以及我们对容器镜像生态的展望。 听众收获\n 了解当前 OCI 容器镜像格式优缺点 了解 nydus 项目的背景，架构和技术细节 了解容器镜像生态的发展趋势 《WebAssembly Micro Runtime：云原生时代的超轻量级新型沙箱》\n嘉宾介绍\n王鑫，英特尔高级工程经理，WAMR(WebAssembly Micro Runtime)项目的创建者，主要工作集中在管理语言运行时和Web技术，2009年以来领导了Java和WebAssembly虚拟机运行时开发、V8 JavaScript引擎的性能优化等相关工作。加入英特尔之前，在摩托罗拉主要作为技术Leader，负责无线基站系统相关的工作。\n议题简介\n 近年来WebAssembly在服务器侧及云原生场景中越来越流行，WAMR(WebAssembly Micro Runtime)是字节码联盟(Bytecode Alliance)旗下的WebAssembly独立运行时开源项目，支持多种软硬件平台，支持解释器/AOT/JIT等多种执行方式，性能优异，资源占用少，对多线程和SIMD也有良好的支持。这次分享将介绍WAMR的架构、特性、社区合作及在云原生场景中的应用。 听众收获\n 了解WebAssembly这一新兴技术 了解WAMR开源项目的架构、特性及社区合作 了解WAMR在云原生场景中的应用实例 《WebAssembly 在 MOSN 中的探索与实践》\n嘉宾介绍\n叶永杰，蚂蚁集团可信原生技术部软件工程师，开源项目 MOSN 核心成员，目前关注云原生 ServiceMesh、WebAssembly 等相关领域。\n议题简介\n 随着云原生数据面 MOSN 在蚂蚁金服内部的大规模落地，安全隔离逐渐成为急需解决的问题之一。为此，我们利用 WebAssembly 基于给定资源的安全模型，依托于社区 Proxy-Wasm 开源规范，为 MOSN 中的扩展插件提供了一个独立隔离的沙箱环境。这次分享将介绍 MOSN 的背景，WebAssembly 在 MOSN 中的实践、以及我们在 Proxy-Wasm 开源规范上的贡献。 听众收获\n 了解云原生数据平面 MOSN 的基本情况 了解 Proxy-Wasm 开源规范的基本情况 了解 WebAssembly 技术在云原生数据平面的实践案例 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1620370800,"description":"SOFAStack Meetup#5 上海站 容器沙箱专场","dir":"activities/sofa-meetup-6/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"411a4b0f323c4d5ced46847b710a948d","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-6/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-6/","summary":"概要 活动主题：SOFAStack Meetup#5 上海站 容器沙箱专场 活动时间：2021 年 05 月 22 日（周六）14:00-17:00 活动地点：上海市浦东新区蚂蚁 S","tags":["SOFAMeetup"],"title":"SOFAStack Meetup#5 上海站 容器沙箱专场","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-6/","wordcount":1805},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@李明 提问：\n 请教一下： SOFATracer 用 3.1.0 版本对应 SOFABoot，应该使用 3.1. 版本吗？\n A：都可以，不依赖 SOFABoot 版本。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@黄海淇 提问：\n 有没有 SOFABoot 从零开始的文档哇？这家公司用的 SOFA 相关的组件做的银行项目。\n A：https://www.sofastack.tech/projects/sofa-boot/overview/ ，在我们社区各个项目的主页介绍里面都是有文档的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@陈承邦 提问：\n undo_log 日志当时回滚删除，还是过一段时间批量删除？ A：回滚删除，status 为 1 的 7 天删除。\nSeata：https://github.com/seata/seata\n4、@贾云森 提问：\n @GlobalTransactional 这个注解下的，不同 Service 的数据库操作，都要加本地事务吗？\n A：AT 模式下不需要。\nSeata：https://github.com/seata/seata\n5、@天成 提问：\n 问下：生产跟预发感觉也得搭建 2 个 seata-server，不能共用一个对吧？\n A：可以共用一个，因为锁需要共享才能排他；也可以分开，但是要用表共享，具体看官网事务分组。\nSeata：https://github.com/seata/seata\n本周推荐阅读 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 开发 Wasm 协议插件指南\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n ","date":1619766000,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-0430/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8225fa5618621f7b6ea3e7504b74610a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0430/","publishdate":"2021-04-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0430/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0430/","wordcount":903},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谭新宇 提问：\n 请教 SOFAJRaft 的问题：默认的 election timeout 这么小嘛？业务压力比较大的话感觉很可能发生超过 1s 的 STW GC 吧，这时会不会导致频繁换主。\n A：最好调整下默认参数，不过 1s 的 STW 实际上也不太正常，需要优化。\nSOFAJRaft：https://github.com/sofastack/sofa-jrafta\n2、@刚刚 提问：\n SOFARPC 是通过 MOSN 转发协议？SOFA RPC 对外注册的 IP 在 k8 的容器是什么策略？\n A：：MOSN 支持 SOFARPC 协议的转发。\nA：服务发布订阅没有做啥特殊的，就和原来是一样的。\nMOSN:https://github.com/mosn/mosn\n3、@王哲 提问：\n 问下 MOSN 对 Kubernetes 版本有限制么？\n A：MOSN 对 K8s 没有强制版本要求，不过 Istio 是对其有版本要求的，具体可以看文档：https://istio.io/latest/about/supported-releases/#support-status-of-istio-releases。\nMOSN:https://github.com/mosn/mosn\n4、@王哲 提问：\n 我试了下 mosn bookinfo出现了这个问题：那个 demo Istio 注入后 yaml 文件是 OK 的，但是运行时 describe pod 看 binaryPath 又变成了 envoy，下面是运行时的，不知道是不是因为这个问题？\n A：看起来是你修改的路径没有生效，可以先在 configmap 里面修改下这个 binarypath 。\nMOSN:https://github.com/mosn/mosn\n5、@朱闯 提问：\n 请教个问题：saga 模式下是无锁的，一阶段就提交了本地事务，那么也会出现脏写而导致没法正常回滚事务的情况吧。\n A：所以允许向前重试，最终一致。向前是最终一致，没有脏写。\nSeata：https://github.com/seata/seata\n6、@何凯博 提问：\n 请教下各位大佬，xa 模式下 Seata 是怎么实现事务隔离的？\n A：xa 就是本地事务隔离，把本地事务 prepare，到二阶段再提交或者回滚。\nSeata：https://github.com/seata/seata\n7、@谢太阳 提问：\n A 项目独立库，B 项目用 sharding jdbc 分库分表，A 项目发起分布式事务，出现异常，B 项目不回滚，请教这个一般是什么问题呢？上面是 A 调用 B 的日志，没有分支的回滚记录。下面 B 调用 A 是正常的。\n A：xid 传递检查一下，数据源代理没成功，或者 xid 没传递。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Rust 大展拳脚的新兴领域：机密计算\n 开发 Wasm 协议插件指南\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n 本周发布 本周发布详情如下：\n1、Occlum 发布了 0.22.0 版本，主要变更如下：\n 三个新的 demo：redis，Flink 和 Enclave RA_TLS 支持 /dev/shm 文件子系统 支持 golang1.16.3 详细参考：\nhttps://github.com/occlum/occlum/releases/tag/0.22.0\n","date":1619161200,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-20210423/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"30345ac491d8918983986d2f4cf1d058","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210423/","publishdate":"2021-04-23T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210423/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210423/","wordcount":1277},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@藜蒿 提问：\n 请问一下，SOFATracer+SpringBoot 如何在 spring-mvc-digest.log 增加 rest 请求的请求体数据在 json 日志中。需要打印 request 数据，不单单是 url 上的，可能是 post 请求放在 body 里面的。A：可以用这里的命名空间：\n A：这个暂时不行，不过你可以通过手动埋点的方式去拿这些信息，可以提个 issue ，详细描述下场景诉求。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@南桥 提问：\n 请问下 select * for update, 在 Seata 的事务中，除了会加一个全局的锁，还会加数据库锁吗？ 如果一条记录在分布式事务中，已经加了 for update 读。 那么这条记录再在数据库本地事务中，不加 @GlobalLock，加 for update 读，能读到吗？\n A：不会加全局锁，先加本地锁。\nA：如果要根据读的结果来写，为了得到分布式事务下的已提交数据，需要 for update。数据库层面可以快照读，但是无法当前读（for update 会阻塞），上了分布式事务后，结果都是二阶段后才是准确的，因为有了分布式事务的概念，在此之下的所有本地事务，也就是数据库方的数据已经不能算是准确的了，因为在 AT 模式下随时都有会回滚数据。\nSeata：https://github.com/seata/seata\n3、@姜广兴 提问：\n saga 模式 demo 中的服务都有对应的补偿服务，如果对接外部系统，没有提供相应的补偿服务，还可以使用 saga 模式吗？\n A：可以，没有补偿服务就不补偿，可以向前重试。\nSeata：https://github.com/seata/seata\n4、@彭勃 提问：\n 看到这段，我请教一下。目前，我们自己通过再加一个 mysql MGR 集群去回避这个外部持久化单点故障的问题请问有人有过相关实践吗？您觉得可行吗？\n A：可以这么做，MGR 的话性能应该就比单 DB 要下降了，但是比主备要靠谱，主备的话还是有可能丢数据，MGR 有一致性协议存在，理论上没什么大问题。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Rust 大展拳脚的新兴领域：机密计算\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n 本周发布 本周发布详情如下：\n1、SOFATracer **** 发布 v3.1.1 版本，主要变更如下：\n 添加数据脱敏扩展点，默认无对应的开源实现，用户可以自定义；商业版则提供了该实现 。\n详细参考：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.1.1 ","date":1618556400,"description":"SOFA WEEKLY |SOFATracer 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210416/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6e17e1cbdfbb154ddbe2066aa24dabfa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210416/","publishdate":"2021-04-16T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210416/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210416/","wordcount":1212},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA开源三周年，Let\u0026amp;rsquo;s have fun together\n 活动时间：2021 年 04 月 24 日（周六）14:00-17:00\n 活动地点：北京海淀中关村创业大街72号拓荒族众创空间（三层路演厅）\n 活动形式：线下活动\n 资料下载：\n 《SOFAStack 三周年分享》下载链接\n 《Enabling Financial-Grade Secure Infrastructure with Confidential Computing》下载链接\n 《云原生网络代理 MOSN 新的助推器—Envoy》下载链接\n 《注册中心 6.0 新特性》下载链接\n 《服务网格在企业落地的典型场景与实践》下载链接\n 活动介绍 SOFA 开源三周年， Let\u0026amp;rsquo;s have fun together！北京，我们来啦！\n不知不觉，我们已相识三年，\n很开心能邀请你一起来见证 SOFAStack 社区三周年，\n三年的时间，见证了 SOFAStack 在各个行业环境中的成长，是我们 SOFA 星球的骄傲。\n我们将在北京迎来 SOFA 三周岁的生日，期待与你一同分享！\n活动议程 本期议题以及嘉宾详解 《SOFA 三周年 \u0026amp;mdash;- 一起做些有趣的事儿吧！》\n嘉宾介绍\n黄挺，蚂蚁集团资深技术专家，目前主要负责蚂蚁中间件团队，推动了蚂蚁 Service Mesh，Serverless 等云原生技术在蚂蚁落地。\n议题简介\n SOFA 开源已经进行了三年的时间，在本次分享中，将会带大家了解 SOFA 开源三周年以来的一些心路历程，介绍 SOFA 开源未来的发展方向. 听众收获\n 了解 SOFA 开源的现状 了解 SOFA 开源的未来的发展方向\n 《机密计算如何为金融级基础设施保驾护航》\n嘉宾介绍\n田洪亮，蚂蚁集团高级技术专家，在机密计算、可信执行环境（TEE）和系统软件方面拥有丰富的经验，是蚂蚁自主研发的开源 TEE 操作系统 Occlum 的架构师。在加入蚂蚁之前，供职于 Intel 中国研究院。他于清华大学获得博士学位。\n议题简介\n 构建金融级基础设施的重要一环就是金融级安全性，而这正是 SOFAStack 技术栈中的 Occlum 项目所瞄准的目标。本次演讲将介绍蚂蚁集团在机密计算（Confidential Computing）和可信执行环境（TEE）方面所做的努力，尤其是如何通过蚂蚁自研的、开源TEE操作系统 Occlum 来实现零门槛、高性能的机密计算。 听众收获\n 了解机密计算这一激动人心的新兴技术方向；\n 了解机密计算领域的重要进展\n 《云原生网络代理 MOSN 新的助推器 —Envoy》\n嘉宾介绍\n王发康，蚂蚁集团技术专家，专注于高性能网络服务器研发，MOSN、Tengine 开源项目核心成员，目前关注云原生 ServiceMesh、Nginx、Envoy、Istio 等相关领域。\n议题简介\n MOSN 在 Service Mesh 领域作为东西向服务治理网络在蚂蚁集团双 11 、红包等活动及开源社区都得到了实践，为进一步节省研发及运维等相关成本，目前业界也有东西和南北向数据面进行统一的趋势。该演讲主题介绍了如何使用 Envoy 作为 MOSN 的网络层扩展，将 MOSN 和 Envoy 生态打通，同时使得 MOSN 底层网络处理能力具备 C/C++ 同等高性能、满足南北向高并发场景，又能复用 MOSN 的服务治理能力及 GoLang 的高研发效率。 听众收获\n 可快速了解如何使用 MOSN/GoLang 来扩展 Envoy 的服务治理能力\n 收获 MOSN 扩展 Envoy 时遇到的踩坑事项\n 了解 MOSN 开源社区进展\n 《新版 SOFARegistry 的多个 10X 提升》\n嘉宾介绍\n李旭东，蚂蚁集团中间件高级开发工程师，SOFARegistry Committer，专注于分布式中间件开发与优化。毕业后先后参与分布式服务发现体系构建和企业级 ServiceMesh 平台的开发。\n议题简介\n 随着集群的规模越来越大，服务注册中心的压力也越来越大。如何通过应用级服务发现改造减少服务数据一到两个数量级。现有服务如何利用 MOSN 无感知平滑迁移到应用级服务发现。分布式注册中心如何提高稳定性，如何利用混沌测试提前发现问题。SOFARegistry未来的发展方向。 听众收获\n 了解应用级服务发现如何进行实现和改造以及迁移的方案\n 分布式注册中心的质量和稳定性如何保障\n 《服务网格在企业落地的典型场景与实践》\n嘉宾介绍\n王磊，时速云CTO，负责时速云企业级容器 PaaS、中间件、DevOps、微服务治理、API 网关等多个云原生产品及相关解决方案的架构、产品和研发管理工作，对云原生相关领域有较深的理解及丰富的落地经验，致力于为企业构建新一代以应用为中心的云原生基础平台。曾在IBM中国开发实验室从事IBM中间件、Bluemix PaaS平台等产品的研发和设计工作。\n议题简介\n 当前，应用的微服务改造正在许多企业中如火如荼地进行，然而，微服务改造后的治理问题成了其进一步发展的障碍。在这一背景下，Service Mesh 应运而生，通过将治理能力下沉到基础设施层的方式来降低对业务应用的侵入。从实际需求出发，时速云基于 MOSN 等技术研发了自己的服务网格产品，克服了落地中的各种障碍，目前已在金融客户的核心生产系统中运行了1年多的时间，算是较早落地服务网格的典型案例。在这个过程中我们也感悟到，技术的先进性是持续追求的方向，而如何更好的结合实际场景才是推进服务网格落地的关键。本次分享主要介绍一下我们在落地服务网格时碰到的一些典型需求场景及实践经验。 听众收获\n 了解企业对于服务网格的典型诉求\n 了解服务网格落地时面临的主要问题与相关解决方案\n 服务网格的典型使用场景及未来展望\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1618210800,"description":"SSOFA 开源三周年，Let's have fun together！","dir":"activities/sofa-meetup-5/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"aee1e29a3825c8fdcafee69bc8a1613e","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-5/","publishdate":"2021-04-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-5/","summary":"概要 活动主题：SOFA开源三周年，Let\u0026rsquo;s have fun together 活动时间：2021 年 04 月 24 日（周六）14:00-17:00 活动地点：北京海淀中","tags":["SOFAMeetup"],"title":"SOFA 开源三周年，Let's have fun together！","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-5/","wordcount":2041},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@闫文超 提问：\n 问下 SOFARPC 注册到 nacos 上，可以指定 group 的名字吗？想用于不同租户的隔离的功能。\n A：可以用这里的命名空间：\nnamespace :com.alipay.sofa.rpc.registry.nacos.NacosRegistry。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@霂白 提问：\n 注解方式发布的服务，有插件能自动生成给其他语言使用的 protobuf 的文件吗？Java 已经写了接口和 bean 的结构，直接转换为对应 pb 的文件。现在有 pb的定义文件转换注解方式的，Java 的代码的 maven 插件吗？写 pb 转 Java 或者写 Java 转 pb 两个方向总有一个通的吧，不然又写 Java，又写pb？\n A：这个我理解目前应该是没有的，不过确实是一个比较有意思的方向。\nA：pb 转 Java 问题不大，有现成的工具， 自己写一个也不是很复杂，Java 转 pb 不太兼容；pb 不支持两个参数，这里的问题在于传输协议，不在于代码格式，有需要我们开个 issue 详细聊下 ，鉴权这块后续应该会交给 MOSN 来做。 SOFAStack：https://github.com/sofastack/sofastack.tech\n3、@阿怪 提问：\n 请教大佬一个问题：TCC 模式，事务异常，回滚走自定义实现的 cancel 方法，这个方法里面操作了数据库回滚并且报错，有两个问题： 1.重试次数如何配置？ 2.线程的 ThreadLocal 的数据无法获取，BusinessActionContext 这个类获取不到，可不可以配置？\n A：那就用 localtcc，一开始的 TCC 不支持 spring cloud，后续开发了个 localtcc 的注解和功能来满足。 Seata：https://github.com/seata/seata\n4、@冯明明 提问：\n 我用的是最新版的 spring-cloud-ablibaba rpc 使用的 Dubbo 。截图中这种依赖方式，必须在接口上增加@LocalTcc 才能应用 TCC 模式。我看源码 这种依赖生成的是 xxx.proxy0 这种实现类不能被 RemotingParser解析，接口提供者倒是能被解析，但 DubboRemotingParser 生成的 RemoteSpec 的 protocol 属性是 Dubbo，源码中只有 injvm 能走 TCC 的相关逻辑，请问我是哪里没有配置正确吗 ?\n A：1.方便以后出控制台可以实时查看分支事务状态； 2.比如某些分支吞了异常后，有 report 的情况下方便判断。比如：a 调 b 再调 c，b 其实已经出现异常并且本地事务下已经回滚了，此时 c 响应给 a，a 做后续处理的时候异常，此时 TC 发现 b 已经由本地事务回滚了，就无需驱动了，这样就减少了下发的数量。 Seata：https://github.com/seata/seata\n5、@张红亮 提问：\n 能在 service 实现里再次调用的方法上加 @GlobalTransactional 吗？\n A：可以的，跟本地事务注解一样，支持事务传播。 Seata：https://github.com/seata/seata\n本周推荐阅读 Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n 本周发布 本周发布详情如下：\n1、SOFAJRaft 发布 v1.3.6 版本，主要变更如下：\n 增加 Replicator 的状态变化监听器  RheaKV 增加批量原子更新 API  Grpc 模块支持 max_inbound_message_size 配置  优化 RheaKV 内存占用  详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.6\n","date":1617951600,"description":"SOFA WEEKLY | SOFAJRaft 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210409/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"403b28d70a485885d5c8b391175a5f81","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210409/","publishdate":"2021-04-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210409/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210409/","wordcount":1512},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 请教一下：为什么 KVStoreStateMachine#onSnapshotLoad 是 leader 的时候，不去做；leader 节点如果之前进行过 snapshot 之后，raft log 应该会被删除吧；后续集群重启的时候，leader 不用 snapshot 怎么保证数据还原呢？\n A：想一下，如果它还需要 load snapshot 的话，它是怎么变成 leader 的，如果已经是 leader 了，肯定不需要 load snapshot；理论上不会走到这个分支，只是防御性的代码，如果走到这个分支，就直接报错停止状态机了。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@明惑 提问：\n 现在创建 Grpc Server 的时候，只提供了 port 配置，考虑放开一些参数可以用户配置吗？比如 grpc 的 messageSize。\n A：helper.config看一下。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@刘明明 提问：\n 请教一下：我现在想用 Go 去写一个组件当一个简易的 Sidecar 去对其他服务做健康检查。这个 Go 组件要整合 nacos 注册发现和元数据管理，后期也会整合 Istio，这个组件干的事情应该和 MOSN 类似，Go 这边 0 基础，我是写 JAVA 的，就比如这个用 JAVA 实现只需要 springboot 就好了，Go 这边我调研了下准备用 go-Micro，请问各位这个方向是否正确？\n A：可以参考这个实现： https://github.com/mosn/mosn/issues/1087 这个是直接对接 zk 做的。\nMOSN：https://github.com/mosn/mosn\n4、@彭勃 提问：\n 请教一下，关于 TCC 模式下，会有发生空回滚，资源悬挂，幂等性等问题，需要通过事务控制表去管理。我此前看到同学介绍它们会将事务控制表变成 TCC 模式的一部分（2020 年初），让业务开发者不用自己关注这些问题，请问现在 TCC 模式已经做了吗？\n A：目前只能支持单数据源下的防悬挂，直接利用开启 spring 本地事务，然后做一些前置操作来预防。\nSeata：https://github.com/seata/seata\n5、@王译锌 提问：\n 请教一下：既然回滚依赖于异常上报给 TM，那为什么分支事务的状态还要上报给 TC 呢？一直没想通这个问题。\n A：1.方便以后出控制台可以实时查看分支事务状态； 2.比如某些分支吞了异常后，有 report 的情况下方便判断。比如：a 调 b 再调 c，b 其实已经出现异常并且本地事务下已经回滚了，此时 c 响应给 a，a 做后续处理的时候异常，此时 TC 发现 b 已经由本地事务回滚了，就无需驱动了，这样就减少了下发的数量。\nSeata：https://github.com/seata/seata\n本周推荐阅读 WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n ","date":1617346800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210402/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"99c3b3c82b2f3fb86b66e6632aef8a20","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210402/","publishdate":"2021-04-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210402/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210402/","wordcount":1337},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 使用 jraft 跨 IDC 搭建了集群，一旦读 follower 节点，有 13ms 的网络延迟，用了lease read，读 leader 还好，直接返回。读 follower，要和 leader 通信，hreadb 有跨机房部署的场景吗？\n A：ollower 节点提供读能力，属于额外赠送的能力，其实 readIndex 的实现必须要和 leader 现有一个通信，这个没办法；我们不开 follower 读，从 leader 读；etcd 的 read-index 也是一样的原理，都需要请求一次 leader， zk 我了解貌似还不支持 follower 读；当然如果你不要求线性一致读，那么你绕开 raft 状态机，直接从你的存储里面读就好，如果你要的是最终一致性，那么你直接从 follower 节点上绕过 raft 直接读。 A：核心就是：follower 节点必须知道 leader 此时的 applyIndex 到哪里，然后需要再等待自己状态机的 applyIndex 也到达这个位置了才能提供读，否则就有可能一个数据 leader 上有，follower 上没有，这就很明显违背了线性一致读，所以和 leader 的这一次通信必须有，不过数据包很小，通常应该很快。 SOFAJRaft：https://github.com/sofastack/sofa-jraft 2、@吴岳奇 提问：\n 需求场景：AbstractRoutingDataSource 动态切换数据源，同一方法下，对两个不同服务器上数据表新增，涉及分布式事务。 问题: springboot 整合 Seata AT 模式 ，但无法动态代理数据源，一直代理的 yml 配置的默认的数据源。\n A：多数据源关闭自动代理；bstractRoutingDataSource 内部的多个数据源手动代理后放进去。 Seata：https://github.com/seata/seata 3、@彭勃 提问：\n 我在启动 Seata server 的时候，日志里报告了这种找不到 zookeeper 相关节点的异常；KeeperErrorCode = NoNode for /seata/store.mode。\n A：应该是用了zk 当配置中心，但是又没有写配置进去。 Seata：https://github.com/seata/seata \n本周推荐阅读 MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n ","date":1616742000,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210326/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"617144edd18f95b94e5860ed416ed165","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210326/","publishdate":"2021-03-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210326/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210326/","wordcount":1116},{"author":"嘉祁","categories":"Service mesh","content":" 本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。主要分为 3 个部分： -介绍 MOSN 在规模化运维中遇到的挑战 -无人值守上的实践 -MOSN 与技术风险方面的思考\n MOSN 规模化后的运维挑战 MOSN 早期在内部推进的时候，变更方面的支持是比较传统的。早期的变更工具只有基础的 pod 粒度的 MOSN 升级的能力。变更过程中的问题，最初依赖于上层业务系统的监控和反馈，稍后我们又在 MOSN 内建设了错误码。发布控制上，将版本区分为稳定版和灰度版本，升级的灰度过程和大范围的覆盖过程都由人工控制。这些方式在小范围、大量人力投入的情况下，保证了 MOSN 早期的快速演进和范围覆盖，也兼顾了基本的稳定性需求。\n随着 MOSN 的成熟，MOSN 的接入规模快速增长到了覆盖多个技术栈，数千应用的数十万 pod，涉及蚂蚁内部几乎所有的业务，早期的这些做法也遇到了很多问题。我们接入的应用不再只是 SOFA 技术栈的某些版本，业务也不再局限在某几条链路，大范围变更影响范围数倍甚至数十倍增长，风险变得极高，需要投入大量的人力评估每一个版本变更的影响。 举个例子，早期的 MOSN 几乎只需要考虑与较新版本的 SOFA 的对接。而当 node.js 应用开始接入时，MOSN 的变更也需要相应的考虑对 node.js 应用的影响。\n同样是为了减小风险，变更过程中尽可能减少单位时间的可能的影响范围，变更时长不可避免被拉长。\n早期的 MOSN 可能只需发布数十个应用，当范围扩大到过千时，如果单位时间发布的 pod 数据不变，那么变更时长即增加数十倍，变更的总时长变得荒谬。而如果总时长不变，则影响面和风险增加数十倍，风险不可控，业务也无法接受。\n最终结果是平衡单位时间的影响面和变更时长，风险放大无法避免，整体的迭代周期同样变长。更糟糕的是，新的特性不断堆积在下一个大版本，bugfix 也难以及时上线。这些问题最终不仅推高了下一次变更的风险，甚至直接影响当前生产的稳定。\n这么一个负向的循环需要如何打破呢。我们希望跳出传统的运维模式，既要变更的高效率，又要整体的稳定性。我们希望用技术来解决问题。\nMOSN 的无人值守变更 关于无人值守，一个可以借鉴的定义来源于近年火热的自动驾驶领域。同样都是希望把人从乏味的工作中解放出来，同样都需要面临复杂的环境问题。\n自动驾驶领域的等级定义方式也给了无人值守变更一个很好的参考点。最低级别的是 L0，一切都是人工操作，像云时代之前的时代，从装系统到应用部署，都依赖于人工命令行处理。 然后是 L1，平台提供了原子粒度的变更工具支持和基础的观察工具支持，如同早期的 MOSN。\n当这些工具更完善，提供一些基本的流程编排能力之后，开始进入自动化的时代，但可能随时需要人工介入处理。在此基础上，加上自动化的观测规则，把人工观察介入变成系统自动阻断，变更开始具备了无人值守的基本能力。 历经一年多的演进，MOSN 当前就处于这个阶段。我们也还在持续的完善和打磨，向着完全无人干预的方向演进。\n接下来我们来看 MOSN 是如何逐步达到无人值守的。 首先来看下风险的防控。前面我们提到，在传统的变更流程里面，需要人工介入的有变更范围控制；还有变更准入的检查，变更批次完成后，还要抽查确认变更结果以及业务异常情况。 也就是图上标红的这些内容。\n但是人本身是不可靠的。人为控制变更范围意味着灰度过程无法保证，准入的检查会存在比如信息不同步，规则遗漏的情况，完成情况的检查在大量应用或 pod 同步变更时，也只能做到少量抽检，无法避免问题被漏过。 把人工介入的部分交给系统，我们就有了一个初步可以脱离手动操作和人工观察的流程。\n上图展示了变更防御的介入流程。 变更范围改为由算法来自动产生的带有强度灰度的批次范围。前置准入与后置检查通过将变更类型与变更范围传递给变更防御的检查，通过检查才能继续执行。\n举一个简单的场景。MOSN 覆盖很多不同业务的链路，各业务有不同的变更保护时段，怎么来解决呢？\n首先在已经业务有保护时段的情况下，我们当然不能不管业务的风险强行变更。在有变更自动防控之前，我们只能找个共同的可变更时段，很多时候这就是半夜，但对于 MOSN 这么大规模的变更，半夜变更不仅仅是影响研发和运维幸福感的问题，只有半夜能变更的话，效率也无法接受。而有了变更的自动准入阻断规则，这个时间选择的问题立即就不存在了，我们只需要把所有应用的变更都跑起来，系统自动判断各自的可执行时段，甚至不需要参与变更的各方都知道所有业务的可变更时段。\n变更防控上线以后，极大的解决了我们的变更风险问题。但它并没有解决效率问题，一段时间来看，我们的效率甚至下降了。为什么? 我们分析了自身的变更过程，注意到两点：一是我们引用的业务错误的检查标准不一，部分业务的敏感度偏高或是阈值不合理，导致变更被持续阻断，无法继续；二则我们的全面检查放大了上面的问题，多个批次下来被中断的的概率也极大的提高了\n仔细来看业务的错误检查。这些检查不仅说明了 MOSN 自身的检查，还包括了业务的自身的错误和其它中间件、基础设施的问题。这些检查无法直接说明 MOSN 自身的健康情况。怎么解决呢？我们决定不再依赖这个不靠谱的检查，由 MOSN 自己来说明自己的健康情况。\n我们在 MOSN 中建设了两个层面的健康度观测能力。第一层是静态健康度，主要是 MOSN 的启动自检，在流量进入前完成，体现 MOSN 运行环境和基本启动依赖的健康情况；第二层是动态健康度，主要是 error metrics 日志，体现核心功能运行状态。结合这两层健康层，MOSN 就具备了完整了自身状态的观察能力，可以把业务的错误检查从变更检查中移除。\n我们还做了一个进一步提升变更效率的事情，彻底解决业务冷启动消耗的时间。\n无论是传统的原地升级或者是滚动升级的模式，过程都无法避免业务需要冷启动。由于业务依赖比较多，大部分业务的启动速度和成功率是大幅低于 MOSN 的，因此业务的冷启动时间一直是 MOSN 变更时间的大头。\n一个很好的解决方案是热升级。MOSN 自身是具备热升级能力的，下图展示了热升级的过程。 稍微解释一下的 MOSN 热升级过程。sidecar operator 会给待升级的 pod 注入一个新版本的 MOSN sidecar，旧版本的 MOSN 会收到连接迁移的请求，所有的长连接会被新版本的 MOSN 接管，完成之后旧版本 MOSN 会停止，sidecar container 被删除。\n热升级是一个很理想的升级方式，但是完善的热升级需要的条件和环境都比较复杂，需要 k8s 和 operator 的相应支持，而且被迁移的长连接需要同步的迁移状态，对于 MOSN 内的有状态协议也带来比较大的研发压力。\n我们的选择是把复杂做到了运维侧，做一个相对折中的方式。相对于热升级，这个方案没有那么热，我们称为温升级。 上图展示了温升级的过程。概括起来是三步：关闭待运维 pod 的所有入流量，升级 MOSN 的容器，打开流量。\n温升级去掉了业务的冷启动时间，避免了业务重启失败。MOSN 只需要做好配置的向下兼容，升级过程和传统升级过程几乎完全一样，但成倍的提升了升级效率。\n最后，我们说 …","date":1616677200,"description":" 本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。","dir":"blog/mosn-meetup-4-deploy-automation-at-large-scale/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"aec6af134a0e93f3576b7d5f3fd9101d","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","publishdate":"2021-03-25T21:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","summary":"本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。主要分为 3 个部分： -介绍 MOSN 在规模化运维中遇到的挑战 -无人值守上的实践 -MOSN 与技术风险","tags":["Service mesh","Service Mesh 落地实践"],"title":"mosn的无人值守变更实践","type":"blog","url":"/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","wordcount":3465},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 请教一下：JRaft 的 StateMachine 的 onApply 方法是线程安全的吗？如果在 onApply 里面有一些耗时操作的话，整个应用吞吐会下降很明显吧。\n A：是，对于同一个 st，onApply 必须由 JRaft 的单线程去执行，因为 raft 算法本身需要保证 raft log 被顺序 apply，所以这里没有线程安全问题；把结果同步了就好了，计算别放里头。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@孙军超 提问：\n 请教个问题：我现在直接跑 jraft-example 的 rheakv 的测试代码 PutExample，第一次调用 Rocksdb put 函数总会先阻塞整整 5 秒钟，server 端也没有任何报错。 A：猜测是 DefaultChannelId 里的 getProcessId() 太慢了，或者是 NetUtil 里获取 loopback 地址太慢，有一个办法可以证实：在 main 方法最开始提前 Class.forName 去加载这俩个类，应该会先卡住 5 秒，等到 rheakv 的逻辑执行时就不会卡住了；试一下我上面说的方法，猜测就是这两个类其中之一导致的：https://stackoverflow.com/questions/33289695/inetaddress-getlocalhost-slow-to-run-30-seconds； 配 etc/hosts 生效后可以解决。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@明惑 提问：\n 请教一下：状态机中 onApply 和 onSnapshot 的方式是线程安全的吗，我在这两个方法中操作同一个数据，会不会出现并发问题呢？\n A：onSnapshot 会暂停其他线程；不会有影响，onApply 又是单线程执行的。\nSOFAStack：https://github.com/sofastack/sofastack.tech\n4、@胡志奇 提问：\n Snapshot 的 save/load 方法都将阻塞状态机，应该尽力优化，避免阻塞。Snapshot 的保存如果可以做到增强备份更好。 onSnapshotSave 需要在保存后调用传入的参数 closure.run(status) 告知保存成功或者失败，推荐的实现类似：\n @Override public void onSnapshotSave(SnapshotWriter writer, Closure done) { // 同步获取状态机的当前镜像状态 state // 异步保存 state // 保存成功或者失败都通过 done.run(status) 通知到 jraft } 官网上说的，异步保存也会阻塞？\n A：没有问题，安全的；你截取的内容其实已经说得很清楚了，异步是指存储操作，同步是指获取当前状态机的镜像必须是同步操作；就是说：你必须在状态机被后续的 raft log 更改之前，拿到镜像，也就是拿镜像和 apply 是串行操作，一旦拿到镜像，你可以用异步的方式把镜像保存的磁盘上，甚至再压缩一下。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n5、@闫文超 提问：\n 问下大佬，SOFABoot 启动服务端暴露两个接口，但是 nacos 注册中心只注册了一个 RPC 端口，客户端调用接口报错\n A：SOFARPC + NACOS 有实践案例：https://www.sofastack.tech/projects/sofa-rpc/registry-nacos/ 如果还是解决不了可以上传一个可以复现问题的 demo 工程到 GitHub。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n6、@游侠 提问：\n 请教一下：在 SOFAJRaft，Learner 这种复制器，怎么理解？表示这个节点，只读？\n A：learner 不参与选举，可理解为冷备。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n 可信原生负责人入选“2021年度全球青年领袖”名单\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n ","date":1616137200,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210319/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"196034de19b2d4c77fbe5c88e6721a8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210319/","publishdate":"2021-03-19T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210319/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210319/","wordcount":1712},{"author":"SOFA 团队","categories":"sofagw","content":" 简介：本周将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会重点说明如何解决在安全、互通、接入成本、高效等几方面问题，接着介绍了SOFAGW网关的内部实现架构，最后是SOFAGW网关达成的业务成果。\n 1. 业务痛点 随着业务发展越来越多元化，部分业务域相对比较独立，或因其业务属性，会建立成独立的站点（租户），比如：国际业务和蚂蚁保等。这些站点之间网络是隔离的，但实际业务上会存在一些通信的需求，所以我们碰到的核心问题是：网络互相隔离的多个站点之间怎么做高效可信的通信？对此我们有两种针对站点间互通的解决思路：\n思路1：为每个业务创建跨域 VIP 为每个业务创建跨域 VIP，站点的业务通过 VIP 来做通信。这种方式，运维管理员要在两个网络间开很多 VIP，加访问白名单，最终网络拓扑会变成如下；将面临网络口子多、运维成本高、业务接入成本高、安全阈值低等问题。\n这个方案有以下几个问题：\n 很多服务需要开 VIP 口子，服务多了之后，VIP 难以维护； VIP 的 ACL 控制很弱，只能基于 IP 端口或 IP 段控制，不能按业务应用或服务来做控制； 安全管控能力很弱，对请求不可审计； 业务适配改造工作量大，技术栈不统一，存在多种 RPC 框架。 思路2：实现一个高效可信的互通网关，来承接站点之间的通信代理 这就是我们采用的多站点互相通信的解决方案，下面详细介绍我们的互通方案和重点解决的问题。\n2. 解决方案：SOFAGW 互通网关 鉴于上面提到的问题，我们研发了 SOFAGW 互通网关，致力于实现一个简单高效、安全可信的跨域 RPC/消息 互通网关。\n如上面的整体架构图所示，我们的解决方案是各站点部署一套 SOFAGW 网关，把站点间的通信都收敛到 SOFAGW 上，由 SOFAGW 来保证安全通信，而在研发体验上，业务方同学按照本地服务做开发，不用为跨域通信做特殊处理，做到无缝接入。\nRPC互通过程： 在 SOFAGW 网关上，申请接入需要互通的 RPC 服务。接入后，消费方 SOFAGW 网关会把这个 RPC 服务发布到本站点注册中心上，服务方 SOFAGW 网关会从注册中心订阅这个 RPC 服务提供方地址。 消费方应用通过注册中心订阅到目标服务是本站点的 SOFAGW，把请求发送到本站点的 SOFAGW。 本站点的 SOFAGW 根据 API 配置信息，把请求转发到对端站点的 SOFAGW。 对端站点的 SOFAGW 根据注册中心订阅到的地址，把请求发送给真实的服务提供方。 完成跨展达 RPC 通信。 消息互通过程： 消息的互通和 RPC 互通非常类似，差别主要在于需要通过消息中心来收发消息。\n 在 SOFAGW 网关上，申请需要接入互通的消息服务。 客户端把消息投递到本站点的消息中心，消息中心把消息封装成 RPC 请求发送到本站点 SOFAGW。 本站点的 SOFAGW 根据API配置信息，把请求转发到对端站点的 SOFAGW。 对端站点的 SOFAGW 把请求发送到消息中心，消息中心再把消息投递到真实的消费方。 完成跨站点消息投递。 SOFAGW 互通网关重点解决以下几个痛点：\n2.1 安全通信 首先我们要解决网络不可达问题。从图里可以看到：每个站点都部署了 SOFAGW 网关，网关之间可以用专线或 VIP 之类的产品打通，这样站点间把流量就收敛到了 SOFAGW 网关，避免到处开网络通道口子，便于安全管理。\n网络安全 为了保证 SOFAGW 网关之间的通信安全可信，我们开启了 mTLS 双向认证，既能对数据做加密，也能确认对方的身份可信，从而确保通信安全。\n数据安全 一个站点（租户）会给其他多个站点提供服务，这些暴露的服务首先要确保租户级别的水平权限隔离，也就是说，A 站点暴露给 B 站点的服务，不能被 C 站点的应用调用到。如何做到这点？\n SOFAGW 网关会给不同站点提供不同的访问域名（这些域名都会解析到 SOFAGW 的 VIP 上）。 SOFAGW 之间通过 mTLS 双向认证通过后，可以确认请求的域名（ host ）可信，也就是 C 站点的应用无法用 B 站点的域名与 A 站点的 SOFAGW 网关建立 TLS 连接。 SOFAGW 会通过请求头里的 host + path 路由做路由转发，C 站点的请求无法匹配上提供给 B 站点的域名，也就无法访问到提供给 B 站点的服务。 除了要确保租户级别的水平权限控制，SOFAGW 还具备应用级别的 ACL 权限控制，如果一个 API 服务只暴露给某特定应用，那其他的应用是无法访问这个 API 服务的。\n另外，站点间的通信数据不是任意的，目前在业务 API 接入过程中，我们会有严格的数据安全审计流程。\n2.2 统一技术栈，跨域 RPC/消息 互通 不同的业务方会使用不同 RPC 框架，如 SOFARPC、HSF、Dubbo，底层用的通信协议和序列化协议也不一样，很难直接通信，如果做协议转化适配又会有很大的成本。在性能、扩展性和新特性支持等方面，老的各种协议难以满足发展需求，也很难在原有协议的基础上扩展以支持新的功能。为了更好的支持业务发展，对齐各 RPC 框架通用能力，需要设计一种新的通用的协议，从协议层解决以上问题。\n所以，阿里巴巴及蚂蚁集团共同制定了 Triple 协议，让内部使用的编程框架都支持 Triple 协议，这样大家互通时就会很顺畅。\nTriple 协议是什么？\nTriple 协议本身，是基于 gRPC-over-HTTP2 扩展的 RPC 协议，与现有的其他 RPC 协议比较， 有以下优势：\n 多种 RPC 模式 ( P2P/ Reactive Streams/ Bidirectional / Pub-Sub ) 基于 protobuf 提供统一的服务定义以及 API 治理 更好的性能 ( Protobuf / Protostuff / Back Pressure ) 原生跨语言支持 ( C++/ Dart/ Go/ Java/ Python/ Ruby/ C# / OC / JS / PHP )，原生兼容 gRPC 客户端 易于升级和修改协议 兼容现有的 RPC 框架，易于协议升级和互通 ( gRPC / SOFA-RPC / HSF / Dubbo \u0026amp;hellip;) 对网关型应用友好，原生支持 gRPC-over-HTTP2 支持移动设备原生调用 Triple 遵循 gRPC-over-HTTP2 协议规范，使用 CUSTOM-METADATA 扩展元数据。对于已经存在的 grpc- 开头的 Header 保持不变，保证与原生 gRPC 客户端/服务端互通，对于协议中不存在需要新扩展的 Header，将以tri- 开头。另外，去年发布的 Dubbo 3.0 也是以gRPC为基础，Triple 能和 Dubbo 3.0 保持良好兼容。\n举例，当前我们约定的 Triple 协议头：\n2.3 无缝接入 为了让业务方无缝接入，SOFAGW 网关和注册中心专门做了联动，具体原理从上面的整体架构图可以看到：\n 在调用 …","date":1615878000,"description":"将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会重点说明如何解决在安全、互通、接入成本、高效等几方面问题，接着介绍了SOFAGW网关的内部实现架构，最后是SOFAGW网关达成的业务成果。","dir":"blog/sofagw-cross-domain-communication-solution/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"158827766506b1c5f49729b31a6f66e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","publishdate":"2021-03-16T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","summary":"简介：本周将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会","tags":["Service mesh","Service Mesh 落地实践"],"title":"SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案","type":"blog","url":"/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","wordcount":4308},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@孙军超 提问：\n 请教一下 jraft-rheakv rocksdb 的 get put 操作，耗时要 5 秒钟，是服务端配置需要优化吗？ 以下是我的服务端配置截图。 A：kill -s sigusr2 可以看到性能指标度量，官方文档请看一下有相关说明。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@戚金奎 提问：\n 请教一个问题：如图，目前服务都是通过 openfeign 远程调用，如果 setScore 所在的服务抛出了异常，是能直接出发事务回滚吗（我本地的无法出发回滚），还是需要在这个 seata1 里面接受一下返回值然后抛出异常才可以回滚吗（目前我这边是这种可以回滚）？\n A：决议全局提交/回滚的只能是\n@GlobalTransactional 注解的发起者，它 catch 到异常才会触发回滚；远端的异常应该是没抛给调用者，或者被框架拦截了异常。\nSeata：https://github.com/seata/seata\n@谭玖朋 提问：\n 这两个地方调用 rollback 有特殊意义吗？我发现在此之前没有更新操作啊。 A：这个地方应该是一个编码的习惯，在 autocommit=false 的时候，返回前都做一次 commit 或者 rollback 操作，确保当前的事务能够提交或者回滚，同时释放数据库的锁（哪怕前面并没有事务和锁）。\nSeata：https://github.com/seata/seata\n@戚金奎 提问：\n 请教一个问题：如果出现如图的这种情况， 执行的这个全局事务在获取全局锁之后，会获取 m 字段最新的值，再和自己的 before_image 里面记录的值去比较，发现不一致，全局事务失败并回滚。 A：所有写场景要被 globaltransational 覆盖，不允许直接去数据库改数据。否则就会出现在全局事务被决议回滚的时候，别的地方把这个数据改了。\nSeata：https://github.com/seata/seata\n@姜世存 提问：\n 请教一个问题，这个 LoadLevel 注解有什么作用\n A：所以别的业务要继承 Seata，写入口加入 globaltransational 注解，只读无需加注解。\nSeata：https://github.com/seata/seata\n@winyQ 提问：\n 项目里 Seata 用 AT 模式，可以在项目里再集成 JTA 吗，两个并存有没有什么问题？\n A：JTA 是 XA ，无法跟 AT 兼容。\nSeata：https://github.com/seata/seata\n本周推荐阅读 可信原生负责人入选“2021年度全球青年领袖”名单\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 本周发布 本周发布详情如下：\n1、sofa-common-tools 发布 v1.3.3 版本，主要变更如下：\n 修复 log space factory 的懒初始化模型问题  详细参考：\nhttps://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.3\n","date":1615532400,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210312/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f2a08527a8868ee63936378b903d5b07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210312/","publishdate":"2021-03-12T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210312/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | sofa-common-tools 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210312/","wordcount":1269},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望\n 活动时间：2021 年 03 月 21 日（周日）14:00-17:00\n 活动地点：浙江杭州西湖区学院路77号黄龙万科中心-I座\n 活动形式：线下活动\n 资料地址：点击链接\n 活动介绍 SOFAMeetup 牛年首站：3月21日 杭州见！\n久别重逢，朋友们，SOFAMeetup 回来了。 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁集团超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n本期 SOFA Meetup 将带来 Service Mesh专题： Service Mesh 在蚂蚁、美团的落地后，如何开展能力及基础设施的建设？如何更好的支撑业务发展？在Service Mesh 大规模落地后，MOSN 如何解决变更风险和效率问题？ 如何支撑 Service Mesh 的演进与优化？本次分享将会提供我们一些思考和实践！\n活动议程 本期议题以及嘉宾详解 《Service Mesh 在蚂蚁落地后的探索与实践》\n嘉宾介绍\n李唯，蚂蚁集团技术专家，2017 年加入蚂蚁集团中间件团队。参与了 Service Mesh 在蚂蚁的落地建设，目前主要负责 MOSN 在蚂蚁内部的设计开发。\n议题简介\n Service Mesh 在蚂蚁落地之后的能力建设，结合 MOSN 在蚂蚁的实践和探索，分析 Service Mesh 在大规模场景下持续向前演进的挑战及其背后的思考。 听众收获\n 了解 Service Mesh 在蚂蚁实践过程中遇到的困难和思考 收获 Service Mesh 在赋能业务方面的案例经验与启发\n 收获 Service Mesh 在研发效能方面的最佳实践\n 《MOSN 的无人值守变更实践》\n嘉宾介绍\n黄家琦，蚂蚁金服技术专家，SRE，专注于基础设施与中间件稳定性建设。深度参与了 Service Mesh 在蚂蚁内部大规模生产落地过程中的技术风险能力建设。SOFABolt-Python 组件维护者。\n议题简介\n 自 Service Mesh 在蚂蚁大规模落地之后，MOSN 的变更风险和效率问题愈发突出，本次将介绍从 SRE 视角下对于 MOSN 变更问题的思考，以及对于无人值守变更的实践。 听众收获\n 了解大规模 Service Mesh 下的变更问题与思考\n 收获 Service Mesh 在无人值守变更方面的经验与启发\n 《Service Mesh 在美团的落地挑战与实践》\n嘉宾介绍\n薛晨，美团基础架构团队技术专家，一直专注于分布式系统架构、服务治理领域和基础软件产品化。毕业以来先后深度参与了分布式调度系统、分布式配置服务、PaaS 平台构建和 Service Mesh 方向的探索和实践，在相关领域有较多的思考和沉淀。\n议题简介\n 云原生时代的到来，美团的服务治理系统 OCTO 也向 Service Mesh 的方向演进。作为集团的标准化基础设施，覆盖所有业务线和日均万亿调用，在演进的过程中我们面临着诸多挑战。 如何支撑和更好的支撑业务的发展？如何尽可能的保证演进过程的可靠和丝滑？如何更好的兼顾效率与稳定性？ 听众收获\n 了解超大规模服务治理系统 Mesh 化的最新进展\n 了解 Service Mesh 规模化落地的挑战和应对方案\n 对服务治理和 Service Mesh 未来的一些思考\n 《过往可鉴，未来可期 — MOSN 社区周年回顾与展望》\n嘉宾介绍\n田阳，蚂蚁金服高级技术专家，专注于高性能网络服务器研发，MOSN 开源项目维护者，Tengine 项目成员。\n议题简介\n MOSN 开启开源社区，独立运营已一年有余。在这期间，社区持续投入开源生态建设和云原生演进，并成为了 Istio 官方推荐的数据平面。本次我们将对过去一年的成绩进行回顾与总结，对未来社区的发展进行探讨与展望。 听众收获\n 了解 MOSN 的核心能力和支撑的业务场景\n 了解 MOSN 怎样支撑蚂蚁 Mesh 的演进和大规模落地所做的优化\n 了解 MOSN 后续规划，与 Envoy 社区的合作进展等\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1615273200,"description":"SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望","dir":"activities/sofa-meetup-4/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2619f4f8ba15ac0f4fe43a82ef297db1","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-4/","publishdate":"2021-03-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-4/","summary":"概要 活动主题：SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望 活动时间：2021 年 03 月 21 日（周日）14:00-17:00 活动地","tags":["SOFAMeetup"],"title":"SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-4/","wordcount":1552},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@刘嘉伟 提问：\n 请教一下：我在纯 TCC 事务 a、b、c个服务调用中 c 服务异常了，b 服务回滚日志是 rm handle undo log process: UndoLogDeleteRequest{resourceId=\u0026amp;lsquo;insert\u0026amp;rsquo;, saveDays=7, branchType=AT} 明明是纯 TCC 事务，怎么 AT 都出来了，导致了一个问题：TCC 数据源也没有代理的，也没有相应的 undo log表，然后 AT 事务回滚肯定无效的，TCC 的 cancel 也没有执行。\n A：这个理论上来说是没影响的，定时触发的，跟你本身的回滚逻辑应该没关系；这个 pr 会优化这个点：https://github.com/seata/seata/pull/3501。\nSeata：https://github.com/seata/seata\n@刘嘉伟 提问：\n 请问 AT 模式中如何防止事务回滚时，系统中一闪而过的脏数据，有时页面刚好打开，被用户感知到这些脏数据了；人工处理很麻烦，触发异常因为回滚操作有耗时，脏数据通常怎么处理；TCC 就没有这个问题，隔离的资源用户感知不到。\n A：数据在数据库，在数据库写被隔离的；前端本身就会有脏读出现，要靠后端保证。\nSeata：https://github.com/seata/seata\n@赵勇 提问：\n 比如这个图：A、B、C 各自都有自己的代码、自己的数据库，分开部署的；A 调用 B、C 提供的服务，那 undo_log 要在 db-a、db-b、db-c 里都建一份，然后 A、B、C 的代码里都要引入全局事务相关的类、包， 再加上把 GlobalTransaction 标到 A 的代码上，是这样实现吗；我看 GTS 的文档，感觉 undo_log 是 A 的代码引入的类包去写的，不是 B、C 自己写的，B、C 的代码还是该怎么写怎么写，不需要接全局事务相关的东西。 A：Undo_log 是每一个微服务的业务数据库都要建立，各自维护自己的 Undo_log；如果刚入门了解的话，先看看官网和跑一跑 demo。\nSeata：https://github.com/seata/seata\n@吴宗杰 提问：\n 2020 年 4 月份 Seata 从 1.2.0 支持 XA 协议，Mycat 支持 XA 分布式事务，是不是说明 Seata 和 Mycat 可以一起用？不过看到 19 年 slievrly 有和 Mycat 方沟通，后面应该也会支持的吧。\n A：可以试试，因为 Seata 所谓的 XA 模式是对支持了 XA 协议的数据库的 API 进行自动化的，XA 事务开启和统一提交回滚，Mycat 是属于一种 proxy，伪装的数据库层来代理背后的数据库，不知道这种结合会不会有什么问题存在，特别是 XA 这种出现中间层和 Seata 的兼容问题导致 XA 死锁就麻烦大了。\nSeata：https://github.com/seata/seata\n@谭玖鹏 提问：\n 请教一个问题，这个 LoadLevel 注解有什么作用\n A：看一下 EnhancedServiceLoader#getUnloadedExtensionDefinition 这个函数，跟一下 spi 那块加载的代码就知道了，跟 dubbo 那边差不多，dubbo 有个博客解析：https://dubbo.apache.org/zh/docs/v2.7/dev/source/dubbo-spi/。\nSeata：https://github.com/seata/seata\n@winyQ 提问：\n 不用 Seata 事务的数据操作方法里用的 datasource 还是代理数据源对象，这个没办法改吗，一旦设置 datasourceproxy，好像就一直只能用这个了。\n A：虽然拿到的都是 datasourceproxy，但是没有 globaltransational 和线程中没有 xid 的时候都是不会干预的；内部还是原来的 datasource 做操作，如果你确定没有 2 个服务以上参与的函数，可以用 globallock+ 对要修改的数据进行 for update 先再做写操作，会比直接加 globaltransational 注解效率高，但是相对而言入侵也高了。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 蚂蚁 Service Mesh 大规模落地实践与展望\n ","date":1614927600,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210305/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c5c658590a95eee0eb2c13cfb67d7d49","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210305/","publishdate":"2021-03-05T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210305/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210305/","wordcount":1701},{"author":"雪连","categories":"MOSN","content":" Serverless Task 是蚂蚁集团在分布式调度和批处理中间件发展而来的解决方案。通过 ServiceMesh 的精细化引流能力，再利用研发框架的“服务分组”配置能力，将 Serverless Task 流量全部收敛在指定的“服务分组”集群内。结合定时任务本身具备的周期、可预测等特点，根据任务执行情况弹性伸缩“服务分组”内的机器资源从而提升资源利用率和系统稳定性。\n 分布式调度在蚂蚁的场景和遇到的问题 在单体架构中，为了解决一台机器在固定的周期间隔执行相同的任务，避免人工干预过多，有了基于 Cron 的单机调度；随着企业级应用的发展和微服务化以及云原生架构的逐渐演进，原先的单体架构逐渐演变为服务化或者云原生架构。在此背景下，既要解决原先单机要解决的定时调度问题，还需要解决任务管理、负载均衡以及高可用、容灾等问题，同时兼顾用户体验的简单高效，分布式调度产品就应运而生。\n在蚂蚁域内，分布式调度广泛应用于各个 BU 的业务场景中，举例：如在支付宝上购买基金的用户每天需要计算基金收益，那么就需要在分布式调度的基础上结合批处理的能力，充分利用应用集群的处理能力，完成每一个用户基金净值的收益计算，典型处理场景如下：\n为了充分利用集群的能力，业务会采用按照业务各个维度拆分的方式对数据进行分片，然后根据分片原则加载数据，最后尽可能的将数据分散在集群机器上完成每一个用户基金净值的计算。通过类似上述集群执行的方式，结合分布式调度及批处理的能力，可以完成业务的计算诉求，但是由于这部分计算逻辑被原有的应用集群承载，随着业务的发展和数据量的不断增加，就会有如下的问题：\n稳定性问题：在线流量如 RPC/MSG 等与任务调度流量（简称异步任务流量）在 CPU/MEM/线程池 资源共享而引发的相互抢占导致的稳定性问题。\n资源利用率问题：异步任务流量最常用 Cron 表达式来描述，对于一天 24 小时只需要运行 7 个小时的任务来说，剩余的 17 个小时的资源就是浪费掉的。\n效率问题：业务同学在接入任务调度以及对批处理执行的控制，数据量统计、异常归类和动态调整参数等复杂性导致的研发效率较低；发布上线后，对处理速度、资源容量评估以及稳定性投入导致的运维效率较低。\nServerless Task 解决方案 为了解决上文分布式调度在蚂蚁的多年实践中遇到的问题，我们提供了 Serverless Task 的解决方案。\n通过故障隔离的方式来提高稳定性。Serverless Task 在不影响大家研发习惯的前提下，业务同学只需要通过在 PaaS 平台中，在同一个集群下申请“服务分组”集群，这些机器用于达到只承担异步任务的流量，而屏蔽其他在线流量的访问的目的。机器资源承载的流量做区分后，再配合 ServiceMesh 的精细化引流能力能够将流量收敛在指定的“服务分组”内，同时结合框架的“服务分组”配置能力，能够指定 Bean、消息、任务或者服务是否注册或者启动。通过上述的方式，最终能够实现，指定的异步任务收敛在指定的“服务分组”机器资源内，以此实现在线流量和异步任务流量的故障隔离，避免相互影响，而提升系统的整体稳定性。\n通过弹性伸缩的方式来提高资源利用率。基于可控弹性伸缩 HPA 技术，通过分析任务的 Cron 表达式或者基于 CPU/Mem/线程池等各项正常或者异常指标，能够将隔离在指定“服务分组”内运行异步任务的机器动态调整其 Pod 数量，在满足业务处理诉求的前提下，通过弹性伸缩技术最大化的提升资源利用率。\n提供更加产品化的能力。Serverless Task 支持处理器编排、支持迭代隔离、自定义参数和自定义限流等能力以提升业务的研发效率；同时，异步任务在故障隔离的基础上，利用弹性伸缩技术动态调整业务的 Pod 资源数量，可以让业务研发同学尽可能少的关注资源而只需关注任务的运行情况，以此极大的提升运维效率。\nServerless Task 关键能力介绍 弹性伸缩技术 上文介绍了 Serverless Task 的解决方案思路，为了真正实现 Serverless ，让业务同学不关注容量只关注业务逻辑，一个很重要的技术能力就是弹性伸缩。\n弹性伸缩技术，通过分析任务的 Cron 表达式或者基于 CPU/Mem 等各项指标计算出来的画像（每个时刻期望的 Pod 副本数量），来确定每个时刻的应该 Ready 的 Pod 数量，当在流量低峰或者任务没有在运行的时间就可以将机器缩容到相对较小的副本数。同时为了能够在最短的时间内恢复业务 Pod 的运行，启动速度是一个至关重要的指标，采用基于 ServiceMesh、JVM Elastic Heap 和内存 swap 的容器保活技术实现极速启动，来保证业务容器再恢复到期望的副本数时，有足够快的速度。\n 任务链路隔离与伸缩能力 通过上面描述的 Serverless Task 的解决方案，能够将异步任务的流量收敛在一个业务集群指定的“服务分组”集群内，并能够在弹性伸缩的基础上充分利用机器资源。但是，这样就会导致新的问题，当上游系统被隔离后，其处理速度和稳定性都会一定程度的增加，但是对下游的调用量就会激增，导致下游出现热点或者稳定性问题。基于此，我们提供了任务链路的解决方案，期望将 Serverless Task 触发异步任务的门面系统以及对下游系统的调用，都能够通过“服务分组”的方式隔离开，期望组合成一条异步任务流量作为入口流量的任务链路，具体的实现方案如下所示。\n每一个 Serverless Task 在周期触发时都会自动携带染色标识（每一个异步任务的唯一标识），通过在任务调度平台选择当前异步任务要引流到的“服务分组”，就可以完成门面系统的 Serverless Task 到指定“服务分组”的引流。每一次 Serverless Task 调用门面系统均携带染色标识，门面系统紧接着对下游系统再发起调用，门面系统结合控制面的业务引流能力，就可以在控制面对门面系统下发引流规则，并配置流量比例，便可以将门面系统对下游系统的调用也收敛在指定的“服务分组”集群内。以此类推，下游系统如果继续有对后续系统的调用，也可以采用类似的方式推送引流规则来完成指定调用流量的“服务分组”集群收敛，以此来完成一条 Serverless Task 作为入口流量的任务链路的流量隔离，并具有单独的业务语义，比如：批扣链路、计价链路。\n在完成了任务链路的隔离之后，由于入口的流量是由异步任务驱动或者触发的，流量是能够通过 Cron 或者运行状态做比较准确的预测，那么在任务链路执行完毕后，就可以将整个链路的资源全部伸缩掉，同样当异步任务的流量高峰到来之前时再扩容出足够的机器资源，以此在隔离出任务链路的同时，还能提升整体任务链路的稳定性以及整个任务链路的资源利用率。\n总结与展望 通过 ServiceMesh 的精细化引流能力，可以将 Serverless Task 流量收敛在指定的“服务分组”集群内，再利用框架（如 SOFA Boot）的“服务分组”配置能力，控制非期望的 Bean 和服务在“服务分组”集群内关闭，最终就能够做到将 Serverless Task 流量完整的收敛在指定的服务器集群内，达到流量收敛的目的后，再结 …","date":1614668400,"description":"如何实现任务调度和存量应用的 Serverless 化，本文为大家介绍 Serverless Task 是如何实现这一解决方案。","dir":"blog/antgroup-serverless-task/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cb83515191621dc518d49a84ac297f0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-serverless-task/","publishdate":"2021-03-02T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/antgroup-serverless-task/","summary":"Serverless Task 是蚂蚁集团在分布式调度和批处理中间件发展而来的解决方案。通过 ServiceMesh 的精细化引流能力，再利用研发框架的“服务分组”配置能力，将 Serverless Task 流量全部收敛","tags":["Serverless","任务调度","弹性伸缩","ServerlessTask","Service Mesh"],"title":"Serverless 给任务调度带来的变化及蚂蚁集团落地实践","type":"blog","url":"/sofastack.tech/blog/antgroup-serverless-task/","wordcount":2748},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@宓文明 提问：\n 请教：大家有没有遇到过 SOFAArk 工程这样的情况：双机房集群部署（检查模块 jar 大小相同、MD5 相同、部署时间相同），其中一台服务器中报错 NoClassDefFoundError（调用模块工具类的静态方法时，工具类找不到），其余的服务器都 OK。 A：你们登录到机器上去，堆栈是有的；这种问题可能是因为底层有 class 没找到，两个思路： - 版本冲突 ，不一定局限在你的 JsonUtil 这个类，里面的类也有可能引发 。 - 通过 arthas ，分析下不同 bizClassLoader 加载 JsonUtil 的情况。\nSOFAArk:https://github.com/sofastack/sofa-ark\n@郭强 提问：\n MOSN 是如何保证一定是先于业务容器启动，并且保证是后于业务容器销毁呢？\n A：启动就是按 pod 里的容器顺序启动，MOSN 容器在 APP 容器前。APP 容器内的应用进程启动前会检查 MOSN 的端口是否存活，得等到 MOSN 进程启动完成才能继续。销毁 pod 的时候没有特别处理，就是摘了pod 的流量整个销毁。\nMOSN:https://github.com/mosn/mosn\n@郭强 提问：\n APP 容器内的应用进程启动前会检查 MOSN 的端口是否存活。 这个是怎么做到的呢，是自动修改应用容器的 command 配置？还是说需要应用进程的 dockerfile 保证一定规范吗？\n A：蚂蚁内部的 Kubernetes 有针对性的做一些定制改造支持，标准 k8s 目前是控制不了容器启动顺序的； 最好的方式还是 k8s 原生支持 sidecar lifecycle，没有这个的话，相对折中的方式就是在应用启动脚本前 check 下了。\nMOSN:https://github.com/mosn/mosn\n@饶文强 提问：\n 请教一下：我不是很理解这一步锁撤销的步骤：线程 A 进入同步代码块方法，尝试获取偏向锁，此时若 CAS 线程 id 替换失败，为什么涉及一个偏向锁撤销，线程 A 不是没有获取到锁。我的理解是此时锁对象的偏向锁线程 id 不是线程A本身，为什么还需要偏向锁撤销？ A：因为偏向锁可以被降级，其他的不可以，这个时候需要升级锁或降级锁；偏向锁持有者是不会做降级操作的，只有前来竞争锁的线程会去判断。\nSeata:https://github.com/seata/seata\n@莹 提问：\n 有个场景：tcc 模式，try 方法创建订单记录，插入到数据库，然后异常回滚，在 rollback 方法中把这个订单记录根据主键删除，请问数据库主键字段怎么传过去？\n A：可以通过一阶段把 xid 对应业务信息存在 redis 中，二阶段通过 xid 拿出来使用。\nSeata:https://github.com/seata/seata\n@敲跃 提问：\n 问个问题：Seata 的 at 和 saga 模式 一阶段本地事务已提交，为了防止这部分数据被其他事务读到，文档给的解决方案 \u0026amp;gt; 脏读 select 语句加 for update，代理方法增加 @GlobalLock+@Transactional 或 @GlobalTransaction ； \u0026amp;gt; 实际操作的时候：涉及到本地事务的表的所有 sql 和方法都要这么改造，会不会成本太大，有没有其他好点的解决方案？\n A：涉及到所有的写入口加上 @GlobalTransaction 即可；只读场景 @GlobalLock +for update 即可；读了就写场景一定要 @GlobalTransaction，只读了给前端展示之类的。\nSeata:https://github.com/seata/seata\n本周推荐阅读 Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 蚂蚁 Service Mesh 大规模落地实践与展望\n 基于 MOSN 和 Istio Service Mesh 的服务治理实践\n ","date":1614322800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly20210226/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fff3af65c30bb18078a3222b86261205","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly20210226/","publishdate":"2021-02-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly20210226/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly20210226/","wordcount":1351},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@王盛 提问：\n 这个配置在 sidecar 里面怎么改，这个怎么配到 Istio 里面?\n A：在 Istio 中关于 tracing 这块的 driver 目前是通过配置 xxx_bootstrap.json 静态配置的，然后通过 istioctl 命令参数来选择使用哪个 driver。当前由于 skywalking 自身配置还没作为 bootstrap 的静态默认配置，所以需要你自己修改下 xxx_bootstrap.json，这个配置就好了（即把上面的那个配置加进去）。简单说就是修改下 sidecar 的静态默认配置文件，增加 skywalking 为 tracing 的 driver 配置。\nMOSN：https://github.com/mosn/mosn\n@卞平超 提问：\n TCC 多阶段；rollback 可以设置顺序吗？比如被调用的服务，先回滚，再回滚主服务的，A-\u0026amp;gt;B，想先回滚 B 的数据，commit 和 rollback；方法中的业务代码有异常，是会不断的重复执行。\n A：TC 的表字段 datetime 看下精度，二阶段都决议了，没有从 commit 异常，直接到 rollback。如果 10 个参与方，就 1 个 commit 异常，不去重试保证最终一致的话，数据不就乱了；已经决议了，就要保证起码能最终一致，而不应该串改结果，参考消息队列设计，为什么消费异常要重试。\nSeata：https://github.com/seata/seata\n@方舟 提问：\n 请问一下，在 TCC 模式中，如果 TM 和 TC 断开连接，能够保证全局事务的回滚吗，重连超时后，全局事务会回滚吗？\n A：会重连，然后重试；需要你自己保证幂等和悬挂，会等你连上之后再重试。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁集团轻量级类隔离框架概述 | SOFAArk 源码解析\n 蚂蚁集团研发框架总览 | SOFABoot 框架剖析\n SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理\n 蚂蚁集团 API Gateway Mesh 思考与实践\n 本周发布 本周发布详情如下：\n1、SOFARPC发布 v5.7.7版本，主要变更如下：\n 使用 Github Action 替代 Travis 进行持续集成 升级 jackson-datebind 到 2.9.10.7 升级 junit 到 4.13.1 修复了Rest中，当请求经过代理源IP获取不准确的问题 修复了内置 Protobuf Compiler 的 BUG 详细参考：https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.7\n","date":1613718000,"description":"SOFA WEEKLY | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210219/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"29b9f9ae46cecd6979ce334f8e11baf0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210219/","publishdate":"2021-02-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210219/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210219/","wordcount":1096},{"author":"李唯","categories":"云原生","content":" Service Mesh 双十一后的探索和思考(上) 引言 2019 年 Service Mesh 在蚂蚁大规模落地并完美支撑双十一核心链路，对于落地过程在去年已经有系列文章解读。而在此之后的一年多时间，Service Mesh 在蚂蚁又在如何演进呢。本文介绍蚂蚁 Service Mesh 在双十一落地之后所做的探索和思考。\n能力建设 得益于 Service Mesh 将业务和基础设施解耦，在过去一年中我们的基础设施能力得到了飞快的发展。大量能力大规模落地蚂蚁。例如链路加密，可信身份认证，服务鉴权，自适应限流，集群限流，精细化引流，服务自愈等。这里先对四个能力进行解读，其它能力后续再有文章讲述。\n链路加密 为了达到一个更高的安全水位，我们预期在蚂蚁内部所有的通信 100% 加密覆盖，这就是链路加密。\n设计 链路加密落地最大的挑战就是加密对业务不能造成影响，包括几个问题：\n 必须简化大规模场景下的运维复杂度问题，需要具备可灰度、可回滚的能力； 灰度运行期间，明文和加密切换不能对业务请求造成影响，需要进行热切换； 开启加密以后，对性能的影响必须控制在可接受的范围内； 基于这些需求，完成了链路加密的架构设计，主要思路包括：\n 通过统一的管控面控制服务端应用的配置，基于动态服务发布与订阅机制，在服务端支持加密能力以后，客户端自动进行加密的切换，运维人员只需要控制服务端配置节奏完成灰度；在灰度运行期间，服务端同一个端口需要同时支持明文和加密的能力； 相比于明文通信，基于 TLS 加密的通信主要消耗在连接建立的握手期间，服务端和客户端采用长连接的方式，减少连接的建立，以减少开启加密对性能的影响； 客户端在感知到服务端明文和加密状态变化以后，需要在不同的长连接之间进行稳定的切换，后文会详细介绍； 完整的一个加密开启流程如图所示，首先运维人员在管控面选择需要开启加密的应用，通过 XDS 完成配置下发。MOSN 在收到配置以后，会基于 SDS 机制获取到证书和私钥在内存中，证书和私钥由统一的 Secret 进行管理，应用侧不持久化保存。收到证书和私钥以后，会向注册中心发布本机已经支持了加密，注册中心会向所有订阅的客户端进行推送，客户端收到推送以后，与服务端的通信切换到加密状态。\n加密状态热切换：连接淘汰机制 我们的加密通信是基于 TLS 进行的实现，一个连接在建立好并且开始传输数据以后，连接上的数据是 TLS 加密的还是明文的就已经固定了，不存在将一个明文通信的连接变成 TLS 加密连接的情况。基于 TLS 这个机制，通信从明文切换到加密时，一定是需要新建一个连接，并且成功完成 TLS 握手。\n为了做到在连接切换期间业务请求不受影响，MOSN 实现了一个连接淘汰机制，用于连接加密状态的热切换。 每一个请求在 MOSN 中经过了路由和负载均衡以后，会选择到一个后端地址，基于这个地址从连接池中选择对应的长连接转发请求，在引入了加密切换以后，每次选择到连接以后，都需要判断当前预期的加密状态和连接的加密状态是否匹配，如果不匹配，则会创建新的连接进行加密状态的切换，并且使用新连接将连接池中的旧连接代替，这样就可以确保后续的请求都使用状态匹配的连接。对于被替换的旧连接，我们需要进行淘汰，但是这个淘汰不是简单的断开连接，因为旧连接上可能还有正在处理的请求，如果直接将连接断开就会导致请求有损，这是不能接受的。\n那么是如何淘汰旧连接的呢？这里就要讲到 MOSN 的长连接保持机制了。为了避免因为异常断网等导致连接“假死”的情况，在连接空闲时，会主动发起心跳请求，确保连接处于活跃状态，而如果服务端一段时间内都没有收到心跳，则会主动将连接断开。连接淘汰就是利用这个机制，对于准备淘汰的连接，我们将停止该连接的心跳发送，当连接上的请求处理结束后，这个连接上就不再会有任何数据的传输，经过一段时间后，服务端就会主动将这个连接断开，此时连接断开是安全的，不会影响任何请求。 优化 对应用无感知开启加密，除了指开启过程中不需要重启、请求无损等，还包括在开启以后的资源消耗、RT 影响也需要是无感知的。在实际落地应用过程中，由于我们都是使用长连接，TLS 握手带来的建连消耗只占用了很少一部分，在长连接通信过程中的对称加密消耗经过实际测试几乎可以忽略不计，看上去链路加密对性能的指标没有什么问题。\n但是在实际大规模落地以后，我们发现部分应用开启了加密以后，内存占用有显著的上涨，经过排查，定位到属于Golang TLS 标准库实现问题（ MOSN 是使用 Golang 编写的），我们自行优化以后，也向 Golang 官方提了 PR回馈社区，目前该 PR 已经被 Golang 官方所接受，预计在 go1.16 中发布，具体实现可以见 crypto/tls: pool Conn\u0026amp;rsquo;s outBuf to reduce memory cost of idle connections\n自适应限流 流量管理本身就是 Mesh 架构最为核心的功能之一，我们在 MOSN 中实现了多种策略的限流能力，包括单机 QPS限流、集群限流、热点限流、接口熔断、自适应限流等，其中自适应限流是一大亮点。\n限流是每个技术同学都不陌生的名词，同时也是很多不同角色的同学头疼的事情。对于业务同学而言逐个接口做容量评估和压测回归费时费心，有限的精力只能投入到重点的接口保障上，难免会漏配一些小流量接口的限流；而负责质量和稳定性保障的同学经常在故障复盘时看到各种漏配限流、错配限流、压测故障、线程阻塞等造成的各种故障\u0026amp;hellip;\u0026amp;hellip;\n我们希望即使在系统漏配错配限流的情况下，在系统资源严重不足时 MOSN 能够精准的找到导致系统资源不足的罪魁祸首，并实时根据系统水位自动调节异常流量。这就是自适应限流想要实现的效果。\n技术原理 能用一句话说清楚你们的技术原理吗？ 类 PID 控制流量闭环自适应调节 朴素的解释就是，触发限流后一边观察系统整体水位，一边秒级按比例调节流量的策略，用一张图来解释具体的原理： 1.系统资源检测：秒级检测系统资源占用情况，如果连续超过阈值N秒则触发基线计算，同时开始拒绝压测流量进入； 2.基线计算：将当前所有的接口统计数据遍历一遍，通过一系列算法找出资源消耗大户，再把这些大户里明显上涨的流量找出来，把他们当前的资源占用做个快照存入基线数据中； 3.基线调节器：将上一步骤存入的基线数据根据实际情况进行调整，根据系统资源检测的结果秒级的调整基线值，若系统水位超过阈值则按比例下调基线值，否则按比例恢复基线值，如此反复； 4.限流决策：根据上述步骤生产的基线数据决策是否限流；\n自适应限流已在全站线上应用中大规模启用，成功防范了多起业务故障。为新春红包压测和线上业务保驾护航。\n技术优势 相较于传统的限流组件，MOSN 中的自适应限流具备很多优势，MOSN 架构天然的流量劫持让应用无需逐个接入SDK，也无需为特定语言开发不同版本的限流组件，同时给业务同学降低了配置的难度，也为业务实现了兜底保护。在研发效能和研发成本上都取得了明显的收益。\n MOSN 自适应限流 传统 QPS …","date":1613548800,"description":"本文介绍蚂蚁 Service Mesh 在双十一落地之后所做的探索和思考。","dir":"blog/service-mesh-exploration-thinking-after-1111-1/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3a08e94a57454e3ef36f8eee6da6795e","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","publishdate":"2021-02-17T16:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","summary":"Service Mesh 双十一后的探索和思考(上) 引言 2019 年 Service Mesh 在蚂蚁大规模落地并完美支撑双十一核心链路，对于落地过程在去年已经有系列文章解读。而在此之后的一年多","tags":["云原生"],"title":"Service Mesh 双十一后的探索和思考(上)","type":"blog","url":"/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","wordcount":5691},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" 本文作者：蚂蚁集团黄挺（花名鲁直），SOFAStack 社区主理人，同时负责蚂蚁集团云原生方向的推动和落地，包括 Service Mesh、Serverless、消息、微服务等领域，带领 SOFA 团队扎根技术完成很多落地实践。\n 大家好，我是鲁直，有段时间没有和大家见面，今天是农历一年的起点，首先祝大家新年快乐，在新的一年牛气冲天！在这样特别的日子里，我想和大家分享对于 Service Mesh 未来方向的思考，再谈谈 SOFAStack 社区接下来计划做的一些事情，希望大家接下来能够在社区里面玩得开心，let\u0026amp;rsquo;s have fun together! Service Mesh 是否已经解决了所有问题？ 2020 年， SOFA 团队宋顺（花名齐天，当前蚂蚁集团 Service Mesh 负责人）在 QCon 上海站分享了《蚂蚁 Service Mesh 大规模落地实践与展望》，详细讲述了 Service Mesh 在蚂蚁集团的进展和未来规划。 在过去的几年里面，Service Mesh 在整个云原生社区如火如荼地发展，从刚开始的 Linkerd，到后面的 Istio，不断地有大公司加入到 Service Mesh 的领域的开拓之中，随着小剑、净超等同学在国内布道 Service Mesh，Service Mesh 从 2017 开始在国内火热程度也不断升温，SOFA 团队也在这个时候开始关注到 Service Mesh 这个领域，并且开始在内部尝试做落地的事情，也和业界的很多朋友一起举办了一场又一场的 Service Mesh Meetup。\n应该说我们是幸运的，成功在 2019 年实现了 Service Mesh 在蚂蚁大促业务链路上的全面落地，获得了大规模落地 Service Mesh 的经验，并且在这之后持续应对 Service Mesh 大规模落地之后的遇到的各种挑战，截止到 2020 年底，蚂蚁集团已经基本上实现了在线业务的全面 Service Mesh 化，在一部分网关场景上，也采用了 Service Mesh 的架构，实现了南北向和东西向流量架构的统一。\n但是随着 Mesh 化的进程不断地往前推进，一直在我们心中萦绕这一个问题，Service Mesh 在一定程度上解决了基础设施和业务耦合的问题，但是是否已经把所有的问题都解决完毕了？这个问题的答案显然是没有全部解决完毕，这个尚待解决的问题还是基础设施和业务耦合的问题。\n目前包括蚂蚁集团在内的各种各样的 Service Mesh 的解决方案，都是会选择采用尽量透明的方式去适配应用已有的协议，让业务尽量减少接入 Service Mesh 的成本，即使不是全透明的方式，而是采用瘦 SDK 的方式接入（蚂蚁集团目前采用了这种方式），也是为了这个目的。在这种形态下，应用固然可以透明地获得非常多的能力，包括限流，服务发现，安全通信等等，但是一旦涉及到 RPC 协议的变化（从 SOFARPC 到 gRPC），后端缓存的变化（从 Memcached 到 Redis），应用还是需要去修改代码适配新框架的 SDK，这又是一件无论让应用还是让基础设施团队非常痛苦的事情，本质上还是应用去适配基础设施的变化，而不是反过来。\n###\nService Mesh 的未来方向：Cloud Native Application Runtime 那么我们应该如何去解决这个问题？在一次内部的会议上，我们和几个同事在讨论如何对 K8s 里面我们自定义的 Operator 进行规范化的问题，防止一个有问题的 Operator 把整个 K8s 搞挂了，但是一个同事提出了 Operator Framework 的想法，在 Operator 里面运行一个 Sidecar，这个 Sidecar 提供 Operator Framwork 的能力，这里面给了我们一个启发，可以用 Sidecar 这种模式去实现一个开发框架，一个运行时，来更好地帮助业务屏蔽掉对于后端基础设施的访问，我们看到业界也出现了这样的一些产品，比如 Dapr，CloudState 等，在这种模式下 Sidecar 已经不是一个简简单单的 Proxy，而是一个 Runtime，我们把这种形态称之为 Cloud Native Application Runtime。\n这种模式之所以可以称之为 Cloud Native Application Runtime，关键还是 Sidecar 定义了一套面向应用的 API，这套 API 正是解耦应用和基础设施的关键。有了这套 API Spec，就相当于在应用和基础设施之间构建了一层防腐层，只要这一层 API Spec 能够持续往前保持兼容，后面的基础设施不断地演进和变化，都不会动到应用侧，基础设施和应用之间才能够实现更加彻底的分离，未来基础设施无缝升级才会成为可能。未来云原生的应用在不同的云之间迁移，甚至基于多朵云来构建应用，应用这一侧也不用重复进行适配的工作，应该说，这种模式也是符合未来混合云的方向的。所以，我们大胆的预测，未来 Service Mesh 持续往前继续演进，必然会发展到 Cloud Native Application Runtime 这样的方向。\n基于这样的思考，在 2021 年，SOFAStack 社区一方面会继续推进已有的项目的健康发展，另一方面在继续在Service Mesh 的方向上深耕：继续分享在 Service Mesh 领域上的一些新思考之外，比如 Service Mesh 大规模落地之后的研发效率和运维效率的解决思路，我们也会和社区中的其他的组织一起通过 Service Mesh 的 Meetup 等活动继续推动 Service Mesh 的理念在国内的影响力，以及企业落地实践。（PS：最近 MOSN 刚刚公布了 2021 年的 RoadMap，欢迎大家关注：https://github.com/mosn/mosn/issues/1559，其他项目的 RoadMap 也会在春节后陆续和社区讨论然后公布；我们计划在 3 月份举办一次 Service Mesh 的 Meetup，欢迎感兴趣的社区同学报名)。\nSOFAStack 开源社区即将成立三周年，SOFA 团队深刻地体会到一个开源项目的持续健康地发展，关键在于社区和社区中的每一位开发者，是你们每一个 star，每一个 issue 和 PR 推动着项目的成长。特别感谢接近三年时间，大家一同参与社区建设，感谢一起帮助社区成长的小伙伴们。SOFAStack 开源社区还有很长的路要和你们走，我们也会联合其他社区一起推动 Cloud Native Application Runtime 的理念的落地和实践，希望有更多开发者可以和我们一起去探索 Service Mesh 的未来形态，一起推动其成为云原生应用构建的一种标准方式。\nAwesome SOFAer, then awesome SOFAStack， Let\u0026amp;rsquo;s have fun together！\n","date":1613113200,"description":"Special Weekly | SOFAStack 社区牛年展望，Let's have fun together!","dir":"blog/sofa-weekly-20210212/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3ef0208984bc034e62f2db51cf66a8e4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210212/","publishdate":"2021-02-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210212/","summary":"本文作者：蚂蚁集团黄挺（花名鲁直），SOFAStack 社区主理人，同时负责蚂蚁集团云原生方向的推动和落地，包括 Service Mesh、Serverles","tags":["SOFA Weekly"],"title":"Special Weekly | SOFAStack 社区牛年展望，Let's have fun together!","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210212/","wordcount":2162},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@李明阳 提问：\n SOFAArk 的项目里面 controller 层可以是 Biz 包么，这样 mng 里面引入 one，然后启动 mng 访问不到 one 里面的接口呢？ A：SOFAArk 的项目里面 controller 层不限制的，biz 包部署普通的依赖包，它是一个可执行的 jar，ark包 = biz + plugin + container，动态部署你可以通过 telnet 指令的方式去动态安装，不建议直接塞到 pom 里面去。\nSOFAArk：https://github.com/sofastack/sofa-ark\n@王盛 提问：\n 请教个问题：\u0026amp;ndash;set meshConfig.defaultConfig.binaryPath=\u0026amp;ldquo;/usr/local/bin/mosn\u0026amp;rdquo; 这个不起作用，有谁碰见过这个情况？ A：你用的是 istio1.5.2 吧，这个是不行的，istio 代码写死了的。这种手动注入应该可以的。这一块儿有些细节没有说明，你可以重新提交一下 pr。 MOSN：https://github.com/mosn/mosn\n@杨星 提问：\n 如果 Seata 使用注册中心的话，Client 端的 registry.type，与 config.type 需要改成对应的注册中心吧，Client 端的这两项配置的作用是什么？SeataServer 的这两项配置倒好理解，Client 端的config.type 目的是读取client端的配置信息，那 registry.type 是干什么的呢？\n A：我认为，registry.type 指的是注册中心的类型，config.type 指的是配置中心的类型。注册和配置中心是 2 个东西，我认为是从注册中心里拿 seata-server 实例，客户端找协调者。\nSeata：https://github.com/seata/seata\n本周推荐阅读 干货 | 蚂蚁集团是如何实现经典服务化架构往 Service Mesh 方向的演进的？\n 开源 | SOFAMesh 的通用协议扩展\n 【剖析 | SOFAMosn】系列之 SOFAMosn 的诞生和特性总览\n Service Mesh 发展趋势：云原生中流砥柱\n MOSN 项目进展 本月我们还认证了一位新的 Committer，是来自字节跳动的 郑泽超 同学，感谢 郑泽超 同学为 MOSN 社区做出的贡献。\n本周发布详情如下：\n1、MOSN发布 v0.21.0 版本，主要变更如下：\n 限流模块升级与优化，支持自定义过滤条件等能力 为适配路由支持变量机制对部分常量名进行了不兼容的删除和新增，可能会影响部分基于 MOSN 的代码编写 新增了 DSL(Domain-Specific Language)的路由支持 StreamFilter 模块支持加载基于 Go 动态连接库编写的 Filter 基于 XProtocol 实现了 DubboThrift 协议的支持 其他 BUG Fix 与优化 详细参考：https://github.com/mosn/mosn/releases/tag/v0.21.0\nSOFABoot 项目进展 本周发布详情如下：\n1、SOFABoot发布 v3.6.0 版本，主要变更如下：\n 支持本地开发时自动将 SOFABoot 日志输出到控制台 startup endpoint 采用新的数据格式，支持按时间轴分析 修复 baen 加载耗时的图形化展示问题 修复 ReadinessCheckListener 的启动顺序问题 SOFARPC 升级版本至 5.7.7 SOFATracer 升级版本至 3.1.0 SOFA-common-tools 升级版本至 1.3.2 Tomcat 升级版本至 9.0.37 使用 Github Action 进行CI 移除默认的 Maven Profile 配置 详细参考：https://github.com/sofastack/sofa-boot/releases/tag/v3.6.0\nSOFATracer 项目进展 本周发布详情如下：\n1、SOFATracer 发布 v3.1.0 版本，主要变更如下：\n 修复 flexible result.code 返回成功、失败 code 码 修复 DubboSofaTracerFilter Server span tag value error 修复 SofaTracerFeignClient 中 UnsupportedOperationException 问题 优化 spring mvc filter 的 error tag 支持 kafka 支持 RabbitMQ 支持 oracle rac JDBC URL 支持 hikari 详细参考： https://github.com/sofastack/sofa-tracer/releases/tag/v3.1.0\n","date":1612508400,"description":"SOFA WEEKLY | MOSN、SOFABoot、SOFATracer 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210205/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4cde1d3e68e2e13cbca7278164a4ab12","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210205/","publishdate":"2021-02-05T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210205/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、SOFABoot、SOFATracer 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210205/","wordcount":1518},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@潘麒安 提问：\n 请教下 session-server 报这个错，是需要扩更多的 session 么，但是 session进程本身 CPU 和内存占用不高。 A：看错误是把 session 发向 data 的处理队列打满了，可以排查一下，检查一下使用的版本，data 的资源使用和common-error.log 下的错误日志。\n SOFARegistry：https://github.com/sofastack/sofa-registry\n@刘达 提问：\n MOSN 怎么配置监听一个端口，这个端口上会接受有多种协议的数据，根据协议转发到不同的集群地址。ISTIO+MOSN， 用户 http 请求 gateway，通过 gateway 调 dubbo，每个应用自动注入 sidecar，测试没跑起来。 A：配置 Auto，支持协议自动识别，转发不同的集群，那就看路由了；用新版本，然后这样配置。 MOSN：https://github.com/mosn/mosn\n本周推荐阅读 剖析 | 详谈 SOFABoot 模块化原理\n 网商银行是如何建设金融级云原生分布式架构的？\n 实操 | 基于 SOFABoot 进行模块化开发\n 开源 | SOFABoot 类隔离原理剖析\n SOFABolt 项目进展 本周发布详情如下：\n1、SOFABolt 发布 v1.5.7 版本，主要变更如下：\n 优化 log4j2 日志配置，解决在异常场景下的性能问题 详细参考：https://github.com/sofastack/sofa-bolt/releases/tag/v1.5.7\nsofa-common-tools 项目进展 本周发布详情如下：\n1、sofa-common-tools 发布 v1.3.2 版本，主要变更如下：\n 修复 LogCode2Description 性能问题 详细参考：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.2\n","date":1611903600,"description":"SOFA WEEKLY | SOFABolt、 sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210129/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4f4f43ac764d4c99010c408e4d53c92e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210129/","publishdate":"2021-01-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt、 sofa-common-tools 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210129/","wordcount":934},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@叶毅威 提问：\n 请教下 SOFARegistry 数据持久化在哪里啊?\n A：SOFARegistry 的元数据（注册中心自身的 IP 列表之类的数据）存储在 meta 角色内，使用 JRaft 进行存储。 应用的发布数据保存在 data 角色的内存中，采用三副本（可配置）的方式实现高可用。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n@叶毅威 提问：\n 我用 SDK 调用注册了一个 datainfo 但是关掉之后 这个并没有下线，是哪里需要配置么，不是默认链接断开就下线么？\n A：session 上采用 HTTP 方式获取的数据都是当前节点的注册数据，只有 data 上才会做数据聚合。 dataInfo 是不会被删除的，连接断开后对应 dataInfo 下的对应 Publisher 会被自动移除。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n@田冲 提问：\n 现象：canal 监听到某个被分布式事务控制的表的 insert-binlog 日志后再去查询 MySQL 表里数据时发现这条数据不存在，延迟1秒钟左右再查询就能查询到。 疑问：seata-at 模式-两阶段提交的设计会出现 MySQL 先生成了 binlog 日志，后提交事务的情况吗？\n A：这个问题其实很简单，你 canal 读不到，那你自己应用本地事务提交后马上读这个 insert 的数据看能不能读到；如果读到，理论上来说这个过程不可能超过一秒，所以如果你应用能查到，你canal查不到，排查canal的问题，而不是 Seata 的问题；Seata 最后也只不过做了 connection.commit；最后事务的提交落库是数据库方本地事务流程落库，Seata 不会起到任何干扰，Seata 代理的是 jdbc 层的处理；redo 后写 binlog 时马上就会广播的，而不是事务提交才把 binlog 广播出去；所以内 xa 的二阶段没提交你就去查主库，由于隔离级别不一定查得到。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Kubernetes 是下一代操作系统 | 面向 Kubernetes 编程\n 蚂蚁集团生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理\n 蚂蚁集团服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析\n 开箱即用的 Java Kubernetes Operator 运行时\n ","date":1611298800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210122/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"16aa2c7282629fe75b244cdce08845e7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210122/","publishdate":"2021-01-22T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210122/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210122/","wordcount":1098},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@吴小彬 提问：\n 请教下，如果分支事务中使用了分库分表中间件（shardingsphere-proxy、mycat 等），Seata-AT 模式是不是不能用的？是只可以用 TCC 模式吗？现在的 shardingsphereProxy 中间件（不是 shardingsphereJdbc ）用 AT 模式，它对微服务来说就是一个 MySQL 连接，它是怎么知道微服务调用链中的 xid 的？\n A：可以用，shardingsphere 4.1 支持 Seata AT， proxy 我估摸着有点悬，因为他属于一个代理层。Jdbc 是直接在应用的 Jdbc 层提供服务的，所以 AT 可以很好的支持。\n@谭玖朋 提问：\n 在关于 AT 模式，第一阶段执行完后生成行锁然后注册分支事务，其中的行锁具体是指什么锁呢？因为发现第一阶段执行完后，其实再查数据的话是已经改变了。所以关于这个行锁这么解释？\n A：Select for update 的时候，首先 Seata 会代理这个语句，去查询 TC 这个行有没有锁住，如果没锁住，客户端业务用了 for update 那么就拿到了本地锁，此时因为本地锁排他，这个时候没有全局锁的 for update 就是分布式下的读已提交。 不是允许脏读，是读已提交。读未提交是默认的，所以只有在你 update 的时候（update 是当前读），但是如果你的 update 是基于快照度的 select 结果，可能会出现事与愿违的结果，如果你要基于某个数据来 update，要么 for update 来读分布式下的已提交，要么就用 update x=x-1 之类的写法，因为提交时会抢占全局锁，没抢到会 rollback，释放当前锁进行重试，这样就能保证抢到锁的时候，update 的数据当前读是分布式下的读已提交并修改 目前好像没人写关于 AT 行锁及全局锁部分源码有分析讲解的资料，如果感兴趣可以去阅读一下，写出来投稿给我们。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Mecha：将 Mesh 进行到底 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 Service Mesh 和 API Gateway 关系深度探讨 Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍 Occlum 项目进展 Occlum 发布 v0.19.1 版本，主要变更如下：\ni.同时兼容 Glibc 和 musl libc的应用\nii. 支持基于 DCAP (Intel SGX Data Center Attestation Primitives) 的远程验证\niii. 修复了内存泄漏问题\n详细发布报告： https://github.com/occlum/occlum/releases/tag/0.19.1\n","date":1610694000,"description":"SOFA WEEKLY | Occlum 发布新版本，Seata QA 整理","dir":"blog/sofa-weekly-20210115/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"48d18f44f20f4b6d5f8b219e383bfa51","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210115/","publishdate":"2021-01-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210115/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Occlum 发布新版本，Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210115/","wordcount":1106},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王家爵 提问：\n SOFABoot 项目要一两分钟才能启动，目前这边有监控工具可以看到启动过程中各个步骤的耗时吗？\n A：3.6.0 之后可以通过 actuator/startup 查看启动的耗时分布。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n@东仔 提问：\n SOFABolt 的最新分支是哪个？\n A：master 就是最新分支。https://github.com/sofastack/sofa-bolt\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\n我是一个小胖子 提问：\n 请问现在已经支持自适应限流了吗？\n A：开源版本里有基于 sentinel 的自适应限流，这个你可以看看 sentinel-golang 的文档，但是和我们内部用的自适应限流有一些差异。\n 你们内部不用 sentinel 是吗？\n A：也用，我们基于 sentinel 做了一些扩展。\n「MOSN」：https://github.com/mosn/mosn\n来永国 提问：\n 为什么我起了 RPC 服务端客户端和注册中心，然后连接调用是可以的，然后我把注册中心关了，它还是跑得通？\n A：client 会有缓存的。\n 获取注册中心的服务有 API 接口吗?\n A：有的，有个从单机 session 获取数据的接口 curl localhost:9603/digest/pub/data/query?dataInfoId=com.test.SimpleService#@#DEFAULT_INSTANCE_ID#@#DEFAULT_GROUP dataInfoId 参数需要进行 url encode 应该还没公开的 API 文档，获取数据的 HTTP 接口也不太易用，我最近会补一下文档还有方便使用的接口。\n 那看样子这个相当于是指定搜索了吗？\n A：是的，目前没有模糊查询的接口， curl localhost:9603/digest/getDataInfoIdList 你可以用这个 API grep 一下。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1610607600,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20220114/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7e0323f9034710384e38cbb6f2176adf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220114/","publishdate":"2021-01-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220114/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220114/","wordcount":1222},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@梁俊 提问：\n 有一台物理服务器，没有安装 OS，是不是可以把 Occlum LibOS 像通用操作系统一样当做 host OS 用，运行 Occlum LibOS，需不需要在物理服务器上安装 host OS?\n A：Occlum 对硬件也是有要求的。这个机器需要支持 Intel SGX 技术。简单得说，就是必须可以安装 SGX 驱动。 Guest OS 是虚拟机的概念，从 guest OS 的角度看，OS 依然运行在 kernel 态。简单来说，如果想使用 Occlum，那么建议方案： 1 . 找一台 SGX 机器 （比如 W55）； 2. 安装一个OS，并且装上 SGX 驱动； 3. 安装 Occlum；\n Occlum 相对于 Docker 有哪些优势，比 Docker 快吗?\n A：Occlum 的优势是安全。外界无法探测运行在 Occlum 中的程序和这个程序使用的内存以及寄存器。也就是说，可以把机密信息（比如密钥）放在 Occlum 中而不用担心信息泄露。\nOcclum：https://github.com/occlum/occlum\n2、@李天宇 提问：\n 可不可以定义一个这样的准则每个 RPC 后面，必须得有一个 TM，每个 TM 维护一个 TM 块，RPC +1，就应该等于 TM 块？ A：这样一个完整的链路有多少个参与者，发起者可以获得，校验规则就是 spanid 是否与参与者数量 +1，是否相等？认为 RPC 向下的服务资源都是一个完整的事务，不管它是否与 db 交互，即可以无 RM ，我的想法就是让 TM 发起者，可以随着链路信息感知所有的 TM。 Tm 可以在每个微服务上都标注下 注解，默认是加入到之前的事务中。TraceId 可以塞到 Seata 的协议中传递到 RPC 下游。\n3、@李天宇 提问：\n 支持不同 branch 不同的 type 吗？\n A：AT 和 TCC 可以共存，Saga 不行。比如 a 数据在 AT 下被改，又被 Saga 或者 xa 分支改动，因为它们不是 AT 无法通过全局锁保证隔离性，除非所有的模式只要内部含有 AT 分支，都去获取全局锁，这样带来了一个问题，如何提前知晓某个 TM 的调用链路中有 AT 分支，靠用户注解上写，那入侵性就有点大了。\nSeata：https://github.com/seata/seata\n本周推荐阅读 SOFAEnclave：蚂蚁机密计算如何解决现实挑战？ 蚂蚁集团宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 开源项目是如何让这个世界更安全的？ 网商银行是如何建设金融级云原生分布式架构的？ MOSN 项目进展 本周发布详情如下：\n1、MOSN 发布 v0.20.0 版本，主要变更如下：\n 路由模块进行了优化与重构，支持变量机制与可配置的扩展模式 使用的 Go 版本升级到了 1.14.13 支持 XDS 非持久化模式下配置的热升级 完善支持了 Netpoll 模式 其他一些新功能、优化与 Bug Fix 详细参考：https://github.com/mosn/mosn/releases/tag/v0.20.0\n","date":1610089200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20210108/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"86ee4a89adc2c475c6f406d2774743c8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210108/","publishdate":"2021-01-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210108/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210108/","wordcount":1294},{"author":"小蚂蚁","categories":"SOFAStack","content":" Forrester 认为：\n包括容器、微服务与服务网格等领域在内的云原生平台，将成为构建适应未来的现代企业的核心引擎。\n在常态化混合异构环境下，面对云原生应用路径的多样化趋势与全维度挑战，企业必须将服务网格技术与微服务有效结合，才能真正释放云原生技术的红利。\n近几年云计算发展如火如荼，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施的统一资源调度带来了极大挑战。\n在越来越复杂的异构基础设施上，存量应用和增量应用应该如何上云？面对大量异构基础设施带来的挑战，企业如何最大化上云价值？\n服务网格（SOFAStack Mesh）是蚂蚁集团自主研发的基于金融级生产实践的增强版服务网格平台，将传统微服务和 Service Mesh 技术进行了深度融合，其核心技术经过了蚂蚁集团的大规模生产实践验证。\n它深度、无缝对接了 SOFAStack 经典应用服务和容器应用服务，为客户提供了简单易用的 Service Mesh 架构的支撑平台。目前， 服务网格已经广泛应用在大型金融机构。\n近日，蚂蚁集团联合 Forrester 公司发布了《蚂蚁集团服务网格总体经济影响》（以下简称白皮书）。\n白皮书基于蚂蚁集团云原生分布式架构 SOFAStack，结合客户使用的成本节省情况和业务收益，为企业上云提供新的路径方法与参考实践。\n白皮书首先系统地分析了全球企业在资产现代化、数字化等市场趋势下面临的风险与挑战，面对挑战。Forrester 提出适应未来 (Future Fit) 的技术战略模型。\n即以客户为中心，帮助企业快速重构业务结构和能力，调整运营方式，以自适应性、创造力和韧性满足未来客户和员工的需求。而平台、实践与合作伙伴将成为构建这一技术战略的关键因素。\nForrester 认为，包括容器、微服务与服务网格等领域在内的云原生平台将成为构建适应未来的现代企业的核心引擎。\nForrester 在报告中指出，在常态化混合异构环境下，面对云原生采用路径的多样化趋势与全维度挑战，企业必须将服务网格技术与微服务有效结合，才能真正释放云原生技术的红利。\n具体而言，企业技术决策者与实践者应当积极拥抱服务网格技术，并致力于在以下四个方面实现异构分布式环境下的策略化、平台化赋能：可观测性、微服务治理、灰度发布与部署、微服务框架可管理性。\n 可观测性 通过服务网格，Sidecar 代理可以主动观测相关微服务的调用关系，并将链路信息进行统一日志记录。而企业级的服务网格监控工具，应当可以对服务网格产生的遥测数据进行分析与关联。为企业开发与运维团队提供可视化的链路拓扑、实时的监控报告、基于策略的告警，以及分布式追踪与故障定位能力。\n 微服务治理微服务 主要治理能力还包括服务发现、流量治理、安全通信和应用弹性伸缩。服务网格通过基于策略的运行状况检查、动态路由、自动重试、服务熔断、服务降级、服务限流等机制提升微服务运行时的可配置性与健壮性，从而显著简化异构环境下微服务治理的技术复杂性。\n 灰度发布与部署 服务网格提供对调用方与服务方透明的灰度代理开启机制和有效的回滚机制，从而实现一体化、精细化与智能化的灰度发布与部署能力。在保障业务连续性与客户体验稳定性的同时，加速客户价值交付。\n 微服务框架可管理性 借助服务网格，企业能够将服务治理能力从各类异构的微服务框架下沉到服务网格所在的基础设施层面。而微服务框架自身只需要聚焦业务核心实现和语言差异性，从而实现微服务框架在服务治理层面的轻量化。\n面对技术发展和市场需求，蚂蚁集团在近十多年五代架构的演进过程中，经过充分的迭代和验证，逐渐沉淀出了一套金融级分布式架构 SOFAStack。\n其中的服务网格产品 SOFA Mesh 是基于 Istio 开源项目研发的企业级云原生网络通信方案，为分布式应用提供流量管理、安全加密、可观察性、服务治理等能力，实现灰度发布、蓝绿部署、滚动升级，助力企业数字化转型。\n蚂蚁集团数字科技事业部产品总监马振雄认为，相比于其他上云方式，Service Mesh 能够实现跨平台、跨协议，并且业务代码无侵入改造。从而快速地将应用植入 Sidecar 完成 Mesh 化，获得分布式红利、安全可观测，并且整个架构平滑演进。企业在架构升级过程中可以按部就班、循序渐进，并且实现端到端的安全可信以及全链路可观测能力。\n蚂蚁集团客户的访谈提到，Forrester 发现无论是传统金融机构还是互联网金融机构，都面临在混合架构下存在的共性挑战，包括基础设施升级换代、应用开发升级、云上云下交互等方方面面。\nForrester 表示，对于金融机构而言，网格服务在单体应用改造成本、云原生环境开发人员效率提升、运维安全管理效率提升以及替代旧有系统等方面能实现明显的降本增效。通过研究三年数据测算，使用蚂蚁服务网格产品后，其客户的投资回报率达到 99%。\n以某资产总额超一万亿的省级农信为例。\n随着金融科技的迅速发展，该银行积极加速数字化转型。在转型过程中，遇到了异构系统难以统一治理，技术栈绑定等一系列问题。蚂蚁集团 SOFA Mesh 帮助该用户：\n构建全行级通信网络，异构系统服务治理， 低成本云原生落地，实现无侵入平滑上云，无需修改业务代码，无需考虑依赖关系；\n同时支持架构灵活演进，兼容 ESB 等传统异构系统，帮助客户最大化上云价值。\n此外，SOFA Mesh 还能够实现以下重要的非量化重要收益：\n 统一监控能力 SOFA Mesh 能够实现传统技术栈和云原生环境的统一监控，提升问题定位效率。\n 精准故障定位 对于已完成了微服务化改造的服务云原生环境来说，服务网格提供了强大的流量管控能力，通过调用链精准定位故障。\n 故障复盘资源消耗节省 对于监管要求极高的金融企业，在故障出现后要进行全面复盘，以确保系统未来的可用性，避免类似事故发生。但复盘也消耗大量开发运维人员的时间，对工作效率产生影响。\n 组件能力提升 解耦后的微服务的公共组件、业务组件、及安全组件都得以实现性能上的提升。\n未来，蚂蚁集团希望和更多合作伙伴一起，借助 SOFAStack 以及服务网格的成功实践经验，让更多企业用户低成本上云，迈向数字化云原生的新时代。\nSOFAStack 社区为了能提供更好更优质的内容来满足大家的需求、口味\n特别设计了本次的问卷，大概占用您 2 分钟的时间～\n我们会选取 5 份认真回答的问卷送出SOFAStack 社区的 2022 限量新年礼物\n快扫描二维码一起写问卷吧～\nhttps://www.wjx.cn/vj/rXjIC9b.aspx\n本周推荐阅读 「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\nService Mesh 双十一后的探索和思考(下)\n","date":1609743600,"description":"服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书","dir":"blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9fdc287491ed68fe45196c70d88a67c9","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","publishdate":"2021-01-04T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","summary":"Forrester 认为： 包括容器、微服务与服务网格等领域在内的云原生平台，将成为构建适应未来的现代企业的核心引擎。 在常态化混合异构环境下，面对云原生应用路径","tags":["SOFAStack"],"title":"服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书","type":"blog","url":"/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","wordcount":2531},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News  SOFA 社群元旦快乐！新的一年我们也要在一起哦！\n同时，也有一个好消息要和大家共享： MOSN 荣获 「2020 年中国优秀开源项目」，感谢所有开发者们的支持和喜爱，MOSN 团队会继续努力，提供更好的开源产品和服务，也期待大家的持续共建。\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@苏榴结 提问：\n 对于某个全局事务来说，向 tc 注册说你是 tm 也是 rm，但因为这个全局事务已经有了 tm，所以它就会被认定为rm 是吗？\n A :服务起来的时候就跟 TC 说了你可以做 TM ，也可以做 RM (分别建立一个长连接与 TC 通信)，然后在需要进行某个全局事务的时候，如果他是发起全局事务的那个，那么他就发挥了他 TM 那部分职能，如果他是负责操作数据库，那他就发挥了 RM 那部分的职能。\n2、@刘亚飞 提问：\n 为什么图 1 中描述用协程池来处理可读 conn，图 2 中，又说每一个 conn 有一个读协程呢？是因为图 1 描述的是 rawpoll 模型下的代码方式，而图 2 是 goroutine-per-connection 模式下的一个 write goroutine 池化吗？\n 图1\n图2\nA：图 1 图 2 属于两种模型。Rawpoll 模型的话就是自己做 epoll_wait，有可读事件从协程池拿一个协程来读取数据；协程模型的话就是一个连接一个协程，标准的 go 编码模式，runtime 来处理 epoll_wait，可配置选择不同模式。\n本周推荐阅读 云原生网络代理 MOSN 的进化之路 基于 MOSN 和 Istio Service Mesh 的服务治理实践 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 SOFA项目进展 本周发布详情如下：\n1、SOFA-Common-Tools 发布 1.3.1 版本：\n 修复多 classloader 场景下 commons-logging 的兼容性 修复 SOFAThreadPoolExecutor 被删除的方法，提高向下兼容性 详细参考: https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.1\n2、SOFA-Ark 发布 1.1.6 版本：\n 支持插件扩展，通过宿主动态扩展指定 plugin 依赖和导出关系 SOFA-Ark-manve-plugin 支持打包按规则排除依赖（from file） 详细参考： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.6\n","date":1609398000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201231/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ca60ed7c9ac011477c8861c0f5650629","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201231/","publishdate":"2020-12-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201231/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA 社区元旦快乐，MOSN 荣获 2020 中国优秀开源项目","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201231/","wordcount":994},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@薛帅领 提问：\n 多数据源切换后，增加事务但不起作用（切数据源是执行方法后才切换的），本地事务及 Seate 分布式事务也不行，这个有什么好的解决方案吗？\n A：Spring 本地事务注解本身就不支持多数据源事务，且如果你开启了本地事务，之后并不会进入你的切换数据源的切面。 在多数据源下，去掉本地事务注解就好了。用 globaltransactional 注解在多数据源的入口加上，多个数据源都被 Seata 代理的话，就会保证多数据源的事务。\n2、@李天宇 提问\n 如果在分布式事务中，另一个线程做批处理 update 之类的，是否会锁住呢?\n A：不会，另一个线程也要记得加上 globaltransactional 注解就行了。在 a 线程要提交之前要去尝试拿到它修改数据的全局锁的，如果 a 拿到了，但是还没到二阶段提交，b 也是要去尝试拿，拿不到就会不执行 SQL，等待全局锁释放了，也就是 a 发起的事务结束了，b 才能执行 SQL 提交。这样就保证了利用全局锁（粒度行级），来达到隔离性。\nSeata：https://github.com/seata/seata\n相关推荐阅读 Kubernetes: 微内核的分布式操作系统 走出微服务误区：避免从单体到分布式单体\n 网商银行是如何建设金融级云原生分布式架构的？\n 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构\n SOFA 项目进展 本周发布详情如下：\nSOFA-Common-Tools 发布1.3.0 版本，主要变更如下：\n SOFA 线程池支持 ScheduledThreadPoolExecutor 与 ThreadPoolTaskScheduler 新增 SofaConfigs 支持统一的配置获取 新增 LogCode2Description 支持统一的错误码获取 重构线程池实现，支持更丰富的监控数据 所有组件统一 spce 属性获取逻辑 修复配置日志输出到控制台时不生效的问题 详细参考：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.0\n祝大家圣诞节快乐！\n","date":1608879600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201225/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"59bc2ae2a6b06f7ca356aeb61a6c78fd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201225/","publishdate":"2020-12-25T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201225/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA-Common-Tools 发布新版本， QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201225/","wordcount":963},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@缪文 提问:\n SOFA-Boot 框架，模块隔离时，子 module 中引入 mybatis 框架，@MapperScan 注解是在RootContext 中扫描，还是在子 module 中扫描？\n A: 非 auto 的 configuration 都是在对应模块进行解析的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n2、@李扬 提问：\n 分支事务被回滚是同步还是异步的,如果是异步的,能加监听方法吗?\n A：可以实现 transactionhook 这个类，然后在 tm 发起者里加入到 Transaction HookManager#registerHook 。这样在二阶段决议后，可以做一些小动作，比如二阶段提交的时候，再执行 redis ，mongo 的数据插入。\n3、@吴国柱 提问：\n 本地事务与全局事务一起开启会有问题吗？\n A：全局事务要在本地事务的外层,就是包裹本地事务，不能由本地事务包裹全局事务。本地事务出异常都不会进行注册，也就代表本地事务如果出问题本地事务自行会回滚(基础知识)，如果本地事务提交了，其它服务的本地事务出现异常，或者业务代码出现异常，将有 Seata来负责把已提交的事务回滚。\nSeata：https://github.com/seata/seata\nSOFAChannel 部分合辑 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 蚂蚁集团分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁集团分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 相关推荐阅读 剖析 | 详谈 SOFABoot 模块化原理 蚂蚁集团研发框架日志隔离解析 | SOFABoot 框架剖析 蚂蚁集团研发框架总览 | SOFABoot 框架剖析 ","date":1608274800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201218/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"712d560758c60f16cc7d2651bb781e65","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201218/","publishdate":"2020-12-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201218/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 线上直播合辑整理，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201218/","wordcount":949},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 【12/07 - 12/11】每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@bruce 提问：\n SOFAJRaft 可以实现在三个节点中选出一个 leader , 其他逻辑由自己实现吗?\n A：可以，可以不用状态机，也不用加载和持久化快照, 只需要选个 leader。 \u0026amp;gt; 各个节点如何知道自己是主还是从?\nA：示例 2、@李明 提问:\n 全局事务执行过程中，有其他线程操作数据库，这时全局事务执行失败，在回滚的时校验数据发现数据被修改过，导致回滚失败，这种情况怎么避免?\n A：其他线程也加上 global transactional 注解。分布式事务下，没有单个分支是独立的个体存在，需要拿到全局事务中，让其他事务知晓他的存在，从而避免在分布式调用链路中，恰好遇到同一个数据进行修改时，发生的脏写脏读 globallock 是在更新前去 tc 看下这个时候这个数据有没有被其他事务锁定，没有的话就说明这个数据没有被其他事务使用，是提交的数据，所以这叫读分布式事务下的已提交。 但是他并没有去注册分支，也就是他没有去占有这个全局锁，来达到分布式事务下的排他性。他在得到 tc 响应的时候，去执行 update 是有时间的，此时有个分布式事务下的分支 update 后，拿到了全局锁，然后他的链路二阶段是回滚 ，但是数据就被你这个认为没有全局锁的本地线程给改了，这就导致被干扰无法回滚。 所以 globallock 需要配合 sql 语句，在 update 前，先做 for update 这个数据，拿到这个数据的本地锁，拿到本地锁之后，再去 tc 判断有没有全局锁，如果 tc 没有锁，因为本地已经拿到本地锁了，具有本地事务的排他性，其他分支事务拿不到该数据的本地锁，是无法去注册分支去拿到全局锁，也就是禁止了其他分支事务的干扰，所以不会脏写。 目前 tcc 下一般就是 globallock+select for update 来防止被其他 at 事务改动后，进行了脏写。\n3、@ 尚攀 提问:\n Raft 是为了解决目前的什么问题？\n A: 依赖外部存储。AT 有 before 镜像、after 镜像，after 镜像是在 undo_log 表里存储，那么 before 在哪里存着了？未来的 Raft 模式，集群支持动态扩缩容，事务信息存储在内存中（测试下来比 redis 快），现在的全局事务信息，分支事务信息，全局锁都是持久化到 db，或者 redis 去的。如果这个时候持久化用的 db 宕机了，Seata-Server会不可用，而集成了 Raft ，leader 宕机后自动选举新 leader，继续运转。所以，利用 raft 一致性算法，可以让多个Seata集群内存中的数据保持一致。\n相关推荐阅读 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑\n 蚂蚁集团生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理\n 蚂蚁集团 SOFAJRaft 优先级选举剖析 | 特性解析\n 剖析 | 蚂蚁集团生产级 Raft 算法 SOFAJRaft 合辑\n Seata 项目进展 本周发布详情如下： 发布 Seata 1.4.0 版本，主要变更如下：\n 支持 yml 配置文件 支持 Oracle nclob 类型 支持客户端最少的活动负载均衡 支持客户端一致性哈希的负载均衡 支持 Spring Boot 使用自定义配置中心和注册中心 支持配置默认全局事务超时时间 多处 BUG 修复和功能优化 详细参考：https://github.com/seata/seata/releases/tag/v1.4.0\n","date":1607670000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201211/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dc10639aea7c443d918ac8f8355ed64c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201211/","publishdate":"2020-12-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201211/","summary":"SOFA WEEKLY | 【12/07 - 12/11】每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是","tags":["SOFA Weekly"],"title":"SOFA Weekly | Seata 发布新版本， QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201211/","wordcount":1418},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@刘江涛 提问： \u0026amp;gt; 已知在同一个分布式事务中，各个 RM 的模式都应该与对应 TM 模式相同。那同一个微服务可以多种模式并存吗？比如 AT , XA , Saga 并存，然后 A 业务使用 AT 模式，B 业务使用其他模式之类的。\nA：不可以，隔离性无法得到保证。如果要一起用，就要保证一条调用链路中所有数据的隔离性，也就是跟 AT 一样都得去竞争锁，而且 Saga，TCC 之类的对 SQL 没要求，可能在跟 AT 一起使用的时候就有要求了，得不偿失。\n 如果公司要引入多种模式的话，微服务之间的关系是这样的吗？\n A ：是的，当然 AT 集群是可以调 Saga 集群的，但是他们不能属于同一个全局事务,也就是 AT 那个事务提交了，Saga 的如果回滚了，是 Saga 集群的问题，等于有 2 个全局事务的诞生。 Seata：https://github.com/seata/seata\n相关推荐阅读 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化\n 云原生网络代理 MOSN 透明劫持技术解读 | 开源\n 基于 MOSN 和 Istio Service Mesh 的服务治理实践\n 云原生网络代理 MOSN 的进化之路\n MOSN 项目进展 本周发布详情如下： 1、MOSN 发布了 v0.19.0 版本： - 重构了 StreamFilter 框架，提供更强的可复用的能力 - 支持 MaxProcs 可基于 CPU 使用限制自动识别的能力 - 支持指定 Istio cluster 的网络 - 针对高并发场景的内存使用进行了优化 - 多处BUG修复\n详细参考：https://github.com/mosn/mosn/releases/tag/v0.19.0\n","date":1607065200,"description":"SOFA WEEKLY | 【11/30 - 12/04】每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201204/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4123f0805fdf3799cbafcc143f8d6bac","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201204/","publishdate":"2020-12-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201204/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本、 Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201204/","wordcount":843},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech\n SOFAStack：https://github.com/sofastack\n 社区 Big News  SOFAStack 获得 2020 年度 OSC 中国开源项目评选「优秀 Gitee 组织」，感谢所有开发者们的支持和喜爱，SOFA 团队会继续努力，提供更好的开源产品和服务，也期待大家的持续共建。 2020 年度 OSC 中国开源项目评选结果公布\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张松 提问： \u0026amp;gt; SOFARPC 支持提供者注册的时候配置一个标识，然后消费者根据这个标识来获取到对应的服务提供者吗？类似于对服务提供者做一个分组。\nA：你是指 SOFARPC 的 unique-id 吧，支持的。 \u0026amp;gt; 不是，类似于分组的配置，因为我这边现在需要多环境，要来区分同一个注册中心下的同一个接口的不同分组。\nA：SOFARPC 就是用 uniqueId 来区分同一个接口，不同实现的。SOFARPC 没有 group 的概念，只有一个 uniqueId，需要服务方和调用方配置一样，强隔离的。 SOFARPC：https://github.com/sofastack/sofa-rpc\n2、@徐泽唯 提问： \u0026amp;gt; 自动降级以后如果调用的服务抛错了 数据是不是就不对了？\nA：自动降级只是发起者那边发现 SeataServer 不可用后，不去走 begin 。你业务数据就完全没全局事务的允许运行，是会出现数据不一致。比如seata-server宕机了，后续的服务因为 Seata-Server 宕机，不走分布式事务，此时全局事务有部分数据是需要回滚的，但是由于Seata-Server宕机了，导致没法回滚，这个时候不经过全局事务的事务执行就会导致数据不一致。所以说，tc 最好集群搭建，以免宕机后，降级代表了你允许 at 模式下数据不一致。 Seata：https://github.com/seata/seata\n相关推荐阅读 蚂蚁金服微服务实践 | 开源中国年终盛典分享实录 火了 2 年的服务网格究竟给微服务带来了什么？ 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下： 1、SOFAJRaft 发布了 1.3.5 版本： - 增加对IPv6的支持＃526 ＃527 - 升级\u0026amp;rsquo;rocksdb\u0026amp;rsquo;到5.18.4以支持AArch64\n- 优化：心跳响应不经过管道直接发送，避免管道影响心跳响应的及时性 详细参考：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.5 2、SOFABoot 发布 3.4.6 版本: - 支持手动 readiness 回调（健康检查二阶段） - 扩展点失败反馈健康检查，默认为否 - 提供上下文隔离场景下获取所有 Spring 上下文的标准方法 - Bean 加载时间和层级树形分层显示\n详细参考：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.6\n","date":1606460400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201127/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f379c4483cff2807f5cfe8c6bbab5d8c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201127/","publishdate":"2020-11-27T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201127/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/23 - 11/27】SOFA Weekly | SOFAJRaft 、SOFABoot发布新版本，SOFAStack 获优秀 Gitee 组织奖","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201127/","wordcount":1352},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech\n SOFAStack：https://github.com/sofastack\n 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@小刘 提问： \u0026amp;gt; 刚开始用 Seata ，方法上用了 @GlobalTrasactional + mybatis 插入一条数据的时候返回的自增id不正确,取消@GlobalTrasactional用普通的事务@Trasactiona 插入数据的时候返回的自增 id 正常了。\nA: 这个基础是有问题的。全局锁的作用是锁定并发修改时的数据的，不是针对接口。接口并发肯定是多线程走的，不可能阻塞等待排队。 Seata：https://github.com/seata/seata\n2、@初识 提问： \u0026amp;gt; 防悬挂是怎么理解的？能简单说说吗？\nA: 保证一致性，幂等用的。比如a-\u0026amp;gt;b，因为特殊原因，比如全局事务超时，b注册上了分支事务，本地事务的 commit 还没执行的时候，全局事务回滚下发到了，如果这个时候本地事务 commit 了，那么数据就不一致了，所以全局事务回滚下发到了，会插入一个 undolog ，让本地事务 commit 的时候因为 undolog 唯一索引冲突使本地事务提交失败，触发回滚，保证了当全局事务状态是回滚时，分支事务都是回滚的。 当然，如果是 commit 了，再收到下发回滚，因为 commit 了已经有 undolog了，那么会通过 undolog 回滚，这个针对的是没有 undolog 时的情况。\n**3、@StevenCheney **提问： \u0026amp;gt; Nmosn 的版本 和 Istio 有对应关系吗？\nA：目前的 Master 支持 1.5._，但是上次看1.5._的时候有一些注入的问题，你可以看一下 feature-istio_adapter 这个分支，最近应该会合并一些pr进来，到时候可以直接适配1.7._，理论上1.6._也是可以支持的，需要测试一下。 \u0026amp;gt; Docker image 会同步更新吗？\nA：主要是看你的需求，如果你是只要 MOSN ，不要 Envoy，就直接使用https://github.com/istio/istio/issues/23753 这个来打包，如果你都需要的话或者说不介意多一个 Envoy，就直接使用 proxyv2 打一个就好了。 MOSN：https://github.com/mosn/mosn\n本周推荐阅读 蚂蚁智能运维：单指标异常检测算法初探 蚂蚁宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 企业数字化转型指南，《SOFAStack 解决方案白皮书》正式发布 SOFA 项目进展** 本周发布详情如下： 1、SOFA-Common-Tools 发布1.2.1版本：\n 重构了本地控制台输出日志逻辑； 移除了 log-sofa-boot-starter 相关代码； 详细参考： https://github.com/sofastack/sofa-common-tools/releases/tag/v1.2.1\n","date":1605855600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201120/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a81d6649eb11649a90e54eef8a5a57e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201120/","publishdate":"2020-11-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201120/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/16 - 11/20】SOFA-Common-Tools 项目发布新版本、Seata、MOSN 相关 QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201120/","wordcount":1234},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@杨文鹏 提问：\n 感觉 SOFAArk 在静态合并部署情况下,和 SOFABoot 的类隔离起到的作用是一样的？不知道我理解对不对。\n A：SOFABoot 没类隔离，它的类隔离就是继续 SOFAArk。 \u0026amp;gt; 比如新建一个 SOFABoot 应用，需要再手动集成 SOFAArk 吗？\nA：需要的。\n SOFABoot：https://github.com/sofastack/sofa-boot SOFAArk：https://github.com/sofastack/sofa-ark 2、@倪绍东 提问：\n 如果是提交阶段有数据库失败了，其他成功的怎么办呢，没办法了吧？\n A：一阶段提交,二阶段不可能提交的情况下还失败，XA 本地事务一阶段持久化在数据库层面不可能丢失，本地事务undolog跟redolog了解一下。对 Seata-server 来说保存了事务状态，如果二阶段有节点执行失败，就重试，直到成功。也就是你节点二阶段执行失败，自己了解下为什么你数据库出问题了，而不是分布式事务有什么问题。 \u0026amp;gt; 会不会出现重试过程中，其他事务修改了现有数据，而最终又被重试成功的情况?\n A：二阶段提交代表了什么？代表了整个调用链是成功的，一个成功的分布式事务，一阶段已经持久化了，你再去改，这个数据又不是脏的有什么问题？XA 来说，本地事务的本地锁先了解一下，一阶段不提了，锁被本地持有，如何修改？本地排它锁都没释放，何来脏写。\n3、@李艺渊 提问：\n Seata TCC 模式下，订单微服务和库存微服务。订单微服务try阶段添加订单信息，现阶段可以支持在库存微服务try阶段获取订单信息吗？或者说能把创建好的订单信息存储到 Seata-server ，然后在其他微服务可以获取到吗？\n  A：我理解 Server只负责全局事务的流转，try 出错就 cancel ，成功就 commit。Try 里面对两个库操作，正常是可以拿到数据吧。 \u0026amp;gt; 这2个微服务是分开部署的，数据库也是分开的。像订单微服务的 try 阶段，把订单信息存储到 order 数据库了。那库存微服务是不会去访问 order 数据库的。现在就是看库存微服务如何获取到新增的订单信息，看有没有什么 好的方式。\n Seata：https://github.com/seata/seata Service Mesh 相关推荐阅读 Service Mesh 中的可观察性实践 陌陌的 Service Mesh 探索与实践 - 直播回顾 Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 Apache SkyWalking 在 Service Mesh 中的可观察性应用 ","date":1605254400,"description":"【11/9-11/13】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201113/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"59cb50e2977d5e0b3ad675ca234c2b0f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201113/","publishdate":"2020-11-13T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201113/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 相关阅读合集、SOFABoot 以及 Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201113/","wordcount":1270},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、《Service Mesh Webinar#4:阿里云 CDN 微服务架构演进之路》直播回顾以及 QA 整理 视频回顾地址：https://www.bilibili.com/video/BV13D4y1R7do/\n@道酉 提问： \u0026amp;gt; 请问阿里云 MOSN 两个容器的热更新怎么实现的，就是怎么在pod内添加一个容器再去掉一个\nA：我们其实也没用跨容器热升级的方式，两个 Pod 挂载相同目录的方式是支持的。\n@陈鹏 提问：\n 请问一下同一个容器的热升级是怎么做的呢？\n A：我们是通过 RPM 升级的方式，容器内 systemd 管理的进程。\n@梁昌泰 提问：\n 重启不叫热升级吧？\n A：没有重启哈，直接起来一个新的进程。\n2、@谢子华 提问：\n Seata Saga 中，TC 的作用是什么？在 Saga 执行过程中 TM、TC、RM 和状态机的交互过程是怎样的？\n A：1）发起重试。2）根据分支响应状态，判断是否切换重试方向。目前，Sage 的分支默认情况下不会注册到 TC 了的，因为 Saga 本地库里有各 RM 的数据。 只有全局事务注册和全局事务提交或回滚时，与 TC 交互。\n 现在二阶段重试失败不断发起重试在 1.4.0 版本解决了吗？判断是否切换重试方向是只有可能 TC 会决定向后或者向前重试？\n A：是由 RM 端返回的状态为依据，由 TC 端切换重试方向，决定权在 RM 端。\n 我的理解是 RM 告诉 TC 回滚失败，然后有可回滚和不可回滚两个状态，TC 根据这个决定是否继续重试？那如何在 RM 进行配置？\n A：我刚才的截图是 TC 端发起全局提交时，RM 返回“回滚”失败重试回滚，这种情况，默认情况下不存在了，因为 Saga 不会注册分支到 TC。 实际上，应该是在 SagaCore 的全局回滚时，RM 端如果返回“提交”失败，重试提交状态时，会切换到向前重试。\n看了下源码，只有全局事务是因超时而进入全局回滚时，才会切换重试方向。\n 切换重试方向是指本来流程图配置是向后重试，然后超时了，TC 会切换为向前重试？\n A：意思是全局事务正在运行时，因超时60秒，TC 端自动将全局事务标记为超时回滚状态，然后会异步发起全局回滚请求。 这种情况下，碰到回滚失败时，会切换为向前重试。\n 哦哦，原来是这个样子。默认情况下，本地只会把全局的 RM，状态发送给 TC?\n A：默认情况下，RM 的数据只会存在本地。TC 端可以说是不管 Saga 分支的情况的。TC 只管接收 1）TM 的开始全局事务、完成全局事务；2）超时进入全局回滚；3）根据状态判断是否继续重试，还是切换重试方向。\n 1)是 TM 监测到所有 RM 都已完成然后告诉 TC 全局事务结束？3)TC 根据状态判断是否重试，现在 RM 不把状态发送给 TC，那这个状态是从哪里来?\n A：1）是的。 3）这个请求是从 TC 向 RM 端发起的。RM 只是返回一个状态而已。\n 我在实践中的问题就是在二阶段执行出现异常会不断地重试，如之前跟你聊过的补偿触发后补偿服务执行异常会不断重试。上述 TC 发起的全局回滚如果回滚过程中出现异常是不是也会不断地重试？不断地重试感觉比较占用资源？是否有应对策略让他能够只是有限次重试？\n A：重试策略的 PR 已经有了，但是因为 PR 依赖关系较多，暂时还没有合并，后续我会精简 PR 代码，单单引入重试策略的功能及其配置的功能。到时候会能够配置重试策略。目前，基本上是1秒钟就会发起一次重试。\n 现在没有重试策略的情况下，是否有其他的应对方法？\n A：将重试时间间隔配置稍微大一些，默认1秒。\n本周推荐阅读 云原生网络代理 MOSN 的进化之路 基于 MOSN 和 Istio Service Mesh 的服务治理实践 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 云原生网络代理 MOSN 平滑升级原理解析 | 开源 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.18.0 版本，主要变更如下：\n 新增 MOSN 配置文件扩展机制； 新增 MOSN 配置工具，提升用户配置体验； 优化 HTTP 协议处理对内存的占用； TLS 模块优化，增加了客户端降级配置逻辑、降低了 TLS 内存占用； 支持大于 4M 的 XDS 消息； 部分 API 接口进行了重构； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.18.0\n2、发布 Seata v1.4.0 版本，主要变更如下：\n 支持 yml 配置文件； 支持 Oracle nclob 类型； 支持客户端最少的活动负载均衡； 支持客户端一致性哈希的负载均衡； 支持 Spring Boot 使用自定义配置中心和注册中心； 支持 Apollo 密钥 key 配置； 修复禁止执行更新主键值的 SQL； 重构 Redis 存储模式下 session 的存储结构； 详细发布报告： https://github.com/seata/seata/releases/tag/v1.4.0\n","date":1604646000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201106/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dc199415476133ea6f6ee6adf2bf91fa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201106/","publishdate":"2020-11-06T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201106/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、Seata 发布新版本、MOSN 相关阅读整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201106/","wordcount":2032},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@王钢 提问： \u0026amp;gt; https://github.com/sofastack-guides/kc-sofastack-dynamic-demo/issues/11 基于 SOFAArk 和 SOFADashboard 实现动态模块管控时遇到宿主应用能够下载biz安装成功，但是不能在zookeeper下生成对应的/apps/biz节点，导致管理端不能更新状态，不知道应该怎么排查解决。使用的 ZK 版本是 3.4.10。\nA：可以 debug 下写 /apps/biz 的逻辑，这里是不是宿主客户端没有连接上来，具体可以看一下：https://github.com/sofastack/sofa-dashboard-client SOFADashboard 之前只做了一个简单的模型，后面陆续其他同学也在上面做了一些开发，如果有兴趣可以一起参与共建哈。\nSOFADashboard：https://github.com/sofastack/sofa-dashboard\n2、@钟文豪 提问： \u0026amp;gt; SOFAJRaft 是如何计算 commitIndex 的呢？\nA：可以看看这个文档：https://www.sofastack.tech/projects/sofa-jraft/raft-introduction/\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@张潇 提问： \u0026amp;gt; 各位好 问个概念的问题。我三个服务 A,B,C，在 A 服务方法加了 @GlobalTransactional，调用 B ，C。启动三个服务的时候看 Seata 日志 ,A,B,C 服务每一个都是 RM 也是 TM。是这样的吗？不是 A 服务才是 TM 吗？\nA：在你这个事务当中，A 是对应着 TM，B、C 对应着 RM。 但是在注册的时候，他们都同时向 seata-server 注册了 TM 和 RM，意味着他们可以作为 TM，也可以作为 RM。 比如你有一个全局事务从 B 发起的，那这个时候他就是 TM。如果你认为你的业务场景中 B、C 这两个服务不会作为 TM 存在，你也可以把 TM 相关的配置删了，然后他就不会去注册 TM 了。可以从定义上去看 TM 和 RM，会发起全局事务的就是 TM，对应着数据库资源的就是 RM。一个服务可能只是 TM，也可能只是 RM，也可能都是。\nSeata：https://github.com/seata/seata\n本周推荐阅读 网商银行是如何建设金融级云原生分布式架构的？ 开源项目是如何让这个世界更安全的？ SOFA 项目进展 本周发布详情如下：\n开源 MOSN Golang 系统诊断工具 holmes beta 版：\n 支持基于 goroutine 波动的自动 goroutine profile dump； 支持基于 RSS 统计的 heap profile dump； 支持基于 CPU 使用率的自动 cpu profile dump； 详细参考： https://github.com/mosn/holmes/blob/master/readme.md\nSOFA 直播预告 传统 CDN 节点内组件间通信通过 IP 分组渲染的方式实现，当更多参差不齐的异构节点资源出现的时候则不再能很好地满足我们的需求。\n本期主要分享阿里云将传统的 CDN 节点改造成微服务架构的落地过程，主要使用了蚂蚁 SOFAStack–Service Mesh 的数据面 MOSN，主要分为两个阶段，第一个阶段是由传统 CDN 节点到数据面先行的微服务架构，通过数据面 MOSN+coredns 实现服务发现；第二个阶段是由数据面先行到数据面+控制面的标准 Service Mesh 架构。根据我们的落地和改造经验，介绍基于 MOSN+coredns/Istio 的 Service Mesh 架构改造的实际案例。上期分享了《Service Mesh 在 CDN 边缘场景的落地实践》，大家也可以温故一下～ 视频回顾地址：https://tech.antfin.com/community/live/1289\n分享主题：《Service Mesh Webinar#4:阿里云 CDN 节点微服务架构演进之路》\n分享嘉宾：邓茜（花名沐沂），阿里云高级开发工程师\n听众收获：\n 了解边缘场景下，使用 Service Mesh 架构的好处； 了解如何利用 MOSN + coredns 实现简单的服务发现； 了解如何利用 MOSN+ Istio 配置 http/tcp/udp 的转发规则以及如何动态配置持久化； 线上直播时间：2020 年 11 月 4 日（周三）20:00-21:00\n欢迎报名：点击“这里”，即可报名。\n","date":1604041200,"description":"【10/26-10/30】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201030/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a67a4e194b658ba2f0427011c0b56dba","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201030/","publishdate":"2020-10-30T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201030/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 项目更新及直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201030/","wordcount":1772},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@廖虹剑 提问：\n 我们想扩展一下 Dubbo 的 thrift 协议，遇到一个问题，consumer -\u0026amp;gt; mosn-client -\u0026amp;gt; provider，现在请求可以正常 decode -\u0026amp;gt; encode 到达 provider，并且 provider 可以正常调用，在返回的时候，数据包已经发回 MOSN，并且成功 decode，但是会阻塞在 read 处直到超时，没办法 write 回 consumer。 请问有什么排查思路吗？MOSN 里面这个网络模型看得有点晕。\n A：先 read 再 decode 的呀，你说的阻塞在 read 是阻塞在哪？\n read 方法已经正常调用，并且 decode了，但是没有触发写事件，consumer端 会一直在等待。 然后又会到这里卡住直到超时 A：数据 read 了没有新数据，这里就是会超时啊。你要看 decode 之后做了什么。\n 我打断点看到的 remote ip 和端口是 provider 端的。或者我换一个问法，MOSN 在获取到 upstream 的响应数据并且 decode 之后，是如何怎么触发 encodeResponse 并写回 writebuffer 的。我调试发现它 read 完数据之后无法进入到 endStream 方法。 也没看到什么异常日志。 我对 go 还不是特别了解，如果有什么问题还请多指正，辛苦了。\n A：你从 Decode 的逻辑往下跟一下就可以了，Dubbo 目前是 xprotocol 协议的实现 Decode 以后会经过 proxy 的流程最后再 encode，然后 write。read 是异步的，这个有点简单的介绍： https://mosn.io/blog/code/mosn-eventloop/\n 找到问题了，是 encode 的时候 replace requestId 的时候出了点问题，导致找不到对应的 stream，感谢~\n MOSN：https://github.com/mosn/mosn\n2、@Bernie G 提问：\n 我这边项目是 Spring Boot，没有用 Dubbo， 这种情况可以用 Seata 做 Saga 事务吗？\n A：你的服务调用是通过 feign，resttemplate？Saga 跟 RPC 框架不是强绑定的，你的远程服务可用在被调用方作为类似 reference bean 的形式调用就可以。\n 我们这边主要用的是 RestfulApi 还有 gRPC 来作为微服务之间的调用， Seata 能支持吗？ 如果能给个代码 Sample 最好。\n A：Test 中有 gRPC 的实例，看下是否满足需求。 https://github.com/seata/seata/tree/develop/integration/grpc\nSeata：https://github.com/seata/seata\n本周推荐阅读 开源项目是如何让这个世界更安全的？ Hey，邀请你加入我们一起玩耍 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.4.5 版本，主要变更如下：\n 支持 triple 线程监控； 升级 sofa-ark 版本至 1.1.5； 升级 junit 版本至 4.13.1； 修复 jvm filter npe 问题； 修复http server 线程池配置问题； 详细发布报告： https://github.com/sofastack/sofa-boot/releases/tag/v3.4.5\n2、发布 SOFAArk v1.1.5 版本，主要变更如下：\n 修复 web 模块并发安装问题； 修复支持 web 环境测试 webContext 默认为 null 导致的 NPE 问题； 详细发布报告： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.5\nSOFA 直播预告 在边缘计算和 5G 商业化风起云涌的当下，阿里云 CDN 开展了节点全面云原生化的改造，在此背景下，我们尝试利用 CDN 资源池为底座，在大规模复杂边缘场景下建设 Service Mesh 的基础能力，打造边缘 PaaS 平台。落地实践过程中我们使用了蚂蚁 SOFAStack–Service Mesh 体系中的 MOSN 作为数据面，Istio 作为控制面。本次分享将从 Service Mesh 技术以及 CDN 边缘场景介绍入手，重点分析 Istio 和 MOSN 结合的落地实战过程。\n分享主题：《Service Mesh Webinar#3：Service Mesh 在 CDN 边缘场景的落地实践》\n分享嘉宾：肖源（花名萧源），阿里云技术专家\n听众收获：\n 了解 Service Mesh 技术； 了解 Service Mesh 在阿里云 CDN 边缘场景的落地实践； 给到想要落地 Service Mesh 的同学一些案例与建议； 线上直播时间：2020 年 10 月 28 日（周三）20:00-21:00\n欢迎报名：点击“这里”，即可报名。\n","date":1603436400,"description":"【10/19-10/23】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201023/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cf0c4a06a60155202353fe19c3185072","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201023/","publishdate":"2020-10-23T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201023/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAArk、SOFABoot 发版、10月28日线上直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201023/","wordcount":1640},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谢子华 提问：\n SOFARPC 客户端A调用服务端 B，B在方法中想异步调用C（不同步等结果），在callback里面才响应结果返回给A。这种有 Demo 吗？\n A：链路异步吗？ 可直接看测试用例 https://github.com/sofastack/sofa-rpc/blob/master/test/test-integration/src/test/java/com/alipay/sofa/rpc/test/async/AsyncChainTest.java\n 谢谢，看了下用例。我理解是 服务端接口执行时在 RpcInvokeContext 设置了 SendableResponseCallback 类型的 callback。SOFA 就会忽略接口的返回值。然后在 callback 中主动调用 sendAppResponse 返回结果。对吗？\n A：对的。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@明丽 提问：\n 有没有存在经常锁表的童鞋？lock_table 里存在锁表数据和 undo_log 里面有历史几天的数据没有被删除掉？\n A：locktable 如果没删除，说明可能遇到脏数据导致分支事务无法回滚，此时就会有锁无法释放，这时候要根据 locktable 的信息去找对应的分支事务是那个应用，去看下日志提示，如果是脏数据会说镜像校验不通过\n 这里的脏数据具体是指什么样的数据？\n A：全局事务是回滚时，需要回滚的数据被改动。\n 通常报错的就是并发情况下扣减库存，操作同一条 update 库存数量语句。\n A：比如 a=1，update 后时 a=2。此时其他的分支事务异常，导致全局事务决议时回滚，这个时候 a 被改为了3，这个 a 的数据脏了，隔离性没被保证。此时回滚的时候会校验 a 还是不是当前事务修改的值，如果不是，说明这个数据脏了，已经不正确了，不能盲目的直接回滚成1，说明隔离性没保证，有数据被 Seata 全局事务外的地方修改了，如果想保证隔离性，就需要保证任何一个写场景，都被全局事务注解覆盖。\n 我们这边的更新场景都有加全局事务的注解，好像没有起作用，还有别的不起作用的情况吗？\n A：那就检查是否都覆盖了，比如定时任务，或者会不会有认为的去数据库层面直接修改。\n 另外一个问题，我在订单服务下单的时候发起扣库存请求，这个时候只需要在订单服务的方法加上全局注解就可以了，对吗？不需要在库存服务被调用的方法加注解？\n A：只要保证 xid 传递跟数据源代理即可，但是如果有订单服务之外，没有被全局事务注解覆盖的地方操作了库存，一样会脏。这个文章我借鉴了清铭、屹远、煊意的博客，总结了一下 XA 跟 AT 的关系，也谈到了隔离性方面的问题，希望你看过后可以理解 AT 的隔离性是如何保证的。 https://blog.csdn.net/qq_35721287/article/details/108982806\nSeata：https://github.com/seata/seata\n剖析 SOFAJRaft 实现原理合集 SOFAJRaft 实现原理 - 生产级 Raft 算法库存储模块剖析原理 SOFAJRaft 实现原理 - SOFAJRaft-RheaKV 是如何使用 Raft 的 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析 | SOFAJRaft 实现原理 SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.5.Alpha1 版本，主要变更如下：\n 升级 \u0026amp;lsquo;rocksdb\u0026amp;rsquo; 到 5.18.4 以支持 AArch64； 优化：心跳响应不经过 pipeline 直接发送，避免 pipeline 影响心跳响应的及时性； 修复使用 grpc 时，在一定情况下无法自动重连的问题； 修复使用 grpc 时，在 error response 处理的错误； 致谢（排名不分先后）：@cmonkey @odidev 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.5.Alpha1\nSOFA 团队欢迎你加入 蚂蚁集团招聘技术运营专家啦～欢迎加入我们一起为可信技术带来更多的想象。\n岗位名称：可信原生技术运营专家\n岗位描述：\n 挖掘技术内容和业务价值，并形成体系，构建传播矩阵，形成并提高产品和技术的行业美誉度； 完整策划并执行线上、线下的技术活动、大赛，构建围绕可信原生技术的开发者活跃群体，并有更多创造性的技术玩法，使技术可感知； 维护重点 KOL，并吸纳行业专业意见，加大行业贡献，并深化行业影响力。 岗位要求：\n 具备用户细分、市场定位、产品规划、产品包装的能力中的一项或多项； 具备良好的创新思维、有技术前瞻性； 良好的沟通协作能力，及横向驱动能力； 有线上市场推广经验，或线下活动策划经验者优先考虑； 对于云计算领域有较深入的了解，有相关工作背景者优先考虑。 欢迎简历投递至：khotyn.huangt@antgroup.com\n","date":1602831600,"description":"【10/12-10/16】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201016/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a7a2f16f7c62d777b8aff0f90a85ba7b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201016/","publishdate":"2020-10-16T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201016/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布、SOFAJRaft 源码解析文章合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201016/","wordcount":1951},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@叶翔宇 提问： \u0026amp;gt; 想请教一个问题，使用 MOSN 的过程中，我们想通过 request 的 header 中带的 version 信息来实现灰度的机制。比如：目标 service 有 3 个 host，其中一台版本1.0，其他两个版本2.0。\nA：你这个加一个 route 的判断就可以路由到不同的 cluster 了。\n 我们的是同一个 cluster 里面的不同 hosts\u0026amp;hellip;\n A：你就把不同版本的 hosts 归为不同的 cluster 就可以啦。\n2、@李样兵 提问： \u0026amp;gt; 我们现在生产环境中没有使用 K8s, 只使用 MOSN+自定义配置和注册中心，可行吗？\nA：你们是 Dubbo 么？\n 对，dubbo+http， 生产环境是 docker 还没有 K8s。\n A：你可以用这个方案，MOSN 直接连接注册中心。 https://github.com/mosn/mosn/issues/1087 MOSN：https://github.com/mosn/mosn\n线上直播 SOFAChannel 合集 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 蚂蚁金服分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 ","date":1602226800,"description":"【10/05-10/09】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201009/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a83b0d192a605f994a1379ab41578403","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201009/","publishdate":"2020-10-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201009/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN QA 整理、SOFAChannel 线上直播合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201009/","wordcount":938},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@周爽 提问： \u0026amp;gt; 我现在基于springcloud 集成 nacos,sentinel,zipkin,jpa,shardingjdbc，昨天说的做了防止重复代理，如果我是多数据源呢？后续1.3.1是配置也需要开启，代码也需要写代理吗？\nA：多数据源就关掉自动代理，自己手动\n 就在我多数据源里面加上右边的 DataSourceProxy 就可以了吗？ @Primary 这个只需DataSource1Config加上，DataSource2Config是否需要加呢？\n A：代理这个 reresult；\n AT 和 XA 1.3版本可以理解为代码“使用”上就一个 new poxy 不同吗？\n A：一个是 new DataSourceProxy，一个是 new DataSourceXAProxy\n Seata “实现”一个是二阶，一个是基于 XA 事务规范？\n A：都是二阶段，一个模式是自研，一个是基于数据库底层实现。 Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 SOFAEnclave：蚂蚁金服新一代可信编程环境，让机密计算为金融业务保驾护航102年 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.7.6 版本，主要变更如下：\n 支持精细化配置 Jackson 序列化； Triple 协议支持用户自定义元数据； Triple 协议支持 SPI 编程模式； 升级 hibernate-validator 版本到 5.3.6.Final； TripleServer 启动时发送启动事件； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.6\n2、发布 MOSN v0.17.0 版本，主要变更如下：\n 重构 XProtocol 连接池，支持 pingpong 模式、多路复用模式与连接绑定模式； 优化 XProtocol 多路复用模式，支持单机 Host 连接数可配置； Listener 配置新增对 UDS 的支持； 新增在 Dubbo 协议下通过 xDS HTTP 配置进行转换的过滤器； 部分框架实现优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.17.0\n","date":1601622000,"description":"【09/28-10/02】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201002/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bc9b38b8088d82138a46a8318e944840","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201002/","publishdate":"2020-10-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201002/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":" SOFA Weekly | MOSN、SOFARPC 发版、Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201002/","wordcount":1018},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@刘源远 提问：\n 请教一下大家，这个本地事务提交，是指这个本地事务在分布式事务中提交，还是指在自己的事务中提交啊？ 如果是指分布式事务中提交，那不就应该在分支事务提交之前，才存在回滚嘛？如果是指自己的事务中提交，那我断点下来，本地业务事务已经提交了，为什么还产生这条记录呢？ A：只要二阶段回滚的时候，发现你的 undolog 没插入就会做一条防御性的 undolog，你可以认为你没产生资源悬挂，但是二阶段确实没读到你的 undolog。所以才会插入一个防御性，你完全不需要理会 status=1 的记录。\n 奇怪的是，我断点下来，在一阶段会产生 undolog 记录（两条），然后抛异常回滚之后，一阶段的 undolog 记录（两条）被删除了，产生一条 status=1 的记录。会不会是因为某些原因，一阶段会产生 undolog 记录被删除了，所有二阶段没有查询到？\n A： 多数据源？\n 对的，多数据源。\n A：确认下是不是重复代理了？把自动代理关了，一般多数据源都是已经手动代理了，因为二阶段的时候，下发找 datasource，找到的不是你当时操作数据库的 datasource，导致没发现 undolog，就插了一条 status=1。\n 我现在手动配置代理，有两个数据源，一个用了 DataSourceProxy，一个没有。现在处于分布式事务中是使用了 DataSourceProxy 的数据源，但是回滚后还是会产生一条 status=1 的 undolog。\n A： 自动代理关了吗，看下怎么代理的。\n 你指的自动代理是 springboot-start 吗？还是其他的？\n A：Seata 的数据源自动代理，设置 Seata: enable-auto-data-source-proxy: false\n OK，好啦\n Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服通信框架 SOFABolt 解析 | 超时控制机制及心跳机制 蚂蚁金服通信框架 SOFABolt 解析 | 连接管理剖析 蚂蚁金服通信框架 SOFABolt 解析 | 协议框架解析 蚂蚁金服通信框架 SOFABolt 解析 | 序列化机制(Serializer) 蚂蚁金服通信框架 SOFABolt 解析 | 编解码机制 社区活动预告 CSDI summit 中国软件研发管理行业技术峰会（Software development management industry technology summit）由国内专业咨询机构百林哲匠心打造的软件行业技术领域顶级盛会，将于2020年9月24-27日举办。 话题涵盖：组织数字化转型、研发效能、产品创新、用户增长、云原生、架构创新、微服务、AI 大数据、数据安全和云安全、AIOT 实践等方面。蚂蚁集团也应邀参与本次大会分享。\n分享主题：金融级云原生 PaaS 实践之路\n分享嘉宾：成旻 蚂蚁金服高级技术专家\n分享时间：2020-09-26 16:40 - 18:00\n分享亮点：\n 蚂蚁 PaaS 产品的缘起； 经典应用服务的能力和特色； 容器应用服务的进阶能力； 面向未来\u0026amp;ndash;混合云发展发向； 活动形式：线上峰会\n活动详情：点击“这里”，了解日程详情\n","date":1601017200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200925/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c7562a535d9b34b23d0b559dd756ef6a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200925/","publishdate":"2020-09-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200925/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt 源码解析合辑、CSDI summit 活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200925/","wordcount":1385},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 社区大事件 MOSN 支持 Istio 啦～详见链接：\n 英文版：《Using MOSN with Istio: an alternative data plane》 中文版：《在 Istio 中使用 MOSN：另一个数据平面》 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@梓郁 提问：\n 我最近刚刚接触分布式链路监控，看了 SOFATracer 的 slf4j 的 demo。现在有一个问题。就是我想在日志里面打印出 span 的 parentid，但是我不想在我自己的代码里面显性地用 MDC 添加，有什么其他方法吗？（我现在是打算在 MDCSpanExtension 里面用 mdc.put 添加;再重新打包添加依赖这样可行吗？）\n A：自己扩展下这个接口 SpanExtension。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@石评 提问：\n 我有个关于 Seata 的疑问：A -\u0026amp;gt; B-\u0026amp;gt;C 的时候，不管 B 有没有本地事务，如果 C 失败了 B 的都会回滚，那么 B 的本地事务的作用是什么呢？\n A：分布式事务认为由若干个分支事务（本地事务）构成的，如果加了 autocommit=false，那么 B 服务的几条 sql构成一个本地事务，如果不加那么每条 DML 语句都是一个本地事务。本地事务越少那么与 TC 的交互次数越少。\n3、@徐成阳 提问：\n Seata 的 TCC 强一致的嘛？\n A：AT、XA、TCC 应该都属于强一致性。 SAGA 无法保证事务隔离性，在部分情况下可能会存在无法回滚，而选择向前继续重试来保证事务最终一致性。 四种模式都是属于最终一致性。SAGA 性能更高，因为没有二阶段提交，而且分支数据都是保存在本地的。\nSeata：https://github.com/seata/seata\n本周推荐阅读 来了！2020 云栖大会 蚂蚁金融科技产品能力再升级 企业数字化转型指南，《SOFAStack 解决方案白皮书》正式发布 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.4.bugfix_2 版本，主要变更如下：\n 修复使用 grpc 时，在一定情况下无法自动重连的问题； 详细发布报告： https://github.com/sofastack/sofa-jraft/releases/tag/1.3.4.bugfix_2\n社区活动预告 这里有一个您的专属日程提醒，请查收：\n日程主题：OceanBaseDev Meetup#1 上海站「深入分布式数据库：事务·高可用·云原生」\n出品人： - 杨传辉（花名：日照）蚂蚁集团研究员、OceanBase 总架构师 - 韩富晟（花名：颜然）蚂蚁集团资深技术专家、OceanBase 事务研发负责人\n日程时间：2020-09-20 本周日 13:00-17:30\n日程地点：上海市杨浦区政学路77号 InnoSpace+\n日程详情：点击“这里”，了解日程详情\n","date":1600412400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200918/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d3e2feb22ec7504b5fc6648eeba4769f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200918/","publishdate":"2020-09-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200918/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFAWeekly｜MOSN 支持 Istio、SOFAJRaft 发布、本周日您有一条待办日程","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200918/","wordcount":1251},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈健斌 提问：\n Seata 使用注册中心只存储个地址列表，引入 SOFAJRaft 后感觉注册中心没必要了？用户用起来就跟 zk 集群、kafka 集群一样，ip:port,ip:port 这样。\n A：这个 看需求了，都可以啊。我感觉还是可以继续使用注册中心，然后 SOFAJRaft 的地址从注册中心回去，动态构建 SOFAJRaft 集群。\n 可以噢，这样 client 端不需要设置 server 的集群了，通过注册中心来就可以了，自动组装了。 我目前是这么设计的，有空的话还望指点一二。\n A：Sesta server 经常会经常替换吗？\n 这个得看用户了，要不咱假设2个情况吧，如果不经常替换，此方案适用不。经常替换下要做哪些改进？\n A：经常替换的话要考虑 raft 集群的替换，要处理 addpeer removepeer 这是要走 raft 协议的（用 cliservice 这个接口），就是换一台 server 不是换个地址就完事了，需要调用 addpeer把新机器加入 raftgroup 然后 SOFAJRaft 会自动同步数据，移除一个节点需要调用 removepeer。\n 也就是，如果我现在扩容，比如我原来的节点是127.0.0.1:7091，127.0.0.1:7092，127.0.0.1:7093 然后我现在要加一个127.0.0.1:7094，我能不能直接跟 zk 那边扩容一样，我新加入进来的节点设置的地址是127.0.0.1:7091，127.0.0.1:7092，127.0.0.1:7093，127.0.0.1:7094，先让他加入进去，然后手动挨个重启其余3台。目前这样的扩缩容，我的设计方案能满足吗？\n A：不需要重启，需要 addpeer，参考第11小结，最有效的排查 SOFAJRaft 问题工具 https://www.sofastack.tech/projects/sofa-jraft/jraft-user-guide/ SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@koutatu 提问： \u0026amp;gt; 想咨询下，Seata Saga 模式下，TC 的作用是什么呢，回滚操作还是 TC 触发吗？感觉 Saga 状态机模式下，状态机可以控制回滚，TC 是不是只是记录下状态，不做什么实际处理了呢？\nA：你说的应该是对的，Saga 脱离 TC 理论上都是可行的。\n 目前的回滚操作是不是也是状态机自身控制的，也就是链路里面的每一步都需要有一个状态机。TC 只负责接收消息，而不是像 TCC 或者拦截器式的 Saga 一样，回滚由 TC 统一控制。\n A：TC 在 Saga 模式的作用就是记录全局事务分支事务状态。 Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析 SOFABoot 扩展点初体验 | SOFALab 实践系列 剖析 | 详谈 SOFABoot 模块化原理 实操 | 基于 SOFABoot 进行模块化开发 开源 | SOFABoot 类隔离原理剖析 SOFA 项目进展 1、发布 SOFAArk v1.1.4 版本，主要变更如下：\n 支持动态替换 biz name； TestClassLoader 导出 mockito 包以支持 mockito 测试框架； 修复 AfterBizStopEvent 事件处理时机问题导致的 NPE； 修复 web 模块卸载问题； 支持 ark telnet 使用安全模式启动； 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.1.4\n2、发布 SOFABoot v3.4.4 版本，主要变更如下：\n 提供 jvm 调用拦截扩展； 修复若干测试用例； 修复在 ark 环境使用 sofa:reference 引用 jvm 服务出现 NPE bug； 修复健康检查通过但 ExtensionComponent activate 失败 bug； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.4\n社区活动预告 近几年，越来越多的传统企业面临互联网化，IOT、区块链、AI、5G 等技术也在高速发展，任何一个技术的推广到成熟都会带来数据量的指数级增长，都会对存储带来巨大的冲击。相信随着这些技术的突破，未来越来越多的核心场景会走向分布式的领域。国内很多团队也在进行分布式数据库的探索与实践。\nOceanBaseDev Meetup 是以城市站展开的数据库技术交流活动，旨在为关注分布式数据库技术的同学提供技术交流、分享、探讨的空间与平台。\nOceanBaseDev Meetup#1 上海站，将邀请蚂蚁集团 OceanBase 团队的三位核心研发专家以及网易杭研资深研发工程师，针对分布式数据库的分布式事务以及落地实践展开分享。现场更有外滩大会门票等你来拿～\n活动主题：**OceanBaseDev Meetup#1 上海站「深入分布式数据库：事务·高可用·云原生」\n出品人： - 杨传辉（花名：日照）蚂蚁集团研究员、OceanBase 总架构师 - 韩富晟（花名：颜然）蚂蚁集团资深技术专家、OceanBase 事务研发负责人\n活动时间：2020-09-20 13:00-17:30\n活动地点：上海市杨浦区政学路77号 InnoSpace+\n活动报名：点击“[阅读原文**](https://www.huodongxing.com/event/5562442480600)”，了解活动详细议题并锁定席位\n","date":1599807600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200911/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"25ab3501e7db2cd836d05f86bb6c17ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200911/","publishdate":"2020-09-11T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200911/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot、SOFAArk 发布、9/20 上海线下活动推荐","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200911/","wordcount":2145},{"author":"王发康（毅松）","categories":"MOSN","content":" 本文根据 2020 年 8 月 15 号在深圳 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会云原生专场现场实录整理。\n分享嘉宾：王发康（毅松）蚂蚁集团可信原生技术部 技术专家，专注于高性能网络服务器研发，是 MOSN、Tengine 开源项目核心成员，目前关注云原生 Service Mesh、Nginx、Istio 等相关领域，喜欢开源，乐于分享。\nGItHub：https://github.com/wangfakang\n以下是分享全文。\n前言 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，本文就其在演进过程中遇到的问题及思考进行展开。对接 UDPA，实现 Istio 融合，并增强 MOSN 服务治理及流量控制能力对接云原生周边组件，实现 MOSN 开箱即用。\n大家下午好，我叫王发康，来自蚂蚁集团可信云原生应用网络团队，之前几年一直从事南北向网关（接入层）的开发和维护，说来也是和流量有着别样的渊缘，现在主要做东西向的流量网关（Service Mesh）开发和设计。今天演讲的主题是《云原生网络代理 MOSN 的进化之路》，主要从如下几点介绍：\n MOSN 介绍； 云原生演进； 总结与展望； MOSN 介绍 接下来，就 MOSN 的诞生背景、发展历程、MOSN 具备的功能和架构以及内部的落地情况这几个维度介绍下 MOSN。\nMOSN 诞生背景 随着云计算、物联网等技术迅速发展，也促使着微服务的架构一直在进化，其演进过程通常经历了如下四个阶段：\n单体：一般起始阶段业务很简单，流量也不大，所有的处理都可以在一个服务中完成；\n分布式：随着业务操作的多样化以及流量的日益增长，不得不按照服务维度进行拆分，这样相同的服务资源消耗可对等，方便容量评估及管理；\n微服务：随着服务的拆分粒度越来越细，其服务的数量一直在增加，由此出现各种微服务治理的需求（限流、鉴权、路由等），于是便出现各种治理组件并以 SDK 插件的方式集成到不同应用中；\nService Mesh：伴随着服务治理的 SDK 种类、版本、重复等一系列问题，于是把 SDK 的能力剥离到 Sidecar，和业务进行解耦，从而实现业务和中间件能力的并行迭代；\n业务痛点\n 多语言，中间件组件开发适配成本高； SDK 升级困难； 服务治理能力弱； 技术不通用，无法复用； 业界解决方案\n Envoy (C++)； Linkerd (活跃度较低)； NginxMesh (活跃度低)； 综合以上业务痛点以及业界现有方案的评估，于是 MOSN 就诞生了。MOSN（Modular Open Smart Network）是用 GoLang 编写的网络代理服务器。作为 Sidecar、API Gateway、云原生 Ingress、Layer 4 或 Layer 7 负载均衡器等场景构建的。随着时间的推移，我们添加了额外的功能，例如多协议框架，多进程插件机制，DSL 以及对 xDS API 等的支持，支持 xDS 意味着我们现在可以将 MOSN 用作 Istio 的数据平面。\nMOSN 发展历程 从 2017 年底开始 Service Mesh 技术调研，2018 年 3 月份 MOSN 雏形问世并进行了小规模试点，秉着让更多的用户能够享受这一技术红利的思路，于是 2018 年 6 月正式开源 MOSN。2019 年 618 进行了规模化落地，并在同年的双 11 大促达到了核心支付链路的全覆盖。在通过大规模验证后，MOSN 社区开始在其标准化以及生态方面进行发展和演进。\nMOSN 功能视图 MOSN 作为一个通用的数据转发平面，提供多协议卸载、动态服务发现、服务治理（Trace、限流、重试、重写、超时控制等）、丰富的负载均衡算法等功能，可用于 Sidecar、API Gateway、云原生 Ingress、Layer 4 或 Layer 7 负载均衡器等场景。\nMOSN 架构解析 MOSN 采用的是分层的体系结构，其系统分为 NET/IO、Protocol、Stream、Proxy 四层：\n NET/IO 作为网络层，监测连接和数据包的到来，同时作为 listener filter 和 network filter 的挂载点; Protocol 作为多协议引擎层，对数据包进行检测，并使用对应协议做 decode/encode 处理; Stream 对 decode 的数据包做二次封装为 stream，作为 stream filter 的挂载点; Proxy 作为 MOSN 的转发框架，对封装的 stream 做 proxy 处理; 其中，每一层通过工厂设计模式向外暴露其接口，方便用户灵活地注册自身的需求。通过协程池的方式使得用户以同步的编码风格实现异步功能特性。通过区分协程类型，MOSN 实现了 read 和 proxy worker 两大类协程，read 协程主要是处理网络的读取及协议解析，proxy worker 协程用来完成读取后数据的加工、路由、转发等。其架构如下图所示：\nMOSN 为了降低 Runtime GC 带来的卡顿，自身做了内存池的封装方便多种对象高效地复用，另外为了提升服务网格之间的建连性能还设计了多种协议的连接池从而方便地实现连接复用及管理。\n在连接管理方面，MOSN 设计了多协议连接池， 当 Proxy 模块在 Downstream 收到 Request 的时候，在经过路由、负载均衡等模块处理获取到 Upstream Host 以及对应的转发协议时，通过 Cluster Manager 获取对应协议的连接池 ，如果连接池不存在则创建并加入缓存中，之后在长连接上创建 Stream，并发送数据，如下图所示：\n在内存管理方面，MOSN 在 sync.Pool 之上封装了一层资源对的注册管理模块，可以方便的扩展各种类型的对象进行复用和管理。其中 bpool 是用来存储各类对象的构建方法，vpool 用来存放 bpool 中各个实例对象具体的值。运行时通过 bpool 里保存的构建方法来创建对应的对象通过 index 关联记录到 vpool 中，使用完后通过 sync.Pool 进行空闲对象的管理达到复用，如下图所示：\nMOSN 落地情况 服务在做了 Mesh 化后，有人可能会质疑，增加一跳 Sidecar 转发是否会导致性能下降，其实不然，在蚂蚁的部分业务场景中，部分业务上了 Mesh 后，其 CPU 消耗还比之前低了，原因是之前的一些通用 SDK 能力都下沉到 Sidecar 中，并统一做了一定的优化。另一个好处是，由于 MOSN 使用 GoLang 开发，天然具备其高开发效率，所以也大大的提升了中间件相关能力的研发速度。\nMOSN 云原生演进 在 MOSN 大规模落地并通过双 11 大考后，MOSN 也开始在实践的道路上进行标准化演进。并通过和 Istio 社区的合作，MOSN 实现了 xDS 的适配，可方便的实现 Istio 作为 MOSN 的控制面进行服务配置的管理。另一方面， …","date":1599022800,"description":"MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，本文就其在演进过程中遇到的问题及思考进行展开。","dir":"blog/cloud-native-network proxy-mosn-evolutionary-path/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"080e78e9d0103daed414ee3a8b5b7996","permalink":"https://sofastack.github.io/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","publishdate":"2020-09-02T13:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","summary":"本文根据 2020 年 8 月 15 号在深圳 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会云原生专场现场实录整理。 分享嘉宾：王发康（毅松）","tags":["MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 的进化之路","type":"blog","url":"/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","wordcount":5065},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@晏伦 提问：\n 请问 Seata 的全局锁粒度是数据库级别还是表级别？全局锁会带来并发的问题吧？如何权衡的呢？\n A：全局锁是行级别的；如果2个事务在同时更新同一行，会出现锁竞争问题，所以 AT 模式的适用场景是并发请求较低，不会产生行锁竞争的业务场景。\nSeata：https://github.com/seata/seata\n本周推荐阅读 少年五年升阿里 P8，他如何从低谷登上“光明顶”？ 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构 Forrester中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求 组件解析部分合辑 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 SOFA 项目进展 发布 sofa-common-tools v1.2.0 版本，主要变更如下：\n 修复多线程日期打印问题； SOFAThreadPool 支持一个 Runnable 在多个 thread 运行； 停止 JDK6 支持； 详细发布报告：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.2.0\n社区活动预告 CSDI summit 中国软件研发管理行业技术峰会（Software development management industry technology summit）是软件行业技术领域顶级盛会，协同国内外知名软件、互联网等企业研发一线技术专家从 AI 和大数据、产业变革、技术创新、生态发展、业务创新、商业模式等方面重点研讨软件研发趋势。蚂蚁集团也受邀参与本次峰会分享“云原生”相关主题。\n分享主题：金融级云原生 PaaS 实践之路\n分享嘉宾：成旻 蚂蚁集团高级技术专家\n分享时间：2020-09-26 16:40-18:00\n听众收获：\n 蚂蚁 PaaS 产品的缘起； 经典应用服务的能力和特色； 容器应用服务的进阶能力； 面向未来\u0026amp;ndash;混合云发展发向； 活动地点： 线上活动\n活动报名： 点击“这里\n","date":1598598000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200828/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"474484cd88c8a1971016217eb9c1438d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200828/","publishdate":"2020-08-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200828/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | sofa-common-tools 发布、组件解析合辑、云原生活动推荐","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200828/","wordcount":1038},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谢小东 提问：\n 请教一个问题，在使用 AT 模式的时候，新增的一条数据，回滚之前我在 db 改了我刚新增的数据，这个时候如果我抛出异常，但是就不发回滚，该怎么处理？\n A：不要在全局事务包裹之外进行对数据的并发操作，如果你这样做，就跳过了 AT 的全局锁，隔离性无法保证，如果你有这方面需求的，可以用 XA 模式，并且使用数据库自身带有排它锁的操作，数据库的自身支持了 XA 模式，就可以帮你保证隔离性。\n 你的意思就是我在这种情况下 XA 模式适合？XA 模式是行锁么？\n A：XA 是数据库自身实现的隔离机制，AT 是统一到 TC 去竞争行锁，而没用到 AT 的地方修改数据库当然就不会去 TC 竞争行锁，隔离性只能保证再全局事务注解下的操作生效。\n2、@彭兴家 提问：\n 请问 Seata 里说的全局锁和本地锁对应 MySQL 的什么锁呀？\n A：全局锁就是从 TC 竞争的锁，本地锁就是参与方自己本地的 MySQL 连接，比如 update 不就有排他锁的作用吗，因为一阶段提交，连接释放了，这个本地数据库的锁就解开了。而全局锁是从 TC 拿的，这个锁保证了你的入口只要是分布式事务注解下，就会去竞争这个全局锁。保证了再分布式事务注解下的全局事务间的隔离性\n 谢谢，明白了。但这样的话，Seata 通过前置镜像回滚。在全局事物执行的过程中，要是其他项目(没在全局事物下的项目)对该条数据进行了修改，那么按照 Seata 的机制，前置镜像对比不同了就不能回滚，需要手动处理？\n A：是的，需要人工介入，因为只有人为分析才能校准数据了。对 Seata 来说他只知道要把数据回滚到发生前，但是数据被干扰了，就无法回滚了。\n 理论上来说这种情况出现的几率很大呀，多个不同项目操作同一条数据。\n A：全局事务，字面意思要理解一下。你让他不全局了，让它不覆盖到，如何保证隔离性？要么涉及到的库对应的应用全局使用 Seata AT，要么就换 XA，修改的数据，用 select for update，这个本地锁在二阶段下发通知前不会释放，保证了隔离性。\n3、@苏龙飞 提问：\n 请问，现在我们的 cloud 项目中用了 Seata，数据库只有一个，然后发现性能不够，所以想换成多主从数据库，并且能和 Seata 兼容，有没有好的方案呀？\n A：主从方案本就应该是允许暂时的不一致，只要你保证读写都需要的时候，一定是主库，并把主库的 datasource 代理掉就好了，保证需要读后马上写的，一定要是主库操作。 Seata：https://github.com/seata/seata\nSOFAChannel 部分合辑 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 [链接]()蚂蚁金服分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 本周推荐阅读 蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO？ 蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？ ","date":1597993200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200821/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"34ac475f8a4ec2435b62a9bf4d520e2a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200821/","publishdate":"2020-08-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200821/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 线上直播合辑整理、Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200821/","wordcount":1515},{"author":"樱桃","categories":"Occlum","content":" \u0026amp;lt; SOFA:Channel/ \u0026amp;gt;，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 本文根据 SOFAChannel#18 直播分享整理，主题：零门槛的机密计算：Occlum LibOS 使用入门和技术揭秘。\n大家好，我是今天的讲师田洪亮（花名：樱桃），蚂蚁集团技术专家，也是 Occlum 开源负责人。今天我和大家分享一下如何使用 Occlum 的轻松开发机密计算应用以及 Occlum 技术架构和特色。\n前言 云计算、大数据、人工智能，我们正处在一个数据爆炸的时代。如何能够在享受和利用海量数据所产生的价值的同时，保证数据的安全和用户的隐私呢？这无异是一个用户、企业和监管部门共同关注的问题。\n近年来兴起的机密计算（Confidential Computing），正是为了解决这个问题而来。利用可信执行环境（Trusted Execution Environments，简称 TEE）技术，机密计算使得数据始终保持加密和强隔离状态，从而确保了用户数据的安全和隐私。机密计算可以解决诸多应用场景中“信任”难题，比如多个不互信组织之间的数据融合与联合分析、区块链上的智能合约的机密性保护、公有云平台对外部或内部攻击的防御、高敏感信息（比如密码学材料、医疗档案等）的安全保护等等。\n但是，机密计算底层依赖的 TEE 技术——比如目前最成熟的云端 TEE 技术 Intel SGX——也带来了额外的功能限制和兼容问题。这使得机密计算的开发者面领一个巨大的阻碍：应用开发难。\n在本文中，我们会首先分析当前 SGX 应用开发者会遇到的各种挑战和痛点，然后介绍蚂蚁集团自研的开源 TEE OS 系统 Occlum 如何大幅降低 SGX 应用开发的门槛，真正做到人人都可以玩转机密计算。\n为什么 SGX 应用开发难？ SGX 应用程序是一种基于划分的模型：在用户态的（不可信）应用程序（上图红色部分）可以嵌入 SGX TEE 保护的区域（上图绿色部分），被称为 Enclave。支持 SGX 的 Intel CPU 保证 Enclave 中的受保护内容是在内存中加密的，并且与外界强隔离。外界的代码如果想进入 Enclave 中执行其中的可信代码必须通过指定的入口点，后者可以实施访问控制和安全检查以保证 Enclave 无法被外界滥用。\n由于 SGX 应用程序是基于这种划分的架构，应用开发者通常需要使用某种 SGX SDK，比如 Intel SGX SDK、Open Enclave SDK、Google Asylo 或 Apache Rust SGX SDK。但无论使用上述哪种 SDK，开发者会遭遇下面的开发困境：\n 必须将目标应用做二分：开发者需要决定哪些组件应该置于 Enclave 内部，哪些置于 Enclave 外部，以及双方如何通信。对于复杂的应用，确定高效、合理且安全的划分方案本身就是一件颇具挑战的工作，更不要说实施划分所需的工程量。 被限定在某个编程语言：无论使用上述哪种 SDK 开发，一个开发者都将被限定在该 SDK 所支持的语言，这通常意味着 C/C++（当使用 Intel SGX SDK、Open Enclave SDK 或 Google Asylo 时），而无法使用 Java、Python、Go 等更加友好的编程语言。 只能获得很有限的功能：处于硬件限制和安全考虑，Enclave 中是无法直接访问 Enclave 外的（不可信）OS 的。由于 Enclave 中缺乏 OS 的支持，各种 SDK 只能提供普通不可信环境下的一个很小的功能子集，这使得很多现有的软件库或工具都无法在 Enclave 中运行。 上述困境使得为 SGX 开发应用成为一件十分痛苦的事，制约了 SGX 和机密计算的普及度和接受度。\n学会 Occlum 的“三板斧” Occlum 是一款蚂蚁集团开源的 TEE OS，可以大幅降低 SGX 应用的开发门槛。那到底多低呢？只需要学会 Occlum的三条命令：new、build和run。本节我们以利用 Occlum 在 SGX 中运行一个 Hello World 程序为例进行说明。\n这里有一个非常简单的 Hello World 程序。\n$ cat hello_world.c #include \u0026amp;lt;stdio.h\u0026amp;gt; int main() { printf(\u0026amp;quot;Hello World!\\n\u0026amp;quot;); return 0; } 首先，我们用 Occlum 提供的 GCC 工具链（occlum-gcc）编译这个程序，并验证它在 Linux 上能正常工作。\n$ occlum-gcc hello_world.c -o hello_world $ ./hello_world Hello World! 然后，我们为这个程序创建一个 Occlum 的实例目录（使用 occlum new 命令）。\n$ occlum new occlum_hello $ cd occlum_hello 该命令会创建一个名为 occlum_hello 的目录，并在该目录中准备一些必要的文件（如 Occlum.json 配置文件）子目录（如 image/）。\n接下来，我们基于刚刚编译好的 hello_world 制作一个 Occlum 的 Enclave 文件和可信镜像（使用 occlum build 命令）。\n$ cp ../hello_world image/bin $ occlum build 最后，我们在 SGX 中运行 hello_world（使用 occlum run 命令）。\n$ occlum run /bin/hello_world Hello World! 更复杂的程序也可以用类似上面的流程通过 Occlum 移植进 SGX 中。用户无需理解 SGX 的二分编程模型，无需或只需少量修改应用代码，还可以自由选择编程语言（比如 Java、Python、Go 等）。使用 Occlum，应用开发者可以将宝贵的精力集中在编写应用上，而非为 SGX 做应用移植。\n用起来像 Docker 的 TEE OS 在了解了 Occlum 的基本用法和体验之后，很自然地会好奇 Occlum 的技术原理：Occlum 的用户接口为什么这样设计？而简单接口背后的技术架构又是怎样的？本节就试图回答这些问题。\nOcclum 的一个设计理念是 Enclave-as-a-Container。在云原生时代，容器至关重要，容器无处不在。容器最常见的实现方式是基于 Linux 的 cgroup 和 namespace（比如 Docker），但也有基于虚拟化的实现（比如 Kata）。我们观察到，TEE 或者 Enclave 也可以作为一种容器的实现手段。因此，为了传达这种理念，同时给用户提供一种熟悉的体验，我们特意将 Occlum 的用户接口设计成与 Docker 和 OCI 标准接近。除了前面提到的 new、build和run 三个命令，Occlum 还提供 start、exec、stop、kill 等命令，其语意与 Docker 同 …","date":1597906800,"description":"本文分享如何使用 Occlum 的轻松开发机密计算应用以及 Occlum 技术架构和特色。","dir":"blog/sofa-channel-18-retrospect/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a1d55e5deb00aa8cde8d14f250569013","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-18-retrospect/","publishdate":"2020-08-20T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-channel-18-retrospect/","summary":"\u0026lt; SOFA:Channel/ \u0026gt;，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。 本文根据 SOFAChannel#18 直","tags":["Occlum","SOFAchannel"],"title":"人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | SOFAChannel#18 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-18-retrospect/","wordcount":2939},{"author":"田晓旭","categories":"Kubernetes","content":" 随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。\n 根据 CNCF 2019 Kubernetes 使用调查报告的显示：目前 84% 的用户已经在生产环境中使用 Kubernetes，生产环境中容器部署规模超过 1000 的比例是 34%，其中超过 5000 的大规模应用比例是 19%。当集群越来越大、越来越复杂，集群可用性就会面临挑战。\n 整体指标：集群是否健康，所有组件是否正常工作，集群中 Pod 创建的失败数量有多少等等； 追踪能力：集群中发生了什么，是否有异常，用户做了什么事情等等； 原因定位：出现异常之后，找到是哪个组件出了问题； 想要解决这些问题，比较好的一个方法就是 SLO，通过定义 SLO 来描述集群的可用性，追踪集群中 Pod 的生命周期，一旦出现失败 Pod，快速定位异常组件。本文采访了蚂蚁集团技术专家范康和姚菁华来分享蚂蚁集团的 SLO 体系是如何建立的。\n大家常会听到 SLA，其实 SLA 是 SLO 衍生出来的协议，SLA 协议会形成具有法律效力的合同，通常是服务供应商和外部客户之间签订的，而 SLO 是用于内部服务之间，定义服务所提供功能的一种期望状态。\n1 SLO 指标定义 如果我们要通过定义来描述集群的可用性，那么具体的描述指标就成为了需要解决的关键问题。在蚂蚁 集团 内部，集群可用性的关键指标包含五个：集群健康度、Pod 创建成功率、残留 Terminating Pod 的数量、服务在线率和故障机数量。\n 集群健康度：通常使用 Healthy，Warning，Fatal 三个值来描述，其中 Warning 和 Fatal 对应告警体系，例如 P2 告警发生，那集群就是 Warning，而 P0 告警发生，那集群就是 Fatal，必须进行处理； Pod 创建成功率：这是一个非常重要的指标，蚂蚁集团一周的 Pod 创建量在百万级别，如果成功率波动会造成大量 Pod 失败，同时 Pod 成功率下跌也是集群异常的最直观反映； 残留 Terminating Pod 的数量：有人可能会好奇为什么使用残留 Terminating Pod 的数量，而不用删除成功率？这是因为当 Pod 数量达到百万级别后，即使删除成功率达到了 99.9%，Terminating Pod 的数量也有数千，残留这么多 Pod 占用应用容量，在生产环境中是不可接受的； 服务在线率：这个指标是通过探针来衡量的，探针失败则意味着集群不可用； 故障机数量：这是一个节点维度的指标，故障机通常是指无法正确交付 Pod 的物理机，集群故障机需要做到“快速发现，快速隔离，及时修复”，否则会对集群容量造成影响； 以上指标的阈值和 SLO 性能目标都是根据业务方的增长来定义的，随着业务的不断增长，这些指标的定义也可能需要跟着做调整。\n以 Pod 创建成功率为例，蚂蚁集团将 Pod 分为了普通 Pod 和 Job 类 Pob，普通 Pod 的 RestartPolicy 为 Never，Job 类 Pod 的 RestartPlicy 为 Never 或 OnFailure，两者都设定有交付时间，普通 Pod 的交付标准是 1min 内 Pod 已经 Ready；Job 类 Pod 的交付标准是 1min 内 Pod 的状态已达 Running、Succeeded 或 Failed。最开始 Pod 创建成功率的定义是成功创建的 Pod 和总 Pod 的比值，但是很快就发现在排查原因时，系统很难分辨，所以又将 Pod 失败原因调整成用户和系统两部分，创建成功率的定义就变成了创建成功的 Pod 和总的 Pod 减去用户失败 Pod 的比值。\n2 蚂蚁集团的 SLO 体系 确定好 SLO 各项关键指标的定义之后，接下来就是构建 SLO 体系。\n据范康介绍，蚂蚁集团 SLO 系统主要包括两个方面，一个方面用于向终端用户 / 运维人员展示当前集群各项指标状，另一方面是各个组件相互协作，分析当前集群状态，获取影响 SLO 的各项因素，为提升集群 pod 交付成功率提供数据支持。\n蚂蚁集团 SLO 体系架构图\n自顶向下而看，蚂蚁集团 SLO 的分层架构包括 SLO、Trace system、Increase of SLO、Target 和 The unhealthy node。\n其中，顶层组件主要面向各种指标数据，如集群健康状态、pod 创建、删除、升级成功率、残留 pods 数量、不健康节点数量等指标。其中 Display Board 是指监控大盘，可能不会实时查看，为避免错过处理紧急事件的最佳时机，同时构建了 Alert 告警子系统，支持配置多种告警方式；Analysis System 通过分析指标历史数据以及采集到的节点 metrics 和 master 组件指标，给出更详细的集群运营报告；Weekly Report 子系统给出当前集群本周 pod 创建 / 删除 / 升级的数据统计，以及失败案例原因汇总；Terminating Pods Number 给出一段时间内集群内新增的无法通过 Kubernetes 机制删除的 Pods 列表和 Pods 残留原因；Unhealthy Nodes 则给出一个周期内集群所有节点的总可用时间占比，每个节点的可用时间、运维记录、以及不能自动恢复，需要人工介入恢复的节点列表。\n为了支撑上述这些功能，蚂蚁集团还开发了 Trace System，用来分析展示单个 pod 创建 / 删除 / 升级失败的具体原因。其中包含日志和事件采集、数据分析、pod 生命周期展示三个模块。日志和事件采集模块采集各 master 组件以及节点组件的运行日志和 pod、node 事件，分别以 pod/node 为索引存储日志和事件；数据分析模块分析还原出 pod 生命周期中各阶段用时，判断 pod 失败原因，节点不可用原因。最后，由 Report 模块向终端用户暴露接口和 UI，向终端用户展示 pod 生命周期以及出错原因。\n3 经验总结 目前蚂蚁集团的 SLO 实践不仅提高了集群 pod 的交付成功率，同时通过构建 tracing 系统，分析到集群内 pod 交付关键链路的耗时，整理失败原因，实现了数据分析 / 诊断平台。对于如何实现高 SLO，范康也给出了自己的五点经验。\n 在提升成功率的进程中，SLO 治理团队面临最大的问题是镜像下载。Pod 必须在规定时间内交付，而镜像下载通常需要非常多的时间。所以，团队通过计算镜像下载时间，专门设置了一个 ImagePullCostTime 的错误，即镜像下载时间太长，导致 Pod 无法按时交付。另外，阿里镜像分发平台蜻蜓支持了 Image lazyload 技术，在 Kubelet 创建容器时，不用再下载镜像，大大加速了 Pod 的交付速度； 提升单个 Pod 成功率：随着成功率的提升，再提升的难度会越来越大，这是可以引入 workload 进行重试。蚂蚁集团内部的 PaaS 平台会不断重试，直到 Pod 成功交付或者超时。需要注意的是，重试时要先排除之前的失败节点； 检查关键 Daemonset： …","date":1597820400,"description":"随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。本文分享蚂蚁集团的 SLO 体系是如何建立的。","dir":"blog/antgroup-kubernetes-high-slo/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f15367978d8b820ec3fcddf3ab6d7779","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-kubernetes-high-slo/","publishdate":"2020-08-19T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/antgroup-kubernetes-high-slo/","summary":"随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。 根据 CNCF 2019 Kubernetes 使用调查报告的显示：目前 84% 的用户已经在生产环境中使用 Kubernetes，生","tags":["Kubernetes"],"title":"蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO？","type":"blog","url":"/sofastack.tech/blog/antgroup-kubernetes-high-slo/","wordcount":2530},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈亚兵 提问：\n 我想单独使用注册中心 SOFARegistry，可能的服务有 Java 和 Python，SOFARegistry 支持 Python 服务接口的注册吗？\n A：SOFARegistry 注册中心是支持各个语言的服务发现和订阅的，目前开源版中只有 Java client。实现其他语言的服务发现和订阅，需要自己实现相关语言的 Registry client。\n sofa-bolt-python 也有服务发现和发布，它和 sofa-registry 的发现有什么不同吗？\n A：sofa-bolt-python 只做了使用 MOSN 的服务接口的客户端。sofa-registry 是服务端。 SOFARegistry：https://github.com/sofastack/sofa-registry\n2、@刘明 提问：\n Seata 的 XA 模式做了一个压测，tps=1000，开始报错，ORA-24756：事务处理不存在。 看了下数据库global_table，状态是 3。 3 是 CommitRetrying ， 这说明 phase 1 阶段过了，2 阶段提交报事务不存在。 目前 global_table 里有700多条记录，95%是状态3，还有状态1的。\n A：应该是一个原因，很可能就是2阶段提交失败了。begin 的你查看下他的分支事务状态是什么。\n begin 的分支表里没有数据，可能注册就失败了。\n A：是的，有可能，TC 收到了，然后 TM 超时了，我建议你 1000tps 的测试，搞个 TC 集群，就一台可能撑不住。\n 我想在出错的时候，有个日志轨迹，可以知道数据目前是不是脏的？\n A：select for update 或者 update x=x+n 这样写法一般没事。\n 会不会锁住记录呢？\n A：不锁住怎么保证隔离性。这个 for update xa 没提交前会锁住的，这个锁由数据库方自己已经实现了。\n 是的，那1阶段已经过了，记录会一直锁在那里了吗？\n A：二阶段没提交，锁在数据库肯定没释放。不过看起来你应该提交了吧，因为已经提示你事务不存在了。\n 是的，事务提示不存在，但是数据没有提交。 我研究下。\n A：可以的，seata-xa 现在还不是特别完善，可以多研究下，发现问题可以提交 PR 来贡献，一起让 XA 更稳定更好。\n 并发情况下，事务已经提交，TCC 发起 global commit 请求超时导致了 commitRetry，因此事务不再存在，只是 TCC 会一直去重试。 这导致了性能下降很快，不断重复已经不存在事务的 commit 动作，使用 Oralce 测试下来耗时很大，MySQL 可能也不会更好。考虑在 RM 端做 xaCommit 的时候，引入一个 Redis 检查 xid 是否已经提交，已经提交返回提交成功。\n Seata：https://github.com/seata/seata\n本周推荐阅读 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？ SOFA 项目进展 本周发布详情如下：\n发布 SOFABoot v3.4.3 版本，主要变更如下：\n 新增 endpoint，支持展示启动耗时信息； 升级 Tomcat 版本，修复安全隐患 CVE-2020-11996； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.3\n社区活动报名 A2M 峰会旨在发现全球互联网领域在人工智能、大数据、互联网架构等领域的创新工程和杰出团队，整合国际最佳技术实践，构建行业案例研究智库，帮助中国企业在人工智能时代成功转型、升级。蚂蚁集团受邀进行云原生构建之路的专题分享。\n分享主题：Dubbo 基于 MOSN 在 Service Mesh 场景下的落地实践\n分享嘉宾：曹春晖 蚂蚁集团 可信原生技术部技术专家\n蚂蚁集团技术专家，对 Go 语言有深入的研究，《Go 语言高级编程》作者。在后端业务开发、数据平台等领域有多年的实践经验。目前正在领导 MOSN 社区进行 Dubbo 生态在 Service Mesh 场景下的落地工作。\n背景介绍：过去一段时间，云原生和 Service Mesh 大火。很多公司希望借着东风推动公司的微服务架构演进到下一阶段。然而在实践过程中不会事事如意，问题接踵而至。\n在使用 Dubbo 来做微服务框架的公司中，因为每个公司发展阶段不同，上云的进度不同，社区方案却要求必须要在完全上云之后才能沐浴 Service Mesh 的春风，这着实令人失望。\n解决思路：借助前人的落地经验，在 MOSN 与 Dubbo 结合的探索中，我们思考出一些可供处于不同上云阶段的公司参考的落地方案。经过对数据面的简单改造，在控制风险的前提下，能够渐进地将 Service Mesh 落地到公司内。\n成果：基于 MOSN 和 Dubbo-go，实现 Service Mesh 在 Dubbo 场景下的落地。\n听众收益：\n 了解落地 Service Mesh 对于整体架构的收益； 了解 MOSN 社区的发展现状和规划； 了解 Dubbo 在各种业务场景和上云发展阶段中如何优雅落地 Service Mesh； 分享时间：2020-09-05 16:50-17:50\n活动地点：上海\n活动报名：点击“这里”锁定席位\n","date":1597388400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200814/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"68d4b22d401ef51b62f39c8680895b36","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200814/","publishdate":"2020-08-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200814/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot 发布、SOFAJRaft 以及 SOFARPC 内容合辑、MOSN 活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200814/","wordcount":2113},{"author":"万佳","categories":"Kubernetes","content":" 在 Kubernetes 中，Secret 显得尤其重要。因为它是 K8s 中存储所有敏感信息的对象。据悉，这些敏感信息包含密码、集群的证书、OAuth token、ssh key 以及其他用户自定义的敏感文件等。因此，一旦 K8s 中 Secret 出现安全问题，后果将非常严重。此外，虽然社区提供了一定的安全防护方案，但是依然存在诸多问题。\nK8s Secret 面临着哪些安全问题？这些安全问题会带来什么影响？社区提供的解决方案存在哪些不足？\u0026amp;hellip;\u0026amp;hellip;针对这些问题，InfoQ 记者采访了蚂蚁集团高级工程师秦凯伦，他专注于可信计算、系统安全和虚拟化等领域，对 K8s Secret 有着深入的研究和探索。\nK8s Secret 的安全问题 根据 Kubernetes 文档，Secret 是 K8s 中存储所有敏感信息的对象。事实上，如果敏感信息直接存放于 K8s 的 Pod spec 或镜像中，不仅管控困难，而且存在较大的安全隐患。因此，K8s 通过创建、管理、应用 Secret 对象，可以更好地控制敏感信息的用途，并降低其意外暴露的风险。\n秦凯伦称，虽然引入 K8s Secret 对象，这在一定程度上降低了意外泄露的风险（更多地是通过集中式的管理），但是 K8s Secret 对象自身的安全性，“社区默认方案中仍存在许多安全问题”。\n一般来说，K8s 中，Secret 数据以纯文本的方式存储在 etcd 中，默认只有 base64 编码，未经加密。同时，共享该文件或将其检入代码库，密码容易泄露。\n社区解决方案的不足 针对此问题，K8s 社区提供了基于 KMS 的 K8s Secret 加密方案，谷歌云、AWS 和 Azure 均支持该方案。他说，“这虽然解决了 etcd 中 Secret 明文存储问题，但依然有一些问题。”\n Secret、加密 Secret 的密钥在内存中明文存放、易被攻破； 攻击者可以假冒合法用户，调用解密接口，窃取密钥； 密钥一旦泄露，将导致所有数据的泄露，从而引起用户对整个系统的信任崩溃。“为此，社区和一些公司尝试为该方案中的 Plugin 加上基于硬件的安全保护，从而提升攻击难度。但对某些特定用户来说，保护的覆盖面和程度依然不够”。\n实际上，我们可以从 K8s Secret 的整个生命周期来看：\n Secret 的生成及访问 Secret 的身份证书明文存放在用户侧内存中，用户侧环境复杂，容易被攻击者攻破； 加密 Secret 的密钥的生成、cache 等在 K8s API server 中明文存放在内存中，安全根易被窃取或破坏； 与 KMS 交互的 Plugin 的加解密接口无法防止攻击者假冒，存在泄漏风险； Secret 在 Node 中消费，依然明文内存存放，暴露出一定攻击面； 在秦凯伦看来，理想中，对 K8s 中 Secret 的保护程度应该考虑其整个生命周期的安全、可信，做到端到端的安全防护。\n蚂蚁集团的探索 为此，他们基于 TEE 技术，将 K8s Secret 整个生命周期和端到端使用过程中的关键组件、步骤保护起来。整体方案大致如下：\n 将 API Server 端与 KMS 交互的 KMS Plugin 用 TEE 保护，在保障了 Plugin 中根密钥（安全根）、数据加密密钥无泄漏风险的前提下，降低了性能开销； 将 API Server 端的 KMS provider 用 TEE 保护，避免数据密钥及 Secret 在任何时候明文直接暴露在内存中；同时，通过 TEE 的本地证明机制能够认证解密数据密钥接口的调用者，防止攻击者假冒，确保密钥的安全； 将用户端的 kubectl、kubeconfig 等使用 TEE 保护，一方面 kubeconfig 不落盘同时被硬件保护，提升了安全水位；另一方面，用户的 Secret 通过安全信道直通到 TEE 中进行处理，避免了直接暴露在内存中，规避了被恶意窃取的风险，且用户对 API Server 进行 TEE 远程证明，可以帮助用户确信他正在把自己的 Secret 托付给可信的软件实体（没有含有故意泄露用户秘密的恶意逻辑），建立对 API Server 的信任； 将 Node 端的 kubelet 中 Secret 的消费过程用 TEE 保护，进一步避免了 Secret直接暴露在内存中，规避了被恶意窃取的风险； 秦凯伦向 InfoQ 记者指出，“这种方案是基于 TEE 的端到端 K8s Secret 保护，还引入 LibOS 技术，实现 TEE 保护对用户、开发者和运维团队完全透明。”\n据悉，KMS Plugin 和 TEE-based KMS Plugin 没有标准和开源的社区实现，因此他们设计并开发了自己的 KMS Plugin，并在灰度发布、应急处理、监控管理等方面进行了生产增强。“在与 TEE 结合的过程中，我们为了应对 SGX 机型存在的性能问题，提供了 standalone 和服务化 KMS Plugin 两套方案”。\n同样，TEE-based kubectl 也没有标准和开源的社区实现，他说：“我们基于 kubeproxy 开发了自己的安全 kubectl，实现了 kubeconfig 对用户透明、与用户身份绑定、不落盘并采用TEE保护内存安全等设计目标。”\n此外，考虑到 TEE 保护的易用性、可靠性、可扩展性和可维护性等，他们在评估多套方案后，引入了由蚂蚁开源的 Occlum LibOS，屏蔽了 TEE 对用户、开发者和运维团队的影响，大大降低了 TEE 开发的门槛和成本。\n在秦凯伦看来，K8s 作为蚂蚁大规模容器集群的管控根基，应用基于 TEE 的端到端 K8s Secret 保护防护方案，增强了其自身安全和可信，提升了蚂蚁核心管控平面的安全水位，“这对于金融场景下高标准的数据安全和隐私保护来说不可或缺”。\nK8s 相关阅读 备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？ Kubernetes: 微内核的分布式操作系统 开箱即用的 Java Kubernetes Operator 运行时 深入Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统 深度 | 蚂蚁金服自动化运维大规模 Kubernetes 集群的实践之路 ","date":1597215600,"description":"K8s Secret 面临着哪些安全问题？这些安全问题会带来什么影响？社区提供的解决方案存在哪些不足？","dir":"blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"39e435e749635a88bce9e36771e5b2e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","publishdate":"2020-08-12T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","summary":"在 Kubernetes 中，Secret 显得尤其重要。因为它是 K8s 中存储所有敏感信息的对象。据悉，这些敏感信息包含密码、集群的证书、OAuth token、ssh key","tags":["Kubernetes"],"title":"蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？","type":"blog","url":"/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","wordcount":1958},{"author":"SOFA 团队","categories":"SOFAStack","content":" PS：阅读本文大约需要 15 分钟，或者您可以选择直接拉至文末投递简历，加入云上江湖。\n 有人说，历史是由懒汉推动的。\n科技的演进史，其实就是人类不断偷懒的过程。我们懒得浪费体力，于是有了蒸汽机；我们懒得动笔演算，于是有了电子计算机；我们懒得随身携带现钞，于是有了线上交易和无接触支付……程序和信息成为这个时代的基底，服务和应用围绕着我们的指尖打转。\n我们从网络上索取一切，海量的数据和代码在赛博空间里奔流不息。\n突然有一天，构筑代码世界的工人们也犯懒了。为首的“懒汉”开始思考，能不能把一些通用的代码模块打包起来，供给上层随时取用，这样就省下了重复“造轮子”的力气，让敲代码也成为一种模块化的工作？\n这一“偷懒”，就偷出了一个新概念：中间件。\n无人探索的道路 对普通人来说，“中间件”是一个很遥远的词汇。\n从技术层面来讲，中间件是介于基础设施和业务系统之间的特殊软件。程序员们别出心裁地构思了各种比喻：有人说它是建筑工地上的“预制件”，让工人不必从头开始搅拌水泥；有人说它是整合货源的“中间商”，让商家免于一次次询价比价的操劳……\n“基础设施和业务系统之间，有很多通信和集成方面的要求，让每个业务系统都去做一遍是很浪费人力的。”蚂蚁集团高级产品专家马振雄这么说，“大家都有这样的诉求。”\n时势造英雄，SOFAStack 在蚂蚁集团应运而生。\n它诞生得悄无声息，初衷只是为了“解救”支付宝。那还是青涩年代的支付宝，没有琳琅满目的蚂蚁森林、花呗和健康码，用4个“一”就能概括它的全部：一个简单的应用，装在一台应用服务器上，使用一个数据库，服务一个大客户——淘宝。\n简单、轻快、便捷，这个系统支撑了支付宝从2004年到2006年早期的发展。但是随着交易量的攀升、业务的复杂化，支付宝很快遭遇了成长中的阵痛。\n“从刚开始几十个人，后来几百人，到现在几千人的技术团队，在不同规模下的研发方式和组织方式都是不一样的。”蚂蚁集团高级技术专家黄挺说，“人一多，你发现不同的人写的代码会不一样，冲突也越来越多。”\n概而言之，研发效率出现了问题。\n如果说从前的支付宝是一间平房，如今则要发展成一座城市。而每搭建一座建筑，工人都必须从头开始烧制砖块、搅拌水泥——没有挖掘机，没有液压锤，一切从手无寸铁开始，对以“建设城市”为己任的团队来说，这是完全不可接受的。\n举个例子，当时支付宝的一个电子钱包系统 iWallet，每次启动需要五六分钟，足够开发人员下楼抽一支烟。如果发现错误，就得修改后重新启动，开发人员每天深陷在代码编译和重启的“死循环”之中。\n究其原因，就是因为 iWallet 系统包含了几十个工程，有十多个团队并行开发。支付宝原本的系统无法支撑这么复杂的业务逻辑，也难以让那么多工程师在一起并行工作，大家把它称为 monolithic——庞大的单体系统。\n支付宝的诉求显而易见：第一，希望成百上千个项目并行进行，每个工程师可以不受干扰地工作；第二，当业务逻辑增加的时候，系统的复杂度不要成指数级上升。 它需要一套能够力挽狂澜的“中间件”。\n2006年，契机来临。技术团队在这一年开了一连串的会，会议的核心议题只有一个：决定支付宝未来的技术架构。团队内部分成两派：第一派提议向银行老大哥学习，走集中式架构的老路；第二派则认为分布式架构才能支撑未来的交易支付系统，而且不是客户端/服务器时代那种小规模架构，是互联网时代的超大规模分布式架构。\n毫无疑问，这是一条无人探索过的道路。\n当然，你知道阿里人的秉性，退缩和守成从来不是他们的标签。经过长达一年左右的思考和论证，技术团队果断驶入第二条赛道。2007年起，支付宝率先启动了对交易系统、商户系统、会员系统、支付清算系统的改造，一个全新的架构正在孕育之中。\n这套分布式架构就叫“SOFA”。\n为什么叫这个名字？其一是源于当时正火的“SOA”概念，即 Service-Oriented Architecture，“面向服务的架构”，在此基础上加入金融业务，就构成了 SOFA 的全称：Service-Oriented Fabric Architecture。\n其二则是开发者的私心，“希望能够像沙发（Sofa）一样，让工程师可以非常爽地工作。” 从“连接器”到“工具库” 什么是 SOA？用偏技术的语言表述，就是把企业的 IT 系统以“服务”的方式重新组织，再通过“服务总线”连接起来，形成可插拔式的企业 IT 架构，这个架构就是 SOA。\n你或许觉得这个释义很难懂，没关系，因为在那个年代，SOA 纯粹只是一套面向传统企业 IT 架构的思想，换句话说，一套理论框架罢了。\n你问业界具体的成功实践？抱歉，没有。\n初次试水，蚂蚁的“探路者”们走得非常谨慎：第一代 SOFA 只解决两个问题，一是充当一个类似于“胶水”、“连接器”的机制，把分布式系统连接成整体；二是做到每一个服务组件化，让每个工程师专注做好各自的组件，最后把组件拼装在一起成为“服务”，再把“服务”拼装在一起组成整个系统。\n用黄挺的话来说，“SOFA 能够隔离出一些不同的模块，由不同的人去做开发，每个人有了更加细致的分工，不会跟别人出现太多的交叉。”\n第一代 SOFA 清晰地定义了团队之间的边界，何时分工协作，何时紧密联合，安排得明明白白。黄挺举了个例子：简单的一次转账业务，系统需要调用用户的通讯录，调用账务相关的子系统——可能还得去问银行，账户余额到底够不够？整个流程涉及到非常复杂的系统交互，这些由不同团队开发和运维的系统，怎样才能高效交互、稳定完成每一笔业务呢？这就仰赖 SOFA 从中协调和沟通了。\n燃眉之急解决了，但初生的分布式中间件 SOFA 并不能处理所有问题。它还需要打怪升级，积累经验，向下一代、再下一代演化。\n无人探索的道路上没有先驱者，只有野蛮生长的技术难题在横冲直撞。\n在 SOFA 的加持下，支付宝一边拆分金融业务系统（后来的业务中台）一边拆分底层 IT 系统（后来的数据中台和计算中台），在拆分过程中还要应对历年双十一的海量数据冲刷，以及不断涌现、千奇百怪的技术问题。甚至在解决分布式服务一致性问题时，由于业界提出的两个 SOA 事务标准都无法支撑支付宝核心系统的交易量，团队干脆一狠心一咬牙：现有的标准都不可行，要不我们自己提一个吧！\n逢山开路，遇水搭桥。很难说清 SOFA 这些年来的演进中，他们遭遇过多少类似的阻碍，又有多少奇思妙想和技术实践沉淀下来，最后凝练成 SOFA 内部的几行代码。\n他们在无人区设下哨塔，漫漫长夜被灯火点亮。\n第一代 SOFA，做到了模块化。\n第二代 SOFA，完成了服务化。\n第三代 SOFA 的亮点，则是被誉为“蚂蚁黑科技”的单元化，“异地多活”架构让服务器资源水平扩容的难度大大下降，保障了用户的每一笔订单平稳顺滑。团队坦诚，面向超大规模互联网金融交易的分布化改造，单元化这一技术构想完全是被业务倒逼的，业界没有先例可循。\n“我们找到过一些论文、一些概念，但以支付宝这么大的体量，没有人确定这事儿真的能做成。”团队成员感慨。\n就这样，随着支付宝架构的逐次优化，SOFA 也在不断迭代和成长。从最初仅是一个简单的框架，到后来强化通讯性能、提升容灾效率、建设异地容灾架构、单元化改造、添加 LDC 逻辑数据中心项目……SOFA 羽 …","date":1597042800,"description":"从初试锋芒到大展拳脚，从无人区的前哨到数字化转型的领航员，云上自有江湖，欢迎加入云上江湖","dir":"blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","fuzzywordcount":8900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dc1065f8e3a2e016a6fc8750bbfab2c2","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","publishdate":"2020-08-10T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","summary":"PS：阅读本文大约需要 15 分钟，或者您可以选择直接拉至文末投递简历，加入云上江湖。 有人说，历史是由懒汉推动的。 科技的演进史，其实就是人类不断偷","tags":["SOFAStack"],"title":"蚂蚁 SOFAStack：云上自有江湖","type":"blog","url":"/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","wordcount":8849},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@丁浪 提问：\n 这个跟 TCP 长链接的心跳没根本区别啊！也只能保证链路上的通畅，应用僵死或者苟延残喘了可能发现不了，可以补充从注册中心去主动探测 URL，反正现在 SpringBoot 和 SOFABoot 应用都可以开启 healthcheck 的 endpoint，为啥不从注册中心发探测请求，反正都有 healthcheck 的 endpoint。链路上的保活那只是基本生存需求，稍微高级一点就不行了，应用僵死或者苟延残喘那种可能还有心跳的。我看你们把这个问题交给 RPC 框架去做了，让 RPC 框架去做故障剔除和容错。 A：SOFARegistry 目前设计是比较依赖网络连接的，网络连接只要出发了断链事件（这个目前监听是靠 Netty 的事件通知过来的）就会进行数据清理，这个敏感性也决定了服务发现比较快，但是对于抖动和其他大面积不稳定情况处理确实显得不足。我们说的 RPC 框架剔除是对于经常性的链接不通地址采取自动降级不进行调用处理，至于 Spring 那种心跳检测机制，我们开始实现也考虑过，因为这个健康检查机制和网络断连触发的敏感性差别较大，健康检是定期轮训的可能确定服务下线没有这么快速发现，所以没有采用，后续也想过兼容两种模式解决这个断链处理，引入类似 ZK 那种 Session 过期等机制可以在快速发现和稳定性做一个取舍。\n 那种应用进程僵死、较长时间 fullgc 之类的，长链接心跳还在注册中心发现不了流量过来就有问题的，RPC 框架的剔除机制我个人认为只能是种兜底降级。我目前是结合 K8s 探针去请求应用的 healthcheck 路径的，K8s 健康检查不通过就会杀进程重启 Pod，这样注册中心也会感知到 RPC 流量也就剔了。\n SOFARegistry：https://github.com/sofastack/sofa-registry\n2、@倪美俭 提问：\n 这是 AT 模式，store:db，rollback 的交互图，麻烦帮忙瞅瞅有问题吗？ A：是的，一阶段都是提交的，二阶段如果是回滚就会把之前的本地 commit 回滚掉。\n 这种场景是否要优化下，直接发起二阶段回滚，就不再进行这个本地事务一阶段的提交呢？这里为什么会进入到本地事务的 commit 方法里，而不是 rollback 方法里呢？\n A：这种你把本地的事务注解加到全局事务注解下面就好了，这样发起方所在的本地事务是直接走 rollback，其余参与方才是二阶段决议通知下来。\n 强一致性需求的场景，Seata 里只能用 XA，但 XA 是依赖数据库本身对 XA 协议的支持来实现的，那是不是这种模式下性能上会比 LCN 要逊色一些呢？\n A：首先 LCN 的原理是通过 connection 的代理，使之做空提交，二阶段决议后，把 hold 住的 connection 进行真正的 commit 或者 rollback，然而这个方式的隔离性交由本地事务来实现，因为 connection 未提交，所以事务还未提交，强依赖了本地事务。其次除非你的服务不会宕机，否则不建议你使用 LCN 模式，因为如果在二阶段决议后，宕机了一个参与者，那么 LCN 是无法恢复之前的数据，导致数据丢失。\n而 XA 你可以认为他跟 LCN 也很像，但是 LCN 面对的是数据源连接，而 XA 你会发现这个才是由数据库真正意义上去支持的一个协议，即使宕机了，Seata XA 也是做了 XA 的预提交，持久化提交数据在数据库层面，但未真正提交，从而可达到宕机后重启也可以提交事务。\n这是我做在 Seata 中 LCN 原理实现的 PR：https://github.com/seata/seata/pull/2772 ，你可以阅读下，很容易发现他的缺陷，LCN 的性能高是基于啥也基本没干，就多了个几个 RPC 通信的消耗，无需解析 SQL，做镜像校验，全局锁解锁等操作，他仅仅只是把本地事务的提交延迟到其余的参与者都完成了业务并且没发生异常的情况下。看过这个 PR 或者 LCN 的源码后，你就会真正的理解为什么 LCN 说自己不产生事务，而是事务的协调者而已。\n 去年看过 LCN 的源码，它也是代理了数据库连接，在一阶段会 hold 住所有的数据库连接，并不真正提交，二阶段会全部一起提交或回滚，那么有参与者宕机的话不应该会全部回滚吗？\n A：因为是基于本地连接的回滚，连接断开会自动回滚，所以即使二阶段决议形成提交时，若应用或网络出问题，连接断开就自动回滚了，不能保证极端一致性。 Seata：https://github.com/seata/seata\n本周推荐阅读 少年五年升阿里 P8，他如何从低谷登上“光明顶”？ 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.15.0 版本，主要变更如下：\n 新增 UDP Listener 的支持； 新增配置扩展能力，Dubbo 服务发现可通过扩展配置扩展，支持 Yaml 格式的配置解析； 新增流量镜像功能的扩展实现； 支持了更多路由配置； Skywalking 升级到 0.5.0 版本； 针对 Upstream 与 XProtocol 进行了优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.15.0\n同时，恭喜邓茜（@dengqian）成为 MOSN Committer，感谢她为 MOSN 社区所做的贡献。\n2、发布 SOFARPC v5.7.5 版本，主要变更如下：\n 修复日志打印的问题； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.5\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题： …","date":1596783600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200807/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3ae77ff6536d0104b38d51679b7f078b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200807/","publishdate":"2020-08-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200807/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN \u0026 SOFARPC 发布、MOSN 社区活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200807/","wordcount":2576},{"author":"陈伟荣","categories":"智能监控","content":" 电影《太空旅客》里，无人驾驶的阿瓦隆号飞船去往家园2号要经历120年，飞船的顺利抵达必须依赖一套高端智能运维系统。在蚂蚁，技术风险部的智能监控就好比那个智能运维系统，而智能监控团队便是背后那群看不见的守护飞船的人。\n 2019年双十一的凌晨三四点，阿里西溪园区附近的某家网咖里门客冷清，只有几个神色淡定的青年小伙聚在一排座位上愉快地进行 DOTA 游戏， 他们时不时看一眼手机上发来的消息，像是在守着什么不敢掉以轻心，但脸上又流露出胜券在握的信心。\n就在几个小时前，这群看似“不务正业”的网咖少年还坐在阿里双十一最核心的作战室“光明顶”，与阿里众大佬高管一起值班，助力双十一决胜千里。\n他们正是蚂蚁集团技术风险部智能监控团队。\n对于阿里人来说，“光明顶之战”为每年大促中的巅峰一战，能够登上“光明顶”的非泰山北斗即拥有超强武功的高手。作为该团队主力之一的陈伟荣说，光明顶上各路阿里大神、大佬汇聚一堂，每年的双十一就是智能监控团队的“高光时刻”。\n从象牙塔走向“光明顶” 在蚂蚁技术大事记上，智能监控团队于2012年就曾被留名：首次实现秒级交易监控。之后，他们每隔一段时间就会有技术突破。2014年至2016年期间，蚂蚁监控就用一套 xflush 系列产品成功走出蚂蚁实现与阿里集团监控团队的合作，为当时的淘系赋能。之后的 sunfire 监控、新一代阿里集团网络监控与 IDC 监控均是在此基础上迭代而来，并且沿用至今。\n这期间，一位青涩少年正从象牙塔走向阿里。他就是陈伟荣，2015年以应届毕业生身份加入阿里监控团队成为一名工程师。\n和很多刚毕业的同学一样，陈伟荣对互联网公司的技术体系并不熟悉，彼时他眼中的监控团队更像是一个运维工具组，日常工作就是服务器上看看日志，看看 CPU、内存指标，再做下数据展现就完事了。相较于消息中间件、数据中间件、虚拟化、块存储等各种基础技术团队相比，初入职场的陈伟荣偶尔也会觉得智能监控好像并没有那么高端大气上档次。因此才刚工作几个月，他就判定自己在监控团队肯定呆不了多久就会转岗。\n但是随着进一步深入工作领域，他发现大家工作对标的是各类流式计算，加之团队重视底层引擎研发，在对计算框架和时序存储研究一番后，陈伟荣意识到团队在做的事一点都不比其他基础技术团队简单：这是一个非常典型的垂直领域大数据应用，技术和业务上都非常具有相当挑战性。\n在技术层面上，实时、稳定、低成本、高精度都是对监控的要求，这些约束条件做到一点两点不难，但是要同时做到，极难。但陈伟荣所在的团队就是落地了这样一个高度稳定，秒级延迟，PB 级吞吐的监控平台，他透露后面团队还将重点发力算法和智能化能力。\n2016年发生了很多让陈伟荣迄今难忘的事，有一些事情的影响至今存留。\n那年支付宝新春红包登上了央视春晚，春晚直播屏幕前是全国人民一双双充满期待的眼睛。对于春节红包项目组的技术同学来说自然是严阵以待、不允许有丝毫差池。入职仅半年的陈伟荣有幸和团队其他精兵强将一起加入项目组，承担实时数据计算部分的任务，他主动提出要做项目内相对复杂的内存缓存部分研发。\n但代码写出来后陈伟荣被师兄狠狠痛批了。本来对于自己的技术和工作态度都很有信心的陈伟荣看到师兄一边改 bug 一边骂、一副恨铁不成钢的架势，心中的底气彻底被击碎。\n此后，少年卸下傲气，行路时步步夯实。\n2016年的双十一如约而至，这是陈伟荣在监控团队的第二年，面孔依旧很新，但是双十一活动却已经迎来了第八年。恰逢又一年的光明顶之战，团队却正好缺位，陈伟荣主动挺身而出，承担起阿里16年双十一监控系统稳定性负责人的角色。\n那次双十一，陈伟荣首次挑大梁，最终拼尽全力不负众望完成任务。双十一交易巅峰来临的那十几分钟也成为陈伟荣至今回忆起来最难忘的一段时间。据后来公布的数据了解到，2016年的双十一支付宝支付峰值已达到12万笔/秒，全天交易量达十亿，但是没有一笔交易异常。\n“平时研发中只要我认定这个事情从长期，或者更高视角看能帮助到团队和用户，我就愿意去做一些非常危险的，甚至短期都看不到收益的研发工作，”陈伟荣说。\n2017年，陈伟荣从阿里集团转到了蚂蚁集团，随后逐步切入工作，带领着蚂蚁技术风险部监控技术中台，负责数据的采集链路和实时计算的架构，并在此基础上构筑监控的数据服务体系。猛将加持，蚂蚁监控团队持续发力，2018年后，他们便结合自身的定位和业务目标，重新审视监控这个领域，又推出了 Antmonitor 系列的监控产品，现已发展到了2.0版本。 五年升P8，回首依然是少年 十年前，高考在陈伟荣生命里落下帷幕。只不过这场尽力准备了三年的考试，结果并不如意。\n高考成绩出来后陈伟荣大失所望，比正常发挥时几乎掉了一个层次，最后被南开大学德语专业录取，几乎等同于被调剂。高考后的暑假，难以接受打击的陈伟荣一度靠游戏度日。在复读和将就之间纠结了很久后，最终他决定向前看，并开始着手调研和规划大学的学习计划，为转专业作准备。\n高考失意，大学时奋起直追，陈伟荣通过各种努力走出了一条独特的发展道路：从文科的德语专业到软件工程专业，期间还修了金融学学位。\n毕业前的校招季，不少互联网公司开始招实习生，陈伟荣把简历投递给了阿里。但那时他心里更想走的是继续出国深造的路，所以当年投的简历更多是无心插柳之举。\n经过几轮紧张的现场面试后，没想到第二天阿里面试官就电话通知陈伟荣面试通过了。人生就是这样不可预料，同期报名的同学中仅他一个临时起意投递简历的被录取了。来了阿里后，陈伟荣一下子被阿里技术体系的先进性吸引了，实习转正后，他便决定不再继续读书直接工作了。\n他不知道自己本科拼命几年扭转的人生方向是否正确，只携一身热血前往，不回头。\n从2015年加入阿里开始，陈伟荣一直在监控领域做事，但是工作范围逐渐放大，从最初采集 agent 研发到逐步深入理解整个数链路、开始掌握数据技术架构，到现在能带领团队推进技术架构演进，他不断挑战自己的极限。\n五年时间弹指一挥间，说起过去，陈伟荣的回忆里酸甜苦辣翻涌。但要说最开心的时刻，他觉得是今年年初完成 pontus2.0 项目研发并最终上线支撑业务监控场景这个事。这次的技术升级突破了先前的监控技术框架，真正统一了监控数据层模型为未来数据建设铺平了道路，大家一起攻克艰难让项目按时落地，过程中的不易最后都变成了开心的回忆。\n团队里同事们年龄相仿，组队打篮球或者去网吧开黑打 DOTA 成为大家最放松的时刻，或嬉笑怒骂，或相互扶持，抛去工作上的对接合作与依赖关系，他们可以聊天南地北，聊海阔天空……\n最近，有一件事让 92 年的陈伟荣比较开心，那就是他专门定制的电吉他终于到货了。\n原来，这位少年还是一位重金属音乐爱好者。说着，他给我发来一个 Arch Enemy 在 2016 年 wacken 音乐节现场的视频链接，还提醒我要关小声音听。\n“我去过两次这个乐队在上海的 live，还跟主唱的那个妹子击过掌。”\n我眼前浮现这样一幅画面：“光明顶”少年与 Arch Enemy 歌曲中那些真实直白歌词达成了共识——人生也要“不断突破，向死而生”。\n","date":1596438000,"description":"坐在光明顶的少年。","dir":"blog/five-years-to-ali-p8/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"80f2d7c63c3dfb1ee561e79745630a68","permalink":"https://sofastack.github.io/sofastack.tech/blog/five-years-to-ali-p8/","publishdate":"2020-08-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/five-years-to-ali-p8/","summary":"电影《太空旅客》里，无人驾驶的阿瓦隆号飞船去往家园2号要经历120年，飞船的顺利抵达必须依赖一套高端智能运维系统。在蚂蚁，技术风险部的智能监","tags":["智能监控"],"title":"少年五年升阿里 P8，他如何从低谷登上“光明顶”？","type":"blog","url":"/sofastack.tech/blog/five-years-to-ali-p8/","wordcount":2786},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@刘明 提问\n 请问，分支事务在回滚过程中，服务器宕机了，重新启动后，TC 如果发送过来的回滚请求，是否还能继续回滚？\n A：可以。\n 是使用 XA 模式的 Oracle 数据库，分支服务器即使宕机了，回滚日志还在 Oracle 上是么？\n A：是的，xa_prepare 在 DB 实现 XA 层面做了持久化，MySQL 要求 5.7.7+。\n 刚测试了下 Oracle 的，xid 就像一个字符串 key 一样，任何时候只要告诉 Oracled 对 xid 做 rollback 都可以成功。我以为需要在 start/end 同一个连接里才行，是我理解错了。\n A：lcn 才需要这样，xa 不需要一个连接，所以 lcn 那种宕机了数据就没了。\n LCN 没有了解，他难道不是基于数据库自带的 XA 实现的？\n A：lcn 是 lcn 框架的一个原理，就是通过 connection 来统一提交和回滚。\n 我是用 jdbc 直接操作 Oracle 测试的，用 Oracle 的 XAResource。 这个特性是数据库自带的？\n A：XA 协议本来就是由数据库方进行的支持。\n 使用 DatabaseSessionManager 去存储 globalsession，这个 lockAndExecute 方法没有 lock 的逻辑，多个进程在获取 global 会话做超时、重试提交等时，会有资源冲突吗？\n A：多个 TC 会出现资源争抢冲突，倒是不影响一致性。\n 多个 TC 会对同一个 XID 做 retryCommitingg 操作吧，2个 TC 会做2次，3个 TC 会做3次？\n A：是的，没有分布式任务调度。\n 2个事务分支，TC 在发起提交请求后，分支一正常提交，分支二网络波动没有收到提交请求。 这个时候 TC 会尝试重试提交。 如果一直重试失败，会因为全局事务 timeout 发起回滚请求吗？\n A：提交一阶段就是持久化了，不会影响。\n 但是全局事务会有个超时检查，超时的事务处理方式就是回滚，会不会这样？分支二的提交重试一直不能成功，最后global 会话超时的吧？这时候分支一已经 commit，再做 rollback 肯定不行了。\n A：二阶段结果已经出现了，已经决议好了的，二阶段的提交只不过是空提交而已，异步的。\n 二阶段 TC 成功发送 commit，RM 接收到了后，执行 XA 提交动作，这时候数据才真正可以看到，如果 RM 接收不到 commit 请求，他本地数据时没有提交的吧？\n A：XA 模式确实是这样的。\n 那参与者中有人收到 commit 请求了，有人没收到，最后 global 超时，是不是也没法回滚了？\n A：XA 一阶段只是做了预备数据的持久化，保持操作，并没有真正入库，等到 commit 的时候才会入库，每个模式2阶段都不一样。 Seata：https://github.com/seata/seata\n本周推荐阅读 Kata Containers 2.0 的进击之路 Kata Containers 创始人：安全容器导论 Kata创始人王旭：远程工作可以从开源中借鉴哪些经验？ SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.4.2 版本，主要变更如下：\n 修复 ServiceComponent 和 ReferenceComponent 的健康检查结果不包含抛出的内部异常； 修复默认情况下 SOFA runtime 忽略组件抛出的内部异常； 增加引流操作的阻断性，fail fast； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.2\n2、发布 SOFAJRaft v1.3.4 版本，主要变更如下：\n 升级 SOFABolt 到 1.6.2（支持异步非阻塞建连机制）； 移除对 log4j 的直接依赖； RouteTable、RegionEngine、StoreEngine 实现 Describer 以提供更详细的调试信息； 修复 snapshot 文件创建漏洞，禁止跳出 snapshot 目录之外创建文件； 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.4\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题：云原生网络代理 MOSN 的进化之路 分享嘉宾：王发康（毅松）蚂蚁集团 可信原生技术部 技术专家 背景介绍：网络通信代理 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，增强 MOSN 服务治理及流量控制能力，对接云原生周边组件，实现 MOSN 开箱即用，MOSN 成为云原生 Service Mesh 的标准 Sidecar 之一，从而借力开源，反哺开源。 听众收益：可快速基于 MOSN 和 Istio 进行 Service Mesh 实践，了解微服务的发展历程、遇到的痛点以及解决方案，获取 MOSN 的功能特性，解决微服务常见的问题。 分享时间：2020-08-15 13:30-14:30 活动地点：深圳 活动报名：点击“这里” ","date":1596178800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200731/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ba067c1a03b386adff832962bb27dd52","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200731/","publishdate":"2020-07-31T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200731/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 以及 SOFABoot 发布、MOSN 社区活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200731/","wordcount":1941},{"author":"李昊阳","categories":"Kata Containers","content":" Kata Containers 开源项目于2017年底正式启动，其目标是将虚拟机（VM）的安全优势与容器的高速及可管理性相结合，为用户带来出色的容器解决方案。该项目在过去两年取得了哪些进展？下一版本的路线图包含什么特性？首先让我们快速回顾一下 Kata Containers 项目的奋进之路… 缘起：Kata Containers 2013 年，Docker 问世，容器成为热门新事物，全球的开发者为之着迷。也难怪，容器以标准格式封装，将运行于标准操作系统环境上的应用打包，使应用程序可从一个计算环境快速可靠的切换至另一个计算环境，这对于那些想要快速构建、测试和部署软件的开发者而言至关重要。容器具有轻量化、低开销的特性，几乎可以立即被调度和启动，可在任何环境中运行，为微服务提供便利，扩展资源等（以上仅列举了一些流行的优势）。 尽管有许多技术优势，但容器有一个缺点 - 容器与宿主机共享内核，这可能会引发严重的安全漏洞问题。理论上，如果您在单个主机上部署了多个容器，一旦其中某个容器被恶意代码利用，由于共享namespace，该主机上的其他所有容器也容易受到攻击，在这种情况下，可能会对云基础设施整体构成严重的安全威胁。如果您是云供应商，安全威胁可能会扩展到云端客户的数据和业务，这是绝对要避免的。\n图1. 传统容器：主要通过共享内核的 Cgroup 和 Namespace 来达到容器隔离和资源限制的目的\n因此，许多负责大规模容器运行的运维人员将容器“嵌套”在虚拟机中，从逻辑上将其与运行在同一主机上的其他进程隔离开，但在虚拟机中运行容器会丧失容器的速度和敏捷性优势。Intel 和 Hyper.sh（已加入蚂蚁集团）的开发人员意识到了这个问题，同时开始独立研发解决方案，两家公司都希望容器可以摆脱传统虚机的所有包袱，换言之，就是开发“面向云原生的虚拟化”技术：\n 来自 Intel 开源技术中心的工程师在 Intel Clear Containers 项目中运用 Intel Virtualization Technology（Intel VT）技术来强化性能和安全隔离； 与此同时，Hyper.sh 的工程师采用相似的策略启动了开源项目 runV，将容器放在一个安全“沙箱”中，通过支持多种 CPU 架构和管理程序，侧重于开发技术中立的解决方案； 2017年，两家公司将项目合并，互为补充，创建了开源项目 Kata Containers。Intel 和 Hyper.sh 联合开发者社区，希望在各方的共同努力下，兼顾性能和兼容性，在为终端用户提供出色应用体验的同时，加速开发新的功能特性以满足未来新兴用例的需求。Kata Containers 成为 OpenStack 基金会（OSF）除 OpenStack 之外的首个托管项目，该项目于2017年12月在北美 KubeCon 上正式公开亮相，社区座右铭是“快如容器，稳似虚机”。 其实质是，通过 Kata Containers 让每个容器/pod 采用其单独的内核，运行在一个轻量级的虚拟机中。由于每个容器/pod 现在都运行在专属虚拟机中，恶意代码无法再利用共享内核来访问邻近的容器，因此，容器即服务(CaaS)供应商能够更安全的提供在裸金属上运行容器的服务。由于容器之间的硬件隔离，Kata Containers 允许互不信任的租户，甚至生产应用及未经认证的生产应用程序都能在同一集群内安全运行。\n图2. Kata Containers: 每个容器/pod 被隔离在各自的轻量级虚拟机中\n因此，Kata Containers 与容器一样轻便快捷，并且可与容器生态系统无缝集成（包括流行的编排工具，如 Docker 和 Kubernetes），同时还具有虚拟机的安全优势。\n社区进展 Kata Containers 项目成立的第一年，社区主要致力于合并 Intel 及 Hyper.sh 的代码，并在全球的行业活动中介绍该项目独特的硬件隔离方案，这是其他容器运行时所缺乏的功能，同时也邀请了大量的社区开发者共同推进该项目。 Kata Containers 社区如今已经拥有众多的贡献者和支持者，包括来自九州云、阿里巴巴、AMD、AWS、百度、Canonical、中国移动、CityNetwork、戴尔易安信、易捷行云、烽火通信、谷歌、华为、IBM、微软、红帽、SUSE、腾讯、同方有云、中兴、英伟达、Mirantis、NetApp、PackageCloud、Packet、Vexxhost 等许多有影响力公司的开发者。随着社区的不断壮大，该项目正在稳步发展中。 社区成就包括：\n 加入开放容器倡议（OCI）规范，Kata Containers 社区持续与 OCI 和 Kubernetes 社区紧密合作，并在 AWS、Azure、GCP 和 OpenStack 公有云环境以及所有主要 Linux 发行版中对 Kata Containers 进行定期测试； 添加了对主要架构的支持，除 x86_64 外，还包括 AMD64，ARM，IBM p- 系列和 IBM z- 系列等架构； 无缝集成上游 Kubernetes 生态系统，Kata Containers 现在可以立即连接到大多数开箱即用的 Kubernetes 网络； 删除不必要的间接层，社区已经去掉了 kata-proxy 组件，并在 KubernetesSIG-Node 开发者和 containerd 社区的帮助下引入了 shim-v2，从而减少了 Kata Containers 辅助进程的数量； 降低开销，提升速度，社区正努力提升启动速度，减少内存消耗，并朝着创建（几乎）“零开销”沙箱技术的目标迈进。为此引入多个虚拟机管理程序，包括 QEMU，QEMU-lite，NEMU和AWSFirecracker。还与 containerd 项目整合，推动建立了 rust-vmm 项目，2019年，社区用 Rust 重写了一个沙箱内的 agent，显著减少了匿名页。总之，社区正通过一系列的改进工作来最大限度地减少开销，通过引入 FirecrackerVMM 将内存开销减少到 10MB，而通过 rust-agent 的合并将 agent 的匿名页从10MB减少到1.1MB； “面向云原生的虚拟化”，与面向虚拟机领域不同，容器领域是以应用为中心的，为了解决这种差异，社区引入了 virtio-vsock 和 virtio-fs，后续将引入更灵活的内存弹性技术virtio-mem； 如需详细了解项目进展，可查看王旭的系列博客：KataContainers: 两年而立 百度智能云的 Kata Containers 应用实践 百度，中国领先的搜索引擎运营商，全球最大的中文网站托管商，全球领先的 AI 公司-正在其百度智能云中大规模（超过 43k CPU 内核！）应用 Kata Containers，包括百度智能云函数计算（CFC）、百度智能云容器实例（BCI）、百度边缘计算等多种实践场景。 百度智能云是百度面向企业和开发人员的智能云计算平台，致力于为各行各业的企业提供一体化的人工智能、大数据和云计算服务。根据 Synergy Research Group 发布 …","date":1595919600,"description":"Kata Containers 项目的奋进之路","dir":"blog/kata-container-2.0-road-to-attack/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2eaaa668460266fb66b2b44f5611c472","permalink":"https://sofastack.github.io/sofastack.tech/blog/kata-container-2.0-road-to-attack/","publishdate":"2020-07-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/kata-container-2.0-road-to-attack/","summary":"Kata Containers 开源项目于2017年底正式启动，其目标是将虚拟机（VM）的安全优势与容器的高速及可管理性相结合，为用户带来出色的容器解决方案。该项目在过","tags":["Kata Containers"],"title":"Kata Containers 2.0 的进击之路","type":"blog","url":"/sofastack.tech/blog/kata-container-2.0-road-to-attack/","wordcount":4042},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网https://www.sofastack.tech SOFAStack:https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@Zhengguang 提问：\n 想问下，默认的 RMClient.init(applicationId, txServiceGroup); 这个方式启动 RM 的时候有个问题，它传递的 resourceId 为 null 也就是说 RM 初始化的时候虽然在 TC 注册了，但是注册的信并非之前断开始后那个 resourceId，所以 RM 重启后并不会立即收到来自 TC 的 retry。 以下是日志，可以看到默认 RM 初始化的时候 resourceIds 是空的： [timeoutChecker_2] INFO io.seata.core.rpc.netty.NettyPoolableFactory - NettyPool create channel to transactionRole:RMROLE,address:127.0.0.1:8091,msg:\u0026amp;lt; RegisterRMRequest{resourceIds=\u0026amp;lsquo;null\u0026amp;rsquo;, applicationId=\u0026amp;lsquo;api\u0026amp;rsquo;, transactionServiceGroup=\u0026amp;lsquo;my_test_tx_group\u0026amp;rsquo;} \u0026amp;gt;\n使用 API 方式，跑的是 seata-sample-api 这个 demo，AT 模式。\n A：1.其实 RMClient.init 的时候，并不会进行注册，真正进行注册的是初始化 DataSourceProxy的 时候。 2.如果注册的时候 resourceIds=\u0026amp;lsquo;null\u0026amp;rsquo;，很有可能你的 DataSourceProxy 没有初始化，也即是数据源没代理成功。\n 是的我观察到的就是这个现象，我这边项目更希望在 API 模式下使用 Seata，所以并没有通过 spring 启动，可能 DataSourceProxy 没有自动初始化，所以这里是不是应该有什么方式可以手动触发 DataSourceProxy 初始化的过程。\n A：手动配置一样就可以了，像这样子：\n\u0026amp;lt;bean id=\u0026amp;quot;dataSourceProxy\u0026amp;quot; class=\u0026amp;quot;io.seata.rm.datasource.DataSourceProxy\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;constructor-arg ref=\u0026amp;quot;dataSource\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; 哦哦，所以我要在 RMClient.init 启动后，马上手动获取一次 DataSourceProxy。Demo 中的这个 DataSourceUtil 要在第一次 getDataSource 的时候才会初始化 proxy，所以我要在 RMClient.init 启动后马上 get 一次数据源就好了， 测试通过。\n Seata：https://github.com/seata/seata\n本周推荐阅读 基于 MOSN 和 Istio Service Mesh 的服务治理实践 再启程，Service Mesh 前路虽长，尤可期许 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 SOFA 项目进展 本周发布详情如下：\n发布 SOFABolt v1.6.2 版本，主要变更如下：\n 支持检查连接并异步创建连接； 支持用户设置 UserProcessor 的 ClassLoader； 修复 URL 对象默认连接数为0导致不创建连接的问题； 修复无可用连接的 ConnectionPool 无法被回收的问题； 详细发布报告：https://github.com/sofastack/sofa-bolt/releases/tag/v1.6.2\n社区活动报名 机密计算（Confidential Computig）是近年来发展迅速的一种安全技术，它利用可信执行环境（TEE）——如 Intel SGX——来保证内存数据始终处于加密状态，因而将安全性提高到前所未有的程度，并赋能了诸多新型应用场景，比如多方联合数据分析、隐私保护的机器学习、保证机密性的区块链合约等等。虽然技术本身令人兴奋，但机密计算对应用开发者有比较高的门槛，令人望而却步。\n针对上面的问题，蚂蚁集团开源了 Occlum 项目，一款使用 Rust 语言开发的、面向机密计算的 TEE OS，可使得任何语言的任何应用程序轻松地移植进 TEE 环境。本次分享既会从用户角度介绍如何使用 Occlum 的轻松开发机密计算应用，也会从技术角度分享 Occlum 技术架构和特色。\nOcclum 网站：https://occlum.io\nOcclum Github：https://github.com/occlum/occlum\n本期主题：《SOFAChannel#18：零门槛的机密计算：Occlum LibOS 使用入门和技术揭秘》\n分享嘉宾：田洪亮（花名：樱桃） 蚂蚁集团技术专家 Occlum 开源负责人\n你将收获：\n 了解机密计算领域的最新进展； 了解 Occlum 的技术架构； 了解使用 Rust 语言开发安全软件的一手经验； 了解如何将创新工作转化为实用系统； 直播时间：2020-07-30 19:00-20:00\n报名方式：点击“这里”，即可报名\n","date":1595574000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200724/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6efe8af3dfb578bdfd495367e78b60e4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200724/","publishdate":"2020-07-24T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200724/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt 发布新版本、MOSN 相关文章整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200724/","wordcount":1603},{"author":"姚昌宇","categories":"Service Mesh","content":" Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。\n 本文根据7月22日晚 Service Mesh Webinar#2 有米科技高级后端工程师、MOSN Committer 姚昌宇，线上主题分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》整理，文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 大家好, 欢迎大家参加第二期 Service Mesh Webinar。本期的分享主题是《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。我是今天的分享嘉宾姚昌宇，来自有米科技，目前在公司也是负责服务治理相关的工作，我本身也是一名云原生爱好者，在空余时间关注和参与 Service Mesh 社区，最近参与了 MOSN 新版本的开发，也是有了很多收获。这次受社区邀请来给大家做这次分享，希望能给大家带来收获。\n今天的分享将从以下几个方面进行：\n 第一部分会简单介绍一下什么是 Service Mesh、Service Mesh 可以给我们带来什么红利以及我参与社区的过程和一些收获； 第二部分是这次分享的重点，我会从一个开发者的角度，说说如何基于 MOSN 和 Istio 去做服务治理，中间会包括 MOSN 源码的分析和 Istio 功能的实操，也是比较多 Service Mesh 爱好者关注的如何落地的问题，比如流量的控制啊、服务监控等等的功能； 第三部分会总结一下今天的分享以及 MOSN 一些近况和未来愿景的介绍； Service Mesh 简介以及社区共建实践分享 Service Mesh 简介 首先，什么是 Service Mesh 呢？相信这是众多爱好者刚接触 Service Mesh 时的最初疑问。Service Mesh 发展了这么多年，网上介绍和分析的文章也是很多，在这里我也再啰嗦一句。如果用一句话来概括 Service Mesh，我会说，它是一种微服务的通信方案，是不断演进而成的。\n大家都知道，服务端架构经历了一系列的演进，从最开始的单体服务到 SOA，再到微服务，服务间通信也从最开始的无需通信、到集成在代码里、再到胖客户端库，再演进为 Service Mesh 的 network stub 模式，又或者称为 sidecar 模式。\nService Mesh 主要解决了之前的服务间通信方案的几个问题：\n 语言绑定； 升级困难； 重复开发、标准不一； 语言绑定：在将服务治理逻辑抽离到 Sidecar 之前，这些治理逻辑需要集成在代码里面。这就容易导致业务要么要绑死在同一种开发语言上，要么就要相同的逻辑不同语言维护多份。这样既不灵活，维护起来成本也比较大。\n升级困难：企业里的基础设施团队，在升级服务治理逻辑之后，需要推动各个业务去重启他们的服务，这样一个周期通常会拖的非常长，重启过程也会有各种问题，导致线上各个版本的治理功能不一致，落地起来相当费劲。\n重复开发、标准不一：每个公司都会根据他们的实际情况落地微服务，有的会使用各个语言比较成熟的微服务框架，比如 Java 的 Spring Cloud、Dubbo；或者 Golang 的 go-micro 之类的框架。有的团队或者会使用集成组件的方式，在各个语言的基础上，加上一些成熟的服务治理组件，比如 Consul、Zookeeper、Hytrix、Vault 等。通常，通过对接这些组件来抽象出一个类似于微服务控制平面需要一定的开发成本，而且这些框架和组件标准也是不一致的，维护起来也会有不少成本。\n那么，Service Mesh 是如何解决这些问题的呢？\n首先，Service Mesh 架构将服务治理的逻辑抽离到一个单独的 Sidecar 进程中，而 Sidecar 进程是与语言无关的。Sidecar 通过代理的形式劫持业务进程的流量，从而做到与具体的业务开发语言解耦。\n其次，Sidecar 通过边车模式和业务进程部署在一起，但是又与业务进程分离。Sidecar 进程可以随时重启更新，业务进程无需感知这个过程。这样可以加速治理逻辑更新换代的过程，解决了传统服务治理，升级困难的问题。\n最后，Service Mesh 定义了控制面和数据面的概念。控制面提供 UI 给操作者去控制整个集群的流量，数据面，顾名思义就是数据流动的平面，负责接收这些配置信息，表现出对应的代理行为。控制面和数据面通过统一的协议进行通信，也就是 Service Mesh 里的 xDS 协议来交换配置信息。通过这样的方式，理论上实现了 xDS 协议的控制面/数据面可以互相插拔替换，这就统一了标准，解决了第三点重复开发和标准不一的问题。\n社区共建经历分享 那了这么多，那我是如何从关注 Service Mesh 社区，到参与到 MOSN 开源共建的呢？觉得整个过程可以概括成3点：\n 找到组织； 知识积累； 参与贡献； 其实一开始我也是一个初学者，刚接触到 Service Mesh 也会被一大堆不知名的名词砸得晕头转向的，像是 xDS、控制面、metrics tracing 之类的名词。所幸的是，ServiceMesher 的中文社区相当完善和活跃。我相信有了解过 Service mesh 的同学，肯定有加过2个微信 \u0026amp;ndash; 一个就是宋净超宋大的微信，一个就是 ServiceMesher 社区的微信群。也是得益于众多的前辈将 ServiceMesher 中文社区维护的这么好，将各种内部实践分享出去，以及外部一手资讯搬运甚至翻译过来，乃至是这样子的不定期的线上线下分享。这些都是非常好的资源。只要你想去学，就肯定有方法的。而对于新人的疑问，社区里的大神们也是非常乐意解答。\n既然有了目标和资源，那就差去做了。接下来我通过不断的去理解这些新领域的概念，理解它们的含义和背后的设计目的以及应用场景，再加上源码分析和动手实践，慢慢也就搭建起了整个关于 Service Mesh 的知识体系。\n在摸清门道之后，其实参与开发也不是什么难事了。那为什么我会选择 MOSN 呢？其实蚂蚁集团有整个 SOFAStack，也就是金融级云原生架构的开源共建计划，其中有服务注册、流量跟踪、rpc 协议、分布式事务等等的项目。我选择 MOSN 主要是有两点考虑：\n 第一是 MOSN 是使用 Golang 实现的，这一点和个人的技术栈比较吻合； 那第二点，我认为 Sidecar 在 Mesh 的位置是比较关键的。在大型的集群里，上百万的 Sidecar 在集群里互相通信，为业务进程转发处理数据包，其稳定性、性能要求和灵活性都是比较高的； 近期我也参与到了 MOSN 的 Istio Roadmap 开发中，主要目标是将 MOSN无 缝地接入到 Istio 里，成为在里面可以工作的 Sidecar。我主要做的几个功能是pilot-agent 的适配以及一致性哈希负载均衡功能的开发。其实和做业务需求是类似的，首先要知道功能要达到什么目的，然后预演改动的地方，最后实践：fork 一份 MOSN、开发 …","date":1595498400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/mosn-istio-service-mesh/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"03b066886bc7e069eca5654ee35e4782","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-istio-service-mesh/","publishdate":"2020-07-23T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/mosn-istio-service-mesh/","summary":"Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。 本文根据7月22日晚 Service Mesh Webinar#2 有米科技高级后端","tags":["Service Mesh","MOSN"],"title":"基于 MOSN 和 Istio Service Mesh 的服务治理实践","type":"blog","url":"/sofastack.tech/blog/mosn-istio-service-mesh/","wordcount":4565},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@古月 提问：\n 请问 SOFARPC 可以在 Spring MVC 环境 XML 配置使用?老项目 ssm，非 Spring Boot 环境。\n A：可以的。和直接用 SOFARPC 没区别。 SOFARPC 相关 Demo：https://www.sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@伍月 提问：\n 工程使用 OperatingSystemMXBean（osBean）类对系统 CPU 情况进行监控。 osBean.getSystemCpuLoad() = -1 ？？？ osBean.getProcessCpuLoad() = -1 ？？？ 有没有人知道是怎么回事。 注：正常情况下 CPU 返回值在 0 到 1 之间。\n A：抛出异常的时候会返回 -1，之前记得 arthas 也会返回 -1。\n 感谢回答。 工程在 Linux 服务器上运行时获取 CPU 数据正常。只是在本地 Windows 上运行时获取 CPU 数据返回 -1。后来百度得知可能由于本地 Windows 用户没有获取系统 CPU 数据的权限。\n Seata：https://github.com/seata/seata\n本周推荐阅读 我们需要什么样的端到端 AI 系统？蚂蚁 SQLFlow 的思考与答案 火了 2 年的服务网格究竟给微服务带来了什么？ Kubernetes: 微内核的分布式操作系统 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.7.4版本，主要变更如下：\n 允许用户设置 Triple 服务的版本； protobuf 编译器升级到 0.0.2； hibernate-validator 升级到 5.3.5.Final； jackson-databind 升级到 2.9.10.5； 修复了 Hessian over triple 不支持基本类型的问题； 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.4\n2、发布 Seata v1.3.0 版本，主要变更如下：\n AT 模式支持了像多主键，自动升降级，redis 存储等大量 feature； TCC 模式支持了模式支持 Dubbo 和 SOFARPC 注解调用； Saga 模式支持 Groovy 脚本任务、支持 jackson 序列化、代码重构将内部扩展点 SPI 化； 整体性能得到大幅度提升，修复了旧版本的存量 bug； 本次 release 变动文件数：442，代码变动：+17062 −8419，参与代码 commit 人数：31，合并 PR 数：90，其中：feature：20，bugfix：29，代码优化重构：41； 详细发布报告：https://github.com/seata/seata/releases/tag/v1.3.0\n社区活动报名 Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#2，邀请有米科技高级后端工程师姚昌宇，带来分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。本期分享可以收获对 Service Mesh 技术以及如何落地有更多的认识。\n分享主题：基于 MOSN 和 Istio Service Mesh 的服务治理实践\n分享嘉宾：姚昌宇 有米科技高级后端工程师、MOSN committer\n你将收获：\n 了解如何参与到 MOSN 开源社区共建中； 了解如何使用 MOSN 在 Istio 场景下的服务治理实践 ; 了解 MOSN 新版本的功能以及未来远景； 结合 Istio 各个场景的 Demo，分享 MSON 的多协议/私有协议实现； 直播时间：2020-07-22 20:00-21:00\n直播间地址：关注直播间，7月22日不见不散\n","date":1594969200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200717/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"54ea1b69911fe82c9674739a421a0ce5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200717/","publishdate":"2020-07-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200717/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC、Seata 组件发布以及社区 QA 整理、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200717/","wordcount":1475},{"author":"沈凋墨","categories":"Kubernetes","content":" 如今，Kubernetes 已经成为分布式集群管理系统和公有云/私有云的事实标准。实际上，Kubernetes 是一个分布式操作系统，它是 Google 在分布式操作系统领域十余年工程经验和智慧的结晶，而 Google 一直以来都管理着世界上最大的分布式集群，在分布式操作系统领域的研究和认识领先于全世界。因此，2014年发布的 Kubernetes 能在短短几年时间内就超越了诸多前辈，大获成功。\n作为分布式操作系统，Kubernetes（包括其前代产品 Google Borg）的出现远远晚于 UNIX、Linux、Windows 等著名的单机操作系统，Kubernetes 架构设计自然地继承了很多单机操作系统的珍贵遗产，微内核架构就是这些遗产中最重要的一份。在本文接下来的部分，我们将专注于微内核（microkernel）这个概念及其对 Kubernetes 架构的影响。\n什么是微内核？ 在介绍微内核的时候，我们有必要同时回顾一下单机操作系统的历史，以理解其价值所在。本章中以「操作系统」指代「单机操作系统」。\nUNIX 的兴起 电子计算机诞生之后，在上个世纪70年代以前，出现过许许多多的操作系统，DOS、OS/360、Multics 是其中的知名代表，这是操作系统领域的拓荒时代。20年来的拓荒孕育出了伟大的成果：随着 CPU 技术的发展，UNIX 于1969年诞生了，这是一个真正意义上的分时操作系统。\n图片来源：维基百科\n借助新的 CPU 技术的支持，UNIX 将软件系统划分为内核（kernel）和用户态程序（userland programs）两部分。内核是一组中断处理程序的集合，把硬件的能力封装为操作系统功能调用（system calls），用户态程序通过系统调用使用硬件功能，用户态程序运行于各自的进程中，所有用户态进程都共享同一个内核，每当系统调用或中断发生，UNIX 便陷入（trap）内核，内核执行系统调用，与此同时，内核中的分时调度算法将决定把 CPU 交给哪个进程，并管理进程的上下文切换。另外，UNIX 把（几乎）所有硬件都封装为文件。UNIX 还提供了一个特殊的用户态程序 shell，供用户直接使用系统，通过内核提供的进程间通信能力，shell让 用户可以把一系列应用程序组合起来，处理复杂的需求，作者称这个设计思想为「KISS」（Keep It Simple and Stupld）。UNIX 的所有设计思想在当时是都是非常了不起的创举。\nUNIX 不但自身对业界产生了巨大的直接贡献，还成为所有现代操作系统的蓝本，两位作者 Ken Tompson 和 Dennis Ritchie 因此荣获1983年度的图灵奖。\nUNIX 诞生于贝尔实验室，该实验室属于美国国家电信电报公司（AT\u0026amp;amp;T），见识到 UNIX 的强大威力之后，AT\u0026amp;amp;T 做出了一个看似无私的决定：将 UNIX 开源（初期只对大学开源），这使得所有现代操作系统得以诞生。虽然 AT\u0026amp;amp;T 最终被分拆，辉煌不再，但这个决定对人们的贡献绵延至今。在21世纪20年代的今天，无论是 MacOS、Windows、Linux，都直接受到 UNIX 的影响，而 iOS 来自 MacOS，Android 来自 Linux，因此 UNIX 的灵魂仍然活在每个人的手机中、活在每个手机 App 后台的服务中。\n此外，UNIX 诞生之时，还附送了一项比操作系统本身价值更大的副产品：Dennis Ritchie 为开发 UNIX 设计了C语言，C语言成为了所有流行的现代编程语言的主要设计来源，不仅如此，C语言在其诞生近40年后的今天，仍然是最重要的编程语言之一。\n值得一提的是，当时 UNIX 的主要开放对象是伯克利、卡内基梅隆等研究型大学，文理学院规模较小，没有研究生项目，不属于 AT\u0026amp;amp;T 的主要开放目标，因此 Olivet College 毕业的一位小哥未受到 UNIX 思潮的影响。这位名叫 David Cutler 的软件天才于1975年在 DEC 设计了 VMS 操作系统，VMS 和最初的 UNIX 一样，运行在 PDP-11 上，但并不是基于 UNIX，而是独立设计的。VMS 在业界没有掀起大浪，以兼容 UNIX 告终。后来 David Cutler 离开 DEC，加入微软，在那里谱写了属于他自己的传奇。有趣的是，乔布斯也曾在文理学院就读，看来美国文理学院的学生是不走寻常路的。\n微内核的兴起 UNIX「一切皆文件」的设计带来了用户程序设计的很多便利，但它要求所有对硬件的封装都要在内核态，因此内核中模块的 bug 会让整个系统受到影响，比如说，如果某个设备驱动有内存泄漏，所有使用该设备的用户态进程都会有内存泄漏，如果某个内核模块有安全漏洞，整个系统的安全性将不再可控。\n为了解决这类问题，上个世纪70年代，操作系统研究者们开始发展「微内核」的概念，微内核的本质是让操作系统的内核态只保留内存地址管理、线程管理和进程间通讯（IPC）这些基本功能，而把其它功能如文件系统、设备驱动、网络协议栈、GUI 系统等都作为单独的服务，这类服务一般是单独的用户态 daemon 进程。\n用户态应用程序通过 IPC 访问这些服务，从而访问操作系统的全部功能，如此一来，需要陷入内核的系统调用数量将大大减少，系统的模块化更加清晰。同时系统更加健壮，只有内核中的少量系统调用才有权限访问硬件的全部能力，如设备驱动的问题只会影响对应服务，而不是影响整个系统。和 micro kernel 相对，UNIX 的设计被称为 monolithic kernel。\nUNIX 开放后，AT\u0026amp;amp;T 继续着版本迭代，而各大学基于 AT\u0026amp;amp;T 的 UNIX 开发了很多新的操作系统内核，其中较为知名的有：\n BSD，monolithic，由伯克利的传奇人物 Bill Joy 于1974年发布（据说 Bill Joy 花三天便完成了 BSD 内核的第一个版本开发，Bill Joy 的作品还包含第一个 TCP/IP 协议栈、vi、Solaris、SPARK 芯片等等）。该内核对业界影响非常之大，后来发展为 FreeBSD、OpenBSD、NetBSD 等分支。现代操作系统如 Solaris、MacOS X、Windows NT 对其多有借鉴。 Mach，微内核，由卡内基梅隆大学于1984年发布，主要作者是 CMU 的两位研究生 Avie Tevanian 和 Rick Rashid。该内核对业界影响也很大，GNU Hurd、MacOS X 对其多有借鉴，但该项目本身以失败告终。 MINIX，微内核，由阿姆斯特丹自由大学（Vrije Universiteit Amsterdam）的 Andrew Tanenbaum 教授于1987年发布。无数计算机系学生通过 MINIX 及其配套教材掌握了操作系统的设计原理，Linux 的初始版本就是基于 MINIX 复刻的。MINIX 虽然著名，但主要用于教学，从未在工业界获得一席之地。 微内核的沉寂 从上世纪90年代至本世纪10年代，UNIX 和 VMS 的后裔们展开了一场混战，从结果来看，微内核的概念虽然美好，但现实非常 …","date":1594882800,"description":"本文将专注于微内核（microkernel）这个概念及其对 Kubernetes 架构的影响分享。","dir":"blog/microkernel-distributed-operating-system-kubernetes/","fuzzywordcount":7100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9fc5956b0fc0551dfdcf50df35ee8a84","permalink":"https://sofastack.github.io/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","publishdate":"2020-07-16T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","summary":"如今，Kubernetes 已经成为分布式集群管理系统和公有云/私有云的事实标准。实际上，Kubernetes 是一个分布式操作系统，它是 Google 在分","tags":["Kubernetes"],"title":"Kubernetes: 微内核的分布式操作系统","type":"blog","url":"/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","wordcount":7097},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践\n 活动时间：7 月 22 日周四晚 8 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 Service Mesh Webinar Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#2 Service Mesh Webinar#2，邀请有米科技高级后端工程师姚昌宇，带来分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。\n本期嘉宾将为大家分享从关注 ServiceMesher 社区，到参与 MOSN 开源共建的心路历程，包括 Service Mesh 技术的相关介绍、如何参与社区共建以及如何将 MOSN 结合 Istio 根据实际场景落地的示范。本期分享可以使你对 Service Mesh 技术，以及如何落地有更多的认识。\n分享主题：\n《基于 MOSN 和 Istio Service Mesh 的服务治理实践》\n分享嘉宾：\n姚昌宇 有米科技高级后端工程师、MOSN committer。多年后端开发经验、云原生爱好者。目前负责公司内部数据和算法能力接口的服务治理相关的开发工作，2018年起关注并参与 ServiceMesher 社区发起的各种活动，近期参与 MOSN v0.14.0 版本功能的开发。\n直播时间：2020年5月28日（周四）20:00-21:00\n大纲：\n Service Mesh 带来的红利 参与 MOSN 开源共建给我带来的收获 如何参与 MOSN 开源共建 找到组织：进入 MOSN 开发者群 熟悉 MOSN \u0026amp;amp; 搭建本地调试环境：现场演示（http、grpc 服务流量控制演示，指标收集，请求跟踪演示） 发现优化点/参与 Roadmap 感悟总结，以及 MOSN 近况\u0026amp;amp;未来远景介绍 用户收获：\n 了解如何参与到 MOSN 开源社区共建中； 了解如何使用 MOSN 在 Istio 场景下的服务治理实践 ; 了解 MOSN 新版本的功能以及未来远景； 结合 Istio 各个场景的 Demo，分享 MSON 的多协议/私有协议实现； ","date":1594710000,"description":"7 月 22 日周四晚 8 点，Service Mesh Webinar#2 线上直播。","dir":"activities/service-mesh-webinar-2/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"856529bdb9666c8bad4c59a80444662f","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-webinar-2/","publishdate":"2020-07-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-webinar-2/","summary":"概要 活动主题：Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践 活动时间：7 月 22 日周四晚 8 点 活动形式：线上直播 报名方式：戳这里","tags":["MOSN","Service Mesh Webinar"],"title":"Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践","type":"activities","url":"/sofastack.tech/activities/service-mesh-webinar-2/","wordcount":657},{"author":"罗广明","categories":"Service Mesh","content":" 本文节选自 ServiceMesher 社区出品的开源电子书《Istio Handbook——Istio 服务网格进阶实战》，作者罗广明，来自百度。\n 在过去几年中，微服务成为了业界技术热点，大量的互联网公司都在使用微服务架构，也有很多传统企业开始实践互联网技术转型，基本上也是以微服务和容器为核心。本文将主要介绍微服务架构的概述以及云原生环境下的 Service Mesh 和传统微服务应用的区别。\n微服务架构概述 微服务架构可谓是当前软件开发领域的技术热点，在各种博客、社交媒体和会议演讲上的出镜率非常之高，无论是做基础架构还是做业务系统的工程师，对微服务都相当关注，而这个现象与热度到目前为止，已经持续了近 5 年之久。\n尤其是近些年来，微服务架构逐渐发展成熟，从最初的星星之火到现在的大规模落地与实践，几乎已经成为分布式环境下的首选架构。微服务成为时下技术热点，大量互联网公司都在做微服务架构的落地和推广。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。\n而在这个技术转型中，国内有一个趋势，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。然而软件开发没有银弹，基于这些传统微服务框架构建的应用系统在享受其优势的同时，痛点也越加明显。这些痛点包括但不限于以下几点：\n 侵入性强。想要集成 SDK 的能力，除了需要添加相关依赖，往往还需要在业务代码中增加一部分的代码、或注解、或配置；业务代码与治理层代码界限不清晰。 升级成本高。每次升级都需要业务应用修改 SDK 版本，重新进行功能回归测试，并且对每一台机器进行部署上线，而这对于业务方来说，与业务的快速迭代开发是有冲突的，大多不愿意停下来做这些与业务目标不太相关的事情。 版本碎片化严重。由于升级成本高，而中间件却不会停止向前发展的步伐，久而久之，就会导致线上不同服务引用的 SDK 版本不统一、能力参差不齐，造成很难统一治理。 中间件演变困难。由于版本碎片化严重，导致中间件向前演进的过程中就需要在代码中兼容各种各样的老版本逻辑，带着 “枷锁” 前行，无法实现快速迭代。 内容多、门槛高。Spring Cloud 被称为微服务治理的全家桶，包含大大小小几十个组件，内容相当之多，往往需要几年时间去熟悉其中的关键组件。而要想使用 Spring Cloud 作为完整的治理框架，则需要深入了解其中原理与实现，否则遇到问题还是很难定位。 治理功能不全。不同于 RPC 框架，Spring Cloud 作为治理全家桶的典型，也不是万能的，诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。而这些功能往往是企业大规模落地不可获缺的功能，因此公司往往还需要投入其它人力进行相关功能的自研或者调研其它组件作为补充。 以上列出了传统微服务框架的局限性，但这并不意味着它们就一无是处了。在中小企业，采用 Spring Cloud 这样的传统微服务框架已经可以满足绝大部分服务治理的需求，并且借此快速推进微服务化改造。这些痛点往往是技术发展到一定的程度必然要经历的阶段，这些痛点促使技术不断发展、不断前进。\n在众多热门技术趋势中，云原生的关注度居高不下，很多开发者都对由此兴起的一众技术十分追捧，众多企业又开始探索云原生架构的转型与落地。这一年，中国的开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变。而 Service Mesh 技术也因此越来越火热，受到越来越多开发者的关注，并拥有了大批拥趸。那么 Service Mesh 是什么呢？它为什么会受到开发者的关注？它和传统微服务应用有什么区别？\nService Mesh 定义 Service Mesh 一词最早由开发 Linkerd 的 Buoyant 公司提出，并于 2016 年 9 月29 日第一次公开使用了这一术语。William Morgan，Buoyant CEO，对 Service Mesh 这一概念定义如下：\n A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.\n 翻译成中文如下：\nService Mesh 是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。\n以上这段话有四个关键点：\n 本质：基础设施层； 功能：请求分发； 部署形式：网络代理； 特点：透明； 2017 年，随着 Linkerd 的传入，Service Mesh 进入国内社区的视野，并且由国内的技术布道师们翻译成“服务网格”。\n服务网格概述 服务网格从总体架构上来讲比较简单，不过是一堆紧挨着各项服务的用户代理，外加一组任务管理流程组成。代理在服务网格中被称为数据层或数据平面（data plane），管理流程被称为控制层或控制平面（control plane）。数据层截获不同服务之间的调用并对其进行“处理”；控制层协调代理的行为，并为运维人员提供 API，用来操控和测量整个网络。\n更进一步地说，服务网格是一个专用的基础设施层，旨在“在微服务架构中实现可靠、快速和安全的服务间调用”。它不是一个“服务”的网格，而是一个“代理”的网格，服务可以插入这个代理，从而使网络抽象化。在典型的服务网格中，这些代理作为一个 sidecar（边车）被注入到每个服务部署中。服务不直接通过网络调用服务，而是调用它们本地的 sidecar 代理，而 sidecar 代理又代表服务管理请求，从而封装了服务间通信的复杂性。相互连接的 sidecar 代理集实现了所谓的数据平面，这与用于配置代理和收集指标的服务网格组件（控制平面）形成对比。\n总而言之，Service Mesh 的基础设施层主要分为两部分：控制平面与数据平面。当前流行的两款开源服务网格 Istio 和 Linkerd 实际上都是这种构造。\n控制平面的特点：\n 不直接解析数据包。 与控制平面中的代理通信，下发策略和配置。 负责网络行为的可视化。 通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。 数据平面的特点：\n 通常是按照无状态目标设计的，但实际上为了提高流量转发性能， …","date":1594710000,"description":"本文将主要介绍微服务架构的概述以及云原生环境下的 Service Mesh 和传统微服务应用的区别。","dir":"blog/microservices-service-mesh/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f6d713862b049df801c82f5c52ec6ed1","permalink":"https://sofastack.github.io/sofastack.tech/blog/microservices-service-mesh/","publishdate":"2020-07-14T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/microservices-service-mesh/","summary":"本文节选自 ServiceMesher 社区出品的开源电子书《Istio Handbook——Istio 服务网格进阶实战》，作者罗广明，来自百度。 在过去几年中，微服务成为","tags":["Service Mesh"],"title":"火了 2 年的服务网格究竟给微服务带来了什么？","type":"blog","url":"/sofastack.tech/blog/microservices-service-mesh/","wordcount":5219},{"author":"SOFA 团队","categories":"SQLFlow","content":" 端到端机器学习是一种由输入端的数据直接得到输出端结果的AI系统，它可以对业务人员屏蔽复杂技术细节，同时给模型以更多自动调节空间，增加模型整体契合度。近两年来，端到端机器学习成为 AI 领域研发热点，蚂蚁集团于2019年5月发布端到端 AI 系统 SQLFlow 开源项目，受到业界广泛关注。今天，就让我们来看看它对端到端 AI 的思考与解答。\n SQLFlow 是蚂蚁集团开源的使用 SQL 完成 AI 工作流构建的编译系统。SQLFlow 将多种数据库系统（MySQL, Hive, MaxCompute）和多种机器学习引擎（Tensorflow, Keras, XGBoost）连接起来，将 SQL 程序编译成可以分布式执行的工作流，完成从数据的抽取，预处理，模型训练，评估，预测，模型解释，运筹规划等工作流的构建。\n接下来我们会根据以下内容逐步介绍 SQLFlow：\n 为什么要使用 SQL 语言描述端到端 AI 任务； 使用 SQLFlow SQL 语句构建 AI 任务； 使用 SQL 程序构建端到端 AI 工作流； 使用 SQLFlow Model Zoo 沉淀模型； 应用 SQLFlow 的场景案例； 为什么要使用 SQL 语言描述端到端 AI 任务 首先，思考一个问题，人工智能和金融有哪些耳熟能详的结合呢？  在智能征信风控方向，可以运用大数据进行机器学习，刻画用户画像，抽取个性化典型特征，推进反欺诈评估、用户征信评估。 用到的技术：聚类（将有相似特征的群体聚类，确定人群标签）、分类（学习已有分类标签的用户特征，识别新用户所属的类型、标签）、模型解释\n 在智能投资顾问方向，我们以人工智能算法为基础，为客户提供自动化投资管理解决方案，包括提供投资资讯、构建投资组合、直接投资管理等服务。 用到的技术：时序模型、回归、运筹规划\n 智能营销方向，上世纪90年代沃尔玛超市将「啤酒」与「尿布」摆在同一区域的做法，大大增加了商品销售收入，成为借助数据分析实现智能营销的经典案例。而今天，在人工智能等新技术的加持下，数据分析技术正在不断进化，千人千面的智能营销已有广泛的应用。 用到的技术：推荐算法、Ranking、CTR、运筹规划\n然而，构建传统的机器学习工作流程，需要经历非常多的步骤并使用复杂的技术栈： 构建完整的 AI 应用，首先需要获取用于构建模型的数据，这些数据通常可以从日志、订单数据、交易记录等获得。之后通过数据抽取，将其中我们需要用到的部分信息，从多个存储位置抽取出来。抽取数据之后需要进行数据预处理，比如去掉错误的数据，填充缺失的数据，整理，排序等。预处理完成之后，我们需要从这部分数据中得到用于训练模型的特征，比如提取时间序列的周期性特征，获取交叉特征等，最后将构建的特征转换成训练框架可以接收的数据格式，才能开始训练。 另外，在开始训练之前，我们还需要确定使用哪个模型，XGBoost 模型还是深度学习模型，哪个模型更适合当前的场景？模型可以从现有模型库中获取并根据需要修改，或者从头编写新的模型使用。另外在构建机器学习模型时，我们需要不断的评估模型的表现如何，以获得最优的模型，这时就要使用各种评价指标描述训练好的模型。当模型评估结果验证达标之后，就需要将模型代码发布一个新的版本，部署到线上环境。发布之前还要通过线下测试，小流量 ABTest，然后推全部署。如果是离线任务则需要更新定时任务使用新的模型代码。\n当模型的时效性比较强的时候，我们还需要不断的使用新的数据更新模型，就是“增量训练“，这样每次增量训练就不得不再次从头走一次完整的流程。\n要完成这一整套流程，需要用到复杂的技术栈。\n我们需要的数据可能存储在磁盘，或者像 HDFS 这样的分布式文件系统，或者可以从结构化的数据库系统中获得，或者是 NoSQL 引擎（比如 mongodb）存储的数据；在预处理阶段，有可能需要编写 MapReduce Job 来处理 HDFS 上的大量的数据，或者使用 Hive 编写 SQL 语句完成处理，亦或直接编写 Python 代码处理数据；在特征工程阶段，又需要使用类似 statsmodels, tsfresh 或者编写 Python 程序使用诸如 Pandas 之类的库完成预处理；在模型训练阶段，算法工程师首先需要掌握各种建模的能力，算法原理和基础知识，也需要熟练使用各种机器学习引擎如 sklearn, XGBoost, Tensorflow, Pytorch 等；最后在上线部署阶段，还需要了解模型如何接入 Serving 系统，怎么样做 ABTest，怎么编写 CI/CD 任务保证模型上线不影响线上业务。\n构建 AI 应用，不仅需要冗长的链路和复杂的技术，从业务需求到 AI 系统上线也需要特别长的沟通链路。\n比如业务同学和产品同学在构建产品思路的时候，在他的脑海中的 AI 系统需要完成的任务，传达给开发同学之后，有可能传达不到位，需要反复的沟通。有时甚至做了一半还需要重做。\n另外从需求到上线，为了保证线上服务和数据产出的稳定，也需要通过许多的步骤。比如业务同学说：「活动要上线了，时间点很关键，明天必须发布！」开发同学接到需求，加班加点，开发验证完成之后，模型准确率提升10个点，准备发布模型。SRE 同学则会把控上线之前的各项准备，包括预发测试是否通过，压力测试是否通过，CPU 负载是否有提升，硬件资源是否能承载新的模型，模型预测延迟是否提升了等……完成流程也需要很长时间。然而如果没有 SRE 的把关，线上的服务很难保证稳定性。\n使用 SQL 作为描述和构建 AI 任务的语言，可以降低构建 AI 应用的门槛，提升效率。\n首先需要区分编程语言主要的两种描述方法：描述意图和描述过程。简而言之，描述意图是在描述「做什么」，描述过程是描述「怎么做」。比如，夏天大家有空喜欢吃点烧烤喝点啤酒，描述意图的方式，说「我想去撸串」这一句就够了。而描述过程，就需要说「我今天晚上下班后，叫上老王小李，去公司楼下的烧烤店，点100个串和10个啤酒，最后用支付宝扫码付款」。可以看到描述意图可以非常简洁，而具体的执行方案，可以根据意图中构建得出。这点也是 SQL 不同于其他语言的关键点。\n在描述模型训练任务时，使用 SQLFlow SQL 只需要编写 SELECT * FROM iris.train TO TRAIN DNNClassifier LABEL class INTO my_dnn_model; 即可，如果使用 Python 完成相同的任务则需要编写如下图这样的较长的代码。\nSQL 语言除了有非常简洁的优势之外，在数据科学领域，SQL 语言的已有用户量大，并且在不断的增加。这里也有两个统计图，统计了数据科学类任务所使用的工具的流行程度和增长趋势。SQL 语言流行程度排名第三，增量排在第四名。数据科学领域正在更多的使用 SQL 是我们希望使用 SQL 语言描述 AI 任务的原因。除了在表达能力上 SQL 语言有非常简洁的优势之外，在蚂蚁内 MaxCompute 被广泛使用也是我们选择 SQL 的一个原因。\n如何使用 SQLFlow SQL 语句构建 AI 任务 SQLFlow 是一个开源项目， …","date":1594623600,"description":"近两年来，端到端机器学习成为 AI 领域研发热点，蚂蚁集团于2019年5月发布端到端 AI 系统 SQLFlow 开源项目，受到业界广泛关注。今天，就让我们来看看它对端到端 AI 的思考与解答。","dir":"blog/end-to-end-ai-system-sqlflow/","fuzzywordcount":6700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"667a8ff160a9c7f54a5ceba7c20b7437","permalink":"https://sofastack.github.io/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","publishdate":"2020-07-13T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","summary":"端到端机器学习是一种由输入端的数据直接得到输出端结果的AI系统，它可以对业务人员屏蔽复杂技术细节，同时给模型以更多自动调节空间，增加模型整体","tags":["SQLFlow"],"title":"我们需要什么样的端到端 AI 系统？蚂蚁 SQLFlow 的思考与答案","type":"blog","url":"/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","wordcount":6621},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网:https://www.sofastack.tech SOFAStack:https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@郝连帅 提问： \u0026amp;gt; 如果回滚失败有没有告警机制实现？比如钉钉告警。\nA：可以的，实现 FailureHandler 接口。\n本周推荐阅读 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.3，主要变更如下：\n RheaKV 允许不同分片各自配置不同的 learner 节点； 在只有一个成员变更的情况下，仍然使用 raft 联合一致性算法； 替换基于 GPL-2.0 licence 的 Bits.java； 升级 jackson.databind 版本到 2.10.4 已修复安全漏洞； 修复在 node panic 后可能因为未及时刷盘导致快照元数据丢失的 bug； 致谢（排名不分先后）：@zongtanghu\n此版本强烈建议升级 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.3\n社区活动报名 CNCF 的旗舰会议聚集了全球领先开源社区和云原生社区的使用者和技术大咖参加线上峰会。相约 2020 年 7 月 30 日 - 8 月 1 日三天的线上峰会，共同探讨云原生计算的未来和方向。蚂蚁集团也受邀进行两个云原生主题分享。\n分享主题：在大规模 Kubernetes 集群上实现高 SLO 的方法\n 分享嘉宾：霜林 蚂蚁集团技术专家、散樗 蚂蚁集团高级开发工程师 议题介绍：随着 Kubernetes 集群的规模和复杂性的增加，集群越来越难以提供高成功率和低延迟的合格 pod。在本次演讲中，蚂蚁集团的工程师将分享他们在设计 SLO架构和实现高服务水平目标的方法的经验。他们将引入适当的指标，首先衡量 Kubernetes 集群是否健康。然后，他们将解释如何设计和实现跟踪和分析平台，以收集有效的度量和计算这些指标。有了跟踪分析平台，pod 提供过程中出现的问题可以很容易的被诊断出来。最后，他们将展示如何沉淀人工体验到自我修复系统，以自动修复已知的问题。 分享时间：2020-07-30 20:10-20:40 报名方式：点击“这里”，即可报名 分享主题：为 Kubernetes 的秘密披上无形的盾牌\n 分享嘉宾：柯粟 蚂蚁集团高级开发工程师 议题介绍：K8s 的秘密广泛应用于生产中，用于对敏感信息进行存储管理。与 KMS 的集成，甚至与基于硬件的插件，确实增强了保护，但还远远不够，特别是对于财务级的安全需求。由于缺乏端到端的秘密加固解决方案，攻击面在很大程度上在 K8s 集群中其他关键元素/流的威胁中仍然不受保护。通过聚合可信执行环境（TEE）和增强的身份验证，本讲座探索在使用、静止和传输中保护 K8s 秘密的答案。对 kubectl、K8S主节点和节点进行了更改，以保证可用性和机密性。TEE 对开发人员和用户的透明性将通过一个演示进行阐述和演示。最后，将分享在蚂蚁集团的实践经验和 KEP 给社区。 分享时间：2020-07-31 20:10-20:40 报名方式：点击“这里”，即可报名 ","date":1594364400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200710/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"304a9dc50d507f12e1b562491d6b5546","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200710/","publishdate":"2020-07-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200710/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布、CNCF 旗舰会议活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200710/","wordcount":1362},{"author":"尹博学","categories":"分布式架构","content":" 过去几年是云原生理念高速普及的黄金时期。微服务、容器、无服务器架构、服务网格等新技术的出现，在技术社区中激起了一浪又一浪的创新热潮。然而由于金融行业对性能和安全的严苛要求，云原生技术在企业实际场景中的实施落地，特别是在金融场景的实施落地，仍然面临诸多挑战。\n本文整理自2020阿里云线上峰会蚂蚁集团资深技术专家尹博学的主题演讲，为大家分享蚂蚁关于金融级 IT 架构及分布式架构的思考和应用实践。关注本网站，蚂蚁 SOFAStack 白皮书即将发布，不要错过哦～\n 以下为演讲整理全文：\n大家好，我是蚂蚁集团的尹博学，今天和大家分享一下蚂蚁关于金融级 IT 架构及分布式架构的一些思考和应用案例，主要包含三个部分，分别是行业常见的分布式架构介绍、蚂蚁单元化架构的介绍以及单元化架构的应用案例。\n行业常见分布式架构 行业常见的分布式架构主要包含，单活架构、双活架构和冷备架构。从容灾能力角度来看，双活架构和冷备架构均能做到应用级跨机房容灾，但是数据库因为使用了异步复制的技术，无法做到机房级 RPU=0 的容灾。再看灰度发布的能力，冷备架构和双活架构都只能做到机房级灰度发布，无法做到更细粒度的灰度发布。\n蚂蚁集团单元化架构介绍 在介绍完行业常见的分布式架构后，我们来看一下蚂蚁的分布式架构发展历程，和单元化架构的详细介绍。\n这是蚂蚁分布式架构发展历程。蚂蚁也经历了单活、同城双活、两地三中心三个阶段。其中两地三中心是同城双活加一个冷备。随着蚂蚁业务和业务量复杂度的越来越高，业务对于基础架构的要求也越来越高，即扩展能力、容灾能力、灰度能力要求越来越高。最终蚂蚁发展到了单元化架构，将主要业务拆分单元即分片，装入不同的逻辑单元内，每个分片的数据库实现三地五中心部署即三地五中心的单元化架构。\n首先我们来看一下蚂蚁单元化架构的整体架构设计，整体架构包含 RZone、GZone 和 CZone。其中 GZone 部署的是无法拆分的数据和业务，GZone 的数据和业务被 RZone 依赖，GZone 全局只部署一份，而 RZone 部署的是可拆分的业务和对应的数据。每个 RZone 内的数据分片如图所示有五副本，实现三地五中心部署，每个分片内只有一个可写入的主副本，其余副本按照 Paxos 协议做数据强一致。每个 RZone 内实现业务单元封闭，独立完成自己的所有业务。而 CZone 的出现是因为 GZone 全局只有一份，不同城市的 RZone 可能依赖 GZone 服务和数据的时候需要远距离调用，延迟比较大，所以在每个城市部署一个 CZone 作为 GZone 的只读副本，为本城市的 RZone 提供服务。\n介绍完单元化架构的整体设计之后，我们从容灾、灰度发布、弹性三个方面详细看一下该架构的能力。\n首先看容灾能力，容灾能力分为同城容灾和异地容灾，以图中所示为例，RZone1 出现故障先看同城容灾能力，我们目标将 RZone1 切换至同城容灾 RZone2。先做数据库分片切换，RZone1 对应的分片为分片1，把分片1在 RZone2 的副本提升为主副本，数据库副本提升完毕后将 RZone1 的流量切换至 RZone2，实现同城容灾 RPO=0、RTO\u0026amp;lt;1min。\n再看异地容灾，同样以 RZone1 故障为例。目标切换至 RZone3，先做数据库切换，分片1在 RZone3 的副本切换成主副本，完成后将 RZone1 的流量切换至 RZone3，实现异地容灾，该过程 RPO=0、RTO\u0026amp;lt;1min。\n接下来我们看弹性。弹性的背景是业务在大促、节假日等流量出现大幅上涨的过程，我们可以短期租借新的城市和新的 IDC。如图所示，我们租借城市 X 的 IDCX 作为 RZoneX，将 RZone5 的部分流量弹出至 RZoneX，对应流量的数据也弹出至 RZoneX 内。在节假日大促结束之后，将 RZoneX 内的流量和数据弹回至 RZone5，然后回收 RZoneX，这样大幅节约了机房成本。\n介绍完弹性之后，我们来看灰度能力。如图所示，我们将四个 RZone（RZone1、RZone2、RZone3、RZone4）的业务和应用分为 A、B 组，日常 A 组和 B 组各承担50%的应用流量。在应用新版本发布时，我们将 A 组的流量全部切换至 B 组，此时在 A 组上部署新版本，部署完毕后将 B 组的流量按粒度切换至 A 组上，切换粒度等于数据分片的粒度。在切换的过程中可以做 A 组和 B 组的服务对比，如果发现 A 组的服务异常，可以快速将流量切换回 B 组。在 A 组服务一段时间后无异常发生，最终可以将 B 组的流量全部切换至 A 组，把 B 组的版本更新为新的版本，在整个切换的过程中实现了可灰度、可回滚、可监控。\n我们再深入到架构内部，来阐释一下架构内关键模块是如何支撑该架构的。\n首先我们看流量路由模块。流量路由模块的核心是将用户的 uid 信息和对应的 Zone 信息植入到 cookie 中，供流量路由模块做精准路由。我们以用户 uid=68、RZone=RZ03 为例来看流量路由模块是如何工作的，首次用户接入时 cookie 内无 Zone 信息，流量接入模块会随即将该请求发到一个 RZone 内，如发到 RZone1 内，RZone1 通过 zoneClinet 会准确计算该请求应发至 RZone3，即通过 RouteClinet 将该请求发送。发送过程中将计算出的 uid 信息和对应的 Zone 信息植入 cookie 内转发至 RZone3，RZone3 完成本次业务请求后将结果返回给用户，其后用户同意 session 内的其它请求，因为在 cookie 内已经有了准确的路由信息，会被流量路由模块准确的发至 RZone3 完成业务请求。\n接着我们再看一下服务路由，服务路由分为本机房服务路由和跨机房服务路由调用。先看本机房服务路由，服务调用端向本机房服务注册中心订阅服务，发现服务地址后做本机房服务路由调用。再看跨机房服务路由调用，服务调用端向其他 IDC 的注册中心订阅服务地址，发现服务地址后做跨机房服务调用。\n最后我们看数据是如何实现高可靠的。蚂蚁使用自研的分布式关系数据库 OceanBase，每个分片的数据库做5副本部署，部署地域实现三地五中心部署，5副本中有3副本实现强一致，如图所示可以实现同城、IDC 容灾和异地容灾。\n单元化架构实践场景 介绍完蚂蚁单元化架构的主要概念即关键模块信息之后，我们看一下单元化架构在外部客户实施的一些案例。\n第一个案例是一家城商行，它的业务系统、IT系统历史比较长，无法一步跨越到单元化架构，我们为其推荐了大 GZone 的模式，即把城商行的所有服务和数据不做拆分，直接装入一个 GZone 内，在 GZone 的基础上实现同城双活即应用同城双中心部署，数据库同城三中心部署，从而实现同城容灾能力，RPO=0、RTO\u0026amp;lt;1min，但无法实现异地容灾能力，其可灰度能力和弹性能力都无法做到更细力度。\n再看第二个区域银行的案例。我们为这家区域银行实现了同城单元化，即将这家区域银行的主要业务拆分成两个逻辑业务单元两个分片，将其装入一个城市的两个 IDC 内，在另外一个城市建设冷 …","date":1594278000,"description":"本文整理自2020阿里云线上峰会蚂蚁集团资深技术专家尹博学的主题演讲，为大家分享蚂蚁关于金融级 IT 架构及分布式架构的思考和应用实践。","dir":"blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dec27e85a58fcb573b33b9de6125bbc5","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","publishdate":"2020-07-09T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","summary":"过去几年是云原生理念高速普及的黄金时期。微服务、容器、无服务器架构、服务网格等新技术的出现，在技术社区中激起了一浪又一浪的创新热潮。然而由于","tags":["分布式架构"],"title":"支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构","type":"blog","url":"/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","wordcount":3642},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@guotaisu 提问：\n 根据 jraft-example, 使用“fake PD”, 怎样手动 rebalance。使用 PD 自管理体现在哪？\n A：手动 API： https://github.com/sofastack/sofa-jraft/blob/master/jraft-core/src/main/java/com/alipay/sofa/jraft/CliService.java#L190\nPD 目前只实现了 leader 平衡和自动分裂，支持很容易基于 SPI 扩展增加自己的逻辑(增加并实现自己的 com.alipay.sofa.jraft.rhea.util.pipeline.Handler 即可)，文档见：https://www.sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/\n regionEngineOptionsList 配置：实例中的 regionId 的 startKey：01000000-endKey：23000000 根据什么来定义的，假设我一个 store 节点只部署 1-3 个 region，可以自定义上下界是吗，依据什么来定义？\n A：rheakv multi group 按照 range 分片，左闭右开，可以自定义，怎么定义取决于你对自己场景 key 分布的评估。\n yaml 配置中 regionEngineOptionsList.RegionEngineOptions 中的 serverAddress、initialServerList 等配置和外部与 regionEngineOptionsList 平级的 serverAddress 配置以及与 storeEngineOptions 平级的 initialServerList 是什么关系，谁覆盖谁？\n A：store 和 region 为1：n， region 包含在 store 中，store 的参数会 copy 传递到 region。\n jraft-example 展示，Rhea-kv 是客户端+服务端模式，其中 benchmark 使用分片集群部署模式，需要先同时使用 BenchmarkClient、BenchmarkServer 拉启后台服务，而后面的 rheakv 使用分节点配置和启动，如何区分二者的场景和使用姿势。\n A：rheakv 可以作为 client+server 部署，也可以单独作为 client 部署，通常你不想在每个节点提供服务但是还需要调用服务，那么就只 client 部署即可（配置的区别就在于是否配置了 StoreEngineOptions）。\n 本人项目使用 SOFAJRaft 场景是分布式单体服务快速便捷存储业务元数据，实现一致性访问。请问后台需要拉取这么多服务如何还能保证我的应用轻量快捷？另外，这些后台 jraft-kv 选举和存储服务启动后，是独立进程吗，整合到自己到项目中后，可否一个进程并且其服务生命周期随同我的母体应用的生命周期。\n A：SOFAJRaft 是一个 jar 包，是不是独立进程完全取决于你自己的意愿，都可以。\n 参考 jraft-example 实例，基于 rheakv 部署 multi group，加减 learnner 节点等，应该是以分组为单位操作，目前只看到 NodeOptions 中有 groupId 属性，多组时怎么配置和分别操作。\n A：这应该是两个问题。 问题1（groupId 多组如何配置）：在 rheakv 里，groupId 是 clusterName + ‘-’ regionId。 问题2（多组如何配置 learner）：目前没有很灵活，我们内部使用还是单独指定几台机器，上面的节点全部是 learner 节点，只要配置 initialServerList: 127.0.0.1:8181,127.0.0.1:8182,127.0.0.1:8183/learner 即所有 group 的 learner 都在 127.0.0.1:8183/learner 一个节点上，你的需求收到了，下个版本会增加每个 region 单独指定 learner，需要修改 RegionEngineOptions.initialServerList 在不为空的时候不被 StoreEngineOptions 的值覆盖即可。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 网络通信框架 SOFABolt 功能介绍及协议框架解析 | SOFAChannel#17 直播回顾 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.14.0，主要变更如下：\n 支持 Istio 1.5.x 版本； 升级了一些依赖库，如 FastHTTP、Dubbo-go、Tars； 支持 Maglev 负载均衡、支持 HostRewrite Header； 新增了一些 Metrics 输出与查询接口； 部分实现优化与 Bug 修复； 详细发布报告：https://mosn.io/zh/blog/releases/v0.14.0/\n同时，恭喜姚昌宇（@trainyao）成为 MOSN Committer，感谢他为 MOSN 社区所做的贡献。\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题：云原生网络代理 MOSN 的进化之路 分享嘉宾：王发康（毅松）蚂蚁集团 可信原生技术部 技术专家 背景介绍：网络通信代理 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，增强 MOSN 服务治理及流量控制能力，对接云原生周边组件，实现 MOSN 开箱即用，MOSN …","date":1593759600,"description":"【06/29-07/03】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200703/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6f65c94a70fdd3d222fb510cbec05abf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200703/","publishdate":"2020-07-03T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200703/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 版本发布以及社区活动预告、SOFABolt 直播回顾整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200703/","wordcount":1989},{"author":"丞一","categories":"SOFAChannel","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 大家好，我是本期 SOFAChannel 的分享讲师丞一，来自蚂蚁集团，是 SOFABolt 的开源负责人。今天我们来聊一下蚂蚁集团开源的网络通信框架 SOFABolt 的框架解析以及功能介绍。本期分享将从以下四个方面展开：\n SOFABolt 简介； 基础通信能力解析； 协议框架解析； 私有协议实现解析； SOFABolt 是什么 SOFABolt 产生背景 相信大家都知道 SOFAStack，SOFAStack(Scalable Open Financial Architecture Stack)是一套用于快速构建金融级云原生架构的中间件，也是在金融场景里锤炼出来的最佳实践。\nSOFABolt 则是 SOFAStack 中的网络通信框架，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架，他的名字 Bolt 取自迪士尼动画《闪电狗》。他一开始是怎么在蚂蚁集团内部产生的，我们可以类比一下 Netty 的产生原因：\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生； 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生； 这些年，在微服务与消息中间件在网络通信上，蚂蚁集团解决过很多问题、积累了很多经验并持续进行着优化和完善，我们把总结的解决方案沉淀到 SOFABolt 这个基础组件里并反馈到开源社区，希望能够让更多使用网络通信的场景受益。目前该组件已经运用在了蚂蚁集团中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n同时，已有数家企业在生产环境中使用了 SOFABolt，感谢大家的肯定，也希望 SOFABolt 可以给更多的企业带来实践价值。\n以上企业信息根据企业用户 Github 上反馈统计 — 截止 2020.06。\nSOFABolt：https://github.com/sofastack/sofa-bolt\nSOFABolt 框架组成 SOFABolt 整体可以分为三个部分：\n 基础通信能力（基于 Netty 高效的网络 IO 与线程模型、连接管理、超时控制）； 协议框架（命令与命令处理器、编解码处理器）； 私有协议实现（私有 RPC 通信协议的实现）； 下面，我们分别介绍一下 SOFABolt 每个部分的具体能力。\n基础通信能力 基础通信模型 如上图所示，SOFABolt 有多种通信模型，分别为：oneway、sync、future、callback。下面，我们介绍一下每个通信模型以及他们的使用场景。\n oneway：不关注结果，即客户端发起调用后不关注服务端返回的结果，适用于发起调用的一方不需要拿到请求的处理结果，或者说请求或处理结果可以丢失的场景； sync：同步调用，调用线程会被阻塞，直到拿到响应结果或者超时，是最常用的方式，适用于发起调用方需要同步等待响应的场景； future：异步调用，调用线程不会被阻塞，通过 future 获取调用结果时才会被阻塞，适用于需要并发调用的场景，比如调用多个服务端并等待所有结果返回后执行特定逻辑的场景； callback：异步调用，调用线程不会被阻塞，调用结果在 callback 线程中被处理，适用于高并发要求的场景； oneway 调用的场景非常明确，当调用方不需要拿到调用结果的时候就可以使用这种模式，但是当需要处理调用结果的时候，选择使用同步的 sync 还是使用异步的 future 和 callback？都是异步调用，又如何在 future、callback 两种模式中选择？\n显然同步能做的事情异步也能做，但是异步调用会涉及到线程上下文的切换、异步线程池的设置等等，较为复杂。如果你的场景比较简单，比如整个流程就一个调用并处理结果，那么建议使用同步的方式处理；如果整个过程需要分几个步骤执行，可以拆分不同的步骤异步执行，给耗时的操作分配更多的资源来提升系统整体的吞吐。\n在 future 和 callback 的选择中，callback 是更彻底的异步调用，future 适用于需要协调多个异步调用的场景。比如需要调用多个服务，并且根据多个服务端响应结果执行逻辑时，可以采用 future 的模式给多个服务发送请求，在统一对所有的 future 进行处理完成协同操作。\n超时控制机制 在上一部分的通信模型中，除了 oneway 之后，其他三种（sync、future、callback）都需要进行超时控制，因为用户需要在预期的时间内拿到结果。超时控制简单来说就是在用户发起调用后，在预期的时间内如果没有拿到服务端响应的结果，那么这次调用就超时了，需要让用户感知到超时，避免一直阻塞调用线程或者 callback 永远得不到执行。\n在通信框架中，超时控制必须要满足高效、准确的要求，因为通信框架是分布式系统的基础组件，一旦通信框架出现性能问题，那么上层系统的性能显然是无法提升的。超时控制的准确性也非常重要，比如用户预期一次调用最多只能执行3秒，因为超时控制不准确导致用户调用时线程被阻塞了4秒，这显然是不能接受的。\nSOFABolt 的超时控制采用了 Netty 中的 HashedWheelTimer，其原理如上图。假设一次 tick 表示100毫秒，那么上面的时间轮 tick 一轮表示800毫秒，如果需要在300毫秒后触发超时，那么这个超时任务会被放到\u0026amp;rsquo;2\u0026amp;rsquo;的 bucket 中，等到 tick 到\u0026amp;rsquo;2\u0026amp;rsquo;时则被触发。如果一个超时任务需要在900毫秒后触发，那么它会被放到如\u0026amp;rsquo;0\u0026amp;rsquo;的 bucket 中，并标记 task 的 remainingRounds=1，当第一次 tick 到\u0026amp;rsquo;0\u0026amp;rsquo;时发现 remainingRounds 不等于0，会对 remainingRounds 进行减1操作，当第二次 tick 到\u0026amp;rsquo;0\u0026amp;rsquo;，发现这个任务的 remainingRounds 是0，则触发这个任务。\n如果将时间轮的一次 tick 设置为1秒，ticksPerWheel 设置为60，那么就是现实时钟的秒针，走完一圈代表一分钟。如果一个任务需要再1分15秒后执行，就是标记为秒针走一轮之后指向第15格时触发。关于时间轮的原理推荐阅读下面这篇论文： 《Hashed and Hierarchical Timing Wheels: data structures to efficiently implement a timer facility》。\n快速失败机制 超时控制机制可以保证客户端的调用在一个预期时间之后一定会拿到一个响应，无论这个响应是由服务端返回的真实响应，还是触发了超时。如果因为某些原因导致客户端的调用超时了，而服务端在超时之后实际将响 …","date":1593694800,"description":"开源网络通信框架 SOFABolt 首次线上直播文字回顾。","dir":"blog/sofa-channel-17-retrospect/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9f88cb52dccf190278f16c9eab448644","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-17-retrospect/","publishdate":"2020-07-02T21:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-17-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播","tags":["SOFAChannel","SOFABolt"],"title":"网络通信框架 SOFABolt 功能介绍及协议框架解析 | SOFAChannel#17 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-17-retrospect/","wordcount":5457},{"author":"敖小剑","categories":"微服务","content":" 最近社区频繁出现的对微服务的各种质疑和反思的声音，甚至放弃微服务回归单体。本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Event/EDA 来走出微服务实践误区：从单体到微服务，却最后沦为分布式单体。\n 回顾：从单体到微服务到 Function 在过去几年间，微服务架构成为业界主流，很多公司开始采用微服务，并迁移原有的单体应用迁移到微服务架构。从架构上，微服务和单体最大的变化在于微服务架构下应用的粒度被“拆小”：将所有业务逻辑都在一起的单体应用，按照领域模型拆分为多个内聚而自治的“更小”的应用。而 Function 则在拆分上更进一步，拆分粒度变成了“单个操作”，基于 Function 逐渐演进出现 FaaS 形态和 Serverless 架构。\n在微服务和 Serverless 的喧嚣中，也逐渐出现了很多质疑和反对的声音：越来越多的人发现，当他们兴冲冲的迁移单体应用到微服务和 Serverless 架构之后，得到的收益并没有期望中的那么理想。最近，出现了对微服务的各种质疑、反思的声音，甚至放弃微服务回归单体。举例，我在 InfoQ 中国网站 简单搜索关键字“微服务”，前三页中就出现了如下的内容：\n 我们为什么停用微服务？ 这些公司为什么放弃微服务？ 什么？你的团队没有100人，那就不要用微服务了！ 致传统企业朋友：不够痛就别微服务，有坑 微服务带来的心理阴影 微服务到底该多大？如何设计微服务的粒度？ Uber 团队放弃微服务改用宏服务，网友评论炸锅了 为什么 Segment 从微服务回归单体 无论是支持还是反对微服务的声音，大多都是着眼于组织架构（康威定律，对应用和代码的 ownership）、微服务拆分（粒度大小，如何识别领域模型和业务边界）、分布式事务（跨多个微服务调用时维持一致性），工具（自动化构建、部署，可测试性，监控，分布式链路跟踪，CI/CD），数据库分离（避免多个微服务尤其是领域模型外的微服务共享数据库）等方面进行合理性分析和观点阐述，相信大家都对这些问题都有了解。\n而我今天的文章，将从另外一个角度来看待微服务（也包括 Serverless）实践中存在的误区——辛辛苦苦从单体走到微服务，却最后沦为分布式单体。\n分布式单体 “Distributed Monolith”，分布式单体，这真是一个悲伤的技术术语。而这偏偏是企业采用微服务后通常最容易踏进去的一个“陷阱”，事实上我看到的很多微服务落地最终都是以\u0026amp;rdquo;分布式单体\u0026amp;rdquo;收场，无法获得微服务的完整收益。\n问题源于微服务实施的方式 —— 按照业务逻辑拆解单体，划分为多个微服务，定义 API 接口，然后通过 REST 或者 RPC 进行远程调用，最终把这些微服务组合起来提供各种业务功能。简单说，就是在业务拆分的基础上，用进程间的远程调用简单替代原来进程内的方法调用。期间，对于原来使用的各种分布式能力，继续沿用之前的方式，简单说：方式不变，只是粒度变小。\n从方法论说这样做无可厚非，这也是微服务采用过程中非常标准的做法。但问题在于，止步于此是不够的 —— 至少存在两个有待继续努力改进的地方。\n分布式单体起因之一：通过共享库和网络客户端访问分布式能力 分布式能力的共享库和网络客户端是造成分布式单体问题的原因之一，关于这一点，来自 verizon 的 Mohamad Byan 在他的名为 Avoid the Distributed Monolith!! 的演讲中有详细的阐述，我这里援引他的图片和观点：\n上图是微服务体系的逻辑架构，由两部分组成：\n 内层架构（图上浅蓝色部分），是每个微服务的实现架构； 外层架构（图上黄色部分），是构建强大微服务架构所需要的各种能力，这里通常有大家熟悉的各种分布式能力； 特别提示：这里说的“网络客户端”是各种分布式能力的客户端，如服务注册发现/ MQ 中间件/ Redis 等 key-value 存储/数据库/监控日志追踪系统/安全体系等，不是服务间通讯如 RPC 的客户端。\n 而内层的微服务是通过 共享类库 和 网络客户端 来访问外层架构提供的分布式能力：\n分布式能力的 共享类库 和 网络客户端 会迫使内层微服务和外层架构的各种分布式能力之间产生强耦合，增加运维的复杂性（如升级困难造成版本碎片化），多语言受限于类库和网络客户端支持的语言，各种组件（如消息中间件）往往使用自定义数据格式和通讯协议 —— 所有这些迫使内层微服务不得不实质性受限于外层架构的技术选型。\n对于 Function，这个问题就更加明显了：Function 的粒度更小，更专注业务逻辑。某些简短的 Function 可能只有几百行代码，但是，为了让这几百行代码运转起来而需要引入的共享类库和网络客户端可能相比之下就规模惊人了。援引一张网上图片作为示意：\n分布式单体起因之二：简单用远程调用替代进程内方法调用 在微服务架构改造过程中，熟悉单体系统和架构的开发人员，习惯性的会将这些单体时代的知识和经验重用到新的微服务架构之中。其中最典型的做法就是：在遵循领域模型将现有单体应用按照业务边界拆分为多个微服务时，往往选择用 REST 或者 RPC 等远程调用方式简单替代原有的进程内方法调用。\n当两个逻辑上的业务模块存在协作需求时：\n从单体到微服务，直接方法调用被替换为远程调用（REST 或者 RPC），即使采用 Service Mesh 也只是在链路中多增加了 Sidecar 节点，并未改变远程调用的性质：\n这导致了前面所说的 “分布式单体”：\n 在微服务之前：应用程序由多个耦合在一起的模块组成，这些模块通过内存空间进行方法调用….. 在微服务之后：应用程序由多个耦合在一起的微服务组成，这些微服务通过网络进行远程调用….. 抛开调用方式的差异来看采用微服务前后的系统架构，会发现：两者几乎是完全一样的！！\n而微服务版本在某些情况下可能表现的更糟糕：因为调用方式更脆弱，因为网络远比内存不可靠。而我们将网络当成 “胶水” 来使用，试图把分散的业务逻辑模块（已经拆分为微服务）按照单体时代的同样方式简单粘在一起，这当然比单体在同一个进程内直接方法调用更加的不可靠。\n 关于这一点，在 \u0026amp;ldquo;The Eight Fallacies of Distributed Computing/分布式计算的8个谬论\u0026amp;rdquo; 一文中有详细阐述。\n 类似的，在采用 Function 时，如果依然沿用上面的方式，以单体或微服务架构的思维方式和设计模式来创建 FaaS/Serverless 架构：\n其本质不会发生变化 —— 不过是将微服务变成粒度更小的函数，导致系统中的远程调用数量大为增加：\n系统内的耦合并没有发生变化，Serverless 并不能改变微服务中存在的这个内部耦合问题：调用在哪里，则耦合就在哪里！只是把将组件的粒度从 “微服务“换成了 “Function/函数”。\n耦合的存在是源于系统不同组件之间的通讯模式，而不是实现通讯的技术。\n如果让两个组件通过“调用”（后面再展开讲何为调用）进行远程通信，那么不管调用是如何实现的，这两个组件都是紧密耦合。因此，当系统从单体到微服务到 Serverless，如果止步于简单的用远程调 …","date":1593414000,"description":"本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Event/EDA 来走出微服务实践误区：从单体到微服务，却最后沦为分布式单体。","dir":"blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","fuzzywordcount":9800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9ab906cecb82200b18dceb4ab43ba46a","permalink":"https://sofastack.github.io/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","publishdate":"2020-06-29T15:00:00+08:00","readingtime":20,"relpermalink":"/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","summary":"最近社区频繁出现的对微服务的各种质疑和反思的声音，甚至放弃微服务回归单体。本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Eve","tags":["微服务","分布式"],"title":"走出微服务误区：避免从单体到分布式单体","type":"blog","url":"/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","wordcount":9732},{"author":"王旭","categories":"镜像","content":" 众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知道，最初的 Docker = LXC + aufs，前者就是所谓的 Linux 容器了，而后者则是我今天要聊的镜像。\n 千禧年：惊艳的 Live CD 说到 Linux distro，除了做差异化的界面主题之外，核心差异一般都在于：\n 如何更方便地安装； 如何更方便地升级； 而在 distro 界却有一股清流，超脱于这两件事情之外，它们就是 Live CD，它们装在一张光盘里，或者是一个 U盘上，不需要安装、也不会改变。之前创业的时候，我司的运维大佬——彤哥曾经说过：\n 第一次见到 liveCD 时我内心是震惊的。。\n 这我当然是赞同的，那时我也是震惊的同学之一，要知道 Knoppix 在 2000 千禧年就来到了世界，而它所基于的著名的 Debian，直到2005年6月，Sarge (3.1) 发布的时候才正式在 stable release 里带上了图形界面的安装程序 debian-installer （简称 d-i），此前版本的安装还在用文本菜单。就在这个年代，这样一个开光盘即用、启动起来就是图形界面的系统，给我们这些玩家带来的震撼，当然是可想而知的。那时候的 Live CD 就是十三年后的 Docker，绝对配得上“惊艳”两个字。\n要知道，一张 700MB 左右的光盘里塞下个完整的操作系统并不容易（当然有人开头之后也不太难，后来我爱的 DSL 可以做到 50MB）。Knoppix 有个很棒的想法——把装好的操作系统给压缩一下，放在光盘里， 随用随解压，这样，一张 700MB 光盘里可以放下大约 2GB 的根文件系统，这样就跑 KDE 桌面也就没啥问题了，当是时，distrowatch.com 上可以看到，一大片 distro 都是基于 Knoppix 魔改的，足见其影响力。\n进化：可读写层与 UnionFS Knoppix 在诞生之初的一个执念是“绝不碰本地存储一根指头”，而光盘，CD-ROM，所使用的 ISO9600 文件系统也是只读的，这无疑暗合了当今流行的“不可变基础设施”的潮流，但是，即使在今天，没有可写文件系统对于很多 Linux 软件仍然是非常困难的，毕竟随随便便一个程序也要写一点配置文件、状态信息、锁、日志之类的嘛。而诞生之初的 Knoppix 是不可写的，那么，要有什么东西要罗盘，就得手工挖掘出本地硬盘来挂上，或者是挂个 NAS 到 /home 或其他挂载点上来，当你不想只是做个紧急启动盘的时候，这就有点麻烦了。\n如果我们从今天穿越回去，毫不费力就可以指出，用 overlayfs 加上一个 tmpfs 做可写层嘛。但是，overlayfs 要到2010年才首次提交 patchset，2014年才被合并到 3.18内核（这中间，当时的淘宝内核组也有不少贡献和踩坑呢）。当然，比 overlay 早的类似的 unionfs 还是有的，Docker 最早采用的 Aufs 就是其中之一，它是2006年出现的，这里 AUFS 的 A，可以理解成 Advanced，但它最早的意思实际是 Another——是的，“另一个 UFS”，而它的前身就是 UnionFS。\n在2005年5月，也就是十五年前，Knoppix 创造性地引入了 UnionFS，而在一年半以后的 5.1 版本中，Knoppix 引入了当年诞生的更稳定的 aufs，此后，包括大家熟悉的 Ubuntu LiveCD、Gentoo LiveCD 全都使用了 aufs。可以说，正是 Live CD 们，提前了8年，为 Docker 和 Docker Image 的诞生，做好了存储上的准备。\n这里简单说一句给不了解的人听，所谓 union fs，是指多个不同文件系统联合（堆叠）在一起，呈现为一个文件系统，它和一般的 FHS 规定的那种树装组织方式是不同的，如下图，对于左边的标准的目录树结构，任何一个文件系统，挂载在树上的一个挂载点，根据路径，就可以指到一个确定的文件系统，比如，下图中，所有的 /usr/local/ 下面的路径都在一个文件系统上，而其他 /usr 就会在另一个文件系统上；而 UnionFS 是多层堆叠的，你写的文件会停留在最上层，比如图中，你修改过的 /etc/passwd 就会在最上的可写层，其他的文件就要去下面的层中去找，也就是说，它允许同一个目录中的不同文件在不同层中，这样，Live CD 操作系统跑起来就像真正的本地操作系统一样可以读写所有路径了。\n块或文件：Cloop 与 SquashFS 让我们把目光放在只读层上，这一层是 Live CD 的基础，在 Live CD 还没有 union FS 来做分层的时候就已经存在这个只读 rootfs 了。对 Knoppix 来说，这一层是不能直接放完整、无压缩的操作系统的，因为在21世纪初，大家都还在用 24x 到 40x 速光驱的时代，Knoppix Live CD 面临的一个大问题是 700MB 的光盘和庞大的桌面操作系统之间的矛盾。\n开头我们提到了，Knoppix 的想法就是“把装好的操作系统给压缩一下，放在光盘里， 随用随解压”，这样精心选择后的 2GB 的 Distro 就可以压到一张光盘里了，不过“随用随解压“不是说有就有的，文件系统访问块设备，是要找到块的偏移量的，压缩了之后，这个偏移量就并不那么好找了，全解压到内存里再找偏移并不那么容易。\n回到2000年，那时候还是2.2内核，Knoppix 的作者 Klaus Knopper 在创立 Knoppix 之初就引入了一种压缩的(compressed) loop 设备，称为 cloop，这种设备是一种特殊的格式，它包含了一个索引，从而让解压缩的过程对用户来说是透明的，Knoppix 的 cloop 设备看起来就是一个大约 2GB 大的块设备，当应用读写一个偏移的数据的时候，它只需要根据索引解压缩对应的数据块，并返回数据给用户就可以了，无需全盘解压缩。\n尽管 Knoppix 把众多 distro 带上了 Live CD 的船，但是，众多后继者，诸如 arch、Debian、Fedora、Gentoo、Ubuntu 等等 distro 的 LiveCD，以及大家熟悉的路由器上玩的 OpenWrt，都并没有选择 cloop 文件，它们选择了和应用语义更接近的文件系统级的解决方案——Squashfs。Squashfs 压缩了文件、inode 和目录，并支持从 4K 到 1M 的压缩单元尺寸。同样，它也是根据索引按需解压的，和 cloop 的不同之处是，当用户访问一个文件的时候，它来根据索引解压相应的文件所在的块，而非再经过一层本地文件系统到压缩块的寻址，更加简单直接。事实上，Knoppix 里也一直有呼声想要切换到 squashfs，比如，2004年就有开发者在转换 knoppix 到squashfs 上，而且，一些测试数据似乎也表明 Squashfs 的性能似乎要更好一些，尤其在元数据操作方面。\n在 wiki 上是这么评价 cloop 的缺点的： …","date":1592895600,"description":"众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知道，最初的 Docker = LXC + aufs，前者就是所谓的 Linux 容器了，而后者则是今天要聊的镜像。","dir":"blog/twenty-years-of-image-format-from-Knoppix-to-OCI-Image-v2/","fuzzywordcount":6100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f918e4318b9157894559ba289b29553d","permalink":"https://sofastack.github.io/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","publishdate":"2020-06-23T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","summary":"众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知","tags":["镜像"],"title":"镜像格式二十年：从 Knoppix 到 OCI-Image-v2","type":"blog","url":"/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","wordcount":6095},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@雷霆 提问：\n 各位大佬 请问 TCC 拦截器这块为什么 xid 要先解绑，再绑定呢，这样做是有什么考虑吗？ A：执行 TCC 分支时，首先会解绑 xid，这是因为在 TCC 分支内，是不需要执行 AT 的 SQL 解析和自动补偿的（可以在 seata-rm-datasource 的 ExecuteTemplate 里看下实现），同时需要绑定下当前的拦截类型 TCC，这个拦截器类型在跨服务传递时也有特殊处理，建议也看下跨服务传递的源码。最后然后执行完 TCC 分支后的解绑、还原 xid 的操作，就是一个事务上下文的还原了。你目前看到的这个源码，后续我们还会优化下，更方便理解。这一系列操作是为了根据分支类型来区分分支事务的行为：AT 分支的行为是自动补偿，会走 SQL 解析和 undo 回滚，TCC 分支的行为是手动补偿，不会走 undo，而是执行用户自定义的 try 和 confirm。\n2、@taking 提问：\n 为何 TCC 模式的分支事务 commit 需要同步呢？\n A：因为如果异步 commit 会存在，退款的问题，如果没有 commit 那么事务没有完成，这时来了一笔退款交易，则原交易状态没有完成，会失败。当然也可以异步化，但是需要能够容忍一些反向交易的失败，或对反向交易做特殊处理。\n 如果 commit 被阻塞，退款请求也一样还是会失败吧？\n A：commit 被阻塞，说明支付还没有成功，前面不会发起退款的。\n 可以考虑在 LocalTCC 注解上加个属性表示是否允许异步执行。\n A：也可以的，然后在反向交易时需要能判断这个正交易是否已经完成，没有完成，触发一次事务恢复，进行 commit，然后再执行反交易。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服智能监控云原生可观测大盘设计概览 再启程，Service Mesh 前路虽长，尤可期许 蚂蚁金服在 Service Mesh 监控落地经验分享 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFAJRaft v1.3.2 版本，主要变更如下：\n 抽象出网络通信层，增加 GRPC 实现并支持 Replication Pipeline，用户亦可自行对通信层进行其他实现的扩展； RheaKV 增加 reverseScan API ； 提供 Replicator 与 RPC 的线程池隔离，避免相互影响； read-index 线性一致读请求提供请求超时（timeout）配置； 几个 corner case 修复，比如 replicate logs 如果比 appliedIndex（follower）更小，那么可以认为是成功的； 致谢（排名不分先后） @shibd 、@SteNicholas 、@killme2008 、@zongtanghu 详细发布报告： https://github.com/sofastack/sofa-jraft/releases/tag/1.3.2\n2、发布 Occlum v0.13.0 版本，主要变更如下：\n 扩展了Occlum.json的配置格式，更强大，更易读； 增加了3个新的系统调用； 增强了编程语言支持：支持了 Rust、改进了 Python 和 Go 的 demo； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.13.0\n社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1592550000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200619/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4b795b006dbfdc77ff65a693f80f1e6c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200619/","publishdate":"2020-06-19T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200619/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft、Occlum 发布、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200619/","wordcount":1726},{"author":"申尘","categories":"智能监控","content":" 背景 蚂蚁金服业务自定义监控是蚂蚁金服监控产品中的一个重要功能，主要是通过自定义日志数据源并配置大盘的方式来解决蚂蚁金服业务实时监控的需求。在产品功能上，用户可以通过对一系列日志数据源的创建、组织、管理及表单配置化的方式，简单、快速组织出一个多维监控大盘。这项能力在当时是一个具有创新性的能力，从功能到产品体验上很好解决了当时蚂蚁金服复杂业务监控的痛点。\n但是，随着蚂蚁金服监控产品的不断迭代更新，以及云原生可观测性对于监控大盘的高要求，大家对自定义监控的体验诉求也越来越多，包括更便捷的交互方式、更丰富的图表、更丰富的数据源、更多扩展点等，因此对监控大盘的升级也势在必行。\n本文将介绍蚂蚁金服监控产品在监控大盘方面的创新设计与尝试，新版自定义监控大盘 Barad-Dur 目标成为业界体验最优秀的自定义监控大盘，在交互、体验与设计理念上有诸多创新点，同时将以模块的形式发布，支持二次开发，可以同时为蚂蚁金服内外监控系统服务。\n产品体验 WYSIWYG 当前优秀的监控大盘产品都标配一个“所见即所得（WYSIWYG）”编辑器，这方面能力是蚂蚁金服监控产品一直缺失的。在蚂蚁金服监控产品中配置大盘还是通过传统的表单方式，对用户非常不友好、学习曲线陡峭、配置效率不高。导致用户经常将配置大盘作为一项需求提给监控团队，由监控团队的“大盘配置专家”来进行配置，不仅存在较高的沟通成本，也给监控团队增加了很大的负担。\n在新版监控大盘 Barad-Dur 中，对 WYSIWYG 编辑器的交互体验进行了大量工作，力求做到市面上最优秀的编辑体验。\n体验1：缩放 Barad-Dur 的缩放是可以在四周以及四角上进行的，而市面上常见的大盘产品只支持右下角的缩放。由于坐标系统一般采用的是 (left, top, width, height) 来定义一个矩形，最容易实现的就是右下角缩放，只需要变动 width 和 height 两个参数即可。最难实现的是左上角的缩放，四个参数需要同时变动，且关系比较复杂。特别是在引入网格布局后，缩放时要自动“吸附”临近的网格点，难上加难。\n体验2：拖动 Barad-Dur 的图表拖动可以实现图表位置的一步交换，而市面上常见的大盘产品需要进行多次拖动才能实现两个图表的交换。且在拖动过程中，图表的整体布局会被打乱，而 Barad-Dur 不会存在这样的问题。\n体验3：自动重布局 Barad-Dur 的自动重布局功能非常强大，可以支持实时布局预览（当然市面上常见的大盘产品也支持），同时大盘的布局调整会根据具体操作（缩放、拖动）的方向进行。而市面上常见的大盘产品只能在垂直方向上进行布局调整，因为所用的算法非常简单，只是粗暴地把所有图表向页面上“推”。\n体验4：任意位置 Barad-Dur 的布局支持图表在任意位置摆放，而市面上常见的大盘产品由于上述的简陋算法，不支持此功能，所有的图表必须堆叠在页面的顶部。\n体验5：布局复位 Barad-Dur 的自动重布局能够在对单个图表进行调整时将其他图表“推开”，然后更强大的是可以再将被推开的图表复位。这里找到了市面上常见的大盘产品直接拿来用的开源布局框架进行对比。该框架其实提供了上述的任意位置功能，然而由于没有布局复位的功能，导致该功能一旦启用，会令整个大盘在编辑过程中布局被扰乱，对用户起不到任何帮助，所以市面上常见的大盘产品没有启用这个功能。\n体验6：文字编辑 Barad-Dur 支持在大盘中添加静态文字以及对于文字的编辑。静态文字可用于公告、标题、说明等一些常见的大盘场景。\n功能对比 Barad-Dur 市面上常见的大盘产品 任意拖动 ✔︎ ✔︎ 任意缩放 ✔︎ ✘ 多样图表 ✔︎ ✔︎ 图表实时编辑 ✔︎ ✔︎ 图表导入导出 ✔︎ ✔︎ 任意布局 ✔︎ ✘ 添加文字 ✔︎ ✘ 综上对比，可以看出 Barad-Dur 的 WYSIWYG 编辑器在各项功能上已经领先于市面上常见的大盘产品。\n控制器 大盘，即 Dashboard (in an automobile or similar vehicle) a panel beneath the front window having various gauges and accessories for the use of the driver; instrument panel。其本意是指汽车上的仪表板，这里的仪表板包括了两类组成部分：监视器、控制器。在仪表板上不仅能看到汽车的当前状态，也能对汽车进行各种控制。这是大盘的本意，但是就目前看来，市面上所有的监控大盘产品都缺失了控制器这个重要的组成部分，导致监控大盘其实只是监视大盘。如果只是用来监视的，那大盘独立存在就没有意义，就像汽车的仪表板上只有转速表、时速表、里程表，却没有油门、刹车、换挡杆。\n我们再来看几个工业产品的大盘：\n面向普通消费者的量产产品\n面向专业消费者的量产产品\n面向专家的定制产品\n控制器是不可或缺的组成部分，甚至比监视器更加重要。Barad-Dur 提供了在大盘中设置控制按钮的功能，可以实现一些简单的控制，比如关闭/启动报警、打开钉钉聊天窗口、启动控制预案等。日后会不断加入更加强大的控制功能，让蚂蚁金服监控大盘变成一个完整的监控系统。\n技术实现 自定义数据源 上文提到 Barad-Dur 支持二次开发，支持自定义数据源，仅需一点点工作即可接入自己的数据源：\n 继承 AbstractDatasource，并实现 doRequestData 接口； 调用 registerDatasource 将数据源注册至 Barad-Dur（如果使用 Barad-Dur 的数据源编辑器，可在注册时指定自定义的数据源的编辑器）； Barad-Dur 会对所有的数据源进行包装，提供缓存、增量加载、请求合并等功能。\n统一时序数据源 为了实现自定义数据源能够在任意图表中正确展现，Barad-Dur 定义了一种 universal 的时序数据格式，支持多 key 以及多 value。所有的时序数据源（以后可能会支持非时序数据源）都会将查询结果转换为这种格式，所有的图表也都会使用这种数据格式进行展现。\n使用统一数据格式的优势在于，图表和数据源都是按照同样的数据接口（约定）来实现的，所以图表和数据源是可以独立变化的。即图表可以任意切换而不需要改动数据源配置，数据源也可以任意切换而不需要调整图表配置。这是市面上常见的大盘产品做不到的。\n另一大优势在于计算。Barad-Dur 支持数据源的简单前端计算（如计算比率的场景需要将数据 A 与数据 B 相除），在使用了统一的数据格式之后，将计算也视为一个时序数据源，它的输入是一组时序数据源，也就是说一个计算数据源可以引用另一个计算数据源。这也是市面上常见的大盘产品做不到的。\nScene Graph Scene Graph 的概念常用于游戏引擎对于场景的渲染。由于场景中各个节点有父子关系且子节点的空间关系常常用相对于父节点的量来表示，所以需要一种数据结构来将这些 local 空间的量（translation、rotation）转变为 global 空间的量，才能最终转换成屏幕空间的量用于渲染。 …","date":1592463600,"description":"本文将介绍蚂蚁金服监控产品在监控大盘方面的创新设计与尝试。","dir":"blog/antfin-monitoring-cloud-native-observable-market-design-overview/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"30e37e5824f0c80a9aef838c5db03a3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","publishdate":"2020-06-18T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","summary":"背景 蚂蚁金服业务自定义监控是蚂蚁金服监控产品中的一个重要功能，主要是通过自定义日志数据源并配置大盘的方式来解决蚂蚁金服业务实时监控的需求。在","tags":["智能监控"],"title":"蚂蚁金服智能监控云原生可观测大盘设计概览","type":"blog","url":"/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","wordcount":3490},{"author":"涵畅","categories":"Service Mesh","content":" 前言 几乎所有人都在说 Service Mesh；貌似没人知道怎么落地 Service Mesh；但是大家都觉得其他人在大力做 Service Mesh；所以大家都宣称自己在做 Service Mesh。\n上面只是开一个玩笑，但是从某种程度反映了一些实际情况：Service Mesh 是一种设计思想和理念，而不是具体的架构或者实现方式，虽然 Istio+Envoy 的配置似乎已经成了事实标准，当我们环顾四周，却发现理想太丰满，现实太骨感，因为各企业当前切实原因，导致各种形态的 Service Mesh 百花齐放。\n蚂蚁金服的 Service Mesh 就属于上面提到的百花齐放中的一员，我们已经渡过探索期，全面进入生产应用。去年的双十一完成了交易支付核心链路，几十万容器规模的生产级验证。但是业界对于 Service Mesh 仍然有很多种不同的声音，一方面是众星捧月式的支持，另一方面是困惑和质疑，包括对价值、架构以及性能的质疑。那么我们对此是什么态度？双十一深度实践之后蚂蚁金服的 Service Mesh 路又在何方？Service Mesh 架构是终点吗？\n本文将结合蚂蚁金服内部实际场景以及思考，讲述继 2019 双十一之后，蚂蚁金服在 Service Mesh 路上的规划和持续演进。\n蚂蚁金服 Service Mesh 实践回顾 上图是 2019 年蚂蚁金服双十一的实践架构，云原生网络代理 MOSN（https://github.com/mosn）作为蚂蚁金服自研数据面产品，承载了 Mesh 架构的东西向流量。对于控制平面，基于务实的前提我们探索出一套当前阶段切实可行的方案，基于传统服务发现体系落地了 Service Mesh 架构。\n这里是数据化的落地总结，在满足业务的同时，我们真正做到了对业务的低侵入：极低的资源消耗以及快速迭代能力，业务和基础技术都享受到云原生 Mesh 化所带来的红利。\nService Mesh 前路漫漫 我们再来看看 InfoQ 发布的 2020 年 4 月份 Software Architecture and Design 趋势报告，Service Mesh 目前处于 Early Adoption 代，在云原生技术圈仍处于大热阶段，各种技术论坛我们都能见到 Mesh 架构的专场，本篇文章我们不过多讨论 Service Mesh 的选型、使用场景、合理性等等问题，需要的同学可以参考一下文末历史文章，有很多蚂蚁金服对 Service Mesh 的思考。\n对于我们来说，既然在深度思考后选择了这条路，并且在去年双十一进行了深度实践，那么棋到中盘，下一步应该如何落子，除了务实落地之外，我们还要仰望星空，必须知道离诗和远方还有哪些 Gap：\n非全面云原生 前面提到我们落地 Service Mesh 时，仍然采用了传统微服务体系，虽然整体架构基于 K8s，但在控制面上并没有采用社区的方案，当然这些是有考虑的，但是随着整体架构的演进，非全面云原生化势必会成为我们持续享受云原生红利的最大障碍。\n平台能力不足 Service Mesh 的定位是解耦基础设施与业务，但是目前看来，不管是社区 Istio+Envoy 的组合，还是蚂蚁金服传统微服务+MOSN 的实践，均是把东西流量的治理作为了重点，离诗和远方还有很长的路。目前还有大量的基础设施逻辑作为 SDK 镶嵌在业务系统中，我们仍然要面临基础设施升级对业务带来的影响。\n边界流量覆盖不全 随着云原生在数据中心内部愈演愈烈，但是对于数据中心边界以及边缘网络，七层应用网络流量仍然没有形成一个全局体系，由于体系的缺失我们不得不在边界网关与 Mesh 网络两者之间各自分裂发展，均有独立的流量调度体系以及安全可信体系。\n生态融合度低 传统服务体系发展了这么多年，积累了大量宝贵的财富，Service Mesh 作为新贵出现，从两个方面来说：Service Mesh 需要传统服务体系的融入支撑，才能使现有业务迁移到 Mesh 体系；同时传统服务体系的组件也需要有和 Mesh 体系融合的能力才能持续保持竞争力。\n性能 性能是一个老生常谈的问题，Mesh 架构中质疑性能的声音也层出不穷 ，包括 Mixer 控制面，还有引入 Sidecar 造成的额外网络消耗、编解码消耗等等。不过我们可以看到社区一直在解决这些问题，包括对 Mixer 架构的重构，引入 ebpf 来加速流量劫持等等。\n综上所述，我们在 Service Mesh 上任重道远。\n将 Service Mesh 进行到底 今年我们的目标是 Mesh 全面覆盖主要业务，这将面临非常大的挑战：\n 金融级安全可信的要求，需要我们做到全链路加密与服务鉴权； 统一 Sidecar 与 Ingress Web Server； 云原生控制面的落地； 透明劫持能力； 需要承载更多的中间件能力下沉； 上面分析了目前存在的各种问题，同时结合蚂蚁金服自身的业务发展需求，那么我们可以很清晰的对症下药了，我们将上述问题抽象成三类，并进行专项攻坚：\n 以开源生态建设，来应对生态融合问题； 通过云原生标准演进，来解决非全面云原生问题； 最后通过基础核心能力增强，来治理平台能力，覆盖场景以及性能的不足的问题； 开源生态建设 我们再来回顾一下双十一之后我们做的第一个动作：在 2019 年 12 月 28 日由蚂蚁金服主办的第九期 Service Mesh Meetup 上，我们对外宣布了 MOSN 完成在 SOFAStack 的孵化，开始独立运营，以更加开放的姿态寻求合作共建伙伴：\n我们认为，未来会更多地属于那些告别大教堂、拥抱集市的人们。《大教堂与集市》\n在宣布独立运营的同时，我们也做了一系列措施：\n 独立的项目域名：mosn.io 项目地址：github.com/mosn/mosn 社区组织：MOSN Community Organization 项目管理条例：PMC、Committer 选举晋升机制等等 接下来，开源社区我们也持续做了非常多的事情，包括专题 Working Group的创建，例如 Isito WG， Dubbo WG 等等。\n同时也寻求了非常多的外部合作，超过一半的 contributor 均来自外部，接受了第一个来自 BOSS 直聘的 Committer 等等，针对生态融合，我们同Skywalking，Sentinel和Dubbo-go社区进行了深度合作。\nSkywalking 调用依赖以及服务与服务之间的调用状态，是微服务管理中一个重要指标。Skywalking 是该领域非常优秀的一款 APM 软件，MOSN 与 Skywalking 社区展开了合作，进行了两个系统的深度整合工作，目前支持：\n 调用链路拓扑展示； QPS 监控； 细粒度 RT 展示； 在今年五月份，SkyWalking 8.0 版本进行了一次全面升级，采用新的探针协议和分析逻辑，探针将更具互感知能力，更好的在 Service Mesh 下使用探针进行监控。同时，SkyWalking 将开放之前仅存在于内核中的 Metrics 指标分析体系。Prmoetheus、Spring Cloud Sleuth、Zabbix …","date":1592298000,"description":"本文将结合蚂蚁金服内部实际场景以及思考，讲述继 2019 双十一之后，蚂蚁金服在 Service Mesh 路上的规划和持续演进。","dir":"blog/service-mesh-the-road-ahead-long/","fuzzywordcount":7300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"81941474b0c2d163a199a461aaa3f2f3","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-the-road-ahead-long/","publishdate":"2020-06-16T17:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/service-mesh-the-road-ahead-long/","summary":"前言 几乎所有人都在说 Service Mesh；貌似没人知道怎么落地 Service Mesh；但是大家都觉得其他人在大力做 Service Mesh；所以大家都宣称自己在做 Service Mesh。 上","tags":["Service Mesh","源创会"],"title":"再启程，Service Mesh 前路虽长，尤可期许","type":"blog","url":"/sofastack.tech/blog/service-mesh-the-road-ahead-long/","wordcount":7212},{"author":"霄鸿","categories":"Service Mesh","content":" 引言 Service Mesh 是目前社区最为炙手可热的技术方向，去年双11在蚂蚁金服得到全面的应用，并平稳顺滑的支撑了大促服务。作为目前规模最大的 Service Mesh 集群，本文从监控的领域对 Service Mesh 落地进行经验总结，主要从以下几方面进行介绍：\n 云原生监控，介绍蚂蚁金服 Metrics 监控的落地； 用户视角分析，介绍从应用 owner 的角度对这一基础服务设施的体验以及 SRE 从全站服务的稳定性对监控提出的要求； 未来的思考，介绍后续发展方向； 云原生监控 云原生应用的设计理念已经被越来越多的开发者接受与认可，今年蚂蚁金服应用服务全面云原生化，对我们监控服务提出更高的要求。目前 Metrics 指标监控服务也逐渐形成体系，如下图所示基于社区原生 Prometheus 采集方案在蚂蚁金服监控场景下落地。\n怎么采集 蚂蚁金服监控采集 AGENT 是部署在物理机上，支持多个采集插件，如下图，包括执行命令、日志、HTTP 请求、动态 SQL 采集、系统指标采集、JVM 采集以及进程监控等，同时支持多个解析插件自定义解析、单行文本解析、Lua 脚本解析、JSON 解析以及 Prometheus 解析等。\n在Service Mesh 监控落地中，业务方参考业界标准输出 Metrics 指标数据，监控采集该物理机不同 Pod、App 和 Sidecar 的各项指标，包含 Metrics 指标和系统服务指标（CPU、MEM、DISK、JVM、IO 等），然后计算清洗集群节点通过拉取最近周期数据进行数据汇总、groupby 等，数据采集周期又分为：5秒级数据和分钟级数据。 对于 Service Mesh 来说，主要关注的指标有系统指标和 Metrics 指标：\n 系统指标（包括 Pod、App 和 MOSN 等 Sidecar 多个维度的系统指标）： 系统指标, 包含 CPU、LOAD、MEM、BYTES、TCP、UCP 等信息； 磁盘，包含分区可用空间、使用率等信息； IO，包含 IOPS 等信息； Metrics 指标： PROCESSOR，包含 MOSN 进程打开的 fd 数量、申请的虚拟内存大小等进程资源信息； GO，包含 MOSN 进程 goroutine 数量(G)、thread 数量(M)以及 memstats 等 go runtime 信息； Downstream，包含全局下游累计建链数、总读取字节数、累计请求数、请求耗时等； Upstream，包含上游请求失败次数、集群累计建链数、累计断链数、异常断链次数、上游请求平均耗时等； MQ Mesh，包含发送消息总数、耗时、失败数等以及消费消息总数、耗时、失败数等； Gateway Mesh，包含 qps、rt、限流以及多维度的成功数和失败数等； 数据计算 对于 Agent 采集的数据需要从不同维度向上汇聚，满足不同用户对不同视角（LDC、IDC、APP、架构域、站点等视角）的数据需求，以适配蚂蚁金服运维架构体系。\n此时对于这么大规模的数据体系，我们团队建设蚂蚁金服统一的监控数据计算平台。\n 使用统一的监控数据标准、插件化的数据采集接入、通用的数据服务 API 服务来帮助不同的监控产品的快速迭代； 建立一套健全的数据质量体系、高可用计算集群来保障监控数据质量； 通过类 SQL 任务定义、自定义计算任务、插件化来提供丰富、开放的数据分析能力，来满足技术风险业务领域下各种复杂数据分析的需求； 其中计算任务调度（spark）执行的关键组件包括 GS(Global-Scheduler 全局图调度)和 CS (Compute-Space 计算空间)。\nGS 是平台的任务调度中心，如下图所示，它收集了所有业务的数据源配置，根据数据源之间的计算关系，构建出全局计算任务拓扑模型(GlobalGraph)。再根据不同的任务执行策略，将全局任务拓扑图切割成小范围的任务拓扑(Graph)。主要特性有：\n GS 根据任务优先级、资源质量、负载情况等策略，将 Graph 分发到不同的计算空间进行计算(Cspace)； 同一个 Graph 内部的数据依赖是计算过程中直接依赖的； 不同的 Graph 之间的数据依赖会通过存储进行数据解耦； GS 会管理所有 Graph 及计算节点的任务状态，根据 Graph 的依赖关系和依赖 Graph 的执行状态，控制 Graph 的执行时间； CS 是计算平台抽象的计算任务执行空间，如下图所示，主要负责 Graph 的解析和具体计算任务的提交执行，适用于不同的计算引擎，如 Spark/Flink。以 Spark 为例，CS 接收到 GS 发出的 GraphTask，根据 GraphTask 中的 Node(Transform) 解析成 Spark 的 Transfomation 算子和 Action 算子，组成计算 DAG 并提交到 Spark 集群执行。\n在任务执行过程中，CS 会向 GS 同步各任务的执行状态，用于任务跟踪监控。\n多个 CSpace 组成一个 CSpaceGroup，CSpace 之间可以根据负载均衡、资源等级、蓝绿发布等具体场景划分不同的计算分组，多个 CSpace 之间的任务切流可以满足负载均衡、资源隔离、蓝绿发布、灰度等高可用的要求。\n规模化问题 对于蚂蚁金服这么大规模的 Service Mesh 集群数据，产品请求无法都通过 PromQL 方式实时查询结果，以及报警及时通知。此时我们对于监控数据进行分类，其中应用、机房、站点等维度数据进行预计算聚合，例如不同机房的 QPS、RPC 转发成功量、Error 错误等等，前端通过自定义配置出自己关注的大盘视图。\n其中今年大促 MOSN 容器达到几十万，在频繁的发布部署，上线下线过程中，对监控查看的实时性提出更高的要求。其中 Meta 元数据模块对接 K8s 集群，部署监控 operator 监控容器状态变化，达到秒级将最新采集配置通过 Agent registry 更新到 Agent 模块。\n大促保障 我们一方面对监控高可用进行保障，做到采集计算水平扩缩容，另一方面对容量进行评估，通过对不同任务进行分级处理，在大促的时候对高优先级任务进行重点保障，对低优先级任务和业务方进行沟通做降级处理。这样在监控计算资源紧张的情况下，保障核心数据稳定。\n产品视角 Service Mesh 是蚂蚁金服内部应用服务所使用的基础服务设施，对不同的用户看的视角不一样。在监控产品上，用户对产品的使用主要集中在“配、看、用”数据这三个层面。我们早期也做过类似的用户分析。在蚂蚁金服按使用方式将用户分为全局关注者，产品 owner、SRE、领域专家和普通用户等，这里监控产品对于 Service Mesh 也提供不同的视角满足不同的用户需求，举例来说：\n 产品 Owner 视角：特指 MOSN 产品的开发们，他们重点负责 MOSN 的监控指标数据覆盖、数据准确性以及重点调优目标； 普通用户视角：特指应用 Owner，应用 Owner 主要看 MOSN 服务对应用 RPC 调用的影响以及该应用使用 MOSN 服务带来的效率提升； SRE 视角：他们 …","date":1592204400,"description":"作为目前规模最大的 Service Mesh 集群，本文从监控的领域对 Service Mesh 落地进行经验总结","dir":"blog/antfin-service-mesh-monitor-landing-experience/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5728ecea53b7505a29fdd8d498a8f111","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","publishdate":"2020-06-15T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","summary":"引言 Service Mesh 是目前社区最为炙手可热的技术方向，去年双11在蚂蚁金服得到全面的应用，并平稳顺滑的支撑了大促服务。作为目前规模最大的 Service Mesh 集群，本文从","tags":["Service Mesh","智能运维"],"title":"蚂蚁金服在 Service Mesh 监控落地经验总结","type":"blog","url":"/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","wordcount":3749},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 这里有个机会和 SOFAStack 一起玩，你要不要来？ 阿里巴巴编程之夏（Alibaba Summer of Code，以下简称 ASoC）是面向全球18岁及以上本科、硕士、博士高校学生的编程普惠计划，鼓励高校学生深度参与开源开发活动，以第一视角感受开源世界的魅力，成为开源社区新鲜“血液”。\n今年 SOFAStack 开源社区也加入了选题，有兴趣的同学可以尝试下以下 feature：\nSOFAJRaft\n是基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用。\n Feature1:当前 LogStorage 的实现，采用 index 与 data 分离的设计，我们将 key 和 value 的 offset 作为索引写入 rocksdb，同时日志条目（data）写入 Segnemt Log，因为使用 SOFAJRaft 的用户经常也使用了不同版本的 rocksdb，这就要求用户不得不更换自己的 rocksdb 版本来适应 SOFAJRaft， 所以我们希望做一个改进：移除对 rocksdb 的依赖，构建出一个纯 java 实现的索引模块。这个 feature 难度适中，https://github.com/sofastack/sofa-jraft/issues/453\n Feature2:这个 feature 更有挑战些，在 multi raft group 场景中，可能有多个 raft node 在同一个进程中并且很多都是 leader，当他们各自向自己的 followers 发送心跳时会过多的消耗 CPU 和网络 IO。例如我们可以在同一个进程内共享心跳计时器并将这些 leaders 发往同一台机器的心跳请求合并起来发送出去，以此来减少系统消耗，当然你还可以提供更多的优化方案。欢迎尝试 https://github.com/sofastack/sofa-jraft/issues/454\n SOFABolt\n是基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，我们把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。\n Feature：当前的SOFABolt实现中私有协议是直接和整体框架耦合在一起的，在使用SOFABolt的同时需要使用提供的私有协议，当用户希望使用自己的自定义协议时需要进行比较有挑战的代码拓展才能实现。因此我们希望对SOFABolt的协议框架做一些重构以支持快速方便的集成用户的自定义协议。这个 feature 稍有难度，欢迎尝试，https://github.com/sofastack/sofa-bolt/issues/224 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明詹 提问：\n 问下 SOFATracer 现在支持 RabbitMQ 吗？\n A：原生 RabbitMQ API ，Tracer 是没有埋点的；如果和 Spring 集成的，可以基于 Spring Message 方式埋点。使用最新版本即可。 SOFATracer：https://github.com/sofastack/sofa-tracer\n2、@雷霆 提问：\n 请问一下，如果 TCC 在提交全局事务时失败了，比如网络或者 TC 服务异常，导致 TC 压根没有收到全局事务提交的通知，此时 TM 会抛一个异常，导致整个业务处理失败，这个时候已经在一阶段冻结的资源还会回滚吗？看了 Seata 源码，对于这种情况没有看到有触发回滚的操作。\n A：TCC 先注册分支再执行 Try，如果注册分支失败那么 Try 不会执行，如果注册分支成功了 Try 方法失败了，那应该抛出异常触发主动回滚或者触发 Server 超时回滚。\n 那如果分支已经注册成功，且 Try 也执行成功了，就是在 TM 向 TC 发起 global commit 时失败了，TM 多次重试失败后抛了异常，TC 没有收到 commit，这种情况下还会有 rollback 吗？\n A：这种情况触发超时回滚，TC 主动来回滚超时的事务。\n 明白了 谢谢~\n Seata：https://github.com/seata/seata\n本周推荐阅读 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 Forrester 中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求 社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1591945200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200612/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a85bdf92bd596c0809df4b4464b8a85b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200612/","publishdate":"2020-06-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200612/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 绝妙的机会与 SOFAStack 一起玩、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200612/","wordcount":2201},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析\n 活动时间：7 月 2 日周四晚 7 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#16：不得不说的云原生隔离性 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。本期分享将介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1265\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 不得不说的云原生隔离性 丞一 SOFABolt 开源负责人\n你将收获 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 嘉宾 SOFAGirl 主持人 丞一 SOFABolt 开源负责人 ","date":1591945200,"description":"7 月 2 日周四晚 7 点，线上直播第 17 期。","dir":"activities/sofa-channel-17/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6b021a35ee168e2bc4cb3350c6828d68","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-17/","publishdate":"2020-06-12T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-17/","summary":"概要 活动主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 活动时间：7 月 2 日周四晚 7 点 活动形式：线上直播 报名方式：戳","tags":["SOFAChannel","SOFABolt"],"title":"SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-17/","wordcount":574},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" 6月9日，在2020阿里云线上峰会上，蚂蚁联合全球知名市场研究与咨询机构 Forrester 发布《蚂蚁 SOFAStack 总体经济影响报告——金融级云原生市场趋势以及云原生平台带来的成本节省和业务优势》（以下简称“白皮书”）。《白皮书》指出，随着云计算在各行各业的落地不断深化，被技术赋能的企业早已加速构建企业级平台，通过推进数字化转型来塑造可持续的竞争力。其中云平台使能新型基础设施，赋能数字商业模式，成为了社会经济新旧动能转换和信息化应用创新发展的重要数字底座。\n云原生技术已趋向成熟 为金融企业带来全新业务价值与技术优势 Forrester 首席分析师戴鲲表示，越来越多的企业正在借助以云计算为代表的数字技术的巨大潜力，不断提供数字化的客户体验，改进卓越运营能力，加速数字创新进程，构建和扩展数字生态体系，从而加速数字化转型来塑造可持续的竞争力。\n他指出，尤其是一些积极采用新兴技术的泛金融企业，更在加速构建企业级云平台，取得了显著的早期业务成果。而伴随着在应用基础设施、应用软件架构、开发模式与部署架构四个层面协同进化与趋向成熟，云原生技术已为包括金融行业在内的各行各业的企业与机构带来了全新的业务价值与技术优势，具体表现在：\n应用基础设施 从物理机和虚拟机向大规模容器集群进化 容器技术可以实现更高密度的宿主机部署能力和伸缩性，提供更好的性能、更低的空间占用率以及更高的资源利用率，可以实现基础架构的自动化与高效率，帮助金融企业更好地满足大规模互联网业务的动态工作负载支撑要求，从而为客户获得一致的差异化体验提供有效保障。\n应用软件架构 从集中式单体和多层架构向分布式微服务架构进化 微服务框架进一步增强了应用架构伸缩性，通过模块化的复用能力与渐进式的变更能力加速应用价值交付；服务网格为微服务应用带来更为强大的服务间网络连接、可见性和安全性；无服务器计算以全新的编程模型实现应用松耦合和自动伸缩性，有效屏蔽基础架构的复杂性；而边缘计算与物联网技术的发展也使得企业计算架构从中心化向分布式演进，加速洞察的获得与决策反馈的闭环。\n开发模式 从瀑布式和敏捷式向 DevOps 进化 容器技术可以提供良好定义、一致的、高度可迁移的应用软件包，帮助改善开发和运营团队之间的协作过程。而微服务架构的细粒度可重用模块化特性可以帮助技术部门通过技术组件与业务服务的动态组装，通过与持续集成和持续交付流水线的有效集成，实现面向 DevOps 的软件交付，从而加速企业创新进程，有效提升市场响应效率，迅速满足企业内部不同业务部门与区域环境的差异化客户与业务需求。\n运营模式 从单一云环境向混合私有云与公有云的多云环境进化 根据 Forrester 的研究，面向多云、混合云环境的云平台管理能力已经成为了中国乃至全球企业的常态化需求。企业不仅需要在基础架构层面实现跨集群发布部署和跨云平台管控，而且需要具备面向异构资源的一体化管理能力，包括虚机与容器集群的混合管控、经典多层架构与微服务架构的混合支持、传统开发框架与包括大数据和机器学习等在内的新兴技术框架混合使能等。\n如何借助合作伙伴力量 以平台化方式构建金融级云原生能力？ 在迈向云原生的路上，新兴技术带来战略业务价值的同时，也必然引入更多的不确定性。一方面云原生技术依然处在快速演进阶段，距离金融行业所需要的在云端运行关键任务系统的金融级特性仍存在显著差距，另一方面，云原生技术本身在应用架构、开发测试部署过程、应用重构与迁移路径以及系统运维等各个领域都具有技术和管理复杂性。\n戴鲲指出，金融机构在云原生技术的落地实践过程中，必须通过审慎务实的整体战略规划，以平台化的方式有效构建金融级云原生能力，借助合作伙伴的技术深度、生态系统广度以及相关行业实践的专业度，加速可持续的信息化应用创新，真正释放数字基础设施的巨大潜能，需要从以下三大领域进行考虑。\n面向架构敏捷性 构建稳健的集成技术平台，打造业务创新引擎 金融行业的传统企业在长期发展历程中往往积累了大量的技术资产，因此，金融级云原生平台不仅必须具备融合支持能力，还应当以工具化、产品化的方式，帮助开发与运维团队实现云原生应用的快速开发迭代与对存量应用资产的平滑迁移，从而加速金融业务创新进程。\n聚焦业务连续性 基于金融技术风险防控，保障业务稳妥演进 金融级云原生平台必须能够在混合环境下，具备业务同城双活甚至异地多活的高可用容灾能力，而且能够基于单元化架构和数据分片等技术，实现多活容灾的单元化。同时，还应当具备灵活可控的应用发布进程，通过按需暂停回滚、分组灰度发布和原地升级等能力，实现应用的平滑演进；并具备可定制的流程编排能力，实现巡检诊断与容灾应急的自动化。\n追求运维精益性 关注安全可信稳定连续，降低运维保障成本 首先，金融级云原生平台必须具备基于策略的弹性规则配置能力，并通过多维度资源分析、网络流量调拨、实时指标评估以及灵活的回滚方式支持等技术，实现优雅的弹性伸缩。其次，平台必须为全链路可观测性提供支持，不仅提供多维度的监控数据，而且具备场景化的支持能力。最后，平台必须从应用视角出发，结合服务目录、服务网格、日志服务、链路跟踪等技术组件，为大规模分布式业务系统提供可视化的自动化运维能力，有效简化云原生运维过程。\nForrester 为众多希望推动完成数字化转型的金融企业和机构在云计算发展领域提出了以上有关发展方向的战略建议。蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）作为构建金融级云原生架构的应用平台，沉淀了金融场景的最佳实践。在企业面向金融级环境采用云原生技术过程中面临困难时，蚂蚁 SOFAStack 能够提供从服务构建、应用开发、部署发布、服务治理、监控运维、容灾高可用等全生命周期、全栈式解决方案，兼容 Dubbo、Spring Cloud 等微服务运行环境，助力客户各类应用轻松转型分布式架构。\n点击，获取完整 《白皮书》\n","date":1591858800,"description":"云原生技术已趋向成熟 为金融企业带来全新业务价值与技术优势","dir":"blog/forrester-daipeng-white-paper-cloud-native/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"eb590c61c39c7b48afdb5abd95889b99","permalink":"https://sofastack.github.io/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","publishdate":"2020-06-11T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","summary":"6月9日，在2020阿里云线上峰会上，蚂蚁联合全球知名市场研究与咨询机构 Forrester 发布《蚂蚁 SOFAStack 总体经济影响报告——金融级云原生市场趋势以及云原生平台","tags":["SOFAStack","云原生"],"title":"Forrester 中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求","type":"blog","url":"/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","wordcount":2340},{"author":"诣极","categories":"MOSN","content":" 背景 蚂蚁金服内部对 Service Mesh 的稳定性和性能要求是比较高的，内部 MOSN 广泛用于生产环境。在云上和开源社区，RPC 领域 Dubbo 和 Spring Cloud 同样广泛用于生产环境，我们在 MOSN 基础上，支持了 Dubbo 和 Spring Cloud 流量代理。我们发现在支持 Dubbo 协议过程中，经过 Mesh 流量代理后，性能有非常大的性能损耗，在大商户落地 Mesh 中也对性能有较高要求，因此本文会重点描述在基于 Go 语言库 dubbo-go-hessian2 、Dubbo 协议中对 MOSN 所做的性能优化。\n性能优化概述 根据实际业务部署场景，并没有选用高性能机器，使用普通 Linux 机器，配置和压测参数如下：\n Intel\u0026amp;reg; Xeon\u0026amp;reg; Platinum 8163 CPU @ 2.50GHz 4核16G； pod 配置 2c、1g，jvm 参数 -server -Xms1024m -Xmx1024m； 网络延迟 0.23ms, 2台 Linux 机器，分别部署 server+MOSN, 压测程序 rpc-perfomance； 经过3轮性能优化后，使用优化版本 MOSN 将会获得以下性能收益(框架随机512和1k字节压测)：\n 512字节：MOSN+Dubbo 服务调用 tps 整体提升55-82.8%，rt 降低45%左右，内存占用 40M； 1k数据：MOSN+Dubbo 服务调用 tps 整体提升51.1-69.3%，rt 降低41%左右, 内存占用 41M； 性能优化工具 pprof 磨刀不误砍柴工，在性能优化前首先要找到性能卡点，找到性能卡点后，另一个难点就是如何用高效代码优化替代 slow code。因为蚂蚁金服 Service Mesh 是基于 Go 语言实现的，我们首选 Go 自带的 pprof 性能工具，我们简要介绍这个工具如何使用。如果我们 Go 库自带 http.Server 时并且在 main 头部导入import _ \u0026amp;quot;net/http/pprof\u0026amp;quot;，Go 会帮我们挂载对应的 handler, 详细可以参考 godoc 。\n因为 MOSN 默认会在34902端口暴露 http 服务，通过以下命令轻松获取 MOSN 的性能诊断文件：\ngo tool pprof -seconds 60 http://benchmark-server-ip:34902/debug/pprof/profile # 会生成类似以下文件，该命令采样cpu 60秒 # pprof.mosn.samples.cpu.001.pb.gz 然后继续用 pprof 打开诊断文件，方便在浏览器查看，在图1-1给出压测后 profiler 火焰图：\n# http=:8000代表pprof打开8000端口然后用于web浏览器分析 # mosnd代表mosn的二进制可执行文件，用于分析代码符号 # pprof.mosn.samples.cpu.001.pb.gz是cpu诊断文件 go tool pprof -http=:8000 mosnd pprof.mosn.samples.cpu.001.pb.gz 在获得诊断数据后，可以切到浏览器 Flame Graph(火焰图，Go 1.11以上版本自带)，火焰图的 X 轴坐标代表 CPU 消耗情况，Y 轴代码方法调用堆栈。在优化开始之前，我们借助 Go 工具 pprof 可以诊断出大致的性能卡点在以下几个方面(直接压 Server 端 MOSN)：\n MOSN 在接收 Dubbo 请求，CPU 卡点在streamConnection.Dispatch； MOSN 在转发 Dubbo 请求，CPU 卡点在 downStream.Receive； 可以点击火焰图任意横条，进去查看长方块耗时和堆栈明细（请参考图1-2和1-3所示）：\n性能优化思路 本文重点记录优化了哪些 case 才能提升 50%+ 的吞吐量和降低 rt，因此后面直接分析当前优化了哪些 case。在此之前，我们以 Dispatch 为例，看下它为啥那么吃性能 。在 terminal 中通过以下命令可以查看代码行耗费 CPU 数据（代码有删减）：\ngo tool pprof mosnd pprof.mosn.samples.cpu.001.pb.gz (pprof) list Dispatch Total: 1.75mins 370ms 37.15s (flat, cum) 35.46% of Total 10ms 10ms 123:func (conn *streamConnection) Dispatch(buffer types.IoBuffer) { 40ms 630ms 125:\tlog.DefaultLogger.Tracef(\u0026amp;quot;stream connection dispatch data string = %v\u0026amp;quot;, buffer.String()) . . 126: . . 127:\t// get sub protocol codec . 250ms 128:\trequestList := conn.codec.SplitFrame(buffer.Bytes()) 20ms 20ms 129:\tfor _, request := range requestList { 10ms 160ms 134:\theaders := make(map[string]string) . . 135:\t// support dynamic route 50ms 920ms 136:\theaders[strings.ToLower(protocol.MosnHeaderHostKey)] = conn.connection.RemoteAddr().String() . . 149: . . 150:\t// get stream id 10ms 440ms 151:\tstreamID := conn.codec.GetStreamID(request) . . 156:\t// request route . 50ms 157:\trequestRouteCodec, ok := conn.codec.(xprotocol.RequestRouting) . . 158:\tif ok { . 20.11s 159:\trouteHeaders := requestRouteCodec.GetMetas(request) . . 165:\t} . . 166: . . 167:\t// tracing 10ms 80ms 168:\ttracingCodec, ok := conn.codec.(xprotocol.Tracing) . . 169:\tvar span types.Span . . 170:\tif ok { 10ms 1.91s 171:\tserviceName := tracingCodec.GetServiceName(request) . 2.17s 172: …","date":1591686000,"description":"本文将重点描述在基于 Go 语言库 dubbo-go-hessian2、Dubbo 协议中对 MOSN 所做的性能优化。","dir":"blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2584f4b7cd5bf07fb458ef9fbe60433c","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","publishdate":"2020-06-09T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","summary":"背景 蚂蚁金服内部对 Service Mesh 的稳定性和性能要求是比较高的，内部 MOSN 广泛用于生产环境。在云上和开源社区，RPC 领域 Dubbo 和 Spring Cloud 同样广泛用于生产环境，我们在","tags":["MOSN"],"title":"记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化","type":"blog","url":"/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","wordcount":4450},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@林尤庆 提问：\n 请问 SOFARPC 支持 fegin 不？\n A：SOFARPC 发的 rest 服务，feign 的方式是可以调用的，但是跟 ribbon 是没打通的。\n 有具体的例子不？\n A：https://github.com/sofastack/spring-cloud-sofastack-samples\n 我想问下 SOFARegistry 能像 Nacos 那样注册的是整个服务的名称么，现在 SOFARegistry 是细到接口。Spring Cloud是以整个应用注册的，SOFARegistry 是以每一个SofaServicce 注册的。\n A：SOFARegistry 和 Nacos 都是注册中心服务端产品，存的都是 key: list\u0026amp;lt; string \u0026amp;gt; 这样的数据结构，里面存什么数据是由他们的客户端决定的。SOFARPC 就算是注册中心的客户端。\n SOFARegistry 是以每一个 SofaServicce 注册的，fegin 访问的话也是每一个 SofaServicce 去访问的，不是整个应用访问的？\n A：跟 SOFARegistry 没关系，是 SOFARPC 的实现，目前按接口维度注册的。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n2、@姜哲 提问：\n SOFARPC 能发布一个 https 协议的服务吗？\n A：https 不行，h2（http/2+tls）是可以的。\n SOFABoot 环境下怎么发布？有 Demo 吗？\n A：基于 SOFABoot 可能没有适配， 可以先看下 API 方式的： https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/http2/Http2WithSSLServerMain.java\nSOFARPC：https://github.com/sofastack/sofa-rpc\n本周推荐阅读 多点生活在 Service Mesh 上的实践 | 线上直播整理 Service Mesh 中的可观察性实践 | 线上直播整理 Apache SkyWalking 在 Service Mesh 中的可观察性应用 | 线上直播回顾 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 陌陌的 Service Mesh 探索与实践 | 线上直播回顾 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.13.0 版本，主要变更如下：\n 新增 Strict DNS Cluster、GZIP 处理、单机故障隔离； 集成 Sentinel 实现限流能力； 优化 EDF 算法，使用 EDF 算法重新实现 WRR 算法； 支持 Dubbo 服务发现 Beta 版本，优化 Dubbo Decode 性能； 部分实现优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.13.0\n社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1591340400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200605/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9ba8595438771312ed9c187e57789bad","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200605/","publishdate":"2020-06-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200605/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发版、Service Mesh 相关文章整理、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200605/","wordcount":1488},{"author":"陈鹏","categories":"Service Mesh","content":" Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。\n 本文根据5月28日晚 Service Mesh Webinar#1 多点生活平台架构组研发工程师陈鹏，线上主题分享《多点生活在 Service Mesh 上的实践 \u0026amp;ndash; Istio + Mosn 在 Dubbo 场景下的探索之路》整理，文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处。如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点。\n今天主要给大家分享一下 Service Mesh 的一些技术点以及多点生活在 Service Mesh 落地过程中适配 Dubbo 的一些探索。\n首先我们从三个方面入手：\n 为什么需要 Service Mesh 改造； 探索 Istio 技术点； Dubbo 场景下的改造； 为什么需要 Service Mesh 改造 说到为什么需要改造，应该先说一下 Service Mesh 和传统微服务架构的一些特点。\n微服务 微服务一般有这些模块：\n 安全； 配置中心； 调用链监控； 网关； 监控告警； 注册和发现； 容错和限流； 这些模块在传统的微服务架构中有的是和 SDK 结合在一起，有的是一个独立的中间件。\n特点：\n 独立部署； 模块的边界； 技术多样性； 正是由于技术多样性，我的微服务系统可以使用不同的语言进行开发，比如我一个商城系统，订单系统使用 Java 开发，库存系统使用 Go 开发，支付系统使用 Python 开发，微服务之间通过轻量级通信机制协作，比如：HTTP/GRPC 等。比如目前多点使用的 Dubbo(服务治理框架)，随着多点生活的业务发展，目前遇到最棘手的问题就是中间件在升级过程中，推进很慢，需要业务方进行配合，接下来我们看看 Service Mesh。\nService Mesh 优点：\n 统一的服务治理； 服务治理和业务逻辑解藕； 缺点：\n 增加运维复杂度； 引入延时； 需要更多技术栈； 看了 Service Mesh 的优缺点，如果我们 Mesh 化了之后就可以解决我们目前的痛点，升级中间件只需要重新发布一下 Sidecar 就好了，不同语言开发的微服务系统可以采用同样的服务治理逻辑，业务方就可以尝试更多的技术。\n探索 Istio 技术点 在谈 Dubbo 场景下的改造之前我们先介绍一下 Istio 相关的技术点，然后结合 Dubbo 场景应该如何进行适配\nMCP MCP（Mesh Configuration Protocol）提供了一套用于订阅(Watch)、推送(Push)的 API，分为 Source 和 Sink 两个角色。\n Source 是资源提供方(server)，资源变化了之后推送给订阅者(Pilot)，Istio 1.5 之前这个角色就是 Galley 或者自定义 MCP Server； Sink 是资源的订阅者(client)，在 Istio 1.5 之前这个角色就是 Pilot 和 Mixer，都是订阅 Galley 或者自定义 MCP Server 的资源 MCP 的订阅、推送流程图:\n为了和实际情况结合，我们就以 MCPServer 作为 Source，Pilot 作为 Sink 来介绍订阅、推送流程，其中 MCP 通信过程中所传输的「资源」就是 Istio 定义的 CRD 资源，如：VirtualService、DestinationRules 等。\n订阅 Pilot 启动后会读取 Configmap 的内容，里面有一个 configSources 的一个数组配置（Istio 1.5 之后没有这个配置，需要自己添加）、存放的是 MCP Server 的地址； Pilot 连接 MCPServer 之后发送所关注的资源请求； MCPServer 收到资源请求，检查请求的版本信息（可能为空），判断版本信息和当前最新维护的版本信息是否一致，不一致则触发 Push 操作，一致则不处理； Pilot 收到 Push 数据，处理返回的数据（数据列表可能为空，为空也标示处理成功），根据处理结果返回 ACK（成功）/ NACK（失败），返回的应答中包含返回数据的版本信息，如果返回的是 NACK，Pilot 会继续请求当前资源； MCPServer 收到 ACK（和资源请求一致）之后对比版本号，如果一致则不推送，否则继续推送最新数据； 推送 MCPServer 自身数据发生变化，主动推送变化的资源给 Pilot； Pilot 收到之后处理这些数据，并根据处理结果返回 ACK / NACK； MCPServer 收到 ACK（和资源请求一致） 之后对比版本号，如果一致则不推送，否则继续推送最新数据； 这样的订阅、推送流程就保证了 MCPServer 和 Pilot 资源的一致。MCPServer 只能通过 MCP 协议告诉 Pilot 资源发生变化了么？当然不是，MCPServer 可以使用创建 CR 的方式，Pilot 通过 Kubernetes 的 Informer 机制也能感知到资源发生变化了，只是通过 MCP 传输的资源在 Kubernetes 里面看不到，只是存在于 Pilot 的内存里面，当然也可以通过 Pilot 提供的 HTTP debug 接口（istiod_ip:8080/debug/configz）来查。\nhttps://github.com/champly/mcpserver 提供了一个 MCPServer 的一个 demo，如果需要更加细致的了解 MCP 原理可以看一看。\n 更多 debug 接口可以查看: https://github.com/istio/istio/blob/5b926ddd5f0411aa50fa25c0a6f54178b758cec5/pilot/pkg/proxy/envoy/v2/debug.go#L103\n Pilot Pilot 负责网格中的流量管理以及控制面和数据面之前的配置下发，在 Istio 1.5 之后合并了 Galley、Citadel、Sidecar-Inject 和 Pilot 成为 Istiod。我们这里说的是之前 Pilot 的功能，源码里面 pilot-discovery 的内容。\n功能 根据不同平台（Kubernetes、Console）获取一些资源，Kubernetes 中使用 Informer 机制获取 Node、Endpoint、Service、Pod 变化； 根据用户的配置（CR、MCP 推送、文件）触发推送流程； 启动 gRPC server 用于接受 Sidecar 的连接； 推送流程 记录变化的资源类型； 根据变化的资源类型(数组)整理本地数据； 根据变化的资源类型判断需要下发的 xDS 资源； 构建 xDS 资源， …","date":1591264800,"description":"本文主要给分享 Service Mesh 的一些技术点以及多点生活在 Service Mesh 落地过程中适配 Dubbo 的一些探索。","dir":"blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"99f4c0638c5fbd0b762ce8d373142ae0","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","publishdate":"2020-06-04T18:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","summary":"Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。 本文根据5月28日晚 Service Mesh Webinar#1 多点生活平台架构","tags":["Service Mesh","Service Mesh Webinar"],"title":"多点生活在 Service Mesh 上的实践 -- Istio + Mosn 在 Dubbo 场景下的探索之路","type":"blog","url":"/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","wordcount":5590},{"author":"叶志远","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖如何使用 SkyWalking 来观测 Service Mesh，来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务监控的区别。\n本文根据5月14日晚，G7 微服务架构师叶志远的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 谈到 Service Mesh，人们总是想起微服务和服务治理，从 Dubbo 到 Spring Cloud (2016开始进入国内研发的视野，2017年繁荣)再到 Service Mesh (2018年开始被大家所熟悉)，正所谓长江后浪推前浪，作为后浪，Service Mesh 别无选择，而 Spring Cloud 对 Service Mesh 满怀羡慕，微服务架构的出现与繁荣，是互联网时代架构形式的巨大突破。Service Mesh 具有一定的学习成本，实际上在国内的落地案例不多，大多是云商与头部企业，随着性能与生态的完善以及各大社区推动容器化场景的落地，Service Mesh 也开始在大小公司生根发芽，弥补容器层与 Kubernetes 在服务治理方面的短缺之处。本次将以一个选型调研者的视角，来看看 Service Mesh 中的可观察性主流实践方案。\n可观察性的哲学 可观察性（Observability）不是一个新名词，它在很久之前就已经诞生了，但是它在 IT 领域却是一个新兴事物。可观察性在维基百科中原文是这样定义的：“In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. ”。云原生领域第一次出现这个词，是在云原生理念方兴未艾的2017年，在云原生的思潮之下，运用传统的描述方式已经不足以概括这个时代的监控诉求，而 Observability 就显得贴切许多。\n回想一下传统的监控方式，除去运维层面的主机监控、JVM 监控、消息队列监控之外，有多少监控是事先就想好怎么做的？很少！其实很多时候，我们做的事情就是在故障发生之后，对故障复盘的过程中，除了 bug 重现与修复，也会去定制加一些监控，以期望下次发生同样的情况时有一个实时的告警。研发人员收到告警之后得以快速地处理问题，尽可能地减少损失。所以，传统的监控模式大多都是在做亡羊补牢的事情，缺少一个主动性。\n在云原生时代的容器化体系当中就不一样了，容器和服务的生命周期是紧密联系在一起的，加上容器完美的隔离特性，再加上 Kubernetes 的容器管理层，应用服务跑在容器当中就显得更加地黑盒化，相较在传统物理主机或者虚拟机当中，排查问题的时候显得非常不便。所以在云原生时代强调的是可观察性，这样的监控永远都是兵马未动而粮草先行的，需要提前想好我们要如何观察容器内的服务以及服务之间的拓扑信息、各式指标的搜集等，这些监测能力相当重要。\n关于可观察性在云原生领域是何时开始流行起来的，没有一个很明确的时间。业界认为可观察性最早是由 Cindy Sridharan 提出的，其实一位德国柏林的工程师 Peter Bourgon 早在2017年2月就已经有文章在讨论可观察性了，Peter 算是业界最早讨论可观察性的开发者，他写的著名的博文《Metrics, Tracing, and Logging》被翻译成了多种语言。真正可观察性成为一种标准，是来自 Pivotal 公司的 Matt Stine 定义的云原生标准，可观察性位列其中，由此可观察性就成为了云原生时代一个标准主题。\nPeter Bourgon 提出的可观察性三大支柱围绕 Metrics、Tracing 和 Logging 展开，这三个维度几乎涵盖了应用程序的各种表征行为，开发人员通过收集并查看这三个维度的数据就可以做各种各样的事情，时刻掌握应用程序的运行情况，关于三大支柱的理解如下：\n Metrics：Metrics 是一种聚合态的数据形式，日常中经常会接触到的 QPS、TP99、TP95 等等都属于Metrics 的范畴，它和统计学的关系最为密切，往往需要使用统计学的原理来做一些设计； Tracing：Tracing 这个概念几乎是由 SOA 时代带来的复杂性补偿，服务化带来的长调用链，仅仅依靠日志是很难去定位问题的，因此它的表现形式比 Metrics 更复杂，好在业界涌现出来了多个协议以支撑 Tracing 维度的统一实现； Logging：Logging 是由请求或者事件触发，应用程序当中用以记录状态快照信息的一种形式，简单说就是日志，但这个日志不仅仅是打印出来这么简单，它的统一收集、存储以及解析都是一个有挑战的事情，比如结构化(Structured)与非结构化(Unstructed)的日志处理，往往需要一个高性能的解析器与缓冲器； 此外，Peter Bourgon 在博文中还提到了三大支柱结合态的一些理想输出形式，以及对存储的依赖，Metrics、Tracing、Logging 由于聚合程度的不同，对存储依赖由低到高。更多细节，感兴趣的同学可以查看文末的原文链接。\nPeter Bourgon 关于可观察性三大支柱的思考不止于此，他还在2018年的 GopherCon EU 的分享上面再次讨论了 Metrics、Tracing 和 Logging 在工业生产当中的深层次意义，这次他探讨了4个维度。\n CapEx：表示指标初始收集成本，很明显日志的成本最低，埋点即可；其次是 Metrics，最难是 Tracing 数据，在有了协议支撑的情况下，依然要定义许多数据点，以完成链路追踪必须的元数据定义收集； OpEx：表示运维成本，一般指存储成本，这个之前已经讨论过； Reaction：表示异常情况的响应灵敏度，显然聚合之后的数据可以呈现出波动情况，因此 Metrics 是对异常情况最灵敏的；Logging 次之，也可以从 Logging 清洗之中发现异常量；而 Tracing 在响应灵敏度上面似乎沾不上边，最多还是用在排障定位的场景； Investigation：标准故障定位能力，这个维度是 Tracing 的强项，可以直观看出链路当中的故障，精确定位；Logging 次之；Metrics 维度只能反馈波动，对定位故障帮助不大； 在 CNCF Landscape 当中，有一块区域专门用作展示云原生场景下的可观察性解决方案，里面又分为好几个维度，图中是截至2020年5月14日的最新版图，未来还会有更多优秀的解决方案涌现出来。CNCF 目前毕业的10个项目库当中，有3个是和可观察性有关的， …","date":1591092000,"description":"本文根据 G7 微服务架构师叶志远线上分享整理，以一个选型调研者的视角，来看看 Service Mesh 中的可观察性主流实践方案。","dir":"blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a4bde9dc8721fabf285171be403d7f5a","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","publishdate":"2020-06-02T18:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖如何使","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Service Mesh 中的可观察性实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","wordcount":8781},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@钱德鹏 提问：\n 官网的泛化调用 Demo 地址为https://www.sofastack.tech/projects/sofa-rpc/generic-invoke，代码如下： 这段代码里 consumerConfig 没有指定 directUrl，那么是如何获取服务地址的？自己测试时，如果不指定 directUrl，那么会报找不到服务的错误；如果指定 directUrl，可以正常调用。所以想问一下到底需不需要指定？\n ConsumerConfig consumerConfig = new ConsumerConfig() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); A：你这个跟是否跟泛化调用没关系。 RPC 调用肯定是要拿到对方的服务端地址的，这里要么走注册中心去做服务发现，要么走指定直连地址。\n 明白，我的意思是官网的 Demo 里面没指定 URL，那么他是怎么调用成功的？既然官网没有指定，为什么我不指定就调用不到？另外附加一个问题，如果说一定要指定地址，那么我指定成 SLB 地址，由 SLB 去分发，是否可行？\n A：你说官网的 Demo 是哪个？\n https://www.sofastack.tech/projects/sofa-rpc/generic-invoke\n A：这里应该是代码片段，不是完整 Demo。Example 可以参加 https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/invoke/generic/GenericClientMain.java 指定成 SLB 地址是可以的，不过是 slb 跟服务端是长连接，建立了就不断了，服务端负载不一定会均衡。\n 好的，是否可以认为如果像 Demo 里这样调用，就必须指定 directUrl？\n A：对，使用 ZK 为注册中心的例子就是： https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/zookeeper/start/ZookeeperBoltClientMain.java\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@王振 提问：\n 请问，配置 Nacos，如果 Nacos 是集群部署的话，那 Seata 配置 Nacos 地址的时候是不是只需要填写 Nacos 集群地址就行了，不要三个都填的吧？\n A：Nacos 集群不是填3个地址嘛？你自己做了前端负载？\n 用 Nginx 去做了，在 Nacos 之上加入了 Nginx 做了负载均衡，那在 Seata 配置上是不是只需要配置负载均衡的地址就可以了是吗？如果不做负载的话，那填三个地址是逗号隔开吗？\n A：是的，跟直接使用 Nacos 集群写法一致，我们把这个属性透传给 Nacos。\n 是 ip:port,ip:port,ip:port 这种形式对吧？\n A：是的。\n 另外，请问 Seata 对服务器有最低要求吗？\n A：server 推荐 2C4G+ 吧，jvm 内存2G+。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Apache SkyWalking 在 Service Mesh 中的可观察性应用 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 陌陌的 Service Mesh 探索与实践 - 直播回顾 剖析 SOFARPC 框架 【剖析 | SOFARPC 框架】系列之SOFARPC 序列化比较 【剖析 | SOFARPC 框架】系列之SOFARPC跨语言支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 路由实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 优雅关闭剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 数据透传剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 泛化调用实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 单机故障剔除剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 线程模型剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 同步异步实现剖析 【剖析 | SOFARPC 框架】系列之连接管理与心跳剖析 【剖析 | SOFARPC 框架】系列之链路追踪剖析 【剖析 | SOFARPC 框架】系列之总体设计与扩展机制 ","date":1590735600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200529/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2009de6439107016241e7f8efc5a665c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200529/","publishdate":"2020-05-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200529/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 系列直播回顾、SOFARPC 剖析回顾","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200529/","wordcount":1431},{"author":"高洪涛","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖 Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh，来自陌陌和百度的 Service Mesh 生产实践。\n本文根据5月7日晚，美国 Service Mesh 服务商 Tetrate 创始工程师高洪涛的主题分享《Apache SkyWalking 在 Service Mesh 中的可观察性应用》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 本次演讲为大家分享的是 Apache SkyWalking 对 Service Mesh 可观测性方面的应用实践，共分为三个部分：\n 第一部分是 Apache SkyWalking 的相关背景； 第二部分是 Service Mesh 场景下 SkyWalking 所面临的挑战； 最后是针对 Service Mesh 场景方案的演化； SkyWalking 的历史沿革及其特点 SkyWalking 项目的建设目的是为了解决在微服务环境下，如何快速的定位系统稳定性问题。创始团队于2016年启动项目，经过一年的努力完善了最初的版本。2017年，团队启动将项目捐献给 Apache 基金会的流程。在 Apache 基金会孵化器内，经过了多轮系统升级迭代，并获得近乎翻倍的贡献者和关注度，于2019年顺利毕业。经过经年的升级与维护，SkyWalking 从最开始专注于分布式追踪系统的单一平台，发展为包含多个门类并拥有丰富的功能的全领域 APM 系统。\nSkyWalking 整体的系统架构包括有三个部分:\n 第一个是数据采集端，可以使用语言探针对系统的监控指标进行采集，同时也提供了一套完整的数据采集协议。第三方系统可以使用协议将相关的监控数据上报到分析平台。 第二部是分析平台，主要包括对监控指标数据的搜集，流式化处理，最终将数据写到存储引擎之中。存储引擎可使用Elasticsearch，MySQL数据库等多种方案。 第三部分是 UI。UI 组件有丰富的数据展示功能，包含指标展板，调用拓扑图，跟踪数据查询，指标比较和告警等功能。 在此基础上，SkyWalking 本身组件具有丰富的定制功能，方便用户去进行二次开发以支持自己特有的场景。\nSkyWalking 定义了三个维度用来绑定相关的监控指标数据。\n 服务(Service)：表示对请求提供相同行为的一系列或一组工作负载。在使用打点代理或 SDK 的时候, 你可以定义服务的名字。如果不定义的话，SkyWalking 将会使用你在平台上定义的名字, 如 Istio。 实例(Instance)：上述的一组工作负载中的每一个工作负载称为一个实例。就像 Kubernetes 中的 Pod 一样, 服务实例未必就是操作系统上的一个进程。但当你在使用打点代理的时候，一个服务实例实际就是操作系统上的一个真实进程。 端点(Endpoint)：对于特定服务所接收的请求路径，如 HTTP 的 URL 路径和 gRPC 服务的类名 + 方法签名。 预定义的维度可以方便的进行数据预汇集操作，是 SkyWalking 分析引擎重要的组成部分。虽然其相对的会有使用不够灵活的缺点，但在 APM 场景下，指标往往都是预先经过精心设计的，而性能才是关键因素。故 SkyWalking 采用这种预定义维度模式来进行数据汇集操作。\nService Mesh 场景下 SkyWalking 面对的挑战 在描述 Service Mesh 的场景下所面临的挑战之前，需要去解释可观测性所包含的含义。可观测性一般包含有三个部分:\n 第一点，日志系统。由其可以构建出系统运行的实时状态。故日志成为非常方便的观测手段。 第二点，分布式追踪。这部分数据在微服务场景下具有强大的生命力，可以提供给用户分布式系统观测指标。 第三点，指标监控。相比于日志和分布式追踪，其具有消耗小，处理简便等特点，通常作为系统监测告警的重要数据来源。 如上所示是 Istio1.5 的架构图。重点看一下他对可观测性的支持。从图上看，所有的监控指标都汇聚到中间的 Mixer 组件，然后由 Mixer 再发送给他左右的 Adapter，通过 Adapter 再将这些指标发送给外围的监控平台，如 SkyWalking 后端分析平台。在监控数据流经 Mixer 的时候，Istio 的元数据会被附加到这些指标中。另一种新的基于 Telemetry V2 观测体系是通过 Envoy 的 Proxy 直接将监控指标发送给分析平台，这种模式目前还处于快速的演进和开发中，但是它代表着未来的一种趋势。\n从架构图中我们可以看到，这里面的第一个挑战就是 Service Mesh 场景下，对于可观测性的技术体系的支持是非常多变的。\nIstio 本身就包括两种不融合的体系，第一种是基于 Mixer 的场景，第二种是 Mixerless 场景。\nMixer 是基于访问日志进行指标生成的，也就是说服务与服务之间的访问日志经过 Mixer 增加相关的原数据后再发给外围分析系统。其特点是这个模式非常的成熟、稳定，但是性能会非常的低。它的低效源于两个方面，第一点是他的数据发送通道很长，中间节点过多。可以看到数据需要到从 Proxy 发送到 Mixer 节点，再发送给外围的 Adapter 节点。另一个效能低下的原因主要是体现在它发送的是原始访问日志，其数据量是非常大的，会消耗过多的带宽，这对整体的数据搜集与分析提出了非常大的挑战。\n另一种模式是 Mixerless，它完全是基于 Metrics 指标的。通过可观测性包含的技术及其特点分析可知，它是一种消耗比较小的技术，对带宽以及分析后台都是非常友好的。但是它同时也有自己的问题，第一个问题就是他需要的技术门槛是比较高的（使用 WASM 插件来实现），并且对于 Proxy 端的性能消耗也是比较大的。同时由于是新的技术，稳定性较差，相关接口与规范并不完整。\n第二个挑战就是无 Tracing 数据。SkyWalking 最早是为了收集处理跟踪数据（Tracing）而设计的一套系统，但是我们可以从右边的图发现，对于 Service Mesh 上报的数据其实是基于调用的，也就是说它不存在一条完整的跟踪链路。这样就对后台的分析模型有比较大的挑战，如何才能同时支持好这两种模式成为后端分析系统所要处理的棘手问题。\n第三个挑战就是维度匹配的问题。我们从前一章可以看到 SkyWalking 是包括三个维度的，其中对于实例和端点，在 Service Mesh 场景下都是有比较好的支持。这里多说一句，不仅仅是对 Mesh 场景，对于大部分场景都可以很好的去匹配它们。但是对于服务的匹配是有相当大难度的，因为 SkyWalking 只有服务这一层的概念，而在 Istio 中有好几个概念可以称之为“服 …","date":1590649200,"description":"本文根据5月7日晚，美国 Service Mesh 服务商 Tetrate 创始工程师高洪涛的主题分享《Apache SkyWalking 在 Service Mesh 中的可观察性应用》整理。","dir":"blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2414682129ca15d4cfc86bffc6694aaa","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","publishdate":"2020-05-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖 Service Mesh 的","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Apache SkyWalking 在 Service Mesh 中的可观察性应用","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","wordcount":4356},{"author":"罗广明","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。\n本文根据5月13日晚，百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 Service Mesh 在企业落地中有诸多挑战，当与传统微服务应用共同部署治理时可用性挑战更为严峻。本次分享将以 Service Mesh 与 Spring Cloud 应用互联互通共同治理为前提，着重介绍基于 Consul 的注册中心高可用方案，通过各种限流、熔断策略保证后端服务的高可用，以及通过智能路由策略（负载均衡、实例容错等）实现服务间调用的高可用。\nService Mesh 与 Spring Cloud 应用的互通、互联 微服务是时下技术热点，大量互联网公司都在做微服务架构的推广和落地。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。而在这个技术转型中，国内有一个现象，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。近年来，新兴的 Service Mesh 技术也越来越火热，受到越来越多开发者的关注，大有后来居上的趋势。\n在听到社区里很多人谈到微服务技术选型时，注意到他们讨论一个非此即彼的问题：采用 Spring Cloud 还是以 Istio 为代表的 Service Mesh 技术？然而这个答案并非非黑即白、非你即我，一部分应用采用 Spring Cloud，另一部分采用 Service Mesh（Istio）是完全可能的。今天我就和大家一起来讨论这个问题。\n首先，我们来看一下 Spring Cloud 这个传统侵入式微服务框架。它包含以下优点：\n 集大成者，Spring Cloud 包含了微服务架构的方方面面；选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架； 轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者； 开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发； 开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件； 特别感谢 Netflix，这家很早就成功实践微服务的公司，几年前把自家几乎整个微服务框架栈贡献给了社区，早期的 Spring Cloud 主要是对 Netflix 开源组件的进一步封装。不过近两年，Spring Cloud 社区开始自研了很多新的组件，也接入了其他一些互联网公司的优秀实践。\n接下来，我们简单看一下 Service Mesh 框架。它带来了两大变革：微服务治理与业务逻辑的解耦，异构系统的统一治理。此外，服务网格相对于传统微服务框架，还拥有三大技术优势：可观察性、流量控制、安全。服务网格带来了巨大变革并且拥有其强大的技术优势，被称为第二代“微服务架构”。\n然而就像之前说的软件开发没有银弹，传统微服务架构有许多痛点，而服务网格也不例外，也有它的局限性。这些局限性包括：增加了链路与运维的复杂度、需要更专业的运维技能、带来了一定的延迟以及对平台的适配。\n更多关于 Spring Cloud 与 Service Mesh 的优缺点与比较，请阅读 Istio-Handbook [Service Mesh 概述]。\n前面提到过，对于传统微服务框架 Spring Cloud 与新兴微服务框架 Service Mesh，并非是个非黑即白，非你即我，延伸到微服务与单体架构，它们也是可以共存的。\n也可以将其与混合云相类比，混合云中包含了公有云、私有云，可能还有其它的自有基础设施。目前来看，混合云是一种流行的实践方式；实际上，可能很难找到一个完全单一云模式的组织。对多数组织来说，将一个单体应用完全重构为微服务的过程中，对开发资源的调动是一个很严峻的问题；采用混合微服务策略是一个较好的方式，对开发团队来说，这种方式让微服务架构触手可及；否则的话，开发团队可能会因为时间、经验等方面的欠缺，无法接受对单体应用的重构工作。\n构建混合微服务架构的最佳实践：\n 最大化收益的部分优先重构； 非 Java 应用优先采用 Service Mesh 框架； 混合微服务出现的原因是为了更好的支持平滑迁移，最大限度的提升服务治理水平，降低运维通信成本等，并且可能会在一个较长的周期存在着。而实现这一架构的前提，就是各服务的“互联互通”。\n要想实现上述“混合微服务架构”，运行时支撑服务必不可少，它主要包括服务注册中心、服务网关和集中式配置中心三个产品。\n传统微服务和 Service Mesh 双剑合璧（双模微服务），即“基于 SDK 的传统微服务”可以和“基于 Sidecar 的 Service Mesh 微服务”实现下列目标：\n 互联互通：两个体系中的应用可以相互访问； 平滑迁移：应用可以在两个体系中迁移，对于调用该应用的其他应用，做到透明无感知； 灵活演进：在互联互通和平滑迁移实现之后，我们就可以根据实际情况进行灵活的应用改造和架构演进； 这里还包括对应用运行平台的要求，即两个体系下的应用，既可以运行在虚拟机之上，也可以运行在容器/K8s 之上。我们不希望把用户绑定在 K8s 上，因此 Service Mesh 没有采用 K8s 的 Service 机制来做服务注册与发现，这里就突出了注册中心的重要性。\n百度智能云 CNAP 团队实现了上述混合微服务架构，即实现了两个微服务体系的应用互联互通、平滑迁移、灵活演进。上述混合微服务架构图包括以下几个组件：\n API Server：前后端解耦，接口权限控制、请求转发、异常本地化处理等等； 微服务控制中心：微服务治理的主要逻辑，包括服务注册的多租户处理、治理规则（路由、限流、熔断）的创建和转换、微服务配置的管理； 监控数据存储、消息队列：主要是基于 Trace 的监控方案使用的组件； 配置中心：微服务配置中心，最主要的功能是支持配置管理，包括治理规则、用户配置等所有微服务配置的存储和下发，微服务配置中心的特色是借助 SDK 可以实现配置/规则热更新； 接下来主要看一下注册中心的服务注册和发现机制：\n Spring Cloud 应用通过 SDK、Service Mesh 应用实现 Sidecar 分别向注册中心注册，注册的请求先通过微服务控制中心进行认证处理与多租户隔离； Mesh 控制面直接对接注册中心获取服务实例、Spring Cloud 应用通过 SDK 获取服务实例； 双模异构，支持容器与虚机两种模型； 注册中心与高可用方案 前面提到过，要想实现实现混合微服务架构，注册中心很关键。谈到注册中心，目前主流的开源注 …","date":1590476400,"description":"本文根据5月13日晚，百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。","dir":"blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","fuzzywordcount":9100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2cea7fee830cbfcc69ee7732909b231c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","publishdate":"2020-05-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","wordcount":9014},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张晓明 提问：\n 关于 SOFATracer 采样率的配置，只在请求经过的第一个服务配置采样率就可以吗，还是每个服务都需要配置采样率，每个服务都配置的话，要求各服务采样率必须一致吗？\n A：第一个，只在请求经过的第一个服务配置采样率就可以。\n 上报 Zipkin 的话，也只在第一个服务配置就可以吧，其他服务只需要引入 tracer-sofa-boot-starter 就行吧？\n A：上报每个服务节点都要配，不然你下游链路数据拿不到。\n 采样率支持动态更新吗，就是修改后需要重启服务吗？\n A：可以通过自定义采样，配合个配置中心就可以。\n 采样模式用 PercentageBasedSampler，配合配置中心可以吗？\n A：可以，比较麻烦，要反射去改配置类的值，配置类初始化时采样率就确定了，如果要动态改只能通过反射去改。或者通过拿到配置类对象去设置也行，思路差不多。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@李振鸿 提问：\n 请问，分布式事务执行 (只插入两条数据) 执行时间 0.3 会不会比较慢？\n A：嗯，Seata 是消耗了不少性能，尤其是跟 TC 通信、TC 那边的处理。 Seata：https://github.com/seata/seata\n本周推荐阅读 云原生网络代理 MOSN 透明劫持技术解读 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.12.0版，主要更新如下：\n 支持 Go 语言，并增加了 Demo； 新增三个命令行子命令：start, exec 和 stop； 新增 signal 子系统； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.12.0\n社区直播报名 随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处？如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点？服务之间主要通过 Dubbo 交互。本次分享将探索 Istio + MOSN 在 Dubbo 场景下的改造方案，结合现有业务场景和可切入点，明确需要修改的场景，制定符合自己业务场景的 Service Mesh 落地方案，介绍多点生活在 Dubbo 案例的探索及改造方案。\n将从以下几个方面，与大家交流分享：\n 传统微服务架构与 Service Mesh 架构 传统微服务架构在多点遇到的痛点； Service Mesh 架构能带来的福利； Istio 技术点介绍 在 Dubbo 场景下的改造分析 对比 MOSN 和 Envoy 对现有场景的支持； Istio+MOSN 和 Istio+Envoy 在 Dubbo 场景下如何改造； MOSN + Istio 具体实现探索 MOSN 配置文件介绍、从一个流量进来到转发到具体的远端的流程分析； Provider 配置信息如何下发到 Sidecar； 从多点现在的实际场景对现有的 Dubbo 改造方案； Demo 演示 直播主题： Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路\n分享嘉宾：陈鹏，多点生活平台架构组研发工程师，开源项目与云原生爱好者，有多年的网上商城、支付系统相关开发经验，2019年至今从事云原生和 Service Mesh 相关开发工作。\n直播时间：2020/5/28（周四）20:00-21:00\n直播间：点击“这里”，关注直播间即可\n","date":1590138000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200522/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b5778b2bc8e9e6cd92abd8bd7bfc387b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200522/","publishdate":"2020-05-22T17:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200522/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Occlum 发布、技术直播回顾\u0026预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200522/","wordcount":1432},{"author":"巴德","categories":"Kata Containers","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 本文根据 SOFAChannel#16 直播分享整理，主题：不得不说的云原生隔离性。\n大家好，我是今天的讲师巴德，来自蚂蚁金服，主要从事 Kata 容器相关的开发，也是 Kata Containers 项目的维护者之一。今天我和大家分享一下云原生场景下容器隔离性的需求以及我们如何运用 Kata Containers 来提升容器的隔离性。\n从 Kubernetes Pod 说起 在讲云原生隔离性之前，我们先来回顾一下历史。这张图是生产环境应用部署形态的变迁过程。从最左边的物理机上直接部署，到后来的虚拟化兴起，大家把应用部署在虚拟机里，再到 Docker 兴起，大家都把应用部署到容器里面，到现在 Kubernetes 成为主流，大家都把应用部署在 Pod 里面。\n我们看一下 Kubernetes 的一个基本架构，它本身是一个容器的编排系统，主要角色是管理和调度 Pod 以及相关的资源。今天我们主要关注的就是在节点上部署的 Pod，这也是 Kubernetes 资源调度的基本单位。\nKubernetes 官方对 Pod 的定义是一个应用的逻辑主机，其中包含了一个或者多个应用容器，这些容器在资源上是相对紧密的耦合在一起的。Pod 包含了这些容器共享的网络和存储以及如何运行这些容器的声明。Pod 中的内容总是放置在一起并且一同调度，并在共享的上下文中运行。\n这段定义有些抽象，其目的是为了说明 Pod 是可以用不同的隔离技术来实现的。我们先来看一下一个经典的 Pod 实现，基于 Linux namespace 和 cgroups 做抽象的 Pod 实现。\n这个示意图中，我们在一台主机上运行了两个 Pod，这两个 Pod 之间通过主机内核提供的 namespace 和 cgroups 能力来进行隔离。他们之间的所有 namespace 资源都是隔离的。然后在 pod 内部，不同容器之间的 IPC 和网络 namespace 是共享的，但是他们的 mnt/pid/user/uts namespace 又是相互隔离的。这就是一个经典的基于 Linux namespace 和 cgroups 来做隔离的 Pod 的实现。\n对于这种 Pod 的实现，我们可以关注到这两个 Pod 虽然所有的 namespace 都是隔离的，但是他们共享了同一个内核。\n共享内核引入的问题 那么，我们来看一下 Pod 共享同一个内核可能造成什么问题。\n首先我们关注到的是安全问题。也就是说 Pod 中的容器应用会不会通过共享内核的漏洞逃逸出 Pod 的资源隔离？这里我们列了两个近几年的内核 bug，一个是 CVE-2016-5915，另外一个是 CVE-2017-5123，这两个 bug 都曾经造成容器应用通过触发内核 bug 获取宿主机 root 权限并逃逸出 Pod 资源隔离限制。\n另外一个点是故障影响。这个好理解，如果一个 Pod 中的容器应用触发了一个严重的内核 bug，造成内核 panic，这时候同一台宿主机上的所有 Pod 都会被牵连。\n还有一个我们非常关注的点，是共享内核造成的内核资源竞争。同一个宿主机上的不同 Pod，实际上是不同的用户态进程的集合，这些用户态进程虽然在 namespace 上是相互隔离的，但他们还是会共享很多内核资源，比如调度器、某些内核线程或者对象。这种级别的资源共享会引入很多可以观测到的性能抖动，对在线业务的影响也很明显。\n如何避免共享内核造成的这些问题呢？大家最直接的想法就是，把 Kubernetes 装到虚拟机里不就可以更好的隔离起来了吗？如图所示，这本质上是通过增加一个 VM 间接层来解决隔离性问题。\n看起来问题解决了，不是吗？这时候我们就需要抛出计算机届大佬 David Wheeler 的一个名言，“计算机科学中的所有问题都可以通过增加一个间接层来解决，当然，除了间接层过多的问题”。\n那么增加 VM 间接层的方案有什么问题呢？第一，同一个 VM 内的 Pod 之间还是共享内核的。第二，整个集群里出现了虚拟机和 Pod 两层调度系统。\n上帝说，要有光；我们说，要有 Kata 面对这些问题，我们要怎么做呢？我们要部署 Kata 容器 ：)\nKata 容器的一个基本思路是，用虚拟机来作为 Pod 的一种隔离方式。我们把 Pod 中的多个容器资源，放到同一个虚拟机里面，利用虚拟机来实现不同 Pod 独占内核的目的。而 Pod 仍然是 Kubernetes 的基本调度单位，集群里也不会有虚拟机和 Pod 两层调度系统。\n我们简单介绍一下 Kata Containers 这个项目，这是 Openstack 基金会管理下的开放基础设施顶级项目。Kata Containers 的 slogen 是 The speed of containers, the security of VMs。其设计是基于虚拟机完美符合 Pod 抽象这个理念，为用户提供强隔离，易用的容器基础设施。\nKata Containers：https://github.com/kata-containers/kata-containers\n这是 Kata Containers 项目的发展历史概要。在 2015 年的五月，一帮国内的创业者(就是我们) 和 Intel 的同学们分别独立发布了两个叫 runV 和 Clear Containers 的虚拟化容器项目，这就是 Kata Containers 的前身。这两个项目互相有很多交流，在分别独立发展了两年半之后，在 2017 年底，合并成了 Kata Containers 项目，并把这个项目捐给 Openstack 基金会管理，这也是 Openstack 基金会的第一个 Pilot 项目，有一些探索转型的味道。在去年的四月，Kata Containers 被 Openstack 基金会认可为其第二个顶级项目，在这之前的十多年里，Openstack 基金会都只有 Openstack 一个顶级项目。\n目前 Kata Containers 的稳定版本发布到了 1.10.0，而且 2.0 也正在紧锣密鼓地开发中。\n我们再简单介绍下 Kata Containers 的架构。左边蓝色部分是 Kata Containers 对接的上游组件，也就是 Kubernetes 通过 CRI 接口访问 CRI daemon，这里是用 containerd 做展示。 Containerd 通过一个 Shim API 来访问 Kata Containers。右边的就都是 Kata 的组件了。对每一个 Pod，我们有一个名叫 containerd-shim-kata-v2 的服务进程，这个服务进程会负责基于虚拟机的 Pod 的生命周期管理。最后边的 Pod Sandbox 就是我们基于虚拟机来实现的一个 Pod 抽象。在里面我们要运行一个叫 kata-agent 的服务进程，来负责 Pod 内容器的生命周期管理。\nKata 容器特性大放送 介绍了 Kata …","date":1590123600,"description":"本文根据线上直播整理，一起来看看云原生场景下容器隔离性的需求以及我们如何运用 Kata Containers 来提升容器的隔离性。欢迎阅读","dir":"blog/sofa-channel-16-retrospect/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c57953062af87158c42de61e48d1676f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-16-retrospect/","publishdate":"2020-05-22T13:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-channel-16-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播","tags":["Kata Containers","SOFAChannel"],"title":"不得不说的云原生隔离性 | SOFAChannel#16 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-16-retrospect/","wordcount":3573},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路\n 活动时间：5 月 28 日周四晚 8 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 Service Mesh Webinar Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#1 Service Mesh Webinar#1，邀请多点生活平台架构组研发工程师陈鹏，带来分享《多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路》。\n随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处。如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点。服务之间主要通过 Dubbo 交互，本次分享将探索 Istio + MOSN 在 Dubbo 场景下的改造方案。\n分享主题：\n《多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路》\n分享嘉宾：\n陈鹏，多点生活平台架构组研发工程师，开源项目与云原生爱好者，有多年的网上商城、支付系统相关开发经验，2019年至今从事云原生和 Service Mesh 相关开发工作。\n直播时间：2020年5月28日（周四）20:00-21:00\n解决思路:\n从 MCP、Pilot、xDS、MOSN 技术，对 Service Mesh 的可切入点分析。\n成果：\n结合现有业务场景和可切入点，明确需要修改的场景，制定符合自己业务场景的 Service Mesh 落地方案，介绍多点生活在 Dubbo 案例的探索及改造方案。\n大纲：\n 传统微服务架构与 Service Mesh 架构 传统微服务架构在多点遇到的痛点 Service Mesh 架构能带来的福利 Istio 技术点介绍 在 Dubbo 场景下的改造分析 对比 MOSN 和 Envoy 对现有场景的支持 Istio+MOSN 和 Istio+Envoy 在 Dubbo 场景下如何改造 MOSN + Istio 具体实现探索 MOSN 配置文件介绍、从一个流量进来到转发到具体的远端的流程分析 Provider 配置信息如何下发到 Sidecar 从多点现在的实际场景对现有的 Dubbo 改造方案 Demo 演示 ","date":1589958000,"description":"5 月 28 日周四晚 8 点，Service Mesh Webinar#1 线上直播。","dir":"activities/service-mesh-webinar-1/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d146e6a876059c0f8da819f408add6fa","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-webinar-1/","publishdate":"2020-05-20T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-webinar-1/","summary":"概要 活动主题：Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路 活动时间：5 月 28 日周四晚 8 点 活","tags":["MOSN","Service Mesh Webinar"],"title":"Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践","type":"activities","url":"/sofastack.tech/activities/service-mesh-webinar-1/","wordcount":742},{"author":"无在","categories":"MOSN","content":" MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称，可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡、API Gateway、云原生 Ingress 等使用。 MOSN：https://github.com/mosn/mosn\n 在由 Istio 定义的 Service Mesh 体系中，服务治理相关逻辑由独立的 Sidecar 进程处理，如服务发现、故障注入、限流熔断等等。这些处理逻辑是 Service Mesh 着重要解决的问题。通常在谈论到 Service Mesh 时，会优先关注在这些点上，但是在落地过程中，有一个问题同等重要但往往容易被忽视。这个问题概括起来，就是流量是如何被导入到 Sidecar 的监听端口的。\n在数据平面的 Sidecar 中拦截进出应用容器的流量，这一直以来就是 Istio Service Mesh 中一切功能的基础，如何实现透明高效的拦截也是 Service Mesh 设计中的一大难点，本文为大家介绍云原生网络代理 MOSN 是如何做到这一点的。\n流量接管 如果服务注册/发布过程能够允许适当的修改，这个问题会得到极大的简化，比如 Sidecar 将服务发布方的监听地址修改为 127.0.0.1:20882，订阅方 Sidecar 监听本机 20882 端口，当订阅方访问 127.0.0.1:20882 时，流量就自然到达了本端 Sidecar。在这种情况下，无需在网络层面使用重定向技术就可以达到目的。\n服务发布订阅修改逻辑框图\n流量转发流程图\n如上图中，在发布服务时，Sidecar 将服务端原本的地址转换为 Sidecar 自身的端口；服务订阅时，订阅方获取到的端口则是本地 Sidecar 监听的端口。这一方案的优势很明显，逻辑都收敛在了 Sidecar 中，除了需要对 Sidecar 服务注册/发布流程进行改造外，不需要其他组件的参与，但是缺点也很明显，如果业务模型不存在注册中心，或者是服务发布/订阅 SDK 不能进行改造，这个方案就行不通了，而在 Mesh 落地场景中，这个条件恰恰较难满足。\n目前大多数业务的逻辑架构都不符合 Istio 定义的云原生体系，为了享受到 Service Mesh 在服务治理方面的优势，需要选择合适的流量劫持方案。一般而言，流量劫持工作在 L4 层，在进行劫持技术选型时需要考虑三个方面的问题：\n 第一是环境适配，包括容器、虚拟机、物理机、内核、系统发行版等方面的考虑，确保劫持方案在运行环境中能够正常工作； 第二是控制灵活简单，包括如何维护劫持规则，劫持规则如何下发等； 第三是性能，确保在业务运行期间，劫持本身不会带来过大的开销； 下面将从这三个层面分析 MOSN 在落地过程中的一些思考。\n环境适配 在环境适配性上，最容易想到的是 iptables，作为一项古典网络技术，iptables 使用简单，功能灵活，几乎所有现代生产级内核版本与 OS 发行版都默认具备使用条件，Istio 社区也使用 iptables 做流量透明劫持。\niptables 流量劫持原理图\n尽管环境适应性强，但是基于 iptables 实现透明劫持存在以下问题：\n DNAT 模式下，需要借助于 conntrack 模块实现连接跟踪，在连接数较多的情况下，会造成较大的消耗，同时可能会造成 track 表满的情况。为了避免这个问题，可以使用 TProxy 取代 DNAT，但受限于内核版本，TProxy 应用于 outbound 存在一定缺陷。 iptables 属于常用模块，全局生效，不能显式的禁止相关联的修改，可管控性比较差。 iptables 重定向流量本质上是通过 loopback 交换数据，outbond 流量将两次穿越协议栈，在大并发场景下会损失转发性能。 针对 oubound 流量，还可以使用 hook connect 来实现，如图所示：\nhook connect 逻辑框图\n无论采用哪种透明劫持方案，均需要解决获取真实目的 IP/端口的问题，使用 iptables 方案通过 getsockopt 方式获取，TProxy 可以直接读取目的地址，通过修改调用接口，hook connect 方案读取方式类似于 TProxy。\n由于 MOSN 落地的场景十分复杂，有容器与 VM 甚至物理机环境，有基于 K8s 的云原生应用，有基于注册中心的微服务，也存在单体应用，有些场景对性能要求非常高，有些则是够用即可，针对不同的场景，我们选择不同的劫持方案进行适配。如果应用程序通过注册中心发布/订阅服务时，可以结合注册中心劫持流量；在需要用到透明劫持的场景，如果性能压力不大，使用 iptables DNAT 即可，大并发压力下使用 TProxy 与 sockmap 改善性能。\n配置管理 通常基于申明式体系构建的服务在部署时能够得到全局信息，而非申明式体系往往需要在运行期间进行动态的配置修改，由于缺乏全局信息，在运行期间很难获取到准确的服务间调用信息。在生成透明劫持规则时，我们需要明确哪些流量要被重定向到 Sidecar，否则一旦出错，而 Sidecar 又无法处理这部分流量时，将会使得 Sidecar 变成流量黑洞，比如，某一个容器内的 TCP 流量全部被重定向至 Sidecar，而该容器中存在一个使用私有协议承载应用数据的监控 Agent，而 Sidecar 不能识别该协议导致无法争取转发，只能选择丢弃。\n通常情况下，为了确保 Sidecar 能够正确的转发流量，需要满足两个条件，首先是要能够正确识别协议，其次是需要配置转发规则，明确下一跳。对于不满足这两个条件的流量，不应将其重定向至 Sidecar。对于现有的非云原生应用，同时满足这两个条件的代价非常高，比如，某个虚拟机上运行了一个业务，同时还运行了收集 Metrics 的 Agent、日志采集工具、健康检查工具等等。而基于 L4 规则很难精确的将业务流量重定向至 Sidecar，如果多个业务混部，可能导致无法在 L4 层进行业务流量的区分。总结起来，为了精确的把流量引至 Sidecar，需要获得全局的调用关系，这一目标原本应该由 Service Mesh 来完成，而在流量劫持的场景下，却成为了 Service Mesh 的前提。\n为了使用 Service Mesh 而引入大量的部署运维开销是得不偿失的。在落地的过程中，MOSN 引入了多项手段来降低流量劫持的配置难度。我们将需要精确配置重定向规则的工作模式定义为精确匹配，与之相对应的是模糊匹配，即不要求精确区分出需要劫持的流量。降低配置难度的关键在于取消对于精确规则的依赖，在配置模糊规则的前提下，既做到对于关心的业务流量的治理，同时也不影响非业务流量的正常流程。\n我们采用 L4 规则与 L7 规则融合的方式下发模糊的匹配规则，此规则下除了包含关心的业务流量外，还可能包含预期之外的非业务流量。对于业务流量，Sidecar 根据相应的服务治 …","date":1589871600,"description":"如何实现透明高效的拦截也是 Service Mesh 设计中的一大难点，本文为大家介绍云原生网络代理 MOSN 是如何做到这一点的。","dir":"blog/mosn-transparent-hijacking/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c2505ec6bd3034e6cf3222dca8e1b83e","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-transparent-hijacking/","publishdate":"2020-05-19T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-transparent-hijacking/","summary":"MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简","tags":["MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 透明劫持技术解读 | 开源","type":"blog","url":"/sofastack.tech/blog/mosn-transparent-hijacking/","wordcount":3410},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n**1、@黄泽宏 **提问：\n SOFAJRaft 中 rheakv 不实现 region 新增删除，是因为分片迁移比较复杂么？\n A：不知道您说的新增删除是指什么？ 分裂与合并？ 分裂是有的，合并没有，不过分裂还没有经过严格的验证，也暂时不建议使用，分裂和合并确实比较复杂，复杂的不是分片迁移，分片迁移只要 raft 协议实现的没问题就是很自然的事情了。\n 对，sharding 合并分裂迁移，代码大概在哪个位置呢，想先看下实现。\n A：com.alipay.sofa.jraft.rhea.StoreEngine#applySplit 从这里看吧。 SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@廖景楷 提问：\n 请教 Seata 在做超时处理时怎么协调多个节点不会同时对某个事务做多次处理？还是说要求业务容许多次commit，rollback，Seata 就不协调了？ 我在测试 seata-server 多节点 HA 部署，用 MySQL 存储，看代码貌似所有节点都是无差别无状态的，在多个实例的 DefaultCoordiantor 里头有定时器去扫描超时的事务进行重试或者回滚，打开 general log 也发现有多个客户端 IP 在用同样的语句在扫描 global_table 表进行超时等处理。想确认一下多节点间是否有协调机制？ 我在 K8s下面部署3节点的 seata-server statefulset，镜像 docker.io/seataio/seata-server:latest 使用 Nacos 作为 registry。\n A：目前没有，多次不会导致数据问题，不过确实浪费资源，可以考虑引入分布式 job。\n 也就是说比如同一个超时的未 commit Global Session 被多个节点同时扫描到，可能会调用业务做多次 commit，然后由业务自己去重？\n A：是的，不过不是业务处理，框架会处理。\n3、@Cheng cheng 提问：\n 最近正在做 Seata 跟我们产品集成到研究，问一个小白问题，我们需要把 Seata 部署到 K8s 里，那么如果 Seata server 的一个 pod 突然挂了，那在途的调用会突然中断，这样依然可以完美控制事务达成数据一致性吗？\n A：如果 Server 是公用的一个 DB，理论上没问题的。\n 没有理解你说的公用 DB\u0026amp;hellip;. Seata Server 在 K8s 上用独立的几个 pod 部署，那相应的我们会给它单独创建数据库。\n A：Seata 高可用要求就是需要 server 的集群共用同一个 Seata 库，不然无法数据共享，也就是无法知晓当前运作的事务信息。首先你要保证 Server 集群用的同一个注册中心集群，并且共用同一个 Seata 库，这样才能保障数据共享、高可用。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Mecha：将 Mesh 进行到底 陌陌的 Service Mesh 探索与实践 | 线上直播回顾 《Service Mesh Virtual Meetup#1》：视频回顾 *SOFA 项目进展* 本周发布详情如下：\n1、发布 SOFABoot v3.4.0 版本，主要变更如下：\n 支持基于 gRPC 的 triple 协议； 修复 bolt callback 方式的兼容问题； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.0\n2、发布 SOFAHessian v4.0.4 版本，主要变更如下：\n 修复 JDK 判断逻辑有锁问题； 修复 _staticTypeMap 为 ConcurrentMap，和 v3.x 对齐； 详细发布报告： https://github.com/sofastack/sofa-hessian/releases/tag/v4.0.4\n社区直播报名 在云原生时代，容器和 Kubernetes 在日常工作和实际生产中越来越普遍，随之而来的隔离性问题在不断被提起同时也受到了越来越多的关注。\nSOFAChannel#16 线上直播带来《不得不说的云原生隔离性》分享，将邀请 Kata Containers 维护者彭涛（花名：巴德）带我们走近云原生基础设施 \u0026amp;ndash; Kata Containers，详细分享它是如何在云原生框架下解决容器隔离性问题的。\n将从以下几个方面，与大家交流分享：\n 从 Kubernetes Pod 说起，经典容器场景下的 Pod 分享； 共享内核存在的问题以及解决办法； 上帝说，要有光；我们说，要有 Kata； The speed of containers, the security of VMs； Kata Containers 特性大放送； What? 你刚说过增加一个 VM 间接层的问题？ 活动详情：\n 直播主题：SOFAChannel#16：不得不说的云原生隔离性 直播时间：2020/5/21（周四）19:00-20:00 报名方式：点击“这里”，即可报名 ","date":1589533200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200515/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f02bec7b5443778e602b655210ee33fb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200515/","publishdate":"2020-05-15T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200515/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot\u0026SOFAHessian 发布、5/21 社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200515/","wordcount":1781},{"author":"敖小剑","categories":"Service Mesh","content":" 内容摘要：Service Mesh 落地实践三年，效果一直并不理想，到了该反思的时候了。Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化版本，预计也将是云原生化和 Mesh 化的必然趋势，让我们将 Mesh 进行到底。\nMecha 介绍 什么是 Macha？ Mecha 一词，相信爱好动漫的同学应该都不陌生。是的，就是大家熟悉的那个 Mecha（机甲）：\nMecha 这个词之所以出现在这里，主要是因为 Bilgin Ibryam 的这个博客文章 “Multi-Runtime Microservices Architecture”，提出了微服务架构的一个新的设想：Multiple Runtime。\n 备注：这篇博客文章强烈推荐阅读，我甚至建议在阅读本文之前先阅读这篇文章，因为我今天的内容，可以视为对这个文章的深度解读和思考。为了方便，这里提供一份中文翻译版本 多运行时微服务架构。\n 在这篇博客中，Bilgin Ibryam 首先分析并总结了分布式应用的四大需求:\n 生命周期（Lifecycle） 网络（Networking） 状态（State） 捆绑（Binding） 由于每种需求存在的问题和局限性，导致传统解决方案如企业服务总线（ESB）及其变体（例如面向消息的中间件，更轻量级的集成框架等）不再适用。随着微服务架构的发展，以及容器和 Kubernetes 的普及和广泛使用，云原生思想开始影响这些需求的实现方式。未来的架构趋势是通过将所有传统的中间件功能移至其他运行时来全面发展，最后的目标是在服务中只需编写业务逻辑。\n 备注：详情请见原文，为了节约篇幅，这里只做简单概述，不完全引用原文内容。\n 下图是传统中间件平台和云原生平台的对比，传统中间件以各种SDK的方式提供能力，而云原生平台则通过各种外围Runtime（典型如大家熟悉的Servicemesh/Istio）：\n因此作者引入了 Multiple Runtime 的概念：\n作者提出：很可能在将来，我们最终将使用多个运行时来实现分布式系统。多个运行时，不是因为有多个微服务，而是因为每个微服务都将由多个运行时组成，最有可能是两个运行时-自定义业务逻辑运行时和分布式原语运行时。\n对多运行时微服务架构和 Mecha 的说明：\n 您还记得电影《阿凡达》和科学家们制作的用于去野外探索潘多拉的 Amplified Mobility Platform (AMP)“机车服”吗？这个多运行时架构类似于这些 Mecha-套装，为人形驾驶员赋予超能力。在电影中，您要穿上套装才能获得力量并获得破坏性武器。在这个软件架构中，您将拥有构成应用核心的业务逻辑（称为微逻辑/micrologic）和提供强大的开箱即用的分布式原语的 Sidecar Mecha 组件。Micrologic 与 Mecha 功能相结合，形成多运行时微服务，该服务将进程外功能用于其分布式系统需求。最棒的是，Avatar 2 即将面世，以帮助推广这种架构。我们最终可以在所有软件会议上用令人赞叹的机甲图片代替老式的边车摩托车；-)。接下来，让我们看看该软件架构的详细信息。 这是一个类似于客户端-服务器体系结构的双组件模型，其中每个组件都是独立的运行时。它与纯客户端-服务器架构的不同之处在于，这两个组件都位于同一主机上，彼此之间有可靠的网络连接。这两个组件的重要性相当，它们可以在任一方向上发起操作并充当客户端或服务器。其中的一个组件称为 Micrologic，拥有非常少的业务逻辑，把几乎所有分布式系统问题都剥离出去了。另一个伴随的组件是 Mecha，提供了我们在本文中一直讨论的所有分布式系统功能（生命周期除外，它是平台功能）。\n 作者在这里正式提出了 Mecha 的理念：\n思路大体是：Smart Runtime， Dumb Pipes。\n我对 Mecha 的理解是：业务逻辑在编码开始阶段应该是“裸奔”的，专注于业务逻辑的实现，而尽量不涉及到底层实现逻辑；而在运行时，则应该装备“机甲”，全副武装，大杀四方。熟悉的味道是吧？标准而地道的云原生思想。\nMecha 的本质 作者在原文中探讨了 Mecha 运行时的特性：\n Mecha 是通用的，高度可配置的，可重用的组件，提供分布式原语作为现成的能力。 Mecha 可以与单个 Micrologic 组件一起部署(Sidecar 模式)，也可以部署为多个共享(注：我称之为 Node 模式)。 Mecha 不对 Micrologic 运行时做任何假设，它与使用开放协议和格式（例如 HTTP/gRPC、JSON、Protobuf、CloudEvents）的多语言微服务甚至单体一起使用。 Mecha 以简单的文本格式（例如 YAML、JSON）声明式地配置，指示要启用的功能以及如何将其绑定到Micrologic 端点。 与其依靠多个代理来实现不同的目的（例如网络代理、缓存代理、绑定代理），不如使用一个 Mecha 提供所有这些能力。 下面是我对上述特性的个人理解：\n Mecha 提供的是能力，以分布式原语体现的各种能力，而不局限于单纯的网络代理。 Mecha 的部署模型，不局限于 Sidecar 模式，Node 模式在某些场景下（如 Edge/IoT，Serverless FaaS）可能会是更好的方式。至少，Mecha下有机会按需选择，而不是绑死在 Sidecar 模式上。 Mecha 和 Micrologic 之间的交互是开放而有 API 标准的，Mecha 和 Micrologic 之间的“协议”体现在 API 上，而不是 TCP 通讯协议。这提供了一个契机：一个统一 Micrologic 和 Mecha 之间通讯方式的契机。 Mecha 可以以声明式的方式进行配置和控制，这非常符合云原生的理念，同样也使得 API 更关注于能力本身，而不是能力如何配置。 应用需要的能力如此之多（参见上面的图：分布式应用的四大需求），如果每个能力都对应一个代理（不管是 Node 还是 Sidecar），数量会非常夸张，带来的运维压力会很可怕。因此，如 Mecha 这个名字暗示的，运行时应该是整套的形式提供能力，而不是分散。 如果用一句话来总结，那么我认为 Mecha 的本质应该是：\n“面向应用的分布式能力抽象层”\n如 Service Mesh 的本质是服务间通讯的抽象层一样，Mecha 的本质是应用需要的各种分布式能力和原语，包括但不限于服务间通讯。\n从这个角度上说，Mecha 覆盖的范围是 Service Mesh 的超集：毕竟 Service Mesh 只覆盖到应用的部分需求（服务间通讯，还只限于同步/一对一/request-response 模式），还有更多的分布式能力和原语有待覆盖。\n换一句话说，Mecha 的目标应该是：“将 Mesh 进行到底！”\nMecha 的优势和未来 作者指出：Mecha 的好处是业务逻辑和越来越多的分布式系统问题之间的松耦合。\n下图是业务逻辑和分布式系统问题在不同架构中的耦合：\n其实思路和 Service Mesh 是一脉相承的，只是覆盖的分布式能力更广泛一些。\n有一个问题：Mecha 会不会成为微 …","date":1589364000,"description":"Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化版本，预计也将是云原生化和 Mesh 化的必然趋势，让我们将 Mesh 进行到底。","dir":"blog/mecha-carry-mesh-to-the-end/","fuzzywordcount":7500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2ef4b817d0dc0018551a25d24b174ee0","permalink":"https://sofastack.github.io/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","publishdate":"2020-05-13T18:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","summary":"内容摘要：Service Mesh 落地实践三年，效果一直并不理想，到了该反思的时候了。Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化","tags":["Service Mesh"],"title":"Mecha：将 Mesh 进行到底","type":"blog","url":"/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","wordcount":7479},{"author":"高飞航","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。\n本文根据5月6日晚，陌陌中间件架构师高飞航的主题分享《陌陌的 Service Mesh 探索与实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 本次演讲为大家分享的是陌陌目前正在进行的 Service Mesh 实践的相关内容。共分为三个部分：\n 第一部分是原有微服务架构的相关背景； 第二部分是原有架构遇到的问题以及决定采用 Service Mesh 方案的思考过程； 最后的部分对Service Mesh落地实践的方案进行介绍； 陌陌微服务体系演进历程 单体应用到微服务 各个应用的发展过程，都会经历从单体应用、到应用拆分再到微服务架构这样一个过程。陌陌的这个演进过程，有一点比较特别的是，在应用拆分时加入了由 PHP 开发、与客户端 App 进行对接的 API 层，并采用 Java 开发底层具有复杂运算的业务逻辑，这样能够兼得 PHP 的开发效率与 Java 高性能的优势。\n但这个选择的影响也是十分深远的，由于 PHP 在业务中的比重很高，我们在后续进行微服务改造和服务治理时，需要不断地去应对多语言架构带来的挑战。\n微服务体系演进 陌陌的微服务架构改造从 2013 年就开始了，在当时还没有较为完善的服务框架产品的情况下，我们自研了服务框架产品 MOA，支撑了陌陌 IM、附近动态、直播、短视频等核心业务的高速发展历程。\n在多年的迭代发展中，我们逐步完善了服务框架产品功能，同时也扩充了其他基础架构产品，最终形成了一个完善的微服务体系。其他基础架构产品也都是采用了自研的方案，因此整体是一个非常定制化的架构。这一点也成为后续 Service Mesh 落地选型时重点要考量的因素。\n微服务体系整体架构 下面对微服务体系的整体架构进行介绍。我们采用了一个 Redis 作为底层存储的注册中心。服务实例的存活检测主要依赖一个中心化的检测应用 MOA Watcher，能够将无法连通的实例从注册中心的在线列表中移除、摘除实例的业务流量。\n在多语言支持方面，我们除了支持最核心的 Java 与 PHP 应用之外，后续还支持了 Python、C++、Go、NodeJS 等非常多的语言接入微服务体系。由于陌陌的中间件团队是以 Java 工程师为主导的，服务框架组件的核心产品也是一个 Java 的 SDK。在没有足够的资源投入到其他语言 SDK 开发的情况下，我们采用了很多能够简化多语言开发工作的方案。\n例如跨语言调用和 Java 应用内部调用会采用不同的协议，Java 内部是较为传统的自定义二进制传输协议与 Hessian 序列化，跨语言则采用了 Redis 传输协议与 JSON 序列化。Redis 协议分别利用 GET 命令的 key 和 value 的位置传递 Request 和 Response，这样每种语言都可以基于成熟的 Redis 客户端开发 SDK，避免重复编写复杂的网络通信逻辑。此外还增加了一个地址发现服务 Lookup，使其他语言能够像调用普通服务的方式，轮询获取目标服务地址。跨语言场景的这些方案虽然简化了开发工作，但却不是最优方案。这也为整体架构的长期发展埋下了隐患。\n微服务体系的其他产品还包括统一的配置中心、监控平台、日志采集平台、分布式跟踪系统等，这些都是为微服务体系保驾护航的重要基础架构能力。\n流量代理机制 在多语言支持的场景中，我们很早就采用了两个和 Service Mesh 非常相近的方案。一个是为了支持多语言发布服务的入流量代理方案，使用 Java 开发的 Proxy 复用了 Java SDK 注册发现与监控等诸多服务治理能力，使得其他语言仅简单处理本地请求后就能实现发布服务。这些 Java Proxy 与多语言的业务进程是 1:1 部署的，但当时的方案是和业务进程放在一个容器里，升级时需要和业务进程一起重新发布。\n另外一个方案是为了解决 PHP 并行调用下游服务而实现的出流量代理，但这个方案中代理层的进程是运行在独立的服务器上，没有部署在与调用端相同的服务器。\n我们将流量代理机制应用于多语言服务治理的经历，在某种程度上突显了 Service Mesh 的价值，我们可能想到类似的方案去解决问题，但都没有像 Service Mesh 一样系统地给出一种最佳方案。不过这些相近方案的经验是有助于我们后续去推进 Service Mesh 落地的。\n微服务体系规模 随着业务的发展，整个微服务体系也达到了一个很具有挑战的量级。特别是在服务数量大幅增长后，Java 应用的服务治理问题也逐步暴露出来，其中最难以解决的是 SDK 升级的问题，这一点也是进一步推动我们转向 Service Mesh 架构的原因。\n借助 Service Mesh 解决现有架构痛点 架构痛点分析  前面我们提到的各种问题，其实都可以归结为微服务体系中服务治理能力滞后的问题。对于非 Java 的应用，由于没有足够的开发资源，会导致服务框架的 SDK 迭代进度非常缓慢。对于 Java 应用，虽然 SDK 具备最完善的功能，但使全量应用完成升级需要耗费大量人力和时间。根据以往的经验来看，一次推广至少需要一个季度的时间，并且为业务团队带来很多不必要的负担。\n两种场景最终的危害是一致的，都会导致架构能力上无法实现统一，先进的功能无法覆盖到全部应用，使应用稳定性受到损失，甚至引发故障。我们在多语言方案中依赖的中心化的 Lookup 服务，曾经就因为一次服务异常导致整个 API 层不可用，原因就是 PHP 的 SDK 采用了一种有缺陷的机制没有升级。在我们设计新方案时，也会因为架构能力无法统一而无法采用最佳的方案。例如我们在设计多机房架构时，由于流量调度机制无法快速覆盖到全部应用，因此只能采用从应用入口整体调度流量的一种粗粒度的方案。\n引入 Service Mesh Service Mesh 将基础架构逻辑与业务逻辑解耦、并支持独立升级的方式，能够很好地解决前面描述的架构痛点。但引入 Service Mesh 是一项非常重大的架构变更，并且需要多方面的成本投入。因此在实际落地实施前，我们必须思考以下几个问题，并在不同阶段完成对应的工作。\n 第一个是方案是否足够成熟。这里的方案不局限于 Service Mesh 本身，也依赖公司内其他基础设施的演进积累。例如我们在观察阶段实现了应用容化的推广覆盖、日志 Agent 方案的经验积累等。 第二个是遇到的问题是否有其他替代方案。例如我们之前急需在多语言场景覆盖的一个能力是流量调度机制，尝试过一个只提供地址路由机制，不代理流量的 Agent 方案。 …","date":1589266800,"description":"本文根据5月6日晚，陌陌中间件架构师高飞航的主题分享《陌陌的 Service Mesh 探索与实践》整理。","dir":"blog/momo-service-mesh-exploration-and-practice/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9c4d2df383550d5412e3de24312862ed","permalink":"https://sofastack.github.io/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","publishdate":"2020-05-12T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌","tags":["Service Mesh"],"title":"陌陌的 Service Mesh 探索与实践 - 直播回顾","type":"blog","url":"/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","wordcount":6499},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n**SOFAStack 官网: **https://www.sofastack.tech\n**SOFAStack: **https://github.com/sofastack\n社区大事件 MOSN 社区新认证一位 Committer\n孙福泽（@peacocktrain）认证成为 MOSN Committer：\n主要贡献： 贡献 3 个 feature PR\n 使 MOSN 支持 Istio 1.4； 协议支持 HTTP2 双向流式； 添加管道缓冲区； MOSN：https://github.com/mosn/mosn\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n**1、@chromosome **提问：\n 这个视频中提到因为 log server 中存储得到 commitedId 和 applyId 不是任意时刻都同步的，这样的话，如果说状态机的 apply 速度较慢，很可能 client 的 read request 并不能读取到状态机最新 committed 的操作的结果。 https://tech.antfin.com/community/live/821/data/902\n A：commitedIndex 和 applyIndex 的不完全同步，并不影响 read request 的结果，所以上面的后半句理解还是有点问题，可以看一下 SOFAJRaft 线性一致读的原理介绍，参考这个链接线性一致读章节 https://www.sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/\n 所以 counter 例子中的 readindex 写法就是为了读线性一致性吗？例如 this.counterServer.getNode().readindex\n A：是的。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、**@王勇 **提问：\n 在 AT 模式下，事务的回滚如何补偿三方的缓存操作呢？有没有额外的接口，还是只能是变成 TC 模式，或是自己写 aop？\n A：TCC 嵌套 AT，TCC 二阶段行为做补充。\n TCC 内应该说是不存在 AT 吧。\n A：AT 保证数据库的一致性，TCC 做来二阶段时的三方处理，比如发出 MQ 消息、缓存之类的。\n 就是 AT 和 TCC 在同一全局事务中一起使用是吧。这个 TCC 一阶段可以是空的，二阶段回滚时清理缓存嘛？\n A：嗯。\n OK，我明白了。就是让 TCC 嵌套 AT，通常情况下 TCC 为空，需要补偿的时候向 TCC 里写入东西。\n A：可以这么说，如果 TCC 触发二阶段是回滚，你就把缓存删掉，如果是提交就啥也不干，大概是这么个意思。\n TCC 模式下 AT 是默认的吗？对于大事务，Saga 模式，您用过吗？\n A：一、首先需要创建状态机引擎的 bean。 1.2.0里，状态机引擎的 bean 需要自己创建的。 1.3.0里，spring-boot-starter-seata 里会提供自动配置类。（可以先参考我修改过的代码吧。https://github.com/wangliang1986/seata） 二、需要创建 Saga 模式所需的三张表。github 上可以找到建表 SQL。 三、使用 Seata 的在线状态机设计器来定义流程。地址：http://seata.io/saga_designer/index.html 四、将设计器生成的 json 文件放到自己项目的 resources 中，由状态机引擎去加载它。状态机配置类中有一个配置项可以配置 json 文件路径。 五、使用状态机引擎启动 Saga 事务即可。（要注意的是 1.2.0 版本中，Saga 无法与 AT 一起启用。1.3.0 将修复此问题。） Seata：https://github.com/seata/seata\n本周推荐阅读 （含直播报名）Kata Containers 创始人：安全容器导论 蚂蚁金服 SOFAJRaft 优先级选举剖析 | 特性解析 Service Mesh 和 API Gateway 关系深度探讨 SOFA 项目进展 本周发布详情如下：\n1、发布SOFARPC v5.7.0,主要变更如下：\n 支持基于 grpc 的 triple 协议； 重构项目模块结构； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.0\n2、发布 SOFA MOSN v0.12.0，主要变更如下：\n 支持 SkyWalking； 支持流式 HTTP2； 熔断功能、负载均衡逻辑优化，负载均衡新增 ActiveRequest 和 WRR 算法； 优化 HTTP 连接建立性能； 底层实现优化； Bug Fix； 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/v0.12.0\n社区直播报名 本期为第一期 Service Mesh Virtual Meetup 线上系列直播第一期，邀请了四位来自不同公司的嘉宾，从四个角度对 Service Mesh 的应用实践展开分享。\n本次线直播分享涵盖 Service Mesh 的可观察性和生产实践，为大家介绍 Service Mesh 中的可观察性与传统微服务中可观察性的区别，如何使用 SkyWalking 来观测 Service Mesh，还有来自百度和陌陌的 Service Mesh 生产实践。\n本系列采用线上直播的形式，从 5 月 6 日开始到 5 月 14 日，每周三、周四晚上 19:00-20:00 我们相约进行一个主题分享。\n 时间 分享主题 分享嘉宾 嘉宾介绍 5\u0026amp;frasl;6 陌陌的 Service Mesh 实践 高飞航 陌陌中间件架构师 5\u0026amp;frasl;7 Apache SkyWalking 在 Service Mesh 中的可观察性应用 高洪涛 Tetrate 创始工程师 5\u0026amp;frasl;13 Servicre Mesh 高可用在企业级生产中的实践 罗广明 百度高级研发工程师 5\u0026amp;frasl;14 Servicre Mesh 中的可观察性实践 叶志远 G7 微服务架构师 观看直播方式：点击“这里”，关注直播 …","date":1588928400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200508/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c743041c871c1b4fdd685334ab29add6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200508/","publishdate":"2020-05-08T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200508/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN\u0026amp;SOFARPC 发布、社区活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200508/","wordcount":1872},{"author":"王旭","categories":"Kata Container","content":" 从2015年5月初开始创业开发 HyperContainer (runV) 到现在，也快五年了，在这个时候还来写一篇什么是安全容器，显得略有尴尬。不过，也正是经过这五年，越来越多到人开始感到，我需要它却说不清它，这个时候来给大家重新解释 “\u0026amp;gt; 安全容器” 也正是时候。\n缘起：安全容器的命名 Phil Karlton 有一句名言—— _计算机科学界只有两个真正的难题——缓存失效和命名。_ 就容器圈而言，我相信命名绝对配得上这句话，这毫无疑问是一件让老开发者沉默，让新人落泪的事情。\n仅就系统软件而言，我们当今比较通行地称为 Linux 容器（LinuxContainer）的这个概念，曾经用过的名字大概还有——jail, zone, virtualserver, sandbox\u0026amp;hellip; 而同样，在早期的虚拟化技术栈里，也曾经把一个虚拟机环境叫做容器。毕竟这个词本身就指代着那些用来包容、封装和隔离的器物，实在是太过常见。以至于，以严谨著称的 Wikipedia 里，这类技术的词条叫做“系统级虚拟化”，从而回避了“什么是容器”这个问题。\n当2013年 Docker 问世之后，容器这个概念伴随着“不可变基础设施”、“云原生”这一系列概念，在随后的几年间，以摧枯拉朽之势颠覆了基于“软件包+配置”的细粒度组合的应用部署困境，用简单地声明式策略+不可变容器就清爽地描述了软件栈。应用怎么部署似乎离题了，我们这里想要强调的是——\n云原生语境下的容器，实质是“应用容器”——以标准格式封装的，运行于标准操作系统环境（常常是 Linux ABI）上的应用打包——或运行这一应用打包的程序/技术。\n这个定义是我在这里写下的，但是它并不是我的个人意志，这是基于 OCI (Open ContainerInitiative) 规范这一共识的，这个规范规定了容器之中的应用将被放置在什么环境中，如何运行，比如启动容器根文件系统上的哪个可执行文件，用什么用户，需要什么样的 CPU、内存资源，有什么外置存储，有什么样的共享需求等等。\n有了这一共识做基础，我们来说安全容器，这又是一段命名血泪史。当年，我的联合创始人赵鹏是用“虚拟化容器”命名的我们的技术的，为了搏人眼球，用了“Secure as VM, Fast asContainer”的大字标语，自此，被容器安全性问题戳中心坎的人们立刻用“Secure Container”来称呼这类东西，一发而不可收。而我们的内心中，这项技术提供了一层额外的隔离，隔离可能意味着安全性中的一环，也意味着某些运维效率、某些优化可能或者其他的功能。实际上，给安全容器这样的定义更合理——\n一种运行时技术，为容器应用提供一个完整的操作系统执行环境（常常是 LinuxABI），但将应用的执行与宿主机操作系统隔离开，避免应用直接访问主机资源，从而可以在容器主机之间或容器之间提供额外的保护。\n间接层：安全容器的精髓 安全问题的唯一正解在于允许那些（导致安全问题的）Bug 发生，但通过额外的隔离层来阻挡住它们。 —— LinuxCon NA 2015, Linus Torvalds 为了安全，为什么要引入间接层？因为以 Linux 之类的目前主流宿主机操作系统的规模，是无法从理论上验证程序是没有 Bug 的，而一旦合适的 Bug 被合适地利用，安全性风险就变成了安全性问题了，框架和修补并不能确保安全，所以，进行额外的隔离、缩减攻击面，就成了缓解安全问题的法宝——我们不能确保没有漏洞，但我们通过组合来减少漏洞被彻底攻破的风险。\nKata: 云原生化的虚拟化 2017年12月，我们在 KubeCon上对外发布了 Kata Containers 安全容器项目，这个项目的两个前身——我们发起的的 runV 和Intel 发起的 Clear Container 都发布于2015年5月（是的，早于上面 Linus 的引语）。这组项目的思路很简单 ——   操作系统本身的容器机制没办法解决安全性问题，需要一个隔离层；  虚拟机是一个现成的隔离层，AWS 这样的云服务已经让全世界相信，对户来说，\u0026amp;rdquo;secure of VM\u0026amp;rdquo; 是可以满足需求的；  虚机里面只要有个内核，就可以支持 OCI 规范的语义，在内核上跑个 Linux 应用这并不太难实现；  虚机可能不够快，阻碍了它在容器环境的应用，那么可不可以拥有 \u0026amp;ldquo;speed of container\u0026amp;rdquo; 呢？  现在，如果最后一个问题可以解决，那么它就是我们要的“安全的容器”了——这就是 Kata Containers。 目前 Kata Containers 通常是在 Kubernetes 环境中使用的，Kubelet 通过CRI 接口让 containerd 或 CRI-O 执行运行时操作，通常镜像操作由这些 CRI Daemon 来进行，而根据请求，把 Runtime 操作写成一个 OCI Spec 交给 OCI Runtime 执行。这里，对于 1.2 以上的 containerd 和 1.5 版本上后的 Kata Containers（对应 ），通常是利用 containerd 来完成的：\n 每个 Pod 会有一个 shim-v2 进程来为 containerd/CRI-O 执行各种运行时操作，这个进程和整个 Pod 的生命周期一致，通过一个 ttRPC 接口为 containerd/CRI-O 提供服务； Shim-v2 会为 Pod 启动一个虚拟机作为 PodSandbox提供隔离性，其中运行着一个 Linux 内核，通常这个 Linux 内核是一个裁剪过的内核，不会支持没有必要的设备； 这里用的虚拟机可以是 Qemu 或是 Firecracker，如果是 Firecracker，那么根本就没有模拟的设备，而如果是 Qemu，通过配置和补丁，也会让它尽量小一些，支持的其他虚拟机还包括 ACRN 和 cloud-hypervisor，未来后者可能会被越来越多的用到； 这个虚拟机在启动的时候可能根本就是一个 initrd 而没有完整操作系统，或者有个极小的操作系统，总之，它完全不是按照一台模拟机的操作系统来配置的，它只是支撑容器应用运行的基础设施，以及相关的应用环境 Metrics 采集或应用跟踪调试需要的资源； 容器本身的 rootfs 会在 Sandbox 启动之后，在收到 contaienrd/CRI-O 的创建容器的 OCI 请求之后，以热插拔的方式动态插入到虚机中，容器的 rootfs 准备和虚机本身的启动是可以并行的； 依照 CRI 语义和 OCI 规范，Pod 里可以启动多个相关联的容器，它们被放在同一个虚机里，并且可以互相共享 namespace； 外来的存储卷可以以块设备或文件系统共享的方式插入到 PodSandbox 中，但对于 Pod 里的容器来说，它们都是加载好的文件系统，目前开始逐渐普及的文件系统方式是专为 Kata 这样的场景设计的 virtio-fs，它不仅比传统的 9pfs 更快、有更完整的 POSIX 文件系统的支持，而且借由所谓 vhost-user 和 DAX 技术，它还可以在不 …","date":1588921200,"description":"隔离，让云原生基础设施更完美。","dir":"blog/kata-container-introduction-to-safe-containers/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6075ee3441970bada70f11c633f4ba85","permalink":"https://sofastack.github.io/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","publishdate":"2020-05-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","summary":"从2015年5月初开始创业开发 HyperContainer (runV) 到现在，也快五年了，在这个时候还来写一篇什么是安全容器，显得略有尴尬。不过，也正是经过这五年，越来越多到人","tags":["Kata Container"],"title":"（含直播报名）Kata Containers 创始人：安全容器导论","type":"blog","url":"/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","wordcount":4686},{"author":"Committer 胡宗棠","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文作者胡宗棠，SOFAJRaft Committer，来自中国移动。本文主要介绍 SOFAJRaft 在 Leader 选举过程中的重要优化方案—一种半确定性的优先级选举机制，将会先简单地介绍下原 Raft 算法中随机超时选举机制的大致内容，如果读者对这块内容理解得不够深入，建议可以先阅读下《SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理》。阅读完这篇文章后，再来看本篇的内容会对半确定性的优先级选举机制有更为深刻的理解。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n一、Raft 算法中选举机制的概念与特点 Raft 算法是一种“共识性”算法，这里所谓的“共识性”主要体现在让多个参与者针对某一件事达成完全一致：一件事一个结论，同时对已达成一致的结论，是不可推翻的。基于这个根本特征，就决定了 Raft 算法具有以下几个主要特点：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成。这是主要为了保证在任何的时间段内，Raft 集群最多只能存在一个 Leader 角色的节点； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务； 在 Raft 算法中，选举是很重要的一部分。所谓选举就是在由多个节点组成的一个 Raft 集群中选出一个 Leader 节点，由他来对外提供写服务 （以及默认情况下的读服务）。\n这里先介绍一个任期的概念—Term， 其用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。同时，该 Term ID 的值是按照时间轴单调递增的，它构成了 Raft Leader 选举的必要属性。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。为了让 Raft 集群中的所有节点尽可能的客观公平公正，采用了随机超时时间触发选举，来避免若干个节点在同一时刻尝试选举而导致选票被瓜分的情况，保证选举的顺利完成。SOFAJRaft 的做法是，在 Node 触发选举的定时任务— electionTimer 中的设置每次定时执行的时间点：时间区间 [electionTimeoutMs，electionTimeoutMs + maxElectionDelayMs) 中的任何时间点。\n在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求； 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳； 同时，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。当选举 Leader 选举成功后，整个 Raft 集群就可以正常地向外提供读写服务了，如上图所示，集群由一个 Leader 和两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳和将日志 Log 复制给 Follower。\n但 Raft 算法的“随机超时时间选举机制”存在如下问题和限制：\n 下一个任期 Term，Raft 集群中谁会成为 Leader 角色是不确定的，集群中的其他节点成为 Leader 角色的随机性较强，无法预估。试想这样的一个场景：假设部署 Raft 集群的服务器采用不同性能规格，业务用户总是期望 Leader 角色节点总是在性能最强的服务器上，这样能够为客户端提供较好的读写能力，而上面这种“随机超时时间选举机制”将不能满足需求； 如上图所示，由于会存在选票被瓜分的场景，集群中的各个 Candidate 角色节点将在下一个周期内重新发起选举。而在这个极短的时间内，由于集群中不存在 Leader 角色所以是无法正常向客户端提供读写能力，因此业务用户需要通过其他方式来避免短时间的不可用造成的影响； 二、SOFAJRaft 基于优先级的半确定性选举机制 2.1 SOFAJRaft 基于优先级选举机制的原理 为了解决原本 Raft 算法“随机超时时间选举机制”带来的问题，增加选举的确定性，作者贡献了一种“基于优先级的半确定性选举机制”。主要的算法思想是：通过配置参数的方式预先定义 Raft 集群中各个节点的 priority 选举优先级的值，每个 Raft 节点进程在启动运行后是能够知道集群中所有节点的 priority 的值（包括它自身的、本地会维护 priority 变量）。\n对每个 Raft 节点的配置如下（下面以其中一个节点的配置举例），其中 PeerId 的字符串值的具体形式为：{ip}:{port}:{index}:{priority}；\n在 Raft 节点进程初始化阶段，通过对所有节点 priority 值求最大值来设置至节点自身维护的 targetPriority 本地全局变量里。在上面这个例子中，节点的 targetPriority 本地全局变量值就被设置为 160，而自身的 priority 值为 100。\n在每个 Raft 节点通过随机超时机制触发 PreVote 预选举阶段之前，会通过先比较自身的 priority 值和 targetPriority 值来决定是否参加本轮的 Leader 选举投票。所以，一组 Raft 节点组成的集群在刚启动运行的阶段，priority 值最大的节点（上面例子中 160 的那个节点）必然会优先被选择成为这个集群中 Leader 角色的节点向外提供读和写的服务。\n2.2 SOFAJRaft 优先级选 …","date":1588759200,"description":"继源码解析系列后，推出特性解析系列，本文为 SOFAJRaft 特性解析第一篇，主要介绍 SOFAJRaft 在 Leader 选举过程中的重要优化方案—一种半确定性的优先级选举机制。","dir":"blog/sofa-jraft-priority-election/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d867df257326471e46ce05ed548f72e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-priority-election/","publishdate":"2020-05-06T18:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-jraft-priority-election/","summary":"SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFAJRaft 特性解析"],"title":"蚂蚁金服 SOFAJRaft 优先级选举剖析 | 特性解析","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-priority-election/","wordcount":5415},{"author":"敖小剑","categories":"Service Mesh","content":" 前言 关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做一个资料的整理和汇总，结合个人的理解给出一些看法。另外在本文最后，介绍蚂蚁金服在 Service Mesh 和 API Gateway 融合的这个最新领域的一些开创性的实践和探索，希望给大家一个更有体感的认知。\n 备注1：为了节约篇幅，我们将直奔主题，假定读者对 Service Mesh 和 API Gateway 已有基本的了解。 备注2: 这边文章更关注于梳理整个脉络，内容不会展开的特别细，尤其是其他文章已经详细阐述的部分。如果您在浏览本文之后，还想更深入的了解细节，请继续阅读文章最后的参考资料和推荐阅读。\n 原本清晰的界限：定位和职责 首先，Service Mesh 和 API Gateway 在功能定位和承担的职责上有非常清晰的界限：\n Service Mesh：微服务的网络通信基础设施，负责（系统内部的）服务间的通讯； API Gateway： 负责将服务以 API 的形式暴露（给系统外部），以实现业务功能； 如上图所示：\n从功能和职责上说：\n 位于最底层的是拆分好的原子微服务，以服务的形式提供各种能力； 在原子微服务上是（可选的）组合服务，某些场景下需要将若干微服务的能力组合起来形成新的服务； 原子微服务和组合服务部署于 系统内部，在采用 Service Mesh 的情况下，由 Service Mesh 提供服务间通讯的能力； API Gateway 用于将系统内部的这些服务暴露给 系统外部，以 API 的形式接受外部请求； 从部署上说：\n Service Mesh 部署在系统内部：因为原子微服务和组合服务通常不会直接暴露给外部系统； API Gateway 部署在系统的边缘：一方面暴露在系统之外，对外提供 API 供外部系统访问；一方面部署在系统内部，以访问内部的各种服务。 在这里引入两个使用非常广泛的术语：\n 东西向通讯：指服务间的相互访问，其通讯流量在服务间流转，流量都位于系统内部； 南北向通讯：指服务对外部提供访问，通常是通过 API Gateway 提供的 API 对外部保罗，其通讯流量是从系统外部进入系统内部； 解释一下“东西南北”的由来：如上图所示，通常在地图上习惯性的遵循“上北下南，左东右西”的原则。\n 总结：Service Mesh 和 API Gateway 在功能和职责上分工明确，界限清晰。但如果事情就这么结束，也就不会出现 Service Mesh 和 API Gateway 关系的讨论了，自然也不会有本文。\n问题的根源在哪里？\n 强烈推荐阅读：附录中 Christian Posta 的文章 \u0026amp;ldquo;Do I Need an API Gateway if I Use a Service Mesh?\u0026amp;ldquo;对此有深度分析和讲解。\n 哲学问题：网关访问内部服务，算东西向还是南北向？ 如下图所示，图中黄色的线条表示的是 API Gateway 访问内部服务：\n问题来了，从流量走向看：这是外部流量进入系统后，开始访问对外暴露的服务，应该属于“南北向”通讯，典型如上图的画法。但从另外一个角度，如果我们将 API Gateway 逻辑上拆分为两个部分，先忽略对外暴露的部分，单独只看 API Gateway 访问内部服务的部分，这时可以视 API Gateway 为一个普通的客户端服务，它和内部服务的通讯更像是“东西向”通讯：\n所以，API Gateway 作为一个客户端访问内部服务时，到底算南北向还是东西向，就成为一个哲学问题：完全取决于我们如何看待 API Gateway ，是作为一个整体，还是逻辑上分拆为对内对外两个部分。\n这个哲学问题并非无厘头，在 API Gateway 的各种产品中，关于如何实现 “API Gateway 作为一个客户端访问内部服务” ，就通常分成两个流派：\n 泾渭分明：视 API Gateway 和内部服务为两个独立事物，API Gateway 访问内部服务的通讯机制自行实现，独立于服务间通讯的机制； 兼容并济：视 API Gateway 为一个普通的内部服务的客户端，重用其内部服务间通讯的机制； 而最终决策通常也和产品的定位有关：如果希望维持 API Gateway 的独立产品定位，希望可以在不同的服务间通讯方案下都可以使用，则通常选择前者，典型如 Kong；如果和服务间通讯方案有非常深的渊源，则通常选择后者，典型如 Spring Cloud 生态下的 Zuul 和 SpringCloud Gateway。\n但无论选择哪个流派，都改变不了一个事实，当 “API Gateway 作为一个客户端访问内部服务” 时，它的确和一个普通内部服务作为客户端去访问其他服务没有本质差异：服务发现、负载均衡、流量路由、熔断、限流、服务降级、故障注入、日志、监控、链路追踪、访问控制、加密、身份认证\u0026amp;hellip;\u0026amp;hellip; 当我们把网关访问内部服务的功能一一列出来时，发现几乎所有的这些功能都是和服务间调用重复。\n这也就造成了一个普遍现象：如果已有一个成熟的服务间通讯框架，再去考虑实现 API Gateway，重用这些重复的能力就成为自然而然的选择。典型如前面提到的 Spring Cloud 生态下的 Zuul 以及后面开发的 Spring Cloud Gateway，就是以重用类库的方式实现了这些能力的重用。\n这里又是一个类似的哲学问题：当 “API Gateway 作为一个客户端访问内部服务” 时，它以重用类库的方式实现了代码级别的能力重用，相当于自行实现了一个和普通服务间通讯方案完全一样的客户端，那这个“客户端”发出来的流量算东西向还是南北向？\n答案不重要。\nSidecar：真正的重合点 在进入 Service Mesh 时代之后，Service Mesh 和 API Gateway 的关系开始是这样：\n 功能和职责清晰划分； 客户端访问服务的功能高度重叠； 此时两者的关系很清晰，而且由于当时 Service Mesh 和 API Gateway 是不同的产品，两者的重合点只是在功能上。\n而随着时间的推移，当 Service Mesh 产品和 API Gateway 产品开始出现相互渗透时，两者的关系就开始变得暧昧。\n在 Service Mesh 出现之后，如何为基于 Service Mesh 的服务选择合适的 API Gateway 方案，就慢慢开始提上日程，而其中选择重用 Service Mesh 的能力也自然成为一个探索的方向，并逐步出现新式 API Gateway 产品，其想法很直接：\n如何融合东西向和南北向的通讯方案？\n其中的一个做法就是基于 Service Mesh 的 Sidecar 来实现 API Gateway，从而在南北向通讯中引入 Service Mesh 这种东西向通讯的方案。这里我们不展开细节，我这里援引一个图片(鸣谢赵化冰同学)来解释这个方案的思路：\n这个时候 Service …","date":1588143600,"description":"Service Mesh 和 API Gateway 之间的关系，是“泾渭分明”还是“兼容并进”？","dir":"blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"17986a3e65f4db0f66b6ba707cf27a40","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","publishdate":"2020-04-29T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","summary":"前言 关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做","tags":["Service Mesh","API Gateway "],"title":"Service Mesh 和 API Gateway 关系深度探讨","type":"blog","url":"/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","wordcount":5306},{"author":"卫恒","categories":"SOFATracer","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。\n 本文根据 SOFAChannel#15 直播分享整理，主题：分布式链路组件 SOFATracer 埋点机制解析。\n大家好，我是宋国磊，花名卫恒，是 SOFATracer 的开源负责人。今天要和大家分享的是分布式链路组件 SOFATracer 埋点机制解析，将通过具体 Demo 演示快速上手 SOFATracer，同时介绍 SOFATracer 功能点，并详细介绍其核心关键「埋点机制」的原理。\nSOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFATracer：https://github.com/sofastack/sofa-tracer\nSOFATracer 作为 SOFAStack 中的分布式链路组件，也伴随着 SOFAStack 走过了两年的时间，在此首先对两年来对 SOFATracer 保持关注并且参与社区建设的同学表示感谢，也希望大家能够继续关注 SOFAStack 的发展，也欢迎更多的同学加入到 SOFAStack 的社区参与中来。\n今天的分享内容主要将会围绕以下三个部分展开：\n SOFATracer 功能点详细介绍； SOFATracer 埋点机制原理详解； 快速上手 SOFATracer 演示； 关于 SOFATracer 更多的问题也欢迎在 Github 上跟我们交流。\nSOFATracer 简介 首先简单介绍一下 SOFATracer。上图展示的是 SOFATracer 目前所包括的基本能力和所支持的插件。下面虚线框中绿色背景部分，是 SOFATracer 提供的基本功能，具体可以参考官方文档描述。上面虚线框中是 SOFATracer 目前所支持的组件，大概分了以下几种类型：客户端、Web、数据存储、消息、RPC、Spring Cloud。\n之前社区也发起过 剖析 | SOFATracer 框架 的源码解析系列文章，在此系列中对 SOFATracer 所提供的能力及实现原理都做了比较全面的分析，有兴趣的同学可以看下。\n今天主要聊一下埋点机制。不同组件的埋点机制也是有很大的差异，SOFATracer 是如何实现对上述组件进行埋点的，下面就详细分析下不同组件的埋点机制。\n埋点机制 目前 SOFATracer 已经支持了对以下开源组件的埋点支持：Spring MVC、RestTemplate、HttpClient、OkHttp3、JDBC、Dubbo(2.6\u0026amp;frasl;2.7)、SOFARPC、Redis、MongoDB、Spring Message、Spring Cloud Stream (基于 Spring Message 的埋点)、RocketMQ、Spring Cloud FeignClient、Hystrix。\n 大多数能力提供在 3.x 版本，2.x 版本从官方 issue 中可以看到后续将不再继续提供新的功能更新；这也是和 SpringBoot 宣布不再继续维护 1.x 版本有关系。\n 标准 Servlet 规范埋点原理 SOFATracer 支持对标准 Servlet 规范的 Web MVC 埋点，包括普通的 Servlet 和 Spring MVC 等，基本原理就是基于 Servelt 规范所提供的 javax.servlet.Filter 过滤器接口扩展实现。\n 过滤器位于 Client 和 Web 应用程序之间，用于检查和修改两者之间流过的请求和响应信息。在请求到达 Servlet 之前，过滤器截获请求。在响应送给客户端之前，过滤器截获响应。多个过滤器形成一个 FilterChain，FilterChain 中不同过滤器的先后顺序由部署文件 web.xml 中过滤器映射的顺序决定。最先截获客户端请求的过滤器将最后截获 Servlet 的响应信息。\n Web 应用程序一般作为请求的接收方，在 SOFATracer 中应用是作为 Server 存在的，其在解析 SpanContext 时所对应的事件为 sr (server receive)。\nSOFATracer 在 sofa-tracer-springmvc-plugin 插件中解析及产生 Span 的过程大致如下：\n Servlet Filter 拦截到 request 请求； 从请求中解析 SpanContext； 通过 SpanContext 构建当前 MVC 的 Span； 给当前 Span 设置 tag、log； 在 Filter 处理的最后，结束 Span； 当然这里面还会设计到其他很多细节，比如给 Span 设置哪些 tag 属性、如果处理异步线程透传等等。本次分享就不展开细节探讨，有兴趣的同学可以自行阅读代码或者和我们交流。\nDubbo 埋点原理 Dubbo 埋点在 SOFATracer 中实际上提供了两个插件，分别用于支持 Dubbo 2.6.x 和 Dubbo 2.7.x；Dubbo 埋点也是基于 Filter ，此 Filter 是 Dubbo 提供的 SPI 扩展-调用拦截扩展 机制实现。\n像 Dubbo 或者 SOFARPC 等 RPC 框架的埋点，通常需要考虑的点比较多。首先， RPC 框架分客户端和服务端，所以在埋点时 RPC 的客户端和服务端必须要有所区分；再者就是 RPC 的调用方式包括很多种，如常见的同步调用、异步调用、oneway 等等，调用方式不同，所对应的 Span 的结束时机也不同，重要的是基本所有的 RPC 框架都会使用线程池用来发起和处理请求，那么如何保证 SOFATracer 在多线程环境下不串也很重要。\n另外 Dubbo 2.6.x 和 Dubbo 2.7.x 在异步回调处理上差异比较大，Dubbo 2.7.x 中提供了 onResponse 方法（后面又升级为 Listener，包括 onResponse 和 onError 两个方法）；而 Dubbo 2.6.x 中则并未提供相应的机制，只能通过对 Future 的硬编码处理来完成埋点和上报。\n 这个问题 Zipkin Brave 对 Dubbo 2.6.x 的埋点时其实也没有考虑到，在做 SOFATracer 支持 Dubbo 2.6.x 时发现了这个 bug，并做了修复。\n SOFATracer 中提供的 DubboSofaTracerFilter 类：\n@Activate(group = { CommonConstants.PROVIDER, CommonConstants.CONSUMER }, value = \u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;, order = 1) public class …","date":1588068000,"description":"SOFATracer 埋点机制解析直播文字回顾。","dir":"blog/sofa-channel-15-retrospect/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4e4c9d4539119eb12ece83c8228ee4a3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-15-retrospect/","publishdate":"2020-04-28T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-channel-15-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["SOFATracer","SOFAChannel"],"title":"分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-15-retrospect/","wordcount":4579},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#16：不得不说的云原生隔离性\n 活动时间：5 月 21 日周四晚 7 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#16：不得不说的云原生隔离性 在云原生时代，容器和 Kubernetes 在日常工作和实际生产中越来越普遍，随之而来的隔离性问题在不断被提起同时也受到了越来越多的关注。\nKata Containers 是 OpenStack 基金会旗下又独立于 OpenStack 项目之外的开放基础设施顶级项目，旨在把虚拟机的安全隔离优势与容器的速度和可管理性统一起来，为用户提供安全快速易用的容器基础设施。\n本期直播，将邀请 Kata Containers 维护者彭涛（花名：巴德）带我们走近云原生的一项基础设施 \u0026amp;ndash; Kata Containers，看它是如何在云原生框架下解决容器隔离性问题的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1197\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 不得不说的云原生隔离性 卫恒 SOFATracer 开源负责人\n你将收获 从 Kubernetes Pod 说起，经典容器场景下的 Pod 分享； 共享内核存在的问题以及解决办法； 上帝说，要有光；我们说，要有 Kata； The speed of containers, the security of VMs； Kata Containers 特性大放送； What? 你刚说过增加一个 VM 间接层的问题？ 嘉宾 SOFAGirl 主持人 卫恒 SOFATracer 开源负责人 ","date":1588057200,"description":"5 月 21 日周四晚 7 点，线上直播第 16 期。","dir":"activities/sofa-channel-16/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4756bc76f718255ad5fc4fd172a706b4","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-16/","publishdate":"2020-04-28T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-16/","summary":"概要 活动主题：SOFAChannel#16：不得不说的云原生隔离性 活动时间：5 月 21 日周四晚 7 点 活动形式：线上直播 报名方式：戳这里 介绍 | SOFAChannel \u0026lt;SOFA:Channel/\u0026gt; 有","tags":["SOFAChannel","Kata Container"],"title":"SOFAChannel#16：不得不说的云原生隔离性","type":"activities","url":"/sofastack.tech/activities/sofa-channel-16/","wordcount":568},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n**SOFAStack 官网: **https://www.sofastack.tech\n**SOFAStack: **https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@闫圣哲 提问：\n 请问：关于 SOFAJRaft 线性读，为什么读失败了要应用到状态机呢，是为了拉齐 readindex 吗？\n A：线性一直读不走 raft log （应该是你说的状态机的意思），在 rheakv 里面，如果线性一直读失败了，那么会和write操作一样通过 raft log 达成一致再走状态机读，这是个兜底策略，否则 readIndex 失败了能怎么办呢？ 另一只方式就是直接返回用户失败了。可以具体看一下「JRaft 实现细节解析之高效的线性一致读」这一小节的内容～\nhttps://www.sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFA 项目进展 本周发布详情如下：\n发布 Seata v1.2.0 版本，主要变更如下：\n 支持 XA 事务模式； 支持事务传播机制； 支持批量更新和删除 SQL； TCC 模式支持 hsf 服务调用； Saga 模式性能优化默认不注册分支事务等； 本次发布涉及代码改动文件数 324个，代码行 +11,907 −3,437。 此版本在 feature 和稳定性相对 1.1.0 版本都有较大幅度增强，强烈推荐大家验证和升级到此版本。 详细发布报告：https://seata.io/zh-cn/blog/download.html\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 社区直播报名 本期为第一期 Service Mesh Virtual Meetup 线上系列直播第一期，邀请了四位来自不同公司的嘉宾，从四个角度对 Service Mesh 的应用实践展开分享。\n本次线上 meetup 分享涵盖 Service Mesh 的可观察性和生产实践。为大家介绍 Service Mesh 中的可观察性与传统微服务中可观察性的区别，如何使用 SkyWalking 来观测 Service Mesh，还有来自百度和陌陌的 Service Mesh 生产实践。\n本系列采用线上直播的形式，从 5 月 6 日开始到 5 月 14 日，每周三、周四晚上 19:00-20:00 我们相约进行一个主题分享。\n观看直播方式：保存图片扫码 或 点击“这里”，关注直播间，即可观看直播\n","date":1587722400,"description":"【04/20-04/24】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200424/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"455d22426589849b45f59083c641ee7c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200424/","publishdate":"2020-04-24T18:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200424/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 系列直播预告、Seata 发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200424/","wordcount":1092},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析\n 活动时间：4 月 23 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1167\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 分布式链路组件 SOFATracer 埋点机制解析 卫恒 SOFATracer 开源负责人\n你将收获 带你快速上手 SOFATracer； SOFATracer 功能点详细介绍； SOFATracer 埋点机制原理详解； 嘉宾 SOFAGirl 主持人 卫恒 SOFATracer 开源负责人 ","date":1587114000,"description":"4 月 23 日周四晚 7 点，线上直播第 15 期。","dir":"activities/sofa-channel-15/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e1323556a7e34b0937a8d3c1f6815a77","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-15/","publishdate":"2020-04-17T17:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-15/","summary":"概要 活动主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 活动时间：4 月 23 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍 |","tags":["SOFAChannel","SOFATracer"],"title":"SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-15/","wordcount":442},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@杨俊 提问：\n AT 模式下，当 seata-server 挂掉之后，有未完成的全局事务还在 undo_log 表中，这里有两个问题问一下： 1. seata-server 再次重启后，之前未完成的全局事务偶尔会出现回滚失败的问题，就是一直重试，但始终回滚失败，这个问题如何解决？ 1. seata-server 再次重启后，大多数情况下会成功回滚，但是等待时间过长，感觉要至少3-5分钟才会回滚，这期间涉及到的相关业务服务无法处理其他请求，直至之前的未完成全局事务成功回滚了，才能处理其他请求，请问这个问题如何解决，还有回滚时间在哪里配置能够缩短？ ※上述两个问题都是基于 seata-sample 产生的。\n A：1. 要确认下客户端日志中回滚失败的原因，重启后会恢复重启前未完成的事务。一般是出现脏写数据了，需要人工订正。如果单纯跳过可以删除 server 或 undo_log 对应记录。 2. server.recovery.rollbackingRetryPeriod , 是不是重启前未完成事务过多？\n 好的，谢谢。 1. seata-sample 中三个服务，Account、Order 回滚成功，Storage 回滚失败，然后 seata-server 就一直反复重试，seata 和 storage 及其他服务重启也无用，然后手工将日志删除，依然不停重试，最后重启 seata 服务，系统把删掉的日志又给重写到日志表了，但是 log_status 为1，至此不再重试，但是事务未能成功回滚。 1. 重启未完成的事务只有那么三个而已，并不多。\n A：问题1，你还是要看下回滚失败的原因，客户端日志会打印。 问题2，你提个 issue ，我们排查下。\n2、@吕布 提问：\n 请教一下, AT 下分支事务提交后释放资源, 虽然资源释放了, 但别的事务操作它时还是被全局锁了, 这种释放的好处体现在哪些方面？ A：即使你数据库本地事务也是排队执行的，全局锁是 AT 模式的排队机制，所以如果是相同数据主键的这个与连接无关。释放连接是因为数据库连接资源是宝贵的，不会因为连接池连接数不够导致的其他数据无关的事务得不到执行，从更大的层面认为是一定程度提高了吞吐。\n 明白了，一方面就是说提高吞吐, 然后一方面是避免本地事务的间隙锁和表锁, 导致其他不相关数据被锁, 可以说锁粒度变小了。谢谢。\n Seata：https://github.com/seata/seata\nSOFATracerLab 系列阅读 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览 | 剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码分析 | 剖析 蚂蚁金服分布式链路跟踪组件链路透传原理与SLF4J MDC的扩展能力分析 | 剖析 蚂蚁金服分布式链路跟踪组件采样策略和源码 | 剖析 蚂蚁金服分布式链路跟踪组件埋点机制 | 剖析 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.1 版本，主要变更如下：\n multi raft group 之间共享 timer 和 scheduler 等较重的线程资源，优化 multi group 场景中的多余资源占用； 提供 RPC adapter，用户可基于 SPI 扩展不同的 RPC 实现； 正式提供稳定的 RocksDBSegmentLogStorage，适合 value 较大的数据存储； SOFABolt 升级到 1.6.1，支持 SSL 以及具有更好的小数据包传输能力； 引入一个新的数据结构 segment list 来解决 LogManager 中过多的 log memory copy； 采纳 nacos 建议，对 raft Task 增加 join API； 修复 learner 启动晚于 leader 选举成功时无法复制日志的 bug； 致谢（排名不分先后） @jovany-wang 、@SteNicholas 、@zongtanghu 、@OpenOpened\n详细发布报告：https://github.com/sofastack/sofa-jraft/issues/420\n社区直播报名 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n本期直播将通过具体 Demo 带你快速上手 SOFATracer，同时将介绍 SOFATracer 具体功能，并详细介绍其核心关键「埋点机制」的原理。\n 主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 时间：2020年4月23日（周四）19:00-20:00 嘉宾：卫恒 SOFATracer 开源负责人 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1587106800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200417/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1bb16db78404cb9d09dd18ec48374246","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200417/","publishdate":"2020-04-17T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200417/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 直播预告、SOFAJRaft 组件发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200417/","wordcount":1836},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@熊胜 提问：\n 请教个问题，biz 卸载中的关闭 ApplicationContext 这一步是哪里处理的呢？我在 com.alipay.sofa.ark.container.model.BizModel#stop 方法中没看到相应的实现。\n A： biz stop 会发出一个事件，这个时间会被 runtime 拿到处理，可以看下 sofa-boot runtime 里面有处理 biz 卸载事件的 handler。\nSOFAArk：https://github.com/sofastack/sofa-ark\n2、@揭印泉 提问：\n 请问 registry.conf 中的 registry 作用是向 Seata 服务器注册分支事务？\n A：registry 是注册中心，seata server 和 client 都需要的，server 往注册中心注册服务，client 往注册中心找寻 server 服务。\n seata server 和 client 是共用 nacos-config.sh 脚本跑到 Nacos 配置？ 如果他们都配置了 Nacos。\n A：随你，你也可以分开，配置中心没约束，你可以 server 用 nacos，client 用 file，只要读取到即可。\n 服务器端配置了 store.mode=\u0026amp;ldquo;db\u0026amp;rdquo;, 启动参数需要加参数：-m db ?\n A：可以不加，优先级启动参数\u0026amp;gt;配置。\nSeata：https://github.com/seata/seata\nSOFARegistryLab 系列阅读 服务注册中心如何实现 DataServer 平滑扩缩容 | SOFARegistry 解析 服务注册中心数据一致性方案分析 | SOFARegistry 解析 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFAChannel 线上直播合集 SOFAChannel#14：云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 SOFAChannel#13：云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 SOFAChannel#12：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 SOFATracer v3.0.12 版本，主要变更如下：\n 2个 Dubbo 插件融合, 新的用户请直接使用 sofa-tracer-dubbo-common-plugin； 修复 Dubbo 插件传递错误 spanId 的问题； 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.12\n社区直播报名 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n本期直播将通过具体 Demo 带你快速上手 SOFATracer，同时将介绍 SOFATracer 具体功能，并详细介绍其核心关键「埋点机制」的原理。\n 主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 时间：2020年4月23日（周四）19:00-20:00 嘉宾：卫恒 SOFATracer 开源负责人 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1586509200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200410/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9f805804c54d097bea99536c21da6387","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200410/","publishdate":"2020-04-10T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200410/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 直播预告、SOFARegistry 解析系列合集、线上直播回顾合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200410/","wordcount":1705},{"author":"永鹏","categories":"SOFAChannel","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。\n 本文根据 SOFAChannel#14 直播分享整理，主题：云原生网络代理 MOSN 扩展机制解析。\n大家好，我是今天的讲师永鹏，来自蚂蚁金服，目前主要负责 MOSN 的开发，也是 MOSN 的Committer。今天我为大家分享的是云原生网络代理 MOSN 的扩展机制，希望通过这次分享以后，能让大家了解 MOSN 的可编程扩展能力，可以基于 MOSN 的扩展能力，按照自己实际的业务需求进行二次开发。\n前言 今天我们将从以下几个方面，对 MOSN 的扩展机制进行介绍：\n MOSN 扩展能力和扩展机制的详细介绍； 结合示例对 MOSN 的 Filter 扩展机制与插件扩展机制进行详细介绍； MOSN 后续扩展能力规划与展望； 欢迎大家有兴趣一起共建 MOSN。在本次演讲中涉及到的示例就在我们的 Github 的 examples/codes/mosn-extensions 目录下，大家有兴趣的也可以下载下来运行一下，关于这些示例我们还做了一些小活动，也希望大家可以踊跃参与。\nMOSN：https://github.com/mosn/mosn\nMOSN 简介 MOSN 作为云原生的网络代理，旨在为服务提供多协议、模块化、智能化、安全的代理能力。在实际生产使用中，不同的厂商会有不同的使用场景，通用的网络代理能力面对具体的业务场景会显得有些不足，通常都需要进行二次开发以满足业务需求。MOSN 在核心框架中，提供了一系列的扩展机制和扩展点，就是为了满足需要基于业务进行二次开发的场景，同时 MOSN 提供的部分通用逻辑也是基于扩展机制和扩展点的实现。\n比如通过 MOSN “内置实现”的透明劫持的能力，就是通过 MOSN Filter 机制实现。而要实现消息的代理，则可以通过类似的扩展实现。在通用代理的情况下，可以通过 Filter 机制实现业务的认证鉴权，也可以实现定制的负载均衡逻辑；除了转发流程可以扩展实现以外，MOSN 还可以扩展日志的实现，用于对标已有的日志系统，也可以扩展 XDS 实现定制的配置更新；根据不同的业务场景还会有很多具体的扩展情况，就不在此展开了，有兴趣的可以关注MOSN 社区正在建设的源代码分析系列文章与文档。\nMOSN 作为一款网络代理，在转发链路上的网络层、协议层、转发层，在非转发链路上的配置、日志、Admin API 等都提供了扩展能力，对于协议扩展的部分，有兴趣的可以看一下上期直播讲的 MOSN 多协议机制解析，我们今天将重点介绍一下转发层的 Stream Filter 扩展机制与 MOSN 的插件机制。\nStream Filter 机制 在实际业务场景中，在转发请求之前或者回写响应之前，都可能需要对请求/响应做一些处理，如判断是否需要进行转发的认证/鉴权，是否需要限流，又或者需要对请求/响应做一些具有业务语义的记录，需要对协议进行转换等。这些场景都与具体的业务高度耦合，是一个典型的需要进行二次开发的情况。MOSN 的 Stream Filter 机制就是为了满足这样的扩展场景所设计的，它也成为目前 MOSN 扩展中使用频率最高的扩展点。\n在目前的内置 MOSN 实现中，Stream Filter 机制暂时与内置的 network filter: proxy 是绑定的，后面我们也考虑将这部分能力进行抽象，让其他 network filter 也可以复用这部分能力。\n关于 Stream Filter，今天会为大家讲解两个部分的内容： 1. 一个 Stream Filter 包含哪些部分以及在 MOSN 中是如何工作的； 2. 通过一个 Demo 演示来加深对 Stream Filter 的实现与应用；\n一个完整的 Stream Filter 一个完整的 StreamFilter，包含三个部分的内容：\n 一个 StreamFilter 对象，存在于每一个请求/响应当中，在 MOSN 收到请求的时候发挥作用，我们称为 ReceiverFilter，在 MOSN 收到响应时发挥作用，我们称为 SenderFilter。一个 StreamFilter 可以是其中任意一种，也可以是两种都是； 一个 StreamFilterFactory 对象，用于 MOSN 在每次收到请求时，生成 StreamFilter 对象。在 Listener 配置解析时，一个 StreamFilter 的配置会生成一个其对于的 StreamFilterFactory。同一个 StreamFilter 在不同的 Listener 下可能对应不同的 StreamFilterFactory，但是也有的特殊情况下，StreamFilterFactory 可能需要实现为单例； 一个 CreateStreamFilterFactory 方法，配置解析时生成 StreamFilterFactory 就是调用它； Stream Filter 在 MOSN 中是如何工作的 接下来，我们看下 Stream Filter 在 MOSN 中是如何工作的。\n当 MOSN 经过协议解析，收到一个完整的请求时，会创建一个 Stream。此时收到请求的 Listener 中每存在 StreamFilterFactory，就会生成一个 StreamFilter 对象，随后进入到 proxy 流程。\n进入 proxy 流程以后，如果存在 ReceiverFilter，那么就会执行对应的逻辑，ReceiverFilter 包括两个阶段，“路由前”和“路由后”，在每个 Filter 处理完成以后，会返回一个状态，如果是 Stop 则会中止后续尚未执行的 ReceiverFilter，通常情况下，返回 Stop 状态的 Filter 都会回写一个响应。如果是 Continue 则会执行下一个 ReceiverFilter，直到本阶段的 ReceiverFilter 都执行完成或中止；路由前阶段的 ReceiverFIlter 执行完成后，就会执行路由后阶段，其逻辑和路由前一致。如果是正常转发，那么随后 MOSN 会收到一个响应或者发现其他异常直接回写一个响应，此时就会进入到 SenderFilter 的流程中，完成 SenderFilter 的处理。SenderFilter 处理完成以后，MOSN 会写响应给 Client，并且完成最后的收尾工作，收尾工作包括一些数据的回收、日志的记录，以及 StreamFilter 的“销毁”（调用 OnDestroy）。\nStream Filter Demo 对 Stream Filter 有了一个基本的认识以后，我们来看一个实际的 Demo 代码来看下如何实现一个 StreamFilter 并且让它在 MOSN 中发挥作用。\n按照刚才我们的介绍，一个 StreamFIlter 要包含三部分：Filter、Factory、CreateFactory。\n 首先我们实现一个 Filter，其逻辑是模拟一个鉴权的 Filter： …","date":1586437200,"description":"本文根据 SOFAChannel#14 直播分享整理，主题：云原生网络代理 MOSN 扩展机制解析。","dir":"blog/sofa-channel-14-retrospect/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"54f04c153ed4827819de6a6716ad46e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-14-retrospect/","publishdate":"2020-04-09T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-14-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["SOFAChannel","MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-14-retrospect/","wordcount":6144},{"author":"404P","categories":"SOFARegistry ","content":" SOFAStack（Scalable Open Financial Architecture Stack ）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。  SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》最后一篇，本篇作者404P(花名岩途)。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n前言 在微服务架构体系下，服务注册中心致力于解决微服务之间服务发现的问题。在服务数量不多的情况下，服务注册中心集群中每台机器都保存着全量的服务数据，但随着蚂蚁金服海量服务的出现，单机已无法存储所有的服务数据，数据分片成为了必然的选择。数据分片之后，每台机器只保存一部分服务数据，节点上下线就容易造成数据波动，很容易影响应用的正常运行。本文通过介绍 SOFARegistry 的分片算法和相关的核心源码来展示蚂蚁金服是如何解决上述问题的。~~\n服务注册中心简介 在微服务架构下，一个互联网应用的服务端背后往往存在大量服务间的相互调用。例如服务 A 在链路上依赖于服务 B，那么在业务发生时，服务 A 需要知道服务 B 的地址，才能完成服务调用。而分布式架构下，每个服务往往都是集群部署的，集群中的机器也是经常变化的，所以服务 B 的地址不是固定不变的。如果要保证业务的可靠性，服务调用者则需要感知被调用服务的地址变化。\n图1 微服务架构下的服务寻址\n既然成千上万的服务调用者都要感知这样的变化，那这种感知能力便下沉成为微服务中一种固定的架构模式：服务注册中心。\n图2 服务注册中心\n服务注册中心里，有服务提供者和服务消费者两种重要的角色，服务调用方是消费者，服务被调方是提供者。对于同一台机器，往往兼具两者角色，既被其它服务调用，也调用其它服务。服务提供者将自身提供的服务信息发布到服务注册中心，服务消费者通过订阅的方式感知所依赖服务的信息是否发生变化。\nSOFARegistry 总体架构 SOFARegistry 的架构中包括4种角色：Client、Session、Data、Meta，如图3所示：\n图3 SOFARegistry 总体架构\n Client 层 应用服务器集群。Client 层是应用层，每个应用系统通过依赖注册中心相关的客户端 jar 包，通过编程方式来使用服务注册中心的服务发布和服务订阅能力。\n Session 层 Session 服务器集群。顾名思义，Session 层是会话层，通过长连接和 Client 层的应用服务器保持通讯，负责接收 Client 的服务发布和服务订阅请求。该层只在内存中保存各个服务的发布订阅关系，对于具体的服务信息，只在 Client 层和 Data 层之间透传转发。Session 层是无状态的，可以随着 Client 层应用规模的增长而扩容。\n Data 层 数据服务器集群。Data 层通过分片存储的方式保存着所用应用的服务注册数据。数据按照 dataInfoId（每一份服务数据的唯一标识）进行一致性 Hash 分片，多副本备份，保证数据的高可用。下文的重点也在于随着数据规模的增长，Data 层如何在不影响业务的前提下实现平滑的扩缩容。\n Meta 层 元数据服务器集群。这个集群管辖的范围是 Session 服务器集群和 Data 服务器集群的服务器信息，其角色就相当于 SOFARegistry 架构内部的服务注册中心，只不过 SOFARegistry 作为服务注册中心是服务于广大应用服务层，而 Meta 集群是服务于 SOFARegistry 内部的 Session 集群和 Data 集群，Meta 层能够感知到 Session 节点和 Data 节点的变化，并通知集群的其它节点。\nSOFARegistry 如何突破单机存储瓶颈 在蚂蚁金服的业务规模下，单台服务器已经无法存储所有的服务注册数据，SOFARegistry 采用了数据分片的方案，每台机器只保存一部分数据，同时每台机器有多副本备份，这样理论上可以无限扩容。根据不同的数据路由方式，常见的数据分片主要分为两大类：范围分片和 Hash（哈希）分片。\n图4 数据分片\n 范围分片 每一个数据分片负责存储某一键值区间范围的值。例如按照时间段进行分区，每个小时的 Key 放在对应的节点上。区间范围分片的优势在于数据分片具有连续性，可以实现区间范围查询，但是缺点在于没有对数据进行随机打散，容易存在热点数据问题。\n Hash （哈希）分片 Hash 分片则是通过特定的 Hash 函数将数据随机均匀地分散在各个节点中，不支持范围查询，只支持点查询，即根据某个数据的 Key 获取数据的内容。业界大多 KV（Key-Value）存储系统都支持这种方式，包括 cassandra、dynamo、membase 等。业界常见的 Hash 分片算法有哈希取模法、一致性哈希法和虚拟桶法。\n哈希取模 哈希取模的 Hash 函数如下：\nH(Key) = hash(key) mod K; 这是一个 key-machine 的函数。key 是数据主键，K 是物理机数量，通过数据的 key 能够直接路由到物理机器。当 K 发生变化时，会影响全体数据分布。所有节点上的数据会被重新分布，这个过程是难以在系统无感知的情况下平滑完成的。\n图5 哈希取模\n一致性哈希 分布式哈希表（DHT）是 P2P 网络和分布式存储中一项常见的技术，是哈希表的分布式扩展，即在每台机器存储部分数据的前提下，如何通过哈希的方式来对数据进行读写路由。其核心在于每个节点不仅只保存一部分数据，而且也只维护一部分路由，从而实现 P2P 网络节点去中心化的分布式寻址和分布式存储。DHT 是一个技术概念，其中业界最常见的一种实现方式就是一致性哈希的 Chord 算法实现。\n 哈希空间 一致性哈希中的哈希空间是一个数据和节点共用的一个逻辑环形空间，数据和机器通过各自的 Hash 算法得出各自在哈希空间的位置。\n图6 数据项和数据节点共用哈希空间\n图7是一个二进制长度为5的哈希空间，该空间可以表达的数值范围是0～31（2^5），是一个首尾相接的环状序列。环上的大圈表示不同的机器节点（一般是虚拟节点），用 $$Ni$$ 来表示，$$i$$ 代表着节点在哈希空间的位置。例如，某个节点根据 IP 地址和端口号进行哈希计算后得出的值是7，那么 N7 则代表则该节点在哈希空间中的位置。由于每个物理机的配置不一样，通常配置高的物理节点会虚拟成环上的多个节点。\n图7 长度为5的哈希空间\n环上的节点把哈希空间分成多个区间，每个节点负责存储其中一个区间的数据。例如 N14 节点负责存储 Hash 值为8～14范围内 …","date":1586340000,"description":"本文介绍 SOFARegistry 分片算法和相关核心源码来展示蚂蚁金服是如何解决数据分片带来的节点上下线数据波动的问题。","dir":"blog/sofa-registry-dataserver-smooth-expansion-contraction/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"35c77b7278ad2675b56540b1f97ecf8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","publishdate":"2020-04-08T18:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","summary":"SOFAStack（Scalable Open Financial Architecture Stack ）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里","tags":["SOFARegistry ","剖析 | SOFARegistry 框架","SOFALab"],"title":"蚂蚁金服服务注册中心如何实现 DataServer 平滑扩缩容 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","wordcount":6179},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@王磊 提问：\n SOFARPC 注册的 Dubbo 服务和通过 Dubbo 组件注册的服务可以互通的吧？\n A：可以的， Dubbo 是桥接模式。\n 这个怎么配置的。现在注册的 Dubbo 服务 generic=false。 A：现在只支持泛化调用不支持泛化服务，可以关注一下这个 Issue，后期会排期做，也欢迎共建。 https://github.com/sofastack/sofa-rpc/issues/894\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@黄振祥 提问：\n 使用 SOFAStack 快速构建微服务的 Demo 时遇到的一些问题，可以怎么解决呢？ https://github.com/sofastack-guides/kc-sofastack-demo\n A：可以详细看一下这个 issue： https://github.com/sofastack-guides/kc-sofastack-demo/issues/9\n3、@哈哈哈 提问：\n AT 和 Saga 有什么区别吗，AT 我感觉是自动的 Saga。\n A：也可以这么说，Saga 框架上没有加锁，AT 有加锁，事实上 Seata Saga 是一个具备“服务编排”和“Saga 分布式事务”能力的产品。\n4、@全 提问：\n 麻烦问一下，Seata TCC 只支持 Dubbo、SOFARPC 吗？\n A：还有 local，其他的 rpc 框架可以基于 local 包装一下或者扩展下 parser，也欢迎大家贡献。\n 如果通过 spring-cloud 整合的话需要扩展这个 Parser 是吧？\n A：是的，但是像 resttemplate 这种 rest 请求没办法走 parser，需要你 local 包一下。 Seata：https://github.com/seata/seata\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n发布 SOFA MOSN v0.11.0 版本，主要变更如下：\n 重构 XProtocol Engine，优化了协议层的实现； 支持 Listener Filter 的扩展，基于 Listener Filter 重新实现了透明劫持能力； 优化了 LDS 接口，修改了路由配置结构，完善了变量机制； 完善了 TraceLog 的实现； Bug Fix； 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/v0.11.0\n社区直播报名 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n本期直播包含 Demo，可以先下载 Demo，提前体验 MOSN 拓展机制的使用（报名页面有详细 Demo 链接）。\n 主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 时间：2020年4月9日（下周四）19:00-20:00 嘉宾：永鹏 蚂蚁金服高级开发工程师、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1585908000,"description":"【03/30-04/03】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200403/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e109585632269dffffd2819dd121da2b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200403/","publishdate":"2020-04-03T18:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200403/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告 \u0026 发布更新、Service Mesh 落地实践解析合辑","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200403/","wordcount":1376},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@John Deng 提问：\n 现在 MOSN 对 Dubbo 协议支持怎样？\n A：这儿，协议支持了：https://github.com/mosn/mosn/tree/master/pkg/protocol/xprotocol/dubbo 完整的支持，我们已经创建了 Dubbo WG 专门来做这个事情，https://github.com/mosn/community/blob/master/wg-dubbo.md\n 已经生产就绪了吗？\n A：如果是 Dubbo 的话，目前还没有生产可用，主要是相关生态还没对齐，我们正在推进 Dubbo WG kick off，有兴趣可以加入一起完善。 如果指 MOSN 的话，我们去年双11已经线上部署几十万容器，生产可用。 MOSN：https://github.com/mosn/mosn\n2、@Liang 提问：\n SOFAJRaft 的 Leader 节点执行完状态机，把这次的 index 提交之后，什么时候通知的 Follower 节点也提交呢？ 我看现象是 Follower 也立刻跟着提交了，但是这块代码没有找到。想问下具体是怎么实现的，谢谢~\n A：Leader 会往 Follower 发送 lastCommittedIndex， 详情见：\ncom.alipay.sofa.jraft.core.NodeImpl#handleAppendEntriesRequest com.alipay.sofa.jraft.core.BallotBox#setLastCommittedIndex SOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@琦玉 提问：\n 这种情况下，状态机怎么确定是执行回滚，还是执行重试呢？ A：这个是由开发者决定的。 Server 事务恢复的逻辑是：\n 当提交失败时，重试提交； 补偿失败时，重试补偿； 如果超时默认是进行重试补偿，如果配置了这个\u0026amp;rdquo;RecoverStrategy\u0026amp;rdquo;: \u0026amp;ldquo;Forward\u0026amp;rdquo;则进行重试向前执行； 这个\u0026amp;rdquo;RecoverStrategy\u0026amp;rdquo;: \u0026amp;ldquo;Forward\u0026amp;rdquo;配置是告诉状态机默认的事务恢复策略。如果发现这条事务无法向前，也可以通过手动调状态机“补偿”。\n 这种是否最终成功可能有其它业务上的条件，比如取决于另外一个步骤的成功与否。没法在状态语言里面定义。如果 A 充值成功，事务失败，B 就不能回退，必须重试到最终成功。如果 A 充值失败，事务失败，B 就可以回退。这种具体是要怎么去处理呢？分布式事务内先给用户 A 充值, 然后给用户 B 扣减余额, 如果在给 A 用户充值成功, 在事务提交以前, A 用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了\n A：不允许这样设计，业务流水，必须先扣，再充，必须要遵循“宁可长款，不可短款”的原则。\n 意思是分成两个独立的事务，Saga 模式中不定义在同一个状态机流程里？先把B的扣钱流程执行完，再去执行 A 的充值流程 ？\n A：不是，是在同一个事务里，同一个流程，要先进行扣 B 的款，再给 A 充值，那和如果充值失败，可以回滚 B。\n 假如同时给 B 和 C 充值呢？\n A：那就都向前重试，因为充钱业务上不会失败。\n 如果做重试的话，是不是整个流程其它做回退的动作都要在充值动作之前完成?在重试动作之后的动作都只能做重试?\n A：也不是完全只能这样，要根据业务场景来吧。做一个合理的流程设计。 相关阅读：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 Seata：https://github.com/seata/seata\n本周推荐阅读 Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 SOFARegistry v5.4.2 版本，主要变更如下：\n 修复 cloud 模式推送时客户端 cell 设置错误的问题； 详细发布报告： https://github.com/sofastack/sofa-registry/releases/tag/v5.4.2\n社区直播报名 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n本期直播包含 Demo，可以先下载 Demo，提前体验 MOSN 拓展机制的使用（报名页面有详细 Demo 链接）。\n 主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 时间：2020年4月9日（周四）19:00-20:00 嘉宾：永鹏 蚂蚁金服高级开发工程师、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1585299600,"description":"【03/23-03/27】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-0327/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0c6b194e66eeb4c95efa4260e279bab7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0327/","publishdate":"2020-03-27T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0327/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告、本周直播回顾整理、SOFARegistry 发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0327/","wordcount":1980},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析\n 活动时间：4 月 9 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n欢迎先下载 Demo，提前体验 MOSN 拓展机制的使用，成功完成预习作业—— Demo 完整操作的，有机会获得小礼物哟（记得留下完成的证明，获得方式在直播中公布），我们将在直播中公布答案——进行 Demo 的详细演示。PS：在直播中也会发布闯关任务，完成闯关任务也有机会获得小礼物哟～\nDemo：https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions\nDemo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions\n欢迎了解 MOSN：https://github.com/mosn/mosn\n| 针对人群 对云原生、Service Mesh、网络代理有基本了解，想要了解云原生以及对云原生网络代理 MOSN 有二次开发需求的人群\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：21992058（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1131\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 永鹏 蚂蚁金服高级开发工程师， MOSN Committer\n你将收获 快速了解 MOSN 的多种扩展能力 3 个案例，实际体验 MOSN 扩展能力 多案例多形式，使用 MOSN 实现个性化业务需求 嘉宾 SOFAGirl 主持人 永鹏 蚂蚁金服高级开发工程师， MOSN Committer ","date":1585299600,"description":"4 月 9 日周四晚 7 点，线上直播第 14 期。","dir":"activities/sofa-channel-14/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0e1d5c0ea19ec82218fbf675b891ee5a","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-14/","publishdate":"2020-03-27T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-14/","summary":"概要 活动主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 活动时间：4 月 9 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍","tags":["SOFAChannel","MOSN"],"title":"SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-14/","wordcount":901},{"author":"无钩","categories":"MOSN","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。 本文根据 SOFAChannel#13 直播分享整理，主题：云原生网络代理 MOSN 多协议机制解析。\n 大家好，我是今天的讲师无钩，目前主要从事蚂蚁金服网络代理相关的研发工作，也是 MOSN 的 Committer。今天要和大家分享的是《云原生网络代理 MOSN 多协议机制解析》，并介绍对应的私有协议快速接入实践案例以及对 MOSN 实现多协议低成本接入的设计进行解读。\n我们将按以下顺序进行介绍：\n 多协议机制产生的背景与实践痛点； 常见的协议扩展思路初探； SOFABolt 协议接入实践；（重点） MOSN 多协议机制设计解读；（重点） 后续规划及展望； 其中第三点「接入实践」是今天分享的重点，希望能给大家就「如何在 MOSN 中快速扩展私有协议接入」有一个具体的感受。另外「MOSN 如何实现多协议框架」也是很多人关心和问题，我们将摘选几个技术功能，对其背后的设计思考进行解读。\nMOSN 简介 云原生网络代理 MOSN 定位是一个全栈的网络代理，支持包括网络接入层(Ingress)、API Gateway、Service Mesh 等场景，目前在蚂蚁金服内部的核心业务集群已经实现全面落地，并经受了 2019 年双十一大促的考验。今天要向大家介绍的是云原生网络代理 MOSN 核心特性之一的多协议扩展机制，目前已经支持了包括 SOFABolt、Dubbo、TARS 等多个协议的快速接入。\nMOSN：https://github.com/mosn\n多协议机制产生的背景与实践痛点 首先介绍一下多协议机制产生的背景。\n前面提到，蚂蚁金服 2019 年双十一核心链路百分之百 Mesh 化，是业界当时已知的最大规模的 Service Mesh 落地，为什么我们敢这么做？因为我们具备能够让架构平滑迁移的方案。\u0026amp;rdquo;兼容性\u0026amp;rdquo;是任何架构演进升级都必然要面对的一个问题，这在早已实践微服务化架构的蚂蚁金服内部同样如此。为了实现架构的平滑迁移，需要让新老节点的外在行为尽可能的表现一致，从而让依赖方无感知，这其中很重要的一点就是保持协议兼容性。\n因此，我们需要在 Service Mesh 架构下，兼容现有微服务体系中的通信协议——也就是说需要在 MOSN 内实现对目前蚂蚁金服内部通信协议的扩展支持。\n基于 MOSN 本身的扩展机制，我们完成了最初版本的协议扩展接入。但是在实践过程中，我们发现这并不是一件容易的事情：\n 相比编解码，协议自身的处理以及与框架集成才是其中最困难的环节，需要理解并实现包括请求生命周期、多路复用处理、链接池等等机制； 社区主流的 xDS 路由配置是面向 HTTP 协议的，无法直接支持私有协议，存在适配成本； 基于这些实践痛点，我们设计了 MOSN 多协议框架，希望可以降低私有协议的接入成本，加快普及 ServiceMesh 架构的落地推进。\n常见的协议扩展思路初探 前面介绍了背景，那么具体协议扩展框架要怎么设计呢？我们先来看一下业界的思路与做法。\n协议扩展框架 - Envoy 注：图片来自 Envoy 分享资料\n第一个要介绍的是目前发展势头强劲的 Envoy。从图上可以看出，Envoy 支持四层的读写过滤器扩展、基于 HTTP 的七层读写过滤器扩展以及对应的 Router/Upstream 实现。如果想要基于 Envoy 的扩展框架实现 L7 协议接入，目前的普遍做法是基于 L4 filter 封装相应的 L7 codec，在此基础之上再实现对应的协议路由等能力，无法复用 HTTP L7 的扩展框架。 协议扩展框架 - Nginx 第二个则是老牌的反向代理软件 Nginx，其核心模块是基于 Epoll/Kqueue 等 I/O 多路复用技术之上的离散事件框架，基于事件框架之上构建了 Mail、Http 等协议模块。与 Envoy 类似，如果要基于 Nginx 扩展私有协议，那么也需要自行对接事件框架，并完整实现包括编解码、协议处理等能力。\n协议扩展框架 - MOSN 最后回过头来，我们看一下 MOSN 是怎么做的。实际上，MOSN 的底层机制与 Envoy、Nginx 并没有核心差异，同样支持基于 I/O 多路复用的 L4 读写过滤器扩展，并在此基础之上再封装 L7 的处理。但是与前两者不同的是，MOSN 针对典型的微服务通信场景，抽象出了一套适用于基于多路复用 RPC 协议的扩展框架，屏蔽了 MOSN 内部复杂的协议处理及框架流程，开发者只需要关注协议本身，并实现对应的框架接口能力即可实现快速接入扩展。\n三种框架成本对比 最后对比一下，典型微服务通信框架协议接入的成本，由于 MOSN 针对此类场景进行了框架层面的封装支持，因此可以节省开发者大量的研发成本。\nSOFABolt 协议接入实践 初步了解多协议框架的设计思路之后，让我们以 SOFABolt 协议为例来实际体验一下协议接入的过程。\nSOFABolt 简介 这里先对 SOFABolt 进行一个简单介绍，SOFABolt 是一个开源的轻量、易用、高性能、易扩展的 RPC 通信框架，广泛应用于蚂蚁金服内部。\nSOFABolt：https://github.com/sofastack/sofa-bolt\n基于 MOSN 的多协议框架，实际编写了 7 个代码文件，一共 925 行代码(包括 liscence、comment 在内)就完成了接入。如果对于协议本身较为熟悉，且具备一定的 MOSN/Golang 开发经验，甚至可以在一天内就完成整个协议的扩展，可以说接入成本是非常之低。\nGithub: https://github.com/mosn/mosn/tree/master/pkg/protocol/xprotocol/bolt\n下面让我们进入正题，一步一步了解接入过程。\nStep1：确认协议格式 第一步，需要确认要接入的协议格式。为什么首先要做这个，因为协议格式是一个协议最基本的部分，有以下两个层面的考虑：\n 任何协议特性以及协议功能都能在上面得到一些体现，例如有无 requestId/streamId 就直接关联到协议是否支持连接多路复用； 协议格式与报文模型直接相关，两者可以构成逻辑上的映射关系；而这个映射关系也就是所谓的编解码逻辑； 以 SOFABolt 为例，其第一个字节是协议 magic，可以用于校验当前报文是否属于 SOFABolt 协议，并可以用于协议自动识别匹配的场景；第二个字节是 type，用于标识当前报文的传输类型，可以是 Request / RequestOneway / Response 中的一种；第三个字节则是当前报文的业务类型，可以是心跳帧，RPC 请求/响应等类型。后面的字段就不一一介绍了，可以发现，理解了协议格式本身，其实对于协议的特性支持和模型编解码就理解了一大半，因此第一步协议格式的确认了解是重中之重，是后续一切工作开展的前提。\nStep2：确认报文模型 顺应第一步，第二步的主要工作是确认报文编程模型。一般地，在第 …","date":1585227600,"description":"本文根据昨晚直播整理，主要分享云原生网络代理 MOSN 多协议机制解析，并介绍对应私有协议快速接入实践案例以及对其实现多协议低成本接入的设计进行解读。","dir":"blog/sofa-channel-13-retrospect/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"683f36d11af9e48e910e694bf1a119fc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-13-retrospect/","publishdate":"2020-03-26T21:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-channel-13-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["MOSN","Service Mesh","SOFAChannel"],"title":"云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-13-retrospect/","wordcount":6523},{"author":"敖小剑","categories":"Service Mesh","content":" 在2019年5月，CNCF 筹建通用数据平面 API 工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API。\n当时我写了一个博客文章 “CNCF 正在筹建通用数据平面 API 工作组，以制定数据平面的标准 API” 对此进行了介绍。当时 UDPA 还处于非常早期的筹备阶段，信息非常的少。\n现在9个月过去了，我最近收集并整理了一下 UDPA 目前的情况和信息，给大家介绍一下 UDPA 目前最新的进展（截止2020年2月24日）。\n另外蚂蚁金服开源的云原生网络代理 MOSN 目前已经支持 xDS v2 API，后面也会逐步向着 UDPA 的方向去演进，兼容标准 Istio，感兴趣的读者可以去了解下。\nMOSN：https://github.com/mosn/mon\nUDPA 介绍 首先快速介绍一下什么是 UDPA：\n UDPA ：“Universal Data Plane API”的缩写， “通用数据平面 API” UDPA-WG：”Universal Data Plane API Working Group”的缩写，这是 CNCF 下的一个工作组，负责制定 UDPA； UDPA 的目标，援引自 https://github.com/cncf/udpa 的描述：\n 通用数据平面 API 工作组（UDPA-WG）的目标是召集对数据平面代理和负载均衡器的通用控制和配置 API 感兴趣的业界人士。\n UDPA 的愿景，同样援引：\n 通用数据平面 API（UDPA）的愿景在 https://blog.envoyproxy.io/the-universal-data-plane-api-d15cec7a 中阐明。我们将寻求一组 API，它们为 L4/L7 数据平面配置提供事实上的标准，类似于 SDN 中 L2/L3/L4 的 OpenFlow 所扮演的角色。 这些 API 将在 proto3 中规范定义，并通过定义良好的、稳定 API 版本控制策略，从现有的 Envoy xDS API 逐步演进。API 将涵盖服务发现、负载均衡分配、路由发现、监听器配置、安全发现、负载报告、运行状况检查委托等。 我们将对 API 进行改进和成型，以支持客户端 lookaside 负载均衡（例如 gRPC-LB），Envoy 之外的数据平面代理，硬件 LB，移动客户端以及其他范围。我们将努力尽可能与供应商和实现无关，同时坚持支持已投入生产的 UDPA 的项目（到目前为止，Envoy 和 gRPC-LB）。\n 对 UDPA 感兴趣的同学，可以通过以下两个途径进一步深入了解：\n UDPA @ GitHub：UDPA 在 github 上的项目，UDPA API 定义的代码都在这里； Universal Data Plane API Working Group (UDPA-WG)：CNCF 的 UDPA 工作组，可以通过加入工作组的方式了解更多信息； UDPA 和 xDS 的关系 在展开 UDPA 的细节之前，有必要先解释清楚 UDPA 和 xDS 的关系，因为这对理解 UDPA 会有很大帮助。\n在2019年11月的 EnvoyCon 上，Envoy 的开发者，也是目前 UDPA 最主要的负责人之一，来自 Google 的 Harvey Tuch，有一个演讲非常详细而清晰的解答了这个问题，这个演讲的标题是：“The Universal Dataplane API (UDPA): Envoy’s Next Generation APIs”。\n 备注：这里我直接援引这份演讲的部分内容，以下两张图片均出自 这份演讲的PPT 。鸣谢 Harvey。\n 下图展示了近年来 xDS 协议的演进历程和未来规划：\n 2017年，xDS v2 引入 proto3 和 gRPC，同年 Istio 项目启动； 2018和2019年，xDS v2 API 继续发展，陆续引入了新的 API 定义，如 HDS / LRS / SDS 等，尤其是为了改进 Pilot 下发性能，开始引入增量推送机制； xDS v3 API 原计划于2019年年底推出，但目前看技术推迟，目前 v3 还是 alpha1 状态，预计在即将发布的 Istio 1.5 中会有更多的 v3 API 引入。同时 v3 API 也引入了 UDPA 的部分内容，但是由于 UDPA 目前进展缓慢，对 xDS 的影响并不大，主要还是 xDS 自身的发展，比如对 API 和技术债务的清理； 但在2020年，预计 UDPA 会有很大的进展，尤其是下面我们将会展开的 UDPA-TP 和 UDPA-DM 的设计开始正式制定为 API 之后。而 xDS v4 预计将基于 UDPA ，因此 xDS v4 可能会迎来比较大的变动； 简单总结说：xDS 将逐渐向 UDPA 靠拢，未来将基于 UDPA 。\n下图则展示了 Envoy 在 xDS 版本支持上的时间线：\n目前看这个计划在执行时稍微有一点点延误，原计划于2019年年底推出的 v3 的 stable 版本实际上是在1月中定稿的。（备注：具体可参考 Envoy PR api: freeze v3 API ）。然后目前正在广泛使用的 v2 API 将被标记为 depreated。而且在2020年底，v3 API 预计被 v4 API 取代（注意 v4 API 将会是基于 UDPA），而目前我们最熟悉的 v2 API 将计划在2020年底移除，不再支持！\n上图也展示了未来 xDS 协议的大版本演进和更替的方式，总的来说规律是这样：\n 一年一个大版本：2019 v2 -\u0026amp;gt; 2020 v3 -\u0026amp;gt; 2021 v4 -\u0026amp;gt;2022 v5； 每个大版本都要经历 alpha -\u0026amp;gt; stable -\u0026amp;gt; deprecated -\u0026amp;gt; removed 四个阶段，每个阶段历时一年； 稳定后 Envoy 会同时存在三个 API 大版本：正在使用的稳定版本，已经弃用的上一个稳定版本，准备开发的新的下一个大版本（但只会是Alpha）； 发布一个新的 stable 的大版本，就一定会 deprecated 上一个稳定的大版本，同时 remove 更前一个已经 deprecated 的大版本； 所谓 “长江后浪推前浪，前浪死在沙滩上”，又或者说，“江山代有新版出，各领风骚12个月”。\n 备注：Envoy 具体的稳定 API 版本控制策略，可以参见 Envoy 的设计文档 “Stable Envoy API versioning” ，不过这个文档长的有点过分，嫌长的同学可以直接看这个文档的缩减版本 API versioning guidelines。\n UDPA API 进展 言归正传，我们来看一下 UDPA 目前的最新进展。从 https://github.com/cncf/udpa ，可以看到目前 UDPA 中已经定义好的部分 API 内容：\n类型定义 目前只定义了一个类型 TypedStruct。\nTypedStruct 包含任意 JSON …","date":1585130400,"description":"本文收集并整理了一下 UDPA 目前的情况和信息，给大家介绍一下 UDPA 目前最新的进展。","dir":"blog/service-mesh-api-udpa-follow-up/","fuzzywordcount":11000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7293f926580393ddac18da73da056d07","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","publishdate":"2020-03-25T18:00:00+08:00","readingtime":22,"relpermalink":"/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","summary":"在2019年5月，CNCF 筹建通用数据平面 API 工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API。 当时我写了一","tags":["Service Mesh"],"title":"Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍","type":"blog","url":"/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","wordcount":10901},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@木易 提问：\n 请问，这个并发隔离是怎么做到的？二阶段是一阶段的最后去做的对吧，在 TCC 模式下的，RPC 调用二阶段失败了或者 MQ 异步调二阶段失败了，那二阶段失败了可咋整？ A：一阶段如果都成功了，说明所有分支的事务的“资源”已经预留成功了，这时候的失败都是“技术上”的失败比如网络抖动，这时会要重试提交。举个例子，如果二阶段一部份服务 commit 成功了，然后有一个失败了，这时只能重试提交，不能回滚，因为那些二阶段已经成功的服务，不能回滚了。\n 是不是一阶段的发起方还得根据业务编号记录一条 response，然后参与方定时去扫状态未更新的记录，然后根据业务编号去查 response 中的状态再更新自己的状态？\n A：业务流水是肯定要记的。\n 有行锁可用余额肯定没问题，就是这个预扣冻结字段如果放这行数据里，一阶段一释放锁，另一个事务给他改了就不对了，所以我感觉表里加这个字段不行啊，还是得用业务流水加这个预扣字段形成一条记录，这样事务之间的这个才是隔离的 。\n A：是的，是在业务上还要记录一条流水，一来为是业务上的要求，二来可以做幂等和防悬挂控制，三也是在回滚的时候需要这条流水才知道要回滚多少金额。\n相关阅读：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理\nSeata：https://github.com/seata/seata\n2、@邓从宝 提问：\n 您好，合并部署是个什么概念？什么时候会用到合并部署？\n A： 就是将原本独立开发的应用部署在一起，比如资源有限要高密度部署的时候，比如两个微服务应用频繁 rpc 交互想要部署到一个进程里提高性能的时候。\n3、@苏东东 提问：\n SOFAJRaft 能不能不通过 rpcserver 注册 GetValueRequestProcessor，我想用自己的 RPC 框架。\n A：暂时不能，请关注这个 pr 合并以后就可以了 https://github.com/sofastack/sofa-jraft/pull/402 详细 issue： https://github.com/sofastack/sofa-jraft/issues/268 SOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFAArk 解析文章集合 蚂蚁金服轻量级类隔离框架 Maven 打包插件解析 | SOFAArk 源码解析 蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFATracer 解析文章集合 蚂蚁金服分布式链路跟踪组件 SOFATracer 中 Disruptor 实践（含源码） 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 埋点机制剖析 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 采样策略和源码剖析 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 链路透传原理与SLF4J MDC 的扩展能力剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析 社区直播报名 作为云原生网络代理，Service Mesh 是 MOSN 的重要应用场景。随着 Service Mesh 概念的日益推广，大家对这套体系都已经不再陌生，有了较为深入的认知。但是与理论传播相对应的是，生产级别的大规模落地实践案例却并不多见。这其中有多方面的原因，包括社区方案饱受诟病的“大规模场景性能问题”、“配套的运维监控基础设施演进速度跟不上”、“存量服务化体系的兼容方案”等等。\n现实场景中，大部分国内厂商都有一套自研 RPC 的服务化体系，属于「存量服务化体系的兼容方案」中的协议适配问题。为此，MOSN 设计了一套多协议框架，用于降低自研体系的协议适配及接入成本，加速 Service Mesh 的落地普及。SOFAChannel#13，将向大家介绍 MOSN 实现多协议低成本接入的设计思路以及相应的快速接入实践案例。\n 主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 时间：2020年3月26日（周四）19:00-20:00 嘉宾：无钩，蚂蚁金服技术专家、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 欢迎参与投票 MOSN Logo 社区投票，在本期直播结束将公布投票结果，确定最新 Logo。\n 投票方式：回复 issue 你喜欢的方案编号以及原因 ","date":1584691200,"description":"【03/16-03/20】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200320/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e2add88606de2be4ddcf9c9ac2e4bbef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200320/","publishdate":"2020-03-20T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200320/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告、SOFAArk\u0026SOFATracer 解析文章合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200320/","wordcount":1761},{"author":"盲僧","categories":"SOFAArk","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAArk 实现原理》第二篇，本篇作者盲僧，来自 OYO。《剖析 | SOFAArk 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附系列共建列表，目前已完成领取。\n前言 SOFAArk 是 SOFA 团队开源的又一款扛鼎力作，它是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署的能力。\n从 2016 年底开始，蚂蚁金服内部开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构，也是为系列文章做好铺垫。\nSOFAArk biz 的打包插件是 sofa-ark-maven-plugin ，它可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式的 Ark 包或者 Ark Biz 包，关于 Ark 包和 Ark Biz 包可以参考这里：\n Ark 包：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/ Ark Biz：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/ 本文将从如下三个方面进行介绍：先对插件的使用和打包出来的产物做一个简单介绍，然后告诉大家调试插件的方法，最后对整个插件的原理做一个流程图和阐述。\nSOFAArk ：https://github.com/sofastack/sofa-ark\nSOFAArk 插件使用 文中的示例代码可以参考 我的 github\n 插件使用 先将 Spring Boot 的打包插件 spring-boot-maven-plugin 删除或者注释，然后再引入如下插件即可：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 执行 mvn package 命令后，将会打出如下结构的 3 个 jar 包，大家可以自行解压这三个 jar 包，看一看里面的具体内容，下面我们简单分析一下：\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT.jar ：它是 maven 插件打出来的原生 jar 包，只包含我们写的代码和 manifest 文件，无特殊意义。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-biz.jar ：这个 jar 包称之为 Ark Biz 包，因为 SOFAArk 容器是支持运行多个 Ark Biz 的，所以打成这种包是为了和别的项目一起合并部署使用，另外 Ark 包里也包含了这个。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-executable.jar ：这个 jar 包称之为 Ark 包，从字面上来看它是一个可执行的 jar 包，即意味着它是一个可以用 java-jar 命令来单独运行的 Fat Jar，类似于我们用 Spring Boot 插件打出来的包。\n后面的分析主要是围绕 Ark 包来做讲解，因为它包含了 Ark Biz 包，所以只要搞明白它是如何生成的，那么对整个插件的原理也就基本了解了。\n与 Spring Boot 插件对比 要想分析出 sofa-ark-maven-plugin 插件的作用，我们需要先和 Spring Boot 的插件进行对比，从打包产物上直观的感受一下两者的区别。\nspring-boot-maven-plugin 插件 spring-boot-maven-plugin 是 SpringBoot 默认提供的打包插件，其功能就是将工程打包成一个可执行的 FATJAR。spring-boot-maven-plugin 打包产物的目录结构如下：\n. ├── BOOT-INF │ ├── classes # 应用的字节码目录 │ └── lib # 应用所依赖的 jar 包 ├── META-INF │ ├── MANIFEST.MF # manifest 文件信息 │ └── maven # 应用的坐标信息 └── org └── springframework └── boot └── loader # 存放的是 Spring Boot Loader 的 class 文件 ├── JarLauncher.class # Spring Boot 启动类 ├── archive ├── data ├── jar └── util MANIFEST.MF 文件内容：\nManifest-Version: 1.0 Archiver-Version: Plexus Archiver Built-By: rrz Start-Class: pers.masteryourself.tutorial.sofa.ark.maven.plugin.MavenP luginApplication Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Spring-Boot-Version: 2.1.4.RELEASE Created-By: Apache Maven 3.5.3 Build-Jdk: 1.8.0_101 Main-Class: org.springframework.boot.loader.JarLauncher MANIFEST.MF 文件中可以看到，描述了当前 jar 的一些核心元素，包括启动类、class 文件路径、lib 依赖路径、jdk 版本等等，这里需要关注的是 Main-Class，SpringBoot 就是通过该类来引导启动的。SOFAArk 应用也提供了类似的引导类及其自身特殊的结构， …","date":1584612000,"description":"本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构","dir":"blog/sofa-ark-maven- packaging-plugins/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dd530d14f20a460c2f49300c0d784c32","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","publishdate":"2020-03-19T18:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAArk","SOFAArkLab"],"title":"蚂蚁金服轻量级类隔离框架 Maven 打包插件解析 | SOFAArk 源码解析","type":"blog","url":"/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","wordcount":3304},{"author":"卫恒","categories":"SOFATracer","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n Disruptor 简介 Disruptor 旨在在异步事件处理体系结构中提供低延迟，高吞吐量的工作队列。它确保任何数据仅由一个线程拥有以进行写访问，因此与其他结构相比，减少了写争用。目前，包括 Apache Storm、Camel、Log4j 2 在内的很多知名项目都应用了 Disruptor 以获取高性能。\nSOFATracer 也是基于 Disruptor 高性能无锁循环队列来提供异步打印日志到本地磁盘能力的，SOFATracer 提供两种类似的日志打印类型即摘要日志和统计日志，摘要日志：每一次调用均会落地磁盘的日志；统计日志：每隔一定时间间隔进行统计输出的日志；无论是哪种日志的输出，对于 SOFATracer 来说都需要保证较高的性能，以降低对于业务整体流程耗时的影响。\n关于 Disruptor 的 一些原理分析可以参考：Disruptor 。\n A High Performance Inter-Thread Messaging Library 高性能的线程间消息传递库\n 案例 先通过 Disruptor 的一个小例子来有个直观的认识；先看下它的构造函数：\npublic Disruptor( final EventFactory\u0026amp;lt;T\u0026amp;gt; eventFactory, final int ringBufferSize, final ThreadFactory threadFactory, final ProducerType producerType, final WaitStrategy waitStrategy) { this( RingBuffer.create(producerType, eventFactory, ringBufferSize, waitStrategy), new BasicExecutor(threadFactory)); } eventFactory : 在环形缓冲区中创建事件的 factory； ringBufferSize:环形缓冲区的大小，必须是2的幂； threadFactory：用于为处理器创建线程； producerType：生成器类型以支持使用正确的sequencer和publisher创建RingBuffer；枚举类型，SINGLE、MULTI两个项。对应于 SingleProducerSequencer和MultiProducerSequencer两种Sequencer； waitStrategy : 等待策略； 如果我们想构造一个 disruptor，那么我们就需要上面的这些组件。从 eventFactory 来看，还需要一个具体的 Event 来作为消息事件的载体。【下面按照官方给的案例进行简单的修改作为示例】\n消息事件 LongEvent ，能够被消费的数据载体 public class LongEvent { private long value; public void set(long value) { this.value = value; } public long getValue() { return value; } } 创建消息事件的 factory public class LongEventFactory implements EventFactory\u0026amp;lt;LongEvent\u0026amp;gt; { @Override public LongEvent newInstance() { return new LongEvent(); } } ConsumerThreadFactory public class ConsumerThreadFactory implements ThreadFactory { private final AtomicInteger index = new AtomicInteger(1); @Override public Thread newThread(Runnable r) { return new Thread(r, \u0026amp;quot;disruptor-thread-\u0026amp;quot; + index.getAndIncrement()); } } OK ，上面的这些可以满足创建一个 disruptor 了：\nprivate int ringBufferCapacity = 8; //消息事件生产Factory LongEventFactory longEventFactory = new LongEventFactory(); //执行事件处理器线程Factory ConsumerThreadFactory consumerThreadFactory = new ConsumerThreadFactory(); //用于环形缓冲区的等待策略。 WaitStrategy waitStrategy = new BlockingWaitStrategy(); //构建disruptor Disruptor\u0026amp;lt;LongEvent\u0026amp;gt; disruptor = new Disruptor\u0026amp;lt;\u0026amp;gt;( longEventFactory, ringBufferCapacity, longEventThreadFactory, ProducerType.SINGLE, waitStrategy); 现在是已经有了 disruptor 了，然后通过：start 来启动：\n//启动 disruptor disruptor.start(); 到这里，已经构建了一个disruptor；但是目前怎么使用它来发布消息和消费消息呢？\n发布消息 下面在 for 循环中 发布 5 条数据：\nRingBuffer\u0026amp;lt;LongEvent\u0026amp;gt; ringBuffer = disruptor.getRingBuffer(); for (long l = 0; l \u0026amp;lt; 5; l++) { long sequence = ringBuffer.next(); LongEvent event = ringBuffer.get(sequence); event.set(100+l); System.out.println(\u0026amp;quot;publish event :\u0026amp;quot; + l); ringBuffer.publish(sequence); Thread.sleep(1000); } 消息已经发布，下面需要设定当前 disruptor 的消费处理 …","date":1584439200,"description":"本文将对 SOFATracer 中使用 Disruptor 来进行日志输出的代码进行了具体的分析。","dir":"blog/sofa-trcaer-disruptor-practice/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a97d804a20a7af180c889c55210ab2fa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","publishdate":"2020-03-17T18:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFATracer"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 中 Disruptor 实践（含源码）","type":"blog","url":"/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","wordcount":5441},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析\n 活动时间：3 月 26 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 作为云原生网络代理，Service Mesh 是 MOSN 的重要应用场景。随着 Service Mesh 概念的日益推广，大家对这套体系都已经不再陌生，有了较为深入的认知。但是与理论传播相对应的是，生产级别的大规模落地实践案例却并不多见。这其中有多方面的原因，包括社区方案饱受诟病的“大规模场景性能问题”、“配套的运维监控基础设施演进速度跟不上”、“存量服务化体系的兼容方案”等等。\n现实场景中，大部分国内厂商都有一套自研 RPC 的服务化体系，属于「存量服务化体系的兼容方案」中的协议适配问题。为此，MOSN 设计了一套多协议框架，用于降低自研体系的协议适配及接入成本，加速 Service Mesh 的落地普及。本次演讲将向大家介绍 MOSN 实现多协议低成本接入的设计思路，以及相应的快速接入实践案例。\n本期为 SOFAChannel 线上直播第 13 期，将邀请蚂蚁金服技术专家\u0026amp;amp; MOSN Committer 无钩分享《云原生网络代理 MOSN 的多协议机制解析》。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：21992058（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1131\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 无钩 蚂蚁金服技术专家 MOSN Committer\n本期分享大纲 一个请求的 MOSN 之旅 如何在 MOSN 中接入新的协议 SOFABolt 协议接入实践 未来发展：统一路由框架 嘉宾 SOFAGirl 主持人 无钩 蚂蚁金服技术专家 MOSN Committer ","date":1584349200,"description":"3 月 26 日周四晚 7 点，线上直播第 13 期。","dir":"activities/sofa-channel-13/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ba88bba5176867c90fb18dc045408d84","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-13/","publishdate":"2020-03-16T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-13/","summary":"概要 活动主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 活动时间：3 月 26 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介","tags":["SOFAChannel","MOSN"],"title":"SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-13/","wordcount":692},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@胡秋林 提问：\n 请教一个问题，服务拆分然后使用分布式事务，会不会事务链路过长，然后整体性能下降很大呢？\n A：用了分布式事务性能肯定会下降，这是大家对一致性和性能的取舍。在性能对比这块我建议大家去和同类的分布式事务框架对比，而不是只和不用分布式事务去对比。分布式事务很大一部分是处理的系统异常时的一致性，如果针对系统异常这个点，大家如果相信自己的框架 100% 正常的，不会出现超时，网络和宕机等问题，那可以不使用分布式事务，所以保证一致性的很多场景是极端情况下的一致性，在同类框架的对比中，一定是看框架一致性场景的覆盖，如果场景覆盖不全的基础上和我们对比性能我觉得这个没太大意义。这就好比我系统有 1% 几率出现极端情况，我不用 Seata 和使用 Seata 的对比是一样的。\n2、@吴攀 提问：\n 麻烦问下，我现在做的一个销售订单的流程。需要监听审批的状态变化，然后状态机才往下进行流转。Saga 能否满足呢？  A：目前是不支持的，因为 Saga 的状态机定位是服务编排的事务处理，不应该包含人工审批动作，建议做成两个流程，包含人工审批动作，中间状态时间会很长。\n 我来状态想能否把“状态”配置成“IsAsync = true”来实现，然后异步任务来监听审批状态的变化。感觉有些负责。所以来咨询下？有没有更好其他的推荐的方案呢？Netflix Conductor 能满足这个场景么？我现在的场景是：一个销售单出库的流程。销售单建立成功后，要经过审批流程进行审批，然后进入仓库进行库存分配。分配成功后，进行分拣，然后进行打包。最后进行出库。老板想把这些状态流转编制成一个 Saga 支持的状态机。\n A：isAsync 是这个服务异步调用，应该解决不了你这个问题。我的建议是把这个流程差分一下，拆分成两个，或者，销售订单不要纳入状态机，只是插入一条记录，审批通过后，把后面的流程配置成状态机，而且我理解你们这流程是每一步都是人工做完，然后在系统里点一下，然后继续，如果是这样，这不是服务编排的需求，为是工作流的需求。\nSeata：https://github.com/seata/seata\n3、@兴元 提问：\n SOFABoot 版本 v3.3.0，目前官网文档里只有整合 Nacos 0.6.0 版本的，请问怎么使用 Nacos 的命名空间功能？SOFABoot 版本 v3.3.0，maven 引用里 nacos-client 版本是 1.0.0，请问现在支持 nacos 最新版本是多少。\n A：Nacos 配置格式参考：https://www.sofastack.tech/projects/sofa-rpc/registry-nacos/ 对于 namespace 的，可以配置成这样即可：namespace nacos://yyy:8848/namespaceNacos 客户端应该是兼容的，你可以直接升级这个包的版本。\n 命名空间问题解决了，感谢。因为我使用的时候指定了 nacos client 版本为0.6.0，升级到 0.8.0 以上nacos://yyy:8848/namespace 这种形式是可以的，而且只能使用 nacos://yyy:8848/namespace 这种形式，nacos://yyy:8848 是不行的。还望官方文档可以及时更新一下。\n A：这里应该是要配置成：nacos://yyy:8848/ 后面有个/。好的，最近我们升级一下 Nacos 的 client 版本。文档我们同步修改下。\n 刚试了nacos://yyy:8848/，服务依然无法发布到默认命名空间。Nacos server 是1.2.0，客户端是使用SOFABoot v3.3.0。\n A：不会发到默认的，这个会发到的是 SOFARPC 这个 Namespace：private static final String DEFAULT_NAMESPACE = \u0026amp;quot;sofa-rpc\u0026amp;quot;;\nSOFARPC：https://github.com/sofastack/sofa-rpc\n期待见到，每一个精彩的你 蚂蚁金服云原生团队实习生招聘开始啦 【岗位继续增了】蚂蚁金服云原生团队招聘~欢迎加入我们 SOFAChannel 直播回顾 SOFAChannel#12：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.3.1 版本，主要变更如下：\n 升级 Spring Boot 至 2.1.13.RELEASE； 修复 Tomcat AJP 漏洞； …","date":1584086400,"description":"【03/09-03/13】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200313/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cd22bd67fe25923bca65eae188627da8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200313/","publishdate":"2020-03-13T16:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200313/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 3/26 直播预告、多个组件发布、云原生团队校招社招信息汇总","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200313/","wordcount":2967},{"author":"仁空","categories":"SOFA Weekly","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#12 直播分享整理，主题：蚂蚁金服分布式事务实践解析。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 大家好，我是今天分享的讲师仁空，目前是蚂蚁金服分布式事务产品的研发。今天跟大家分享的是蚂蚁金服分布式事务实践解析，也就是分布式事务 Seata 在蚂蚁金服内部的实践。\n今天我们将从以下 4 个主题进行详细介绍：\n 为什么会有分布式事务产品的需求； 理论界针对这个需求提出的一些理论和解决方案； 蚂蚁金服在工程上是如何解决这个问题的； 针对蚂蚁金服业务场景的性能优化； 分布式事务产生背景 首先是分布式事务产生的背景。\n支付宝支付产品在 2003 年上线的时候，那时候的软件形态是单体应用，在一个应用内完成所有的业务逻辑操作。随着软件的工业化，场景越来越复杂，软件也越做越大，所有的业务在一个应用内去完成变的不可能，出现了软件模块化、服务化。\n在从单体应用升级到分布式架构过程中，很自然得需要进行业务服务拆分，将原来糅在一个系统中的业务进行梳理，拆分出能独立成体系的各个子系统，例如交易系统、支付系统、账务系统等，这个过程就是服务化。业务服务拆分之后，原来一个服务就能完成的业务操作现在需要跨多个服务进行了。\n另一个就是数据库拆分，分库分表。原来的单体数据库存不下的这么多信息，按服务维度拆库，比如把用户相关的存一起，形成用户库，订单放一块形成订单库，这个是拆库的过程；另一个是拆表，用户信息按照用户 ID 散列到不同的 DB 中，水平拆分，数据库的容量增大了。这样分库分表之后，写操作就会跨多个数据库了。\n分布式事务理论基础 我们可以看到，在分布式架构中，跨数据库、跨服务的问题是天然存在的。一个业务操作的完成，需要经过多个服务配合完成，这些服务操作的数据可能在一个机房中，也可能跨机房存在，如果中间某一个服务因为网络或机房硬件的问题发生了抖动，怎么保证这笔业务最终的状态是正确的，比如支付场景，怎么防止我转钱给你的过程中，我的钱扣了，而对方的账户并没有收到钱。这个就是业务最终一致性的问题，是分布式事务需要解决的问题。\n2PC 协议 针对这个问题，理论界也提出了解决方案，其中最为人熟知的就是二阶段协议了，简称2PC（Two Phase Commitment Protocol）两阶段提交协议。\n两阶段提交协议，就是把整个过程分成了两个阶段，这其中，它把参与整个过程的实体分成了两类角色，一个叫事务管理器或事务协调者，一个叫资源管理器，事务管理器我们也把它叫做事务发起方，资源管理器称为事务参与者。\n两个阶段，第一个阶段是资源准备阶段，比如我要转账，我要先查询下我的余额够不够，够的话我就把余额资源预留起来，然后告诉发起方“我准备好了”，第二个阶段，事务发起方根据各个参与者的反馈，决定事务的二阶段操作是提交还是取消。\nTCC 协议 另一个协议是 TCC 协议，各个参与者需要实现3个操作：Try、Confirm 和 Cancel，3个操作对应2个阶段，Try 方法是一阶段的资源检测和预留阶段，Confirm 和 Cancel 对应二阶段的提交和回滚。\n图中，事务开启的时候，由发起方去触发一阶段的方法，然后根据各个参与者的返回状态，决定二阶段是调 Confirm 还是 Cancel 方法。\n蚂蚁金服分布式事务介绍 2019年，蚂蚁金服跟阿里巴巴共同开源了分布式事务 Seata ，目前 Seata 已经有 TCC、AT、Saga 模式，Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。今天的分享也是 Seata 在蚂蚁金服内部的实践。\n分布式事务在蚂蚁金服的发展 基于上述的理论，接下来我们详细看下蚂蚁金服的分布式事务实现。\n经过多年的发展，蚂蚁金服内部针对不同的场景发展了几种不同的模式，最早的是 TCC 模式，也就是上面讲的 Try - confirm - Cancel，我们定义接口规范，业务自己实现这3个操作。这个模式提供了更多的灵活性，因为是业务自己实现的，用户可以介入两阶段提交过程，以达到特殊场景下的自定义优化及特殊功能的实现，这个模式能几乎满足任何我们想到的事务场景，比如自定义补偿型事务、自定义资源预留型事务、消息事务等场景。TCC 模式广泛用于蚂蚁金服内部各金融核心系统。\n这里要强调一点的是，TCC 模式与底层数据库事务实现无关，是一个抽象的基于 Service 层的概念，也就是说，在 TCC 的范围内，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，或者列式存储数据库 HBase，只要将对它们的操作包装成 TCC 的参与者，就可以接入到 TCC 事务范围内。\nTCC 模式的好处是灵活性，弊端是牺牲了易用性，接入难度比较大，所有参与者需要进行改造提供 Try - Confirm - Cancel 三个方法。为了解决 TCC 模式的易用性问题，蚂蚁金服分布式事务推出了框架管理事务模式（Framework - Managed Transactions，简称 FMT），也就是 Seata 中的 AT 模式。FMT 模式解决分布式事务的易用性问题，最大的特点是易于使用、快速接入、对业务代码无侵入。\nXA 模式是依赖于底层数据库实现的。\nSaga 模式是基于冲正模型实现的一个事务模式，现在的银行业金融机构普遍用的是冲正模型。\n这期我们重点讲 TCC 和 FMT，关于 Saga 模式，之前 Saga 模式也有专场直播分享过，感兴趣的可以看一下之前的直播回顾：《Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾》。\nTCC 模式在蚂蚁金服内的使用 首先看下 TCC 模式，主要包含一下几个模块：\n 参与者，它要实现全部的三个方法，Try、Confirm 和 Cancel； 发起方，主要是作为协调者的角色，编排各个参与者，比如调用参与者的一阶段方法，决策二阶段是执行提交还是回滚； 举个例子，比如在这个流程图中，存在一个发起方和两个参与者，两个参与者分别实现了 Try、Confirm 和 Cancel 接口，第一阶段被包含在发起方的本地事务模版中（图中黄颜色的两条虚线就是发起方本地事务的范围），也就是说发起方负责调用各个参与者的一阶段方法，发起方的本地事务结束后，开始执行二阶段操作，二阶段结束则整个分布式事务结束。\n二阶段是通过 Spring 提供的事务同步器实现的，发起方在发起一个分布式事务的时候，会注册一个事务同步器，当发起方本地事务结束的时候，会进入事务同步器的回调方法中。如果发起方的本地事务失败，则在回调中自动回滚所有参与者。如果发起方的本地事务成功，则二阶段自动提交所有参与者。二阶段结束后，删除所有事务记录。\n总结一下：\n 事务发起方是分布式事务的协调者； 分布式事务必须在本地事务模板中进行，发起方本地事务的最终状态（提交或回滚）决定整个分布式事务的最终状态； 发起方主职责：开启一个分布式事务 + 调用参 …","date":1584016200,"description":"分布式事务 TCC、FMT 模式在蚂蚁金服内部的实践分享。","dir":"blog/sofa-channel-12-retrospect/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1aaf09602548f4204f00c7b02260e180","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-12-retrospect/","publishdate":"2020-03-12T20:30:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-channel-12-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#12 直播分享整理，主题：蚂蚁金服分布式事务实践解析。 回顾视频以及 PPT 查看地址见文末","tags":["SOFAChannel","分布式事务"],"title":"蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-12-retrospect/","wordcount":6522},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@水木今山 提问：\n 请问下 SOFAJRaft 能否在日志复制到大多数后就响应客户端？我看 rhea 和 counter 的例子好像都是应用到状态机后才通过 closure 响应客户端。\n A：SOFAJRaft 没有限制，可以在自己的 statemachine 里不直接返回客户端再应用， rheakv 不能。举个例子， compareAndSet 操作，需要先读取再设置，最后返回 client，那么怎么能做到不应用状态机就返回呢，对吧？\n 有道理，但直接返回客户端的逻辑只能在 StateMachine 提供的 onApply 方法里实现吗，因为 onApply 的调用应该会滞后许久吧？\n A：onApply 里面实现就可以，onApply 就可以理解为和达成多数派之间没有延迟。\n 我在文档中有看到 TaskClosure 这么一个接口，在它的 onCommitted 方法里响应客户端会不会更高效？据我所知，raft 仅需写入日志就可保证强一致性，可以异步去 apply，所以在复制日志给大多数后就通过 onCommitted方法响应客户端（尽管还没有任何一个节点 apply 了该日志），这样效率好像会高一点，不知道我对这个接口理解有没有误。\n A：com.alipay.sofa.jraft.core.FSMCallerImpl#doCommitted\n可以看看这个方法，里面会在调用状态机之前调用 TaskClosure，想用 TaskClosure 也可以，不过两者没什么延迟区别。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@匿名 提问：\n MOSN 支持 Istio 的什么版本？什么时候可以在 Istio 中可用？\n A：目前 MOSN 可基于 Istio 1.1.4 跑通 bookinfo example，由于最新版本的 Istio 对 XDS 协议进行了升级以及部分能力增强，MOSN 当前正在适配中，预计 2020 年 10 月份会完整支持高版本 Istio 的 HTTP 系能力；同时我们一直在关注 UDPA 的发展，也在尝试参与到标准的制定中。控制平面方面，我们和社区一直保持紧密沟通与合作，大力发展控制平面，MOSN 也将与控制平面共同前进。\nMOSN：https://github.com/mosn/mosn\n3、@孙俊 提问：\n 请问下，全局事务开启后，全局事务锁未释放时，此时又来个操作同一个数据的本地请求，这个请求没有开启全局事务，是可以修改这个数据的呀。\n A：全局事务的分支事务结束后，不在全局事务的本地数据请求可修改数据。\n 那这样，全局事务的其他分支出现异常，分支事务回滚，从undo里读，发现数据已经被修改了，就得人工处理了？\n A：是，从业务设计上来说如果使用 AT 模式要把数据修改都交给 AT 来管理来避免这类问题。 Seata：https://github.com/seata/seata\n剖析 SOFARegistry 系列 服务注册中心数据一致性方案分析 | SOFARegistry 解析 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 1、发布 SOFARegistry v5.4.0 版本，主要变更如下：\n SessionServer 与 DataServer 通讯性能优化； jraft 从 1.2.5 更新到 1.2.7.beta1； 解决 MethodHandle 在某些 jdk 版本存在内存泄露的 bug； Bug Fix； 详细发布报告：https://github.com/sofastack/sofa-registry/releases/tag/v5.4.0\n2、发布 SOFAArk v1.1.1 版本，主要变更如下：\n 优化biz 卸载，清理临时文件； 支持 biz 打包 指定 bizName -D 参数； 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.1.1\n社区直播预告 SOFAChannel#12 线上直播将邀请蚂蚁金服分布式事务核心开发仁空分享介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1583481600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200306/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"762ff425feef89f406716a6c0c4fff9d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200306/","publishdate":"2020-03-06T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200306/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARegistry 发版以及源码系列合辑、SOFAArk 发版、3/12直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200306/","wordcount":1922},{"author":"SOFA 团队","categories":"云原生","content":" 2月19日-2月26日，蚂蚁金服开展了“共战‘疫情’，技术破局”数字课堂线上直播，邀请资深专家从“云原生”、“研发效能”、“数据库”三方面分享蚂蚁金服的实践经验并在线答疑，解析 PaaS 在金融场景的落地建设实践，解析支付宝移动端弹性动态架构，分享 OceanBase 2.2版本的特性和实践。\n 本文根据 蚂蚁金服 SOFAStack 产品专家俞仁杰，在蚂蚁金服数字课堂直播间分享的云原生应用 PaaS 平台的建设实践内容整理，以下为演讲整理全文：\n大家好，欢迎来到蚂蚁金服数字课堂直播间。今年 2 月，SOFAStack 金融分布式架构产品已经在阿里云上完成了商业化发布，为了让更多朋友了解到我们的产品的能力、定位以及背后的设计思路，后续我们会有一系列的直播分享。我们今天想分享给大家的话题叫《云原生应用 PaaS 平台的建设实践》，主要会围绕 PaaS 产品能力在一些需要稳妥创新的金融场景下的落地思路，并且能够更好地与云原生架构做好链接。\n金融场景云原生落地面临挑战 云原生是业务快速变化背景下的必然技术趋势 回顾 IT 的发展史，云计算分类为 IaaS PaaS 和 SaaS 已经有十几年了。而事实上，整个云计算行业的发展，我们能够明显看到企业在落地云计算战略的时候经历的三个阶段，Cloud-Based, Cloud-Ready, Cloud-Native。这三个阶段其实是因为业务的变化越来越敏捷，要求企业关注重心上移，把更多的精力和人才投入到业务逻辑的建设上，而把下层自已并不擅长并且越来越复杂的基础设施、中间件逐渐交给云计算厂商去实现，专业的人做专业的事。\n这本质是社会分工的进一步细化，也符合人类社会发展的规律。在云原生时代，业界所提出的容器技术，Service Mesh 技术，Serverless 技术都是希望让业务研发与基础技术更加的解耦，让业务创新和基础技术创新都更容易的发生。\n容器技术带来的是一种应用交付模式的变革 云原生就是业务快速变化背景下的必然技术趋势。而这个趋势背后的实质载体，就是我们所说的云原生、Kubernetes 以及以 Docker 为代表的容器技术，这些所带来的，本质是一种应用交付模式的变革。而为了真正能够使业界、社区所倡导的新兴应用交付模式落地到实际的企业环境，我们需要一个以应用为中心的平台来进行承载，贯穿应用运维的各项生命周期。\n围绕“云原生”这个关键词，其实在社区和业界已经有了非常多的交流和资料，围绕Docker/K8S 的最佳实践、DevOps CICD、容器网络存储设计、日志监控对接优化等等等等，而我们今天的分享，主要想表达的是我们围绕在 K8S 之上塑造一个 PaaS 平台的产品价值主张。Kubernetes 是一个非常好的编排和调度框架，它核心的贡献是让应用的编排和资源的调度更加的标准化，同时提供了一个高度可扩展的架构，方便上层进行各种控制器和调度器的定制。但是，它并不是一个 PaaS。PaaS 底层可以基于 Kubernetes 去实现，但是在上层要补足非常多的能力才能真正把 Kubernetes 用于生产环境，特别是金融行业的生产环境。\n金融场景需要“稳妥创新” 生产环境落地云原生需要着重考虑哪些挑战？\n我们之前做过一些调研和客户访谈。就现在 2020 年来说，绝大多数金融机构都展现出了对 Kubernetes、容器等技术的极大兴趣，有不少机构也已经在一些非关键的业务、或开发测试环境搭建了开源或商业版的集群。驱动力很简单，金融机构非常希望这一整套新的交付模式帮助到业务飞速迭代。然而对比落差非常明显的是，真正敢于在核心生产环境落地云原生架构的，又少之又少。因为金融业务创新的前提，是要保障稳妥。\n我们团队在服务蚂蚁内部业务、外部金融机构的过程中，总结了以上这几个方面，事实上这六大方面也是我们内部 SRE 不断挑战的几点。我们在今天以及未来的分享中，会逐步总结深化应对这些挑战的产品思路。\nK8S 体系下的应用变更与发布管控 我们今天分享的一个核心内容，就是我们如何在产品层面做应用变更的风险保障的。并围绕此话题向大家介绍变更“三板斧”的背景、K8S 原生部署能力、我们产品围绕变更需求做的扩展并向大家介绍我们在开源方面的规划。\n需求背景：变更“三板斧” 所谓“三板斧”就是可灰度、可监控、可应急。这是蚂蚁内部运维的一条红线准则，所有的变更，都必须要遵从这个规则，即使再细小的变更，再严密的测试，也不能忽略这条规则。为了满足这个需求，我们在 PaaS 产品层设计了各种各样的精细化发布策略，比如分组发布、beta 发布，灰度发布，蓝绿发布等。这些发布策略跟我们在做传统运维时用的手段是非常相似的，但很多使用容器的用户认为在 K8S 里实现会非常的困难。\n有些时候，由于对业务连续性的极高要求，也很难接受原生 K8S 模型标准化模式，比如原生 Deployment 做灰度或者金丝雀发布时，默认情况下在 Pod 变更和流量治理层面的管控还稍显不足，无法完全做到无损发布或按需过程管控。因此，我们在 PaaS 产品层面做了定制，在 Kubernetes 层面做了自定义资源的扩展，目的是能够在云原生的场景下，依然对整个发布过程实现精细化管控，使得大规模集群发布、灰度、回滚时更加优雅，符合技术风险三板斧原则。 Kubernetes 原生发布能力 我们先来回顾一下 K8S 的原生 Deployment 对象，及其背后的 ReplicaSet，其实已经是在最近好几个大版本中已经逐渐的稳定了。 简单的来说，最常见的 K8S 发布场景，我们会通过 Deployment 的对象，声明出我希望的发布模式以及 Pod Spec 定义。在运行时，会有 ReplicaSet 对象来管理 Pod 数量的预期，默认情况下会提供滚动发布或重建发布能力。\nimage.png\n这幅图的下半部分，是围绕 Deployment 作滚动发布时的示意图，这里不再做过多的展开，它的本质根据用户根据我们的运维需求设定好一定的步长，创建新的 Pod，销毁旧的 Pod，因此能做到整个应用版本的变更和发布过程中，都能有对应的容器对外提供服务。 对大部分场景来说，它是够用的，而且整个过程也是非常好的理解，事实上在 K8S 体系，大家除了 Pod/Node，看的最多的就是 Deployment了。\nCAFEDeployment：感知底层拓扑和领域模型 回顾完 Deployment，我们可以再给大家看一下我们根据实际需求作的 CRD 扩展，CAFEDeployment。CAFE 是我们 SOFAStack PaaS 产品线的名称，本文的最后会作一些介绍。\nCAFEDeployment 有一个很重要的能力，就是能够感知到底层拓扑，这个拓扑是什么意思呢？能够知道我想把我的 Pod 发布到哪里，哪边的 Node，不只是基于亲和性的规则作绑定，而是真正能把高可用、容灾、以及部署策略等场景息息相关的信息，带到整个围绕发布的领域模型中。对此，我们提出了一个叫部署单元的领域模型，他是一个逻辑概念，在 yaml 中简单的叫做 Cell。在实际使用中，Cell 的背后，可以是不同的 AZ 不同的物理机房，不同的机架，一切都是围绕着不同级别的高可 …","date":1583395200,"description":"云原生应用 PaaS 平台的建设实践","dir":"blog/distributed-architecture-and-cloud-native/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6c1ff3975ace44ac5189b1f845a43fcb","permalink":"https://sofastack.github.io/sofastack.tech/blog/distributed-architecture-and-cloud-native/","publishdate":"2020-03-05T16:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/distributed-architecture-and-cloud-native/","summary":"2月19日-2月26日，蚂蚁金服开展了“共战‘疫情’，技术破局”数字课堂线上直播，邀请资深专家从“云原生”、“研发效能”、“数据库”三方面分","tags":["云原生"],"title":"技术破局：如何实现分布式架构与云原生？| 含 ppt 下载","type":"blog","url":"/sofastack.tech/blog/distributed-architecture-and-cloud-native/","wordcount":5553},{"author":"明不二","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第七篇，本篇作者明不二。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 在前面的文章已经做过介绍，与其他注册中心相比，SOFARegistry 主要特点在于支持海量数据、支持海量客户端、秒级的服务上下线通知以及高可用特性。本文将从如下几个方面来讲述 SOFARegistry 的一致性方案：\n MetaServer 数据一致性 为支持高可用特性，对于 MetaServer 来说，存储了 SOFARegistry 的元数据，为了保障 MetaServer 集群的一致性，其采用了 Raft 协议来进行选举和复制。\n SessionServer 数据一致性 为支持海量客户端的连接，SOFARegistry 在客户端与 DataServer 之间添加了一个 SessionServer 层，客户端与 SessionServer 连接，避免了客户端与 DataServer 之间存在大量连接所导致的连接数过多不可控的问题。客户端通过 SessionServer 与 DataServer 连接的时候，Publisher 数据同时会缓存在 SessionServer 中，此时就需要解决 DataServer 与 SessionServer 之间数据一致性的问题。\n DataServer 数据一致性 为支持海量数据，SOFARegistry 采用了一致性 Hash 来分片存储 Publisher 数据，避免了单个服务器存储全量数据时产生的容量瓶颈问题。而在这个模型中，每个数据分片拥有多个副本，当存储注册数的 DataServer 进行扩容、缩容时，MetaServer 会把这个变更通知到 DataServer 和 SessionServer，数据分片会在集群内部进行数据迁移与同步，此时就出现了 DataServer 内部数据的一致性问题。\nMetaServer 数据一致性 MetaServer 在 SOFARegistry 中，承担着集群元数据管理的角色，用来维护集群成员列表，可以认为是 SOFARegistry 注册中心的注册中心。当 SessionServer 和 DataServer 需要知道集群列表，并且需要扩缩容时，MetaServer 将会提供相应的数据。\n图1 MetaServer 内部结构 图源自 《蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析》\n因为 SOFARegistry 集群节点列表数据并不是很多，因此不需要使用数据分片的方式在 MetaServer 中存储。如图 1 所示，集群节点列表存储在 Repository 中，上面通过 Raft 强一致性协议对外提供节点注册、续约、列表查询等 Bolt 请求，从而保障集群获得的数据是强一致性的。\nRaft 协议 关于 Raft 协议算法，具体可以参考 The Raft Consensus Algorithm 中的解释。在 SOFA 体系中，对于 Raft 协议有 SOFAJRaft 实现。下面对 Raft 协议算法的原理进行简要介绍。\nRaft 协议由三个部分组成，领导人选举（Leader Election）、日志复制（Log Replication）、安全性（Safety）。\n 领导人选举 通过一定的算法选举出领导人，用于接受客户端请求，并且把指令追加到日志中。\n图2 Raft 状态机状态转换图 图源自Understanding the Raft consensus algorithm: an academic article summary\n 日志复制 领导人接受到客户端请求之后，把操作追加到日志中，同时与其他追随者同步消息，最终 Commit 日志，并且把结果返回给客户端。\n图3 复制状态机 图源自 Raft一致性算法笔记\n 安全性 安全性保证了数据的一致性。\n基于 Raft 协议的数据一致性保障 图4 SOFARegistry 中的 Raft 存储过程 图源自 《蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析》\n如图 4 所示，SOFARegistry 中的 Raft 协议数据存储经历了如上的一些流程。客户端发起 Raft 协议调用，进行数据注册、续约、查询等操作时，会通过动态代理实现 ProxyHandler 类进行代理，通过 RaftClient 把数据发送给 RaftServer ，并且通过内部的状态机 Statemachine ，最终实现数据的操作，从而保证了 MetaServer 内部的数据一致性。\nSessionServer 数据一致性 SessionServer 在 SOFARegistry 中，承担着会话管理及连接的功能。同时，Subscriber 需要通过 SessionServer 来订阅 DataServer 的服务数据，Publisher 需要通过 SessionServer 来把服务数据发布到 DataServer 中。\n在这个场景下，SessionServer 作为中间代理层，缓存从 DataServer 中获取的数据成了必然。DataServer 的数据需要通过 SessionServer 推送到 Subscriber 中，触发 SessionServer 推送的场景有两个：一个是 Publisher 到 DataServer 的数据发生变化；另外一个是 Subscriber 有了新增。\n而在实际的场景中，Subscriber 新增的情况更多，在这种场景下，直接把 SessionServer 缓存的数据推送到 Subscriber 中即可，能够大大减轻 SessionServer 从 DataServer 获取数据对 DataServer 的压力。因此，这也进一步确认了在 SessionServer 缓存数据的必要性。\n图5 两种场景的数据推送对比图\nSessionServer 与 DataServer 数据对比机制 当服务 Publisher 上下线或者断连时，相应的数据会通过 SessionServer 注册到 DataServer 中。此时，DataServer 的数据与 SessionServer 会出现短暂的不一致性。为了保障这个数据的一致性，DataServer 与 SessionServer 之间通过 推 和 拉 两种方式实 …","date":1583224200,"description":" 本文为《剖析 | SOFARegistry 框架》第七篇，作者明不二","dir":"blog/sofa-registry-data-consistency/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"356cd2beadad494a22e2d480948fce8d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-data-consistency/","publishdate":"2020-03-03T16:30:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-data-consistency/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心数据一致性方案分析 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-data-consistency/","wordcount":4336},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:BootLab/\u0026amp;gt;是《剖析 | SOFABoot 框架》系列，会逐步详细介绍 SOFABoot 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFABoot SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\nSOFABoot :https://github.com/sofastack/sofa-boot\n| SOFA:Boot Lab 认领列表：\n 【已认领】《SOFABoot 总览》 【已认领】《SOFABoot runtime 机制解析》 【已认领】《SOFABoot HealthCheck 机制解析》 【已认领】《SOFABoot 日志隔离解析》 【已认领】《SOFABoot 上下文隔离机制解析》 领取方式：关注 「金融级分布式架构」 回复可领取的文章标题，我们将会主动联系你，确认资质后，即可加入 SOFA:BootLab/，It\u0026amp;rsquo;s your show time！\n 如果有同学对以上某个主题特别感兴趣的，可以留言讨论，我们会适当根据大家的反馈调整文章的顺序，谢谢大家关注 SOFAStack ，关注 SOFABoot，我们会一直与大家一起成长的。\n除了源码解析，也欢迎提交 issue 和 PR： SOFABoot：https://github.com/sofastack/sofa-boot\n欢迎领取，参与共建~\n","date":1583208000,"description":"","dir":"activities/sofa-boot-lab/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ee08908ed6148190ca7ebcc0cdc5a3fc","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-boot-lab/","publishdate":"2020-03-03T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-boot-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:BootLab/\u0026gt;是《剖析 | SOFABoot 框架》系列，会逐步详细","tags":["SOFALab","SOFABoot","剖析 | SOFABoot 框架"],"title":"\u003cSOFA:BootLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-boot-lab/","wordcount":542},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@朱楠 提问：\n SpringBoot 集成 Seata Saga 模式后启动报了这个错，有谁知道是什么情况吗？不知道问题出在哪，我就参照Saga 的 demo 来配置的。 A：这个事务异常了，然后 server 端出发了事务恢复，但是这条事务在客户端已经没有了。\n @Reference 这个注解没有 id 或者 name 的属性，试了几次还是不行，实在不行我就用配置文件的方式主入 Dubbo 服务了。 A：其实这也合理，因为 @Reference 是作用在一个类的 field 或 method 上面的，而状态机引擎它不是一个 field 或 method，所以状态机引擎不应该用访问这个类的 reference，而是应该访问一个 spring 上下文作用域的 reference 。我看了一下 Dubbo 的源码 @Reference 这种它并不会注册成为一个 bean，只是生成一个代理然后注入到这个引用它的属性里。所以状态机默认是取 bean 的形式拿不到 bean，你用 xml 的方式引用一个服务。状态机的编排本来就不是用 Java 代码上编排的，而 @Reference 是用于编程方式使用的。 Seata：https://github.com/seata/seata\n2、@魏敏 提问：\n 请问一下，关于 tomcat 的 ajp 漏洞，使用的 SOFABoot 是否受影响呢？https://www.cnvd.org.cn/webinfo/show/5415\n A：针对此次 Tomcat 的 AJP 协议漏洞，SOFABoot 内置的 Tomcat 默认是不会打开 AJP Connector 的，也就是说默认情况下所有版本的 SOFABoot 都是安全的。但是如果你自行打开了 AJP Connector，或者认为风险较大，可以通过覆盖 SOFABoot 管控的 Tomcat 版本进行升级，在主 pom 中的 properties section 指定 Tomcat 版本：\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;!-- other properties goes here --\u0026amp;gt; \u0026amp;lt;tomcat.version\u0026amp;gt;9.0.31\u0026amp;lt;/tomcat.version\u0026amp;gt; \u0026amp;lt;!-- Tomcat 升级规则如下： - 9.x 版本升级至 9.0.31 及以上 - 8.x 版本升级至 8.5.51 及以上 - 7.x 版本升级至 7.0.100 及以上 --\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; SOFABoot：https://github.com/sofastack/sofa-boot\n3、@jinn 提问：\n MOSN 与 Envoy 不同点是什么？优势在哪里？\n A：简单描述一下：\n 语言栈的不同：MOSN 使用 Go 语言技能栈对于使用 Java 语言的公司和个人心智成本更低。 核心能力的差异化： MOSN 支持多协议框架，用户可以比较容易的接入私有协议，具有统一的路由框架； 多进程的插件机制，可以通过插件框架很方便的扩展独立 MOSN 进程的插件，做一些其他管理，旁路等的功能模块扩展； 具备中国密码合规的传输层国密算法支持； MOSN：https://github.com/mosn/mosn\nSOFAChannel 线上直播集锦 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.10.0 版本，主要变更如下：\n 分离部分 MOSN 基础库代码到 mosn.io/pkg； 分离部分 MOSN 接口定义到 mosn.io/api； 支持多进程插件模式； 部分代码实现细节优化； Bug Fix； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.10.0\n社区直播预告 SOFAChannel#12 线上直播将邀请蚂蚁金服分布式事务核心开发仁空分享介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1582873200,"description":"【02/24-02/28】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200228/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"825d23ac19f5c5ae4cfaca517a9a87fd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200228/","publishdate":"2020-02-28T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200228/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布、直播系列整理、0312直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200228/","wordcount":1935},{"author":"SOFA 团队","categories":"SOFAArk","content":" SOFA:Channel/，有趣实用的分布式架构频道。\n本文根据 SOFAChannel#11 直播分享整理，主题：从一个例子开始体验轻量级类隔离容器 SOFAArk。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群：23372465，不错过每场直播。\n 大家好，我是玄北，SOFAArk 开源负责人，今天跟大家分享的主题是《从一个例子开始体验轻量级类隔离容器 SOFAArk》，会跟大家一起解读 SOFAArk ，也会讲解一个 Demo 案例，希望大家可以跟我一起实际操作，体验 SOFAArk 具体操作以及功能实现。\nSOFAArk：https://github.com/sofastack/sofa-ark\n今天的分享将从一下面三个方面展开：\n 初识 SOFAArk； 组件运行时； 动手实践； 今天的重点是最后一个部分的动手实践，前面两部分会跟大家简单介绍一下 SOFAArk 的基础概念，希望在最后一个实践部分，大家可以跟着我一起通过 Demo 实际操作体验 SOFAArk，也可以在实践过程中帮助大家更好得了解前面介绍到的概念。\n一、初识 SOFAArk 现在我们就开始了解 SOFAArk，在实践之前，我们先来了解一下什么是 SOFAArk。SOFAArk 是蚂蚁金服开源的一款基于 Java 实现的轻量级类隔离容器，欢迎大家关注并 Star SOFAArk。\nSOFAArk：https://github.com/sofastack/sofa-ark\n在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案。产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin）； 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz)； 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制； 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz； SOFAArk 可以帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\nSOFAArk 中有三个最主要的概念，分别是 Ark 包、Ark Biz 包、Ark Plugin 包：\nArk 包：类似 Spring Boot 的打包产物，是一个 Fat Jar，即应用交付终态，一个 Ark 包，可以通过 Java-jar 的方式把它运行起来。\nArk Biz 包: 简称 Biz，是组件的交付终态，大家通过名字也可以理解，里面主要封装了一些业务逻辑。\nArk Plugin 包: 简称 Plugin，提供把非业务基础组件下沉的能力，比如 RPC、消息等。\n接下来按照上述三个的顺序，我们来看一下这三个包里主要是什么。\nArk 包目录结构 下图是 Ark 包的目录结构，Ark 包下有 Biz 目录，Container 目录，Plugin 目录，Biz 目录中就是一个一个的 Ark Biz，Plugin 目录保存了所有的 Ark Plugin，Container 是 Ark 容器，Ark 容器会负责启动 Ark Plugin 及 Ark Biz。\nArk Biz 包目录格式 介绍完 Ark 包的目录格式，接下来介绍 Ark Biz 包的格式：\n在 Ark Biz 包的目录格式里同样有几个比较关键的目录格式，分别是：\n application.properties：标准 Spring Boot/SOFABoot 工程配置文件； lib 目录：应用依赖目录； META-INF/MANIFEST：Biz 配置文件。 Ark Plugin 包目录结构 接下来跟大家介绍 Ark Plugin 包，Ark Plugin 包的目录结构与 Ark Biz 包的目录结构类似，但是 Ark Plugin 包的 META-INF/MANIFEST.MF 文件会比 Ark Biz 包复杂一点，Ark Plugin 支持在 META-INF/MANIFEST.MF 文件中定义 Import package、Export package、Import classes 以及 Export classes 等属性，这些属性支持 Plugin ClassLoader 在加载类或者资源文件时可以委托给其他 Plugin 加载。\n上文介绍了 Ark 包、Ark Biz 包、Ark Plugin 包的目录结构，接下来我们介绍下 Ark 包运行时的整个运行时结构。通过下面这张图我们可以看到，在整个运行时，Ark 包分为三层，底层是 Ark Container，中间层是 Ark Plugin，上层是 Ark Biz。Ark Container 负责启动所有 Ark Plugin 及 Ark Biz，Ark Plugin 支持类导入导出能力，所以 Ark Plugin 之间有双向箭头相互委托。为了简化 Ark Biz 的使用，Ark Biz 不支持导入导出类，Ark Biz默认会导入所有 Ark Plugin 的类。\nSOFAArk 的不同 Plugin 相互委托类加载的能力可以帮助我们解决一个文件场景，那就是依赖冲突：\n以上图的场景为例，有一个 Project，依赖了 Dependency A 以及 Dependency B，这两个依赖依赖了不同版本的 Hessian，Dependency A 依赖了 Hessian 3，Dependency B 依赖了 Hessian 4，Hessian 3 与 Hessian 4 是不兼容的，会出现冲突，那么要如何解决这个问题呢？\nSOFAArk 就给出了一个解决方案。如果我们的 Dependency A 跟 Dependency B 的 Hessian 依赖有冲突的话，我们可以把 Dependency A 作为一个整体打包成一个 Ark Plugin， Dependency B 作为一个整体打包成一个 Ark Plugin，每个 Ark plugin 都是一个单独的 Classloader，这样 Dependency A 使用的 Hessian 3 和 Dependency B 使用的 Hessian 4 将不再冲突。\n解决依赖冲突是 SOFAArk 的一个主要使用场景，但是今天我们不详细介绍这个场景，今天主要介绍 SOFAArk 的另一个能力，即组件运行时能力。\n二、组件运行时 组件运行时提供了一种能力，它能够在不重启应用的前提下，通过动态安装、卸载、切换 Biz 模块，实现修改应用运行方式的目的。下图展示了组件运行时的运行时结构，整个运行时结构与上文的 Ark 包运行时结 …","date":1582700400,"description":"本文根据 SOFAChannel#11 直播分享整理。","dir":"blog/sofa-channel-11-retrospect/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a3216377eb47b27325f279f124c2bfd8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-11-retrospect/","publishdate":"2020-02-26T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-channel-11-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#11 直播分享整理，主题：从一个例子开始体验轻量级类隔离容器 SOFAArk。 回顾视","tags":["SOFAArk","SOFAChannel"],"title":"从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-11-retrospect/","wordcount":4342},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@朱楠 提问：\n 请教下，我看文档上有说json可以热部署，有demo吗，没怎么看明白如何热部署 A：就是用这个回答里的这个方法 registerByResource，Java 代码的热部署可以用 SOFAArk，stateMachineEngine 是一个 bean，可以在代码里注入这个 bean，然后你可以实现一个 web 页面，可以上传 json 文件和 jar 包，调用图片中的方法注册状态机，用 SOFAArk 注册 jar 包。\n 我在看 registryByResources 这个方法的源码，注册状态机是不是就不需要修改本地的 json 文件了？\n A：注册了 json，如果数据库里有名称相同的，它会对比字节码，如果不一样，则创建新版本，一样则不注册，新启动的状态机实例用新版本，已启动的状态机实例用老的。\n 懂了，你这里说的上传 jar 包是什么意思？\n A：因为状态机里定义了要调用服务，这个服务可能是目前在系统里没有引用，所以需要上传 jar。\n2、@刘川江 提问：\n Seata Saga 模式服务（ServiceTask）之间如何在运行时传递业务参数？如将服务A运行后的生成的业务对象传递到后续的服务中进行处理。\n A：用 Output 和 Input 属性： Input: 调用服务的输入参数列表, 是一个数组, 对应于服务方法的参数列表, $.表示使用表达式从状态机上下文中取参数，表达使用的 SpringEL, 如果是常量直接写值即可； Ouput: 将服务返回的参数赋值到状态机上下文中, 是一个 map 结构，key 为放入到状态机上文时的 key（状态机上下文也是一个 map），value 中$.是表示 SpringEL 表达式，表示从服务的返回参数中取值，#root 表示服务的整个返回参数。\n 是否支持根据业务参数中的某些值作为条件判断状态机中的服务（ServiceTask）是否执行？\n A: 支持的，可以用 Status 属性来判断 Service 是否执行成功。 Status: 服务执行状态映射，框架定义了三个状态，SU 成功、FA 失败、UN 未知, 我们需要把服务执行的状态映射成这三个状态，帮助框架判断整个事务的一致性，是一个 map 结构，key 是条件表达式，一般是取服务的返回值或抛出的异常进行判断，默认是 SpringEL 表达式判断服务返回参数，带 $Exception{ 开头表示判断异常类型。value 是当这个条件表达式成立时则将服务执行状态映射成这个值。\n 是否支持状态机中的部分服务开启事务。如状态机配置了服务流程A-\u0026amp;gt;B-\u0026amp;gt;C，只在服务B和C上开启分布式事务。\n A：可以，比如 A 是一个查询类的服务，可以将 A 设置成 IsForUpdate=false，如果这个服务不想记录执行日志，可以设置这个服务为 IsPersist=false。\nSeata：https://github.com/seata/seata\n3、@SUNBIAO 提问：\n 请问 SOFA 消费者端可以同时配置多个注册中心嘛？例如一个 web 控制器接入端当作消费者，配置连接多个注册中心，订阅不同注册中心上的生产者服务，但是这个消费者端不同的具体消费者调用不同注册中心的服务，前提是注册中心不能合成一个，现实有多个不同的注册中心。\n A：可以的，可以看这个类 com.alipay.sofa.rpc.config.AbstractInterfaceConfig#registry， 是个 list。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n4、@七美 提问：\n SOFATracer 目前落盘的摘要 log 是固定格式的，能否直接以 zipkin 的 json 数据格式落盘？如果可以如何操作？\n A：使用自定义 reporter ： https://www.sofastack.tech/projects/sofa-tracer/reporter-custom/ + ZipkinV2SpanAdapter 来实现。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n每周读者问答提炼 蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 SOFA 项目进展 本周发布详情如下：\n1、发布 Seata v1.1.0 版本，主要变更如下：\n 支持 postgreSQL； 支持自定义 Saga 恢复策略超时时间； 支持 Saga 模式跳过成功分支事务的 report； 支持httpClient 自动集成； 详情发布报告：https://seata.io/zh-cn/blog/download.html\n2、发布 SOFARPC v5.6.4 版本，主要变更如下：\n 试验性支持 RPC 可能的多版本发布； 升级 Dubbo 依赖版本到2.6.7； 优化 gRPC 支持代码； 升级 Netty 版本4.1.44.final，解决安全问题； 修复 Tracer 采样兼容问题； 修复注册中心虚拟端口的问题； 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.4\n3、发布 SOFABoot v3.3.0 版本，主要变更如下：\n 健康检查页面显示组件的具体绑定类型； RPC XML 超时配置支持字符串变量； 修复无法使用 zk 以外注册中心的 bug； 修复控制台大量输出的 bug； 升级 Spring Boot 依赖版本至 2.1.11.RELEASE； 升级 RPC 版本至 5.6.4； 升级 sofa-common-tools 版本至 1.0.21； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.3.0\n4、发布 sofa-common-tools v1.0.21 版本，主要变更如下：\n 修复类隔离情况下 classloader 加载问题； 详 …","date":1582268400,"description":"【02/17-02/23】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200221/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b82b9b4c82bc3905d736962bd157238c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200221/","publishdate":"2020-02-21T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200221/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 3/12直播预告、SOFARPC、SOFABoot 组件发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200221/","wordcount":2625},{"author":"盲僧","categories":"SOFABoot","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFABoot 框架》第二篇，本篇作者盲僧，来自遨游酒店信息技术。《剖析 | SOFABoot 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:BootLab/]()，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFABoot 是蚂蚁金服开源的基于 SpringBoot 的研发框架，提供了诸如 Readiness Check、类隔离、日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\n本文将从 Java 的日志体系谈起，对 JCL、SLF4J 两个经典的日志框架做一个阐述，引出 SOFABoot 开源的日志隔离框架 sofa-common-tools ，并且有实战 Demo，能够帮助我们快速上手和了解这款框架的使用和作用，最后从源码角度对其进行分析，不仅知其然，还要知其所以然。\nSOFABoot ：https://github.com/sofastack/sofa-boot\nsofa-common-tools ：https://github.com/sofastack/sofa-common-tools\nJava 日志问题 业务开发对日志的选择 众所周知，Java 的日志体系非常复杂，有 Log4j、Log4j2、Logback、JUL 等实现，这么多的日志实现让开发人员在选择上不得不犯晕，因为每个日志实现都对外提供了不同的 API，而且还要担心与项目中现有的第三方框架依赖的日志实现产生冲突问题，甚至还要去维护第三方框架带来的日志依赖。在这些问题的基础上，Java 日志框架应运而生，典型的有 JCL 和 SLF4J。\nJCL JCL 即 Apache Commons Logging，它的原理是提供了一套接口，用户使用了它的接口进行编程，具体实现交由它的 LogFactoryImpl 去动态查找， 但是它并不能绑定所有的日志实现，因为查找绑定的日志实现是放在 classesToDiscover 数组里写死的，导致扩展起来比较麻烦，当前最新版本是 1.2 版本，还不支持绑定 Log4j2 和 Logback。\nSLF4J 于是乎，大名鼎鼎的 SLF4J 出现了，它的存在就是为了替换 JCL，所以肯定提供了比 JCL 更强大的功能。同样是面向接口编程的设计，但是 SLF4J 充分考虑到了后期的扩展问题：一旦市面上有新的日志实现，那么只需要提供新的绑定包即可，相对于 JCL 的动态绑定，SLF4J 实际上是静态绑定，因为应用程序具体要选用哪种日志组件是由开发人员使用哪个绑定包决定的。绑定原理请看下图：\n除此之外，SLF4J 还提供了桥接包，它的意思是指可以把使用某个具体 Log 组件的 API 重定向到 SLF4J 的 API 里（前提需要排除具体实现包，然后引入桥接包），然后 SLF4J 会根据具体的绑定包输出内容，从而达到多种日志实现统一输出的目的。绑定原理请看下图：\n中间件对日志的选择 上面解决了业务开发人员的问题，那么对于从事中间件的开发者来说呢？日志依旧是一个痛点。参考一些中间件项目，如 zookeeper 使用的是 log4j ，hibernate-validator 使用的是 jboss-logging，当业务开发人员去集成这些第三方组件时，就会感到头疼，因为这些组件的日志实现很有可能会和当前业务自身的日志依赖产生冲突。常用的解决方法就是排除某一种日志实现依赖，然后修改 appender 和 logger 达到日志隔离。但这并不是一个一劳永逸的方法，因为每次引入新的 jar 包，你都需要考虑是否有日志冲突。\n那么市面上是否有成熟的框架来解决这个问题呢？当然是有的，蚂蚁金服开源的 SOFABoot 就提供了这样的功能，底层主要是通过 sofa-common-tools 实现的。那么 sofa-common-tools 又是个啥呢？借用官网的描述： sofa-common-tools 是 SOFAStack 中间件依赖的一个通用工具包，通过自动感知应用的日志实现，提供中间件与应用隔离的日志空间打印能力。\n本篇将通过一个案例 demo 先来直观的体验下 sofa-common-tools 所能解决的问题，然后再在此基础上，通过源码解析了解其内部的具体实现原理，以帮助大家更好的认识和了解 sofa-common-tools 这个“小而美”的日志工具包。\n日志隔离实战 完整项目已经上传到 https://github.com/masteryourself/study-sofa.git ，工程是 study-sofa-common-tools\n 有这样一个场景：公司的中间件团队做了一款 middleware-apm 监控系统，并且通过以输出日志的方式向监控系统提供基础数据。由于公司并没有制定统一的日志规范，各个业务方所使用的日志也是千差万别；如：如订单系统使用的是 log4j，账务系统用的 Logback，用户中心用的是 Log4j2； 如果期望 apm 提供的日志输出和业务的不冲突，可以独立的并且完整的兼容业务日志的不同实现，此时便可以使用 SOFABoot 提供的日志隔离框架；其可以帮助我们解决日志实现冲突、日志文件隔离以及动态调试日志级别等功能。下面就先来看下 apm 是如何使用 sofa-commons-tools 来实现的。\nmiddleware-apm 项目 新建 middleware-apm 工程，然后执行 mvn clean install 命令，安装到本地仓库。具体代码可以参考 middleware-apm ，下面对一些核心代码进行简单的说明和分析。代码结构如下：\n日志资源文件配置 这里主要是在 pers.masteryourself.study.sofa.apm.log 目录下创建 log4j、log4j2、logback 的配置文件，详情请参考 github 链接。\n核心日志工厂类-ApmLoggerFactory ApmLoggerFactory 主要是对外提供获取 Logger 实例的 API 方法，其作用类似于 slf4j 中的 LoggerFactory 类；对于想使用 SOFABoot 日志特性的类，只要使用它调用 getLogger 方法获得的 Logger 实例即可。\nLoggerFactory 和 ApmLoggerFactory 的最本质区别在于 ApmLoggerFactory 引入了 LOG_SPACE 的概念。\npublic class ApmLoggerFactory { // 日志空间 private static final String APM_LOG_SPACE = \u0026amp;quot;pers.masteryourself.study.sofa.apm\u0026amp;quot;; static { if …","date":1582016400,"description":"本文将从 Java 的日志体系谈起，对 JCL、SLF4J 两个经典的日志框架做一个阐述，引出 SOFABoot 开源的日志隔离框架 sofa-common-tools，并且有实战 Demo，能够帮助我们快速上手和了解这款框架的使用和作用，最后从源码角度对其进行分析，不仅知其然，还要知其所以然。","dir":"blog/sofa-boot- log-isolation/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a428e36a94180c1e33920579423b4402","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-log-isolation/","publishdate":"2020-02-18T17:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-boot-log-isolation/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFABoot","剖析 | SOFABoot 框架","SOFALab"],"title":"蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-log-isolation/","wordcount":4632},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@乘疯破浪 提问：\n 咨询一个性能问题，一个 2C 的业务场景：本地库操作多次 db，再调用分布式服务，再 TC 端注册多个分支事务耗时较多，用户 C 端等待时间较长，这种问题有处理方案吗？client 已设置 report 分支状态 =false。\n A：确实比较长，个人建议从架构入手去改良，可以通过存入 redis 等一个消息，告诉用户正在插入-\u0026amp;gt;然后一步出力业务，出现异常同样 redis 里的信息改为异常。如果成功就为成功存储 id 或者其它看业务具体情况,然后用户端页面做个倒计时，或者转圈圈，或者直接告诉他正在插入稍等。比如以前用 MQ 削峰就差不多是这个思路吧。长事务尝试用用 Saga、AT 上手快，但是因为锁的存在，效率比较低，后续会逐步优化，性能高入侵也高的 TCC 如果能尝试也可以试试。\n2、@孟昊 提问：\n 请问一下，我今天看了一下文档，好像 cloud 通过 feign 调用方式只能使用 AT 模式, 在并发量比较高的场景下会有问题么(小事务)。\n A：微服务框架跟分布式事务模式没有绑定，还可以用 TCC、Saga。Saga 目前理论上支持所有 RPC 框架，只要是个 bean 即可。\n3、@小孟 提问：\n MOSN 是否支持了 Dubbo 协议？\n A：MOSN 在本周已通过 x-protocol 支持了 Dubbo 和 Tars 协议，具体可见： https://github.com/mosn/mosn/pull/950\n4、关于线上直播 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk 提问回答\n直播视频回顾：https://tech.antfin.com/community/live/1096\n@鸿关 提问：\n 用 SOFAArk 的话，能直接集成到 SOFABoot 工程不？还是说必须要建个 SOFAArk 的工程？SOFAArk 可以运用于非 SOFABoot 的项目么？\n A： 能直接继承到 SOFABoot 工程，不需要新建 SOFAArk 工程，也可以用于非 SOFABoot 工程，只要是 Spring Boot 工程即可，但是不引入 SOFA 相关依赖的话，@SofaService 及 @SofaReference 等注解就没法用了。\n@盲僧 提问：\n 运行期间安装 biz，然后激活模块这一过程做了哪些事情 ，如果这个 biz jar 包放在远程仓库怎么加载里面的代码呢？是拉下来放到本地的一个磁盘用 classloader 去加载使用吗？\n A：安装和激活是的两个操作，安装支持两种协议获取 biz 包：http 和 file，激活只是在内部调整了同 biz 不同版本的状态。\n 运行期间安装 biz 后，那个 execute jar 包里会有这个 biz 包吗？ A：可以尝试用插件打个包出来解压看下哦。\n @曾鹏 提问：\n SOFAArk 有什么实际的应用场景吗？\nA：可以看下这个：蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析\n SOFAArk：https://github.com/sofastack/sofa-ark\n本周推荐阅读 SOFAStack Community | 欢迎加入 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFATracer v2.4.5\u0026amp;frasl;3.0.9 版本，主要变更如下：\ni. 默认禁用上报数据到zipkin, 需要显式设置 com.alipay.sofa.tracer.zipkin.enabled=true 才能开启； 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.5 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.9\n2、发布 SOFATracer v2.4.6v/v3.0.10 版本，主要变更如下：\ni. 支持使用 JVM系统属性 或 环境变量 SOFA_TRACER_LOGGING_PATH 来定制 tracelog 的路径 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.6 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.10\n社区直播预告 本期为 SOFAChannel 线上直播第 12 期，将邀请蚂蚁金服分布式事务核心开发仁空分享《蚂蚁金服分布式事务实践解析》。\n软件开发模式从原来的单应用，到现在的微服务、分布式架构，一个大型分布式系统内，单业务链路往往需要编排多个不同的微服务，如何实现分布式场景下业务一致性，是摆在软件工程师面前的一个技术难题。\n本期分享将介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1581667200,"description":"【02/10-02/14】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200214/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3deaf12dd1b6589f41c57291d9061534","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200214/","publishdate":"2020-02-14T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200214/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 2/13直播回顾、3/12直播预告、SOFATracer 发版","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200214/","wordcount":1781},{"author":"SOFA 团队","categories":"Service Mesh","content":" 2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。\n参与问卷调查的人员情况 共收集到 516 份问卷结果，问卷填写者 94.2% 来自 ServiceMesher 社区，21.7% 的人参与过社区线上活动，27.5% 的人参与过社区 meetup，86.6% 看好 Service Mesh 的未来发展前景。\n下面是参与问卷调查人员的基本情况。\n公司所属行业\n所在公司的 Service Mesh 使用情况\n工作年限\n在公司中担任的职务\n关注 Service Mesh 技术的时长\n周围关注或了解 Service Mesh 技术的人员情况\n学习 Service Mesh 技术的方式\n关注的 Service Mesh 相关开源项目\n除了 Service Mesh 外关注的其他云原生领域\n对 Service Mesh 的了解程度\n关注 Service Mesh 技术中的哪部分\n社区参与 了解社区活动的情况\n对社区的建议\n还有很多对社区的建议，反馈比较多的如下：\n 更多落地实践和指南 发布一些入门级的文章，结合案例，让技术在中小企业中落地 组织一些线上或线下活动 对普通开发者的职业发展的建议 出系列教程 结论 从结果中可以看出，Service Mesh 在互联网公司中关注的比例最高，但是它仍然还在高速发展中，还缺乏完善的教程和案例。\n本次问卷调查旨在了解 ServiceMesher 社区成员对 Service Mesh 的了解及社区参与程度，帮助 ServiceMesher 社区做的更好，还需要社区成员们共同的努力。\n欢迎关注 Service Mesh 技术的小伙伴们加入 ServiceMesher 社区，共同交流学习和成长。\n关于本次调查问卷的最终解释权归 ServiceMesher 社区所有。\n","date":1581667200,"description":"2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。","dir":"blog/service-mesh-end-user-survey-report/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e2f1dc19ca9ab916db565bdd2bd5a50f","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-end-user-survey-report/","publishdate":"2020-02-14T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/service-mesh-end-user-survey-report/","summary":"2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。 参与问卷调查的人员情况 共收集到 516 份问卷结","tags":["Service Mesh"],"title":"Service Mesh 终端用户调查报告","type":"blog","url":"/sofastack.tech/blog/service-mesh-end-user-survey-report/","wordcount":530},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n 活动时间：3 月 12 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#12：蚂蚁金服分布式事务实践解析 软件开发模式从原来的单应用，到现在的微服务、分布式架构，一个大型分布式系统内，单业务链路往往需要编排多个不同的微服务，如何实现分布式场景下业务一致性，是摆在软件工程师面前的一个技术难题。\n蚂蚁金服作为一家金融科技公司，业务涉及金融核心的各个领域，从2007年开始就自主研发了分布式事务框架，解决跨数据库、跨服务的业务一致性问题；随着13来年的不断打磨和沉淀，历经双十一、双十二等大促的洗礼，如今所有核心业务都已经在使用这套框架来保障交易的完整性和最终一致性，做到知托付，让用户放心。\n本期分享将介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n本期为 SOFAChannel 线上直播第 12 期，将邀请蚂蚁金服分布式事务核心开发仁空分享《蚂蚁金服分布式事务实践解析》。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1096\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 仁空，蚂蚁金服分布式事务核心开发\n本期分享大纲 分布式事务产生的背景； 蚂蚁金服分布式事务理论与实践； TCC 模式 FMT 模式 蚂蚁金服分布式事务极致性能提升； 蚂蚁金服分布式事务开源与展望； 嘉宾 SOFAGirl 主持人 仁空，蚂蚁金服分布式事务核心开发 ","date":1581498000,"description":"3 月 12 日周四晚 7 点，线上直播第 12 期。","dir":"activities/sofa-channel-12/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c80a24fd4e76747f0ed57c139a2bfae9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-12/","publishdate":"2020-02-12T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-12/","summary":"概要 活动主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析 活动时间：3 月 12 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍 | SOFAChannel","tags":["SOFAChannel","分布式事务"],"title":"SOFAChannel#12：蚂蚁金服分布式事务实践解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-12/","wordcount":784},{"author":"纶珥","categories":"SOFALab","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFABoot 框架》第一篇，本篇作者纶珥，来自蚂蚁金服。《剖析 | SOFABoot 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:BootLab/]()，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFABoot 是蚂蚁金服开源的基于 SpringBoot 的研发框架，提供了诸如 Readiness Check、类隔离、日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\nSpringBoot 基于 Spring 的按条件配置（Conditional Configuration），结合 starter 依赖机制提供了快捷、方便开发 Spring 项目的体验，获得了极大的成功；SOFABoot 同样在这两个能力上基于 SpringBoot 扩展出适应于金融级应用开发框架。作为脱胎于蚂蚁金服内部对于 SpringBoot 的实践，SOFABoot 补充了 SpringBoot 在大规模金融级生产场景下一些不足的地方，例如 Readiness 检查、类隔离和日志空间隔离等等能力。在增强了 SpringBoot 的同时，SOFABoot 还提供了让用户可以在 SpringBoot 中非常方便地使用 SOFAStack 中间件的能力。\nSOFABoot ：https://github.com/sofastack/sofa-boot\n功能点概览 SOFABoot 完全兼容 SpringBoot，SpringBoot 技术栈可以快速切换到 SOFABoot 技术栈：修改项目 pom 依赖的 \u0026amp;lt;parent/\u0026amp;gt; 节点，例如将：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 当前 SOFABoot 的最新版本为 v3.2.2。\n应用 Readiness 检查 一个应用启动之后，是否是“准备”好能够处理外部请求呢？作为应用流量入口的组件是否可以接收外部连接？这就很有必要引入应用 Readiness 的检查，SOFABoot 提供除 SpringBoot 健康检查之外的应用 Readiness 检查能力，保证应用组件的正常启动、应用安全上线。\nSOFABoot 通过 HealthChecker 检查各组件的 ready 情况。在 Spring 上下文刷新完成之后（所有的 Spring Bean 已经实例化完成），SOFABoot 会获取 IoC 容器中所有的 HealthChecker 实现类，检查其返回的组件健康状况；在应用开启了模块化隔离之后，模块 HealthChecker 还会 kicks in，检查模块的健康状况。Spring 原生的 HealthIndicator 作为 Readiness 的一部分也会纳入 Readiness 的结果中，若 HealthIndicator 出现了失败的情况，那么应用的 Readiness 也是不通过。\nReadiness 检查包含组件的后置检查，流量入口组件（例如：RPC、REST）需要保证后置检查通过之后能接受外部流量的请求，应用才是真正 ready 了。\n应用 Readiness 与 Liveliness 不同的是 Readiness 表示的是应用启动完成之后是否“准备”好的状态，启动完成之后是不变的；两次部署间的 Readiness 的所有请求结果是一致的。\n应用模块化 应用模块化的方案多种多样。传统方案是以应用功能为边界做模块划分；研发期间，不同职责的类放在不同的模块下，但在运行期间都在同一个 classpath 下，没有任何隔离。而与传统的模块划分方案不同，人们发现可以利用 Java 的 ClassLoader 机制，将模块与模块间的类完全隔离；当某个模块需要与另一个模块通信时，可以通过类的导入和导出来实现。OSGi 和 SOFAArk 都是基于 ClassLoader 隔离的模块化实践方案。\n传统的模块化方案没有任何的隔离手段，模块间的边界得不到保障，容易出现模块间的紧耦合；而基于 ClassLoader 的模块化方案则过于彻底，研发人员必须十分清楚类的导入与导出、Java 的类加载体系，模块划分的负担转嫁到了普通研发人员身上。\nSOFABoot 综合以上两种方案的利弊，引入了介于两者之间的模块化方案：每个模块有独立的 Spring 上下文，通过上下文的隔离，让不同模块之间的 Bean 的引用无法直接进行，达到模块在运行时的隔离。这样既保证了不引入过多的复杂性，也避免了没有任何隔离措施的模块边界保障。如下图所示：\n所有的 SOFABoot 模块都会有一个相同的 Spring Context 的 Parent，称之为 Root Application Context。对于所有模块都需要引入的 Bean，可以选择将其放置于 Root Application Context 中，在所有的模块间共享。此外，SOFABoot 框架提供两种 Spring 上下文隔离方案后的模块间通信能力：\n JVM 服务的发布和引用：同一个应用内不同模块间的通信 // Publish a JVM service @Component @SofaService public class MyServiceImpl implements MyService { // implementation goes here } // Reference a JVM service public class AnyClass { @SofaReference private MyService myService; } RPC 服务的发布和引用：不同应用间的通信 // Publish a RPC service @Component @SofaService(interfaceType = MyService.class, bindings = { …","date":1581321600,"description":"本文为《剖析 | SOFABoot 框架》第一篇，主要介绍 SOFABoot 的基础特效。","dir":"blog/sofa-boot-overview/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d1a5fa7654f26a159c65061d4f7712d7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-overview/","publishdate":"2020-02-10T16:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-boot-overview/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFALab","剖析 | SOFABoot 框架","SOFABoot"],"title":"蚂蚁金服研发框架总览 | SOFABoot 框架剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-overview/","wordcount":3219},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@张一心 提问：\n 建议 Seata 全局加锁时候支持快速抢占机制，在不同重要程度事务处理中优先满足重要业务的加锁处理以优先保证紧急重要逻辑的处理，实现方式有多种的，可以根据情况直接回滚干掉非紧急事务也可以在等待加锁队列中做插队处理。\n A：不是通用场景，这个不是通过 API 来实现，后续添加控制台后，在控制台页面对活动事务可以进行控制，可单个事务降级或 redo。\n 之前我是通过改造其值来源于 Nacos 配置的全局事务注解完成的，有了单独事务控制台能起到各司其职更好，既然后续补充了控制台，是不是事务处理的各类统计也能在控制台上面看得到，作为一系列资源分配的参考指标。\n A：控制台主要包括监控统计和事务控制介入，你说的应该是动态降级，这个是全局的，细化不到刚才说的那种抢占机制比如手动在控制台的具体某个事务进行降级释放锁，直接通过 API 这个数据破坏性无法控制，对于这种需要人工去介入并且有 trace。\n 实际生产中涉及金钱交易的优先级往往高于非金钱交易的优先级。破坏性来源主要是加锁中的破坏性回滚，实际业务中往往会存在不能锁刚好被加在队列中等待一阵的现象，这时候完全可以根据全局标记做全局性插队，在处理中加快相关业务处理。监控粒度不应该忽视锁的名称，全局业务的加锁顺序和持有时间，不然当业务量大且相互交叉发生全局性死锁也是会存在的。确切说是业务量大并且分布在不同 TC 上加锁情况下可能会产生哲学家就餐问题带来的死锁。\n A：这里不存在死锁，先拿的是数据库的 X 锁，在拿的是全局锁，你可以举个栗子。一种优先级是处理前优先级类似于 mq 的优先级队列，这种是哪个事务优先被处理，这种是需要兼顾顺序和锁优先级排序，高优先级事务分支优先被处理。 一种是处理中的锁被剥夺，这种是破坏性的，如果在一个不重要的事务中分支1执行完成，另外一个重要事务请求分支1同样的锁，这个锁这时可被剥夺，不重要事务释放锁降级非分布式事务。大多数冲突的情况应该属于处理中而不是处理前。\n 根据测试经验，量小的时候会等，量大的时候会直接碰撞，量进一步加大则除了碰撞而且跑队列里一起挤挤的概率就会飙上去。这时候会遇到几个难点，1队列下是不是插队（这个通过认为设置比较好解决）2抢占是否必要，这时候需要通过对之前加锁的统计（包括业务处理时间与网络通信等综合指标）和潜在破坏性做评估，如果破坏性较小或无且不抢占下对业务预等待时间较长且其他回滚表较为独立则直接回滚抢占，最典型场景就是扣钱的时候充值，或者出货的时候补货。\n A：第2中的破坏性来源于不重要事务锁被剥夺降级为非分布式事务，但是由于后续事务分支出现异常，会导致这个事务分支无法参与回滚，若参与回滚必会导致重要事务全局回滚时数据校验不通过而无法回滚。\n 对，校验不通过关键在于目前采用的是全量型业务，而不是基于对 sql 语句解析之后的增量型业务（即 TCC 的 cancel 步骤里反向对冲）。\n A：对于 AT 模式都是基于数据的不是基于 sql 的，与 binlog 同步方式类型同理。\n 下面问题来了，数据破坏是因为先去 TC 报道还是先去数据库加锁造成的。如果先去 TC 报道，等报道成功再去 DB 加锁就不会发生数据破坏的问题，因为报道失败就直接返回了不会对 DB 造成影响。\n A：那个锁的范围更大些，肯定是 DB 的 X 锁。服务是操作 DB 的，如果连 DB 锁拿不到，拿全局锁有什么意义，假设先拿全局锁，数据库锁拿不到时是不是又需要 RPC 去释放全局锁？\n 不知道有没必要添加对全局读写锁的支持，这个个人未实践过，纯属个人观点，也不知道现在是否已经实现了？\n A：这个说的是类似 JUC 的读写锁嘛？如果单纯这样没什么实际意义，现在是类似数据库 select for update 的 X 锁上升到全局锁。\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.9.0 版本，主要变更如下：\n 引入嵌入模式； 升级 SGX SDK 依赖到最新版； 大幅提升网络 I/O 的性能； 正式支持 Python 语言的应用； 正式支持 Ubuntu 18.04 和 CentOS 7.2； 修复了多个 bug； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.9.0\n社区直播预告 春节后直播预告来啦～本期为 SOFAChannel 线上直播第 11 期，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n时间：2020年2月13日（周四）19:00-20:00\n嘉宾：玄北，蚂蚁金服技术专家 SOFAArk 开源负责人\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1581066000,"description":"【02/03 - 02/07】 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200207/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4e10f9b05976b3f0f8ce4d9128fa8d79","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200207/","publishdate":"2020-02-07T17:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200207/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 落地系列文章、2/13直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200207/","wordcount":2288},{"author":"柑橘、西经、柏翘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，该系列从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n前言 Service Mesh 在蚂蚁金服内部已经大规模落地，经历刚刚双十一的检阅，将现有的体系快速演进至 Service Mesh 架构，无异于给飞机换发动机。本主题主要分享在蚂蚁金服当前的体量下，我们如何做到给飞机换发动机，还确保不出问题。同时在 Mesh 对外客户输出同样有高质量的保障。\n本文结合蚂蚁金服 Mesh 化落地质量保障落地的思考，给大家带来如下三个方面的一些质量保障的分享：\n Mesh 化质量保障体系； Mesh 化测试技术； Mesh 化双十一大规模落地的性能保障； 质量保障体系 首先给大家介绍下我们的质量保障体系。\n测试保障体系\n我们从测试环境、测试用例、基础功能测试原子镜像能力、测试工具平台、测试场景组合调度、测试方案制定、线上巡检监控、灰度发布三板斧、交付验证、性能、自动化测试等多个方面进行系统性测试保障。通过内外部的质量数据度量和双十一大促来检阅我们的质量能力。\nMesh 测试技术 在开始介绍测试技术之前，我们先了解一下什么是 Service Mesh 以及 Service Mesh 是如何工作的，在蚂蚁金服的技术架构中是以什么形式存在，发挥着怎样的作用。\n简单的说 Service Mesh 存在两个面，一个面叫数据面（比如 MOSN），就是处理应用数据请求的一个独立代理模块，脱离于应用，为应用提供请求代理及一些复杂通信逻辑处理，另外一个叫控制面（比如 SOFAMesh），管理应用配置及业务规则等（比如业务开关/服务路由规则），通过下发配置“指挥”数据面去执行，满足不同阶段实现不同的业务支持。\nMesh 框架简图\n我们先简单介绍下经典微服务请求路由。\n经典微服务模式请求路由\n经典微服务模式下 Docker 镜像化服务在一个 Pod 一般只有一个业务应用容器在运行，这种情况下测试框架只要关心业务应用即可。\n经典微服务测试架构\nMesh 测试架构改进 Mesh 测试架构在经典微服务测试架构上也做了新的演进。MOSN 作为 Sidecar 与业务容器共存在一个 Pod，资源与业务应用容器共享，每个业务逻辑都需要通过 MOSN 去处理，因而只关心业务应用肯定不够，需要再扩展支持到 MOSN 这类 Sidecar 的测试验证。在 MOSN 中集成了控制面 xds client，与控制面 pilot 建立通信，用于接收 pilot 下发的配置信息。在蚂蚁金服技术架构存在三地五中心/同城双活等容灾能力，因而产生了 LDC，一个集群多个 zone 情况，控制面 pilot下发是可以配置集群+zone+应用+ip 组合粒度，要验证这个多 zone 下发规则准确性，那就需要创建多个 xds client（或者 MOSN）。另外 Sidecar 是不能直接访问的，通过测试应用暴露出接口，给上层测试。\nMesh 化测试架构\n构建高仿真测试环境 那么，我们测试环境要做到足够仿真，面临哪些挑战呢？首先看下我们自研的 MOSN 具备的能力和技术复杂性。\n MOSN 能力大图\n应对 MOSN 测试场景复杂性，我们搭建了一套高仿真测试环境，这里以 MOSN 中的 RPC 功能为例，阐述这套环境的构成要素及环境部署架构。\n集成测试环境构成要素\n这里可以举一个 RPC 路由的例子来详细讲述。我们知道，业务在做跨 IDC 路由时，主要通过跨域 VIP 实现，这就需要业务在自己的代码中设置 VIP 地址，例如：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.APPNAME.facade.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleRpcService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.tr\u0026amp;gt; \u0026amp;lt;sofa:vip url=\u0026amp;quot;APPNAME-pool.zone.alipay.net:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.tr\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 这时候假如业务配置了不合法的 URL，如：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.APPNAME.facade.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleRpcService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.tr\u0026amp;gt; \u0026amp;lt;sofa:vip url=\u0026amp;quot;http://APPNAME-pool.zone.alipay.net:12200?_TIMEOUT=3000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.tr\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上述 VIP URL 指定了 12200 端口，却又同时指定了 http，这种配置是不合法的，就会出现问题，这时候测试环境就需要跨 zone、跨 LDC 的测试环境。我们在多数复杂产品测试里都会遇到，极度复杂测试场景无法 100% 分析充分。一般对于这种场景，我们可以借助于线上流量回放的能力，将线上的真实流量复制到线下，作为我们测试场景的补充。这也需要非常仿真的测试环境做 MOSN 的流量回放支撑。\n兼容性测试 MOSN 兼容性验证\n我们通过一个例子来详细阐述：老版本的 RPC 中我们支持 TR 协议，后续的新版支持 BOLT 协议，应用升级过程中，存在同时提供 TR 协议和 BOLT 协议服务的情况，如下图：\n应用升级过程中，相同接口提供不同协议的服务\n首先，应用向 MOSN 发布服务订阅的请求，MOSN 向配置中心订阅，配置中心返回给 MOSN 两个地址，分别支持 TR 和 BOLT，MOSN 从两个地址中选出一个返回给应用 APP。\n这里兼容性风险是：MOSN 返回给 APP 的地址是直接取配置中心返回的第一条数据，这里可能是 TR 也可能是 BOLT。\n如果 MOSN 返回给应用的地址是支持 BOLT 协议的服务端，那么后续应用发起服调用时，会直接以 BOLT 协议请求 MOSN，MOSN 选址时，会以轮询的方式两个服务提供方，如果调用到 Server1，就会出现协议不支持的报错。 因此我们针对各种兼容性具体场景都要做好分析和相应的测试。\nMOSN 的鲁棒测试（稳定性、健壮性） 从 MOSN 的视角来看，其外部依赖如下：\nMOSN 外部依赖图\n除了验证 MOSN 自身的功能外，我们还通过故障注入的方式，对 MOSN 的外部依赖做了专项测试。通过这种方式，我们发现了一些上述功能测试未覆盖的场景，这里以应用和 MOSN 之间的 12199 端口举例。\n应用 APP 接入 MOSN 后，原先应用对外提供的 12200 端口改由 MOSN 去监听，应用的端口修改为 12199，MOSN 会向应用的 12199 端口发送心跳，检测应用是否存活。\n如果应 …","date":1579514400,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，结合蚂蚁金服 Mesh 化落地质量保障落地的思考，给大家带来一些质量保障的分享。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8dfd6e1dabd16bc85d9876ce9764e3ab","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","publishdate":"2020-01-20T18:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，该系列从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","wordcount":3163},{"author":"嘉祁","categories":"Service mesh","content":" 本文根据蚂蚁金服中间件 SRE技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。\n背景 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。而在具体部署上，保守的做法是以独立进程的方式与业务进程共同存在于业务容器内。蚂蚁金服的做法是从开始就选择了拥抱云原生。\n大规模落地的过程中，我们在看到 Service Mesh 带来的巨大红利的同时，也面临过很多的挑战。为此，蚂蚁金服配备了“豪华”的技术团队阵容，除了熟悉的 SOFA 中间件团队，还有安全、无线网关以及专门配备了专属的 SRE 团队，使得 MOSN 能力更加全面更加可靠。\n今天我们详细聊聊技术风险这个方面。对于一个新的中间件技术，在落地过程中总会面临稳定性、运维模式变化等等很多的问题与挑战，需要建设相应的技术风险能力，确保整个落地过程以及长期运行的稳定和可靠。\n本次分享主要从以下三个方面展开：\n 落地过程中对于部署模式和资源分配的思考； 变更包括接入、升级的支持、问题与思考； 整个生产生命周期中稳定性面临的挑战与技术风险保障； Sidecar 部署模式 业务容器内独立进程的好处在于与传统的部署模式兼容，易于快速上线；但独立进程强侵入业务容器，对于镜像化的容器更难于管理。而云原生化，则可以将 Service Mesh 本身的运维与业务容器解耦开来，实现中间件运维能力的下沉。在业务镜像内，仅仅保留长期稳定的 Service Mesh 相关 JVM 参数，从而仅通过少量环境变量完成与 Service Mesh 的联结。同时考虑到面向容器的运维模式的演进，接入 Service Mesh 还同时要求业务完成镜像化，为进一步的云原生演进打下基础。\n 优 劣 独立进程 兼容传统的部署模式；改造成本低；快速上线 侵入业务容器； 镜像化难于运维 Sidecar 面向终态；运维解耦 依赖 K8s 基础设施；运维环境改造成本高；应用需要镜像化改造 在接入 Service Mesh 之后，一个典型的 POD 结构可能包含多个 Sidecar：\n MOSN：RPC Mesh, MSG Mesh, \u0026amp;hellip;（扩展中）； 其它 Sidecar； MOSN：https://github.com/mosn/mosn\n这些 Sidecar 容器与业务容器共享相同的网络 Namespace，使得业务进程可以以本地端口访问 Service Mesh 提供的服务，保证了与保守做法一致的体验。\n基础设施云原生支撑 我们也在基础设施层面同步推进了面向云原生的改造，以支撑 Service Mesh 的落地。\n运维平台模型支撑 首先是运维平台需要能够理解 Sidecar，支撑 Sidecar 模型的新增元数据，包括基于 POD 的 Sidecar 的多种标签，以及 Sidecar 基线配置的支持。\n业务全面镜像化 其次我们在蚂蚁金服内部推进了全面的镜像化，我们完成了内部核心应用的全量容器的镜像化改造。改造点包括：\n 基础镜像层面增加对于 Service Mesh 的环境变量支撑； 应用 Dockerfile 对于 Service Mesh 的适配； 推进解决了存量前后端分离管理的静态文件的镜像化改造； 推进了大量使用前端区块分发的应用进行了推改拉的改造； 大批量的 VM 模式的容器升级与替换； 容器 POD 化 除了业务镜像层面的改造，Sidecar 模式还需要业务容器全部跑在 POD 上，来适应多容器共享网络。由于直接升级的开发和试错成本很高，我们最终选择将接入 Service Mesh 的 数百个应用的数万个非 K8s 容器，通过大规模扩缩容的方式，全部更换成了 K8s PODs。\n经过这两轮改造，我们在基础设施层面同步完成了面向云原生的改造。\n资源的演进 Sidecar 模式的带来一个重要的问题，如何分配资源。\n理想比例的假设独占资源模型 最初的资源设计基于内存无法超卖的现实。我们做了一个假设：\n MOSN 的基本资源占用与业务选择的规格同比例这一假设。 CPU 和 Memory 申请与业务容器相应比例的额外资源。这一比例最后设定在了 CPU 1/4，Memory 1/16。\n此时一个典型 Pod 的资源分配如下图示：\n独占资源模型的问题 这一方式带来了两个问题：\n 蚂蚁金服已经实现了业务资源的 Quota 管控，但 Sidecar 并不在业务容器内，Service Mesh 容器成为了一个资源泄漏点； 业务很多样，部分高流量应用的 Service Mesh 容器出现了严重的内存不足和 OOM 情况； 共享资源模型 讨论之后，我们追加了一个假设：\n Service Mesh 容器占用的资源实质是在接入 Service Mesh 之前业务已使用的资源。接入 Service Mesh 的过程，同时也是一次资源置换。 基于这个假设，推进了调度层面支持 POD 内的资源超卖，新的资源分配方案如下图，Service Mesh 容器的 CPU、MEM 都从 POD 中超卖出来，业务容器内仍然可以看到全部的资源。\n考虑到内存超卖也引入了 POD OOM 的风险，因此对于 Sidecar 容器还调整了 OOM Score，保证在内存不足时，Service Mesh 进程能够发挥启动比 Java 业务进程更快的优势，降低影响。\n新的分配方案解决了同时解决了以上两个问题，并且平稳支持了蚂蚁金服的双十一大促。\n变更-Service Mesh 是如何在蚂蚁金服内部做变更的 Service Mesh 的变更包括了接入与升级，所有变更底层都是由 Operator 组件来接受上层写入到 POD annotation 上的标识，对相应 POD Spec 进行修改来完成，这是典型的云原生的方式。\n接入-从无至有 标准的云原生的接入方式，是在创建时通过 sidecar-operator webhook 注入一个 Sidecar 容器。\n这个方式的固有缺陷在于：\n 滚动替换过程需要 Buffer 资源； 过程缓慢； 回滚慢，应急时间长； 原地接入 原地接入是为了支撑大规模的快速接入与回滚，通过在存量的 POD 上操作修改 POD Spec。\n尽管看起来不太云原生，但期望能绕过以上几个痛点，从而可以：\n 不需要重新分配资源； 可原地回滚； 升级 Service Mesh 是深度参与业务流量的，最初的 Sidecar 的升级方式也需要业务伴随重启。\n带流量的平滑升级 为了规避 Java 应用重启带来的重新预热等问题，MOSN 提供了更为灵活的平滑升级机制：由 Operator 控制启动第二个 MOSN Sidecar，完成连接迁移，再退出旧的 Sidecar。整个过程业务可以做到流量不中断，几近无感。\n变更能力的取舍 虽然提供了原地接入与平滑升级，但从实践的效果来看，对存量 POD spec 的修改带来的问题，比收益要多得多。\n 创建时注入/普通升级 原地注入/平滑升级 不改变现存 POD spec 改变现存 POD 资源预分配，不影响调度； 逻辑简单，成功率高；与原有业务升级逻辑一致； …","date":1579514400,"description":" 本文根据蚂蚁金服中间件 SRE 技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。","dir":"blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7e1941c7099e109de92394b49df59a2b","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","publishdate":"2020-01-20T18:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","summary":"本文根据蚂蚁金服中间件 SRE技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。 背景 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。","tags":["Service mesh","Service Mesh Meetup"],"title":"蚂蚁金服 Service Mesh 技术风险思考和实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","wordcount":4057},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n 活动时间：2 月 13 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本期为 SOFAChannel 线上直播第 11 期，将邀请 SOFAArk 开源负责人玄北和大家一起解读 SOFAArk ，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk：https://github.com/sofastack/sofa-ark\n你将收获：\n 快速认识轻量级类隔离容器 SOFAArk； Demo 案例实操，了解如何使用 SOFAArk 实现类隔离； SOFAArk 完整功能详解； | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1096\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 从一个例子开始体验轻量级类隔离容器 SOFAArk 玄北，蚂蚁金服技术专家 、SOFAArk 开源负责人\n本期分享大纲： 快速认识轻量级类隔离容器 SOFAArk； Demo 案例实操，了解如何使用 SOFAArk 实现类隔离； SOFAArk 完整功能详解； 嘉宾 SOFAGirl 主持人 玄北，蚂蚁金服技术专家 、SOFAArk 开源负责人 ","date":1579251600,"description":"2 月 13 日周四晚 7 点，线上直播第 11 期。","dir":"activities/sofa-channel-11/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b110f76087d52e5c6d8ccbe31c76a7f5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-11/","publishdate":"2020-01-17T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-11/","summary":"概要 活动主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk 活动时间：2 月 13 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这","tags":["SOFAChannel","SOFAArk"],"title":"SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk","type":"activities","url":"/sofastack.tech/activities/sofa-channel-11/","wordcount":709},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@J~杰 提问：\n 咨询一下，Seata TCC 中这个 BusinessActivityContext 是用于做什么的？\n A：比如说在 rollback 服务里需要用到 try 服务里的参数时，可以放到 BusinessActivityContext，然后在 rollback 和 comfirm 服务里可以取到这个参数。\n 那是要自己在 try 阶段需要手动实例化 BusinessActivityContext？\n A：不需要，可以在 try 方法上的参数加注解，它会自动把这个参数放入 BusinessActivityContext。\nSeata：https://github.com/seata/seata\n2、王国柱 提问：\n 有一个问题想要请教一下： HBX：如果是 spanner - \u0026amp;gt; gateway -\u0026amp;gt; app1 这种架构，每次上新的应用，应该是需要在 geteway 中配置新应用的 ip 地址路由信息。 如果是 spanner -\u0026amp;gt; gateway.jar,app1 这种架构，如果新增加 app2， spanner 如何知道新的应用地址在哪里。\nHBX：我理解集中式的 gateway，应该会把后端 app 的应用地址信息配置在集中式的 gateway 中。如果做成 jar，那 app 和 jar 的地址信息，该如何被 spanner 知道？\n A：Spanner 其实就是 ingress，不管是 gateway 还是 app x，都可以通过服务发现来发现服务器的 ip 信息。\n 那像这种的话，就是后台服务上线，可以自己注册到 spanner 上，然后外部应用就可以直接访问了。\n A：是的。 MOSN：https://github.com/mosn/mosn\nKubeCon NA2019 回顾 开箱即用的 Java Kubernetes Operator 运行时 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 本周推荐文章 10年后，阿里给千万开源人写了一封信 蚂蚁金服消息队列 SOFAMQ 加入 OpenMessaging 开源标准社区 蚂蚁金服 API Gateway Mesh 思考与实践 社区直播预告 春节后直播预告来啦～本期为 SOFAChannel 线上直播第 11 期，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n时间：2020年2月13日（周四）19:00-20:00\n嘉宾：玄北，蚂蚁金服技术专家 SOFAArk 开源负责人\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1579248000,"description":"【01/13-01/17】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200117/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2fd8dd14cb119400890ef134622ad4d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200117/","publishdate":"2020-01-17T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200117/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":" SOFA Weekly | 2.13直播预告、KubeCon NA2019 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200117/","wordcount":1210},{"author":"何子波、金敏","categories":null,"content":" 本篇分享的内容难度为“初学者/Beginner”级别，以下是阅读本文前推荐您了解的背景知识：\n Java 语言编程基础； 了解过 Kubernetes 平台上的 Operator/Controller 工作机制； 也可以同步参考 Kubernetes 官方博客内容：https://kubernetes.io/blog/2019/11/26/develop-a-kubernetes-controller-in-java\n图为何子波和金敏在 KubeCon NA2019 大会分享后的交流\n何子波 蚂蚁金服技术专家： _(adohe@github) _Kubernetes 维护者，SIG CLI Co-Chair（包括 Kubectl 及其扩展插件，Kustomize 以及客户端运行时），同时关注安全容器，多租户等领域。\n金敏 蚂蚁金服软件工程师： _(yue9944882@github) _Kubernetes SIG API-Machinery 维护者及其子领域 Owner（CRD 服务实现，APIAggregation SDK 套件，控制面流控，OpenAPIv2/3，Java SDK 等），同时也是 OpenAPI 开源生态工具链openapitools.org 的 Techincal Committee。\n本文根据两位在 KubeCon NA2019 的分享内容整理。本次演讲与大家分享蚂蚁金服金融科技扩展云原生 Java 能力到云的实践和改造，并将收获的产出回馈开放给 Kubernetes 社区。\n分享概要 在 Kubernetes 平台上开发部署运行 Operator 已经是在 Kubernetes 上拓展开发能力的默认范式。最早是 CoreOS 的工程师们创新提出了 Operator 的开发理念并且在社区收获了良好的反响，在经过一段时间的波折、打磨和实践之后，我们今天才看到丰富多样的 Operator 层出不穷。实际上 Operator 的效力往往要结合 Kubernetes API 的扩展能力才能更好发挥。所以其广泛传播反过来锤炼演进了 Kubernetes 上 CustomResourceDefinition 承载第三方 API 模型的能力。水涨船高，这也是社区集中投入人力从 v1.14 开始启动 Extensibility GA Sprint 小组冲刺 Kubernetes 扩展性建设的推动原因。\n图为何子波和金敏在 KubeCon NA2019 大会现场演示\n随着 Operator 的受众越来越多，社区也衍生出了面向 Operator 开发提效的工具链项目比如 operator-sdk、kubebuilder、metacontroller 等等优秀的开源项目。可是这些项目大都是面向 Go 语言研发者的，虽然越来越多的研发者向 Go 靠扰已是事实，但是 Go 语言尚不及其他主流编程语言成熟，倒是慢慢铺开的 Kubernetes 等其他开源项目的工业实践在“倒逼”Go 语言底层库的修复和稳固，比如 http2 的底层网络库[1]。与此相似的，我们最早内部孵化的 Java 语言的 Operator 运行时框架也是被实际业务“倒逼”出来的，并在 Kubernetes 社区露头试水之初便收获了许多反馈推动发展直到今天走到全面开放。\n你为什么需要使用 Java 开发 Operator 如果你在犹豫不决是否要使用 Java 开发 Operator 并应用到实际中来，我们从以下几个方面进行对比看看哪一点是足够吸引你尝鲜：\n 适配存量系统：如果在登陆 Kubernetes 之前你的基础设施底层系统都是通过 Java 开发的，那么恭喜你已经有了使用 Java Operator 的天然土壤。反过来把存量系统接口逐个“翻译”为 Go 语言既消耗大量人力又引出持续同步维护 Go 语言库的成本。 堆内存快照：相比于 Java，Go 语言很难将运行中的程序的内存进行完整的快照分析，PProf 相关工具链能做的只是将内存的使用概况汇总输出，虽然也可以帮助分析锁定出泄漏的对象类型，但是粒度有限。反过来 Java 程序的堆内存进行快照分析已经具有成熟的工具链支持，研发者通过一份完整的堆快照可以直接锁定出比如 WorkQueue 中积压的内容，甚至限流器中逐个 Key 的瞬时状态，也可以在 Operator 静默不响应的场景下快速锁定问题。 性能诊断/在线调试：结合比如 JMX Exporter 等工具链的帮助，我们直接将 Java 虚拟机的细节运行状态以 Prometheus Metrics 的形式收集起来，虽然 Go 程序也可以暴露出其运行时的 Metrics，但是对比后我们发现 Java 的 Metrics 在分析 GC 状态和堆分布上更加强大。除此之外，Java Operator 的远程调试更加方便上手。 线程模型：与 Java 显著不同的是，Go 语言中的 Routine 不具有直接从外部“杀死”的功能，你需要结合 Channel/Context 等模型间接实现。而在 Java 虚拟机上的线程模型有和操作系统类似的生命周期管理，开发者可以白盒的操作干涉线程的生命周期。这对于某些业务场景是重要的。 OOP 范型编程接口： Go 语言本身的设计哲学是不认可面向对象编程的，尽管好处很多但是在 API 模型繁多的 Kubernetes 项目中，维护者不得己转向使用代码生成器批量为这些模型生成大量模版代码。Java 的优势之一是范型编程，这可以彻底取代代码生成器的工作，同一套代码可以自由地适配在各种模型，比如 Pod 到 Service 等等。 第三方研发者库生态：经过数十年的演进，Java 积累的第三方工具库远比 Go 语言丰富的多，至少目前而已可以算得上是一个优势。 示例代码速览 下面两张代码片段为你展示了具体开发 Java Operator 所需要的全部工作，相信接触过 Kubernetes Client-Go 的开发者通过名字大致了解如何使用了：\n（如何构造出一个 Informer 实例） https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/InformerExample.java\n（如何构造出一个 Operator 实例） https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/ControllerExample.java\n开发 Java Operator 需要额外注意什么 仅仅是通过代码开发 Operator 显然不是大结局，你还需要注意其他的问题，以下是我们在实际运用的获得的经验总结：\n 严谨管理 CRD Yaml 定义：如最开始提到的，当 Java Operator 操作的是自定义资源比如 CRD 时，我们自然需要操作/维护该 CRD 对应的 Java 模型。 …","date":1579176000,"description":" 本文介绍了如何快速上手使用 Java 开发 Operator，感兴趣的读者可以根据官方实例在本地开发环境体验。","dir":"blog/java-kubernetes-operator-kubecon-na2019/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4af2ef3082aeed080e87501fd71134d9","permalink":"https://sofastack.github.io/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","publishdate":"2020-01-16T20:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","summary":"本篇分享的内容难度为“初学者/Beginner”级别，以下是阅读本文前推荐您了解的背景知识： Java 语言编程基础； 了解过 Kubernetes 平台上的 Operator/Controller 工作机制； 也可","tags":["Kubernetes"],"title":" 开箱即用的 Java Kubernetes Operator 运行时","type":"blog","url":"/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","wordcount":2778},{"author":"贾岛","categories":"Service Mesh","content":" 本文整理自蚂蚁金服高级技术专家贾岛在 12 月 28 日 Service Mesh Meetup 杭州站现场分享。\nMOSN 完成孵化， 启用独立 Group 2020.2019.12.18，MOSN 项目负责人、蚂蚁金服应用网络组负责人涵畅宣布 MOSN 完成从 SOFAStack 的孵化，将启用独立 Group 进行后续运作，欢迎大家共同建设社区。\nMOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称，可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡，API Gateway，云原生 Ingress 等使用。\n项目地址：https://github.com/mosn/mosn\n导语 在 Service Mesh 微服务架构中，我们常常会听到东西流量和南北流量两个术语。蚂蚁金服开源的 Service Mesh Sidecar：MOSN（Modular Observable Smart Network）已经多次与大家见面交流，以往的议题重点在东西流量的服务发现与路由，那么蚂蚁金服在南北流量上的思考是怎样的？\n本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的、解决了什么问题、双十一的实践表现以及我们对未来的思考。\n今天的分享分为三个部分：\n API Gateway Mesh 的定义：我在 Google 上搜了下 API Gateway Mesh 这个词，找到的都是 API Gateway vs Service Mesh，大家估计也会很好奇：这个词具体的定义是怎样的呢？所以我们下面会做将 API Gateway 和 Service Mesh 做个对比，然后讲一下我个人对这个词有理解和思考。 API Gateway Mesh 在蚂蚁金服的实践：今年阿里巴巴核心系统 100% 云原生化，撑住了双11的世界级流量洪峰，这其中，蚂蚁金服的 Service Mesh 大放光彩，核心链路全上 Mesh，数万容器规模，我们 API Gateway 在其中也承担了部分钱包链路和支付链路 100% 的请求。这个章节，我会从蚂蚁金服 API 网关的发展历程来看，我们为什么做 API Gateway Mesh，我们的架构是如何的，以及我们在过程中的一些风险和考验。 云原生下 API Gateway 的思考：大家现在都在讲云原生，但是真正实践云原生的过程中，会越到各种各样的问题，怎么样的 API Gateway 方案和形态是最合适你们的业务的？在云原生的架构中，Service Mesh，API Gateway 都是最核心的组件之一，我们对于云原生下的 API Gateway 在 Service Mesh 架构中的定位是如何思考的？还有，未来我们的一些计划是怎样的？都会在这个章节跟大家分享一下。 API Gateway Mesh 的定义 上面这张图是一个云原生，南北+东西流量的架构图，这里面包含了核心的一些组件，我快速介绍一下：\n LB\\ingress：负责 ssl 卸载、入口流量的负载均衡，通常会做一些简单的路由； API Gateway：负责更偏向业务的 API 验签、限流、协议转换、用户会话、负载均衡等逻辑； Sidecar in POD：业务系统中的 Sidecar，代理机房内东西流量的转发，一般走内部的 RPC（比如SOFARPC \\ Dubbo \\ Thrift \\ SpringCloud），这里面的流量全部通过 Service Mesh 的 Sidecar Proxy 来承载，这个 Sidecar 负责路由（单元化\\灰度\\金丝雀），负载均衡、服务鉴权等等； Control Plane：流量控制「大管家」，云原生里目前最主流的方案是 Istio，负责路由策略、安全、鉴权等等下发和控制； 上面的架构大家都比较了解了，从上面的描述大家也看出来了，API Gateway 和 Service Mesh 的 Sidecar 很多能力都是类似的，比如都是一个网络代理，都具备负载均衡，都具备一些限流和鉴权能力。下面，我们将做一个 API Gateway 和 Service Mesh 的对比。\nAPI Gateway vs Service Mesh  从本质概念上来讲，API Gateway 用一句话概括：「Exposes your services as managed APIs」，将内部的服务以更加可控可管理的方式暴露出去，这里的关键词是「暴露」和「可控」。Service Mesh 用一句话概括：「A infrastructure to decouple the application network from your service code」，一种将服务代码与应用网络解耦的基础设施，这里的关键词是「解耦」。\n在流量上，API Gateway 是管理南北流量的，而 Servcie Mesh 中的 Sidecar 一般情况下是用来负载东西流量的Proxy。两者都具备负责均衡的能力，API Gateway 一般情况下是通过 lvs 、nginx 中心化的一个负载均衡器，我们管这个叫硬负载；而 Service Mesh 一般情况下是通过服务发现，Sidecar 之间是点对点的调用，我们叫软负载。\n通信协议上，API Gateway 一般对外接收开放的通信协议，一般是 HTTP、gRPC 等，而且可能涉及到协议的转换，将 HTTP 转换成内部的 RPC 协议，而 Service Mesh 代理的内部流量一般是内部的私有 RPC 协议（WebService、Dubbo、SOFABolt、Thrift 等等）。在鉴权、流控、安全等控制流量的层面上，对于 API Gateway 来讲都是强依赖的，这样才体现「可控」的特点，而 Service Mesh 代理的内部流量，由于一般处于内网环境，这些控制一般情况下都是弱依赖。\n我们对 Service Mesh 的真正理解 大家可以看到，API Gateway 和 Service Mesh 实际上有很多共同点，也有很多区别。那 API Gateway Mesh 到底是如何定义的呢？那要介绍下，我们对 Service Mesh 的真正理解！\nService Mesh 中的 Sidecar 就是这样一辆边车摩托车，Sidecar 将 Service Code 和内部通信 RPC 逻辑解耦掉。但是 Sidecar 的座位上，不仅仅可以坐「内部通信的 RPC」，也可以将其他中间件放到这辆 Sidecar 中，API Gateway + Sidecar = API Gateway Mesh，我们也可以把 MessageQueue Client 放在 Sidecar 中，就是 Message Mesh。\n所以，大家看，其实 Service Mesh 是一种模式和架构，关键词就是「解耦」你的服务代码和你的「中间件」。\nAPI Gateway Mesh …","date":1579078800,"description":" 本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的、解决了什么问题、双十一的实践表现以及我们对未来的思考。","dir":"blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"370ccd30a2edcf559eb2c82976bcb8a0","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","publishdate":"2020-01-15T17:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","summary":"本文整理自蚂蚁金服高级技术专家贾岛在 12 月 28 日 Service Mesh Meetup 杭州站现场分享。 MOSN 完成孵化， 启用独立 Group 2020.2019.12.18，MOSN 项目负责人、","tags":["Service Mesh","MOSN","Service Mesh Meetup"],"title":"蚂蚁金服 API Gateway Mesh 思考与实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","wordcount":5174},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@李彦迎 提问：\n TCC 模式我可以作为 Saga 模式使用不？譬如 try 为空，永远成功。\n A：可以，不过应该是 confirm 为空，不是 try 为空。\n 请问 Seata 的 Saga 模式能支持 DB2 数据库吗？\n A：可以支持 DB2。\n 请教基础问题：Gateway 调用微服务 A、B，B内部失败了，补偿交易应该回退A的，这个补偿交易应该定义在微服A里面还是微服务B里面？\n A：原服务是谁提供的，补偿服务就应该谁提供。\n 请问能否 Client 用 DB2，Server 用 MySQL? Client 的必须和业务数据库保持一致吧？\n A：也可以的。是的，Client端必须与业务数据库保持一致。\n2、@米晓飞 提问：\n Saga 和现有框架有啥区别呢，优劣比较？\n A：我们在实践中发现，长流程的业务场景，往往有服务编排的需求，同时又要保证服务之间的数据一致性。目前开源社区也有一些 Saga 事务框架，也有一些服务编排的框架，但是它们要么只有 Saga 事务处理能力、要么只有服务编排能力，Seata Saga 是将这两者能力非常优雅的结合在一起，为用户提供一个简化研发、降低异常处理难度、高性能事件驱动的产品。\n3、@张春雨 提问：\n Saga 的模式补偿和 XA 回滚有啥区别呀？\n A：XA 是数据库提交的两阶段提交协议，Saga 的是需要业务层来实现的。\n Seata server 端使用 mysql 去记录事务日志,感觉性能上不是很好、 有没有其他的可替代的持久化方案吗？\n A：Seata 每个模块都设计有 SPI，持久化也一样，未来可以扩展更多持久化方式。 Seata：https://github.com/seata/seata 更多关于 Seata Saga 的内容可以看下文直播回顾。\n4、@FAN 提问：\n MOSN 的平滑升级原理是什么？跟 Nginx 和 Envoy 的区别是什么？\n A：MOSN 的平滑升级方案和 Envoy 类似，都是通过 UDS 来传递 listener fd。但是其比 Envoy 更厉害的地方在于它可以把老的连接从 Old MOSN 上迁移到 New MOSN 上。也就是说把一个连接从进程 A 迁移到进程 B，而保持连接不断！Nginx 的实现是兼容性最强的。 可以详细阅读：https://ms2008.github.io/2019/12/28/hot-upgrade/ MOSN：https://github.com/mosn/mosn\nSOFAArkLab 系列 蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析 本篇开始将正式启动SOFA:ArkLab/源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。文中附共建列表，欢迎领取共建~\nSOFAChannel 集锦 Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v3.2.2 版本，主要变更如下：\n ReadinessCheckListener 的 Order 过高 删除 jaxrs-api 依赖项 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.2.2\n","date":1578643200,"description":"【01/05-01/10】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200110/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1143431da4314982069d5d5465391dc5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200110/","publishdate":"2020-01-10T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200110/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot 发版、直播回顾、SOFAArkLab共建启动","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200110/","wordcount":1463},{"author":"屹远","categories":"Seata","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#10 直播分享整理，主题：分布式事务 Seata 长事务解决方案 Saga 模式详解。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群：23372465，不错过每场直播。\n 大家好，我是陈龙，花名: 屹远（_long187@github_），是蚂蚁金服分布式事务核心研发，也是 Seata Committer。今天分享的主题是《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\nSeata：https://github.com/seata/seata\n金融分布式应用开发的痛点 分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。\u0026amp;mdash;《左耳听风-弹力设计之“补偿事务”》\n而在金融领域微服务架构下的业务流程往往会更复杂，流程很长，比如一个互联网微贷业务流程调十几个服务很正常，再加上异常处理的流程那就更复杂了，做过金融业务开发的同学会很有体感。\n所以在金融分布式应用开发过程中我们面临一些痛点：\n 业务一致性难以保障 我们接触到的大多数业务（比如在渠道层、产品层、集成层的系统），为了保障业务最终一致性，往往会采用“补偿”的方式来做，如果没有一个协调器来支持，开发难度是比较大的，每一步都要在 catch 里去处理前面所有的“回滚”操作，这将会形成“箭头形”的代码，可读性及维护性差。或者重试异常的操作，如果重试不成功可能要转异步重试，甚至最后转人工处理。这些都给开发人员带来极大的负担，开发效率低，且容易出错。\n 业务状态难以管理 业务实体很多、实体的状态也很多，往往做完一个业务活动后就将实体的状态更新到了数据库里，没有一个状态机来管理整个状态的变迁过程，不直观，容易出错，造成业务进入一个不正确的状态。\n 业务监控运维难 业务的执行情况监控一般通过打印日志，再基于日志监控平台查看，大多数情况是没有问题的，但是如果业务出错，这些监控缺乏当时的业务上下文，对排查问题不友好，往往需要再去数据库里查。同时日志的打印也依赖于开发，容易遗漏。\n 缺乏统一的差错守护能力 对于补偿事务往往需要有“差错守护触发补偿”、“人工触发补偿”操作，没有统一的差错守护和处理规范，这些都要开发者逐个开发，负担沉重。\n理论基础 对于事务我们都知道 ACID，也很熟悉 CAP 理论最多只能满足其中两个，所以，为了提高性能，出现了 ACID 的一个变种 BASE。ACID 强调的是一致性（CAP 中的 C），而 BASE 强调的是可用性（CAP 中的 A）。在很多情况下，我们是无法做到强一致性的 ACID 的。特别是我们需要跨多个系统的时候，而且这些系统还不是由一个公司所提供的。BASE 的系统倾向于设计出更加有弹力的系统，在短时间内，就算是有数据不同步的风险，我们也应该允许新的交易可以发生，而后面我们在业务上将可能出现问题的事务通过补偿的方式处理掉，以保证最终的一致性。\n所以我们在实际开发中会进行取舍，对于更多的金融核心以上的业务系统可以采用补偿事务，补偿事务处理方面在30多年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较也公认 Saga 是作为长事务的解决方案。\n https://github.com/aphyr/dist-sagas/blob/master/sagas.pdf http://microservices.io/patterns/data/saga.html\n Saga 模式用一种非常纯朴的方式来处理一致性：补偿。上图左侧是正常的事务流程，当执行到 T3 时发生了错误，则开始执行右边的事务补偿流程，返向执行T3、T2、T1 的补偿服务，其中 C3 是 T3 的补偿服务、C2 是 T2 的补偿服务、C1 是 T1 的补偿服务，将T3、T2、T1 已经修改的数据补偿掉。\n使用场景 一些场景下，我们对数据有强一致性的需求时，会采用在业务层上需要使用“两阶段提交”这样的分布式事务方案。而在另外一些场景下，我们并不需要这么强的一致性，那就只需要保证最终一致性就可以了。\n例如蚂蚁金服目前在金融核心系统使用的就是 TCC 模式，金融核心系统的特点是一致性要求高（业务上的隔离性）、短流程、并发高。\n而在很多金融核心以上的业务（比如在渠道层、产品层、集成层的系统），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务（如金融网络）。这是如果每个服务都开发 Try、Confirm、Cancel 三个方法成本高。如果事务中有其它公司的服务，也无法要求其它公司的服务也遵循 TCC 这种开发模式。同时流程长，事务边界太长，加锁时间长，会影响并发性能。\n所以 Saga 模式的适用场景是：\n 业务流程长、业务流程多； 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口； 典型业务系统：如金融网路（与外部机构对接）、互联网微贷、渠道整合、分布式架构下服务集成等业务系统； 银行业金融机构使用广泛； 其优势：\n 一阶段提交本地事务，无锁，高性能； 参与者可异步执行，高吞吐； 补偿服务易于实现，因为一个更新操作的反向操作是比较容易理解的； 其缺点：\n 不保证隔离性，后面我们会讲到如何应对隔离性的缺失。 基于状态机引擎的 Saga 实现 基于状态机引擎的 Saga 实现的基本原理：\n 通过状态图来定义服务调用的流程并生成 json 定义文件； 状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点（虚线关联的节点）； 状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚； 异常发生时是否进行补偿也可由用户自定义决定； 可以实现服务编排需求，路由、异步、重试、参数转换、参数映射、服务执行状态判断、异常捕获等功能 ； Seata 目前的 Saga 模式采用了状态机+DSL 方案来实现，原因有以下几个：\n 状态机+DSL 方案在实际生产中应用更广泛； 可以使用 Actor 模型或 SEDA 架构等异步处理引擎来执行，提高整体吞吐量； 通常在核心系统以上层的业务系统会伴随有“服务编排”的需求，而服务编排又有事务最终一致性要求，两者很难分割开，状态机+DSL 方案可以同时满足这两个需求； 由于 Saga 模式在理论上是不保证隔离性的，在极端情况下可能由于脏写无法完成回滚操作，比如举一个极端的例子，分布式事务内先给用户 A 充值，然后给用户 B 扣减余额，如果在给A用户充值成功，在事务提交以前，A 用户把线消费掉了，如果事务发生回滚，这时则没有办法进行补偿了，有些业务场景可 …","date":1578574800,"description":"本文根据 SOFAChannel#10 直播分享整理，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用","dir":"blog/sofa-channel-10-retrospect/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2ba15ca1c710e1be2e6758950246d1ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-10-retrospect/","publishdate":"2020-01-09T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-10-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#10 直播分享整理，主题：分布式事务 Seata 长事务解决方案 Saga 模式详解。 回顾视频以及 PPT 查看","tags":["Seata","SOFAChannel"],"title":"Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-10-retrospect/","wordcount":6186},{"author":"卫恒","categories":"SOFAArk","content":" 本篇开始将正式启动 SOFAArk:Lab/ 源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。\n本文为《剖析 | SOFAArk 源码》第一篇，本篇作者卫恒，SOFAArk 开源负责人。《剖析 | SOFAArk 源码》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附共建列表，欢迎领取共建~\n 在大型软件开发过程中，通常会推荐底层功能插件化、业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。对于模块化，从语言层面，原计划在 Java7 就有的模块化特性，终于在 Java9 里面提供了。在 Java语言级对模块化提供支持之前，业界内最知名的 Java 模块化规范当属 OSGi 了，直至到今天，OSGi 在众多企业、厂商中被广泛使用，比如我们常用的 Web 应用服务器、Eclipse 等均采用了 OSGi 规范。\n蚂蚁金服内部，CE 作为使用了 10 年的\u0026amp;rdquo;元老级\u0026amp;rdquo;容器组件，见证了和支撑了每年的大促、新春红包等流量场景。作为中间件的常青树，CE 以足够的稳定性为业务保驾护航。CE 容器也是基于 OSGi 实现了模块化，但是由于 CE 背负了太多包袱，使得其自身变得太重，在云原生及商业化输出上逐渐失去了优势。\n从 2016 年底开始，框架组内部开始在 CE 的基础上进行抽离和整合，开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\nSOFAArk 简介 SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin） 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz) 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz。 SOFAArk：https://github.com/sofastack/sofa-ark\n应用场景 基于模块化及模块的动态能力，SOFAArk 有非常丰富的落地场景，如：通过从 classloader 层面解决 依赖冲突问题、基于 arkcontainer 的多应用合并部署，基于动态 biz 的 SOFAServerless 等等。\n依赖冲突 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError、NoSuchMethodError 等；实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法，统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突；这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题；如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题； OSGi 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGi 框架太过臃肿，功能繁杂；为了解决包冲突问题，引入 OSGi 框架，有牛刀杀鸡之嫌，且反而使工程变得更加复杂，不利于开发。\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 – Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如果工程需要引入两个三方包：A 和 B，但是 A 需要依赖版本号为 0.1 的 C 包，而恰好 B 需要依赖版本号为 0.2 的 C 包，且 C 包的这两个版本无法兼容：\n此时，即可使用 SOFAArk 解决该依赖冲突问题；只需要把 A 和版本为 0.1 的 C 包一起打包成一个 Ark 插件，然后让应用工程引入该插件依赖即可。\n合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 - Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成可执行 Fat Jar 时，可以将其他应用 Biz 包一并打入，启动时，则会根据优先级依次启动各应用。每个 Biz 使用独立的 BizClassLoader 加载，不需要考虑相互依赖冲突问题，Biz 之间则通过 SofaService / SofaReference JVM 服务进行交互。\n 静态合并部署是将多个应用打包在一个 ARK 可执行 JAR 包中，然后通过 java -jar 启动，这种方式可以在 ARK 容器内同时运行多个应用，对于一些资源要求不高、流量较少的应用可以使用这种方式部署以节省资源。\n 动态模块 模块是 ark biz 在动态模型场景下的一种别名，其实质就是一个 ark biz 包。\n 动态模块相对于静态合并部署最大的不同点是，运行时通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态模块的设计理念图如下：\n无论是静态合并部署还是动态模块都会有宿主应用（master biz）的概念, 如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主应用不允许被卸载，一般而言，宿主应用 …","date":1578398400,"description":" 本文为《剖析 | SOFAArk 源码》第一篇，作者卫恒","dir":"blog/sofa-ark-overview/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"56bc84e9737dbad9c77b9700b12bf63d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-overview/","publishdate":"2020-01-07T20:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-ark-overview/","summary":"本篇开始将正式启动 SOFAArk:Lab/ 源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。 本文为《剖析 | SOFAArk 源码》第一篇，本篇作者卫恒，SOFAArk 开源负责人","tags":["SOFAArk","剖析 | SOFAArk 源码 ","SOFALab"],"title":"蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析","type":"blog","url":"/sofastack.tech/blog/sofa-ark-overview/","wordcount":3810},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\nSeata：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，其中长事务解决方案 Saga 模式有着无锁高性能、异步架构高吞吐的优势。\nSeata：https://github.com/seata/seata\nSaga 状态机在线设计器：http://seata.io/saga_designer/index.html\nSaga 状态机设计器视频教程：http://seata.io/saga_designer/vedio.html\n1、@李宇博 提问：\n 您好，我这边看视频直接把 Catch 直接拖到 serviceTask 上，好像没有生效，需要连线还是配置什么属性吗？\n A：没有生效是指什么？Catch 要连一个线到一个其它的 state，意思是捕获到异常后，去执行一个分支，这个 state可以是任何类型的 state，比如 CompensationTrigger、ServiceTask，通常是 CompensationTrigger，立即触发补偿。\n 我是直接连接到 compensateTrigger 上的，然后我手动抛出异常，并没有执行补偿方法，而是在不停的重试调用之前抛出异常的方法。\n A：需要在线上配置异常类型：\n2、@J～杰 提问：\n 咨询一个问题，AT 模式分支事物注册的时候会获取锁，锁名就是和 table+主键有关系的，由于压力测试的时候，有个 check 去数据库查询同一个 rowkey，导致直接获取锁失败，在业务上就是业务失败回滚了，这种有啥办法？\n A：你的意思是热点数据问题吗？\n 可以理解成热点数据，我这边的测试场景就是下单减库存，2个微服务，库存由于基本上是同一行库存数据。\n A：热点数据撞锁是正常的，你可以用自旋锁，让其它事务等待一下再获取锁，而不是立即失败。http://seata.io/zh-cn/docs/user/configurations.html\n 本地调用 Dubbo 微服务是可以的，用 Saga 状态机就报这个问题，报服务没有提供者。\n A：你的 Service 是用的 XML 注册的还是用的注解注册的？\n 注解的方式。\n A：嗯嗯。你尝试用 XML 方法注册一个 Bean 看看行不行，机制上可能有不一样，因为 Saga 状态机是通过 getBean 反射去调方法。而 Dubbo 的注解是通过代理的方式来注入一个对象，这个对象是不是一个有完全成功的 Bean，不确定。之前我遇到过 TCC 用注解不好使，用 XML 好使的问题。\n本周推荐阅读 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 SOFARegistryLab 系列 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 蚂蚁金服服务注册中心 Session 存储策略 | SOFARegistry 解析 蚂蚁金服服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.9.0 版本，主要变更如下： i. 重构了包引用路径，从 sofastack.io/sofa-mosn 变更为 mosn.io/mosn； ii. 支持变量机制，accesslog 修改为使用变量机制获取信息； iii. 修复在 proxy 协程 panic 时导致的内存泄漏； iv. 修复在特定的场景下，读写协程卡死导致的内存泄漏； v. 修复 HTTP2 Stream 计数错误的 bug；\n详细发布报告：https://github.com/mosn/mosn/releases/tag/0.9.0\n社区直播预告 新年快乐~2020年第一期线上直播来啦，SOFAChannel#10 将和大家一起探讨 《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\n主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解\n时间：2020年1月9日（下周四）19:00-20:00\n嘉宾：陈龙（花名：屹远） 蚂蚁金服分布式事务核心研发、Seata Committer\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1578038400,"description":"【12/31-01/03】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200103/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"aa8f76ccca9d7d700e3d9b16c2b0df21","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200103/","publishdate":"2020-01-03T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200103/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 1.9直播预告、MOSN 发版、Saga 状态机设计器视频教程","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200103/","wordcount":1862},{"author":"米麒麟","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第六篇，本篇作者子懿，来自阿里云。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n前言 微服务架构为了保证所有服务可用，当服务发生问题时能及时摘除有问题的服务，需要定期检测服务可用性即健康检测。健康检测包括客户端心跳和服务端主动探测两种方式，定期发送 TCP 或 HTTP 请求根据响应确定服务是否正常。服务注册中心提供服务注册和订阅服务，在服务发布者服务信息发生变化、或者节点上下线时通知变更，动态更新消费方的服务地址列表信息，支持服务注册和下线的快速变更通知。\n本文重点围绕服务的健康检测、SOFARegistry 的健康检测以及基于 SOFARegistry 实现秒级服务注册下线等方面剖析 SOFARegistry 如何实现秒级服务上下线通知原理，阐述如何使用 SOFARegistry 对于服务的注册下线场景通过推送机制快速实现端到端的传达功能：\n 如何实现服务的健康检测？业界服务注册中心的健康机制是怎样的？SOFARegistry 的健康检测实现方式？ SOFARegistry 服务注册下线数据流转过程是怎样的？SOFARegistry 内部角色如何实现秒级服务上下线通知？ 服务的健康检测 服务的健康检测是如何实现？健康检测分为客户端心跳和服务端主动探测两种方式：\n 客户端心跳 客户端采取每隔一定时间间隔主动发送心跳方式向服务端表明自己的服务状态正常，心跳是 TCP 或者 HTTP 的形式； 通过维持客户端和服务端的 Socket 长连接自己实现客户端心跳的方式； ZooKeeper 没有主动的发送心跳，而是依赖组件本身提供的临时节点的特性，通过 ZooKeeper 连接的 Session 维持临时节点； 客户端心跳中长连接的维持和客户端的主动心跳偏重服务链路是否正常，不一定是服务状态正常；服务端主动调用服务健康检查是比较准确的方式，通过返回结果成功判断服务状态健康情况； 服务端主动探测 服务端调用服务发布者 HTTP 接口来完成健康检测； 对于没有提供 HTTP 服务的 RPC 应用，服务端调用服务发布者的接口来实现健康检测； 通过执行脚本形式来进行定时检测； 服务端主动探测依然存在问题。服务注册中心主动调用 RPC 服务的某个接口无法做到通用性；在很多场景下服务注册中心到服务发布者的网络是不通的，服务端无法主动发起健康检查； 注册中心的健康检测 业界服务注册中心的健康检测机制：\n Eureka：定期有 Renew 心跳，数据具有 TTL（Time To Live）；并且支持自定义 HealthCheck 机制，当 HealthCheck 检测出系统不健康时主动更新 Instance 的状态； Zookeeper：定期发送连接心跳以保持会话 （Session），会话本身 （Session） 具有TTL； Etcd：定期通过 HTTP 对数据进行 Refresh，数据具有 TTL。申请 Lease 租约，设置服务生存周期TTL； Consul：Agent 定期对服务进行 healthcheck，支持 HTTP/TCP/Script/Docker；由服务主动定期向 agent 更新 TTL； SOFARegistry 的健康检测 业界服务注册中心的健康检测都有个共同的关键词：“定期”。定期检测的时间周期通常设置为秒级，比如 3 秒、5 秒或 10 秒，甚至更长，也就是说服务的健康状态总是滞后的。蚂蚁金服的注册中心从最初的版本设计开始，就把健康状态的及时感知，当做一个重要的设计目标，特别是需要做到“服务宕机能被及时发现”。因此 SOFARegistry 在健康检测的设计方面决定“服务数据与服务发布者的实体连接绑定在一起，断连马上清数据”，简称此特点叫做连接敏感性。连接敏感性是指在 SOFARegistry 里所有 Client 都与 SessionServer 保持长连接，每条长连接都设置基于 SOFABolt 的连接心跳，如果长连接断连客户端立即发起重新建连，时刻保持 Client 与 SessionServer 之间可靠的连接。\nSOFARegistry 将服务数据 （PublisherRegister） 和服务发布者 （Publisher） 的连接的生命周期绑定在一起：每个 PublisherRegister 定义属性 connId，connId 由注册本次服务的 Publisher 的连接标识 （IP 和 Port）构成，也就是只要该 Publisher 和 SessionServer 断连，服务信息数据即失效。客户端重新建连成功后重新注册服务数据，重新注册的服务数据会被当成新的数据，考虑更换长连接后 Publisher 的 connId 是 Renew 新生成的。\n譬如当服务的进程宕机时，一般情况下 OS 立刻断开进程相关的连接（即发送 FIN），因此 SessionServer 能够实时感知连接断开事件，然后把该 connId 相关的所有 PublisherRegister 都清除，并且及时推送给所有服务订阅者 （Subscriber）。如果只是网络问题导致连接断开，实际的服务进程没有宕机，此时客户端立即发起重新连接 SessionServer 并且重新注册所有服务数据。对服务订阅者本身来说接收到的是服务发布者经历短暂的服务下线后以及再次重新上线。假如此过程耗时足够短暂（例如 500ms 内发生断连和重连），服务订阅者可能感受不到服务下线，因为 DataServer 内部的数据通过 mergeDatum 延迟合并变更的 Publisher 服务信息，version 是合并后最新的版本号。\n服务上下线过程 服务的上下线过程是指服务通过代码调用执行常规注册（Publisher#register） 和下线（Publisher#unregister）操作，不考虑因为服务宕机等意外情况导致的下线场景。\n“一次服务注册过程”的服务数据在 SOFARegistry 内部流转过程：\n 客户端 Client 调用服务发布者 Publisher 的 register 向 SessionServer 注册服务。 SessionServer 接收到服务数据即 PublisherRegister 写入内存 （SessionServer 存储 Client 的服务数据到内存，用于后续跟 DataServer 做定期检查）， …","date":1577955600,"description":" 本文为《剖析 | SOFARegistry 框架》第六篇，作者米麒麟","dir":"blog/sofa-registry-service-offline-notification/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"289ee5ccb8ee61cdd0a42ce60874284b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-service-offline-notification/","publishdate":"2020-01-02T17:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-service-offline-notification/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-service-offline-notification/","wordcount":4114},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解\n 活动时间：1 月 9 日周四晚 7 点\n 活动形式：线上直播\n 活动回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，其中长事务解决方案 Saga 模式有着无锁高性能、异步架构高吞吐的优势。\n本期为 SOFAChannel 线上直播第 10 期，将邀请 蚂蚁金服 分布式事务核心研发 \u0026amp;amp; Seata Committer 屹远 和大家一起探讨 《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1076\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服 Service Mesh 双十一落地详解 屹远 蚂蚁金服分布式事务核心研发、Seata Committer\n本期分享大纲： 金融分布式应用开发的痛点 Seata Saga 理论基础以及使用场景 基于状态机引擎的 Saga 实现 Seata Saga 模式最佳实践以及优势 嘉宾 SOFAGirl 主持人 屹远 蚂蚁金服分布式事务核心研发、Seata Committer ","date":1577765400,"description":"1 月 9 日周四晚 7 点，线上直播第 10 期。","dir":"activities/sofa-channel-10/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a2f7bb983d4cbad1bda1a48a3c99abb7","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-10/","publishdate":"2019-12-31T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-10/","summary":"概要 活动主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解 活动时间：1 月 9 日周四晚 7 点 活动形式：线上直播 活动回顾：戳这","tags":["SOFAChannel","Seata"],"title":"SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解","type":"activities","url":"/sofastack.tech/activities/sofa-channel-10/","wordcount":627},{"author":"董一韬、王轲","categories":null,"content":" 本文推荐知道的背景知识：\n Kubernetes 的基本原理和各大组件的职责； Serverless 计算的基本概念和它的优势； Plus: 对社区 Knative 项目的基本了解； 本文根据董一韬和王轲在 KubeCon NA 2019 大会分享整理。\n董一韬 蚂蚁金服，产品经理，致力于驱动云计算相关产品，包括云原生 PaaS 平台、容器与 Serverless 产品等，与最终顾客紧密合作，帮助客户在规模化的金融场景下采用与落地云原生相关解决方案。\n王轲 蚂蚁金服，软件工程师，建设基于 Kubernetes/Knative 的企业级 Serverless 产品，Knative 的早期使用者，Kubernetes 社区成员、控制面流控早期维护者，长期致力于用创新的方式优化、落地云原生技术。\n一. 分享概要 Knative 是 Google 主导的基于 Kubernetes 的 Serverless 平台，在社区上有较高的知名度。然而，身为社区项目的 Knative 主要关心的是标准、架构。虽有先进的理念，却离可在生产上使用有不少的差距。\n本次 KubeCon 的演讲中，来自蚂蚁金服 SOFAStack-PaaS 平台产品技术团队的隐秀和仲乐与大家分享蚂蚁金服金融科技 Knative 的实践和改造：基于 Knative 构建一个优秀的 Serverless 计算平台，详细分析如何用独特的技术，解决性能、容量、成本三大问题。\n从 Serverless 计算的应用场景开始，提炼客户真正的 Use Case，分公有云、私有云、行业云等，讲述 Serverless 计算的多种用途。之后我们将介绍在 Kubernetes 上运行 Knative 平台的方案，详细介绍要使其生产可用，不得不克服的问题。演讲最后，将刚刚的这些问题一一攻破，做出一个比社区版本优秀的 Knative 平台。\n二. 解决性能问题：使用 Pod 预热池 熟悉 Kubernetes 的同学可能知道，Kubernetes 的首要目标并不是性能。\n在一个大规模的 Kubernetes 集群下，要创建一个新的 Pod 并让它跑起来，是很慢的。这是因为这整个链路很长：先要向 APIServer 发一个 POST 请求，再要等 Scheduler 收到新 Pod 资源被创建的事件，再等 Scheduler 在所有的 Node 上运行一遍筛选、优选算法并把调度结果返回给 API Server，再到被选中 Node 的 Kubelet 收到事件，再到Docker 镜像拉取、容器运行，再到通过安全检查并把新的容器注册到 Service Mesh 上…\n任何一个步骤都有可能出现延时、丢事件，或失败（如调度时资源不足是很常见的）。就算一切都正常工作，在一个大规模的 Kubernetes 集群里，整个链路延时达到20s，也是很常见的。\n这便导致在 Kubernetes 上做 Serverless 的窘境：Serverless 的一大特点是自动扩缩容，尤其是自动从0到1，不使用时不占任何资源。但如果一个用户用 Serverless 跑自己的网站/后端，但用户的首个请求花费20s才成功，这是无法接受的。\n为了解决冷启性能问题，我们团队提出了一个创造性的解决方案：使用 Pod 预热池（Pod Pool）。\n我们的产品会预先创建许多个 Pod 并让它们运行起来，当 Kubernetes 的控制器希望创建一个新的 Pod 的时候，我们不再是从零开始新建一个 Pod，而是找到一个处于待命状态的符合条件的 Pod，并把代码注入这个 Pod，直接使用。\n在演讲中，我们分享了一定技术实现的细节，例如如何创建 CRD 并 fork Kubernetes 的 ControllerManager，来以较小的成本实现新 Workload；如何自动根据历史的使用数据来自动伸缩 Pod 池的水位；如何做代码注入等。我们提了3种方式，分别是给容器发指令让容器中的进程下载并执行代码包、使用 Ephemeral Container、魔改 Kubelet允许替换 Container。\n实际的实现比这个还要复杂，要考虑的问题更多，例如如何响应 Pod 中不同的资源 request、limit。我们实际上也实现了一个调度器。当某个预热好的 Pod 不能满足，会看那个 Pod 所在 Node 上的资源余量，如果余量够则动态改 Kubernetes 控制面数据和 cgroups，实现“垂直扩容”。\n实际操作证明，这个冷启优化的效果非常好，当 Pod 大小固定、代码包缓存存在时，启动一个最简单的 HTTP 服务器类型应用的耗时从近20秒优化到了2秒，而且由于不需要当场调度 Pod，从0到1的稳定性也提升了很多。\n这个优化主要是跳过了若干次 API Server 的交互、Pod Schedule 的过程和 Service Mesh 注册的过程，用户程序从零到一的体验得到极大的提升，又不会招致过多的额外成本。一般来讲多预留10-20个 Pod 就可以应付绝大多数情况，对于少见的短时间大量应用流量激增，最坏情况也只是 fallback 到原先的新创建 Pod 的链路。\nPod 预热池不光可以用来做冷启优化，还有很多其他的应用场景。演讲中我呼吁将这种技术标准化，来解决 Kubernetes 数据面性能的问题。会后有观众提出 cncf/wg-serverless 可能有兴趣做这件事情。\n三. 降低成本：共享控制面组件 在成本方面，我们和大家分享了多租户改造和其他的降低成本的方式。\n如果以单租户的方式运行社区版的 Knative，成本是昂贵的：需要部署 Kubernetes 控制面和 Service Mesh 控制面，因为这些都是 Knative 的依赖，Knative 本身的控制面也很占资源。十几C几十G 的机器就这样被使用了，不产生任何业务价值。因此，共享这些控制面的组件是非常必要的。\n通过共享，用户不必再单独为基础设施买单。控制面的成本也只和每个租户创建的应用的数量之和有关，而不会再和租户多少产生关联。\n我们推荐两种共享的方式，一种是 Namespace 隔离+ RBAC 权限控制，这种控制面共享的方法是最简单、Kubernetes 原生支持，也广为使用的一种方法。另一种方法是蚂蚁金服金融科技自研 Kubernetes 实现的多租户方案，通过在 etcd 中多加一级目录并把每个用户的数据存在他们自己的目录中，实现真正全方位多租户的 Kubernetes。\n演讲中还提到了其他的一些降低成本的方法，如通过 Virtual Kubelet 对接阿里云的 ECI（按需的容器服务）、通过 Cluster AutoScaler 来自动释放使用率低的 Kubernetes 节点或从阿里云购置 ECS 来增加新的节点以水平扩容等。还简单提了一下多个租户的容器共享同一个宿主机可能面临的安全问题，如 Docker 逃逸。一种可能的解决方法是使用 Kata Container（虚拟机）以避免共享 Linux 内核。\n四. 解决容量问题：每个层级都做好对分片的支持 容量方面的挑战在于当 Workload 数量增多后， …","date":1577707200,"description":" 本文基于 Knative 构建一个优秀的 Serverless 计算平台，详细分析如何用独特的技术，解决性能、容量、成本三大问题。","dir":"blog/knative-serverless-kubecon-na2019/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ceeb7bee775048b0c23fe553fc5cd335","permalink":"https://sofastack.github.io/sofastack.tech/blog/knative-serverless-kubecon-na2019/","publishdate":"2019-12-30T20:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/knative-serverless-kubecon-na2019/","summary":"本文推荐知道的背景知识： Kubernetes 的基本原理和各大组件的职责； Serverless 计算的基本概念和它的优势； Plus: 对社区 Knative 项目的基本了解； 本文根据董一韬和王轲在 KubeCon NA 2019 大会","tags":["Knative","Serverless"],"title":" 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019","type":"blog","url":"/sofastack.tech/blog/knative-serverless-kubecon-na2019/","wordcount":3400},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News SOFAStack 社区上线了 SOFA Community 试运行方案，欢迎社区内更多的同学参与我们，加入共建❤\n社区随时都欢迎各种贡献，无论是简单的错别字修正、bug 修复还是增加新功能，欢迎提 issue 或 pull request 至 Github 社区。\nSOFA Community 期待你的加入：https://www.sofastack.tech/community/\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@包和平 提问：\n 请问 Seata Saga 状态机可以跨服务来配置吗？案例中的 springcloud-eureka-feign-mybatis-seata 这个和我们的情况类似。这个默认的不是 AT 模式吗？我想使用 Saga 的状态机来配置整个流程，这个情况就涉及了三个服务 storage order account，我看 demo 中都是在单个服务中配置的状态机，所以想询问一下怎么配置。 A：可以跨服务调用，而且服务用不同的 RPC 框架也是可以的，Saga 的事例在 seata-sample 仓库有，Seata 仓库的 test 模块也有很多事例。文档地址：http://seata.io/zh-cn/docs/user/saga.html\n 有 Saga 模式的 spring feign 方式的配置 demo 吗？\n A：没有，不过 Seata Saga 只需要是一个 bean 就可以调用，理论上和什么 RPC 框架无关。\n A 服务的状态机 a_state.json 设置的子状态机是在 B 服务上配置的 b_state.json，可以这样设置吗？\n A：A 服务如果是通过状态机实现的，例如 a_state.json，这个状态机可以调用 B 服务，B 服务也可以是状态机实现的，例如 b_state.json，这两个状态机都不是子状态机，而 a_state.json 其实只知道调到了一个服务，而它内部是什么实现的它不知道。子状态机是要再同一个应用内，才可以被其它状态机调用，跨了应用，则认为只是一个服务。\n Seata 还支持其他方式实现 Saga？ 我看好像都是状态机呢，是我遗漏了哪里吗?\n A：目前是只有状态机。未来会有通过注解+拦截器实现。我所说的“A 服务如果是通过状态机实现的”，服务的实现是可以任何方式的，不是 Saga 的实现。实现一个服务，自己编码也能实现，和框架无关。\n 这个意思其实只是在 A 中调用了 feignClient 是这个意思吧?\n A：是的。\n2、@李宇博 提问：\n Saga 状态机设计器很多属性和文档不太一样呢。\n A：没有和文档不一致的属性吧。你看到的设计器生成的 json，是因为它带了布局信息，它的 stateProps 是和文档是一致的，其它属性是设计器生成的，不需要关心。\n 我没有找到 startState 属性，然后我以为要自己写 next 属性，好像是连线解决了这个问题，还有一点不太明白，就是一个事务只用设计一个 compensationTrigger么？\n A：是的，是用 Start 后面的连线解决，所以不需要 startState 属性了。 compensationTrigger 可以有任意多个，看怎么画好看就行。\n start、success、fail、choice 节点都省去了配置么？还有 compensationtrigger。\n A： Start 里有配置状态机的名称，描述，版本什么的、fail 里可以配置错误码和错误信息，succed 和 choice 应该只有一个名称，没其他的了。\n 嗯嗯，compensationTrigger 是不是也不用配置了?\n A：不用，也是 id 不重就行。\n3、@赵润泽 提问：\n TCC 模式下的事务发起者和 AT 模式下的事务发起者，被代理后执行的操作是一样的吗？\n A：TccActionInterceptor 拦截的是 TwoPhaseBusinessAction 注解也就是拦截的是分支事务，在之前 TM 已经做了 begin，这个是通过 GlobalTransactional 的 intercept 开启的。\n TCC 事务的开启和 AT 事务的开启流程是一样的吗，毕竟都是一个注解？\n A： 是一样的，都是发起方加 GlobalTransactional 注解，对于 TCC 分支来说都要额外加一个 TwoPhaseBusinessAction 注解。\n本周推荐阅读 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 社区活动预告 就在明天，Service Mesh Meetup 第9期杭州站，本期与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用，现场还有机会获得 Istio 官方 T 恤 以及 相关技术书籍。明天，不见不散~\n主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond\n时间：2019年12月28日（明天）13:00-17:30\n地点：杭州西湖区紫霞路西溪谷G座8楼\n报名方式：点击“这里”，即可报名\n","date":1577430000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191227/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"026916366f7c75abaf698dabaed81047","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191227/","publishdate":"2019-12-27T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191227/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 明日活动信息、社区方案上线、落地系列阅读","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191227/","wordcount":1949},{"author":"封尘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，本次主题主要分享在蚂蚁金服当前的体量下，控制面平稳支撑大规模 Sidecar 的落地实践。聚焦控制面核心组件 Pilot 和 Citadel，分享蚂蚁金服双十一控制面如何管理并服务好全站 Sidecar。\n本次分享主要分为两大部分，分别是：\n Pilot 落地实践； Citadel 安全加固； Pilot 落地实践 在开始分享落地实践之前，我们先来看看 Istio 的架构图：\n理想很丰满，现实很骨感。由于性能等方面的综合考虑，我们在落地过程中，将控制面的组件精简为 Pilot 和 Citadel 两个组件了，不使用因性能问题争议不断的 Mixer，不引入 Galley 来避免多一跳的开销。\n在架构图中，控制面组件 Pilot 是与 Sidecar 交互最重要的组件，负责配置转化和下发，直面 Sidecar 规模化带来的挑战。这也是双十一大促中，控制面最大的挑战。\n规模化的问题在生产实践中，是一个组件走向生产可用级的必经之路。接下来将会分别从稳定性、性能优化、监控这三个方面分别展开。\n稳定性增强 我们先梳理下 Pilot 提供的服务能力，从功能实现上来看，Pilot 是一个 Controller + gRPC Server 的服务，通过 List/Watch 各类 K8s 资源，进行整合计算生成 XDS 协议的下发内容，并提供 gRPC 接口服务。本次分享我们先把关注点放在 gRPC 接口服务这个环节，如何保证接口服务支撑大规模 Sidecar 实例，是规模化的一道难题。\n负载均衡\n要具备规模化能力，横向扩展能力是基础。Pilot 的访问方式我们采用常用的 DNSRR 方案，Sidecar 随机访问 Pilot 实例。由于是长连接访问，所以在扩容时，原有的连接没有重连，会造成负载不均。为解决这个问题，我们给 Pilot 增加了连接限流、熔断、定期重置连接功能，并配合 Sidecar 散列重连逻辑，避免产生连接风暴。\n 连接限流 为了降低大量 MOSN 同时连接同一个 Pilot 实例的风险，在 gRPC 首次连接时，Pilot 增加基于令牌桶方案的流控能力，控制新连接的处理响应，并将等待超时的连接主动断连，等待 Sidecar 下一次重连。\n 熔断 基于使用场景的压测数据，限制单实例 Pilot 同时可服务的 Sidecar 数量上限，超过熔断值的新连接会被Pilot 主动拒绝。\n 定期重置 为了实现负载均衡，对于已经存在的旧连接，应该怎么处理呢？我们选择了 Pilot 主动断开连接，不过断开连接的周期怎么定是个技术活。要考虑错开大促峰值，退避扩缩容窗口之类，这个具体值就不列出来了，大家按各自的业务场景来决定就好了。\n Sidecar 散列重连 最后还有一点是 Client 端的配合，我们会控制 Sidecar 重连 Pilot 时，采用退避式重试逻辑，避免对 DNS 和 Pilot 造成负载压力。\n性能优化 规模化的另一道难题是怎么保证服务的性能。在 Pilot 的场景，我们最关注的当然是配置下发的时效性了。性能优化离不开细节，其中部分优化是通用的，也有部分优化是面向业务场景定制的，接下来会分享下我们优化的一些细节点。\n 首次请求优化 社区方案里 Pilot 是通过 Pod.Status 来获取 Pod 的 IP 信息，在小集群的测试中，这个时间基本秒级内可以完成。然而在大集群生产环境中，我们发现 Status 的更新事件时间较慢，甚至出现超过 10s 以上的情况，而且延迟时间不稳定，会增加 Pilot 首次下发的时延。我们通过与基础设施 K8s 打通，由 PaaS 侧将 Pod 分配到的 IP 直接标记到Pod.Annotation 上，从而实现在第一次获取 Pod 事件时，就可以获取到 IP，将该环节的时延减少到0。\n 按需获取 \u0026amp;amp; Custom Resource 缓存 这是一个面向 DBMesh 业务场景的定制性优化，是基于按需获取的逻辑来实现的。其目的在于解决 DBMesh CR 数量过多，过大导致的性能问题，同时避免 Pilot 由于 List/Watch CR 资源导致 OOM 问题，Pilot 采用按需缓存和过期失效的策略来优化内存占用。  局部推送 社区方案中当 Pilot List/Watch 的资源发生变更时，会触发全部 Sidecar 的配置推送，这种方案在生产环境大规模集群下，性能开销是巨大的。举个具体例子，如果单个集群有 10W 以上的 Pod 数量，任何一个 Pod 的变更事件都会触发全部 Sidecar 的下发，这样的性能开销是不可接受的。\n优化的思路也比较简单，如果能够控制下发范围，那就可以将配置下发限制在需要感知变更的 Sidecar 范围里。为此，我们定义了 ScopeConfig CRD 用于描述各类资源信息与哪些 Pod 相关，这样 Pilot 就可以预先计算出配置变更的影响范围，然后只针对受影响的 Sidecar 推送配置。\n 其他优化 强管控能力是大促基本配备，我们给 Pilot Admin API 补充了一些额外能力，支持动态变更推送频率、推送限流、日志级别等功能。\n监控能力 安全生产的基本要求是要具备快速定位和及时止血能力，那么对于 Pilot 来说，我们需要关注的核心功能是配置下发能力，该能力有两个核心监控指标：\n 下发时效性 针对下发的时效性，我们在社区的基础上补充完善了部分下发性能指标，如下发的配置大小分布，下发时延等。\n 配置准确性 而对于配置准确性验证是相对比较复杂的，因为配置的准确性需要依赖 Sidecar 和 Pilot 的配置双方进行检验，因此我们在控制面里引入了 Inspector 组件，定位于配置巡检，版本扫描等运维相关功能模块。\n配置巡检的流程如下：\n Pilot 下发配置时，将配置的摘要信息与配置内容同步下发； MOSN 接收配置时，缓存新配置的摘要信息，并通过 Admin API 暴露查询接口； Inspector 基于控制面的 CR 和 Pod 等信息，计算出对应 MOSN 的配置摘要信息，然后请求 MOSN 接口，对比配置摘要信息是否一致； 由于 Sidecar 的数量较大，Inspector 在巡检时，支持基于不同的巡检策略执行。大体可以分为以下两类：\n 周期性自动巡检，一般使用抽样巡检； SRE 主动触发检查机制； Citadel 安全方案 证书方案 Sidecar 基于社区 SDS 方案 （Secret Discovery Service），支持证书动态发现和热更新能力。同时蚂蚁金服是一家金融科技公司，对安全有更高的要求，不使用 Citadel 的证书自签发能力，而是通过对接内部 KMS 系统获取证书。同时提供证书缓存和证书推送更新能力。\n我们先来看看架构图，请看图：\n对整 …","date":1577271600,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，聚焦控制面核心组件 Pilot 和 Citadel，分享蚂蚁金服双十一控制面如何管理并服务好全站 Sidecar。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f7e9ad6fafaa6db46864cf0704d2b145","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","publishdate":"2019-12-25T19:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","wordcount":3783},{"author":"徐迪、张晓宇","categories":null,"content":" 图为 KubeCon NA 2019 大会分享现场照\nSpeaker:\n 徐迪 蚂蚁金服技术专家：负责蚂蚁金融云PaaS平台建设，Kubernetes 社区老兵，核心代码库贡献量社区前50； 张晓宇 阿里云技术专家：负责阿里巴巴云原生应用容器平台的生态建设，主要设计和研发节点稳定性和资源利用率相关解决方案，同时也是 Kubernetes 社区热心的成员和贡献者。 本文根据徐迪和张晓宇在 KubeCon NA2019 大会分享整理。分享将会从以下几个方面进行切入：首先会简单介绍一下什么是 Sidecar 容器；其次，我们会分享几个蚂蚁金服和阿里巴巴集团的通用场景，以及我们是如何解决这些挑战的。当然，现在还是有很多的挑战需要后续继续解决，邀请大家与我们一同努力。\nSidecar 简介 Sidecar 容器并不是一个新鲜事物。它是一种设计模式，主要用来做一些辅助的工作，比如网络连通性、下载拷贝文件之类的事情；如果大家熟悉 Docker Swarm 的话，就会发现 Docker Ambassador 其实就是 Sidecar。\n看看如上这个例子，Service Consumer 和 Redis Provider 强耦合，部署在同一个节点上。如果这个时候，Redis Provider 出现问题，需要连接到另外一个 Redis 实例上，需要重新配置，并重启 Service Provider。\n那么在引入了 Ambassador 以后，问题变得相对简单些，只需要重启这里的 Redis Ambassador 即可，并不需要 Service Consumer 进行任何变动。\n当然这种模式，还可以进行跨节点通信，比如下图。这样 Service Consumer 和 Redis Provider 就可以部署在不同的节点上。在某种程度上，很容易地就将两种服务进行了解耦。\nSidecar 案例分享 Sidecar 容器能用来干什么？ 一般来讲，Sidecar 容器可以：\n 日志代理/转发，例如 fluentd； Service Mesh，比如 Istio，Linkerd； 代理，比如 Docker Ambassador； 探活：检查某些组件是不是正常工作； 其他辅助性的工作，比如拷贝文件，下载文件等； \u0026amp;hellip; 仅此而已？ 事实上，Sidecar 越来越被大家接受，并且使用越来越广泛。Sidecar 容器通常和业务容器（非 Sidecar 容器）部署在同一个 Pod 里，共享相同的生命周期，为业务容器提供辅助功能。这是一个非常好的模式，能够极大程度解耦应用，并且支持异构组件，降低技术壁垒。\n但目前 Kubernetes 对 Sidecar 的管理还不完善，越来越不满足我们的使用，尤其是在生产环境中使用 Sidecar。\n几个典型案例 1. 顺序依赖 假设我们在一个 Pod 内注入了多个 Sidecar，但是 Sidecar 之间或者 Sidecar 和业务容器之间有相互依赖关系。\n如下这个例子，我们需要先启动 proxy Sidecar 容器用于建立网络连接，这样 mysql client 才能连接到远端的 mysql 集群，并在本地暴露服务。而后主的业务容器才能正常工作。\n#1 proxy_container (sidecar) #2 mysql_client #3 svc_container 当然，有的人会觉得这个地方，可以通过诸如更改镜像启动脚本延迟启动等方法来解决。但是这些方法侵入性太强，不利于扩展，还很难进行准确的配置。\n2. Sidecar 管理 我们来看看另外一个案例。Sidecar 容器和业务容器耦合在同一个 Pod 内，共享相同的生命周期。因此，单独来管控 Sidecar 容器非常不方，比如更新 Sidecar 的镜像。\n比如，我们已经给很多 Pod 注入了 Istio Proxy 这样的 Sidecar 容器，目前运行状态良好。但是如果这个时候我们想升级这个 Proxy 镜像的话，该怎么办？\n如果按照 Istio 社区官方的文档，我们需要重新注入这些 Sidecar 容器。具体来说，需要删除原有 Pod，重新生成一份新的 Pod（有些 workload 关联的 Pod，会由相应的 workload 控制器自动生成）。\n那如果我们有很多个这样的 Pod 需要处理的话，怎么办？通过命令行的话，太不方便，而且容易出错。通过自己单独写的代码的话，可扩展性是个问题，需要频繁更改这些代码。\n而且这里还有另外一个问题，我们肯定不会一下子升级所有的 Sidecar，肯定要有个灰度的过程，也就是只升级一部分 Sidecar，这个时候又该怎么办呢？\n社区进展 上游社区 这里我们非常感谢 Joseph Irving (@Joseph-Irving) 提出了一个 Sidecar kep，通过定义 LifecycleType 来区分是否是 Sidecar 容器。\ntype Lifecycle struct { // Type // One of Standard, Sidecar. // Defaults to Standard // +optional Type LifecycleType `json:\u0026amp;quot;type,omitempty\u0026amp;quot; protobuf:\u0026amp;quot;bytes,3,opt,name=type,casttype=LifecycleType\u0026amp;quot;` } // LifecycleType describes the lifecycle behaviour of the container type LifecycleType string const ( // LifecycleTypeStandard is the default container lifecycle behaviour LifecycleTypeStandard LifecycleType = \u0026amp;quot;Standard\u0026amp;quot; // LifecycleTypeSidecar means that the container will start up before standard containers and be terminated after LifecycleTypeSidecar LifecycleType = \u0026amp;quot;Sidecar\u0026amp;quot; ) 未来只需要在 Pod Spec 中，按如下方式标记即可：\nname: sidecarContainer image: foo lifecycle: type: Sidecar Pod 内容器的启动顺序按照：初始化容器-\u0026amp;gt;Sidecar 容器-\u0026amp;gt;业务容器 的顺序依次启动。\n其中上述 kep 的 kubelet 端实现 正在进行中。\n为了支持 Sidecar 更多的使用场景，我们以此为基础提出了 PreSidecar 和 PostSidecar，分别用于在业务容器之前和之后启动。具体的使用场景见 我们的 PR。\n为什么我们觉得 Sidecar 应该区分前置和后置呢？\n这是因为在一些场景下， …","date":1577188800,"description":" 本文主要介绍了什么是 Sidecar 容器，蚂蚁金服和阿里巴巴集团的通用场景，以及我们是如何解决这些挑战的。","dir":"blog/sidacar-kubecon-na2019/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"db0769ed83607e39fba6020d4eba87b8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sidacar-kubecon-na2019/","publishdate":"2019-12-24T20:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sidacar-kubecon-na2019/","summary":"图为 KubeCon NA 2019 大会分享现场照 Speaker: 徐迪 蚂蚁金服技术专家：负责蚂蚁金融云PaaS平台建设，Kubernetes 社区老兵，核心代码库贡献量社区前50； 张","tags":["Sidecar 容器"],"title":" 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019","type":"blog","url":"/sofastack.tech/blog/sidacar-kubecon-na2019/","wordcount":2993},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@番番 提问：\n MOSN 的配置信息在哪里呢？\n A：MOSN 配置信息已更新到文档中：https://www.sofastack.tech/projects/sofa-mosn/configuration/overview/\n2、@古月 提问：\n 请问 SOFARPC 服务注册 ip 怎么使用主机 ip，不使用分配给容器的 ip？开发时调用容器内的服务调用不到，容器内的服务注册 ip 为 docker 分配的 ip。\n A：https://www.sofastack.tech/projects/sofa-rpc/application-rpc-config/ com.alipay.sofa.rpc.enabled.ip.range # 多网卡 ip 范围 com.alipay.sofa.rpc.bind.network.interface # 绑定网卡 可以通过网卡/ip段过滤；\nSOFARPC：https://github.com/sofastack/sofa-rpc\n SOFABoot 的服务运行在容器内，注册到注册中心的 ip 为容器的 ip，开发机器的调用不到。\n A：下面的两个参数，容器内端口映射到宿主机，virtual.host 用宿主机的去注册， com.alipay.sofa.rpc.virtual.host com.alipay.sofa.rpc.virtual.port\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@聂风 提问：\n SpringCloud 的项目怎么迁移到 SOFA 有这方面的教程文档吗？\n A：可以先参考下这个工程 https://github.com/sofastack/spring-cloud-sofastack-samples ，SOFAStack 集成 SpringCloud 的案例工程，不知道是不是对你有帮助。\n4、@周小斌 提问：\n Seata 以后会考虑集成分库分表和读写分离功能吗（无业务入侵的方式）？\n A：一般是分库分表组件内部中集成 Seata，负载均衡本质上是在切换数据源，一种是通过 DB URL 这种对外是个黑盒，Seata 不需要关注。另外一种是分库分表组件中使用配置中心做对等库物理库配置，这种需要通过 Resource 的 Group 来定义，比如我在一个节点上执行完一阶段，但是在进行二阶段的时候进行了主备切换，这时候需要在新主节点完成回滚。\n5、@温明磊 提问：\n Saga 项目开启时间长了后，会报 java.sql.SQLException: No operations allowed after statement closed. 这个错误。这个类 DbAndReportTcStateLogStore 方法 recordStateMachineStarted。\n A：是不是因为你的数据源连接池配置有问题呢？可能没有配置 testOnBorrow 或者 testOnReturn。\n 是没有。\n A：你配置一个 testOnBorrow。\n 那能不能在数据库连接的代码里判断，还是必须配置 testOnBorrow？Seata Saga 的数据库连接那代码处理异常。\n A：testOnBorrow 是数据源连接池的配置，和 Seata Saga 无关的，连接池你可以用任何连接池，比如 durid，dbcp。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服 ZSearch 在向量检索上的探索 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.8.0 版本，主要变更如下：\n 重构 futex 实现，增加 FUTEX_REQUEUE 支持 支持 SGX 远程证明 增加 sendmsg 和 recvmsg 系统调用 增加 gRPC demo 增加 Intel OpenVINO demo 增加 SGX 远程证明 demo 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.8.0\n2、发布 SOFABolt v1.6.1 版本，主要变更如下：\n 支持 SSL 支持 UserProcessor 生命周期的方法 支持用户自定义 SO_SND_BUF 和 SO_RCV_BUF 支持 RejectedException 的处理策略 优化了生命周期的检查，避免组件在关闭或启动前后仍然能够提供服务 优化了 DefaultConnectionManager 的构造方法以及其它的部分代码 修复 DefaultConnectionManager#check(Connection) 异常信息不完整的问题 修复 AbstractLifeCycle 启动/关闭的并发问题 详细发布报告： https://github.com/sofastack/sofa-bolt/releases/tag/v1.6.1\n社区活动预告 下周六 Service Mesh Meetup 第9期杭州站来啦，本期与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。欢迎参加~\n主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond\n时间：2019年12月28日（下周六）13:00-17:30\n地点：杭州西湖区紫霞路西溪谷G座8楼\n报名方式：点击“这里”，即可报名\n","date":1576825200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191220/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c9e61e735545e48bd341dd6da7310440","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191220/","publishdate":"2019-12-20T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191220/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 配置文档、SOFABolt 等组件发布、社区活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191220/","wordcount":1781},{"author":"十倍","categories":null,"content":" 图为 ZSearch 基础架构负责人十倍 2019 Elastic Dev Day 现场分享\n引言 ElasticSearch（简称 ES）是一个非常受欢迎的分布式全文检索系统，常用于数据分析，搜索，多维过滤等场景。蚂蚁金服从2017年开始向内部业务方提供 ElasticSearch 服务，我们在蚂蚁金服的金融级场景下，总结了不少经验，此次主要给大家分享我们在向量检索上的探索。\nElasticSearch 的痛点 ElasticSearch 广泛应用于蚂蚁金服内部的日志分析、多维分析、搜索等场景。当我们的 ElasticSearch 集群越来越多，用户场景越来越丰富，我们会面临越来越多的痛点：\n 如何管理集群； 如何方便用户接入和管理用户； 如何支持用户不同的个性化需求； \u0026amp;hellip; 为了解决这些痛点，我们开发了 ZSearch 通用搜索平台：\n 基于 K8s 底座，快速创建 ZSearch 组件，快捷运维，故障机自动替换； 跨机房复制，重要业务方高保； 插件平台，用户自定义插件热加载； SmartSearch 简化用户搜索，开箱即用； Router 配合 ES 内部多租户插件，提高资源利用率； 向量检索需求 基于 ElasticSearch 的通用搜索平台 ZSearch 日趋完善，用户越来越多，场景更加丰富。\n随着业务的飞速发展，对于搜索的需求也会增加，比如：搜索图片、语音、相似向量。\n为了解决这个需求，我们是加入一个向量检索引擎还是扩展 ElasticSearch 的能力使其支持向量检索呢？\n我们选择了后者，因为这样我们可以更方便的利用 ElasticSearch 良好的插件规范、丰富的查询函数、分布式可扩展的能力。\n接下来，我来给大家介绍向量检索的基本概念和我们在这上面的实践。\n向量检索基本概念 向量从表现形式上就是一个一维数组。我们需要解决的问题是使用下面的公式度量距离寻找最相似的 K 个向量。\n 欧式距离： 两点间的真实距离，值越小，说明距离越近； 余弦距离： 就是两个向量围成夹角的 cosine 值，cosine 值越大，越相似； 汉明距离： 一般作用于二值化向量，二值化的意思是向量的每一列只有0或者1两种取值。 汉明距离的值就两个向量每列数值的异或和，值越小说明越相似，一般用于图片识别； 杰卡德相似系数： 把向量作为一个集合，所以它可以不仅仅是数字代表，也可以是其他编码，比如词，该值越大说明越相似，一般用于相似语句识别； 因为向量检索场景的向量都是维度很高的，比如256，512位等，计算量很大，所以接下来介绍相应的算法去实现 topN 的相似度召回。\n向量检索算法 KNN 算法 KNN 算法表示的是准确的召回 topK 的向量，这里主要有两种算法，一种是 KDTtree，一种是 Brute Force。我们首先分析了 KDTree 的算法，发现 KDTree 并不适合高维向量召回，于是我们实现的 ES 的 Brute Force 插件，并使用了一些 Java 技巧进行加速运算。\nKDTree 算法 简单来讲，就是把数据按照平面分割，并构造二叉树代表这种分割，在检索的时候，可以通过剪枝减少搜索次数。\n构建树\n以二维平面点(x,y)的集合(2,3)，(5,4)，(9,6)，(4,7)，(8,1)，(7,2)为例：\n图片来源\n 按照 x 排序，确定中间值7，其他坐标分两边； 第二层按照 y 排序，第三层按照 x 排序； 并且在构建时维护每个节点中的 x 最大最小，y 最大最小四个值； 查找最近点\n图片来源\n搜索(3,5)的最近邻：\n 到根节点距离为5； 遍历到右节点(9,6)，发现整棵右子树的x轴，最小值是8，所以所有右子树的节点到查询节点的距离一定都大于8-3=5，于是所有右子树的节点都不需要遍历； 同理，在左子树，跟(5，4)节点比较，(7,2)被排除； 遍历完(2,3),(4,7)，最近点(5,4) 返回； 结论 Lucene 中实现了 BKDTree，可以理解为分块的 KDTree，并且从源码中可以看到 MAX_DIMS = 8，因为 KDTree 的查询复杂度为 O(kn^((k-1)/k))，k 表示维度，n 表示数据量。说明 k 越大，复杂度越接近于线性，所以它并不适合高维向量召回。\nBrute Force 顾名思义，就是暴力比对每一条向量的距离，我们使用 BinaryDocValues 实现了 ES 上的 BF 插件。更进一步，我们要加速计算，所以使用了 JAVA Vector API 。JAVA Vector API 是在 openJDK project Panama 项目中的，它使用了 SIMD 指令优化。\n结论 使用 avx2 指令优化，100w 的 256 维向量，单分片比对，RT 在 260ms，是常规 BF 的 1/6。 ElasticSearch 官方在7.3版本也发布了向量检索功能，底层也是基于 Lucene 的 BinaryDocValues，并且它还集成入了 painless 语法中，使用起来更加灵活。\nANN 算法 可以看到 KNN 的算法会随着数据的增长，时间复杂度也是线性增长。例如在推荐场景中，需要更快的响应时间，允许损失一些召回率。\nANN 的意思就是近似 K 邻近，不一定会召回全部的最近点。ANN 的算法较多，有开源的 ES ANN 插件实现的包括以下这些：\n 基于 Hash 的 LSH； 基于编码的 IVFPQ； 基于图的 HNSW； ZSearch 依据自己的业务场景也开发了 ANN 插件（适配达摩院 Proxima 向量检索引擎的 HNSW 算法）。\nLSH 算法 Local Sensitive Hashing 局部敏感 hash，我们可以把向量通过平面分割做 hash。例如下面图例，0表示点在平面的左侧，1表示点在平面的右侧，然后对向量进行多次 hash，可以看到 hash 值相同的点都比较靠近，所以在 hash 以后，我们只需要计算 hash 值类似的向量，就能较准确的召回 topK。\nIVF-PQ 算法 PQ 是一种编码，例如图中的128维向量，先把向量分成4份，对每一份数据做 kmeans 聚类，每份聚类出256个聚类中心，这样，原始向量就可以使用聚类中心的编号重新编码，可以看出，现在表示一个向量，只需要用4个字节就行。然后当然要记录下聚类中心的向量，它被称之为码本。\n图片来源\nPQ 编码压缩后，要取得好的效果，查询量还是很大，所以前面可以加一层粗过滤，如图，把向量先用 kmeans 聚类成1024个类中心，构成倒排索引，并且计算出每个原始向量与其中心的残差后，对这个残差数据集进行 PQ 量化。用 PQ 处理残差，而不是原始数据的原因是残差的方差能量比原始数据的方差能量要小。\n这样在查询的时候，我们先找出查询出靠近查询向量的几个中心点，然后再在这些中心点中去计算 PQ 量化后的 top 向量，最后把过滤出来的向量再做一次精确计算，返回 topN 结果。\n图片来源\nHNSW 算法 讲 HNSW 算法之前，我们先来讲 NSW 算法，如下图，它是一个顺序构建图流程：\n 例如第5次构造 D …","date":1576670400,"description":" 本文整理自 2019 Elastic Dev Day 现场分享，主要给大家分享蚂蚁金服在向量检索上的探索。","dir":"blog/antfin-zsearch-vector-search/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"194a0b7104c5147b2fd54e8c74b17e22","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-zsearch-vector-search/","publishdate":"2019-12-18T20:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/antfin-zsearch-vector-search/","summary":"图为 ZSearch 基础架构负责人十倍 2019 Elastic Dev Day 现场分享 引言 ElasticSearch（简称 ES）是一个非常受欢迎的分布式全文检索系统，常用于数据分析，搜索","tags":["ZSearch"],"title":" 蚂蚁金服 ZSearch 在向量检索上的探索","type":"blog","url":"/sofastack.tech/blog/antfin-zsearch-vector-search/","wordcount":4634},{"author":"应明","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第六篇 - Operator 篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 是蚂蚁金服下一代技术架构的核心，也是蚂蚁金服内部双十一应用云化的重要一环，本文主要分享在蚂蚁金服当前的体量下，如何支撑应用从现有微服务体系大规模演进到 Service Mesh 架构并平稳落地。\n本文作者：杜宏伟（花名：应明），蚂蚁金服技术专家，关注 API 网关，Service Mesh 和容器网络，蚂蚁金服 Service Mesh 核心成员。\n为什么需要 Service Mesh 在此之前，SOFAStack 作为蚂蚁金服微服务体系下服务治理的核心技术栈，通过提供 Cloud Engine 应用容器、SOFABoot 编程框架（已开源）、SOFARPC（已开源） 等中间件，来实现服务发现和流量管控等能力。经过若干年的严苛金融场景的锤炼，SOFAStack 已经具备极高的可靠性和可扩展性，通过开源共建，也已形成了良好的社区生态，能够与其他开源组件相互替换和集成。在研发迭代上，中间件类库已经与业务解耦，不过避免不了的是，运行时两者在同一个进程内，意味着基础库的升级需要推动业务方升级对应的中间件版本。\n我们一直在探索更好的技术实现方式。我们发现，Service Mesh 通过将原先通过类库形式提供的服务治理能力进行提炼和优化后，下沉到与业务进程协同，但独立运行的 Sidecar Proxy 进程中，大量的 Sidecar Proxy 构成了一张规模庞大的服务网络，为业务提供一致的，高质量的用户体验的同时，也实现了服务治理能力在业务无感的条件下独立进行版本迭代的目标。\n应用 Service Mesh 的挑战 Service Mesh 带给我们的能力很美好，但现实为我们带来的挑战同样很多。比方说数据面技术选型和私有协议支持，控制面与蚂蚁金服内部现有系统对接，配套监控运维体系建设，以及在调用链路增加两跳的情况下如何优化请求延迟和资源使用率等等。\n本文着重从 MOSN（Sidecar Proxy）的运维和风险管控方面，分享我们的实践经验，其他方面的挑战及应对方案，请参考系列分享中的其他文章。\nMOSN：https://github.com/sofastack/sofa-mosn\nSidecar 注入 创建注入 已经完成容器化改造，运行在 Kubernetes 中的应用，如何接入到 Service Mesh 体系中？最简单的方式，也是以 Istio 为代表的 Service Mesh 社区方案所采用的方式，即是在应用发布阶段，通过 mutating webhook 拦截 Pod 创建请求，在原始 Pod Spec 的基础上，为 Pod 注入一个新的 MOSN 容器。\n值得注意的是，在资源分配上，起初我们依据经验值，在应用 8G 内存的场景下，为 Sidecar 分配 512M 内存，即：\nApp: req=8G, limit=8G Sidecar: req=512M, limit=512M\n很快我们就发现了这种分配方案带来的问题，一方面部分流量比较高的应用的 MOSN 容器，出现了严重的内存不足甚至 OOM；另一方面注入进去的 Sidecar 容器额外向调度器申请了一部分内存资源，这部分资源脱离了业务的 quota 管控。\n因此，为了消除内存 OOM 风险和避免业务资源容量规划上的偏差，我们制定了新的“共享内存”策略。在这个策略下，Sidecar 的内存 request 被置为0，不再向调度器额外申请资源；同时 limit 被设置为应用的 1/4，保障 Sidecar 在正常运行的情况下，有充足的内存可用。为了确实达到“共享”的效果，蚂蚁金服 sigma 团队针对 kubelet 做了调整，使之在设置 Sidecar 容器 cgroups limit 为应用 1\u0026amp;frasl;4 的同时，保证整个 Pod 的 limit 没有额外增加（细节这里不展开）。\n当然，Sidecar 与应用“共享”分配到的内存资源，也导致了在异常情况（比如内存泄露）下，sidecar 跟应用抢内存资源的风险。如何应对这个风险？我们的做法是，通过扩展 Pod Spec（及相应的 apiserver, kubelet 链路），我们为 Sidecar 容器额外设置了 Linux oom_score_adj 这个属性，以保障在内存耗尽的情况下，Sidecar 容器会被 OOM Killer 更优先选中，以发挥 sidecar 比应用能够更快速重启，从而更快恢复到正常服务的优势。\n此外，在 CPU 资源的分配上，我们也遇到过在一些场景下，MOSN 抢占不到 CPU 资源从而导致请求延迟大幅抖动，解决方案是确保在注入 Sidecar 时，根据 Pod 内的容器数量，为每个 Sidecar 容器计算出相应的 cpushare 权重，并通过工具扫描并修复全站所有未正确设置的 Pod。\n原地注入 在创建 Pod 的时候注入 Sidecar，是一件相对比较“舒服“的接入方式，因为这种做法，操作起来相对比较简单，应用只需先扩容，再缩容，就可以逐步用带有 Sidecar 的 Pod，替换掉旧的没有 Sidecar 的 Pod。可问题是，在大量应用，大规模接入的时候，需要集群有较大的资源 buffer 来供应用实例进行滚动替换，否则替换过程将变得十分艰难且漫长。而蚂蚁金服走向云原生的目标之一则是，双十一大促不加机器，提高机器使用率。如果说我们要花更多的钱购买更多的机器来支持云原生，就多少有点事与愿违了。\n为了解决这个问题，我们提出了“原地注入”的概念，也就是说在 Pod 不销毁，不重建的情况下，原地把 Sidecar 注入进去。\n如图所示，原地注入由以下步骤构成：\n 在 PaaS 提交工单，选择一批需要原地注入的 Pod； PaaS 调用中间件接口，关闭业务流量并停止应用容器； PaaS 以 annotation 的形式打开 Pod 上的原地注入开关； Operator 观察到 Pod 原地注入开关打开，渲染 sidecar 模版，注入到 Pod 中并调整 cpu/memory 等参数； Operator 将 Pod 内容器期望状态置为运行； kubelet 将 Pod 内容器重新拉起； PaaS 调用中间件接口，打开业务流量； Sidecar 升级 我们将 RPC 等能力从基础库下沉到 Sidecar 之后，基础库升级与业务绑定的问题虽然消除了，但是这部分能力的迭代需求依然存在，只是从升级基础库变成了如何升级 Sidecar。\n最简单的升级就是替换，即销毁 Pod 重新创建出一个新的，这样新建出来的 Pod 所注入的 Sidecar 自然就是新版本了。但通过替换的升级方式，与创建注入存在相似的问题，就是需要大量的资源 buffer，并且，这种升级方式对业务的影响最大，也最慢。\n非平滑升级 为了避免销毁重建 Pod，我们通过 Operator 实现了“非平滑升级” …","date":1576501200,"description":" 本文着重从 MOSN（Sidecar Proxy）的运维和风险管控方面，分享我们的实践经验。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3528d4d6bd82bd170eccd20d98f5f7e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","publishdate":"2019-12-16T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第六篇 - Operator 篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模","tags":["Service mesh","Service Mesh 落地实践"],"title":" 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","wordcount":3725},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@温明磊 提问：\n 我用的 ShardingSqhere 分库分表，按照各个业务方分库。\u0026amp;gt; 所以我们项目里所有分库的表都带了业务方字段biz_code，这个字段的值也就是虚库的名字，都是写在配置里的。 A：从你的需求看，比较简单只是需要按业务方进行分库，而 biz_code 不在状态机日志表的字段里，你可以考虑先算好分库位，然后用 ShadingJDBC 的 hint 功能来设置分库位即可。\n A：我看了一下 ShardingJDBC 也是用的 ThreadLocal 来设置 hint：https://shardingsphere.apache.org/document/current/cn/manual/sharding-jdbc/usage/hint/\n ShadingJDBC 的 hint 功能是基于 ThreadLocal 的，Saga 异步的方式不能用 sharding jdbc 的吗?\n A：有一个优雅的办法：你实现 StateLogStore 接口，然后代理 Seata Saga 的DbAndReportTcStateLogStore，在每个方法前后加上：hintManager.addDatabaseShardingValue();、hintManager.close()，这样就和同步异步没有关系了，因为设置 hint 和 sql 执行都在同一个线程。\n另外，DbAndReportTcStateLogStore 如何传到你自己实现的 StateLogStore 里，你需要继承 DbStateMachineConfig，然后在 afterProperties 方法，先调 super.afterProperties 方法，然后 getStateLogStore()，传入你自己实现的 StateLogStore 里，然后把自己实现的 StateLogStore 调 setStateLogStore 覆盖。\n2、@Purge yao 提问：\n Saga 状态机在线设计器： http://seata.io/saga_designer/index.html 这个状态机可以让流程引擎用吗？\n A：不可以当工作流用，没有人工节点。\n Seata 用这个流程是干嘛用的？\n A：事实上 Seata Saga 模式 是一个具备“服务编排”和“Saga 分布式事务”能力的产品，总结下来它的适用场景是：\n 适用于微服务架构下的“长事务”处理； 适用于微服务架构下的“服务编排”需求； 适用于金融核心系统以上的有大量组合服务的业务系统（比如在渠道层、产品层、集成层的系统）； 适用于业务流程中需要集成遗留系统或外部机构提供的服务的场景（这些服务不可变不能对其提出改造要求）。 Seata：https://github.com/seata/seata\n3、@anorqiu9 提问：\n 关于 MOSN 我们目前遇到一个架构方面的问题，就是原基于 Dubbo 的服务和现在基于 Spring Cloud 的服务互调如何做？一种方案设计服务同时开启两个服务框架的服务接口为两个框架的服务同时提供服务;另一种方案是异构系统基于网关交互.这两种方案有什么优缺点？大家有没有碰到过类似的场景，是如何处理的？谢谢！\n A：Dubbo 和 Spring Cloud 互相调用，需要使用的是 http 接口来调用，个人推荐用网关来做交互，这样 API 的管理上更方便，当然也可以通过 Sidecar 来解决。\n 是的，我也倾向于网关交互，由网关完成协议的转换，进行包括流量控制、安全访问控制等在内的 API 管理工作。如果一个服务同时处于两种服务框架治理之下，就意味着对这个服务的治理（如限流、熔断及安全访问等）必须在两个地方进行，这将会是一个挑战。 当然，如果使用 Service Mesh 架构，通过 Sidecar 如 MOSN 来实现多 RPC 协议的支持，同时又能通过 Service Mesh 的控制平面实现服务治理的统一，这样就不存在上述说的挑战。 MOSN：https://github.com/sofastack/sofa-mosn\n 本周推荐阅读 蚂蚁金服 DB Mesh 的探索与实践 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布SOFARPC v5.6.3，主要变更如下：\n 试验性支持 grpc； 试验性支持 H2 的 tls； 序列化方式支持 msgpack； 修复直接通过线程上下文指定的地址调用； 扩展加载过程日志改为 debug，防止错误信息过多； 升级 jackson 和 netty 的小版本； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.3\n2、发布 SOFAArk v1.1.0，主要变更如下：\n 支持在 Biz 中使用 Ark 扩展点机制； 修复遗漏处理加载 ark spi 类资源 bug； 提供全新的biz/plugin 生命周期事件； 优化SOFAArk 自身日志输出； 优化 SOFAArk 与 SOFABoot 日志依赖管控； telnet 服务支持退出指令； 升级 netty 版本到 4.1.42.Final； 迁移 sofa-ark-samples 到 https://github.com/sofastack-guides/sofa-ark-samples 详细发布报告： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.0\n3、发布 SOFABoot v3.2.1，主要变更如下：\n 版本升级： …","date":1576220400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191213/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"37b96cc1a849775521b4d2b78d6602ce","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191213/","publishdate":"2019-12-13T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191213/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"活动报名、本周 QA、组件发布 | SOFA Weekly","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191213/","wordcount":2258},{"author":"潘潘","categories":"Service Mesh","content":" 概要 活动主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond 活动时间：时间：2019 年 12 月 28 日（周六）13:00-17:30 活动地点：杭州西湖区紫霞路西溪谷G座8楼 活动形式：线下活动 活动回顾：请戳这里 活动介绍 关于 Service Mesh\n服务网格（Service Mesh）是致力于解决服务间通讯的基础设施层。它负责在现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，Service Mesh 通常是通过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一起来实现，而无需感知应用程序本身。\n关于 ServiceMesher 社区\nServiceMesher 社区，专注于 Service Mesh 和云原生技术，立足开源，分享技术资讯和实践，致力于新技术的推广和普及。\nService Mesh Meetup #9 杭州站\nService Mesh Meetup 是由蚂蚁金服联合 CNCF 官方共同出品，ServiceMesher 社区主办，主题围绕服务网格、Kubernetes 及云原生，在全国各地循环举办的技术沙龙。\n本期 Meetup 与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。\n活动议程 时间 环节（分享主题） 分享嘉宾 13:00-13:30 签到 13:30-14:15 《蚂蚁金服 API Gateway Mesh 的思考与实践》 贾岛 蚂蚁金服 高级技术专家 14:15-15:00 《酷家乐的 Istio 与 Knative 踩坑实录》 付铖 酷家乐 容器化负责人 15:00-15:10 MOSN 社区化发布 涵畅 15:10-15:20 茶歇 15:20-16:00 圆桌环节-《Service Mesh 落地的务实与创新》 鲁直 16:00-16:45 《蚂蚁金服 Service Mesh 技术风险思考和实践》 嘉祁 蚂蚁金服 技术专家 16:45-17:30 《网易严选的 Service Mesh 实践》 王国云 网易严选 架构师 本期议题以及嘉宾详解 13:30-14:15《蚂蚁金服 API Gateway Mesh 的思考与实践》\n 讲师：贾岛 蚂蚁金服 高级技术专家 讲师介绍：靳文祥（花名贾岛），2011年毕业后加入支付宝无线团队，一直从事移动网络接入、API 网关、微服务等相关的研发工作，目前负责蚂蚁金服移动网络接入架构设计与优化。 Topic 介绍：在 Service Mesh 微服务架构中，我们常常会听到东西流量和南北流量两个术语。蚂蚁金服开源的Service Mesh Sidecar MOSN 已经多次与大家见面交流了，以往的议题重点在东西流量的服务发现与路由，那么蚂蚁金服在南北流量上的思考是怎样的？本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的，解决了什么问题，双十一的实践表现，以及我们对未来的思考。 14:15-15:00《酷家乐的 Istio 与 Knative 踩坑实录》\n 讲师：付铖 酷家乐 技术专家 讲师介绍：先后负责酷家乐户型图, 渲染引擎等模块，目前负责酷家乐国际站的研发。在业务开发过程中推动和布道云原生技术，并在部分业务落地了 Istio 服务治理和基于 Knative 的 Serverless 基础设施。 Topic 介绍：酷家乐在部分业务模块，自2018年使用了 Istio 进行服务治理，自2019年使用了 Knative 作为 FaaS 基础设施，在实践过程中解决了大量问题，也积累了不少第一手经验。本次分享，将重点讨论服务网格的性能损耗，存量业务迁移难题，函数计算的冷启动时间问题以及解决方案等。 15:20-16:00 圆桌环节《Service Mesh 落地的务实与创新》\n 主持人：鲁直 蚂蚁金服云原生落地负责人 嘉宾： 涵畅 蚂蚁金服高级技术专家 张超盟 华为云微服务平台架构师 付铖 酷家乐技术专家 王国云 网易严选架构师 16:00-16:45《蚂蚁金服 Service Mesh 技术风险思考和实践》\n 讲师：嘉祁 蚂蚁金服 技术专家 讲师介绍：黄家琦（花名：嘉祁）2012年毕业后加入阿里巴巴技术保障，2015年转入蚂蚁金服SRE，长期从事稳定性相关工作，当前重点关注于中间件，Service Mesh 与云原生基础设施的稳定性。 Topic 介绍：Servish Mesh 是微服务架构与云原生碰撞出的火花，对于传统的中间件体系与运维支撑能力是极大的挑战。本次分享的主题主要关注于在蚂蚁金服内部如何应对这些挑战，并建设相应的技术风险能力来保障其稳定。 16:45-17:30《网易严选的 Service Mesh 实践》\n 讲师：王国云 网易高级技术专家、网易严选架构师 讲师介绍：2008年加入网易，长期从事一线的研发与管理工作，曾参与或负责过网易博客、网易邮箱、网易有钱等多个核心产品的研发工作，擅长服务端架构及技术体系建设，现任严选支持业务研发部技术负责人，负责严选的容器化及 Service Mesh 演进。 Topic 介绍：网易严选在2016年选择了 Service Mesh 作为未来微服务改造的基础架构，并在过去几年支持了业务的持续快速增长。本次分享主要介绍 Service Mesh 在严选的落地和演进情况，讨论 Service Mesh 在混合云架构下落地遇到的挑战和我们的解决方案，同时也希望和大家交流一下在架构方面的一些思考。 加入 SOFA 钉钉互动群 群号：23390449，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n主办方与合作伙伴 主办方：CNCF、ServiceMesher 协办方：蚂蚁金服、SOFAStack、滴滴 合作伙伴：掘金社区、开源中国、养码场、SegmentFault、麦思博、开源社 ","date":1576051200,"description":"本次 Meetup 与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。","dir":"activities/service-mesh-meetup-9/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a7103ed15ed823b9156082c37b7d464a","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-meetup-9/","publishdate":"2019-12-11T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/service-mesh-meetup-9/","summary":"概要 活动主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond 活动时间：时间：2019 年 12 月 28 日（周六）13:00-17:30 活动地点：杭州西湖区紫霞路","tags":["Meetup","Service Mesh"],"title":"Service Mesh Meetup#9 杭州站：To Infinity and Beyond","type":"activities","url":"/sofastack.tech/activities/service-mesh-meetup-9/","wordcount":1855},{"author":"改之","categories":"Service mesh","content":" 蚂蚁金服数据访问层有三个核心组件：数据访问框架 ZDAL、数据访问代理 DBP 和 OceanBase 代理服务器 OBProxy。本篇主要涉及 ZDAL 和 OBProxy 两个组件。ZDAL 作为全站数据访问的标准组件，不仅提供了分库分表、读写分离、分布式 Sequence等标准的应用能力，还提供了链路跟踪、影子压测、单元化、容灾切换等技术风险能力 。OBProxy 作为 OceanBase 的访问入口，提供了 OceanBase 路由寻址、读写分离等数据库能力，同时从执行效率和资源成本角度考虑，从 OBProxy 诞生那天我们就采用了近应用的独立进程部署模式，目前生产环境上保持在几十万级别的进程数。\n本篇文章通过介绍当前蚂蚁金服数据访问层遇到的问题，解决的思路，演进的方向三个方面，期望能够用阐述下 DB Mesh 发展的一些思考并让更多同学认识到 DB Mesh。期望能够 DB Mesh 的方式将数据访问层下沉到统一的基础设施之上，让新业务快速使用上全站多年的技术风险能力，并能够持续享受到更多的性能、资源等技术红利。\n背景 随着业务的快速发展，ZDAL 作为客户端模式的组件，一直存在业务耦合、版本迭代推进、多语言支持等问题。OBProxy 是为 OceanBase 数据库专门量身定制的代理服务器，天然就是业务无耦合、支持多语言。用户的数据在 OceanBase 上以多副本的形式存放在各个 OBServer 上，OBProxy 则负责接收用户发过来的 SQL 请求，解析 SQL 请求并计算分区信息后，将用户请求转发到最佳目标 OBServer 上，并将执行结果给用户。在蚂蚁金服内部也存在分库分表组件 ZDAL，用在多 OceanBase 集群以及单元化的场景。两者配合使用，分库分表组件 ZDAL 做业务层的流量调拨，OceanBase 分区功能支持数据库的水平扩容能力。\n我们进一步看 ZDAL 和 OBProxy 这两个组件的核心逻辑。\nZDAL 的核心逻辑：\n SQL 解析器：获得表名及分库分表字段； 规则引擎：计算分库分表结果； 执行层：将 SQL 改写发给数据库，并做结果集合并用户； OBProxy 的核心逻辑：\n 协议解析器：解析协议中的 SQL，Parse 后获得表名及分区字段； 路由器：计算分区表所在的 OBServer； IO 层：将请求转发给 OBServer，将结果集返回给客户端； 可以看出，OBProxy 和 ZDAL 这两个组件的执行路径有一定的重复度，比如两个组件都做了 SQL 解析，并分析表名和字段。这对性能带来一定的损耗，而且这种重复给研发迭代带来更多的工作量。\n基于前面的考虑将 ZDAL 和 OBProxy 两者合并成一个组件的是一个自然的方案，通过将 ZDAL 逻辑下沉到 OBProxy 中，让 OBProxy 提供了分库分表、读写分离、分布式序列等中间件能力，这个组件我们命名为 ODP（Open Database Proxy）。\nODP 作为近业务端部署的进程，虽然逻辑独立出来，升级时但是依然需要去改动业务的容器，所以迭代过程中的升级推进工作也是比较费时费力，而且 ODP 只是整个产品的冰山一角，需要大量的精力来构建冰山之下的基础设施，比如说如何解决 ODP 的运维问题、用户透明切换的方案、复杂配置的推送问题、金融级数据库密钥管理问题等。我们发现这部分与蚂蚁金服内部大规模实践的 ServiceMesh 遇到的问题有比较大的重合度，所以与 ServiceMesh 一起共建底层基础设施，为这块的完整产品方案命名为 DBMesh。下文会简单介绍一下我们的演进路线和发展方向。\n解决思路 Sidecar 模式以解耦部署 从执行效率和资源成本角度考虑，OBProxy 在蚂蚁金服一直都在采用近业务端部署的方式，日常保有的服务数在数十万的级别。近业务端部署虽然提供了高效率，但是也带来了运维上的复杂度，同时需要升级版本时，也需要和通知业务一起来做发布和升级。要让单个应用升级，基本都是按月计，如果涉及到全站层面的升级，时间基本不太好估算。\n但是随着云原生以及 Kubernetes 的发展，让 Sidecar 模式更为成熟，即在业务的容器旁边再运行一个容器，这个非常贴合我们近业务端部署的 OBProxy 进程，只需要将 OBProxy 进程改造成 OBProxy Sidecar，即可进行独立升级、发布、运维等。同时蚂蚁金服在云原生领域有非常深的实践，有着世界上最大规模的 Kubernetes 集群和 ServiceMesh 集群，将 OBProxy 变成 Sidecar 也是比较合理和方便实施的了。\n今年双十一切了约 10% 的数万个的 PODs 到 ODP Sidecar 模式，通过 Sidecar 的方式能够让业务快速享受到基础软件迭代的好处，本次双十一 ODP 修复了一个非预期日志打印导致某个机房出现慢 SQL 问题，在传统的本地进程方式，需要推动所有的业务进行拉迭代、发布、打包时间周期基本不太可控。而今年让所有涉及应用独立的灰度、升级仅花费两天时间。\n合并重复逻辑拿技术红利 解决了部署模式的问题，通过快速迭代并且独立升级的方式，才能让功能下沉的落地成为可能。我们将分库分表组件的大多数功能都下沉到了 ODP 上，比如：分库分表功能、读写分离功能、分布式 Sequence 功能、全链路跟踪等。如下图：\n整个分库分表组件功能下沉之后，在今年双十一我们在核心系统上线，拿到了一些非常可观的技术红利：\n 性能提升：通过功能的合并可以省去额外的 SQL 解析和路由计算过程，双十一上线的系统 SQL 平均响应时间可以下降上百微秒； 启动速度：应用只需要和 ODP 建立连接即可，无需初始化多个分库的数据源，初始化时间从数十秒降到数十毫秒； 内存下降：和启动速度一样，由于应用和 ODP 的连接数减少了，同样也可以节省应用端的内存使用，生产上能够下降上百 MB； 共建 Mesh 基础设施完善技术风险 研发同学会将更多的关注点放在 ODP 数据链路上，如何提高数据平面的性能，如何增加更多的 SQL 特性，而会忽略非 SQL 执行链路上的诉求。DBMesh 作为应用侧的基础设施，更多的要考虑如何更好的管理 Sidecar、数据访问高安全防控、满足配置变更的三板斧要求、最大程度的节省资源成本等。\n我们在与蚂蚁金服 ServiceMesh 团队共建整个云原生下 Mesh 的技术风险能力，优先完善 Sidecar 的运维能力和变更三板斧能力，后续会将 ODP Sidecar 部署到宿主机上以最大程度优化 ODP 的资源占用，也会逐步下沉更多如影子压测、灰度机房、流量镜像等的技术风险能力。\n总结 DBMesh 让数据访问从客户端模式切换到代理模式，给应用带来了启动速度的极大优化。Sidecar 的部署模式则是 SQL 平均响应时间、资源利用的最优模式。将更多的技术风险能力沉淀进来，让新应用快速享受到金融级的技术风险能力，存量应用的技术风险指标更完善。我们期望通过统一的数据访问基础设施，让业务都使用标准的技术组件，降低学习以及维护成本，仅专注在业务开发和创新上。\n作者介绍 易鸿伟（花名：改 …","date":1575982800,"description":" 本篇文章通过介绍当前蚂蚁金服数据访问层遇到的问题，解决的思路，演进的方向三个方面，期望能够用阐述下 DB Mesh 发展的一些思考并让更多同学认识到 DB Mesh。","dir":"blog/ant-financial-db-mesh-explore-practice/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9732786e2e2be0688d1e6a594838f87e","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","publishdate":"2019-12-10T21:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","summary":"蚂蚁金服数据访问层有三个核心组件：数据访问框架 ZDAL、数据访问代理 DBP 和 OceanBase 代理服务器 OBProxy。本篇主要涉及 ZDAL 和 OBProxy 两个组件。ZDAL 作为","tags":["Service mesh","DB Mesh"],"title":"蚂蚁金服 DB Mesh 的演进之路","type":"blog","url":"/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","wordcount":2561},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@温明磊 提问：\n 我们还是想用 redis 存状态机上下文一个大的实体，输入输出只放 id，我想问下，redis 宕机或者其它情况下，状态机 redis 宕机节点之前的节点都是幂等可重复的，那我怎样让它重新跑一边状态机？只能人工干预吗？\n A：你的意思是因为参数没有了，所以你想重跑状态机回放参数？\n 是的。从最开始跑，因为之前的节点幂等， 也没有变更数据，或者数据已经被 catch 住然后补偿了。\n A：我理解是你可以新启动一个状态机事例，把之前的生成的 id 传进上下文，这样和从新开始没有区别吧？不然你人工处理的话，需要把 state_inst 表里的数据删除。\n 嗯 ，我明白 ，通过定时就可以，因为在状态机开始之前 数据已经落库了。redis 宕机捕获异常后，可以给最开始的数据设置状态，然后定时开启状态机。但是 Saga 确实不能帮我完成定时重启状态机这个事情对吧，或者我就设置个补偿节点，专门用来重启新状态机实例的？这样可以？\n A：我建议是不要搞个补偿节点来处理非补偿的事，我觉得可以自己做个定时任务，然后处理这种情况。\nSeata：https://github.com/seata/seata\n2、@李林 提问：\n 数据面默认是能感知到所有服务的变更么？\n A：是的，因为对接了 SOFARegistry。\n 那当集群规模比较大的时候，是不是会出现感知较慢的情况呢？\n A：SOFARegistry 里有全量的服务订阅信息，MOSN 和 SOFARegistry 对接只会感知当前 MOSN 必须的服务信息，所以 MOSN 内的数据总量不会很大。\n Istio 控制面占用的资源比较多，MOSN 是做了优化么？\n A：你指的 Istio 控制面占用资源比较多指的是哪一部分？Mixer 么？\n 可以理解为只告知当前服务需要依赖的信息吧，这样的话数据量就小多了。\n A：是的。\n Pilot 在我们自己的集群里部署了，占用资源也挺多的，不过比 Mixer 小。 另外我查看数据面 Envoy 从 Pilot 拿到的数据信息挺多的，config_dump 的信息有 30 万行左右。\n A：我们暂时没有从 Pilot 拿服务注册数据，只有一些服务流量管控的配置从 Pilot 下发，Mixer 的能力是集成在 MOSN 内部的所以控制面的消耗还好，不是很重。\n 那应该是做了挺多优化调整的吧。\n A：是的，集成后省去了 Mixer 的两跳，Metrics 数据可以直接被采集。\n 那服务的依赖关系需要通过配置提供才能做到只感知需要依赖的服务吧？Metrics 的直接采集是通过 prometheus 直接抓取每个数据面节点的数据么？\n A：是的，通过 prometheus 协议定时有专门的 agent 抓取的数据。\nMOSN：https://github.com/sofastack/sofa-mosn\n3、@NameHaibinZhang 提问：\n 将 MOSN 按照容器化的方式部署，通过读取默认配置，暴露 15001 端口，MOSN 能够同时在一个端口接收不同协议的请求么，如 Http、SOFARPC 请求。\n A：MOSN 的默认配置都是一些 example，没有 15001 端口，你需要按照你的需求写你的配置。一个 listener 目前不能同时处理两种协议，listener 中 proxy 的配置指定了可以处理的协议。\n 15001 端口是按 Sidecar 方式部署的时候开启的端口，比如通过 Istio 来部署，iptables 中 Envoy 开启 15001 端口。\n A：目前同一个端口支持 tls/明文自定识别， http1/http2 的自动识别，协议哪儿配置 Auto。Http 和 SOFA 的识别目前不支持，有需求的话支持也很方便。\n 嗯，因为作为 Sidecar 部署的时候，http 的接口和 SOFA 接口都希望能通过 Sidecar 来做流量劫持，Auto 可以做 rpc 协议的支持和识别不？\n A：如果是做流量劫持的话，其实是不需要支持识别的，这个 15001 不会实际处理请求，会转发给正确的端口来处理。\n Sidecar 内部做一个转发是吧，开另外2个端口，那15001这个端口配置 TCP 协议了，然后接收到之前做判断是什么协议，转给对应的端口。\n A：可以看一下这篇文章：《SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案》。\nSOFA 项目进展 本周发布详情如下：\n发布 Occlum v0.7.0 版本，主要变更如下：\n 重构了 ioctl 的实现； 增加了 socketpair； 实现了与Alpine Linux的二进制兼容性； 增加了 nanosleep； 增加了外部可调用命令的路径检查（即 occlum run 的）； 增加了 XGBoost 的 demo； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.7.0\n社区活动 回顾： 11月24日 Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动回顾（含现场PPT以及视频回顾）：\n Service Mesh 在『路口』的产品思考与实践：务实是根本 深入Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统 12月5日 SOFAChannel#9 直播回顾：\n https://tech.antfin.com/community/live/1021/data/957 预告-专享福利： “剑指源码，尖峰对话”2019 OSC源创会是由 OSCHINA 主办的线下技术沙龙，理念为“自由、开放、分享”，SOFAStack 也受邀参加本次年终盛会，并带来主题分享。\n主题：《蚂蚁金服 Service Mesh 超大规模实践以及开源》\n嘉宾：卓与，蚂蚁金服 Mesh 化落地负责人\n时间：2019年12月15日下午14:05-14:40（架构分会场）\n专享福利：点击“这里”，验证码填写“SOFAStack”即可获得大会免费票。\nTopic 简 …","date":1575615600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191206/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"aa9ec52b9b85a6c8830ff752423d1248","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191206/","publishdate":"2019-12-06T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191206/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【12/2 - 12/6】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191206/","wordcount":2358},{"author":"曹寅","categories":"Kubernetes","content":" 一、前言 经过超过半年的研发，蚂蚁金服在今年完成了 Kubernetes 的全面落地，并使得核心链路100% 运行在 Kubernetes。到今年双十一，蚂蚁金服内部通过 Kubernetes 管理了数以万计的机器以及数十万的业务实例，超过90%的业务已经平稳运行在 Kubernetes 上。整个技术切换过程平稳透明，为云原生的资源基础设施演进迈好了关键的一步。\n本文主要介绍 Kubernetes 在蚂蚁金服的使用情况，双十一大促对 Kubernetes 带来史无前例的挑战以及我们的最佳实践。希望通过分享这些我们在实践过程中的思考，让大家在应用 Kubernetes 时能够更加轻松自如。\n二、蚂蚁金服的 Kubernetes 现状 2.1 发展历程与落地规模 Kubernetes 在蚂蚁金服落地主要经历了四个阶段：\n 平台研发阶段：2018年下半年蚂蚁金服和阿里集团共同投入 Kubernetes 技术生态的研发，力求通过 Kubernetes 替换内部自研平台； 灰度验证：2019年初 Kubernetes 在蚂蚁金服灰度落地，通过对部分资源集群进行架构升级以及灰度替换生产实例两种方式，让 Kubernetes 得以小规模的验证； 云化落地（蚂蚁金服内部基础设施云原生化）：2019年4月蚂蚁金服内部完成 Kubernetes 适配云化环境的目标，并于618之前完成云化机房100% 使用 Kubernetes 的目标，这是 Kubernetes 第一次在蚂蚁金服内部得到规模化的验证； 规模化落地：2019年618之后，蚂蚁金服内部开始全面推动 Kubernetes 落地，在大促之前完成核心链路100% 运行在 Kubernetes的目标，并完美支撑了双十一大考。 2.2 统一资源调度平台 Kubernetes 承载了蚂蚁金服在云原生时代对资源调度的技术目标：统一资源调度。通过统一资源调度，可以有效提升资源利用率，极大的节省资源成本。要做到统一调度，关键在于从资源层面将各个二层平台的调度能力下沉，让资源在 Kubernetes 统一分配。\n蚂蚁金服在落地 Kubernetes 实现统一调度目标时遵循了标准化的扩展方式：\n 一切业务扩展均围绕 Kubernetes APIServer，通过CRD + Operator方式完成业务功能的适配和扩展； 基础服务通过 Node 层定义的资源接口完成个性化适配，有益于形成资源接入的最佳实践。 得益于持续的标准化工作，我们在落地 Kubernetes 的大半年内应用了多项技术，包含安全容器，统一日志，GPU 精细调度，网络安全隔离及安全可信计算等，并通过 Kubernetes 统一使用和管理这些资源服务了大量在线业务以及计算任务型业务。\n三、双十一 Kubernetes 实践 下面我们通过以下几种场景介绍蚂蚁金服内部是如何使用 Kubernetes，以及在此过程中我们面对的挑战和实践之路。\n3.1 资源分时复用 在大促过程中，不同业务域的洪峰流量通常都是在不同时间段来临，而应对这些不同时间到来的业务流量往往都需要大量的额外计算资源做保障。在以往的几次活动中，我们尝试了通过应用快速腾挪的方式来做到资源上的分时复用，但是服务实例上下线需要预热，腾挪耗时不可控，大规模调度的稳定性等因素都影响了最终腾挪方案的实践效果。\n今年双十一我们采用了资源共享调度加精细化切流的技术以达到资源分时利用的目标，为了达到资源充分利用和极速切换的目标，我们在以下方面做了增强：\n 在内部的调度系统引入了联合资源管理（Union-Resource Management），他可以将波峰波谷不重叠的业务实例摆放在相同的资源集合内，达到最大化的资源利用。 研发了一套融合资源更新，流量切换及风险控制的应用分时复用平台，通过该平台SRE可以快速稳定的完成资源切换以应对不同的业务洪峰。 整套平台和技术最终实现了令人激动的成果：蚂蚁金服内部不同业务链路数以万计的实例实现了最大程度的资源共享，这些共享资源的实例可分钟级完成平滑切换。这种技术能力也突破了当下资源水平伸缩能力的效率限制，为资源的分时复用打开了想象空间。\n3.2 计算型任务混部 Kubernetes 社区的落地案例中，我们往往看到的都是各种各样的在线业务，计算型业务往往通过“圈地”式的资源申请和独立的二层调度跑在 Kuberentes 集群中。但是在蚂蚁内部我们从决定使用 Kubernetes 的第一天起，就将 Kubernetes 融合计算型业务实现资源的统一调度作为我们的目标。\n在蚂蚁金服内部我们持续的使用 Kubernetes 支持各类计算业务，例如各类AI 训练任务框架，批处理任务和流式计算等。他们都有一个共同的特点：资源按需申请，即用即走。\n我们通过 Operator 模型适配计算型任务，让任务在真正执行时才会调用 Kubernetes API 申请 Pod 等资源，并在任务退出时删除 Pod 释放资源。同时我们在调度引擎中引入了动态资源调度能力和任务画像系统，这为在线和计算的不同等级业务提供了分级资源保障能力，使在线业务不受影响的情况下资源被最大化的利用。\n今年双十一除了洪峰时间段（00：00~02：00），蚂蚁金服 Kubernetes 上运行的任务均未做降级，每分钟仍有数以百计的计算任务在 Kubernetes 上申请和释放。未来蚂蚁金服内部将会持续推动业务调度融合，将 Kubernetes 打造成为资源调度的航空母舰。\n3.3 规模化核心 蚂蚁金服是目前少数运行了全球最大规模的 Kubernetes 集群的公司之一，单集群机器规模过万，Pods 数量数十万。随着类似计算型任务混部和资源分时复用这类业务的落地，资源的动态使用以及业务自动化运维都对 Kubernetes 的稳定性和性能带来的巨大的挑战。\n首先需要面对的挑战是调度性能，社区的调度器在5k规模测试中调度性能只有1~2 pods/s，这显然无法满足蚂蚁金服的调度性能需求。\n针对同类业务的资源需求往往相同的特点，我们自研了批量调度功能，再加上例如局部的filters性能优化等工作，最终达到了百倍的调度性能提升！\n在解决了调度性能问题后，我们发现规模化场景下 APIServer 逐渐成为了影响 Kubernetes 可用性的关键组件，CRD+Operator 的灵活扩展能力更是对集群造成巨大的压力。业务方有100种方法可以玩垮生产集群，让人防不胜防。 造成这种现象一方面是由于社区今年以前在规模化上的投入较少 APIServer 能力较弱，另一方面也是由 Operator 模式的灵活性决定。开发者在收益于 Operator 高灵活度的同时，往往为集群管理者带来业务不受控制的风险。即使对 Kubernetes 有一定熟悉程度的开发者，也很难保障自己写出的 Operator 在生产中不会引爆大规模的集群。\n面对这种“核按钮”不在集群管理员手上的情况，蚂蚁内部通过两方面入手解决规模化带来的问题：\n 我们通过持续总结迭代过程中的经验，形成了内部的最佳实践原则，以帮助业务更好的设计Operator CRD 在定义时需要明确未来的最大数量，大量CR …","date":1575464400,"description":"本文主要介绍 Kubernetes 在蚂蚁金服的使用情况，双十一大促对 Kubernetes 带来史无前例的挑战以及我们的最佳实践。","dir":"blog/kubernetes-practice-antfinal-shopping-festival/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5e1572fd3da2309cb49050bc05e24450","permalink":"https://sofastack.github.io/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","publishdate":"2019-12-04T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","summary":"一、前言 经过超过半年的研发，蚂蚁金服在今年完成了 Kubernetes 的全面落地，并使得核心链路100% 运行在 Kubernetes。到今年双十一，蚂蚁金服内部通","tags":["Kubernetes"],"title":"深入 Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统","type":"blog","url":"/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","wordcount":3956},{"author":"齐天","categories":"Service mesh","content":" 一、引言 Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』，我们在产品设计上的思考和实践，希望能给大家带来一些启发。\n二、为什么需要 Service Mesh? 2.1 微服务治理与业务逻辑解耦 在 Service Mesh 之前，微服务体系的玩法都是由中间件团队提供一个 SDK 给业务应用使用，在 SDK 中会集成各种服务治理的能力，如：服务发现、负载均衡、熔断限流、服务路由等。\n在运行时，SDK 和业务应用的代码其实是混合在一个进程中运行的，耦合度非常高，这就带来了一系列的问题：\n 升级成本高 每次升级都需要业务应用修改 SDK 版本号，重新发布； 在业务飞速往前跑的时候，是不太愿意停下来做这些和自身业务目标不太相关的事情的； 版本碎片化严重 由于升级成本高，但中间件还是会向前发展，久而久之，就会导致线上 SDK 版本各不统一、能力参差不齐，造成很难统一治理； 中间件演进困难 由于版本碎片化严重，导致中间件向前演进过程中就需要在代码中兼容各种各样的老版本逻辑，戴着『枷锁』前行，无法实现快速迭代； 有了 Service Mesh 之后，我们就可以把 SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以 Sidecar 的模式部署。通过将服务治理能力下沉到基础设施，可以让业务更加专注于业务逻辑，中间件团队则更加专注于各种通用能力，真正实现独立演进，透明升级，提升整体效率。\n2.2 异构系统统一治理 随着新技术的发展和人员更替，在同一家公司中往往会出现使用各种不同语言、不同框架的应用和服务，为了能够统一管控这些服务，以往的做法是为每种语言、每种框架都重新开发一套完整的 SDK，维护成本非常高，而且对中间件团队的人员结构也带来了很大的挑战。\n有了 Service Mesh 之后，通过将主体的服务治理能力下沉到基础设施，多语言的支持就轻松很多了，只需要提供一个非常轻量的 SDK、甚至很多情况都不需要一个单独的 SDK，就可以方便地实现多语言、多协议的统一流量管控、监控等治理需求。\n图片来源\n2.3 金融级网络安全 当前很多公司的微服务体系建设都建立在『内网可信』的假设之上，然而这个原则在当前大规模上云的背景下可能显得有点不合时宜，尤其是涉及到一些金融场景的时候。\n通过 Service Mesh，我们可以更方便地实现应用的身份标识和访问控制，辅之以数据加密，就能实现全链路可信，从而使得服务可以运行于零信任网络中，提升整体安全水位。\n三、在当下『路口』的思考 3.1 云原生方案？ 正因为 Service Mesh 带来了上述种种的好处，所以这两年社区中对 Service Mesh 的关注度越来越高，也涌现出了很多优秀的 Service Mesh 产品，Istio 就是其中一款非常典型的标杆产品。\nIstio 以其前瞻的设计结合云原生的概念，一出现就让人眼前一亮，心之向往。不过深入进去看了之后发现，在目前阶段要落地的话，还是存在一些 gap 的。\n图片来源\n3.2 Greenfield vs Brownfield 在正式展开讨论之前，我们先来看一副漫画。\n图片来源\n上面这幅漫画描绘了这样一个场景：\n 有两个工人在工作，其中一个在绿色的草地（Greenfield）上，另一个在棕色的土地（Brownfield）上； 在绿色草地上的工人对在棕色土地上的工人说：“如果你没有给自己挖这么深的坑，那么你也可以像我一样做一些很棒的新东西”； 然后在棕色土地上的工人回答道：“你倒是下来试试！”； 这是一幅很有意思的漫画，从表面上看我们可以认为在绿色草地上的工人是站着说话不腰疼，不过其实本质的原因还是两者所处的环境不同。\n在一片未开发过的土地上施工确实是很舒服的，因为空间很大，也没有周遭各种限制，可以使用各种新技术、新理念，我们国家近几十年来的一些新区新城的建设就属于这类。而在一片已经开发过的土地上施工就大不一样了，周围环境会有各种限制，比如地下可能有各种管线，一不小心就挖断了，附近还有各种大楼，稍有不慎就可能把楼给挖塌了，所以做起事来就要非常小心，设计方案时也会受到各种约束，无法自由发挥。\n对于软件工程，其实也是一样的，Greenfield 对应着全新的项目或新的系统，Brownfield 对应着成熟的项目或遗留系统。\n我相信大部分程序员都是喜欢做全新的项目的，包括我自己也是一样。因为可以使用新的技术、新的框架，可以按照事物本来的样子去做系统设计，自由度很高。而在开发/维护一个成熟的项目时就不太一样了，一方面项目已经稳定运行，逻辑也非常复杂，所以无法很方便地换成新的技术、新的框架，在设计新功能时也会碍于已有的架构和代码实现做很多妥协，另一方面前人可能不知不觉挖了很多坑，稍有不慎就会掉进坑里，所以行事必须要非常小心，尤其是在做大的架构改变的时候。\n3.3 现实场景 3.3.1 Brownfield 应用当道 在现实中，我们发现目前大部分的公司还没有走向云原生，或者还刚刚在开始探索，所以大量的应用其实还跑在非 k8s 的体系中，比如跑在虚拟机上或者是基于独立的服务注册中心构建微服务体系。\n虽然确实有少量 Greenfield 应用已经在基于云原生来构建了，但现实是那些大量的 Brownfield 应用是公司业务的顶梁柱，承载着更大的业务价值，所以如何把它们纳入 Service Mesh 统一管控，从而带来更大的价值，也就成了更需要优先考虑的话题。\n图片来源 独立的服务注册中心\n3.3.2 云原生方案离生产级尚有一定距离 另一方面，目前 Istio 在整体性能上还存在一些有待解决的点（引述小剑老师在蚂蚁金服 Service Mesh 深度实践中的观点）：\n Mixer Mixer 的性能问题，一直都是 Istio 中最被人诟病的地方； 尤其在 Istio 1.1\u0026amp;frasl;1.2 版本之后引入了 Out-Of-Process Adapter，更是雪上加霜； 从落地的角度看，Mixer V1 糟糕至极的性能，已经是“生命无法承受之重”。对于一般规模的生产级落地而言，Mixer 性能已经是难于接受，更不要提大规模落地…… Mixer V2 方案则给了社区希望：将 Mixer 合并进 Sidecar，引入 web assembly 进行 Adapter 扩展，这是我们期待的 Mixer 落地的正确姿势，是 Mixer 的未来，是 Mixer 的『诗和远方』。然而社区望穿秋水，但Mixer V2 迟迟未能启动，长期处于 In Review 状态，远水解不了近渴； Pilot Pilot 是一个被 Mixer 掩盖的重灾区：长期以来大家的性能关注点都在 Mixer，表现糟糕而且问题明显的Mixer 一直在吸引火力。但是当选择放弃 Mixer（典型如官方在 Istio 新版本中提供的关闭 Mixer 的配置开关）之后，Pilot 的性能问题也就很快浮出水面； 我们实践下来发现 Pilot 目前主要有两大问题：1）无法支撑海量数据 2）每次变化都会触发全量推送，性能较差； 图片来源\n3.4 当 …","date":1575291600,"description":"Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』，我们在产品设计上的思考和实践。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-wushi/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"30414154356f38408eac8044657b5d63","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","publishdate":"2019-12-02T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","summary":"一、引言 Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』","tags":["Service mesh","Service Mesh 落地实践"],"title":"Service Mesh 在『路口』的产品思考与实践：务实是根本","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","wordcount":6226},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News NO.1 社区新认证一位 Committer\nGithub ID @zongtanghu 成为 SOFAJRaft Committer：\n主要贡献：\n 贡献了两个重要 Feature： 基于优先级配置的自动选举； 为 Replicator 日志复制实现 ReplicatorStateListener 监听器； 添加一些优化功能和 Bugfix： 优化 SOFAJRaft 的工具类，减少冗余代码，增加单元测试用例代码； 优化常量类，实现 Copiable 接口； 原创文章贡献 《SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理》; 《中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说》; 目前，社区已经认证超过四十位 Committer。\n感谢对 SOFAStack 的支持和帮助，也欢迎你加入 SOFAStack community~ SOFAStack 社区：https://www.sofastack.tech/awesome/\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@kaka19ace 提问：\n 为什么 MOSN 热重启机制需要新老进程，两个 unix domain socket server 通信交互? 目前分为 旧进程 reconfigerServer 新进程 transferServer, 1. reconfigerServer 只是新进程主动判断 isReconfigure() 就结束了连接； 1. 迁移 listener fd 以及 connection fd 让旧进程作为 client 角色；\n如果仅使用 reconfigerServer 作为交互通信会存在哪些问题？\n A：你的意思就是旧进程 reconfigerServer在收到 isReconfigure() 后，直接传输旧进程的fd给新进程。原理上也是可以的。这儿其实有个历史原因，最开始支持信号 fork 子进程的方式，是不需要 isReconfigure() 来判断是否存在旧进程的，通过环境变量就可以了，后来为了支持容器升级的方式，单独启一个新的进程，才需要一个机制来判断是否存在旧进程，为了改动更小，之前的逻辑不受影响，才加了这个新的 us 来通讯。\n 翻了老版本代码阅读： reconfigure 这块是基于环境变量设置 fd. fork exec 参数使用 sys.ProcAttr 继承 fd 信息。 这块有一个问题确认，老版本场景里如果升级新版的二进制文件，也是基于同目录下替换了相同的 bin 文件，然后再给老进程 hup 信号触发重启吧？\n A：是的，老版本是发送 hup 信号，然后 fork 一个子进程来做二进制升级，这个适用于虚拟机升级。而基于容器的话，是重新拉起一个容器，一个新的进程，就需要跟老的进程来交互。\n 早期版本和 Envoy uds 迁移方式不同，当时设计是有什么考虑吗？后续基于 SCM_RIGHTS 传输 fd 方式与 Envoy 类似，这块重构原因有哪些?想了解代码演进的过程。\n A：你看到代码是 listen fd 的迁移，和 Envoy 最大的不同是我们会把存量的长链接也做迁移。 代码演进是： 第一阶段， 只支持 listen fd 的迁移。 第二阶段， 支持存量长链接的迁移，hup 信号，然后 fork 的方式。 第三阶段， 支持容器间存量长链接的迁移，通过 uds 查找子进程。\n 非常感谢丰富的演进说明。重新拉起容器这块不太明白，对 Envoy 的场景理解： - 热重启是同一个容器内，Sidecar 新老进程的交接，业务进程继续运行； - Sidecar 进程管理是由 pilot-agent 进行管理，当前容器内 agent 发送热重启信号，非重新拉起容器；\nMOSN 这里指的是拉起新容器, 容器间迁移数据？uds 的路径是挂载盘?\n A：Envoy 的方式不能用镜像来管理二进制了。MOSN 除了支持 Envoy 这种容器内热升级，也支持容器间。MOSN 会拉起新容器，然后做容器间的连接迁移，uds 的路径是共享卷，2个 container 共享。\n 容器间迁移是否和业务场景有关，为何不是让旧容器自己销毁（摘掉服务发现, 并延迟一段时间自己销毁）？\n A：是的，就是为了 Sidecar 的发布对用户无感知，连接不断，升级 Sidecar 的时候服务也一直在运行。 MOSN：https://github.com/sofastack/sofa-mosn\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFAJRaft v1.3.0 版本，主要变更如下：\n 新增 Read-only member(learner) 角色，支持 learner 节点上的线性一致读 实现优先级选举 在 multi-raft-group 的场景中，随机打散每个 group 的第一次 snapshot timeout 时间，避免一个进程内多个 group 同时 snapshot RheaKV 实现 snapshot checksum 以及异步 snapshot 致谢（排名不分先后）：@zongtanghu @devYun @masaimu @SteNicholas @yetingsky 详细发布报告： https://github.com/sofastack/sofa-jraft/issues/362\n社区活动 回顾 11月24日 Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动回顾：\n 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇（文末含分享视频回顾以及 PPT 查看地址） 预告 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔 …","date":1575010800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191129/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"af340bf3bee03aa71221229aee4c986b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191129/","publishdate":"2019-11-29T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/25 - 11/29】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191129/","wordcount":2060},{"author":"鲁直、碧远","categories":"Service mesh","content":" 蚂蚁金服云原生负责人鲁直 双十一后首次线下分享\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA（service-oriented architecture，面向服务的架构）体系快速演进至 Service Mesh 架构。聚焦 RPC 层面的设计和改造方案，本次将分享蚂蚁金服双十一核心应用是如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本。\n蚂蚁金服每年双十一大促会面临非常大的流量挑战，在已有 LDC（Logical Data Center，逻辑数据中心，是蚂蚁金服原创的一种“异地多活单元化架构”实现方案）微服务架构下已支撑起弹性扩容能力。本次分享主要分为 5 部分：\n Service Mesh 简介； 为什么要 Service Mesh； 方案落地； 分时调度案例； 思考与未来； 作者简介 黄挺（花名：鲁直）：蚂蚁金服云原生负责人 主要 Focus 领域：\n SOFAStack 微服务领域； Service Mesh，Serverless 等云原生领域； 雷志远（花名：碧远）：蚂蚁金服 RPC 框架负责人 主要 Focus 领域：\n 服务框架：SOFARPC（已开源）； Service Mesh：MOSN（已开源）； SOFARPC：https://github.com/sofastack/sofa-rpc\nMOSN：https://github.com/sofastack/sofa-mosn\nService Mesh 简介 在讲具体的蚂蚁金服落地之前，想先和大家对齐一下 Service Mesh 的概念，和蚂蚁金服对应的产品。这张图大家可能不陌生，这是业界普遍认可的 Service Mesh 架构，对应到蚂蚁金服的 Service Mesh 也分为控制面和数据面，分别叫做 SOFAMesh 和 MOSN，其中 SOFAMesh 后面会以更加开放的姿态参与到 Istio 里面去。\n今天我们讲的实践主要集中在 MOSN 上，以下我的分享中提到的主要就是集中在数据面上的落地，这里面大家可以看到，我们有支持 HTTP/SOFARPC/Dubbo/WebService。\n为什么我们要 Service Mesh 有了一个初步的了解之后，可能大家都会有这样一个疑问，你们为什么要 Service Mesh，我先给出结论：\n因为我们要解决在 SOA 下面，没有解决但亟待解决的：基础架构和业务研发的耦合，以及未来无限的对业务透明的稳定性与高可用相关诉求。\n那么接下来，我们一起先看看在没有 Service Mesh 之前的状况。\n在没有 Service Mesh 之前，整个 SOFAStack 技术演进的过程中，框架和业务的结合相当紧密，对于一些 RPC 层面的需求，比如流量调度，流量镜像，灰度引流等，是需要在 RPC 层面进行升级开发支持，同时，需要业务方来升级对应的中间件版本，这给我们带来了一些困扰和挑战。如图所示：\n 线上客户端框架版本不统一； 业务和框架耦合，升级成本高，很多需求由于在客户端无法推动，需要在服务端做相应的功能，方案不够优雅； 机器逐年增加，如果不增加机器，如何度过双十一； 在基础框架准备完成后，对于新功能，不再升级给用户的 API 层是否可行；  流量调拨，灰度引流，蓝绿发布，AB Test 等新的诉求； 这些都困扰着我们。我们知道在 SOA 的架构下，负责每个服务的团队都可以独立地去负责一个或者多个服务，这些服务的升级维护也不需要其他的团队的接入，SOA 其实做到了团队之间可以按照接口的契约来接耦。但是长期以来，基础设施团队需要推动很多事情，都需要业务团队进行紧密的配合，帮忙升级 JAR 包，基础设施团队和业务团队在工作上的耦合非常严重，上面提到的各种问题，包括线上客户端版本的不一致，升级成本高等等，都是这个问题带来的后果。\n而 Service Mesh 提供了一种可能性，能够将基础设施下沉，让基础设施团队和业务团队能够解耦，让基础设施和业务都可以更加快步地往前跑。\n我们的方案 说了这么多，那我们怎么解决呢？我们经历了这样的选型思考。\n总体目标架构 我们的 MOSN 支持了 Pilot、自有服务发现 SOFARegistry 和自有的消息组件，还有一些 DB 的组件。在产品层，提供给开发者不同的能力，包括运维、监控、安全等能力，这个是目前我们的一个线上的状态。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n 看上去很美好，要走到这个状态，我们要回答业务的三个灵魂拷问。\n这三个问题后面，分别对应着业务的几大诉求，大家做过基础框架的应该比较有感触。\n框架升级方案 准备开始升级之后，我们要分析目前我们的线上情况，而我们现在线上的情况，应用代码和框架有一定程度的解耦，用户面向的是一个 API，最终代码会被打包，在 SOFABoot 中运行起来。\n SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n 那么，我们就可以在风险评估可控的情况下，直接升级底层的 SOFABoot。在这里，我们的 RPC 会检测一些信息，来确定当前 Pod 是否需要开启 MOSN 的能力。然后我们完成如下的步骤。\n我们通过检测 PaaS 传递的容器标识，知道自己是否开启了 MOSN，则将发布和订阅给 MOSN，然后调用不再寻址，直接完成调用。\n可以看到，通过批量的运维操作，我们直接修改了线上的 SOFABoot 版本，以此，来直接使得现有的应用具备了 MOSN 的能力。有些同学可能会问，那你一直这么做不行吗？不行，因为这个操作是要配合流量关闭等操作来运行的，也不具备平滑升级的能力，而且直接和业务代码强相关，不适合长期操作。\n这里我们来详细回答一下，为什么不采用社区的流量劫持方案？\n主要的原因是一方面 iptables 在规则配置较多时，性能下滑严重。另一个更为重要的方面是它的管控性和可观测性不好，出了问题比较难排查。蚂蚁金服在引入 Service Mesh 的时候，就是以全站落地为目标的，而不是简单的“玩具”，所以我们对性能和运维方面的要求非常高，特别是造成业务有损或者资源利用率下降的情况，都是不能接受的。\n容器替换方案 解决了刚刚提到的第一个难题，也只是解决了可以做，而并不能做得好，更没有做得快，面对线上数十万带着流量的业务容器， 我们如何立刻开始实现这些容器的快速稳定接入？\n这么大的量，按照传统的替换接入显然是很耗接入成本的事情，于是我们选择了原地接入，我们可以来看下两者的区别：\n在之前，我们做一些升级操作之类的，都是需要有一定的资源 Buffer，然后批量的进行操作， …","date":1574946000,"description":" 聚焦 RPC 层面的设计和改造方案，本次将分享蚂蚁金服双十一核心应用是如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3d67d3c4d38ced6f9de8a92364c0827c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","publishdate":"2019-11-28T21:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","summary":"蚂蚁金服云原生负责人鲁直 双十一后首次线下分享 引言 Service Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","wordcount":4496},{"author":"悟尘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第五篇 - 网关篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 本文结合无线网关的发展历程，解读进行 Service Mesh 改造的缘由和价值，同时介绍在双十一落地过程中如何保障业务流量平滑迁移至新架构下的 Mesh 网关。分享将从如下三个方面展开：\n 网关的前世今生，解释网关为什么要 Mesh 化； 网关 Mesh 化，阐述如何进行 Mesh 化改造； 双十一落地，介绍在此过程中实现三板斧能力； 前世今生 蚂蚁金服无线网关当前接入数百个业务系统，提供数万个 API 服务，是蚂蚁金服客户端绝对的流量入口，支持的业务横跨支付宝、网商、财富、微贷、芝麻和国际 A+ 等多种场景。面对多种业务形态、复杂网络结构，无线网关的架构也在不断演进。\n中心化网关 在 All In 无线的年代，随着通用能力的沉淀，形成了中心化网关 Gateway。\n 客户端连接到网关接入层集群 Spanner ； Spanner 会把客户端请求转发到无线网关集群 Gateway； Gateway 提供通用能力如鉴权、限流等处理请求，并根据服务标识将请求路由到正确的后端服务；服务处理完请求，响应原路返回； 2016 年新春红包爆发，蚂蚁森林等新兴业务发展壮大，网关集群机器数不断增长。这加剧了运维层面的复杂性，IT成本也不能承受之重。同时，一些核心链路的业务如无线收银台、扫一扫等，迫切需要与其他业务隔离，避免不可预知的突发流量影响到这些高保业务的可用性。因此，2016 年下半年开始建设和推广去中心化网关。\n去中心化网关 去中心化网关将原先集中式网关的能力进行了拆分：\n 转发逻辑：将 Gateway 中根据服务标识转发的能力迁移到 Spanner 上； 网关逻辑：将网关通用能力如鉴权、限流、LDC 等功能，抽成一个 mgw jar 集成到业务系统中，与后端服务同JVM 进程运行； 此时，客户端请求的处理流程如下：\n 客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务的 mgw 中； mgw 进行通用网关能力处理，90% 的请求随即进行 JVM 内部调用； 去中心化网关与集中式网关相比，具有如下优点：\n 提升性能： 少一层网关链路，网关 jar 调用业务是 JVM 内部调用； 大促期间，无需关心网关的容量，有多少业务就有多少网关； 提高稳定性： 集中式网关形态下，网关出现问题，所有业务都会收到影响； 去中心化后，网关的问题，不会影响去中心化的应用； 但凡事具有两面性，随着在 TOP30 的网关应用中落地铺开，去中心化网关的缺点也逐步显现：\n 研发效能低： 接入难：需要引入 15+ pom 依赖、20+ 的配置，深度侵入业务配置； 版本收敛难：当前 mgw.jar 已迭代了 40+ 版本，当前还有业务使用的是初版，难以收敛； 新功能推广难：新能力上线要推动业务升级和发布，往往需要一个月甚至更久时间； 干扰业务稳定性： 依赖冲突，干扰业务稳定性，这种情况发生了不止一次； 网关功能无法灰度、独立监测，资源占用无法评估和隔离； 不支持异构接入：财富域大部分系统是 Node 技术栈，无法使用去中心化网关；  Mesh 网关 去中心化网关存在的诸多问题，多数是由于网关功能与业务进程捆绑在一起造成的。这引发了我们的思考：如果网关功能从业务进程中抽离出来，这些问题是否就可以迎刃而解了？这种想法，与 Service Mesh 的 Sidecar 模式不谋而合。因此在去中心化网关发展了三年后，我们再出发对蚂蚁金服无线网关进行了 Mesh 化改造，以期籍此解决相关痛点。\nMesh 网关与后端服务同 Pod 部署，即 Mesh 网关与业务系统同服务器、不同进程，具备网关的全量能力。客户端请求的处理流程如下：\n 客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务同 Pod 中的 Mesh 网关； Mesh 网关执行通用逻辑后调用同机不同进程的业务服务，完成业务处理； 对比去中心化网关的问题，我们来分析下 Mesh 网关所带来的优势：\n 研发效能： 接入方便：业务无需引入繁杂的依赖和配置，即可接入 Mesh 网关； 版本容易收敛、新功能推广快：新版本在灰度验证通过后，即可全网推广升级，无需维护和排查多版本带来的各种问题； 业务稳定性： 无损升级：业务系统无需感知网关的升级变更，且网关的迭代升级将可利用 MOSN 现有的特性进行细粒度的灰度和验证，做到无损升级； 独立监测：由于和业务系统在不同进程，可以实时遥测 Mesh 网关进程的表现，并据此评估和优化，增强后端服务稳定性； 异构系统接入：Mesh 网关相当于一个代理，对前端屏蔽后端的差异，将支持 SOFARPC、Dubbo 和 gRPC 等主流 RPC 协议，并支持非 SOFA 体系的异构系统接入； 至此，我们卖瓜自夸式地讲完了无线网关的前世今生，解释了为何要撸起袖子进行网关 Mesh 化。但细心的你想必怀疑：\n Mesh 化之后的请求处理流程不是同进程调用，比起去中心化网关多了一跳，是否有性能损耗？ 毕竟进行了大刀阔斧的变革，在上线过程中如何保障稳定性？ 接下来的章节将对上述问题进行解释。\nMesh 化 架构 首先，从架构层面详细介绍网关 Mesh 化所做的相关工作。依照 Service Mesh 的分层模型，Mesh 网关分为数据面和控制面。\n解读：\n 蓝色箭头线是客户端请求的处理流程，Mesh 网关数据面在蚂蚁金服内部 MOSN 的 Sidecar 中； 绿色箭头线是网关配置下发过程，Mesh 网关控制面当前还是由网关管控平台来承载； 红色箭头线条是 MOSN Sidecar 的运维体系； MOSN：https://github.com/sofastack/sofa-mosn\n数据面 采用 Go 语言实现了原先网关的全量能力，融合进 MOSN 的模型中，复用了其他组件已有的能力。 同时网络接入层 Spanner 也实现了请求分发决策能力。\n数据转换 将客户端的请求数据转换成后端请求数据，将后端响应数据转换成客户端响应。利用 MOSN 协议层扩展能力，实现了对网关自有协议 Mmtp 的解析能力。\n通用功能 授权、安全、限流、LDC 和重试等网关通用能力。利用 MOSN Stream Filter 注册机制以及统一的 Stream Send/Receive Filter 接口扩展而来。\n请求路由 客户端请求按照特定规则路由到正确的后端系统。在网关层面实现 LDC 逻辑后，复用 MOSN RPC 组件的路由匹配能力。其中大部分请求都会路由到当前 Zone，从而直接请求到当前 Pod 的业务进程端口。\n后端调用 支持调用多种类型的后端服务，支持对 SOFARPC、Chair 等后端，后期计划支持更多的 RPC 框架和异构系统。\n控制面 为网关用户提供新增、配置 API 等服务的管控系统，可将网关配置数据下发至 Mesh …","date":1574946000,"description":" 本文结合无线网关的发展历程，解读进行 Service Mesh 改造的缘由和价值，同时介绍在双十一落地过程中如何保障业务流量平滑迁移至新架构下的 Mesh 网关。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a51651ca16ad1df8e867f4e25296c50b","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","publishdate":"2019-11-28T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第五篇 - 网关篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","wordcount":3545},{"author":"嘉祁","categories":"Service mesh","content":" 《蚂蚁金服 Service Mesh 大规模落地系列》将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析，文末包含往期系列文章。本文为该系列文章的第三篇 - 运维篇。\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，也是蚂蚁金服内部向云原生演进的重要一环。本文为 Service Mesh 系列文章的运维篇，作者：黄家琦 （花名：嘉祁），蚂蚁金服运维专家，Service Mesh SRE，主要关注云原生基础设施、中间件及 Service Mesh 的稳定性，同时也是 Pythoner，sofa-bolt-python 作者。\n本文将主要分享大规模服务网格在蚂蚁金服当前体量下落地到支撑蚂蚁金服双十一大促过程中，运维角度所面临的挑战与演进。内容包括云原生化的选择与问题，对资源模型的挑战，大规模下运维设施的演进，以及周边技术风险能力的建设。\nService Mesh 在2019年得到了大规模的应用与落地，截止目前，蚂蚁金服的 Service Mesh 数据平面 MOSN 已接入应用数百个，接入容器数量达数十万，是目前已知的全世界最大的 Service Mesh 集群。同时，在刚刚结束的双十一大促中，Service Mesh 的表现也十分亮眼，RPC 峰值 QPS 达到了几千万，消息峰值 TPS 达到了几百万，且引入 Service Mesh 后的平均 RT 增长幅度控制在 0.2 ms 以内。\n拥抱云原生 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。而在具体部署上，保守的做法是以独立进程的方式与业务进程共同存在于业务容器内。我们在蚂蚁金服内部的做法，则从开始，就选择了拥抱云原生。\nSidecar 模式 业务容器内独立进程的好处在于与传统的部署模式兼容，易于快速上线；但独立进程强侵入业务容器，对于镜像化的容器更难于管理。而云原生化，则可以将 Service Mesh 本身的运维与业务容器解耦开来，实现中间件运维能力的下沉。在业务镜像内，仅仅保留长期稳定的 Service Mesh 相关 JVM 参数，从而仅通过少量环境变量完成与 Service Mesh 的联结。同时考虑到面向容器的运维模式的演进，接入 Service Mesh 还同时要求业务完成镜像化，为进一步的云原生演进打下基础。\n 优 劣 独立进程 兼容传统的部署模式；改造成本低；快速上线 侵入业务容器；镜像化难于运维 Sidecar 面向终态；运维解耦 依赖 K8s 基础设施；运维环境改造成本高；应用需要镜像化改造 在接入 Service Mesh 之后，一个典型的 POD 结构可能包含多个 Sidecar：\n MOSN：RPC Mesh, MSG Mesh, \u0026amp;hellip;（扩展中）； 其它 Sidecar； MOSN：https://github.com/sofastack/sofa-mosn\n这些 Sidecar 容器，与业务容器共享相同的网络 Namespace，使得业务进程可以以本地端口访问 Service Mesh 提供的服务，保证了与保守做法一致的体验。\n基础设施云原生支撑 我们也在基础设施层面同步推进了面向云原生的改造，以支撑 Service Mesh 的落地。\n业务全面镜像化 首先是在蚂蚁金服内部推进了全面的镜像化，我们完成了内部核心应用的全量容器的镜像化改造。改造点包括：\n 基础镜像层面增加对于 Service Mesh 的环境变量支撑； 应用 Dockerfile 对于 Service Mesh 的适配； 推进解决了存量前后端分离管理的静态文件的镜像化改造； 推进了大量使用前端区块分发的应用进行了推改拉的改造； 大批量的 VM 模式的容器升级与替换； 容器 POD 化 除了业务镜像层面的改造，Sidecar 模式还需要业务容器全部跑在 POD 上，来适应多容器共享网络。由于直接升级的开发和试错成本很高，我们最终选择将接入 Service Mesh 的 数百个应用的数万个非 K8s 容器，通过大规模扩缩容的方式，全部更换成了 K8s PODs。\n经过这两轮改造，我们在基础设施层面同步完成了面向云原生的改造。\n资源的演进 Sidecar 模式的带来一个重要的问题，如何分配资源。\n理想比例的假设 最初的资源设计基于内存无法超卖的现实。我们做了一个假设：\n MOSN 的基本资源占用与业务选择的规格同比例这一假设。 CPU 和 Memory 申请与业务容器相应比例的额外资源。这一比例最后设定在了 CPU 1/4，Memory 1/16。\n此时一个典型 Pod 的资源分配如下图示：\n这一方式带来了两个问题：\n 蚂蚁金服已经实现了业务资源的 Quota 管控，但 Sidecar 并不在业务容器内，Service Mesh 容器成为了一个资源泄漏点； 业务很多样，部分高流量应用的 Service Mesh 容器出现了严重的内存不足和 OOM 情况； 完美分割的不完美 不止于此，为了快速支撑 Service Mesh 在非云环境的铺开，上线了原地接入 Service Mesh。而原地接入 Service Mesh 的资源无法额外分配，在内存不能超卖的情况下，采取了二次分割的分配方式。此时的 POD 内存资源被切分为1/16内存给 Sidecar，与15/16给业务容器。除了以上两个问题，还带来一些新的问题：\n 业务可见内存不一致，业务监控偏差，业务进程 OOM 风险。 讨论之后，我们追加了一个假设：\n Service Mesh 容器占用的资源实质是在接入 Service Mesh 之前业务已使用的资源。接入 Service Mesh 的过程，同时也是一次资源置换。 共享 基于这个假设，推进了调度层面支持 POD 内的资源超卖，新的资源分配方案如下图，Service Mesh 容器的 CPU、MEM 都从 POD 中超卖出来，业务容器内仍然可以看到全部的资源。\n考虑到内存超卖也引入了 POD OOM 的风险，因此对于 Sidecar 容器还调整了 OOM Score，保证在内存不足时，Service Mesh 进程能够发挥启动比 Java 业务进程更快的优势，降低影响。\n新的分配方案解决了同时解决了以上两个问题，并且平稳支持了大促前的多轮压测。\n重建 但新的分配方案上线时，Service Mesh 已经在弹性建站时同步上线。同时我们还发现在一些场景下，Service Mesh 容器无法抢占到 CPU 资源，导致业务 RT 出现了大幅抖动，原因是在 CPU Share 模式下，POD 内默认并没有等额的分配 CPU Quota 给 Sidecar。\n于是还有两个问题待解决：\n 存量的已分配 Sidecar 仍有 OOM 风险； Sidecar 无法抢占到 CPU； 我们已经无法承受更换全部 POD 的代价。最终在调度的支持下，通过对 Pod Annotation 的手动重新计算+修改，在 POD 内进行了全部资源的重分配，来修复这两个风险。最终的修复容器总数约 25w 个。 …","date":1574859600,"description":" 本文将主要分享大规模服务网格在蚂蚁金服当前体量下落地到支撑蚂蚁金服双十一大促过程中，运维角度所面临的挑战与演进。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b4428f1c979dfa574a7ec8b4d96bc191","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","publishdate":"2019-11-27T21:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","summary":"《蚂蚁金服 Service Mesh 大规模落地系列》将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析，文末","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","wordcount":4049},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解\n 活动时间：12 月 5 日周四晚 7 点\n 活动形式：线上直播\n 直播回看：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。\n12 月 5 日周四晚 7 点，将邀请蚂蚁金服技术专家卓与 ，聚焦 RPC 层面的设计和改造方案，分享蚂蚁金服双十一核心应用如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本，并从核心、RPC、消息等模块展开本次双十一落地实践的实现细节分享。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1021\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服 Service Mesh 双十一落地详解 卓与 蚂蚁金服 Service Mesh 落地负责人\n本期分享大纲： 蚂蚁金服 Service Mesh 架构双十一大规模落地实践案例分析； 从核心、RPC、消息等模块分享蚂蚁金服 Service Mesh 落地实践细节； 欢迎先阅读Service Mesh 落地系列文章，收看直播收获更好的效果； 嘉宾 SOFAGirl 主持人 卓与 蚂蚁金服 Service Mesh 落地负责人 ","date":1574741400,"description":"12 月 5 日周四晚 7 点，线上直播第 9 期。","dir":"activities/sofa-channel-9/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"33ec75a1b0e23d96934a7ec43dfa5df5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-9/","publishdate":"2019-11-26T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-9/","summary":"概要 活动主题：SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解 活动时间：12 月 5 日周四晚 7 点 活动形式：线上直播 直播回看：戳这里 介绍 | SOFAChannel","tags":["SOFAChannel","Service Mesh"],"title":"SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解","type":"activities","url":"/sofastack.tech/activities/sofa-channel-9/","wordcount":554},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@J～杰 提问：\n 帮我看个问题，标红的这个状态没执行是啥原因？ A：没有 Next 属性，可以下载 seata-sample，里面有例子，https://github.com/seata/seata-samples。\n 好的，CompensateState 这个属性是正向失败后，重试这个状态？\n A：正向失败后，触发这个补偿状态。 https://github.com/seata/seata/tree/develop/test/src/test/java/io/seata/saga/engine 为里有很多单元测试案例，代码对应的json在：https://github.com/seata/seata/tree/develop/test/src/test/resources/saga/statelang。 正向失败后，触发这个 CompensateState 状态，但失败后并不会默认就触发补偿流程，需要在 Catch 属性里，Next 到一个 CompensateTrigger。\n 那 Saga 模式下，如果 TC 端发出回滚命令，Saga 怎么处理，没发现有回滚状态？\n A：Saga 模式的 TCC 模式有点不一样的是，Saga 的回滚不是由 TC 来协调，而是只 TC 触发，回滚流程是由状态机执行的。 https://github.com/seata/seata/blob/develop/test/src/test/resources/saga/statelang/simple_statelang_with_compensation.json\n这里是 Catch 到异常后，可以自定义捕获某些异常，然后 Next 到一个处理 state，这个 state 可以是任何 state，如果是 CompensateTrigger 则立即进行回滚。\n Saga 是通过检测异常来识别回滚命令？\n A：Catch 属性是用来检测异常的，但异常的处理可能不仅仅是进行回滚，可能有别的处理逻辑，因业务不同而不同，catch 到这些异常处理，你可以 Next 到任何一个 state 来处理异常；如果希望回滚，框架提供了 CompensateTrigger 这种一个特定的 state，Next 到 CompensateTrigger，则立即进行回滚。\n 如果一个 Saga 状态失败后，RM 一直会重试，这个重试有没有次数限制的？\n A：https://github.com/seata/seata/blob/develop/server/src/main/resources/file.conf.example 重试间隔和重试超时时间, -1是无限重试，比如可以配置成 1d ，只重度一天。\n 还有个问题，发现 catch 没有捕捉到 RuntimeExcepeion 异常： A：它走到 Fail 那个状态去了吗？另外就是 Status 是会执行的，catch 异常和状态判断是两个互不干扰的事情。\n 就是没有走到 Fail 那个状态才奇怪，刚开始我是把 Status 给去掉的，也没走，后来就加上的。这个重试是状态为 un 的时候，TC 就会一直发起重试的吧？\n A：如果没有发起过回滚（补偿流程），失败后 TC 会重试继续完成状态机正向执行，如果发了回滚，回滚失败后 TC 会重试回滚。\n 那如果发生回滚，是从哪个状态节点开始回滚的？\n A：从失败的节点开始。\n 是通过读这张表的数据 seata_state_inst？\n A：对。\nSeata：https://github.com/seata/seata\n2、@胡文伟 提问：\n 双模微服务是指什么？\n A：所谓双模，是指 SOFA 微服务和 Service Mesh 技术的双剑合璧，即“基于 SDK 的 SOFA 微服务”可以和“基于 Sidecar 的 Service Mesh 微服务”实现下列目标： 互联互通：两个体系中的应用可以相互访问； 平滑迁移：应用可以在两个体系中迁移，对于调用该应用的其他应用，做到透明无感知； 异构演进：在互联互通和平滑迁移实现之后，我们就可以根据实际情况进行灵活的应用改造和架构演进。\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.8.1，主要变更如下：\n 新增 MOSN 处理失败请求数的统计； 提升写共享内存时的性能； 优化内存占用与日志输出； 修复日志文件轮转的 Bug； 详细发布报告：https://github.com/sofastack/sofa-mosn/releases/tag/0.8.1\nSOFAChannel 直播推荐 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。聚焦 RPC 层面的设计和改造方案，分享蚂蚁金服双十一核心应用如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本，并从核心、RPC、消息等模块展开分享本次双十一落地实践的实现细节。\n你将收获：\n 蚂蚁金服 Service Mesh 架构双十一大规模落地实践案例分析； 从核心、RPC、消息等模块分享蚂蚁金服 Service Mesh 落地实践细节； 时间：2019年12月5日（周四）19:00-20:00 形式：线上直播 报名方式：点击“这里”即可报名\n","date":1574406000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191122/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d1021e16b4acefdf05a527584900ba69","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191122/","publishdate":"2019-11-22T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191122/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/18 - 11/22】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191122/","wordcount":2007},{"author":"无勤","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 作为蚂蚁金服向下一代云原生架构演进的核心基础设施，在2019年得到了大规模的应用与落地，截止目前，蚂蚁金服的 Service Mesh 数据平面 MOSN 已接入应用数百个，接入容器数量达数十万，一举成为全世界最大的 Service Mesh 集群。同时，在刚刚结束的双十一大促中，Service Mesh 的表现也十分亮眼，RPC 峰值 QPS 达到了几千万，消息峰值 TPS 达到了几百万，且引入 Service Mesh 后的平均 RT 增长幅度控制在 0.2 ms 以内。\n本文作为整个 Service Mesh 系列文章的消息篇，作者：刘翔（花名：无勤），蚂蚁金服消息 Mesh 负责人， 消息中间件核心研发成员，专注于高吞吐、低延迟的消息中间件研发，以及云原生时代下一代消息系统的架构设计与研发。本文将从以下几个方面对消息 Mesh 进行解读：\n 对消息 Mesh 进行介绍，解答消息 Mesh 在整个 Service Mesh 中的地位是什么，它又能为业务带来哪些价值； 结合蚂蚁金服消息中间件团队 Mesh 化的实践与思考，阐述如何在消息领域进行 Mesh 化改造； 消息 Mesh 在蚂蚁金服内部大规模落地过程中遇到的问题与挑战，以及对应的解决方案； 消息流量精细化调度上的思考与在 Mesh 上的实现与落地； 消息 Mesh 简介 Service Mesh 作为云原生场景下微服务架构的基础设施（轻量级的网络代理），正受到越来越多的关注。Service Mesh 不仅负责在微服务架构的复杂拓扑中可靠地传递请求，也将限流、熔断、监控、链路追踪、服务发现、负载均衡、异常处理等与业务逻辑无关的流量控制或服务治理行为下沉，让应用程序能更好地关注自身业务逻辑。\n微服务架构中的通信模式实际上是多种多样的，既包含同步的请求调用，也包含异步的消息/事件驱动，然而流行的 Service Mesh 实现（Istio，Linkerd，Consul Connect等），都仍局限在对微服务中同步请求调用的关注，却无法管理和追踪异步消息流量。而消息 Mesh 则是对这一块的重要补充，通过将消息 Mesh 有机地融合到 Service Mesh 中，可以帮助 Service Mesh 实现对所有微服务流量的管控和追踪，从而进一步完善其架构目标。\n消息 Mesh 的价值 在传统的消息中间件领域，我们更关注的是消息服务端的性能、服务可用性、数据可靠性等核心指标，而与业务应用密切相关的一些能力，包括消息的流量控制（限流、熔断、灰度、着色、分组等），消息的服务治理（消息量级与消息应用拓扑等），消息链路的追踪（消息轨迹）却往往不尽如人意。\n这不仅是因为传统模式下上述能力的提供和优化都涉及客户端的改造与大规模升级，整个过程常常比较漫长，难以快速根据有效反馈不断优化，更重要的是缺乏一个统一的架构指导思想，混乱无序地向客户端叠加相关功能只会让消息客户端变得越来越臃肿和难以维护，也变向增加了业务系统的接入、调试和排查问题的成本。而消息 Mesh 作为 Service Mesh 的补充，能显著带来如下价值和收益：\n 快速升级 - 通过将与业务逻辑无关的一些核心关键能力下沉到 Sidecar 中，使这些能力的单独快速迭代与升级成为可能； 流量控制 - 可以向 Sidecar 中集成各种流量控制策略，例如可根据消息类型、消息数量、消息大小等多种参数来控制消息的发送和消费速率； 流量调度 - 通过打通 Sidecar 节点之间的通信链路，可以利用 Sidecar 的流量转发来实现任意精度的消息流量调度，帮助基于事件驱动的微服务应用进行多版本流量管理、流量着色、分组路由、细粒度的流量灰度与A/B策略等； 消息验证 - 消息验证在基于事件驱动的微服务架构中正变得越来越重要，通过将这部分能力下沉到 Sidecar，不仅可以让业务系统无缝集成消息验证能力，也可以让 Sidecar 通过 Schema 理解消息内容，并进一步具备恶意内容识别等安全管控能力； 可观测性 - 由于所有的消息流量都必须通过 Sidecar，因此可以为 Sidecar 上的消息流量按需增加 Trace 日志，Metrics 采集，消息轨迹数据采集等能力，并借此进一步丰富消息服务的治理能力； 消息 Mesh 化改造 在蚂蚁金服内部，Msgbroker 基于推模型提供高可靠、高实时、事务消息、header 订阅等特性，帮助核心链路进行异步解耦，提升业务的可扩展能力，并先后伴随蚂蚁金服众多核心系统一起经历了分布式改造、单元化改造与弹性改造，目前主要承载蚂蚁内部交易、账务、会员、消费记录等核心在线业务的异步消息流量。\n由于 Service Mesh 的推进目标也是优先覆盖交易支付等核心链路，为在线业务赋能，因此我们优先选择对 Msgbroker 系统进行 Mesh 化改造。下面将以 Msgbroker 为例，重点剖析 Mesh 化后在整体架构和核心交互流程上的变化，为消息领域的 Mesh 化改造提供参考。\n整体架构 消息 Mesh 化后的整体架构如上图所示，与原有的消息架构相比，主要的变化有：\n 客户端不再与服务端直连，而是通过 Sidecar 进行请求的中转，对客户端而言，Sidecar 实际上是它唯一能感知到的消息服务端，对服务端而言，Sidecar 则扮演着客户端的角色； 所有 Sidecar 都会与控制平面交互，接收服务端地址列表、流量管控和调度配置、运行时动态配置等的下发，从而使数据平面具备限流、熔断、异常重试、服务发现、负载均衡、精细化流量调度等能力； 核心交互流程 当 Sidecar 代理了消息客户端的所有请求后，一旦 Sidecar 完成消息服务的发现与服务端/客户端路由数据的缓存，无论是客户端的发消息请求还是服务端的推消息请求，都能由 Sidecar 进行正确的代理转发，而这一切的关键，则是 Sidecar 与消息客户端协同完成一系列的初始化操作。\n消息 Mesh 化后具体的初始化流程如下所示，与原有的初始化流程相对比，主要有如下不同：\n 在经过 Mesh 化改造后，消息客户端不再直接向 SOFARegistry 订阅消息服务端的地址，而是将所有消息元数据（包含业务应用声明的消息 Topic、发送/订阅组 GroupId 等关键信息）通过 HTTP 请求上报给 MOSN，由 MOSN 进行元数据的持久化（用于 MOSN 异常 Crash 后的恢复）以及消息服务端地址的订阅和处理； 当客户端收到 MOSN 对于注册请求的响应时，会主动与 MOSN 建立连接，并将与该连接相关的 Group 集合信息通过控制指令发送给 MOSN，由于客户端与 MOSN 可能存在多个连接，且不同连接上的 Group 集合可以不同，而 MOSN 与同一个消息服务端只维持一个连接，因此控制指令无法向消息数据一样直接进行转发，而是需要 …","date":1574326800,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇-消息篇","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1778dffdda6a839ad3e72183df3393d6","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","publishdate":"2019-11-21T17:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","wordcount":4722},{"author":"卓与","categories":"Service mesh","content":" 2019 年的双十一是蚂蚁金服的重要时刻，大规模落地了 Service Mesh 并顺利保障双十一平稳渡过。我们第一时间与这次的落地负责人进行了交流。\n采访的开头： 花肉：“这次大规模上了 Service Mesh ，双十一值班感觉是什么？” 卓与：“Service Mesh 真的稳。”\n 图为卓与 TOP100 北京峰会分享现场图\n落地负责人介绍 Service Mesh 是蚂蚁金服下一代架构的核心，今年蚂蚁金服大规模的 Service Mesh 落地，我有幸带领并面对了这个挑战，并非常平稳的通过了双十一的大考。\n我个人主要专注在微服务领域，在服务注册与服务框架方向深耕多年，主导过第五代服务注册中心（SOFARegistry）设计与实施，在微服务的架构演进中持续探索新方向，并在蚂蚁金服第五代架构演进中负责内部 Service Mesh 方向的架构设计与落地。\nSOFAStack：https://github.com/sofastack SOFAMosn：https://github.com/sofastack/sofa-mosn\nService Mesh 在蚂蚁金服 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已经渡过探索期，今年已经全面进入深水区探索。\n2019 年的双十一是我们的重要时刻，我们进行了大规模的落地，可能是目前业界最大规模的实践。作为技术人能面对世界级的流量挑战，是非常紧张和兴奋的。当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？我们借助四个“双十一考题”一一为大家揭晓。\nService Mesh 背景知识 Service Mesh 这个概念社区已经火了很久，相关的背景知识从我们的公众号内可以找到非常多的文章，我在这里不做过于冗余的介绍，仅把几个核心概念统一，便于后续理解。\n图1. Service Mesh 开源架构来自 https://istio.io/\nIstio 的架构图上清晰的描述了 Service Mesh 最核心的两个概念：数据面与控制面。数据面负责做网络代理，在服务请求的链路上做一层拦截与转发，可以在链路中做服务路由、链路加密、服务鉴权等，控制面负责做服务发现、服务路由管理、请求度量（放在控制面颇受争议）等。\nService Mesh 带来的好处不再赘述，我们来看下蚂蚁金服的数据面和控制面产品，如下图：\n图2. 蚂蚁金服 Service Mesh 示意架构\n数据面：SOFAMosn。蚂蚁金服使用 Golang 研发的高性能网络代理，作为 Service Mesh 的数据面，承载了蚂蚁金服双十一海量的核心应用流量。\n控制面：SOFAMesh。Istio 改造版，落地过程中精简为 Pilot 和 Citadel，Mixer 直接集成在数据面中避免多一跳的开销。\n2019 Service Mesh 双十一大考揭秘 双十一 SOFAMosn 与 SOFAMesh 经历海量规模大考，顺利保障双十一平稳渡过。今年双十一蚂蚁金服的百十多个核心应用全面接入 SOFAMosn，生产 Mesh 化容器几十万台，双十一峰值 SOFAMosn 承载数据规模数千万 QPS，SOFAMosn 转发平均处理耗时 0.2ms。\n图3. 双十一落地数据\n在如此大规模的接入场景下，我们面对的是极端复杂的场景，同时需要多方全力合作，更要保障数据面的性能稳定性满足大促诉求，整个过程极具挑战。下面我们将从几个方面来分享下我们在这个历程中遇到的问题及解决方案。\n双十一考题 如何让 Service Mesh 发挥最大的业务价值？ 如何达成几十万容器接入 SOFAMosn 的目标？ 如何处理几十万容器 SOFAMosn 的版本升级问题？ 如何保障 Service Mesh 的性能与稳定性达标？ 落地架构 为了更加方便的理解以上问题的解决与后续介绍中可能涉及的术语等，我们先来看下 Service Mesh 落地的主要架构：\n图4. Service Mesh 落地架构\n以上架构图中主要分几部分：\n 数据面：借助 Kubernetes 中的 Pod 模型，SOFAMosn 以独立镜像和 App 镜像共同编排在同一个 Pod 内，共享相同的 Network Namespace、CPU、Memory，接入 SOFAMosn 后所有的 App RPC 流量、消息流量均不在直接对外，而是直接和 SOFAMosn 交互，由 SOFAMosn 直接对接服务注册中心做服务发现，对接 Pilot 做配置下发，对接 MQ Server 做消息收发等； 控制面：由 Pilot、Citadel 和服务注册中心等组件组成，负责服务地址下发、服务路由下发、证书下发等； 底层支撑：Sidecar 的接入与升级等均依赖 Kubernetes 能力，通过 webhook 做 Sidecar 的注入，通过 Operator 做 Sidecar 的版本升级等，相关运维动作均离不开底层的支撑； 产品层：结合底层提供的原子能力做运维能力封装，监控对接，采集 Sidecar 暴露的 Metrics 数据做监控与预警，流量调控，安全等产品化能力； 蚂蚁金服的答卷 1. 如何让 Service Mesh 发挥最大的业务价值？ 作为一个技术人，我们非常坚持不要为了技术革新本身去做技术革新，一定要让技术帮助业务，用技术驱动业务。这几年随着大家消费习惯以及网络行为的改变，双十一面对的业务场景远比想象中复杂。举个例子大家感受下，大家有没有发现你的女友或者老婆每天对着李佳琦的淘宝直播购物，主播们不断的、实时的红包、上新等等，带来了远比秒杀更复杂的业务场景和体量。大促的模式也更加丰富，不同场景下的大促涉及的应用是不同的，每一类应用在应对独特的洪峰时都需要有足够的资源。\n假如运营同学在不同时间点设计了两种活动，两种活动分别会对应两类不同的应用，如果这两类应用都在大促前准备充足的资源自然是轻松渡过大促峰值，但大促洪峰时间短暂，大量的资源投入有很长一段时间都处于空闲状态，这自然不符合技术人的追求。\n那么如何在不增加资源的场景下渡过各种大促呢？\n核心问题就是如何在足够短的时间内做到大规模资源腾挪，让一批机器资源可以在不同时间点承载起不同的大促洪峰。\n面对这样的挑战，我们会有怎样的解法呢？\nService Mesh 618 大促落地试点时，我们有介绍到为什么要做这个事情，核心价值是业务与基础设施解耦，双方可以并行发展，快速往前走。那么并行发展究竟能为业务带来哪些实际的价值？除了降低基础组件的升级难度之外，我们还在资源调度方向做了以下探索：\n1.1 腾挪调度 说到资源调度，最简单的自然是直接做资源腾挪，比如大促A峰值过后，大促A对应的应用通过缩容把资源释放出来，大促B对应的应用再去申请资源做扩容，这种方式非常简单，难点在于当资源规模非常庞大时，缩容扩容的效率极低，应用需要把资源申请出来并启动应用，耗时很长，假如多个大促 …","date":1574154000,"description":" 当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？我们借助四个“双十一考题”一一为大家揭晓。","dir":"blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"269c9444948a5f83a5a17f907b72ce4a","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","publishdate":"2019-11-19T17:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","summary":"2019 年的双十一是蚂蚁金服的重要时刻，大规模落地了 Service Mesh 并顺利保障双十一平稳渡过。我们第一时间与这次的落地负责人进行了交流。 采访的开头： 花肉：“这","tags":["Service mesh","Service Mesh 落地实践"],"title":"Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","wordcount":6239},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@瀚墨 提问：\n 请问 SOFARPC 本地多人开发有没有最佳实践分享一下了？\n A：你说的多人开发具体是指啥协作场景？\n 开发人员开发本地的服务时，需要依赖的服务可以来自一个开发环境！这样的开发人员就不需要启动自己本地所有的服务了。我们已经有一个开发环境，会部署所有的服务，但是当开发人员开发某一个功能时，可能只希望其中几个接口走本地，其他的接口走开发环境！\n A：你的这个开发环境是一组不确定的机器，还是一台指定 IP 的机器？\nSOFARPC：https://github.com/sofastack/sofa-rpc\n 指定的 IP 地址。\n A：一种方法本地调用方直接配开发环境的机器直连调用， 另外一个方法就是开发环境统一使用一个 uniqueId，和本地用不同的uniqueId。\n2、@温明磊 提问：\n Seata Saga 向前重试状态机 json 该怎么配置，节点代码内部和节点 json 的 catch 都不捕获异常吗，这样就会一直调用该节点。\n A：运行过程中向前重试：通过 Catch 到异常然后 Next 到当前节点（这种实现了 Retry 配置之后就不需要了），事后向前重试：直接调 forward 方法即可（一般不需要自己调，server 端会自动触发）。\n Retry 配置什么时候实现，事后向前重试是一定会发生的吗？\n A：Retry 配置正在做了。事后向前重试目前 server 端的逻辑是这样的：失败时，如果没有触发回滚，那么 server 端会不断发起重试，如果触发过回滚（也就是回滚失败了）server 端会不断触发 compensate。\n 这个没用触发回滚，是不是像我上面说的这个出错节点，代码内部没用捕获异常，json 也没有 catch 异常，然后就不断重试了。\n A：是的。\n3、@金雷-上海 提问：\n 看代码，Saga 二阶段提交成功不删分支事务？回滚也是不删，有特殊原因？\n A：你是 server 端的分支事务吗？客户端的状态机日志不会删，server 端没有显示删除分支事务，只是提交或回滚全局事务。\n 嗯，我看了代码是这样，不清楚为什么这么操作。 全局事务表删了，分支事务不删。\n A：是这样的，Saga 模式的回滚是在客户端状态机协调的，不是用 TC 协调的，TC 只是触发，客户端回滚或成功后会调 server 端上报回滚成功。所以我理解是 server 端这时会删除全局事务记录，而没有删除分支事务记录。因为是客户端协调，所以 TC 也没有循环去调每一个分支事务的 rollback，所以分支事务实际上是留下了，没有被删除。\n 既然全局事务都删除了，如果留着没有什么意义，我觉得可以删除分支事务。\n A：是的。提个 issue，修改一下。\n你提的那个 issue 修复了 ，https://github.com/seata/seata/pull/1893 同时做了一个优化，重试和补偿服务不向 Seata server 注册分支事务，仅原始服务注册分支事务，重试和补偿服务执行完成时向原始服务注册的分支事务上报成功与否的状态。\nRetry 功能，\u0026amp;rdquo;BackoffRate\u0026amp;rdquo;: 1.5，表示重试间隔增量，1.5表示本次重试间隔是上次的1.5倍：https://github.com/seata/seata/issues/1899\n还有一个点，当重试过程中生了别的异常，框架会重新匹配这个异常对应的重试规则，并按新规则来重试，但同一种规则的总次数的不会超过它配置的 MaxAttempts，避免不同异常来回切换而一直重试。\n 新规则就是下面这个配置吗？\n A： 就是你可以配置多个重试规则，根据 Exceptions 属性来匹配，下面那个没有带 Exceptions 表示框架自动匹配网络超时异常。\n 配置了 Exceptions，不只是可以匹配节点的异常，还可以匹配重试的异常，执行新的重试规则。\n A：对的。\n4、@J～杰 提问：\n 我看整个 Saga 流程引擎都是自己开发的，那个 json 的参数属性含义哪里可以参考？\n A：这是官网文档，每个属性的含义，可以看 State language referance 节。 http://seata.io/zh-cn/docs/user/saga.html\n 如果用了 @GlobalTransactional，在并发场景中，是不是还要用 @GlobalLock 保证数据的隔离性？\n A：@GlobalLock 是用于非分布式事务场景下的读分布式事务中数据。在分布式事务的场景本身有全局锁来隔离。\nSeata：https://github.com/seata/seata\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 万字长文丨1分36秒，100亿，支付宝技术双11答卷：没有不可能 SOFA 项目进展 本周发布详情如下：\n发布 SOFATracer v2.4.2\u0026amp;frasl;3.0.8，主要变更如下：\n 迁移 samples 到 sofastack-guides空间下 修复 Server Receive 阶段出现 spanId 增长问题 优化 Zipkin 远程上报问题 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.2 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.8\n云原生活动推荐  本期为 Service Mesh Meetup#8 特别场，联合 CNCF、阿里巴巴及蚂蚁金服共同举办。\n不是任何一朵云都撑得住双 11。\n成交 2684 亿，阿里巴巴核心系统 100% 上云。\n蚂蚁金服的核心交易链路大规模上线 Service Mesh。\n这次，让双 11 狂欢继续，让云原生经得起双 11 大考，也让云原生走到开发者身边。\n你将收获 3 大经验加持：\n 双 11 洗礼下的阿里巴巴 K8s 超大规模实践经验 蚂蚁金服首次 Service Mesh 大规模落地经验 阿里巴巴超大规模神龙裸金属 K8s …","date":1573801200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191115/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c08a41ec62ae153bbc0ce35958093192","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191115/","publishdate":"2019-11-15T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191115/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/11 - 11/15】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191115/","wordcount":2326},{"author":"烈元","categories":"Service mesh","content":" 揭秘 2019 Service Mesh 双十一大考 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已经渡过探索期，今年已经全面进入深水区探索。\n2019 年的双十一是我们的重要时刻，我们进行了大规模的落地。作为技术人能面对世界级的流量挑战，是非常紧张和兴奋的。当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？让我们一起来揭秘蚂蚁金服 Service Mesh 双十一实战。\nService Mesh 基础概念 Istio 清晰的描述了 Service Mesh 最核心的两个概念：数据面与控制面。数据面负责做网络代理，在服务请求的链路上做一层拦截与转发，可以在链路中做服务路由、链路加密、服务鉴权等，控制面负责做服务发现、服务路由管理、请求度量（放在控制面颇受争议）等。\nService Mesh 带来的好处不再赘述，我们来看下蚂蚁金服的数据面和控制面产品：\n 数据面：SOFAMosn。蚂蚁金服使用 Golang 研发的高性能网络代理，作为 Service Mesh 的数据面，承载了蚂蚁金服双十一海量的核心应用流量。\n 控制面：SOFAMesh。Istio 改造版，落地过程中精简为 Pilot 和 Citadel，Mixer 直接集成在数据面中避免多一跳的开销。\n 双十一落地情况概览 今年，蚂蚁金服的核心应用全面接入 SOFAMosn，生产 Mesh 化容器几十万台，双十一峰值 SOFAMosn 承载数据规模数千万 QPS，SOFAMosn 转发平均处理耗时 0.2ms。\n在如此大规模的接入场景下，我们面对的是极端复杂的场景，同时需要多方全力合作，更要保障数据面的性能稳定性满足大促诉求，整个过程极具挑战。\n同时，Service Mesh 的落地也是一个跨团队合作的典范案例，集合了核心、RPC、消息、无线网关、控制面、安全、运维、测试等团队的精诚合作，接下来我们会按照以上几个模块来解析 Service Mesh 的双十一落地情况，更多解析关注本网站。\n本文为《蚂蚁金服 Service Mesh 落地实践系列》第一篇 - 核心篇，作者：田阳（花名：烈元），蚂蚁金服技术专家，专注于高性能网络服务器研发，Tengine 开源项目核心成员，蚂蚁金服开源 SOFAMosn 项目核心成员。\n基础能力建设 SOFAMosn 的能力大图 SOFAMosn 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 XDS 等云原生能力。\n业务支持 SOFAMosn 作为底层的高性能安全网络代理，支撑了 RPC，MSG，GATEWAY 等业务场景。\nIO 模型 SOFAMosn 支持两种 IO 模型，一个是 Golang 经典模型，goroutine-per-connection；一个是 RawEpoll 模型，也就是 Reactor 模式，I/O 多路复用(I/O multiplexing) + 非阻塞 I/O(non-blocking I/O)的模式。\n在蚂蚁金服内部的落地场景，连接数不是瓶颈，都在几千或者上万的量级，我们选择了 Golang 经典模型。而对于接入层和网关有大量长链接的场景，更加适合于 RawEpoll 模型。\n协程模型 一条 TCP 连接对应一个 Read 协程，执行收包，协议解析； 一个请求对应一个 worker 协程，执行业务处理，proxy 和 Write 逻辑； 常规模型一个 TCP 连接将有 Read/Write 两个协程，我们取消了单独的 Write 协程，让 workerpool 工作协程代替，减少了调度延迟和内存占用。\n能力扩展 协议扩展\nSOFAMosn 通过使用同一的编解码引擎以及编/解码器核心接口，提供协议的 plugin 机制，包括支持：\n SOFARPC； HTTP1.x/HTTP2.0； Dubbo； NetworkFilter 扩展\nSOFAMosn 通过提供 network filter 注册机制以及统一的 packet read/write filter 接口，实现了 Network filter 扩展机制，当前支持：\n TCP proxy； Fault injection； StreamFilter 扩展\nSOFAMosn 通过提供 stream filter 注册机制以及统一的 stream send/receive filter 接口，实现了 Stream filter 扩展机制，包括支持：\n 流量镜像； RBAC鉴权； TLS 安全链路 作为金融科技公司，资金安全是最重要的一环，链路加密又是其中最基础的能力，在 TLS 安全链路上我们进行了大量的调研测试。\n通过测试，原生的 Go 的 TLS 经过了大量的汇编优化，在性能上是 Nginx(OpenSSL）的80%，Boring 版本的 Go(使用 cgo 调用 BoringSSL) 因为 cgo 的性能问题， 并不占优势，所以我们最后选型原生 Go 的 TLS，相信 Go Runtime 团队后续会有更多的优化，我们也会有一些优化计划。\n go 在 RSA 上没有太多优化，go-boring（CGO）的能力是 go 的1倍； p256 在 go 上有汇编优化，ECDSA 优于go-boring； 在 AES-GCM 对称加密上，go 的能力是 go-boring 的20倍； 在 SHA、MD 等 HASH 算法也有对应的汇编优化； 为了满足金融场景的安全合规，我们同时也对国产密码进行了开发支持，这个是 Go Runtime 所没有的。虽然目前的性能相比国际标准 AES-GCM 还是有一些差距，大概是 50%，但是我们已经有了后续的一些优化计划，敬请期待。\n平滑升级能力 为了让 SOFAMosn 的发布对应用无感知，我们调研开发了平滑升级方案，类似 Nginx 的二进制热升级能力，但是有个最大的区别就是 SOFAMosn 老进程的连接不会断，而是迁移给新的进程，包括底层的 socket FD 和上层的应用数据，保证整个二进制发布过程中业务不受损，对业务无感知。除了支持 SOFARPC、Dubbo、消息等协议，我们还支持 TLS 加密链路的迁移。\n容器升级\n基于容器平滑升级 SOFAMosn 给了我们很多挑战，我们会先注入一个新的 SOFAMosn，然后他会通过共享卷的 UnixSocket 去检查是否存在老的 SOFAMosn，如果存在就和老的 SOFAMosn 进行连接迁移，然后老的 SOFAMosn 退出。这一块的细节较多，涉及 SOFAMosn 自身和 Operator 的交互。\nSOFAMosn 的连接迁移\n连接迁移的核心主要是内核 Socket 的迁移和应用数据的迁移，连接不断，对用户无感知。\nSOFAMosn 的 metric 迁移\n我们使用了共享内存来共享新老进程的 metric 数据，保证在迁移的过程中 metric 数据也是 …","date":1573779600,"description":" 当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？让我们一起来揭秘蚂蚁金服 Service Mesh 双十一实战。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f758a3d4476cd3e8516947fa6fff5747","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","publishdate":"2019-11-15T09:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","summary":"揭秘 2019 Service Mesh 双十一大考 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","wordcount":3391},{"author":"潘潘","categories":"Service Mesh","content":" 概要 活动主题：Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动时间：2019 年 11 月 24 日（星期日）9:30-16:30 活动地点：北京朝阳大望京科技商务园区宏泰东街浦项中心B座2层多功能厅 活动形式：线下活动 活动报名：请戳这里 活动介绍 Service Mesh Meetup#8 特别场 本期为 Service Mesh Meetup#8 特别场，联合 CNCF、阿里巴巴及蚂蚁金服 共同举办。\n不是任何一朵云都撑得住双 11。\n成交 2684 亿，阿里巴巴核心系统 100% 上云。\n蚂蚁金服的核心交易链路大规模上线 Service Mesh。\n这次，让双 11 狂欢继续，让云原生经得起双 11 大考，也让云原生走到开发者身边。\n你将收获 3 大经验加持：\n 双 11 洗礼下的阿里巴巴 K8s 超大规模实践经验； 蚂蚁金服首次 Service Mesh 大规模落地经验； 阿里巴巴超大规模神龙裸金属 K8s 集群运维实践经验； 错过一次，再等一年哦。\n议程 时间 环节（分享主题） 分享嘉宾 9:00-9:30 签到 9:30-10:10 《释放云原生价值，双 11 洗礼下的阿里巴巴 K8s 超大规模实践》 曾凡松（逐灵），阿里巴巴高级技术专家；汪萌海（木苏），阿里巴巴技术专家 10:10-10:50 《蚂蚁金服双十一Service Mesh超大规模落地揭秘》 黄挺（鲁直），蚂蚁金服云原生负责人；雷志远（碧远），蚂蚁金服技术专家 10:50-11:30 《阿里巴巴超大规模神龙裸金属 K8s 集群运维实践》 周涛 （广侯），阿里巴巴高级技术专家 11:30-12:10  《深入Kubernetes的“无人区” — 蚂蚁金服双十一的调度系统》 曹寅，蚂蚁金服 Kubernetes 落地负责人 12:10-13:30 午休 13:30-14:10  《服务网格在“路口”的产品思考与实践》 宋顺（齐天），蚂蚁金服高级技术专家，开源配置中心Apollo作者 14:10-14:50 《阿里集团核心应用落地 Service Mesh 的挑战与机遇》 李云（至简），阿里巴巴高级技术专家 14:50-13:10 茶歇 15:10-15:50 《蚂蚁金服云原生 PaaS 实践之路》 王成昌（晙曦），蚂蚁金服技术专家 15:50-16:30 《函数计算在双十一小程序场景的应用》 吴天龙（木吴），阿里云函数计算技术专家 加入 SOFA 钉钉互动群 群号：23390449，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n","date":1573639200,"description":"11月24日，Service Mesh Meetup#8 双十一特别场邀您参加，本期联合 CNCF、阿里巴巴及蚂蚁金服共同举办。","dir":"activities/service-mesh-meetup-8/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f127ede30ff37760f648b79ecf887ffa","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-meetup-8/","publishdate":"2019-11-13T18:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-meetup-8/","summary":"概要 活动主题：Kubernetes \u0026amp; Cloud Native X Service Mesh Meetup 活动时间：2019 年 11 月 24 日（星期日）9:30-16:30 活动地点：北京朝阳大望京科技商务园","tags":["Meetup","Service Mesh","Kubernetes"],"title":"Kubernetes \u0026 Cloud Native X Service Mesh Meetup","type":"activities","url":"/sofastack.tech/activities/service-mesh-meetup-8/","wordcount":758},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@温明磊 提问： \u0026amp;gt; 出参入参都放在 Saga 的上下文中，如果参数内容较多较大，业务量又大的话，对内存有限制吗?\nA: 没有做限制，建议无关的参数不要放到上下文。下一个服务需要用的参数、或用于分支判断的参数可以放入上下文。\n 确认个事情：每个节点，要么自己方法内部 Catch 异常处理，使最终有返回信息。要么自己内部可以不处理，交由状态机引擎捕获异常，在 json 中定义 Catch 属性。 而不是补偿节点能够自动触发补偿，需要补偿必须手动在 json，由 Catch 或者 Choices 属性路由到 CompensationTrigger。\n A：对的，这个是为了提高灵活性。用户可以自己控制是否进行回滚，因为并不是所有异常都要回滚，可能有一些自定义处理手段。\n 所以 Catch 和 Choices 可以随便路由到想要的 state 对吧？\n A：是的。这种自定义出发补偿的设计是参考了 bpmn2.0 的。\n 还有关于 json 文件，我打算一条流程，就定义一个 json，虽然有的流程很像，用 Choices，可以解决。但是感觉 json 还是要尽量简单。这样考虑对吗？\n A：你可以考虑用子状态机来复用，子状态机会多生成一行 stateMachineInstance 记录，但对性能影响应该不大。\nService Mesh 相关阅读 从网络接入层到 Service Mesh，蚂蚁金服网络代理的演进之路\n 诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录\n Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录\n 蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录\n Service Mesh 发展趋势：云原生中流砥柱\n 企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录\n 蚂蚁金服Service Mesh新型网络代理的思考与实践 | GIAC 分享实录\n 蚂蚁金服 Service Mesh 渐进式迁移方案|Service Mesh Meetup 实录\n 蚂蚁金服 Service Mesh 实践探索 | Qcon 实录\n 干货 | 蚂蚁金服是如何实现经典服务化架构往 Service Mesh 方向的演进的？\n 活动推荐 2019年度TOP100全球软件案例研究峰会即将举行，蚂蚁金服也受邀参与本次案例分享。\nService Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。RPC、消息、DB、安全、运维等每一个环节均充满挑战。本次实战分享蚂蚁金服双十一核心应用如何大规模落地 Service Mesh 架构并降低大促成本。\n主题：《蚂蚁金服 Service Mesh 双十一实战》\n嘉宾：石建伟，花名：卓与，蚂蚁金服中间件技术专家，主要负责蚂蚁金服服务注册中心、配置中心与 Service Mesh 的研发与架构。当前专注在蚂蚁金服 Service Mesh 内部落地。\n时间：2019年11月15日（周五）16:50-17:50\n地点：北京国际会议中心\n报名方式：点击“这里”即可锁定席位\n","date":1573196400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191108/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4615f39bbae97f3f8b4b1705fcbc5d2f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191108/","publishdate":"2019-11-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191108/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/04 - 11/08】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191108/","wordcount":1255},{"author":"涵畅","categories":"Service mesh","content":" 本文作者：肖涵（涵畅）\n上篇文章《诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录》中，介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，帮助大家了解 Service Mesh 未来发展方向和前景。蚂蚁金服持续在进行 Service Mesh 布道和交流。本文内容整理自 10 月 26 日 Service Mesh Meetup#7 成都站主题演讲，现场视频以及分享 PPT 获取方式见文章底部。\n从网络硬件设备到自研平台，从传统服务治理到 Service Mesh，本文将介绍蚂蚁金服网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑起秒级百万支付，千万春晚咻一咻的。\n前言 在云计算和 SDN 下，我们经常听到流量的东西南北向概念，简单来说从外部 Internet 等到数据中心内部的流量走向被称为南北流量，数据中心内部的 VM 之间的流量被称为东西流量。\n当我们追踪南北向的网络流，请求通常会经过四层负载均衡，七层负载均衡等，这通常被我们称为网络接入层代理。当数据中心内部主动访问公网时候，流量通常也会经过 NAT 网关等做网络地址的转换，这也被我们称为网络代理。当我们把视角转向数据中心内部，网络代理的存在感似乎不是那么强，随着 SOA 的发展我们形成了各种成熟的服务通信框架，例如蚂蚁金服的 SOFAStack，阿里集团的 HSF，Google 的 gRPC 等等，网络代理功能被集成进了各种通信框架中，似乎已经 Proxyless 化了，但是随着微服务以及 Service Mesh 的架构提出，东西向的网络代理以独立的姿态又出现了。\n本文将围绕蚂蚁金服近十年网络代理的变迁，揭示整个蚂蚁金服接入层网络以及 Service Mesh 的演进过程，同时带来我们的思考。\n旧瓶新装 我们先来看看业界情况，传统四层负载均衡的代表产品当然是 IPVS，百度阿里等公司早年均对 IPVS 做了非常深度的定制功能，支撑了早期业务的飞速发展。接着也有 DPDK(阿里云 SLB)，类 DPDK 技术的代表 Google 的 Maglev 以及 eBPF 技术的代表 Facebook 的 Katran 出现。\n七层网络代理各个大厂均有产品代表，Google 的 GFE、百度 的 BFE、腾讯 的 TGW，阿里经济体内部也因为场景等原因有众多，例如手淘的 Aserver，集团 web 统一接入 Tengine，当然还有蚂蚁金服的 Spanner（后面会详细介绍）。同时随着 Service Mesh 概念的提出和技术的逐渐成熟，Mesh 中 Sidecar 角色的网络代理也像雨后春笋一样多了起来，包括蚂蚁金服的 SOFAMosn，Istio 社区方案的 Envoy 以及 Rust 编写的 Linkerd，当然 Service Mesh 场景的网络代理和网络接入层的代理我认为没有本质的差别，随着云原生的深入化，大家终将会形成合力并保持一致的形态。\n上图是2019年 Gartner Networking 方向的曲线，可以看到在上升和爆发区有着非常多的网络代理的影子（Secure Access Service Edge，Service Mesh，Edge Networking，Firewall as a Service etc.），虽然网络代理是一项古老的技术以及产品形态，但是仍然随着基础设施以及业务的变化以新的能力和角色展现在世人眼前。\n网络代理的十年 网络代理技术一直围绕“高效接入，访问加速，稳定高可用，安全合规”四个关键词，不断升级核心能力，架构以及运维能力，底层基础网络物理带宽从1G到10G、25G、100G；阿里骨干广域网络走出杭州扩展到全国、全球规模，不断地通过前瞻技术架构研发，技术自主能力的提升和转变，助力业务发展。\n蚂蚁金服应用网络架构概览 产品理念 我们应该以什么样的业务设计来满足上层业务以及市场的需要？产品理念决定了产品的走向，我们设定了网络产品的核心理念模型：\n网络产品设计理念\n接入层代理十年变迁 接入层网络代理的十年变迁之路，我们可以总结为三个时代，四个阶段：PC 时代、移动时代和万物互联云原生时代，伴随着这三个时代，我们经历了四个关键路径。\n前世 2010年前蚂蚁金服网络代理是商用设备的时代，包括 F5 的 bigip，Netscaler 等产品，对于商业设备白盒化，大家比较熟知的是去 IOE，其实网络设备走在了更前面。使用商用设备主要有几个问题，厂商的 Lockin，成本以及灵活扩展等问题，所以从2010年蚂蚁金服开始向自主研发演进。\n自主研发 我们同时开启了四七层网络接入的自研之路，四七层网络由于场景的不同，在整个演进路线上也有较大的差异。\n四层负载均衡 四层网络由于不理解业务语义，主要进化路线是伴随着系统技术，硬件技术的变化，围绕提高吞吐，降低延迟的目标而演进。2014年全面使用 DPDK 进行技术重构，将传统基于内核技术的 IPVS 新建，转发指标分别从万级，十万级提高到百万和千万级的每秒包转发。\n同时随着 Ebpf，Xdp 技术的出现，基于内核的高速转发平面产品又横空出世（包括 Facebook 开源的 Katran）打破了 DPDK 技术的垄断，同时可编程交换芯片以及 P4 语言也加入了这一站场，这里不具体讨论每种技术的优劣。\nSpanner Spanner 是蚂蚁金服的统一接入网关，其意为扳手，主要是为蚂蚁金服 SSL 卸载和网络接入提供了白盒化解决方案，承载了蚂蚁金服所有的业务流量，包括支付宝 App，Web，商户等的终端访问。\n金融级三地五中心架构的流量调度\n上图展示了 Spanner 的编年史，在2013年蚂蚁金服上架了自己的逻辑数据中心架构 LDC，同时随着演进支持了目前的蚂蚁金服金融级的三地五中心容灾架构：\n为了支持这套架构，蚂蚁金服的所有基础设施都进行了改造和技术升级，流量调拨能力作为最基础的能力，是一个基本盘，Spanner 通过对请求头的识别以及全站转发规则映射来实现流量调度，支撑并不限于以下场景：\n 机房内随机路由； 蓝绿发布； 容灾： 逻辑机房内容灾； 机房级别； 城市级别； 弹性调度； 压测流量调度； 灰度流量调度； SSL/TLS 实践\n蚂蚁金服作为全集团最早实践 https 全站的 BU，一直围绕着安全，合规，性能的主题进行全站加密体系的建设。\n成本之战\n前面提到2012年 Spanner 全面上线后，我们接入层具备了定制业务逻辑的能力，在2013年很好支撑了 LDC 的上线，同时我们在性能成本方面也有机会去进行持续的提升，同年我们引入 SSL 加速卡软硬件一体解决方案，从现在来看该套方案已经非常成熟了，集团 Tengine，Openssl 都提供了非常方便的接入框架，但是当年这一块还一直处于探索阶段。我们在 Spanner 里做了 Nginx 的 SSL 握手异步化改造，改造了 Openssl 同 Cavium 的 SSL 加速卡进行适配，整套方案在当时的机型上较 CPU 提升了基于 RSA2048 算法的 SSL 握手3倍的性能，同时也对后续各大厂商在这方面的实践产生了指导性意 …","date":1573030800,"description":" 从网络硬件设备到自研平台，从传统服务治理到 Service Mesh，本文将介绍蚂蚁金服网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑起秒级百万支付，千万春晚咻一咻的。","dir":"blog/antfin-service-mesh-network-agents/","fuzzywordcount":7600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b539a4c29754f9e761c2027426566250","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-service-mesh-network-agents/","publishdate":"2019-11-06T17:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/antfin-service-mesh-network-agents/","summary":"本文作者：肖涵（涵畅） 上篇文章《诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录》中，介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，帮助大家了","tags":["Service mesh"],"title":"从网络接入层到 Service Mesh，蚂蚁金服网络代理的演进之路","type":"blog","url":"/sofastack.tech/blog/antfin-service-mesh-network-agents/","wordcount":7507},{"author":"敖小剑","categories":"Service mesh","content":" 2019 年，蚂蚁金服在 Service Mesh 领域继续高歌猛进，进入大规模落地的深水区。本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的演讲，他介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，以及大规模落地时遇到的困难和解决方案，助你了解 Service Mesh 的未来发展方向和前景。\n 前言 大家好，我是敖小剑，来自蚂蚁金服中间件团队，今天带来的主题是“诗和远方：蚂蚁金服 Service Mesh 深度实践”。\n在过去两年，我先后在 QCon 做过两次 Service Mesh 的演讲：\n 2017年，当时 Service Mesh 在国内还属于蛮荒时代，我当时做了一个名为“Service Mesh: 下一代微服务”的演讲，开始在国内布道 Service Mesh 技术； 2018年，做了名为“长路漫漫踏歌而行：蚂蚁金服 Service Mesh 实践探索”的演讲，介绍蚂蚁金服在 Service Mesh 领域的探索性的实践，当时蚂蚁金服刚开始在 Service Mesh 探索。 今天，有幸第三次来到 QCon，给大家带来的依然是蚂蚁金服在 Service Mesh 领域的实践分享。和去年不同的是，今年蚂蚁金服进入了 Service Mesh 落地的深水区，规模巨大，而且即将迎来双十一大促考验。\n 备注：现场做了一个调研，了解听众对 Servicve Mesh 的了解程度，结果不太理想：在此之前对 Service Mesh 有了解的同学目测只有10%多点（肯定不到20%）。Service Mesh 的技术布道，依然任重道远。\n 今天给大家带来的内容主要有三块：\n 蚂蚁金服落地情况介绍：包括大家最关心的双十一落地情况； 大规模落地的困难和挑战：分享一下我们过去一年中在大规模落地上遇到的问题； 是否采用 Service Mesh 的建议：这个问题经常被人问起，所以借这个机会给出一些中肯的建议供大家参考； 蚂蚁金服落地情况介绍 发展历程和落地规模 Service Mesh 技术在蚂蚁金服的落地，先后经历过如下几个阶段：\n 技术预研 阶段：2017年底开始调研并探索 Service Mesh 技术，并确定为未来发展方向； 技术探索 阶段：2018年初开始用 Golang 开发 Sidecar SOFAMosn，年中开源基于 Istio 的 SOFAMesh； 小规模落地 阶段：2018年开始内部落地，第一批场景是替代 Java 语言之外的其他语言的客户端 SDK，之后开始内部小范围试点； 规模落地 阶段：2019年上半年，作为蚂蚁金融级云原生架构升级的主要内容之一，逐渐铺开到蚂蚁金服内部的业务应用，并平稳支撑了618大促； 全面大规模落地 阶段：2019年下半年，在蚂蚁金服内部的业务中全面铺开，落地规模非常庞大，而且准备迎接双十一大促； 目前 ServiceMesh 正在蚂蚁金服内部大面积铺开，我这里给出的数据是前段时间（大概9月中）在云栖大会上公布的数据：应用数百个，容器数量（pod 数）超过10万。当然目前落地的pod数量已经远超过10万，这已经是目前全球最大的 Service Mesh 集群，但这仅仅是一个开始，这个集群的规模后续会继续扩大，明年蚂蚁金服会有更多的应用迁移到 Service Mesh。\n主要落地场景 目前 Service Mesh 在蚂蚁金服内部大量落地，包括支付宝的部分核心链路，落地的主要场景有：\n 多语言支持：目前除了支持 Java 之外，还支持 Golang，Python，C++，NodeJS 等语言的相互通信和服务治理； 应用无感知的升级：关于这一点我们后面会有特别的说明； 流量控制：经典的 Istio 精准细粒度流量控制； RPC 协议支持：和 Istio 不同，我们内部使用的主要是 RPC 协议； 可观测性； Service Mesh 的实际性能数据 之前和一些朋友、客户交流过，目前在 Service Mesh 方面大家最关心的是 Service Mesh 的性能表现，包括对于这次蚂蚁金服 Service Mesh 上双十一，大家最想看到的也是性能指标。\n为什么大家对性能这么关注？\n因为在 Service Mesh 工作原理的各种介绍中，都会提到 Service Mesh 是将原来的一次远程调用，改为走 Sidecar（而且像 Istio 是客户端和服务器端两次 Sidecar，如上图所示），这样一次远程调用就会变成三次远程调用，对性能的担忧也就自然而然的产生了：一次远程调用变三次远程调用，性能会下降多少？延迟会增加多少？\n下图是我们内部的大促压测数据，对比带 SOFAMosn 和不带 SOFAMosn 的情况（实现相同的功能）。其中 SOFAMosn 是我们蚂蚁金服自行开发的基于 Golang 的 Sidecar/数据平面，我们用它替代了 Envoy，在去年的演讲中我有做过详细的介绍。\nSOFAMosn：https://github.com/sofastack/sofa-mosn\n CPU：CPU 使用在峰值情况下增加8%，均值约增加2%。在最新的一次压测中，CPU 已经优化到基本持平（低于1%）； 内存：带 SOFAMosn 的节点比不带 SOFAMosn 的节点内存占用平均多 15M； 延迟：延迟增加平均约0.2ms。部分场景带 SOFAMosn 比不带 SOFAMosn RT 增加约5%，但是有部分特殊场景带 SOFAMosn 比不带 SOFAMosn RT 反而降低7.5%； 这个性能表现，和前面\u0026amp;rdquo;一次远程调用变三次远程调用\u0026amp;rdquo;的背景和担忧相比有很大的反差。尤其是上面延迟的这个特殊场景，居然出现带 SOFAMosn（三次远程调用）比不带 SOFAMosn（一次远程调用） 延迟反而降低的情况。\n是不是感觉不科学？\nService Mesh 的基本思路 我们来快速回顾一下 Service Mesh 实现的基本思路：\n在基于 SDK 的方案中，应用既有业务逻辑，也有各种非业务功能。虽然通过 SDK 实现了代码重用，但是在部署时，这些功能还是混合在一个进程内的。\n在 Service Mesh 中，我们将 SDK 客户端的功能从应用中剥离出来，拆解为独立进程，以 Sidecar 的模式部署，让业务进程专注于业务逻辑：\n 业务进程：专注业务实现，无需感知 Mesh； Sidecar 进程：专注服务间通讯和相关能力，与业务逻辑无关； 我们称之为\u0026amp;rdquo;关注点分离\u0026amp;ldquo;：业务开发团队可以专注于业务逻辑，而底层的中间件团队（或者基础设施团队）可以专注于业务逻辑之外的各种通用功能。\n通过 Sidecar 拆分为两个独立进程之后，业务应用和 Sidecar 就可以实现“独立维护”：我们可以单独更新/升级业务应用或者 Sidecar。\n性能数据背后的情景分析 我们回到前面的蚂蚁金服 Service Mesh 落地后的性能对比数据：从原理上说，Sidecar 拆分之后，原来 SDK 中的各种功能只是拆分到 Sidecar 中。整体上并没有增减，因 …","date":1572922800,"description":" 本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的演讲。","dir":"blog/service-mesh-antfin-deep-practice-qcon/","fuzzywordcount":12500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"561edcf88763b36e72894da214d2b123","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","publishdate":"2019-11-05T11:00:00+08:00","readingtime":25,"relpermalink":"/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","summary":"2019 年，蚂蚁金服在 Service Mesh 领域继续高歌猛进，进入大规模落地的深水区。本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的","tags":["Service mesh"],"title":"诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","wordcount":12438},{"author":"屹远","categories":"Seata","content":" Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的 Saga 模式。 项目地址：https://github.com/seata/seata\n本文作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。\n金融分布式应用开发的痛点 分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。\u0026amp;mdash;《左耳听风-弹力设计之“补偿事务”》\n而在金融领域微服务架构下的业务流程往往会更复杂，流程很长，比如一个互联网微贷业务流程调十几个服务很正常，再加上异常处理的流程那就更复杂了，做过金融业务开发的同学会很有体感。\n所以在金融分布式应用开发过程中我们面临一些痛点：\n 业务一致性难以保障 我们接触到的大多数业务（比如在渠道层、产品层、集成层的系统），为了保障业务最终一致性，往往会采用“补偿”的方式来做，如果没有一个协调器来支持，开发难度是比较大的，每一步都要在 catch 里去处理前面所有的“回滚”操作，这将会形成“箭头形”的代码，可读性及维护性差。或者重试异常的操作，如果重试不成功可能要转异步重试，甚至最后转人工处理。这些都给开发人员带来极大的负担，开发效率低，且容易出错。\n 业务状态难以管理 业务实体很多、实体的状态也很多，往往做完一个业务活动后就将实体的状态更新到了数据库里，没有一个状态机来管理整个状态的变迁过程，不直观，容易出错，造成业务进入一个不正确的状态。\n 幂等性难以保障 服务的幂等性是分布式环境下的基本要求，为了保证服务的幂等性往往需要服务开发者逐个去设计，有用数据库唯一键实现的，有用分布式缓存实现的，没有一个统一的方案，开发人员负担大，也容易遗漏，从而造成资损。\n 业务监控运维难，缺乏统一的差错守护能力 业务的执行情况监控一般通过打印日志，再基于日志监控平台查看，大多数情况是没有问题的，但是如果业务出错，这些监控缺乏当时的业务上下文，对排查问题不友好，往往需要再去数据库里查。同时日志的打印也依赖于开发，容易遗漏。对于补偿事务往往需要有“差错守护触发补偿”、“工人触发补偿”操作，没有统一的差错守护和处理规范，这些都要开发者逐个开发，负担沉重。\n理论基础 一些场景下，我们对数据有强一致性的需求时，会采用在业务层上需要使用“两阶段提交”这样的分布式事务方案。而在另外一些场景下，我们并不需要这么强的一致性，那就只需要保证最终一致性就可以了。\n例如蚂蚁金服目前在金融核心系统使用的就是 TCC 模式，金融核心系统的特点是一致性要求高（业务上的隔离性）、短流程、并发高。\n而在很多金融核心以上的业务（比如在渠道层、产品层、集成层的系统），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务（如金融网络）。这是如果每个服务都开发 Try、Confirm、Cancel 三个方法成本高。如果事务中有其它公司的服务，也无法要求其它公司的服务也遵循 TCC 这种开发模式。同时流程长，事务边界太长会影响性能。\n对于事务我们都知道 ACID，也很熟悉 CAP 理论最多只能满足其中两个，所以，为了提高性能，出现了 ACID 的一个变种 BASE。ACID 强调的是一致性（CAP 中的 C），而 BASE 强调的是可用性（CAP 中的 A）。我们知道，在很多情况下，我们是无法做到强一致性的 ACID 的。特别是我们需要跨多个系统的时候，而且这些系统还不是由一个公司所提供的。BASE 的系统倾向于设计出更加有弹力的系统，在短时间内，就算是有数据不同步的风险，我们也应该允许新的交易可以发生，而后面我们在业务上将可能出现问题的事务通过补偿的方式处理掉，以保证最终的一致性。\n所以我们在实际开发中会进行取舍，对于更多的金融核心以上的业务系统可以采用补偿事务，补偿事务处理方面在30年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较也公认 Saga 是作为长事务的解决方案。 \u0026amp;gt; https://github.com/aphyr/dist-sagas/blob/master/sagas.pdf \u0026amp;gt; http://microservices.io/patterns/data/saga.html\n社区和业界的方案 Apache Camel Saga Camel 是实现 EIP（Enterprise Integration Patterns）企业集成模式的一款开源产品，它基于事件驱动的架构，有着良好的性能和吞吐量，它在2.21版本新增加了 Saga EIP。\nSaga EIP 提供了一种方式可以通过 camel route 定义一系列有关联关系的 Action，这些 Action 要么都执行成功，要么都回滚，Saga 可以协调任何通讯协议的分布式服务或本地服务，并达到全局的最终一致性。Saga 不要求整个处理在短时间内完成，因为它不占用任何数据库锁，它可以支持需要长时间处理的请求，从几秒到几天，Camel 的 Saga EIP 是基于 Microprofile 的 LRA（Long Running Action），同样也是支持协调任何通讯协议任何语言实现的分布式服务。\nSaga 的实现不会对数据进行加锁，而是在给操作定义它的“补偿操作”，当正常流程执行出错的时候触发那些已经执行过的操作的“补偿操作”，将流程回滚掉。“补偿操作”可以在 Camel route 上用 Java 或 XML DSL（Definition Specific Language）来定义。\n下面是一个 Java DSL 示例：\n// action from(\u0026amp;quot;direct:reserveCredit\u0026amp;quot;) .bean(idService, \u0026amp;quot;generateCustomId\u0026amp;quot;) // generate a custom Id and set it in the body .to(\u0026amp;quot;direct:creditReservation\u0026amp;quot;) // delegate action from(\u0026amp;quot;direct:creditReservation\u0026amp;quot;) .saga() .propagation(SagaPropagation.SUPPORTS) .option(\u0026amp;quot;CreditId\u0026amp;quot;, body()) // mark the current body as needed in the compensating action .compensation(\u0026amp;quot;direct:creditRefund\u0026amp;quot;) .bean(creditService, \u0026amp;quot;reserveCredit\u0026amp;quot;) .log(\u0026amp;quot;Credit ${header.amount} …","date":1572861600,"description":" 一起来解读 Seata Saga 模式到底解决了什么问题。","dir":"blog/seata-saga-flexible-financial-applications/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9c17449b81e0f1fe51d46bbaeaaa5516","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-saga-flexible-financial-applications/","publishdate":"2019-11-04T18:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/seata-saga-flexible-financial-applications/","summary":"Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的","tags":["Seata"],"title":"基于 Seata Saga 设计更有弹性的金融应用","type":"blog","url":"/sofastack.tech/blog/seata-saga-flexible-financial-applications/","wordcount":6384},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@罗健 提问： \u0026amp;gt; SOFAJRaft 跨机房支持吗？\nA： 跨机房不需要特殊支持，只是网络延时大一点而已。\n 延时大了，读写性能就会降低了吧？ 像 ZooKeeper 一样。\n A：1. SOFAJRaft 支持 transfer leader，把 leader transfer 到和业务就近的机房（目前需要手动调用 cli 服务）； 2. SOFAJRaft 1.3.0 会增加一个选举优先级特性，可以将指定机房节点优先级调高，尽量保证 leader 在指定机房。 SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@阮仁照 提问： \u0026amp;gt; SOFAArk 在打多个 ark-biz 包时，如果有多个 biz 包之间互相调用，默认是会走 injvm 协议的，这是如何做到的。我看了 SOFABoot 那块对 injvm 的支持，是通过 sofaRuntimeContext 来查找实现类，sofaRuntimeContext 是被 spring 容器管理的 bean，这就要求多个 biz 包之间是共用一套 spring 环境（或者说有个统一的父容器），是这样的吗？还是有什么其他实现的思路？\nA：可以看下 com.alipay.sofa.runtime.invoke.DynamicJvmServiceProxyFinder 这个类。\n 懂了，原来在这之上还有个 SofaFramework维护一个静态变量，真巧妙，用这个来解决多个 spring 容器里的 rpc 调用问题吗？\n A：多个 spring 容器之间的调用，不是 rpc 调用，是进程内调用。\n 对的， 这里不是 rpc 调用了， 所以这里也是 filter 会失效的原因。这样的话，那 SofaFramework 这个类就要被所有子容器都共享才对，但是我看打出来的 executable-ark 包，并没有在 classpath 下加载这个类啊，子容器咋共享的？\n A：这个会打包成一个插件，放在 ark plugin 层。 既然说插件之间是隔离的，那你把 SofaFramework 打在插件里，别的 biz 包启动时从会从 plugin里拿一个 SofaFramework ，互相不可见，这不是有问题吗？\n A：不同 biz 会共享同一个。 SOFAArk：https://github.com/sofastack/sofa-ark\n3、@温明磊 提问： \u0026amp;gt; Seata 的 Saga 模式的 json 文件，支持热部署吗？\nA：支持，stateMachineEngine.getStateMachineConfig().getStateMachineRepository().registryByResources()。不过 Java 代码和服务需要自己实现支持热部署。\n Seata 服务部署集群是需要怎么配置? 还是现在不支持\n A：异步执行一个服务，已实现。https://github.com/seata/seata/issues/1843\n Saga 的参数是不是只能在状态机启动时定义。如果第二个服务，依赖第一个服务返回的信息，或者里面组装好的信息怎么办？\n A：有个 Output 参数定义，可以把服务返回的参数映射到状态机上下文，然后在下一个服务的 Input 里定义参数引用。\n 异步执行服务的话，需要在 file 加上这个配置吗? A：这个是状态机定义的 Json 文件，不是 Seata 的客户端配置文件。 Seata：https://github.com/seata/seata\n本周推荐阅读 备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？\n K8s 1.14 发布了，Release Note 该怎么读？\n SOFA 项目进展 本周发布详情如下：\n发布 SOFAMosn v0.8.0，主要变更如下： i. 内存占用优化，优化在连接数、并发数较多的场景下的内存占用 ii. Metrics 统计优化，RPC 心跳场景不计入 QPS 等 Metrics 统计 iii. XDS 处理优化，修改为完全无阻塞启动，并且降低了重试的频率 详细发布报告，请见： https://github.com/sofastack/sofa-mosn/releases/tag/0.8.0\n","date":1572591600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191101/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cd5f758d6d5d28784524b55169ae0a98","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191101/","publishdate":"2019-11-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191101/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/28 - 11/01】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191101/","wordcount":1512},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:ArkLab/\u0026amp;gt;是《剖析 | SOFAArk 源码》系列，会逐步详细介绍 SOFAArk 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFAArk SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力。在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\nSOFAArk :https://github.com/sofastack/sofa-ark\n|\u0026amp;lt; SOFA:ArkLab/\u0026amp;gt; 认领列表：\n 【已完成】轻量级类隔离框架 SOFAArk 简介 【已认领】 SOFAArk 容器模型解析 【已认领】 SOFAArk 类加载模型机制解析 【已认领】 SOFAArk 合并部署能力解析 【已认领】 SOFAArk SPI 机制和 ClassLoaderHook 机制解析 【已认领】 SOFAArk 动态配置机制解析 【已认领】 SOFAArk maven 打包插件解析 【已认领】 （实践）SOFAArk 插件化机制解析与实践 领取方式：关注「金融级分布式架构」 回复可领取的文章标题，我们将会主动联系你，确认资质后，即可加入 SOFA:ArkLab/，It\u0026amp;rsquo;s your show time！\n 如果有同学对以上某个主题特别感兴趣的，可以留言讨论，我们会适当根据大家的反馈调整文章的顺序，谢谢大家关注 SOFAStack ，关注 SOFAArk，我们会一直与大家一起成长的。\n除了源码解析，也欢迎提交 issue 和 PR： SOFAArk :https://github.com/sofastack/sofa-ark\n欢迎领取，参与共建~\n","date":1572408000,"description":"欢迎参与 SOFAArk 源码解析系列文章共建。","dir":"activities/sofa-ark-lab/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"02869baa65a4730cea247cf1763d920c","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-ark-lab/","publishdate":"2019-10-30T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-ark-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:ArkLab/\u0026gt;是《剖析 | SOFAArk 源码》系列，会逐步详细介","tags":["SOFALab","SOFAArk","剖析 | SOFAArk 源码"],"title":"\u003cSOFA:ArkLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-ark-lab/","wordcount":572},{"author":"沧漠","categories":"Kubernetes","content":" 本文 PPT 下载\n导读：Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统，它大幅降低了容器化应用部署的门槛，但运维和管理一个生产级的高可用 Kubernetes 集群仍十分困难。本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。\nKubernetes 以其超前的设计理念和优秀的技术架构，在容器编排领域拔得头筹。越来越多的公司开始在生产环境部署实践 Kubernetes，在阿里巴巴和蚂蚁金服 Kubernetes 已被大规模用于生产环境。\n系统概览 Kubernetes 集群管理系统需要具备便捷的集群生命周期管理能力，完成集群的创建、升级和工作节点的管理。在大规模场景下，集群变更的可控性直接关系到集群的稳定性，因此管理系统可监控、可灰度、可回滚的能力是系统设计的重点之一。除此之外，超大规模集群中，节点数量已经达到 10K 量级，节点硬件故障、组件异常等问题会常态出现。面向大规模集群的管理系统在设计之初就需要充分考虑这些异常场景，并能够从这些异常场景中自恢复。\n设计模式 基于这些背景，我们设计了一个面向终态的集群管理系统。系统定时检测集群当前状态，判断是否与目标状态一致，出现不一致时，Operators 会发起一系列操作，驱动集群达到目标状态。这一设计参考控制理论中常见的负反馈闭环控制系统，系统实现闭环，可以有效抵御系统外部的干扰，在我们的场景下，干扰对应于节点软硬件故障。\n架构设计 如上图，元集群是一个高可用的 Kubernetes 集群，用于管理 N 个业务集群的 Master 节点。业务集群是一个服务生产业务的 Kubernetes 集群。SigmaBoss 是集群管理入口，为用户提供便捷的交互界面和可控的变更流程。元集群中部署的 Cluster-Operator 提供了业务集群集群创建、删除和升级能力，Cluster-Operator 面向终态设计，当业务集群 Master 节点或组件异常时，会自动隔离并进行修复，以保证业务集群 Master 节点达到稳定的终态。这种采用 Kubernetes 管理 Kubernetes 的方案，我们称作 Kube on Kube 方案，简称 KOK 方案。业务集群中部署有 Machine-Operator 和节点故障自愈组件用于管理业务集群的工作节点，提供节点新增、删除、升级和故障处理能力。在 Machine-Operator 提供的单节点终态保持的能力上，SigmaBoss 上构建了集群维度灰度变更和回滚能力。\n核心组件 集群终态保持器 基于 K8s CRD，在元集群中定义了 Cluster CRD 来描述业务集群终态，每个业务集群对应一个 Cluster 资源，创建、删除、更新 Cluster 资源对应于实现业务集群创建、删除和升级。Cluster-Operator watch Cluster 资源，驱动业务集群 Master 组件达到 Cluster 资源描述的终态。业务集群 Master 组件版本集中维护在 ClusterPackageVersion CRD 中，ClusterPackageVersion 资源记录了 Master 组件（如：api-server、controller-manager、scheduler、operators 等）的镜像、默认启动参数等信息。Cluster 资源唯一关联一个 ClusterPackageVersion，修改 Cluster CRD 中记录的 ClusterPackageVersion 版本即可完成业务集群 Master 组件发布和回滚。\n节点终态保持器 Kubernetes 集群工作节点的管理任务主要有：\n 节点系统配置、内核补丁管理； docker / kubelet 等组件安装、升级、卸载； 节点终态和可调度状态管理（如关键 DaemonSet 部署完成后才允许开启调度）； 节点故障自愈。 为实现上述管理任务，在业务集群中定义了 Machine CRD 来描述工作节点终态，每一个工作节点对应一个 Machine 资源，通过修改 Machine 资源来管理工作节点。\nMachine CRD 定义如下图所示，spec 中描述了节点需要安装的组件名和版本，status 中记录有当前这个工作节点各组件安装运行状态。除此之外，Machine CRD 还提供了插件式终态管理能力，用于与其它节点管理 Operators 协作，这部分会在后文详细介绍。\n工作节点上的组件版本管理由 MachinePackageVersion CRD 完成。MachinePackageVersion 维护了每个组件的 rpm 版本、配置和安装方法等信息。一个 Machine 资源会关联 N 个不同的 MachinePackageVersion，用来实现安装多个组件。\n在 Machine、MachinePackageVersion CRD 基础上，设计实现了节点终态控制器 Machine-Operator。Machine-Operator watch Machine 资源，解析 MachinePackageVersion，在节点上执行运维操作来驱动节点达到终态，并持续守护终态。\n节点终态管理 随着业务诉求的变化，节点管理已不再局限于安装 docker / kubelet 等组件，我们需要实现如等待日志采集 DaemonSet 部署完成才可以开启调度的需求，而且这类需求变得越来越多。如果将终态统一交由 Machine-Operator 管理，势必会增加 Machine-Operator 与其它组件的耦合性，而且系统的扩展性会受到影响。因此，我们设计了一套节点终态管理的机制，来协调 Machine-Operator 和其它节点运维 Operators。设计如下图所示：\n 全量 ReadinessGates: 记录节点可调度需要检查的 Condition 列表； Condition ConfigMap: 各节点运维 Operators 终态状态上报 ConfigMap； 协作关系：\n 外部节点运维 Operators 检测并上报与自己相关的子终态数据至对应的 Condition ConfigMap； Machine-Operator 根据标签获取节点相关的所有子终态 Condition ConfigMap，并同步至 Machine status 的 conditions 中； Machine-Operator 根据全量 ReadinessGates 中记录的 Condition 列表，检查节点是否达到终态，未达到终态的节点不开启调度。 节点故障自愈 我们都知道物理机硬件存在一定的故障概率，随着集群节点规模的增加，集群中会常态出现故障节点，如果不及时修复上线，这部分物理机的资源将会被闲置。\n为解决这一问题，我们设计了一套故障发现、隔离、修复的闭环自愈系统。\n如下图所示，故障发现方面，采取 Agent 上报和监控系统主动探测相结合的方式，保证了故障发现的实时性和可靠性（Agent 上报实时性比较好，监控系统主动探测可以覆盖 Agent 异常未上 …","date":1572246000,"description":"本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。","dir":"blog/ant-financial-managing-large-scale-kubernetes-clusters/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0fbce82d736863f9039c6a8f15c6f5d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","publishdate":"2019-10-28T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","summary":"本文 PPT 下载 导读：Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统，它大幅降低了容器化应用部署的门槛，但运维和管理一个生产级","tags":["Kubernetes"],"title":"备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？","type":"blog","url":"/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","wordcount":4899},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@罗健 提问：\n 请问，SOFAJRaft 跨机房支持吗？\n A：跨机房不需要特殊支持，只是网络延时大一点而已。\n 延时大了，读写性能就会降低了吧？ 像 ZooKeeper 一样。\n A：1. SOFAJRaft 支持 transfer leader，把 leader transfer 到和业务就近的机房（目前需要手动调用 cli 服务） 2. SOFAJRaft 1.3.0 会增加一个选举优先级特性，可以将指定机房节点优先级调高，尽量保证 leader 在指定机房。\n2、@梁开心 提问：\n 使用 Seata 的时候，现在是 AT 模式 如果改成 Saga 模式的话，改造会大吗？\n A：AT 模式完全是透明的，Saga 是有侵入性的，要配置状态机 json，如果服务多改造会比较大。\n Saga 模式是不是基于 AT 来加强的长事务处理呢？\n A：没有基于 AT，客户端完全是两套，Server 端是复用的。你也可以看 Saga 的单元测试，那里有很多示例：https://github.com/seata/seata/tree/develop/test/src/test/java/io/seata/saga/engine\n Saga 服务流程可以不配置吗，使用全局事务 id 串起来，这样省去配置的工作量，再加上人工配置难免会配置错误。\n A：Saga 一般有两种实现，一种是基于状态机定义，比如 apache camel saga、eventuate，一种是基于注解+拦截器实现，比如 service comb saga，后者是不需要配置状态图的。由于 Saga 事务不保证隔离性, 在极端情况下可能由于脏写无法完成回滚操作, 比如举一个极端的例子, 分布式事务内先给用户 A 充值, 然后给用户B扣减余额, 如果在给 A 用户充值成功, 在事务提交以前, A 用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了，有些业务场景可以允许让业务最终成功, 在回滚不了的情况下可以继续重试完成后面的流程, 基于状态机引擎除可以提供“回滚”能力外, 还可以提供“向前”恢复上下文继续执行的能力, 让业务最终执行成功, 达到最终一致性的目的，所以在实际生产中基于状态机的实现应用更多。后续也会提供基于注解+拦截器实现。\n3、@温明磊 提问：\n 关于 Saga 的使用，有两个问题咨询下 1、比如有服务 A 在系统1里面，服务 B 在系统2里面。全局事务由 A 开启，流程调用 B 开启子事务，那系统2也需要维护 Saga 状态机的三个表吗，也需要在 Spring Bean 配置文件中配置一个 StateMachineEngine 吗？\n2、如果 系统1和系统2里面的服务，可以相互调用。系统12都可以开启全局事务，可以这样使用吗。那1和2 都需要维护Saga状态机的三个表，也需要在Spring Bean配置文件中配置一个StateMachineEngine。\n A：1、不需要，只在发起方记录日志。由于只在发起方记录日志同时对参与者服务没有接口参数的要求，使得Saga可以方便集成其它机构或遗留系统的服务。 2、可以这样使用，如果两个系统都开启 Saga 事务，那就要记录那三个表配置 StateMachineEngine。\n 这个 EventQueue 只是开启分布式事务的系统 来进行事件驱动，调用其它系统服务像调用本地一样。系统之间还是 RPC 调用是吧，而不是系统之前也是纯事件驱动的？ A：是的。你指的\u0026amp;rdquo;系统之间也是纯事件驱动的\u0026amp;rdquo; 是不是说 RPC 也是非阻塞的？\n 是的，也可以是异步的。\n A：那 RPC 的非阻塞需要 rpc client 支持，理论上也是可以的。rpc client 如果也是非阻塞 IO，那么所有环节都是异步了。\n 就是考虑一个业务流程， 它后续的子流程， 不管谁先运行都不会相互影响，可以异步调用。子流程是其它系统服务。Seata Saga 是不是实现了这点，其实我没看明白 ，Seata Saga 异步调用具体是不是各个节点异步了。是不是两个 ServiceTask 类型，可以同时 process ？\n A：你说的是并发节点类型，还未实现，接下来会实现。目前的事件驱动是指的节点的执行是事件驱动的，流程的顺序是同步的。上一个节点执行完成后，产生事件，触发下一个节点执行。如果要满足你刚说的需求要扩展并发节点。\n 那目前区分同步 BUS 和异步 BUS 是什么作用？\n A：同步 BUS 是线程阻塞的，等整个状态机执行完毕才返回，异步 BUS 是非线程阻塞的，调用后立即返回，状态机执行完毕后回调你的 Callback。\n IsPersist: 执行日志是否进行存储，默认是 true，有一些查询类的服务可以配置在 false，执行日志不进行存储提高性能，因为当异常恢复时可以重复执行？\n A：是的，可以配置成 false, 不过建议先保持默认，这样在查询执行日志比较全，真的要做性能调优再配，一般不会有性能问题。\n每周推荐阅读 蚂蚁金服开源背后的“有意思”工程师 | 1024快乐 蚂蚁金服云原生专家招聘 | 1024有你更快乐 SOFA 项目进展 本周发布详情如下：\n1、Occlum 是一个多任务、内存安全的库操作系统，专门针对可信执行环境（如 Intel SGX）。\n发布 Occlum v0.6.0，主要变更如下： i. 支持 release 模式运行 enclave，轻松发布基于 Occlum 的 SGX 应用； ii. 给 SEFS 增加额外的 MAC 和权限检查，保证 Occlum 的 FS 镜像的完整性； iii. 重构底层错误处理机制，使得报错对用户友好，且附带详细的调试信息； iv. 增加3个新 demo，包括 Bazel、HTTPS file server 和 Tensorflow Lite； v. 在 Docker 镜像中默认安装 Occlum，使得用户开箱即用； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.6.0\n2、发布SOFARPC v5.5.9，主要变更如下： …","date":1571986800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191025/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7927ee3392339de5283b8c4e75f9b4e9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191025/","publishdate":"2019-10-25T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191025/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/21 - 10/25】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191025/","wordcount":2571},{"author":"SOFAStack","categories":"1024","content":" !important 希望我们是最早给你祝福的朋友\n去年的1024，我们回顾了第一代到第五代架构 去年的今天，我们和大家分享了 SOFAStack 背后的这群工程师。比如程立，花名鲁肃，蚂蚁金服 CTO。胡喜，蚂蚁金服副总裁、副CTO。杨冰，蚂蚁金服智能科技产品技术部总监。\n也与大家分享了从第一代到第五代架构的进化历程，详解了 SOFAStack 走的这一条跟传统金融行业不同的分布式架构之路。要基于不可靠的硬件系统实现金融级的性能和可靠性，要应对支付宝这样的超大规模互联网金融应用，有很多难题要解决。蚂蚁金服构建了一整套处理金融级交易的分布式架构与平台，在金融级的一致性要求和海量并发处理能力上达到了很好的平衡，并在快速容灾恢复、弹性伸缩能力、多地多活高可用保证能力和按需供给的精细化资源调度能力方面沉淀了丰富的实践经验。\n前往去年此刻的时光机：蚂蚁金服自研架构SOFA背后的工程师|1024快乐\n今年，SOFAStack 团队在忙什么呢？ 近几年来，“云原生架构”的相关话题讨论比较热烈，我们也相信这也将是金融 IT 架构的关键发展趋势之一。IT 架构转型绝不是一蹴而就的，积极探索和应用以“云原生”为代表的新兴技术的同时，还需考虑与传统模式和技术融合并存，沿着一条稳妥的可落地路径进行创新变革，确保架构转型的价值交付能够稳妥支撑甚至积极引领业务创新。\nService Mesh 是蚂蚁金服下一代架构的核心，这一年，我们在奔跑的火车上换轮子，将现有的微服务架构快速演进到云原生架构。RPC、消息、DB、安全、运维等每一个环节均充满挑战。\n蚂蚁金服每年双十一大促会面临非常大的流量挑战，在已有 LDC 微服务架构下已支撑起弹性扩容能力。当有多个大促分阶段进行时，如何在架构上保障资源最大程度复用降低大促成本极具挑战。期望在最小规模的资源集群下可通过灵活的架构来支撑起快速的资源腾挪来达成多个大促链路最大化利用资源的目的。通过 Service Mesh 架构的支持，基础设施层在应用外具备更强的管控能力，通过流量的调拨，JVM 内存的动态 Swap 等手段可以使用技术手段达成节省资源的目的。 今年即将到来的双十一，蚂蚁金服这套 Service Mesh 将迎来第一次大考 — 双十一实战，也或许是业界第一个如此大规模的实战，请持续关注本公众号，我们会逐步进行技术揭秘。\n今天，我们想介绍蚂蚁金服开源背后的这位“有意思”工程师： 对于蚂蚁金服研究员王益而言，2019年是个颇有纪念意义的年份。今年他整40岁。从10岁开始，写代码整30年。这30年来，他当过“不务正业”的学生，创纪录地在大一就考下系统分析员，“单枪匹马”闯荡过从国内到硅谷的多家知名互联网科技公司，和AI领域许多传奇人物都有所交集。不惑之年对于许多工程师来说，或许已是需要焦虑的年龄，但40岁的王益在蚂蚁金服每天都过得很充实：起床，自由泳一千米，然后去做他最喜欢的事——写代码和组织大家一起写代码。\n 2019年9月11日，在上海举办的Google开发者大会上，蚂蚁金服研究员王益分享了新开发的分布式深度学习系统ElasticDL。这是他来到蚂蚁金服的一年之中所做的第二个开源项目，主要用于大幅提升集群总体利用率以及深度学习团队的工作效能。之前开源的 SQLFlow系统在短短的几个月之间，已经在GitHub上获得了三千多颗星星。\n2019对于王益而言是个颇有纪念意义的年份，今年他整40岁，写代码整30年。 这听上去是一件不可思议的事——30年前，上世纪的80年代末，他在⻓沙上小学，全城都很难找出一位能教编程的老师，个人电脑更是一个陌生名词，一台以苹果2为原型、可以用BASIC语言编程的 “中华学习机”售价7000人民币，在当时几乎可以买下一套房子。\n幸运的是，王益在10岁那年得到了这样一件贵重的礼物，从这台学习机和一本BASIC语言教材开始，他开启了与代码结缘的人生。\n“我那时不是个好学生，经常受‘别人家的孩子’打击，老师和同学都觉得写代码是不务正业。”回想起30年来的经历，这位清华博士、足迹从国内到硅谷历经多家知名互联网科技公司的学霸笑谈自己“活得比较任性”，“但我就是想做与众不同的事。别人越说这样不行，我就越想用这种方式证明自己。”\n初中毕业那年的暑假，他用“中华学习机”和自己焊接的电路板，把自家的老式“威力牌”双筒洗衣机改造成了自动洗衣机。同时，他用Apple BASIC语言和6502汇编混合编程，写了人生中第一个游戏。高中三年，其他同学努力备考，他却加班加点自学了大学计算机系所有课程，随后参加计算机水平考试，先后获得了程序员、高级程序员、以及最高级别系统分析员资格。2018年，他获得Google APAC Innovation Award。从不断摸索代码世界的少年时代，到专注于AI基础架构和系统开发的求学工作生涯，这份“任性”一直伴随他走到今天。\n“我经常从零开始。选择去做什么的一大标准是‘有意思’。”\n相比于规划一条稳妥的职业发展道路，王益更愿意顺应自己强烈的好奇心，去选择最困难但最有意思的探索方向。他在中国和美国互联网公司都工作过，也分别在美国公司的中国分部和中国公司的美国分部工作过。他的足迹遍及国内BAT三家。任性的是，每次跳槽， 他都从一个人coding一个创新项目开始，吸引同事们加入，从而组建团队。虽然2011年就在腾讯作为广告系统技术总监，但是他从不在跳槽时要求带何等规模的团队。\n2014年，王益带着妻子和两个月大的女儿离开腾讯移居硅谷。“一切都归零了。工资减半。”他笑笑说。不过凭着多位学界和业界领袖的推荐，他很快就安顿下来，不到一年就开始在硅谷创业，作为Head of Research Scienets 参与创建了AI创业公司 ScaledInference。这是一家人才济济的创业公司。人工智能行业的领袖人物、加州大学伯克利分校的Michael Jordan教授是这家公司顾问。陆奇曾代表微软到访，讨论技术合作。“可惜我们不够关注业务落地，做的不够好。技术研发一定要有落地的能力。”事后，王益不无遗憾的说。\n在加入蚂蚁金服之前，王益在百度硅谷研究院工作，负责开源深度学习系统PaddlePaddle。在历经两年的艰苦开发，新一代技术Fluid开始系统地落地百度各个业务之后，他发起了他在 PaddlePaddle的最后一个子项目——一条太阳能驱动的无人驾驶船。这是一条双体船，由他和五岁女儿的两条划艇构成。船上的笔记本电脑运行基于immitation learning的人工智能系统，自动学习驾驶者的技巧。为了船体稳定，他在自家车库里焊接了连接两条划艇的金属框架。便于拆装的结构，可以装上他的皮卡，方便下水测试。\n做出加入蚂蚁金服的决定，也是出于同样的理由——“有意思”。“这里的业务很新颖，对AI 有着更加多样化的需求。”如何用AI解决金融行业的问题，是和他以往所面对的完全不同的全新挑战。 SQLFlow：分析师与AI模型间的翻译  加入蚂蚁金服不久，王益就意识到自己之前的朦胧猜想越来越清晰地被验证：和主要依靠流量与广告赚钱的传统互联网公司不同，蚂蚁金服不是纯互联网公司，它有独特的商业模式和对于工具的独到需求。\n此前的十多年中，他的大部分经历是在传统互联网 …","date":1571883840,"description":"不管世界如何，永远永远希望开发者能感觉技术“有意思”，永远希望开发者快乐不复杂。","dir":"blog/ant-financial-happy-1024/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c89decd5fb9b75c59f487dc58bac0365","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-happy-1024/","publishdate":"2019-10-24T10:24:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/ant-financial-happy-1024/","summary":"!important 希望我们是最早给你祝福的朋友 去年的1024，我们回顾了第一代到第五代架构 去年的今天，我们和大家分享了 SOFAStack 背后的这群工程师。比如程立，花名鲁肃","tags":["1024"],"title":"蚂蚁金服开源背后的“有意思”工程师 | 1024快乐","type":"blog","url":"/sofastack.tech/blog/ant-financial-happy-1024/","wordcount":5806},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@温明磊 提问： \u0026amp;gt; 最近在选型 Zeebe 还是 Seata Saga 来实现微服务编排。Zeebe 使用了基于行业标准 BPMN 2.0 的可视工作流。 但是考虑到 Seata 的开源和生态，如果 Seata 能实现流程可视就好了。\nA：未来我们会做可视化的也可以社区贡献。另外给一个调研服务编排选型的建议，遵循 bpmn 2.0 行业标准没有问题的，不过 bmpn2.0 xml 格式太复杂了，我们微服务的编排不需要那么多标签，另外微服务的编排里有很重要一块就是要保证编排的服务的事务一致性，所以需有能支持分布式事务的处理能力，这里面就会涉及服务的状态判断定义，异常处理定义，复杂服务参数的映射，这些在 bpmn 2.0 标准里是没有定义的（当然框架可以在扩展节点里自己扩展）。用 json 定义之后，你会发现其实有没有可视化开发工具没有那么重要了，只是如果有个可视化监控更好。\n 是的，json 我们都可以自己组装。只要把业务接口做成可视可配，完全可以用配置信息组装 json。这样说不知道对不对。但是像您说的，有个可视化的工具 肯定要更好点。\n A：是的，json 还有一个好处是，服务调用的参数可以直接在 json 里组织好。\nSOFARegistryLab 系列阅读 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 云原生推荐阅读 云原生时代，什么是蚂蚁金服推荐的金融架构？ 当金融科技遇上云原生，蚂蚁金服是怎么做安全架构的？ SOFA 项目进展 发布 Seata v0.9.0，主要变更如下：\ni. 长事务解决方案: Saga 模式（基于状态机实现） ii. 支持自定义配置和注册中心类型 iii. 支持 spring cloud config 配置中心 iv. 修复对象锁和全局锁可能造成的死锁和优化锁的粒度 v. 修复 oracle 的批量获取问题 vi. 优化了一些基于 java5 的语法结构 vii. 抽象 undologManager 的通用方法\n详细发布报告： https://github.com/seata/seata/releases/tag/v0.9.0\n云原生活动推荐 Service Mesh Meetup 是由蚂蚁金服联合 CNCF 官方共同出品，ServiceMesher 社区主办，主题围绕服务网格、Kubernetes 及云原生，在全国各地循环举办的技术沙龙。\n本期 Meetup 邀请社区大咖，从服务网格下微服务架构设计、在 5G 时代的应用、如何使用开源的 Traefik 构建云原生边缘路由及蚂蚁金服的服务网格代理演进角度给大家带来精彩分享。\n时间：2019年10月26日（周六）13:00-17:0 0地点：成都武侯区蚂蚁C空间 报名方式：点击这里，即可锁定席位\n","date":1571382000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191018/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"91ccf1c351bfb03d7e18f70fad5f5224","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191018/","publishdate":"2019-10-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191018/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/14 - 10/18】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191018/","wordcount":1198},{"author":"力鲲","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第五篇，本篇作者力鲲，来自蚂蚁金服。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n回顾：服务注册 SOFARegistry 作为服务注册中心，面临的一个很重要的挑战就是如何解决海量的客户端连接问题，这也是本文要剖析的内容。不过作为一篇完整的文章，我们还是会先花一点时间介绍 SOFARegistry 的相关信息，以便读者了解其背景。\n服务注册中心在服务调用的场景中，扮演一个“中介”的角色，服务发布者 (Publisher) 将服务发布到服务注册中心，服务调用方 (Subscriber) 通过访问服务注册中心就能够获取到服务信息，进而实现调用。\n图1 - 服务的“中介”\n流程：订阅 / 发布 在《海量数据下的注册中心 - SOFARegistry 架构介绍》一文中，我们提到了一个典型的 “RPC 调用的服务寻址” 应用场景，服务的提供方通过如下两个步骤完成服务发布：\n 注册，将自己以 Publisher 的角色注册到 SOFARegistry； 发布，将需要发布的数据 (通常是IP 地址、端口、调用方式等) 发布到 SOFARegistry； 与此相对应的，服务的调用方通过如下步骤实现服务调用：\n 注册，将自己以 Subscriber 的角色注册到 SOFARegistry； 订阅，收到 SOFARegistry 推送的服务数据； 从上面我们可以看到，整个流程中很重要的一个步骤就是注册，不管是 Publisher 还是 Subscriber 都只能在注册成功后才能实现发布订阅的需求。因此 SOFARegistry 要解决的一个问题就是如何维护与 Client 连接而产生的 Session，尤其是当 Client 数量众多的时候。\n图2 - 海量啊海量\n设计：分层隔离 在 SOFARegistry 的应用场景中，体量庞大的数据主要有两类：Session 数据、服务信息数据。两类数据的相同之处在于其数据量都会不断扩展，而不同的是其扩展的原因并不相同：Session 是对应于 Client 的连接，其数据量是随着业务机器规模的扩展而增长，而服务信息数据量的增长是由 Publisher 的发布所决定。所以 SOFARegistry 通过分层设计，将两种数据隔离，从而使二者的扩容互不影响。\n图3 - 分层，扩容互不影响\n当然，对于分层设计的概念介绍，在《海量数据下的注册中心 - SOFARegistry 架构介绍》的 “如何支持海量客户端” 章节已经有了很完整的介绍，这里不再赘述。本文是想从代码层面来看看其设计实现的方式。\n通信 Exchange Exchange 作为 Client / Server 连接的抽象，负责节点之间的连接。在建立连接中，可以设置一系列应对不同任务的 handler (称之为 ChannelHandler)，这些 ChannelHandler 有的作为 Listener 用来处理连接事件，有的作为 Processor 用来处理各种指定的事件，比如服务信息数据变化、Subscriber 注册等事件。\n图4 - 每一层各司其职，协同实现节点通信\nSession 节点在启动的时候，利用 Exchange 设置了一系列 ChannelHandler：\n PublisherHandler SubscriberHandler\n WatcherHandler\n ClientNodeConnectionHandler\n CancelAddressRequestHandler\n SyncConfigHandler\n 其中 SubscriberHandler 和 PublisherHandler 主要是与服务发布方 (Publisher) 以及服务调用方 (Subscriber) 的行为相关，我们在下面说明。\n任务处理 由于 SubscriberHandler 在 Session 节点启动时就已经初始化并设置，所以当有 Subscriber 注册时，就由 SubscriberHandler 负责后续一系列的处理逻辑。\n图5 - Subscriber 的注册过程\n上面的流程图展示了 Subscriber 注册的处理过程，SessionSever 在处理注册请求时，除了保存 Subscriber 的会话信息，还要为新注册的 Subscriber 提供其所订阅的服务信息数据，最后通过推送的方式将数据发送 Subscriber。\n下面是上述流程在代码模块上的实现，我们依然用图的方式展示出来，大家按图索骥也便于查阅相关源码中的细节。\n图6 - 代码流转：Subscriber 注册\n可以看到，SOFARegistry 采用了 Handler - Task \u0026amp;amp; Strategy - Listener 的方式来应对服务注册中的各种场景和任务，这样的处理模型能够尽可能的让代码和架构清晰整洁。\nPublisher 的注册过程和 Subscriber 基本一致，略有不同的是 Publisher 在注册完毕之后将要发布的数据写到 DataServer 上。\n图7 - Publisher 的注册过程\n这个过程也是采用了 Handler - Task \u0026amp;amp; Strategy - Listener 的方式来处理，任务在代码内部的处理流程和订阅过程基本一致。\n图8 - 代码流转：Publisher 注册\n会话缓存 在二层架构中 (即 Client 直接连接 DataServer)，连接数是一个很难收敛的指标，因为当一个 Subscriber 订阅的服务位于不同 DataServer 上时，他就会与多个 DataServer 同时保持连接，这样“每台 DataServer 承载的连接数会随 Client 数量的增长而增长，每台 Client 极端的情况下需要与每台 DataServer 都建连，因此通过 DataServer 的扩容并不能线性的分摊 Client 连接数”。\n图9 - 两层结构中，扩容无法减少连接数\n这也是 SOFARegistry 设计三层模型的原因，通过 SessionServer 来负责与 Client 的连接，将每个 Client 的连接数收敛到 1，这样当 Client 数量增长时，只需要扩容 SessionServer 集群就可以了。 所以从设计初衷上我们就能够看出来 SessionServer 必须要满足的两个主要能力： …","date":1571223600,"description":" 本文为《剖析 | SOFARegistry 框架》第五篇，作者力鲲","dir":"blog/sofa-registry-session-storage/","fuzzywordcount":2900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5ae2be3be1d395dd7ccb2bddc97b346f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-session-storage/","publishdate":"2019-10-16T19:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-registry-session-storage/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心 Session 存储策略 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-session-storage/","wordcount":2821},{"author":"杨延昭","categories":"云原生","content":" 蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀，以及面向未来的金融技术创新和参会者分享。我们将其中的优秀演讲整理成文并将陆续发布在本网站，本文为其中一篇。\n 本文作者：杨延昭（杨冰），蚂蚁金服智能科技产品技术部总监\n互联网技术发展日新月异，我们正在进入云原生时代，这个过程中金融行业要如何拥抱云原生？在近两年蚂蚁金服将云原生在金融领域落地，沉淀下一些实践经验，接下来我想分享在蚂蚁的演进过程当中，我们心中的云原生是什么样的，在金融领域落地的时候遇到什么问题，以及我们是怎么解决的。\n经过多年云计算的蓬勃发展，上云已经不是太大问题，接下来的问题是怎么把云用好，用得更高效。RightScale 2019年最新数据显示，现在公有云规模占22%，只使用私有云的客户占3%，更多客户通过混合的模式去使用云，通过混合云取得数据隐私、安全与效率、弹性的平衡。\n再看全球整个 IT 行业，公有云的比例只占整个基础 IT 市场的10%，市场空间仍然很大，IT 市场中剩下很多都是传统企业客户。为什么传统行业无法很好地利用公有云，一个重要的原因是因为他们的 IT 系统经过很长时间建设，很多都有自己的机房。另外有些则业务比较稳定，对上公有云没有很强的需求。它们通常会发展混合云策略，把一些核心业务留在私有云，而把一些边缘业务或创新业务放在公有云上。\n这些特点在金融行业也非常明显，除此之外金融行业还有两个特征：\n 业务形态走向开放和互联网化：随着互联网和数字化经济的发展，金融机构需要进行数字化转型，以及业务敏捷化、服务场景化，以应对新的商业模式带来的冲击； 监管合规的诉求：金融行业的业务特点决定了必须是强隔离，强监管的，所以公有云上的资源共享模式在监管方面会有比较大的挑战。 因此，混合云战略对金融机构更为适用。这一结论也得到研究支持，根据调研机构 Nutanix 的报告，全球金融业在混合云应用方面的发展速度超过其它行业，目前部署普及率达到21%，而全球平均水平为18.5%。\n那么，什么样的混合云是适合金融机构的呢？以蚂蚁的演进历程为例。\n蚂蚁在第四代架构的时候演变成为云平台架构，而且为了应对互联网业务形态下突发性业务对资源的弹性需求，蚂蚁也在同一阶段将架构直接进化成弹性混合云架构。现在蚂蚁已经演进到第五代云原生架构。蚂蚁又是如何在云原生的架构下，把混合云变成金融级的混合云，我想会对各位有些启发。在这个发展过程中，有一条主线，是不同阶段蚂蚁对研发的标准和要求，包括：自主、成本、安全、稳定、海量、敏捷，这也是在在线金融的时代，我们对云原生架构的要求。\n从分布式到云原生 建立金融级交易支付系统  建立金融级的在线交易系统，第一步是要实现金融级分布式的架构，蚂蚁在这方面的代表技术是 SOFAStack 和 OceanBase，目前都已对外商业化，并有丰富的案例。SOFAStack 代表的是，在整个应用层或者无状态服务这个层面上，如何去做可伸缩、可扩展的一套架构。OceanBase 代表的是以数据库为代表的存储或者是有状态服务层面，如何在架构上面去进行分布式。它们拥有四个特性：\n 高可用，99.99%+的可用性保证，确保系统始终连续运行不中断； 一致性，在任何异常情况下数据最终一致，确保资金安全； 可扩展，支持应用级、数据库级、机房级、地域级的快速扩展； 高性能，存储采用读写分离架构，计算引擎全链路性能优化，准内存数据库性能。 而这四个关键的特性都是金融业务最为看重的，而且需要在应用和存储上端到端实现。 以一致性为例，在单个数据库内是可以确保数据一致性的，但在大规模应用的情况下，单个数据库总是会出现瓶颈，数据往往会像服务或者应用一样，按照类似交易、支付、账目等粒度垂直拆开，当这些数据分别存储在不同的数据库集群后，就需要在应用层来解决一致性问题了，同时为了支持海量数据，数据库集群内部也会做分别和多副本，OceanBase 就是这样一套分布式数据库，在其内部也要实现分布式事务。只有这样上下配合才能解掉所有分布式架构下的一致性问题，缺一不可。\n再比如可扩展性方面，有些系统号称做了分布式架构，实际可能只是用了微服务框架，做了应用层的服务化改造，但数据库层既没有用水平扩展的技术，也没用分布式数据库，整个系统的可扩展性就卡在数据层的短板上。\n所以，真正的分布式系统，需要实现端到端的分布式，才能实现无限可扩展和高性能，而真正的金融级分布式系统则要实现端到端的高可用和一致性。\n蚂蚁金服三地五中心异地多活架构我们认为，高可用架构最关键的目标是数据不丢，业务不停。在这个目标的基础上，我们设计并实施了三地五中心的异地多活架构。它的核心优势包括城市级容灾，低成本交易，无限可扩展，以及 RPO=0，PTO\u0026amp;lt;30s. 大家知道我们在去年云栖大会上做了一次剪网线的demo，它演示了整个架构层面上怎么样做到跨城市多活和灾难情况下的恢复快速恢复能力。同时在高可用达标的情况下，我们也做了很多风险相关的事情，总结起来就是在高可用的基础上还要做到资金的安全、变更的免疫和故障的快速恢复。\n解决了高可用的问题，其实金融级最被高频提到的话题就是安全，在云原生时代，我们要解决的是全链路、端到端的安全风险。具体分为三个层面：\n 云原生网络安全，包括策略化高效流量控制，全链路加密，流量劫持与分析； 云原生基础设施安全，包括安全容器，不共享内核，以及安全沙箱； 云原生业务安全，包括 SOFAEnclave 机密计算中间件，以及内存安全的、多任务 Enclave LibOS Occlum。  这个部分我的同事在《金融服务的云原生安全架构》演讲中会详细介绍。小结一下，所谓金融级的能力，最主要是要实现端到端的金融级的高可用，同时实现端到端的安全。接下来我想分享的是，在云原生这个阶段往前走遇到了哪些问题。\n从单元化到弹性架构 应对互联网爆炸式的流量脉冲  从单元化到云原生下的弹性架构\n首先解释下什么是单元化，大家可能比较容易理解数据库层的分库分表或者说 Sharding，能够通过分片的方式解决集中存储计算性能问题，单元化的核心思想是把数据的分片提前到了入口请求的分片，在机房的网络接入层将用户请求根据某个纬度（比如用户 ID）进行 Sharding，这就好比把每个机房就当做了一个巨大无比的有状态的数据库分片，当你是一个 ID 尾号为007或者008用户的时候，当请求通过手机端或者网页域名发送到机房，接入层就已经识别出应该将你路由到华东地区还是在华南地区。当你进入到某个地区的机房时，大部分请求处理工作可以在机房内部完成。偶尔会有一些业务可能会发生跨机房的服务调用，比如说数据在 A 机房的用户给数据在 B 机房的用户转账。这个时候就需要在这个机房上去做有状态的设计。\n我们走向云原生时代的时候，在大的架构上面用 Kubernetes 为基础来设计，在单元化架构下，我们选择在每个单元里部署一个 Kubernetes 集群，将支持多 K8s 集群管理和管控指令下发的 Federated APIServer 做逻辑上的全局部署，其中管控元数据是存储在一个 ETCD 集群的，以保持全局数据一 …","date":1571209200,"description":"本文将分享在蚂蚁金服的演进过程当中，我们心中的云原生是什么样的，在金融领域落地的时候遇到什么问题，以及我们是怎么解决的。","dir":"blog/ant-financial-native-cloud-financial-architecture/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b0fce431d72c523e27e31f1fe831fdee","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","publishdate":"2019-10-16T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","summary":"蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀","tags":["云原生"],"title":"云原生时代，什么是蚂蚁金服推荐的金融架构？","type":"blog","url":"/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","wordcount":5366},{"author":"何征宇","categories":"云原生","content":" 蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀，以及面向未来的金融技术创新和参会者分享。我们将其中的优秀演讲整理成文并将陆续发布在“ 金融级分布式架构”公众号上，本文为其中一篇。\n 本文作者：何征宇，gVisor 创始人，蚂蚁金服研究员\n在云原生发展趋势之下，金融行业想要应用云原生技术，安全问题是一个非常大的拦路虎，而云原生社区对安全问题的重视程度远远不够。蚂蚁金服在落地云原生的时候，解决安全问题是重中之重，经过探索与实践，我们沉淀出了一套从底层硬件到软件、从系统到应用层的全链路金融级云原生安全架构。\n金融行业最重要的就是信任，我们认为，安全所带来的信任，是一种无形的产品，支撑着所有金融业务。\n顺应互联网时代发展，金融行业与机构也发生了很多的变化，包括 App、小程序等更多的访问渠道，更快的业务变化，更多的第三方供应商。但是，不管怎么变化，金融行业有一点始终不变，那就是 Zero Fault，对错误的零容忍，也就是对稳定性和安全性的极高要求。\n这里，我还想澄清大家对金融行业的一个错误看法，就是，大家都说金融机构有很多遗留系统，很多技术是十几年前的，就认为金融机构的技术是落后的。但其实，金融行业一直是科技含量非常高的。前段时间有一部电影上映，叫《蜂鸟计划》，根据真实事件改编，讲一帮做高频交易的人，为了降低从堪萨斯到纽约交易所的时间，建造了一条上千英里直通两地的光纤，想尽办法去争取那最后一毫秒。所以，金融行业并不只有平庸保守的科技，它同样也在追逐最前沿最先进的技术，我们的使命就是要用科技来进一步武装金融行业，为金融科技注入更多的活力。\n云原生架构其实代表一种新的生产力，金融行业肯定是需要云原生的，它为我们带来了节约成本和敏捷开发的能力，但是在它前面还需要加一个定语，就是安全的云原生架构，它里面不仅仅包含之前的相对简单的安全方案，而是一个从端到端的全链路可信的安全解决方案。包括明晰代码所有权，做到可信启动，对镜像的制作和发布收口，配合账号体系，明晰应用的所有权和访问权限；以及安全可独立部署的精细化隔离方案，将安全策略和实施集成在基础架构中，对软件开发和测试透明。\n这里我们着重分享蚂蚁金服正在实践的几项云原生安全技术，包括云原生网络安全 Service Mesh，安全容器，以及机密计算。\n云原生网络安全：SOFAMesh  当前，云原生里除了容器之外第二大技术其实就是 Service Mesh，从蚂蚁的实践来看，其实它对金融安全有非常高的帮助。它至少可以做到三点：\n 策略化高效流量控制，可以帮助运维迅速适应业务快速变化； 全链路加密，保护端到端数据安全； 流量劫持与分析，当发现异常流量与容器时，进行流量阻断。 并且，这些工作对业务是透明的，不需要给业务开发增加负担，同时我们还可以对流量进行实时的语义分析等等，做比传统的防火墙更多的事情。\n蚂蚁金服在对 Service Mesh 的探索中，推出了自己用 Golang 打造的 SOFAMesh，并且已经对外开源，希望和社区一起努力，让 Service Mesh 的理念和技术更加普及。\nSOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强大功能和丰富特性的基础上，为满足大规模部署下的性能要求以及应对落地实践中的实际情况，所做的改进包括采用 Golang 编写的 SOFAMosn 取代 Envoy，极大降低了 Mesh 本身的开发难度，并做了一些创新性工作，例如合并Mixer到数据平面以解决性能瓶颈，增强 Pilot 以实现更灵活的服务发现机制，增加对 SOFARPC、Dubbo 的支持，等等。\n更多详情可查看 SOFAMesh 的 GitHub 主页：https://github.com/sofastack/sofa-mesh\n蚂蚁金服率先在生产环境中大规模落地 SOFAMesh，超过 10W+ 容器做到了 Mesh 化，平稳支撑了 618 大促，给我们带来了多协议支持、UDPA、平滑升级、安全等多方面的好处，并且对性能仅有轻微的影响，单跳 CPU 增加 5% 损耗，RT增加不到 0.2ms，甚至部分业务经过 Mesh 化改造将业务链路下沉，RT 反而下降 7%。\n安全容器：Kata Containers  传统容器架构\n提云原生大家肯定都会提容器，传统容器从虚拟机到容器，其实是牺牲了隔离性的，从上图可以很清楚的看到，当我们的应用在容器里，其实共享着同一个 CPU、内存、网络和存储，只是从外面看起来是不同的。这会导致安全上的问题，就是不同的容器之间不存在真正的隔离，一旦一个容器发生安全问题，很可能影响到其它容器，甚至入侵整个系统。蚂蚁金服在这方面做的工作就是安全容器，具体就是 Kata Containers。\n安全容器架构\nKata Containers 安全容器是 OpenStack 基金会的顶级开放基础设施项目，由蚂蚁金服和 Intel 共同主导开发。在安全容器里，每个 Pod 运行在独立的沙箱中，彼此不共享内核，提供强安全保障。这里给大家分享一下 Kata Containers 的近期进展，针对大家最关注的性能问题有了非常大的提升：\n 引入 shimv2 每 Pod 辅助进程数量从 2N+2 减少到 1 个； 引入 virtiofs，提升文件系统性能约 70% 到 90%； 引入 Firecracker， VMM 内存开销从 60MB 降到约 15MB； 改用 rust 实现 agent，占用内存从 11MB 下降到约 1MB。 我们也会和社区一起继续共建 Kata Containers，让安全容器成为云原生的标配。\n安全容器可以有效的保护主机，但是，金融业务本身仍然需要更强的隔离保护，蚂蚁金服引入了机密计算，并根据实际场景研发了大规模落地解决方案 SOFAEnclave。\n机密计算中间件：SOFAEnclave 所谓机密计算，也就是基于例如 Inte SGX，ARM Trustzone 等可信执行环境（Trusted Execution Environment, TEE），也称为 Enclave ，访问计算机内存时隔离用户数据，以避免将数据暴露给其他应用程序、操作系统或其他云服务器租户的解决方案。\nEnclave架构\nEnclave 是运行时的双向保护，比如说你的金融业务跑在 Enclave 上的时候，操作系统都看不到 Enclave 里的内存，同时会进行完整性检查，保证访问 Enclave 的代码不被替换。\n但是 Enclave 目前存在一些问题，阻碍了它在实际生产环境中的应用。总结这些问题包括：\n第一，需要改写应用，因为可信执行环境里面没有内核和基础库，所以没法把应用直接在 Enclave 中执行；第二，需要分割应用，需要把业务程序划分为 Enclave 内和 Enclave 外的部分；第三，未集群化，与客户端场景不同，Enclave 中的应用如何 failover，容灾也是阻止其在数据中心中大规模使用的一个原因。 …","date":1571036400,"description":"本文着重分享蚂蚁金服正在实践的几项云原生安全技术，包括云原生网络安全 Service Mesh，安全容器，以及机密计算。","dir":"blog/ant-financial-native-cloud-security-architecture/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d65835b57ec0e3e24af2c65db5f41824","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","publishdate":"2019-10-14T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","summary":"蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀","tags":["云原生"],"title":"当金融科技遇上云原生，蚂蚁金服是怎么做安全架构的？","type":"blog","url":"/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","wordcount":3402},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@陈文龙 提问：\n 请问一下，使用 Seata 时，undo_log 表的 rollback_info 字典的内容为｛｝（相当于空），事务回滚后记录又没被清除，而服务的日志打出的是成功回滚，log_status 是 1，这是什么原因呢？\n A：1 是防御性的，是收到 globalrollback 回滚请求，但是不确定某个事务分支的本地事务是否已经执行完成了，这时事先插入一条 branchid 相同的数据，插入的假数据成功了，本地事务继续执行就会报主键冲突自动回滚。假如插入不成功说明表里有数据这个本地事务已经执行完成了，那么取出这条 undolog 数据做反向回滚操作。\n相关阅读：分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾\nSOFARegistryLab 系列阅读 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 活动推荐 2019中国开源年会 (COSCon\u0026amp;rsquo;19) 正式启动啦~\n时间： 2019-11-02 09:00 ~ 11-03 17:00\n地址： 上海普陀区中山北路3663号华东师范大学（中北校区）\n本次大会的主题是“开源无疆、携手出航”（Let’s Cross the Boundaries Together!），这也代表主办方对于中国开源，走向世界，走向辉煌的殷切期望。\nSOFAStack 开源社区也受到主办方的邀请参加此次开源年会。\n更多重磅议题与开源嘉宾，点击“这里”，即可了解。\n","date":1570777200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191011/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"98ed37338b0cd1036114b205bcb980c2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191011/","publishdate":"2019-10-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191011/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/7 - 10/11】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191011/","wordcount":776},{"author":"明不二","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第四篇，本篇作者明不二。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 在前面的章节中我们已经提到，SOFARegistry 与其他服务发现领域的产品相比，最大的不同点在于支持海量数据。本章即将讲述 SOFARegistry 在支撑海量数据上的一些特性。\n本文将从如下几个方面进行讲解：\n DataServer 总体架构：对 SOFARegistry 中支持海量数据的总体架构做一个简述，讲解数据分片和同步方案中所涉及到的关键技术点； DataServer 启动：讲解 DataServer 启动的服务，从而为接下来更直观地理解数据分片、数据同步的触发时机以及触发方式等做一个铺垫； 数据分片：讲解 SOFARegistry 中采用的一致性 Hash 算法进行数据分片的缘由以及具体实现方法； 数据同步方案：讲解 SOFARegistry 采用的数据同步方案； DataServer 总体架构 在大部分的服务注册中心系统中，每台服务器都存储着全量的服务注册数据，服务器之间通过一致性协议（paxos、Raft 等）实现数据的复制，或者采用只保障最终一致性的算法，来实现异步数据复制。这样的设计对于一般业务规模的系统来说没有问题，而当应用于有着海量服务的庞大的业务系统来说，就会遇到性能瓶颈。\n为解决这一问题，SOFARegistry 采用了数据分片的方法。全量服务注册数据不再保存在单机里，而是分布于每个节点中，每台服务器保存一定量的服务注册数据，同时进行多副本备份，从理论上实现了服务无限扩容，且实现了高可用，最终达到支撑海量数据的目的。\n在各种数据分片算法中，SOFARegistry 采用了业界主流的一致性 Hash 算法做数据分片，当节点动态扩缩容时，数据仍能均匀分布，维持数据的平衡。\n在数据同步时，没有采用与 Dynamo、Casandra、Tair、Codis、Redis cluster 等项目中类似的预分片机制，而是在 DataServer 内存里以 dataInfoId 为粒度进行操作日志记录，这种实现方式在某种程度上也实现了“预分片”，从而保障了数据同步的有效性。\n图 1 SOFARegistry 总体架构图\nDataServer 启动 启动入口 DataServer 模块的各个 bean 在 JavaConfig 中统一配置，JavaConfig 类为 DataServerBeanConfiguration， 启动入口类为 DataServerInitializer，该类不由 JavaConfig 管理配置，而是继承了 SmartLifecycle 接口，在启动时由 Spring 框架调用其 start 方法。\n该方法中调用了 DataServerBootstrap#start 方法（图 2），用于启动一系列的初始化服务。\n从代码中可以看出，DataServer 服务在启动时，会启动 DataServer、DataSyncServer、HttpServer 三个 bolt 服务。在启动这些 Server 之时，DataServer 注册了一系列 Handler 来处理各类消息。\n图2 DataServerBootstrap 中的 start 方法\n这几个 Server 的作用如下：\n DataServer：数据服务，获取数据的推送，服务上下线通知等； DataSyncServer：数据同步服务； HttpServer：提供一系列 REST 接口，用于 dashboard 管理、数据查询等； 各 Handler 具体作用如图 3 所示：\n图 3 各 Handler 作用\n同时启动了 RaftClient 用于保障 DataServer 节点之间的分布式一致性，启动了各项启动任务，具体内容如图 4 所示：\n图 4 DataServer 各项启动任务\n各个服务的启动监听端口如图 5 所示：\n图5 监听端口\n其他初始化 Bean 除上述的启动服务之外，还有一些 bean 在模块启动时被初始化, 系统初始化时的 bean 都在 DataServerBeanConfiguration 里面通过 JavaConfig 来注册，主要以如下几个配置类体现（配置类会有变更，具体内容可以参照源码实现）：\n DataServerBootstrapConfigConfiguration：该配置类主要作用是提供一些 DataServer 服务启动时基本的 Bean，比如 DataServerConfig 基础配置 Bean、DataNodeStatus 节点状态 Bean、DatumCache 缓存 Bean 等；\n LogTaskConfigConfiguration：该配置类主要用于提供一些日志处理相关的 Bean；\n SessionRemotingConfiguration：该配置类主要作用是提供一些与 SessionServer 相互通信的 Bean，以及连接过程中的一些请求处理 Bean。比如 BoltExchange、JerseyExchange 等用于启动服务的 Bean，还有节点上下线、数据发布等的 Bean，为关键配置类；\n DataServerNotifyBeanConfiguration：该配置类中配置的 Bean 主要用于进行事件通知，如用于处理数据变更的 DataChangeHandler 等；\n DataServerSyncBeanConfiguration：该配置类中配置的 Bean 主要用于数据同步操作；\n DataServerEventBeanConfiguration：该配置类中配置的 Bean 主要用于处理与数据节点相关的事件，如事件中心 EventCenter、数据变化事件中心 DataChangeEventCenter 等；\n DataServerRemotingBeanConfiguration：该配置类中配置的 Bean 主要用于 DataServer 的连接管理；\n ResourceConfiguration：该配置类中配置的 Bean 主要用于提供一些 Rest 接口资源；\n AfterWorkingProcessConfiguration：该配置类中配置一些后处理 Handler Bean，用于处理一些业务逻辑结束后的后处理动作；\n ExecutorConfiguration： …","date":1570690800,"description":" 本文为《剖析 | SOFARegistry 框架》第四篇，作者明不二","dir":"blog/sofa-registry-data-fragmentation-synchronization-scheme/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e4e0cf21756799897553099d37f73100","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","publishdate":"2019-10-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心数据分片和同步方案详解 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","wordcount":5784},{"author":"闫守孟等","categories":"SOFAEnclave","content":" 近日，Linux 基金会宣布全球多家巨头企业成立机密计算联盟（Confidential Computing Consortium），在对于数据安全和隐私担忧的不断增长下，基于可信执行环境技术的机密计算作为一种可行的解决方案，成为互联网巨头关注的焦点。 蚂蚁金服很早就关注此类技术，并基于机密计算打造了蚂蚁金服新一代可信编程中间件 SOFAEnclave，为金融业务保驾护航。 机密计算是蚂蚁安全计算的一环，也是金融级云原生的一块重要版图，蚂蚁金服表示：相信未来机密计算将和 HTTPS 一样，成为云计算的标配。\n 作者 | 闫守孟、肖俊贤、田洪亮 引言 互联网金融本质上是对大量敏感数据的处理以及由此沉淀的关键业务智能。近年来涌现出来的新业态更是将数据处理的范畴从单方数据扩展到了涉及合作方的多方数据。\n另一方面，从 GDPR 到 HIPAA，数据隐私监管保护的范围愈加扩大，力度日益增强。可见，对金融数据和关键业务智能的安全保护，不仅是互联网金融业务的基础，也是其创新发展的依托，更是攸关合规的关键因素。\n近年来迅速发展的机密计算技术是一种创新的数据隔离和加密处理技术，其重要特点是，TCB(trusted computing base 可信计算基) 中仅包含应用自身和基础硬件，即使 OS kernel、Hypervisor、甚至 BIOS 等特权软件都已经遭到破坏甚至本来就是恶意的，敏感数据和代码依然能安全无虞。\n蚂蚁金服在自身的实践过程中，基于机密计算底层技术发展出金融级的机密计算中间件，确保金融应用数据和代码的机密性和完整性，为关键业务提供易用、安全、集群化的计算环境。\n本文从机密计算的技术背景、关键问题、蚂蚁的技术突破、以及典型应用场景等方面展开。\n机密计算的技术背景 随着云计算的快速发展，越来越多的关键性服务和高价值数据被迁移到了云端。云安全也因此成为学术界和工业界关注的一个焦点。\n近年来，云安全领域最重要的一项技术进展名为机密计算（Confidential Computing）。机密计算填补了当前云安全的一项空白——使用中数据（Data-in-use）的加密。过去通行的做法是对数据在存储中（比如硬盘）和传输中（比如网络）加密，而在使用中（比如内存）解密，以便处理。而机密计算可以保护使用中数据的机密性和完整性。\n目前，多家云计算巨头都在不约而同地推广这项技术：微软已于 2017 年 7 月宣布开始接受 Azure 机密计算的早期试用申请；IBM 于 2017 年 12 月宣布 IBM 云数据保护（Cloud Data Guard）的预览版；谷歌也于 2018 年 5 月开源了名为 Asylo 的机密计算框架。\n那么，机密计算究竟是如何实现的呢？\n实际上，上述所有云计算巨头在实现机密计算时都离不开一种称为“可信执行环境（TEE）”的技术。\n顾名思义，TEE 提供一种与不可信环境隔离的安全计算环境，正是这种隔离和可信验证机制使得机密计算成为可能。\nTEE 一般是直接基于硬件实现的，比如 Intel SGX，AMD SEV，ARM TrustZone，以及 RISC-V Keystone 等；基于虚拟化技术也可以构造 TEE，比如微软的 VSM，Intel 的 Trusty for iKGT \u0026amp;amp; ACRN，但尚不能匹敌硬件 TEE 的安全性。\n其中，Intel 软件防护拓展（Software Guard Extensions，简称 SGX）是目前商用 CPU 中最为先进的 TEE 实现，它提供了一套新的指令集使得用户可以定义称为 Enclave 的安全内存区域。CPU 保证 Enclave 与外界隔离，从而保护其中的代码和数据的机密性、完整性和可验证性。不同于之前的 TEE 实现，比如 ARM TrustZone，SGX 每个 APP 都可以有自己独立的 TEE，甚至可以创建多个 TEE，而 TrustZone 是整个系统有一个 TEE；这里也省去了向设备厂商申请将 TA 装入 TEE 的过程。由于 SGX 的先进性，目前云端机密计算领域甚至已公认用 Enclave 这个词来指代 TEE。\n典型 TEE 安全特性和使用流程 [1]\n典型的 Enclave 达到的安全目标可以用 CIA 概括，即机密性（Confidentiality）、完整性（Integrity）和真实性（Authenticity）。在实现上具有以下基本要求：\n1) Enclave 内存保护\nEnclave 内存只有 Enclave 本身的代码可以访问。CPU 通过内存隔离和加密来防止对安全内存的软件攻击和硬件嗅探。SGX 更通过内存控制器的 integrity tree 防止了对 Enclave 内存的物理篡改。\n2) Enclave 的可信验证\nCPU 支持对 Enclave 中数据和代码的测量，以及对 Enclave 合法性的本地或远程验证。有了测量和验证，本地的 Enclave 之间、客户端与远程 Enclave 之间，就可以认证身份，进而建立安全的通信信道。\n如何开发受 Enclave 保护的应用程序呢？\n以 SGX 为例，其中一种方法是利用 Intel SGX SDK。如下图所示，基于 SGX SDK 的应用程序分为两部分：Enclave 外的不可信组件（左边黄色部分）和 Enclave 内的可信组件（右边绿色部分）。两边可以通过跨 Enclave 的函数调用通信：不可信组件可以通过 ECall 调用可信组件中定义的函数；反之，可信组件也可以通过 OCall 调用不可信组件中定义的函数。\nEnclave 编程模型 [2]\n机密计算面临的关键问题 Enclave 给我们带来了前文所谓 CIA 的安全保障，但是目前面临较大的易用性问题。主要体现在几个方面。\n第一，需要将原有应用分割成两部分，一部分是 enclave 外的 untrusted 部分，一部分在 enclave 里面作为 trusted 部分；\n第二，需要精心设计两部分之间的接口，规划好什么时候进入 Enclave，什么时候退出 Enclave——这存在一定技术门槛，而且比较繁琐容易出错；\n第三，即使我们做了完美的分割， Enclave 里面的环境相对于我们熟悉的通常的 Linux 运行环境来说是非常受限的。例如，enclave 里面不能进行系统调用，libc、pthread 不完整，没有 openmp，多进程支持欠缺等等。\n可见，把应用移植到 Enclave 里面是极具挑战的，在某些时候甚至是不可能做到的。而且，由于开发过程中必须考虑业务无关的繁杂琐细的方面，即使最终能完成应用开发移植目标，也会导致低下的开发效率，极高的开发成本，这对于快节奏的互联网业务来说是难以接受的。\n机密计算走向工程实用面临的另一较大问题是，如何将机密计算从单节点向集群扩展。由于缺乏标准的做法，或者没有一个 best practice 作为参考，很多时候各个业务不得不各自从头造轮子，搭建跟业务逻辑过度耦合的 Enclave 集群基础设施。从而导致低下的开发效率和重复的资源投入。\n另一方面，互联网业务日趋云原生化， …","date":1570258800,"description":"基于机密计算打造的新一代可信编程中间件。","dir":"blog/sofa-enclave-confidential-computing/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f994d83c7c4b263b08e4d2fd22a461b4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-enclave-confidential-computing/","publishdate":"2019-10-05T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-enclave-confidential-computing/","summary":"近日，Linux 基金会宣布全球多家巨头企业成立机密计算联盟（Confidential Computing Consortium），在对于数据安全和隐私担忧的不断","tags":["SOFAEnclave"],"title":"SOFAEnclave：蚂蚁金服新一代可信编程环境，让机密计算为金融业务保驾护航102年","type":"blog","url":"/sofastack.tech/blog/sofa-enclave-confidential-computing/","wordcount":6249},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFALab 系列文章 十一特刊带来 SOFALab 系列源码解析文章集合~\nSOFA:RPCLab/ 系列文章 【剖析 | SOFARPC 框架】系列之总体设计与扩展机制 【剖析 | SOFARPC 框架】系列之链路追踪剖析 【剖析 | SOFARPC 框架】系列之连接管理与心跳剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 同步异步实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 线程模型剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 单机故障剔除剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 泛化调用实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 数据透传剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 优雅关闭剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 路由实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 跨语言支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 序列化比较 SOFA:BoltLab/ 系列文章 蚂蚁金服通信框架SOFABolt解析 | 编解码机制 蚂蚁金服通信框架SOFABolt解析 | 序列化机制(Serializer) 蚂蚁金服通信框架SOFABolt解析 | 协议框架解析 蚂蚁金服通信框架SOFABolt解析 | 连接管理剖析 蚂蚁金服通信框架SOFABolt解析 | 超时控制机制及心跳机制 SOFA:TracerLab/ 系列文章 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览 | 剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码分析 | 剖析 蚂蚁金服分布式链路跟踪组件链路透传原理与SLF4J MDC的扩展能力分析 | 剖析 蚂蚁金服分布式链路跟踪组件采样策略和源码 | 剖析 蚂蚁金服分布式链路跟踪组件埋点机制 | 剖析 SOFA:JRaftLab/ 系列文章 SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.5.8，主要变更如下：\n 优化 log4j2 日志异步化 修复故障剔除模块的事件接收问题 修复 tracelog 日志 local 地址打印不正确的问题 优化泛化调用的方法名显示 修复特殊场景下的泛化调用超时设置 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.5.8\n","date":1570172400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191004/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"81a2a8115038fb193b50618c4d845bf4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191004/","publishdate":"2019-10-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191004/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/30 - 10/4】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191004/","wordcount":1056},{"author":"SQLFlow","categories":"SQLFlow","content":" 2018 年 1 月，Oracle 的官方博客上发表了一篇文章，标题是“It\u0026amp;rsquo;s Pervasive：AI Is Everywhere”。作为全球最著名的商业数据库系统提供商，Oracle 在这篇文章里历数了 AI 在企业信息系统中的发展空间。在面向最终用户的互联网行业，巨头们招募 AI 专家，用 Python 和 C++ 打造服务大众的特定 AI 能力——搜索、推荐、以及精准定向的互联网广告系统。在企业业务中，使用 SQL 的分析师是大多数。\n滴滴首席数据科学家谢梁（左）与蚂蚁金服研究员王益开启共建SQLFlow之旅\n2019 年 7 月，滴滴的数据科学（Data Science）团队的几名数据科学家在北京新澄海大厦见到了来自蚂蚁金服的几位工程师。在那之前两个月，蚂蚁金服从事 AI 基础架构研发的王益团队开源了一款机器学习工具 SQLFLow，将 SQL 程序翻译成 Python 程序，调用数据库和 AI 引擎，实现端到端的 AI。滴滴首席数据科学家谢梁敏锐地关注到这个项目。这次拜访双方一拍即合，开启了共建 SQLFlow 之旅。\n用 SQLFlow 构建 AI 的训练和预测任务\n数据分析师的普适 AI  数据驱动决策是很多公司的追求，在国内很多业务人员都了解 SQL，但是对于 AI、深度学习模型的训练，需要长时间系统性的学习，有一定的门槛。SQLFLow 的出现让包括数据分析师在内的业务人员通过写简单的 SQL 去调用 AI 模型成为了可能。滴滴数据科学团队长期地直面一线业务，了解业务需求，也沉淀了很多常用模型。本次合作双方希望优势互补共同助力 AI 的落地，据悉合作分为三步，第一步滴滴为蚂蚁金服贡献更多针对于业务产品的理解和洞见；第二步滴滴将公司自身业务场景最有价值用的最好的模型贡献到 SQLFLow；第三步滴滴加入到建设到整个 SQLFLow 开源社区的建设，双方要在模型、社区、文化等全方位共建。\nSQLFlow的技术架构\n一个多月的时间，滴滴已经为 SQLFLow 贡献了基于 DNN 分类预测模型、可解释模型和无监督聚类模型三个高价值模型。这三个模型覆盖的场景非常广泛，对于滴滴内部来说，包括网约车、单车、金融等在内的诸多业务场景都可应用起来，于外部而言，“因为整个模型它是一种基础能力，其实它不会局限于某一个公司或某一个行业，它具有普适性。”滴滴高级数据科学家高梓尧强调。\nSQLFlow 和滴滴数据的整合逻辑\n比如分类预测模型，适用于做产品增长的场景，对特定人群进行定向推荐。而无监督聚类模型，也就是模式识别，在滴滴的产品的应用非常广，比如会根据司机出车时长分布，去整合归纳司机出车的偏好，更好地为司机提供调度建议，进而帮助缓解出行供需。\n滴滴首席数据科学家谢梁认为在共建 SQLFlow 过程中，充分体现了算法和数据科学在对数据的理解和应用上的两个不同，以及双方优势互补形成 1+1 大于 2 的合力效果。因为对于传统的算法来讲主要强调对于预测一个给定事件的预测精准性。但是数据科学在预测精准性之上，还强调预测的可解释性。实际上在更广泛的商业层面上，比如运营、营销等更需要了解为什么会这这样发生，这对于业务战略制定、营销方案的确定，以及整个产品序列的设计都有非常大的帮助。\n滴滴数据科学团队在过去不到两个月的共建工作中显著扩大了 SQLFlow 的应用场景。根据蚂蚁金服 SQLFlow 项目的产品负责人刘勇峰介绍，滴滴的同事们建议并且参与研发了 SQLFlow 对接 XGBoost 的功能，从而在深度学习模型之外支持树模型；以及对接 unsupervised learning 的能力，支持聚类分析。此外，SQLFlow 基于 SHAP 支持了深度学习模型和树模型的图示化解释。SQLFlow 也支持了滴滴常用的 Hive 数据库系统。\n基于 XGBoost 的汽车价格预测模型（数据来自 Kaggle）的 SHAP 解释图（注：SHAP 值表征了每个特征对模型输出的影响，如图中，较小的 engine_hp“引擎马力”值会降低汽车的预测价格）\n“我们是希望通过 SQLFlow 真正能够把数据驱动业务、科学决策的思想，能够在中国传播得更好更远，也希望就是能够通过我们自己的努力，真正让 AI 模型能力大众化和普及化，然后使得我们整个国内的数据分析的科学性、合理性和洞察性，能够逐步提升，甚至达到国际领先。”高梓尧说。\n而所有参与项目的同事们对 SQLFlow 的未来都有更大的期待，这是对于开源社区作为一种高效率的工作模式的信任。\n打造一个 SQL 花园生态 在强调数据驱动的滴滴其实一直积极参与到开源建设中，截至目前，滴滴和蚂蚁金服分别开源了数十个项目。SQLFlow 是双方开源共建的首秀。\n对于双方仅一个多月的时间就能够共建三个高价值的模型，谢梁认为很重要的原因是 SQLFlow 已经给滴滴搭建好了底层能力，滴滴相当于做了一个交通领域的几个核心插件，并且通过滴滴插件能力，对整个 SQLFlow 覆盖面和深度方面的底层能力进行了验证和提升，“那么再把这个基础打好之后，我们就相当于造了一个大的花园，我们把土都铺好了，需要什么营养的土，要种什么类型的花，都给他做好了，之后就需要有更多的农民伯伯一起来种田，他们要去种向日葵，我们毕竟精力有限可能就是以种小麦和种主粮为主，更多的经济作物就需要其他开源社区的同学一起来贡献。”\n在整个 SQLFlow 开源社区建设方面双方都有更大的愿景，滴滴的分析团队总结的很多模型在 BI 领域具备普适性，而 SQLFlow 在蚂蚁的场景使用模型在金融领域颇有普适性，未来要让更多的人去用上普适的 AI 能力，在 SQLFlow 社区之上会形成一个开源货架式的交易市场，更多懂业务的人把更多商业场景抽象成模型打造成模型库，模型库是 SQLFlow 生态中的重要一环，双方正在讨论如何共建。“你就像走进一个超市，里面有 10万个 SQL，每一个 SQL 就是一个实现了你商业逻辑的模型，你就拿来用就行了，这是终极的一个目标”，谢梁兴奋地谈到。\n当然现在的 SQLFlow 还是一个非常年轻的开源项目，需要更多的呵护。虽然目前在开源合作方面中国相比美国还有不少差距，但正是因为越来越多的公司和个人去投身其中为之贡献，差距正在缩小。实际上，几乎所有的 SQLFlow 项目成员都是利用业余时间参与到开源项目中。比如滴滴资深算法工程师陈祥，他平时负责数据治理和应用方向上数据、应用与算法的结合和落地, 在 8 月初听到 SQLFlow 项目就决定参与进来，未来他也会号召很多的人参与到开源建设中。\n“开源社区所说的构建大生态，其实大生态还包含着另外一层，就是大家互相学习，然后行业内的所有从业人员进行知识交流。所以当各行各业的同学都在里面贡献自己的经验、技能时，我们其实也能从其他的同学那学习到很多处理数据，或者解决实际问题的方法。”高梓尧所言恰如其分地诠释了开源社区众人拾柴火焰高的魅力。\nGartner 预测“到 2020 年，AI 技术将普遍出现在几乎每一个新的软件产品和服务中。”这其中有蚂蚁金服与滴滴 DS 团队的一份力。\n项目地址 欢迎感兴趣的同学加入社区讨论： 项目官 …","date":1569740400,"description":"让AI 像 SQL 查询一样简单。","dir":"blog/sqlflow-ai-didi-antfin-open-source-construction/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d8e2fdbfc1d48f984a2adf17474cb983","permalink":"https://sofastack.github.io/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","publishdate":"2019-09-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","summary":"2018 年 1 月，Oracle 的官方博客上发表了一篇文章，标题是“It\u0026rsquo;s Pervasive：AI Is Everywhere”。作为全球最著","tags":["SQLFlow"],"title":"让 AI 无处不在：滴滴与蚂蚁金服开源共建 SQLFlow","type":"blog","url":"/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","wordcount":2732},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、关于 SOFAJRaft 的提问：\n@LoFi 提问：\n 关于 SOFAJRaft，请教几个问题：不管 raft log 是并行，batch 还是 pipeline 复制，都是为了提高 throughput，但对 latency 没有好处，因为最终日志必须要顺序 commit 和顺序 Apply ，这是 Raft 论文的要求。但是在某些简单的 KV 场景，上层业务可以根据需求去乱序 commit 和 Apply 么？这样可以降低 latency 。\n A：pipeline 对 latency 会有一些好处，总体上讲 batch 对吞吐有好处，SOFAJRaft 里的 batch 设计也不会对 latency 有坏处，所以它还是好的，乱序 apply 理论上影响一致性。\n 如果 raft log commit 成功，但是 apply 失败，系统目前的处理方式是什么？直接 crash?\n A：apply 异常失败会阻塞住状态机，只有重启才可能恢复，为了保证一致性。\n 如果 leader 本地磁盘 error 或者本地 log flush 失败, 但收到了多数派的响应，日志会 commit 么？怎么处理这种情况？\n A：你说的这种异常状态机就挂掉了，原因同上一条。\n关于扩容：\n 扩容时，新节点的角色不能为 follow 吧？会影响 ballot，不应该先增加一个 Follow 角色，等 snapshot 加载成功后再变为 follow 么？\n A：新加节点首先要求日志追上才行，你说的这个不存在。\n 扩容时，如果是 follow 的话，根据论文就会影响 leader 的投票吧\n A：那首先得你说的这个 follower 在这个组里呀。首先要追上数据，才能变更配置，这个节点才会进入 group，另外再退一步，没有最新日志的 follower 也无法影响投票。SOFAJRaft 比 Raft 论文里面多了一个 preVote。\n 明白，就是先追上数据，然后才能再走一遍 addpeer raftlog ?\n A：不是额，是 addPeer 的流程里第一步就是要先追数据。\n 你的意思是：当新的节点加入集群时，会先追日志 , 然后再把这个节点加入到 raft goup 中，成为投票中的一员 是么？ 也就是说在追日志的过程中，这个新的节点是不会参与 raft log 的投票么？那如果说我只是为一个 raft goup 增加副本数，比如从 3 副本变成 4 副本时，这个时候是怎么处理的呢？反正就是不管哪种情况，都是先追数据，然后再加入到 Goup 里？\n A：新加的 follower 一启动，就会 electiontimeout 发起选举，但是不会成功，然后 leader 会为这个节点新起一个 replicator 开始复制数据日志（通常包含 snapshot），等到数据追上后，leader 会再提交一条配置变更日志，此时这个节点就正式加入到 group 了。\n2、关于 Seata 的提问：\n@姜伟锋 提问：\n 最近在看 Seata 的源码，发现 rpc 相关的 Request、Response 网络传输对象太多了，在保证扩展性的基础上是不是可以优化下，因为主要参数也就是事务组 id、事务组 status、分支事务 id、分支事务 status，再加上附加信息字段，感觉这块设计还有相关序列化设计有点复杂了，这样设计的目的是什么呢，求大佬解。\n A：是指字段冗余还是指外层的包装协议复杂了？\n rpc 传输对象感觉有点冗余，一些 request response 对象是不是可以合并，主要字段应该是固定的，这样设计的目的扩展性是很好，复用性是不是还有优化空间呢？\n A： 这里是按照非事务消息（注册鉴权之类）和事务消息，事务消息又按照 RM，TM 角色以及传输的方向做了分类，你说的冗余能举个栗子嘛？\n 看到是按角色定义的 rpc req，res 传输对象，这些词传输对象中主要的字段是全库事务 id，全库事务状态，分支事务 id，分支事务状态，资源 id，还有一些附加字段，TM、TC、RM 交互时为什么不设计成一个 req res 对象公用或者是否可以在现有框架上提高下复用性，个人是觉得这块设计了好多传输对象，每个对象有对应的序列化和反序列化，有点复杂，这样设计扩展性这个点我明白，复用性不是太好，还有其他考虑吗？\n A：每个消息都有一个名称（code），消息名对于整个事务的链路流程上理解比较清晰，结合着我们的事务流程图来看，每个阶段的 rpc 都有一个确切的含义，即使从字段上来说是相同的比如GlobalRollbackRequest，GlobalCommitRequest 从名称上来看不一样，但从传输层面来看除了code 不一样其他的是一样的。但是大部分消息的字段还是不一样的，对于这种通用字段比如 xid begin 消息就是空的，设计成通用这里只能是 null，非通用比如 lockkey 那这里如果使用通用消息就可能直接塞到一个 applicationData 的扩展字段里，这种写法我觉得不确切，同时有增加了我私有协议序列化时不必要的长度标识字段，每条消息都是由确切的所需的字段，宁愿复杂一些，也要从设计上更清晰些。\nSeata：https://github.com/seata/seata\nSOFAJRaft 解析文章全系列 《剖析 | SOFAJRaft 实现原理》系列文章完结啦，感谢 SOFAStack 社区的核心贡献者们的编写，也欢迎更多感兴趣的技术同学加入。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft …","date":1569567600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190927/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d1709ae51d5099a6263d7269a435e264","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190927/","publishdate":"2019-09-27T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190927/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/23 - 9/27】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190927/","wordcount":2458},{"author":"胡宗棠","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》最后一篇，本篇作者胡宗棠，来自中国移动。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文末包含往期系列文章。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n导读 本文主要介绍 SOFAJRaft 在日志复制和管理中所采用的快照机制。考虑到单独介绍 SOFAJRaft 中的快照机制原理和实现或许有一些唐突，我会先通过一个读者都能够看得明白的例子作为切入点，让大家对快照这个概念、它可以解决的主要问题，先有一个比较深刻的理解。\n一、快照的概念与特点 SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法，就不可避免的要对需要达成共识的内容，在多个服务器节点之间进行传输，一般将这些共识的内容称之为日志块（LogEntry）。如果读过《剖析 | SOFAJRaft 实现原理》系列前面几篇文章的同学，应该了解到在 SOFAJRaft 中，可以通过“节点之间并发复制日志”、“批量化复制日志”和“复制日志pipeline机制”等优化手段来保证服务器节点之间日志复制效率达到最大化。\n但如果遇到下面的两个场景，仅依靠上面的优化方法并不能有效地根本解决问题：\n 当对某个 SOFAJRaft Group 集群以新增节点方式来扩容，新节点需要从当前的 Leader 中获取所有的日志并重放到本身的状态机中，这对 Leader 和网络带宽都会带来不小的开销，还有其他方法可以优化或解决这个问题么？ 因为服务器节点需要存储的日志不断增加，但是磁盘空间有限，除了对磁盘卷大小扩容外，还有其他方式来解决么？ 带着上面两个疑问，我们可以先来看一个大家日常生活中都会遇到的场景—重新安装操作系统，然后再通俗易懂地为大家介绍快照的概念与特点。\n有一天，你的笔记本电脑的 Windows 操作系统因为某一些原因出现启动后多次崩溃问题，不管通过任何方式都没办法解决。这时候，我们想到解决问题的第一个方案就是为这台电脑重新安装操作系统。如果，我们平时偶尔为自己电脑的操作系统做过镜像，直接用之前的镜像文件即可快速还原系统至之前的某一时间点的状态，而无需从零开始安装 Windows 操作系统后，再花大量时间来重新安装一些自己所需要的系统软件（比如 Chrome 浏览器、印象笔记和 FoxMail 邮件客户端等）。\n在上面的例子中，电脑操作系统的镜像就是系统某一时刻的“快照”，因为它包含了这一时刻，系统当前状态机的值（对于用户来说，就是安装了哪些的应用软件）。在需要重新安装操作系统时候，通过镜像这一“快照”，可以很高效地完成还原电脑操作系统这个任务，而无需从零开始安装系统和相应的应用软件。所以，我们这里可以为“快照”下一个简单的定义：一种通过某种数据格式文件来保存系统当前的状态值的一个副本。\n“快照”的特点，就如同它字面意思一样，可以分为“快”和“照”：\n “快”：高效快捷，通过快照可以很方便的将系统还原至某一时刻的状态； “照”：通过快照机制是保存系统某一时刻的状态值； 二、SOFAJRaft 的 Snapshot 机制 2.1 SOFAJRaft Snapshot 机制的原理 读到这里，再去回顾第一节内容开头提出的两个问题，大家应该可以想到解决问题的方法就是通过引入快照机制。\n1. 解决日志复制与节点扩容的瓶颈问题 在 SOFAJRaft 中，Snapshot 为当前 Raft 节点状态机的最新状态打了一个“镜像”单独保存，保存成功后在这个时刻之前的日志即可删除，减少了日志文件在磁盘中的占用空间。而在 Raft 节点启动时，可以直接加载最新的 Snapshot 镜像，直接重放在此之后的日志文件即可。如果设置保存 Snapshot 的时间间隔比较合理，那么节点加载镜像后重放的日志文件较少，启动速度也会比较快。对于新 Raft 节点加入某个 SOFAJRaft Group 集群的场景，新节点可先从 Leader 节点上拷贝最新的 Snapshot 安装到本地状态机，然后拷贝后续的日志数据即可，这样可以在快速跟上整个 SOFAJRaft Group 集群进度的同时，又不会占用 Leader 节点较大的网络带宽资源。\n2. 解决 Raft 节点故障恢复中的时效问题 在一个正常运行的 SOFAJRaft Group 集群中，当其中某一个 Raft 节点出现故障了（假设该故障的原因不是由磁盘损坏等不可逆因素导致的），该 Raft 节点修复故障重新启动时，如果节点禁用 Snapshot 快照机制，那么会重放所有本地的日志到状态机以跟上最新的日志，这样节点启动和达到日志备份完整的耗时均会比较长。但是，如果此时节点开启了 Snapshot 快照机制，那么一切就会变得非常高效，节点只需要加载最新的 Snapshot 至状态机，然后以 Snapshot 数据的日志为起点开始继续回放日志至状态机，直到使得状态机达到最新状态。\n图1 在 Snapshot 禁用情况下集群节点扩容\n图2 在 Snapshot 启用情况下集群节点扩容\n从上面两张 SOFAJRaft 集群的结构图上，可以很明显地看出在开启和禁用 Snapshot 时，扩容的新 Raft 节点需要从 Leader 节点传输过来不同的日志数量。在禁用 Snapshot 情况下，新 Raft 节点需要把 Leade 节点内从起始的 T1 时刻至当前 T3 时刻这一时间范围内的所有日志都重新传至本地后提交给状态机。而在开启 Snapshot 情况下，新 Raft 节点则无需像 图1 中那么逐条复制 T1~T3 时刻内的所有日志，而只需先从 Leader 节点加载最新的镜像文件 Snapshot_Index_File 至本地，然后仅复制 T3 时刻以后的日志至本地并提交状态机即可。\n在这里可能有同学会有疑问：“在 图 1 中，从 Leader 节点传给新扩容的 Raft 节点的数据是 T1~T3 的日志，而 图2 中取而代之的是 Snapshot_Index_File 快照镜像文件，似乎还是不可避免额外的数据传输么？”仔细看下图 2，会发现其中 Snapshot_Index_File 快照镜像文件是对 T1~T3 时刻内日志数据指令的合并（包括数集合[Add 1,Add 6,Add 4,Sub 3,Sub 4,Add 3]），也即为最终的数据状态值。\n2.2 SOFAJRaft Snapshot 机制的实践应用 如果用户需开启 SOFAJRaft 的 Snapshot 机制，则需要在其客户端中设置配置参数类 NodeOptions …","date":1569232800,"description":"本文为《剖析 | SOFAJRaft 实现原理》最后一篇，本篇作者胡宗棠。","dir":"blog/sofa-jraft-snapshot-principle-analysis/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"39ff132d4c11bccb0059665f6e9c4b31","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","publishdate":"2019-09-23T18:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","wordcount":4407},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@wy223170 提问：\n 你好，请问下 SOFAJRaft 如何在虚拟化环境下使用，比如部署三个实例，三个实例都是 docker 的。因为虚拟化实例可能漂移，怎么保证 snapshot 的迁移呢？另外怎么控制多个实例的同时漂移，导致集群不可用的问题？\n A：SOFAJRaft 本身是有状态的，你说的实例漂移就可以理解为这个节点挂掉并新拉起了一个节点，我们内部的做法是通过一个 manager 节点监听容器上下线并执行 CliService removePeer 和 addPeer，利用 raft 协议本身的能力达到数据迁移的目的，但是对于半数以上节点同时漂移是无解的，可能出现丢数据的情况。这是 etcd 的一个解决类似问题的方式，供参考：https://github.com/coreos/etcd-operator\n 感谢回答，是不是只要 manager 节点监听到容器变化就会立刻进行 removePeer 或 addPeer，需不需等待容器已经达到某种状态，比如迁移完 snapshot 等才进行 addPeer 之类的，这可能就需要实例迁移后完成一个打标记的功能标志迁移完成了。\n A：流程是先 addPeer 成功以后再 removePeer。其中 addPeer 在追数据成功后才会返回成功。看到你多次强调 snapshot，其实这里你不用关注 snapshot，这是 SOFAJRaft 内部会考虑的 raft 层的东西，不需要额外做特殊处理。\n开源项目 ElasticDL：蚂蚁金服开源基于 TensorFlow 的弹性分布式深度学习系统 蚂蚁金服开源机器学习工具 SQLFlow，技术架构独家解读 SOFA 项目进展 本周发布详情如下：\n发布 Seata v0.8.1，主要变更如下：\n 支持配置文件使用绝对路径 支持 DataSource 的自动代理 支持通信协议的 kryo 编解码 修复 file 存储模式的 selectForUpdate lockQuery exception 修复数据库连接使用后的 autocommit 问题 优化 etcd3 中 watcher 订阅的效率 优化当数据表无索引时抛出显式异常 详细发布报告： https://github.com/seata/seata/releases/tag/v0.8.1\nSOFAJRaftLab 系列阅读 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 ","date":1568962800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190920/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4519012918ba68bf9e39b0daed78cfc4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190920/","publishdate":"2019-09-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190920/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/16 - 9/20】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190920/","wordcount":1043},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第七篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文末包含往期系列文章。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 在分布式部署、高并发、多线程场景下，我们经常会遇到资源的互斥访问的问题，最有效、最普遍的方法是给共享资源或者对共享资源的操作加一把锁。在 JDK 中我们可以使用 ReentrantLock 重入锁或者 synchronized 关键字达成资源互斥访问目的，但是由于分布式系统的分布性（即多线程和多进程并且分布在不同机器中），使得两种锁失去原有锁的效果，需要用户自定义来实现分布式锁。\n本文重点围绕分布式锁概览、实现方式以及基于 SOFAJRaft 实现等方面剖析 SOFAJRaft-RheaKV 基于 SOFAJRaft 实现分布式锁原理，阐述如何使用 SOFAJRaft 组件提供分布式锁服务功能：\n 什么是分布式锁？分布式锁具备哪些条件？分布式锁有哪些实现方式？ RheaKV 基于 SOFAJRaft 如何实现分布式锁？解决分布式锁哪些问题？ 分布式锁 分布式锁是控制分布式系统之间同步访问共享资源的一种方式，用于在分布式系统中协调他们之间的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下便需要使用到分布式锁。分布式锁通过共享标识确定其唯一性，对共享标识进行修改时能够保证原子性和对锁服务调用方的可见性。\n分布式锁概览 Martin Kleppmann 是英国剑桥大学的分布式系统研究员，之前和 Redis 之父 Antirez 关于 RedLock 红锁是否安全的问题激烈讨论过。Martin 认为一般我们使用分布式锁有两个场景：\n 效率：使用分布式锁能够避免不同节点重复相同的工作导致浪费资源，譬如用户付款之后有可能不同节点发出多条短信； 正确性：添加分布式锁同样避免破坏正确性事件的发生，如果两个节点在同一条数据上面操作，譬如多个节点机器对同一个订单操作不同的流程有可能导致该笔订单最后状态出现错误造成资金损失； 分布式锁需要具备的条件包括：\n 获取锁和释放锁的性能要好； 判断获得锁是否是原子性的，否则可能导致多个请求都能获取到锁； 网络中断或者宕机无法释放锁时，锁必须被清除； 可重入一个线程中多次获取同一把锁，譬如一个线程在执行带锁的方法，该方法调用另一个需要相同锁的方法，则该线程直接执行调用的方法，而无需重新获得锁； 阻塞锁和非阻塞锁，阻塞锁即没有获取到锁，则继续等待获取锁；非阻塞锁即没有获取到锁，不继续等待直接返回获取锁失败； 分布式锁实现 分布式 CAP 理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance），最多只能同时满足两项。”，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。在很多场景中为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候需要保证一个方法在同一时间内只能被同一个线程执行。 分布式锁一般有三种实现方式：\n 基于数据库实现分布式锁； 基于缓存（Redis，Memcached，Tair）实现分布式锁； 基于 ZooKeeper 实现分布式锁； 基于数据库实现分布式锁 基于数据库实现分布式锁的核心思想：在数据库中创建一张表，表里包含方法名等字段，并且在方法名字段上面创建唯一索引，执行某个方法需要使用此方法名向表中插入数据，成功插入则获取锁，执行结束则删除对应的行数据释放锁。\n基于缓存实现分布式锁 基于缓存通常选用 Redis 实现分布式锁，考虑到 Redis 有非常高的性能，Redis 命令对分布式锁支持友好，并且实现方便。基于单 Redis 节点的分布式锁在 Failover 的时候产生解决不了的安全性问题，Redlock 是 Redis 的作者 Antirez 提出的集群模式 Redis 分布式锁，基于 N 个完全独立的 Redis 节点（通常情况下 N 可以设置成5），运行 Redlock 算法依次执行下面各个步骤完成获取锁的操作\n 获取当前时间（毫秒数）； 按顺序依次向 N 个 Redis 节点执行获取锁的操作。此获取操作包含随机字符串 my_random_value，也包含过期时间(比如 PX 30000，即锁的有效时间)。为了保证在某个 Redis 节点不可用的时候算法能够继续运行，获取锁的操作还有超时时间(time out)，它要远小于锁的有效时间（几十毫秒量级）。客户端在向某个 Redis 节点获取锁失败以后应该立即尝试下一个Redis 节点。这里的失败包含任何类型的失败，比如该 Redis 节点不可用，或者该 Redis 节点上的锁已经被其它客户端持有（注：Redlock 原文中这里只提及 Redis 节点不可用的情况，但也应该包含其它的失败情况）； 计算整个获取锁的过程总共消耗了多长时间，计算方法是用当前时间减去第1步记录的时间。如果客户端从大多数 Redis 节点（\u0026amp;gt;= N/2+1）成功获取到了锁，并且获取锁总共消耗的时间没有超过锁的有效时间（lock validity time），那么这时客户端才认为最终获取锁成功；否则认为最终获取锁失败； 如果最终获取锁成功了，那么此锁的有效时间应该重新计算，它等于最初锁的有效时间减去第3步计算出来的获取锁消耗的时间； 如果最终获取锁失败（可能由于获取到锁的 Redis 节点个数少于 N/2+1，或者整个获取锁的过程消耗的时间超过了锁的最初有效时间），那么客户端立即向所有 Redis 节点发起释放锁的操作； 基于 ZooKeeper 实现分布式锁 ZooKeeper 是以 Paxos 算法为基础的分布式应用程序协调服务，为分布式应用提供一致性服务的开源组件，其内部是分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于 ZooKeeper 实现分布式锁步骤包括：\n 创建一个锁目录 lock； 希望获得锁的线程 A 在 lock 目录下创建临时顺序节点； 当前线程获取锁目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在表示当前线程顺序号最小，获得锁； 线程 B 获取所有节点，判断自己不是最 …","date":1568721600,"description":"本文为《剖析 | SOFAJRaft 实现原理》第七篇，本篇作者米麒麟。","dir":"blog/sofa-jraft--rheakv-distributedLock/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"be578aa3941f24a603a7053e7c7e1107","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","publishdate":"2019-09-17T20:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","剖析 | SOFAJRaft 实现原理","SOFALab"],"title":"SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","wordcount":6176},{"author":"Oschina","categories":"ElasticDL","content":" 9 月 11 日，蚂蚁金服在2019谷歌开发者大会上海站上开源了 ElasticDL 项目，这是业界首个基于 TensorFlow 实现弹性深度学习的开源系统。\n开源地址为：https://github.com/sql-machine-learning/elasticdl/\n开源中国采访了 ElasticDL 项目负责人王益，对该深度学习系统的技术细节进行了全面介绍。\n基于 TensorFlow 2.0 和 Kubernetes实现弹性深度学习 这个基于 Eager Execution 模式的开源项目名为“ElasticDL”，它是一个Kubernetes 原生深度学习框架，根据介绍，ElasticDL 主要有四大特点：\n 容错性 弹性调度 易用性 高效 其中又以容错与弹性调度特性最具特色。\nElasticDL 实现了容错和弹性调度的分布式深度学习，可以极大提升集群的总体利用率，同时显著减少用户提交作业之后等待作业启动的时间（pending time）。\n王益介绍：“ElasticDL 是我们知道的第一个基于 TensorFlow 实现弹性深度学习的开源系统。具体地说，ElasticDL 是基于 TensorFlow 2.0 和 Kubernetes 实现弹性深度学习的。”\n集群效用从 1/N 到 N/N 在深度学习技术研发的早期，公用一个计算集群的人相对少， 计算作业之间的协调可以通过口头交流实现。开发者更关心缩短运行时间，也就是从作业启动到结束的这段时间。高性能计算技术（HPC）是解决这个问题的有效途径，比如 NVIDIA 的 cuBLAS 和 cuDNN 优化高性能数学计算、NCCL 优化 GPU 之间的通信效率。\n随着深度学习技术的大规模应用，在许多工程师和研究员公用一个集群的情况下，通过商量来协调调度显然不可行，于是大家开始使用集群管理系统调度分布式作业。\nKubernetes 近年来已经逐渐成为集群管理的重要工具，目前已经在各大公有云中广泛采用。因此，让 TensorFlow 能更好地运行在 Kubernetes 集群上，同时提升利用集群进行深度学习的效率和资源利用率（效用），显得非常具有实际意义。\n关于提升集群资源利用率，王益举了一个比较极端的例子：假设一个集群有 N 个 GPU，而一个任务只使用其中一个，现在有一个任务占用了一个 GPU。当没有弹性调度机制时，一个要求所有 N 个 GPU 的任务需要等待前一个任务结束才能开始，这个等待时间可能高达数天甚至数周，在等待期间，集群的效用是 1/N；而拥有弹性调度能力之后，新的任务可以在 N-1 个 GPU 上立即运行，并且 Kubernetes 可以在第一个任务完成后将占用的 GPU 赋予这个任务，这种情况下，集群整体效用是 100%。\nElasticDL 在容错与弹性调度上都有不错的表现，它的现实意义便是高效解决集群效用问题。\nElasticDL 如何实现？ 前边讲到集群资源利用率提高的前提其实就是ElasticDL 的“弹性调度”特性带来的，而弹性调度依赖于容错能力。\n容错是指作业不受其中进程数量变化的影响，在弹性调度过程中，作业里的进程数量会随集群 workload 情况相应增减，所以作业必须是容错的，才能配合调度系统，实现弹性调度。\n在这个过程中，容错通常由分布式框架实现，比如 Spark 和 ElasticDL 都可以做到当有进程挂掉，或者新的进程加入时，作业不会暂停或者重启，而是平滑地继续。而弹性调度是由分布式框架和分布式操作系统（集群管理系统）一起实现的。比如，当有进程挂掉的时候，分布式框架应该通知集群管理系统新启进程来补位 —— 至于集群管理系统能不能启动起来，取决于用户剩余 quota 和集群的忙碌情况。\n1. 基于 Kubernetes-native 通常使用 Keras 的 model-fit API 和 Estimator，开发者只需要调用 API 即可进行分布式训练或预测，然而 ElasticDL 不依赖于 TensorFlow runtime 实现分布式计算，它的实现在 runtime 之外。\nElasticDL 通过 Kubernetes-native 机制来完成分布式计算，而这也为其带来了容错性与弹性调度的能力。\n所谓 Kubernetes-native指的是一个程序调用 Kubernetes API 来起止进程，它与 Google MapReduce 的机制类似。MapReduce 是一个 Borg-native 的分布式计算框架，用户通过运行一个 Borg 客户端程序启动一个 MapReduce 作业；Borg 客户端调用 Borg API 提交作业，并且启动一个 master 进程；这个 master 调用 Borg API 启动其它 workers 进程。\n在 ElasticDL 中，用户调用 ElasticDL 的命令行客户端程序启动作业；这个客户端程序调用Kubernetes API 启动 master 进程，master进程继续调用 Kubernetes API 启动其它进程。\n“ElasticDL 的整个容错和弹性调度机制都依赖于 Kubernetes-native 架构”，王益介绍：“如果 worker 挂了，按照分布式深度学习训练算法的数学特性，可以不用处理，即可确保训练过程继续。如果一个 parameter server 进程挂了，master会选择一个 worker 进程，让它转换角色替补上挂掉的parameter server 进程。”\n在这两种情况下，master 都会调用 Kubernetes API，请它再启动一个额外的 worker 进程。如果启动成功，master 会带其加入到与其它进程的协作中。master 进程的状态（主要是三个 task queues：todo、doing与 done）可以保留在 Kubernetes 集群的 etcd 存储系统中。\n“这样，万一 master 挂了，重启的 master 进程可以从 etcd 继承前世的状态。任何进程挂了，master 都会请 Kubernetes 去启动一个新的进程代替挂掉的进程。而 Kubernetes 是否能完成使命取决于用户剩余 quota 和集群剩余资源情况。”\n2. 基于 TensorFlow 2.0 EagerExecution 为什么 ElasticDL 又基于 TensorFlow 2.0 呢？王益介绍，这是因为 TensorFlow 2.0 带来了 Eager Execution 特性，正是针对这一特性的尝试，让开发团队实现了Kubernetes-native 的调度方式，从而让 ElasticDL 支持容错和弹性调度。\n分布式学习需要了解每个进程根据局部训练数据计算得到的 gradients，才能汇总这些 gradients 来更新模型。\nTensorFlow 1.x 的执行方式被称为 Graph Mode —— 深度学习计算步骤被表示成一个 graph 数据结构，TensorFlow runtime 会解释执行这个 graph。其中，gradients 的计算过程是 graph …","date":1568635200,"description":"业界首个基于 TensorFlow 实现弹性深度学习的开源系统 ElasticDL 项目的技术细节全面介绍。","dir":"blog/alipay-deep-learning-tensorflow-elasticdl/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"74eedc82d0b4a438d332dd5443605318","permalink":"https://sofastack.github.io/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","publishdate":"2019-09-16T20:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","summary":"9 月 11 日，蚂蚁金服在2019谷歌开发者大会上海站上开源了 ElasticDL 项目，这是业界首个基于 TensorFlow 实现弹性深度学习的开源系统。 开源地址为：https://g","tags":["ElasticDL"],"title":"ElasticDL：蚂蚁金服开源基于 TensorFlow 的弹性分布式深度学习系统","type":"blog","url":"/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","wordcount":4705},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n中秋特辑推荐阅读 【中秋特辑】（含视频回顾）SOFAStack 活动回顾整理集合 SOFARegistry 系列解析文章 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 本周发布详情如下：\n发布 SOFARPC v5.6.1，主要变更如下：\n 升级 sofa-bolt 的版本到 1.5.6 修复 com.alipay.sofa.rpc.log.LoggerFactory 提供的 Logger 实现方案在多 classloader 场景下存在会出现类型不匹配的问题 修复 providerInfo 中可能出现的 staticAttrs 空指针问题 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.1\nHey，中秋快乐呀 ","date":1568271600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190913/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"85b998cb10df30ee42c04a8571b73598","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190913/","publishdate":"2019-09-12T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190913/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/9 - 9/13】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190913/","wordcount":423},{"author":"Yavin","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第三篇，本篇作者 Yavin，来自考拉海购。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n导读 集群成员管理是分布式系统中绕不开的话题。MetaServer 在 SOFARegistry 中，承担着集群元数据管理的角色，用来维护集群成员列表。本文希望从 MetaServer 的功能和部分源码切入剖析，为学习研究、或者项目中使用SOFARegistry 的开发者带来一些启发，分为三个部分：\n 功能介绍 内部架构 源码分析 功能介绍 MetaServer 作为 SOFARegistry 的元数据中心，其核心功能可以概括为集群成员管理。分布式系统中，如何知道集群中有哪些节点列表，如何处理集群扩所容，如何处理集群节点异常，都是不得不考虑的问题。MetaServer 的存在就是解决这些问题，其在 SOFARegistry 中位置如图所示： MetaServer 通过 SOFAJRaft 保证高可用和一致性，类似于注册中心，管理着集群内部的成员列表：\n 节点列表的注册与存储 节点列表的变更通知 节点健康监测 内部架构 内部架构如下图所示：\nMetaServer 基于 Bolt, 通过 TCP 私有协议的形式对外提供服务，包括 DataServer, SessionServer 等，处理节点的注册，续约和列表查询等请求。\n同时也基于 Http 协议提供控制接口，比如可以控制 session 节点是否开启变更通知, 健康检查接口等。\n成员列表数据存储在 Repository 中，Repository 被一致性协议层进行包装，作为 SOFAJRaft 的状态机实现，所有对 Repository 的操作都会同步到其他节点, 通过Rgistry来操作存储层。\nMetaServer 使用 Raft 协议保证数据一致性， 同时也会保持与注册的节点的心跳，对于心跳超时没有续约的节点进行驱逐，来保证数据的有效性。\n在可用性方面，只要未超过半数节点挂掉，集群都可以正常对外提供服务， 半数以上挂掉，Raft 协议无法选主和日志复制，因此无法保证注册的成员数据的一致性和有效性。整个集群不可用 不会影响 Data 和 Session 节点的正常功能，只是无法感知节点列表变化。\n源码分析 服务启动 MetaServer 在启动时，会启动三个 Bolt Server，并且注册 Processor Handler，处理对应的请求, 如下图所示：\n DataServer：处理 DataNode 相关的请求； SessionServer：处理 SessionNode 相关的请求； MetaServer：处理MetaNode相关的请求； 然后启动 HttpServer, 用于处理 Admin 请求，提供推送开关，集群数据查询等 Http 接口。\n最后启动 Raft 服务， 每个节点同时作为 RaftClient 和 RaftServer, 用于集群间的变更和数据同步。\n各个 Server 的默认端口分别为：\nmeta.server.sessionServerPort=9610 meta.server.dataServerPort=9611 meta.server.metaServerPort=9612 meta.server.raftServerPort=9614 meta.server.httpServerPort=9615 节点注册 由上节可知，DataServer 和 SessionServer 都有处理节点注册请求的 Handler。注册行为由 Registry 完成。注册接口实现为：\n@Override public NodeChangeResult register(Node node) { StoreService storeService = ServiceFactory.getStoreService(node.getNodeType()); return storeService.addNode(node); } Regitsry 根据不同的节点类型，获取对应的StoreService，比如DataNode，其实现为 DataStoreService 然后由 StoreService 存储到 Repository 中，具体实现为：\n// 存储节点信息 dataRepositoryService.put(ipAddress, new RenewDecorate(dataNode, RenewDecorate.DEFAULT_DURATION_SECS)); //... // 存储变更事件 dataConfirmStatusService.putConfirmNode(dataNode, DataOperator.ADD); 调用 RepositoryService#put 接口存储后，同时会存储一个变更事件到队列中，主要用于数据推送，消费处理。\n节点数据的存储，其本质上是存储在内存的哈希表中，其存储结构为：\n// RepositoryService 底层存储 Map\u0026amp;lt;String/*dataCenter*/, NodeRepository\u0026amp;gt; registry; // NodeRepository 底层存储 Map\u0026amp;lt;String/*ipAddress*/, RenewDecorate\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; nodeMap; 将RenewDecorate存储到该 Map 中，整个节点注册的流程就完成了，至于如何和 Raft 协议进行结合和数据同步，下文介绍。\n节点移除的逻辑类似，将节点信息从该 Map 中删除，也会存储一个变更事件到队列。\n注册信息续约和驱逐 不知道有没有注意到，节点注册的时候，节点信息被 RenewDecorate 包装起来了，这个就是实现注册信息续约和驱逐的关键：\nprivate T renewal; // 节点对象封装 private long beginTimestamp; // 注册事件 private volatile long lastUpdateTimestamp; // 续约时间 private long duration; // 超时时间 该对象为注册节点信息，附加了注册时间、上次续约时间、过期时间。那么续约操作就是修改lastUpdateTimestamp，是否过期就是判 …","date":1568271600,"description":" 本文为《剖析 | SOFARegistry 框架》第三篇，作者 Yavin ，来自考拉海购。","dir":"blog/sofa-registry-metaserver-function-introduction/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6e08281a1d2851d95121fc739cf80669","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","publishdate":"2019-09-12T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","wordcount":3311},{"author":"潘潘","categories":"SOFAStack","content":" SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时任务、限流/熔断框架、动态配置推送、分布式链路追踪、Metrics 监控度量、分布式高可用消息队列、分布式事务框架和分布式数据库代理层等。\nSOFAStack：https://github.com/sofastack\n本文为 SOFAStack 相关线上线下活动的回顾集合，并且会不定时更新。\n/ SOFAChannel 线上直播系列 / SOFAChannel#8 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 视频回顾资料 SOFAChannel#7 自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 视频回顾资料 SOFAChannel#6 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 视频回顾资料 SOFAChannel#5 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 视频回顾资料 SOFAChannel#4 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 视频回顾资料 SOFAChannel#3 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 视频回顾资料 SOFAChannel#2 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 视频回顾资料 SOFAChannel#1 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 视频回顾资料 / SOFAMeetup 系列 / SOFAMeetup#3\u0026amp;lt;广州站\u0026amp;gt; 分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾 视频回顾资料\n 蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾 视频回顾资料\n SOFAMeetup#2\u0026amp;lt;上海站\u0026amp;gt; 当 Spring Cloud 遇上 SOFAStack | Meetup#2 回顾 视频回顾资料\n 基于 SOFAArk 和 SOFADashboard 实现动态模块管控 | Meetup#2 回顾 视频回顾资料\n SOFAMeetup#1\u0026amp;lt;北京站\u0026amp;gt; 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼 视频回顾资料\n 蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼 视频回顾资料\n 详解蚂蚁金服 SOFAJRaft | 生产级高性能 Java 实现 视频回顾资料\n / 技术大会系列 / 2019 年技术大会实录集合 五小时构建云原生电商平台 | KubeCon SOFAStack Workshop 详解\n 蚂蚁金服大规模分布式事务实践和开源历程 | GIAC 实录\n 蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录\n 2018 年技术大会实录集合 企业实施分布式架构的挑战以及应对建议 | 上海 ATEC 大会实录\n 企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录\n Knative：重新定义 Serverless | GIAC 实录\n 蚂蚁金服微服务实践 | 开源中国年终盛典分享实录\n 蚂蚁金服Service Mesh新型网络代理的思考与实践 | GIAC 分享实录\n 蚂蚁金服 Service Mesh 渐进式迁移方案|Service Mesh Meetup 实录\n 蚂蚁金服SOFAMesh在多语言上的实践 | CNUTCon 实录\n 从平台到中台 | Elaticsearch 在蚂蚁金服的实践经验\n 从“挖光缆”到“剪网线”|蚂蚁金服异地多活单元化架构下的微服务体系\n 蚂蚁金服 Service Mesh 实践探索 | Qcon 实录\n ","date":1568260800,"description":"本文为 SOFAStack 相关线上线下活动的回顾集合，并且会不定时更新。","dir":"blog/sofa-activity-retrospect-collection/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b1f0034b1e2c249a33c57be88f5a184c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-activity-retrospect-collection/","publishdate":"2019-09-12T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-activity-retrospect-collection/","summary":"SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时","tags":["SOFAStack"],"title":"（含视频回顾）SOFAStack 活动回顾整理集合","type":"blog","url":"/sofastack.tech/blog/sofa-activity-retrospect-collection/","wordcount":986},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@王冰 提问：\n 请问个问题，SOFATracer 在采样计算时 rootSpan 为什么会计算两次，第一次是生成 span 时，第二次是在上报前又计算了一次？\n A：这种是考虑到产生 span 的逻辑是业务自己来构建，非正常逻辑情况下的一种兼容处理。对于 Tracer 来说，所有的上报是必须 SOFATracer 的行为，因此在 report 之前也会基于当前采样策略计算一次计算。默认情况下产生跟 span 时的计算更多是 span 或者说 span context 的，这个会作为向下透传的。另外产生不一致的情况不会出现，上报那段逻辑会先检查当前 span 的父 span，如果父 span 是 null 也就意味着当前 span 是 root span，所以也必须要计算。\n2、@迟广文 提问：\n 在使用 Seata 的时候，使用了 restful 框架，我的 TCC 调通了，是在接口上加了 @LocalTCC，实现类加 @Component，本以为会冲突，结果没有。\n A：TCC 的代理会代理二种类型的分支：在本地标注为 localTcc，第二种是 RPC 框架（dubbo、sofa-rpc）当 consumer 端使用作为 reference bean 且在 provider 端标注了二阶段注解时，这二种类型时互斥的，一个 TCC 分支只属于其一类型。\nSOFAChannel 回顾集合 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、SOFATracer v2.4.1/v3.0.6 版本发布，主要变更如下：\n 支持自定义埋点 (FlexibleTracer) 支持 Dubbo 2.6.x 日志输出支持非 json 格式(xstringbuilder)\n 支持自定义扩展 Repoter 上报\n Dubbo 2.7.x 系列支持 2.7.3 版本\n 修复 BasePreparedStatement 初始化问题\n 修复 SQLException 被覆盖问题\n 优化常量命名及代码注释等\n 更新案例及官方文档\n 详细发布报告：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v2.4.1\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.0.6\n官方文档：\nhttps://www.sofastack.tech/projects/sofa-tracer/overview/\n2、SOFABoot v3.2.0 版本发布，主要变更如下：\n 升级 sofa-bolt 版本至 1.5.6 根据 Spring Boot 官方文档建议重构工程代码和组织结构 详细发布报告：\nhttps://github.com/sofastack/sofa-boot/releases/tag/v3.2.0\n官方文档：\nhttps://www.sofastack.tech/projects/sofa-boot/overview/\nSOFA 用户召集 如果您已经在生产环境使用了 SOFAStack 相关组件，请在下方链接登记告诉我们，方便我们更好地为您服务，我们将会把您加入到 “SOFAStack金牌用户服务群【邀约制】”里面，以便更加快捷的沟通和更加高效的线上使用问题支持。 https://github.com/sofastack/sofastack.tech/issues/5 已有用户查看： https://www.sofastack.tech/awesome\n","date":1567753200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190906/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"94743dfe34353e1f6910291d127a73d6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190906/","publishdate":"2019-09-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190906/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/2 - 9/6】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190906/","wordcount":1296},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:RegistryLab/\u0026amp;gt;是《剖析 | SOFARegistry 实现原理》系列，会逐步详细介绍 SOFARegistry 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFARegistry SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nSOFARegistry:https://github.com/sofastack/sofa-registry\n| SOFA:RegistryLab 认领列表：\n 【已完成】海量数据下的注册中心 - SOFARegistry 架构介绍 【已完成】SOFARegistry 服务发现优化之路 【已完成】SOFARegistry 数据分片和同步方案详解 【已完成】SOFARegistry MetaServer 功能介绍和实现剖析 【已完成】SOFARegistry Session 存储策略 【已领取】SOFARegistry 如何实现秒级服务上下线通知 【已领取】SOFARegistry 如何实现 DataServer 平滑扩缩容 参与方式：关注「金融级分布式架构」回复可领取的文章标题，会有相关同学联系进行确认。\n 欢迎领取，参与共建~\n","date":1567483200,"description":"","dir":"activities/sofa-registry-lab/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ebbc0e9574d88e21f39926e750c848e9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-registry-lab/","publishdate":"2019-09-03T12:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-registry-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:RegistryLab/\u0026gt;是《剖析 | SOFARegistry 实现原理》系列","tags":["SOFALab","SOFARegistry"],"title":"\u003cSOFA:RegistryLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-registry-lab/","wordcount":435},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFA:Channel/，有趣实用的分布式架构频道。\n本文根据 SOFAChannel#8 直播分享整理，主题：从一个例子开始体验 SOFAJRaft。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23390449，不错过每场直播。\n 大家好，我是力鲲，来自蚂蚁金服， 现在是 SOFAJRaft 的开源负责人。今天分享主题是《从一个例子开始体验 SOFAJRaft》，其实从这个题目大家也能看出来，今天是要从一个用户而非 owner 的视角来了解 SOFAJRaft。这么设计题目的原因是 SOFAJRaft 作为一种共识算法的实现，涉及到了一些概念和术语，而这些内容更适合通过一系列文章进行阐述，而在直播中我们希望能够分享对用户更有用、更容易理解的信息——SOFAJRaft 是什么，以及我们怎么去用它。\n首先介绍一下 SOFAJRaft 的背景知识，接下来说说这个例子源于什么需求，第三部分是架构的选型，第四部分来看看我们如何使用 SOFAJRaft，最后运行代码，看看 SOFAJRaft 是如何支撑业务运行的。\n欢迎加入社区成为 Contributor，SOFAJRaft。\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务； 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\n图1 - 复制状态机\nSOFAJRaft SOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统。\n图2 - SOFAJRaft 结构\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依然用之前的银行账户系统举例来说明 SOFAJRaft 的各模块是如何工作的。\n当 Client 向 SOFAJRaft 发来一个“存 100 元”的命令之后，Node 的 Log 存储模块首先将这个命令以 Log 的形式存储到本地，同时 Replicator 会把这个 Log 复制给其他的 Node，Replicator 是有多个的，集群中有多少个 Follower 就会有多少个 Replicator，这样就能实现并发的日志复制。当 Node 收到集群中半数以上的 Follower 返回的“复制成功” 的响应之后，就可以把这条 Log 以及之前的 Log 有序的送到状态机里去执行了。状态机是由用户来实现的，比如我们现在举的例子是银行账户系统，所以状态机执行的就是账户金额的借贷操作。如果 SOFAJRaft 在别的场景中使用，状态机就会有其他的执行方式。\nSnapshot 是快照，所谓快照就是对数据当前值的一个记录，Leader 生成快照有这么几个作用：\n 当有新的 Node 加入集群的时候，不用只靠日志复制、回放去和 Leader 保持数据一致，而是通过安装 Leader 的快照来跳过早期大量日志的回放； Leader 用快照替代 Log 复制可以减少网络上的数据量； 用快照替代早期的 Log 可以节省存储空间； 图3 - 需要用户实现：StateMachine、Client\nSOFAJRaft 需要用户去实现两部分：StateMachine 和 Client。\n因为 SOFAJRaft 只是一个工具，他的目的是帮助我们在集群内达成共识，而具体要对什么业务逻辑达成共识是需要用户自己去定义的，我们将用户需要去实现的部分定义为 StateMachine 接口。比如账务系统和分布式存储这两种业务就需要用户去实现不同的 StateMachine 逻辑。而 Client 也很好理解，根据业务的不同，用户需要去定义不同的消息类型和客户端的处理逻辑。\n图4 - 需要用户实现一些接口\n前面介绍了这么多，我们引出今天的主题：如何用 SOFAJRaft 实现一个分布式计数器？\n需求 我们的需求其实很简单，用一句话来说就是：提供一个 Counter，Client 每次计数时可以指定步幅，也可以随时发起查询。\n我们对这个需求稍作分析后，将它翻译成具体的功能点，主要有三部分：\n 实现：Counter server，具备计数功能，具体运算公式为：Cn = Cn-1 + delta； 提供写服务，写入 delta 触发计数器运算； 提供读服务，读取当前 Cn 值； 除此之外，我们还有一个可用性的可选需求，需要有备份机器，读写服务不能不可用。\n系统架构 根据刚才分析出来的功能需求，我们设计出 1.0 的架构，这个架构很简单，一个节点 Counter Server 提供计数功能，接收客户端发起的计数请求和查询请求。\n图5 - 架构 1.0\n但是这样的架构设计存在这样两个问题：一是 Server 是一个单点，一旦 Server 节点故障服务就不可用了；二是运算结果都存储在内存当中，节点故障会导致数据丢失。\n图6 - 架构 1.0 的不足：单点\n针对第二个问题，我们优化一下，加一个本地文件存储。这样每次计数器完成运算之后都将数据落盘，当节点故障之时，我们要新起一台备用机器，将文件数据拷贝过来，然后接替故障机器对外提供服务。这样就解决了数据丢失的风险，但是同时也引来另外的问题：磁盘 IO 很频繁，同时这种冷备的模式也依然会导致一段时间的服务不可用。\n图7 - 架构 1.0 的不足：冷备\n所以我们提出架构 2.0，采用集群的模式提供服务。我们用三个节点组成集群，由一个节点对外提供服务，当 Server 接收到 Client 发来的写请求之后，Server 运算出结果，然后将结果复制给另外两台机器，当收到其他所有节点的成功响应之后，Server 向 Client 返回运算结果。\n图8 - 架构 2.0\n但是这样的架构 …","date":1567400400,"description":"本文根据 SOFAChannel#8 直播分享整理，以 Counter 为例，介绍 SOFAJRaft 的概念，并从需求提出开始，一步步完善架构，明确业务要实现哪些接口，最后启动日志观察 SOFAJRaft 如何支撑业务执行。","dir":"blog/sofa-channel-8-retrospect/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7eab29bc73ad095706ad2daef197b1bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-8-retrospect/","publishdate":"2019-09-02T13:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-channel-8-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#8 直播分享整理，主题：从一个例子开始体验 SOFAJRaft。 回顾视频以及 PPT 查看","tags":["SOFAJRaft","SOFAChannel"],"title":"从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-8-retrospect/","wordcount":5541},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@柴炜晨 提问：\n 求问下 SOFAJRaft rhea split 后，原片1 [0,100) 分裂为 1 [0, 50) , 新片 2[50, 100)，新片 2 上的初始数据是从怎么来的呢？\n A：一个 store 里的所有 region 实际上是共享一个存储，split 只是新增一个逻辑 region 并修改被分裂的和新 region 的 range，后续的 snoapshot ，副本迁移等就均以新的 region 为最小单位了。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、关于 SOFARegistry 的几个问题：\n@虞家成 提问：\n 服务 Sub 数据的一致性问题，其中主要的机制是通过 client, session 对缓存的逐级回放和比对，再加上版本号机制来实现最终一致性，问题是：这个版本号的生成，与递增是由谁来管理与维护？client? session? 还是 data ?\n A：这个版本号主要是在 data 上产生，版本号和最终写入内存时间戳关联产生，所有数据是指服务发布数据保证一致性。\n 对于每条服务的 Pub 数据，是否需要维护一个 ttl 值，否则在某些情况下，这条数据不能释放？\n A：如果你说的 ttl 值是指 pub 数据的生存时间，是有的，我们 pub 数据会有租约机制进行定时更新保证一致性，如果过期会进行清理释放。\n Data 节点是通过广播的方式来通知每个 session 节点？那每个 session 节点是否会存在所有服务的全量 Pub 数据？ 这对内存及网络资源消耗会不会过大？\n A：Data 是通过广播方式通知每个 session 节点，session上有订阅关系按照自己订阅关系判断是否需要推送给客户端。每个 session 没有全量的 pub 数据，但会存在和其连接部分客户端发布数据作为一致性备份回放使用。这个堆内存目前看压力还是可以的。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n3、@黄剑 提问：\n 关于 Seata 有一个问题，全局锁用进去之后，意思就是要等 2 阶段完成后，进行当前资源释放，全局锁那边的接口才进行调用到，如果业务有很多地方都操作到相同表的某一条数据，那岂不是每个业务上面加全局锁？可是我并不知道哪些业务可能会有冲突的哇！\n A：目前只查锁不加锁。\n 我需要查到最终 2 阶段的那张表数据，意思自己的业务上面全部都要使用 @GlobalLock 注解？是这个意思么？\n A：如果你查询的业务接口没有 GlobalTransactional 包裹，也就是这个方法上压根没有分布式事务的需求，这时你可以在方法上标注 @GlobalLock 注解，并且在查询语句上加 for update。如果你查询的接口在事务链路上外层有 GlobalTransactional 注解，那么你查询的语句只要加 for update 就行。设计这个注解的原因是在没有这个注解之前，需要查询分布式事务读已提交的数据，但业务本身不需要分布式事务。若使用 GlobalTransactional 注解就会增加一些没用的额外的 rpc 开销比如 begin 返回 xid，提交事务等。GlobalLock 简化了 rpc 过程，使其做到更高的性能。\n 好的，感谢回复，因为现在出现了一个业务，但是不同接口，上游有全局事务来调用，然后又有其他业务操作了相同的表，所以现在导致我现在根本不知道哪些业务要考虑使用 GlobalLock。\n Seata：https://github.com/seata/seata\n本周推荐阅读 Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录 Service Mesh 发展趋势：云原生中流砥柱 SOFA 项目进展 本周发布详情如下：\n发布 SOFA Mosn v0.7.0，主要变更如下：\n 新增 FeatureGates 的支持 新增一项 Metrics 统计:mosn_process_time 支持 Listener 重启 升级 Go 版本到 1.12.7 修改 XDS Client 启动时机，优先于 MOSN Server 的启动 BUG 修复 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/0.7.0\n","date":1567148400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190830/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"afd535d1a14ed1fc010e93bcff36553d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190830/","publishdate":"2019-08-30T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190830/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/26 - 8/30】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190830/","wordcount":1599},{"author":"敖小剑","categories":"Service Mesh","content":" 敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。\n本文内容整理自 8 月 11 日 Service Mesher Meetup 广州站主题演讲，完整的分享 PPT 获取方式见文章底部。\n 前言 标题“Service Mesh发展趋势(续)”中的“续”是指在今年5月底，我在 CloudNative Meetup上做了一个“Service Mesh发展趋势：云原生中流砥柱”的演讲，当时主要讲了三块内容：Service Mesh 产品动态、发展趋势、与云原生的关系。后来有同学反应希望部分感兴趣的内容能讲的更深一些，所以今天将继续“Service Mesh 发展趋势”这个话题。\n今天给大家分享的内容有部分是上次演讲内容的深度展开，如社区关心的 Mixer v2 以及最近看到的一些业界新的技术方向，如 web assembly 技术，还有产品形态上的创新，如 google traffic director 对 Service Mesh 的虚拟机形态的创新支持。\n在 Service Mesh 出道四年之际，也希望和大家一起带着问题来对 Service Mesh 未来的发展进行一些深度思考。\n在正式开始分享之前，让我们先轻松一下，下面是最近流行的梗，各种灵魂拷问：\n我们今天的分享内容，将效仿上面的方式，对 Servic Mesh 进行四个深入灵魂的拷问。\nService Mesh 灵魂拷问一：要架构还是要性能？ 第一个灵魂拷问针对 Istio 的：要架构还是要性能？\nIstio 的回答：要架构 Istio 的回答很明确：架构优先，性能靠边。\n左边是 Istio 的架构图，从 2017 年的 0.1 版本开始，一直到 Istio1.0，控制平面和数据平面完全物理分离，包括我们今天要关注的 Mixer 模块。Sidecar 通过和 Mixer 的交互实现策略检查和遥测报告。\n右边是 Mixer 的架构图，在 Mixer 内部提供了很多 Adapter 实现，用来提供各种功能。这些 Adapter 运行在 Mixer 进程中，因此被称为进程内适配器（In-Process Adapter）。\n为什么 Istio 选择 Mixer 和 Proxy 分离的架构？\n我们先来看这个架构的优点，概括地说优点主要体现为：\n 架构优雅 职责分明 边界清晰 特别指出，上图右侧的红色竖线，是 Istio0.1 到 Istio1.0 版本中 Istio 和后台基础设施的边界。这意味着，从 k8s API Server 中读取 Adapter 相关的配置信息 （以 Istio CRD 的形式存在），是作为 Istio 功能的一部分。\n具体的优点是：\n Mixer 的变动不影响 Sidecar：包括 Mixer 的部署调整和版本升级； Sidecar 无需和 Adapter 耦合，具体有： Sidecar 不需要读取配置，因此也无需直接连接到 k8s AP Server/Istio Galley； Adapter 的运行时资源开销和 Sidecar 无关； Sidecar 不受 Adapter 增减/更新/升级影响； 保持 Sidecar 代码简单：数以几十计的 Adapter 的代码无需直接进入 Sidecar 代码； 数据平面可替换原则：如果有替换数据平面的需求，则 Mixer 分离的架构会让事情简单很多； 至于缺点，只有一个：性能不好。\n而 1.1 版本之后，Istio 给出了新的回答：架构继续优先，性能继续靠边。\n上图是 Istio1.1 版本之后新的架构图，和之前的差异在于 Mixer 发生了变化，增加了进程外适配器（Out-of-Process Adapter），而 Mixer 和新的 Out-of-Process Adapter 之前依然是远程调用。\n为什么 Istio 改而选择 Out-of-Process Adapter?\n下图是采用 Out-of-Process Adapter 之后的请求处理流程图，Mixer 通过 Bypass Adapter 选择需要的属性列表，然后通过远程调用发送给 Out-of-Process Adapter。Out-of-Process Adapter 实现和之前的 In-Process Adapter 类似的功能，但是改为独立于 Mixer 的单独进程。\n采用 Out-of-Process Adapter 之后，Istio 的优点更加明显了，简单说就是：架构更优雅，职责更分明，边界更清晰。\n而且，请注意：按照 Istio 的设想，此时 Out-of-Process Adapter 已经不再作为 Istio 的组成部分，它的代码实现、安装部署、配置、维护等职责也不再由 Istio 承担，请留意上图中的红色竖线位置。Out-of-Process Adapter 的引入，对于 Istio 来说职责和边界的改变会让 Istio 简单，但是对于使用者（主要指运维）来说则增加了额外的负担，因此造成了很大的争议。\n至于缺点，除了上述的职责转移造成争议外，依然只有一个：性能不好，原来 Sidecar 和 Mixer 之间的远程调用已经让性能变得非常糟糕，现在 Mixer 和 Out-of-Process Adapter 之间再增多加一次远程调用，可谓雪上加霜。\nMixer v1 架构的优缺点分析 Mixer v1 架构的优点主要体现为：\n 集中式服务：提高基础设施后端的可用性，为前置条件检查结果提供集群级别的全局 2 级缓存； 灵活的适配器模型，使其以下操作变得简单： 运维添加、使用和删除适配器； 开发人员创建新的适配器（超过20个适配器）； 而 Mixer v1 架构的缺点，则主要体现为：\n 管理开销： 管理 Mixer 是许多客户不想负担的； 而进程外适配器强制运维管理适配器，让这个负担更加重； 性能： 即使使用缓存，在数据路径中同步调用 Mixer 也会增加端到端延迟； 进程外适配器进一步增加了延迟； 授权和认证功能是天然适合 mixer pipeline 的，但是由于 mixer 设计的延迟和 SPOF（单点故障）特性，导致直接在 Envoy 中实现(Envoy SDS)； 复杂性： Mixer 使用一组称为模板的核心抽象，来描述传递给适配器的数据。这些包括“metrics”，“logentry”，“tracepan”等。这些抽象与后端想要消费的数据不匹配，导致运维需要编写一些手动配置，以便在规范的 Istio 样式和后端特定的样式之间进行映射。原本期望这种映射可以在适配器中实现很大程度上的自动化，但是最终还是太复杂并需要手动配置。 备注：上述优点和缺点的描述摘录自 mixer v2 proposal 。\n 其中，Mixer 性能问题一直以来都是 Istio 最被人诟病的地方。\n那问题来了：如果要性能，该怎么做？\n下图是 Mixer v1 的调用流程，Proxy/Sidecar 是请求数据的起点，Infrastructure Backend 是终点。Mixer v1 …","date":1566972000,"description":"继续探讨 Service Mesh 发展趋势：深度分析 Istio 的重大革新 Mixer v2，Envoy 支持 Web Assembly 的意义所在；深入介绍 Google Traffic Director 对虚拟机模式的创新支持方式，以及最近围绕 SMI 发生的故事。","dir":"blog/service-mesh-development-trend-2/","fuzzywordcount":8100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"51e4af6a0771823fe055c5aebd2e76bd","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-development-trend-2/","publishdate":"2019-08-28T14:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/service-mesh-development-trend-2/","summary":"敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。 本文内容整理","tags":["Service mesh"],"title":"Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-development-trend-2/","wordcount":8088},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@廖春涛 提问：\n 在 SOFAJRaft 中，snapshot load 后应该会有个日志重放的实现，但是我目前看代码没看到说 snapshot 和 LogEntry 有关联的地方，请问是什么关系呢？\n A：snapshot 就是为了压缩日志，以及加快新节点加入。snapshot 后，会将上上次的 snapshot 当时对应的日志级之前的删掉，为什么是上上次？ 因为本次 snapshot 的日志，可能还没有复制到所有 follower，这是一个小优化。 具体到日志重放，如果启动是 leader，会写入一条当前配置的日志，触发 fsm caller 的 onCommitted，然后去重放从 snapshot 的日志到最新的 committed 的日志到状态机。如果是 follower，安装 snapshot 后， leader 会发送该 snapshot 对应的日志之后的日志，走正常的复制流程，因此也会重放到最新的状态机。\n SOFAJRaft 当 Leader 的 Node 执行 apply 后，将 LogEntry 提交给 follower 是通过通知来进行的吗？是不是在 LogManagerImpl 里面的这串代码 A：这段是 wakeup replicators，复制日志到 follower 都是在 Replicator 中实现的。\n2、关于 Seata 的 grouplist 问题：\n 什么时候会用到 file.conf 中的 default.grouplist？\n A：当 registry.type=file 时会用到，其他时候不读。\n default.grouplist 的值列表是否可以配置多个？\n A：可以配置多个，配置多个意味着集群，但当 store.mode=file 时，会报错。原因是在 file 存储模式下未提供本地文件的同步，所以需要使用 store.mode=db，通过 db 来共享 TC 集群间数据\n 是否推荐使用 default.grouplist？\n A：不推荐，如问题1，当 registry.type=file 时会用到，也就是说这里用的不是真正的注册中心，不具体服务的健康检查机制当tc不可用时无法自动剔除列表，推荐使用 nacos 、eureka、redis、zk、consul、etcd3、sofa。registry.type=file 或 config.type=file 设计的初衷是让用户再不依赖第三方注册中心或配置中心的前提下，通过直连的方式，快速验证 Seata 服务。\n3、关于 Seata 事务分组：\n 什么是事务分组？\n A：事务分组是 Seata 的资源逻辑，类似于服务实例。在 file.conf 中的 my_test_tx_group 就是一个事务分组。\n 通过事务分组如何找到后端集群？\n A：首先程序中配置了事务分组（GlobalTransactionScanner 构造方法的 txServiceGroup 参数），程序会通过用户配置的配置中心去寻找 service.vgroup_mapping. 事务分组配置项，取得配置项的值就是 TC 集群的名称。拿到集群名称程序通过一定的前后缀+集群名称去构造服务名，各配置中心的服务名实现不同。拿到服务名去相应的注册中心去拉取相应服务名的服务列表，获得后端真实的 TC 服务列表。\n 为什么这么设计，不直接取服务名？\n A：这里多了一层获取事务分组到映射集群的配置。这样设计后，事务分组可以作为资源的逻辑隔离单位，当发生故障时可以快速 failover。\nSOFA 项目进展 本周发布详情如下：\n1、发布 Seata v0.8.0 版本，主要变更如下：\n 支持 oracle 数据库的 AT 模式 支持 oracle 数据库的批量操作 支持 undo_log 表名可配置 修复 xid 在 db 模式可重复的问题 优化数据镜像比对日志 详细参考发布报告：https://github.com/seata/seata/releases/tag/v0.8.0\n2、发布 SOFAARK v1.0.0 版本，主要变更如下：\n 支持插件批量导出资源和 ark-biz 禁止批量导入资源 支持指定版本调用，解决对于非激活状态的ark-biz服务访问问题（主要用于灰度验证，测试等） 支持打包时跳过打ark-executable 包的过程（优化） 支持从目录运行启动 ArkClient api 支持指定 biz 的 arguments 参数 使用 netty 代替 java NIO 实现 telnet server 支持 SpringBoot testNG 优化示例工程 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.0.0 SOFA 活动推荐 SOFA:Channel/线上直播第 8 期报名中~ 8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。\n 本期主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft 直播时间：8 月 29 日下周四晚 7点 你将收获： 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 报名方式：点击“这里” 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可） ","date":1566543600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190823/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"067db1c93be21087cc809be0294c1b32","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190823/","publishdate":"2019-08-23T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190823/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/19 - 8/23】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190823/","wordcount":1855},{"author":"苟利","categories":"SOFAMeetup","content":" 作者：苟利（陈自欣），蚂蚁金服中间件产品专家， 负责蚂蚁金服分布式链路跟踪系统的产品化工作，在日志分析、监控领域有多年工作经验。\n本文根据 8 月 11 日 SOFA Meetup#3 广州站 《蚂蚁金服在云原生架构下的可观察性的探索和实践》主题分享整理。现场回顾视频以及 PPT 查看地址见文末链接。\n前言 随着应用架构往云原生的方向发展，传统监控技术已经不能满足云原生时代运维的需求，因此，可观察性的理念被引入了 IT 领域。\n下面我将会就可观察性在云原生的起源，可观察性发展动力， 可观察性与监控的关系，可观察性的三大支柱，社区发展方向及产品现状，以及蚂蚁金服对相关问题的理解及实践进行探讨。\n才疏学浅，欢迎拍砖。\n为什么云原生时代需要可观察性 可观察性的由来 在云原生语境下的可观察性这个词，最早出现于2017年7月， Cindy Sridharan 在 Medium 写的一篇博客， \u0026amp;ldquo;Monitoring and Observability\u0026amp;ldquo;，谈到了可观察性与云原生监控的关系。\n而在2017年10月， 来自 Pivotal 公司的 Matt Stine，在接受 InfoQ 采访的时候，对云原生的定义进行了调整， 将Cloud Native Architectures 定义为具有以下六个特质：\n 模块化 （Modularity） (通过微服务) 可观察性 （Observability） 可部署性 （Deployability） 可测试性 （Testability） 可处理性 （Disposability） 可替换性 （Replaceability） 可见，在2017年下半年， 可观察性成为了一个 buzzword（时髦词） ，正式出现在了云计算领域。\n可观察性的定义 虽然“可观察性”这个词在 IT 行业是一个新的术语，但它其实是在上世纪60年代，由匈牙利裔工程师鲁道夫·卡尔曼提出的概念。\n术语“可观察性”，源于控制论，是指系统可以由其外部输出推断其内部状态的程度。\n这个外部输出， 在云原生的语境下，即 Telemetry ，遥测，通常由服务（services）产生，划分为三个维度或者说支柱， Tracing（跟踪），Metrics（指标） , Logging（日志）。\n为什么云原生需要可观察性 近年可以看到，云计算对基础架构改变甚为巨大，无论是互联网行业，还是传统行业，云化在提升资源利用率，提高业务敏捷性的价值已经成为了公式。而在应用层面，由于业务特性的原因，互联网公司大部分已经完成云化，应用架构也不同程度上，完成了从单体应用向微服务应用演进。 在转型后，整体系统复杂性大大增加，倒逼相应的工具及方法论进行升级改造， 去 hold 住这么复杂的局面。\n上图为 Uber 展示的总体调用链图。考虑到业务多样性及复杂度，在蚂蚁金服内部，相关调用关系只会更为复杂，用人类的智力，已经没有办法去理解如此复杂的调用关系。而上图只是展示了可观察性的链路调用， 如果再加上指标及日志， 不对工具及方法论进行革新， 是难以实现对复杂微服务架构的管控的。\n微服务只是云原生的模块化特性的体现， 再考虑到近年被广泛应用容器，Kubernetes , 以及大家关注度极高的 Service Mesh , Istio， 每一个新的技术的出现，在带来了更优雅的架构、更灵活的调度、更完善的治理的同时，也带来更多新的复杂性。\n因此，可观察性对于云原生的应用架构，是必不可少的特性。\n可观察性和传统监控的区别 说半天，不少同学就会说，这个可观察性与我们谈的最多的监控有什么区别。 虽然有不少的人认为， 这词就是个buzzword，就是赶时髦的，没有太大的意义， 但是我结合网上的讨论， 个人认为可观察性与监控， 含义上虽然接近，但是也有一些理念上的差别，使得讨论可观察性这个词，是有具有现实意义，并能真正产生相应的价值。\n 监控更多关注的是基础设施，更多与运维工程师相关，更强调是从外部通过各种技术手段去看内部，打开黑盒系统。 可观察性更多的是描述应用，在我们谈论具体某应用，或者是某些应用是否具备客观性的时候，通常与开发人员相关，因为在常见的可观察性的实践之中，开发人员需要在应用的开发过程中嵌入例如 statd 或者是 opentracing，或者是 opencensus 等所提供的库，对相关的 telemetry 进行输出，或者是俗话说的埋点。通过埋点，将服务内部的状态白盒化，使得其在运维阶段具备可观察性。某种程度上可以说，可观察性遵循了 DevOps 及 SRE 的理念，即研发运维一体化，从开发侧就考虑系统的可运维性。  这里值得补充说明的是，目前市面上，有商用或者开源APM 方案，通过入侵 JVM 或者其他技术手段，对应用进行自动埋点的，输出 trace 及 metrics 信息。 这同样也是一种可观察性的实现方式，这样做的最大的好处是，不需要对现有的应用进行改造，但是相应的 agent 对应用进行实时的监控， 必然会或多或少的增加资源的占用，例如每实例额外 30+MB 内存，5~10% 的 CPU 占用，在大规模的运行环境之中， 会有不少的成本增加。\n可观察性的三大支柱及社区进展 可观察性的三大支柱 可观察性的三大支柱及其之间的关系， Peter Bourgon 在2017年2月撰写了一篇简明扼要的文章， 叫 \u0026amp;ldquo;Metrics, tracing, and logging\u0026amp;rdquo; ， 有兴趣的可以去看一下， 以下仅为简单的提及。\n指标数据（Metrics Data） 描述具体某个对象某个时间点的值。在 Prometheus 中， 指标有四种类型，分别 Counter（计数器）、Gauge（瞬时值）、Histogram（直方图）和 Summary （概要）， 通过这四种类型，可以实现指标的高效传输和存储。\n日志数据 ( Logging Data） 描述某个对象的是离散的事情，例如有个应用出错，抛出了 NullPointerExcepction，或者是完成了一笔转账，个人认为 Logging Data 大约等同于 Event Data，所以告警信息在我认为，也是一种 Logging Data。 但是也有技术团队认为，告警应该算是可观察性的其中一个支柱。 跟踪数据（Tracing Data） Tracing Data 这词貌似现在还没有一个权威的翻译范式，有人翻译成跟踪数据，有人翻译成调用数据，我尽量用Tracing 这个词。 Tracing 的特点就是在单次请求的范围内处理信息，任何的数据、元数据信息都被绑定到系统中的单个事务上。 一个Trace 有一个唯一的Trace ID ，并由多个Span 组成。\n社区方案进展 由于可观察性在云原生中，是一个非常重要的特性， 因此，在开源世界中，先后出现了两个定位都比较类似的项目，分别是源自 Google 的 OpenCensus （定位上报 Tracing + metris） 和由 CNCF 孵化的 OpenTracing（定位上报 Tracing）。 两者都定位于提供厂商中立的技术规范，及实现该规范各种编程语言遥测库，使得用户在使用了相关的库以后，可 …","date":1566381600,"description":"本文根据 8 月 11 日 SOFA Meetup#3 广州站 《蚂蚁金服在云原生架构下的可观察性的探索和实践》主题分享整理，文中包含本次分享视频回顾以及 PPT 查看地址。","dir":"blog/sofa-meetup-3-cloud-original-retrospect/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"85eba21fd9adf73841d7b7ee103723ae","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","publishdate":"2019-08-21T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","summary":"作者：苟利（陈自欣），蚂蚁金服中间件产品专家， 负责蚂蚁金服分布式链路跟踪系统的产品化工作，在日志分析、监控领域有多年工作经验。 本文根据 8 月 11","tags":["SOFAMeetup"],"title":"蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","wordcount":4758},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n本周推荐阅读 分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾 中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说 溢米教育推荐平台的效率与稳定性建设 | SOFAStack 用户说 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.2.6, 主要变更如下： - i. 修复 ReadIndex 并发情况下可能出现的读超时 - ii. 保存 raft meta 失败后终止状态机 - iii. 增加 LogEntry checksum validation - iv. 优化 log replication 线程模型减少锁竞争 - v. 优化 RheaKV multi group snapshot - vi. 致谢（排名不分先后）@SteNicholas @zongtanghu\n详细参考发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.2.6\nSOFA 活动推荐  SOFA:Channel/线上直播第 8 期《从一个例子开始体验 SOFAJRaft》报名中~\n8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。 在本次直播中，我们将重点放在如何去使用这个工具上，用示例来说明如何使用 SOFAJRaft 实现自己的分布式应用。在此过程中，我们会对涉及到的一些 SOFAJRaft 经典概念进行讲解。\n| 点击“这里”即可报名\n| 本期将带来：\n 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可）\n","date":1565942400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190816/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"277754f72430d4473dc3920edbaf2ddb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190816/","publishdate":"2019-08-16T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190816/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/12 - 8/16】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190816/","wordcount":724},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft\n 活动时间：8 月 29 日周四晚 7 点\n 活动形式：线上直播\n 视频回顾：https://tech.antfin.com/community/live/821\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#8：从一个例子开始体验 SOFAJRaft SOFAJRaft 是 Raft 算法的 Java 实现，其本质是一个工具项目。在本次直播中，我们将重点放在如何去使用这个工具上，用示例来说明如何使用 SOFAJRaft 实现自己的分布式应用。在此过程中，我们会对涉及到的一些 SOFAJRaft 经典概念进行讲解。\n为了更好地直播体验，可以在直播前，预习 SOFAJRaft 相关源码解析文章，文章集合：https://www.sofastack.tech/tags/sofajraft/\n8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/737\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 SOFAChannel#8：从一个例子开始体验 SOFAJRaft 力鲲 SOFAJRaft 开源负责人\n本期分享大纲： 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 嘉宾 SOFAGirl 主持人 力鲲 SOFAJRaft 开源负责人 ","date":1565842200,"description":"8 月 29 日周四晚 7 点，线上直播第 8 期。","dir":"activities/sofa-channel-8/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"92590333a35992bc201c798645cbf7ea","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-8/","publishdate":"2019-08-15T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-8/","summary":"概要 活动主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft 活动时间：8 月 29 日周四晚 7 点 活动形式：线上直播 视频回顾：https://tec","tags":["SOFAChannel","SOFAJRaft"],"title":"SOFAChannel#8：从一个例子开始体验 SOFAJRaft","type":"activities","url":"/sofastack.tech/activities/sofa-channel-8/","wordcount":561},{"author":"屹远","categories":"Seata","content":" 作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。 本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，着重分享分布式事务产生的背景、理论基础，以及 Seata 分布式事务的原理以及三种模式（AT、TCC、Saga）的分布式事务实现。\n本次分享的视频回顾以及 PPT 查看地址：https://tech.antfin.com/community/activities/779/review\n一、分布式事务产生的背景 1.1 分布式架构演进之 - 数据库的水平拆分 蚂蚁金服的业务数据库起初是单库单表，但随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。所以我们对数据库进行了水平拆分，将原单库单表拆分成数据库分片。\n如下图所示，分库分表之后，原来在一个数据库上就能完成的写操作，可能就会跨多个数据库，这就产生了跨数据库事务问题。\n1.2 分布式架构演进之 - 业务服务化拆分 在业务发展初期，“一块大饼”的单业务系统架构，能满足基本的业务需求。但是随着业务的快速发展，系统的访问量和业务复杂程度都在快速增长，单系统架构逐渐成为业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。\n如下图所示，蚂蚁金服按照面向服务架构（SOA）的设计原则，将单业务系统拆分成多个业务系统，降低了各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。\n业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，如何保证多个服务间的数据一致性成为一个难题。\n二、分布式事务理论基础 2.1 两阶段提交协议 两阶段提交协议：事务管理器分两个阶段来协调资源管理器，第一阶段准备资源，也就是预留事务所需的资源，如果每个资源管理器都资源预留成功，则进行第二阶段资源提交，否则协调资源管理器回滚资源。\n2.2 TCC TCC（Try-Confirm-Cancel） 实际上是服务化的两阶段提交协议，业务开发者需要实现这三个服务接口，第一阶段服务由业务代码编排来调用 Try 接口进行资源预留，所有参与者的 Try 接口都成功了，事务管理器会提交事务，并调用每个参与者的 Confirm 接口真正提交业务操作，否则调用每个参与者的 Cancel 接口回滚事务。\n2.3 Saga Saga 是一种补偿协议，在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。\n分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。\nSaga 理论出自 Hector \u0026amp;amp; Kenneth 1987发表的论文 Sagas。\nSaga 正向服务与补偿服务也需要业务开发者实现。\n三、Seata 及其三种模式详解 3.1 分布式事务 Seata 介绍 Seata（Simple Extensible Autonomous Transaction Architecture，一站式分布式事务解决方案）是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。Seata 开源半年左右，目前已经有超过 1.1 万 star，社区非常活跃。我们热忱欢迎大家参与到 Seata 社区建设中，一同将 Seata 打造成开源分布式事务标杆产品。\nSeata：https://github.com/seata/seata\n3.2 分布式事务 Seata 产品模块 如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。\n在 Seata 中，分布式事务的执行流程：\n TM 开启分布式事务（TM 向 TC 注册全局事务记录）； 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）； TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）； TC 汇总事务信息，决定分布式事务是提交还是回滚； TC 通知所有 RM 提交/回滚 资源，事务二阶段结束； 3.3 分布式事务 Seata 解决方案 Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。\n3.3.1 AT 模式 今年 1 月份，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。\nAT 模式如何做到对业务的无侵入 ： 一阶段： 在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。\n 二阶段提交： 二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。\n 二阶段回滚： 二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。\nAT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。\n3.3.2 TCC 模式 2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。\nTCC 三个方法描述：\n Try：资源的检测和预留； Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功； Cancel：预留资源释放； 蚂蚁金服在 TCC 的实践经验\n1 TCC 设计 - 业务模型分 2 阶段设计：\n用户接入 TCC ，最重要的是考虑如何将自己的业务模型拆成两阶段来实现。\n以“扣钱”场景为例，在接入 TCC 前，对 A 账户的扣钱，只需一条更新账户余额的 SQL 便能完成；但是在接入 TCC 之后，用户就需要考虑如何将原来一步就能完 …","date":1565776800,"description":"本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，文中包含本次分享视频回顾以及 PPT 查看地址。","dir":"blog/sofa-meetup-3-seata-retrospect/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"841ac02b2ce20e10748bf97db9d644ec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","publishdate":"2019-08-14T18:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","summary":"作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。 本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，着重分享分布式事务","tags":["Seata","SOFAMeetup"],"title":"分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","wordcount":5793},{"author":"胡宗棠","categories":"SOFAJRaft","content":" 文章摘要：BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云服务中的最佳应用实践。\n前言： 高可用的定义，指的是“一个系统经过特有的设计与改造，减少因不确定故障停服的时间，从而对业务使用方来说可以保证其服务的高度可用性”。在生产环境中，往往会存在很多不可预知的故障因素，比如虚拟机宕机、磁盘损坏和网络故障等，因此系统自身的高可用是任何工业级产品所需重点考虑的因素。\n对于消息队列服务来说，考虑到故障切换和业务感知等问题，传统的高可用方式（冷备或者热备）一般都不太适用。在经过多种技术方案对比后，我们发现采用基于 Raft 共识算法的多副本设计方案可以满足我们产品的要求，因此在鉴权认证组件和API计量服务组件中，我们集成了蚂蚁金服开源的 SOFAJRaft 库，实现这两个组件应对单点故障的高可用。\nGitHub 地址：https://github.com/sofastack/sofa-jraft\n一、背景知识：Raft 共识性算法是什么？ Raft 是一种分布式系统中易于理解的共识算法，该协议本质上是 Paxos 算法的精简版，而不同的是依靠 Raft 模块化的拆分以及更加简化的设计，其实现起来更加容易和方便。[1]\n模块化的拆分主要体现在 Raft 把一致性协议划分为如下几部分：\n Leader 选举； Membership 变更； 日志复制； Snapshot。 而更加简化的设计则体现在：Raft 不允许类似 Paxos 中的乱序提交、简化系统中的角色状态（算法定义 Leader、Follower 和 Candidate 三种角色）、限制仅 Leader 可写入、采用随机超时触发 Leader Election 机制来避免“瓜分选票”等等。[2]\n1.1 Raft 算法的整体结构概览 从上面的 Raft 算法整体结构图中可以看出，整个分布式系统中同一时刻有且仅有一个 Leader 角色的节点（如图最右边的服务器），只有 Leader 节点可以接受 Client 发送过来的请求。Leader 节点负责主动与所有 Follower 节点进行网络通信（如图左边两个服务器），负责将本地的日志发送给所有 Follower 节点，并收集分布式系统中多数派的 Follower 节点的响应。此外，Leader 节点，还需向所有 Follower 节点主动发送心跳维持领导地位（即：保持存在感）。\n所以，只要各个节点上的日志保持内容和顺序是一致的，那么节点上的状态机就能以相同的顺序执行相同的命令，这样它们执行的结果也都是一样的。\n1.2 Raft 算法的三种角色及转换 Follower：完全被动，不能发送任何请求，只接受并响应来自 Leader 和 Candidate 的 Message，每个节点启动后的初始状态一般都是 Follower； Leader：处理所有来自客户端的请求、复制 Log 到所有 Follower，并且与 Follower 保持心跳请求； Candidate：节点竞选 Leader 时的状态。Follower 节点在参与选举之前，会将自己的状态转换为 Candidate。 1.3 任期与逻辑时钟概念 时间被划分为多个任期 term（如同总统选举一样），term id 按时间轴单调递增； 每一个任期开始后要做的第一件事都是选举 Leader 节点，选举成功之后，Leader 负责在该任期内管理整个分布式集群，“日志复制”、“通过心跳维护自己的角色”； 每个任期至多只有一个 Leader 节点，也可能没有 Leader (由于“分票”导致)。 1.4 Raft 算法的实际应用实现 目前，Raft 算法已经成熟地应用于诸多知名的开源项目中。业界非常著名的 Etcd(Kubernetes 高可用强一致性的服务发现组件)和 TiKV (高性能开源 KV 存储)均是 Raft 算法的实现。\n二、BC-MQ 基于 Raft 的高可用设计 为满足企业上云和构建万物相连的物联网业务需求，中国移动苏州研发中心结合自身在云计算产品和技术的较多积累，研发了大云消息队列中间件产品 BC-MQ。该产品基于 Apache 开源社区的 RocketMQ 内核，同时结合云端 PAAS 产品架构和消息中间件的应用业务需求进行深度优化和定制化的研发，提供了一款可以满足于云端场景的高性能、高可靠、低延迟和高可用的工业级产品。\n本节从解决原有高可用技术方案的问题视角出发，同时结合选型 SOFAJRaft 库的缘由，将详细阐述 BC-MQ 产品中的安全认证和 API 计量采集服务的高可用设计方案（注：这里不会涉及到安全认证和 API 计量采集组件本身的技术方案细节）。\n2.1 GlusterFS+Keepalived 高可用方案与问题 1. GlusterFS+Keepalived 高可用设计方案 在BC-MQ原有的方案中，多组安全认证服务各自独立部署组建集群，各个安全认证服务相互独立，没有主从关联，服务本身无状态，可水平任意扩展。安全认证服务的高可用依赖于RPC通信的客户端保证，其主要通过负载均衡算法从安全认证服务集群选择一个节点发送RPC请求来实现租户级鉴权认证元数据的获取。在生产环境中，如果出现其中一个安全认证节点宕机不可用时，客户端的RPC通信层能够及时感知并从本地的Node列表中剔除不可用节点。\n集群中有状态的租户级安全认证元数据的强一致性由GlusterFS分布式文件存储的同步机制来保证。安全认证服务组建高可用集群的具体设计方案图如下所示：\n而 BC-MQ 中 API 计量采集服务组件的高可用性则是依靠 Keepalived 组件的冷备模式结合 GlusterFS 分布式文件存储的同步机制共同保证，从而在一定程度上解决了 API 计量采集服务的单点不可用问题。API 计量采集服务的具体高可用设计方案图如下所示：\n2. GlusterFS+Keepalived 高可用方案遇到的问题 初步看上面的这种高可用技术方案挺完美的。但是经过验证和仔细推敲后就发现在生产环境中可能会存在如下几个问题：\n 上面所述的高可用设计方案中引入了 GlusterFS 分布式文件存储系统和 Keepalived 组件，这增加了系统整体的运维复杂度，给运维人员带来很多人工介入排查和部署的工作负担；另一方面，GlusterFS 和 Keepalived 本身的可靠性、稳定性和性能指标等问题也需要软件研发人员重点关注，这增加了系统整体设计的复杂度； 在实际的生产环境中，Keepalived 组件采用冷备方式作为高可用方案需要考虑主机故障宕机后切换到备机的时间成本消耗。在这段时间内，API 计量服务是短暂不可用的。因此，Keepalived 组件的主备切换会造成业务感知影响，导致一些业务的风险发生。 2.2 基于 SOFAJRaft 库的高可用设计方案 由于“GlusterFS+Keepalived”的高可用方案存在上一节阐述的两个问题，所以我们考虑是否可以采用其他的高可用方案来解决这两个问题？目标：即使生产环境出现部分节点故障后， …","date":1565694000,"description":"BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云服务中的最佳应用实践。","dir":"blog/sofa-jraft-user-china-mobile/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a7eb984bdb11d8c0b47133af4c16f48f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-user-china-mobile/","publishdate":"2019-08-13T19:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-user-china-mobile/","summary":"文章摘要：BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云","tags":["SOFAJRaft"],"title":"中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-user-china-mobile/","wordcount":6179},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n关于 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 的讨论： @龚小涛 提问： \u0026amp;gt; 对于快照部分讲解是对某一刻时间点的数据做的快照吗，然后此快照最新的记录下 logindex term 等信息？\nA：快照里记录的数据不是日志复制的数据，而是状态机执行的结果，这个快照数据保存的动作是由用户通过实现这个接口来实现的： com.alipay.sofa.jraft.StateMachine#onSnapshotSave 。当然，里面的快照里面还包括了一些 index、term 等元信息。所以如果你理解的数据是由状态机执行的结果，那理解是对的。\n 关于快照的解决方案中是对数据集合的快照，这里可以细说下吗？\n A：快照中保存的是用户自定义的状态机的当前的状态，具体内容需要用户自己去实现，你可以看下这个接口： com.alipay.sofa.jraft.StateMachine#onSnapshotSave，比如 Counter 这个 example 中，保存的就是计数器当前的 value。\nSOFAJRaftLab 系列阅读 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n发布 SOFARegistry 5.2.1, 主要变更如下： i. 安全修改，升级 Jettyserver 版本到 9.4.17.v20190418. ii. jraft bug 修正版本到1.2.5 iii. 修复 dataServer 启动没有 working 时刻一些操作延迟处理问题 iv. data 重连 meta 逻辑 bug 导致所有 data 无法连接 meta 修改 v. data 从 working 状态变回 init 状态 bug 修改 详细发布报告： https://github.com/sofastack/sofa-registry/releases/tag/v5.2.1\nSOFA 活动推荐 SOFA Meetup #3《从开源技术到产品能力》，本周日我们在广州等你~\n本期活动将为大家带来蚂蚁金服在这些方面的探索和实践，解析 SOFARPC、分布式事务 Seata、无线自动化测试框架 SoloPi 等开源项目的内部大规模落地和社区发展，并且通过可观察性的理念，实现对微服务，Service Mesh 以至未来的 Serverless 架构的应用进行监控，帮助大家应对从应用架构过渡到云原生架构的挑战。\n报名方式：点击“这里”了解活动详情。\n","date":1565337600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190809/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"31aa100cb2b1edaacaa1874644af50ff","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190809/","publishdate":"2019-08-09T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190809/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/5 - 8/9】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190809/","wordcount":1018},{"author":"力鲲、徐家锋","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第六篇，本篇作者徐家锋，来自专伟信息，力鲲，来自蚂蚁金服。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：\u0026amp;lt;SOFA:JRaftLab/\u0026amp;gt;，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n本文的目的是要介绍 SOFAJRaft 在日志复制中所采用的 pipeline 机制，但是作者落笔时突然觉得这个题目有些唐突，我们不应该假设读者理所应当的对日志复制这个概念已经了然于胸，所以作为一篇解析，我觉得还是应该先介绍一下 SOFAJRaft 中的日志复制是要解决什么问题。\n概念介绍 SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法，就不可避免的要对需要达成共识的内容在多个服务器节点之间进行传输，在 SOFAJRaft 中我们将这些内容封装成一个个日志块 (LogEntry)，这种服务器节点间的日志传输行为在 SOFAJRaft 中也就有了专门的术语：日志复制。\n为了便于阅读理解，我们用一个象棋的故事来类比日志复制的流程和可能遇到的问题。\n假设我们穿越到古代，要为一场即将举办的象棋比赛设计直播方案。当然所有电子通讯技术此时都已经不可用了，幸好象棋比赛是一种能用精简的文字描述赛况的项目，比如：“炮二平五”, “马８进７”, “车２退３”等，我们将这些描述性文字称为棋谱。这样只要我们在场外同样摆上棋盘 (可能很大，方便围观)，通过棋谱就可以把棋手的对弈过程直播出来。\n图1 - 通过棋谱直播\n所以我们的直播方案就是：赛场内两位棋手正常对弈，设一个专门的记录员来记录棋手走出的每一步，安排一个旗童飞奔于赛场内外，棋手每走一步，旗童就将其以棋谱的方式传递给场外，这样观众就能在场外准实时的观看对弈的过程，获得同观看直播相同的体验。\n图2 - 一个简单的直播方案\n这便是 SOFAJRaft 日志复制的人肉版，接下来我们完善一下这个“直播系统”，让它逐步对齐真实的日志复制。\n改进1. 增加记录员的数量 假设我们的比赛获得了很高的关注度，我们需要在赛场外摆出更多的直播场地以供更多的观众观看。\n这样我们就要安排更多的旗童来传递棋谱，场外的每一台直播都需要一个旗童来负责，这些旗童不停的在赛场内外奔跑传递棋谱信息。有的直播平台离赛场远一些，旗童要跑很久才行，相应的直播延迟就会大一些，而有些直播平台离得很近，对应的旗童就能很快的将对弈情况同步到直播。\n随着直播场地的增加，负责记录棋局的记录员的压力就会增加，因为他要针对不同的旗童每次提供不同的棋谱内容，有的慢有的快。如果记录员一旦记混了或者眼花了，就会出现严重的直播事故(观众看到的不再是棋手真正的棋局)。\n图4 - 压力很大的记录员\n为此我们要作出一些优化，为每个场外的直播平台安排一个专门的记录员，这样 “赛局-记录员-旗童-直播局” 就构成了单线模式，专人专职高效可靠。\n图5 - “赛局-记录员-旗童-直播棋局”\n改进2. 增加旗童每次传递的信息量 起初我们要求棋手每走一步，旗童就向外传递一次棋谱。可是随着比赛进行，其弊端也逐渐显现，一方面记录员记录了很多棋局信息没有传递出去，以至于不得不请求棋手停下来等待 (不可思议)；另一方面，场外的观众对于这种“卡帧”的直播模式也很不满意。\n所以我们做出改进，要求旗童每次多记几步棋，这样记录员不会积攒太多的待直播信息，观众也能一次看到好几步，而这对于聪明的旗童来说并不是什么难事，如此改进达到了共赢的局面。\n图6 - 旗童批量携带信息\n改进3. 增加快照模式 棋局愈发精彩，应棋迷的强烈要求，我们临时增加了几个直播场地，这时棋手已经走了很多步了，按照我们的常规手段，负责新直播的记录员和旗童需要把过去的每一步都在直播棋盘上还原一遍(回放的过程)，与此同时棋手还在不断下出新的内容。\n从直觉上来说这也是一种很不聪明的方式，所以这时我们采用快照模式，不再要求旗童传递过去的每一步棋谱，而是把当前的棋局图直接描下来，旗童将图带出去后，按照图谱直接摆子。这样新直播平台就能快速追上棋局进度，让观众欣赏到赛场同步的棋局对弈了。\n图7 - 采用快照模式\n改进4. 每一个直播平台用多个旗童传递信息 虽然我们之前已经在改进 2 中增加了旗童每次携带的信息量，但是在一些情况下(棋手下快棋、直播平台很远等)，记录员依然无法将信息及时同步给场外。这时我们需要增加多个旗童，各旗童有次序的将信息携带到场外，这样记录员就可以更快速的把信息同步给场外直播平台。\n图8 - 利用多个旗童传递信息，实现 pipeline 效果\n现在这个人肉的直播平台在我们的逐步改进下已经具备了 SOFAJRaft 日志复制的下面几个主要特点：\n特点1: 被复制的日志是有序且连续的 如果棋谱传递的顺序不一样，最后下出的棋局可能也是完全不同的。而 SOFAJRaft 在日志复制时，其日志传输的顺序也要保证严格的顺序，所有日志既不能乱序也不能有空洞 (也就是说不能被漏掉)。\n图9 - 日志保持严格有序且连续\n特点2: 复制日志是并发的 SOFAJRaft 中 Leader 节点会同时向多个 Follower 节点复制日志，在 Leader 中为每一个 Follower 分配一个 Replicator，专用来处理复制日志任务。在棋局中我们也针对每个直播平台安排一个记录员，用来将对弈棋谱同步给对应的直播平台。\n图10 - 并发复制日志\n特点3: 复制日志是批量的 SOFAJRaft 中 Leader 节点会将日志成批的复制给 Follower，就像旗童会每次携带多步棋信息到场外。\n图11 - 日志被批量复制\n特点4: 日志复制中的快照 在改进 3 中，我们让新加入的直播平台直接复制当前的棋局，而不再回放过去的每一步棋谱，这就是 SOFAJRaft 中的快照 (Snapshot) 机制。用 Snapshot 能够让 Follower 快速跟上 Leader 的日志进度，不再回放很早以前的日志信息，即缓解了网络的吞吐量，又提升了日志同步的效率。\n特点5: 复制日志的 pipeline 机制 在改进 4 中，我们让多个旗童参与信息传递，这样记录员和直播平台间就可以以“流式”的方式传递信息，这样既能保证信息传递有序也能保证信息传递持续。\n在 SOFAJRaft 中我们也有类似的机制来保证日志复制流式的进行，这种机制就是 pipeline。Pipeline 使得 Leader 和 Follower 双方不再需要严格遵从 “Request - Response - Request” 的交互模式，Leader …","date":1565080200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第六篇，本篇作者徐家锋、力鲲。","dir":"blog/sofa-jraft-pipeline-principle/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c88030d7b6620240943e8326565b0ec2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-pipeline-principle/","publishdate":"2019-08-06T16:30:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-jraft-pipeline-principle/","summary":"SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-pipeline-principle/","wordcount":3903},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@屈冉 提问：\n SOFAJRaft 目前支持 Multi-Raft 嘛?\n A：支持的，可以参考 rheakv 实现，就是用的 multi raft group。\n 好的，另外想问一下，SOFAJRaft 有没有和 Braft 的性能比较数据，或者同类实现的？\n A：这里有一份 Benchmark 数据可以参考一下，我们暂时没有计划和同类实现对比性能：\nhttps://github.com/sofastack/sofa-jraft/wiki/Benchmark-%E6%95%B0%E6%8D%AE\nSOFA 开源系列 SoloPi：支付宝 Android 专项测试工具 | 开源 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源 蚂蚁金服分布式事务开源以及实践 | SOFA 开源 蚂蚁金服开源自动化测试框架 SOFAACTS 蚂蚁金服开源 SOFAJRaft：生产级 Java Raft 算法库 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFATracer 2.4.1\u0026amp;frasl;3.0.6, 主要变更如下：\ni. 升级 Dubbo 版本至 2.7.3.\nii. 修复 Dubbo 插件中相关埋点参数获取问题\niii. 修复 Datasource 埋点中的若干问题\niv. Cheery pick 代码优化至 3.x 分支\n详细发布报告：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v2.4.1\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.0.6\n2、发布 SOFA MOSN v0.6.0，主要变更如下：\ni. Listener 支持配置空闲连接超时关闭\nii. 日志新增 Alertf 接口\niii. 支持 SDS 方式获取证书\niv. Metrics统计与输出优化\nv. IO 协程优化\nvi. 后端模块实现重构，提升了动态更新性能，降低了内存的使用\nvii. racer 模块实现重构，支持更完善的扩展机制\n详细发布报告：\nhttps://github.com/sofastack/sofa-mosn/releases/tag/0.6.0\nSOFA 活动推荐 SOFA Meetup #3 广州站《从开源技术到产品能力》报名进行中~\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 SoloPi 的首秀分享~\n8 月 11 日，我们广州见~\n报名方式：点击“这里”即可报名。\n","date":1564732800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190802/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4edd066a5855f1a118fd562cfc299571","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190802/","publishdate":"2019-08-02T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190802/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【7/29- 8/2】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190802/","wordcount":818},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n本周推荐阅读 大公司开源怎么做？SOFAStack 给出了一个很好的例子 对话鲁直：蚂蚁金服中间件的开源头羊 | 穿山甲专访 SOFAJRaftLab 系列阅读 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 活动推荐  SOFA Meetup #3 广州站《从开源技术到产品能力》报名开始啦~\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 Soloπ 的首秀分享~\n8 月 11 日，我们广州见~\n报名方式：点击“这里”了解活动详情。\n","date":1564124400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190726/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"70e3dace7979772fdf90f9f5a47d2e13","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190726/","publishdate":"2019-07-26T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190726/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"（含活动报名）SOFA Weekly | 每周精选【7/22 - 7/26】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190726/","wordcount":485},{"author":"潘潘","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#3 广州站-从开源技术到产品能力 活动时间：8 月 11 日周日下午 13 点 活动地点：广州市广电平云 B 塔 15F 活动形式：线下活动 报名方式：https://tech.antfin.com/community/activities/779 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n欢迎 Star 我：https://github.com/sofastack\nSOFA Meetup#3 广州站-从开源技术到产品能力 适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 Soloπ 的首秀分享~\n随着应用架构往云原生的方向发展，传统监控手段已经不能满足云原生时代运维的需求，因此，可观察性的理念被引入了 IT 领域。如何通过可观察性的理念，对微服务，Service Mesh 以至未来的 Serverless 架构的应用进行监控， 将是应用架构往云原生迁移过程中的一个重要命题。\n加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n点击即可报名 https://tech.antfin.com/community/activities/779\n议程 时间 环节 分享大纲 分享嘉宾 13:00-13:30 签到 13:30-14:15 《RPC 服务框架 SOFARPC 在蚂蚁金服的发展与进化》 - SOFARPC 在蚂蚁金服的应用现状\n- 协议和通信层的变化与设计\n- 跨机房与弹性的挑战\n- RPC 框架发展中的经验与教训\n- 拥抱开源，SOFARPC 的未来\n 碧远@SOFARPC 开源负责人 14:15-15:00 《蚂蚁金服在云原生架构下的可观察性的探索和实践》 \n- 为什么云原生时代需要可观察性\n- 可观察性的三大支柱\n- 现在社区方案的缺陷\n- 蚂蚁金服对云原生的可观察性的理解及实践\n 苟利@蚂蚁金服中间件团队产品专家 15:00-15:10 茶歇 15:10-15:55 《分布式事务 Seata 三种模式详解》 \n- 分布式事务产生的背景\n- 分布式事务理论基础\n- 蚂蚁金服分布式事务实践\n- 开源分布式事务 Seata 简介(AT，TCC，SAGA)\n 屹远@Seata 核心贡献者 15:55-16:40 《无线自动化测试框架 Soloπ 的跨平台实践》 \n- 移动端自动化测试转向轻量化\n- “Android+iOS”双端核心功能介绍\n- “Android+iOS”双端功能打通介绍\n- 结合云测平台、用例管理、IDE 的自动化测试解决方案\n 茅舍@Soloπ 核心作者\n不溯@Soloπ 核心作者 ","date":1564038000,"description":"SOFA Meetup#3 广州站-从开源技术到产品能力，8 月 11 日周日下午 13 点，广州市广电平云 B 塔 15F 等你。","dir":"activities/sofa-meetup-3/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0e50b11d1a8e52f8cefbac0bb4826ffe","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-3/","publishdate":"2019-07-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofa-meetup-3/","summary":"概要 活动主题：SOFA Meetup#3 广州站-从开源技术到产品能力 活动时间：8 月 11 日周日下午 13 点 活动地点：广州市广电平云 B 塔 15F 活动形式：线下活动 报名方式：","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#3 广州站-从开源技术到产品能力","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-3/","wordcount":1067},{"author":"袖扣","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第五篇，本篇作者袖扣，来自蚂蚁金服。\n《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：\u0026amp;lt;SOFA:JRaftLab/\u0026amp;gt;，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/alipay/sofa-jraft\n前言 RheaKV 是首个以 JRaft 为基础实现的一个原生支持分布式的嵌入式键值（key、value）数据库，现在本文将从 RheaKV 是如何利用 MULTI-RAFT-GROUP 的方式实现 RheaKV 的高性能及容量的可扩展性的，从而进行全面的源码、实例剖析。\nMULTI-RAFT-GROUP 通过对 Raft 协议的描述我们知道：用户在对一组 Raft 系统进行更新操作时必须先经过 Leader，再由 Leader 同步给大多数 Follower。而在实际运用中，一组 Raft 的 Leader 往往存在单点的流量瓶颈，流量高便无法承载，同时每个节点都是全量数据，所以会受到节点的存储限制而导致容量瓶颈，无法扩展。\nMULTI-RAFT-GROUP 正是通过把整个数据从横向做切分，分为多个 Region 来解决磁盘瓶颈，然后每个 Region 都对应有独立的 Leader 和一个或多个 Follower 的 Raft 组进行横向扩展，此时系统便有多个写入的节点，从而分担写入压力，图如下：\n此时磁盘及 I/O 瓶颈解决了，那多个 Raft Group 是如何协作的呢，我们接着往下看。\n选举及复制 RheaKV 主要由 3 个角色组成：PlacementDriver（以下成为 PD） 、Store、Region。由于 RheaKV 支持多组 Raft，所以比单组场景多出一个 PD 角色，用来调度以及收集每个 Store 及 Region 的基础信息。\nPlacementDriver PD 负责整个集群的管理调度、Region ID 生成等。此组件非必须的，如果不使用 PD，设置 PlacementDriverOptions 的 fake 属性为 true 即可。PD 一般通过 Region 的心跳返回信息进行对 Region 调度，Region 处理完后，PD 则会在下一个心跳返回中收到 Region 的变更信息来更新路由及状态表。\nStore 通常一个 Node 负责一个 Store，Store 可以被看作是 Region 的容器，里面存储着多个分片数据。Store 会向 PD 主动上报 StoreHeartbeatRequest 心跳，心跳交由 PD 的 handleStoreHeartbeat 处理，里面包含该 Store 的基本信息，比如，包含多少 Region，有哪些 Region 的 Leader 在该 Store 等。\nRegion Region 是数据存储、搬迁的最小单元，对应的是 Store 里某个实际的数据区间。每个 Region 会有多个副本，每个副本存储在不同的 Store，一起组成一个Raft Group。Region 中的 Leader 会向 PD 主动上报 RegionHeartbeatRequest 心跳，交由 PD 的 handleRegionHeartbeat 处理，而 PD 是通过 Region的Epoch 感知 Region 是否有变化。\nRegionRouteTable 路由表组件 MULTI-RAFT-GROUP 的多 Region 是通过 RegionRouteTable 路由表组件进行管理的，可通过 addOrUpdateRegion、removeRegion 进行添加、更新、移除 Region，也包括 Region 的拆分。目前暂时还未实现 Region 的聚合，后面会考虑实现。\n分区逻辑与算法 Shard “让每组 Raft 负责一部分数据。”\n数据分区或者分片算法通常就是 Range 和 Hash，RheaKV 是通过 Range 进行数据分片的，分成一个个 Raft Group，也称为 Region。这里为何要设计成 Range 呢？原因是 Range 切分是按照对 Key 进行字节排序后再做每段每段切分，像类似 scan 等操作对相近 key 的查询会尽可能集中在某个 Region，这个是 Hash 无法支持的，就算遇到单个 Region 的拆分也会更好处理一些，只用修改部分元数据，不会涉及到大范围的数据挪动。\n当然 Range 也会有一个问题那就是，可能会存在某个 Region 被频繁操作成为热点 Region。不过也有一些优化方案，比如 PD 调度热点 Region 到更空闲的机器上，或者提供 Follower 分担读的压力等。\nRegion 和 RegionEpoch 结构如下：\nclass Region { long id; // region id // Region key range [startKey, endKey) byte[] startKey; // inclusive byte[] endKey; // exclusive RegionEpoch regionEpoch; // region term List\u0026amp;lt;Peer\u0026amp;gt; peers; // all peers in the region } class RegionEpoch { // Conf change version, auto increment when add or remove peer long confVer; // Region version, auto increment when split or merge long version; } class Peer { long id; long storeId; Endpoint endpoint; } Region.id：为 Region 的唯一标识，通过 PD 全局唯一分配。\nRegion.startKey、Region.endKey：这个表示的是 Region 的 key 的区间范围 [startKey, endKey)，特别值得注意的是针对最开始 Region 的 startKey，和最后 Region 的 endKey 都为空。\nRegion.regionEpoch：当 Region 添加和删除 Peer，或者 split 等，此时 regionEpoch 就会发生变化，其中 confVer 会在配置修改后递增，version 则是每次有 split 、merge（还未实现）等操作时递增。 …","date":1563955200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第五篇，本篇作者袖扣，来自蚂蚁金服。","dir":"blog/sofa-jraft-rheaKV-multi-raft-group/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fbebe45fe1ffaa4e8f134c2531cde55c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","publishdate":"2019-07-24T16:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","wordcount":4503},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n社区 Big News NO.1 社区新认证一位 Committer\n@SteNicholas 成为 SOFAJRaft Committer。\n主要贡献\n一、贡献了 SOFAJRaft 源码剖析系列一共三篇文章\n 蚂蚁金服生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 二、贡献了 4 个 feature PR\n Multi-raft-group 的手动集群 Leader 平衡实现 实现了 RheaKV 的 CompareAndPut API 实现了 RheaKV 的 putIfAbsent batch 优化 实现了 RheaKV 的 batch delete API 目前，社区已经认证超过四十位 Committer。 感谢对 SOFAStack 的支持和帮助~\n也欢迎你加入 SOFAStack community，指南：\nhttps://github.com/sofastack/community\nSOFARegistryLab 系列阅读 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼 SOFAChannel 回顾集合 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下\nSOFAActs 1.0.1 版本发布，主要变更如下：\n 插件兼容性问题修复 详细参考 发布报告\n","date":1563519600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190719/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"03bd5ad0ca023620792ed7ee60d4c448","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190719/","publishdate":"2019-07-19T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190719/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【7/15 - 7/19】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190719/","wordcount":776},{"author":"枫晟","categories":"CafeDeployment","content":" 本文简单介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。\n相关直播视频以及 PPT 查看地址\n背景介绍 Kubernetes 原生社区 Deployment 和 StatefulSet 解决了“服务节点版本一致性”的问题，并且通过 Rolling Update 实现了滚动升级，提供了基本的回滚策略。对于高可用建设要求不高的“年轻”业务，是一个不错的选择。\n但是，在金融场景下，要解决的场景复杂得多。因此我们在金融分布式架构-云应用引擎（SOFAStack-CAFE，参见《金融级云原生探索实践系列——开篇》）中提出了 CafeDeployment 的云原生模型，致力于解决以下问题：\n1. IP 不可变\n对于很多运维体系建设较为早期的用户，使用的服务框架、监控、安全策略，大量依赖 IP 作为唯一标识而被广泛使用。迁移到 Kubernetes 最大的改变就是 IP 会飘，而这对于他们来说，无异于运维、服务框架的推倒重来。\n2. 金融体系下的高可用\nDeployment/StatefulSet 无法根据特定属性进行差异化部署。而在以同城双活为建设基础的金融领域，为了强管控 Pod 的部署结构（即保证每个机房/部署单元都有副本运行），若通过原生组件进行部署，我们不得不维护多个几乎一模一样的 Deployment/StatefulSet，来保证 Pod 一定会飘到指定机房/部署单元的 node 上。在规模上到一定程度后，这无疑加大了运维管控的复杂度和成本。\n3. 灵活的部署策略\nDeployment 无法控制发布步长，StatefulSet 虽然可以控制步长，但是每次都需要人工计算最新版本需要的副本数并修改 Partition，在多机房/部署单元的情况下，光想想发布要做的操作都脑袋炸裂。\n在面对以上这些问题的时候，我们思考：能不能有一个类似 Deployment 的东西，不仅可以实现副本保持，并且能协助用户管控应用节点部署结构、做 Beta 验证、分批发布，减少用户干预流程，实现最大限度减少发布风险的目标，做到快速止损，并进行修正干预。这就是我们为什么选择定义了自己的资源——CafeDeployment。\n模型定义 CafeDeployment 主要提供跨部署单元的管理功能，其下管理多个 InPlaceSet。每个 InPlaceSet 对应一个部署单元。部署单元是逻辑概念，他通过 Node 上的 label 来划分集群中的节点，而 InPlaceSet 则通过 NodeAffinity 能力，将其下的 Pod 部署到同一个部署单元的机器上。由此实现 CafeDeployment 跨部署单元的管理。\nCafeDeployment 作为多个部署单元的上层，除了提供副本保持，历史版本维护等基本功能，还提供了跨部署单元的分组扩容，分组发布，Pod 调度等功能。模型定义如下：\napiVersion: apps.cafe.cloud.alipay.com/v1alpha1 kind: CafeDeployment metadata: ...... spec: historyLimit: 20 podSetType: InPlaceSet\t# 目前支持底层PodSet：InPlaceSet，ReplicaSet，StatefulSet replicas: 10 selector: matchLabels: instance: productpage name: bookinfo strategy: batchSize: 4\t# 分组发布时，每组更新的Pod数目 minReadySeconds: 30 needWaitingForConfirm: true\t# 分组发布中，每组结束时是否需要等待确认 upgradeType: Beta\t# 目前支持发布策略：Beta发布，分组发布 pause: false template: ...... volumeClaimTemplates:\t# 用于支持statefulSet serviceName:\t# 用于支持statefulSet topology: autoReschedule: enable: true\t# 是否启动Pod自动重调度 initialDelaySeconds: 10 unitType: Cell\t# 部署单元类型：Cell，Zone，None unitReplicas: CellA: 4\t# 固定某部署单元的Pod数目 values:\t# 部署单元 - CellA - CellB 因为我们将大部分的控制逻辑都抽取到上层 CafeDeployment 中，因此我们重新设计了 InPlaceSet，将它做得足够简单，只关注于“InPlace”相关的功能，即副本保持和原地升级，保持 IP 不变的能力，模型定义如下：\nspec: minReadySeconds: 30 replicas: 6 selector: matchLabels: instance: productpage name: bookinfo deployUnit: CellB strategy: partition: 6\t# 控制发布时更新Pod的进度 template: ...... 功能特性 灵活的分组定义 CafeDeployment 支持跨部署单元的分组扩容，Pod 调度，分组发布。分组策略主要分为两种，Beta 分组和 Batch 分组：\n Batch 分组 即根据 BatchSize 将 Pod 分为多个批次，每批中的 Pod 会同时发布。待用户确认（needWaitingForConfirm=true时）无误时，或当前批次所有 Pod 都 ready 后（needWaitingForConfirm=false 时），则会开始进行下一组的发布。\n在分组暂停时，CafeDeployment 会被打上 Annotation: cafe.sofastack.io/upgrade-confirmed=false，用户可通过将 Annotation 的值改为 true，确认当前分组。\n Beta 分组 相比 Batch 发布，会在第一组发布之前多一步 Beta 分组。此组会在每个部署单元内选择一个 Pod 进行发布，以减小错误配置带来的影响。若用户确认无误，可以确认继续，以进入正常的 Batch 发布流程。\n安全的分组扩容和发布能力 分组扩容 为预防不正确的配置造成大量错误 Pod 同时创建，占用大量资源等意外情况出现，CafeDeployment 支持分组扩容，以降低风险。\n在如下配置时，CafeDeployment 会创建两个 InPlaceSet 实例，并开始分组创建（扩容）Pod。\nspec: ...... replicas: 10\t# 副本数为10 strategy: upgradeType: Beta\t# Beta发布 batchSize: 4\t# 每组Pod数为4 needWaitingForConfirm: true\t# 分组暂停 topology: ...... values:\t# …","date":1563454800,"description":"本文根据 SOFAChannel#7 直播分享整理，介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。","dir":"blog/sofa-channel-7-retrospect/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a1185b6bb7c21fd49c4118950c16a2a9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-7-retrospect/","publishdate":"2019-07-18T21:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-channel-7-retrospect/","summary":"本文简单介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。 相关直播视频以及 PPT 查看地址 背景介绍 Kubernetes 原生社区 Deployment 和 StatefulSet 解决了“服务节点版本一致性”","tags":["CafeDeployment","SOFAChannel"],"title":"自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-7-retrospect/","wordcount":3476},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第二篇，本篇作者尚彧，是 SOFARegistry 开源负责人。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末附共建列表，欢迎领取共建~\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 无论传统的 SOA 还是目前的微服务架构，都离不开分布式的特性，既然服务是分布的就必须解决服务寻址的问题。服务注册中心是这个过程最主要的组件，通过服务注册和服务发现特性收集服务供求关系，解耦服务消费方对服务提供方的服务定位问题。\n服务注册中心的最主要能力是服务注册和服务发现两个过程。服务注册的过程最重要是对服务发布的信息进行存储，服务发现的过程是把服务发布端的所有变化（包括节点变化和服务信息变化）及时准确的通知到订阅方的过程。\n本文详细描述服务注册中心 SOFARegistry 对于服务发现的实现和技术演进过程，主要涉及 SOFARegistry 的服务发现实现模式以及服务数据变化后及时推送到海量客户端感知的优化过程。\n服务发现分类 分布式理论最重要的一个理论是 CAP 原理。关于注册中心的解决方案，根据存储数据一致性维度划分业界有很多实现，比如最有代表性的强一致性 CP 系统 ZooKeeper 和最终一致性 AP 系统 Eureka。SOFARegistry 在数据存储层面采用了类似 Eureka 的最终一致性的过程，但是存储内容上和 Eureka 在每个节点存储相同内容特性不同，采用每个节点上的内容按照一致性 Hash 数据分片来达到数据容量无限水平扩展能力。\n服务端发现和客户端发现 抛开数据存储的一致性，我们从服务发现的实现维度考虑服务注册中心的分类，业界也按照服务地址选择发生主体和负载均衡策略实现主体分为客户端服务发现和服务端服务发现。\n 客户端服务发现：即由客户端负责决定可用的服务实例的\u0026amp;rdquo;位置\u0026amp;rdquo;以及与其相关的负载均衡策略，就是服务发现的地址列表在客户端缓存后由客户端自己根据负载均衡策略进行选址完成最终调用，地址列表定期进行刷新或服务端主动通知变更。最主要的缺点是需要有客户端实现，对于各种异构系统不同语言不同结构的实现必须要进行对应的客户端开发，不够灵活，成本较高。 服务端服务发现：在服务端引入了专门的负载均衡层，将客户端与服务发现相关的逻辑搬离到了负载均衡层来做。客户端所有的请求只会通过负载均衡模块，其并不需要知会微服务实例在哪里，地址是多少。负载均衡模块会查询服务注册中心，并将客户端的请求路由到相关可用的微服务实例上。这样可以解决大量不同实现应用对客户端的依赖，只要对服务端的负载均衡模块发请求就可以了，由负载均衡层获取服务发现的地址列表并最终确定目标地址进行调用。 SOFARegistry 服务发现模式：以客户端服务发现模式为主。这样的模式实现比较直接，因为在同一个公司内部实践面对的绝大多数应用基本上都是同一个语言实现的，客户端实现也只需要确定一套，每个客户端通过业务内嵌依赖方式部署，并且可以根据业务需求进行定制负载均衡策略进行选址调用。当然也会遇到特殊的异构系统，这个随着微服务架构 RPC 调用等通信能力下沉到 Mesh 执行也得到解决，可以在 Mesh 层进行特定的服务注册中心客户端嵌入，选择路由都在这里统一进行，对不同语言实现的系统进行无感知。 服务发现的推、拉模型 服务发现最重要的过程是获取服务发布方地址列表的过程，这个过程可以分为两种实现模式：客户端主动获取的拉模式和服务端主动变更通知的推送模式：\n 拉模式主要是在客户端按照订阅关系发起主动拉取过程。客户端在首次订阅可以进行一次相关服务 ID 的服务列表查询，并拉取到本地缓存，后续通过长轮询定期进行服务端服务 ID 的版本变更检测，如果有新版本变更则及时拉取更新本地缓存达到和服务端一致。这种模式在服务端可以不进行订阅关系的存储，只需要存储和更新服务发布数据。由客户端主动发起的数据获取过程，对于客户端实现较重，需要主动获取和定时轮训，服务端只需要关注服务注册信息的变更和健康情况及时更新内存。这个过程由于存在轮训周期，对于时效性要求不高的情况比较适用。 推模式主要是从服务端发起的主动变更推送。这个模式主要数据压力集中在服务端，对于服务注册数据的变更和提供方，节点每一次变更情况都需要及时准确的推送到客户端，更新客户端缓存。这个数据推送量较大，在数据发布频繁变更的过程，对于大量订阅方的大量数据推送频繁执行，数据压力巨大，但是数据变更信息及时，对于每次变更都准确反映到客户端。 SOFARegistry 服务发现模式采用的是推拉结合方式。客户端订阅信息发布到服务端时可以进行一次地址列表查询，获取到全量数据，并且把对应的服务 ID 版本信息存储在 Session 回话层，后续如果服务端发布数据变更，通过服务 ID 版本变更通知回话层 Session，Session 因为存储客户端订阅关系，了解哪些客户端需要这个服务信息，再根据版本号大小决定是否需要推送给这个版本较旧的订阅者，客户端也通过版本比较确定是否更新本次推送的结果覆盖内存。此外，为了避免某次变更通知获取失败，定期还会进行版本号差异比较，定期去拉取版本低的订阅者所需的数据进行推送保证数据最终一致。 SOFARegistry 服务发现模式 数据分层 前面的文章介绍过 SOFARegistry 内部进行了数据分层，在服务注册中心的服务端因为每个存储节点对应的客户端的链接数据量有限，必须进行特殊的一层划分用于专门收敛无限扩充的客户端连接，然后在透传相应的请求到存储层，这一层是一个无数据状态的代理层，我们称之为 Session 层。\n此外，Session 还承载了服务数据的订阅关系，因为 SOFARegistry 的服务发现需要较高的时效性，对外表现为主动推送变更到客户端，所以推送的主体实现也集中在 Session 层，内部的推拉结合主要是通过 Data 存储层的数据版本变更推送到所有 Session 节点，各个 Session 节点根据存储的订阅关系和首次订阅获取的数据版本信息进行比对，最终确定推送给那些服务消费方客户端。\n触发服务推送的场景 直观上服务推送既然是主动的，必然发生在主动获取服务时刻和服务提供方变更时刻：\n 主动获取：服务订阅信息注册到服务端时，需要查询所有的服务提供方地址，并且需要将查询结果推送到客户端。这个主动查询并且拉取的过程，推送端是一个固定的客户端订阅方，不涉及服务 ID 版本信息判定，直接获取列表进 …","date":1563433200,"description":"本文为《剖析 | SOFARegistry 框架》第二篇，本篇作者尚彧，来自蚂蚁金服。","dir":"blog/sofa-registry-service-discovery-optimization/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f99d259a0c323df2ddaaea719da2f93c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","publishdate":"2019-07-18T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路","type":"blog","url":"/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","wordcount":5056},{"author":"隐秀","categories":"SOFAStack","content":" \u0026amp;gt; KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。\n市场观察 当我们回顾云计算的发展历程，会看到基础架构经历了从物理机到虚拟机，从虚拟机再到容器的演进过程。在这大势之下，应用架构也在同步演进，从单体过渡到多层，再到当下的微服务。在变化的背后，有一股持续的动力，它来自于三个不变的追求：提高资源利用率，优化开发运维体验，以及更好地支持业务发展。\n目前， Serverless 已成为云原生社区关注的重点之一，它的发展也不例外。相比容器技术，Serverless 可以将资源管理的粒度更加细化，使开发者更快上手云原生，并且倡导事件驱动模型支持业务发展。从而帮助用户解决了资源管理复杂、低频业务资源占用等问题；实现面向资源使用，以取代面向资源分配的模式。根据 CNCF 在2018年底基于 2400 人的一份统计报告，已有 38% 的组织正在使用 Serverless 技术，相比 2017 同期增长了 22%。(数据来源：CNCF Survey)\n\u0026amp;gt; 图片来源：Gartner Report: China Summary Translation Evolution of Server Computing - VMs to Containers to Serverless - Which to Use When\n目前市场上，云厂商提供了多种 Serverless 产品和解决方案，大致可划分为：\n 函数计算服务：如 AWS Lambda，特点是以代码片段为单位运行，并对代码风格有一定要求。 面向应用的 Serverless 服务：如 Knative，特点是基于容器服务，并提供了从代码包到镜像的构建能力。 容器托管服务：如 AWS Fargate，特点是以容器镜像为单元运行，但用户仍需感知容器。 从社区来看，CNCF 云原生基金会正通过 Serverless 工作组协调社区讨论并促进规范和标准的形成，工作组产出了 Serverless 白皮书和全景图等重要内容。其中，全景图将目前的生态划分为了平台层，框架层，工具链层和安全层这四个模块。\n\u0026amp;gt; 图片来源：https://landscape.cncf.io/\n落地挑战 在交流过程中，我们发现 Serverless 很好地解决了客户的一些诉求：包括通过 0-1-0 的伸缩能力来提高资源时用率，降低成本；支持代码包出发，从而让客户无感化实现云原生，历史应用无需经过容器化改造；支持灵活的触发器配置，引导用户对应用进行事件驱动的改造，从而适应业务的高速发展等。这些优势，使得 Serverless 在小程序开发的场景下大放异彩。\n同时，对于在企业级应用的生产环境落地 Serverless，各方也有了很多探索和突破。在本周刚结束的 KubeCon China 2019 大会上，Serverless 工作组会议也以此为话题展开了讨论。目前的核心挑战可归纳为：\n平台可迁移\n目前众多平台都推出了自己的 Serverless 标准，包括代码格式、框架和运维工具等，用户既面临较高的学习成本和选择压力，也担心无法在平台之间灵活迁移 Serverless 应用。\n0-M-N 性能\n线上应用对控制请求延迟有严格的要求，因此，用户需要谨慎地验证 Serverless 0-1 冷启动速度、M-N 扩容速度以及稳定性都达到了生产要求。\n调试和监控\n用户对底层资源无感知，只能借助平台能力对应用进行调试和监控，用户需要平台提供强大的日志功能进行排错，和多维度的监控功能时刻了解应用状态。\n事件源集成\n采用 Serverless 架构后，应用往往进行更细粒度的拆分，并通过事件串联。因此用户希望平台能集成大多数通用的事件源，并支持自定义事件，使得触发机制更加灵活。\n工作流支持\n完成某个业务，往往涉及多个 Serverless 应用之间的配合，当数目较多时，用户希望可以用工作流工具来进行统一编排和状态查看，提高效率。\n蚂蚁金服实践 SOFAStack 致力于通过产品技术解决云上客户实际痛点，沉淀蚂蚁金服技术实践，帮助用户以高效、低成本的方式迁移到云原生架构。Serverless 应用服务（Serverless Application Service，简称 SOFA SAS）是一款源自蚂蚁金服实践的一站式 Serverless 平台。SAS 基于 SOFAStack CAFE 云应用引擎 （Cloud Application Fabric Engine 简称 CAFE），CAFE 的容器服务已经通过了 CNCF 的一致性认证，是一个标准的 Kubernetes。\nServerless 应用服务产品在兼容标准 Knative 同时，融入了源自蚂蚁金服实践的应用全生命周期管理能力，提供了 Serverless 引擎管理、应用与服务管理、版本管理与流控、根据业务请求或事件触发较快的 0-M-N-0 自动伸缩、计量、日志及监控等配套能力。同时结合金融云上客户实际痛点，产品独居匠心的提供独占版与共享版两种形态，以及传统代码包、容器镜像与纯函数三种研发模式，以解决用户的不同需求，降低客户准入门槛。\n 一键部署：用户可以通过代码包或容器镜像的方式一键部署应用并在任意时刻测试执行。 引擎管理：SAS 提供了丰富的引擎全生命周期管理、诊断、监测等能力，为独占版客户赋能 Serverless 引擎数据面的全方位管理与运维运营能力。 服务及版本：SAS 提供应用管理、应用服务管理以及版本管理。版本可以采用容器镜像方式部署也可以采用传统VM发布模式下的代码包部署，很多情况下用户代码无需修改也无需编写维护 Dockerfile 即可迁移。 0-M-N：SAS 提供 0-M-N-M-0 的 Serverelss 快速伸缩能力，支持事件触发或流量触发的 0-M，多种指标的 M-N（如 QPS、CPU、MEM 等等） 日志监控计量：产品内置了日志、监控、计量等配套设施能力，帮助用户进行调试和应用状态监控。 流量控制：基于 SOFAMesh，SAS提供基本流控能力，后续会与服务网格进一步深度集成提供大规模多维跨地域及混合云的流控能力。 触发器管理：产品支持基于常见周期以及秒级精度的cron表达式触发器，可关联并触发无服务器应用，后续将支持更多 IaaS、PaaS 管控型与数据型事件。 性能简析：横轴为完全在同一时刻触发冷启的Java应用个数，纵轴为冷启应用的平均与最小耗时。随着压力增大，50个Java应用同一时刻调度加冷启平均耗时2.5秒左右，100个Java应用同一时刻调度冷启平均耗时3-4秒，最短耗时1.5到2秒。\n 性能简析：Pooling 快弹慢缩时序算法，池容量和实际单位时间申请量关系可做到如图所示（蓝色为实际申请量，绿色为池容量）\n 目前产品已顺利支撑生产环境小程序 Serverless 模式。同时通过 0-M-N-M-0 的能力在很大程度上降低了小程序的运营成本。在行业客户领域，某保险公司决定近期迁移部分日结前置和长尾应用到 Serverless 产品平台，这也是我们产品又一个重要突破。未来， …","date":1562828400,"description":"KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。","dir":"blog/serverless-market-challenge/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e2a95cbe3e0343e3908f17bea5a55d70","permalink":"https://sofastack.github.io/sofastack.tech/blog/serverless-market-challenge/","publishdate":"2019-07-11T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/serverless-market-challenge/","summary":"\u0026gt; KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。 市场观察 当我们回顾云计算的发展历程，会看到基础架构经历了从物理机到","tags":["SOFAStack","Serverless"],"title":"Serverless 市场观察和落地挑战","type":"blog","url":"/sofastack.tech/blog/serverless-market-challenge/","wordcount":2537},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，ServiceMesh，Serverless，安全容器等方向，并发挥自己的力量。SOFAStack 作为蚂蚁金服重要的开源项目，最近也与 CNCF 有故事发生。\n 近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nCNCF \u0026amp;amp; CNCF Cloud Native Landscape CNCF(Cloud Native Computing Foundation)，是由 Google 牵头创立的云原生计算开源软件基金会。它致力于云原生(Cloud Native)技术的普及和可持续发展。2016 年 11 月，CNCF 开始维护 Cloud Native Landscape，汇总流行热门的云原生技术与工具，并加以分类，为企业构建云原生体系提供参考，在云生态研发、运维领域具有广泛影响力。\nSOFAStack \u0026amp;amp; CNCF Cloud Native Landscape 蚂蚁金服金融级分布式架构 SOFAStack 中的 3 个项目加入这次最新版本的 Cloud Native Landscape ，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 **SOFATracer ** 和 RPC 服务框架 SOFARPC。\nSOFAMosn Star 一下✨： https://github.com/sofastack/sofa-mosn\nSOFAMosn(Modular Observable Smart Network)，是一款采用 GoLang 开发的 Service Mesh 数据平面代理， 功能和定位类似 Envoy ，旨在提供分布式，模块化，可观察，智能化的代理能力。 SOFAMosn 支持 Envoy 和 Istio 的 API，可以和 Istio 集成，在 SOFAMesh 中，我们使用 SOFAMosn 替代 Envoy。 SOFAMosn 初始版本由蚂蚁金服和阿里大文娱 UC 事业部携手贡献，期待社区一起来参与后续开发，共建一个开源精品项目。\nSOFARPC Star 一下✨： https://github.com/sofastack/sofa-rpc\nSOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有业务相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括Bolt， RESTful ， Dubbo ， H2C 协议进行通信。其中 Bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\nSOFATracer Star 一下✨： https://github.com/sofastack/sofa-tracer\nSOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFAStack 开源家族 SOFAStack™（Scalable Open Financial Architecture Stack）是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n图为 SOFAStack 开源全景图，其中橙色部分为 SOFAStack 包含的开源组件，白色部分为兼容或集成开源社区其它优秀的开源产品\n特别感谢 SOFAStack 开源社区的每一个你 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。 到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期认证了两位社区 Committer，再次感谢开发者和企业的信任和认可，因为你们，SOFAStack 社区才能会更好。\n","date":1562749200,"description":"Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC 加入 CNCF 云原生全景图","dir":"blog/sofastack-projects-joined-cncf-landscape/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"219e8daac9b49b95c7d5afd94d9ee791","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","publishdate":"2019-07-10T17:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","summary":"2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kuberne","tags":["SOFAStack","CNCF","开源"],"title":"蚂蚁金服 3 个项目进入 CNCF 云原生全景图 | 开源","type":"blog","url":"/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","wordcount":1278},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第四篇，本篇作者力鲲，来自蚂蚁金服。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 在 Raft 算法中，选举是很重要的一部分，所谓选举也就是在多个节点中选出一个 Leader 节点，由他来对外提供写服务 （以及默认情况下的读服务）。\n在剖析源码时，对选举机制的理解经常会遇到两极分化的情况，对于了解 Raft 算法基本原理的同学，阅读源码就是品味实现之巧妙的过程，而对初体验的同学，却会陷入丈二和尚的窘境，仿佛坠入云里雾里。\n为了提升文章的可读性，我还是希望花一部分篇幅讲清楚选举机制的基本原理，以便后面集中注意力于代码实现。下面是一段图文比喻，帮助理解的同时也让整篇文章不至于过早陷入细节的讨论。\n问题1：选举要解决什么 一个分布式集群可以看成是由多条战船组成的一支舰队，各船之间通过旗语来保持信息交流。这样的一支舰队中，各船既不会互相完全隔离，但也没法像陆地上那样保持非常密切的联系，天气、海况、船距、船只战损情况导致船舰之间的联系存在但不可靠。\n舰队作为一个统一的作战集群，需要有统一的共识、步调一致的命令，这些都要依赖于旗舰指挥。各舰船要服从于旗舰发出的指令，当旗舰不能继续工作后，需要有别的战舰接替旗舰的角色。\n图1 - 所有船有责任随时准备接替旗舰\n如何在舰队中，选出一艘得到大家认可的旗舰，这就是 SOFAJRaft 中选举要解决的问题。\n问题2：何时可以发起选举 何时可以发起选举？换句话说，触发选举的标准是什么？这个标准必须对所有战舰一致，这样就能够在标准得到满足时，所有舰船公平的参与竞选。在 SOFAJRaft 中，触发标准就是通信超时，当旗舰在规定的一段时间内没有与 Follower 舰船进行通信时，Follower 就可以认为旗舰已经不能正常担任旗舰的职责，则 Follower 可以去尝试接替旗舰的角色。这段通信超时被称为 Election Timeout （简称 ET）， Follower 接替旗舰的尝试也就是发起选举请求。\n图2 - ET 触发其他船竞选旗舰\n问题3：何时真正发起选举 在选举中，只有当舰队中超过一半的船都同意，发起选举的船才能够成为旗舰，否则就只能开始一轮新的选举。所以如果 Follower 采取尽快发起选举的策略，试图尽早为舰队选出可用的旗舰，就可能引发一个潜在的风险：可能多艘船几乎同时发起选举，结果其中任何一支船都没能获得超过半数选票，导致这一轮选举无果，然后失败的 Follower 们再一次几乎同时发起选举，又一次失败，再选举 again，再失败 again ···\n图3 - 同时发起选举，选票被瓜分\n为避免这种情况，我们采用随机的选举触发时间，当 Follower 发现旗舰失联之后，会选择等待一段随机的时间 Random(0, ET) ，如果等待期间没有选出旗舰，则 Follower 再发起选举。\n图4 - 随机等待时间\n问题4：哪些候选者值得选票 SOFAJRaft 的选举中包含了对两个属性的判断：LogIndex 和 Term，这是整个选举算法的核心部分，也是容易让人产生困惑的地方，因此我们做一下解释：\n Term：我们会对舰队中旗舰的历史进行编号，比如舰队的第1任旗舰、第2任旗舰，这个数字我们就用 Term 来表示。由于舰队中同时最多只能有一艘舰船担任旗舰，所以每一个 Term 只归属于一艘舰船，显然 Term 是单调递增的。 LogIndex：每任旗舰在职期间都会发布一些指令（称其为“旗舰令”，类比“总统令”），这些旗舰令当然也是要编号归档的，这个编号我们用 Term 和 LogIndex 两个维度来标识，表示“第 Term 任旗舰发布的第 LogIndex 号旗舰令”。不同于现实中的总统令，我们的旗舰令中的 LogIndex 是一直递增的，不会因为旗舰的更迭而从头开始计算。 图5 - 总统令 Vs 旗舰令，LogIndex 稍有区别\n所有的舰船都尽可能保存了过去从旗舰接收到的旗舰令，所以我们选举的标准就是哪艘船保存了最完整的旗舰令，那他就最有资格接任旗舰。具体来说，参与投票的船 V 不会对下面两种候选者 C 投票：一种是 lastTermC \u0026amp;lt; lastTermV；另一种是 (lastTermV == lastTermC) \u0026amp;amp;\u0026amp;amp; (lastLogIndexV \u0026amp;gt; lastLogIndexC)。\n稍作解释，第一种情况说明候选者 C 最后一次通信过的旗舰已经不是最新的旗舰了，至少比 V 更滞后，所以它所知道的旗舰令也不可能比 V 更完整。第二种情况说明，虽然 C 和 V 都与同一个旗舰有过通信，但是候选者 C 从旗舰处获得的旗舰令不如 V 完整 (lastLogIndexV \u0026amp;gt; lastLogIndexC)，所以 V 不会投票给它。\n图6 - Follower 船 b 拒绝了船 c 而投票给船 a，船 a 旗舰令有一个空白框表示“第 Term 任旗舰”没有发布过任何旗舰令\n问题5：如何避免不够格的候选者“捣乱” 如上一小节所说，SOFAJRaft 将 LogIndex 和 Term 作为选举的评选标准，所以当一艘船发起选举之前，会自增 Term 然后填到选举请求里发给其他船只 （可能是一段很复杂的旗语），表示自己竞选“第 Term + 1 任”旗舰。\n这里要先说明一个机制，它被用来保证各船只的 Term 同步递增：当参与投票的 Follower 船收到这个投票请求后，如果发现自己的 Term 比投票请求里的小，就会自觉更新自己的 Term 向候选者看齐，这样能够很方便的将 Term 递增的信息同步到整个舰队中。\n图7 - Follower 船根据投票请求更新自己的 Term\n但是这种机制也带来一个麻烦，如果一艘船因为自己的原因没有看到旗舰发出的旗语，他就会自以为是的试图竞选成为新的旗舰，虽然不断发起选举且一直未能当选（因为旗舰和其他船都正常通信），但是它却通过自己的投票请求实际抬升了全局的 Term，这在 SOFAJRaft 算法中会迫使旗舰 stepdown （从旗舰的位置上退下来）。\n图8 - 自以为是的捣乱者，迫使旗舰 stepdown\n所以我们需要一种机制阻止这种“捣乱”，这就是预投票 (pre-vote) 环节。候选者在发起投票之前，先发起预投票，如果没有得到半数以上节点的反馈，则候选者就会识趣的放弃参选，也就不会抬升全局的 Term。\n图9 - Pre-vote 预 …","date":1562742000,"description":"本文为《剖析 | SOFAJRaft 实现原理》第四篇，本篇作者力鲲，来自蚂蚁金服","dir":"blog/sofa-jraft-election-mechanism/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e40fefafd980ac2308a3ba6f3fda9cdd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-election-mechanism/","publishdate":"2019-07-10T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-jraft-election-mechanism/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-election-mechanism/","wordcount":3152},{"author":"SOFAStack","categories":"SOFAStack","content":" 本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。\n 2019 年 6 月 25 日，在 KubeCon China 2019，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，Service Mesh，Serverless，安全容器等方向，并发挥自己的力量。\n在本次大会，蚂蚁金服也与数百名云原生爱好者用五个小时搭建了一个云原生的电商平台，具体怎么做？希望本文能提供一些思路。\n近二十年技术发展：从集中式架构到云原生架构 过去的十几年里，技术发生了翻天覆地的变化，先来简单回顾下：在二十一世纪初，大部分企业的应用还处于集中式架构。这个阶段企业开始做一些信息化的建设工作，典型的一些技术例如集群部署（Tomcat 集群、Weblogic 集群）来保证系统的高可用，以及采购 IOE（IBM，Oracle，EMC）等这些商业化的软硬件产品，通过更高的配置、更好的性能等方式来抗住业务的增长。\n慢慢的，随着公司规模的扩大，集中式架构已经不足以再支撑复杂的业务系统，很多企业开始做一些系统拆分的改造，典型的技术例如 SOA 化。当系统拆分后，就不再需要使用之前昂贵的小型机去部署服务，慢慢的虚拟机的部署方式变成了主流。同样的，服务化后数据库和存储也不再必须采用商业化软硬件的解决方案，企业转为一些开源的解决方案，例如把 Oracle 换成了 MySQL。\n系统的拆分虽然可以带来很多好处，例如使业务内聚，系统之间松耦合，方便快速迭代等。但是随之带来的问题也很明显，例如拆分后系统越来越多，系统间的交互也会变得更加复杂，调用链路变长可能引起性能问题，分布式后数据存储等数据一致性也有不少挑战，还有服务化后带来资源分配、隔离等问题。这时候一些虚拟化和容器化的技术开始涌现，典型技术就是 OpenStack 和 Docker，OpenStack 帮助我们解决了 IaaS 层的建设与管理问题，而 Docker 给了我们资源隔离的最佳实践，但这些并没有解决掉运维复杂的一些问题。\n而近几年，新的云原生的一些技术产品和理念开始出现，例如 Kubernetes、Service Mesh、Serverless 等，这些可以解决应用部署、运维复杂的一些实际问题。\n技术发展下的蚂蚁金服 蚂蚁金服从 2007 年开始从集中式架构走向分布式架构。我们把过去十多年的技术演进过程中自主研发的一套金融级分布式架构沉淀成为 SOFAStack™（Scalable Open Financial Architecture Stack）。\n从 2007 年到 2012 年，蚂蚁金服完成所有业务系统的模块化、服务化改造。通过 TCC 模式解决了服务化、数据拆分等带来的数据一致性的问题，通过注册中心解决了服务单点的问题。\n在完成服务化改造后，随着服务集群的增大，系统的伸缩性遇到了瓶颈，另外为了满足金融级的属性，蚂蚁金服对系统可用性、数据一致性提出了更高的要求。蚂蚁金服从 2013 年开始摸索出了一套单元化的思想，并基于此，推出了同城双活、异地多活、弹性调度等能力，保证业务不停机，数据不丢失。\n再之后随着国内互联网金融的崛起、蚂蚁金服的国际化，蚂蚁金服也将自己的能力和技术开放出来，在金融云上以云产品的形式存在，开发者可以基于此快速搭建金融级能力的分布式系统，同时我们也将内部的一些实践开源出来。\n从 2017 年开始，我们注意到云原生的理念正在快速发展，面对云原生带来的机会和改变，蚂蚁金服的策略是积极拥抱云原生。 因为云原生带来的思想和理念刚好可以用来解决蚂蚁金服内部遇到的一些场景和问题。\n例如 Service Mesh 可以解决中间件等基础能力下层的问题，Serverless 可以解决研发效能的问题，可以让业务开发更专注于业务。这些新的技术和理念蚂蚁金服都会在内部探索并在生产落地，最近我们在深圳 GIAC 首次分享了大规模落地的实践总结，蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录。同时，我们也会将这些云原生落地实践开源出来，并和社区一起共同推进和建设金融级的云原生标准。\nSOFAStack 开源版本： 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期也认证了两位社区 Committer，这里想再次感谢开发者和企业的信任和认可，我们将持续优化和扩大开源版图。\n我们看下这张图，这里可以看到 SOFAStack 体系下开源了很多微服务相关的技术组件，例如 SOFABoot、SOFARPC 等，我们也和社区其它优秀的开源产品进行了兼容或者集成，利用这些组件可以快速的搭建出金融级分布式架构系统。开源的源码可以在这张图下面的 Github 地址上找到。本次的 Workshop 我们就会利用到开源的一些技术组件。\nSOFAStack 云产品： 上图是云上 SOFAStack 的架构图，我们可以看到 SOFAStack 商业化对外输出的是完整的解决方案。支撑解决方案的就是本次要体验的分布式中间件和云应用引擎等等能力。除此之外还有完善的研发效能平台服务以及技术风险防控平台。关于这部分内容，在本次下午场会有更详细的介绍和体验。\nLet\u0026amp;rsquo;s get started! 刚聊了这么多，大家是不是想动手试试了呢？本次 Demo 将带领大家综合利用开源版本的 SOFAStack 和云上产品，五小时实现一个在线电商平台。\n下面简单介绍下本次 Workshop 的内容，如下图：\n上午\n 构建基础电商平台（书店） ，并改造为微服务架构； 基于 SOFABoot 动态模块能力实时的电商平台（书店）增加智能推荐的能力； 用分布式事务 Seata 来解决微服务拆分后的分布式事务的问题，保证购买和余额的数据一致性； 下午\n 通过 Serverless 快速上云，利用 SOFA SAS 发布书店到云环境上，根据流量自动扩缩容； 通过 Service Mesh 的方式来实现精度灰度和流控的能力； 这是提到的是在线书店的系统架构图，最上面是部署好的一些基础设施，包括注册中心 SOFARegistry，服务管控台 SOFADashboard，监控度量 SOFALookout 等，我们已经提前准备好了这部分内容。\n下面就是业务的内容。为了方便，我们不再做前后端分类部署，本次大家只需要操作 2 个应用：\n左边是网页系统和库存系统，提供库存操作服务，右边是账务系统，提供余额相关服务，当用户的请求进来时，库存系统需要通过 RPC 调到账务系统。\n另外库存服务和余额服务分别对应的是独立的数据库，这个后面会用分布式事务 Seata 去解决分布式事务的问题。\nSOFAStack Cloud …","date":1562742000,"description":"本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。","dir":"blog/sofastack-cloud-native-workshop-show/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bed45f24a92c60ca5b141952abdc2049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","publishdate":"2019-07-10T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","summary":"本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。 2019 年 6 月 25 日，在 KubeCon China 2019，全球知名开源组织云原生计","tags":["分布式事务","SOFABoot","Service Mesh","开源","Seata"],"title":"五小时构建云原生电商平台 | KubeCon SOFAStack Workshop 详解","type":"blog","url":"/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","wordcount":2648},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 活动时间：7 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 在 6 月 KubeCon 大会期间，蚂蚁金服正式宣布加入了 CNCF 成为黄金会员，同时 SOFAStack-CAFE 云应用引擎产品也通过了 K8S 一致性认证，旨在向广大金融机构提供云原生的可落地路径。\n为满足金融级云原生发布部署、变更管控场景对于可灰度、可监控、可应急的需求，SOFAStack 产品研发团队在 Kubernetes 基础上实现了自定义资源 CAFEDeployment ，它能够通过可靠而灵活的分发、风险控制的部署策略以及高性能的原地升级更新扩展部署能力。它尤其消除了金融服务行业所面临的技术障碍，使用户能够专心发展核心业务。\n与 Kubernetes 原生工作负载对象 Deployment 所提供的简洁轻量的滚动发布相比，CAFEDeployment 旨在满足金融场景对分批发布、多活容灾、原地升级等方面的诉求。\n7 月 18 日周四晚 7 点，将邀请 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人 枫晟 为大家分享《扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进》。\n在此次分享中，将介绍对此 Kubernetes 扩展能力的相关观点主张、产品探索和实际演示。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/737\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 枫晟 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人\n本期分享大纲： Kubernetes Deployment 发展历史与现状 Kubernetes Deployment 在互联网金融云场景下的问题与挑战 CafeDeployment 适配互联网金融发布的工作负载 CafeDeployment 的运行机制 CafeDeployment 功能演示 嘉宾 SOFAGirl 主持人 枫晟 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人 ","date":1562573400,"description":"7 月 18 日周四晚 7 点，线上直播第 7 期。","dir":"activities/sofa-channel-7/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"51c929733c988190de480a3a0dc5e735","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-7/","publishdate":"2019-07-08T16:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-7/","summary":"概要 活动主题：SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 活动时间：7 月 18 日周四晚 7 点 活动形式","tags":["SOFAChannel","CAFEDeployment"],"title":"SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进","type":"activities","url":"/sofastack.tech/activities/sofa-channel-7/","wordcount":813},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，ServiceMesh，Serverless，安全容器等方向，并发挥自己的力量。SOFAStack 作为蚂蚁金服重要的开源项目，最近也与 CNCF 有故事发生。\n 近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nCNCF \u0026amp;amp; CNCF Cloud Native Landscape CNCF(Cloud Native Computing Foundation)，是由 Google 牵头创立的云原生计算开源软件基金会。它致力于云原生(Cloud Native)技术的普及和可持续发展。2016 年 11 月，CNCF 开始维护 Cloud Native Landscape，汇总流行热门的云原生技术与工具，并加以分类，为企业构建云原生体系提供参考，在云生态研发、运维领域具有广泛影响力。\nSOFAStack \u0026amp;amp; CNCF Cloud Native Landscape 蚂蚁金服金融级分布式架构 SOFAStack 中的 3 个项目加入这次最新版本的 Cloud Native Landscape，分别是 Service Mesh 数据平面代理 SOFAMosn 、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nSOFAMosn Star 一下✨：https://github.com/sofastack/sofa-mosn\nSOFAMosn(Modular Observable Smart Network)，是一款采用 GoLang 开发的 Service Mesh 数据平面代理， 功能和定位类似 Envoy ，旨在提供分布式，模块化，可观察，智能化的代理能力。 SOFAMosn 支持 Envoy 和 Istio 的 API，可以和 Istio 集成，在 SOFAMesh 中，我们使用 SOFAMosn 替代 Envoy。 SOFAMosn 初始版本由蚂蚁金服和阿里大文娱 UC 事业部携手贡献，期待社区一起来参与后续开发，共建一个开源精品项目。\nSOFARPC Star 一下✨：https://github.com/sofastack/sofa-rpc\nSOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有业务相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括Bolt， RESTful ， Dubbo ， H2C 协议进行通信。其中 Bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\nSOFATracer Star 一下✨：https://github.com/sofastack/sofa-tracer\nSOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFAStack 开源家族 SOFAStack™（Scalable Open Financial Architecture Stack）是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n图为 SOFAStack 开源全景图，其中橙色部分为 SOFAStack 包含的开源组件，白色部分为兼容或集成开源社区其它优秀的开源产品\n特别感谢 SOFAStack 开源社区的每一个你 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期认证了两位社区 Committer，再次感谢开发者和企业的信任和认可，因为你们，SOFAStack 社区才能会更好。\n文中涉及的相关链接：\n SOFAMosn：https://github.com/sofastack/sofa-mosn SOFARPC：https://github.com/sofastack/sofa-rpc SOFATracer：https://github.com/sofastack/sofa-tracer SOFAMesh：https://github.com/sofastack/sofa-mesh ","date":1562569200,"description":"近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入。","dir":"blog/sofastack-cncf-cloud-native-landscape/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7146cdd7e74b9901a8ac20cb3e80cf6e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","publishdate":"2019-07-08T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","summary":"2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kuberne","tags":["SOFAStack"],"title":"蚂蚁金服 3 个项目进入 CNCF 云原生全景图 | 开源","type":"blog","url":"/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","wordcount":1590},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 7 月 3 日，在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开源技术创新奖（自主研发）。云计算开源产业大会由中国信息通信研究院主办，是中国云计算开源领域最权威和专业的行业盛会。\n本次大会上，中国信息通信研究院还发布了《混合云白皮书（2019年）》，该白皮书梳理了混合云的最新发展现状、关键能力、应用案例和技术发展趋势。基于完全自主研发的 SOFAStack 金融级分布式架构的网商银行三地五中心异地多活部署方案被作为典型应用案例入选其中。\n完全自主研发的金融级分布式架构 SOFAStack SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时任务、限流/熔断框架、动态配置推送、分布式链路追踪、Metrics 监控度量、分布式高可用消息队列、分布式事务框架和分布式数据库代理层等。\n据了解，经过数代架构演进和“双十一”考验的 SOFAStack，已于 2018 年 4 月正式对外开源，仅一年时间，SOFAStack 所有相关的开源代码，累计获得 16,000+ 个 Star，并有 110+ 个代码贡献者参与其中。\nSOFAStack 助力客户数字化转型 作为一套分布式架构的完整的解决方案，SOFAStack 在真实的金融场景里锤炼出不少最佳实践。\n2017 年 10 月，SOFAStack 与南京银行共同打造出“鑫云+”互金开放平台。该平台具备高性能承载、敏捷开发、强数据一致性和容灾能力等特性，从而使得南京银行互金核心系统在贷款交易处理能力、成本控制和对接效率都得到了极大的提升。南京银行与互联网平台合作开展线上业务仅一年时间，业务量就已经达到了过去十年传统线下消费金融业务的总和。南京银行“鑫云+”平台上线后，业务快速增长，贷款交易处理量增长了数倍。\n据介绍，SOFAStack 还帮助中国人保健康打造行业领先的互联网保险云核心业务系统，助力网商银行成为中国第一家将核心系统架构在金融云上的银行。\nSOFAStack 引领开源技术创新 2019 年 6 月 25 日，蚂蚁金服正式成为 CNCF 云原生计算基金会黄金会员，SOFAStack 云应用引擎产品 CAFE 已通过 CNCF 一致性认证，积极拥抱云原生的同时，满足严苛金融业务场景需求、保障金融技术风险。\n蚂蚁金服是金融级云原生的首倡者，主张金融级的云原生容器产品必须拥有稳定性与高可用保障、无限弹性扩展、运行时安全的能力，这些理念也集中体现在蚂蚁金服的金融级分布式开源项目 SOFAStack 里。\n蚂蚁金服一直积极参与开源社区共建。截至目前，蚂蚁金服已经有 400 多个开源项目。除了 SOFAStack 系列，Ant Design、SQLFlow、EggJS、Seata（与阿里巴巴共建）等也成为社区热门。\n蚂蚁金服金融科技产品技术总监杨冰表示：“开源是一种可以使客户和上下游产业共同参与和发展的可行模式，是个共赢的模式。在贡献蚂蚁金服的技术沉淀给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。只有开放才能求同存异，共同发展。”\n","date":1562223600,"description":"在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开源技术创新奖（自主研发）。","dir":"blog/sofastack-2019-oscar/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"21da7fc5e118681336c84d2dc46fe6bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-2019-oscar/","publishdate":"2019-07-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofastack-2019-oscar/","summary":"2019 年 7 月 3 日，在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开","tags":["SOFAStack"],"title":"蚂蚁金服 SOFAStack 荣获云计算开源产业大会尖峰开源技术创新奖","type":"blog","url":"/sofastack.tech/blog/sofastack-2019-oscar/","wordcount":1223},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第三篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 线性一致读是在分布式系统中实现 Java volatile 语义，当客户端向集群发起写操作的请求并且获得成功响应之后，该写操作的结果要对所有后来的读请求可见。实现线性一致读常规手段是走 Raft 协议，将读请求同样按照 Log 处理，通过日志复制和状态机执行获取读结果返回给客户端，SOFAJRaft 采用 ReadIndex 替代走 Raft 状态机的方案。本文将围绕 Raft Log Read，ReadIndex Read 以及 Lease Read 等方面剖析线性一致读原理，阐述 SOFAJRaft 如何使用 ReadIndex 和 Lease Read 实现线性一致读：\n 什么是线性一致读？共识算法只能保证多个节点对某个对象的状态是一致的，以 Raft 为例只能保证不同节点对 Raft Log 达成一致，那么 Log 后面的状态机的一致性呢？ 基于 ReadIndex 和 Lease Read 方式 SOFAJRaft 如何实现高效的线性一致读？ 线性一致读 什么是线性一致读? 所谓线性一致读，一个简单的例子是在 t1 的时刻我们写入了一个值，那么在 t1 之后，我们一定能读到这个值，不可能读到 t1 之前的旧值(想想 Java 中的 volatile 关键字，即线性一致读就是在分布式系统中实现 Java volatile 语义)。简而言之是需要在分布式环境中实现 Java volatile 语义效果，即当 Client 向集群发起写操作的请求并且获得成功响应之后，该写操作的结果要对所有后来的读请求可见。和 volatile 的区别在于 volatile 是实现线程之间的可见，而 SOFAJRaft 需要实现 Server 之间的可见。\n如上图 Client A、B、C、D 均符合线性一致读，其中 D 看起来是 Stale Read，其实并不是，D 请求横跨 3 个阶段，而 Read 可能发生在任意时刻，所以读到 1 或 2 都行。\nRaft Log read 实现线性一致读最常规的办法是走 Raft 协议，将读请求同样按照 Log 处理，通过 Log 复制和状态机执行来获取读结果，然后再把读取的结果返回给 Client。因为 Raft 本来就是一个为了实现分布式环境下线性一致性的算法，所以通过 Raft 非常方便的实现线性 Read，也就是将任何的读请求走一次 Raft Log，等此 Log 提交之后在 apply 的时候从状态机里面读取值，一定能够保证这个读取到的值是满足线性要求的。\n当然，因为每次 Read 都需要走 Raft 流程，Raft Log 存储、复制带来刷盘开销、存储开销、网络开销，走 Raft Log不仅仅有日志落盘的开销，还有日志复制的网络开销，另外还有一堆的 Raft “读日志” 造成的磁盘占用开销，导致 Read 操作性能是非常低效的，所以在读操作很多的场景下对性能影响很大，在读比重很大的系统中是无法被接受的，通常都不会使用。\n在 Raft 里面，节点有三个状态：Leader，Candidate 和 Follower，任何 Raft 的写入操作都必须经过 Leader，只有 Leader 将对应的 Raft Log 复制到 Majority 的节点上面认为此次写入是成功的。所以如果当前 Leader 能确定一定是 Leader，那么能够直接在此 Leader 上面读取数据，因为对于 Leader 来说，如果确认一个 Log 已经提交到大多数节点，在 t1 的时候 apply 写入到状态机，那么在 t1 后的 Read 就一定能读取到这个新写入的数据。\n那么如何确认 Leader 在处理这次 Read 的时候一定是 Leader 呢？在 Raft 论文里面，提到两种方法：\n ReadIndex Read Lease Read ReadIndex Read 第一种是 ReadIndex Read，当 Leader 需要处理 Read 请求时，Leader 与过半机器交换心跳信息确定自己仍然是 Leader 后可提供线性一致读：\n Leader 将自己当前 Log 的 commitIndex 记录到一个 Local 变量 ReadIndex 里面； 接着向 Followers 节点发起一轮 Heartbeat，如果半数以上节点返回对应的 Heartbeat Response，那么 Leader就能够确定现在自己仍然是 Leader； Leader 等待自己的 StateMachine 状态机执行，至少应用到 ReadIndex 记录的 Log，直到 applyIndex 超过 ReadIndex，这样就能够安全提供 Linearizable Read，也不必管读的时刻是否 Leader 已飘走； Leader 执行 Read 请求，将结果返回给 Client。 使用 ReadIndex Read 提供 Follower Read 的功能，很容易在 Followers 节点上面提供线性一致读，Follower 收到 Read 请求之后：\n Follower 节点向 Leader 请求最新的 ReadIndex； Leader 仍然走一遍之前的流程，执行上面前 3 步的过程(确定自己真的是 Leader)，并且返回 ReadIndex 给 Follower； Follower 等待当前的状态机的 applyIndex 超过 ReadIndex； Follower 执行 Read 请求，将结果返回给 Client。 不同于通过 Raft Log 的 Read，ReadIndex Read 使用 Heartbeat 方式来让 Leader 确认自己是 Leader，省去 Raft Log 流程。相比较于走 Raft Log 方式，ReadIndex Read 省去磁盘的开销，能够大幅度提升吞吐量。虽然仍然会有网络开销，但是 Heartbeat 本来就很小，所以性能还是非常好的。\nLease Read 虽然 ReadIndex Read 比原来的 Raft Log Read 快很多，但毕竟还是存在 Heartbeat 网络开销，所以考虑做更进一步的优化。Raft 论文里面提及一种通过 Clock + Heartbeat 的 Lease Read  …","date":1562050800,"description":"本文为《剖析 | SOFAJRaft 实现原理》第三篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-jraft-linear-consistent-read-implementation/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cfa43268e0ca8424ff44bd4397f720b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","publishdate":"2019-07-02T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","wordcount":4732},{"author":"绍辉","categories":"Seata","content":" 获取本次分享完整 PPT：下载地址\n本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。详细讲解了在分布式架构演进中，蚂蚁金服面对的跨服务、跨数据库的业务数据一致性问题以及应对措施，并分享了分布式事务 Seata 的 AT、TCC、Saga 和 XA 四种模式。\nSeata：https://github.com/seata/seata\n一、自研分布式事务解决数据一致性问题 1.1 分布式事务问题产生原因 1.1.1 数据库的水平拆分 蚂蚁金服的业务数据库起初是单库单表，但随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。所以我们对数据库进行了水平拆分，将原单库单表拆分成数据库分片。\n如下图所示，分库分表之后，原来在一个数据库上就能完成的写操作，可能就会跨多个数据库，这就产生了跨数据库事务问题。\n1.1.2 业务服务化拆分 在业务发展初期，“一块大饼”的单业务系统架构，能满足基本的业务需求。但是随着业务的快速发展，系统的访问量和业务复杂程度都在快速增长，单系统架构逐渐成为业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。\n如下图所示，蚂蚁金服按照面向服务（SOA）的架构的设计原则，将单业务系统拆分成多个业务系统，降低了各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。\n业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，如何保证多个服务间的数据一致性成为一个难题。\n1.2 蚂蚁金服遇到的数据一致性问题 在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。在分布式网络环境下，我们无法保障所有服务、数据库都百分百可用，一定会出现部分服务、数据库执行成功，另一部分执行失败的问题。\n当出现部分业务操作成功、部分业务操作失败时，业务数据就会出现不一致。以金融业务中比较常见的“转账”场景为例：\n如下图所示，在支付宝的“转账”操作中，要分别完成 4 个动作：\n 创建交易订单； 创建支付订单； A 账户扣钱； B 账户加钱； 而完成以上操作要分别访问 3 个服务和 4 个数据库。\n在分布式环境下，肯定会出现部分操作成功、部分操作失败的问题，比如：A 账户的钱扣了，但是 B 账户的钱没加上，这就造成了资金损失，影响资金安全。\n在金融业务场景下，我们必须保证“转账”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象。\n为了解决跨数据库、跨服务的业务数据一致性问题，蚂蚁金服自主研发了分布式事务中间件。\n从 2007 年开始做分布式事务并支持双十一，至今已经有 12 年。\n2013 年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014 年，蚂蚁金服分布式事务中间件 DTX(Distributed Transaction-eXtended)开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户。在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。所以在 2015 年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务（Distributed Transaction-eXtended，简称 DTX）链接：\nhttps://tech.antfin.com/products/DTX\n二、投入开源社区，共建开源分布式事务 Seata  2.1 分布式事务 Seata 介绍 Seata（Simple Extensible Autonomous Transaction Architecture，简单可扩展自治事务框架）是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。Seata 开源半年左右，目前已经有接近一万 star，社区非常活跃。我们热忱欢迎大家参与到 Seata 社区建设中，一同将 Seata 打造成开源分布式事务标杆产品。\nSeata：https://github.com/seata/seata\n2.2 分布式事务 Seata 产品模块 如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。\n在 Seata 中，分布式事务的执行流程：\n TM 开启分布式事务（TM 向 TC 注册全局事务记录）； 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）； TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）； TC 汇总事务信息，决定分布式事务是提交还是回滚； TC 通知所有 RM 提交/回滚 资源，事务二阶段结束。 2.3 分布式事务 Seata 解决方案 Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。\n2.3.1 AT 模式 今年 1 月份，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。\nAT 模式如何做到对业务的无侵入 ： 一阶段： 在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。\n 二阶段提交： 二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。\n 二阶段回滚： 二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。\nAT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。\n2.3.2 TCC 模式 2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段 执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。\nTCC 三个方法描述：\n Try： …","date":1562050800,"description":"本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。","dir":"blog/seata-distributed-transaction-deep-dive/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d87c4d85b8c16bfc24a0b9bea52b604d","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","publishdate":"2019-07-02T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","summary":"获取本次分享完整 PPT：下载地址 本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。详细讲解了","tags":["分布式事务","实践","开源","Seata"],"title":"Seata 分布式事务实践和开源详解 | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","wordcount":5775},{"author":"响风","categories":"SOFALookout","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23195297，不错过每场直播。\n 大家好，我是响风，来自蚂蚁金服， 现在是 SOFALookout 的开源负责人。本期 SOFAChannel 我给大家带来主题是《轻量级监控分析系统 SOFALookout 原理讲解和功能演示》的分享。本期的讲解内容如下将从以下四个部分展开：\n 监控预警基本概念介绍 SOFALookout 的客户端使用（包括系统设计简介与实现） SOFALookout 的服务端使用（包括系统设计简介与实现） SOFALookout 发展规划 欢迎大家 Star 我，SOFALookout：https://github.com/sofastack/sofa-lookout\n1 监控预警基本概念介绍 1.1 什么是 SOFALookout 现在我们开始第一部分，先介绍一些基本概念。6 月初，SOFALookout 服务端开源，具体内容可以查看相关文章：蚂蚁金服轻量级监控分析系统 SOFALookout 服务端开源，SOFALookout 客户端在之前也已经开源。目前整个系统是真正地可以玩转起来的，这里先介绍一下 SOFALookout。\nSOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。开源版本只提供对 Metrics 的处理部分：涵盖 Metrics 数据的产生，也就是 Metrics 的埋点、收集、加工、存储与查询等一系列服务。\n1.2 Metrics 的前置知识 介绍一些 Metrics 的前置知识：\n第一是时序数据，比较正式的解释是“基于稳定频率持续产生的一系列指标监测数据”。简单说横轴是时间，纵轴是数值的情况下，第一印象可以做成走势图的数据通常就是时序数据。比如 2009 年到 2018 年每年双十一天猫的成交额，就构成了时序数据。\n第二是标签（Tag），它用于表明指标项监测针对的具体对象。还是以刚才的成交额为例子，其实我们要监测的指标是“成交额”，但是“成交额”并没有标明要监测的对象，即谁的成交额，哪个省的成交额，也就是缺少“定语”。标签的作用就相当于是“定语”。比如“天猫的 浙江省的 成交额”，在代码中通常会有键值对来描述，比如 type=\u0026amp;ldquo;天猫\u0026amp;rdquo;，province=\u0026amp;ldquo;浙江\u0026amp;rdquo;。\n第三是时序数据库，即专门为存查时序数据而设计的数据管理系统。主要有以下几个特点：\n 写多读少 数据多维度，无 schema，需要多维度查询或聚合 通常无删除和更新操作， 或受限 以下是一些常见的开源时序数据库，由于篇幅关系，就不一一介绍了。\n Graphite InfluxDB OpenTSDB Prometheus 1.3 传统 Metrics 和 Metrics 2.0 的对比 下面再来看一下传统 Metrics 和 Metrics 2.0 的对比。\n1.3.1 传统 Metrics 传统 Metrics 是我对它的称呼，简单来说它只有 Name 和 Value，没有显式的 Tags 概念。比如 \u0026amp;ldquo;temperature = 29\u0026amp;rdquo;，温度=29，当然这里都省略了时间戳。这个表达式并没有指出监测对象，传统 Metrics 的做法是，将监测对象的信息编码到 Name 里，因此可能就变成了 \u0026amp;ldquo;temperature.hangzhou=29\u0026amp;rdquo;。这里是有一些隐式的 Tags 信息的，只是被编码到 Name 里了。\n这种做法很快会导致一个问题，我们来看下一个例子： shanghai.host1.foo.exporter.bar 。 只看这个名字的话几乎很难知道这个 Metrics 统计的是什么。这是因为它并没有把字段对应的 Key 编码到名字里，所以在缺少一些上下文的情况下，我们很难读懂它的含义。\n另外，字段的顺序也是很重要的，不能写错，这是因为编码到 Name 里的只有 Tag 的 Value，Key 不在里面，于是又有了另外一种编码方式：zone.shanghai.host.host1.app.foo.counters.exporter.bar 。这种方式将 Tag 的 Key 也编码在Name 里。但带来的问题也很明显：Name 越来越长。\n我们再看下一个例子： login.success.h5，它想表达来自 H5 平台登录成功的次数。假设我们还有其他平台，比如安卓、IOS，我们想求所有平台的总登录成功次数，那么就需要做一个聚合操作。通常时序数据库会提供型号来匹配所有值。\n其实上面这些都是旧版本 Graphite 的例子, 不过它在 2017 年底的版本支持了 Tags 概念，所以已经不能拿新版来当反面教材了。\n这是 Dropwizard 客户端的一个简单 Demo，它是一个很流行的 Metrics 埋点客户端，但是只能支持传统 Metrics 的概念。\nMetricRegistry registry = new MetricRegistry(); Counter h5Counter = registry.counter(\u0026amp;quot;login.success.h5\u0026amp;quot;); h5Counter.inc(); 1.3.2 Metrics 2.0 我们再来看 Metrics 2.0，其实 Metrics 2.0 也就只是多了 Tags 的概念，这里同样省略了 Timestamp。\n这是 OpenTSDB 风格的数据描述。\n{ \u0026amp;quot;metric\u0026amp;quot;: \u0026amp;quot;login.counter\u0026amp;quot;, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;result\u0026amp;quot;: \u0026amp;quot;success\u0026amp;quot;, \u0026amp;quot;platform\u0026amp;quot;: \u0026amp;quot;h5\u0026amp;quot; }, \u0026amp;quot;timestamp\u0026amp;quot;: 1560597254000, \u0026amp;quot;value\u0026amp;quot;: 100 } 这是 Prometheus 的描述方式。\ntemperature{city=\u0026amp;quot;hangzhou\u0026amp;quot;}=29 这是对应的 lookout-client 的埋点代码。\nRegistry registry = …; Id loginCounter = registry.createId(\u0026amp;quot;login.counter\u0026amp;quot;); Id id = loginCounter.withTags( \u0026amp;quot;result\u0026amp;quot;, \u0026amp;quot;success\u0026amp;quot;, \u0026amp;quot;platform\u0026amp;quot;, \u0026amp;quot;ios\u0026amp;quot; ); registry.counter(reqId).increment(); 可以看到它们都显式支持了 Metrics 2.0 的概念。\n这里我们花了点时间强调传统 Metrics …","date":1561705200,"description":"本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。","dir":"blog/sofa-channel-6-retrospect/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"27fcb53174efd0b72fcee578993cae38","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-6-retrospect/","publishdate":"2019-06-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-channel-6-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。 回顾视频以及 PPT 查","tags":["SOFALookout","SOFAChannel"],"title":"蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-6-retrospect/","wordcount":4165},{"author":"卓与","categories":"SOFAStack","content":" 本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。分享基于 Service Mesh 的理念，结合蚂蚁金服内部实际场景，将中间件、数据层、安全层等能力从应用中剥离出来后下沉至独立的 Sidecar SOFAMosn 中，结合 Kubernetes 运维体系，提供应用无感知的情况下升级基础设施层能力的案例。\n本次分享将从以如下次序展开进行：\n蚂蚁金服当前的服务化现状 在看蚂蚁金服的服务化架构之前我们先从一个简单的服务化调用示例说起，下图是 SOFARPC 基本原理：\n我们从上图可以看出，构建一个服务化框架需要有服务注册中心，有服务定义，调用方和服务提供方使用相同的服务定义来互相通讯。通过服务注册中心，调用方可以直接订阅到服务提供方的地址，采用点对点的方式直接发起请求。客户端内可实现服务发现、路由寻址、负载均衡、限流熔断等能力来增强服务通讯能力。通过我们开源的 SOFARPC、SOFARegistry、SOFABoot，用户已经可以直接构建起微服务体系，助力业务发展。\n蚂蚁金服发展至今，双 11 系统需要应对的交易洪峰逐年递增：\n每秒 26.5 万笔交易是 2017 年双 11 的峰值数据，这个数据背后有非常复杂的架构支持，LDC 单元化架构是蚂蚁金服沉淀多年的核心架构，依靠这个架构实现每年峰值交易量飞速增长下系统依然能平滑渡过。我们来简要看下 LDC 架构：\n上图摘自 金融级分布式架构 中的 素描单元化 一文，这里不详细展开。LDC 的单元化架构给应用的服务化带来更多的规范与抽象，服务路由中需要考虑单元间的调用，跨机房调用等更多场景。这里主要希望表达的是 LDC 架构给 RPC 调用带来更高的复杂度。\n服务化痛点 中间件版本升级 在上面介绍背景时，有介绍到目前 LDC 架构下服务调用的复杂度，这些复杂度目前是直接体现在应用的代码中。对于业务同学来讲，一个应用的关注重点是如何实现业务逻辑，至于高可用、容灾等能力更多是整体架构层面会考虑的点。应用内通过引入 RPC 的 jar 包即可获得 LDC 架构下服务调用各种能力的支撑，带来便利的同时也可以看到这种模式的缺点：\n应用内除业务逻辑之外，由中间件的 SDK 引入大量外部依赖，来完成服务发现、路由寻址、负载均衡、限流熔断、序列化、通讯等能力，每个组件的引入都可能带来稳定性风险，以及更高的升级成本。\n根据目前 SOFARPC 在内部的版本举例，服务发现依赖 SOFARegistry 的客户端做 IDC 内的服务发现，依赖 Antvip 做跨 IDC 的服务发现，ZoneClient 集成 LDC 架构的单元化信息，路由寻址需要根据请求的入参计算目前 Zone 然后确定调用目标，限流熔断依赖 Guardian 组件，通讯协议与序列化协议相对稳定，变更较少。仅为了完成服务调用，应用需要额外引入 7+ 客户端包。\n每年双 11 需要涉及到架构调整时：比如支持弹性架构，需要做很多中间件客户端的版本升级来支撑更优的架构，对于业务同学来讲，这些升级是很耗费精力的，拿 200 个核心应用举例，每个应用升级中间件版本经过研发、测试、再到部署预发、灰度、生产等环境需要 5个人日的话，200 个核心应用中间件升级需要耗费 1000 人日，如果这部分时间可以节省出来，每年架构升级可以节约大量人力资源。\n跨语言通讯 蚂蚁金服发展至今，内部业务百花齐放，搜索推荐、人工智能、安全等各种业务使用到的技术栈非常多样化，跨语言的服务通讯能力也十分重要。早在几年前，Java 之外规模最大的就是 NodeJS 应用，为了让 Java 和 NodeJS 应用之间可以复用蚂蚁金服内部的各种中间件和基础设施，前端团队使用 NodeJS 逐步重写了各种中间件客户端，让整个 NodeJS 和 Java 体系可以完美互通。\n中间件 SDK 跨语言重写与维护成本极高，随着语言种类的增多，跨语言通讯的诉求也越来越多。\nJava, NodeJS, Go, Python, C++ 等，5+ 语言，中间件 SDK 全部重写成本极高。这些问题不得不激励我们寻找更优的解法。\n解决痛点 SDK 能力下沉 依然以上述 RPC SDK 举例，SDK 中的能力我们可以根据稳定性与不可剥离等特性来看，哪些是可以从应用中抽出来的，尽量把 SDK 做薄，做的足够稳定无需变更，那么升级成本将不复存在。\nRPC SDK 中的服务发现、路由寻址、限流熔断等特性，是更易于变更的，我们将这部分能力下沉至独立的 Sidecar 中，可以复用这部分能力，让多语言的 SDK 只实现最基本的序列化与通讯协议，而这些能力是很轻量且易于实现的。这里的 Sidecar 我们是希望它作为独立进程存在，和业务应用的进程剥离，并和业务应用的升级解耦开来，实现业务和基础设施并行发展，互不干扰的愿景。\n除了 RPC 通讯，我们还可以下沉消息、数据源等能力至 Sidecar 中，业务应用可以越来越薄，SDK 实现成本也降低到可接受的程度，基础设施层与业务剥离，双方均可独立演进。\n落地架构 整体架构 不同于开源的 Istio 体系，蚂蚁金服内部版 Service Mesh 落地优先考虑数据面的实现与落地，控制面在逐步建设中，整体的架构上看，我们使用数据面直接和内部的各种中间件服务端对接，来完成 RPC、消息等能力的下沉，给业务应用减负。由上图可以看出，我们将不同的 Sidecar 与业务应用编排在同一个 Pod 中，App 与 Mosn 直接通讯，Mosn 来负责目标接口的服务发现、路由寻址，并且由 Mosn 内置的安全模块来做应用间调用的加密鉴权。通过 DBMesh 的 Sidecar 来实现数据层的下沉，App 不在需要与多个数据源建立连接，只需要连接本 Pod 内的 DBMesh 即可完成数据层调用，数据库的用户名、密码、分库分表规则等均不再需要关心。\n图中名词解析：\nConfigServer：配置中心，负责各种元数据配置、动态开关等。\nRegistry：服务注册中心，负责 IDC 内服务发现。\nAntVip：类 DNS 解析的产品，可通过域名解析一组目标地址，用于跨 IDC 服务发现。\nMQ：消息中心服务端，用于收发消息。\n落地数据 目前这套架构已经在支付核心链路中做试点，618 大促 Mesh 化应用对比无 Mesh 化应用 CPU 损耗增长 1.7%，单笔交易整体耗时增长 5ms。CPU 增长是由于多出一个进程，请求增加一条之后，RT 会有稳定的小幅增长，但这些成本相比于整体架构带来的红利，微乎其微，并且针对整个数据面的持续优化是有望逐步减少资源占用，提升资源利用率。\n降低打扰度 中间件能力下沉在架构上看是可行的，实际落地如何做到无打扰的在奔跑的火车上换轮子，低打扰是一个非常重要的考量点。借助于 Kubernetes 的优秀实践，将业务容器与 Sidecar 容器编排在同一个 Pod 中是比较合理的架构，Sidecar 与业务容器互不干扰，互相升级均可做到双方无感。\n我们为了让业务应用升级尽可能如丝般顺滑，主要做了 …","date":1561359600,"description":"本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。","dir":"blog/service-mesh-giac-2019/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7cfc7c8a7b735c31418186aae0ca99a2","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-giac-2019/","publishdate":"2019-06-24T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/service-mesh-giac-2019/","summary":"本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。","tags":["SOFAStack","Service mesh"],"title":"蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-giac-2019/","wordcount":4572},{"author":"雾渊","categories":"SOFAArk","content":"  本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。感谢溢米教育对 SOFAStack 的支持，同时也欢迎更多用户投稿 Join us。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服开源贡献。\n写在前面 个性化推荐，相信大家都不陌生，简单来说就是根据每个人的偏好经过模型计算推荐出适合的东西，这些东西可以是视频、商品、文章、电影等。经过互联网这几年的发展，个性化推荐已经无处不在，不管是电商、教育、游戏、金融行业，推荐系统对业务的提升都有着非常重要的帮助。溢米教育作为一家互联网教育平台，近几年推荐业务发展非常迅速，技术团队也在持续的进行能力提升。业务快速增长的同时，亟需一个高效率、高稳定的推荐系统来支持推荐场景。\n本文是根据我们内部推荐平台效率与稳定性建设的实际经验整理，介绍了溢米教育推荐系统的改造优化。在整个过程中我们基于公司架构做了分析，确认了技术选型和改造方案，最终选择基于 SOFAStack 社区开源的 SOFAArk 组件开发框架，极大的提升了我们推荐系统的开发效率和稳定性。希望能给有同样困扰的技术团队参考。\n背景 一次完整的个性化推荐，通常包括召回、过滤、排序等步骤。虽然步骤不多，但是涉及到的逻辑是非常多的，包括 abtest、用户画像、物品画像、离线数据、在线数据、模型系统、字段补全等等。个性化推荐极为依赖场景定制化，不同的场景对应不同的处理逻辑。\n我们可以想象，把这一堆处理逻辑都放在一个系统里面，应用会变得十分臃肿和复杂，随着业务系统不断的迭代更新，逐渐会变得难以维护，开发效率和系统稳定性都会面临不小的挑战。不幸的是，随着溢米业务快速发展，内部的推荐平台已经变得 “过劳肥”。不管是迭代效率、性能、稳定性都遇到了瓶颈，比如：\n 发布耗时：算法团队一个人跟进一条业务线，导致业务迭代频繁、应用发布非常频繁，由于系统本身复杂性，这么一个庞然大物发布一次非常慢，降低了工程师效率；\n 系统臃肿：所有模块统一维护，包含了存储、算法、业务等，几乎每次迭代都是只增不减，降低了系统可维护性；\n 覆盖风险：多个团队共同维护一份代码，分支上容易存在冲突，合并代码存在覆盖风险，降低了团队合作效率；\n 版本不一致：不同业务团队使用的 jar 包版本不一致，每次升级一个 jar 包都会引起很多问题，导致各个团队在开发期间都要花费不少精力解决依赖冲突；\n 基于上述背景，溢米推荐平台不得不进行应用瘦身和系统改造，从而提升平台的开发效率和稳定性。然而在实际的改造过程中，我们不难发现这两者其实是互相冲突的。为了提高稳定性，我们肯定要做到流程上的把控，比如测试、灰度、发布等流程的规范，这势必会影响业务迭代效率；反过来如果要提升效率，那么在流程上肯定会有一定的舍弃，随之而来的是稳定性的潜在风险。 但是人总是需要梦想驱动的，每个工程师都希望能用一种架构或者方案，同时解决很多通用的问题，节约成本，提升效率， 让设计人员能够不至于疲于奔命， 解放生产力来完成更多有创新有挑战的工作。\n调研 效率和稳定性并非一定是二选一，在进行推荐平台升级改造之前，我们梳理了溢米内部影响业务效率和系统稳定性的主要因素。\n 开发效率 系统稳定 影响因素 业务复杂度+开发复杂度 业务变更：代码变更+数据变更 业务迭代流程+开发流程 非业务变更：配置变更+代码变更 业务变更+服务变更上线 流量变化 稳定性流程 硬件故障 关于开发效率，从上面可以看出来除了开发部分是依赖平台所能提供的便利和开发者个人技术能力之外，其余大部分都是流程上的把控。这些流程上的把控一是为了保障业务迭代的正确性，二是为了提升业务迭代带来的线上服务稳定性，但是简单的流程不足以把控住这些点，而过度复杂的流程会很大程度上影响业务迭代效率，所以我们需要思考并且寻求一种平衡，比如如何降低业务开发复杂度？如何提升平台提供的便利？如何在不影响稳定性的情况下简化业务迭代和维护流程？\n关于稳定性，我列举几个在溢米内部遇到的几个类似案例：\n 推荐服务性能优化上线，功能性测试没有问题，但是没有经过压测导致高峰期服务能力下降，最终导致整个服务不可用，而上游由于没有做好服务治理也受影响变成了服务不可用； 推荐服务所依赖的某个数据源或者 RPC 响应从 10ms 突然增长到 100ms，从而导致推荐服务主要线程池耗尽，最终导致服务不可用； 上游压测或者流量推广或者爬虫导致流量激增，但是推荐服务没有做好限流导致服务被打垮而不可用； 推荐系统依赖业务系统提供的RPC服务进行过滤，由于此RPC服务变更导致响应变慢，而推荐服务没有区分强弱依赖导致整体服务超时； 某个业务由于排期时间紧张，测试周期太短，上线后导致其它业务异常； 结合这些案例和上文总结的系统稳定性影响因素，可以发现除了硬件故障是不可控之外，其余几点基本都是因为变更而引起的。那么如何不受变更影响而提升稳定性呢？上面我们介绍过最主要也是最有效的是变更流程控制，通过测试、灰度、发布流程规范，其余也可以通过技术手段来控制，比如性能优化、服务治理、业务隔离、强弱依赖区分、多机房容灾、扩容等等。\n针对以上开发效率和稳定性分析，最开始确定如下了改造目标：\n 场景模块化 系统瘦身，拆分模块，提高系统可维护性 模块复用，提升开发效率 模块开发时隔离 各模块单独迭代开发，解决之前统一迭代开发的代码冲突问题 各模块单独测试，提升测试效率 模块运行时隔离 模块运行时类隔离，解决模块间包冲突问题 模块间有明确的服务边界，一定程度的故障隔离 模块动态可插拔 动态升级，秒级发布回滚 改造 为了满足改造目标，我们初步确认了三个选择：\n 采用自定义 SPI 的 ServiceLoader 动态加载实现； 采用自定义 Classloader 实现； 寻求开源软件支持。 基于资源成本、时间成本的考虑，我们选择了寻求开源支持，蚂蚁金服开源其分布式架构吸引了我们的关注，经过技术判断，我们最终决定使用 SOFAStack 社区开源的 SOFAArk 组件开发框架。\nSOFAArk 定义了一套相对简单的类加载模型、特殊的打包格式、统一的编程界面、事件机制、易扩展的插件机制等，从而提供了一套较为规范化的插件化、组件化的开发方案。更多内容可以参考官方文档：\nSOFA JVM 服务： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-ark-jvm\nSOFAArk 官方文档： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-readme\nSOFAArk 源码： https://github.com/sofastack/sofa-ark\n通过 SOFAArk+SOFABoot 的组合，我们将应用进行拆分，分为宿主应用+数据模块+业务模块：\n 主应用：负责整个容器的状态保持； 数据模块：负责数据通信，包括 Redis，DB，RPC 等基础服务； 业务模块：只需要负责调用数据模块进行业务实现， …","date":1560409200,"description":"本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。","dir":"blog/sofastack-user-yimi/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"967e9a815b24a3b000d5ecd90c59b8fb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-user-yimi/","publishdate":"2019-06-13T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofastack-user-yimi/","summary":"本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。感谢溢米教育对 SOFAStack 的支持，同时也欢迎更多用户","tags":["SOFAArk"],"title":"溢米教育推荐平台的效率与稳定性建设 | SOFAStack 用户说","type":"blog","url":"/sofastack.tech/blog/sofastack-user-yimi/","wordcount":3303},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 活动时间：6 月 12 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 6 月 27 日周四晚 7 点，将邀请 蚂蚁金服 SOFALookout 开源负责人 响风 为大家分享，通过对多个模块的剖析，详解 SOFALookout 服务端以及客户端，带你了解 SOFALookout 具体是如何支持主流 Metrics协议的数据收集、存储、查询计算和可视化的。欢迎报名参加~\nSOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务，提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\n本期分享大纲：\n 监控预警基本概念介绍 SOFALookout 客户端使用 Gateway - 多协议数据收集与处理的设计与实现 Server - PromQL 与多种存储层的设计与实现 SOFALookout 发展路线 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/687\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 轻量级监控分析系统 SOFALookout 原理讲解和功能演示 响风 蚂蚁金服轻量级监控分析系统 SOFALookout 开源负责人\n本期分享大纲： 监控预警基本概念介绍 SOFALookout 客户端使用 Gateway - 多协议数据收集与处理的设计与实现 Server - PromQL 与多种存储层的设计与实现 SOFALookout 发展路线 嘉宾 SOFAGirl 主持人 响风 蚂蚁金服轻量级监控分析系统 SOFALookout 开源负责人 ","date":1560312000,"description":"6 月 12 日周四晚 7 点，线上直播第 6 期。","dir":"activities/sofa-channel-6/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"29a5673d4608770bbe7598954fcecc78","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-6/","publishdate":"2019-06-12T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-6/","summary":"概要 活动主题：SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 活动时间：6 月 12 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直","tags":["SOFAChannel","SOFALookout"],"title":"SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示","type":"activities","url":"/sofastack.tech/activities/sofa-channel-6/","wordcount":637},{"author":"卿祤、 首仁","categories":"SOFAStack","content":" 由蚂蚁金服主办的 SOFAStack Cloud Native Workshop 将在 6月24日于 KubeCon + CloudNativeCon + Open Source Summit China 大会的同场活动中进行，欢迎报名参与，更多信息可见此链接。 欢迎加入 SOFA 钉钉互动群（钉钉搜索群号）：23195297\n 楔子 为支撑业务高速发展并积极拥抱主流技术，我们从 2017 年开始探索并构建以Kubernetes为核心的云原生应用 PaaS 平台。在 2018 年，我们已在网商银行顺利落地了 K8S 容器引擎，并顺利支撑了 2018 年双十一。2019 年伊始，国泰产险作为互金行业的典型代表，正基于 SOFAStack 容器应用服务和监控分析产品探索云原生架构转型。时至今日，已完成了关键业务 SOFABoot 应用的容器化改造，在开发、测试乃至灰度生产环境践行云原生的运维实践。\n这将是一系列技术分享文章的开端，基于在实际金融机构和场景中落地的云原生产品项目经验，我们希望和大家一起分享从中获得的洞察和总结，探讨我们的产品观点、技术实现，并非常期待大家的建议和指点，欢迎一起交流共创。\n云原生容器产品的金融机构落地挑战 从去年开始，云原生、Kubernetes、容器这些关键字逐渐从社区走向金融科技圈，越来越多的金融机构客户开始向我们咨询，云原生技术是什么，能够给企业带来什么价值，对现有业务有什么影响？落地的路径可能会是哪些？\n我们的观点是，金融场景下的云原生，绝对不止是 12Factors，亦不止是 CNCF TOC 所定义的 5 大件，我们不仅要提供标准、通过一致性认证的 Kubernetes 产品，还需要满足更多金融场景需求，创造实际业务价值。\n经过很长一段时间的产品研发实践、深挖内外容器平台落地诉求，金融客户的关注点可能包括但不限于以下几点：\n 业务采用了云原生能否节省资源，提升工程效率？ 发现问题后如何做到快速止损，甚至线上零故障？ 如何在云原生下做到业务同城双活甚至异地多活的高可用容灾能力？ 能否和现有业务能无缝集成，如何做平滑升级？ 采用了云原生平台能否保证和现有云上一致的安全性？ 云原生能否支撑大规模分布式系统的架构？ \u0026amp;hellip; 而基于以上实际场景下的落地挑战，我们对自身容器平台产品的设计和实施，提出了以下六大关键价值主张：\n云原生容器产品的价值主张 一 使用 Immutable Infrastructure 的思想进行设计 在 PaaS 平台中，核心是应用。在之前的经典运维体系中，要对应用打一个全量快照不是件容易的事情，但在云原生世界中，会方便许多。从描述流量接入层的 Service 到描述应用配置和代码包的 Pod template，这些已是 kubernetes 的标准 Resources。\n为了解决应用管理需求，我们定义了一个 CafeAppService 对象，用于整体描述上述内容，并通过 Revision 对象属性作版本控制（和 Knative 中的 Revision 类似）。用户每次的修改都是一个 Revision，发布一个应用本质上是发布该应用的一个 Revision，故可做到快速的弹性扩缩容，并且可以方便回滚到之前发布成功过的 Revision。相比之前基于包的经典发布运维体系，效率有极大提升。\n二 可审计和无损应用发布的能力 发布变更是 PaaS 平台提供的重要能力。对于金融客户来说，每次发布必须要有据可查，而且要保证安全无损。这里，我们将蚂蚁的安全生产理念融入其中，在产品层面上提供“可灰度，可回滚（应急），可监控”的能力。\n为了做到上述能力，我们提供了发布单的概念，并定义了一个原生的 CRD：CafeDeployment。接下来逐一介绍。\n发布单 主要两个用途：做应用发布的审查记录，用于统计分析，故障复盘回顾等；协调多个应用的发布顺序，这是由于金融业务对系统的可靠性要求高，尤其在涉及资金的主链路，另外，不少系统由于业务原因，存在依赖关系，必须做有序发布。\nCafeDeployment 在这里只做简单介绍，后续会有专题介绍。该 CRD 拥有三种能力：\n 原地升级（InplaceSet）:升级过程中 Pod 的 IP 保持不变，可和经典的运维监控体系做无缝集成。 替换升级（ReplicaSet）:和社区版本的 ReplicaSet 能力保持一致。 有状态应用（StatefulSet）:和社区版本的 StatefulSet 能力保持一致。 除此之外，相比社区的 deployment，还具备 beta 验证，自定义分组策略，分组暂停，引流验证（配合 ServiceMesh）的能力。\n三 具有高可用容灾能力的工作负载 金融业由于监管的要求对系统可用性和容灾能力具有很高的要求。从应用的生命周期来看，最主要有两个状态：发布态 和 运行态。\n对于发布态，由于存在 Pod 上下线的过程，线上有抖动不可避免，要做的是尽可能的降低抖动幅度以及降低系统报错率。kubernetes 的 deployment 在发布一个 pod 时，pod 里容器的 kill 和对应 endpoint 的销毁是异步的，这就意味着可能出现 pod 里应用容器已经 kill 了，但仍然会有流量打到该 Pod，导致出现报错，甚至故障。为了防止这种情况，我们采用 finalizer 的机制，保证在南北流量和东西流量（7 层协议）都切断的情况下才对 Pod 进行更新。\n同时，还通过 CafeDeployment 里的灰度发布策略，保证发布态时线上系统的水位不会过低，防止出现流量过载，造成系统异常。\n对于运行态，要考虑以下几个方面：Pod 异常退出后的重新上线，Node 故障后的 Pod 的迁移，机房级故障后系统仍然可用。对于第一点，Kubernetes 本身已经有了较好的机制；第二点，我们做了增强，使用自定义的 NodeLifecycle Controller 结合更加详细的监控信息来判断Node是否出现故障，然后做 Pod 迁移；第三点，从 Scheduler 方面进行保障，CafeDeployment 可以定义相应的高可用拓扑结构，以同城双活为例，在创建 Pod 时，调度器会根据定义好的拓扑信息尽量将 Pod 均分到不同的可用区，达到同城双活的状态。\n四 一致的验证授权体验 蚂蚁金服 PaaS 平台在近 4 年的时间里，已经有了一套完整的 IAM 体系，并且许多客户已经基于此定义了许多的角色，用做安全防护。我们从两方面来提供一致性的体验：\n首先，在产品上的操作上提供和原先一样的验证授权机制。只要客户将 K8S 内预先定义好的角色或者权限分配相应的用户或用户组，那该用户或者属于该用户组的用户就能在产品上做相应的操作。\n其次，IAM 的权限和角色与 Kubernetes 的 RBAC 做映射。根据用户在 IAM 所具备的角色，在 Kubernetes 集群中创建相应的 ClusterRole，并生成访问 Kubernetes 集群的 token，创建 ClusterRoleBinding 与 token 绑定。这样用户使用 kubectl 操作集群时也可以具备相同的权限，保证权限 …","date":1559890800,"description":"这将是一系列技术分享文章的开端，基于在实际金融机构和场景中落地的云原生产品项目经验，我们希望和大家一起分享从中获得的洞察和总结，探讨我们的产品观点、技术实现，并非常期待大家的建议和指点，欢迎一起交流共创。","dir":"blog/sofa-financial-cloud-native-exploration/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9c93781d7d4b980b1990e4655445d4bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","publishdate":"2019-06-07T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","summary":"由蚂蚁金服主办的 SOFAStack Cloud Native Workshop 将在 6月24日于 KubeCon + CloudNativeCon + Open Source Summit China 大会的同场活动中进行，欢迎报名参与，更多信息可见此链接。 欢迎加入 SOFA 钉钉互动群（钉钉搜","tags":["SOFAStack"],"title":"金融级云原生探索实践系列 - 开篇","type":"blog","url":"/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","wordcount":3874},{"author":"墨睿","categories":"SOFALookout","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFALookout 是在 SOFAStack 体系内研发开源的一款解决系统的度量和监控问题的轻量级中间件服务。本文给大家介绍下 SOFALookout 服务器端主要提供的特性以及使用方式。 SOFALookout：https://github.com/sofastack/sofa-lookout\n 前言 容器，K8S，微服务，Mesh 以及 Serverless 这些新技术方向正在根本的变革我们运行软件的方式。我们构建的系统更加分布式化，另外由于容器，系统的生命周期更加短，变得易逝。针对这些变化，SOFALookout 希望提供一套轻量级解决方案。之前 SOFALookout 已经开源客户端的能力。今天，SOFALookout 服务器端 Metrics 部分的代码终于正式开源啦！本文给大家介绍下 SOFALookout 服务器端的主要特性以及使用方法。\n什么是 SOFALookout SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\nSOFALookout 目标是打造一套轻量级 Observability 实时工具平台，帮助用户解决基础设施、应用和服务等的监控和分析的问题。SOFALookout（目前已开源部分） 是一个利用多维度的 metrics 对目标系统进行度量和监控的项目。SOFALookout 的多维度 metrics 参考 Metrics2.0 标准。\nSOFALookout ：https://github.com/sofastack/sofa-lookout\nSOFALookout 安装文档：https://www.sofastack.tech/sofa-lookout/docs/quickstart-metrics-server\n SOFALookout 服务器端的主要特性:\n 适配社区主要 Metrics 数据源协议写入（比如: Prometheus，Metricbeat 等）； 数据的存储支持扩展，暂时开源版默认支持 Elasticsearch， 并且透明和自动化了相关运维操作； 遵循 Prometheus 查询 API 的标准以及支持 PromQL，并进行了适当改进； 自带数据查询的控制台，并支持 Grafana 进行数据可视化； 使用简单，支持单一进程运行整个服务器端模块。 随着 SOFALookout （metrics）服务器端代码开源，metrics 数据的处理已经形成闭环。后续我们将会进一步开源 Trace 和 Event 相关的服务能力，敬请期待。\nSOFALookout 项目结构 服务器端代码分别包括两部分：Gateway 模块和 Server 模块。如下图所示（展示了 SOFALookout 源码项目的模块概要结构）\n├── boot ├── client ├── gateway └── server 项目中的 boot 模块作用是方便集成和运行服务端的模块，既可以单独运行 Gateway 和 Server 的服务，也可以借助 SOFAArk 完成（Gateway 和 Server）的 All in One 的合并为单一进程运行。\nSOFALookout 工作机制 下图完整展示了 SOFALookout 如何从 metrics 数据采集、上报、存储到最终展示的完整流程路径。\n目前 SOFALookout 支持灵活的 metrics 数据存储选型。但开源版本我们暂时只支持了 Elasticsearch 作为存储的方案（后续可能继续支持 Cassandra,InfluxDB\u0026amp;hellip;），其他存储地适配我们希望更多同学能参与共建和支持。优先支持 Elasticsearch 是因为我们考虑到了 ELK 解决方案在业界已经广泛使用，尤其是日志数据。\n为了开箱即用，同时考虑到不熟悉 Elasticsearch 的同学的使用，SOFALookout已经内置了关于 metrics 数据存储的自动化运维工具，可以免除大家自己建 Index，和日常维护 ES Index 的麻烦，更多细节后续单独讲解。\n本次新增开源模块 一、SOFALookout Gateway 模块 SOFALookout Gateway 轻量的数据管道，它提供丰富的协议接入支持，包括自有SDK（SOFALookout Client）上报协议，还支持 Prometheus 的数据协议（推模式和拉模式），Metricbeat 协议（版本是6），OpenTSDB 写入协议。每种数据来源对应于一个 Importer 的概念。\nSOFALookout Gateway 对于远程（推模式）上报提供本地硬盘缓冲的支持。Gateway 总体设计是围绕数据加工的Pipeline 形式，包括前置后置的数据过滤器方便进行开发者数据加工。 另外 Gateway 可以支持自定义 Exporter，默认提供了 Elasticsearch Exporter，Standard Exporter(用于 Gateway 间数据中继)，开发者也可以自定义其他存储的 或 Kafka 等各式各样 Exporter。\n二、SOFALookout Server 模块 SOFALookout Server 兼容和增强了 Prometheus 的数据及元数据查询的 RESTful API。同样对应 PromQL 我们也基本实现了兼容和增强（不包括 Alert 相关语法），SOFALookout 的 promQL 相关解析逻辑是从 Prometheus 移植而来，做了一些优化和改进， 感谢 Prometheus 开源了如此易用和强大的 golang 版本的 QL 实现。\n为了方便方便开发者做数据探索和试验，我们也提供了自有 Web-UI 的支持，能够满足基本功能使用。\n我们还是推荐大家使用 Grafana 进行数据展示。Grafana 集成 SOFALookout 很简单，只需要选择 Prometheus 作为数据源协议即可（SOFALookout默认查询端口也是: 9090）。下图展示 Grafana 新增数据源配置：\n近期计划 下图是近期的 Roadmap：\n非常欢迎更多同学参与 SOFALookout 共建，尤其是支持更多的 Metrics 存储库。\n","date":1559804400,"description":"本文给大家介绍下 SOFALookout 服务器端主要提供的特性以及使用方式。","dir":"blog/sofa-lookout-server-open-source/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d80fe27f8652b6e8a8da8d712a90a027","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-lookout-server-open-source/","publishdate":"2019-06-06T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-lookout-server-open-source/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFALookout 是在 SOFAStack 体系内","tags":["SOFALookout"],"title":"轻量级监控分析系统 SOFALookout 服务端开源","type":"blog","url":"/sofastack.tech/blog/sofa-lookout-server-open-source/","wordcount":1970},{"author":"Jimmy Song","categories":null,"content":" SOFAStack Cloud Native Workshop hosted by Ant Financial (KubeCon China 2019 Co-Located Event) Date: Monday, 24 June, 2019 Time: 9:00 – 16:00 Location: Shanghai Expo Centre Room 616 Registration Fees: Complimentary Register here: https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop Note: This event is hands-on, please bring your personal computer. The language of communication in this workshop is Chinese. SOFAStack (Scalable Open Financial Architecture Stack) is a financial-grade distributed architecture independently developed and open sourced by Ant Financial. It contains the components required to build a financial-grade cloud native architecture. It is a best practice tempered in financial scenarios. SOFAStack official website: https://www.sofastack.tech/\nAttendees can get:\n Rapidly build microservices based on SOFAStack Best Practices for Distributed Transactions in Financial Scenarios Cloud native deployment experience based on Kubernetes Service Mesh basic usage scenario experience on the cloud Get started on Serverless apps Easily build applications on the cloud based on Serverless How to Register: Pre-registration is required. To register for SOFAStack Cloud Native Workshop, add it on during your KubeCon + CloudNativeCon + Open Source Summit registration. You can get KubeCon half price tickets with KCCN19COMATF coupon code!\nFor questions regarding this event, please reach out to jingchao.sjc@antfin.com.\nEvent details 9:00 - 9:20 Opening speech SOFAStack Cloud Native\n9:20 - 10:10 Quickly build microservices with SOFAStack by Jie Cao\nBuilding a microservices application based on the SOFAStack. Through this workshop, you can learn how to report application monitoring data, service link data, and publish and subscribe services in the SOFAStack.\n10:15 - 11:05 SOFABoot dynamic module practice by Guolei Song\nIn this workshop, you can implement the combined deployment and dynamic module push capabilities provided by SOFAArk based on the ARK control capabilities of SOFADashboard.\n11:10 - 12:00 Using Seata to guarantee the consistency of payment by Long Chen\nUnder the microservice architecture, the distributed transaction problem is an industry problem. Through this workshop, you can understand the background of distributed transaction problems under distributed architecture, as well as common distributed transaction solutions and experience on how to use the open source distributed transaction framework - Seata\u0026amp;rsquo;s AT mode, TCC mode to solve the ultimate consistency of the business data.\n12:00 - 13:00 Lunch time\n13:00 - 13:30 Cloud Native exlporation and practice in Ant Fnancial by Renjie Yu\n13:30 - 14:40 Migrating to cloud based on Serverless by Yitao Dong\nAs one of the pioneering technologies of cloud technology, Serverless architecture allows you to further improve resource utilization and focus on business development. Through our workshop, you can experience new product …","date":1559643600,"description":"","dir":"activities/sofastack-cloud-native-workshop/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"57c6b0262af34c2010179000834d8363","permalink":"https://sofastack.github.io/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","publishdate":"2019-06-04T10:20:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","summary":"SOFAStack Cloud Native Workshop hosted by Ant Financial (KubeCon China 2019 Co-Located Event) Date: Monday, 24 June, 2019 Time: 9:00 – 16:00 Location: Shanghai Expo Centre Room 616 Registration Fees: Complimentary Register here: https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop Note: This event is hands-on, please bring your personal computer. The language of communication in this workshop is Chinese. SOFAStack (Scalable Open Financial Architecture Stack) is a financial-grade distributed architecture independently developed and open sourced by Ant Financial.","tags":["KubeCon","Workshop","Cloud Native"],"title":"KubeCon China 2019 Co-Located Event SOFAStack Cloud Native Workshop","type":"activities","url":"/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","wordcount":515},{"author":"宋净超","categories":null,"content":" 蚂蚁金服 SOFAStack 云原生工作坊（KubeCon China 2019 同场活动） 日期：2019年6月24日，星期一 时间：9:00 – 16:00 地点：上海世博中心 616 房间 注册费：免费 注册地址：https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop 备注：本次活动为动手实践，请携带个人电脑。本沙龙沟通语言为中文。 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发并开源的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。SOFAStack 官方网站：https://www.sofastack.tech/\n参加此次 Meetup 您将获得：\n 基于 SOFAStack 快速构建微服务 金融场景下的分布式事务最佳实践 基于 Kubernetes 的云原生部署体验 云上的 Service Mesh 基本使用场景体验 基于 Serverless 轻松构建云上应用 如何注册：此活动须提前注册。请将 SOFAStack Cloud Native Workshop 添加到您 KubeCon + CloudNativeCon + Open Source Summit 的注册表里。您可以使用 KCCN19COMATF 折扣码获取 KubeCon 半价门票！\n如果对此活动有任何疑问，请发送邮件至 jingchao.sjc@antfin.com。\n活动详情 9:00 - 9:20 开场演讲 SOFAStack 云原生开源体系介绍 by 余淮\n9:20 - 10:10 使用 SOFAStack 快速构建微服务 by 玄北\n基于 SOFA 技术栈构建微服务应用。通过本 workshop ，您可以了解在 SOFA 体系中如何上报应用监控数据、服务链路数据以及发布及订阅服务。\n10:15 - 11:05 SOFABoot 动态模块实践 by 卫恒\n在本 workshop 中，您可以基于 SOFADashboard 的 ARK 管控能力来实现 SOFAArk 提供的合并部署和动态模块推送的功能。\n11:10 - 12:00 使用 Seata 保障支付一致性 by 屹远\n微服务架构下，分布式事务问题是一个业界难题。通过本workshop，您可以了解到分布式架构下，分布式事务问题产生的背景，以及常见的分布式事务解决方案；并亲身体验到如何使用开源分布式事务框架Seata的AT模式、TCC模式解决业务数据的最终一致性问题。\n12:00 - 13:00 午餐时间\n13:00 - 13:30 蚂蚁金服的云原生探索与实践 by 首仁\n13:30 - 14:40 通过 Serverless 快速上云 by 隐秀\n作为云原生技术前进方向之一，Serverless 架构让您进一步提高资源利用率，更专注于业务研发。通过我们的 workshop，您可以体验到快速创建 Serveless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错、按时间触发应用等产品新功能。\n14:50 - 16:00 使用 CloudMesh 轻松实践 Service Mesh by 敖小剑\nService Mesh 将服务间通信能力下沉到基础设施，让应用解耦并轻量化。但 Service Mesh 本身的复杂度依然存在，CloudMesh 通过将 Service Mesh 托管在云上，使得您可以轻松的实践 Service Mesh 技术。通过我们的 workshop，您可以快速部署应用到 CloudMesh ，对服务进行访问，通过监控查看流量，体验服务治理、Sidecar管理和对服务的新版本进行灰度发布等实用功能。\n","date":1559643600,"description":"","dir":"activities/sofastack-cloud-native-workshop/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"57c6b0262af34c2010179000834d8363","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofastack-cloud-native-workshop/","publishdate":"2019-06-04T10:20:00Z","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofastack-cloud-native-workshop/","summary":"蚂蚁金服 SOFAStack 云原生工作坊（KubeCon China 2019 同场活动） 日期：2019年6月24日，星期一 时间：9:00 – 16:00 地点：上海世博中心 616 房间 注册费：免费","tags":["KubeCon","Workshop","Cloud Native"],"title":"KubeCon 上海同场活动 SOFAStack Cloud Native Workshop","type":"activities","url":"/sofastack.tech/activities/sofastack-cloud-native-workshop/","wordcount":1134},{"author":"卫恒","categories":"SOFAMeetup","content":" 作者：卫恒（宋国磊），SOFATracer 以及 SOFADashboard 开源负责人。\n本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，着重分享如何使用 SOFADashboard 来管控 SOFAArk ，对于 SOFAArk 中的一些基础概念和知识不过多涉及；建议大家在阅读之前，先了解下 SOFAArk 的相关基本知识。\n现场回顾视频以及 PPT 见文末链接。\n前言 SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署能力，由蚂蚁金服开源贡献。SOFAArk 在 0.6.0 版本 提供了非常丰富的功能特性，其中最核心的当属多应用（模块）合并部署这个能力。SOFAArk 本身提供了多种方式来支持多应用（模块）合并部署 ，包括基于命令行的管控，基于 API 的管控等。本篇将结合 SOFA 开源的管控端组件 SOFADashboard，来实现 SOFAArk 提供的合并部署和动态模块推送的功能。\n案例工程地址\n背景 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n案例模型 本篇所演示案例是上图的一个简化版，从整体上可以体现 SOFAArk多应用合并部署的能力。主要包括已经几个工程：\n sofa-dashboard-ark-hostapp : 宿主应用 sofa-dashboard-ark-facade : 提供接口 API sofa-dashboard-ark-provider ：提供接口 API 的具体实现，将发布一个 JVM 服务 sofa-dashboard-ark-hostapp 和 sofa-dashboard-ark-provider 均作为 SOFAArk 中的 ark-biz 存在；sofa-dashboard-ark-hostapp 作为宿主应用对外提供服务。\n上图的模型中，在宿主应用不重启的情况下，实现 provider 模块的动态替换，从而实现版本升级。\n 在宿主应用启动时，provider 1.0.0 以静态合并部署方式“寄宿”到宿主应用中，这部分实际上与 SOFADashboard 管控是没有什么关系的，为了案例效果，在下面的案例中，关于静态合并部署的操作也会涉及到。\n 最终的工程结构图如下：\n环境准备 本文需要启动 SOFADashboard 服务端，具体请参考 : Quick Start ；其他基础设施环境如 Zookeeper 、Mysql 等需提前准备。\n工程构建 本篇将通过 step by step 的方式来构建整个工程，为大家在实际的应用过程中提供一种简单的思路，同时也帮助大家更好的理解 SOFAArk 中的一些点。\nsofa-dashboard-ark-facade 基础 API 提供模块，不需要依赖任何其他二方或者三方 JAR，这里仅提供一个接口。\npublic interface SofaJvmService { String test(); } sofa-dashboard-ark-provider 这个模块是 JVM 服务的提供方，也是后面需要在宿主应用中进行替换演示的模块包，这个模块本身也是一个 Web 应用。这里就来一步步分解下，如何将一个普通的 SpringBoot 工程改造成一个 ark-biz 工程。\n1、新建一个 SpringBoot 工程 新建 SpringBoot 工程推荐的方式有两种，一种是在 https://start.spring.io/ 进行下载，另外一种是基于 IDEA 的 Spring 插件来生成；此处不在过多描述过程。\n2、工程基本能力实现 引入 sofa-dashboard-ark-facade 依赖，先将需要提供的 JVM 服务实现： @SofaService @Service public class SofaJvmServiceImpl implements SofaJvmService { @Override public String test() { return \u0026amp;quot;first version biz\u0026amp;quot;; } } NOTE: SofaService 的作用是将一个 Bean 发布成一个 JVM 服务， 所以这里需要加上 Spring 提供的 @Service 注解将 SofaJvmServiceImpl 标注为一个 Bean。\n 配置文件： spring.application.name=biz-ark-test server.port=8800 logging.path=./logs 3、配置打包插件，将应用打包成 ark-biz  根据官方文档，可以使用 sofa-ark-maven-plugin 插件将一个普通的工程打包成一个 ark biz 包。这里直接给出本篇中工程的配置：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!--ark-biz 包的打包配置 --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- ark-biz 包的启动优先级，值越小，优先级越高--\u0026amp;gt; …","date":1559286000,"description":"本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，着重分享如何使用 SOFADashboard 来管控 SOFAArk ，对于 SOFAArk 中的一些基础概念和知识不过多涉及。","dir":"blog/sofa-meetup-2-2-retrospect/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"61a156b1a9f1a80f555200bfea5a20b6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","publishdate":"2019-05-31T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","summary":"作者：卫恒（宋国磊），SOFATracer 以及 SOFADashboard 开源负责人。 本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，","tags":["SOFAMeetup","SOFAArk","SOFADashboard"],"title":"基于 SOFAArk 和 SOFADashboard 实现动态模块管控 | Meetup#2 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","wordcount":3608},{"author":"玄北","categories":"SOFAStack","content":" 本文作者：玄北（曹杰），蚂蚁金服 SOFAStack 开源组核心成员。\n本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理，主要来聊聊 spring-cloud-antfin 包含的主要特性及如何使用 SOFAStack 和 SpringCloud 快读构建微服务系统。\n现场回顾视频以及 PPT 见文末链接。\n概念 Spring Cloud 是 Spring 社区开源的一套微服务开发框架，帮助开发人员快速构建分布式应用，Spring Cloud 的官网介绍如下：\n Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state).\n 蚂蚁金服从 2007 年开始在公司内部使用 SOFAStack 框架，2014 年基于 Spring Boot 研发了 SOFABoot，2016 年将 SOFAStack 在公有云输出，2018 年 4 月，蚂蚁金服宣布开源 SOFAStack。SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服开源的，用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。SOFAStack ：https://github.com/sofastack\nSOFAStack 包含以下主要特性：\n 全面：覆盖多种场景，让用户更加专注于业务开发； 可靠：经历过大规模场景的锤炼，特别是严苛的金融场景； 丰富：包含构建金融级云原生架构所需的各个组件，满足用户场景的现状和未来需求； 开放：兼容开源生态，组件可插拔， SOFAStack 组件与其它开源组件可相互集成或替换。 SOFAStack 开源全景图涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的 Nacos、Sentinel 等，为用户提供更加广泛地选择。\nSOFAStack 开源已经超过一年，Spring Cloud 作为当下流行的微服务框架，社区用户以及公司内部用户迫切希望能够将这两个优秀的框架进行整合，将 SOFAStack 中间件适配 Spring Cloud 规范也就产生了我们今天的主角——spring-cloud-antfin。\nspring-cloud-antfin 全景图 Spring 官网提供了一份 Spring Cloud 的架构图：\n从 Spring Cloud 的架构图可以看到，Spring Cloud 框架涵盖了分布式应用开发的方方面面，包括：\n API 网关  熔断与限流 服务发现 分布式配置 分布式链路 spring-cloud-antfin 是 Spring Cloud 微服务规范的 antfin 实现，同样的，我们也有一份 spring-cloud-antfin 全景图，涵盖了蚂蚁金服所有中间件：\n与 Spring Cloud 全景图不同，在 spring-cloud-antfin 中每种分布式组件都有具体的蚂蚁中间件实现：\n API 网关：SOFAGateway 熔断与限流：Guardian 服务发现：SOFARegistry 分布式配置：DRM 分布式链路：SOFATracer 在 spring-cloud-antfin 适配 Spring Cloud 的过程中，我们发现 Spring Cloud 制定的规范并不完整，对于一些 Spring Cloud 规范并未涵盖的方面，spring-cloud-antfin 进行了扩展。\n扩展 Spring Cloud 虽然 Spring Cloud 定义了很多微服务规范，但是在具体业务开发过程中，我们发现 Spring Cloud 还有很多不足，例如 Spring Cloud 对以下能力没有进行规范化：\n 属性级别动态配置 事务消息 Big Table 分布式事务 属性级别动态配置 Spring Cloud 的动态配置基于 RefreshScope 接口，默认 RefreshScope 会对整个 Bean 进行刷新，而且实现自动刷新需要配合 spring-cloud-bus，我们认为与 Apollo、Nacos 等属性级别刷新相比，这个是明显的退步，所以 spring-cloud-antfin 定义一个 DynamicConfig 注解，对于打有这个注解的 Bean，spring-cloud-antfin 支持属性级别动态配置：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) public @interface DynamicConfig { } 事务消息 spring-cloud-stream 默认不支持事务消息，但是在金融级场景中事务消息是必不可少的，所以 spring-cloud-antfin 扩展了 spring-cloud-stream 的定义，对事务消息进行了支持：\n MQ 支持事务：对于使用 MQ 本身就支持事务消息的，spring-cloud-antfin 会在 MessageHeaders 中增加 Transcation 相关属性，以此支持事务消息； MQ 不支持事务：对于使用 MQ 本身不支持事务的，spring-cloud-antfin 支持用本地事件表的模式支持事务消息。 消息发送端在同一个本地事务中记录业务数据和消息事件； 事件恢复服务定时从事件表中恢复未发布成功的事件，重新发布成功后删除记录的事件。 通过事件恢复服务的不停执行，我们保证了本地事件和消息发送到 Message Broker 必定同时成功或者同时失败。\nBig Table 一些 SOFAStack 的使用者，一套代码会在多种技术栈使用，当使用开源技术栈时，Big Table 的实现会使用 HBase，在使用商业技术栈时，Big Table 会使用阿里云的 TableStore，为了让用户实现不修改代码在不同技术栈使用，spring-cloud-antfin 会定义一套统一接口，然后让用户针对 spring-cloud-antfin 的接口进行编程，这样在替换底层实现时用户代码不需要修改：\npublic interface BigTableService { Result get(Get get) throws StoreException; Result[] get(List\u0026amp;lt;Get\u0026amp;gt; get) …","date":1559113200,"description":"本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理。","dir":"blog/sofa-meetup-2-1-retrospect/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ffc229811fe6c3065b010a9730e6d895","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","publishdate":"2019-05-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","summary":"本文作者：玄北（曹杰），蚂蚁金服 SOFAStack 开源组核心成员。 本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理，主要来聊聊 spring-cloud-antfin 包含","tags":["SOFAStack","SOFAMeetup"],"title":"当 Spring Cloud 遇上 SOFAStack | Meetup#2 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","wordcount":2918},{"author":"敖小剑","categories":"Service Mesh","content":" 前言 本文内容整理自5月25日在 Kubernetes \u0026amp;amp; Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 ServiceMesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁金服的上云实践，阐述在云原生背景下 Service Mesh 的核心价值，以及对云原生落地的关键作用。\n内容主要有三个部分：\n Service Mesh 产品动态：介绍最近半年 Service Mesh 的产品动态，包括开源项目和云厂商推出的云上服务 Service Mesh 发展趋势：根据最近的产品动态，总结 Service Mesh 的发展趋势，推断未来的走向 Service Mesh 与云原生：结合云原生，更好的理解 Service Mesh 的价值和作用 Service Mesh 产品动态 Istio1.1 发布 Istio 是目前 Service Mesh 社区最引人注目的开源项目，在今年的3月份发布了期待已久的 Istio 1.1 版本，我们来看看 Istio 最近几个版本的发布情况：\n 2018年6月1日，Istio 发布了 0.8 版本，这是 Istio 历史上第一个 LTS 版本，也是 Istio 历史上变动最大的一个版本； 2018年7月31日，Istio 发布了 1.0 版本，号称 \u0026amp;ldquo;Product Ready\u0026amp;rdquo;； 然后就是漫长的等待，Istio 1.0 系列以每个月一个小版本的方式一路发布了 1.0.1 到 1.0.6，然后才开始 1.1.0 snapshot 1 到 6，再 1.1.0-rc 1 到 6，终于在 2019年3月20日 发布了 1.1 版本，号称 \u0026amp;ldquo;Enterprise Ready\u0026amp;rdquo;。 从 Istio 1.0 到 Istio 1.1，中间的时间跨度高达9个月！我们来看看经过这漫长的开发时间才发布的 Istio 1.1 版本带来了哪些新的东西：\n图中标红的部分，涉及到 Istio 的架构调整，下面将详细介绍 Istio 1.1 版本中带来的架构变化。\nIstio 1.1 架构变化 下图是 Istio 1.0 和 Istio 1.1 的架构图对比：\nIstio 1.1 的第一个架构变化来自 Galley：在 Istio 1.1 的架构图中增加了 Galley 组件。但是实际上在 Istio 1.0 版本中 Gallay 组件就已经存在，只是当时 Galley 的功能非常简单，只是做配置更新之后的验证（Validation），在 Istio 1.0 的架构图中都没有出现。而在 Istio 1.1 版本之后，Galley 的定位发生了巨大的变化：Galley开始分担 Pilot/Mixer 的职责。\n在 Istio 1.1 版本之前的设计中，Istio 的三大组件 Pilot/Mixer/Citadel 都需要访问 Kubernetes 的 API Server，以获取服务注册信息和配置信息，包括 Kubernetes 原生资源如 service/deployment/pod 等，还有 Istio 的自定义资源（数量多达50多个的 CRD） 。这个设计导致 Istio 的各个组件都不得不和 Kubernetes 的 API Server产生强绑定，不仅仅代码大量冗余，而且在测试中也因为需要和 Kubernetes 的 API Server 交互导致 Pilot/Mixer 模块测试困难。\n为了解决这个问题，在 Istio 1.1 之后，访问 Kubernetes 的 API Server 的工作将逐渐交给 Galley 组件，而其他组件如 Pilot/Mixer 就会和 Kubernetes 解耦。\n这个工作还在进行中，目前 Istio 的 CRD 已经修改为由 Galley 读取，而 K8s 的原生资源（Service / Deployment / Pod等），暂时还是由 Pilot 读取。\n为了方便在各个组件中同步数据，Istio 引入了MCP（Mesh Configuration Protocol）协议。在 Istio 1.1 版本中，Pilot 通过 MCP 协议从 Galley 同步数据。MCP 是受 xDS v2 协议（准确说是 aDS）的启发而制定的新协议，用于在Istio 各模块之间同步数据。\nIstio 1.1 的第二个架构变化来自于 Mixer，在 Istio 1.1 版本中，推荐使用 Out-of-Process Adapter，即进程外适配器。Istio 预计下一个版本将弃用 In-Proxy Adapter，目前所有的 Adapter 都将改为 Out-of-Process adapter。\n什么是 In-Proxy Adapter？下图是 Mixer 的架构图，在 Istio 的设计中，Mixer 是一个独立进程，Proxy 通过远程调用来和 Mixer 交互。而 Mixer 的实现了 Adapter 模式，定义了 Adapter API，然后内建了数量非常多的各种Adapter。这些 Adatper 的代码存放在 Mixer 代码中，运行时也在 Mixer 的进程内，因此称为 In-Process Adapter。\nIn-Process Adapter 的问题在于所有的 Adapter 的实现都和 Mixer 直接绑定，包括代码和运行时。因此当 Adapter 需要更新时就需要更新整个 Mixer，任意一个 Adapter 的实现出现问题也会影响整个 Mixer，而且数量众多的 Adapter 也带来了数量众多的CRD。为此，Istio 1.1 版本中通过引入 Out-of-Process Adapter 来解决这个问题。\nOut-of-Process Adapter 以独立进程的方式运行在 Mixer 进程之外，因此 Out-of-Process Adapter 的开发/部署和配置都可以独立于 Mixer，从而将 Mixer 从 Adaper 的实现细节中解脱出来。\n但是，Out-of-Process Adapter 的引入，会导致新的性能问题：原来 Mixer 和 In-Process Adapter 之间是方法调用，现在改成 Out-of-Process Adapter 之后就变成远程调用了。而 Mixer 一直以来都是 Istio 架构设计中最大的争议，之前 Proxy 和 Mixer 之间的远程调用，已经造成非常大的性能瓶颈，而引入 Out-of-Process Adapter 之后远程调用会从一次会变成多次（每个配置生效的 Out-of-Process Adapter 就意味着一次远程调用），这会让性能雪上加霜。\n总结 Out-of-Process Adapter 的引入：架构更加的优雅，性能更加的糟糕。\n在 Istio 1.1 为了架构而不顾性能的同时，Istio 内部也有其他的声音传出，如正在规划中的 Mixer v2。这个规划最重要的决策就是放弃 Mixer 独立进程的想法，改为将 Mixer 的功能合并到 Envoy 中，从而避免 Envoy …","date":1559026800,"description":"本文内容整理自5月25日在 Kubernetes \u0026 Cloud Native Meetup 上海站发表的主题演讲。","dir":"blog/service-mesh-development-trend-1/","fuzzywordcount":8400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8756e6985e0df28a5150ebd3af0e48c5","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-development-trend-1/","publishdate":"2019-05-28T15:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/service-mesh-development-trend-1/","summary":"前言 本文内容整理自5月25日在 Kubernetes \u0026amp; Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 ServiceMesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁金服的上云实践，","tags":["Service Mesh"],"title":"Service Mesh 发展趋势：云原生中流砥柱","type":"blog","url":"/sofastack.tech/blog/service-mesh-development-trend-1/","wordcount":8383},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第二篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 SOFAJRaft-RheaKV 是基于 SOFAJRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库，SOFAJRaft 是基于 Raft 一致性算法的生产级高性能 Java 实现，支持 Multi-Raft-Group。SOFAJRaft-RheaKV 集群主要包括三个核心组件：PD，Store 和 Region。本文将围绕 SOFAJRaft-RheaKV 架构设计，存储概览，核心模块，使用场景以及基于 Raft 实现等方面剖析 SOFAJRaft-RheaKV 基于 SOFAJRaft 实现原理，阐述如何使用 Raft 协议支持 KV 存储类库功能特性：\n SOFAJRaft-RheaKV 基础架构如何设计？核心组件负责哪些功能？模块内部处理流程是怎样？ 基于 SOFAJRaft 如何使用 Raft 实现 SOFAJRaft-RheaKV 强一致性和自驱动等特性？  SOFAJRaft-RheaKV 概览 SOFAJRaft-RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 Library， RheaKV 包含在 SOFAJRaft 项目里，是 SOFAJRaft 的子模块。SOFAJRaft-RheaKV 定位是嵌入式 jar 包方式嵌入到应用中，涵盖以下功能特性：\n 强一致性，基于 Multi-Raft 分布式一致性协议保证数据可靠性和一致性； 自驱动，自诊断，自优化，自决策，自恢复； 可监控基于节点自动上报到 PD 的元信息和状态信息； 基本 API get/put/delete 和跨分区 scan/batch put，distributed lock 等。 架构设计 SOFAJRaft-RheaKV 存储类库主要包括 PD，Store 和 Region 三个核心组件，支持轻量级的状态/元信息存储以及集群同步，分布式锁服务使用场景：\n PD 是全局的中心总控节点，负责整个集群的调度管理，维护 RegionRouteTable 路由表。一个 PDServer 管理多个集群，集群之间基于 clusterId 隔离；PD Server 需要单独部署，很多场景其实并不需要自管理，RheaKV 也支持不启用 PD，不需要自管理的集群可不启用 PD，设置 PlacementDriverOptions 的 fake选项为 true 即可。 Store 是集群中的一个物理存储节点，一个 Store 包含一个或多个 Region。 Region 是最小的 KV 数据单元，可理解为一个数据分区或者分片，每个 Region 都有一个左闭右开的区间 [startKey, endKey)，能够根据请求流量/负载/数据量大小等指标自动分裂以及自动副本搬迁。Region 有多个副本 Replication 构建 Raft Groups 存储在不同的 Store 节点，通过 Raft 协议日志复制功能数据同步到同 Group 的全部节点。 存储设计 SOFAJRaft-RheaKV 存储层为可插拔设计，实现 RawKVStore 存储接口，目前 StoreEngine 存储引擎支持 MemoryDB 和 RocksDB 两种实现：\n MemoryRawKVStore：MemoryDB 基于 ConcurrentSkipListMap 实现，有更好的性能，但是单机存储容量受内存限制； RocksRawKVStore：RocksDB 在存储容量上只受磁盘限制，适合更大数据量的场景。 SOFAJRaft-RheaKV 存储引擎基于 MemoryDB 和 RocksDB 实现 KV 存储入口：\ncom.alipay.sofa.jraft.rhea.storage.RawKVStore com.alipay.sofa.jraft.rhea.storage.MemoryRawKVStore com.alipay.sofa.jraft.rhea.storage.RocksRawKVStore SOFAJRaft-RheaKV 数据强一致性依靠 SOFAJRaft 同步数据到其他副本 Replication, 每个数据变更都会落地为一条 Raft 日志, 通过 Raft 协议日志复制功能将数据安全可靠地同步到同 Raft Group 的全部节点里。\n核心设计 SOFAJRaft-RheaKV 核心模块包括 KV 模块[RheaKVStore 基于 RegionRouteTable 路由表使用 RaftRawKVStore 存储 KeyValue]，PD 模块[PlacementDriverServer 基于 StoreHeartbeat/RegionHeartbeat 心跳平衡节点分区 Leader 以及分裂]。\nKV 模块内部处理 RheaKVStore：最上层 User API，默认实现为 DefaultRheaKVStore， RheaKVStore 为纯异步实现，所以通常阻塞调用导致的客户端出现瓶颈，理论上不会在 RheaKV 上遭遇，DefaultRheaKVStore 实现包括请求路由、Request 分裂、Response 聚合以及失败重试等功能。 PlacementDriverClient：非必须，作为与 PlacementDriver Server 集群沟通的客户端，通过它获取集群完整信息包括但不仅限于\u0026amp;rdquo;请求路由表\u0026amp;rdquo;，对于无 PD 场景， RheaKV 提供 Fake PD Client。 RegionRouteTable：分片逻辑基于 RegionRouteTable 路由表结构，最适合的数据结构便是跳表或者二叉树(最接近匹配项查询)。作为本地路由表缓存组件，RegionRouteTable 根据 KV 请求的具体失败原因来决策是否从 PD Server 集群刷新数据，并且提供对单个 Key、多个 Key 列表以及 Key Range 进行计算返回对应的分区 ID。选择 Region 的 StartKey 作为 RegionRouteTable 的 Key ，主要取决于 Region Split 的方式，父 Region 分裂成两个子 Region 导致其中一个子 Region 的 StartKey …","date":1558681200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第二篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-jraft-rheakv/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4d79102c8300ca628483bdba44c13049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv/","publishdate":"2019-05-24T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 实现原理 - SOFAJRaft-RheaKV 是如何使用 Raft 的","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv/","wordcount":5817},{"author":"Linux 中国老王","categories":"SOFAStack","content":" — 本文转载自 Linux 中国老王\n蚂蚁金服的 SOFAStack 作为一个成功地将企业私有项目转化为开源核心模式的知名案例，我们之前对背后的思考和推动力做过专题分析，但是具体这件事是如何在蚂蚁金服内部发生的、是如何实操的，有很多读者向我们表示非常感兴趣，而我觉得这也是其它技术公司所正在探索和思考的方向。\n因此，上个月底，老王在参加上海举办的 KubeCon 2019 时，遇到了蚂蚁金服 SOFA 团队的余淮，他目前在蚂蚁金服中间件团队服务与框架组具体负责开发框架与 SOFAStack 的开源工作。于是，参会之余，我和余淮就 SOFA 开源的实操方面进行了深入的沟通，现将谈话所得整理给大家。\nSOFA 与开源 继去年开始开源 SOFAStack 以来，今年上半年他们又开源了分布式事务框架 Seata 和服务注册中心 SOFARegistry，之前我曾经向蚂蚁金服中间件负责人杨冰了解过为什么要将 SOFA 开源的背后思考，以及 SOFA 发展迭代的历程，详情可以看之前的文章《蚂蚁金服技术总监杨冰：金融科技公司为什么要拥抱开源？ 》进行了解。\n目前，SOFA 的架构已经发展到 SOFA 5 阶段，在今年 2 月，前任 SOFA 开源负责人鲁直还向我分享了 SOFA 5 中重点推进的方向，主要包括 Service Mesh 和 Serverless，以及分布式事务 Seata 的落地，具体内容见文章《蚂蚁金服开源负责人鲁直：不只是中间件，未来会开源更多》。\n作为一个成功的开源核心模式的项目，我非常关注 SOFA 开源的实操是如何进行的，是如何进行开源治理的，作为 SOFA 团队的老朋友，我们话题就直接从 SOFA 的开源治理聊起。\n以 SOFA 为例：公司内部软件的开源流程 余淮说，从 2015 年开始，蚂蚁金服开启了金融科技对外输出的战略，SOFAStack 也走出了蚂蚁金服，甚至跨越了国界，被更多金融机构与合作伙伴所使用，如天弘基金、信美互信、南京银行、PayTM、DANA 钱包等。\n在与合作伙伴以及客户的沟通、合作过程中，他们发现了 SOFAStack 的理念和能力也正是很多金融行业的企业所需要的。在蚂蚁金融科技对外输出的过程中，内部已经对 SOFAStack 进行了一定程度的代码重构，例如历史兼容逻辑的剥离等，但是并未能达到直接开源的标准。\n关于开源，内部一直有开源的讨论，到 2017 年双十一结束后正式决定开源。经过了一系列的准备，2018 年 4 月，完成了对 SOFA 项目的满足了开源改造的标准后，SOFAStack 马上宣布正式开源框架中部分重要组件。\nSOFA 团队采用的开源策略叫「Open Core」，顾名思义就是要将接口层以及核心实现都开源，以可扩展化的方式来层层构建 SOFAStack 的能力，保证 SOFAStack 的内部版本和开源的版本采用的是同一个内核。为此 SOFAStack 做了大量的改造和重构工作。\n在开源的具体考量上，余淮表示，SOFAStack 的开源改造基本上有三条原则，分别是高可扩展性、对内兼容历史版本、对外兼容业界标准。\n以 SOFARPC 重构为例，大概经历了这样的过程：\n 首先需要将 SOFARPC 进行了一次核心接口和模型抽象，然后增加了扩展点机制和事件总线机制，所有的对内对外实现都基于这些核心接口和模型去扩展，并且保证这些扩展能力都是平等的、可选的； 接着将核心的处理逻辑实现迁移到这套接口和模型上来，保证 SOFARPC 能力完整可用； 然后需要将 SOFARPC 里一些对接内部系统的、兼容历史逻辑的代码做成内部扩展，并进行全量测试验证，确保和已有线上的历史方案的兼容，发布上线； 最后会调研业界的一些开源标准方案和实现，并对其进行兼容，例如 SOFARPC 不仅对接自己的 SOFARegistry 的实现，还兼容了 Zookeeper、Etcd、Nacos 等业界优秀的注册中心方案。 虽然上面重构过程听上去没那么复杂，但是在实际过程中还是非常考验团队的技术能力的，特别是在抽象核心接口和模型的时候，为了做到既兼容内部又兼容外部，这需要进行大量的调研工作，才能做好这层较为通用抽象。其次在对内逻辑兼容的时候，由于内部的历史负担还是比较重的，为了能让重构的代码安全上线，团队也做了很多事情。\n还是举 SOFARPC 的例子，蚂蚁金服内部的服务路由过程比开源是要复杂很多的，特别是配合蚂蚁金服特有的单元化部署以及异地多活的能力，有时候需要多层路由才能找到目标地址。为了验证重构后逻辑的正确性，除了在开源代码里有单元测试用例外，SOFA 团队在内部也构建了一套非常完善的集成框架，专门用来测试已有逻辑的兼容性及正确性。\n基于 Open Core 这套思想建设 SOFAStack 以后，其实对开发同学的工作量来不会变少，反而可能是增多的。这是因为在写代码的同时，需要更多的考虑内部外部的使用情况，对代码质量也提出了更高的要求，开发流程会变得更加复杂。\n例如，内部新增一个特性，在以前可能直接修改代码经过测试就发布上线了，但现在的话会去思考这其中哪些能力是通用的，把这些能力抽象一下放到开源版本里去，然后开源版测试后发布，这个时候内部版本在基于这个开源版进行扩展，再经过测试后发布上线。\n虽然开发同学工作变多了，但是这样的话可以让 SOFAStack 的核心代码被更多的开发者 Review，在更多的系统中运行，在更多的场景下进行验证，对 SOFAStack 的品质保证有非常大的帮助。\n此外在开源进度上，余淮表示， SOFAStack 并不追求开源全部内部的组件，而是会根据产品的特性和开源准备的情况有选择的开源。\n例如 SOFAStack 下的分库分表组件，因为产品特性和 OB 等内部结合紧密就暂时不会开源。金融级分布式架构下未开源部分能力，SOFAStack 会和与业界其它优秀的开源项目做集成，保证整个金融级分布式架构功能的完整性和多样性。\n所以对于 SOFAStack 来说，并不只有自己开源的产品，而更多关注的是，和整个社区里所有开源优秀的产品一起，打造一套快速构建金融级分布式架构的套件。\n开源项目管理 开源一个项目，作为背后推动的公司事实上要付出相当多的人力和资金成本，同时，也不可避免的会涉及到审批流程。随着蚂蚁金服越来越多领域的项目开源，包括 SOFAStack，AI，区块链等，蚂蚁金服内部出台了相应的严格的审核机制，包括技术、合规、法务、安全等部门进行审核，同时还会考察项目开源对公司的意义，以及是否对社区有价值，在审核通过之后项目就会正式开源与大家见面了。\n蚂蚁金服对于开源文化是十分友好的，其内部的代码也大多都是公开在内网的 GitLab 仓库，经常会有业务团队对 SOFAStack 提交一些合并请求（拉取请求）来帮助项目的发展。\n同时，蚂蚁金服的工程师也普遍地拥抱开源，开源能够帮助项目产生更多、更好的想法，同时也可以吸收来自社区的贡献，让项目本身能够做的更好，这是大家所喜闻乐见的。 SOFA 的社区治理 开源项目并不是开放源代码就是终点，事实上，这只是开始，之后持续不断的开源治理才是开源之路。而如何将一个开源项目从最开始的由开源项目背后的公司主导转变为社 …","date":1558681200,"description":"SOFAStack 开源如何在蚂蚁金服内部发生、是如何实操的、如何运营，Lunix中国老王进行了采访和分析，欢迎阅读","dir":"blog/sofastack-linux-china/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c1896b9b50b60432bb345d583a9be24a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-linux-china/","publishdate":"2019-05-24T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofastack-linux-china/","summary":"— 本文转载自 Linux 中国老王 蚂蚁金服的 SOFAStack 作为一个成功地将企业私有项目转化为开源核心模式的知名案例，我们之前对背后的思考和推动力做过专题分析，但是具","tags":["SOFAStack"],"title":"大公司开源怎么做？SOFAStack给出了一个很好的例子","type":"blog","url":"/sofastack.tech/blog/sofastack-linux-china/","wordcount":3968},{"author":"花肉","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 活动时间：5 月 26 日周日下午 13 点 活动地点：上海市徐汇区田林路200号A7栋一楼 活动形式：线下活动 报名方式：https://tech.antfin.com/community/activities/576 活动介绍 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n欢迎 Star 我：https://github.com/sofastack\nSOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n5 月 26 日，SOFAMeetup#2 上海站，SOFAStack 开源核心成员集体出动。本期我们将侧重于各个落地的实际场景进行架构解析。\n分布式事务 Seata 详解、与 Spring Cloud 生态的融合案例、使用 SOFAStack 快速构建微服务 Demo 实操、更有最新开源的《让 AI 像 SQL 一样简单 — SQLFlow Demo 》首秀，期待与你不见不散~\n建议：参会者可带上电脑，现场有 Demo 实操环节~\n加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n点击即可报名 https://tech.antfin.com/community/activities/576\n议程 时间 环节 讲师 13:00 - 13:30 签到 13:30 - 14:15 《研发框架 SOFABoot 的特性及落地场景介绍》 蚂蚁金服 SOFABoot 负责人 善逝 14 :15 - 15:00 《谈注册中心 SOFARegistry 架构设计 》 蚂蚁金服 SOFARegistry 负责人 琪祥 15:00 - 15:05 茶歇休息 15:05 - 15:15 《SOFALab 社区共建分享》 SOFALab 杰出贡献者 米麒麟 15:15 - 16:00 《当 SpringCloud 遇上 SOFAStack》 蚂蚁金服 SOFAStack 开源组核心负责人 玄北 16:00 - 16:45 《分布式事务 Seata 实现原理及实践详解》 Seata Committer 绍辉 16:45 - 17:30 《使用 SOFAStack 快速构建微服务》SOFADashboard 演示 + SOFARegistry + SOFARPC + SOFAArk 蚂蚁金服 SOFADashboard 负责人 卫恒 17:30 - 17:45 《让 AI 像 SQL 一样简单 — SQLFlow Demo 演示》 蚂蚁金服深度学习引擎开源产品负责人 三平 ","date":1558437600,"description":"SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务，5 月 26 日周日下午 13 点，上海市徐汇区田林路200号A7栋一楼。","dir":"activities/sofa-meetup-2/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5765309cb693fc8cc45958ecab5a9c3b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-2/","publishdate":"2019-05-21T11:20:00Z","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-meetup-2/","summary":"概要 活动主题：SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 活动时间：5 月 26 日周日下午 13 点 活动地点：上海市徐汇区田林路200号A7栋一楼 活动形式：线","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#2 上海站——使用 SOFAStack 快速构建微服务","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-2/","wordcount":849},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFAStack 启用独立 Group ，社区更加开放 今日，SOFAStack 将启用独立 Group： https://github.com/sofastack\n感谢大家的一路支持，未来，我们继续相伴~\n背景：分布式架构 SOFAStack 开源历史 金融级分布式架构 SOFAStack 产生于蚂蚁金服内部需求，起初是为了解决高速发展下的业务问题。到 2019 年，已经历12年的业务锤炼，变成了一套成熟的金融级最佳实践。\nSOFAStack 的发展受益于开源社区的优秀产品，我们也决定结合我们的实践积累，把这些技术反馈给开源社区。\n2018 年 4 月，SOFAStack 宣布开源。这一年，SOFAStack 逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFABolt、SOFAMosn、SOFAMesh、SOFAJRaft、SOFAActs、SOFARegistry、SOFADashboard 等组件。2019 年 3 月，蚂蚁金服加入分布式事务Seata的社区共建中，并贡献其 TCC 模式。\nSOFAStack 未来也将持续开源，丰富生态。\nSOFA 开源全景图，涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的 Nacos、Sentinel 等，为用户提供更加广泛地选择。\nSOFAStack 启用独立 Group 和邮件订阅列表 为了开源管理更加清晰，更社区化的运作，更中立的技术态度，开放给更多的开发者和企业参与，SOFAStack 将启用独立 Group：\n SOFAStack 项目地址： https://github.com/sofastack 原项目地址： https://github.com/alipay 继续可访问，会跳转到新的地址上。\n 邮件订阅列表 加入 SOFAStack 邮件组 https://groups.google.com/forum/#!forum/sofastack 获取邮件订阅。\n感谢大家的一路支持，未来，我们继续相伴~\n","date":1557990000,"description":"SOFAStack 将启用独立 Group，社区更加开放今日。感谢大家的一路支持，未来，我们继续相伴","dir":"blog/sofastack-independent-droup/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f25b8521e498ebce982a98b882f941b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-independent-droup/","publishdate":"2019-05-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofastack-independent-droup/","summary":"SOFAStack 启用独立 Group ，社区更加开放 今日，SOFAStack 将启用独立 Group： https://github.com/sofastack 感谢大家的一路支持，未来，我们继续相伴~ 背景：分布式架构 SOFAStack 开源历史","tags":["SOFAStack"],"title":"持续技术开放 | SOFAStack 启用独立 Group","type":"blog","url":"/sofastack.tech/blog/sofastack-independent-droup/","wordcount":617},{"author":"SQLFlow","categories":"SQLFlow","content":" 5 月 6 日，在 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow，他在演讲中表示：“未来三年，AI 能力会成为每一位技术人员的基本能力。我们希望通过开源 SQLFlow，降低人工智能应用的技术门槛，让技术人员调用 AI 像 SQL 一样简单。”\nSQLFlow 的目标是将 SQL 引擎和 AI 引擎连接起来，让用户仅需几行 SQL 代码就能描述整个应用或者产品背后的数据流和 AI 构造。其中所涉及的 SQL 引擎包括 MySQL、Oracle、Hive、SparkSQL、Flink 等支持用 SQL 或其某个变种语言描述数据，以及描述对数据的操作的系统。而这里所指的 AI 引擎包括 TensorFlow、PyTorch 等深度学习系统，也包括 XGBoost、LibLinear、LibSVM 等传统机器学习系统。\nSQLFlow 开源项目链接：https://sqlflow.org/sqlflow\n5 月 26 日，将在上海迎来 SQLFlow 线下首秀 —《让 AI 像 SQL 一样简单— SQLFlow Demo》，还有 SOFAStack 开源生态交流分享，点击链接，即可报名~期待你的到来~\nhttps://tech.antfin.com/community/activities/576\nSQLFlow 的研发团队认为，在 SQLFlow 和 AI 引擎之间存在一个很大的空隙——如何把数据变成 AI 模型需要的输入。谷歌开源的 TensorFlow 项目开了一个好头，TFX Data Transform 和 feature column API 都是意图填补这个空缺的项目。但是这个空缺很大，是各种 SQL 引擎和各种 AI 引擎的笛卡尔积，远不是 TensorFlow 的这两个子项目就足以填补的，需要一个开源社区才行。要填补好这个空缺，需要先让用户意识到其重要性，这也是蚂蚁金服开源 SQLFlow 的意图之一。\nSQLFlow 位于 AI 软件系统生态的最顶端，最接近用户，它也位于数据和数据流软件生态之上。\n其实，将 SQL 和 AI 连接起来这个想法并非 SQLFlow 原创。谷歌于 2018 年年中发布的 BigQueryML 同样旨在“让数据科学家和分析师只用 SQL 语言就可以实现流行的机器学习功能并执行预测分析”。除了 Google 的 BigQueryML，微软基于 SQL Server 的 AI 扩展，以及 Teradata 的 SQL for DL 同样旨在连接 SQL 和 AI，让人工智能的应用变得像 SQL 一样简单。而 SQLFlow 与上述各个系统最根本的差异在于：SQLFlow 是开源的，以上系统都不是。\n开发 SQLFlow 的初衷 蚂蚁金服和很多互联网公司一样，不同产品背后有很多功能都依赖于 AI，比如用户信用的评估就是一套预测模型。到目前为止，每一个这样的功能的实现，都依赖一个工程师团队开发多个子系统——读取数据库或者在线日志流、这两类数据的 join、各种数据筛选、数据到模型输入（常说的 features）的映射、训练模型、用训练好的模型来做预测。整个过程下来耗时往往以月计，如果加班加点放弃写 unit test 代码，可能缩短到以周记。\n以上问题正是 SQLFlow 系统希望替工程师们解决的问题。蚂蚁金服拥有数千数据分析师，他们日常工作用的就是 SQL 语言。虽然数据分析师在互联网行业往往不像用 Python、Java、C++ 的工程师那样醒目，但是在很多有面向商业伙伴的业务的公司里，比如 LinkedIn，他们的贡献和人数都能与工程师相匹敌。SQLFlow 最早的初衷，就是希望解决分析师既要操作数据又要使用 AI、往往需要在两个甚至更多的系统之间切换、工作效率低的窘境。\nSQLFlow 旨在大幅提升效率，让上述功能实现所花费的时间进一步缩短到能以日计，甚至以小时计的程度。\n要达到这样的效率，必须有一种效率极高的描述工作意图的方式。SQL 是一种典型的描述意图，而不描述过程的编程语言。用户可以说我要 join 两个表，但是不需要写循环和构造 hash map 来描述如何 join 两个表。这个特性使得 SQL 能极大地提升开发效率，这正是 SQLFlow 选择扩展 SQL 语法支持 AI 这条思路的原因。\n不过，高效率的背后是更大的工程技术挑战。SQLFlow 需要做到能根据用户的意图，自动生成达到意图的 Python、C++、Go 语言的程序。\nSQLFlow 的架构设计 设计目标 在连接 SQL 和 AI 应用这一方向上，业内已有相关工作。开发者可以使用像 DOT_PRODUCT 这样的运算符在 SQL 中编写简单的机器学习预测（或评分）算法。但是，从训练程序到 SQL 语句需要进行大量的模型参数复制粘贴的工作。目前在一些商业软件中，已经有部分专有 SQL 引擎提供了支持机器学习功能的扩展。\n Microsoft SQL Server：Microsoft SQL Server 支持机器学习服务，可以将 R 或 Python 编写的机器学习程序作为外部脚本运行。 Teradata SQL for DL：Teradata 也提供了 RESTful 服务，可以通过扩展的 SQL SELECT 语法调用。 Google BigQuery：Google BigQuery 通过引入 CREATE MODEL 语句让用 SQL 实现机器学习成为可能。 但上述已有的解决方案都无法解决蚂蚁金服团队的痛点，他们的目标是打造一个完全可扩展的解决方案。\n 这一解决方案应与许多 SQL 引擎都兼容，而不是只能兼容特定版本或类型的 SQL 引擎。 它应该支持复杂的机器学习模型，包括用于深度学习的 TensorFlow 和用于树模型的 XGBoost。 能够灵活地配置和运行前沿机器学习算法，包括指定特征交叉，无需在 SQL 语句中嵌入 Python 或 R 代码，以及完全集成超参数估计等。 应对上述挑战的关键在于打造一套 SQL 扩展语法。研发团队首先从仅支持 MySQL 和 TensorFlow 的原型开发开始，后续计划支持更多 SQL 引擎和机器学习工具包。\n从 SQL 到机器学习 SQLFlow 可以看作一个翻译器，它把扩展语法的 SQL 程序翻译成一个被称为 submitter 的程序，然后执行。 SQLFlow 提供一个抽象层，把各种 SQL 引擎抽象成一样的。SQLFlow 还提供一个可扩展的机制，使得大家可以插入各种翻译机制，得到基于不同 AI 引擎的 submitter 程序。\nSQLFlow 对 SQL 语法的扩展意图很简单：在 SELECT 语句后面，加上一个扩展语法的 TRAIN 从句，即可实现 AI 模型的训练。或者加上一个 PREDICT 从句即可实现用现有模型做预测。这样的设计大大简化了数据分析师的学习路径。\n此外，SQLFlow 也提供一些基本功能，可以供各种 submitter 翻译插件使用，用来根据数据的特点，推导如何自动地把数据转换成 features。这样用户 …","date":1557903600,"description":"本文整理于 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow 的现场演讲。","dir":"blog/sqlflow-open-source/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fcd6535619144aec695ee9afbf2fc36b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sqlflow-open-source/","publishdate":"2019-05-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sqlflow-open-source/","summary":"5 月 6 日，在 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow，他在演讲中表示：“未来三年，AI","tags":["SQLFlow"],"title":"蚂蚁金服开源机器学习工具 SQLFlow，技术架构独家解读","type":"blog","url":"/sofastack.tech/blog/sqlflow-open-source/","wordcount":5106},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs\n活动时间：5 月 16 日周四晚 7 点\n活动形式：线上直播\n报名方式：https://tech.antfin.com/activities/552\n介绍 | SOFAChannel\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs\n如何自动生成测试用例？\n如何减少测试用例设计过程中的阻力？\n如何进行精细化校验以及用例的高效管理，从而保障代码质量，有效提高测试效率？\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 线上直播第 5 期《给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs》报名开启！\n5 月 16 日周四晚 7 点，围绕蚂蚁金服的多年测试实践的积累与沉淀，自动化测试框架 SOFAActs 核心成员青勤将为大家带来精彩分享，不要错过哦。\nSOFAActs 是基于数据模型驱动测试引擎的的新一代测试框架，它的数据以 YAML 为载体，在此上构建基于数据模型的驱动引擎，适配 TestNg+SOFABoot 的测试上下文环境；支持高效、标准化构建用例，可视化编辑测试数据，精细化校验结果数据和自动清理 DB 数据，可以有效降低人工录入用例数据的成本，同时支持 API 重写提高测试代码的可扩展可复用性，提供特有注解提高测试代码编排的灵活性。\n| 加入 SOFA 钉钉互动群\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n| 点击即可报名\nhttps://tech.antfin.com/activities/552\n议程 19:00-19:05 主持人开场\nSOFAGirl 主持人\n19:05-20:00 给研发工程师的代码质量利器 — 自动化测试框架 SOFAActs\n青勤 蚂蚁金服自动化测试框架 SOFAActs 核心成员\n本期分享大纲：\n 蚂蚁金服接口自动化测试理念 如何接入 SOFAActs 自动化测试框架 SOFAActs 自动化测试框架的基本使用 嘉宾 SOFAGirl 主持人 青勤 蚂蚁金服自动化测试框架 SOFAActs 核心成员 ","date":1557310800,"description":"5 月 16 日周四晚 7 点，线上直播。","dir":"activities/sofa-channel-5/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e000553c2c76f43ed8df5b8e56491a7b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-5/","publishdate":"2019-05-08T10:20:00Z","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-5/","summary":"概要 活动主题：SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs 活动时间：5 月 16 日周四晚 7 点 活动形式：线上直播 报名方","tags":["SOFAChannel","SOFAActs"],"title":"SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs","type":"activities","url":"/sofastack.tech/activities/sofa-channel-5/","wordcount":733},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第一篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft 存储模块分为：\n Log 存储记录 Raft 配置变更和用户提交任务日志； Meta 存储即元信息存储记录 Raft 实现的内部状态； Snapshot 存储用于存放用户的状态机 Snapshot 及元信息。 本文将围绕日志存储，元信息存储以及快照存储等方面剖析 SOFAJRaft 存储模块原理，阐述如何解决 Raft 协议存储问题以及存储模块实现：\n Raft 配置变更和用户提交任务日志如何存储？如何调用管理日志存储？ SOFAJRaft Server 节点 Node 是如何存储 Raft 内部配置？ Raft 状态机快照 Snapshot 机制如何实现？如何存储安装镜像？ 日志存储 Log 存储，记录 Raft 配置变更和用户提交任务的日志，把日志从 Leader 复制到其他节点上面。\n LogStorage 是日志存储实现，默认实现基于 RocksDB 存储，通过 LogStorage 接口扩展自定义日志存储实现； LogManager 负责调用底层日志存储 LogStorage，针对日志存储调用进行缓存、批量提交、必要的检查和优化。 LogStorage 存储实现 LogStorage 日志存储实现，定义 Raft 分组节点 Node 的 Log 存储模块核心 API 接口包括：\n 返回日志里的首/末个日志索引； 按照日志索引获取 Log Entry 及其任期； 把单个/批量 Log Entry 添加到日志存储； 从 Log 存储头部/末尾删除日志； 删除所有现有日志，重置下任日志索引。 Log Index 提交到 Raft Group 中的任务序列化为日志存储，每条日志一个编号，在整个 Raft Group 内单调递增并复制到每个 Raft 节点。LogStorage 日志存储实现接口定义入口：\ncom.alipay.sofa.jraft.storage.LogStorage RocksDBLogStorage 基于 RocksDB 实现 Log Structured Merge Tree 简称 LSM ，把一颗大树拆分成 N 棵小树，数据首先写入内存，内存里构建一颗有序小树，随着小树越来越大，内存的小树 Flush 到磁盘，磁盘中的树定期做合并操作合并成一棵大树以优化读性能，通过把磁盘的随机写转化为顺序写提高写性能，RocksDB 就是基于 LSM-Tree 数据结构使用 C++ 编写的嵌入式 KV 存储引擎，其键值均允许使用二进制流。RocksDB 按顺序组织所有数据，通用操作包括 get(key), put(key), delete(Key) 以及 newIterator()。RocksDB 有三种基本的数据结构：memtable，sstfile 以及 logfile。memtable 是一种内存数据结构\u0026amp;ndash;所有写入请求都会进入 memtable，然后选择性进入 logfile。logfile 是一种有序写存储结构，当 memtable 被填满的时候被刷到 sstfile 文件并存储起来，然后相关的 logfile 在之后被安全地删除。sstfile 内的数据都是排序好的，以便于根据 key 快速搜索。\nLogStorage 默认实现 RocksDBLogStorage 是基于 RocksDB 存储日志，初始化日志存储 StorageFactory 根据 Raft节点日志存储路径和 Raft 内部实现是否调用 fsync 配置默认创建 RocksDBLogStorage 日志存储。基于 RocksDB 存储实现 RocksDBLogStorage 核心操作包括：\n init()：创建 RocksDB 配置选项调用 RocksDB#open() 方法构建 RocksDB 实例，添加 default 默认列族及其配置选项获取列族处理器，通过 newIterator() 生成 RocksDB 迭代器遍历 KeyValue 数据检查 Value 类型加载 Raft 配置变更到配置管理器 ConfigurationManager。RocksDB 引入列族 ColumnFamily 概念，所谓列族是指一系列 KeyValue 组成的数据集，RocksDB 读写操作需要指定列族，创建 RocksDB 默认构建命名为default 的列族。 shutdown()：首先关闭列族处理器以及 RocksDB 实例，其次遍历列族配置选项执行关闭操作，接着关闭RocksDB 配置选项，最后清除强引用以达到 Help GC 垃圾回收 RocksDB 实例及其配置选项对象。 getFirstLogIndex()：基于处理器 defaultHandle 和读选项 totalOrderReadOptions 方法构建 RocksDB 迭代器 RocksIterator，检查是否加载过日志里第一个日志索引，未加载需调用 seekToFirst() 方法获取缓存 RocksDB 存储日志数据的第一个日志索引。 getLastLogIndex()：基于处理器 defaultHandle 和读选项 totalOrderReadOptions 构建 RocksDB 迭代器 RocksIterator，调用 seekToLast() 方法返回 RocksDB 存储日志记录的最后一个日志索引。 getEntry(index)：基于处理器 defaultHandle 和指定日志索引调用 RocksDB#get() 操作返回 RocksDB 索引位置日志 LogEntry。 getTerm(index)：基于处理器 defaultHandle 和指定日志索引调用 RocksDB#get() 操作获取 RocksDB 索引位置日志并且返回其 LogEntry 的任期。 appendEntry(entry)：检查日志 LogEntry 类型是否为配置变更，配置变更类型调用 RocksDB#write() 方法执行批量写入，用户提交任务的日志基于处理器 defaultHandle 和 LogEntry 对象调 …","date":1557066600,"description":"本文为《剖析 | SOFAJRaft 实现原理》第一篇，本篇作者米麒麟，来自陆金所。。","dir":"blog/sofa-jraft-algorithm-storage-module-deep-dive/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b48c76bf76b0c77d11af1a6265c9b78b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","publishdate":"2019-05-05T14:30:00Z","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 实现原理 - 生产级 Raft 算法库存储模块剖析","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","wordcount":6384},{"author":"卫恒","categories":"SOFADashboard","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 为了建设更完整的 SOFAStack 微服务体系，我们计划发起 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。欢迎共建~ SOFADashboard：https://github.com/sofastack/sofa-dashboard  背景 从 2018 年 4 月 19 日宣布开源至今，SOFAStack 目前已经开源了包括 SOFABoot、 SOFARPC、SOFALookout、SOFATracer、SOFARegistry 等在内的一系列微服务相关的项目，并投入分布式事务 Seata 进行重要贡献。随着 SOFAStack 架构体系的不断丰富和完善，外部对于 SOFAStack 的管控平台的需求也愈加强烈。\n由于 SOFAStack 内部的管控平台依赖众多的内部基础设施，为了建设更完整的 SOFAStack 微服务体系，我们计划发起全新的 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。\n能力大图 SOFADashboard 作为一站式 SOFAStack 管控台，希望对 SOFAStack 各个组件的使用等进行统一管理。为此我们为 SOFADashboard 规划一版能力图，包含了微服务里的一些能力点，例如应用信息管理、服务治理、配置管控、动态模块等等。见下图所示：\n每个能力点对应的实现我们都做了一层抽象。例如服务查看需要从注册中心获取数据，我们封装了一层服务列表获取接口，底层可以是从 Zookeeper 或者 SOFARegistry 等不同的注册中心实现读取服务列表。\n技术栈选择 为了最大限度的降低开发成本、部署成本及运维成本，SOFADashboard 会基于开源社区优秀的产品来进行开发构建。经过讨论，最终选择社区主流的前后端分离思路，具体的组件包括：\n Ant Design：基于 React封装的一套 Ant Design 的组件库，主要用于研发企业级中后台产品。从产品成熟度、社区活跃度、框架上手难易程度等各个方面均有很好的表现。 SOFABoot：蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。 MyBatis：Mybatis 相对于 JPA 来说，上手难度略低，JPA 更加倾向于结合 DDD 使用(业务越复杂，对于DDD 的需求越高)；对于简单的增删改查业务操作，Mybatis 相对来说更灵活和可控。 v1.0 发布 4 月 30 日，我们上传了第一个 SOFADashboard 版本，主要能力包括：应用信息、服务查看、动态模块管控等。\n目前演示地址：http://dashboard.dev.sofastack.tech:8000/ 详细设计图 基础依赖 从架构图中可以看到，目前 SOFADashboard 中的服务治理、SOFAArk 管控等需要依赖于 Zookeeper 和 MySQL；它们承担的解决如下：\n 外部依赖 作用 备注 Zookeeper 注册中心 SOFARPC 服务治理 配置推送 SOFAArk 管控 MySql 资源存储 注册的 ark-biz 信息，插件与应用的关联信息，插件版本信息等 应用面板 SOFADashboard 支持查看应用的 IP、端口、健康检查状态等基本信息，此功能依赖 SOFADashboard client。SOFADashboard client 用于向 SOFADashboard 服务端注册 IP、端口、健康检查状态等应用基本信息；SOFADashboard client 并非是直接通过 API 调用的方式将自身应用信息直接注册到 SOFADashboard 服务端 ，而是借助于 Zookeeper 来完成。\n客户端向 Zookeeper 中如上图所示的节点中写入数据，每一个 ip:port 节点代表一个应用实例，应用本身信息将写入当前节点的 data 中。\n如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可，具体使用参考 SOFADashboard client 快速开始 。\n服务治理 SOFADashboard 服务治理是对 SOFARPC 的服务进行管理，服务治理管控台部分，主要包括基于服务名查询和服务信息列表展示两个基础能力。在服务治理管控台界面，可以直观的看到当前服务的一些基本元数据信息：\n当点击 服务 ID 对应的超链接时，会进入到当前服务的详情页；服务提供者详情页中，可以看到当前服务所有的提供方信息列表，每个 item 行对应一个服务提供方实例，通过此界面可以快速查看服务的 providers 信息。\n服务消费者详情页中，可以看到当前服务所有的消费方信息列表。\nSOFAArk 管控 SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAArk 管控是 SOFADashboard 针对 API 管控的一种实现。通过面向 Zookeeper 进行命令的推送和命令的解析执行。SOFAArk 管控主要包括以下功能：\n 插件注册 将 ark-biz 插件注册到 SOFADashboard，作为基础数据，统一管控。\n插件基本信息录入：\n插件列表：\n 关联应用 将 ark-biz 插件与宿主应用进行绑定，此关联信息在 SOFAArk 多应用（模块）合并部署中作为重要的基础信息存在。在后续的操作中，可以通过此关联关系查看到某个插件下挂载的应用信息。\n 插件详情 通过插件详情页，可以看下当前 ark-biz 插件下所有关联的宿主应用信息，以及宿主应用中的 ark-biz 状态信息，插件详情页中，可以查看所有关联此插件的应用中，插件的状态信息。\n 命令推送 命令推送是 SOFADashboard 中提供 SOFAArk 管控的核心能力，通过面向 Zookeeper 编程的方式，将指令信息传递给各个宿主应用中的 ark-biz 模块，ark-biz 在接收到相关指令之后再进行相应的行为，如安装、切换、卸载等。\n可以针对应用维度、IP 维度推送一些指令，比如 install、uninstall 等等，当这些命令被写入到 Zookeeper 的某个节点上时，所有监听此节点的宿主应用均会解析此指令，并进行相关的操作。\n基于 IP 维度推送如图例所示，每个应用实例表单默认会有对应的操作，可以通过展示的命令按钮操作当前实例行为：\n点击 安装按钮，延迟 1~1.5s 之后 界面将会刷 …","date":1557039600,"description":"为了建设更完整的 SOFAStack 微服务体系，我们计划发起 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。欢迎共建~","dir":"blog/sofa-dashboard-open-source/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f9a78639fd427da4c3ea19d32e8420e7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-dashboard-open-source/","publishdate":"2019-05-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-dashboard-open-source/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 为了建设更完整","tags":["SOFADashboard"],"title":"SOFADashboard 启动开源共建 | SOFAStack 一站式管控平台","type":"blog","url":"/sofastack.tech/blog/sofa-dashboard-open-source/","wordcount":2602},{"author":"老王","categories":"SOFAStack","content":" 本文转自 Linux 中国\n谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。\u0026amp;ndash; 老王\n二月初春，在西子湖畔的细雨中，我拜访了蚂蚁金服中间件团队，和 SOFA 技术负责人鲁直做了一次深入交谈，更妙的是，鲁直也是负责 SOFA 开源事务推进的人，而这样一个切实践行开放核心模式的开源项目，也正是我非常感兴趣的。\n两个技术人的谈话，自然是朴实而直白的，话题主要围绕着 SOFA 和开源主题展开，希望也能一样引起同是技术人的你的共鸣。\n 人物介绍 受访者：鲁直，蚂蚁金服 SOFA 开源负责人。 采访者：老王，开源布道人，有 20 年互联网从业经历的技术老兵。\n 虽然我和鲁直在微信上已经联系很久了，但这还是第一次见面。交谈中，我了解到鲁直是 2009 年加入阿里巴巴工作，已经有十年了。刚开始是在 1688.COM 做业务系统，对中间件技术非常感兴趣，也会经常研究各种中间件的实现和功能。后来在 2013年时，为了更深入地学习研究中间件框架，转到了蚂蚁金服中间件团队，从那个时候开始就一直在做 SOFA。\n目前鲁直在 SOFA 的团队主要负责的工作包括几个部分。其中一个主要部分就是 SOFA 开源相关的工作。SOFA 的产品体系非常广，包括已经对外开源的部分、内部整个微服务体系，以及 SOFA 框架等等——而这些开源相关的工作主要是由鲁直负责推动的。\n当然，作为技术负责人，鲁直既要带技术团队也要做技术工作。谈及这一点，鲁直说：\n“我觉得做技术管理，跟普通的管理不太一样，因为技术管理最重要的一个点是除了管理之外，还要保持一定的技术判断力和敏锐度。对一些新技术，包括团队中遇到一些重大的技术问题，你都要有一些方向性的判断。虽然最后不一定是你具体解决的，但是在整个团队的技术攻坚和技术选型上，要一起确立方向。”\n我以前也做过十余年的技术管理，我很能够感受这种情况，重大问题技术负责人更要迎难而上。\nSOFA 5 落子 Service Mesh 就我了解的情况，现在 SOFA 已经发展到了 SOFA5 了。在 SOFA4 阶段，主要的任务是将开源体系捋清楚了，然后开始按步骤地开源；到现在发展到了 SOFA5。我想知道从 SOFA4 发展到 SOFA5，是什么让蚂蚁金服中间件团队判断 SOFA4 的阶段性目标已经达成，可以迈进到新的 SOFA5 阶段了呢？\n “从整个业界趋势上来讲，SOFA4 的架构相对来说还是偏传统一些，更多是对我们之前的技术框架的整理和梳理。在这个阶段，SOFA 的代码经过了非常多的优化和重构，才达到了对外开源的要求，从而 SOFA 走上了开源核心的模式，逐步分阶段的将各个部分进行了开源。”鲁直讲到，“但是，从我们对业界的整体判断上来说，未来无疑是云的时代，所以说要考虑怎么让所有的业务系统能够提供云的能力，比如说 Serverless。”\n接着这个话题，鲁直讲了他对云计算的理解：“一方面云计算肯定要为整个业务的发展提供更加方便的基础资源，可以不用去关心底层的基础设施。Serverless 字面的意思就是说‘无服务器’——我不用关心服务器怎么来的，不用关心基础设施，只要关心业务代码就可以了。那反过来对于云服务商来说，经过了这一层抽象，其资源利用率会更高，可以有更多的利润空间，这是一个双赢的局面。对于用户来讲，这种好处是实实在在的，可以更少关注基础设施，只关心代码就可以了。”\n  “我们希望在 SOFA5 的方向上，在这个新的迭代中，去让业务——包括让未来我们开源出来各种功能、各样服务模式——都更多地去关心自己的业务代码，而不用再过多地关心基础设施。”鲁直说。\n 在 SOFA5 中，一个重要的方向就是 Service Mesh 这个方向，这将是 SOFA5 中非常重要的特性。鲁直强调了其对 Service Mesh 技术的看好：“我认为 Service Mesh 是迈向未来往前走的非常关键的一步，让业务不用再关心基础设施。通过 Service Mesh，我们可以将很多技术能力直接放到基础设施里面，而业务可以不用感知到这一层。原来可能需要花几个小时或者更多的时间解决的基础设施问题，现在可以通过 Service Mesh 解决掉。”\n“目前我们我们已经在生产环境中应用了 Service Mesh。我们在这方面有非常大的决心，我们希望能够在今年，在更大的范围中去落地 Service Mesh。当前这个阶段更聚焦在这种技术的内部落地上，希望用好了，再给社区做更多的贡献。”\n Service Mesh 这个词最早是由开发 Linkerd 的 Buoyant 公司于 2016 年提出的，随着 Linkerd 的传入，Service Mesh 也进入国内技术社区的视野。Service Mesh 也被翻译为“服务网格”。Linkerd 则是业界第一个 Service Mesh。 Service Mesh 是一个基础设施层，用于处理服务间通信，负责实现请求的可靠传递。在实践中，服务网格通常实现为轻量级网络代理，通常与应用程序部署在一起，但是对应用程序透明。\nService Mesh 的部署模型，有两种情况： ◈ 对于一个简单请求，作为请求发起者的客户端应用实例，会首先用简单方式将请求发送到本地的 Service Mesh 实例。这是两个独立进程，它们之间是远程调用。Service Mesh 会完成完整的服务间调用流程，如服务发现负载均衡，最后将请求发送给目标服务。这就是 Sidecar，它在原有的客户端和服务端之间加多了一个代理。 ◈ 多个服务调用的情况，Service Mesh 出现在所有的服务的下面，这一层被称之为服务间通讯专用基础设施层。Service Mesh 会接管整个网络，把所有的请求在服务之间做转发。在这种情况下，上面的服务不再负责传递请求的具体逻辑，只负责完成业务处理。服务间通讯的环节就从应用里面剥离出来，呈现出一个抽象层。\n如果有大量的服务，Sidecar 之间的连接就会形成一个网络，这个就是服务网格名字的由来。\n “我们将以 Service Mesh 为跳板再往前走。”鲁直表示，“Serverless 更多的还是应该聚焦在其字面本身，其含义就是‘无服务器’，后面的技术都是为了让无服务器承载具体的业务。”\nServerless 这个概念虽然提出来已经有几年了，目前 AWS 在 Serverless 和 FaaS 方面处于比较前沿的位置，但是在国内，Serverless、FaaS 这些技术的发展还是相对比较滞后。\n鲁直指出，“我觉得 Serverless 想要成功，还是要从覆盖业务的整个广度上打开，否则可能还是停留在 FaaS 上，那场景就比较受限。”\n Service Mesh 将是微服务的下一个时代，关于它还在持续进行理论研究和实践探索。\n 鲁直说：“坦白来讲，我觉得 istio 的理念非常好，但是在整个工程设计上，如果放到蚂蚁金服这样体量较大的环境里面，可能跑起来还需要做一些工作。我们希望今年 Service Mesh 在蚂蚁金服有了更大规模落地之后，可以把我们在 Service Mesh 方面的一些实践经验用到产品环境的工程中去实践，然后贡献出去。目前更多的一些工作，是将整个 …","date":1556607600,"description":"谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。-- 老王","dir":"blog/antfin-middleware-open-source-key-figure-luzhi/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6779f59b05648131b0d635a71cd95d0d","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","publishdate":"2019-04-30T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","summary":"本文转自 Linux 中国 谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。\u0026ndash; 老王 二月初春，在西子湖畔的细雨中，我拜访了蚂蚁金服中间","tags":["SOFAStack"],"title":"对话鲁直：蚂蚁金服中间件的开源头羊 | 穿山甲专访","type":"blog","url":"/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","wordcount":5979},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nGitHub 地址：https://github.com/sofastack/sofa-jraft\n之前，我们有一篇介绍 SOFAJRaft 的文章，可在文末获得链接，延续这个内容，今天的演讲分为三部分，先简要介绍 Raft 算法，然后介绍 SOFAJRaft 的设计，最后说说它的优化。\n分享嘉宾：力鲲 蚂蚁金服 SOFAJRaft 核心成员\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务。 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\nLeader 选举 复制状态机集群在利用 Raft 算法保证一致性时，要做的第一件事情就是 Leader 选举。在讲 Leader 选举之前我们先要说一个重要的概念：Term。Term 用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求；\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳；\n 当然了，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。\n当选举 Leader 成功之后，整个集群就可以向外提供正常读写服务了，如图所示，集群由一个 Leader 两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳或者把 Log 复制给 Follower。\nLog 复制 下面我们就详细说一下 Log 复制。我们之前已经说了 Log 就是 Client 发送给复制状态机的一系列命令。这里我们再举例解释一下 Log，比如我们的复制状态机要实现的是一个银行账户系统，那么这个 Log 就可以是 Client 发给账户系统的一条存钱的命令，比如“存 100 元钱”。\nLeader 与 Follower 之间的日志复制是共识算法运用于复制状态机的重要目的，在 Raft 算法中 Log 由 TermId、LogIndex、LogValue 这三要素构成，在这张图上每一个小格代表一个 Log。当 Leader 在向 Follower 复制 Log 的时候，Follower 还需要对收到的 Log 做检查，以确保这些 Log 能和本地已有的 Log 保持连续。我们之前说了，Raft 算法是要严格保证 Log 的连续性的，所以 Follower 会拒绝无法和本地已有 Log 保持连续的复制请求，那么这种情况下就需要走 Log 恢复的流程。总之，Log 复制的目的就是要让所有的 Server 上的 Log 无论在内容上还是在顺序上都要保持完全一致，这样才能保证所有状态机执行结果一致。\n目前已经有一些很优秀的对 Raft 的实现，比如 C++ 写的 braft，Go 写的 etcd，Rust 写的 TiKV。当然了，SOFAJRaft 并不是 Raft 算法的第一个 Java 实现，在我们之前已经有了很多项目。但是经过我们的评估，觉得目前还是没有一个 Raft 的 Java 实现库类能够满足蚂蚁生产环境的要求，这也是我们去写 SOFAJRaft 的主要原因。\nSOFAJRaft 介绍 接下来我们介绍 SOFAJRaft。 SOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。从去年 3 月开发到今年 2 月完成，并在今年 3 月开源。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统，目前使用案例有 RheaKV，这是 SOFAJRaft 中自带的一个分布式 KV 存储，还有今天开源的 SOFA 服务注册中心中的元信息管理模块也是用到了 SOFAJRaft，除此之外还有一些内部的项目也有使用，但是因为没有开源，所以就不再详述了。\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依 …","date":1556202600,"description":"本文根据 SOFAChannel#4 直播分享整理，主题：SOFAJRaft 详解。","dir":"blog/sofa-jraft-deep-dive/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f2d4559ece4184ef09b96899a1aeb900","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-deep-dive/","publishdate":"2019-04-25T14:30:00Z","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-jraft-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFAJRaft","剖析 | SOFAJRaft 实现原理","SOFALab"],"title":"蚂蚁金服开源 SOFAJRaft 详解| 生产级高性能 Java 实现","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-deep-dive/","wordcount":5688},{"author":"琪祥","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。 GitHub 地址：https://github.com/sofastack/sofa-registry \n 3 月 31 日，蚂蚁金服正式开源了内部演进了近 10 年的注册中心产品-SOFARegistry。先前的文章介绍了 SOFARegistry 的演进之路，而本文主要对 SOFARegistry 整体架构设计进行剖析，并着重介绍一些关键的设计特点，期望能帮助读者对 SOFARegistry 有更直接的认识。\n如有兴趣，也欢迎加入《剖析 | SOFARegistry 实现原理》系列的共建，认领列表见文末。\n服务注册中心是什么 不可免俗地，先介绍一下服务注册中心的概念。对此概念已经了解的读者，可选择跳过本节。\n如上图，服务注册中心最常见的应用场景是用于 RPC 调用的服务寻址，在 RPC 远程过程调用中，存在 2 个角色，一个服务发布者（Publisher）、另一个是服务订阅者（Subscriber）。Publisher 需要把服务注册到服务注册中心（Registry），发布的内容通常是该 Publisher 的 IP 地址、端口、调用方式 （协议、序列化方式）等。而 Subscriber 在第一次调用服务时，会通过 Registry 找到相应的服务的 IP 地址列表，通过负载均衡算法从 IP 列表中取一个服务提供者的服务器调用服务。同时 Subscriber 会将 Publisher 的服务列表数据缓存到本地，供后续使用。当 Subscriber 后续再调用 Publisher 时，优先使用缓存的地址列表，不需要再去请求Registry。\n如上图，Subscriber 还需要能感知到 Publisher 的动态变化。比如当有 Publisher 服务下线时， Registry 会将其摘除，随后 Subscriber 感知到新的服务地址列表后，不会再调用该已下线的 Publisher。同理，当有新的 Publisher 上线时，Subscriber 也会感知到这个新的 Publisher。\n初步认识 在理解了常见的服务注册中心的概念之后，我们来看看蚂蚁金服的 SOFARegistry 长什么样子。如上图，SOFARegistry 包含 4 个角色：\n Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\n SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\n DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。\n MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n产品特点 （图片改编自 https://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products ）\n首先放一张常见的服务注册中心的特性对比，可以看出，在这些 Feature 方面，SOFARegistry 并不占任何优势。那么，我们为什么还开源这样的一个系统？SOFARegistry 开源的优势是什么？下面将着重介绍 SOFARegistry 的特点。\n支持海量数据 大部分的服务注册中心系统，每台服务器都是存储着全量的服务注册数据，服务器之间依靠一致性协议（如 Paxos/Raft/2PC 等）实现数据的复制，或者只保证最终一致性的异步数据复制。“每台服务器都存储着全量的服务注册数据”，在一般规模下是没问题的。但是在蚂蚁金服庞大的业务规模下，服务注册的数据总量早就超过了单台服务器的容量瓶颈。\nSOFARegistry 基于一致性 Hash 做了数据分片，每台 DataServer 只存储一部分的分片数据，随数据规模的增长，只要扩容 DataServer 服务器即可。这是相对服务发现领域的其他竞品来说最大的特点，详细介绍见后面《如何支持海量数据》一节。\n支持海量客户端 SOFARegistry 集群内部使用分层的架构，分别为连接会话层（SessionServer）和数据存储层（DataServer）。SessionServer 功能很纯粹，只负责跟 Client 打交道，SessionServer 之间没有任何通信或数据复制，所以随着业务规模（即 Client 数量）的增长，SessionServer 可以很轻量地扩容，不会对集群造成额外负担。\n相比之下，其他大多数的服务发现组件，如 eureka，每台服务器都存储着全量的数据，依靠 eurekaServer 之间的数据复制来传播到整个集群，所以每扩容 1 台 eurekaServer，集群内部相互复制的数据量就会增多一份。再如 Zookeeper 和 Etcd 等强一致性的系统，它们的复制协议（Zab/Raft）要求所有写操作被复制到大多数服务器后才能返回成功，那么增加服务器还会影响写操作的效率。\n秒级的服务上下线通知 对于服务的上下线变化，SOFARegistry 使用推送机制，快速地实现端到端的传达。详细介绍见后面《秒级服务上下线通知》一节。\n接下来，我将围绕这些特点，讲解 SOFARegistry 的关键架构设计原理。\n高可用 各个角色都有 failover 机制：\n MetaServer 集群部署，内部基于 Raft 协议选举和复制，只要不超过 1\u0026amp;frasl;2 节点宕机，就可以对外服务。 DataServer 集群部署，基于一致性 Hash 承担不同的数据分片，数据分片拥有多个副本，一个主副本和多个备副本。如果 DataServer 宕机，MetaServer 能感知，并通知所有 DataServer 和 SessionServer，数据分片可 failover 到其他副本，同时 DataServer 集群内部会进行分片数据的迁移。 SessionServer 集群部署，任何一台 SessionServer 宕机时 Client 会自动 failover 到其他 SessionServer，并且 Client …","date":1556175600,"description":"本文为《剖析 | SOFARegistry 框架》第一篇，本篇作者琪祥。","dir":"blog/sofa-registry-introduction/","fuzzywordcount":11100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"04394de7d7b0ecba5303baa6949a40d4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-introduction/","publishdate":"2019-04-25T15:00:00+08:00","readingtime":23,"relpermalink":"/sofastack.tech/blog/sofa-registry-introduction/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"海量数据下的注册中心 - SOFARegistry 架构介绍","type":"blog","url":"/sofastack.tech/blog/sofa-registry-introduction/","wordcount":11079},{"author":"觉生","categories":"Seata","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。 Seata：https://github.com/seata/seata 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23127468，不错过每场直播。\n 2019 年 3 月，蚂蚁金服加入分布式事务 Seata 的社区共建中，并贡献其 TCC 模式。本期是 SOFAChannel 第四期，主题：分布式事务 Seata TCC 模式深度解析，本文根据觉生的直播整理。\n大家晚上好，我是 Seata Committer 觉生，来自蚂蚁金服数据中间件团队。今天的内容主要分为以下四个部分：\n Seata TCC 模式的原理解析； 从 TCC 的业务模型与并发控制分享如何设计一个 TCC 接口，并且适配 TCC 模型； 如何控制异常； 性能优化，使得 TCC 模式能够满足更高的业务需求。 1、 Seata 的 TCC 模式 1.1 服务化拆分 下面我们就进入第一个主题，Seata 的 TCC 模式。蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个系统中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，而网络、机器等不可靠，数据一致性的问题很容易出现，与可扩展性、高可用容灾等要求并肩成为金融 IT 架构支撑业务转型升级的最大挑战之一。\n从图中可以看到，从单系统到微服务转变，其实是一个资源横向扩展的过程，资源的横向扩展是指当单台机器达到资源性能瓶颈，无法满足业务增长需求时，就需要横向扩展资源，形成集群。通过横向扩展资源，提升非热点数据的并发性能，这对于大体量的互联网产品来说，是至关重要的。服务的拆分，也可以认为是资源的横向扩展，只不过方向不同而已。\n资源横向扩展可能沿着两个方向发展，包括业务拆分和数据分片：\n 业务拆分。根据功能对数据进行分组，并将不同的微服务分布在多个不同的数据库上，这实际上就是 SOA 架构下的服务化。业务拆分就是把业务逻辑从一个单系统拆分到多个微服务中。\n 数据分片。在微服务内部将数据拆分到多个数据库上，为横向扩展增加一个新的维度。数据分片就是把一个微服务下的单个 DB 拆分成多个 DB，具备一个 Sharding 的功能。通过这样的拆解，相当于一种资源的横向扩展，从而使得整个架构可以承载更高的吞吐。\n 横向扩展的两种方法可以同时进行运用：交易、支付与账务三个不同微服务可以存储在不同的数据库中。另外，每个微服务内根据其业务量可以再拆分到多个数据库中，各微服务可以相互独立地进行扩展。\nSeata 关注的就是微服务架构下的数据一致性问题，是一整套的分布式事务解决方案。Seata 框架包含两种模式，一种是 AT 模式。AT 模式主要从数据分片的角度，关注多 DB 访问的数据一致性，当然也包括多服务下的多 DB 数据访问一致性问题。\n另外一个就是 TCC 模式，TCC 模式主要关注业务拆分，在按照业务横向扩展资源时，解决微服务间调用的一致性问题，保证读资源访问的事务属性。\n今天我们主要讲的就是TCC模式。在讲 TCC 之前，我们先回顾一下 AT 模式，这样有助于我们理解后面的 TCC 模式。\n1.2. AT 模式 对于 AT 模式，之前其他同学已经分享过很多次，大家也应该比较熟悉了。AT 模式下，把每个数据库被当做是一个 Resource，Seata 里称为 DataSource Resource。业务通过 JDBC 标准接口访问数据库资源时，Seata 框架会对所有请求进行拦截，做一些操作。每个本地事务提交时，Seata RM（Resource Manager，资源管理器） 都会向 TC（Transaction Coordinator，事务协调器） 注册一个分支事务。当请求链路调用完成后，发起方通知 TC 提交或回滚分布式事务，进入二阶段调用流程。此时，TC 会根据之前注册的分支事务回调到对应参与者去执行对应资源的第二阶段。TC 是怎么找到分支事务与资源的对应关系呢？每个资源都有一个全局唯一的资源 ID，并且在初始化时用该 ID 向 TC 注册资源。在运行时，每个分支事务的注册都会带上其资源 ID。这样 TC 就能在二阶段调用时正确找到对应的资源。\n这就是我们的 AT 模式。简单总结一下，就是把每个数据库当做一个 Resource，在本地事务提交时会去注册一个分支事务。\n1.3 TCC 模式 那么对应到 TCC 模式里，也是一样的，Seata 框架把每组 TCC 接口当做一个 Resource，称为 TCC Resource。这套 TCC 接口可以是 RPC，也以是服务内 JVM 调用。在业务启动时，Seata 框架会自动扫描识别到 TCC 接口的调用方和发布方。如果是 RPC 的话，就是 sofa:reference、sofa:service、dubbo:reference、dubbo:service 等。\n扫描到 TCC 接口的调用方和发布方之后。如果是发布方，会在业务启动时向 TC 注册 TCC Resource，与DataSource Resource 一样，每个资源也会带有一个资源 ID。\n如果是调用方，Seata 框架会给调用方加上切面，与 AT 模式一样，在运行时，该切面会拦截所有对 TCC 接口的调用。每调用一次 Try 接口，切面会先向 TC 注册一个分支事务，然后才去执行原来的 RPC 调用。当请求链路调用完成后，TC 通过分支事务的资源ID回调到正确的参与者去执行对应 TCC 资源的 Confirm 或 Cancel 方法。\n在讲完了整个框架模型以后，大家可能会问 TCC 三个接口怎么实现。因为框架本身很简单，主要是扫描 TCC 接口，注册资源，拦截接口调用，注册分支事务，最后回调二阶段接口。最核心的实际上是 TCC 接口的实现逻辑。下面我将根据蚂蚁金服内部多年的实践来为大家分析怎么实现一个完备的 TCC 接口。\n2、 TCC 业务模型与并发控制 2.1 TCC 设计原则 从 TCC 模型的框架可以发现，TCC 模型的核心在于 TCC 接口的设计。用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。下面我会分享蚂蚁金服内多年的 TCC 应用实践以及在 TCC 设计和实现过程中的注意事项。\n设计一套 TCC 接口最重要的是什么？主要有两点，第一点，需要将操作分成两阶段完成。TCC（Try-Confirm-Cancel）分布式事务模型相对于 XA 等传统模型，其特征在于它不依赖 RM 对分布式事务的支持，而是通过对业务逻辑的分解来实现分布式事务。\nTCC 模型认为对于业务系统中一个特定的业务逻辑 ，其对外提供服务时，必须接受一些不确定性，即对业务逻辑初步操作的调用仅是一个临时性操作，调用它的主业务服务保留了后续的取消权。如果主业务服务认为全局事务应该回滚，它会要求取消之前的临时性操作，这就对应从业 …","date":1556089200,"description":"本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。","dir":"blog/sofa-channel-4-retrospect/","fuzzywordcount":10500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"75094c50f180bcd31d84bc687e4c93e0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-4-retrospect/","publishdate":"2019-04-24T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/sofa-channel-4-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。 Seata：https://","tags":["Seata","SOFAChannel"],"title":"分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-4-retrospect/","wordcount":10459},{"author":"青勤","categories":"SOFAActs","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23195297，不错过每场直播。\n 大家晚上好，我是蚂蚁金服自动化测试框架 SOFAActs 开源核心成员青勤，目前从事测试技术相关的研发工作，今晚将由我来给大家分享交流自动化测试框架 SOFAActs 的基本原理和使用，今天的内容主要分为以下四个章节：\n 项目介绍 SOFAActs 接入 功能介绍与使用 升阶功能使用 欢迎大家 Star 我，SOFAActs：https://github.com/sofastack/sofa-acts\n1 项目介绍 在分享使用操作前，我将引导大家来熟悉下 SOFAActs 的项目背景、基本原理等。\n对于研发质量保障而言，金融系统和金融业务的多样性、复杂性同样也会在测试场景、测试验证和测试流程的复杂程度上得到充分体现。\n譬如，对于包含出参、RPC 调用、DB 变更和异常等多个测试验证点的用例而言，在研发和测试人员维护和验证用例场景的过程中，时常发生业务结果校验遗漏，对我们及早发现和纠错问题造成干扰，进而无法严格保障产品质量。这些问题对研发质量保障提出了很高的挑战，相应的自动化、精细化的白盒测试工具需求日益增长，这其中就包括 SOFAActs。\n为了解决上述痛点、满足精细化测试需要，在多年测试实践积累与沉淀下，我们研发了基于模型驱动的 SOFAActs 测试框架，它可以灵活、可扩展的提供一站式用例管理，标准化测试执行和精细化校验。目前 SOFAActs 测试框架逐渐成熟并在蚂蚁金服内部得到广泛应用。\n1.1 项目架构 介绍完背景，我们来看下 SOFAActs 的大体框架，SOFAActs 底层封装并集成适配 SOFABoot 等运行环境。\n在重要的引擎层，SOFAActs 封装了工具类和数据模型，并将测试模式的过程进行了标准化，提供通用测试能力和扩展点。对于有自动化测试经验的同学来讲，测试模式其实并不复杂，这其中有很多工作是可以抽象和固定的，SOFAActs 将这部分内容内聚到引擎层，封装成标准测试流程等，尤其是模型驱动和精细化校验等，从而释放精力，将更多关注点聚焦在待测目标上。\n引擎层之上，是 SOFAActs 提供的可视化用例管理功能，可以一站式的维护测试脚本、测试数据和数据模型，借助可视化编辑器可成倍提高用例管理等等操作效率，整体而言 SOFAActs 围绕模型驱动引擎和可视化编辑器，将测试代码的编写工作量极尽降低，目标聚焦在测试对象上。\n这里我们示例看下，SOFAActs 对测试代码和效率的优化。这里以 Credit 接口为例，业务处理开始之前会检查传参，构造上下文、随后发起业务处理，涉及对三张表的读取或变更，并在数据库事物结束之后，返回业务处理结果。\n 针对这一业务逻辑，这里我们构造一个 Credit 接口的完整测试用例，在代码驱动测试时，它需要一下 9 个步骤，手动准备依赖数据、构造请求参数、执行业务逻辑、校验业务结果以及数据清理等等，人工介入成本居高，尤其当存在多个用例时，测试代码可复用性低，测试效率是难以得到有效提升。而与之对比，在模型驱动测试下，Credit 接口的 SOFAActs 测试脚本会对固有的测试模式进行封装，用例复杂度得到极大精简，众多用例数据可以得到高效的可视化管理。\n1.2 执行原理 在开始使用 SOFAActs 之前，我们来了解一下有关 SOFAActs 执行引擎的运作原理。SOFAActs 框架也提供了非常多的扩展点，如果需要个性化的定义，可以对每一个环节进行扩展。\n上文中已提到过 SOFAActs 执行引擎是对测试模式过程的封装，Setup 方法是引擎入口，用于加载初始化 SOFAActs 运行时的必需资源，如获取数据源。\n以下是主体测试过程：clear、prepare、execute、check 这 4 个方法依次负责环境清理、依赖准备、执行、结果校验等。这些内容是代码驱动测试时需要手写的测试代码和内容，每个测试脚本的完成意味着上面的过程会被我们重复一遍，于是 SOFAActs 将这部分内容进行了封装，实现了最通用基础的功能。\n右侧，我们对高频数据如方法入参、出参、异常和依赖DB数据进行了抽象，给出 SOFAActs 的模型，这是代码驱动转向模型驱动、精细化校验的基础。左侧的数据总线会贯穿每个用例的执行生命周期，即贯穿中间的主体测试过程，如果大家对框架封装的基础功能有自定义需要，可以通过数据总线对 SOFAActs 的对象、方法进行获取、重写，以便更灵活的控制框架行为。当然 SOFAActs 对这些内容作了较好的封装，覆盖了大部分的测试需求，无需大家过度关注。\n以上就是 SOFAActs 的执行原理，接下来我会给大家详细介绍 SOFAActs 的接入和使用。\n2 SOFAActs 接入 SOFAActs 分为两部分，其一是可视化编辑器，在 [SOFAStack 官网上 1 我们可以获取该编辑器的安装包，并通过 IDEA 的插件管理进行安装。其二是 SOFAActs 的基础 jar，它提供了 SOFAActs 用例运行的环境支持，在 test 模块 pom 中添加下列依赖即可，有关 test 模块或者多模块详细内容大家可以参考 [SOFAActs 的快速开始文档 1 。\n3 功能介绍和使用 下面，我们进入 SOFAActs 的功能介绍和使用章节，这部分我将分为三小节展开：一站式构建、SOFAActs 核心的模型驱动以及 SOFAActs 提供的精准校验。\n3.1 一站式构建 一站式构建中，SOFAActs 通过可视化编辑器为我们提供了便捷操作，以帮助一键配置初始化、构建测试脚本与模型，可视化管理用例数据等等。借助可视化编辑器，在整个过程中我们可以替换大部分手工编写代码的工作，进行一站式操作。\n一键初始化\n这里我们示例看下，如何操作一键初始化以及一键初始化做哪些内容。首先一键初始化框架只需要 3 个鼠标点击步骤。在 Package 视图下选中测试模块并右键选择 SOFAActs 功能，一键初始化，输入该应用的应用名称和工程编码格式。在一键初始化完成后，SOFAActs 将会在 test 模块写入 SOFAActs 配置文件，DB 连接配置文件，测试套件配置文件以及创建模型存储目录等。\n acts-config 配置文件是 SOFAActs 的核心配置，提供了测试环境切换、数据库连接切换、冒烟测试以及预跑反填等配置，来开关 SOFAActs 的相关功能；model 目录用于存放对象模型、数据模型，以便对模型进行统一管理；DB 配置文件指明了数据库连接信息，用于生成数据模型时自动填充表结构和模版数据。\n一键生成测试脚本\n在完成配置初始化操作后，我们可以开始第一个用例的编写，SOFAActs 提供了一键测试脚本生成功能。以待测的 getMessage 接口为例，在其方法定义上右键选择 SOFAActs 功能，生成测试用例，在弹出框中检查用例信息，修正无误后点击确定可以生成该 …","date":1556089200,"description":"本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。","dir":"blog/sofa-channel-5-retrospect/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1f088b226caf9430dc6aafb3f248316d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-5-retrospect/","publishdate":"2019-04-24T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-5-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAAc","tags":["SOFAActs","SOFAChannel"],"title":"给研发工程师的代码质量利器 | SOFAChannel#5 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-5-retrospect/","wordcount":5492},{"author":"SOFAStack","categories":"SOFAStack","content":"Hey, SOFAer！有些话想对你说：\n“开源”二字代表的不仅仅是一个项目，更是代表了整个技术社区，代表了隐藏在背后的工程师们。\n很幸运，这一年遇到你们。\n生于蚂蚁金服，经历 12 年的业务锤炼，这是金融级分布式架构 SOFAStack。SOFAStack 的发展受益于开源社区的优秀产品，我们也决定结合我们的实践积累，把这些技术反馈给开源社区。\n于是，2018 年 4 月，SOFAStack 宣布开源，项目地址：https://github.com/alipay 。\n这一年，SOFAStack 逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFABolt、SOFAMosn、SOFAMesh、SOFAJRaft、SOFAActs、SOFARegistry 等组件。2019 年 3 月，蚂蚁金服加入分布式事务 Seata 的社区共建中，并贡献其 TCC 模式。\n这一年，我们获得了 14,000+ Star，超过 100 位贡献者参与，并有超过 30 家企业用户将 SOFAStack 应用在了生产环境上。\n这一年，SOFAStack 团队从电脑屏幕前，走到了开源社区里，与大家讨论并吸纳社区的建议。\n这一年，尝试了很多的“第一次”：第一次与大家编写 SOFALab 源码解析系列文章，第一次做 SOFAChannel 技术直播，第一次组织 SOFAMeetup，第一次在开源技术大会演讲。\n嘿，或许你见过我们紧张的样子。\n这一年，我们得到了太多来自社区的帮助，因为你们，SOFAStack 团队能一直享受“Make something people want”的乐趣。\n这一年，感谢有你。Hey, SOFAer~有些话想对你说：\n戳这里\n","date":1555333200,"description":"这一年，感谢有你。","dir":"blog/sofastack-anniversary-1/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"82d2afd98352ab185691773fcd616233","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-anniversary-1/","publishdate":"2019-04-15T21:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofastack-anniversary-1/","summary":"Hey, SOFAer！有些话想对你说： “开源”二字代表的不仅仅是一个项目，更是代表了整个技术社区，代表了隐藏在背后的工程师们。 很幸运，这一年遇到你","tags":["SOFAStack"],"title":"Hey, SOFAer！有些话想对你说：","type":"blog","url":"/sofastack.tech/blog/sofastack-anniversary-1/","wordcount":639},{"author":"李钊","categories":"Seata","content":" 本文作者李钊，公众号「咖啡拿铁」作者，分布式事务 Seata 社区 Contributor。\n1.关于 Seata 在前不久，我写了一篇关于分布式事务中间件 Fescar 的解析，没过几天 Fescar 团队对其进行了品牌升级，取名为 Seata(Simpe Extensible Autonomous Transcaction Architecture)，而以前的 Fescar 的英文全称为 Fast \u0026amp;amp; EaSy Commit And Rollback。可以看见 Fescar 从名字上来看更加局限于 Commit 和 Rollback，而新的品牌名字 Seata 旨在打造一套一站式分布式事务解决方案。更换名字之后，我对其未来的发展更有信心。\n这里先大概回忆一下 Seata 的整个过程模型：\n TM：事务的发起者。用来告诉 TC，全局事务的开始，提交，回滚。 RM：具体的事务资源，每一个 RM 都会作为一个分支事务注册在 TC。 TC 事务的协调者。也可以看做是 Fescar-server，用于接收我们的事务的注册，提交和回滚。 在之前的文章中对整个角色有个大体的介绍，在这篇文章中我将重点介绍其中的核心角色 TC，也就是事务协调器。\n2.Transaction Coordinator 为什么之前一直强调 TC 是核心呢？那因为 TC 这个角色就好像上帝一样，管控着芸芸众生的 RM 和 TM。如果 TC 一旦不好使，那么 RM 和 TM 一旦出现小问题，那必定会乱的一塌糊涂。所以要想了解 Seata，那么必须要了解他的 TC。\n那么一个优秀的事务协调者应该具备哪些能力呢？我觉得应该有以下几个：\n 正确的协调：能正确的协调 RM 和 TM 接下来应该做什么，做错了应该怎么办，做对了应该怎么办。 高可用：事务协调器在分布式事务中很重要，如果不能保证高可用，那么他也没有存在的必要了。 高性能：事务协调器的性能一定要高，如果事务协调器性能有瓶颈，那么他所管理的 RM 和 TM 会经常遇到超时，从而引起回滚频繁。 高扩展性：这个特点是属于代码层面的，如果是一个优秀的框架，那么需要给使用方很多自定义扩展，比如服务注册/发现，读取配置等等。 下面我也将逐步阐述 Seata 是如何做到上面四点。\n2.1 Seata-Server 的设计 Seata-Server 整体的模块图如上所示：\n Coordinator Core：最下面的模块是事务协调器核心代码，主要用来处理事务协调的逻辑，如是否 Commit、Rollback 等协调活动。 Store：存储模块，用来将我们的数据持久化，防止重启或者宕机数据丢失。 Discover：服务注册/发现模块，用于将 Server 地址暴露给 Client。 Config：用来存储和查找服务端的配置。 Lock：锁模块，用于给 Seata 提供全局锁的功能。 Rpc：用于和其他端通信。 HA-Cluster：高可用集群，目前还没开源。为 Seata 提供可靠的高可用功能。 2.2 Discover 首先来讲讲比较基础的 Discover 模块，又称服务注册/发现模块。我们将 Seata-Server 启动之后，需要将自己的地址暴露给其他使用者，那么就需要这个模块帮忙。\n这个模块有个核心接口 RegistryService，如上图所示：\n register：服务端使用，进行服务注册。 unregister：服务端使用，一般在 JVM 关闭钩子，ShutdownHook 中调用。 subscribe：客户端使用，注册监听事件，用来监听地址的变化。 unsubscribe：客户端使用，取消注册监听事件。 lookup：客户端使用，根据 Key 查找服务地址列表。 close：都可以使用，用于关闭 Register 资源。 如果需要添加自己定义的服务注册/发现，那么实现这个接口即可。截止目前在社区的不断开发推动下，已经有四种服务注册/发现，分别是 redis、zk、nacos、eruka。下面简单介绍下 Nacos 的实现：\n2.2.1 register 接口 step1：校验地址是否合法；\nstep2：获取 Nacos 的 Name 实例，然后将地址注册到当前 Cluster 名称上面。\nunregister 接口类似，这里不做详解。\n2.2.2 lookup 接口 step1：获取当前 clusterName 名字；\nstep2：判断当前 Cluster 是否已经获取过了，如果获取过就从 Map 中取；\nstep3：从 Nacos 拿到地址数据，将其转换成我们所需要的；\nstep4：将我们事件变动的 Listener 注册到 Nacos。\n2.2.3 subscribe 接口 这个接口比较简单，具体分两步：\nstep1：将 Clstuer 和 Listener 添加进 Map 中；\nstep2：向 Nacos 注册。\n2.3 Config 配置模块也是一个比较基础，比较简单的模块。我们需要配置一些常用的参数比如：Netty 的 Select 线程数量，Work 线程数量，Session 允许最大为多少等等，当然这些参数在 Seata 中都有自己的默认设置。\n同样的在 Seata 中也提供了一个接口 Configuration，用来自定义我们需要的获取配置的地方：\n getInt/Long/Boolean/Config()：通过 DataId 来获取对应的值。 putConfig：用于添加配置。 removeConfig：删除一个配置。 add/remove/get ConfigListener：添加/删除/获取 配置监听器，一般用来监听配置的变更。 目前为止有四种方式获取 Config：File（文件获取）、Nacos、Apollo、ZK。在 Seata 中首先需要配置 registry.conf，来配置 conf 的类型。实现 conf 比较简单这里就不深入分析。\n2.4 Store 存储层的实现对于 Seata 是否高性能，是否可靠非常关键。\n如果存储层没有实现好，那么如果发生宕机，在 TC 中正在进行分布式事务处理的数据将会被丢失。既然使用了分布式事务，那么其肯定不能容忍丢失。如果存储层实现好了，但是其性能有很大问题，RM 可能会发生频繁回滚那么其完全无法应对高并发的场景。\n在 Seata 中默认提供了文件方式的存储，下面定义存储的数据为 Session，而 TM 创造的全局事务数据叫 GloabSession，RM 创造的分支事务叫 BranchSession，一个 GloabSession 可以拥有多个 BranchSession。我们的目的就是要将这么多 Session 存储下来。\n在 FileTransactionStoreManager#writeSession 代码中：\n上面的代码主要分为下面几步：\nstep1：生成一个 TransactionWriteFuture。\nstep2：将这个 futureRequest 丢进一个 LinkedBlockingQueue 中。为什么需要将所有数据都丢进队列中呢？当然这里其实也可以用锁来实现，在 …","date":1554793200,"description":"在这篇文章，将重点介绍 Seata 其中的核心角色 TC，也就是事务协调器。","dir":"blog/seata-server-deep-analysis/","fuzzywordcount":6900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3354370f3ca29297c819c279994e0a0d","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-server-deep-analysis/","publishdate":"2019-04-09T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/seata-server-deep-analysis/","summary":"本文作者李钊，公众号「咖啡拿铁」作者，分布式事务 Seata 社区 Contributor。 1.关于 Seata 在前不久，我写了一篇关于分布式事务中间件 Fescar 的解析，没","tags":["Seata"],"title":"深度剖析一站式分布式事务方案 Seata-Server","type":"blog","url":"/sofastack.tech/blog/seata-server-deep-analysis/","wordcount":6831},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 活动时间：4 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 4月初，分布式事务 Fescar 宣布进行品牌升级为 Seata，Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n本期为 SOFAChannel 线上直播第 4 期，将邀请 蚂蚁金服 技术专家 \u0026amp;amp; Seata Committer 觉生 和大家一起探讨 《分布式事务 Seata TCC 模式深度解析》。\n本期分享大纲：\n TCC 模式基本原理解析 分布式事务并发控制解析 分布式事务空回滚与幂等解析 分布式事务防悬挂解析 分布式事务异步化解析 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/462\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 分布式事务 Seata TCC 模式深度解析 觉生 蚂蚁金服 技术专家 / Seata Committer\n本期分享大纲： TCC 模式基本原理解析 分布式事务并发控制解析 分布式事务空回滚与幂等解析 分布式事务防悬挂解析 分布式事务异步化解析 嘉宾 SOFAGirl 主持人 觉生 蚂蚁金服 技术专家 / Seata Committer ","date":1554783000,"description":"4 月 18 日周四晚 7 点，线上直播第 4 期。","dir":"activities/sofa-channel-4/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0e0d4d4a75723cc408567a65aab0c3df","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-4/","publishdate":"2019-04-09T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-4/","summary":"概要 活动主题：SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 活动时间：4 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介","tags":["SOFAChannel","Seata"],"title":"SOFAChannel#4：分布式事务 Seata TCC 模式深度解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-4/","wordcount":551},{"author":"绍辉","categories":"Seata","content":" 上周，分布式事务 Fescar 宣布进行品牌升级：\nThanks, Fescar ❤️，\nHello, Seata 🚀。\nSeata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。\n项目地址：https://github.com/seata/seata\n蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n为了帮助大家理解，分布式事务开源负责人绍辉进行了一次线下分享，详细讲述了分布式事务在蚂蚁金服的发展，希望可以帮助大家理解分布式事务，以下为分享的文字整理版本。\n前言 今天的分享将从以下三个部分展开：分布式事务问题产生的背景、蚂蚁金服分布式事务以及分布式事务 Seata 的 Roadmap。\n分享嘉宾：绍辉 蚂蚁金服 分布式事务开源负责人\n1、分布式事务问题产生的背景 1.1、数据库的水平拆分 蚂蚁金服早期，业务量比较小，单库单表便能满足业务需求；但是随着业务的发展，单库单表数据库逐渐成为瓶颈。为了解决数据库的瓶颈问题，我们对数据库进行了水平拆分。拆分所带来的一个问题就是以前一个数据库上便能完成的写操作现在要跨多个数据库，由此带来了跨库事务问题。\n1.2、业务的服务化拆分 蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个 APP 中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，由此产生了跨服务事务问题。\n1.3、转账案例说明数据一致性问题 数据库的水分拆分以及服务的垂直拆分，所带来的问题是一个业务活动通常要调用多个服务、访问多个数据库才能完成。\n以金融业务场景下的转账场景为例，转账服务要完成以下操作：\n 调用交易系统服务创建交易订单； 调用支付系统记录支付明细； 调用账务系统执行 A 扣钱； 调用账务系统执行 B 加钱。 以上 4 个操作要跨 3 个系统，访问 4 个数据库。而网络、数据库、机器等都具有不可靠性，我们很难保证以上 4 个操作能 100% 全部成功。\n在金融属性的业务中，不允许 A 账户的钱扣了，而 B 账户的钱没有加上的现象出现，所以我们必须想办法保证 1 ~ 4 这四个操作要么全部成功，要么全部失败；所以蚂蚁金服自主研发了分布式事务中间件，解决跨服务、跨数据库的数据一致性问题。\n2、蚂蚁金服分布式事务 2.1、分布式事务理论基础 在介绍蚂蚁金服的分布式事务中间件之前，先介绍一些分布式事务的理论背景。\n 2PC 两阶段提交协议（Two Phase Commitment Protocol）是分布式事务最基本的协议。在两阶段提交协议中，有一个事务管理器和多个资源管理器，事务管理器分两阶段协调资源管理器。在第一阶段，事务管理器询问所有资源管理器准备是否成功。如果所有资源均准备成功，那么在第二阶段事务管理器会要求所有资源管理器执行提交操作；如果任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求所有资源管理器在第二阶段执行回滚操作。通过事务管理器的两阶段协调，最终所有资源管理器要么全部提交，要么全部回滚，最终状态都是一致的。\n TCC 资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现。TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题。TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中。事务管理器分两个阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法，最终所有 TCC 服务要么全部都是提交的、要么全部都是回滚的。\n2.2、蚂蚁金服分布式产品介绍 蚂蚁金服从 2007 年开始做分布式事务，至今已经有 12 年历史。蚂蚁金服的分布式事务最初是采用 TCC 实现的，TCC 模式帮蚂蚁业务解决了各类金融核心场景下的数据一致性问题。\n2007 年我们开始支持双十一，为了满足双十一的高性能需求，我们对分布式事务做了一系列的性能优化。\n2013年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014年，蚂蚁金服分布式事务中间件开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户；在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。\n所以在 2015年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务中间件经过长期演进，目前积累了 TCC、FMT 和 XA 三种模式，具有丰富的应用场景。下面分别介绍这三种模式。\n2.3、TCC 模式 蚂蚁金服的 TCC 模式和前面介绍 TCC 理论中提的 TCC 原理是一致的。不同的是，我们在整个分布式事务执行过程中，会去记录事务日志，一个分布式事务会产生一条主事务记录（对应发起方）和若干分支事务记录（对应 TCC 参与者）。记录事务日志的目的是，当分布式事务执行过程中出现异常中断时，事务恢复服务通过轮询事务日志，找出这个异常中断的事务，补偿执行该异常事务剩余未完成的动作，整个分布式事务的最终状态要么全部提交，要么全部回滚。\nTCC 设计规范和注意事项：\n用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。经过蚂蚁金服多年的 TCC 应用实践，总结如下在 TCC 设计和实现过程中的注意事项：\n1、业务操作分两阶段完成： 接入 TCC 前，业务操作只需要一步就能完成。但是在接入 TCC 之后，需要考虑如何将其分成两个阶段完成：把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户 A 的余额中有 100 元，需要扣除其中 30 元”。\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成两步完成：\n Try 操作：资源的检查和预留。 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交。 在扣款场景下，Confirm 阶段 …","date":1554706800,"description":"本文根据 SOFAMeetup#1 分享整理，详细讲述了分布式事务在蚂蚁金服的发展。","dir":"blog/sofa-meetup-1-seata/","fuzzywordcount":5000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fd2c8c1c6ee4231c6987a1d556ce4089","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-seata/","publishdate":"2019-04-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-seata/","summary":"上周，分布式事务 Fescar 宣布进行品牌升级： Thanks, Fescar ❤️， Hello, Seata 🚀。 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。 项","tags":["Seata","SOFAMeetup"],"title":"蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-seata/","wordcount":4909},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享视频回顾获取方式见文章底部。\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nGitHub 地址：https://github.com/alipay/sofa-jraft\n之前，我们有一篇介绍 SOFAJRaft 的文章，可在文末获得链接，延续这个内容，今天的演讲分为三部分，先简要介绍 Raft 算法，然后介绍 SOFAJRaft 的设计，最后说说它的优化。\n分享嘉宾：力鲲 蚂蚁金服 SOFAJRaft 核心成员\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务。 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\nLeader 选举 复制状态机集群在利用 Raft 算法保证一致性时，要做的第一件事情就是 Leader 选举。在讲 Leader 选举之前我们先要说一个重要的概念：Term。Term 用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求； 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳； 当然了，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。\n当选举 Leader 成功之后，整个集群就可以向外提供正常读写服务了，如图所示，集群由一个 Leader 两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳或者把 Log 复制给 Follower。\nLog 复制 下面我们就详细说一下 Log 复制。我们之前已经说了 Log 就是 Client 发送给复制状态机的一系列命令。这里我们再举例解释一下 Log，比如我们的复制状态机要实现的是一个银行账户系统，那么这个 Log 就可以是 Client 发给账户系统的一条存钱的命令，比如“存 100 元钱”。\nLeader 与 Follower 之间的日志复制是共识算法运用于复制状态机的重要目的，在 Raft 算法中 Log 由 TermId、LogIndex、LogValue 这三要素构成，在这张图上每一个小格代表一个 Log。当 Leader 在向 Follower 复制 Log 的时候，Follower 还需要对收到的 Log 做检查，以确保这些 Log 能和本地已有的 Log 保持连续。我们之前说了，Raft 算法是要严格保证 Log 的连续性的，所以 Follower 会拒绝无法和本地已有 Log 保持连续的复制请求，那么这种情况下就需要走 Log 恢复的流程。总之，Log 复制的目的就是要让所有的 Server 上的 Log 无论在内容上还是在顺序上都要保持完全一致，这样才能保证所有状态机执行结果一致。\n目前已经有一些很优秀的对 Raft 的实现，比如 C++ 写的 braft，Go 写的 etcd，Rust 写的 TiKV。当然了，SOFAJRaft 并不是 Raft 算法的第一个 Java 实现，在我们之前已经有了很多项目。但是经过我们的评估，觉得目前还是没有一个 Raft 的 Java 实现库类能够满足蚂蚁生产环境的要求，这也是我们去写 SOFAJRaft 的主要原因。\nSOFAJRaft 介绍 接下来我们介绍 SOFAJRaft。\nSOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。从去年 3 月开发到今年 2 月完成，并在今年 3 月开源。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统，目前使用案例有 RheaKV，这是 SOFAJRaft 中自带的一个分布式 KV 存储，还有今天开源的 SOFA 服务注册中心中的元信息管理模块也是用到了 SOFAJRaft，除此之外还有一些内部的项目也有使用，但是因为没有开源，所以就不再详述了。\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依然用之前的银 …","date":1554188400,"description":"本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享视频回顾获取方式见文章底部。","dir":"blog/sofa-meetup-1-jraft/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"614c6031770d98ed7d0c23c3276d72ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-jraft/","publishdate":"2019-04-02T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-jraft/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFAJRaft","SOFAMeetup"],"title":"详解蚂蚁金服 SOFAJRaft | 生产级高性能 Java 实现","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-jraft/","wordcount":5507},{"author":"张磊、心贵、临石、徙远、衷源、浔鸣","categories":"Kubernetes","content":" 本文由张磊、心贵、临石、徙远、衷源、浔鸣等同学联合撰写。\nKubernetes 1.14.0 Release 已经于 3 月 25 日正式发布。相信你也已经注意到，相比于1.13 和 1.12 版本，这次发布包含的重要变非常多，其对应的 Release Note 的篇幅长度也创下了“新高”。\n面对这样一份“海量信息”的 Release Note，我们该如何从这份文档里进行高效的信息过滤和挖掘，帮助团队更精准、快速的梳理出这次发布最主要的技术脉络呢？\n在本篇文章中，我们将 1.14 的 Release Note 按照主题进行了重新归纳和梳理，按照类别对重要变更进行了技术剖析和讨论。希望这种“分类解读”的方式，能够帮助大家更好的理解 1.14 这个发布的核心内容。\nWindows Node 正式生产可用 随着1.14的发布，Kubernetes 对windows节点的生产级支持无疑是一个重要的里程碑。具体来说，1.14 版本针对 Windows 做了大量增强；\n Pod：Pod内支持 readiness 和 liveness 探针；支持进程隔离和 volume 共享的多容器 Pod；Pod 支持原生configmap 和 sercret；Pod 支持emptyDir；支持对 Pod 进行资源配额等；但是像优雅删除、Termination message、Privileged Containers、HugePages、Pod 驱逐策略等部分特性还未在 1.14 版本提供； Service：支持服务环境变量提供 DNS 解析；支持 NodePort、ClusterIP、LoadBalancer、Headless service；暂不支持 Pod 的 hostnetwork 模式； 常规 Workload controller：RS、deployment、statefulset、daemonset、job、cronjob 均支持 windows 容器； 除此之外，支持 Pod 和 container 维度的metrics、HPA、“kubectl exec”、调度抢占、resource quotas、CNI 网络支持等多种特性让 windows workload 更加云原生；由于 windows 的特殊兼容性，目前 host OS 的版本必须和容器镜像 OS 版本一致，1.14 版本支持 win server 2019；未来版本中会考虑使用 Hyper-V 隔离机制来解决版本兼容性问题。 而伴随着 Windows 容器的生态正在慢慢壮大，能够在生产级别支持 Windows 节点的容器服务开始见诸各大云厂商。阿里云容器服务（ACK）近期已经推出了 Windows Container 的支持，提供了 linux/windows 应用混合部署的统一管理能力。\n参见：Support for Windows Nodes is Graduating to Stable (#116 )\n本地持久化数据卷（Local PV） 正式可用 长期以来，能够让 Kubernetes 直接用宿主机的本地存储设备（比如：本地 SSD 硬盘）来提供持久化数据卷（即：Local PV 功能），一直是社区里非常强烈的一个诉求。这个原因很容易理解：相对于远程存储（网络存储），Local PV 在时延性、易用性、稳定性和费用上具有独特的优势，尤其是对于相关特性比较敏感的应用，如数据库应用和搜索引擎应用来说，有着重要的意义。\n而在 1.14 中，Local PV 终于正式宣布 GA，为云上的持久化存储选择增加了一种重要的的可能。\n不过，必须要明确的是， 选择使用 Local PV，也意味着用户必须自己承担一些潜在的风险，这包括：\n 目前社区的开源方案无法动态创建卷 调度器需要由额外的调度逻辑工作，以确保调度的节点可以分配出足够的磁盘容量 容错性差，如果 Pod 正在运行的宿主机宕机或者磁盘发生异常，那么它的持久化卷里的信息可能丢失 第一个问题，可以通过比如阿里云的 local-volume-provisioner 实现本地 SSD Nvme 实例自动创建数据卷来解决，但对于容错性和健壮性的问题，就是比较棘手的了。\n参见：Durable Local Storage Management is Now GA (#121)\nPod 优先级与抢占机制稳定可用 Kubernetes 里的任务优先级（priority）和抢占机制（preemption）的目的十分明确：保证高优先级的任务可以在需要的时候通过抢占低优先级任务的方式得到运行。\n这其中，优先级定义了一个 Pod 在集群中的重要程度，这个重要程度体现且仅体现在两个地方： 1. 高优先级的Pod 在调度阶段更容易被优先调度（K8s 采用队列调度模型），注意这里并不保证高优先级 Pod 永远被优先调度，实际影响调度顺序的因素有很多； 2. 在集群整体负载较高时，如果出现高优先级 Pod 无法被调度的情况（集群中没有满足条件的 Node 供 Pod 运行），K8s 会启动抢占机制，通过抢占已经运行的低优先级的 Pod 的方式，让高优先级的 Pod 可以运行起来。抢占机制便是在这里引入的。\n抢占机制指当调度器发现某个Pod（如 Pod-A）无法在集群中找到合适的节点部署时（所有节点 Predicates 全部失败），会试图通过删除一些优先级低于 Pod-A 的 Pod 来“腾出空间”部署 Pod-A，这样 Pod-A 就可以被调度了。这样一个“看似简单”的需求在分布式环境中实施起来有很多细节，例如：如何决定删除哪个节点的哪些 Pod、如何保证为 Pod-A 腾出的空间不被其它 Pod 占用、如何保证 Pod-A 不被饿死（Starvation）、如何处理有亲和性需求的 Pod 调度约束、是否需要支持跨节点 Preemption 以支持某些特定的约束（例如某 Failure Domain 的反亲和约束）等等。\n参见：Pod Priority and Preemption in Kubernetes (#564) 你一定要知道什么是 Pod Ready++ 在 1.14 版本之前，Kubernetes 判断一个 Pod 是否 Ready，就是检查这个 Pod 的容器是否全部正常运行。但是这里有个问题，那就是容器或者说里面的主进程 Ready，并不一定意味着这个应用副本就一定是就绪的。为了确认 Pod 确实可以正常可用，我们希望给它增加一些外部指标（比如，该 Pod 需要的 Service，DNS，存储等服务全部就绪），来反应这个Pod是否“真正”Ready。\n这个特性，就是1.14 里一个叫做“Pod Readiness Gates”、也叫做 Pod Ready ++ 的特性。它为pod的“Ready 状态” 提供了一个非常强大的扩展点。需要注意的是，用户需要编写一个外部控制器（Controller）来为这个Pod Readiness Gates 字段对应的指标设置值。\n参见：Pod Ready++ (#580) Kubernetes 原生应用管理能力 1.14之后，Kubernetes 项目本身 …","date":1553756400,"description":"在本篇文章中，我们将 1.14 的 Release Note 按照主题进行了重新归纳和梳理，按照类别对重要变更进行了技术剖析和讨论。希望这种“分类解读”的方式，能够帮助大家更好的理解 1.14 这个发布的核心内容。","dir":"blog/k8s-1.14-release-note/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8dddcb73179e656ccebedbba2d4e9131","permalink":"https://sofastack.github.io/sofastack.tech/blog/k8s-1.14-release-note/","publishdate":"2019-03-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/k8s-1.14-release-note/","summary":"本文由张磊、心贵、临石、徙远、衷源、浔鸣等同学联合撰写。 Kubernetes 1.14.0 Release 已经于 3 月 25 日正式发布。相信你也已经注意到，相比于1.13 和 1.12 版本，这次发布包","tags":["Kubernetes"],"title":"Kubernetes 1.14 发布了，Release Note 该怎么读？","type":"blog","url":"/sofastack.tech/blog/k8s-1.14-release-note/","wordcount":4012},{"author":"Yu Shuqiang","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》最后一篇，本篇作者yushuqiang，来自小象生鲜。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:TracerLab/]，目前领取已经完成，感谢大家的参与。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n 前言 自 Google《Dapper，大规模分布式系统的跟踪系统》论文发表以来，开源 Tracer 系统如雨后春笋般相继面市，各显神通，但都是用于分布式系统调用跟踪的组件，通过统一的 traceId 将调用链路中的各种网络调用情况记录下来，以达到透视化网络调用的目的。本文介绍的 SOFATracer 是以日志的形式来记录的，这些日志可用于故障的快速定位，服务治理等。目前来看 SOFATracer 团队已经为我们搭建了一个完整的 Tracer 框架内核，包括数据模型、编码器、跨进程透传 traceId、采样、日志落盘与上报等核心机制，并提供了扩展 API 及基于开源组件实现的部分插件，为我们基于该框架打造自己的 Tracer 平台提供了极大便利。\n作为一个开源实现，SOFATracer 也尽可能提供大而全的插件实现，但由于多数公司都有自己配套的技术体系，完全依赖官方提供的插件可能无法满足自身的需要，因此如何基于 SOFATracer 自身 API 的组件埋点机制进行扩展，实现自己的插件是必须掌握的一项本领。\n本文将根据 SOFATracer 自身 AP I的扩展点及已提供的插件源码来分析下 SOFATracer 插件的埋点机制。\nSOFATracer 的插件埋点机制 对一个应用的跟踪要关注的无非就是 客户端-\u0026amp;gt;web 层-\u0026amp;gt;rpc 服务-\u0026amp;gt;dao 后端存储、cache 缓存、消息队列 mq 等这些基础组件。SOFATracer 插件的作用实际上也就是对不同组件进行埋点，以便基于这些组件采集应用的链路数据。\n不同组件有不同的应用场景和扩展点，因此对插件的实现也要因地制宜，SOFATracer 埋点方式一般是通过 Filter、Interceptor 机制实现的。\n组件扩展入口之 Filter or Interceptor SOFATracer 目前已实现的插件中，像 SpringMVC 插件是基于 Filter 进行埋点的，httpclient、resttemplate 等是基于 Interceptor 机制进行埋点的。在实现插件时，要根据不同插件的特性和扩展点来选择具体的埋点方式。正所谓条条大路通罗马，不管怎么实现埋点，都是依赖 SOFATracer 自身 API 的扩展机制来实现。\nAPI 扩展点之 AbstractTracer API SOFATracer 中所有的插件均需要实现自己的 Tracer 实例，如 SpringMVC 的 SpringMvcTracer 、HttpClient 的 HttpClientTracer 等。\n 基于 SOFATracer API 埋点方式插件扩展如下： AbstractTracer 是 SOFATracer 用于插件扩展使用的一个抽象类，根据插件类型不同，又可以分为 clientTracer 和 serverTracer，分别对应于 AbstractClientTracer 和 AbstractServerTracer；再通过 AbstractClientTracer 和 AbstractServerTracer 衍生出具体的组件 Tracer 实现，比如上图中提到的 HttpClientTracer 、RestTemplateTracer 、SpringMvcTracer 等插件 Tracer 实现。\nAbstractTracer 这里先来看下 AbstractTracer 这个抽象类中具体提供了哪些抽象方法，也就是对于 AbstractClientTracer 和 AbstractServerTracer 需要分别扩展哪些能力。\n从上图 AbstractTracer 类提供的抽象方法来看，不管是 client 还是 server，在具体的 Tracer 插件实现中，都必须提供以下实现：\n DigestReporterLogName ：当前组件摘要日志的日志名称 DigestReporterRollingKey : 当前组件摘要日志的滚动策略 SpanEncoder：对摘要日志进行编码的编码器实现 AbstractSofaTracerStatisticReporter : 统计日志 reporter 类的实现类 基于 SOFATracer 自身 API 埋点最大的优势在于可以通过上面的这些参数来实现不同组件日志之间的隔离，上述需要实现的这些点是实现一个组件埋点常规的扩展点，是不可缺少的。\n上面分析了 SOFATracer API 的埋点机制，并且对于一些需要扩展的核心点进行了说明。SOFATracer 自身提供的内核非常简单，其基于自身 API 的埋点扩展机制为外部用户定制组件埋点提供了极大的便利。下面以 Thrift 扩展，具体分析如何实现一个组件埋点。\n PS : Thrift 是外部用户基于 SOFATracer API 扩展实现的，目前仅用于其公司内部使用，SOFATracer 官方组件中暂不支持，请知悉；后续会沟通作者提供 PR ，在此先表示感谢。\n Thrift 插件埋点分析 这里我们以 Thrift RPC 插件实现为例，分析如何实现一个埋点插件。\n1、实例工程的分包结构\n从上图插件的工程的包结构可以看出，整个插件实现比较简单，代码量不多，但从类的定义来看，直观的体现了SOFATracer 插件埋点机制所介绍的套路。下面将进行详细的分析与介绍。\n2、实现 Tracer 实例\nRpcThriftTracer 继承了 AbstractTracer 类，是对 clientTracer、serverTracer 的扩展。\n AbstractTracer RpcThriftTracer PS：如何确定一个组件是 client 端还是 server 端呢？就是看当前组件是请求的发起方还是请求的接受方，如果是请求发起方则一般是 client 端，如果是请求接收方则是 server 端。那么对于 RPC 来说，即是请求的发起方也是请求的接受方，因此这里实现了 AbstractTracer 类。\n 3、扩展点类实现\n DigestReporterLogName RpcTracerLogEnum …","date":1553697000,"description":"本文为《剖析 | SOFATracer 框架》最后一篇，本篇作者 Yu Shuqiang，来自小象生鲜。","dir":"blog/sofa-tracer-event-tracing-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"35dc2221b95ec62fd2aa03fca6367554","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","publishdate":"2019-03-27T14:30:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 埋点机制剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","wordcount":4338},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack\nScalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n SOFAStack 开源一周年，继续补充开源大图 2018 年 4 月， 蚂蚁金服宣布开源 SOFAStack 金融级分布式架构。这一年的时间，感谢社区的信任和支持，目前已经累积超过一万的 Star 数目，超过 30 家企业用户。 2019 年 3 月 24 日，SOFA 在北京举办了首场 Meetup，我们有幸见到了关心SOFA 的朋友们。 此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。 SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概念 注册中心在微服务架构中位置 服务发现，并非新鲜名词，在早期的 SOA 框架和现在主流的微服务框架中，每个服务实例都需要对外提供服务，同时也需要依赖外部服务。如何找到依赖的服务（即服务定位），最初我们思考了很多方式，比如直接在 Consumer 上配置所依赖的具体的服务地址列表，或者使用 LVS、F5 以及 DNS（域名指向所有后端服务的 IP）等负载均衡。\n但是以上方式都有明显的缺点，比如无法动态感知服务提供方节点变更的情况，另外基于负载均衡的话还需要考虑它的瓶颈问题。所以需要借助第三方的组件，即服务注册中心来提供服务注册和订阅服务，在服务提供方服务信息发生变化、或者节点上下线时，可以动态更新消费方的服务地址列表信息，最终解耦服务调用方和服务提供方。\n能力 服务注册中心的主要能力：\n 服务注册 服务订阅 演进 蚂蚁金服的服务注册中心，经历了 5 代技术架构演进，才最终形成了如今足以支撑蚂蚁海量服务注册订阅的，具有高可用、高扩展性和高时效性的架构。\n数据结构 SOFARegistry 的存储模型比较简单，主要基于 KV 存储两类数据，一类是订阅关系，体现为多个订阅方关心的 Topic（或服务键值）和他们的监听器列表，另一类是同一个 Topic（或服务键值）的发布者列表。基于观察者模式，在服务提供方发生变化时（比如服务提供方的节点上下线），会从订阅关系中寻找相应的订阅者，最终推送最新的服务列表给订阅者。\n存储扩展 主备模式 既然服务注册中心最主要能力之一是存储，那么就要思考：怎么存？存哪儿？存了会不会丢？ 怎么存，主要是由存什么数据来决定的，由于 SOFARegistry 所存储的数据结构比较简单( KV），因为并没有基于关系数据库；另外由于服务发现对变更推送的时效性要求高，但并没有很高的持久化要求(数据可以从服务提供方恢复)，所以最终我们决定自己实现存储能力。 SOFARegistry 的存储节点，最初是主备模式。 强一致集群 随着蚂蚁的服务数据量不断增长，我们将存储改为集群方式，每个存储节点的数据是一样的，每一次写入都保证所有节点写入成功后才算成功。这种模式的特点是每台服务器都存储了全量的服务数据，在当时数据规模比较小的情况下，尚可接受。\n这样的部署结构有两个问题：\n 首先，根据 CAP 原理，在分区容忍性（P）的前提下，为了保持强一致（C），必然牺牲高可用（A）为代价，比如 Zookeeper 是 CP 系统，它在内部选举期间是无法对外提供服务的，另外由于需要保证 C（顺序一致性），写的效率会有所牺牲。 其次，每个节点都存储全量的服务数据，随着业务的发展就有很大的瓶颈问题。 数据分片 如果要实现容量可无限扩展，需要把所有数据按照一定维度进行拆分，并存储到不同节点，当然还需要尽可能地保证数据存储的均匀分布。我们很自然地想到可以进行 Hash 取余，但简单的取余算法在节点数增减时会影响全局数据的分布，所以最终采用了一致性 Hash 算法（这个算法在业界很多场景已经被大量使用，具体不再进行介绍）。\n每个服务数据，经过一致性 Hash 算法计算后会存储到某个具体的 Data 上，整体形成环形的结构。理论上基于一致性 Hash 对数据进行分片，集群可以根据数据量进行无限地扩展。\n内部分层 连接承载 我们知道单机的 TCP 连接数是有限制的，业务应用不断的增多，为了避免单机连接数过多，我们需要将存储节点与业务应用数量成正比地扩容，而我们实际上希望存储节点的数量只跟数据量成正比。所以我们选择从存储节点上把承载连接职责的能力独立抽离出来成为新的一个角色，称之为 Session 节点，Session 节点负责承载来自业务应用的连接。这么一来，SOFARegistry 就由单个存储角色被分为了 Session 和 Data 两个角色，Session 承载连接，Data 承载数据，并且理论上 Session 和 Data 都支持无限扩展。\n如图，客户端直接和 Session 层建立连接，每个客户端只选择连接其中一个 Session 节点，所有原本直接到达 Data层的连接被收敛到 Session 层。Session 层只进行数据透传，不存储数据。客户端随机连接一台 Session 节点，当遇到 Session 不可用时重新选择新的 Session 节点进行重连即可。\n读写分离 分离出 Session 这一层负责承载连接，引起一个新的问题：数据到最终存储节点 Data 的路径变长了，整个集群结构也变的复杂了，怎么办呢？\n我们知道，服务注册中心的一个主要职责是将服务数据推送到客户端，推送需要依赖订阅关系，而这个订阅关系目前是存储到 Data 节点上。在 Data 上存储订阅关系，但是 Client 并没有直接和 Data 连接，那必须要在 Session 上保存映射后才确定推送目标，这样的映射关系占据了大量存储，并且还会随 Session 节点变化进行大量变更，会引起很多不一致问题。\n因此，我们后来决定，把订阅关系信息（Sub）直接存储在 Session 上，并且通过这个关系 Session 直接承担把数据变化推送给客户端的职责。而对于服务的发布信息（Pub）还是通过 Session 直接透传最终在 Data 存储节点上进行汇聚，即同一个服务 ID 的数据来自于不同的客户端和不同的 Session 最终在 Data 的一个节点存储。\n这样划分了 Sub 和 Pub 数据之后，通过订阅关系（Sub）进行推送的过程就有点类似于对服务数据读取的过程，服务发布进行存储的过程有点类似数据写的过程。数据读取的过程，如果有订阅关系就可以确定推送目标，迁移订阅关系数据到 Session，不会影响整个集群服务数据的状态，并且 Client 节点连接新的 Session 时，也会回放所有订阅关系，Session 就可以无状态的 …","date":1553697000,"description":"此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。","dir":"blog/sofa-registry-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"86b3010d0f85f6711d60de29a244ed7e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-deep-dive/","publishdate":"2019-03-27T14:30:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFARegistry","SOFAMeetup"],"title":"蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-registry-deep-dive/","wordcount":4313},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n SOFAStack 开源一周年，继续补充开源大图 2018 年 4 月， 蚂蚁金服宣布开源 SOFAStack 金融级分布式架构。这一年的时间，感谢社区的信任和支持，目前已经累积超过一万的 Star 数目，超过 30 家企业用户。\n2019 年 3 月 24 日，SOFA 在北京举办了首场 Meetup，我们有幸见到了关心 SOFA 的朋友们。\n此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。\nSOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nGitHub 地址：https://github.com/alipay/sofa-registry 概念 注册中心在微服务架构中位置 服务发现，并非新鲜名词，在早期的 SOA 框架和现在主流的微服务框架中，每个服务实例都需要对外提供服务，同时也需要依赖外部服务。如何找到依赖的服务（即服务定位），最初我们思考了很多方式，比如直接在 Consumer 上配置所依赖的具体的服务地址列表，或者使用 LVS、F5 以及 DNS（域名指向所有后端服务的 IP）等负载均衡。\n但是以上方式都有明显的缺点，比如无法动态感知服务提供方节点变更的情况，另外基于负载均衡的话还需要考虑它的瓶颈问题。所以需要借助第三方的组件，即服务注册中心来提供服务注册和订阅服务，在服务提供方服务信息发生变化、或者节点上下线时，可以动态更新消费方的服务地址列表信息，最终解耦服务调用方和服务提供方。\n能力 服务注册中心的主要能力：\n 服务注册 服务订阅 演进 蚂蚁金服的服务注册中心，经历了 5 代技术架构演进，才最终形成了如今足以支撑蚂蚁海量服务注册订阅的，具有高可用、高扩展性和高时效性的架构。\n数据结构 SOFARegistry 的存储模型比较简单，主要基于 KV 存储两类数据，一类是订阅关系，体现为多个订阅方关心的 Topic（或服务键值）和他们的监听器列表，另一类是同一个 Topic（或服务键值）的发布者列表。基于观察者模式，在服务提供方发生变化时（比如服务提供方的节点上下线），会从订阅关系中寻找相应的订阅者，最终推送最新的服务列表给订阅者。\n存储扩展 主备模式 既然服务注册中心最主要能力之一是存储，那么就要思考：怎么存？存哪儿？存了会不会丢？ 怎么存，主要是由存什么数据来决定的，由于 SOFARegistry 所存储的数据结构比较简单( KV），因为并没有基于关系数据库；另外由于服务发现对变更推送的时效性要求高，但并没有很高的持久化要求(数据可以从服务提供方恢复)，所以最终我们决定自己实现存储能力。 SOFARegistry 的存储节点，最初是主备模式。 强一致集群 随着蚂蚁金服的服务数据量不断增长，我们将存储改为集群方式，每个存储节点的数据是一样的，每一次写入都保证所有节点写入成功后才算成功。这种模式的特点是每台服务器都存储了全量的服务数据，在当时数据规模比较小的情况下，尚可接受。\n这样的部署结构有两个问题：\n 首先，根据 CAP 原理，在分区容忍性（P）的前提下，为了保持强一致（C），必然牺牲高可用（A）为代价，比如 Zookeeper 是 CP 系统，它在内部选举期间是无法对外提供服务的，另外由于需要保证 C（顺序一致性），写的效率会有所牺牲。 其次，每个节点都存储全量的服务数据，随着业务的发展就有很大的瓶颈问题。 数据分片 如果要实现容量可无限扩展，需要把所有数据按照一定维度进行拆分，并存储到不同节点，当然还需要尽可能地保证数据存储的均匀分布。我们很自然地想到可以进行 Hash 取余，但简单的取余算法在节点数增减时会影响全局数据的分布，所以最终采用了一致性 Hash 算法（这个算法在业界很多场景已经被大量使用，具体不再进行介绍）。\n每个服务数据，经过一致性 Hash 算法计算后会存储到某个具体的 Data 上，整体形成环形的结构。理论上基于一致性 Hash 对数据进行分片，集群可以根据数据量进行无限地扩展。\n内部分层 连接承载 我们知道单机的 TCP 连接数是有限制的，业务应用不断的增多，为了避免单机连接数过多，我们需要将存储节点与业务应用数量成正比地扩容，而我们实际上希望存储节点的数量只跟数据量成正比。所以我们选择从存储节点上把承载连接职责的能力独立抽离出来成为新的一个角色，称之为 Session 节点，Session 节点负责承载来自业务应用的连接。这么一来，SOFARegistry 就由单个存储角色被分为了 Session 和 Data 两个角色，Session 承载连接，Data 承载数据，并且理论上 Session 和 Data 都支持无限扩展。\n如图，客户端直接和 Session 层建立连接，每个客户端只选择连接其中一个 Session 节点，所有原本直接到达 Data层的连接被收敛到 Session 层。Session 层只进行数据透传，不存储数据。客户端随机连接一台 Session 节点，当遇到 Session 不可用时重新选择新的 Session 节点进行重连即可。\n读写分离 分离出 Session 这一层负责承载连接，引起一个新的问题：数据到最终存储节点 Data 的路径变长了，整个集群结构也变的复杂了，怎么办呢？\n我们知道，服务注册中心的一个主要职责是将服务数据推送到客户端，推送需要依赖订阅关系，而这个订阅关系目前是存储到 Data 节点上。在 Data 上存储订阅关系，但是 Client 并没有直接和 Data 连接，那必须要在 Session 上保存映射后才确定推送目标，这样的映射关系占据了大量存储，并且还会随 Session 节点变化进行大量变更，会引起很多不一致问题。\n因此，我们后来决定，把订阅关系信息（Sub）直接存储在 Session 上，并且通过这个关系 Session 直接承担把数据变化推送给客户端的职责。而对于服务的发布信息（Pub）还是通过 Session 直接透传最终在 Data 存储节点上进行汇聚，即同一个服务 ID 的数据来自于不同的客户端和不同的 Session 最终在 Data 的一个节点存储。\n这样划分了 Sub 和 Pub 数据之后，通过订阅关系（Sub）进行推送的过程就有点类似于对服务数据读取的过程，服务发布进行存储的过程有点类似数据写的过程。数据读取的过程，如果有订阅关系就可以确定推送目标，迁移订阅关系数据到 Session，不会影响整个集群服务数据的状态，并且 Client 节点连接新的 Session 时，也会回放所有订阅关系，Session 就可以无状态的 …","date":1553670000,"description":"本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/sofa-meetup-1-registry/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0e3d1f0cf167e7afea39c2435ceefcfd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-registry/","publishdate":"2019-03-27T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-registry/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFARegistry","SOFAMeetup"],"title":"蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-registry/","wordcount":4318},{"author":"蚂蚁金服团队","categories":"seata","content":" Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。\nSample 地址：https://github.com/fescar-group/fescar-samples/tree/master/tcc\n文末也提供了项目后续的 Roadmap，欢迎关注。\n一、TCC 简介 在两阶段提交协议（2PC，Two Phase Commitment Protocol）中，资源管理器（RM, resource manager）需要提供“准备”、“提交”和“回滚” 3 个操作；而事务管理器（TM, transaction manager）分 2 阶段协调所有资源管理器，在第一阶段询问所有资源管理器“准备”是否成功，如果所有资源均“准备”成功则在第二阶段执行所有资源的“提交”操作，否则在第二阶段执行所有资源的“回滚”操作，保证所有资源的最终状态是一致的，要么全部提交要么全部回滚。\n资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现；TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题；TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中；事务管理器分 2 阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法；最终所有 TCC 服务要么全部都是提交的，要么全部都是回滚的。\n二、TCC 设计 用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上，进过蚂蚁金服多年的 TCC 应用，总结如下主要的TCC 设计和实现主要事项：\n1、业务操作分两阶段完成 接入 TCC 前，业务操作只需要一步就能完成，但是在接入 TCC 之后，需要考虑如何将其分成 2 阶段完成，把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户A的余额中有 100 元，需要扣除其中 30 元”；\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成 2 步完成：\n Try 操作：资源的检查和预留； 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交； 在扣款场景下，Confirm 阶段走的事情就是发生真正的扣款，把A账户中已经冻结的 30 元钱扣掉。\n Cancel 操作：预留资源的是否； 在扣款场景下，扣款取消，Cancel 操作执行的任务是释放 Try 操作冻结的 30 元钱，是 A 账户回到初始状态。\n2、并发控制 用户在实现 TCC 时，应当考虑并发性问题，将锁的粒度降到最低，以最大限度的提高分布式事务的并发性。\n以下还是以A账户扣款为例，“账户 A 上有 100 元，事务 T1 要扣除其中的 30 元，事务 T2 也要扣除 30 元，出现并发”。\n在一阶段 Try 操作中，分布式事务 T1 和分布式事务 T2 分别冻结资金的那一部分资金，相互之间无干扰；这样在分布式事务的二阶段，无论 T1 是提交还是回滚，都不会对 T2 产生影响，这样 T1 和 T2 在同一笔业务数据上并行执行。\n3、允许空回滚 如下图所示，事务协调器在调用 TCC 服务的一阶段 Try 操作时，可能会出现因为丢包而导致的网络超时，此时事务管理器会触发二阶段回滚，调用 TCC 服务的 Cancel 操作，而 Cancel 操作调用未出现超时。\nTCC 服务在未收到 Try 请求的情况下收到 Cancel 请求，这种场景被称为空回滚；空回滚在生产环境经常出现，用户在实现TCC服务时，应允许允许空回滚的执行，即收到空回滚时返回成功。\n4、防悬挂控制 如下图所示，事务协调器在调用 TCC 服务的一阶段 Try 操作时，可能会出现因网络拥堵而导致的超时，此时事务管理器会触发二阶段回滚，调用 TCC 服务的 Cancel 操作，Cancel 调用未超时；在此之后，拥堵在网络上的一阶段 Try 数据包被 TCC 服务收到，出现了二阶段 Cancel 请求比一阶段 Try 请求先执行的情况，此 TCC 服务在执行晚到的 Try 之后，将永远不会再收到二阶段的 Confirm 或者 Cancel ，造成 TCC 服务悬挂。\n用户在实现 TCC 服务时，要允许空回滚，但是要拒绝执行空回滚之后 Try 请求，要避免出现悬挂。\n5、幂等控制 无论是网络数据包重传，还是异常事务的补偿执行，都会导致 TCC 服务的 Try、Confirm 或者 Cancel 操作被重复执行；用户在实现 TCC 服务时，需要考虑幂等控制，即 Try、Confirm、Cancel 执行一次和执行多次的业务结果是一样的。\nRoadmap 当前已经发布到 0.4.0 版本，后续我们会发布 0.5 ~ 1.0 版本，继续对 AT、TCC 模式进行功能完善和和丰富，并解决服务端高可用问题，在 1.0 版本之后，本开源产品将达到生产环境使用的标准。\n","date":1553583600,"description":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。","dir":"blog/seata-tcc-theory-design-realization/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"45ef8a72beefcd26f4f62e7bdb34671c","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-tcc-theory-design-realization/","publishdate":"2019-03-26T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/seata-tcc-theory-design-realization/","summary":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。 Sample 地址：https://github.com/fescar-group/fescar","tags":["seata"],"title":"TCC 理论及设计实现指南介绍","type":"blog","url":"/sofastack.tech/blog/seata-tcc-theory-design-realization/","wordcount":1971},{"author":"蚂蚁金服团队","categories":"seata","content":" Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用，文末也提供了项目后续的 Roadmap，欢迎关注。\n前言：基于 TCC 模型的应用场景 TCC 分布式事务模型直接作用于服务层。不与具体的服务框架耦合，与底层 RPC 协议无关，与底层存储介质无关，可以灵活选择业务资源的锁定粒度，减少资源锁持有时间，可扩展性好，可以说是为独立部署的 SOA 服务而设计的。\n一、TCC 模型优势 对于 TCC 分布式事务模型，笔者认为其在业务场景应用上，有两方面的意义。\n1.1 跨服务的分布式事务 服务的拆分，也可以认为是资源的横向扩展，只不过方向不同而已。\n横向扩展可能沿着两个方向发展：\n 功能扩展，根据功能对数据进行分组，并将不同的功能组分布在多个不同的数据库上，这实际上就是 SOA 架构下的服务化。 数据分片，在功能组内部将数据拆分到多个数据库上，为横向扩展增加一个新的维度。 下图简要阐释了横向数据扩展策略：\n横向扩展的两种方法可以同时进行运用：用户信息（Users）、产品信息（Products）与交易信息（Trans）三个不同功能组可以存储在不同的数据库中。另外，每个功能组内根据其业务量可以再拆分到多个数据库中，各功能组可以相互独立地进行扩展。\n因此，TCC 的其中一个作用就是在按照功能横向扩展资源时，保证多资源访问的事务属性。\n1.2 两阶段拆分 TCC 另一个作用就是把两阶段拆分成了两个独立的阶段，通过资源业务锁定的方式进行关联。资源业务锁定方式的好处在于，既不会阻塞其他事务在第一阶段对于相同资源的继续使用，也不会影响本事务第二阶段的正确执行。\n传统模型的并发事务：\nTCC 模型的并发事务：\n可以发现 TCC 模型进一步减少了资源锁的持有时间。同时，从理论上来说，只要业务允许，事务的第二阶段什么时候执行都可以，反正资源已经业务锁定，不会有其他事务动用该事务锁定的资源。\n这对业务有什么好处呢？拿支付宝的担保交易场景来说，简化情况下，只需要涉及两个服务，交易服务和账务服务。交易作为主业务服务，账务作为从业务服务，提供 Try、Commit、Cancel 接口：\n Try 接口扣除用户可用资金，转移到预冻结资金。预冻结资金就是业务锁定方案，每个事务第二阶段只能使用本事务的预冻结资金，在第一阶段执行结束后，其他并发事务也可以继续处理用户的可用资金。 Commit 接口扣除预冻结资金，增加中间账户可用资金（担保交易不能立即把钱打给商户，需要有一个中间账户来暂存）。 假设只有一个中间账户的情况下，每次调用支付服务的 Commit 接口，都会锁定中间账户，中间账户存在热点性能问题。 但是，在担保交易场景中，七天以后才需要将资金从中间账户划拨给商户，中间账户并不需要对外展示。因此，在执行完支付服务的第一阶段后，就可以认为本次交易的支付环节已经完成，并向用户和商户返回支付成功的结果，并不需要马上执行支付服务二阶段的 Commit 接口，等到低锋期时，再慢慢消化，异步地执行。\n可能部分读者认为担保交易比较特殊，其实直付交易（直接把钱打到商户账户的交易模式，Commit 接口扣除预冻结资金以后，不是转移到中间账务，而是直接转移到商户账户）也可以这样使用，只要提前告知商户，高峰期交易资金不是实时到账，但保证在一定时间之内结算完成，商户应该也是可以理解的。\n这就是 TCC 分布式事务模型的二阶段异步化功能，从业务服务的第一阶段执行成功，主业务服务就可以提交完成，然后再由框架异步的执行各从业务服务的第二阶段。\n二、通用型 TCC 解决方案 通用型 TCC 解决方案就是最典型的 TCC 分布式事务模型实现，所有从业务服务都需要参与到主业务服务的决策当中。\n适用场景 由于从业务服务是同步调用，其结果会影响到主业务服务的决策，因此通用型 TCC 分布式事务解决方案适用于执行时间确定且较短的业务，比如互联网金融企业最核心的三个服务：交易、支付、账务：\n当用户发起一笔交易时，首先访问交易服务，创建交易订单；然后交易服务调用支付服务为该交易创建支付订单，执行收款动作，最后支付服务调用账务服务记录账户流水和记账。\n为了保证三个服务一起完成一笔交易，要么同时成功，要么同时失败，可以使用通用型 TCC 解决方案，将这三个服务放在一个分布式事务中，交易作为主业务服务，支付作为从业务服务，账务作为支付服务的嵌套从业务服务，由 TCC 模型保证事务的原子性。\n支付服务的 Try 接口创建支付订单，开启嵌套分布式事务，并调用账务服务的 Try 接口；账务服务在 Try 接口中冻结买家资金。一阶段调用完成后，交易完成，提交本地事务，由 TCC 框架完成分布式事务各从业务服务二阶段的调用。\n支付服务二阶段先调用账务服务的 Confirm 接口，扣除买家冻结资金；增加卖家可用资金。调用成功后，支付服务修改支付订单为完成状态，完成支付。\n当支付和账务服务二阶段都调用完成后，整个分布式事务结束。\n三、异步确保型 TCC 解决方案 异步确保型 TCC 解决方案的直接从业务服务是可靠消息服务，而真正的从业务服务则通过消息服务解耦，作为消息服务的消费端，异步地执行。\n可靠消息服务需要提供 Try，Confirm，Cancel 三个接口。Try 接口预发送，只负责持久化存储消息数据；Confirm 接口确认发送，这时才开始真正的投递消息；Cancel 接口取消发送，删除消息数据。\n消息服务的消息数据独立存储，独立伸缩，降低从业务服务与消息系统间的耦合，在消息服务可靠的前提下，实现分布式事务的最终一致性。\n此解决方案虽然增加了消息服务的维护成本，但由于消息服务代替从业务服务实现了 TCC 接口，从业务服务不需要任何改造，接入成本非常低。\n适用场景 由于从业务服务消费消息是一个异步的过程，执行时间不确定，可能会导致不一致时间窗口增加。因此，异步确保性 TCC 分布式事务解决方案只适用于对最终一致性时间敏感度较低的一些被动型业务（从业务服务的处理结果不影响主业务服务的决策，只被动的接收主业务服务的决策结果）。比如会员注册服务和邮件发送服务：\n当用户注册会员成功，需要给用户发送一封邮件，告诉用户注册成功，并提示用户激活该会员。但要注意两点：\n 如果用户注册成功，一定要给用户发送一封邮件； 如果用户注册失败，一定不能给用户发送邮件。 因此，这同样需要会员服务和邮件服务保证原子性，要么都执行，要么都不执行。不一样的是，邮件服务只是一种被动型的业务，并不影响用户是否能够注册成功，它只需要在用户注册成功以后发送邮件给用户即可，邮件服务不需要参与到会员服务的活动决策中。\n对于此种业务场景，可以使用异步确保型TCC分布式事务解决方案，如下：\n由可靠消息服务来解耦会员和邮件服务，会员服务与消息服务组成 TCC 事务模型，保证事务原子性。然后通过消息服务的可靠特性，确保消息一定能够被邮件服务消费，从而使得会员与邮件服务在同一个分布式事务中。同时，邮件服务也不会影响会员服务的执行过程，只在会员服务执行成功后被动接收发送邮件的请求。\n四、补偿型 TCC 解决方案 补偿型 TCC 解决方案与通用型 TCC 解决方案的结构相似，其从业务服务也需要参与到主 …","date":1553410800,"description":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。","dir":"blog/seata-tcc-applicable-models-scenarios/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa8436ce2760fafb880427799a763f32","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","publishdate":"2019-03-24T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","summary":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用，文末也提供了项目后续的 Roadmap，欢迎关注。 前言：基于 TCC 模型的应用场景 TCC 分布式事","tags":["seata"],"title":"TCC 适用模型与适用场景分析","type":"blog","url":"/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","wordcount":3912},{"author":"善逝","categories":"SOFAArk","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服在 SOFAStack 体系内研发了一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力\u0026amp;ndash;SOFAArk。本篇文章为 SOFAArk 0.6.0 的新特性介绍。 GitHub 地址：https://github.com/alipay/sofa-ark\n 简介 在大型软件开发过程中，通常会推荐底层功能插件化、业务功能模块化的开发模式，以其达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化开发方案，产品能力主要包括：\n 定义插件开发规范，提供 Maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin）， 适用于将底层组件插件化输出，例如 RPC、富客户端等； 定义模块开发规范，提供 Maven 打包工具，简单快速将应用（Spring Boot/SOFABoot/普通 Java 应用）打包成模块 (Ark Biz，以下简称 Biz)，适用于将业务组件模块化输出，提升业务能力复用； 定义类加载模型，运行时 Plugin、Biz 之间均相互隔离，运行时由不同的 ClassLoader 加载，有效避免相互之间的包冲突，降低 Plugin 和 Biz 对运行环境的要求； 定义标准的编程界面，包括服务、事件、扩展点等机制，方便 Plugin、Biz 交互和扩展； 定义业务模块 (Biz) 生命周期，支持多 Biz 合并部署。开发阶段将多个 Biz 打包成 Executable Ark Jar 包(以下简称 Ark 包)，或者运行时使用 API 或配置中心(Zookeeper)动态地管理 Biz 安装和卸载，满足多应用合并部署及动态升级的需求。 基于以上能力，SOFAArk 可以帮助解决多应用(模块)合并部署、动态升级、依赖包冲突等场景问题。\n场景 场景一：合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件。协调跨团队合作开发会遇到不少问题：比如各自技术栈不统一导致的依赖冲突、往同一个 Git 仓库提交代码常常导致 merge 冲突、组件功能相互依赖影响测试进度。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发和测试，运行时合并部署，那么将有助于提升开发效率及应用可扩展性。\nSOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互，如下：\nBiz 对应用类型没有限制，可以是 Spring Boot/SOFABoot/Java 普通应用类型，Biz 之间采用统一的编程界面-SOFA JVM服务进行交互。发布和引用服务也非常简单，使用 API 或者 Spring 注解/XML 方式：\n合并部署的形式，分为两种 \u0026amp;ndash; 静态合并部署和动态合并部署。\n静态合并部署 在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成 Ark 包时，会将引入的其他 Biz 包一并打入。通过 java -jar 启动 Ark 包时，则会根据优先级依次启动各 Biz，单个 Biz 使用独立的 BizClassLoader 加载，不需要考虑依赖包冲突问题，Biz 之间则通过 SOFA JVM 服务交互。\n动态合并部署 动态合并部署区别于静态合并部署最大的一点是，在运行时可以通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态合并部署的设计理念图如下：\n无论是静态抑或动态合并部署都有存在宿主应用 (master biz) 的概念，如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主 Biz 和其他 Biz 唯一不同在于，宿主 Biz 不允许被卸载。\n一般而言，宿主应用会作为流量入口的中台系统，具体的服务实现会放在不同的动态 Biz 中，供宿主应用调用。宿主应用可以使用 SOFAArk 提供的客户端 API 实现动态应用的部署和卸载。除了 API， SOFAArk 提供了 Config Plugin，用于对接配置中心（目前支持 Zookeeper），运行时接受动态配置；Config Plugin 会解析下发的配置，控制动态应用的部署和卸载。\n场景二：动态升级 SOFAArk 在蚂蚁内部也被用来解决动态升级的场景问题。有时候，因为业务迭代较快，应用依赖的某二方包需要频繁的变更，这将导致应用每次都因为升级二方包版本做变更发布，影响开发效率；而作为二方包的开发者，常常因为推动依赖方应用升级阻力较大，导致新特性无法按时上线，影响业务发展。\n为了加快创新业务的迭代速度，会将需要频繁变更的二方包打包成 Biz 包，供其他应用依赖。作为依赖方，不会直接在 Pom 文件（假设是使用 Maven 构建）定义 Biz 包版本，而是通过配置中心（例如 Zookeeper）下发配置。如此，当应用启动时，会拉取 Biz 版本配置信息，进而拉取正确版本的 Biz 包并启动。如此，当需要依赖方升级 Biz 版本时，只需要在配置中心重新推送配置即可。\n场景三：依赖隔离 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError, NoSuchMethodError 等。实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法：统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突。这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题。如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题。 OSGi 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGi 框架门槛较高，功能繁杂。为了解决包冲突问题，引入 OSGi 框架，有牛刀杀鸡之嫌，反而使工程变得更加复杂，不利于开发。\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如 …","date":1553065200,"description":"本篇文章为 SOFAArk 0.6.0 的新特性介绍。","dir":"blog/sofa-ark-0.6.0/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7a25cfa30d66586c83abafd947447de3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-0.6.0/","publishdate":"2019-03-20T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-ark-0.6.0/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 蚂蚁金服在 SOFAStack 体","tags":["SOFAArk"],"title":"蚂蚁金服 SOFAArk 0.6.0 新特性介绍 | 模块化开发容器","type":"blog","url":"/sofastack.tech/blog/sofa-ark-0.6.0/","wordcount":3490},{"author":"炎竹","categories":"SOFAActs","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服在 SOFAStack 体系内研发了基于模型驱动的自动化接口测试框架 SOFAACTS。 GitHub 地址：https://github.com/alipay/sofa-acts\n 背景 伴随着业务需求的爆发，蚂蚁金服金融级分布式架构质量测试活动变得复杂起来，表现在测试的业务场景复杂，诸如分布式事务处理流程场景、并发性、账户状态多样性、幂等性和兼容性等等。在原有的自动化测试框架下，测试流程编排极易出现测试数据冗余分散、可维护性差、人工编码成本高和测试验证点易遗漏的问题。\n如何解决上面的问题呢？\n蚂蚁金服在 SOFAStack 体系内研发了基于模型驱动的自动化接口测试框架 SOFAACTS。\nSOFAACTS 介绍 SOFAACTS 由 IDE 和测试引擎组成，下图为产品架构图：\n框架适配 TestNg+Spring 的测试上下文环境，以 YAML 为数据载体并在此上构建数据模型驱动，具有契合快速互联网发展和复杂分布式金融系统特点的优良特性：\n 模型驱动和标准执行引擎； 精细化校验和数据的自动回写； 具有灵活的可扩展性； 用例可视化维护。 1.模型驱动和标准化 在测试用例数据与测试代码分离的探索上，很多测试框架采用数据驱动的方式，但这也无法从容应对金融级的复杂业务场景。框架对用例数据进行了深度抽象，提出模型驱动理念，研发出基于模型的数据驱动和标准化执行引擎，实现了数据和代码的分离管理，同时对测试过程中的数据清理、数据准备、用例执行、结果校验阶段进行标准化，做到测试数据维护和测试代码的简洁优雅。用例执行时用户无需关注数据如何加载，结果和期望数据如何比对，只需要关注测试数据和执行结果。\n接下来，我们介绍如何使用 SOFAACTS 来高效率地完成一键生成数据模型生成和一键生成测试脚本。\n数据模型生成 首先进行数据模型的准备，以方便之后模版化地快速创建对象和表，按照如下方式来准备 DB 数据、接口请求参数和返回结果对象模型。\nDB 数据模型生成 任意测试代码中右击-\u0026amp;gt; SOFAACTS 功能-\u0026amp;gt;生成 DB 表结构模板； 选择生成的目标测试工程； 点击确认后选择并添加需要生成模型的表即可生成。 类对象模型生成 待构建模型的类定义的任意方法上右击-\u0026amp;gt; SOFAACTS 功能-\u0026amp;gt;模板生成，生成当前对象的模型； 生成完成后，我们可以在下图位置找到生成的数据对象模型； 按照上述步骤，这样我们就生成了接口对象模板。 现在，我们开始进行脚本一键生成：\n测试脚本生成 SOFAACTS IDE 提供测试脚本自动生成功能，无需手动编码。操作方式如下：\n 被测接口方法上点击，选择 SOFAACTS 功能\u0026amp;ndash;\u0026amp;gt;生成测试用例； 这时会弹出一个文本框，填写脚本生成的位置和编码格式，如下： 填写完成后，点击 OK 即可自动生成如下测试脚本，可以看出模型驱动生成的脚本精简而优雅。 原来数据驱动下的脚本是如下面图这样的，测试数据冗余分散，人工编码成本高维护性差。\n实践证明 SOFAACTS 用例的测试代码构建效率提高 80% ，测试数据精简到 1/case 数。\n2.精细化校验 在解决复杂业务场景下测试验证难、易遗漏等问题时，SOFAACTS 基于代码行为跟踪和分析理念，通过反射机制和日志解析实现结果数据的自动采集，以此做为场景用例校验的数据基线，并在持续集成时进行基线全量因子匹配来达到精细化验证。如下图：\n同时，为了提高自动采集后数据回填的效率，框架支持预校验数据的自动写入能力，进一步实现了数据的自动化精细校验。如下图：一键点击即可采集到校验数据基线，在蚂蚁内部实践中 ACTS 做到了结果校验效率提升至少 80%，场景验证 0 遗漏。\n3.灵活可扩展 框架为了应对各种特殊业务测试情况而不需要过多改动，设计上应用高内聚与低耦合原则，支持既可以复用框架底层代码又可以针对业务个性化情况做扩展的能力。整个框架提供了丰富的 API，测试执行过程每个方法、每个类以便测试执行过程的每个阶段（如下图）都能够在测试脚本里面被重新为其他方法或者被其他多态的子类替换，这样让框架变得更通用，既赋予了框架轻量性又增加了灵活性。\n自定义的 API 如下：\nAPI 的具体使用请详细学习产品使用手册。\n4.用例可视化维护 框架支持研发集成环境的一站式编辑，高效的用例脚本和数据维护，有效减少重复性的数据准备代码。如下图：\n总结 以上便是对 SOFAACTS 测试框架的基本介绍，还有诸多能力各位可以查阅我们详细的使用手册。\n目前，SOFAACTS 已经在蚂蚁金服大范围使用，分钟级用例编写 10 倍效能提升，累计用例个数 10w 以上，高频功能使用可达近 2000 次/日，并持续保持着旺盛的生命力。\n当前，代码已开源托管在 GitHub 上，欢迎关注，同时也欢迎业界爱好者共同创造更好的 SOFAACTS。\nGitHub 项目地址：https://github.com/alipay/sofa-acts\n相关链接 SOFAACTS ：https://github.com/alipay/sofa-acts API 产品使用手册：https://www.sofastack.tech/sofa-acts/docs/Usage-API SOFAACTS 详细使用手册：https://www.sofastack.tech/sofa-acts/docs/Home 招聘 蚂蚁金服金融核心测试技术团队持续寻找对测试自动化、智能风险管控等方向充满热情的小伙伴加入，有意者请联系 zhiqiang.li@antfin.com\n","date":1552546800,"description":"SOFAStack 体系，基于模型驱动的自动化接口测试框架 SOFAACTS。","dir":"blog/sofa-acts-automated-testing-framework/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b76c650b1a69560fe38c8e4f237f6207","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-acts-automated-testing-framework/","publishdate":"2019-03-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-acts-automated-testing-framework/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 蚂蚁金服在 SOFAStack 体","tags":["SOFAActs"],"title":"SOFAStack 开源自动化测试框架 SOFAACTS","type":"blog","url":"/sofastack.tech/blog/sofa-acts-automated-testing-framework/","wordcount":2096},{"author":"家纯","categories":"SOFAJRaft","content":" 什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 Raft 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。 SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\n 基础知识：分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 Paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 Paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等）。 Zab：被应用在 Zookeeper 中，业界使用广泛，但没有抽象成通用的 library。 Raft：以容易理解著称，业界也涌现出很多 Raft 实现，比如大名鼎鼎的 etcd, braft, tikv 等。 什么是 Raft？ Raft 是一种更易于理解的分布式共识算法，核心协议本质上还是师承 Paxos 的精髓，不同的是依靠 Raft 模块化的拆分以及更加简化的设计，Raft 协议相对更容易实现。\n模块化的拆分主要体现在：Raft 把一致性协议划分为 Leader 选举、MemberShip 变更、日志复制、Snapshot 等几个几乎完全解耦的模块。\n更加简化的设计则体现在：Raft 不允许类似 Paxos 中的乱序提交、简化系统中的角色状态（只有 Leader、Follower、Candidate 三种角色）、限制仅 Leader 可写入、使用随机化的超时时间来设计 Leader Election 等等。\n特点：Strong Leader 系统中必须存在且同一时刻只能有一个 Leader，只有 Leader 可以接受 Clients 发过来的请求； Leader 负责主动与所有 Followers 通信，负责将“提案”发送给所有 Followers，同时收集多数派的 Followers 应答； Leader 还需向所有 Followers 主动发送心跳维持领导地位(保持存在感)。 一句话总结 Strong Leader: \u0026amp;ldquo;你们不要 BB! 按我说的做，做完了向我汇报!\u0026amp;rdquo;。另外，身为 Leader 必须保持一直 BB(heartbeat) 的状态，否则就会有别人跳出来想要 BB 。\nRaft 中的基本概念 篇幅有限，这里只对 Raft 中的几个概念做一个简单介绍，详细请参考 Raft paper。\nRaft-node 的 3 种角色/状态 Follower：完全被动，不能发送任何请求，只接受并响应来自 Leader 和 Candidate 的 Message，每个节点启动后的初始状态一定是 Follower； Leader：处理所有来自客户端的请求，以及复制 Log 到所有 Followers； Candidate：用来竞选一个新 Leader （Candidate 由 Follower 触发超时而来）。 Message 的 3 种类型 RequestVote RPC：由 Candidate 发出，用于发送投票请求； AppendEntries (Heartbeat) RPC：由 Leader 发出，用于 Leader 向 Followers 复制日志条目，也会用作 Heartbeat （日志条目为空即为 Heartbeat）； InstallSnapshot RPC：由 Leader 发出，用于快照传输，虽然多数情况都是每个服务器独立创建快照，但是Leader 有时候必须发送快照给一些落后太多的 Follower，这通常发生在 Leader 已经丢弃了下一条要发给该Follower 的日志条目(Log Compaction 时清除掉了) 的情况下。 任期逻辑时钟 时间被划分为一个个任期 (term)，term id 按时间轴单调递增； 每一个任期的开始都是 Leader 选举，选举成功之后，Leader 在任期内管理整个集群，也就是 “选举 + 常规操作”； 每个任期最多一个 Leader，可能没有 Leader (spilt-vote 导致)。 本图出自《Raft: A Consensus Algorithm for Replicated Logs》\n什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 Raft 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\nSOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nSOFAJRaft 整体功能\u0026amp;amp;性能优化 功能支持 Leader election：Leader 选举，这个不多说，上面已介绍过 Raft 中的 Leader 机制。\n Log replication and recovery：日志复制和日志恢复。\n Log replication 就是要保证已经被 commit 的数据一定不会丢失，即一定要成功复制到多数派。 Log recovery 包含两个方面： Current term 日志恢复：主要针对一些 Follower 节点重启加入集群或者是新增 Follower 节点后如何追日志； Prev term 日志恢复：主要针对 Leader 切换前后的日志一致性。 Snapshot and log compaction：定时生成 snapshot，实现 log compaction 加速启动和恢复，以及 InstallSnapshot 给 Followers 拷贝数据，如下图：\n 本图出自《In Search of an Understandable Consensus Algorithm》\n Membership change：用于集群线上配置变更，比如增加节点、删除节点、替换节点等。\n Transfer leader：主动变更 leader，用于重启维护，leader 负载平衡等。\n Symmetric network partition tolerance：对称网络分区容忍性。\n 如上图 S1 为当前 leader，网络分区造成 S2 不断增加本地 term，为了避免网络恢复后 S2 …","date":1552374000,"description":"本文为 SOFAJRaft 的基础解析，欢迎阅读~","dir":"blog/sofa-jraft-production-level-algorithm-library/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a2e98969240f05af10554781f4ab81ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","publishdate":"2019-03-12T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","summary":"什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用","tags":["SOFAJRaft","SOFALab"],"title":"SOFAStack 开源 SOFAJRaft：生产级 Java Raft 算法库","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","wordcount":6481},{"author":"Linux 中国 老王","categories":"SOFAStack","content":" 我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\u0026amp;ndash; 蚂蚁金服总监杨冰\n引言 最近，我听到了一个消息，蚂蚁金服将会开源 SOFA最核心的两个组件——分布式事务框架和服务注册中心。\n熟悉中间件的朋友们都知道，这两个组件都是针对当前最火的微服务架构。其中，分布式事物框架是解决数据一致性问题的关键。服务注册中心则是服务治理的基础。在这两块开源后，SOFA 将成为一套真正完备的分布式解决方案。\n作为开源人士，我对此消息深感兴趣，因此联系到了蚂蚁金服中间件团队的杨冰总监，就此消息向他求证。机缘凑巧之下，杨冰花费了宝贵的时间，和我深入讲述了 SOFA 开源的思考，以及近期的规划。\n通过这次交谈，也让我看到了一个成功的商业公司是如何拥抱开源、并将开源作为其根本战略来撬动技术红利，支持其急速发展的业务需求的。\n以下是正文，我将它分享出来以飨读者。\n如今，开源已经成为主流，可以说，整个信息产业已经从过去的闭源模式转换为现今的开源模式。各种开源公司纷纷创新不同的开源模式，其中以 RedHat、Google、Facebook 等公司所取得的成绩最为耀眼。\n2018 年的时候，我曾经参与“开源社”主持的《2018 中国开源年度报告》的撰写工作，并建立了一个数学分析模型，以此来对中国的互联网公司的开源项目分析其活跃度和健康度。让我既感意外，也不意外的是，阿里系的开源项目占据了活跃度排行榜前五的第一、第二和第四；甚至在前五十个项目中，阿里系的开源项目占据了超过一半的份额！我不意外的是，业界一直对阿里在开源方面的动作和力度颇有感受；意外的是，这种力度还是超乎了我的想象。这其中包括阿里巴巴集团和蚂蚁金服等都贡献了相当可观的开源项目。\n因此，这次遇到杨冰时，我就开源方面和他深入聊了几句，想了解一下蚂蚁金服是如何思考开源和践行开源的，是如何将开源与公司的商业价值有机地结合起来的。\n缘何开源 作为一家商业公司，宣称自己开源，甚至也形式上开源一些代码，其实已经是很常见的事情了。但是，真正能将开源与公司的技术演进相融合，并能有效地助推公司业务发展的，却并不太多。这件事其实并没有那么简单——远非只是上传到 GitHub 那么简单。\n根据业界的经验，在公司的技术产品开源方面，要将现有场景的代码开源，至少需要在已经运行稳定、结构清晰的现有代码基础上多付出 30% 的技术投入，对代码进行梳理、完善和通用化，才能做到初步的代码开源；而进一步要将这些开源代码维护下去，乃至于和公司业务线上的产品代码保持同步发展，多付出的技术成本还远远不止这些。作为一个互联网技术老兵，我对此深以为然。\n那么，蚂蚁金服是如何说服公司决策层在尚未看到开源回报的前景下，同意付出这么多的额外代价来支持开源的呢？推动开源的力量是因何而来的？\n“首先，开源是个共赢的模式，对于蚂蚁金服来说，开源可以扩大技术服务场景，为支付、金融等更多的客户提供服务，提升合作伙伴的效率。”杨冰说，“虽然，蚂蚁金服已经有很多的业务场景，也在很多场景下取得了超大规模的实践经验，但是，依然存在没有覆盖到的金融服务场景。而将技术开源出来，可以供更多的客户应用到其自身的场景下——这些场景有效的补充了蚂蚁金服的技术应用面，也为更完善的技术框架奠定了基础。因此，我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。”\n“其次，对金融服务来说，监管和自主可控的要求更多，”杨冰接着谈到，“客户也希望可以对其所采用的技术有更多的掌控。”开源是一种可以使客户和上下游产业共同参与和发展的可行模式。\n“所以，其实并不是技术部门去说服公司决策层去开源，而是业务发展的自然选择，这也是一种合理的发展方向。”他总结道。这样的结果，其实是和当前流行的开源商业模式所暗合的。\n“另外，如你所说，确实在开源时，我们做了很大的改造。以可扩展化的方式来层层构建 SOFA 框架的能力，保证 SOFA 的内部版本和开源的版本采用的是同一个内核。在开源时，剥离了特定业务的逻辑，而保持了公司内部的业务线上的代码和开源代码的核心是一致的。这样，只要公司的业务在持续发展，开源的代码就会一直维护和演进下去。所以 SOFA 的内部版本就是在开源版本之上扩展了内部逻辑和历史版本的兼容逻辑。开源版本的核心逻辑，内外是一致的，并在蚂蚁金服的生产环境中被广泛使用，同时会随着蚂蚁金服自身业务诉求的驱动不断的演进。”杨冰补充道，“但这是值得的，在为开源代码做改进时，也是为公司自己的业务做改进，这是双赢且可持续发展的。”\n很多公司在初涉开源时，常常有疑虑，将核心技术开放出去，会不会导致竞争对手的技术提升，会不会造成更大的技术竞争压力？\n“事实上，我们在最初准备开源时，也有讨论过这个方面。技术要被更多人用、更多场景用，才会有发展。而开放的技术才能带来团队的发展，因为技术是动态发展的，作为开源的一方，事实上在技术上是相对领先的。开源和掌握是两码事，掌握和用好又是两码事，所以，因开源而带来的竞争，其实是助推整个开源体系的发展的，是良性的、有益的。”杨冰说，“而从社区和行业现状看，大家都在开放，封闭的技术体系会逐渐落后。只有开放才能求同存异，共同发展。”\n 花絮\n我问蚂蚁金服的朋友，在你们开源中有什么有趣的“段子”吗？可以讲来听听。\n我朋友过了几天后，给我发来了这样一段文字：\n“参与双十一的中间件团队的常态是什么呢？\n当晚，团队的常态大概就是喝着茶等零点高峰，高峰期过了之后，当然就是参与买买买啦。 我们很多的一些事情的初始想法都是来自于双十一当天的夜聊，似乎在经历了紧张的零点高峰之后，脑细胞特别活跃。\n对于基础设施团队来说，双十一算是一次大考的结束，考完成绩出来了，我们就想琢磨一些有挑战的事情，于是我们会天马行空地聊一聊对于下一年在技术上需要去做的事情。而在 2017 年的双十一当天，SOFA 的几个同学就围在一起聊了 SOFA 能不能开源？为什么要开源？开源和商业化之间的关系？开源后要做哪些事情等等，这个算是 SOFA 开源的第一次内部讨论。\n从这次内部讨论之后，经过了大约半年的准备时间，我们在 2018 年 4 月份正式宣布开源并一直在逐步开源的进程中。”\n他说，这就是他们憋了半天想出来的“段子”，哈哈哈，这群可爱的技术人啊。\n SOFA 的演进和开源之路 SOFA 中间件框架是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\nSOFA 开源全景图，涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的Nacos、Sentinel等，为用户提供更加广泛地选择。\nSOFA 作为一个演进了几年的框架，也一定程度上代表了蚂蚁金服的技术体系的演变，并且现在形成了开源核心、开放式（组件式）开源的模式。SOFA 从 2018 年开始开源，但是我比较好奇 SOFA 开源之前的发展旅程是怎样的。\n杨冰说，“最早的时候，在蚂蚁金服还没有从淘宝分拆出来时，公司内使用过一个 …","date":1552287600,"description":"我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。","dir":"blog/financial-technology-meet-open-source/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"620bf66a94dd1d8b872cb4cb90ca3028","permalink":"https://sofastack.github.io/sofastack.tech/blog/financial-technology-meet-open-source/","publishdate":"2019-03-11T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/financial-technology-meet-open-source/","summary":"我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\u0026ndas","tags":["SOFAStack"],"title":"蚂蚁金服总监杨冰：金融科技公司为什么要拥抱开源？ | 穿山甲专访","type":"blog","url":"/sofastack.tech/blog/financial-technology-meet-open-source/","wordcount":6192},{"author":"潘潘","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布 活动时间：3 月 24 日周日下午 13 点 活动地点：北京中关村创业大街 氪空间 活动形式：线下活动 活动视频回顾：https://tech.antfin.com/community/activities/382 活动介绍 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。 欢迎 Star 我：https://github.com/alipay\nSOFA Meetup#1 北京站-服务注册中心、分布式事务重磅发布 这次的 Meetup 是 SOFAStack 第一场线下活动，也是 SOFA 开源一周年的线下庆祝会。\n我们将带来重磅发布，继续补充 SOFAStack 的开源大图，届时除了 SOFA 团队的见面交流之外，也安排了周年的庆祝环节，期待与朋友们的见面。\n重磅发布：开源蚂蚁金服分布式事务 蚂蚁金服内部的分布式事务框架已经发展十多年，广泛用于解决各类复杂业务场景的数据一致性问题，同时经受大规模业务挑战，在高性能、高可用等方面也积累了丰富的实践经验。\n这次，将带来蚂蚁金服分布式事务十多年的技术总结分享，同时也会宣布开源版本。\n重磅发布：开源蚂蚁金服注册中心 SOFARegistry SOFARegistry 是蚂蚁金服开源的服务注册中心。\nSOFARegistry： https://github.com/alipay/sofa-registry\nSOFARegistry 最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。目前 SOFARegistry 不仅全面应用于蚂蚁金服的自有业务，还随着蚂蚁金融科技输出，助力广大合作伙伴，同时也兼容开源生态。SOFARegistry 最新一代内部版与商业版，均以开源版为基础内核，在其上开发内部特性插件。\n更多内容，到现场来看\n加入 SOFA 钉钉互动群 群号：23127468，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n议程 时间 环节 嘉宾介绍 13:00 - 13:30  签到 13:40 - 14:20  《SOFAStack 开源这一年》 蚂蚁金服技术总监 杨冰 14:20 - 15:00 《SOFARegistry \u0026amp;ndash; 蚂蚁金服高性能服务注册中心开源》 蚂蚁金服服务注册中心开源负责人 尚彧 15:00 - 15:20 庆祝一周年环节 15:20 - 16:00  《SOFAFescar \u0026amp;ndash; 蚂蚁金服分布式事务开源以及实践》 蚂蚁金服分布式事务开源负责人 绍辉 16:00 - 16:40 《SOFAJRaft \u0026amp;ndash; 蚂蚁金服基于 RAFT 一致性算法的生产级高性能 Java 实现》 蚂蚁金服 SOFAJRaft 核心成员 力鲲 16:40 - 17:00  互动交流 ","date":1552277400,"description":"SOFA Meetup#1 北京站，3 月 24 日周日下午 13 点，北京中关村创业大街氪空间。","dir":"activities/sofa-meetup-1/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dd713adb17a610bef8a0f6ed06cace55","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-1/","publishdate":"2019-03-11T12:10:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofa-meetup-1/","summary":"概要 活动主题：SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布 活动时间：3 月 24 日周日下午 13 点 活动地点：北京中关村创业大街 氪空间 活动形式：","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-1/","wordcount":1037},{"author":"SOFA 团队","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFA 文档: http://www.sofastack.tech/ SOFA: https://github.com/alipay\n 最新的 SOFARPC 5.5.1 已经发布啦，本文给大家介绍下 SOFARPC v5.5.x 系列主要提供的特性以及使用方式。\nSOFARPC 作为成熟的 RPC 框架，一直致力于给用户提供稳定可靠的 RPC 框架 以及最自主的选择权。SOFARPC 的插件扩展机制可以支持各类实现的可插拔实现。\nSOFARPC 5.5 主要给开发者们带来了服务发现的新选择：Nacos 的集成 与 服务容错对 Hystrix 的集成。\n服务注册 Nacos 新选择 Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。根据 Nacos 的 Roadmap，0.8.0 已具备生产使用的能力，截止笔者撰稿时间，Nacos 已发布 0.9.0，距离 1.0.0 越来越近了。\nSOFARPC 5.5.0 开始提供对 Nacos 的集成，以下介绍两种使用方式：\n1、SOFABoot 集成 Nacos SOFABoot 从 2.5.3 开始已集成 SOFARPC 对 Nacos 的配置支持，假如开发者本机已经根据 Nacos 快速开始安装并启动 Nacos Server。\n根据 RPC 的示例工程创建一个 SOFABoot 工程，SOFABoot 工程使用 2.5.3。\n$ git clone git@github.com:alipay/sofa-rpc-boot-projects.git $ git checkout 5.x 在 application.properties 中配置服务注册中心地址信息，就能够使用 Nacos 作为注册中心。\n$ vi sofa-boot-samples/src/main/resources/application.properties com.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 启动 RPC 服务端实例工程：\nrun com.alipay.sofa.rpc.samples.invoke.InvokeServerApplication 启动成功后即可在 Nacos 服务端看到服务注册信息：Nacos 服务列表 （注：如果用户自己部署了nacos 的服务端，可以通过这个地址访问）\n启动 RPC 客户端调用工程：\nrun com.alipay.sofa.rpc.samples.invoke.InvokeClientApplication 可以看到调用成功结果，分别代表同步、异步、回调调用成功：\nsync future callback client process:callback 2、SOFARPC 独立集成 Nacos SOFARPC 独立使用集成 Nacos 也很简单，只需要将注册中心地址设置为 Nacos 服务地址即可。\n引入 SOFARPC：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; API 方式发布服务：\n# 构造服务注册中心配置 RegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;nacos\u0026amp;quot;) .setSubscribe(true) .setAddress(\u0026amp;quot;127.0.0.1:8848\u0026amp;quot;) .setRegister(true); # 构造服务端口配置 ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setHost(\u0026amp;quot;0.0.0.0\u0026amp;quot;) .setPort(12200); # 构造服务发布者 ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRef(new HelloServiceImpl()) .setServer(serverConfig) .setRegister(true) .setRegistry(Lists.newArrayList(registryConfig)); providerConfig.export(); 即可发布服务至 Nacos Server。\n服务容错支持 Hystrix 在大规模的分布式系统中，一个完整的请求链路会跨越多个服务，其中每一个节点出现故障都将放大到全局，轻则造成执行逻辑崩溃，重则消耗掉所有资源拖垮整个系统。\nHystrix 是 Netflix 开源的容错组件，提供以下功能以解决该问题：\n 通过线程池或是信号量对资源进行隔离，避免依赖服务在故障时使用大量资源拖垮整个应用 使用熔断器模式（Circuit Breaker pattern）实现请求故障服务的快速失败（fail-fast），避免故障服务所造成的延时影响整体请求的延时 提供故障降级（Fallback）使用户可以编写优雅降级的策略，防止故障传递到上层 提供准实时的监控指标，使每一个依赖服务的请求结果和延时可观测 在 SOFARPC 中使用 Hystrix Hystrix 本身使用命令模式（Command pattern）实现了 API，我们在 SOFARPC 中对其进行了封装，只需要简单配置即可开启相关功能。\nHystrix 作为 SOFARPC 的可选模块默认不会进行加载，所以首先需要显式在项目中添加 Hystrix 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后通过开关选择开启全局的 Hystrix 支持，或是只对一部分 Consumer 开启：\n// 全局开启 RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // …","date":1551769200,"description":"最新的 SOFARPC 5.5.1 已经发布啦，本文给大家介绍下 SOFARPC v5.5.x 系列主要提供的特性以及使用方式。","dir":"blog/sofarpc-5.5.x-nacos-hystrix/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c712254801354ae1b1bd22cd39b80ec2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","publishdate":"2019-03-05T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFA 文档: http://www.sofastack.tech/ SOFA: https://github.com/alipay","tags":["SOFARPC"],"title":"SOFARPC 5.5.X 新版发布 | 集成 Nacos 与 Hystrix","type":"blog","url":"/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","wordcount":2473},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo） 活动时间：2 月 28 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 SOFA:Channel/，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\nSOFA:Channel/ 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n本期 SOFAChannel 为 SOFARPC 专场，分为上下两篇，将采用内容分享与 Demo 实际操作结合的形式进行。\n本期为上篇，下篇将在 2 月 28 日开展，记得关注哟~\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 时间：2019-02-21 19:00-20:00 《SOFARPC 性能优化（上）—— 详解优化设计点》 蚂蚁金服 SOFA 团队 碧远 在业务规模大并发极高的情况下，RPC 对性能的追求就变得极为重要，任何一点小的优化都会累积提高业务整体性能。 本期手把手带你解读： 自定义通信协议使用有哪些注意细节？ SOFARPC 如何进行连接保持？ 在 IO 线程池中批量解包带来的性能提升有哪些？\n嘉宾 蚂蚁金服 SOFA 团队 碧远\n","date":1551349200,"description":"本次为下半场，2 月 28 日晚 7 点，线上直播。","dir":"activities/sofa-channel-3/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"202f32cfe0c8a1c3aacbf435389a956f","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-3/","publishdate":"2019-02-28T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-3/","summary":"概要 活动主题：SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo） 活动时间：2 月 28 日周四晚 7 点 活动形","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo）","type":"activities","url":"/sofastack.tech/activities/sofa-channel-3/","wordcount":477},{"author":"碧远","categories":"SOFARPC","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第三期，SOFARPC 性能优化（下），进一步分享 SOFARPC 在性能上做的一些优化。 本期你将收获：\n 如何控制序列化和反序列化的时机； 如何通过线程池隔离，避免部分接口对整体性能的影响； 如何进行客户端权重调节，优化启动期和故障时的性能； 服务端 Server Fail Fast 支持，减少无效操作； 在 Netty 内存操作中，如何优化内存使用。 欢迎加入直播互动钉钉群：23127468，不错过每场直播。\n 大家好，今天是 SOFAChannel 第三期，欢迎大家观看。\n我是来自蚂蚁金服中间件的雷志远，花名碧远，目前负责 SOFARPC 框架的相关工作。在上一期直播中，给大家介绍了 SOFARPC 性能优化方面的关于自定义协议、Netty 参数优化、动态代理等的优化。\n 往期的直播回顾，可以在文末获取。\n本期互动中奖名单： @司马懿 @邓从宝 @雾渊，请文章下方回复进行礼品领取\n 今天我们会从序列化控制、内存操作优化、线程池隔离等方面来介绍剩余的部分。\n序列化优化 上次介绍了序列化方式的选择，这次主要介绍序列化和反序列化的时机、处理的位置以及这样的好处，如避免占用 IO 线程，影响 IO 性能等。\n上一节，我们介绍的 BOLT 协议的设计，回顾一下：\n可以看到有这三个地方不是通过原生类型直接写的：ClassName，Header，Content 。其余的，例如 RequestId 是直接写的，或者说跟具体请求对象无关的。所以在选择序列化和反序列化时机的时候，我们根据自己的需求，也精确的控制了协议以上三个部分的时机。\n对于序列化 serializeClazz 是最简单的：\nbyte[] clz = this.requestClass.getBytes(Configs.DEFAULT_CHARSET); 直接将字符串转换成 Byte 数组即可，跟具体的任何序列化方式，比如跟采用 Hessian 还是 Pb 都是无关的。\nserializeHeader 则是序列化 HeaderMap。这时候因为有了前面的 requestClass，就可以根据这个名字拿到SOFARPC 层或者用户自己注册的序列化器。然后进行序列化 Header，这个对应 SOFARPC 框架中的 SofaRpcSerialization 类。在这个类里，我们可以自由使用本次传输的对象，将一些必要信息提取到Header 中，并进行对应的编码。这里也不跟具体的序列化方式有关，是一个简单 Map 的序列化，写 key、写 value、写分隔符。有兴趣的同学可以直接看源码。\n源码链接：https://github.com/alipay/sofa-bolt/blob/531d1c0d872553d92fc55775565b3f7be8661afa/src/main/java/com/alipay/remoting/rpc/protocol/RpcRequestCommand.java#L66\nserializeContent 序列化业务对象的信息，这里 RPC 框架会根据本次用户配置的信息决定如何操作序列化对象，是调用 Hessian 还是调用 Pb 来序列化。\n至此，完成了序列化过程。可以看到，这些操作实际上都是在业务发起的线程里面的，在请求发送阶段，也就是在调用 Netty 的写接口之前，跟 IO 线程池还没什么关系，所以都会在业务线程里先做好序列化。\n对于反序列化 介绍完序列化，反序列化的时机就有一些差异，需要重点考虑。在服务端的请求接收阶段，我们有 IO 线程、业务线程两种线程池。为了最大程度的配合业务特性、保证整体吞吐，SOFABolt 设计了精细的开关来控制反序列化时机。\n具体选择逻辑如下：\n体现在代码的这个类中。\ncom.alipay.remoting.rpc.protocol.RpcRequestProcessor#process 从上图可以看到 反序列化 大致分成以下三种情况，适用于不同的场景。\n IO 线程池动作 业务线程池 使用场景 反序列化 ClassName 反序列化 Header 和 Content 处理业务 一般 RPC 默认场景。IO 线程池识别出来当前是哪个类，调用用户注册的对应处理器 反序列化 ClassName 和 Header 仅反序列化 Content 和业务处理 希望根据 Header 中的信息，选择线程池，而不是直接注册的线程池 一次性反序列化 ClassName、Header 和 Content，并直接处理 没有逻辑 IO 密集型的业务 线程池隔离 经过前面的介绍，可以了解到，由于业务逻辑通常情况下在 SOFARPC 设置的一个默认线程池里面处理，这个线程池是公用的。也就是说， 对于一个应用，当他作为服务端时，所有的调用请求都会在这个线程池中处理。\n举个例子：如果应用 A 对外提供两个接口，S1 和 S2，由于 S2 接口的性能不足，可能是下游系统的拖累，会导致这个默认线程池一直被占用，无法空闲出来被其他请求使用。这会导致 S1 的处理能力受到影响，对外报错，线程池已满，导致整个业务链路不稳定，有时候 S1 的重要性可能比 S2 更高。\n因此，基于上面的设计，SOFARPC 框架允许在序列化的时候，根据用户对当前接口的线程池配置将接口和服务信息放到 Header 中，反序列化的时候，根据这个 Header 信息选择到用户自定义的线程池。这样，用户可以针对不同的服务接口配置不同的业务线程池，可以避免部分接口对整个性能的影响。在系统接口较多的时候，可以有效的提高整体的性能。\n内存操作优化 介绍完线程池隔离之后，我们介绍一下 Netty 内存操作的一些注意事项。在 Netty 内存操作中，如何尽量少的使用内存和避免垃圾回收，来优化性能。先看一些基础概念。\n内存基础 在 JVM 中内存可分为两大块，一个是堆内存，一个是直接内存。\n堆内存是 JVM 所管理的内存。所有的对象实例都要在堆上分配，垃圾收集器可以在堆上回收垃圾，有不同的运行条件和回收区域。\nJVM 使用 Native 函数在堆外分配内存。为什么要在堆外分配内存？主要因为在堆上的话， IO 操作会涉及到频繁的内存分配和销毁，这会导致 GC 频繁，对性能会有比较大的影响。\n注意：直接分配本身也并不见得性能有多好，所以还要有池的概念，减少频繁的分配。\n因此 JVM 中的直接内存，存在堆内存中的其实就是 DirectByteBuffer 类，它本身其实很小，真的内存是在堆外，通过 JVM 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。直接内存不会受到 Java 堆的限制，只受本机内存影响。当然可以设置最大大小。也并不是 Direct 就完全跟 Heap 没什么关系了，因为堆中的这个对象持有了堆外的地址，只有这个对象被回收了，直接内存才能释放。\n其中 DirectByteBuffer 经过几次 young gc 之后，会进入老年代。当老年代满了之后，会触发 Full GC。\n因为本身很小， …","date":1551337200,"description":"本文根据 SOFAChannel#3 直播分享整理，进一步分享 SOFARPC 在性能上做的一些优化。","dir":"blog/sofa-channel-3-retrospect/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7a816fa5f942ce857c10ebb1c416482d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-3-retrospect/","publishdate":"2019-02-28T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-channel-3-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第三期，SOFARPC 性能优化（下），进一步分享 SOFARPC 在性能上做的一些优化。 本期你","tags":["SOFARPC","SOFAChannel"],"title":"SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-3-retrospect/","wordcount":5775},{"author":"心贵","categories":"Kubernetes","content":" 此文章适合没有任何 Kubernetes/容器/Docker 经验的同学 — 在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。此文章阅读耗时大概 15 分钟。\n 蚂蚁金服资源调度组致力于将 Kubernetes 落地到世界上最有价值的金融科技独角兽公司，欢迎联系作者微信： answer1991chen 咨询招聘事宜。\n文章 Markdown 源码位于 https://github.com/answer1991/articles/blob/master/Kubernetes-is-the-next-generation-os.md ，遵从 Apache License 2.0 开源协议。\n导言 此文章着重介绍如何在入门阶段使用 Kubernetes，以及要面向 Kubernetes 编程带来的优势，不会介绍复杂的 Kubernetes 架构、实现。因此此文章适合没有任何 Kubernetes/容器/Docker 经验的同学，对 Kubernetes 有了解的同学也可以从此文章里面获取一些灵感，可以更加酷炫的玩转 Kubernetes。\n希望在阅读完此文章之后，你可以从 “我需要一个 Linux VM 做开发、测试和部署”，变成 “我需要一个 Kubernetes 做开发、测试和部署”。\nKubernetes 是下一代操作系统 Kubernetes 是这几年非常热门的一个词汇，大概所有的软件工程师都已经听说过这个词。\n那么 Kubernetes 到底是什么呢？可能 Google 会告诉你很多，但是我想告诉你的是：Kubernetes 是下一代操作系统；一个 Kubernetes 集群是一个资源无限大(可扩容)的虚拟机。而且，Kubernetes 的接口是是声明式的，是天然面向分布式系统而设计的（下面会详细介绍）。\n说到这里，大家估计立刻就有疑问了。我想大概是这些：\nQ: 那么，Linux、Windows 要被淘汰了？\nA: 不会被淘汰，只是 Linux、Windows 是一个底层的单机操作系统。而我们这些普通的应用软件工程师将来都不会跟Linux 打交道了，都会使用 Kubernetes 这个更上层、同时功能也更强大的操作系统。\nQ: 那么，我不学 Kubernetes 可以吗？\nA: 不行！在未来不久的某一天，也许云厂商只卖 Kubernetes “虚拟机”了：阿里云不单独卖 ecs 了，亚马逊AWS，微软云，Google 云等各种云厂商都不卖 Linux 虚拟机了。如果你想买单机版的 Linux 虚拟机，他们都会一脸惊讶的问你，你买那么底层的、功能那么薄弱的计算机干什么？就像你现在从云厂商那里买不到一个还没有安装 Linux 的虚拟机一样。以后，云厂商交付的 “虚拟机” 必定是 “集群级别的虚拟机” ，而 “集群级别的虚拟机” 的操作系统就是 Kubernetes。\n在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。\nQ: 那这样的话，我买不到 Linux 虚拟机，我连学习 Linux 的机会都没有了？\nA: 当然不是，有了 Kubernetes，你可以在 1秒内自己搞一个任何 Linux 发行版本的 “单机虚拟机” 出来。\nQ: Kubernetes 真的是一个操作系统？ Show me\u0026amp;hellip;.\nA:\n 功能/名词 单机 Linux Kubernetes 说明 Shell, CMD sh, bash kubectl kubectl 是 Kubernetes 的 shell 工具，有了 kubectl 你就可以连接并管理 Kubernetes 这个超级虚拟机了。 用户，登录 Linux User, Group, ssh 登录 kubeconfig 文件类似 Linux ssh 的 .key 文件，用户使用 kubeconfig 访问 Kubernetes 就自带了用户信息。Kubernetes 能根据用户限制权限，也能限制用户能使用的资源。kubectl 使用 kubeconfig 访问 Kubernetes 就好比使用 .ssh key 访问 Linux Kubernetes 集群管理员(或者自动化的申请系统)为用户颁发 kubeconfig 文件。 进程 进程 Pod Pod 就是 Kubernetes 这个 “超级虚拟机” 的进程。 管理进程 ps, kill kubectl get po, kubectl delete pod 发布、升级、管理 “进程”(或者说应用) 配置管理 登录各个 Linux VM，替换机器上的文件。 kubectl apply -f ./cm.yaml 使用 ConfigMap 管理应用的配置文件，一次提交，进程的每个实例自动生效新的配置。由于篇幅管理，使用 ConfigMap 配置应用（“进程”）启动参数不在此文章里面举例。 发布、管理、升级应用 在 Linux 上面发布一个应用，需要一顿疯狂的操作：先阅读如何发布、参数有什么、下载二进制包、搞定一些配置文件，然后运行应用。 kubectl apply -f ./my-app.yaml my-app.yaml 可能是应用提供商提供的、面向 Kubernetes 发布应用的“菜单”文件(为什么叫“菜单”我后面会介绍)。只要提交这个“菜单”，应用就部署好了。Kubernetes 让一切简单，而且，它是分布式，是天然容灾的。只要向 Kubernetes 提交 Deployment 这样的“资源”即可，下文有介绍。 限制应用资源 一顿疯狂的操作，把应用进程的 Cgroup 限制好。 发布应用时已经做了 Kubernetes 让一切简单。 分布式应用发布 在各个 Linux 虚拟机上面发布好应用，然后把他们组网。 发布应用时已经做了 还是那句话，Kubernetes 让一切简单。 分布式应用容灾 搞个监控，监控我们各个 Linux 虚拟机上面的应用是不是不健康了。不健康了的话，我们起床，来一次“一顿操作猛如虎”的故障恢复操作。 / 天然容灾，安心睡你的觉。 数据持久化，故障时数据迁移 “一顿操作猛如虎” 用 PV（持久化存储卷），容灾把应用的一个应用实例从 “节点一” 切换到了 “节点二”，都不用做任何数据迁移。新的应用实例起来就能使用老数据。 还是那句话，Kubernetes 让一切简单。我都不用关心这个事情。（由于篇幅管理，下文的例子中也不会涉及 PV 的例子） “一顿操作猛如虎” 听起来很酷，但是你在做一些没必要的事情，同时你做了这些事情并不讨好你的老板，可能在因为你的失误操作引起更大的故障和问题。\n面向 Kubernetes 做最简单的操作，达到最佳的效果，才是更酷的事情。\nA: 行了行了，别说那么多了，我还是需要一个 Linux VM。\nQ: 好的，我给您一个 Kubernetes，然后给你一个 基础 OS Pod “菜单”文件，然后您自己就可以创建任何一个 Linux 发行版、任何一个 Linux 版本的的 Linux VM …","date":1551078000,"description":"希望在阅读完此文章之后，你可以从 “我需要一个 Linux VM 做开发、测试和部署”，变成 “我需要一个 Kubernetes 做开发、测试和部署”。","dir":"blog/kubernetes-the-next-gen-os/","fuzzywordcount":8600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"09e6dbd10bffdeea13865fc45e3b3ee5","permalink":"https://sofastack.github.io/sofastack.tech/blog/kubernetes-the-next-gen-os/","publishdate":"2019-02-25T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/kubernetes-the-next-gen-os/","summary":"此文章适合没有任何 Kubernetes/容器/Docker 经验的同学 — 在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。","tags":["Kubernetes"],"title":"Kubernetes 是下一代操作系统 | 面向 Kubernetes 编程","type":"blog","url":"/sofastack.tech/blog/kubernetes-the-next-gen-os/","wordcount":8595},{"author":"碧远","categories":"SOFARPC","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第二期，主要分享 SOFARPC 在性能上做的一些优化，这个系列会分成上下两部分进行分享，今天是 SOFARPC 性能优化（上），也会对本次分享中的一些结论，提供部分代码 Demo，供大家了解验证。 欢迎加入直播互动钉钉群：23127468，不错过我们每场直播。\n 大家好，今天是我们 SOFAChannel 第二期。欢迎大家观看。\n我是来自蚂蚁金服中间件的雷志远，花名碧远，目前在负责 SOFARPC 框架相关工作。\n去年的时候，我们和外部的爱好者们一起，做了一个基于 SOFARPC 的源码解析系列，我同事已经发到群里了，大家可以保存，直播之后查看。\nSOFARPC 源码解析系列：（点击【剖析 | SOFARPC 框架】即可查看）\nhttps://www.sofastack.tech/blog/ 今年，基于源码解析的基础，我们来多讲讲实践，如何应用到大家的业务，来帮助大家解决实际问题。在直播过程中有相关的问题想提问，可以在钉钉群互动。\n前言 在上一期中，余淮分享了《从蚂蚁金服微服务实践谈起》。介绍了蚂蚁微服务的起源，以及之后服务化，单元化的情况。同时介绍了 SOFAStack 目前开源的情况。最后也分享了一下整个微服务中 SOFARPC 的设计与实现。\n本期，我们主要分享 SOFARPC 在性能上做的一些优化。这个系列会分成上下两部分进行分享，今天是 SOFARPC 性能优化（上），也会对本次分享中的一些结论，提供部分代码 Demo，供大家了解验证。\n我们先简要介绍一下 SOFARPC 的框架分层。这个在上次的分享中已经进行了介绍。\n下层是网络传输层，依次是协议，序列化，服务发现和 Filter 等。\nTransport 主要负责数据传输，可以是 Http2Transport，也可以是 BoltTransport，还有可能是其他。\nProtocol 层是协议，是 Rest 还是 Bolt ，或者是 Dubbo 。\nSerialization 是序列化，对于每种协议，可以是用不同的序列化方式，比如 hessian，pb，json 等。\nFilter 是通用的过滤器层，主要是为了留出一些扩展，完成一些其他扩展功能，比如 Tracer 的埋点等。\nRouter 是路由层，主要是做寻址，这里可能是 Zk，也可能是 LVS，也可能是直连。Cluster 是客户端集群方式的表示。\n自定义通讯协议使用 首先我想介绍一下自定义通讯协议。\n在说明自定义通讯协议之前，我先简单介绍一下通讯协议。在TCP之上，RPC框架通常还需要将请求和响应数据进行一定的封装，组装成 Packet，然后发送出去。这样，服务端收到之后，才能正确识别整个 TCP 发过来的字节流中，哪一部分是我们可以进行处理的一个完整单位。反之，客户端收到服务端的TCP 数据流也是如此。\n有了上面的共识之后，我们要回答下面两个问题：\n 为什么要自定义，不使用 Http2/Dubbo/Rest/Grpc？ 自定义之后，带来了什么好处呢？ Http2 虽然更为通用，但是一方面，出现较晚，迁移转换成本高，并且通用则意味着传输的辅助数据会变多，会有一些额外的信息需要传递或者判断。对于序列化反序列化的控制上，也不是很好扩展操作。\n而 Dubbo，协议简单强大。但是一些元信息需要解析，Header 中传输的数据太少，很多都需要依赖 body 中的数据反序列化完成后才能使用，头部的信息太少。\n而使用了自研的协议之后，Header 中可自定义传输更多的元信息，序列化方式，Server Fail Fast，服务端线程隔离等也都成为可能。甚至蚂蚁在 ServiceMesh 的场景下，Mesh 本身也能利用 Bolt 的协议，进行部分数据的读取，而不依赖具体的序列化实现。\n经过我们的实践，大致来看，目前给我们带来的好处主要有以下的能力：\n Server Fast 的支持 Header 和 Body 的分开序列化 Crc 校验的支持 版本的支持，预防未来可能出现的更好的设计方案 多种序列化方式的支持 安全认证，Mesh 路由 如果你要自己设计一个通讯协议。可以考虑使用 BOLT 协议，或者参考进行更好的设计和优化。\n关于 SOFABolt 相关的源码解析，也可以通过这个系列来了解。\nSOFABolt 源码解析系列：点击【剖析 | SOFABOLT 框架】即可查看） https://www.sofastack.tech/blog Netty 性能参数优化 在介绍了自定义通讯协议之后，也就是确定好了怎么封包解包之后，还需要确定传输层的开发。一个 RPC 框架从现在的情况来看，一般不太可能完全基于 JAVA 的 NIO 或者其他 IO 进行直接的开发，主要是一些 NIO 原生的问题和使用难度，而成熟的，目前可选的不多。基本上，大家都会基于 Netty 进行开发，HSF/Dubbo/Motan 等都是这样。\n直接使用是比较简单的。在 Netty 的 Bootstrap 的设置中，有一些可选的优化项，有必要跟大家分享一下。\n1. SO_REUSEPORT/SO_REUSEADDR - 端口复用(允许多个 socket 监听同一个IP+端口)\nSO_REUSEPORT 支持多个进程或者线程绑定到同一端口，提高服务器的接收链接的并发能力，由内核层面实现对端口数据的分发的负载均衡，在服务器 socket 上没有了锁的竞争。\n同时 SO_REUSEADDR也要打开，这样针对 time-wait 链接 ，可以确保 server 重启成功。在一些服务端启动很快的情况下，可以防止启动失败。\n2. TCP_FASTOPEN - 3次握手时也用来交换数据\n三次握手的过程中，当用户首次访问服务端时，发送 syn 包，server 根据客户端 IP 生成 cookie ，并与 syn+ack 一同发回客户端；客户端再次访问服务端时，在 syn 包携带 TCP cookie；如果服务端校验合法，则在用户回复 ack 前就可以直接发送数据；否则按照正常三次握手进行。也就是说，如果客户端中途断开，再建联的时候，会同时发送数据，会有一定的性能提升。\nTFO 提高性能的关键是省去了热请求的三次握手，这在小对象传输较多的移动应用场景中，能够极大提升性能。\nNetty 中仅在 Epoll 的时候可用 Linux特性，不能在 Mac/Windows 上使用，SOFARPC 未开启。\n3. TCP_NODELAY-关闭 (纳格) Nagle 算法，再小的包也发送，而不是等待\nTCP/IP 协议中针对 TCP 默认开启了 Nagle 算法。Nagle 算法通过减少需要传输的数据包个数，来优化网络。但是现在的环境下，网络带宽足够，需要进行关闭。这样，对于传输数据量小的场景，能很好的提高性能，不至于出现数据包等待。\n4. SO_KEEPALIVE –开启 TCP 层面的 Keep Alive 能力\n这个不多说，开启一下 TCP 层面的 Keep Alive 的能力。\n5. WRITE_BUFFER_WATER_MARK …","date":1551078000,"description":"本文根据 SOFAChannel#2 直播分享整理，主要分享 SOFARPC 在性能上做的一些优化。","dir":"blog/sofa-channel-2-retrospect/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6751c882f7879a7dd9c9f49823410ffc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-2-retrospect/","publishdate":"2019-02-25T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-2-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第二期，主要分享 SOFARPC 在性能上做的一些优化，这个系列会分成上下两部分进行分享，今天","tags":["SOFARPC","SOFAChannel"],"title":"SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-2-retrospect/","wordcount":5077},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 活动时间：2 月 21 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 SOFA:Channel/，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\nSOFA:Channel/ 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n本期 SOFAChannel 为 SOFARPC 专场，分为上下两篇，将采用内容分享与 Demo 实际操作结合的形式进行。\n本期为上篇，下篇将在 2 月 28 日开展，记得关注哟~\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 时间：2019-02-21 19:00-20:00 《SOFARPC 性能优化（上）—— 详解优化设计点》 蚂蚁金服 SOFA 团队 碧远 在业务规模大并发极高的情况下，RPC 对性能的追求就变得极为重要，任何一点小的优化都会累积提高业务整体性能。 本期手把手带你解读： 自定义通信协议使用有哪些注意细节？ SOFARPC 如何进行连接保持？ 在 IO 线程池中批量解包带来的性能提升有哪些？\n嘉宾 蚂蚁金服 SOFA 团队 碧远\n","date":1550744400,"description":"本次为上半场，2 月 21 日晚 7 点，线上直播。","dir":"activities/sofa-channel-2/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3140990819c0601c041bf5091405220b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-2/","publishdate":"2019-02-21T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-2/","summary":"概要 活动主题：SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 活动时间：2 月 21 日周四晚 7 点 活动形式：线上直播 直播视","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点","type":"activities","url":"/sofastack.tech/activities/sofa-channel-2/","wordcount":468},{"author":"卫恒","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n本文为《剖析 | SOFATracer 框架》第一篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\n 0、前言 在单体应用时代，我们不需要花费时间去关心调用链路这个东西。但是链路跟踪不仅仅是在分布式场景下才会有，即使是单体应用，同样也会存在调用链路。例如，我们把应用中的每个服务接口作为一个链路节点，那么从请求进来到返回响应，把这个过程中多历经的所有的方法接口串联起来，就能组成一条完整的链路，如下图所示：\n对于单体应用而言，如果访问一个资源没有成功，那么我们可以很快的锁定是哪一台机器，然后通过查询这台机器上的日志就能定位问题。\n但是在微服务体系架构下，这种方式会显得非常无力。对于一个稍具规模的应用来说，一次请求可能会跨越相当多的服务节点，在这种情况下，如果一个请求没有得到成功的响应，就不能确定到底是哪个节点出了问题。\n因此在面对这种复杂的大规模分布式集群来实现的服务体系来说，就需要一些可以帮助理解各个应用的线上调用行为、并可以分析远程调用的组件。\n基于上述背景，蚂蚁金服开源了基于 OpenTracing 规范实现的 SOFATracer 分布式链路跟踪组件，为实施大规模服务化体系架构场景下提供了链路跟踪的解决方案。\n在介绍 SOFATracer 之前，先来了解一下 Opentracing 规范。\n1、Opentracing 简介 首先来解释下 OpenTracing 是什么OpenTracing 致力于为分布式跟踪创建更标准化的API和工具，它由完整的API规范、实现该规范的框架、库以及项目文档组成。\nOpenTracing 提供了一套平台无关、厂商无关的 API，这样不同的组织或者开发人员就能够更加方便的添加或更换追踪系统的实现。 OpenTracing API 中的一些概念和术语，在不同的语言环境下都是共享的。\n1.1、数据模型 Opentracing 规范中，一条 trace 链路是由多个与之关联的 span 组成，一条链路整体可以看做是一张有向无环图，各个span之间的边缘关系被称之为“References”。下面是官方提供的示例：\n如果已时间轴维度来看的话，也可以表现为下面的形式(官方示例)：\n root span : 当前链路中的第一个 span ChildOf 和 FollowFrom 是目前被定义的两种 References 类型 ChildOf : 父级 span某种程度上取决于子span （子span的结果可能会对父span产生影响） FollowFrom : 父 Span不以任何方式依赖子 Span 但是为了简化 span 之间的这种依赖关系，在具体实现时通常会将具有嵌套关系的作为 ChildOf，平行执行的作为FollowFrom，比如：\na、ChildOf 示例\n在 methodA 中调用了 method B :\nmethodA(){ // spanA start methodB(); } // spanA finish methodB(){ // spanB start } // spanB finish 产生的 span在时间维度上展现的视角如下：\n这种关系一般会 表示为 SpanB ChildOf SpanA 。\nb、FollowFrom 示例\nmethod 方法中，methodA执行之后 methodB 执行 :\nmethod(){ methodA(); methodB(); } 产生的 span在时间维度上展现的视角如下：\n这种关系一般会 表示为 SpanB FollowFrom SpanA 。\n1.2、API Opentracing API 是对分布式链路中涉及到的一些列操作的高度抽象集合。Opentracing 中将所有核心的组件都声明为接口，例如 Tracer、Span、SpanContext、Format（高版本中还包括 Scope 和 ScopeManager）等。SOFATracer 使用的版本是 0.22.0 ，主要是对 Tracer、Span、SpanContext 三个概念模型的实现。下面就针对这三个组件结合 SOFATracer 来分析。\n1.3、SOFATracer 标准实现 下图为 SOFATracer 中对于这三个核心接口实现的类图结构：\n 由于篇幅原因，下面的介绍过程中一些点不会展开说明，有兴趣的同学可以自行官网查看完整的 OpenTracing-api 规范 （https://opentracing.io/specification/）。\n a、Tracer \u0026amp;amp; SofaTracer\nTracer 是一个简单、广义的接口，它的作用就是构建 span 和传输 span 。核心接口列表如下：\n 接口 描述 SpanBuilder buildSpan(String operationName) 根据指定的operationName构建一个新的span void inject(SpanContext spanContext, Format format, C carrier); 将 spanContext 以 format 的格式注入到 carrier 中 SpanContext extract(Format format, C carrier); 以 format 的格式从carrier中解析出 SpanContext SofaTracer 实现了 Tracer 接口，并扩展了采样、数据上报等能力。\nb、Span \u0026amp;amp; SofaTracerSpan\nSpan 是一个跨度单元，在实际的应用过程中，Span 就是一个完整的数据包，其包含的就是当前节点所需要上报的数据。核心接口列表如下：\n 接口 描述 SpanContext context() 从 span 中获取 SpanContext void finish()/void finish(long finishMicros) 结束一个 span void close() 关闭 span Span setTag(String key, value) 设置 tags Span log(long timestampMicroseconds, String event) 设置 log 事件 Span setOperationName(String operationName) 设 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第一篇。","dir":"blog/sofa-tracer-overview/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ff58d686746c53b81af210eaf17bb154","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-overview/","publishdate":"2019-02-21T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-overview/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-overview/","wordcount":4138},{"author":"卫恒","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第二篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n 0、前言 在《蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析》一文中已经对 SOFATracer 进行了概要性的介绍。从对 SOFATracer 的定义可以了解到，SOFATracer 作为一个分布式系统调用跟踪的组件，是通过统一的 TraceId 将调用链路中的各种网络调用情况以数据上报的方式记录下来，以达到透视化网络调用的目的。\n本篇将针对SOFATracer的数据上报方式进行详细分析，以帮助大家更好的理解 SOFATracer 在数据上报方面的扩展。\n1、Reporter 整体模型 本节将对 SOFATracer 的 Report 模型进行整体介绍，主要包括两个部分：\n Reporter 的接口设计及实现； 数据上报流程。 1.1、Reporter 的接口设计及实现 数据上报是 SofaTracer 基于 OpenTracing Tracer 接口扩展实现出来的功能；Reporter 实例作为 SofaTracer 的属性存在，在构造 SofaTracer 实例时，会初始化 Reporter 实例。\n1.1.1、Reporter 接口设计 Reporter 接口是 SOFATracer 中对于数据上报的顶层抽象，核心接口方法定义如下：\n//获取 Reporter 实例类型 String getReporterType(); //输出 span void report(SofaTracerSpan span); //关闭输出 span 的能力 void close(); Reporter 接口的设计中除了核心的上报功能外，还提供了获取 Reporter 类型的能力，这个是因为 SOFATracer 目前提供的埋点机制方案需要依赖这个实现。\n1.1.2、Reporter 接口实现 Reporter 的类体系结构如下：\nReporter 的实现类有两个，SofaTracerCompositeDigestReporterImpl 和 DiskReporterImpl ：\n SofaTracerCompositeDigestReporterImpl：组合摘要日志上报实现，上报时会遍历当前 SofaTracerCompositeDigestReporterImpl 中所有的 Reporter ，逐一执行 report 操作；可供外部用户扩展使用。 DiskReporterImpl：数据落磁盘的核心实现类，也是目前 SOFATracer 中默认使用的上报器。 1.2、数据上报流程分析 数据上报实际都是由不同的链路组件发起，关于插件扩展机制及埋点方式不是本篇范畴，就不展开了。这里直接来看数据上报的入口。\n在 Opentracing 规范中提到，Span#finish 方法是 span 生命周期的最后一个执行方法，也就意味着一个 span 跨度即将结束。那么当一个 span 即将结束时，也是当前 span 具有最完整状态的时候。所以在 SOFATracer 中，数据上报的入口就是 Span#finish 方法，这里贴一小段代码：\n//SofaTracerSpan#finish @Override public void finish(long endTime) { this.setEndTime(endTime); //关键记录:report span this.sofaTracer.reportSpan(this); SpanExtensionFactory.logStoppedSpan(this); } 在 finish 方法中，通过 SofaTracer#reportSpan 将当前 span 进行了上报处理。以这个为入口，整个数据上报的调用链路如下图所示：\n整个上报调用流程其实并不是很难，这里留两个问题：\n 如何构造 clientRportor 和 serverReporter 的，依据是什么？ 摘要日志和统计日志是怎么落盘的？ 第一个问题会在插件埋点解析篇中给出答案；第二个问题下面来看。\n2、日志落盘 前面已经提到，SOFATracer 本身提供了两种上报模式，一种是落到磁盘，另外一种是上报到zipkin。在实现细节上，SOFATracer 没有将这两种策略分开以提供独立的功能支持，而是将两种上报方式组合在了一起，然后再通过配置参数来控制是否进行具体的上报逻辑，具体参考下图：\n本节将来剖析下日志落盘的实现细节。日志落盘又分为摘要日志落盘 和 统计日志落盘；摘要日志是每一次调用均会落地磁盘的日志；统计日志是每隔一定时间间隔进行统计输出的日志。\n2.1、摘要日志落盘 摘要日志落盘是基于 Disruptor 高性能无锁循环队列实现的。SOFATracer 中，AsyncCommonDigestAppenderManager 类对 disruptor 进行了封装，用于处理外部组件的 Tracer 摘要日志打印。\n 关于 Disruptor 的原理及其自身的事件模型此处不展开分析，有兴趣的同学可以自行查阅相关资料。这里直接看下 SOFATracer 中是如何使用 Disruptor 的。\n 2.1.1、消息事件模型 SOFATracer 使用了两种不同的事件模型，一种是 SOFATracer 内部使用的 StringEvent，一种是外部扩展使用的SofaTacerSpanEvent。详见：SofaTracerSpanEvent \u0026amp;amp; StringEvent 。\n2.1.2、Consumer 消费者 Consumer 是 AsyncCommonDigestAppenderManager 的内部类；实现了 EventHandler 接口，这个 Consumer 作为消费者存在，监听事件，然后通过 TraceAppender 将 span 数据 flush 到磁盘。详见：AsyncCommonDigestAppenderManager\n2.1.3、Disruptor 的初始化 Disruptor 的构建：在 AsyncCommonDigestAppenderManager 的构造函数中完成的。 //构建disruptor，使用的是 ProducerType.MULTI //等待策略是 BlockingWaitStrategy，考虑到的是CPU的 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第二篇。","dir":"blog/sofa-tracer-response-mechanism/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"350b5d9eacee1bc4b3b604236b247a3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-response-mechanism/","publishdate":"2019-02-21T10:20:00Z","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-tracer-response-mechanism/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-response-mechanism/","wordcount":5014},{"author":"米麒麟","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第四篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\nSOFATracer： https://github.com/sofastack/sofa-tracer\n 前言 由于分布式链路追踪涉及到调用的每个环节，而每个环节都会产生大量的数据，为了存储这种数据，可能需要大量的成本，另外在实际的生产过程中并非所有数据都是值得关注的，基于这些原因，SOFATracer 提供链路数据采样功能特性，一方面可以节约 I/O 磁盘空间，另一方面需要把无关数据直接过滤筛选。目前 SOFATracer 内置两种采样策略，一种是基于固定比率的采样，另一种是基于用户扩展实现的自定义采样。自定义采样模式将 SofaTracerSpan 实例作为采样计算的条件，用户可以基于此实现自行扩展自定义的采样规则。\n本篇文章主要介绍 SOFATracer 数据采样策略原理，通过剖析源码实现详细讲述采样规则算法。\nDapper 论文中的采样模型与策略 跟踪采样模型 每个请求都会利用到大量服务器高吞吐量的线上服务，这是对有效跟踪最主要的需求之一。这种情况需要生成大量的跟踪数据，并且他们对性能的影响是最敏感的。延迟和吞吐量带来的损失在把采样率调整到小于1/16之后就能全部在实验误差范围内。\n在实践中，我们发现即便采样率调整到 1\u0026amp;frasl;1024 仍然是有足够量的跟踪数据用来跟踪大量的服务。保持链路跟踪系统的性能损耗基线在一个非常低的水平是很重要的，因为它为那些应用提供了一个宽松的环境使用完整的 Annotation API 而无惧性能损失。使用较低的采样率还有额外好处，可以让持久化到硬盘中的跟踪数据在垃圾回收机制处理之前保留更长时间，这样为链路跟踪系统的收集组件提供更多灵活性。\n分布式链路跟踪系统中任何给定进程的消耗和每个进程单位时间的跟踪采样率成正比。然而，在较低的采样率和较低的传输负载下可能会导致错过重要事件，而想用较高的采样率就需要能接受的相应的性能损耗。我们在部署可变采样的过程中，参数化配置采样率时，不是使用一个统一的采样方案，而是使用一个采样期望率来标识单位时间内采样的追踪。这样一来，低流量低负载会自动提高采样率，而在高流量高负载的情况下会降低采样率，使损耗一直保持在控制之内。实际使用的采样率会随着跟踪本身记录下来，这有利于从跟踪数据里准确分析排查。\n跟踪采样策略 要真正做到应用级别的透明，我们需要把核心跟踪代码做的很轻巧，然后把它植入到那些无所不在的公共组件中，比如线程调用、控制流以及 RPC 库。使用自适应的采样率可以使链路跟踪系统变得可伸缩，并且降低性能损耗。链路跟踪系统的实现要求性能低损耗，尤其在生产环境中不能影响到核心业务的性能，也不可能每次请求都跟踪，所以要进行采样，每个应用和服务可以自己设置采样率。采样率应该是在每个应用自己的配置里设置的，这样每个应用可以动态调整，特别是应用刚上线时可以适当调高采样率。一般在系统峰值流量很大的情况下，只需要采样其中很小一部分请求，例如 1\u0026amp;frasl;1000 的采样率，即分布式跟踪系统只会在 1000 次请求中采样其中的某一次。\n在 Dapper 论文中强调了数据采样的重要性，如果将每条埋点数据都刷新到磁盘上会增大链路追踪框架对原有业务性能的影响。如果采样率太低，可能会导致一些重要数据的丢失。 论文中提到如果在高并发情况下 1\u0026amp;frasl;1024 的采样率是足够的，也不必担心重要事件数据的丢失。因为在高并发环境下，一个异常数据出现一次，那么就会出现1000次。 然而在并发量不是很多的系统，并且对数据极为敏感时需要让业务开发人员手动设置采样率。\n对于高吞吐量服务，积极采样并不妨碍最重要的分析。如果一个显著的操作在系统中出现一次，他就会出现上千次。低吞吐量服务可以负担得起跟踪每一个请求。这是促使我们下决心使用自适应采样率的原因。为了维持物质资源的需求和渐增的吞吐要求之间的灵活性，我们在收集系统自身上增加了额外的采样率支持。\n如果整个跟踪过程和收集系统只使用一个采样率参数确实会简单一些，但是这就不能应对快速调整在所有部署节点上的运行期采样率配置的这个要求。我们选择了运行期采样率，这样就可以优雅的去掉我们无法写入到仓库中的多余数据。我们还可以通过调节收集系统中的二级采样率系数来调整这个运行期采样率。Dapper 的管道维护变得更容易，因为我们可以通过修改二级采样率的配置，直接增加或减少全局覆盖率和写入速度。\nSOFATracer 的采样源码剖析 SOFATracer 提供链路数据采样功能特性，支持两种采样策略：基于固定采样率的采样模式和基于用户扩展实现的自定义采样模式。\n采样接口模型 SOFATracer 提供定义链路追踪数据采样模式接口 com.alipay.common.tracer.core.samplers.Sampler，此接口 sample 方法通过 SofaTracerSpan 实例参数作为采样计算基础条件决定链路是否采样，实现丰富的数据采样规则。SOFATracer 基于 com.alipay.common.tracer.core.samplers.SamplerFactory 生成的采样器执行链路数据采样基本流程：\n 构建链路追踪器，通过采样器工厂 SamplerFactory 根据自定义采样规则实现类全限定名配置生成指定策略采样器 Sampler，其中基于用户扩展实现的采样模式优先级高，默认采样策略为基于固定采样率的采样计算规则； Reporter 数据上报 reportSpan 或者链路跨度 SofaTracerSpan 启动调用采样器 sample 方法检查链路是否需要采样，获取采样状态 SamplingStatus 是否采样标识 isSampled。 采样器的初始化 上面分析到，采样策略实例是通过 SamplerFactory 来创建的，SamplerFactory 中提供了一个 getSampler 方法用于获取采样器： 从代码片段来看，用户自定义的采样策略将会优先被加载，如果在配置文件中没有找到自定义的 ruleClassName ，则构建默认的基于固定采样率的采样器。SamplerProperties 是采样相关的配置属性，默认提供的基于固定比率的采样率是 100%，即默认情况下，所有的 Span 数据都会被记录到日志文件中。关于具体配置，在下文案例中会有详细介绍。\n采样计算 采样是对于整条链路来说的，也就是说从 RootSpan 被创建开始， …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第四篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-tracer-sampling-tracking-deep-dive/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"552e5d7feb431d3ff658a0194ead7b8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","publishdate":"2019-02-21T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 采样策略和源码剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","wordcount":4224},{"author":"J. Queue","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第三篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。 SOFATracer：https://github.com/sofastack/sofa-tracer\n SOFATracer 是一个用于分布式系统调用跟踪的组件，其核心作用就是能够在分布式场景下将请求经过的各个的链路环节的相关数据记录下来，通过这些数据将各个调用链路相关的组件串联起来。\n在日常的开发中，我们除了跟踪链路外，可能还会遇到一些场景：\n例如在线压测，我们在已有的系统中，模拟一些请求（压测流量）对我们的系统进行压力测试，那么在整个链路中我们是如何让所有的系统都识别出当前的请求是压测流量而不是正式流量的呢？压测流量的标记又是如何在整个链路传递的呢？\n又例如我们已经有了链路数据分析能力，能够快速定位到某个请求是在 A 系统里出的问题，那么我们怎么从 A 系统的业务日志里找到当前请求对应的业务日志呢？\n带着这些问题，让我们先来看看 SOFATracer 的链路透传以及支持 SLF4J MDC 扩展能力。\nSOFATracer 链路透传原理 SOFATracer 的链路透传具体包括两个点：\n 跨进程的透传，即如何将链路数据从一个进程传递到下游进程中 线程中的透传 当前请求跨进程调用结束之后，当前如何恢复 tracer 上下文信息 如何实现跨线程的透传，如在当前线程中起一个异步线程的场景 跨进程链路透传原理 跨进程透传就是将上游系统的链路数据透传到下游系统中，以便于提取出全局的链路标记，如 TracerId 、采样标记等，来实现将服务串联起来并且保持传输过程中某些属性的一致性。SOFATracer 基于 Opentracing 规范实现，因此在链路透传部分，也是基于此规范；下面就先从 Opentracing 规范中的透传开始说起。\nOpentracing 中的定义 在 OT 原文有这么一段描述 传送门\n Programmers adding tracing support across process boundaries must understand the Tracer.Inject(...)and Tracer.Extract(...) capabilities of the OpenTracing specification. They are conceptually powerful, allowing the programmer to write correct_general cross-process propagation code without being bound to a particular OpenTracing implementation; that said, with great power comes great opportunity for confusion.\n 大概意思就是：如果开发者要给应用添加跨进程的追踪能力, 首先要理解 OpenTracing 规范中的 Tracer.Inject(...)和 Tracer.Extract(…)的功能。它们在概念抽象上非常强大，而且允许开发者编写正确的、通用的跨进程传输的代码，而不需要绑定到特定的 OpenTracing 实现上去。\n总的来说就是 Opentracing 的 Tracer 接口定义了跨进程的能力，但是就是没具体实现，不同的基于此规范实现的组件，需要遵循此规范来实现具体的透传逻辑，下面是 Tracer 接口定义的用于透传的两个方法：\n 接口 描述 void inject(SpanContext spanContext, Formatformat, C carrier); 把 spanContext 以指定的 format 的格式注入到 carrier 中 SpanContext extract(Format format, C carrier); 以指定的 format 的格式从 carrier 中解析出 SpanContext 进程透传实现分析 SOFATracer 的 Tracer 的实现类是 SofaTracer， UML 图如下：\n从图中可以看出 SofaTracer 除了有跨进程传输的能力，还扩展了数据上报的能力( Reporter )和采样能力( Sampler )。数据上报能力可以参考《SOFATracer 数据上报机制和源码分析|剖析》这篇文章；采样将在下一篇文章中进行剖析。\n跨进程透传的就是 SpanContext 的内容， carrier 为传输的载体， SpanContext 的实现类为 SofaTracerSpanContext， UML 图：\n跨进程透传处理流程 SOFATracer 中跨进程传输的总体流程如下图所示：\n透传原理的实质就是：调用方编码将指定内容传输到被调方， 被调方解码获取内容的过程。\n跨进程透传的方式有很多， 在这里以客户端向服务端发起 HTTP 请求的方式来演示跨进程传输， fork 代码， 打开 sample/tracer-sample-with-httpclient 示例工程运行 HttpClientDemoApplication ，打开 logs/tracelog/spring-mvc-stat.log 即可看到链路日志， 运行结果 ：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-01-07 19:42:50.134\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:1563,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-01-07 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第三篇。","dir":"blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"82a08996dd671b01595748aa2d2fa748","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","publishdate":"2019-02-21T10:20:00Z","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 链路透传原理与SLF4J MDC 的扩展能力剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","wordcount":6294},{"author":"卫恒","categories":"SOFABoot","content":" SOFABoot 是基于 Spring Boot 的一套研发框架。 在完全兼容 Spring Boot 的基础上，SOFABoot 还提供了启动期监控检查，上下文隔离，模块化开发，类隔离，日志空间隔离等等能力 SOFABoot 地址：https://github.com/alipay/sofa-boot 本文工程案例：https://github.com/glmapper/glmapper-sofa-extension\n 春节小长假还没感觉就过去了，对于“热爱工作”的我，也早早的回到了工作岗位；感受下假期中的我和上班时的我。\n 后面拿枪的就是\u0026amp;rdquo;逼着\u0026amp;rdquo;我写文章的五花肉，上次 SOFATracer 采样用的是刀，这次用了枪！\n 模块化与扩展点 言归正传，节前 SOFABoot 发布了 2.6.x 系列版本，新特性也是相当给力，这里简单罗列下新特性：\n 支持扩展和扩展点 在刷新上下文期间支持 spring bean 的并行初始化 支持使用注解方式发布 JVM 服务 之前的文章中有 @玄北 写过的模块化的文章( 传送门 : 剖析 | 详谈 SOFABoot 模块化原理 \u0026amp;amp; 基于 SOFABoot 进行模块化开发 )，这两篇文章中介绍了模块化的几种实现方案（PS：当然主要还是为了宣传一下 SOFABoot 提供的基于 Spring 上下文隔离的模块化能力）。SOFABoot 的模块隔离方案是为了解决传统的模块化方案模块化不彻底的问题，从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化能力，每个 SOFABoot 模块使用独立的 Spring 上下文，每个模块自包含，模块与模块之间通过 JVM Service 进行通信，从而避免模块间的紧耦合。\n在 Spring 上下文隔离的情况下，各个上下文之间的 bean 是互不可见；SOFABoot 中通过发布 JVM 服务的方式使得不同模块 bean 之间的访问得以实现。但是同时又带来了另外一个问题，如果一个模块以独立 jar 的方式对外提供 api ，那么对于其他依赖此模块的模块来说，就无法去改变这个模块中的 bean 实例行为。\n在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项目，并在上面扩展，与 Spring 融合，提供了扩展点的能力。\n本篇将针对 SOFABoot 2.6.x 版本中提供的扩展点进行简单尝试，结合官方文档提供的示例，一步一步实现我们自定义的一个扩展点功能（本文过于简单，可能会引起极度舒适，请备好被子和热水袋）。\n案例背景 这里先抛出一个例子，现在有一个三方 jar ，它定义了获取数据源接口的顶层抽象；不同的业务方如果依赖这个 jar，则需要自己提供一个数据源的实现，当然其本身提供了默认实现（假设是 mysql）。基于此我们大概能够想到的方式就是基于 SPI 来提供这种扩展能力，但是对于在 Spring 上下文隔离的情况下，业务方的 Spring 上下文是无法与引入 jar 的上下文共享 bean 的，这样自然也就无法实现对原有数据源实现的扩展。\n那么这里我们就可以选择使用 SOFABoot 扩展点来实现，这里有两个比较重要的概念，也是扩展点区别于 SPI 的主要特性：\n 可以在基于 Spring 上下文隔离的情况下实现扩展 扩展的是 Spring Bean  下面基于这两个点，来完成自定义扩展点的一个案例。在实现上述案例之前我们需要先构建一个基于 Spring 上下文隔离的模块化工程，然后再简单介绍下扩展点的基本使用方式。\n构建模块化工程 SOFABoot 开源版本中并没有给出扩展点相关的案例工程，只是在测试用例中进行了详细的测试，有兴趣的同学可以看下相关测试用例代码。实际上测试用例中也没有涉及到在模块化的场景下使用扩展点，测试用例都是基于同一个Spring 上下文来完成的。本篇文章将先搭建一个简单的模块化工程，然后基于此工程来实现扩展点的能力。\n本工程主要包括 4 个模块：\n glmapper-sofa-facade // JVM 服务发布与引用的 API 包 glmapper-sofa-provider // Annotation 方式发布 JVM 服务 glmapper-sofa-consumer // Annotation 方式引用 JVM 服务 glmapper-sofa-web // 启动包含 SOFABoot 模块的 SOFA Boot 应用 官方文档及案例 中给的比较复杂，包含了多种使用服务发布和引用的方式，这里我使用了最新提供的基于注解的方式来实现；获取本文工程案例。\n扩展点基本使用 在 SOFABoot 中使用扩展点能力，需要以下三个步骤：\n 定义提供扩展能力的 bean 定义扩展点 定义扩展并使用 这三步中前两步都是由服务提供方来完成，最后一步由具体的业务使用方式来定义。\n定义提供扩展能力的 bean 本案例工程中，是将 glmapper-sofa-provider 作为服务提供方，因此也在此模块下定义一个具有扩展能力的 bean 。\n定义这个接口的实现：\n在模块的 Spring 配置文件 resources/META-INF/service-provider.xml 中，我们把这个 bean 给配置起来：\n定义扩展点 在上面的 bean 中有一个字段 word ，在实际中，我们希望这个字段能够被其他的模块自定义进行覆盖，这里我们将其以扩展点的形式暴露出来。这里先定义一个类去描述这个扩展点：\n然后在模块的 Spring 配置文件 resources/META-INF/service-provider.xml 中定义扩展点：\n name：为扩展点的名字 ref：为扩展点所作用在的 bean object：为扩展点的贡献点具体的描述，这个描述是通过 XMap 的方式来进行的（XMap 的作用是将 Java 对象和 XML 文件进行映射，这里建议通过在网上搜索下 XMap 的文档来了解 XMap） 至此服务提供端已经暴露出了扩展点，那么在服务使用端，也就是需要扩展这个 bean 的使用方就可以扩展这个bean 了。\n定义扩展 上述已经将扩展点定义好了，此时我们就可以对这个 bean 进行扩展了。扩展是具体业务使用方来做的事，在本案例中，glmapper-sofa-web 模块作为使用服务使用方，因此在 resources/META-INF/spring/web-home.xml 下进行扩展定义：\n bean：为扩展所作用在的 bean point：为扩展点的名字 content 里面的内容为扩展的定义，会通过 XMap 将内容解析为：扩展点的贡献点具体的描述对象，在这里即为 com.glmapper.bridge.extension.ExtensionDescriptor 对象 需要注意一点，glmapper-sofa-web 模块不是一个 SOFABoot 模块，这里留坑。\n 编写一个 TestController 类，这里最先 …","date":1550127600,"description":"本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。","dir":"blog/sofa-boot-extension-practice/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4f05313f7adf5401f3b5f499b43bb928","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-extension-practice/","publishdate":"2019-02-14T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-boot-extension-practice/","summary":"SOFABoot 是基于 Spring Boot 的一套研发框架。 在完全兼容 Spring Boot 的基础上，SOFABoot 还提供了启动期监控检查，上下文隔离，模块化开发，类隔离，日志空间隔离等等","tags":["SOFABoot"],"title":"SOFABoot 扩展点初体验 | SOFALab 实践系列","type":"blog","url":"/sofastack.tech/blog/sofa-boot-extension-practice/","wordcount":3773},{"author":"余淮","categories":"SOFAStack","content":" SOFA:Channel/，有趣实用的分布式架构频道。 SOFA:Channel/ 作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）。\n 大家晚上好，今天是 SOFAChannel 第一次线上直播，感谢大家的收看。\n先自我介绍下，我是来自蚂蚁金服中间件的章耿，花名余淮，目前在负责应用框架与 SOFAStack 开源相关的工作。\n今天给大家的分享主要分为三部分，第一部分是蚂蚁金服服务化演进的简介，第二部分是SOFAStack开源的情况。这两部分之前的分享也提到过，我们讲快一点，第三部分会详细介绍下 SOFARPC 的一些设计和实现细节。\n分享过程中如果大家对技术点比较感兴趣，或者其他组件感兴趣，也欢迎留言，后面的直播会安排更多的相关分享。\n蚂蚁服务化架构演进简介 大家现在对蚂蚁金服技术的概念，听得比较多的应该是“余额宝”、“相互宝”、“蚂蚁森林”、“刷脸支付”，“扫描工具地铁”、“双十一”等等这些耳耳熟能详的产品和场景。\n这些产品的背后，是蚂蚁金融科技的一套核心技术，包括 “三地五中心异地多活架构”，“金融级分布式架构”、“国产金融级分布式数据库 OceanBase”，“智能风控”，“区块链” 等诸多黑科技。\n当然，蚂蚁金服的微服务架构体系像其它传统的企业一样，也不是一开始就这么高大上，也是随着业务的发展慢慢演进而来的。下面给大家简单介绍下演进的过程。\n这个支付宝最早的架构示意图，可以看到当时支付宝只是电商后台的一个支付系统，是一个单体应用，里面简单的分了几个业务模块，连的也是一个数据库。但随着业务规模的不断扩展，单系统架构已经无法满足业务需求。\n所以支付宝就对大系统进行了拆分，将原来的一个单体应用内部的多个模块变成了多个独立的子系统，这算是典型的 SOA 化的架构。\n最开始系统之间是使用 F5 的硬件负载设备来做系统间的负载均衡，但由于 F5 设备存在单点的问题，所以后面就在中间引入一个注册中心的组件。服务提供者去注册中心注册服务，服务消费者去注册中心订阅服务列表，服务消费者通过软负载方式通过 RPC 框架直接调用服务提供者。这在现在看来是一种非常显而易见的服务化架构，但当时 07 年就采用这样的架构还是算比较超前的。\n支付宝在做系统拆分的同时，对数据库也按子系统进行了垂直拆分。数据库的拆分就会引入分布式事务的问题，蚂蚁金服中间件就提供了基于 TCC 思想的分布式事务组件 DTX。\n业务还是不断扩展，系统也越来越多，当系统节点到一定数量的时候，单个物理机房已经无法承受。另外考虑到同城容灾的问题，支付宝就在同城再扩建另外一个机房，通过专线部署为一个内部网络，然后将应用部署上去。\n同城多机房会引入一个跨机房远程访问的问题，相比同机房调用，这个延迟损耗一定是更高的。远程访问主要包括两种：RPC 调用和数据库访问。为了解决 RPC 跨机房调用的问题，支付宝的工程师选择的方案是在每个机房都部署注册中心，同机房优先调用本机房服务的方式，也就变成图中的部署模式。但是数据库跨机房访问的问题，在这个阶段并没有解决。\n另外还存在的一个问题就是调用链路混乱以及数据库连接瓶颈的调用。例如这个图里，我们对数据进行了分片，然后图中的 user0 的请求进来后，随机转到 S2，再随机转到B0，在随机到C1，最终跟进数据分配落到了数据库 D0。可以看到这里的调用链路是随机的，而每一个核心层也需要跟所有的分库都建立长连接。\n为了解决上面的跨机房数据访问、数据库连接数瓶颈以及未来数据水平扩展的问题，蚂蚁的工程师们设计了一套单元化的架构，这是单元化的一个示意图。\n在没有单元化的时候，用户请求进入内部后，所有请求链路都是随机走的，例如图里的 S0 到 B1 到 C2 到 D0。首先蚂蚁的请求都是跟用户相关的，所以我们将数据按用户的维度进行水平分片，例如这张示意图我们将所有用户分为三组。然后我们将我们的应用也部署成三组独立的逻辑单元，每个逻辑单元的应用和数据都是独立的，相当于每个逻辑单元都处理1/3总量用户的数据。\n这个时候我们的三个不同终端的用户，不管是在PC端或者手机端或者扫二维码，当请求进入统一接入层的时候，接入层会按上面逻辑单元的分组规则，将用户请求转发到对应的逻辑单元，例如 user0 的请求转到 S0，后面的应用之间的调用、数据都只在逻辑单元 0 内。统一的 user1 只在逻辑单元 1，user2 也只到逻辑单元 2。\n我们把这种逻辑单元称之为 RegionZone。在实际的部署过程中，物理数据中心 IDC 和 逻辑单元的数量没有完全的对等关系。例如图中我们物理机房可以是两地三中心，而 RegionZone 则是分为五个。\n两地三中心是国家对金融机构的一个容灾指导方案，要求在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同时在异地（＞ 200KM ) 建立异地容灾中心。\n有了这套单元化的架构做指导思想，蚂蚁进行大规模的改造，包括应用改造、基础框架改造、数据中心的建设。\n机房建设完成后，同时蚂蚁金服将自己的用户分成了若干份，划了几个逻辑单元，分别部署进了不同的物理机房，同时完成大规模的数据迁移。\n从两地三中心到容灾能力更强大的三地五中心，我们只需要先进行第三个城市的机房建设，然后将部分 RegionZone 部署到第三个城市，最后再完成数据迁移和引流即可。\n每一个 RegionZone 在异地都有备份，当发生城市级的故障时，我们通过统一的管控中心将新的逻辑规则推送到统一接入层以及异地的备 RegionZone 时，就可以做到城市级的整体容灾切换。\n再后面基于单元化思想，蚂蚁工程师还建设了弹性 LDC 的能力，例如大型活动开始的时候，我们将动态的将大促相关应用调度到其它的临时机房（例如是云上的机房）去，然后将流量引入。例如图中实例将 10% 的流量引入了 ZoneX 中。等到活动结束，我们再将流量引回。\nSOFAStack 开源情况 从前面的服务化演进可以看到，蚂蚁的微服务架构面临的场景已经慢慢从简单的远程调用发展到要面临复杂的三地五中心异地多活场景，为了支持这些场景，蚂蚁中间件自研了一套中间件 SOFAStack。\nSOFAStack 中的 SOFA 其实是 Scalable Open Financial Architecture 的首字母缩写，它是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n这是我们内部的技术栈，可以看到微服务领域各个功能点我们都有对应的内部系统或者组件。包括有RPC框架、服务发现、动态配置、熔断限流，还有分布式事务，分库分表等一整套中间件。\n目前 SOFAStack 也在蚂蚁金融科技上进行了技术输出。我们对中间件产品进行了产品化，并在蚂蚁金融云上变成了云上的产品，并提供了诸多例如同城双活之类的解决方案。这个是商业的产品，大家有空可以看下。\n在去年的 4.19 号，SOFAStack 正式宣布开源，我们第一批主要开了SOFABoot …","date":1548680400,"description":"本文根据 SOFAChannel#1 直播分享整理，主题：从蚂蚁金服微服务实践谈起。","dir":"blog/sofa-channel-1-retrospect/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c7997723a3859feb5f4f8fa454b6e00e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-1-retrospect/","publishdate":"2019-01-28T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-1-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 SOFA:Channel/ 作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。欢迎加入直播","tags":["SOFAStack","SOFAChannel"],"title":"从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-1-retrospect/","wordcount":6269},{"author":"花肉","categories":"SOFAChannel","content":" 活动主题：SOFAChannel#1——从蚂蚁金服微服务实践谈起 活动时间：1 月 17 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 \u0026amp;lt;SOFA:Channel/\u0026amp;gt;，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#1 《从蚂蚁金服微服务实践谈起》\n时间：2019-01-17 地点：浙江省杭州市西湖区线上直播 19:00-20:00 《从蚂蚁金服微服务实践谈起》 章耿 花名余淮（蚂蚁金服高级技术专家。目前在蚂蚁金服中间件服务与框架组负责应用框架及 SOFAStack 相关的工作） 嘉宾 蚂蚁金服 SOFA 团队 余淮\n视频回顾地址 https://tech.antfin.com/community/live/148\n","date":1547720400,"description":"首次 SOFAChannel 线上直播，1 月 17 日晚 7 点等你。","dir":"activities/sofa-channel-1/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5c79d2fac126784ef412f107470b2924","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-1/","publishdate":"2019-01-17T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-1/","summary":"活动主题：SOFAChannel#1——从蚂蚁金服微服务实践谈起 活动时间：1 月 17 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 \u0026","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#1——从蚂蚁金服微服务实践谈起","type":"activities","url":"/sofastack.tech/activities/sofa-channel-1/","wordcount":323},{"author":"许文奇","categories":"SOFAStack","content":" 许文奇 蚂蚁金服高级技术专家，SOFAStack 商业化产品技术 Leader，多年分布式架构及中间件研发经验，负责过蚂蚁金服分布式架构在多家金融机构的咨询和落地 本文根据他在 2019 蚂蚁金服 ATEC（Ant Technology Exploration Conference）科技大会上海站的分享整理。\n 本次分享主要会从单体架构和微服务架构的对比开始，后面重点谈一下实施金融级分布式架构的常见三个问题。\n常用架构：单体式架构 目前很多金融机构的架构是典型的单体式架构，一般由反向代理服务器，数据库和应用组成，所有业务模块都打包在一个应用里面运行，一般为了高可用考虑，应用至少会部署两个节点。单体式架构在业务简单的时候有很多它自身的优点：\n 开发，测试简单 部署简单 扩容简单，只要给应用加机器就行 但同样，单体式架构也有很多缺点，尤其是业务规模变得复杂以后，缺点会非常突出：\n 编译慢，启动慢，代码冲突等各种问题，严重影响开发效率 性能扩展有局限性，一定规模后，单纯堆机器已经很难扩展性能了。 蚂蚁金服的架构：分布式架构 微服务架构是目前大家最关注的一种分布式架构。微服务架构除了在性能可扩展性上对比单体式架构有巨大优势，还有一个重要优势体现在复杂业务下的生产效率优势。\n只有在业务复杂度较低的时候，单体式架构的生产效率才能超过微服务架构，但随着业务复杂度上升，尤其过了临界点，单体架构下的生产效率是非常恐怖的急速下坠，而微服务架构生产效率有所下降，但下降趋势非常缓慢，且不会偏离原有生产效率太多，能很好的应对业务复杂性的增长。\n所以实施微服务架构最重要的一个意义是在业务复杂度较高的情况下提升生产效率，更快速的进行业务创新。\n实施金融级分布式架构最常见的三个挑战 基于微服务架构的巨大优势，很多金融机构、企业开始逐渐转型微服务架构，转型总是伴随着挑战，这里选了三个最常见的，最多用户关心的问题，聊聊蚂蚁金服的一些实践心得：\n 如何进行微服务架构拆分及治理？ 新的分布式架构如何兼容老系统？ 如何一步一步构建金融级容灾架构？ 1、微服务架构拆分及治理 微服务拆分模式可以从微服务架构的扩展立方开始讲起，分为X轴，Y轴，Z轴三类拆分。\nX轴代表横向扩展模式。主要通过部署多份应用，负载均衡的方式来扩展性能，这个单体架构也可以做。当然，在微服务架构下，横向扩展模式的实现方式有别于单体架构。\n微服务架构做服务负载均衡不需要通过F5或者LVS集群这样的硬件设备，只需要通过注册中心就可以实现，这样带来的好处是降低了成本，不需要购买大量的硬件设备了；提高了性能，业务干路上少了一个单点风险；降低了维护成本。\n当然支持横向扩展模式还需要应用是无状态的，这个是微服务架构的基本要求，任何涉及状态的数据都应该保存在数据库，缓存或者其他一些存储介质中。更高的要求的话，应用应该要满足著名的12要素的要求。\nY轴代表功能分解模式。我们提倡业务系统在开发的时候就应该按照模块化进行开发，满足高内聚，低耦合的架构要求。为了更好支持模块化开发，以SOFAStack中间件的SOFABoot框架为例，框架支持模块隔离能力，不同的模块使用不同的Spring上下文，这样不同的模块之间就不能直接引用了，如果需要调用别的模块的接口，那么需要走SOFABoot框架规定的特别声明才可以办到。这样极大的规范了模块化开发，使得这些系统将来在进行拆分的时候，成本非常的低。\n关于功能分解，服务拆分，虽然没有一个标准答案告诉我们就该怎么做，但其实也有一些基本指导原则和实践：\n 按照业务领域进行拆解，而不是组织。所有拆分必须按照业务领域模型进行合理划分，因为实体组织不一定能和业务领域完全对应，且组织一般粒度较大，不能作为拆分细粒度微服务的参考。 从数据核心模型拆分开始先拆，而后再往上进行服务拆分。这个主要是进行拆分的一个重要次序问题。一般梳理数据核心模型比较容易，比如很容易梳理出哪些表，哪些数据属于交易，哪些表，哪些数据属于账务，然后按照业务垂直进行拆分。有些业务归属不那么明确的可以按照数据亲和性进行拆分。然后数据核心模型拆分好以后，再往上按照功能模块，所对应的场景，进行服务拆分。 单一职责。这个是微服务架构的一条金科玉律，要求微服务架构必须遵守。一个很主要的原因是为了避免微服务架构重新掉进单体架构的老问题里面。原来单体架构最大的问题就是任何的改动，都要导致整个应用重新的编译打包部署，还包括全量回归测试。试想一个微服务里面有太多的功能、职责，如果任意一个业务模块有需求，需要改动，必然导致该微服务的应用重新编译，打包部署和全量回归测试，频繁变动成本很高，研发效率也会降低。 注意拆分粒度，避免一开始拆得过细，循序渐进。关于拆分粒度，这个也是一个没有标准答案的问题。总的一个原则就是适用最好。任何一家公司的业务都是独一无二的，不存在一模一样业务的两家公司，所以别人的拆分，可以借鉴，但往往很难照抄。所以推荐拆分的时候，一开始不要拆得过细，按照业务发展的规律，循序渐进。举个例子，比如说红包业务，原来可能只是营销系统的一个模块，但如果公司的业务在红包这块发展得足够复杂，是可以考虑拆为单独的微服务，这一切取决于业务发展。 注意服务分级和分层，避免循环依赖。这个要求服务拆分的时候，充分注意到哪些是核心服务，哪些是非核心服务，不能出现核心服务强依赖非核心服务的情况，更不能出现循环依赖的情况。 考虑团队结构。最后微服务拆出来，肯定是要有对应团队去维护的，所以整个拆分的粒度，拆分的逻辑也要考虑团队结构的情况。 Z 轴代表数据分区模式。一般在数据库遇到性能瓶颈的时候，需要进行数据拆分，一般分为垂直拆分和水平拆分。垂直拆分一般就是按照业务划分来进行，比如以前账务和交易放在一个数据库，现在数据库有瓶颈了，那么就可以拆成账务和交易两个数据库，缓解数据库的性能瓶颈。当然，如果按照垂直拆分完毕以后，还是不能满足性能要求，这个时候就需要进行水平拆分了。\n关于水平拆分，也有一些重要的实践原则。在做数据库水平拆分的时候，最好一次性考虑未来十年，甚至二十年的业务的要求，要避免今天做了一个拆5张表的决定，过了两年，发现不行，还要继续拆成10张表，甚至20张表的情况。\n重新分片是个非常复杂的工作，尤其是线上还不允许停机的情况。另外关于确定如何拆多少库，多少表，也有一些实践。一般拆的数据库数量等于未来业务的峰值（TPS）除以单数据库的容量（TPS）。这里并不代表要一步到位，拆那么多实际物理库，一开始可借助SOFAStack分库分表中间件虚拟成逻辑库，只需要少量物理库，等到访问量上来后，再扩容物理库。拆的表的数量等于单表时间业务量乘以存储时长除以单标容量上限。记住表的数量一定要一步拆到位，避免过一两年还要折腾。\n做了数据拆分后，就会遇到分布式事务的问题，需要解决分布式事务的问题，这个也是金融行业区分与别的行业的最大不同。SOFAStack分布式事务中间件目前支持TCC和FMT两种模式（这里主要讨论实践，对于TCC和FMT两种模式的原理，这里不再赘述，有兴趣的可以参考之前的文章）。TCC模式虽然编码复杂，业务有侵入，难度较高，但胜在性能好，所以像核心系统里面的分布式事务都是用该方案。当然，因为复杂，所以实现中有些地 …","date":1547535600,"description":"本次分享主要会从单体架构和微服务架构的对比开始，后面重点谈一下实施金融级分布式架构的常见三个问题。","dir":"blog/distributed-arch-in-the-enterprise/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e2f9f404c5e859e21c65fb3c2f2f0324","permalink":"https://sofastack.github.io/sofastack.tech/blog/distributed-arch-in-the-enterprise/","publishdate":"2019-01-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/distributed-arch-in-the-enterprise/","summary":"许文奇 蚂蚁金服高级技术专家，SOFAStack 商业化产品技术 Leader，多年分布式架构及中间件研发经验，负责过蚂蚁金服分布式架构在多家金融","tags":["SOFAStack"],"title":"企业实施分布式架构的挑战以及应对建议 | 上海 ATEC 科技大会实录","type":"blog","url":"/sofastack.tech/blog/distributed-arch-in-the-enterprise/","wordcount":5455},{"author":"崔秀龙","categories":"Service Mesh","content":" 崔秀龙，HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员。\n本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整理，完整的分享 PPT 获取方式见文章底部。\n本文内容收录在崔秀龙的新书：《深入浅出 Istio - Service Mesh 快速入门与实践》的第十章，该书将于近期由博文视点出版发行，敬请关注。\n Service Mesh 概念在 Linkerd 落地之后，让一直漂浮在空中的微服务治理方案有了一个明确的落地点，给微服务架构的具体实现指出了一个清晰的方向，围绕这一概念逐步开始形成新的技术生态，在业界造成不少震动。这种震动对于企业 IT 转型工作带来的影响，甚至比容器化的影响更加深远。对于承担企业 IT 转型工作的企业服务行业来说，也自然首当其冲感觉到新概念带来的压力。\n企业服务行业和互联网行业相比，业务形态、技术积累和人员结构等方面都大相径庭，举几个常见的差异：\n 开发、运维、基础设施所属 人员结构、水平和年龄 资源使用率差别 架构和平台一致性 负载能力 \u0026amp;hellip; 目前进行 Service Mesh 布道的主力还是互联网行业的旗手们，一味追求跟进互联网同行们的进度和做法，颇有邯郸学步的风险。\n本文中将会针对目前 Service Mesh 方面的一些普遍问题和关注热点发表一些个人意见。并尝试提供一种 Istio 的试用思路，给乙方同行们提供参考。\nIstio 的功能 无需赘述，多数用户都很清楚，Istio 使用和应用共享网络栈的方式，利用 Iptables 劫持应用的网络流量，从而在不修改业务源码的情况下，完成一系列的功能：\n 监控服务质量 控制服务间的访问路由 应对服务故障 在服务间通信之间进行加密 访问控制和频率限制 分布式跟踪和业务紧密相关，无法做到无侵入。\n 这其中最大的优势就是无侵入，这意味着给试用流程留下了全身而退的机会，如果没有回滚的能力，上述种种能力都是空中楼阁。\nIstio 的问题 API 稳定性可能是最严重的一个问题。目前最成熟的功能组别应该是流量控制，其版本号也仅是 v1alpha3，一般来说，alpha 阶段的产品，代表着不提供向后兼容的承诺，流量控制 API 在从 v1alpha2 升级为 v1alpha3 的过程中，API 几乎全部改写，使得很多早期用户的精力投入付诸东流。核心功能尚且如此，遑论相对比较边缘的 Mixer、Citadel 以及 Galley 组件的相关内容。 发布节奏和发布质量的问题也相当严重。Istio并不算长的历史中，出现了多次版本撤回、大版本严重延期、发布质量低下无法使用以及 Bug 反复等状况，这无疑会让每次升级尝试都充满了不确定性，会很大的影响生产过程的连续性。 Mixer 是一个问题焦点，其数据模型较为复杂，并且集中了所有应用的流量于一点，虽然其中加入了各种缓存等技术来降低延迟，但是其独特地位决定了 Mixer 始终处于一个高风险的位置。同时其 API 结构稍显混乱，重构风险较大。 Pilot的性能方面也经常为人诟病，虽然经过几次升级，但是即使是 1.0 之后，还是出现了两次 Pilot 在集群中服务/Pod 过多的情况下会超量消耗资源的问题。 安全、物理机和虚拟机的支持以及网格边缘通信这三组功能，目前用户较少，质量尚不明确。 最后就是 Istio 的 Sidecar 注入模式，这种模式一定会增加服务间调用的网络延迟，在目前阶段这是一个痼疾，Sidecar 的固定延迟和 Mixer 的不确定行为相结合，有可能会产生严重后果。 这里提出的只是被反复提及，或者经常出现在 Issue 列表中的问题，由发布问题来看，面临的风险可能远不止这些。\nIstio 试用工作的理由和规划 试用 Istio，首先应该确定，该技术的采用，是否能够在可控的风险和投入下，得到有效的产出。\n 微服务模式的推进，必须要有相应的管理能力，Service Mesh 目前看来，是一个确定有效的方案，如果不是 Istio，也会有其它替代产品出现。 目前看来，Istio 是 Service Mesh 的标志性产品，有一定可能性成为事实标准。 提供了众多开箱即用的丰富特性，能够迅速进入 Service mesh。 最后是无侵入的优势：如果试用失败，可以退回，控制损失范围。 Istio 的多数功能，在无需对程序进行修改（分布式跟踪除外）的情况下，能对应用提供如此之多的功能支持，无疑是非常有吸引力的。Istio 的功能集，完全可以说是服务网格技术的典范。一旦确认现有环境有可能支持 Istio 的运行，并且在合理的投入下能够获得有效益的产出，那么这个试用就是有价值的。\n结合 Istio 的现状，以及多数企业的运行状态，个人浅见，Istio 的应用在现阶段只能小范围试探性地进行，在进行过程中要严格定义试用范围，严控各个流程。 按照个人经验，笔者将试用过程分为如下 4 个阶段。\n 范围定义：选择进入试用的服务，确定受影响的范围，并根据 Istio 项目现 状决定预备使用的 Istio 相关功能。围绕这些需要，制定试用需求。 方案部署：根据范围定义的决策，制定和执行相关的部署工作。其中包含 Istio 自身的部署和业务服务、后备服务的部署工作。 测试验证：根据既有业务目标对部署结果进行测试。 切换演练：防御措施，用于在业务失败时切回到原有的稳定环境。 Istio 的试用步骤 确定功能范围 在 Istio 中包含了非常多的功能点，从原则上来说，各种功能都是有其实际作用的。然而，Istio 作为一个新产品，本身也有很多不足，我们在 10.1 节中也提到了这些不足。\nIstio 提供的众多功能对每个公司或者项目，都会有不同价值。我们在采用一个新系统时，首先要考虑的就是性价比问题，这里的“价”代表着 Istio 带来的风险、对业务应用的影响，还包括可能出现的服务停机等问题。\n可以根据性价比，做出一个优先级别列表。在制定了优先级列表之后，就可以根据这一列表，结合项目的实际需求，按照效果明显、功能稳定、部署成本低、少改造或者不改造的标准来进行选择，最终确定待测试的功能点。\n在选定功能点之后，应该遵循目前已有的 Istio 文档，对各个功能点进行单项测试和验证，以确保其有效性。并通过官方 GitHub 的 Issue 列表及讨论组内容，了解现有功能是否存在待解决的问题，以及相关的注意事项等。\n选择试用业务 在试用功能点确定之后，就要选择用于试用的业务应用了。Istio 作为一个相对底层的系统，其部署和调试过程必然会对业务产生一定的影响，在运行阶段又有 Sidecar 和各个组件造成的损耗，如下所述：\n 所有网格之间的通信都要经过 Sidecar 的中转，会造成大约 10 毫秒的延迟。 Pilot 对集群规模敏感，集群中的服务数量、Pod 数量都可能对 Pilot 造成较大影响，也会影响到 Istio 各种规则向 Pod 的传输过程。 所有流量都会经由 Mixer 处理，也有造成瓶颈的可能。 安全功能设置不当同样会造成服务中断。 如上所述还只是个概要，对业务来说，对这些风险都是必须正 …","date":1547103600,"description":"本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-meetup-5-istio-retrospect/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"88553acdb286a68c44cc9bf390855f26","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","publishdate":"2019-01-10T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","summary":"崔秀龙，HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员。 本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整","tags":["Service Mesh"],"title":"企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","wordcount":4050},{"author":"敖小剑","categories":"Serverless","content":" Knative 是Google 发起的 Serverless 项目，希望通过提供一套简单易用的 Serverless 开源方案，将 Serverless 标准化。 本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，PPT 获取地址：下载地址\n 前言 大家好，今天给大家来的演讲专题是“Knative：重新定义Serverless”, 我是来自蚂蚁金服中间件的敖小剑。\n这是我的个人资料，有兴趣的同学可以关注的我的个人技术博客网站 https://skyao.io\n这次演讲的内容将会有这些，首先给大家介绍一下 Knative 是什么，然后是 Knative 的主要组件，让大家对 Knative 有一个基本的了解。之后我会简单的对 Knative 做一些分析和探讨，以及介绍一下 Knative 后续的发展。希望本次的内容让大家能够对Knative有一个基本的认知。\n什么是 Knative？ Knative 是 Google 牵头发起的 Serverless 项目。\n这是Knative的项目定义，注意这句话里面几个关键字：Kubernetes，Serverless，Workload。\n这是最近几年 Google 做大型项目的常态：产品刚出来，阵营就已经很强大了，所谓先声夺人。\n是目前Knative项目的进展，可以看到这是一个非常新的项目，刚刚起步。\n 备注：这是截至2018-11-24演讲当天的情况，到2018年12月底，Knative已经发布了v0.2.2和v0.2.3两个bugfix版本。但也还只是 0.2 ……\n 我们来看一下，在Knative出来前， Serverless 领域已有的实现，包括云端提供的产品和各种开源项目。\n这幅图片摘自 The New Stack 的一个 Serverless 调查，我们忽略调查内容，仅仅看看这里列出来的 Serverless 产品的数量——感受是什么？好多Serverless项目，好多选择！\n那问题来了：到底该怎么选？\n这就是目前 Serverless 的问题：由于缺乏标准，市场呈现碎片化。不同厂商，不同项目，各不相同，因此无论怎么选择，都面临一个风险：供应商绑定！\n这段话来自 Knative 的官方介绍，Google 推出 Knative 的理由和动机。其中第一条和第二条针对的是当前 Serverless 市场碎片的现状。而第四条多云战略，则是针对供应商绑定的风险。\nGoogle 描述 Knative 的动机之一，是将云原生中三个领域的最佳实践结合起来。\n小结：\n当前 Serverless 市场产品众多导致碎片化严重，存在厂商绑定风险，而 Google 推出 Knative，希望能提供一套简单易用的 Serverless 方案，实现 Serverless 的标准化和规范化。\nKnative 的主要组件 第二部分，来介绍一下Knative的主要组件。\n前面提到，Google 推出 Knative ，试图将云原生中三个领域的最佳实践结合起来。反应到 Knative 产品中，就是这三大主要组件：Build，Serving，Eventing。\nKnative Build 组件，实现从代码到容器的目标。为什么不直接使用 dockfile 来完成这个事情？\nKnative Build 在实现时，是表现为 Kubernetes 的 CRD，通过 yaml 文件来定义构建过程。这里引入了很多概念如：Build，Builder，Step，Template，Source等。另外支持用 Service Account 做身份验证。\nKnative Serving 组件的职责是运行应用以对外提供服务，即提供服务、函数的运行时支撑。\n注意定义中的三个关键：\n Kubernetes-based：基于 k8s，也仅支持 k8s，好处是可以充分利用k8s平台的能力 scale-to-zero：serverless 最重要的卖点之一，当然要强调 request-driven compute：请求驱动的计算 值得注意的是，除了k8s之外，还有另外一个重要基础：istio！后面会详细聊这个。\nKnative Serving项目同样也提供了自己的中间件原语，以支持如图所示的几个重要特性。\nKnative中有大量的概念抽象，而在这之后的背景，说起来有些意思：Knative 觉得 kubernetes 和 istio 本身的概念非常多，多到难于理解和管理，因此 Knative 决定要自己提供更高一层的抽象。至于这个做法，会是釜底抽薪解决问题，还是雪上加霜让问题更麻烦……\nKnative的这些抽象都是基于 kubernetes 的 CRD 来实现，具体抽象概念有：Service、Route、Configuration 和 Revision。特别提醒的是，右边图中的 Service 是 Knative 中的 Service 概念，service.serving.knative.dev，而不是大家通常最熟悉的 k8s 的 service。\n对于 Knative Serving 组件，最重要的特性就是自动伸缩的能力。目前伸缩边界支持从0到无限，容许通过配置设置。\nKnative 目前是自己实现的 Autoscaler ，原来比较简单：Revision 对应的pod由 k8s deployment 管理，pod上的工作负载上报 metrics，汇总到 Autoscaler 分析判断做决策，在需要时修改 replicas 数量来实现自动伸缩（后面会再讲这块存在的问题）。\n当收缩到0，或者从0扩展到1时，情况会特别一些。Knative在这里提供了名为 Activator 的设计，如图所示：\n Istio Route 控制流量走向，正常情况下规则设置为将流量切到工作负载所在的pod 当没有流量，需要收缩到0时，规则修改为将流量切到 Activator ，如果一直没有流量，则什么都不发生。此时Autoscaler 通过 deployment 将 replicas 设置为0。 当新的流量到来时，流量被 Activator 接收，Activator 随即拉起 pod，在 pod 和工作负载准备好之后，再将流量转发过去 Knative Eventing 组件负责事件绑定和发送，同样提供多个抽象概念：Flow，Source，Bus，以帮助开发人员摆脱概念太多的负担（关于这一点，我保留意见）。\nBus 是对消息总线的抽象。\nSource 是事件数据源的抽象。\nKnative 在事件定义方面遵循了 Cloudevents 规范。\n小结：\n简单介绍了一下 Knative 中的三大组件，让大家对 Knative 的大体架构和功能有个基本的认知。这次就不再继续深入 Knative 的实现细节，以后有机会再展开。\nKnative分析和探讨 在第三部分，我们来分析探讨一下 Knative 的产品定位，顺便也聊一下为什么我们会看好 Knative。\n首先，最重要的一点是：Knative 不是一个 Serverless 实现，而是一个 Serviceless 平台。\n也就是说，Knative 不是在现有市场上的20 …","date":1546498800,"description":"本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，文中有 PPT 获取地址。","dir":"blog/serverless-knative-giac/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"21d3b124a0863acf6481463647b92095","permalink":"https://sofastack.github.io/sofastack.tech/blog/serverless-knative-giac/","publishdate":"2019-01-03T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/serverless-knative-giac/","summary":"Knative 是Google 发起的 Serverless 项目，希望通过提供一套简单易用的 Serverless 开源方案，将 Serverless 标准化。 本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，PPT 获取地址：下载","tags":["Serverless","Knative"],"title":"Knative：重新定义 Serverless | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/serverless-knative-giac/","wordcount":3746},{"author":"余淮","categories":"SOFAStack","content":" 章耿，花名余淮，蚂蚁金服高级技术专家。 2007 年毕业后一直从事服务化相关的工作，最早在国家电网做电子商务平台 SOA 化的工作，之后在京东负责京东的服务化框架 JSF，目前在蚂蚁金服中间件服务与框架组负责应用框架及 SOFAStack 相关的工作。\n本文根据余淮在 2018 开源中国年终盛典的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 本次分享主要分为三部分： 蚂蚁金服服务化架构演进 蚂蚁金服微服务体系 蚂蚁金服 SOFAStack 的开源情况 1、蚂蚁金服服务化架构演进 在开始讲架构演进之前，我们先来看一组数据。 这是历年来的双十一数据图，柱状是双十一的交易额，从最初到20亿到去年的1682亿，今年是2135亿。而这个橙色的折线则是支付宝双十一 0 点的交易峰值，去年是 26.5w笔每秒，今年更高。从这两组数据可以看出蚂蚁的业务每年都是在高速增长，那技术面临的压力更是在不断的增长。但是最近几年，峰值虽然越来越大，但是大家有个体感，就是大促的购物体验更好了，再也不像以前系统会被大促搞挂，系统反而越来越稳了。\n而支撑这些数字的背后，是蚂蚁金融科技的一些核心技术，我们可以看到有三地五中心多活架构，分布式数据库 OceanBase，金融级分布式架构 SOFAStack，还有更多的一些黑科技，例如 Zoloz 生物识别，蚂蚁区块链，第五代智能风控引擎。\n相信大家都听过一句话 “罗马不是一天建成的”。蚂蚁金服科技的技术也不是最早就设计成这样，和所有的大公司发展一样，目前这些技术架构也是随着业务发展、系统的壮大，一步一步演进而来的。\n下面给大家介绍下蚂蚁金服的演进。\n这个是支付宝最早的架构示意图，可以看到当时支付宝只是电商后台的一个支付系统，是一个单体应用，里面简单的分了几个业务模块，连的也是一个数据库。但随着业务规模的不断扩展，单系统架构已经无法满足业务需求。\n所以支付宝就对大系统进行了拆分，将原来的一个单体应用内部的多个模块变成了多个独立的子系统，这算是典型的 SOA 化的架构。最开始系统之间是使用 F5 的硬件负载设备来做系统间的负载均衡，但由于 F5 设备存在单点的问题，所以后面就在中间引入一个注册中心的组件。服务提供者去注册中心注册服务，服务消费者去注册中心订阅服务列表，服务消费者通过软负载方式通过 RPC 框架直接调用服务提供者。这在现在看来是一种非常显而易见的服务化架构，但当时 07 年就采用这样的架构还是算比较超前的。 支付宝在做系统拆分的同时，对数据库也按子系统进行了垂直拆分。数据库的拆分就会引入分布式事务的问题，蚂蚁金服中间件就提供了基于 TCC 思想的 分布式事务组件 DTX。\n业务还是不断扩展，系统也越来越多，当系统节点到一定数量的时候，单个物理机房已经无法承受。另外考虑到同城容灾的问题，支付宝就在同城再扩建另外一个机房，通过专线部署为一个内部网络，然后将应用部署上去。同城多机房会引入一个跨机房远程访问的问题，相比同机房调用，这个延迟损耗一定是更高的。远程访问主要包括两种：RPC 调用和数据库访问。为了解决 RPC 跨机房调用的问题，支付宝的工程师选择的方案是在每个机房都部署注册中心，同机房优先调用本机房服务的方式，也就变成图中的部署模式。但是数据库跨机房访问的问题，在这个阶段并没有解决。\n为了解决上面的跨机房数据访问、数据库连接数瓶颈以及未来数据水平扩展的问题，蚂蚁的工程师们设计了一套单元化的架构，这是单元化的一个示意图。在没有单元化的时候，用户请求进入内部后，所有请求链路都是随机走的，例如图里的 S0 到 B1 到 C2 到 D0。首先蚂蚁的请求都是跟用户相关的，所以我们将数据按用户的维度进行水平分片，例如这张示意图我们将所有用户分为三组。然后我们将我们的应用也部署成三组独立的逻辑单元，每个逻辑单元的应用和数据都是独立的，相当于每个逻辑单元都处理1/3总量用户的数据。\n这个时候我们的三个不同终端的用户，不管是在PC端或者手机端或者扫二维码，当请求进入统一接入层的时候，接入层会按上面逻辑单元的分组规则，将用户请求转发到对应的逻辑单元，例如 user0 的请求转到 S0，后面的应用之间的调用、数据都只在逻辑单元 0 内。统一的 user1 只在逻辑单元 1，user2 也只到逻辑单元 2。\n我们把这种逻辑单元称之为 RegionZone。在实际的部署过程中，物理数据中心 IDC 和 逻辑单元的数量没有完全的对等关系。例如图中我们物理机房可以是两地三中心，而 RegionZone 则是分为五个。\n两地三中心是国家对金融机构的一个容灾指导方案，要求在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同时在异地（＞ 200KM ) 建立异地容灾中心。\n有了这套单元化的架构做指导思想，蚂蚁进行大规模的改造，包括应用改造、基础框架改造、数据中心的建设。\n机房建设完成后，同时蚂蚁金服将自己的用户分成了若干份，划了几个逻辑单元，分别部署进了不同的物理机房，同时完成大规模的数据迁移。\n从两地三中心到容灾能力更强大的三地五中心，我们只需要先进行第三个城市的机房建设，然后将部分 RegionZone 部署到第三个城市，最后再完成数据迁移和引流即可。\n每一个 RegionZone 在异地都有备份，当发生城市级的故障时，我们通过统一的管控中心将新的逻辑规则推送到统一接入层以及异地的备 RegionZone 时，就可以做到城市级的整体容灾切换。\n再后面我们基于单元化的思想做了更多弹性调度等能力，这里就不展开了。\n2015 年 9 月蚂蚁金融云对外正式发布，在今年 9 月的云栖大会，蚂蚁金融云正式升级为蚂蚁金融科技，并宣布技术全面对外开放，其中就包括金融级分布式架构 SOFAStack，左上角就是网址，感兴趣的朋友可以看下：https://tech.antfin.com/sofa\n云上的 SOFAStack 继承了蚂蚁金服内部的能力，有三大特点，分别是开放（全栈开放、开源共建）、云原生（异地多活、无限扩展）、金融级（资金安全、无损容灾），下面是一些核心能力大家可以看下。这一切就使得蚂蚁金服的微服务体系不仅仅在蚂蚁内部玩得转，也需要适应云上例如云原生、多租户等更复杂的场景。\n2、蚂蚁微服务体系 讲到微服务，大家就会看到或者脑子就跳出各种各样的词，例如 RPC 框架、服务安全、路由寻址等等。 除了这些以外，其实还有更多的服务归属、服务测试、服务编排等更多概念。\n那蚂蚁内部围绕微服务体系，也建设了很多的组件和框架对应这些微服务的概念点。\n这是一张蚂蚁内部微服务体系的一张简图，只列了部分主要组件，这些组件都是自研的，部分已经开源。可以看到有配置中心 DRM、注册中心 SOFARegistry，应用开发框架 SOFABoot，应用里的 RPC 框架、分布式链路跟踪组件 Tracer、监控度量组件 Lookout 等微服务组件，应用旁边是我们的 SOFAMosn，也就是 ServiceMesh 里的数据平面 SideCar，会将 RPC 里的路由、限流、鉴权等一些能力集成到这个组件里， …","date":1545030000,"description":"本文根据余淮在 2018 开源中国年终盛典的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/sofastack-oschina-2018/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e636d50f3f49170801c38118bf711adc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-oschina-2018/","publishdate":"2018-12-17T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofastack-oschina-2018/","summary":"章耿，花名余淮，蚂蚁金服高级技术专家。 2007 年毕业后一直从事服务化相关的工作，最早在国家电网做电子商务平台 SOA 化的工作，之后在京东负责京东的服务化","tags":["微服务","开源","实践"],"title":"蚂蚁金服微服务实践- 2018 开源中国年终盛典分享实录","type":"blog","url":"/sofastack.tech/blog/sofastack-oschina-2018/","wordcount":6551},{"author":"颜洄、丞一","categories":"SOFABolt","content":" 1. 前言 为了让中间件开发者们将更多的精力投入到产品的功能特性上，而不是重复的写通信层框架，蚂蚁中间件团队设计并实现了SOFABolt。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。蚂蚁中间件的同学这些年在微服务和消息中间件上解决了很多网络通信的问题，积累了很多经验，并将这些经验、解决方案沉淀到了SOFABolt这个项目中，希望能让更多需要使用网络通信的团队、开发者受益。目前SOFABolt已经运行在蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n2. 主要特性 SOFABolt核心功能包括三大块：\n 网络通信能力 协议框架 私有协议实现 网络通信能力 网络通信能力（remoting-core）可以理解为Netty的最佳实践，并额外进行了一些优化工作，包含：\n 基于Netty的高效的网络IO于线程模型的应用 链接管理（无锁建连、定时断连、自动重连） 通信模型（oneway、sync、callback、future） 超时控制 批量解包和批量提交处理 心跳于IDLE机制 协议框架 协议框架（protocol-skeleton）包含命令处理器、编解码器等，是底层通信能力之上，具体私有协议之下，连接通信能力和私有协议的中间层。网络通信层是SOFABolt对Netty的封装和功能增强，协议框架则是SOFABolt对网络请求处理流程的抽象，是用户可以不关心底层细节快速实现自己的处理器来完成网络请求的处理逻辑，是用户可以进行拓展来实现自定义的私有协议的基础，也是本篇文章分析的内容。\n私有协议实现 由于性能、安全性等等的原因，很多中间件都会采用私有协议进行通信。SOFABolt除了提供基础的通信能力、协议框架之外，还提供了默认的RPC协议的实现，这样它就是一个完整的通信框架，用户可以不关心协议而直接上手使用。本篇文章主要分析SOFABolt的协议框架的设计和实现，不展开对SOFABolt中的RPC协议实现做介绍。\n3. 协议框架 协议框架整体如下：\n Command：协议命令，通讯数据的顶层抽象。从交互的角度可以分为Request（请求）于Response（响应），从功能的角度，分为负载命令（交换业务数据）和控制命令（进行系统的管理、协调等）。 CommandEncoder/CommandDecoder：协议命令的编解码器，自定义协议实现的基础，编解码器完成对象和字节数组之间的相互转换。 CommandHandler：协议命令的处理器，命令处理入口，负责分发、处理命令。 CommandFactory：协议命令工厂类，负责创建协议命令对象。 HeartbeatTrigger：心跳的处理器，用户用户拓展特定的心跳机制的处理。 下面以SOFABolt中默认实现的RPC协议为例来介绍SOFABolt协议框架的实现。 3.1 请求的处理流程 一个请求处理流程大致如下：\n 通过CommandFactory构建请求对象 通过CommandEncoder对请求对象进行编码，写入到网络连接 服务端从连接中读取数据，通过CommandDecoder解析成请求对象 CommandHandler接收请求对象，进行分发和处理 CommandFactory是一个工厂类，比较简单，不展开介绍。编解码相关内容见《SOFABolt编解码机制》。下面介绍一下CommandHandler对请求的分发和处理。\n上面是SOFABolt中RpcHandler的代码片段，这段代码是命令处理的入口：\n 首先从连接的上下文中获取使用的协议的版本ProtocolCode 再根据ProtocolCode从ProtocolManager中获取具体的协议 之后从协议中获取CommandHandler，并构造请求的上下文信息和请求的对象（代码片段中的msg）提交处理 上面的处理逻辑中透露出一个信息：SOFABolt支持同时运行多个版本的协议，通过ProtocolCode来区分协议。这一点可以使得系统在做升级或重构时，需要同时支持新老系统不同协议时变得简单。\n上面是CommandHandler的代码片段，透露出的信息是SOFABolt支持批量提交请求，这在《SOFABolt编解码机制》一文中也有部分介绍。而具体的process流程如下：\n通过Command对象获取CommandCode，根据CommandCode获取对应的RemotingProcessor进行处理。 CommandCode是一个接口，只有一个返回short的value()方法，表示Command的具体类型，每个请求都需要有自己的CommandCode来标识自己的类型。框架通过一个Map来维护CommandCode和RemotingProcessor的关系，每个CommandCode需要有对应的RemotingProcessor进行处理，一个RemotingProcessor可以处理多个CommandCode的请求。\n再往下看一层，请求会被提交到RemotingProcessor中处理。上面是RpcRequestProcessor处理请求的代码片段，处理流程中会通过cmd.getRequestClass()来获取请求的对象的Class名称，再获取对应的UserProcess进行处理（具体处理不再上面的代码片段中）。 对用户来说，只需要实现自己的Command对象、实现自己的UserProcessor并注册到ProcessorManager中，就可以完成自己的网络通信。 以上是一个请求在SOFABolt的协议框架下的处理流程和核心代码的分析。\n3.2 协议框架的拓展机制 通过对请求处理流程的分析可以感受到SOFABolt的协议框架是支持多协议版本运行，能直接使用，也支持进行拓展来实现更丰富和定制化的功能。下面具体介绍SOFABolt的拓展机制。\n上图是RemotingCommand在处理过程中的路由示意图。第一层路由根据ProtocolCode进行，第二层路由根据CmdCode进行，第三层路由则根据RequestClass进行。用户可以在每一层进行扩展来实现自己的处理。 这种设计具有很好的拓展性和灵活性，ProtocolCode用于区分“大版本”的协议，适用于协议发生较大的变化的场景。CmdCode则标识请求类型，比如在RPC场景中CmdCode可能就两个：RPC_REQUEST、RPC_RESPONSE，而在消息场景中CmdCode可能会更丰富一些，比如有发送消息、批量发送消息、投递消息等等。RequestClass是Command上承载的数据的类型，用户根据不同的类名进行不同的业务逻辑的实行。\n实际应用中，以RPC的场景为例，用户更多的是去实现UserProcessor来完成不同的业务逻辑的处理。而在消息的场景中，因为消息承载的是二进制的数据，所以请求的数据类型是固定的，系统更多的是拓展CmdCode来执行不同类型的请求的处理，比如心跳请求的处理、写入消息的处理、批量写入消息的处理等等。SOFABolt协议框架的设计和实现，具备较好的可拓展性，使其能应用于蚂蚁 …","date":1544091600,"description":"本文是对蚂蚁金服开源通信框架 SOFABolt 的协议框架解析。","dir":"blog/sofa-bolt-framework-deep-dive/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"67335ca275995497a5f28340cb13f45b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","summary":"1. 前言 为了让中间件开发者们将更多的精力投入到产品的功能特性上，而不是重复的写通信层框架，蚂蚁中间件团队设计并实现了SOFABolt。 Bolt 名字取","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架 SOFABolt 协议框架解析","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","wordcount":3889},{"author":"鲁道","categories":"SOFABolt","content":" 前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将重点分析 SOFABolt 的序列化机制。\n我们知道，但凡在网络中传输数据，都涉及到序列化以及反序列化。即将数据编码成字节，再把字节解码成数据的过程。\n例如在 RPC 框架中，一个重要的性能优化点是序列化机制的设计。即如何为服务消费者和和服务提供者提供灵活的，高性能的序列化器。\n这里说的序列化器，不仅仅是指“对象”的序列化器，例如 Hessian，Protostuff，JDK 原生这种“对象”级别的序列化器，而是指“协议”级别的序列化器，“对象”的序列化只是其中一部分。通常“协议”级别的序列化器包含更多的信息。\n下面我们将先从 SOFABolt 的设计及实现入手，进而分析 SOFABolt 详细的序列化与分序列化流程，最后介绍 SOFABolt 序列化扩展。\n设计及实现 一个优秀的网络通信框架，必然要有一个灵活的，高性能的序列化机制。那么，SOFABolt 序列化机制的设计目标是什么呢？具体又是如何设计的呢？\n首先说灵活，灵活指的是，框架的使用方（这里指的是网络通信框架的使用方，例如 RPC，消息中心等中间件）能够自定义自己的实现，即用户决定使用什么类型的序列化以及怎么序列化。\n再说高效，序列化和反序列化事实上是一个重量级的操作，阿里 HSF 作者毕玄在著名的 NFS-RPC框架优化过程（从37k到168k） 文章中提到，其优化 RPC 传输性能的第一步就是调整反序列化操作，从而将 TPS 从 37k 提升到 56k。之后又通过更换对象序列化器，又将 TPS 提升了将近 10k。由此可见，合理地设计序列化机制对性能的影响十分巨大。\n而 SOFABolt 和 HSF 有着亲密的血缘关系，不但有着 HSF 的高性能，甚至在某些地方，优化的更为彻底。\n我们现在可以看看 SOFABolt 序列化设计。\n接口设计 SOFABolt 设计了两个接口：\n Serializer 该接口定义 serialize 方法和 deserialize 方法，用于对象的序列化和反序列化。 CustomSerializer 该接口定义了很多方法，主要针对自定义协议中的 header 和 content 进行序列化和反序列化。同时提供上下文，以精细的控制时机。 同时，从框架设计的角度说，他们可以称之为 “核心域”， 他们也被对应的 “服务域” 进行管理。\n这里解释一下服务域和核心域，在框架设计里，通常会有“核心域”，“服务域”， “会话域” 这三部分组成。\n例如在 Spring 中，Bean 就是核心域，是核心领域模型，所有其他模型都向其靠拢；而 BeanFactory 是服务域，即服务“核心域”的模型，通常长期存在于系统中，且是单例；“会话域” 指的是一次会话产生的对象，会话结束则对象销毁，例如 Request，Response。\n在 SOFABolt 序列化机制中，Serializer 和 CustomSerializer 可以认为是核心域，同时，也有服务于他们的 “服务域”，即 SerializerManager 和 CustomSerializerManager。“会话域” RpcCommand 依赖 “服务域” 获取 “核心域” 实例。\nUML 设计图如下：\n其中红色部分就是 SOFABolt 序列化机制的核心接口，同时也是用户的扩展接口，他们被各自的 Manager 服务域进行管理，最后，会话域 RpcCommand 依赖着 Manager 以获取序列化组件。\n这两个接口的使用场景通常在数据被 协议编解码器 编码之前或解码之后，进行处理。\n例如在发送数据之前，协议编码器 根据通信协议（如 bolt 协议）进行编码，编码之前，用户需要将数据的具体内容进行序列化，协议编解码器 再进行更详细的编码。\n同样，协议解码器 在接收到 Socket 发送来的字节后，根据协议将字节解码成对象，但是，对象的内容还是字节，需要用户进行反序列化。\n一个比较简单的流程图就是这样的:\n上图中，假设场景是 Client 发送数据给 Server，那么，编解码器负责将字节流解码成 Command 对象，序列化器负责将 Command 对象里的内容反序列化成业务对象，从设计模式的角度看，这里是 GOF 中 “命令模式”和“职责链模式”的组合设计。\n看完了设计，再看看实现。\n接口实现 我们可以看看这两个接口的实现。\n Serializer Serializer 接口在 SOFABolt 中已有默认实现，即 HessianSerializer，目前使用的是 hessian-3.3.0 版本。通过一个 SerializerManager 管理器进行管理。注意，这个管理器内部使用的是数组，而不是 Map，这在上文毕玄的文章也曾提到：通过使用数组替换成 Map，NFS-RPC 框架的 TPS 从 153k 提升到 160k。事实上，任何对性能非常敏感的框架，能用数组就绝不用 Map，例如 Netty 的 FastThreadLocal，也是如此。\n当然，Serializer 接口用户也是可以扩展的，例如使用 protostuff，FastJson，kryo 等，扩展后，通过 SerializerManager 可以将自己的序列化器添加到 SOFABolt 中。注意：这里的序列化 type 实际就是上面提到的数组的下标，所以不能和其他序列化器的下标有冲突。\n CustomSerializer 再说 CustomSerializer，这个接口也是有默认实现的，用户也可以选择自己实现，我们这里以 SOFARPC 为例。\nSOFARPC 在其扩展模块 sofa-rpc-remoting-bolt 中，通过实现 CustomSerializer 接口，自己实现了序列化 header，content。\n这里稍微扩展讲一下 header 和 content。实际上，header 和 content 类似 http 协议的消息头和消息体，header 和 content 中到底存放什么内容，取决于协议设计者。\n例如在 SOFARPC 的协议中，header 里存放的是一些扩展属性和元信息上下文。而 content 中存放的则是主要的一些信息，比如 request 对象，request 对象里就存放了 RPC 调用中常用信息了，例如参数，类型，方法名称。\n同时，CustomSerializer 接口定义的方法中，提供了 InvokeContext 上下文，例如是否泛化调用等信息，当进行序列化时，将是否泛型的信息放入上下文，反序列化时，再从上下文中取出该属性，即可正确处理泛化调用。\n注意，如果用户已经自己实现了 CustomSerializer 接口，那么 SOFABolt 的 SerializerManager 中设置的序列化器将不起作用！因为 SOFABolt 优先使用用户的序列化器。\n具体代码如下：\n行文至此，讨论的都是“灵活”这个设计，即用户既可以使用 SOFABolt …","date":1544091600,"description":"SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架，本文将重点分析 SOFABolt 的序列化机制。","dir":"blog/sofa-bolt-serialization-deep-dive/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2145bb681760cdf3d1953bf4ed75fa60","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","summary":"前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之序列化机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","wordcount":4630},{"author":"水寒","categories":"SOFABolt","content":" 基础介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生。 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，积累了很多经验，并持续的进行着优化和完善，我们希望能把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。 目前该产品已经运用在了蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n前言 SOFABolt 提供了设计良好、使用便捷的编解码功能。本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。欢迎大家与我们讨论交流。\n编解码介绍 每个网络应用程序都必须定义如何解析在两个节点之间来回传输的原始字节，以及如何将其和目标应用程序的数据格式做相互转换。在一个成熟的通信框架中，我们通常都会通过私有通信协议来描述这种定义，通过编解码技术将理论上的私有通信协议转化为实践。\n通过编解码技术，我们可以方便的做一些逻辑，例如双方可以方便的统一序列化与反序列化方式、解决 TCP 拆包粘包问题等。\n下面，我们先来看一下 TCP 粘包拆包问题的产生，然后分析 Netty 是如何解决粘包拆包问题的，最后分析 SOFABolt 是如何解决粘包拆包问题的。\nTCP 粘包拆包问题 如上图所示，三种拆包原因见黄色标签说明；两种粘包原因见蓝色标签说明。TCP 本身是面向流的，它无法从源源不断涌来的数据流中拆分出或者合并出有意义的信息，通常可以通过以下几种方式来解决：\n 基于分隔符协议：使用定义的字符来标记一个消息的结尾，在编码的时候我们在消息尾部添加指定的分隔符，在解码的时候根据分隔符来拆分或者合并消息。Netty 提供了两种基于分隔符协议的解码器 LineBasedFrameDecoder 和 DelimiterBasedFrameDecoder。LineBasedFrameDecoder 指定以 \\n 或者 \\r\\n 作为消息的分隔符；DelimiterBasedFrameDecoder 使用用户自定义的分隔符来标记消息的结尾。 基于定长消息协议：每一个消息在编码的时候都使用固定的长度，在解码的时候根据这个长度进行消息的拆分和合并。Netty 提供了 FixedLengthFrameDecoder 解码器来实现定长消息解码。 基于变长消息协议：每一个消息分为消息头和消息体两部分，在编码时，将消息体的长度设置到消息头部，在解码的时候，首先解析出消息头部的长度信息，之后拆分或合并出该长度的消息体。Netty 提供了 LengthFieldBasedFrameDecoder 来实现变长消息协议解码。 基于私有通信协议：Netty 提供了 MessageToByteEncoder 和 ByteToMessageDecoder 两个抽象类，这两个抽象类提供了基本的编解码模板。用户可以通过继承这两个类来实现自定义的编解码器。SOFABolt 通过继承 MessageToByteEncoder 实现了自定义的编码器，通过继承修改版的 ByteToMessageDecoder 来实现了解码器。对于处理 TCP 粘包拆包问题，SOFABolt 实际上也是使用变长消息协议，SOFABolt 的私有通信协议将消息体分为三部分 className、header、body，在消息头对应的提供了 classLen、headerLen、bodyContent 分别标识三部分的长度，之后就可以基于这三个长度信息进行消息的拆分和合并。 对于一个成熟的 rpc 框架或者通信框架来讲，编解码器不仅仅是要处理粘包拆包问题，还要实现一些特有的需求，所以必须制定一些私有通信协议，下面来看一下 SOFABolt 的私有通信协议的设计。\nSOFABolt 私有通信协议的设计 以下分析以 SOFABolt 1.5.1 版本为例。SOFABolt 定义了两种协议 RpcProtocol 和 RpcProtocolV2。针对这两种协议，提供了两组不同的编解码器。\n RpcProtocol 协议定义 请求命令（协议头长度：22 byte） ProtocolCode ：这个字段是必须的。因为需要根据 ProtocolCode 来进入不同的核心编解码器。该字段可以在想换协议的时候，方便的进行更换。 RequestType ：请求类型，request / response / oneway 三者之一。oneway 之所以需要单独设置，是因为在处理响应时，需要做特殊判断，来控制响应是否回传。 CommandCode ：请求命令类型，request / response / heartbeat 三者之一。 CommandVersion ：请求命令版本号。该字段用来区分请求命令的不同版本。如果修改 Command 版本，不修改协议，那么就是纯粹代码重构的需求；除此情况，Command 的版本升级，往往会同步做协议的升级。 RequestId ：请求 ID，该字段主要用于异步请求时，保留请求存根使用，便于响应回来时触发回调。另外，在日志打印与问题调试时，也需要该字段。 Codec ：序列化器。该字段用于保存在做业务的序列化时，使用的是哪种序列化器。通信框架不限定序列化方式，可以方便的扩展。 Timeout ：超时字段，客户端发起请求时，所设置的超时时间。 ClassLen ：业务请求类名长度 HeaderLen ：业务请求头长度 ContentLen ：业务请求体长度 ClassName ：业务请求类名。需要注意类名传输的时候，务必指定字符集，不要依赖系统的默认字符集。曾经线上的机器，因为运维误操作，默认的字符集被修改，导致字符的传输出现编解码问题。而我们的通信框架指定了默认字符集，因此躲过一劫。 HeaderContent ：业务请求头 BodyContent ：业务请求体 响应命令（协议头长度：20 byte） ResponseStatus ：响应码。从字段精简的角度，我们不可能每次响应都带上完整的异常栈给客户端排查问题，因此，我们会定义一些响应码，通过编号进行网络传输，方便客户端定位问题。 RpcProtocolV2 协议定义 请求命令（协议头长度：24 byte） ProtocolVersion ：确定了某一种通信协议后，我们还需要考虑协议的微小调整需求，因此需要增加一个 version 的字段，方便在协议上追加新的字段 Switch ：协议开关，用于一些协议级别的开关控制，比如 CRC 校验， …","date":1544091600,"description":"本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。","dir":"blog/sofa-bolt-codec-deep-dive/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9383bfa0b8c9975e3d4b2ed4bc01a593","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","summary":"基础介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之编解码机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","wordcount":3909},{"author":"胡萝卜、丞一","categories":"SOFABolt","content":" 前言 SOFABolt 是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将分析SOFABolt的超时控制和心跳机制。\n超时 在程序中，超时一般指的是程序在特定的等待时间内没有得到响应，网络通信问题、程序BUG等等都会引起超时。系统引入超时机制往往是为了解决资源的问题，比如一个同步RPC请求，在网络不稳定的情况下可能一直无法得到响应，那么请求线程将一直等待结果而无法执行其它任务，最终导致所有线程资源耗尽。超时机制正是为了解决这样的问题，在特定的等待时间之后触发一个“超时事件”来释放资源。\n在一个网络通信框架中，超时问题无处不在，连接的建立、数据的读写都可能遇到超时问题。并且网络通信框架作为分布式系统的底层组件，需要管理大量的连接，如何建立一个高效的超时处理机制就成为了一个问题。\n时间轮（TimeWheel） 在网络通信框架中动辄管理上万的连接，每个连接上都有很多的超时任务，如果每个超时任务都启动一个java.util.Timer，不仅低效而且会占用大量的资源。George Varghese 和 Tony Lauck在1996年发表了一篇论文：《Hashed and Hierarchical Timing Wheels: EfficientData Structures for Implementing a Timer Facility》来高效的管理和维护大量的定时任务。\n时间轮其实就是一种环形的数据结构，可以理解为时钟，每个格子代表一段时间，每次指针跳动一格就表示一段时间的流逝（就像时钟分为60格，秒针没跳动一格代表一秒钟）。时间轮每一格上都是一个链表，表示对应时间对应的超时任务，每次指针跳动到对应的格子上则执行链表中的超时任务。时间轮只需要一个线程执行指针的“跳动”来触发超时任务，且超时任务的插入和取消都是O(1)的操作，显然比java.util.Timer的方式要高效的多。\nSOFABolt的超时控制机制 如上图所示，SOFABolt中支持四中调用方式：\n oneway：不关心调用结果，所以不需要等待响应，那么就没有超时 sync：同步调用，在调用线程中等待响应 future：异步调用，返回future，由用户从future中获取结果 callback：异步调用，异步执行用户的callback 在oneway调用中，因为并不关心响应结果，所以没有超时的概念。下面具体介绍SOFABolt中同步调用（sync）和异步调用（future\\callback）的超时机制实现。 同步调用的超时控制实现 同步调用中，每一次调用都会阻塞调用线程等待服务端的响应，这种场景下同一时刻产生最大的超时任务取决于调用线程的数量。线程资源是非常昂贵的，用户的线程数是相对可控的，所以这种场景下，SOFABolt使用简单的java.util.concurrent.CountDownLatch来实现超时任务的触发。\nSOFABolt同步调用的代码如上，核心逻辑是：\n 创建InvokeFuture 在Netty的ChannelFuture中添加Listener，在写入操作失败的情况下通过future.putResponse方法修改Future状态（正常服务端响应也是通过future.putResponse来改变InvokeFuture的状态的，这个流程不展开说明） 写入出现异常的情况下也是通过future.putResponse方法修改Future状态 通过future.waitResponse来执行等待响应 其中和超时相关的是future.waitResponse的调用，InvokeFuture内部通过java.util.concurrent.CountDownLatch来实现超时触发。 java.util.concurrent.CountDownLatch#await(timeout, timeoutUnit) 方法实现了等待一段时间的逻辑，并且通过countDown方法来提前中断等待，SOFABolt中InvokeFuture通过构建new CountDownLatch(1)的实例，并将await和countDown方法包装为awaitResponse和putResponse来实现同步调用的超时控制。\n异步调用的超时控制实现 相对于同步调用，异步调用并不会阻塞调用线程，那么超时任务的数量并不受限于线程对的数量，用户可能通过一个线程来触发量大的请求，从而产生大量的定时任务。那么我们需要一个机制来管理大量的定时任务，并且作为系统底层的通信框架，需要保证这个机制尽量少的占用资源。上文已经提到TimeWheel是一个非常适合于这种场景的数据结构。\nNetty中实现了TimeWheel数据结构：io.netty.util.HashedWheelTimer，SOFABolt异步调用的超时控制直接依赖于Netty的io.netty.util.HashedWheelTimer实现。\nFuture模式和Callback模式在超时控制机制上一致的，下面以Callback为例分析异步调用的超时控制机制。\nSOFABolt异步调用的代码如上，核心逻辑是：\n 创建InvokeFuture 创建Timeout实例，Timeout实例的run方法中通过future.putResponse来修改InvokeFuture的状态 在Netty的ChannelFuture中添加Listener，在写入操作失败的情况下通过future.cancelTimeout来取消超时任务，通过future.putResponse来修改InvokeFuture的状态 在写入异常的情况下同样通过future.cancelTimeout来取消超时任务，通过future.putResponse来修改InvokeFuture的状态 在异步调用的实现中，通过Timeout来触发超时任务，相当于同步调用中的java.util.concurrent.CountDownLatch#await(timeout, timeoutUnit)。Future#cancelTimeout()方法则是调用了Timeout的cancel来取消超时任务，相当于同步调用中通过 java.util.concurrent.CountDownLatch#countDown() 来提前结束超时任务。具体超时任务的管理则全部委托给了Netty的Timer实现。 另外值得注意的一点是SOFABolt在使用Netty的Timer时采用了单例的模式，因为一般情况下使用一个Timer管理所有的超时任务即可，这样可以节省系统的开销。 Fail-Fast机制 以上关于SOFABolt的超时机制介绍都是关于SOFABolt客户端如何完成高效的超时任务管理的，其实在SOFABolt的服务端同样针对超时的场景做了优化。\n客户端为了应对没有响应的情况，增加了超时机制，那么就可能存在服务端返回一个响应但是客户端在收到这个响应之前已经认为请求超时了，移除了相关的请求上下文，那么这个响应对客户端来说就没有意义 …","date":1544091600,"description":"本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。","dir":"blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8f3ab1ecc952a0fc5ea40576e8b57471","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","summary":"前言 SOFABolt 是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之超时控制机制及心跳机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","wordcount":4303},{"author":"任展","categories":"SOFABolt","content":" 前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将重点分析 SOFABolt 的连接管理功能。\n我们知道，一次 tcp 请求大致分为三个步骤：建立连接、通信、关闭连接。每次建立新连接都会经历三次握手，中间包含三次网络传输，对于高并发的系统，这是一笔不小的负担；关闭连接同样如此。为了减少每次网络调用请求的开销，对连接进行管理、复用，可以极大的提高系统的性能。\n下面我们将介绍 SOFABolt 在连接管理的实现，包括连接生命周期管理、定时断连及自动重连等。\n设计抽象 首先我们将会介绍 SOFABolt 对连接的封装抽象。\n连接封装 SOFABolt 中定义了一个基础的连接类 \u0026amp;ndash; Connection:\n省去 AtributeKey 类型定义以及 Log 配置，以上是Connection中所有的成员变量。包括几个方面:\n 连接：Channel、Url 版本：protocolCode、version 调用：invokeFutureMap 附着：attributes 引用：referenceCount、id2PoolKey、poolKeys 这里提一下 protocolCode 和 version，版本信息会被携带至对端，用于连接的协商。总的来说，通过对于 Channel 的包装，Connection 提供了丰富的上下文及引用信息，是 SOFABolt 连接管理的直接对象。\n连接事件 SOFABolt 定义了连接事件和事件监听器用于处理连接对象。ConnectionEventType 定义了三种事件类型：CONNECT, CLOSE 和 EXCEPTION. 针对不同的连接事件类型，我们可以通过事件监听器 \u0026amp;ndash; ConnectionEventListener 来进行处理，下面来看一下 ConnectionEventListener 类：\n监听器定义了两个方法 onEvent 和 addConnectionEventProcessor, 分别是触发事件和添加事件处理器。整个监听器采用一个 HashMap 来存储事件类型及其对应的处理器集合。在触发相关连接事件后，会遍历处理器集合并调用处理器执行。\nSOFABolt 的连接管理集中在 ConnectionEventHandler 中处理，他继承了 ChannelDuplexHandler，是标准的用来处理Connection连接对象并进行日志打印的一个处理器。先来看一下成员组成：\n其中连接事件监听器上文已经提及，剩下的几个成员从名称上也通俗易懂，先简单介绍一下，后续会详细地展开：\n 连接管理器：管理连接对象，包括创建、添加、删除、检查是否可用等等 连接事件监听器：监听连接事件的触发，然后执行对应的逻辑 连接事件执行器：包装后的线程池，用于异步触发连接事件监听器来处理对应的连接事件，值得一提的是，这个线程池只有一个线程。 重连管理器：顾名思义，管理重连的Url对象以及执行重连任务 全局开关：全局的设置，比如是否需要管理连接对象、是否需要执行重连任务等等 代码中方法都比较简单，大部分的处理逻辑围绕 Connection 对象展开，主要是维护有关本 Channel 对象的 Connection 对象的生命周期(包括connect、close等事件)。下面着重分析两个方法：\nhannelInactive 方法是在连接断开前触发的方法，在 SOFABolt 里的处理逻辑中，会根据globalSwitch 中 CONN_RECONNECT_SWITCH 的开关状态来判定是否开启重连的任务。除此之外，会在最后触发该 Connection 对象的 CLOSE 事件。这个触发事件是在异步线程中执行的，也就是上文提到的连接事件执行器。\n另一个是 userEventTriggered 方法， 用来触发自定义的用户事件，通过查看本方法的调用位置，可以得知，该方法是在连接建立的最初被触发的，一个简单的例子可以在RpcServer类中找到：\n在连接建立触发 fireUserEventTriggered 方法后，我们就开始执行对应此方法中的逻辑，也可以看到，在判定是 CONNECT 事件后，通过attr得到绑定在Channel的Connection对象，然后就同 channelInactive 方法一样，触发 CONNECT 事件异步执行对应的处理器逻辑。\n连接管理 下面来介绍 ConnectionManager，SOFABolt 提供了默认的实现类 DefaultConnectionManager类。顾名思义，主要负责连接对象的管理：\n 通过工厂创建 Connection 连接对象 通过注入的选择策略进行 Connection 连接的选择 管理创建和添加的 Connection 对象和 ConnectionPool 连接池对象（包括检查 Connection 对象、维护 ConnectionPool 的健壮性） 控制 Connection 对象的心跳打开与关闭 创建连接 ConnectionFactory 用于创建连接对象，SOFABolt 提供了两个实现类： DefaultConnectionFactory 和 RpcConnectionFactory。这个工厂类执行了客户端所有 Connection 对象的创建工作，代码也比较简单：\n注意到了吗，在创建完毕 Connection 对象后，执行了 fireUserEventTriggered 方法，这样就保证了每一个 Connection 对象在创建之后都会去触发 CONNECT 事件。\n选择连接 ConnectionSelectStrategy 选择策略的默认实现是随机策略 RandomSelectStrategy, 在执行选择连接时大致分为两步：\n 在开启CONN_MONITOR_SWITCH监控时，会从该连接池所有的连接中做一个简单的filter操作，把CONN_SERVICE_STATUS为ON的连接挑选出来，作为选择池。如果没有开启监控，那么选择池就是连接池。 执行挑选策略，获取选择池中的一个连接。 管理连接和连接池 管理连接和连接池是 ConnectionManager 最主要的作用，用来进行连接和连接池的生命周期管理，包括添加、删除、检查健康、恢复连接数等功能。下面先看一个在添加中常见的方法，用来获取一个连接池对象或者创建一个，限于篇幅，这里不贴代码，有兴趣的同学可以在 GitHub 上查看源码。在执行创建连接池对象时，会有两种逻辑:\n 返回空的连接池 返回一个初始化过的连接池(有一定的连接数) 这两种逻辑其实对应的是两种需求，第一个对应连接已经创建好然后放入连接池的流程，第二个则是对应通过 Url 来创建一个连接池并且在连接池中做新建连接的流程。那么对于第二种情况，由于建立连接需要耗时且有可能抛出异常，所以 ConnectionManager 允许重试两次。\n下面来说说对于连接和连接池的维护方面的功能， …","date":1544091600,"description":"本文将重点分析 SOFABolt 的连接管理功能。","dir":"blog/sofa-blot-connection-management-deep-dive/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"99733a6333604b8aeb8ada37d5705d36","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","summary":"前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之连接管理剖析","type":"blog","url":"/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","wordcount":3490},{"author":"奕杉","categories":"Service Mesh","content":" 朵晓东，花名奕杉，蚂蚁金服高级技术专家。专注企业云计算技术及产品，蚂蚁金融云 PaaS 创始团队核心成员，Antstack 网络产品负责人。开源爱好者，Apache Kylin 创始团队核心成员；SOFAMesh 创始团队核心成员，SOFAMosn 项目负责人。 本文根据晓东在 GIAC 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，我是蚂蚁金服系统部的高级技术专家奕杉，今天分享的内容是: 《蚂蚁金服在 ServiceMesh 推进落地过程中对新型网络代理的思考和实践》\n内容结构： 主要的分享顺序：\n 背景概述 架构设计及功能特性 技术案例 总结展望 1、背景、概览 ServiceMesh 作为云原生之上的服务网格技术在今年引起了业界的广泛关注，首先我们来看一下目前 ServiceMesh 数据平面的一些方案。\n最为大家熟知的是老牌七层代理 Nginx 和 ISTIO 原生的数据平面 Envoy。Nginx 早已在国内外广泛使用，近两年积极探索 K8S、ServiceMesh 微服务场景，并推出了与 ISTIO 集成的微服务解决方案，试图扩展其场景边界，拿下新的领域，从单纯的7层流量代理到云原生时代的智能数据平面转型。但目前看 “NgMesh”研发不够活跃，已知的使用方也不多。Envoy 作为 Google 和 Lyft联合开发的 ISTIO 原生数据平面产品，近两年借助 ServiceMesh 微服务场景快速打开了市场，并在一些互联网公司推广使用，同时引入了一批开发者进行 API 网关等功能网关的开发，发展势头非常好。\n其次 LINKERD 是基于 Rust 的一种高性能数据平面，但其发展空间受到了 Envoy 挤压，业界使用的公司也比较有限。\n蚂蚁金服基于自身诉求自研了基于 Golang 的数据平面 SOFAMosn（后简称MOSN），并在蚂蚁、UC 等公司落地使用。 同时对业界开源，提供了一种新的数据平面产品选择。\n此外国内的华为、新浪等公司都基于自身场景提出了数据平面方案并先后进行了开源，数据平面竞争已经从独霸业界的基于 Nginx 二开方案逐步转变为目前的多样化产品同场竞技的局面。\n为什么众多大厂纷纷投入研发数据平面呢？\n我个人认为新生技术栈、云原生、微服务快速发展等契机对数据平面提出了场景多样化、功能服务化、云原生亲和等多重挑战。\n以往从未像现在这样对数据平面提出过如此多的要求：\n 数据平面需要执行部署运维中的流量切换； 需要提供云亲和的细粒度流量调度功能； 需要提供微服务亲和的服务发现、路由组网特性； 需要以云原生的方式感知资源； 需要支撑服务粒度、高度自定义的压测、故障测试、线上灰度流量管理； 需要提供链路级、服务级的安全隔离保护，需要支持多种语言、多种协议的转换分发能力； 需要能享受系统层面、硬件层面的红利； 需要为复杂的运维架构（如蚂蚁的 LDC 等）提供可扩展的流量调拨能力等等； 当然根据每个公司的业务场景可能还有其他的因素。 最后，如何要将这些能力都汇聚在统一的数据平面产品上，弥合南北向、东西向数据平面由于技术栈、团队等差异带来的鸿沟，变成了另一个更为复杂的问题。这里所提到的问题中任何一点扩展开来都可以是一个丰富独立的 Topic，受限于篇幅本次分享只能介绍我们在解决这些问题中的一小部分思考和实践。\n2、SOFAMesh 架构 \u0026amp;amp; 重点特性 首先，蚂蚁已经将基于 ISTIO 的 ServiceMesh 方案 \u0026amp;ldquo;SOFAMesh\u0026amp;rdquo; 开源，在控制面我们选择克隆 ISTIO 官方版本并研发符合蚂蚁需求的控制面，在数据面我们选择使用 Golang 研发数据平面 MOSN，目前已经支持了微服务场景所需的大量常用功能。\n这里我根据 ISTIO 的 Task 文档总结了目前 SOFAMesh 支持的一些能力，如：透明拦截适配，细粒度的流控，故障注入，双向链路加密等。对于一些暂时存疑的功能，如 Mixer Check 等，暂时没有支持。目前 SOFAMesh 已在 UC 生产环境落地使用，满足了 Sidecar、Ingress、Egress 多种场景的使用需求。在这里附上 SOFAMesh，SOFAMosn 的 Github 地址，也欢迎大家使用交流。\nSOFAMesh: https://github.com/alipay/sofa-mesh SOFAMosn: https://github.com/alipay/sofa-mosn\n再来看看蚂蚁内部，由于目前蚂蚁生产环境尚未大量铺开K8S，并且已经存在一套完善的管控技术体系，加上目前ISTIO 的性能和稳定性还不满足大规模微服务场景等原因，我们暂时没有选择直接升级到 ISTIO，而是通过优先落地Sidecar 的方式来赢得 ServiceMesh 解决方案带来的红利。在蚂蚁内部，MOSN 接管了SOFABoot 应用，代理了服务发现、路由/负载均衡、通信等工作，构成了微服务网格，通过自有的中间件及管控平面进行微服务的管理、治理。同时，我们积极的推进 MOSN 与 SOFA中间件，网络接入层，安全防护及监控体系的整合，以提供更统一更强大的数据平面。\n接下来我将介绍 MOSN 支持多协议的方案。\n为了在内部快速落地试错，我们首先支持了内部使用最广泛的 SOFARPC 协议，并对其进行了深度优化。随后我们根据 UC Mesh 化推进遇到的普遍问题提出了 XProtocol 方案，以在不解包的场景下提供路由能力。最后我们深度改造了三方 HTTP/1.1 实现及官方 HTTP/2.0 实现。到目前为止，MOSN 已提供了多种协议的支持。同时 MOSN 提供了两种自定义协议的能力支持使用者通过扩展的方式自定义协议实现，满足需要解包、不需要解包的协议扩展需求。\n除协议之外，性能是大家比较关心的另一个问题。为了提供满足生产要求的7层转发性能，我们在 IO、协议、内存、协程、网络处理等方面进行了优化，从目前通过 SOFARPC 通信应用的上线情况来看可以满足生产使用要求，在案例分析中我将展示一些性能数据，后续我们也将继续推进性能优化，以达到更好的性能。\n在安全能力上，SOFAMesh 支持 mTLS，并在蚂蚁内部集成蚂蚁内部的 KMS 完成了 mTLS 落地，同时 RBAC 功能在研发中，此外WAF、流量镜像能功能也在规划中。\n在蚂蚁内部基于 MOSN 的网关产品正在研发中，将会在稳定验证后开源。网关场景相对于 Sidecar 场景有一些特性需求，比如说一般会 Hold 住大量长链接，比如说会根据请求内容动态选择后端应用，由于网关可能代理了不同的后端应用，就会需要动态选择后端协议。此外还有一些网关类的通用能力需求，如签名，授权，限流等。\n为了能基于开源版建设蚂蚁内部的 Sidecar 及网关产品，我们充分考虑了开源版 MOSN 的扩展性，在路由、后端管理、TLS、网络、流处理等各方面提供了扩展性支持。对于其他使用 MOSN 的场景，也可以通过类似的方式来满足自身业务定制需求。\n为了更清晰的展示 MOSN 功能特性，这里将 MOSN 0.4.0 的功能特性通过表格的方式展示出来。可 …","date":1543906800,"description":"本文根据晓东在 GIAC 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-giac-2018/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"71d6ede37fa4f1d1e6c99fbd37ff2f52","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-giac-2018/","publishdate":"2018-12-04T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/service-mesh-giac-2018/","summary":"朵晓东，花名奕杉，蚂蚁金服高级技术专家。专注企业云计算技术及产品，蚂蚁金融云 PaaS 创始团队核心成员，Antstack 网络产品负责人。开源爱好者，","tags":["Service Mesh"],"title":"蚂蚁金服 Service Mesh 新型网络代理的思考与实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-giac-2018/","wordcount":7130},{"author":"敖小剑","categories":"Service Mesh","content":" 敖小剑，蚂蚁金服高级技术专家，十六年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher 社区联合创始人。 龙轼，阿里巴巴技术专家、前京东 Hadoop 负责人、Hadoop 代码贡献者、现负责UC 基于 Kubernetes 自研的 PaaS 平台整体的稳定性。 本文根据他们在 Service Mesher Meetup 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，今天给大家带来的演讲主题是《蚂蚁金服 Service Mesh 渐进式迁移方案》，给大家介绍一下我们蚂蚁金服主站的 Service Mesh 迁移方案，在稍后的内容中我会给大家解释什么是“渐进式”。今天的演讲方式有些特殊，将会是两位讲师合作。我是敖小剑，来自蚂蚁金服中间件团队，另外一位讲师 龙轼 ，来自 UC 基础研发部。\nService Mesh 演进路线 今天的内容将会有四块主要内容：\n Service Mesh演进路线：介绍蚂蚁金服计划在主站落地Service Mesh的方案，由于涉及到大量的存量应用和超大规模，又要保证迁移过程的平滑，因此我们的落地方案相比社区方案要复杂的多。 实现平滑迁移的关键：介绍在整个迁移方案中，为了实现平滑迁移的几个关键做法，然后今天我们将详细展开其他的一个关键点：DNS寻址方案。 DNS寻址方案的演进：详细介绍Kubernetes/Istio/SOFAMesh一路演进过来的DNS寻址方式 DNS寻址方案的后续规划：介绍我们在DNS寻址方案上的后续规划。 前两块内容将由我来为大家介绍，后两块内容将由我的同事 龙轼 为大家介绍。\n在展开内容之前，先看一下背景，Service Mesh在蚂蚁金服主站落地的背景：\n 目标：需要满足我们对长期目标的认可，具体指服务间通讯走Service Mesh，而且是Istio这种带完整的控制平面的Service Mesh形态，基础设施要构建在k8s之上，而应用的形态要向微服务靠拢。 现状：而现实是存在很多挑战，首先还有很多应用没有实现微服务化，而且我们的k8s普及程度也不够，还有非常多的应用没有运行在kubernets之上。Istio的成熟程度也稍显不足，不够稳定，更大的挑战的是Istio目前无法原生支持我们蚂蚁金服的规模，我们还在试图对Istio进行改进和扩展。最后，在落地时必须考虑的非常现实的一点：现有系统中为数众多的应用不可能一夜之间全部迁移。 关键需求：因此在落地实施时，非常重要的需求是：要实现平滑迁移。简单说，微服务 + Service Mesh + kubernetes 是我们的目标，但是如何从现有体系出发，向目标平稳和坚实的迈进，必须给出可行的实践指导。 今天演讲的内容，要给大家介绍的就是，在这样的背景下，我们蚂蚁金服选择的Service Mesh主站落地演进方案。这个方案预期会在2019年初全面铺开。\n主站落地方案的实施原则，这是我们在过去半年的实践中，总结归纳出来的行为指导：\n 符合远期规划：一定要有清晰的长期目标，明确的知道未来的大方向。避免走弯路，避免浪费投资，理想状态是计划中的每一步都可以为下一步奠定坚实的基础。即使因为某些原因不得已妥协或绕行，也应该清晰的知道后面应该如何回归，谢绝中途推倒重来——代价太高，无法承受。 循序渐进：认清现实，如此之大的变革，一定是需要分步进行，不要心存一步登天的幻想，现实可行的方式是小步快跑。将整个过程拆解为若干个大步骤，每一步的工作量和复杂度都控制在一个可以接受的范围内，以保证每一步都简单方便，切实可行。 有可操作性：在操作层面上，要有足够的弹性，即每个步骤中的工作内容，都应该是可以分批进行。以步步为营的方式，逐步扩大战果，杜绝一刀切。 在接下来的演进路线中，大家将会体会到这三个原则在实际落地时的指导作用。\n这个图的信息量有点大，描述的是 Service Mesh 和 k8s 落地可能的多种演进路线。\n我们先从最下面开始看，这是当前蚂蚁金服主站大多数应用的现状：即应用\u0026amp;rdquo;部署在非k8s上\u0026amp;rdquo;，应用也\u0026amp;rdquo;不是Service Mesh形态\u0026amp;rdquo;。 然后看最上面，这是我们期望的蚂蚁金服主站未来的应用终极形态：应用\u0026amp;rdquo;部署在k8s上\u0026amp;rdquo;，应用也迁移到了\u0026amp;rdquo;Service Mesh形态\u0026amp;rdquo;。\n这里有个特别的地方，我们将Service Mesh形态细分为两种模式：\n Sidecar模式：只有Sidecar，没有控制平面，和外部系统的各种集成都是在Sidecar中直接进行。这是第一代的Service Mesh，Linkerd/Envoy都是如此，华为基于ServiceComb演进而来的mesher，新浪微博的Mesh，包括我们蚂蚁金服基于MOSN开发的用于取代多语言客户端的Mesh方案。 Istio模式：有完善的控制平面，可以提供强大的控制能力，而且从数据平面分离，这是第二代的Service Mesh，典型如Istio和Conkduit/Linkerd 2.0。 之所以将Service Mesh形态细分，是因为我们有着这样一个特殊背景：目前的原生Istio无法支撑我们蚂蚁金服的规模，因此在改进完善Istio之前，我们不得不暂时在Sidecar模式下短暂停留。另外一个原因就是考虑到存量应用的迁移，多一个Sidecar模式作为中间缓冲，会让整个迁移过程平滑很多。\n现在我们来介绍图中展示的四条演进路线：\n 左边的路线1，思路是先将应用迁移k8s部署，再迁移到Service Mesh形态。这条路线的最大好处，是过程中每个阶段的绝大多数投资都将最终得以保留，因为符合k8s+service mesh的远期目标。 右边的路线2，思路是跳过k8s，先迁移到Service Mesh形态，一路演进到Istio模式，然后最后迁移到k8s。 中间的路线3，直接一步到位，这个路线是Istio默认的方式，或者说Istio根本没有考虑过迁移的问题，默认客户已经有完善的k8s，然后将改造好的应用直接部署在Istio上。这个路线对于蚂蚁金服主站的复杂场景，当然是不现实的。（补充：只是对蚂蚁金服主站不合适，对于大多数公司，规模不是那么巨大，也没有历史负担，也有k8s基础，完全可行。） 还有一条特别的路线4，走位飘忽，先和路线2一样迁移到Sidecar模式，然后走回路线1，上k8s，再在有k8s支持的情况下继续演进到Istio模式。 下面我们来详细分析各条演进路线的优劣和实施条件。\n演进路线2，和路线1的核心差别，在于：是先上k8s，还是先上Service Mesh。而且路线2是在非k8s条件下一路演进Service Mesh到我们期望的终极形态Istio模式，这意味着过程中和最终目标有非常大的偏移。\n演进路线2的好处，在于第一步非常的自然：\n 没有k8s的限制，因此不依赖基础设施，实施方便。毕竟，k8s普及度是个大问题； 在原有的侵入式框架的客户端SDK基础上，通过包裹一个proxy，重用原有SDK的能力，可以非常快速的得到一个基本可用的Sidecar； 除了多一个proxy外，没有引入太多的新概念和新 …","date":1543474800,"description":"本文根据敖小剑、龙轼在 Service Mesher Meetup 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-meetup-5-retrospect/","fuzzywordcount":10300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5031be4287bf1a7d7921bf5133ea414c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","publishdate":"2018-11-29T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","summary":"敖小剑，蚂蚁金服高级技术专家，十六年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher 社区联合创始人。 龙轼，阿里巴","tags":["Service Mesh"],"title":"Service Mesh 渐进式迁移方案 | Service Mesh Meetup 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","wordcount":10259},{"author":"鲁直","categories":"SOFAMesh","content":" 本文作者：黄挺，蚂蚁金服高级技术专家，蚂蚁金服分布式架构 SOFA 的开源负责人。目前在蚂蚁金服中间件团队负责应用框架与服务化相关的工作。 本文根据黄挺在 CNUTCon 全球运维大会的主题分享整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，我是来自于蚂蚁金服的黄挺，花名鲁直，目前在蚂蚁金服负责微服务团队，也是 SOFA 开源的负责人。来到这个场子的朋友们肯定都知道，Service Mesh 在过去一两年之中迅速成长为社区中非常热门的话题，几乎所有的大会中，都多多少少有一些关于 Service Mesh 的话题。在一个月之前，我的同事敖小剑老师在上海的 QCon 中也分享了蚂蚁金服在 Service Mesh 上的探索，包括在前面的场次中，来自华为的巨震老师也分享了华为在 Service Mesh 上的一些思考。在今天的分享中，我不会去花太多时间介绍什么是 Service Mesh，更多地聚焦在蚂蚁金服将 Service Mesh 用在解决多语言的问题上的一些实践，希望在场的各位可以从这些实践中有所收获。\n这个是我今天介绍的主要的内容，首先，我会大家简单介绍一下多语言在蚂蚁金服发展的一些情况，铺垫一下背景，交代各个语言在蚂蚁金服的使用情况，并且之前在多语言通信上面遇到了哪些问题。\n然后，我会给大家简单介绍下 SOFAMesh，SOFAMesh 是蚂蚁金服产出的 Service Mesh 的解决方案。\n接着我会介绍我们在 SOFAMesh 之上架构的多语言通信的方案以及在这个方案的实施过程中遇到的一些技术要点。\n蚂蚁金服多语言发展 不知道在场的同学有没有听说过 SOFA，SOFA 是蚂蚁金服大约 10 年前开始研发的一套分布式中间件，包括了微服务体系，分布式事务，消息中间件，数据访问代理等等组件，这套组件一直以来都是完全用 Java 来构建的，因此基于 SOFA 构建的 SOFA 应用也都是用 Java 写的，在蚂蚁金服，目前大概有接近 2000 个 SOFA 应用，顺带提一下，这套 SOFA 中间件目前已经部分开源在 Github 上面。从这个数据我们也可以显而易见地得出以下的结论，Java 在蚂蚁金服，至少在在线的应用上，占据了绝对主导的地位。\n随着无线技术的发展以及 NodeJS 技术的兴起，在 2013 年，蚂蚁金服开始引入了 NodeJS，研发了 EggJS，目前也已经在 Github 上开源，在蚂蚁金服，我们主要将 EggJS 作为服务于无线以及 PC 的 BFF 层来使用，后端的所有的微服务还都是用基于 Java 的 SOFA 来研发，EggJS 要调用后端的 SOFA 服务，并且对 PC 和无线端提供接口，必然就要遵守 Java 世界的 SOFA 之前定下的种种“规矩”，事实上，蚂蚁金服的 NodeJS 团队完全用 EggJS 适配了所有的 SOFA 中间件的客户端，保证在 EggJS 上，也可以使用所有的 SOFA 中间件，可以和之前基于 Java 研发的 SOFA 应用进行通信。但是，由于 Java 在蚂蚁中间件上的主导地位，导致 SOFA 中间件的某些特性的实现，完全依赖于 Java 特有的语言特性，因此，NodeJS 团队在追赶 SOFA 中间件的过程中，也非常的痛苦，在后面的例子中，我会有一些具体的例子，大家看了之后肯定会感同身受。\n再到最近几年，随着 AI 的兴起，在蚂蚁金服也越来越多地出现 CPP，Python 等系统，而由于 CPP 和 Python 等等语言，在蚂蚁金服并没有一个独立的基础设施团队去研发对应的中间件，因此，他们和基于 Java 的 SOFA 应用的互通就降级成了直接采用 HTTP 来通信，这种方式虽然也可以 Work，但是在通信基础之上的服务调用的能力却完全没有，和原本的 SOFA 的基础设施也完全没法连接在一起。\n基于以上的一些现状，可以看到我们在发展过程中的主要的两个问题，一个是基础设施上的重复投入的消耗，很多 SOFA 中间件的特性，除了用 Java 写了一遍之外，还得用 NodeJS 再写一遍。另一个是以 Java 为中心，以 Java 为中心其实在只有 Java 作为开发语言的时候并没有什么问题，但是当其他的语言需要和你进行通信的时候，就会出现巨大的问题，事实上，很多框架上的特性的研发同学在不经意之间，就直接就用了 Java 的语言特有的特性去进行研发，这种惯性和隐性的思维会对其他语言造成巨大的壁垒。\n基于以上的问题，我们希望能够产出一个方案，一方面，可以尽量做到一次实现，到处可用。另一方面，需要能够保证语言的中立性，最好是能够天然地就可以让框架或者中间件的研发的同学去在做架构设计以及编码的时候，考虑到需要支持多语言。\nSOFAMesh 其实在这之前，我们已经尝试在数据访问层去解决类似的多语言适配的问题，蚂蚁金服有一个 OceanBase 的数据库，当各个语言需要访问 OceanBase 数据库的时候，采用的就是一个本地的 Proxy，这个 Proxy 会负责 Fail Over，容灾等等场景，而对各个语言只要保证 SQL 上的兼容就可以了，这让我们意识到，Proxy 的模式可能是解决多语言的一个方式，然后，在业界就出现了 Service Mesh，如果只是从技术上讲，Service Mesh 的 Sidecar 本质上也就是一个 Proxy，只是每一个服务实例都加上一个 Sidecar，这些 Sidecar 组成了一个网络，在加上一个控制平面，大家把他叫做 Service Mesh。通过 Service Mesh，我们可以将大量原来需要在语言库中实现的特性下沉到 Sidecar 中，从而达到一次实现，到处可用的效果；另外，因为 Sidecar 本身不以 Library 的形式集成到特定语言实现的服务中，因此也就不会说某些关键特性采用特定语言的特性来实现，可以保证良好的中立性。\n看起来 Service Mesh 似乎是一个非常完美的解决方案，但是如果我们探寻一下 Service Mesh 的本质的话，就会发现 Service Mesh 并非完美解决方案，这种不完美主要是体现在 Service Mesh 本质上是一种抽象，它抽象了什么东西，它把原来的服务调用中的一些高可用的能力全部抽象到了基础设施层。在这张 PPT 中，我放了三张图片，都是一棵树，从左到右，越来越抽象，从图中也可以非常直观地看出来，从右到左，细节越来越丰富。不管是什么东西，抽象就意味着细节的丢失，丢失了细节，就意味着在能力上会有所欠缺，所以，在 Service Mesh 的方案下，虽然看起来我们可以通过将能力下层到基础设施层，但是一旦下层下去，某些方面的能力就会受损。\n因此，我们希望能够演化出这样一套多语言通信的方案，它能够以 Service Mesh 为基础，但是我们也会做适当地妥协去弥补因为上了 Service Mesh 之后的一些能力的缺失。首先我们希望有一个语言中立的高效的通信协议，每个语言都能够非常简单地理解这个协议，这个是在一个跨语言的 RPC 通信中避免不了的，无论是否采用 Service Mesh。然后， …","date":1542870000,"description":"本文根据黄挺在 CNUTCon 全球运维大会的主题分享整理，完整的分享 PPT 获取方式见文章底部。。","dir":"blog/sofa-mesh-cnutcon-2018/","fuzzywordcount":7000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5a750edaa8c6a9759fd5e3533dd3fa4d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","publishdate":"2018-11-22T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","summary":"本文作者：黄挺，蚂蚁金服高级技术专家，蚂蚁金服分布式架构 SOFA 的开源负责人。目前在蚂蚁金服中间件团队负责应用框架与服务化相关的工作。 本文根据黄挺","tags":["SOFAMesh"],"title":"蚂蚁金服 SOFAMesh 在多语言上的探索实践","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","wordcount":6910},{"author":"明不二","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》最后一篇，作者明不二，就职于华为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部完成，感谢所有参与的源码爱好者！\n 前言 在应用服务化架构中，RPC 框架是非常重要的基础组件。而在 RPC 框架当中，序列化（以及反序列化）又是必不可少的一环。因为序列化的性能对整体框架性能有比较大的影响，之前的文章中，我们已经详细剖析了 SOFARPC 各个核心功能模块的实现原理，想必大家已经很清楚 RPC 的调用流程。\n在整个 RPC 调用流程当中，序列化及反序列化起到了承上启下的作用。序列化时，RPC客户端把待调用的方法和参数对象转换为网络上可传输的字节序列，为进一步的编解码提供原料。反序列化时，把从网络上接收到且已经解码了的字节序列转换成对象，便于 RPC 服务端调用。\n本文将从序列化概述、序列化协议特性、序列化使用方法分类、SOFARPC 序列化的设计及实现、几种序列化协议对比等方面介绍及对比序列化及其在 SOFARPC 中的应用。\n序列化概述 RPC 调用通过网络传输相关的调用方法及参数，在这个网络传输过程中，内存中的对象是无法直接传输的，只有二进制字节才能在网络上传输。而为了实现调用对象在网络上的传输，必须通过序列化实现对象 -\u0026amp;gt; 字节的过程，以及反序列化实现字节 -\u0026amp;gt; 对象的过程。在网络协议模型中，序列化属于应用层协议的一部分。\n如下列定义：\n序列化：将数据结构或者对象转换成二进制串的过程。\n反序列化：将序列化过程中生成的二进制串转换成数据结构或者对象的过程。\n在上述定义中，二进制字节数组专指 Java 语言中的 byte[]。\n序列化协议特性 每种序列化协议都有其优点和缺点，在对一个序列化协议进行衡量评判时，通常由如下一些指标可以参考：\n 指标 说明 重要性 通用性 是否跨平台，社区如何 中高 可读 序列化格式是否可读 中低 易用性 是否简单易用 中高 性能 序列化后的大小和压缩 CPU消耗 中高 可扩展性 是在允许字段修改 高 安全性 是否存在一些无法修复的漏洞 高 以下逐个来详细说明：\n通用性 在通用性上，主要考察该序列化协议是否支持跨平台、跨语言的使用，同时兼顾考察业界的流行度及社区的活跃性。\n可读/易用性 在可读、易用性上面，主要考察该序列化协议序列化之后是否人眼可读，如 XML 和 JSON 就是人眼可读的序列化框架，这会大大提高调试的效率。同时，需要考察序列化框架所提供的 API 是否容易学习、调用。当然，在远程调用 的场景下，可读性不是一个重要因素。或者说，我们更多希望不可读。来保证一定的安全性。\n性能 性能指标，主要考虑序列化框架的时间复杂度和空间复杂度。\n序列化之后的数据一般都是用于存储或者网络传输，空间占用大小决定了传输的效率。序列化通常情况下要在原有的数据上加上描述字段，如果这个过程中引入的额外开销过大，则在大规模分布式系统中，很可能会造成巨大的额外空间开销。\n同时，为了提高系统的性能，是否耗费 CPU，解析和反解析二进制串的时间也是一个非常重要的指标。\n可扩展性 主要考虑当系统准备升级，需要对实体的属性进行变更，此时序列化协议能否快速支持，并且不会对原有的系统造成影响。如作为服务提供方的 API 接口入参中，增加了一个字段，是否一定要强制所有的客户端进行升级。这个会涉及到线上兼容性的问题。一般我们要求新增字段，在客户端尚未使用的情况下，不应该有序列化问题。\n安全性 需要考察序列化协议是否支持跨局域网之间的安全访问。是否存在一些安全漏洞。可以通过构造一些字节数组，使得服务端反序列化的时候，触发某些安全漏洞，执行一些系统调用，或者越权操作。\n序列化使用方式分类 按照序列化的使用方式，可以分为自描述型序列化以及基于中间格式型序列化。\n自描述型 所谓的自描述型，即在序列化的字节流里有着完整的对象类型信息和属性信息，可以在不依赖任何外界描述信息的前提下，只要拿到这个二进制流，就可以直接还原出原始对象。\n类似的系列化产品有：hessian、JSON、XML 等。\n例如，有如下一个对象 Person，Java 语言定义如下：\npackage com.sofa.test.Person; public class Person { private int age = 15; private String name = “sofa”; } 则使用 hessian 序列化后的字节流如下：\nM**com.sofa.test.PersonS**nameS**sofaS**ageI**b3 b2 b1 b0 z\n上面的*和b3 b2 b1 b0都表示不可打印的二进制。从上面内容可以看出，按照相应规定就能从二进制串中反序列化出对象来。因为这里面已经描述了类型，类型的字段名，以及对应的值，这样就可以直接反序列化了。\n基于中间描述型 一般这种类型的序列化主要用于跨语言当中，比如 Protobuf以及 thrift等等。在使用时都需要事先定义一个中间格式的文件（IDL 文件），然后根据不同语言的生成工具生成一个相应语言的可序列化类。以下是一个简单的 Proto的描述文件\nmessage SofaApp{ string appName = 1; repeated string authList = 2; repeated string serviceList = 3; } 然后当需要反序列化时，根据 IDL 文件及逆行相应的反序列化即可。格式是这样\n其中，图中的用户定义编号就是前面 proto中对每个字段定义的编号。\nSOFARPC 序列化的设计与实现 SOFARPC 支持及将要支持的序列化协议有：hessian、Protobuf、Json。\n序列化接口定义 在目前的 SOFARPC 5.4 分支中，已经支持的序列化协议有 hessian 和 Protobuf。两个序列化实现类继承了 AbstractSerializer抽象类，该抽象类又实现了如下的 Serializer接口：\n/** * 序列化器接口 * * @author \u0026amp;lt;a href=mailto:zhanggeng.zg@antfin.com\u0026amp;gt;GengZhang\u0026amp;lt;/a\u0026amp;gt; */ @Extensible(coded = true) @Unstable public interface Serializer { /** * 序列化 * * @param object 对象 * @param context 上下文 * @return 序列化后的对象 * @throws SofaRpcException 序列化异常 */ public AbstractByteBuf encode(Object object, Map\u0026amp;lt;String, …","date":1541055600,"description":"本文为《剖析 | SOFARPC 框架》最后一篇，作者明不二，就职于华为。","dir":"blog/sofa-rpc-serialization-comparison/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f0a5fd044fa69071a7251518ea7d69f6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-serialization-comparison/","publishdate":"2018-11-01T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-serialization-comparison/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 序列化比较","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-serialization-comparison/","wordcount":3267},{"author":"鸥波","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十二篇，作者鸥波。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 随着 TIOBE 10月份的编程语言排行 的发布，C++重回第三的位置，新兴的 Swift 和 Go 表现出强劲的上升趋势。与此同时，虽然目前 Java 的领头位置尚未出现有力挑战，我们希望能够在基础设施的建设上预留跨语言的可扩展设计。同时，跨语言的挑战也是工程实际面临的现状，蚂蚁内部如 AI、IoT，算法等缺少 JVM 原生支持的领域，往往不可避免地需要涉及到跨语言调用的问题。\n本文将为大家介绍 基于 SOFARPC 的微服务应用在面临跨语言调用时的方案和实现。\n总体设计 经过前面几篇对 SOFARPC 的 BOLT 协议和序列化这些的介绍，相信大家已经对 RPC 有了一些自己的理解，提到跨语言，我们会首先想到其他语言调用 Java，Java 调用其他语言，那么这里的跨，体现在代码上，到底跨在哪里？\n从跨语言的实现上来说，主要解决两个方面的问题：\n 跨语言的通讯协议和序列化协议\n 跨语言服务发现\n 另外从跨语言的落地来说，还得解决一个平滑兼容的问题。\n业界常见的做法是一般是通过 DNS 和 HTTP 来解决跨语言的问题，但是在内部已经有完善技术栈体系的情况下，直接切换一个新的方案显然是不合适的，所以蚂蚁内部是在已有的技术体系基础上进行改进。\n蚂蚁内部使用的通讯协议是Bolt，序列化协议是Hessian。我们知道，服务端和客户端在请求和返回之间携带的结构化的业务数据，需要在传输到达对端后，被本地的语言能够易于解析消费。由于语言本身特性的差异，同一对象的在序列化和反序列化的转换后，结构可能有差异，但是需要保证其转换操作是可逆的。以上这点Hessian做的不是很好，其跨语言的兼容性不能满足跨语言的需求，所以另外一个可行的方案就是就是选择其它基于 IDL 的序列化协议，例如Protobuf。\n现成的服务注册中心一般都有一些多语言解决方案，像Zookeeper、SOFARegistry、Consul、etcd等都有多语言客户端，所以服务发现这块问题不算太大。\n例如下面就是一个基于注册中心 + Bolt 协议 + Protobuf 序列化的设计图。\n通讯协议和序列化协议 通讯协议只要跨语言各方约定清楚，大家安装约定实现即可，而序列化协议则需要较多的考量。\n序列化的协议选择列出一些考虑要点：\n 是否采用具备自我描述能力的序列化方案，如不需要借助一些 schema 或者接口描述文件。\n 是否为语言无关的，包括脚本语言在内。\n 是否压缩比例足够小，满足网络传输场景的要求。\n 是否序列化和反序列化的性能均足够优秀。\n 是否向前/向后兼容，能够处理传输对象的新增属性在服务端和客户端版本不一致的情况。\n 是否支持加密、签名、压缩以及扩展的上下文。\n JSON Over HTTP 首先，说到跨语言，序列化支持，肯定有同学会问，为什么不直接通过 Http的Json来搞定呢？\n虽然得益于JSON和HTTP在各个语言的广泛支持，在多语言场景下改造支持非常便捷，能够低成本的解决网络通讯和序列化的问题。服务发现的过程则可以使用最简单的固定URL（协议+域名+端口+路径）的形式，负载均衡依赖于F5或者LVS等实现。\n但是这个方案的有明显的局限性：\n HTTP 作为无状态的应用层协议，在性能上相比基于传输层协议（TCP）的方案处于劣势。HTTP/1.1后可以通过设置keep-alive使用长连接，可以一定程度上规避建立连接的时间损耗；然而最大的问题是，客户端线程采用了 request-response 的模式，在发送了 request 之后被阻塞，直到拿到 response 之后才能继续发送。这一问题直到 HTTP/2.0 才被解决。\n JSON 是基于明文的序列化，较二进制的序列化方案，其序列化的结果可读性强，但是压缩率和性能仍有差距，这种对于互联网高并发业务场景下，意味着硬件成本的提升。\n 对于网络变化的响应。订阅端处理不够强大。\n Hessian Over BOLT 在否决了上一个方案后，我们继续看，蚂蚁内部，最开始的时候，SOFARPC 还没有支持 Protobuf 作为序列化方式，当时为了跨语言，NodeJs的同学已经在此基础上，用 js 重写了一个 hessian 的版本，完成了序列化。也已经在线上平稳运行。但是当我们要扩展给其他语言的时候，重写 hessian 的成本太高。而且 Java语言提供的接口和参数信息，其他语言也需要自己理解一遍，对应地转换成自己的语言对象。因此该方案在特定场景下是可行的。但不具备推广至其他语言的优势。\nNode的实现版本可以参考：https://github.com/alipay/sofa-rpc-node\nProtobuf Over BOLT Protobuf 基于IDL，本身具备平台无关、跨语言的特性，是一个理想的序列化方案。但是需要先编写proto文件，结构化地描述传输的业务对象，并生成中间代码。\n由于要重点介绍一下这种方案，因此再次回顾一下SOFABolt的协议规范部分，便于后面的解释。\nRequest command protocol for v1 0 1 2 4 6 8 10 12 14 16 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ |proto| type| cmdcode |ver2 | requestId |codec| timeout | classLen | +-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+ |headerLen | contentLen | ... ... | +-----------+-----------+-----------+ + | className + header + content bytes | + + | ... ... | +-----------------------------------------------------------------------------------------------+ codec: code for codec 序列化,hessian 是1,pb 是11,java 是2 Response command protocol for v1 0 1 2 3 4 6 8 10 12 14 16 …","date":1540969200,"description":"本文为《剖析 | SOFARPC 框架》第十二篇，作者鸥波。","dir":"blog/sofa-rpc-cross-language-support/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"28621f1b90e6ce8edf1b3e446fa5be23","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-cross-language-support/","publishdate":"2018-10-31T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-cross-language-support/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之SOFARPC 跨语言支持剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-cross-language-support/","wordcount":3741},{"author":"敏古","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十一篇，作者敏古。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。 SOFARPC：https://github.com/sofastack/sofa-rpc\n 1、前言 在 SOFABoot 环境下，SOFARPC 提供三种方式给开发人员发布和引用 RPC 服务：\n XML 方式（配置）\n Annotation 方式（注解）\n 编程 API 方式（动态）\n 编程 API 方式与Spring 的 ApplicationContextAware 类似。XML的方式依赖于在xml中引入 SOFA 命名空间，利用 Bean 的生命周期管理，进行 Bean 的注入。相比这两种方式，通过 Annotation 方式发布 JVM 服务更加灵活方便，只需要在实现类上加 @SofaService、@SofaRefernce 注解即可进行服务的发布和引用。本文针对 SOFARPC 在注解的支持和使用分原理、源码两部分进行一一介绍。\n2、原理介绍 2.1、注解是什么 注解又称为元数据，可以对代码中添加信息，这是一种形式化的方法，可以在稍后的某个时刻非常方便地使用这些数据。这个时刻可能是编译时，也可能是运行时。\n注解是JDK1.5版本开始引入的一个特性，用于对代码进行说明，可以对包、类、接口、字段、方法参数、局部变量等进行注解。注解的本质就是一个继承了 Annotation 接口的接口。一个注解准确意义上来说，只不过是一种特殊的注释而已，如果没有解析它的代码，它可能连注释都不如。\n一般常用的注解可以分为三类：\n Java自带的标准注解，包括@Override（标明重写某个方法）、@Deprecated（标明某个类或方法过时）和@SuppressWarnings（标明要忽略的警告）。\n 元注解，元注解是用于定义注解的注解。\n 自定义注解，可以根据自己的需求定义注解。\n 2.2、元注解 元注解是用于修饰注解的注解，通常用在注解的定义上。JAVA 中有以下几个元注解：\n @Target：注解的作用目标，也就是指明，你的注解到底是用来修饰方法的？修饰类的？还是用来修饰字段属性的，有以下几种类型： ElementType.TYPE：允许被修饰的注解作用在类、接口和枚举上 ElementType.FIELD：允许作用在属性字段上 ElementType.METHOD：允许作用在方法上 ElementType.PARAMETER：允许作用在方法参数上 ElementType.CONSTRUCTOR：允许作用在构造器上 ElementType.LOCAL_VARIABLE：允许作用在本地局部变量上 ElementType.ANNOTATION_TYPE：允许作用在注解上 ElementType.PACKAGE：允许作用在包上 @Retention：指定了被修饰的注解的生命周期，分以下三种类型： RetentionPolicy.SOURCE：该注解只保留在一个源文件当中，当编译器将源文件编译成class文件时，它不会将源文件中定义的注解保留在class文件中。 RetentionPolicy.CLASS：该注解只保留在一个class文件当中，当加载class文件到内存时，虚拟机会将注解去掉，从而在程序中不能访问。 RetentionPolicy.RUNTIME：该注解在程序运行期间都会存在内存当中。此时，我们可以通过反射来获得定义在某个类上的所有注解。 @Documented：当我们执行 JavaDoc 文档打包时会被保存进 doc 文档，反之将在打包时丢弃。\n @Inherited：解修饰的注解是具有可继承性的，也就说我们的注解修饰了一个类，而该类的子类将自动继承父类的该注解。\n 以 @Override 为例子：\n当编译器检测到某个方法被修饰了 @Override 注解，编译器就会检查当前方法的方法签名是否真正重写了父类的某个方法，也就是比较父类中是否具有一个同样的方法签名。\n@Override 仅被编译器可知，编译器在对 java 文件进行编译成字节码的过程中，一旦检测到某个方法上被修饰了该注解，就会去匹对父类中是否具有一个同样方法签名的函数，否则不能通过编译。\n2.3、注解解析方式 解析一个类或者方法的注解通常有两种形式，一种是编译期直接的扫描，一种是运行期反射。\n2.3.1、编译器的扫描 指的是编译器在对 java 代码编译字节码的过程中会检测到某个类或者方法被一些注解修饰，这时它就会对于这些注解进行某些处理。典型的就是注解 @Override，一旦编译器检测到某个方法被修饰了 @Override 注解，编译器就会检查当前方法的方法签名是否真正重写了父类的某个方法，也就是比较父类中是否具有一个同样的方法签名。\n这一种情况只适用于那些编译器已经熟知的注解类，比如 JDK 内置的几个注解，而你自定义的注解，编译器是不知道你这个注解的作用的，\n2.3.1、运行期反射 首先对虚拟机的几个注解相关的属性表进行介绍，先大体了解注解在字节码文件中是如何存储的。虚拟机规范定义了一系列和注解相关的属性表，也就是说，无论是字段、方法或是类本身，如果被注解修饰了，就可以被写进字节码文件。属性表有以下几种：\n RuntimeVisibleAnnotations：运行时可见的注解 RuntimeInVisibleAnnotations：运行时不可见的注解 RuntimeVisibleParameterAnnotations：运行时可见的方法参数注解 RuntimeInVisibleParameterAnnotations：运行时不可见的方法参数注解 AnnotationDefault：注解类元素的默认值 java.lang.reflect.AnnotatedElement 接口是所有程序元素（Class、Method和Constructor）的父接口，程序通过反射获取了某个类的 AnnotatedElemen t对象之后，利用 Java 的反射机获取程序代码中的注解，然后根据预先设定的处理规则解析处理相关注解以达到主机本身设定的功能目标。\n本质上来说，反射机制就是注解使用的核心，程序可以调用该对象的以下方法来访问 Annotation信息：\n getAnnotation：返回指定的注解 isAnnotationPresent：判定当前元素是否被指定注解修饰 getAnnotations：返回所有的注解 getDeclaredAnnotation：返回本元素的指定注解 getDeclaredAnnotations：返回本元素的所有注解，不包含父类继承而来的 3、源码解析 3.1、 …","date":1540450800,"description":"本文为《剖析 | SOFARPC 框架》第十一篇，作者敏古。","dir":"blog/sofa-rpc-annotation-support/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e68884b2feaf90e26f191de0ef49e945","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-annotation-support/","publishdate":"2018-10-25T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-rpc-annotation-support/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-annotation-support/","wordcount":4359},{"author":"敖小剑","categories":"SOFAMesh","content":" 背景 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，这两个是Istio/Envoy中的一等公民。而基于HTTP/1.1的REST和基于HTTP/2的gRPC，一个是目前社区最主流的通讯协议，一个是未来的主流，google的宠儿，CNCF御用的RPC方案，这两个组成了目前Istio和Envoy（乃至CNCF所有项目）的黄金组合。\n而我们SOFAMesh，在第一时间就遇到和Istio/Envoy不同的情况，我们需要支持REST和gRPC之外的众多协议：\n SOFARPC：这是蚂蚁金服大量使用的RPC协议(已开源) HSF RPC：这是阿里集团内部大量使用的RPC协议(未开源) Dubbo RPC: 这是社区广泛使用的RPC协议(已开源) 其他私有协议：在过去几个月间，我们收到需求，期望在SOFAMesh上运行其他TCP协议，部分是私有协议 为此，我们需要考虑在SOFAMesh和SOFAMosn中增加这些通讯协议的支持，尤其是要可以让我们的客户非常方便的扩展支持各种私有TCP协议：\n实现分析 我们来大体看一下，在SOFAMesh/Istio中要新增一个通讯协议需要有哪些工作：\n protocol decoder：负责解析协议，读取协议字段 protocol encoder：负责生成请求报文，注意通常会有改动，比如修改某些header 在pilot中需要为新协议生成 Virtual Host 等配置，有 inbound 和 outbound 两份，分别下发到Sidecar 在Sidecar中，根据下发的 Virtual Host 等配置，进行请求匹配，以决定请求该转发到何处 备注：实际下发的配置不止 Virtual Host 配置，为了简单起见，我们仅以 Virtual Host 为例做讲解。\n 其中，protocol encoder和protocol decoder是容易理解的，对于新的通讯协议肯定需要有协议编解码层面的工作必须要完成，这块有工作量是很自然的。\n我们来看看第三块的工作量是什么，inbound 和 outbound 的Virtual Host配置示例如下：\noutbound 配置中，注意 domains 字段是各种域名和ClusterIP，而 routes 中，match是通过prefix来匹配。我们结合HTTP/1.1，domains字段是用来和请求的Host header进行域名匹配的，比如 Host: istio-telemetry，这决定了哪些请求是要转发到 istio-telemetry 这个服务的。routes的match用来进行路由匹配的，通过HTTP请求的path进行匹配。\ninbound 配置类似，只是inbound更简单，domains匹配*就可以。\n从上面的例子中可以看到，Istio和Envoy的设计有非常浓重的HTTP协议的味道，各种语义都是和HTTP直接相关。而当我们进行TCP协议的转发时，就需要将请求的协议字段进行映射，映射到HTTP的相应语义。\n比如，最基本的Destination，原始语义是请求的目的地，在前面的文章中我们指出过这是请求转发最关键的字段。在HTTP协议中，通常是通过Host header和Path表示，对于REST而言还有重要的Method字段。\n下面的格式是其他各种协议对这个Destination原始语义的实际实现方式：\n 协议 实现 原始语义 请求的目的地(Destination) HTTP/1.1 Host header，Method，Path HTTP/2 Header帧中的伪header :authority，:path和:method Bolt协议 header map中key为”service”的字段 HSF协议 协议头中的服务接口名和服务方法名 Dubbo协议 data字段（payload）中的path/method 这些通讯协议在下发规则和进行请求匹配时，就需要进行协调：\n 定义好 Virtual Host 配置中的 domains 字段和 route 中的 match 用到的字段在当前通讯协议中的实际语义 在 protocol encoder 中读取请求的协议字段，和上面的字段对应 然后进行请求路由规则匹配（参照HTTP/1.1中的domain和route match的匹配） 而这些都是需要以代码的方式进行实现，以满足新通讯协议的要求。正规的做法，是每次新增一个通讯协议就将上述的工作内容重复一遍。这会直接导致大量的高度类似的重复代码。\nx-protocol的实现 在上述需要在协议扩展时修改的四个内容中，有一块是特别的：生成 Virtual Host 配置的工作是在Pilot中实现的，而其他三个是在Sidecar （Envoy或MOSN）中。考虑到 protocol encoder 和 protocol decoder 的工作是必不可少的，必然会修改Sidecar来增加实现代码，因此简化开发的第一个想法就是：能不能做到不修改Pilot？\n基本思路就是固定好原始语义，避免每个通讯协议都映射一遍。从前面我们列出来的各个协议的映射情况看，对于RPC协议而言，一般目的地信息都是服务名(有些是接口名)+方法名居多，因此可以考虑直接将服务名和方法名固定下来：\n RPC协议在 Virtual Host 配置中就固定为服务名对应 domains 字段，方法名对应 route 中的 match 用到的字段，这样只要修改一次然后各个RPC协议公用此配置，以后就不用再重复修改Pilot。 protocol encoder 在解析通讯协议完成之后，就直接将协议中对应服务名和方法名的字段提取出来，后面的匹配处理过程就可以公用一套通用实现，这样路由匹配这块也可以不用在重复开发。 因此，在x-protocol中，如果需要引入一个新的通讯协议，需要的工作内容只有必不可少的protocol encoder 和 protocol decoder，和实现以下几个接口：\n总结 X-protocol 在支持新通讯协议上的做法并无新奇之处，只是由于需求特殊有众多通讯协议需要支持，在开发时发现大量重复工作，因此我们选择了一条可以让后面更舒服一点的道路。\n目前这个方案在SOFAMesh中采用，我们将进一步检验实际效果，也会和合作的小伙伴时验证，看他们在自行扩展新协议时是否足够理想。这个方案理论上应该可以同样适用于Istio、Envoy体系，随着社区对Istio的接受程度的提高，在Istio上支持各种TCP通讯协议的需求会越来越多，有理由相信Istio后续可能也会出现类似的方案。毕竟，每次都改一大堆类似的东西，不是一个好做法。\n系列文章 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发 ","date":1539500400,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，本文介绍的是TCP协议扩展。","dir":"blog/sofa-mesh-x-protocol-tcp-protocol-extension/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2c2876e9ae6a7a2b374b0d04cc42e6a4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","publishdate":"2018-10-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","summary":"背景 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，这两个是Istio/Envoy中的一等公民。而","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（3）——TCP协议扩展","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","wordcount":2488},{"author":"敖小剑","categories":"SOFAMesh","content":" 前言 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，而我们SOFAMesh，则需要支持以下几个RPC协议：\n SOFARPC：这是蚂蚁金服大量使用的RPC协议（已开源） HSF RPC：这是阿里集团内部大量使用的RPC协议（未开源） Dubbo RPC: 这是社区广泛使用的RPC协议（已开源） 更适合的平衡点：性能和功能 对于服务间通讯解决方案，性能永远是一个值得关注的点。而SOFAMesh在项目启动时就明确要求在性能上要有更高的追求，为此，我们不得不在Istio标准实现之外寻求可以获取更高性能的方式，比如支持各种RPC协议。\n期间有两个发现：\n Istio在处理所有的请求转发如REST/gRPC时，会解码整个请求的header信息，拿到各种数据，提取为Attribute，然后以此为基础，提供各种丰富的功能，典型如Content Based Routing。 而在测试中，我们发现：解码请求协议的header部分，对CPU消耗较大，直接影响性能。 因此，我们有了一个很简单的想法：是不是可以在转发时，不开启部分功能，以此换取转发过程中的更少更快的解码消耗？毕竟，不是每个服务都需要用到Content Based Routing这样的高级特性，大部分服务只使用 Version Based Routing，尤其是使用RPC通讯协议的服务，没有HTTP那么表现力丰富的header，对Content Based Routing的需求要低很多。\n此外，对于部分对性能有极高追求的服务，不开启高级特性而换取更高的性能，也是一种满足性能要求的折中方案。考虑到系统中总存在个别服务对性能非常敏感，我们觉得Service Mesh提供一种性能可以接近直连的方案会是一个有益的补充。为了满足这些特例而不至于因此整体否决Service Mesh方案，我们需要在Service Mesh的大框架下提供一个折中方案。\n请求转发 在我们进一步深入前，我们先来探讨一下实现请求转发的技术细节。\n有一个关键问题：当Envoy/SOFA MOSN这样的代理程序，接收到来自客户端的TCP请求时，需要获得哪些信息，才可以正确的转发请求到上游的服务器端？\n最关键的信息：destination 首先，毫无疑问的，必须拿到destination/目的地，也就是客户端请求必须通过某种方式明确的告之代理该请求的destination，这样代理程序才能根据这个destionation去找到正确的目标服务器，然后才有后续的连接目标服务器和转发请求等操作。\nDestination信息的表述形式可能有：\n1. IP地址\n可能是服务器端实例实际工作的IP地址和端口，也可能是某种转发机制，如Nginx/HAProxy等反向代理的地址或者Kubernetes中的ClusterIP。\n举例：“192.168.1.1:8080”是实际IP地址和端口，“10.2.0.100:80”是ngxin反向代理地址，“172.168.1.105:80”是Kubernetes的ClusterIP。\n2. 目标服务的标识符\n可用于名字查找，如服务名，可能带有各种前缀后缀。然后通过名字查找/服务发现等方式，得到地址列表（通常是IP地址+端口形式）。\n举例：“userservice”是标准服务名， “com.alipay/userservice”是加了域名前缀的服务名， “service.default.svc.cluster.local”是k8s下完整的全限定名。\nDestination信息在请求报文中的携带方式有：\n1. 通过通讯协议传递\n这是最常见的形式，标准做法是通过header头，典型如HTTP/1.1下一般使用 host header，举例如“Host: userservice”。HTTP/2下，类似的使用“:authority” header。\n对于非HTTP协议，通常也会有类似的设计，通过协议中某些字段来承载目标地址信息，只是不同协议中这个字段的名字各有不同。如SOFARPC，HSF等。\n有些通讯协议，可能会将这个信息存放在payload中，比如后面我们会介绍到的dubbo协议，导致需要反序列化payload之后才能拿到这个重要信息。\n2. 通过TCP协议传递\n这是一种非常特殊的方式，通过在TCP option传递，上一节中我们介绍Istio DNS寻址时已经详细介绍过了。\nTCP拆包 如何从请求的通讯协议中获取destination？这涉及到具体通讯协议的解码，其中第一个要解决的问题就是如何在连续的TCP报文中将每个请求内容拆分开，这里就涉及到经典的TCP沾包、拆包问题。\n转发请求时，由于涉及到负载均衡，我们需要将请求发送给多个服务器端实例。因此，有一个非常明确的要求：就是必须以单个请求为单位进行转发。即单个请求必须完整的转发给某台服务器端实例，负载均衡需要以请求为单位，不能将一个请求的多个报文包分别转发到不同的服务器端实例。所以，拆包是请求转发的必备基础。\n由于篇幅和主题限制，我们不在这里展开TCP沾包、拆包的原理。后面针对每个具体的通讯协议进行分析时再具体看各个协议的解决方案。\n多路复用的关键参数：RequestId RequestId用来关联request和对应的response，请求报文中携带一个唯一的id值，应答报文中原值返回，以便在处理response时可以找到对应的request。当然在不同协议中，这个参数的名字可能不同（如streamid等）。\n严格说，RequestId对于请求转发是可选的，也有很多通讯协议不提供支持，比如经典的HTTP1.1就没有支持。但是如果有这个参数，则可以实现多路复用，从而可以大幅度提高TCP连接的使用效率，避免出现大量连接。稍微新一点的通讯协议，基本都会原生支持这个特性，比如SOFARPC、Dubbo、HSF，还有HTTP/2就直接內建了多路复用的支持。\nHTTP/1.1不支持多路复用（http1.1有提过支持幂等方法的pipeline机制但是未能普及），用的是经典的ping-pong模式：在请求发送之后，必须独占当前连接，等待服务器端给出这个请求的应答，然后才能释放连接。因此HTTP/1.1下，并发多个请求就必须采用多连接，为了提升性能通常会使用长连接+连接池的设计。而如果有了requestid和多路复用的支持，客户端和Mesh之间理论上就可以只用一条连接（实践中可能会选择建立多条）来支持并发请求：\n而Mesh与服务器（也可能是对端的Mesh）之间，也同样可以受益于多路复用技术，来自不同客户端而去往同一个目的地的请求可以混杂在同一条连接上发送。通过RequestId的关联，Mesh可以正确将reponse发送到请求来自的客户端。\n由于篇幅和主题限制，我们不在这里展开多路复用的原理。后面针对每个具体的通讯协议进行分析时再具体看各个协议的支持情况。\n请求转发参数总结 上面的分析中，我们可以总结到，对于Sidecar，要正确转发请求：\n 必须获取到destination信息，得到转发的目的地，才能进行服务发现类的寻址 必须要能够正确的拆包，然后以请求为单位进行转发，这是负载均衡的基 …","date":1539154800,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，本文介绍的是快速解码转发方案。","dir":"blog/sofa-mesh-x-protocol-rapid-decode-forward/","fuzzywordcount":6900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"37ad5c3f997c173a4ceb60cc9dfd0532","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","summary":"前言 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，而我们SOFAMesh，则需要支持以下几个RP","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","wordcount":6856},{"author":"米麒麟","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第九篇，作者米麒麟，目前就职于陆金所。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕，文末提供了已完成的文章目录。\n 前言 众所周知，在微服务架构下面，当应用需要进行新功能升级发布，或者异常关闭重启的时候，我们会对应用的进程进行关闭，而在关闭之前，我们希望做一些诸如关闭数据库连接，等待处理任务完成等操作，这个就涉及到我们本文中的优雅关闭功能。假如应用没有支持优雅停机，则会带来譬如数据丢失，交易中断、文件损坏以及服务未下线等情况。\n微服务的优雅停机需要遵循\u0026amp;rdquo;注销发布服务 → 通知注销服务 → 更新服务清单 → 开启请求屏蔽 → 调用销毁业务服务 → 检查所有请求是否完成 → 超时强制停机\u0026amp;rdquo;应用服务停机流程。\nSOFARPC 提供服务端/客户端优雅关闭功能特性，用来解决 kill PID，应用意外自动退出譬如 System.exit() 退出 JVM，使用脚本或命令方式停止应用等使用场景，避免服务版本迭代上线人工干预的工作量，提高微服务架构的服务高可靠性。\n本文将从进程的优雅关闭，SOFARPC 应用服务优雅关闭流程，Netty 的优雅停机等方面出发详细剖析 。\n进程优雅关闭 Kill 结束进程 在 Linux上，kill 命令发送指定的信号到相应进程，不指定信号则默认发送 SIGTERM(15) 终止指定进程。如果无法终止，可以发送 SIGKILL(9) 来强制结束进程。kill 命令信号共有64个信号值，其中常用的是：\n2(SIGINT：中断，Ctrl+C)。\n15(SIGTERM：终止，默认值)。\n9(SIGKILL：强制终止)。\n这里我们重点说一下15和9的情况。\nkill PID/kill -15 PID 命令系统发送 SIGTERM 进程信号给响应的应用程序，当应用程序接收到 SIGTERM 信号，可以进行释放相应资源后再停止，此时程序可能仍然继续运行。\n而kill -9 PID 命令没有给进程遗留善后处理的条件。应用程序将会被直接终止。\n对微服务应用而言其效果等同于突然断电，强行终止可能会导致如下几方面问题：\n 缓存数据尚未持久化到磁盘，导致数据丢失；\n 文件写操作正在进行未更新完成，突然退出进程导致文件损坏；\n 线程消息队列尚有接收到的请求消息，未能及时处理，导致请求消息丢失；\n 数据库事务提交，服务端提供给客户端请求响应，消息尚在通信线程发送队列，进程强制退出导致客户端无法接收到响应，此时发起超时重试带来重复更新。\n 所以支持优雅关闭的前提是关闭的时候，不能被直接 通过发送信号为9的 Kill 来强制结束。当然，其实我们也可以对外统一暴露应用程序管理的 API 来进行控制。本文暂时不做讨论。\nJava 优雅关闭 当应用程序收到信号为15的关闭命令时，可以进行相应的响应，Java 程序的优雅停机通常通过注册 JDK 的 ShutdownHook 来实现，当应用系统接收到退出指令，首先 JVM 标记系统当前处于退出状态，不再接收新的消息，然后逐步处理推积的消息，接着调用资源回收接口进行资源销毁，例如内存清理、对象销毁等，最后各线程退出业务逻辑执行。\n优雅停机需要超时控制机制，即到达超时时间仍然尚未完成退出前资源回收等操作，则通过停机脚本调用kill-9 PID命令强制退出进程。\n其中 JVM 优雅关闭的流程主要的阶段如下图所示：\n如图所示，Java进程优雅退出流程包括如下五个步骤：\n 应用进程启动，初始化 Signal 实例；\n 根据操作系统类型，获取指定进程信号；\n 实现 SignalHandler 接口，实例化并注册到 Signal，当 Java 进程接收到譬如 kill -12 或者 Ctrl+C 命令信号回调其 handle() 方法；\n SignalHandler 的 handle 回调接口初始化 ShutdownHook 线程，并将其注册到 Runtime 的 ShutdownHook。\n Java 进程接收到终止进程信号，调用 Runtime 的exit() 方法退出 JVM 虚拟机，自动检测用户是否注册ShutdownHook 任务，如果有则触发 ShutdownHook 线程执行自定义资源释放等操作。\n SOFARPC 优雅关闭 在进程可以进行优雅关闭后，SOFARPC 如何实现优雅关闭呢？首先 SOFARPC 对于所有可以被优雅关闭的资源设计com.alipay.sofa.rpc.base.Destroyable接口，通过向 JVM 的 ShutdownHook 注册来对这些可被销毁的资源进行优雅关闭，支持销毁前和销毁后操作。\n这里包括两部分：\n 作为服务端注册 JDK 的 ShutdownHook 执行取消服务注册、关闭服务端口等动作实现；\n 作为客户端通过实现 DestroyHook 接口逐步处理正在调用的请求关闭服务调用。\n 总体设计 运行时上下文注册 JDK 的 ShutdownHook 执行销毁 SOFARPC 运行相关环境实现类似发布平台/用户执行kill PID 优雅停机。运行时上下文 RpcRuntimeContext 静态初始化块注册 ShutdownHook 函数：\nstatic { ... // 增加jvm关闭事件 if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } } 注册本身很简单，重要的是 destroy 方法实际上做的事情非常多。按照先后顺序，大致包含如下几个部分。\nRpcRuntimeContext 销毁服务优雅关闭完整流程：\n 设置 RPC 框架运行状态修改为正在关闭，表示当前线程不再处理 RPC 服务请求；\n 遍历运行时上下文关闭资源的销毁钩子，进行注册销毁器清理资源前期准备工作；\n 获取发布的服务配置反注册服务提供者，向指定注册中心批量执行取消服务注册；\n 检查当前服务端连接和队列任务，先把队列任务处理完毕，再缓慢关闭启动端口；\n 关闭发布的服务，到注册中心取消服务发布，取消将处理器注册到服务端，清除服务发布配 …","date":1539154800,"description":"本文为《剖析 | SOFARPC 框架》第九篇，作者米麒麟，目前就职于陆金所。","dir":"blog/sofa-rpc-graceful-exit/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6a1f6847a5ecf97e90a3a06c36f39246","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-graceful-exit/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-graceful-exit/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 优雅关闭剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-graceful-exit/","wordcount":3972},{"author":"明不二","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十篇，作者明不二，就职于华为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 RPC 框架需要创造一种调用远程服务如同调用本地般的体验，因此在实现一个基于 RPC 框架的微服务架构的系统时，服务消费者（客户端）往往只需要知道服务端提供了哪些接口和方法，并不需要知道服务具体由哪些 IP 在提供。RPC 框架本身的服务发现和路由寻址功能解决了如何知道目标地址的问题，该过程对于 RPC 客户端调用方来说应该是完全透明的。\n在这个过程中，RPC 框架需要接入注册中心来完成服务发现和路由寻址的功能。同时，在应用大规模请求时，微服务系统还需要对请求服务集群化，同时通过负载均衡来达到降低访问压力的效果。\n本文我们会先介绍一下注册中心，然后介绍一下 SOFRPC 中的几种路由，最后会介绍一下负载均衡的几种比较。\n注册中心支持 首先我们简要介绍一下注册中心的原理。\n服务端推送地址给注册中心，注册中心将地址进行合并后，推送给客户端。\n其中，注册中心的场景依赖于各类注册中心的实现。在这里，SOFARPC 提供了注册中心的抽象类 Registry，该抽象类提供了注册中心的配置、启动、注册、反注册、订阅等方法。客户端在接入过程中，可以通过配置来激活 Zookeeper、Consul、local 等注册中心注册进启动类中，当请求到来时，可以通过注册中心进行相应的路由。\n注册中心的抽象类如下：\n在这个接口的基础上，目前内置实现了几种注册中心，包括即将合并的。\nLocal注册中心(Local) Local 注册中心是 SOFARPC 自己实现的一个本地注册中心，该注册中心的实现主要由类 LocalRegistry提供，可以调用其 register(ProviderConfig config) 方法实现服务的注册，主要是文件的读写。\n实现原理很简单，通过在本地注册文件来保存服务的发布和订阅信息。\nZookeeper注册中心(Zookeeper) Zookeeper 接入 SOFARPC 的实现类为 ZookeeperRegistry。目前是 SOFARPC 中默认的注册中心实现。也是大多数情况下，可以方便使用的。\nZookeeper 是一个分布式协调服务，用于维护配置信息、命名、提供分布式同步功能以及提供组服务等。Zookeeper 提供了服务注册与发现的解决方案，提供了简单的 API，可以让集成者简洁调用。\n当要发布一个 SOFARPC 服务时，首先需要在 zookeeper 中注册服务提供者的相关信息，包括：该服务接口隶属于哪个系统、服务的 IP 以及端口号、服务的请求 URL 和服务的权重等等。zookeeper 在这个过程中，注意负责对 SOFARPC 中的服务信息进行中心存储，同时负责把服务注册信息的更新及时通知到服务消费者。\n作为服务调用者，SOFARPC 调用端在调用时，若走的路由链路中有注册中心，则会从注册中心中获取到服务注册的相关信息，然后在调用时会根据负载均衡策略来发送请求。\nConsul注册中心(Consul) Consul 注册中心与 SOFARPC 之间的对接主要依赖于 ConsulRegistry类。\n该注册中心在功能表现上与 zookeeper 看起来一致。对比起 Zookeeper 来，Consul 支持多数据中心，同时支持 http 和 dns 等接口，有着多语言的能力。\n其他注册中心 目前已经在开发中的有 Nacos，SOFAMesh 等。也可以根据自己的场景，进行方便的扩展。\n路由设计 路由原理和设计 在阅读本部分之前，请大家注意：路由是为了选中一组地址。\nSOFARPC 通过对各类注册中心的支持，实现了服务发现、路由寻址的功能。访问客户端时，请求的路由可以由以下一些实现类实现：DirectUrlRouter、RegistryRouter、CustomRouter，上述三个路由实现类分别对应了直接地址路由（不需要经过注册中心直接路由直连到某个地址）、注册中心路由、以及客户自定义路由等。路由从 AddressHolder 获取到地址，同时通过各种负载均衡算法进行负载均衡，请求到相应的系统接口。\n首先我们看一下整个路由寻址过程的阶段。\n这 SOFARPC 中，路由可以分为地址直连路由、注册中心路由以及客户定制化路由。这以上三个路由均扩展了 Router 抽象类。服务路由的抽象类代码如下：\n这里的核心代码是 route 这个方法，将本次请求的信息，和服务列表进行计算。当客户端请求到达 Router 时，会根据请求的参数信息从 Router 和连接管理器中获取请求地址，通过调用 route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) 方法达到路由寻址的目的。\n其中，路由并不是一个非此即彼的过程，这些可选的路由是由用户和系统的配置，被构造成一个路由链来执行的。这样。就可以有一些兜底的逻辑，如指定了 IP 地址，那我们就直接路由到这个地址，如果没有，就进行注册中心的路由等等。\n直连(DirectUrlRouter) 直接路由是比较简单的，因为有专门的配置，所以地址列表这些都是可以很方便地进行识别，在客户端配置时，可通过如下方式配置：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); 直接地址路由扩展了 Router 抽象类的实现，在重写的 route 方法中，直接获取配置好的直接路由地址。当请求到来时，直接从地址管理列表中，拿到对应的地址，就实现了直接地址路由的功能。\n注册中心(RegistryRouter) 注册中心路由同样扩展了 Router 抽象方法，这个 Router是大多数情况下使用最多的路由，主要是从本应用使用的注册中心中获取对应的地址，并进行路由寻址等。后面我们会介绍目前注册中心的几个内置实现。\n自定义(CustomRouter) 客户定制化路由可以配置客户自己所定制的路由实现，可以参考直接地址路由或者注册中心路由的实现，扩展 Router 类即可。\n这里的使用场景：\n一种是对于某些用户来说，在注册中心的场景下，用户认为所有的地址并不是等价的。会对地址进行人为拆分，使用方保存了自己的的所有服务提供方地址（或者是通过某种方法查询），然后重写路由定制逻辑，通过方法级别进行地址的选择。\n另一 …","date":1539154800,"description":"本文为《剖析 | SOFARPC 框架》第十篇，作者明不二，就职于华为。","dir":"blog/sofa-rpc-routing-implementation/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dc2f04fd097731619e17f7da6a24ae6a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-routing-implementation/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-routing-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 路由实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-routing-implementation/","wordcount":3769},{"author":"敖小剑","categories":"SOFAMesh","content":" 本文是SOFAMesh中的多协议通用解决方案x-protocol介绍系列文章之一。\n 前言 在2018年上半年，蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决方案，在6月底对外公布了 SOFAMesh，详情请见之前的文章: 大规模微服务架构下的Service Mesh探索之路 。\n在 SOFAMesh 的开发过程中，针对遇到的实际问题，我们给出了一套名为 x-protocol 的解决方案，定位是云原生、高性能、低侵入性的通用 Service Mesh 落地方案，依托 Kubernetes 基座，利用其原生的服务注册和服务发现机制，支持各种私有 RPC 协议低成本、易扩展的接入，快速享受 Service Mesh 所带来的红利。\n具体解决的问题包括：\n 多通讯协议支持问题，减少开发工作量，简单快捷的接入新协议 尽量提升性能，提供更灵活的性能与功能的平衡点选择，满足特定高性能场景 兼容现有SOA体系，提供通过接口进行访问的方式，实现不修改业务代码也能顺利接入 Service Mesh 支持单进程多服务的传统SOA程序，可以在微服务改造之前，先受益于 Service Mesh 带来的强大功能 在本系列文章中，我们将对此进行详细的讲解，首先是“DNS通用寻址方案”。\n背景和需求 SOA的服务模型 在SOFAMesh计划支持的RPC框架中，SOFARPC、HSF、Dubbo都是一脉相承的SOA体系，也都支持经典的SOA服务模型，通常称为”单进程多服务”，或者叫做”单进程多接口”。（备注：由于服务一词使用过于频繁，下文都统一称为接口以便区分）\nSOA标准的服务注册，服务发现和调用流程如下：\n 在单个SOA应用进程内，存在多个接口 服务注册时，以接口为单位进行多次独立的服务注册 当客户端进行调用时，按照接口进行服务发现，然后发起调用 当我们试图将这些SOA架构的应用搬迁到ServiceMesh时，就会遇到服务模型的问题：微服务是单服务模型，也就是一个进程里面只承载一个服务。以Kubernetes的服务注册为例，在单进程单服务的模型下，服务名和应用名可以视为一体，Kubernetes的自动服务注册会将应用名作为服务注册的标示。\n这就直接导致了SOA模型和微服务模型的不匹配问题：\n SOA以接口为单位做服务注册和服务发现，而微服务下是服务名 SOA是”单进程多接口”，而微服务是”单进程单服务” 一步接一步的需求 先上车后补票 最理想的做法当然是先进行微服务改造，实现微服务拆分。但是考虑到现有应用数量众多，我们可能更愿意在大规模微服务改造之前，先想办法让这些应用可以运行在ServiceMesh下，提前受益于Service Mesh带来的强大功能。因此，我们需要找到一个合适的方案，让ServiceMesh支持没有做微服务改造依然是”单进程多接口”形式的传统SOA应用，所谓”先上车后补票”。\n 不修改代码 考虑到原有的SOA应用，相互之间错综复杂的调用关系，最好不要修改代码，即保持客户端依然通过接口名来访问的方式。当然，SOA架构的客户端SDK可能要进行改动，将原有的通过接口名进行服务发现再自行负载均衡进行远程调用的方式，精简为标准的Servicemesh调用（即走Sidecar），因此修改SDK依赖包和重新打包应用是不可避免。\n 支持带特殊字符的接口名 Kubernetes的服务注册，Service名是不能携带”.“号的。而SOA架构下，接口名有时出于管理方便，有可能是加了域名前缀，如”com.alipay.demo.interface-2”。为了实现不修改原有代码，就只能想办法支持这种带特殊字符的接口名。\n参考Kubernetes和Istio 在进一步讨论解决方案之前，我们先来看一下kubernetes和Istio中的标准请求寻址方式。\n 备注：过程稍显复杂，涉及到Kubernetes/Istio的一些底层细节。但是了解这个过程对后续的理解非常重要，也可以帮助大家了解Kubernetes和Kubernetes的工作原理，强烈推荐阅读。\n Kubernetes下的DNS寻址方式 在Kubernetes下，如图所示，假定我们部署了一个名为userservice的应用，有三个实例，分别在三个pod中。则应用部署之后，Kubernetes会为这个应用分配ClusterIP和域名，并在DNS中生成一条DNS记录，将域名映射到ClusterIP：\n当部署在Kubernetes下的某个充当客户端的应用发起请求时，如图中的HTTP GET请求，目标URL地址为 http://userservice/id/1000221。请求的寻址方式和过程如下：\n 首先进行域名解析，分别尝试解析”userservice”/“userservie.default.svc.cluster.local”等域名，得到ClusterIP 然后客户端发出请求的报文，目标地址为ClusterIP，源地址为当前客户端所在的pod IP（简单起见，端口先忽略） 请求报文随即被kube-proxy拦截，kube-proxy根据ClusterIP，拿到ClusterIP对应的多个实际服务实例所在的pod ip，取其中一个，修改目标地址为这个pod IP 请求报文最终就被发送到服务实例所在的pod IP 应答回来的方式类似，userservice发出的应答报文会被kube-proxy拦截并修改为发送到客户端所在的pod IP。\n我们详细看一下请求和应答全称的四个请求包的具体内容（简单起见继续忽略端口）：\n重点关注请求和应答报文的源地址和目标地址：\n 客户端发出的请求，为”客户端到ClusterIP” kube-proxy拦截到请求后，将请求修改为”客户端到服务器端” 服务器端收到请求时，表现为”客户端到服务器端”，ClusterIP被kube-proxy屏蔽 服务器端发送应答，因为收到的请求看似来自客户端，因此应答报文为”服务器端到客户端” 应答报文被kube-proxy拦截，将应答修改为”ClusterIP到服务器端” 客户端收到应答，表现为”ClusterIP到服务器端”，服务器端IP被kube-proxy屏蔽 kube-proxy在客户端和服务器端之间拦截并修改请求和应答的报文，联通两者，但各自屏蔽了一些信息：\n 在客户端看来它是在和ClusterIP交互，userservice的具体服务器端实例对客户端是无感知的 在服务器端看来，客户端是直接在和它交互，ClusterIP的存在对服务器端是无感知的 更深入一步，看kube-proxy在两个拦截和修改报文中的逻辑处理关系，即kube-proxy是如何在收到应答时正确的找回原有的ClusterIP：\n 在拦截并修改请求报文之后，kube-proxy会保存报文修改的5元组对应关系（5元组指源IP地址，源端口，协议，目的地IP地址，目的地端口） 在收到应答报文后，根据应答报文中的5元组，在保存的5元组对应关系中，找到对应信息，得到原有的ClusterIP和端口，然后修改应答报文 总结，通过上述Kubernetes下的寻址方式，客户端只需发送带简单寻址信息的请求（ …","date":1538982000,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，首先介绍的是DNS通用寻址方案。","dir":"blog/sofa-mesh-x-protocol-common-address-solution/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6429061afc56c5832c17b541943498e6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","publishdate":"2018-10-08T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","summary":"本文是SOFAMesh中的多协议通用解决方案x-protocol介绍系列文章之一。 前言 在2018年上半年，蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","wordcount":5813},{"author":"水寒","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第八篇，作者水寒，目前就职于网易。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕，文末提供了已完成的文章目录。\n 前言 在本系列之前的文章中，我们已经介绍了同步，异步，泛化调用等，也介绍了链路追踪的能力，本篇，我们将介绍一下 SOFARPC 中另一种内置的数据透传的能力。会依次介绍，数据透传的概念， SOFARPC 的设计原理，以及各种不同调用方式下的透传使用和详细说明，最后， 还会比较一下和 SOFATracer 的区别。欢迎大家与我们讨论交流。\n数据透传介绍 首先，我们介绍一下数据透传的概念，我们知道，在 RPC调用中，数据的传递，是通过接口方法参数来传递的，需要接口方定义好一些参数允许传递才可以，在一些场景下，我们希望，能够更通用的传递一些参数，比如一些标识性的信息。业务方可能希望，在每一次调用请求中都能够传递一些自定义的信息到下游。甚至也希望下游能够将一些数据传递回来。\n而数据透传功能，就是指数据不需要以作为方法参数的形式在调用链路中进行传递，而是直接存储到调用上下文中，之后通过 RPC 的内置对象，进行传递，调用双端可从上下文中获取数据而不需要去关注数据的传输过程。\nSOFARPC 提供的数据透传支持请求数据透传（客户端向服务端）和响应数据透传（服务端向客户端）。\nSOFARPC 设计原理 这里主要是介绍一下，实现的核心原理，更加具体的每种调用方式的透传，在后文中都会详细介绍。\n 用户通过 SOFARPC 提供的 API 进行数据传递设置\n SOFARPC 在调用传输前，将透传的数据进行打包获取\n 进行正常的序列化和反序列化\n SOFARPC 在反序列化时将用户设置的透传数据写回 Context\n 服务端用户即可进行获取使用\n 不同调用方式的透传 我们知道，SOFARPC 目前支持四种调用模式，如果没有阅读过之前文章的同学，可以阅读一下 SOFARPC 同步异步实现剖析，请求透传数据的原理都是一样的，服务端设置响应透传数据的原理也是一样的，只是客户端获取响应透传数据的方式有所不同（后三种模式只介绍客户端获取响应透传数据的原理）。因此我们会介绍下不同调用方式的透传细节，并介绍其使用方式，方便大家理解。以下为了方便说明，我们会使用如下的接口示例：\n接口服务 public interface HelloService { String sayHello(String string); } 服务实现 public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string) { // 获取请求透传数据并打印 System.out.println(\u0026amp;quot;service receive reqBag -\u0026amp;gt; \u0026amp;quot; + RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;req_bag\u0026amp;quot;)); // 设置响应透传数据到当前线程的上下文中 RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;resp_bag\u0026amp;quot;, \u0026amp;quot;s2c\u0026amp;quot;); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; ！\u0026amp;quot;; } } 后续的所有调用模式都使用HelloServiceImpl这个服务实现。(示例代码在 SOFARPC 的 测试 case 中都要对应的示例，大家可以对应阅读。)\n对用户可见的操作 API 只有一个就是 RpcInvokeContext，在 SOFABoot 和 SOFARPC 下都适用，当然如果你了解 SOFARPC 的 Filter 机制，也可以通过扩展这个来实现。\nsync 调用下的透传 使用示例 原理剖析 请求透传数据 客户端首先在 main 线程（图中的user thread）中设置请求透传数据到其调用上下文RpcInvokeContext.requestBaggage属性中，之后在调用过程中从requestBaggage中取出请求透传数据并设置到SofaRequest.requestProps属性中； 服务端接收到请求SofaRequest对象后，在其调用链中的 ProviderBaggageFilter#invoke 方法中会先从SofaRequest.requestProps中取出请求透传数据并设置到当前服务端线程的调用上下文RpcInvokeContext.requestBaggage属性中，最后业务代码就可以从调用上下文中获取请求透传数据了。 响应透传数据 服务端设置响应透传数据到其调用上下文RpcInvokeContext.responseBaggage属性中，之后在ProviderBaggageFilter#invoke 方法中先从responseBaggage中取出响应透传数据并设置到SofaResponse.responseProps属性中； 客户端main线程被唤醒后，先从SofaResponse.responseProps中获取响应透传数据，之后将响应透传数据设置到其调用上下文RpcInvokeContext.responseBaggage中，最后业务代码就可以从调用上下文中获取响应透传数据了。 oneway 调用下的透传 使用示例 原理剖析 在 oneway 模式下，客户端不接受服务端响应，也不会获取响应透传数据。\nfuture 调用下的透传 使用示例 原理剖析 客户端获取响应透传数据 future 模式在 SOFARPC 内部会被转化为 callback 的方式进行调用，在 callback 对象中会存储main线程的调用上下文；当客户端接收到响应时，会执行该 callback 对象的回调函数，在其回调函数中，对于响应透传数据，会做如下操作：\n 从SofaResponse.responseProps中获取响应透传数据\n 从 callback 对象中获取 main 线程的调用上下文\n 设置响应透传数据到 main 线程的调用上下文\n 将 main 线程上下文拷贝到当前的回调线程中\n 实际上，第三步与第四步在 SOFARPC 源码中顺序相反，本文这样解读是为了更容易理解。这样无论是 future 模式（从 main 线程的调用上下文获取响应透传数据）还是 callback 模式（从回调线程的调用上下文获取响应透传数据），都可以顺利的获取到响应透传数据。\ncallback 调用下的透传 使用示例 原理剖析 与 future 模式原理一样，只是最终业务代码中是从回调线程而不是main …","date":1538550000,"description":"本文为《剖析 | SOFARPC 框架》第八篇，作者水寒，目前就职于网易。","dir":"blog/sofa-rpc-data-transmission/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a26f5f1db99edadf48c406492ccdcaf8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-data-transmission/","publishdate":"2018-10-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-rpc-data-transmission/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 数据透传剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-data-transmission/","wordcount":2528},{"author":"莫那·鲁道","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第七篇，作者莫那·鲁道 ，来自 E签宝。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 我们知道，在 RPC 调用中，客户端需要加载服务端提供的接口定义类，但是，很多情况下，这个并不总是可行的，于是，衍生了泛化调用的需求，一个成熟的，功能完善的 RPC 框架一般都会支持泛化调用，那么什么是泛化调用呢？SOFA RPC 又是如何支持泛化调用的？同时又是如何实现的？ 和其他的 RPC 泛化调用又有何不同？有何优势？我们将在本文一一解答这些问题。\n泛化调用介绍 当客户端因为某种原因无法得到服务提供方的接口 jar 包时，或者是客户端是一个比较通用的系统，并不想依赖每个服务提供方提供的 facade接口，但是又需要进行调用，那么此时就需要进行泛化调用。\n例如： 1. 当分布式系统由多个语言开发，假设是 Node Js ，同时 Node Js 需要调用 Java 语言的 RPC 服务，那么，我们就需要在两者之间架设适配层，让适配层处理 Node Js 的请求后再转发给 Java 的 RPC 服务。 2. 一些中间系统的功能，比如某些内部网关，需要以一个统一的方式实现对其他下游系统的调用（非 SPI的情况），逐个依赖下游的包显然是不可能的。 3. 一些流量回放类的线上系统，可以将数据采集拦截，之后，通过泛化调用回放，而不需要依赖全站的应用。\n那么这种情况下，肯定不能包含所有接口的 jar 文件，否则就太臃肿了。实际上也是不现实的，总不能每增加一个服务端，就增加一个 jar 包依赖，然后应用进行发布重启。\n这个时候就可以使用泛化调用，将相应的请求包装成泛化调用，就能够实现不依赖接口 jar 包，多语言调用 RPC 服务，避免重复开发。\nSOFA RPC 的泛化调用使用 SOFA RPC 的官方文档十分详细，在官方 wiki 泛化调用 中，已有详细介绍。同时，在源码中的 example 模块中，也有现成的 demo 可以跑起来，读者可以自己 clone 源码阅读，这里我们简要说明一下使用方式，以便大家有一个直观的了解。\n接口定义 总的来说，泛化调用有 2 个 API，包含 5 个方法，其中， 2 个方法已经废弃，也就是说，有 3 个主要方法。分别是：\n/** * 泛化调用 * @return 正常类型（不能是GenericObject类型） */ Object $invoke(String methodName, String[] argTypes, Object[] args); /** * 支持参数类型无法在类加载器加载情况的泛化调用 * @return 除了JDK等内置类型，其它对象是GenericObject类型 */ Object $genericInvoke(String methodName, String[] argTypes, Object[] args); /** * 支持参数类型无法在类加载器加载情况的泛化调用 * @return 返回指定的T类型返回对象 */ \u0026amp;lt;T\u0026amp;gt; T $genericInvoke(String methodName, String[] argTypes, Object[] args, Class\u0026amp;lt;T\u0026amp;gt; clazz); \\$invoke 该方法使用场景：用户知道参数类型和返回值类型，那么就可以使用该方法。 \\$genericInvoke 该方法是个重载方法，重载一的使用场景是：如果你的应用不知道接口的参数类型和返回值类型，这个时候，你就需要使用 GenericObject 类，来包装返回值和参数。 \\$genericInvoke 重载二的使用场景是：如果应用不知道接口参数类型，但是知道接口返回值的类型，那么就不需要使用 GenericObject 作为返回值了。 基本上，已经覆盖了常用的集中场景，可以说功能相当全面。\n泛化使用 由于篇幅有限，这里就不贴使用 demo 了，感兴趣的可以通过链接查看官方的 demo 或者源码，包含 SOFARPC 的 API 使用方式和 SOFABoot 的使用方式：\n demo wiki 地址：用户手册-\u0026amp;gt;基本特性-\u0026amp;gt;泛化调用 源码地址：示例源码 SOFARPC 泛化调用的设计与实现 接下来我们重点来介绍 SOFARPC 是如何实现泛化调用的。\n框架调用设计 简单来说，泛化调用的关键就是对象表示和序列化，SOFARPC 提供了 GenericObject 等对象来表示参数对象或者返回值对象，而将 GenericObject 对象序列化成目标对象，或者将返回值反序列化成 GenericObject 对象，是 SOFARPC 实现泛化的关键。\n这里我们先来看一下 SOFARPC 泛化调用的流程图，有助于后面理解泛化实现。\n我们来说一下这个图： 1. 泛化 API 调用时，会加载泛化过滤器，作用是做一些参数转换，同时设置序列化工厂类型。 2. SOFARPC 在使用 SOFABolt 进行网络调用前，会创建 context 上下文并传递给 SOFABolt，上下文中包含着序列化工厂类型信息，这个信息将决定使用何种序列化器，同时这个上下文将流转于整个调用期间。 3. 在 SOFABolt 正式发送数据之前，会将 GenericObject 对象序列化成普通对象的字节流，这样，服务提供方就不必关心是否为泛化调用，从图中可见，提供方不用对泛化调用做任何改变 —— 这是 SOFARPC 泛化区别于其他 RPC 泛化的关键。 4. 当提供方成功接收请求后，使用普通序列化器即可反序列化数据，只需要正常调用并返回即可。 5. 当消费者的 SOFABolt 接收到响应数据后，便根据 context 的序列化类型，对返回值做反序列化，即将普通的字节流反序列化成 GenericObject 对象 —— 因为客户端有可能不知道返回值的 Class 类型。 6. 最终，泛化 API 即可得到 GenericObject 类型的返回值。\n从上面的流程可以看出，序列化器在泛化调用中，占了极大的篇幅和作用。而 SOFARPC 针对泛化调用，对 hessian3 进行了改造，使其支持泛化调用所需要的序列化功能。SOFA-Hessian的改动可以参考这里。\nHessian 泛化实现 SOFA-Hessian 在 hessian 的包中加入了 com.alipay.hessian.generic 包，此包的作用就是处理泛化调用，重写的关键是实现或继承 SerializerFactory 类和 Serializer、Deserializer 等接口。在这里，设计了一下几个类，来描述对应的类型信息，同时实现这几个类的序列化和反序列化。对应关系如下： …","date":1537945200,"description":" 本文为《剖析 | SOFARPC 框架》第七篇，作者莫那·鲁道 ，来自 E签宝。","dir":"blog/sofa-rpc-generalized-call-implementation/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"de327dfe502c28ef0f926f17b29a6c80","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","publishdate":"2018-09-26T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 泛化调用实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","wordcount":3226},{"author":"畅为","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第六篇，作者畅为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 一. 前言 对于金融业务而言每个环节都涉及到大量的资金操作，若因为网络、硬件等原因导致系统不稳定性，不仅影响用户体验，更重要的是可能会引起资损问题，因此系统可用性至关重要。在微服务分布式架构中提高系统可用性的常见方案是 集群（冗余）。 集群方式将一个服务部署在多个机器上，通过硬负载或软负载实现服务的均衡负载，虽然可以有效避免单点问题，但是仍然避免不了某些场景单机故障引起服务调用失败的问题。\nSOFARPC 提供了自动单机故障剔除能力，能够自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复，提高系统可用性。本文将从以下几个方面进行剖析：\n 单机故障和服务降级介绍\n SOFARPC 单机故障剔除原理\n 二. 单机故障和服务降级 在分布式架构中常见可用性方案的是 集群（冗余），即将一个服务部署在多个机器上，通过硬负载或软负载实现服务的均衡负载。硬件负载因每次请求都需要经过硬件负载，承担所有的访问压力，当集群规模增加、流量增多，硬件负载可能因无法支撑所有流量而导致系统不可用。\n软负载则提供注册中心，并将负载能力转移到服务调用方( Consumer )，注册中心只有在 Consumer 首次订阅或服务发生变化时才会发生交互，避免了并发访问下的单点问题。下图是基于软负载的服务调用：\n虽然软负载可以避免单点问题，但可能存在以下场景导致服务不可用：\n Provider 出现单点故障或宕机，与 Consumer 的长连接已断开，但注册中心尚未摘除或未及时通知Consumer。\n Consumer 和 Provider的长连接还在，注册中心未下发摘除，但服务器端由于某些原因，例如长时间的 Full GC, 硬件故障（后文中为避免重复，统一描述为机器假死）等场景，处于假死状态。\n 这两种场景都是服务端出现故障，但由于长连接还保留等原因注册中心未摘除服务，导致服务调用失败。针对第一种情况 Consumer 不应调用出现故障的 Provider，否则会引起部分服务不可用；针对第二种情况，这个 Consumer 应该不调用或少调用该 Provider，可以通过权重的方式来进行控制。目前 SOFARPC 5.3.0 以上的版本支持 RPC 单机故障剔除能力。SOFARPC 通过服务权重控制方式来减少异常服务的调用，将更多流量打到正常服务机器上，提高服务可用性。\n2.1 SOFARPC故障剔除 vs 注册中心故障剔除 SOFARPC 的故障剔除与注册中心故障服务剔除不同，它们从不同的维度来完成故障剔除提高服务可用性。主要两方面的区别：\n 故障剔除的时机\n 故障剔除的细粒度\n 故障剔除的时机 SOFARPC 的故障剔除与注册中心故障服务剔除不同，它们从不同的维度来完成故障剔除提高服务可用性。注册中心服务管理关注 Provider 与注册中心的心跳或长连接。如果 Provider 出现心跳异常或长连接不存在，则及时将服务从注册中心剔除，并告知 Consumer 移除本地缓存的故障 Provider 信息。Comsumer 在负载均衡选择时则不考虑被剔除的 Provider，如图所示：\n而 SOFARPC 单机故障剔除针对的场景不同，针对的是注册中心还未剔除的服务，这些服务与 Consumer 仍然保持长连接，但由于机器假死，不能提供正常服务。 如下图所示：\n故障剔除的细粒度 注册中心剔除的是粒度是针对单机上的某个服务进程，属于进程级别。一旦这个进程和注册中心断开连接或心跳无感应，则将其从注册中心剔除。\nSOFARPC 故障剔除并控制精度会更精细一些，会细致到进程对外暴露的服务，如部署在某个机器上的交易系统对外提供的交易查询服务 TransQueryService. 管理的维度是 IP + 服务， 这里的服务特指进程中的服务接口。\n2.2 服务权重降级 vs 服务降级 服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。这里的降级级别是整个系统服务，而不是针对接口级别。\nSOFARPC 的服务降级，是指当某些个别机器因为存在机器假死，导致处于假死状态，导致一些服务接口响应异常，通过 SOFARPC 的故障剔除和服务权重降级来减少对这些异常机器接口的访问，而将更多的流量打到正常的机器上。 这里针对的维度主要还是 IP + 服务维度，如部署在 xxx 机器上交易系统对外提供的 TransQueryService 服务。\n三. 原理解析 通常一个服务有多个服务提供者，其中部分提供者可能由于机器假死等导致长连接还存活但是程序已经无法正常响应 。 故障剔除功能会将这部分异常的服务提供者进行降级，使得客户端的请求更多地指向健康节点。当异常节点的表现正常后，故障剔除功能会对该节点进行恢复，使得客户端请求逐渐将流量分发到该节点。\nSOFARPC 5.3.0 以上支持故障剔除的功能，故障剔除功能采用自动化监控和降级，因此可以减少人工干预，提供系统可用率。SOFARPC 剔除的维度是服务 + Ip 级别。为了支持单机故障剔除能力，SOFARPC 提供了以下几个方面的设计：\n 入口设计: 进行RPC调用的时候，增加一个信息统计的传递入口。SOFARPC 采用无缝插入设计，在不破坏开放封闭原则前提下引入单机故障剔除能力。\n 信息收集器 : 维护和管理从入口传进来的统计信息。\n 计算策略 : 主要是根据度量结果，判断是否需要执行降级或者恢复服务。如果命中降级规则，则触发降级行为。如果命中恢复规则，则触发恢复行为。\n 度量策略 : 负责按一定维度对调用信息做度量，判断服务正常或异常。\n 降级策略 : 如果服务异常，需要进行降级处理，降级策略指定了处理逻辑，比如按打印日志或降低服务权重。\n 恢复策略 ：当一个异常服务恢复正常时，如何恢复该服务，例如提高服务权重等。\n 3.1 整体结构和入口 《SOFARPC 链路追踪剖析》中已介绍 SOFARPC 的 内核设计和总线设计，和链路追踪功能一样，SOFARPC 单机故障剔除能力也是基于内核设计和总线设计，做到可插拔、零侵入。\nSOFARPC 单机故障剔除模块是 FaultToleranceModule， 通过 SOFARPC 的 SPI 机制完成模块的自动化加载，以完成该功能的插入。 FaultToleranceModule 模块包含了两个重要部分：\n subscriber 事件订阅器 。 通过订阅事件总线 EventBus 的事件，以零侵入方式完成 RPC 调用的统计和信息收集。\n regulator 调节器 。 根据收集的 RPC 调用信息，完成服务调用或服务权重的调节，达到服务 …","date":1537167600,"description":"本文为《剖析 | SOFARPC 框架》第六篇，作者畅为。","dir":"blog/sofa-rpc-single-machine-fault-culling/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3171526788b6f17e3ffa37512918729f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","publishdate":"2018-09-17T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 单机故障剔除剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","wordcount":5281},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第五篇。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 上一篇，我们介绍了 SOFARPC 同步异步的实现，本文我们将会介绍 SOFARPC 中的线程模型。\n本文会从同步异步，阻塞非阻塞开始讲起，进而探讨常见的线程模型设计，之后，我们会介绍下 SOFABolt 中对 Netty 的模型使用，最后 SOFARPC 在一次调用过程中各个步骤执行的线程。\n几种常见的 IO 模型 首先介绍一下 Linux 的几种 IO 模型，以进程从 Socket 中读取数据为例。实际上，进程最终是通过 recvfrom 系统调用来读取数据。这个时候，系统内核在收到之后，根据 IO 模型的不同，处理是不同的。\n注意，图下的红色部分表示阻塞时间。\n阻塞 I/O 阻塞 I/O(blocking I/O) 模型是最流行，最简单易用的 I/O 模型，默认情况下，所有套接字和文件描述符就是阻塞的。阻塞 I/O 将使请求进程阻塞，直到请求完成或出错。\n非阻塞 I/O 非阻塞 I/O(nonblocking I/O)的含义：如果 I/O 操作会导致请求进程休眠，则不要把它挂起，也就是不会让出 CPU，而是返回一个错误告诉它（可能是 EWOULDBLOCK 或者 EAGAIN）。\nI/O 复用 I/O 多路复用(I/O multiplexing)会用到 select 或者 poll 或者 epoll 函数，这几个函数也会使进程阻塞，但是和阻塞 I/O 所不同的的，函数可以同时阻塞多个 I/O 操作。而且可以同时对多个读操作，多个写操作的 I/O 函数进行检测，直到有数据可读或可写时，才真正调用 I/O 操作函数。\n信号驱动式 I/O 信号驱动 I/O(signal-driver I/O)使用信号，让内核在描述符就绪时发送 SIGIO 信号通知我们进行处理，这时候我们就可以开始真正的读了。\n异步 I/O 异步 I/O(asynchronous I/O)由 POSIX 规范定义，包含一系列以 aio 开头的接口。一般地说，这些函数的工作机制是：告知内核启动某个操作，并让内核在整个操作（包括将数据从内核空间拷贝到用户空间）完成后通知我们。\n这种模型与信号驱动模型的主要区别是：信号驱动 I/O 是由内核通知我们何时可以启动一个 I/O 操作，而异步 I/O 模型是由内核通知我们 I/O 操作何时完成。\n汇总 综上，我们给出一个大家比较熟知的比较图。方便理解。\nJAVA BIO \u0026amp;amp; NIO 在了解了内核层面上这几个线程模型之后，我们要给大家介绍下 JAVA BIO 和 JAVA NIO。\nJAVA BIO 首先我们给大家看一个直接使用 JAVA BIO 写得一个服务端。\n传统的BIO里面socket.read()，如果TCP RecvBuffer里没有数据，调用会一直阻塞，直到收到数据，返回读到的数据。\nJAVA NIO 对于 NIO，如果 TCP 的 buffer 中有数据，就把数据从网卡读到内存，并且返回给用户；反之则直接返回0，永远不会阻塞。下面是一段比较典型的 NIO 的处理代码。\n在我们可以将 JAVA NIO 和多路复用结合起来。这里也是最简单的 Reactor 模式：注册所有感兴趣的事件处理器，单线程轮询选择就绪事件，执行事件处理器。\n这里简单比较了一下以前的 BIO 和现在的 NIO，新的 NIO 给我们带来了如下的好处。\n 事件驱动模型\n 单线程处理多任务\n 非阻塞 I/O，I/O 读写不再阻塞，而是返回 0\n 基于快的传输，比基于流的传输更高效\n 更高级的 IO 函数，零拷贝\n 允许 IO 多路复用\n Reactor 线程模型 前面说了，我们有了 JAVA NIO ，可以用多路复用。有些同学可能会问，不能直接使用吗？答案是可以直接使用，\n但是技术层面上的问题虽然解决了，在工程层面，实现一个高效没有问题的架构依然很难，而且这种多路复用，对编程思维有比较大的挑战，所以，工程层面还不够。因此，有了 Reactor 编程模型\n一般情况下，I/O 复用机制需要事件分发器，以上这个分发事件的模型太简单了。实际使用起来会有一些性能问题。目前比较流行的是 Reactor 和 Proactor，本文不介绍 Proactor 模型，有兴趣的同学可以自己学习。\n标准/典型的 Reactor 中定义了三个角色：\n而一个标准的操作流程则是：\n 步骤1：等待事件到来（Reactor 负责）。\n 步骤2：将读就绪事件分发给用户定义的处理器（Reactor 负责）。\n 步骤3：读数据（用户处理器负责）。\n 步骤4：处理数据（用户处理器负责）。\n 在这个标准之下，Reactor 有几种演进模式可以选择。注意 Reactor 重点描述的是 IO 部分的操作，包括两部分，连接建立和 IO 读写。\n单线程模型 Reactor 单线程模型指的是所有的 IO 操作都在同一个NIO 线程上面完成，NIO 线程的职责如下：\n 作为 NIO 服务端，接收客户端的 TCP 连接；\n 作为 NIO 客户端，向服务端发起 TCP 连接；\n 读取通信对端的请求或者应答消息；\n 向通信对端发送消息请求或者应答消息。\n 这是最基本的单 Reactor 单线程模型。其中 Reactor 线程，负责多路分离套接字，有新连接到来触发 connect 事件之后，交由 Acceptor 进行处理，有 IO 读写事件之后交给 hanlder 处理。\nAcceptor 主要任务就是构建 handler，在获取到和 client 相关的 SocketChannel 之后 ，绑定到相应的 handler上，对应的 SocketChannel 有读写事件之后，基于 reactor 分发，hanlder 就可以处理了（所有的 IO 事件都绑定到 selector 上，由 Reactor 分发）。\n该模型 适用于处理器链中业务处理组件能快速完成的场景。不过，这种单线程模型不能充分利用多核资源，所以实际使用的不多。\n多线程模型 Reactor 多线程模型与单线程模型最大的区别就是将 IO 操作和非 IO 操作做了分离。效率提高。\nReactor 多线程模型的特点：\n 有专门一个 NIO 线程-Acceptor 线程用于监听服务端，主要接收客户端的 TCP 连接请求；\n 网络 IO 操作-读、写等由一个单独的 NIO 线程池负责，线程池可以采用标准的 JDK 线程池实现，它包含一个任务队列和 N 个可用的线程，由这些 NIO 线程负责消息的解码、处理和编码；\n 主从多线程模型 这个也是目前大部分 RPC 框架，或者服务端处理的主要选择。\nReactor 主从多线程模型的特点：\n服务端用于接收客户端连接的不再是个1个单独的 NIO 线程，而是一个独立的 NIO 线程池。\n主要的工作流程： …","date":1536735600,"description":"本文为《剖析 | SOFARPC 框架》第五篇。","dir":"blog/sofa-rpc-threading-model/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fbde29dd299a8163dafa9d571d1714e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-threading-model/","publishdate":"2018-09-12T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-threading-model/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 线程模型剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-threading-model/","wordcount":3410},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第四篇。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 这一篇，我们为大家带来了开发过程中，最常接触到的同步异步调用解析。本文会介绍下同步异步的使用场景，以及 SOFARPC 中的代码实现机制，为了方便大家理解和阅读代码。不会过多的设计代码实现细节，更多的还是希望大家从中有所收获，并能够独立阅读核心代码。\n原理剖析 SOFARPC 以基于 Netty 实现的网络通信框架 SOFABolt 用作远程通信框架，使用者不用关心如何实现私有协议的细节，直接使用内置 RPC 通信协议，启动客户端与服务端，同时注册用户请求处理器即可完成远程调用：\nSOFARPC 服务调用提供同步 Sync、异步 Future、回调 Callback 以及单向 Oneway 四种调用类型。\n这里我们先提供一张整体的图，后面每个方式原理介绍的时候，我会进行更加详细的解释。读者可以重点阅读以下部分的图示，根据阻塞时间的长短，会有不同的标识。\nSync 同步调用 同步调用是指的客户端发起调用后，当前线程会被阻塞，直到等待服务端返回结果或者出现了超时异常，再进行后续的操作，是绝大多数 RPC 的默认调用方式，无需进行任何设置即可。\n这种调用方式，当前线程发起调用后阻塞请求线程,需要在指定的超时时间内等到响应结果才能完成本次调用。如果超时时间内没有得到响应结果，那么抛出超时异常。Sync 同步调用模式最常用，注意要根据对端的处理能力合理设置超时时间。\n如上图所示，这里主要是描述了客户端的处理逻辑，其中客户端线程和 RPC 内部部分处理并不在一个线程里。所以这里客户端线程包含其中一部分操作，后文的图中也是类似。其中红色的树状框表示客户端的线程阻塞。\n可以看到，客户端在代码片段2中，发起 RPC 调用，那么除非本次 RPC 彻底完成，或者 RPC 在指定时间内抛出超时异常，否则红框一直阻塞，代码片段3没有机会执行。\nFuture 异步调用 客户端发起调用后不会同步等待服务端的结果，而是获取到 RPC框架给到的一个 Future 对象，调用过程不会阻塞线程，然后继续执行后面的业务逻辑。服务端返回响应结果被 RPC 缓存，当客户端需要响应结果的时候需要主动获取结果，获取结果的过程阻塞线程。\n如上图所示，代码片段2发起 RPC 调用后，RPC 框架会立刻返回一个 Future 对象。给到代码片段2，代码片段2可以选择等待结果，或者也可以继续执行代码片段3，等代码片段3执行完成后，再获取 Future 中的值。\nCallback 回调调用 客户端提前设置回调实现类，在发起调用后不会等待结果，但是注意此时是通过上下文或者其他方式向 RPC 框架注册了一个 Callback 对象，结果处理是在新的线程里执行。RPC在获取到服务端的结果后会自动执行该回调实现。\n如图所示，客户端代码段2发起 RPC 调用后，并不关心结果，此时也不会有结果。只是将自己的一个 Callback 对象传递给 RPC 框架，RPC 框架发起调用后，立即返回。之后自己等待调用结果，在有了调用结果，或者超过业务配置的超时时间后，将响应结果或者超时的异常，进行 callback 的回调。一般的，一个 callback 的结果需要包含两个部分\npublic interface InvokeCallback { /** * Response received. * * @param result */ public void onResponse(final Object result); /** * Exception caught. * * @param e */ public void onException(final Throwable e); } 如果是正常返回，则 RPC 框架回调用户传入 callback 对象的 onResponse 方法，如果是框架层的异常，比如超时，那么会调用 onException 方法。\nOneway 单向调用 客户端发送请求后不会等待服务端返回的结果，并且会忽略服务端的处理结果，\n当前线程发起调用后，用户并不关心调用结果，只要请求已经发出就完成本次调用。单向调用不关心响应结果，请求线程不会被阻塞，使用 Oneway 调用需要注意控制调用节奏防止压垮接收方。注意 Oneway 调用不保证成功，而且发起方无法知道调用结果。因此通常用于可以重试，或者定时通知类的场景，调用过程是有可能因为网络问题、机器故障等原因导致请求失败，业务场景需要能接受这样的异常场景才能够使用。\n调用方式比较 调用方式 优点 不足 使用场景 Sync 简单 同步阻塞 大部分场景 Oneway 简单，不阻塞 无结果 不需要结果，业务不需要保证调用成功的场景 Future 异步，可获取结果 需要再次调用 get 方法获取结果 同线程内多次 RPC 调用。且没有先后关系 Callback 异步，不需要手动获取结果 使用稍微复杂。且不能在当前代码段直接操作结果 当前不关心结果。但是最终依赖结果做一些其他事情的场景 源码剖析 下面我们以 SOFARPC 中的 BOLT 协议为基础，介绍一些 RPC 框架下面的代码层面的设计。主要介绍代码结构和相互的调用关系。\n对 BOLT 的包装主要在\ncom.alipay.sofa.rpc.transport.bolt.BoltClientTransport 业务方并不直接使用 BOLT 定义的一些类型，而是使用 RPC 定义的一些类型。这些类型被适配到 BOLT 的类型上，使得 RPC 框架对用户提供了统一的 API，和底层是否采用 BOLT 不强相关。\nSync 同步调用 SOFARPC 中的的同步调用是由 Bolt 通信框架来实现的。核心代码实现在\ncom.alipay.remoting.BaseRemoting#invokeSync com.alipay.remoting.rpc.protocol.RpcResponseProcessor#doProcess 使用时无需特殊配置。\nFuture 异步调用 使用 Future 异步调用 SOFABoot 配置服务引用需要设置\n\u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; 元素的 type 属性声明调用方式为 future：\n如上设置为 Future 调用的方式。客户端获取响应结果有两种方式：\n1.通过 SofaResponseFuture 直接获取结果。第一个参数是获取结果的超时时间，第二个参数表示是否清除线程上下文中的结果。\nString result =(String)SofaResponseFuture.getResponse(timeout,true); 2.获取原生 Futrue，该种方式获取JDK原生 …","date":1536130800,"description":"本文为《剖析 | SOFARPC 框架》第四篇。","dir":"blog/sofa-rpc-synchronous-asynchronous-implementation/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d7ab7dabc882ef32b491dc6ce551fc39","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","publishdate":"2018-09-05T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 同步异步实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","wordcount":3596},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第三篇，本篇由米麒麟/碧远共同出品。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 在 RPC 调用过程中，我们经常会和多个服务端进行远程调用，如果在每次调用的时候，都进行 TCP 连接，会对 RPC 的性能有比较大的影响，因此，实际的场景中，我们经常要对连接进行管理和保持。\nSOFARPC 应用心跳包以及断线重连实现,结合系统 tcp-keepalive 机制，来实现对 RPC 连接的管理和保持。\n连接管理 首先我们将会介绍连接管理相关的一些背景知识。\n长连接和短连接 短连接，一般是指客户端向服务端发起连接请求。连接建立后，发送数据，接收服务端数据返回，然后触发连接断开，下次再重新重复以上过程。\n长连接，则是在建立连接后，发送数据，接收数据，但是不主动断开，并且主动通过心跳等机制来维持这个连接可用，当再次有数据发送请求时，不需要进行建立连接的过程。\n一般的，长连接多用于数据发送频繁，点对点的通讯，因为每个 TCP 连接都需要进行握手，这是需要时间的，在一些跨城，或者长距离的情况下，如果每个操作都是先连接，再发送数据的话，那么业务处理速度会降低很多，所以每个操作完后都不断开，再次处理时直接发送数据包即可，节省再次建立连接的过程。\n但是，客户端不主动断开，并不是说连接就不会断。因为系统设置原因，网络原因，网络设备防火墙，都可能导致连接断开。因此我们需要实现对长连接的管理。\nTCP 层 keep-alive tcp 的 keep-alive 是什么 tcp-keepalive，顾名思义，它可以尽量让 TCP 连接“活着”，或者让一些对方无响应的 TCP 连接断开，\n使用场景主要是：\n 一些特定环境，比如两个机器之间有防火墙，防火墙能维持的连接有限，可能会自动断开长期无活动的 TCP 连接。\n 还有就是客户端，断电重启，卡死等等，都会导致 TCP 连接无法释放。\n 这会导致：\n一旦有热数据需要传递，若此时连接已经被中介设备断开，应用程序没有及时感知的话，那么就会导致在一个无效的数据链路层面发送业务数据，结果就是发送失败。\n无论是因为客户端意外断电、死机、崩溃、重启，还是中间路由网络无故断开、NAT 超时等，服务器端要做到快速感知失败，减少无效链接操作。\n而 tcp-keepalive 机制可以在连接无活动一段时间后，发送一个空 ack，使 TCP 连接不会被防火墙关闭。\n默认值 tcp-keepalive，操作系统内核支持，但是不默认开启,应用需要自行开启，开启之后有三个参数会生效，来决定一个 keepalive 的行为。\nnet.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 75 可以通过如下命令查看系统 tcp-keepalive 参数配置。\nsysctl -a | grep keepalive cat /proc/sys/net/ipv4/tcp_keepalive_time sysctl net.ipv4.tcp_keepalive_time 系统默认值可以通过这个查看。\ntcp_keepalive_time，在 TCP 保活打开的情况下，最后一次数据交换到 TCP 发送第一个保活探测包的间隔，即允许的持续空闲时长，或者说每次正常发送心跳的周期，默认值为 7200s（2h）。 tcp_keepalive_probes 在 tcp_keepalive_time 之后，没有接收到对方确认，继续发送保活探测包次数，默认值为 9（次）。 tcp_keepalive_intvl，在 tcp_keepalive_time 之后，没有接收到对方确认，继续发送保活探测包的发送频率，默认值为 75s。\n这个不够直观，直接看下面这个图的说明：\n如何使用 应用层，以 Java 的 Netty 为例，服务端和客户端设置即可。\nServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 100) .childOption(ChannelOption.SO_KEEPALIVE, true) .handler(new LoggingHandler(LogLevel.INFO)) .childHandler(new ChannelInitializer\u0026amp;lt;SocketChannel\u0026amp;gt;() { @Override public void initChannel(SocketChannel ch) throws Exception { ch.pipeline().addLast( new EchoServerHandler()); } }); // Start the server. ChannelFuture f = b.bind(port).sync(); // Wait until the server socket is closed. f.channel().closeFuture().sync(); 就是这里面的ChannelOption.SO_KEEPALIVE, true 对应即可打开.\n目前 bolt 中也是默认打开的.\n.childOption(ChannelOption.SO_KEEPALIVE, Boolean.parseBoolean(System.getProperty(Configs.TCP_SO_KEEPALIVE, \u0026amp;quot;true\u0026amp;quot;))); Java 程序只能做到设置 SO_KEEPALIVE 选项，至于 TCP_KEEPCNT，TCP_KEEPIDLE，TCP_KEEPINTVL 等参数配置，只能依赖于 sysctl 配置，系统进行读取。\n检查 查看 tcp 连接 tcp_keepalive 状态\n我们可以用 netstat -no|grep keepalive 命令来查看当前哪些 tcp 连接开启了 tcp keepalive. 应用层 keep-alive 应用层 keep-alive 方案，一般叫做心跳包，跟 tcp-keepalive 类似，心跳包就是用来及时监测是否断线的一种机制，通过每间隔一定时间发送心跳数据，来检测对方是否连接，是属于应用程序协议的一部分。\n心跳是什么 心跳想要实现的和 tcp keep-alive 是一样的。\n由于连接丢失时，TCP 不会立即通知应用程序。比如说，客户端程序断线了，服务端的 TCP 连接不会检测到断线，而是一直处于连接状态。这就带来了很大的麻烦， …","date":1535526000,"description":"本文为《剖析 | SOFARPC 框架》第三篇，本篇由米麒麟/碧远共同出品。","dir":"blog/sofa-rpc-connection-management-heartbeat-analysis/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2f911034e6bec76b8b0496b7f06e10b7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","publishdate":"2018-08-29T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之SOFARPC 连接管理与心跳剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","wordcount":4225},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第二篇，本篇由畅为/碧远/卓与共同出品。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 一. 前言 微服务已经被广泛应用在工业界，微服务带来易于团队并行开发、独立部署、模块化管理等诸多优点。然而微服务将原单体拆分多个模块独立部署，各模块之间链接变得错综复杂，在大规模分布式系统中这种复杂链路给维护带来了诸多困难。 如果对整个微服务架构不能了然于胸，便很难理清各模块之间的调用关系。 例如修改一个服务接口，对哪些服务造成影响不能快速定位。\nSOFARPC 在5.4.0 以后提供了链路追踪技术，可以有效协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。\n如思维导图所示，本文将从以下几个方面介绍目前已经开源的 SOFARPC 的链路追踪技术：\n二. 什么是链路追踪技术 链路追踪技术主要是收集、存储、分析分布式系统中的调用事件数据，协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。 链路追踪技术包含了数据埋点、收集、存储、分析等相关技术，是一套技术体系。 大部分的链路追踪框架都是参考 google链路追踪系统Dapper 的一篇设计论文（《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 ），SOFARPC 的SOFATracer 的设计灵感也是来自这篇著名论文。\n以大规模分布式电商系统为例，用户下单购买某款产品时后端需要调用各系统或子模块进行协作，共同完成一个用户请求。 如下图所示，用户的下单行为涉及到了A、B、C、D、E、F 6个系统的协同工作，这些系统都是以集群形式部署。整个链路中最长的链路调用是3层，如 A-\u0026amp;gt; C -\u0026amp;gt; E 或 A -\u0026amp;gt; C -\u0026amp;gt; F。\n模块的增多加大了系统出错的概率，一旦因某系统/模块出错导致整个请求调用出错，在缺乏链路追踪的条件下很难定位具体出错的模块，只能通过日志搜索定位。 在实际生产环境下比较关注一个请求中的各个模块的耗时情况、连续调用情况、出错的节点等信息。 为了解决上述问题，Dapper提供了一套解决方案。整个方案分为数据收集、存储和分析几个部分。分布式追踪技术会记录一个请求中各模块的调用信息；并通过一个处理集群把所有机器上的日志增量地收集到集群当中进行处理，将同一个请求的日志串联；最后可视化显示调用情况。\n常用的数据收集方式为埋点，通过在公共组件如RPC等注入代码，收集服务调用的相关信息。目前大部分链路调用系统如Dapper、鹰眼、Spring Cloud Sleuth 都在用这种模式。同样SOFARPC 作为一个公共的通讯框架，在金融业务领域被广泛应用，因此适合作为埋点，这样无需业务端自行埋点，可做到对业务代码的无侵入性。\nDapper 将一个调用过程构建成一棵调用树(称为Tracer)，Tracer树中的每个节点表示链路调用中的一个模块或系统。 通过一个全局唯一的 traceId 来标识一个请求调用链。 并定义了span，span表示一个系统的调用，一个span 包含以下阶段：\n Start: 发起调用\n cleint send(cs): 客户端发送请求\n Server Recv(sr)：服务端收到请求\n Server Send(ss): 服务端发送响应\n Client Recv(cr) : 客户端收到服务端响应\n End： 整个链路完成\n 每个span 包含两个重要的信息 span id(当前模块的span id) 和 span parent ID(上一个调用模块的span id)，通过这两个信息可以定位一个span 在调用链的位置。 通过以上信息我们可以定义用户下单过程的调用链：\nSOFARPC中的链路追踪技术主要是作为埋点部分，因此对于链路追踪系统的收集和分析部分本文不做详述，想要深入了解的可参看参考资料内容。链路追踪可以提供我们以下功能:\n 服务耗时、瓶颈分析 ：分析每个服务的耗时情况，可以针对耗时长的服务进行优化，提高服务性能。\n 可视化错误：快速定位服务链路中出错的环境，便于排查和定位问题。一般链路追踪中间件都提供了ZipKin 页面支持。\n 链路优化: 对于调用比较频繁的服务，可以针对这些服务实施一些优化措施。\n 调用链路梳理：通过可视化界面，对整个调用链路有个清晰的认识。\n 在设计分布式链路框架时需要考虑一下几个问题：\n 低损耗、高性能: 追踪系统对在线服务的影响应该做到足够小，不影响线上服务性能。\n 应用透明: 对于业务开发人员来说，应不需要知道有跟踪系统这回事的。\n 可扩展性：虽则业务规则增大、集群增多，监控系统都应该能完全把控住这种快速变化。\n 数据采样设计：如果每条日志都记录，在高并发情况下对系统有一定的损耗。但收集数据太少可能对统计结果有所影响，所以应合理设计采样比例。\n 三. SOFARPC 链路追踪设计原理 SOFARPC 作为一个基础的通讯中间件，对服务调用有很强的感知能力，容易获取链路追踪所需的服务调用信息。因此很多链路追踪系统都会选择RPC 作为埋点对象，通过对RPC中间件的埋点可以轻松做到对用户的无感知、透明化。 SOFARPC在5.4.0 以后开始支持分布式链路追踪，其技术实现主要依赖于所集成的SOFATracer。\nSOFARPC 不仅提供了埋点信息采集的能力, 还支持数据上报zipkin。 通过SOFARPC + SOFATracer + zipKin 可以快速搭建一套完整的链路追踪系统，包括埋点、收集、分析展示等。 收集和分析主要是借用zipKin的能力，本文重点讲SOFARPC中的数据埋点设计。SOFARPC自身具备的微内核设计和可拓展性，使得在SOFARPC在不破坏开放封闭原则的前提下，比较轻松地集合SOFATracer。该部分主要从以下几个方面讨论SOFARPC的链路追踪设计思路：\n 可插拔设计。 SOFARPC采用了微内核设计，使得很容易扩展，增加新功能。\n 总线设计。为数据埋点做提供一种无侵入的扩展方式。\n 调用trace和span\n 数据采样设计\n 异步刷新机制\n 耗时计算：链路调用的耗时统计等信息获取。\n 埋点数据透传，各模块之间的链路调用数据的透传机制。\n 异步线程的链路调用。在异步多线程环境下如何保证traceId和spanId的有序性。\n 链路调用日志数据的文件存储结构\n 3.1 可插拔设计 SOFARPC自身具备的微内核设计和可拓展性，使得在SOFARPC在不破坏开放封闭原则的前提下，比较轻松地集合SOFATracer。SOFARPC 采用了自己实现的一套SPI机制， 通过该SPI机制动态去加载其他模块、过滤器、协议等，实现灵活拓展。SOFARPC 为了集成SOFATracer也采用了这套机制，做到可插拔。\nSofaTracerModule 类实现了Module …","date":1534921200,"description":"本文为《剖析 | SOFARPC 框架》第二篇，本篇由畅为/碧远/卓与共同出品。","dir":"blog/sofa-rpc-link-tracking/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"09e24cfad0d59d40a509e893f26c59ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-link-tracking/","publishdate":"2018-08-22T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-rpc-link-tracking/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 链路追踪剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-link-tracking/","wordcount":6480},{"author":"碧远","categories":"SOFARPC","content":" 前言 RPC 框架作为分布式技术的基石，在分布式和微服务环境下，扮演着非常重要的角色。\n在蚂蚁金服的分布式技术体系下，我们大量的技术产品（非网关类产品），都需要在内网，进行节点间通信。底层通信框架，已经在蚂蚁自研的 BOLT中的进行了实践，BOLT 提供了优秀的通信协议与通信框架，在 BOLT 的基础上，我们研发了自己的 RPC 框架，提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等基础能力，本文将从以下几个方面介绍目前已经开源的 SOFARPC 框架。\n RPC 是什么 通用 RPC 框架原理 SOFARPC 框架设计 RPC是什么 RPC 这个概念术语在上世纪 80 年代由 Bruce Jay Nelson 提出，在 Nelson 的论文 \u0026amp;ldquo;Implementing Remote Procedure Calls\u0026amp;rdquo; 中他提到了几点：\n 简单：RPC 概念的语义清晰,简单，方便建立分布式计算。 高效：在使用方看来,十分简单而且高效。 通用：通用,适用于各种不同的远程通信调用。 这里面Nelson提出了一个 RPC框架应该包含的几个部分。\n User User-stub RPC-Runtime Server-stub Server 如下图示，为了和现在我们通用的术语一致，我将 User 改成 Client 了。\n当 Client 想发起一个远程调用时，实际是通过本地调用 Client-stub，而 Client-stub 负责将调用的接口、方法和参数通过约定的协议规范进行编码并通过本地的 RPC-Runtime 实例传输到远端的实例。远端 RPC-Runtime 实例收到请求后交给 Server-stub 进行解码后发起本地端调用，在 Java中可以认为就是反射调用,调用结果再返回给 Client 端。\n从上文可以看到，一个典型的 RPC 调用过程还是相对简单的。但是实际上，一个真正的 RPC 框架要做的远不止这些。\n通用 RPC 框架原理 相信对 RPC 框架有过一定了解，或者使用过 RPC 产品的同学，在看到了图上之后，会产生几个疑问：\n1.Stub 怎么出现？\n2.怎么打包参数？\n3.怎么传输?\n4.怎么知道目标地址?\n5.怎么发布一个 RPC 服务?\n在解释这些问题之前，这里我画了一张目前通用的 RPC 框架的一个流程图：\n其中：\n1.创建代理解决了 Stub 的问题。\n2.序列化和网络协议编码解决了打包的问题。\n3.服务发现与路由寻址解决了如何知道目标地址的问题。\n4.如何发布一个服务，Registry 来解决。\n Bolt，Netty 等解决了网络传输的问题。 当然 SOFARPC 的功能不止这些,在解决了这些问题之后，根据业务的需求和实际的线上情况，我们也开发了熔断,限流,故障剔除,数据透传等能力，下面我会来介绍 SOFARPC 的框架设计。\nSOFARPC框架设计 SOFARPC RoadMap 首先介绍下目前 SOFARPC 的现状和一些正在做的事情。\n欢迎对相关功能和 feature 有兴趣的同学，一起参与开发~\nSOFARPC 结构设计 原理大家清楚之后，为了方便大家尽快上手开发使用，我先从目前的 RPC 框架结构来简单介绍。\n其中 core和 core-impl 是核心的功能，包含 API 和一些扩展机制，extension-impl 中，则包含了不同的实现和扩展，比如对 http，rest，对 metrics，以及其他注册中心的集成和扩展。\n如 bootstrap 中对协议的支持，remoting 中对网络传输的支持，registry 中对注册中心的支持等。\n在此基础上，由于 RPC 框架涉及服务端和客户端，我会结合 SOFARPC 的处理流程，详细介绍下客户端和服务端的处理。\n客户端调用流程 当使用方对服务进行了引用配置之后：\n1.RPC 生成 Proxy，作为用户可以操作的入口。\n2.向服务中心订阅这个 RPC 的地址信息。\n3.使用方发起调用，经过路由，负载均衡，各类 Filter 发起调用。\n服务端处理流程 在服务端看来,通过 TCP 监听端口后：\n1.接到 RPC 请求后，进行解码和反序列化。\n2.选择线程池，进行分发。\n3.经过 Filter，进行反射调用。\n4.将结果序列化，编码,进行写回。\n可扩展的机制 从上面的流程中，可以看到，每个部分基本都有多种实现可选，这得益于RPC的扩展机制。\n为了对 RPC 各个环节的都有充足的可扩展性，提供 SPI 的能力，所以内部的实现和第三方实现都是绝对平等的。\n相比原生 SPI，我们实现了更强大的功能\n 按需加载\n 可以有别名\n 可以有优先级进行排序和覆盖\n 可以控制是否单例\n 可以在某些场景下使用编码\n 可以指定扩展配置位置\n 可以排斥其他扩展点\n 我们实现了一套自己的 SPI 机制。整个流程如下：\n在启动加载阶段，RPC 会根据对应的配置，加载需要调用方法ExtensionLoader(Class\u0026amp;lt;T\u0026amp;gt; interfaceClass, ExtensionLoaderListener\u0026amp;lt;T\u0026amp;gt; listener) 逻辑如下：\n 首先读取rpc-config-default.json和rpc-config.json，找到扩展描述文件存放的文件夹：extension.load.path属性。\n 找到接口类对应的扩展描述文件的文件名（默认就是接口名，也可以自己指定）。\n 循环加载这个文件下的扩展描述文件，按行读取。（同一个接口的同一个别名对应唯一的一个实现类，可以重复，允许覆盖。）\n 保存扩展实现类的alias和实现类的对应关系。\n 如果 ExtensionLoaderListener 不为空，则通知 Listener。\n 最终，将会构造出各个不同的 Filter，Invoker 等等。\n其中我们首先设计了一个扩展，代表这个类或者接口是可扩展的，默认单例、不需要编码。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * 指定自定义扩展文件名称，默认就是全类名 * * @return 自定义扩展文件名称 */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * 扩展类是否使用单例，默认使用 * * @return 是否使用单例 */ boolean singleton() default true; /** * 扩展类是否需要编码，默认不需要 * * @return 是否需要编码 */ boolean coded() default false; } 同时，针对具体的扩展实现，定义一个扩展注解\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * 扩展点名字 * * …","date":1533193200,"description":"本文为 剖析 SOFARPC 框架第一篇。","dir":"blog/sofa-rpc-framework-overall-extension/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d83b816009377f7f93fcd1edf63c534d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","publishdate":"2018-08-02T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","summary":"前言 RPC 框架作为分布式技术的基石，在分布式和微服务环境下，扮演着非常重要的角色。 在蚂蚁金服的分布式技术体系下，我们大量的技术产品（非网关类产品","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之总体设计与扩展机制","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","wordcount":2629},{"author":"鲁直","categories":"SOFABoot","content":" 无论是什么样的业务系统，多多少少都会去做一些模块化的划分，或横或纵，各种姿势，但是这些姿势真地能帮你划分出良好的模块吗？帮你在模块之间做到高内聚，低耦合吗？模块化对于服务化又有什么样的影响？本来将分析常见的几种模块化方案的利弊，并且介绍蚂蚁金服开源的框架 SOFA 在模块化中发挥的作用。\n传统模块化的陷阱 在一个简单的 Spring/SpringBoot 的系统中，我们常常见到一个系统中的模块会按照如下的方式进行分层，如下图中的左边部分所示，一个系统就简单地分为 Web 层、Service 层、DAL 层。\n当这个系统承载的业务变多了之后，系统可能演化成上图中右边的这种方式。在上图的右边的部分中，一个系统承载了两个业务，一个是 Cashier（收银台），另一个是 Pay（支付），这两个业务可能会有一些依赖的关系，Cashier 需要调用 Pay 提供的能力去做支付。\n但是在这种模块化的方案里面，Spring 的上下文依然是同一个，类也没有任何做隔离，这就意味着，Pay Service 这个模块里面的任何的一个 Bean，都可以被 Cashier Service 这个模块所依赖。极端的情况下，可能会出现下面这种情况：\nCashier Service 错误地调用了 Pay Service 中的一个内部的 Bean，造成了两个模块之间的紧耦合。\n这种传统的模块化的问题在于模块化地不彻底。虽然在研发的时候，通过划分模块，把特定职责的类放到特定的模块里面去，达到了类的「物理位置」的内聚。但是在运行时，由于没有做任何隔离的手段，作为一个模块的开发者，并没有办法清楚地知道对方模块提供的对外的接口到底是什么，哪些 Bean 我是可以直接注入来用的，哪些 Bean 是你的内部的 Bean，我是不能用的。长此以往，模块和模块之间的耦合就会越来越严重，原来的模块的划分形同虚设。当系统越来越大，最后需要做服务化拆分的时候，就需要花费非常大的精力去梳理模块和模块之间的关系。\nOSGi 模块化 提到模块化，不得不提 OSGi，虽然 OSGi 没有成为 Java 官方的模块化的标准，但是由于 Java 在 Java 9 之前，一直没有官方的模块化的标准，所以 OSGi 已经是事实上的标准。\nOSGi 为模块化主要做了两个事情：\n OSGi 的类隔离 OSGi 的声明式服务 下面就给读者们简单地解释一下 OSGi 的这两个方面。\nOSGi 的类隔离 OSGi 通过扩展 Java 的 ClassLoader 机制，将模块和模块之间的类完全隔离开来，当一个模块需要引用另一个模块的类的时候，通过在模块中的 MANIFEST.MF 文件中声明类的导出和导入来解决，如下图所示：\n通过这种方式，可以控制一个模块特定的类才可以被另一个模块所访问，达到了一定程度地模块的隔离。\n但是，光光通过类的导出导入来解决类的引用问题还不够，还需要去解决实例的引用的问题，我们往往希望能够直接使用对方模块提供的某一个类的实例，而不是自己去 new 一个实例出来，所以 OSGi 还提供了声明式服务的方式，让一个模块可以引用到另一个模块提供的服务。\nOSGi 的声明式服务 OSGi 的声明式服务正是为了解决这个实例引用的问题，我们可以在一个 OSGi 的模块（Bundle）中去添加一个 XML 配置文件去声明一个服务，如下面的代码所示：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;scr:component xmlns:scr=\u0026amp;quot;http://www.osgi.org/xmlns/scr/v1.1.0\u0026amp;quot; name=\u0026amp;quot;ITodoService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;implementation class=\u0026amp;quot;com.example.e4.rcp.todo.service.internal.MyTodoServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;service\u0026amp;gt; \u0026amp;lt;provide interface=\u0026amp;quot;com.example.e4.rcp.todo.model.ITodoService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/service\u0026amp;gt; \u0026amp;lt;/scr:component\u0026amp;gt; 也可以同样的通过 XML 配置文件去引用一个其他的模块声明的服务：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;scr:component xmlns:scr=\u0026amp;quot;http://www.osgi.org/xmlns/scr/v1.1.0\u0026amp;quot; name=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;reference name=\u0026amp;quot;ITodoService\u0026amp;quot; interface=\u0026amp;quot;com.example.e4.rcp.todo.model.ITodoService\u0026amp;quot; bind=\u0026amp;quot;setITodoService\u0026amp;quot; cardinality=\u0026amp;quot;0..1\u0026amp;quot; unbind=\u0026amp;quot;unsetITodoService\u0026amp;quot; policy=\u0026amp;quot;dynamic\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;implementation class=\u0026amp;quot;com.example.e4.rcp.todo.service.internal.XXXServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/scr:component\u0026amp;gt; 通过声明式服务的方式，我们就可以直接在一个 OSGi 的 Bundle 中使用另一个 Bundle 中提供的服务实例了。\nOSGi 的模块化的问题 OSGi 通过类隔离的机制解决了模块之间的类隔离的问题，然后通过声明式服务的方式解决了模块之间的服务调用的问题，看起来已经完美的解决了我们在传统的模块化中遇到的问题，通过这两个机制，模块和模块之间的边界变得清晰了起来。\n但是在实践的过程中，OSGi 的模块化却面临着一个非常严峻的问题，这个就是就是 OSGi 的类隔离带来的复杂性，OSGi 把每一个模块都通过独立的 ClassLoader 去加载，这样在开发模块的时候，研发的同学就必须非常清楚地去定义哪些类应该导出，哪些类应该导入，一旦少导出，或者导出错误，就会出现各种各样的错误，比如 LinkageError，NoSuchMethodError 等等，而要解决这些错误，要求研发同学清楚地理解 OSGi 的整个类加载体系，以及 Java 的整个类加载体系，这对普通的研发同学来说实在是一个太高的要求。所以这种方式在实施成本非常高，OSGi 并不是非常适合于业务研发。\nSOFA 模块化 为了解决传统的模块化方案模块化不彻底的问题，以及 OSGi 的彻底的模块化带来的复杂性的问题，SOFA 在早期就开始引入了一种折衷的模块化的方案。\nSOFA 模块化的整体的示意图如下：\nSOFA 模块化的方 …","date":1532520754,"description":"本来将分析常见的几种模块化方案的利弊，并且介绍蚂蚁金服开源的框架 SOFA 在模块化中发挥的作用。","dir":"blog/sofastack-modular-isolation/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"796c3ab365dd1191a7777c4dbf9d0a1b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-modular-isolation/","publishdate":"2018-07-25T12:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-modular-isolation/","summary":"无论是什么样的业务系统，多多少少都会去做一些模块化的划分，或横或纵，各种姿势，但是这些姿势真地能帮你划分出良好的模块吗？帮你在模块之间做到高","tags":["SOFABoot"],"title":"蚂蚁金服的业务系统模块化之模块化隔离方案","type":"blog","url":"/sofastack.tech/blog/sofastack-modular-isolation/","wordcount":2688},{"author":"玄北","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力，SOFABoot 模块除了包括 Java 代码外，还会包含 Spring 配置文件，每个 SOFABoot 模块都是独立的 Spring 上下文。\n1. 背景 为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式：\n 基于代码组织上的模块化：这是最常见的形式，在开发期，将不同功能的代码放在不同 Java 工程下，在编译期被打进不同 jar 包，在运行期，所有 Java 类都在一个 classpath 下且使用同一个 Spring 上下文，没做任何隔离； 基于 Spring 上下文隔离的模块化：使用 Spring 上下文来做不同功能模块的隔离，在开发期和编译期，代码和配置也会分在不同 Java 工程中，但在运行期，不同的 Spring Bean 相互不可见，IoC 只在同一个上下文内部发生，但是所有的 Java 类还是在一个 ClassLoader 下； 基于 ClassLoader 隔离的模块化：借用 ClassLoader 来做隔离，每个模块都有独立的 ClassLoader，模块与模块之间的 classpath 不同，SOFAArk 就是这种模块化的实践方式。 以上三种模块化形式的隔离化程度逐次递进，但模块化就像一把双刃剑，在降低模块间耦合的同时也给模块间交互增加了成本，本文介绍第二种模块化形式 —— 基于 Spring 上下文隔离的模块化。\n与基于代码组织上的模块化相比，每个 SOFABoot 模块不仅仅包括 Java 代码，还会包含 Spring 配置文件，这种全新的包组织方式大大降低了用户接入成本，用户只需要简单的引入 Jar 包即可，由 SOFABoot 框架负责刷新模块上下文，无需在原来 Spring 配置文件中新增任何 Bean 定义，简化了接入流程，降低了出错几率。\n每个 SOFABoot 模块的 Spring 上下文都是隔离的。在 Spring 开发中，保证 Spring BeanId 不冲突是 Spring 运行的基础，这个限制在应用规模较小时很容易解决，只需用户在定义 BeanId 时稍加注意即可。但是随着系统规模越来越大，一个系统的开发往往涉及多个团队，保证每个业务定义 BeanId 不重复的成本也越来越高。在 SOFABoot 中，每个 SOFABoot 模块使用独立的 Spring 上下文，避免了不同 SOFABoot 模块间 BeanId 冲突，有效降低企业级多模块开发时团队间的沟通成本。\n2. 基本原理 在介绍 SOFABoot 模块化开发使用之前，我们简单了解下其背后的实现原理。下图是应用运行时的逻辑视图：\nSOFABoot 模块是模块化开发的最小单元，每个 SOFABoot 模块是一个独立的 Spring 上下文，在 SOFABoot 模块中我们可以定义Bean、发布 RPC 服务、连接数据库等等。\n由于上下文隔离，模块与模块之间的 Bean 无法通过 @Autowired 依赖注入，我们提供了 JVM Service/Reference 的方式进行模块间通信。SOFABoot 提供了两种形式的服务发布和引用，用于解决不同级别的模块间调用问题：\n JVM 服务发布和引用：解决一个 SOFABoot 应用内部各个 SOFABoot 模块之间的调用问题 RPC 服务发布和引用：解决多个 SOFABoot 应用之间的远程调用问题 Spring Boot 应用在调用 SpringApplication.run 时会创建一个 Spring Context，我们把它叫做 Root Application Context，它是每个 SOFABoot 模块创建的 Spring Context 的 Parent。这样设计的目的是为了保证每个 SOFABoot 模块的 Spring Context 都能发现 Root Application Context 中创建的 Bean，这样当应用新增 Starter 时，不仅 Root Application Context 能够使用 Starter 中新增的 Bean，每个 SOFABoot 模块的 Spring Context 也能使用这些 Bean。\n下面我们来演示如何开发一个简单的 SOFABoot 模块。\n3. 编写 SOFABoot 模块 3.1 新建工程 DEMO 工程地址\n运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，并创建两个普通的 Maven 模块：\n service-facade: 定义服务接口 service-provide: 演示新建 SOFABoot 模块并发布 JVM 服务 3.2 定义服务接口 service-facade 模块包含用于演示 SOFABoot 模块发布与引用服务接口:\npublic interface SampleService { String message(); } 3.3 定义 SOFABoot 模块 service-provider 是一个 SOFABoot 模块，它会发布一个 JVM 服务供其他模块使用。首先需要为 service-provider 模块增加 sofa-module.properties 文件，将其定义为 SOFABoot 模块，sofa-module.properties 文件放置在 resources 目录:\nModule-Name=com.alipay.sofa.service-provider 3.4 发布服务 SOFABoot 支持三种形式的服务发布，分别是： XML 方式、Annotation 方式以及 API 编码方式，这里演示的是 XML 方式发布服务。\n首先增加 SampleServiceImpl 类，实现 SampleService 接口：\npublic class SampleServiceImpl implements SampleService { private String message; public String message() { return message; } public String getMessage() { return message; } public void setMessage(String message) { this.message = message; } } 增加 META-INF/spring/service-provide.xml 文件，将 SampleServiceImpl 发布为 JVM 服务:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; …","date":1532175154,"description":"本文是对蚂蚁金服开源的 SOFABoot 模块化开发的介绍。","dir":"blog/sofa-boot-modular-development/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"12a378e9b4d93d3dd89e79964b63d186","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-modular-development/","publishdate":"2018-07-21T12:12:34Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-boot-modular-development/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力，SOFABoot 模块除","tags":["SOFABoot"],"title":"基于 SOFABoot 进行模块化开发","type":"blog","url":"/sofastack.tech/blog/sofa-boot-modular-development/","wordcount":2209},{"author":"善逝","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力，以更好地解决随着工程应用变得臃肿庞大后带来的包冲突问题。类隔离能力天生带来模块化能力，同样给协作开发带来便利。\nSOFABoot 的类隔离能力借助单独的组件 SOFAArk 实现，遵循 Spring Boot 依赖即服务的思想，只要工程中引入了 SOFAArk 组件依赖，类隔离能力即生效。\n在上一篇文章 《在 Spring Boot 中集成 SOFABoot 类隔离能力》中，我们详细介绍了 SOFABoot 类隔离能力的使用背景及其使用方式。本文将介绍 SOFABoot 类隔离组件 SOFAArk 的实现原理。\n理解 SOFAArk 三要素 SOFAArk 类隔离框架定义了三个概念，Ark Container，Ark Plugin，Ark Biz。\n在介绍这三个主角之前，我们先来介绍另一个管家：Ark 包。我们都知道一个标准的 Spring Boot 应用可以借助 Spring 官方提供的打包插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 将应用打包成一个可执行 FatJar。相对应的，Ark 包则是 SOFABoot 官方提供的打包插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 将应用打包成一个具有类隔离能力的可执行 FatJar，称之为 Ark 包。下图是粗略地对比两者的目录结构差别：\n可以看到 Ark 包作为应用部署包的分发格式，它包含有 Ark Container，Ark Plugin 和 Ark Biz 三种格式模块。这里我们不对 Ark 包或者其他格式模块的目录结构作分析，感兴趣的同学可以点开文末附上的相关链接。我们重点介绍这三个角色的功能。\n Ark Container: Ark 容器，是组件 SOFAArk 的核心，运行 Ark 包时，Ark 容器会最先启动，负责应用运行时的管理，主要包括构建 Ark Plugin 和 Ark Biz 的类导入导出关系表、启动并初始化 Ark Plugin 和 Ark Biz、管理 Ark Plugin 服务的发布和引用等等。 Ark Plugin: SOFAArk 定义的一种模块格式，由若干个 Jar 包组成的一个 FatJar，开发人员可以借助官方提供的 maven 打包插件将若干 Jar 包打包成一个 Ark Plugin 供应用依赖。运行时，由独立的类加载器加载，因此有隔离需求的 Jar 包建议打包成 Ark Plugin 供应用依赖。 Ark Biz: SOFAArk 定义的一种模块格式，是应用及其依赖的所有三方包组成的一个 FatJar，需要注意的是，Ark Biz 不会包含应用依赖的 Ark Plugin。运行时，Ark Biz由独立的类加载器加载，借助类导入导出关系表，Ark Biz 可以使用 Ark Plugin 的导出类和资源。 SOFAArk 运行时隔离 根据上一节的描述可以知道 SOFABoot 类隔离关键是理解 SOFAArk 定义的三个概念，Ark Container，Ark Plugin 和 Ark Biz。下图表示的是应用启动后，运行时 Ark Container，Ark Plugin，Ark Biz 的逻辑分层图：\n我们将先以 Ark Plugin 入手来介绍 SOFABoot 类隔离的实现原理。\nArk Plugin 隔离 开发者借助 SOFABoot 官方提供的插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 可以将 Java 模块打包成一个 Ark Plugin，这里我们不讨论该打包插件的配置参数和使用方式，感兴趣的同学可以点开文末附上的相关链接以及学习 SOFABoot 类隔离能力使用篇。只需要知道，Ark Plugin 主要包含元信息有：插件启动器、导出类、导入类、导出资源、导入资源、优先级等，这些元信息保存在 Ark Plugin 中的 META-INF/MANIFEST.MF 中，一份典型的 MANIFEST.MF 文件样式如下：\nManifest-Version: 1.0 groupId: com.alipay.sofa artifactId: sample-ark-plugin version: 0.3.0-SNAPSHOT priority: 1000 pluginName: sample-ark-plugin activator: com.alipay.sofa.ark.sample.activator.SamplePluginActivator import-packages: import-classes: import-resources: export-packages: com.alipay.sofa.ark.sample.common.*,com.alipay.sofa.ark.sample export-classes: com.alipay.sofa.ark.sample.facade.SamplePluginService export-resources: Sample_Resource_Exported 在上面我们提到，运行 Ark 包时，类隔离容器 Ark Container 会最先启动，然后 Ark Container 会接管整个应用的启动过程。针对 Ark Plugin 处理逻辑如下：\n 首先解析 Ark 包中引入的所有 Ark Plugin，读取插件元信息，构建类/资源导入导出关系索引表。 提前生成所有插件类加载器，每个 Ark Plugin 都使用独立的类加载器，管理插件类加载逻辑，借助第一步生成的类导入导出关系表，突破 Java 原生的双亲委派模型，可以委托其他插件加载所需类，构建一个类 OSGi 的网状类加载模型。 根据插件优先级，依次调用插件启动器。在插件启动器中，插件开发者可以向容器注册服务以方便其他插件引用，也可以引用其他插件发布的服务，及插件启动所需的初始化操作。 需要明确一点，为了让类加载模型足够简单，Ark 容器在启动任何插件前，会把所有的插件类加载器提前构建完毕。Ark Plugin 可以相互委托加载，插件优先级只是影响插件的启动顺序，而且也不强制 …","date":1528107154,"description":"本文将介绍 SOFABoot 类隔离组件 SOFAArk 的实现原理。","dir":"blog/sofa-boot-class-isolation-deep-dive/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"84c324f1230d57a0c4009566de91bb3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","publishdate":"2018-06-04T10:12:34Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力，以更好地解决随着工程应用变得臃肿庞大后带来的包冲","tags":["SOFAArk","SOFABoot"],"title":"SOFABoot 类隔离原理剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","wordcount":3540},{"author":"余淮","categories":"SOFAStack","content":" 蚂蚁金服自主研发的分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件），包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\n一个多月前，蚂蚁金服开源了 SOFABoot 和 SOFARPC 两个组件，受到了社区的热烈欢迎，也收到了很多社区的反馈，其中就有提到目前开源的组件太少。\n本次 SOFA 中间件将继续开源微服务体系下的几个组件：包括分布式链路追踪（SOFATracer）客户端、Metrics监控度量（SOFALookout）客户端、SOFARPC 的 Nodejs 版实现。同时还开源了 SOFABoot 下的模块化开发框架，以及 SOFARPC 的 HTTP/2 能力等。\n下面将逐一进行简单介绍。\nSOFATracer SOFATracer 是一个用于分布式系统调用跟踪的中间件，通过统一的 traceId 将调用链路中的各种网络调用信息以日志或者上报的方式记录下来，以达到透视化网络调用的目的。这些日志可用于故障的快速发现，数据统计，服务治理等。为了解决在实施大规模微服务架构时的链路跟踪问题，SOFATracer 基于 OpenTracing（http://opentracing.io） 规范并扩展其能力，包括基于 Disruptor 高性能无锁循环队列的异步落地磁盘的日志打印能力，自定义日志格式，日志自清除和滚动能力，基于 SLF4J MDC 的扩展能力，统一的配置能力等。同时 SOFATracer 也对接了开源生态，可以选择将 Tracer 数据对接到 Zipkin 等开源产品。\nSOFATracer 的 Github 的地址是：https://github.com/sofastack/sofa-tracer ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFALookout SOFALookout 是一个利用多维度的 Metrics 对目标系统进行度量和监控的中间件。Lookout 的多维度 Metrics 参考 Metrics 2.0（http://metrics20.org/spec） 标准，提供一整套 Metrics 的处理，包括数据埋点、收集、加工、存储与查询等。SOFALookout 包括客户端与服务器端服务两部分，本次先开源客户端部分，服务端部分代码在整理中。 SOFALookout 客户端提供了一套 Metrics API 标准，通过它可以方便地对 Java 应用的 Metrics 进行埋点统计。为了方便使用，SOFALookout 客户端默认提供一些扩展模块，它们提供 JVM，OS 等基本 Metrics 信息的统计，遵循该扩展机制，我们可以自定义或集成更多的 Metrics 数据。另外，SOFALookout 客户端除了支持向 SOFALookout 服务端上报数据外，还支持与社区主流的相关产品，包括 Dropwizard,（SpringBoot）Actuator 以及 Prometheus 等进行集成和数据适配。\nSOFALookout 的 Github 的地址是：https://github.com/sofastack/sofa-lookout ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nEggjs 集成 每种语言都有自己最擅长的领域，跨语言友好性对于分布式架构也是非常重要的。在蚂蚁内部还有一套 Nodejs 版本的 SOFA 中间件的实现，包含了绝大部分 Java 版本的功能，并将它们集成到已经开源的企业级 Nodejs 框架 Eggjs（https://eggjs.org） 中，形成了一套完整的 Web MVC 和 BFF (Backend For Frontend) 解决方案。这套架构目前广泛应用于蚂蚁的 Web 开发和多端适配等场景，让各岗位有了更清晰的职责划分，服务端（一般是 Java）提供基于领域模型的 RPC 接口，前端调用接口拿到数据后进行剪裁和格式化，并实现人机交互。领域模型与页面数据是两种思维模式，通过分层可以很好地解耦，让彼此更专业高效。后面我们也会陆续开源 SOFA 中间件的 Nodejs 版本实现，本期会先放出 SOFARPC 相关的两个模块：\nSOFARPC Node 的 Github 的地址是：https://github.com/sofastack/sofa-rpc-node ， SOFABolt Node 的 Github 的地址是：https://github.com/sofastack/sofa-bolt-node ， 欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFABoot 在最新的 SOFABoot 2.4.0 版本中，SOFABoot 新增加了基于 Spring 上下文隔离的模块化开发能力。在企业级应用场景，随着应用系统模块的增多，每个业务模块之间的耦合也会越来越严重，业务模块的自测更加复杂，团队之间的沟通成本增加。模块化开发是该问题的有效解决方案，但是 Spring Boot 默认不支持模块化开发，所有 Bean 共用一个 Spring 上下文。为此，SOFABoot 提出 SOFABoot 模块的概念，每个业务团队专注于开发自己的 SOFABoot 应用模块，模块自包含模块的代码和配置，拥有独立的 Spring 上下文，便于开发及自测，减少团队间的沟通成本。SOFABoot 模块间通信使用 JVM 服务进行通信，避免模块之间的耦合；如果远程服务在本地其它本地模块中存在，可优先调本地提高性能。同时 SOFABoot 提供了模块并行启动及 Bean 异步初始化能力，大幅提高应用启动速度。\nSOFABoot 的 Github 的地址是：https://github.com/sofastack/sofa-boot ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFARPC 在最新的 SOFARPC 5.4.0 版本中，SOFARPC 基于事件扩展机制，集成了 SOFATracer 和 SOFALookout 两个微服务体系产品，完善了自身的服务监控度量以及分布式跟踪功能。用户可以通过 SOFATracer 对接到 Zipkin 查看服务调用跟踪信息，也可以通过 SOFALookout 对接到 Prometheus 查看服务度量信息。新版本的 SOFARPC 中还增加了 HTTP/1.1 和 HTTP/2 协议的支持，在跨语言等场景下可以快速通过标准的 HTTP 协议进行通信。SOFARPC 也与 Eggjs 进行了打通了 Bolt 协议，方面用户在 Java 和 Nodejs 之间高效通信。\nSOFARPC 的 Github 的地址 …","date":1527761554,"description":"本次 SOFA 中间件将继续开源微服务体系下的几个组件：包括分布式链路追踪（SOFATracer）客户端、Metrics监控度量（SOFALookout）客户端、SOFARPC 的 Nodejs 版实现。同时还开源了 SOFABoot 下的模块化开发框架，以及 SOFARPC 的 HTTP/2 能力等。","dir":"blog/sofastack-open-source-doubles/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"00f2a1c85bfe83bf9f25ef1af9c44366","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-open-source-doubles/","publishdate":"2018-05-31T10:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-open-source-doubles/","summary":"蚂蚁金服自主研发的分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件），包含了构建金融级云原生架构所需的各个组件，","tags":["SOFAStack"],"title":"蚂蚁金服分布式中间件开源第二弹：丰富微服务架构体系","type":"blog","url":"/sofastack.tech/blog/sofastack-open-source-doubles/","wordcount":2957},{"author":"善逝","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力。蚂蚁金服内部丰富的实践场景表明，类隔离能力对解决类冲突、版本管控有其特殊的优势。\nSOFABoot 的类隔离能力由单独的组件 SOFAArk 实现，相比业界遵循 OSGi（https://www.osgi.org/） 规范的 Equinox 或者 Felix，SOFAArk 专注于类隔离，简化了类加载模型，是一款更加轻量的类隔离框架。\n本文将介绍 SOFABoot 类隔离能力的背景及其使用方式。\n1. 背景 在 Java 世界中，依赖的 JAR 包之间相互冲突永远是一个痛，Spring Boot 采用统一的依赖管理机制规避了大部分依赖冲突问题。理想很美好，现实却很骨感，作为蚂蚁金服这类大体量的公司，各业务线纷繁复杂、基础服务组件繁多，很难做到对所有 JAR 包做统一管控，尤其涉及到多个跨团队模块组件相互依赖时，因为各自技术栈历史包袱的存在，难以有效统一冲突包版本。\n假设如下场景，工程需要引入两个三方组件：A 和 B，组件 A 需要依赖 Hessian 3，组件 B 需要依赖 Hessian 4，因为 Hessian 3 和 Hessian 4 是不兼容的。作为开发者，遇到这种包冲突问题，如果不借助类隔离框架，只能耗费精力升级到统一版本。\n为了彻底解决类似的包冲突问题，我们需要借助类隔离机制，使用不同的类加载器加载冲突的三方依赖包，进而做到在同一个应用运行时共存。\n基于此背景，SOFABoot 提供了一个轻量级的类隔离框架，也是本文的主角，SOFAArk。\n2. 基本原理 在介绍 SOFAArk 类隔离框架使用之前，我们简单了解下其背后的实现原理。正如前文中描述，SOFAArk 是通过独立的类加载器加载相互冲突的三方依赖包，从而做到隔离包冲突。那么我们不禁要问，SOFAArk 是如何区分应用中哪些依赖包是需要单独的类加载器加载呢？原因是 Ark Plugin，它是 SOFAArk 框架定义的一种特殊的 JAR 包文件格式，SOFAArk 框架会自动识别 Ark Plugin 这种特殊依赖。\n何为 Ark Plugin ? Ark Plugin 本质上是一个 FatJar，借助 SOFABoot 官方提供的 maven 打包插件，开发者可以把若干普通的 JAR 包打包成 Ark Plugin 供应用依赖或者把普通的 Java 模块改造成 Ark Plugin。通常来说，如果把一个普通 JAR 打包成 Ark Plugin，那么该 JAR 包依赖的其他三方包也会被打入同一个 Ark Plugin，默认情况下 SOFABoot 官方打包插件会自动把间接依赖也打入到 Ark Plugin。\n应用使用添加 maven 依赖的方式引入 Ark Plugin，运行时，SOFAArk 框架会自动识别应用的三方依赖包中是否含有 Ark Plugin，进而使用单独的类加载器加载。为了更加直观，下图是应用运行时逻辑分层图：\n可以看到，在应用运行时，SOFAArk 容器处于最底层，负责启动应用。应用依赖的所有 Ark Plugin 处于中间层，每个 Ark Plugin 都由 SOFAArk 容器使用独立的类加载器加载，相互隔离。应用业务代码及其他非 Ark Plugin 的普通三方依赖包，为了描述简单，统称为 Ark Biz，它运行在最上层，需要依赖中间层的 Ark Plugin。\n一个标准 Ark Plugin 会包含一些配置文件，主要包含导出类和导入类配置。导出类即把 Ark Plugin 中的类导出给 Ark Biz 和其他 Ark Plugin 可见。默认情况下，所有 Ark Plugin 的导出类对于 Ark Biz 来说都是可见的，即 Ark Biz 可以使用 Ark Plugin 的导出类。对于 Ark Plugin 来说，如果需要使用其他 Ark Plugin 的导出类，必须声明为自身的导入类。关于 Ark Plugin 详细说明可以参考文末相关链接。\n下面我们来演示如何开发一个简单的 Ark Plugin。\n3. Java 模块改造成 Ark Plugin 3.1 新建工程 Demo 工程参见：https://github.com/QilongZhang/ark-plugin-demo\n运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，并创建三个普通的 Java 模块。以前文描述的 Hessian 冲突为例，在演示工程中定义了三个模快：\n pojo-module: 定义了一个简单的 PoJo 类 SamplePoJo，并设置为导出类，打包成 pojo-ark-plugin 。 hessian3-module：定义了一个服务类 Hessian3Service，实现了简单的序列化和反序列逻辑，使用的版本是 Hessian 3，并导入了 SamplePoJo，打包成 hessian3-ark-plugin 。 hessian4-module：定义了一个服务类 Hessian4Service，和 Hessian3Service 功能类似，使用的版本是 Hessian 4，并导入了 SamplePoJo，打包成 hessian4-ark-plugin 。 该用例是为了演示如何将普通的 Java 模块及其三方依赖包打包成 Ark Plugin，以 hessian3-module 模块为例来讲解打包流程。\n3.2 编写服务类 在 hessian3-module 中，提供了一个简单的序列化和反序列化功能类 Hessian3Service：\npackage com.alipay.sofa.demo.hessian3; import com.caucho.hessian.io.HessianInput; import com.caucho.hessian.io.HessianOutput; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; /** * @author qilong.zql */ public class Hessian3Service { public byte[] serialize(Object obj) throws IOException { if(obj==null) throw new NullPointerException(); ByteArrayOutputStream os = new ByteArrayOutputStream(); HessianOutput ho = new HessianOutput(os); ho.writeObject(obj); return os.toByteArray(); } public Object deserialize(byte[] by) throws …","date":1526465554,"description":"本文将介绍 SOFABoot 类隔离能力的背景及其使用方式。","dir":"blog/spring-boot-sofa-boot-class-isolation-integration/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c22dd2791732b32177419ff678b34546","permalink":"https://sofastack.github.io/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","publishdate":"2018-05-16T10:12:34Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力。蚂蚁金服内部丰富的实践场景表明，类隔离能力对解决","tags":["SOFABoot","SpringBoot","SOFAArk"],"title":"在 Spring Boot 中集成 SOFABoot 类隔离能力","type":"blog","url":"/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","wordcount":3524},{"author":"绍辉","categories":"Seata","content":" 上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。\nSeata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。项目地址：https://github.com/seata/seata\n蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n为了帮助大家理解，分布式事务开源负责人绍辉进行了一次线下分享，详细讲述了分布式事务在蚂蚁金服的发展，希望可以帮助大家理解分布式事务，以下为分享的文字整理版本。\n前言 今天的分享将从以下三个部分展开：分布式事务问题产生的背景、蚂蚁金服分布式事务以及分布式事务 Seata 的 Roadmap。\n分享嘉宾：绍辉 蚂蚁金服 分布式事务开源负责人\n1、分布式事务问题产生的背景 1.1、数据库的水平拆分 蚂蚁金服早期，业务量比较小，单库单表便能满足业务需求；但是随着业务的发展，单库单表数据库逐渐成为瓶颈。为了解决数据库的瓶颈问题，我们对数据库进行了水平拆分。拆分所带来的一个问题就是以前一个数据库上便能完成的写操作现在要跨多个数据库，由此带来了跨库事务问题。\n1.2、业务的服务化拆分 蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个 APP 中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，由此产生了跨服务事务问题。\n1.3、转账案例说明数据一致性问题 数据库的水分拆分以及服务的垂直拆分，所带来的问题是一个业务活动通常要调用多个服务、访问多个数据库才能完成。\n以金融业务场景下的转账场景为例，转账服务要完成以下操作：\n 调用交易系统服务创建交易订单； 调用支付系统记录支付明细； 调用账务系统执行 A 扣钱； 调用账务系统执行 B 加钱。 以上 4 个操作要跨 3 个系统，访问 4 个数据库。而网络、数据库、机器等都具有不可靠性，我们很难保证以上 4 个操作能 100% 全部成功。\n在金融属性的业务中，不允许 A 账户的钱扣了，而 B 账户的钱没有加上的现象出现，所以我们必须想办法保证 1 ~ 4 这四个操作要么全部成功，要么全部失败；所以蚂蚁金服自主研发了分布式事务中间件，解决跨服务、跨数据库的数据一致性问题。\n2、蚂蚁金服分布式事务 2.1、分布式事务理论基础 在介绍蚂蚁金服的分布式事务中间件之前，先介绍一些分布式事务的理论背景。\n 2PC 两阶段提交协议（Two Phase Commitment Protocol）是分布式事务最基本的协议。在两阶段提交协议中，有一个事务管理器和多个资源管理器，事务管理器分两阶段协调资源管理器。在第一阶段，事务管理器询问所有资源管理器准备是否成功。如果所有资源均准备成功，那么在第二阶段事务管理器会要求所有资源管理器执行提交操作；如果任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求所有资源管理器在第二阶段执行回滚操作。通过事务管理器的两阶段协调，最终所有资源管理器要么全部提交，要么全部回滚，最终状态都是一致的。\n TCC 资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现。TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题。TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中。事务管理器分两个阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法，最终所有 TCC 服务要么全部都是提交的、要么全部都是回滚的。\n2.2、蚂蚁金服分布式产品介绍 蚂蚁金服从 2007 年开始做分布式事务，至今已经有 12 年历史。蚂蚁金服的分布式事务最初是采用 TCC 实现的，TCC 模式帮蚂蚁业务解决了各类金融核心场景下的数据一致性问题。\n2007 年我们开始支持双十一，为了满足双十一的高性能需求，我们对分布式事务做了一系列的性能优化。\n2013年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014年，蚂蚁金服分布式事务中间件开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户；在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。\n所以在 2015年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务中间件经过长期演进，目前积累了 TCC、FMT 和 XA 三种模式，具有丰富的应用场景。下面分别介绍这三种模式。\n2.3、TCC 模式 蚂蚁金服的 TCC 模式和前面介绍 TCC 理论中提的 TCC 原理是一致的。不同的是，我们在整个分布式事务执行过程中，会去记录事务日志，一个分布式事务会产生一条主事务记录（对应发起方）和若干分支事务记录（对应 TCC 参与者）。记录事务日志的目的是，当分布式事务执行过程中出现异常中断时，事务恢复服务通过轮询事务日志，找出这个异常中断的事务，补偿执行该异常事务剩余未完成的动作，整个分布式事务的最终状态要么全部提交，要么全部回滚。\nTCC 设计规范和注意事项：\n用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。经过蚂蚁金服多年的 TCC 应用实践，总结如下在 TCC 设计和实现过程中的注意事项：\n1、业务操作分两阶段完成： 接入 TCC 前，业务操作只需要一步就能完成。但是在接入 TCC 之后，需要考虑如何将其分成两个阶段完成：把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户 A 的余额中有 100 元，需要扣除其中 30 元”。\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成两步完成：\n Try 操作：资源的检查和预留。 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交。 在扣款场景下，Confirm 阶段做的事 …","date":1526465554,"description":"上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。","dir":"blog/seata-distributed-transaction-open-source/","fuzzywordcount":5000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"acb90bbbf0e7ec7dfb8c797bbd94efee","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-distributed-transaction-open-source/","publishdate":"2018-05-16T10:12:34Z","readingtime":10,"relpermalink":"/sofastack.tech/blog/seata-distributed-transaction-open-source/","summary":"上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式","tags":["Seata"],"title":"蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/seata-distributed-transaction-open-source/","wordcount":4977},{"author":"鲁直","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 的健康检查的基础上，加上了 Readiness Check 的能力，以更好地适应大规模金融级的服务化场景，防止在应用启动有问题的情况下让外部流量进入应用。在本文中，我们将通过 Kubernetes 来演示 SOFABoot 的 Readiness Check 的能力，主要涉及到两个部分的能力的演示：\n SOFABoot 的 Readiness Check 失败之后，SOFABoot 不会将发布的 RPC 服务的地址注册到 ZooKeeper 上面，防止 RPC 的流量进入。 Kubernetes 通过 http://localhost:8080/health/readiness 访问到 SOFABoot 的 Readiness 检查的结果之后，不会将 Pod 挂到对应的 Service 之上，防止 Kubernetes 上的流量进入。 准备一个 Kubernetes 的环境 为了演示在 Kubernetes 中使用 SOFABoot 的 Readiness Check 的能力，首先需要准备好一个 Kubernetes 的环境，在这个例子中，我们直接选择在本机安装一个 minikube，minikube 是 Kubernetes 为了方便研发人员在自己的研发机器上尝试 Kubernetes 而准备的一个工具，对于学习 Kubernetes 的使用非常方便。关于如何在本机安装 minikube，大家参考这个官方的安装教程即可。\n安装完成以后，大家可以直接终端中使用 minikube start来启动 minikube。\n需要注意的是，由于国内网络环境的问题，直接用 minikube start 可能会无法启动 minikube，如果遇到无法启动 minikube 的问题，可以尝试加上代理的设置，大家可以参考以下的命令来设置代理服务器的地址：\nminikube start --docker-env HTTP_PROXY=http://xxx.xxx.xxx.xxx:6152 --docker-env HTTPS_PROXY=http://xxx.xxx.xxx.xxx:6152 在 Kubernetes 上安装一个 ZooKeeper 在准备好了 Kubernetes 的环境之后，我们接下来需要在 Kubernetes 上安装一个 ZooKeeper 作为 SOFARPC 的服务自动发现的组件。首先我们需要有一个 ZooKeeper 的 Deployment：\napiVersion: apps/v1beta1 kind: Deployment metadata: name: zookeeper-deployment labels: app: zookeeper spec: replicas: 1 selector: matchLabels: app: zookeeper template: metadata: labels: app: zookeeper spec: containers: - name: zookeeper image: zookeeper imagePullPolicy: IfNotPresent ports: - containerPort: 2181 这个 Deployment 会部署一个 ZooKeeper 的实例，并且将 2181 端口暴露出来。\n有了这个 YAML 文件之后，我们再部署一个 Service 来作为 ZooKeeper 的负载均衡，这样我们在应用中就可以直接通过域名来访问，而不用 IP 来访问 ZooKeeper 了。这个 Service 的 Yaml 文件如下：\napiVersion: v1 kind: Service metadata: name: zookeeper-service spec: selector: app: zookeeper ports: - protocol: TCP port: 2181 targetPort: 2181 这个 Service 直接将 2181 端口映射到 ZooKeeper 的 2181 端口上，这样，我们就可以在应用中直接通过 zookeeper-service:2181 来访问了。\n准备一个 SOFABoot 的应用 在前面的两步都 OK 之后，我们需要准备好一个 SOFABoot 的应用，并且在这个应用中发布一个 SOFARPC 的服务。首先，我们需要从 start.spring.io 上生成一个工程，例如 GroupId 设置为 com.alipay.sofa，ArtifactId 设置为 rpcserver。\n生成好了之后，接下来，我们需要把 SOFABoot 的依赖加上，将 pom.xml 中的 parent 修改成：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 然后，增加一个 SOFARPC 的 Starter 的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 接着，在 application.properties 里面加上我们的配置，包括应用名和 ZooKeeper 的地址：\n# Application Name spring.application.name=SOFABoot Demo # ZooKeeper 的地址 com.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 上面的事情准备好之后，我们可以在应用中发布一个服务，首先，我们需要分别声明好一个接口和一个实现：\npackage com.alipay.sofa.rpcserver; public interface SampleService { String hello(); } package com.alipay.sofa.rpcserver; public class SampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } 接下来，将这个接口和实现发布成一个 SOFARPC 的服务，我们可以新建一个 src/main/resources/spring/rpc-server.xml 的文件：\n\u0026amp;lt;?xml …","date":1525428754,"description":"在本文中，我们将通过 Kubernetes 来演示 SOFABoot 的 Readiness Check 的能力。","dir":"blog/sofa-boot-readiness-check-in-kubernetes/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4018d6494df0e7ecde1c4911610fc89c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","publishdate":"2018-05-04T10:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 的健康检查的基础上，加上了 Readiness Check 的能力，以更好地适应大规模金融级的服务化场景，防止","tags":["SOFABoot","Kubernetes"],"title":"在 Kubernetes 中使用 SOFABoot 的 Readiness Check 能力","type":"blog","url":"/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","wordcount":2732},{"author":"余淮","categories":"SOFARPC","content":" SOFARPC 是近期蚂蚁金服开源的一个高可扩展性、高性能、生产级的 Java RPC 框架。在蚂蚁金服 SOFARPC 已经经历了十多年及五代版本的发展。SOFARPC 致力于简化应用之间的 RPC 调用，为应用提供方便透明、稳定高效的点对点远程服务调用方案。为了用户和开发者方便的进行功能扩展，SOFARPC 提供了丰富的模型抽象和可扩展接口，包括过滤器、路由、负载均衡等等。\nSOFARPC 可以集成多种注册中心实现，其中一种就是常用的 ZooKeeper。\nZooKeeper 作为一个开源的分布式应用协调系统，已经用到了许多分布式项目中，用来完成统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等工作。\n本文将介绍 SOFARPC 是使用 ZooKeeper 作为注册中心的用法。\n1. ZooKeeper 注册中心安装 这里介绍下 Zookeeper 单机模式两种安装方式，集群模式请参考下其他文档。\n1.1 基于压缩包安装 第一步：去官网下载 http://zookeeper.apache.org/releases.html#download 例如目前最新版是 v3.4.11，我们下载压缩包zookeeper-3.4.11.tar.gz，然后解压到文件夹下，例如 /home/admin/zookeeper-3.4.11。\n第二步：设置配置文件，可以直接从样例复制一份。\n$ cd /home/admin/zookeeper-3.4.11 $ cp conf/zoo_sample.cfg conf/zoo.cfg 第三步：到 Zookeeper 安装目录下直接启动Zookeeper。\n$ cd /home/admin/zookeeper-3.4.11 $ sh bin/zkServer.sh start ZooKeeper JMX enabled by default Using config: /Users/zhanggeng/dev/zookeeper/bin/../conf/zoo.cfg -n Starting zookeeper ... STARTED 第四步：我们使用四字命令检查下。\n$ echo stat | nc 127.0.0.1 2181 Zookeeper version: 3.4.11-37e277162d567b55a07d1755f0b31c32e93c01a0, built on 11/01/2017 18:06 GMT ... 第五步：如果需要查看数据，直接运行 zkCli.sh，连接后执行 ls /即可。\n$ sh bin/zkCli.sh Connecting to localhost:2181 ...... WatchedEvent state:SyncConnected type:None path:null [zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] 1.2 基于 Docker 安装 如果您已安装了 Docker，那么可以选择使用镜像启动 Zookeeper。\n$ docker image pull zookeeper:3.4.11 $ docker run -i -t --name my_zookeeper -p2181:2181 -d zookeeper:3.4.11 我们查看下启动日志：\n$ docker logs -f my_zookeeper ZooKeeper JMX enabled by default Using config: /conf/zoo.cfg 2018-04-16 07:38:59,373 [myid:] - INFO [main:QuorumPeerConfig@136] - Reading configuration from: /conf/zoo.cfg ...... 2018-04-16 07:23:41,187 [myid:] - INFO [main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:2181 可以看到端口已经启动并发布，我们使用四字命令检查下。\n$ echo stat | nc 127.0.0.1 2181 Zookeeper version: 3.4.11-37e277162d567b55a07d1755f0b31c32e93c01a0, built on 11/01/2017 18:06 GMT ... 我们可以查看启动的容器运行状态、关闭、重启，参考命令如下：\n$ docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 30b13a744254 zookeeper:3.4.11 \u0026amp;quot;/docker-entrypoin...\u0026amp;quot; 23 hours ago Up 42 seconds 2888/tcp, 0.0.0.0:2181-\u0026amp;gt;2181/tcp, 3888/tcp my_zookeeper ## 关闭重启的话 $ docker container stop 30b13a744254 $ docker container start 30b13a744254 如果需要使用 ZooKeeper 客户端查看查看数据，参考命令如下：\n$ docker exec -it 30b13a744254 zkCli.sh Connecting to localhost:2181 ...... WatchedEvent state:SyncConnected type:None path:null [zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] 2. SOFARPC 集成 Zookeeper 注册中心 Demo 工程参见: sofa-rpc-zookeeper-demo\n2.1 新建工程 运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，然后在 pom.xml 中引入如下 RPC 和 Zookeeper 相关依赖：\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.3.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.curator\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;curator-recipes\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.9.1\u0026amp;lt;/version\u0026amp;gt; …","date":1524737554,"description":"本文是 SOFARPC 集成 Zookeeper 的介绍。","dir":"blog/sofa-rpc-zookeeper-integriation/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"34d9ac266c4b2a95cc924705212d2eb0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","publishdate":"2018-04-26T10:12:34Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","summary":"SOFARPC 是近期蚂蚁金服开源的一个高可扩展性、高性能、生产级的 Java RPC 框架。在蚂蚁金服 SOFARPC 已经经历了十多年及五代版本的发展。SOFARPC 致力于简化应用之","tags":["SOFARPC"],"title":"SOFARPC 集成 Zookeeper 注册中心","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","wordcount":2367},{"author":"蚂蚁中间件","categories":"SOFAStack","content":" 我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！\nSOFA 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服期望通过逐步向社区开源 SOFA 中各个组件，来帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，也期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固，并具备更多金融级的属性。所以我们也非常欢迎社区的伙伴和各行业的伙伴能够参与共同探讨、交流和共建。\nWhy（为什么要做） SOFA 中间件在蚂蚁内部经历了十年的发展和四代架构的演进，被广泛应用在包括支付，借贷，信用，基金，保险等全金融场景，支撑着蚂蚁平稳度过历次双十一，双十二，新春红包等大考，创造了25.6 w/s 的交易记录，并还在不断刷新这个记录。\n从 2015 年开始，蚂蚁金服开启了金融科技对外输出的战略，SOFA 也走出了蚂蚁，甚至跨越了国界，被更多金融机构与合作伙伴所使用，如天弘基金，信美互信，南京银行，PayTM、DANA钱包等。\n在与合作伙伴以及客户的沟通、合作过程中，我们发现了 SOFA 的理念和能力也正是很多金融行业的企业所需要的，大家或多或少正在规划或者已经在做类似的东西，但缺乏像蚂蚁金服这么大的流量来提供考验，也缺乏专业团队的长期投入，更缺乏丰富的金融场景和严苛的业务压力来驱动技术持续发展。\n随着近几年蚂蚁金服在生态构建上不断完善，以及不断地有更多的公司加入到蚂蚁金服的金融生态中，我们也发现了整个金融生态地复杂性和多样性，SOFA 中间件也需要在更多地场景下被打磨、被完善、被增强。因此，我们选择将 SOFA 逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\nHow（怎么做） 为了让 SOFA 能够开源出来，我们投入了大量的重构工作，以可扩展化的方式来层层构建 SOFA 的能力，保证 SOFA 的内部版本和开源的版本采用的是同一个内核。所以 SOFA 的内部版本就是在开源版本之上扩展了内部逻辑和历史版本的兼容逻辑。开源版本的核心逻辑，内外是一致的，并在蚂蚁金服的生产环境中被广泛使用的，同时会随着蚂蚁自身业务诉求的驱动，不断的演进。\n开源社区有非常多优秀的技术和丰富的生态，为了更好的能融入和对接现有技术体系，尊重并遵守一些社区标准，SOFA 在设计过程中就充分考虑了兼容性和架构分层，充分兼容适配社区标准，实现组件化、可扩展、可替换。\n所有的 SOFA 中间件中的组件组合起来可以发挥更大的能力，但是每一个组件都是可以被替换的，比如用户可以选择用 Dubbo 来替换 SOFARPC，或者跟 SOFARPC 对接互通；可以选择 Zookeeper 来作为服务注册发现，也可以选择 SOFA 的服务注册中心来做服务发现；分布式链路追踪组件遵守 OpenTracing 的规范，可以直接和 Zipkin 进行对接等等；Metrics组件会遵循 Metrics2.0 标准，适配 Prometheus 体系等等。\nWhat（要做什么） 本次 SOFA 中间件开源的内容包含了 SOFABoot 和 SOFARPC 两个组件。\nSOFABoot 是蚂蚁金服基于 Spring Boot 构建一个研发框架，整体架构上类似于蚂蚁金服之前开源的Egg框架，遵守微内核，可插拔的理念，我们以标准 Spring Boot Starter的方式，扩展了很多企业级特性，以解决大规模团队开发云原生微服务系统中会遇到的问题，如类隔离，ReadinessCheck，日志隔离等等能力，后续会开放更多内部实践过的特性，如 Spring 上下文隔离，合并部署，动态模块，Tracing、Metrics、Streaming、测试框架等。\n同时，蚂蚁的很多技术团队和阿里的技术团队也开放了很多类库和组件，我们都会提供原生的集成能力和 Demo，方便大家更好的整合使用。SOFABoot 100% 兼容 Spring Boot，和 Spring Boot 并非是替代的关系，所有 Spring Boot 中的能力也都可以在 SOFABoot 中使用。\nSOFABoot 的 Github 的地址是：https://github.com/sofastack/sofa-boot ，欢迎大家使用反馈、贡献代码。\nSOFARPC 是一个高效，可靠，可扩展的 RPC 的框架，是蚂蚁金服服务化架构的基石。SOFARPC 最早源于阿里内部的 HSF，经过了蚂蚁金服内部多年的发展，在协议，网络，路由，可扩展性等层面都进行了大量的改造和优化的工作，适配了更多金融级的场景。\nSOFARPC 在蚂蚁金服内部是被所有在线应用的使用的服务调用框架，截止 2017 年双十一，SOFARPC 已经被蚂蚁 2000 多个系统所使用，生产环境发布的服务数量超过了 23000 个。\nSOFARPC 提供了多协议的支持，包括在蚂蚁金服内部被广泛采用，并且高度优化的 Bolt 协议，以及 REST，Dubbo，gRPC 等等主流的协议；也针对内部网关，测试等等场景提供了泛化调用能力；为了解决超大规模流量的预热的问题，提供了服务预热的能力；用户也可以根据 SOFARPC 的扩展机制扩展自己需要的能力。\n在后续的版本中，SOFARPC 将会加上分布式链路追踪，Metrics，更多的服务注册中心的支持，CRC 校验等等能力。\nSOFARPC 的 Github 的地址是：https://github.com/sofastack/sofa-rpc ，欢迎大家使用反馈、贡献代码。\n除了以上的两个 SOFA 中间件中的组件，在接下来，我们将会陆续开源 SOFA 中间件中的其他的组件，目前这些组件正在进行一定程度地重构中，为开源做准备，敬请大家期待~\n附本文中提到的链接：\n Egg：http://eggjs.org SOFABoot：https://github.com/sofastack/sofa-boot SOFARPC：https://github.com/sofastack/sofa-rpc SOFABolt：https://github.com/sofastack/sofa-bolt 彩蛋 最后，我们也为对 SOFA 中间件感兴趣的小伙伴们准备了一个微信交流群，欢迎感兴趣的同学扫描下方二维码联系加群小助手加入我们 SOFA 交流群哦。👇\n","date":1524147739,"description":"我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！","dir":"blog/announcing-sofastack-open-source/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6019b0e0f6e4c9569640bcdb51b5a157","permalink":"https://sofastack.github.io/sofastack.tech/blog/announcing-sofastack-open-source/","publishdate":"2018-04-19T14:22:19Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/announcing-sofastack-open-source/","summary":"我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！ SOFA 是蚂蚁金服自主","tags":["开源"],"title":"蚂蚁金服启动分布式中间件开源计划，用于快速构建金融级云原生架构","type":"blog","url":"/sofastack.tech/blog/announcing-sofastack-open-source/","wordcount":2479},{"author":"程立","categories":"SOFAStack","content":" 声明：本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创，经谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。\n移动互联网、大数据与云计算作为新的基础设施，催生了新的互联网经济，也正在推动各行各业的升级。在过去十多年中，金融服务飞速发展，移动支付支撑了零售业线上线下的变革，基于大数据的信贷服务支持了无数小微企业的创业创新，老百姓可以随时随地享受曾经高门槛的理财、保险等金融服务。以普惠服务为目标、数据与技术驱动、新型信用体系为基础的新金融已经成为新经济的基石。\n伴随着蚂蚁金服在新金融领域的探索，蚂蚁金服技术团队也在金融技术与架构领域不断开拓。从 2005 年每秒处理 1 笔交易到 2015 年双十一每秒处理 8.59 万笔交易，从单一的支付到覆盖微贷、理财、保险、信用、银行等，通过十多年的探索与实践，我们形成了一套包含金融级分布式交易、分布式大数据分析与决策等在内的完整架构与技术体系。\n在本文中，我们将与大家交流金融级分布式交易相关的实践与体会。\n金融级系统的关键目标 如果将建造系统比作盖楼的话，建一个常规的系统要先立稳四根柱子：高可用、安全、性能、成本。但要建一个移动互联网时代的金融级大厦，除了上述四根柱子需要更加牢固，还需要加上两根柱子：资金安全与数据质量。这六根柱子，是我们在架构蚂蚁金服的每一个系统时的首要目标。\n具体来说，我们对一个金融级系统有以下关键目标：\n高可用：具备 99.99% 以上的高可用性。系统能够容忍各种软硬件设施的故障，可以在服务不中断的情况下进行升级，在严苛的应用场景下保证承诺的服务质量，容忍各种人为失误。对于关键系统，还需要具备异地容灾能力。\n安全：具备多层次检测、感知与防御各类安全攻击的能力。系统有能力实时、精细地分析系统行为与数据流发现异常，必要时可以快速调集资源阻断大规模、有组织的攻击。\n性能：对于实时交易业务，要求极快的响应时间与极高并发能力。对于批量业务，要求极大的吞吐量。尤其重要的是，系统必须具备很强的可伸缩性与弹性，在需要时可以快速调集资源应对突发的业务量。\n成本：在满足高可用、安全与性能的前提下，成本是一个重要约束。我们将单笔交易的平均处理成本（月交易总笔数/月成本）、以及峰值交易的处理成本（每提升 1000 交易 TPS 需要追加的成本）作为两个关键指标去持续优化。除了必须在基础软硬件与系统关键链路上做极致的优化外，灵活的资源调度与按需伸缩能力是优化成本的关键。\n资金安全：这是金融级系统与常规系统的一个关键差异。要做到资金处理绝对不出差错，需要交易与数据具备强一致性，需要在任何故障场景数据不丢不错，需要具备准实时的交易资金核对能力，需要在异常场景下有精细化熔断与快速恢复能力。\n数据质量：数据质量是金融服务质量的基础。数据从采集、生成、流转、存储、计算、使用需要经历很多环节，要确保经过这么多环节后，数据依然是准确、完整和及时的，需要系统具备全链路的数据质量管控与治理能力。\n金融交易系统是否可以走分布式路线？如何基于分布式的思想与技术达到以上 6 个关键目标？接下来，我们就以蚂蚁金服的实践为基础，分享对这个问题的观点。\n分布式金融交易架构与技术 1 强一致的微服务：微交易架构 微服务是一种广泛应用的分布式架构。通过将系统分解为单一职责、高内聚、松耦合、独立部署、自主运行的“微“服务，可以极大提升系统的灵活性与扩展能力。但由于每一个微服务是自包含的数据与计算单元，当一个有严格一致性要求的交易，被分布在很多节点上执行时，如何保证数据与服务处理达到金融级的强一致性，成为一个难题。尽管可以用支持分布式事务的数据库或数据中间件来保证数据分布时的一致性，但解决不了当服务分布时的一致性问题。由于分布式事务对资源加锁的时间长、粒度大，也制约了系统的可伸缩性与高可用性。\n为了解决这个难题，我们提出一种使微服务具备强一致性的微交易架构。在这种架构中，涉及到交易操作的微服务具备事务属性。一个微交易提供三种操作TCC（Try-Confirm-Cancel），其中 Try 操作负责业务检查与资源预留，Confirm 操作负责实际操作，Cancel 操作负责释放预留的资源。一次完整的交易由一系列微交易的 Try 操作组成，如果所有的 Try 操作都成功，最终由微交易框架来统一Confirm，否则统一 Cancel，从而实现了类似经典两阶段提交协议（2PC）的强一致性。但不同于 2PC，微交易架构力求高效与可伸缩。TCC 三个操作都是基于本地事务的短事务，Try 操作只预留必须的业务资源，比如一笔交易涉及10元钱，仅预留账户中的 10 元钱，而不是锁定整个账户，TCC 协议在提交时，也没有单独的 Prepare 阶段，将提交协议的成本降到最低。\n从 2008 年初上线至今，微交易架构已经应用到蚂蚁金服的各种金融业务场景，经历过历次大促高峰考验，证明这套架构与技术的可行性。\n2 金融级分布式数据库: OceanBase 目前，主要商业数据库本质上是单机系统，其容量、性能和可靠性均依赖于单个或少量高性能服务器与高可靠存储的组合，成本高昂且扩展困难。尽管通过运用微交易架构，可以将对数据操作的压力分拆多个数据库，解决了水平可扩展的问题，但数据库本身的性能、成本与可靠性依然是一个难点。因此，阿里巴巴与蚂蚁金服从 2010 年起，开始研发专门的金融级分布式数据库 OceanBase。\nOceanBase 在以下几个方面，对传统数据库架构进行了突破：\n高性能：数据库的一个显著特征是总数量比较大，但每天变化(增删改)的数据只是总数据量的很小一部分。因此 OceanBase 将数据划分为基线数据和修改增量。基线数据即数据库在某个时间点的一个快照，存放在每台 OceanBase 服务器的硬盘中，修改增量即快照点之后的增删改数据，相对比较小，通常存放在每台 OceanBase 服务器的内存中。通过这种方式，使得增删改操作基本都在内存中进行，从而获得接近内存数据库的事务处理性能；\n强一致：经典的主库+备库方式的数据库，很难兼具高可用与强一致能力。为了解决这个问题，OceanBase 使用多数据副本（\u0026amp;gt;=3）投票协议，对于每个写事务，OceanBase 只有在事务日志（redo log）到达超过半数服务器后，才应答客户。这样当少数服务器（例如 3 台中的 1 台，或者 5 台中的 2 台）异常时，剩下的服务器至少有一台有事务日志，保证了数据库不因为少数服务器故障而导致数据丢失；\n高可用：关键业务的数据库必须达到 99.999% 的可用性，服务器故障、机房或网络故障都不能导致数据库不可用。OceanBase 通常由分布于多个机房（3 个或以上）的机群组成，每个机群有完整数据，其中一个机群作为主库对外提供读写服务，其余机群作为备库，接收主库的事务日志和回放日志。当主库故障时，剩下的机群会立刻自动发起投票选举，选出新的主库，新主库从其他机群获得可能存在的最新事务日志并回放，完成后对外提供服务。\n目前 OceanBase 已经稳定支撑了支付宝的核心交易、支付与账务，支撑了网商银行的核心系统，经历了多次“双十一”的考验，形成了跨机房、跨区域部署的高可用架构，并在日常运行、应急 …","date":1520578800,"description":"本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创。","dir":"blog/technical-financial-distributed-trading/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e6da780e4d5f611c48ac55795531fb2c","permalink":"https://sofastack.github.io/sofastack.tech/blog/technical-financial-distributed-trading/","publishdate":"2018-03-09T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/technical-financial-distributed-trading/","summary":"声明：本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创，经谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。","tags":["SOFAStack"],"title":"金融级分布式交易的技术路径","type":"blog","url":"/sofastack.tech/blog/technical-financial-distributed-trading/","wordcount":4822},{"author":null,"categories":null,"content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。 本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同； - 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。\n平台工程旨在帮助企业构建面向应用研发者的自服务运维体系，尝试通过工程化的技术手段和工作流程解决以下关键问题：\n- 设计合理的抽象层次，帮助应用研发者降低对 Infra 、platform 等技术以及运维、稳定性工作的认知负担；\n- 为应用研发者提供统一的工作界面和空间，避免用户陷入割裂的平台产品界面、复杂的工作流中；\n- 帮助研发者通过有效的工作流程和推荐路径基于 内部工程平台[4] 快速开展工作；\n- 帮助研发者通过配套的 CI 、CD 、CDRA 等产品自服务管理应用生命周期；\n- 帮助平台产品研发团队简单、高效、一致的开放其平台基础能力；\n- 通过培训、布道、运营等手段营造协同工作和分享的文化。\n事实上，不是所有人都应该或者能够成为这个领域的专家，这非常困难！\n实际上平台技术团队的专家通常也仅擅长自己的专业领域而已，特别是在云原生理念和技术广泛应用的今天，面向大量高度开放、可配置的平台技术带来的成百上千的应用配置，PaaS 领域的业务复杂性，以及高稳定性和统一治理的要求，而平台工程的目的正是为了让应用研发者尽可能简单无痛的参与到这样规模化的 DevOps 工作中。\n在蚂蚁的实践中，我们更趋向于以下这种合作状态，在团队架构和工作模式上更靠近 Google 的最佳实践。平台研发者及 SRE 成为 “ Enabler ” 支持应用研发者自服务的完成研发及交付运维，同时应用研发者使其应用可交付运维的工作结果也成为运维人员可以接手应用运维工作的基础。最终 SRE 、应用研发及运维人员把工作过程中的问题和痛点反馈给平台研发者形成正向循环。\n三、专用语言：工程化方式的一极 有什么比一种专用语言更适合开放的、自服务的、面向领域业务的问题定义，同时需要满足自动化、低安全风险、低噪音、易治理的企业内部要求吗？正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在平台工程的特定问题域内，一批配置和策略语言用于编写和管理规模化复杂配置及策略。\n不同于混合编写范式、混合工程能力的高级通用语言，这类专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将规模化复杂配置和策略编写思路和方式沉淀到语言特性中。\n在蚂蚁的平台工程实践中，我们强化了客户端的工作方式，将围绕应用运维生命周期的模型、编排、约束和策略稳定、可扩展的通过专用语言 KCL[5] 编写维护在共享仓库 Konfig[6] 中。\nKCL 是一种面向有编程能力的应用研发者的静态强类型语言，提供现代高级语言的编写体验和围绕领域目的有限功能。在平台工程实践中 KCL 不是一种仅用于编写 K-V 对的语言，而是一种面向平台工程领域的专用语言。应用研发者、 SRE 、平台研发者面向 Konfig 协同研发，通过 KCL 原生功能编写应用配置，以及在 PaaS 领域更为高频和复杂的 模型抽象[7] 、 功能函数[8] 和 约束规则[9] ，即编写稳定、可扩展的业务模型、业务逻辑、防错约束和环境规则。\nKonfig 仓库则成为统一的编程界面，工作空间和业务层载体，而基于 KCL 的安全、低噪音、低副作用、一致的编写范式更有利于长期管理和治理。\n四、分治：解构规模化问题 分治思路是解决规模化问题的钥匙，从 MapReduce 到 Kubernetes 无不体现其功效。在规模化交付运维领域，经典运维平台试图在统一的黑盒平台产品中，以内置的统一模型、编排、 provision 技术来应对全量业务场景。这样的实践可以快速启动，在小范围内奏效，但随着不同业务主体采用率提升引入差异化需求，同时随着持续变化的平台技术逐渐进入疲态。\n在蚂蚁的实践中，Konfig monorepo 是内部工程平台向研发者开放的编程界面和工作空间，帮助应用研发者以统一的编程界面编写围绕应用运维生命周期的配置和策略，从而编排和使用存量和新增的平台基础设施，按需创建管理云原生环境以及基于 RBAC 的权限，并通过 GitOps 方式管理交付过程。\nKonfig monorepo 为不同场景、项目、应用提供了独立的白盒的编程空间，其内生的扩展性来源于：\n- 灵活、可扩展、独立的客户端的 工程结构设计[10] ；\n- 独立配置块自动合并技术[11] 支持任意分块、可扩展的配置块组织；\n- 静态类型系统[12] 技术提供现代编程语言可复用、可扩展的类型化建模和约束功能；\n- 项目粒度的 GitOps CI 工作流程定义支持；\n- 基于 Kusion[13] 引擎的 provision 技术选择。\nKonfig monorepo 提供了分治的、可组合的工程结构设计、代码组织、建模方式、工作流程定义和 provision 技术选择支持，同时又以一致的研发模式和工作流承载了可扩展的业务需求。这样客户端的工作方式在保证灵活性、可扩展性、可移植性的同时也降低了对服务 …","date":-62135596800,"description":"","dir":"blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":-62135596800,"objectID":"025e2d84d60225a85a714bfd63e2c369","permalink":"https://sofastack.github.io/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","summary":"文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。 本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同； - 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。","tags":null,"title":"","type":"blog","url":"/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","wordcount":422},{"author":null,"categories":null,"content":" Novel features: Strong leader Raft uses a stronger form of leadership than other consensus algorithms. For example, log entries only flow from the leader to other servers. This simplifies the management of replicated logs and makes Raft easier to understand. Leader election Raft uses randomized timers to elect leaders. This reduces election conflicts simply and rapidly. Membership change Raft uses a new joint consensus approach. Replicated state machines 1. Replicated state machines are implemented based on logs. Each server stores a log. Each log entry contains a command. The state machine executes commands in order. 2. Consensus algorithms for practical systems typically have the following properties: They ensure safety. They are highly available. They do not depend on the time sequence to ensure log consistency. A command can be completed as soon as a majority of the cluster has responded to a single round of remote procedure calls (RPCs). Drawbacks of Paxos Paxos is exceptionally difficult to understand. Paxos does not provide a good foundation for building practical implementations. Raft design principles Concept decomposition Leader election Log replication Membership changes Raft reduces the number of states to simplify the state space. Raft does not allow log holes and restricts the possibilities of log inconsistency. Raft uses randomized timers to simplify the leader election. Raft consistency algorithm State Persistent state on all servers (updated on stable storage before responding to RPCs):\n currentTerm The latest term that the server gets (initialized to 0 on initial boot, increasing monotonically) votedFor The candidateId that has received votes in the current term (or null if none). Log[] Log entries. Each entry contains a command for the state machine, and the term when the entry was received by the leader. Volatile state on all servers:\n commitIndex The index of the highest log entry known to be committed. lastApplied The index of the highest log entry applied to the state machine. Volatile state on leaders:\n nextIndex[] The index of the next log entry to be sent to each follower. matchIndex[] The index of the highest log entry known to have been replicated on each follower. AppendEntries RPC (log replication) Called by the leader to replicate log entries or used as heartbeats.\nArguments:\n term leader\u0026amp;rsquo;s term leaderId The leader\u0026amp;rsquo;s ID that can be used to redirect clients to the leader. prevLogIndex The index of the preceding log entry. prevLogTerm The term of the prevLogIndex entry. entries[] The log entries to be stored (empty for heartbeat, and the leader may send more than one for efficiency). leaderCommit The leader\u0026amp;rsquo;s commitIndex (for committed log entries). Results:\n term The currentTerm for the leader to update. success True if the follower contains log entries matching prevLogIndex and prevLogTerm. Receiver …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/raft-introduction/","fuzzywordcount":2600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b811e803d23b40da67657798801f8b51","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","publishdate":"0001-01-01T00:00:00Z","readingtime":13,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","summary":"Novel features: Strong leader Raft uses a stronger form of leadership than other consensus algorithms. For example, log entries only flow from the leader to other servers. This simplifies the management of replicated logs and makes Raft easier to understand. Leader election Raft uses randomized timers to elect leaders. This reduces election conflicts simply and rapidly. Membership change Raft uses a new joint consensus approach.","tags":null,"title":"'Introduction to the Raft algorithm'","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","wordcount":2562},{"author":null,"categories":null,"content":" Open ACTS IDE In the Packages view, right click the function name annotated by @Test, and choose ACTS Function \u0026amp;gt; Edit Test Case as shown in the following figure.\nWrite test data Prepare request parameters Prepare correct request parameter data for the request parameters (type, order, and quantity) of the tested method. The parameters are divided into simple and complex types. Simple parameters include parameter types String, Date, Integer, Float, Double, Long, Short, and Byte (including their corresponding basic types, such as int and float). Complex parameters include parameter types List, Map, Set, custom class, Java defined class, and their nested expressions.\nSimple request parameters Right click Request Parameters, choose Select Model, and click Simple Type in the pop-up to select simple parameters.\nAfter importing simple request parameters, enter their values directly in the field as shown in the preceding figure. Parameters listed top down are the first, second, and third parameters of the tested method. You can right click a parameter to adjust its order.\nComplex parameters As shown in Figure 27, you need to generate request parameter models for the AccountTransRequest class and the BusinessActionContext class. Generally, class models of the tested method\u0026amp;rsquo;s request parameters and responses are automatically generated along with the test script. You can open ACTS IDE to edit class models of request parameters as shown in Figure 28.\nFigure 28\nIf the models of the method\u0026#39;s request parameters and responses are not identified when you generate the test script, first generate models of complex request parameters and responses (for detailed operation steps, see [Generate object model](../usage-model/#generate-object-model)). Then open ACTS IDE, right click Request Parameters, choose Select Model, and click Complex Type in the pop-up to add complex objects. After this, you can view and edit complex objects under Request Parameters. ![Complex type](complex-type.png) ### List ![List example](list-example.png) ![Edit value](edit-value.png) ### Map See example 2 (the Set type is similar). In Figure 32, request parameters of the method shown in sample 2 is the `Map` type. Objects do not belong to a specific type. If you want to set an object as a complex one, edit the YAML file. For example, if you want to set an object as the AccountTransResult class, edit the YAML file as follows: ![Map examples](map-example.png) Figure 32\n![ Change type](change-type.png) ![Set property values](set-value.png) ### enum Example code: ![Example code](sample.png) 1. You can edit the values in ACTS IDE as follows: ![Edit value](change-value.png) 2. If an enum type class is nested in another class, set the value of the enum type to DEBIT in the CSV model of the class. 3. Figure 37 shows the test case data in the YAML file. ```yaml interestRecoverTypeEnum: !!com.alipay.fc.loancore.common.util.enums.InterestRecoverTypeEnum \u0026#39;ALL\u0026#39; ``` ![YAML data](yaml-data.png) …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ide/","fuzzywordcount":2000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"697e7e6d35a2e058f3ca8b0a72032690","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-ide/","publishdate":"0001-01-01T00:00:00Z","readingtime":10,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-ide/","summary":"Open ACTS IDE In the Packages view, right click the function name annotated by @Test, and choose ACTS Function \u0026gt; Edit Test Case as shown in the following figure.\nWrite test data Prepare request parameters Prepare correct request parameter data for the request parameters (type, order, and quantity) of the tested method. The parameters are divided into simple and complex types. Simple parameters include parameter types String, Date, Integer, Float, Double, Long, Short, and Byte (including their corresponding basic types, such as int and float).","tags":null,"title":"All-in-one editor","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-ide/","wordcount":1929},{"author":null,"categories":null,"content":" Introduction To understand the usage mode of Jarslink2.0, you need to have a certain understanding of the SOFAArk framework and the packaging of Ark packages and Ark Biz packages.\nTo ensure the consistency of reading, here is a rough description of the packaging logic of the application\u0026amp;rsquo;s use of Jarslink2.0. The official recommendation is to jump to the above-mentioned link to obtain the necessary background knowledge.\nJarslink2.0 requires an application type of Spring Boot or SOFABoot. Before introducing new modes of application packaging, let\u0026amp;rsquo;s see why it is necessary for Spring Boot/SOFABoot applications to introduce new packaging modes after using Jarslink2.0.\nBackground At runtime, Jarslink2.0 works as an Ark Plugin of the SOFAArk framework, which must be introduced for the use of Jarslink2.0. The Jarslink2.0 plugin will not be loaded and started until the SOFAArk container is started. As we know, when official Spring Boot projects use plugins:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; An executable FatJar will be packaged, which contains all the dependencies, configurations, and other resources required by the running application. The FatJar entry method is the main method of the Spring Boot application. The packaging logic of a SOFABoot project is the same as that of a Spring Boot project.\nAfter the application introduces Jarslink2.0, which needs to depend on the SOFAArk framework, the FatJar that is packaged by a new packaging mode needs to contain a SOFAArk container. The FatJar entry method also needs to be replaced by the SOFAArk container startup method, because the startup of SOFAArk takes precedence over the execution of the FatJar. The SOFAArk container starts all the Ark Plugins in turn before finally starting the application. Therefore, a new packaging mode is needed, and SOFAArk provides a packaging plugin.\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; responsible for packaging Spring Boot/SOFABoot applications into an executable FatJar called Ark package.\nPackaging Type In the previous section, we have described why the use of Jarslink 2.0 needs to introduce a packaging mode that is different from the official Spring Boot packaging mode, and brought out the first packaging type—Ark package. Now let\u0026amp;rsquo;s summarize the features of Ark package:\n Ark package is an executable FatJar package format customized by the SOFAArk framework, the details of which are available in Reference Documents. The Ark package contains all the configurations, dependencies, and other resources required by the running application. Its packaging logic is similar to that of Spring Boot, and it also contains the Ark Plugin and the SOFAArk framework on which the application depends. The SOFAArk framework does not need to be introduced into the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-repackage/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a9cb3c5d3fa32c5f6c476d9ed80c80cb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","summary":"Introduction To understand the usage mode of Jarslink2.0, you need to have a certain understanding of the SOFAArk framework and the packaging of Ark packages and Ark Biz packages.\nTo ensure the consistency of reading, here is a rough description of the packaging logic of the application\u0026rsquo;s use of Jarslink2.0. The official recommendation is to jump to the above-mentioned link to obtain the necessary background knowledge.\nJarslink2.0 requires an application type of Spring Boot or SOFABoot.","tags":null,"title":"Application packaging","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","wordcount":749},{"author":null,"categories":null,"content":" RheaKV: an embedded, distributed, highly available, and strongly consistent KV storage class library that is implemented based on JRaft and RocksDB. AntQ Streams QCoordinator: uses JRaft to implement elections and meta information storage in the Coordinator cluster. Metadata management module of SOFARegistry: an IP address registration. The data held by all nodes must be consistent, and the normal data storage must not be affected when a minority of nodes fail. AntQ NameServer leader election ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/user-stories/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b233be7d9eed33645945293e637e28ea","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/user-stories/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/user-stories/","summary":"RheaKV: an embedded, distributed, highly available, and strongly consistent KV storage class library that is implemented based on JRaft and RocksDB. AntQ Streams QCoordinator: uses JRaft to implement elections and meta information storage in the Coordinator cluster. Metadata management module of SOFARegistry: an IP address registration. The data held by all nodes must be consistent, and the normal data storage must not be affected when a minority of nodes fail.","tags":null,"title":"Application scenarios","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/user-stories/","wordcount":74},{"author":null,"categories":null,"content":" ## Architecture diagram Jarslink 2.0 is an Ark plugin and needs to depend on the SOFAArk container at runtime. Jarslink 2.0 is in the middle layer between the applications and the containers at runtime. Boundary interaction mode: + 1. Application boundaries: Jarslink 2.0 configures export classes that can be directly used by the applications. Such classes are loaded by Jarslink at runtime. + 2. Container boundaries: The Ark plugin can interact with the SOFAArk container by using the exposed extension points and services. Jarslink expanded the BizDeployer implementation and referenced BizManagerService and BizFactoryService container services.\nModule division The implementation classes of each module appear only in their own modules and are generally not cross-dependent. Required cross-dependencies will be moved into the core module. Detailed module descriptions can be found in the following table:\n Module name Sub-module name Description Dependency relationship bom Dependent on version control None core common Common module with log classes None core spi SPI module, defining basic interfaces and commands None core-impl runtime Jarslink runtime management, processing commands Core integration Ark plugin packaging module, implementing SOFAArk container service extension point and referencing container services All ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-structure/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fa09c01de689002edbd0bea7f68fe66e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","summary":"## Architecture diagram Jarslink 2.0 is an Ark plugin and needs to depend on the SOFAArk container at runtime. Jarslink 2.0 is in the middle layer between the applications and the containers at runtime. Boundary interaction mode: + 1. Application boundaries: Jarslink 2.0 configures export classes that can be directly used by the applications. Such classes are loaded by Jarslink at runtime. + 2. Container boundaries: The Ark plugin can interact with the SOFAArk container by using the exposed extension points and services.","tags":null,"title":"Architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","wordcount":188},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-biz/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d7f80ce6a00d914546e642c887d23a01","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","summary":"","tags":null,"title":"Ark Biz","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","wordcount":0},{"author":null,"categories":null,"content":" 简介 本小节将介绍 Ark Biz 目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark Biz。\nArk Biz 包和 Ark 包 都是使用 Maven 插件 sofa-ark-maven-plugin 打包生成；工程应用在配置该插件时，默认情况下只会打包发布 Ark 包， 只有在配置参数 attach 为 true 时，才会打包发布 Ark Biz：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;false\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 那 Ark Biz 和 Ark 包 有什么区别呢？ 简单来说，Ark Biz 是工程应用所有资源的组织单元，它包含了应用启动所需的所有资源，详细可参考下文描述的 Ark Biz 目录格式；而工程应用打出来的 Ark 包，是一个通过 java -jar 启动，运行在 SOFAArk 容器的 Fat Jar，不仅包含应用工程对应的 Ark Biz，也包含 Ark Container，以及应用依赖的 Ark Plugin；\n通常情况，只需要发布 Ark 包 即可，但是 SOFAArk 是支持运行多个 Ark Biz的，因此如果开发者希望自己应用的 Ark Biz 包能够被其他应用直接当成 Jar 包依赖，进而运行在同一个 SOFAArk 容器之上，那么就需要打包发布 Ark Biz 包；\nArk-Biz 典型目录结构 . ├── META-INF │ ├── MANIFEST.MF │ ├── maven │ │ └── me.qlong.tech │ │ └── sofa-boot-demo3-web │ │ ├── pom.properties │ │ └── pom.xml │ └── sofa-boot-demo3 │ └── sofa-boot-demo3-web.xml ├── com │ └── alipay │ └── sofa │ └── ark │ └── biz │ └── mark ├── config │ ├── application-dev.properties │ ├── application-test.properties │ └── application.properties ├── lib │ ├── spring-beans-4.3.4.RELEASE.jar │ ├── spring-boot-1.4.2.RELEASE.jar │ ├── spring-boot-autoconfigure-1.4.2.RELEASE.jar │ ├── spring-boot-devtools-1.4.2.RELEASE.jar │ ├── spring-boot-starter-1.4.2.RELEASE.jar │ ├── spring-boot-starter-logging-1.4.2.RELEASE.jar │ ├── spring-boot-starter-tomcat-1.4.2.RELEASE.jar │ ├── spring-boot-starter-web-1.4.2.RELEASE.jar │ ├── spring-context-4.3.4.RELEASE.jar │ ├── spring-core-4.3.4.RELEASE.jar │ ├── spring-expression-4.3.4.RELEASE.jar │ ├── spring-web-4.3.4.RELEASE.jar │ ├── ... │ ├── ... │ ├── ... │ └── velocity-1.7.jar ├── logback-spring.xml ├── me │ └── qlong │ └── tech │ └── SOFABootWebSpringApplication.class └── static └── index.html 上述目录结构相关文件和目录说明如下：\n普通的 Java 工程或者 Spring Boot Core/Web 工程都可以打包成 Ark Biz；Ark Biz 没有固定的目录格式，它只是在原来 Jar 包结构基础上新增两个目录文件：\n com/alipay/sofa/ark/biz/mark : 标记文件，标记该 Jar 包是 sofa-ark-maven-plugin 打包生成的 Ark Biz 文件；\n lib/ : lib 目录存放工程应用的三方依赖，\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-biz/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d7f80ce6a00d914546e642c887d23a01","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","summary":"简介 本小节将介绍 Ark Biz 目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark Biz。 Ark Biz 包和 Ark 包 都是使用 Maven 插件 sofa-ark-maven-plugin 打包生成；工程应用在配置该插件时，默认情","tags":null,"title":"Ark Biz","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","wordcount":700},{"author":null,"categories":null,"content":" SOFAArk 合并部署时，除了宿主应用，其他 Biz 允许运行时动态部署和卸载。Biz 的状态如下:\n unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时 Biz 包还没有安装或者安装中 activated: Biz 包启动完成，且处于激活状态，可以对外提供服务 deactivated: Biz 包启动完成，但处于未激活状态，模块多个版本时，只有一个版本处于激活状态(注意这个状态只对 JVM 服务生效，对 RPC 等其他中间件无效) broken: Biz 包启动失败后状态 目前 SOFAArk 提供了三种方式操作 Biz:\n 编程 API Zookeeper 动态配置 Telnet 指令 本质上，后两种都是通过编程 API 操作 Biz，所以在这里详细描述通过编程 API 控制 Biz 的生命周期。SOFAArk 提供客户端 ArkClient 操作 Biz, 主要包含三条指令：\n install: 安装 Biz，虽然有多个重载方法，本质是接受 bizFile 文件作为入参 uninstall: 卸载 Biz，运行时 Biz 是由 bizName 和 bizVersion 唯一确定的，因此需要这两个入参 switch: 激活 Biz，SOFAArk 运行部署多个相同名称不同版本的 Biz，但是运行时只有一个 Biz 被激活（JVM 服务对外可用）；当使用 switch 指令激活其他版本时，当前处于激活状态的 Biz 将切换到钝化，同样也需要 bizName 和 bizVersion 作为入参 注意：部署相同名称不同版本 Biz 时，如果已有激活的版本，后续部署的其他版本 Biz 将自动处于钝化状态\n安装 Biz 以 Spring Boot/SOFABoot 为例，应用(模块)安装包含以下流程：\n 解析模块 \u0026amp;gt; SOFAArk 容器会解析文件流，读取 Biz 配置，创建 BizClassLoader 等，生成 Biz 运行时模型\n 注册模块 \u0026amp;gt; 注册解析后的 Biz 模型，设置状态为 resolved\n 启动模块 \u0026amp;gt; 执行 Biz 的入口方法，完成上下文的刷新，如果报错则对外抛出异常\n 健康检查 \u0026amp;gt; 启动完成，此时 Biz 还没有切换至下一个状态，将会执行应用健康检查，健康检查参考 SOFABoot 文档，健康检查失败则抛出异常，如果应用没有引入 SOFABoot 健康检查依赖，则跳过\n 切换状态 \u0026amp;gt; 健康检查成功，会切换 Biz 状态；如果不存在其他版本 Biz 处于激活状态，则切换状态至 Activated，否则切换状态至 DeActivated\n 注意：启动模块时抛出异常，均导致 Biz 启动失败，可以查看 sofa-ark/common-error.log 日志\n卸载 Biz 应用（模块）卸载包含以下流程：\n 切换 Biz 状态至少 deactivated \u0026amp;gt; 钝化 Biz, 防止流量进入正在卸载的 Biz\n 关闭 ApplicationContext \u0026amp;gt; 关闭 Biz 的 Spring 上下文，如果用户需要自定义卸载操作，可以监听 ContextClosedEvent 事件\n 注销 JVM 服务 \u0026amp;gt; SOFAArk 运行时注销 Biz 发布的 JVM 服务\n 发送卸载事件 \u0026amp;gt; 通知所有 Ark Plugin 和 Ark Biz，正在卸载某个 Biz\n 清楚缓存 \u0026amp;gt; SOFAArk 运行时注销所有和该 Biz 相关的缓存\n 切换 Biz 状态为 unresolved \u0026amp;gt; Biz 执行完所有卸载操作时，将状态置为 unresolved\n 卸载面临的挑战 卸载 Biz 最大的挑战在于 ClassLoader 的卸载，如果 ClassLoader 没有卸载干净，极有可能会导致 metaspace OOM. JDK 对 Class 的回收条件非常苛刻，包含：\n 该类所有实例都已经回收 加载该类的 ClassLoader 已经回收 该类对应的 java.lang.Class 对象已经没有在任何地方被引用，无法在任何地方通过反射访问该类的方法 每个 Biz 都由独立的 BizClassLoader 加载，只要该 Biz 的加载的类或对象或 ClassLoader 被其他 Biz 或 Plugin 引用，则会导致 Biz 无法卸载成功\n激活 Biz 激活指令用于设置 Biz 状态为 Activated，如果此时已有其他版本 Biz 处于激活状态，则先设置其为 Deactivated，再激活指定的 Biz 为 Activated. 激活状态是相对 JVM 服务而言，只有被激活的 Biz，其发布的 JVM 服务才能被其他 Biz 引用\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-biz-lifecycle/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"090ee6596c6808339fa3233139903040","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","summary":"SOFAArk 合并部署时，除了宿主应用，其他 Biz 允许运行时动态部署和卸载。Biz 的状态如下: unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时","tags":null,"title":"Ark Biz 生命周期","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","wordcount":1195},{"author":null,"categories":null,"content":" This section will introduce the directory structure of standard Ark package and how to use the maven plugin of sofa-Ark-maven-plugin to package and release an Ark package.\nMaven plugin The officially provided Maven plugin sofa-Ark-maven-plugin can package common Java projects or Spring Boot projects into standard-format Ark packages. Based on Fat Jar technology, we can directly start an Ark package with the java -jar command. The Maven plugin coordinates are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals The sofa-Ark-maven-plugin plugin provides goal: repackage, which can package the project into an executable Ark package, it can be configured as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Configuration information --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Complete configuration template Complete sofa-Ark-maven-plugin configuration template is as follows:\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.1.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--The default packaging storage directory for Ark package and Ark biz is the project build directory--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;../target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--The name of the generated Ark package file is ${artifactId} by default--\u0026amp;gt; \u0026amp;lt;finalName\u0026amp;gt;demo-ark\u0026amp;lt;/finalName\u0026amp;gt; \u0026amp;lt;!--Whether to skip execution of goal:repackage (false by default)--\u0026amp;gt; \u0026amp;lt;skip\u0026amp;gt;false\u0026amp;lt;/skip\u0026amp;gt; \u0026amp;lt;!--Whether to package, install, and release Ark biz (false by default). Refer to the Ark Biz file for details --\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--Set the classifier of Ark package, which is null by default--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;ark-classifier\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- Set the classifier of Ark biz, which is Ark-biz by default --\u0026amp;gt; \u0026amp;lt;bizClassifier\u0026amp;gt;ark-biz-classifier\u0026amp;lt;/bizClassifier\u0026amp;gt; \u0026amp;lt;!--Exclude the specified package dependency when packaging the Ark biz. The format is: ${groupId:artifactId} or ${groupId:artifactId:classifier}--\u0026amp;gt; \u0026amp;lt;excludes\u0026amp;gt; \u0026amp;lt;exclude\u0026amp;gt;org.apache.commons:commons-lang3\u0026amp;lt;/exclude\u0026amp;gt; \u0026amp;lt;/excludes\u0026amp;gt; \u0026amp;lt;!--Exclude the package dependency that is the same as the specified groupId when packaging the Ark biz--\u0026amp;gt; \u0026amp;lt;excludeGroupIds\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jar/","fuzzywordcount":1400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c2a9b8ad142f15b9ee82d7d9d8237850","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","summary":"This section will introduce the directory structure of standard Ark package and how to use the maven plugin of sofa-Ark-maven-plugin to package and release an Ark package.\nMaven plugin The officially provided Maven plugin sofa-Ark-maven-plugin can package common Java projects or Spring Boot projects into standard-format Ark packages. Based on Fat Jar technology, we can directly start an Ark package with the java -jar command. The Maven plugin coordinates are:","tags":null,"title":"Ark JAR package","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","wordcount":1317},{"author":null,"categories":null,"content":" This section will introduce the standard specifications and directory structure of Ark Plugin and how to use the maven plugin of sofa-ark-plugin-maven-plugin to package and release it.\nPlugin Specifications A standard Ark Plugin should meet the following specifications:\n The plugin should have a name (default is ${artifactId}). At runtime, duplicate names are not allowed. In other words, the name will be used as the unique ID of Ark Plugin;\n A plugin must be configured with a priority (default is 1,000): the lower the number, the higher the priority;\n A plugin should be configured with no more than one entry class activator, a portal for the container startup plugin used to implement the com.alipay.sofa.ark.spi.service.PluginActivator interface class in a uniform way. The plugin with higher priority will start up first;\n Import classes support both package and class levels. They are loaded first from other plugins;\n Export classes support package and class levels. Plugins with higher priority will be exported first;\n Support importing resources from the classpath (wildcard is not supported). Specified resources will be searched for from other plugins first;\n Support exporting resources from the classpath (wildcard is not supported); resources with higher priority will be exported first;\n Maven plugins The officially provided Maven plugin sofa-ark-plugin-maven-plugin can package projects into a standard-format Ark Plugin. The coordinates of Maven plugin are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals The sofa-ark-plugin-maven-plugin plugin provides goal: ark-plugin, which can be used to package the project into a standard-format Ark Plugin. Configurations are as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Configuration information --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Complete configuration template The complete configuration template of the sofa-ark-plugin-maven-plugin plugin is shown as follows:\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Specify the directory to package ${pluginName}.ark.plugin (${project. build. directory} is the default location) --\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin/","fuzzywordcount":1300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"684dc1caa0f834eec498905f95913f83","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","summary":"This section will introduce the standard specifications and directory structure of Ark Plugin and how to use the maven plugin of sofa-ark-plugin-maven-plugin to package and release it.\nPlugin Specifications A standard Ark Plugin should meet the following specifications:\n The plugin should have a name (default is ${artifactId}). At runtime, duplicate names are not allowed. In other words, the name will be used as the unique ID of Ark Plugin;","tags":null,"title":"Ark Plugin","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","wordcount":1242},{"author":null,"categories":null,"content":" 本小节将介绍 Ark Plugin 的标准规范和目录结构，以及如何使用官方插件 sofa-ark-plugin-maven-plugin 打包发布 Ark Plugin。\n插件规范 标准的 Ark Plugin 需要满足以下规范：\n 插件必须配置插件名，默认为 ${artifactId} ；运行时，不允许存在同名的插件，可以认为它是 Ark Plugin 的唯一 ID;\n 插件必须配置优先级，默认为1000，数字越低表示优先级越高；\n 插件最多配置一个入口类 activator ，它是容器启动插件的入口，统一实现 com.alipay.sofa.ark.spi.service.PluginActivator 接口类；优先级高的插件优先启动；\n 导入类支持 package 和 class 两个级别；导入类优先从其他的插件加载；\n 导出类支持 package 和 class 两个级别；优先级高的插件优先导出；\n 支持导入 classpath 中资源，不支持通配符；优先从其他插件中查找指定资源；\n 支持导出 classpath 中资源，不支持通配符；优先级高的插件优先导出；\n Maven 插件 官方提供 Maven 插件 sofa-ark-plugin-maven-plugin 可以将工程打包成标准格式的 Ark Plugin ； Maven 插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${demo.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals sofa-ark-plugin-maven-plugin 插件提供 goal: ark-plugin，可以将工程打包成标准格式的 Ark Plugin, 如下配置：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 配置信息 --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 完整配置模板 完整的 sofa-ark-plugin-maven-plugin 插件配置模板如下：\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 指定打包的 ${pluginName}.ark.plugin 存放目录; 默认放在 ${project.build.directory} --\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!-- 是否把 ark plugin 安装、发布到仓库，默认为true --\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!-- ark plugin 最多仅能指定一个 com.alipay.sofa.ark.spi.service.PluginActivator 接口实现类 --\u0026amp;gt; \u0026amp;lt;activator\u0026amp;gt;com.alipay.sofa.ark.service.impl.SampleActivator\u0026amp;lt;/activator\u0026amp;gt; \u0026amp;lt;!-- 配置优先级，数字越小，优先级越高，优先启动，优先导出类，默认1000 --\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;2000\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!-- 配置插件的名字，务必配置对，运行时，是插件的唯一标识 ID。比如 sofa-rpc 插件，可以配置为 sofa-rpc; 默认为 ${artifactId} --\u0026amp;gt; \u0026amp;lt;pluginName\u0026amp;gt;${ark.plugin.name}\u0026amp;lt;/pluginName\u0026amp;gt; \u0026amp;lt;!--设置 ark plugin 的 classifier, 默认为空, 如非必要，建议不用设置--\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;!-- 配置导入类、资源 --\u0026amp;gt; \u0026amp;lt;imported\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的 package --\u0026amp;gt; \u0026amp;lt;packages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;javax.servlet\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework.*\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/packages\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的 class --\u0026amp;gt; \u0026amp;lt;classes\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.rpc.config.ProviderConfig\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/classes\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的资源 --\u0026amp;gt; \u0026amp;lt;resources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/bean.xml\u0026amp;lt;/resource\u0026amp;gt;\u0026amp;gt; \u0026amp;lt;/resources\u0026amp;gt; \u0026amp;lt;/imported\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"684dc1caa0f834eec498905f95913f83","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","summary":"本小节将介绍 Ark Plugin 的标准规范和目录结构，以及如何使用官方插件 sofa-ark-plugin-maven-plugin 打包发布 Ark Plugin。 插件规范 标准的 Ark Plugin 需要满足以下规范： 插件必须配置插件名，","tags":null,"title":"Ark Plugin","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","wordcount":1937},{"author":null,"categories":null,"content":" Ark container class loading mechanism The plugins and business modules are managed in the Ark container. The following figure describes the class loading mechanism:\nClass loading mechanism of Ark container Each Ark plugin has a separate classloader which loads a class in the following order:\n If byte codes generated by reflection are loaded, the system will throw a ClassNotFoundException to terminate the loading process. This primarily comes from our engineering practice: to avoid long time searches for the classes that can never be found. Search for the already loaded classes Search for classes in the JDK, which mainly consists of two parts: 1) the classes to be loaded by ExtClassloader; 2) the classes that are provided by the JDK but fail to be loaded from the ExtClassloader. When running locally, however, these classes will be added to the SystemClassloader\u0026amp;rsquo;s classpath or they might be put into some third-party toolkits such as sun.tools.attach.BsdVirtualMachine in tool.jar at the same time. This part also comes from our engineering practice, avoiding errors caused by loading a class more than once. See if the class is an interface from Sofa Ark, such as com.alipay.sofa.Ark.spi.service.PluginActivator. If so, the class will be delegated to the classloader of the Ark container responsible for loading. See if it is located in the plugin import (including import-classes and import-package). If so, the loading will be delegated to the plugin classloader that will export it. Load in the plugin\u0026amp;rsquo;s own classpath If the above steps have failed, it will try to load the class in SymtemClassloader to deal with the situation that the agent is used. If the class fails to be loaded with all the above steps, the ClassNotFoundException will be thrown.\nArk business class loading mechanism Each Ark business has a separate classloader. Its class loading mechanism is basically consistent with that of Ark plugin, except for the step 5:\nFor Ark business, no import configuration is provided. Instead, it defaults to importing all classes exported by plug-ins. To deal with some particular business scenarios, however, we do provide the Deny-import configuration so that we can exclude the classes exported by some plugins.\nClass loading mechanism of Ark plugin resources The Ark plugin supports importing and exporting resources. To achieve this, we need to configure the corresponding import and export settings in sofa-Ark-plugin-maven-plugin. There are two ways to search for resources when using ClassLoader: ClassLoader.getResource(String) or ClassLoader.getResources(String);\n ClassLoader.getResource(String): When an Ark Plugin is searching for a single resource, it will delegate the Ark Plugin that will export the resource to load the class first. If multiple plugins export the resource at the same time, then the plugin with higher priority will export the resource first. If the loading fails or no other Ark Plugin has exported the resource, it will have a …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-classloader/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5803b870aae47885c37e4bbb02cb0a06","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","summary":"Ark container class loading mechanism The plugins and business modules are managed in the Ark container. The following figure describes the class loading mechanism:\nClass loading mechanism of Ark container Each Ark plugin has a separate classloader which loads a class in the following order:\n If byte codes generated by reflection are loaded, the system will throw a ClassNotFoundException to terminate the loading process. This primarily comes from our engineering practice: to avoid long time searches for the classes that can never be found.","tags":null,"title":"Ark container class loading mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","wordcount":549},{"author":null,"categories":null,"content":" Starting an Ark plug-in Ark provides the interface for starting a plug-in com.alipay.sofa.ark.spi.service.PluginActivator. The definition of the interface is as follows:\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } Once a plug-in implements this interface, and the activator attribute is configured in MANIFEST.MF, the plug-in will use the start method when it starts and the stop method when it stops.\nArk plug-in communication Ark plug-ins communicate using services. The interfaces used by the publishing and reference services are provided in the input parameter type com.alipay.sofa.ark.spi.model.PluginContext of the preceding method of starting an interface.\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param pluginName the name of the plugin which publish the service * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String pluginName); /** * Get Service List publish by plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;ServiceReference\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; referenceServices(Class\u0026amp;lt;T\u0026amp;gt; ifClass); A plug-in service is interface-specific. For one interface, the following descriptions are true: * Only one service can be published for each plug-in. When more than one service is published, the reference of the previously published service will be returned. * If you use referenceService to reference a single service when multiple plug-ins have published services, which service is returned depends on whether pluginName is specified: * When not specified, the service with the highest priority is returned. * When specified, the service published by the plugin with the specified name is returned.\nThe returned service reference ServiceReference is defined as follows:\npublic interface ServiceReference\u0026amp;lt;T\u0026amp;gt; { /** * get Service Object * @return service */ T getService(); /** * get Service Metadata * @return */ ServiceMetadata getServiceMetadata(); } public interface ServiceMetadata { /** * get Service Unique Name * @return service name */ String getServiceName(); /** * get Service Interface Class * @return interface class */ Class\u0026amp;lt;?\u0026amp;gt; getInterfaceClass(); /** * get …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-plugin/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b552fc51eb84cc0fa4c26860bd316490","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","summary":"Starting an Ark plug-in Ark provides the interface for starting a plug-in com.alipay.sofa.ark.spi.service.PluginActivator. The definition of the interface is as follows:\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } Once a plug-in implements this interface, and the activator attribute is configured in MANIFEST.","tags":null,"title":"Ark container plugin mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","wordcount":477},{"author":null,"categories":null,"content":" Ark container start process The startup process of the Ark container is illustrated as follows:\nArkService Ark Service is a service in the Ark container. The underlying layer uses Guice to manage the service. The service is provided with the lifecycle interface com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } After the service implements the preceding lifecycle interface, the Ark Service container invokes the interface when it starts and stops.\nPipeline service Pipeline is also a service registered in the Ark Service container. The service itself has no order or priority. The service is assembled in the Pipeline while the entire Ark container starts.\nArchive parsing At the very beginning of Pipeline, the running fatjar will be resolved into the models required for runtime, including the Ark plug-in model and the Ark business model, which are registered to the PluginManagerService and the BizManagerService in the Ark Service.\nDeploy the Ark plug-in Get all the Ark plug-ins from the PluginManagerService in the order of their priorities: * ClassloaderService prepares for the map mapping of plug-in export class * PluginDeployService starts com.alipay.sofa.Ark.spi.service.PluginActivator\nStart the Ark business Get all the Ark business from the BizManagerService, and execute the entry main function provided by the business configuration in the Main-Class attribute of MANIFEST.MF.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ad60e803febd20607686a1b4ea98efc3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","summary":"Ark container start process The startup process of the Ark container is illustrated as follows:\nArkService Ark Service is a service in the Ark container. The underlying layer uses Guice to manage the service. The service is provided with the lifecycle interface com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } After the service implements the preceding lifecycle interface, the Ark Service container invokes the interface when it starts and stops.","tags":null,"title":"Ark container startup process","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","wordcount":233},{"author":null,"categories":null,"content":" 使用 Ark 事件处理机制 SOFAArk 从 1.1.0 版本开始提供了全新的事件模型，囊括了 SOFAArk 中 biz 和 plugin 的各个生命周期；该版本提供的事件模型参考了 Spring 中的生命周期事件模型。本篇文档将描述如何使用 SOFAArk 的事件机制。\n事件概览 biz 生命周期事件 事件名 描述 AfterBizStartupEvent biz 启动之后发送的事件 AfterBizStopEvent biz 停止之后发送的事件 AfterBizSwitchEvent biz 切换之后发送的事件 BeforeBizStartupEvent biz 启动之前发送的事件 BeforeBizStopEvent biz 停止之前发送的事件 BeforeBizSwitchEvent biz 切换之前发送的事件 plugin 生命周期事件 事件名 描述 AfterPluginStartupEvent plugin 启动之后发送的事件 AfterPluginStopEvent plugin 停止之后发送的事件 BeforePluginStartupEvent plugin 启动之前发送的事件 BeforePluginStopEvent plugin 停止之前发送的事件 容器级别生命周期事件 事件名 描述 AfterFinishDeployEvent 执行完 DeployStage 阶段之后发送的事件 AfterFinishStartupEvent 执行完 Ark 容器启动之后发送的事件 事件监听 监听指定类型的事件 上述提到的各个阶段的事件，我们可以通过编写 EventHandler 来处理，例如，希望监听类型为 BeforeBizStartupEvent 的事件，则可以通过以下方式实现监听：\n@Component public class EventHandlerSample implements EventHandler\u0026amp;lt;BeforeBizStartupEvent\u0026amp;gt; { private static final Logger LOGGER = LoggerFactory.getLogger(\u0026amp;quot;EVENT-HANDLER-LOGGER\u0026amp;quot;); @Override public int getPriority() { return 0; } @Override public void handleEvent(BeforeBizStartupEvent event) { Biz source = event.getSource(); LOGGER.info(\u0026amp;quot;begin to startup biz, current biz is: {}\u0026amp;quot;,source.getIdentity()); } } 日志目录：target/test/logs/host-app/event-handler.log 日志输出： 2019-11-28 15:18:33,248 INFO EVENT-HANDLER-LOGGER - begin to startup biz, current biz is: provider1:2.0.0, bizState: resolved\n 在此基础上，在提供其他几个 event 的处理器：\n AfterBizStartupEvent @Component public class AfterBizStartupEventHandler implements EventHandler\u0026amp;lt;AfterBizStartupEvent\u0026amp;gt; { private static final Logger LOGGER = LoggerFactory.getLogger(\u0026amp;quot;EVENT-HANDLER-LOGGER\u0026amp;quot;); @Override public void handleEvent(AfterBizStartupEvent event) { Biz source = event.getSource(); LOGGER.info(\u0026amp;quot;after startup biz, current biz is: {}, bizState: {}\u0026amp;quot;,source.getIdentity(),source.getBizState() ); } @Override public int getPriority() { return 0; } } 分别启动 基座 -\u0026amp;gt; 安装 ark-provider 模块 -\u0026amp;gt; 卸载 ark-provider 模块 ，然后看到日志输出如下：\n2019-11-28 15:31:42,325 INFO EVENT-HANDLER-LOGGER - after startup biz, current biz is: host-app:2.0.0, bizState: resolved 2019-11-28 15:36:23,956 INFO EVENT-HANDLER-LOGGER - begin to startup biz, current biz is: provider1:2.0.0, bizState: resolved 2019-11-28 15:36:27,216 INFO EVENT-HANDLER-LOGGER - after startup biz, current biz is: provider1:2.0.0, bizState: resolved 2019-11-28 15:53:38,225 INFO EVENT-HANDLER-LOGGER - before stop biz, current biz is: provider1:2.0.0, bizState: deactivated 2019-11-28 15:53:38,233 INFO EVENT-HANDLER-LOGGER - after biz stop, current biz is: provider1:2.0.0, bizState: unresolved 监听不指定类型的事件 某些情况下，如果期望监听所有 biz 或者 plugin 生命周期事件，可以使用以下方式：\n@Component public class AbstractArkEventHandler implements EventHandler\u0026amp;lt;AbstractArkEvent\u0026amp;gt; { @Override public int getPriority() { return 0; } @Override public void handleEvent(AbstractArkEvent event) { System.out.println(\u0026amp;quot;------------ current event topic: \u0026amp;quot; + event.getTopic()); } } 为了 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-event/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b0f233742572536edc8a517cf7547269","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","summary":"使用 Ark 事件处理机制 SOFAArk 从 1.1.0 版本开始提供了全新的事件模型，囊括了 SOFAArk 中 biz 和 plugin 的各个生命周期；该版本提供的事件模型参考了 Spring 中的生命周期事件模型。本篇","tags":null,"title":"Ark 事件机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","wordcount":1254},{"author":null,"categories":null,"content":" 本小节将介绍标准 Ark 包 的目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark 包。\nMaven 插件 官方提供 Maven 插件 sofa-ark-maven-plugin 可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式 Ark 包 ；基于 Fat Jar 技术，使用 java -jar 命令可以直接启动 Ark 包 。 Maven 插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals sofa-ark-maven-plugin 插件提供 goal: repackage， 可以将工程打包成可执行的 Ark 包，如下配置：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 配置信息 --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 完整配置模板 完整的 sofa-ark-maven-plguin 插件配置模板如下：\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--设置应用的根目录，用于读取 ${base.dir}/conf/ark/bootstrap.application 配置文件，默认为 ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;./\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;!--生成 ark 包文件名称，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;finalName\u0026amp;gt;demo-ark\u0026amp;lt;/finalName\u0026amp;gt; \u0026amp;lt;!--是否跳过执行 goal:repackage，默认为false--\u0026amp;gt; \u0026amp;lt;skip\u0026amp;gt;false\u0026amp;lt;/skip\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--设置 ark 包的 classifier，默认为空--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 classifier，默认为 ark-biz--\u0026amp;gt; \u0026amp;lt;bizClassifier\u0026amp;gt;ark-biz\u0026amp;lt;/bizClassifier\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 biz name，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;bizName\u0026amp;gt;demo-ark\u0026amp;lt;/bizName\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 biz version，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;bizVersion\u0026amp;gt;0.0.1\u0026amp;lt;/bizVersion\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 启动优先级，值越小优先级越高，${artifactId}--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;100\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的启动入口，默认会搜索被打 org.springframework.boot.autoconfigure.SpringBootApplication 注解且含有 main 方法的入口类--\u0026amp;gt; \u0026amp;lt;mainClass\u0026amp;gt;com.alipay.sofa.xx.xx.MainEntry\u0026amp;lt;/mainClass\u0026amp;gt; \u0026amp;lt;!--设置是否将 scope=provided 的依赖打包，默认为 false--\u0026amp;gt; \u0026amp;lt;packageProvided\u0026amp;gt;false\u0026amp;lt;/packageProvided\u0026amp;gt; \u0026amp;lt;!--设置是否生成 Biz 包，默认为true--\u0026amp;gt; \u0026amp;lt;keepArkBizJar\u0026amp;gt;true\u0026amp;lt;/keepArkBizJar\u0026amp;gt; \u0026amp;lt;!--针对 Web 应用，设置 context path，默认为 /--\u0026amp;gt; \u0026amp;lt;webContextPath\u0026amp;gt;/\u0026amp;lt;/webContextPath\u0026amp;gt; \u0026amp;lt;!--打包 ark biz 时，排除指定的包依赖；格式为: ${groupId:artifactId} 或者 ${groupId:artifactId:classifier}--\u0026amp;gt; \u0026amp;lt;excludes\u0026amp;gt; \u0026amp;lt;exclude\u0026amp;gt;org.apache.commons:commons-lang3\u0026amp;lt;/exclude\u0026amp;gt; \u0026amp;lt;/excludes\u0026amp;gt; \u0026amp;lt;!--打包 ark biz 时，排除和指定 groupId 相同的包依赖--\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jar/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c2a9b8ad142f15b9ee82d7d9d8237850","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","summary":"本小节将介绍标准 Ark 包 的目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark 包。 Maven 插件 官方提供 Maven 插件 sofa-ark-maven-plugin 可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式 Ark 包 ；","tags":null,"title":"Ark 包","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","wordcount":1626},{"author":null,"categories":null,"content":" Ark 应用的整体启动流程如下图所述：\n当用 java -jar 启动 Ark 包 或者 在 IDE 中通过 SofaArkBootstrap.launch 启动 Ark 应用时，相应 Launcher 入口会负责启动应用，其中会反射调用 ArkContainer 的入口，初始化 ArkService ，然后依次执行 pipeline，来完成整个 Ark 应用的启动。\nArkService Ark Serivce 是 Ark 容器中的服务，底层使用 Guice 对服务进行管理。同时针对服务，提供了生命周期接口 com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } 当服务实现了上述接口时，在 Ark Serivce 容器启动时和停止时会调用相应的生命周期接口\nPipeline 服务 Pipeline 也是注册在 Ark Service 容器中的一个服务，服务本身是没有顺序和优先级的，在 Pipeline 中会对服务进行一些组装，同时完成整个 Ark 容器的启动\nArchive 解析 在 Pipeline 的最开始，会将运行的 fatjar 进行解析，解析成运行时需要的模型，主要包括 Ark 插件模型和 Ark 业务模型，并将这些模型注册到 Ark Service 中的 PluginManagerService 以及 BizManagerService 中\n初始化环境 设置一些运行时需要的默认参数，比如设置 log4j.ignoreTCL 为 true 让 log4j/log4j2 初始化是日志不要从 ThreadContextClassloader 中寻找配置文件(背景)\n注册容器服务 在 Ark 容器中会发布一些服务供其它的插件来使用，比如 BizDeployer 来让 SOFAArk 官方插件 sofa-jarslink 来完成 biz 的动态加载/卸载等\n部署 Ark 插件 从 PluginManagerService 中获取到所有的 Ark 插件，并按照插件优先级顺序： * ClassloaderService 准备插件 export 类的 map 映射 * PluginDeployService 启动插件的 com.alipay.sofa.ark.spi.service.PluginActivator\n启动 Ark 业务 从 BizManagerService 中获取到所有的 Ark 业务，并执行业务配置在 MANIFEST.MF 属性 Main-Class 中提供的入口 main 函数\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ad60e803febd20607686a1b4ea98efc3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","summary":"Ark 应用的整体启动流程如下图所述： 当用 java -jar 启动 Ark 包 或者 在 IDE 中通过 SofaArkBootstrap.launch 启动 Ark 应用时，相应 Launcher 入口会负责启动应用，其中会反射调用 ArkContainer 的入口，初始化 ArkService ，然","tags":null,"title":"Ark 容器启动流程","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","wordcount":523},{"author":null,"categories":null,"content":" Ark 插件启动 Ark 中提供了插件启动的接口 com.alipay.sofa.ark.spi.service.PluginActivator ，其定义如下：\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } 插件只需要实现此接口，并在 MANIFEST.MF 中配置 activator 属性，就会在启动时执行 start 方法，停止时执行 stop 方法\nArk 插件通信 Ark 之间的通信是通过服务来完成的， 在上述启动接口方法的入参类型 com.alipay.sofa.ark.spi.model.PluginContext 中提供了发布服务和引用服务的接口\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param pluginName the name of the plugin which publish the service * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String pluginName); /** * Get Service List publish by plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;ServiceReference\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; referenceServices(Class\u0026amp;lt;T\u0026amp;gt; ifClass); 插件服务是以接口为粒度的，针对同一个接口： * 每一个插件只允许发布一个服务，重复发布则会直接返回已经发布服务的引用 * 当多有个插件发布服务时，若通过 referenceService 引用单个服务 * 当不指定 pluginName 时，则返回优先级最高的服务 * 当指定 pluginName 时，则返回该插件发布的服务\n返回的服务引用 ServiceReference 定义如下:\npublic interface ServiceReference\u0026amp;lt;T\u0026amp;gt; { /** * get Service Object * @return service */ T getService(); /** * get Service Metadata * @return */ ServiceMetadata getServiceMetadata(); } public interface ServiceMetadata { /** * get Service Unique Name * @return service name */ String getServiceName(); /** * get Service Interface Class * @return interface class */ Class\u0026amp;lt;?\u0026amp;gt; getInterfaceClass(); /** * get ServiceProvider * @return */ ServiceProvider getServiceProvider(); } 其中通过 * getService() 可以获取到服务的实体 (也即发布服务时的 implObject) * getServiceMetadata() 可以获取到服务的元数据信息，包括 * 服务名：即服务的接口名 * 服务接口 * 服务的提供方：包括提供方名字(插件名等)、提供方优先级(插件优先级)\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-plugin/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b552fc51eb84cc0fa4c26860bd316490","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","summary":"Ark 插件启动 Ark 中提供了插件启动的接口 com.alipay.sofa.ark.spi.service.PluginActivator ，其定义如下： public interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } 插件只需要实","tags":null,"title":"Ark 容器插件机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","wordcount":574},{"author":null,"categories":null,"content":" Ark 容器类加载机制 Ark 容器中会管理插件和业务，整体的类加载机制可见如下图描述：\nArk 插件类加载机制 每个 Ark 插件都拥有一个独立的类加载器，其类加载的顺序如下：\n 如果是加载反射生成的字节码，那么会直接抛出 ClassNotFoundException，终止类加载。这一部分主要是来源于我们的工程实践，避免一定找不到的类查找路径过长 查找已经被加载过的类 查找 JDK 中的类，这一块主要包含两部分：第一部分是 ExtClassloader 负责加载的类；第二部分是 JDK 提供的类但从 ExtClassloader 中加载不到，但在本地运行时会被加入到 SystemClassloader 的 classpath 中，同时这些类可能会被放到一些三方工具包中，典型的如 tool.jar 中 sun.tools.attach.BsdVirtualMachine,这一部分也主要来源于我们的工程实践，避免类被加载超过一次，从而引发报错 看类是否是由 Sofa Ark 提供的接口类，典型的如: com.alipay.sofa.ark.spi.service.PluginActivator, 如果是，则类会委托给 Ark 容器的类加载器加载 看是否在插件的 import 中(包括 import-classes 和 import-package)， 如果在，则会委托给导出该类的插件类加载器加载 在插件自身的 classpath 中加载 如果上述都失败了，则会尝试在 SymtemClassloader 中加载，这一步主要是为了解决使用 agent 时的情形 如果上述的步骤都加载失败了，则抛出 ClassNotFoundException\nArk 业务类加载机制 每个 Ark 业务都拥有一个独立的类加载器， Ark 业务类加载机制基本上与 Ark 插件保持一致，在上述的7步中，主要是第5步不一样：\n对于 Ark 业务而言，并没有提供 import 的配置，而是认为默认 import 所有插件 export 出来的类；但为了一些特殊的业务场景，我们提供了 Deny-import 的配置让业务可以排除掉某些插件导出的类\nArk 插件资源加载机制 Ark 插件支持导入导出资源，需要在 sofa-ark-plugin-maven-plugin 配置相关的导入导出配置；在使用 ClassLoader 加载资源时，存在两种方式查找资源，ClassLoader.getResource(String) 和 ClassLoader.getResources(String)；\n ClassLoader.getResource(String): Ark Plugin 在查找单个资源时，会优先委托导出该资源的 Ark Plugin 加载，如果有多个插件同时导出，则优先级高的插件优先导出；如果加载失败或者没有其他 Ark Plugin 导出，则尝试在本 Ark Plugin 查找加载；\n ClassLoader.getResources(String): Ark Plugin 在查找多个资源时，会从所有导出该资源的 Ark Plugin 加载，同时也会从本 Ark Plugin 加载资源；\n Ark 业务资源加载机制 默认情况下，Ark Biz 会优先加载 Ark Plugin 导出的资源；如果开发者希望只在工程应用内部查找，则可以通过 sofa-ark-maven-plugin 配置 denyImportResources；如此，Ark Biz 不会从 Ark Plugin 查找该资源，只会在 Ark Biz 内部查找。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-classloader/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5803b870aae47885c37e4bbb02cb0a06","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","summary":"Ark 容器类加载机制 Ark 容器中会管理插件和业务，整体的类加载机制可见如下图描述： Ark 插件类加载机制 每个 Ark 插件都拥有一个独立的类加载器，其类加载的顺序","tags":null,"title":"Ark 容器类加载机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","wordcount":974},{"author":null,"categories":null,"content":" Ark 容器和 Ark Plugin 在运行时由不同的类加载器加载，不能使用常规的 ServiceLoader 提供 SPI 扩展，SOFAArk 自定义扩展点 SPI 机制， Ark Plugin 实现 SPI 机制，考虑到 Biz 卸载问题，Ark Biz 暂时不支持该 SPI 机制，只适用于 Ark Plugin 之间。\n声明扩展接口 使用注解 @Extensible 声明扩展接口，注解定义如下：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Extensible { /** * return specify extensible file name, default value is the * full name of interface. */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * return whether this a singleton, with a single, shared instance * returned on all calls, default value is true. */ boolean singleton() default true; } file 用于声明 SPI 扩展文件名，默认为接口全类名 singleton 用于声明加载扩展类是否为单例模式 声明扩展实现 使用注解 @Extension 声明扩展实现，注解定义如下：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Extension { /** * extension name */ String value(); /** * extension order, Higher values are interpreted as lower priority. * As a consequence, the object with the lowest value has the highest * priority. */ int order() default 100; } value 用于定义扩展实现名称，例如不同的插件扩展同一个接口，可能会取不同的名字。 order 用于决定具体扩展实现的生效顺序 运行时，对于同一个接口的扩展实现生效规则如下： + 规则一：名称相同的扩展实现，只会返回优先级高的扩展实现类，order 数字越小，优先级越高 + 规则二：名称不相同的扩展实现，则返回一个对应的 List 列表，每个名称返回优先级最高的扩展实现\n加载 SPI 实现类 正常情况下，我们使用 ServiceLoader 加载 SPI 接口实现；SOFAArk 提供了工具类 ArkServiceLoader 用于加载扩展实现，工具类定义了两个简单的方法：\npublic class ArkServiceLoader { private static ExtensionLoaderService extensionLoaderService; // 方法一 public static \u0026amp;lt;T\u0026amp;gt; T loadExtension(Class\u0026amp;lt;T\u0026amp;gt; interfaceType, String extensionName) { return extensionLoaderService.getExtensionContributor(interfaceType, extensionName); } // 方法二 public static \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;T\u0026amp;gt; loadExtension(Class\u0026amp;lt;T\u0026amp;gt; interfaceType) { return extensionLoaderService.getExtensionContributor(interfaceType); } } 方法一：用于加载指定接口和名称的扩展实现，返回单个结果。参考上述规则一 方法二：用于加载指定接口的扩展实现，返回列表结果。参考上述规则二 需要注意下，定义 SPI 接口的插件需要导出该接口，负责实现 SPI 接口的插件需要导入该接口。另外 SOFAArk 容器本身也会定义部分用于插件扩展实现的 SPI 接口，例如 ClassLoaderHook\n为什么不支持 Biz 的 SPI 扩展实现加载 考虑到 Biz 会动态的安装和卸载，如果支持 Biz 的扩展实现加载，生命周期容易引起混乱，暂时不考虑支持。如果确实存在 Ark Plugin 需要主动触发 Ark Biz 的逻辑调用，可以通过 SOFAArk 内部事件机制。\nSOFAArk 默认扩展点 SOFAArk 容器目前提供了唯一一个扩展点 ClassLoaderHook，用于其他插件提供扩展实现，自定义类/资源加载逻辑。ClassLoaderHooker 接口定义如下，用于扩展 BizClassLoader 和 PluginClassLoader 类(资源）加载逻辑：\n@Extensible public interface ClassLoaderHook\u0026amp;lt;T\u0026amp;gt; { Class\u0026amp;lt;?\u0026amp;gt; preFindClass(String name, ClassLoaderService classLoaderService, T t) throws ClassNotFoundException; Class\u0026amp;lt;?\u0026amp;gt; postFindClass(String name, ClassLoaderService classLoaderService, T t) throws ClassNotFoundException; URL preFindResource(String name, ClassLoaderService classLoaderService, T t); URL postFindResource(String name, ClassLoaderService classLoaderService, T t); Enumeration\u0026amp;lt;URL\u0026amp;gt; preFindResources(String name, ClassLoaderService classLoaderService, T t) throws IOException; Enumeration\u0026amp;lt;URL\u0026amp;gt; postFindResources(String name, ClassLoaderService classLoaderService, T t) throws IOException; } 通过在插件中扩展该 SPI 接口实现，可以自定义 PluginClassLoader 和 BizClassLoader 的类/资源的加载逻辑。 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-extension/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"685e049f442cde4f3f51fefad5453dae","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","summary":"Ark 容器和 Ark Plugin 在运行时由不同的类加载器加载，不能使用常规的 ServiceLoader 提供 SPI 扩展，SOFAArk 自定义扩展点 SPI 机制， Ark Plugin 实现 SPI 机制，考虑到 Biz 卸载问题，A","tags":null,"title":"Ark 扩展机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","wordcount":1961},{"author":null,"categories":null,"content":"SOFAArk 容器使用了 logback 日志实现，并集成了 sofa-common-tools，日志相关配置可以参考 配置文档, 这里介绍 SOFAArk 三个日志文件：\n sofa-ark/common-default.log \u0026amp;gt; sofa-ark 默认日志，打印 SOFAArk 启动日志等，大概内容如下： 2019-03-12 15:08:55,758 INFO main - Begin to start ArkServiceContainer 2019-03-12 15:08:56,290 INFO main - Init Service: com.alipay.sofa.ark.container.session.StandardTelnetServerImpl 2019-03-12 15:08:56,311 INFO main - Listening on port: 1234 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.plugin.PluginDeployServiceImpl 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.biz.BizDeployServiceImpl 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.classloader.ClassLoaderServiceImpl 2019-03-12 15:08:56,317 INFO main - Finish to start ArkServiceContainer 2019-03-12 15:08:56,338 INFO main - Start to process pipeline stage: com.alipay.sofa.ark.container.pipeline.HandleArchiveStage 2019-03-12 15:08:56,349 INFO main - Finish to process pipeline stage: com.alipay.sofa.ark.container.pipeline.HandleArchiveStage 2019-03-12 15:08:56,349 INFO main - Start to process pipeline stage: com.alipay.sofa.ark.container.pipeline.RegisterServiceStage 2019-03-12 15:08:56,354 INFO main - Service: com.alipay.sofa.ark.spi.service.biz.BizManagerService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,354 INFO main - Service: com.alipay.sofa.ark.spi.service.biz.BizFactoryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,355 INFO main - Service: com.alipay.sofa.ark.spi.service.plugin.PluginManagerService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,356 INFO main - Service: com.alipay.sofa.ark.spi.service.plugin.PluginFactoryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,356 INFO main - Service: com.alipay.sofa.ark.spi.service.event.EventAdminService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,357 INFO main - Service: com.alipay.sofa.ark.spi.service.registry.RegistryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,360 INFO main - Inject {field= bizManagerService} of {service= ServiceMetadata{service=\u0026#39;com.alipay.sofa.ark.spi.service.biz.BizDeployer\u0026#39;, provider=\u0026#39;ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=100}\u0026#39;}} success! sofa-ark/common-error.log \u0026amp;gt; sofa-ark 错误日志，打印 SOFAArk 容器运行时错误日志，例如 biz 启动失败日志等： 2019-03-12 16:38:41,873 ERROR main - Start biz: Startup In IDE meet error java.lang.reflect.InvocationTargetException: null at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-log/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a514225510e53e9bf7173734c1f878e1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","summary":"SOFAArk 容器使用了 logback 日志实现，并集成了 sofa-common-tools，日志相关配置可以参考 配置文档, 这里介绍 SOFAArk 三个日志文件： sofa-ark/common-default.log \u0026gt; sofa-ark 默认日志，打","tags":null,"title":"Ark 日志","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","wordcount":667},{"author":null,"categories":null,"content":" SOFAArk 定义了两种服务类型，用于解决应用和插件，应用和应用之间的通信问题，下面分别介绍这两种服务类型：\n插件服务 SOFAArk 允许在 Plugin 通过 PluginContext 发布和引用服务，也可以使用注解 @ArkInject 引用服务。为了方便开发高级特性，SOFAArk 容器默认将内部功能组件发布成了服务，包括 Biz 管理，Plugin 管理，事件管理，服务注册管理。目前不允许 Biz 发布服务，只能引用插件服务。下面介绍如何发布和引用插件服务，以及 SOFAArk 容器默认发布的服务。\n发布服务 每个 Plugin 都可以定义唯一的插件入口，需要实现 PluginActivator 接口并在打包插件配置中声明，先看下接口定义：\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkRuntimeException */ void start(PluginContext context); /** * Stop Plugin * @param context * @throws ArkRuntimeException */ void stop(PluginContext context); } SOFAArk 容器在启动插件时，会调用插件启动入口(如果有)，因此如果插件实现方需要发布插件服务供其他插件或者 Biz 调用，可以使用入参 PluginContext 发布服务，PluginContext 提供了两个方法发布服务：\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param uniqueId service implementation id * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject, String uniqueId); 这两个方法的区别在于是否指定 uniqueId，因为同一个接口，可能会有多个服务实现，因此需要使用 uniqueId 区别，同样在引用端也需要指定 uniqueId. 默认 uniqueId 为空\n引用服务 SOFAArk 提供了两种方式引用插件服务，在插件内部，可以直接使用 PluginContext 引用服务，PluginContext 提供了两个简单的方法引用服务：\n/** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param uniqueId service implementation * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String uniqueId); 在 Biz 内部，如果是 Spring Boot/SOFABoot 应用，可以直接使用注解 @ArkInject 引用服务，注解声明如下：\n@java.lang.annotation.Target(ElementType.FIELD) @java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME) @java.lang.annotation.Documented public @interface ArkInject { /** * ark service interface * @return */ Class\u0026amp;lt;?\u0026amp;gt; interfaceType() default void.class; /** * ark service uniqueId * * @return return reference unique-id */ String uniqueId() default \u0026amp;quot;\u0026amp;quot;; } SOFAArk 提供集成 Spring Boot/SOFABoot 功能，在 Field 上打上 @ArkInject，指定接口类型和 uniqueId 即可完成自动注入。为了更加方便的使用，如果没有指定 interfacetType 类型，默认使用被打注解的 Field 类型。\n在插件内部，有时候也可以使用 @ArkInject 引用服务，即插件在发布某个服务时，服务内部可以直接使用 @ArkInject 引用服务；需要注意的是，被引用的服务如果是其他插件发布的，则必须满足其他插件优先当前插件启动。\n默认服务 前面提到，为了方便 Plugin 和 Biz 开发高级特性，SOFAArk 将内部功能组件发布成服务，包括：\n BizManageService \u0026amp;gt; Biz 管理器，管理、查询 Biz 信息\n BizFactoryService \u0026amp;gt; Biz 解析器，解析 Biz 文件\n PluginManagerService \u0026amp;gt; Plugin 管理器，管理、查询 Plugin 信息\n PluginFactoryService \u0026amp;gt; Plugin 解析器，解析 Plugin 文件\n EventAdminService \u0026amp;gt; SOFAArk 事件管理器， …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-service/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"81b7e697b890139c03831cdb648e094b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","summary":"SOFAArk 定义了两种服务类型，用于解决应用和插件，应用和应用之间的通信问题，下面分别介绍这两种服务类型： 插件服务 SOFAArk 允许在 Plugin 通过 PluginContext 发布和引用服务，也可","tags":null,"title":"Ark 服务机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","wordcount":1188},{"author":null,"categories":null,"content":" 在 Ark 服务机制 中，我们详细介绍了如何引用和发布插件服务，主要是解决 Plugin 和 Biz 的通信问题；为了解决 Biz 之间的通信问题，SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference 编程界面；下面介绍其使用方法。\n引入依赖 引入 runtime-sofa-boot-plugin 依赖，如果应用基于 Spring Boot 1.x 开发，推荐使用 v2.6.1 版本；如果应用基于 Spring Boot 2.x 开发，推荐使用 v3.1.3 版本；\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 发布和引用 JVM 服务 SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference JVM 服务概念(参考文档)，为了方便文档统一，重复其介绍。\nSOFABoot 提供三种方式给开发人员发布和引用 JVM 服务\n XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上面的 Bean 发布成一个 SOFA JVM 服务。\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 上面的配置中的 interface 指的是需要发布成服务的接口，ref 指向的是需要发布成 JVM 服务的 Bean，至此，我们就已经完成了一个 JVM 服务的发布。\n服务引用 使用 SOFA 提供的 Spring 扩展标签引用服务:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上面的配置中的 interface 是服务的接口，需要和发布服务时配置的 interface 一致。id 属性的含义同 Spring BeanId。上面的配置会生成一个 id 为 sampleServiceRef 的 Spring Bean，你可以将 sampleServiceRef 这个 Bean 注入到当前 SOFABoot 模块 Spring 上下文的任意地方。\n service/reference 标签还支持 RPC 服务发布，相关文档: RPC 服务发布与引用\n Annotation 方式 警告\n如果一个服务已经被加上了 @SofaService 的注解，它就不能再用 XML 的方式去发布服务了，选择一种方式发布服务，而不是两种混用。\n 除了通过 XML 方式发布 JVM 服务和引用之外，SOFABoot 还提供了 Annotation 的方式来发布和引用 JVM 服务。通过 Annotation 方式发布 JVM 服务，只需要在实现类上加一个 @SofaService 注解即可，如下：\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } 提示\n@SofaService 的作用是将一个 Bean 发布成一个 JVM 服务，这意味着虽然你可以不用再写 \u0026amp;lt;sofa:service/\u0026amp;gt; 的配置，但是还是需要事先将 @SofaService 所注解的类配置成一个 Spring Bean。\n 在使用 XML 配置 \u0026amp;lt;sofa:service/\u0026amp;gt; 的时候，我们配置了一个 interface 属性，但是在使用 @SofaService 注解的时候，却没有看到有配置服务接口的地方。这是因为当被 @SofaService 注解的类只有一个接口的时候，框架会直接采用这个接口作为服务的接口。当被 @SofaService 注解的类实现了多个接口时，可以设置 @SofaService 的 interfaceType 字段来指定服务接口，比如下面这样：\n@SofaService(interfaceType = SampleInterface.class) public class SampleImpl implements SampleInterface, Serializable { public void test() { } } 和 @SofaService 对应，Sofa 提供了 @SofaReference 来引用一个 JVM 服务。假设我们需要在一个 Spring Bean 中使用 SampleJvmService 这个 JVM 服务，那么只需要在字段上加上一个 @SofaReference 的注解即可：\npublic class SampleServiceRef { @SofaReference private SampleService sampleService; } 和 @SofaService 类似，我们也没有在 @SofaReference 上指定服务接口，这是因为 @SofaReference 在不指定服务接口的时候，会采用被注解字段的类型作为服务接口，你也可以通过设定 @SofaReference 的 interfaceType 属性来指定：\npublic class SampleServiceRef { @SofaReference(interfaceType = SampleService.class) private SampleService sampleService; } 使用 @SofaService 注解发布服务时，需要在实现类上打上 @SofaService 注解；在 Spring Boot 使用 Bean Method 创建 Bean 时，会导致 @Bean 和 @SofaService 分散在两处，而且无法对同一个实现类使用不同的 unique id。 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jvm/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1bf80b24428da0f91edc6af7b63f6047","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","summary":"在 Ark 服务机制 中，我们详细介绍了如何引用和发布插件服务，主要是解决 Plugin 和 Biz 的通信问题；为了解决 Biz 之间的通信问题，SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference 编","tags":null,"title":"Ark 服务通信","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","wordcount":2430},{"author":null,"categories":null,"content":" Use java.lang.Runnable in thread If you start a thread via java.lang.Runnable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerRunnable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.start(); Use java.util.concurrent.Callable in thread If you start a thread via java.util.concurrent.Callable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerCallable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nExecutorService executor = Executors.newCachedThreadPool(); SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt; sofaTracerSpanSofaTracerCallable = new SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt;(new Callable\u0026amp;lt;Object\u0026amp;gt;() { @Override public Object call() throws Exception { return new Object(); } }); Future\u0026amp;lt;Object\u0026amp;gt; futureResult = executor.submit(sofaTracerSpanSofaTracerCallable); //do something in current thread Thread.sleep(1000); //another thread execute success and get result Object objectReturn = futureResult.get(); This example assumes that the object type returned by java.util.concurrent.Callable is java.lang.Object. You can replace it with the expected type based on actual situation.\nSOFATracer support for thread pool and asynchronous call scenarios Asynchronous Asynchronous invocation, in RPC calls, for example,each time the rpc call request goes out, it will not wait until the result is returned before initiating the next call. There is a time difference here, before the callback of the previous rpc call comes back, another new one begin. At this time, the TracerContext in the current thread is not cleaned up, the spanId will be incremented, and the tracerId is the same.\n For the above situation, when the SOFATracer is processed for the asynchronous situation, it will not wait for the callback to execute, and then the cr phase will be cleaned up. Instead, the current thread\u0026amp;rsquo;s tracerContext context will be cleaned up in advance to ensure the correctness of the link.\nThread Pool For now, whether it\u0026amp;rsquo;s SOFARPC or Dubbo\u0026amp;rsquo;s trace implementation, the situation is the same when using single-thread or thread pools:\n Synchronous call. A thread in the thread pool is allocated to handle the RPC request. This does not cause the next RPC request to take the tracerContext data of the previous request by mistake Asynchronous calls, since the asynchronous callback is not in the callback to clean up the context, but in advance, there is no dirty data problem. callback, which is essentially an …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/async/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e755346c441115663c101638667fe4c0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/async/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/async/","summary":"Use java.lang.Runnable in thread If you start a thread via java.lang.Runnable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerRunnable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.","tags":null,"title":"Asynchronous thread processing","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/async/","wordcount":436},{"author":null,"categories":null,"content":" ## Model\nApplications Jarslink manages the life cycle of multiple applications. During runtime dynamic deployment, it usually converts a Jar file entity into an abstract model Biz. + Biz: abstract model of the application at runtime\nInstruction Currently, Jarslink supports the telnet protocol and accepts the entered instructions. In the future, it will also support instruction execution through APIs. Acceptable instruction types: + InstallCommand: install the application + UninstallCommand: uninstall the application + CheckCommand: check the application state + SwitchCommand: switch the application state\nService The Jarslink plugin has expanded the SOFAArk container\u0026amp;rsquo;s services of BizDeployer and CommandProvider and referenced the SOFAArk container\u0026amp;rsquo;s exposed services of BizManagerService and BizFactoryService. + BizDeployer is the application deployment extension point provided by the SOFAArk container, and it is used to control the Biz startup in the Ark package. Jarslink has registered its own implementation with the SOFAArk container. + CommandProvider is the command processing extension point provided by the SOFAArk container, and it is used to process the commands received by the SOFAArk container through a telnet link. + BizManagerService is the Biz manager exposed by the SOFAArk container, and it is used for registration, deregistration, and other operations. + BizFactoryService is the Biz generator exposed by the SOFAArk container, and it is used to abstract static Biz package files into runtime Biz models.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-model/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"991cb277d50874fa27095b920ac9b736","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","summary":"## Model\nApplications Jarslink manages the life cycle of multiple applications. During runtime dynamic deployment, it usually converts a Jar file entity into an abstract model Biz. + Biz: abstract model of the application at runtime\nInstruction Currently, Jarslink supports the telnet protocol and accepts the entered instructions. In the future, it will also support instruction execution through APIs. Acceptable instruction types: + InstallCommand: install the application + UninstallCommand: uninstall the application + CheckCommand: check the application state + SwitchCommand: switch the application state","tags":null,"title":"Basic model","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","wordcount":221},{"author":null,"categories":null,"content":" Messages All messages are internally passed through SofaRequest and SofaResponse.\nTo convert to other protocols, you need to transform the messages to the objects that are to be actually transferred when calling and receiving requests.\nThe modules that can write SofaRequest and SofaResponse are as follows:\n Invoker Filter ServerHandler Serialization The modules that can only read message bodies are as follows:\n Cluster Router LoadBalance Logs The log initialization is based on the extension mechanism. Since the log loading should be done earliest, there is a separate key in rpc-config.json.\n{ / / Log implementation is done earlier than configuration loading, so it cannot adapt to the extension mechanism \u0026amp;quot;logger.impl\u0026amp;quot;: \u0026amp;quot;com.alipay.sofa.rpc.log.MiddlewareLoggerImpl\u0026amp;quot; } Configuration items RPC configuration for users The user configuration includes port configuration (although the fields for setting port in the objects have been opened, SOFA gets those fields from the configuration file by default), thread pool size configuration, and other configurations.\n Load the configuration via SofaConfigs and call ExternalConfigLoader to read external properties. Get the configuration through the API provided by SofaConfigs. All the internally configured keys are in the SofaOptions class. Priority: System.property \u0026amp;gt; sofa-config.properties (one for each application) \u0026amp;gt; rpc-config.properties. RPC framework configuration The configuration of the framework itself, such as default serialization and default timeout. In the future, SOFARPC may support the configuration for multiple ClassLoaders.\n Load the configuration file via RpcConfigs. Get and listen to data changes via the API provided by RpcConfigs All internally configured keys are in the RpcOptions class Priority: System.property \u0026amp;gt; custom rpc-config.json (There may be multiple custom configuration files which are sorted in certain order) \u0026amp;gt; rpc-config-default.json. Constants The global basic constants are in RpcConstants. For example: Calling method (sync/oneway) Protocol (bolt/grpc/rest); serialization (hessian/java/protobuf) Context key If the extension implements its own constants, you need to maintain the constants yourself. For example:\n The constants of BOLT protocol SERIALIZE_CODE_HESSIAN = 1 PROTOCOL_TR = 13 The constants related with DSR Configuration Center The keys specific for DSR Configuration Center, such as _WEIGHT and _CONNECTTIMEOUT Address The address information of provider is placed in the ProviderInfo class. The value of ProviderInfo is mainly divided into three parts: Fields, which are generally required items, such as IP, port and status. Static fields, such as application name. Dynamic fields, such as warm-up weight. Field enumerations are maintained in the ProviderInfoAttrs class. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/common-model/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b2cc3f7ed134408d6adc25e418e1978b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/common-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/common-model/","summary":"Messages All messages are internally passed through SofaRequest and SofaResponse.\nTo convert to other protocols, you need to transform the messages to the objects that are to be actually transferred when calling and receiving requests.\nThe modules that can write SofaRequest and SofaResponse are as follows:\n Invoker Filter ServerHandler Serialization The modules that can only read message bodies are as follows:\n Cluster Router LoadBalance Logs The log initialization is based on the extension mechanism.","tags":null,"title":"Basic model","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/common-model/","wordcount":386},{"author":null,"categories":null,"content":" Publish Service To use SOFARPC to publish a Bolt-protocol service, you only need to add a Binding named bolt. The ways to add Bolt Binding are as follows:\nXML To publish a Bolt service using XML, simply add the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag to the \u0026amp;lt;sofa:service\u0026amp;gt; tag:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation To publish a Bolt service using Annotation, you only need to set the bindingType of @SofaServiceBinding to bolt:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)}) Public class SampleServiceImpl implements SampleService { } API in Spring environment To publish a Bolt-protocol service in Spring or Spring Boot environment, just add BoltBindingParam to ServiceParam:\nServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(SampleService.class); // Set the service interface serviceParam.setInstance(new SampleServiceImpl()); // Set the implementation of the service interface List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); Params.add(serviceBindingParam); serviceParam.setBindingParams(params); API in non-Spring environment To provide the Bolt-protocol service using the bare API of SOFARPC in a non-Spring environment, just set the ServerConfig whose protocol is Bolt to the corresponding ProviderConfig:\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;); // Create a new ServerConfig with Bolt protocol ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRef(new SampleServiceImpl()) .setServer(serverConfig) // Set ServerConfig to ProviderConfig to indicate that the protocol published by this service is Bolt. .setRegistry(registryConfig); providerConfig.export(); Reference Service To reference a Bolt-protocol service using SOFARPC, just add a Binding named bolt. The ways to use Bolt Binding are as follows:\nXML To reference a Bolt-protocol service using XML, simply add the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag to the \u0026amp;lt;sofa:reference\u0026amp;gt; tag:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation To reference a Bolt-protocol service using Annotation, just set the bindingType of @SofaReferenceBinding to bolt:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) Private SampleService sampleService; API in Spring environment To reference a Bolt-protocol service in a Spring or Spring Boot environment, simply add a BoltBindingParam to ReferenceParam:\nReferenceClient …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-usage/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dd929c0a3cd2f4620ddf0d30d98ba85d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","summary":"Publish Service To use SOFARPC to publish a Bolt-protocol service, you only need to add a Binding named bolt. The ways to add Bolt Binding are as follows:\nXML To publish a Bolt service using XML, simply add the \u0026lt;sofa:binding.bolt\u0026gt; tag to the \u0026lt;sofa:service\u0026gt; tag:\n\u0026lt;sofa:service ref=\u0026quot;sampleService\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.sample.SampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt/\u0026gt; \u0026lt;/sofa:service\u0026gt; Annotation To publish a Bolt service using Annotation, you only need to set the bindingType of @SofaServiceBinding to bolt:","tags":null,"title":"Basic usage of Bolt protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","wordcount":364},{"author":null,"categories":null,"content":" In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the Dubbo protocol, just set Binding to Dubbo. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish a Dubbo service, just set the bindingType of @SofaServiceBinding to dubbo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a Dubbo service, just set the bindingType of @SofaReferenceBinding to dubbo:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; Set the Group of Dubbo Service In the SOFARPC program model, there is no field called Group, but there is a model of uniqueId, which can be directly mapped to the Group in Dubbo model. For example, the following code is to publish a service whose Group is groupDemo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}, uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;) public class SampleServiceImpl implements SampleService { } The following code is to reference a service whose Group is groupDemo:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;, jvmFirst = false) private SampleService sampleService; Note that Dubbo protocol currently only supports Zookeeper as service registry center.\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo-usage/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1bf72c194a20a5dccea70423690191f4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","summary":"In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the Dubbo protocol, just set Binding to Dubbo. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish a Dubbo service, just set the bindingType of @SofaServiceBinding to dubbo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026quot;dubbo\u0026quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a Dubbo service, just set the bindingType of @SofaReferenceBinding to dubbo:","tags":null,"title":"Basic usage of Dubbo protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","wordcount":203},{"author":null,"categories":null,"content":" In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the H2C protocol, just set Binding to H2C. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish an H2C service, just set the bindingType of @SofaServiceBinding to h2c:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a H2C service, just set the bindingType of @SofaReferenceBinding to h2c:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c-usage/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fa75eff1e99b3acad5087160a1b44a09","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","summary":"In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the H2C protocol, just set Binding to H2C. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish an H2C service, just set the bindingType of @SofaServiceBinding to h2c:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026quot;h2c\u0026quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a H2C service, just set the bindingType of @SofaReferenceBinding to h2c:","tags":null,"title":"Basic usage of H2C protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","wordcount":100},{"author":null,"categories":null,"content":" In SOFARPC (Not In SOFABoot/SpringBoot)，when use Http as a protocol of server，we can use Json as the way of serialization，for some basic test scenes.\nSOFARPC API Usage Service Publish ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026amp;quot;serverApp\u0026amp;quot;)) .setServer(serverConfig) .setUniqueId(\u0026amp;quot;uuu\u0026amp;quot;) .setRegister(false); providerConfig.export(); Service Consume Because of the Http+Json，So users can use HttpClient to start a normal call, this is a piece of code in test.\nprivate ObjectMapper mapper = new ObjectMapper(); HttpClient httpclient = HttpClientBuilder.create().build(); // POST normal request String url = \u0026amp;quot;http://127.0.0.1:12300/com.alipay.sofa.rpc.server.http.HttpService:uuu/object\u0026amp;quot;; HttpPost httpPost = new HttpPost(url); httpPost.setHeader(RemotingConstants.HEAD_SERIALIZE_TYPE, \u0026amp;quot;json\u0026amp;quot;); ExampleObj obj = new ExampleObj(); obj.setId(1); obj.setName(\u0026amp;quot;xxx\u0026amp;quot;); byte[] bytes = mapper.writeValueAsBytes(obj); ByteArrayEntity entity = new ByteArrayEntity(bytes, ContentType.create(\u0026amp;quot;application/json\u0026amp;quot;)); httpPost.setEntity(entity); HttpResponse httpResponse = httpclient.execute(httpPost); Assert.assertEquals(200, httpResponse.getStatusLine().getStatusCode()); byte[] data = EntityUtils.toByteArray(httpResponse.getEntity()); ExampleObj result = mapper.readValue(data, ExampleObj.class); Assert.assertEquals(\u0026amp;quot;xxxxx\u0026amp;quot;, result.getName()); You will get some result.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http-json/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"28abdf6369247346bad670c639a422b8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/http-json/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/http-json/","summary":"In SOFARPC (Not In SOFABoot/SpringBoot)，when use Http as a protocol of server，we can use Json as the way of serialization，for some basic test scenes.\nSOFARPC API Usage Service Publish ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); ProviderConfig\u0026lt;HttpService\u0026gt; providerConfig = new ProviderConfig\u0026lt;HttpService\u0026gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026quot;serverApp\u0026quot;)) .setServer(serverConfig) .setUniqueId(\u0026quot;uuu\u0026quot;) .setRegister(false); providerConfig.export(); Service Consume Because of the Http+Json，So users can use HttpClient to start a normal call, this is a piece of code in test.","tags":null,"title":"Basic usage of HTTP protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/http-json/","wordcount":140},{"author":null,"categories":null,"content":" In SOFARPC, using different communication protocols is equal to using different Bindings. If you need to use the RESTful protocol, just set Binding to REST.\nPublish Service When defining a RESTful service interface, you need to add meta information to the interface using the annotations in JAXRS standard, such as the following interface:\n@Path(\u0026amp;quot;sample\u0026amp;quot;) public interface SampleService { @GET @Path(\u0026amp;quot;hello\u0026amp;quot;) String hello(); } The annotations in JAXRS standard can be found in RESTEasy documentation.\n After the interface is defined, you can publish the implementation of the interface as a service, for example, by means of Annotation:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}) public class RestfulSampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } If you want to publish the service by other methods, please refer to Basic usage of Bolt protocol.\nAccess services through browser After the service is published, you can directly access the service through the browser. For the above service, the access address is as follows:\nhttp://localhost:8341/sample/hello The default port for SOFARPC RESTful service is 8341.\nReference Service In addition to accessing RESTful services published by SOFARPC through a browser, you can also reference services through the standard SOFARPC service reference methods, such as Annotation:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)) private SampleService sampleService; If you want to reference the service by other methods, please refer to Basic usage of Bolt protocol.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-basic/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d41f976864ba8f8221f5b5d26f354d1c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-basic/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-basic/","summary":"In SOFARPC, using different communication protocols is equal to using different Bindings. If you need to use the RESTful protocol, just set Binding to REST.\nPublish Service When defining a RESTful service interface, you need to add meta information to the interface using the annotations in JAXRS standard, such as the following interface:\n@Path(\u0026quot;sample\u0026quot;) public interface SampleService { @GET @Path(\u0026quot;hello\u0026quot;) String hello(); } The annotations in JAXRS standard can be found in RESTEasy documentation.","tags":null,"title":"Basic usage of RESTful protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-basic/","wordcount":228},{"author":null,"categories":null,"content":" Benchmark 源码解析任务还在进行中，敬请期待！\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-benchmark/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fdcbd9e5c563ad087756f0703f94db61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","summary":"Benchmark 源码解析任务还在进行中，敬请期待！","tags":null,"title":"Benchmark","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","wordcount":18},{"author":null,"categories":null,"content":" Test code\nTest environment and conditions Three 16-core 20 GB memory Docker containers as the server nodes (3 replicas) Two to eight 8-core Docker containers as clients 24 Raft groups. Each server node has eight leaders responsible for processing read/right requests. Followers do not have the permission to read. The target of stress testing is the RheaKV module of JRaft. Only the put and get APIs are subject to stress testing. Linearizable reads are guaranteed for the get API. The key size and value size are both 16 bytes. The read percentage is 10% and the write percentage is 90%. Currently, the test scenarios are relatively simple. We will add more test scenarios in the future.\nTest scenario 1 Scenario 1: Test conditions Number of clients Client batching Storage type Read/write ratio Replicator pipeline Key size Value size 8 Enabled MemoryDB 1:9 Enabled 16 bytes 16 bytes Scenario 1: Result summary Eight clients achieved 400,000+ ops, and the p95 RT is within 8 ms. Three server nodes didn\u0026amp;rsquo;t reach their maximum load. The load is about 15, and the CPU usage is about 40%. Scenario 1: Load of three servers Scenario 1: Server 1 top - 20:11:14 up 10 days, 23:09, 1 user, load average: 12.29, 6.92, 4.00 Tasks: 36 total, 1 running, 35 sleeping, 0 stopped, 0 zombie %Cpu0 : 24.3 us, 17.7 sy, 0.0 ni, 50.0 id, 2.0 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu1 : 21.9 us, 18.5 sy, 0.0 ni, 49.5 id, 2.0 wa, 0.0 hi, 0.0 si, 8.1 st %Cpu2 : 20.6 us, 18.6 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 5.6 st %Cpu3 : 23.3 us, 20.0 sy, 0.0 ni, 50.3 id, 1.3 wa, 0.0 hi, 0.0 si, 5.0 st %Cpu4 : 24.1 us, 19.1 sy, 0.0 ni, 49.8 id, 2.3 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu5 : 21.3 us, 18.9 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu6 : 24.7 us, 18.4 sy, 0.0 ni, 50.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu7 : 24.8 us, 17.8 sy, 0.0 ni, 50.0 id, 1.7 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu8 : 26.0 us, 18.3 sy, 0.0 ni, 51.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu9 : 26.6 us, 16.9 sy, 0.0 ni, 52.2 id, 2.0 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu10 : 31.7 us, 17.7 sy, 0.0 ni, 46.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu11 : 23.2 us, 18.9 sy, 0.0 ni, 53.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu12 : 25.6 us, 18.3 sy, 0.0 ni, 51.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu13 : 22.6 us, 18.3 sy, 0.0 ni, 54.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu14 : 24.7 us, 17.3 sy, 0.0 ni, 54.0 id, 1.7 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu15 : 61.8 us, 8.3 sy, 0.0 ni, 28.2 id, 0.3 wa, 0.0 hi, 0.0 si, 1.3 st KiB Mem : 62914560 total, 6854596 free, 39128016 used, 16931948 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 6854596 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15682 root 20 0 12.853g 8.859g 24064 S 708.7 14.8 26:49.38 java Scenario 1: Server 2 top - 20:11:47 up 10 days, 23:03, 1 user, load average: 17.68, 8.50, 4.56 Tasks: 33 total, 1 running, 31 sleeping, 0 stopped, 1 zombie %Cpu0 : 22.7 us, 17.3 sy, 0.0 ni, 35.0 id, 8.3 wa, 0.0 hi, 0.0 si, 16.7 st %Cpu1 : 20.1 us, 19.4 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/benchmark-performance/","fuzzywordcount":8900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4530827525ca87732eaf76ae34f03603","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","publishdate":"0001-01-01T00:00:00Z","readingtime":42,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","summary":"Test code\nTest environment and conditions Three 16-core 20 GB memory Docker containers as the server nodes (3 replicas) Two to eight 8-core Docker containers as clients 24 Raft groups. Each server node has eight leaders responsible for processing read/right requests. Followers do not have the permission to read. The target of stress testing is the RheaKV module of JRaft. Only the put and get APIs are subject to stress testing.","tags":null,"title":"Benchmark data","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","wordcount":8817},{"author":null,"categories":null,"content":" 测试代码\n测试环境\u0026amp;amp;条件 3 台 16C 20G 内存的 docker 容器作为 server node (3 副本) 2 ~ 8 台 8C docker 容器 作为 client 24 个 raft 复制组，平均每台 server node 上各自有 8 个 leader 负责读写请求，不开启 follower 读 压测目标为 JRaft 中的 RheaKV 模块，只压测 put、get 两个接口，其中 get 是保证线性一致读的，key 和 value 大小均为 16 字节 读比例 10%，写比例 90% 目前的测试场景比较简单，以后会增加更多测试场景\n测试场景1 场景1: 测试条件 Client 数量 Client-Batching Storage-Type 读写比例 Replicator-Pipeline key 大小 value 大小 8 开启 MemoryDB 1:9 开启 16 字节 16字节 场景1: 结果汇总： 8 个 client 一共达到 40w+ ops，p95 RT 在 8ms 以内 3 个 server 节点负载没达到极限 load 15 左右，cpu 40% 左右 场景1: 3 个 server 机器负载： 场景1: server1 top - 20:11:14 up 10 days, 23:09, 1 user, load average: 12.29, 6.92, 4.00 Tasks: 36 total, 1 running, 35 sleeping, 0 stopped, 0 zombie %Cpu0 : 24.3 us, 17.7 sy, 0.0 ni, 50.0 id, 2.0 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu1 : 21.9 us, 18.5 sy, 0.0 ni, 49.5 id, 2.0 wa, 0.0 hi, 0.0 si, 8.1 st %Cpu2 : 20.6 us, 18.6 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 5.6 st %Cpu3 : 23.3 us, 20.0 sy, 0.0 ni, 50.3 id, 1.3 wa, 0.0 hi, 0.0 si, 5.0 st %Cpu4 : 24.1 us, 19.1 sy, 0.0 ni, 49.8 id, 2.3 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu5 : 21.3 us, 18.9 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu6 : 24.7 us, 18.4 sy, 0.0 ni, 50.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu7 : 24.8 us, 17.8 sy, 0.0 ni, 50.0 id, 1.7 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu8 : 26.0 us, 18.3 sy, 0.0 ni, 51.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu9 : 26.6 us, 16.9 sy, 0.0 ni, 52.2 id, 2.0 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu10 : 31.7 us, 17.7 sy, 0.0 ni, 46.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu11 : 23.2 us, 18.9 sy, 0.0 ni, 53.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu12 : 25.6 us, 18.3 sy, 0.0 ni, 51.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu13 : 22.6 us, 18.3 sy, 0.0 ni, 54.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu14 : 24.7 us, 17.3 sy, 0.0 ni, 54.0 id, 1.7 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu15 : 61.8 us, 8.3 sy, 0.0 ni, 28.2 id, 0.3 wa, 0.0 hi, 0.0 si, 1.3 st KiB Mem : 62914560 total, 6854596 free, 39128016 used, 16931948 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 6854596 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15682 root 20 0 12.853g 8.859g 24064 S 708.7 14.8 26:49.38 java 场景1: server2 top - 20:11:47 up 10 days, 23:03, 1 user, load average: 17.68, 8.50, 4.56 Tasks: 33 total, 1 running, 31 sleeping, 0 stopped, 1 zombie %Cpu0 : 22.7 us, 17.3 sy, 0.0 ni, 35.0 id, 8.3 wa, 0.0 hi, 0.0 si, 16.7 st %Cpu1 : 20.1 us, 19.4 sy, 0.0 ni, 43.8 id, 9.4 wa, 0.0 hi, 0.0 si, 7.4 st %Cpu2 : 23.3 us, 20.0 sy, 0.0 ni, 39.7 id, 10.3 wa, 0.0 hi, 0.0 si, 6.7 st %Cpu3 : 24.1 us, 20.1 sy, 0.0 ni, 40.8 id, 9.4 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu4 : 21.4 us, 17.7 sy, 0.0 ni, 37.1 id, 9.0 wa, 0.0 hi, 0.0 si, 14.7 st %Cpu5 : 22.6 us, 19.6 sy, 0.0 ni, 40.5 id, 10.6 wa, 0.0 hi, 0.0 si, 6.6 st %Cpu6 : 23.6 us, 19.9 sy, 0.0 ni, 40.2 id, 10.3 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu7 : 20.5 us, 19.9 sy, 0.0 ni, 44.4 id, 9.9 wa, 0.0 hi, 0.0 si, 5.3 st %Cpu8 : 40.7 us, 13.3 sy, 0.0 ni, 34.3 id, 9.0 wa, 0.0 hi, 0.0 si, 2.7 st %Cpu9 : 39.9 us, 14.0 sy, 0.0 ni, 35.2 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/benchmark-performance/","fuzzywordcount":9300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4530827525ca87732eaf76ae34f03603","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/benchmark-performance/","publishdate":"0001-01-01T00:00:00Z","readingtime":19,"relpermalink":"/sofastack.tech/projects/sofa-jraft/benchmark-performance/","summary":"测试代码 测试环境\u0026amp;条件 3 台 16C 20G 内存的 docker 容器作为 server node (3 副本) 2 ~ 8 台 8C docker 容器 作为 client 24 个 raft 复制组，平均每台 server node 上各自有 8 个 leader 负责读写请求","tags":null,"title":"Benchmark 数据","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/benchmark-performance/","wordcount":9269},{"author":null,"categories":null,"content":"Bolt protocol is a TCP-based custom protocol that performs better than HTTP. Within Ant Financial, a large number of RPCs use the Bolt protocol to communicate: * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b812f6aadadf38b79140a711ff6aa6cd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt/","summary":"Bolt protocol is a TCP-based custom protocol that performs better than HTTP. Within Ant Financial, a large number of RPCs use the Bolt protocol to communicate: * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool","tags":null,"title":"Bolt protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt/","wordcount":45},{"author":null,"categories":null,"content":"Bolt 协议一个基于 TCP 的自定义的协议，相比 HTTP 来说，性能更好，在蚂蚁金服内部，大量的 RPC 都是采用 Bolt 协议来进行通信： * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化协议 * 自定义线程池\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b812f6aadadf38b79140a711ff6aa6cd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt/","summary":"Bolt 协议一个基于 TCP 的自定义的协议，相比 HTTP 来说，性能更好，在蚂蚁金服内部，大量的 RPC 都是采用 Bolt 协议来进行通信： * 基本使用 * 调用方式 * 超时控制 * 泛化","tags":null,"title":"Bolt 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt/","wordcount":85},{"author":null,"categories":null,"content":" Bolt 协议基本使用 发布服务 使用 SOFARPC 发布一个 Bolt 协议的服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下：\nXML 使用 XML 发布一个 Bolt 协议只需要在 \u0026amp;lt;sofa:service\u0026amp;gt; 标签下增加 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签即可：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation 使用 Annotation 发布一个 Bolt 协议的服务只需要设置 @SofaServiceBinding 的 bindingType 为 bolt 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Spring 环境下 API 方式 在 Spring 或者 Spring Boot 环境下发布一个 Bolt 协议的服务只需要往 ServiceParam 里面增加一个 BoltBindingParam 即可：\nServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(SampleService.class); // 设置服务接口 serviceParam.setInstance(new SampleServiceImpl()); // 设置服务接口的实现 List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); 非 Spring 环境下的 API 方式 在非 Spring 环境下使用 SOFARPC 的裸 API 提供 Bolt 协议的服务，只需要将 Protocol 为 Bolt 的 ServerConfig 设置给对应的 ProviderConfig：\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;); // 新建一个协议为 Bolt 的 ServerConfig ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRef(new SampleServiceImpl()) .setServer(serverConfig) // 将 ServerConfig 设置给 ProviderConfig，表示这个服务发布的协议为 Bolt。 .setRegistry(registryConfig); providerConfig.export(); 引用服务 使用 SOFARPC 引用一个 Bolt 服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下：\nXML 使用 XML 引用一个 Bolt 协议的服务只需要在 \u0026amp;lt;sofa:reference\u0026amp;gt; 标签下增加 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签即可：\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 使用 Annotation 引用一个 Bolt 协议的服务只需要设置 @SofaReferenceBinding 的 bindingType 为 bolt 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private SampleService sampleService; Spring 环境下 API 方式 在 Spring 或者 Spring Boot 环境下引用一个 Bolt 协议的服务只需要往 ReferenceParam 里面增加一个 BoltBindingParam 即可：\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;SampleService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;SampleService\u0026amp;gt;(); referenceParam.setInterfaceType(SampleService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); 非 Spring 环境下的 API 方式 在非 Spring 环境下使用 SOFARPC 的裸 API 引用一个 Bolt 协议的服务，只需要设置 ConsumerConfig 的 Protocol 为 bolt 即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-usage/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dd929c0a3cd2f4620ddf0d30d98ba85d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt-usage/","summary":"Bolt 协议基本使用 发布服务 使用 SOFARPC 发布一个 Bolt 协议的服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下： XML 使用 XML 发布一个 Bolt 协议只需要","tags":null,"title":"Bolt 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt-usage/","wordcount":570},{"author":null,"categories":null,"content":" 泛化调用提供了让客户端在不需要依赖服务端的接口情况下就能够发起调用的能力。目前 SOFARPC 的泛化调用仅支持在 Bolt 通信协议下使用 Hessian2 作为序列化协议，其他的方式并不支持。\nSOFABoot 环境 发布服务 发布服务没有什么特殊的,正常发布服务即可.比如\n\u0026amp;lt;!-- generic --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 引用服务 \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.api.GenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs generic-interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 其中,jvm-first根据实际情况,默认可以不写,接口写泛化调用的通用接口,generic-interface中写上自己要调用的接口名称即可.\n发起调用 GenericService sampleGenericServiceReference = (GenericService) applicationContext .getBean(\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot;); GenericObject genericResult = (GenericObject) sampleGenericServiceReference.$genericInvoke(\u0026amp;quot;sayGeneric\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericParamModel\u0026amp;quot; }, new Object[] { genericObject }); RPC API ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt;() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); 如上通过 setGeneric 设置该服务为泛化服务，设置服务方的接口名。以 GenericService 作为泛化服务，通过 GenericService 就能够发起泛化调用了。发起调用时，需要传入方法名，方法类型，方法参数。\n如果参数或者返回结果在客户端也需要泛化表示。可以通过 GenericObject 来实现。\nGenericObject genericObject = new GenericObject(\u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot;); genericObject.putField(\u0026amp;quot;str\u0026amp;quot;, \u0026amp;quot;xxxx\u0026amp;quot;); genericObject.putField(\u0026amp;quot;num\u0026amp;quot;, 222); GenericObject result = (GenericObject) testService.$genericInvoke(\u0026amp;quot;echoObj\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot; }, new Object[] { genericObject }); String str = result.getField(\u0026amp;quot;str\u0026amp;quot;); String num = result.getField(\u0026amp;quot;num\u0026amp;quot;); 如上就能获得序列化结果。完整的泛化调用方式使用说明如下：\n/** * Java Bean */ public class People { private String name; private int age; // getters and setters } /** * 服务方提供的接口 */ interface SampleService { String hello(String arg); People hello(People people); String[] hello(String[] args); } /** * 客户端 */ public class ConsumerClass { GenericService genericService; public void do() { // 1. $invoke仅支持方法参数类型在当前应用的 ClassLoader 中存在的情况 genericService.$invoke(\u0026amp;quot;hello\u0026amp;quot;, new String[]{ String.class.getName() }, new Object[]{\u0026amp;quot;I\u0026#39;m an arg\u0026amp;quot;}); // 2. $genericInvoke支持方法参数类型在当前应用的 ClassLoader 中不存在的情况。 // 2.1 构造参数 GenericObject genericObject = new …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/generic-invoke/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"84ac624dc99a42a8f89489aa10304ef7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/generic-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/generic-invoke/","summary":"泛化调用提供了让客户端在不需要依赖服务端的接口情况下就能够发起调用的能力。目前 SOFARPC 的泛化调用仅支持在 Bolt 通信协议下使用 Hessian2 作为序列化协议，其他的方","tags":null,"title":"Bolt 协议泛化调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/generic-invoke/","wordcount":710},{"author":null,"categories":null,"content":" 调用方式 SOFARPC 在 Bolt 协议下提供了多种调用方式满足不同的场景。\n同步 在同步的调用方式下，客户端发起调用后会等待服务端返回结果再进行后续的操作。这是 SOFARPC 的默认调用方式，无需进行任何设置即可。\n异步 异步调用的方式下，客户端发起调用后不会等到服务端的结果，继续执行后面的业务逻辑。服务端返回的结果会被 SOFARPC 缓存，当客户端需要结果的时候，再主动调用 API 获取。如果需要将一个服务设置为异步的调用方式，在对应的使用方式下设置 type 属性即可：\nXML 方式 在 XML 方式下，设置 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 type 属性为 future 即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 在 Annotation 方式下，设置 @SofaReferenceBinding 的 invokeType 属性为 future 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, invokeType = \u0026amp;quot;future\u0026amp;quot;)) private SampleService sampleService; Spring 环境下 API 方式 在 Spring 环境下使用 API，设置 BoltBindingParam 的 type 属性即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setType(\u0026amp;quot;future\u0026amp;quot;); 在非 Spring 环境下 API 方式 在非 Spring 环境下使用 SOFARPC 裸 API，设置 ConsumerConfig 的 invokeType 属性即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setInvokeType(\u0026amp;quot;future\u0026amp;quot;); 获取调用结果 使用异步调用的方式，目前提供了两种方式来获取异步调用的结果：\n直接获取结果 用户可以通过以下的方式来直接获取异步调用的结果：\nString result = (String)SofaResponseFuture.getResponse(0, true); 其中第一个参数是获取结果的超时时间，第二个参数表示是否清除线程上下文中的结果。\n获取 JDK 原生 Future 用户可以通过以下的方式来获取 JDK 的原生的 Future 对象，再可以从任意地方去调用这个 Future 对象来获取结果：\nFuture future = SofaResponseFuture.getFuture(true); 其中的第一个参数表示是否清除线程上下文中的结果。\n回调 SOFARPC Bolt 协议的回调方式可以让 SOFARPC 在发起调用后不等待结果，在客户端收到服务端返回的结果后，自动回调用户实现的一个回调接口。\n使用 SOFARPC Bolt 协议的回调方式，首先需要实现一个回调接口，并且在对应的配置中设置回调接口，再将调用方式设置为 callback。\n实现回调接口 SOFARPC 提供了一个回调的接口 com.alipay.sofa.rpc.core.invoke.SofaResponseCallback，用户使用 SOFARPC Bolt 协议的回调方式，首先需要实现这个接口，该接口提供了三个方法：\n onAppResponse：当客户端接收到服务端的正常返回的时候，SOFARPC 会回调这个方法。 onAppException：当客户端接收到服务端的异常响应的时候，SOFARPC 会回调这个方法。 onSofaException：当 SOFARPC 本身出现一些错误，比如路由错误的时候，SOFARPC 会回调这个方法。 设置回调接口 实现回调接口之后，用户需要将实现类设置到对应的服务引用配置中，并且将调用方式设置为 callback。\nSOFARPC 为设置回调接口提供了两种方式，分别为 Callback Class 和 Callback Ref。Callback Class 的方式直接设置回调的类名，SOFARPC 会通过调用回调类的默认构造函数的方式生成回调类的实例。Callback Ref 的方式则为用户直接提供回调类的实例。\nXML 方式 如果通过 XML 的方式引用服务，将 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 type 属性设置为 callback，并且设置 callback-ref 或者 callback-class 属性即可：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleCallback\u0026amp;quot; class=\u0026amp;quot;com.example.demo.SampleCallback\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;callback\u0026amp;quot; callback-ref=\u0026amp;quot;sampleCallback\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 在 XML 的方式下，callback-ref 的值需要是回调类的 Bean 名称。\nAnnotation 方式 如果通过 Annotation 的方式引用服务，设置 @SofaReferenceBinding 注解的 invokeType 属性为 callback，并且设置 callbackClass 或者 callbackRef 属性即可：\n@SofaReference(binding = …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-type/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e296d9344b6aa9f550e6213b97da084b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/invoke-type/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/invoke-type/","summary":"调用方式 SOFARPC 在 Bolt 协议下提供了多种调用方式满足不同的场景。 同步 在同步的调用方式下，客户端发起调用后会等待服务端返回结果再进行后续的操作。这是 SOFARPC 的","tags":null,"title":"Bolt 协议调用方式","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/invoke-type/","wordcount":1619},{"author":null,"categories":null,"content":" 超时控制 使用 Bolt 协议进行通信的时候，SOFARPC 的超时时间默认为 3 秒，用户可以在引用服务的时候去设置超时时间，又分别可以在服务以及方法的维度设置超时时间，SOFARPC 的超时时间的设置的单位都为毫秒。\n服务维度 如果需要在发布服务的时候在服务维度设置超时时间，设置对应的 timeout 参数到对应的值即可。\nXML 方式 如果使用 XML 的方式引用服务，设置 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签下的 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 timeout 属性的值即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 如果使用 Annotation 引用服务，设置 @SofaReferenceBinding 的 timeout 属性的值即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, timeout = 2000)) private SampleService sampleService; Spring 环境 API 方式 如果在 Spring 或者 Spring Boot 的环境下引用服务，设置 BoltBindingParam 的 timeout 属性的值即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setTimeout(2000) 非 Spring 环境下 API 方式 如果在非 Spring 环境下直接使用 SOFARPC 的裸 API 引用服务，设置 ConsumerConfig 的 timeout 属性即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setTimeout(2000); 方法维度 如果想要单独调整一个服务中某一个方法的超时时间，可以通过在方法维度上设置超时时间来实现。\n对于某一个方法来说，优先方法维度的超时时间，如果没有设置，则使用服务维度的超时时间。\nXML 方式 如果使用 XML 的方式引用一个服务，设置对应的 \u0026amp;lt;sofa:method\u0026amp;gt; 标签的 timeout 属性即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 目前暂未提供通过 Annotation 的方式来设置方法级别的超时时间。\nSpring 环境 API 方式 如果在 Spring 或者 Spring Boot 的环境下引用服务，设置 RpcBindingMethodInfo 的 timeout 属性的值即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); RpcBindingMethodInfo rpcBindingMethodInfo = new RpcBindingMethodInfo(); rpcBindingMethodInfo.setName(\u0026amp;quot;hello\u0026amp;quot;); rpcBindingMethodInfo.setTimeout(2000); List\u0026amp;lt;RpcBindingMethodInfo\u0026amp;gt; rpcBindingMethodInfos = new ArrayList\u0026amp;lt;\u0026amp;gt;(); rpcBindingMethodInfos.add(rpcBindingMethodInfo); boltBindingParam.setMethodInfos(rpcBindingMethodInfos); 非 Spring 环境 API 方式 如果在非 Spring 环境下使用 SOFARPC 的裸 API 引用服务，设置 MethodConfig 的 timeout 属性即可：\nMethodConfig methodConfig = new MethodConfig(); methodConfig.setName(\u0026amp;quot;hello\u0026amp;quot;); methodConfig.setTimeout(2000); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfig); ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setMethods(methodConfigs); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-timeout/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cf14f73dc0c4672a9255ef55b56de419","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt-timeout/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt-timeout/","summary":"超时控制 使用 Bolt 协议进行通信的时候，SOFARPC 的超时时间默认为 3 秒，用户可以在引用服务的时候去设置超时时间，又分别可以在服务以及方法的维度","tags":null,"title":"Bolt 协议超时控制","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt-timeout/","wordcount":584},{"author":null,"categories":null,"content":" As one of the developing directions of cloud native technology, Serverless architecture enables you to further improve resource utilization and focus on service development. With our workshop, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, and quick troubleshooting via log viewer.\nWorkshop procedure Flow diagram Preview Preparation Access to Serverless application service address Login with account and password Git clone this project to local Step 1-1: Publish backend Java application Select Create quickly Select Java Runtime Upload the code package balance-mng.jar The entry method can be automatically recognized Port: 8080 Copy and save the backend service address after creation View the number of computing instances of backend service: 0 Step 1-2: Publish frontend NodeJS application Select create an application Select the buildpack NodeJS Upload the code package stock-mng.zip The entry method can be automatically recognized Select nodejs-0.0.1.1-pre at runtime Port: 3000 Set the environment variable BALANCEMNG_URL as the backend service address Step 2: 0-1 cold boot capability Access frontend service View the changes in the number of the computing instances of backend service Step 3: Log and monitoring View application service logs via Log Shell View usage amount via monitoring Step 4: Configure time trigger Configure timing trigger to call application at fixed time View the triggering results via operation records Step 5: Create versions and control traffic Clone the frontend application and create a new version Upload the code package stock-mng-v2.zip Configure router to visit V1 and V2 at 1:1 ratio View the effect in the browser Step 6: Quick M-n capability for high-concurrency Simulate high concurrency situtation via scripts and access the frontend application service Check how the Serverless application perform quick M-N computing instance changes ","date":-62135596800,"description":"With this guide, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, quick troubleshooting via log viewer, and application startup at fixed time.","dir":"guides/kc-serverless-demo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f355d1b598fed47b730bd74ad25f3683","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-serverless-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/guides/kc-serverless-demo/","summary":"As one of the developing directions of cloud native technology, Serverless architecture enables you to further improve resource utilization and focus on service development. With our workshop, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, and quick troubleshooting via log viewer.\nWorkshop procedure Flow diagram Preview Preparation Access to Serverless application service address Login with account and password Git clone this project to local Step 1-1: Publish backend Java application Select Create quickly Select Java Runtime Upload the code package balance-mng.","tags":null,"title":"Build applications on the cloud based on Serverless","type":"guides","url":"/sofastack.tech/en/guides/kc-serverless-demo/","wordcount":290},{"author":null,"categories":null,"content":" Procedure This guide introduces how to quickly build a microservice based on SOFAStack. It mainly includes the following steps.\n Publish service using SOFABoot and SOFARPC Call service using SOFABoot and SOFARPC View Tracer information reported by SOFATracer via ZipKin View Metrics information via SOFALookout Architecture Tasks 1. Preparation Clone the project demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git Import the project into IDEA or Eclipse. After import, the interface is as follows:\n balance-mng: account management system, providing deduction balance service stock-mng: account system, providing deduction inventory service 2. Introduce dependencies Add the following dependencies into the pom.xml files of balance-mng and stock-mng project modules.\n\u0026amp;lt;!--SOFARPC dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFATracer dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFARegistry dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--runtime dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFALookout dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; For balance-mng project, you need to introduce the dependencies into the pom file of balance-mng-imp module.\nFor stock-mng project, you need to introduce the dependencies into the pom file of stock-mng module.\n3. Add configurations Copy the following configurations into the application.properties file of balance-mng and stock-mng project module.\n# 1、Add Service Registry address com.alipay.sofa.rpc.registry.address=sofa://118.31.43.62:9603 # 2、Add the zipkin address where tracer data is reported com.alipay.sofa.tracer.zipkin.base-url=http://139.224.123.199:9411 # 3、Add the server-side address where the metrics data is reported com.alipay.sofa.lookout.agent-host-address=139.224.123.35 For balance-mng project, you need to add configurations to the application.properties file in balance-mng-bootstrap module.\nFor stock-mng project, you need to add configurations to the application.properties file in stock-mng module.\n4. Modify unique id Since everyone shares a set of service discoveries, to differentiate the services published by different users, it is required to add a unique id to the service.\nKubeCon workshop will prepare a SOFAStack account for each user in the format ofuser0@sofastack.io to user99@sofastack.io. The first half of the account, namely …","date":-62135596800,"description":"This guide introduces how to quickly build a microservice based on SOFAStack. ","dir":"guides/sofastack-quick-start/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"78bfd4806a86dc15ac86eee16fb85c82","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/sofastack-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/guides/sofastack-quick-start/","summary":"Procedure This guide introduces how to quickly build a microservice based on SOFAStack. It mainly includes the following steps.\n Publish service using SOFABoot and SOFARPC Call service using SOFABoot and SOFARPC View Tracer information reported by SOFATracer via ZipKin View Metrics information via SOFALookout Architecture Tasks 1. Preparation Clone the project demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git Import the project into IDEA or Eclipse. After import, the interface is as follows:","tags":null,"title":"Build microservices with SOFAStack","type":"guides","url":"/sofastack.tech/en/guides/sofastack-quick-start/","wordcount":586},{"author":null,"categories":null,"content":" SOFARPC provides a variety of calling types under the Bolt protocol to meet different scenarios.\nSynchronous In the synchronous calling type, after the client initiates a call, it will wait for the server to return the result and then perform subsequent operations. This is the default calling type of SOFARPC.\nAsynchronous In the asynchronous calling type, after the client initiates a call, it will not wait for the result from the server but continue to execute the subsequent business logic. The result returned by the server will be cached by SOFARPC. When the client needs the result, it can call the API to get the result. To set a service to be asynchronous, you can configure the type attribute in the corresponding usage mode:\nXML In the XML mode, set the type attribute of the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag to future:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation In Annotation mode, set the invokeType attribute of @SofaReferenceBinding to future:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, invokeType = \u0026amp;quot;future\u0026amp;quot;)) private SampleService sampleService; API in Spring environment When using the API in Spring environment, you just need to set the type attribute of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setType(\u0026amp;quot;future\u0026amp;quot;); API in non-Spring environment When using the bare API of SOFARPC in a non-Spring environment, you just need to set the invokeType attribute of ConsumerConfig:\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setInvokeType(\u0026amp;quot;future\u0026amp;quot;); Get the calling result Currently, there are two ways to get the result of an asynchronous call:\nGet result directly You can directly get the result of an asynchronous call in the following way:\nString result = (String)SofaResponseFuture.getResponse(0, true); The first parameter is the timeout period for getting the result, and the second parameter indicates whether to clear the result in the thread context.\nGet JDK native Future You can get the JDK native Future object in the following way, and then call the Future object from anywhere to get the result:\nFuture future = SofaResponseFuture.getFuture(true); The first parameter indicates whether to clear the result in the thread context.\nCallback By using the callback type of the SOFARPC Bolt protocol, SOFARPC doesn\u0026amp;rsquo;t need to wait for the result after initiating a call. After the client receives the result returned from the server, it can automatically call back a callback interface implemented by the user.\nTo use the callback type of the SOFARPC Bolt protocol, you first need to …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-type/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e296d9344b6aa9f550e6213b97da084b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/invoke-type/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/invoke-type/","summary":"SOFARPC provides a variety of calling types under the Bolt protocol to meet different scenarios.\nSynchronous In the synchronous calling type, after the client initiates a call, it will wait for the server to return the result and then perform subsequent operations. This is the default calling type of SOFARPC.\nAsynchronous In the asynchronous calling type, after the client initiates a call, it will not wait for the result from the server but continue to execute the subsequent business logic.","tags":null,"title":"Calling type","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/invoke-type/","wordcount":908},{"author":null,"categories":null,"content":" Client built-in extension metrics The extension modules currently in effect by default are lookout-ext-jvm and lookout-ext-os (from v1.5.0).\nJVM thread metric name metric tags specification jvm.threads.totalStarted \u0026amp;mdash; jvm.threads.active \u0026amp;mdash; jvm.threads.peak \u0026amp;mdash; jvm.threads.daemon \u0026amp;mdash; JVM class loading metric name metric tags specification jvm.classes.unloaded \u0026amp;mdash; jvm.classes.loaded \u0026amp;mdash; jvm.classes.total \u0026amp;mdash; JVM memory metric name metric tags specification jvm.memory.heap.init \u0026amp;mdash; jvm.memory.heap.used \u0026amp;mdash; jvm.memory.heap.max \u0026amp;mdash; jvm.memory.heap.committed \u0026amp;mdash; JVM garbage recycling metric name metric tags specification jvm.gc.young.time \u0026amp;mdash; jvm.gc.young.count \u0026amp;mdash; jvm.gc.old.time \u0026amp;mdash; jvm.gc.old.count \u0026amp;mdash; Machine file system information metric name metric tags specification instance.file.system.free.space root（the available filesystem roots） \u0026amp;mdash; instance.file.system.total.space root \u0026amp;mdash; instance.file.system.usabe.space root \u0026amp;mdash; Machine information metric name metric tags specification instance.mem.free \u0026amp;mdash; instance.mem.total \u0026amp;mdash; instance.processors \u0026amp;mdash; instance.uptime \u0026amp;mdash; instance.systemload.average \u0026amp;mdash; Linux operating system information (enabled by default after version 1.5.0) metric name metric tags specification os.systemload.average.1min \u0026amp;mdash; os.systemload.average.5min \u0026amp;mdash; os.systemload.average.15min \u0026amp;mdash; os.cpu.idle \u0026amp;mdash; os.cpu.iowait \u0026amp;mdash; os.cpu.irq \u0026amp;mdash; os.cpu.nice \u0026amp;mdash; os.cpu.softirq \u0026amp;mdash; os.cpu.system \u0026amp;mdash; os.cpu.user \u0026amp;mdash; os.disk.usage.percent.used device,root,type \u0026amp;mdash; os.disk.usage.total.bytes device,root,type \u0026amp;mdash; os.disk.usage.used.bytes device,root,type \u0026amp;mdash; os.net.stats.in.bytes intfc \u0026amp;mdash; os.net.stats.in.compressed intfc \u0026amp;mdash; os.net.stats.in.dropped intfc \u0026amp;mdash; os.net.stats.in.errs intfc \u0026amp;mdash; os.net.stats.in.fifo.errs intfc \u0026amp;mdash; os.net.stats.in.frame.errs intfc \u0026amp;mdash; os.net.stats.in.multicast intfc \u0026amp;mdash; os.net.stats.in.packets intfc \u0026amp;mdash; os.net.stats.out.bytes intfc \u0026amp;mdash; os.net.stats.out.carrier.errs intfc \u0026amp;mdash; os.net.stats.out.collisions intfc \u0026amp;mdash; os.net.stats.out.compressed intfc \u0026amp;mdash; os.net.stats.out.dropped intfc \u0026amp;mdash; os.net.stats.out.errs intfc \u0026amp;mdash; os.net.stats.out.fifo.errs intfc \u0026amp;mdash; os.net.stats.out.packets intfc \u0026amp;mdash; os.memory.stats.buffers.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.cached.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.free.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.total.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-ext-metrics/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c8a4fb3d904e359e99db9d4e81e60812","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","summary":"Client built-in extension metrics The extension modules currently in effect by default are lookout-ext-jvm and lookout-ext-os (from v1.5.0).\nJVM thread metric name metric tags specification jvm.threads.totalStarted \u0026mdash; jvm.threads.active \u0026mdash; jvm.threads.peak \u0026mdash; jvm.threads.daemon \u0026mdash; JVM class loading metric name metric tags specification jvm.classes.unloaded \u0026mdash; jvm.","tags":null,"title":"Client built-in extension metrics","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","wordcount":224},{"author":null,"categories":null,"content":"The client module is a complex module which contains cluster, router, address holder，connection holder, and load balancer, and interacts with proxy, registry center and other modules.\nSee the following flow chart:\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/client-invoke-flow/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"310d99d64b808a3b526563e92c699952","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","summary":"The client module is a complex module which contains cluster, router, address holder，connection holder, and load balancer, and interacts with proxy, registry center and other modules.\nSee the following flow chart:","tags":null,"title":"Client call flow","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","wordcount":31},{"author":null,"categories":null,"content":" Client configuration example lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026amp;quot;127.0.0.1\u0026amp;quot;); Description of server configuration item Configuration item Corresponding SpringBoot configuration item Default value Description lookout.enable com.alipay.sofa.lookout.enable true Function switch, it defaults to true. If you change it to false (empty objects and empty methods), then all metrics comsume almost no memory and computing resource lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 Maximum number limit of metrics, over which will be automatically ignored lookout.prometheus.exporter.server.port com.alipay.sofa.lookout.prometheus-exporter-server-port 9494 The port got by Prometheus Lookout.exporter.enable com.alipay.sofa.lookout.exporter-enable false Whether or not to enable services that support passive collection Lookout.agent.host.address com.alipay.sofa.lookout.agent-host-address - Proactively report the annotation address of the Agent server. Multiple addresses are separated by commas Description of client log configuration Configuration item of system property Corresponding SpringBoot configuration item Default Value Description -Dlogging.level.com.alipay.lookout=? logging.level.com.alipay.lookout warn The log level of Lookout client. Debug to see the details of the report data -Dlogging.path=? logging.path Directory of the current user Modify SpringBoot V1 log directory, including \u0026amp;ldquo;lookout/\u0026amp;rdquo; log subdirectory Custom client configuration (suitable for SpringBoot technology stack mode) Use configuration custom extensions: MetricConfigCustomizerConfig\n@Configuration public class MetricConfigCustomizerConfig { @Bean public MetricConfigCustomizer metricConfigCustomizer() { return new MetricConfigCustomizer() { @Override public void customize(MetricConfig metricConfig) { metricConfig.addProperty(\u0026amp;quot;testaa\u0026amp;quot;, \u0026amp;quot;testbb\u0026amp;quot;); } }; } } ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-configuration/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5fd84950d4d565d3fb20781337792bf1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/client-configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/client-configuration/","summary":"Client configuration example lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026quot;127.0.0.1\u0026quot;); Description of server configuration item Configuration item Corresponding SpringBoot configuration item Default value Description lookout.enable com.alipay.sofa.lookout.enable true Function switch, it defaults to true. If you change it to false (empty objects and empty methods), then all metrics comsume almost no memory and computing resource lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 Maximum number limit of metrics, over which will be automatically ignored lookout.","tags":null,"title":"Client configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/client-configuration/","wordcount":192},{"author":null,"categories":null,"content":" 1. Create a Maven project After deploying the servers, we can create a new Maven project to use services provided by SOFARegistry. Create a new Maven project, and then import the following dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. Publish data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create a publisher registry. String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // Register the registry with the client and publish data. registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); Perform the following steps to publish data by using SOFARegistry:\n Create a client instance. Create a publisher registry. Register the registry with the client and publish data. 2.1 Create a client instance The key to creating a client instance is to create a RegistryClientConfig object. When creating a RegistryClientConfig object, you need to specify the RegistryEndpoint and RegistryEndpointPort.\n RegistryEndpoint: the endpoint of any session node of SOFARegistry RegistryEndpointPort: the session.server.httpServerPort port number configured for a session node 2.2 Create a publisher registry To create a publisher registry, you only need to create a PublisherRegistration object and specify the dataId, which is the unique identifier of the publisher service.\n2.3 Publish data You can call the register method of the RegistryClient to publish data. This method requires two parameters: the first is a publisher registry with the specified dataId of a service, and the second is a string type data value.\n3. Subscribe to the data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create SubscriberDataObserver. SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // Create a subscriber registry and specify the subscription level. ScopeEnum covers three subscription levels: zone, dataCenter, and global. String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setScopeEnum(ScopeEnum.global); // Register the registry with …","date":-62135596800,"description":"","dir":"projects/sofa-registry/client-quick-start/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"66e300d44b2f2a903d976bf83eb7c16e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/client-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/client-quick-start/","summary":"1. Create a Maven project After deploying the servers, we can create a new Maven project to use services provided by SOFARegistry. Create a new Maven project, and then import the following dependency:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. Publish data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create a publisher registry. String dataId = \u0026quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // Register the registry with the client and publish data.","tags":null,"title":"Client usage","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/client-quick-start/","wordcount":558},{"author":null,"categories":null,"content":" Project address\n Introduction During merged deployment, Biz packages can communicate with each other by releasing and referencing JVM services apart from using the RPC framework. This sample project is intended to demonstrate how two Biz packages communicate by JVM services.\nWithin the biz-jvm-invocation-sample project, there are three sub-projects whose functions are as follows: + facade: A common Java module that defines the SampleJvmService interface.\npackage me.qlong.tech.service; public interface SampleJvmService { String service(); } app-one: A SOFABoot Web application that defines a simple rest request and use the @SofaReference annotation to reference the SampleJvmService. When a page request is triggered, an attempt is made to call the JVM service. The key code is: package me.qlong.controller; import com.alipay.sofa.runtime.api.annotation.SofaReference; import me.qlong.tech.service.SampleJvmService; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class HelloController { @SofaReference private SampleJvmService sampleJvmService; @RequestMapping(\u0026amp;quot;/hello\u0026amp;quot;) public String hello() { return sampleJvmService.service(); } } app-two: A non-web application in SOFABoot that uses the @SofaService annotation to publish the SampleJvmService. ```java package me.qlong.tech.service.impl; import com.alipay.sofa.runtime.api.annotation.SofaService; import me.qlong.tech.service.SampleJvmService; import org.springframework.stereotype.Component;\n@SofaService @Component public class AppTwoSampleService implements SampleJvmService{ public String service() { return \u0026amp;ldquo;App Two\u0026amp;rdquo;; } }\n ## Dependency To communicate between Biz packages through JVM services, you must add dependencies on the SOFARuntime package and the corresponding Ark Plugin as follows: ```xml \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; For detailed information about publishing and referencing JVM services, see the SOFABoot Documentation. You are advised to use annotations in Jarslink2.0.\nDemo cd biz-jvm-invocation-sample/facade \u0026amp;amp;\u0026amp;amp; mvn clean install Execute the mvn clean install command in the facade root directory, and install the facade package in the local Maven repository so that you can add a facade dependency in app-one and app-two: \u0026amp;lt;!--service facade--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;me.qlong.tech\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;facade\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; cd biz-jvm-invocation-sample/app-one \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-one root directory and …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"59778c5223dc6267bd537be6c79b658a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","summary":"Project address\n Introduction During merged deployment, Biz packages can communicate with each other by releasing and referencing JVM services apart from using the RPC framework. This sample project is intended to demonstrate how two Biz packages communicate by JVM services.\nWithin the biz-jvm-invocation-sample project, there are three sub-projects whose functions are as follows: + facade: A common Java module that defines the SampleJvmService interface.\npackage me.qlong.tech.service; public interface SampleJvmService { String service(); } app-one: A SOFABoot Web application that defines a simple rest request and use the @SofaReference annotation to reference the SampleJvmService.","tags":null,"title":"Communicate across applications","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","wordcount":527},{"author":null,"categories":null,"content":"SOFARPC supports different communication protocols and currently supports Bolt, RESTful and Dubbo. For details, please refer to the corresponding document of each protocol: * Bolt Protocol * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool * RESTful * Basic usage * Custom filter * Integrate Swagger * Dubbo * Basic usage * H2C * Basic usage\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/protocol/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"18f51cb12f7a0384a71ab22349292a08","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/protocol/","summary":"SOFARPC supports different communication protocols and currently supports Bolt, RESTful and Dubbo. For details, please refer to the corresponding document of each protocol: * Bolt Protocol * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool * RESTful * Basic usage * Custom filter * Integrate Swagger * Dubbo * Basic usage * H2C * Basic usage","tags":null,"title":"Communication protocols","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/protocol/","wordcount":66},{"author":null,"categories":null,"content":" How to compile Install JDK7 and above, and Maven 3.2.5 and above.\n Directly download the code and then execute the following command:\ncd sofa-jarslink mvn clean install Note: you cannot compile the code under a sub-directory (i.e., sub-module). Since there are many modules, the configuration is restricted to the root directory only to avoid repetitive configuration of some packaging plugins such as the formatting plugin and License plugin. There will be an error message if you execute the packaging command in a sub-module.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-compile/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"23c8cae6050d7a772f45d3ff2b4ce889","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","summary":"How to compile Install JDK7 and above, and Maven 3.2.5 and above.\n Directly download the code and then execute the following command:\ncd sofa-jarslink mvn clean install Note: you cannot compile the code under a sub-directory (i.e., sub-module). Since there are many modules, the configuration is restricted to the root directory only to avoid repetitive configuration of some packaging plugins such as the formatting plugin and License plugin.","tags":null,"title":"Compile Jarslink project","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","wordcount":83},{"author":null,"categories":null,"content":" Install JDK7 or later and Maven 3.2.5 or later.\n Download the codes directly and execute the following commands:\ncd sofa-rpc mvn clean install Note: You can not build under a subdirectory (namely the submodule). Because there are too many SOFARPC modules, if every submodule needs to be installed and deployed, there will be much useless records in the repository. This issue is considered in the process of designing the SOFARPC project structure. The current structure saves you the trouble of installing and deploying all submodules, and you just have to install and deploy one module, namely the sofa-rpc-all (all) module.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/how-to-build/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"52ad3debb35be8743c97bb4b6b77f22b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/how-to-build/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/how-to-build/","summary":"Install JDK7 or later and Maven 3.2.5 or later.\n Download the codes directly and execute the following commands:\ncd sofa-rpc mvn clean install Note: You can not build under a subdirectory (namely the submodule). Because there are too many SOFARPC modules, if every submodule needs to be installed and deployed, there will be much useless records in the repository. This issue is considered in the process of designing the SOFARPC project structure.","tags":null,"title":"Compile SOFARPC project","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/how-to-build/","wordcount":100},{"author":null,"categories":null,"content":"Provide all the parameters that can be configured. * Service publishing and reference configuration * Warm-up forwarding configuration * Fault tolerance configuration\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b1a8a8c426beab292165716f1dff1ae4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration/","summary":"Provide all the parameters that can be configured. * Service publishing and reference configuration * Warm-up forwarding configuration * Fault tolerance configuration","tags":null,"title":"Configuration parameters","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration/","wordcount":22},{"author":null,"categories":null,"content":"To use Consul as service registry center, you need to add this dependency\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.ecwid.consul\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;consul-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; and need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 The value after consul: is the connection address of the consul. If you need to set some other parameters, you can also configure as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;amp;b=2 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-consul/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e6b0aa843ea0ad401c3184f6ce87649b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-consul/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-consul/","summary":"To use Consul as service registry center, you need to add this dependency\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.ecwid.consul\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;consul-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.4.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; and need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 The value after consul: is the connection address of the consul. If you need to set some other parameters, you can also configure as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;b=2 ","tags":null,"title":"Consul","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-consul/","wordcount":54},{"author":null,"categories":null,"content":" You can visit Development Route first to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n Refer to the Git official books for the Git tool usage. The first few chapters will help you get a quick start. Read Git collaboration process through GitHub Code Contribution Process Submitting an issue Whether you want to fix a bug of SOFAArk or add a new feature of SOFAArk, you have to submit an issue to describe your demand before you submit the code on GitHub address in SOFAArk. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The maintenance personnel of SOFAArk will discuss about the bug or new function you submitted, to determine if the modification is necessary, or if there is any room for improvement or any better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Getting the source code To modify or add a function, click the fork button in the upper left corner to copy a SOFAArk trunk code to your code repository, after submitting an issue.\nPulling a branch Perform all the SOFAArk modifications on the branch, and submit a pull request after the modifications, which will be merged to the trunk by the project maintenance personnel after Code Review.\nTherefore, after getting the introduction to source code steps, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/{your account}/sofa-ark.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\ngit branch -a If you want to switch back to the trunk, execute the following command:\ngit checkout -b master If you want to switch back to the branch, execute the following command:\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally. After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFAArk uses the Maven plug-in to keep the code style consistent. Before submitting the code, execute the following commands locally: mvn clean compile Supplement unit test code. New modifications should have passed existing unit tests. You should provide the new unit test to prove that the previous code has bugs and the new code has fixed such bugs. Execute the following command to run all tests:\nmvn clean test Other do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original style of the code you are editing, especially the spaces and line feeds in the code. Delete useless annotations. Annotate the places where the logic and functionality …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-contribution/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dbf77f98884a71c5c7a3fbb4dd189cfe","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","summary":"You can visit Development Route first to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n Refer to the Git official books for the Git tool usage. The first few chapters will help you get a quick start. Read Git collaboration process through GitHub Code Contribution Process Submitting an issue Whether you want to fix a bug of SOFAArk or add a new feature of SOFAArk, you have to submit an issue to describe your demand before you submit the code on GitHub address in SOFAArk.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","wordcount":795},{"author":null,"categories":null,"content":" You can go into the development route to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n For the use of git tools, refer to official books on git and get familiarized by reading the first few chapters. For the git collaboration process, refer to the article named Git Collaboration Process. GitHub Code Contribution Process Submitting an issue No Matter whether you are fixing a Jarslink bug or adding a Jarslink feature, submit an issue on the Jarslink GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The Jarslink maintenance personnel will discuss the bug or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Getting the source code To modify or add a feature, click the fork button in the upper left corner to copy Jarslink trunk code to your code repository, after submitting an issue.\nPulling a branch Perform all the Jarslink modifications on the branch, and submit a pull request after the modifications, which will be merged into the trunk by the project maintenance personnel after the code review.\nTherefore, after getting the introduction to source code steps, you need to:\n Download the code locally. You may select the git/https mode in this step.\ngit clone https://github.com/your account name/sofa-jarslink.git Pull a branch to prepare for code modification.\ngit branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\n git branch -a If you want to switch back to the trunk, execute the following command:\n git checkout -b master If you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally. After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. Jarslink uses the Maven plugin to keep the code style consistent. Before submitting the code, be sure to execute the following commands locally\nmvn clean compile Supplement unit test code. New modifications should have passed existing unit tests. You should provide the new unit test to prove that the previous code has bugs and the new code has fixed such bugs. Execute the following command to run all tests:\n mvn clean test You can also use the IDE to help execute a command.\nOther do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-contribution/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d4c1185c6a691679f6dc9dba033550ce","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","summary":"You can go into the development route to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n For the use of git tools, refer to official books on git and get familiarized by reading the first few chapters. For the git collaboration process, refer to the article named Git Collaboration Process.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","wordcount":827},{"author":null,"categories":null,"content":" Before you read this document, you are suggested to read the SOFARPC development roadmap to learn about development tasks and future plans.\n Preparations Before you contribute code, you need to learn the basic use of Git tool and GitHub website.\n For how to use the Git tool, see Git official documenation and pay attention to the first few chapters. For Git collaboration process, see Git collaboration process. GitHub code contribution process Submit an issue No matter to fix SOFARPC bugs or add SOFARPC features, before submitting the codes, you must submit an issue on SOFARPC\u0026amp;rsquo;s GitHub to describe the bugs to be fixed and the functions you want to add.\nThere are several benefits of doing this:\n Avoid the conflict with other developers or their plans for this project, thus eliminating repetitive work. SOFARPC operations staff discuss your bugs or new features to determine if the changes are necessary and whether there is space for improvement or a better approach. Reduce communication cost between you and the SOFARPC operations staff, thus reducing the cases that pull request is rejected. Get source codes To modify or add features, after you submit the issue, you can click Fork in the upper left corner to copy the SOFARPC trunk code to your code repository.\nPull branches All SOFARPC modifications are made on the branch. After modification, submit the pull request. After the code review, the project operations staff merge the branches to the trunk.\nTherefore, you must complete the following steps after getting the source codes:\n Download the codes locally through Git or HTTPs.\n git clone https://github.com/your account name/sofa-rpc.git Pull branches for code modifications.\n \t git branch add_xxx_feature \nAfter executing the above command, your code repository switches to the corresponding branch. Execute the following command to see your current branch:\n\t git branch -a \nIf you want to switch back to the trunk, execute the following command:\n git checkout -b master \nIf you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; \nModify and submit codes locally Once the branch is pulled, you can modify the code.\nAttentions for modifying codes Keep a consistent code style.\nSOFARPC keeps the code format consistent through the Maven plugin. You must execute the following command locally before committing the code: mvn clean compile Supplemental unit test code. New modifications should have passed the existing unit tests. Provide new unit tests to prove that the previous code has bugs, and the new code has fixed these bugs.\nYou can run all tests with the following command:\nmvn clean test You can also use IDE to assist the test running.\n Other attentions Keep the original code style, especially the spacing and alignment. Delete the useless comments directly. Add comments for the logics and functions that cannot be easily understood. Update documentation timely. After modification, …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/contributing/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"448a7b9a949bd2d9e2e71ac6c237f9df","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/contributing/","summary":"Before you read this document, you are suggested to read the SOFARPC development roadmap to learn about development tasks and future plans.\n Preparations Before you contribute code, you need to learn the basic use of Git tool and GitHub website.\n For how to use the Git tool, see Git official documenation and pay attention to the first few chapters. For Git collaboration process, see Git collaboration process.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/contributing/","wordcount":751},{"author":null,"categories":null,"content":"SOFARPC uses some third-party open-source components which include but not limited to:\n Major dependencies\n Netty under Apache License 2.0 SLF4j under MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 Extended dependencies\n protobuf under New BSD License Snappy under New BSD License dubbo under Apache License 2.0 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b6c87388d5c1462f13d92012639a08b2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/notice/","summary":"SOFARPC uses some third-party open-source components which include but not limited to:\n Major dependencies\n Netty under Apache License 2.0 SLF4j under MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 Extended dependencies\n protobuf under New BSD License Snappy under New BSD License dubbo under Apache License 2.0 ","tags":null,"title":"Copyright","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/notice/","wordcount":62},{"author":null,"categories":null,"content":" Copyright statement of dependent components SOFADashboard uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFABolt under Apache License 2.0 SOFABolt under Apache License 2.0 Curator under Apache License 2.0 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a9ebe38d245302f94ab7bfa793329926","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/notice/","summary":" Copyright statement of dependent components SOFADashboard uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFABolt under Apache License 2.0 SOFABolt under Apache License 2.0 Curator under Apache License 2.0 ","tags":null,"title":"Copyright statement","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/notice/","wordcount":47},{"author":null,"categories":null,"content":" Copyright statement of dependent components SOFARegistry uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1\n SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 If you find anything we have missed, please let us know.\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c40263ffd56a2f1292756c9fafea55e2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/notice/","summary":"Copyright statement of dependent components SOFARegistry uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1\n SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 If you find anything we have missed, please let us know.","tags":null,"title":"Copyright statement","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/notice/","wordcount":68},{"author":null,"categories":null,"content":" 本文档主要介绍一个基于 jraft 的分布式计数器的例子。\n场景 在多个节点（机器）组成的一个 raft group 中保存一个分布式计数器，该计数器可以递增和获取，并且在所有节点之间保持一致，任何少数节点的挂掉都不会影响对外提供的两个服务：\n incrmentAndGet(delta) 递增 delta 数值并返回递增后的值。 get() 获取最新的值 RPC 请求 jraft 底层使用 bolt 作为通讯框架，定义两个请求\n IncrementAndGetRequest，用于递增 public class IncrementAndGetRequest implements Serializable { private static final long serialVersionUID = -5623664785560971849L; private long delta; public long getDelta() { return this.delta; } public void setDelta(long delta) { this.delta = delta; } } GetValueRequest，用于获取最新值： public class GetValueRequest implements Serializable { private static final long serialVersionUID = 9218253805003988802L; public GetValueRequest() { super(); } } 应答结果 ValueResponse，包括：\n success　是否成功 value 成功情况下返回的最新值 errorMsg 失败情况下的错误信息 redirect　发生了重新选举，需要跳转的新的leader节点。 public class ValueResponse implements Serializable { private static final long serialVersionUID = -4220017686727146773L; private long value; private boolean success; /** * redirect peer id */ private String redirect; private String errorMsg; public String getErrorMsg() { return this.errorMsg; } public void setErrorMsg(String errorMsg) { this.errorMsg = errorMsg; } ...... } IncrementAndGetRequest 用于 Leader 服务端接收 IncrementAndAddClosure 请求后的回调处理： public class IncrementAndAddClosure implements Closure { private CounterServer counterServer; private IncrementAndGetRequest request; private ValueResponse response; private Closure done; // 网络应答callback public IncrementAndAddClosure(CounterServer counterServer, IncrementAndGetRequest request, ValueResponse response, Closure done) { super(); this.counterServer = counterServer; this.request = request; this.response = response; this.done = done; } @Override public void run(Status status) { // 返回应答给客户端 if (this.done != null) { done.run(status); } } public IncrementAndGetRequest getRequest() { return this.request; } public void setRequest(IncrementAndGetRequest request) { this.request = request; } public ValueResponse getResponse() { return this.response; } } 服务端 状态机 CounterStateMachine 首先持有一个初始值：\npublic class CounterStateMachine extends StateMachineAdapter { /** * counter value */ private AtomicLong value = new AtomicLong(0); 实现核心的 onApply(iterator) 方法，应用用户提交的请求到状态机：\n@Override public void onApply(Iterator iter) { // 遍历日志 while (iter.hasNext()) { long delta = 0; IncrementAndAddClosure closure = null; // done 回调不为null，必须在应用日志后调用，如果不为 null，说明当前是leader。 if (iter.done() != null) { // 当前是leader，可以直接从 IncrementAndAddClosure 中获取 delta，避免反序列化 closure = (IncrementAndAddClosure) iter.done(); delta = closure.getRequest().getDelta(); } else { // 其他节点应用此日志，需要反序列化 IncrementAndGetRequest，获取 delta ByteBuffer data = iter.getData(); try { IncrementAndGetRequest request = Codecs.getSerializer(Codecs.Hessian2).decode(data.array(), IncrementAndGetRequest.class.getName()); delta = request.getDelta(); } catch (CodecException e) { LOG.error(\u0026amp;quot;Fail to decode IncrementAndGetRequest\u0026amp;quot;, e); } } long prev = this.value.get(); // 更新状态机 long …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/counter-example/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f9c54b9f7883ccb1d7c259b7101f4674","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/counter-example/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-jraft/counter-example/","summary":"本文档主要介绍一个基于 jraft 的分布式计数器的例子。 场景 在多个节点（机器）组成的一个 raft group 中保存一个分布式计数器，该计数器可以递增和获取，并且在所有","tags":null,"title":"Counter 例子详解","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/counter-example/","wordcount":2404},{"author":null,"categories":null,"content":" Project address\n Introduction Jarslink 2.0 is available for both Spring Boot and SOFABoot; we just need to add the specified dependencies. To be convenient, it is recommended to use Jarslink 2.0 in the form of SOFABoot projects. This sample project is intended to demonstrate how to quickly reform a Spring Boot project into a SOFABoot project.\nReform After creating a Spring Boot project in the official Spring Boot website, we only need to introduce the SOFABoot dependencies. First, modify the configuration file pom.xml of the Maven project.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace as\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.5.0-SNAPSHOT\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Note: Currently Jarslink 2.0.0 is still at its snapshot version, and the SOFABoot 2.5.0 that it depends on will be released in the near future, so for the moment, the SOFABoot 2.5.0-SNAPSHOT version has to be introduced as the dependency. The pull of the SNAPSHOT package requires special configuration, for which you can refer to FAQ: How do I configure for pulling a SNAPSHOT dependency package?\nThen, add a Spring Boot or SOFABoot official Starter, such as:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;!-- Jarslink2.0 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-jarslink-ark-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0-SNAPSHOT\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- Web --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; To package the application into an Ark package or Biz package, we need to configure the sofa-Ark-maven-plugin packaging plugin in the main pom.xml file, and delete the native packaging plugin the Spring Boot configuration.\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Finally, add a parameter that SOFABoot must use under the application.properties file for the project, including spring.application.name (used to mark the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"46cb9153d039f01a375a569c2a9a5535","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","summary":"Project address\n Introduction Jarslink 2.0 is available for both Spring Boot and SOFABoot; we just need to add the specified dependencies. To be convenient, it is recommended to use Jarslink 2.0 in the form of SOFABoot projects. This sample project is intended to demonstrate how to quickly reform a Spring Boot project into a SOFABoot project.\nReform After creating a Spring Boot project in the official Spring Boot website, we only need to introduce the SOFABoot dependencies.","tags":null,"title":"Create a SOFABoot application","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","wordcount":419},{"author":null,"categories":null,"content":" SOFARPC provides a good extensibility mechanism, which provide SPI capabilities for each module. SOFARPC uses multiple filters to intercept requests and responses. These filters can be customized and extended by users. The execution order of custom filters is after the built-in filters. The procedure is as follows:\nBolt filter 1 Create a new custom filter.\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 2 The custom filter will be added into the interceptor chain. There are three specific ways to do this step.\n Method 1: In API. In this way, the custom filter can take effect in the specified provider or consumer. // Service provider providerConfig.setFilterRef(Arrays.asList(new CustomFilter())); // Service caller consumerConfig.setFilterRef(Arrays.asList(new CustomFilter())); Method 2: Add @Extension annotation + configuration extension file to the class. @Extension(\u0026amp;quot;customer\u0026amp;quot;) public class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } Create a new extension file META-INF/services/sofa-rpc/com.alipay.sofa.rpc.filter.Filter with the following content:\ncustomer=com.alipay.sofa.rpc.custom.CustomFilter Code injection.\n// Service provider providerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); // Service caller consumerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); Method 3: Add @Extension annotation + @AutoActive annotation + configuration extension file to the class. In this way, the code injection step in method 2 is replaced with the @AutoActive annotation. The custom filter can take effect in all providers or consumers. The providerSide parameter indicates whether it takes effect on the server, and the consumerSide parameter indicates whether it takes effect on the client. @Extension(\u0026amp;quot;customer\u0026amp;quot;) @AutoActive(providerSide = true, consumerSide = true) public class customerFilter extends Filter { // ... } ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-filter/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"30ff5937b52a7c2dd8028e878979a33d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-filter/","summary":"SOFARPC provides a good extensibility mechanism, which provide SPI capabilities for each module. SOFARPC uses multiple filters to intercept requests and responses. These filters can be customized and extended by users. The execution order of custom filters is after the built-in filters. The procedure is as follows:\nBolt filter 1 Create a new custom filter.\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.","tags":null,"title":"Custom filter","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-filter/","wordcount":285},{"author":null,"categories":null,"content":"The route service address in SOFARPC is abstracted into a processing chain, and is processed by each router. Like filter, SOFARPC provides the same extensibility for router.\n@Extension(value = \u0026amp;quot;customerRouter\u0026amp;quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026amp;lt;ProviderInfo\u0026amp;gt; route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) { return providerInfos; } Create a extension file META-INF/services/sofa-rpc/com.alipay.sofa.rpc.client.Router with the following content:\ncustomerRouter=com.alipay.sofa.rpc.custom.CustomRouter This file customized a CustomerRouter, which takes effect in all consumers. The parameter ConsumerBootstrap in init method is a wrapper class of the referenced service, and can get objects such as ConsumerConfig, proxy class, and service address pool. needToLoad indicates whether the Router is valid, and the route method is the method for filtering addresses.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-router/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"236e8d4bda3e856267a3575853aa900c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-router/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-router/","summary":"The route service address in SOFARPC is abstracted into a processing chain, and is processed by each router. Like filter, SOFARPC provides the same extensibility for router.\n@Extension(value = \u0026quot;customerRouter\u0026quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026lt;ProviderInfo\u0026gt; route(SofaRequest request, List\u0026lt;ProviderInfo\u0026gt; providerInfos) { return providerInfos; } Create a extension file META-INF/services/sofa-rpc/com.","tags":null,"title":"Custom router","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-router/","wordcount":131},{"author":null,"categories":null,"content":" SOFARPC supports custom business thread pools. A separate business thread pool can be set up for the specified service, isolated from SOFARPC\u0026amp;rsquo;s global business thread pool. Multiple services can share a single thread pool.\nSOFARPC requires that the type of custom thread pool must be com.alipay.sofa.rpc.server.UserThreadPool.\nUse XML If you publish the service using XML, you can first set the bean of the thread pool whose class is com.alipay.sofa.rpc.server.UserThreadPool, and then set the bean in the thread-pool-ref attribute of \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag.\n\u0026amp;lt;bean id=\u0026amp;quot;helloService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Customize a thread pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;customExecutor\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.server.UserThreadPool\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;corePoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;maximumPoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;queueSize\u0026amp;quot; value=\u0026amp;quot;0\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloService\u0026amp;quot; interface=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;!-- Set the thread pool to a Service --\u0026amp;gt; \u0026amp;lt;sofa:global-attrs thread-pool-ref=\u0026amp;quot;customExecutor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Use Annotation If you publish the service using Annotation, you can set the bean of the custom thread pool by setting the userThreadPool attribute of @SofaServiceBinding:\n@SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, userThreadPool = \u0026amp;quot;customThreadPool\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Use API in Spring environment If you publish a service using the API in Spring environment, you can configure a custom thread pool by calling the setUserThreadPool method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setUserThreadPool(new UserThreadPool()); Use API in non-Spring environment If you publish service using the API in non-Spring environment, you can set a custom thread pool as follows:\nUserThreadPool threadPool = new UserThreadPool(); threadPool.setCorePoolSize(10); threadPool.setMaximumPoolSize(100); threadPool.setKeepAliveTime(200); threadPool.setPrestartAllCoreThreads(false); threadPool.setAllowCoreThreadTimeOut(false); threadPool.setQueueSize(200); UserThreadPoolManager.registerUserThread(ConfigUniqueNameGenerator.getUniqueName(providerConfig), threadPool); As above, a custom thread pool is set up for the HelloService service.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-thread-pool/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4d582a7894b2381248522f3a1fc400c9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","summary":"SOFARPC supports custom business thread pools. A separate business thread pool can be set up for the specified service, isolated from SOFARPC\u0026rsquo;s global business thread pool. Multiple services can share a single thread pool.\nSOFARPC requires that the type of custom thread pool must be com.alipay.sofa.rpc.server.UserThreadPool.\nUse XML If you publish the service using XML, you can first set the bean of the thread pool whose class is com.alipay.sofa.rpc.server.UserThreadPool, and then set the bean in the thread-pool-ref attribute of \u0026lt;sofa:global-attrs\u0026gt; tag.","tags":null,"title":"Custom thread pool","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","wordcount":252},{"author":null,"categories":null,"content":" You can view basic information of your application on SOFADashboard, including the IP address, ports, and health check status. This feature is dependent on the SOFADashboard client. If you want to display the information about an application on the SOFADashboard control page, import the sofa-dashboard-client dependency.\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-dashboard-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; Function display ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/dashboard-client/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"60586c6dfee1f2afcdac88cbe7a36b83","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","summary":" You can view basic information of your application on SOFADashboard, including the IP address, ports, and health check status. This feature is dependent on the SOFADashboard client. If you want to display the information about an application on the SOFADashboard control page, import the sofa-dashboard-client dependency.\n\u0026lt;denpendency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofa-dashboard-client\u0026lt;/artifactId\u0026gt; \u0026lt;/denpendency\u0026gt; Function display ","tags":null,"title":"Dashboard client","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","wordcount":52},{"author":null,"categories":null,"content":" In this document will demonstrate how to use SOFATracer to track of Datasource.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce SOFATracer Introduce SOFATracer dependency in the new Spring Boot project:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.2.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce h2database dependencies For convenience, we use the h2database memory database for test. So, we need to introduce the following dependencies:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.h2database\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;h2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;runtime\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;mysql\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mysql-connector-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce the required connection pool dependencies Introduce the required connection pool dependency packages, such as druid, c3p0, tomcat, dbcp, Hikari, and so on.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;druid\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;c3p0\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;c3p0\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.9.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.tomcat\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tomcat-jdbc\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;8.5.31\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-dbcp\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-dbcp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.zaxxer\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;HikariCP-java6\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.8\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configure data source Taking HikariCP as the example, we create a new Spring configuration file named datasource.xml, which defines the followings:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- dataSource pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;simpleDataSource\u0026amp;quot; class=\u0026amp;quot;com.zaxxer.hikari.HikariDataSource\u0026amp;quot; destroy-method=\u0026amp;quot;close\u0026amp;quot; primary=\u0026amp;quot;true\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;driverClassName\u0026amp;quot; value=\u0026amp;quot;org.h2.Driver\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;jdbcUrl\u0026amp;quot; value=\u0026amp;quot;jdbc:h2:~/test\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;username\u0026amp;quot; value=\u0026amp;quot;sofa\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;password\u0026amp;quot; value=\u0026amp;quot;123456\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; Application configuration Required configuration It should be noted that it is …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-datasource/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d9d8f6756a294104647067eaa7827f61","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","summary":"In this document will demonstrate how to use SOFATracer to track of Datasource.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce SOFATracer Introduce SOFATracer dependency in the new Spring Boot project:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.2.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Introduce h2database dependencies For convenience, we use the h2database memory database for test. So, we need to introduce the following dependencies:","tags":null,"title":"DataSource Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","wordcount":642},{"author":null,"categories":null,"content":" Datasource Log Format SOFATracer tracks the standard JDBC data source and outputs the chain data of SQL statement execution, in the default JSON format.\nDataSource digest log (datasource-client-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Database.name Database name Sql SQL execution statement Result.code SQL execution status code Total.time SQL statement execution total time Connection.establish.span SQL execution connection establishment time Db.execute.cost SQL execution time Database.type Database type Database.endpoint Database url Current.thread.name Current thread name Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-28 01:11:56.715\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e1bcab91538068316462100111113\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1.2\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;success\u0026amp;quot;,\u0026amp;quot;total.time\u0026amp;quot;:\u0026amp;quot;228ms\u0026amp;quot;,\u0026amp;quot;connection.establish.span\u0026amp;quot;:\u0026amp;quot;220ms\u0026amp;quot;,\u0026amp;quot;db.execute.cost\u0026amp;quot;:\u0026amp;quot;3ms\u0026amp;quot;,\u0026amp;quot;database.type\u0026amp;quot;:\u0026amp;quot;h2\u0026amp;quot;,\u0026amp;quot;database.endpoint\u0026amp;quot;:\u0026amp;quot;jdbc:h2:~/test:-1\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} DataSource statistical Log (datasource-client-stat.log) stat.key is the set of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, database.name, and SQL field.\n Key Meaning time Log printing time stat.key local.app Current application name database.name Database name sql SQL execution statement count SQL execution count in this period total.cost.milliseconds Total duration (ms) for SQL execution in this period success Request result: Y for success; N for failure load.test Pressure mark: T for pressure test; F for non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-28 01:12:43.647\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;, \u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:228,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-datasource/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"647de768aff8ececc8276d247c5afee1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","summary":"Datasource Log Format SOFATracer tracks the standard JDBC data source and outputs the chain data of SQL statement execution, in the default JSON format.\nDataSource digest log (datasource-client-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Database.","tags":null,"title":"DataSource log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","wordcount":202},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 DataSource 进行埋点。\n SOFATracer 2.2.0 基于标准的 JDBC 接口实现，支持对标准的数据库连接池（如 DBCP、Druid、c3p0、tomcat、HikariCP、BoneCP）埋点。下面演示如何接入 SOFATracer 埋点能力。\n 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 引入 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入 h2database 依赖 为了方便，我们使用 h2database 内存数据库测试，引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.h2database\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;h2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;runtime\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;mysql\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mysql-connector-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入所需的连接池依赖 用户引入所需的连接池依赖包，如 druid, c3p0, tomcat, dbcp, Hikari 等。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;druid\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;c3p0\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;c3p0\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.9.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.tomcat\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tomcat-jdbc\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;8.5.31\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-dbcp\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-dbcp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.zaxxer\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;HikariCP-java6\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.8\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置数据源 我们以 HikariCP 为例，新建一个名为datasource.xml Spring 配置文件，定义如下内容:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- dataSource pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;simpleDataSource\u0026amp;quot; class=\u0026amp;quot;com.zaxxer.hikari.HikariDataSource\u0026amp;quot; destroy-method=\u0026amp;quot;close\u0026amp;quot; primary=\u0026amp;quot;true\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;driverClassName\u0026amp;quot; value=\u0026amp;quot;org.h2.Driver\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;jdbcUrl\u0026amp;quot; value=\u0026amp;quot;jdbc:h2:~/test\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;username\u0026amp;quot; value=\u0026amp;quot;sofa\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;password\u0026amp;quot; value=\u0026amp;quot;123456\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 应用配置 必要配置 需要注意一点，引入 SOFATracer 需要强制配置应用名，否则应用启动失败。这一属性和 SOFABoot 框架要求一致，配置如下：\nspring.application.name=SOFATracerDataSource 非必要配置 为了该演示工程正常运行，需要配置 h2database 属性；另为了方便查看日志，配置日志路径。如下：\n# logging path logging.path=./logs # h2 web consloe 路径 spring.h2.console.path=/h2-console # 开启 h2 web consloe，默认为 false spring.h2.console.enabled=true #允许远程访问 h2 web consloe spring.h2.console.settings.web-allow-others=true spring.datasource.username=sofa …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-datasource/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d9d8f6756a294104647067eaa7827f61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","summary":"在本文档将演示如何使用 SOFATracer 对 DataSource 进行埋点。 SOFATracer 2.2.0 基于标准的 JDBC 接口实现，支持对标准的数据库连接池（如 DBCP、Druid、c3p0、tomcat、H","tags":null,"title":"DataSource 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","wordcount":1014},{"author":null,"categories":null,"content":" SOFATracer 对标准的 JDBC 数据源进行埋点，输出 SQL 语句执行链路数据，默认日志输出为 JSON 数据格式。\nDataSource 摘要日志（datasource-client-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 database.name 数据库名称 sql sql执行语句 connection.establish.span sql执行建连时间 db.execute.cost sql执行时间 database.type 数据库类型 database.endpoint 数据库url sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 21:31:31.566\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe91d156743109138810017302\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;15ms\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;DROP TABLE IF EXISTS TEST; CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;,\u0026amp;quot;connection.establish.span\u0026amp;quot;:\u0026amp;quot;128ms\u0026amp;quot;,\u0026amp;quot;db.execute.cost\u0026amp;quot;:\u0026amp;quot;15ms\u0026amp;quot;,\u0026amp;quot;database.type\u0026amp;quot;:\u0026amp;quot;h2\u0026amp;quot;,\u0026amp;quot;database.endpoint\u0026amp;quot;:\u0026amp;quot;jdbc:h2:~/test:-1\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} DataSource 统计日志（datasource-client-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、database.name、和 sql 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 database.name 数据库名称 sql sql执行语句 count 本段时间内sql执行次数 total.cost.milliseconds 本段时间内sql执行总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 21:31:50.435\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;DROP TABLE IF EXISTS TEST; CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:15,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-datasource/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"647de768aff8ececc8276d247c5afee1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-datasource/","summary":"SOFATracer 对标准的 JDBC 数据源进行埋点，输出 SQL 语句执行链路数据，默认日志输出为 JSON 数据格式。 DataSource 摘要日志（datasource-client-digest.","tags":null,"title":"DataSource 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-datasource/","wordcount":427},{"author":null,"categories":null,"content":" SOFABoot is based on Spring Boot. It means SOFABoot manages SOFA middleware dependencies and provides the Starter for Spring Boot, facilitating the use of SOFA middleware in Spring Boot.\nSOFABoot dependency management You must load SOFABoot\u0026amp;rsquo;s management dependencies before using SOFA middleware. In a way similar to use Spring Boot, add the configuration tag \u0026amp;lt;parent/\u0026amp;gt; in the project settings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Where ${sofa.boot.version} represents the SOFABoot version (refer to release history).\nUse Middleware of SOFAStack For SOFABoot, use -sofa-boot-starter suffixes to name middleware components. If you want to use middleware, simply add its dependencies; To use SOFARPC, for example, simply add the following Maven dependencies:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note that there is no version declaration in the above Maven dependencies as the version has already been declared in sofabook-dependencies. This allows for unified upgrade of all SOFA middleware versions, allaying concerns over dependency conflicts or incompatibility brought by upgrade of a single middleware version. The SOFABoot middleware under control is listed as follows:\n Middleware starter SOFARPC rpc-sofa-boot-starter SOFATracer tracer-sofa-boot-starter SOFALookout lookout-sofa-boot-starter Introducing SOFABoot Extension Based on Spring Boot, SOFABoot provides extended capabilities such as health check, module isolation, and class isolation. In accordance with Spring Boot\u0026amp;rsquo;s the dependency-as-a-service principle, the extension capability will be ready immediately after relevant dependencies are added. Currently, there are several extension modules available:\n Extension components starter Health check healthcheck-sofa-boot-starter Module isolation Isle-Sofa-boot-starter Class isolation sofa-Ark-springboot-starter Test extension test-Sofa-boot-starter Introducing the SOFA middleware: the Ark plug-in SOFABoot provides a class isolation component—SOFAArk, which enables users to package third-party packages with dependency conflicts into an Ark plug-in. At run time, the Ark plug-in is loaded with a separate classloader; it is isolated from other Ark plug-ins and business dependencies to address class conflicts. SOFABoot provides SOFARPC and SOFATracer\u0026amp;rsquo;s Ark plug-ins; the Ark plug-in SOFARPC, for example, is loaded into the application to replace SOFARPC starter, to isolate the application from SOFARPC and its indirect dependencies. The controlled Ark plug-ins are listed as follows:\n Ark plug-in plugin SOFARPC rpc-sofa-boot-plugin SOFATracer tracer-sofa-boot-plugin Introducing SOFABoot namespace Before using SOFA middleware, we need to add …","date":-62135596800,"description":"","dir":"projects/sofa-boot/dependency-management/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dabdbd425f20dee4d7ab580d43574456","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/dependency-management/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/dependency-management/","summary":"SOFABoot is based on Spring Boot. It means SOFABoot manages SOFA middleware dependencies and provides the Starter for Spring Boot, facilitating the use of SOFA middleware in Spring Boot.\nSOFABoot dependency management You must load SOFABoot\u0026rsquo;s management dependencies before using SOFA middleware. In a way similar to use Spring Boot, add the configuration tag \u0026lt;parent/\u0026gt; in the project settings:\n\u0026lt;parent\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofaboot-dependencies\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${sofa.boot.version}\u0026lt;/version\u0026gt; \u0026lt;/parent\u0026gt; Where ${sofa.boot.version} represents the SOFABoot version (refer to release history).","tags":null,"title":"Dependency management","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/dependency-management/","wordcount":391},{"author":null,"categories":null,"content":" 1. Environment preparation To use SOFARegistry, you need to prepare the basic environment first. SOFARegistry depends on the following environment:\n Linux, UNIX, Mac are supported. JDK8 Compile it with Apache Maven 3.2.5 or later versions. 2. Resource Quota -cpu: 4c -memory: 8G -disk: 50G\n3. Two deployment modes Integrated deployment Package and integrate the three roles of meta, data, and session into one jvm, which can be deployed on a standalone machine or a cluster. The deployment is simple. Independent deployment Deploy the meta, data, and session roles separately. You can deploy each of them on a standalone machine or a cluster. You can deploy different numbers of servers for each role as needed. We recommend that you use this deployment mode in the production environment. 4. Configuration parameters The deployment of SOFARegistry depends on some public parameters\n properties environment Default value Function nodes.localDataCenter x DefaultDataCenter Cluster name, multiple registry centers use the same database nodes.localRegion x DEFAULT_ZONE Logical region, create multiple groups of sessions jdbc.url JDBC_URL Required Database address jdbc.username JDBC_USERNAME required database user name jdbc.password JDBC_PASSWORD Required Database password Properties can be written in registry-all/conf/application.properties, deployment under kubernetes can also use configmap for file mounting\n5. Packaging jar release page Download the latest registry-all.tgz package\ntar -zxvf registry-all.tgz cd registry-all Or package from source\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all image image hosted at https://hub.docker.com/r/sofaregistry/sofaregistry\nOr build from source code: Modify the image repository in Makefile\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true make image_build make image_push 6. Integrated deployment mode The integrated deployment mode is to package and integrate the three roles of meta/data/session into a JVM to run. It can be deployed on a single machine or in a cluster. It is not recommended for large-scale use\n6.1 jar stand-alone deployment For the stand-alone deployment mode of integrated deployment, you can directly refer to the Quick Start-Server Deployment section.\n6.2 jar cluster deployment Unzip registry-all.tgz and modify the configuration file Cluster deployment, that is, to build a cluster of 2 or more, it is recommended to use at least 3 (note: currently does not support the deployment of multiple SOFARegistry on the same machine, so you must have 3 different machines). The deployment method on each machine is the same as above:\ncp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar …","date":-62135596800,"description":"","dir":"projects/sofa-registry/deployment/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7e28583bc38be66af8d704d7fbcd9dd4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/deployment/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/deployment/","summary":"1. Environment preparation To use SOFARegistry, you need to prepare the basic environment first. SOFARegistry depends on the following environment:\n Linux, UNIX, Mac are supported. JDK8 Compile it with Apache Maven 3.2.5 or later versions. 2. Resource Quota -cpu: 4c -memory: 8G -disk: 50G\n3. Two deployment modes Integrated deployment Package and integrate the three roles of meta, data, and session into one jvm, which can be deployed on a standalone machine or a cluster.","tags":null,"title":"Deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/deployment/","wordcount":1040},{"author":null,"categories":null,"content":" 1. How to compile Install JDK7 or later versions, and Maven 3.2.5 or later versions. Directly download the code, and execute the following command in the code directory:\n mvn clean install 2. Version release Version number ACTS uses a three-digit version number in the form of major, minor, and patch, for example, 1.0.1.\nFor more information, see https://semver.org/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Patch number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application is. Version maintenance At most two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 1.3.0, the BugFix branch of version 1.2.x will be maintained, but bugs in branch 1.1.x will no longer be fixed. Therefore, a version upgrade for 1.1.x is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 1.3.0-SNAPSHOT. Upon formal release, SNAPSHOT is replaced with a formal version number, for example 1.3.0. After the formal release, the next version is pulled, for example, 1.3.1-SNAPSHOT. 3. Testing Unit test Add the unit test case to the model that you have developed. The package name of the test class is identical to that of the tested class.\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/developer-guide/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fcacc7e89b979f3aec8dc3333a7a3c37","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/developer-guide/","summary":"1. How to compile Install JDK7 or later versions, and Maven 3.2.5 or later versions. Directly download the code, and execute the following command in the code directory:\n mvn clean install 2. Version release Version number ACTS uses a three-digit version number in the form of major, minor, and patch, for example, 1.0.1.\nFor more information, see https://semver.org/.\n Major version number: All versions within a major version number must be compatible with each other.","tags":null,"title":"Developer guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/developer-guide/","wordcount":249},{"author":null,"categories":null,"content":" Develope guide of code contribution First refer to the basic Notes for code contribution Note the test case coverage; Note the code format; Verify samples Import the sample Maven project separately; Modify the dependency version in the corresponding Pom file; Verify that samples can work correctly as well. ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/development-use-guide/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"423a54ec3f5fbfc9c0e150eb853738ae","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","summary":" Develope guide of code contribution First refer to the basic Notes for code contribution Note the test case coverage; Note the code format; Verify samples Import the sample Maven project separately; Modify the dependency version in the corresponding Pom file; Verify that samples can work correctly as well. ","tags":null,"title":"Development guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","wordcount":48},{"author":null,"categories":null,"content":"SOFARPC supports scenarios where a specified address is called.\nThe use of direct call in Java API is as follows, only set the direct connection address:\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); The use of direct call in XML is as follows:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sample.HelloService\u0026amp;quot; id=\u0026amp;quot;helloService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; The use of direct call in Annotation is as follows:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, directUrl = \u0026amp;quot;127.0.0.1:12220\u0026amp;quot;)) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/peer-to-peer/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b1815c322f5dc9528f6429d1d5e38369","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","summary":"SOFARPC supports scenarios where a specified address is called.\nThe use of direct call in Java API is as follows, only set the direct connection address:\nConsumerConfig\u0026lt;HelloService\u0026gt; consumer = new ConsumerConfig\u0026lt;HelloService\u0026gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026quot;bolt://127.0.0.1:12201\u0026quot;); The use of direct call in XML is as follows:\n\u0026lt;sofa:reference interface=\u0026quot;com.alipay.sample.HelloService\u0026quot; id=\u0026quot;helloService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:route target-url=\u0026quot;127.0.0.1:12200\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:reference\u0026gt; The use of direct call in Annotation is as follows:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026quot;bolt\u0026quot;, directUrl = \u0026quot;127.","tags":null,"title":"Direct call","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","wordcount":73},{"author":null,"categories":null,"content":" Fault Recover Including Fault-Hystrix and Fault-Tolerance features.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e567dc5e291867e92c8dd1c4f953b768","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault/","summary":"Fault Recover Including Fault-Hystrix and Fault-Tolerance features.","tags":null,"title":"Disaster recovery","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault/","wordcount":7},{"author":null,"categories":null,"content":" Distributed consensus algorithm Understand distributed consensus Multiple participants reach a complete consensus on one thing: one conclusion for one thing. The conclusion cannot be overthrown. Typical distributed consensus algorithms Paxos: It is considered as the foundation of distributed consensus algorithms. Other algorithms are its variants. However, the Paxos paper only provides the process of a single proposal, without describing the details of multi-paxos that is required for state machine replication. Paxos implementation involves high engineering complexity, for example, multiple-point writes and log hole tolerance. Zab: It is applied in ZooKeeper and widely used in the industry. However, it is not available as a universal library. Raft: It is known for being easy to understand. There are many renowned Raft implementations in the industry, such as etcd, Braft, and TiKV. Introduction to Raft Raft is in nature a Paxos-based distributed consensus algorithm that is much easier to understand than Paxos. Unlike Paxos, Raft divides the protocols into independent modules, and uses a streamlined design, making the Raft protocol easier to implement.\nSpecifically, Raft divides consensus protocols into almost completely decoupled modules, such as leader election, membership change, log replication, and snapshot.\nRaft adopts a more streamlined design by preventing reordering commits, simplifying roles (it has only three roles: leader, follower, and candidate), allowing only the leader to write, and using randomized timeout values to design leader election.\nFeature: strong leader The system can have only one leader at the same time, and only the leader can accept requests sent by clients. The leader is responsible for communication with all followers, sending proposals to all followers, and receiving responses from the majority of followers. The leader also needs to send heartbeats to all followers to maintain its leadership. To summarize, a strong leader tells its followers: \u0026amp;ldquo;Do not say anything. Do what I said and let me know when you finish!\u0026amp;rdquo; In addition, a leader must always remain active by sending heartbeats to followers. Otherwise, a follower will take its place.\nReplicated state machine Assume we have an infinitely incrementing sequence (system) a[1, 2, 3…]. If for any integer i, the value of a[i] meets the distributed consensus requirement, the system meets the requirement of a consensus state machine. Basically, all real life systems are subject to continuous operations, and reaching consensus on a single value is definitely not enough. To make sure all replicas of a real life system are consistent, we usually convert the operations into entries of a write-ahead-log(WAL). Then, we make sure all replicas of the system reach a consensus on the WAL entries, so that each replica performs operations of the WAL entries in order. As a result, the replicas are in consistent states.\n A client sent a write (operation) request to …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/consistency-raft-jraft/","fuzzywordcount":4900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a0e98df1bec305cca7db6fc34fc97771","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":23,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","summary":"Distributed consensus algorithm Understand distributed consensus Multiple participants reach a complete consensus on one thing: one conclusion for one thing. The conclusion cannot be overthrown. Typical distributed consensus algorithms Paxos: It is considered as the foundation of distributed consensus algorithms. Other algorithms are its variants. However, the Paxos paper only provides the process of a single proposal, without describing the details of multi-paxos that is required for state machine replication.","tags":null,"title":"Distributed consensus - Raft and JRaft","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","wordcount":4871},{"author":null,"categories":null,"content":"SOFARPC provides support for the Dubbo protocol, making it convenient for you to interface with existing Dubbo service. * Basic usage\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"87d78ed0c2d06fe7e1dbf9cb9d6c1c9d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/dubbo/","summary":"SOFARPC provides support for the Dubbo protocol, making it convenient for you to interface with existing Dubbo service. * Basic usage","tags":null,"title":"Dubbo","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/dubbo/","wordcount":21},{"author":null,"categories":null,"content":" Dubbo Integration In this document will demonstrate how to use SOFATracer to track of Dubbo, this example address.\nPrepare Environment The versions of the framework components used in this case are as follows:\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 This case includes three submodules:\n tracer-sample-with-dubbo-consumer service provider tracer-sample-with-dubbo-provider service consumer tracer-sample-with-dubbo-facade service interface define New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026amp;rsquo;s dependency. First, you need to unzip the generated zip package of Spring Boot project and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more information about SOFABoot versions, refer to Release notes.\nNew tracer-sample-with-dubbo-facade Module provider a service interface\npublic interface HelloService { String SayHello(String name); } New tracer-sample-with-dubbo-provider Module provider SOFATracer dependency\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer versions are controlled by SOFABoot versions. If the SOFABoot versions used do not match, you need to manually specify a tracer version that is higher than 2.4.0.\n application.properties Configuration # Spring boot application spring.application.name=dubbo-provider # Base packages to scan Dubbo Component: @org.apache.dubbo.config.annotation.Service dubbo.scan.base-packages=com.alipay.sofa.tracer.examples.dubbo.impl ## Filter dubbo.provider.filter=dubboSofaTracerFilter # Dubbo Protocol dubbo.protocol.name=dubbo ## Dubbo Registry dubbo.registry.address=zookeeper://localhost:2181 logging.path=./logs Publish the Dubbo service using annotations\n@Service public class HelloServiceImpl implements HelloService { @Override public String SayHello(String name) { return \u0026amp;quot;Hello , \u0026amp;quot;+name; } } New tracer-sample-with-dubbo-consumer Module provider SOFATracer dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; application.properties Configuration\nspring.application.name=dubbo-consumer dubbo.registry.address=zookeeper://localhost:2181 dubbo.consumer.filter=dubboSofaTracerFilter logging.path=./logs Service reference @Reference(async = false) public HelloService …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-dubbo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"03f845606b454a7224333238aeecd9ab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","summary":"Dubbo Integration In this document will demonstrate how to use SOFATracer to track of Dubbo, this example address.\nPrepare Environment The versions of the framework components used in this case are as follows:\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 This case includes three submodules:\n tracer-sample-with-dubbo-consumer service provider tracer-sample-with-dubbo-provider service consumer tracer-sample-with-dubbo-facade service interface define New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026rsquo;s dependency.","tags":null,"title":"Dubbo Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","wordcount":297},{"author":null,"categories":null,"content":" Dubbo Log Format SOFATracer integrates Dubbo and outputs the requested link log data format. The default is JSON data format.\nDubbo service consumer digest log（dubbo-client-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app Current application name protocol protocol service service interface method service method invoke.type invoke type remote.host remote host remote.port remote port local.host local host client.serialize.time request serialize time client.deserialize.time response deserialize time req.size.bytes Request Body Size resp.size.bytes Response Body Size result.code result code current.thread.name Current thread name time.cost.milliseconds Request time (ms) baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-03 11:36:01.909\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8451554262561656100126684\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;dubbo-consumer\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;dubbo\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.dubbo.facade.HelloService\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;SayHello\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.232.69\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;20880\u0026amp;quot;,\u0026amp;quot;local.host\u0026amp;quot;:\u0026amp;quot;10.15.232.69\u0026amp;quot;,\u0026amp;quot;client.serialize.time\u0026amp;quot;:35,\u0026amp;quot;client.deserialize.time\u0026amp;quot;:0,\u0026amp;quot;req.size.bytes\u0026amp;quot;:323,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:323,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:252,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Dubbo service provider digest log（dubbo-server-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app current application name service service inteface method service method local.host local host local.host local port protocol protocol server.serialize.time response serialize time server.deserialize.time request deserialize time result.code result code current.thread.name current thread name time.cost.milliseconds Request time (ms) baggage Transparently transmitted baggage data Example\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-03 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-dubbo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"9bac8256ee1a74546b74799f9f1c0de9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","summary":"Dubbo Log Format SOFATracer integrates Dubbo and outputs the requested link log data format. The default is JSON data format.\nDubbo service consumer digest log（dubbo-client-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app Current application name protocol protocol service service interface method service method invoke.","tags":null,"title":"Dubbo log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","wordcount":275},{"author":null,"categories":null,"content":"SOFARPC 提供了 Dubbo 协议的支持，可以让用户非常方便地和现有的 Dubbo 的系统做对接。 * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"87d78ed0c2d06fe7e1dbf9cb9d6c1c9d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/dubbo/","summary":"SOFARPC 提供了 Dubbo 协议的支持，可以让用户非常方便地和现有的 Dubbo 的系统做对接。 * 基本使用","tags":null,"title":"Dubbo 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/dubbo/","wordcount":38},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 Dubbo 协议，只要将 Binding 设置为 Dubbo 即可。下面使用以注解的方式来例举，其他的使用方式可以参考 Bolt 协议基本使用，这里不再重复说明。：\n发布服务 发布一个 Dubbo 的服务，只需要将 @SofaServiceBinding 的 bindingType 设置为 dubbo 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 引用服务 引用一个 Dubbo 的服务，只需要将 @SofaReferenceBinding 的 bindingType 设置为 dubbo 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; 设置 Dubbo 服务的 Group 在 SOFARPC 的模型中，没有直接的一个字段叫做 Group，但是 SOFARPC 有一个 uniqueId 的模型，可以直接映射到 Dubbo 的模型中的 Group，比如下面的代码，就是发布了一个 Group 为 groupDemo 的服务：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}, uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;) public class SampleServiceImpl implements SampleService { } 如下的代码，就是引用了一个 Group 为 groupDemo 的服务：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;, jvmFirst = false) private SampleService sampleService; 注意，目前 Dubbo 协议只支持 Zookeeper 作为服务注册中心。\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo-usage/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1bf72c194a20a5dccea70423690191f4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/dubbo-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/dubbo-usage/","summary":"在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 Dubbo 协议，只要将 Binding 设置为 Dubbo 即可。下面使用以注解的方式来例举，其他的使用方式可以","tags":null,"title":"Dubbo 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/dubbo-usage/","wordcount":322},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 Dubbo 进行埋点，本示例工程地址。\n基础环境 本案例使用的各框架组件的版本如下：\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 本案例包括三个子模块：\n tracer-sample-with-dubbo-consumer 服务调用方 tracer-sample-with-dubbo-provider 服务提供方 tracer-sample-with-dubbo-facade 接口 原理 SOFATracer 对象 Dubbo 的埋点实现依赖于 Dubbo 的 SPI 机制来实现，Tracer 中基于 调用拦截扩展 自定义了 DubboSofaTracerFilter 用于实现对 Dubbo 的调用埋点。由于 DubboSofaTracerFilter 并没有成为 Dubbo 的官方扩展，因此在使用 SOFATracer 时需要安装 调用拦截扩展 中 所提供的方式进行引用，即：\n\u0026amp;lt;!-- 消费方调用过程拦截 --\u0026amp;gt; \u0026amp;lt;dubbo:reference filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;!-- 消费方调用过程缺省拦截器，将拦截所有reference --\u0026amp;gt; \u0026amp;lt;dubbo:consumer filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- 提供方调用过程拦截 --\u0026amp;gt; \u0026amp;lt;dubbo:service filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;!-- 提供方调用过程缺省拦截器，将拦截所有service --\u0026amp;gt; \u0026amp;lt;dubbo:provider filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;/\u0026amp;gt; 新建 SOFABoot 工程作为父工程 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 Maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n新建 tracer-sample-with-dubbo-facade 提供一个接口\npublic interface HelloService { String SayHello(String name); } 新建 tracer-sample-with-dubbo-provider 在工程模块的 pom 文件中添加 SOFATracer 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer 版本受 SOFABoot 版本管控，如果使用的 SOFABoot 版本不匹配，则需要手动指定 tracer 版本，且版本需高于 2.4.0.\n 在工程的 application.properties 文件下添加相关参数， # Spring boot application spring.application.name=dubbo-provider # Base packages to scan Dubbo Component: @org.apache.dubbo.config.annotation.Service dubbo.scan.base-packages=com.alipay.sofa.tracer.examples.dubbo.impl ## Filter 必须配置 dubbo.provider.filter=dubboSofaTracerFilter # Dubbo Protocol dubbo.protocol.name=dubbo ## Dubbo Registry dubbo.registry.address=zookeeper://localhost:2181 logging.path=./logs 使用注解方式发布 Dubbo 服务\n@Service public class HelloServiceImpl implements HelloService { @Override public String SayHello(String name) { return \u0026amp;quot;Hello , \u0026amp;quot;+name; } } 新建 tracer-sample-with-dubbo-consumer 在工程模块的 pom 文件中添加 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 在工程的 application.properties 文件下添加相关参数\nspring.application.name=dubbo-consumer dubbo.registry.address=zookeeper://localhost:2181 # Filter 必须配置 dubbo.consumer.filter=dubboSofaTracerFilter logging.path=./logs 服务引用 @Reference(async = false) public HelloService helloService; @Bean …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-dubbo/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"03f845606b454a7224333238aeecd9ab","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","summary":"在本文档将演示如何使用 SOFATracer 对 Dubbo 进行埋点，本示例工程地址。 基础环境 本案例使用的各框架组件的版本如下： SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 本案例包括三个子模块： tracer-sample-with-dubbo-consumer 服务调","tags":null,"title":"Dubbo 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","wordcount":760},{"author":null,"categories":null,"content":" SOFATracer 集成 Dubbo 后输出请求的链路数据格式，默认为 JSON 数据格式。\nDubbo 服务消费方摘要日志（dubbo-client-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 protocol 协议 service 服务接口 method 调用方法 invoke.type 调用类型 remote.host 目标主机 remote.port 目标端口 local.host 本地主机 client.serialize.time 请求序列化时间 client.deserialize.time 响应反序列化时间 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 error 错误信息 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:36:08.250\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;dubbo-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e27a79c156743856804410019644\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;205ms\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;dubbo\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.glmapper.bridge.boot.service.HelloService\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;SayHello\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;192.168.2.103\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;20880\u0026amp;quot;,\u0026amp;quot;local.host\u0026amp;quot;:\u0026amp;quot;192.168.2.103\u0026amp;quot;,\u0026amp;quot;client.serialize.time\u0026amp;quot;:35,\u0026amp;quot;client.deserialize.time\u0026amp;quot;:5,\u0026amp;quot;req.size.bytes\u0026amp;quot;:336,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:48,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Dubbo 服务提供方摘要日志（dubbo-server-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 protocol 协议 service 服务接口 method 调用方法 invoke.type 调用类型 local.host 本地主机 local.port 本地端口 server.serialize.time 响应序列化时间 server.deserialize.time 请求反序列化时间 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 error 错误信息 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-dubbo/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9bac8256ee1a74546b74799f9f1c0de9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","summary":"SOFATracer 集成 Dubbo 后输出请求的链路数据格式，默认为 JSON 数据格式。 Dubbo 服务消费方摘要日志（dubbo-client-digest.log） 以 JSON 格式输出的数据","tags":null,"title":"Dubbo 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","wordcount":550},{"author":null,"categories":null,"content":" The engine architecture is shown in the following diagram. Node A node in a Raft cluster connects and encapsulates all underlayer service modules, and main service interfaces that are visible to users. Specifically, the leader node of a raft group calls apply(task) to commit new tasks to the state machine replication cluster made up by the Raft group, which will then apply the task to the business state machine.\nStorage It stores Raft configuration changes and log entries converted from requests submitted by users, and replicates log entries from the leader\u0026amp;rsquo;s log to followers\u0026amp;rsquo; logs. LogStorage stores logs, while LogManager is responsible for calling the underlayer storage, caching and batch submitting storage calls, and conducting necessary checks and optimization. MetaStorage stores the metadata and records the internal states of the Raft implementation, for example, the current term of the node and the node to vote for. Optional. Snapshot storage is used to store users\u0026amp;rsquo; state-machine snapshots and meta information. SnapshotStorage stores snapshots, while SnapshotExecutor manages the actual storage, remote installation, and replication of snapshots. State machine StateMachine is an implementation of users\u0026amp;rsquo; core logic. It calls the onApply(Iterator) method to apply log entries that are submitted with Node#apply(task) to the business state machine. FSMCaller encapsulates state transition calls that are sent to the User StateMachine, writes log entries, implements a finite-state machine (FSM), conducts necessary checks, and merges requests for batch submission and concurrent processing. Replication Replicator is used by the leader to replicate log entries to followers. It does the same thing as an AppendEntries RPC of Raft. Without log entries, it is sent by the leader as heartbeats. ReplicatorGroup is used by a Raft group to manage all replicators, and to perform necessary permission checks and dispatches. RPC The RPC module is used for network communication between nodes.\n The RPC server is built in a node to receive requests from other nodes or clients, and to redirect such requests to the corresponding service modules. The RPC client is used to issue requests to other nodes, such as requests for votes, log replication requests, and heartbeats. ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/engine-architecture/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d2cc9de133aed20695229d0cde5b6ff9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","summary":"The engine architecture is shown in the following diagram. Node A node in a Raft cluster connects and encapsulates all underlayer service modules, and main service interfaces that are visible to users. Specifically, the leader node of a raft group calls apply(task) to commit new tasks to the state machine replication cluster made up by the Raft group, which will then apply the task to the business state machine.","tags":null,"title":"Engine architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","wordcount":347},{"author":null,"categories":null,"content":" ExtensionLoader To ensure that all steps of SOFARPC have sufficient scalability, SOFARPC defines a very flexible extension mechanism in which all extension implementations are equal.\nThis mechanism is very useful for both SOFARPC developers and users. SOFARPC abstracts itself into multiple modules which have no explicit dependencies on each other and interact via SPI.\nThis extension mechanism abstracts the interaction method of SPI. If you have read the documents about Filter and Router, you may have such experience.\nThe following sections introduce how to extend through the SPI interaction method.\nSOFARPC provides the capabilities of ExtensionLoader.\nDesign extension points SOFARPC defines an annotation @Extensible, which is on the interface or abstract class to identify that the class is an extension point. Namely, it informs SOFARPC that the class is extensible and SOFARPC needs to find the implementation of the extension point. In addition, the annotation defines the file name of the implementation class and whether the class is a singleton.\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * Specify the name of the custom extension file, which is the full class name by default * * @return Custom extension file name */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * Whether the extension class uses a singleton, yes by default * * @return Whether to use a singleton */ boolean singleton() default true; /** * Whether the extension class needs to be encoded, not by default * * @return Whether to encode */ boolean coded() default false; } SOFARPC also defines the @Extension annotation, which indicates an extension implementation class. It also defines the name that the extension point uses when looking for an extension implementation in the file.\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * Extension point name * * @return Extension point name */ String value(); /** * Extension point coding, not required by default; it is required when the interface needs to be encoded * * @return Extension point encoding * @see Extensible#coded() */ byte code() default -1; /** * Priority sorting, not required by default, the larger number, the higher priority * * @return Sort */ int order() default 0; /** * Whether to override other extensions with low {@link #order()} * * @return Whether to override other low-order extensions * @since 5.2.0 */ boolean override() default false; /** * Exclude other extensions, namely exclude other extensions with low {@link #order()} * * @return Excludes other extensions * @since 5.2.0 */ String[] rejection() default {}; } Add extension point Define extension points. @Extensible public interface Person { void getName(); } Define the extension implementation. @Extension(\u0026amp;quot;A\u0026amp;quot;) public class PersonA implements Person{ @Override public void getName() { System.out.println(\u0026amp;quot;li wei\u0026amp;quot;); } } …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/extension-loader/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"acc5628da3a7ea2df5eb68bd8ec17159","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/extension-loader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/extension-loader/","summary":"ExtensionLoader To ensure that all steps of SOFARPC have sufficient scalability, SOFARPC defines a very flexible extension mechanism in which all extension implementations are equal.\nThis mechanism is very useful for both SOFARPC developers and users. SOFARPC abstracts itself into multiple modules which have no explicit dependencies on each other and interact via SPI.\nThis extension mechanism abstracts the interaction method of SPI. If you have read the documents about Filter and Router, you may have such experience.","tags":null,"title":"Extension mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/extension-loader/","wordcount":603},{"author":null,"categories":null,"content":" Customize different engine stages You can rewrite APIs provided by ActsTestBase in the test script or in the base class.\n Rewrite the prepare, execute, check, and clear actions. For example, you can add some actions before or after super.prepare(). Rewrite the process method. You can add some actions before or after super.process() to reorchestrate the entire script. For example, you can add some personalized steps in the existing clear \u0026amp;gt; prepare \u0026amp;gt; execute \u0026amp;gt; check process. Rewrite beforeActsTest and afterActsTest to add some personalized actions before or after the running of each test case, such as preparing the context and refreshing the cache. Parameterization In response expectation and database expectation data, you can use $Variable name to define a value as a variable. You can set values of the variable in the test script. Supported scope: request parameters, responses, and database table fields. Supported types: Currently, only string parameterization is supported.\nUsage:\n(1) Add $ before a value to define it as a variable in the interface.\n(2) Assign values to the variables in the test script.\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { actsRuntimeContext.paramMap.put(\u0026amp;quot;roleId\u0026amp;quot;, \u0026amp;quot;123\u0026amp;quot;); actsRuntimeContext.refreshDataParam(); } When you write the database expectation, you can use the equal sign = to assign a value to the variable. This indicates that the value is a query result, and subsequent tables can use this variable as the value.\nAssume that the interface will insert data into two tables.\n id_A value_A 123 abc id_B value_B abc efg When you query these two tables, first query for value_A based on id_A in Table A that is returned by the interface. Then use value_A as a condition for the query in Table B. You can set the values as follows in the plug-in.\n Field Flag Value id_A C $param1 value_A Y =param2 Field Flag Value id_B C $param2 value_B Y efg Operation description:\n =param2 and $param2 indicate that the ACTS framework will first query for value_A in Table A, and then select from B where id_B = value_A to obtain the property value of id_B in Table B. $param1 indicates that you can assign a value to id_A in the code, for example: actsRuntimeContext.paramMap.put(\u0026amp;quot;param1\u0026amp;quot;,\u0026amp;quot;123\u0026amp;quot;); This snippet assigns the value 123 to the variable param1. You can write this snippet to beforeActsTest in the test script to make the ACTS framework query table A before assigning the value 123 to id_A.\nComponentization Currently, only string componentization is supported.\nIf a property is a dynamically generated string, for example, some IDs. You can use the at sign @ to call a component to generate this property. The component must be placed in the component package at the same level as the test module, namely: com.corpname.appname.acts.component (appname is the name of the system, and corpname is the name of the company, for …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-api/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ce7e264713a6f7a3f0672e2432489f59","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-api/","summary":"Customize different engine stages You can rewrite APIs provided by ActsTestBase in the test script or in the base class.\n Rewrite the prepare, execute, check, and clear actions. For example, you can add some actions before or after super.prepare(). Rewrite the process method. You can add some actions before or after super.process() to reorchestrate the entire script. For example, you can add some personalized steps in the existing clear \u0026gt; prepare \u0026gt; execute \u0026gt; check process.","tags":null,"title":"Extensions","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-api/","wordcount":1102},{"author":null,"categories":null,"content":" Q: What should I do if NoSuchMethodError is returned? Generally, this error is returned in the case of dependency conflicts. Commonly known dependency conflicts are listed as follows. Exclude the corresponding dependencies when you encounter relevant conflicts.\nLog conflict commons-logging conflict \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-logging\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; logback-classic conflict Rule out logback-classic by the location of the conflict. For example, application dependencies spring-boot-starter-logging and spring-test conflict with each other.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.3.4.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; snakeyaml conflict java.lang.NoSuchMethodError: org.yaml.snakeyaml.Yaml.\u0026amp;lt;init\u0026amp;gt;(Lorg/yaml/snakeyaml/constructor/BaseConstructor;)V org.yaml referenced in spring-boot-starter-test conflicts with org.yaml referenced in org.testing. In the following sample code, a conflict of org.yaml in spring-boot-starter-test is ruled out (it can also be ruled out at other conflict locations such as org.testing):\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.yaml\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;snakeyaml\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Q: What should I do if NoClassDefFoundError is returned? Generally, this error is returned in the case of missing dependencies or dependency conflicts.\nMockito returns a no class found error While using Mockito with SOFABoot, you do not have to import Mockito if the spring-boot-starter-test dependency already exists.\nQ: What should I do if \u0026amp;ldquo;No bean dataAccessConfigManager available\u0026amp;rdquo; is returned? This error is returned because the application starter class specified by the test script does not have the acts-core.xml file. You can add the acts-core.xml file according to the following figure.\nQ: What should I do if \u0026amp;ldquo;No runnable methods\u0026amp;rdquo; is returned? Generally, this error is caused when you run your Junit test with the ACTS test script. You can use the TestNG framework to run the ACTS test script.\nQ: What should I do in the case of a model …","date":-62135596800,"description":"","dir":"projects/sofa-acts/faq/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5f89d1f5695cbe6b669a8738741529bd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/faq/","summary":"Q: What should I do if NoSuchMethodError is returned? Generally, this error is returned in the case of dependency conflicts. Commonly known dependency conflicts are listed as follows. Exclude the corresponding dependencies when you encounter relevant conflicts.\nLog conflict commons-logging conflict \u0026lt;exclusion\u0026gt; \u0026lt;artifactId\u0026gt;commons-logging\u0026lt;/artifactId\u0026gt; \u0026lt;groupId\u0026gt;commons-logging\u0026lt;/groupId\u0026gt; \u0026lt;/exclusion\u0026gt; logback-classic conflict Rule out logback-classic by the location of the conflict. For example, application dependencies spring-boot-starter-logging and spring-test conflict with each other.\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.","tags":null,"title":"FAQ","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/faq/","wordcount":633},{"author":null,"categories":null,"content":" Common issues Q: Is SOFARPC the version used inside Ant Financial? Yes, SOFARPC has excellent extension interfaces, and the version for internal use just has some additional extension implementations based on the open source version. For example, the cloud-based commercial version integrates the Ant Financial Technology\u0026amp;rsquo;s shared registry center, Distributed System Tracing (DST) and other products. The version for internal use integrates Ant Financial\u0026amp;rsquo;s internal registry center, LDC router and other individual extensions.\nQ: Does SOFARPC use ZooKeeper as the registry center internally? Can it integrate other registry centers such as etcd? Ant Financial uses its self-developed registry products internally. SOFARPC\u0026amp;rsquo;s registry modules are extensible. All the registry modules use the same set of core interfaces for both internal and external use. Currently, the open-source version has integrated with ZooKeeper, and other registry implementation communities are being integrated.\nQ: What is the difference between SOFARPC and Dubbo? Dubbo, developed by Alibaba Group, is an excellent open-source RPC framework featuring high performance and good scalability. Dubbo is a comparatively mature open source framework, with a large number of users and rich open source ecology. Now, it has joined the Apache Foundation for incubation. Dubbo was first widely used in the Alibaba B2B department.\nOriginated from HSF in Alibaba Group, SOFARPC now has grown to an independent product. SOFARPC has carried out a lot of reconstruction and optimization on the aspects of protocol, network, routing, and scalability to meet the large-scale financial business scenarios of Ant Financial. In the Ant Financial\u0026amp;rsquo;s middleware (SOFAStack) ecosystem, SOFARPC is supported by a comprehensive microservices technology stack, including Microservices R\u0026amp;amp;D framework, RPC framework, service registry center, distributed scheduling task, throttling framework, Dynamic Configuration, DST, Metrics and others. By Dec. 11, 2017, SOFARPC has been used by thousands of systems in Ant Financial, and the production environment has released more than tens of thousands of interfaces.\nHowever, in the open source field, SOFARPC is still at the initial stage, and its open source ecosystem is still under construction. With the advancement of the open source plan, various related components will be available in the subsequent versions to improve the microservices stack. You are welcome to build SOFAStack together with us.\nIn terms of performance, the technical points of both products involved in protocols are similar. As for scalability, both products have good scalability. As for other functional differences, here are some features that have been opened source or will be open sourced in the near future for reference:\n SOFARPC supports HTTP/2 and GRPC protocols and provides such capabilities as service warm-up weight, automatic degradation upon fault, negotiation mechanism, and CRC data …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/faq/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a6ec77ce5a423c5345394f42c64a416b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/faq/","summary":"Common issues Q: Is SOFARPC the version used inside Ant Financial? Yes, SOFARPC has excellent extension interfaces, and the version for internal use just has some additional extension implementations based on the open source version. For example, the cloud-based commercial version integrates the Ant Financial Technology\u0026rsquo;s shared registry center, Distributed System Tracing (DST) and other products. The version for internal use integrates Ant Financial\u0026rsquo;s internal registry center, LDC router and other individual extensions.","tags":null,"title":"FAQ","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/faq/","wordcount":742},{"author":null,"categories":null,"content":"Usually, a service have multiple service providers in a cluster. Some of the service providers may have persistent connections still survived due to network, configuration, long-term fullgc, full thread pool, hardware failure and others, but the program cannot respond properly. The stand-alone fault tolerance function can degrade the exceptional service providers so that the client requests can be pointed to the healthy node. When the exceptional nodes become normal, the standalone fault tolerance function will restore the nodes, so that the client requests can gradually distribute traffic to the nodes. The standalone fault tolerance function solves the problem that service failures continue to affect the business, avoids the avalanche effect, reduces the long response time required for manual intervention and increases system availability.\nRunning mechanism:\n Standalone fault tolerance counts the number of calls and the number of exceptions in a time range, and calculates the abnormal rate of IP for each service and the average abnormal rate of the service. When the IP abnormal rate is greater than the service average abnormal rate to a certain ratio, the dimension of the service + ip is degraded. If the weight of the service + ip dimension is not degraded to 0, then when the call of the service + ip dimension is normal, the weight will be restored. The entire calculation and control process proceeds asynchronously, thus not blocking the call. The standalone fault tolerance is used as follows:\nFaultToleranceConfig faultToleranceConfig = new FaultToleranceConfig(); faultToleranceConfig.setRegulationEffective(true); faultToleranceConfig.setDegradeEffective(true); faultToleranceConfig.setTimeWindow(20); faultToleranceConfig.setWeightDegradeRate(0.5); FaultToleranceConfigManager.putAppConfig(\u0026amp;quot;appName\u0026amp;quot;, faultToleranceConfig); As above, after the standalone fault tolerance switch is turned on, the application will calculate the exceptions every 20s time window. If a service + IP calling dimension is determined to be a faulty node, the weight of the service + IP will be degraded to 0.5 times.\nFor more detailed parameters, please refer to Standalone troubleshooting\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-tolerance/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7501b0fac1d1d89c61de0d591e29e1d0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","summary":"Usually, a service have multiple service providers in a cluster. Some of the service providers may have persistent connections still survived due to network, configuration, long-term fullgc, full thread pool, hardware failure and others, but the program cannot respond properly. The stand-alone fault tolerance function can degrade the exceptional service providers so that the client requests can be pointed to the healthy node. When the exceptional nodes become normal, the standalone fault tolerance function will restore the nodes, so that the client requests can gradually distribute traffic to the nodes.","tags":null,"title":"Fault tolerance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","wordcount":306},{"author":null,"categories":null,"content":"Fault tolerance automatically monitors the RPC calls, degrades the weight of the failed node, and recovers the weight when the node restored to normal. The bolt protocol is currently supported.\nIn SOFABoot, you only need to configure fault tolerance parameters to application.properties. You can select not to configure all parameters but only configure the parameters that you care about. Then, the remaining parameters will take the default values. Note that rpc.aft.regulation.effective is a global switch for this function. If it is off, the function will not work and other parameters will not take effect.\n Attribute Description Default value timeWindow Time window size: the period in which statistics are calculated. 10s leastWindowCount Minimum number of calls in the time window: Only data that has reached this minimum value in the time window will be added in calculation and control. 10 times leastWindowExceptionRateMultiple Degradation ratio of the exception rate in the time window to the average exception rate of the service: When calculating the statistical information, the average exception rate of all valid call IPs of the service is calculated. If the exception rate of an IP is greater than or equal to the lowest ratio, the IP will be degraded. 6 times weightDegradeRate Degradation ratio: The rate of degradation of an address when it is degraded. 1\u0026amp;frasl;20 weightRecoverRate Recovery ratio: The recovery ratio of the address when it is weighted. 2 times degradeEffective Degradation switch: If the application turns on this switch, it will degrade the address that matches the degradation criteria; otherwise, only the log will be printed. false (off) degradeLeastWeight Degradation minimum weight: If the address weight is degraded to the weight less than this minimum weight, the minimum weight will be used. 1 degradeMaxIpCount Maximum number of IPs for degradation: The number of IPs in the same service that have been degraded cannot exceed this value. 2 regulationEffective Global switch: If the switch is turned on by the application, the entire standalone fault tolerance function will be turned on; otherwise, this function will not be used at all. false (off) Example\nCom.alipay.sofa.rpc.aft.time.window=20 Com.alipay.sofa.rpc.aft.least.window.count=30 Com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple=6 Com.alipay.sofa.rpc.aft.weight.degrade.rate=0.5 Com.alipay.sofa.rpc.aft.weight.recover.rate=1.2 Com.alipay.sofa.rpc.aft.degrade.effective=ture Com.alipay.sofa.rpc.aft.degrade.least.weight=1 Com.alipay.sofa.rpc.aft.degrade.max.ip.count=2 Com.alipay.sofa.rpc.aft.regulation.effective=true As configured above, the fault tolerance function and degradation switch are enabled. When a node fails too many times, its weight is degraded, and during recovery, the weight will be restored. The node healthy is measured every 20s, and the nodes called for more than 30 times in 20s are recognized as calculation data. If the …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-fault-tolerance/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a132b54b2398534d1773489e2b0db166","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","summary":"Fault tolerance automatically monitors the RPC calls, degrades the weight of the failed node, and recovers the weight when the node restored to normal. The bolt protocol is currently supported.\nIn SOFABoot, you only need to configure fault tolerance parameters to application.properties. You can select not to configure all parameters but only configure the parameters that you care about. Then, the remaining parameters will take the default values. Note that rpc.","tags":null,"title":"Fault tolerance configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","wordcount":487},{"author":null,"categories":null,"content":" Feature architecture SOFABolt provides the following basic features: Basic communication functions (remoting-core) Netty-based, highly-effective network I/O and thread model practice Connection management (lock-free connection establishment, timed disconnection, automatic reconnection) Basic communication models (oneway, sync, future, callback) Timeout control Batch unpacking and batch submission processor Heartbeat and IDLE event processing Protocol framework (protocol-skeleton) Commands and command processor Coding and decoding processor Heartbeat trigger Custom private protocol implementation - RPC communication protocol (protocol-implementation) RPC communication protocol design Flexible deserialization timing control Request processing timeout FailFast mechanism User request processor (UserProcessor) Duplex communication Usage 1 Use SOFABolt as a remote communication framework. You do not need to consider the details of how to implement a private protocol, just use our built-in RPC communication protocol. You can simply enable the client side and the server side, and simultaneously register a user request processor, thereby completing the remote calling. In addition, basic features such as connection management and heartbeat are available by default. Currently supported call types are shown in the figure below:\n For a sample demonstration, refer to our user guide. Usage 2 Use SOFABolt as a protocol framework. You can reuse the basic functions of the basic communication model, the interface definitions included in the protocols, etc. Then, according to the private protocol you designed, you can customize the command types, command processors, decoding processors, etc. The RPC and message command definition structure is as shown in the figure below:\n","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-functions/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fde29139cbd8b786326a6479e52814dd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","summary":"Feature architecture SOFABolt provides the following basic features: Basic communication functions (remoting-core) Netty-based, highly-effective network I/O and thread model practice Connection management (lock-free connection establishment, timed disconnection, automatic reconnection) Basic communication models (oneway, sync, future, callback) Timeout control Batch unpacking and batch submission processor Heartbeat and IDLE event processing Protocol framework (protocol-skeleton) Commands and command processor Coding and decoding processor Heartbeat trigger Custom private protocol implementation - RPC communication protocol (protocol-implementation) RPC communication protocol design Flexible deserialization timing control Request processing timeout FailFast mechanism User request processor (UserProcessor) Duplex communication Usage 1 Use SOFABolt as a remote communication framework.","tags":null,"title":"Features","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","wordcount":237},{"author":null,"categories":null,"content":" Features Service publishing and reference Communication Protocol Bolt protocol Basic usage Calling type Timeout control Generic call Serialization protocol Custom thread pool RESTful protocol Basic usage Custom filter Integrated Swagger Dubbo Basic usage H2C Basic usage Registry center Direct call Load balancing Custom filter Custom router addressing Call retry Tracing SOFATracer Skywalking Custom thread pool Link data transparent transmission Warm-up weight Fault tolerance Node cross-language call Graceful shutdown ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/features/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0059809aed46360e8787e945ff098610","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/features/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/features/","summary":" Features Service publishing and reference Communication Protocol Bolt protocol Basic usage Calling type Timeout control Generic call Serialization protocol Custom thread pool RESTful protocol Basic usage Custom filter Integrated Swagger Dubbo Basic usage H2C Basic usage Registry center Direct call Load balancing Custom filter Custom router addressing Call retry Tracing SOFATracer Skywalking Custom thread pool Link data transparent transmission Warm-up weight Fault tolerance Node cross-language call Graceful shutdown ","tags":null,"title":"Features","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/features/","wordcount":68},{"author":null,"categories":null,"content":" 本文描述的是 MOSN 的 FilterChain 配置。\nFilterChain 是 MOSN Listener 配置中核心逻辑配置，不同的 FilterChain 配置描述了 Listener 会如何处理请求。\n目前 MOSN 一个 Listener 只支持一个 FilterChain。\nFilterChain 的配置结构如下所示。\n{ \u0026amp;quot;tls_context\u0026amp;quot;: {}, \u0026amp;quot;tls_context_set\u0026amp;quot;: [], \u0026amp;quot;filters\u0026amp;quot;: [] } tls_context_set 一组 tls_context 配置，MOSN 默认使用 tls_context_set 来描述 listener 的 TLS 的证书信息。 一个 listener 可同时支持配置多张 TLS 证书。 tls_context 单独配置 tls_context 而不是使用 tls_context_set 是兼容 MOSN 历史配置（只支持一张证书配置时）的场景，这种配置方式后面会逐步废弃。 tls_context 的详细配置说明，参考 tls_context。 filters 一组 network filter 配置。\nnetwork filter network filter 描述了 MOSN 在连接建立以后如何在 4 层处理连接数据。\n{ \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: {} } type 是一个字符串，描述了 filter 的类型。 config 可以是任意 json 配置，描述不同 filter 的配置。 network filter 可自定义扩展实现，默认支持的 type 包括 proxy、tcp proxy、connection_manager。 connection_manager 是一个特殊的 network filter，它需要和 proxy 一起使用，用于描述 proxy 中路由相关的配置，是一个兼容性质的配置，后续可能有修改。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/filter-chain/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d79979b85edad41aa6f0b3d8fe3295ee","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","summary":"本文描述的是 MOSN 的 FilterChain 配置。 FilterChain 是 MOSN Listener 配置中核心逻辑配置，不同的 FilterChain 配置描述了 Listener 会如何处理请求。 目前 MOSN 一个 Listener 只支持一个 FilterChain。 FilterChain 的配","tags":null,"title":"FilterChain 配置","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","wordcount":389},{"author":null,"categories":null,"content":" Framework preparation Before reading, you can download and install ACTS IDE and import the ACTS framework by refering to Quick start.\nThis topic mainly describes the encoding, datasource configuration, and quick configuration to help you use the ACTS framework.\nEncoding Ensure that the encoding of ACTS and that of the system code are consistent, specifically, ensure that the encoding for script generation and the encoding of the IDEA workspace are consistent with the encoding of your application code. Otherwise, the code may get corrupted.\nThe encoding selected for test script generation is shown as follows.\nEncoding of the IDEA workspace:\nDatasource configuration The purpose of configuring data sources in ACTS is to ensure that you can use the system\u0026amp;rsquo;s data sources to properly perform database addition, deletion, and query operations during the preparation, clearance, and check stages.\nDatasource configuration Configure the mapping relationship between the ModuleName, datasource, and tables at the DAL layer in src/test/resource/config/acts-config.properties. The name of datasources starts with ds_ as follows:\ndatasource_bundle_name =com.alipay.testapp.common.dal ds_bean1=table1,table2 ds_bean2=table3,table4 #Configuration format #ds_datasource bean=logical table 1,logical table 2 Bean 1 and bean 2 are the names of the datasource beans at the DAL layer of the application code. Multiple datasources are supported. The table name supports regular expressions and sharding suffixes are not required. In the case of multiple datasources, a table must belong to only one datasource. See the following figure.\nDirect JDBC connection to the database The direct JDBC connection to the database is used to generate the DB data model. The configuration in devdb.conf or testdb.conf under src/test/resource/config/dbConf/ is as follows:\nxxx_url = jdbc:oracle:thin:@localhost:1521:cifdb xxx_username = myname xxx_password = mypswd Quick configuration description The quick test framework configuration mainly generates the basic Java classes and the necessary configuration files:\nJava classes AppNameActsBaseUtils.java The utility class that is commonly used in the test script writing process to get various data from the ACTS framework. The initial version provides only common methods. You can add desired methods by yourself.\n AppNameActsTestBase.java The encapsulated application test base class. If you have special business system requirements, you can encapsulate additional methods based on this class. If not, ignore this file.\nConfiguration files ","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ready/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c3a89cbf42d55c98206a08e94d05ffde","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-ready/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-ready/","summary":"Framework preparation Before reading, you can download and install ACTS IDE and import the ACTS framework by refering to Quick start.\nThis topic mainly describes the encoding, datasource configuration, and quick configuration to help you use the ACTS framework.\nEncoding Ensure that the encoding of ACTS and that of the system code are consistent, specifically, ensure that the encoding for script generation and the encoding of the IDEA workspace are consistent with the encoding of your application code.","tags":null,"title":"Framework preparation","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-ready/","wordcount":358},{"author":null,"categories":null,"content":"Since Java 8, Java has introduced various @FunctionalInterface interfaces to support functional programming. Generally, Java functions will be executed in a ForkJoinPool. If some thread variables of Tracer are not passed in, it will cause the loss of Trace information.\nTherefore, in SOFATracer XXX version, a series of wrapper classes for these @FunctionalInterface interfaces has been added to ensure that trace-related information can be transferred correctly and transparently. The following is an example of the Consumer interface, just need to change the construction of Consumer to SofaTracerConsumer, and pass the original Consumer as the parameter of the constructor of SofaTracerConsumer:\nConsumer\u0026amp;lt;String\u0026amp;gt; consumer = new SofaTracerConsumer\u0026amp;lt;\u0026amp;gt;(System.out::println); All wrapped classes are in the https://github.com/sofastack/sofa-tracer/tree/master/tracer-core/src/main/java/com/alipay/common/tracer/core/async directory.\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/functional-interface-support/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"45e4d21f290976f4206beac2f4712aec","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","summary":"Since Java 8, Java has introduced various @FunctionalInterface interfaces to support functional programming. Generally, Java functions will be executed in a ForkJoinPool. If some thread variables of Tracer are not passed in, it will cause the loss of Trace information.\nTherefore, in SOFATracer XXX version, a series of wrapper classes for these @FunctionalInterface interfaces has been added to ensure that trace-related information can be transferred correctly and transparently. The following is an example of the Consumer interface, just need to change the construction of Consumer to SofaTracerConsumer, and pass the original Consumer as the parameter of the constructor of SofaTracerConsumer:","tags":null,"title":"Functional interface support","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","wordcount":113},{"author":null,"categories":null,"content":"从 Java 8 中，Java 开始引入了各种 @FunctionalInterface 接口，以更好地支持函数式编程，通常，Java 的函数会在一个 ForkJoinPool 中执行，如果这个时候没有把 Tracer 的一些线程变量传递进去的话，就会造成 Trace 信息的丢失。\n因此，在 SOFATracer XXX 版本中增加了对这些 @FunctionalInterface 接口的包装类，以确保 Trace 相关的信息能够正确地传递下面，下面以 Consumer 接口为例进行说明，只需要将原来构造 Consumer 的地方修改成构造 SofaTracerConsumer，并且将原来的 Consumer 传入作为 SofaTracerConsumer 的构造函数的参数即可：\nConsumer\u0026amp;lt;String\u0026amp;gt; consumer = new SofaTracerConsumer\u0026amp;lt;\u0026amp;gt;(System.out::println); 所有做了包装的类都在 https://github.com/sofastack/sofa-tracer/tree/master/tracer-core/src/main/java/com/alipay/common/tracer/core/async 目录下，文档中不一一列举。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/functional-interface-support/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"45e4d21f290976f4206beac2f4712aec","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/functional-interface-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/functional-interface-support/","summary":"从 Java 8 中，Java 开始引入了各种 @FunctionalInterface 接口，以更好地支持函数式编程，通常，Java 的函数会在一个 ForkJoinPool 中执行，如果这个时候没有把 Tracer 的一些线程变量传递","tags":null,"title":"Functional 接口支持","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/functional-interface-support/","wordcount":229},{"author":null,"categories":null,"content":" Generic calls provide the ability for clients to initiate calls without having to rely on the server`s interface. Currently, the generic call of SOFARPC only supports using Hessian2 as the serialization protocol under the Bolt communication protocol.\nSOFABoot environment Publish Service There is nothing special about publishing a service. Just publish the service normally, for example:\n\u0026amp;lt;!-- generic --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Reference Service \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.api.GenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs generic-interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; The jvm-first can be left empty according to the actual situation. The interface should be the general interface of generic call. As for the generic-interface, you can just write in the name of the interface to be called.\nInitiate a call GenericService sampleGenericServiceReference = (GenericService) applicationContext .getBean(\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot;); GenericObject genericResult = (GenericObject) sampleGenericServiceReference.$genericInvoke(\u0026amp;quot;sayGeneric\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericParamModel\u0026amp;quot; }, new Object[] { genericObject }); RPC API ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt;() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); You can set the service as a generic service and set the interface name of the server by setGeneric as above. GenericService is used as a generic service, and GenericService can initiate generic calls. You need to pass in the method name, method type, and method parameters when invoking a call.\nIf the parameter or return result is also required to be generalized on the client side, you can achieve this with GenericObject.\nGenericObject genericObject = new GenericObject(\u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot;); genericObject.putField(\u0026amp;quot;str\u0026amp;quot;, \u0026amp;quot;xxxx\u0026amp;quot;); genericObject.putField(\u0026amp;quot;num\u0026amp;quot;, 222); GenericObject result = (GenericObject) testService.$genericInvoke(\u0026amp;quot;echoObj\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot; }, new Object[] { genericObject }); String str = result.getField(\u0026amp;quot;str\u0026amp;quot;); String …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/generic-invoke/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"84ac624dc99a42a8f89489aa10304ef7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","summary":"Generic calls provide the ability for clients to initiate calls without having to rely on the server`s interface. Currently, the generic call of SOFARPC only supports using Hessian2 as the serialization protocol under the Bolt communication protocol.\nSOFABoot environment Publish Service There is nothing special about publishing a service. Just publish the service normally, for example:\n\u0026lt;!-- generic --\u0026gt; \u0026lt;bean id=\u0026quot;sampleGenericServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;sampleGenericServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt/\u0026gt; \u0026lt;/sofa:service\u0026gt; Reference Service \u0026lt;sofa:reference jvm-first=\u0026quot;false\u0026quot; id=\u0026quot;sampleGenericServiceReference\u0026quot; interface=\u0026quot;com.","tags":null,"title":"Generic call","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","wordcount":501},{"author":null,"categories":null,"content":" This document introduces how to use SOFARPC for service publishing and reference in SOFABoot.\nYou can get the code sample of this document by clicking here. Note that the code sample requires a local installation of the zookeeper environment. If not, you need to remove the com.alipay.sofa.rpc.registry.address configuration in application.properties to use the local file as a registry center.\nCreate a project Prepare environment: SOFABoot requires JDK7 or JDK8 and needs to be compiled with Apache Maven 2.2.5 or above. Build SOFABoot project: SOFABoot is based on Spring Boot. So you can use Spring Boot\u0026amp;rsquo;s project generation tool to generate a standard Spring Boot project. Add SOFABoot dependency: The generated standard Spring Boot project directly uses Spring parent dependency, which should be changed to the parent dependency provided by SOFABoot. The parent dependency provides and manages a variety of starters provided by SOFABoot. \u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa-boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Here, \u0026amp;lsquo;${sofa-boot.version}\u0026amp;rsquo; specifies the specific SOFABoot version. Refer to Release History.\n Configure application.properties: application.properties is the configuration file in SOFABoot project. Here you need to configure the application name. spring.application.name=AppName Introduce RPC starter: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Define service interface and implementation public interface AnnotationService { String sayAnnotation(String string); } Publish service on server Publish the service through \u0026amp;lsquo;@SofaService\u0026amp;rsquo; annotation, as shown in the following code: SOFABoot registers the service implementation on the server, communicates with the client by bolt protocol, and publishes metadata such as address to registry center (local file is used as registry center by default).\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } Reference service by client The reference service is annotated with \u0026amp;lsquo;@SofaReference\u0026amp;rsquo;, as shown in the following code: SOFABoot will generate a RPC proxy bean for \u0026amp;lsquo;AnnotationService\u0026amp;rsquo;, it also …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-sofa-boot/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0dd5e0e5116473aee630cba38679d493","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","summary":"This document introduces how to use SOFARPC for service publishing and reference in SOFABoot.\nYou can get the code sample of this document by clicking here. Note that the code sample requires a local installation of the zookeeper environment. If not, you need to remove the com.alipay.sofa.rpc.registry.address configuration in application.properties to use the local file as a registry center.\nCreate a project Prepare environment: SOFABoot requires JDK7 or JDK8 and needs to be compiled with Apache Maven 2.","tags":null,"title":"Get started with SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","wordcount":501},{"author":null,"categories":null,"content":" This document introduces how to apply SOFARPC for service publishing and reference. This example will simulate a server locally to listen to a port and publish a service, and the client will reference the service for direct call.\nYou can get the code sample of this document by clicking here.\nCreate a project You need to install JDK 6 or above and Maven 3 or above.\nCreate a new Maven project and introduce SOFARPC dependency.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;latest version\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note: The latest version can be found at https://github.com/sofastack/sofa-rpc/releases.\nWrite a server implementation Step 1: Create interface\n/** * Quick Start demo interface */ public interface HelloService { String sayHello(String string); } Step 2: Create interface implementation\n/** * Quick Start demo implement */ public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string { System.out.println(\u0026amp;quot;Server receive: \u0026amp;quot; + string); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; !\u0026amp;quot;; } } Step 3: Write the server code\n/** * Quick Start Server */ public class QuickStartServer { public static void main(String[] args) { ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // Set a protocol, which is bolt by default .setPort(12200) // set a port, which is 12200 by default .setDaemon(false); // non-daemon thread ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // Specify the interface .setRef(new HelloServiceImpl()) // Specify the implementation .setServer(serverConfig); // Specify the server providerConfig.export (); // Publish service } } Write a client implementation Step 1: Get the server interface\nIn general, the server provides the interface class to the client in the form of jar. In this example, this step is skipped since the server and client are in the same project.\nStep 2: Write the client code\n/** * Quick Start client */ public class QuickStartClient { public static void main(String[] args) { ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // Specify the interface .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // Specify the protocol.setDirectUrl .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12200\u0026amp;quot;); // Specify the direct connection address // Generate the proxy class HelloService helloService = consumerConfig.refer(); while (true) { System.out.println(helloService.sayHello(\u0026amp;quot;world\u0026amp;quot;)); try { Thread.sleep(2000); } catch (Exception e) { } } } } Run Start the server and client separately.\nThe server outputs:\n Server receive: The world\n The client outputs:\n hello world !\n More For more examples, please refer to: example\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-rpc/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"192d252b0b36266622284b68d10e9fe4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","summary":"This document introduces how to apply SOFARPC for service publishing and reference. This example will simulate a server locally to listen to a port and publish a service, and the client will reference the service for direct call.\nYou can get the code sample of this document by clicking here.\nCreate a project You need to install JDK 6 or above and Maven 3 or above.\nCreate a new Maven project and introduce SOFARPC dependency.","tags":null,"title":"Get started with SOFARPC","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","wordcount":371},{"author":null,"categories":null,"content":" Graceful shutdown includes two parts. One is the RPC framework as client, and the other is the RPC framework as server.\nAs server As the server, the RPC framework should not be violently shutdown.\ncom.alipay.sofa.rpc.context.RpcRuntimeContext Added a ShutdownHook to the static initialization snippet:\n// Add jvm shutdown event if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } The logic in ShutdownHook is executed first when the publishing platform or users run the following method kill pid. In the destroy operation, the RPC framework first performs actions such as canceling service registration to the registry center and closing the service port.\nprivate static void destroy(boolean active) { RpcRunningState.setShuttingDown (true); for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.preDestroy(); } List\u0026amp;lt;ProviderConfig\u0026amp;gt; providerConfigs = new ArrayList\u0026amp;lt;ProviderConfig\u0026amp;gt;(); for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { providerConfigs.add(bootstrap.getProviderConfig()); } // First, unregister the server List\u0026amp;lt;Registry\u0026amp;gt; registries = RegistryFactory.getRegistries(); if (CommonUtils.isNotEmpty(registries) \u0026amp;amp;\u0026amp;amp; CommonUtils.isNotEmpty(providerConfigs)) { for (Registry registry : registries) { registry.batchUnRegister(providerConfigs); } } / / Shut down the port that has been started ServerFactory.destroyAll(); // Close the published service for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { bootstrap.unExport(); } // Close the called service for (ConsumerBootstrap bootstrap : REFERRED_CONSUMER_CONFIGS) { ConsumerConfig config = bootstrap.getConsumerConfig(); If (!CommonUtils.isFalse(config.getParameter(RpcConstants.HIDDEN_KEY_DESTROY))) { // Unless you do not let the active unrefer bootstrap.unRefer(); } } // Shut down the registry center RegistryFactory.destroyAll(); / / Close some public resources of the client ClientTransportFactory.closeAll(); // Uninstall the module if (!RpcRunningState.isUnitTestMode()) { ModuleFactory.uninstallModules(); } // Uninstall the hook for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.postDestroy(); } // Clean up the cache RpcCacheManager.clearAll(); RpcRunningState.setShuttingDown (false); if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework has been release all resources {}...\u0026amp;quot;, active ? \u0026amp;quot;actively \u0026amp;quot; : \u0026amp;quot;\u0026amp;quot;); } } Taking bolt as an example, closing the port is not an immediate action.\n@Override public void destroy() { if (!started) { return; } int stopTimeout = serverConfig.getStopTimeout(); If (stopTimeout \u0026amp;gt; 0) { // need to wait for the end time AtomicInteger count = …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/graceful-shutdown/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"53af179e23ba184b01eb8234c055b15d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","summary":"Graceful shutdown includes two parts. One is the RPC framework as client, and the other is the RPC framework as server.\nAs server As the server, the RPC framework should not be violently shutdown.\ncom.alipay.sofa.rpc.context.RpcRuntimeContext Added a ShutdownHook to the static initialization snippet:\n// Add jvm shutdown event if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.","tags":null,"title":"Graceful shutdown","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","wordcount":669},{"author":null,"categories":null,"content":" H2C protocol SOFARPC provides support for the H2C protocol, which can be used to publish and reference services.\n Basic usage ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"45b6d6ba0ca1ae7f6d415d79c184f766","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/h2c/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/h2c/","summary":" H2C protocol SOFARPC provides support for the H2C protocol, which can be used to publish and reference services.\n Basic usage ","tags":null,"title":"H2C","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/h2c/","wordcount":20},{"author":null,"categories":null,"content":"SOFARPC 提供了 H2C 协议的支持，可以可以采用 H2C 协议来进行服务的发布和引用 * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"45b6d6ba0ca1ae7f6d415d79c184f766","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/h2c/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/h2c/","summary":"SOFARPC 提供了 H2C 协议的支持，可以可以采用 H2C 协议来进行服务的发布和引用 * 基本使用","tags":null,"title":"H2C","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/h2c/","wordcount":36},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 H2C 协议，只要将 Binding 设置为 H2C 即可。下面使用以注解的方式来例举，其他的使用方式可以参考 Bolt 协议基本使用，这里不再重复说明。：\n发布服务 发布一个 H2C 的服务，只需要将 @SofaServiceBinding 的 bindingType 设置为 h2c 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 引用服务 引用一个 H2C 的服务，只需要将 @SofaReferenceBinding 的 bindingType 设置为 h2c 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c-usage/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa75eff1e99b3acad5087160a1b44a09","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/h2c-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/h2c-usage/","summary":"在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 H2C 协议，只要将 Binding 设置为 H2C 即可。下面使用以注解的方式来例举，其他的使用方式可以","tags":null,"title":"H2C 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/h2c-usage/","wordcount":168},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0e92b5faec8584280cc296255f3a4541","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/http/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/http/","summary":"","tags":null,"title":"HTTP","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/http/","wordcount":0},{"author":null,"categories":null,"content":" SOFABoot provides Readiness Check to enhance Spring Boot\u0026amp;rsquo;s Health Check. If you need to use the SOFA middleware, you are advised to use the Health Check extension of SOFABoot to launch application examples in a more elegant way.\nEnable Health Check To enable the Health Check feature in SOFABoot, you only need to import the following starter:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Without the Health Check extension, users still can perform Liveness Check with native Spring Boot Actuator directly relying on the HealthIndicator interface.\nSecurity alert From SOFABoot 2.3.0 on, the Health Check depends on the Actuator component in SpringBoot 1.4.x, and the component opens a lot of EndPoint such as \u0026amp;lsquo;/dump \u0026amp;rsquo; and \u0026amp;lsquo;/trace\u0026amp;rsquo;. So there may be a security risk. Refer to the Security Recommendations in the official document for settings.\nSpringBoot 1.5.x and SpringBoot 2.x. have fixed some security issues. SOFABoot will be supported by upgrading the SpringBoot kernel.\nView Health Check results After adding the Health Check extension, you can directly browser http://localhost:8080/health/readiness to view the Readiness Check results. To view the Liveness Check results, access the URL of the Spring Boot Health Check results. http://localhost:8080/health。\nIn SOFABoot, you can also view Health Check results by checking the specific logs in the health-check directory. Generally, such logs contain the following content:\n2018-04-06 23:29:50,240 INFO main - Readiness check result: success At present, the SOFA middleware has controlled upstream traffic access through the Readiness Check offered by SOFABoot. But, apart from the middleware, traffic of an application may come from other sources such as the load balancer. To control such traffic, users are advised to view the Readiness Check results by PAAS and determine whether to launch corresponding nodes in the load balancer based on the results.\n** Note: Versions after SOFABoot 2.x no longer indirectly introduce spring-boot-starter-web dependencies. To view Health Check results in the browser, you need to introduce Web container dependencies in the project. **\n** Note: In SOFABoot 3.x, the endpoint path has been changed from health/readiness to actuator/readiness**\nReadiness Check extension SOFABoot allows extension in every phase of the Readiness Check. Applications can be extended according to their needs. In version 2.x, the extendable points are as follows:\n Callback interface Description org.springframework.context.ApplicationListener If you want to do something before the Readiness Check, you can monitor the SofaBootBeforeHealthCheckEvent event of this listener. org.springframework.boot.actuate.health.HealthIndicator If you want to add a check item to the Readiness Check in SOFABoot, you can directly extend this interface of Spring Boot. …","date":-62135596800,"description":"","dir":"projects/sofa-boot/health-check/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a366b25125fa4aedb08a9cef572db1c8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/health-check/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/health-check/","summary":"SOFABoot provides Readiness Check to enhance Spring Boot\u0026rsquo;s Health Check. If you need to use the SOFA middleware, you are advised to use the Health Check extension of SOFABoot to launch application examples in a more elegant way.\nEnable Health Check To enable the Health Check feature in SOFABoot, you only need to import the following starter:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;healthcheck-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Without the Health Check extension, users still can perform Liveness Check with native Spring Boot Actuator directly relying on the HealthIndicator interface.","tags":null,"title":"Health check","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/health-check/","wordcount":707},{"author":null,"categories":null,"content":" Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to the article Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing an ACTS bug or adding an ACTS feature, submit an issue on ACTS GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The ACTS maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All ACTS modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step.\nGit clone https://github.com/your account name/acts.git Pull a branch to prepare for code modification.\ngit branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\n git branch -a If you want to switch back to the master branch, execute the following command:\n git checkout -b master If you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\n After modifying the code, execute the following command to submit all modifications to your local repository:\ngit commit -am \u0026#39;Add xx feature\u0026#39; When modifying the code, note the following: Keep the code style consistent. ACTS uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Supplement unit test code.\n New modifications should have passed existing unit tests.\n Provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. Execute the following command to run all tests:\nmvn clean test You can also use the IDE to help run a test.\nOther do\u0026amp;rsquo;s and …","date":-62135596800,"description":"","dir":"projects/sofa-acts/contributing/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"cd68baede6258921f83665ef0a446f1f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/contributing/","summary":"Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to the article Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing an ACTS bug or adding an ACTS feature, submit an issue on ACTS GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/contributing/","wordcount":808},{"author":null,"categories":null,"content":" We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submitting an issue Regardless of whether you are fixing a SOFADashboard bug or adding a SOFADashboard feature, submit an issue on SOFADashboard GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.\nThere are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFADashboard maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All SOFADashboard modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-dashboard.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to the branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFADashboard uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Add the unit test code.\n Modifications should have passed existing unit tests.\n You should provide a new unit test to prove that the previous code has bugs and the bugs\nhave been fixed in the new code. You can execute the following code to run all tests:\n mvn clean test You can also use the IDE to help run a test. …","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/contribution/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"584584be9c13f2d36c85890dd192368a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/contribution/","summary":"We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/contribution/","wordcount":837},{"author":null,"categories":null,"content":" We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of git tools, refer to official books on gitand get familiarized by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFARegistry bug or adding a SOFARegistry feature, submit an issue on the SOFARegistry GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFARegistry maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All SOFARegistry modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review.\nTherefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-registry.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command:\ngit branch -a If you want to switch back to the master branch, execute the following command:\ngit checkout -b master If you want to switch back to the branch, execute the following command:\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFARegistry uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Add the unit test code. Modifications should have passed existing unit tests. You should provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. You can execute the following code to run all tests: mvn clean test You can also use the IDE to help run a test.\nOther do\u0026amp;rsquo;s …","date":-62135596800,"description":"","dir":"projects/sofa-registry/contributing/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c08b5945719137833634c111c43a8d9e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/contributing/","summary":"We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of git tools, refer to official books on gitand get familiarized by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFARegistry bug or adding a SOFARegistry feature, submit an issue on the SOFARegistry GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/contributing/","wordcount":839},{"author":null,"categories":null,"content":" How to contribute SOFABolt\u0026amp;rsquo;s code is open source. You can submit your contributions to the code after signing the required agreement.\nContributor License Agreement Alterations and modifications made to SOFABolt\u0026amp;rsquo;s code must comply with the Contributor License Agreement.\nPrerequisites Before contributing any code, you need to know how to use the Git tool and the GitHub website.\nFor the use of Git tools, refer to the official Pro Git book and get familiar with the tools by reading the first few chapters.\nFor the Git collaboration process, refer to Git Workflows.\nGitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a Bolt bug or adding a Bolt feature, submit an issue on the Bolt GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The Bolt maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the Bolt\u0026amp;rsquo;s master branch code to your code repository.\nPull a branch All Bolt modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with the getting source code step, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/sofastack/sofa-bolt.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to your branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; If you want to directly pull a branch from GitHub, execute the following command: git clone -b branchname https://xxx.git Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. Bolt uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally. mvn clean package Add the unit test code. Modifications should have passed existing unit …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-contribution/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c044ad534cf99e4d6d400113b490f816","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","summary":"How to contribute SOFABolt\u0026rsquo;s code is open source. You can submit your contributions to the code after signing the required agreement.\nContributor License Agreement Alterations and modifications made to SOFABolt\u0026rsquo;s code must comply with the Contributor License Agreement.\nPrerequisites Before contributing any code, you need to know how to use the Git tool and the GitHub website.\nFor the use of Git tools, refer to the official Pro Git book and get familiar with the tools by reading the first few chapters.","tags":null,"title":"How to contribute to SOFABolt","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","wordcount":1140},{"author":null,"categories":null,"content":" Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFAJRaft bug or adding a SOFAJRaft feature, submit an issue on the SOFAJRaft GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFAJRaft maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch We recommend that you first read the SOFAJRaft Branch management policy.\nAll SOFAJRaft modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-jraft Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to the branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFAJRaft uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally. mvn clean compile Add the unit test code.\n New modifications should have passed existing unit tests.\n Provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. Execute the following command to run all tests:\n mvn clean test You can also use the IDE to help execute a command.\nOther do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original style of the …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"99034715298f73cd835672b872141609","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","summary":"Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFAJRaft bug or adding a SOFAJRaft feature, submit an issue on the SOFAJRaft GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute to SOFAJRaft","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","wordcount":841},{"author":null,"categories":null,"content":" Http 协议基本使用 在 SOFARPC (非SOFABoot 环境)中，当使用Http作为服务端协议的时候，支持Json作为序列化方式，作为一些基础的测试方式使用。\nSOFARPC API 使用 发布服务 // 只有1个线程 执行 ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); // 发布一个服务，每个请求要执行1秒 ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026amp;quot;serverApp\u0026amp;quot;)) .setServer(serverConfig) .setUniqueId(\u0026amp;quot;uuu\u0026amp;quot;) .setRegister(false); providerConfig.export(); 服务引用 因为是Http+Json，所以引用方可以直接通过HttpClient进行调用,以下为一段测试代码。\nprivate ObjectMapper mapper = new ObjectMapper(); HttpClient httpclient = HttpClientBuilder.create().build(); // POST 正常请求 String url = \u0026amp;quot;http://127.0.0.1:12300/com.alipay.sofa.rpc.server.http.HttpService:uuu/object\u0026amp;quot;; HttpPost httpPost = new HttpPost(url); httpPost.setHeader(RemotingConstants.HEAD_SERIALIZE_TYPE, \u0026amp;quot;json\u0026amp;quot;); ExampleObj obj = new ExampleObj(); obj.setId(1); obj.setName(\u0026amp;quot;xxx\u0026amp;quot;); byte[] bytes = mapper.writeValueAsBytes(obj); ByteArrayEntity entity = new ByteArrayEntity(bytes, ContentType.create(\u0026amp;quot;application/json\u0026amp;quot;)); httpPost.setEntity(entity); HttpResponse httpResponse = httpclient.execute(httpPost); Assert.assertEquals(200, httpResponse.getStatusLine().getStatusCode()); byte[] data = EntityUtils.toByteArray(httpResponse.getEntity()); ExampleObj result = mapper.readValue(data, ExampleObj.class); Assert.assertEquals(\u0026amp;quot;xxxxx\u0026amp;quot;, result.getName()); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http-json/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"28abdf6369247346bad670c639a422b8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/http-json/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/http-json/","summary":"Http 协议基本使用 在 SOFARPC (非SOFABoot 环境)中，当使用Http作为服务端协议的时候，支持Json作为序列化方式，作为一些基础的测试方式使用。","tags":null,"title":"Http 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/http-json/","wordcount":242},{"author":null,"categories":null,"content":" HttpClient Integration In this document will demonstrate how to use SOFATracer to track of HttpClient, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;!-- SOFATracer dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- HttpClient dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 4.5.X --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpasyncclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 4.X --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.1.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer under the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the current application name and logging.path that specifies the log output directory.\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs Add a Controller that provides RESTful service @RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8080/httpclient?name= * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/httpclient\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;httpclient\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } Construct HttpClient to initiate a call to the RESTful service above The code example is as follows:\n Construct an HttpClient synchronous call instance: HttpClientBuilder httpClientBuilder = HttpClientBuilder.create(); // SOFATracer SofaTracerHttpClientBuilder.clientBuilder(httpClientBuilder); CloseableHttpClient httpClient = httpClientBuilder.setConnectionManager(connManager).disableAutomaticRetries() .build(); Construct an HttpClient asynchronous call instance: RequestConfig requestConfig = RequestConfig.custom().setSocketTimeout(6000).setConnectTimeout(6000).setConnectionRequestTimeout(6000).build(); HttpAsyncClientBuilder httpAsyncClientBuilder = HttpAsyncClientBuilder.create(); //tracer SofaTracerHttpClientBuilder.asyncClientBuilder(httpAsyncClientBuilder); CloseableHttpAsyncClient asyncHttpclient = httpAsyncClientBuilder.setDefaultRequestConfig(requestConfig).build(); When you construct the HttpClient via the SofaTracerHttpClientBuilder (clientBuilder method for synchronous call instance, and asyncClientBuilder method for asynchronous call instance) to initiate a call to the RESTful service above, the link data of …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-httpclient/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3efb3d0d5bd884665537aa974ec21359","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","summary":"HttpClient Integration In this document will demonstrate how to use SOFATracer to track of HttpClient, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;!-- SOFATracer dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- HttpClient dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.apache.httpcomponents\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;httpclient\u0026lt;/artifactId\u0026gt; \u0026lt;!-- 4.5.X --\u0026gt; \u0026lt;version\u0026gt;4.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.apache.httpcomponents\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;httpasyncclient\u0026lt;/artifactId\u0026gt; \u0026lt;!-- 4.X --\u0026gt; \u0026lt;version\u0026gt;4.1.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer under the project\u0026rsquo;s application.","tags":null,"title":"HttpClient Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","wordcount":498},{"author":null,"categories":null,"content":" HttpClient Log Format After integrating tracer-httpclient-plugin, SOFATracer outputs the link data requested by HttpClient in JSON data by default.\nHttpClient digest log (httpclient-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.code HTTP call returns status code req.size.bytes Request body size resp.size.bytes Response body size Time.cost.milliseconds Request time (ms) Current.thread.name Thread name Remote.app Name of the called application Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-27 21:58:43.067\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8801538056723034100235072\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:33,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;I/O dispatcher 1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Note: The application name can be passed in as a parameter when constructing an HttpClient instance via SofaTracerHttpClientBuilder.\nHttpClient statistical Log (httpclient-stat.log) stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success (the result code starting with 1 and 2 indicates success, and 302 indicates that the redirection is successful, and others indicate failure); N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-27 21:59:42.233\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:562,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-httpclient/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7df3d68ba21f1b2a43c0265fdc4eae3e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","summary":"HttpClient Log Format After integrating tracer-httpclient-plugin, SOFATracer outputs the link data requested by HttpClient in JSON data by default.\nHttpClient digest log (httpclient-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.","tags":null,"title":"HttpClient log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","wordcount":220},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 HttpClient 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;!-- SOFATracer 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- HttpClient 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 版本 4.5.X 系列 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpasyncclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 版本 4.X 系列 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.1.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8080/httpclient?name= * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/httpclient\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;httpclient\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } 构造 HttpClient 发起一次对上文的 RESTful 服务的调用 代码示例如下：\n 构造 HttpClient 同步调用实例： HttpClientBuilder httpClientBuilder = HttpClientBuilder.create(); //SOFATracer SofaTracerHttpClientBuilder.clientBuilder(httpClientBuilder); CloseableHttpClient httpClient = httpClientBuilder.setConnectionManager(connManager).disableAutomaticRetries() .build(); 构造 HttpClient 异步调用实例： RequestConfig requestConfig = RequestConfig.custom().setSocketTimeout(6000).setConnectTimeout(6000).setConnectionRequestTimeout(6000).build(); HttpAsyncClientBuilder httpAsyncClientBuilder = HttpAsyncClientBuilder.create(); //tracer SofaTracerHttpClientBuilder.asyncClientBuilder(httpAsyncClientBuilder); CloseableHttpAsyncClient asyncHttpclient = httpAsyncClientBuilder.setDefaultRequestConfig(requestConfig).build(); 通过 SofaTracerHttpClientBuilder(clientBuilder 方法构造同步，asyncClientBuilder 方法构造异步) 构造的 HttpClient 在发起对上文的 RESTful 服务调用的时候，就会埋点 SOFATracer 的链路的数据。\n运行 启动 SOFABoot 应用，在控制台中看到启动打印的日志如下：\n2018-09-27 20:31:21.465 INFO 33277 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-09-27 20:31:21.599 INFO 33277 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-09-27 20:31:21.608 INFO 33277 --- [ main] c.a.s.t.e.h.HttpClientDemoApplication : Started HttpClientDemoApplication in 5.949 seconds (JVM running for 6.573) 当有类似如下的日志时，说明 HttpClient 的调用成功：\n2018-09-27 20:31:22.336 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-httpclient/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3efb3d0d5bd884665537aa974ec21359","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","summary":"在本文档将演示如何使用 SOFATracer 对 HttpClient 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;!-- SOFATracer 依","tags":null,"title":"HttpClient 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","wordcount":748},{"author":null,"categories":null,"content":" SOFATracer 集成 sofa-tracer-httpclient-plugin 插件后输出 HttpClient 请求的链路数据，默认为 JSON 数据格式。\nHttpClient 摘要日志（httpclient-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:43:13.191\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e27a79c1567438993170100210107\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;I/O dispatcher 1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;21ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} 备注：应用名称可以通过 SofaTracerHttpClientBuilder 构造 HttpClient 实例时以入参的形式传入。\nHttpClient 统计日志（httpclient-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功(1 开头和 2 开头的结果码算是成功的，302表示的重定向算成功，其他算是失败的)；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:44:11.785\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:229,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-httpclient/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7df3d68ba21f1b2a43c0265fdc4eae3e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","summary":"SOFATracer 集成 sofa-tracer-httpclient-plugin 插件后输出 HttpClient 请求的链路数据，默认为 JSON 数据格式。 HttpClient 摘要日志（httpclient-digest.log） 以 JSON 格式输出的数据，相应 key 的含","tags":null,"title":"HttpClient 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","wordcount":407},{"author":null,"categories":null,"content":" SOFARPC is integrated Hystrix provides fuse capability and is currently available in the first preview version. More information about Hystrix can be found in Hystrix Official Documentation, Hystrix integration capabilities are provided primarily by ScienJus, thanks for contribution.\nNext, let\u0026amp;rsquo;s talk about how to experience the fuse capability of Hystrix. The following example uses the SOFARPC 5.5.0 version. More Hystrix configuration and SOFABoot integration usage will be provided in subsequent releases, so stay tuned.\nWork preparation The Hystrix module is not loaded directly as an optional module by default. If you need to use it, you need to actively add the Hystrix maven dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; By explicitly opening Hystrix by configuration, HystrixFilter will be loaded automatically:\n// Open globally RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // Open for a specific Consumer ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); FallbackFactory The FallbackFactory interface mainly provides the injection capability of the Fallback implementation, which is used to automatically perform the degraded logic when Hystrix executes an exception (throws an exception, timeout, thread pool rejection, and blown).\nDefine the interface Fallback implementation:\npublic class HelloServiceFallback implements HelloService { @Override public String sayHello(String name, int age) { return \u0026amp;quot;fallback \u0026amp;quot; + name + \u0026amp;quot; from server! age: \u0026amp;quot; + age; } } Inject Fallback implementation:\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); // You can directly inject Fallback implementation directly using the default FallbackFactory SofaHystrixConfig.registerFallback(consumerConfig, new HelloServiceFallback()); // You can also customize FallbackFactory to directly inject FallbackFactory SofaHystrixConfig.registerFallbackFactory(consumerConfig, new HelloServiceFallbackFactory()); When the server responds with a failure, the client automatically triggers the Fallback logic execution.\nSetterFactory SetterFactory provides Hystrix fine-grained configuration capabilities. SOFARPC has provided the default DefaultSetterFactory to generate the Setter for each caller. If there is a more customized description, it can also be provided for each ConsumerConfig. Customize SetterFactory.\nSofaHystrixConfig.registerSetterFactory(consumerConfig, new CustomSetterFactory()); In the implementation provided by default, GroupKey is InterfaceId, and CommandKey is the …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-hystrix/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7482dc341bf16dd5671634ffa689604a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","summary":"SOFARPC is integrated Hystrix provides fuse capability and is currently available in the first preview version. More information about Hystrix can be found in Hystrix Official Documentation, Hystrix integration capabilities are provided primarily by ScienJus, thanks for contribution.\nNext, let\u0026rsquo;s talk about how to experience the fuse capability of Hystrix. The following example uses the SOFARPC 5.5.0 version. More Hystrix configuration and SOFABoot integration usage will be provided in subsequent releases, so stay tuned.","tags":null,"title":"Hystrix fault tolerance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","wordcount":335},{"author":null,"categories":null,"content":" SOFARPC 已集成 Hystrix 提供熔断能力，当前提供第一个预览版。关于 Hystrix 的更多介绍可以参考 Hystrix 官方文档，Hystrix 集成能力主要由 ScienJus 提供，感谢贡献。\n接下来介绍一下如何体验 Hystrix 带来的熔断能力，以下示例使用 SOFARPC 5.5.0 版本，更多 Hystrix 的配置及 SOFABoot 集成使用方式将在后续版本提供，敬请关注。\n准备工作 Hystrix 模块作为可选模块默认不会直接加载，如需要使用，需要先主动加入 Hystrix maven 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 通过配置显式开启 Hystrix，将会自动加载 HystrixFilter：\n// 全局开启 RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // 对特定 Consumer 开启 ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); FallbackFactory FallbackFactory 接口主要提供 Fallback 实现的注入能力，用于在 Hystrix 执行出现异常（抛出异常、超时、线程池拒绝和熔断等）时自动执行降级逻辑。\n定义接口 Fallback 实现：\npublic class HelloServiceFallback implements HelloService { @Override public String sayHello(String name, int age) { return \u0026amp;quot;fallback \u0026amp;quot; + name + \u0026amp;quot; from server! age: \u0026amp;quot; + age; } } 注入 Fallback 实现：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); // 可以直接使用默认的 FallbackFactory 直接注入 Fallback 实现 SofaHystrixConfig.registerFallback(consumerConfig, new HelloServiceFallback()); // 也可以自定义 FallbackFactory 直接注入 FallbackFactory SofaHystrixConfig.registerFallbackFactory(consumerConfig, new HelloServiceFallbackFactory()); 当服务端响应失败时，客户端会自动触发 Fallback 逻辑执行。\nSetterFactory SetterFactory 提供 Hystrix 细粒度配置能力，SOFARPC 已提供默认的 DefaultSetterFactory 来生成每个调用方对应的 Setter，如有更定制化的述求，也可以针对每个 ConsumerConfig 提供自定义 SetterFactory。\nSofaHystrixConfig.registerSetterFactory(consumerConfig, new CustomSetterFactory()); 默认提供的实现中 GroupKey 为 InterfaceId，CommandKey 为方法的名称。\n支持 Hystrix 的版本信息 SOFARPC: 5.5.0, SOFABoot: 2.5.3。\nSOAF RPC 集成验证 Hystrix 版本：1.5.12。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-hystrix/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7482dc341bf16dd5671634ffa689604a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault-hystrix/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault-hystrix/","summary":"SOFARPC 已集成 Hystrix 提供熔断能力，当前提供第一个预览版。关于 Hystrix 的更多介绍可以参考 Hystrix 官方文档，Hystrix 集成能力主要由 ScienJus 提供，感谢贡献。 接下来介绍一","tags":null,"title":"Hystrix 客户端熔断","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault-hystrix/","wordcount":552},{"author":null,"categories":null,"content":" Installation guide To use Istio in a non-Kubernetes environment, you must complete the following critical tasks first:\n Configure the Istio API server for the Istio control plane. You can also use MemStore to launch Pilot for demonstration purpose. Manually add SOFAMosn to all microservice instances and start in SideCar mode. Make sure that all requests are routed through SOFAMosn. Set control plane The Istio control plane consists of four main services: Pilot, Mixter, Citadel, and API server.\nAPI server Istio\u0026amp;rsquo;s API server, which is based on Kubernetes API server, provides configuration management and role-based access control. The API server requires an etcd cluster as the underlying persistent storage.\nInstall locally Use the following Docker compose file to install an API server for POC:\nversion: \u0026#39;2\u0026#39; services: etcd: image: quay.io/coreos/etcd:latest networks: default: aliases: - etcd ports: - \u0026amp;quot;4001:4001\u0026amp;quot; - \u0026amp;quot;2380:2380\u0026amp;quot; - \u0026amp;quot;2379:2379\u0026amp;quot; environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;/usr/local/bin/etcd\u0026amp;quot;, \u0026amp;quot;-advertise-client-urls=http://0.0.0.0:2379\u0026amp;quot;, \u0026amp;quot;-listen-client-urls=http://0.0.0.0:2379\u0026amp;quot; ] istio-apiserver: image: gcr.io/google_containers/kube-apiserver-amd64:v1.7.3 networks: default: aliases: - apiserver ports: - \u0026amp;quot;8080:8080\u0026amp;quot; privileged: true environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;kube-apiserver\u0026amp;quot;, \u0026amp;quot;--etcd-servers\u0026amp;quot;, \u0026amp;quot;http://etcd:2379\u0026amp;quot;, \u0026amp;quot;--service-cluster-ip-range\u0026amp;quot;, \u0026amp;quot;10.99.0.0/16\u0026amp;quot;, \u0026amp;quot;--insecure-port\u0026amp;quot;, \u0026amp;quot;8080\u0026amp;quot;, \u0026amp;quot;-v\u0026amp;quot;, \u0026amp;quot;2\u0026amp;quot;, \u0026amp;quot;--insecure-bind-address\u0026amp;quot;, \u0026amp;quot;0.0.0.0\u0026amp;quot; ] Other control plane components Currently, SOFAMosn hasn\u0026amp;rsquo;t integrated with the components other than Pilot, so you don\u0026amp;rsquo;t need to install Mixer, Citadel and other components.\nAdd SOFAMosn Sidecar to microservice instances Every microservice application instance must have an associated SOFAMosn instance.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-installation/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4c0bd56673dc8aebef9011a22496392d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","summary":"Installation guide To use Istio in a non-Kubernetes environment, you must complete the following critical tasks first:\n Configure the Istio API server for the Istio control plane. You can also use MemStore to launch Pilot for demonstration purpose. Manually add SOFAMosn to all microservice instances and start in SideCar mode. Make sure that all requests are routed through SOFAMosn. Set control plane The Istio control plane consists of four main services: Pilot, Mixter, Citadel, and API server.","tags":null,"title":"Installation guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","wordcount":221},{"author":null,"categories":null,"content":" Project address\n Introduction SOFABoot extends the Health Check of Spring Boot. For detailed information, see SOFABoot Documentation. This sample project is intended to demonstrate how to integrate the Health Check component of SOFABoot during merged deployment. Differences between the Health Check in merged deployment and that of a single SOFABoot application are as follows: + During static merged deployment, all Biz packages must pass the Health Check before the Ark package can be started normally. + When deploying the Biz packages dynamically in Jarslink2.0, all packages must pass the Health Check before successful deployment. + In merged deployment, a new check item named multiApplicationHealthChecker will be added when you access Spring Boot\u0026amp;rsquo;s default /health. The item is used to check the health of all Biz packages. Only after all Biz packages pass the Health Check can the merged package pass the Health Check.\nDependency To integrate the Health Check capability of SOFABoot in merged deployment, you need to add the following dependencies:\n\u0026amp;lt;!--health check--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note that spring-boot-starter-web is excluded to avoid starting multiple web applications when you introduce the healthcheck-sofa-boot-starter dependency.\nDemo cd biz-health-check-sample/app-one \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-one root directory and package the application into an Ark or Biz package. The file will be exported to the biz-health-check-sample/app-one/target directory.\n cd biz-health-check-sample/app-two \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-two root directory and package the application into an Ark or Biz package. The file will be exported to the biz-health-check-sample/app-two/target directory.\n Use java -jar to start the Ark package for app-one.\n After the Ark package has started, visit http://localhost:8080/health in the browser. This is Spring Boot\u0026amp;rsquo;s default Health Check endpoint. A new check item named multiApplicationHealthChecker is added in the results and there is now only one Biz package. The page is displayed as follows: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"99832d969ec54b925c3dca1205b95165","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","summary":"Project address\n Introduction SOFABoot extends the Health Check of Spring Boot. For detailed information, see SOFABoot Documentation. This sample project is intended to demonstrate how to integrate the Health Check component of SOFABoot during merged deployment. Differences between the Health Check in merged deployment and that of a single SOFABoot application are as follows: + During static merged deployment, all Biz packages must pass the Health Check before the Ark package can be started normally.","tags":null,"title":"Integrate SOFABoot health check","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","wordcount":389},{"author":null,"categories":null,"content":" Since rpc-sofa-boot-starter version 6.0.1, SOFARPC provide the ability to integrate RESTful service with Swagger easily.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment and you want to enable Swagger support, first, you need add Swagger dependencies in your pom.xml:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Then you need add a configuration com.alipay.sofa.rpc.restSwagger=true in application.properties.\nFinally, visit http://localhost:8341/swagger/openapi and you can get all the Swagger OpenAPI information about SOFARPC\u0026amp;rsquo;s RESTful services.\nIf you are not using rpc-sofa-boot-starter or the version of rpc-sofa-boot-starter you depends is smaller then 6.0.1, you can integration SOFARPC RESTful service with Swagger by using the following tutorial.\nCurrently, SOFARPC does not provide the ability to integrate RESTful service with Swagger via one click. The ability will be provided in future versions, but you can refer to this document to integrate RESTful service with Swagger in the existing versions of SOFARPC.\nFirst, you need to add Swagger related dependencies into your application. Since SOFARPC\u0026amp;rsquo;s RESTful protocol is based on the JAXRS, so you just need to add Swagger\u0026amp;rsquo;s JAXRS dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; The 20.0 version of Guava was added to resolve Guava version conflict.\nAdd a Swagger RESTful service To enable Swagger to expose SOFARPC\u0026amp;rsquo;s RESTful services through Swagger OpenAPI, we can provide Swagger\u0026amp;rsquo;s OpenAPI services through SOFARPC\u0026amp;rsquo;s RESTful services. First, you need to create a new interface:\n@Path(\u0026amp;quot;swagger\u0026amp;quot;) public interface OpenApiService { @GET @Path(\u0026amp;quot;openapi\u0026amp;quot;) @Produces(\u0026amp;quot;application/json\u0026amp;quot;) String openApi(); } Then provide an implementation class and publish it as a RESTful service of SOFARPC:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}, interfaceType = OpenApiService.class) public class OpenApiServiceImpl implements OpenApiService, InitializingBean { private OpenAPI openAPI; @Override public String openApi() { return Json.pretty(openAPI); } @Override public void afterPropertiesSet() { List\u0026amp;lt;Package\u0026amp;gt; resources = new ArrayList\u0026amp;lt;\u0026amp;gt;(); Resources.add(this.getClass().getPackage()); // Scan the package of the current class, or scan the packages of other SOFARPC RESTful service …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-swagger/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d068767fe0dd2922eecef69736684be8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","summary":"Since rpc-sofa-boot-starter version 6.0.1, SOFARPC provide the ability to integrate RESTful service with Swagger easily.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment and you want to enable Swagger support, first, you need add Swagger dependencies in your pom.xml:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.swagger.core.v3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;swagger-jaxrs2\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.0.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.guava\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;guava\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;20.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Then you need add a configuration com.alipay.sofa.rpc.restSwagger=true in application.properties.\nFinally, visit http://localhost:8341/swagger/openapi and you can get all the Swagger OpenAPI information about SOFARPC\u0026rsquo;s RESTful services.","tags":null,"title":"Integrate with Swagger","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","wordcount":462},{"author":null,"categories":null,"content":"Jarslink2.0 supports receiving dynamic commands at runtime to manage the Biz package lifecycle. Before starting an Ark package that has introduced the Jarslink2.0 plugin, you can send commands through the telnet connection protocol with port 1234. For example, execute telnet ip 1234 to enter the Jarslink2.0 command interface and type \u0026amp;ldquo;help\u0026amp;rdquo; in the interface to obtain all relevant command manuals. Next we will introduce the syntax of each Jarslink2.0 command.\n Install the Biz package: The installation command is used to dynamically deploy of applications. Its syntax is install -b $bizFile. You can replace -b with -biz. All Jarslink2.0 commands must contain either a –b or –biz. The \u0026amp;ldquo;install\u0026amp;rdquo; command has only one parameter, the Biz package URI, which can either be the path of a local file or the link to a remote file, for example, install -b file:///Users/qilong.zql/sample-ark-biz.jar.\n Uninstall the Biz package: The uninstall command is used to close the application. The services released by the application and the resources that it occupied will be destroyed. Command syntax: uninstall -b -n $bizName -v $bizVersion. The command must specify the name and version number of the Biz package by -n and -v, which can be replaced with -name and -version. The name and version number of a Biz package are determined at the time of packaging. For detailed information, see Application Packaging.\n Switch the Biz package: The switch command is used for the Biz package hot update to ensure service continuity. Jarslink2.0 allows loading different versions of Biz packages with the same name at runtime. However, only one Biz package can deliver services at one time. To upgrade the loaded Biz package that is delivering services at runtime, execute the installation command to install a later version of the Biz package. After installation, the newer version is inactive because the older version is providing services. Execute the switch command to switch to the newer version without suspending the services that the application is delivering. This is called a hot update. The command syntax is switch -b -n $bizName -v $bizVersion. Parameters are the same as the above.\n Query the Biz package: The query command is used to query the Biz packages installed in JVM and their status. The command syntax is check -b -n $bizName -v $bizVersion, where the Biz package\u0026amp;rsquo;s name and version number are optional parameters. If you do not specify the name and the version number, information for all Biz packages will be returned. If you only specify the name, information for all versions with the specified name will be returned.\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-instruction/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c7e69fe8035b59c0e191538c8ef3da18","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","summary":"Jarslink2.0 supports receiving dynamic commands at runtime to manage the Biz package lifecycle. Before starting an Ark package that has introduced the Jarslink2.0 plugin, you can send commands through the telnet connection protocol with port 1234. For example, execute telnet ip 1234 to enter the Jarslink2.0 command interface and type \u0026ldquo;help\u0026rdquo; in the interface to obtain all relevant command manuals. Next we will introduce the syntax of each Jarslink2.0 command.","tags":null,"title":"Interactive instruction","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","wordcount":424},{"author":null,"categories":null,"content":" Introduction Jarslink2.0 is a functional SOFABoot plugin developed based on SOFAArk. It manages the merged deployment of multiple applications on top of the SOFAArk container, with the following features: + It supports runtime dynamic installation and uninstallation of applications. + It supports runtime application hot replacement capability to ensure service continuity. + For cross-application communication, it supports the JVM services publish and reference. Cross-application communication can base on RPC framework or internal JVM services. + It supports application Health Check.\nBackground At Ant Financial, it is common to deploy multiple applications on top of the same JVM. Main advantages of this approach are as follows:\n Merged deployment of unrelated applications: Some applications have no service dependencies on each other when they are deployed independently and their volume of business is small, so it would be a waste of resources to start the Java Virtual Machine just for them. Merged deployment of these applications can save resources.\n Merged deployment of related applications: Some applications have service dependencies between them. When deployed independently, RPC calls are used between applications. Despite the high stability of the distributed architecture, there are still delays caused by network jitter. By merged deployment of these applications, JVM internal calls will replace RPC calls, which reduces the call overhead.\n Not only is there merged deployment between applications, but the near-client package has the same appeal.\nThe near-client package is a three-party component that provides a series of public services, normally introduced by the application as a dependency. This development mode is likely to cause two problems:\n The three-party dependency that is introduced by the near-client package conflicts with the dependency of the application itself, so an isolated deployment is expected.\n Since the near-client package is introduced by the application as a dependency, any upgrade of the near-client package will require upgrade of the application as well. However, as a common functional component, many business applications rely on the near-client package as a dependency, which entails a huge amount of transformation. Consequently, a dynamic upgrade of the near-client package is expected.\n In addition to merged deployment, many Ant Financial business scenarios require hot deployment of modules, that is, when the application is running, a specific module needs to be dynamically replaced without affecting the normal running of other modules.\nJarslink2.0 is designed to solve such problems. It is an Ark Plugin developed based on SOFAArk and used to manage the merged deployment of multiple applications. Before getting to know Jarslink2.0, you need to understand the SOFAArk framework. For detailed information of SOFAArk, visit the link.\nPrinciple Jarslink2.0 is an Ark Plugin developed based on SOFAArk. Assuming that you …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-readme/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"48a4bc23f10f1ecca3960aecfd0a77d5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","summary":"Introduction Jarslink2.0 is a functional SOFABoot plugin developed based on SOFAArk. It manages the merged deployment of multiple applications on top of the SOFAArk container, with the following features: + It supports runtime dynamic installation and uninstallation of applications. + It supports runtime application hot replacement capability to ensure service continuity. + For cross-application communication, it supports the JVM services publish and reference. Cross-application communication can base on RPC framework or internal JVM services.","tags":null,"title":"Introduction to Jarslink","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","wordcount":651},{"author":null,"categories":null,"content":" Pilot introduction The SOFAMesh project forked the Istio project to enhance Pilot\u0026amp;rsquo;s capabilities. Currently, the ongoing enhancements are focused on the following three areas:\n Support ZooKeeper as a registry center, and support SOFA, DUBBO and other microservice frameworks using ZooKeeper as a registry center. Support the common protocol framework. Use a common protocol, and support multiple protocols simultaneously based on Kubernetes DNS. Add register agent to support the container models of SOFA, Dubbo and HSF. Namely, a single application can register multiple service instances. ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-readme/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7b098e394986596d8fb01e1fe2120829","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","summary":"Pilot introduction The SOFAMesh project forked the Istio project to enhance Pilot\u0026rsquo;s capabilities. Currently, the ongoing enhancements are focused on the following three areas:\n Support ZooKeeper as a registry center, and support SOFA, DUBBO and other microservice frameworks using ZooKeeper as a registry center. Support the common protocol framework. Use a common protocol, and support multiple protocols simultaneously based on Kubernetes DNS. Add register agent to support the container models of SOFA, Dubbo and HSF.","tags":null,"title":"Introduction to Pilot","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","wordcount":84},{"author":null,"categories":null,"content":" ## Product description SOFAArk is a light-weight，java based classloader isolation framework open sourced by Ant Financial. Based on Fat Jar technology, the container can pack simple single-module Java applications or Spring Boot applications into a self-contained executable Fat Jar, known as an Ark package. When the java -jar command is used to start an Ark package embedded with the SOFAArk class isolation container, the SOFAArk container will start, and it then starts each Ark plugin and application.\nBackground In Java world, dependency is always a problem, and can cause various errors, such as LinkageError, NoSuchMethodError etc. There are many ways to solve the dependency problems, the Spring Boot\u0026amp;rsquo;s way is using a dependency management to manage all the dependencies, make sure that all the dependencies in the dependency management will not conflict and can work pretty well. This is quite a simple and efficient way, it can cover most scenario, but there is some exceptions.\nFor example, there is a project that need protobuf version 2 and protobuf version 3, and because protobuf version 3 is not compatible with version 2, so the project can not simply upgrade the protobuf to version 3 to solve the problem. There is same problem for hessian version 3 and version 4.\nTo cover those exceptions, we need to introduce a classloader isolation way, make different version of a framework loaded by different classloader. There are many framework that can do classloader isolation, perhaps the most famous one is OSGi, but OSGi classloader schema is too complex, beside classloader isolation, it also has ability to do hot deploy and a lot of other functionalities that we actually don\u0026amp;rsquo;t want.\nSo this is the origin of SOFAArk, it\u0026amp;rsquo;s goal is to use a light-weight classloader isolation mechanism to solve the problem that Spring Boot did not solve. And just a remind that SOFAArk is not bind to Spring Boot, actually it is a more general classloader isolation framework that can be used with any other frameworks too.\nHow SOFAArk Works There are three concepts in SOFAArk: Ark Container, Ark-Plugin and Ark-Biz; they are organized as what the following graph shows:\nFirst of all, we explain what roles these concepts play;\n Ark Container: It\u0026amp;rsquo;s the runtime manager of total framework; it will startup in the first place, then it resolves Ark Plugin and Ark Biz in classpath and deploys them.\n Ark Plugin: A fat jar packaged by sofa-ark-plugin-maven-plugin, generally it would bring with a class-index configuration which describes what class would be exported and imported. Ark Plugin can resolve classes from each other.\n Ark Biz: A fat jar packaged by sofa-ark-maven-plugin, it mainly contains all staff what a project need in runtime. Ark Biz can resolve classes form Ark Plugin, but not inverse.\n In runtime, Ark Container would automatically recognize Ark-Plugin and Ark-Biz in classpath, and load them with the independent classloader. According to …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-readme/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"cdb6729fc7a63954b7559c8ea319f550","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","summary":"## Product description SOFAArk is a light-weight，java based classloader isolation framework open sourced by Ant Financial. Based on Fat Jar technology, the container can pack simple single-module Java applications or Spring Boot applications into a self-contained executable Fat Jar, known as an Ark package. When the java -jar command is used to start an Ark package embedded with the SOFAArk class isolation container, the SOFAArk container will start, and it then starts each Ark plugin and application.","tags":null,"title":"Introduction to SOFAArk","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","wordcount":642},{"author":null,"categories":null,"content":" MOSN, the short name of Modular Observable Smart Network, is a powerful proxy acting as Service Mesh\u0026amp;rsquo;s data plane like Envoy but written in Go. MOSN supports Envoy and Istio\u0026amp;rsquo;s APIs and can be integrated with Istio, so we use MOSN instead of Envoy in SOFAMesh. The initial version of MOSN was jointly contributed by Ant Financial and UC Business Unit of Alibaba, and we look forward to the community to participate in the follow-up development and build an open source excellent project together.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/sofa-mosn-readme/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"11219bb3b9689ec5f328b8281bd62a95","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","summary":"MOSN, the short name of Modular Observable Smart Network, is a powerful proxy acting as Service Mesh\u0026rsquo;s data plane like Envoy but written in Go. MOSN supports Envoy and Istio\u0026rsquo;s APIs and can be integrated with Istio, so we use MOSN instead of Envoy in SOFAMesh. The initial version of MOSN was jointly contributed by Ant Financial and UC Business Unit of Alibaba, and we look forward to the community to participate in the follow-up development and build an open source excellent project together.","tags":null,"title":"Introduction to SOFAMosn","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","wordcount":223},{"author":null,"categories":null,"content":" Introduction to RheaKV RheaKV is a lightweight, distributed, and embedded KV storage library, which is included in the JRaft project as a submodule.\nFeatures\n Embedded: RheaKV is embedded in applications in the form of Jar files. Strong consistency: RheaKV ensures data reliability and consistency based on the multi-raft distributed consensus protocol. Self-driven (not fully implemented at present): RheaKV supports automatic diagnosis, optimization, decision making, and recovery. Monitorable: RheaKV automatically reports meta information and state information by node to the PD. Basic APIs: get, put, and delete; cross-region APIs: scan, batch put, and distributed lock. Architecture design Terms and definitions PD: The global central master node that is responsible for scheduling the entire cluster. A PD server can manage multiple clusters, with each of them isolated by clusterId. The PD server requires separate deployment. Actually, many scenarios do not need automatic cluster management, and RheaKV does not support PD. Store: A physical storage node within a cluster. A store may contain one or more regions. Region: The minimal KV data unit. Each region can be understood as a database partition or database shard, and has a left closed and right open interval [startKey, endKey). Storage design The storage layer adopts a pluggable design and supports both MemoryDB and RocksDB currently: MemoryDB is implemented based on ConcurrentSkipListMap and provides better performance. However, its independent storage capacity is restricted by the memory. RocksDB is suitable for scenarios with large data volumes, because its storage capacity is only restricted by the disk. Strong data consistency is ensured. RheaKV synchronizes data to other replicas with the help of JRaft, and each data change is recorded as a Raft log entry. The log replication feature of Raft ensures all data is securely and reliably synchronized to all nodes within the same Raft group. Scenarios Lightweight state/meta information storage and cluster synchronization Distributed lock service API description Generally, RheaKV APIs are divided into two types: synchronous APIs and asynchronous APIs. Methods whose names start with letter b (block) are synchronous blocking APIs, and the rest are asynchronous APIs. All asynchronous APIs return the same CompletableFuture parameter. The read method may contain another important parameter, that is readOnlySafe. When this parameter is set to true, linearizable read is supported. Read methods that do not contain this parameter provide linearizable read by default.\nget CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key, final boolean readOnlySafe); byte[] bGet(final byte[] key); byte[] bGet(final String key); byte[] bGet(final byte[] key, final boolean …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-rheakv-user-guide/","fuzzywordcount":4100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e6fa7125455982961214dfe82245be4d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":20,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","summary":"Introduction to RheaKV RheaKV is a lightweight, distributed, and embedded KV storage library, which is included in the JRaft project as a submodule.\nFeatures\n Embedded: RheaKV is embedded in applications in the form of Jar files. Strong consistency: RheaKV ensures data reliability and consistency based on the multi-raft distributed consensus protocol. Self-driven (not fully implemented at present): RheaKV supports automatic diagnosis, optimization, decision making, and recovery. Monitorable: RheaKV automatically reports meta information and state information by node to the PD.","tags":null,"title":"JRaft RheaKV user guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","wordcount":4086},{"author":null,"categories":null,"content":" RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 lib， rheaKV 包含在 jraft 项目中，是 jraft 的一个子模块。\n定位与特性\n 嵌入式: jar 包方式嵌入到应用中 强一致性: 基于 multi-raft 分布式一致性协议保证数据可靠性和一致性 自驱动 （目前未完全实现）: 自诊断, 自优化, 自决策, 自恢复 可监控: 基于节点自动上报到PD的元信息和状态信息 基本API: get/put/delete 和跨分区 scan/batch put, distributed lock 等等 架构设计 功能名词 PD: 全局的中心总控节点，负责整个集群的调度，一个 PD server 可以管理多个集群，集群之间基于 clusterId 隔离；PD server 需要单独部署，当然，很多场景其实并不需要自管理，rheaKV 也支持不启用 PD Store: 集群中的一个物理存储节点，一个 store 包含一个或多个 region Region: 最小的 KV 数据单元，可理解为一个数据分区或者分片，每个 region 都有一个左闭右开的区间 [startKey, endKey) 存储设计 存储层为可插拔设计， 目前支持 MemoryDB 和 RocksDB 两种实现： MemoryDB 基于 ConcurrentSkipListMap 实现，有更好的性能，但是单机存储容量受内存限制 RocksDB 在存储容量上只受磁盘限制，适合更大数据量的场景 数据强一致性， 依靠 jraft 来同步数据到其他副本, 每个数据变更都会落地为一条 raft 日志, 通过 raft 的日志复制功能, 将数据安全可靠地同步到同 group 的全部节点中 使用场景 轻量级的状态/元信息存储以及集群同步 分布式锁服务 API 说明 整体上 rheaKV apis 分为异步和同步两类， 其中以 b （block）开头的方法均为同步阻塞方法， 其他为异步方法，异步方法均返回一个 CompletableFuture，对于 read method， 还有一个重要参数 readOnlySafe，为 true 时表示提供线性一致读， 不包含该参数的 read method 均为默认提供线性一致读\nget CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key, final boolean readOnlySafe); byte[] bGet(final byte[] key); byte[] bGet(final String key); byte[] bGet(final byte[] key, final boolean readOnlySafe); byte[] bGet(final String key, final boolean readOnlySafe); String 类型入参，rheaKV 内部提供了更高效的 Utf8String encoder/decoder， 业务 key 为 String 时， 推荐的做法是直接使用 String 参数的接口 不需要线性一致读语义的场景可以将 readOnlySafe 设置为 false， 负载均衡器会优先选择本地调用，本地不能提供服务则轮询选择一台远程机器发起读请求 multiGet CompletableFuture\u0026amp;lt;Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt;\u0026amp;gt; multiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys); CompletableFuture\u0026amp;lt;Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt;\u0026amp;gt; multiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys, final boolean readOnlySafe); Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt; bMultiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys); Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt; bMultiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys, final boolean readOnlySafe); multiGet 支持跨分区查询，rheaKV 内部会自动计算每个 key 的所属分区（region）并行发起调用， 最后合并查询结果 为了可以将 byte[] 放进 HashMap，这里曲线救国，返回值中 Map 的 key 为 ByteArray 对象，是对 byte[] 的一层包装，实现了 byte[] 的 hashCode scan \u0026amp;amp; iterator CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final byte[] startKey, final byte[] endKey); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final String startKey, final String endKey); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final byte[] startKey, final byte[] endKey, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final String startKey, final String endKey, final boolean readOnlySafe); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final byte[] startKey, final byte[] endKey); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final String startKey, final String endKey); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final byte[] startKey, final byte[] endKey, final boolean readOnlySafe); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final String startKey, final String endKey, final boolean readOnlySafe); RheaIterator\u0026amp;lt;KVEntry\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-rheakv-user-guide/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e6fa7125455982961214dfe82245be4d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":13,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","summary":"RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 lib， rheaKV 包含在 jraft 项目中，是 jraft 的一个子模块。 定位与特性 嵌入式: jar 包方式嵌入到应用中 强一致性: 基于 multi-raft 分布","tags":null,"title":"JRaft RheaKV 用户指南","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","wordcount":6408},{"author":null,"categories":null,"content":" 0. Basic concepts Every request submitted by log index to a Raft group is serialized into a log entry. Each log entry has an ID, which monotonically increases within the Raft group, and the log entries are replicated to every Raft node in the group. Term is a long-type number that monotonically increases within the Raft group. You can simply take it as the number of votes. The term of an elected leader is called the leader term. Before this leader steps down, log entries submitted during this period have the same term. 1. Configuration and supporting classes This topic mainly describes the configuration and utility methods and classes. The core objects are:\n Endpoint, which refers to a service address PeerId, which refers to ID of a Raft node Configuration, which refers to the configuration of a Raft group, or a node list in other words. 1.1 Endpoint Endpoint refers to a service address, including the IP address and the port number. Raft nodes must not be started on the IPv4 address 0.0.0.0. The startup IP address must be clearly specified Create a address, and bind it to port 8080 of the local host, as shown in the following example:\nEndpoint addr = new Endpoint(\u0026amp;quot;localhost\u0026amp;quot;, 8080); String s = addr.toString(); // The result is localhost:8080 PeerId peer = new PeerId(); boolean success = peer.parse(s); // Specifies whether parsing the endpoint from a string is supported. The result is true. 1.2 PeerId A PeerId indicates a participant (leader, follower, or candidate) of the Raft protocol. It comprises three elements in the format of ip:port:index, where ip is the IP address of the node, port is the port number, and index is the serial number of the same port. Currently, the index is not used, and is always set to 0. This field is reserved to allow starting different Raft nodes from the same port and to differentiate them by index.\nCreate a PeerId and set the index to 0, the IP to localhost, and the port to 8080:\nPeerId peer = new PeerId(\u0026amp;quot;localhost\u0026amp;quot;, 8080); EndPoint addr = peer.getEndpoint(); // Gets the endpoint of a node int index = peer.getIdx(); // Gets the index of a node, which is always set to 0 currently String s = peer.toString(); // The result is localhost:8080 boolean success = peer.parse(s); // Specifies whether PeerId parsing from a string is supported. The result is true. 1.3 Configuration It refers to the configuration of a Raft group, or a participant list in other words.\nPeerId peer1 = ... PeerId peer2 = ... PeerId peer3 = ... // A Raft group that consists of three nodes Configuration conf = new Configuration(); conf.addPeer(peer1); conf.addPeer(peer2); conf.addPeer(peer3); 1.4 JRaftUtils utility class To enable users conveniently create objects such as Endpoint, PeerId, and Configuration, Jraft provides the JRaftUtils class to help users quickly create the required objects from strings.\nEndpoint addr = JRaftUtils.getEndpoint(\u0026amp;quot;localhost:8080\u0026amp;quot;); PeerId peer = …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-user-guide/","fuzzywordcount":8400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"105dfa34c3b20df1f2c23c112730507d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":39,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","summary":"0. Basic concepts Every request submitted by log index to a Raft group is serialized into a log entry. Each log entry has an ID, which monotonically increases within the Raft group, and the log entries are replicated to every Raft node in the group. Term is a long-type number that monotonically increases within the Raft group. You can simply take it as the number of votes. The term of an elected leader is called the leader term.","tags":null,"title":"JRaft user guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","wordcount":8306},{"author":null,"categories":null,"content":" 1. 基本概念说明 log index 提交到 raft group 中的任务都将序列化为一条日志存储下来，每条日志一个编号，在整个 raft group 内单调递增并复制到每个 raft 节点。 term 在整个 raft group 中单调递增的一个 long 数字，可以简单地认为表示一轮投票的编号，成功选举出来的 leader 对应的 term 称为 leader term，在这个 leader 没有发生变更的阶段内提交的日志都将拥有相同的 term 编号。 2. 配置和辅助类 本节主要介绍 jraft 的配置和辅助工具相关接口和类。核心包括：\n Endpoint 表示一个服务地址。 PeerId 表示一个 raft 参与节点。 Configuration 表示一个 raft group 配置，也就是节点列表。 2.1 地址 Endpoint Endpoint 表示一个服务地址，包括 IP 和端口， raft 节点不允许启动在 0.0.0.0 所有的 IPv4 上，需要明确指定启动的 IP 创建一个地址，绑定在 localhost 的 8080 端口上，如下例：\nEndpoint addr = new Endpoint(\u0026amp;quot;localhost\u0026amp;quot;, 8080); String s = addr.toString(); // 结果为 localhost:8080 PeerId peer = new PeerId(); boolean success = peer.parse(s); // 可以从字符串解析出地址，结果为 true 2.2 节点 PeerId PeerId 表示一个 raft 协议的参与者（leader/follower/candidate etc.)， 它由三元素组成： ip:port:index， IP 就是节点的 IP， port 就是端口， index 表示同一个端口的序列号，目前没有用到，总被认为是 0。预留此字段是为了支持同一个端口启动不同的 raft 节点，通过 index 区分。\n创建一个 PeerId, index 指定为 0， ip 和端口分别是 localhost 和 8080:\nPeerId peer = new PeerId(\u0026amp;quot;localhost\u0026amp;quot;, 8080); Endpoint addr = peer.getEndpoint(); // 获取节点地址 int index = peer.getIdx(); // 获取节点序号，目前一直为 0 String s = peer.toString(); // 结果为 localhost:8080 boolean success = peer.parse(s); // 可以从字符串解析出 PeerId，结果为 true 2.3 配置 Configuration Configuration 表示一个 raft group 的配置，也就是参与者列表：\nPeerId peer1 = ... PeerId peer2 = ... PeerId peer3 = ... // 由 3 个节点组成的 raft group Configuration conf = new Configuration(); conf.addPeer(peer1); conf.addPeer(peer2); conf.addPeer(peer3); 2.4 工具类 JRaftUtils 为了方便创建 Endpoint/PeerId/Configuration 等对象， jraft 提供了 JRaftUtils 来快捷地从字符串创建出所需要的对象：\nEndpoint addr = JRaftUtils.getEndpoint(\u0026amp;quot;localhost:8080\u0026amp;quot;); PeerId peer = JRaftUtils.getPeerId(\u0026amp;quot;localhost:8080\u0026amp;quot;); // 三个节点组成的 raft group 配置，注意节点之间用逗号隔开 Configuration conf = JRaftUtils.getConfiguration(\u0026amp;quot;localhost:8081,localhost:8082,localhost:8083\u0026amp;quot;); 2.5 回调 Closure 和状态 Status Closure 就是一个简单的 callback 接口， jraft 提供的大部分方法都是异步的回调模式，结果通过此接口通知：\npublic interface Closure { /** * Called when task is done. * * @param status the task status. */ void run(Status status); } 结果通过 Status 告知，Status#isOk() 告诉你成功还是失败，错误码和错误信息可以通过另外两个方法获取：\nboolean success= status.isOk(); RaftError error = status.getRaftError(); // 错误码，RaftError 是一个枚举类 String errMsg = status.getErrorMsg(); // 获取错误详情 Status 提供了一些方法来方便地创建：\n// 创建一个成功的状态 Status ok = Status.OK(); // 创建一个失败的错误，错误信息支持字符串模板 String filePath = \u0026amp;quot;/tmp/test\u0026amp;quot;; Status status = new Status(RaftError.EIO, \u0026amp;quot;Fail to read file from %s\u0026amp;quot;, filePath); 2.6 任务 Task Task 是用户使用 jraft 最核心的类之一，用于向一个 raft 复制分组提交一个任务，这个任务提交到 leader，并复制到其他 follower 节点， Task 包括：\n ByteBuffer data 任务的数据，用户应当将要复制的业务数据通过一定序列化方式（比如 java/hessian2) 序列化成一个 ByteBuffer，放到 task 里。 long expectedTerm = -1 任务提交时预期的 leader term，如果不提供(也就是默认值 -1 )，在任务应用到状态机之前不会检查 leader 是否发生了变更，如果提供了（从状态机回调中获取，参见下文），那么在将任务应用到状态机之前，会检查 term 是否匹配，如果不匹配将拒绝该任务。 Closure done 任务的回调，在任务完成的时候通知此对象，无论成功还是失败。这个 closure 将在 StateMachine#onApply(iterator) 方法应用到状态机的时候，可以拿到并调用，一般用于客户端应答的返回。 创建一个简单 Task 实例：\nClosure done = ...; Task task = new …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-user-guide/","fuzzywordcount":13200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"105dfa34c3b20df1f2c23c112730507d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":27,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","summary":"1. 基本概念说明 log index 提交到 raft group 中的任务都将序列化为一条日志存储下来，每条日志一个编号，在整个 raft group 内单调递增并复制到每个 raft 节点。 term 在整个 raft group 中单","tags":null,"title":"JRaft 用户指南","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","wordcount":13134},{"author":null,"categories":null,"content":" SOFABoot 提供三种方式给开发人员发布和引用 JVM 服务\n XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上面的 Bean 发布成一个 SOFA JVM 服务。\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 上面的配置中的 interface 指的是需要发布成服务的接口，ref 指向的是需要发布成 JVM 服务的 Bean，至此，我们就已经完成了一个 JVM 服务的发布。\n服务引用 使用 SOFA 提供的 Spring 扩展标签引用服务:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上面的配置中的 interface 是服务的接口，需要和发布服务时配置的 interface 一致。id 属性的含义同 Spring BeanId。上面的配置会生成一个 id 为 sampleServiceRef 的 Spring Bean，你可以将 sampleServiceRef 这个 Bean 注入到当前 SOFABoot 模块 Spring 上下文的任意地方。\n service/reference 标签还支持 RPC 服务发布，相关文档: RPC 服务发布与引用\n Annotation 方式 警告\n如果一个服务已经被加上了 @SofaService 的注解，它就不能再用 XML 的方式去发布服务了，选择一种方式发布服务，而不是两种混用。\n 除了通过 XML 方式发布 JVM 服务和引用之外，SOFABoot 还提供了 Annotation 的方式来发布和引用 JVM 服务。通过 Annotation 方式发布 JVM 服务，只需要在实现类上加一个 @SofaService 注解即可，如下：\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } 提示\n@SofaService 的作用是将一个 Bean 发布成一个 JVM 服务，这意味着虽然你可以不用再写 \u0026amp;lt;sofa:service/\u0026amp;gt; 的配置，但是还是需要事先将 @SofaService 所注解的类配置成一个 Spring Bean。\n 在使用 XML 配置 \u0026amp;lt;sofa:service/\u0026amp;gt; 的时候，我们配置了一个 interface 属性，但是在使用 @SofaService 注解的时候，却没有看到有配置服务接口的地方。这是因为当被 @SofaService 注解的类只有一个接口的时候，框架会直接采用这个接口作为服务的接口。当被 @SofaService 注解的类实现了多个接口时，可以设置 @SofaService 的 interfaceType 字段来指定服务接口，比如下面这样：\n@SofaService(interfaceType=SampleInterface.class) public class SampleImpl implements SampleInterface, Serializable { public void test() { } } 和 @SofaService 对应，Sofa 提供了 @SofaReference 来引用一个 JVM 服务。假设我们需要在一个 Spring Bean 中使用 SampleJvmService 这个 JVM 服务，那么只需要在字段上加上一个 @SofaReference 的注解即可：\npublic class SampleServiceRef { @SofaReference private SampleService sampleService; } 和 @SofaService 类似，我们也没有在 @SofaReference 上指定服务接口，这是因为 @SofaReference 在不指定服务接口的时候，会采用被注解字段的类型作为服务接口，你也可以通过设定 @SofaReference 的 interfaceType 属性来指定：\npublic class SampleServiceRef { @SofaReference(interfaceType=SampleService.class) private SampleService sampleService; } 使用 @SofaService 注解发布服务时，需要在实现类上打上 @SofaService 注解；在 Spring Boot 使用 Bean Method 创建 Bean 时，会导致 @Bean 和 @SofaService 分散在两处，而且无法对同一个实现类使用不同的 unique id。因此自 SOFABoot v2.6.0 及 v3.1.0 版本起，支持 @SofaService 作用在 Bean Method 之上，例如：\n@Configuration public class SampleSofaServiceConfiguration { @Bean(\u0026amp;quot;sampleSofaService\u0026amp;quot;) @SofaService(uniqueId = \u0026amp;quot;service1\u0026amp;quot;) SampleService service() { return new SampleServiceImpl(\u0026amp;quot;\u0026amp;quot;); } } 同样为了方便在 Spring Boot Bean Method 使用注解 @SofaReference 引用服务，自 SOFABoot v2.6.0 及 v3.1.0 版本起，支持在 Bean Method 参数上使用 @SofaReference 注解引用 JVM 服务，例如：\n@Configuration public class MultiSofaReferenceConfiguration { @Bean(\u0026amp;quot;sampleReference\u0026amp;quot;) TestService …","date":-62135596800,"description":"","dir":"projects/sofa-boot/module-service/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"527472fbe57ce450e4e2b41d878704cb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/module-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/module-service/","summary":"SOFABoot 提供三种方式给开发人员发布和引用 JVM 服务 XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean： \u0026lt;bean id=\u0026quot;sampleService\u0026quot; class=\u0026quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026quot;\u0026gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上","tags":null,"title":"JVM 服务发布与引用","type":"projects","url":"/sofastack.tech/projects/sofa-boot/module-service/","wordcount":1926},{"author":null,"categories":null,"content":" 1. Create a Maven project and import the dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. Create the SOFARegistry client instance The key code for creating the SOFARegistry client instance is as follows:\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); Properties related to SOFARegistry are specified by the DefaultRegistryClientConfigBuilder class, which provides the following key properties:\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } Property Type Description instanceId String The ID of the instance. Default value: DEFAULT_INSTANCE_ID. The same instance ID must be used for data publishing and subscription. The unique data identifier consists of dataId+group+instanceId. zone String The zone where the instance is located. Default value: DEFAULT_ZONE. registryEndpoint String The endpoint of any session node of the servers. registryEndpointPort Integer The session.server.httpServerPort configured for a session node. Default value: 9603. dataCenter String The data center of SOFARegistry. Default value: DefaultDataCenter. appName String The name of the app that accesses SOFARegistry. connectTimeout Integer Specifies the timeout for establishing a connection with a server. Default value: 3000 ms. socketTimeout Integer Specifies the timeout for accessing the servers\u0026amp;rsquo; REST API. Default value: 3000 ms. invokeTimeout Integer Specifies the timeout for calling services on the servers. Default value: 1000 ms. recheckInterval Integer Specifies the interval for checking the task queue. Default value: 500 ms. observerThreadCoreSize Integer Specifies the number of core threads in the thread pool that process data pushed from the servers. Default value: 5. observerThreadMaxSize Integer Specifies the maximum number of threads in the thread pool that process data pushed from the servers. Default value: 10. observerThreadQueueLength Integer Specifies the maximum thread queue length of the thread pool that processes data pushed from the servers. Default value: 1000. syncConfigRetryInterval Integer Specifies the retry interval to synchronize the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/java-sdk/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"32cff5cc5d89ffa85b12c207a1c0c6f3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/java-sdk/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/java-sdk/","summary":"1. Create a Maven project and import the dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. Create the SOFARegistry client instance The key code for creating the SOFARegistry client instance is as follows:\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); Properties related to SOFARegistry are specified by the DefaultRegistryClientConfigBuilder class, which provides the following key properties:\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } Property Type Description instanceId String The ID of the instance.","tags":null,"title":"Java SDK","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/java-sdk/","wordcount":890},{"author":null,"categories":null,"content":" 1. Maven 坐标 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. 创建 SOFARegistry 客户端实例 构建 SOFARegistry 客户端实例的关键代码如下：\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); 其中注册中心相关的属性通过 DefaultRegistryClientConfigBuilder 构建指定，该类包含以下关键属性：\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } 属性名 属性类型 描述 instanceId String 实例ID，发布订阅时需要使用相同值，数据唯一标识由dataId+group+instanceId组成，默认值 DEFAULT_INSTANCE_ID。 zone String 单元化所属 zone，默认值 DEFAULT_ZONE。 registryEndpoint String 服务端任一 Session 节点地址。 registryEndpointPort int Session 节点配置的 session.server.httpServerPort 端口值，默认值 9603。 dataCenter String 数据中心，默认值 DefaultDataCenter。 appName String 应用名。 connectTimeout int 与服务端建立连接超时时间，默认值 3000ms。 socketTimeout int 访问服务端 REST 接口超时时间，默认值 3000ms。 invokeTimeout int 调用服务端服务超时时间，默认值 1000ms。 recheckInterval int 检测任务队列间隔时间，默认值 500ms。 observerThreadCoreSize int 处理服务端推送数据线程池核心线程大小，默认值 5。 observerThreadMaxSize int 处理服务端推送数据线程池最大线程大小，默认值 10。 observerThreadQueueLength int 处理服务端推送数据线程池队列大小，默认值 1000。 syncConfigRetryInterval int 同步服务端列表间隔时间，默认值 30000ms。 3. 发布数据 发布数据的关键代码如下：\n// 构造发布者注册表 PublisherRegistration registration = new PublisherRegistration(\u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); // 将注册表注册进客户端并发布数据 Publisher publisher = registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); // 如需覆盖上次发布的数据可以使用发布者模型重新发布数据 publisher.republish(\u0026amp;quot;10.10.1.1:12200?xx=zz\u0026amp;quot;); 发布数据的关键是构造 PublisherRegistration，该类包含三个属性：\n 属性名 属性类型 描述 dataId String 数据ID，发布订阅时需要使用相同值，数据唯一标识由 dataId + group + instanceId 组成。 group String 数据分组，发布订阅时需要使用相同值，数据唯一标识由 dataId + group + instanceId 组成，默认值 DEFAULT_GROUP。 appName String 应用 appName。 4. 订阅数据 订阅数据的关键代码如下：\n// 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { @Override public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, …","date":-62135596800,"description":"","dir":"projects/sofa-registry/java-sdk/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"32cff5cc5d89ffa85b12c207a1c0c6f3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/java-sdk/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/java-sdk/","summary":"1. Maven 坐标 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. 创建 SOFARegistry 客户端实例 构建 SOFARegistry 客户端实例的关键代码如下： RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); 其中注册中心相关的属性通过 DefaultRegistryClientConfigBuilder 构建指定，该类包含以下关","tags":null,"title":"Java SDK","type":"projects","url":"/sofastack.tech/projects/sofa-registry/java-sdk/","wordcount":1368},{"author":null,"categories":null,"content":"In addition to hundreds of unit tests and some chaos tests, SOFAJRaft also uses a distributed verification and fault injection testing framework Jepsen to simulate many cases, and has passed all these tests:\n Randomized partitioning with two partitions: a big one and a small one Randomly adding and removing nodes Randomly stopping and starting nodes Randomly kill -9 and starting nodes Randomly dividing a cluster into two groups, with one node connection the two to simulate network partitioning Randomly dividing a cluster into different majority groups sofa-jraft-jepsen project address\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jepson-test/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c60bc5083fdf888f6eef5b344b1ad157","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jepson-test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jepson-test/","summary":"In addition to hundreds of unit tests and some chaos tests, SOFAJRaft also uses a distributed verification and fault injection testing framework Jepsen to simulate many cases, and has passed all these tests:\n Randomized partitioning with two partitions: a big one and a small one Randomly adding and removing nodes Randomly stopping and starting nodes Randomly kill -9 and starting nodes Randomly dividing a cluster into two groups, with one node connection the two to simulate network partitioning Randomly dividing a cluster into different majority groups sofa-jraft-jepsen project address","tags":null,"title":"Jepsen tests","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jepson-test/","wordcount":89},{"author":null,"categories":null,"content":"除了几百个单元测试以及部分 chaos 测试之外, SOFAJRaft 还使用 jepsen 这个分布式验证和故障注入测试框架模拟了很多种情况，都已验证通过：\n 随机分区，一大一小两个网络分区 随机增加和移除节点 随机停止和启动节点 随机 kill -9 和启动节点 随机划分为两组，互通一个中间节点，模拟分区情况 随机划分为不同的 majority 分组 sofa-jraft-jepsen 项目地址\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jepson-test/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c60bc5083fdf888f6eef5b344b1ad157","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jepson-test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jepson-test/","summary":"除了几百个单元测试以及部分 chaos 测试之外, SOFAJRaft 还使用 jepsen 这个分布式验证和故障注入测试框架模拟了很多种情况，都已验证通过： 随机分区，一大一小两个网络分","tags":null,"title":"Jepsen 验证","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jepson-test/","wordcount":137},{"author":null,"categories":null,"content":"In the Interactive Instructions section, we have described the set of instructions that Jarslink2.0 supports. In this section, we will focus on all the possible state transitions behind these instructions in the following diagram of a Biz package being loaded from a static file to the runtime and to being uninstalled.\nThe diagram above basically shows the complete life cycle of a Biz package. Now we will explain the direction of each state transition in the diagram:\n Label 1: Execute the install instruction, and Jarslink2.0 will resolve the file format. If the format is correct, it is the Biz package file, and the Biz package will be registered and installed.\n Label 2: When the Biz package is successfully installed, the Biz package\u0026amp;rsquo;s main function is executed, the Spring context is loaded successfully, and passes the health check. If Biz packages with the same name but different versions are detected to be activated, the Biz package state will be set to an inactive state. The JVM services that are published by an inactive Biz package will not be called.\n Label 3: When the Biz package is successfully installed, the Biz package\u0026amp;rsquo;s main function is executed, the Spring context is loaded successfully, and passes the health check. If Biz packages with the same name but different versions are detected to be activated, the Biz package state will be set as active and can provide services.\n Label 4: If there are any exceptions or a health check failure, the Biz package state will be set to broken. During the installation, the resources that the Biz package occupies will be quickly released and unregistered, at which point the Biz state will be set to unresolved.\n Label 5: When running, Jarslink2.0 can load Biz packages with the same name but different versions, but only one Biz package is in the active state and can provide services. Execute the switch instruction, and the two Biz packages\u0026amp;rsquo; states will be interchanged.\n Label 6: Execute the uninstallation instruction, the Biz package will be uninstalled, and its occupied resources and published services will be unregistered.\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0f166dd5388f3dc7d968bce31d0f6e4f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","summary":"In the Interactive Instructions section, we have described the set of instructions that Jarslink2.0 supports. In this section, we will focus on all the possible state transitions behind these instructions in the following diagram of a Biz package being loaded from a static file to the runtime and to being uninstalled.\nThe diagram above basically shows the complete life cycle of a Biz package. Now we will explain the direction of each state transition in the diagram:","tags":null,"title":"Lifecycle","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","wordcount":346},{"author":null,"categories":null,"content":" The link data transparent transmission function allows the applications to store data in the calling context, and then any applications in the entire link can operate the data. This feature is used as follows. Data can be put into the request and response of the link for transparent transmission, and then the applications can get the corresponding data from the link.\nRpcInvokeContext.getContext().putRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;,\u0026amp;quot;value_request\u0026amp;quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;,\u0026amp;quot;value_response\u0026amp;quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;); Example For example, in the scenario of A -\u0026amp;gt; B -\u0026amp;gt; C, the request arguments set by A are transmitted to B and C. On return, response arguments of C and B are transmitted to A.\nRequester A is set as follows:\n// Set the value of the request transparently before calling RpcInvokeContext context = RpcInvokeContext.getContext(); context.putRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;, \u0026amp;quot;a2bbb\u0026amp;quot;); // Call service String result = service.hello(); // Get the result value context.getResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;); Business code for B is as follows:\npublic String hello() { / / Get the value of the request transparent transmission RpcInvokeContext context = RpcInvokeContext.getContext(); String reqBaggage = context.getRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;); // doSomthing(); // result passes a value transparently context.putResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;, \u0026amp;quot;b2aaa\u0026amp;quot;); return result; } If you start the child thread halfway, you need to set the context of the child thread:\nCountDownLatch latch = new CountDownLatch(1); final RpcInvokeContext parentContext = RpcInvokeContext.peekContext(); Thread thread = new Thread(new Runnable(){ public void run(){ Try { RpcInvokeContext.setContext(parentContext); / / Call a remote service xxxService.sayHello(); latch.countDown(); } finally { RpcInvokeContext.removeContext(); } } }, \u0026amp;quot;new-thread\u0026amp;quot;); thread.start(); // If failed to get the transparently transmitted data of the return value. latch.await(); //wait // Return ends, and you can get the value returned by transparent transmission. Compare with SOFATracer SOFATracer is an open-source distributed link tracing system of Ant Finanicial. RPC has been integrated with Tracer and is enabled by default.\nThe differences between data transparent transmission and data transfer by Tracer are as follows:\n RPC data transparent transmission is business-oriented. And it can implement two-way data transmission in the full link. The caller can transmit data to the service provider, and the service provider can also transmit data to the caller. SOFATracer is middleware-oriented and is more suitable for the data transfer without service itself perceving. It can only implement one-way data …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-chain-pass-data/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"96cfb41f07a6a2ad979b53093ff5eee9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","summary":"The link data transparent transmission function allows the applications to store data in the calling context, and then any applications in the entire link can operate the data. This feature is used as follows. Data can be put into the request and response of the link for transparent transmission, and then the applications can get the corresponding data from the link.\nRpcInvokeContext.getContext().putRequestBaggage(\u0026quot;key_request\u0026quot;,\u0026quot;value_request\u0026quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026quot;key_response\u0026quot;,\u0026quot;value_response\u0026quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026quot;key_request\u0026quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026quot;key_response\u0026quot;); Example For example, in the scenario of A -\u0026gt; B -\u0026gt; C, the request arguments set by A are transmitted to B and C.","tags":null,"title":"Link data transparent transmission","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","wordcount":427},{"author":null,"categories":null,"content":" 本文描述的是 MOSN listener 配置。\n Listener 配置详细描述了 MOSN 启动时监听的端口，以及对应的端口对应不同逻辑的配置。 Listener 的配置可以通过Listener动态接口进行添加和修改。 { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;address\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;bind_port\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;use_original_dst\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;access_logs\u0026amp;quot;:[], \u0026amp;quot;filter_chains\u0026amp;quot;:[], \u0026amp;quot;stream_filters\u0026amp;quot;:[], \u0026amp;quot;inspector\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;connection_idle_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } name 用于唯一区分 Listener，如果配置为空，会默认生成一个 UUID 作为 name。在对 Listener 进行动态更新时，使用 name 作为索引，如果 name 不存在，则是新增一个 listener，如果 name 存在则是对 listener 进行更新。\ntype 标记 Listener 的类型，目前支持 ingress 和 egress 两种类型。不同 type 的 Listener 输出的 tracelog 不同。\naddress IP:Port 形式的字符串，Listener 监听的地址，唯一。\nbind_port bool 类型，表示 Listener 是否会占用 address 配置的地址，通常情况下都需要配置为true。\nuse_original_dst bool 类型，用于透明代理。\naccess_logs 一组 access_log 配置。\nfilter_chains 一组 FilterChain 配置，但是目前 MOSN 仅支持一个 filter_chain。\nstream_filters 一组 stream_filter 配置，目前只在 filter_chain 中配置了 filter 包含 proxy 时生效。\ninspector bool 类型，当此值为 true 时，表示即便 listener 在 filter_chain 中配置开启了 TLS 监听，listener 依然可以处理非 TLS 的请求。\nconnection_idle_timeout Duration String，空闲连接超时配置。当 listener 上建立的连接空闲超过配置的超时时间以后，MOSN 会将此连接关闭。\n","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"028e9053b21853890114c38d55d15390","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/overview/","summary":"本文描述的是 MOSN listener 配置。 Listener 配置详细描述了 MOSN 启动时监听的端口，以及对应的端口对应不同逻辑的配置。 Listener 的配置可以通过Listener动态接口进行添加","tags":null,"title":"Listener 配置","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/overview/","wordcount":447},{"author":null,"categories":null,"content":" SOFARPC provides a variety of load balancing algorithms and currently supports the following five types:\n Type Name Description random Random algorithm The default load balancing algorithm. localPref Local preference algorithm Firstly detect whether the service is published locally, if not, random algorithm is used. roundRobin Round Robin algorithm Method-level polling, the polling is carried out separately to each method, without affecting each other. consistentHash Consistent hash algorithm The same method-level request is routed to the same node. weightRoundRobin Weighted Round Robin algorithm Poll nodes by weight. Not recommended due to poor performance. To use a specific load balancing algorithm, you can configure as follows:\nIn XML If you reference the service using XML, you can configure it by setting the loadBalancer property of the sofa:global-attrs tag:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs loadBalancer=\u0026amp;quot;roundRobin\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; In Annotation It is currently not supported to configure a load balancing algorithm for a reference in Annotation. The function will be provided in subsequent releases.\nIn API under Spring environment If you use the API in a Spring or Spring Boot environment, you can configure it by calling the setLoadBalancer method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setLoadBalancer(\u0026amp;quot;roundRobin\u0026amp;quot;); In API under non-Spring environment If you directly use the bare API provided by SOFARPC in a non-Spring environment, you can configure it by calling the setLoadBalancer method of ConsumerConfig:\nConsumerConfig consumerConfig = new ConsumerConfig(); consumerConfig.setLoadbalancer(\u0026amp;quot;random\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/load-balance/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"739984ca9a414429304f85010fd73ad0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/load-balance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/load-balance/","summary":"SOFARPC provides a variety of load balancing algorithms and currently supports the following five types:\n Type Name Description random Random algorithm The default load balancing algorithm. localPref Local preference algorithm Firstly detect whether the service is published locally, if not, random algorithm is used. roundRobin Round Robin algorithm Method-level polling, the polling is carried out separately to each method, without affecting each other.","tags":null,"title":"Load balance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/load-balance/","wordcount":230},{"author":null,"categories":null,"content":"To use local file as service registry center, you can configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg The /home/admin/registry/localRegistry.reg is the directory of the local files to be used.\nOn windows OS, the above path indicates the following directory:\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-local/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"33bc89393392e21b3917f090313c0df5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-local/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-local/","summary":"To use local file as service registry center, you can configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg The /home/admin/registry/localRegistry.reg is the directory of the local files to be used.\nOn windows OS, the above path indicates the following directory:\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","tags":null,"title":"Local","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-local/","wordcount":40},{"author":null,"categories":null,"content":" Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately. For single-core forwarding, in the case of specifying P=1, MOSN binds CPU with cores to improve the call execution efficiency of the system and the locality affinity of cache. For memory, in the case of binding single core, MOSN uses SLAB-style recycling mechanism to improve reuse and reduce memory copy. For IO, MOSN mainly implements optimization by controlling the read/write buffer size, read/write timing, read/write frequency and other parameters. The performance test data is as follows:\nTCP proxy performance data For the same deployment mode, this report compares MOSN 0.1.0 and envoy for the upper-layer protocol Bolt (SOFARPC related protocol) and HTTP1.1 respectively.\nDeployment mode The pressure test is deployed in a pure proxy mode. The client process accesses the server process through the MOSN process and serves as a forwarding proxy. The client process, MOSN process, and server process run on the machines which belong to different network segments. The network delay of the direct access from the client to server is about 2.5ms.\nClient Bolt protocol (send 1K string) The client that sends the Bolt protocol data uses the online pressure generators developed by Ant Financial and deploys the SOFARPC client.\nOn the pressure generator performance page, you can see the QPS, success/failure counts, RT and other parameters.\nHTTP1.1 protocol (send 1K string) Use ApacheBench/2.3. The test instructions are:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Mesh machine specifications The mesh runs in a container where the CPU is an exclusive logical core. The specifications are as follows:\n Category Information OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream machine specifications Category Information OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt protocol test result Performance data Indicators MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% Conclusion For single-core TCP forwarding, there is little difference between MOSN 0.1.0 and Envoy 1.7 in terms of performance in the condition with full load, such as QPS, RTT and success/failure counts. We will continue to optimize in the subsequent versions.\nHTTP/1.1 test result Since the HTTP/1.1 request response model is …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report010/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3cb22950b4be5a25b90f8aa1376786e9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/mosn/reference-performance-report010/","summary":"Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately.","tags":null,"title":"MOSN 0.1.0 performance report","type":"projects","url":"/sofastack.tech/en/projects/mosn/reference-performance-report010/","wordcount":730},{"author":null,"categories":null,"content":" Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately. For single-core forwarding, in the case of specifying P=1, MOSN binds CPU with cores to improve the call execution efficiency of the system and the locality affinity of cache. For memory, in the case of binding single core, MOSN uses SLAB-style recycling mechanism to improve reuse and reduce memory copy. For IO, MOSN mainly implements optimization by controlling the read/write buffer size, read/write timing, read/write frequency and other parameters. The performance test data is as follows:\nTCP proxy performance data For the same deployment mode, this report compares MOSN 0.1.0 and envoy for the upper-layer protocol Bolt (SOFARPC related protocol) and HTTP1.1 respectively.\nDeployment mode The pressure test is deployed in a pure proxy mode. The client process accesses the server process through the MOSN process and serves as a forwarding proxy. The client process, MOSN process, and server process run on the machines which belong to different network segments. The network delay of the direct access from the client to server is about 2.5ms.\nClient Bolt protocol (send 1K string) The client that sends the Bolt protocol data uses the online pressure generators developed by Ant Financial and deploys the SOFARPC client.\nOn the pressure generator performance page, you can see the QPS, success/failure counts, RT and other parameters.\nHTTP1.1 protocol (send 1K string) Use ApacheBench/2.3. The test instructions are:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Mesh machine specifications The mesh runs in a container where the CPU is an exclusive logical core. The specifications are as follows:\n Category Information OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream machine specifications Category Information OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt protocol test result Performance data Indicators MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% Conclusion For single-core TCP forwarding, there is little difference between MOSN 0.1.0 and Envoy 1.7 in terms of performance in the condition with full load, such as QPS, RTT and success/failure counts. We will continue to optimize in the subsequent versions.\nHTTP/1.1 test result Since the HTTP/1.1 request response model is …","date":-62135596800,"description":"","dir":"projects/occlum/reference-performance-report010/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"035dfbc7e310acf31561343432aea680","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/occlum/reference-performance-report010/","summary":"Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately.","tags":null,"title":"MOSN 0.1.0 performance report","type":"projects","url":"/sofastack.tech/en/projects/occlum/reference-performance-report010/","wordcount":730},{"author":null,"categories":null,"content":" 以下的的性能报告为 MOSN 0.1.0 在做 Bolt 与 HTTP1.x 协议的纯 TCP 转发上与 envoy 的一些性能对比数据，主要表现在 QPS、RTT、失败率/成功率等。\n这里需要强调的是，为了提高 MOSN 的转发性能，在 0.1.0 版本中，我们做了如下的一些优化手段：\n 在线程模型优化上，使用 worker 协程池处理 stream 事件，使用两个独立的协程分别处理读写 IO 在单核转发优化上，在指定 P=1 的情况下，我们通过使用 CPU 绑核的形式来提高系统调用的执行效率以及 cache 的 locality affinity 在内存优化上，同样是在单核绑核的情况下，我们通过使用 SLAB-style 的回收机制来提高复用，减少内存 copy 在 IO 优化上，主要是通过读写 buffer 大小以及读写时机和频率等参数的控制上进行调优 以下为具体的性能测试数据。\nTCP 代理性能数据 这里，针对相同的部署模式，我们分别针对上层协议为 \u0026amp;quot;Bolt(SofaRpc相关协议)\u0026amp;quot; 与 \u0026amp;quot;HTTP1.1\u0026amp;quot; 来进行对比。\n部署模式 压测采用纯代理模式部署，client 进程通过 MOSN 进程作为转发代理访问server进程。其中，client 进程，MOSN 进程，server 进程分别运行在属于不同网段的机器中。client 直连访问 server 网络延时为 2.5ms 左右。\n客户端 Bolt 协议（发送 1K 字符串） 发送 Bolt 协议数据的客户端使用 \u0026amp;ldquo;蚂蚁金服\u0026amp;rdquo;内部开发的线上压力机，并部署 sofa rpc client。 通过压力机的性能页面，可反映压测过程中的QPS、成功/失败次数，以及RT等参数。\nHTTP1.1 协议（发送 1K 字符串） 使用 ApacheBench/2.3, 测试指令:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Service mesh 运行机器规格 Service mesh 运行在容器中，其中 CPU 为独占的一个逻辑核，具体规格如下：\n 类别 信息 OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream 运行机器规格 类别 信息 OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt 协议测试结果 性能数据 指标 MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% 结论 可以看到，在单核 TCP 转发场景下，MOSN 0.1.0 版本和 Envoy 1.7版本，在满负载情况下的 QPS、RTT、成功数/失败数等性能数据上相差不大，后续版本我们会继续优化。\nHTTP/1.1 测试结果 由于 HTTP/1.1 的请求响应模型为 PING-PONG，因此 QPS 与并发数会呈现正相关。下面分别进行不同并发数的测试。\n并发20 指标 MOSN Envoy QPS 5600 5600 RT(mean) 3.549ms 3.545ms RT(P99) 4ms 4ms RT(P98) 4ms 4ms RT(P95) 4ms 4ms MEM 24m 23m CPU 40% 20% 并发40 指标 MOSN Envoy QPS 11150 11200 RT(mean) 3.583ms 3.565ms RT(P99) 4ms 4ms RT(P98) 4ms 4ms RT(P95) 4ms 4ms MEM 34m 24m CPU 70% 40% 并发200 指标 MOSN Envoy QPS 29670 38800 RT(mean) 5.715ms 5.068ms RT(P99) 16ms 7ms RT(P98) 13ms 7ms RT(P95) 11ms 6ms MEM 96m 24m CPU 100% 95% 并发220 指标 MOSN Envoy QPS 30367 41070 RT(mean) 8.201ms 5.369ms RT(P99) 20ms 9ms RT(P98) 19ms 8ms RT(P95) 16ms 8ms MEM 100m 24m CPU 100% 100% 结论 可以看到，在上层协议为 HTTP/1.X 时，MOSN 的性能和 Envoy 的性能存在一定差距，对于这种现象我们的初步结论为：在 PING-PONG 的发包模型下，MOSN 无法进行 read/write 系统调用合并，相比 SOFARPC 可以合并的场景，syscall 数量大幅上升，因此导致相比 SOFARPC 的场景，HTTP 性能上相比 Envoy 会存在差距。针对这个问题，在 0.2.0 版本中，我们会进行相应的优化。\n附录 Envoy 版本信息 version：1.7 tag：1ef23d481a4701ad4a414d1ef98036bd2ed322e7 Envoy TCP 测试配置 static_resources: listeners: - address: socket_address: address: 0.0.0.0 port_value: 12200 filter_chains: - filters: - name: envoy.tcp_proxy config: stat_prefix: ingress_tcp cluster: sofa_server clusters: - name: sofa_server connect_timeout: 0.25s type: static lb_policy: round_robin hosts: - socket_address: address: 10.210.168.5 port_value: 12222 - socket_address: address: 10.210.168.5 port_value: 12223 - socket_address: address: 10.210.168.5 port_value: 12224 - socket_address: address: 10.210.168.5 port_value: 12225 admin: access_log_path: …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report010/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3cb22950b4be5a25b90f8aa1376786e9","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/reference-performance-report010/","summary":"以下的的性能报告为 MOSN 0.1.0 在做 Bolt 与 HTTP1.x 协议的纯 TCP 转发上与 envoy 的一些性能对比数据，主要表现在 QPS、RTT、失败率/成功率等。 这里需要强调的是，为了提","tags":null,"title":"MOSN 0.1.0 性能报告","type":"projects","url":"/sofastack.tech/projects/mosn/reference-performance-report010/","wordcount":1229},{"author":null,"categories":null,"content":" 以下性能报告的基准版本为 MOSN 0.2.1。在 0.2.1 版本中，我们进行了如下一些优化手段： - 添加内存复用框架，涵盖 io/protocol/stream/proxy 层级，减少对象分配、内存使用和 GC 压力。 - 针对大量链接场景，新增 Raw Epoll 模式，该模式使用了事件回调机制 + IO 协程池，规避了海量协程带来的堆栈内存消耗以及调度开销。\n需要注意的是，由于目前 SOFARPC 和 H2 的压测工具还没有 pxx 指标的展示，我们在性能报告中选取的数据都为均值。后续需要我们自行进行相关压测环境工具的建设来完善相关指标（P99，P95……）\n总览 本次性能报告在0.1.0 性能报告的基础上，新增了若干场景的覆盖，总体包含以下几部分： - 单核性能（sidecar场景） - 7层代理 - Bolt（串联） - Http/1.1（串联） - Http/2（串联） - 多核性能（gateway场景） - 7层代理 - Bolt（直连） - Http/1.1（直连） - Http/2（直连） - 长连接网关 - Bolt（read/write loop with goroutine/raw epoll）\n单核性能（sidecar 场景） 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2430 0 @ 2.20GHz bolt client client 为压力平台，有 5 台压力机，共计与client MOSN 之间会建立 500 条链接 http1 client（10.210.168.5） ApacheBench/2.3 -n 2000000 -c 500 -k http2 client（10.210.168.5） nghttp.h2load -n1000000 -c5 -m100 -t4 部署结构 压测模式 部署结构 串联 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 请求内容 1K req/resp 7层代理 场景 QPS RT(ms) MEM(K) CPU(%) Bolt 16000 15.8 77184 98 Http/1.1 4610 67 47336 90 Http/2 5219 81 31244 74 多核性能（gateway 场景） 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2430 0 @ 2.20GHz bolt client client为压力平台，有5台压力机，共计与client MOSN之间会建立500条链接 http1 client（10.210.168.5） ApacheBench/2.3 -n 2000000 -c 500 -k http2 client（10.210.168.5） nghttp.h2load -n1000000 -c5 -m100 -t4 部署结构 压测模式 部署结构 直连 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 请求内容 1K req/resp 7层代理 场景 QPS RT(ms) MEM(K) CPU(%) Bolt 45000 23.4 544732 380 Http/1.1 21584 23 42768 380 Http/2 8180 51.7 173180 300 长连接网关 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2430 0 @ 2.20GHz 部署结构 压测模式 部署结构 直连 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 链接数 请求内容 2 台压力机，每台 5w 链接 + 500 QPS，共计10W链接 + 1000 QPS 1K req/resp 长连接网关 场景 QPS MEM(g) CPU(%) goroutine RWLoop + goroutine 1000 3.3 60 200028 Raw epoll 1000 2.5 18 28 总结 MOSN 0.2.1引入了内存复用框架，相比0.1.0，在 bolt 协议转发场景性能表现得到了大幅优化。在提升了20% 的 QPS 的同时，还优化了 30% 的内存占用。\n与此同时，我们对 HTTP/1.1 及 HTTP/2 的场景也进行 …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report021/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7b04a2e6cf1c4f9e732dc1dfdab74c57","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/reference-performance-report021/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/reference-performance-report021/","summary":"以下性能报告的基准版本为 MOSN 0.2.1。在 0.2.1 版本中，我们进行了如下一些优化手段： - 添加内存复用框架，涵盖 io/protocol/stream/proxy 层级，减少对象分配、内存使用和 GC 压力","tags":null,"title":"MOSN 0.2.1 性能报告","type":"projects","url":"/sofastack.tech/projects/mosn/reference-performance-report021/","wordcount":1616},{"author":null,"categories":null,"content":" MOSN 的官方网站 mosn.io 正在建设中，文档临时托管在这里。\nMOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称。MOSN 可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡，API Gateway，云原生 Ingress 等使用。\n快速开始 请参考快速开始。\n核心能力 Istio集成 集成 Istio 1.0 版本与 V4 API，可基于全动态资源配置运行 核心转发 自包含的网络服务器 支持 TCP 代理 支持 TProxy 模式 多协议 支持 HTTP/1.1，HTTP/2 支持 SOFARPC 支持 Dubbo 协议（开发中） 核心路由 支持 Virtual Host 路由 支持 Headers/URL/Prefix 路由 支持基于 Host Metadata 的 Subset 路由 支持重试 后端管理\u0026amp;amp;负载均衡 支持连接池 支持熔断 支持后端主动健康检查 支持 Random/RR 等负载策略 支持基于 Host Metadata 的 Subset 负载策略 可观察性 观察网络数据 观察协议数据 TLS 支持 HTTP/1.1 on TLS 支持 HTTP/2.0 on TLS 支持 SOFARPC on TLS 进程管理 支持平滑 reload 支持平滑升级 扩展能力 支持自定义私有协议 支持在 TCP IO 层，协议层面加入自定义扩展 社区 MOSN 仍处在初级阶段，有很多能力需要补全，所以我们欢迎所有人参与进来与我们一起共建。\n如有任何疑问欢迎提交 Issue。\n","date":-62135596800,"description":"","dir":"projects/mosn/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f25c59cbb758b4dae5de39e1f1c3a2f4","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/overview/","summary":"MOSN 的官方网站 mosn.io 正在建设中，文档临时托管在这里。 MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，","tags":null,"title":"MOSN 介绍","type":"projects","url":"/sofastack.tech/projects/mosn/overview/","wordcount":470},{"author":null,"categories":null,"content":" Service Mesh 中 Sidecar 运维一直是一个比较棘手的问题，数据平面的 Sidecar 升级是常有的事情，如何在升级 Sidecar（MOSN）的时候而不影响业务，对于存量的长连接如何迁移，本文将为你介绍 MOSN 的解决之道。\n背景 本文介绍 MOSN 支持平滑升级的原因和解决方案，对于平滑升级的一些基础概念，大家可以通过 Nginx vs Enovy vs Mosn 平滑升级原理解析了解。\n先简单介绍一下为什么 Nginx 和 Envoy 不需要具备 MOSN 这样的连接无损迁移方案，主要还是跟业务场景相关，Nginx 和 Envoy 主要支持的是 HTTP1 和 HTTP2 协议，HTTP1使用 connection: Close，HTTP2 使用 Goaway Frame 都可以让 Client 端主动断链接，然后新建链接到新的 New process，但是针对 Dubbo、SOFA PRC 等常见的多路复用协议，它们是没有控制帧，Old process 的链接如果断了就会影响请求的。\n一般的升级做法就是切走应用的流量，比如自己UnPub掉服务，等待一段时间没有请求之后，升级MOSN，升级好之后再Pub服务，整个过程比较耗时，并且会有一段时间是不提供服务的，还要考虑应用的水位，在大规模场景下，就很难兼顾评估。MOSN 为了满足自身业务场景，开发了长连接迁移方案，把这条链接迁移到 New process 上，整个过程对 Client 透明，不需要重新建链接，达到请求无损的平滑升级。\n正常流程 Client 发送请求 Request 到 MOSN MOSN 转发请求 Request 到 Server Server 回复响应 Response 到 MOSN MOSN 回复响应 Response 到 Client 上图简单介绍了一个请求的正常流程，我们后面需要迁移的是 TCP1 链接，也就是 Client 到 MOSN 的连接，MOSN 到 Server 的链接 TCP2 不需要迁移，因为 MOSN 访问 Server 是根据 LoadBalance 选择，我们可以主动控制断链建链。\n平滑升级流程 触发条件 有两个方式可以触发平滑升级流程：\n MOSN 对 SIGHUP 做了监听，发送 SIGHUP 信号给 MOSN 进程，通过 ForkExec 生成一个新的 MOSN 进程。 直接重新启动一个新 MOSN 进程。 为什么提供两种方式？最开始我们支持的是方法1，也就是 nginx 和 Envoy 使用的方式，这个在虚拟机或者容器内替换 MOSN 二级制来升级是可行的，但是我们的场景需要满足容器间的升级，所以需要新拉起一个容器，就需要重新启动一个新的 MOSN 进程来做平滑升级，所以后续又支持了方法2。容器间升级还需要 operator 的支持，本文不展开叙述。\n交互流程 首先，老的 MOSN 在启动最后阶段会启动一个协程运行 ReconfigureHandler() 函数监听一个 Domain Socket（reconfig.sock）, 该接口的作用是让新的 MOSN 来感知是否存在老的 MOSN。\nfunc ReconfigureHandler() { l, err := net.Listen(\u0026amp;quot;unix\u0026amp;quot;, types.ReconfigureDomainSocket) for { uc, err := ul.AcceptUnix() _, err = uc.Write([]byte{0}) reconfigure(false) } } 触发平滑升级流程的两种方式最终都是启动一个新的 MOSN 进程，然后调用GetInheritListeners()，通过 isReconfigure() 函数来判断本机是否存在一个老的 MOSN（就是判断是否存在 reconfig.sock 监听），如果存在一个老的 MOSN，就进入迁移流程，反之就是正常的启动流程。\n// 保留了核心流程 func GetInheritListeners() ([]net.Listener, net.Conn, error) { if !isReconfigure() { return nil, nil, nil } l, err := net.Listen(\u0026amp;quot;unix\u0026amp;quot;, types.TransferListenDomainSocket) uc, err := ul.AcceptUnix() _, oobn, _, _, err := uc.ReadMsgUnix(buf, oob) file := os.NewFile(fd, \u0026amp;quot;\u0026amp;quot;) fileListener, err := net.FileListener(file) return listeners, uc, nil } 如果进入迁移流程，新的 MOSN 将监听一个新的 Domain Socket（listen.sock），用于老的 MOSN 传递 listen FD 到新的 MOSN。FD 的传递使用了sendMsg 和 recvMsg。在收到 listen FD 之后，调用 net.FileListener() 函数生产一个 Listener。此时，新老 MOSN 都同时拥有了相同的 Listen 套接字。\n// FileListener returns a copy of the network listener corresponding // to the open file f. // It is the caller\u0026#39;s responsibility to close ln when finished. // Closing ln does not affect f, and closing f does not affect ln. func FileListener(f *os.File) (ln Listener, err error) { ln, err = fileListener(f) if err != nil { err = \u0026amp;amp;OpError{Op: \u0026amp;quot;file\u0026amp;quot;, Net: \u0026amp;quot;file+net\u0026amp;quot;, Source: nil, Addr: fileAddr(f.Name()), Err: err} } return } 这里的迁移和 Nginx 还是有一些区别，Nginx 是 fork 的方式，子进程自动就继承了 listen FD，MOSN 是新启动的进程，不存在父子关系，所以需要通过 sendMsg 的方式来传递。\n在进入迁移流程和 Listen 的迁移过程中，一共使用了两个 Domain Socket：\n reconfig.sock 是 Old MOSN 监听，用于 New MOSN 来判断是否存在 listen.sock 是 New MOSN 监听，用于 Old MOSN 传递 listen FD 两个 sock 其实是可以复用的，也可以用 reconfig.sock …","date":-62135596800,"description":"","dir":"projects/mosn/concept/smooth-upgrade/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2c09c045287c33c760368abe02bb8986","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/smooth-upgrade/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/mosn/concept/smooth-upgrade/","summary":"Service Mesh 中 Sidecar 运维一直是一个比较棘手的问题，数据平面的 Sidecar 升级是常有的事情，如何在升级 Sidecar（MOSN）的时候而不影响业务，对于存量的长连接","tags":null,"title":"MOSN 平滑升级原理解析","type":"projects","url":"/sofastack.tech/projects/mosn/concept/smooth-upgrade/","wordcount":3957},{"author":null,"categories":null,"content":" 1. registry-meta 1.1 Push switch When publishing new SOFARegistry versions, to minimize the impact on services, and avoid large amounts of push messages caused by large-scale service endpoint changes during the server restart process, we will temporarily turn off the push service at the management layer. After publishing the new SOFARegistry version, we can turn on the push service and restore the normal working conditions. Data subscription and service publication information generated for the period when the push service is turned off will be subject to global push for compensation.\nTurn on the push service:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/close\u0026amp;quot; Turn off the push service:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/open\u0026amp;quot; 1.2 Query the endpoint list View the endpoint list of the meta cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/META/node/query\u0026amp;quot; View the endpoint list of the data cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/DATA/node/query\u0026amp;quot; View the endpoint list of the session cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/SESSION/node/query\u0026amp;quot; 1.3 Scale up/down the meta cluster 1.3.1 Modify the cluster: changePeer You can call this operation to modify the Raft cluster list when you have scaled up/down the cluster. This allows you to correctly add nodes to or remove nodes from the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;ip1\u0026amp;gt;,\u0026amp;lt;ip2\u0026amp;gt;,\u0026amp;lt;ip3\u0026amp;gt;\u0026amp;quot; 1.3.2 Reset the cluster: resetPeer When a cluster is unavailable, for example, two of three servers are not functional, the cluster can not carry out leader election. Here, you can call this operation to reset the cluster list. For example, you can reset the cluster to a one-server cluster (with the only functional server) to resume election and restore service.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/manage/resetPeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;ip1\u0026amp;gt;,\u0026amp;lt;ip2\u0026amp;gt;,\u0026amp;lt;ip3\u0026amp;gt;\u0026amp;quot; 2. registry-data 2.1 Query data View the pub count:\ncurl \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/datum/count\u0026amp;quot; You can call this operation to view data published by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;\u0026amp;quot;:\u0026amp;quot;\u0026amp;lt;client port\u0026amp;gt;\u0026amp;quot;}\u0026#39; 3. registry-session 3.1 Query data You can call this operation to view data published by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/pub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client port\u0026amp;gt;\u0026amp;quot;]\u0026#39; You can call this operation to view data subscribed to by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/sub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: …","date":-62135596800,"description":"","dir":"projects/sofa-registry/management-api/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2cf59ac422c84c279d73c1f7f1cd0902","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/management-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/management-api/","summary":"1. registry-meta 1.1 Push switch When publishing new SOFARegistry versions, to minimize the impact on services, and avoid large amounts of push messages caused by large-scale service endpoint changes during the server restart process, we will temporarily turn off the push service at the management layer. After publishing the new SOFARegistry version, we can turn on the push service and restore the normal working conditions. Data subscription and service publication information generated for the period when the push service is turned off will be subject to global push for compensation.","tags":null,"title":"Management commands","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/management-api/","wordcount":406},{"author":null,"categories":null,"content":" pom dependencies \u0026amp;lt;!-- jraft --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jraft-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- jsr305 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.code.findbugs\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jsr305\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- bolt --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hessian\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- log --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.7.21\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- disruptor --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.lmax\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;disruptor\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-io\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-io\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-lang\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-lang\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protobuf --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.protobuf\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protobuf-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protostuff --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-runtime\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- rocksdb --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.rocksdb\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rocksdbjni\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.14.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- java thread affinity --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;net.openhft\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;affinity\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.1.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- metrics --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.dropwizard.metrics\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;metrics-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/maven-dependency/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"abb08cef5ebf1a10a723597a65415313","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","summary":"pom dependencies \u0026lt;!-- jraft --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jraft-core\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- jsr305 --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.code.findbugs\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jsr305\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.0.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- bolt --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;hessian\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- log --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.slf4j\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;slf4j-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.7.21\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- disruptor --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.lmax\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;disruptor\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.7\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-io\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-io\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.4\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-lang\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-lang\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protobuf --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.protobuf\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;protobuf-java\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.5.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protostuff --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.","tags":null,"title":"Maven dependencies","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","wordcount":104},{"author":null,"categories":null,"content":" pom依赖 \u0026amp;lt;!-- jraft --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jraft-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- jsr305 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.code.findbugs\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jsr305\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- bolt --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hessian\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- log --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.7.21\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- disruptor --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.lmax\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;disruptor\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-io\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-io\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-lang\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-lang\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protobuf --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.protobuf\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protobuf-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protostuff --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-runtime\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- rocksdb --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.rocksdb\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rocksdbjni\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.14.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- java thread affinity --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;net.openhft\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;affinity\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.1.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- metrics --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.dropwizard.metrics\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;metrics-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/maven-dependency/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"abb08cef5ebf1a10a723597a65415313","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/maven-dependency/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/maven-dependency/","summary":"pom依赖 \u0026lt;!-- jraft --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jraft-core\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- jsr305 --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.code.findbugs\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jsr305\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.0.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- bolt --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;hessian\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- log --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.slf4j\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;slf4j-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.7.21\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- disruptor --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.lmax\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;disruptor\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.7\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-io\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-io\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.4\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-lang\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-lang\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protobuf --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.protobuf\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;protobuf-java\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.5.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protostuff","tags":null,"title":"Maven 依赖说明","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/maven-dependency/","wordcount":107},{"author":null,"categories":null,"content":" In Jarslink 2.0, merged deployment refers to loading and running multiple Biz packages in the same JVM. In the section Application Packaging, we have described the relationship between the Spring Boot/SOFABoot application and the Biz package. We may think that merged deployment here refers to loading and running multiple Spring Boot/SOFABoot applications in the same JVM.\nIt is mentioned at the end of Application Packaging that a Biz package can be released to a remote repository through the mvn deploy command, similar to releasing common Jar packages. It comes naturally to mind that the advantage of doing so is that the Biz package generated by other applications can be introduced in the form of dependencies, just like introducing common Jar package dependencies. Then, what is the purpose of introducing the Biz package generated by other applications into your application? Also, how do we dynamically install and uninstall Biz packages in Jarslink 2.0?\nTo answer the two questions above is to understand the concepts of static merged deployment and dynamic merged deployment.\nStatic merged deployment To answer the first question: What is the purpose of introducing the Biz package generated by other applications into your application?\nIn the section Application Packaging, we have described how to package an application into an Ark package and offered a rough equation: Ark package = Biz package + SOFAArk framework + Ark Plugin. When a Biz package generated by other applications is introduced in the application, what kind of packaged Ark package will it be? The conclusion is that the packaging plugin will treat special dependency packages like the Biz package differently. The plugin will package all the non-Biz package dependencies into the application\u0026amp;rsquo;s Biz package, but will consider the introduced Biz package as equal to those of the current application. The final Ark package will contain multiple Biz packages. For details, refer to Ark Package Directory Structure. At this point, when you use java -jar to start this Ark package, you will find that all the contained Biz packages will be started as well.\nTo sum up, the application introduces the Biz packages generated by other applications in the form of dependencies, and the Ark package packaged by this application will contain multiple Biz packages. By executing this Ark package, all the Biz packages will be started, known as static merged deployment.\nStatic merged deployment does not depend on Jarslink 2.0 but is available directly with the SOFAArk packaging plugin.\nNote that the startup order of multiple Biz packages is controllable. When each Biz package is generated, you can use the packaging plugin to configure its priority, whose value is 100 by default. The higher the priority, the lower the value is. The priority determines the startup order of the Biz package.\nDynamic merged deployment To answer the second question: how do you dynamically install and uninstall Biz packages in Jarslink …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-deploy/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ce787203d9d834b7f796b3dbb40bf55d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","summary":"In Jarslink 2.0, merged deployment refers to loading and running multiple Biz packages in the same JVM. In the section Application Packaging, we have described the relationship between the Spring Boot/SOFABoot application and the Biz package. We may think that merged deployment here refers to loading and running multiple Spring Boot/SOFABoot applications in the same JVM.\nIt is mentioned at the end of Application Packaging that a Biz package can be released to a remote repository through the mvn deploy command, similar to releasing common Jar packages.","tags":null,"title":"Merged deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","wordcount":749},{"author":null,"categories":null,"content":" Quickly understand of ACTS models When you write a test case, you need to prepare some database tables, request parameter data of methods, or data for validating database tables and responses. You can save such data in models, and import it to preparation data or validation data when you edit the test case. This allows you to conveniently reuse data. Currently, ACTS models can be divided into database models and class models.\nIn conventional test case compilation, data preparation of models, such as database models, request parameter models, and response models, is based on the test code. The complexity of models increases with the business complexity, especially in financial-level business applications, where a class or data table may have dozens of properties or fields, and where class nesting is common. In this case, constructing complex objects is extremely difficult and prone to omissions. Some of the most frequently occurring problems are listed as follows:\n Omissions may occur and troubleshooting takes a lot of time for a large number of tables. Field names of tables are difficult to remember, and spelling errors frequently occur. The large number and complex types of interface request parameters are frustrating. There are so many class properties that important properties are prone to omission. Object construction with nested structures requires continuous effort in creating and setting values. Important properties are easily omitted when the inheritance and implementation relationships are complex. ACTS models can effectively address the above problems by formatting classes and tables in CSV, which makes the structure of classes easier to understand. Class models and data table models can help you quickly create objects, and serialize them into the YAML file. ACTS models allow you to conveniently manage test case data.\nStorage location of models You can view existing models under the resource/model directory of the test module.\nFigure 4\nGenerate data table model Sample data table model Figure 5\n1. Validation flag description\nY: indicates that the data is to be inserted. N: indicates that the data is not to be inserted. C: indicates that ACTS will clean the inserted data by taking this value as the where condition. F: indicates that the value of this column is a database function. L: indicates that a large field data record requires line wrap. The preparation method for this data record is: A=B;C=D. 2. Quickly import data from models during test case editing\nWhen editing database table data (including preparing table data and expectation data) in ACTS IDE, you can right click to add a model of the specified table, to import all fields and values of the specified table directly from the CSV file of the table model for quick editing. For more information about the use of DB models, see Prepare database data.\nGenerate table model Figure 6\nFigure 7\nFigure 8\nClick OK to generate the model as shown in Figure 9.\nFigure 9\nACTS also supports …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-model/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"65aaf62462b3b0ea142ca75a5b61eb0d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-model/","summary":"Quickly understand of ACTS models When you write a test case, you need to prepare some database tables, request parameter data of methods, or data for validating database tables and responses. You can save such data in models, and import it to preparation data or validation data when you edit the test case. This allows you to conveniently reuse data. Currently, ACTS models can be divided into database models and class models.","tags":null,"title":"Models","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-model/","wordcount":752},{"author":null,"categories":null,"content":" Since version 2.4.0, SOFABoot has started to support modular development capability based on Spring context isolation. To better understand the concept of modular development of SOFABoot, let\u0026amp;rsquo;s distinguish several common forms of modularization:\n Modularization based on code organization: This is the most common form. Codes with different functions are placed under different Java projects at development time and into different jar packages at compile time. At runtime, all Java classes are under the same classpath without any isolation; Modularization based on Spring context isolation: Use the Spring context to perform isolation of different function modules. At development and compile time, the codes and configurations are also placed under different Java projects. At runtime, however, if Spring beans are in different Spring contexts, they are invisible to each other, so dependency injection occurs within the same context. But, all the Java classes are still under the same ClassLoader; Modularization based on ClassLoader isolation: Borrow the ClassLoader to perform isolation. Each module has an independent ClassLoader, and the classpath between modules differs. SOFAArk is the practice of such modularization. SOFABoot Modular Development belongs to the second modularization form\u0026amp;ndash;modularization based on Spring context isolation. Each SOFABoot module uses an independent Spring context to avoid BeanId conflicts between different SOFABoot modules and effectively reduces the cost of communication between teams during enterprise-level multi-module development.\nMore details about SOFABoot module is introduced in the article.\nFeature Description Import Dependency To use SOFABoot module, you should import the following dependency: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;isle-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFABoot Module SOFABoot framework has defined the concept of SOFABoot module: A SOFABoot module is a common Jar package including Java code, Spring configuration files, and SOFABoot module identifiers. A SOFABoot application can be comprised of multiple SOFABoot modules, each of which has independent Spring context.\nThe modular development with SOFABoot provides developers with the following features:\n At runtime, the Spring context of each SOFABoot module is isolated, so the defined Beans between modules will not affect each other; Each SOFABoot module is full-featured and self-contained, allowing for easy migration and reuse in different SOFABoot applications. Developers only need to copy the whole SOFABoot module to the application and adjust the Maven dependence before running it. For the format definition of SOFABoot module, see: Module Configuration.\nInvocation between SOFABoot Modules After isolation of context, the Bean between modules cannot be directly injected, so the SOFA service is required for invocation between the modules. Currently, SOFABoot offers …","date":-62135596800,"description":"","dir":"projects/sofa-boot/modular-development/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"95bc080787c3614bfa485d2f3cd0de4c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/modular-development/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/modular-development/","summary":"Since version 2.4.0, SOFABoot has started to support modular development capability based on Spring context isolation. To better understand the concept of modular development of SOFABoot, let\u0026rsquo;s distinguish several common forms of modularization:\n Modularization based on code organization: This is the most common form. Codes with different functions are placed under different Java projects at development time and into different jar packages at compile time. At runtime, all Java classes are under the same classpath without any isolation; Modularization based on Spring context isolation: Use the Spring context to perform isolation of different function modules.","tags":null,"title":"Modular development","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/modular-development/","wordcount":578},{"author":null,"categories":null,"content":" The SOFABoot module combines a regular JAR with some SOFABoot-specific configurations, which enables a JAR to be identified by SOFABoot and modularized.\nThere are two differences between a complete SOFABoot module and a regular JAR:\n A SOFABoot module contains a sofa-module.properties file, where the name and the dependencies of the module are defined. We can place one or more Spring configuration files in the SOFABoot module\u0026amp;rsquo;s META-INF/spring directory; and SOFABoot will automatically load them as Spring configurations for that module. Inside the sofa-module.properties file Let\u0026amp;rsquo;s look at a complete sofa-module.properties file:\nModule-Name=com.alipay.test.biz.service.impl Spring-Parent=com.alipay.test.common.dal Require-Module=com.alipay.test.biz.shared Module-Profile=dev Module-Name This is the name of a SOFABoot module, which is also the unique identifier of the module. In a SOFABoot application, the Module-Name of a SOFABoot module must be different from that of another SOFABoot module. Note that the SOFABoot modules of a SOFABoot application runtime do not only cover the modules of the current application but also the modules introduced by dependency from other applications. When determining whether a module is unique, you must take these SOFABoot modules into consideration.\nRequire-Module This defines the dependency order of different modules. The value contains a comma-separated list of SOFABoot module names. For example, in the preceding configuration, it indicates that the current module depends on the com.alipay.test.biz.shared module. The SOFABoot framework processes this dependency by starting the com.alipay.test.biz.shared module before the current module.\nIn most cases, you do not have to define the Require-Module for a module. It is required only when the startup of a module\u0026amp;rsquo;s Spring context depends on that of another module\u0026amp;rsquo;s. For example, you have published a JVM Service in module A. In the init method of a Bean in module B, you need to call the JVM Service with a SOFA Reference. Assume that module B is started before module A, the Bean of module B will fail because the JVM Service of module A is not published yet and the init method fails. In this case, you can use the Require-Module to force module A to start before module B.\nSpring-Parent In a SOFABoot application, each SOFABoot module has a separate Spring context, and these Spring contexts are isolated from each other. Although this modular approach has many benefits, it can still cause some inconveniences in certain scenarios. For these scenarios, you can use the Spring-Parent to connect the Spring contexts of two SOFABoot modules. The name of a module can be configured with the Spring-Parent property. For example, in the preceding configuration, the Spring context of com.alipay.test.common.dal is set to the parent of the current module\u0026amp;rsquo;s Spring context.\nDue to Spring\u0026amp;rsquo;s limitations, a module\u0026amp;rsquo;s Spring-Parent contains only one …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-module/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2dbb8a536237f21afbee1e3f320b8193","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","summary":"The SOFABoot module combines a regular JAR with some SOFABoot-specific configurations, which enables a JAR to be identified by SOFABoot and modularized.\nThere are two differences between a complete SOFABoot module and a regular JAR:\n A SOFABoot module contains a sofa-module.properties file, where the name and the dependencies of the module are defined. We can place one or more Spring configuration files in the SOFABoot module\u0026rsquo;s META-INF/spring directory; and SOFABoot will automatically load them as Spring configurations for that module.","tags":null,"title":"Module configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","wordcount":565},{"author":null,"categories":null,"content":"SOFABoot will calculate the dependency tree based on the Require-Module. For example, the following dependency tree represents that Modules B and C depend on Module A, Module E depends on Module D, and Module F depends on Module E:\nThe dependency tree guarantees that Module A starts before Modules B and C, Module D before Module E, and Module E before Module F, but without defining the start orders between Modules B and C, or Modules B, C and Modules D, E and F, which can start either in serial or parallel.\nSOFABoot will start the modules in parallel by default. During use, if you want to disable parallel start, you can add the following parameter to application.properties:\ncom.alipay.sofa.boot.module-start-up-parallel=false ","date":-62135596800,"description":"","dir":"projects/sofa-boot/parallel-start/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a6ef51b78d2a4f9af0debbc25ea45e8a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/parallel-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/parallel-start/","summary":"SOFABoot will calculate the dependency tree based on the Require-Module. For example, the following dependency tree represents that Modules B and C depend on Module A, Module E depends on Module D, and Module F depends on Module E:\nThe dependency tree guarantees that Module A starts before Modules B and C, Module D before Module E, and Module E before Module F, but without defining the start orders between Modules B and C, or Modules B, C and Modules D, E and F, which can start either in serial or parallel.","tags":null,"title":"Module parallel startup","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/parallel-start/","wordcount":119},{"author":null,"categories":null,"content":"SOFARPC already supports using Nacos as a service registry. Suppose you have deployed Nacos Server locally according to Nacos\u0026amp;rsquo;s Quick Start, and the service discovery port is set to 8848 by default.\nTo use Nacos as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 If you use SOFARPC directly, not SOFABoot, you need to add dependency of nacos, notice that version is what you want to use in your project.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba.nacos\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;nacos-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; The current version of Nacos is supported:\nSOFARPC: 5.5.0, SOFABoot: 2.5.3。\nSOFARPC integration verification Nacos server version:0.6.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-nacos/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"cc161f22cd2145fe309e63087581adc1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","summary":"SOFARPC already supports using Nacos as a service registry. Suppose you have deployed Nacos Server locally according to Nacos\u0026rsquo;s Quick Start, and the service discovery port is set to 8848 by default.\nTo use Nacos as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 If you use SOFARPC directly, not SOFABoot, you need to add dependency of nacos, notice that version is what you want to use in your project.","tags":null,"title":"Nacos","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","wordcount":100},{"author":null,"categories":null,"content":" 前言 本文是对 Nginx、Envoy 及 MOSN 的平滑升级原理区别的分析，适合对 Nginx 实现原理比较感兴趣的同学阅读，需要具备一定的网络编程知识。\n平滑升级的本质就是 listener fd 的迁移，虽然 Nginx、Envoy、MOSN 都提供了平滑升级支持，但是鉴于它们进程模型的差异，反映在实现上还是有些区别的。这里来探讨下它们其中的区别，并着重介绍 Nginx 的实现。\nNginx 相信有很多人认为 Nginx 的 reload 操作就能完成平滑升级，其实这是个典型的理解错误。实际上 reload 操作仅仅是平滑重启，并没有真正的升级新的二进制文件，也就是说其运行的依然是老的二进制文件。\nNginx 自身也并没有提供平滑升级的命令选项，其只能靠手动触发信号来完成。具体正确的操作步骤可以参考这里：Upgrading Executable on the Fly，这里只分析下其实现原理。\nNginx 的平滑升级是通过 fork + execve 这种经典的处理方式来实现的。准备升级时，Old Master 进程收到信号然后 fork 出一个子进程，注意此时这个子进程运行的依然是老的镜像文件。紧接着这个子进程会通过 execve 调用执行新的二进制文件来替换掉自己，成为 New Master。\n那么问题来了：New Master 启动时按理说会执行 bind + listen 等操作来初始化监听，而这时候 Old Master 还没有退出，端口未释放，执行 execve 时理论上应该会报：Address already in use 错误，但是实际上这里却没有任何问题，这是为什么？\n因为 Nginx 在 execve 的时候压根就没有重新 bind + listen，而是直接把 listener fd 添加到 epoll 的事件表。因为这个 New Master 本来就是从 Old Master 继承而来，自然就继承了 Old Master 的 listener fd，但是这里依然有一个问题：该怎么通知 New Master 呢？\n环境变量。execve 在执行的时候可以传入环境变量。实际上 Old Master 在 fork 之前会将所有 listener fd 添加到 NGINX 环境变量：\nngx_pid_t ngx_exec_new_binary(ngx_cycle_t *cycle, char *const *argv) { ... ctx.path = argv[0]; ctx.name = \u0026amp;quot;new binary process\u0026amp;quot;; ctx.argv = argv; n = 2; env = ngx_set_environment(cycle, \u0026amp;amp;n); ... env[n++] = var; env[n] = NULL; ... ctx.envp = (char *const *) env; ccf = (ngx_core_conf_t *) ngx_get_conf(cycle-\u0026amp;gt;conf_ctx, ngx_core_module); if (ngx_rename_file(ccf-\u0026amp;gt;pid.data, ccf-\u0026amp;gt;oldpid.data) == NGX_FILE_ERROR) { ... return NGX_INVALID_PID; } pid = ngx_execute(cycle, \u0026amp;amp;ctx); return pid; } Nginx 在启动的时候，会解析 NGINX 环境变量：\nstatic ngx_int_t ngx_add_inherited_sockets(ngx_cycle_t *cycle) { ... inherited = (u_char *) getenv(NGINX_VAR); if (inherited == NULL) { return NGX_OK; } if (ngx_array_init(\u0026amp;amp;cycle-\u0026amp;gt;listening, cycle-\u0026amp;gt;pool, 10, sizeof(ngx_listening_t)) != NGX_OK) { return NGX_ERROR; } for (p = inherited, v = p; *p; p++) { if (*p == \u0026#39;:\u0026#39; || *p == \u0026#39;;\u0026#39;) { s = ngx_atoi(v, p - v); ... v = p + 1; ls = ngx_array_push(\u0026amp;amp;cycle-\u0026amp;gt;listening); if (ls == NULL) { return NGX_ERROR; } ngx_memzero(ls, sizeof(ngx_listening_t)); ls-\u0026amp;gt;fd = (ngx_socket_t) s; } } ... ngx_inherited = 1; return ngx_set_inherited_sockets(cycle); } 一旦检测到是继承而来的 socket，那就说明已经打开了，不会再继续 bind + listen 了：\nngx_int_t ngx_open_listening_sockets(ngx_cycle_t *cycle) { ... /* TODO: configurable try number */ for (tries = 5; tries; tries--) { failed = 0; /* for each listening socket */ ls = cycle-\u0026amp;gt;listening.elts; for (i = 0; i \u0026amp;lt; cycle-\u0026amp;gt;listening.nelts; i++) { ... if (ls[i].inherited) { /* TODO: close on exit */ /* TODO: nonblocking */ /* TODO: deferred accept */ continue; } ... ngx_log_debug2(NGX_LOG_DEBUG_CORE, log, 0, \u0026amp;quot;bind() %V #%d \u0026amp;quot;, \u0026amp;amp;ls[i].addr_text, s); if (bind(s, ls[i].sockaddr, ls[i].socklen) == -1) { ... } ... } } if (failed) { ngx_log_error(NGX_LOG_EMERG, log, 0, \u0026amp;quot;still could not bind()\u0026amp;quot;); return NGX_ERROR; } return NGX_OK; } Envoy Envoy 使用的是单进程多线程模型，其局限就是无法通过环境变量来传递 listener fd。因此 Envoy 采用的是 UDS（unix domain sockets）方案。当 New Envoy 启动完成后，会通过 UDS 向 Old Envoy 请求 listener fd 副本， …","date":-62135596800,"description":"","dir":"projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"63ca389b7e6e0a585d0183ad71887f65","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","summary":"前言 本文是对 Nginx、Envoy 及 MOSN 的平滑升级原理区别的分析，适合对 Nginx 实现原理比较感兴趣的同学阅读，需要具备一定的网络编程知识。 平滑升级的","tags":null,"title":"Nginx vs Envoy vs MOSN 平滑升级原理解析","type":"projects","url":"/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","wordcount":1525},{"author":null,"categories":null,"content":" If you need to call SOFARPC through NodeJs, you can start by following this document.\nInstall First install the SOFARPC Node.\nhttps://github.com/sofastack/sofa-rpc-node\nUse the following command:\n$ npm install sofa-rpc-node --save Code sample Expose an RPC service and publish it to registry center \u0026#39;use strict\u0026#39;; const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, Address: \u0026#39;127.0.0.1:2181\u0026#39;, // need to start a zkServer locally }); // 2. Create an RPC Server instance const server = new RpcServer({ logger, Registry, // incoming registry client port: 12200, }); // 3. Add service server.addService({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }, { async plus(a, b) { return a + b; }, }); // 4. Start the server and publish the service server.start() .then(() =\u0026amp;gt; { server.publish(); }); Call RPC service (Get service list from registry center) \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); async function invoke() { // 2. Create an RPC Client instance const client = new RpcClient({ logger, registry, }); // 3. Create a service consumer const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }); // 4. Wait for the consumer ready (subscribe to the service list from registry center...) await consumer.ready(); // 5. Execute generic call const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); Call RPC service (direct call) \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const logger = console; async function invoke() { // No need to pass in the registry instance const client = new RpcClient({ logger, }); const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, serverHost: \u0026#39;127.0.0.1:12200\u0026#39;, // directly specify the service address }); await consumer.ready(); const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); Expose and call the protobuf interface Define interface Define the interface with *.proto\nsyntax = \u0026amp;quot;proto3\u0026amp;quot;; package com.alipay.sofa.rpc.test; // optional option java_multiple_files = false; service ProtoService { rpc echoObj (EchoRequest) returns (EchoResponse) {} } message EchoRequest { string name = 1; Group group = 2; } message EchoResponse { int32 code = 1; string message = 2; } enum Group { A = 0; B = 1; } Server code \u0026#39;use strict\u0026#39;; const antpb = require(\u0026#39;antpb\u0026#39;); const protocol = require(\u0026#39;sofa-bolt-node\u0026#39;); const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/node-and-java-communicate/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3329852e9991868a3cdc473b861ca750","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","summary":"If you need to call SOFARPC through NodeJs, you can start by following this document.\nInstall First install the SOFARPC Node.\nhttps://github.com/sofastack/sofa-rpc-node\nUse the following command:\n$ npm install sofa-rpc-node --save Code sample Expose an RPC service and publish it to registry center 'use strict'; const { RpcServer } = require('sofa-rpc-node').server; const { ZookeeperRegistry } = require('sofa-rpc-node').registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, Address: '127.","tags":null,"title":"NodeJS support","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","wordcount":635},{"author":null,"categories":null,"content":" 快速上手 如果你有通过 NodeJs 调用 SOFARPC 的需求.可以按照如下的文档来开始.\n安装 首先按照文档安装\nhttps://github.com/sofastack/sofa-rpc-node\n使用命令.\n$ npm install sofa-rpc-node --save 代码示例 暴露一个 RPC 服务，并发布到注册中心 \u0026#39;use strict\u0026#39;; const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. 创建 zk 注册中心客户端 const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, // 需要本地启动一个 zkServer }); // 2. 创建 RPC Server 实例 const server = new RpcServer({ logger, registry, // 传入注册中心客户端 port: 12200, }); // 3. 添加服务 server.addService({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }, { async plus(a, b) { return a + b; }, }); // 4. 启动 Server 并发布服务 server.start() .then(() =\u0026amp;gt; { server.publish(); }); 调用 RPC 服务（从注册中心获取服务列表） \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. 创建 zk 注册中心客户端 const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); async function invoke() { // 2. 创建 RPC Client 实例 const client = new RpcClient({ logger, registry, }); // 3. 创建服务的 consumer const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }); // 4. 等待 consumer ready（从注册中心订阅服务列表...） await consumer.ready(); // 5. 执行泛化调用 const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); 调用 RPC 服务（直连模式） \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const logger = console; async function invoke() { // 不需要传入 registry 实例了 const client = new RpcClient({ logger, }); const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, serverHost: \u0026#39;127.0.0.1:12200\u0026#39;, // 直接指定服务地址 }); await consumer.ready(); const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); 暴露和调用 protobuf 接口 接口定义 通过 *.proto 来定义接口\nsyntax = \u0026amp;quot;proto3\u0026amp;quot;; package com.alipay.sofa.rpc.test; // 可选 option java_multiple_files = false; service ProtoService { rpc echoObj (EchoRequest) returns (EchoResponse) {} } message EchoRequest { string name = 1; Group group = 2; } message EchoResponse { int32 code = 1; string message = 2; } enum Group { A = 0; B = 1; } 服务端代码 \u0026#39;use strict\u0026#39;; const antpb = require(\u0026#39;antpb\u0026#39;); const protocol = require(\u0026#39;sofa-bolt-node\u0026#39;); const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 传入 *.proto 文件存放的目录，加载接口定义 const proto = antpb.loadAll(\u0026#39;/path/proto\u0026#39;); // 将 proto 设置到协议中 protocol.setOptions({ proto }); const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); const server = new RpcServer({ logger, protocol, // 覆盖协议 registry, codecType: \u0026#39;protobuf\u0026#39;, // 设置默认的序列化方式为 protobuf port: 12200, }); server.addService({ interfaceName: …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/node-and-java-communicate/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3329852e9991868a3cdc473b861ca750","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","summary":"快速上手 如果你有通过 NodeJs 调用 SOFARPC 的需求.可以按照如下的文档来开始. 安装 首先按照文档安装 https://github.com/sofastack/sofa-rpc-node 使用命令. $ npm install sofa-rpc-node --save 代码示例 暴露一个 RPC 服务，并发布到注册","tags":null,"title":"Node跨语言调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","wordcount":757},{"author":null,"categories":null,"content":" OkHttp Integration In this document will demonstrate how to use SOFATracer to track of OkHttp, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nDependency introduction \u0026amp;lt;!-- SOFATracer dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- okhttp dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.squareup.okhttp3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;okhttp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.12.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs # port server.port=8081 Add a Controller that provides RESTful services In the project, provide a simple Controller, for example:\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8081/okhttp?name=sofa * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/okhttp\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;okhttp\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } Construct OkHttp to initiate a call to the RESTful service above The code example is as follows:\n Construct the OkHttp Client instance: OkHttpClientInstance httpClient = new OkHttpClientInstance(); String httpGetUrl = \u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;; String responseStr = httpClient.executeGet(httpGetUrl); Run Start the SOFABoot app and see the log in the console as follows:\n2019-04-12 13:38:09.896 INFO 51193 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2019-04-12 13:38:09.947 INFO 51193 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8081 (http) 2019-04-12 13:38:09.952 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Started OkHttpDemoApplication in 3.314 seconds (JVM running for 4.157) When there is a log similar to the following, the call to OkHttp is successful:\n2019-04-12 13:38:10.205 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;sofa\u0026amp;quot;} View log In the application.properties, the log printing directory we configured is ./logs, which is the root directory of the current application (we can configure it based on actual situation). In the root directory, you can see log files in the structure similar to …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-okhttp/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2b665b984dd33a4c04b5cd7b4de2410c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","summary":"OkHttp Integration In this document will demonstrate how to use SOFATracer to track of OkHttp, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nDependency introduction \u0026lt;!-- SOFATracer dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- okhttp dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.squareup.okhttp3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;okhttp\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.12.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.","tags":null,"title":"OkHttp Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","wordcount":374},{"author":null,"categories":null,"content":" OkHttp Log Format SOFATracer integrates OkHttp and outputs the requested link log data format. The default is JSON data format.\nOkHttp digest log（okhttp-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code req.size.bytes Request Body Size resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.app remote app baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-12 13:38:10.187\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe85a1555047489980100151193\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:207,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} OkHttp stat log（okhttp-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-12 13:39:09.720\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:207,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-okhttp/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dbc9555f43d0b2eda22f10ed45713fb9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","summary":"OkHttp Log Format SOFATracer integrates OkHttp and outputs the requested link log data format. The default is JSON data format.\nOkHttp digest log（okhttp-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.","tags":null,"title":"OkHttp log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","wordcount":174},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 OkHttp 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;!-- SOFATracer 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- okhttp 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.squareup.okhttp3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;okhttp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.12.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=OkHttpClientDemo # logging path logging.path=./logs # port server.port=8081 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8081/okhttp?name=sofa * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/okhttp\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;okhttp\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } 构造 OkHttp 发起一次对上文的 RESTful 服务的调用 代码示例如下：\n 构造 OkHttp Client 调用实例： OkHttpClientInstance httpClient = new OkHttpClientInstance(); String httpGetUrl = \u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;; String responseStr = httpClient.executeGet(httpGetUrl); 运行 启动 SOFABoot 应用，在控制台中看到启动打印的日志如下：\n2019-04-12 13:38:09.896 INFO 51193 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2019-04-12 13:38:09.947 INFO 51193 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8081 (http) 2019-04-12 13:38:09.952 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Started OkHttpDemoApplication in 3.314 seconds (JVM running for 4.157) 当有类似如下的日志时，说明 OkHttp 的调用成功：\n2019-04-12 13:38:10.205 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;sofa\u0026amp;quot;} 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要进行配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── okhttp-digest.log ├── okhttp-stat.log ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 示例中通过构造 OkHttp 对象发起 RESTful 服务的调用，调用完成后可以在 okhttp-digest.log 中看到类似如下的日志:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-okhttp/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2b665b984dd33a4c04b5cd7b4de2410c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","summary":"在本文档将演示如何使用 SOFATracer 对 OkHttp 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;!-- SOFATracer 依","tags":null,"title":"OkHttp 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","wordcount":578},{"author":null,"categories":null,"content":" SOFATracer 集成 OkHttp 后输出请求的链路数据格式，默认为 JSON 数据格式。\nOkHttp 摘要日志（okhttp-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId request.url 请求 URL method 请求 HTTP 方法 result.code HTTP 返回状态码 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 time.cost.milliseconds 请求耗时（ms） current.thread.name 当前线程名 remote.app 目标应用 baggage 透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 11:35:28.429\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567481728265100112783\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;164ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} OkHttp 统计日志（okhttp-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 11:43:06.975\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:174,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-okhttp/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dbc9555f43d0b2eda22f10ed45713fb9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","summary":"SOFATracer 集成 OkHttp 后输出请求的链路数据格式，默认为 JSON 数据格式。 OkHttp 摘要日志（okhttp-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下","tags":null,"title":"OkHttp 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","wordcount":330},{"author":null,"categories":null,"content":" OpenFeign Integration In this document will demonstrate how to use SOFATracer to track of OpenFeign.\nPrepare Environment The versions of the framework components used in this case are as follows:\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 This case includes two submodules:\n tracer-sample-with-openfeign-provider service provider tracer-sample-with-openfeign-consumer service consumer New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026amp;rsquo;s dependency. First, you need to unzip the generated zip package of Spring Boot project and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more information about SOFABoot versions, refer to Release notes.\nNew tracer-sample-with-openfeign-provider Module Introducing dependence\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer versions are controlled by SOFABoot versions. If the SOFABoot versions used do not match, you need to manually specify a tracer version that is higher than 3.0.4.\n application.properties Configuration spring.application.name=tracer-provider server.port=8800 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-provider Simple resource class\n@RestController public class UserController { @RequestMapping(\u0026amp;quot;/feign\u0026amp;quot;) public String testFeign(HttpServletRequest request) { return \u0026amp;quot;hello tracer feign\u0026amp;quot;; } } New tracer-sample-with-openfeign-consumer Module Introducing dependence \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-openfeign/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"75d9940033ad3b4342eab9d5c7a191f1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","summary":"OpenFeign Integration In this document will demonstrate how to use SOFATracer to track of OpenFeign.\nPrepare Environment The versions of the framework components used in this case are as follows:\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 This case includes two submodules:\n tracer-sample-with-openfeign-provider service provider tracer-sample-with-openfeign-consumer service consumer New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026rsquo;s dependency.","tags":null,"title":"OpenFeign Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","wordcount":368},{"author":null,"categories":null,"content":" OpenFeign Log Format SOFATracer integrates Spring Cloud OpenFeign and outputs the requested link log data format. The default is JSON data format.\nSpring Cloud OpenFeign digest log（feign-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code error error massage req.size.bytes Request Body Size resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.host remote host remote.port remote port component.client.impl component name baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-03-28 18:08:06.800\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe88f1553767685981100124403\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.232.143:8800/feign\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:18,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:206,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8082-exec-1\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.232.143\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;8800\u0026amp;quot;,\u0026amp;quot;component.client.impl\u0026amp;quot;:\u0026amp;quot;open-feign\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring Cloud OpenFeign stat log（feign-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success ; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-03-28 18:09:06.800\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.232.143:8800/feign\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:206,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;Y\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-openfeign/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"81864817e297a7bf019705c72f8ff0a8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","summary":"OpenFeign Log Format SOFATracer integrates Spring Cloud OpenFeign and outputs the requested link log data format. The default is JSON data format.\nSpring Cloud OpenFeign digest log（feign-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.","tags":null,"title":"OpenFeign log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","wordcount":190},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 Spring Cloud OpenFeign 进行埋点。\n基础环境 本案例使用的各框架组件的版本如下：\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 本案例包括两个子工程：\n tracer-sample-with-openfeign-provider 服务提供方 tracer-sample-with-openfeign-consumer 服务调用方 新建 SOFABoot 工程作为父工程 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 Maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n新建 tracer-sample-with-openfeign-provider 在工程模块的 pom 文件中添加 SOFATracer 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer 版本受 SOFABoot 版本管控，如果使用的 SOFABoot 版本不匹配，则需要手动指定 tracer 版本，且版本需高于 3.0.4.\n 在工程的 application.properties 文件下添加相关参数 spring.application.name=tracer-provider server.port=8800 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-provider 简单的资源类\n@RestController public class UserController { @RequestMapping(\u0026amp;quot;/feign\u0026amp;quot;) public String testFeign(HttpServletRequest request) { return \u0026amp;quot;hello tracer feign\u0026amp;quot;; } } 新建 tracer-sample-with-openfeign-consumer 在工程模块的 pom 文件中添加 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 在工程的 application.properties 文件下添加相关参数\nspring.application.name=tracer-consumer server.port=8082 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-consumer 定义 feign 资源 @FeignClient(value = \u0026amp;quot;tracer-provider\u0026amp;quot;,fallback = FeignServiceFallbackFactory.class) public interface FeignService { @RequestMapping(value = \u0026amp;quot;/feign\u0026amp;quot;, method = RequestMethod.GET) …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-openfeign/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"75d9940033ad3b4342eab9d5c7a191f1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","summary":"在本文档将演示如何使用 SOFATracer 对 Spring Cloud OpenFeign 进行埋点。 基础环境 本案例使用的各框架组件的版本如下： Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 本案例包括两个子工程： tracer-sample-with-openfeign-provider 服务提供方 tracer-sample-with-openfeign-consumer","tags":null,"title":"OpenFeign 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","wordcount":602},{"author":null,"categories":null,"content":" SOFATracer 集成 Spring Cloud OpenFeign 后输出请求的链路数据格式，默认为 JSON 数据格式。\nSpring Cloud OpenFeign 摘要日志（feign-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method error 错误信息 req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:28:52.363\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477731347100110969\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8082-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;219ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.233.39:8800/feign\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:18,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.233.39\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;8800\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring Cloud OpenFeign 统计日志（feign-stat.log）ls stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:29:34.528\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.233.39:8800/feign\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:378,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-openfeign/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"81864817e297a7bf019705c72f8ff0a8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","summary":"SOFATracer 集成 Spring Cloud OpenFeign 后输出请求的链路数据格式，默认为 JSON 数据格式。 Spring Cloud OpenFeign 摘要日志（feign-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解","tags":null,"title":"OpenFeign 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","wordcount":341},{"author":null,"categories":null,"content":" MOSN\u0026amp;rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer Acknowledgement MOSN builds on open source projects such as Envoy and Istio, thanks to the efforts of the open source community.\n","date":-62135596800,"description":"","dir":"projects/mosn/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f25c59cbb758b4dae5de39e1f1c3a2f4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/mosn/overview/","summary":"MOSN\u0026rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/mosn/overview/","wordcount":245},{"author":null,"categories":null,"content":" MOSN\u0026amp;rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer Acknowledgement MOSN builds on open source projects such as Envoy and Istio, thanks to the efforts of the open source community.\n","date":-62135596800,"description":"","dir":"projects/occlum/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1d8851c81ed6dacf04ebbe841d1b2835","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/occlum/overview/","summary":"MOSN\u0026rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/occlum/overview/","wordcount":245},{"author":null,"categories":null,"content":" Introduction SOFALookout is a lightweight and open source middleware service of Ant Financial that solves the metrics and monitoring issues of the system. The services it provides include: Event logging, collecting, processing, storing, and querying of Metrics. The open source project consists of two separate parts, the client and server side services.\nClient-side service SOFALookout Client is a Java SDK that helps developers log events of metrics in project code. It also allows you to view real-time status information for the Java application.\n +------------------+ Reg: API: | dimension meters +--------+ +------------------+ | flatmap +---------------------------+ +-----------\u0026amp;gt; | Default/DropwizardMetrics| | +---------------------------+ | | http +--------------+ +-----------\u0026amp;gt; |Lookout server| | +--------------+ +----------------------+ | add common tags dimension EXTS: | JVM,OS,GC... +----+ +----------------------+ Server-side services SOFALookout Server helps you solve system state metrics in a distributed environment. Its data sources include, but not limited to the projects that use the lookout-client package. The server will be available in the next release, so stay tuned.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/overview/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"8a8a8ef02ca95d4d11e3e4b195bbae70","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/overview/","summary":"Introduction SOFALookout is a lightweight and open source middleware service of Ant Financial that solves the metrics and monitoring issues of the system. The services it provides include: Event logging, collecting, processing, storing, and querying of Metrics. The open source project consists of two separate parts, the client and server side services.\nClient-side service SOFALookout Client is a Java SDK that helps developers log events of metrics in project code.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/overview/","wordcount":160},{"author":null,"categories":null,"content":" SOFARPC is a Java-based RPC service framework open sourced by Ant Financial, which provides remote service call between applications, high scalability and fault tolerance features. Currently, all RPC calls of Ant Financial businesses use SOFARPC. SOFARPC provides users with functions such as load balancing, traffic forwarding, link tracing, link data transparent transmission, and fault removal.\nIn addition, SOFARPC supports different protocols, currently including bolt, RESTful, dubbo, and H2C. Bolt is a network communication framework based on Netty developed by Ant Financial Services Group.\nImplementation principle When an SOFARPC application is started, if the current application needs to publish RPC services, SOFARPC will register these services to the service registry center. As shown in the figure, the service points to the Registry. When the SOFARPC application that references this service is started, it subscribes to the metadata information of the corresponding service from the service registry. After receiving the subscription request, the service registry will push the publisher\u0026amp;rsquo;s metadata list to the service reference party in real time. As shown in the figure, Register points to Reference. When the service reference party gets the addresses, it can pick up the address and initiate the call. As shown in the figure, Reference points to Service. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"62f0806ad40fcaaeab6a82470b14a2e2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/overview/","summary":"SOFARPC is a Java-based RPC service framework open sourced by Ant Financial, which provides remote service call between applications, high scalability and fault tolerance features. Currently, all RPC calls of Ant Financial businesses use SOFARPC. SOFARPC provides users with functions such as load balancing, traffic forwarding, link tracing, link data transparent transmission, and fault removal.\nIn addition, SOFARPC supports different protocols, currently including bolt, RESTful, dubbo, and H2C. Bolt is a network communication framework based on Netty developed by Ant Financial Services Group.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/overview/","wordcount":203},{"author":null,"categories":null,"content":" Introduction This sample project shows how to build an executable-ark-jar based on a springboot project with the tool of sofa-ark-maven-plugin.\nPreparation As this project depends on the ark-plugin generated by the project of sample-ark-plugin, please ensure the sample sample-ark-plugin installed in your local maven repository before run this project.\nTools The Maven plugin of sofa-ark-maven-plugin is provided to build a standard executable-ark-jar, and just needs some simple configurations. Its maven coordinates is:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Refer to the document of plugin use for details\n Step By Step Based on the sample project, we will describe step by step how to package a Spring Boot Web project to an executable Ark package\nCreating Spring Boot Web Project Download a standard Spring Boot Web project from the official website https://start.spring.io/\nIntroducing sample-ark-plugin Configure items as follows under the main pom.xml of the project, and add the Ark Plugin dependency generated from another sample project, reference documents\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configuring Packaging Plugin Configure the Maven plugin (sofa-Ark-maven-plugin) as follows under the main pom.xml of the project:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; In this sample project, we have configured only a fraction of the items, but they are enough to generate an executable Ark package. The meaning of each configuration item is shown below: * outputDirectory: the directory for the output Ark package files after packaging of mvn package;\n arkClassifier: the value of classifier included in the Maven coordinates of the Ark specified for release, which is null by default; Note that arkClassifier is null by default. If you do not specify a classifier, the Jar package uploaded to the repository is actually an executable Ark package. If you need to distinguish it from common packaging, you need to configure a value for this …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-demo/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2c97c409788f41051c79836d277997be","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","summary":"Introduction This sample project shows how to build an executable-ark-jar based on a springboot project with the tool of sofa-ark-maven-plugin.\nPreparation As this project depends on the ark-plugin generated by the project of sample-ark-plugin, please ensure the sample sample-ark-plugin installed in your local maven repository before run this project.\nTools The Maven plugin of sofa-ark-maven-plugin is provided to build a standard executable-ark-jar, and just needs some simple configurations. Its maven coordinates is:","tags":null,"title":"Package into Ark JAR","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","wordcount":757},{"author":null,"categories":null,"content":" Introduction This sample project demonstrates how to use Maven plugins to package a general Java project into an Ark plugin that meets the standard specifications.\nBackground In actual development, dependency conflicts often occur. Suppose we have developed a class library named sample-lib, and it might conflict with the existing dependencies when the business application is imported. At this point, we hope the library can be isolated from other business dependencies, without negotiating with each other over dependency package versions. Ark Plugin is exactly the result of our best practice under this demand background. It runs on top of the Ark Container, which is loaded by a container. Any Ark Plugin is loaded by a separate ClassLoader to be isolated from each other. There are four concepts of Ark Plugin: * Import class: When the plugin starts up, a plugin used to export the class is first delegated to load the class. If that fails, it will attempt to load from inside this plugin;\n Export class: If the class has been imported by other plugins, it will be first loaded from this plugin;\n Import resource: When the plugin is searching for resources, a plugin used to export the class is first delegated to load the class. If that fails, it will attempt to load from inside this plugin.\n Export resource: If the resource has been imported by other plugins, it will be first loaded from this plugin;\n Refer to the plugin specifications for more details\n Tools Upon simple configurations, the officially provided Maven plugin sofa-ark-plugin-maven-plugin can package common Java projects into a standard-format Ark Plugin. The coordinates of Maven plugin are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; For more information, see the plugin configuration document\n Getting started Based on this sample project, we will describe how to build an Ark plugin step by step.\nCreate a Standard Maven Project This is a standard Maven project consisting of two modules: * The common module: contains the plugin export class\n The plugin module: contains com.alipay.sofa.ark.spi.service.PluginActivator interface implementation class and a plugin service class. The plugin packaging tool sofa-ark-plugin-maven-plugin can be configured in the module\u0026amp;rsquo;s pom.xml file; Configuring Packaging Plugin Package the plugin in the pom.xml file according to the following configurations:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${project.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--can only configure no more than one activator--\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin-demo/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d8125843ced13352dd228299f222c74d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","summary":"Introduction This sample project demonstrates how to use Maven plugins to package a general Java project into an Ark plugin that meets the standard specifications.\nBackground In actual development, dependency conflicts often occur. Suppose we have developed a class library named sample-lib, and it might conflict with the existing dependencies when the business application is imported. At this point, we hope the library can be isolated from other business dependencies, without negotiating with each other over dependency package versions.","tags":null,"title":"Package into Ark Plugin","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","wordcount":664},{"author":null,"categories":null,"content":"SOFA Mesh 项目 fork 了 Istio 项目，对 Pilot 的能力进行增强，目前在进行中的增强主要集中在下面三个方面： - 支持 Zookeeper 作为注册中心，并在此基础上支持 SOFA、DUBBO 等使用 Zookeeper 作为注册中心的微服务框架。 - 支持通用协议框架，使用一个通用协议，在 Kubernetes DNS 的基础上同时支持多种协议。 - 新增 register agent，支持 SOFA、DUBBO 和 HSF 的容器模型，即支持单个应用注册多个服务实例。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-readme/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7b098e394986596d8fb01e1fe2120829","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-readme/","summary":"SOFA Mesh 项目 fork 了 Istio 项目，对 Pilot 的能力进行增强，目前在进行中的增强主要集中在下面三个方面： - 支持 Zookeeper 作为注册中心，并在此基础上支持 SOFA、DUBBO","tags":null,"title":"Pilot 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-readme/","wordcount":168},{"author":null,"categories":null,"content":" Print traceId And spanId To Application Log SLF4J provides MDC (Mapped Diagnostic Contexts), which supports you to define and modify log output formats and content. This document introduces the SLF4J MDC feature integrated in SOFATracer, which allows you to output the current SOFATracer context TraceId and SpanId with simply modifying the log configuration file.\nPrerequisites In order to properly print the TraceId and SpanId parameters in the logs of the application, the log programming interface needs to be programmed for SLF4J. That is, the programming interface for printing log does not rely on specific log implementation.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce dependency For SOFABoot or Spring Boot application, you need to introduce the specific log implementation. It is recommended to introduce Logback and Log4j2 instead of Log4j. Also, it is suggested to use only one log implementation rather than multiple implementations.\n Logback implementation: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Log4j2 implementation: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-log4j2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!--SOFABoot does not control log4j2 version --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configuration method The corresponding TraceId and SpanId are printed based on SLF4J MDC. First, the log programming interface in application should be oriented to SLF4J, as follows:\n/ / Introduce interface import org.slf4j.Logger; import org.slf4j.LoggerFactory; / / Construct log printing instance private static final Logger logger = LoggerFactory.getLogger(XXX.class); Second, to correctly print the TraceId and SpanId parameters, we also need to configure the extra parameters of PatternLayout in the log configuration file. The two parameters are %X{SOFA-TraceId} and %X. {SOFA-SpanId}, whose values ​​can be obtained from MDC.\npattern parameter configured with Logback as an example:\n\u0026amp;lt;pattern\u0026amp;gt;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId}, %X{SOFA-SpanId}] ---- %m%n\u0026amp;lt;/pattern\u0026amp;gt; Key configuration items: As a part of the Logback pattern, [%X{SOFA-TraceId},%X{SOFA-SpanId}] replaces the placeholders in the pattern with the specific TraceId and SpanId in the current thread process when the corresponding appender is called. If there is no corresponding TraceId and SpanId in the current thread, the placeholder is replaced with \u0026amp;ldquo;null\u0026amp;rdquo;. Log4j2 PatternLayout configuration sample:\n\u0026amp;lt;PatternLayout pattern=\u0026amp;quot;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId},%X{SOFA-SpanId}] ---- %m%n \u0026amp;quot; /\u0026amp;gt; Log4j PatternLayout configuration sample:\n\u0026amp;lt;layout class=\u0026amp;quot;org.apache.log4j.PatternLayout\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;param …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/print-traceid-spanid/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0d8cc680f811d1db2cffddbba269571c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","summary":"Print traceId And spanId To Application Log SLF4J provides MDC (Mapped Diagnostic Contexts), which supports you to define and modify log output formats and content. This document introduces the SLF4J MDC feature integrated in SOFATracer, which allows you to output the current SOFATracer context TraceId and SpanId with simply modifying the log configuration file.\nPrerequisites In order to properly print the TraceId and SpanId parameters in the logs of the application, the log programming interface needs to be programmed for SLF4J.","tags":null,"title":"Print traceId and spanId in application log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","wordcount":360},{"author":null,"categories":null,"content":"Describe several methods to use SOFARPC in different environments. * Use API in non-Spring environment * Use XML in SOFABoot environment * Use Annotation in SOFABoot environment * Use dynamic API in SOFABoot environment\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programming/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"9a947dae761c84aa4d95121c076ac552","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programming/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programming/","summary":"Describe several methods to use SOFARPC in different environments. * Use API in non-Spring environment * Use XML in SOFABoot environment * Use Annotation in SOFABoot environment * Use dynamic API in SOFABoot environment","tags":null,"title":"Programming","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programming/","wordcount":34},{"author":null,"categories":null,"content":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-samples/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"600c182fdee786a59e14899ba0fce8a1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-run-samples/","summary":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-run-samples/","wordcount":42},{"author":null,"categories":null,"content":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-run-samples/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"93784b2fca67986e00aa3bc5ea0dbb6b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-run-samples/","summary":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-run-samples/","wordcount":42},{"author":null,"categories":null,"content":" Some sample projects are provided in the source project to assist in the use of the project. The readme file of the sample project has additional instructions for use, and you need to import these sample projects separately into IDE.\nClient-side sample project lookout-client-samples-java  This sample project demonstrates how to use and configure the client in code form in a normal Java project.\n lookout-client-samples-boot  This sample project demonstrates how to use and configure the client in a SpringBoot (or SofaBoot) project.\n lookout-client-samples-prometheus  The sample project demonstrates how to use and configure the client to use prometheus in a SpringBoot (or SofaBoot) project.\nServer-side sample project ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-samples/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a8a0fcd3f99ce2fb46e4d543e30797c9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","summary":"Some sample projects are provided in the source project to assist in the use of the project. The readme file of the sample project has additional instructions for use, and you need to import these sample projects separately into IDE.\nClient-side sample project lookout-client-samples-java  This sample project demonstrates how to use and configure the client in code form in a normal Java project.\n lookout-client-samples-boot  This sample project demonstrates how to use and configure the client in a SpringBoot (or SofaBoot) project.","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","wordcount":105},{"author":null,"categories":null,"content":" SOFABoot provides developers with three ways to publish and reference JVM services\n XML Annotation Programming API XML Service Publish First, we need to define a Bean:\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; Then, publish the Bean as a SOFA JVM service by using the Spring extension tag provided by SOFA.\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; In the preceding configuration, the interface parameter indicates the interface for releasing services, and the ref parameter indicates the Bean to be published as a JVM service.\nAt this point, we have published a JVM service success.\nService Reference We can also reference a JVM service by using the Spring extension tag provided by SOFA.\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; In the preceding configuration, the interface parameter indicates the service interface, which must be consistent with that configured during the service publish. The meaning of the ID attribute is the same as Spring BeanId. A Spring Bean with the ID sampleServiceRef will be generated from the above configuration. We can inject it anywhere in the Spring context of the current SOFABoot module.\n service/reference tag also supports RPC service publish, with related document: RPC Service Publish and Reference\n Annotation Warning\nIf a service has been annotated with @SofaService, it cannot be published in the mode of XML. Choose one mode to publish the service instead of a mixture of two modes.\n In addition to publishing JVM services and reference through XML, SOFABoot also provides Annotation for JVM services publish and reference. To publish JVM services through Annotation, we only need to add an annotation @SofaService to the implementation class, as follows:\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } Prompt\n@SofaService is used to publish a Spring Bean as a JVM service, which means that although you may not write the configuration of \u0026amp;lt;sofa:service/\u0026amp;gt;, you still need to configure the class annotated with @SofaService as a Spring Bean.\n When configuring \u0026amp;lt;sofa:service/\u0026amp;gt; in the XML mode, you have configured an interface for the service. However, when using the @SofaService annotation, you haven\u0026amp;rsquo;t configured the service interface. This is because when the class annotated with @SofaService has implemented only one interface, the framework directly uses the interface as the service interface. What if the class annotated with @SofaService has implemented multiple interfaces? In this case, you can set the interfaceType field of @SofaService to specify the service interface, as shown below: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/module-service/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"527472fbe57ce450e4e2b41d878704cb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/module-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/module-service/","summary":"SOFABoot provides developers with three ways to publish and reference JVM services\n XML Annotation Programming API XML Service Publish First, we need to define a Bean:\n\u0026lt;bean id=\u0026quot;sampleService\u0026quot; class=\u0026quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026quot;\u0026gt; Then, publish the Bean as a SOFA JVM service by using the Spring extension tag provided by SOFA.\n\u0026lt;sofa:service interface=\u0026quot;com.alipay.sofa.runtime.test.service.SampleService\u0026quot; ref=\u0026quot;sampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.jvm/\u0026gt; \u0026lt;/sofa:service\u0026gt; In the preceding configuration, the interface parameter indicates the interface for releasing services, and the ref parameter indicates the Bean to be published as a JVM service.","tags":null,"title":"Publish and reference JVM services","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/module-service/","wordcount":1001},{"author":null,"categories":null,"content":" To run this demo, you should sign up an Ant Financial technology account. Please see Ant Finanical Official Site to see more details.\nDemo content Service Mesh applies the communication capabilities between services to the infrastructure, thus decoupling and lightweighting applications.\nHowever, Service Mesh itself is still complex. CloudMesh can easily implement Service Mesh technology by hosting Service Mesh on the cloud.\nWith our workshop, you can easily deploy applications developed in multiple programming languages ​​to CloudMesh, thereby experiencing the capabilities of Service Mesh. The capabilities include accessing services, monitoring traffic, experiencing service goverance, managing Sidecar, and gray release of new versions of services.\nThis demo focuses on the powerful traffic control capability of CloudMesh. In the process of gray release, you can precisely control the gray traffic ratio, and monitor the actual traffic trend in CloudMesh:\nThe general gray release function occupies twice capacity in the gray process.\nThe gray release function of CloudMesh does not need to occupy extra capacity in gray release process, and also allows pausing the release process to modify gray ratio multiple times.\nOperation guide For convenience, we have prepared a detailed operation guide for this demo.\nClick here to visit online version.\n","date":-62135596800,"description":"This guide introduces how to quickly deploy applications to CloudMesh, access services, monitor traffic, experience service governance, manage Sidecar, and perform gray release of new versions of services.","dir":"guides/kc-cloud-mesh-demo/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e389a65e6736e909718275cd76505525","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-cloud-mesh-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/guides/kc-cloud-mesh-demo/","summary":"To run this demo, you should sign up an Ant Financial technology account. Please see Ant Finanical Official Site to see more details.\nDemo content Service Mesh applies the communication capabilities between services to the infrastructure, thus decoupling and lightweighting applications.\nHowever, Service Mesh itself is still complex. CloudMesh can easily implement Service Mesh technology by hosting Service Mesh on the cloud.\nWith our workshop, you can easily deploy applications developed in multiple programming languages ​​to CloudMesh, thereby experiencing the capabilities of Service Mesh.","tags":null,"title":"Put Service Mesh into practice with CloudMesh","type":"guides","url":"/sofastack.tech/en/guides/kc-cloud-mesh-demo/","wordcount":199},{"author":null,"categories":null,"content":" This topic comprises four parts:\n Part 1: Install the ACTS IDE visual editor on Intellij IDEA. Part 2: Import the ACTS dependency to a multi-module project. Part 3: Establish the ACTS framework in the test module to manage ACTS test cases. Part 4: Generate the ACTS test script. 1. Install ACTS IDE We recommend that you use Intellij IDEA 2017. For the sake of your data security, please download the ACTS IDE installation package from the following source only: Click to download ACTS IDE.\nLocal installation: Choose Preferences \u0026amp;gt; Plugins. Install the plugin from disk and restart Intellij IDEA. 2. Import the ACTS dependency Before introducing the dependencies, make sure your application is a multi-module project (including the test module). After you import the dependency, ACTS places all test code under the test module for convenient ACTS test case management.\nYou can read the following information based on the actual situation of your application:\nIf your application is a complete multi-module project, you can refer to section 2.1 to import the ACTS dependency. If your application is a multi-module project without a test module, you can refer to section 2.2 to quickly create a test module. If your application is not a multi-module project, you can refer to section 2.3 to quickly create a multi-module project. If you have not created a project yet, you can use SOFABoot to quickly create an application.\n2.1 Multi-module application - with the test module You only need to import acts-bom to the pom.xml file of the test module.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2 Multi-module application - without the test module Here, Intellij IDEA is used to create the submodule.\nRight click the parent project, choose New \u0026amp;gt; Module, and enter the name for the test module, which follows the pattern of appname-test. The step-by-step procedure is illustrated in the following figures.\nStep 1: Create a test module Step 2: Manage the test module Manage the test module that you have created in the pom.xml file under the parent project.\nStep 3: Import the ACTS dependency Find the test module that you just created and import acts-bom to its pom.xml file.\n\u0026amp;lt;! -- Import the pom file that contains SOFABootApplication --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.example\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;example-service\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;! -- Import the ACTS dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.3 Single-module application If you already have a sound single-module SOFABoot application, you can quickly create a multi-module project based on the existing project in the following …","date":-62135596800,"description":"","dir":"projects/sofa-acts/getting-started/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dfc5fb9b394ea14c280568dcb881a8b0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/getting-started/","summary":"This topic comprises four parts:\n Part 1: Install the ACTS IDE visual editor on Intellij IDEA. Part 2: Import the ACTS dependency to a multi-module project. Part 3: Establish the ACTS framework in the test module to manage ACTS test cases. Part 4: Generate the ACTS test script. 1. Install ACTS IDE We recommend that you use Intellij IDEA 2017. For the sake of your data security, please download the ACTS IDE installation package from the following source only: Click to download ACTS IDE.","tags":null,"title":"Quick start","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/getting-started/","wordcount":650},{"author":null,"categories":null,"content":" This topic helps you quickly download, install, and use SOFADashboard on your computer.\nPrepare the environment sofa-dashboard-backend needs to be run in a Java environment. Make sure that it can be used normally in the following runtime environments:\n JDK 1.8+: Download and Configure. Maven 3.2.5+: Download and Configure. sofa-dashboard-frontend uses the Ant Design Pro scaffold. For more information about the frontend environment, see Ant Design.\nInitialize the database MySQL version: 5.6+\n SOFAArk control uses MySQL for resource data storage. You can find the SofaDashboardDB.sql script under the project directory and run this script to initialize database tables.\nZooKeeper ZooKeeper 3.4.x and ZooKeeper 3.5.x\n Service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper, therefore you need to start the ZooKeeper service locally. For more information, see ZooKeeper Document.\nRun the backend project \u0026amp;gt; git clone https://github.com/sofastack/sofa-dashboard.git \u0026amp;gt; cd sofa-dashboard \u0026amp;gt; mvn clean package -DskipTests \u0026amp;gt; cd sofa-dashboard-backend/sofa-dashboard-web/target/ \u0026amp;gt; java -jar sofa-dashboard-web-1.0.0-SNAPSHOT.jar Run the frontend project sofa-dashboard-front is the frontend code-based project of SOFADashboard. It is developed based on the open-source frontend framework antd of Ant Financial.\n\u0026amp;gt; cd sofa-dashboard-front \u0026amp;gt; npm i \u0026amp;gt; npm start ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/quick-start/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fa4c5f48810727f71d675255f19617a3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/quick-start/","summary":"This topic helps you quickly download, install, and use SOFADashboard on your computer.\nPrepare the environment sofa-dashboard-backend needs to be run in a Java environment. Make sure that it can be used normally in the following runtime environments:\n JDK 1.8+: Download and Configure. Maven 3.2.5+: Download and Configure. sofa-dashboard-frontend uses the Ant Design Pro scaffold. For more information about the frontend environment, see Ant Design.\nInitialize the database MySQL version: 5.","tags":null,"title":"Quick start","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/quick-start/","wordcount":186},{"author":null,"categories":null,"content":" This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment. Install Go\u0026amp;rsquo;s build environment. Install dep. See the official installation documentation. Get codes The codes for the MOSN project are hosted in GitHub and can be obtained in the following way:\ngo get mosn.io/mosn If an error occurs when run \u0026amp;ldquo;go get\u0026amp;rdquo;, just create the project manually.\n# Enter src dirctory under GOPATH cd $GOPATH/src # Create mosn.io dirctory mkdir -p mosn.io cd mosn.io # clone MOSN codes git clone git@github.com:mosn/mosn.git cd sofa-mosn The final path of MOSN source codes is $GOPATH/src/mosn.io/mosn.\nImport by using IDE Use the Golang IDE to import the $GOPATH/src/mosn.io/mosn project. Goland is recommended.\nCompile codes In the project root directory, select the following command to compile the MOSN binary file according to your machine type and the environment where you want to execute binary:\nCompile with Docker image\nmake build // compile linux 64bit executable binary non-docker, local compilation\nCompile local executable binary files.\nmake build-local Non-Linux machine compiles Linux 64-bit executable binary files crosswise.\nmake build-linux64 Non-Linux machine compiles Linux 32-bit executable binary files crosswise.\nmake build-linux32 Once compiled, the compiled binary files can be found in the build/bundles/${version}/binary directory.\nCreate image Run the following command to create an image:\nmake image Run test In the project root directory, run the unit test:\nmake unit-test In the project root directory, run the integrate test(slow):\nmake integrate Start MOSN from configuration file ./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; Start MOSN forwarding sample program See the sample project in the examples directory.\nUse MOSN to build a Service Mesh platform See Integrate Istio.\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-setup/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d41615315adb522aa4b84762f113a574","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-setup/","summary":"This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-setup/","wordcount":325},{"author":null,"categories":null,"content":" This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment. Install Go\u0026amp;rsquo;s build environment. Install dep. See the official installation documentation. Get codes The codes for the MOSN project are hosted in GitHub and can be obtained in the following way:\ngo get mosn.io/mosn If an error occurs when run \u0026amp;ldquo;go get\u0026amp;rdquo;, just create the project manually.\n# Enter src dirctory under GOPATH cd $GOPATH/src # Create mosn.io dirctory mkdir -p mosn.io cd mosn.io # clone MOSN codes git clone git@github.com:mosn/mosn.git cd sofa-mosn The final path of MOSN source codes is $GOPATH/src/mosn.io/mosn.\nImport by using IDE Use the Golang IDE to import the $GOPATH/src/mosn.io/mosn project. Goland is recommended.\nCompile codes In the project root directory, select the following command to compile the MOSN binary file according to your machine type and the environment where you want to execute binary:\nCompile with Docker image\nmake build // compile linux 64bit executable binary non-docker, local compilation\nCompile local executable binary files.\nmake build-local Non-Linux machine compiles Linux 64-bit executable binary files crosswise.\nmake build-linux64 Non-Linux machine compiles Linux 32-bit executable binary files crosswise.\nmake build-linux32 Once compiled, the compiled binary files can be found in the build/bundles/${version}/binary directory.\nCreate image Run the following command to create an image:\nmake image Run test In the project root directory, run the unit test:\nmake unit-test In the project root directory, run the integrate test(slow):\nmake integrate Start MOSN from configuration file ./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; Start MOSN forwarding sample program See the sample project in the examples directory.\nUse MOSN to build a Service Mesh platform See Integrate Istio.\n","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-setup/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"cd757e2e2cca38a99b2de1c0be1f6807","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-setup/","summary":"This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-setup/","wordcount":325},{"author":null,"categories":null,"content":" In this document, we will create a Spring Boot project and introduce the basic dependencies of SOFABoot as well as its Health Check expansion capability, to demonstrate how to get started quickly with SOFABoot.\nEnvironment Preparation To use SOFABoot, we need to prepare the basic environment first. SOFABoot depends on the following environment: - JDK7 or JDK8 - Needs to be compiled with Apache Maven 3.2.5 or above\nCreate Project SOFABoot is directly built on Spring Boot, so it can be generated by Spring Boot Generators. In this document, we need to add a web dependency for final view of its effect in the browser.\nAdd SOFABoot dependencies When creating a Spring Boot project, we need to import SOFABoot dependencies. First, extract the \u0026amp;lsquo;zip\u0026amp;rsquo; package of the project generated above and modify the \u0026amp;lsquo;pom.xml\u0026amp;rsquo; file, or the maven project configuration file. Replace\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; as:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Here, ${sofa.boot.version} denotes the SOFABoot version (please refer to release note). Then, add a SOFABoot dependency of Health Check extension and Spring Boot Web Starter.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Finally, configure parameters commonly used in the SOFABoot project in the application.properties file. The spring.application.name parameter is required to name the current application; the logging path specifies the output directory for logging information.\n# Application Name spring.application.name=SOFABoot Demo # logging path logging.path=./logs Advice to refer to the SOFABoot Module document before learn this demo.\nRun it We can import the project into IDE and run the \u0026amp;lsquo;main\u0026amp;rsquo; method in the generated project (generally in the XXXApplication class) to start the application, or we can execute the mvn spring-boot:run command under the project\u0026amp;rsquo;s root directory, which will print the startup logging in the console:\n2018-04-05 21:36:26.572 INFO ---- Initializing ProtocolHandler [\u0026amp;quot;http-nio-8080\u0026amp;quot;] 2018-04-05 21:36:26.587 INFO ---- Starting ProtocolHandler [http-nio-8080] 2018-04-05 21:36:26.608 INFO ---- Using a shared selector for servlet write/read 2018-04-05 21:36:26.659 INFO ---- Tomcat started on port(s): 8080 (http) We can browse http://localhost:8080/sofaboot/versions to view the version summary generated by Maven plugin in SOFABoot. The result is …","date":-62135596800,"description":"","dir":"projects/sofa-boot/quick-start/","fuzzywordcount":1400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7f582b905fde4a56791c03d4dd6b5a57","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/quick-start/","summary":"In this document, we will create a Spring Boot project and introduce the basic dependencies of SOFABoot as well as its Health Check expansion capability, to demonstrate how to get started quickly with SOFABoot.\nEnvironment Preparation To use SOFABoot, we need to prepare the basic environment first. SOFABoot depends on the following environment: - JDK7 or JDK8 - Needs to be compiled with Apache Maven 3.2.5 or above\nCreate Project SOFABoot is directly built on Spring Boot, so it can be generated by Spring Boot Generators.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/quick-start/","wordcount":1381},{"author":null,"categories":null,"content":" SOFATracer integration component list reference:Introduction To SOFATracer, Please pay attention to the SOFATracer version and JDK version of different components when using.\nPrepare Environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: - JDK7 or JDK8 - Apache Maven 3.2.5+ required for compilation\nSamples List The following Samples projects are all SOFABoot projects (also supported in the SpringBoot project). For information on how to create SOFABoot projects, please refer to SOFABoot quick start.\n Component Integration Spring MVC Integration HttpClient Integration DataSource Integration RestTemplate Integration OkHttp Integration SOFARPC Integration Dubbo Integration Spring Cloud OpenFeign Integration Sampling Report Data To Zipkin ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/componentaccess/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"42fbb0f6b6d459b7b04d45cad143d4ff","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/componentaccess/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/componentaccess/","summary":"SOFATracer integration component list reference:Introduction To SOFATracer, Please pay attention to the SOFATracer version and JDK version of different components when using.\nPrepare Environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: - JDK7 or JDK8 - Apache Maven 3.2.5+ required for compilation\nSamples List The following Samples projects are all SOFABoot projects (also supported in the SpringBoot project). For information on how to create SOFABoot projects, please refer to SOFABoot quick start.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/componentaccess/","wordcount":108},{"author":null,"categories":null,"content":" This project demonstrates how to use SOFALookout in SOFABoot and connect to the Actuator of Spring Boot. If you want to connect to Prometheus or other Registry, see the Registry section.\nCreate a SpringBoot (or SofaBoot) project Create a new Spring Boot application (In case of SOFABoot project, import to SOFABoot as described in SOFABoot Documentation - Dependency Management.\nIntroduce Lookout\u0026amp;rsquo;s Starter dependency Introduce the following dependency in pom.xml:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; In case of Spring Boot project, it is required to specify a version.\nCreate a Metrics indicator After completing the introduction of dependencies, you can add the following methods to the startup class in Spring Boot:\n@Autowired private Registry registry; @PostConstruct public void init() { Counter counter = registry.counter(registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;).withTag(\u0026amp;quot;instant\u0026amp;quot;, NetworkUtil.getLocalAddress().getHostName())); counter.inc(); } The above code directly injects a Registry field through @Autowired. Through the Registry field, you can create the corresponding Counter, and then modify the Counter data to generate the Metrics of the SOFALookout.\nAdd configuration item In SOFABoot project, you need to add a configuration item for the application name: spring.application.name=xxx.\nConnect to Spring Boot Actuator After adding a new indicator, you can choose to connect to the Spring Boot Actuator. Then the following dependency is required:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; After adding the above dependency, you can launch the application locally, visit http://localhost:8080/metrics, and you can see the metrics added earlier, as follows:\n\u0026amp;quot;http_requests_total.instant-MacBook-Pro-4.local\u0026amp;quot;: 1, The above codes are at lookout-client-samples-boot, you can Download them as a reference.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-boot/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"27e057f8a8a4ac97f42ea66ca6a17fdd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","summary":"This project demonstrates how to use SOFALookout in SOFABoot and connect to the Actuator of Spring Boot. If you want to connect to Prometheus or other Registry, see the Registry section.\nCreate a SpringBoot (or SofaBoot) project Create a new Spring Boot application (In case of SOFABoot project, import to SOFABoot as described in SOFABoot Documentation - Dependency Management.\nIntroduce Lookout\u0026rsquo;s Starter dependency Introduce the following dependency in pom.xml:","tags":null,"title":"Quick start guide for SOFABoot project","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","wordcount":244},{"author":null,"categories":null,"content":" Quick start for client Common Java Project Add the Maven dependency of the client to the application:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Lookout-client relies on the lookout-reg-server module by default (supports reporting metrics data to the lookout server). If you want to use a different type of registry (such as lookout-reg-prometheus), then add the corresponding dependency.\nBefore starting to use the SOFALookout Client, you must firstly build a global client instance (com.alipay.lookout.client.DefaultLookoutClient).\nLookoutConfig lookoutConfig = new LookoutConfig(); DefaultLookoutClient client = new DefaultLookoutClient(\u0026amp;quot;appName\u0026amp;quot;); // Choose to build the Registry you need to use (if you need multiple registry types, it is recommended to use the same lookoutConfig instance for centralized management). LookoutRegistry lookoutRegistry = new LookoutRegistry(lookoutConfig); // Client can add a registry instance (at least one) after the client is created. client.addRegistry(lookoutRegistry); // (Optional) Uniformly register the metrics of extended modules for the registry instances that have been added or will be added to the client. client.registerExtendedMetrics(); Then get the Registry instance through the client and use it:\n// The registry is a \u0026amp;quot;combination\u0026amp;quot; registry Registry registry = client.getRegistry(); //demo Id id = registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;); Counter counter = registry.counter(id); counter.inc(); For the use of the client, see Project sample.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-java/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5dc476aa21ece4789859f1af598d4445","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","summary":"Quick start for client Common Java Project Add the Maven dependency of the client to the application:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa.lookout\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;lookout-client\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${lookout.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Lookout-client relies on the lookout-reg-server module by default (supports reporting metrics data to the lookout server). If you want to use a different type of registry (such as lookout-reg-prometheus), then add the corresponding dependency.\nBefore starting to use the SOFALookout Client, you must firstly build a global client instance (com.","tags":null,"title":"Quick start guide for common Java project","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","wordcount":197},{"author":null,"categories":null,"content":" For REST，we provide a Filter to support cors now.\nSOFARPC API Usage For users who use SOFARPC API directly，they can add parameters in ServerConfig.\nMap\u0026amp;lt;String,String\u0026amp;gt; parameters=new HashMap\u0026amp;lt;String, String\u0026amp;gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026amp;quot;abc.com,cdf.com\u0026amp;quot;); serverConfig.setParameters(parameters); XML Usage You can add this configuration to application.properties\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-cors/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"549f73920842ebb121abf87566761c47","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-cors/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-cors/","summary":" For REST，we provide a Filter to support cors now.\nSOFARPC API Usage For users who use SOFARPC API directly，they can add parameters in ServerConfig.\nMap\u0026lt;String,String\u0026gt; parameters=new HashMap\u0026lt;String, String\u0026gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026quot;abc.com,cdf.com\u0026quot;); serverConfig.setParameters(parameters); XML Usage You can add this configuration to application.properties\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com ","tags":null,"title":"REST Cors","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-cors/","wordcount":40},{"author":null,"categories":null,"content":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。如果希望有一个通用的 异常处理类，用来处理REST的某中异常类型的信息。可以实现一个REST 的处理类。如下示例是一个拦截SofaRpcException 的通用处理器。\n@PreMatching public class CustomExceptionMapper implements ExceptionMapper\u0026amp;lt;SofaRpcException\u0026amp;gt; { @Override public Response toResponse(SofaRpcException exception) { return Response.status(500).entity(exception.getMessage()).build(); } } 并将该处理器注册到JAXRSProviderManager中，时机可以在Main方法中。具体说明可以参考RESTful-Filter。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-exception/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0ff4ef4139b228537d2ce4d52a213651","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-exception/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-exception/","summary":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。如果希望有一个通用的 异常处理类，用来处理REST的某中异常类型的","tags":null,"title":"REST Exception","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-exception/","wordcount":204},{"author":null,"categories":null,"content":"For REST, we designed a JAXRSProviderManager manager class. It takes effect on the server when the service starts.\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider For the user-defined Filter class, you can call it after the initialization is complete.\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance To register filter, since the custom Filter follows REST specification, you need to implement the following interface:\njavax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.container.ContainerRequestFilter After the REST server is started, if using bare SOFARPC, you need to register filter first before starting the service. In SOFABoot environment, it is similar. The specific encoding method is as follows:\ncom.alipay.sofa.rpc.server.rest.TraceRequestFilter com.alipay.sofa.rpc.server.rest.TraceResponseFilter ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-filter/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"53eb86b2504bf3beda2aca24437d6dab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-filter/","summary":"For REST, we designed a JAXRSProviderManager manager class. It takes effect on the server when the service starts.\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider For the user-defined Filter class, you can call it after the initialization is complete.\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance To register filter, since the custom Filter follows REST specification, you need to implement the following interface:\njavax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.container.ContainerRequestFilter After the REST server is started, if using bare SOFARPC, you need to register filter first before starting the service.","tags":null,"title":"REST filter","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-filter/","wordcount":89},{"author":null,"categories":null,"content":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider 对于用户自定义的 Filter 类，可以在初始化完成后，调用\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance 进行注册，其中自定义的 Filter 遵循 REST 的规范，需要实现如下接口：\njavax.ws.rs.container.ContainerResponseFilter 或者 javax.ws.rs.container.ContainerRequestFilter REST server 启动之后，对于裸 SOFARPC 的使用，需要先注册，再启动服务。对于 SOFABoot 环境下的使用，也是类似的过程，具体的写法可以参考：\ncom.alipay.sofa.rpc.server.rest.TraceRequestFilter com.alipay.sofa.rpc.server.rest.TraceResponseFilter ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-filter/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"53eb86b2504bf3beda2aca24437d6dab","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-filter/","summary":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。 com.alipay.sofa.rpc.server.rest.RestServer#registerProvider 对于用户自定义的 Filter 类，可以在初始化完成后，调用 com.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance 进行注册，其中","tags":null,"title":"REST 自定义 Filter","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-filter/","wordcount":152},{"author":null,"categories":null,"content":" 对于 REST，我们内置了一个跨域 Filter 的支持。\nSOFARPC API 使用 对于使用 SOFARPC API 的用户，可以在 ServerConfig 中添加一个参数表明即可\nMap\u0026amp;lt;String,String\u0026amp;gt; parameters=new HashMap\u0026amp;lt;String, String\u0026amp;gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026amp;quot;abc.com,cdf.com\u0026amp;quot;); serverConfig.setParameters(parameters); XML 方式使用 直接通过配置\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com 即可\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-cors/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"549f73920842ebb121abf87566761c47","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-cors/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-cors/","summary":"对于 REST，我们内置了一个跨域 Filter 的支持。 SOFARPC API 使用 对于使用 SOFARPC API 的用户，可以在 ServerConfig 中添加一个参数表明即可 Map\u0026lt;String,String\u0026gt; parameters=new HashMap\u0026lt;String, String\u0026gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026quot;abc.com,cdf.com\u0026quot;); serverConfig.setParameters(parameters); XML 方式使用 直接通过配置 com.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com 即可","tags":null,"title":"REST 跨域","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-cors/","wordcount":70},{"author":null,"categories":null,"content":"SOFARPC supports RESTful protocol, making it convenient for users to publish an interface in the manner of RESTful. * Basic usage * Custom Filter * Integrate Swagger\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f238d7f58de0c4a0e12d566ea9e09f52","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful/","summary":"SOFARPC supports RESTful protocol, making it convenient for users to publish an interface in the manner of RESTful. * Basic usage * Custom Filter * Integrate Swagger","tags":null,"title":"RESTful","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful/","wordcount":27},{"author":null,"categories":null,"content":"SOFARPC 提供了 RESTful 协议的支持，可以让用户非常方便地将一个接口通过 RESTful 的方式发布出去。 * 基本使用 * 自定义 Filter * 通用异常处理 * 集成 Swagger\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f238d7f58de0c4a0e12d566ea9e09f52","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful/","summary":"SOFARPC 提供了 RESTful 协议的支持，可以让用户非常方便地将一个接口通过 RESTful 的方式发布出去。 * 基本使用 * 自定义 Filter * 通用异常处理 * 集成 Swagger","tags":null,"title":"RESTful 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful/","wordcount":58},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议即使用不同的 Binding 即可，如果需要使用 RESTful 协议，只要将 Binding 设置为 REST 即可。\n发布服务 在定义 RESTful 的服务接口的时候，需要采用 JAXRS 标准的注解在接口上加上元信息，比如下面的接口：\n@Path(\u0026amp;quot;sample\u0026amp;quot;) public interface SampleService { @GET @Path(\u0026amp;quot;hello\u0026amp;quot;) String hello(); } JAXRS 的标准的注解的使用方式可以参考 RESTEasy 的文档。\n 在定义好了接口之后，将接口的实现发布成一个服务，比如，通过 Annotation 的方式：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}) public class RestfulSampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } 如果要通过其他的方式发布服务，请参考 Bolt 协议基本使用。\n通过浏览器访问服务 在发布服务之后，用户可以通过浏览器来直接访问服务，对于上面的服务，访问的地址如下：\nhttp://localhost:8341/sample/hello SOFARPC 的 RESTful 服务的默认端口为 8341。\n引用服务 除了通过浏览器访问 SOFARPC 发布的 RESTful 服务之外，用户也可以通过 SOFARPC 标准的服务引用的方式来引用服务，比如通过 Annotation 的方式：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)) private SampleService sampleService; 如果要使用其他的方式引用服务，请参考 Bolt 协议基本使用。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-basic/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d41f976864ba8f8221f5b5d26f354d1c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-basic/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-basic/","summary":"在 SOFARPC 中，使用不同的通信协议即使用不同的 Binding 即可，如果需要使用 RESTful 协议，只要将 Binding 设置为 REST 即可。 发布服务 在定义 RESTful 的服务接口的时候，需要采用 JAXRS 标准的注","tags":null,"title":"RESTful 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-basic/","wordcount":358},{"author":null,"categories":null,"content":"In SOFABoot, the RPC framework provides some configuration parameters at the application level, and supports application-level parameter configuration, such as port and thread pool, which are bound by Spring Boot\u0026amp;rsquo;s @ConfigurationProperties. The binding attribute class is com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties, and the configuration prefix is as follows:\nstatic final String PREFIX = \u0026amp;quot;com.alipay.sofa.rpc\u0026amp;quot;; Then in the application.properties file, you can currently configure the following options. Also, you can write the codes based on your own coding habits as well as according to the Spring Boot specification, camel, underline and so on.\n#Standalone fault tolerance com.alipay.sofa.rpc.aft.regulation.effective # Whether to enable standalone fault tolerance com.alipay.sofa.rpc.aft.degrade.effective # Whether to enable degradation com.alipay.sofa.rpc.aft.time.window # Time window com.alipay.sofa.rpc.aft.least.window.count # Minimum number of calls com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple # minimum exception rate com.alipay.sofa.rpc.aft.weight.degrade.rate # Degradation rate com.alipay.sofa.rpc.aft.weight.recover.rate # Recovery rate com.alipay.sofa.rpc.aft.degrade.least.weight #Minimum degrading weight com.alipay.sofa.rpc.aft.degrade.max.ip.count # Maximum number of degraded IPs # bolt com.alipay.sofa.rpc.bolt.port # bolt port com.alipay.sofa.rpc.bolt.thread.pool.core.size # Number of bolt core threads com.alipay.sofa.rpc.bolt.thread.pool.max.size # Maximum number of bolt threads com.alipay.sofa.rpc.bolt.thread.pool.queue.size # bolt thread pool queue com.alipay.sofa.rpc.bolt.accepts.size # Number of connections that server allows client to establish # rest com.alipay.sofa.rpc.rest.hostname # rest hostname com.alipay.sofa.rpc.rest.port # rest port com.alipay.sofa.rpc.rest.io.thread.size # Number of rest io threads com.alipay.sofa.rpc.rest.context.path # rest context path com.alipay.sofa.rpc.rest.thread.pool.core.size # Number of rest core threads com.alipay.sofa.rpc.rest.thread.pool.max.size # Maximum number of rest threads com.alipay.sofa.rpc.rest.max.request.size # Maximum rest request size com.alipay.sofa.rpc.rest.telnet # Whether to allow rest telnet com.alipay.sofa.rpc.rest.daemon # Whether to hold the port. If true, exit with the main thread exit # dubbo com.alipay.sofa.rpc.dubbo.port # dubbo port com.alipay.sofa.rpc.dubbo.io.thread.size # dubbo io thread size com.alipay.sofa.rpc.dubbo.thread.pool.max.size # Maximum number of dubbo business threads com.alipay.sofa.rpc.dubbo.accepts.size # Number of connections that server allows client to establish com.alipay.sofa.rpc.dubbo.thread.pool.core.size #Number of dubbo core Threads com.alipay.sofa.rpc.dubbo.thread.pool.queue.size #Maximum number of dubbo threads # registry com.alipay.sofa.rpc.registry.address # Registry center address com.alipay.sofa.rpc.virtual.host # virtual host com.alipay.sofa.rpc.bound.host # bind host …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/application-rpc-config/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"bd19b2ced39a8deb802c13e525093fac","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","summary":"In SOFABoot, the RPC framework provides some configuration parameters at the application level, and supports application-level parameter configuration, such as port and thread pool, which are bound by Spring Boot\u0026rsquo;s @ConfigurationProperties. The binding attribute class is com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties, and the configuration prefix is as follows:\nstatic final String PREFIX = \u0026quot;com.alipay.sofa.rpc\u0026quot;; Then in the application.properties file, you can currently configure the following options. Also, you can write the codes based on your own coding habits as well as according to the Spring Boot specification, camel, underline and so on.","tags":null,"title":"RPC application parameter configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","wordcount":381},{"author":null,"categories":null,"content":" ProviderConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (unique identifier) filterRef Filter configuration example List filter Filter configuration alias separated by commas registry Registry center on the server List methods Method-level configuration Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect. subscribe Whether to subscribe true It depends on the implementation and may not take effect. proxy Proxy type javassist As well as JDK dynamic proxy ref Service interface implementation class server server List, and it can be sent to multiple servers at once delay Time for delaying service publishing Service delay weight Service static weight include Included methods exclude Methods not included dynamic Whether to dynamically register priority Service priority bootstrap Service publishing starter bolt executor Custom thread pool timeout Execution timeout period for server concurrents Concurrent execution request Maximum number of parallel executable requests per method under interface. -1 indicates turning off the concurrent filter, and 0 means that filtering is enabled but not limited cacheRef Result cache implementation class mockRef Mock implementation class mock Whether to enable Mock validation Whether to enable parameter verification (jsr303) compress Whether to start compression false cache Whether to enable result caching false parameters Extra attributes Map\u0026amp;lt;String, String\u0026amp;gt; ConsumerConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (Unique identifier) filterRef Filter configuration example List filter Filter configuration alias List registry Registry center on the server List methods Method-level configuration Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect. subscribe Whether to subscribe true It depends on the implementation and may not take effect. proxy proxy type javassist As well as JDK dynamic proxy protocol Call protocol bolt Currently supports bolt, rest, dubbo directUrl Direct address Directly connected to register generic Whether to generalize calls false connectTimeout Timeout period for connection establishment 3000(cover 5000) disconnectTimeout Timeout period for disconnection 5000(cover …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-common/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2eb5963f4785f5f828f0e15759272971","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration-common/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration-common/","summary":"ProviderConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (unique identifier) filterRef Filter configuration example List filter Filter configuration alias separated by commas registry Registry center on the server List methods Method-level configuration Map\u0026lt;String, MethodConfig\u0026gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect.","tags":null,"title":"RPC publishing and reference configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration-common/","wordcount":1118},{"author":null,"categories":null,"content":" ProviderConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 uniqueId 服务标签（唯一标识元素） filterRef 过滤器配置实例 List filter 过滤器配置别名 多个用逗号隔开 registry 服务端注册中心 List methods 方法级配置 Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization 序列化协议 hessian2 register 是否注册 true 取决于实现，可能不生效。 subscribe 是否订阅 true 取决于实现，可能不生效。 proxy 代理类型 javassist 还有JDK动态代理 ref 服务接口实现类 server 服务端 List，可以一次发到多个服务端 delay 服务延迟发布时间 服务延迟 weight 服务静态权重 include 包含的方法 exclude 不包含的方法 dynamic 是否动态注册 priority 服务优先级 bootstrap 服务发布启动器 bolt executor 自定义线程池 timeout 服务端执行超时时间 concurrents 并发执行请求 接口下每方法的最大可并行执行请求数，配置-1关闭并发过滤器，等于0表示开启过滤但是不限制 cacheRef 结果缓存实现类 mockRef Mock实现类 mock 是否开启Mock validation 是否开启参数验证(jsr303) compress 是否启动压缩 false cache 是否启用结果缓存 false parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; ConsumerConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 uniqueId 服务标签（唯一标识元素） filterRef 过滤器配置实例 List filter 过滤器配置别名 List registry 服务端注册中心 List methods 方法级配置 Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization 序列化协议 hessian2 register 是否注册 true 取决于实现，可能不生效。 subscribe 是否订阅 true 取决于实现，可能不生效。 proxy 代理类型 javassist 还有JDK动态代理 protocol 调用的协议 bolt 目前支持bolt，rest，dubbo directUrl 直连地址 直连后register generic 是否泛化调用 false connectTimeout 建立连接超时时间 3000(cover 5000) disconnectTimeout 断开连接等等超时时间 5000(cover 10000) cluster 集群模式 failover connectionHolder 连接管理器实现 all loadBalancer 负载均衡算法 random lazy 是否延迟建立长连接 false sticky 是否使用粘性连接 false 跳过负载均衡算法使用上一个地址 inJVM 是否转为JVM调用 true JVM发现服务提供者，转为走本地 check 是否检查强依赖 false 无可用服务端启动失败 heartbeat 心跳间隔 30000 客户端给服务端发心跳间隔。取决于实现，可能不生效。 reconnect 重连间隔 10000 客户端重建端口长连接的间隔。取决于实现，可能不生效。 router 路由器配置别名 List routerRef 路由器配置实例 List bootstrap 服务引用启动器 bolt addressWait 等待地址获取时间 -1 取决于实现，可能不生效。 timeout 调用超时时间 3000(cover 5000) retries 失败后重试次数 0 跟集群模式有关，failover读取此参数。 invokeType 调用类型 sync onReturn 并发执行请求数 接口下每方法的最大可并行执行请求数，\n配置-1关闭并发过滤器，等于0表示开启过滤但是不限制 cacheRef 结果缓存实现类 mockRef Mock实现类 cache 是否启用结果缓存 false mock 是否开启Mock validation 是否开启参数验证 基于JSR303 compress 是否启动压缩 false parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; rejectedExecutionPolicy 回调线程池满拒绝策略 DISCARD DISCARD：默认丢弃，CALLER_RUNS：IO 线程继续执行任务，CALLER_HANDLE_EXCEPTION：IO 线程执行异常回调任务 @since 5.8.1 MethodConfig 属性 名称 默认值 备注 name 方法名 timeout 调用超时时间 null retries 失败后重试次数 null invokeType 调用类型 null validation 是否开启参数验证 null 基于JSR303 onReturn 返回时调用的SofaResponseCallback null 用于实现Callback等 concurrent 并发执行请求数 null 接口下每方法的最大可并行执行请求数，配置-1关闭并发过滤器，等于0表示开启过滤但是不限制。 validation 是否开启参数验证 null compress 是否启动压缩 null parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; ServerConfig id Id 默认值 备注 protocol 协议 bolt 目前支持bolt，rest，dubbo host 主机 0.0.0.0 port 端口 12200 默认端口 bolt:12200, rest:8341, h2c:12300, dubbo:20880 contextPath …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-common/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2eb5963f4785f5f828f0e15759272971","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration-common/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration-common/","summary":"ProviderConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置","tags":null,"title":"RPC 发布订阅配置","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration-common/","wordcount":1868},{"author":null,"categories":null,"content":"在 SOFABoot 的使用场景下，RPC 框架在应用层面，提供一些配置参数，支持的应用级别的参数配置，如端口，线程池等信息，都是通过 Spring Boot的@ConfigurationProperties 进行的绑定。绑定属性类是com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties，配置前缀是\nstatic final String PREFIX = \u0026amp;quot;com.alipay.sofa.rpc\u0026amp;quot;; 那么在 application.properties 文件中，目前可以配置以下几个选项。其中使用者也可以根据自己的编码习惯，按照 Spring Boot的规范，按照驼峰，中划线等进行书写。\n单机故障剔除\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.aft.regulation.effective 是否开启单机故障剔除功能 Boolean false com.alipay.sofa.rpc.aft.degrade.effective 是否开启降级 Boolean false com.alipay.sofa.rpc.aft.time.window 时间窗口 Long 10 com.alipay.sofa.rpc.aft.least.window.count 最小调用次数 Long 10 com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple 最小异常率 Double 6.0 com.alipay.sofa.rpc.aft.weight.degrade.rate 降级速率 Double 0.05 com.alipay.sofa.rpc.aft.weight.recover.rate 恢复速率 Double 2.0 com.alipay.sofa.rpc.aft.degrade.least.weight 降级最小权重 Integer 1 com.alipay.sofa.rpc.aft.degrade.max.ip.count 最大降级 ip数量 Integer 2 Bolt\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.bolt.port bolt 端口 Integer 优先生效的是environment中是否设置rpc_tr_port，然后才是此处设置的值。默认12200 com.alipay.sofa.rpc.bolt.thread.pool.core.size bolt 核心线程数 Integer 20 com.alipay.sofa.rpc.bolt.thread.pool.max.size bolt 最大线程数 Integer 200 com.alipay.sofa.rpc.bolt.thread.pool.queue.size bolt 线程池队列 Integer 0 com.alipay.sofa.rpc.bolt.accepts.size bolt 服务端允许客户端建立的连接数 Integer 必须大于0，默认100000 com.alipay.sofa.rpc.bolt.process.in.io.thread bolt 服务端业务处理是否直接在worker中处理 Boolean false com.alipay.sofa.rpc.enable.swagger 是否开启针对bolt协议的swagger文档 Boolean false Rest\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.rest.hostname rest hostname String “” com.alipay.sofa.rpc.rest.port rest port Integer 8341 com.alipay.sofa.rpc.rest.io.thread.size rest io 线程数 Integer 机器cpu核数* 2 com.alipay.sofa.rpc.rest.context.path rest context path String “” com.alipay.sofa.rpc.rest.thread.pool.core.size rest 核心线程数 Integer 目前不可配置，默认20 com.alipay.sofa.rpc.rest.thread.pool.max.size rest 最大线程数 Integer 200 com.alipay.sofa.rpc.rest.max.request.size rest 最大请求大小 Integer 10485760 com.alipay.sofa.rpc.rest.telnet 是否允许 rest telnet Boolean true com.alipay.sofa.rpc.rest.daemon 是否hold住端口，true的话随主线程退出而退出 String true com.alipay.sofa.rpc.rest.allowed.origins 跨域设置 String “” com.alipay.sofa.rpc.rest.swagger 是否开启针对rest协议的swagger文档 boolean false Dubbo\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.dubbo.port dubbo port Integer 20880 com.alipay.sofa.rpc.dubbo.io.thread.size dubbo io 线程大小 Integer 0 com.alipay.sofa.rpc.dubbo.thread.pool.max.size dubbo 业务线程最大数 Integer 200 com.alipay.sofa.rpc.dubbo.accepts.size dubbo 服务端允许客户端建立的连接数 Integer 必须大于0，默认100000 com.alipay.sofa.rpc.dubbo.thread.pool.core.size dubbo 核心线程数 Integer 目前不可配置，默认20 com.alipay.sofa.rpc.dubbo.thread.pool.queue.size dubbo 线程池队列大小 Integer 目前不可配置，默认0 Http\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.http.port http port Integer 12400 com.alipay.sofa.rpc.http.thread.pool.core.size http 核心线程数 Integer 20 com.alipay.sofa.rpc.http.thread.pool.max.size http …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/application-rpc-config/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bd19b2ced39a8deb802c13e525093fac","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/application-rpc-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/application-rpc-config/","summary":"在 SOFABoot 的使用场景下，RPC 框架在应用层面，提供一些配置参数，支持的应用级别的参数配置，如端口，线程池等信息，都是通过 Spring Boot的@Config","tags":null,"title":"RPC 应用参数配置","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/application-rpc-config/","wordcount":1496},{"author":null,"categories":null,"content":" Raft 新特性 Strong Leader 更强的领导形式 例如日志条目只会从领导者发送到其他服务器, 这很大程度上简化了对日志复制的管理 Leader Election 使用随机定时器来选举领导者 用最简单的方式减少了选举冲突的可能性 Membership Change 新的联合一致性 (joint consensus) 方法 复制状态机 1. 复制状态机通过日志实现 每台机器一份日志 每个日志条目包含一条命令 状态机按顺序执行命令 2.应用于实际系统的一致性算法一般有以下特性 确保安全性 高可用性 不依赖时序保证一致性 一条命令能够尽可能快的在大多数节点对一轮RPC调用响应时完成 Paxos 算法的不足 算法复杂度高, 较难理解 工程复杂度高, 难以在实际环境中实现 Raft 设计原则 概念分解 Leader election Log replication Membership changes 通过减少状态数量将状态空间简化 日志不允许出现空洞, 并且 raft 限制了日志不一致的可能性 使用随机化时钟简化了领导选举的算法 Raft 一致性算法 State (状态) 在所有服务器上持久存储的(响应RPC之前稳定存储的)\n currentTerm 服务器最后知道的任期号(从0开始递增) votedFor 在当前任期内收到选票的候选人Id(如果没有就为null) log[] 日志条目, 每个条目包含状态机要执行的命令以及从Leader收到日志时的任期号 在所有服务器上不稳定存在的\n commitIndex 已知被提交的最大日志条目索引 lastApplied 已被状态机执行的最大日志条目索引 在Leader服务器上不稳定存在的\n nextIndex[] 对于每一个follower, 记录需要发给他的下一条日志条目的索引 matchIndex[] 对于每一个follower, 记录已经复制完成的最大日志条目索引 AppendEntries RPC (日志复制) 由leader通过RPC向follower复制日志, 也会用作heartbeat\n入参\n term Leader任期号 leaderId Leader id, 为了能帮助客户端重定向到Leader服务器 prevLogIndex 前一个日志的索引 prevLogTerm 前一个日志所属的任期 entries[] 将要存储的日志条目列表(为空时代表heartbeat, 有时候为了效率会发送超过一条) leaderCommit Leader已提交的日志条目索引 返回值\n term 当前的任期号, 用于leader更新自己的任期号 success 如果其他follower包含能够匹配上prevLogIndex和prevLogTerm的日志, 那么为真 接收日志的follower需要实现的\n 如果term \u0026amp;lt; currentTerm, 不接受日志并返回false 如果索引prevLogIndex处的日志的任期号与prevLogTerm不匹配, 不接受日志并返回false 如果一条已存在的日志与新的冲突(index相同但是term不同), 则删除已经存在的日志条目和他之后所有的日志条目 添加任何在已有日志中不存在的条目 如果leaderCommit \u0026amp;gt; commitIndex, 则设置commitIndex = min(leaderCommit, index of last new entry) RequestVote RPC (投票请求) 入参\n term 候选人的任期号 candidateId 发起投票请求的候选人id lastLogIndex 候选人最新的日志条目索引 lastLogTerm 候选人最新日志条目对应的任期号 返回值\n term 目前的任期号, 用于候选人更新自己 voteGranted 如果候选人收到选票, 那么为true 接收日志的follower需要实现的\n 如果term \u0026amp;lt; currentTerm, 那么拒绝投票并返回false 如果votedFor为空或者与candidateId相同, 并且候选人的日志和自己一样新或者更新, 那么就给候选人投票并返回true 服务器要遵守的规则 所有服务器: 如果commitIndex \u0026amp;gt; lastApplied, 那么将lastApplied自增并把对应日志log[lastApplied]应用到状态机 如果RPC请求或响应包含一个term T大于currentTerm, 那么将currentTerm赋值为T并立即切换状态为follower Follower: 无条件响应来自candidate和leader的RPC 如果在选举超时之前没收到任何来自leader的AppendEntries RPC或RequestVote RPC, 那么自己转换状态为candidate Candidate: 转变为candidate之后开始发起选举 currentTerm自增 \u0026amp;ndash;\u0026amp;gt; 重置选举计时器 \u0026amp;ndash;\u0026amp;gt; 给自己投票 \u0026amp;ndash;\u0026amp;gt; 向其他服务器发起RequestVote RPC 如果收到了来自大多数服务器的投票, 转换状态成为leader 如果收到了来自新leader的AppendEntries RPC(Heartbeat), 转换状态为follower 如果选举超时, 开始新一轮的选举 Leader: 一旦成为leader, 向其他所有服务器发送空的AppendEntries RPC(Heartbeat), 并在空闲时间重复发送以防选举超时 如果收到来自客户端的请求, 向本地日志追加条目并向所有服务器发送AppendEntries RPC, 在收到大多数响应后将该条目应用到状态机并回复响应给客户端 如果leader上一次收到的日志索引大于一个follower的nextIndex, 那么通过AppendEntries RPC将nextIndex之后的所有日志发送出去; 如果发送成功, 将follower的nextIndex和matchIndex更新, 如果由于日志不一致导致失败, 那么将nextIndex递减并重新发送 如果存在一个N \u0026amp;gt; commitIndex和半数以上的matchIndex[i] \u0026amp;gt;= N并且log[N].term == currentTerm, 将commitIndex赋值为N 一致性算法总结 Election Safety 选举安全原则: 一个任期内最多允许有一个leader Leader Append-Only 只增加日志原则: Leader只会增加日志条目, 永远不会覆盖或删除自己的日志 Log Matching 日志匹配原则: 如果两个日志在相同的的索引位置上并且任期号相同, 那么就可以认为这个日志从头到这个索引位置之间的条目完 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/raft-introduction/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b811e803d23b40da67657798801f8b51","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/raft-introduction/","publishdate":"0001-01-01T00:00:00Z","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-jraft/raft-introduction/","summary":"Raft 新特性 Strong Leader 更强的领导形式 例如日志条目只会从领导者发送到其他服务器, 这很大程度上简化了对日志复制的管理 Leader Election 使用随机定时器来选举领导者 用最简单","tags":null,"title":"Raft 算法解读","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/raft-introduction/","wordcount":5182},{"author":null,"categories":null,"content":"TBD\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-register-agent/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"da6c96fadd94eedcf961d50ce7b00600","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","summary":"TBD","tags":null,"title":"Register Agent","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","wordcount":1},{"author":null,"categories":null,"content":" Register agent TBD\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-register-agent/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"da6c96fadd94eedcf961d50ce7b00600","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","summary":"Register agent TBD","tags":null,"title":"Register agent","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","wordcount":3},{"author":null,"categories":null,"content":" Related articles ISSUES User manual Chinese introductory article: Ant communication framework practices ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/related-links/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"6844d2a639b69fa3128132b8631f33e3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/related-links/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/related-links/","summary":" Related articles ISSUES User manual Chinese introductory article: Ant communication framework practices ","tags":null,"title":"Related articles","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/related-links/","wordcount":12},{"author":null,"categories":null,"content":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.\n","date":-62135596800,"description":"","dir":"projects/mosn/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"62efb8e40401ab4612bcccaa6e942c97","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/mosn/release-notes/","summary":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/mosn/release-notes/","wordcount":5},{"author":null,"categories":null,"content":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.\n","date":-62135596800,"description":"","dir":"projects/occlum/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"6b9dec1dd8c196e43129ab36a046a84f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/occlum/release-notes/","summary":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/occlum/release-notes/","wordcount":5},{"author":null,"categories":null,"content":" Release history For more information, refer to: https://github.com/sofastack/sofa-ark/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-release/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"994c3569ea416ee5b0dea253f08af6be","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","summary":"Release history For more information, refer to: https://github.com/sofastack/sofa-ark/releases","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","wordcount":8},{"author":null,"categories":null,"content":"## Release history For more information, refer to: https://github.com/sofastack/sofa-jarslink/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-release/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4554e362f42cbc42b9408d9507cdf689","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","summary":"## Release history For more information, refer to: https://github.com/sofastack/sofa-jarslink/releases","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","wordcount":9},{"author":null,"categories":null,"content":"For more information, see https://github.com/sofastack/sofa-dashboard/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/release-node/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3c8e6985123810c9692f47cc56b50081","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/release-node/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/release-node/","summary":"For more information, see https://github.com/sofastack/sofa-dashboard/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/release-node/","wordcount":5},{"author":null,"categories":null,"content":" 1.2.5 April 1, 2019\n Bugs fixed Fixed the conflict between jmh and the unit test code. Fixed the installation failure bug that would occur when the snapshot is too large. This bug may affect the addition of new nodes. Features Optimized part of the LogManagerImpl code to reduce CPU usage. Corrected some spelling errors. Breaking changes None We strongly recommend that you upgrade to this version.\n1.2.4 March 20, 2019\n Bugs fixed Fixed stale read of lease read in a circumstance. Modified part of timestamps to monotonic time. Fixed the problem of the replicator being blocked in one circumstance. Resolved directory creation failures for some unit tests on Windows. Resolved process crashes caused by improper rocksdb options settings on Windows. Features Made the RocksDB options available for users to set. Optimized the pre-vote process, and used the lease mechanism to avoid the current term\u0026amp;rsquo;s interruption on a disconnected node (caused by network partitioning or no writes in the cluster for a long time) to improve the system availability. Updated SOFABolt to 1.5.3. Modified ReadWriteLock of the BallotBox to StampedLock, and provided the OptimisticRead implementation. Fixed a few spelling errors. Breaking changes None Acknowledgements (in no particular order) @pifuant @huangyunbin @shiftyman @slievrly 1.2.3 March 5, 2019 Released the first open source version.\n1.2.2 February 21, 2019\n Bugs fixed Made PeerId and Endpoint immutable, to avoid concurrency problems on APIs such as getLeaderId. Upgraded sofa-common to 1.0.12. The earlier version 1.0.9 was not released to the public GitHub repository. Features The JRaft-RheaKV implemented auto range split. When placementDriver(pd) is enabled, the pd can calculate and issue the range split command based on state information reported by each node. When pd is disabled, RheaKVCliService is provided to allow users to manually trigger range split by using the CLI service. Provided LogExceptionHandler generic support. Added MetricThreadPoolExecutor (an updated version of LogThreadPoolExecutor) to print the uncaught exception log and record the time for task.run() and replaced all ThreadPoolExecutors in JRaft with MetricThreadPoolExecutor to record time-consumption metric statistics. This metric can be used as an important reference for adjusting the thread pool configuration in actual application. Breaking changes Removed the reset method of Endpoint/PeerId. V1.2.1 January 28, 2019\n Bugs fixed Fixed a bug that RaftGroupService may mistakenly disable the shared rpcServer. Fixed the bug of the apply-order change caused by batch write of the RheaKV state machine. Fixed the time usage API error. Features Merged the code of duplicate functions of Jraft and RheaKV. Reduced memory usage of the log replication request handling process on followers. Optimized the synchronized conf read/write of the RouteTable to the read/write lock. Implemented lock safe with fencing and the automatic lease …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/release-log/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"9e24fb74a3cda6a600252b01f8a85db9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/release-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/release-log/","summary":"1.2.5 April 1, 2019\n Bugs fixed Fixed the conflict between jmh and the unit test code. Fixed the installation failure bug that would occur when the snapshot is too large. This bug may affect the addition of new nodes. Features Optimized part of the LogManagerImpl code to reduce CPU usage. Corrected some spelling errors. Breaking changes None We strongly recommend that you upgrade to this version.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/release-log/","wordcount":855},{"author":null,"categories":null,"content":"For more information, see https://github.com/sofastack/sofa-registry/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d92dddf77bbbd6078f3f96ba2224a53d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/release-notes/","summary":"For more information, see https://github.com/sofastack/sofa-registry/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/release-notes/","wordcount":5},{"author":null,"categories":null,"content":"To learn more, see https://github.com/sofastack/sofa-rpc/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ab7d46caa6906863103b77b742ec7e84","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/release-notes/","summary":"To learn more, see https://github.com/sofastack/sofa-rpc/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/release-notes/","wordcount":5},{"author":null,"categories":null,"content":" This example demonstrates how to remotely report link data to Zipkin by configuring SOFATracer in an application that integrates SOFATracer.\nThe following examples demonstrate how to use them in SOFABoot/SpringBoot projects and non-SOFABoot/SpringBoot projects, respectively.\nPrepare environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: + JDK7 or JDK8 + Apache Maven 3.2.5+ required for compilation\nIntroduce SOFABoot After creating a Spring Boot project, you need to introduce the SOFABoot dependency. First, you need to unzip the zip package of the Spring Boot project generated above and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more about SOFABoot versions, see Release notes.\nAdd SOFATracer starter \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Application configuration Finally, add the properties to be used by SOFATracer under the project\u0026amp;rsquo;s application.properties file, including spring.application.name to indicate the name of the current application; logging.path to specify the output directory of the log.\n# Application Name spring.application.name=SOFATracerReportZipkin # logging path logging.path=./logs # open zipkin report com.alipay.sofa.tracer.zipkin.enabled=true # specify zipkin server address com.alipay.sofa.tracer.zipkin.baseUrl=http://localhost:9411 Configure Zipkin Dependencies Considering that Zipkin\u0026amp;rsquo;s data reporting capability is not the ability of SOFATracer to be enabled by default,it‘s desirable to add the following Zipkin data reporting dependencies when using SOFATracer for data reporting:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.zipkin2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.11.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.reporter2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin-reporter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.7.13\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt;\t Start the Zipkin server Start the Zipkin server to receive the link data reported by SOFATracer and display it. Zipkin Server can be configured with reference to this document.\nRunning You can import the project into IDE and run the main method in the project to start the application. In the console, you can see the log about startup as follows:\n2018-05-12 13:12:05.868 INFO 76572 --- …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/report-to-zipkin/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d28d192386829452262116de9c32b570","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","summary":"This example demonstrates how to remotely report link data to Zipkin by configuring SOFATracer in an application that integrates SOFATracer.\nThe following examples demonstrate how to use them in SOFABoot/SpringBoot projects and non-SOFABoot/SpringBoot projects, respectively.\nPrepare environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: + JDK7 or JDK8 + Apache Maven 3.2.5+ required for compilation\nIntroduce SOFABoot After creating a Spring Boot project, you need to introduce the SOFABoot dependency.","tags":null,"title":"Report data to Zipkin","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","wordcount":465},{"author":null,"categories":null,"content":" RestTemplate Integration In this document will demonstrate how to use SOFATracer to track of RestTemplate, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- SOFABoot version unified management --\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs Add a Controller that provides RESTFul services In the project, provide a simple Controller, for example:\n@RestController public class SampleController { private final AtomicLong counter = new AtomicLong(0); @RequestMapping(\u0026amp;quot;/rest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; rest() { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); return map; } @RequestMapping(\u0026amp;quot;/asyncrest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; asyncrest() throws InterruptedException { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); Thread.sleep(5000); return map; } } Construct the RestTemplate in API model to initiate a call to the RESTful service above Construct a RestTemplate synchronous call instance RestTemplate restTemplate = SofaTracerRestTemplateBuilder.buildRestTemplate(); ResponseEntity\u0026amp;lt;String\u0026amp;gt; responseEntity = restTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;, String.class); Construct a RestTemplate asynchronous call instance AsyncRestTemplate asyncRestTemplate = SofaTracerRestTemplateBuilder .buildAsyncRestTemplate(); ListenableFuture\u0026amp;lt;ResponseEntity\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; forEntity = asyncRestTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/asyncrest\u0026amp;quot;, String.class); Get the RestTemplate in an automatic injection @Autowired RestTemplate restTemplate; Run the project Start the SOFABoot app and see the log in the console as follows:\n2018-10-24 10:45:28.683 INFO 5081 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-10-24 10:45:28.733 INFO 5081 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-10-24 10:45:28.736 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Started RestTemplateDemoApplication in 2.163 seconds (JVM running for 3.603) Successful call：\n2018-10-24 10:45:28.989 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-resttemplate/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"8b66d6ad488bd59ecbf113b37825d58e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","summary":"RestTemplate Integration In this document will demonstrate how to use SOFATracer to track of RestTemplate, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;!-- SOFABoot version unified management --\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.properties file, including spring.","tags":null,"title":"RestTemplate Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","wordcount":434},{"author":null,"categories":null,"content":" RestTemplate Log Format SOFATracer integrates RestTemplate and outputs the requested link log data format. The default is JSON data format.\nRestTemplate digest log（resttemplate-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.app remote app name baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-10-24 10:45:28.977\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8b3154034912878910015081\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:188,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RestTemplate stat log（resttemplate-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success ; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-10-24 10:46:28.769\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5009,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-resttemplate/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c52c919080b467801700a8a1f156c513","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","summary":"RestTemplate Log Format SOFATracer integrates RestTemplate and outputs the requested link log data format. The default is JSON data format.\nRestTemplate digest log（resttemplate-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.","tags":null,"title":"RestTemplate log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","wordcount":172},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 RestTemplate 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括 spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=TestTemplateDemo # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleController { private final AtomicLong counter = new AtomicLong(0); @RequestMapping(\u0026amp;quot;/rest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; rest() { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); return map; } @RequestMapping(\u0026amp;quot;/asyncrest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; asyncrest() throws InterruptedException { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); Thread.sleep(5000); return map; } } 以 API 方式构造 RestTemplate 发起一次对上文的 RESTful 服务的调用 构造 RestTemplate 同步调用实例 RestTemplate restTemplate = SofaTracerRestTemplateBuilder.buildRestTemplate(); ResponseEntity\u0026amp;lt;String\u0026amp;gt; responseEntity = restTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;, String.class); 构造 RestTemplate 异步调用实例 AsyncRestTemplate asyncRestTemplate = SofaTracerRestTemplateBuilder .buildAsyncRestTemplate(); ListenableFuture\u0026amp;lt;ResponseEntity\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; forEntity = asyncRestTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/asyncrest\u0026amp;quot;, String.class); 以自动注入的方式获取 RestTemplate @Autowired RestTemplate restTemplate; 运行 启动 SOFABoot 应用，将会在控制台中看到启动打印的日志：\n2018-10-24 10:45:28.683 INFO 5081 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-10-24 10:45:28.733 INFO 5081 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-10-24 10:45:28.736 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Started RestTemplateDemoApplication in 2.163 seconds (JVM running for 3.603) 调用成功：\n2018-10-24 10:45:28.989 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Async Response is {\u0026amp;quot;count\u0026amp;quot;:2} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : test finish ....... 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要进行配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── resttemplate-digest.log ├── resttemplate-stat.log ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 示例中通过构造两个 RestTemplate（一个同步一个异步） 发起对同一个 RESTful 服务的调用，调用完成后可以在 restTemplate-digest.log 中看到类似如下的日志： …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-resttemplate/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8b66d6ad488bd59ecbf113b37825d58e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","summary":"在本文档将演示如何使用 SOFATracer 对 RestTemplate 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt;","tags":null,"title":"RestTemplate 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","wordcount":610},{"author":null,"categories":null,"content":" SOFATracer 集成 RestTemplate 后输出请求的链路数据格式，默认为 JSON 数据格式。\nRestTemplate 摘要日志（resttemplate-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SimpleAsyncTaskExecutor-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5009ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RestTemplate 统计日志（resttemplate-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:34:04.130\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5009,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-resttemplate/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c52c919080b467801700a8a1f156c513","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","summary":"SOFATracer 集成 RestTemplate 后输出请求的链路数据格式，默认为 JSON 数据格式。 RestTemplate 摘要日志（resttemplate-digest.log） 以 JSON 格式输出的数据，相应 key 的","tags":null,"title":"RestTemplate 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","wordcount":342},{"author":null,"categories":null,"content":" SOFARPC supports a framework-level retry strategy when the cluster mode is FailOver (SOFARPC uses FailOver mode by default). Retry is only initiated if there is a framework-level exception or a timeout exception on the server. If the business itself throws an exception, the service will not be called again. SOFARPC does not perform any retry by default.\n Note: Although the system will retry calling in case of timeout exception, the server still needs to guarantee the idempotency of the service. Otherwise there may be risks.\n Use XML If you subscribe to the service using XML, you can set the number of retries by setting the retries parameter of sofa:global-attrs:\n\u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;retriesServiceReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.retries.RetriesService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs retries=\u0026amp;quot;2\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation If you are using Annotation, you can set the retries attribute of @SofaReferenceBinding annotation:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, retries = 2)) private SampleService sampleService; Use API in Spring environment If you are using the API in Spring environment, you can call the setRetries method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setRetries(2); Use API in non-Spring environment If you are using the bare API of SOFARPC directly in non-Spring environment, you can call the setRetries method of ConsumerConfig:\nConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt;(); consumerConfig.setRetries(2); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/retry-invoke/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d60b44aa8f1b49ab6c1bbc55593a91da","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","summary":"SOFARPC supports a framework-level retry strategy when the cluster mode is FailOver (SOFARPC uses FailOver mode by default). Retry is only initiated if there is a framework-level exception or a timeout exception on the server. If the business itself throws an exception, the service will not be called again. SOFARPC does not perform any retry by default.\n Note: Although the system will retry calling in case of timeout exception, the server still needs to guarantee the idempotency of the service.","tags":null,"title":"Retry strategy","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","wordcount":205},{"author":null,"categories":null,"content":" SOFAJRaft 2019 年 4-7 月开发计划 (p1) Telnet 服务（或其他，越简单越好），作为一种在线排查问题的手段，主要提供以下几个功能 Raft_stat: 以 node 节点为 root，能列出大部分甚至所有相关 stat Metrics: 展示当前节点最新的所有 metrics 指标度量(虽然日志里有相关数据但是相对分散) (p1) 扩展点：引入 SPI 机制，先列出几个扩展点 LogStorage LogEntry codec RaftMetaStorage Metric 指标度量 (p1) 对于 multi-raft-group 场景，提供一个 manual rebalance api 用于平衡各个节点的 leaders 数量 (p2) 文档国际化 (p2) 添加 Learner 角色，只用于同步数据不参与投票 (p3) RheaKV 完成 jepsen 验证\n ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/road-map/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d39cc6e615d623f8dfc320f32dcbdfa6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/road-map/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/road-map/","summary":"SOFAJRaft 2019 年 4-7 月开发计划 (p1) Telnet 服务（或其他，越简单越好），作为一种在线排查问题的手段，主要提供以下几个功能 Raft_stat: 以 node 节点为 root，能列出大部分甚至所有","tags":null,"title":"Road Map","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/road-map/","wordcount":194},{"author":null,"categories":null,"content":" Roadmap Version 1.5.1 Fixed code style problems in the project: https://github.com/alipay/sofa-bolt/issues/85 Fixed known bugs in the project: https://github.com/alipay/sofa-bolt/issues/82 The RPC layer supports message list dispatching from the I/O thread: https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 Overall goal Unify lifecycle APIs for all components Extract and incorporate network component APIs Converge configuration methods and enhance configuration scalability Unify lifecycle APIs for all components In the current Bolt version, APIs of lifecycle management components are named inconsistently, for example:\n ReconnectManager does not need startup or initialization, and the disabling method is stop. The initialization method for DefaultConnectionMonitor of is start, and the disabling method is destroy. The initialization method forRpcClient init, and the disabling method is shutdown. The initialization method forRpcTaskScanner is start, and the disabling method is shutdown. We plan to unify lifecycle APIs of all components in V1.6.0:\n For components that are subject to lifecycle management, which require initialization before use and must release resources after use, their startup/shutdown APIs are to be unified. Extract and incorporate network component APIs Network operations of Bolt are mainly performed by using the remoting class, which is provided as an abstract class. We plan to converge methods of this class, and provide them in the form of APIs in the future. There are a few advantages of doing so:\n Standardized usage Stable service Convenient internal code iteration Taking the ReconnectManager as an example. It provides the public addCancelUrl method, which is not called in the Bolt project. This may cause problems:\n IDE will give a warning. Users may get confused on whether they should delete this method. We plan to solve the these problems in V1.6.0 by extracting a set of stable APIs, which are convenient for users to use, helpful to improve code readability, and can lay a solid foundation for future iterations.\nConverge configuration methods and enhance configuration scalability Currently, Bolt supports the following configuration methods:\n ProtocolSwitch: supports protocol configuration (enabling or disabling CRC validation), and creates configuration objects by static means. GlobalSwitch: offers instance-level configuration, and offers GlobalSwitch configuration items to every AbstractConfigurableInstance. The default value is taken from the SystemProperty, and the configuration can be adjusted through an API. ConfigItem: enumerates Netty-related configuration items that cannot be inherited or extended before you modify the source code. ConfigManager: reads SystemProperty configurations by static means. Configs: defines the configuration item names and specifies their default values. Generally, Bolt\u0026amp;rsquo;s configuration items look to be loose and scattered and are hard for users to extend their usage. …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-roadmap/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3d4eac90b5c8e657d14eb885ab1f9a92","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","summary":"Roadmap Version 1.5.1 Fixed code style problems in the project: https://github.com/alipay/sofa-bolt/issues/85 Fixed known bugs in the project: https://github.com/alipay/sofa-bolt/issues/82 The RPC layer supports message list dispatching from the I/O thread: https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 Overall goal Unify lifecycle APIs for all components Extract and incorporate network component APIs Converge configuration methods and enhance configuration scalability Unify lifecycle APIs for all components In the current Bolt version, APIs of lifecycle management components are named inconsistently, for example:","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","wordcount":539},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c4532d11cef15d8fe3ff5e04c7b08f90","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","summary":"","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","wordcount":0},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f1d0bf15efba08535f9574e1c8344cab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","summary":"","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","wordcount":0},{"author":null,"categories":null,"content":" Development plans of SOFAJRaft from April to July 2019 (p1) Implement the Telnet service (or similar equivalents, the simpler the better) as an online troubleshooting means. It should be able to provide the following functions: Raft_stat: List most or all stats of a Raft node. Metrics: Uniformly display the latest values of all metrics for the current node (the related data is scattered in the log). (p1) Extension points: introduce the SPI mechanism. Some of the extension points are listed as follows: LogStorage LogEntry codec RaftMetaStorage Metrics (p1) Provide a manual rebalance API for the multi-raft-group scenario to balance the number of leaders on each node. (p2) Translate the document into multiple languages. (p2) Add a learner role that only replicates data and does not vote. (p3) Complete jepsen tests for RheaKV. ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/road-map/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d39cc6e615d623f8dfc320f32dcbdfa6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/road-map/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/road-map/","summary":"Development plans of SOFAJRaft from April to July 2019 (p1) Implement the Telnet service (or similar equivalents, the simpler the better) as an online troubleshooting means. It should be able to provide the following functions: Raft_stat: List most or all stats of a Raft node. Metrics: Uniformly display the latest values of all metrics for the current node (the related data is scattered in the log). (p1) Extension points: introduce the SPI mechanism.","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/road-map/","wordcount":132},{"author":null,"categories":null,"content":" Task list Some of the existing internal features will be available in subsequent iterations.\nThe features that have been implemented are listed in the following table. You are welcome to claim the tasks and make contributions.\n Task type Task Degree of difficulty Claimant and time Planned completion time Progress Related issues Documentation Document translation Low Code Flexible persistent connection management Low #56 Code etcd registry center implementation Medium @wynn5a\n2018-6 #153 Code eureka registry center implementation Medium @liufeiit\n2018-4 #52 Code gRPC support High #57 Code CXF protocol High #58 Code TLS support High Version iteration Plan v5.5.0 Support JSON serialization Support H2 TLS Implement flexible connection pool Integrate Hystrix Support Consul registry center v5.6.0 Support GRPC communication layer Support etcd registry center Support SOFAMesh Implement BOLT version negotiation and CRC verification v5.7.0 Support Telnet built-in instructions Support SpringBoot 2.0 Support Mock function Support encryption v5.8.0 Support authorization Support SofaRegistry Support Reactive ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/roadmap/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"6064fc180911f520f6d1590b88595693","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/roadmap/","summary":"Task list Some of the existing internal features will be available in subsequent iterations.\nThe features that have been implemented are listed in the following table. You are welcome to claim the tasks and make contributions.\n Task type Task Degree of difficulty Claimant and time Planned completion time Progress Related issues Documentation Document translation Low Code Flexible persistent connection management Low #56 Code etcd registry center implementation Medium @wynn5a","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/roadmap/","wordcount":152},{"author":null,"categories":null,"content":" Tasks The following table lists the features that have not yet been implemented. We encourage you to claim the tasks and make a contribution.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document SOFADashboard Parameter Configuration Guide Simple Code Support for SOFARegistry Medium Code Support for Docker Medium Code Support for Kubernetes Medium Code Support for Apollo Medium Code Frontend optimization Medium ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a740c874742b504de9011b07f3a4ddb5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/roadmap/","summary":" Tasks The following table lists the features that have not yet been implemented. We encourage you to claim the tasks and make a contribution.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document SOFADashboard Parameter Configuration Guide Simple Code Support for SOFARegistry Medium Code Support for Docker Medium Code Support for Kubernetes Medium Code Support for Apollo Medium Code Frontend optimization Medium ","tags":null,"title":"Roadmap and task claim","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/roadmap/","wordcount":67},{"author":null,"categories":null,"content":" Roadmap Tasks We have some internal implementations of some new features, which will be released along with the iterations when sorted out.\nFeatures that are not implemented yet are listed in the following table. We encourage you to claim the tasks and contribute to SOFARegistry.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document Document Translation Low Code Support for Spring Cloud Medium Code Data self-check High Code Blacklist filtering Medium Code SOFARegistry Dashboard High Code Support for other microservice frameworks Medium Code Support for Docker \u0026amp;amp; Kubernetes High Code Multi-language client support High Version iteration plan v5.3.0 Support for Spring Cloud Data self-check Blacklist filtering v5.4.0 SOFARegistry Dashboard Support for other microservice frameworks v5.5.0 Support for Docker \u0026amp;amp; Kubernetes Multi-language client support ","date":-62135596800,"description":"","dir":"projects/sofa-registry/roadmap/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b0ab45d52ba3eb7db590a4f5e4197c9e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/roadmap/","summary":"Roadmap Tasks We have some internal implementations of some new features, which will be released along with the iterations when sorted out.\nFeatures that are not implemented yet are listed in the following table. We encourage you to claim the tasks and contribute to SOFARegistry.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document Document Translation Low Code Support for Spring Cloud Medium Code Data self-check High Code Blacklist filtering Medium Code SOFARegistry Dashboard High Code Support for other microservice frameworks Medium Code Support for Docker \u0026amp; Kubernetes High Code Multi-language client support High Version iteration plan v5.","tags":null,"title":"Roadmap and task claims","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/roadmap/","wordcount":128},{"author":null,"categories":null,"content":" AntCoreTest (ACTS) is a white-box test framework developed by Ant Financial based on years\u0026amp;rsquo; testing knowledge and experience with the financial-level distributed architecture for the purpose of providing enterprises with a highly efficient, precise, and automated interface testing services. In addition to general testing capabilities such as data-driven testing provided by conventional open source frameworks like TestNG, ACTS offers new features such as model-driven testing, visualized editing, and a standard process engine to assist engineers with efficient and high quality test case compilation as well as standard and precise test validation for interface testing.\nACTS is a next generation testing framework based on the data model-driven testing engine. ACTS is applicable to context environments that require the integration of TestNg and Spring. ACTS uses the YAML file as the data carrier and builds data model drivers upon it, providing features such as the all-in-one editor, precise validation, and efficient test case management to significantly improve testing efficiency.\nOperating principle Upon the start of the test script, ActsDataProvider starts the tested method (the method annotated by @Test), loads the corresponding test case data file (YAML file), and converts the data into corresponding PrepareData objects.\n When runTest starts running, it passes PrepareData and test case names to ACTS. ACTS then assembles such information into the ActsRuntimeContext class, transmits it in the entire process, and initializes the TestUnitHandler. The running period of the runTest process method consists of the following stages:\n | Action | Method | | :\u0026amp;mdash; | :\u0026amp;mdash; | | Clear | clear(actsRuntimeContext) | | Prepare | prepare(actsRuntimeContext) | | Execute | execute(actsRuntimeContext) | | Check | check(actsRuntimeContext) |\nDescription:\n Clear: Clean up the preparation data and validation data to avoid the negative impact of dirty data on the test script. Prepare: Prepare data such as DB data. Execute: Call the tested method, and capture the corresponding information, such as responses and exception messages. Check: Validate the corresponding information such as the responses, DB data, and exception messages based on the test data. Features ACTS provides the following features:\n2.1 All-in-one editor The ACTS framework separates the test data from the test code, and provides the visual editor ACTS IDE. ACTS IDE can help you quickly enter, view, and manage the test case data, which significantly reduces repetitive coding.\n2.2 Precise validation To improve data fill-in efficiency and reduce omission of check points among the expectation data, such as response expectations and database expectations, the ACTS framework provides a run and backfill function. In addition, ACTS uses validation rule flags to implement precise validation of the expectation data.\n2.3 Flexible scalability ACTS provides a rich variety of APIs, which are encapsulated …","date":-62135596800,"description":"","dir":"projects/sofa-acts/overview/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ac57071cd0d40a63359d476d05344c61","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/overview/","summary":"AntCoreTest (ACTS) is a white-box test framework developed by Ant Financial based on years\u0026rsquo; testing knowledge and experience with the financial-level distributed architecture for the purpose of providing enterprises with a highly efficient, precise, and automated interface testing services. In addition to general testing capabilities such as data-driven testing provided by conventional open source frameworks like TestNG, ACTS offers new features such as model-driven testing, visualized editing, and a standard process engine to assist engineers with efficient and high quality test case compilation as well as standard and precise test validation for interface testing.","tags":null,"title":"SOFAActs overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/overview/","wordcount":556},{"author":null,"categories":null,"content":" ACTS（AntCoreTest）源于蚂蚁金服多年金融级分布式架构工程的测试实践的积累与沉淀，是一款白盒测试框架，旨在为企业提供高效、精细化的接口自动化测试。 与现有的诸如 TestNG 等开源框架相比，ACTS 除了具备通用的数据自动化驱动等测试能力外，还具有契合快速的互联网发展和复杂的分布式金融系统特点的模型驱动、可视化编辑和标准流程引擎等新特性，可辅助工程师高效、高质量地完成接口测试用例编写以及标准化精准化测试验证。\nACTS 是基于数据模型驱动测试引擎执行的的新一代测试框架（如图1所示），适配 TestNg+Spring 的测试上下文环境，以 YAML 为数据载体并在此上构建数据模型驱动，实现了一站式编辑、精细化校验和高效用例管理等，可以有效提高测试效率。\n运行原理 测试脚本启动的时，ActsDataProvider 会启动被测方法（被 @Test 注解的方法），加载对应的用例数据文件(以 YAML 文件承载)，然后转换成对应的 PrepareData 对象； runTest 开始执行时会传入 PrepareData 和用例名称，ACTS 根据这些信息组装出 ActsRuntimeContext 上下文并在整个过程中传递，同时初始化 TestUnitHandler 测试处理器。runTest -\u0026amp;gt; process 方法执行期包含如下四个子流程：\n 说明 方法 清理 clear(actsRuntimeContext) 准备 prepare(actsRuntimeContext) 执行 execute(actsRuntimeContext) 检查 check(actsRuntimeContext) 方法功能说明： + 清理阶段：清理准备数据、校验数据，防止脏数据对测试脚本产生影响； + 准备阶段：准备 DB 数据等； + 执行阶段：调用被测方法，捕获返回结果和异常等信息； + 检查阶段：根据测试数据，校验返回结果、DB 数据和异常信息等内容。\n功能描述 ACTS 提供了以下能力：\n2.1 一站式编辑 框架实现了测试数据与测试代码的分离，同时配套提供可视化编辑器 ACTS IDE，通过 ACTS IDE 可以快速地录入、查看和管理用例数据，有效减少重复性编码。\n2.2 精细化校验 为了提高返回结果、DB 数据等期望数据的填写效率和减少检验点遗漏，框架提供了预跑返填功能；同时在 ACTS 校验规则标签的标记下，实现期望 DB 数据、期望结果等数据的精细化校验。\n2.3 灵活可扩展 ACTS 提供了丰富的 API ，其封装于 ActsRuntimeContext 类中，借助 API 可快速获取和设置自定义参数、用例入参、期望结果等，满足用户对用例数据的自定义操作；\n同时，框架的 ActsTestBase 测试基类对外暴露各个执行阶段方法，包括 prepare，execute，check，clear 等，例如在测试类中通过重写 process 方法可将整个测试脚本重新编排。\n2.4 统一配置能力 配置文件中提供丰富的配置能力以定制化框架的个性需求。\n应用场景 基于 SOFABoot 搭建的应用，在 Intellij IDEA 开发环境下快速编写和执行接口测试用例。推荐使用 Intellij IDEA 2017 以便能更好地兼容 ACTS IDE。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/overview/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ac57071cd0d40a63359d476d05344c61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/overview/","summary":"ACTS（AntCoreTest）源于蚂蚁金服多年金融级分布式架构工程的测试实践的积累与沉淀，是一款白盒测试框架，旨在为企业提供高效、精细化","tags":null,"title":"SOFAActs 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-acts/overview/","wordcount":998},{"author":null,"categories":null,"content":" SOFAArk offers a variety of methods to support multi-application (module) consolidation and deployment, including command line-based control and API-based control. SOFAArk control is an implementation of SOFADashboard\u0026amp;rsquo;s control over APIs. SOFAArk control is implemented by pushing commands to and parsing commands in ZooKeeper.\nSOFAArk control mainly provides the following functions:\n Plug-in registration: registers the ark-biz package with SOFADashboard as basic data processors. Application association: binds the ark-biz package with host applications. Plug-in details: On the plug-in details page, you can view the information about all host applications that are associated with the current ark-biz package, as well as the status information of the ark-biz package in these host applications. Command push: On the plug-in details page, you can push some commands for specific applications and IP addresses, such as install and uninstall. When these commands are written to a ZooKeeper node, all host applications that listen to this node will parse the commands and perform related operations. Plug-in registration Register the ark-biz package with SOFADashboard:\nEnter basic information of the plug-in\nAfter successful registration, the plug-in is displayed on the module list as follows.\nApplication association Click Associate application in the Actions column of a plug-in on the module list to associate it with an application.\nClick Associate application in the Actions column of the plug-in to associate it with an application.\nPlug-in details Click Details in the Actions column of a plug-in to view all apps and app instances associated with the current plug-in.\n Version switch After switching the plug-in to V2.0.0, the status information is empty, because the plug-in V2.0.0 has not been installed in the host application.\nCommand push SOFADashboard supports command push in two dimensions:\n Application-based command push, where all instances of the specified application listen to this command IP-based and group-based command push for single-IP address scenarios IP-based command push Click Install. The page is refreshed after about 1s to 1.5s.\n Application-based command push is similar.\n ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/ark-console/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b42cffbb8e55a4c47412e49de0e9b228","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/ark-console/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/ark-console/","summary":"SOFAArk offers a variety of methods to support multi-application (module) consolidation and deployment, including command line-based control and API-based control. SOFAArk control is an implementation of SOFADashboard\u0026rsquo;s control over APIs. SOFAArk control is implemented by pushing commands to and parsing commands in ZooKeeper.\nSOFAArk control mainly provides the following functions:\n Plug-in registration: registers the ark-biz package with SOFADashboard as basic data processors. Application association: binds the ark-biz package with host applications.","tags":null,"title":"SOFAArk control","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/ark-console/","wordcount":321},{"author":null,"categories":null,"content":" SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献；\n在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin） 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz) 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz 基于以上能力，SOFAArk 可以帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\n场景 包冲突 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError, NoSuchMethodError 等；实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法，统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突；这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题；如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题； OSGI 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGI 框架太过臃肿，功能繁杂；为了解决包冲突问题，引入 OSGI 框架，有牛刀杀鸡之嫌，且反而使工程变得更加复杂，不利于开发；\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如果工程需要引入两个三方包：A 和 B，但是 A 需要依赖版本号为 0.1 的 C 包，而恰好 B 需要依赖版本号为 0.2 的 C 包，且 C 包的这两个版本无法兼容：\n此时，即可使用 SOFAArk 解决该依赖冲突问题；只需要把 A 和版本为 0.1 的 C 包一起打包成一个 Ark 插件，然后让应用工程引入该插件依赖即可；\n合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n静态合并部署 SOFAArk 提供了静态合并部署能力，在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成可执行 Fat Jar 时，可以将其他应用 Biz 包一并打入，启动时，则会根据优先级依次启动各应用。每个 Biz 使用独立的 BizClassLoader 加载，不需要考虑相互依赖冲突问题，Biz 之间则通过 SofaService/SofaReference JVM 服务进行交互。\n动态合并部署 动态合并部署区别于静态合并部署最大的一点是，运行时通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态合并部署的设计理念图如下：\n无论是静态还是动态合并部署都会有宿主应用（master biz）的概念, 如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主应用不允许被卸载，一般而言，宿主应用会作为流量入口的中台系统，具体的服务实现会放在不同的动态 Biz 中，供宿主应用调用。宿主应用可以使用 SOFAArk 提供的客户端 API 实现动态应用的部署和卸载。除了 API, SOFAArk 提供了 Config Plugin，用于对接配置中心（目前支持 Zookeeper），运行时接受动态配置；Config Plugin 会解析下发的配置，控制动态应用的部署和卸载。\n原理 SOFAArk 包含三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下:\n在介绍这三个概念之前，先介绍上述 Ark 包概念；Ark 包是满足特定目录格式要求的可运行 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将单个或多个应用打包成标准格式的 Ark 包；使用 java -jar 命令即可在 SOFAArk 容器之上启动所有应用；Ark 包通常包含 Ark Container、Ark Plugin 和 Ark Biz；以下我们针对这三个概念简单做下名词解释：\n Ark Container: SOFAArk 容器，负责 Ark 包启动运行时的管理；Ark Plugin 和 Ark Biz 运行在 SOFAArk 容器之上；容器具备管理插件和应用的功能；容器启动成功后，会自动解析 classpath 包含的 Ark Plugin 和 Ark Biz 依赖，完成隔离加载并按优先级依次启动之；\n Ark Plugin: Ark 插件，满足特定目录格式要求的 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-plugin-maven-plugin 可以将一个或多个普通的 Java jar 打包成一个标准格式的 Ark Plugin；Ark Plugin 会包含一份配置文件，通常包括插件类导入导出配置、资源导入导出配置、插件启动优先级等；运行时，SOFAArk 容器会使用独立的 PluginClassLoader加载插件，并根据插件配置构建类加载索引表、资源加载索引表，使插件和插件之 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-readme/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cdb6729fc7a63954b7559c8ea319f550","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","summary":"SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献； 在大型软件开发过程中，通常会推荐底层","tags":null,"title":"SOFAArk 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","wordcount":2577},{"author":null,"categories":null,"content":" 【SOFAChannel 分享】SOFAArk 类隔离框架设计原理 https://www.bilibili.com/video/BV1gS4y1i7Fg/?spm_id_from=333.999.0.0\n\n【SOFA 开源四周年分享】Serverless 技术简介 https://www.bilibili.com/video/BV1nU4y1B7u3/?spm_id_from=333.999.0.0\n\n【SOFA Meetup 云原生技术沙龙】SOFAServerless 体系助力业务极速研发 https://www.bilibili.com/video/BV1Ld4y1P7VK/?spm_id_from=333.999.0.0\n\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-public-presentation/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c460ccc2d706f49e26eb4f74d5468d63","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","summary":"【SOFAChannel 分享】SOFAArk 类隔离框架设计原理 https://www.bilibili.com/video/BV1gS4y1i7Fg/?spm_id_from=333.999.0.0 【SOFA 开源四周年分享】Serverless 技术简介 https://www.bilibili.com/video/BV1nU4y1B7u3/?spm_id_from=333.999.0.0 【SOFA Meetup 云原生技","tags":null,"title":"SOFAArk 相关公开分享材料","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","wordcount":99},{"author":null,"categories":null,"content":" SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAARK 管控是 SOFADashboard 针对 API 的管控的一种实现。通过面向 Zookeeper 进行命令的推送和命令的解析执行。\nSOFAArk 管控主要包括以下功能：\n 插件注册：将 ark-biz 插件注册到 SOFADashboard，作为基础数据 关联应用：将 ark-biz 插件与宿主应用进行绑定 插件详情：通过插件详情页，可以看下当前 ark-biz 插件下所有关联的宿主应用信息，以及宿主应用中的ark-biz 状态信息 命令推送：插件详情页，可以针对应用维度、分组维度、IP 维度 推送一些指令，比如 install、uninstall 等等，当这些命令被写入到 Zookeeper 的某个节点上时，所有监听此节点的 宿主应用均会解析此指令，并进行相关的操作 插件管理 插件注册 将 ark-biz 插件注册到 SOFADashboard：\n插件删除 添加插件版本 插件版本 biz 包路径 删除版本 关联应用 点击模块列表操作菜单栏中的关联应用，可以将一个应用与插件进行绑定：\n动态管控 点击插件列表后面的 详情 按钮，可以查看当前插件下所有应用信息和应用实例信息。\n命令推送 SOFADashboard 提供三种维度的命令推送\n 基于应用维度，当前应用所有的实例都会监听到此命令变更 基于IP 维度，分组维度的单 ip 场景 动态模块详情 点击 状态详细按钮，左侧栏将会展开 \u0026amp;ldquo;抽屉\u0026amp;rdquo; 展示详情状态数据\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/ark-console/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b42cffbb8e55a4c47412e49de0e9b228","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/ark-console/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/ark-console/","summary":"SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAARK 管控是 SOFADashboard 针对 API 的管控的一种实现。通过面","tags":null,"title":"SOFAArk 管控","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/ark-console/","wordcount":541},{"author":null,"categories":null,"content":" SOFAArk 的配置目录不是必须存在，如果需要，统一放在工程根目录 ${baseDir}/conf/ark 下，执行 sofa-ark-maven-plugin 打包，将会自动将该目录下的配置打包至 Ark 包，例如 Ark 包目录为：\n. ├── META-INF │ └── MANIFEST.MF ├── SOFA-ARK │ ├── biz │ │ └── demo-0.0.1-SNAPSHOT-ark-biz.jar │ └── container │ └── sofa-ark-all-0.6.0-SNAPSHOT.jar ├── com │ └── alipay │ └── sofa │ └── ark │ ├── ... │ └── conf └── ark ├── bootstrap-dev.properties ├── bootstrap.properties └── log └── logback-conf.xml 注意事项：如果应用中包含 SOFAArk 配置，打包时需要注意 baseDir 配置，用于指定工程根目录，具体参考文档\n上述 conf/ark 目录中可以配置 SOFAArk 容器启动配置以及日志配置，下面介绍配置的使用.\nconf/ark/bootstrap.properties 是 SOFAArk 容器默认启动配置文件，配置内容包括：日志配置、plugin 激活和钝化配置、biz 激活和钝化配置.\n日志配置 SOFAArk 容器日志内部实现使用 logback, 日志配置参数包括： + logging.path \u0026amp;gt; 容器日志目录根路径，这里只影响 SOFAArk 容器日志路径，不影响应用日志，应用自身日志由自身配置决定，默认打印在 ${user.admin}/logs 目录\n logging.level.com.alipay.sofa.ark \u0026amp;gt; 设置 SOFAArk 容器日志级别，默认为 INFO\n logging.config.com.alipay.sofa.ark \u0026amp;gt; 指定自定义日志配置文件名，用于覆盖 SOFAArk 容器自带的日志配置文件。建议自定义配置文件放在 conf/ark/log 目录中\n sofa.middleware.log.com.alipay.sofa.ark.console \u0026amp;gt; 配置容器日志是否打印在 console，默认为 false.\n sofa.middleware.log.com.alipay.sofa.ark.console.level \u0026amp;gt; 配合上述配置项使用，如果打印在 console ，该配置项用于配置 SOFAArk 容器打印在 console 的日志级别\n 插件配置 ark.plugin.active.include \u0026amp;gt; 指定激活哪些插件，多个插件使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认激活 Ark 包中所有的插件。\n ark.plugin.active.exclude \u0026amp;gt; 指定排除哪些插件，多个插件使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认为空\n 注：如果同时配置了这两个属性，以 ark.plugin.active.include 为准\nbiz配置 ark.biz.active.include \u0026amp;gt; 指定激活哪些 Biz，多个 Biz 使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认激活 Ark 包中所有的 Biz.\n ark.biz.active.exclude \u0026amp;gt; 指定排除哪些 Biz，多个 Biz 使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认为空\n com.alipay.sofa.ark.master.biz \u0026amp;gt; 指定宿主 Biz 名，如果 Ark 包中只有一个 Biz，则不用设置，默认设置为宿主 Biz; 否则需要显示设置\n 注：如果同时配置了前两个属性，以 ark.biz.active.include 为准\n动态配置 SOFAArk 提供了对接 Zookeeper 的插件，目前用于动态接收 Biz 指令，目前只支持 Zookeeper，配置格式如下：\ncom.alipay.sofa.ark.config.address=zookeeper://ip:port?key1=value1\u0026amp;amp;key2=value2 特别注意，SOFAArk 有一个默认的逻辑，如果用户配置了 com.alipay.sofa.ark.config.address，且 Ark 包中打入了多个 Biz，则只会启动宿主应用(master biz)；这样做的原因是如果配置了动态配置，SOFAArk 会优先根据动态配置控制 Biz 的部署。\nProfile 机制 默认 SOFAArk 容器使用 bootstrap.properties 配置，实际开发中，可能根据运行环境加载不同的配置，SOFAArk 提供了 profile 机制. 指定 profile 值，SOFAArk 容器会加载 bootstrap-${profile}.properties 配置文件。指定 profile 的配置有两种方式： + 通过 -D VM 参数传入，例如：-Dark.profile=dev,dev2 多个值使用 \u0026amp;lsquo;,\u0026amp;rsquo; 隔开。 + 通过应用启动参数传入，例如：java -jar demo-executable-ark.jar -Aprofile=dev,dev2 多个值使用 \u0026amp;lsquo;,\u0026amp;rsquo; 隔开。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-config/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"70dd9c389e65ee3f89573cf93bd466ec","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","summary":"SOFAArk 的配置目录不是必须存在，如果需要，统一放在工程根目录 ${baseDir}/conf/ark 下，执行 sofa-ark-maven-plugin 打包，将会自动将该目录下的配置打包至 Ark 包，例如 Ark 包目录为： . ├── META-INF │ └─","tags":null,"title":"SOFAArk 配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","wordcount":1036},{"author":null,"categories":null,"content":" 背景 SOFAArk 框架包含有三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下：\n每次应用启动时，首先运行 Ark 包，Ark Container 优先启动，容器自动解析 Ark 包中含有的 Ark Plugin 和 Ark Biz，并读取他们的配置信息，构建类和资源的加载索引表；然后使用独立的 ClassLoader 加载并按优先级配置依次启动；需要指出的是，Ark Plugin 优先 Ark Biz 被加载启动。 详细介绍可阅读： SOFAArk 介绍\n在三层概念的基础上，衍生出复杂的类加载机制，如图：\n详细介绍可阅读：Ark 容器类加载机制\n问题一 由于Ark Plugin的存在，插件在依赖层面的强管控，造成了一些问题 - 业务使用的依赖是被插件管控导出的，但是插件管控导出的版本与业务实际期望的版本不符（比如插件管控的版本是 1.0，而业务需要的是 2.0）。 - 插件对于依赖的强管控，直接堵住了业务扩展插件能力的路；也存在部分依赖，当业务引入时会直接报错（其package 被导出了，但是依赖不在插件中），那么对于业务来说就只能等框架发版解决。 - 业务接入成本，学习成本较高，问题排查困难，需要非常熟悉Ark类加载机制。 - 由于管控依赖的增长，Ark Plugin难以持续维护\n问题二 另外，由于Ark Container先于master biz启动，master biz的启动入口和springboot/sofaboot不一致，导致Ark master biz的的启动在研发运维中需要定制镜像，定制启动入口，造成研发运维困难。\nSOFAArk2.0 针对这些问题，我们尝试从框架层面去优化三层结构，沉淀出了SOFAArk2.0方案，整体优化思路和原则是 Ark Master Biz保持和原生springboot/sofaboot保持一致，弱化复杂的Ark Plugin类管控机制，将Ark Plugin与master biz合并。\nSOFAArk2.0方案整体优化点： - 弱化Ark Plugin层，改为普通pom依赖； - Ark master biz和原生的springboot/sofaboot应用启动方式，类加载方式保持一致； - 优化Ark Biz启动速度；\n升级方式 版本升级 SOFAArk版本号第一位为大版本号，当为1.x.x时为SOFAArk1.0版，当为2.x.x时是SOFAArk2.0版，当前2.0版本已正式release，Release-Notes\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;sofa.ark.version\u0026amp;gt;1.1.6\u0026amp;lt;/sofa.ark.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; 改为\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;sofa.ark.version\u0026amp;gt;2.0.0\u0026amp;lt;/sofa.ark.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; 打包插件 在SOFAArk1.0中使用sofa-ark-maven-plugin打包，在SOFAArk2.0中采用spring-boot原生打包插件spring-boot-maven-plugin打包\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 替换为：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 运行启动 方式一：IDEA启动 本地启动需要加上启动参数\n -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二：命令行启动 Ark包是可执行Jar，可直接使用Java -jar的方式启动，先使用 mvn clean package 进行打包，打包得到 ${bizName}-${bizVersion}-ark-biz.jar，命令行启动\n java -jar -Dsofa.ark.embed.enable=true …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-migration-guide/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b924edd10ef0e13f7220cff7c019d137","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","summary":"背景 SOFAArk 框架包含有三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下： 每次应用启动时，首先运行 Ark 包，Ark Container 优先启动，容器自动解析 Ark 包中含有的 Ark","tags":null,"title":"SOFAArk2.0 升级","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","wordcount":1266},{"author":null,"categories":null,"content":" Introduction SOFABolt is a network communication framework implemented based on Netty and developed by Ant Finance.\n Netty was developed to let Java programmers focus more on the implementation of network communication-based business logic, and not worry excessively about network low-level NIO implementation or network problems that are difficult to debug. SOFABolt was developed to let middleware developers focus more on the implementation of products\u0026amp;rsquo; functional performance, and not on making the communication framework\u0026amp;rsquo;s wheels over and over again. Bolt takes its name from a Disney movie character. Bolt is a light, easy-to-use, high-performance, and flexibly scalable communication framework based on the Netty best practices. In the past few years, we have solved a lot of problems in terms of network communication for microservices and message oriented middleware. We have accumulated a lot of experience and have been constantly optimizing and improving our solutions. We hope that our solutions can be incorporated into the SOFABolt base component to serve more network communication scenarios. At present, SOFABolt has already been put to use in many Ant Middleware products, such as microservice products (SOFARPC), message queue, distributed transactions, distributed switches, and configuration centers.\nMultiple languages supported node Python cpp ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/overview/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5ee08df7c4bbd2c3be846e16f3bc81b1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/overview/","summary":"Introduction SOFABolt is a network communication framework implemented based on Netty and developed by Ant Finance.\n Netty was developed to let Java programmers focus more on the implementation of network communication-based business logic, and not worry excessively about network low-level NIO implementation or network problems that are difficult to debug. SOFABolt was developed to let middleware developers focus more on the implementation of products\u0026rsquo; functional performance, and not on making the communication framework\u0026rsquo;s wheels over and over again.","tags":null,"title":"SOFABolt overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/overview/","wordcount":196},{"author":null,"categories":null,"content":" 功能架构 SOFABolt　的基础功能： 基础通信功能 ( remoting-core ) 基于 Netty 高效的网络 IO 与线程模型运用 连接管理 (无锁建连，定时断链，自动重连) 基础通信模型 ( oneway，sync，future，callback ) 超时控制 批量解包与批量提交处理器 心跳与 IDLE 事件处理 协议框架 ( protocol-skeleton ) 命令与命令处理器 编解码处理器 心跳触发器 私有协议定制实现 - RPC 通信协议 ( protocol-implementation ) RPC 通信协议的设计 灵活的反序列化时机控制 请求处理超时 FailFast 机制 用户请求处理器 ( UserProcessor ) 双工通信 用法1 将 SOFABolt 用作一个远程通信框架，使用者可以不用关心如何实现一个私有协议的细节，直接使用我们内置的 RPC 通信协议。可以非常简单的启动客户端与服务端，同时注册一个用户请求处理器，即可完成远程调用。同时，像连接管理、心跳等基础功能特性都默认可以使用。 当前支持的调用类型如下图所示：\n 示例 Demo 请参考我们的 用户手册 用法2 将 SOFABolt 用作一个协议框架，使用者可以复用基础的通信模型、协议包含的接口定义等基础功能。然后根据自己设计的私有协议自定义 Command 类型、Command 处理器、编解码处理器等。如下图所示，RPC 和消息的 Command 定义结构：\n","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-functions/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fde29139cbd8b786326a6479e52814dd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","summary":"功能架构 SOFABolt 的基础功能： 基础通信功能 ( remoting-core ) 基于 Netty 高效的网络 IO 与线程模型运用 连接管理 (无锁建连，定时断链，自动重连) 基础通信模型 ( oneway，","tags":null,"title":"SOFABolt 功能介绍","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","wordcount":450},{"author":null,"categories":null,"content":" 参与贡献 开放代码允许在签署协议之后,提交贡献代码.\n版权协议 对 SOFABolt 代码的修改和变更，需要遵守版权协议。\n准备工作 贡献代码前需要先了解git工具的使用和GitHub网站的使用。 git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git协作流程 GitHub 贡献代码流程 提issue 不论你是修复 Bolt 的bug还是新增 Bolt 的功能，在你提交代码之前，在 Bolt 的GitHub上提交一个 issue, 描述你要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突,产生重复工作。Bolt 的维护人员会对你提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提issue后，点击左上角的fork按钮，复制一份 Bolt 主干代码到你的代码仓库。\n拉分支 Bolt 所有修改都在分支上进行，修改完后提交 pull request ， 在code review 后由项目维护人员 merge 到主干。 因此，在获取源码步骤介绍后，你需要：\n 下载代码到本地,这一步你可以选择git/https方式. git clone https://github.com/sofastack/sofa-bolt.git 拉分支准备修改代码 git branch add_xxx_feature 执行完上述命令后，你的代码仓库就切换到相应分支了。执行如下命令可以看到你当前分支： git branch -a 如果你想切换回主干，执行下面命令: git checkout -b master 如果你想切换回分支，执行下面命令： git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 想直接从github上拉取分支到本地 git clone -b branchname https://xxx.git 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 Bolt 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行 mvn clean package 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在bugs，而新的代码已经解决了这些bugs. 你可以用如下命令运行所有测试\nmvn clean test 也可以通过IDE来辅助运行.\n其它注意事项 请保持你编辑的代码的原有风格,尤其是空格换行等. 对于无用的注释, 请直接删除 对逻辑和功能不容易被理解的地方添加注释. 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地: git commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到github上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面你是通过fork来做的,那么那么这里的 origin 是push到你的代码仓库，而不是 Bolt 的代码仓库.\n提交合并代码到主干的请求 在你的代码提交到GitHub后，你就可以发送请求来把你改好的代码合入 Bolt 主干代码了。此时你需要进入你的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是主干master, 系统会通知 Bolt 的人员，Bolt 人员会 review 你的代码，符合要求后就会合入主干，成为 Bolt 主干代码的一部分。\n代码review 在你提交代码后，你的代码会被指派给维护人员review,请保持耐心。如果在数天后，仍然没有人对你的提交给予任何回复，可以在pull request下面留言,并@对应的人员. 对于代码review的意见会提交到对应issue。如果觉得建议是合理的，也请你把这些建议更新到你的补丁中。\n合并代码到主干 在代码 Bolt 通过后，就由 Bolt 维护人员操作合入主干了。这一步不用参与,review合并之后,你会收到合并成功的提示.\nContributing to SOFABolt SOFABolt is released under the Apache 2.0 license, and follows a very standard Github development process, using Github tracker for issues and merging pull requests into master . If you would like to contribute something, or simply want to hack on the code this document should help you get started.\nSign the Contributor License Agreement Before we accept a non-trivial patch or pull request we will need you to sign the Contributor License Agreement. Signing the contributor’s agreement does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do. Active contributors might be asked to join the core team, and given the ability to merge pull requests.\nCode Conventions None of these is essential for a pull request, but they will all help.\n we provided a code formatter file, it will formatting automatically your project when during process of building.\n Make sure all new .java files to have a simple Javadoc class comment with at least an @author tag identifying you, and preferably at least a paragraph on what the class is for.\n Add the …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-contribution/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c044ad534cf99e4d6d400113b490f816","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","summary":"参与贡献 开放代码允许在签署协议之后,提交贡献代码. 版权协议 对 SOFABolt 代码的修改和变更，需要遵守版权协议。 准备工作 贡献代码前需要先了解git工具的使","tags":null,"title":"SOFABolt 参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","wordcount":1650},{"author":null,"categories":null,"content":" 发展路线 Version 1.5.1 修复项目中代码风格的问题：https://github.com/alipay/sofa-bolt/issues/85 修复项目中已知的BUG：https://github.com/alipay/sofa-bolt/issues/82 RPC 层支持从 IO 线程派发 message list：https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 整体目标 统一生命周期组件 抽象并沉淀网络组件的API 收敛配置入口\u0026amp;amp;增强配置的可扩展性 统一生命周期组件 在1.5.x的Bolt版本中，管理组件的生命周期相关的API命名并不统一，比如：\n ReconnectManager不需要启动或者初始化，关闭方法为stop DefaultConnectionMonitor初始化方法为start，关闭的方法为destroy RpcClient初始化方法为init，关闭的方法为shutdown RpcTaskScanner初始化的方法为start，关闭方法为shutdown 在1.6.0版本里，统一了所有组件的生命周期接口：\n 对于有生命周期的组件，即使用前需要进行初始化，使用完毕需要释放资源的，统一提供startup/shutdown接口 抽象并沉淀网络组件的API Bolt中remoting类是网络操作的主要入口，目前以抽象类的形式提供，后续希望对方法进行收敛，暴露对应的接口：\n 标准化，规范使用 沉淀接口，保持稳定 收敛入口，便于内部的代码迭代 在1.5.x的版本中，ReconnectManager类尽管提供了public的addCancelUrl方法，但是这个方法在Bolt项目中没有调用：\n IDE会给出警告 给用户造成困惑：这个方法可否删除？ 在1.6.0版本中解决了以上的问题，抽象出一套稳定的API，便于用户使用、提升代码可读性，同时也为后续的迭代打下基础。\n收敛配置入口\u0026amp;amp;增强配置的可扩展性 1.5.x版本的Bolt配置入口有以下几个：\n ProtocolSwitch：协议配置（是否开启CRC校验），通过静态的方法创建配置对象 GlobalSwitch：实例级配置，每个AbstractConfigurableInstance拥有自己的GlobalSwitch配置，默认值取自SystemProperty，可以通过API调整配置 ConfigItem：Netty相关的配置项的枚举，不可以继承拓展（用户需要修改源码） ConfigManager：配置读取入口，通过静态方法读取SystemProperty的配置 Configs：配置项名称的定义和配置项的默认值 整体上看Bolt的配置项比较零散，且对用户来说难以拓展使用，有以接口暴露的配置项、有以静态方法暴露的配置项，配置项可以通过系统参数配置也可以通过API执行配置。\n且Bolt配置项存在相互影响的问题，比如一个产品同时使用了RPC和消息，而RPC和消息底层都依赖于Bolt，那么基于SystemProperty的配置将无法做到RPC和消息的配置隔离。\n在1.6.0版本中对配置模块进行了调整，在兼容当前版本配置的情况下：\n 收敛配置入口，提供统一的配置的编程界面（以类似Netty的Option的方式进行配置） 支持配置隔离，不同的Bolt实例使用不同的配置项 提升配置的可扩展性 ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-roadmap/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3d4eac90b5c8e657d14eb885ab1f9a92","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","summary":"发展路线 Version 1.5.1 修复项目中代码风格的问题：https://github.com/alipay/sofa-bolt/issues/85 修复项目中已","tags":null,"title":"SOFABolt 发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","wordcount":1356},{"author":null,"categories":null,"content":" 介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生。 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，积累了很多经验，并持续的进行着优化和完善，我们希望能把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。 目前该产品已经运用在了蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n多语言 node python cpp ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/overview/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5ee08df7c4bbd2c3be846e16f3bc81b1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/overview/","summary":"介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于","tags":null,"title":"SOFABolt 概述","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/overview/","wordcount":369},{"author":null,"categories":null,"content":" 用户指南 maven coordinator \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; check release note for version\n 1. 基础功能 1.1 实现用户请求处理器 (UserProcessor) 我们提供了两种用户请求处理器，SyncUserProcessor 与 AsyncUserProcessor。 二者的区别在于，前者需要在当前处理线程以return返回值的形式返回处理结果；而后者，有一个 AsyncContext 存根，可以在当前线程，也可以在异步线程，调用 sendResponse 方法返回处理结果。示例可参考如下两个类：\n 同步请求处理器 异步请求处理器 1.2 实现连接事件处理器 (ConnectionEventProcessor) 我们提供了两种事件监听，建连事件（ConnectionEventType.CONNECT）与断连事件（ConnectionEventType.CLOSE），用户可以创建自己的事件处理器，并注册到客户端或者服务端。客户端与服务端，都可以监听到各自的建连与断连事件。\n 处理连接建立事件 处理连接断开事件 1.3 客户端与服务端初始化 (RpcClient，RpcServer) 我们提供了一个 RpcClient 与 RpcServer，经过简单的必要功能初始化，或者功能开关，即可使用。一个最简单的例子如下：\n 客户端初始化示例 服务端初始化示例 1.4 基础通信模型 我们提供了四种通信模型：\n1.Oneway 调用\n当前线程发起调用后，不关心调用结果，不做超时控制，只要请求已经发出，就完成本次调用。注意 Oneway 调用不保证成功，而且发起方无法知道调用结果。因此通常用于可以重试，或者定时通知类的场景，调用过程是有可能因为网络问题，机器故障等原因，导致请求失败。业务场景需要能接受这样的异常场景，才可以使用。请参考示例。\n2. Sync 同步调用\n当前线程发起调用后，需要在指定的超时时间内，等到响应结果，才能完成本次调用。如果超时时间内没有得到结果，那么会抛出超时异常。这种调用模式最常用。注意要根据对端的处理能力，合理设置超时时间。请参考示例。\n3. Future调用\n当前线程发起调用，得到一个 RpcResponseFuture 对象，当前线程可以继续执行下一次调用。可以在任意时刻，使用 RpcResponseFuture 对象的 get() 方法来获取结果，如果响应已经回来，此时就马上得到结果；如果响应没有回来，则会阻塞住当前线程，直到响应回来，或者超时时间到。请参考示例。\n4. Callback异步调用\n当前线程发起调用，则本次调用马上结束，可以马上执行下一次调用。发起调用时需要注册一个回调，该回调需要分配一个异步线程池。待响应回来后，会在回调的异步线程池，来执行回调逻辑。请参考示例。\n1.5 日志打印 SOFABolt 只依赖 SLF4J 作为日志门面。同时提供了 log4j、log4j2、logback 三种日志模板，使用者只需要在运行时依赖某一种日志实现，我们依赖的 sofa-common-tools 组件，会在运行时动态感知是哪一种日志实现，同时加载正确的日志模板，进行打印。日志会打印在 ~/logs/bolt/ 目录下面，包括如下几种日志：\n common-default.log：默认日志，打印一些客户端、服务器启动、关闭等通信过程的普通日志 common-error.log：异常日志，框架运行过程中出现的异常 connection-event.log：连接事件日志 remoting-rpc.log：RPC 协议相关的日志 关于日志依赖，可以参考日志实现依赖参考\n2. 进阶功能 2.1 请求上下文 在调用过程中，我们还提供了带 InvokeContext 的接口，并一路传递下去，可以在自定义序列化器，用户请求处理器中获得。我们分为两种场景来使用请求上下文：\n 客户端：用户可以设置一些针对本次请求生效的参数，比如序列化类型，是否开启crc等机制。同时可以从上下文中获取建连耗时，连接信息等。 服务端：用户可以从用户请求处理器中获得请求到达后的排队耗时，连接信息等 注意：客户端与服务端的上下文是独立的，即客户端设置的上下文只在客户端可见，对服务端不可见；反之同理。 使用示例 2.2 双工通信 除了服务端可以注册用户请求处理器，我们的客户端也可以注册用户请求处理器。此时，服务端就可以发起对客户端的调用，也可以使用 1.4 提到了任何一种通信模型。\n 示例1：使用 Connection 对象的双工通信，注意使用 Connection 对象的双工通信，服务端需要通过事件监听处理器或者用户请求处理器，自己保存好 Connection 对象。 示例2：使用 Address 的双工通信，注意使用 Address 方式的双工通信，需要在初始化 RpcServer 时，打开 manageConnection 开关，表示服务端会根据客户端发起的建连，维护一份地址与连接的映射关系。默认不需要双工通信的时候，这个功能是关闭的。 2.3 建立多连接与连接预热 通常来说，点对点的直连通信，客户端和服务端，一个 IP 一个连接对象就够用了。不管是吞吐能力还是并发度，都能满足一般业务的通信需求。而有一些场景，比如不是点对点直连通信，而是经过了 LVS VIP，或者 F5 设备的连接，此时，为了负载均衡和容错，会针对一个 URL 地址建立多个连接。我们提供如下方式来建立多连接，即发起调用时传入的 URL 增加如下参数 127.0.0.1:12200?_CONNECTIONNUM=30\u0026amp;amp;_CONNECTIONWARMUP=true，表示针对这个 IP 地址，需要建立30个连接，同时需要预热连接。其中预热与不预热的区别是：\n 预热：即第一次调用（比如 Sync 同步调用），就建立30个连接 不预热：每一次调用，创建一个连接，直到创建满30个连接 使用示例 2.4 自动断连与重连 通常 RPC 调用过程，是不需要断链与重连的。因为每次 RPC 调用过程，都会校验是否有可用连接，如果没有则新建一个。但有一些场景，是需要断链和保持长连接的：\n 自动断连：比如通过 LVS VIP 或者 F5 建立多个连接的场景，因为网络设备的负载均衡机制，有可能某一些连接固定映射到了某几台后端的 RS 上面，此时需要自动断连，然后重连，靠建连过程的随机性来实现最终负载均衡。注意，开启了自动断连的场景，通常需要配合重连使用。 重连：比如客户端发起建连后，由服务端来通过双工通信，发起请求到客户端。此时如果没有重连机制，则无法实现。 使用示例，注意考虑一个进程可能会有多个 SOFABolt 的通信实例，我们提供了全局开关以及用户开关两种开关方式： …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-handbook/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2a0a2e3c7749dbcdceea064f6f850e33","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","summary":"用户指南 maven coordinator \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; check release note for version 1. 基础功能 1.1 实现用户请求处理器 (UserProcessor) 我们提供了两种用户请求处理器，SyncUserProcessor 与 Async","tags":null,"title":"SOFABolt 用户手册","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","wordcount":3516},{"author":null,"categories":null,"content":" 相关链接 ISSUES 用户手册 中文介绍文章: 蚂蚁通信框架实践 ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/related-links/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6844d2a639b69fa3128132b8631f33e3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/related-links/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/related-links/","summary":"相关链接 ISSUES 用户手册 中文介绍文章: 蚂蚁通信框架实践","tags":null,"title":"SOFABolt 相关链接","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/related-links/","wordcount":24},{"author":null,"categories":null,"content":" # Upgrade SOFABoot from 2.3.x/2.4.x to 2.5.x SOFABoot 2.3.x/2.4.x is developed based on Spring Boot 1.4.2.RELEASE, SOFABoot 2.5.x is developed based on Spring Boot 1.5.x. When upgrading SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x, we should pay special attention to the differences between the Spring Boot 1.5.x upgrade and the Spring Boot 1.4.x upgrade.\nRenamed Spring Boot Starters spring-boot-starter-ws \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-data-redis Endpoint Security Control Spring Boot 1.5.x has security control over all sensitive endpoints by default, that is, endpoints such as /beans and /dump, which were previously accessible by default in version 1.4.x, are not accessible in version 1.5.x. To access such endpoints, we need to configure Spring Boot as follows: \u0026amp;gt; management.security.enabled=false\nOnly /health, /info, and /docs are accessible by default in version 1.5.x. Please refer to official description for details: + endpoints + Accessing sensitive endpoints\nApplicationEvent Change ApplicationStartedEvent in 1.4.x has been renamed ApplicationStartingEvent in Spring Boot 1.5.x. The version 1.5.x remains forward compatible. Note that the ApplicationStartedEvent event has a completely different meaning in version 2.x.\n** Users who have upgraded the SOFABoot to the version 2.5.x are strongly advised to change ApplicationStartedEvent to ApplicationStartingEvent to avoid compatibility issues when upgrading SOFABoot to the version 3.0.x in the future.**\nProperty renaming server.max-http-post-size \u0026amp;ndash;\u0026amp;gt; server.tomcat.max-http-post-size spring.data.neo4j.session.scope is removed Refer to the configuration of Spring Boot 1.5.x changelog\nSummary The above are the major points worthy of notice when we upgrade SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x. For detailed information, refer to the Release Report of Spring Boot 1.5.x.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_2_5_x/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4b7dd4287b00106684831d2a8524a6f7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","summary":"# Upgrade SOFABoot from 2.3.x/2.4.x to 2.5.x SOFABoot 2.3.x/2.4.x is developed based on Spring Boot 1.4.2.RELEASE, SOFABoot 2.5.x is developed based on Spring Boot 1.5.x. When upgrading SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x, we should pay special attention to the differences between the Spring Boot 1.5.x upgrade and the Spring Boot 1.4.x upgrade.\nRenamed Spring Boot Starters spring-boot-starter-ws \u0026ndash;\u0026gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026ndash;\u0026gt; spring-boot-starter-data-redis Endpoint Security Control Spring Boot 1.","tags":null,"title":"SOFABoot 2.5.x upgrade","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","wordcount":251},{"author":null,"categories":null,"content":" SOFABoot 2.3.x/2.4.x 升级到 2.5.x SOFABoot 2.3.x/2.4.x 基于 Spring Boot 1.4.2.RELEASE 版本开发，SOFABoot 2.5.x 则是基于 Spring Boot 1.5.x 版本开发。 从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 需要重点考虑 Spring Boot 1.5.x 相较 Spring Boot 1.4.x 的升级注意点。\n重命名的 spring boot starters spring-boot-starter-ws \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-data-redis endpoint 安全性控制 Spring Boot 1.5.x 对所有 Sensitive Endpoint 默认进行了安全管控，即之前在 1.4.x 默认能访问的诸如 /beans, /dump 等 endpoints 在 1.5.x 版本均不能访问。如果需要访问，需要配置： \u0026amp;gt; management.security.enabled=false\n默认情况下，在 1.5.x 只有 /health, /info, /docs 能够访问。详细请参考官方描述： + endpoints + Accessing sensitive endpoints\nApplicationEvent 变更 Spring Boot 1.5.x 将 1.4.x 中的 ApplicationStartedEvent 重命名为 ApplicationStartingEvent，在 1.5.x 仍然保持向前兼容。需要格外注意的是，在 2.x 版本中，ApplicationStartedEvent 事件意义完全不一样。\n强烈建议升级到 SOFABoot 2.5.x 的用户，将应用中使用的 ApplicationStartedEvent 变更为 ApplicationStartingEvent；避免今后升级至 SOFABoot 3.0.x 出现兼容性问题\nProperty 重命名 server.max-http-post-size \u0026amp;ndash;\u0026amp;gt; server.tomcat.max-http-post-size spring.data.neo4j.session.scope 被移除 具体参考 Spring Boot 1.5.x 配置的 changelog\n总结 以上总结了从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 的几个主要注意点，详细可以参考 Spring Boot 1.5.x 的发布报告\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_2_5_x/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4b7dd4287b00106684831d2a8524a6f7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","summary":"SOFABoot 2.3.x/2.4.x 升级到 2.5.x SOFABoot 2.3.x/2.4.x 基于 Spring Boot 1.4.2.RELEASE 版本开发，SOFABoot 2.5.x 则是基于 Spring Boot 1.5.x 版本开发。 从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 需要重点考虑 Spring Boot 1.5.x 相较 Spring Boot 1.4.x 的升级注意点。 重命","tags":null,"title":"SOFABoot 2.5.x 升级注意事项","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","wordcount":404},{"author":null,"categories":null,"content":" ## Preface As a Spring Boot-based development framework open sourced by Ant Financial, SOFABoot provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nWe have received a lot of feedback from community users since SOFABoot was open sourced in April 2018. We are also very pleased to see many community users take an active part in building the SOFAStack open source, which greatly increases our determination to prosper SOFAStack community and ecosystem. Here, we announce the release of the SOFABoot 3.0, which is developed based on Spring Boot 2.0. SOFABoot 3.0 allows us to seamlessly integrate the extension capability of SOFABoot with official components of Spring Boot 2.x. In addition, SOFABoot 3.0 is compatible with Spring Cloud components, which allows us to easily integrate Spring Cloud components like Zuul and Config in the SOFABoot framework.\nBelow are the major changes of SOFABoot 3.0 compared with SOFABoot 2.x.\nUpgrade Spring Boot to version 2.x Upgrade Spring Boot in SOFABoot 3.0 to version 2.0. As the Spring Boot community recently announced that the maintenance for version 1.x will end in August 2019, we will focus on SOFABoot 3.x in the future and will release SOFABoot 3.1 with Spring Boot upgraded to version 2.1 soon.\nSpring Cloud compatible Some components are not compatible with SOFABoot in SOFABoot 2.x. In SOFABoot 3.x, we have run thorough compatibility tests on Spring Cloud components and fixed all problems found to ensure good compatibility between SOFABoot 3.x and Spring Cloud.\nWebFlux framework compatible Spring Boot 2.x introduces the WebFlux framework. SOFABoot 3.x is compatible with WebFlux in two major aspects; + Health Check is compatible with the ReactiveHealthIndicator extension interface. The Readiness Check will include the implementation of the interface extension; + Compatible with buried points of WebFlux web requests. Point burying logs and files are compatible with common MVC requests. For detailed information, refer to MVC point burying request.\nJDK version support SOFABoot 3.x must run on JDK 8 or higher versions and does not support JDK 6 and JDK 7.\nHealth Check SOFABoot adds Readiness Check capability to Spring Boot\u0026amp;rsquo;s Health Check capability, to ensure that all components and operations are in a healthy state before the application goes into services. Compared with SOFABoot 2.x, SOFABoot 3.0 features great adjustments to the Health Check. It abandons some internal compatibility logic of Ant Financial and uses a friendlier coding scheme. Besides, the Health Check of SOFABoot 3.0 offers extensions in various scenarios, supports the \u0026amp;lsquo;ReactiveHealthIndicator\u0026amp;rsquo; extension interface introduced in Spring Boot 2.x, and provides more Health Check extension features.\nAdjust the Readiness Check Endpoint path The Endpoint for checking the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_3_x/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"91ba09adf6bc42aaf70645b9a19b409b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","summary":"## Preface As a Spring Boot-based development framework open sourced by Ant Financial, SOFABoot provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nWe have received a lot of feedback from community users since SOFABoot was open sourced in April 2018. We are also very pleased to see many community users take an active part in building the SOFAStack open source, which greatly increases our determination to prosper SOFAStack community and ecosystem.","tags":null,"title":"SOFABoot 3.0 upgrade","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","wordcount":910},{"author":null,"categories":null,"content":" 前言 SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n自今年 4 月份 SOFABoot 开源至今，我们收到了非常多来自社区同学的反馈，也非常高兴的看到很多社区同学积极的参与到 SOFAStack 开源共建，这极大了鼓舞了我们建设 SOFAStack 开源社区的决心，力图把 SOFAStack 社区和生态建设更加繁荣。在此，我们宣布推出 SOFABoot 3.0 版本，SOFABoot 3.0 是基于 Spring Boot 2.0 版本开发。在 SOFABoot 3.0 中，可以将 SOFABoot 扩展能力和 Spring Boot 2.x 官方组件无缝集成。此外，我们在 SOFABoot 3.0 中兼容了 Spring Cloud 组件集成，可以很方便地在 SOFABoot 框架中集成 Spring Cloud 组件，如 Zuul, Config 等。\n以下，本文将详细介绍 SOFABoot 3.0 相较 SOFABoot 2.x 的变更。\nSpring Boot 升级 2.x SOFABoot 3.0 版本升级 Spring Boot 版本至 2.0。鉴于Spring Boot 社区最近刚公告 1.x 版本将维护至明年 8 月份为止，未来，我们也将主力维护 SOFABoot 3.x 版本，近期也将发布 SOFABoot 3.1 升级 Spring Boot 版本至 2.1。\nSpring Cloud 兼容 在 SOFABoot 2.x 中，存在部分组件和 SOFABoot 兼容性问题。在 SOFABoot 3.x 中，对 Spring Cloud 各组件进行了比较完备的兼容性测试和问题修复，保证了 SOFABoot 3.x 与 Spring Cloud 良好的兼容性。\nWebFlux 框架兼容 Spring Boot 2.x 引入了 WebFlux 框架，SOFABoot 3.x 主要在两个方面兼容了 WebFlux 框架； + 健康检查兼容了 ReactiveHealthIndicator 扩展接口，业务对这个接口的扩展实现将会纳入到 Readiness Check； + 兼容对 WebFlux 网络请求进行埋点，埋点日志格式和文件保持对普通 MVC 请求兼容，详细参考MVC 埋点请求\nJDK 版本支持 SOFABoot 3.x 最低要求运行在 JDK 8 及其以上版本，不支持 JDK 6，7。\n健康检查 SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 能力，以确保应用在正常对外服务前，所有组件及业务本身处于健康状态。相较于与 SOFABoot 2.x, SOFABoot 3.0 在健康检查做了很大的重构，主要是剥离了部分蚂蚁金服内部兼容逻辑，采用更加友好的编码方案；其次，SOFABoot 3.0 健康检查提供了多种不同场景下的健康检查扩展形式，支持 Spring Boot 2.x 引入的 ReactiveHealthIndicator 扩展接口，丰富了健康检查扩展特性。\n调整 Readiness Check Endpoint 路径 在 SOFABoot 2.x 中，查看健康检查结果的 Endpoint 为 /health/readiness，而在 SOFABoot 3.0 中，变更为 /actuator/readiness。\n扩展接口变更 在 SOFABoot 3.x 中，提供四种方式扩展健康检查，分别是 + HealthChecker + HealthIndicator(Spring Boot 原生) + ReactiveHealthIndicator(Spring Boot 原生) + ReadinessCheckCallback\n这四个接口的扩展实现执行顺序是 HealthChecker \u0026amp;gt; HealthIndicator, ReactiveHealthIndicator \u0026amp;gt; ReadinessCheckCallback，相同接口的扩展实现执行顺序则遵循 Spring Boot 标准的方案。即扩展类可以额外实现两个标准的 Order 接口：\n org.springframework.core.Ordered org.springframework.core.PriorityOrdered 或者使用注解\n org.springframework.core.annotation.Order 这些接口的扩展实现处理结果将会在健康检查结果查中展现。\n删除 SofaBootBeforeHealthCheckEvent 事件 在 SOFABoot 2.x 中，我们没有提供支持对健康检查扩展实现进行排序，导致用户无法预期自身扩展执行时机。如上述，SOFABoot 3.x 支持各组件扩展实现的排序，因此该事件可以统一使用 HealthChecker 接口和高优先级顺序实现替代。其次，在 SOFABoot 2.x 中，SofaBootBeforeHealthCheckEvent 事件的处理逻辑结果并不会反应在健康检查结果中，使用 HealthChecker 替代之后，这部分逻辑处理自然变成健康检查的一部分，可供查看。\n删除 DefaultHealthChecker 接口 使用 JDK8 默认方法特性，删除 DefaultHealthChecker 接口，用户可以直接使用 HealthChecker 接口替代 DefaultHealthChecker.\n删除 SofaBootMiddlewareAfterReadinessCheckCallback 和 SofaBootAfterReadinessCheckCallback 接口 在 SOFABoot 2.x 中，这两个接口是两种场景下的健康检查回调；推荐 SOFABoot 官方 Starter 使用 SofaBootMiddlewareAfterReadinessCheckCallback，而业务应用推荐使用SofaBootAfterReadinessCheckCallback，框架将优先执行 SofaBootMiddlewareAfterReadinessCheckCallback 的扩展实现，然后执行 SofaBootAfterReadinessCheckCallback 的扩展实现。这样的设计有两个缺陷： + 两个接口本质没有区别，但是隐藏了先后顺序逻辑，给用户引入了额外的学习成本； + 只考虑了 SofaBootMiddlewareAfterReadinessCheckCallback 和 SofaBootAfterReadinessCheckCallback 两个接口的顺序，但无法保证相同接口实现的执行顺序。\nSOFABoot 3.x …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_3_x/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"91ba09adf6bc42aaf70645b9a19b409b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_3_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_3_x/","summary":"前言 SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFA","tags":null,"title":"SOFABoot 3.0 升级注意事项","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_3_x/","wordcount":1687},{"author":null,"categories":null,"content":" Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开发。\n二方库升级 SOFABoot 4.0 基于 Spring Boot 3.0 与 Spring Framework 6 构建。在 Spring Boot 3.0 与 Spring Framework 6 引入的二方库升级列表可参考文档👉 Spring Boot 3.0 Release Notes\n在 SOFABoot 4.0 引入的二方库升级列表如下：\n Spring Boot 3.0.7 Spring Cloud 4.0.0 Spring Cloud Stream 3.2.6 SOFA Common tools 2.0.0 SOFATracer 4.0.0 SOFARPC 5.10.0 FastJson 1.2.83 Guava 31.1-jre Grpc 1.51.1 Grpc common protos 2.11.0 Druid 1.2.16 ASM 9.4 Javassist 3.29.2-GA Curator 4.3.0 Dubbo 3.1.8 Nacos 2.0.3 Swagger 1.6.7 Swagger2 2.2.8 基于 Jakarta EE Spring Boot 3.0 中依赖 Jakarta EE 规范的部分已经升级到了 Jakarta EE 10 版本。例如，使用 Servlet 6.0 和 JPA 3.1 规范。因此，部分包的命名空间也进行了替换，例如你应该使用：\n✅jakarta.servlet.Filter\n而不是 javax.servlet.Filter。\n同时，如果你使用了自己的依赖提供 Jakarta EE 规范的 API，需注意进行对应的依赖升级，例如你应该使用：\n✅jakarta.servlet:jakarta.servlet-api\n而不是 javax.servlet:javax.servlet-api。\n可参考文档：Migrate to Jakarta EE 9 来修改 Jakarta 相关的包名以及依赖。\n支持 SOFAArk 2.0 SOFAArk 2.0 模式是 SOFAArk 框架的整体优化版本，相较于 SOFAArk 1.0 模式，它的整体优化思路和原则是 Ark Master Biz 保持和原生 SOFABoot 保持一致，弱化复杂的 Ark Plugin 类管控机制，将 Ark Plugin 与 Master Biz 合并。使得 Ark Master Biz 和原生 SOFABoot 应用的启动方式、类加载方式保持一致，大大降低了 Master Biz 应用的编程难度。\nSOFABoot 4.0 版本不再支持 SOFAArk 1.0 模式，如果你想要在 SOFABoot 应用中使用 SOFAArk 2.0 模式，可以按照以下步骤进行操作：\n1、在项目中引入 SOFAArk 组件依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;ark-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2、添加 Spring Boot 的 Package 插件\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 3、启动应用\n 方式一： IDEA 启动，注意需要添加启动参数：-Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二： 命令行启动，先运行 mvn clean package 命令进行打包，生成 ${bizName}-${bizVersion}-ark-biz.jar 的可执行文件，然后在终端运行以下启动参数：\njava -jar -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName} ${bizName}-${bizVersion}-ark-biz.jar\n支持场景化的按配置加载能力 通常情况下，应用在不同的场景下可能需要开启或者关闭不同的功能，Spring Boot 提供了丰富的 Configuration 动态配置能力[4] 能力以支持应用在不同的场景下加载不同的 Bean。\nSOFABoot 在此基础上，对 org.springframework.context.ApplicationContextInitializer 等扩展点进行了增强，支持通过统一风格的配置定制各类 Bean 以及扩展点的开启与关闭，并提供了定制模版配置的开启方式以降低应用配置项的复杂度。\n 通过： com.alipay.sofa.boot.autoconfigure.condition.ConditionalOnSwitch 注解为 Bean 添加按配置开启能力：\n@Configuration(proxyBeanMethods = false) @ConditionalOnSwitch(id=\u0026amp;quot;sample\u0026amp;quot;) public class SampleConfiguration { @Bean public SampleBean sampleBean() { return new SampleBean(); } } 添加：\nsofa.boot.switch.bean.sample.enabled=false 配置后，SampleConfiguration 配置类将不再加载。\n 通过继承： …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_4_x/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5c33e340d1a0200b2dac6aa548142849","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_4_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_4_x/","summary":"Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开","tags":null,"title":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_4_x/","wordcount":3757},{"author":null,"categories":null,"content":" SOFABoot supports modular isolation. But in actual usage scenarios, There is one case that beans in one module sometimes need to open some entries for another module to expand. SOFABoot draws on and uses the Nuxeo Runtime project and the nuxeo project and expands on it, provides the ability to extend points with Spring, We call it Extension Point.\nUsage Using extension point capabilities in SOFABoot requires the following three steps:\nDefine a bean that provides extension capabilities When using the SOFABoot extension point capability, you first need to define an interface that needs to be extended, like:\npackage com.alipay.sofa.boot.test; public interface IExtension { String say(); } Define the implementation of this interface:\npackage com.alipay.sofa.boot.test.impl; public class ExtensionImpl implements IExtension { private String word; @Override public String say() { return word; } public void setWord(String word) { this.word = word; } public void registerExtension(Extension extension) throws Exception { Object[] contributions = extension.getContributions(); String extensionPoint = extension.getExtensionPoint(); if (contributions == null) { return; } for (Object contribution : contributions) { if (\u0026amp;quot;word\u0026amp;quot;.equals(extensionPoint)) { setWord(((ExtensionDescriptor) contribution).getValue()); } } } } Here you can see that there is a method: registerExtension, you can temporarily ignore this method, and later will introduce its specific role.\nIn the module\u0026amp;rsquo;s Spring configuration file, we add configuration of this bean:\n\u0026amp;lt;bean id=\u0026amp;quot;extension\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.test.impl.ExtensionImpl\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;word\u0026amp;quot; value=\u0026amp;quot;Hello, world\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; Defining extension points There is a field word in the above bean. In practice, we want this field to be overridden by other module customizations. Here we expose it as an extension point.\nFirst, you need a class to describe this extension point:\n@XObject(\u0026amp;quot;word\u0026amp;quot;) public class ExtensionDescriptor { @XNode(\u0026amp;quot;value\u0026amp;quot;) private String value; public String getValue() { return value; } } Then define the extension point in xml:\n\u0026amp;lt;sofa:extension-point name=\u0026amp;quot;word\u0026amp;quot; ref=\u0026amp;quot;extension\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:object class=\u0026amp;quot;com.alipay.sofa.boot.test.extension.ExtensionDescriptor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:extension-point\u0026amp;gt; among them: - name is the name of the extension point - ref is the bean to which the extension point is applied - object is a concrete description of the contribution point of the extension point. This description is done by XMap (XMap is used to map Java objects and XML files. It is recommended to search XMap documents on the Internet to understand XMap)\nDefining extension implements The above has defined the extension point, and we can extend this bean at this point:\n\u0026amp;lt;sofa:extension bean=\u0026amp;quot;extension\u0026amp;quot; point=\u0026amp;quot;word\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:content\u0026amp;gt; \u0026amp;lt;word\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/extension/","fuzzywordcount":1300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"93225b6c1f2b68f2047a7cf49b76650b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/extension/","summary":"SOFABoot supports modular isolation. But in actual usage scenarios, There is one case that beans in one module sometimes need to open some entries for another module to expand. SOFABoot draws on and uses the Nuxeo Runtime project and the nuxeo project and expands on it, provides the ability to extend points with Spring, We call it Extension Point. Usage Using extension point capabilities in SOFABoot requires the following three","tags":null,"title":"SOFABoot Extension Point","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/extension/","wordcount":1279},{"author":null,"categories":null,"content":" Spring 框架从 3.1.X 版本开始提供了 profile 功能: Bean Definition Profiles，SOFABoot 支持模块级 profile 能力，即在各个模块启动的时候决定模块是否能够启动。\n使用 Module-Profile 激活 module 使用 SOFABoot 的 profile 功能，需要在 application.properties 文件增加 com.alipay.sofa.boot.active-profiles 字段，该字段的值为逗号分隔的字符串，表示允许激活的 profile 列表，指定该字段后，SOFABoot 会为每个可以激活的模块指定此字段表示的 profile 列表。\nSOFABoot 模块的 sofa-module.properties 文件支持 Module-Profile 字段，该字段的值为逗号分隔的字符串，表示当前模块允许在哪些 profile 激活。Module-Profile 支持取反操作， !dev 表示 com.alipay.sofa.boot.active-profiles 不包含 dev 时被激活。\n当应用未指定 com.alipay.sofa.boot.active-profiles 参数时，表示应用所有模块均可启动。SOFABoot 模块未指定 Module-Profile 时，表示当前 SOFABoot 模块可以在任何 profile 启动。\n使用例子 激活 dev SOFABoot 模块 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev 该配置表示激活 profile 为 dev 的模块。\n在每个需要限定为 dev profile 被激活模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=dev 配置多个激活 profile application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev,test 该配置表示激活 profile 为 dev 或者 test 的模块。\n在 SOFABoot 模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=test,product 该配置表示当 com.alipay.sofa.boot.active-profiles 包含 test 或者 product 时激活模块，由于当前指定的 com.alipay.sofa.boot.active-profiles 为 dev,test ，此模块将被激活。\nModule-Profile 取反 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev 该配置表示激活 profile 为 dev 的模块。\n在 SOFABoot 模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=!product 该配置表示当 com.alipay.sofa.boot.active-profiles 不包含 product 时激活模块，由于当前指定的 com.alipay.sofa.boot.active-profiles 为 dev ，此模块将被激活。\n设置激活模块 Spring 上下文的 spring.profiles.active 属性 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev,test 该配置表示激活 profile 为 dev 或者 test 的模块，当一个模块满足上面的激活条件时，这个模块就会被启动，同时 Spring 上下文的环境信息 spring.profiles.active 也被设置为了 dev,test ，这样如下的配置 beanId 为 devBeanId 和 testBeanId 的bean都会被激活。\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:jdbc=\u0026amp;quot;http://www.springframework.org/schema/jdbc\u0026amp;quot; xmlns:jee=\u0026amp;quot;http://www.springframework.org/schema/jee\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.2.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;beans profile=\u0026amp;quot;dev\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;devBeanId\u0026amp;quot; class=\u0026amp;quot;com.alipay.cloudenginetest.sofaprofilesenv.DemoBean\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;name\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;demoBeanDev\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/property\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; \u0026amp;lt;beans profile=\u0026amp;quot;test\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBeanId\u0026amp;quot; class=\u0026amp;quot;com.alipay.cloudenginetest.sofaprofilesenv.DemoBean\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;name\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;demoBeanTest\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/property\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-profile/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b29d568fa057cad0b440790d5cc65d07","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-profile/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-profile/","summary":"Spring 框架从 3.1.X 版本开始提供了 profile 功能: Bean Definition Profiles，SOFABoot 支持模块级 profile 能力，即在各个模块启动的时候决定模块是否能够启动。 使用 Module-Profile 激","tags":null,"title":"SOFABoot Profile","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-profile/","wordcount":666},{"author":null,"categories":null,"content":" Background kc-sofastack-demo has introduced how to quickly build an e-commerce microservice application and has implemented the service calling link tracking and application status monitoring.\nIn e-commerce system, the platforms often are not satisfied with the default product listing order, and always want to arrange some products in the conspicuous places. Also, there are some cases where the platforms would like to show different products to different users based on the collected user behaviors.\nBased on the background of kc-sofastack-demo, this guide will implement sorting the products dynamically based on the total amount of products of each onsite attendee.\nDemo content Implement the dynamic change of product sorting via the dynamic module capability provided by SOFABoot and the dynamic module control capability of SOFADashboard.\nImplement the change of application behavior without restarting the host and without changing the application configuration.\nThe project architecture is as follows:\nTasks 1. Preparation Clone the demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-dynamic-demo.git Then, import the project into IDEA or Eclipse.\n2. Package SOFABoot project as Ark JAR As shown in the following screenshot, add the Ark package plugin in the POM file and configure it:\nStep 1: Copy the Ark plugin and configuration to the specified positions in the above screenshot \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!-- package configuration of ark-biz JAR --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Whether to package, install and publish ark biz. The default value is false. For details, see Ark Biz documentation.--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!-- The directory for ark package and ark biz package, defaulting to the build directory of project--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- The priority of starting ark-biz package. The smaller the value, the higher the priority.--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;200\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--Set the root directory of application, used to read ${base.dir}/conf/ark/bootstrap.application configuration file and defaulting to ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;../\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Step 2: Run mvn clean package to package the project. The successfully packaged JAR file is as shown in the following screenshot:\n3. Build host application In the downloaded project, dynamic-stock-mng is the host application model. In this task, we will build dynamic-stock-mng as the host application of dynamic module.\nStep 1: Introduce Ark …","date":-62135596800,"description":"This guide introduce how to implement the merged deployment and dynmaic module push provided by SOFAArck based on the Ark control function of SOFADashboard.","dir":"guides/kc-sofastack-dynamic-demo/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"8bfd4a50e21ce9fc867b1cf18a8c9af3","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","summary":"Background kc-sofastack-demo has introduced how to quickly build an e-commerce microservice application and has implemented the service calling link tracking and application status monitoring.\nIn e-commerce system, the platforms often are not satisfied with the default product listing order, and always want to arrange some products in the conspicuous places. Also, there are some cases where the platforms would like to show different products to different users based on the collected user behaviors.","tags":null,"title":"SOFABoot dynamic module practice","type":"guides","url":"/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","wordcount":630},{"author":null,"categories":null,"content":" SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nYou can view all the release notes in Release History. The correspondence between SOFABoot version and Spring Boot version is as follows:\n SOFABoot version Spring Boot version 2.3.x 1.4.2.RELEASE 2.4.x 1.4.2.RELEASE 2.5.x 1.5.16.RELEASE 3.0.x 2.0.3.RELEASE 3.1.0 2.1.0.RELEASE That is, the SOFABoot 2.3.x and 2.4.x series are based on Spring Boot 1.4.2.RELEASE; SOFABoot 2.5.x series are based on Spring Boot 1.5.x; SOFABoot 3.x series are based on Spring Boot 2.x. You can view and get the codes of all revisions in Release History. In addition, to facilitate users in the community to learn the latest development version of SOFABoot, we will release the SNAPSHOT version, which is a branch of the current development. To successfully pull the SNAPSHOT package from the central repository, it\u0026amp;rsquo;s necessary to add the following profile configuration to the local maven setting.xml file:\n\u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; Feature Description Based on Spring Boot, SOFABoot provides the following capabilities:\n Capability of expanding the Health Check of Spring Boot: Provide the Readiness Check based on the Health Check of Spring Boot, to ensure a secure launch of application examples. Capability of log space isolation: The middleware framework automatically finds the application\u0026amp;rsquo;s logs and realizes dependence on the logs and independent log printing, avoiding binding the middleware and the application logs. The capability is achieved through sofa-common-tools. Capability of providing class isolation: Provide class isolation based on the SOFAArk framework, making it easy for users to solve various class conflicts. Capability of providing modular development: Based on the Spring context isolation, provide modular development capability, with a separate Spring context for each SOFABoot module, to avoid BeanId conflicts between different SOFABoot modules. Integrated management of middleware: manage in a unified manner, provide a unified and easy-to-use …","date":-62135596800,"description":"","dir":"projects/sofa-boot/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fe6aed461c61b86dfed846a2dc0b7dcb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/overview/","summary":"SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nYou can view all the release notes in Release History. The correspondence between SOFABoot version and Spring Boot version is as follows:","tags":null,"title":"SOFABoot overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/overview/","wordcount":461},{"author":null,"categories":null,"content":" Since 3.1.X Spring framework has started to support the profile function: Bean Definition Profiles, SOFABoot support modular-level profiling, it will determine whether a module can be started when each module is getting started.\nActivating Module Using Module-Profile To enable the SOFABoot profiling, we need to add the com.alipay.sofa.boot.active-profiles field in the application.properties file. The value of this field is a comma-separated string denoting a list of profiles allowed to be activated. After specifying it, SOFABoot will specify a profile list represented by the field for each module that can be activated.\nThe sofa-module.properties file of the SOFABoot module supports the Module-Profile field, which points to a comma-separated string of values representing which profiles are allowed to be activated. Module-Profile supports the inversion operation, !dev indicates that com.alipay.sofa.boot.active-profiles is activated when it does not contain dev.\nIf the value of the com.alipay.sofa.boot.active-profiles field is not specified in the application, all modules are allowed to be started. If the Module-Profile is not specified in the SOFABoot module, the current SOFABoot module can be started with any profile.\nExample Activating the dev SOFABoot Module Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev With this configuration, the module with dev profile will be activated.\nAdd the following configuration to each sofa-module.properties file where modules with dev profile need to be activated.\nModule-Profile=dev Configuring Multiple Activation Profiles Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev,test With this configuration, the modules with dev or test profile will be activated.\nAdd the following configuration to the SOFABoot\u0026amp;rsquo;s sofa-module.properties file:\nModule-Profile=test,product With this configuration, the module will be activated when the com.alipay.sofa.boot.active-profiles contains test or product. Since the com.alipay.sofa.boot.active-profiles is specified as dev and test, this module will be activated.\nThe Inverted Module-Profile Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev With this configuration, the module with dev profile will be activated.\nAdd the following configuration to the SOFABoot\u0026amp;rsquo;s sofa-module.properties file:\nModule-Profile=!product This will activate the module when the com.alipay.sofa.boot.active-profiles does not contain product. Since it is specified as dev, this module will be activated.\nSet the spring.profiles.active property that is used to activate the Spring context of the module. Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev,test With this configuration, the modules with dev or test profile will be activated. If a module meets those …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-profile/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b29d568fa057cad0b440790d5cc65d07","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","summary":"Since 3.1.X Spring framework has started to support the profile function: Bean Definition Profiles, SOFABoot support modular-level profiling, it will determine whether a module can be started when each module is getting started.\nActivating Module Using Module-Profile To enable the SOFABoot profiling, we need to add the com.alipay.sofa.boot.active-profiles field in the application.properties file. The value of this field is a comma-separated string denoting a list of profiles allowed to be activated.","tags":null,"title":"SOFABoot profile","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","wordcount":450},{"author":null,"categories":null,"content":" SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n你可以在发布历史中查看所有的发布报告，SOFABoot 版本和 Spring Boot 版本对应关系如下：\n SOFABoot 版本 Spring Boot 版本 3.3.0～3.3.1 2.1.11.RELEASE 3.3.2～3.6.0 2.1.13.RELEASE 3.7.0～3.10.0 2.3.9.RELEASE 3.11.0～3.11.1 2.3.12.RELEASE 3.12.0～3.13.0 2.4.13 3.14.0～3.14.1 2.6.9 3.15.0～3.16.3 2.7.3 3.17.0 2.7.8 3.18.0～3.19.1 2.7.10 4.0.0 ～ 4.0.2 3.0.7 4.1.0 3.1.5 4.2.0 3.2.2 4.3.0 3.2.6 SOFABoot 3.x 系列版本将构建在 Spring Boot 2.x 基础之上，SOFABoot 4.x 系列版本将构建在 Spring Boot 3.x 基础之上 。你可以在发布历史中查看获取所有的历史版本代码。另外为了方便社区同学能够基于最新开发版本的 SOFABoot 进行开发学习，我们会发布当前开发分支的 SNAPSHOT 版本。为顺利从中央仓库拉取 SNAPSHOT 包，需要在本地 maven setting.xml 文件增加如下 profile 配置:\n\u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; 目前 SOFABoot 最新版本为 4.0.0，基于 Spring Boot 3.0.7, 支持 JDK17。\n功能描述 SOFABoot 在 Spring Boot 基础上，提供了以下能力：\n 扩展 Spring Boot 健康检查的能力：在 Spring Boot 健康检查能力基础上，提供了 Readiness Check 的能力，保证应用实例安全上线。 提供模块化开发的能力：基于 Spring 上下文隔离提供模块化开发能力，每个 SOFABoot 模块使用独立的 Spring 上下文，避免不同 SOFABoot 模块间的 BeanId 冲突。 增加模块并行加载和 Spring Bean 异步初始化能力，加速应用启动； 增加日志空间隔离的能力：中间件框架自动发现应用的日志实现依赖并独立打印日志，避免中间件和应用日志实现绑定，通过 sofa-common-tools 实现。 增加类隔离的能力：基于 SOFAArk 框架提供类隔离能力，方便使用者解决各种类冲突问题。 增加中间件集成管理的能力：统一管控、提供中间件统一易用的编程接口、每一个 SOFA 中间件都是独立可插拔的组件。 提供完全兼容 Spring Boot的能力：SOFABoot 基于 Spring Boot 的基础上进行构建，并且完全兼容 Spring Boot。 应用场景 SOFABoot 本身就脱胎于蚂蚁金服内部对于 Spring Boot 的实践，补充了 Spring Boot 在大规模金融级生产场景下一些不足的地方，所以 SOFABoot 特别适合于这样的场景。\n当然，SOFABoot 的每个组件都是可选的，用户可以灵活选择其中的功能来使用，比如如果仅仅想在 Spring Boot 下面引入 SOFA 中间件，可以不需引入 SOFABoot 中的类隔离能力。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/overview/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fe6aed461c61b86dfed846a2dc0b7dcb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/overview/","summary":"SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABo","tags":null,"title":"SOFABoot 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-boot/overview/","wordcount":938},{"author":null,"categories":null,"content":" SOFABoot 提供了类隔离框架 SOFAArk, 弥补了 Spring Boot 在类隔离能力上的缺失，用以解决在实际开发中常见的类冲突、包冲突问题，详细请参考 SOFAArk。\n在 SOFABoot 工程中使用类隔离能力，只需两步操作；配置 sofa-ark-maven-plugin 打包插件以及引入 sofa-ark-springboot-starter 类隔离框架依赖；\n配置 Maven 打包插件 官方提供了 Maven 插件 - sofa-ark-maven-plugin ，只需要简单的配置项，即可将 SpringBoot 工程打包成标准格式规范的可执行 Ark 包，插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 配置模板如下：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- all class exported by ark plugin would be resolved by ark biz in default, if configure denyImportClasses, then it would prefer to load them by ark biz itself --\u0026amp;gt; \u0026amp;lt;denyImportClasses\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass1\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass2\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/denyImportClasses\u0026amp;gt; \u0026amp;lt;!-- Corresponding to denyImportClasses, denyImportPackages is package-level --\u0026amp;gt; \u0026amp;lt;denyImportPackages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/denyImportPackages\u0026amp;gt; \u0026amp;lt;!-- denyImportResources can prevent resource exported by ark plugin with accurate name to be resolved --\u0026amp;gt; \u0026amp;lt;denyImportResources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test1.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test2.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;/denyImportResources\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 插件配置项解释：\n outputDirectory: 执行 mvn package 命令后，指定打出来的 ark 包存放目录，默认存放至 ${project.build.directory} arkClassifier: 执行 mvn depleoy 命令后，指定发布到仓库的 ark 包的maven坐标的 classifer 值, 默认为空；我们推荐配置此配置项用于和普通的 Fat Jar 加以名字上区别； denyImportClasses: 默认情况下，应用会优先加载 ark plugin 导出的类，使用该配置项，可以禁止应用从 ark plugin 加载其导出类； denyImportPackages: 对应上述的 denyImportClasses, 提供包级别的禁止导入； denyImportResources: 默认情况下，应用会优先加载 ark plugin 导出的资源，使用该配置项，可以禁止应用从 ark plugin 加载其导出资源； 添加类隔离框架依赖 在实际开发中，为了在跑测试用例时使用 SOFABoot 类隔离能力，需要在 SOFABoot 工程中添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 根据 SpringBoot 依赖即服务的原则，添加该依赖之后，应用启动之前，会优先启动 SOFABoot 类隔离容器；\nSOFABoot 的类隔离框架会自动检测应用中是否有引入 Ark Plugin（即需要被隔离的jar包，详情请参考 SOFAArk）, 并隔离加载；例如为了避免 SOFABoot 官方提供的 SOFARPC 组件和应用产生依赖冲突，SOFABoot提供了 SOFARPC 组件对应的 ark plugin 版，用户如果需要隔离 SOFARPC，只需要添加如下组件：\n\u0026amp;lt;dependency\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/classloader-isolation/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e007416ab008c1dd4b886433dbf8af01","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/classloader-isolation/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/classloader-isolation/","summary":"SOFABoot 提供了类隔离框架 SOFAArk, 弥补了 Spring Boot 在类隔离能力上的缺失，用以解决在实际开发中常见的类冲突、包冲突问题，详细请参考 SOFAArk。 在 SOFABoot 工程中使用类","tags":null,"title":"SOFABoot 使用类隔离","type":"projects","url":"/sofastack.tech/projects/sofa-boot/classloader-isolation/","wordcount":1667},{"author":null,"categories":null,"content":" SOFABoot 动态模块实践 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n 实验背景 实验内容 任务 任务准备 将 SOFABoot 应用打包成 ark 包 修改动态模块名称 配置动态模块的打包插件 构建宿主应用 引入动态模块依赖 宿主应用配置 打包 \u0026amp;amp; 启动宿主应用 SOFADashboard 添加版本\u0026amp;amp;管理应用 查看详情 \u0026amp;amp; 推送安装命令 实验背景 kc-sofastack-demo 分享中已经通过 SOFAStack 快速构建了一个电商微服务应用， 并且完成了对应用服务调用链路的跟踪及应用状态的监控。\n在电商系统中，平台方往往不会满足商品的自然排序展示，必定会根据某种规则来将部分商品放置在列表最瞩目的地方， 当然也可能是平台方通过收集用户行为动态的为每个不同的用户推荐不同的商品展示列表。\n本实验背景就是基于kc-sofastack-demo的基础上， 根据现场同学对每个商品的购买总数（通过订单统计）来对商品列表进行动态排序。\n实验内容 通过 SOFABoot 提供的动态模块能力及 SOFADashboard 的动态模块管控能力，实现商品列表排序策略的动态变更。通过在不重启宿主机，不更改应用配置的情况下实现 应用行为的改变。\n 项目工程架构图如下 任务 1、任务准备 从 github 上将 demo 工程克隆到本地\ngit clone https://github.com/sofastack-guides/kc-sofastack-dynamic-demo.git 然后将工程导入到 IDEA 或者 eclipse。\n2、将 SOFABoot 应用打包成 ark 包 step1 : 修改动态模块名称 在实际的应用场景中，不需要对其进行任何修改\n 如下图所示，对 dynamic-module/pom.xml 中的 artifactId 进行修改，将 {your-number} 修改为当前座位上的编号\nstep2 : 配置动态模块的打包插件 在 dynamic-provider/pom.xml 中，增加 ark 打包插件，并进行配置：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!--ark-biz 包的打包配置 --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- ark-biz 包的启动优先级，值越小，优先级越高--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;200\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--设置应用的根目录，用于读取 ${base.dir}/conf/ark/bootstrap.application 配置文件，默认为 ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;../\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 3、构建宿主应用 在已下载下来的工程中，dynamic-stock-mng 作为实验的宿主应用工程模型。通过此任务，将 dynamic-stock-mng 构建成为动态模块的宿主应用。\nstep1 : 引入动态模块依赖 动态模块是通过 SOFAArk 组件来实现的，因此次数需要引入 SOFAArk 相关的依赖即可。关于 SOFAArk 可以参考SOFABoot 类隔离 一节进行了解。\n SOFAArk 相关依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;web-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;config-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.sofastack\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dynamic-provider-{your-number}\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 将此配置文件中的 {your-number} 替换为当前座位编号\n 宿主应用打包插件 \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; …","date":-62135596800,"description":"本指南将基于 SOFADashboard 的 ARK 管控能力来实现 SOFAArk 提供的合并部署和动态模块推送的功能。","dir":"guides/kc-sofastack-dynamic-demo/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8bfd4a50e21ce9fc867b1cf18a8c9af3","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-sofastack-dynamic-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/guides/kc-sofastack-dynamic-demo/","summary":"SOFABoot 动态模块实践 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 实验背景 实验内容 任务 任务准备 将 SOFABoot 应用打包成 ark 包 修改动态模","tags":null,"title":"SOFABoot 动态模块实践","type":"guides","url":"/sofastack.tech/guides/kc-sofastack-dynamic-demo/","wordcount":2025},{"author":null,"categories":null,"content":" SOFABoot 支持模块化隔离，在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项目，并在上面扩展，与 Spring 融合，提供扩展点的能力。\n使用 在 SOFABoot 中使用扩展点能力，需要以下三个步骤：\n定义提供扩展能力的 bean 在使用 SOFABoot 扩展点能力时，首先需要定一个需要被扩展的 bean，先定一个接口：\npackage com.alipay.sofa.boot.test; public interface IExtension { String say(); } 定义这个接口的实现：\npackage com.alipay.sofa.boot.test.impl; public class ExtensionImpl implements IExtension { private String word; @Override public String say() { return word; } public void setWord(String word) { this.word = word; } public void registerExtension(Extension extension) throws Exception { Object[] contributions = extension.getContributions(); String extensionPoint = extension.getExtensionPoint(); if (contributions == null) { return; } for (Object contribution : contributions) { if (\u0026amp;quot;word\u0026amp;quot;.equals(extensionPoint)) { setWord(((ExtensionDescriptor) contribution).getValue()); } } } } 在这里可以看到有一个方法：registerExtension ，暂时可以先不用管这个方法，后续会介绍其具体的作用。\n在模块的 Spring 配置文件中，我们把这个 bean 给配置起来：\n\u0026amp;lt;bean id=\u0026amp;quot;extension\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.test.impl.ExtensionImpl\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;word\u0026amp;quot; value=\u0026amp;quot;Hello, world\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; 定义扩展点 在上面的 bean 中有一个字段 word ，在实际中，我们希望这个字段能够被其他的模块自定义进行覆盖，这里我们将其以扩展点的形式暴露出来。\n首先需要一个类去描述这个扩展点：\n@XObject(\u0026amp;quot;word\u0026amp;quot;) public class ExtensionDescriptor { @XNode(\u0026amp;quot;value\u0026amp;quot;) private String value; public String getValue() { return value; } } 然后在 xml 中定义扩展点：\n\u0026amp;lt;sofa:extension-point name=\u0026amp;quot;word\u0026amp;quot; ref=\u0026amp;quot;extension\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:object class=\u0026amp;quot;com.alipay.sofa.boot.test.extension.ExtensionDescriptor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:extension-point\u0026amp;gt; 其中： - name 为扩展点的名字 - ref 为扩展点所作用在的 bean - object 为扩展点的贡献点具体的描述，这个描述是通过 XMap 的方式来进行的(XMap 的作用是将 Java 对象和 XML 文件进行映射，这里建议通过在网上搜索下 XMap 的文档来了解 XMap)\n定义扩展 上述已经将扩展点定义好了，此时我们就可以对这个 bean 进行扩展了:\n\u0026amp;lt;sofa:extension bean=\u0026amp;quot;extension\u0026amp;quot; point=\u0026amp;quot;word\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:content\u0026amp;gt; \u0026amp;lt;word\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;newValue\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/word\u0026amp;gt; \u0026amp;lt;/sofa:content\u0026amp;gt; \u0026amp;lt;/sofa:extension\u0026amp;gt; 其中： - bean 为扩展所作用在的 bean - point 为扩展点的名字 - content 里面的内容为扩展的定义，其会通过 XMap 将内容解析为：扩展点的贡献点具体的描述对象，在这里即为 com.alipay.sofa.boot.test.extension.ExtensionDescriptor 对象\n到这里，我们可以回头看一开始在 com.alipay.sofa.boot.test.impl.ExtensionImpl 中定义的 registerExtension 方法了，SOFABoot 在解析到贡献点时，会调用被扩展 bean 的 registerExtension 方法，其中包含了用户定义的贡献点处理逻辑，在上述的例子中，获取用户定义的 value 值，并将其设置到 word 字段中覆盖 bean 中原始定义的值。\n此时，调用 extension bean 的 say() 方法，可以看到返回扩展中定义的值: newValue 。\nXMap 支持和扩展 上述的例子中只是一个很简单的扩展，其实 XMap 包含了非常丰富的描述能力，包括 List, Map 等，这些可以通过查看 XMap 的文档来了解。\n在 SOFABoot 中，除了 XMap 原生的支持以外，还扩展了跟 Spring 集成的能力： - 通过 XNode 扩展出了 XNodeSpring - 通过 XNodeList 扩展出了 XNodeListSpring - 通过 XNodeMap 扩展出了 XNodeMapSpring\n这部分的扩展能力，让扩展点的能力更加丰富，描述对象中可以直接指向一个 SpringBean(用户配置 bean 的名字，SOFABoot 会根据名字从 spring 上下文中获取到 bean)，这里举一个使用 XNodeListSpring 的例子，依然是上述描述的三个步骤：\n定义提供扩展能力的 bean 接口定义：\n在这个接口里，返回一个 list，目标是这个 list 能够被通过扩展的方式填充\npackage com.alipay.sofa.boot.test; public interface IExtension { …","date":-62135596800,"description":"","dir":"projects/sofa-boot/extension/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"93225b6c1f2b68f2047a7cf49b76650b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/extension/","summary":"SOFABoot 支持模块化隔离，在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项","tags":null,"title":"SOFABoot 拓展点","type":"projects","url":"/sofastack.tech/projects/sofa-boot/extension/","wordcount":1959},{"author":null,"categories":null,"content":" 本文档将演示了如何在 SOFABoot 环境下应用 SOFARPC 进行服务的发布和引用。 您可以直接在工程下找到本文档的示例代码。注意，示例代码中需要本地安装 zookeeper 环境，如果没有安装。需要将application.properties中的com.alipay.sofa.rpc.registry.address 配置注释掉，走本地文件注册中心的方式。\n创建工程 环境准备：SOFABoot 需要 JDK7 或者 JDK8 ，需要采用 Apache Maven 2.2.5 或者以上的版本来编译。 工程构建：SOFABoot 构建在 Spring Boot 之上。因此可以使用 Spring\u0026amp;nbsp;Boot\u0026amp;nbsp;的工程生成工具来生成一个标准的Spring Boot 工程。 引入 SOFABoot 环境：生成的 Spring Boot 标准工程直接使用的 Spring Boot 的 parent 依赖，改为 SOFABoot 提供的 parent 依赖，该parent 提供并管控了多种 SOFABoot 提供的 starter。 \u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa-boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa-boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n 配置 application.properties ：application.properties 是 SOFABoot 工程中的配置文件。这里需要配置一个必不可少的配置项，即应用名。 spring.application.name=AppName 引入 RPC Starter： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 定义服务接口 public interface AnnotationService { String sayAnnotation(String string); } 服务端发布服务 通过 @SofaService注解发布服务，如下代码所示：\nSOFABoot 扫描到该注解，就会将该服务实现发布到服务器，同时指定了 bolt 协议与客户端进行通信地址，并将地址等元数据发布到了注册中心（这里默认使用的本地文件作为注册中心）。\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } 客户端引用服务 通过@SofaReference注解引用服务，如下代码所示： SOFABoot 会生成一个 AnnotationService RPC 的代理 bean，同时指定了 bolt 协议与服务端通信。这样就可以直接在代码中使用该 bean 进行远程服务的调用了。\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } 运行 在 SpringBoot 的启动类中编码如下： 启动服务端\n@SpringBootApplication public class AnnotationServerApplication { public static void main(String[] args) { SpringApplication springApplication = new SpringApplication( AnnotationServerApplication.class); ApplicationContext applicationContext = springApplication.run(args); } } 启动客户端，获取AnnotationClientImpl的实现 bean，并调用 sayClientAnnotation，间接通过@SofaReference生成的代理类调用远程服务 AnnotationServiceImpl。\npublic class …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-sofa-boot/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0dd5e0e5116473aee630cba38679d493","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","summary":"本文档将演示了如何在 SOFABoot 环境下应用 SOFARPC 进行服务的发布和引用。 您可以直接在工程下找到本文档的示例代码。注意，示例代码中需要本地安装 zookeeper 环境，如果没有","tags":null,"title":"SOFABoot 方式快速入门","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","wordcount":990},{"author":null,"categories":null,"content":"声明 SOFABoot 的 xsd 文件：在要使用的 XML 配置文件中将头部 xsd 文件的声明设置为如下。这样就能够使用 SOFABoot 定义的 XML 元素进行开发。\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xmlns:context=\u0026amp;quot;http://www.springframework.org/schema/context\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; 在xml方式中发布和引用服务的方式如下。 sofa:service 元素表示发布服务， sofa:reference 元素表示引用服务。 sofa:binding 表示服务发布或引用的协议。\n\u0026amp;lt;bean id=\u0026amp;quot;personServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 一个服务也可以通过多种协议进行发布，如下：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 服务引用\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 也可以是其他的协议\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceRest\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-xml/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9192a93415bee3070a9be62c0f693949","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","summary":"声明 SOFABoot 的 xsd 文件：在要使用的 XML 配置文件中将头部 xsd 文件的声明设置为如下。这样就能够使用 SOFABoot 定义的 XML 元素进行开发。 \u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;beans xmlns=\u0026quot;http://www.springframework.org/schema/beans\u0026quot; xmlns:xsi=\u0026quot;http://www.w3.org/2001/XMLSchema-instance\u0026quot; xmlns:sofa=\u0026quot;http://sofastack.io/schema/sofaboot\u0026quot; xmlns:context=\u0026quot;http://www.springframework.org/schema/context\u0026quot; xsi:schemaLocation=\u0026quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026quot; default-autowire=\u0026quot;byName\u0026quot;\u0026gt; 在xml","tags":null,"title":"SOFABoot 环境 XML 配置使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","wordcount":179},{"author":null,"categories":null,"content":"SOFABoot 为 RPC 服务的发布和引用提供了一套编程 API 方式，方便直接在代码中发布和引用 RPC 服务，与 Spring 的 ApplicationContextAware 类似，为使用编程 API 方式，首先需要实现 ClientFactoryAware 接口获取编程组件 API：\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } 以 DirectService 为例，看下如何使用 clientFactory 通过编程 API 方式发布 RPC 服务：\nServiceClient serviceClient = clientFactory.getClient(ServiceClient.class); ServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(DirectService.class); serviceParam.setInstance(new DirectServiceImpl()); List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); serviceClient.service(serviceParam); 上面的代码中\n 首先通过 clientFactory 获得 ServiceClient 对象 然后构造 ServiceParam 对象，ServiceParam 对象包含发布服务所需参数，通过 setInstance 方法来设置需要被发布成 RPC 服务的对象，setInterfaceType 来设置服务的接口 最后，调用 ServiceClient 的 service 方法，发布一个 RPC 服务 通过编程 API 方式引用 RPC 服务的代码也是类似的：\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt;(); referenceParam.setInterfaceType(DirectService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); DirectService proxy = referenceClient.reference(referenceParam); proxy.sayDirect(\u0026amp;quot;hello\u0026amp;quot;); 同样，引用一个 RPC 服务只需从 ClientFactory 中获取一个 ReferenceClient ，然后和发布一个服务类似，构造出一个 ReferenceParam，然后设置好服务的接口，最后调用 ReferenceClient 的 reference 方法即可。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-api/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2679388dc3459714f869d8f8a71739d7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","summary":"SOFABoot 为 RPC 服务的发布和引用提供了一套编程 API 方式，方便直接在代码中发布和引用 RPC 服务，与 Spring 的 ApplicationContextAware 类似，为使用编程 API 方式，首先需要实现 ClientFactoryAware 接口获取编程组件","tags":null,"title":"SOFABoot 环境动态 API 使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","wordcount":374},{"author":null,"categories":null,"content":" 这部分介绍在 SOFABoot 环境下,完整的 SOFARPC 服务发布与引用说明\n发布服务 \u0026amp;lt;bean id=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; thread-pool-ref=\u0026amp;quot;\u0026amp;quot; warm-up-time=\u0026amp;quot;60000\u0026amp;quot; warm-up-weight=\u0026amp;quot;10\u0026amp;quot; weight=\u0026amp;quot;100\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 属性 名称 默认值 备注 id ID bean名 class 类 无 ref 服务接口实现类 interface 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 unique-id 服务标签（唯一标识元素） filter 过滤器配置别名 多个用逗号隔开 registry 服务端注册中心 逗号分隔 timeout 服务端执行超时时间 serialize-type 序列化协议 hessian2,protobuf thread-pool-ref 服务端当前接口使用的线程池 无 weight 服务静态权重 warm-up-weight 服务预热权重 warm-up-time 服务预热时间 单位毫秒 引用服务 \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;helloSyncServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;sync\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; address-wait-time=\u0026amp;quot;1000\u0026amp;quot; connect.num=\u0026amp;quot;1\u0026amp;quot; check=\u0026amp;quot;false\u0026amp;quot; connect.timeout=\u0026amp;quot;1000\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; generic-interface=\u0026amp;quot;\u0026amp;quot; idle.timeout=\u0026amp;quot;1000\u0026amp;quot; idle.timeout.read=\u0026amp;quot;1000\u0026amp;quot; lazy=\u0026amp;quot;false\u0026amp;quot; loadBalancer=\u0026amp;quot;\u0026amp;quot; registry=\u0026amp;quot;\u0026amp;quot; retries=\u0026amp;quot;1\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;xxx:12200\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; type=\u0026amp;quot;sync\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 属性 名称 默认值 备注 id ID 自动生成 jvm-first 是否优先本地 true interface 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 unique-id 服务标签（唯一标识元素） type 调用方式 sync callback,sync,future,oneway filter 过滤器配置别名 List registry 服务端注册中心 List method 方法级配置 说明同上 serialize-type 序列化协议 hessian2 target-url 直连地址 直连后register generic-interface 泛化接口 connect.timeout 建立连接超时时间 3000(cover 5000) connect.num 连接数 1 idle.timeout 空闲超时时间 idle.timeout.read 读空闲超时时间 loadBalancer 负载均衡算法 random lazy 是否延迟建立长连接 false address-wait-time 等待地址获取时间 -1 取决于实现，可能不生效。 timeout 调用超时时间 3000(cover 5000) retries 失败后重试次数 0 跟集群模式有关，failover读取此参数。 callback-class callback 回调类 无 callback 才可用 callback-ref callback 回调类 无 callback 才可用 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/rpc-config-xml-explain/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4b5110e9eb6cf6c6f287aef0fd210047","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","summary":"这部分介绍在 SOFABoot 环境下,完整的 SOFARPC 服务发布与引用说明 发布服务 \u0026lt;bean id=\u0026quot;helloSyncServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;helloSyncServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026quot; unique-id=\u0026quot;\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs registry=\u0026quot;\u0026quot; serialize-type=\u0026quot;\u0026quot; filter=\u0026quot;\u0026quot; timeout=\u0026quot;3000\u0026quot; thread-pool-ref=\u0026quot;\u0026quot; warm-up-time=\u0026quot;60000\u0026quot; warm-up-weight=\u0026quot;10\u0026quot; weight=\u0026quot;100\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;sofa:binding.rest\u0026gt; \u0026lt;/sofa:binding.rest\u0026gt; \u0026lt;/sofa:service\u0026gt; 属性 名称 默认值 备注 id ID bean名 class 类 无 ref 服","tags":null,"title":"SOFABoot 环境发布订阅说明","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","wordcount":518},{"author":null,"categories":null,"content":" 注解服务发布与服务引用 除了常规的 xml 方式发布服务外，我们也支持在SOFABoot 环境下，注解方式的发布与引用，同 xml 类似，我们有 @SofaService 和 @SofaReference，同时对于多协议，存在@SofaServiceBinding 和 @SofaReferenceBinding 注解。\n服务发布 如果要发布一个 RPC 服务。我们只需要在 Bean 上面打上@SofaService注解。指定接口和协议类型即可。\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } 服务引用 对于需要引用远程服务的 bean, 只需要在属性，或者方法上，打上@SofaReference的注解即可，支持 bolt, dubbo, rest 协议。\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } 使用演示 可以在 sample 工程目录的 annotation 子项目中进行验证测试。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-annotation/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2c3afd33cbce4f5aa2473716b3afe5a6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","summary":"注解服务发布与服务引用 除了常规的 xml 方式发布服务外，我们也支持在SOFABoot 环境下，注解方式的发布与引用，同 xml 类似，我们有 @SofaService 和 @SofaR","tags":null,"title":"SOFABoot 环境注解使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","wordcount":317},{"author":null,"categories":null,"content":" SOFADashboard is designed to implement unified management over SOFA framework components, including service governance and SOFAArk control. All technology stacks used by SOFADashboard are developed and constructed based on open-source community products, such as Ant Design Pro, SOFABoot, Spring, and MyBatis.\nCurrently, service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper. Therefore, you need to ensure the ZooKeeper service is available when you decide to use SOFADashboard. You also need to ensure that MySQL is available, because SOFAArk control and deployment uses MySQL for resource data storage.\nArchitecture Currently, service governance and SOFAArk control of SOFADashboard are implemented upon ZooKeeper-based programming.\n SOFADashboard backend corresponds to the sofa-dashboard-backend project. It is the server end project of SOFADashboard, responsible for data interaction between ZooKeeper and MySQL and for providing the rest API to the SOFADashboard frontend. SOFADashboard frontend corresponds to the sofa-dashboard-frontend project. It is the frontend project of SOFADashboard. It provides UIs for interaction with users. Application rpc provider: service provider of SOFARPC, which registers services with ZooKeeper. rpc consumer: service consumer of SOFARPC, which subscribes to services on ZooKeeper. client: SOFADashboard client, which is available upon the installation of the sofa-dashboard-client package. Currently, the SOFADashboard client only supports registration of health-check status and port information of applications with ZooKeeper. Later on, it will evolve into SOFABoot client, and report more diversified application data. ark-biz host app: see SOFAArk. ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f0664d0ca7fc1fa87e67847525081993","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/overview/","summary":"SOFADashboard is designed to implement unified management over SOFA framework components, including service governance and SOFAArk control. All technology stacks used by SOFADashboard are developed and constructed based on open-source community products, such as Ant Design Pro, SOFABoot, Spring, and MyBatis.\nCurrently, service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper. Therefore, you need to ensure the ZooKeeper service is available when you decide to use SOFADashboard. You also need to ensure that MySQL is available, because SOFAArk control and deployment uses MySQL for resource data storage.","tags":null,"title":"SOFADashboard overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/overview/","wordcount":230},{"author":null,"categories":null,"content":" SOFADashboard 致力于对 SOFA 框架中组件进行统一管理，包括服务治理、SOFAArk 管控等。SOFADashboard 本身所用技术栈均基于开源社区产品来开发构建，包括：Ant Design Pro、SOFABoot、Spring、MyBatis 等。\n目前，SOFADashboard 中的服务治理、SOFAArk 管控等需要依赖于 Zookeeper，因此如果您需要使用 SOFADashboard 那么请确保 Zookeeper 服务可用；另外 SOFAArk 管控部署需要依赖 MySQL 进行资源数据存储，因此也需要保证 MySQL 可以正常使用。\n架构简图 SOFADashboard 目前服务治理与 SOFAArk 管控都是面向 Zookeeper 来编程实现的。\n SOFADashboard backend : 对应 sofa-dashboard-backend 工程，是 SOFADashboard 的服务端工程，负责与 Zookeeper 和 MySQL 进行数据交互，并且为 SOFADashboard frontend 提供 rest 接口。 SOFADashboard frontend : 对应 sofa-dashboard-frontend 工程，是 SOFADashboard 的前端工程，用于提供与用户交互的 UI 界面。 app 应用 rpc provider : SOFARPC 的服务提供方，会将服务注册到 Zookeeper 上。 rpc consumer : SOFARPC 的服务消费方，会从 Zookeeper 上订阅服务。 client : SOFADashboard 客户端，引入 sofa-dashboard-client 包即可。目前仅提供将应用的健康检查状态及端口信息注册到 Zookeeper ，后面将会演化成 SOFABoot client，上报更丰富的应用数据。 ark-biz 宿主应用: 参考 SOFAArk 。 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f0664d0ca7fc1fa87e67847525081993","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/overview/","summary":"SOFADashboard 致力于对 SOFA 框架中组件进行统一管理，包括服务治理、SOFAArk 管控等。SOFADashboard 本身所用技术栈均基于开源社区产品来开发构建","tags":null,"title":"SOFADashboard 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/overview/","wordcount":431},{"author":null,"categories":null,"content":" This topic is a part of the Braft document. To read the Braft document, click here. The Raft algorithm and its application are comprehensively described in the Braft document. As JRaft is designed on the basis of Braft, we strongly recommend that you read the Braft document first to understand the basic principles and application of the Raft algorithm.\nDistributed consensus Distributed consensus is a very fundamental problem in a distributed system. Simply put, it is about how to reach a consensus on a specific value among multiple servers, and ensure that the decision is not overthrown regardless of what failures may occur on these servers. Assume that, all processes of a distributed system needs to determine a value V. If the system has the following properties, we consider it solves the problem of distributed consensus:\n Termination: All normal processes will determine the specific value of V, and there is no process that keeps running in a loop. Validity: A value V\u0026amp;rsquo; determined by normal processes must have been proposed by one of them. For example, a random number generator does not have this property. Agreement: All normal processes choose the same value. Consensus state machine Assume we have an infinitely incrementing sequence (system) a[1, 2, 3…]. If for any integer i, the value of a[i] meets the distributed consensus requirement, the system meets the requirement of a consensus state machine. Basically, all systems are subject to continuous operations, and reaching consensus on a single value is definitely not enough. To make sure all replicas of a real-life system are consistent, we usually convert the operations into entries of a write-ahead-log(WAL). Then, we make sure all replicas of the system reach a consensus on the WAL entries, so that each process will perform operations corresponding to the WAL entries in order. As a result, the replicas are in consistent states.\nRAFT RAFT is a new and easy-to-understand distributed consensus replication protocol proposed by Diego Ongaro and John Ousterhout of Stanford University as a central coordination component of the RAMCloudproject. Raft is a leader-based multi-Paxos variant that provides a more complete and straightforward protocol description than existing protocols such as Paxos, Zab, and Viewstamped Replication. It also provides a clear description for adding and deleting nodes. In Raft, replicated state machines are the most important and fundamental to distributed systems. Raft allows commands to be replicated and executed in order, and ensures that the states of nodes remain consistent when their initial states are the same. A system is fully functional (available) as long as a majority of nodes function properly. It allows non-Byzantine conditions, including network delays, packet loss, and reordering, but does not allow tampering with any messages.\nRaft can solve the distributed consensus and partitioning problems, but cannot solve the availability problem. Raft covers …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/overview/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"eff7088d010aefabdffa2858e88d76c0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/overview/","summary":"This topic is a part of the Braft document. To read the Braft document, click here. The Raft algorithm and its application are comprehensively described in the Braft document. As JRaft is designed on the basis of Braft, we strongly recommend that you read the Braft document first to understand the basic principles and application of the Raft algorithm.\nDistributed consensus Distributed consensus is a very fundamental problem in a distributed system.","tags":null,"title":"SOFAJRaft overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/overview/","wordcount":645},{"author":null,"categories":null,"content":" 本介绍内容来自 braft 文档，原文链接请参见这里。braft 的关于算法和应用本身的文档非常优秀，由于 jraft 脱胎自 braft，我们强烈推荐阅读上述文档以了解 raft 算法的基本原理和应用。\n分布式一致性 分布式一致性 (distributed consensus) 是分布式系统中最基本的问题，用来保证一个分布式系统的可靠性以及容灾能力。简单的来讲，就是如何在多个机器间对某一个值达成一致, 并且当达成一致之后，无论之后这些机器间发生怎样的故障，这个值能保持不变。 抽象定义上， 一个分布式系统里的所有进程要确定一个值 v，如果这个系统满足如下几个性质， 就可以认为它解决了分布式一致性问题, 分别是:\n Termination: 所有正常的进程都会决定 v 具体的值，不会出现一直在循环的进程。 Validity: 任何正常的进程确定的值 v\u0026amp;rsquo;, 那么 v\u0026amp;rsquo; 肯定是某个进程提交的。比如随机数生成器就不满足这个性质。 Agreement: 所有正常的进程选择的值都是一样的。 一致性状态机 对于一个无限增长的序列 a[1, 2, 3…], 如果对于任意整数 i, a[i] 的值满足分布式一致性，这个系统就满足一致性状态机的要求。 基本上所有的系统都会有源源不断的操作, 这时候单独对某个特定的值达成一致是不够的。为了真实系统保证所有的副本的一致性，通常会把操作转化为 write-ahead-log(简称WAL)。然后让系统的所有副本对WAL保持一致，这样每个进程按照顺序执行WAL里的操作，就能保证最终的状态是一致的。\nRAFT RAFT 是一种新型易于理解的分布式一致性复制协议，由斯坦福大学的 Diego Ongaro 和 John Ousterhout 提出，作为 RAMCloud 项目中的中心协调组件。Raft 是一种 Leader-Based 的 Multi-Paxos 变种，相比 Paxos、Zab、View Stamped Replication 等协议提供了更完整更清晰的协议描述，并提供了清晰的节点增删描述。 Raft 作为复制状态机，是分布式系统中最核心最基础的组件，提供命令在多个节点之间有序复制和执行，当多个节点初始状态一致的时候，保证节点之间状态一致。系统只要多数节点存活就可以正常处理，它允许消息的延迟、丢弃和乱序，但是不允许消息的篡改（非拜占庭场景）。\nRaft 可以解决分布式理论中的 CP，即一致性和分区容忍性，并不能解决 Available 的问题。其中包含分布式系统中一些通常的功能：\n Leader Election Log Replication Membership Change Log Compaction RAFT 可以做什么 通过 RAFT 提供的一致性状态机，可以解决复制、修复、节点管理等问题，极大的简化当前分布式系统的设计与实现，让开发者只关注于业务逻辑，将其抽象实现成对应的状态机即可。基于这套框架，可以构建很多分布式应用：\n 分布式锁服务，比如 Zookeeper 分布式存储系统，比如分布式消息队列、分布式块系统、分布式文件系统、分布式表格系统等 高可靠元信息管理，比如各类 Master 模块的 HA JRAFT 一个纯 Java 的 Raft 算法实现库, 基于百度 braft 实现而来, 使用 Java 重写了所有功能, 支持:\n Leader election and priority-based semi-deterministic leader election. Replication and recovery. Snapshot and log compaction. Read-only member (learner). Membership management. Fully concurrent replication. Fault tolerance. Asymmetric network partition tolerance. Workaround when quorate peers are dead. Replication pipeline optimistic Linearizable read, ReadIndex/LeaseRead. 联系我们 更多讨论欢迎加入钉钉讨论群：44858463\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/overview/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"eff7088d010aefabdffa2858e88d76c0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-jraft/overview/","summary":"本介绍内容来自 braft 文档，原文链接请参见这里。braft 的关于算法和应用本身的文档非常优秀，由于 jraft 脱胎自 braft，我们强烈推荐阅读上述文档以了","tags":null,"title":"SOFAJRaft 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/overview/","wordcount":1132},{"author":null,"categories":null,"content":" SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\n1.客户端部分 SOFALookout Client 是一个 Java 的 SDK，可以帮助开发者在项目代码中进行 metrics 埋点。通过它也可以查看该 JAVA 应用的实时的状态信息。\n +------------------+ Reg: API: | dimension meters +--------+ +------------------+ | flatmap +---------------------------+ +-----------\u0026amp;gt; | Default/DropwizardMetrics| | +---------------------------+ | | http +--------------+ +-----------\u0026amp;gt; |Lookout server| | +--------------+ +----------------------+ | add common tags dimension EXTS: | JVM,OS,GC... +----+ +----------------------+ 2.服务器端服务 SOFALookout Server 可以帮助我们解决分布式环境下系统状态度量的问题，它提供丰富的协议接入支持，包括自有SDK（SOFALookout Client）上报协议，还支持 Prometheus 的数据协议（推模式和拉模式），Metricbeat 协议（版本是6），Opentsdb写入协议。 Lookout Server 兼容和增强了 Prometheus 的数据及元数据查询的 RESTful API。同样对应 PromQL 我们也基本实现了兼容和增强（不包括 Alert 相关语法）。\n2.1.Metrics 服务器端主要特性: 适配社区主要 Metrics 数据源协议写入（比如: Prometheus，Metricbeat等）； 数据的存储支持扩展，暂时开源版默认支持 Elasticsearch,并且透明和自动化了相关运维操作； 遵循 Prometheus 查询 API 的标准以及支持 PromQL，并进行了适当改进； 自带数据查询的控制台，并支持 Grafana 进行数据可视化； 使用简单，支持单一进程运行整个服务器端模块。 2.2.Metrics 服务器端工作机制: +----------------+ | Lookout Client +-----+ +----------------+ | +----------------+ | | Prometheus SDK +-----+ +-------------------+ +----------------------+ +------------------+ +-----------+ +----------------+ +--\u0026amp;gt; Lookout Gateway +---\u0026amp;gt; DB(ES/InfluxDB...) \u0026amp;lt;-----+ Lookout Server \u0026amp;lt;----+ Grafana | +----------------+ | +-------------------+ +----------------------+ +------------------+ +-----------+ | Metricbeat +-----+ +----------------+ | +----------------+ | | ... +-----+ +----------------+ ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/overview/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8a8a8ef02ca95d4d11e3e4b195bbae70","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/overview/","summary":"SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项","tags":null,"title":"SOFALookout 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/overview/","wordcount":602},{"author":null,"categories":null,"content":" 1.使用本机 ES 服务 1)本地启动 ES docker run -d --name es -p 9200:9200 -p 9300:9300 -e \u0026amp;quot;discovery.type=single-node\u0026amp;quot; elasticsearch:5.6 版本：V5，V6\n 2)检查 ES 是否健康 http://localhost:9200/_cat/health?v 3)启动 Lookout 服务 执行 all-in-one-bootstrap 编译后的 fat-jar 包，如何获得，见文末备注部分：\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -jar lookout-all-in-one-bootstrap-1.6.0-executable-ark.jar 注意 -Dcom.alipay.sofa.ark.master.biz=lookoutall 是必须的, 用于设置 sofa-ark 的 master biz。\n 4)最后进行功能验证\n 查询 （Gateway）的 metrics 作为功能验证，访问“localhost:9090”，在查询框输入：\njvm.memory.heap.used{app=\u0026amp;quot;gateway\u0026amp;quot;} 最后，也可以使用 grafana\n2.使用远程 ES 服务 总体步骤和“使用本机 ES 服务”类似，唯一不同的是，需要指定配置文件。\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -Dlookoutall.config-file=abc.properties \\ -jar lookout-all-in-one-bootstrap-1.6.0-executable-ark.jar -Dlookoutall.config-file（如果你本地启动 ES 测试的话则该配置项可以忽略！），该配置项制定的文件暂时只能引用文件系统上的 properties 文件(没有像 spring-boot 支持那么丰富），配置项必须以应用名开头，从而提供隔离能力。\n例如：在fat-jar同目录下创建一个abc.properties配置文件, 用于存放存放配置文件(下面列出了必须的配置项,用于指向使用的 ES 服务地址）：\ngateway.metrics.exporter.es.host=localhost gateway.metrics.exporter.es.port=9200 metrics-server.spring.data.jest.uri=http://localhost:9200 备注 如何获得 all-in-one-bootstrap 编译后的 fat-jar。\n方式1：本地编译\n./boot/all-in-one-bootstrap/build.sh 打包结果在boot/all-in-one-bootstrap/target/allinone-executable.jar\n 方式2：发布报告中附件获取\n临时方式（针对 1.6.0）暂时提供一个 v1.6.0的snapshot包，下载后（保证ES服务已经单独启动）运行：\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -jar lookout-all-1.6.0.snapshot.jar 方式3：使用docker镜像\n服务端默认会连接到 localhost:9200 的ES实例, 而我所用的开发机器是MacOS，无法使用 --net=host 模式启动容器，因此在容器内无法通过 localhost:9200 连接ES，需要使用如下方式绕过去：\n编辑一个配置文件，比如 foo.properties：\ngateway.metrics.exporter.es.host=es metrics-server.spring.data.jest.uri=http://es:9200 在 foo.properties 所在的目录下运行 all-in-one 镜像：\ndocker run -it \\ --name allinone \\ --link es:es \\ -p 7200:7200 \\ -p 9090:9090 \\ -v $PWD/foo.properties:/home/admin/deploy/foo.properties \\ -e JAVA_OPTS=\u0026amp;quot;-Dlookoutall.config-file=/home/admin/deploy/foo.properties\u0026amp;quot; \\ -e JAVA_OPTS=\u0026amp;quot;...定制JVM系统属性...\u0026amp;quot; \\ xzchaoo/lookout-allinone:1.6.0-SNAPSHOT 这里利用了docker的\u0026amp;ndash;link参数使得应用可以访问到ES实例 这里做测试用，所以不用-d参数在后台运行\n ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-metrics-server/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7c12565c66342c2f8e963cf1c1e26db5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","summary":"1.使用本机 ES 服务 1)本地启动 ES docker run -d --name es -p 9200:9200 -p 9300:9300 -e \u0026quot;discovery.type=single-node\u0026quot; elasticsearch:5.6 版本：V5，V6 2)检查 ES 是否健康 http://localhost:9200/_cat/health?v 3)启动 Lookout 服务 执行 all-in-one-bootstrap 编译后的 fat-jar 包，如何获得，见文","tags":null,"title":"SOFALookout 服务端快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","wordcount":808},{"author":null,"categories":null,"content":" This repository is deprecated. It will contribute to istio directly instead of developing in a forked repo. Please go to see Istio’s doc.\nSOFAMesh is a large-scale implementation scheme of Service Mesh based on Istio. On the basis of inheriting the powerful functions and rich features of Istio, in order to meet the performance requirements in large-scale deployments and to respond to the actual situation in the implementation, the following improvements are made:\n MOSN written in Golang instead of Envoy Merge Mixer to data plane to resolve performance bottlenecks Enhance Pilot for more flexible service discovery mechanism Added support for SOFA RPC, Dubbo The initial version was contributed by Ant Financial and Alibaba UC Business Unit.\nThe following figure shows the architectural differences between SOFAMesh and Istio:\nMain components MOSN In SOFAMesh, the data pane adopts Golang to write a module called MOSN (Modular Open Smart Network), and replaces Envoy with MOSN to integrate with Istio to implement the functions of Sidecar. MOSN is fully compatible with Envoy\u0026amp;rsquo;s APIs.\nSOFAMesh Pilot SOFAMesh greatly expands and enhances the Pilot module in Istio:\n Add an Adapter for SOFA Registry to provide solutions for super large-scale service registration and discovery; Add data synchronization modules to enable data exchange between multiple service registry centers; Add Open Service Registry API to provide standardized service registration. Together with Pilot and MOSN, SOFAMesh provides the ability to enable traditional intrusive frameworks (such as Spring Cloud, Dubbo and SOFARPC) and Service Mesh products to communicate with each other, thus it can smoothly evolve and transit to Service Mesh.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e44a7cb73f7b68217663bd75655f43d7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/overview/","summary":"This repository is deprecated. It will contribute to istio directly instead of developing in a forked repo. Please go to see Istio’s doc.\nSOFAMesh is a large-scale implementation scheme of Service Mesh based on Istio. On the basis of inheriting the powerful functions and rich features of Istio, in order to meet the performance requirements in large-scale deployments and to respond to the actual situation in the implementation, the following improvements are made:","tags":null,"title":"SOFAMesh overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/overview/","wordcount":260},{"author":null,"categories":null,"content":" 该项目仓库已弃用。该项目将直接向 Istio 贡献，不会继续在 fork 的仓库中开发，请转至 Istio 官网。\nSOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强大功能和丰富特性的基础上，为满足大规模部署下的性能要求以及应对落地实践中的实际情况，有如下改进：\n 采用 Golang 编写的 MOSN 取代 Envoy 合并 Mixer 到数据平面以解决性能瓶颈 增强 Pilot 以实现更灵活的服务发现机制 增加对 SOFA RPC、Dubbo 的支持 初始版本由蚂蚁金服和阿里大文娱UC事业部携手贡献。\n下图展示了SOFAMesh 和 Istio 在架构上的不同：\n主要组件 MOSN 在 SOFAMesh 中，数据面我们采用 Golang 语言编写了名为 MOSN（Modular Open Smart Network）的模块来替代 Envoy 与 Istio 集成以实现 Sidecar 的功能，同时 MOSN 完全兼容 Envoy 的 API。\nSOFA Pilot SOFAMesh 中大幅扩展和增强 Istio 中的 Pilot 模块：\n 增加 SOFA Registry 的 Adapter，提供超大规模服务注册和发现的解决方案 增加数据同步模块，以实现多个服务注册中心之间的数据交换 增加 Open Service Registry API，提供标准化的服务注册功能 MOSN 和 Pilot 配合，将可以提供让传统侵入式框架（如 Spring Cloud、Dubbo、SOFARPC 等）和 Service Mesh 产品可以相互通讯的功能，以便可以平滑的向 Service Mesh 产品演进和过渡。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e44a7cb73f7b68217663bd75655f43d7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/overview/","summary":"该项目仓库已弃用。该项目将直接向 Istio 贡献，不会继续在 fork 的仓库中开发，请转至 Istio 官网。 SOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强","tags":null,"title":"SOFAMesh 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/overview/","wordcount":474},{"author":null,"categories":null,"content":" SOFARPC Metrics SOFARPC currently measures two metrics.\nServer thread pool metric name metric tags specification rpc.bolt.threadpool.config bolt thread pool configuration Mainly includes thread pool configuration information for RPC server rpc.bolt.threadpool.active.count Running thread of the current thread pool rpc.bolt.threadpool.idle.count Idle thread of the current thread pool rpc.bolt.threadpool.queue.size Tasks in the queue of the current thread pool Client call information metric name metric tags specification rpc.consumer.service.stats.fail_count.count app,service,method,protocol,invoke_type,target_app Failure count of a certain interface rpc.consumer.service.stats.fail_count.rate app,service,method,protocol,invoke_type,target_app Number of failures per second of a certain interface rpc.consumer.service.stats.fail_time.elapPerExec app,service,method,protocol,invoke_type,target_app Average time per failed execution of a certain interface rpc.consumer.service.stats.fail_time.max app,service,method,protocol,invoke_type,target_app Maximum failure time of a certain interface rpc.consumer.service.stats.fail_time.totalTime app,service,method,protocol,invoke_type,target_app Total failure time of a certain interface rpc.consumer.service.stats.request_size.max app,service,method,protocol,invoke_type,target_app Maximum request size of a certain interface rpc.consumer.service.stats.request_size.rate app,service,method,protocol,invoke_type,target_app Average request size per second of a certain interface rpc.consumer.service.stats.request_size.totalAmount app,service,method,protocol,invoke_type,target_app Total request amount of a certain interface rpc.consumer.service.stats.response_size.max app,service,method,protocol,invoke_type,target_app Maximum response size of a certain interface rpc.consumer.service.stats.response_size.rate app,service,method,protocol,invoke_type,target_app Average response size per second of a certain interface rpc.consumer.service.stats.response_size.totalAmount app,service,method,protocol,invoke_type,target_app Total response amount of a certain interface rpc.consumer.service.stats.total_count.count app,service,method,protocol,invoke_type,target_app Total number of calls of a certain interface rpc.consumer.service.stats.total_count.count_service_sum_30000 app,service,method,protocol,invoke_type,target_app Total call information of a certain interface rpc.consumer.service.stats.total_count.rate app,service,method,protocol,invoke_type,target_app Number of calls per second of a certain interface rpc.consumer.service.stats.total_time.elapPerExec app,service,method,protocol,invoke_type,target_app Average time per execution of a certain interface rpc.consumer.service.stats.total_time.max app,service,method,protocol,invoke_type,target_app Maximum total time of a certain interface rpc.consumer.service.stats.total_time.totalTime …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/sofarpc-metrics/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1f444349855508f4b111d8f2d2b5e43d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","summary":"SOFARPC Metrics SOFARPC currently measures two metrics.\nServer thread pool metric name metric tags specification rpc.bolt.threadpool.config bolt thread pool configuration Mainly includes thread pool configuration information for RPC server rpc.bolt.threadpool.active.count Running thread of the current thread pool rpc.bolt.threadpool.idle.count Idle thread of the current thread pool rpc.bolt.threadpool.queue.size Tasks in the queue of the current thread pool Client call information metric name metric tags specification rpc.","tags":null,"title":"SOFARPC Metrics","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","wordcount":332},{"author":null,"categories":null,"content":" SOFARPC 目前度量了两个指标。\n 服务端线程池 metric name metric tags specification rpc.bolt.threadpool.config bolt 线程池配置 主要包括 rpc 服务端的线程池配置信息 rpc.bolt.threadpool.active.count 当前线程池的运行线程 rpc.bolt.threadpool.idle.count 当前线程池的空闲线程 rpc.bolt.threadpool.queue.size 当前线程池的队列中的任务 客户端调用信息 metric name metric tags specification rpc.consumer.service.stats.fail_count.count app,service,method,protocol,invoke_type,target_app 某个具体接口失败次数 rpc.consumer.service.stats.fail_count.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒失败 rpc.consumer.service.stats.fail_time.elapPerExec app,service,method,protocol,invoke_type,target_app 某个具体接口每秒执行时间 rpc.consumer.service.stats.fail_time.max app,service,method,protocol,invoke_type,target_app 某个具体接口失败时间最大值 rpc.consumer.service.stats.fail_time.totalTime app,service,method,protocol,invoke_type,target_app 某个具体接口失败时间总值 rpc.consumer.service.stats.request_size.max app,service,method,protocol,invoke_type,target_app 某个具体接口请求大小最大值 rpc.consumer.service.stats.request_size.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒平均请求大小 rpc.consumer.service.stats.request_size.totalAmount app,service,method,protocol,invoke_type,target_app 某个具体接口请求大小总金额 rpc.consumer.service.stats.response_size.max app,service,method,protocol,invoke_type,target_app 某个具体接口响应大小最大值 rpc.consumer.service.stats.response_size.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒平均响应大小 rpc.consumer.service.stats.response_size.totalAmount app,service,method,protocol,invoke_type,target_app 某个具体接口响应大小总金额 rpc.consumer.service.stats.total_count.count app,service,method,protocol,invoke_type,target_app 某个具体接口总的调用数目 rpc.consumer.service.stats.total_count.count_service_sum_30000 app,service,method,protocol,invoke_type,target_app 某个具体接口总的调用信息 rpc.consumer.service.stats.total_count.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒调用次数 rpc.consumer.service.stats.total_time.elapPerExec app,service,method,protocol,invoke_type,target_app 某个具体接口平均每次指定时间 rpc.consumer.service.stats.total_time.max app,service,method,protocol,invoke_type,target_app 某个具体接口总时间最大值 rpc.consumer.service.stats.total_time.totalTime app,service,method,protocol,invoke_type,target_app 某个具体接口总时间 服务端被调用信息 metric name metric tags specification rpc.provider.service.stats.fail_count.count app,service,method,protocol,caller_app 某个具体接口总的被调用失败次数 rpc.provider.service.stats.fail_count.rate app,service,method,protocol,caller_app 某个具体接口每秒失败次数 rpc.provider.service.stats.fail_time.elapPerExec app,service,method,protocol,caller_app 某个具体接口每次失败失败 rpc.provider.service.stats.fail_time.max app,service,method,protocol,caller_app 某个具体接口失败次数最大值 rpc.provider.service.stats.fail_time.totalTime app,service,method,protocol,caller_app 某个具体接口失败总时间 rpc.provider.service.stats.total_count.count app,service,method,protocol,caller_app 某个具体接口总的调用次数 rpc.provider.service.stats.total_count.rate app,service,method,protocol,caller_app 某个具体接口每秒调用次 …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/sofarpc-metrics/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1f444349855508f4b111d8f2d2b5e43d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","summary":"SOFARPC 目前度量了两个指标。 服务端线程池 metric name metric tags specification rpc.bolt.threadpool.config bolt 线程池配置 主要包括 rpc 服务端的线程池配置信息 rpc.bolt.threadpool.active.count 当前线程池的运行线程 rpc.bolt.threadpool.idle.count 当前线程池的空闲线程 rpc.bolt.threadpool.queue.size 当前","tags":null,"title":"SOFARPC Metrics 指标","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","wordcount":487},{"author":null,"categories":null,"content":" SOFARPC is divided into two layers from bottom to top:\n Core layer: It contains the core components of RPC (such as various interfaces, APIs and common packages) and some common implementations (such as random load balancing algorithms). Function implementation layer: All users of the function implementation layer are equal, and all functions are implemented based on the extension mechanism. The internal version specific for Ant Financial just has some internal extension based on the open source version.\nOf course, you can add your own third-party extension. See Extension mechanism for more information.\nModule division The implementation classes of each module only appear in the modules. Generally, the modules don\u0026amp;rsquo;t depend on each other. The modules that require cross dependency have been abstracted into the core or common modules.\nCurrently, SOFARPC is divided into the following modules:\nThe main modules and their corresponding dependencies are as follows:\n Module Submodule Definition Description Dependency all Publish and packing module All modules that need to be packaged bom Dependency control module Control dependency version None example Sample module all test Test module Include integration test all core api API module Include various basic process interfaces, messages, contexts, extension interfaces and others Common core common Public module Include utils and data structure exception core exception Exception module Include various exception interfaces and others common bootstrap Startup implementation module Include start class, service publish or reference logic, and registry operations core proxy Proxy implementation module Generate interface implementation proxy core Client Client implementation module Send request, receive response, maintain connections, routing, and implement load balancing, synchronization, asynchronization and other operations server Server implementation module Start listening, receive requests, send responses, distribute business threads, and implement other operations filter Interceptor implementation module Implement various interceptors for server and client core codec Coding and encoding implementation module Implement compression, serialization and other operations core protocol Protocol implementation module Package and process protocol and conduct negotiation core transport Network transmission implementation module Establish TCP connection, process sticky data packets, and distribute requested response objects registry Registry center implementation module Implement registration centers, such as ZooKeeper core ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/structure-intro/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1902232a50d57df7ab5b2c7eea1f8caa","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/structure-intro/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/structure-intro/","summary":"SOFARPC is divided into two layers from bottom to top:\n Core layer: It contains the core components of RPC (such as various interfaces, APIs and common packages) and some common implementations (such as random load balancing algorithms). Function implementation layer: All users of the function implementation layer are equal, and all functions are implemented based on the extension mechanism. The internal version specific for Ant Financial just has some internal extension based on the open source version.","tags":null,"title":"SOFARPC architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/structure-intro/","wordcount":347},{"author":null,"categories":null,"content":" SOFARPC Log Format After SOFARPC (v5.4.0 and above) is integrated in SOFATracer, the link data is output in JSON format by default. Each field meaning is as follows:\nRPC client digest log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type (bolt, rest) Service interface information Method name Current thread name Calling type (sync, callback, oneway, future) Routing record (DIRECT, REGISTRY) Target IP Target appName Local machine IP Return code (00=success; 01=business exception; 02=RPC logic error; 03=timeout failure;04=routing failure) Request serialization time (in ms) Response deserialization time (in ms) Response size (in Byte) Request size (in Byte) Client connection duration (in ms) Total call duration (in ms) Local client port Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;samples\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC server digest log (rpc-server-digest.log) Log printing time TraceId SpanId Span type Service interface information Method name Source IP Source appName Protocol (bolt, rest) Current appName Current thread name Return code (00=success; 01=business exception; 02=RPC logic error) Server thread pool waiting time (in ms) Business processing duration (in ms) Response serialization time (in ms) Request deserialization time (in ms) Response size (in Byte) Request size (in Byte) Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-sofarpc/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ad45177e2719b9a22f4bfb07a0481905","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","summary":"SOFARPC Log Format After SOFARPC (v5.4.0 and above) is integrated in SOFATracer, the link data is output in JSON format by default. Each field meaning is as follows:\nRPC client digest log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type (bolt, rest) Service interface information Method name Current thread name Calling type (sync, callback, oneway, future) Routing record (DIRECT, REGISTRY) Target IP Target appName Local machine IP Return code (00=success; 01=business exception; 02=RPC logic error; 03=timeout failure;04=routing failure) Request serialization time (in ms) Response deserialization time (in ms) Response size (in Byte) Request size (in Byte) Client connection duration (in ms) Total call duration (in ms) Local client port Transparently transmitted baggage data (kv format) Example:","tags":null,"title":"SOFARPC log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","wordcount":259},{"author":null,"categories":null,"content":" 项目简介 SOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有的业务的相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括 bolt，RESTful，dubbo，H2C 协议进行通信。其中 bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\n基本原理 当一个 SOFARPC 的应用启动的时候，如果发现当前应用需要发布 RPC 服务的话，那么 SOFARPC 会将这些服务注册到服务注册中心上。如图中 Service 指向 Registry。 当引用这个服务的 SOFARPC 应用启动时，会从服务注册中心订阅到相应服务的元数据信息。服务注册中心收到订阅请求后，会将发布方的元数据列表实时推送给服务引用方。如图中 Registry 指向 Reference。 当服务引用方拿到地址以后，就可以从中选取地址发起调用了。如图中 Reference 指向 Service。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"62f0806ad40fcaaeab6a82470b14a2e2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/overview/","summary":"项目简介 SOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有的业务的相互","tags":null,"title":"SOFARPC 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/overview/","wordcount":402},{"author":null,"categories":null,"content":" 架构图 SOFARPC 从下到上分为两层：\n 核心层：包含了我们的 RPC 的核心组件（例如我们的各种接口、API、公共包）以及一些通用的实现（例如随机等负载均衡算法）。 功能实现层：所有的功能实现层的用户都是平等的，都是基于扩展机制实现的。 蚂蚁内部使用的版本也只是开源版本上增加一些内部扩展而已。\n当然你也可以增加自己三方扩展，参见：扩展机制\n模块划分 各个模块的实现类都只在自己模块中出现，一般不交叉依赖。需要交叉依赖的全部已经抽象到core或者common模块中。\n目前模块划分如下:\n主要模块及其依赖如下：\n 模块名 子模块名 中文名 说明 依赖 all 发布打包模块 需要打包的全部模块 bom 依赖管控模块 依赖版本管控 无 example 示例模块 all test 测试模块 包含集成测试 all core api API模块 各种基本流程接口、消息、上下文、扩展接口等 common core common 公共模块 utils、数据结构 exception core exception 异常模块 各种异常接口等 common bootstrap 启动实现模块 启动类，发布或者引用服务逻辑、以及registry的操作 core proxy 代理实现模块 接口实现代理生成 core client 客户端实现模块 发送请求、接收响应、连接维护、路由、负载均衡、同步异步等 core server 服务端实现模块 启动监听、接收请求，发送响应、业务线程分发等 core filter 拦截器实现模块 服务端和客户端的各种拦截器实现 core codec 编解码实现模块 例如压缩，序列化等 core protocol 协议实现模块 协议的包装处理、协商 core transport 网络传输实现模块 TCP连接的建立，数据分包粘包处理，请求响应对象分发等 core registry 注册中心实现模块 实现注册中心，例如zk等 core ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/structure-intro/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1902232a50d57df7ab5b2c7eea1f8caa","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/structure-intro/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/structure-intro/","summary":"架构图 SOFARPC 从下到上分为两层： 核心层：包含了我们的 RPC 的核心组件（例如我们的各种接口、API、公共包）以及一些通用的实现（例如随机等负载均衡算法）","tags":null,"title":"SOFARPC 工程架构介绍","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/structure-intro/","wordcount":598},{"author":null,"categories":null,"content":" 本文档将演示了如何应用 SOFARPC 进行服务的发布和引用。 本例将在本地模拟服务端启动监听一个端口并发布一个服务，客户端引用该服务进行直连调用。\n您可以直接在工程下找到本文档的示例代码。\n创建工程 需要安装 JDK 6 及以上 和 Maven 3 以上.\n我们新建一个 Maven 工程，并引入 SOFARPC 的依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;最新版本\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 注：最新版本可以从 https://github.com/sofastack/sofa-rpc/releases 里找到。\n编写服务端实现 第一步：创建接口\n/** * Quick Start demo interface */ public interface HelloService { String sayHello(String string); } 第二步：创建接口实现\n/** * Quick Start demo implement */ public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string) { System.out.println(\u0026amp;quot;Server receive: \u0026amp;quot; + string); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; ！\u0026amp;quot;; } } 第三步：编写服务端代码\n/** * Quick Start Server */ public class QuickStartServer { public static void main(String[] args) { ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // 设置一个协议，默认bolt .setPort(12200) // 设置一个端口，默认12200 .setDaemon(false); // 非守护线程 ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // 指定接口 .setRef(new HelloServiceImpl()) // 指定实现 .setServer(serverConfig); // 指定服务端 providerConfig.export(); // 发布服务 } } 编写客户端实现 第一步：拿到服务端接口\n一般服务端会通过jar的形式将接口类提供给客户端。而在本例中，由于服务端和客户端在一个工程所以跳过。\n第二步：编程客户端代码\n/** * Quick Start client */ public class QuickStartClient { public static void main(String[] args) { ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // 指定接口 .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // 指定协议 .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12200\u0026amp;quot;); // 指定直连地址 // 生成代理类 HelloService helloService = consumerConfig.refer(); while (true) { System.out.println(helloService.sayHello(\u0026amp;quot;world\u0026amp;quot;)); try { Thread.sleep(2000); } catch (Exception e) { } } } } 运行 分别启动服务端和客户端，观察运行效果。\n服务端将打印：\n Server receive: world\n 客户端将打印：\n hello world ！\n 更多 更多示例请参考：example\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-rpc/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"192d252b0b36266622284b68d10e9fe4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","summary":"本文档将演示了如何应用 SOFARPC 进行服务的发布和引用。 本例将在本地模拟服务端启动监听一个端口并发布一个服务，客户端引用该服务进行直连调用。 您可以直接","tags":null,"title":"SOFARPC 方式快速入门","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","wordcount":563},{"author":null,"categories":null,"content":" SOFATracer 集成在 SOFARPC(5.4.0及之后的版本) 后输出链路数据的格式，默认为 JSON 数据格式，具体的字段含义解释如下：\nRPC 客户端 摘要日志（ rpc-client-digest.log） 日志打印时间 TraceId SpanId Span 类型 当前 appName 协议类型(bolt,rest) 服务接口信息 方法名 当前线程名 调用类型(sync,callback,oneway,future) 路由记录(DIRECT,REGISTRY) 目标ip 目标 appName 本机ip 返回码(00=成功/01=业务异常/02=RPC逻辑错误/03=超时失败/04=路由失败) 请求序列化时间(单位ms) 响应反序列化时间(单位ms) 响应大小(单位Byte) 请求大小(单位Byte) 客户端连接耗时(单位ms) 调用总耗时(单位ms) 本地客户端端口 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;samples\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 服务端 摘要日志（ rpc-server-digest.log） 日志打印时间 TraceId SpanId Span 类型 服务接口信息 方法名 来源ip 来源 appName 协议(bolt,rest) 当前 appName 当前线程名 返回码(00=成功/01=业务异常/02=RPC逻辑错误) 服务端线程池等待时间(单位ms) 业务处理耗时(单位ms) 响应序列化时间(单位ms) 请求反序列化时间(单位ms) 响应大小(单位Byte) 请求大小(单位Byte) 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:00:53.312\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526806853032100185011\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SOFA-BOLT-BIZ-12200-5-T1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;server.pool.wait.time\u0026amp;quot;:\u0026amp;quot;3\u0026amp;quot;,\u0026amp;quot;biz.impl.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;resp.serialize.time\u0026amp;quot;:\u0026amp;quot;4\u0026amp;quot;,\u0026amp;quot;req.deserialize.time\u0026amp;quot;:\u0026amp;quot;38\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 客户端 统计日志（ rpc-client-stat.log） 日志打印时间 日志关键key 方法信息 客户端 appName 服务接口信息 调用次数 总耗时(单位ms) 调用结果(Y/N) 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-05-18 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-sofarpc/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ad45177e2719b9a22f4bfb07a0481905","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","summary":"SOFATracer 集成在 SOFARPC(5.4.0及之后的版本) 后输出链路数据的格式，默认为 JSON 数据格式，具体的字段含义解释如下： RPC 客户端 摘要日志（ rpc-c","tags":null,"title":"SOFARPC 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","wordcount":705},{"author":null,"categories":null,"content":"SOFARPC already supports using SOFARegistry as a service registry. Suppose you have deployed SOFARegistry Server locally according to SOFARegistry\u0026amp;rsquo;s Quick Start, and the service discovery port is set to 9603 by default.\nTo use SOFARegistry as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 The current version of SOFARegistry is supported:\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\nBecause of the time of SOFABoot, users need to specify the version of rpc starter.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFARPC integration verification SOFARegistry server version: 5.2.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-sofa/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"65085018ce2b2b2ef452993bb79a69de","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","summary":"SOFARPC already supports using SOFARegistry as a service registry. Suppose you have deployed SOFARegistry Server locally according to SOFARegistry\u0026rsquo;s Quick Start, and the service discovery port is set to 9603 by default.\nTo use SOFARegistry as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 The current version of SOFARegistry is supported:\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\nBecause of the time of SOFABoot, users need to specify the version of rpc starter.","tags":null,"title":"SOFARegistry","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","wordcount":90},{"author":null,"categories":null,"content":" Product introduction SOFARegistry is a production-level, low-latency, and highly available service registry powered by Ant Financial. SOFARegistry was developed on the basis ConfigServer of Taobao. After more than ten years of business development of Ant Financial, SOFARegistry has evolved into the fifth generation architecture. Currently, SOFARegistry not only provides full support to Ant Financial and its numerous partners, but also embraces the open source community. Built on an AP architecture, SOFARegistry support s message push in seconds. It also adopts a layered architecture to support infinite horizontal scaling.\nFeatures High scalability SOFARegistry adopts a layered architecture and partition-based data storage to break the single machine performance and capacity bottleneck, and to support the theoretical \u0026amp;ldquo;infinite horizontal scaling\u0026amp;rdquo;. It has been providing reliable services to the Ant Financial production environment which has a massive number of nodes and services.\nLow latency By virtue of the SOFABolt communication framework, SOFARegistry implements TCP long connection-based heartbeat detection among nodes, and the customized push mode to send service messages between upstream and downstream nodes in seconds.\nHighly available Unlike CP-architecture based registry products such as ZooKeeper, Consul, and Etcd, SOFARegistry adopts the AP architecture based on the service characteristics of service discovery, which significantly improves the availability of the registry in the case of failures caused by network partitioning. SOFARegistry takes many measures, such as multi-replica clusters, to prevent service unavailability arising from node failures.\nArchitecture SOFARegistry has four roles: Client, SessionServer, DataServer, and MetaServer, each with unique capabilities and responsibilities. They are combined to provide external services. The relationships and structures of them are explained as follows.\nClient A client provides basic APIs to allow applications to access SOFARegistry. The client provides JAR packages to application systems, so that they can call the service subscription and publishing features of SOFARegistry.\nSessionServer The SessionServer grants clients access to SessionServer, and accepts service publishing and subscription requests from clients. It also serves as an intermediate layer to forward the published data to DataServer for storage. The SessionServer can be infinitely scaled up to support connection with large amounts of clients.\nDataServer The DataServer is responsible for storing data published by clients. The data is stored by dataId through consistent hashing. DataServer supports multi-replica backup to ensure high availability of the data. The Data can also be infinitely scaled up to support large amounts of data.\nMetaServer The MetaServer is responsible for maintaining the consistency lists of the SessionServer and DataServer within the cluster, and immediately notify other nodes in the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d444761f1ad8b0c52e3505926176b13f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/overview/","summary":"Product introduction SOFARegistry is a production-level, low-latency, and highly available service registry powered by Ant Financial. SOFARegistry was developed on the basis ConfigServer of Taobao. After more than ten years of business development of Ant Financial, SOFARegistry has evolved into the fifth generation architecture. Currently, SOFARegistry not only provides full support to Ant Financial and its numerous partners, but also embraces the open source community. Built on an AP architecture, SOFARegistry support s message push in seconds.","tags":null,"title":"SOFARegistry overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/overview/","wordcount":429},{"author":null,"categories":null,"content":" 项目简介 SOFARegistry 是蚂蚁集团开源的一个生产级、高时效、高可用的服务注册中心。SOFARegistry 最早源自于淘宝的 ConfigServer，十年来，随着蚂蚁金服的业务发展，注册中心架构已经演进至第六代。目前 SOFARegistry 不仅全面服务于蚂蚁集团的自有业务，还随着蚂蚁金融科技服务众多合作伙伴，同时也兼容开源生态。SOFARegistry 采用 AP 架构，支持秒级时效性推送，同时采用分层架构支持无限水平扩展。\n产品特点 高可扩展性 采用分层架构、数据分片存储等方式，突破单机性能与容量瓶颈，接近理论上的“无限水平扩展”。经受过蚂蚁集团生产环境海量节点数与服务数的考验。\n高时效性 借助 SOFABolt 通信框架，实现基于 TCP 长连接的节点判活与推模式的变更推送，服务上下线通知时效性在秒级以内。\n高可用性 不同于 Zookeeper、Consul、Etcd 等 CP 架构注册中心产品，SOFARegistry 针对服务发现的业务特点，采用 AP 架构，最大限度地保证网络分区故障下注册中心的可用性。通过集群多副本等方式，应对自身节点故障。\n架构 服务注册中心分为四个角色，客户端（Client）、会话服务器（SessionServer）、数据服务器（DataServer）、元数据服务器（MetaServer），每个角色司职不同能力组合后共同提供对外服务能力，各部分关系和结构如下：\nClient 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\nSessionServer 会话服务器，提供客户端接入能力，接受客户端的服务发布及服务订阅请求，并作为一个中间层将发布数据转发 DataServer 存储。SessionServer 可无限扩展以支持海量客户端连接。\nDataServer 数据服务器，负责存储客户端发布数据，数据存储按照数据 ID 进行一致性 hash 分片存储，支持多副本备份，保证数据高可用。DataServer 可无限扩展以支持海量数据量。\nMetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，在节点变更时及时通知集群内其他节点。MetaServer 通过 SOFAJRaft 保证高可用和一致性。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/overview/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d444761f1ad8b0c52e3505926176b13f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/overview/","summary":"项目简介 SOFARegistry 是蚂蚁集团开源的一个生产级、高时效、高可用的服务注册中心。SOFARegistry 最早源自于淘宝的 ConfigServer，十年来","tags":null,"title":"SOFARegistry 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-registry/overview/","wordcount":838},{"author":null,"categories":null,"content":" SOFAStack-Demos 分布式链路组件 SOFATracer 埋点机制 Demo Demo 地址：https://github.com/glmapper/tracers-guides 相关文章：https://www.sofastack.tech/blog/sofa-channel-15-retrospect/ 云原生网络代理 MOSN 扩展机制：MOSN Stream Filter 操作 Demo Demo：https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions Demo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions 操作视频：https://www.bilibili.com/video/BV1SQ4y1K7iw 相关文章：https://www.sofastack.tech/blog/sofa-channel-14-retrospect/ 云原生网络代理 MOSN 多协议机制：接入 SOFABolt 操作 Demo Demo 地址：https://github.com/mosn/mosn/tree/master/examples/codes/sofarpc-with-xprotocol-sample 操作视频：https://www.bilibili.com/video/BV1UZ4y1x7Sj 相关文章：https://www.sofastack.tech/blog/sofa-channel-13-retrospect/ 轻量级类隔离容器 SOFAArk 动态模块操作 Demo Demo：https://github.com/caojie09/sofachannel-demo 操作视频：https://www.bilibili.com/video/BV1wQ4y1T7rt 相关文章：https://www.sofastack.tech/blog/sofa-channel-11-retrospect/ 分布式事务 Seata 长事务解决方案 Saga 模式可视化状态机 Seata Saga 可视化状态机设计器演示地址： http://seata.io/saga_designer/index.html Seata Saga 可视化状态机设计器代码以及运行指南： https://github.com/seata/seata/tree/develop/saga/seata-saga-statemachine-designer 相关文章：https://www.sofastack.tech/blog/sofa-channel-10-retrospect/ SOFAJRaft 的 Counter 例子 Demo Demo 地址：https://www.sofastack.tech/projects/sofa-jraft/counter-example/ 相关文章：https://www.sofastack.tech/blog/sofa-channel-8-retrospect/ 轻量级监控分析系统 SOFALookout 客户端的相关演示操作 Demo Demo 地址：https://github.com/sofastack/sofa-lookout/tree/master/samples/metrics/client 相关文章https://www.sofastack.tech/blog/sofa-channel-6-retrospect/ SOFARPC 内存优化操作 Demo Demo 地址：https://github.com/leizhiyuan/rpcchannel 相关文章：https://www.sofastack.tech/blog/sofa-channel-3-retrospect/ ","date":-62135596800,"description":"本指南为 SOFAStack 多个组件的 Demo 合集。","dir":"guides/sofastack-demos/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6a1fada81ea88116efa0e30539da60a1","permalink":"https://sofastack.github.io/sofastack.tech/guides/sofastack-demos/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/sofastack-demos/","summary":"SOFAStack-Demos 分布式链路组件 SOFATracer 埋点机制 Demo Demo 地址：https://github.com/glmapper/tracers-guides 相关文章：https","tags":null,"title":"SOFAStack Demos","type":"guides","url":"/sofastack.tech/guides/sofastack-demos/","wordcount":1353},{"author":null,"categories":null,"content":" Since SOFARPC 5.4.0, the SOFATracer function is integrated, which is enabled by default. It can output the data information in the link.\nBy default, the output data is in JSON format. The involved fields are as follows:\nRPC client digest Log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type Service interface information Method name Current thread name Calling type Routing record Target IP Local machine IP Return code Request serialization duration Response deserialization duration Response size (in Byte) Request size (in Byte) Client connection duration Total duration for call Local client port Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC server digest log (rpc-server-digest.log) Log printing time TraceId SpanId Span type Service interface information Method name Source IP Source appName Protocol Local appName Current thread name Return code Server thread pool waiting time Business processing duration Response serialization duration Request deserialization duration Response size (in Byte) Request size (in Byte) Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/sofatracer-usage/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dde9dc7a759b7c0c272d67bac1b315d4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","summary":"Since SOFARPC 5.4.0, the SOFATracer function is integrated, which is enabled by default. It can output the data information in the link.\nBy default, the output data is in JSON format. The involved fields are as follows:\nRPC client digest Log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type Service interface information Method name Current thread name Calling type Routing record Target IP Local machine IP Return code Request serialization duration Response deserialization duration Response size (in Byte) Request size (in Byte) Client connection duration Total duration for call Local client port Transparently transmitted baggage data (kv format) Example:","tags":null,"title":"SOFATracer","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","wordcount":222},{"author":null,"categories":null,"content":" SOFATracer Tools Get Span through SOFATracer context In the process of a distributed link call, the component that integrates SOFATracer generates a Span and caches it in the SOFATracer context. And the context is cached in ThreadLocal. You can get the current SOFATracer context in the following way:\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); Through the SOFATracer context SofaTraceContext, you can add, delete, modify, check, and empty the cached Spans. As the developers responsible for integrating components, we will add, delete, modify and check the SOFATracer context to integrate distributed link tracking. However, as the application developer to directly use SOFATracer, you only need to get the corresponding Span. That is to say, you only need to use the following method after getting the context:\nSofaTracerSpan sofaTracerSpan = sofaTraceContext.getCurrentSpan(); Get information through Span When using the SOFATracer plugin component, such as Spring MVC, the component integrates the capabilities of SOFATracer. So it can get all the information in the Span after getting Span. The specific acquisition method example (it demands that Span is not empty, namely that the corresponding component has integrated SOFATracer) is as follow:\nGet TraceId and SpanId: SofaTracerSpanContext sofaTracerSpanContext = currentSpan.getSofaTracerSpanContext(); String traceId = sofaTracerSpanContext.getTraceId(); String spanId = sofaTracerSpanContext.getSpanId(); Get Tags and Logs in OpenTracing specification Get Tags:\nMap\u0026amp;lt;String, String\u0026amp;gt; tagsStr = sofaTracerSpan.getTagsWithStr(); Map\u0026amp;lt;String, Boolean\u0026amp;gt; tagsBool = sofaTracerSpan.getTagsWithBool(); Map\u0026amp;lt;String, Number\u0026amp;gt; tagsNumber = sofaTracerSpan.getTagsWithNumber(); Get Logs:\nList \u0026amp;lt;LogData\u0026amp;gt; logDataList = sofaTracerSpan.getLogs (); Process transparently transmitted data Baggage element is a collection of key-value pairs that carries data to be transparently transmitted. In SOFATracer, Baggage data is divided into sysBaggage and bizBaggage; sysBaggage mainly refers to transparently transmitted system data, and bizBaggage mainly refers to transparently transmitted business data.\nConfigure and get BaggageItem BaggageItem is a data element in the Baggage collection.\n Configure the corresponding BaggageItem data through the standard interface: String baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageVal = \u0026amp;quot;val\u0026amp;quot;; sofaTracerSpan.setBaggageItem(baggageKey,baggageVal); Get the corresponding BaggageItem data through the standard interface: String baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageValue = sofaTracerSpan.getBaggageItem(baggageKey); Note: Configuring and getting Baggage data through the standard interface is actually operated on bizBaggage.\nConfigure and get \u0026amp;lsquo;Baggage\u0026amp;rsquo; data 1, Configure \u0026amp;lsquo;Baggage\u0026amp;rsquo; data\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggage …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/utils/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d40318a5bd3ee5e1573f8770ea649dba","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/utils/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/utils/","summary":"SOFATracer Tools Get Span through SOFATracer context In the process of a distributed link call, the component that integrates SOFATracer generates a Span and caches it in the SOFATracer context. And the context is cached in ThreadLocal. You can get the current SOFATracer context in the following way:\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); Through the SOFATracer context SofaTraceContext, you can add, delete, modify, check, and empty the cached Spans. As the developers responsible for integrating components, we will add, delete, modify and check the SOFATracer context to integrate distributed link tracking.","tags":null,"title":"SOFATracer Tools","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/utils/","wordcount":443},{"author":null,"categories":null,"content":" SOFATracer configuration item After introducing SOFATracer, you can add related configuration items in Spring Boot configuration file application.properties to customize the behaviors of SOFATracer.\nFor SOFATracer log output directory, you can configure logging.path in application.properties, then the log output path is ${logging.path}/tracelog; if logging.path is not configured, the default output path is ${user.home}/logs/tracelog.\n Configuration item Description Default value logging.path log output directory SOFATracer output logs to logging.path directory in priority; If the directory is not configured, log will be output to ${user.home} by default. com.alipay.sofa.tracer.disableDigestLog Disable all integrated SOFATracer summary log printing false com.alipay.sofa.tracer.disableConfiguration[${logType}] Disable specific SOFATracer summary log printing of ${logType}. ${logType} indicates the log type, such as spring-mvc-digest.log false com.alipay.sofa.tracer.tracerGlobalRollingPolicy SOFATracer log rolling policy yyyy-MM-dd：roll by day；yyyy-MM-dd_HH：roll by hour;Logs are not rolled by day by default. com.alipay.sofa.tracer.tracerGlobalLogReserveDay Retention days of SOFATracer logs Retained for 7 days by default. com.alipay.sofa.tracer.statLogInterval Time interval of statistical logs, unit: second Output statistical logs once every 60 seconds by default com.alipay.sofa.tracer.baggageMaxLength Maximum length for retaining penetration data Default: 1024 com.alipay.sofa.tracer.zipkin.enabled Whether to enable SOFATracer remote data reporting to Zipkin true: enable; false: disable. Disabled by default. com.alipay.sofa.tracer.zipkin.baseUrl The address Zipkin address to which SOFATracer remotely reports data, which works only in the case of com.alipay.sofa.tracer.zipkin.enabled=true Format: http: //${host}:${port} com.alipay.sofa.tracer.springmvc.filterOrder Order validated by SOFATrace Filter intergrated in SpringMVC -2147483647(org.springframework.core.Ordered#HIGHEST_PRECEDENCE + 1) com.alipay.sofa.tracer.springmvc.urlPatterns URL Pattern paths validated by SOFATrace Filter intergrated in SpringMVC /*: All validated ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/configuration/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1a6bf2b7aa168440544f8d0d69358869","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/configuration/","summary":"SOFATracer configuration item After introducing SOFATracer, you can add related configuration items in Spring Boot configuration file application.properties to customize the behaviors of SOFATracer.\nFor SOFATracer log output directory, you can configure logging.path in application.properties, then the log output path is ${logging.path}/tracelog; if logging.path is not configured, the default output path is ${user.home}/logs/tracelog.\n Configuration item Description Default value logging.path log output directory SOFATracer output logs to logging.","tags":null,"title":"SOFATracer configuration items","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/configuration/","wordcount":231},{"author":null,"categories":null,"content":" SOFATracer is a distributed link tracing system based on OpenTracing specification developed by Ant Financial. Its core concept is to concatenate the same request distributed on each service node with a global TraceId. By the unified TraceId, it can record the various network call information in the call link in logs, and can remotely report the call records to Zipkin for presentation, thus implementing perspective network call.\nFeatures Distributed link tracing solution based on OpenTracing specification SOFATracer is a solution that provides link tracing based on and improved from the OpenTracing specification. Based on this implementation, each framework or component can provide the ability to link tracking by burying points.\nProvide asynchronous log printing to disks Based on high-performance lock-free loop queue of Disruptor, SOFATracer provides the ability to print logs asynchronously to local disk. The introduced framework or component can customize the output format of the log file under the premise of asynchronous log printing. SOFATracer provides two types of logs, digest log and statistical log. Digest log: logs that are printed to disk upon each call. Statistical log: logs that are printed at regular intervals.\nSupport automatic log cleanup and scrolling Asynchronous SOFATracer log supports automatic cleanup and scrolling, and supports cleaning by day and scrolling by hour or day.\nExtended based on SLF4J MDC SLF4J provides MDC (Mapped Diagnostic Contexts), which supports user to define and modify the output log format and content. SOFATracer integrates the SLF4J MDC function, which allows user to output the TraceId and SpanId of the current Tracer context by simply modifying the log configuration file.\nInterface presentation SOFATracer can remotely report link tracing data to the open-source product Zipkin for distributed link tracing presentation.\nUnified configuration The profile file provides various configuration options for you to customize the individual requirements of the application.\nScenario SOFATracer solves the problem of link tracing when implementing large-scale microservice architecture, achieves perspective network call, and can be used to rapidly Failures Discovery, Service Governance, and so on.\nComponent event tracking At present, SOFATracer supports Spring MVC, database connection pool (DBCP, Druid, c3p0, tomcat, HikariCP, BoneCP) acheived by standard JDBC interface, HttpClient and other open-source components. Event tracking for other open-source components (such as MQ, Redis) is still in development.\n Component Document Version Spring MVC doc link 2.1.0 DBCP doc link 2.2.0 Druid doc link 2.2.0 C3p0 doc link 2.2.0 HikariCP doc link 2.2.0 HttpClient doc link 2.2.0 RestTemplate doc link 2.3.0 OkHttp doc link 2.3.2 Dubbo doc link 2.4.0 OpenFeign doc link 3.0.4 Redis TODO MQ TODO ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e8d6bf5eec6c5ce1e41d461743f2c4f1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/overview/","summary":"SOFATracer is a distributed link tracing system based on OpenTracing specification developed by Ant Financial. Its core concept is to concatenate the same request distributed on each service node with a global TraceId. By the unified TraceId, it can record the various network call information in the call link in logs, and can remotely report the call records to Zipkin for presentation, thus implementing perspective network call.\nFeatures Distributed link tracing solution based on OpenTracing specification SOFATracer is a solution that provides link tracing based on and improved from the OpenTracing specification.","tags":null,"title":"SOFATracer overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/overview/","wordcount":421},{"author":null,"categories":null,"content":" SOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n功能描述 基于 OpenTracing 规范提供分布式链路跟踪解决方案 基于 OpenTracing 规范 并扩展其能力提供链路跟踪的解决方案。各个框架或者组件可以基于此实现，通过在各个组件中埋点的方式来提供链路跟踪的能力。\n提供异步落地磁盘的日志打印能力 基于 Disruptor 高性能无锁循环队列，提供异步打印日志到本地磁盘的能力。框架或者组件能够在接入时，在异步日志打印的前提下可以自定义日志文件的输出格式。SOFATracer 提供两种类似的日志打印类型即摘要日志和统计日志，摘要日志：每一次调用均会落地磁盘的日志；统计日志：每隔一定时间间隔进行统计输出的日志。\n支持日志自清除和滚动能力 异步落地磁盘的 SOFATracer 日志支持自清除和滚动能力，支持按照按照天清除和按照小时或者天滚动的能力\n基于 SLF4J MDC 的扩展能力 SLF4J 提供了 MDC（Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。SOFATracer 集成了 SLF4J MDC 功能，方便用户在只简单修改日志配置文件即可输出当前 Tracer 上下文的 TraceId 和 SpanId。\n界面展示能力 SOFATracer 可以将链路跟踪数据远程上报到开源产品 Zipkin 做分布式链路跟踪的展示。\n统一配置能力 配置文件中提供丰富的配置能力以定制化应用的个性需求。\n应用场景 解决在实施大规模微服务架构时的链路跟踪问题，达到透视化网络调用的目的，并可用于故障的快速发现，服务治理等。\n组件埋点 目前 SOFATracer 支持 Spring MVC、标准 JDBC 接口实现的数据库连接池(DBCP、Druid、c3p0、tomcat、HikariCP、BoneCP)、HttpClient、Dubbo、Spring Cloud OpenFeign 等开源组件，其他开源组件（如 MQ、Redis）埋点支持在开发中。\n 支持组件 接入文档 支持版本 Spring MVC doc link 2.1.0 DBCP doc link 2.2.0 Druid doc link 2.2.0 c3p0 doc link 2.2.0 HikariCP doc link 2.2.0 HttpClient doc link 2.2.0 OkHttp doc link 2.3.2 Dubbo doc link 2.4.0 Redis TODO MQ TODO ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/overview/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e8d6bf5eec6c5ce1e41d461743f2c4f1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/overview/","summary":"SOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调","tags":null,"title":"SOFATracer 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/overview/","wordcount":843},{"author":null,"categories":null,"content":" 通过 SOFATracer 上下文获取 Span 在一次分布式链路调用过程中，在集成了 SOFATracer 的组件会产生一个 Span 并会缓存到 SOFATracer 的上下文中，这个上下文是缓存在 ThreadLocal 中的，作为使用者可以通过如下的方式随时获取到当前 SOFATracer 的上下文：\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); SOFATracer 上下文 SofaTraceContext 通过这个实例，可以对其缓存的 Span 执行增、删、改、查和清空操作。作为组件集成的同学在集成过程中我们会对 SOFATracer 上下文做增、删、改和查等操作来集成分布式链路跟踪的能力；但是作为直接使用 SOFATracer 的应用开发者，我们只需要能够获取相应的 Span 即可，即只需要在获取上下文后使用如下的方法：\nSofaTracerSpan sofaTracerSpan = sofaTraceContext.getCurrentSpan(); 通过 Span 获取信息 在使用相应的组件如 Spring MVC 时，该组件集成了 SOFATracer 的能力后可以在获取到 Span 后获取到 Span 中的所有信息，具体获取方式示例（前提 Span 不为空即相应组件已经集成 SOFATracer）：\n获取 TraceId 和 SpanId ： SofaTracerSpanContext sofaTracerSpanContext = currentSpan.getSofaTracerSpanContext(); String traceId = sofaTracerSpanContext.getTraceId(); String spanId = sofaTracerSpanContext.getSpanId(); 获取 OpenTracing 规范中的 Tags 和 Logs 获取 Tags:\nMap\u0026amp;lt;String, String\u0026amp;gt; tagsStr = sofaTracerSpan.getTagsWithStr(); Map\u0026amp;lt;String, Boolean\u0026amp;gt; tagsBool = sofaTracerSpan.getTagsWithBool(); Map\u0026amp;lt;String, Number\u0026amp;gt; tagsNumber = sofaTracerSpan.getTagsWithNumber(); 获取 Logs:\nList\u0026amp;lt;LogData\u0026amp;gt; logDataList = sofaTracerSpan.getLogs(); 透传数据处理 Baggage 元素是一个键值对集合，其携带的是需要透传的数据。SOFATracer 中将 Baggage 数据分为 sysBaggage 和 bizBaggage；sysBaggage 主要是指系统维度的透传数据，bizBaggage 主要是指业务的透传数据。\n设置和获取 BaggageItem BaggageItem 是 Baggage集合中的数据元素。\n1、通过标准接口设置相应的 BaggageItem 数据：\nString baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageVal = \u0026amp;quot;val\u0026amp;quot;; sofaTracerSpan.setBaggageItem(baggageKey,baggageVal); 2、通过标准接口获取相应的 BaggageItem 数据：\nString baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageValue = sofaTracerSpan.getBaggageItem(baggageKey); 注：当通过标准接口进行设置和获取 Baggage 数据时，实际上操作的对象均为 bizBaggage\n设置和获取 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据 1、设置 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggage = new HashMap\u0026amp;lt;String, String\u0026amp;gt;(); bizBaggage.put(\u0026amp;quot;bizKey\u0026amp;quot;,\u0026amp;quot;bizVal\u0026amp;quot;); sofaTracerSpanContext.addBizBaggage(bizBaggage); Map\u0026amp;lt;String, String\u0026amp;gt; sysBaggage = new HashMap\u0026amp;lt;String, String\u0026amp;gt;(); sysBaggage.put(\u0026amp;quot;sysKey\u0026amp;quot;,\u0026amp;quot;sysVal\u0026amp;quot;); sofaTracerSpanContext.addSysBaggage(sysBaggage); 2、获取 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); //获取 bizBaggage Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggages = sofaTracerSpanContext.getBizBaggage(); //获取 sysBaggage Map\u0026amp;lt;String, String\u0026amp;gt; sysBaggages = sofaTracerSpanContext.getSysBaggage(); 遍历 Baggage 数据 OpenTracing 规范中 SpanContext 接口提供了 baggageItems() 方法，可以通过这个方法来遍历所有的 baggage 元素。SOFATracer 在 SofaTracerSpanContext 类中对 baggageItems() 方法进行了具体实现。\nIterable\u0026amp;lt;Map.Entry\u0026amp;lt;String, String\u0026amp;gt;\u0026amp;gt; entrySet = sofaTracerSpanContext.baggageItems(); 注：遍历 Baggage 数据返回的是 sysBaggage 和 bizBaggage 的合集。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/utils/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d40318a5bd3ee5e1573f8770ea649dba","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/utils/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/utils/","summary":"通过 SOFATracer 上下文获取 Span 在一次分布式链路调用过程中，在集成了 SOFATracer 的组件会产生一个 Span 并会缓存到 SOFATracer 的上下文中，这个上下文是缓存在 ThreadLocal 中的，作为使用者可以通","tags":null,"title":"SOFATracer 工具类","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/utils/","wordcount":738},{"author":null,"categories":null,"content":" 应用在引入 SOFATracer 后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 SOFATracer 的相关行为。\nSOFATracer 的日志输出目录，可以在 application.properties 中配置 logging.path 的路径，那么其日志输出路径为 ${logging.path}/tracelog；如果没有配置 logging.path，那么 SOFATracer 的默认输出路径为 ${user.home}/logs/tracelog。\nSpringBoot 工程配置 SOFATracer 配置项 说明 默认值 logging.path 日志输出目录 SOFATracer 会优先输出到 logging.path 目录下；如果没有配置日志输出目录，那默认输出到 ${user.home} com.alipay.sofa.tracer.disableDigestLog 是否关闭所有集成 SOFATracer 组件摘要日志打印 false com.alipay.sofa.tracer.disableConfiguration[${logType}] 关闭指定 ${logType} 的 SOFATracer 组件摘要日志打印。${logType}是指具体的日志类型，如：spring-mvc-digest.log false com.alipay.sofa.tracer.tracerGlobalRollingPolicy SOFATracer 日志的滚动策略 .yyyy-MM-dd：按照天滚动；.yyyy-MM-dd_HH：按照小时滚动。默认不配置按照天滚动 com.alipay.sofa.tracer.tracerGlobalLogReserveDay SOFATracer 日志的保留天数 默认保留 7 天 com.alipay.sofa.tracer.statLogInterval 统计日志的时间间隔，单位：秒 默认 60 秒统计日志输出一次 com.alipay.sofa.tracer.baggageMaxLength 透传数据能够允许存放的最大长度 默认值 1024 com.alipay.sofa.tracer.zipkin.enabled 是否开启 SOFATracer 远程上报数据到 Zipkin true：开启上报；false：关闭上报。默认不上报 com.alipay.sofa.tracer.zipkin.baseUrl SOFATracer 远程上报数据到 Zipkin 的地址，com.alipay.sofa.tracer.zipkin.enabled=true时配置此地址才有意义 格式：http://${host}:${port} com.alipay.sofa.tracer.springmvc.filterOrder SOFATracer 集成在 SpringMVC 的 Filter 生效的 Order -2147483647（org.springframework.core.Ordered#HIGHEST_PRECEDENCE + 1） com.alipay.sofa.tracer.springmvc.urlPatterns SOFATracer 集成在 SpringMVC 的 Filter 生效的 URL Pattern 路径 /* 全部生效 com.alipay.sofa.tracer.jsonOutput 是否以json格式输出日志 true，如果期望较少日志空间占用，可以使用非 json 格式输出（日志顺序与JSON 格式顺序一致） 非SpringBoot 工程配置 在非 SpringBoot 工程中，可以通过在 classpath 下新建一个 sofa.tracer.properties 配置文件，配置项如下：\n SOFATracer 配置项 说明 默认值 disable_middleware_digest_log 是否关闭中间件组件摘要日志打印 false disable_digest_log 关闭摘要日志打印。 false tracer_global_rolling_policy SOFATracer 日志的滚动策略 .yyyy-MM-dd：按照天滚动；.yyyy-MM-dd_HH：按照小时滚动。默认不配置按照天滚动 tracer_global_log_reserve_day SOFATracer 日志的保留天数 默认保留 7 天 stat_log_interval 统计日志的时间间隔，单位：秒 默认 60 秒统计日志输出一次 tracer_penetrate_attribute_max_length 透传数据能够允许存放的最大长度 默认值 1024 tracer_async_appender_allow_discard 是否允许丢失日志 false tracer_async_appender_is_out_discard_number 丢失日志数 0 spring.application.name 应用名 `` tracer_sampler_strategy_name_key 采样策略名 `` tracer_sampler_strategy_custom_rule_class_name 采样规则 spi 实现的类的全限定名 `` tracer_sampler_strategy_percentage_key 采样比率 com.alipay.sofa.tracer.jsonOutput 是否以json格式输出日志 true，如果期望较少日志空间占用，可以使用非 json 格式输出（日志顺序与JSON 格式顺序一致） ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/configuration/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1a6bf2b7aa168440544f8d0d69358869","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-tracer/configuration/","summary":"应用在引入 SOFATracer 后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 SOFATracer 的相关行为。 SOFATracer 的日志输出目录，可以在 application.properties 中配置 logging.path 的路径，那么其日志输出路径为 ${","tags":null,"title":"SOFATracer 配置项","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/configuration/","wordcount":1004},{"author":null,"categories":null,"content":" 在SOFARPC(5.4.0及之后的版本) 后的版本中，我们集成了SOFATracer的功能，默认开启，可以输出链路中的数据信息。\n默认为 JSON 数据格式，具体的字段含义解释如下：\nRPC 客户端 摘要日志（ rpc-client-digest.log） 日志打印时间 TraceId SpanId Span 类型 当前 appName 协议类型 服务接口信息 方法名 当前线程名 调用类型 路由记录 目标ip 本机ip 返回码 请求序列化时间 响应反序列化时间 响应大小(单位Byte) 请求大小(单位Byte) 客户端连接耗时 调用总耗时 本地客户端端口 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 服务端 摘要日志（ rpc-server-digest.log） 日志打印时间 TraceId SpanId Span 类型 服务接口信息 方法名 来源ip 来源 appName 协议 本应用 appName 当前线程名 返回码 服务端线程池等待时间 业务处理耗时 响应序列化时间 请求反序列化时间 响应大小(单位Byte) 请求大小(单位Byte) 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:00:53.312\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526806853032100185011\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SOFA-BOLT-BIZ-12200-5-T1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;server.pool.wait.time\u0026amp;quot;:\u0026amp;quot;3\u0026amp;quot;,\u0026amp;quot;biz.impl.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;resp.serialize.time\u0026amp;quot;:\u0026amp;quot;4\u0026amp;quot;,\u0026amp;quot;req.deserialize.time\u0026amp;quot;:\u0026amp;quot;38\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/sofatracer-usage/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dde9dc7a759b7c0c272d67bac1b315d4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","summary":"在SOFARPC(5.4.0及之后的版本) 后的版本中，我们集成了SOFATracer的功能，默认开启，可以输出链路中的数据信息。 默认为 JSON 数据","tags":null,"title":"SOFATracer 链路追踪","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","wordcount":529},{"author":null,"categories":null,"content":" Sampling Currently,SOFATracer provides two sampling modes. One is the fixed sampling rate based on BitSet. The other is the sampling provided to the user to customize the implementation sampling.The following example shows how to use it.\nThis example is based on the tracer-sampled-with-springmvc project,Except for application.properties, everything else is the same.\nSampling mode based on fixed sampling rate Add sampling related configuration items in application.properties #Sampling rate 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #Sampling type name com.alipay.sofa.tracer.samplerName=PercentageBasedSampler Verification When the sample rate is set to 100, the digest log is printed each time. When the sample rate is set to 0, the digest log is not printed. Print by probability when the sampling rate is set between 0 and 100. The result is verified by requesting 10 times.\n1、When the sample rate is set to 100, the digest log is printed each time.\nStart the project and enter in the browser:http://localhost:8080/springmvc ,And refresh the address 10 times, check the log as follows:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:47.643\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173568757510019269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:68,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:50.980\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569097710029269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:51.542\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569153910049269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-4\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/sampler/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"48856a040da01abc84213934c1c5fce4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/sampler/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/sampler/","summary":"Sampling Currently,SOFATracer provides two sampling modes. One is the fixed sampling rate based on BitSet. The other is the sampling provided to the user to customize the implementation sampling.The following example shows how to use it.\nThis example is based on the tracer-sampled-with-springmvc project,Except for application.properties, everything else is the same.\nSampling mode based on fixed sampling rate Add sampling related configuration items in application.properties #Sampling rate 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #Sampling type name com.","tags":null,"title":"Sampling modes","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/sampler/","wordcount":426},{"author":null,"categories":null,"content":" 1. Integrated deployment 1.1 Scale up registry-integration Assume that three registry-integration servers have been deployed currently, which are namely node1, node2, and node 3. The new node to be added to the cluster is node 4.\nOperation steps:\nStep 1. Deploy the new registry-integration node\nFirst, deploy registry-integration.tgz on node4 by referencing the Deployment topic. Note that you need to set the nodes.metaNode configuration item on node4 to a 4-server endpoint list:\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt; In this step, after node4 is started, visit curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check. The status will be unhealthy, because node4 has not been added to the cluster yet. To add it to the cluster, perform the next step.\nStep 2. Call the changePeer operation to add a new node to a cluster\nRun the changePeer command on one of the existing servers (node1, node2, and node3), to modify the current cluster from a three-node cluster (node1, node2, and node3) to a four-node cluster (node1, node2, node3, and node4):\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt;\u0026amp;quot; After completing this step, visit curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check. The status will be healthy.\n1.2 Scale down registry-integration Assume that you have three servers in one cluster, which are respectively node1, node2, and node3, and you want to scale down node3.\n1.2.1 Smooth scale-down Operation steps:\nStep 1. Call the changePeer operation to remove a node\nRun the changePeer command on either node1 or node2 to change the cluster list from \u0026amp;ldquo;node1, node2, node3\u0026amp;rdquo; to \u0026amp;ldquo;node1,node2\u0026amp;rdquo;. This removes node3 from the endpoint list of the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; After completing this step, visit curl http://\u0026amp;lt;node3\u0026amp;gt;:9615/health/check. The status will be unhealthy, because node3 has already been removed from the cluster.\nStep 2. Close node3\nThis step is optional, because node3 has already been removed from the cluster, and it does not affect the cluster even if it is still running.\n1.2.2 Handling of node failure If node3 is no longer functional, you need to remove it from the cluster.\nOperation steps:\nStep 1. Call the changePeer operation to remove a node\nRun the changePeer command on either node1 or node2 to change the cluster list from \u0026amp;ldquo;node1, node2, node3\u0026amp;rdquo; to \u0026amp;ldquo;node1,node2\u0026amp;rdquo;. This removes node3 from the endpoint list of the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 2. Independent deployment 2.1 Scale up registry-meta Assume that you have already deployed three registry-meta servers, which are respectively metaNode1, metaNode2, and metaNode3. The new node to be added to the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/scale/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"57de6dc4da1292063ff25ecea9ffbd08","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/scale/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/scale/","summary":"1. Integrated deployment 1.1 Scale up registry-integration Assume that three registry-integration servers have been deployed currently, which are namely node1, node2, and node 3. The new node to be added to the cluster is node 4.\nOperation steps:\nStep 1. Deploy the new registry-integration node\nFirst, deploy registry-integration.tgz on node4 by referencing the Deployment topic. Note that you need to set the nodes.metaNode configuration item on node4 to a 4-server endpoint list:","tags":null,"title":"Scaling","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/scale/","wordcount":954},{"author":null,"categories":null,"content":" Quickly understand ACTS scripts Do you have to frequently compile test cases? Are you frustrated by the following problems?\n You have to repeat assertEquals, which is definitely not creative. Missing an assert may lead to false success, while mistaking one may ruin your mood. If the scenario is complex, the test code may be longer than the service code, which is painful. You have to migrate utility classes every time you start writing test cases for a new application. A TestNG test case is shown on the left side, and an ACTS test case on the right. Repeated coding is gone, and the code size is significantly reduced. Unlike ordinary test scripts, ACTS scripts inherit from the ActsTestBase class, which is encapsulated with data loading methods, driving methods, execution engines, and validation rules. Users do not have to clean or prepare data, run test cases, or validate results. ACTS implements zero coding for simple services, which greatly reduces the coding and maintenance costs.\nGenerate test scripts Prerequisites: Be sure to use Maven to compile your project and generate the object model. Otherwise, ACTS IDE may encounter unexpected errors, such as edit failures and incorrect data.\nRight click a the method defined in the interface and select ACTS Function \u0026amp;gt; Generate Test Case.\nRun test script Method: Right click the tested method in ACTS script, and select TestNG to run the test script as shown in the following figure.\nSpecify a test script to run Set test_only＝^T in src/test/resource/config/acts-config.properties to run only the test case whose name starts with T. You can also replace ^T with other regular expressions.\n In this case, you can modify the name of the test case that you want to run by adding T in front of its name. ACTS only runs a test case whose name starts with T.\n Split test cases of the test script ACTS stores all test case data of a test script in the same YAML file by default. You can determine whether to store test case data by test script or by test case by configuring the option spilt_yaml_by_case. It is set to false by default, which means all test case data of the same test script is stored in one YAML file.\nYou can set spilt_yaml_by_case=true in acts-config.properties to store each test case of a new test script in a separate YAML file that is named after the case ID. This reduces the chances of file conflicts in the case where multiple developers work on the same interface.\nIn addition, ACTS provides a utility class that allows you split a legacy YAML file of a specified test script under a specified path by test case. See the following.\nBaseDataUtil.saveYamlDataToCaseByCase\n Note: Before the split, we recommend that you rename the original YAML file for backup, and then use the test case editor to check whether the content of the split files is correct. The original YAML file must be deleted if the split files are correct, because they cannot coexist. Coding for data preparation ACTS provides context APIs …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-script/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0d20739dedad1f11277bd02ed65329c3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-script/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-script/","summary":"Quickly understand ACTS scripts Do you have to frequently compile test cases? Are you frustrated by the following problems?\n You have to repeat assertEquals, which is definitely not creative. Missing an assert may lead to false success, while mistaking one may ruin your mood. If the scenario is complex, the test code may be longer than the service code, which is painful. You have to migrate utility classes every time you start writing test cases for a new application.","tags":null,"title":"Scripts","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-script/","wordcount":825},{"author":null,"categories":null,"content":" SEATA Demo for SOFAStack Cloud Native Workshop on KubeCon China 2019\nAT mode 1.Introduce maven dependencies Introduce the following dependencies into the POM file of the parent project (seata-demo-at/pom.xml):\n... \u0026amp;lt;properties\u0026amp;gt; ... \u0026amp;lt;seata.version\u0026amp;gt;0.6.1\u0026amp;lt;/seata.version\u0026amp;gt; \u0026amp;lt;netty4.version\u0026amp;gt;4.1.24.Final\u0026amp;lt;/netty4.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; ... \u0026amp;lt;dependencyManagement\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; ... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;javax.servlet\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;servlet-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${netty4.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; \u0026amp;lt;/dependencyManagement\u0026amp;gt; Introduce the following dependencies into the POM file of the stock-mng project (seata-demo-at/stock-mng/pom.xml):\n\u0026amp;lt;dependencies\u0026amp;gt; .... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; Introduce the following dependencies into the POM file of the balance-mng-impl project (seata-demo-at/balance-mng/balance-mng-impl/pom.xml):\n\u0026amp;lt;dependencies\u0026amp;gt; .... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 2. Use Seata\u0026amp;rsquo;s DataSourceProxy to proxy actual data source and configure GlobalTransactionScanner to scan @GlobalTransaction annotation Add the following java snippet to the main methods in BalanceMngApplication and StockMngApplication classes:\n... import io.seata.rm.datasource.DataSourceProxy; import io.seata.spring.annotation.GlobalTransactionScanner; ... @Configuration public static class DataSourceConfig { @Bean @Primary @ConfigurationProperties(prefix = \u0026amp;quot;spring.datasource.hikari\u0026amp;quot;) public DataSource dataSource(DataSourceProperties properties) { HikariDataSource dataSource = createDataSource(properties, HikariDataSource.class); if (StringUtils.hasText(properties.getName())) { dataSource.setPoolName(properties.getName()); } return new DataSourceProxy(dataSource); } @SuppressWarnings(\u0026amp;quot;unchecked\u0026amp;quot;) …","date":-62135596800,"description":"This guide introduces how to use the AT mode and TCC mode of the open-source distributed transaction framework Seata to solve the final consistency of service data.","dir":"guides/kc-seata-demo/","fuzzywordcount":1500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"60071a0eb44bf0901fb187eefd63ccdb","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-seata-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/guides/kc-seata-demo/","summary":"SEATA Demo for SOFAStack Cloud Native Workshop on KubeCon China 2019\nAT mode 1.Introduce maven dependencies Introduce the following dependencies into the POM file of the parent project (seata-demo-at/pom.xml):\n... \u0026lt;properties\u0026gt; ... \u0026lt;seata.version\u0026gt;0.6.1\u0026lt;/seata.version\u0026gt; \u0026lt;netty4.version\u0026gt;4.1.24.Final\u0026lt;/netty4.version\u0026gt; \u0026lt;/properties\u0026gt; ... \u0026lt;dependencyManagement\u0026gt; \u0026lt;dependencies\u0026gt; ... \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.seata\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;seata-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${seata.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.seata\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;seata-server\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${seata.version}\u0026lt;/version\u0026gt; \u0026lt;exclusions\u0026gt; \u0026lt;exclusion\u0026gt; \u0026lt;groupId\u0026gt;javax.servlet\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;servlet-api\u0026lt;/artifactId\u0026gt; \u0026lt;/exclusion\u0026gt; \u0026lt;/exclusions\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.netty\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;netty-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${netty4.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;/dependencies\u0026gt; \u0026lt;/dependencyManagement\u0026gt; Introduce the following dependencies into the POM file of the stock-mng project (seata-demo-at/stock-mng/pom.","tags":null,"title":"Seata distributed transaction practice","type":"guides","url":"/sofastack.tech/en/guides/kc-seata-demo/","wordcount":1464},{"author":null,"categories":null,"content":"SOFABoot RPC Starter provides a variety of registry center options as well as convenient configurations.\nCurrently, bolt, rest, and dubbo all support Zookeeper as registry center. In addition, bolt and rest support the local file system as registry center, which is generally used for testing.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-usage/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5a1a4619c8ac4a9fc27b8576472aed9f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-usage/","summary":"SOFABoot RPC Starter provides a variety of registry center options as well as convenient configurations.\nCurrently, bolt, rest, and dubbo all support Zookeeper as registry center. In addition, bolt and rest support the local file system as registry center, which is generally used for testing.","tags":null,"title":"Select Service Registry","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-usage/","wordcount":45},{"author":null,"categories":null,"content":"When using the Bolt communication protocol, SOFARPC can choose different serialization protocols, which can be hessian2 or protobuf currently.\nBy default, SOFARPC uses hessian2 as the serialization protocol. If you need to set the serialization protocol to protobuf, you need to configure the following settings when publishing the service:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; That is to add the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag to the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag and set the serialize-type attribute to protobuf.\nCorrespondingly, when referencing the service, you also need to change the serialization protocol to protobuf. The setting method is similar to publishing the service:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot; jvm-first=\u0026amp;quot;false\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Currently, when you use Annotation for service reference, it is not yet supported to set serialization protocol. But this will be supported in future versions. For details, see ISSUE: https://github.com/sofastack/sofa-boot/issues/278\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/serialization/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"87e2faa84c2c7a7605243dc096bc4e17","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/serialization/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/serialization/","summary":"When using the Bolt communication protocol, SOFARPC can choose different serialization protocols, which can be hessian2 or protobuf currently.\nBy default, SOFARPC uses hessian2 as the serialization protocol. If you need to set the serialization protocol to protobuf, you need to configure the following settings when publishing the service:\n\u0026lt;sofa:service ref=\u0026quot;sampleService\u0026quot; interface=\u0026quot;com.alipay.sofarpc.demo.SampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs serialize-type=\u0026quot;protobuf\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:service\u0026gt; That is to add the \u0026lt;sofa:global-attrs\u0026gt; tag to the \u0026lt;sofa:binding.bolt\u0026gt; tag and set the serialize-type attribute to protobuf.","tags":null,"title":"Serialization protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/serialization/","wordcount":138},{"author":null,"categories":null,"content":" Local development Starting SOFARegistry locally is to use the H2 database as the configuration database used by the registry, which can be started directly com.alipay.sofa.registry.server.integration.RegistryApplication#main\nBy default, application-dev.properties will be used as the configuration file\nDeployment The deployment of SOFARegistry relies on mysql, which uses mysql as the metadata storage of the registry itself SOFARegistry supports two types of deployment modes, which are integrated deployment and independent deployment. This topic describes the simplest integrated single-node deployment. For more information about deployment modes, see the Deployment topic.\nDeployment steps 1. Download the source code or installation package Download the source code git clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all Download the installation package You can download the latest registry-all.tgz package from Releases.\nrecommended to download v6 or above\ntar -zxvf registry-all.tgz cd registry-all 2. Start registry-integration 2.1 If you start the development registry locally, you can use h2 as the database\nIDEA source code startup: run com.alipay.sofa.registry.server.integration.RegistryApplication#main\nFat jar script start command: sh bin/start_dev.sh\n2.2 MySQL is recommended for the official environment Create database and table\necho \u0026amp;quot;create database registrymetadb \u0026amp;quot; | mysql -u username -p mysql -u username -p registrymetadb \u0026amp;lt; create_table.sql Modify the configuration in conf/application.properties, the database password can also be passed in through the JDBC_PASSWORD environment variable\nStart command: sh bin/integration/start.sh\n3. Check the running status You can access the healthcheck API provided by these three roles, or view logs/registry-startup.log to check the running status.\n# View the healthcheck API of the meta role: $ curl http://localhost:9615/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... raftStatus:Leader\u0026amp;quot;} # View the healthcheck API of the data role: $ curl http://localhost:9622/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... status:WORKING\u0026amp;quot;} # View the healthcheck API of the session role: $ curl http://localhost:9603/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-registry/server-quick-start/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b620900b56ba04f4668838846a97698a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/server-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/server-quick-start/","summary":"Local development Starting SOFARegistry locally is to use the H2 database as the configuration database used by the registry, which can be started directly com.alipay.sofa.registry.server.integration.RegistryApplication#main\nBy default, application-dev.properties will be used as the configuration file\nDeployment The deployment of SOFARegistry relies on mysql, which uses mysql as the metadata storage of the registry itself SOFARegistry supports two types of deployment modes, which are integrated deployment and independent deployment. This topic describes the simplest integrated single-node deployment.","tags":null,"title":"Server deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/server-quick-start/","wordcount":290},{"author":null,"categories":null,"content":" 本文是关于 MOSN server 配置的说明。\n虽然 MOSN 的配置结构里 servers 是一个 server 数组，但是目前最多只支持配置一个server。\nserver 描述的 MOSN 的基本的全局参数如下所示。\n{ \u0026amp;quot;default_log_path\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;default_log_level\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;global_log_roller\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;graceful_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;processor\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;listeners\u0026amp;quot;:[] } default_log_path 默认的错误日志文件路径，支持配置完整的日志路径，以及标准输出（stdout）和标准错误（stderr）。\n 如果配置为空，则默认输出到标准错误（stderr）。 default_log_level 默认的错误日志级别，支持DEBUG、INFO、WARN、ERROR、FATAL。\n 如果配置为空，则默认为 INFO。 global_log_roller 日志轮转配置，会对所有的日志生效，如 tracelog、accesslog、defaultlog。 字符串配置，支持两种模式的配置，一种是按时间轮转，一种是按日志大小轮转。同时只能有一种模式生效。 按照日志大小轮转\n size， 表示日志达到多少 M 进行轮转。 age，表示最多保存多少天的日志。 keep，表示最多保存多少个日志。 compress，表示日志是否压缩，on 为压缩，off 为不压缩。\n\u0026amp;quot;global_log_roller\u0026amp;quot;: \u0026amp;quot;size=100 age=10 keep=10 compress=off\u0026amp;quot; 按照时间轮转\n time，表示每个多少个小时轮转一次。\n\u0026amp;quot;global_log_roller\u0026amp;quot;:\u0026amp;quot;time=1\u0026amp;quot; graceful_timeout Duration String 的字符串配置，表示 MOSN 在进行平滑升级时，等待连接关闭的最大时间。 如果没有配置，默认为 30s。 processor MOSN 使用的 GOMAXPROCS 数量 - 如果没有配置，默认为 CPU 数量。 - 如果配置为 0，等价于没有配置。\nListeners 一组 Listener 的配置。\n","date":-62135596800,"description":"","dir":"projects/mosn/configuration/server/overview/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3b43981b2aebeca5879d566d8264f6b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/server/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/configuration/server/overview/","summary":"本文是关于 MOSN server 配置的说明。 虽然 MOSN 的配置结构里 servers 是一个 server 数组，但是目前最多只支持配置一个server。 server 描述的 MOSN 的基本的全局参数如下所示。 { \u0026quot;default_log_path\u0026quot;:\u0026quot;\u0026quot;,","tags":null,"title":"Server 配置说明","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/server/overview/","wordcount":528},{"author":null,"categories":null,"content":"If you want to extend a registry center, you should take a look at the abstract classes of the registry center.\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026amp;lt;ProviderConfig\u0026amp;gt; configs); public abstract List\u0026amp;lt;ProviderGroup\u0026amp;gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026amp;lt;ConsumerConfig\u0026amp;gt; configs); } You can see the main necessary interfaces.\nStart the registry client and maintain the connection; Destroy the registry client and release resources; Publish service and cache publish information; Unpublish service and delete cache; Subscribe to service list, return data synchronously or asynchronously, and receive notifications upon changes Unsubscribe service list and delete cache Other interfaces:\nWhen the registry center node is disconnected, the local call is not affected. Switch from one disconnected registry center node to another one by itself. After switching to another registry center node, the system resumes the registration and subscription information automatically. The registry data is cached to the local file. Even if no registry center node is connected, the service provider and caller can restart and call normally. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-extension-guide/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c952ecbea16f7ae68ad095ab8baf0583","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","summary":"If you want to extend a registry center, you should take a look at the abstract classes of the registry center.\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026lt;ProviderConfig\u0026gt; configs); public abstract List\u0026lt;ProviderGroup\u0026gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026lt;ConsumerConfig\u0026gt; configs); } You can see the main necessary interfaces.","tags":null,"title":"Service Registry extension guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","wordcount":192},{"author":null,"categories":null,"content":" SOFADashboard\u0026amp;rsquo;s service governance mainly manages SOFARPC services.\nConsole The service governance console mainly provides two basic functions: service name query and service information display. When you click the hyperlink of a service ID, you are redirected to the details page of the service.\nService provider details page Service consumer details page ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/governance/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e547baf489fd5d125be9e67a366854b6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/governance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/governance/","summary":" SOFADashboard\u0026rsquo;s service governance mainly manages SOFARPC services.\nConsole The service governance console mainly provides two basic functions: service name query and service information display. When you click the hyperlink of a service ID, you are redirected to the details page of the service.\nService provider details page Service consumer details page ","tags":null,"title":"Service governance","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/governance/","wordcount":51},{"author":null,"categories":null,"content":" The basic configuration for SOFARPC service publishing and reference is described in the \u0026amp;ldquo;Programming Interface\u0026amp;rdquo; chapter. Here are some of the features of service publishing and referencing.\nOne service publishes multiple protocols In SOFARPC, a service can be published as multiple protocols, which allows the callers to call the service provider using different protocols.\nIf you use the Java API, you can build multiple ServerConfigs as follows to set different protocols for different ServerConfigs and then assign these ServerConfigs to ProviderConfig:\nList\u0026amp;lt;ServerConfig\u0026amp;gt; serverConfigs = new ArrayList\u0026amp;lt;ServerConfig\u0026amp;gt;(); serverConfigs.add(serverConfigA); serverConfigs.add(serverConfigB); providerConfig.setServer(serverConfigs); If you use XML, add multiple bindings directly in the \u0026amp;lt;sofa:service\u0026amp;gt; tag:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; If you use annotation, add multiple bindings in @SofaService:\n@SofaService ( interfaceType = SampleService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;), @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) } ) public class SampleServiceImpl implements SampleService { // ... } One service registers multiple registry centers If you use the API, build multiple RegistryConfigs and assign them to ProviderConfig:\nList\u0026amp;lt;RegistryConfig\u0026amp;gt; registryConfigs = new ArrayList\u0026amp;lt;RegistryConfig\u0026amp;gt;(); registryConfigs.add(registryA); registryConfigs.add(registryB); providerConfig.setRegistry(registryConfigs); Method-level parameter settings In the Java API mode, you can set the corresponding parameters by calling the set method of the MethodConfig object, as shown below:\nMethodConfig methodConfigA = new MethodConfig(); MethodConfig methodConfigB = new MethodConfig(); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfigA); methodConfigs.add(methodConfigB); providerConfig.setMethods(methodConfigs); //server settings consumerConfig.setMethods(methodConfigs); //Client settings In the XML mode, you can use the \u0026amp;lt;sofa:method\u0026amp;gt; tag in the corresponding binding to set the corresponding parameters:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;3000\u0026amp;quot; address-wait-time=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Call timeout; address wait time. --\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:22000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Directly connected address --\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;sayName\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Method level configuration --\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/publish-and-reference/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"6a78b8b84b226eaf1e6d2b1ff1d15fee","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","summary":"The basic configuration for SOFARPC service publishing and reference is described in the \u0026ldquo;Programming Interface\u0026rdquo; chapter. Here are some of the features of service publishing and referencing.\nOne service publishes multiple protocols In SOFARPC, a service can be published as multiple protocols, which allows the callers to call the service provider using different protocols.\nIf you use the Java API, you can build multiple ServerConfigs as follows to set different protocols for different ServerConfigs and then assign these ServerConfigs to ProviderConfig:","tags":null,"title":"Service publishing and reference","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","wordcount":348},{"author":null,"categories":null,"content":" This document describes the complete SOFARPC service publishing and reference in the SOFABoot environment.\nPublish service \u0026amp;lt;bean id=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; thread-pool-ref=\u0026amp;quot;\u0026amp;quot; warm-up-time=\u0026amp;quot;60000\u0026amp;quot; warm-up-weight=\u0026amp;quot;10\u0026amp;quot; weight=\u0026amp;quot;100\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Attribute Name Default value Comment id ID bean名 class Class None ref Service interface implementation class interface Service interface (unique identifier) Use actual interface class for both normal calls and return calls unique-id Service tag (unique identifier) filter Filter configuration alias Separated by commas registry Server registry center Separated by commas timeout Execution timeout period on the server serialize-type Serialization protocol hessian2,protobuf thread-pool-ref Thread pool used by the current interface of the server None weight Service static weight warm-up-weight Service warm-up weight warm-up-time Service warm-up time Unit: millisecond Reference service \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;helloSyncServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;sync\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; address-wait-time=\u0026amp;quot;1000\u0026amp;quot; connect.num=\u0026amp;quot;1\u0026amp;quot; check=\u0026amp;quot;false\u0026amp;quot; connect.timeout=\u0026amp;quot;1000\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; generic-interface=\u0026amp;quot;\u0026amp;quot; idle.timeout=\u0026amp;quot;1000\u0026amp;quot; idle.timeout.read=\u0026amp;quot;1000\u0026amp;quot; lazy=\u0026amp;quot;false\u0026amp;quot; loadBalancer=\u0026amp;quot;\u0026amp;quot; registry=\u0026amp;quot;\u0026amp;quot; retries=\u0026amp;quot;1\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;xxx:12200\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; type=\u0026amp;quot;sync\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Attribute Name Default value Comment id ID Generated automatically jvm-first Whether to call the service of local machine first true interface Service interface (unique identifier) Use actual interface class for both normal calls and return calls unique-id Service tag (unique identifier) local-first whether refer to the service via jvm call true set it to false if this is to call a remote service via rpc type Calling type sync callback,sync,future,oneway filter Filter configuration alias List registry Server …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/rpc-config-xml-explain/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4b5110e9eb6cf6c6f287aef0fd210047","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","summary":"This document describes the complete SOFARPC service publishing and reference in the SOFABoot environment. Publish service \u0026lt;bean id=\u0026quot;helloSyncServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;helloSyncServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026quot; unique-id=\u0026quot;\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs registry=\u0026quot;\u0026quot; serialize-type=\u0026quot;\u0026quot; filter=\u0026quot;\u0026quot; timeout=\u0026quot;3000\u0026quot; thread-pool-ref=\u0026quot;\u0026quot; warm-up-time=\u0026quot;60000\u0026quot; warm-up-weight=\u0026quot;10\u0026quot; weight=\u0026quot;100\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;sofa:binding.rest\u0026gt; \u0026lt;/sofa:binding.rest\u0026gt; \u0026lt;/sofa:service\u0026gt; Attribute Name Default value Comment id ID bean名 class Class None ref Service interface implementation class interface Service interface (unique identifier) Use actual interface class for both normal calls","tags":null,"title":"Service publishing and reference in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","wordcount":356},{"author":null,"categories":null,"content":" Sidecar 模式是 Service Mesh 中习惯采用的模式，是容器设计模式的一种，在 Service Mesh 出现之前该模式就一直存在，本文将为您讲解 Sidecar 模式。\n什么是 Sidecar 模式 将应用程序的功能划分为单独的进程可以被视为 Sidecar 模式。如图所示，Sidecar 模式允许您在应用程序旁边添加更多功能，而无需额外第三方组件配置或修改应用程序代码。\n就像连接了 Sidecar 的三轮摩托车一样，在软件架构中， Sidecar 连接到父应用并且为其添加扩展或者增强功能。Sidecar 应用与主应用程序松散耦合。它可以屏蔽不同编程语言的差异，统一实现微服务的可观察性、监控、日志记录、配置、断路器等功能。\n使用 Sidecar 模式的优势 Sidecar 模式具有以下优势：\n 将与应用业务逻辑无关的功能抽象到共同基础设施降低了微服务代码的复杂度。\n 因为不再需要编写相同的第三方组件配置文件和代码，所以能够降低微服务架构中的代码重复度。\n 降低应用程序代码和底层平台的耦合度。\n Sidecar 模式如何工作 Sidecar 是容器应用模式的一种，也是在 Service Mesh 中发扬光大的一种模式，详见 Service Mesh 架构解析，其中详细描述使用了节点代理和 Sidecar 模式的 Service Mesh 架构。\n使用 Sidecar 模式部署服务网格时，无需在节点上运行代理，但是集群中将运行多个相同的 Sidecar 副本。在 Sidecar 部署方式中，每个应用的容器旁都会部署一个伴生容器，这个容器称之为 Sidecar 容器。Sidecar 接管进出应用容器的所有流量。在 Kubernetes 的 Pod 中，在原有的应用容器旁边注入一个 Sidecar 容器，两个容器共享存储、网络等资源，可以广义的将这个包含了 Sidecar 容器的 Pod 理解为一台主机，两个容器共享主机资源。\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/sidecar-pattern/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"38b45799d69d52f24f26008cd2ad7da5","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/sidecar-pattern/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/concept/sidecar-pattern/","summary":"Sidecar 模式是 Service Mesh 中习惯采用的模式，是容器设计模式的一种，在 Service Mesh 出现之前该模式就一直存在，本文将为您讲解 Sidecar 模式。 什么是 Sidecar 模式 将应用程序的功能划分为","tags":null,"title":"Sidecar 模式","type":"projects","url":"/sofastack.tech/projects/mosn/concept/sidecar-pattern/","wordcount":602},{"author":null,"categories":null,"content":" Since SOFARPC 5.4.0, the link analysis feature of Skywalking is supported. You can use it as needed. The Skywalking must be 6.0.0-alpha and above.\nThis document does not cover the backend deployment. If you need it, please refer to the official Skywalking documentation.\nInstall Java agent Locate the agent directory in the downloaded Skywalking release package.\n Set agent.service_name in config/agent.config, which can be any English character. Generally, it can be your own system name.\n Set the collector.backend_service Skywalking backend address in config/agent.config, which defaults to 127.0.0.1:11800. It is used for local verification.\n Add -javaagent:/path/to/skywalking-package/agenxt/skywalking-agent.jar to the application, which must be placed before the -jar parameter. The skywalking-agent can be gotten in official release package. The new directory structure is as follows:\n+-- agent +-- activations apm-toolkit-log4j-1.x-activation.jar apm-toolkit-log4j-2.x-activation.jar apm-toolkit-logback-1.x-activation.jar ... +-- config agent.config +-- plugins sofa-rpc-plugin-6.0.0-alpha.jar apm-feign-default-http-9.x.jar apm-httpClient-4.x-plugin.jar ..... skywalking-agent.jar Note: Ensure that the plugins/sofa-rpc-plugin-**.jar file exists.\n Start the application. After a period of RPC calls, you can view the UI to observe the calling link.\n More For more relevant documents, please refer to\nSkywalking Agent installation documentation Skywalking Backend deployment documentation\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/skywalking-usage/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3cd5fb45f1b981d0a8c54c8ce43b190b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","summary":"Since SOFARPC 5.4.0, the link analysis feature of Skywalking is supported. You can use it as needed. The Skywalking must be 6.0.0-alpha and above.\nThis document does not cover the backend deployment. If you need it, please refer to the official Skywalking documentation.\nInstall Java agent Locate the agent directory in the downloaded Skywalking release package.\n Set agent.service_name in config/agent.config, which can be any English character. Generally, it can be your own system name.","tags":null,"title":"Skywalking","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","wordcount":181},{"author":null,"categories":null,"content":" SOFARPC 在5.4.0 及之后的版本中，已经支持 Skywalking 的链路分析的功能，用户可以根据需要进行使用，其中Skywalking 的版本 要求6.0.0-alpha及以上。本文档，不涉及后端的部署，如有需要，可查看 Skywalking 官方文档。\n安装 Java agent 1.在下载的 Skywalking 的release 包中找到 agent 目录。\n2.在config/agent.config 中设置 agent.service_name，可以是任何英文字符，一般可以设置为自己的系统名。\n3.在config/agent.config 中设置 collector.backend_service Skywalking 的后端地址，默认指向 127.0.0.1:11800,这个是为了本地验证的。\n4.给应用程序添加 -javaagent:/path/to/skywalking-package/agenxt/skywalking-agent.jar，其中注意，一定要放在 -jar 参数之前。 Agent 在 kywalking 的 官方 release 包. 新的目录结构如下.\n+-- agent +-- activations apm-toolkit-log4j-1.x-activation.jar apm-toolkit-log4j-2.x-activation.jar apm-toolkit-logback-1.x-activation.jar ... +-- config agent.config +-- plugins sofa-rpc-plugin-6.0.0-alpha.jar apm-feign-default-http-9.x.jar apm-httpClient-4.x-plugin.jar ..... skywalking-agent.jar 注意，确保plugins/sofa-rpc-plugin-**.jar 文件存在。\n5.启动应用程序，经过一段时间RPC调用后，可以查看 UI 来观察链路。\n更多 更多文档请参考\n Skywalking Agent 安装文档 Skywalking Backend 部署文档 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/skywalking-usage/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3cd5fb45f1b981d0a8c54c8ce43b190b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/skywalking-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/skywalking-usage/","summary":"SOFARPC 在5.4.0 及之后的版本中，已经支持 Skywalking 的链路分析的功能，用户可以根据需要进行使用，其中Skywalking 的版本 要求6.0.0-alpha","tags":null,"title":"Skywalking 链路分析","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/skywalking-usage/","wordcount":482},{"author":null,"categories":null,"content":" SOFABoot 提供了模块并行启动以及 Spring Bean 异步初始化能力，用于加快应用启动速度。本文介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力以提高应用启动速度。\n使用场景 在实际使用 Spring/Spring Boot 开发中，一些 Bean 在初始化过程中执行准备操作，如拉取远程配置、初始化数据源等等。在应用启动期间，这些 Bean 会增加 Spring 上下文刷新时间，导致应用启动耗时变长。\n为了加速应用启动，SOFABoot 通过配置可选项，将 Bean 的初始化方法（init-method）使用单独线程异步执行，加快 Spring 上下文加载过程，提高应用启动速度。\n引入依赖 在工程的 pom.xml 文件中，引入如下 starter：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 使用方法 异步初始化 Bean 的原理是开启单独线程负责执行 Bean 的初始化方法（init-method）。因此，除了引入上述依赖，还需要在 Bean 的 XML 定义中配置 async-init=\u0026amp;ldquo;true\u0026amp;rdquo; 属性，用于指定是否异步执行该 Bean 的初始化方法，例如：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- async init test --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBean\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.beans.TimeWasteBean\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot; async-init=\u0026amp;quot;true\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 属性配置 SOFABoot 异步初始化能力提供两个属性配置，用于指定负责异步执行 Bean 初始化方法（init-method）的线程池大小：\n com.alipay.sofa.boot.asyncInitBeanCoreSize：线程池基本大小，默认值为 CPU 核数加一。 com.alipay.sofa.boot.asyncInitBeanMaxSize：线程池中允许的最大线程数大小，默认值为 CPU 核数加一。 此配置可以通过 VM -D 参数或者 Spring Boot 配置文件 application.yml 设置。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/bean-async-init/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1b7c2d94076ffb7ac96f64a557067917","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/bean-async-init/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/bean-async-init/","summary":"SOFABoot 提供了模块并行启动以及 Spring Bean 异步初始化能力，用于加快应用启动速度。本文介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力以提高应用启动速度。 使用场景 在实际使用","tags":null,"title":"Spring Bean 异步初始化","type":"projects","url":"/sofastack.tech/projects/sofa-boot/bean-async-init/","wordcount":578},{"author":null,"categories":null,"content":" 借助 SofaArk 框架，一个普通的 Java 应用可拆分为一个宿主应用（master biz，又称“基座”）与多个业务应用（普通 biz，又称“模块”）的模式，细化研发粒度，以此实现更快速的研发运维。本文将介绍 Spring Boot 应用如何结合 SofaArk 框架，以此构建宿主应用与业务应用。文章由以下七点展开：\n 简介 如何构建 Spring Boot 业务应用 如何构建 Spring Boot 宿主应用 如何执行 Spring Boot 宿主应用 如何执行 Spring Boot 业务应用 多 Host 与单 Host 模式 如何动态卸载 Spring Boot 业务应用 1. 简介 宿主应用（master biz）负责沉淀通用的逻辑，为业务应用提供计算和环境，为业务应用的开发者屏蔽基础设施，更新迭代较慢。各个业务应用（普通 biz）是独立的代码仓库，可以进行独立的研发运维，粒度小，更新迭代较快。业务应用将通用的依赖下沉至宿主应用，依赖宿主应用的环境运行，不是一个 可执行 Jar，因此业务应用自身的 jar 包可以不包含该通用依赖，以此得到轻量化的业务应用 jar 包。\n宿主应用与业务应用的运行关系是：宿主应用首先启动，拥有与普通应用相同的类加载器；业务应用 jar 包以热拔插的模式在宿主应用中动态部署，通用依赖通过宿主应用的类加载器加载，其它依赖使用业务自己的BizClassLoader进行加载。\n本文中宿主应用和业务应用均为 Web 应用，采用了单 host 模式，其样例代码地址如下：\n Spring Boot 宿主应用：Spring Boot 宿主应用 Spring Boot 业务应用：Spring Boot 业务应用 2. 如何构建 Spring Boot 业务应用 业务应用是一种普通 Biz，换而言之，“如何构建业务应用”即为“如何构建普通 Ark Biz”，Ark Biz的介绍请详见Ark Biz。\n2.1 依赖配置 首先，我们需要把业务应用构建成一种 SofaArk 框架可识别的Ark Biz，即：使用Ark Biz打包构建的依赖，配置如下：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;{sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;!-- 建议使用最新版本--\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;skipArkExecutable\u0026amp;gt;true\u0026amp;lt;/skipArkExecutable\u0026amp;gt; \u0026amp;lt;!-- 不生成可执行 fat jar--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!-- 生成的 Ark Biz 所在目录--\u0026amp;gt; \u0026amp;lt;bizName\u0026amp;gt;spring-boot-ark-biz\u0026amp;lt;/bizName\u0026amp;gt; \u0026amp;lt;!-- Ark Biz 名字--\u0026amp;gt; \u0026amp;lt;!-- webContextPath 是单 host 模式下的必要配置，详细配置见 5. 多 host 模式与单 host 模式 --\u0026amp;gt; \u0026amp;lt;webContextPath\u0026amp;gt;biz\u0026amp;lt;/webContextPath\u0026amp;gt; \u0026amp;lt;!-- 同一个host中设置不同的webContextPath--\u0026amp;gt; \u0026amp;lt;!-- declaredMode 开启后，业务应用可以使用自己声明过的、且宿主应用拥有的通用依赖--\u0026amp;gt; \u0026amp;lt;declaredMode\u0026amp;gt;true\u0026amp;lt;/declaredMode\u0026amp;gt; \u0026amp;lt;!-- 使用宿主应用的通用依赖--\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;!-- 此处不使用 spring boot 应用的原有构建依赖--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;plugin\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;/plugin\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 其次，由于业务应用运行时使用宿主应用的通用依赖，因此业务应用需要“排除”通用依赖，即：把 scope 设置成 provided。本样例代码中，业务应用直接使用宿主应用的 spring boot 各项依赖，配置如下：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2 打包 首先，使用 maven 打包业务应用，如下：\nmvn clean package -Dmaven.test.skip=true 在之前设定的 outputDirectory 目录下，后缀为ark-biz.jar的包是业务应用的 Ark …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-spring-boot-demo/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa8f11f9f806997290dac0ff5c105ab6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","summary":"借助 SofaArk 框架，一个普通的 Java 应用可拆分为一个宿主应用（master biz，又称“基座”）与多个业务应用（普通 biz，又称“模块”）的模式，细化研","tags":null,"title":"Spring Boot 应用如何结合 SofaArk","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","wordcount":3263},{"author":null,"categories":null,"content":" In this document will demonstrate how to use SOFATracer to track of SpringMVC, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs Add a simple Controller In the project code, add a simple Controller, for example:\n@RestController public class SampleRestController { private static final String TEMPLATE = \u0026amp;quot;Hello, %s!\u0026amp;quot;; private final AtomicLong counter = new AtomicLong(); /** * http://localhost:8080/springmvc * @param name name * @return map */ @RequestMapping(\u0026amp;quot;/springmvc\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; springmvc(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;SOFATracer SpringMVC DEMO\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; resultMap = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); resultMap.put(\u0026amp;quot;success\u0026amp;quot;, true); resultMap.put(\u0026amp;quot;id\u0026amp;quot;, counter.incrementAndGet()); resultMap.put(\u0026amp;quot;content\u0026amp;quot;, String.format(TEMPLATE, name)); return resultMap; } } Run the project Start Current SOFABoot Application. You will see the log about startup in the console:\n2018-05-11 11:55:11.932 INFO 66490 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcOpenTracingFilter\u0026#39; to urls: [/*] 2018-05-11 11:55:13.961 INFO 66490 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-05-11 11:55:13.970 INFO 66490 --- [ main] c.a.s.t.e.springmvc.DemoApplication : Started DemoApplication in 8.361 seconds (JVM running for 9.34) You can access the REST service by visiting http://localhost:8080/springmvc in your browser. You can see the result similar to the followings:\n{ content: \u0026amp;quot;Hello, SOFATracer SpringMVC DEMO!\u0026amp;quot;, id: 1, success: true } View log In the application.properties, the log printing directory we configured is ./logs, which is the root directory of the current application (we can configure it based on actual situation). In the root directory, you can see log files in the structure similar to the followings:\n./logs ├── spring.log └── tracelog ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log Every time you visit http://localhost:8080/springmvc, SOFATracer will log the digest log. You can open the spring-mvc-digest.log file to see the specific log content. As for the meaning of each output field, you can refer to here.\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-05-17 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-mvc/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"6c6389a6f994f43f08cbdf4a49d1755a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","summary":"In this document will demonstrate how to use SOFATracer to track of SpringMVC, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.","tags":null,"title":"Spring MVC Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","wordcount":356},{"author":null,"categories":null,"content":" SpringMVC Log Format After integrating SpringMVC, SOFATracer will output the link data format of the MVC requests, which is JSON by default.\nSpring MVC digest log (spring-mvc-digest.log) Data is ouput in JSON format. The meaning of each key is as follows:\n Key Meaning Time Log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.code HTTP return status code req.size.bytes Request body size resp.size.bytes Response body size Time.cost.milliseconds Request time (ms) Current.thread.name Current thread name Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-06-03 16:44:05.829\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SpringMvcJsonOutput\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;c0a80d9e1528015445828101064625\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:63933/greeting\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:50,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:1,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-auto-1-exec-10\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring MVC statistical log (spring-mvc-stat.log) stat.key is a collection of statistical keywords in this period., which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration for (ms) requests in this period success Request result: Y means success (the result code starting with 1 and 2 indicates success, and 302 indicates that the redirection is successful, and others indicate failure); N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-06-03 16:44:02.473\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:63933/greeting\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SpringMvcJsonOutput\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:5,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:149,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;Y\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-springmvc/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"af13acf5aee90a32f0fa143996063a91","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","summary":"SpringMVC Log Format After integrating SpringMVC, SOFATracer will output the link data format of the MVC requests, which is JSON by default.\nSpring MVC digest log (spring-mvc-digest.log) Data is ouput in JSON format. The meaning of each key is as follows:\n Key Meaning Time Log printing time Local.app Current application name traceId TraceId spanId SpanId Request.","tags":null,"title":"Spring MVC log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","wordcount":200},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 SpringMVC 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private static final String TEMPLATE = \u0026amp;quot;Hello, %s!\u0026amp;quot;; private final AtomicLong counter = new AtomicLong(); /** * http://localhost:8080/springmvc * @param name name * @return map */ @RequestMapping(\u0026amp;quot;/springmvc\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; springmvc(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;SOFATracer SpringMVC DEMO\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; resultMap = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); resultMap.put(\u0026amp;quot;success\u0026amp;quot;, true); resultMap.put(\u0026amp;quot;id\u0026amp;quot;, counter.incrementAndGet()); resultMap.put(\u0026amp;quot;content\u0026amp;quot;, String.format(TEMPLATE, name)); return resultMap; } } 运行 启动 SOFABoot 应用，将会在控制台中看到启动打印的日志：\n2018-05-11 11:55:11.932 INFO 66490 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcOpenTracingFilter\u0026#39; to urls: [/*] 2018-05-11 11:55:13.961 INFO 66490 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-05-11 11:55:13.970 INFO 66490 --- [ main] c.a.s.t.e.springmvc.DemoApplication : Started DemoApplication in 8.361 seconds (JVM running for 9.34) 可以通过在浏览器中输入 http://localhost:8080/springmvc 来访问 REST 服务，结果类似如下：\n{ content: \u0026amp;quot;Hello, SOFATracer SpringMVC DEMO!\u0026amp;quot;, id: 1, success: true } 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 通过访问 http://localhost:8080/springmvc SOFATracer 会记录每一次访问的摘要日志，可以打开 spring-mvc-digest.log 看到具体的输出内容。\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8801-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5006ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-mvc/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6c6389a6f994f43f08cbdf4a49d1755a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","summary":"在本文档将演示如何使用 SOFATracer 对 SpringMVC 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt;","tags":null,"title":"Spring MVC 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","wordcount":514},{"author":null,"categories":null,"content":" SOFATracer 集成 SpringMVC 后输出 MVC 请求的链路数据格式，默认为 JSON 数据格式。\nSpring MVC 摘要日志（spring-mvc-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8801-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5006ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring MVC 统计日志（spring-mvc-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功(1 开头和 2 开头的结果码算是成功的，302表示的重定向算成功，其他算是失败的)；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:34:04.129\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5006,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-springmvc/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"af13acf5aee90a32f0fa143996063a91","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","summary":"SOFATracer 集成 SpringMVC 后输出 MVC 请求的链路数据格式，默认为 JSON 数据格式。 Spring MVC 摘要日志（spring-mvc-digest.log） 以 JSON 格式输出的数据，相应 key 的","tags":null,"title":"Spring MVC 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","wordcount":380},{"author":null,"categories":null,"content":" 本文将向您展示 MOSN 的 TLS 安全能力。\n证书方案 MOSN 支持通过 Istio Citadel 的证书签发方案，基于 Istio 社区的 SDS （Secret Discovery Service）方案为 Sidecar 配置证书，支持证书动态发现和热更新能力。为了支持更高级的安全能力，MOSN 没有使用 Citadel 的证书自签发能力，而是通过对接内部 KMS 系统获取证书。同时提供证书缓存和证书推送更新能力。\n我们先来看看 MOSN 证书方案的架构图，如下图所示：\n各组件职能如下：\n Pilot：负责 Policy、SDS 配置下发，为简化复杂度，图中未标出 Citadel：Citadel 作为 Certificate Provider ，同时作为 MCP Server 为 Citadel Agent 提供 Pod、CR等资源 Citadel Agent：提供 SDS Server 服务，为MOSN、DB Sidecar、Security Sidecar 提供Certificate和CR下发能力 KMS：密钥管理系统负责证书签发 证书获取流程 对整体架构有个大致理解后，我们分解下 Sidecar 获取证书的流程，如下图所示：\n补充说明下图中的每一步环节：\n Citadel 与 Citadel agent（nodeagent）组件通过MCP协议（Mesh Configuration Protocol）同步Pod 和 CR 信息，避免 citadel agent 直接请求 API Server 导致 API Server 负载过高 MOSN 通过Unix Domain Socket 方式向 Citadel Agent 发起 SDS 请求 Citadel Agent 会进行防篡改校验，并提取appkey Citadel Agent 携带 appkey 请求 Citadel 签发证书 Citadel 检查证书是否已缓存，如果缓存证书未过期，Citadel 将直接响应缓存证书 证书不在缓存中，Citadel 会基于 appkey 构造证书签发请求，向 KMS 申请签发证书 KMS 会将签发的证书响应回Citadel，另外 KMS 也支持证书过期轮换通知 Citadel 收到证书后，会将证书传递给到对应的 Citadel Agent Citadel Agent 收到证书后，会在内存中缓存证书，并将证书下发给到 MOSN ","date":-62135596800,"description":"","dir":"projects/mosn/concept/tls/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"47ccccf9690bc65fa437463a8f5e55b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/tls/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/concept/tls/","summary":"本文将向您展示 MOSN 的 TLS 安全能力。 证书方案 MOSN 支持通过 Istio Citadel 的证书签发方案，基于 Istio 社区的 SDS （Secret Discovery Service）方案为 Sidecar 配置证书，支持证书","tags":null,"title":"TLS 安全链路","type":"projects","url":"/sofastack.tech/projects/mosn/concept/tls/","wordcount":654},{"author":null,"categories":null,"content":" SOFAArk 容器提供了一个简单的 telnet 服务端小工具，用于运行时查看容器状态，目前支持查看 Plugin 和 Biz 相关信息。\n使用方式 使用 telnet 连接服务端，端口号为 1234， 例如：\n telnet localhost 1234\n 进入交互界面:\n➜ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is \u0026#39;^]\u0026#39;. sofa-ark\u0026amp;gt; sofa-ark\u0026amp;gt; sofa-ark\u0026amp;gt; 目前支持查看 Plugin 和 Biz 相关信息，相关命令可参考提示信息：\nsofa-ark\u0026amp;gt;h Plugin Command Tips: USAGE: plugin [option...] [pluginName...] SAMPLE: plugin -m plugin-A plugin-B -h Shows the help message. -a Shows all plugin name. -m Shows the meta info of specified pluginName. -s Shows the service info of specified pluginName. -d Shows the detail info of specified pluginName. Biz Command Tips: USAGE: biz [option...] [arguments...] SAMPLE: biz -m bizIdentityA bizIdentityB. -h Shows the help message. -a Shows all biz. -m Shows the meta info of specified bizIdentity. -s Shows the service info of specified bizIdentity. -d Shows the detail info of specified bizIdentity. -i Install biz of specified bizIdentity or bizUrl. -u Uninstall biz of specified bizIdentity. -o Switch biz of specified bizIdentity. sofa-ark\u0026amp;gt; Plugin 命令 如提示信息所说，plugin 支持查看插件相关信息，包括类(资源)导入导出配置、插件打包配置等。例如：\nsofa-ark\u0026amp;gt;plugin -md runtime-sofa-boot-plugin PluginName: runtime-sofa-boot-plugin Version: 3.1.3 Priority: 1500 Activator: com.alipay.sofa.runtime.integration.activator.SofaRuntimeActivator Export Packages: com.alipay.sofa.runtime.api.*,com.alipay.sofa.runtime.client.*,com.alipay.sofa.runtime.component.*,com.alipay.sofa.runtime.constants.*,com.alipay.sofa.runtime.integration.*,com.alipay.sofa.runtime.model.*,com.alipay.sofa.runtime.service.component,com.alipay.sofa.runtime.service.helper,com.alipay.sofa.runtime.spi.client,com.alipay.sofa.runtime.spi.component,com.alipay.sofa.runtime.spi.health,com.alipay.sofa.runtime.spi.log,com.alipay.sofa.runtime.spi.binding,com.alipay.sofa.runtime.spi.util,org.aopalliance.aop,org.aopalliance.intercept Import Packages: \\ Export Classes: com.alipay.sofa.runtime.service.binding.JvmBinding,com.alipay.sofa.runtime.SofaFramework,com.alipay.sofa.runtime.SofaRuntimeProperties,com.alipay.sofa.runtime.service.binding.JvmBindingParam,com.alipay.sofa.runtime.spi.service.ServiceProxy Import Classes: \\ Export Resources: \\ Import Resources: \\ GroupId: com.alipay.sofa ArtifactId: runtime-sofa-boot-plugin Version: 3.1.3 URL: jar:file:/Users/qilong.zql/.m2/repository/com/alipay/sofa/runtime-sofa-boot-plugin/3.1.3/runtime-sofa-boot-plugin-3.1.3.jar!/ ClassLoader: com.alipay.sofa.ark.container.service.classloader.PluginClassLoader@420a63fb ClassPath: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-telnet/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f23d585e5439569b47ed83f7bc955b22","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","summary":"SOFAArk 容器提供了一个简单的 telnet 服务端小工具，用于运行时查看容器状态，目前支持查看 Plugin 和 Biz 相关信息。 使用方式 使用 telnet 连接服务端，端口号为 1234， 例如：","tags":null,"title":"Telnet 指令","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","wordcount":513},{"author":null,"categories":null,"content":" Ark package The Executed Fat Jar that meets the specific directory format requirements can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package the engineering application into a standard-format Ark package. Start the application on top of the SOFAArk container with the java -jar command. The Ark package usually contains the Ark Container, Ark Plugin dependency (if any), merged deployed Ark Biz (if any), and the Ark Biz of the application itself. For details, refer to the Ark package；\nArk Container The Ark container (Ark Plugin and Ark Biz) runs on top of the SOFAArk container. The container has the ability to manage multiple plug-ins and applications. After successful start, the container will resolve the configuration of Ark Plugin and Ark Biz, complete loading of the isolation and start them in turn based on their priorities. For details, refer to SOFAArk container startup；\nArk Plugin The Ark plug-in, which meets the specific fat jar directory format requirements, can use the officially provided Maven plug-in (sofa-Ark-plugin-maven-plugin) to package one or multiple common Java Jar packages into a standard-format Ark Plugin. Ark Plugin will contain a configuration file that usually contains the import and export configuration of plug-in classes and resources and the priority of plug-in startup. When running, the Ark container will use an independent PluginClassLoader to load the plug-ins, and build the index table for class loading according to the plug-in configuration, so that the plug-ins are isolated from each other and from the applications. For details, refer to Ark Plugin；\nArk Biz The Ark module, which meets the specific fat jar directory format requirements, can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package an engineering application into a standard-format Ark Biz package. The Ark Biz package has two roles: one is to be the organizational unit of the engineering application module and its dependent packages, and the other is to be used as a common jar package dependency by other applications to start multiple Ark Biz packages in the same SOFAArk container. Multiple Ark Biz packages share the Ark Container and Ark Plugin. For details, refer to Ark Biz；\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-terminology/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b6d0ed10afe9d04bc00307017ffba7c5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","summary":"Ark package The Executed Fat Jar that meets the specific directory format requirements can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package the engineering application into a standard-format Ark package. Start the application on top of the SOFAArk container with the java -jar command. The Ark package usually contains the Ark Container, Ark Plugin dependency (if any), merged deployed Ark Biz (if any), and the Ark Biz of the application itself.","tags":null,"title":"Terminologies","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","wordcount":351},{"author":null,"categories":null,"content":" Explanation of Terms Terminology Description TraceId TraceId refers to the ID that represents the unique request in SOFATracer. This ID is generally generated by the first system in the cluster that processes the request and is passed over the network to the next requested system in distributed calls. SpanId SpanId represents the location or level of the request in the entire call link. For example, the system A calls system B, C, and D in sequence when processing a request. Then the SpanId of the three calls are respectively: 0.1, 0.2, 0.3. If system B continues to call system E and F, the SpanIds of the two calls are: 0.1.1, 0.1.2. For other related terminologies, see OpenTracing specification.\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/explanation/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"8ba307b0679e918f7ac68c7efb7e53f7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/explanation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/explanation/","summary":"Explanation of Terms Terminology Description TraceId TraceId refers to the ID that represents the unique request in SOFATracer. This ID is generally generated by the first system in the cluster that processes the request and is passed over the network to the next requested system in distributed calls. SpanId SpanId represents the location or level of the request in the entire call link.","tags":null,"title":"Terminologies","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/explanation/","wordcount":118},{"author":null,"categories":null,"content":" General terminology Term Description Service A software function provided over the network with specific business logic processing capabilities. Service provider A computer node that provides services over the network. Service consumer A computer node that receives services through the network. The same computer node can both be the service provider of some services and the service consumer of others. Service discovery The process in which the service consumer obtains the network address of the service provider. Service registry A software system that provides service discovery functions to help service consumers obtain network addresses of service providers. Data center An independent physical area with a fixed physical location, stable power supply, and reliable network. A data center is usually an important factor that you want to consider in high availability design. Generally, deployment in the same data center features higher network quality, lower latency, but limited disaster recovery capability. However, deployment across different data centers features lower network quality, higher latency, but better disaster recovery capability. SOFARegistry terminology Terminology Description SOFARegistry A registry product open sourced by Ant Financial to provide service discovery based on the \u0026amp;ldquo;publishing-subscription\u0026amp;rdquo; mode. In addition to service discovery, SOFARegistry is applicable to more general \u0026amp;ldquo;publishing-subscription\u0026amp;rdquo; scenarios. Data In the context of service discovery, data specifically refers to the network address and some additional information of the service provider. In other circumstances, it also refers to information published to SOFARegistry. Zone The key concept of the zone-based architecture. In the context of service discovery, a zone is a collection of publishing and subscription requests. When you publish or subscribe to a service, you need to specify the zone name. For more information, see Active geo-redundant zone-based architecture solution. Publisher A node that publishes data to SOFARegistry. In the context of service discovery, the service provider is the publisher of the \u0026amp;ldquo;service provider\u0026amp;rsquo;s network address and additional information\u0026amp;rdquo;. Subscriber A node that subscribes to data from SOFARegistry. In the context of service discovery, the service consumer is the subscriber of the \u0026amp;ldquo;service provider\u0026amp;rsquo;s network address and additional information\u0026amp;rdquo;. Data ID A string that is used to identify the data. In the context of service discovery, DataId usually consists of the service port name, protocol, and version number. It is used as an identifier of the service. Group ID A string that is used for grouping data. It can be used in conjunction with DataId and InstanceId as a namespace identifier of data. Two services may be considered one same service only when their DataIds, GroupIds, and InstanceIds are identical. Instance ID A …","date":-62135596800,"description":"","dir":"projects/sofa-registry/terminology/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b678a49547c55f2a70e2d94dbce5b4a2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/terminology/","summary":"General terminology Term Description Service A software function provided over the network with specific business logic processing capabilities. Service provider A computer node that provides services over the network. Service consumer A computer node that receives services through the network. The same computer node can both be the service provider of some services and the service consumer of others.","tags":null,"title":"Terminology","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/terminology/","wordcount":508},{"author":null,"categories":null,"content":" Unit test Place the unit test cases in the modules developed by yourself.\nIf the cases rely on a third-party server (such as ZooKeeper), you must manually add the profile. See the registry-zookeeper module code.\nIf the cases rely on other modules and integration test is required, place them in the test/test-intergrated module.\nIf the cases also rely on a third-party server (such as ZooKeeper), place them in the test-intergrated-3rd module.\nPerformance test Close the following projects that are closed by default:\n-Dcontext.attachment.enable=false -Dserialize.blacklist.enable=false -Ddefault.tracer= -Dlogger.impl=com.alipay.sofa.rpc.log.SLF4JLoggerImpl -Dmultiple.classloader.enable=false -Devent.bus .enable=false\nA pressure test on BOLT+hessian has been done.\n Server: 4C8G virtual machine; gigabit network; jdk1.8.0_111;\n Client: 50 concurrent requests\n Protocol Request Response Server TPS Average RT (ms) bolt+hessian 1KB string 1KB string Directly return 10000 1.93 bolt+hessian 1KB string 1KB string Directly return 20000 4.13 bolt+hessian 1KB string 1KB string Directly return 30000 7.32 bolt+hessian 1KB string 1KB string Directly return 40000 15.78 bolt+hessian 1KB string 1KB string Directly return 50000 (Close to the utmost limit, error rate: 0.3%) 26.51 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/test/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ccda7c2372a7f55d61f682b72d3b1dc2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/test/","summary":"Unit test Place the unit test cases in the modules developed by yourself.\nIf the cases rely on a third-party server (such as ZooKeeper), you must manually add the profile. See the registry-zookeeper module code.\nIf the cases rely on other modules and integration test is required, place them in the test/test-intergrated module.\nIf the cases also rely on a third-party server (such as ZooKeeper), place them in the test-intergrated-3rd module.","tags":null,"title":"Test","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/test/","wordcount":169},{"author":null,"categories":null,"content":" When using the Bolt protocol for communication, invoke timeout defaults is 3 seconds. You can configure the timeout when referencing the service, and can also configure the timeout period from the dimension of service or method respectively. SOFARPC timeout can be set in milliseconds.\nService If you need to set the timeout from the dimension of service when publishing a service, just configure the timeout parameter to the corresponding value.\nUse XML If you reference the service using XML, set the value of the timeout attribute of the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag under the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation If you reference the service using Annotation, set the value of the timeout attribute of @SofaReferenceBinding:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, timeout = 2000)) private SampleService sampleService; Use API in Spring environment If you reference the service in Spring or Spring Boot environment, just set the value of timeout attribute of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setTimeout(2000) Use API in non-Spring environment If you reference service using the bare API of SOFARPC directly in non-Spring environment, just set the timeout attribute of ConsumerConfig:\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setTimeout(2000); Method If you want to adjust the timeout for a certain method in a service individually, you can set the timeout period from the dimension of method.\nFor a method, the timeout period of the method is prioritized. If not set, the timeout period of the service will be used.\nUse XML If you reference service using XML, just set the timeout attribute of the corresponding \u0026amp;lt;sofa: method\u0026amp;gt;:\n\u0026amp;lt;Sofa: Reference interface = \u0026amp;quot;com.example.demo .SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation No method is available for setting the method-level timeout with Annotation currenty.\nUse API in Spring environment To reference a service in Spring or Spring Boot environment, you can just set the value of timeout attribute of RpcBindingMethodInfo\nBoltBindingParam boltBindingParam = new BoltBindingParam(); RpcBindingMethodInfo rpcBindingMethodInfo = new RpcBindingMethodInfo(); rpcBindingMethodInfo.setName(\u0026amp;quot;hello\u0026amp;quot;); rpcBindingMethodInfo.setTimeout(2000); List\u0026amp;lt;RpcBindingMethodInfo\u0026amp;gt; rpcBindingMethodInfos = new ArrayList\u0026amp;lt;\u0026amp;gt;(); …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-timeout/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"cf14f73dc0c4672a9255ef55b56de419","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","summary":"When using the Bolt protocol for communication, invoke timeout defaults is 3 seconds. You can configure the timeout when referencing the service, and can also configure the timeout period from the dimension of service or method respectively. SOFARPC timeout can be set in milliseconds.\nService If you need to set the timeout from the dimension of service when publishing a service, just configure the timeout parameter to the corresponding value.","tags":null,"title":"Timeout control","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","wordcount":388},{"author":null,"categories":null,"content":" TraceId generation rule SOFATracer uses TraceId to concatenate the call logs of a request on each server. The TraceId is typically generated by the first server that receives the request. The generation rule is: server IP + generated time + incremental sequence + current process ID, such as:\n0ad1348f1403169275002100356696 The first 8 digits 0ad1348f is the IP of the machine that generates TraceId. This is a hexadecimal number, in which every two digits represents a part of IP. Based on the number, we can get a common IP address like 10.209.52.143 by converting every two digits into a decimal number. According to this rule, you can also figure out the first server that the request goes through. The next 13 digits 1403169275002 is the time to generate the TraceId. The next 4 digits 1003 is an auto-incrementing sequence that increases from 1000 to 9000. After reaching 9000, it returns to 1000 and then restarts to increase. The last 5 digits 56696 is the current process ID. Its role in tracerId is to prevent the TraceId conflicts caused by multiple processes in a single machine. Currently, TraceId\u0026amp;rsquo;s generated rules refer to Taobao\u0026amp;rsquo;s Hawkeye components.\n SpanId generation rule The SpanId in SOFATracer represents where the current call is in the entire calling link. If a Web system A receives a user request, then in the SOFATracer MVC log of this system, the recorded SpanId is 0, which means the root node of the entire call. If the system A processes this request and needs to call system B, C, and D through RPC, then the SpanIds in the SOFATracer RPC client log of system A are 0.1, 0.2, and 0.3 respectively. And in the SOFATracer RPC server logs of the system B, C, and D, the SpanIds are also 0.1, 0.2 and 0.3 respectively. If system C calls system E and F when processing the request, then in the corresponding SOFATracer RPC client log of system C, the SpanIds are 0.2.1 and 0.2.2. And the SpanIds in the SOFATracer RPC server logs of system E and F are also 0.2.1 and 0.2.2. As we can known from above, if all SpanIds in a call can be collected to compose a complete link tree.\nWe assume that the TraceId generated in a distributed call is 0a1234 (much longer in practice). Then, according to the generation process of SpanId, the call link tree is as shown in the following figure:\n Currently, SpanId\u0026amp;rsquo;s generated rules refer to Taobao\u0026amp;rsquo;s Hawkeye components.\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/traceid-generated-rule/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"8f0ef8df65deec2a4fa6591a316aa5e8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","summary":"TraceId generation rule SOFATracer uses TraceId to concatenate the call logs of a request on each server. The TraceId is typically generated by the first server that receives the request. The generation rule is: server IP + generated time + incremental sequence + current process ID, such as:\n0ad1348f1403169275002100356696 The first 8 digits 0ad1348f is the IP of the machine that generates TraceId. This is a hexadecimal number, in which every two digits represents a part of IP.","tags":null,"title":"TraceId and spanId generation rule","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","wordcount":415},{"author":null,"categories":null,"content":" TraceId 生成规则 SOFATracer 通过 TraceId 来将一个请求在各个服务器上的调用日志串联起来，TraceId 一般由接收请求经过的第一个服务器产生，产生规则是： 服务器 IP + 产生 ID 时候的时间 + 自增序列 + 当前进程号 ，比如：\n0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，大家也可以根据这个规律来查找到请求经过的第一个服务器。 后面的 13 位 1403169275002 是产生 TraceId 的时间。 之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。 最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。\n TraceId 目前的生成的规则参考了阿里的鹰眼组件。\n SpanId 生成规则 SOFATracer 中的 SpanId 代表本次调用在整个调用链路树中的位置，假设一个 Web 系统 A 接收了一次用户请求，那么在这个系统的 SOFATracer MVC 日志中，记录下的 SpanId 是 0，代表是整个调用的根节点，如果 A 系统处理这次请求，需要通过 RPC 依次调用 B，C，D 三个系统，那么在 A 系统的 SOFATracer RPC 客户端日志中，SpanId 分别是 0.1，0.2 和 0.3，在 B，C，D 三个系统的 SOFATracer RPC 服务端日志中，SpanId 也分别是 0.1，0.2 和 0.3；如果 C 系统在处理请求的时候又调用了 E，F 两个系统，那么 C 系统中对应的 SOFATracer RPC 客户端日志是 0.2.1 和 0.2.2，E，F 两个系统对应的 SOFATracer RPC 服务端日志也是 0.2.1 和 0.2.2。根据上面的描述，我们可以知道，如果把一次调用中所有的 SpanId 收集起来，可以组成一棵完整的链路树。\n我们假设一次分布式调用中产生的 TraceId 是 0a1234（实际不会这么短），那么根据上文 SpanId 的产生过程，有下图：\n SpanId 目前的生成的规则参考了阿里的鹰眼组件。\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/traceid-generated-rule/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8f0ef8df65deec2a4fa6591a316aa5e8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","summary":"TraceId 生成规则 SOFATracer 通过 TraceId 来将一个请求在各个服务器上的调用日志串联起来，TraceId 一般由接收请求经过的第一个服务器产生，产生规则是： 服务器 IP + 产","tags":null,"title":"TraceId 和 SpanId 生成规则","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","wordcount":707},{"author":null,"categories":null,"content":"By default, SOFARPC has integrated SOFATracer. Also, you can use other APM products, such as Skywalking, to achieve the corresponding functions. For details, see the relevant documents:\n SOFATracer Skywalking If you want to disable the tracing ability of SOFARPC, you can do it in two ways.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment, you can add a configuration com.alipay.sofa.rpc.defaultTracer= in application.properties.\nIf you are using sofa-rpc-all directly, you can add the following code in the main method of your application before publish any SOFARPC service or create any SOFARPC reference.\nRpcConfigs.putValue(RpcOptions.DEFAULT_TRACER, \u0026amp;quot;\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/tracing-usage/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5f944f87d827ae060fb0528f6715af97","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","summary":"By default, SOFARPC has integrated SOFATracer. Also, you can use other APM products, such as Skywalking, to achieve the corresponding functions. For details, see the relevant documents:\n SOFATracer Skywalking If you want to disable the tracing ability of SOFARPC, you can do it in two ways.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment, you can add a configuration com.alipay.sofa.rpc.defaultTracer= in application.properties.\nIf you are using sofa-rpc-all directly, you can add the following code in the main method of your application before publish any SOFARPC service or create any SOFARPC reference.","tags":null,"title":"Tracing","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","wordcount":96},{"author":null,"categories":null,"content":" Use client API In the design of SOFALookout client, API is decoupled from the implementation. If you need to log the events based on the SOFALookout API, you only need to add the lookout-api Maven dependency to the pom.xml file in your application/project. If the dependencies (such as client dependencies or SOFABoot (Spring Boot) Starter) do not exist, the API package uses NoopRegistry automatically, to replace all the locations of which the events are logged.\n1.Introduce API dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.About ID Compared to the traditional metrics library\u0026amp;rsquo;s single-dimensional information description, Lookout metrics provides tag capability that supports multi-dimensional descriptions. ID class, the unique identification of Lookout metrics, consists of name and tags.\nId basicId = registry.createId(\u0026amp;quot;rpc.provider.service.stats\u0026amp;quot;); id = basicId.withTag(\u0026amp;quot;service\u0026amp;quot;, \u0026amp;quot;com.alipay.demo.demoService\u0026amp;quot;) .withTag(\u0026amp;quot;method\u0026amp;quot;, \u0026amp;quot;sayHi\u0026amp;quot;) .withTag(\u0026amp;quot;protocol\u0026amp;quot;, \u0026amp;quot;tr\u0026amp;quot;) .withTag(\u0026amp;quot;alias\u0026amp;quot;, \u0026amp;quot;group1\u0026amp;quot;); The above is a simple example of ID introducing how to create ID and how to tag. Note that every time you tag, a new ID object is generated and returned.\n Do not proactively cache Id or the specific Metric object, since Lookout\u0026amp;rsquo;s Registry has already recorded. When using a same Id (with the same name and tags), the existing Id and its corresponding Metric object will be reused.\n 2.1 Priority tag (optional) PRIORITY enumeration level: HIGH, NORMAL, LOW.\nid.withTag(LookoutConstants.LOW_PRIORITY_TAG); It is recommended that you do not add this tag, the default level will be NORMAL. The level represents the collection interval (HIGH: 2s, NORMAL: 30s, LOW: 1min).\n2.2 About tags General tags, such as local IP, data center, and other details, will be attached and no need to be specified separately. In a non-SOFABoot project, you must manually add tags to the client, especially the app tag which specifies the app name: app=appName. key contains only lowercase letters, numbers, and underscores. (especially the metrics at runtime, such as Counter, Timer, and DistributeSummary) The values ​​of a tag shall be within a stable finite set. Try to use as few tags as possible to prevent the number of metrics from exceeding the maximum limit. For example: In RPC service, the value of method\u0026amp;rsquo;s two tags shall be as few as possible. The counterexample is that each RPC call has a separate tag-value. Therefore, the overall principle is that there should be as few custom tags as possible, and the number of sets of the values ​​should be as small as possible. Specialized TAG name \u0026amp;ldquo;priority\u0026amp;rdquo; indicates priority. The tag key reserved by the system is _*_. Starting with an underscore and ending with an …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-api/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"76574f2435a3565fe1fc50831ff9ab0c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","summary":"Use client API In the design of SOFALookout client, API is decoupled from the implementation. If you need to log the events based on the SOFALookout API, you only need to add the lookout-api Maven dependency to the pom.xml file in your application/project. If the dependencies (such as client dependencies or SOFABoot (Spring Boot) Starter) do not exist, the API package uses NoopRegistry automatically, to replace all the locations of which the events are logged.","tags":null,"title":"Use API","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","wordcount":911},{"author":null,"categories":null,"content":" SOFARPC Service publishing The process of service publishing involves three classes RegistryConfig, ServerConfig, ProviderConfig.\n RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;) RegistryConfig represents the registry center. As above, the address and port of the service registry center is 127.0.0.1:2181, and the protocol is Zookeeper.\n ServerConfig java ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ServerConfig represents the container where service runs. The above declares a server using the 8803 port and the bolt protocol.\n ProviderConfig\nProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt;() .setInterfaceId(HelloWorldService.class.getName()) .setRef(new HelloWorldServiceImpl()) .setServer(serverConfig) .setRegistry(registryConfig); providerConfig.export(); ProviderConfig represents service publishing. The above declares the interface of the service, implements the server running the service, and eventually publishes the service by the export method.\nService reference Service reference involves two classes, namely RegistryConfig and ConsumerConfig.\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig); HelloService helloService = consumerConfig.refer(); ConsumerConfig represents service reference. The above declares the interface and service registry center of the referenced service interface, and finally references the service by the refer method to get the proxy for the remote call of the service.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-rpc/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ee6f74a4974c7abf72322cef108d5ef0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","summary":"SOFARPC Service publishing The process of service publishing involves three classes RegistryConfig, ServerConfig, ProviderConfig.\n RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026quot;zookeeper\u0026quot;) .setAddress(\u0026quot;127.0.0.1:2181\u0026quot;) RegistryConfig represents the registry center. As above, the address and port of the service registry center is 127.0.0.1:2181, and the protocol is Zookeeper.\n ServerConfig java ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026quot;bolt\u0026quot;); ServerConfig represents the container where service runs. The above declares a server using the 8803 port and the bolt protocol.","tags":null,"title":"Use API in non-Spring environment","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","wordcount":173},{"author":null,"categories":null,"content":" This article describes how to quickly start installing and configuring Istio by using Docker Compose.\nSOFAMosn can not only support the standard Istio deployment mode, but also support the unilateral Inbound Sidecar or Outbound Sidecar deployment mode to meet the various requirements of users.\nPrerequisites Docker Docker Compose Install Istio Download the latest release package. Unzip the installation file and go to the decompressed path. The installation path contains: Sample application path samples/. The istioctl client executable file which is in the /bin path. The istioctl can be used to create routing rules and policies. Configuration file istion.VERSION. Add the Istio\u0026amp;rsquo;s bin path to your system\u0026amp;rsquo;s PATH. For example, execute the following command in the MacOS or Linux operating system:\nexport PATH=$PWD/bin;$PATH Pull up the Istio control plane container: SHELL docker-compose -f install/zookeeper/istio.yaml up -d Ensure that all Docker containers are running:\ndocker ps -a If the Istio pilot container terminates unexpectedly, you can run the istioctl context-create command and re-execute the previous command. 6. Configure istioctl to use the Istio API server:\nistioctl context-create -context istio-local --api-server Deploy application Now, you can start deploying the SOFABoot demo program. The demo program includes a client and a server, which communicate with each other through Bolt protocol.\ndocker-compose up -f sofa-sample-spec.yaml up -d Uninstall Istio docker-compose up -f install/zookeeper/istio.yaml down ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1de4868fa0e9c73d932343847864d7fb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","summary":"This article describes how to quickly start installing and configuring Istio by using Docker Compose.\nSOFAMosn can not only support the standard Istio deployment mode, but also support the unilateral Inbound Sidecar or Outbound Sidecar deployment mode to meet the various requirements of users.\nPrerequisites Docker Docker Compose Install Istio Download the latest release package. Unzip the installation file and go to the decompressed path. The installation path contains: Sample application path samples/.","tags":null,"title":"Use Docker to get started with Istio","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","wordcount":219},{"author":null,"categories":null,"content":" Introduction This section is intended to demonstrate how to use Jarslink 2.0 to dynamically control the life cycle of the Biz package and to complete its installation, uninstallation, and query.\nDemo With reference to How to reform common Spring Boot applications, the reformed spring-boot-transform-sample project has integrated the Jarslink 2.0 component. By executing the Ark package that the application packaged and generated, you can dynamically install or uninstall the application during its running.\n java -jar starts the spring-boot-transform-sample application Ark package. telnet localhost 1234 enters the Jarslink 2.0 command interface, as follows:\n\u0026amp;gt; telnet localhost 1234 s \u0026amp;gt; Trying 127.0.0.1\u0026amp;hellip;\n\u0026amp;gt; Connected to localhost.\n\u0026amp;gt; Escape character is \u0026amp;lsquo;^]\u0026amp;rsquo;.\n\u0026amp;gt; sofa-ark\u0026amp;gt; Execute the check -b query command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=1\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt; With reference to How to reform a common Spring Boot application, create any SOFABoot application of non-Web type, package it into a Biz package, and execute the install -b installation command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;install -b file:///Users/qilong.zql/Desktop/test-ark-biz.jar\n\u0026amp;gt; Biz:\u0026amp;lsquo;test-biz:1.0.0\u0026amp;rsquo; is installing. \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the check -b query command again, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=2\n\u0026amp;gt; bizName=\u0026amp;lsquo;test-biz\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo;\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the uninstall -b -n -v uninstallation command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;uninstall -b -n test-biz -v 1.0.0\n\u0026amp;gt; Uninstall biz:\u0026amp;lsquo;test-biz:1.0.0\u0026amp;rsquo; success. \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the check -b query command again, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=1\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n For use of more commands, refer to Interactive Commands.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"749f6debe73b73b4882477779008bb99","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","summary":"Introduction This section is intended to demonstrate how to use Jarslink 2.0 to dynamically control the life cycle of the Biz package and to complete its installation, uninstallation, and query.\nDemo With reference to How to reform common Spring Boot applications, the reformed spring-boot-transform-sample project has integrated the Jarslink 2.0 component. By executing the Ark package that the application packaged and generated, you can dynamically install or uninstall the application during its running.","tags":null,"title":"Use Jarslink for multi-application dynamic deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","wordcount":277},{"author":null,"categories":null,"content":" This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio. Serving as a critical component of SOFAMesh, MOSN is used to complete data plane forwarding.\nThe following figure shows the workflow chart of MOSN based on the overall SOFAMesh framework.\nNote: Currently, MOSN cannot be directly used in the native Istio.\nPreparations This guide supposes you are using macOS. For other operating systems, you can install the corresponding software.\n1. Install HyperKit Install docker-for-mac, and then install driver.\n1.1 Install Docker Download the Docker software package to install it or run the following command to install it:\n$ brew cask install docker 1.2 Install driver $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. Install Minikube (or purchase the commercial version of k8s cluster) It is recommended to use Minikube V0.28 or later, see https://github.com/kubernetes/minikube.\n$ brew cask install minikube 3. Start Minikube Note that Pilot requires at least 2G memory, so you can add resources to Minikube by adding parameters at startup. If your machine has insufficient resources, it is recommended to use the commercial version of the k8s cluster.\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit Create Istio namespace\n$ kubectl create namespace istio-system 4. Install kubectl command line tool kubectl is a command line interface used to run commands for k8s cluster. For how to install it, see https://kubernetes.io/docs/tasks/tools/install-kubectl.\n$ brew install kubernetes-cli 5. Install Helm Helm is a package management tool for k8s. For how to install it, see https://docs.helm.sh/using_helm/#installing-helm.\n$ brew install kubernetes-helm Deploy SOFAMesh with source codes 1. Download SOFAMesh source codes $ git clone git@github.com:sofastack/sofa-mesh.git 2. Use Helm to install SOFAMesh You should change directory to sofa-mesh source code, and then use helm template to install isito crd and istio\n``` $ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template …","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-with-sofamesh/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"9c6461e92180417d3a8ec4f3f2c723fe","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","summary":"This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio.","tags":null,"title":"Use MOSN to build Service Mesh platform","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","wordcount":1078},{"author":null,"categories":null,"content":" This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio. Serving as a critical component of SOFAMesh, MOSN is used to complete data plane forwarding.\nThe following figure shows the workflow chart of MOSN based on the overall SOFAMesh framework.\nNote: Currently, MOSN cannot be directly used in the native Istio.\nPreparations This guide supposes you are using macOS. For other operating systems, you can install the corresponding software.\n1. Install HyperKit Install docker-for-mac, and then install driver.\n1.1 Install Docker Download the Docker software package to install it or run the following command to install it:\n$ brew cask install docker 1.2 Install driver $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. Install Minikube (or purchase the commercial version of k8s cluster) It is recommended to use Minikube V0.28 or later, see https://github.com/kubernetes/minikube.\n$ brew cask install minikube 3. Start Minikube Note that Pilot requires at least 2G memory, so you can add resources to Minikube by adding parameters at startup. If your machine has insufficient resources, it is recommended to use the commercial version of the k8s cluster.\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit Create Istio namespace\n$ kubectl create namespace istio-system 4. Install kubectl command line tool kubectl is a command line interface used to run commands for k8s cluster. For how to install it, see https://kubernetes.io/docs/tasks/tools/install-kubectl.\n$ brew install kubernetes-cli 5. Install Helm Helm is a package management tool for k8s. For how to install it, see https://docs.helm.sh/using_helm/#installing-helm.\n$ brew install kubernetes-helm Deploy SOFAMesh with source codes 1. Download SOFAMesh source codes $ git clone git@github.com:sofastack/sofa-mesh.git 2. Use Helm to install SOFAMesh You should change directory to sofa-mesh source code, and then use helm template to install isito crd and istio\n``` $ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template …","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-run-with-sofamesh/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7353dfd1d668eb3e2a1c8cd26acca372","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","summary":"This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio.","tags":null,"title":"Use MOSN to build Service Mesh platform","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","wordcount":1078},{"author":null,"categories":null,"content":" Use Registry Different Registry integrations provide different ways to access Metrics.\n1. LookoutRegistry Provides the ability to count metrics by a time window. It is divided into two modes: “active” and “passive”. The passive mode is off currently.\n(1) Active mode\n You can specify the IP address of the remote agent through [Client Configuration], that is, check when start reporting, and regularly report data.\n(2) Passive mode\n This mode can be activated through [Client Configuration], and HTTP service is provided on port 19399.\n2. Connect to Prometheus The data of SOFALookout can be shared with Prometheus. In order to connect to Prometheus, you first need to add dependencies to your project:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-reg-prometheus\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; After adding the dependencies, launch the application, and you can see the data by visiting http://localhost:9494, where 9494 is the default port, you can configure com.alipay.sofa.lookout.prometheus-exporter-server-port in application.properties to change the port.\nOnce you have the URL to access the data, you can edit a prometheus.yml to grab the project information. Assuming that the local IP address is 10.15.232.20, you can configure prometheus.yml as follows:\nscrape_configs: - job_name: \u0026#39;lookout-client\u0026#39; scrape_interval: 5s static_configs: - targets: [\u0026#39;10.15.232.20:9494\u0026#39;] With the above configuration file, you can start Prometheus locally via Docker:\ndocker run -d -p 9090:9090 -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml --name prom prom/prometheus:master Then visit http://localhost:9090 through the browser, and you can query the corresponding Metrics through PromQL.\nAn example of connecting to Prometheus is also available in SOFALookout, so you can go and see it as a reference.\n3. Connect to SpringBoot actuator In addition to Prometheus, SOFALookout can be integrated with the Actuator of SpringBoot 1.x by adding the following dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Then, start and visit http://localhost:8080/metrics to see the data of events logged by the SOFALookout API.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-registry/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3c51ba6519cee542b459a170dabcf32b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","summary":"Use Registry Different Registry integrations provide different ways to access Metrics.\n1. LookoutRegistry Provides the ability to count metrics by a time window. It is divided into two modes: “active” and “passive”. The passive mode is off currently.\n(1) Active mode\n You can specify the IP address of the remote agent through [Client Configuration], that is, check when start reporting, and regularly report data.\n(2) Passive mode\n This mode can be activated through [Client Configuration], and HTTP service is provided on port 19399.","tags":null,"title":"Use Registry","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","wordcount":297},{"author":null,"categories":null,"content":" XML mode Declare the xsd file of SOFABoot: In the XML configuration file to be used, configure the declaration of the header xsd file to the followings. This enables development using the XML elements defined by SOFABoot.\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www .w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xmlns:context=\u0026amp;quot;http://www.springframework.org/schema/context\u0026amp;quot; xsi:schemaLocation =\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack .io/schema/sofaboot.xsd\u0026amp;quot; The way to publish and reference services in xml mode is as follows. sofa:service represents publishing service, and sofa:reference represents referencing service. sofa:binding indicates the protocol for service publishing or reference.\n\u0026amp;lt;bean id=\u0026amp;quot;personServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; A service can also be published through multiple protocols, as follows:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Service reference\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; A service can also be referenced through other protocols:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceRest\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-xml/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"9192a93415bee3070a9be62c0f693949","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","summary":"XML mode Declare the xsd file of SOFABoot: In the XML configuration file to be used, configure the declaration of the header xsd file to the followings. This enables development using the XML elements defined by SOFABoot.\n\u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;beans xmlns=\u0026quot;http://www.springframework.org/schema/beans\u0026quot; xmlns:xsi=\u0026quot;http://www .w3.org/2001/XMLSchema-instance\u0026quot; xmlns:sofa=\u0026quot;http://sofastack.io/schema/sofaboot\u0026quot; xmlns:context=\u0026quot;http://www.springframework.org/schema/context\u0026quot; xsi:schemaLocation =\u0026quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack .io/schema/sofaboot.xsd\u0026quot; The way to publish and reference services in xml mode is as follows. sofa:service represents publishing service, and sofa:reference represents referencing service.","tags":null,"title":"Use XML in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","wordcount":130},{"author":null,"categories":null,"content":" Use annotation for service publishing/reference In addition to the regular xml mode, it is also supported to publish and reference services with annotation in the SOFABoot environment. Similar to xml, we provide @SofaService and @SofaReference as well as @SofaServiceBinding and @SofaReferenceBinding annotation for multi-protocol.\nService publishing To publish an RPC service, you only need to add a @SofaService annotation on the bean to specify the interface and protocol type.\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } Service reference For a bean that needs to reference a remote service, you only need to add the @SofaReference annotation on the attribute or method. This supports the bolt, dubbo, rest protocol.\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } Use the demo You can test in the annotation subproject of the sample project.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-annotation/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2c3afd33cbce4f5aa2473716b3afe5a6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","summary":"Use annotation for service publishing/reference In addition to the regular xml mode, it is also supported to publish and reference services with annotation in the SOFABoot environment. Similar to xml, we provide @SofaService and @SofaReference as well as @SofaServiceBinding and @SofaReferenceBinding annotation for multi-protocol.\nService publishing To publish an RPC service, you only need to add a @SofaService annotation on the bean to specify the interface and protocol type.","tags":null,"title":"Use annotation in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","wordcount":182},{"author":null,"categories":null,"content":" This topic mainly describes a JRaft-based distributed counter.\nScenario Save a distributed counter in a raft group of multiple nodes (servers). The counter can increment and be called while remaining consistent among all nodes. The counter can normally provide two external services when a minority of nodes fail:\n incrmentAndGet(delta): increments the value of delta and returns the incremented value. get(): gets the latest value. Remote procedure calls (RPCs) JRaft adopts the Bolt communication framework at the underlayer, and defines two requests:\n IncrementAndGetRequest: used for incrementing the value public class IncrementAndGetRequest implements Serializable { private static final long serialVersionUID = -5623664785560971849L; private long delta; public long getDelta() { return this.delta; } public void setDelta(long delta) { this.delta = delta; } } GetValueRequest: used for getting the latest value public class GetValueRequest implements Serializable { private static final long serialVersionUID = 9218253805003988802L; public GetValueRequest() { super(); } } ValueResponse responses include:\n success: indicates that the request was successful value: the latest value returned by a successful request errorMsg: the error message of a failed request redirect: indicates that a leader election occurred and the request needs to be sent to the new leader node public class ValueResponse implements Serializable { private static final long serialVersionUID = -4220017686727146773L; private long value; private boolean success; /** * redirect peer id */ private String redirect; private String errorMsg; public String getErrorMsg() { return this.errorMsg; } public void setErrorMsg(String errorMsg) { this.errorMsg = errorMsg; } ...... } IncrementAndAddClosure: used for receiving requests at the leader node IncrementAndGetRequest: used for handling callbacks of the request public class IncrementAndAddClosure implements Closure { private CounterServer counterServer; private IncrementAndGetRequest request; private ValueResponse response; private Closure done; // The network response callback public IncrementAndAddClosure(CounterServer counterServer, IncrementAndGetRequest request, ValueResponse response, Closure done) { super(); this.counterServer = counterServer; this.request = request; this.response = response; this.done = done; } @Override public void run(Status status) { // Return the response to the client if (this.done != null) { done.run(status); } } public IncrementAndGetRequest getRequest() { return this.request; } public void setRequest(IncrementAndGetRequest request) { this.request = request; } public ValueResponse getResponse() { return this.response; } } Server CounterStateMachine First hold an initial value:\npublic class CounterStateMachine extends StateMachineAdapter { /** * counter value */ private AtomicLong value = new AtomicLong(0); Implement the core onApply(iterator) method, and apply the user request to the state machine: …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/counter-example/","fuzzywordcount":1900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f9c54b9f7883ccb1d7c259b7101f4674","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/counter-example/","publishdate":"0001-01-01T00:00:00Z","readingtime":9,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/counter-example/","summary":"This topic mainly describes a JRaft-based distributed counter.\nScenario Save a distributed counter in a raft group of multiple nodes (servers). The counter can increment and be called while remaining consistent among all nodes. The counter can normally provide two external services when a minority of nodes fail:\n incrmentAndGet(delta): increments the value of delta and returns the incremented value. get(): gets the latest value. Remote procedure calls (RPCs) JRaft adopts the Bolt communication framework at the underlayer, and defines two requests:","tags":null,"title":"Use case of a counter","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/counter-example/","wordcount":1859},{"author":null,"categories":null,"content":" SOFABoot provides a class isolation framework SOFAArk, giving Spring Boot a class isolation ability to resolve class or package conflicts in the development. For detailed information, please refer to:SOFAArk\nTo use this feature in SOFABoot projects, we need only two steps: configure the sofa-ark-maven-plugin plugins for packaging and add sofa-ark-springboot-starter dependencies of the class isolation framework.\nConfigure Maven packaging plugins The Maven plugins - sofa-ark-maven-plugin are available on the Central Repository. Through simple configurations, a SpringBoot project can be wrapped into an executable Ark package in the standard format. The coordinate of sofa-ark-maven-plugin is:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; The configuration template is described as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- all class exported by ark plugin would be resolved by ark biz in default, if configure denyImportClasses, then it would prefer to load them by ark biz itself --\u0026amp;gt; \u0026amp;lt;denyImportClasses\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass1\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass2\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/denyImportClasses\u0026amp;gt; \u0026amp;lt;!-- Corresponding to denyImportClasses, denyImportPackages is package-level --\u0026amp;gt; \u0026amp;lt;denyImportPackages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/denyImportPackages\u0026amp;gt; \u0026amp;lt;!-- denyImportResources can prevent resource exported by ark plugin with accurate name to be resolved --\u0026amp;gt; \u0026amp;lt;denyImportResources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test1.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test2.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;/denyImportResources\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Description of plugin configuration:\n outputDirectory: Execute mvn package and then specify a directory to store the Ark package. The default directory is ${project. Build. Directory}. arkClassifier: Execute mvn docleoy, and then specify the coordinates of Maven repositories to locate the Ark package by setting the classfaulter value (the default is empty). We recommend that you configure this to give a different name from the ordinary Fat jar; denyImportClasses: By default, the application will first load …","date":-62135596800,"description":"","dir":"projects/sofa-boot/classloader-isolation/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e007416ab008c1dd4b886433dbf8af01","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","summary":"SOFABoot provides a class isolation framework SOFAArk, giving Spring Boot a class isolation ability to resolve class or package conflicts in the development. For detailed information, please refer to:SOFAArk\nTo use this feature in SOFABoot projects, we need only two steps: configure the sofa-ark-maven-plugin plugins for packaging and add sofa-ark-springboot-starter dependencies of the class isolation framework.\nConfigure Maven packaging plugins The Maven plugins - sofa-ark-maven-plugin are available on the Central Repository.","tags":null,"title":"Use class isolation in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","wordcount":1129},{"author":null,"categories":null,"content":" Use API SOFABoot provides a set of programming APIs for RPC service publishing and reference. It is convenient to publish and reference RPC services directly in the code. Similar to Spring\u0026amp;rsquo;s ApplicationContextAware, in order to use the programming API, you first need to implement the ClientFactoryAware interface to get the programming component API:\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } With DirectService as an example, see how to use the clientFactory to publish an RPC service through the programming API:\nServiceClient serviceClient = clientFactory.getClient(ServiceClient.class); ServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(DirectService.class); serviceParam.setInstance(new DirectServiceImpl()); List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); serviceClient.service (serviceParam); In the code above:\n First, get the ServiceClient object through the clientFactory. Then, construct the ServiceParam object, which contains the parameters required to publish the service, and use the setInstance method to set the object to be published as an RPC service, setInterfaceType to set the interface of the service. Finally, call the service method of ServiceClient to publish an RPC service. The code that references the RPC service through the programming API is similar:\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt;(); referenceParam.setInterfaceType(DirectService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); DirectService proxy = referenceClient.reference(referenceParam); proxy.sayDirect(\u0026amp;quot;hello\u0026amp;quot;); Likewise, to reference an RPC service, the code simply needs to get a ReferenceClient from the ClientFactory and then construct a ReferenceParam similar to publishing a service, next set up the service interface, and finally call the ReferenceClient\u0026amp;rsquo;s reference method.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-api/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2679388dc3459714f869d8f8a71739d7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","summary":"Use API SOFABoot provides a set of programming APIs for RPC service publishing and reference. It is convenient to publish and reference RPC services directly in the code. Similar to Spring\u0026rsquo;s ApplicationContextAware, in order to use the programming API, you first need to implement the ClientFactoryAware interface to get the programming component API:\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } With DirectService as an example, see how to use the clientFactory to publish an RPC service through the programming API:","tags":null,"title":"Use dynamic API in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","wordcount":255},{"author":null,"categories":null,"content":" User guide Maven coordinator \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Check release notes for the version information.\n 1. Basic functions 1.1. Implement user request processor (UserProcessor) We provide two types of user request processors: SyncUserProcessor and AsyncUserProcessor. The difference between them is that the former returns the processing result in the form of a return value in the current processor thread, while the latter has an AsyncContext stub and can call the sendResponsemethod in the current thread or an asynchronous thread to return the processing result. For examples, refer to the following two types:\n Synchronous request processor Asynchronous request processor 1.2 Implement connection event processor (ConnectionEventProcessor) We provide two connection event processors: ConnectionEventType.CONNECT and ConnectionEventType.CLOSE. You can create your own event processors and register them with the client or the server. The client side and server side can each monitor both of their connection and disconnection events.\n Process connection event Process disconnection event 1.3 Client side and server side initialization (RpcClient, RpcServer) We have provided an RpcClient and RpcServer. They can be used after going through a simple initialization of necessary functions, or after switching on the functions. The most simple example is as follows:\n Client side initialization example Server side initialization example 1.4 Basic communication model We have provided four types of communication models:\n1. Oneway calls\nThe current thread initiates a call that is not interested in the call result and is not subject to timeout control. As long as the request is sent out, the call is completed. Note: Oneway calls are not guaranteed to succeed, and the initiator of the call has no way of knowing its result. For that reason, these calls are usually used in scenarios that can be retried or that have fixed-time notifications. Network problems or machine malfunctions during the call process may result in failure. This kind of call should only be used in business scenarios that accept such exceptions. For more information, see Example.\n2. Sync calls\nThe current thread initiates a call that only completes if it receives a result within the set timeout time. If a result is not received within the timeout time, it will generate a timeout error. This is the most commonly used call type. Ensure that the timeout time is set reasonably in accordance with the opposing terminal\u0026amp;rsquo;s processing capacity. For more information, see Example.\n3. Future calls\nThe current thread initiates a call and can then move onto executing the next call after getting an RpcResponseFuture object. The get() method of the RpcResponseFuture object can be used at any time to get the result. If the response has already been returned, the result …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-handbook/","fuzzywordcount":2000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2a0a2e3c7749dbcdceea064f6f850e33","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","publishdate":"0001-01-01T00:00:00Z","readingtime":10,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","summary":"User guide Maven coordinator \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Check release notes for the version information.\n 1. Basic functions 1.1. Implement user request processor (UserProcessor) We provide two types of user request processors: SyncUserProcessor and AsyncUserProcessor. The difference between them is that the former returns the processing result in the form of a return value in the current processor thread, while the latter has an AsyncContext stub and can call the sendResponsemethod in the current thread or an asynchronous thread to return the processing result.","tags":null,"title":"User guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","wordcount":1988},{"author":null,"categories":null,"content":" ## Version release\nVersion No. Major, minor, and revision version numbers are used. For example 2.0.0.\nRefer to: http://semver.org/lang/zh-CN/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Revision version number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance At most two versions can be maintained simultaneously.\nFor example, if the current major version is 2.2.0, the BugFix version 2.1.x will be maintained and bugs in version 2.0.x will no longer be fixed and a version upgrade is recommended.\nRelease process Daily development uses the SNAPSHOT version, such as 2.0.0-SNAPSHOT. When the modified version is officially released, the version number is revised to a formal version, such as 2.0.0. After release, the next version is pulled up, for example, 2.1.0-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-version/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b82f2d74eff3937e10f15b13cb503751","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","summary":"## Version release\nVersion No. Major, minor, and revision version numbers are used. For example 2.0.0.\nRefer to: http://semver.org/lang/zh-CN/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Revision version number: represents the BugFix version.","tags":null,"title":"Version release","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","wordcount":175},{"author":null,"categories":null,"content":" Version number The system adopts a three-digit versioning scheme. The three digits respectively are major version number, minor version number, and revision number, for example: 5.1.2.\nFor more information, see the http://semver.org/lang/zh-CN/.\n Major version number: All versions in the major version number must be compatible with each other. It is not necessary to be fully compatible with other major version numbers, but it is best to have backward compatibility. Minor version number: Represents new feature enhancements. The larger the version number, the richer the feature. Revision number: Represents the BugFix version. The revision number is only for bug fixes. The larger the version number, the more stable it is. Version maintenance You can maintain up to two versions at the same time.\nFor example, the current trunk is 5.3.0, then the bugfix branch of 5.2.x will be maintained. When any bugs arise in 5.1.x, users are prompted to upgrade the system.\nRelease process The daily development branch uses the SNAPSHOT version, for example: 5.3.0-SNAPSHOT. When it comes to official release, you can modify the version to official version, for example: 5.3.0. Pull up the next version after release, for example: 5.3.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/version-release/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"604f113607e6815757f4d1907190c13c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/version-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/version-release/","summary":"Version number The system adopts a three-digit versioning scheme. The three digits respectively are major version number, minor version number, and revision number, for example: 5.1.2.\nFor more information, see the http://semver.org/lang/zh-CN/.\n Major version number: All versions in the major version number must be compatible with each other. It is not necessary to be fully compatible with other major version numbers, but it is best to have backward compatibility.","tags":null,"title":"Version release","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/version-release/","wordcount":191},{"author":null,"categories":null,"content":" Version number Major, minor, and revision version numbers are used. For example, 1.0.0.\nFor more information, see https://semver.org/\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has. Revision version number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance Up to two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 1.2.0, the BugFix branch 1.1.x will be maintained, but bugs in branch 1.0.x will no longer be fixed. In this case, a version upgrade is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 1.0.0-SNAPSHOT. Upon formal release, the snapshot version is modified to the formal version, for example 1.0.0. After the formal release, the next version is pulled, for example, 1.0.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/version-rule/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a2093bdf478bdff0e15a2de70e522d03","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/version-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/version-rule/","summary":"Version number Major, minor, and revision version numbers are used. For example, 1.0.0.\nFor more information, see https://semver.org/\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has.","tags":null,"title":"Version rules","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/version-rule/","wordcount":180},{"author":null,"categories":null,"content":" Version number SOFARegistry uses a three-digit version number in the form of major, minor, and patch. For example, 5.2.0.\nFor more information, see https://semver.org/.\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has. Patch number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance Up to two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 5.4.0, the BugFix branch of version 5.3.x will be maintained, but bugs in branch 5.2.x will no longer be fixed. Therefore, a version upgrade for 5.2.x is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 5.3.0-SNAPSHOT. Upon formal release, SNAPSHOT is replaced with a formal version number, for example 5.3.0. After the formal release, the next version is pulled, for example, 5.3.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-standard/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"71aad9cbc42aba3d9f875ae9169cf005","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/release-standard/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/release-standard/","summary":"Version number SOFARegistry uses a three-digit version number in the form of major, minor, and patch. For example, 5.2.0.\nFor more information, see https://semver.org/.\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has.","tags":null,"title":"Version rules","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/release-standard/","wordcount":186},{"author":null,"categories":null,"content":" With SOFABoot, we can directly view the version of SOFA middleware and other detailed information in the browser.\nIntroducing SOFABoot Infra Dependency To view the version information of the SOFA middleware directly in the browser in SOFABoot, all you need to do is add the following to the Maven dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;infra-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Version Information Viewing After an application started successfully, you can visit http://localhost:8080/sofaboot/versions in the browser to view the version information of the SOFA middleware, the response such as:\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Build-Time: \u0026amp;quot;2018-04-05T20:55:22+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.0\u0026amp;quot; } ] ** Note: In SOFABoot 3.x, the endpoint path has been changed from sofaboot/versions to actuator/versions**.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/view-versions/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c6b6d22e9038aa1f5e4ce74449ba1cda","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/view-versions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/view-versions/","summary":"With SOFABoot, we can directly view the version of SOFA middleware and other detailed information in the browser.\nIntroducing SOFABoot Infra Dependency To view the version information of the SOFA middleware directly in the browser in SOFABoot, all you need to do is add the following to the Maven dependency:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;infra-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Version Information Viewing After an application started successfully, you can visit http://localhost:8080/sofaboot/versions in the browser to view the version information of the SOFA middleware, the response such as:","tags":null,"title":"View version","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/view-versions/","wordcount":115},{"author":null,"categories":null,"content":"The warm-up weight feature allows the client machine to distribute traffic based on the corresponding weight of the server. This feature is also often used in the scenario where a few machines within a cluster are being started. The server machines can be warmed up in a short time with the traffic weight function, and then continue to receive the normal traffic.\nThe operating mechanism is as follows: When the server service starts, it pushes its own warm-up duration, weight during warm-up, and normal weight after warm-up to the Service Registry. As shown above, Service B points to Service Registry.\n When referencing service, the client obtains the warm-up weight information of each service instance. As shown above, Service Registry points to client.\n When calling service, the client distributes the traffic according to the warm-up weight of the address where the service is located. As shown above, the client points to Service A and Service B. Service A has completed warm-up, and its weight is 100 by default. Service B is in the warm-up period, and its weight is 10. Therefore, their traffic is 100%110 and 10%110 respectively.\n This feature is used as follows:\nProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt;() .setWeight(100) .setParameter(ProviderInfoAttrs.ATTR_WARMUP_WEIGHT,\u0026amp;quot;10\u0026amp;quot;) .setParameter(ProviderInfoAttrs.ATTR_WARM_UP_END_TIME, \u0026amp;quot;12000\u0026amp;quot;); As above, the warm-up duration of the service is 12s, the weight is 10 during warm-up, and the normal weight after warm-up is 100. If the service is published on two machines, such as machine A and B, and the machine A is in the warm-up period with the above configuration, while B has already completed warm-up, and the normal weight is 200, then when the client calls the service, the proportion of traffic distribution is 10:200. After the machine A is warmed up, the traffic distribution ratio is 100:200.\nIn SOFABoot, the warm-up duration and the weight during and after warm-up can be configured as follows:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleRestFacadeReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.endpoint.facade.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs weight=\u0026amp;quot;100\u0026amp;quot; warm-up-time=\u0026amp;quot;10000\u0026amp;quot; warm-up-weight=\u0026amp;quot;1000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/provider-warmup-weight/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b9e320dfaa4f9700ecdca67d76e07d54","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","summary":"The warm-up weight feature allows the client machine to distribute traffic based on the corresponding weight of the server. This feature is also often used in the scenario where a few machines within a cluster are being started. The server machines can be warmed up in a short time with the traffic weight function, and then continue to receive the normal traffic.\nThe operating mechanism is as follows: When the server service starts, it pushes its own warm-up duration, weight during warm-up, and normal weight after warm-up to the Service Registry.","tags":null,"title":"Warm-up weight","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","wordcount":319},{"author":null,"categories":null,"content":" X-Protocol X-Protocol is a special common protocol supported by SOFAMesh. It can access different RPC protocols in a unified manner. Because it doesn\u0026amp;rsquo;t require to parse protocols, it can not only provide higher performance, but also reduce the development cost of accessing new protocols.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-x-protocol/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"220f4a76b277463bb1f7201519950450","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","summary":"X-Protocol X-Protocol is a special common protocol supported by SOFAMesh. It can access different RPC protocols in a unified manner. Because it doesn\u0026rsquo;t require to parse protocols, it can not only provide higher performance, but also reduce the development cost of accessing new protocols.","tags":null,"title":"X-Protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","wordcount":44},{"author":null,"categories":null,"content":"X-Protocol 协议是 SOFAMesh 支持的特殊通用协议，能够以统一的方式接入不同的 RPC 协议，因为无需进行协议解析，不仅能够提供更高的性能, 更能降低接入新协议的开发成本。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-x-protocol/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"220f4a76b277463bb1f7201519950450","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","summary":"X-Protocol 协议是 SOFAMesh 支持的特殊通用协议，能够以统一的方式接入不同的 RPC 协议，因为无需进行协议解析，不仅能够提供更高的性能, 更能降低接入新协议的开发成本。","tags":null,"title":"X-Protocol","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","wordcount":70},{"author":null,"categories":null,"content":" ZooKeeper Adapter ZooKeeper Adapter is an Adapter plug-in developed in accordance with the Istio registry center extension mechanism. It is used for docking all microservices frameworks that use ZooKeeper as a registry center. Currently, ZooKeeper Adapter supports SOFARPC and will be available for Dubbo soon.\nZooKeeper Adapter uses ZooKeeper\u0026amp;rsquo;s watch mechanism to listen to the change events of service registration information, providing better real-time performance than polling.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-zookeeper-adapter/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a174a0de8dd47df7c3043f6d49fa1b07","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","summary":"ZooKeeper Adapter ZooKeeper Adapter is an Adapter plug-in developed in accordance with the Istio registry center extension mechanism. It is used for docking all microservices frameworks that use ZooKeeper as a registry center. Currently, ZooKeeper Adapter supports SOFARPC and will be available for Dubbo soon.\nZooKeeper Adapter uses ZooKeeper\u0026rsquo;s watch mechanism to listen to the change events of service registration information, providing better real-time performance than polling.","tags":null,"title":"ZooKeeper Adapter","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","wordcount":67},{"author":null,"categories":null,"content":" To use Zookeeper as service registry center, you only need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 Note: Considering the real-time nature of the service, the following features are not supported currently.\nSOFABoot RPC also provides a cache file (not supported currently), which is used for service discovery when ZooKeeper is not available. The way to configure this cache file is as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth When users need to auth the providers and consumers, they can use a auth key to write or read the dictionary normally, only when they use the same key, zookeeper server will process these requests.\nSOFARPC API Usage If you use SOFARPC API directly, you can add two parameters to registry config.\nparameters.put(\u0026amp;quot;scheme\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;); //if there was multi auth infos, you need to set the value as user1:passwd1,user2:passwd2 parameters.put(\u0026amp;quot;addAuth\u0026amp;quot;, \u0026amp;quot;sofazk:rpc1\u0026amp;quot;); registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181/authtest\u0026amp;quot;) .setParameters(parameters); then if another provider or consumer use a different auth info, they will not access these providers or consumers.\nXML Usage You only need to set it in application.properties\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry\u0026amp;amp;scheme=digest\u0026amp;amp;addAuth=sofazk:rpc1 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-zookeeper/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"71d6486c5577cc85d84c56688cdf2af1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","summary":"To use Zookeeper as service registry center, you only need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 Note: Considering the real-time nature of the service, the following features are not supported currently.\nSOFABoot RPC also provides a cache file (not supported currently), which is used for service discovery when ZooKeeper is not available. The way to configure this cache file is as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth When users need to auth the providers and consumers, they can use a auth key to write or read the dictionary normally, only when they use the same key, zookeeper server will process these requests.","tags":null,"title":"Zookeeper","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","wordcount":174},{"author":null,"categories":null,"content":"Zookeeper Adapter 是按照 Istio 注册中心扩展机制开发的一个 Adapter 插件，用于对接所有使用 Zookeeper 作为注册中心的微服务框架。目前已经支持了 SOFARPC，很快将提供对于 Dubbo 的支持。\nZookeeper Adapter 使用 zk 的 watch 机制监听服务注册信息的变化事件，提供了比轮询机制更好的实时性。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-zookeeper-adapter/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a174a0de8dd47df7c3043f6d49fa1b07","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","summary":"Zookeeper Adapter 是按照 Istio 注册中心扩展机制开发的一个 Adapter 插件，用于对接所有使用 Zookeeper 作为注册中心的微服务框架。目前已经支持了 SOFARPC，很快将提供对于 Dubbo 的支","tags":null,"title":"Zookeeper Adpater","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","wordcount":110},{"author":null,"categories":null,"content":" 在介绍 Biz 生命周期 时，我们提到了有三种方式控制 Biz 的生命周期，并且介绍了使用客户端 API 实现 Biz 的安装、卸载、激活。在这一章节我们介绍如何使用 SOFAArk 提供的动态配置插件，通过 Zookeeper 下发指令，控制 Biz 的生命周期。\n引入依赖 SOFAArk 提供了 config-ark-plugin 对接 Zookeeper 配置中心，用于运行时接受配置，达到控制 Biz 生命周期，引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;config-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置 ZK 地址 参考 SOFAArk 配置，在 SOFAArk 配置文件 conf/ark/bootstrap.properties 增加如下配置：\ncom.alipay.sofa.ark.config.address=zookeeper://ip:port 配置维度 SOFAArk 启动后，会在 ZK 注册两个节点配置，分别是宿主应用维度和 IP 维度：\n sofa-ark/${com.alipay.sofa.ark.master.biz}/ \u0026amp;gt; 宿主应用维度配置，应用启动时，会拉取该维度配置，控制相关 Biz 的部署；应用重启后，配置不会丢失\n sofa-ark/${com.alipay.sofa.ark.master.biz}/ip/ \u0026amp;gt; IP 维度配置，应用重启后丢失，通常用于运行时控制单台机器的 Biz 行为\n 通过写这两个节点的配置，可以控制相关机器和应用的 Biz 运行时状态。\n配置形式 下面介绍配置的形式，动态配置采用状态声明指令，SOFAArk 收到配置后，会根据状态描述解析出具体的指令（包括 install，uninstall, switch），指令格式如下：\nbizName:bizVersion:bizState?k1=v1\u0026amp;amp;k2=v2\n多条指令使用 ; 隔开，单条指令主要由 biz 名称，biz 版本，biz 预期状态及参数组成。简单记住一点，状态配置是描述指令推送之后，所有非宿主 Biz 的状态；\n例如当前 SOFAArk 容器部署了两个应用 A，B，版本均为 1.0，其中 A 应用为宿主应用，因为宿主应用不可卸载，因此不需要考虑宿主应用，可以简单认为当前容器的 Biz 状态声明为：\n B:1.0:Activated\n 如果此时你希望安装 C 应用，版本为 1.0，文件流地址为 urlC，那么推送指令应为：\n B:1.0:Activated;C:1.0:Activated?bizUrl=urlC\n 操作继续，如果你又希望安装安装 B 应用，版本为 2.0，文件流地址为 urlB，且希望 2.0 版本处于激活状态，那么你推送的指令应为：\n B:1.0:Deactivated;B:2.0:Actaivated?bizUrl=urlB;C:1.0:Activated\n解释下为什么是这样配置指令，因为 SOFAArk 只允许应用一个版本处于激活状态，如果存在其他版本，则应处于非激活状态；所以当希望激活 B 应用 2.0 版本时，B 应用 1.0 版本应该声明为非激活状态。另外你可能注意到了 C 应用参数 urlC 不用声明了，原因是目前只有当安装新 Biz 时，才有可能需要配置参数 bizUrl，用于指定 biz 文件流地址，其他场景下，参数的解析没有意义。\n 操作继续，如果你希望卸载 B 应用 2.0 版本，激活 B 应用 1.0 版本，卸载 C 应用，那么推送的指令声明为：\n B:1.0:Activated\n 从上面的操作描述看，在推送动态配置时，只需要声明期望的 Biz 状态即可，SOFAArk 会根据状态声明推断具体的执行指令，并尽可能保持服务的连续性，以上面最后一步操作为例，SOFAArk 推断的执行指令顺序如下： + 执行 switch 指令，激活 B 应用 1.0 版本，钝化 B 应用 2.0 版本，保证服务连续性 + 执行 uninstall 指令，卸载 B 应用 2.0 版本 + 执行 uninstall 指令，卸载 C 应用 1.0 版本\n注意事项 目前只有在安装新 Biz 时才可能使用指令参数 bizUrl，用于指定 Biz 文件流地址。文件流地址字符串是能够直接构建 URL 对象，例如 file://xxx 或者 http://xxx. 安装新 Biz 时，参数 bizUrl 不是必须的，SOFAArk 提供了扩展点：\n@Extensible public interface BizFileGenerator { File createBizFile(String bizName, String bizVersion); } 用于扩展实现，根据 biz 名称和 biz 版本返回 biz 文件。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-zk-config/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c675734b1cb5fa546f96a31d8b9e3533","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","summary":"在介绍 Biz 生命周期 时，我们提到了有三种方式控制 Biz 的生命周期，并且介绍了使用客户端 API 实现 Biz 的安装、卸载、激活。在这一章节我们介绍如何使用 SOFAArk 提供的","tags":null,"title":"Zookeeper 配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","wordcount":1160},{"author":null,"categories":null,"content":" connection_manager 用于描述 MOSN 的路由配置，通常与 proxy 配合使用。\n{ \u0026amp;quot;router_config_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;virtual_hosts\u0026amp;quot;: [ ] } router_config_name，唯一的路由配置标识，与 proxy 中配置的字段对应。 virtual_hosts，描述具体的路由规则细节。 VirtualHost { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;domains\u0026amp;quot;:[], \u0026amp;quot;routers\u0026amp;quot;:[] } name，字符串。用作 virtual host 的唯一标识。 domains，字符串数组。表示一组可以匹配到该 virtual host 的 domain，支持配置通配符。domain 的匹配优先级如下： 首先匹配精确的，如 www.foo.com。 其次匹配最长后缀的通配符，如 *.foo.com、*-bar.foo.com，其中如果一个 domain 是 foo-bar.foo.com，那么会优先匹配 *-bar.foo.com。 最后匹配任意domain的通配符 * 。 routers，一组具体的路由匹配规则。 Router { \u0026amp;quot;match\u0026amp;quot;:{}, \u0026amp;quot;route\u0026amp;quot;:{}, \u0026amp;quot;per_filter_config\u0026amp;quot;:{} } match，路由的匹配参数。 route，路由行为，描述请求将被路由的 upstream 信息。 per_filter_config，是一个 key: json 格式的 json。 其中 key 需要匹配一个 stream filter 的 type，key 对应的 json 是该 stream filter 的 config。 当配置了该字段时，对于某些 stream filter（依赖具体 filter 的实现），可以使用该字段表示的配置覆盖原有 stream filter 的配置，以此做到路由匹配级别的 stream filter 配置。 match { \u0026amp;quot;prefix\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;path\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;regex\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;headers\u0026amp;quot;: [] } 路径（path）匹配 prefix，表示路由会匹配 path 的前缀，该配置的优先级高于 path 和 regex。 如果 prefix 被配置，那么请求首先要满足 path 的前缀与 prefix 配置相符合。 path，表示路由会匹配精确的 path，该配置的优先级高于 regex。如果 path被配置，那么请求首先要满足 path 与 path 配置相符合。 regex，表示路由会按照正则匹配的方式匹配 path。如果 regex 被配置，那么请求首先要满足 path 与 regex 配置相符合。 路径匹配配置同时存在时，只有高优先级的配置会生效。 Heaer 匹配 headers，表示一组请求需要匹配的 header。请求需要满足配置中所有的 Header 配置条件才算匹配成功。 header { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;value\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;regex\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } name，表示 header 的 key。 value，表示 header 对应 key 的 value。 regex，bool 类型，如果为 true，表示 value 支持按照正则表达式的方式进行匹配。 route { \u0026amp;quot;cluster_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;metadata_match\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;retry_policy\u0026amp;quot;:{} } cluster_name，表示请求将路由到的 upstream cluster。 metadata_match，metadata，如果配置了该字段，表示该路由会基于该 metadata 去匹配 upstream cluster 的 subset 。 timeout，Duration String，表示默认情况下请求转发的超时时间。如果请求中明确指定了超时时间，那么这个配置会被忽略。 retry_policy，重试配置，表示如果请求在遇到了特定的错误时采取的重试策略，默认没有配置的情况下，表示没有重试。 retry_policy { \u0026amp;quot;retry_on\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;retry_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;num_retries\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } retry_on，bool 类型，表示是否开启重试。 retry_timeout，Duration String，表示每次重试的超时时间。当 retry_timeout 大于 route 配置的 timeout 或者请求明确指定的 timeout 时，属于无效配置。 num_retries，表示最大的重试次数。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/network-filter/connection-manager/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"88e2d06bd6137225eeebf9015b2192a2","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","summary":"connection_manager 用于描述 MOSN 的路由配置，通常与 proxy 配合使用。 { \u0026quot;router_config_name\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;virtual_hosts\u0026quot;: [ ] } router_config_name，唯一的路由配置标识，与 proxy 中配置的字段对应。 vir","tags":null,"title":"connection_manager","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","wordcount":1188},{"author":null,"categories":null,"content":"proxy 是 MOSN 最常用的 network filter，其配置格式如下。\n{ \u0026amp;quot;downstream_protocol\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;upstream_protocol\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;router_config_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;extend_config\u0026amp;quot;:{} } downstream_protocol 描述 proxy 期望收到的请求协议，在连接收到数据时，会使用此协议去解析数据包并完成转发，如果收到的数据包协议和配置不符，MOSN 会将连接断开。 upstream_protocol 描述 proxy 将以何种协议转发数据，通常情况下应该和downstream_protocol 保持一致，只有特殊的场景会进行对应协议的转换。 router_config_name 描述 proxy 的路由配置的索引，通常情况下，这个配置会和同 listener 下的 connection_manager 中配置的 router_config_name 保持一致。 extend_config 扩展配置，目前仅在 MOSN 的 XProtocol 协议中使用。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/network-filter/proxy/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b04f78179a47a64d7e209b6660bfa80f","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","summary":"proxy 是 MOSN 最常用的 network filter，其配置格式如下。 { \u0026quot;downstream_protocol\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;upstream_protocol\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;router_config_name\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;extend_config\u0026quot;:{} } downstream_protocol 描述 proxy 期望收到的请求协议，在连接收到数据时，会使用此协议去解析数据包并完成转发，","tags":null,"title":"proxy","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","wordcount":221},{"author":null,"categories":null,"content":" 打开 ACTS IDE 在 Package 视图下，右键含 @Test 注解的函数名，ACTS 功能 -\u0026amp;gt; 修改测试用例，如下图：\n编写测试数据 准备入参 根据被测的接口方法的入参（类型、顺序、数量）正确准备入参数据，简单类型包括 String、Date、Integer、Float、Double、Long、Short、Byte（包含其对应的基本类型，即 int、float 等）；复杂类型为 List、Map、Set、自定义类、Java 定义的类以及前面五者的嵌套等。\n简单入参 入参设置上右键 -\u0026amp;gt; 模版选择 -\u0026amp;gt; 简单入参选择：\n导入简单入参后，值直接在这里填写； 自上而下表示被测接口方法的第1个、第2个和第3个参数，右键可以调节顺序。\n复杂入参 如图27所示，AccountTransRequest 和 BusinessActionContext 类需要生成入参模板，一般情况下，在一键生成测试脚本时会自动生成方法的入参和返回结果的类模板，打开 ACTS IDE 可对其进行编辑，如图28。\n图28\n如果生成测试脚本时没有识别出方法的入参和返回结果模版，可先生成复杂入参和结果模版（具体操作参考 对象模型生成），然后打开 ACTS IDE 编辑器，在入参设置上右键 -\u0026amp;gt; 模版选择 -\u0026amp;gt; 复杂类型，添加后可以看到复杂对象，直接进行编辑。\nlist map 以示例2为例（Set 与此类似） 图32中，演示示例2的方法入参为 Map\u0026amp;lt;String,Object\u0026amp;gt; 类型。由于 Object 不是具体类型，如果要设置 Object 为复杂对象，则需要去编辑 YAML。例如设置 Object 为 AccountTransResult 类型，则按照如下编辑：\n图32\nenum 代码样例：\n 在 ACTS IDE 中编辑如下： 如果枚举嵌套在其他类中，则在该类的 CSV 模版中设置枚举的值为 DEBIT；\n 用例数据 YAML 中，如图37：\n interestRecoverTypeEnum: !!com.alipay.fc.loancore.common.util.enums.InterestRecoverTypeEnum \u0026#39;ALL\u0026#39; 图37\n编码方式准备入参 覆盖 prepare 方法，通过 ActsRuntimeContext 的方法，快速获取和设置用例入参，如图38所示：\n 获取所有入参：List getInputParams() 按位置获取：Object getInputParamByPos(int i) 新增用例参数：void addInputParam(Object obj) 图 38\n准备 DB 数据 准备 DB 数据-单列场景 如图39，在数据库准备设置位置右键，选择好要插入的 DB 模板（请先确保该DB模板已经生成），图中1、2、3步骤之后点击 OK 即插入 DB 准备模板，如图41，可对要插入 DB 的数据进行编辑：\n图39\n图40\n图41\n准备 DB 数据-多列场景 选中一列数据，点击复制，按此方法可复制多列数据，然后进行编辑即可：\n图42\n准备 DB 数据-flag说明 数据依赖标记：\nY: 插入 N：不插入 C：以此为where条件对插入后的数据进行清理 F：数据库函数 L: 大字段换行准备，准备方式为A=B;C=D 图43\n准备期望结果数据 生成期望结果的对象模型后，在 ACTS IDE 界面中，期望结果设置右键 -\u0026amp;gt; 模版选择，见下图。\n图44\n期望结果的 flag 说明 Y: 校验 N：不校验 D：时间偏移值比较，如 D200 ME：map 默认全 key 校验，ME则以期望 key 为准，实际值多余期望值的 key 不予校验 对于返回结果的时间 Date 类型字段校验说明： 1. Y | null -\u0026amp;gt; 代表期望为 null 2. Y | 2015-01-01 00:00:00 -\u0026amp;gt; 代表期望为 2015-01-01 00:00:00 3. N | null -\u0026amp;gt; 代表不校验 4. D200 | 2015-01-01 00:00:00/null -\u0026amp;gt; 代表与 2015-01-01 00:00:00/new Date() 相差 200 秒\n编码方式准备期望结果 覆盖 prepare 方法，通过 ActsRuntimeContext 的如下方法，快速获取和设置期望结果。 1. 获取期望结果：Object getExpectResult() 2. 设置期望结果：Boolean setExpectResult(Object objToSet)\n准备期望 DB 数据 准备期望 DB 数据-单列场景 在数据库期望设置里配置，操作参考准备 DB 数据-单列场景\n准备期望 DB 数据-多列场景 在数据库期望设置里配置，操作参考准备 DB 数据-多列场景\n期望 DB 数据的 flag 说明 数据校验标记：\nY: 校验 N：不校验 C：以此为条件 select 然后比较，如果结果有多个，则返回的结果所有记录都要和当前需要校验的数据进行校验 CN： 这个 flag 表示当前这张表中以 C 和 CN 为条件查询出的结果为空 D200：表示对比时间的时候误差 200s 之内都算通过，日期类型的格式为：today L： 数据库大字段换行数据校验，准备方式为 A=B;C=D P：DB 大字段校验，以期望结果的 kv 为基准，对 DB 大字段里的 kv 进行校验，要求 DB 里的 kv 之间是换行分隔 R：正则匹配校验 准备期望异常数据 编码方式准备期望异常数据 部分系统封装的异常类没有默认构造函数，这样通过模版添加的异常结果在加载 YAML 时会有问题（无默认构造函数无法构造当前类），需要通过代码方式，结合自定义参数编写异常脚本，如下图：\n图45\n准备自定义数据 自定义数据-用途 用户自定义的各类型数据，用于测试过程中自由使用。\n自定义数据-数据类型 数据类型可参考 入参 部分\n编码方式准备自定义数据 快速获取和设置自定义参数：\n 获取全部自定义参数：getParamMap getParamMap() 按 key 获取：Object getParamByName(String paraName) 新增自定义参数：void addOneParam(String paraName, Object paraObj) 替换自定义参数：void setParamMap(Map\u0026amp;lt;String,Object\u0026amp;gt; paramMap) 以范型方式获取自定义参数：T getParamByNameWithGeneric(String paraName) 不同数据类型编辑方式 简单类型编辑 以自定义参数设置添加简单类型数据为例。如图46，自定义参数设置右键 -\u0026amp;gt; 模板选择，弹框填写入参名字：\n图46\n图47\n选择 String 类型，在下方编辑框填写值即可，生成后也可自行编辑： ![填写值](enter-value.png) 图48\n图49\n复杂对象编辑 以自定义参数设置添加复杂对象数据为例\n参照 简单类型编辑，在弹框填 …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ide/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"697e7e6d35a2e058f3ca8b0a72032690","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-ide/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-ide/","summary":"打开 ACTS IDE 在 Package 视图下，右键含 @Test 注解的函数名，ACTS 功能 -\u0026gt; 修改测试用例，如下图： 编写测试数据 准备入参 根据被测的接口方法的入参（类型、顺序、数量","tags":null,"title":"一站式编辑","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-ide/","wordcount":2588},{"author":null,"categories":null,"content":" 快速理解 ACTS 的模型 在写测试用例的过程中，需要预先准备一些 DB 表、方法入参的数据，或者需要校验一些 DB 表、返回结果的数据，这些数据可以以模版的形式保存下来，在编辑用例时，可以方便的导入这些数据到准备数据或者校验数据，实现数据复用。目前 ACTS 模型可以分为 DB 模型和类模型。\n常规的测试用例编写，DB 、方法入参、返回结果等领域模型的数据准备是通过测试代码组织的，随着业务复杂度，领域模型复杂度也在不断增加，尤其在金融级业务用，往往一个类或者数据表有数十个属性或者字段，类与类的嵌套也是随处可见，代码构造复杂对象变得十分困难且容易疏漏，问题频现： * 表太多容易遗漏，排查时间太长； * 表的字段名记不住，时不时写错； * 接口入参数量多类型复杂，看见就头疼； * 类的属性太多，容易遗漏重要属性； * 嵌套构造对象，不断的 new 和 set 赋值； * 继承和实现关系复杂，遗漏重要属性；\nACTS 的模版有可以有效应对上述问题，通过将类和表固化为 CSV，类的结构一目了然，通过类、数据表的模版可以快速的模版化地创建对象，并序列化到 YAML 文件中，使用 ACTS IDE 可以方便的管理用例数据。\n模型存储位置 在 test 模块的 resource/model 目录可以查看已经存在的模型。\n图4\n数据表模型生成 数据表模型样例 图5\n1. 校验 flag 说明\n```plain Y: 插入 N：不插入 C：以此为 where 条件对插入后的数据进行清理 F：数据库函数 L: 大字段换行准备，准备方式为 A=B;C=D ``` 2. 用例编辑使用模型快速导入数据\n使用 ACTS IDE 编辑 DB 表数据（包括准备表数据、期望表数据）时，可右键新增指定表的模型，用于直接从表模型的 CSV 中导入表的全部字段和值，以便快速编辑。 DB 模版的使用可参考准备 DB 数据。\n生成表模型 图6\n图7\n图8\n点击 OK 后生成模板，如图9：\n图9\n同时支持不配置直连获取表结构的方式生成表模型，即在 DO 类上右键根据类生成表模型： DO 类上右击 -\u0026amp;gt; ACTS 功能 -\u0026amp;gt; 生成 DO 模型：\n图10\n![生产的模型](generated-do-model.png) 图11\n对象模型生成 对象模型样例 图12\n图13\n一个复杂对象是一个闭包，不但包含其自身模型还包含其嵌套对象的模型。\nACTS 使用模型快速导入数据、编辑复杂对象（包括入参、返回结果和异常等），在 ACTS IDE 中可右键选择类模型，用于构建该类的对象并赋值以便快速编辑。\n生成方法 有两种方式： 1.待构建模型的类定义的任意方法上点击； 1.接口定义的方法上点击，详细操作看下图示例。\n使用 IDEA 的同学请注意：请先确保代码已编译，IDEA 不会自动编译而需要手动 mvn clean install 或者打开自动编译 File -\u0026amp;gt; Settings -\u0026amp;gt; Build,Execution,Deployment -\u0026amp;gt; Compiler -\u0026amp;gt; Make project automatically。\nACTS IDE 生成对象模型 （1）待构建模型的类定义的任意方法上点击，生成当前类的模型\n图14\n（2）接口定义任意方法上点击，生成当前接口中，所有方法的复杂入参、复杂返回结果的模型\n图15\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-model/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"65aaf62462b3b0ea142ca75a5b61eb0d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-model/","summary":"快速理解 ACTS 的模型 在写测试用例的过程中，需要预先准备一些 DB 表、方法入参的数据，或者需要校验一些 DB 表、返回结果的数据，这些数据可以以模版的形式保","tags":null,"title":"一键模型化","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-model/","wordcount":1096},{"author":null,"categories":null,"content":" 快速理解 ACTS 中的脚本 如果你是一个经常编写测试用例的同学，是不是经常苦于这样的问题： * 不断的 assertEquals 写得快吐了，重复性编码毫无创意； * 少一个 assert 容易假绿，错一个败坏心情； * 场景一旦复杂，测试代码比业务代码还要长，写起来痛不欲生； * 每换一个应用，之前写的工具类就要搬一次；\n左图为 TestNG 用例，右图为 ACTS 用例，重复性代码一去不回，代码体积明显缩小。区别于普通测试脚本，ACTS 脚本继承自 ActsTestBase 类，封装了数据加载、驱动、执行引擎和校验规则，无需用户来组织清理数据、准备数据、执行用例和校验结果，对于简单业务可以做到零编码，极大释放代码编写和后期维护成本。\n测试脚本生成 前提条件：务必 mvn 编译工程和生成对象模型，否则会造成 ACTS IDE 不可预料的错误，如无法编辑、数据不正确等。\n接口定义的方法上点击，选择 ACTS 功能 -\u0026amp;gt; 生成测试用例。\n测试脚本运行 方法：右键 ACTS 脚本中的被测方法，选择 TestNG 来执行测试脚本，如下图：\n指定测试脚本运行 在 src/test/resource/config/acts-config.properties 中配置 test_only＝^T，表示只跑用例名称以 T 开头的用例，^T 也可以换成其他正则表达式；\n 修改要测试的用例名称，在用例名前面加 T，ACTS 运行时时仅执行用例名称以 T 开头的用例。\n 脚本用例拆分功能 默认每个测试脚本的所有用例数据保存在同一个 YAML 中，ACTS 支持用例数据根据开关 spilt_yaml_by_case 来决定同一测试脚本的所有用例数据存储在一个 YAML 中还是每个用例存储为一个 YAML。 开关默认为关闭，即同一测试脚本的所有测试数据存储在一个 YAML 文件中。\n在 acts-config.properities 中设置 spilt_yaml_by_case=true 即可打开开关，之后新生成测试脚本时每个用例对应一个单独的以 caseId 命名的 YAML文件，拆分的方式可以降低多人研发同一接口带来的文件冲突问题。\n此外，为了支持将老的 YAML 文件按用例拆分，ACTS 提供了工具类，如下，支持将指定脚本下，指定路径的 YAML 文件按用例拆分。\n BaseDataUtil.saveYamlDataToCaseByCase\n 注意：拆分后，建议先给原有 YAML 重命名做备份，然后打开用例编辑器检查拆分后的文件内容是否正确，确认无误后可删除原有 YAML 文件，两者不能并存。 编码方式准备数据 ACTS 提供了数据自定义 API 接口，封装于 ActsRuntimeContext 类中，如下： + 快速获取和设置自定义参数\n获取全部自定义参数：`getParamMap getParamMap()` 按 key 获取：`Object getParamByName(String paraName)` 新增自定义参数：`void addOneParam(String paraName, Object paraObj)` 替换自定义参数：`void setParamMap(Map\u0026amp;lt;String, Object\u0026amp;gt; paramMap)` 泛型方式获取自定义参数：`T getParamByNameWithGeneric(String paraName)` 快速获取和设置用例入参\n获取所有入参：List getInputParams() 按位置获取：Object getInputParamByPos(int i) 新增用例参数：void addInputParam(Object obj)\n 快速获取和设置期望结果\n获取期望结果：Object getExpectResult() 设置期望结果：Boolean setExpectResult(Object objToSet)\n Mock 功能使用 Mock 功能目前是采用 Mockito 的方案，具体资料见 Mockito 英文文档和 Mockito 中文文档\n增加依赖 在 test 模块增加如下依赖（如果已经引入 SOFABoot 的测试 starter 则无需重复引入）\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 默认 spring test 依赖的 mockito 版本是 1.x，想要升级的可以排除后再引入相应的版本\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.mockito\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mockito-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.18.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Mockito 用于测试时进行打桩处理，通过它可以指定某个类的某个方法在什么情况下返回什么样的值。Mockito 库能够 Mock 对象、验证结果以及打桩，示例如下：\n@SpringBootTest(classes = SOFABootApplication.class) @TestExecutionListeners(listeners = MockitoTestExecutionListener.class) public class RegisterUserActsTest extends ActsTestBase { @TestBean @Autowired // 这是测试类 public UserService userService; @MockBean // 这是要mock的bean public AccountManageFacadeClient accountManageFacadeClient; @Test(dataProvider = \u0026amp;quot;ActsDataProvider\u0026amp;quot;) public void registerUser (String caseId, String desc, PrepareData prepareData) { runTest(caseId, prepareData); } @Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { super.beforeActsTest(actsRuntimeContext); AccountManageResult accountManageResult = new AccountManageResult(); …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-script/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0d20739dedad1f11277bd02ed65329c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-script/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-script/","summary":"快速理解 ACTS 中的脚本 如果你是一个经常编写测试用例的同学，是不是经常苦于这样的问题： * 不断的 assertEquals 写得快吐了，重复性编码毫无创意； * 少一个 assert 容易假绿","tags":null,"title":"一键脚本化","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-script/","wordcount":1276},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 集成 Zipkin 进行数据上报展示。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n 下面的示例中将分别演示在 SOFABoot/SpringBoot 工程中 以及 非 SOFABoot/SpringBoot 工程中如何使用。\n 依赖引入 添加 SOFATracer 依赖 工程中添加 SOFATracer 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置 Zipkin 依赖 考虑到 Zipkin 的数据上报能力不是 SOFATracer 默认开启的能力，所以期望使用 SOFATracer 做数据上报时，需要添加如下的 Zipkin 数据汇报的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.zipkin2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.11.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.reporter2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin-reporter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.7.13\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置文件 在工程的 application.properties 文件下添加一个 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFATracerReportZipkin # logging path logging.path=./logs com.alipay.sofa.tracer.zipkin.enabled=true com.alipay.sofa.tracer.zipkin.baseUrl=http://localhost:9411 启动 Zipkin 服务端 启动 Zipkin 服务端用于接收 SOFATracer 汇报的链路数据，并做展示。Zipkin Server 的搭建可以参考此文档进行配置和服务端的搭建。\n运行 可以将工程导入到 IDE 中运行生成的工程里面中的 main 方法启动应用，也可以直接在该工程的根目录下运行 mvn spring-boot:run，将会在控制台中看到启动日志：\n2018-05-12 13:12:05.868 INFO 76572 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcSofaTracerFilter\u0026#39; to urls: [/*] 2018-05-12 13:12:06.543 INFO 76572 --- [ main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped \u0026amp;quot;{[/helloZipkin]}\u0026amp;quot; onto public java.util.Map\u0026amp;lt;java.lang.String, java.lang.Object\u0026amp;gt; com.alipay.sofa.tracer.examples.zipkin.controller.SampleRestController.helloZipkin(java.lang.String) 2018-05-12 13:12:07.164 INFO 76572 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 可以通过在浏览器中输入 http://localhost:8080/helloZipkin 来访问 REST 服务，结果类似如下：\n{ content: \u0026amp;quot;Hello, SOFATracer Zipkin Remote Report!\u0026amp;quot;, id: 1, success: true } 查看 Zipkin 服务端展示 打开 Zipkin 服务端界面，假设我们部署的 Zipkin 服务端的地址是 http://localhost:9411，打开 URL 并搜索 helloZipkin(由于我们本地访问的地址是 localhost:8080/helloZipkin)，可以看到展示的链路图。\nSpring 工程运行 对于一般的 Spring 工程，我们通常使用 tomcat/jetty 作为 servlet 容器来启动应用。具体工程参考 在 Spring 工程中使用 SOFATracer\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/report-to-zipkin/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d28d192386829452262116de9c32b570","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","summary":"在本文档将演示如何使用 SOFATracer 集成 Zipkin 进行数据上报展示。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 下面的示例中将分别演","tags":null,"title":"上报数据至 Zipkin","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","wordcount":661},{"author":null,"categories":null,"content":" 优雅关闭，包括两部分，一个是 RPC 框架作为客户端，一个是 RPC 框架作为服务端。\n作为服务端 作为服务端的时候，RPC 框架在关闭时，不应该直接暴力关闭。在 RPC 框架中\ncom.alipay.sofa.rpc.context.RpcRuntimeContext 在静态初始化块中，添加了一个 ShutdownHook\n// 增加jvm关闭事件 if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } 这个 ShutdownHook 的作用是当发布平台/用户执行 kill pid 的时候，会先执行 ShutdownHook 中的逻辑。在销毁操作中，RPC 框架会先执行向注册中心取消服务注册、关闭服务端口等动作。\nprivate static void destroy(boolean active) { RpcRunningState.setShuttingDown(true); for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.preDestroy(); } List\u0026amp;lt;ProviderConfig\u0026amp;gt; providerConfigs = new ArrayList\u0026amp;lt;ProviderConfig\u0026amp;gt;(); for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { providerConfigs.add(bootstrap.getProviderConfig()); } // 先反注册服务端 List\u0026amp;lt;Registry\u0026amp;gt; registries = RegistryFactory.getRegistries(); if (CommonUtils.isNotEmpty(registries) \u0026amp;amp;\u0026amp;amp; CommonUtils.isNotEmpty(providerConfigs)) { for (Registry registry : registries) { registry.batchUnRegister(providerConfigs); } } // 关闭启动的端口 ServerFactory.destroyAll(); // 关闭发布的服务 for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { bootstrap.unExport(); } // 关闭调用的服务 for (ConsumerBootstrap bootstrap : REFERRED_CONSUMER_CONFIGS) { ConsumerConfig config = bootstrap.getConsumerConfig(); if (!CommonUtils.isFalse(config.getParameter(RpcConstants.HIDDEN_KEY_DESTROY))) { // 除非不让主动unrefer bootstrap.unRefer(); } } // 关闭注册中心 RegistryFactory.destroyAll(); // 关闭客户端的一些公共资源 ClientTransportFactory.closeAll(); // 卸载模块 if (!RpcRunningState.isUnitTestMode()) { ModuleFactory.uninstallModules(); } // 卸载钩子 for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.postDestroy(); } // 清理缓存 RpcCacheManager.clearAll(); RpcRunningState.setShuttingDown(false); if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework has been release all resources {}...\u0026amp;quot;, active ? \u0026amp;quot;actively \u0026amp;quot; : \u0026amp;quot;\u0026amp;quot;); } } 其中以 bolt 为例，关闭端口并不是一个立刻执行的动作\n@Override public void destroy() { if (!started) { return; } int stopTimeout = serverConfig.getStopTimeout(); if (stopTimeout \u0026amp;gt; 0) { // 需要等待结束时间 AtomicInteger count = boltServerProcessor.processingCount; // 有正在执行的请求 或者 队列里有请求 if (count.get() \u0026amp;gt; 0 || bizThreadPool.getQueue().size() \u0026amp;gt; 0) { long start = RpcRuntimeContext.now(); if (LOGGER.isInfoEnabled()) { LOGGER.info(\u0026amp;quot;There are {} call in processing and {} call in queue, wait {} ms to end\u0026amp;quot;, count, bizThreadPool.getQueue().size(), stopTimeout); } while ((count.get() \u0026amp;gt; 0 || bizThreadPool.getQueue().size() \u0026amp;gt; 0) \u0026amp;amp;\u0026amp;amp; RpcRuntimeContext.now() - start \u0026amp;lt; stopTimeout) { // 等待返回结果 try { Thread.sleep(10); } catch (InterruptedException ignore) { } } } // 关闭前检查已有请求？ } // 关闭线程池 bizThreadPool.shutdown(); stop(); } 而是 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/graceful-shutdown/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"53af179e23ba184b01eb8234c055b15d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","summary":"优雅关闭，包括两部分，一个是 RPC 框架作为客户端，一个是 RPC 框架作为服务端。 作为服务端 作为服务端的时候，RPC 框架在关闭时，不应该直接暴力关闭。在","tags":null,"title":"优雅关闭","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","wordcount":866},{"author":null,"categories":null,"content":" 使用 CloudMesh 轻松实践 Service Mesh Demo 内容介绍 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。\nDemo内容介绍 Service Mesh 将服务间通信能力下沉到基础设施，让应用解耦并轻量化。\n但 Service Mesh 本身的复杂度依然存在，CloudMesh 通过将 Service Mesh 托管在云上，使得您可以轻松的实践 Service Mesh 技术。\n通过我们的 workshop，您可以将以多种编程语言开发的应用，简单部署到 CloudMesh 上，即可获得服务网格提供的强大能力。包括对服务进行访问，通过监控查看流量，体验服务治理、Sidecar 管理和对服务的新版本进行灰度发布等实用功能。\n本次 demo 中，我们将重点体验 CloudMesh 强大的流量控制能力。在灰度发布过程中，可以对灰度流量占比进行精准控制，并通过实时流量监控了解服务网格中流量的实际走向：\n常规的灰度发布，在灰度过程中需要占用两倍容量：\nCloud Mesh 提供的灰度发布功能，可以实现在灰度发布过程中不必占有额外的容量，而且容许在发布期间多次暂停以便修改灰度占比：\nDemo 操作指南 为了方便参加本次 demo 的同学，我们准备了整个 demo 流程的详尽的操作指南。\n更多 请 点击此处访问 在线版本。 下载本地 Demo 幻灯片。 ","date":-62135596800,"description":"使用该指南您可以快速部署应用到 CloudMesh ，对服务进行访问，通过监控查看流量，体验服务治理、Sidecar管理和对服务的新版本进行灰度发布等实用功能。","dir":"guides/kc-cloud-mesh-demo/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e389a65e6736e909718275cd76505525","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-cloud-mesh-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/guides/kc-cloud-mesh-demo/","summary":"使用 CloudMesh 轻松实践 Service Mesh Demo 内容介绍 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。 Demo内容介绍 Service Mesh 将服务间通信能力下沉到基础","tags":null,"title":"使用 CloudMesh 轻松实践 Service Mesh","type":"guides","url":"/sofastack.tech/guides/kc-cloud-mesh-demo/","wordcount":453},{"author":null,"categories":null,"content":"使用 Consul 作为服务注册中心需要添加如下依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.ecwid.consul\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;consul-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 中如下配置：\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 其中后面的值为 consul 的连接地址，如果需要设置一些其他参数，也可以通过\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;amp;b=2 进行设置\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-consul/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e6b0aa843ea0ad401c3184f6ce87649b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-consul/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-consul/","summary":"使用 Consul 作为服务注册中心需要添加如下依赖 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.ecwid.consul\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;consul-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.4.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 然后在 application.properties 中如下配置： com.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 其中后面的值为 consul 的连接地址，如果需要设置一些其他参数，也可以通过 com.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;b=2 进行","tags":null,"title":"使用 Consul 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-consul/","wordcount":72},{"author":null,"categories":null,"content":" 本文将介绍如何使用 MOSN 在 SOFAMesh 框架下搭建 Service Mesh 的开发环境，并验证 MOSN 的一些基础路由能力、负载均衡能力等。本文介绍的内容将包括 :\n MOSN 与 SOFAMesh 的关系 准备工作 源码方式部署 SOFAMesh Bookinfo 实验 MOSN 与 SOFAMesh 的关系 我们曾在 MOSN 介绍中介绍过，MOSN 是一款采用 Go 语言开发的 Service Mesh 数据平面代理。而 SOFAMesh 则是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案，MOSN 作为 SOFAMesh 的关键组件用来完成数据面的转发。\n下图是 SOFAMesh 整体框架下，MOSN 的工作示意图。\n注意：当前 MOSN 不支持在原生的 Istio 中直接使用。\n 准备工作 本文以 macOS 为例 ，其他环境可以安装对应版本的软件。\n1. 安装 hyperkit 先安装 docker-for-mac，之后安装驱动\n1.1 安装 docker 下载软件包安装，或者使用如下的命令安装。\n$ brew cask install docker 1.2 安装驱动 $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. 安装 Minikube(也可以购买商业 k8s 集群) 推荐使用 Minikube v0.28 以上来体验，请参考 https://github.com/kubernetes/minikube\n$ brew cask install minikube 3. 启动 Minikube 注意，pilot 至少需要 2G 内存，所以在启动的时候，可以通过加参数的方法给 minikube 添加分配的资源，如果你机器的资源不够，推荐使用商业版本的 k8s 集群。\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit 创建istio 命名空间\n$ kubectl create namespace istio-system 4. 安装 kubectl 命令行工具 kubectl 是用于针对 k8s 集群运行命令的命令行接口，安装参考 https://kubernetes.io/docs/tasks/tools/install-kubectl。\n$ brew install kubernetes-cli 5. 安装 Helm Helm 是一个 k8s 的包管理工具，安装参考 https://docs.helm.sh/using_helm/#installing-helm\n$ brew install kubernetes-helm 源码方式部署 SOFAMesh 1. 下载 SOFAMesh 源码 $ git clone https://github.com/sofastack/sofa-mesh.git 2. 通过 Helm 安装 SOFAMesh 使用 helm template 安装\n首先需要切换到SOFAMesh源码所在目录，然后使用Helm安装istio CRD以及各个组件\n$ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - 3. 验证安装 istio-system 命名空间下的 pod 状态都是 Running 时，说明已经部署成功。 如果仅仅是为了运行bookinfo，只需要pilot,injector,citadel这三个pods运行成功就可以满足最低要求\n$ kubectl get pods -n istio-system NAME READY STATUS RESTARTS AGE istio-citadel-6579c78cd9-w57lr 1/1 Running 0 5m istio-egressgateway-7649f76df4-zs8kw 1/1 Running 0 5m istio-galley-c77876cb6-nhczq 1/1 Running 0 5m istio-ingressgateway-5c9c8565d9-d972t 1/1 Running 0 5m istio-pilot-7485f9fb4b-xsvtm 1/1 Running 0 5m istio-policy-5766bc84b9-p2wfj 1/1 Running 0 5m istio-sidecar-injector-7f5f586bc7-2sdx6 1/1 Running 0 5m istio-statsd-prom-bridge-7f44bb5ddb-stcf6 1/1 Running 0 5m istio-telemetry-55ff8c77f4-q8d8q 1/1 Running 0 5m prometheus-84bd4b9796-nq8lg 1/1 Running 0 5m 4. 卸载安装 卸载SOFAMesh\n$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - $ kubectl delete namespace istio-system BookInfo 实验 BookInfo 是一个类似豆瓣的图书应用，它包含四个基础服务：\n Product Page：主页，由 python 开发，展示所有图书信息，它会调用 Reviews 和 Details 服务 Reviews：评论，由 java 开发，展示图书评论，会调用 Ratings 服务 Ratings：评分服务，由 nodejs …","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-with-sofamesh/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9c6461e92180417d3a8ec4f3f2c723fe","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","summary":"本文将介绍如何使用 MOSN 在 SOFAMesh 框架下搭建 Service Mesh 的开发环境，并验证 MOSN 的一些基础路由能力、负载均衡能力等。本文介绍的内容将包括 : MOSN 与 SOFAMesh 的关系 准备工作 源码","tags":null,"title":"使用 MOSN 搭建 Service Mesh 平台","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","wordcount":1654},{"author":null,"categories":null,"content":"SOFARPC 已支持使用 Nacos 作为服务注册中心。假设你已经根据 Nacos 的快速开始在本地部署好 Nacos Server，服务发现的端口默认设置在 8848。\n在 SOFARPC 中使用 Nacos 作为服务注册中心只需要在 application.properties 中加入如下配置即可：\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 如果你直接使用了 SOFARPC，而不是 SOFABoot，需要手动添加 nacos 的依赖，其中 version 为用户想使用的 version。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba.nacos\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;nacos-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 当前支持 Nacos 的版本： - SOFARPC：5.5.0 支持 Nacos 服务端版本 0.6.0，SOFABoot: 2.5.3。 - SOFARPC：5.6.0 支持 Nacos 服务端版本 1.0.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-nacos/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cc161f22cd2145fe309e63087581adc1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-nacos/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-nacos/","summary":"SOFARPC 已支持使用 Nacos 作为服务注册中心。假设你已经根据 Nacos 的快速开始在本地部署好 Nacos Server，服务发现的端口默认设置在 8848。 在 SOFARPC 中使用 Nacos 作为服务","tags":null,"title":"使用 Nacos 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-nacos/","wordcount":232},{"author":null,"categories":null,"content":"SOFARPC 已支持使用 SOFARegistry 作为服务注册中心。假设你已经根据 SOFARegistry 的快速开始在本地部署好 SOFARegistry Server，服务发现的端口默认设置在 9603。\n在 SOFARPC 中使用 SOFARegistry 作为服务注册中心首先要添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.2.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 中加入如下配置即可：\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 当前支持 SOFARegistry 的版本：\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\n由于本次发布的时间问题，暂时需要用户指定SOFARPC Starter的版本\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFARPC 集成验证 SOFARegistry 服务端版本：5.2.0\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-sofa/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"65085018ce2b2b2ef452993bb79a69de","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-sofa/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-sofa/","summary":"SOFARPC 已支持使用 SOFARegistry 作为服务注册中心。假设你已经根据 SOFARegistry 的快速开始在本地部署好 SOFARegistry Server，服务发现的端口默认设置在 9603。 在 SOFARPC 中使用 SOFARegistry 作为服务","tags":null,"title":"使用 SOFARegistry 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-sofa/","wordcount":182},{"author":null,"categories":null,"content":" 使用 SOFAStack 快速构建微服务 前置条件 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n [必选]部署注册中心：https://www.sofastack.tech/projects/sofa-registry/server-quick-start/ [必须]部署数据库：本地自行搭建数据库，然后导入 DDL.sql [可选]部署 LookoutServer：https://www.sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/ [可选]部署 Zipkin：https://zipkin.io/pages/quickstart.html 实验内容 本实验基于 SOFAStack 快速构建一个微服务，主要包括以下几个部分：\n 使用 SOFABoot + SOFARPC 发布服务 使用 SOFABoot + SOFARPC 调用服务 通过 ZipKin 查看 SOFATracer 上报的 Tracer 信息 通过 SOFALookout 查看上报的 Metrics 信息 架构图 任务 1、任务准备 从 github 上将 demo 工程克隆到本地\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git 然后将工程导入到 IDEA 或者 eclipse。导入之后界面如下：\n balance-mng：余额管理系统，提供扣减余额服务 stock-mng：库存管理系统，提供扣减库存服务 2、引入依赖 将下面的依赖引入到 balance-mng 和 stock-mng 工程模块的 pom.xml 文件中。\n\u0026amp;lt;!--SOFARPC 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFATracer 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFARegistry 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--runtime 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFALookout 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; balance-mng 工程需要将依赖引入 balance-mng/balance-mng-impl/pom.xml 文件：\nstock-mng 工程直接将依赖引入 stock-mng/pom.xml 文件：\n3、添加配置 将如下配置复制到 balance-mng 和 stock-mng 工程模块的 application.properties 中。\n# 1、添加服务注册中心地址 com.alipay.sofa.rpc.registry.address=sofa://localhost:9603 # 2、添加 tracer 数据上报的服务端 zipkin 地址 # 如果上面前置条件未搭建 tracer，可以不配置 com.alipay.sofa.tracer.zipkin.base-url=http://localhost:9411 # 3、添加 metrics 数据上报的服务端地址 # 如果上面前置条件未搭建 lookout-server，可以不配置 com.alipay.sofa.lookout.agent-host-address=localhost balance-mng 工程需要将配置添加至 balance-mng/balance-mng-bootstrap/src/main/resources/application.properties 文件：\n另外数据库配置修改为自己的数据库信息：\n# database config spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://localhost:3306/stock_db spring.datasource.username=root spring.datasource.password=root stock-mng 工程需要将配置添加至 stock-mng/src/main/resources/application.properties 文件：\n另外数据库配置修改为自己的数据库信息：\n# database config spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://localhost:3306/stock_db spring.datasource.username=root spring.datasource.password=root 4、修改 unique id 由于所有人共用一套服务发现，为区分不同用户发布的服务，需要为服务增加 unique id。\nKubeCon workshop 会给每个用户准备一个 SOFAStack 账号，格式为 user0@sofastack.io 到 user99@sofastack.io，去掉 @sofastack.io 部分，账户前半部分的 user0 至 user99 即可作为 unique id。\n 注意：balance-mng 和 stock-mng 里的 unique id 需要一致。 …","date":-62135596800,"description":"本指南将基于 SOFAStack 快速构建一个微服务。","dir":"guides/sofastack-quick-start/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"78bfd4806a86dc15ac86eee16fb85c82","permalink":"https://sofastack.github.io/sofastack.tech/guides/sofastack-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/sofastack-quick-start/","summary":"使用 SOFAStack 快速构建微服务 前置条件 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 [必选]部署注册中心：https://ww","tags":null,"title":"使用 SOFAStack 快速构建微服务","type":"guides","url":"/sofastack.tech/guides/sofastack-quick-start/","wordcount":1486},{"author":null,"categories":null,"content":" 使用 Seata 保障支付一致性 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n在开始该 demo 之前先完成《使用 SOFAStack 快速构建微服务》，如果没有完成，可以基于仓库里的 kc-sofastack-demo 工程为基线完成下面的 demo，该 demo 是在它基础上加上 Seata 分布式事务。但该 demo 不是只能应用于 SOFA，可以适用于任何 java 技术栈应用。\nAT 模式 1、引入 maven 依赖 将下面的依赖引入到父工程的 pom 文件中（kc-sofastack-demo/pom.xml）:\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;seata.version\u0026amp;gt;0.6.1\u0026amp;lt;/seata.version\u0026amp;gt; \u0026amp;lt;netty4.version\u0026amp;gt;4.1.24.Final\u0026amp;lt;/netty4.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; \u0026amp;lt;dependencyManagement\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;javax.servlet\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;servlet-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${netty4.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; \u0026amp;lt;/dependencyManagement\u0026amp;gt; 将下面的依赖引入到 stock-mng 工程的 pom 文件中（kc-sofastack-demo/stock-mng/pom.xml）:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 将下面的依赖引入到 balance-mng-impl 工程的 pom 文件中（kc-sofastack-demo/balance-mng/balance-mng-impl/pom.xml）:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 2、使用 Seata 的 DataSourceProxy 代理实际的数据源，并配置 GlobalTransactionScanner 扫描@GlobalTransaction 注解 将下面的 java 代码段加到 BalanceMngApplication 和 StockMngApplication 类的 main 方法下面:\nimport io.seata.rm.datasource.DataSourceProxy; import io.seata.spring.annotation.GlobalTransactionScanner; public static void main(String[] args) { SpringApplication.run(BalanceMngApplication.class, args); } @Configuration public static class DataSourceConfig { @Bean @Primary @ConfigurationProperties(prefix = \u0026amp;quot;spring.datasource.hikari\u0026amp;quot;) public DataSource dataSource(DataSourceProperties properties) { HikariDataSource dataSource = createDataSource(properties, HikariDataSource.class); if (properties.getName()!=null \u0026amp;amp;\u0026amp;amp; properties.getName().length() \u0026amp;gt; 0) { dataSource.setPoolName(properties.getName()); } return new DataSourceProxy(dataSource); } @SuppressWarnings(\u0026amp;quot;unchecked\u0026amp;quot;) protected …","date":-62135596800,"description":"该指南将向您展示如何使用开源分布式事务框架 Seata 的 AT 模式、TCC 模式解决业务数据的最终一致性问题。 ","dir":"guides/kc-seata-demo/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"60071a0eb44bf0901fb187eefd63ccdb","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-seata-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/guides/kc-seata-demo/","summary":"使用 Seata 保障支付一致性 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 在开始该 demo 之前先完成《使用 SOFAStack 快速构建微服务》，如果","tags":null,"title":"使用 Seata 保障支付一致性","type":"guides","url":"/sofastack.tech/guides/kc-seata-demo/","wordcount":2320},{"author":null,"categories":null,"content":" 使用 Zookeeper 作为服务注册中心只需要在 application.properties 中如下配置即可：\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 注意：考虑掉服务的实时性，以下特性暂不支持\nSOFABoot RPC 也提供一个缓存文件(目前暂不支持)，当 Zookeeper 不可用时，使用该缓存文件进行服务发现。配置该缓存文件的方式如下：\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth 支持 当用户需要对发布和消费服务，进行权限认证的时候，可以通过在操作 zookeeper 时，指定对应的目录和账号密码来进行读写。这样只有使用了相同密码的 服务方或者消费方才能进行读写。\nSOFARPC API 支持 在构造注册中心的时候，将Auth添加上\nparameters.put(\u0026amp;quot;scheme\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;); //如果存在多个认证信息，则在参数形式为为user1:passwd1,user2:passwd2 parameters.put(\u0026amp;quot;addAuth\u0026amp;quot;, \u0026amp;quot;sofazk:rpc1\u0026amp;quot;); registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181/authtest\u0026amp;quot;) .setParameters(parameters); 之后其他没有使用正确auth的，将无法访问authtest目录\nXML 方式支持 如下使用即可\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry\u0026amp;amp;scheme=digest\u0026amp;amp;addAuth=sofazk:rpc1 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-zookeeper/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"71d6486c5577cc85d84c56688cdf2af1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","summary":"使用 Zookeeper 作为服务注册中心只需要在 application.properties 中如下配置即可： com.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 注意：考虑掉服务的实时性，以下特性暂不支持 SOFABoot RPC 也提供一个缓存文件(目前暂不支持)，当 Zookeeper 不可","tags":null,"title":"使用 Zookeeper 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","wordcount":309},{"author":null,"categories":null,"content":"使用本地文件作为服务注册中心在 application.properties 中如下配置即可：\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg 其中 /home/admin/registry/localRegistry.reg 就是使用的本地文件的目录。\n对于 windows 用户，则以上地址类似：\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-local/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"33bc89393392e21b3917f090313c0df5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-local/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-local/","summary":"使用本地文件作为服务注册中心在 application.properties 中如下配置即可： com.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg 其中 /home/admin/registry/localRegistry.reg 就是使用的本地文件的目录。 对于 windows 用户，则以上地址类似： com.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg","tags":null,"title":"使用本地文件作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-local/","wordcount":56},{"author":null,"categories":null,"content":" SOFABoot 是在 Spring Boot 的基础上提供的功能扩展。基于 Spring Boot 的机制，SOFABoot 管理了 SOFA 中间件的依赖，并且提供了 Spring Boot 的 Starter，方便用户在 Spring Boot 中使用 SOFA 中间件。\nSOFABoot 依赖管理 \u0026amp;ndash; Maven 在使用 SOFA 中间件之前，需要引入 SOFABoot 依赖管理。类似 Spring Boot 引入方式，在工程中增加如下 \u0026amp;lt;parent/\u0026amp;gt; 标签配置的方式:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 其中 ${sofa.boot.version} 为具体的 SOFABoot 版本，参考发布历史。\nSOFABoot 依赖管理 \u0026amp;ndash; Gradle 从 SOFABoot 3.1.1 版本开始，SOFABoot 开始支持使用 Gradle 来进行依赖管理，如果要使用 Gradle 来进行依赖管理，需要按照如下的形式来配置 build.gradle：\nbuildscript { ext { sofaBootVersion = \u0026#39;3.1.1\u0026#39; } repositories { mavenLocal() mavenCentral() } dependencies { classpath(\u0026amp;quot;com.alipay.sofa:sofa-boot-gradle-plugin:${sofaBootVersion}\u0026amp;quot;) } } apply plugin: \u0026#39;java\u0026#39; apply plugin: \u0026#39;eclipse\u0026#39; apply plugin: \u0026#39;com.alipay.sofa.boot\u0026#39; apply plugin: \u0026#39;io.spring.dependency-management\u0026#39; group = \u0026#39;com.example\u0026#39; version = \u0026#39;0.0.1-SNAPSHOT\u0026#39; sourceCompatibility = 1.8 repositories { mavenLocal() mavenCentral() } dependencies { implementation(\u0026#39;com.alipay.sofa:rpc-sofa-boot-starter\u0026#39;) implementation(\u0026#39;org.springframework.boot:spring-boot-starter\u0026#39;) testImplementation(\u0026#39;org.springframework.boot:spring-boot-starter-test\u0026#39;) } 主要有几个步骤：\n 添加 buildScript，增加 sofa-boot-gradle-plugin 的依赖，其中版本号为你使用的 SOFABoot 的版本。 添加两个 plugin，分别是 com.alipay.sofa.boot 和 io.spring.dependency-management。 这样，在 dependencies 里面，就可以直接添加 SOFABoot 管理的各种中间件和依赖了，而不用声明版本号。\n引入 SOFA 中间件 SOFABoot 使用一系列后缀为 -sofa-boot-starter 来标示一个中间件组件，如果想要使用某个中间件，直接添加对应的依赖即可。例如，如果期望使用 SOFARPC，只需增加下面的 Maven 依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 注意上面的 Maven 依赖中并没有声明版本，这个是因为版本已经在 sofaboot-dependencies 里面声明好。这样做的好处是对于 SOFA 中间件，用户统一进行升级即可，不需要单独升级一个中间件的版本，防止出现依赖冲突以及兼容性的问题。目前管控的 SOFABoot 中间件列表如下:\n 中间件 starter SOFARPC rpc-sofa-boot-starter SOFATracer tracer-sofa-boot-starter SOFALookout lookout-sofa-boot-starter 引入 SOFABoot 扩展组件 SOFABoot 基于 Spring Boot 提供了健康检查，模块隔离，类隔离等扩展能力。遵循 Spring Boot 依赖即服务的理念，添加相关组件依赖之后，扩展能力即可生效。目前提供的扩展组件如下：\n 扩展组件 starter 健康检查 actuator-sofa-boot-starter 模块化隔离 isle-sofa-boot-starter 类隔离 sofa-ark-springboot-starter 测试扩展 test-sofa-boot-starter 引入 SOFA 中间件 ark 插件 SOFABoot 提供了类隔离组件 SOFAArk，借助 SOFAArk 容器，用户可以将依赖冲突的三方包打包成 ark 插件。运行时，ark 插件使用单独的类加载器加载，可以和其他 ark 插件以及业务依赖隔离，解决类冲突问题。SOFABoot 官方提供了 SOFARPC 和 SOFATracer 的 ark 插件，例如在应用中引入 SOFARPC ark 插件依赖替代 SOFARPC starter，从而隔离应用和 SOFARPC 及其间接依赖。目前管控的 ark 插件列表如下:\n Ark插件 plugin SOFARPC rpc-sofa-boot-plugin SOFATracer tracer-sofa-boot-plugin 引入 SOFABoot 命名空间 使用 SOFA 中间件时，需要在 XML 中根据中间件的具体使用方式添加相应的配置，这个时候需要引入 SOFABoot 的命名空间 xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; 以能够正确解析相应的配置标签，示例：\n\u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/dependency-management/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dabdbd425f20dee4d7ab580d43574456","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/dependency-management/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/dependency-management/","summary":"SOFABoot 是在 Spring Boot 的基础上提供的功能扩展。基于 Spring Boot 的机制，SOFABoot 管理了 SOFA 中间件的依赖，并且提供了 Spring Boot 的 Starter，方便用户在 Spring Boot 中使用","tags":null,"title":"依赖管理","type":"projects","url":"/sofastack.tech/projects/sofa-boot/dependency-management/","wordcount":981},{"author":null,"categories":null,"content":"SOFARPC 使用了一些三方开源组件，他们分别是：\n一些主要依赖：\n Netty under Apache License 2.0 SLF4j under the MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 一些扩展依赖：\n protobuf under New BSD License Snappy under Apache License 2.0 dubbo under Apache License 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b6c87388d5c1462f13d92012639a08b2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/notice/","summary":"SOFARPC 使用了一些三方开源组件，他们分别是： 一些主要依赖： Netty under Apache License 2.0 SLF4j under the MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 一些扩展依赖： protobuf under New BSD License","tags":null,"title":"依赖组件版权说明","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/notice/","wordcount":87},{"author":null,"categories":null,"content":" SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 的能力。如果你需要使用 SOFA 中间件，那么建议使用 SOFABoot 的健康检查能力的扩展，来更优雅的上线应用实例\n引入健康检查扩展 要引入 SOFABoot 的健康检查能力的扩展，只需要引入以下的 Starter 即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 如果不引入 SOFABoot 的健康检查扩展，用户依然可以直接依赖 HealthIndicator 接口进行原生的 Spring Boot Actuator 的 Liveness Check。\n安全提醒 从 SOFABoot 2.3.0 开始，由于健康检查能力依赖于 SpringBoot 1.4.x 里的 Actuator 组件，而 Actuator 会默认开启很多 EndPoint，例如 /dump，/trace 等等，可能存在安全风险，可以参照官方文档里的安全建议进行设置。\n SpringBoot 1.5.x 和 SpringBoot 2.x 已修复了部分安全行为，SOFABoot 将通过升级 SpringBoot 内核进行支持。\n 查看健康检查结果 加入健康检查扩展之后，我们可以直接在浏览器中输入 http://localhost:8080/health/readiness 来查看 Readiness Check 的结果。如果要查看 Liveness Check 的结果，可以直接查看 Spring Boot 的健康检查的 URL http://localhost:8080/health。\n除了通过 URL 来查看健康检查的结果之外，在 SOFABoot 中，还可以通过查看具体的日志来确定健康检查的结果，日志的目录位于 health-check 目录下，日志的内容大概如下：\n2018-04-06 23:29:50,240 INFO main - Readiness check result: success 目前 SOFA 中间件已经通过 SOFABoot 的 Readiness Check 的能力来控制了上游流量的进入，但是一个应用的流量可能并不是全部都是从中间件进入的，比较常见的还有从负载均衡器进入的，为了控制从负载均衡器进入的流量，建议使用者通过 PAAS 来访问 Readiness Check 的结果，根据结果来控制是否要在负载均衡器中上线对应的节点。\n注: 自 SOFABoot 2.x 之后，不再间接引入 spring-boot-starter-web 依赖，如果需要在浏览器中查看健康检查结果，需要额外在工程中引入 web 容器依赖。\n注: 在 SOFABoot 3.x 中调整了 endpoint 路径，health/readiness 更改为 actuator/readiness\n扩展 Readiness Check 能力 在 Readiness Check 的各个阶段，SOFABoot 都提供了扩展的能力，应用可以根据自己的需要进行扩展，在 2.x 版本中，可供扩展的点如下：\n 回调接口 说明 org.springframework.context.ApplicationListener 如果想要在 Readiness Check 之前做一些事情，那么监听这个 Listener 的 SofaBootBeforeHealthCheckEvent 事件。 org.springframework.boot.actuate.health.HealthIndicator 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 com.alipay.sofa.healthcheck.startup.SofaBootAfterReadinessCheckCallback 如果想要在 Readiness Check 之后做一些事情，那么可以扩展 SOFABoot 的这个接口。 在 3.x 版本中，可供扩展点如下：\n 回调接口 说明 com.alipay.sofa.healthcheck.core.HealthChecker 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，可以直接扩展该接口。相较于 Spring Boot 本身的 HealthIndicator 接口，该接口提供了一些额外的参数配置，比如检查失败重试次数等。 org.springframework.boot.actuate.health.HealthIndicator 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 org.springframework.boot.actuate.health.ReactiveHealthIndicator 在 WebFlux 中，如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 com.alipay.sofa.healthcheck.startup.ReadinessCheckCallback 如果想要在 Readiness Check 之后做一些事情，那么可以扩展 SOFABoot 的这个接口。 需要指出的是，上述四个扩展接口均可以通过 Spring Boot 标准的 Ordered, PriorityOrdered 和注解 @Order 实现执行顺序的设置。\nReadiness Check 配置项 应用在引入 SOFABoot 的健康检查扩展之后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 Readiness Check 的相关行为。\n Readiness Check 配置项 说明 默认值 开始支持版本 com.alipay.sofa.healthcheck.skip.all 是否跳过整个 Readiness Check 阶段 false 2.4.0 com.alipay.sofa.healthcheck.skip.component 是否跳过 SOFA 中间件的 Readiness Check false 2.4.0 com.alipay.sofa.healthcheck.skip.indicator 是否跳过 HealthIndicator 的 Readiness Check false 2.4.0 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/health-check/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a366b25125fa4aedb08a9cef572db1c8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/health-check/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/health-check/","summary":"SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 的能力。如果你需要使用 SOFA 中间件，那么建议使用 SOFABoot 的健康检查能力的扩展，来更优雅的上线应用实例 引入健康检查扩展 要","tags":null,"title":"健康检查","type":"projects","url":"/sofastack.tech/projects/sofa-boot/health-check/","wordcount":1269},{"author":null,"categories":null,"content":" 目前默认生效的的扩展模块是：lookout-ext-jvm，lookout-ext-os(from v1.5.0)。\n JVM 线程 metric name metric tags specification jvm.threads.totalStarted \u0026amp;mdash; jvm.threads.active \u0026amp;mdash; jvm.threads.peak \u0026amp;mdash; jvm.threads.daemon \u0026amp;mdash; JVM 类加载 metric name metric tags specification jvm.classes.unloaded \u0026amp;mdash; jvm.classes.loaded \u0026amp;mdash; jvm.classes.total \u0026amp;mdash; JVM 内存 metric name metric tags specification jvm.memory.heap.init \u0026amp;mdash; jvm.memory.heap.used \u0026amp;mdash; jvm.memory.heap.max \u0026amp;mdash; jvm.memory.heap.committed \u0026amp;mdash; JVM 垃圾回收 metric name metric tags specification jvm.gc.young.time \u0026amp;mdash; jvm.gc.young.count \u0026amp;mdash; jvm.gc.old.time \u0026amp;mdash; jvm.gc.old.count \u0026amp;mdash; 机器文件系统信息 metric name metric tags specification instance.file.system.free.space root（文件系统根目录名） \u0026amp;mdash; instance.file.system.total.space root \u0026amp;mdash; instance.file.system.usabe.space root \u0026amp;mdash; 机器信息 metric name metric tags specification instance.mem.free \u0026amp;mdash; instance.mem.total \u0026amp;mdash; instance.processors \u0026amp;mdash; instance.uptime \u0026amp;mdash; instance.systemload.average \u0026amp;mdash; Linux 操作系统信息 （1.5.0版本之后默认启用） metric name metric tags specification os.systemload.average.1min \u0026amp;mdash; os.systemload.average.5min \u0026amp;mdash; os.systemload.average.15min \u0026amp;mdash; os.cpu.idle \u0026amp;mdash; os.cpu.iowait \u0026amp;mdash; os.cpu.irq \u0026amp;mdash; os.cpu.nice \u0026amp;mdash; os.cpu.softirq \u0026amp;mdash; os.cpu.system \u0026amp;mdash; os.cpu.user \u0026amp;mdash; os.disk.usage.percent.used device,root,type \u0026amp;mdash; os.disk.usage.total.bytes device,root,type \u0026amp;mdash; os.disk.usage.used.bytes device,root,type \u0026amp;mdash; os.net.stats.in.bytes intfc \u0026amp;mdash; os.net.stats.in.compressed intfc \u0026amp;mdash; os.net.stats.in.dropped intfc \u0026amp;mdash; os.net.stats.in.errs intfc \u0026amp;mdash; os.net.stats.in.fifo.errs intfc \u0026amp;mdash; os.net.stats.in.frame.errs intfc \u0026amp;mdash; os.net.stats.in.multicast intfc \u0026amp;mdash; os.net.stats.in.packets intfc \u0026amp;mdash; os.net.stats.out.bytes intfc \u0026amp;mdash; os.net.stats.out.carrier.errs intfc \u0026amp;mdash; os.net.stats.out.collisions intfc \u0026amp;mdash; os.net.stats.out.compressed intfc \u0026amp;mdash; os.net.stats.out.dropped intfc \u0026amp;mdash; os.net.stats.out.errs intfc \u0026amp;mdash; os.net.stats.out.fifo.errs intfc \u0026amp;mdash; os.net.stats.out.packets intfc \u0026amp;mdash; os.memory.stats.buffers.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.cached.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.free.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.total.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-ext-metrics/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c8a4fb3d904e359e99db9d4e81e60812","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","summary":"目前默认生效的的扩展模块是：lookout-ext-jvm，lookout-ext-os(from v1.5.0)。 JVM 线程 metric name metric tags specification jvm.threads.totalStarted \u0026mdash; jvm.threads.active \u0026mdash; jvm.threads.peak","tags":null,"title":"内置扩展 Metrics 指标","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","wordcount":296},{"author":null,"categories":null,"content":" 分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等） Zab：被应用在 zookeeper 中，业界使用广泛，但没有抽象成通用的 library Raft：以容易理解著称，业界也涌现出很多 raft 实现，比如大名鼎鼎的 etcd, braft, tikv 等 什么是 Raft？ Raft 是一种更易于理解的分布式共识算法，核心协议本质上还是师承 paxos 的精髓，不同的是依靠 raft 模块化的拆分以及更加简化的设计，raft 协议相对更容易实现。\n模块化的拆分主要体现在：Raft 把一致性协议划分为 Leader 选举、MemberShip 变更、日志复制、Snapshot 等几个几乎完全解耦的模块\n更加简化的设计则体现在：Raft 不允许类似 paxos 中的乱序提交、简化系统中的角色状态（只有 Leader、Follower、Candidate三种角色）、限制仅 Leader 可写入、使用随机化的超时时间来设计 Leader Election 等等\n特点：Strong Leader 系统中必须存在且同一时刻只能有一个 leader，只有 leader 可以接受 clients 发过来的请求 Leader 负责主动与所有 followers 通信，负责将\u0026amp;rsquo;提案\u0026amp;rsquo;发送给所有 followers，同时收集多数派的 followers 应答 Leader 还需向所有 followers 主动发送心跳维持领导地位(保持存在感) 一句话总结 Strong Leader: \u0026amp;ldquo;你们不要 BB! 按我说的做，做完了向我汇报!\u0026amp;rdquo; 另外，身为 leader 必须保持一直 BB(heartbeat) 的状态，否则就会有别人跳出来想要 BB\n复制状态机 对于一个无限增长的序列 a[1, 2, 3…]，如果对于任意整数 i，a[i] 的值满足分布式一致性，这个系统就满足一致性状态机的要求 基本上所有的真实系统都会有源源不断的操作，这时候单独对某个特定的值达成一致显然是不够的。为了让真实系统保证所有的副本的一致性，通常会把操作转化为 write-ahead-log(WAL)。然后让系统中所有副本对 WAL 保持一致，这样每个副本按照顺序执行 WAL 里的操作，就能保证最终的状态是一致的\n Client 向 leader 发送写请求 Leader 把\u0026amp;rsquo;操作\u0026amp;rsquo;转化为 WAL 写本地 log 的同时也将 log 复制到所有 followers Leader 收到多数派应答, 将 log 对应的\u0026amp;rsquo;操作\u0026amp;rsquo; 应用到状态机 回复 client 处理结果 Raft 中的基本概念 Raft-node 的 3 种角色/状态 Follower：完全被动，不能发送任何请求，只接受并响应来自 leader 和 candidate 的 message，每个节点启动后的初始状态一定是 follower Leader：处理所有来自客户端的请求，以及复制 log 到所有 followers Candidate：用来竞选一个新 leader （candidate 由 follower 触发超时而来） Message 的 3 种类型 RequestVote RPC：由 candidate 发出，用于发送投票请求 AppendEntries (Heartbeat) RPC：由 leader 发出，用于 leader 向 followers 复制日志条目，也会用作 Heartbeat （日志条目为空即为 Heartbeat） InstallSnapshot RPC：由 leader 发出，用于快照传输，虽然多数情况都是每个服务器独立创建快照，但是leader 有时候必须发送快照给一些落后太多的 follower，这通常发生在 leader 已经丢弃了下一条要发给该follower 的日志条目(Log Compaction 时清除掉了) 的情况下 任期逻辑时钟 时间被划分为一个个任期 (term)，term id 按时间轴单调递增 每一个任期的开始都是 leader 选举，选举成功之后，leader 在任期内管理整个集群，也就是 \u0026amp;lsquo;选举 + 常规操作\u0026amp;rsquo; 每个任期最多一个 leader，可能没有 leader (spilt-vote 导致) Raft 功能分解 Leader 选举 超时驱动：Heartbeat/Election timeout 随机的超时时间：降低选举碰撞导致选票被瓜分的概率 选举流程： Follower \u0026amp;ndash;\u0026amp;gt; Candidate (选举超时触发) 赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Leader 另一个节点赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Follower 一段时间内没有任何节点器赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Candidate 选举动作： Current term++ 发送 RequestVote RPC New Leader 选取原则 (最大提交原则) Candidates include log info in RequestVote RPCs(index \u0026amp;amp; term of last log entry) During elections, choose candidate with log most likely to contain all committed entries Voting server V denies vote if its log is “more complete”: (lastTermV \u0026amp;gt; lastTermC) || ((lastTermV == lastTermC) \u0026amp;amp;\u0026amp;amp; (lastIndexV \u0026amp;gt; lastIndexC)) Leader will have “most complete” log among electing majority 安全性：一个 term，最多选出一个 leader，可以没 leader，下一个 term 再选 影响 raft 选举成功率的几个时间参数： RTT(Round Trip Time)：网络延时 Heartbeat timeout：心跳间隔，通常应该比 election timeout 小一个数量级，目的是让 leader 能够持续发送心跳来阻止 followers 触发选举 Election timeout：Leader 与 followers …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/consistency-raft-jraft/","fuzzywordcount":8000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a0e98df1bec305cca7db6fc34fc97771","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":16,"relpermalink":"/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","summary":"分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? P","tags":null,"title":"分布式一致性 Raft 与 JRaft","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","wordcount":7950},{"author":"林楠","categories":"SOFAStack","content":" 前言 在实践中，我们通常会使用业务功能模块化的开发模式，部署时将不同模块合并部署，由于团队间技术栈不统一，此时就有可能出现依赖冲突等问题。SOFAArk 定义了一种开发规范，将不同的应用模块打包成 Ark Biz，由一个基座 Biz 和多个 Biz 模块组成部署包，支持两种合并部署的方式，一种是静态合并部署，Ark Biz 以 Maven 依赖的方式引入项目；另一种是在运行时使用 API 或者 配置中心（Zookeeper）动态地安装或卸载 Biz，本文将重点讨论此方式。\nArk Biz 的生命周期 Ark Biz 的生命周期主要包含三条指令：\n install: 安装 Biz uninstall: 卸载 Biz switch: 激活 Biz 在动态的安装和卸载时，Ark Biz 会流转于生命周期的五个阶段，Biz 在不同阶段时的状态如下：\n unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时 Biz 包还没有安装或者安装中 activated: Biz 包启动完成，且处于激活状态，可以对外提供服务 broken: Biz 包启动失败后状态 deactivated: Biz 包启动完成，但处于未激活状态(注意这个状态只对 JVM 服务生效，对 RPC 等其他中间件无效) 这里我们可以看一下 Ark Biz 的数据模型 BizModel 类：\npublic class BizModel implements Biz { ... private String bizName; private String bizVersion; private BizState bizState; ... } 在 Ark Biz 的数据模型中 bizState 表示的就是当前状态，可以看到数据模型中定义了 Biz 包的名称和版本号，在运行时 SOFAArk 允许部署相同名称不同版本的 Biz，但只能有一个版本处于 activated 激活状态，其他版本的 Biz 状态将自动处于 deactivated 未激活状态。\ninstall 在入口方法 ArkClient#installOperation 中，下载 Biz 包到本地临时文件，临时文件命名规则：${bizName}-${bizVersion}-${时间戳}。准备好 Biz 包后，调用 installBiz 方法，进入安装主流程。\npublic static ClientResponse installOperation(BizOperation bizOperation) throws Throwable { return installOperation(bizOperation, arguments); } public static ClientResponse installOperation(BizOperation bizOperation, String[] args) throws Throwable { ... if (bizOperation.getParameters().get(Constants.CONFIG_BIZ_URL) != null) { URL url = new URL(bizOperation.getParameters().get(Constants.CONFIG_BIZ_URL)); bizFile = ArkClient.createBizSaveFile(bizOperation.getBizName(), bizOperation.getBizVersion()); FileUtils.copyInputStreamToFile(url.openStream(), bizFile); } return installBiz(bizFile, args); } 安装 Ark Biz 的主流程：\n 解析 Biz 包，创建 BizModel 将 Ark Biz 注册到 Biz Manager 中（如果已经注册过，安装流程将直接结束，并返回提示信息） 启动 Ark Biz 如果启动失败，则关停并卸载 Ark Biz public static ClientResponse installBiz(File bizFile, String[] args) throws Throwable { ... Biz biz = bizFactoryService.createBiz(bizFile); // 1 ClientResponse response = new ClientResponse(); if (bizManagerService.getBizByIdentity(biz.getIdentity()) != null || !bizManagerService.registerBiz(biz)) { // 2 return response.setCode(ResponseCode.REPEAT_BIZ).setMessage( String.format(\u0026amp;quot;Biz: %s has been installed or registered.\u0026amp;quot;, biz.getIdentity())); } try { biz.start(args); // 3 ... response .setCode(ResponseCode.SUCCESS) .setMessage( String.format(\u0026amp;quot;Install Biz: %s success, cost: %s ms, started at: %s\u0026amp;quot;, biz.getIdentity(), end - start, startDate)) .setBizInfos(Collections.\u0026amp;lt;BizInfo\u0026amp;gt; singleton(biz)); return response; } catch (Throwable throwable) { ... response.setCode(ResponseCode.FAILED).setMessage( String.format(\u0026amp;quot;Install Biz: %s fail,cost: %s ms, started at: %s\u0026amp;quot;, biz.getIdentity(), end - start, startDate)); ... try { biz.stop(); // 4 } catch (Throwable e) { ... throw e; } finally { bizManagerService.unRegisterBizStrictly(biz.getBizName(), biz.getBizVersion()); } return response; } } 解析 Ark Biz 当开启内嵌模式时，将 Biz 包解压到 ${Biz}-unpack 目录下，生成展开型的 Biz 包；当未开启内嵌模式时，直接使用原始的 Biz Jar 包，生成压缩型的 Biz …","date":-62135596800,"description":"源码解析 | 动态部署","dir":"projects/sofa-boot/sofa-ark-dynamic-deploy/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"49b198c473b8ee5d8de18d8260661df6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","summary":"前言 在实践中，我们通常会使用业务功能模块化的开发模式，部署时将不同模块合并部署，由于团队间技术栈不统一，此时就有可能出现依赖冲突等问题。SO","tags":["源码解析"],"title":"动态部署","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","wordcount":3759},{"author":null,"categories":null,"content":" 单元测试 单元测试例子放到自己开发的模块下。\n如果依赖了第三方服务端（例如Zookeeper），请手动加入 profile。参考 registry-zookeeper 模块代码。\n如果依赖了其它模块要集成测试，请放到 test/test-intergrated 模块中。\n如果还依赖了第三方服务端（例如Zookeeper），请放到 test-intergrated-3rd 模块中。\n性能测试 关闭了以下默认开启项目：\n-Dcontext.attachment.enable=false -Dserialize.blacklist.enable=false -Ddefault.tracer= -Dlogger.impl=com.alipay.sofa.rpc.log.SLF4JLoggerImpl -Dmultiple.classloader.enable=false -Devent.bus.enable=false\n我们对 BOLT+hessian 进行了压测。\n服务端：4C8G 虚拟机，千M网络，jdk1.8.0_111；\n客户端：50个客户端并发请求。\n 协议 请求 响应 服务端 TPS 平均RT(ms) bolt+hessian 1K String 1K String 直接返回 10000 1.93 bolt+hessian 1K String 1K String 直接返回 20000 4.13 bolt+hessian 1K String 1K String 直接返回 30000 7.32 bolt+hessian 1K String 1K String 直接返回 40000 15.78 bolt+hessian 1K String 1K String 直接返回 50000(接近极限,错误率0.3%） 26.51 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/test/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ccda7c2372a7f55d61f682b72d3b1dc2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/test/","summary":"单元测试 单元测试例子放到自己开发的模块下。 如果依赖了第三方服务端（例如Zookeeper），请手动加入 profile。参考 registry-zookeeper 模块代码。 如果依","tags":null,"title":"单元测试与性能测试","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/test/","wordcount":292},{"author":null,"categories":null,"content":" 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git 官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git 协作流程 GitHub 贡献代码流程 提交 issue 不论您是修复 ACTS 的 bug 还是新增 ACTS 的功能，在您提交代码之前，在 ACTS 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. ACTS 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 ACTS 主干代码到您的代码仓库。\n拉分支 ACTS 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式.\ngit clone https://github.com/您的账号名/acts.git 拉分支准备修改代码\ngit branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n 修改完代码后，执行如下命令提交所有修改到本地\ngit commit -am \u0026#39;添加xx功能\u0026#39; 修改代码注意事项 代码风格保持一致 ACTS 通过 Maven 插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码\n 新有修改应该通过已有的单元测试.\n 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\nmvn clean test 也可以通过 IDE 来辅助运行。\n 其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。 * 执行如下命令提交本地修改到 github 上\n``` git push origin \u0026amp;quot;branchname\u0026amp;quot; ``` 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 ACTS 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 ACTS 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 ACTS 的人员， ACTS 人员会 Review 您的代码，符合要求后就会合入主干，成为 ACTS 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 ACTS 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/contributing/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cd68baede6258921f83665ef0a446f1f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/contributing/","summary":"准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git 官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章G","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-acts/contributing/","wordcount":1224},{"author":null,"categories":null,"content":" 可以先去 发展路线 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看 git官方书籍，需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程。 GitHub 贡献代码流程 提交issue 不论您是修复 SOFAArk 的 bug 还是新增 SOFAArk 的功能，在您提交代码之前，在 SOFAArk 的 GitHub 地址上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFAArk 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的fork按钮，复制一份 SOFAArk 主干代码到您的代码仓库。\n拉分支 SOFAArk 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择git/https方式.\ngit clone https://github.com/您的账号名/sofa-ark.git 拉分支准备修改代码\ngit branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\n git branch -a 如果您想切换回主干，执行下面命令:\n git checkout -b master 如果您想切换回分支，执行下面命令：\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFAArk 通过 Maven 插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\n mvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\n git commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFAArk 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFAArk 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFAArk 的人员， SOFAArk 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFAArk 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFAArk 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-contribution/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dbf77f98884a71c5c7a3fbb4dd189cfe","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","summary":"可以先去 发展路线 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看 git官方书籍，需要阅","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","wordcount":1278},{"author":null,"categories":null,"content":" 可以先去 RoadMap 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看 git官方书籍，需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFADashboard 的 bug 还是新增 SOFADashboard 的功能，在您提交代码之前，在 SOFADashboard 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。\n这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFADashboard 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFADashboard 主干代码到您的代码仓库。\n拉分支 SOFADashboard 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式.\ngit clone https://github.com/您的账号名/sofa-dashboard.git 拉分支准备修改代码 bash git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令: bash git checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFADashboard 通过 Maven插件来保持代码格式一致。在提交代码前，务必本地执行\nmvn clean compile 补充单元测试代码\n 新有修改应该通过已有的单元测试.\n 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug\n您可以用如下命令运行所有测试\nmvn clean test 也可以通过 IDE 来辅助运行。 其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地：\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFADashboard 的代码仓库。\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFADashboard 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFADashboard 的人员， SOFADashboard 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFADashboard 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。 对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFADashboard 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/contribution/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"584584be9c13f2d36c85890dd192368a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/contribution/","summary":"可以先去 RoadMap 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看 git官方书籍，需要阅读前几","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/contribution/","wordcount":1262},{"author":null,"categories":null,"content":" 可以先去 发展路线 \u0026amp;amp; 任务认领 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFARegistry 的 bug 还是新增 SOFARegistry 的功能，在您提交代码之前，在 SOFARegistry 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFARegistry 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFARegistry 主干代码到您的代码仓库。\n拉分支 SOFARegistry 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式. git clone https://github.com/您的账号名/sofa-registry.git 拉分支准备修改代码 git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFARegistry 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug您可以用如下命令运行所有测试 mvn clean test 也可以通过 IDE 来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFARegistry 的代码仓库.\n提交合并代码到主干的请求 在您的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFARegistry 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request 按钮。选择目标分支,一般就是 master，系统会通知 SOFARegistry 的人员， SOFARegistry 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFARegistry 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFARegistry 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/contributing/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c08b5945719137833634c111c43a8d9e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/contributing/","summary":"可以先去 发展路线 \u0026amp; 任务认领 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git官方书","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-registry/contributing/","wordcount":1264},{"author":null,"categories":null,"content":" 可以先去 发展路线 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFARPC 的 bug 还是新增 SOFARPC 的功能，在您提交代码之前，在 SOFARPC 的GitHub上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFARPC 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的fork按钮，复制一份 SOFARPC 主干代码到您的代码仓库。\n拉分支 SOFARPC 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择git/https方式. git clone https://github.com/您的账号名/sofa-rpc.git 在提交pull request请求前, 请将您克隆的代码和远程代码库同步，这样您的pull request会简单清晰 git remote add upstream git@github.com:sofastack/sofa-rpc.git git fetch upstream git rebase upstream/master 拉分支准备修改代码 git checkout -b add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFARPC 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\nmvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFARPC 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFARPC 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFARPC 的人员， SOFARPC 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFARPC 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFARPC 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/contributing/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"448a7b9a949bd2d9e2e71ac6c237f9df","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/contributing/","summary":"可以先去 发展路线 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git官方书籍,需要阅","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/contributing/","wordcount":1351},{"author":null,"categories":null,"content":" 客户端发展规划 v2.0 ，在基于 Java 8 进行重构，v1.0 为支持 Java 6 做了些设计与性能妥协； 集成更多的开源产品； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/plan/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6153fc1f5e000f195d96dfdb03c5b381","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/plan/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/plan/","summary":"客户端发展规划 v2.0 ，在基于 Java 8 进行重构，v1.0 为支持 Java 6 做了些设计与性能妥协； 集成更多的开源产品；","tags":null,"title":"发展规划","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/plan/","wordcount":49},{"author":null,"categories":null,"content":" 任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 代码 支持多个 Web 应用合并部署，采用多 Host/单 Host 两种模式 难 代码 支持 telnet 指令查看 ark plugin 简单 代码 支持 telnet 指令查看 jvm/rpc 服务 中 版本迭代计划 v0.5.0 支持多个 Web 应用合并部署，采用多 Host/单 Host 两种模式 v0.6.0 支持 telnet 指令查看 ark plugin； 支持 telnet 指令查看 jvm/rpc 服务； ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-roadmap/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c4532d11cef15d8fe3ff5e04c7b08f90","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","summary":"任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 代码 支持多个 Web 应用合","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","wordcount":175},{"author":null,"categories":null,"content":" 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。\n如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关Issue 文档 文档翻译 低 代码 弹性长连接管理方式 低 #56 代码 etcd注册中心实现 中 @wynn5a\n2018-6 #153 代码 eureka注册中心实现 中 @liufeiit\n2018-4 #52 代码 gRPC 支持 高 #57 代码 CXF 协议 高 #58 代码 TLS 支持 高 版本迭代计划 v5.5.0 JSON 序列化支持 H2的TLS安全支持 弹性连接池 hystrix集成 Consul注册中心支持 v5.6.0 grpc 通讯层支持 etcd注册中心支持 SofaMesh支持 BOLT 版本协商与 CRC 校验 v5.7.0 Telnet 内置指令支持 SpringBoot 2.0 支持 Mock功能支持 加密功能支持 v5.8.0 授权支持 SofaRegistry 支持 Reactive 支持 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/roadmap/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6064fc180911f520f6d1590b88595693","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/roadmap/","summary":"任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。 如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。 类型","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/roadmap/","wordcount":292},{"author":null,"categories":null,"content":" 任务列表 欢迎大家领取任务参与贡献。\n 类型 任务 困难度 认领人及时间 计划发布时间 计划完成时间 进度 相关 issue 代码 SOFATracer 性能优化专题 高 issue 18和 issue 11 代码 SOFATracer 支持 HttpClient 中 已经完成，见 HttpClient 接入文档 代码 SOFATracer 数据汇报能力提供在非 SOFABoot 框架下的运行和配置能力 中 已经完成，见 Spring 工程中使用 SOFATracer issue 32 代码 SOFATracer 提供采样能力 中 已经完成，见使用 SOFATracer 的采样能力 issue 10 代码 SOFATracer 支持 Zipkin 2.X.X 版本 中 已经完成，见使用 SOFATracer 远程汇报数据到 Zipkin issue 23 代码 SOFATracer 支持 Druid 中 已经完成，见 DataSource 接入文档 代码 SOFATracer 支持 c3p0 中 已经完成 代码 SOFATracer 支持 Tomcat-JDBC 中 已经完成 代码 SOFATracer 支持 HikariCP 中 已经完成 代码 SOFATracer 支持 dbcp 中 已经完成，见 DataSource 接入文档 代码 SOFATracer 支持 dbcp2 中 已经完成 代码 SOFATracer 支持 Sharding-JDBC 中 代码 SOFATracer 支持 Mysql JDBC Driver 中 代码 SOFATracer 支持 Oracle JDBC Driver 中 代码 SOFATracer 支持 Dubbo 中 代码 SOFATracer 支持 RestTemplate 和 AsyncRestTemplate 中 已经完成 代码 SOFATracer 支持标准Servlet 中 已经完成，见对于标准 servlet 容器的支持（ tomcat/jetty 等） 代码 SOFATracer 支持单机版链路分析并给用户通过注解使用的埋点方式，数据汇报到 Zipkin 中 代码 SOFATracer 支持 Kafka 中 代码 SOFATracer 支持 Redis 中 代码 SOFATracer 支持 hystrix 中 文档 文档翻译 中 版本迭代计划 2.2.0 SOFATracer 支持 JDBC 数据源 SOFATracer 支持 Mysql Driver SOFATracer 支持 Sharding-JDBC SOFATracer 支持 Mysql-JDBC SOFATracer 支持 Druid SOFATracer 支持 c3p0 SOFATracer 支持 Tomcat-JDBC SOFATracer 支持 HikariCP SOFATracer 支持 HttpClient SOFATracer 支持 Zipkin 2.X.X 版本，开发验证并测试 2.3.0 SOFATracer 支持RestTemplate 和 AsyncRestTemplate SOFATracer 支持提供采样能力 SOFATracer 支持标准 servlet 容器 SOFATracer 支持 Zipkin UI 中文界面 SOFATracer 支持数据汇报能力提供在非 SOFABoot 框架下的运行和配置能力 2.4.0 SOFATracer 支持 Dubbo SOFATracer 支持 Kafka SOFATracer 性能优化专题 2.5.0 SOFATracer 支持单机版链路分析并给用户通过注解使用的埋点方式，数据汇报到 Zipkin 展示 SOFATracer 支持 manual report SOFATracer 支持 基于 Opentracing API 埋点方式 SOFATracer 支持 Opentracing 0.30.0+ 版本 ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/roadmap/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8b0a6fbe5f6ea5ae789f5186271073c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/roadmap/","summary":"任务列表 欢迎大家领取任务参与贡献。 类型 任务 困难度 认领人及时间 计划发布时间 计划完成时间 进度 相关 issue 代码 SOFATracer 性能优化专题 高 issue 18和 issue 11 代码 SOFATracer 支持 HttpClient 中","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/roadmap/","wordcount":605},{"author":null,"categories":null,"content":" 发展路线 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。\n如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关issue 文档 文档翻译 低 代码 支持Spring Cloud 中 代码 数据自检 高 代码 黑名单过滤 中 代码 SOFARegistry Dashboard 高 代码 支持其他微服务框架 中 代码 支持 Docker \u0026amp;amp; Kubernetes 高 代码 多语言客户端支持 高 版本迭代计划 v5.3.0 支持 Spring Cloud 数据自检 黑名单过滤 v5.4.0 SOFARegistry Dashboard 支持其他微服务框架 v5.5.0 支持 Docker \u0026amp;amp; Kubernetes 多语言客户端支持 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/roadmap/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b0ab45d52ba3eb7db590a4f5e4197c9e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/roadmap/","summary":"发展路线 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。 如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡","tags":null,"title":"发展路线 \u0026 任务认领","type":"projects","url":"/sofastack.tech/projects/sofa-registry/roadmap/","wordcount":216},{"author":null,"categories":null,"content":"更多参见：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md\n","date":-62135596800,"description":"","dir":"projects/mosn/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"62efb8e40401ab4612bcccaa6e942c97","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/release-notes/","summary":"更多参见：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md","tags":null,"title":"发布历史","type":"projects","url":"/sofastack.tech/projects/mosn/release-notes/","wordcount":61},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-rpc/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ab7d46caa6906863103b77b742ec7e84","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/release-notes/","summary":"更多参见：https://github.com/sofastack/sofa-rpc/releases","tags":null,"title":"发布历史","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/release-notes/","wordcount":51},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-ark/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-release/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"994c3569ea416ee5b0dea253f08af6be","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-release/","summary":"更多参见：https://github.com/sofastack/sofa-ark/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-release/","wordcount":51},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-dashboard/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/release-node/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3c8e6985123810c9692f47cc56b50081","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/release-node/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/release-node/","summary":"更多参见：https://github.com/sofastack/sofa-dashboard/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/release-node/","wordcount":57},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-registry/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d92dddf77bbbd6078f3f96ba2224a53d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/release-notes/","summary":"更多参见：https://github.com/sofastack/sofa-registry/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-registry/release-notes/","wordcount":56},{"author":null,"categories":null,"content":" SOFABoot 提供了模块并行加载以及 Spring Bean 异步初始化能力，用于加快应用启动速度。模块并行加载参考相应文档，下面介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力来提高应用启动速度。\n引入依赖 SOFABoot 在 v2.6.0 开始提供异步初始化 Spring Bean 能力，引入如下 Starter 即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 使用场景 在实际使用 Spring/Spring Boot 开发中，会有一些 Bean 在初始化过程中执行准备操作，如拉取远程配置、初始化数据源等等；在应用启动期间，这类 Bean 会增加 Spring 上下文刷新时间，导致应用启动耗时变长。为了加速应用启动，SOFABoot 通过配置可选项，将 Bean 的初始化方法(init-method) 使用单独线程异步执行，加快 Spring 上下文加载过程，提高应用启动速度。\n使用方法 异步初始化 Bean 的原理是开启单独线程负责执行 Bean 的初始化方法(init-method)，因此在使用过程中，除了引入上述依赖管理，还需要在 Bean 的 xml 定义中配置 sofa:async-init=\u0026amp;quot;true\u0026amp;quot; 属性，用于指定是否异步执行该 Bean 的初始化方法，例如：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- async init test --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBean\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.beans.TimeWasteBean\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot; sofa:async-init=\u0026amp;quot;true\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 配置 SOFABoot 异步初始化能力提供两个属性配置，用于指定负责异步执行 Bean 初始化方法(init-method)的线程池大小： + com.alipay.sofa.boot.asyncInitBeanCoreSize \u0026amp;gt; 线程池基本大小，默认值为 CPU 核数加一 + com.alipay.sofa.boot.asyncInitBeanMaxSize \u0026amp;gt; 线程池中允许的最大线程数大小，默认值为 CPU 核数加一\n配置可以通过 VM -D 参数或者 Spring Boot 配置文件 application.yml 设置。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/speed-up-startup/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ebd933894c7828948b87610d1d0ca020","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/speed-up-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/speed-up-startup/","summary":"SOFABoot 提供了模块并行加载以及 Spring Bean 异步初始化能力，用于加快应用启动速度。模块并行加载参考相应文档，下面介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力来提高应用启","tags":null,"title":"启动加速","type":"projects","url":"/sofastack.tech/projects/sofa-boot/speed-up-startup/","wordcount":519},{"author":null,"categories":null,"content":" 启动过程 Ark 1.0 非内嵌模式 打包方式 在 SOFAArk 1.0 中使用 sofa-ark-maven-plugin 打包\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 启动流程图 Ark 1.0 应用的整体启动流程如下图所述： 启动方式 方式一、IDEA 启动 使用 idea 启动 SpringBoot Application 即可\n方式二、命令行启动 Ark 包是可执行 Jar，可直接使用 java -jar 的方式启动，先使用 mvn clean package 进行打包，打包得到 ${bizName}-${bizVersion}-executable-ark.jar，命令行启动\njava -jar ${bizName}-${bizVersion}-executable-ark.jar 启动原理分析 Springboot 应用，ArkApplicationStartListener 实现了 ApplicationListener 接口，监听 Spring 的启动事件，调用SofaArkBootstrap.launch(args)启动 Ark。\npublic class ArkApplicationStartListener implements ApplicationListener\u0026amp;lt;SpringApplicationEvent\u0026amp;gt; { @Override public void onApplicationEvent(SpringApplicationEvent event) { try { if (isSpringBoot2() \u0026amp;amp;\u0026amp;amp; APPLICATION_STARTING_EVENT.equals(event.getClass().getCanonicalName())) { startUpArk(event); } if (isSpringBoot1() \u0026amp;amp;\u0026amp;amp; APPLICATION_STARTED_EVENT.equals(event.getClass().getCanonicalName())) { startUpArk(event); } } catch (Throwable e) { throw new RuntimeException(\u0026amp;quot;Meet exception when determine whether to start SOFAArk!\u0026amp;quot;, e); } } public void startUpArk(SpringApplicationEvent event) { if (LAUNCH_CLASSLOADER_NAME.equals(this.getClass().getClassLoader().getClass().getName())) { // Ark 启动入口，非 Springboot 应用需要手动调用该方法 SofaArkBootstrap.launch(event.getArgs()); } } public boolean isSpringBoot1() { return SpringBootVersion.getVersion().startsWith(\u0026amp;quot;1\u0026amp;quot;); } public boolean isSpringBoot2() { return SpringBootVersion.getVersion().startsWith(\u0026amp;quot;2\u0026amp;quot;); } } SofaArkBootstrap launch 方法里面启了一个线程执行SofaArkBootstrap.remain方法，remain 里面调ClasspathLauncher.launch方法。\npublic class SofaArkBootstrap { private static final String BIZ_CLASSLOADER = \u0026amp;quot;com.alipay.sofa.ark.container.service.classloader.BizClassLoader\u0026amp;quot;; private static final String MAIN_ENTRY_NAME = \u0026amp;quot;remain\u0026amp;quot;; private static EntryMethod entryMethod; public static void launch(String[] args) { try { if (!isSofaArkStarted()) { entryMethod = new EntryMethod(Thread.currentThread()); IsolatedThreadGroup threadGroup = new IsolatedThreadGroup( entryMethod.getDeclaringClassName()); // 参数中指定当前类的remain方法，LaunchRunner.run 里面会用反射调用remain方法 LaunchRunner launchRunner = new LaunchRunner(SofaArkBootstrap.class.getName(), MAIN_ENTRY_NAME, args); Thread launchThread = new Thread(threadGroup, launchRunner, entryMethod.getMethodName()); launchThread.start(); // 等待前面的线程 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup-process/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c89b63bd70a937cf29bbf165fda00444","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","publishdate":"0001-01-01T00:00:00Z","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","summary":"启动过程 Ark 1.0 非内嵌模式 打包方式 在 SOFAArk 1.0 中使用 sofa-ark-maven-plugin 打包 \u0026lt;build\u0026gt; \u0026lt;plugins\u0026gt; \u0026lt;plugin\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofa-ark-maven-plugin\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${sofa.ark.version}\u0026lt;/version\u0026gt; \u0026lt;executions\u0026gt; \u0026lt;execution\u0026gt; \u0026lt;id\u0026gt;default-cli\u0026lt;/id\u0026gt; \u0026lt;!--goal executed to generate executable-ark-jar --\u0026gt; \u0026lt;goals\u0026gt; \u0026lt;goal\u0026gt;repackage\u0026lt;/goal\u0026gt; \u0026lt;/goals\u0026gt; \u0026lt;configuration\u0026gt; \u0026lt;outputDirectory\u0026gt;./target\u0026lt;/outputDirectory\u0026gt; \u0026lt;!--default none--\u0026gt; \u0026lt;arkClassifier\u0026gt;executable-ark\u0026lt;/arkClassifier\u0026gt; \u0026lt;/configuration\u0026gt; \u0026lt;/execution\u0026gt; \u0026lt;/executions\u0026gt; \u0026lt;/plugin\u0026gt; \u0026lt;/plugins\u0026gt; \u0026lt;/build\u0026gt; 启动流程图 Ark 1.0 应用的整体启动流程如","tags":null,"title":"启动过程","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","wordcount":4023},{"author":null,"categories":null,"content":" 本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sidecar的部署模式，满足用户的各种需求。\n前置要求 Docker Docker Compose 安装步骤 下载最新的 release 包 解压安装文件，并且进入解压后的路径，安装路径包含： 示例应用路径 samples/ /bin 路径下应该能找到 istioctl 客户端可执行文件，istioctl 可用于创建路由规则和策略 配置文件 istion.VERSION 把 Istio 的 bin 路径添加到系统的 PATH。比如，在 MacOS 或者 Linux 系统下执行如下命令：\nexport PATH=$PWD/bin;$PATH 安装helm 创建命名空间 SHELL kubectl create namespace istio-system 使用helm安装istio CRD\nhelm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - 使用helm安装各个组件 SHELL helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - 确认所有 pod 都在运行中：\nkubectl get pod -n istio-system 如果 Istio pilot 容器意外终止，确保运行 istioctl context-create 命令，并且重新执行上一个命令。\n部署应用程序 现在开始部署 Bookinfo 示例程序 为 default 命名空间打上标签 istio-injection=enabled，实现 Sidecar 自动注入\nkubectl label namespace default istio-injection=enabled 使用 kubectl 部署Bookinfo的服务\nkubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml 确认所有的服务和 Pod 都已经正确的定义和启动\nkubectl get services kubectl get pods 卸载 Istio helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - kubectl delete namespace istio-system ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1de4868fa0e9c73d932343847864d7fb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","summary":"本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sid","tags":null,"title":"在 Kubernetes 中快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","wordcount":465},{"author":null,"categories":null,"content":" 本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。\nSOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sidecar的部署模式，满足用户的各种需求。\n前置要求 Kubernetes 安装 Helm 安装步骤 Step 1. 下载最新的 release 包 Step 2. 把 Istio 的 bin 路径添加到系统的 PATH。比如，在 Linux 系统下执行如下命令：\nexport PATH=$PWD/bin;$PATH Step 3. 创建命名空间\nkubectl create namespace istio-system Step 4. 使用helm安装istio CRD\nhelm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - Step 5. 使用helm安装各个组件\nhelm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - Step 6. 确认所有 pod 都在运行中\nkubectl get pod -n istio-system 部署应用程序 现在开始部署 Bookinfo 示例程序。\n为 default 命名空间打上标签 istio-injection=enabled，实现 Sidecar 自动注入：\nkubectl label namespace default istio-injection=enabled 使用 kubectl 部署Bookinfo的服务：\nkubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml 确认所有的服务和 Pod 都已经正确的定义和启动：\nkubectl get services kubectl get pods 卸载 Istio helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - kubectl delete namespace istio-system ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/sofa-mesh-setup/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"940d012b4883e5c91bf777916cd3c6b3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","summary":"本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sid","tags":null,"title":"在 Kubernetes 中快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","wordcount":362},{"author":null,"categories":null,"content":" 基于 Serverless 轻松构建云上应用 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。\n作为云原生技术前进方向之一，Serverless 架构让您进一步提高资源利用率，更专注于业务研发。通过我们的 workshop，您 可以体验到快速创建 Serverless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错等产品新功能。\nWorkshop 操作内容 流程图 应用架构图 效果预览 \nStep 0: 前期准备 应用 clone：https://github.com/sofastack-guides/kc-serverless-demo \n讲师演示 \n快速发布后端 Java 应用 选择快速创建 选择 Java Runtime 上传代码包 balance-mng.jar 入口方法可自动识别 端口：8080 创建完成后，复制保存后端服务的地址 查看后端服务计算实例数量：0 快速发布前端 Node JS 应用 选择创建应用服务 创建应用，选择技术栈为 Node JS 上传代码包 prod-stockmng-v1.zip 运行时选择 nodejs-0.0.1.1-pre 入口方法可自动识别 端口： 3000 环境变量设置 BALANCEMNG_URL 为后端服务的地址 \nStep 1: 查看 Serverless 应用服务 访问 Serverless 应用服务地址 https://sas.shared.cloud.alipay.com/ 使用账号，密码登陆 选择 workspace： workspace0【user00-09】 workspace1【user10-19】 \u0026amp;hellip; workspace9【user90-99】 查看前端应用服务：kubectl frontend demo xx【00-99】 查看后端应用服务：kubectl backend demo xx【00-99】 查看目前后端应用的计算实例数量：0 \nStep 2: 查看 0-1 冷启能力 使用 Chrome 浏览器访问前端服务，域名为：*.kevinwang.cc 查看后端服务的计算实例数量的变化 \n讲师演示2 \n创建版本和流量控制 克隆前端应用，并创建新版本 上传代码包 prod-stockmng-v2.zip 配置权重，路由 1:1 访问 V1 和 V2 版本 通过浏览器查看效果 \nStep 3: 查看版本和流量控制 打开前端应用服务 查看当前应用服务的 V1 和 V2 版本，和路由 通过浏览器访问应用查看流控效果 \nStep 4: 时间触发器 创建时间触发器，定时 2 分钟后触发一次 为前端应用配置触发器 在指定时间，通过执行记录查看触发效果 [](https://github.com/sofastack-guides/kc-serverless-demo#step-2-%E6%9F%A5%E7%9C%8B-0-1-%E5%86%B7%E5%90%AF%E8%83%BD%E5%8A%9B) \nStep 5: Log Shell 和计量 打开 Log Shell 选择相应的应用服务，并输入日志地址/关键词 搜索查看应用服务日志，可全屏 打开计量信息 通过计量监控查看实例运行情况 \n讲师演示3 \nM-N 快速伸缩 打开应用服务 查看当前版本的计算实例限额 1-5 / 计算实例数量：目前为 1 开始压测模拟高并发，并同步查看计算示例数变化 快速从 1 变化为 4，演示结束 Step 6:【可选步骤】快速开始+测试执行 按照前文步骤，尝试自己创建一个新的前端应用 测试执行应用服务 快速发布前端 Node JS应用 选择创建应用服务 创建应用，选择技术栈为 Node JS 上传代码包 prod-stockmng-v1.zip 运行时选择 nodejs-0.0.1.1-pre 入口方法可自动识别 端口： 3000 环境变量设置 BALANCEMNG_URL 为后端服务的地址 测试执行应用服务 选择测试执行 触发查看效果 更多 下载本次 Demo 幻灯片 ","date":-62135596800,"description":"使用该指南您可以体验到快速创建 Serveless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错、按时间触发应用等产品新功能。","dir":"guides/kc-serverless-demo/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f355d1b598fed47b730bd74ad25f3683","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-serverless-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/kc-serverless-demo/","summary":"基于 Serverless 轻松构建云上应用 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。 作为云原生技术前进方向之一，Serverless 架构","tags":null,"title":"基于 Serverless 轻松构建云上应用","type":"guides","url":"/sofastack.tech/guides/kc-serverless-demo/","wordcount":1070},{"author":null,"categories":null,"content":" Ark 包 SOFAArk 定义特殊格式的可执行 Jar 包，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark 包；使用命令 java -jar 即可在 SOFAArk 容器之上启动应用；Ark 包 通常包含 Ark Container 、Ark Plugin 依赖（如果有）、合并部署的 Ark Biz （如果有）以及应用自身的 Ark Biz；详情可参考 Ark 包；\nArk Container Ark 容器，Ark Plugin 和 Ark Biz 运行在 SOFAArk 容器之上；容器具备管理多插件、多应用的功能；容器启动成功后，会解析 Ark Plugin 和 Ark Biz 配置，完成隔离加载并按优先级依次启动之；Ark Container 一般不会被用户直接感知，由打包插件 sofa-ark-maven-plugin 自动打入。详情可参考 SOFAArk 容器启动；\nArk Plugin Ark 插件，SOFAArk 定义特殊格式的 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-plugin-maven-plugin 可以将一个或多个普通的 Java Jar 包打包成一个标准格式的 Ark Plugin； Ark Plugin 会包含一份配置文件，通常包括插件类和资源的导入导出配置、插件启动优先级等；运行时，Ark 容器会使用独立的 PluginClassLoader 加载插件，并根据插件配置构建类加载索引表，从而使插件与插件、插件与应用之间相互隔离；详情可参考 Ark Plugin；\nArk Biz Ark 模块，SOFAArk 定义特殊格式的 Fat Jar ，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark Biz 包；作用有二点，一、在 Ark 包 中，作为工程应用模块及其依赖包的组织单元；二、可以被其他应用当成普通 Jar 包依赖，用于在同一个 SOFAArk 容器启动多个 Ark Biz；多个 Ark Biz 共享 Ark Container 和 Ark Plugin ；详情可参考 Ark Biz；\n合并部署 SOFAArk 允许将多个应用（Biz 包）合并打入到 Ark 包中，当启动 Ark 包时，会启动所有应用；也支持在运行时通过 API 或者配置中心（例如 Zookeeper）动态的部署和卸载应用，这些应用同时运行在同一个 JVM 中，由独立的 BizClassLoader 加载，各应用之间通过 SofaService/SofaReference 实现交互，称之为多应用的合并部署。\n宿主应用 宿主应用是相对合并部署而言，在打包 Ark 包时，至少有一个 Biz 包被打入，如果应用引入了其他 Biz 包，则 Ark 包中会存在多个 Biz 包。当只有一个 Biz 包时，默认将其设置为宿主应用；如果存在多个 Biz 包，则需要配置指定宿主应用。宿主应用相对其他 Biz 包最大的不同，即不允许被卸载。\n简单总结下，在 SOFAArk 框架中，应用(配置、源码、依赖)被打包成 Biz 包组织在一起，但是特殊的依赖（Ark Plugin 和其他应用 Biz 包）不会被打入 Biz 包中，Biz 包是不可执行的 Fat Jar; Ark Plugin 是特殊的二方包，可以将多个二方依赖打包成 Plugin，运行时由独立的 PluginClassLoader 加载，根据打包时配置的导出导入资源、类，构建运行时类加载模型；Ark 包是可执行 Fat Jar，一般由 Ark Container、Ark Plugin(0个或多个)、Ark Biz(至少一个)。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-terminology/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b6d0ed10afe9d04bc00307017ffba7c5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","summary":"Ark 包 SOFAArk 定义特殊格式的可执行 Jar 包，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark 包；使用命令 java -jar 即可在 SOFAArk 容器之上启动应用；Ark 包","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","wordcount":1015},{"author":null,"categories":null,"content":" 业界通用术语 术语 说明 服务（Service） 通过网络提供的、具有特定业务逻辑处理能力的软件功能。 服务提供者（Service Provider） 通过网络提供服务的计算机节点。 服务消费者（Service Consumer） 通过网络调用服务的计算机节点。一个计算机节点可以既作为一些服务的提供者，又作为一些服务的消费者。 服务发现（Service Discovery） 服务消费者获取服务提供者的网络地址的过程。 服务注册中心（Service Registry） 一种提供服务发现功能的软件系统，帮助服务消费者获取服务提供者的网络地址。 数据中心（Data Center） 物理位置、供电、网络具备一定独立性的物理区域，通常作为高可用设计的重要考量粒度。一般可认为：同一数据中心内，网络质量较高、网络传输延时较低、同时遇到灾难的概率较大；不同数据中心间，网络质量较低、网络延时较高、同时遇到灾难的概率较小。 SOFARegistry 约定术语 术语 说明 SOFARegistry 蚂蚁金服开源的一款服务注册中心产品，基于“发布-订阅”模式实现服务发现功能。同时它并不假定总是用于服务发现，也可用于其他更一般的“发布-订阅”场景。 数据（Data） 在服务发现场景下，特指服务提供者的网络地址及其它附加信息。其他场景下，也可以表示任意发布到 SOFARegistry 的信息。 单元（Zone） 单元化架构关键概念，在服务发现场景下，单元是一组发布与订阅的集合，发布及订阅服务时需指定单元名，更多内容可参考异地多活单元化架构解决方案。 发布者（Publisher） 发布数据到 SOFARegistry 的节点。在服务发现场景下，服务提供者就是“服务提供者的网络地址及其它附加信息”的发布者。 订阅者（Subscriber） 从 SOFARegistry 订阅数据的节点。在服务发现场景下，服务消费者就是“服务提供者的网络地址及其它附加信息”的订阅者。 数据标识（DataId） 用来标识数据的字符串。在服务发现场景下，通常由服务接口名、协议、版本号等信息组成，作为服务的标识。 分组标识（GroupId） 用于为数据归类的字符串，可以作为数据标识的命名空间，即只有 DataId、GroupId、InstanceId 都相同的服务，才属于同一服务。 实例 ID（InstanceId） 实例 ID，可以作为数据标识的命名空间，即只有DataId、GroupId、InstanceId都相同的服务，才属于同一服务。 会话服务器（SessionServer） SOFARegistry 内部负责跟客户端建立 TCP 长连接、进行数据交互的一种服务器角色。 数据服务器（DataServer） SOFARegistry 内部负责数据存储的一种服务器角色。 元信息服务器（MetaServer） SOFARegistry 内部基于 Raft 协议，负责集群内一致性协调的一种服务器角色。 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/terminology/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b678a49547c55f2a70e2d94dbce5b4a2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/terminology/","summary":"业界通用术语 术语 说明 服务（Service） 通过网络提供的、具有特定业务逻辑处理能力的软件功能。 服务提供者（Service Provider） 通","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-registry/terminology/","wordcount":1089},{"author":null,"categories":null,"content":" 名词 说明 TraceId TraceId 指的是 SOFATracer 中代表唯一一次请求的 ID，此 ID 一般由集群中第一个处理请求的系统产生，并在分布式调用下通过网络传递到下一个被请求系统。 SpanId SpanId 代表了本次请求在整个调用链路中的位置或者说层次，比如 A 系统在处理一个请求的过程中依次调用了 B，C，D 三个系统，那么这三次调用的的 SpanId 分别是：0.1，0.2，0.3。如果 B 系统继续调用了 E，F 两个系统，那么这两次调用的 SpanId 分别是：0.1.1，0.1.2。 其他相关的名词解释可以参考 OpenTracing 规范。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/explanation/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8ba307b0679e918f7ac68c7efb7e53f7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/explanation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/explanation/","summary":"名词 说明 TraceId TraceId 指的是 SOFATracer 中代表唯一一次请求的 ID，此 ID 一般由集群中第一个处理请求的系统产生，并在分布式调用下通过网络传递到下一个被请求系统。 SpanId SpanId","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/explanation/","wordcount":211},{"author":null,"categories":null,"content":" 消息 内部全部使用 SofaRequest 和 SofaResponse 进行传递。\n如果需要转换为其它协议，那么在真正调用和收到请求的时候，转换为实际要传输的对象。\n可以对 SofaRequest 和 SofaResponse 进行写操作的模块： - Invoker - Filter - ServerHandler - Serialization\n对消息体是只读的模块： - Cluster - Router - LoadBalance\n日志 日志的初始化也是基于扩展机制。虽然是扩展，但是由于日志的加载应该是最早的，所以在 rpc-config.json 里有一个单独的 Key。\n{ // 日志实现，日志早于配置加载，所以不能适应Extension机制 \u0026amp;quot;logger.impl\u0026amp;quot;: \u0026amp;quot;com.alipay.sofa.rpc.log.MiddlewareLoggerImpl\u0026amp;quot; } 配置项 使用者的 RPC 配置 用户的配置，例如端口配置（虽然已经开放对象中设置端口的字段，但是sofa默认是从配置文件里取的），线程池大小配置等。 - 通过 SofaConfigs 加载配置，调用 ExternalConfigLoader 读取外部属性。 - 通过 SofaConfigs 提供的 API 进行获取。 - 所有内部配置的Key都在 SofaOptions 类 - 优先级： System.property \u0026amp;gt; sofa-config.properties(每个应用一个) \u0026amp;gt; rpc-config.properties\nRPC 框架配置 框架自身的配置，例如默认序列化，默认超时等。 未来要一个ClassLoader一个。 - 通过 RpcConfigs 加载配置文件。 - 通过 RpcConfigs 其提供的API进行获取和监听数据变化 - 所有内部配置的Key都在 RpcOptions 类 - 优先级： System.property \u0026amp;gt; custom rpc-config.json（可能存在多个自定义，会排序） \u0026amp;gt; rpc-config-default.json\n常量 全局的基本常量在 RpcConstants 中。例如： 调用方式 sync oneway 协议 bolt/grpc、 序列化 hessian/java/protobuf\n 上下文的key 等等。 如果扩展实现自身的常量，请自行维护。 例如 BOLT 协议的常量。 SERIALIZE_CODE_HESSIAN = 1 PROTOCOL_TR = 13 例如 DSR 配置中心相关的常量。 _WEIGHT、_CONNECTTIMEOUT 这种 配置中心特有的key 地址 地址信息放到 ProviderInfo 类中 ProviderInfo 的值主要分为三部分 字段，一般是一些必须项目。 例如IP，端口，状态等； 静态字段：例如应用名； 动态字段：例如预热权重等； 字段枚举维护在 ProviderInfoAttrs 类中。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/common-model/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b2cc3f7ed134408d6adc25e418e1978b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/common-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/common-model/","summary":"消息 内部全部使用 SofaRequest 和 SofaResponse 进行传递。 如果需要转换为其它协议，那么在真正调用和收到请求的时候，转换为实际要传输的对象。 可以对 SofaRequest 和 SofaResponse 进行写操作的模块","tags":null,"title":"基础模型","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/common-model/","wordcount":684},{"author":null,"categories":null,"content":" 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 - git 工具用法可以查看 git 官方书籍,需要阅读前几章来熟悉。 - git 协作流程可以查看这篇文章 git 协作流程。\nGitHub 贡献代码流程 提交issue 不论您是修复 SOFAJRaft 的 bug 还是新增 SOFAJRaft 的功能，在您提交代码之前，在 SOFAJRaft 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处: - 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作。 - SOFAJRaft 的维护人员会对您提的 bug 或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 - 在达成一致后再开发，并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。\n获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFAJRaft 主干代码到您的代码仓库。\n拉分支 在这之前，可以先看看 SOFAJRaft 的 分支管理策略\nSOFAJRaft 所有修改都在分支上进行，修改完后提交 pull request，在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要： - 下载代码到本地，这一步您可以选择git/https方式。\ngit clone https://github.com/您的账号名/sofa-jraft 拉分支准备修改代码: git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支： git branch -a 如果您想切换回主干，执行下面命令： git checkout -b master 如果您想切换回分支，执行下面命令： git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFAJRaft 通过 Maven 插件来保持代码格式一致。在提交代码前，务必本地执行 mvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试： mvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等。 对于无用的注释，请直接删除。 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档。 修改完代码后，请按照如下格式执行命令提交所有的修改到本地:\ngit commit -am \u0026#39;(feat) 添加xx功能\u0026#39; git commit -am \u0026#39;(fix) 修复xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，接下来就可以与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的，那么这里的 origin 是 push 到您的代码仓库，而不是 SOFAJRaft 的代码仓库。\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFAJRaft 主干代码了。此时您需要进入您在 GitHub 上的对应仓库，按右上角的 pull request 按钮。选择目标分支，一般就是 master，系统会通知 SOFAJRaft 的人员， SOFAJRaft 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFAJRaft 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFAJRaft 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"99034715298f73cd835672b872141609","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","summary":"准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 - git 工具用法可以查看 git 官方书籍,需要阅读前几章来熟悉。 - git 协作流程可以查看这篇文章 git","tags":null,"title":"如何参与 SOFAJRaft 代码贡献","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","wordcount":1276},{"author":null,"categories":null,"content":" 简介 该样例工程演示了如何借助 maven 插件将一个普通的 Java 工程打包成标准格式规范的 Ark Plugin\n背景 现实开发中，常常会遇到依赖包冲突的情况；假设我们开发了一个类库 sample-lib , 业务应用在引入使用时，可能存在跟已有的依赖发生冲突的情况；通常这个时候，我们会希望自己的类库能够和业务其他依赖进行隔离，互不协商双方依赖包版本。 Ark Plugin 正是基于这种需求背景下的实践产物； Ark Plugin 运行在 Ark Container 之上，由容器负责加载启动，任何一个 Ark Plugin 由独立的 ClassLoader 加载，从而做到相互隔离。Ark Plugin 存在四个概念：\n 导入类：插件启动时，优先委托给导出该类的插件负责加载，如果加载不到，才会尝试从本插件内部加载；\n 导出类：其他插件如果导入了该类，优先从本插件加载；\n 导入资源：插件在查找资源时，优先委托给导出该资源的插件负责加载，如果加载不到，才会尝试从本插件内部加载；\n 导出资源：其他插件如果导入了该资源，优先从本插件加载；\n 详细请参考插件规范\n 工具 官方提供了 Maven 插件 - sofa-ark-plugin-maven-plugin ，只需要简单的配置项，即可将普通的 Java 工程打包成标准格式规范的 Ark Plugin ，插件坐标为:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 详细请参考插件配置文档\n 入门 基于该用例工程，我们一步步描述如何构建一个 Ark Plugin\n创建标准 Maven 工程 该用例工程是一个标准的 Maven 工程，一共包含两个模块： * common 模块：包含了插件导出类\n plugin 模块：包含了 com.alipay.sofa.ark.spi.service.PluginActivator 接口实现类和一个插件服务类，插件打包工具 sofa-ark-plugin-maven-plugin 即配置在该模块的 pom.xml 中； 配置打包插件 在 plugin 模块的 pom.xml 中按如下配置打包插件：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${project.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--can only configure no more than one activator--\u0026amp;gt; \u0026amp;lt;activator\u0026amp;gt;com.alipay.sofa.ark.sample.activator.SamplePluginActivator\u0026amp;lt;/activator\u0026amp;gt; \u0026amp;lt;!-- configure exported class --\u0026amp;gt; \u0026amp;lt;exported\u0026amp;gt; \u0026amp;lt;!-- configure package-level exported class--\u0026amp;gt; \u0026amp;lt;packages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa.ark.sample.common\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/packages\u0026amp;gt; \u0026amp;lt;!-- configure class-level exported class --\u0026amp;gt; \u0026amp;lt;classes\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.ark.sample.facade.SamplePluginService\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/classes\u0026amp;gt; \u0026amp;lt;/exported\u0026amp;gt; \u0026amp;lt;!--specify destination where ark-plugin will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;../target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 在用例工程中，我们只配置了一部分配置项，这已经足够生成一个可用的 Ark Plugin，各配置项含义如下： * activator: Ark 容器启动插件的入口类，最多只能配置一个；通常来说，在插件的 activator 会执行一些初始化操作，比如发布插件服务；在本样例工程中，即发布了插件服务。\n 导出包：包级别的导出类配置，插件中所有以导出包名为前缀的类，包括插件的三方依赖包，都会被导出；\n 导出类：精确类名的导出类配置，导出具体的类；\n outputDirectory： mvn package 打包后，输出的 ark plugin 文件存放目录；\n 需要指出的是，在用例工程中，我们只导出了工程创建的类；实际在使用时，也可以把工程依赖的三方包也导出去。\n打包、安装、发布、引入 和普通的工程操作类似，使用 mvn package , mvn install , mvn deploy 即可完成插件包的安装和发布；需要注意的是，默认发布的 Ark Plugin 其 Maven 坐标会增加 classifier=ark-plugin ；例如在该样例工程中，如果需要使用该 ark plugin，必须如下配置依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin-demo/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d8125843ced13352dd228299f222c74d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","summary":"简介 该样例工程演示了如何借助 maven 插件将一个普通的 Java 工程打包成标准格式规范的 Ark Plugin 背景 现实开发中，常常会遇到依赖包冲突的情况；假设我们开发了一个类","tags":null,"title":"如何打包 Ark Plugin","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","wordcount":1171},{"author":null,"categories":null,"content":" 简介 该样例工程演示了如何借助 Maven 插件将一个 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包；\n准备 因该样例工程依赖 sample-ark-plugin，因此需要提前在本地安装该 Ark Plugin\n工具 官方提供了 Maven 插件 - sofa-ark-maven-plugin ，只需要简单的配置项，即可将 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包，插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 详细请参考插件使用文档\n 入门 基于该样例工程，我们一步步描述如何将一个 Spring Boot Web 工程打包成可运行 Ark 包\n创建 SpringBoot Web 工程 在官网 https://start.spring.io/ 下载一个标准的 Spring Boot Web 工程\n引入 sample-ark-plugin 在工程主 pom.xml 中如下配置，添加另一个样例工程打包生成的 Ark Plugin 依赖，参考文档\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置打包插件 在工程主 pom.xml 中如下配置 Maven 插件 sofa-ark-maven-plugin :\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- 让模块只能使用基座里模块声明过的依赖，详细查看 https://www.sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/ --\u0026amp;gt; \u0026amp;lt;declaredMode\u0026amp;gt;true\u0026amp;lt;/declaredMode\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 在该样例工程中，我们只配置了一部分配置项，这已经足够生成一个可用的可执行 Ark 包，各配置项含义如下： * outputDirectory: mvn package 打包后，输出的 Ark 包文件存放目录；\n arkClassifier: 指定发布的 Ark 包其 Maven 坐标包含的 classifier 值，默认为空； 关于 arkClassifier 配置项需要特别注意下，默认值为空；如果不指定 classifier ，上传到仓库的 Jar 包其实是一个可运行的 Ark 包；如果需要和普通的打包加以区分，需要配置该项值。\n打包、安装、发布 和普通的工程操作类似，使用 mvn package , mvn install , mvn deploy 即可完成插件包的安装和发布；\n运行 我们提供了两种方式在 Ark 容器上启动工程应用，通过命令行启动或者在 IDE 启动；在 IDE 启动时，需要额外添加依赖；使用命令行启动非常简便，直接使用 java -jar 即可启动应用；下面我们说下如何在 IDE 启动 Ark 应用；\n Spring Boot 工程：Spring Boot 工程需要添加如下依赖即可： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 普通 Java 工程： 相较于 SpringBoot 工程，普通的 Java 工程需要添加另一个依赖： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-support-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 除此之外，还需要在工程 main 方法最开始处，执行容器启动，如下：\npublic class Application{ public static void main(String[] args) { SofaArkBootstrap.launch(args); ... } } 运行测试用例 SOFAArk 提供了 org.junit.runner.Runner 的两个实现 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-demo/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2c97c409788f41051c79836d277997be","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","summary":"简介 该样例工程演示了如何借助 Maven 插件将一个 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包； 准备 因该样例工程依赖 sample-ark-plugin，因","tags":null,"title":"如何打包 Ark 包","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","wordcount":1293},{"author":null,"categories":null,"content":" 如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。\n 直接下载代码，然后执行如下命令：\ncd sofa-rpc mvn clean install 注意：不能在子目录（即子模块）下进行编译。因为 SOFARPC 模块太多，如果每个子模块都会install 和 deploy，仓库内会有较多无用记录。 所以在设计 SOFARPC 工程结构的时候，我们决定各个子模块组件是不需要 install 和 deploy 到仓库里的，我们只会install 和 deploy 一个sofa-rpc-all(all) 模块。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/how-to-build/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"52ad3debb35be8743c97bb4b6b77f22b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/how-to-build/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/how-to-build/","summary":"如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后执行如下命令： cd sofa-rpc mvn clean install 注意：不能在子目录（即子模块）下进行编译。因为 SOFARPC 模块太多","tags":null,"title":"如何编译 SOFARPC 工程","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/how-to-build/","wordcount":180},{"author":null,"categories":null,"content":" 在非 Kubernetes 环境下使用 Istio 需要达成以下的关键任务：\n 为 Istio 控制平面配置 Istio API server，也可以通过 memostore 的方式启动 Pilot 用作演示用途。 给所有微服务实例手工添加 SOFA MOSN，并以 Sidecar 模式启动。 确保请求都通过 SOFA MOSN 进行路由。 设定控制平面 Istio 控制平面由四个主要的服务组成：Pilot、Mixter、Citadel 以及 API server。\nAPI server Istio\u0026amp;rsquo;s API server (基于 kubernetes API server) 提供了配置管理和基于角色的访问控制。API server 需要 etcd 集群作为底层的持久化存储。\n本地安装 使用如下的 docker compose file 安装一个用于 POC 目的的 API server：\nversion: \u0026#39;2\u0026#39; services: etcd: image: quay.io/coreos/etcd:latest networks: default: aliases: - etcd ports: - \u0026amp;quot;4001:4001\u0026amp;quot; - \u0026amp;quot;2380:2380\u0026amp;quot; - \u0026amp;quot;2379:2379\u0026amp;quot; environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;/usr/local/bin/etcd\u0026amp;quot;, \u0026amp;quot;-advertise-client-urls=http://0.0.0.0:2379\u0026amp;quot;, \u0026amp;quot;-listen-client-urls=http://0.0.0.0:2379\u0026amp;quot; ] istio-apiserver: image: gcr.io/google_containers/kube-apiserver-amd64:v1.7.3 networks: default: aliases: - apiserver ports: - \u0026amp;quot;8080:8080\u0026amp;quot; privileged: true environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;kube-apiserver\u0026amp;quot;, \u0026amp;quot;--etcd-servers\u0026amp;quot;, \u0026amp;quot;http://etcd:2379\u0026amp;quot;, \u0026amp;quot;--service-cluster-ip-range\u0026amp;quot;, \u0026amp;quot;10.99.0.0/16\u0026amp;quot;, \u0026amp;quot;--insecure-port\u0026amp;quot;, \u0026amp;quot;8080\u0026amp;quot;, \u0026amp;quot;-v\u0026amp;quot;, \u0026amp;quot;2\u0026amp;quot;, \u0026amp;quot;--insecure-bind-address\u0026amp;quot;, \u0026amp;quot;0.0.0.0\u0026amp;quot; ] 其他控制平面组件 目前 SOFA MOSN 还没有集成 Pilot 之外的其他组件，因此我们暂时无需安装 Mixer、Citadel 等组件。\n为微服务实例添加 SOFA MOSN Sidecar 微服务应用的每个实例都必须有个伴生的 SOFA MOSN 实例。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-installation/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4c0bd56673dc8aebef9011a22496392d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","summary":"在非 Kubernetes 环境下使用 Istio 需要达成以下的关键任务： 为 Istio 控制平面配置 Istio API server，也可以通过 memostore 的方式启动 Pilot 用作演示用途。 给所有微服务实例手工添加 SOFA","tags":null,"title":"安装指南","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","wordcount":372},{"author":null,"categories":null,"content":"提供可以允许配置的所有参数。 * 发布订阅配置 * 预热转发配置 * 自动故障剔除配置\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b1a8a8c426beab292165716f1dff1ae4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration/","summary":"提供可以允许配置的所有参数。 * 发布订阅配置 * 预热转发配置 * 自动故障剔除配置","tags":null,"title":"完整配置参数","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration/","wordcount":37},{"author":null,"categories":null,"content":" 客户端 API 使用说明 SOFALookout 客户端设计上保持了 API 与实现解耦。如果我们只需要基于 SOFALookout API 进行埋点，那么只需要依赖 API 包即可。在没有依赖具体实现模块依赖时（比如 client 依赖 或 SOFABoot（Spring Boot）Start 依赖），API 包会自动使用 NoopRegistry，使得所有埋点的地方都已空实现替代。\n1.API 依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.关于 ID Lookout metrics 相比传统的 metrics 库单一维度的信息描述，提供了支持多维度描述的 tags 能力。 Lookout metrics 的唯一标识 Id 类，由 name 和 tags 构成。\nId basicId = registry.createId(\u0026amp;quot;rpc.provider.service.stats\u0026amp;quot;); id = basicId.withTag(\u0026amp;quot;service\u0026amp;quot;, \u0026amp;quot;com.alipay.demo.demoService\u0026amp;quot;) .withTag(\u0026amp;quot;method\u0026amp;quot;, \u0026amp;quot;sayHi\u0026amp;quot;) .withTag(\u0026amp;quot;protocol\u0026amp;quot;, \u0026amp;quot;tr\u0026amp;quot;) .withTag(\u0026amp;quot;alias\u0026amp;quot;, \u0026amp;quot;group1\u0026amp;quot;); 上面是 Id 的简单示例了，如何创建 Id，如何打 tag，（每打一次 tag，都会生成并返回一个新的 Id 对象引用）切记！使用返回新的 Id 对象了哦。\n 不要主动缓存 Id 或具体的 Metric 对象,Lookout 的 Registry 已经登记记录了。相等的 Id （ name 和 tags 一样）会复用已有的Id 对应 Metric 对象。 2.1 Priority tag (不是必须) PRIORITY 枚举级别: HIGH, NORMAL, LOW;\nid.withTag(LookoutConstants.LOW_PRIORITY_TAG); 如果不打该 Tag (建议)，默认是 NORMAL 级别。级别代表了采集间隔周期（HIGH：2s, NORMAL: 30s, LOW: 1min）\n2.2 关于 tags 通用的 tags，比如：本机 ip，机房等详细会统一附上，不需要单独指定。 普通 Java 项目直接 lookout-client 时，tags 需要自己指定，特别记住：appName 别忘啦！tag:app=xx key 必须小写，尽量是字母，数字，下划线； （尤其是运行期的 Counter, Timer, DistributeSummary 这些 metrics）某个类型的 tag 的 values 尽量是稳定不变有限集合，而且 tags 尽量少，防止 metrics 数量超过最大限制！ 比如：rpc 场合 service, method 两个 tag 对应的值是有限较小的； 反例是每次 rpc 调用都有是个独立的 tag-value。 因此，总体原则自定义打 tags 时要尽量少，对应 values 的集合数量尽量小； 专门用途的 TAG 名称: \u0026amp;ldquo;priority\u0026amp;rdquo;: 表示优先级。 系统保留的 tag key 统配格式_*_,以下划线开始，以下划线结束（比如: \u0026amp;ldquo;type\u0026amp;rdquo; ）。 请不要使用这种格式的 key，可能会被系统覆盖或丢弃 3.可接入的统计( Metric )类型API Counter 「计数器」 场景：方法调用次数； 主动汇报的数据包括： count, rate (也就是 qps)； 使用方式 Counter counter=registry.counter(id); counter.inc(); Timer 「耗时统计器」 场景:统计任务，方法耗时，支持分桶统计 主动汇报的数据包括：elapPerExec (单次执行耗时), total 耗时，Max 耗时,（上报单位：秒）； 使用方式 Timer timer=registry.timer(id); timer.record(2, TimeUnit.SECONDS); DistributionSummary 「值分布情况统计器」 场景：比如 io 流量，支持分桶统计 主动汇报的数据包括: count, total(size), max(size)； 使用方式: DistributionSummary distributionSummary=registry.distributionSummary(id); distributionSummary.record(1024); Gauge 「即时数据观察」 场景：比如线程池，内存值等即时值； 主动汇报的数据包括: value； 往注册表中登记新 gauge 时，ID 值相等，注册表继续使用已有的(忽略新的)； 注意，推荐 gauge 观察的对象尽量是单例的（复用），并且建议在运行时一直活着（而不是作为一个临时的统计）！，如果不是单例或者只存活一段时间，那么一定要从 Registry 中 remove 掉，否则影响 GC（主要是它持有的外部对象引用无法释放，浪费空间）!!\n 使用方式: registry.gauge(id,new Gauge\u0026amp;lt;Double\u0026amp;gt;() { @Override public Double value() { return 0.1; } }); MixinMetric 「上述基本统计 metrics 的混合管理体」 MixinMetric 是 Lookout 特有的，表示多个基本 metrics 的混合体。引入该 Mixin 目的是优化对「同一度量目标」（即测量目标一致，tags 一致）的多测量指标传输和存储效率，比如：同一线程池的各种指标(线程总数，活跃总数，等待队列大小\u0026amp;hellip;)。\n 使用方式（比如，对一次服务调用，加入多个测量指标：调用耗时，输入字节，调用次数，输出字节等等） //1. getOrAdd MixinMetric MixinMetric rpcServiceMetric=registry.minxinMetric(id); //2. getOrAdd basic component metric to use Timer rpcTimer = rpcServiceMetric.timer(\u0026amp;quot;perf\u0026amp;quot;); DistributionSummary …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-api/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"76574f2435a3565fe1fc50831ff9ab0c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-api/","summary":"客户端 API 使用说明 SOFALookout 客户端设计上保持了 API 与实现解耦。如果我们只需要基于 SOFALookout API 进行埋点，那么只需要依赖 API 包即可。在没有依赖具体实现模块依赖时（比如","tags":null,"title":"客户端 API 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-api/","wordcount":1562},{"author":null,"categories":null,"content":" Registry 的使用 不同的 Registry 的集成提供了不同的访问 Metrics 的方式。\n1. LookoutRegistry 提供按照一定时间窗口统计 metrics 的能力。它又分为“主动推”和“被动拉”两种模式，暂时被动拉取模式处于关闭状态。\n（1）主动推模式\n可以通过【客户端配置】指定远程 Agent 的IP地址，即开始上报检查，和定时上报数据。 （2）被动拉模式\n可以通过【客户端配置】启动该模式，则在 19399 端口提供 HTTP 服务。更多交互细节请参考（待补充） 2. 对接到 Prometheus SOFALookout 的数据可以对接到 Prometheus 上面。为了将数据对接到 Prometheus 上面，首先需要在工程中加入依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-reg-prometheus\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 添加好依赖之后，启动应用，既可以访问 http://localhost:9494 来看到数据，其中 9494 为默认的端口，可以通过在 application.properties 里面配置 com.alipay.sofa.lookout.prometheus-exporter-server-port 来改变端口。\n有了访问数据的 URL 之后，可以编辑一个 prometheus.yml 来抓取该项目信息，假设本机 IP 地址为 10.15.232.20，那么可以配置如下的 prometheus.yml：\nscrape_configs: - job_name: \u0026#39;lookout-client\u0026#39; scrape_interval: 5s static_configs: - targets: [\u0026#39;10.15.232.20:9494\u0026#39;] 有了上面的配置文件之后，可以再到本地通过 Docker 来启动 Prometheus：\ndocker run -d -p 9090:9090 -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml --name prom prom/prometheus:master 然后通过浏览器访问: http://localhost:9090，再通过 PromQL 查询即可查询到对应的 Metrics。\nSOFALookout 中也提供了一个对接 Prometheus 的样例，大家可以前往自行查看。\n3. 对接 SpringBoot actuator 除了 Prometheus 之外，SOFALookout 可以与 SpringBoot 1.x 的 Actuator 的相集成，只需依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后启动后访问 http://localhost:8080/metrics 既可以看到通过 SOFALookout API 埋点的数据。\nSOFALookout 也提供了集成的样例工程，大家可以前往自行查看。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-registry/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3c51ba6519cee542b459a170dabcf32b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-registry/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-registry/","summary":"Registry 的使用 不同的 Registry 的集成提供了不同的访问 Metrics 的方式。 1. LookoutRegistry 提供按照一定时间窗口统计 metrics 的能力。它又分为“主动推”和“被动拉”两种模式，暂时被动拉取模","tags":null,"title":"客户端 Registry 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-registry/","wordcount":575},{"author":null,"categories":null,"content":" 1. 创建 Maven 工程 服务端部署完毕后，我们可以新建一个 Maven 工程使用 SOFARegistry 提供的服务。首先新建一个 Maven 工程，然后引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. 发布数据 // 构建客户端实例 RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // 构造发布者注册表 String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // 将注册表注册进客户端并发布数据 registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); 使用 SOFARegistry 发布数据一共包含三个步骤：\n 构建客户端实例; 构造发布者注册表; 将注册表注册进客户端并发布数据。 2.1 构建客户端实例 构建客户端实例的关键是创建 RegistryClientConfig 对象，创建 RegistryClientConfig 对象时需要指定 RegistryEndpoint 和 RegistryEndpointPort:\n RegistryEndpoint：注册中心任一 Session 节点地址； RegistryEndpointPort: Session 节点配置的 session.server.httpServerPort 端口值。 2.2 构造发布者注册表 构造发布注册表只需要创建 PublisherRegistration 并指定 dataId，dataId 是发布服务的唯一标识。\n2.3 发布数据 调用 RegistryClient 的 register 方法可以进行数据发布，该方法需要两个参数，第一个参数是发布注册表，指定了服务的 dataId，第二个参数是数据值，一般是一个字符串类型。\n3. 订阅数据 // 构建客户端实例 RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, global String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setScopeEnum(ScopeEnum.global); // 将注册表注册进客户端并订阅数据，订阅到的数据会以回调的方式通知 SubscriberDataObserver registryClient.register(registration); 使用 SOFARegistry 订阅数据一共包含四个步骤：\n 构建客户端实例; 创建 SubscriberDataObserver； 构造订阅者注册表； 将注册表注册进客户端并订阅数据。 其中创建客户端实例方式与上文发布数据时创建客户端实例的方法一致。\n3.1 创建 SubscriberDataObserver SubscriberDataObserver 是一个回调接口，该接口定义了 handleData 方法，该方法包含两个参数，分别是 dataId 及最终数据，当客户端收到服务端订阅的数据时会调用该方法。在 SOFARegistry 中，服务端返回数据用 UserData 表示，该类包含以下两个方法：\npublic interface UserData { Map\u0026amp;lt;String, List\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; getZoneData(); String getLocalZone(); } getLocalZone: 返回当前zone； getZoneData: 返回以 zone 为 key，每个 zone 的数据为 value 的数据。 3.2 构造订阅者注册表 构造订阅者注册表需要创建 SubscriberRegistration 对象，创建该对象需要指定 dataId 及 SubscriberDataObserver。\n3.3 订阅数据 调用 RegistryClient 的 register 方法可以进行数据订阅，该方法包含一个参数，只需传入 SubscriberRegistration 对象即可。\n如果先运行发布数据的程序，然后再运行订阅数据的程序，那么我们将在控制端看到如下输出：\nreceive data success, dataId: …","date":-62135596800,"description":"","dir":"projects/sofa-registry/client-quick-start/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"66e300d44b2f2a903d976bf83eb7c16e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/client-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/client-quick-start/","summary":"1. 创建 Maven 工程 服务端部署完毕后，我们可以新建一个 Maven 工程使用 SOFARegistry 提供的服务。首先新建一个 Maven 工程，然后引入如下依赖： \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. 发布数据 // 构建客户端","tags":null,"title":"客户端使用","type":"projects","url":"/sofastack.tech/projects/sofa-registry/client-quick-start/","wordcount":897},{"author":null,"categories":null,"content":" 该项目演示了如何在 SOFABoot 中使用 SOFALookout 并且对接到 Spring Boot 的 Actuator 中。如果想要对接到 Prometheus 上或者其他的 Registry 中，请参考 Registry 一节。\n新建 SpringBoot（或 SofaBoot ）项目 新建一个 Spring Boot 的应用（如果是 SOFABoot 工程按照 SOFABoot 文档 - 依赖管理中的方式引入 SOFABoot 即可）。\n引入 Lookout 的 Starter 依赖 在 pom.xml 中引入以下依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 如果 Spring Boot 项目需指定版本。\n新建一个 Metrics 指标 在完成依赖的引入之后，然后可以在 Spring Boot 中的启动类中，加入如下的方法：\n@Autowired private Registry registry; @PostConstruct public void init() { Counter counter = registry.counter(registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;).withTag(\u0026amp;quot;instant\u0026amp;quot;, NetworkUtil.getLocalAddress().getHostName())); counter.inc(); } 上面的代码中直接通过 @Autowired 注入了一个 Registry 的字段，通过这个 Registry 的字段，我们就可以创建对应的 Counter，然后通过修改这个 Counter 的数据来生成 SOFALookout 的 Metrics 的指标。\n添加配置项 在 SOFABoot 项目中，需要增加一个应用名的配置项：spring.application.name=xxx。\n与 Spring Boot Actuator 对接 新增了一个指标之后，我们可以选择对接到 Spring Boot Actuator 上，要对接到 Spring Boot Actuator 上面，需要添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 添加如上的依赖之后，我们在本地启动应用，访问 http://localhost:8080/metrics，就可以看到前面添加的指标，如下：\n\u0026amp;quot;http_requests_total.instant-MacBook-Pro-4.local\u0026amp;quot;: 1, 以上的 QuickStart 的代码在: lookout-client-samples-boot，大家可以下载作为参考。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-boot/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"27e057f8a8a4ac97f42ea66ca6a17fdd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","summary":"该项目演示了如何在 SOFABoot 中使用 SOFALookout 并且对接到 Spring Boot 的 Actuator 中。如果想要对接到 Prometheus 上或者其他的 Registry 中，请参考 Registry 一节。 新建 SpringBoot（或 SofaBoot ）项目 新建一","tags":null,"title":"客户端快速开始 - SOFABoot 项目","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","wordcount":490},{"author":null,"categories":null,"content":" 普通 Java 项目 在应用中加入 client 的 Maven 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; lookout-client 默认依赖了 lookout-reg-server 模块（支持向 lookout server 上报 metrics 数据），如果希望使用其他类型注册表(比如 lookout-reg-prometheus)，那么再加上对应依赖即可。\n开始使用 SOFALookout 的 Client 之前，首先需要构建一个全局的客户端实例（ com.alipay.lookout.client.DefaultLookoutClient ）\nLookoutConfig lookoutConfig = new LookoutConfig(); DefaultLookoutClient client = new DefaultLookoutClient(\u0026amp;quot;appName\u0026amp;quot;); //选择构建需要使用的 Registry(如果多个注册表类型，建议使用同一 lookoutConfig 实例，便于集中管理) LookoutRegistry lookoutRegistry = new LookoutRegistry(lookoutConfig); //客户端可以后置添加 registry 实例(至少要加一个) client.addRegistry(lookoutRegistry); //(可选)对已加入或后续加入的客户端的 registry 实例，统一注册扩展模块的 metrics client.registerExtendedMetrics(); 然后通过客户端拿取 Registry 实例，进行使用：\n//该注册表是个“组合”型的注册表 Registry registry = client.getRegistry(); //demo Id id = registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;); Counter counter = registry.counter(id); counter.inc(); 客户端的使用，可以详细参考样例工程。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-java/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5dc476aa21ece4789859f1af598d4445","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","summary":"普通 Java 项目 在应用中加入 client 的 Maven 依赖 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa.lookout\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;lookout-client\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${lookout.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; lookout-client 默认依赖了 lookout-reg-server 模块（支持向 lookout server 上报 metrics 数据），如果希望使用其他类型注册表(比如 lookout-reg","tags":null,"title":"客户端快速开始 - 普通 Java 项目","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","wordcount":311},{"author":null,"categories":null,"content":"客户端模块是一个较复杂的模块，这里包含了集群管理、路由、地址管理器、连接管理器、负载均衡器，还与代理、注册中心等模块交互。\n参见：\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/client-invoke-flow/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"310d99d64b808a3b526563e92c699952","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","summary":"客户端模块是一个较复杂的模块，这里包含了集群管理、路由、地址管理器、连接管理器、负载均衡器，还与代理、注册中心等模块交互。 参见：","tags":null,"title":"客户端调用流程","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","wordcount":64},{"author":null,"categories":null,"content":" 客户端配置项设置示例 lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026amp;quot;127.0.0.1\u0026amp;quot;); 客户端配置项说明 配置项 对应 SpringBoot 配置项 默认配置值 说明 lookout.enable com.alipay.sofa.lookout.enable true 功能开关，默认是 true。如果改为 false，那么所有 metrics 就几乎没有内存与计算消耗(空对象与空方法) lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 metrics 最大数目限制，超过会自动忽略 lookout.prometheus.exporter.server.port com.alipay.sofa.lookout.prometheus-exporter-server-port 9494 prometheus 抓取的端口 lookout.exporter.enable com.alipay.sofa.lookout.exporter-enable false 是否开启支持被动采集的服务 lookout.agent.host.address com.alipay.sofa.lookout.agent-host-address - 主动上报 Agent 服务器的注解地址，支持多个地址以逗号分隔 客户端日志配置说明 系统属性配置项 对应 SpringBoot 配置项 默认配置值 说明 -Dlogging.level.com.alipay.lookout=? logging.level.com.alipay.lookout warn lookout 客户端的日志级别，debug 可以看见汇报数据的详情 -Dlogging.path=? logging.path 当前用户目录 SpringBoot V1的日志目录调整，包括 \u0026amp;ldquo;lookout/\u0026amp;rdquo; 日志子目录 客户端配置自定义(适用于 SpringBoot 技术栈模式) 使用配置定制扩展: MetricConfigCustomizerConfig\n@Configuration public class MetricConfigCustomizerConfig { @Bean public MetricConfigCustomizer metricConfigCustomizer() { return new MetricConfigCustomizer() { @Override public void customize(MetricConfig metricConfig) { metricConfig.addProperty(\u0026amp;quot;testaa\u0026amp;quot;, \u0026amp;quot;testbb\u0026amp;quot;); } }; } } ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-configuration/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5fd84950d4d565d3fb20781337792bf1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/client-configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/client-configuration/","summary":"客户端配置项设置示例 lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026quot;127.0.0.1\u0026quot;); 客户端配置项说明 配置项 对应 SpringBoot 配置项 默认配置值 说明 lookout.enable com.alipay.sofa.lookout.enable true 功能开关，默认是 true。如果改为 false，那么所有 metrics 就几乎没","tags":null,"title":"客户端配置","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/client-configuration/","wordcount":298},{"author":null,"categories":null,"content":"包含单机故障剔除和 Hystrix 熔断。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e567dc5e291867e92c8dd1c4f953b768","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault/","summary":"包含单机故障剔除和 Hystrix 熔断。","tags":null,"title":"容灾恢复","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault/","wordcount":13},{"author":null,"categories":null,"content":" 本文档中提供了 MOSN 的示例工程。\n使用 MOSN 作为 HTTP 代理 请参考 MOSN 转发 HTTP 的示例工程 http-sample。\n使用 MOSN 作为 SOFARPC 代理 请参考 MOSN 转发 SOFARPC 的示例工程 sofarpc-sample。\n使用 MOSN 作为TCP 代理 请参考 MOSN 作为 TCP Proxy 的示例工程 tcpproxy-sample 。\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-samples/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"600c182fdee786a59e14899ba0fce8a1","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-run-samples/","summary":"本文档中提供了 MOSN 的示例工程。 使用 MOSN 作为 HTTP 代理 请参考 MOSN 转发 HTTP 的示例工程 http-sample。 使用 MOSN 作为 SOFARPC 代理 请参考 MOSN 转发 SOFARPC 的示例工程 sofa","tags":null,"title":"工程示例","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-run-samples/","wordcount":106},{"author":null,"categories":null,"content":" 源码工程中提供了一些样例工程，辅助说明项目的使用。样例工程的 readme 有使用补充说明，另外需要将这些 sample 工程单独的导入 IDE。\n客户端样例工程 lookout-client-samples-java 该样例工程展示了，在普通 Java 项目中,如何以代码形式使用和配置客户端。\n lookout-client-samples-boot 该样例工程展示了，在 SpringBoot(或SofaBoot) 项目中,如何使用和配置客户端。\n lookout-client-samples-prometheus 该样例工程展示了，在 SpringBoot(或SofaBoot) 项目中,如何使用和配置客户端使用 prometheus。\n lookout-samples-prom-push 该样例工程展示了，在 Java 项目中,使用 prometheus 客户端并以push方式（PushGateway）上报数据。\n服务器端样例工程 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-samples/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a8a0fcd3f99ce2fb46e4d543e30797c9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-samples/","summary":"源码工程中提供了一些样例工程，辅助说明项目的使用。样例工程的 readme 有使用补充说明，另外需要将这些 sample 工程单独的导入 IDE。 客户端样例工程 lookout-client-samples-java 该样例工","tags":null,"title":"工程示例","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-samples/","wordcount":261},{"author":null,"categories":null,"content":" Q：报错误 NoSuchMethodError 一般情况下该类错误由依赖冲突导致。已知的依赖冲突列举如下，遇到时选择性排除它们。\n日志冲突 commons-logging 冲突 \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-logging\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; logback-classic 冲突 在冲突位置将 logback-classic 排除，如 spring-boot-starter-logging 和 spring-test 为存在冲突的应用依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.3.4.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; snakeyaml 冲突 java.lang.NoSuchMethodError: org.yaml.snakeyaml.Yaml.\u0026amp;lt;init\u0026amp;gt;(Lorg/yaml/snakeyaml/constructor/BaseConstructor;)V spring-boot-starter-test 与 org.testng 中引用的 org.yaml 存在冲突。这里以排除 spring-boot-starter-test 中的 org.yaml 为例（也可在 org.testng 等冲突位置排除）\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.yaml\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;snakeyaml\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Q：报错 NoClassDefFoundError 一般情况下依赖缺失或者依赖冲突会导致该类问题。\nMockito 报错找不到类 SOFABoot 使用 Mockito 时，如果已经存在 spring-boot-starter-test 则无需重复引入 Mockito。\nQ：报错 No bean dataAccessConfigManager available ACTS 测试脚本指定的 Application 启动类中缺少 acts-core.xml，如图添加即可。\nQ：No runnable methods 一般是由于选择 Junit 运行 ACTS 测试脚本导致的，ACTS 测试脚本可使用 TestNG 方式运行。\nQ：生成模版异常 有较多情况会导致这一现象，常见的是新编写的类或者对类进行变更后，没有进行 mvn 编译。先执行 mvn clean install -Dmaven.test.skip=true，再进行模版生成。\nQ：编辑器设置入参错误 使用 ACTS IDE 操作入参时，出现无法选中或者设置数值出错等情况，一般是生成测试脚本操作有误，没有生成入参模版而直接生成测试脚本，导致初始生成的 YAML 中入参不正确。\n 解法一：删除测试脚本对应的 YAML 文件，然后打开 ACTS IDE 并右键入参设置 -\u0026amp;gt; 模版选择，编辑后保存则 YAML 文件会自动重建。 解法二：删除生成的测试脚本和 YAML 文件，首先生成入参的模版，再重新生成测试脚本即可，YAML 中会默认带入参设置； Q：报错 argument type mismatch 该问题一般是被测接口有多个同名重载方法导致的，从而引发反射时参数不匹配错误。\n解决方法 可以在脚本中重写 ACTS 测试基类的 findMethod 方法，返回真正被测的方法对象。下面的方法也适用于获取被测方法失败的情况。\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { Method method =null; try { method = VirtualAssetQueryService.class.getDeclaredMethod (\u0026amp;quot;query\u0026amp;quot;, QueryVirtualAssetListParam.class); } catch (NoSuchMethodException e) { e.printStackTrace(); } catch (SecurityException e) { e.printStackTrace(); } actsRuntimeContext.setTestedMethod(method); } 使用 ACTS IDE 编辑类的属性后保存取值失效 ACTS IDE 默认类是标准的 JavaBean 形式，会调用属性的 set 方法为其赋值，如果不存在 set 方法则无法保存取值。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/faq/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5f89d1f5695cbe6b669a8738741529bd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/faq/","summary":"Q：报错误 NoSuchMethodError 一般情况下该类错误由依赖冲突导致。已知的依赖冲突列举如下，遇到时选择性排除它们。 日志冲突 commons-logging 冲突 \u0026lt;exclusion\u0026gt; \u0026lt;artifactId\u0026gt;commons-logging\u0026lt;/artifactId\u0026gt; \u0026lt;groupId\u0026gt;commons-logging\u0026lt;/groupId\u0026gt; \u0026lt;/exclusion\u0026gt; logback-classic 冲突 在冲突位置将 logback-classic 排除，","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-acts/faq/","wordcount":776},{"author":null,"categories":null,"content":" Q: Readiness Check 有啥应用场景？ Liveness Check 和 Readiness Check 概念来自于 Kuberentes，分别代表运行时检查和启动时检查。Spring Boot 提供了 Liveness Check，但是没有提供 Readiness Check。利用 Readiness Check 的能力，SOFA 中间件中的各个组件只有在 Readiness Check 通过之后，才将流量引入到应用的实例中，比如 RPC，只有在 Readiness Check 通过之后，才会向服务注册中心注册，后面来自上游应用的流量才会进入。除了中间件可以利用 Readiness Check 的事件来控制流量，PAAS 系统也可以通过访问 http://localhost:8080/health/readiness 来获取应用的 Readiness Check 的状况，从而控制例如负载均衡设备等等的流量。\nQ: 是否可以在 SOFABoot 模块中定义 Controller 组件？ SOFABoot 模块一般用于封装对外发布服务接口的具体实现，属于业务层，Controller 属于展现层内容，我们不建议也不支持在 SOFABoot 模块中定义 Controller 组件，Controller 组件相关定义建议直接放在 Root Application Context。\nQ: 类隔离在蚂蚁内部使用是否广泛？ 类隔离在蚂蚁内部使用非常广泛，绝大部分业务应用都是运行在蚂蚁中间件自研的类隔离框架之上。主要是为了解决依赖冲突的问题，像蚂蚁金服这种体量的公司，业务线繁杂、基础服务组件众多，很难做到对所有 JAR 包做统一管控。特别涉及到跨团队模块组件相互依赖时，因为各自技术栈历史包袱的存在，难以有效统一冲突包版本。使用类隔离技术解决了实际开发中的很多痛点，业务开发者不需要担心自身依赖冲突的问题，在多团队协作开发中，也有很大的优势。\nQ: SOFABoot类隔离框架（SOFAArk）和 OSGI 容器有哪些差异？ 作为开源界早负盛名的动态模块系统，基于 OSGi 规范的 Equinox、Felix 等同样具备类隔离能力，然而他们更多强调的是一种编程模型，面向模块化开发，有一整套模块生命周期的管理，定义模块通信机制以及复杂的类加载模型。作为专注于解决依赖冲突的隔离框架，SOFAArk 专注于类隔离，简化了类加载模型，因此显得更加轻量。其次在 OSGi 规范中，所有的模块定义成 Bundle 形式，作为应用开发者，他需要了解 OSGi 背后的工作原理，对开发者要求比较高。在 SOFAArk 中，定义了两层模块类型，Ark Plugin 和 Ark Biz，应用开发者只需要添加隔离的 Ark Plugin 依赖，底层的类加载模型对应用开发者俩说是透明的，基本不会带来额外的学习成本。\nQ: SOFAArk 和 Java9 模块化有哪些差异？ Jigsaw 作为 Java9 模块化方案，抛开内部实现细节，在使用规范上和 OSGi 特别相似：模块的依赖、包导入导出、动态导出、可读性传递、模块服务注册与消费、开放模块、可选模块等等若干概念，相对于 SOFAArk 简单的包导入导出显然过于复杂。在实现细节上，考虑到 JDK 代码的兼容性，Jigsaw 没有采用类加载器隔离的方式，不同模块之间仍然可能是同一个类加载器加载。严格上来讲，Jigsaw 并没有解决同一个类多版本的问题，但是因为模块显示的依赖声明，使用纯 Jigsaw 模块化编程，不同版本类冲突的问题在编译期就能被检查或者启动失败，因为不允许不同模块含有相同类名的包。对于在实际开发中遇到的一类情况，例如两个组件依赖不同版本 hessian 包，即使这两个组件定义成了两个模块，运行时也只有一个hessian版本被加载，依然解决不了不同版本类共存的问题。另外，Jigsaw 相对 Ark 或者 OSGi 有一个明显的缺点，Jigsaw 不允许运行时动态发布模块服务，模块间的通信依赖在 module-info.java 中使用 provides 和 uses 静态注册和引用模块服务。当然，Jigsaw 有很多自己的优点，通过引入module-path，在 module 中显示声明模块依赖关系，避免了传统 maven/gradle 中因为间接依赖导致运行时加载类不确定的缺点；其次通过设置模块包的导入导出配置，可以完全做到接口和实现的分离，提升安全性；另外 Java9 本身借助模块化改造，使用jlink工具，开发者可以将自身应用必须的模块聚合，打包一个自定义的jre镜像。\nQ: 为什么使用 SNAPSHOT 版本拉取不到依赖？ 如果需要使用处于研发状态的 SNAPSHOT 版本，有两种方式：\n 拉取 sofa-ark 仓库代码，本地执行 mvn install。 在本地 maven setting.xml 文件增加如下 profile 配置: \u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; Q: 为什么使用 java -jar 启动 Spring Boot/SOFABoot 应用 Ark 包时，应用自动退出？ 因为 SOFAArk 容器不会开启任何非 Daemon 线程，如果是非 Web 应用或者应用启动时不会创建非 Daemon 线程，则应用在执行完 main 方法时，会正常退出。判断 Ark 包是否正常启动，可以观察是否有如下日志出现：\nArk container started in …","date":-62135596800,"description":"","dir":"projects/sofa-boot/faq/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"56f06d32d37d8a5947d7c7ee43d6d955","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/faq/","summary":"Q: Readiness Check 有啥应用场景？ Liveness Check 和 Readiness Check 概念来自于 Kuberentes，分别代表运行时检查和启动时检查。Spring Boot 提供了 Liveness Check，但是没有提供","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-boot/faq/","wordcount":2071},{"author":null,"categories":null,"content":" 与 Prometheus的差异 答：主要包括:（1）Lookout metrics server 支持适配更多的协议接入；（2）聚焦在围绕 ES 生态提供易使用和运维的最佳实践；（3）支持计算能力下推；（4）除了 Metrics 后期会有 tracing，eventing等方案； （5）对聚合函数和 REST API 都做了兼容性的扩展和增强；（6）支持分布式集群部署具备高可用能力。\nLookout客户端会提供多语言(c,go,python\u0026amp;hellip;)支持吗 答：暂时不会。因为 Lookout Gateway已经支持很多主流协议的数据上报，同时也支持自定义扩展。 如果非Java技术栈，我们推荐大家使用其他开源主流的sdk库，比如: Prometheus sdk，Metricbeat等\n\u0026amp;ldquo;In order to improve query performance, you need to add tag filtering! realQuery:jvm.classes.loaded\u0026amp;rdquo; 答：只输入metric name查询会影响查询性能，所以我们强制每个查询至少有一个 tag（label）的筛选能力，比如:\u0026amp;ldquo;jvm.classes.loaded{app=\u0026amp;ldquo;lookout-gateway\u0026amp;rdquo;}\u0026amp;ldquo;。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/faq/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f05d40c9d503ad466634f0473a5fac40","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/faq/","summary":"与 Prometheus的差异 答：主要包括:（1）Lookout metrics server 支持适配更多的协议接入；（2）聚焦在围绕 ES 生态提供易使用和运维的最佳实践；","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/faq/","wordcount":430},{"author":null,"categories":null,"content":" 咨询 Q: SOFARPC 是蚂蚁金服内部使用的版本吗？ 是的，SOFARPC 有良好的扩展接口，内部使用的版本就是在开源的版本多一些扩展实现。例如我们云上的商业版本集成了蚂蚁金融云的共享版注册中心、链路跟踪等产品；蚂蚁内部的版本集成了蚂蚁内部的注册中心、LDC路由等特性扩展。\nQ: SOFARPC 内部是用 Zookeeper 作为注册中心的吗？可以集成其它 etcd 等注册中心吗？ 在蚂蚁内部使用的是蚂蚁自研的注册中心产品。SOFARPC 的注册中心模块是可扩展的，对内对外使用的都是一套核心接口。目前开源的版本中集成了 Zookeeper，其它的注册中心实现社区已经在集成中。\nQ: 与Dubbo对比？ Dubbo 是阿里集团开源的一款非常优秀的RPC框架，高性能，具有良好的扩展性。Dubbo在国内开源界起步较早，使用者较多，开源生态更加丰富，目前已进入Apache基金会进行孵化。Dubbo最早在阿里巴巴B2B部门广泛使用。更多信息这里就不多介绍了。\nSOFARPC 最早起源于阿里集团内部的 HSF，但是经过了蚂蚁金服集团内部多年的独立发展，目前脱离为一个独立的产品。SOFARPC 在协议，网络，路由，可扩展性等层面都进行了大量的改造和优化的工作，以满足蚂蚁金服大规模金融级的业务场景。在蚂蚁金服内部，SOFARPC 在蚂蚁中间件（SOFAStack）的生态下，有完善的微服务技术栈支持，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量等等。截止 2019 年双十一，SOFARPC 已经被蚂蚁几千个系统所使用，生产环境发布的接口数量超过了十几万。\n但是在开源领域，SOFARPC 目前还是一个起步阶段，开源生态还在建设当中，随着开源计划的推进，我们会在后续的版本里增加各个周边组件，完善微服务技术栈。同时也欢迎大家来贡献，共同打造 SOFAStack。\n对于性能的对比，类似协议下使用的技术点都是差不多的，所以基本上可比性不高。 对于扩展性的对比，两者都具有良好的扩展性。 对于其它功能差异点的话，这里列一些已经开源或者即将开源的功能点供参考：SOFARPC 协议上将支持 HTTP/2、GRPC，能力上如服务预热权重、自动故障降级、协商机制、CRC数据校验等，结合 SOFABoot 可以实现 RPC 框架与业务的类隔离防止类冲突等等，另外 SOFARPC 在跨单元机房的路由，包括配合服务注册体系实现的对异地多活的支撑也是非常有特色的，期望后面能逐步跟大家分享讨论，甚至形成行业标准。而 SOFARPC 结合内部微服务下做一致性的框架实现的「微交易」架构也是蚂蚁在金融领域非常有价值的沉淀，也是跟 dubbo 体系不一样的地方。\nQ: 对比其他 RPC 框架有何优势？ 作为RPC框架，最基本的能力就是 RPC 调用，其它都是些性能、扩展性、功能性的差异，可能各家的侧重点不一样。\nSOFARPC 在蚂蚁金服内部大规模应用足以证明 SOFARPC 是一款可靠的生产级的 RPC 框架。而蚂蚁金服的金融的属性决定了 SOFARPC 在金融场景下的功能侧重点。\nQ: 和Spring Cloud 的对比？ SOFARPC 定位在 RPC 框架，和 Spring Cloud 的比较不在一个对比维度上面。 Spring Cloud 可对比的是 SOFAStack，SOFAStack 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，以及分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案。SOFAStack 的各个组件会在未来逐渐开源。\n另外，SOFARPC 的 Starter 是基于 Spring Boot 开发的，Spring Cloud 的各个组件也是基于 Spring Boot 开发的，所以两者并不冲突。\n研发类 Q: 为什么不使用 JDK8 SOFARPC 在蚂蚁金服内部还有JDK6的使用场景，所以编译选择JDK7，而编译级别选择JDK6。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/faq/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a6ec77ce5a423c5345394f42c64a416b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/faq/","summary":"咨询 Q: SOFARPC 是蚂蚁金服内部使用的版本吗？ 是的，SOFARPC 有良好的扩展接口，内部使用的版本就是在开源的版本多一些扩展实现。例如我们云上的商业版","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/faq/","wordcount":1533},{"author":null,"categories":null,"content":"SOFARPC 可以在使用 Bolt 通信协议的情况下，可以选择不同的序列化协议，目前支持 hessian2 和 protobuf。\n默认的情况下，SOFARPC 使用 hessian2 作为序列化协议，如果需要将序列化协议设置成 protobuf，在发布服务的时候，需要做如下的设置：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 即在 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签内增加 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签，并且设置 serialize-type 属性为 protobuf。\n对应的，在引用服务的时候，也需要将序列化协议改成 protobuf，设置方式和发布服务的时候类似：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot; jvm-first=\u0026amp;quot;false\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 目前，使用注解的方式尚不能支持设置序列化协议，这个将在后续的版本中支持，详见 ISSUE：https://github.com/sofastack/sofa-boot/issues/278\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/serialization/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"87e2faa84c2c7a7605243dc096bc4e17","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/serialization/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/serialization/","summary":"SOFARPC 可以在使用 Bolt 通信协议的情况下，可以选择不同的序列化协议，目前支持 hessian2 和 protobuf。 默认的情况下，SOFARPC 使用 hessian2 作为序列化协议，如","tags":null,"title":"序列化协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/serialization/","wordcount":296},{"author":null,"categories":null,"content":" SLF4J 提供了 MDC （Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。本文将介绍 SOFATracer 集成的 SLF4J MDC功能，方便用户在只简单修改日志配置文件的前提下输出当前 SOFATracer 上下文 TraceId 以及 SpanId 。\n使用前提 为了在应用中的日志正确打印 TraceId 和 SpanId 参数，我们的日志编程接口需要面向 SLF4J 进行编程，即打印日志的编程接口不要依赖具体的日志实现。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入依赖 如果是 SOFABoot 或者 Spring Boot 的应用具体的日志实现需要大家去引入，我们推荐的日志打印实现是 Logback 和 Log4j2，不推荐 Log4j，同时日志实现建议只使用一个而不要使用多个实现。\n Logback 实现引入： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Log4j2 实现引入： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-log4j2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!--SOFABoot 没有管控 log4j2 版本 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置方法 我们基于 SLF4J MDC 的原理打印对应的 TraceId 和 SpanId，首先我们的应用中的日志编程接口应该面向 SLF4J，如通过如下的方式：\n//引入接口 import org.slf4j.Logger; import org.slf4j.LoggerFactory; //构造日志打印实例 private static final Logger logger = LoggerFactory.getLogger(XXX.class); 其次，我们为了正确打印 TraceId 和 SpanId 参数，我们还需要在日志的配置文件中配置 PatternLayout 的额外参数，这两个参数是 %X{SOFA-TraceId} 和 %X{SOFA-SpanId}，参数值我们均是从 MDC 中获取的值。\n以 Logback 为例配置的 pattern 参数：\n\u0026amp;lt;pattern\u0026amp;gt;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId}, %X{SOFA-SpanId}] ---- %m%n\u0026amp;lt;/pattern\u0026amp;gt; 关键配置项目：[%X{SOFA-TraceId},%X{SOFA-SpanId}] 作为 Logback pattern 的一部分，在对应的 appender 被调用的时候，会根据 pattern 中的占位符替换为当前线程上下文中 TraceId 和 SpanId 的具体值，当前线程中没有对应的 TraceId 和 SpanId 值时，会用“空字符串”替代。 Log4j2 配置 PatternLayout 样例：\n\u0026amp;lt;PatternLayout pattern=\u0026amp;quot;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId},%X{SOFA-SpanId}] ---- %m%n \u0026amp;quot; /\u0026amp;gt; Log4j 配置 PatternLayout 样例：\n\u0026amp;lt;layout class=\u0026amp;quot;org.apache.log4j.PatternLayout\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;param name=\u0026amp;quot;ConversionPattern\u0026amp;quot; value=\u0026amp;quot;%d %-5p %-32t [%X{SOFA-TraceId},%X{SOFA-SpanId}] - %m%n\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/layout\u0026amp;gt; 需要注意的是：[%X{SOFA-TraceId},%X{SOFA-SpanId}] 使我们推荐的打印格式，用户可以根据自己的实际需求场景进行定制\n 附:基于 Log4j2 示例工程的源代码地址。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/print-traceid-spanid/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0d8cc680f811d1db2cffddbba269571c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","summary":"SLF4J 提供了 MDC （Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。本文将介绍 SOFATracer 集成的 SLF4J MDC功能，方便用户在只","tags":null,"title":"应用日志打印 traceId 和 spanId","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","wordcount":701},{"author":null,"categories":null,"content":" SOFADashboard 支持查看应用的IP、端口、健康检查状态等基本信息。此功能依赖 SOFADashboard client ，如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可：\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dashboard-client-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; 除此之外，SOFADashboard 解耦了类似于 SpringBoot Admin 客户端和服务端直连的模式，引入了第三方的储存，目前默认是 redis，因此如果希望能够监控 更多 actuator 信息，可以添加如下依赖：\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dashboard-ext-redis-store\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; 功能展示 相关数据的展示采用了 react-json-view 组件，是的可以直观的看到原始数据集。\n应用维度展示 应用实例 基础信息 健康检查详细数据 环境变量 loggins mappings 配置 client , prefix : com.alipay.sofa.dashboard.client\n 属性 名称 默认值 备注 enable 是否可用 true 当开启时，dashboard client 的相应功能才会作用 instanceIp 指定当前实例的IP 地址 \u0026amp;rdquo;\u0026amp;rdquo; 一般用于测试或者需要指定 IP 的场景 storeInitDelayExp 初始上报延迟 30s Dashboard度量数据存储上报延迟期望(s) storeUploadPeriodExp 上报周期 60s Dashboard度量数据存储上报周期(s) virtualHost 虚拟地址 \u0026amp;rdquo;\u0026amp;rdquo; 服务发布虚拟host（同SofaRpc中相同定义），可使用-Dcom.alipay.sofa.rpc.virtual.host引入 virutalPort 虚拟端口 \u0026amp;rdquo;\u0026amp;rdquo; 服务发布虚拟port（同SofaRpc中相同定义），可使用-Dcom.alipay.sofa.rpc.virtual.port引入 internalHost 内部地址 \u0026amp;rdquo;\u0026amp;rdquo; 容器内部地址（例如podIp等)，可使用-Dcom.alipay.sofa.rpc.virtual.internal.host引入 arkEnable 是否启用ark管理 true 当开启时，dashboard client的相应功能才会作用 注：virtualHost，virutalPort 如果通过com.alipay.sofa.rpc指定了相应参数，则不需要通过dashborad再次指定\nzookeeper , prefix : com.alipay.sofa.dashboard.zookeeper\n 属性 名称 默认值 备注 address 地址 true baseSleepTimeMs 客户端错误重试间隔(ms). 1000 maxRetries 客户端最大重试次数 3 sessionTimeoutMs 客户端会话超时时间(ms) 6000 connectionTimeoutMs 客户端超时时间(ms) 6000 redis , prefix : com.alipay.sofa.dashboard.redis\n 属性 名称 默认值 备注 enble 是否可用 true 当开启时，dashboard会使用redis作为存储 recordTtl 上报周期(ms). 3600 url redis对应url 例如：redis://user:password@example.com:6379 host redis对应host（单实例模式） port redis对应port（单实例模式） password redis密码 Sentinel.master Sentinel模式master master节点名，需参阅集群搭建设置 Sentinel.nodes Sentinel模式节点地址 例如host1:port1;host2:port2;host3:port3 Cluster.nodes Cluster模式节点地址 例如host1:port1;host2:port2;host3:port3 Cluster.maxRedirects Cluster模式重定向次数 0 建议给值，例如10 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/dashboard-client/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"60586c6dfee1f2afcdac88cbe7a36b83","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/dashboard-client/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/dashboard-client/","summary":"SOFADashboard 支持查看应用的IP、端口、健康检查状态等基本信息。此功能依赖 SOFADashboard client ，如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可： \u0026lt;denpendency\u0026gt;","tags":null,"title":"应用面板","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/dashboard-client/","wordcount":1078},{"author":null,"categories":null,"content":" 首先参考基本代码贡献需知 注意测试用例覆盖率； 代码格式； 验证 Samples 单独导入 Samples 的 Maven 项目； 修改对应 Pom 文件中依赖版本； 验证 Samples 也能正确工作； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/development-use-guide/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"423a54ec3f5fbfc9c0e150eb853738ae","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/development-use-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/development-use-guide/","summary":"首先参考基本代码贡献需知 注意测试用例覆盖率； 代码格式； 验证 Samples 单独导入 Samples 的 Maven 项目； 修改对应 Pom 文件中依赖版本； 验证 Samples 也能正确工作；","tags":null,"title":"开发指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/development-use-guide/","wordcount":63},{"author":null,"categories":null,"content":" 1.如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后在代码目录下执行如下命令：\n mvn clean install 2.版本发布 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号，例如 1.0.1。\n参见: http://semver.org/lang/zh-CN/。\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表 BugFix 版本。只做 bug 修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 1.3.0，那么将会维护 1.2.x 的 bugfix 分支，而 1.1.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 1.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 1.3.0。 发布后拉起下一个版本，例如 1.3.1-SNAPSHOT。 3.测试 单元测试 单元测试例子放到自己开发的模块下，测试类的包名与被测试类所在包相同。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/developer-guide/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fcacc7e89b979f3aec8dc3333a7a3c37","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-acts/developer-guide/","summary":"1.如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后在代码目录下执行如下命令： mvn clean install 2.版本发布 版本号 采用三位版本号，分别是主版","tags":null,"title":"开发者手册","type":"projects","url":"/sofastack.tech/projects/sofa-acts/developer-guide/","wordcount":404},{"author":null,"categories":null,"content":"介绍实现架构和相关的细节介绍： * 如何编译 * 架构介绍 * 调用流程 * 基础模型 * 扩展点设计 * 版本发布 * 测试\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/developer-guide/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"903b9f3a5372a75d654f8eeaaf750eeb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/developer-guide/","summary":"介绍实现架构和相关的细节介绍： * 如何编译 * 架构介绍 * 调用流程 * 基础模型 * 扩展点设计 * 版本发布 * 测试","tags":null,"title":"开发者手册","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/developer-guide/","wordcount":49},{"author":null,"categories":null,"content":" 线程中使用 java.lang.Runnable 如果用户在代码中通过 java.lang.Runnable 新启动了线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFATracer 提供的 com.alipay.common.tracer.core.async.SofaTracerRunnable 默认完成了此操作，大家可以按照如下的方式使用：\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.start(); 线程中使用 java.util.concurrent.Callable 如果用户在代码中通过 java.util.concurrent.Callable 新启动线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFATracer 提供的 com.alipay.common.tracer.core.async.SofaTracerCallable 默认完成了此操作，大家可以按照如下的方式使用：\nExecutorService executor = Executors.newCachedThreadPool(); SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt; sofaTracerSpanSofaTracerCallable = new SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt;(new Callable\u0026amp;lt;Object\u0026amp;gt;() { @Override public Object call() throws Exception { return new Object(); } }); Future\u0026amp;lt;Object\u0026amp;gt; futureResult = executor.submit(sofaTracerSpanSofaTracerCallable); //do something in current thread Thread.sleep(1000); //another thread execute success and get result Object objectReturn = futureResult.get(); 这个实例中，假设 java.util.concurrent.Callable 返回结果的对象类型是 java.lang.Object，实际使用时可以根据情况替换为期望的类型。\nSOFATracer 对线程池、异步调用场景下的支持 异步场景 异步调用，以 rpc 调用为例，每次 rpc 调用请求出去之后不会等待到结果返回之后才去发起下一次处理，这里有个时间差，在前一个 rpc 调用的 callback 回来之前，又一个新的 rpc 请求发起，此时当前线程中的 TracerContext 没有被清理，则 spanId 会自增，tracerId 相同。\n 对于上面这种情况，SOFATracer 在对于异步情况处理时，不会等到 callback 回来之后，调用 cr 阶段才会清理，而是提前就会清理当前线程的 tracerContext 上下文，从而来保证链路的正确性。\n线程池 目前来说，不管是 SOFARPC 还是 Dubbo 的埋点实现，在使用单线程或者线程池时，情况是一样的：\n 同步调用，线程池中分配一个线程用于处理 rpc 请求，在请求结束之前会一直占用线程；此种情况下不会造成下一个 rpc 请求错拿上一个请求的 tracerContext 数据问题 异步调用，由于异步回调并非是在 callback 中来清理上下文，而是提前清理的，所以也不会存在数据串用问题。 callback 异步回调，这个本质上就是异步调用，所以处理情况和异步调用相同。 附：案例工程\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/async/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e755346c441115663c101638667fe4c0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/async/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/async/","summary":"线程中使用 java.lang.Runnable 如果用户在代码中通过 java.lang.Runnable 新启动了线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFA","tags":null,"title":"异步线程处理","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/async/","wordcount":726},{"author":null,"categories":null,"content":" 本文用于帮助初次接触 MOSN 项目的开发人员，快速搭建开发环境，完成构建，测试，打包和示例代码的运行。\n注：MOSN 基于 Go 1.12.7 开发，使用 dep 进行依赖管理。\n准备运行环境 如果您使用容器运行 MOSN，请先 安装 docker 如果您使用本地机器，请使用类 Unix 环境 安装 Go 的编译环境 安装 dep : 参考官方安装文档 获取代码 MOSN 项目的代码托管在 Github，获取方式如下：\ngo get -u mosn.io/mosn 如果您的 go get 下载存在问题，请手动创建项目工程\n# 进入 GOPATH 下的 src 目录 cd $GOPATH/src # 创建 mosn.io 目录 mkdir -p mosn.io cd mosn.io # 克隆 MOSN 代码 git clone git@github.com:mosn/mosn.git cd mosn 最终 MOSN 的源代码代码路径为 $GOPATH/src/mosn.io/mosn\n导入IDE 使用您喜爱的 Go IDE 导入 $GOPATH/src/mosn.io/mosn 项目，推荐 Goland。\n编译代码 在项目根目录下，根据自己机器的类型以及欲执行二进制的环境，选择以下命令编译 MOSN 的二进制文件。\n使用 docker 镜像编译 make build // 编译出 linux 64bit 可运行二进制文件 本地编译 使用下面的命令编译本地可运行二进制文件。\nmake build-local 在非 Linux 机器交叉编译 Linux 64bit 可运行二进制文件。\nmake build-linux64 在非 Linux 机器交叉编译 Linux 32bit 可运行二进制文件。\nmake build-linux32 完成后可以在 build/bundles/${version}/binary 目录下找到编译好的二进制文件。\n打包 在项目根目录下执行如下命令进行打包。\nmake rpm 完成后可以在 build/bundles/${version}/rpm 目录下找到打包好的文件。\n创建镜像 执行如下命令进行镜像创建。\nmake image 运行测试 在项目根目录下执行如下命令运行单元测试：\nmake unit-test 在项目根目录下执行如下命令运行集成测试（较慢）。\nmake integrate 从配置文件启动 MOSN 运行下面的命令使用配置文件启动 MOSN。\n./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; 开启 MOSN 转发示例程序 参考 examples 目录下的示例工程运行 Samples。\n使用 MOSN 搭建 Service Mesh 平台 请参考与 Istio 集成。\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-setup/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d41615315adb522aa4b84762f113a574","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-setup/","summary":"本文用于帮助初次接触 MOSN 项目的开发人员，快速搭建开发环境，完成构建，测试，打包和示例代码的运行。 注：MOSN 基于 Go 1.12.7 开发，使用 dep 进行依赖管理。","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-setup/","wordcount":614},{"author":null,"categories":null,"content":" 本文档共分为四部分：\n 第一部分：在 Intellij IDEA 上安装 ACTS IDE 可视化编辑器； 第二部分：向您介绍如何在多模块工程中引入 ACTS 依赖； 第三部分：测试模块下一键搭建 ACTS 框架以管理后续 ACTS 用例； 第四部分：一键生成 ACTS 测试脚本； 1.安装 ACTS IDE 推荐使用 Intellij IDEA 2017，为了您的安全，请仅从该下载源获取 ACTS IDE 安装包： 点击下载 ACTS IDE，\n本地磁盘安装：Preference -\u0026amp;gt; Plugins -\u0026amp;gt; Install plugin from disk -\u0026amp;gt; Restart IDEA 即可。 2.引入 ACTS 依赖 在引入依赖之前，需要您的应用是一个多模块工程（包含 test 模块），后续 ACTS 会将全部的测试代码放置在 test 模块下以便管理 ACTS 用例。\n您可以依据应用的具体情况，选择性阅读以下内容：\n应用已经是完整的多模块工程，可参考文档 2.1 部分，帮助您引入 ACTS 依赖； 应用是多模块工程但无 test 模块，可参考文档 2.2 部分，帮助您快速添加 test 模块； 应用不是一个多模块工程，可参考文档 2.3 部分，帮助您快速构建多模块工程。 如果还没有创建工程，可参考 SOFABoot 快速开始搭建应用。\n2.1多模块应用-包含 test 模块 只需在 test 模块的 pom.xml 中引入 acts-bom 即可。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2多模块应用-无 test 模块 这里是使用 Intellij IDEA 来创建子模块。\n对着父工程右键 -\u0026amp;gt; New -\u0026amp;gt; Module -\u0026amp;gt; 输入 test 模块名字（一般是 appname-test），分步示例图如下：\n第一步：新建 test 模块 第二步：管理 test 模块 在父工程的 pom.xml 中管理刚刚新建的 test 模块。\n第三步：依赖 ACTS 引入 最后，找到刚刚新建的 test 模块，并在其 pom.xml 中引入 acts-bom 即可。\n\u0026amp;lt;!-- 引入包含 SOFABootApplication 的 pom --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.example\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;example-service\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- 引入 ACTS 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.3非多模块应用 如果你已经有了一个不错的 SOFABoot 应用，但它不是一个多模块应用，下面的内容将帮助你快速地将现有工程构建为多模块工程。\n第一步：新建父工程 创建好一个 SOFABoot 工程，然后删除无关的文件，只需保留 pom.xml 文件。\n第二步：新建子模块 新建子工程模块，将原有应用作为子工程并入父工程下，相关依赖管理提到父工程中。以新建 service 模块和 test 模块为例。\n第三步：管理子模块 第四步：依赖引入 最后，在 test 模块的 pom.xml 文件中引入 acts-bom 即可。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 3.一键初始化 ACTS 测试框架 下面只需要你轻轻动动手指即可完成初始化工作。在图3.2中，您需要正确填写应用名称并选择适合应用的编码格式。\n有关一键初始化生成的文件有何作用，可以参考 ACTS 使用手册的框架准备部分。\n4.一键生成测试脚本 4.1启动类 将 service 模块中的启动类，如 SOFABootApplication 拷贝到 test 模块，并增加需要加载的配置文件：classpath*:META-INF/spring/acts-core.xml\n4.2测试脚本 前提条件：务必 mvn 编译工程和生成对象模型，否则会造成 ACTS IDE 不可预料的错误，如无法编辑、数据不正确等。\n接口定义的方法上点击，选择 ACTS 功能 -\u0026amp;gt; 生成测试用例，并在刚生成的测试脚本中矫正 SOFABoot 启动类的 import 位置。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/getting-started/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dfc5fb9b394ea14c280568dcb881a8b0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/getting-started/","summary":"本文档共分为四部分： 第一部分：在 Intellij IDEA 上安装 ACTS IDE 可视化编辑器； 第二部分：向您介绍如何在多模块工程中引入 ACTS 依赖； 第三部分：测试模块下一键搭建 ACTS 框","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-acts/getting-started/","wordcount":1074},{"author":null,"categories":null,"content":" 在本文档中，将创建一个 Spring Boot 的工程，引入 SOFABoot 基础依赖，并且引入 SOFABoot 的健康检查扩展能力，演示如何快速上手 SOFABoot。\n环境准备 要使用 SOFABoot，需要先准备好基础环境，SOFABoot 依赖以下环境： - JDK7 或 JDK8 - 需要采用 Apache Maven 3.2.5 或者以上的版本来编译\n创建工程 SOFABoot 是直接构建在 Spring Boot 之上，因此可以使用 Spring Boot 的工程生成工具 来生成，在本文档中，我们需要添加一个 Web 的依赖，以便最后在浏览器中查看效果。\n引入 SOFABoot 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。 然后，添加 SOFABoot 健康检查扩展能力的依赖及 Web 依赖(方便查看健康检查结果)：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 最后，在工程的 application.properties 文件下添加 SOFABoot 工程常用的参数配置，其中 spring.application.name 是必需的参数，用于标示当前应用的名称；logging path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFABoot Demo # logging path logging.path=./logs 运行 可以将工程导入到 IDE 中运行生成的工程里面中的 main 方法（一般上在 XXXApplication 这个类中）启动应用，也可以直接在该工程的根目录下运行 mvn spring-boot:run，将会在控制台中看到启动打印的日志：\n2018-04-05 21:36:26.572 INFO ---- Initializing ProtocolHandler [\u0026amp;quot;http-nio-8080\u0026amp;quot;] 2018-04-05 21:36:26.587 INFO ---- Starting ProtocolHandler [http-nio-8080] 2018-04-05 21:36:26.608 INFO ---- Using a shared selector for servlet write/read 2018-04-05 21:36:26.659 INFO ---- Tomcat started on port(s): 8080 (http) 可以通过在浏览器中输入 http://localhost:8080/sofaboot/versions 来查看当前 SOFABoot 中使用 Maven 插件生成的版本信息汇总，结果类似如下：\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Built-Time: \u0026amp;quot;2018-04-05T20:55:26+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.4\u0026amp;quot; } ] 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，sofaboot/versions 更改为 actuator/versions\n可以通过在浏览器中输入 http://localhost:8080/health/readiness 查看应用 Readiness Check 的状况，类似如下：\n{ status: \u0026amp;quot;UP\u0026amp;quot;, sofaBootComponentHealthCheckInfo: { status: \u0026amp;quot;UP\u0026amp;quot; }, springContextHealthCheckInfo: { status: \u0026amp;quot;UP\u0026amp;quot; }, DiskSpace: { status: \u0026amp;quot;UP\u0026amp;quot;, total: 250140434432, free: 22845308928, threshold: 10485760 } } 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，health/readiness 更改为 actuator/readiness\nstatus: \u0026amp;quot;UP\u0026amp;quot; 表示应用 Readiness Check 健康的。可以通过在浏览器中输入 http://localhost:8080/health 来查看应用的运行时健康状态（可能会随着时间发生变化）。\n注: 在 SOFABOOT 3.X 中调整了 endpoint 路径，/health 更改 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/quick-start/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7f582b905fde4a56791c03d4dd6b5a57","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/quick-start/","summary":"在本文档中，将创建一个 Spring Boot 的工程，引入 SOFABoot 基础依赖，并且引入 SOFABoot 的健康检查扩展能力，演示如何快速上手 SOFABoot。 环境准备 要使用 SOFABo","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-boot/quick-start/","wordcount":2154},{"author":null,"categories":null,"content":" 这个快速开始可以帮您快速在您的电脑上，下载、安装并使用 SOFADashboard。\n环境准备 sofa-dashboard-backend 依赖 Java 环境来运行。请确保是在以下运行环境可以正常使用:\n JDK 1.8+；下载 \u0026amp;amp; 配置。 Maven 3.2.5+；下载 \u0026amp;amp; 配置。 sofa-dashboard-frontend 使用了 Ant Design Pro 脚手架，前端环境请参考 Ant Design\n数据库初始化 Mysql 版本：5.6+\n SOFAArk 管控需要依赖 MySQL 进行资源数据存储，工程目录下有一个 SofaDashboardDB.sql 脚本文件，可以通过执行这个脚本文件进行数据库表的初始化。\nZookeeper  ZooKeeper 3.4.x and ZooKeeper 3.5.x\n SOFADashboard 中的服务治理、SOFAArk 管控依赖于 Zookeeper，需要本地启动 Zookeeper 服务： ZooKeeper Document。\n后端运行 \u0026amp;gt; git clone https://github.com/sofastack/sofa-dashboard.git \u0026amp;gt; cd sofa-dashboard \u0026amp;gt; mvn clean package -DskipTests \u0026amp;gt; cd sofa-dashboard-backend/sofa-dashboard-web/target/ \u0026amp;gt; java -jar sofa-dashboard-web-1.0.0-SNAPSHOT.jar 前端运行 sofa-dashboard-front 是 SOFADashboard 的前端代码工程，基于蚂蚁金服开源的前端框架 antd 开发。\n\u0026amp;gt; cd sofa-dashboard-front \u0026amp;gt; npm i \u0026amp;gt; npm run dev 案例工程 sofastack-dashboard-guides ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/quick-start/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa4c5f48810727f71d675255f19617a3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/quick-start/","summary":"这个快速开始可以帮您快速在您的电脑上，下载、安装并使用 SOFADashboard。 环境准备 sofa-dashboard-backend 依赖 Java 环境来运行。请确保是在以下运行环境可以正常","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/quick-start/","wordcount":313},{"author":null,"categories":null,"content":"SOFARPC 有多种编程界面，下面会对各种界面进行举例： - SOFARPC 方式 - SOFABoot 方式\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"990bb2211b02b04c3ab6e03f3ba1f74b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started/","summary":"SOFARPC 有多种编程界面，下面会对各种界面进行举例： - SOFARPC 方式 - SOFABoot 方式","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started/","wordcount":30},{"author":null,"categories":null,"content":" SOFATracer 接入的组件列表参考：SOFATracer 介绍，在使用时请注意不同组件对应的SOFATracer 版本和 JDK 版本。\n环境准备 要使用 SOFABoot，需要先准备好基础环境，SOFABoot 依赖以下环境： - JDK7 或 JDK8 - 需要采用 Apache Maven 3.2.5 或者以上的版本来编译\n示例列表 下面所有 Samples 工程均为 SOFABoot 工程(同时支持 SpringBoot 工程中使用)，关于如何创建 SOFABoot 工程请参考 SOFABoot 快速开始。\n 组件接入 Spring MVC 埋点接入 HttpClient 埋点接入 DataSource 埋点接入 RestTemplate 埋点接入 OkHttp 埋点接入 Dubbo 埋点接入 采样 上报数据到 Zipkin ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/component-access/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"143f2b9022161ae5a7b10d261752ae5f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/component-access/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/component-access/","summary":"SOFATracer 接入的组件列表参考：SOFATracer 介绍，在使用时请注意不同组件对应的SOFATracer 版本和 JDK 版本。 环境准备 要使用 SOFABoot","tags":null,"title":"快速开始指南","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/component-access/","wordcount":209},{"author":"向旭","categories":null,"content":"TODO\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/code-analyze/summary/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d6fe0ca21825accb191a9eedccf17358","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/summary/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/summary/","summary":"TODO","tags":null,"title":"总览","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/summary/","wordcount":1},{"author":null,"categories":null,"content":" SOFATracer 此前的埋点均是基于组件维度的埋点，用户很难在自己业务代码中进行埋点操作，或者增加自定义 tag 值来监控一些链路信息。基于此，SOFATracer 从 2.4.1\u0026amp;frasl;3.0.6 版本开始支持手动埋点和基于注解的埋点方式，帮助用户解决自定义埋点问题。\n使用方式 自定义埋点提供了两种方式，一种是手动埋点，一种是基于注解方式埋点。\n手动埋点 手动埋点的方式遵循 opentracing 规范，SOFATracer 中通过 beforeInvoke 和 afterInvoke 两个函数封装了 span 的周期，如下：\n// 注入 tracer @Autowired Tracer tracer; private void testManual(){ try { // beforeInvoke 开始 SofaTracerSpan sofaTracerSpan = ((FlexibleTracer) tracer).beforeInvoke(\u0026amp;quot;testManual\u0026amp;quot;); sofaTracerSpan.setTag(\u0026amp;quot;manualKey\u0026amp;quot;,\u0026amp;quot;glmapper\u0026amp;quot;); // do your biz } catch (Throwable t){ // 异常结束 ((FlexibleTracer) tracer).afterInvoke(t.getMessage()); } finally { // 正常结束 ((FlexibleTracer) tracer).afterInvoke(); } } 这种方式在使用上没有直接使用注解方便，但是可以直观的了解到 span 的生命周期，另外手动埋点也是对基于注解方式埋点的一种补充，下面介绍。\n基于注解方式 SOFATracer 中提供了 @Tracer 注解，其作用域是 method 级别。\n// 在 hello 方法上使用 @Tracer 注解进行埋点 @Tracer public String hello(String word){ // 自定义 tag 数据 SpanTags.putTags(\u0026amp;quot;author\u0026amp;quot;,\u0026amp;quot;glmapper\u0026amp;quot;); // 失效 helloInner(word); return \u0026amp;quot;glmapper : hello \u0026amp;quot; + word; } // 在 hello 方法上使用 @Tracer 注解进行埋点 @Tracer private String helloInner(String word){ return \u0026amp;quot;glmapper : hello \u0026amp;quot; + word; } @Tracer 是基于 Spring Aop 实现，因此一定程度上依赖 Spring 中的代理机制。如代码片段中所示，helloInner 方法由于执行过程中不会使用代理对象，而是 this，所以会导致 helloInner 的注解埋点失效。那么对于此种情况，就可以使用手动埋点的方式来弥补。\nSpanTags 是 SOFATracer 中提供的工具类，在使用注解或者手动埋点的情况下，可以通过此类提供的静态方法来设置 tag 。\n日志格式 json 格式 {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-05 10:23:53.549\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;flexible-sample\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9291567650233504100130712\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.2\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;4ms\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;hello\u0026amp;quot;,\u0026amp;quot;param.types\u0026amp;quot;:\u0026amp;quot;java.lang.String\u0026amp;quot;,\u0026amp;quot;author\u0026amp;quot;:\u0026amp;quot;glmapper\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} 非 json 格式 2019-09-05 10:25:50.992,flexible-sample,0a0fe9291567650350953100130778,0.2,client,,http-nio-8080-exec-1,4ms,hello,param.types=java.lang.String\u0026amp;amp;author=glmapper\u0026amp;amp;,,\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/flexible/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5aaadb77e734e58428a0852d14888e92","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/flexible/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/flexible/","summary":"SOFATracer 此前的埋点均是基于组件维度的埋点，用户很难在自己业务代码中进行埋点操作，或者增加自定义 tag 值来监控一些链路信息。基于此，SOFATracer","tags":null,"title":"手动埋点","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/flexible/","wordcount":566},{"author":null,"categories":null,"content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAArk 实现原理》第二篇，本篇作者盲僧，来自 OYO。《剖析 | SOFAArk 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附系列共建列表，目前已完成领取。\n前言 SOFAArk 是 SOFA 团队开源的又一款扛鼎力作，它是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署的能力。\n从 2016 年底开始，蚂蚁金服内部开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2021 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构，也是为系列文章做好铺垫。\nSOFAArk Biz 的打包插件是 sofa-ark-maven-plugin ，它可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式的 Ark 包或者 Ark Biz 包，关于 Ark 包和 Ark Biz 包可以参考这里：\n Ark 包：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/ Ark Biz：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/ 本文将从如下三个方面进行介绍：先对插件的使用和打包出来的产物做一个简单介绍，然后告诉大家调试插件的方法，最后对整个插件的原理做一个流程图和阐述。\nSOFAArk ：https://github.com/sofastack/sofa-ark\nSOFAArk 插件使用 文中的示例代码可以参考 我的 github。\n 插件使用 先将 Spring Boot 的打包插件 spring-boot-maven-plugin 删除或者注释，然后再引入如下插件即可：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \n执行 mvn package 命令后，将会打出如下结构的 3 个 jar 包，大家可以自行解压这三个 jar 包，看一看里面的具体内容，下面我们简单分析一下：\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT.jar ：它是 maven 插件打出来的原生 jar 包，只包含我们写的代码和 manifest 文件，无特殊意义。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-biz.jar ：这个 jar 包称之为 Ark Biz 包，因为 SOFAArk 容器是支持运行多个 Ark Biz 的，所以打成这种包是为了和别的项目一起合并部署使用，另外 Ark 包里也包含了这个。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-executable.jar ：这个 jar 包称之为 Ark 包，从字面上来看它是一个可执行的 jar 包，即意味着它是一个可以用 java -jar 命令来单独运行的 Fat Jar，类似于我们用 Spring Boot 插件打出来的包。\n后面的分析主要是围绕 Ark 包来做讲解，因为它包含了 Ark Biz 包，所以只要搞明白它是如何生成的，那么对整个插件的原理也就基本了解了。\n与 Spring Boot 插件对比 要想分析出 sofa-ark-maven-plugin 插件的作用，我们需要先和 Spring Boot 的插件进行对比，从打包产物上直观的感受一下两者的区别。\nspring-boot-maven-plugin 插件 spring-boot-maven-plugin 是 SpringBoot 默认提供的打包插件，其功能就是将工程打包成一个可执行的 FATJAR。spring-boot-maven-plugin 打包产物的目录结构如下：\n. ├── BOOT-INF │ ├── classes # 应用的字节码目录 │ └── lib # 应用所依赖的 jar 包 ├── META-INF │ ├── MANIFEST.MF # manifest 文件信息 │ └── maven # 应用的坐标信息 └── org └── springframework └── boot └── loader # 存放的是 Spring Boot Loader 的 class 文件 ├── JarLauncher.class # Spring Boot 启动类 ├── archive ├── data ├── jar └── util MANIFEST.MF 文件内容：\nManifest-Version: 1.0 Archiver-Version: Plexus Archiver Built-By: rrz Start-Class: pers.masteryourself.tutorial.sofa.ark.maven.plugin.MavenP luginApplication Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Spring-Boot-Version: 2.1.4.RELEASE Created-By: Apache Maven 3.5.3 Build-Jdk: 1.8.0_101 Main-Class: org.springframework.boot.loader.JarLauncher MANIFEST.MF 文件中可以看到，描述了当前 jar 的一些核心元素，包括启动类、class 文件路径、lib 依赖路径、jdk 版本等等，这里需要关注的是 Main-Class，SpringBoot 就是通过该类来引导启动的。SOFAArk 应用也提供了类似的引导类及其自身特殊的结构， …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-build-package-plugin/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5ebfd73573e2f2d529f0303da2fe026c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":null,"title":"打包插件","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","wordcount":2994},{"author":null,"categories":null,"content":" 1. 集成部署模式 1.1 扩容 registry-integration 假设目前已经部署了 3 台 registry-integration，分别是 node1/node2/node3，扩容的新节点是 node4。\n操作步骤：\n第一步. 部署新的 registry-integration 节点\n首先参考部署文档，将 registry-integration.tgz 在新节点 node4 上部署起来，值得注意的是，node4 需要将 nodes.metaNode 配置项指定为4台机器的地址列表：\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt; 在这一步中，node4启动完成后，访问 curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check 状态显示是不健康，因为 node4 尚未加入集群，要加入集群，需要做第二步。\n第二步. 调用 changePeer 使新节点加入集群\n对已经存在的 node1/node2/node3 的任意一台，执行“修改节点列表”的运维命令，将原有由 node1/node2/node3 构成的集群，改为 node1/node2/node3/node4 集群：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check 状态显示应当是健康。\n1.2 缩容 registry-integration 假设集群目前有3台机器 node1/node2/node3，需要缩容 node3。\n1.2.1 平滑缩容 操作步骤：\n第一步. 调用 changePeer 移除节点\n对 node1/node2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“node1/node2/node3”改为“node1/node2”，即把node3移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;node3\u0026amp;gt;:9615/health/check 状态显示应当是不健康的，因为 node3 已经被踢出了集群。\n**第二步.关闭 node3 **\n这一步可选，因为 node3 已经被移除集群了，所以即便 node3 还在运行，也对原集群不影响。\n1.2.2 宕机处理 假设 node3 已经宕机，也需要将 node3 移除出集群\n操作步骤：\n第一步. 调用 changePeer 移除节点\n对 node1/node2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“node1/node2/node3”改为“node1/node2”，即把 node3 移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 2. 独立部署模式 2.1 扩容 registry-meta 假设目前已经部署了3台 registry-meta ，分别是 metaNode1/metaNode2/metaNode3，扩容的新节点是 metaNode4.\n操作步骤：\n第一步. 部署新的 registry-meta 节点\n首先参考部署文档，将 registry-meta.tgz 在新节点 metaNode4 上部署起来，值得注意的是，metaNode4 需要将 nodes.metaNode 配置项指定为4台机器的地址列表：\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;,\u0026amp;lt;metaNode3\u0026amp;gt;,\u0026amp;lt;metaNode4\u0026amp;gt; 在这一步中，metaNode4 启动完成后，访问 curl http://localhost:9615/health/check 状态显示是不健康，因为 metaNode4 尚未加入集群，要加入集群，需要做第二步。\n第二步. 调用 changePeer 使新节点加入集群\n对已经存在的 metaNode1/metaNode2/metaNode3 的任意一台，执行“修改节点列表”的运维命令，将原有由 metaNode1/metaNode2/metaNode3 构成的集群，改为 metaNode1/metaNode2/metaNode3/metaNode4 集群：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;metaNode1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;,\u0026amp;lt;metaNode3\u0026amp;gt;,\u0026amp;lt;metaNode4\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://localhost:9615/health/check 状态显示应当是健康。\n2.2 缩容 registry-meta 假设集群目前有3台机器 metaNode1/metaNode2/metaNode3，需要缩容 metaNode3。\n2.2.1 平滑缩容 操作步骤：\n第一步. 调用 changePeer 移除节点\n对 metaNode1/metaNode2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“metaNode1/metaNode2/metaNode3”改为“metaNode1/metaNode2”，即把 metaNode3 移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;metaNode1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;metaNode3\u0026amp;gt;:9615/health/check 状态显示应当是不健康的，因为metaNode3已经被踢出了集群。\n第二步. 关闭 metaNode3\n这一步可选，因为 metaNode3 已经被移除集群了，所以即便 metaNode3 还在运行，也对 …","date":-62135596800,"description":"","dir":"projects/sofa-registry/scale/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"57de6dc4da1292063ff25ecea9ffbd08","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/scale/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/scale/","summary":"1. 集成部署模式 1.1 扩容 registry-integration 假设目前已经部署了 3 台 registry-integration，分别是 node1/node2/node3，扩容的新节点","tags":null,"title":"扩容与缩容","type":"projects","url":"/sofastack.tech/projects/sofa-registry/scale/","wordcount":1695},{"author":null,"categories":null,"content":" 自定义引擎各个阶段 可以在测试脚本中或者基类中重写 ActsTestBase 提供的 API。\n 重写 prepare，execute，check，clear 等。可以通过在 super.prepare() 之前或者之后进行某些操作。 重写 process 方法，在 super.process() 之前或之后进行操作。可将整个脚本重新编排，例如在现有的清理 -\u0026amp;gt; 准备 -\u0026amp;gt; 执行 -\u0026amp;gt; 校验流程中增加一些个性化的步骤。 重写 beforeActsTest、afterActsTest，可以在每一个用例运行前后做一些个性化的操作，如准备上下文、缓存刷新等。 参数化 在结果期望和数据库期望中可以使用 $变量名 来标识某个值是变量，测试脚本中可以把值设置进去； 支持范围：入参、返回结果、数据库表字段，支持类型：目前仅支持 String 的参数化。\n使用方法：\n（1）界面以 $ 开头定义变量\n（2）代码中给变量赋值\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { actsRuntimeContext.paramMap.put(\u0026amp;quot;roleId\u0026amp;quot;, \u0026amp;quot;123\u0026amp;quot;); actsRuntimeContext.refreshDataParam(); } 在写 DB 数据期望的时候，也可以通过 = 符号来进行赋值，表示这个值来自于查询结果，后面的表就可以使用这个变量作为值。\n假设接口会向 2 张表插入数据。\n id_A value_A 123 abc id_B value_B abc efg 查询的时候要先通过接口返回的 A 表的 id_A 查到 value_A, 然后把 value_A 作为 B 表的查询条件，在插件上面可以这样写：\n 字段 flag 值 id_A C $param1 value_A Y =param2 字段 flag 值 id_B C $param2 value_B Y efg 上面操作说明：\n =param2 和 $param2 的操作，表示框架会先从 A 表查出 value_A 然后 select from B where id_B = value_A，进而得到全部 B 表的属性值； $param1 表示可以在代码中对 id_A 赋值，代码形如： actsRuntimeContext.paramMap.put(\u0026amp;quot;param1\u0026amp;quot;,\u0026amp;quot;123\u0026amp;quot;); 表示对变量 param1 赋值 123，上述代码可以写到脚本的 beforeActsTest 里面，这样在查询 A 表之前，框架就会将 123 赋值给 id_A。\n参数组件化 目前仅支持 String 的组件化\n如果属性是需要动态生成的字符串，例如某些 ID，可以通过 @ 符号来调用一个组件生成这个属性，组件要放在跟 test 同级的 component 包下，即：com.corpname.appname.acts.component (这里appname是系统名，corpname是公司名，如alipay)。\npublic class MyComponent { @TestComponent(id = \u0026amp;quot;test\u0026amp;quot;) public String test(String param) { return param+\u0026amp;quot;123\u0026amp;quot;; } } 并通过 acts-config.properties 配置指明参数化组件使其生效，多个组件使用英文逗号 , 分隔，末尾注意不必要的空格。\nparam_components=IdGenerateComponent,NoGenerateComponent 如上图 alis_value 值为 @test?param=123 则在用例运行时会自动替换 alis_value 的取值。\n组件的 ID 要保证唯一，否则默认调用第一个，如果声明了一个无参组件方法，调用方式为 @test 即可，同时支持组件化参数通过变量传入：@test?param=$id，实际执行时会替换 $id 的值为实际值。\n脚本中也可以通过代码调用：\nActsComponentUtil.run(\u0026amp;quot;@test?param=123\u0026amp;quot;); 自定义组件多个参数的场景使用 \u0026amp;amp; 分割参数，如 @test?param1=xxx\u0026amp;amp;param2=yyy\nDB 工具类 1. 指定数据源进行 DB 表访问 框架 ActsDBUtils 中提供了 DB 的指定数据源访问，用于个性化 DB 操作。例如某张表的某条纪录不是准备数据也不是校验数据，但是需要在运行后删掉或更新，此时就需要用到该工具操作 DB 数据。\n使用前配置\n使用指定数据源方式需要在 acts-config.properties 文件中首先将要指定的数据源进行配置，配置例子如下：\ndatasource_bean_name_exampleDataSource=com.alipay.example.dal;exampleDataSource #整体配置的格式为：datasource_bean_name_xxx(数据源名字)=yyy(数据源所在 Module);xxx(数据源名字) 指定数据源方法\nActsDBUtils 工具类中指定数据源方法说明：\npublic static int getUpdateResultMap(String sql,String tableName,String dbConfigKey); 该方法用于指定数据源进行表的增、删和改的操作。sql 为标准 sql 语句，tableName 为逻辑表名，dbConfigKey 为该 表所在的逻辑数据源配置，与 acts-config.properties 配置的 xxx（数据源名字）相同。\npublic static List\u0026amp;lt;Map\u0026amp;lt;String, Object\u0026amp;gt;\u0026amp;gt; getQueryResultMap(String sql, String tableName,String dbConfigKey); 该方法用于指定数据源进行表的查询操作，以上两个方法都是原子化的 DB 表的操作，如果有其他的 DB 需求可以在上面进行 封装。\n2. 不指定数据源进行 DB 表访问 该方式下 ACTS 框架默认根据表名搜索数据源，工具方法的使用步骤如下：\n使用前配置\ndatasource_bundle_name=com.alipay.example.common.dal ds_exampleDataSource=table1,tabal2 #整体配置的格式为 #datasource_bundle_name=数据源所在模块名 #ds_数据源名字=该数据源下的逻辑表名 不指定数据源方法\npublic static int getUpdateResultMap(String …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-api/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ce7e264713a6f7a3f0672e2432489f59","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-api/","summary":"自定义引擎各个阶段 可以在测试脚本中或者基类中重写 ActsTestBase 提供的 API。 重写 prepare，execute，check，clear 等。可以通过在 super.prepare() 之","tags":null,"title":"扩展功能","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-api/","wordcount":1955},{"author":null,"categories":null,"content":" ExtensionLoader 为了对 SOFARPC 各个环节的都有充足的可扩展性，SOFA-RPC定义了一套十分灵活的扩展机制，所有扩展实现都是平等的。\n这套机制不管是对SOFA-RPC本身的开发者其使用者而言都是非常有用的。SOFA-RPC将其自身抽象为了多个模块，各个模块之间无显示依赖，通过SPI的方式进行交互。\n这套扩展机制抽象了这一SPI的交互方式。如果你读了上面文档讲到的 Filter 和 Router，应该已经有所体会。\n这里讲一下如何使方式进行扩展的。\nSOFARPC 提供了 ExtensionLoader 的能力。\n扩展点设计 SOFARPC 定义了一个注解 @Extensible，该注解标识在接口或者抽象类上，标识该类是一个扩展点。即告诉 SOFARPC 该类是可扩展的，需要寻找该扩展点的实现，同时也定义了寻找实现类的文件名称，是否单例。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * 指定自定义扩展文件名称，默认就是全类名 * * @return 自定义扩展文件名称 */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * 扩展类是否使用单例，默认使用 * * @return 是否使用单例 */ boolean singleton() default true; /** * 扩展类是否需要编码，默认不需要 * * @return 是否需要编码 */ boolean coded() default false; } SOFARPC 同时定义了 @Extension 注解，标识该类是一个扩展实现类。也定义了扩展点在文件中寻找扩展实现时使用的名字。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * 扩展点名字 * * @return 扩展点名字 */ String value(); /** * 扩展点编码，默认不需要，当接口需要编码的时候需要 * * @return 扩展点编码 * @see Extensible#coded() */ byte code() default -1; /** * 优先级排序，默认不需要，大的优先级高 * * @return 排序 */ int order() default 0; /** * 是否覆盖其它低{@link #order()}的同名扩展 * * @return 是否覆盖其它低排序的同名扩展 * @since 5.2.0 */ boolean override() default false; /** * 排斥其它扩展，可以排斥掉其它低{@link #order()}的扩展 * * @return 排斥其它扩展 * @since 5.2.0 */ String[] rejection() default {}; } 新增扩展点 1.定义扩展点。\n@Extensible public interface Person { void getName(); } 2.定义扩展实现\n@Extension(\u0026amp;quot;A\u0026amp;quot;) public class PersonA implements Person{ @Override public void getName() { System.out.println(\u0026amp;quot;li wei\u0026amp;quot;); } } 3.编写扩展描述文件：META-INF/services/sofa-rpc/com.alipay.sofa.rpc.extension.Person。文件内容如下：\nA=com.alipay.sofa.rpc.extension.PersonA 4.加载扩展点，获取到扩展实现类使用。\nPerson person = ExtensionLoaderFactory.getExtensionLoader(Person.class).getExtension(\u0026amp;quot;A\u0026amp;quot;); 已有扩展点 如果想对 SOFARPC 的各个内置扩展点进行功能扩展，可直接实现已有扩展，配置扩展模式文件即可。\n目前已有的扩展点如下：\n 接口名 中文名 备注 内置实现 com.alipay.sofa.rpc.client.Client 客户端 Failover、Failfast com.alipay.sofa.rpc.client.ConnectionHolder 连接管理器 AllConnect（全部连接） com.alipay.sofa.rpc.client.AddressHolder 地址管理器 单组、多组 com.alipay.sofa.rpc.client.LoadBalancer 负载均衡 随机、轮询、最少并发、一致性hash、本机优先 com.alipay.sofa.rpc.client.Router 路由器 com.alipay.sofa.rpc.codec.Compressor 压缩 snappy、quicklz com.alipay.sofa.rpc.codec.Serializer 序列化器 java、hessian、pb com.alipay.sofa.rpc.filter.Filter 拦截器 com.alipay.sofa.rpc.protocol.Protocol 协议 bolt、dubbo、rest com.alipay.sofa.rpc.protocol.ProtocolDecoder 协议解码 bolt com.alipay.sofa.rpc.protocol.ProtocolEncoder 协议编码 bolt com.alipay.sofa.rpc.protocol.TelnetHandler telnet的响应 version、help、ls com.alipay.sofa.rpc.proxy.Proxy 代理类 java、javassist com.alipay.sofa.rpc.registry.Registry 注册中心 zookeeper com.alipay.sofa.rpc.server.Server 服务端实现 bolt、rest com.alipay.sofa.rpc.transport.ClientTransport 客户端长连接实现 netty com.alipay.sofa.rpc.transport.ServerTransport 服务端长连接实现 netty ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/extension-loader/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"acc5628da3a7ea2df5eb68bd8ec17159","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/extension-loader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/extension-loader/","summary":"ExtensionLoader 为了对 SOFARPC 各个环节的都有充足的可扩展性，SOFA-RPC定义了一套十分灵活的扩展机制，所有扩展实现都是平等的。 这套机制不管是对SOFA-RP","tags":null,"title":"扩展点设计","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/extension-loader/","wordcount":1131},{"author":null,"categories":null,"content":" SOFARPC 的服务发布和引用的基本配置已经在「编程界面」章节中说明，这里主要介绍服务发布和引用的一些特性。\n同一服务发布多种协议 在 SOFARPC 中，可以将同一个服务发布成多个协议，让调用端可以使用不同的协议调用服务提供方。\n如果使用 Java API，可以按照如下的代码构建多个 ServerConfig，不同的 ServerConfig 设置不同的协议，然后将这些 ServerConfig 设置给 ProviderConfig：\nServerConfig serverConfigA = new ServerConfig(); ServerConfig serverConfigB = new ServerConfig(); List\u0026amp;lt;ServerConfig\u0026amp;gt; serverConfigs = new ArrayList\u0026amp;lt;ServerConfig\u0026amp;gt;(); serverConfigs.add(serverConfigA); serverConfigs.add(serverConfigB); providerConfig.setServer(serverConfigs); 如果使用 XML 的方式，直接在 \u0026amp;lt;sofa:service\u0026amp;gt; 标签中增加多个 binding 即可：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 如果使用 Annotation 的方式，在 @SofaService 中增加多个 binding 即可：\n@SofaService( interfaceType = SampleService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;), @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) } ) public class SampleServiceImpl implements SampleService { // ... } 同一服务注册多个注册中心 如果使用 API 的方式，构建多个 RegistryConfig 设置给 ProviderConfig 即可：\nRegistryConfig registryA = new RegistryConfig(); RegistryConfig registryB = new RegistryConfig(); List\u0026amp;lt;RegistryConfig\u0026amp;gt; registryConfigs = new ArrayList\u0026amp;lt;RegistryConfig\u0026amp;gt;(); registryConfigs.add(registryA); registryConfigs.add(registryB); providerConfig.setRegistry(registryConfigs); 如果是使用 XML 的方式\n需要在properties里配置注册中心\ncom.alipay.sofa.rpc.registries.zookeeper=zookeeper://127.0.0.1:2181 com.alipay.sofa.rpc.registries.nacos=nacos://127.0.0.1:8848 \u0026amp;lt;bean id=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacadeImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;nacos,zookeeper\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 如果使用 Annotation 的方式\n需要在properties里配置注册中心\ncom.alipay.sofa.rpc.registries.zookeeper=zookeeper://127.0.0.1:2181 com.alipay.sofa.rpc.registries.nacos=nacos://127.0.0.1:8848 @SofaService(bindings = {@SofaServiceBinding(registry = \u0026amp;quot;nacos\u0026amp;quot;), @SofaServiceBinding(registry = \u0026amp;quot;zookeeper\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { // ... } 方法级参数设置 在 Java API 方式中，调用 MethodConfig 对象相应的 set 方法即可设置对应的参数，如下所示：\nMethodConfig methodConfigA = new MethodConfig(); MethodConfig methodConfigB = new MethodConfig(); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfigA); methodConfigs.add(methodConfigB); providerConfig.setMethods(methodConfigs); //服务端设置 consumerConfig.setMethods(methodConfigs); //客户端设置 使用 XML 的方式，在对应的 binding 里面使用 \u0026amp;lt;sofa:method\u0026amp;gt; 标签即可设置对应的参数：\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/publish-and-reference/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6a78b8b84b226eaf1e6d2b1ff1d15fee","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/publish-and-reference/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/publish-and-reference/","summary":"SOFARPC 的服务发布和引用的基本配置已经在「编程界面」章节中说明，这里主要介绍服务发布和引用的一些特性。 同一服务发布多种协议 在 SOFARPC 中，可以将同一个服务","tags":null,"title":"服务发布与引用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/publish-and-reference/","wordcount":699},{"author":null,"categories":null,"content":" 自动化 推荐版本: ES 5\n自动初始化库 Lookout 服务器端启动时，会自动检查（默认开启，可关闭）所连接的ES机器(或集群)，检查 Metrics 数据存储的 Index和 Mapping 是否已经建立， 如果未初始化则进行初始化工作。默认初始化并产生索引alias: \u0026amp;ldquo;lookout-active-metrics，lookout-search-metrics\u0026amp;rdquo;。\n 看下 Alias 和 Indices\nhttp://localhost:9200/_cat/aliases lookout-active-metrics metrics-2019.05.30-1 - - - lookout-search-metrics metrics-2019.05.30-1 - - - 看下存储 Mapping：\nhttp://localhost:9200/lookout-active-metrics/_mapping { \u0026amp;quot;metrics-2019.05.30-1\u0026amp;quot;: { \u0026amp;quot;mappings\u0026amp;quot;: { \u0026amp;quot;metrics\u0026amp;quot;: { \u0026amp;quot;properties\u0026amp;quot;: { \u0026amp;quot;id\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;keyword\u0026amp;quot; }, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;keyword\u0026amp;quot; }, \u0026amp;quot;time\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;date\u0026amp;quot; }, \u0026amp;quot;value\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;float\u0026amp;quot; } } } } } } 自动运维 自动 Indices Rollover\n 如果超过1天，则切换新索引 如果单个索引的 docs 数目超过: 100000000，则切换新索引； 自动删除过期 Indices\n 默认最多只保留 7 天的数据，过期的 Index 会自动检查并被删除；\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-es/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"016a397aa24e885b5aaa32cf1cac3f35","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-es/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-es/","summary":"自动化 推荐版本: ES 5 自动初始化库 Lookout 服务器端启动时，会自动检查（默认开启，可关闭）所连接的ES机器(或集群)，检查 Metrics 数据存储的 Index和 Mapping 是","tags":null,"title":"服务器端 ES 存储使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-es/","wordcount":315},{"author":null,"categories":null,"content":"由于 SOFALookout Metrics Server 兼容 Prometheus API,所以 Grafana 集成 Lookout 很简单，只需要选择 Prometheus 作为数据源协议即可 （注意 Lookout Server 的默认查询端口也是: 9090）。\n下图展示 Grafana 新增数据源配置:\n使用 PromQL 查询展示数据:\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-grafana/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"45b8a5084ac2a151af28ff11413b13cb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","summary":"由于 SOFALookout Metrics Server 兼容 Prometheus API,所以 Grafana 集成 Lookout 很简单，只需要选择 Prometheus 作为数据源协议即可 （注意 Lookout Server 的默认查询端口也是: 9090）。 下图展示 Grafana 新增数据源配置","tags":null,"title":"服务器端 Grafana 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","wordcount":81},{"author":null,"categories":null,"content":" 如果需要扩展支持适配一个新的数据存储，可能需要下面的步骤:\n1.写入适配 需要在 gateway/metrics/exporter/ 下面添加新的 exporter; 参考已有的 \u0026amp;ldquo;gateway/metrics/exporter/elasticsearch\u0026amp;rdquo; 模块；\n 提供个新存储的 MetricExporter 功能是写入数据到存储中，参考\u0026amp;rdquo;com.alipay.sofa.lookout.gateway.metrics.exporter.es.ESMetricExporter\u0026amp;rdquo;，提供个新存储的 MetricExporter；\n 提供个该模块的spring配置类 参考 \u0026amp;ldquo;com.alipay.sofa.lookout.gateway.metrics.exporter.es.spring.bean.config.EsExporterConfiguration\u0026amp;rdquo;，它包括 ESProperties 的配置描述映射。尤其重要的是带有注解 @ConditionalOnExporterComponent方便该功能开关；\n 在 \u0026amp;ldquo;com.alipay.sofa.lookout.gateway.metrics.starter.MetricPipelineConfiguration\u0026amp;rdquo; 中 @import 上述存储spring配置类； 2.查询数据适配 需要在 server/metrics 目录下，添加新 storage 扩展； 参考 “server/metrics/storage-ext-es” 模块，比如新增“storage-ext-**”\n 提供个新的存储 Storage 实现； 参考已有 “com.alipay.sofa.lookout.server.storage.ext.es.ElasticSearchStorage”，实现Storage接口。这里也需要ES实现对应的 “QueryStmt”，”LabelValuesStmt“，”LabelNamesStmt“.\n 提供个该模块的spring配置类 参考\u0026amp;rdquo;com.alipay.sofa.lookout.server.storage.ext.es.spring.bean.config.ElasticSearchServerConfig\u0026amp;rdquo;,提供 Storage的实例。 另外参考支持”@ConditionalOnProperty“的功能开关配置；\n 在 \u0026amp;ldquo;com.alipay.sofa.lookout.server.starter.ServerAutoConfiguration\u0026amp;rdquo; 中 @import 上述存储spring配置类； 3.最后贡献建议 提issue说明需求，并可以介绍下方案； 保证测试覆盖； fork 代码，编译通过后，提交 PR； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-storage-ext/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b990dad82668bc22c24d4ad0468f0535","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","summary":"如果需要扩展支持适配一个新的数据存储，可能需要下面的步骤: 1.写入适配 需要在 gateway/metrics/exporter/ 下面添加新的 exporter; 参考已有的 \u0026ldquo;gateway/metrics/exporter/elasticsearch\u0026rdquo; 模块； 提供个新存储的 MetricExporter 功能是写入数据","tags":null,"title":"服务器端 Metrics 存储扩展机制","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","wordcount":864},{"author":null,"categories":null,"content":" 1. Tag选择器的“in”筛选 =~| 将tag符合表达式的提供的值选择出来，类似于SQL中的in语义\n示例\n将app为 foo 或 foo2的应用时序数据查询出来\njvm.memory.heap.used{app=~|\u0026amp;quot;foo|foo2\u0026amp;quot;,instance_id=\u0026amp;quot;xxx\u0026amp;quot;} 2. Tag选择器的\u0026amp;rdquo;not in\u0026amp;rdquo;筛选 !~| 将tag不符合表达式提供的值选择出来,类似SQL中的not in语义\n示例\njvm.memory.heap.used{app!~|\u0026amp;quot;foo|foo2\u0026amp;quot;,instance_id=\u0026amp;quot;xxx\u0026amp;quot;} 3. Increase2函数 （类似Increase），适用于Promethues的Counter型指标 increase 会根据根据查询步长，做个时间点上的函数估值（根据既有增长斜率）。所以可能是非整型。 如果你就想返回真实时间点的整数差值，不愿估算目标时刻的近视值。那么推荐使用 Increase2。\n需要组合聚合函数时，记住“Rate then sum, never sum then rate”（这里说的rate 与 increase 函数类似）\nsum by (job)(Increase2(http_requests_total{job=\u0026amp;quot;node\u0026amp;quot;}[5m])) # This is okay 4. \u0026amp;ldquo;histogram_quantile\u0026amp;rdquo; 与(Lookout)自定义 \u0026amp;ldquo;zhistogram_quantile\u0026amp;rdquo; histogram_quantile ，是对使用prometheus client得到的 metrics buckets进行分析；\nzhistogram_quantile，是对使用 lookout sdk的得到的 metrics buckets 进行分析;\n5. Promethues 一些最佳实践总结 rate，increase 函数用于计算指标的速率，在使用时要根据指标数据的采集或上报时间间隔来进行over_time时间的控制。比如metrics数据是1分钟上报一次,如果想获取某个metric指标的1分钟的速率，应该按如下方式写promql语句\nrate(http_requestl{token=\u0026amp;quot;mobile\u0026amp;quot;}[2m] step 表示最终显示的采样（步长），如果和range （比如2m）保持一致，表示原样输出，不采样。 如果想进行采样，step \u0026amp;gt; range 就行了！ 所以总的来说，step \u0026amp;gt;= range.\nrange, 从实际使角度，推荐 range 值要尽量明显大于数据实际的上报时间间隔才有意义，比如上报单位是30秒，那range尽量\u0026amp;gt;= 1分钟。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-promql-feature-enhancement/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3bd5cd1f9d3ce3f9ba5b503ef0ba9da1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","summary":"1. Tag选择器的“in”筛选 =~| 将tag符合表达式的提供的值选择出来，类似于SQL中的in语义 示例 将app为 foo 或 foo2的应用时序数据查询出来","tags":null,"title":"服务器端 PromQL 语法特性增强","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","wordcount":691},{"author":null,"categories":null,"content":" 使用 Lookout sdk是推荐方式，当然 Lookout gateway 还支持其他协议上报。（但由于属于非标接入，细节可联系我们）\n注意如果使用 非lookout sdk ，自己一定注意控制客户端metrics数量！ [Don\u0026amp;rsquo;t over use labels(tags)]\n1.Promethues Push协议写入支持 Lookout-gateway这里扮演的是一个 prometheus-pushgateway 角色：\necho \u0026amp;quot;some_metric{k1=\u0026amp;quot;v1\u0026amp;quot;} 3.14\u0026amp;quot; | curl --data-binary \\ @- http://localhost:7200/prom/metrics/job/{job}/app/{app}/step/{step} 区别在于：\u0026amp;rdquo;http://localhost:7200/prom/\u0026amp;ldquo;，端口为7200，加了级主路径为/prom.\n 【必选】URL路径变量 {app} {job} 和{step}，必须要指定哦。step 单位秒，表示您定时上报的时间间隔（假如10s 上报一次数据，那么 step=10）\n 【可选】如果和lookout gateway间有网络代理，建议URL 里也附带上客户端真实 ip （如 \u0026amp;ldquo;/ip/{ip}\u0026amp;ldquo;）。\n 上报格式样式: 【 http_requests_total{method=\u0026amp;ldquo;post\u0026amp;rdquo;,code=\u0026amp;ldquo;200\u0026amp;rdquo;} 1027 】，多个以换行符【\u0026amp;rsquo;\\n\u0026amp;rsquo;】分割；\n 更多细节可以参考：prometheus-pushgateway ，你可以选择官方对应编程语言的SDKs\n 2. Lookout 自有协议写入支持 默认的收集服务和数据协议标准(即Lookout自有的协议支持标准)\n localhost:7200/lookout/metrics/app/{app}/step/{step}\ncurl -H \u0026amp;quot;Content-type:text/plain\u0026amp;quot; -X POST -d \u0026#39;xx\u0026#39; \\ localhost:7200/lookout/metrics/app/{app}/step/{step} 请求体是一种批量复合形式。内容是多条 metrics 数据以 \u0026amp;ldquo;\\t\u0026amp;rdquo; 进行连接；\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;count\u0026amp;quot;:0,\u0026amp;quot;rate\u0026amp;quot;:0.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;value\u0026amp;quot;:99.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;elapPerExec\u0026amp;quot;:0.0,\u0026amp;quot;totalTime\u0026amp;quot;:0.0,\u0026amp;quot;max\u0026amp;quot;:0.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;totalAmount\u0026amp;quot;:0.0,\u0026amp;quot;rate\u0026amp;quot;:0.0,\u0026amp;quot;max\u0026amp;quot;:0}} 上面内容中组成部分分别是：counter型,gauge型,Timer型\n 其中单条数据结构\n{ \u0026amp;quot;time\u0026amp;quot;: \u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;k1\u0026amp;quot;: \u0026amp;quot;v1\u0026amp;quot; }, \u0026amp;quot;m_name\u0026amp;quot;: { \u0026amp;quot;count\u0026amp;quot;: 0, \u0026amp;quot;rate\u0026amp;quot;: 0 } } tag 的 value 需要转义;\n 如果内容由进行了 snappy 压缩，需添加请求头 \u0026amp;ldquo;Content-Encoding:snappy\u0026amp;rdquo;,且\u0026amp;rdquo;Content-type: application/octet-stream\u0026amp;rdquo;;\n 3.OPEN TSDB 协议写入支持 请求demo\ncurl -X POST \\ http://localhost:7200/opentsdb/api/put \\ -H \u0026#39;Content-Type: application/json\u0026#39; \\ -H \u0026#39;step: 10000\u0026#39; \\ -H \u0026#39;app: xx\u0026#39; \\ -H \u0026#39;X-Lookout-Token: xx\u0026#39; \\ -d \u0026#39;[{ \u0026amp;quot;metric\u0026amp;quot;: \u0026amp;quot;xzc.cpu\u0026amp;quot;, \u0026amp;quot;timestamp\u0026amp;quot;: 1530624430, \u0026amp;quot;value\u0026amp;quot;: 30, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;host\u0026amp;quot;: \u0026amp;quot;web02\u0026amp;quot;, \u0026amp;quot;dc\u0026amp;quot;: \u0026amp;quot;lga\u0026amp;quot; } }]\u0026#39; 注意timestamp的单位是秒(而且尽量是当前时间附近哦，否则不太好查询)\n post的内容可以是一个json对象或json数组(批量模式)\n 更多细节可以参考 OpenTSDB的 /api/put 接口 http://opentsdb.net/docs/build/html/api_http/put.html\n 4.Metricbeat 写入协议支持 （1）.metricbeat的配置 配置文件 metricbeat.yml\noutput.elasticsearch: hosts: [\u0026#39;10.15.232.67:7200\u0026#39;] path: /beat host 是 lookout-gateway 的地址,端口是7200. 另外加了级主路径/beat;\n(2).为了符合metrics2.0标准，gateway会对数据进行转换 这块后续去时序库查询，你需要关注：\n FROM:\n{ \u0026amp;quot;@timestamp\u0026amp;quot;: \u0026amp;quot;2018-03-29T08:27:21.200Z\u0026amp;quot;, …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-other-metrics-protocol-support/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"df745d82f3f681cfd94b8187934a8477","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","summary":"使用 Lookout sdk是推荐方式，当然 Lookout gateway 还支持其他协议上报。（但由于属于非标接入，细节可联系我们） 注意如果使用 非lookout sdk ，自己一定注意控制客","tags":null,"title":"服务器端常见数据采集协议支持","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","wordcount":1013},{"author":null,"categories":null,"content":" SOFADashboard 服务治理主要是对 SOFARpc 的服务进行管理。 目前已经支持基于 ZK 和 SofaRegistry 两个注册中心。\n功能展示 1、基于服务维度 服务列表 服务提供者详情： 2、基于应用维度 应用列表 应用服务详情 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/governance/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e547baf489fd5d125be9e67a366854b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/governance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/governance/","summary":"SOFADashboard 服务治理主要是对 SOFARpc 的服务进行管理。 目前已经支持基于 ZK 和 SofaRegistry 两个注册中心。 功能展示 1、基于服务维度 服务列表 服务提供者详情： 2、基于应用维度 应用","tags":null,"title":"服务治理","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/governance/","wordcount":78},{"author":null,"categories":null,"content":" 本地开发 在本地启动 SOFARegistry 是使用的H2 database 作为注册中心使用的配置数据库, 可以直接启动\ncom.alipay.sofa.registry.server.integration.RegistryApplication#main\n默认会使用 application-dev.properties 作为配置文件\n部署模式 SOFARegistry 部署依赖 mysql, 使用 mysql 作为注册中心自身的元数据存储。\n支持两种部署模式，分别是集成部署模式及独立部署模式，本文将介绍最简单的单节点集成部署模式，更多更详细的部署模式介绍可以查看 部署文档。\n部署步骤 1.下载源码或者安装包 下载源码方式 git clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Pserver-release -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all 下载安装包方式 您可以从 release 页面 下载最新的 registry-all.tgz 包 。\n建议下载 v6 以上版本\ntar -zxvf registry-all.tgz cd registry-all 2.启动 registry-integration 2.1 如果是本地启动开发注册中心, 可以使用 h2 作为数据库\nIDEA 源码启动: 运行 com.alipay.sofa.registry.server.integration.RegistryApplication#main\nfat jar 脚本启动命令: sh bin/integration/start_dev.sh\n2.2 正式环境建议使用 mysql\n创建 database 和 table\necho \u0026amp;quot;create database registrymetadb \u0026amp;quot; | mysql -u username -p mysql -u username -p registrymetadb \u0026amp;lt; create_table.sql 修改 conf/application.properties 中的配置，数据库密码也可以通过 JDBC_PASSWORD 环境变量传入\n启动命令: sh bin/integration/start.sh\n3.确认运行状态 可访问三个角色提供的健康监测 API，或查看日志 logs/registry-startup.log：\n# 查看meta角色的健康检测接口： $ curl http://localhost:9615/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} # 查看data角色的健康检测接口： $ curl http://localhost:9622/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... status:WORKING\u0026amp;quot;} # 查看session角色的健康检测接口： $ curl http://localhost:9603/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-registry/server-quick-start/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b620900b56ba04f4668838846a97698a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/server-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/server-quick-start/","summary":"本地开发 在本地启动 SOFARegistry 是使用的H2 database 作为注册中心使用的配置数据库, 可以直接启动 com.alipay.sofa.registry.server.integration.RegistryApplication#main 默认会使用 application-dev.properties 作为配置文件 部署模式 SOFARegistry 部署依赖 mysql, 使用 mysql 作为注册中心","tags":null,"title":"服务端部署","type":"projects","url":"/sofastack.tech/projects/sofa-registry/server-quick-start/","wordcount":460},{"author":null,"categories":null,"content":" 如图: Node Raft 分组中的一个节点，连接封装底层的所有服务，用户看到的主要服务接口，特别是 apply(task) 用于向 raft group 组成的复制状态机集群提交新任务应用到业务状态机。\n存储 Log 存储，记录 raft 配置变更和用户提交任务的日志，将从 Leader 复制到其他节点上。LogStorage 是存储实现， LogManager 负责对底层存储的调用，对调用做缓存、批量提交、必要的检查和优化。 Meta 存储，元信息存储,记录 raft 实现的内部状态，比如当前 term,、投票给哪个节点等信息。 Snapshot 存储,，用于存放用户的状态机 snapshot 及元信息，可选。 SnapshotStorage 用于 snapshot 存储实现， SnapshotExecutor 用于 snapshot 实际存储、远程安装、复制的管理。 状态机 StateMachine： 用户核心逻辑的实现,核心是 onApply(Iterator) 方法，应用通过 Node#apply(task) 提交的日志到业务状态机。 FSMCaller： 封装对业务 StateMachine 的状态转换的调用以及日志的写入等，一个有限状态机的实现，做必要的检查、请求合并提交和并发处理等。 复制 Replicator： 用于 leader 向 follower 复制日志，也就是 raft 中的 appendEntries 调用，包括心跳存活检查等。 ReplicatorGroup: 用于单个 RAFT Group 管理所有的 replicator，必要的权限检查和派发。 RPC RPC 模块用于节点之间的网络通讯: 1. RPC Server: 内置于 Node 内的 RPC 服务器，接收其他节点或者客户端发过来的请求，转交给对应服务处理。 2. RPC Client: 用于向其他节点发起请求，例如投票、复制日志、心跳等。\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/engine-architecture/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d2cc9de133aed20695229d0cde5b6ff9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/engine-architecture/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-jraft/engine-architecture/","summary":"如图: Node Raft 分组中的一个节点，连接封装底层的所有服务，用户看到的主要服务接口，特别是 apply(task) 用于向 raft group 组成的复制状态机集群提交新任务应用到业务状态机","tags":null,"title":"核心引擎设计","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/engine-architecture/","wordcount":529},{"author":null,"categories":null,"content":" MOSN 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 xDS 等云原生能力。\nxDS（UDPA）支持 MOSN 支持云原生统一数据面 API（UDPA），支持全动态配置更新。\nxDS 是 Envoy 创建的一个关键概念，它是一类发现服务的统称，其包括如下几类：\n CDS：Cluster Discovery Service EDS：Endpoint Discovery Service SDS：Secret Discovery Service RDS：Route Discovery Service LDS：Listener Discovery Service 正是通过对 xDS 的请求来动态更新 Envoy 配置，另外还有个 ADS（Aggregated Discovery Service）通过聚合的方式解决以上 xDS 的更新顺序问题。\n业务支持 MOSN 作为底层的高性能安全网络代理，支撑了 RPC、消息（Messaging）、网关（Gateway）等业务场景。\nIO 模型 MOSN 支持以下两种 IO 模型：\n Golang 经典 netpoll 模型：goroutine-per-connection，适用于在连接数不是瓶颈的情况。\n RawEpoll 模型：也就是 Reactor 模式，I/O 多路复用（I/O multiplexing）+ 非阻塞 I/O（non-blocking I/O）的模式。对于接入层和网关有大量长链接的场景，更加适合于 RawEpoll 模型。\n netpoll 模型 MOSN 的 netpoll 模型如上图所示，协程数量与链接数量成正比，大量链接场景下，协程数量过多，存在以下开销：\n Stack 内存开销 Read buffer 开销 Runtime 调度开销 RawEpoll 模型 RawEpoll 模型如上图所示，使用 epoll 感知到可读事件之后，再从协程池中为其分配协程进行处理，步骤如下：\n 链接建立后，向 Epoll 注册 oneshot 可读事件监听；并且此时不允许有协程调用 conn.read，避免与 runtime netpoll 冲突。 可读事件到达，从 goroutine pool 挑选一个协程进行读事件处理；由于使用的是 oneshot 模式，该 fd 后续可读事件不会再触发。 请求处理过程中，协程调度与经典 netpoll 模式一致。 请求处理完成，将协程归还给协程池；同时将 fd 重现添加到 RawEpoll 中。 协程模型 MOSN 的协程模型如下图所示。\n 一条 TCP 连接对应一个 Read 协程，执行收包、协议解析； 一个请求对应一个 worker 协程，执行业务处理，proxy 和 Write 逻辑； 常规模型一个 TCP 连接将有 Read/Write 两个协程，我们取消了单独的 Write 协程，让 workerpool 工作协程代替，减少了调度延迟和内存占用。\n能力扩展 协议扩展 MOSN 通过使用统一的编解码引擎以及编/解码器核心接口，提供协议的 plugin 机制，包括支持：\n SOFARPC HTTP1.x/HTTP2.0 Dubbo NetworkFilter 扩展 MOSN 通过提供 network filter 注册机制以及统一的 packet read/write filter 接口，实现了 Network filter 扩展机制，当前支持：\n TCP proxy Fault injection StreamFilter 扩展 MOSN 通过提供 stream filter 注册机制以及统一的 stream send/receive filter 接口，实现了 Stream filter 扩展机制，包括支持：\n 流量镜像 RBAC 鉴权 TLS 安全链路 通过测试，原生的 Go 的 TLS 经过了大量的汇编优化，在性能上是 Nginx（OpenSSL）的80%，Boring 版本的 Go（使用 cgo 调用 BoringSSL）因为 cgo 的性能问题， 并不占优势，所以我们最后选择使用原生 Go 的 TLS，相信 Go Runtime 团队后续会有更多的优化，我们也会有一些优化计划。\nGo vs Nginx 测试结果如下图所示：\n Go 在 RSA 上没有太多优化，go-boring（CGO）的能力是 Go 的两倍。 p256 在 Go 上有汇编优化，ECDSA 优于go-boring。 在 AES-GCM 对称加密上，Go 的能力是 go-boring 的 20 倍。 在 SHA、MD 等 HASH 算法也有对应的汇编优化。 为了满足金融场景的安全合规，我们同时也对国产密码进行了开发支持，这个是 Go Runtime 所没有的。虽然目前的性能相比国际标准 AES-GCM 还是有一些差距，大概是 50%，但是我们已经有了后续的一些优化计划，敬请期待。\n支持国密的性能测试结果如下图所示：\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/core-concept/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5fd84bf5ceb2a4ab800cd0e2db774731","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/core-concept/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/concept/core-concept/","summary":"MOSN 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 xDS 等云原生能力。 xDS（UDPA）支持 MOSN 支持云原生统一数据面 API（UDPA），","tags":null,"title":"核心概念","type":"projects","url":"/sofastack.tech/projects/mosn/concept/core-concept/","wordcount":1332},{"author":null,"categories":null,"content":" 框架准备 在阅读前，您可以参考快速开始下载并安装 ACTS IDE 和引入 ACTS 框架.\n本部分主要包含编码说明、数据源配置和一键配置说明，以帮助您使用 ACTS 框架。\n编码说明 请确保 ACTS 的编码与系统代码的编码一致，即确定以下的编码保持一致：生成脚本选择的编码、workspace 的编码应该都与应用代码编码保持一致，不一致时会出现乱码问题。\n生成脚本选择的编码，如下图设置：\nIDEA workspace 的编码：\n数据源配置 ACTS 配置数据源的目的，是为了在数据准备、数据清理、数据校验阶段，能够使用系统的数据源正确的进行 DB 增删改查。\n数据源配置 在 src/test/resource/config/acts-config.properties 中配置 dal 层的 ModuleName、数据源以及表的对应关系，以 ds_ 开头，如下：\ndatasource_bundle_name =com.alipay.testapp.common.dal ds_bean1=table1,table2 ds_bean2=table3,table4 #配置格式 #ds_数据源bean=逻辑表名1,逻辑表名2 其中数据源 bean1、数据源 bean2 是应用代码中 dal 层的数据源 bean 的名称，支持多个数据源。表名支持正则表达式，无需带分库分表后缀，若有多个数据源时请注意，某张表只能属于一个数据源，如下图：\n数据库直连 数据库直连，用于 DB 数据模型的生成。在 src/test/resource/config/dbConf/ 下的 devdb.conf 或 testdb.conf 中配置如下：\nxxx_url = jdbc:oracle:thin:@localhost:1521:cifdb xxx_username = myname xxx_password = mypswd 一键配置的说明 一键配置测试框架主要生成包含两部分，一部分是基础 Java 类，另一类是必须的配置文件，具体生成内容如下：\nJava 类 AppNameActsBaseUtils.java\n测试脚本编写过程中常用的从框架中获取各种数据的工具类，初始化搭建只提供了常用的方法，可自行添加。\n AppNameActsTestBase.java\n封装后的应用测试基类，业务系统如有特殊需求可在其上自行封装，如果没有则可以忽略此文件。\n 配置文件 ","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ready/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c3a89cbf42d55c98206a08e94d05ffde","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-ready/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-ready/","summary":"框架准备 在阅读前，您可以参考快速开始下载并安装 ACTS IDE 和引入 ACTS 框架. 本部分主要包含编码说明、数据源配置和一键配置说明，以帮助您使用 ACTS 框架。 编码说","tags":null,"title":"框架准备","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-ready/","wordcount":593},{"author":null,"categories":null,"content":" SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力。为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式：\n 基于代码组织上的模块化：这是最常见的形式，在开发期，将不同功能的代码放在不同 Java 工程下，在编译期被打进不同 jar 包，在运行期，所有 Java 类都在一个 classpath 下，没做任何隔离； 基于 Spring 上下文隔离的模块化：借用 Spring 上下文来做不同功能模块的隔离，在开发期和编译期，代码和配置也会分在不同 Java 工程中，但在运行期，不同模块间的 Spring Bean 相互不可见，DI 只在同一个上下文内部发生，但是所有的 Java 类还是在同一个 ClassLoader 下； 基于 ClassLoader 隔离的模块化：借用 ClassLoader 来做隔离，每个模块都有独立的 ClassLoader，模块与模块之间的 classpath 不同，SOFAArk 就是这种模块化的实践方式。 SOFABoot 模块化开发属于第二种模块化形式 —— 基于 Spring 上下文隔离的模块化。每个 SOFABoot 模块使用独立的 Spring 上下文，避免不同 SOFABoot 模块间的 BeanId 冲突，有效降低企业级多模块开发时团队间的沟通成本。\n关于 SOFABoot 模块化产生的背景，可参考文章《蚂蚁金服的业务系统模块化 \u0026amp;mdash;- 模块化隔离方案》\n功能简介 依赖引入 使用 SOFABoot 模块化开发方案，需要引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;isle-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFABoot 模块 SOFABoot 框架定义了 SOFABoot 模块的概念，一个 SOFABoot 模块是一个包括 Java 代码、Spring 配置文件、SOFABoot 模块标识等信息的普通 Jar 包，一个 SOFABoot 应用可以包含多个 SOFABoot 模块，每个 SOFABoot 模块都含有独立的 Spring 上下文。\n以 SOFABoot 模块为单元的模块化方式为开发者提供了以下功能：\n 运行时，每个 SOFABoot 模块的 Spring 上下文是隔离的，模块间定义的 Bean 不会相互影响； 每个 SOFABoot 模块是功能完备且自包含的，可以很容易在不同的 SOFABoot 应用中进行模块迁移和复用，只需将 SOFABoot 模块整个拷贝过去，调整 Maven 依赖，即可运行。 SOFABoot 模块的格式定义见: 模块配置。\nSOFABoot 模块间通信 上下文隔离后，模块与模块间的 Bean 无法直接注入，模块间需要通过 SOFA 服务进行通信，目前SOFABoot 提供了两种形式的服务发布和引用，用于解决不同级别的模块间调用的问题：\n JVM 服务发布和引用：解决一个 SOFABoot 应用内部各个 SOFABoot 模块之间的调用问题， JVM 服务发布与引用 RPC 服务发布和引用：解决多个 SOFABoot 应用之间的远程调用问题，RPC 服务发布与引用。 模块并行化启动 每个 SOFABoot 模块都是独立的 Spring 上下文，多个 SOFABoot 模块支持并行化启动，与 Spring Boot 的单 Spring 上下文模式相比，模块并行化启动能够加快应用的启动速度。\nRoot Application Context SOFABoot 应用运行时，本身会产生一个 Spring Context，我们把它叫做 Root Application Context，它是每个 SOFABoot 模块创建的 Spring Context 的 Parent。这样设计的目的是为了保证每个 SOFABoot 模块的 Spring Context 都能发现 Root Application Context 中创建的 Bean，这样当应用新增 Starter 时，不仅 Root Application Context 能够使用 Starter 中新增的 Bean，每个 SOFABoot 模块的 Spring Context 也能使用这些 Bean。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/modular-development/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"95bc080787c3614bfa485d2f3cd0de4c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/modular-development/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/modular-development/","summary":"SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力。为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式： 基于代码组织上的模块化","tags":null,"title":"模块化开发概述","type":"projects","url":"/sofastack.tech/projects/sofa-boot/modular-development/","wordcount":1073},{"author":null,"categories":null,"content":"SOFABoot 会根据 Require-Module 计算模块依赖树，例如以下依赖树表示模块B 和模块C 依赖模块A，模块E 依赖模块D，模块F 依赖模块E：\n该依赖树会保证模块A 必定在模块B 和模块C 之前启动，模块D 在模块E 之前启动，模块E 在模块F 之前启动，但是依赖树没有定义模块B 与模块C，模块B、C与模块D、E、F之间的启动顺序，这几个模块之间可以串行启动，也可以并行启动。\nSOFABoot 默认会并行启动模块，在使用过程中，如果希望关闭并行启动，可以在 application.properties 中增加以下参数:\ncom.alipay.sofa.boot.module-start-up-parallel=false ","date":-62135596800,"description":"","dir":"projects/sofa-boot/parallel-start/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a6ef51b78d2a4f9af0debbc25ea45e8a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/parallel-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/parallel-start/","summary":"SOFABoot 会根据 Require-Module 计算模块依赖树，例如以下依赖树表示模块B 和模块C 依赖模块A，模块E 依赖模块D，模块F 依赖模块E： 该依赖树会保证模块A 必定在模块B 和","tags":null,"title":"模块并行化启动","type":"projects","url":"/sofastack.tech/projects/sofa-boot/parallel-start/","wordcount":204},{"author":null,"categories":null,"content":" SOFABoot 模块是一个普通的 Jar 包加上一些 SOFABoot 特有的配置，这些 SOFABoot 特有的配置，让一个 Jar 包能够被 SOFABoot 识别，使之具备模块化的能力。\n一个完整的 SOFABoot 模块和一个普通的 Jar 包有两点区别:\n SOFABoot 模块包含一份 sofa-module.properties 文件，这份文件里面定义了 SOFABoot 模块的名称以及模块之间的依赖关系。 SOFABoot 模块的 META-INF/spring 目录下，可以放置任意多的 Spring 配置文件，SOFABoot 会自动把它们作为本模块的 Spring 配置加载起来。 sofa-module.properties 文件详解 先来看一份完整的 sofa-module.properties 文件（src/main/resources 目录下）：\nModule-Name=com.alipay.test.biz.service.impl Spring-Parent=com.alipay.test.common.dal Require-Module=com.alipay.test.biz.shared Module-Profile=dev Module-Name Module-Name 是 SOFABoot 模块的名称，也是 SOFABoot 模块的唯一标示符。在一个 SOFABoot 应用中，一个 SOFABoot 模块的 Module-Name 必须和其他的 SOFABoot 模块的 Module-Name 不一样。需要注意的一点是，一个 SOFABoot 应用运行时的 SOFABoot 模块，不仅仅只包含本应用的模块，还包括依赖了其他应用的 SOFABoot 模块，确定是否唯一的时候需要把这些 SOFABoot 模块也考虑进去。\nRequire-Module Require-Module 用于定义模块之间的依赖顺序，值是以逗号分隔的 SOFABoot 模块名列表，比如上面的配置中，就表示本模块依赖于 com.alipay.test.biz.shared 模块。对于这种依赖关系的处理，SOFABoot 会将 com.alipay.test.biz.shared 模块在本模块之前启动，即com.alipay.test.biz.shared 模块将先启动 Spring 上下文。\n一般情况下，是不需要为模块定义 Require-Module 的，只有当模块的 Spring 上下文的启动依赖于另一个模块的 Spring 上下文的启动时，才需要定义 Require-Module。举一个例子，如果你在 A 模块中发布了一个 SOFA JVM Service。在 B 模块的某一个 Bean 的 init 方法里面，需要使用 SOFA Reference 调用这个 JVM Service。假设 B 模块在 A 模块之前启动了，那么 B 模块的 Bean 就会因为 A 模块的 JVM Service 没有发布而 init 失败，导致 Spring 上下文启动失败。这个时候，我们就可以使用 Require-Module 来强制 A 模块在 B 模块之前启动。\nSpring-Parent 在 SOFABoot 应用中，每一个 SOFABoot 模块都是一个独立的 Spring 上下文，并且这些 Spring 上下文之间是相互隔离的。虽然这样的模块化方式可以带来诸多好处，但是，在某些场景下还是会有一些不便，这个时候，你可以通过 Spring-Parent 来打通两个 SOFABoot 模块的 Spring 上下文。Spring-Parent 属性可以配置一个模块的名称，比如上面的配置中，就将 com.alipay.test.common.dal 的 Spring 上下文设置为当前模块的 Spring 上下文的父 Spring 上下文。\n由于 Spring 的限制，一个模块的 Spring-Parent 只能有一个模块\n关于 Spring 的父上下文的作用可以看 Spring 的 BeanFactory 的说明：http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/beans/factory/BeanFactory.html\nModule-Profile 支持 SOFABoot Profile 能力： SOFABoot Profile\nSpring 配置文件 SOFABoot 模块可以包含 Spring 配置文件，配置文件需要放置在 META-INF/spring 目录下，SOFABoot 启动时会自动扫描该目录，并把目录下所有 XML 文件作为本模块的 Spring 配置加载起来。在 Spring 配置文件中，我们可以定义 Bean、发布服务等等。\nSOFABoot 模块一般用于封装对外发布服务接口的具体实现，属于业务层，Controller 属于展现层内容，我们不建议也不支持在 SOFABoot 模块中定义 Controller 组件，Controller 组件相关定义请直接放在 Root Application Context。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-module/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2dbb8a536237f21afbee1e3f320b8193","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-module/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-module/","summary":"SOFABoot 模块是一个普通的 Jar 包加上一些 SOFABoot 特有的配置，这些 SOFABoot 特有的配置，让一个 Jar 包能够被 SOFABoot 识别，使之具备模块化的能力。 一个完整的 SOFABoot 模块和一个普通的 Jar 包","tags":null,"title":"模块配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-module/","wordcount":1194},{"author":null,"categories":null,"content":"如果你要扩展一个注册中心，我们先看下注册中心的抽象类。\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026amp;lt;ProviderConfig\u0026amp;gt; configs); public abstract List\u0026amp;lt;ProviderGroup\u0026amp;gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026amp;lt;ConsumerConfig\u0026amp;gt; configs); } 可以看到我们需要的主要接口。\n 启动注册中心客户端、维持连接 销毁注册中心客户端、释放资源 发布服务、缓存发布信息 取消发布服务、删除缓存 订阅服务列表、同步或者异步返回数据，有变化接收通知 取消订阅服务列表、删除缓存 其它\n 注册中心节点断连后，不影响本地调用 和一个注册中心节点断连后，可自己切换到其它注册中心节点 注册中心节点切换后，自动恢复注册和订阅信息 注册中心数据缓存到本地文件，就算连不上任何注册中心，服务提供者和服务调用者也能重启并正常调用 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-extension-guide/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c952ecbea16f7ae68ad095ab8baf0583","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","summary":"如果你要扩展一个注册中心，我们先看下注册中心的抽象类。 package com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026lt;ProviderConfig\u0026gt; configs); public abstract List\u0026lt;ProviderGroup\u0026gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public","tags":null,"title":"注册中心扩展指南","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","wordcount":290},{"author":null,"categories":null,"content":"SOFABoot RPC Starter 为用户提供多种注册中心选择和方便的配置。 目前 bolt ， rest ， dubbo 都支持 Zookeeper 作为注册中心。另外 bolt ， rest 支持本地文件系统作为注册中心，该种模式一般用于测试。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-usage/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5a1a4619c8ac4a9fc27b8576472aed9f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-usage/","summary":"SOFABoot RPC Starter 为用户提供多种注册中心选择和方便的配置。 目前 bolt ， rest ， dubbo 都支持 Zookeeper 作为注册中心。另外 bolt ， rest 支持本地文件系统作为注册中心，该种模式一般用于测","tags":null,"title":"注册中心选择","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-usage/","wordcount":72},{"author":null,"categories":null,"content":" 本文描述的是 MOSN 作为 Sidecar 使用时的流量劫持方案。\nMOSN 作为 Sidecar 和业务容器部署在同一个 Pod 中时，需要使得业务应用的 Inbound 和 Outbound 服务请求都能够经过 Sidecar 处理。区别于 Istio 社区使用 iptables 做流量透明劫持，MOSN 目前使用的是流量接管方案，并在积极探索适用于大规模流量下的透明劫持方案。\n流量接管 区别于 Istio 社区的 iptables 流量劫持方案，MOSN 使用的流量接管的方案如下：\n 假设服务端运行在 1.2.3.4 这台机器上，监听 20880 端口，首先服务端会向自己的 Sidecar 发起服务注册请求，告知 Sidecar 需要注册的服务以及 IP + 端口（1.2.3.4:20880） 服务端的 Sidecar 会向服务注册中心（如 SOFA Registry）发起服务注册请求，告知需要注册的服务以及 IP + 端口，不过这里需要注意的是注册上去的并不是业务应用的端口（20880），而是 Sidecar 自己监听的一个端口（例如：20881） 调用端向自己的 Sidecar 发起服务订阅请求，告知需要订阅的服务信息 调用端的 Sidecar 向调用端推送服务地址，这里需要注意的是推送的 IP 是本机，端口是调用端的 Sidecar 监听的端口（例如 20882） 调用端的 Sidecar 会向服务注册中心（如 SOFA Registry）发起服务订阅请求，告知需要订阅的服务信息； 服务注册中心（如 SOFA Registry）向调用端的 Sidecar 推送服务地址（1.2.3.4:20881） 服务调用过程 经过上述的服务发现过程，流量转发过程就显得非常自然了：\n 调用端拿到的服务端地址是 127.0.0.1:20882，所以就会向这个地址发起服务调用 调用端的 Sidecar 接收到请求后，通过解析请求头，可以得知具体要调用的服务信息，然后获取之前从服务注册中心返回的地址后就可以发起真实的调用（1.2.3.4:20881） 服务端的 Sidecar 接收到请求后，经过一系列处理，最终会把请求发送给服务端（127.0.0.1:20880） 透明劫持 上文通过在服务注册过程中把服务端地址替换成本机监听端口实现了轻量级的“流量劫持”，在存在注册中心，且调用端和服务端同时使用特定SDK的场景中可以很好的工作，如果不满足这两个条件，则无法流量劫持。为了降低对于应用程序的要求，需要引入透明劫持。\n使用 iptables 做流量劫持 iptables 通过 NAT 表的 redirect 动作执行流量重定向，通过 syn 包触发新建 nefilter 层的连接，后续报文到来时查找连接转换目的地址与端口。新建连接时同时会记录下原始目的地址，应用程序可以通过(SOL_IP、SO_ORIGINAL_DST)获取到真实的目的地址。\niptables 劫持原理如下图所示：\n使用 iptables 做流量劫持时存在的问题 目前 Istio 使用 iptables 实现透明劫持，主要存在以下三个问题： 1. 需要借助于 conntrack 模块实现连接跟踪，在连接数较多的情况下，会造成较大的消耗，同时可能会造成 track 表满的情况，为了避免这个问题，业内有关闭 conntrack 的做法，比如阿里巴巴就关闭了这个模块。 1. iptables 属于常用模块，全局生效，不能显式的禁止相关联的修改，可管控性比较差。 1. iptables 重定向流量本质上是通过 loopback 交换数据，outbond 流量将两次穿越协议栈，在大并发场景下会损失转发性能。\n上述几个问题并非在所有场景中都存在，比方说某些场景下，连接数并不多，且 NAT 表未被使用到的情况下，iptables 是一个满足要求的简单方案。为了适配更加广泛的场景，透明劫持需要解决上述三个问题。\n透明劫持方案优化 使用 tproxy 处理 inbound 流量\ntproxy 可以用于 inbound 流量的重定向，且无需改变报文中的目的 IP/端口，不需要执行连接跟踪，不会出现 conntrack 模块创建大量连接的问题。受限于内核版本，tproxy 应用于 outbound 存在一定缺陷。目前 Istio 支持通过 tproxy 处理 inbound 流量。\n使用 hook connect 处理 outbound 流量\n为了适配更多应用场景，outbound 方向通过 hook connect 来实现，实现原理如下：\n无论采用哪种透明劫持方案，均需要解决获取真实目的 IP/端口的问题，使用 iptables 方案通过 getsockopt 方式获取，tproxy 可以直接读取目的地址，通过修改调用接口，hook connect 方案读取方式类似于tproxy。\n实现透明劫持后，在内核版本满足要求（4.16以上）的前提下，通过 sockmap 可以缩短报文穿越路径，进而改善 outbound 方向的转发性能。\n总结 总结来看，如果应用程序通过注册中心发布/订阅服务时，可以结合注册中心劫持流量；在需要用到透明劫持的场景，如果性能压力不大，使用 iptables redirect 即可，大并发压力下使用 tproxy 与hook connect 结合的方案。\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/traffic-hijack/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5845d8478a48fcddc74f0b9d28ede2c2","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/traffic-hijack/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/concept/traffic-hijack/","summary":"本文描述的是 MOSN 作为 Sidecar 使用时的流量劫持方案。 MOSN 作为 Sidecar 和业务容器部署在同一个 Pod 中时，需要使得业务应用的 Inbound 和 Outbound 服务请求都能够经过 Sidecar 处理。区别于 Istio 社","tags":null,"title":"流量劫持","type":"projects","url":"/sofastack.tech/projects/mosn/concept/traffic-hijack/","wordcount":1671},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.1.2。\n参见: http://semver.org/lang/zh-CN/。\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 5.3.0，那么将会维护 5.2.x 的 bugfix 分支，而 5.1.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 5.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 5.3.0。 发布后拉起下一个版本，例如 5.3.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/version-release/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"604f113607e6815757f4d1907190c13c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/version-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/version-release/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.1.2。 参见: http://semver.org/lang/zh-CN/","tags":null,"title":"版本发布","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/version-release/","wordcount":315},{"author":null,"categories":null,"content":" 1.3.2 2020-06-19\n Bug Fixes 移除对 bolt address parser 的扩展，避免 check connection 返回结果不符合预期 SPI 组件 JRaftServiceLoader 改为延迟加载策略规避多余对象的创建 几个 corner case 修复，比如 replicate logs 如果比 appliedIndex（follower）更小，那么可以认为是成功的 关闭 Recyclers 时的 IndexOutOfBoundsException 问题修复 Features 抽象出网络通信层，增加 GRPC 实现并支持 Replication Pipeline，用户亦可自行对通信层进行其他实现的扩展 RheaKV 增加 reverseScan API 提供 Replicator 与 RPC 的线程池隔离，避免相互影响 read-index 线性一致读请求提供请求超时（timeout）配置 Breaking Changes 无 致谢（排名不分先后） @shibd @SteNicholas @killme2008 @zongtanghu 1.3.1 2020-04-17\n Bug Fixes 修复 bolt rpc callback 默认的任务饱和丢弃策略，改为抛出异常 修复 learner 启动晚于 leader 选举成功时无法复制日志的 bug Features multi raft group 之间共享 timer 和 scheduler 等较重的线程资源，优化 multi group 场景中的多余资源占用 提供 RPC adapter，用户可基于 SPI 扩展不同的 RPC 实现 正式提供稳定的 RocksDBSegmentLogStorage，适合 value 较大的数据存储 sofa-bolt 升级到 1.6.1，支持 SSL 以及具有更好的小数据包传输能力 引入一个新的数据结构 segment list 来解决 LogManager 中过多的 log memory copy 采纳 nacos 的建议，对 raft Task 增加 join API Breaking Changes 无 致谢（排名不分先后） @jovany-wang @SteNicholas @zongtanghu @OpenOpened 1.3.0 2019-11-29\n Bug Fixes 删除数据并重启且期间没有新的 task 提交的情况下 prev log index 紊乱的修复 修复一些选举和线性一致读相关的 corner case Recyclers 多个线程 recycle 资源时的 NPE 修复 Features 新增 Read-only member(learner) 角色，支持 learner 节点上的线性一致读 实现优先级选举 在 multi raft group 的场景中，随机打散每个 group 的第一次 snapshot timeout 时间，避免一个进程内多个 group 同时 snapshot RheaKV 新增 containsKey API RheaKV 实现 snapshot checksum 以及异步 snapshot 新增 replicator 的 state 监听器： ReplicatorStateListener RepeatedTimer 的默认实现替换为 HashedWheelTimer 修复 windows 上定时器 CPU 消耗偏高的问题 kill -s SIGUSR2 pid 中增加打印 rocksdb stats 和所有 ThreadPool 指标统计信息 升级 rocksdb 版本到 5.18.3 新增实验性质的 RocksDBSegmentLogStorage，适合 value 较大的数据存储 Counter 例子改进，演示 ReadIndex 线性一致读 当优化 checksum 中多余的 mem copy Breaking Changes 无 致谢（排名不分先后） @zongtanghu @devYun @masaimu @SteNicholas @yetingsky 1.2.6 2019-08-15\n Bug Fixes 修复 ReadIndex 并发情况下可能出现的读超时 保存 raft meta 失败后终止状态机 修复 windows 环境中无法原子 move 文件的问题 当 RheaKV apply 失败时终止状态机避免出现数据不一致情况 Features 增加 LogEntry checksum validation 优化 log replication 线程模型减少锁竞争 优化 RheaKV multi group snapshot 对于 multi-raft-group 场景，提供 manual rebalance API 在无 PD 模式手动平衡各节点 leader 数量 CliService 提供获取存活 follower 节点的 API 引入 SPI 扩展机制，LogStorage、SnapshotStorage、RaftMetaStorage、LogEntryCodec 均可基于 SPI 扩展 Linux 平台 SIGUSR2 信号输出节点状态以及 metric 信息 RheaKV 增加 CompareAndPut 原子更新 API 新增 pooled buf allocator 解决 log replication 时大量分配 byte[] 频繁触发 fullgc 默认关闭 RheaKV rocksdb 的 fsync 和 WAL，依靠 raft log 和 snapshot 确保数据一致性 当 raft node 过载时拒绝新的请求 Breaking Changes 无 致谢（排名不分先后） @SteNicholas @zongtanghu 1.2.5 2019-04-01\n Bug Fixes 修复 jmh 与 unit test 代码冲突问题 修复 snapshot 过大引起的安装失败 bug，会影响新增节点的加入 Features LogManagerImpl 中耗费 cpu 部分的代码优化 修正一些单词拼写错误 Breaking Changes 无 此版本强烈推荐升级\n1.2.4 2019-03-20\n Bug Fixes 修复一种情况下 lease read 的 stale read 部分 timestamp 修改为 monotonic time 修复一种情况下 replicator 被 block 住的问题 解决 windows 平台下某些单测无法创建目录 解决 windows 平台下某些 rocksdb options 设置不当导致进程 crash Features 开放 RocksDB options 的设置给用户层 Pre-vote 优化，启用 lease 机制来规避网络分区+集群长时间无写入的情况下，游离节点回归后打断当前 term，提升系统可用性 升级 bolt …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/release-log/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9e24fb74a3cda6a600252b01f8a85db9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/release-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-jraft/release-log/","summary":"1.3.2 2020-06-19 Bug Fixes 移除对 bolt address parser 的扩展，避免 check connection 返回结果不符合预期 SPI 组件 JRaftServiceLoader 改为延迟加载策略规避多余对象的创建 几个 corner case 修复，比如 replicate logs 如果比 appliedI","tags":null,"title":"版本发行日志","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/release-log/","wordcount":2298},{"author":null,"categories":null,"content":" 通过 SOFABoot，我们可以直接在浏览器中就可以查看 SOFA 中间件的版本等详细信息。\n引入 SOFABoot Infra 依赖 要在 SOFABoot 中直接通过浏览器查看 SOFA 中间件的版本信息，只需要在 Maven 依赖中增加如下的内容即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;infra-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 版本信息查看 在应用启动成功后，可以在浏览器中输入 http://localhost:8080/sofaboot/versions 查看 SOFA 中间件的版本信息，如：\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Built-Time: \u0026amp;quot;2018-04-05T20:55:22+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.0\u0026amp;quot; } ] 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，sofaboot/versions 更改为 actuator/versions\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/view-versions/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c6b6d22e9038aa1f5e4ce74449ba1cda","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/view-versions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/view-versions/","summary":"通过 SOFABoot，我们可以直接在浏览器中就可以查看 SOFA 中间件的版本等详细信息。 引入 SOFABoot Infra 依赖 要在 SOFABoot 中直接通过浏览器查看 SOFA 中间件的版本信息，只","tags":null,"title":"版本查看","type":"projects","url":"/sofastack.tech/projects/sofa-boot/view-versions/","wordcount":182},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 1.0.0。\n参见: http://semver.org/lang/zh-CN/\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 1.2.0，那么将会维护 1.1.x 的 bugfix 分支，而 1.0.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 1.0.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 1.0.0。 发布后拉起下一个版本，例如 1.0.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/version-rule/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a2093bdf478bdff0e15a2de70e522d03","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/version-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/version-rule/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 1.0.0。 参见: http://semver.org/lang/zh-CN/ 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本","tags":null,"title":"版本规范","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/version-rule/","wordcount":286},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.2.0。\n参见: http://semver.org/lang/zh-CN/\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 5.4.0，那么将会维护 5.3.x 的 bugfix 分支，而 5.2.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 5.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 5.3.0。 发布后拉起下一个版本，例如 5.3.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-standard/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"71aad9cbc42aba3d9f875ae9169cf005","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/release-standard/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/release-standard/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.2.0。 参见: http://semver.org/lang/zh-CN/ 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本","tags":null,"title":"版本规范","type":"projects","url":"/sofastack.tech/projects/sofa-registry/release-standard/","wordcount":286},{"author":null,"categories":null,"content":"SOFABoot 使用了一些三方开源组件，他们分别是：\n一些主要依赖：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License sofa-common-tools under Apache 2.0 license 一些扩展依赖：\n nuxeo under Apache License, Version 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"11f073a7a9965ab5690ed166fe319bbd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/notice/","summary":"SOFABoot 使用了一些三方开源组件，他们分别是： 一些主要依赖： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License sofa-common-tools under Apache 2.0 license 一些扩展依赖： nuxeo under Apache License, Version 2.0 \u0026hellip; 其它整理中。","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-boot/notice/","wordcount":67},{"author":null,"categories":null,"content":" 依赖组件版权说明 SOFADashboard 使用了一些三方开源组件，他们分别是：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFA Bolt under Apache License 2.0 SOFA Bolt under Apache License 2.0 Curator under Apache License 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a9ebe38d245302f94ab7bfa793329926","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/notice/","summary":"依赖组件版权说明 SOFADashboard 使用了一些三方开源组件，他们分别是： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFA Bolt under Apache License 2.0 SOFA Bolt under Apache License 2.0 Curator under Apache License 2.0 \u0026hellip; 其它整理中。","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/notice/","wordcount":67},{"author":null,"categories":null,"content":" 依赖组件版权说明 SOFARegistry 使用了一些三方开源组件，他们分别是：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1  SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 \u0026amp;hellip; 其它整理中，如若发现遗漏，还请主动告知。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c40263ffd56a2f1292756c9fafea55e2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/notice/","summary":"依赖组件版权说明 SOFARegistry 使用了一些三方开源组件，他们分别是： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1 SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 \u0026hellip; 其","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-registry/notice/","wordcount":89},{"author":null,"categories":null,"content":" RheaKV：基于 JRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库。 AntQ Streams QCoordinator： 使用 JRaft 在 coordinator 集群内做选举、元信息存储等功能。 SOFA 服务注册中心元信息管理模块：IP 数据信息注册，要求写数据达到各个节点一致，并且在不小于一半节点挂掉，保证不影响数据正常存储。 AntQ NameServer 选主 ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/user-stories/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b233be7d9eed33645945293e637e28ea","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/user-stories/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/user-stories/","summary":"RheaKV：基于 JRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库。 AntQ Streams QCoordinator： 使用 JRaft 在 coordinator 集群内做选举、元信息存储等","tags":null,"title":"用户案例","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/user-stories/","wordcount":140},{"author":null,"categories":null,"content":"SOFARPC 支持指定地址进行调用的场景。用 Java API 的使用方式如下，设置直连地址即可：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); 用 XML 的使用方式如下：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sample.HelloService\u0026amp;quot; id=\u0026amp;quot;helloService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 用 Annotation 的使用方式如下：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, directUrl = \u0026amp;quot;127.0.0.1:12220\u0026amp;quot;)) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/peer-to-peer/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b1815c322f5dc9528f6429d1d5e38369","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/peer-to-peer/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/peer-to-peer/","summary":"SOFARPC 支持指定地址进行调用的场景。用 Java API 的使用方式如下，设置直连地址即可： ConsumerConfig\u0026lt;HelloService\u0026gt; consumer = new ConsumerConfig\u0026lt;HelloService\u0026gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026quot;bolt://127.0.0.1:12201\u0026quot;); 用 XML 的使用方式如下： \u0026lt;sofa:reference interface=\u0026quot;com.alipay.sample.HelloService\u0026quot; id=\u0026quot;helloService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:route target-url=\u0026quot;127.0.0.1:12200\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:reference\u0026gt; 用 Annotation 的使用方式如下","tags":null,"title":"直连调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/peer-to-peer/","wordcount":82},{"author":null,"categories":null,"content":" 类委托加载 注：这里委托加载不止包含类委托，还包含资源委托加载。\nSOFAArk 通过多 ClassLoader 的方式提供类隔离的能力，并在此基础上具备多版本隔离和热部署的能力。当然类如果纯粹隔离还不够，还需要考虑ClassLoader之间的类共享。SOFAArk 通过类委托机制，提供了一套丰富的委托加载能力。定义了PluginClassLoader 和 BizClassLoader，不同类型具备不同的类查找逻辑，同时提供ClassLoaderHook能力，允许自定义模块间的类委托加载。SOFAArk 框架本身的类委托加载是非常灵活的，但是在实际落地时，需要有一套类委托加载的最佳实践。\nSOFAArk 支持的场景主要分为两类： 1. 多Plugin的类隔离：考虑如何相同类不同版本不会相互冲突 2. 合并部署/热部署：原应用如何拆分，或多个应用如何合并\n这里我们主要考虑第2种，多 ClassLoader 如何布局，在内部探索出的最佳实践多 ClassLoader 布局为 模块里的类和资源查找优先从模块里查找列，查找不到从再基座里查找。\n最佳实践 类委托加载的准则是中间件相关的依赖需要放在同一个的 ClassLoader 里进行加载执行，达到这种方式的最佳实践有两种：\n强制委托加载 由于中间件相关的依赖一般需要在同一个ClassLoader里加载运行，所以可以制定一个中间件依赖的白名单，强制这些依赖委托给基座加载。SOFAArk 已经提供白名单能力，详细查看与 sofa.ark.plugin.export.class.enable 有关源码。\n强制加载优缺点 优点 模块开发者不需要感知哪些依赖属于需要强制加载由同一个 ClassLoader 加载的依赖\n 缺点 白名单里要强制加载的依赖列表需要维护，列表的缺失需要更新基座，较为重要的升级需要推所有的基座升级。\n自定义委托加载 模块里pom通过设置依赖的 scope 为 provided主动指定哪些要委托给基座加载。通过模块瘦身工具自动把与基座重复的依赖委托给基座加载，基座通过预置中间件的依赖（可选，虽然模块暂时不会用到，但可以提前引入，以备后续模块需要引入的时候不需再发布基座即可引入）\n1. 基座预置依赖 基座可以提前预置一些依赖\n2. 通过两种方式委托给基座加载 模块pom里依赖 scope 设置为 provided biz 打包插件sofa-ark-maven-plugin里设置 excludeGroupIds 或 excludeArtifactIds 3. 只有模块声明过的依赖才可以委托给基座加载 模块启动的时候，框架会有一些扫描逻辑，这些扫描如果不做限制会查找到模块和基座的所有类、资源，导致一些模块明明不需要的功能尝试去初始化，从而报错。SOFAArk 2.0.3之后新增了模块的 declaredMode, 来限制只有模块里声明过的依赖才可以委托给基座加载。只需在模块的 sofa-ark-maven-plugin 打包插件的 Configurations 里增加 true即可。\n自定义委托加载优缺点 优点 不需要维护强制加载列表，当部分需要由同一 ClassLoader 加载的依赖没有设置为统一加载时，可以修改模块就可以修复，不需要发布基座（除非基座确实依赖）。\n 缺点 对模块自动瘦身的依赖较强\n对比与总结 ||依赖缺失排查成本|修复成本|模块改造成本|维护成本| |-|-|-|-|-| |强制加载|类转换失败或类查找失败，成本中|更新 plugin，发布基座，高|低|高| |自定义委托加载 |类转换失败或类查找失败，成本中|更新模块依赖，如果基座依赖不足，需要更新基座并发布，中|高|低| |自定义委托加载 + 基座预置依赖 + 模块自动瘦身|类转换失败或类查找失败，成本中|更新模块依赖，设置为provided，低|低|低|\n推荐自定义委托加载方式 模块自定义委托加载 + 模块自动瘦身 模块开启 declaredMode 基座预置依赖 开启后的副作用 由于基座提前启动，模块再次启动的时候，如果依赖了基座的依赖里有发布服务，那么模块在启动的时候还会再次发布，如果该问题有一定影响可以模块pom里exclude掉对应的依赖。 ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-class-loader-delegation/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d3ea2dc9104433356ad82b6a772a971a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","summary":"类委托加载 注：这里委托加载不止包含类委托，还包含资源委托加载。 SOFAArk 通过多 ClassLoader 的方式提供类隔离的能力，并在此基础上具备多版本隔离和热部署的能力。当","tags":null,"title":"类委托加载","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","wordcount":1447},{"author":null,"categories":null,"content":"介绍几种 SOFARPC 在不同环境下的使用方式 * 非 Spring 环境 API 使用 * SOFABoot 环境 XML 配置使用 * SOFABoot 环境注解使用 * SOFABoot 环境动态 API 使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programming/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9a947dae761c84aa4d95121c076ac552","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programming/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programming/","summary":"介绍几种 SOFARPC 在不同环境下的使用方式 * 非 Spring 环境 API 使用 * SOFABoot 环境 XML 配置使用 * SOFABoot 环境注解使用 * SOFABoot 环境动态 API 使用","tags":null,"title":"编程界面","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programming/","wordcount":50},{"author":null,"categories":null,"content":"自动故障剔除会自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复。目前支持 bolt 协议。\n在 SOFABoot 中，只需要配置自动故障剔除的参数到 application.properties 即可。可以不完全配置，只配置自己关心的参数，其余参数会取默认值。需要注意的是 com.alipay.sofa.rpc.aft.regulation.effective 是该功能的全局开关，如果关闭则该功能不会运行，其他参数也都不生效。\n 属性 描述 默认值 timeWindow 时间窗口大小：对统计信息计算的周期。 10s leastWindowCount 时间窗口内最少调用数：只有在时间窗口内达到了该最低值的数据才会被加入到计算和调控中。 10次 leastWindowExceptionRateMultiple 时间窗口内异常率与服务平均异常率的降级比值：在对统计信息进行计算的时候，会计算出该服务所有有效调用ip的平均异常率，如果某个ip的异常率大于等于了这个最低比值，则会被降级。 6倍 weightDegradeRate 降级比率：地址在进行权重降级时的降级比率。 1\u0026amp;frasl;20 weightRecoverRate 恢复比率：地址在进行权重恢复时的恢复比率。 2倍 degradeEffective 降级开关：如果应用打开了这个开关，则会对符合降级的地址进行降级，否则只会进行日志打印。 false(关闭) degradeLeastWeight 降级最小权重：地址权重被降级后的值如果小于这个最小权重，则会以该最小权重作为降级后的值。 1 degradeMaxIpCount 降级的最大ip数：同一个服务被降级的ip数不能超过该值。 2 regulationEffective 全局开关：如果应用打开了这个开关，则会开启整个单点故障自动剔除摘除功能，否则完全不进入该功能的逻辑。 false(关闭) 示例\ncom.alipay.sofa.rpc.aft.time.window=20 com.alipay.sofa.rpc.aft.least.window.count=30 com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple=1.4 com.alipay.sofa.rpc.aft.weight.degrade.rate=0.5 com.alipay.sofa.rpc.aft.weight.recover.rate=1.2 com.alipay.sofa.rpc.aft.degrade.effective=true com.alipay.sofa.rpc.aft.degrade.least.weight=1 com.alipay.sofa.rpc.aft.degrade.max.ip.count=2 com.alipay.sofa.rpc.aft.regulation.effective=true 如上配置，打开了自动故障剔除功能和降级开关，当节点出现故障时会被进行权重降级，在恢复时会被进行权重恢复。每隔 20s 进行一次节点健康状态的度量，20s 内调用次数超过 30 次的节点才被作为计算数据，如果单个节点的异常率超过了所有节点的平均异常率的 1.4 倍则对该节点进行权重降级，降级的比率为 0.5 。权重最小降级到 1 。如果单个节点的异常率低于了平均异常率的 1.4 倍则对该节点进行权重恢复，恢复的比率为1.2 。单个服务最多降级 2 个ip。\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-fault-tolerance/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a132b54b2398534d1773489e2b0db166","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","summary":"自动故障剔除会自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复。目前支持 bolt 协议。 在 SOFABoot 中，只需要配置自动故障剔除的","tags":null,"title":"自动故障剔除","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","wordcount":759},{"author":null,"categories":null,"content":"集群中通常一个服务有多个服务提供者。其中部分服务提供者可能由于网络，配置，长时间 fullgc ，线程池满，硬件故障等导致长连接还存活但是程序已经无法正常响应。单机故障剔除功能会将这部分异常的服务提供者进行降级，使得客户端的请求更多地指向健康节点。当异常节点的表现正常后，单机故障剔除功能会对该节点进行恢复，使得客户端请求逐渐将流量分发到该节点。单机故障剔除功能解决了服务故障持续影响业务的问题，避免了雪崩效应。可以减少人工干预需要的较长的响应时间，提高系统可用率。\n运行机制：\n 单机故障剔除会统计一个时间窗口内的调用次数和异常次数，并计算每个服务对应ip的异常率和该服务的平均异常率。 当达到ip异常率大于服务平均异常率到一定比例时，会对该服务+ip的维度进行权重降级。 如果该服务+ip维度的权重并没有降为0，那么当该服务+ip维度的调用情况正常时，则会对其进行权重恢复。 整个计算和调控过程异步进行，不会阻塞调用。 单机故障剔除的使用方式如下：\nFaultToleranceConfig faultToleranceConfig = new FaultToleranceConfig(); faultToleranceConfig.setRegulationEffective(true); faultToleranceConfig.setDegradeEffective(true); faultToleranceConfig.setTimeWindow(20); faultToleranceConfig.setWeightDegradeRate(0.5); FaultToleranceConfigManager.putAppConfig(\u0026amp;quot;appName\u0026amp;quot;, faultToleranceConfig); 如上，该应用会在打开了单机故障剔除开关，每20s的时间窗口进行一次异常情况的计算，如果某个服务+ip的调用维度被判定为故障节点，则会进行将该服务+ip的权重降级为0.5倍。\n更加详细的参数请参考单机故障剔除参数。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-tolerance/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7501b0fac1d1d89c61de0d591e29e1d0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault-tolerance/","summary":"集群中通常一个服务有多个服务提供者。其中部分服务提供者可能由于网络，配置，长时间 fullgc ，线程池满，硬件故障等导致长连接还存活但是程序已经无法正常","tags":null,"title":"自动故障剔除","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault-tolerance/","wordcount":528},{"author":null,"categories":null,"content":" 在使用自定义埋点组件的情况下，用户可以选择自定义 Reporter。\n自定义 Reporter 实现 public class MyReporter implements Reporter { @Override public String getReporterType() { return \u0026amp;quot;myReporter\u0026amp;quot;; } @Override public void report(SofaTracerSpan sofaTracerSpan) { // System.out 输出 System.out.println(\u0026amp;quot;this is my custom reporter\u0026amp;quot;); } @Override public void close() { // ignore } } 配置 com.alipay.sofa.tracer.reporter-name=com.glmapper.bridge.boot.flexible.MyReporter 自定义实现 Reporter 可以将业务埋点的日志输出到任何期望的地方。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/reporter-custom/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"521206c7f4051c1cc8ec8232c20bab6d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/reporter-custom/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/reporter-custom/","summary":"在使用自定义埋点组件的情况下，用户可以选择自定义 Reporter。 自定义 Reporter 实现 public class MyReporter implements Reporter { @Override public String getReporterType() { return \u0026quot;myReporter\u0026quot;; } @Override public void report(SofaTracerSpan sofaTracerSpan) { // System.out 输出 System.out.println(\u0026quot;this is my custom reporter\u0026quot;); } @Override","tags":null,"title":"自定义 Reporter","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/reporter-custom/","wordcount":108},{"author":null,"categories":null,"content":" SOFARPC 支持自定义业务线程池。可以为指定服务设置一个独立的业务线程池，和 SOFARPC 自身的业务线程池是隔离的。多个服务可以共用一个独立的线程池。\nSOFARPC 要求自定义线程池的类型必须是 com.alipay.sofa.rpc.server.UserThreadPool。\nXML 方式 如果采用 XML 的方式发布服务，可以先设定一个 class 为 com.alipay.sofa.rpc.server.UserThreadPool 的线程池的 Bean，然后设置到 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 thread-pool-ref 属性中：\n\u0026amp;lt;bean id=\u0026amp;quot;helloService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- 自定义一个线程池 --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;customExecutor\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.server.UserThreadPool\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;corePoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;maximumPoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;queueSize\u0026amp;quot; value=\u0026amp;quot;0\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloService\u0026amp;quot; interface=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;!-- 将线程池设置给一个 Service --\u0026amp;gt; \u0026amp;lt;sofa:global-attrs thread-pool-ref=\u0026amp;quot;customExecutor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation 方式 如果是采用 Annotation 的方式发布服务，可以通过设置 @SofaServiceBinding 的 userThreadPool 属性来设置自定义线程池的 Bean：\n@SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, userThreadPool = \u0026amp;quot;customThreadPool\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 在 Spring 环境使用 API 方式 如果是在 Spring 环境下使用 API 的方式发布服务，可以通过调用 BoltBindingParam 的 setUserThreadPool 方法来设置自定义线程池：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setUserThreadPool(new UserThreadPool()); 在非 Spring 环境下使用 API 方式 如果是在非 Spring 环境下使用 API 的方式，可以通过如下的方式来设置自定义线程池：\nUserThreadPool threadPool = new UserThreadPool(); threadPool.setCorePoolSize(10); threadPool.setMaximumPoolSize(100); threadPool.setKeepAliveTime(200); threadPool.setPrestartAllCoreThreads(false); threadPool.setAllowCoreThreadTimeOut(false); threadPool.setQueueSize(200); UserThreadPoolManager.registerUserThread(ConfigUniqueNameGenerator.getUniqueName(providerConfig), threadPool); 如上为 HelloService 服务设置了一个自定义线程池。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-threadpool/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3f05f154bcb2b653ebeebb35b84d5ae1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-threadpool/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-threadpool/","summary":"SOFARPC 支持自定义业务线程池。可以为指定服务设置一个独立的业务线程池，和 SOFARPC 自身的业务线程池是隔离的。多个服务可以共用一个独立的线程池。 SOFARPC 要求自定义","tags":null,"title":"自定义线程池","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-threadpool/","wordcount":412},{"author":null,"categories":null,"content":"SOFARPC 中对服务地址的选择也抽象为了一条处理链，由每一个 Router 进行处理。同 Filter 一样， SOFARPC 对 Router 提供了同样的扩展能力。\n@Extension(value = \u0026amp;quot;customerRouter\u0026amp;quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026amp;lt;ProviderInfo\u0026amp;gt; route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) { return providerInfos; } 新建扩展文件 META-INF/services/sofa-rpc/com.alipay.sofa.rpc.client.Router 。内容如下：\ncustomerRouter=com.alipay.sofa.rpc.custom.CustomRouter 如上自定义了一个 CustomerRouter ，生效于所有消费者。其中 init 参数 ConsumerBootstrap 是引用服务的包装类，能够拿到 ConsumerConfig ，代理类，服务地址池等对象。 needToLoad 表示是否生效该 Router ， route 方法即筛选地址的方法。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-router/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"236e8d4bda3e856267a3575853aa900c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-router/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-router/","summary":"SOFARPC 中对服务地址的选择也抽象为了一条处理链，由每一个 Router 进行处理。同 Filter 一样， SOFARPC 对 Router 提供了同样的扩展能力。 @Extension(value = \u0026quot;customerRouter\u0026quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override","tags":null,"title":"自定义路由寻址","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-router/","wordcount":179},{"author":null,"categories":null,"content":" SOFARPC 提供了一套良好的可扩展性机制，为各个模块提供 SPI 的能力。 SOFARPC 对请求与响应的过滤链处理方式是通过多个过滤器 Filter 来进行具体的拦截处理，该部分可由用户自定义 Filter 扩展，自定义 Filter 的执行顺序在内置 Filter 之后。具体方式如下：\nBolt Filter 新建自定义 Filter 。\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 生效该自定义 Filter 到拦截器链中。这一步具体方式有三种。 方式1：API方式。该种方式能够生效到指定的 provider 或 consumer 。\n// 服务提供者 providerConfig.setFilterRef(Arrays.asList(new CustomFilter())); // 服务调用者 consumerConfig.setFilterRef(Arrays.asList(new CustomFilter())); 方式2：在类上加上 @Extension 注解+配置扩展文件方式。\n@Extension(\u0026amp;quot;customer\u0026amp;quot;) public class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 新建扩展文件 META-INF/services/sofa-rpc/com.alipay.sofa.rpc.filter.Filter 。内容如下：\ncustomer=com.alipay.sofa.rpc.custom.CustomFilter 编码注入。\n// 服务提供者 providerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); // 服务调用者 consumerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); 方式三：在类上加上 @Extension 注解+ @AutoActive 注解方式+配扩展文件方式。该种方式利用 @AutoActive 注解代替了上述第二中方式的编码注入步骤，能够生效于所有 provider 或 consumer 。其中 providerSide 参数表示是否生效于服务端， consumerSide 参数表示是否生效于客户端。\n@Extension(\u0026amp;quot;customer\u0026amp;quot;) @AutoActive(providerSide = true, consumerSide = true) public class customerFilter extends Filter { // ... } ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-filter/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"30ff5937b52a7c2dd8028e878979a33d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-filter/","summary":"SOFARPC 提供了一套良好的可扩展性机制，为各个模块提供 SPI 的能力。 SOFARPC 对请求与响应的过滤链处理方式是通过多个过滤器 Filter 来进行具体的拦截处理，该部分可由用户","tags":null,"title":"自定义过滤器","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-filter/","wordcount":409},{"author":null,"categories":null,"content":" 本文是对 MOSN 自定义配置的说明。\nDuration String 字符串，由一个十进制数字和一个时间单位后缀组成，有效的时间单位为 ns、us（或µs）、ms、s、m、h，例如 1h、3s、500ms。 metadata metadata 用于 MOSN 路由和 Cluster Host 之间的匹配。\n{ \u0026amp;quot;filter_metadata\u0026amp;quot;:{ \u0026amp;quot;mosn.lb\u0026amp;quot;:{} } } mosn.lb 可对应任意的 string-string 的内容。\ntls_context { \u0026amp;quot;status\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;server_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;ca_cert\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;cert_chain\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;private_key\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;verify_client\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;require_client_cert\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;insecure_skip\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;cipher_suites\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;ecdh_curves\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;min_version\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;max_version\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;alpn\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;fall_back\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;extend_verify\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;sds_source\u0026amp;quot;:{} } status，bool类型，表示是否开启 TLS，默认是 false。 type，字符串类型，描述 tls_context 的类型。tls_context 支持扩展实现，不同的 type 对应不同的实现方式，默认实现方式对应的 type 是空字符串。 server_name，当没有配置 insecure_skip 时，用于校验服务端返回证书的 hostname。作为Cluster配置时有效。 ca_cert，证书签发的根 CA 证书。 cert_chain，TLS 证书链配置。 private_key，证书私钥配置。 verify_client，bool 类型，作为 Listener 配置时有效，表示是否要校验 Client 端证书 require_client_cert，bool 类型，表示是否强制 Client 端必须携带证书。 insecure_skip，bool 类型，作为 Cluster 配置时有效，表示是否要忽略 Server 端的证书校验。 cipher_suites，如果配置了该配置，那么 TLS 连接将只支持配置了的密码套件，并且会按照配置的顺序作为优先级使用，支持的套件类型如下：\nECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-AES256-CBC-SHA ECDHE-RSA-AES128-CBC-SHA ECDHE-ECDSA-AES256-CBC-SHA ECDHE-ECDSA-AES128-CBC-SHA RSA-AES256-CBC-SHA RSA-AES128-CBC-SHA ECDHE-RSA-3DES-EDE-CBC-SHA RSA-3DES-EDE-CBC-SHA ECDHE-RSA-SM4-SM3 ECDHE-ECDSA-SM4-SM3 ecdh_curves，如果配置了该配置，那么 TLS 连接将只支持配置了的曲线。\n 支持 x25519、p256、p384、p521。 min_version，最低的 TLS 协议版本，默认是 TLS1.0。\n 支持 TLS1.0、TLS1.1、TLS1.2。 默认会自动识别可用的 TLS 协议版本。 max_version，最高的 TLS 协议版本，默认是 TLS1.2。\n 支持 TLS1.0、TLS1.1、TLS1.2。 默认会自动识别可用的 TLS 协议版本。 alpn，TLS 的 ALPN 配置。\n 支持 h2、http/1.1、 sofa。 fall_back，bool类型，当配置为 true 时，如果证书解析失败，不会报错而是相当于没有开启 TLS。\n extend_verify，任意 json 类型，当 type 为非空时，作为扩展的配置参数。\n sds_source，访问 SDS API 的配置，如果配置了这个配置，ca_cert、cert_chain 和 private_key 都会被忽略，但是其余的配置依然有效。\n sds_source { \u0026amp;quot;CertificateConfig\u0026amp;quot;:{}, \u0026amp;quot;ValidationConfig\u0026amp;quot;:{} } CertificateConfig 描述了如何获取 cert_chain 和 private_key 的配置。 ValidationConfig 描述了如何获取 ca_cert 的配置。 详细的 Config 内容参考 envoy: sdssecretconfig。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/custom/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cdad467fd3551e47a7585511278767cd","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/custom/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/configuration/custom/","summary":"本文是对 MOSN 自定义配置的说明。 Duration String 字符串，由一个十进制数字和一个时间单位后缀组成，有效的时间单位为 ns、us（或µs）、ms、s、m、h，例如","tags":null,"title":"自定义配置说明","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/custom/","wordcount":1005},{"author":null,"categories":null,"content":" SOFARPC 支持进行框架层面的重试策略，前提是集群模式为 FailOver（SOFARPC 默认即为 FailOver 模式）。重试只有在发生服务端的框架层面异常或者是超时异常才会发起。如果是业务抛出异常，是不会重试的。默认情况下 SOFARPC 不进行任何重试。\n 请注意：超时异常虽然可以重试，但是需要服务端保证业务的幂等性，否则可能会有风险\n XML 方式 如果使用 XML 方式订阅服务，可以设置 sofa:global-attrs 的 retries 参数来设置重试次数：\n\u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;retriesServiceReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.retries.RetriesService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs retries=\u0026amp;quot;2\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 如果是使用 Annotation 的方式，可以通过设置 @SofaReferenceBinding 注解的 retries 属性来设置：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, retries = 2)) private SampleService sampleService; Spring 环境下 API 方式 如果是在 Spring 环境下用 API 的方式，可以调用 BoltBindingParam 的 setRetries 方法来设置：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setRetries(2); 非 Spring 环境下 API 方式 如果是在非 Spring 环境下直接使用 SOFARPC 的裸 API 的方式，可以通过调用 ConsumerConfig 的 setRetries 方法来设置：\nConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt;(); consumerConfig.setRetries(2); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/retry-invoke/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d60b44aa8f1b49ab6c1bbc55593a91da","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/retry-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/retry-invoke/","summary":"SOFARPC 支持进行框架层面的重试策略，前提是集群模式为 FailOver（SOFARPC 默认即为 FailOver 模式）。重试只有在发生服务端的框架层面异常或者是超时","tags":null,"title":"调用重试","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/retry-invoke/","wordcount":319},{"author":null,"categories":null,"content":" SOFARPC 提供多种负载均衡算法，目前支持以下五种：\n 类型 名称 描述 random 随机算法 默认负载均衡算法。 localPref 本地优先算法 优先发现是否本机发布了该服务，如果没有再采用随机算法。 roundRobin 轮询算法 方法级别的轮询，各个方法间各自轮询，互不影响。 consistentHash 一致性hash算法 同样的方法级别的请求会路由到同样的节点。 weightRoundRobin 按权重负载均衡轮询算法 按照权重对节点进行轮询。性能较差，不推荐使用。 要使用某种特定的负载均衡算法，可以按照以下的方式进行设置：\nXML 方式 如果使用 XML 的方式引用服务，可以通过设置 sofa:global-attrs 标签的 loadBalancer 属性来设置：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs loadBalancer=\u0026amp;quot;roundRobin\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 Annotation 方式目前暂未提供设置某一个 Reference 的负载均衡算法的方式。将在后续的版本中提供。\n在 Spring 环境下 API 方式 如果在 Spring 或者 Spring Boot 的环境下使用 API，可以通过调用 BoltBindingParam 的 setLoadBalancer 方法来设置：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setLoadBalancer(\u0026amp;quot;roundRobin\u0026amp;quot;); 非 Spring 环境下 API 方式 如果在非 Spring 环境下直接使用 SOFARPC 提供的裸 API，可以通过调用 ConsumerConfig 的 setLoadBalancer 方法来设置：\nConsumerConfig consumerConfig = new ConsumerConfig(); consumerConfig.setLoadbalancer(\u0026amp;quot;random\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/load-balance/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"739984ca9a414429304f85010fd73ad0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/load-balance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/load-balance/","summary":"SOFARPC 提供多种负载均衡算法，目前支持以下五种： 类型 名称 描述 random 随机算法 默认负载均衡算法。 localPref 本地优先算法 优先发现是否本机发布了该服务，如果没有再采用","tags":null,"title":"负载均衡","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/load-balance/","wordcount":375},{"author":null,"categories":null,"content":" 任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 文档 SOFADashboard 配置参数文档 简单 代码 支持 SOFARegistry 中 代码 支持 Docker 中 代码 支持 Kubernetes 中 代码 支持 Apollo 中 代码 优化前端 中 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/roadmap/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a740c874742b504de9011b07f3a4ddb5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/roadmap/","summary":"任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 文档 SOFADashboard 配置参数文档 简","tags":null,"title":"路线图及任务认领","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/roadmap/","wordcount":102},{"author":null,"categories":null,"content":" 1. registry-meta 1.1 推送开关 在注册中心新版本发布的过程中为了把对业务的影响减少到最小，避免服务端重启动引发大规模服务地址信息变更产生大量推送，我们提供运维层面暂时关闭推送的能力。在服务端完成发布后，可以打开推送恢复正常工作状态，在关闭期间的数据订阅和服务发布信息会再次进行全局推送进行补偿。\n打开推送：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/close\u0026amp;quot; 关闭推送：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/open\u0026amp;quot; 1.2 查询地址列表 查看 meta 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/META/node/query\u0026amp;quot; 查看 data 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/DATA/node/query\u0026amp;quot; 查看 session 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/SESSION/node/query\u0026amp;quot; 2. registry-data 2.1 查询数据 查看 pub 数量：\ncurl \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/datum/count\u0026amp;quot; 根据客户端的 ip\u0026amp;amp;port 查询其发布的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;\u0026amp;quot;:\u0026amp;quot;\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;}\u0026#39; 3. registry-session 3.1 查询数据 根据客户端的 ip\u0026amp;amp;port 查询其发布的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/pub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]\u0026#39; 根据客户端的 ip\u0026amp;amp;port 查询其订阅的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/sub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]\u0026#39; 3.2 断开客户端链接：clientOff 根据客户端的 ip\u0026amp;amp;port 强制删除其所有 sub\u0026amp;amp;pub 数据（但不会断开连接）：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/api/clients/off\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;connectIds\u0026amp;quot;: [\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]}\u0026#39; ","date":-62135596800,"description":"","dir":"projects/sofa-registry/management-api/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2cf59ac422c84c279d73c1f7f1cd0902","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/management-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/management-api/","summary":"1. registry-meta 1.1 推送开关 在注册中心新版本发布的过程中为了把对业务的影响减少到最小，避免服务端重启动引发大规模服务地址信息变更产生大量推送，我们提供运维","tags":null,"title":"运维命令","type":"projects","url":"/sofastack.tech/projects/sofa-registry/management-api/","wordcount":554},{"author":null,"categories":null,"content":"SOFARPC 支持不同的通信协议，目前支持 Bolt, RESTful 和 Dubbo，详细的事情请参考各个协议对应的文档： * Bolt 协议 * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化协议 * 自定义线程池 * RESTful * 基本使用 * 自定义 Filter * 集成 Swagger * Dubbo * 基本使用 * H2C * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/protocol/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"18f51cb12f7a0384a71ab22349292a08","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/protocol/","summary":"SOFARPC 支持不同的通信协议，目前支持 Bolt, RESTful 和 Dubbo，详细的事情请参考各个协议对应的文档： * Bolt 协议 * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化","tags":null,"title":"通信协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/protocol/","wordcount":109},{"author":null,"categories":null,"content":" 1. 环境准备 要使用 SOFARegistry，需要先准备好基础环境，SOFARegistry 依赖以下环境：\n Linux/Unix/Mac JDK8 需要采用 Apache Maven 3.2.5 或者以上的版本来编译 2. 资源配额 cpu: 4c memory: 8G disk: 50G 3. 两种部署模式 集成部署模式 将 meta/data/session 三个角色打包集成在一个 jvm 里运行，可单机或集群部署，部署简单。 独立部署模式 将 meta/data/session 三个角色分开部署，每个角色都可以单机或集群部署，可根据实际情况为每个角色部署不同的数量。 生产环境建议使用这种部署模式。 4. 配置参数 SOFARegistry 的部署，依赖于一些公共参数\n properties environment 默认值 作用 nodes.localDataCenter x DefaultDataCenter 集群名，多个注册中心公用同一个数据库用到 nodes.localRegion x DEFAULT_ZONE 逻辑 region, 创建多组 session jdbc.url JDBC_URL 必填 数据库地址 jdbc.username JDBC_USERNAME 必填 数据库用户名 jdbc.password JDBC_PASSWORD 必填 数据库密码 properties 可以写在 registry-all/conf/application.properties 中， kubernetes 下部署也可以使用 configmap 进行文件挂载\n5. 打包 jar release 页面 下载最新的 registry-all.tgz 包\ntar -zxvf registry-all.tgz cd registry-all 或者从源码打包\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Pserver-release -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all image image 托管于 https://hub.docker.com/r/sofaregistry/sofaregistry\n或者从源码 build: 修改 Makefile 中 image 的 repository\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true make image_build make image_push 6. 集成部署模式 集成部署模式，是将 meta/data/session 三个角色打包集成在一个 JVM 里运行，可单机或集群部署, 不建议大规模使用\n6.1 jar 单机部署 集成部署的单机部署模式可以直接参考快速开始-服务端部署部分。\n6.2 jar 集群部署 解压 registry-all.tgz，并修改配置文件 集群部署，即搭建 2 台以上的集群，建议至少使用 3 台（注意：目前不支持在同一台机器部署多个 SOFARegistry，因此您必须有 3 台不同的机器）。在每一台机器上的部署方法同上：\ncp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all 区别是每台机器在部署时需要修改 registry-all/conf/application.properties 配置, 组成同一个注册中心的多台机器需要配置相同的数据库和nodes.localDataCenter\nnodes.localDataCenter=DefaultDataCenter nodes.localRegion=DEFAULT_ZONE jdbc.url = jdbc:mysql://127.0.0.1:3306/registrymetadb?useUnicode=true\u0026amp;amp;characterEncoding=utf8 jdbc.username = root jdbc.password = root 启动 registry-integration 每台机器都修改以上配置文件后，按照“单机部署”的步骤去启动 registry-integration 即可。 sh bin/integration/start.sh\n6.3 docker 集群部署 客户端和 SOFARegistry 需要同一个三层网络内，因此利用 docker 部署需要使用 host network 可以通过配置文件挂载的方式进行部署，也可以通过环境变量传递的方式 同时需要添加 REGISTRY_APP_NAME=integration 进入集成模式，在一个 jvm 里启动 3 个角色\nimage 中， registry-all.tgz 的解压地址在 registry-distribution/registry-all, 配置需要挂载到正确的目录\ndocker run -e REGISTRY_APP_NAME=integration \\ --name=sofa-registry --rm --net=host \\ -v $PWD/conf/:/registry-distribution/registry-all/conf/ \\ -e JDBC_URL=jdbc:mysql://172.17.0.1:3306/registrymetadb -e JDBC_USERNAME=root -e JDBC_PASSWORD=root sofaregistry/sofaregistry:6.1.4 7. 独立部署模式 独立部署模式，是将 meta/data/session 三个角色分开部署，每个角色都可以单机或集群部署，可根据实际情况为每个角色部署不同的数量，生产环境推荐使用这种部署模式。\n以下介绍 332 模式（即 3 台 meta + 3 台 data + 2 台 session）的部署步骤。\n7.1 jar 集群部署 解压 registry-all.tgz，并修改配置文件 集群部署，即搭建 2 台以上的集群，建议至少使用 3 台（注意：目前不支持在同一台机器部署多个 SOFARegistry，因此您必须有 3 台不同的机器）。在每一台机器上的部署方法同上： cp …","date":-62135596800,"description":"","dir":"projects/sofa-registry/deployment/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7e28583bc38be66af8d704d7fbcd9dd4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/deployment/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/deployment/","summary":"1. 环境准备 要使用 SOFARegistry，需要先准备好基础环境，SOFARegistry 依赖以下环境： Linux/Unix/Mac JDK8 需要采用 Apache Maven 3.2.5 或者以上的版本来编译","tags":null,"title":"部署","type":"projects","url":"/sofastack.tech/projects/sofa-registry/deployment/","wordcount":1558},{"author":null,"categories":null,"content":" MOSN 的配置文件可以分为以下四大部分：\n Servers 配置，目前仅支持最多 1 个 Server 的配置，Server 中包含一些基础配置以及对应的 Listener 配置 ClusterManager 配置，包含 MOSN 的 Upstream 详细信息 对接控制平面（Pilot）的 xDS 相关配置 其他配置 Trace、Metrics、Debug、Admin API 相关配置 扩展配置，提供自定义配置扩展需求 配置文件概览\nMOSN 的基本配置部分如下所示：\n{ \u0026amp;quot;servers\u0026amp;quot;: [], \u0026amp;quot;cluster_manager\u0026amp;quot;: {}, \u0026amp;quot;dynamic_resources\u0026amp;quot;: {}, \u0026amp;quot;static_resources\u0026amp;quot;: {}, \u0026amp;quot;admin\u0026amp;quot;:{}, \u0026amp;quot;pprof\u0026amp;quot;:{}, \u0026amp;quot;tracing\u0026amp;quot;:{}, \u0026amp;quot;metrics\u0026amp;quot;:{} } 配置类型 MOSN 的配置包括以下几种类型：\n 静态配置 动态配置 混合模式 静态配置 静态配置是指 MOSN 启动时，不对接控制平面 Pilot 的配置，用于一些相对固定的简单场景（如 MOSN 的示例）。 使用静态配置启动的 MOSN，也可以通过扩展代码，调用动态更新配置的接口实现动态修改。 静态配置启动时必须包含一个 Server 以及至少一个 Cluster。 动态配置 动态配置是指 MOSN 启动时，只有访问控制平面相关的配置，没有 MOSN 运行时所需要的配置。\n 使用动态配置启动的 MOSN，会向管控面请求获取运行时所需要的配置，管控面也可能在运行时推送更新 MOSN 运行配置。\n 动态配置启动时必须包含 DynamicResources 和 StaticResources 配置。\n 混合模式 MOSN 启动时的配置可以同时包含静态模式与动态模式，以混合模式启动的 MOSN 会先以静态配置完成初始化，随后可能由控制平面获取配置更新。\n配置示例 静态配置示例 动态配置的示例如下所示。\n{ \u0026amp;quot;servers\u0026amp;quot;: [ { \u0026amp;quot;default_log_path\u0026amp;quot;: \u0026amp;quot;/home/admin/logs/mosn/default.log\u0026amp;quot;, \u0026amp;quot;default_log_level\u0026amp;quot;: \u0026amp;quot;DEBUG\u0026amp;quot;, \u0026amp;quot;processor\u0026amp;quot;: 4, \u0026amp;quot;listeners\u0026amp;quot;: [ { \u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;0.0.0.0:12220\u0026amp;quot;, \u0026amp;quot;bind_port\u0026amp;quot;: true, \u0026amp;quot;filter_chains\u0026amp;quot;: [ { \u0026amp;quot;filters\u0026amp;quot;: [ { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;proxy\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;downstream_protocol\u0026amp;quot;: \u0026amp;quot;SofaRpc\u0026amp;quot;, \u0026amp;quot;upstream_protocol\u0026amp;quot;: \u0026amp;quot;SofaRpc\u0026amp;quot;, \u0026amp;quot;router_config_name\u0026amp;quot;: \u0026amp;quot;test_router\u0026amp;quot; } }, { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;connection_manager\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;router_config_name\u0026amp;quot;: \u0026amp;quot;test_router\u0026amp;quot;, \u0026amp;quot;virtual_hosts\u0026amp;quot;: [] } } ] } ] } ] } ], \u0026amp;quot;cluster_manager\u0026amp;quot;: { \u0026amp;quot;clusters\u0026amp;quot;: [ { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;example\u0026amp;quot;, \u0026amp;quot;lb_type\u0026amp;quot;: \u0026amp;quot;LB_ROUNDROBIN\u0026amp;quot;, \u0026amp;quot;hosts\u0026amp;quot;: [ {\u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;127.0.0.1:12200\u0026amp;quot;} ] } ] } } 动态配置示例 静态配置的示例如下所示。\n{ \u0026amp;quot;dynamic_resources\u0026amp;quot;: { \u0026amp;quot;ads_config\u0026amp;quot;: { \u0026amp;quot;api_type\u0026amp;quot;: \u0026amp;quot;GRPC\u0026amp;quot;, \u0026amp;quot;grpc_services\u0026amp;quot;: [ { \u0026amp;quot;envoy_grpc\u0026amp;quot;: {\u0026amp;quot;cluster_name\u0026amp;quot;: \u0026amp;quot;xds-grpc\u0026amp;quot;} } ] } } }, \u0026amp;quot;static_resources\u0026amp;quot;: { \u0026amp;quot;clusters\u0026amp;quot;: [ { \u0026amp;quot;name\u0026amp;quot;: \u0026amp;quot;xds-grpc\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;STRICT_DNS\u0026amp;quot;, \u0026amp;quot;connect_timeout\u0026amp;quot;: \u0026amp;quot;10s\u0026amp;quot;, \u0026amp;quot;lb_policy\u0026amp;quot;: \u0026amp;quot;ROUND_ROBIN\u0026amp;quot;, \u0026amp;quot;hosts\u0026amp;quot;: [ { \u0026amp;quot;socket_address\u0026amp;quot;: {\u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;pilot\u0026amp;quot;, \u0026amp;quot;port_value\u0026amp;quot;: 15010} } ], \u0026amp;quot;upstream_connection_options\u0026amp;quot;: { \u0026amp;quot;tcp_keepalive\u0026amp;quot;: { \u0026amp;quot;keepalive_time\u0026amp;quot;: 300 } }, \u0026amp;quot;http2_protocol_options\u0026amp;quot;: { } } ] } } ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/overview/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0aa65950d2c24e8ce86d265bea275e2a","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/configuration/overview/","summary":"MOSN 的配置文件可以分为以下四大部分： Servers 配置，目前仅支持最多 1 个 Server 的配置，Server 中包含一些基础配置以及对应的 Listener 配置 ClusterManager 配置，包含 MOSN 的 Upstream 详细信","tags":null,"title":"配置概览","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/overview/","wordcount":663},{"author":null,"categories":null,"content":" 目前 SOFATracer 提供了两种采样模式，一种是基于 BitSet 实现的基于固定采样率的采样模式；另外一种是提供给用户自定义实现采样的采样模式。下面通过案例来演示如何使用。\n本示例基于 tracer-sample-with-springmvc 工程；除 application.properties 之外，其他均相同。\n基于固定采样率的采样模式 在 application.properties 中增加采样相关配置项 #采样率 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #采样模式类型名称 com.alipay.sofa.tracer.samplerName=PercentageBasedSampler 验证方式 当采样率设置为100时，每次都会打印摘要日志。 当采样率设置为0时，不打印 当采样率设置为0~100之间时，按概率打印 以请求 10 次来验证下结果。\n1、当采样率设置为100时，每次都会打印摘要日志\n启动工程，浏览器中输入：http://localhost:8080/springmvc ；并且刷新地址10次，查看日志如下：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:47.643\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173568757510019269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:68,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:50.980\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569097710029269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:51.542\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569153910049269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-4\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:52.061\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569205910069269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:2,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-6\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/sampler/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"48856a040da01abc84213934c1c5fce4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/sampler/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/sampler/","summary":"目前 SOFATracer 提供了两种采样模式，一种是基于 BitSet 实现的基于固定采样率的采样模式；另外一种是提供给用户自定义实现采样的采样模式。下面通过案例来演示如何使","tags":null,"title":"采样模式","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/sampler/","wordcount":719},{"author":null,"categories":null,"content":" 链路数据透传 链路数据透传功能支持应用向调用上下文中存放数据，达到整个链路上的应用都可以操作该数据。 使用方式如下，可分别向链路的 request 和 response 中放入数据进行透传，并可获取到链路中相应的数据。\nRpcInvokeContext.getContext().putRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;,\u0026amp;quot;value_request\u0026amp;quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;,\u0026amp;quot;value_response\u0026amp;quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;); 使用示例 例如 A -\u0026amp;gt; B -\u0026amp;gt; C 的场景中，将 A 设置的请求隐式传参数据传递给 B 和 C。在返回的时候，将 C 和 B 的响应隐式传参数据传递给 A。\nA 请求方设置的时候：\n// 调用前设置请求透传的值 RpcInvokeContext context = RpcInvokeContext.getContext(); context.putRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;, \u0026amp;quot;a2bbb\u0026amp;quot;); // 调用 String result = service.hello(); // 拿到结果透传的值 context.getResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;); B 业务代码中：\npublic String hello() { // 拿到请求透传的值 RpcInvokeContext context = RpcInvokeContext.getContext(); String reqBaggage = context.getRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;); // doSomthing(); // 结果透传一个值 context.putResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;, \u0026amp;quot;b2aaa\u0026amp;quot;); return result; } 如果中途自己启动了子线程，则需要设置子线程的上下文：\nCountDownLatch latch = new CountDownLatch(1); final RpcInvokeContext parentContext = RpcInvokeContext.peekContext(); Thread thread = new Thread(new Runnable(){ public void run(){ try { RpcInvokeContext.setContext(parentContext); // 调一个远程服务 xxxService.sayHello(); latch.countDown(); } finally { RpcInvokeContext.removeContext(); } } }, \u0026amp;quot;new-thread\u0026amp;quot;); thread.start(); // 此时拿不到返回值透传的数据的 latch.await(); //等待 // 此时返回结束，能拿到返回透传的值 和 SOFATracer 的比较 SOFATracer 是蚂蚁开源的一个分布式链路追踪系统,RPC 目前已经和 Tracer 做了集成,默认开启. 和 Tracer 进行数据传递不同的是\n RPC的数据透传更偏向业务使用,而且可以在全链路中进行双向传递,调用方可以传给服务方,服务方也可以传递信息给调用方,SOFATracer 更加偏向于中间件和业务无感知的数据的传递,只能进行单向传递. RPC的透传可以选择性地不在全链路中透传,而Tracer 中如果传递大量信息,会在整个链路中传递.可能对下游业务会有影响. 所以整体来看,两个信息各有利弊,在有一些和业务相关的透传数据的情况下,可以选择 RPC 的透传.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-chain-pass-data/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"96cfb41f07a6a2ad979b53093ff5eee9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","summary":"链路数据透传 链路数据透传功能支持应用向调用上下文中存放数据，达到整个链路上的应用都可以操作该数据。 使用方式如下，可分别向链路的 request 和 response 中放入数","tags":null,"title":"链路数据透传","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","wordcount":606},{"author":null,"categories":null,"content":"默认 SOFARPC 已经集成了 SOFATracer，用户也可以使用其他的 APM 产品，如 Skywalking来实现相应的功能。详见文档：\n SOFATracer Skywalking 如果想要关闭 SOFARPC 的链路追踪能力的话，在使用了 rpc-sofa-boot-starter 的情况下，可以在 application.properties 配置文件中配置 com.alipay.sofa.rpc.defaultTracer=。\n在直接使用 sofa-rpc-all 的情况下，可以在 main 函数里面加上如下的代码来关闭 SOFARPC 的链路追踪的能力（在发布任何 SOFARPC 的服务或者引用任何 SOFARPC 的服务之前）：\nRpcConfigs.putValue(RpcOptions.DEFAULT_TRACER, \u0026amp;quot;\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/tracing-usage/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5f944f87d827ae060fb0528f6715af97","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/tracing-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/tracing-usage/","summary":"默认 SOFARPC 已经集成了 SOFATracer，用户也可以使用其他的 APM 产品，如 Skywalking来实现相应的功能。详见文档： SOFATracer Skywalking 如果想要关闭 SOFARPC 的链路","tags":null,"title":"链路追踪","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/tracing-usage/","wordcount":197},{"author":null,"categories":null,"content":" 从 rpc-sofa-boot-starter 6.0.1 版本开始，SOFARPC 提供了 RESTful 服务和 Swagger 的一键集成的能力。\n在使用了 rpc-sofa-boot-starter 的情况下，如果想要开启 swagger 的能力，首先需要在 pom.xml 中增加 Swagger 的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 里面增加 com.alipay.sofa.rpc.restSwagger=true。\n最后，访问 http://localhost:8341/swagger/openapi 就可以拿到 SOFARPC 的 RESTful 的 Swagger OpenAPI 内容。\n如果没有使用 rpc-sofa-boot-starter 或者在 rpc-sofa-boot-starter 的版本低于 6.0.1，可以采用如下的方式集成 Swagger。\n首先，需要在应用中引入 Swagger 相关的依赖，由于 SOFARPC 的 RESTful 协议走的是 JAXRS 标准，因此我们引入 Swagger 的 JAXRS 依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 上面引入 Guava 的 20.0 的版本是为了解决 Guava 的版本冲突。\n增加一个 Swagger 的 RESTful 服务 为了能够让 Swagger 将 SOFARPC 的 RESTful 的服务通过 Swagger OpenAPI 暴露出去，我们可以反过来用 SOFARPC 的 RESTful 的服务提供 Swagger 的 OpenAPI 服务。首先，需要新建一个接口：\n@Path(\u0026amp;quot;swagger\u0026amp;quot;) public interface OpenApiService { @GET @Path(\u0026amp;quot;openapi\u0026amp;quot;) @Produces(\u0026amp;quot;application/json\u0026amp;quot;) String openApi(); } 然后提供一个实现类，并且发布成 SOFARPC 的 RESTful 的服务：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}, interfaceType = OpenApiService.class) public class OpenApiServiceImpl implements OpenApiService, InitializingBean { private OpenAPI openAPI; @Override public String openApi() { return Json.pretty(openAPI); } @Override public void afterPropertiesSet() { List\u0026amp;lt;Package\u0026amp;gt; resources = new ArrayList\u0026amp;lt;\u0026amp;gt;(); resources.add(this.getClass().getPackage()); // 扫描当前类所在的 Package，也可以扫描其他的 SOFARPC RESTful 服务接口所在的 Package if (!resources.isEmpty()) { // init context try { SwaggerConfiguration oasConfig = new SwaggerConfiguration() .resourcePackages(resources.stream().map(Package::getName).collect(Collectors.toSet())); OpenApiContext oac = new JaxrsOpenApiContextBuilder() .openApiConfiguration(oasConfig) .buildContext(true); openAPI = oac.read(); } catch (OpenApiConfigurationException e) { throw new RuntimeException(e.getMessage(), e); } } } } 这样，应用启动后，访问 http://localhost:8341/swagger/openapi 即可得到当前的应用发布的所有的 RESTful 的服务的信息。\n解决跨域问题 如果用户在另外一个端口中启动了一个 Swagger UI，并且希望通过 Swagger UI 来访问 http://localhost:8341/swagger/openapi 查看 API 定义，发起调用，那么可能需要解决访问跨域的问题，要解决 SOFARPC RESTful 服务访问跨域的问题，可以在应用启动前增加如下的代码：\nimport org.jboss.resteasy.plugins.interceptors.CorsFilter; public static void main(String[] args) { CorsFilter corsFilter = new CorsFilter(); corsFilter.getAllowedOrigins().add(\u0026amp;quot;*\u0026amp;quot;); …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-swagger/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d068767fe0dd2922eecef69736684be8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-swagger/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-swagger/","summary":"从 rpc-sofa-boot-starter 6.0.1 版本开始，SOFARPC 提供了 RESTful 服务和 Swagger 的一键集成的能力。 在使用了 rpc-sofa-boot-starter 的情况下，如果想要开启 swagger 的能力，首先需要在 pom.xml 中增加 Swagger 的依赖： \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.swagger.core.v3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;swagger-jaxrs2\u0026lt;/artifactId\u0026gt;","tags":null,"title":"集成 SOFARPC RESTful 服务和 Swagger","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-swagger/","wordcount":646},{"author":null,"categories":null,"content":" 服务发布 服务发布过程涉及到三个类 RegistryConfig ，ServerConfig ，ProviderConfig 。\n1. RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;) RegistryConfig 表示注册中心。如上声明了服务注册中心的地址和端口是127.0.0.1:2181，协议是 Zookeeper。\n2. ServerConfig\nServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ServerConfig 表示服务运行容器。如上声明了一个使用8803端口和 bolt 协议的 server 。\n3. ProviderConfig\nProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt;() .setInterfaceId(HelloWorldService.class.getName()) .setRef(new HelloWorldServiceImpl()) .setServer(serverConfig) .setRegistry(registryConfig); providerConfig.export(); ProviderConfig 表示服务发布。如上声明了服务的接口，实现和该服务运行的 server 。 最终通过 export 方法将这个服务发布出去了。\n服务引用 服务引用涉及到两个类， RegistryConfig 和 ConsumerConfig 。\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig); HelloService helloService = consumerConfig.refer(); ConsumerConfig 表示服务引用，如上声明了所引用服务的接口和服务注册中心。 最终通过 refer 方法将这个服务引用，获取到该服务的远程调用的代理。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-rpc/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ee6f74a4974c7abf72322cef108d5ef0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-rpc/","summary":"服务发布 服务发布过程涉及到三个类 RegistryConfig ，ServerConfig ，ProviderConfig 。 1. RegistryConfig RegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026quot;zookeeper\u0026quot;) .setAddress(\u0026quot;127.0.0.1:2181\u0026quot;) RegistryConfig 表示注册中心。如上声明了服务","tags":null,"title":"非 Spring 环境 API 使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-rpc/","wordcount":300},{"author":null,"categories":null,"content":"预热权重功能让客户端机器能够根据服务端的相应权重进行流量的分发。该功能也常被用于集群内少数机器的启动场景。利用流量权重功能在短时间内对服务端机器进行预热，然后再接收正常的流量比重。 运行机制如下： 1.服务端服务在启动时会将自身的预热时间，预热期内权重，预热完成后的正常权重推送给服务注册中心。如上图 ServiceB 指向 Service Registry 。\n2.客户端在引用服务的时候会获得每个服务实例的预热权重信息。如上图 Service Registry 指向 client 。\n3.客户端在进行调用的时候会根据服务所在地址的预热时期所对应的权重进行流量分发。如上图 client 指向 ServiceA 和 ServiceB 。 ServiceA 预热完毕，权重默认 100 ， ServiceB 处于预热期，权重为 10，因此所承受流量分别为 100%110 和 10%110 。\n该功能使用方式如下。\nProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt;() .setWeight(100) .setParameter(ProviderInfoAttrs.ATTR_WARMUP_WEIGHT,\u0026amp;quot;10\u0026amp;quot;) .setParameter(ProviderInfoAttrs.ATTR_WARM_UP_END_TIME,\u0026amp;quot;12000\u0026amp;quot;); 如上，该服务的预热期为12s，在预热期内权重为10，预热期结束后的正常权重为100。如果该服务一共发布在两个机器A,B上，A机器正处于预热期内，并使用上述配置，B已经完成预热，正常权重为200。那么客户端在调用的时候，此时流量分发的比重为10：200，A机器预热结束后，流量分发比重为100：200。 在SOFABoot中，如下配置预热时间，预热期间权重和预热完后的权重即可。\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleRestFacadeReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.endpoint.facade.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs weight=\u0026amp;quot;100\u0026amp;quot; warm-up-time=\u0026amp;quot;10000\u0026amp;quot; warm-up-weight=\u0026amp;quot;1000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/provider-warmup-weight/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b9e320dfaa4f9700ecdca67d76e07d54","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","summary":"预热权重功能让客户端机器能够根据服务端的相应权重进行流量的分发。该功能也常被用于集群内少数机器的启动场景。利用流量权重功能在短时间内对服务端","tags":null,"title":"预热权重","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","wordcount":497}] \ No newline at end of file +[{"author":null,"categories":["SOFAStack"],"content":" \nSOFAStack™ (Scalable Open Financial Architecture Stack) is a collection of cloud native middleware components, which are designed to build distributed systems with high performance and reliability, and have been fully validated by mission-critical financial business scenarios.\nLinks Home Page: https://www.sofastack.tech\nSource Code: https://github.com/sofastack\nProjects SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, log space isolation and asynchronous initialization of bean. SOFARPC is a high-performance, high-extensibility, production-level Java RPC framework. SOFAMesh SOFAMesh is a large-scale implementation solution for Service Mesh which is improved and extended based on Istio. SOFAMosn SOFAMosn(Modular Observable Smart Network) is a powerful proxy acting as Service Mesh\u0026amp;rsquo;s data plane written in Go. SOFATracer SOFATracer is a distributed link tracing system based onOpenTracing specification. SOFALookout SOFALookout is a lightweight and open source middleware service that solves the metrics and monitoring issues of the system. SOFABolt SOFABolt is a network communication framework implemented based on Netty. SOFAArk SOFAArk is a light-weight, java based classloader isolation framework. SOFAJarslink Is a dynamic modules and merged deployments solution based on SOFAArk. SOFAActs ACTS (AntCoreTest) is a white-box testing framework that is based on the accumulation of testing practices for financial-grade distributed architectures. SOFAJraft SOFAJRaft is a production-grade, high-performance Java implementation based on the RAFT consensus algorithm. SOFARegistry SOFARegistry is a production ready, high efficient, highly available service registry. SOFADashboard Is a one-stop console of SOFAStack. More projects in: github/sofastack\nCommunity Github\n WeChat\n Official Account：Antfin_SOFA is a technology exchange platform dedicated to building first-class distributed technologies in financial scenario applications, focusing on the most cutting-edge, reference-oriented technical solutions and implementation routes in the financial technology industry. WeChat Groups：We have ten groups and more than four thousand developers, Add ant-techfin02 as your friend, and reply SOFA will invite to joining into the group. DingTalk\n DingTalk Group:\n 「SOFAStack 1」 No: 23127468 Group is Full\n 「SOFAStack 2」 No: 23195297 Group is Full\n 「SOFAStack 3」 No: 23390449 Group is Full\n 「SOFAStack 4」 No: 23372465 Group is Full\n 「SOFAStack 5」 No: 30315793\n DingTalk Group:「SOFAStack Online service」, If you have used any SOFAStack related components in a production environment, please let us know, and we will invite you to join this group for faster communication and more efficient use of problem support online. Weibo\n SegmentFault\n juejin.im\n ","date":1524135415,"description":"Say hello to SOFAStack!","dir":"blog/hello-sofastack/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"26e249e6b2d0e482eb4404b76dabaec4","permalink":"https://sofastack.github.io/sofastack.tech/en/blog/hello-sofastack/","publishdate":"2018-04-19T11:56:55+01:00","readingtime":2,"relpermalink":"/sofastack.tech/en/blog/hello-sofastack/","summary":"SOFAStack™ (Scalable Open Financial Architecture Stack) is a collection of cloud native middleware components, which are designed to build distributed systems with high performance and reliability, and have been fully validated by mission-critical financial business scenarios.\nLinks Home Page: https://www.sofastack.tech\nSource Code: https://github.com/sofastack\nProjects SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, log space isolation and asynchronous initialization of bean.","tags":["SOFAStack"],"title":"Hello SOFAStack!","type":"blog","url":"/sofastack.tech/en/blog/hello-sofastack/","wordcount":383},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFA 六周年，Hello SOFA World！\n 活动时间：04 月 20 日 13:30\u0026amp;ndash;18:00\n 活动形式：线下 Meetup + 线上直播\n 资料下载：\n Apache Seata(incubating) 新征程\n探索微服务下一站，Koupleless 模块化研发框架与运维调度系统\n开源：除了代码之外还需要做哪些事？\n厚积薄发 - MOSN 社区开启新征程\nSOFABoot - 新一代研发框架\nEnvoy 网关基于 MOE 架构的落地与实践\n介绍 2024 年 4 月 20 日，\nSOFAStack 社区在上海 S 空间与社区小伙伴一起庆祝的第 6 个生日。\n大家一起进入到「SOFA 世界」\n非正式会议+室内露营的活动形式\n让 SOFAer 的技术交流更为轻松自在，现场的开源技术探索氛围十分浓厚。\n现场回顾 点击👉 云相册 进行查看\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 王特（花名：亦夏），Apache Seata(incubating) 社区 PPMC\n 赵真灵（花名：有济），Koupleless 社区负责人\n 马振军（花名：古今），Layotto 社区负责人\n 朱德江（花名：人德），MOSN 开源负责人\n 胡子杰（花名：致节），SOFABoot 社区 PMC\n 杜鑫，中国电子云技术专家、MOSN 社区开发者\n 议程 了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1713596400,"description":"2024 年 4 月 20 日，我们在上海一起庆祝了 SOFA 社区的六岁生日。","dir":"activities/sofa-6th-anniversary/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5711a60fad8f2916fe1fd7bbd9f07242","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-6th-anniversary/","publishdate":"2024-04-20T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-6th-anniversary/","summary":"概要 活动主题：SOFA 六周年，Hello SOFA World！ 活动时间：04 月 20 日 13:30\u0026ndash;18:00 活动形式：线下 Meetup + 线上直播 资料下载： Apache Seata(incubating) 新征程 探索微服务下一站，","tags":["SOFAStack","开源六周年"],"title":"SOFA 六周年，Hello SOFA World","type":"activities","url":"/sofastack.tech/activities/sofa-6th-anniversary/","wordcount":497},{"author":"呈铭","categories":"SOFAStack","content":" 王程铭（呈铭）\n蚂蚁集团技术工程师，Apache Committer\n专注 RPC、Service Mesh 和云原生等领域。\n本文 7368 字，预计阅读 15 分钟\n前言 MOSN（Modular Open Smart Network）是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并经过了双十一大促几十万容器的生产级验证。\nMOSN 为服务提供多协议、模块化、智能化、安全的代理能力，融合了大量云原生通用组件，同时也可以集成 Envoy 作为网络库，具备高性能、易扩展的特点。MOSN 可以和 Istio 集成构建 Service Mesh，也可以作为独立的四、七层负载均衡，API Gateway、云原生 Ingress 等使用。\nMOSN 作为数据面，整体由 NET/IO、Protocol、Stream、Proxy 四个层次组成，其中：\n NET/IO 用于底层的字节流传输\n Protocol 用于协议的 decode/encode\n Stream 用于封装请求和响应，在一个 conn 上做连接复用\n Proxy 做 downstream 和 upstream 之间 stream 的转发\n 那么 MOSN 是如何工作的呢？下图展示的是使用 Sidecar 方式部署运行 MOSN 的示意图，服务和 MOSN 分别部署在同机部署的 Pod 上， 您可以在配置文件中设置 MOSN 的上游和下游协议，协议可以在 HTTP、HTTP2.0 以及 SOFARPC 等中选择。\n以上内容来自官网 https://mosn.io\nRPC 场景下 MOSN 的工作机制 RPC 场景下，MOSN 的工作机制示意图如下：\n我们简单理解一下上面这张图的意义：\n Server 端 MOSN 会将自身 ingress 的协议端口写入到注册中心；\n Client 端 MOSN 会从注册中心订阅地址列表，第一次订阅也会返回全量地址列表，端口号是 Server 端 ingress 绑定的端口号；\n 注册中心会实时推送地址列表变更到 Client 端（全量）；\n Client 端发起 rpc 调用时，请求会被 SDK 打到本地 Client 端 MOSN 的 egress 端口上；\n Client 端 MOSN 将 RPC 请求通过网络转发，将流量通过负载均衡转发到某一台 Server 端 MOSN 的 ingress 端口处理；\n 最终到了 Server 端 ingress listener，会转发给本地 Server 应用；\n 最终会根据原来的 TCP 链路返回。\n 全局视野下的 MOSN 工作流程 现在我们已经了解了 MOSN 的工作机制，那么 MOSN 作为 MESH 的数据面，是怎么进行流量拦截并且将响应原路返回的呢？\n为了方便大家理解，我将以上时序图内容进行拆分，我们一一攻破。\n3.1 建立连接 MOSN 在启动期间，会暴露本地 egress 端口接收 Client 的请求。MOSN 会开启 2 个协程，分别死循环去对 TCP 进行读取和写处理。MOSN 会通过读协程获取到请求字节流，进入 MOSN 的协议层处理。\n// 代码路径 mosn.io/mosn/pkg/network/connection.go func (c *connection) Start(lctx context.Context) { // udp downstream connection do not use read/write loop if c.network == \u0026amp;quot;udp\u0026amp;quot; \u0026amp;amp;\u0026amp;amp; c.rawConnection.RemoteAddr() == nil { return } c.startOnce.Do(func() { // UseNetpollMode = false if UseNetpollMode { c.attachEventLoop(lctx) } else { // 启动读/写循环 c.startRWLoop(lctx) } }) } func (c *connection) startRWLoop(lctx context.Context) { // 标记读循环已经启动 c.internalLoopStarted = true utils.GoWithRecover(func() { // 开始读操作 c.startReadLoop() }, func(r interface{}) { c.Close(api.NoFlush, api.LocalClose) }) // 省略。。。 } 3.2 Protocol 处理 Protocol 作为多协议引擎层，对数据包进行检测，并使用对应协议做 decode/encode 处理。MOSN 会循环解码，一旦收到完整的报文就会创建与其关联的 xstream，用于保持 tcp 连接用于后续响应。\n// 代码路径 mosn.io/mosn/pkg/stream/xprotocol/conn.go func (sc *streamConn) Dispatch(buf types.IoBuffer) { // decode frames for { // 协议 decode，比如 dubbo、bolt 协议等 frame, err := sc.protocol.Decode(streamCtx, buf) if frame != nil { // 创建和请求 frame 关联的 xstream，用于保持 tcp 连接用于后续响应 sc.handleFrame(streamCtx, xframe) } } } func (sc *streamConn) handleFrame(ctx context.Context, frame api.XFrame) { switch frame.GetStreamType() { case api.Request: // 创建和请求 frame 关联的 xstream，用于保持 tcp 连接用于后续响应，之后进入 proxy 层 sc.handleRequest(ctx, frame, false) } } func (sc *streamConn) handleRequest(ctx context.Context, frame api.XFrame, oneway bool) { // 创建和请求 frame 关联的 xstream serverStream := sc.newServerStream(ctx, frame) // 进入 proxy 层并创建 downstream serverStream.receiver = sc.serverCallbacks.NewStreamDetect(serverStream.ctx, sender, span) serverStream.receiver.OnReceive(serverStream.ctx, frame.GetHeader(), frame.GetData(), nil) } 3.3 Proxy …","date":1711436400,"description":"从一次 RPC 请求，探索 MOSN 的工作流程","dir":"blog/explore-the-workflow-of-mosn-from-an-rpc-request/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9993f1cea8de40427d6ef6d8345f9d0c","permalink":"https://sofastack.github.io/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","publishdate":"2024-03-26T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","summary":"王程铭（呈铭） 蚂蚁集团技术工程师，Apache Committer 专注 RPC、Service Mesh 和云原生等领域。 本文 7368 字，预计阅读 15 分钟 前言 MOSN（Modul","tags":["SOFAStack"],"title":"从一次 RPC 请求，探索 MOSN 的工作流程","type":"blog","url":"/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","wordcount":2760},{"author":null,"categories":"SOFAStack","content":" 梁栎鹏（立蓬）\n蚂蚁集团技术工程师,云原生领域工程师\n就职于蚂蚁集团中间件团队，参与维护与建设蚂蚁 SOFAArk 和 Koupleless 开源项目，参与内部 SOFAServerless 产品的研发和实践。\n本文 4603 字，预计阅读 10 分钟\nbackground-你的企业应用协作效率低吗？ 明明只改一行，但代码编译加部署要十分钟？\n多人开发一套代码库，调试却频频遇到资源抢占和相互覆盖，需求上线也因此相互等待？\n当项目代码逐渐膨胀，业务逐渐发展，代码耦合、发布耦合以及资源耦合的问题日益加重，开发效率一降再降。\n如何解决？来试试把单个 Spring Boot 应用拆分为多个 Spring Boot 应用吧！拆出后，多个 Spring Boot 应用并行开发，互不干扰。在 Koupleless 模式下，业务可以将 Spring Boot 应用拆分成一个基座和多个 Koupleless 模块（Koupleless 模块也是 Spring Boot 应用）。\n🙌拉到「Koupleless 拆分插件解决方案」部分，可直接查看单体应用拆分的插件演示视频！\n关键挑战 从单个 Spring Boot 应用拆出多个 Spring Boot 应用有三大关键挑战：\n一是拆子应用前，复杂单体应用中代码耦合高、依赖关系复杂、项目结构复杂，难以分析各文件间的耦合性，更难从中拆出子应用，因此需要解决拆分前复杂单体应用中的文件依赖分析问题。\n二是拆子应用时，拆出操作繁琐、耗时长、用户需要一边分析依赖关系、一边拆出，对用户要求极高，因此需要降低拆分时用户交互成本。\n三是拆子应用后，单体应用演进为多应用共存，其编码模式会发生改变。Bean 调用方式由单应用调用演进为跨应用调用，特殊的多应用编码模式也需根据框架文档调整，比如在 Koupleless 中，为了减少模块的数据源连接，模块会按照某种方式使用基座的数据源，其学习成本与调整成本极高，因此需要解决拆分后多应用编码模式演进问题。\nKoupleless 拆分插件解决方案 针对以上三大关键挑战，Koupleless IntelliJ IDEA 插件将解决方案分为 3 个部分：分析、交互和自动化拆出，提供依赖分析、友好交互和自动化拆出能力，如下图：\n在分析中，分析项目中的依赖关系，包括类依赖和 Bean 依赖分析，解决拆分前复杂单体应用中的文件依赖分析问题；\n在交互中，可视化类文件之间的依赖关系，帮助用户梳理关系。同时，可视化模块目录结构，让用户以拖拽的方式决定要拆分的模块文件，降低拆分时的用户交互成本；\n在自动化拆出中，插件将构建模块，并根据特殊的多应用编码修改代码，解决拆分后多应用编码模式演进问题。\n🙌 Koupleless 半自动拆分演示视频，带你更直观了解插件如何在分析、交互、自动化拆出中提供帮助。\n一个示例，秒懂 Koupleless 解决方案优势 假设某业务需要将与 system 相关的代码都拆出到模块，让通用能力保留在基座。这里我们以 system 的入口服务 QuartzJobController 为例。\n步骤一：分析项目文件依赖关系 首先，我们会分析 QuartzJobController 依赖了哪些类和 Bean。\n 方式一：使用 Idea 专业版，对 Controller 做 Bean 分析和类分析，得到以下 Bean 依赖图和类依赖关系图 优势：借助 IDEA 专业版，分析全面\n劣势：需要对每个类文件都做一次分析，Bean 依赖图可读性不强。\n 方式二：凭借脑力分析 当 A 类依赖了B、C、D、\u0026amp;hellip;、N类，在拆出时需要分析每一个类有没有被其它类依赖，能不能够拆出到模块应用。\n优势：直观\n劣势：当 A 的依赖类众多，需要层层脑力递归。\n 方式三：使用 Koupleless 辅助工具，轻松分析！ 选择你想要分析的任意类文件，点击“分析依赖”，插件帮你分析～ 不仅帮你分析类文件依赖的类和 Bean，还提示你哪些类可以拆出，哪些类不能拆出。\n以 QuartzJobController 为例，当选定的模块中有 QuartzJobController, QuartzJobService 和 QuartzJobServiceImpl 时，QuartzJobController 依赖的类和 Bean 关系如下图所示：\nQuartzJobController 的依赖类/Bean 分为四类：已在模块、可移入模块、建议分析被依赖关系和不建议移入模块：\n 如果在模块中，则被标记为绿色“已在模块”，如：QuartzJobService 和 QuartzJobServiceImpl；\n 如果只被模块类依赖，那么被标记为蓝色“可移入模块”，如 JobQueryCriteria；\n 如果只被一个非模块类依赖，那么被标记为黄色“建议分析被依赖关系”，如 QuartLog；\n 如果被大量非模块类依赖，那么被标记为红色“不建议移入模块”，如 BadRequestException。\n 当使用插件对 QuartzJobController 和 JobQueryCriteria 进行分析时，依赖树和被依赖树如下，与上述分析对应：\n优势：直观、操作便捷、提示友好\n劣势：插件只支持分析常见的 Bean 定义和类引用\n步骤二：拆出到模块\u0026amp;amp;修改单应用编码为多应用编码模式\n选择相关的类文件拆出到模块。\n 方式一：复制粘贴每个文件、脑力分析所有模块基座之间的 Bean 调用、根据多应用编码模式修改代码。 在拆出时不可避免会面临这些问题：刚拆到哪儿了？这文件在没在模块里？我要不要重构这些包名？Bean 调用跨应用吗？多应用编码的文档在哪？\n优势：可以处理插件无法处理的多应用编码模式\n劣势：用户不仅需要分析跨应用 Bean 依赖关系，还需要学习多应用编码方式，人工成本较高。\n 方式二：使用 Koupleless 辅助工具，轻松拆出！ 根据你想要的模块目录结构，拖拽需要拆出的文件至面板。点击“拆出”，插件帮你分析，帮你根据 Koupleless 多应用编码模式修改～\n优势：直观、交互方便、插件自动修改跨应用 Bean 调用方式和部分特殊的多应用编码模式\n劣势：插件只能根据部分多应用编码模式修改代码，因此用户需要了解插件能力的范围\n技术方案 在上文中我们已经知道，插件将整体流程分为 3 个阶段：分析阶段、交互阶段和自动化拆出阶段，整体流程如下图所示：\n 在分析阶段中，分析项目中的依赖关系，包括类依赖、Bean 依赖和特殊的多应用编码分析，如：MyBatis 配置依赖；\n 在交互阶段，可视化类文件之间的依赖关系和模块目录结构；\n 在自动化拆出阶段，插件首先将构建模块并整合配置，然后根据用户需要重构包名，接着修改模块基座 Bean 调用方式，并根据特殊的多应用编码修改代码，如：自动复用基座数据源。\n 接下来，我们将分别简单介绍分析阶段、交互阶段和自动化拆出阶段中用到的主要技术。\n分析阶段 插件分别使用 JavaParser 和 commons-configuration2 扫描项目中的 Java 文件和配置文件。\n类依赖分析 为了准确地分析出项目的类依赖关系，插件需要完整分 …","date":1710831600,"description":"单体应用协作开发太难？Koupleless 带来拆分插件，帮你抽丝剥茧提高协作开发效率！","dir":"blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"31cd46eb078e59933c6f2c5cf7b32bc8","permalink":"https://sofastack.github.io/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","publishdate":"2024-03-19T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","summary":"梁栎鹏（立蓬） 蚂蚁集团技术工程师,云原生领域工程师 就职于蚂蚁集团中间件团队，参与维护与建设蚂蚁 SOFAArk 和 Koupleless 开源项目，参与内部 SOFAServerless 产品的研发和实践。 本","tags":["SOFAStack"],"title":"单体应用协作开发太难？Koupleless 带来拆分插件，帮你抽丝剥茧提高协作开发效率！","type":"blog","url":"/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","wordcount":3944},{"author":null,"categories":"SOFAStack","content":" 文｜祁晓波\n南京爱福路汽车科技基础设施负责人\n主要研究微服务、可观测、稳定性、研发效能、Java 中间件等领域。\n本文 4812 字 阅读 12 分钟\nKoupleless *（原 SOFAServerless）* 自 2023 年开源以来已经落地了若干企业，这些企业也见证了从 SOFAServerless 到 Koupleless 的品牌\u0026amp;amp;技术能力迭代升级。随着 Koupleless 1.0 的重磅发布，一些企业已经在内部取得了不错的效果，例如南京爱福路汽车科技有限公司。\n南京爱福路汽车科技有限公司和大多数科技企业一样，在企业生产开发过程遇到了微服务的一些问题，例如资源成本过高、启动慢等问题。在看到 Koupleless 项目正不断开源出实实在在的能力和案例，在解决很实际的微服务痛点问题，决定采用 Koupleless 进行尝试，并随着 Koupleless 一路走来，已经将 6 个应用合并成 1 个应用大幅降低资源成本，取得了不错的效果。\n1｜背景 南京爱福路汽车科技有限公司 *（以下简称爱福路）* 作为行业 top 的汽车后市场解决方案提供商，为维修门店提供智慧管理系统、为行业提供维修应用大数据，致力于成为汽车后市场数智化构建者。\n随着其服务的企业增多，爱福路也越来越多地接触到了各类体量的企业。\n这就对爱福路的服务提供形式提出了较多不同的诉求： 除了单纯的公有云 SAAS 之外，还包括私有化部署等解决方案的诉求。\n2｜问题提出 我们知道，随着微服务和云原生技术的普及，应用数量急剧膨胀。\n如此多的应用也带来了比较大的成本问题。\n爱福路在为海量公域客户提供服务的时候，更关注稳定、弹性。\n但是在为某个客户提供独立部署方案时，爱福路发现如此多的服务在部署到 K8s 时所带来的服务器成本非常高 *（通常来说，独立部署服务面向的客户群体比之公域客户少了 1-2 个数量级）*，而单个客户也很难有足够的预算负担整个部署方案。这就大大阻塞了爱福路后续持续拓展私有化部署客户的进度。\n举个例子：一个应用在进行 K8s 交付时，最少会提供两个副本；而大量这样的 Java 应用存在对于整体的集群利用率不高，继而造成较高的成本。\n因此爱福路面临着如下的课题： 当进行私有化交付时，如何能够更便捷地、低成本地交付我们现有的产物？\n其中，低成本至少应该包含如下几个角度：\n 既存代码的低成本改造； 新的交付方式低成本的维护； 运行产物低成本的 IT 成本。 3｜问题探索和推导 爱福路基于当前的微服务架构和云原生方式进行了思考和探索： 是否到了爱福路微服务架构进一步升级的时候了？\n在当前整体降本增效的大环境趋势中，在保持服务稳定的前提下对于服务器有更加极致的使用。\n从业务视角来看，服务单店的整体服务器成本越低，爱福路的竞争力就越强。\n那么，有没有可能在保持 Java 的生态环境下，低成本的同时能够保证爱福路继续享受云原生的红利？爱福路做了如下推导：\n通过上述的推导，爱福路判断也许「模块化+Serverless」将是一种解法。\n因此一款来自蚂蚁的开源框架成为他们重点的关注，那就是 Koupleless。（阅读原文可跳转官网地址：https://koupleless.io/user-cases/ant-group/）\n当然一个重要原因是蚂蚁开源一直做得不错，社区也比较活跃。除了社区群和 GitHub 之外，PMC 有济也积极地建立了独享的 VIP 群进行专门对接。\n4｜Koupleless（原 SOFAServerless） Koupleless 技术体系是在业务发展、研发运维的复杂性和成本不断增加的情况下，蚂蚁集团为帮助应用又快又稳地迭代而决定研发，从细化研发运维粒度和屏蔽基础设施的角度出发，演进出的一套低成本接入的「模块化+Serverless」解决方案。\n核心方式是通过类隔离和热部署技术，将应用从代码结构和开发者阵型拆分为两个层次：业务模块和基座，基座为业务模块提供计算环境并屏蔽基础设施，模块开发者不感知机器、容量、中间件等基础设施，专注于业务研发帮助业务快速向前发展。\n合并部署降成本 在企业中， “80%” 的长尾应用仅服务 “20%” 的流量，蚂蚁集团也不例外。\n在蚂蚁集团存在大量长尾应用，每个长尾应用至少需要 预发布、灰度、生产 3 个环境，每个环境最少需要部署 3 个机房，每个机房又必须保持 2 台机器高可用，因此大量长尾应用 CPU 使用率不足 10%。\n通过使用 Koupleless，蚂蚁集团对长尾应用进行了服务器裁撤，借助类委托隔离、资源监控、日志监控等技术，在保证稳定性的前提下，实现了多应用的合并部署，极大降低了业务的运维成本和资源成本。\n此外，采用这种模式，小应用可以不走应用申请上线流程，也不需要申请机器，可以直接部署到业务通用基座之上，从而帮助小流量业务实现了快速创新。\n2023 年底 SOFAServerless 品牌全新升级为 Koupleless（GitHub页面：https://github.com/koupleless/koupleless）。\n企业里不同业务有不同的发展阶段，因此应用也拥有自己的生命周期。\n  * 初创期：一个初创的应用一般会先采用单体架构。 * 增长期：随着业务增长，应用开发者也随之增加。此时您可能不确定业务的未来前景，也不希望过早把业务拆分成多个应用以避免不必要的维护、治理和资源成本，那么您可以用 Koupleless 低成本地将应用拆分为一个基座和多个功能模块，不同功能模块之间可以并行研发运维独立迭代，从而提高应用在此阶段的研发协作和需求交付效率。 * 成熟期：随着业务进一步增长，您可以使用 Koupleless 低成本地将部分或全部功能模块拆分成独立应用去研发运维。 * 长尾期：部分业务在经历增长期或者成熟期后，也可能慢慢步入到低活状态或者长尾状态，此时您可以用 Koupleless 低成本地将这些应用一键改回模块，合并部署到一起实现降本增效。\n 应用生命周期演进\n可以看到 Koupleless 主要通过将应用模块化来降低整个服务的运行成本，更值得称道的是支持模块和应用的来回切换，可以更低成本地接入，支持平滑演进。\n5｜架构适配尝试 Spring Boot 1「可行性确认」 爱福路的存量应用中，九成使用的是 Spring Boot 1，RPC 主要依赖 Dubbo 2.6。这点和社区是有一定出入的，社区仅仅支持 SpringBoot 2。\n为此爱福路需要尝试对于 Spring Boot 1 的支持，也因此提出了相应的 issue👇\nhttps://github.com/sofastack/sofa-ark/issues/268\n通过和社区沟通协调确认，爱福路发现只是社区没能够完全覆盖到这块，企业自身可以通过部分扩展进行支持。\n当时社区同学认为这个是比较重要的变更，可以进一步覆盖更多的社区用户，为此还特地调整了中央仓库的发版频次：加速 review、加速发 snapshot。\n正是这些细节让爱福路更加信任 Koupleless 团队👍，也坚定了此次方案能够实际落地的信心。\n应用合并 当 Spring Boot 1 得到支持之后，爱福路可以快速地将原来的 …","date":1709017200,"description":"高效降本｜深度案例解读 Koupleless 在南京爱福路的落地实践","dir":"blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0c6483ccd63328d158a35bc8b5b81940","permalink":"https://sofastack.github.io/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","publishdate":"2024-02-27T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","summary":"文｜祁晓波 南京爱福路汽车科技基础设施负责人 主要研究微服务、可观测、稳定性、研发效能、Java 中间件等领域。 本文 4812 字 阅读 12 分钟 Koupleless *（原 SOFA","tags":["SOFAStack"],"title":"高效降本｜深度案例解读 Koupleless 在南京爱福路的落地实践","type":"blog","url":"/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","wordcount":3555},{"author":null,"categories":"SOFAStack","content":" 如果你是企业经营者，在为企业降本增效而发愁； 如果你是企业的开发、运维或架构同学，在日常工作中被开发效率、交付问题等困扰…… 欢迎来了解 Koupleless *（原 SOFAServerless）*！\n现在，Koupleless 重磅发布了1.0 版本！（👈点击查看 release note）\n那么，Koupleless 是什么？又将如何为你解决以上问题？除了以上这几种情境，Koupleless 还有哪些能力呢？欢迎你来社区探索发现。\nKoupleless 是什么？ Koupleless 由 SOFAServerless 品牌升级而来，是一款模块化研发框架与运维调度平台。它从应用架构角度出发，帮助应用解决从需求、到研发、到交付再到运维的全生命周期痛点问题。其最核心的架构图如下👇。如果想了解更详细的原理介绍也可以查看官网页面：https://koupleless.gitee.io/docs/introduction/architecture/arch-principle/。\n它能帮助解决的问题包括：\n 应用拆分过度，机器成本和长期维护成本高； 应用拆分不够，多人协作互相阻塞； 应用构建、启动与部署耗时久，应用迭代效率不高； SDK 版本碎片化严重，升级成本高周期长； 平台、中台搭建成本高，业务资产沉淀与架构约束困难； 微服务链路过长，调用性能不高； 微服务拆分、演进成本高； 如果你也被以上问题所困扰，那么欢迎来了解 Koupleless 给出的解决方案。 本模式在蚂蚁集团内部历经 4-5 年时间孵化而成，当前已经帮助 70W 核业务量完成 10 倍级降本增效，可以帮助应用做到秒级启动，只占 20M 内存。\n性能对比示例如下图👇。\n根据我们的模块化应用架构模型，可以看到我们是将传统应用从纵向和横向切分演变而来的。\n所以我们将 SOFAServerless 进行品牌升级成为 Koupleless，取自 Couple + less，寓意通过对应用进行拆分解耦，实现更好的职责分工，帮助业务降本增效。\n我们为什么开源？ 关注应用架构领域的同学，应该知道微服务很好地解决了组织分布式协作难题，但同时也带来了一些问题，并且这些问题正日益获得更多关注。 有人说，2023 年是微服务的转折年[1]，其中一些科技巨头*（如 Amazon 和 Google ）*已经开始尝试去解决和完善微服务带来的问题，例如 service weaver[2]，amazon prime video[3]的架构改造，甚至直接回归单体。\n而蚂蚁内部在 4-5 年前就开始着手解决微服务问题，并为此打造了 Koupleless 应用研发模式。 根据蚂蚁这些年的实践经验，我们相信模块化架构是一种有潜力的架构，真正能够较好地解决微服务问题；我们也希望通过模块化架构给行业内部提供一种新的解决方案，帮助更多企业降本增效。\n开源提供了哪些能力？ 自 2023 年下半年开源以来，经过这半年时间和社区的共同努力，我们已经开放了内部完整的能力，包括研发工具、框架、运维调度平台等；也沉淀了一些常用组件最佳实践和 samples 用例（具体查看 release note：https://github.com/koupleless/koupleless/releases/tag/v1.0.0）。 具备了线上接入使用的能力，一些企业也已经可以按照官网和文档自主接入使用了。\n 研发工具 Arkctl一键构建、部署和发布模块，方便用于本地开发测试验证。 Arklet、SOFAArk 和 Runtime 组件为多种研发框架如 Spring Boot、SOFABoot、Dubbo 提供多模块运行容器环境，适配 30+ 组件，沉淀 25+ samples 用例。 控制面组件 ModuleControllerModuleDeployment，提供模块发布与运维能力； ModuleScheduler，提供模块基础调度能力； ModuleScaler，提供模块扩缩容能力。 有了这些组件之后，从开发验证 -\u0026amp;gt; 交付上线 -\u0026amp;gt; 日常运维全流程的基本能力已经具备，1.0 版本实现生产可用级别。\n挑战与亮点 这套模式最大的挑战来自于将多个应用或代码片段合并在一起，在隔离与共享上如何找到最佳的平衡点，使得在存量应用低成本接入的同时，能享受到隔离的带来稳定可靠的好处，也能享受到共享的高性能、低资源消耗的收益。\n隔离可以确保运行时的稳定可靠，但带来了性能的下降、资源利用率的损失；共享提升了性能和资源利用率，但也带来了运行时的一些问题，例如 static 变量可能带来互相影响的问题。我们采用了模块化技术来解决这类问题。在 Java 领域模块化技术并不是我们首创的，20 年前就有了 OSGl 技术，那为什么我们的模块化技术能在蚂蚁内部规模化落地呢？我们是做了哪些工作来解决存量应用低成本接入和共享后的一些问题的呢？\n要解决这类问题，我们并没有太多可参考的行业案例，相当于是在无人区里摸索，除了解决隔离与共享的核心问题外，还要解决配套设施的建设、用户心智的培养等，这些都需要一个笃定的心力和持续的过程，这些问题就是这套模式的挑战所在。 好在最终，我们拨云见日探索了出来。我们在隔离和共享之间找到了一个最佳的平衡点，并且能让存量业务低成本的接入，这也是我们最自豪的地方。我们在蚂蚁集团用事实证明了模块化技术并不是停留在设计稿里的技术，或者小部分人才能使用的技术，它的问题和挑战并不可怕，是有固定模式的，可以通过工具和流程逐步治理、收敛的，现在将此模式进行开源分享，是希望可以帮助其他企业少走弯路，和社区一起把这套模式心智在行业里树立起来。\nKoupleless 已接入 15+ 企业 当前在统计内的，有 15+ 企业在使用 Koupleless 接入线上或者用于交付，还有 17+ 企业正在试用或者接入中，还有一些因为信息缺失未统计到的。详细企业接入列表可以查看官网信息[4]。 很高兴 Koupleless 能帮助到他们，也十分欢迎这些企业探索的更多使用场景，也欢迎更多企业开发者一起参与社区建设，推广这套技术。\nKoupleless 未来的规划 我们希望能让模块化架构成为应用架构领域里的新模式，并能在行业里推广开来。这不仅是我们作为技术人的技术追求，也是我们做开源的持续动力来源。 当前我们虽然发布了 1.0 版本，但开源工作才只是刚刚开始，还有更多规划。比如，我们希望未来能把模块化技术做得更加完善，将我们想要做到的效果完整地提供出来：\nSpeed as you need, Pay as you need， Deploy as you need， Evolve as you need 。 需要的能力包括支持各种框架、运行时组件、中间件服务，还有非常多相关的配套设施；也希望这套模式能在更多语言里发挥出效果，例如 Go 语言，以此和更多的小伙伴们一起探索出微服务领域的下一站。\n这里感谢所有参与贡献 Koupleless 1.0 的 51 位开发者： @QilingZhang @lvjing2 @glmapper @yuanyuancin @lylingzhen @yuanyuan2021 …","date":1707202800,"description":"成倍降本增效，提升企业竞争力！SOFAServerless 品牌升级为 Koupleless，重磅发布 1.0 版本","dir":"blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bf0d878bbdb545204ab25a89a7c592ac","permalink":"https://sofastack.github.io/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","publishdate":"2024-02-06T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","summary":"如果你是企业经营者，在为企业降本增效而发愁； 如果你是企业的开发、运维或架构同学，在日常工作中被开发效率、交付问题等困扰…… 欢迎来了解 Koupleless *（原","tags":["SOFAStack"],"title":"成倍降本增效，提升企业竞争力！SOFAServerless 品牌升级为 Koupleless，重磅发布 1.0 版本","type":"blog","url":"/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","wordcount":2620},{"author":null,"categories":"SOFAStack","content":" 今天 SOFAStack 邀请到了开源之夏 2023 Layotto 社区的中选学生陈亦昺同学！在本项目中，他负责可插拔式组件的开发。希望他分享的这段经历，能让更多人了解到 Layotto 开源社区，感受开源的魅力～\n项目链接：https://summer-ospp.ac.cn/org/prodetail/23f080194?list=org\u0026amp;amp;navpage=org\n项目名称 Layotto support pluggable components\n项目导师 王文学\n项目背景描述 Layotto 是一款基于云原生的应用运行时，旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，比如状态管理、配置管理、事件发布订阅等能力，以简化应用的开发。同时，它以 MOSN 项目为底座，在提供分布式能力以外，还提供了 Service Mesh 的流量管控能力。\nLayotto 对用户程序暴露 API，用户程序可以通过 API 调度对应的运行时服务。例如 Layotto 支持 config 服务，其内部会使用含有各种 component (如 Nacos，Apollo，Etcd 等) 的 SDK 来提供 config API 能力。\n当前 Layotto 的 component 都是实现在 Layotto 的工程里面的。这也就使得用户在想要使用新的 component 时，必须使用 Golang 语言开发，同时必须在 Layotto 工程中实现，再进行统一编译。这种体验对于多语言用户来说非常不友好。\n因此 Layotto 需要提供 pluggable components 的能力，允许用户通过任何语言实现自己的 component，而 Layotto 则通过 gRPC 协议和外部的 component 进行通信。\n项目实现思路 方案 基于 UDS（Unix Domain Socket）实现本地跨语言组件服务发现，降低通信开销。\n 基于 proto 实现组件跨语言实现能力。\n 数据流架构 组件发现 如上图所示，用户自定义组件启动 socket 服务，并将 socket 文件放到指定目录中。Layotto 启动时，会读取该目录中的所有 socket 文件（跳过文件夹），并建立 socket 连接。\n目前，Layotto 向 Dapr 对齐，不负责用户组件的生命周期。这就意味着在服务期间，用户组件下线后不会进行重连，则该组件服务无法使用。后面会根据社区使用情况，来决定 Layotto 是否需要支持进程管理模块，或是使用一个单独的服务来管理。\n由于 Windows 对于 UDS 的支持还不是很完善，且 Layotto 本身取消了对 Windows 的兼容，所以新特性采用的 UDS 发现模式未对 Windows 系统做兼容。\n组件注册 如上面的数据流架构图所示，用户注册的组件需要实现 pluggable proto 定义的 gRPC 服务。Layotto 会根据 gRPC 接口，实现 Go interface 接口，这里对应于数据流图中的 wrapper component。wrapper component 与 built-in component 对 Layotto Runtime 来说没有任何区别，用户也不会有特殊的感知。\nLayotto 通过 gRPC reflect 库，获取到用户提供服务实现了哪些组件，然后注册到全局的组件注册中心，以供用户使用。\n开源之夏个人随访 自我介绍 大家好，我是陈亦昺，目前就读于杭州电子科技大学，大三学生。自从大二开始，我对开源产生了浓厚的兴趣，特别是在云原生和微服务领域。\n起初，我主要为我个人感兴趣的项目提供使用案例和文档支持，随后逐渐开始贡献一些简单的功能。例如，我为 Kratos 贡献了一个简单的 toml 配置文件解析器，并向 go-zero 提供了一些建议，改进了它的优雅关闭（Graceful Shutdown）功能。\n之后，我接触到了服务网格领域，认识了 MOSN 社区，并开始为其中的子项目 Layotto 做开源贡献：我修复了一些 makefile 脚本使用中的 bug、编写了 Go SDK 的使用文档、并尝试对 Nacos 组件进行封装。\n申请本社区项目的原因 SOFAStack 是一个金融级的云原生架构，内部孵化了许多吸引我的微服务项目。接触 SOFAStack 社区以来，我发现他们对开源贡献十分重视，仓库中有丰富的文档来帮助用户了解项目的背景、功能、代码模块等。\n👉SOFAStack 仓库地址：https://github.com/sofastack\nMOSN 项目也组织过源码阅读活动，将 MOSN 核心组件的代码设计整理成文档；仓库所有者也会为新人提供适合入手的 issue 作为开始。所以在 OSPP 活动开始之前，我其实就先认识了 SOFAStack 社区，并对其新兴项目 Layotto 做了一定的贡献。OSPP 开始后，我很快与导师取得联系，并得知可以参考 Layotto 对标项目 Dapr 的设计实现。于是，我翻阅了 Dapr 的相关文档、该功能实现时的 issues，阅读了该块功能的源码，最终得出适合移植到 Layotto 的方案。\n如何克服项目过程中的困难与挑战？ 在项目开发的初期阶段，导师会引导我了解项目的愿景、业务背景和代码结构；当我在开发过程中遇到困难时，导师为我提供了很多实质性的建议和改进方向；此外，社区每周三定期举行社区会议，让我们可以同步项目开发进度、讨论遇到的问题，共同寻求解决方案。\n在开发过程中我其实遇到了不少问题，其中一个让我印象深刻的是 Go 依赖冲突问题。早期，Layotto 参考了 Dapr 的一些组件接口设计，并直接引入了 Dapr 仓库的代码，这样直接复用了 Dapr 组件的功能，也避免了重复劳动。但是早期的 Dapr 并没有实现可插拔组件的功能，为了让新功能与 Dapr 组件保持兼容，我必须将 Dapr 升级到能够实现该功能的版本。\n然而，这两个版本之间存在许多不兼容的变化（尽管对外提供的服务接口并没有改变），所以一旦我升级了依赖，Layotto 就会出现大量错误。最终在与导师的沟通中，我们一致认为这部分兼容性工作的收益不大，只需实现新的接口供用户使用即可。\n你眼中的社区印象 SOFAStack 是一个充满开源精神的、热情的社区，欢迎并鼓励学生和开源爱好者积极参与其中。同时，SOFAStack 社区也是专业的，它专注于云原生和金融领域的技术创新和解决方案，旨在帮助开发者快速构建和管理云原生应用，提高应用的可伸缩性、弹性以及可靠性。\n一些收获 参加这次开源之夏项目使我获益匪浅。我对云原生有了进一步的深刻理解，并在实际业务操作中积累了宝贵的经验。同时，参加这个活动还扩展了我的知识技能，激发了我对开源项目做出贡献的热情。\n通过与导师和社区的合作，我学会了如何与其他开发者协作、如何提出和解决问题，并且还掌握了使用开源工具和资源的技巧。通过阅读 Layotto 和 Dapr 的源代码，我掌握了许多关于程序设计的经验，例如编写可测试的代码、命名规范、如何构建单元测试用例等等。这 …","date":1700550000,"description":"开源之夏经验分享｜Layotto 社区 陈亦昺：保持热情、全力以赴！","dir":"blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e50c0aaf2bd1fc9a639cb47390aa1839","permalink":"https://sofastack.github.io/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","publishdate":"2023-11-21T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","summary":"今天 SOFAStack 邀请到了开源之夏 2023 Layotto 社区的中选学生陈亦昺同学！在本项目中，他负责可插拔式组件的开发。希望他分享的这段经历，能让更多人了解到 Layotto 开源社区，","tags":["SOFAStack"],"title":"开源之夏经验分享｜Layotto 社区 陈亦昺：保持热情、全力以赴！","type":"blog","url":"/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","wordcount":2488},{"author":null,"categories":"SOFAStack","content":" 北京时间 2023 年 10 月 29 日，分布式事务开源项目 Seata 通过 Apache 基金会的投票决议，以全票通过的优秀表现正式成为 Apache 孵化器项目！\n根据 Apache基金会邮件列表显示，包含 13 个约束性投票（binding votes）和 6 个无约束性投票（non-binding votes）的投票全部持赞同意见，无弃权票和反对票，投票顺利通过。\n“Welcome Seata to the ASF incubator.”\n项目历史 早在 2007 年\n蚂蚁集团和阿里巴巴就在内部开发了分布式事务中间件，用于解决电商、支付、物流等业务场景中应用数据的一致性问题。内部项目分别被称为 XTS（eXtended Transaction Service）/TXC（Taobao Transaction Constructor），该项目几乎在每笔订单的交易支付链路几乎都有使用。\n自 2013 年以来\n蚂蚁集团在金融云上向企业客户发布了分布式事务云服务产品 DTX（Distributed Transaction-eXtended），阿里巴巴在阿里云上发布 GTS（global transaction service），两者均在各个行业领域积累了大量用户。\n2019 年 1 月\n阿里巴巴集团正式开源了该项目，项目命名为 Fescar（Fast \u0026amp;amp; Easy Commit and Rollback）。项目开源以来，它受到了众多开发人员的热烈欢迎和赞扬，开源一周收获了超 3k star，曾一度蝉联 GitHub Trending 排行榜第一。\n2019 年 4 月\n蚂蚁集团数据中间件团队加入了 Fescar 社区。为了创建一个更加开放和中立的社区，Fescar 改名为 Seata（Simple Extensible Autonomous Transaction Architecture），代码仓库从 Alibaba organization 迁移到其独立的 Seata organization。\n2019 年 12 月\nSeata 开源项目正式发布 1.0.0 GA 版本，标志着项目已基本可生产使用。\n2023 年 10 月\n为了更好地通过社区驱动技术的演进，蚂蚁集团和阿里巴巴携手，正式将 Seata 捐赠给 Apache 基金会，提案通过了 Apache 基金会的投票决议。\n项目现状 Seata 开源 4 年来，主项目在 GitHub 累计收获 star 超 24k，累计发布版本超 40 次，参与代码贡献人数超 300 人。\n Seata 被各领域企业/组织广泛应用于解决分布式事务问题，在 GitHub「Used by」拥有超过 3.1k 的仓库依赖，金融领域企业纷纷试点使用。\n Seata 对于市面上主流的关系数据库、RPC 框架做了广泛的支持，同时被许多第三方社区做了主动和被动集成。\n 项目特性 提供 AT、TCC、Saga 和 XA 事务模式，支持事务模式的混用，以满足不同业务场景的数据一致性需求。\n 提供 Java、Golang 等多语言 SDK 支持。\n 支持了 Apache Dubbo、Spring Cloud Alibaba、gRPC、Motan、SOFARPC、HttpClient 等服务调用框架。\n 提供了 MySQL、MariaDB、Oracle、PostgreSQL、OceanBase、TiDB、SQLServer、PolarDB、Dameng 等关系数据库无侵入 AT 事务模式的支持。\n 支持基于多种关系数据库、Redis 存储的存算分离的集群模式，支持基于 Raft 的存算不分离集群模式，满足不同运维场景下的集群高可用需求。\n 支持了市面上主流的注册中心和配置中心。\n 提供了丰富的插件化扩展机制，支持用户自定义 SDK 侧 30 多个扩展点。\n 致谢 感谢所有曾经参与到社区建设中来的贡献者。\n特别感谢愿意为 Seata 提供指导的 Champion 和 Mentors:\nChampion：\nSheng Wu（wusheng @apache.org）\nMentors：\nSheng Wu(wusheng @apache.org）\nJustin Mclean(justin @classsoftware.com）\nHuxing Zhang(huxing @apache.org）\nHeng Du(duhengforever @apache.org）\n我们坚信，将 Seata 引入 ASF 可以推动开源社区向着更强大、更多元化发展。我们将努力践行 Apache Way，同时欢迎更多的公司和个人加入到开发队伍中来，让 Seata 社区更加健康、茁壮地成长，让更多人享受开源带来的技术红利！\n项目寄语 四年前，我们秉持开源开放的理念，在社区写下了第一行代码。回顾过去四年，Seata 开源社区的技术演进和社区运营就像一次创业旅程。这四年我们取得了不菲的成绩，Seata 的出现快速占领了开发者的心智，成为了分布式事务领域的事实标准，在理论实践中我们牵头推动了行业标准的建立。Seata 捐赠给 ASF 是我们迈向更多元化社区治理和全球化发展的重要里程碑。\n\u0026amp;ndash; 季敏（Seata 开源社区创始人）\n恭喜 Seata 全票通过进入 Apache 孵化器！2019 年，蚂蚁集团和阿里集团携手一起开源了分布式事务框架 Seata，各自贡献了内部分布式事务的最佳实践。经过了四年的发展，Seata 早已成为一个被社区广泛认可的分布式事务项目，大量的贡献者在 Seata 里面贡献代码，丰富了 Seata 的各种功能，很多用户在自己的环境中使用 Seata，给 Seata 带来了大量的实践落地案例。Seata 进入 Apache 孵化器不是终点，而是新的起点，期待 Seata 后面能够持续按照 The Apache Way 的方式运作，以更加中立的姿态，吸引更多的贡献者和用户，走向更加宽阔的未来。\n\u0026amp;ndash; 黄挺（蚂蚁集团中间件负责人）\n非常高兴 Seata 这个阿里和蚂蚁合作多年的开源项目进入 Apache 基金会进行孵化，相信 Apache Way 会帮助项目更加社区化、服务更多人，也期待 Apache 的 Seata 能为社区带来更多微小而美好的改变。对于蚂蚁开源来说，Seata 进入 Apache 孵化也是一个重要的里程碑，希望未来有更多蚂蚁团队发起的项目能走上 Apache 之路。\n\u0026amp;ndash; 王旭（蚂蚁开源技术委员会副主席）\n分布式事务是微服务架构最复杂，技术水位最深的部分。阿里\u0026amp;amp;蚂蚁在开源捐献之前申请了数十个专利，开源之后在社区推动下高速发展，吸收 70%+外部开发者，大幅降低分布式的复杂度，扩展了分布式事务的生态；未来随着微服务高速发展，随着数据一致性要求越来越高，相信分布式事务会发挥越来越大的作用！\n\u0026amp;ndash;李艳林（阿里云微服务团队负责人）\nSeata 是一款由阿里巴巴和蚂蚁集团共同参与开发的分布式事务解决方案，广泛应用于两家公司的内部系统。它的突出特点在于高性能和简单易用，为微服务架构下的分布式事务处理提供了高效且可靠的解 …","date":1700118000,"description":"携手开源，共同见证｜Seata 进入 Apache 孵化器","dir":"blog/open-source-together-seata-enters-apache-incubator/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bc69512b849467987dfe2349cb824154","permalink":"https://sofastack.github.io/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","publishdate":"2023-11-16T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","summary":"北京时间 2023 年 10 月 29 日，分布式事务开源项目 Seata 通过 Apache 基金会的投票决议，以全票通过的优秀表现正式成为 Apache 孵化器项目！ 根据 Apache基金会邮件列表显","tags":["SOFAStack"],"title":"携手开源，共同见证｜Seata 进入 Apache 孵化器","type":"blog","url":"/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","wordcount":4740},{"author":null,"categories":"SOFAStack","content":" 文｜王连平（花名：烨川)\n蚂蚁集团容器团队专家\n本文 3441 字 阅读 9 分钟\n技术背景 Kubernetes 是容器编排的标杆平台，其标准化、插件化特性促使其拥有巨大的生态体系。众所周知，Kubernetes 是由其众多管控组件共同驱动容器交付的，但这种特性可会给开发人员和 SRE 在开发和运维过程中带来更高复杂性。\n当容器在交付过程出现错误，通常会使用 Kubectl 命令行工具查看 Pod 相关的事件，进而查看相关组件的日志定位具体的错误。这种方式存在效率低、信息少的缺点，导致问题排查耗时耗力。另外，容器在交付过程中会经历诸多阶段，比如调度、IP 分配、挂卷、容器创建和启动等，当此过程变得很慢时，需要精准定位到哪里是瓶颈点，最直接的方法是在所有管控组件做埋点，然后逐阶段分析问题。这种埋点方式带来了巨大的工作量，不易推进实施。\n针对这些问题，蚂蚁集团围绕 Kubernetes 平台构建了一套综合的容器观测服务——Lunettes。它利用 Kubernetes 多维度的交付信息（例如 API Server 请求、Audit 审计）构建了一套容器交付全生命周期观测服务，可以跟踪和诊断容器交付过程，并且基于诊断能力提供容器交付 SLI/SLO 服务，实现了数字化方式监控和管理 Kubernetes 容器服务。\n整体方案 在 Kubernetes 系统中，大量的管控组件在容器交付的过程中分工协作，为交付出来一个正常运行的容器不断的重试调和，过程中会产出大量的中间请求动作、日志等信息，Kubernetes 系统这种异步终态特性是容器交付可观测服务的一个关键挑战。那么在此类系统中观测容器交付过程，应该具备哪些特性呢？\n我们希望 Lunettes 应该具备：\n 提供多维度的容器交付信息，并且能优雅处理面向终态的机制\n 提供便捷的组件接入方式，尽可能小的侵入组件代码\n 提供较灵活的定制化或者配置方式\n 给用户提供简单易用的交互接口\n Lunettes 基于上述特性的考虑，整体采用旁路数据采集、数据分析和数据服务思路，围绕 Kubernetes 的审计日志做容器交付相关业务的分析，包括 Pod 基本信息、Pod 交付关键生命周期、Pod 交付诊断、Pod 交付跟踪和 Pod 交付 SLO 共 5 部分的交付数据。在数据分析链路上抽象出多个通用的模型，让用户灵活定制容器交付 Trace 及 SLO 诊断能力。同时，向上提供了 OpenAPI 和 Grafana UI 两种用户交互接口，便于用户信息消费。\n系统架构 上图示意了 Lunettes 系统的系统架构和数据链路，除了 Kubernetes API Server 审计数据源、数据采集和数据存储组件外，Lunettes 整体包括用户接口层和数据处理层两部分，其中数据处理层是 Lunettes 的核心业务逻辑所在。其处理流程如下：\n 从数据流向看，Filebeat 从 Kubernetes API Server 采集审计日志后，存储到 Elastic Search 中，在审计采集过程中使用 Filebeat Processor 进行冗余信息过滤，在数据存储 Elastic Search 时使用 Pipeline 增加必要时间序列，如此使得存储到 ES 中的数据量小而丰富。\n Lunettes 会近实时从 ES 拉取审计数据，审计进入 Lunettes 后首先会被 Share Processor 处理，这里处理主要分为 Pod 元数据信息提取、超事件（HyperEvent）抽象、以及并发反序列化审计请求中的 Raw Data，前置反序列化是为了减少后续 SLO、Trace 等业务处理时重复处理，提升性能。\n 数据经过 Share Processor之后，进入核心的交付分析模块，核心包括交付生命周期 Trace、交付 SLO 分析、交付原因分析及容器基础信息搜集，数据在模块之前按照需求做依赖 DAG，最终将产出 OTel、ES Table、Metrics 三种数据写入相关的数据服务。\n 存储到 ES、jaeger 和 prometheus 的数据，会被 Lunettes Rest API 和 Grafana di 处理，转换为 OpenAPI 数据接口和 Grafana Portal 上的数据进行展示。Grafana Portal 中一站式集成了 Lunettes 所有的功能，用户使用更便捷。\n Lunettes 核心能力 交付 SLO 交付 SLO 目的是基于 Kubernetes 交付链路能力对用户承诺交付保障。那么“交付 SLO”是什么呢？可以概括为：在一定时间内保障用户的容器可以成功交付。这个时间就是给用户的承诺，自然地 SLO 时间如何来定是非常关键的。Lunettes 主要从 Pod Spec 中获取资源规格、资源亲和配置等属性，计算出 Pod 的 SLO 时间。另外，Lunettes 也会根据 Pod 选择的不同交付链路（可以简单的理解为高速交付链路和普通低速链路）来给出保障时间。\n有了 SLO 超时计算标准，另一个挑战是如何计算 SLO 时间。如前文所述，容器交付链路中包含了多个阶段，Lunettes 将其区分为 Kubernetes 平台自身耗时和用户耗时两大类，通过 overlay 时间轴，去除用户时间后作为整体 SLO 时间保障。如此，对外承诺的 SLO 时间不会因为用户错误行为（配置、代码 bug 等）导致承诺失败。\n交付诊断 交付过程中出错是必然的，从庞大的 Kubernetes 系统快速定位容器交付过程中的问题是用户非常关心的。Lunettes 另一个重要的能力是从大量的容器交付行为信息中分析出容器交付的错误原因，用户通过 Portal 或者 OpenAPI 可以轻松获取容器交付的结果，如下图所示，Lunettes 在诊断结果中积累沉淀了 30 余种错误类型，帮用户快速定位问题。\n诊断过程中，Lunettes 采用回放审计日志技术，通过模拟容器交付过程抽象定义出原因分析 DAG 框架。审计日志回放输入 DAG 诊断框架后，各模块将分析自己阶段的交付是否完成，如果出错则抛出异常。最终，经过回放分析给出 Pod 出错位置，当然各分析模块是面向终态的分析过程。DAG 的框架既保证了分析过程行为的正确性，也提升了诊断流程的可扩展性。\n交付 Trace 交付 Trace 核心目的是跟踪每个 Pod 的交付过程，记录 Pod 交付过程中各阶段的耗时，以及对出错的阶段进行日志记录。一般地，在微服务系统中面向请求的 Trace 都是打桩，正如前文所述 Kubernetes 这种终态异步系统中，打桩每个管控组件是非常大的一个工程量，而且在组件之间异步分布式传递 Trace Context 很有挑战性。Lunettes 另辟蹊径，基于审计日志，抽象出 HyperEvent 概念，其包含了 Pod 交付过程中发生在 Pod 身上所有的 Verb 和 Event 两类信息，比如 Patch 一个 Condition 表示某个交付阶段完成，透出一个 Event 表示某个阶段结束。这两种信息被进一步用于定义交付 Trace 过程中每个阶段的开始和 …","date":1699945200,"description":"告别复杂性！用正确的工具轻松应对 K8s 管理挑战","dir":"blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"55bbf8c8afe1ee0fec5d19b4e8176065","permalink":"https://sofastack.github.io/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","publishdate":"2023-11-14T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","summary":"文｜王连平（花名：烨川) 蚂蚁集团容器团队专家 本文 3441 字 阅读 9 分钟 技术背景 Kubernetes 是容器编排的标杆平台，其标准化、插件化特性促使其拥有巨大的生态体系。","tags":["SOFAStack"],"title":"告别复杂性！用正确的工具轻松应对 K8s 管理挑战","type":"blog","url":"/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","wordcount":2785},{"author":null,"categories":"SOFAStack","content":" 今天，我们邀请到了开源之夏 2023 活动 Dragonfly 社区的中选学生李从旺同学，他此次承担的项目是——「PyTorch Serve 基于 Dragonfly P2P 技术分发模型」。希望通过他的开源故事，能让更多人了解到开源的魅力，也可以从不同的视角去认识 Dragonfly 项目。\n关于 Dragonfly Dragonfly 提供高效、稳定、安全的基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为孵化级别的托管项目。Dragonfly 在解决大规模文件分发场景下有着无可比拟的优势。P2P 技术在 AI 推理服务分发大模型场景现阶段应用较少，并且 P2P 技术经过证实也可以真正解决大文件分发过程中的性能瓶颈。在 AI 推理服务分发大模型场景，通过集成 Dragonfly P2P 技术减少源站压力，并且提高模型分发效率。结合 AI 推理领域生态拓展 Dragonfly 应用场景，服务 AI 领域并且成为重要基础设施。\n项目信息 项目名称：PyTorch Serve 基于 Dragonfly P2P 技术分发模型\n项目导师：戚文博\n项目描述：本项目是在 PyTorch Serve 分发过程中解决推理模型拉取时，可能会存在性能带宽瓶颈的问题，所以本项目需要 Dragonfly 通过 P2P 能力提高 PyTorch Serve 模型拉取速度，主要供过 Plugin 方式将 Dragonfly P2P 能力集成到 PyTorch Serve 中。\n项目链接：https://github.com/dragonflyoss/dragonfly-endpoint\n项目实现思路 无论你是需要安装或是升级，对 Dragonfly 各个组件的理解很重要，这是后期顺利进行性能测试的一个前提。\n Manager: 维护各 P2P 集群之间的关系，动态配置管理和 RBAC。它还包括一个前端控制台，方便用户直观地操作集群。 Scheduler: 为下载对等体选择最优的下载父对等体。异常控制 Dfdaemon 的返回源。 Seed Peer：Dfdaemon 开启的种子节点模式，可以作为 P2P 集群中的背向源下载节点，它是整个集群中下载的根节点。 Peer: 与 Dfdaemon 一起部署，基于 C/S 架构，提供 dfget 命令下载工具，dfget 守护进程运行守护进程提供任务下载功能。 架构 TorchServe 通过集成 Dragonfly Endpoint 插件，发送模型下载请求到 Dragonfly ，Dragonfly 作为代理去对应的 Object Storage 下载模型并返回。\n模型下载步骤：\n1、TorchServe 发起模型下载请求到 Dragonfly Peer。 2、Dragonfly Peer 会到 Dragonfly Scheduler 注册任务。 3、返回拥有资源的候选的父节点。 - Scheduler 服务发现本地 Cache 对这个任务是缓存未命中状态，就触发从 Seed Peer 进行文件下载。 - Seed Peer 如果对于任务也是缓存未命中状态，就会触发回源下载，即到对应的对象存储下载模型文件。 4、到对应的候选的父节点进行分片下载文件。 5、模型下载返回后，TorchServe 会进行模型注册。\n在性能测试的步骤中，会对模型下载的几种情况分别进行测试，而结果显示下载性能在命中缓存的情况下确实有极大的提升。\n开源之夏个人随访 自我介绍 大家好，我叫李从旺，是佐治亚理工学院电子与计算机工程专业研二的学生。去年就曾参加过开源之夏的活动，当时的任务是为 Apache APISIX 网关做插件。\n参加活动的原因 我之前参与过开源之夏，发现这个活动非常适合学生去了解以及深入参与到开源社区。众多的开源项目与技术发现可以让我们了解到行业中的最新动态，比如去年的云原生和今年的 AI 基础设施、大模型等。\n同时这种实践搭配的任务难度，在导师与社区的热心帮助之下，无论是为了磨练技术、建立社区连接，还是作为新手开源入门的起点都非常合适。对我来说，第二次参与活动的主要目的是了解并学习新技术。\n申请本社区项目的原因 主要是我对 Dragonfly 的 P2P 技术很感兴趣，并且它也符合我的技术栈。我提前了解过 Dragonfly 在业界的使用情况与热度，得知它作为实用的基础设施广泛被各个公司使用，且仍然在迭代新功能，于是便有了申请的想法。其次就是我对于插件的编写比较有经验，上手本次的项目会更加顺利。\n如何克服项目过程中的困难与挑战？ 主要的困难在于，之前我没想到 TorchServe 官方对于前端的插件支持较少，因此在调研初期，花费了较多时间去了解 TorchServe 的架构细节与插件的实现机制等。在插件的设计方案上也踩了不少坑：比如起初只考虑增加模型加速下载的部分，而官方 API 模型的下载与注册却是同时进行的；同时官方的代码设计中许多内部方法是不对外开放的，这样一来插件编写的方案也会有限制。这一问题的克服方法主要是反复查看官方代码、文档以及和导师沟通，不合理的方案不断地被导师淘汰，最终我找到了代码侵入最小的实现方式。\n还有开源项目从零开始搭建的困难，包括目录设计、工作流的设计、测试用例、文档编写（需要不断打磨）等工作。这些非 coding 的部分往往会占据更多的时间。我的建议是——积极参考社区优秀活跃的开源项目和直接询问导师，这样效率会比用搜索引擎快得多。因为很多规范是会随时间变化的，新项目当然要符合最新的规范。\n困难还出现在测试环节！整个插件的使用涉及到不同的对象存储、Dragonfly 以及 TorchServe 等多个组件；多种环境的部署以及不同的配置细节也需要付出额外的关注。当然，最大的挑战是由我硬件资源不足的电脑带来的，解决的办法主要是详细地记录步骤以及利用一些云计算资源，这对后期使用文档的撰写也非常有帮助。\n导师与社区带来的帮助 在整个开发的过程中，包括前期调研环节，导师给予我的帮助是巨大的。耐心、细心、负责是 Dragonfly 社区以及我的导师给我的最大感受了。他们不仅在技术上给出指导，在文档编写乃至后期的技术交流方面也都非常用心。开发周期内的每周例会和平时的信息反馈也都非常及时，我作为学生，体验也非常好。\n你眼中的 Dragonfly 社区印象 Dragonfly 致力于提供高效、稳定、安全的基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。目前社区还在不断壮大发展中，欢迎大家一起来参与开源共建。\n超出预期的收获 在调研中，我学习到了 Dragonfly P2P 的实现原理以及 TorchServe 各个模块的实现方案。在每周例会中，也有许多来自其他社区的同学或嘉宾， …","date":1699340400,"description":"开源之夏经验分享｜Dragonfly 社区 李从旺：社区贡献也是一种影响力","dir":"blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f093077c7b660418d01cdd971f144de1","permalink":"https://sofastack.github.io/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","publishdate":"2023-11-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","summary":"今天，我们邀请到了开源之夏 2023 活动 Dragonfly 社区的中选学生李从旺同学，他此次承担的项目是——「PyTorch Serve 基于 Dragonfly P2P 技术分发模型」。希望通过他的开源","tags":["SOFAStack"],"title":"开源之夏经验分享｜Dragonfly 社区 李从旺：社区贡献也是一种影响力","type":"blog","url":"/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","wordcount":2622},{"author":null,"categories":"SOFAStack","content":" 文｜谭崇康（*花名：见云*）\n蚂蚁集团高级技术专家\n本文 3781 字 阅读 10 分钟\n问题：K8s 服务运营需要更好的可观测能力 云原生系统以 Kubernetes*（K8s）*为基石，业界很多公司的基础设施也构建在 K8s 平台之上。作为公司的关键基础设施，K8s 平台的运营效率直接影响业务的稳定与效率。\n然而，将 K8s 作为服务运营与单纯的使用 K8s 存在很大的区别。在使用 K8s 时，我们关注是形形色色的功能，而在 K8s 服务运营过程中我们将更加聚焦 K8s 服务的质量以及效率。运营一个 K8s 服务需要关注的典型问题例如：\n 问题诊断及其效率：K8s 链路长、组件多、概念丰富、状态复杂等，如何快速诊断日常失败问题原因是一个很关键的能力； 服务质量衡量问题：如何衡量 K8s 平台服务整体资源交付效率以及调度、镜像拉取、IP 分配等各个环节的服务质量，进而引导服务能力的提升； 链路性能问题：如何发现、定位集群中的性能瓶颈，提升集群的资源交付吞吐； 运营体系化问题：当前社区的可观测服务更多关注的还是某些孤立的功能点，服务运营需要的是数字化、性能、效率、体系化等。 Lunettes：K8s 平台运营可观测工作空间 K8s 集群构成的容器服务平台，并努力提升平台服务的质量。在这个过程中，我们沉淀了很多运营工具以及相关的运营经验。基于这些工具及经验，我们构建了容器可观测服务 Lunettes，希望帮助大家更简单地运营 Kuberntes 服务。Lunettes 项目代码已经在 GitHub 平台开放，欢迎大家参与！\n项目链接：https://github.com/alipay/container-observability-service\nLunettes 服务提供的一些特性，包括：\n 定义了 K8s 资源交付效率的 SLO，并基于 SLO 产出了成功率相关的可观测数据，用户基于 SLO 衡量 K8s 整体及子服务的质量，同时发现服务能力受损等问题； 提供了容器一键诊断能力，Lunettes 分析 K8s 资源交付过程的各个阶段，产出当前运维过程中的问题，帮助用户快速定位及解决问题； 建设了一套无侵入的资源交付 Trace 能力，基于 Lunettes 分析的 HyperEvent 事件，用户可以看到资源交付链路中各个子阶段的耗时及错误，及时发现性能瓶颈点。 其他的一些易用特性包括：\n 统一的操作界面，支持多集群管理，一站式服务体验； 多维信息的聚合能力，提供日志、监控、Trace 等多维数据融合的能力。 Lunettes 是一个一站式的 K8s 容器可观测服务，能够为原生的 K8s 集群构建一个为服务运营打造的可观测工作空间，大幅降低了 K8s 服务运营的难度：\n 基于可扩展的多维可观测数据构建：Lunettes 将不同维度的可观测数据抽象为 HyperEvent，并在 HyperEvent 之上构建其他服务能力。我们可以方便地通过配置化封装能力将新的可观测数据维度封装成 HyperEvent 从而扩展 Lunettes 的数据聚合能力。 面向原生 K8s 集群，一键拉起：Lunettes 各个核心功能都具备灵活的配置能力，并且默认配置为原生 K8s 版本设计。Lunettes 可以采用普通 YAML 或 helm charts 部署，用户可以方便地在 K8s 集群一键拉起 Lunettes 服务。 构建 K8s 运营的完整的可观测工作空间*（workspace）*：Lunettes 提供了包含资源交付 SLO、容器生命周期诊断、容器生命周期 Trace、多维数据融合等常用的功能，为 K8s 集群提供一站式运营工作空间。 软件架构 Lunettes 服务的软件架构分为四层，分别为：\n 用户接口层 *（User-Portal）*：图形化交互基于 Grafana 构建，此外我们也提供 OpenAPI 接口； 可观测服务层 *（Observability-Services）*：包含阶段耗时分析、资源交付 SLO、资源交付诊断、资源交付 Trace 等多个可观测特性； 数据处理层 *（Data- Processing）*：Lunettes 具有可观测数据源扩展能力，支持 Operations、Events 等多种可观测数据，并将可观测数据统一封装为 HyperEvent，经由上层的 SharedProcessor 统一处理。在 Lunettes 中，可观测数据的处理是高度可配置化的，ConfigCenter 负责配置的管理。 存储层 *（Storage）*：Lunettes 的存储层支持多种存储服务，包含 Prometheus、ElasticSearch、SLS 等。 基础功能介绍 资源交付 SLO K8s 的核心功能是将资源以容器的形式交付出去。如何定义容器平台的资源交付质量是一个核心的话题。Lunettes 首先根据可观测数据定义容器生命周期中的各个阶段，区分基础设施阶段以及用户应用阶段，从而统计容器平台容器交付所花费的时间。进一步，Lunettes 根据容器交付的时间定义资源交付 SLO。下图中展示了集群的 1 分钟级以及 1 小时级 Pod 创建成功率的 SLO 数据。\n容器生命周期诊断 Lunettes 将诊断 Pod 创建流程中各个阶段的错误，形成典型容器创建错误码，例如 FailedScheduling 对应调度失败、FailedPullImage 对应镜像拉取失败等。典型的错误码将具备以下功能：\n 错误信息形成一个标准的错误集合，每个错误类型以可理解的方式代表特定的一类错误，给用户提供当前交付失败的诊断结果； 形成标准的 ErrorCode，作为上下游问题传递的依据，构建端到端的诊断链路； 当集群故障时，诊断结果作为聚合信息，当大量错误聚合时，方便我们快速定位到集群中的错误组件及错误原因。 在诊断过程中，Lunettes 将从底层的可观测数据中抽取生命周期中的关键事件，涵盖了 Operation、Events 等，帮助用户根据关键事件快速定位容器生命周期中的各种问题。\n资源交付 Trace Lunettes 设计了一套无侵入的资源交付*（创建、删除等）*过程 Trace 体系，基于 Lunettes 分析的 HyperEvent 事件，以用户可理解的方式分析资源交付过程中的各个阶段，例如 IP 分配、镜像拉取、Volume 绑定等，并基于这些分析构建了资源交付 Trace。通过资源交付 Trace，用户可以方便地找到资源交付过程中各个阶段的耗时及错误，从而掌握整个资源交付过程中的热点问题。Trace 与 Log、Event 等关联，帮助用户快速找到问题的根因。\n多维信息聚合能力 基于我们在过去多年积累的 K8s 运营经验，Lunettes 为日常运营活动中的多个典型场景设计，聚合了 YAML 信息、Event 信息、审计信息、Trace 信息、SLO 信息等多维度的可观测信息，为用户提供一个完整的 K8s 运营可观测工作空间。\n实践：几个典型的使用场景 Case1：诊断 Pod 创建失败 以镜像拉取失败为例，我们来看一下在 Lunettes 中， …","date":1698735600,"description":"Lunettes - 让 Kubernetes 服务运营更简单","dir":"blog/lunettes-makes-kubernetes-service-operations-easier/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"edc4c98af54696e29b070cc6ce02dea6","permalink":"https://sofastack.github.io/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","publishdate":"2023-10-31T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","summary":"文｜谭崇康（*花名：见云*） 蚂蚁集团高级技术专家 本文 3781 字 阅读 10 分钟 问题：K8s 服务运营需要更好的可观测能力 云原生系统以 Kubernetes*","tags":["SOFAStack"],"title":"Lunettes - 让 Kubernetes 服务运营更简单","type":"blog","url":"/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","wordcount":3487},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack GitHub issue 精选 本周各项目回复 issue 精选 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n1.@MOSN #2347\n@huayangchan\n 我们目前在调研阶段，想用 envoy 做来做流量代理，但是考虑到研发效能，所以想用 MOE 的方案看看。因为涉及到 L4 的流量处理，顺便再确认下，那对于企业内部自定义的 RPC 协议，涉及到四层的流量 filter 操作，基于目前开源版 MOSN 是做不‍到哈？只能基于原生 envoy 的 L4 extension 来做么？\n A：这个我们内部的做法就是 MOSN 的 xprotocol 框架支持多协议，然后再用 L4 MOE 嫁接到 envoy 上。收益还是很可观，没有链接的常驻协程。如果直接用 envoy 的 L4 的话，你其实还是需要用 Go 搞一套 proxy 框架出来的。你可以先用纯 MOSN 支持你们的 RPC 协议，然后再用 MOE 移植到 envoy 上。\n「MOSN」：https://github.com/mosn/mosn/issues/2347\n2.@SOFABolt #332\n@tongtaodragonfly\n 在我们的环境中，连接事件日志文件中出现警告消息，如下所示：\n未知协议代码：[ProtocolVersion{version=[3]}] 在 ProtocolDecoder 中解码时。] 为什么会报告此警告消息？什么样的情况可能会触发此警告消息？\n A：协议版本是应用层网络帧的第一个字节。通常为 1*（对于 BoltV1）*和 2*（对于 BoltV2 协议）*。如果第一个字节是 3，bolt 找不到对应的协议，所以你会看到这个错误。\n此问题可能有两个常见原因：\n 一些未知的客户端向您的端口发送错误的数据包； 解码器没有消耗掉一个数据包中的所有数据，因此存中留下了一些错误的数据。Decoder 下次消费数据时，读取到了错误的数据。 「SOFARPC」：https://github.com/sofastack/sofa-registry/issues/332\n3.@SOFAArk #741\n@jgslvwy\n 请问下 SOFAArk 子应用支持用 spring-boot-maven-plugin 吗？为什么示例里面子应用还用的 sofa-ark-maven-plugin？\n A：子应用使用 sofa-ark-maven-plugin 构建产物是可以热部署到基座的 Jar 包，你要用 spring-boot-maven-plugin 也是可以，子应用本身也是独立的 Spring Boot，只是不能热部署到基座 JVM 上而已。\n「MOSN」：https://github.com/sofastack/sofa-ark/issues/741\n本周推荐阅读 MoE 系列（六）｜Envoy Go 扩展之并发安全\nSeata Saga 模式快速入门和最佳实践\nGo 语言，如何做逆向类型推导?\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\n","date":1696575600,"description":"SOFA 聊天室、issue 精选","dir":"blog/sofa-weekly-1006/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0dd36b93af4616c470c2dacf6b00830c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-1006/","publishdate":"2023-10-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-1006/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 聊天室、issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-1006/","wordcount":1117},{"author":null,"categories":"SOFAStack","content":" 文｜梁仕威（花名：栖川）\n蚂蚁集团算法专家\n方略平台技术负责人，专注于分布式计算领域，主要负责蚂蚁基础算法的分布式设计与开发。\n本文 3419 字，阅读 9 分钟\n在类似安全风控这种对抗性的场景中，由于欺诈者作案手法的频繁变化，使得训练数据并不总会包含足够的信息给算法自动挖掘出优质的拦截规则，这种场景下高质量拦截规则的挖掘需要结合专家领域知识。如何将算法和专家领域知识相结合成为了业界一个值得探索的课题。蚂蚁集团 AI Infra 团队针对上述问题，构建了一个交互式的规则研发系统——方略，提供了一种在规则研发过程中高效融入专家领域知识的解决方案。\n描述该系统的 Demonstration Paper 《Fanglue: An Interactive System for Decision Rule Crafting》 近期已经被数据库领域的重要会议 International Conference on Very Large Data Bases （VLDB2023） 所接收。VLDB 是中国计算机学会 （CCF） 推荐的 A 类会议，每年都会吸引国内外各大高校和科技公司的投稿。\n1｜背景 决策规则由于其直观可解释的 If-Then 结构，被广泛应用于欺诈预防等金融科技领域至关重要的任务中。标准的决策规则由两部分构成：一系列条件和预测值。 条件是由特征、操作符、值构成的三元组结构，例如 age\u0026amp;lt;50。当规则中的所有条件都被满足时，规则会输出预测值。\n目前大多数现有的规则挖掘系统都是以端到端形式运行的，即给定训练集后，专家设定规则挖掘算法的优化指标和超参数，然后等待算法运行结束就可以获得一组规则。在这种方式下，设置超参数和优化指标是融入专家领域知识的唯一途径，一旦规则挖掘过程开始，专家就没有其他方法能够干预规则的生成。但是在如风控这种对抗性的场景中，由于作案手法的频繁变化，训练数据里并不总会包含足够的信息给算法自动挖掘出优质的规则。在这种情况下，专家必须将领域知识更深入地融合到规则生成过程中才能获得有意义的结果。\n举个例子，假设支付宝的一位风控专家，想要编辑规则来拦截一种新型欺诈行为。由于该欺诈行为是最近才出现的，他准备的数据集中只有少数关于这种欺诈行为的黑样本。假设这种欺诈行为的一个关键步骤是要求受害者向欺诈者发送多个付款码，因此短时间内付款码刷新的次数是识别这种欺诈活动的重要特征。然而风控专家发现挖掘算法返回的规则中没有使用该特征，大多数规则都使用了交易金额来区分欺诈行为和正常行为，因为数据集中的交易金额巧合地将这两种行为区分开了。但是随着新型欺诈行为的普及，交易金额就不能继续作为识别这种欺诈行为的有力依据了。这种现象在反欺诈场景中并不罕见，当黑样本太少时，无关的特征也能够区分出输入数据中的黑白样本。虽然付款码刷新频次确实是规则挖掘过程中一个非常有竞争力的特征 （例如评估指标排名靠前） ，但由于数据中噪声的影响，使得其不能排到最前面，从而不能被算法挖掘出来。这种情况下，将专家领域知识融入进来，让付款码刷新频次这个特征应用到拦截规则中，对阻止新型欺诈行为扩散尤为重要。\n为了能在规则研发过程中高效融入专家领域知识，蚂蚁集团 AI Infra 团队构建了一个交互式的规则研发系统——方略。方略为用户提供了一个 Web 界面来可视化地制定决策规则。用户将数据上传到方略后就可以开始规则研发流程，方略会实时地推荐出规则的候选条件与对应评估指标，并生成数据分析结果，为用户提供有用的定量分析信息。同时方略使用 Ray 作为计算引擎并将数据分布式存储在内存中，以满足在交互式处理大规模数据时的实时响应需求。\n2｜系统架构 （图 1）\n图 1 展示了方略的系统架构。用户通过 Web 界面与方略进行交互。方略的界面上有三个核心模块：条件推荐模块、条件编辑模块和规则评估模块。服务端的 Task Manager 负责接收来自三个核心模块的请求①，并且会启动相应的 Ray 作业②。\n用于计算的数据水平切分后预先加载进 Ray 的一组 Actor 内存里。对于一个特定的计算任务，每个 Actor 都会基于分配到的数据计算出局部统计信息，这些局部统计信息会汇集到 Driver 里进一步处理得到全局统计信息③。然后全局统计信息返回给 Task Manager④，并被传递给 Data Processor。Data Processor 在全局统计信息的基础上进一步处理，例如计算出各个候选条件的评估指标，得到的处理结果会在 Web 界面上展示给用户⑤。然后整个系统会等待用户的下一步操作。\n一旦用户作出某些操作 （例如从候选条件中选择一个加入到当前规则中） 触发相应的核心模块，系统就会重复上述过程。用户编辑好的规则会保存到数据库里⑥。\n3｜技术细节 不同于标准规则，方略采用合取范式 （Conjunctive Normal Form） 的规则表示形式，即同时支持“AND”和“OR”条件。合取范式规则是由一个或多个子句和一个预测值组成的合取式 （AND 连接） ，其中子句是条件的析取式 （OR 连接） ，条件的形式为特征、运算符、值。方略专注于二分类问题，使用训练集和验证集上的精确度、召回率、F1 得分或黑样本覆盖率等指标来评估决策规则。\n方略提供三种实时的条件推荐帮助用户构建规则： “AND”条件推荐、 “OR”条件推荐、近似条件推荐。\n假设我们已经有了一些子句构成的决策规则，需要往这个规则中增加一个“AND”或者“OR”条件，方略会搜索所有可能的三元组 （特征、运算符、值） ，并通过将这些候选条件附加到当前规则里计算评估指标。标准的规则学习算法会选择具有最佳指标的候选条件，而方略会在 Web 界面上展示在验证集上取得 top 评估指标的候选条件列表供用户选择。\n为了快速计算所有候选条件的评估指标，方略使用 Ray 作为计算引擎，每个 Actor 计算出局部统计信息，然后聚合到 Driver 里得到全局统计信息。为了验证系统的效率，我们在一个包含 140 万个样本和 50 个特征的数据集上进行了实验。图 2 对比了在生成“AND”候选条件下，方略的实现与基于 Mars on Ray （基于 DataFrame 运算） 实现的耗时。可以看到方略的实现非常高效，使用 16 个 Actor 就可以在 1 秒内返回结果，满足交互式环境下高响应的需要。\n（图 2）\n在安全风控场景下，当规则中存在一些容易被攻击的条件时 （例如拦截规则里有条件：转账金额\u0026amp;gt;=500，欺诈方只需要使得转账金额小于 500 就可以绕过拦截规则） ，风控专家会希望通过寻找“语义上相似”的条件来增加另一层保护。为了加强规则的鲁棒性，方略提出并引入了近似条件。假设当前的规则是 C1 and C2 and C3，覆盖的样本集为 A，我们希望在 C2 上增加近似条件，那么方略会在 C1 and C3 的基础上遍历所有的候选条件 （特征、运算符、值） ，每个候选条件都会覆盖数据的一个子集，记为 B。一个理想的近似条件应该在 A 和 B 之间具有高重叠度，同时又不引入太多额外的白样本。方略基于图 3 所示的公式衡量条件的相似度，其中表示中带有正标签的子集，表示中带有负标 …","date":1696316400,"description":"VLDB2023｜方略：一个交互式的规则研发系统","dir":"blog/vldb2023-fanglue-an-interactive-rule-development-system/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"310a7da278d5e5a913dc0e0d09ac6c02","permalink":"https://sofastack.github.io/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","publishdate":"2023-10-03T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","summary":"文｜梁仕威（花名：栖川） 蚂蚁集团算法专家 方略平台技术负责人，专注于分布式计算领域，主要负责蚂蚁基础算法的分布式设计与开发。 本文 3419 字，阅读 9 分","tags":["SOFAStack"],"title":"VLDB2023｜方略：一个交互式的规则研发系统","type":"blog","url":"/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","wordcount":3237},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议回顾 SOFAServerless：\n主题：SOFAServerless 社区会议 时间：09 月 27 日 19:30 - 20:30\n会议内容：\n 待跟进事项：\n ModuleController corner case 和多场景验证以及功能打磨\n 0.5 版本补充 ModuleController 和 Arklet 新 feature 使用文档\n 开源中间件排摸继续跟进\n 补充 0.5 版本原理文档\n 0.5 版本待合并收尾，开源之夏结项\n 发布内容：\n SOFAServerless 0.5.0 可试用版本已发布，详细可查看👇\n 试用手册 https://sofaserverless.netlify.app/docs/tutorials/base-create/springboot-and-sofaboot\n 试用样例 https://github.com/sofastack-guides/sofa-ark-spring-guides/tree/master/samples/web/tomcat\n 「SOFAServerless」：https://github.com/sofastack/sofa-serverless/issues/117\nSOFAStack 社区本周贡献 本周推荐阅读 蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata Saga 模式快速入门和最佳实践\n大象转身：支付宝资金技术 Serverless 提效总结\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\n","date":1695970800,"description":"SOFAServerless 社区会议回顾、社区本周贡献、SOFA 亚运特辑","dir":"blog/sofa-weekly-20230929/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5b9c3463eb10dee170d71426e96abb86","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230929/","publishdate":"2023-09-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230929/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议回顾、社区本周贡献、SOFA 亚运特辑","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230929/","wordcount":529},{"author":null,"categories":"SOFAStack","content":" 2023 年 9 月 20 日，KCL 项目通过了全球顶级开源基金会云原生计算基金会 （CNCF） 技术监督委员会评定，正式成为 CNCF 沙盒项目。\n这意味着 KCL 得到了云原生开源社区的认可，保障了项目的中立性，有利于开发者、合作伙伴等共同参与项目建设，协作共赢，并为云原生应用交付带来动态配置管理和自动化能力迈出了重要一步！\n 项目地址：https://github.com/kcl-lang/kcl 项目官网：https://kcl-lang.io 通过进入 CNCF 沙盒，KCL 社区将更多吸引更多开发者和用户参与共建，进一步推动项目在云原生业务场景的成熟应用，此外加入 CNCF 将为 KCL 提供一个增强的协作和创新平台。它提供了与处于云原生技术前沿的多元化开发者、组织和行业专家社区进行交流的机会。我们期待与其他 CNCF 项目进行更多合作，贡献我们的技术专业知识，并探索更多 CNCF 项目集成的可能性。\n什么是 CNCF CNCF，全称 Cloud Native Computing Foundation （云原生计算基金会） ，是 Linux 基金会旗下的子基金会。CNCF 致力于为云原生软件构建可持续生态系统，涉及领域包括存储、计算、编排、调度、CI/CD、DevOps、服务治理、服务网关等。\n比如 Kubernetes 便是 CNCF 最具代表性的项目之一。\n什么是 CNCF 沙盒项目 CNCF 社区将项目分为沙盒项目 （Sandbox） 、孵化项目 （Incubating） 、毕业项目 （Graduated） 。著名的毕业项目有：Kubernetes、Prometheus、Istio、ETCD、Containerd、ArgoCD 和 Helm 等。完整的毕业和孵化项目列表查看地址：https://www.cncf.io/projects/\nSandbox 是 CNCF 创建的，旨在为开源项目提供一个有益的、中立的家园，以促进开源项目的合作与开发。入选沙盒的项目，是被 CNCF TOC 认可的，并值得进行实验和开发的潜力项目。\nSandbox 对应的是 CNCF 社区早期项目，列表为：https://www.cncf.io/sandbox-projects/ 。进入 Sandbox 需要 66% 以上的 TOC （技术委员会） 成员赞成，即全部 11 人 https://github.com/cncf/toc#members 中的 8 人投赞成票。\n什么是 KCL KCL 是一个开源的基于约束的记录及函数语言，期望通过成熟的编程语言技术和实践来改进对大量繁杂配置比如云原生 Kubernetes 配置场景的编写，致力于围绕配置的模块化、扩展性和稳定性，打造更简单的逻辑编写体验，构建更简单的自动化和生态集成路径。\n项目主要里程碑如下：\n 2022 年 5 月，KCL 正式开源； 2023 年 6 月，KCL 正式成为 CNCF Landscape 项目； 2023 年 9 月，KCL 由 CNCF 应用交付 TAG 进行审核并通过 TOC 投票，顺利成为 CNCF Sandbox 项目 - https://github.com/cncf/sandbox/issues/48 为什么需要 KCL 正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在云原生配置和自动化的特定问题域内，我们使用专用配置和策略语言用于编写和管理规模化复杂配置及策略。不同于混合编写范式、混合工程能力的高级通用语言，专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将复杂配置和策略编写思路和方式沉淀到语言特性中。\n此外，KCL 期望通过更现代化的声明式配置语言和工具，在轻量级客户端云原生动态配置领域填补配置语言及工具的空白并解决如下问题：\n 维度爆炸: 大多数静态配置如云原生领域的 Kubernetes YAML 配置需要为每个环境单独进行配置；在最糟糕的情况下，它可能引入涉及环境交叉链接的难以调试的错误，稳定性和扩展性都较差。 配置漂移: 对于不同环境的静态管理应用程序和基础设施配置的方式，往往没有标准的方式去管理这些动态的不同环境的配置，采用非标准化的方法比如脚本和胶水代码的拼盘，会导致复杂度呈指数增长，并导致配置漂移。 认知负担: Kubernetes 等作为构建平台的平台技术手段在底层统一基础架构细节方面出色，但是缺乏更上层的应用软件交付抽象，对于普通开发者认知负担较高，影响了更上层应用开发者的软件交付体验。 针对如上问题，KCL 期望提供如下能力:\n 通过代码抽象等手段屏蔽基础设施和平台的细节和复杂性，降低研发者认知负担； 编辑和校验已有的存量配置或模版，直接解决云原生小配置场景问题如 Helm Chart 配置硬编码问题，但远不止如此； 通过配置语言无副作用地管理跨团队的大规模配置数据，提升团队协作效率。 具体来说，KCL 可以：\n 在代码层面提升配置语义验证的能力，比如 Schema 定义、字段可选/必选、类型、范围等配置检查校验能力； 提供配置分块编写、组合和抽象的能力，比如结构定义、结构继承、约束定义和配置策略合并等能力； 用现代编程语言的方式以编写代码的方式提升配置的灵活度，比如条件语句、循环、函数、包管理等特性提升配置重用的能力； 提供完备的工具链支持，丰富的 IDE 插件、语言和生态工具链支持用以降低上手门槛，提升使用体验； 通过包管理工具和 OCI Registry 使得配置以更简单的方式在不同团队/角色之间分享，传播和交付； 提供高性能的编译器满足规模化配置场景诉求，比如满足由一份基线配置根据部署上下文生成不同环境不同拓扑的配置的渲染性能以及配置自动化修改性能诉求； 通过多语言 SDK，KCL 语言插件等手段提升其自动化集成能力，在发挥配置及策略编写价值的同时显著降低 KCL 的学习成本。 除了语言自身，KCL 还提供了许多额外的工具如格式化，测试、文档等工具帮助您使用、理解和检查编写的配置或策略；通过 VS Code 等 IDE 插件，包管理工具和 Playground 降低配置编写和分享的成本；通过 Rust、Go 和 Python 多语言 SDK 自动化地管理和执行配置。\nKCL 能做什么 动态配置管理 作为一种配置语言，KCL 为应用程序和平台开发人员/SRE 提供的最重要的功能是动态配置管理。通过代码抽象，我们可以构建以应用为中心的模型屏蔽复杂的基础设施和平台概念，为开发人员提供一个以应用程序为中心且易于理解的界面。此外，KCL 还允许平台人员快速扩展和定义自己的模型，并且这些模型可以通过 OCI 注册表进行分享和复用。\n此外，KCL 还支持与 Kubernetes Resource Model (KRM) 规范直接集成，KRM KCL 是一个通用的配置模型规范，用于描述和管理各种云原生资源，如容器、Pod、服务的配置操作和抽象等。KRM KCL 规范提供了一种统一的方式来定义和管理这些资源，使得它们可以在不同的环境中进行移植和复用。它建立在一个完全开放的 Kubernetes 世界当中，几乎不与任何编排/引擎工具 …","date":1695711600,"description":"喜报！CNCF 基金会宣布 KCL 成为沙盒项目！","dir":"blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1b28ec99e654374176191b2a95853377","permalink":"https://sofastack.github.io/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","publishdate":"2023-09-26T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","summary":"2023 年 9 月 20 日，KCL 项目通过了全球顶级开源基金会云原生计算基金会 （CNCF） 技术监督委员会评定，正式成为 CNCF 沙盒项目。 这意味着 KCL 得到了云原生开","tags":["SOFAStack"],"title":"喜报！CNCF 基金会宣布 KCL 成为沙盒项目！","type":"blog","url":"/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","wordcount":4030},{"author":null,"categories":"SOFAStack","content":" 文｜唐荦彦\n深信服高级开发工程师，主要负责 SASE 云化架构以及基础设施建设\n本文 3056 字，阅读 6 分钟\n1｜你将在本文学到什么 多 K8s 集群镜像分发方案 Dragonfly 的理解 Harbor 的预热机制 Dragonfly 的使用以及排障 2｜K8S 多集群镜像分发问题 在边缘云架构的生产环境下，演进过程中，一开始的镜像分发方案如下：\n每个边缘集群都存在节点的 Harbor 仓库，进行缓存操作，当边缘集群集体崩溃重启过程中，不会引发所有 worker 上中心仓拉取镜像。\n带来的问题是：\n 每套环境一个 Harbor，导致部署、维护的困难。 Harbor 的复制策略比较简单，无法单例执行。并且重试非常占用中心仓带宽。 那么面对这种场景存在以下两种方案：\n Harbor 仓库分级复制策略 P2P 镜像分发策略 Harbor 仓库分级复制策略，存在以下问题：\n 如何进行分级划分 升级过程，如果节点所处的是第三级，如何触发复制策略加速缓存 每个节点增加了安全暴露面 节点的不断增加，后续是否需要 3 级、4 级、5 级，维护管理成本指数增加。 所以在项目中，我的选择是 Dragonfly 的 P2P 镜像分发策略。\n3｜Dragonfly 是什么 在理解过程中，首先需要搞懂以下几个问题：\n P2P 是什么？\n 镜像的分层拉取策略。\n 什么是 P2P 此 P2P 不是金融圈里面经常爆雷的，而是 Peer to Peer 网络技术。有几个比较突出的使用：\n 迅雷； 某夭折的播放器（*快 B*）； 国内一些视频网站白嫖用户网络的 P2P CDN。 为什么需要 P2P 网络 P2P 网络对应的就是传统网络传输 C/S 模式。传统模式下，所有的客户端请求数据下载都需要访问服务器，那么服务器的压力会非常大，当客户端多的情况下，网络带宽也存在问题。\n以下来自 WIKI 百科：\n对等式网络（*英语：peer-to-peer，简称 P2P*），又称点对点技术，是去中心化、依靠用户群（*peers*）交换信息的互联网体系。它的作用在于，减低以往网路传输中的节点，以降低资料遗失的风险。与有中心服务器的中央网络系统不同，对等网络的每个用户端既是一个节点，也有服务器的功能，任何一个节点无法直接找到其他节点，必须依靠其户群进行信息交流。\n镜像分层拉取 Docker 镜像通过分层进行资源共享，通过 copy-on-write 完成文件隔离。在执行 Pull 的时候，可以看到：\nc1c792ed5250: Already exists fcac137f6aa5: Already exists c31aa26549dd: Already exists 04699d7e44fb: Pull complete 可以分析得出，在 Docker pull 时，先会判断本地是否存在当前层，如果没有则从远端服务器拉取层。\nDragonfly 架构** 组件包括：\nManager: 多 Dragonfly 调度节点进行管理，提供了 UI 管理界面、镜像预热机制。\nScheduler:\n 基于机器学习的多场景自适应智能 P2P 节点调度，为当前下载节点选择最优父节点； 构建 P2P 下载网络的有向无环图； 根据不同特征值评估节点下载能力, 剔除异常节点； 当下载失败情况，主动通知 Dfdaemon 进行回源下载。 Dfdaemon： （*分为 Peer、Seed Peer*）\n 基于 gRPC 提供下载功能, 并提供多源适配能力； 开启 Seed Peer 模式可以作为 P2P 集群中回源下载节点, 也就是整个集群中下载的根节点； 为镜像仓库或者其他 HTTP 下载任务提供代理服务； 下载任务基于 HTTP 或 HTTPS 或其他自定义协议。 使用场景流程说明如下：（*当需要下载某一层镜像时*）\n Docker 在请求下载镜像时，通过配置 Docker http proxy 代理，将请求转发到 Peer 节点。\n Peer 节点进行本地缓存判断，查看是否存在该层镜像；\n 是，则直接响应。如图： 如果当前 Peer 不存在，将当前请求转发到 Scheduler；\n Scheduler 将判断 Seed Peer 中是否存在：\n 是，则将对应的地址返回，通知 Peer 去指定的 Seed Peer 拉取资源,如图： 否，则通知 Seed Peer 回源拉取，拉取成功后，Peer 再进行拉取。 最长路径：Docker -\u0026amp;gt; Peer -\u0026amp;gt; Seed Peer -\u0026amp;gt; 源站 -\u0026amp;gt; Seed Peer -\u0026amp;gt; Peer -\u0026amp;gt; Docker。\nDragonfly 操作实践（*Docker 版*） 由于 K8s 版本过于简单，封装了 Docker 手动操作部分，这里讲源码版本如何使用。\n源码安装\n从上面已经了解到：Docker pull 通过 http proxy 配置即可通过 Peer 拉取镜像，那么操作就简单了。\n步骤如下：\n 配置 Docker；\n 安装依赖组件：MySQL、Redis、Jaeger（*为了研究操作路径以及代码*）;\n 配置 Manager、Scheduler、Seed Peer、Peer；\n 详细步骤如下：\na.配置 Docker 配置 http proxy  vi /etc/systemd/system/docker.service.d/http-proxy.conf [Service] Environment=\u0026amp;quot;HTTP_PROXY=http://127.0.0.1:65001\u0026amp;quot; Environment=\u0026amp;quot;HTTPS_PROXY=http://127.0.0.1:65001\u0026amp;quot; 私有仓库的话，配置忽略证书 insecure-registries； vi /etc/docker/daemon.json { \u0026amp;quot;insecure-registries\u0026amp;quot;: [\u0026amp;quot;your.private.registry\u0026amp;quot;] } 重启 Docker：systemctl restart docker。\nb.安装依赖 MySQL: docker run -d --name dragonfly-mysql --restart=always -p 3306:3306 \\ --env MARIADB_USER=\u0026amp;quot;dragonfly\u0026amp;quot; \\ --env MARIADB_PASSWORD=\u0026amp;quot;dragonfly\u0026amp;quot; \\ --env MARIADB_DATABASE=\u0026amp;quot;manager\u0026amp;quot; \\ --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=\u0026amp;quot;yes\u0026amp;quot; \\ mariadb:10.6 Redis：\ndocker run -d --name dragonfly-redis --restart=always -p 6379:6379 \\ redis:6-alpine \\ --requirepass …","date":1695106800,"description":"Docker 环境基于 Dragonfly 的 Kubernetes 多集群镜像分发实践","dir":"blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a9c41894dec9bab10278add3e654f859","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","publishdate":"2023-09-19T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","summary":"文｜唐荦彦 深信服高级开发工程师，主要负责 SASE 云化架构以及基础设施建设 本文 3056 字，阅读 6 分钟 1｜你将在本文学到什么 多 K8s 集群镜像分发方案 Dragonfly 的理解 Harbor 的","tags":["SOFAStack"],"title":"Docker 环境基于 Dragonfly 的 Kubernetes 多集群镜像分发实践","type":"blog","url":"/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","wordcount":2798},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题： Layotto 社区会议\n时间： 09 月 20 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入： +02162681677（中国大陆）+057128095818（中国大陆）\n入会链接： https://meeting.dingtalk.com/j/r3Nq5pEd730\n议题：\n Layotto 项目规划和展望 #976 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910 2023 CSDI SUMMIT #987\n add uds support for Java SDK\n 「Layotto」：https://github.com/mosn/layotto/issues/989\nSOAFServerless：\n主题： SOFAServerless 社区会议\n时间： 09 月 19 日 19:30 - 20:30\n入会口令（钉钉）： 909 575 00367\n电话呼入： +02162681677（中国大陆）+057128095818（中国大陆）\n入会链接： https://meeting.dingtalk.com/j/eU7EoXJYiHK\n议题：\n 已完成部分\n 健康状态检查方案 review\n 基座引用的 starter，支持 Spring Boot、SOFABoot，Arklet 版本推到 Maven 中央仓库\n 增加锁控制\n 修复 ModuleController 使用 Arklet 遇到的问题\n 基座 Starter，Arklet 0.4 版本打包发版\n 待迭代事项\n SOFAArk\n 基座模块 1:1 复用\n 支持 SOFABoot 4\n SOFAServerless\n 支持中间件列表与优先级，排摸支持情况，设计评测标准\n 官网搭建\n ModuleController\n 先扩后缩\n 模块回滚\n 模块流量 Service\n 强推基线\n 单测达到 80/60、8+ 集成测试、CI 自动化、开发者指南 #72 #73\n ModuleController 各项参数校验\n replicas = -1 表示对等架构\n Arklet\n 服务的跨 Spring Context 发现与调用\n 健康状态检查方案 review\n 增加影响基座健康状态的能力，查询健康状态指令模块安装支持远程协议\n 【spring-boot-ark-plugin】#74\n 【Arklet】指令耗时统计和资源消耗统计设计 #77\n Arkctl\n Arkctl 增加模块对应实例与状态查询\n Arkctl 增加模块代码初始化能力 #83\n Arkctl 增加模块部署能力 #82\n Arkctl、Arklet、ModuleController 0.5 发版本\n 「SOFAServerless」：https://github.com/sofastack/sofa-serverless/issue/100\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：09 月 13 日 14:00 - 15:00\n会议内容：\n 项目规划方向补充\n Wasm 组件的规划 资源隔离 开源之夏\n Dapr component 升级的讨论 集成 K8s 注入的进度分享和思路讨论 CSDI Summit 社区成员分享同步\n add uds support for Java SDK 的同步\n 「Layotto」：https://github.com/mosn/layotto/issues/989\n「会议回放」：https://www.bilibili.com/video/BV1UF411D77o\nSOFAStack 社区本周贡献 本周推荐阅读 SOFABoot 4.0 正式发布，多项新特性等你来体验！\n蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata-DTX｜分布式事务金融场景案例介绍\nSOFARegistry | 大规模集群优化实践\n","date":1694761200,"description":"SOFA Weekly｜SOFAServerless 社区会议预告、Layotto 社区会议回顾与预告、C 位大咖说","dir":"blog/sofa-weekly-20230915/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa9ec5c3db35fbfd01dcafbf949b707b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230915/","publishdate":"2023-09-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230915/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议预告、Layotto 社区会议回顾与预告、C 位大咖说","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230915/","wordcount":1262},{"author":null,"categories":"SOFAStack","content":" 文｜王勤龙（*花名：长凡*）\n蚂蚁集团 AI 系统工程师\n文｜张吉（*花名：理之*）\n蚂蚁集团 AI 系统工程师\n文｜兰霆峰\n四川大学 20 级计算机系\n本文 5104 字 阅读 13 分钟\n01 背景 如今大语言模型（*LLM*）的分布式训练节点规模越来越大，训练耗时长。比如 OpenAI 在 1024 个 NVIDIA A100 GPU 上训练 GPT-3 大约需要 34 天。训练节点越多，耗时越长，训练期间节点故障概率就越大，况且 A100 GPU 的故障率也相对较高。所以大规模训练作业难免会遇到节点故障。据我们在蚂蚁 GPU 训练集群上观察，一个月内，单卡的故障率约 8%，那么一天单卡的故障率约为 0.27%。常见的故障原因有 Xid、ECC、NVLINK error 和 NCCL error 故障等。对于一个千卡训练作业来说，卡故障导致一天内训练失败的概率高达到 93%。所以训练作业几乎每天都会失败。作业失败后，用户需要手动重启作业，运维成本很高。如果用户重启不及时，中间间隔的时间就会导致 GPU 卡空闲，浪费昂贵的算力资源。\n有些故障会导致机器不可用，从而导致可用节点数量不能达到用户指定的数量。这时，训练就不能启动，用户需要手动减少节点数量后重新提交作业。待故障机修复后，用户又需要手动增加作业的节点数来重启作业。这样增大了用户的运维成本，也导致了新节点无法及时加入训练。\n为此，DLRover 在 Kubernetes 上基于 Torch Elastic 开发了弹性训练功能，实现 PyTorch 分布式训练的自动容错和弹性。具体功能如下：\n 出现故障后，快速执行节点健康检测，定位故障机并将其隔离，然后重启 Pod 来替换故障节点。\n 健康检测通过后，重启训练子进程来自动恢复模型训练，无需重启作业或者所有 Pod。\n 节点故障导致可用机器少于作业配置，自动缩容来继续训练。集群新增机器后，自动扩容来恢复节点数量。\n 优化 FSDP 并行训练的模型 save/load，支持根据实际卡数 reshard 模型参数，缩短 checkpoint 保存和加载时间。\n 在 DLRover 弹性容错应用在蚂蚁大模型训练前，一周内千卡训练运行时间占 60.8%，有效训练时间约 32.9%（*有效训练时间=模型迭代的步数*每步的时间*）。除此之外，训练运行时间还包括 checkpoint 保存时间和训练回退时间等。DLRover 上线后，一周内千卡训练运行时间占比提升至 83.6%，有效训练时间提升至 58.9%。\n02 PyTorch 弹性训练框架 弹性训练是指在训练过程中可以伸缩节点数量。当前支持 PyTroch 弹性训练的框架有 Torch Elastic 和 Elastic Horovod。二者显著的区别在于节点数量变化后是否需要重启训练子进程来恢复训练。Torch Elastic 感知到新节点加入后会立刻重启所有节点的子进程，集合通信组网，然后从 checkpoint 文件里恢复训练状态来继续训练。而 Elastic Horovod 则是每个训练子进程在每个 step 后检查新节点加入，子进程不退出的情况下重新集合通信组网，然后有 rank-0 将模型广播给所有 rank。二者的优劣对比如下：\n通过上述对比可以看出，Torch Elastic 重启训练子进程的方案对用户更加友好，支持更多的分布式训练策略和模型。而 FSDP 和 NCCL 是当前大模型分布式训练使用最为广泛的技术。所以 DLRover 选择使用 Torch Elastic 重启子进程的方案来实现 Kubernetes 集群上分布式训练的弹性容错。\n03 集合通信动态组网 动态组网是指训练进程可以自动根据动态变化的节点数量来组网集合通信，无需固定给各个节点指定集合通信的 rank 和 world size。动态组网是弹性容错训练必须的，因为弹性容错作业中，节点的失败、扩容或者缩容都会导致节点的 rank 和 world size 变化。所以我们无法在作业启动前给节点指定 rank 和 world size。\nTorch Elastic 动态组网 Torch Elastic 启动子进程后，所有子进程需要进行集合通信组网。Torch Elastic 使用 Dynamic Rendezvous 机制来协助子进程组网。每个节点上运行一个 ElasticAgent，ElasticAgent 会从一个共享存储中获取作业节点的 host group，然后将自己的 host 加入 group 并同步到共享存储里。这个共享存储当前默认使用 TCPStore。接着，ElasticAgent 不断从共享存储里获取查询 host group，直到 host group 里的节点数量达到最小节点数量 min_nodes 且一段时间内没有变化，即认为所有节点都准备好了。然后，ElasticAgent 就可以从 host group 里获取自己的节点 rank（*PyTorch 中称为 group rank*）和 world size。这样，ElasticAgent 就可以给拉起的子进程配置 local rank、global rank 和 world size 了。有了这些信息，子进程就可以进程集合通信组网。\n但是使用 Torch Elastic 原生方案中，我们发现一些问题：\n 节点不能容错。TCPStore 在一个训练节点上，如果该节点挂了，重组网就没法继续了。\n 节点 rank 是随机的。ElasticAgent 同步 host 到共享存储的顺序是随机的，导致节点 rank 的随机。在训练代码中，用户一般会将模型迭代信息输出在 rank-0 的日志里，比如 step、loss 和耗时等。用户只能通过进程日志寻找 rank-0 ，对于多节点的作业，这是比较麻烦的。\n Torch Elastic 的动态组网不能控制组网的节点数量。比如 LLM 模型训练中，用户可能会将 4 个节点作为一个数据预处理的组，那么弹性伸缩需要保证节点数量是 4 的整数倍。而 Torch Elastic 只要发现有一个新节点加入就会立刻重启训练。  DLRover 动态组网 针对上面问题，DLRover 重新实现了 PyTorch ElasticAgent 的动态组网模块 RendezvousHandler，利用 ElasticJob 点 Master 来协助 PyTorch 组网。Master 是一个纯 CPU 节点，不参与训练，稳定性比 GPU 节点高很多。\n（DLRover ElasticJob 动态组网）\nDLRover 的 ElasticJob 在启动 Pod 时，会给每个 Pod 一个唯一的编号 Pod ID 并配置到 Pod 的环境变量里。训练节点的 ElasticAgent 的 RendezvousHandler 会将自己的编号 Pod ID 和 GPU 卡数上报给 Master 的 Rendezvous Manager。然后不断从 Master 中请求通信 world，即所有节点的信息。Master 的 Rendezvous Manager …","date":1694502000,"description":"DLRover 在 K8s 上千卡级大模型训练稳定性保障的技术实践","dir":"blog/dlrover's-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9873bd3dccef5853a61dc3c706403d5d","permalink":"https://sofastack.github.io/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","publishdate":"2023-09-12T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","summary":"文｜王勤龙（*花名：长凡*） 蚂蚁集团 AI 系统工程师 文｜张吉（*花名：理之*） 蚂蚁集团 AI 系统工程师 文｜兰霆峰 四川大学 20 级计算机系 本文 5104 字 阅读 13 分","tags":["SOFAStack"],"title":"DLRover 在 K8s 上千卡级大模型训练稳定性保障的技术实践","type":"blog","url":"/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","wordcount":5172},{"author":null,"categories":"SOFAStack","content":" 1. 前言 本文是支付宝资金技术团队在《大象转身-支付宝资金技术交付提效之路》系列总结之一。如果你正在负责一个所支撑的业务面临从平台到场景化创新的发展阶段，希望通过提升交付效率来提升技术团队的竞争力和团队研发幸福感， 那么这篇文章也许会让你有收获：\n Serverless 的技术理念是什么？对业务研发有什么借鉴意义？\n 如何基于 Serverless 驱动研发模式的升级，设计一个能让场景化创新快起来的技术架构，提升全局研发效率？\n 本篇作者：呆莫（代巍）、歆明（何鑫铭）\n文章较长，建议收藏和保存\n为什么写这篇文章 我们做了近两年的 Serverless 研发模式的探索和落地，目前该模式已经承接了大部分资金业务的场景，平台也已经进入推广期，有 20+ 团队经过 SOFAServerless 技术团队的介绍找到我们。未接入 SOFAServerless 的想从业务视角寻求架构选型依据和应用架构设计，已接入 SOFAServerless 的同学来寻找基座治理经验。因此决定写一篇文章，将我们的架构选型、设计和落地经验做一次完整的总结。\n2. 我们遇到的问题 我们的问题：随着场景创新增多，SOFA 应用变臃肿、团队研发人数变多导致研发和运维难度升高，阻碍了业务创新的交付效率，系统需要做重构。\n简单说说背景 资金在这两年时间，肩负了很多业务创新、寻找业务增量的目标。增量时代的创新是残酷的，成功的明星产品背后，是无数次的失败（这三年间，技术支撑了 15+ 个创新产品的建设，包括小程序、行业解决方案）。而支付团队转型做创新也面临着巨大的挑战：动辄 1-2 个月起的研发交付周期，在当时使得技术团队被按在地上摩擦，各种问题接踵而来。\n蚂蚁集团 CTO 苗人凤曾经说过，创新是九死一生，技术就是要帮助业务降低机会成本。\n我们逐渐意识到业务创新的快速发展，一定离不开业务快速交付的新型技术研发模式。如果我们还是沿用平台化的架构思路，在一个庞大的资金平台上写一堆创新场景的代码，在完成业务需求的同时还要思考如何抽象、如何保障增量的代码不影响平台稳定性，那一定快不了。\n2021 年，我们成立“资金场景创新提效项目”，试图通过平台架构升级、研发模式升级解决场景创新效率问题。\n问题定义：资金场景应用变成巨石应用带来一系列问题 试着代入一下案例：\n如果有那么 5 个创新业务迭代在同一个应用发布窗口进行推进，会存在各种各样导致延期的原因:\n1、A 业务验证延后 2 天，那么 5 个迭代都要延后 2 天；\n2、B 业务升级了中间件版本，那整个应用的业务都面临回归成本一样要延后整个发布期；\n3、C 业务想要在预发搭个车微调一些代码，但是由于动作慢没能成功验证，导致污染了主干，进而耽误了整体；\n……\n 在应用架构层面，资金部门早期孵化出了一个“大资金场景层应用”——Fundapplication。Fundapplication 在研发协作方面，从一开始的几个同学，到后来几个业务团队、几十个研发同学，都在一个应用系统上研发，通过多个 bundle 区分不同业务，公共的 bundle 沉淀通用能力和研发工具（*类似于之前的 mng 系统*），如下图：\n这种架构设计在遇到大量的彼此没有复用的业务创新需求时，就逐步沦为了巨石应用，如下图：\n1、研发运维效率低：作为入口系统，mgw 接口无法在本地开发自测，改动任何代码必须发布到联调环境。发布一次需要 10 分钟以上，还要忍受环境不稳定因素带来的额外时间花费。\n2、业务迭代抢占，协同成本高：系统作为创新应用系统，有 10+ 个创新产品，30+ 个正式员工和外包员工也在这个系统上做研发迭代，火车式发布迭代痛点明显——一人晚点，全体延期。\n3、研发时隔离效率低：30+ 研发同学（含外包）在一个系统内研发，经过不到一年的时间，我们的系统就变成 10+ 个 bundle、2w+ 个 Java 文件（*全站均值 4000*）的体量了，因为各种业务的各种依赖的增加，系统启动一次需要 15 分钟。随着创新场景增多会变得更加糟糕，而且很多代码没有办法随着业务的下线而删除。\n4、运行时不隔离：目前我们没有对不同的业务区分不同的机房，业务吃大锅饭，难以做到按产品的资源和稳定性保障。\n如果你的应用也存在上述问题，对业务创新的交付效率产生了一定的影响，那可以继续参考第 3、4 章我们的架构选型和关键设计。\n3. 应用架构的选型 当前蚂蚁基于 SOFABoot 的应用架构，在规模化创新场景研发的交付效率、分工协作模式上存在局限性。从行业的发展趋势分析，云原生等新技术引领的“集装箱”架构模式，有利于促进规模化的生产效率和分工协作方式。借助蚂蚁 SOFAServerless 的孵化，我们决定作为种子用户，使用 Serverless 中 BaaS+FaaS 的理念，重塑创新场景研发的研发模式。\n微服务应用架构的局限性 大应用创新的模式，是在一个应用系统中按照不同 bundle 来隔离创新应用，可复用的代码可能是放到一个公共的 bundle 中。优点当然是复用效率高，运维统一，缺点主要是协作效率、隔离成本和研发效率。大应用变成巨石应用如何解决？这个我们很容易就想到使用分治的思路，将一个大应用拆成多个应用，通过 RPC 来互相调用。\n在蚂蚁当前体系下，微服务系统的 0-1 成本、后续运维成本、硬件机器成本仍然会是一个不小的开销，创新试错还是快不起来。且后端业务创新具有巨大的不确定性，如果因为业务没量了变成长尾系统下线的成本也很高；在性能方面，多个系统间通用能力的调用，会使全链路的调用耗时增加，在业务上不可接受。所以有没有一种技术，可以让业务既能够隔离，又能够降低隔离带来的负向影响：运维成本、能力复用效率、性能？\n行业技术架构的发展趋势 一部分做架构的同学喜欢用“架构隐喻”来介绍架构的理念。近几年容器化、云原生、Serverless 等新技术层出不穷，作为架构师需要在对新技术保持敏感的同时，能够有一双洞察架构本质的眼睛。\n这些底层新技术的出现，本质上是通过抽象定义“集装箱”的方式，规范了构建、部署、运行、运维标准，提升了软件的生产效率。大家可以感受一下这些技术底层理念的相通之处：\n Docker 通过定义容器“集装箱”提升传统虚拟机、基础设施软件构建、运维效率；\n K8s 进一步抽象万物皆可定义为 CRD（*自定义资源*）提升“集装箱”的部署、运维效率；\n 中间件 Mesh 化将“集装箱”理念应用到中间件近端，将中间件近端与业务代码剥离解耦；\n BaaS、FaaS 等 Serverless 技术，将“集装箱”理念范围进一步扩大到可复用的“业务领域插件”。\n 可以这么说，集装箱改变世界航运效率，计算机软件行业的 Docker、K8s 们通过“集装箱”的架构理念改变了基础软件生产效率。而随着 Serverless 的兴起，“集装箱”的架构理念将会自底向上地，重塑对软件交付效率重度依赖的互联网、金融等行业。\n我们来看下，集装箱的理念对我们业务研发的启示：\n过去，业务研发需要关注独立的业务应用，既需要关注业务代码、中间件代码等代码信息，又需要关注 Java 进程、CPU、内存等运维信息，随着这两年蚂蚁 MOSN 等 Service …","date":1693897200,"description":"大象转身：支付宝资金技术 Serverless 提效总结","dir":"blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","fuzzywordcount":12500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d09a365280bac8113c2d8e53309c4911","permalink":"https://sofastack.github.io/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","publishdate":"2023-09-05T15:00:00+08:00","readingtime":25,"relpermalink":"/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","summary":"1. 前言 本文是支付宝资金技术团队在《大象转身-支付宝资金技术交付提效之路》系列总结之一。如果你正在负责一个所支撑的业务面临从平台到场景化创新的","tags":["SOFAStack"],"title":"大象转身：支付宝资金技术 Serverless 提效总结","type":"blog","url":"/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","wordcount":12433},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAChannel#35 预告 SOFABoot 是蚂蚁集团开源的基于 Spring Boot 的研发框架。近期，SOFABoot 更新了 4.0 版本，带来了更多新特性。不仅正式支持了 Spring Boot 3 版本，也同时做出了包括历史功能演进在内的一系列调整优化，使得框架自身更加易用。\n本期 SOFAChannel#35 邀请到了蚂蚁集团技术专家、SOFABoot 项目 Maintainer 胡子杰跟大家分享 《SOFABoot 4.0 — 迈向 JDK 17 新时代》。\nSOFA 社区会议预告 SOFAServerless：\n主题：SOFAServerless 社区会议\n时间：09 月 04 日 19:30 - 20:30\n入会口令（钉钉）：909 575 00367\n电话呼入：+057128095818（中国大陆） +02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/EQzqQVtJoro\n议题：\n 8月回顾\n Arklet 待完成的动作\n 增加影响基座健康状态的能力，查询健康状态指令\n ModuleController 的功能\n 各项参数校验、单测达到 80/60、8+ 集成测试、CI 自动化、开发者指南\n 各组件的发版 release\n ModuleController 0.3\n Arklet 0.3\n SOFAArk 2.2.2\n 9 月迭代规划讨论\n SOFAArk\n 基座模块 1:1 复用 ClassLoader\n 支持 SOFABoot 4\n SOFAServerless\n 支持中间件列表与优先级，排摸支持情况，设计评测标准\n 基座 Starter，Arklet 的打包发布\n ModuleController\n 新扩后缩\n 模块回滚\n 模块流量 Service\n Arklet\n 服务的跨 Spring Context 发现与调用\n Arkctl、Arklet、ModuleController 0.5 发版本\n 「*SOFAServerless*」：https://github.com/sofastack/sofa-serverless/issues/44\nLayotto：\n主题：Layotto 社区会议\n时间：09 月 06 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+02162681677（中国大陆）+057128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/MkM4YQVrEE3\n议题：\n Layotto 项目规划和展望 #976\n 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959\n Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\n Develop a new component for sms API；为“短信 API”开发新的组件 #830\n 「*Layotto*」：https://github.com/mosn/layotto/issues/984\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：08 月 30 日 14:00 - 15:00\n会议内容：\n 下半年规划与展望\n SDK 模式、公有云部署的两个方向明确 开源之夏\n Layotto K8s 集成：关于动态配置注入思路的讨论\n 短信邮件 API：API 适配不同云厂商的组件具体开发\n 「*Layotto*」：https://github.com/mosn/layotto/issues/984\n「*会议回放*」：https://www.bilibili.com/video/BV1bz4y1K7RG\nSOFARPC 5.11.0 版本发布 发布 SOFARPC 5.11.0 版本，主要变更如下:\n 支持 SOFARPC 在 Mac M1 芯片环境编译\n 修复直连调用时，url 拼接错误的问题\n 升级 Hessian 到 3.5.0\n 升级 Bolt 到 1.6.6\n 升级 gRPC 到 1.53.0\n 升级 SOFARegistry 到 6.3.0\n 升级 Dubbo 到 3.1.8\n 升级 Javassist 到 3.29，引入新版 API，支持在 JDK 17 环境下使用\n 解决部分 SOFABoot 4.0 下的兼容性问题，现在 SOFARPC 支持基于 SOFABoot 4.0 运行\n 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.11.0\nSOFAHessian 3.5.0 版本发布 发布 SOFAHessian 3.5.0 版本，主要变更如下:\n 新增了 Currency、 Atomic、Throwable、StackTraceElement 类的定制序列化器，支持在 JDK 17 环境下运行\n 针对内部的反射逻辑做了一定的调整，支持在 JDK 17 环境下运行\n 详细发布报告：https://github.com/sofastack/sofa-hessian/releases/tag/v3.5.0\nSOFAStack 社区本周贡献 本周推荐阅读 SOFABoot 4.0 正式发布，多项新特性等你来体验！\n蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata-DTX｜分布式事务金融场景案例介绍\nSOFARegistry | 大规模集群优化实践\n","date":1693551600,"description":"SOFAChannel#35 直播预告、SOFARPC/SOFAHessian 新版本发布、社区会议","dir":"blog/sofa-weekly-20230901/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4506495f5728921c30461c2adf82271f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230901/","publishdate":"2023-09-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230901/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAChannel#35 直播预告、SOFARPC/SOFAHessian 新版本发布、社区会议","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230901/","wordcount":1753},{"author":null,"categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区 活动时间：09 月 07 日，周四晚 19 点 活动形式：线上直播 资料下载： 点击获取 B 站直播间地址：http://live.bilibili.com/21954520 B 站直播回放：SOFAChannel#35 介绍 | SOFAChannel SOFA:Channel 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\nSOFA:Channel 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\nSOFABoot 项目简介 SOFABoot 是蚂蚁集团开源的基于 Spring Boot 的研发框架，提供了诸如 Readiness Check、模块化和日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\n近期，SOFABoot 更新了 4.0 版本，带来了更多新特性。不仅正式支持了 Spring Boot 3 版本，也同时做出了包括历史功能演进在内的一系列调整优化，使得框架自身更加易用。\n本期 SOFAChannel#35 邀请到了蚂蚁集团技术专家、SOFABoot 项目 Maintainer 胡子杰跟大家分享 《SOFABoot 4.0 — 迈向 JDK 17 新时代》。\n直播介绍 《SOFABoot 4.0—迈向 JDK 17 新时代》\n2023 年 9 月 7 日（周四）\n19：00 - 20：00\n「嘉宾简介」\n胡子杰（*花名：致节*）\n蚂蚁集团技术专家\nSOFABoot Maintainer\n「议题简介」\n本次分享将主要介绍 SOFABoot 4.0 新版本引入的新特性与变化，包括其设计理念与实现方式。再者就是介绍 SOFABoot 3 应用如何升级至 SOFABoot 4.0 版本，并展望 SOFABoot 未来的发展趋势。\n「听众收获」\n SOFABoot 4.0 的新特性与变化； 已有应用如何升级至 SOFABoot 4.0 版本； 一起探讨 SOFABoot 未来发展的趋势。 直播回放 点击查看\n了解更多技术干货 使用钉钉搜索群号：44858463 ，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1693465200,"description":"SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》","dir":"activities/sofa-channel-35/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"94eeffb4d40ce60a8be76d1892342c40","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-35/","publishdate":"2023-08-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-35/","summary":"概要 活动主题：SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区 活动时间：09 月 07 日，周四晚 19 点 活动","tags":["SOFAChannel"],"title":"SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-35/","wordcount":704},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题：Layotto 社区会议\n时间：08 月 30 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+057128095818（中国大陆）+02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/Wv0wyrJyDhA\n议题：\n Layotto 项目规划和展望 #976\n 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959\n Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\n Develop a new component for sms API；为“短信 API” 开发新的组件 #830\n 「*Layotto*」：https://github.com/mosn/layotto/issues/983\nSOFA 社区会议回顾 SOFAServerless：\n主题：SOFAServerless 社区会议\n时间：08 月 21 日 19:30 - 20:30\n会议内容：\n 8月回顾\n Arklet 待完成的动作\n 增加影响基座健康状态的能力，查询健康状态指令\n 健康状态检查方案 review\n 模块安装支持远程协议\n 修复 ModuleController 使用 Arklet 遇到的问题 #17\n 增加锁控制 #39\n 基座引用的 starter，支持 Spring Boot、SOFABoot，推到 Maven 中央仓库\n 9 月迭代规划讨论\n 支持中间件列表与优先级\n 支持 SOFABoot 4.0\n 回滚，先扩后缩，模块流量 Service\n Arkctl Arklet ModuleController 0.5 发版本\n 「*SOFAServerless*」：https://github.com/sofastack/sofa-serverless/issues/38\n「*会议回放*」：https://www.bilibili.com/video/BV19r4y1R761\nLayotto：\n主题：Layotto 社区会议\n时间：08 月 23 日 14:00 - 15:00\n会议内容：\n Layotto 社区下半年规划\n 开源之夏\n 自定义插件：等待同步动作\n 集成 K8s\n 此前遗留问题的讨论、动态配置的思路\n 在 K8s 上已跑通的 demo 分享\n 短信 API\n API 已完成，关闭 issue，将跟进开发各自组件\n 「*Layotto*」：https://github.com/mosn/layotto/issues/983\n「*会议回放*」：https://www.bilibili.com/video/BV15j411q7As\nSOFAStack 社区本周贡献 本周推荐阅读 蚂蚁 SOFAServerless 微服务新架构的探索与实践\n超越边界：FaaS 的应用实践和未来展望\nMoE 系列（七）｜ Envoy Go 扩展之沙箱安全\nSeata-DTX｜分布式事务金融场景案例介绍\n","date":1692946800,"description":"SOFAServerless 社区会议回顾、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-20230825/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"25a1f7a1856d6b2d7c1f7c87dd47da64","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230825/","publishdate":"2023-08-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230825/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议回顾、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230825/","wordcount":1130},{"author":null,"categories":"SOFAStack","content":" 作者简介 赵真灵（有济）\n蚂蚁集团技术专家，Serverless 和微服务领域专家\n曾负责基于 K8s Deployment 的应用发布运维平台建设、K8s 集群的 Node/pod 多级弹性伸缩与产品建设。当前主要负责应用架构演进和 Serverless 相关工作。同时也是 SOFAArk 社区的开发和维护者以及 KNative 社区的贡献者。\n本文 3612 字，预计阅读 12 分钟\n传统微服务架构面临的问题和挑战？ 应用架构从单体应用发展到微服务，结合软件工程从瀑布模式到当前的 DevOps 模式的发展，解决了可扩展、分布式、分工协作等问题，为企业提供较好的敏捷性与执行效率，给企业带来了明显的价值。但该模式发展至今，虽然解决了一些问题，也有微服务自身的问题慢慢暴露出来，在当前已经得到持续关注：\n1、业务开发者需要感知复杂的基础设施，启动慢（*分钟级*），研发效率低，运维负担重：\n对于基础设施的问题，在服务网格和应用运行时的工作已经取得了一定的成果，但是基础设施到业务开发之间还存在业务通用的部分，这里当前没有一个模式来给予支持。\n当前已经有一些开源项目在尝试解决基础设施的问题，例如服务网格、应用运行时，如 Dapr/Layotto，也都在实际应用中得到了不错的效果。但当前服务网格和应用运行时更多的是将中间件以下下沉到 sidecar，而一个应用一般还包括通用的业务逻辑部分，要让更广泛的业务也能享受到无基础设施的体感，也需要让业务以下（*可以把业务层以下的看作基础设施*）都能屏蔽。另外当前对于中小企业来说，使用服务网格和应用运行时的成本还是比较高的。\n2、拆分微服务的资源与维护成本高：\n拆分后每个子应用都包含公共部分（*框架、中间件等*），除了同样存在上述第一个问题之外，还需要独占机器资源成本高，如果部分业务萎缩，会面临长尾应用问题，需要承担长期维护的成本。\n3、拆分微服务的敏捷度与业务、组织发展的敏捷度不一致，导致如何合理地拆分微服务始终是个老大难的问题：\n 拆得多增加了资源和管理成本； 拆得不够造成协作效率问题。有些是应该拆但没拆，有些是因为业务领域已经较为细分不便再拆，特别在一些中小企业里，可能都没有微服务的配套设施。 蚂蚁的解决思路和方案 为了解决这些问题，我们对应用同时做了横向和纵向的拆分。纵向拆分：把应用拆分成基座和模块两层，这两层分别对应两层的组织分工。基座小组与传统应用一样，负责机器维护、通用逻辑沉淀、模块架构治理，并为模块提供运行资源和环境。模块在业务层以下所有的基础设施、应用框架、中间件可以不再关注，聚焦在业务逻辑研发本身；并且采用 jar 包的研发模式，具备秒级的验证能力，让模块开发得到极致的提效。\n这可以理解为这套架构的核心模型，核心的能力有两个：平台化 + 模块化。模块化是 20 年前 OSGI 就已经提出的概念，从 OSGI 到 JPMS 一直未被抛弃，到最近 Spring Modulith、Service Weaver 等行业里又兴起一些开源框架，它一直在发展；平台化从 2017 年出现在技术雷达到 2023 年被 Gartner 列为十大战略趋势之一，到现在国内的平台工程，不断得到重视和发展。而我们实际上在行业还没有对这两个技术方向充分关注的情况下，就在尝试把他们结合起来，并在蚂蚁内部得到规模化验证和落地，给业务带来极致的降本增效效果。\n该模式的另一个特点是可演进、可回滚。这里的模块随着业务发展壮大，可以独立部署成微服务；如果微服务拆分过多，可以低成本改造成模块，合并部署在一起，解决资源成本和长期维护成本。实际上可以理解为我们是在单体应用架构和传统微服务架构中间，增加了一个可以演进过渡的架构。\n总结下来这套新微服务架构可以解决这四个问题：\n1、横向拆分出基座屏蔽业务以下的基础设施、框架、中间件和业务通用逻辑等部分，从而极大降低了业务开发者的认知负荷、提高了开发效率。\n2、一个应用可以低成本改造或拆分出多个模块，模块间可以并行独立迭代，从而解决了多人协作阻塞问题，每个模块不单独占用机器资源，没有拆分的机器成本问题。\n3、存量微服务如果拆分过多，可以低成本改造成模块应用，合并部署在一起，解决拆分过多带来的资源成本和维护成本痛点。\n4、模块可以灵活部署，解决微服务拆分与组织发展灵敏度不一致导致的协作低效与分工不合理问题。应用拆分出多个模块，可以部署在一起，也可以进一步演进成独立微服务，同样如果微服务拆分过多，也可以低成本改回模块合并部署到一起。\n这里卖个关子——为什么这些技术在蚂蚁能规模化落地？存量的业务 owner 在业务迭代进度和升级新架构之间做权衡时，我们做了哪些工作？ 欢迎来到 9 月 3 号 QCon 大会现场获得更详细的信息。\n在采用新的微服务架构模式后的成果 举个当前蚂蚁实际业务采用新模式前后的对比数据：\n可以看到这些数据是十倍级以上的提升，当前蚂蚁所有 BU 都已经接入，将近 40W core 的在线业务，并为两种业务模式：中台模式和轻应用模式的业务都提供秒级研发运维的能力。一个基座上面最多有上百个模块，一个开发同学在研发验证阶段，一下午可以验证上百次，需求的交付效率最快可以到小时级别。\n在当下行情下，新技术落地的挑战与蚂蚁的思路 当前行情下，企业对新技术会更加谨慎，技术人也对新技术采取保守态度。新技术虽然很酷，但投入大落地场景有限。这其实是发展过程的转换，在高速发展的行情下，一方面是历史包袱少，另一方面是乐观态度占据主导，更加相信新技术能较快得到规模化落地，整个社会都对新技术充满热情。而在当下阶段，很多企业已经有一定的历史包袱，时间证明新技术规模化落地需要很长的周期，需要整个体系一起演进才可能达到最初的预想，可能也会带来越来越繁复的基础设施，所以当前行业对新技术更加偏保守也是非常合理的。\n所以蚂蚁在建设这套微服务新架构时，有一个非常关键的设计思路，那就是要接地气或者是可演进，也即是要让存量业务能低成本接入。这也是最初蚂蚁在落地该模式时踩过的最大的坑：一个普通应用转换成基座需要花费上月时间（*包括流量迁移*），模块研发与现有基础设施不匹配导致模块研发成本也很高，这个问题在当时也影响了该模式的生死存亡。后来蚂蚁在这块上投入了很大精力，最终让普通应用在小时内可以成为基座或模块，研发模式也与普通应用基本一致。\n经过这个过程，最终低成本、可演进也成为了该模式的一个核心优势。未来对外开源，我们会把接地气做得更加彻底，不对企业的基础设施程度有预设条件：\n 无需容器化也可以接入； 无需使用 K8s 平台也可接入； 无需具备微服务配套设施可也接入； 无需服务网格化也可接入。 微服务新架构落地实战中遇到的更具体的困难和挑战 我们做的这套模式在行业内没有先例，相当于是在无人区里摸索，因此面临多方面的挑战：\n1、关于模块化技术的质疑：为什么现在模块化技术又开始被关注？为什么我们基于 SOFAArk 的模块化技术能推广？挑战主要集中在如何制定合理的隔离和共享通信策略，我们需要避免 OSGI 之类的复杂度问题，做到可以低成本使用。\n2、模块化技术采用了多 ClassLoader，对于 ClassLoader 的隔离、卸载不干净等问题，我们一步一个脚印，深入并体系化 …","date":1692687600,"description":"蚂蚁 SOFAServerless 微服务新架构的探索与实践","dir":"blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b76d3b366c9f1902b9a16c8792999967","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","publishdate":"2023-08-22T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","summary":"作者简介 赵真灵（有济） 蚂蚁集团技术专家，Serverless 和微服务领域专家 曾负责基于 K8s Deployment 的应用发布运维平台建设、K8s 集群的 Node/pod 多级弹性伸缩","tags":["SOFAStack"],"title":"蚂蚁 SOFAServerless 微服务新架构的探索与实践","type":"blog","url":"/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","wordcount":4058},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题： Layotto 社区会议\n时间： 08 月 23 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入：+057128095818（中国大陆）+02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/KPX3eRflTbk\n议题：\nLayotto 项目规划和展望 #976\n2023 开源之夏-课题汇总 #894\nOSPP | Layotto 支持 Pluggable Component 组件 #959\nSupport Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\nDevelop a new component for sms API；为“短信 API”开发新的组件 #830\nDiscuss: whether the sms API definition needs to be modified；讨论一下是否需要修改 sms API 定义 #966\n「Layotto」：https://github.com/mosn/layotto/issues/981\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：8 月 16 日 14:00 - 15:00\n会议内容：\nLayotto 公有云部署想法、下半年产品演进路线讨论分析；\n开源之夏进展同步：\n可插拔插件初步方案的讨论；\nK8s 集成注入位置确认、Dapr 注入的实现方案讨论；\n短信 API 适应不同场景的设计方案\n「Layotto」：https://github.com/mosn/layotto/issues/981\n「会议回放」：https://www.bilibili.com/video/BV1wX4y1E7KQ/\nSOFAStack 社区本周贡献 本周推荐阅读 超越边界：FaaS 的应用实践和未来展望\nMoE 系列（七）｜ Envoy Go 扩展之沙箱安全\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\nSeata-DTX｜分布式事务金融场景案例介绍\n","date":1692342000,"description":"SOFA Weekly｜Layotto 社区会议回顾与预告、SOFA 茶水间、社区本周贡献","dir":"blog/sofa-weekly-20230818/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f1f84d7ed240f62b5ec5da285c349dd4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230818/","publishdate":"2023-08-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230818/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜Layotto 社区会议回顾与预告、SOFA 茶水间、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230818/","wordcount":828},{"author":null,"categories":"SOFAStack","content":" 作者简介 邢奇（薯片）\n蚂蚁集团技术专家，云原生和 Service Mesh 领域专家\n长期从事服务治理和服务发现等相关领域的研究和实践，在 RPC 框架（*Dubbo、Spring Cloud 和 SOFARPC 等*）方面有源码级的研究和贡献；在 Service Mesh、云原生、容器和 K8s 等方面有深入的研究和实践经验。\n参与了多个开源项目的贡献，包括 MOSN、SOFA、Dubbo 和 Nacos 等。目前担任蚂蚁云开发技术负责人，负责支付宝云开发产品的研发和实践。\n本文 5689 字，预计阅读 16 分钟\n概述 什么是 FaaS ？\n在 ChatGPT 里面输入 FaaS 关键字，得到的结果是：*FaaS 是一种云计算服务模型*。它允许开发者编写和部署函数，而不需要管理底层基础设施的运行，即 Function as a Service。\n同时通过 ChatGPT 可以生成对应的函数代码——\nFaaS 的崛起 FaaS 的理念和函数研发模式，为传统的应用模式解决了许多问题，有着超前的优势。\n传统应用模式的困境 在研发态，不管是单体应用还是微服务应用，亦或是 Mesh 架构或者应用运行时，在研发态，开发者除了要关注业务逻辑本身之外，经常会被中间件所打扰，需要配合去做 SDK 升级改造，性能或者功能优化等。同时在使用云产品或者云服务的时候，需要被迫去感知多云的差异。\n在运维态，开发者面临着更重的运维压力。当一个应用上线，开发者需要对这个业务的未来发展进行一个复杂且不确定的容量评估，再去为这个容量去申请对应的资源，最后经过一个复杂的上线流程进行发布。在发布结束之后，开发者还得时刻关注线上流量的变化，去进行不断的扩容和缩容的调整。\n总而言之，整个中间件和基础设施对开发者的打扰是非常严重的：\n 应用研发模式的代码耦合严重，复杂度高； 运维流程繁琐，效率低； 容量评估一般很难符合真实情况，线上的资源利用率一般都较低，存在着浪费。 于是 FaaS 函数的研发模式应运而生。\n可以很直观地看到，在传统应用和微服务应用的改造和优化的基础之上，FaaS 希望做得更进一步，更面向未来。以函数为编程对象，用户无需关注应用、机器等数据和基础设施信息。\n通过这样的改变，大大提升研发效能，做到快速开发；并且提高运维效率，提供一站式免运维的 Serverless 平台；最后，函数会随着流量进行创建和销毁，最终降低成本和资源的消耗。\nFaaS 使用场景 尽管 FaaS 具有许多优势，但并非所有场景都适合采用函数编程模式。下面介绍一些 FaaS 适用的普遍场景：\n1、BFF 的场景。 即一些胶水代码（*对接多个接口、进行数据的组装和适配等*）。胶水代码的逻辑相对简单，但同时需求变化快、生命周期短。对应的应用场景如运营/营销活动等。活动结束之后，就不再有流量进入，也没有必要再进行代码和机器的维护。\n2、事件驱动的场景。 例如音视频转码，用户上传文件触发任务，或者通过消息触发调度，或者业务上有明显的波峰和波峰的流量特征。\n3、中台型业务。 例如算法平台的算子。算子计算是非常独立的业务逻辑，但是参与的研发人数非常多，逻辑相对来说不可控，需要有更高的隔离能力。\nFaaS 落地面临的技术问题 FaaS 技术产品的落地，可能会面临以下问题和挑战：\n性能问题：\n1、在传统的微服务架构下，开发者会为 RPC 调用性能进行了大量的优化；在 FaaS 的场景，也需要保证函数调用的性能。\n2、弹性扩缩容的反应时效性。很多 FaaS 产品会采用弹性的模型去采集 CPU、QPS 并发等指标，再通过平台去计算指标，进而进行一些扩容和缩容的操作，时效性很低。\n3、函数启动的速度。函数启动的速度在 FaaS 场景中至关重要，函数容器的创建和启动不仅仅是发布态的事情，而是一个数据面流量的依赖。\n安全问题：\n1、想要充分地利用计算资源以降低成本，其必要的前提就是有效地利用和隔离资源。\n2、代码容器。用户的函数代码跑在容器里面，防止容器逃逸就是重中之重。\n3、相较传统的编程模型而言，FaaS 的编程模型到底是如何屏蔽中间件以及云服务的干扰的呢？\n蚂蚁 FaaS 技术架构 蚂蚁在 FaaS 实践之初设定了 3 个 FaaS 技术架构实践的基本原则。\n原则 1：流量模型。 蚂蚁的函数容器是随着流量进行创建和销毁的，而不是通过指标数据进行分析的弹性模型。\n原则 2：函数冷启动。 尽管有 Warm Pool 或者 cache 技术可作选择，但为了最大程度降低成本和利用资源，蚂蚁将目标定为 100ms 以内的极致的冷启动。\n原则 3：安全隔离。 用户的函数都跑在我们的容器里面，因此必须保证高水位的安全隔离特性。\n其实，蚂蚁在实践 FaaS 技术架构时，有一个总的原则就是 one request per instance—极致的情况下，是创建一个函数容器去处理一个请求，类似编程模型创建一个线程去处理一个请求。在这里，创建函数容器就相当于创建一个线程，具有相似的快速、消耗低的优点，同时还有线程所不具备的安全隔离特性。\n架构说明 组件介绍和功能说明 函数网关：负责对函数请求进行转发和控制，并为每一个请求发起一次容器调度任务。\n容器调度引擎：负责对容器进行调度，维护容器的整个生命周期，并且可以对函数容器进行并发度和复用等状态控制，同时也负责管理整个集群的函数 Pod 资源池。（函数 Pod 资源池是函数容器运行的一个环境，一个集群内会有 N 多个 Pod 资源池。 ）\n函数运行时：函数运行时是 OCI 标准的实现，它负责快速地启动函数容器，并对容器的 runtime 进行有效的控制。\n函数容器：函数容器可以理解为是函数运行时+runtime+用户代码的一个运行态，用户的函数代码就跑在函数容器中。\n数据面流量和调度流程说明 从上图可以看到，所有请求都会通过函数网关进入到函数集群，函数网关会发起一次调度任务：通过容器调度引擎 Scheduler 为这一请求快速分配一个 Pod 资源。然后网关就会把这个流量转发给这个 Pod 资源里面的节点网关，节点网关随即缓存对应的请求，并且等待函数容器启动。同时函数节点调度器会并发地创建函数容器并且为容器挂载函数代码。函数容器在启动完成之后，就会立刻作为一个客户端去节点网关上拉取请求，然后进行业务逻辑处理。\n从上述流程中可以看到，蚂蚁 FaaS 场景中的 Serverless 有了第二层含义——no server（*没有 server*）。函数容器永远是作为一个 client 去处理请求。这样的方式从设计上就避免了对基础设施环境的依赖，同时减少了需要去打开一些网络端口、处理网络连接的损耗，也不需要像微服务应用那样去做一些 checkhealth 和 readliness 探针等之后才能进行注册，然后再进行服务发现和调用。\n性能优化实践 函数网关 FaaS 函数网关采用 Go 语言进行编写，网络编程模型是通过一个 go routine 处理一个请求的同步编程，比较符合开发者的习惯。同时由于 Go 语言良好的垃圾回收机制和 GPM 调度模型，网关也有了不错的性能。但是随着业务的不断增长，整个网关在高并发下会出现毛刺现象，P99 长尾也比 …","date":1692082800,"description":"超越边界：FaaS 的应用实践和未来展望","dir":"blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d4e9bc499a9bd2a868c56d990b3f4dc8","permalink":"https://sofastack.github.io/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","publishdate":"2023-08-15T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","summary":"作者简介 邢奇（薯片） 蚂蚁集团技术专家，云原生和 Service Mesh 领域专家 长期从事服务治理和服务发现等相关领域的研究和实践，在 RPC 框架（*Dubbo、Spri","tags":["SOFAStack"],"title":"超越边界：FaaS 的应用实践和未来展望","type":"blog","url":"/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","wordcount":6592},{"author":null,"categories":"SOFAStack","content":" Dragonfly 最新正式版本 v2.1.0 已经发布！ 感谢赵鑫鑫[1]同学帮助重构 Console 代码，并且提供全新的 Console[2]控制台方便用户可视化操作 P2P 集群。欢迎访问 d7y.io[3]网站来了解详情，下面具体介绍 v2.1.0 版本带来了哪些更新。\n功能 Console v1.0.0[4]已经发布，它是一个全新的可视化控制台，方便用户操作 P2P 集群。 新增虚拟网络拓扑探索功能，能够在 P2P 运行时探测节点之间的网络延迟，从而构建一个虚拟网络拓扑结构提供调度使用。 Manager 提供控制 Scheduler 可以提供的服务，例如在 Manager 中设置 Scheduler 不提供预热功能，那么 Scheduler 实例就会拒绝预热请求。 Dfstore 提供 GetObjectMetadatas 和 CopyObject 接口，支持 Dragonfly 作为 JuiceFS 的后端存储。 新增 Personal Access Tokens 功能，用户可以创建自己的 Personal Access Tokens 在调用 Open API 的时候鉴权使用。 Manager REST 服务提供 TLS 配置。 修复当 Dfdaemon 没有可用的 Scheduler 地址时启动失败的现象。 新增 Cluster 资源单位，Cluster 代表一个 P2P 集群，其只包含一个 Scheduler Cluster 和一个 Seed Peer Cluster，并且二者关联。 修复 Dfstore 在 Dfdaemon 并发下载时，可能导致的对象存储下载失败。 Scheduler 新增 Database 配置，并且把之前 Redis 的配置信息移入到 Database 配置中，并且兼容老版本。 在 Dfdaemon 中使用 gRPC 健康检查代替 net.Dial。 修复调度器过滤以及评估过程中 candidateParentLimit 可能影响到调度结果的问题。 修复 Scheduler 中的 Storage 在 bufferSize 为 0 的时候，导致的无法写入下载记录的问题。 日志中隐藏敏感信息，例如 Header 中的一些 Token 信息等。 Manager 中 Scheduler、Seed Peer 等资源删除过程中，不再使用软删除。 Scheduler 数据库表中新增 uk_scheduler 索引，Seed Peer 数据库表中新增 uk_seed_peer 索引。 由于初期功能设计定位不清晰的原因，删除 Security Domain 和 Security 的功能。 Manager 和 Scheduler 新增 Advertise Port 配置，方便用户配置不同的 Advertise Port。 修复 Task 注册阶段状态机状态变更错误的问题。 破坏性变更 不再提供 Scheduler Cluster 和 Seed Peer Cluster 之间 M:N 的关系。提供了 Cluster 的概念，一个 Cluster 即表示一个 P2P 集群，并且一个 Cluster 只包含一个 Scheduler Cluster 和 Seed Peer Cluster，且二者是 1:1 的关联关系。 控制台 更多的关于控制台的内容可以参考官网文档 Manager Console[5]。\nAI 基础设施 Triton Inference Server[6]使用 Dragonfly 下载模型文件，可以参考 #2185[7]。如果有对集成 Triton Inference Server 项目 Drgaonfly Repository Agent[8]感兴趣的同学，可以联系 gaius.qi@gmail.com。 TorchServer[9]使用 Dragonfly 下载模型文件，现正在开发，预计 v2.1.1 版本可以使用，项目仓库在 Dragonfly Endpoint[10]。 Fluid[11]基于 JuiceFS[12]运行时通过 Dragonfly 下载数据，正在开发，预计 v2.1.1 版本可以使用。 Dragonfly 助力火山引擎 AIGC [13]推理业务 P2P 镜像加速。 社区中已经有很多案例，基于 P2P 技术使用 Dragonfly 分发 AI 场景中的文件。在 AI 推理阶段，推理服务并发下载模型可以有效通过 Dragonfly P2P 缓解模型仓库的带宽压力，从而提高整体下载速度。在 KubeCon + CloudNativeCon + Open Source Summit China 2023[14]社区联合快手做一次分享，主题是《Dragonfly: Intro, Updates and AI Model Distribution in the Practice of Kuaishou - Wenbo Qi, Ant Group \u0026amp;amp; Zekun Liu, Kuaishou Technology》[15]，感兴趣的同学可以关注。 维护者 社区新增四位 Maintainer，希望能够帮助更多的 Contributor 参与到社区的工作中。\n 黄逸炀[16]：就职于火山引擎，主要专注于社区代码工程方面。 温满祥[17]：就职于百度，主要专注于社区代码工程方面。 Mohammed Farooq[18]：就职于 Intel，主要专注于社区代码工程方面。 许洲[19]：大连理工大学在读博士，主要专注于智能调度算法方面。 其他 版本更新包含的更多细节可以参考👇 CHANGELOG：https://github.com/dragonflyoss/Dragonfly2/blob/main/CHANGELOG.md\n相关链接 [1].Xinxin Zhao Github：\nhttps://github.com/1zhaoxinxin\n[2].Dragonfly Console Github：\nhttps://github.com/dragonflyoss/console\n[3].Dragonfly 官网： https://d7y.io\n[4].Dragonfly Console Release v1.0.0： https://github.com/dragonflyoss/console/tree/release-1.0.0\n[5].Manager Console 文档： https://d7y.io/docs/reference/manage-console\n[6].Triton Inference Server： https://github.com/triton-inference-server/server\n[7].issue #2185： https://github.com/dragonflyoss/Dragonfly2/issues/2185\n[8].Dragonfly Repository Agent Github： …","date":1691478000,"description":"Dragonfly 发布 v2.1.0 版本！","dir":"blog/dragonfly-v-2-1-0-release/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d4047f2f246c79313ab932a67dc6b444","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-v-2-1-0-release/","publishdate":"2023-08-08T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/dragonfly-v-2-1-0-release/","summary":"Dragonfly 最新正式版本 v2.1.0 已经发布！ 感谢赵鑫鑫[1]同学帮助重构 Console 代码，并且提供全新的 Console[2]控制台方便用户可视化操作 P2P 集群。欢迎访问 d7","tags":["SOFAStack"],"title":"Dragonfly 发布 v2.1.0 版本！","type":"blog","url":"/sofastack.tech/blog/dragonfly-v-2-1-0-release/","wordcount":1667},{"author":null,"categories":"SOFAStack","content":" Dragonfly 项目简介 Dragonfly 是一款基于 P2P 的镜像加速和文件分发系统。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在 AI 数据分发、文件分发、日志分发和镜像分发等领域被大规模使用。在解决大规模文件分发场景下有着无可比拟的优势。\n自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF Sandbox 级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为 Incubating 级别的托管项目。\nSOFAChannel#34 就邀请到了蚂蚁集团技术专家、Dragonfly 项目 Maintainer 戚文博跟大家分享 Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的实践。\n直播介绍 《Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的加速实践》\n2023 年 8 月 9 日（周三）\n19：00 - 20：00\n「嘉宾简介」\n戚文博（花名：百蓦）\n蚂蚁集团技术专家\nDragonfly Maintainer\n「议题简介」\n在 AI 场景下，训练和推理两个过程中，数据的传输往往是关键瓶颈之一。Dragonfly \u0026amp;amp; Nydus 作为 CNCF Incubating 项目，其利用 P2P 技术和按需加载能力，能够大幅度提升数据传输的速度和效率，从而提高 AI 计算的整体效率和性能。这使得 AI 算法的训练和推理过程中数据传输更加高效和可靠，为 AI 技术的应用提供了强有力的支撑。\n「听众收获」\n1、了解并走进 Dragonfly 项目；\n2、镜像加速领域相关技术的分享；\n3、Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的实践。\n直播预约 钉钉搜索：22880028764\n钉钉群同步直播，讲师在线答疑\nB 站直播预约 有机会获得 Dragonfly 精美贴纸～\nhttps://www.bilibili.com/opus/825142485488500792?spm_id_from=444.41.0.0\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1690959600,"description":"Dragonfly \u0026 Nydus 作为 CNCF Incubating 项目，其利用 P2P 技术和按需加载能力，能够大幅度提升数据传输的速度和效率，从而提高 AI 计算的整体效率和性能。","dir":"activities/sofa-channel-34/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0b819934f2ea5ec73a3cbc2f8470a87f","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-34/","publishdate":"2023-08-02T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-34/","summary":"Dragonfly 项目简介 Dragonfly 是一款基于 P2P 的镜像加速和文件分发系统。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在 AI 数据分发、文件分发、日志","tags":["SOFAStack"],"title":"SOFAChannel#34《Dragonfly \u0026 Nydus 在 AI 场景下的加速实践》——Dragonfly 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-34/","wordcount":663},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n*本文* 807 字 阅读 3分钟\n在本系列的第 5 篇《MoE 系列（五）｜Envoy Go 扩展之内存安全》中我们介绍了内存安全如何实现。第 6 篇《MoE 系列（六）｜ Envoy Go 扩展之并发安全》又谈到了并发场景下的内存安全。\n今天，我们来到了安全性的最后一篇：沙箱安全，也是相对来说，最简单的一篇。\n沙箱安全 所谓的沙箱安全，是为了保护 Envoy 这个宿主程序的安全，也就是说，扩展的 Go 代码运行在一个沙箱环境中，即使 Go 代码跑飞了，也不会把 Envoy 搞挂。\n具体到一个场景，也就是当我们使用 Golang 来扩展 Envoy 的时候，不用担心自己的 Go 代码写得不好，而把整个 Envoy 进程搞挂了。\n那么目前 Envoy Go 扩展的沙箱安全做到了什么程度呢？\n简单来说，目前只做到了比较浅层次的沙箱安全。不过，也是实用性比较高的一层。\n严格来说，Envoy Go 扩展加载的是可执行的机器指令，是直接交给 CPU 来运行的，并不像 Wasm 或者 Lua 一样由虚拟机来解释执行。所以，理论上来说，也没办法做到绝对的沙箱安全。\n实现机制 目前实现的沙箱安全机制，依赖的是 Go Runtime 的 recover 机制。\n具体来说，Go 扩展底层框架会自动地，或者（*代码里显示启动的协程*）依赖人工显示地，通过 defer 注入我们的恢复机制。所以，当 Go 代码发生了崩溃的时候，则会执行我们注入的恢复策略，此时的处理策略是，使用 500 错误码结束当前请求，而不会影响其他请求的执行。\n但是这里有一个不太完美的点，有一些异常是 recover 也不能恢复的，比如这几个：\nConcurrent map writes Out of memory Stack memory exhaustion Attempting to launch a nil function as a goroutine All goroutines are asleep - deadlock 好在这几个异常，都是不太容易出现的。唯一一个值得担心的是 Concurrent map writes，不熟悉 Go 的话，还是比较容易踩这个坑的。\n所以，在写 Go 扩展的时候，我们建议还是小心一些，写得不好的话，还是有可能会把 Envoy 搞挂的。\n当然，这个也不是一个很高的要求，毕竟这是 Gopher 写 Go 代码的很常见的基本要求。\n好在大多常见的异常，都是可以 recover 恢复的，这也就是为什么现在的机制，还是比较有实用性。\n未来 那么，对于 recover 恢复不了的，也是有解决的思路：\n比如 recover 恢复不了 Concurrent map writes，是因为 Runtime 认为 map 已经被写坏了，不可逆了。\n那如果我们放弃整个 runtime，重新加载 so 来重建 runtime 呢？那影响面也会小很多，至少 Envoy 还是安全的，不过实现起来还是比较地麻烦。\n眼下比较浅的安全机制，也足够解决大多数的问题了。\n了解更多…\nMOSN Star 一下🌟：\nhttps://github.com/mosn/mosn\n推荐阅读： MoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（四）｜Go 扩展的异步模式\n","date":1690873200,"description":"MoE 系列（七） - Envoy Go 扩展之沙箱安全","dir":"blog/moe-series (7) |envoy-go-extension-sandbox-security/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5f4a7e3872dbe224f8ed9d420af546dc","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","publishdate":"2023-08-01T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 *本文* 807 字 阅读 3分钟 在本","tags":["SOFAStack"],"title":"MoE 系列（七） - Envoy Go 扩展之沙箱安全","type":"blog","url":"/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","wordcount":1055},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 1313 字 阅读 4 分钟\n前一篇介绍了 Envoy Go 扩展的内存安全，相对来说，还是比较好理解的，主要是 Envoy C++ 和 Go GC 都有自己一套的内存对象的生命周期管理。这篇聊的并发安全，则是专注在并发场景下的内存安全，相对来说会复杂一些。\n并发的原因 首先，为什么会有并发呢🤔️\n本质上因为 Go 有自己的抢占式的协程调度，这是 Go 比较重的部分，也是与 Lua 这类嵌入式语言区别很大的点。\n细节的话，这里就不展开了，感兴趣的可以看这篇👉cgo 实现机制 - 从 C 调用 Go\n这里简单交代一下，因为 C 调用 Go，入口的 Go 函数的运行环境是，Goroutine 运行在 Envoy worker 线程上，但是这个时候，如果发生了网络调用这种可能导致 Goroutine 挂起的，则会导致 Envoy worker 线程被挂起。\n所以，解决思路🪄就是像 Go 扩展的异步模式[1]中的示例一样，新起一个 Goroutine，它会运行在普通的 Go 线程上。\n那么此时，对于同一个请求，则会同时有 Envoy worker 线程和 Go 线程，两个线程并发在处理这个请求，这个就是并发的来源。\n但是，我们并不希望用户操心这些细节，而是在底层提供并发安全的 API，把复杂度留在 Envoy Go 扩展的底层实现里。\n并发安全的实现 接下来，我们就针对 Goroutine 运行在普通的 Go 线程上这个并发场景，来聊一聊如何实现并发安全。\n对于 Goroutine 运行在 Envoy 线程上，因为并不存在并发冲突，这里不做介绍。\n写 header 操作 我们先聊一个简单的，比如在 Go 里面通过 header.Set 写一个请求头。\n核心思路是，是通过 dispatcher.post，将写操作当做一个事件派发给 Envoy worker 线程来执行，这样就避免了并发冲突。\n读 header 操作 读 header 则要复杂不少，因为写不需要返回值，可以异步执行，读就不行了，必须得到返回值。\n为此，我们根据 Envoy 流式的处理套路，设计了一个类似于所有权的机制。\nEnvoy 的流式处理，可以看这篇👉 搞懂 http filter 状态码[2]。\n简单来说，我们可以这么理解，当进入 decodeHeaders 的时候，header 所有权就交给 Envoy Go 的 C++ 侧了，然后，当通过 cgo 进入 Go 之后，我们会通过一个简单的状态机，标记所有权在 Go 了。\n通过这套设计/约定，就可以安全地读取 header 了，本质上，还是属于规避并发冲突。\n为什么不通过锁来解决呢？因为 Envoy 并没有对于 header 的锁机制，C++ 侧完全不会有并发冲突。\n读写 data 操作 有了这套所有权机制，data 操作就要简单很多了。\n因为 header 只有一份，并发冲突域很大，需要考虑 Go 代码与 C++ 侧的其他 filter 的竞争。\ndata 则是流式处理，我们在 C++ 侧设计了两个 buffer 对象，一个用于接受 filter manager 的流式数据，一个用于缓存交给 Go 侧的数据。\n这样的话，交给 Go 来处理的数据，Go 代码拥有完整的所有权，不需要考虑 Go 代码与 C++ 侧其他 filter 的竞争，可以安全地读写，也没有并发冲突。\n请求生命周期 另外一个很大的并发冲突，则关乎请求的生命周期，比如 Envoy 随时都有可能提前销毁请求，此时 Goroutine 还在 Go thread 上继续执行，并且随时可能读写请求数据。\n处理的思路是：\n并没有有效的办法，能够立即 kill Goroutine，所以，我们允许 Goroutine 可能在请求被销毁之后继续执行。\n但是，Goroutine 如果读写请求数据，Goroutine 会被终止，panic + recover（*recover 细节我们下一篇会介绍*）。\n那么，我们要做的就是，所有的 API 都检查当前操作的请求是否合法，这里有两个关键：\n每请求有一个内存对象，这个对象只会由 Go 来销毁，并不会在请求结束时，被 Envoy 销毁，但是这个内存对象中保存了一个 weakPtr，可以获取 C++ filter 的状态。\n通过这个机制，Go 可以安全地获取 C++ 侧的 filter，判断请求是否还在。\n同时，我们还会在 onDestroy，也就是 C++ filter 被销毁的 Hook 点；以及 Go thread 读写请求数据，这两个位置都加锁处理，以解决这两个之间的并发冲突。\n最后 对于并发冲突，其实最简单的就是，通过加锁来竞争所有权，但是 Envoy 在这块的底层设计并没有锁，因为它根本不需要锁。\n所以，基于 Envoy 的处理模型，我们设计了一套类似所有权的机制，来避免并发冲突。\n所有权的概念也受到了 Rust 的启发，只是两者工作的层次不一样，Rust 是更底层的语言层面，可以作用于语言层面，我们这里则是更上层的概念，特定于 Envoy 的处理模型，也只能作用于这一个小场景。\n但是某种程度上，解决的问题，以及其中部分思想是一样的。\n了解更多…\nMOSN Star 一下🌟：\nhttps://github.com/mosn/mosn\n参考链接 [1]Go 扩展的异步模式:\nhttps://uncledou.site/2023/moe-extend-envoy-using-golang-4/\n[2]搞懂 http filter 状态码:\nhttps://uncledou.site/2022/envoy-filter-status/\n推荐阅读 MoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（四）｜Go 扩展的异步模式\nMoE 系列（五）｜Envoy Go 扩展之内存安全\n","date":1689663600,"description":"MoE 系列（六）｜Envoy Go 扩展之并发安全","dir":"blog/moe-series（6）｜envoy-go-extensions- concurrency- security/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1689663600,"objectID":"a7747e9132ae0170156edbe2e8b8b0f2","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","publishdate":"2023-07-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 1313 字 阅读 4 分钟 前一篇介","tags":["SOFAStack"],"title":"MoE 系列（六）｜ Envoy Go 扩展之并发安全","type":"blog","url":"/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","wordcount":1822},{"author":null,"categories":"SOFAStack","content":" Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开发。\n二方库升级 SOFABoot 4.0 基于 Spring Boot 3.0 与 Spring Framework 6 构建。在 Spring Boot 3.0 与 Spring Framework 6 引入的二方库升级列表可参考文档👉 Spring Boot 3.0 Release Notes\n在 SOFABoot 4.0 引入的二方库升级列表如下：\n Spring Boot 3.0.5 Spring Cloud 4.0.0 Spring Cloud Stream 3.2.6 SOFA Common tools 2.0.0 SOFATracer 4.0.0 SOFARPC 5.10.0 FastJson 1.2.83 Guava 31.1-jre Grpc 1.51.1 Grpc common protos 2.11.0 Druid 1.2.16 ASM 9.4 Javassist 3.29.2-GA Curator 4.3.0 Dubbo 3.1.8 Nacos 2.0.3 Swagger 1.6.7 Swagger2 2.2.8 基于 Jakarta EE Spring Boot 3.0 中依赖 Jakarta EE 规范的部分已经升级到了 Jakarta EE 10 版本。例如，使用 Servlet 6.0 和 JPA 3.1 规范。因此，部分包的命名空间也进行了替换，例如你应该使用：\n✅jakarta.servlet.Filter\n而不是 javax.servlet.Filter。\n同时，如果你使用了自己的依赖提供 Jakarta EE 规范的 API，需注意进行对应的依赖升级，例如你应该使用：\n✅jakarta.servlet:jakarta.servlet-api\n而不是 javax.servlet:javax.servlet-api。\n可参考文档：Migrate to Jakarta EE 9 来修改 Jakarta 相关的包名以及依赖。\n支持 SOFAArk 2.0 SOFAArk 2.0 模式是 SOFAArk 框架的整体优化版本，相较于 SOFAArk 1.0 模式，它的整体优化思路和原则是 Ark Master Biz 保持和原生 SOFABoot 保持一致，弱化复杂的 Ark Plugin 类管控机制，将 Ark Plugin 与 Master Biz 合并。使得 Ark Master Biz 和原生 SOFABoot 应用的启动方式、类加载方式保持一致，大大降低了 Master Biz 应用的编程难度。\nSOFABoot 4.0 版本不再支持 SOFAArk 1.0 模式，如果你想要在 SOFABoot 应用中使用 SOFAArk 2.0 模式，可以按照以下步骤进行操作：\n1、在项目中引入 SOFAArk 组件依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;ark-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2、添加 Spring Boot 的 Package 插件\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 3、启动应用\n 方式一： IDEA 启动，注意需要添加启动参数：-Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二： 命令行启动，先运行 mvn clean package 命令进行打包，生成 ${bizName}-${bizVersion}-ark-biz.jar 的可执行文件，然后在终端运行以下启动参数：\njava -jar -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName} ${bizName}-${bizVersion}-ark-biz.jar\n支持场景化的按配置加载能力 通常情况下，应用在不同的场景下可能需要开启或者关闭不同的功能，Spring Boot 提供了丰富的 Configuration 动态配置能力[4] 能力以支持应用在不同的场景下加载不同的 Bean。\nSOFABoot 在此基础上，对 org.springframework.context.ApplicationContextInitializer 等扩展点进行了增强，支持通过统一风格的配置定制各类 Bean 以及扩展点的开启与关闭，并提供了定制模版配置的开启方式以降低应用配置项的复杂度。\n 通过： com.alipay.sofa.boot.autoconfigure.condition.ConditionalOnSwitch 注解为 Bean 添加按配置开启能力：\n@Configuration(proxyBeanMethods = false) @ConditionalOnSwitch(id=\u0026amp;quot;sample\u0026amp;quot;) public class SampleConfiguration { @Bean public SampleBean sampleBean() { return new SampleBean(); } } 添加：\nsofa.boot.switch.bean.sample.enabled=false 配置后，SampleConfiguration 配置类将不再加载。\n 通过继承： …","date":1689058800,"description":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","dir":"blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2a9d6f15f257293795df8dec9fbc5130","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","publishdate":"2023-07-11T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","summary":"Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开","tags":["SOFAStak"],"title":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","type":"blog","url":"/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","wordcount":3757},{"author":null,"categories":"SOFAStack","content":" 文｜魏陈豪（花名：无陈 Sam)\n蚂蚁集团 SOFAStack 产品专家\n本文 2966 字 阅读 8 分钟\n序言 今天给大家带来一篇 Seata-DTX[1] 商业版分布式事务在金融行业如何保证事务一致性的实践介绍。从一个全局视角出发看看一致性的保证、分别有哪些节点，事务组件在其中处在一个什么位置、担任什么工作。\n分布式系统下的事务问题阐述 云原生应用以分布式系统为主，应用会被切分到多个分布式的微服务系统下。拆分一般分为水平拆分和垂直拆分，这并不仅仅单指对数据库或者缓存的拆分，主要是表达一种分而治之的思想和逻辑。\n分布式系统的底层无法逃离“CAP 的不可能三角”*（C: Consistency，一致性；A: Availability，可用性；P: Partition Tolerance，分区容忍性）*。CAP 原理证明，任何分布式系统只可同时满足以上两点，无法三者兼顾。而分布式的服务化系统都需要满足分区容忍性，那么必须在一致性和可用性之间进行权衡。\n如果网络发生异常情况，导致分布式系统中部分节点之间的网络延迟不断增大，可能会导致分布式系统出现网络分区。复制操作可能会被延后，如果这时我们的使用方等待复制完成再返回，则可能导致在有限时间内无法返回，就失去了可用性；如果使用方不等待复制完成，而在主分片写完后直接返回，则具有了可用性，但是失去了一致性。\n图 1 CAP 理论\n图片出处：https://lushunjian.github.io/blog/2018/06/20/CAP%E7%90%86%E8%AE%BA/\n金融机构对一致性的诉求 对金融机构而言，架构层面的高可用和业务层面的强一致性，几乎同样重要。这就需要金融级云原生能够很好地平衡“CAP 的不可能三角”，需要尽可能兼顾业务强一致与系统高可用。\n但是“一致性挑战”在分布式系统中绝不仅仅是一个数据库问题，而是一个大的话题。其涵盖分布式系统的各个层面：事务一致性、节点一致性、系统间业务一致性、消息幂等一致性、缓存一致性、跨 IDC 一致性等等。所以也需要云原生架构有一系列技术能够应对金融级对一致性的严苛挑战。\n一致性控制的几个重要维度 这里挑选几个常见的金融场景下需要解决的一致性维度进行阐述。\n事务级：事务级别的一致性控制需要根据不同的金融场景选择合适的分布式事务模式。在我们针对 Seata-DTX 的客户进行调研后，发现大多数客户在平衡成本和性能后，基于 SAGA 和 TCC 是目前金融机构比较常用的两种分布式事务模式。SAGA 模式对应用实现侵入性更小，但基于补偿事务来保障一致性的设计、前后步骤执行过程中不保证事务隔离性；而 TCC 模式能做到比较好的事务隔离性，但需要应用层感知更多的复杂度。\n对于事务流程中部分不需要同步返回结果的节点，为提高执行效率可采用异步消息队列实现，对于一些事务流程较长的场景可明显降低事务实现复杂度、削峰填谷。典型场景如客户购买理财场景简化分为存款账户扣款和理财账户入账两个步骤，若选用 SAGA 模式，存款账户成功扣款后、理财账户入账失败，客户会看到“钱已付、货没到”的中间异常状态，需要系统进行冲正存款账户扣款来保障事务一致性。如选用 TCC 模式，先后完成存款账户扣款、理财账户入账的逻辑处理，各自需要存款系统和理财系统记录逻辑处理的状态，二者均成功后再发起统一提交。\n数据库级：接下来是数据库层面，金融场景下对于数据不丢有着极致的要求：一方面需要在同城、异地多个机房保存多个副本，另一方面需要在多个副本之间实现数据同步，Seata-DTX 的高可用也是依赖数据库之间的数据同步进行保障的。整体作用是以防一个 Seata-DTX 事务集群宕机后，切换到另外一套 Seata-DTX 事务集群后，可以恢复到正在进行中的事务记录，保障同城分布式事务的 RPO 为零、异地 RPO 接近零。数据库同步中，如果使用的是分布式事务库，分布式数据库一般通过对 Paxos 的支持来实现跨多服务器，甚至跨多中心的数据一致性保证。\n机房级：跨机房的路由能力、异常事务的跨机房恢复能力。发生机房故障时，数据库需要能够切到同城/异地的副本、并保障 RPO 为零，配合应用层的交易路由切换，完成机房级容灾切换、恢复业务。期间因机房故障导致的部分交易事务流程中断，分布式事务组件需要具备自动恢复能力，重新启动中断的事务流程按事先设定的业务规则向前完成或向后冲正。\n真实金融客户案例 以某资产规模超过 2 万亿元的省级农信为例，来看一下在核心整体下移的过程中，如何使用事务、配合数据库，机房容灾进行一致性控制。\n首先介绍一下整体的业务架构，在新核心平台中，大致可以分为产品服务层、交易中心层、交易中台层，如图 1 所示。交易中心收口所有的交易流程，对产品服务提供交易能力。最下面是交易原子能力层，主要包含 8 个中台，中台不直接对上提供服务，由交易中心统一处理。整个交易中心的能力，都基于服务编排构建，在编排流程中使用 SAGA 事务进行流程一致性控制。\n图 2 分布式新核心下移平台分层架构\n以贷款产品为例：整体的贷款支取、还款等长流程在信贷产品系统中，由 SAGA 事务进行串联，核心的资金交换部分由 TCC 事务把控一致性，做到对整体长流程里多个应用实现较小的侵入性。但基于补偿事务来保障一致性的设计、前后步骤执行过程中不保证事务隔离性，因此用 TCC 模式来处理对隔离性有较强诉求的核心资金交换服务，如图 3 所示。\n图 3 核心下移智能贷款系统流程\n如下图 4 是上述图 3 信贷产品中的还贷流程 TCC 流程示例。启动 TCC 事务后，使用 try 先尝试锁定客户账户余额，锁定成功后，等待二阶段提交。尝试 try 换贷款利息，锁定成功。整体提交事务，进行二阶段的扣账 confirm，以及还利息 confirm。\n图 4 核心下移智能贷款 TCC 流程\n事务层面的一致性进行了保证后，针对客户的 2 地机房进行事务的高可用部署，如图 5 所示。\n图 5 金融级云原生分布式事务部署架构\nConsole 是分布式事务的配置控制台，用户访问时通过 VIP 路由到不同机房的 console，数据写入到主 DB，主备 DB 数据实时同步。\nSeata-DTX Server 为分布式事务异库模式下的事务控制器和事务恢复器。其主要是记录事务日志，发起二阶段调用以及异常事务的恢复任务。\n业务应用用过 VIP 获取 Seata-DTX Server 对应的 IP。事务发起方发起事务时，事务日志都写入到主 DB 中，数据同步到备 DB。\n当福州 IDC 宕机或者断电时，流量会全部路由到上海 IDC。备数据库中因为有主 DB 的所有事务记录，当控制台查看事务数据和发起恢复事务任务时，仍然能正常执行。（当然可能会有人问这个情况下会不会频繁出现跨机房的分布式事务影响性能，此处负载均衡会基于入口流量的单元信息，自动调拨流量到对应的机房。此处不过多进行阐述。）\n综上可以看出，当前 Seata-DTX 的架构设计中，不单单是在事务层面去控制一致性。当有多个地域，多个副本时，可能需要结合数据库保证事务数据的一致。在多机房的情况下，需要依赖容灾能力，保证交易事务的流程可恢复。 …","date":1687849200,"description":"Seata-DTX｜分布式事务金融场景案例介绍","dir":"blog/seata-dtx｜distributed-transaction-financial-scenario-case-introduction/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1687849200,"objectID":"352eb80ff974af35f8069ba6c958fede","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","publishdate":"2023-06-27T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","summary":"文｜魏陈豪（花名：无陈 Sam) 蚂蚁集团 SOFAStack 产品专家 本文 2966 字 阅读 8 分钟 序言 今天给大家带来一篇 Seata-DTX[1] 商业版分布式事务在金融行业如何保证事务一致性的实践介绍。","tags":["SOFAStack"],"title":"Seata-DTX｜分布式事务金融场景案例介绍","type":"blog","url":"/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","wordcount":2760},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nLayotto：\n主题： Layotto 社区会议\n时间： 06 月 28 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入： +862162681677（中国大陆）+8657128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/NhOf1RUNqwL\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components #888 Support Pod injection to deploy Layotto as a sidecar in Kubernetes #910 Develop a new component for Encryption API #952 「Layotto」：https://github.com/mosn/layotto/issues/953\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 21 日 14:00 - 15:00\n会议内容：\n 本次社区会议预告开源之夏课题审核通过，等待 6 月 26 日 公示； 为 Configure API 开发 Nacos 组件问题，目前已经进入解决的最后阶段； 支持 Pluggable Components 及关于支持 Pod 注入，目前皆已审核通过，等待公示； 新增 Develop a new component for Encryption API 组件，相关任务已发布至社区群，感兴趣同学可留言加入其中。 「Layotto」：https://github.com/mosn/layotto/issues/953\n「会议回放」：https://www.bilibili.com/video/BV1kX4y1i75R/?spm_id_from=333.337.search-card.all.click\u0026amp;amp;vd_source=5dab7f4bd190defb59dcf6e727539b24\nSOFAStack 社区本周贡献\n本周推荐阅读\nSOFAStack 的下一个五年\nMOSN 反向通道详解\nSeata Saga 模式快速入门和最佳实践\n生产环境可用的 Seata-go 1.2.0 来啦！！！\n","date":1687503600,"description":"SOFA Weekly｜Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-20230623/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c0b300d2a38604aa46274b6323f27af1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230623/","publishdate":"2023-06-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230623/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230623/","wordcount":869},{"author":null,"categories":"SOFAStack","content":" 文｜宋顺（GitHub ID：nobodyiam)\nSOFAStack 社区开源负责人\n蚂蚁集团高级技术专家\n本文 3861 字 阅读 11 分钟 01 回顾开源这五年 回想起 2018 年 4 月 19 日 SOFAStack 首次开源，当时的官宣文章中就提到了我们开源的初心：\n期望通过逐步向社区开源 SOFA 中各个组件，从而一方面帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，另一方面也是期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固。\n所以这几年我们也是围绕着这个初心把 SOFAStack 体系的各个产品逐渐开源，包括首批开源的 SOFABoot、SOFARPC、SOFAArk，以及后来的 SOFARegistry、SOFAJRaft、Seata 等。同时我们也孵化了 MOSN 社区，开源了云原生网络代理 MOSN 以及应用运行时 Layotto。这些产品也是代表着 SOFAStack 在金融级云原生领域的沉淀和积累，目前已经在上百家企业中生根发芽。\n图 1 - 产品开源时间线\n我们再来看几个数字，在这 5 年中，我们举办了 18 场 Meetup，开展了 32 场直播分享，目前在 GitHub 组织层面有 438 名贡献者以及 3W 的 Star。\n图 2 - 开源 5 年的几个数字\n除了在项目上收获了不少贡献者和 Star 外，我们也逐渐地对开源有了更为深刻的认识。\n以开源指标为例，我们的初心是为了帮助更多机构和合作伙伴完成金融分布式转型，我们一开始最为关注的指标是用户数；但因开源的特殊性，我们无法直接获取实际的用户数，所以采用了 GitHub 的 Star 作为衡量指标。\n我相信这也是很多开源项目常见的第一反应，后期大家其实也发现了一些问题。举例来说，有些开源项目为了完成指标，采取了点 Star 送礼物等行为。这些虽然没有在我们的项目上发生，我们仍觉得有违开源初心，就放弃了 Star 数作为核心的指标。\n图 3 - Star 数作为衡量指标\n另一个开源项目常用的衡量指标是贡献者数量，很多开源项目是没有商业公司支撑的。为了项目的长期发展，需要持续的吸引新的贡献者加入，从而为社区带来活力。\n我们在放弃 Star 数指标后，把重心放在了贡献者数量上，会为新贡献者提供一些简单的任务，使他们能更快的融入社区，成为潜在的长期贡献者。\n不过和 Star 指标类似，在过程中我们也发现其它社区中出现了一些不好的现象。比如故意留一些明显的 bug，或者提供一些修改错别字的任务来刷贡献者数量，我们认为这些也是有违开源初心的。\n图 4 - Contributor 数作为衡量指标\n那么，我们该如何对待开源呢？\n我脑海中想起了 Envoy 作者 Matt Klein 在 Envoy 开源五周年时说的一句话：成功的开源软件就像创办一个企业。\n图 5 - 成功的开源软件就像创办一个企业\n其实开源项目和创业很类似，首先你需要有一个好的点子，然后去吸引人才一起加入来提升产品能力，再通过一些营销手段对项目做推广来获取客户，而后持续迭代改进。\n对企业而言，员工和客户固然很重要，不过我认为最核心的还是产品，只有一个定位准确、解决实际问题的产品才能受到市场欢迎，从而获取资金维持公司的运营。\n在开源项目上，用户对应着企业的客户，是提供场景的驱动力来源；贡献者对应着企业的员工，属于资源投入，是推动力来源；而产品才是真正能解决用户问题的，是整个开源飞轮中最为核心的部分。所以 Star 数和贡献者数量都只是过程指标，核心还是要提升产品力，不能本末倒置。\n图 6 - 开源飞轮\n02 展望下一个五年 聊完了过去五年的过程和收获，对 SOFAStack 而言，下一个五年的主要方向就比较明确：我们还是会着重放在产品力的提升上，希望能持续解决分布式场景中的核心问题。\n那核心问题究竟是哪些呢？我想起了泛在计算的提出者 Mark Weiser 曾经说过的一句话：最卓越的技术是那些“消失不见的”技术。\n图 7 - 消失不见的技术\n对这个判断，我也是深以为然。在日常生活中，这类案例也是比比皆是：比如电，我们现在都是即插即用，以至于已经不感知电力背后的复杂基础设施，类似的还有水、煤气等。它们背后都有着复杂的基础设施在支撑，经过了数十年的技术发展之后，已经非常稳定可靠，交互也非常简单，所以这些技术就像是“消失不见”一样。\n图 8 - 水电煤随开随用\n然而在我们实际的研发场景中，业务研发对基础设施的感知还远没有达到无感的地步。\n比如在研发态，我们除了要关注业务逻辑之外，还会经常被中间件 SDK 升级所打扰，在使用云产品时还得感知多云的差异。\n在运维态，除了要关注发布时的业务表现，还要时刻去关注资源状况。在其容量不足的时候要申请资源做扩容，在业务低峰的时候要缩容服务来节约成本。\n可以说，技术基础设施的存在感越强，研发运维的效率就越低，无法把精力集中在业务的创新上。\n图 9 - 实际研发场景\n那么，我们该如何才能让技术基础设施也消失不见呢？\n我们知道对微服务而言，可以通过服务网格来解耦业务逻辑和 RPC 通用能力，从而实现独立演进、透明升级。\n图 10 - Service Mesh 演进架构\n项目地址：https://github.com/mosn/mosn\n在实际场景中，除了微服务之外，业务往往还会使用其它的中间件能力。例如动态配置、消息、缓存、数据库等，如何降低这些中间件和业务应用的耦合是一个新的问题。另外，在多语言场景，我们仍然要为每种语言开发一套轻量 SDK 来实现通信协议和编解码逻辑，这部分也有很高的成本。所以我们如何进一步去降低多语言的支持成本是另一个亟待解决的问题。\n为此，我们也是借鉴了 Dapr 的应用运行时思路，基于 MOSN 设计开发了 Layotto，在下层对接了各种基础服务；在上层为应用提供了统一的、具备各种分布式能力的 API。\n开发者不需要再关心底层各种组件的实现差异，只需要关注应用本身需要哪些能力。比如调用 RPC、发送消息，然后通过 gRPC 调用对应的 API 即可。这样就可以彻底和底层基础服务解绑，同时也是极大地降低了多语言的支持成本。\n图 11 - Layotto 架构\n项目地址：https://github.com/mosn/layotto\n通过服务网格和应用运行时，我们解决了研发态对中间件 SDK 升级、多云差异感知等负担，我们再来看下如何通过 Serverless 技术来降低运维态的负担。\n我们知道业务研发一般是从需求到设计、开发、测试，最后发布生产的一个循环过程，其中不少业务还会出现多个迭代并行开发的场景。然而发布生产要求是串行的，就会导致迭代堵车的现象，后一个迭代必须得等前一个迭代发完才能开始发布，整体效率比较低。\n除此之外，随着业务重要性的提升，发布流程也会变重，发布周期短则几个小时，长则几天甚至几周也屡见不鲜。同时，业务逻辑的增加也会导致应用启动变慢，启动一个系统往往需要几十分钟，导致应用扩容等操作响应迟缓。\n图 12 - 研发迭代形式\n我们经过分析，发现不少应用代码本质上是可以分成两层的。一层是公共逻辑和核心模 …","date":1687244400,"description":"SOFAStack 的下一个五年","dir":"blog/the-next-five-years-of-sofastack/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"434c6a58fe31dc8becf81b773891362a","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-next-five-years-of-sofastack/","publishdate":"2023-06-20T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/the-next-five-years-of-sofastack/","summary":"文｜宋顺（GitHub ID：nobodyiam) SOFAStack 社区开源负责人 蚂蚁集团高级技术专家 本文 3861 字 阅读 11 分钟 01 回顾开源这五年 回想起 2018 年 4 月 19 日 SOFAStack 首","tags":["SOFAStack"],"title":"SOFAStack 的下一个五年","type":"blog","url":"/sofastack.tech/blog/the-next-five-years-of-sofastack/","wordcount":3990},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 21 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862162681677（中国大陆）+8657128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/f4KJsKNnxfN\n议题：\n 2023 开源之夏-课题汇总 #894 为 Configure API 开发 Nacos 组件 #921 Support Pluggable Components #888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910 「Layotto」：https://github.com/mosn/layotto/issues/949\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 14 日 14:00 - 15:00\n会议内容：\n本次社区会议预告开源之夏目前已进入社区审核阶段；关于为 Configure API 开发 Nacos 组件问题，根据社区同学在 issue 中的沟通互动，已取得新的进展；支持 Pluggable Components 目前预计已完成审核，月底会有所公示；关于支持 Pod 注入，目前已审核部分，需等待官网公示；网站钉钉群二维码已修复与更新，可正常使用。\n「Layotto」：https://github.com/mosn/layotto/issues/949\n「会议回放」：https://www.bilibili.com/video/BV1wm4y1i7hv/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFARPC 5.10.1 版本发布\n发布 SOFARPC 5.10.1 版本，主要变更如下:\n 支持修改 gRPC Message Size #1333 升级 Hessian 到 3.4.0 以支持部分 java.time 类的序列化 #1338 详细发布报告：https://github.com/sofastack/sofa-rpc/compare/v5.10.0...5.10.1\nSOFAStack 社区本周贡献\n本周推荐阅读\nSeata Saga 模式快速入门和最佳实践\n生产环境可用的 Seata-go 1.2.0 来啦\nMOSN 基于延迟负载均衡算法-走得更快，期待走得更稳\nMoE 系列（五）｜Envoy Go 扩展之内存安全\n","date":1686898800,"description":"SOFA Weekly｜SOFARPC 5.10.1 版本发布、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230616/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cda466451816463410fd13477709f561","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230616/","publishdate":"2023-06-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230616/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFARPC 5.10.1 版本发布、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230616/","wordcount":996},{"author":null,"categories":"SOFAStack","content":" 文｜王特 （花名：亦夏）\nEmail：yixia.wt@antgroup.com\n蚂蚁集团数据中间件核心开发\n本文4927 字 阅读 13 分钟\nSeata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。Seata 为用户提供了 AT、TCC、SAGA、XA 等多种事务模式，帮助解决不同业务场景下的事务一致性问题。\n本文主要介绍 Seata Saga 模式的使用以及最佳实践，围绕三个部分展开，第一部分是 Seata Saga 的简介、第二部分旨在快速介绍 Seata Saga 模式的使用方法并帮助大家入门，最后一部分将会给大家分享一些 Seata Saga 实践中的经验，帮助用户更快、更好得使用 Seata Saga 模式。\n1 Seata Saga 简介 1.1 Saga 模式 Saga 模式是分布式事务的解决方案之一，理念起源于 1987 年 Hector \u0026amp;amp; Kenneth 发表的 Sagas 论文。它将整个分布式事务流程拆分成多个阶段，每个阶段对应我们的子事务，子事务是本地事务执行的，执行完成就会真实提交。\n它是一种基于失败的设计，如上图可以看到，每个活动或者子事务流程，一般都会有对应的补偿服务。如果分布式事务发生异常的话，在 Saga 模式中，就要进行所谓的“恢复”，恢复有两种方式，逆向补偿和正向重试。比如上面的分布式事务执行到 T3 失败，逆向补偿将会依次执行对应的 C3、C2、C1 操作，取消事务活动的“影响”。那正向补偿，它是一往无前的，T3 失败了，会进行不断的重试，然后继续按照流程执行 T4、T5 等。\n根据 Saga 模式的设计，我们可以得到 Saga 事务模式的优缺点。\n优点：\n 子事务 （或流程） ，提交是本地事务级别的，没有所谓的全局锁，在长事务流程下，避免了长时间的资源锁定；另外这种流水线的处理模型天然符合阶段式信号处理模型，能发掘出更高的性能和吞吐。 正向服务和补偿服务都是交给业务开发实现的，所以 Saga 模式和底层数据库协议是无关的。XA/AT 模式可能依赖特定的数据库类型和版本，比如 MySQL 是 5.0 之后才支持的 XA，那么低版本的 MySQL 就不能适用到 XA 模式。 缺点：\n 也是因为正向服务和补偿服务都由业务开发者实现，所以业务上是有开发成本的，侵入性相对 XA/AT 打一个注解的方式会高很多。 因为一阶段子事务活动提交是本地事务级别的，所以 Saga 模式不保证隔离性。提交之后就可能“影响”其他分布式事务、或者被其他分布式事务所“影响”。例如：其他分布式事务读取到了当前未完成分布式事务中子事务的更新，导致脏读；其他分布式事务更新了当前未完成分布式事务子事务更新过的字段，导致当前事物更新丢失；还有不可重复读的场景等。 所以 Saga 模式的使用也需要考虑这些问题带来的“影响”。一般 Saga 模式的使用场景有如下几个：\n 长事务流程，业务上难以接受长时间的资源锁定，Saga 的特性使得它在长事务流程上处理非常容易； 业务性质上，业务可以接受或者解决缺乏隔离性导致的“影响”。例如部分业务只要求最终一致性，对于隔离性要求没有那么严格，其实是可以落地 Saga 模式的； 分布式事务参与者包含其他机构或者三方的服务，数据资源服务不是我们自身维护，无法提供 TCC 模式要求的几个接口。 1.2 Seata Saga 接下来我们来看看 Seata Saga 的实现。Saga 主流的实现分为两种：编排式和协调式。Seata Saga 的实现方式是编排式，是基于状态机引擎实现的。 状态机执行的最小单位是节点：节点可以表示一个服务调用，对应 Saga 事务就是子事务活动或流程，也可以配置其补偿节点，通过链路的串联，编排出一个状态机调用流程。在 Seata 里，调用流程目前使用 JSON 描述，由状态机引擎驱动执行，当异常的时候，我们也可以选择补偿策略，由 Seata 协调者端触发事务补偿。\n有没有感觉像是服务编排，区别于服务编排，Seata Saga 状态机是 Saga+服务编排，支持补偿服务，保证最终一致性。\n我们来看看一个简单的状态机流程定义：\n上方是一个 Name 为 reduceIncentoryAndBalance 的状态机描述，里面定了 ServiceTask 类型的服务调用节点以及对应的补偿节点 CompensateReduceInventory。\n看看几个基本的属性：\n Type：节点类型，Seata Saga 支持多种类型的节点。例如 ServiceTask 是服务调用节点 ServiceName/ServiceMethod：标识 ServiceTask 服务及对应方法 Input/Output：定义输入输出参数，输入输出参数取值目前使用的是 SPEL 表达式 Retry：控制重试流程 Catch/Next：用于流程控制、衔接，串联整个状态机流程 更多类型和语法可以参考 Seata 官方文档[1]，可以看到状态机 JSON 声明还是有些难度的，为了简化状态机 JSON 的编写，我们也提供了可视化的编排界面[2]，如下所示，编排了一个较为复杂的流程。\n话不多说，我们进入下面的实践环节。\n2 Seata Saga 使用入门 2.1 从 Seata 官网新人文档开始 Seata 分 TC、TM 和 RM 三个角色，TC （Server 端） 为单独服务端部署，TM 和 RM （Client 端） 由业务系统集成。\nServer 端存储模式 （store.mode） 现有 file、db、redis 三种 （后续将引入 Raft、MongoDB） ，file 模式无需改动，直接启动即可。\n 部署 Seata Server\n从新人文档，可以看出 Seata 还是传统的 CS 模型。首先我们需要部署 Seata Server 端。Server 端默认的存储模式时 file 模式，无需改动，直接执行 SpringBoot 启动类 main 方法即可启动 Seata Server。为了方便，本次演示就使用 file 模式启动，其他模式的启动方式可以参考新人文档的详细介绍。\n创建 Client 端测试应用\n同时我们需要创建一个客户端的测试应用，这里命名 seata-saga-test，测试应用使用 SpringBoot 框架，配置好 spring 的 aplication.pname 和 port，并且引入 seata-spring-boot-starter 依赖，完成 Client 端应用的搭建。\n2.2 从 Seata Saga 单元测试看起 一般了解一个框架的功能，建议是从入口的单元测试类开始看起。在 Seata 仓库中找到 Seata Saga 的 test 模块，从最外围的测试类 io.seata.saga.engine.StateMachineTests 看起 （一般开源项目最外围的测试类即是入口类） ：\n从上面的截图可以看出，入口测试方法主要分为三个部分：\n【1】处的 spring 配置文件声明了 StateMachineEngine Bean 以及对应的属性，【2】处也引用 …","date":1686726000,"description":"Seata Saga 模式快速入门和最佳实践","dir":"blog/seata-saga-model-quick-start-and-best-practices/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7287981b4eabf6ef5f22582a62cd69ff","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","publishdate":"2023-06-14T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","summary":"文｜王特 （花名：亦夏） Email：yixia.wt@antgroup.com 蚂蚁集团数据中间件核心开发 本文4927 字 阅读 13 分钟 Seata 是一款开源的","tags":["SOFAStack"],"title":"Seata Saga 模式快速入门和最佳实践","type":"blog","url":"/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","wordcount":3753},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n可信基础设施技术分论坛\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：6 月 14 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/f4KJsKNnxfN\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components#888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes#910 How to run layotto with congfig_mongo.json#932 「Layotto」：https://github.com/mosn/layotto/issues/949\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议 时间：06 月 07 日 14:00 - 15:00\n会议内容：\n本次社区会议讨论了开源之夏现阶段导师审核课题的情况，并同步最新进展情况；关于 support pluggable components 与 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes 两个课题，现阶段正常进行中，无风险存在；How to run layotto with congfig_mongo.json 的问题已经解决，具体的解决方案详情可看 issue 或 视频回放。\n「Layotto」：https://github.com/mosn/layotto/issues/937\n「会议回放」：https://www.bilibili.com/video/BV1Pu4y1f7oa/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFAStack 社区本周贡献\n","date":1686294000,"description":"SOFA Weekly｜可信基础设施技术分论坛、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230609/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c2b1e54167604c2f46d7caa6b28da98f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230609/","publishdate":"2023-06-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230609/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜可信基础设施技术分论坛、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230609/","wordcount":781},{"author":null,"categories":"SOFAStack","content":"文｜刘月财（GitHub ID：luky116)\n360 服务端开发专家\nSeata-go 项目负责人\n本文 2752 字 阅读 7 分钟\n发布概览\nSeata-go 1.2.0 版本支持 XA 模式。XA 协议是由 X/Open 组织提出的分布式事务处理规范，其优点是对业务代码无侵入。当前 Seata-go 的 XA 模式支持 MySQL 数据库。至此，Seata-go 已经集齐 AT、TCC、Saga 和 XA 四种事务模式，完成了与 Seata Java 的功能对齐。\nXA 模式的主要功能:\n 支持了 XA 数据源代理\n 支持了 XA 事务模式\n XA 相关的 Samples 可以参考示例：\nhttps://github.com/seata/seata-go-samples/tree/main/xa\n在本版本中还修复了近期大量用户在使用过程中提交的 issue。\n版本的主要更新如下\nFeature：\n[#467] 实现 XA 模式支持 MySQL\nhttps://github.com/seata/seata-go/pull/467\n[#534] 支持 Session 的负载均衡\nhttps://github.com/seata/seata-go/pull/534\nBugfix：\n[#540] 修复初始化 XA 模式的 bug\nhttps://github.com/seata/seata-go/pull/540\n[#545] 修复 XA 模式获取 db 版本号的 bug\nhttps://github.com/seata/seata-go/pull/545\n[#548] 修复启动 XA 时候会失败的 bug\nhttps://github.com/seata/seata-go/pull/548\n[#556] 修复 XA 数据源的 bug\nhttps://github.com/seata/seata-go/pull/556\n[#562] 修复提交 XA 全局事务的 bug\nhttps://github.com/seata/seata-go/pull/562\n[#564] 修复提交 XA 分支事务的 bug\nhttps://github.com/seata/seata-go/pull/564\n[#566] 修复使用 XA 数据源执行本地事务的 bug\nhttps://github.com/seata/seata-go/pull/566\nOptimize：\n[#523] 优化 CI 流程\nhttps://github.com/seata/seata-go/pull/523\n[#525] 将 Jackson 序列化重命名为 JSON\nhttps://github.com/seata/seata-go/pull/525\n[#532] 移除重复的代码\nhttps://github.com/seata/seata-go/pull/532\n[#536] 优化 go import 代码格式\nhttps://github.com/seata/seata-go/pull/536\n[#554] 优化 XA 模式的性能\nhttps://github.com/seata/seata-go/pull/554\n[#561] 优化 XA 模式的日志输出\nhttps://github.com/seata/seata-go/pull/561\nTest:\n[#535] 添加集成测试\nhttps://github.com/seata/seata-go/pull/535\nDoc:\n[#550] 添加 1.2.0 版本的改动日志\nhttps://github.com/seata/seata-go/pull/550\n英文版：https://github.com/seata/seata-go/releases/tag/v1.2.0\n致谢\n非常感谢以下 Contributors 的代码贡献。若有无意遗漏，请报告。\n@georgehao\nhttps://github.com/georgehao\n@luky116\nhttps://github.com/luky116\n@jasondeng1997\nhttps://github.com/jasondeng1997\n@106umao\nhttps://github.com/106umao\n@wang1309\nhttps://github.com/wang1309\n@iSuperCoder\nhttps://github.com/iSuperCoder\n@Charlie17Li\nhttps://github.com/Charlie17Li\n@Code-Fight\nhttps://github.com/Code-Fight\n@Kirhaku\nhttps://github.com/Kirhaku\n@Vaderkai\nhttps://github.com/VaderKai\n同时，我们收到了社区反馈的很多有价值的 issue 和建议，非常感谢大家。\n社区讨论\n加入钉钉群：\nSeata-go 社区群：33069364\nSeata-go 开发群：44816898\n未来展望\nSeata 社区近期与不少国内 Go 语言微服务框架以及 ORM 框架背后的开发社区达成合作，比如 GORM 框架，已经集成到了 Sample 中，后续会将更多的 ORM 框架集成在 Seata-go-samples 项目中。\nSeata-go-samples 集成到 Seata-go GitHub Actions 的集成测试环境，目前已经在进行中，用于测试每个 PR，保证系统的兼容性与稳定性。\nSeata-go 后续的 Saga 模式，计划采用 Temporal 框架来做服务编排，目前正在规划中，期待能给用户带来更实用便利的 Saga 使用体验。\n欢迎对开源感兴趣的朋友加入 Seata 开源建设中来。\n常用链接\nSeata：\nhttp://github.com/seata/seata\nhttps://github.com/seata/seata-php\nhttps://github.com/seata/seata-js\nhttps://github.com/seata/seata-go\nSamples：\nhttps://github.com/seata/seata-samples\nhttps://github.com/seata/seata-go-samples\n官网：\nhttps://seata.io/\n投稿\n欢迎大家将 Seata/Seata-go/Seata-php/Seata-js 相关的实践文章投稿至：https://www.yuque.com/fred-x/ngfgiz/le1h4u5kn0xyhhoh\nSeata Star 一下✨：\nhttps://github.com/seata/seata-go\n","date":1686034800,"description":"生产环境可用的 Seata-go 1.2.0 来啦！！！","dir":"blog/seata-go-1.2.0-available-for-production-environments-is-here/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7df64ba112ba3f76cfa911d05813d383","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","publishdate":"2023-06-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","summary":"文｜刘月财（GitHub ID：luky116) 360 服务端开发专家 Seata-go 项目负责人 本文 2752 字 阅读 7 分钟 发布概览 Seata-go 1.2.0 版本支持 XA 模式。XA 协议是由 X/Open 组织提","tags":["SOFAStack"],"title":"生产环境可用的 Seata-go 1.2.0 来啦！！！","type":"blog","url":"/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","wordcount":920},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区 活动时间：05 月 31 日，周三晚 19 点 活动形式：线上直播 资料下载：点击获取 B 站直播间地址：http://live.bilibili.com/21954520 B 站直播ID：21954520 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》 Occlum 是蚂蚁集团于 2019 年开源的机密计算操作系统，也是 Linux 基金会机密计算联盟官方项目，荣列 2021“科创中国”开源创新榜。2022 年 12 月 10 日，Occlum 正式发布 v1.0 版本。学术成果发表在 ASPLOS\u0026amp;rsquo;20。Occlum 可让复杂应用轻松获得机密计算能力，是目前业界最受欢迎的开源机密计算操作系统。\nSOFAChannel 第 33 期邀请到了 LibOS 项目的 Contributor 惠春阳来做分享，带大家了解机密计算，讲述 Occlum 如何借助 EDMM，获得更高的安全性、易用性和更极致的性能，成为更好的机密计算 Library OS。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 惠春阳（花名：三仟） 蚂蚁集团技术专家 Occlum 机密计算 LibOS 项目 Contributor 议程 直播回放 点击查看\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1685516400,"description":"SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区","dir":"activities/sofa-channel-33/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"eb7a144641c7fa0312314ecca5edb8cb","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-33/","publishdate":"2023-05-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-33/","summary":"概要 活动主题：SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区 活动时间：05 月 31 日","tags":["SOFAStack"],"title":"SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-33/","wordcount":642},{"author":null,"categories":"SOFAStack","content":" 前面几篇介绍了 Envoy Go 扩展的基本用法，接下来几篇将介绍实现机制和原理。\nEnvoy 是 C++ 实现的，那 Envoy Go 扩展，本质上就相当于把 Go 语言嵌入 C++ 里了。\n在 Go 圈里，将 Go 当做嵌入式语言来用的，貌似并不太多见，这里面细节还是比较多的。比如：\n Envoy 有一套自己的内存管理机制，而 Go 又是一门自带 GC 的语言。 Envoy 是基于 libevent 封装的事件驱动，而 Go 又是包含了抢占式的协程调度。 为了降低用户开发时的心智负担，我们提供了三种安全保障。有了这三层保障，用户写 Go 来扩展 Envoy 的时候，就可以像平常写 Go 代码一样简单，而不必关心这些底层细节。\n三种安全 1. 内存安全 用户通过 API 获取到的内存对象，可以当做普通的 Go 对象来使用。\n比如，通过 Headers.Get 得到的字符串，在请求结束之后还可以使用，而不用担心请求已经在 Envoy 侧结束了，导致这个字符串被提前释放了。\n2. 并发安全 当启用协程的时候，我们的 Go 代码将会运行在另外的 Go 线程上，而不是在当前的 Envoy worker 线程上，此时对于同一个请求，则存在 Envoy worker 线程和 Go 线程的并发。\n但是，用户并不需要关心这个细节，我们提供的 API 都是并发安全的，用户可以不感知并发的存在。\n3. 沙箱安全 这一条是针对宿主 Envoy 的保障，因为我们并不希望某一个 Go 扩展的异常，把整个 Envoy 进程搞崩溃。\n目前我们提供的是，Go Runtime 可以 recover 的有限沙箱安全，这通常也足够了。\n更深度的，Runtime 不能 recover 的，比如 Map 并发访问，则只能将 Go So 重载，重建整个 Go Runtime 了，这个后续也可以加上。\n内存安全实现机制 要提供安全的内存机制，最简单的办法，也是*（几乎）*唯一的办法，就是复制。但是，什么时候复制、怎么复制，还是有一些讲究的。这里权衡的目标是降低复制的开销，提升性能。\n这里讲的内存安全，还不涉及并发时的内存安全，只是 Envoy*（C++）*和 Go 这两个语言运行时之间的差异。\nPS：以前用 OpenResty 的时候，也是复制的玩法，只是有一点区别是，Lua String 的 Internal 归一化在大内存场景下，会有相对较大的开销；Go String 则没有这一层开销，只有 Memory Copy + GC 的开销。\n复制时机 首先是复制时机，我们选择了按需复制，比如 Header，Body Data 并不是一开始就复制到 Go 里面，只有在对应的 API 调用时，才会真的去 Envoy 侧获取\u0026amp;amp;复制。\n如果没有被真实需要，则并不会产生复制，这个优化对于 Header 这种常用的，效果倒是不太明显，对于 Body 这种经常不需要获取内容的，效果则会比较的明显。\n复制方式 另一个则是复制方式，比如 Header 获取上，我们采用的是在 Go 侧预先申请内存，在 C++ 侧完成赋值的方式，这样我们只需要一次内存赋值即可完成。\n这里值得一提的是，因为我们在进入 Go 的时候，已经把 Header 的大小传给了 Go，所以我们可以在 Go 侧预先分配好需要的内存。\n不过呢，这个玩法确实有点 tricky，并不是 Go 文档上注明推荐的用法，但是也确实是我们发现的最优的解法了。\n如果按照 Go 常规的玩法，我们可能需要一次半或两次内存拷贝，才能保证安全，这里有个半次的差异，就是我们下回要说的并发造成的。\n另外，在 API 实现上，我们并不是每次获取一个 Header，而是直接一次性把所有的 Header 全复制过来，在 Go 侧缓存了。这是因为大多数场景下，我们需要获取的 Header 数量会有多个，在权衡了 CGO 的调用开销和内存拷贝的开销之后，我们认为一次性全拷贝是更优的选择。\n最后 相对来说，不考虑并发的内存安全，还是比较简单的，只有复制最安全，需要权衡考虑的则更多是优化的事情了。\n比较复杂的还是并发时的安全处理，这个我们下回再聊。\nMOSN Star 一下✨： https://github.com/mosn/mosn\n推荐阅读 MoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\n[MoE 系列（四）｜Go 扩展的异步模式](\n","date":1685430000,"description":"MoE 系列（五）｜Envoy Go 扩展之内存安全","dir":"blog/moe-series (5)｜envoy-go-extensions-memory-security/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1685430000,"objectID":"f5d59dc8bad34c82fb7116161068a117","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","publishdate":"2023-05-30T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","summary":"前面几篇介绍了 Envoy Go 扩展的基本用法，接下来几篇将介绍实现机制和原理。 Envoy 是 C++ 实现的，那 Envoy Go 扩展，本质上就相当于把 Go 语言嵌入 C++ 里了。 在 Go 圈里，将 Go","tags":["SOFAStack"],"title":"MoE 系列（五）｜Envoy Go 扩展之内存安全","type":"blog","url":"/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","wordcount":1443},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAChannel#33 预告\n**Occlum 是蚂蚁集团于 2019 年开源的机密计算操作系统，也是 Linux 基金会机密计算联盟官方项目，荣列 2021“科创中国”开源创新榜。2022 年 12 月 10 日，Occlum 正式发布 v1.0 版本。学术成果发表在 ASPLOS\u0026amp;rsquo;20。Occlum 可让复杂应用轻松获得机密计算能力，是目前业界最受欢迎的开源机密计算操作系统。\nSOFAChannel 第 33 期邀请到了 LibOS 项目的 Contributor 惠春阳来做分享，带大家了解机密计算，讲述 Occlum 如何借助 EDMM，获得更高的安全性、易用性和更极致的性能，成为更好的机密计算 Library OS。\n本期为 SOFAStack 与博文视点联合举办的机密计算专题，直播中也将抽奖送出《机密计算：AI 数据安全和隐私保护》。欢迎所有对 Occlum、机密计算、TEE 感兴趣的小伙伴们一起来听直播！🧸\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 24 日 14:00 - 15:00\n会议内容：\n随着本周社区会议的召开，社区同学讨论了如何为 Configure API 开发 Nacos 组件问题。会议同步了开源之夏的学生招募进展，以及在课题沟通时推进了 Layotto 目前能够解决的问题，并进一步讨论了版本优化的方法。\n「Layotto」：https://github.com/mosn/layotto/issues/931\n「会议回放」：https://www.bilibili.com/video/BV1XM4y1v7A9/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 31 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components#888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes#910 「Layotto」：https://github.com/mosn/layotto/issues/931\nSOFAStack 社区本周贡献\n本周推荐阅读\n直播预告 | SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》\nMOSN 基于延迟负载均衡算法——走得更快，期待走得更稳\nMoE 系列（四）｜Go 扩展的异步模式\nSOFAServerless 体系助力业务极速研发\n","date":1685084400,"description":"SOFA Weekly｜SOFAChannel#33 直播预告、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230526/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6ce1b77204d6ef8dfa8d2dcae4a65d59","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230526/","publishdate":"2023-05-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230526/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAChannel#33 直播预告、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230526/","wordcount":1186},{"author":null,"categories":"SOFAStack","content":" 文｜纪卓志（GitHub ID：jizhuozhi)\n京东高级开发工程师\nMOSN 项目 Committer\n专注于云原生网关研发的相关工作，长期投入在负载均衡和流量控制领域\n前言 这篇文章主要是介绍 MOSN 在 v1.5.0 中新引入的基于延迟的负载均衡算法#2253。首先会对分布式系统中延迟出现的原因进行剖析，之后介绍 MOSN 都通过哪些方法来降低延迟，最后构建与生产环境性能分布相近的测试用例来对算法进行验证。\n在开始聊基于延迟的负载均衡算法之前，我们先介绍下什么是负载均衡。\n什么是负载均衡 Wikipedia中 Load Balancing (Computing) 词条是这样介绍负载均衡的：\n 负载均衡是将一组任务分配到一组资源（计算单元）上的过程，目的是使它们的整体处理更有效率。负载均衡可以优化响应时间，避免负载不均匀导致一些计算节点过载而其他计算节点处于空闲状态\n 负载均衡在大型分布式系统中是关键的组成部分。负载均衡解决了分布式系统中最重要的两个问题：可伸缩性*（Scalability）*和韧性*（Resilience）*。\n 可伸缩性：应用程序部署在多个相同的副本中。当计算资源不足时可以通过部署额外的副本来增加计算资源，而当计算资源大量冗余时可以通过减少副本来节省成本。通过负载均衡可以将请求负载分布到不同的副本中。\n 韧性：分布式系统的故障是部分的。应用程序通过冗余副本的方式，保证在部分组件故障时仍能正常地提供服务。负载均衡通过感知节点的故障，调整流量的分配，将流量更多的分配到那些能够正常提供服务的节点上。\n 走得更快 负载均衡使得现代软件系统具备了可扩展性和韧性。但在分布式系统中还存在不容忽视的问题：延迟。\n延迟来自哪里 现代软件系统通常是多层级结构大型分布式系统，即使是只服务单个终端用户的请求，它背后也有可能经过了上百次的数据访问，这种情况在微服务架构中更是尤为普遍。\n微服务架构（引用自 Microservices Pattern）\n单台性能稳定的服务器中延迟通常由以下几个方面造成：\n 计算任务本身的复杂度 内容的传输过程中的延迟 请求排队等待的延迟 后台任务活动所导的资源竞争 这些服务器之间的延迟将会叠加，任何显著的延迟增加都会影响终端用户的体验。此外，任何来自单个节点的延迟峰值也会直接影响到终端用户体验。同时越来越多地使用公有云部署应用程序也进一步加剧了响应时间的不可预测性。因为在这些环境中存在共享资源*（CPU、内存和 IO）*的争用，应用程序机几乎不可避免地遇到性能影响，而这种影响是随时发生的。\n如何减少延迟 有研究表明，在大型互联网应用中，延迟往往具有长尾特点，P99 比中位数高出几个数量级。如果在应用架构的每层都能够减少这些尾部延迟，那么对终端用户整体的尾部延迟将会显著降低。\n在服务网格中，所有接收和发送的流量都会经过边车代理，通过边车代理可以轻松地控制网格的流量，而无需对服务进行任何修改。如果边车代理在对应用层流量进行转发时，总是通过负载均衡时选择响应时间较短的服务器，那么将会显著降低对终端用户的尾部延迟。\n基于此，我们准备开始为 MOSN 引入基于延迟的负载均衡算法，并进行适当调整来保证能够在大多数使用场景下显著减少延迟。\n性能问题是局部的 前面提到了，每个节点的性能受到多种因素的影响，这些影响因素是动态的，难以准确预测每个节点的性能，因此我们无法精确地选择最好的节点，但是可以避免较差的节点。\n在云环境中，服务器的性能常常是难以预测的，但是我们可以通过对大量的数据进行分析，发现服务器性能的分布大多数情况下是符合正态分布的。因此，尽管有一部分的服务器在性能方面表现比较差，它们的数量通常都是少数的*（3Sigma）*，而绝大部分服务器节点的表现是正常的。\n除了服务器之间的差异，还存在由基础设施导致的动态延迟，这种延迟可能是由于网络拥塞、故障或不断增长的流量所导致。这种延迟通常具有持续性和局部性：持续性则表示延迟会长时间存在，不会在短时间内消失；而局部性指的是延迟往往只出现在某些特定服务器上，而不会在全局发生。\nPeakEWMA 面对这些问题，我们使用 Peak EWMA*（Peak Exponentially Weighted Moving Average）*计算响应时间指标，并根据这个指标来对节点进行负载均衡。\nEWMA 是一种动态权重调整算法，各数值的加权影响力随时间而指数式衰退，越近期的数据加权影响力越重，但较旧的数据也给予一定的加权值。\n它以相对较高的权重考虑了最近响应时间的影响，因此更具有针对性和时效性。加权的程度以常数 𝛼 决定，𝛼 数值介于 0 至 1，它用来控制数据加权影响力衰退的速率。\n作为一种统计学指标，EWMA 的计算过程不需要大量的采样点以及时间窗口的设定，有效地避免了计算资源的浪费，更适合在 MOSN 这样的边车代理中使用。\n由于响应时间是历史指标，当服务器出现性能问题导致长时间未返回时，负载均衡算法会错误地认为这台服务器仍是最优的，而不断地向其发送请求而导致长尾延迟增高。我们使用活跃连接数作为实时变化的指标对响应时间进行加权，表示等待所有活跃的连接都返回所需要的最大时间。\nP2C（Power of Two Choice） 在大规模集群中，如果使用遍历所有服务器选择最好的服务器的方法，虽然可以找到最轻负载的服务器来处理请求，但这种方法通常需要大量的计算资源和时间，因此无法处理大规模的请求。因此，我们使用 P2C 来选择最优节点。相比之下，P2C 算法可以在常数时间内选择两个服务器进行比较，并选择其中负载更轻的服务器来处理请求。P2C 基于概率分配，即不直接基于权重分配，而是根据每个服务器优于其他服务器的概率值来决定请求的分配。\n此外，在多个负载均衡器的情况下，不同负载均衡器可能会有不同的节点视图，这可能导致某些负载均衡器选择的最优节点总是最差的节点。这是因为负载均衡器选择最优节点时基于自己的视图信息，而节点视图随着时间的变化可能会发生变化，因此不同的负载均衡器选择的最优节点也可能不同。P2C 算法通过对随机选择的两个节点进行比较，可以使节点间的负载均衡更加均匀，即使节点视图发生变化，也能提供稳定的负载均衡效果。\n 在 MOSN 的 v1.5.0 版本中，只有节点权重相同时会使用 P2C，当权重不同时会使用 EDF 进行加权选择。后续会提供可配置的选项。\n 模拟流量验证 我们构建了与生产环境性能分布相近的测试用例来对算法进行验证。\n首先我们使用正态分布生成了 10 台服务器的基准性能，其中数学期望为 50ms，标准差为 10ms。接下来，我们将这些基准性能作为数学期望，并以标准差为 5ms 的正态分布随机生成了请求延迟，以模拟真实世界的情况。此外，我们还在其中一台服务器注入了概率为 0.1 的故障，故障发生时会产生 1000ms 的延迟，以测试系统的容错性。\n为了模拟请求倾斜时请求排队等待的延迟，我们限制了每台服务器的最大并发数为 8，当同时处理的最大请求数超过了最大并发数时，将会排队等待。这样能够更加真实地模拟出系统的运行情况。\n最后，我们使用了 Round Robin、Least Request 和 Peak EWMA 三 …","date":1684825200,"description":"MOSN 基于延迟负载均衡算法——走得更快，期待走得更稳","dir":"blog/mosn-delay-based-load-balancing-algorithm-go-faster, expect-to-go-steadier/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4ed40af7694979d98879f50bcaf9093c","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","publishdate":"2023-05-23T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","summary":"文｜纪卓志（GitHub ID：jizhuozhi) 京东高级开发工程师 MOSN 项目 Committer 专注于云原生网关研发的相关工作，长期投入在负载均衡和流量控制领域","tags":["SOFAStack"],"title":"MOSN 基于延迟负载均衡算法——走得更快，期待走得更稳","type":"blog","url":"/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","wordcount":3277},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 大事记\nQCon 是由极客邦科技旗下 InfoQ 中国主办的综合性技术盛会，每年在伦敦、北京、纽约、圣保罗、上海、旧金山召开。自 2007 年 3 月份首次举办以来，已有超万名高级技术人员参加过 QCon 大会。QCon 内容源于实践并面向社区，演讲嘉宾依据热点话题，面向 5 年以上工作经验的技术团队负责人、架构师、工程总监、高级开发人员分享技术创新和典型实践。\n2023 年 5 月 26 日-27 日，QCon 广州站邀请了 MOSN 项目核心开发者、蚂蚁集团技术专家朱德江，将现场分享 《解密 MoE：将 Golang 嵌入 Envoy（C++）》。扫描上图二维码可参与报名。\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 17 日 14:00 - 15:00\n会议内容：\n随着本周社区会议的召开，社区同学进一步探讨了 Layotto 兼容 Dapr 的组件问题，解决思路逐渐清晰；对于如何使 Layotto 提供高性能的通信交互能力，社区同学将此问题与开源之夏的课题进行结合，并确定了版本优化的方向。\n「Layotto」：https://github.com/mosn/layotto/issues/929\n「会议回放」：https://www.bilibili.com/video/BV1Go4y1F7wo/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 24 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题汇总 #894\n Discussion：自建各种 Component #902\n 希望 Layotto 提供高性能的通信交互能力 #867\n 「Layotto」：https://github.com/mosn/layotto/issues/929\nSOFAStack 社区本周贡献\n本周推荐阅读\nMoE 系列（四）｜Go 扩展的异步模式\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\n【开源之夏 2023】欢迎报名 MOSN 社区项目！\n【开源之夏 2023】欢迎报名 SOFAStack 社区项目！\n","date":1684479600,"description":"SOFA Weekly｜SOFA 大事记、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230519/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bd81b1b8854e7bc553af2531bbdbe44a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230519/","publishdate":"2023-05-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230519/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 大事记、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230519/","wordcount":1102},{"author":null,"categories":"SOFAStack","content":"在《MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置》中我们体验了用 Istio 做控制面，给 Go 扩展推送配置，这次我们来体验一下，在 Go 扩展的异步模式下，对 Goroutine 等全部 Go 特性的支持。\n异步模式\n之前，我们实现了一个简单的 Basic Auth[1]，但是，那个实现是同步的，也就是说，Go 扩展会阻塞，直到 Basic Auth 验证完成，才会返回给 Envoy。\n因为 Basic Auth 是一个非常简单的场景，用户名密码已经解析在 Go 内存中了，整个过程只是纯 CPU 计算，所以，这种同步的实现方式是没问题的。\n但是，如果我们要实现一个更复杂的需求，比如，我们要将用户名密码调用远程接口查询，涉及网络操作，这个时候，同步的实现方式就不太合适了。因为同步模式下，如果我们要等待远程接口返回，Go 扩展就会阻塞，Envoy 也就无法处理其他请求了。\n所以，我们需要一种异步模式：\n 我们在 Go 扩展中，启动一个 Goroutine，然后立即返回给 Envoy，当前正在处理的请求会被挂起，Envoy 则可以继续处理其他请求。 Goroutine 在后台异步执行，当 Goroutine 中的任务完成之后，再回调通知 Envoy，挂起的请求可以继续处理了。 注意：虽然 Goroutine 是异步执行，但是 Goroutine 中的代码，与同步模式下的代码，几乎是一样的，并不需要特别的处理。\n为什么需要\n为什么需要支持 Goroutine 等全部 Go 的特性呢？\n有两方面的原因：\n 有了 Full-feature supported Go，我们可以实现非常强大、复杂的扩展。 可以非常方便的集成现有 Go 世界的代码，享受 Go 生态的红利。 如果不支持全部的 Go 特性，那么在集成现有 Go 代码的时候，会有诸多限制，导致需要重写大量的代码，这样，就享受不到 Go 生态的红利了。\n实现\n接下来，我们还是通过一个示例来体验，这次我们实现 Basic Auth 的远程校验版本，关键代码如下：\nfunc (f *filter) DecodeHeaders(header api.RequestHeaderMap, endStream bool) api.StatusType { go func() { // verify 中的代码，可以不需要感知是否异步 // 同时，verify 中是可以使用全部的 Go 特性，比如，http.Post if ok, msg := f.verify(header); !ok { f.callbacks.SendLocalReply(401, msg, map[string]string{}, 0, \u0026amp;quot;bad-request\u0026amp;quot;) return } // 这里是唯一的 API 区别，异步回调，通知 Envoy，可以继续处理当前请求了 f.callbacks.Continue(api.Continue) }() // Running 表示 Go 还在处理中，Envoy 会挂起当前请求，继续处理其他请求 return api.Running } 再来看 verify 的代码，重点是，我们可以在这里使用全部的 Go 特性：\n// 这里使用了 http.Post func checkRemote(config *config, username, password string) bool { body := fmt.Sprintf(`{\u0026amp;quot;username\u0026amp;quot;: \u0026amp;quot;%s\u0026amp;quot;, \u0026amp;quot;password\u0026amp;quot;: \u0026amp;quot;%s\u0026amp;quot;}`, username, password) remoteAddr := \u0026amp;quot;http://\u0026amp;quot; + config.host + \u0026amp;quot;:\u0026amp;quot; + strconv.Itoa(int(config.port)) + \u0026amp;quot;/check\u0026amp;quot; resp, err := http.Post(remoteAddr, \u0026amp;quot;application/json\u0026amp;quot;, strings.NewReader(body)) if err != nil { fmt.Printf(\u0026amp;quot;check error: %v\\n\u0026amp;quot;, err) return false } if resp.StatusCode != 200 { return false } return true } // 这里操作 header 这个 interface，与同步模式完全一样 func (f *filter) verify(header api.RequestHeaderMap) (bool, string) { auth, ok := header.Get(\u0026amp;quot;authorization\u0026amp;quot;) if !ok { return false, \u0026amp;quot;no Authorization\u0026amp;quot; } username, password, ok := parseBasicAuth(auth) if !ok { return false, \u0026amp;quot;invalid Authorization format\u0026amp;quot; } fmt.Printf(\u0026amp;quot;got username: %v, password: %v\\n\u0026amp;quot;, username, password) if ok := checkRemote(f.config, username, password); !ok { return false, \u0026amp;quot;invalid username or password\u0026amp;quot; } return true, \u0026amp;quot;\u0026amp;quot; } 另外，我们还需要实现一个简单的 HTTP 服务，用来校验用户名密码，这里就不展开了，用户名密码还是 foo:bar。\n完整的代码，请移步 Github[2]。\n测试\n老规矩，启动之后，我们使用 curl 来测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; HTTP/1.1 401 Unauthorized # valid foo:bar $ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39; HTTP/1.1 200 OK 依旧符合预期。\n总结\n在同步模式下，Go 代码中常规的异步非阻塞也会变成阻塞执行，这是因为 Go 和 Envoy 是两套事件循环体系。\n而通过异步模式，Go 可以在后台异步执行，不会阻塞 Envoy 的事件循环，这样，就可以用上全部的 Go 特性了。\n由 …","date":1684220400,"description":"MoE 系列（四）｜Go 扩展的异步模式","dir":"blog/moe-series (4)-go-extended-asynchronous-mode/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"34088a54a5896da249c7fab7e02b446e","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","publishdate":"2023-05-16T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","summary":"在《MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置》中我们体验了用 Istio 做控制面，给 Go 扩展推送配置，这次我们来体验一下，在 Go 扩展的异步模式下，对 Goroutine 等","tags":["SOFAStack"],"title":"MoE 系列（四）｜Go 扩展的异步模式","type":"blog","url":"/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","wordcount":1459},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议回顾\nSOFAArk：\n主题：SOFAArk 社区会议（月会）\n时间：5 月 8 日 20:00 - 21:30\n会议内容：\n本次社区会议根据议题介绍了近期 SOFAArk 2.2.0 版本发布计划，更新内容预计包含支持 JDK 17 模式下运行、依据 JarLocation 解析 BUG 修复、Benchmark 的一期建设；会议同步了非迭代 issue 进展，包括搭建 SOFAArk Windows 环境 CI、修复因文件路径不支持跨平台导致的资源加载失败问题；介绍了今年开源之夏 SOFAArk 提交的两个项目，邀请社区同学关注与参与；最后，大家一起讨论了 GPT 在 SOFA 工程领域的探索，目前开发同学正在建设基于 ChatGPT + LangChain 的基础工具链，会议中也邀请了社区同学一起共建。\n「会议纪要」：https://github.com/sofastack/sofa-ark/issues/636\n「会议回放」：https://www.bilibili.com/video/BV1Qs4y1D7Lv/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 2023-05-17 社区会议\n时间：5 月 17 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题:\n 2023 开源之夏-课题汇总#894 Discussion：自建各种 Component#902 希望 Layotto 提供高性能的通信交互能力#867 CLA 机器人问题同步 「Layotto」：https://github.com/mosn/layotto/issues/920\nSOFAStack 社区本周贡献\n本周推荐阅读\n【开源之夏 2023】欢迎报名 SOFAStack 社区项目！\n【开源之夏 2023】欢迎报名 MOSN 社区项目！\nKCL v0.4.6 重磅发布！全新的 IDE 插件，Helm/Kustomize/KPT 工具集成\n恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n","date":1683874800,"description":"SOFA Weekly｜SOFAArk 社区会议回顾、Layotto 社区会议预告、社区本周贡献","dir":"blog/sofa-weekly-230512/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3897039aee7e06226e62c5d248b6a953","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230512/","publishdate":"2023-05-12T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230512/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAArk 社区会议回顾、Layotto 社区会议预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230512/","wordcount":1029},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\nDragonfly 项目介绍\nDragonfly 是一个基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱项目 （Sandbox） 。2020 年 4 月，CNCF 技术监督委员会 （TOC） 投票决定接受 Dragonfly 作为孵化项目 （Incubating） 。经过多年生产实践经验打磨的下一代产品，汲取了 Dragonfly 1.x 的优点并针对已知问题做了大量的优化，在解决大规模文件分发场景下有着无可比拟的优势。基于 P2P 技术的优势，在 AI Inference 分发模型场景可以解决大文件分发过程中的性能瓶颈。并且可以通过集成 Dragonfly P2P 技术减少源站压力，提高模型分发效率。在未来，Dragonfly 会结合 AI 领域生态进行拓展，服务 AI 领域并且成为其重要基础设施。\nKata Containers 项目介绍\n自 2013 年 Docker 问世以来，容器技术立刻让全球的开发者为之着迷，并逐渐成为现代应用程序、构建、发布和运维的主流方式。容器以标准格式对应用程序进行封装，应用程序可从一个计算环境快速、安全地切换到另一个计算环境，这对于想要快速构建、测试和部署软件的开发者而言至关重要。然而传统的以 runC 为代表的容器方案基于共享内核技术，通过 Linux 提供的 Cgroups 和 Namespace 等方案进行隔离和控制，如果某一容器中的恶意程序利用了系统缺陷从容器中逃逸，则会对宿主机系统构成严重威胁。尤其是在公有云环境，这一潜在威胁成为了容器技术普及和落地的一大障碍。如果将不同容器再嵌套放入到不同的虚拟机，通过增加一层相对安全、成熟的隔离技术，就能大大提高系统的安全性，减少系统被攻破的可能。基于这种思想的开源技术也随之出现，代表性的两个项目为 Intel 开源技术中心的 Clear Containers 和 Hyper.sh 的 runV。2017 年，这两个开源项目合并，共同创建了开源项目 Kata Containers，其目标是将虚拟机的安全优势与容器的高速及可管理性相结合，为用户提供标准化、安全、高性能的容器解决方案。Kata Containers 创建的不同 Pod （容器） 运行在不同的虚拟机 （Kernel） 之中，比传统容器提供了更好的隔离性和安全性，同时继承了容器快速启动和标准化等优点。\nNydus 项目介绍\n镜像是容器基础设施中的一个重要部分，目前 OCI 标准镜像的缺陷之一是容器需要等待整个镜像数据下载完成后才能启动，这导致了容器启动时消耗了过多的端到端时间。在大规模集群场景下，这对网络与存储负载的影响尤为明显。Nydus 镜像加速框架提供了容器镜像按需加载的能力，它在生产环境里支撑了每日百万级别的加速镜像容器创建，将容器端到端冷启动时间从分钟级降低到了秒级。Nydus 目前由蚂蚁集团，阿里云，字节跳动联合研发，与内核态 EROFS 做了深度集成，也是 Kata Containers 与 Linux 内核态原生支持的镜像加速方案。目前 Nydus 已经被容器生态主流项目支持，例如 Containerd，Docker，Podman，BuildKit, Nerdctl，Kata Containers。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nDragonfly 社区项目\n项目链接： https://summer-ospp.ac.cn/org/orgdetail/72e6f975-d2b8-4fa3-a377-441c1038db10?lang=zh\nPyTorch Serve 基于 Dragonfly P2P 技术分发模型\n导师： yxxhero\n邮箱： aiopsclub@163.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0132?list=org\u0026amp;amp;navpage=org\nTensorFlow Serving 基于 Dragonfly P2P 技术分发模型\n导师： 崔大钧\n邮箱： bigerous@qq.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0022?list=org\u0026amp;amp;navpage=org\nTriton Inference Server 基于 Dragonfly P2P 技术分发模型\n导师： 戚文博\n邮箱： gaius.qi@gmail.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0001?list=org\u0026amp;amp;navpage=org\nKata Containers 社区项目\n项目链接： https://summer-ospp.ac.cn/org/orgdetail/301597a0-ca46-418a-89d1-13ea3c050ee9?lang=zh\n基于 VSOCK FD Passthrough 对 Container IO Stream 进行重构\n导师： 李福攀\n邮箱： fupan.lfp@antgroup.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010451?list=org\u0026amp;amp;navpage=org\nNydus RAFS v6 guest 内核支持优化\n导师： 李亚南\n邮箱： alex.lyn@antgroup.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010419?list=org\u0026amp;amp;navpage=org\n跨容器 shared-mount 支持\n导师： 彭涛\n邮箱： bergwolf@hyper.sh\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010417?list=org\u0026amp;amp;navpage=org\nNydus 社区项目\n项目链接： …","date":1683788400,"description":"【开源之夏 2023】欢迎报名 Dragonfly、Kata Containers、Nydus 社区项目！","dir":"activities/[Summer-2023-of-open-source-promotion-plan]welcome-to-register-for-dragonfly,kata-containers,and-nydus-community-projects!/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d417195ca31984354ab9fba0f7f2cefe","permalink":"https://sofastack.github.io/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","publishdate":"2023-05-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["开源之夏"],"title":"【开源之夏 2023】欢迎报名 Dragonfly、Kata Containers、Nydus 社区项目！","type":"activities","url":"/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","wordcount":2002},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2023 年，MOSN 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2023”，为大家准备了三个任务，涉及 Go、HTTP、Security、Software-Defined Networking、Container 等多个领域。\nMOSN 项目介绍\nMOSN*（Modular Open Smart Network）*是一款基于 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并在双 11 大促期间经过几十万容器的生产级验证。MOSN 为服务提供多协议、模块化、智能化、安全的代理能力，融合了大量云原生通用组件，同时也可以集成 Envoy 作为网络库，具备高性能、易扩展的特点。另外，MOSN 可以集成 Istio 构建 Service Mesh，也可以作为独立的四、七层负载均衡，API Gateway、云原生 Ingress 等使用。\nLayotto 项目介绍\nLayotto（/leɪˈɒtəʊ/） 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，例如状态管理、配置管理、事件发布订阅等，以简化应用的开发。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nMOSN 社区项目\n项目链接：https://summer-ospp.ac.cn/org/orgdetail/f0813e66-fa19-4302-a3e3-e6f2d210c83d?lang=zh\nMOSN\nGo、HTTP、Security\n项目社区导师：罗泽轩\nspacewanderlzx@gmail.com\n基于 Coraza 和 MOSN on Envoy 开发 Envoy 的 WAF 插件\n项目编号：23f080212\n项目难度：进阶/Advanced\nCoraza 是一个用 Go 实现的 WAF 引擎，我们希望能够借助 MOSN on Envoy 的能力，让 Coraza 运行在 Envoy 当中，并与官方的基于 Wasm 的实现*（https://github.com/corazawaf/coraza-proxy-wasm）*进行比较。\n 实现一个基本可用的 WAF 插件*（需要有详尽的文档+测试）*，并与 Wasm 版本做对比，输出一份比较报告。 了解 MOSN、Envoy 和 WAF，能够用 Go 写代码。 MOSN\nGo、Software-Defined Networking\n项目社区导师：纪卓志\njizhuozhi.george@gmail.com\n为 Envoy Go 扩展建设插件市场\n项目编号：23f080259\n项目难度：进阶/Advanced\nEnvoy 是当前最流行的网络代理之一，Go 扩展是 MOSN 社区为 Envoy 增加的 Go 生态基础，也是 MOSN 社区 MoE 框架的基础。\n受益于 Golang 生态系统，研发可以轻松在 Envoy 实现插件用于更多的长尾场景，其中很多场景都是通用的。\n本项目是为 Envoy Go 扩展构建插件市场。在插件市场中，人们可以在插件市场中分享插件，选用已经存在的插件。通过插件市场，可以让 Envoy、MoE 生态变得更加开放、共享、丰富。\n 提供一个 Envoy Go 插件的内容平台，在这里可以发布经过社区 Review 的优秀插件，需要拥有服务端与前端页面。\n 不自建账号体系，通过 GitHub OAuth2.0 完成用户认证与授权。\n 进阶——对接 GitHub OpenAPI，支持动态获取插件所在仓库信息，包括 README、分支版本以及 Star 数。\n 能够使用 Go 语言*（框架不限）*开发出带前端页面的小型站点。\n 对认证与授权及 OAuth2.0 有基本的了解。\n 熟悉 Git 和 GitHub 工作流程*（分支、版本、合并请求等）*。\n Layotto\nGo、gRPC\n项目社区导师：wenxuwan\nwangwenxue.wwx@antgroup.com\nLayotto Support Pluggable Components\n项目编号：23f080194\n项目难度：进阶/Advanced\n当前 Layotto 的 Components 都是实现在 Layotto 的工程里面的。用户若要想使用新的 Component，就必须使用 Golang 语言开发，同时必须在 Layotto 工程中实现，然后统一编译。对于多语言用户来说非常不友好，因此 Layotto 需要提供 Pluggable Components 的能力，允许用户可以通过任何语言实现自己的 Components，Layotto 通过 gRPC 协议和外部的 Components 进行通信。\n 完成 Pluggable Components 框架设计。\n 提供 Pluggable Components 接入文档和示例。\n 熟悉 Golang 和 gRPC，熟悉 Dapr 和 Layotto 运行时架构。\n 申请资格\n 本活动面向年满 18 周岁在校学生。\n 暑期即将毕业的学生，只要在申请时学生证处在有效期内，就可以提交申请。\n 中国籍学生参与活动需提供身份证、学生证、教育部学籍在线验证报告（学信网）或在读证明。\n 外籍学生参与活动需提供护照，同时提供录取通知书、学生卡、在读证明等文件用于证明学生身份。\n 活动流程\n添加 SOFAGirl 微信\n备注“开源之夏”进群交流\n","date":1683615600,"description":"【开源之夏 2023】欢迎报名 MOSN 社区项目！","dir":"activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project!/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1bdbf9f33dd6670508117cc1e5e907df","permalink":"https://sofastack.github.io/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","publishdate":"2023-05-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["开源之夏"],"title":"【开源之夏 2023】欢迎报名 MOSN 社区项目！","type":"activities","url":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","wordcount":1852},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nSOFAArk：\n主题：SOFAArk 2023-05-08 社区会议\n时间：5 月 8 日（下周一）20:00-21:30\n入会口令（钉钉）：683 550 26227\n电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题：\n 近期版本发布计划和内容 非迭代 issue 处理同步 开源之夏活动介绍 GPT 在 SOFA 工程领域的探索 「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/636\nLayotto：\n主题：Layotto 2023-05-10 社区会议\n时间：5 月 10 日（下周三）14:00-15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题/导师招募 Discussion：自建各种 Component 希望 Layotto 提供高性能的通信交互能力 CLA 机器人问题同步 「Layotto」：https://github.com/mosn/layotto/issues/915\nMOSN 社区：\n 基于 coraza 和 MOSN on Envoy 开发 Envoy 的 WAF 插件 导师：罗泽轩\n联系邮箱：spacewanderlzx@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080212?lang=zh\u0026amp;amp;list=pro\n 为 Envoy Go 扩展建设插件市场 导师：纪卓志\n联系邮箱：jizhuozhi.george@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080259?list=org\u0026amp;amp;navpage=org\nLayotto 社区：\n Layotto 支持自动/手动注入 Pod 部署 导师：刘训灼\n联系邮箱：mixdeers@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/2395a0359?list=org\u0026amp;amp;navpage=org\n Layotto Support Pluggable Components 导师：王文学\n联系邮箱：wangwenxue.wwx@antgroup.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080194?list=org\u0026amp;amp;navpage=org\n社区本周贡献\n本周推荐阅读\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\n如何看待 Dapr、Layotto 这种多运行时架构？\n应用运行时 Layotto 进入 CNCF 云原生全景图\n","date":1683270000,"description":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","dir":"blog/sofa-weekly-0505/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d9d0126ce61dc5e57710e2db403ca34e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0505/","publishdate":"2023-05-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0505/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜开源之夏 MOSN 与 Layotto 项目简介、社区会议预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0505/","wordcount":1039},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2023 年，SOFAStack 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2023”，一共为大家准备了五个任务，涵盖 SOFARPC、SOFAArk、SOFAJRaft 和 Layotto 等核心项目，涉及 Golang、Java、Kubernetes、Cloud Native、Distributed System 等多个领域。\nSOFARPC 项目介绍\nSOFARPC 是由蚂蚁集团开源的一款 Java RPC 框架，具有高可扩展性、高性能和生产级特性。该框架旨在简化应用之间的 RPC 调用，并为应用提供便捷透明、稳定高效的点对点远程服务调用方案。为方便用户和开发者进行功能扩展，SOFARPC 提供了丰富的模型抽象和可扩展接口，包括过滤器、路由、负载均衡等。\nSOFAArk 项目介绍\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，由蚂蚁集团开源贡献。该容器主要提供类隔离和应用（模块）合并部署能力。SOFAArk 提供多种方式来支持多应用（模块）合并部署，包括基于命令行的管控、基于 API 的管控等。\nSOFAJRaft 项目介绍\nSOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，适用于高负载低延迟的场景，支持 MULTI-RAFT-GROUP。使用 SOFAJRaft 可专注于业务领域，由 SOFAJRaft 解决与 RAFT 相关的技术难题。并且 SOFAJRaft 易于使用，可以通过几个示例快速掌握它。\nLayotto 项目介绍\nLayotto(/leɪˈɒtəʊ/) 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，例如状态管理、配置管理、事件发布订阅等，以简化应用的开发。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nSOFAStack 社区项目\n项目链接：https://summer-ospp.ac.cn/org/orgdetail/95a9e459-a200-4a26-bc0a-81074c2d89be?lang=zh\nSOFARPC\nJava、网络通信、RPC\n项目社区导师：EvenLiu\nevenljj@163.com\nSOFARPC 支持 Stream 流式处理方式\n项目编号：2395a0260\n项目难度：进阶/Advanced\nStream 方式是一种异步的流式处理方式，可以在数据传输过程中逐个处理数据，避免一次性传输大量数据造成的性能问题。服务端 Stream 是指服务端在处理请求时，将数据分成多个部分逐个返回给客户端的过程；客户端 Stream 是指客户端在请求服务器时，将请求参数分成多个部分逐个发送给服务器的过程。Stream 方式可以让我们在处理大量数据时更高效地使用资源，提高系统的性能和响应速度。SOFARPC 中需要 Triple、Bolt 协议支持 Stream 方式流式处理。\n SOFARPC 中 Triple 协议支持 Stream 流式处理。\n SOFARPC 中 Bolt 协议支持 Stream 流式处理。\n SOFAArk\nJava、SOFAArk 源代码\n项目社区导师：卫恒\nglmapper_2018@163.com\n开发一个客户端，支持 Biz 模块的热部署和热卸载，初步实现 Serverless 体验\n项目编号：2395a0267\n项目难度：基础/Basic\nSOFAArk 从最初的一个类隔离框架，逐步演进为支持合并部署与热部署的 “Serverless” 运行时框架，尤其在去年我们完成了 SOFAArk1.0 到 2.0 架构的演进。但是为了让开发者真正享受 Serverless 的研发体验，我们还需要建设一个客户端框架，对接 SOFAArk 实现 Biz 模块的热部署和热卸载，并暴露 HTTP API 接口可以让上游系统或者开发者直接使用。\n 设计并开发一个新的 SDK（SOFALet），新的 SDK 也就是 SOFALet 暴露一组 HTTP 接口，底层调用 SOFAArk 原子能力实现模块的热部署和热卸载。SOFALet 未来还会有 Node.js 版，这一期先支持 Java 版也就是对接 SOFAArk。\n 理解 SOFAArk 源代码，尤其是关于 telnet 指令安装和卸载模块的部分。\n SOFAArk\nGo、K8s\n项目社区导师：流铄\nxujinle300@126.com\n开发一个 K8s Operator，编排客户端 API 实现 Biz 模块的热部署，初步达成 Serverless 研发体验\n项目编号：2395a0392\n项目难度：基础/Basic\n为了让开发者真正享受 Serverless 的研发体验，我们需要先建设一个简易的 K8s Operator 和 SOFA Module Deployment、SOFA Module ReplicaSet CRD，对接编排模块热装载和热卸载的客户端，实现模块秒级发布的初步能力，让开发者能初步体验到 Serverless 的发布运维能力。\n 理解 SOFAArk 模块安装和卸载部分的源代码，并且熟悉 K8s CRD 和 Operator 体系的设计与开发。 SOFAJRaft\nJava、网络通信、RPC\n项目社区导师：刘源远\ngege87417376@qq.com\n结合 NWR 实现 Flexible RAFT，用于自定义 Quorum 的大小\n项目编号：2395a0390\n项目难度：进阶/Advanced\nJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，它运行过程分为两个阶段，即 Leader 选举和日志复制。在原始的 RAFT 算法中，Leader 选举和日志复制都需要获得多数派成员的支持。而 NWR 模型则可以在动态调整一致性强度的场景中使用，它需要满足 W+R\u0026amp;gt;N，以保证强一致性。JRaft 将 RAFT 和 NWR 结合起来，使得用户可以根据不同的业务需求来动态调整 Quorum 的数量。例如，在一个写多读少的场景中，用户可以将多数派的数量从 3 调整为 2，以降低达成共识的条件，从而提高写请求的效率。同时，为了保证 RAFT 的正确性，写 Quorum 的调整需要付出代价，即读 Quorum 的数量也需要相应调整。JRaft 支持成员变更，因此用户可以配置 (0,1] 范围内的小数来计算 W 和 R 的具体值。通过使用 JRaft，用户可以根据自己的业务需求来灵活地调整 …","date":1683270000,"description":"【开源之夏 2023】欢迎报名 SOFAStack 社区项目！","dir":"activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"def1ba20e3e6b79b6b9e2c6bae16ba91","permalink":"https://sofastack.github.io/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","publishdate":"2023-05-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["SOFAStack 开源之夏"],"title":"【开源之夏 2023】欢迎报名 SOFAStack 社区项目！","type":"activities","url":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","wordcount":2742},{"author":null,"categories":"SOFAStack","content":"上一篇我们用 Go 扩展实现了 Basic Auth，体验了 Go 扩展从 Envoy 接受配置。\n之所以这么设计，是想复用 Envoy 原有的 xDS 配置推送通道，今天我们就来体验一番，云原生的配置变更。\n前提准备\n这次我们需要一套 K8s 环境，如果你手头没有，推荐使用 Kind 安装一套。具体安装方式，这里就不展开了。\n安装 Istio\n我们直接安装最新版的 Istio：\n# 下载最新版的 istioctl$ export ISTIO_VERSION=1.18.0-alpha.0$ curl -L https://istio.io/downloadIstio | sh - # 将 istioctl 加入 PATH$ cd istio-$ISTIO_VERSION/$ export PATH=$PATH:$(pwd)/bin # 安装，包括 istiod 和 ingressgateway$ istioctl install 是的，由于 Go 扩展已经贡献给了上游官方，Istiod（Pilot）和 Ingress Gateway 都已经默认开启了 Go 扩展，并不需要重新编译。\nIstio 配置 Ingress\n我们先用 Istio 完成标准的 Ingress 场景配置，具体可以看 Istio 的官方文档[1]。\n配置好了之后，简单测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot;HTTP/1.1 200 OKserver: istio-envoydate: Fri, 10 Mar 2023 15:49:37 GMT 基本的 Ingress 已经跑起来了。\n挂载 Golang so\n之前我们介绍过，Go 扩展是单独编译为 so 文件的，所以，我们需要把 so 文件，挂载到 Ingress Gateway 中。\n这里我们把上次 Basic Auth 编译出来的 libgolang.so，通过本地文件挂载进来。简单点搞，直接 edit deployment 加了这些配置：\n# 申明一个 hostPath 的 volumevolumes:- name: golang-so-basic-auth hostPath: path: /data/golang-so/example-basic-auth/libgolang.so type: File # 挂载进来volumeMounts:- mountPath: /etc/golang/basic-auth.so name: golang-so-basic-auth readOnly: true 开启 Basic Auth 认证\nIstio 提供了 EnvoyFilter CRD，所以，用 Istio 来配置 Go 扩展也比较方便，apply 这段配置，Basic Auth 就开启了。\napiVersion: networking.istio.io/v1alpha3kind: EnvoyFiltermetadata: name: golang-filter namespace: istio-systemspec: configPatches: # The first patch adds the lua filter to the listener/http connection manager - applyTo: HTTP_FILTER match: context: GATEWAY listener: filterChain: filter: name: \u0026amp;quot;envoy.filters.network.http_connection_manager\u0026amp;quot; subFilter: name: \u0026amp;quot;envoy.filters.http.router\u0026amp;quot; patch: operation: INSERT_BEFORE value: # golang filter specification name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: \u0026amp;quot;type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config\u0026amp;quot; library_id: example library_path: /etc/golang/basic-auth.so plugin_name: basic-auth plugin_config: \u0026amp;quot;@type\u0026amp;quot;: \u0026amp;quot;type.googleapis.com/xds.type.v3.TypedStruct\u0026amp;quot; type_url: typexx value: username: foo password: bar 虽然有点长，但是，也很明显，配置的用户名密码还是：foo:bar。\n测试\n我们测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot;HTTP/1.1 401 Unauthorized # valid foo:bar$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39;HTTP/1.1 200 OK 符合预期。\n接下来，我们改一下 EnvoyFilter 中的密码，重新 apply，再测试一下：\n# foo:bar not match the new password$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39;HTTP/1.1 401 Unauthorized 此时的 Envoy 并不需要重启，新的配置就立即生效了，云原生的体验就是这么溜~\n总结\n因为 Go 扩展可以利用 Envoy 原有的 xDS 来接受配置，所以，从 Istio 推送配置也变得很顺利。\n不过，Istio 提供的 EnvoyFilter CRD 在使用上，其实并不是那么方便和自然，后面我们找机会试试 Envoy Gateway，看看 K8s Gateway API 的体验如何。\n至此，我们已经体验了整个 Envoy Go 的开发\u0026amp;amp;使用流程，在云原生时代，人均 Golang 的背景下，相信可以很好的完成网关场景的各种定制需求。\n下一篇，我们将介绍，如何在 Go 扩展中使用异步 …","date":1683010800,"description":"MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置","dir":"blog/moe-series (3)｜dynamic-update-of-go-extension-configuration-with-istio/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1683010800,"objectID":"5ff7cec6ed4b29c51c1f65f47b32672c","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","publishdate":"2023-05-02T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","summary":"上一篇我们用 Go 扩展实现了 Basic Auth，体验了 Go 扩展从 Envoy 接受配置。 之所以这么设计，是想复用 Envoy 原有的 xDS 配置推送通道，今天我们就来体验一番，云原生的","tags":["SOFAStack"],"title":"MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置","type":"blog","url":"/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","wordcount":974},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nSOFAArk：\n主题：SOFAArk 社区会议\n时间：5 月 8 日 20:00 - 21:30\n入会口令（钉钉）：683 550 26227\n电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题：\n 近期版本发布计划和内容。 非迭代 issue 处理同步。 开源之夏活动介绍。 GPT 在 SOFA 工程领域的探索。 「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/636\n每月一次的 SOFAArk 社区会议要开啦！有对议题感兴趣的同学不要错过哦～\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：4 月 26 日 14:00 - 15:00\n会议内容：\n本次社区会议根据议题同步了 2023 开源之夏申报的课题，并号召社区同学踊跃参与；对于自建各种组件，会议详细讲解了问题痛点与解决方案；Layotto 在升级 gRPC 版本时出现的前置依赖问题，会议中的同学提出了方案；在会议的最后，同步了 CLA 机器人解决的进展与办法。\n「Layotto」：https://github.com/mosn/layotto/issues/915\n「会议回放」：https://www.bilibili.com/video/BV1Qg4y177dG/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@huayangchan #914\n 下载 Layotto-0.5.0 源码，在本地 Windows 系统编译启动时，报一些函数和变量未定义错误，如 undefined: syscall.GetsockoptIPv 6Mreq，这应该是 Unix 系统才调用的函数，为什么在 Windows 系统运行会调 Unix 系统相关的函数，还说源码只能在 Unix 系统上便已启动?\n A：Layotto 是基于 MOSN 为底座的，用到了 Linux 的系统函数，所以不支持 Windows 上的编译。可以参考：https://github.com/mosn/layotto/issues/801\n「Layotto」：https://github.com/mosn/layotto/issues/914\n2.@shuangchengsun #263\n 图片展示了实例（Client）的上下线过程， 假设这么一个场景，Client1 处于下线过程中，此时它已经和 Session Server 断链，但是 Session Server 在发出同步通知前因为某种原因挂了，此时 Client1 在路由表中的状态是如何维护的？\n A: Data 上有一个定时器去维护每个 Session 相关数据的。如果 Session 挂了，Data 大约 30s 后把挂掉的 Session 的数据清理掉，同时链接挂掉的 Client（除了要下线的那个）会自动重连到其他 Session 上。然后会把数据增长一个 Version 重新注册到 Session，Session 会再次发到那台 Data 上。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/issues/263\n本周推荐阅读\n缘起｜蚂蚁应用级服务发现的实践之路\nSOFARegistry 源码｜数据同步模块解析\nMoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\n","date":1682665200,"description":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","dir":"blog/sofa-weekly-20230428/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f7cd5d7b9340442e111c4dfeaf5a6813","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230428/","publishdate":"2023-04-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230428/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230428/","wordcount":1451},{"author":null,"categories":"SOFAStack","content":"文｜蚂蚁集团 ZOLOZ 团队\n使用全球领先安全科技，为用户和机构提供安全、便捷的安全风控解决方案。\n本文 6386 字 阅读 12 分钟\n背景简介\nZOLOZ[1]是蚂蚁集团旗下的全球安全风控平台，通过业内领先的生物识别、大数据分析和人工智能技术，为用户和机构提供安全又便捷的安全风控解决方案。ZOLOZ 已为中国、印尼、马来西亚、菲律宾等 14 个国家和地区的 70 余家合作伙伴提供数字化转型过程中的安全风控技术支持。目前，已经覆盖金融、保险、证券、信贷、电信、公众服务等领域，累计服务用户超 12 亿。\n随着 Kubernetes 和云原生的大爆发，ZOLOZ 应用开始在公有云上进行大规模容器化部署。ZOLOZ 业务的镜像经过长期维护和更新，无论是镜像层数还是整体大小都达到了一个较大的量级 （数百 MB 或者几个 GB） 。特别是 ZOLOZ AI 算法推理应用的基础镜像大小要远大于一般应用镜像 （Docker Hub 上 PyTorch/PyTorch：1.13.1-CUDA 11.6-cuDNN 8-Runtime 有 4.92GB，同比 CentOS：latest 只有约 234MB） ，对于容器冷启动，即在本地无镜像的情况下，需要先从 Registry 下载镜像才能创建容器，在生产环境中，容器的冷启动往往耗时数分钟，并且随规模扩大会导致 Registry 因集群内网络拥堵而无法快速地下载镜像，如此庞大的镜像给应用的更新和扩容等操作都带来了不少挑战。在公有云上容器化持续推进的当下，ZOLOZ 应用主要遇到了三大挑战：\n 算法镜像大，推送到云上镜像仓库耗时长，开发过程中，在使用测试环境进行测试时，往往希望快速迭代，快速验证，但是每次改完一个分支发布验证都要经过几十分钟，开发效率十分低下。\n 拉取算法镜像耗时长，在集群扩容大量机器拉取镜像文件会容易导致集群网卡被打满，影响业务正常运行。\n 集群机器拉起时间长，难以满足流量突增时，弹性自动扩缩容。\n 虽然也尝试过各种折中的解决方案，但这些方案都有缺陷，现在结合蚂蚁、阿里云、字节跳动等多个技术团队打造了一套更通用的公有云上解决方案，该方案改造成本低，性能好，目前看来是比较理想的方案。\n术语及定义\nOCI：Open Container Initiative，开放容器计划是一个 Linux 基金会项目，由 Docker 在 2015 年 6 月启动，旨在为操作系统级虚拟化 （最重要的是 Linux 容器） 设计开放标准。\nOCI Manifest：遵循 OCI Image Spec 的制品。\nBuildKit：是 Docker 公司出品的一款更高效、Dockerfile 无关、更契合云原生应用的新一代 Docker 构建工具。\n镜像：本文中的镜像指 OCI Manifest，也包括 Helm Chart 等其他 OCI Manifest。\n镜像仓库：遵循 OCI Distribution Spec 实现的制品仓库。\nECS：是一种由 CPU、内存、云盘组成的资源集合，每一种资源都会逻辑对应到数据中心的计算硬件实体。\nACR：阿里云镜像仓库服务。\nACK：阿里云容器服务 Kubernetes 版提供高性能可伸缩的容器应用管理能力，支持企业级容器化应用的全生命周期管理。\nACI：ACI 全称 Ant Continuous Integration （AntCI） ，是蚂蚁集团研发效能旗下一款以流水线 （Pipeline） 为核心的 CI/CD 效能产品。使用智能自动化构建、测试和部署，提供了以代码流为输入的轻量级持续交付解决方案，提高团队研发的工作效率。\nPrivate Zone：基于专有网络 VPC （Virtual Private Cloud） 环境的私有 DNS 服务。该服务允许在自定义的一个或多个 VPC 中将私有域名映射到 IP 地址。\nP2P：点对点技术，当 P2P 网络中某一个 Peer 从 Server 下载数据的时候，下载完数据后也能当作服务端供其他 Peer 下载。当大量节点同时下载的时候，能保证后续下载的数据，可以不用从 Server 端下载。从而减轻 Server 端的压力。\nDragonfly：Dragonfly 是⼀款基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。现在为云原生计算机基金会 （CNCF） 托管作为孵化级项目。\nNydus：Nydus 镜像加速框架是 Dragonfly 的子项目，它提供了容器镜像按需加载的能力，在生产环境支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，端到端数据一致性，内核态支持等方面相比 OCIv1 有巨大优势。\nLifseaOS：面向容器场景，阿里云推出轻量、快速、安全、镜像原子管理的容器优化操作系统，相比传统操作系统软件包数量减少 60%，镜像大小减少 70%，OS 首次启动从传统 OS 的 1min 以上下降到了 2s 左右。支持镜像只读和 OSTree 技术，将 OS 镜像版本化管理，更新操作系统上的软件包、或者固化的配置时，以整个镜像为粒度进行更新。\n方案设计\n解决镜像大的问题\n1. 精简基础 镜像 大小\n基础 OS 从 CentOS 7 改为 AnolisOS 8，精简运维工具的安装，只默认安装一些必须的工具列表 （基础运维工具、运行时通用依赖、日志清理、安全基线等组件） ，并简化安全加固的配置，基础镜像从 1.63GB 减少到 300MB。\nAnolisOS 仓库：https://hub.docker.com/r/openanolis/anolisos/tags\n2. Dockerfile 优化\n通过 Dockerfile 编写约束、镜像检测等手段减少不必要的构建资源和时间。\nDockerfile 最佳实践原则: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/\n3. 并行构建和构建缓存\n蚂蚁构建中心采用 Nydus 社区优化版的 BuildKit[2]，BuildKit 支持 layer 级别缓存，准确引用先前的产出物并进行缓存匹配，使用方法与普通镜像并无区别，对于 Multistage 类型 Dockerfile，BuildKit 可以实现不同 stage 之间的并行执行。\n推送到云上镜像仓库耗时长\n1. 使用 Nydus 镜像进行块级别数据去重\n传统 OCI 镜像，不同镜像之间可以共享的最小单位是镜像中的层，在 deduplication 上的效率是非常低的，层内部存在重复的数据，层与层之间可能存在大量重复的数据，即使有微小的差别，也会被作为不同的层，根据 OCI Image Spec 对删除文件和 Hard Link 的设计，一个镜像内部可能存在已经被上层删除的文件仍然存在于下层中，并包含在镜像中。另外 OCI Image 使用了 tar+gzip 格式来表达镜像中的层，而 tar 格式并不区分 tar archive entries ordering， …","date":1682492400,"description":"蚂蚁安全科技 Nydus 镜像加速实践","dir":"blog/ant-security-technology-nydus-mirror-acceleration-practice/","fuzzywordcount":8700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c89b17510ce48eb33633af0051249102","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","publishdate":"2023-04-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","summary":"文｜蚂蚁集团 ZOLOZ 团队 使用全球领先安全科技，为用户和机构提供安全、便捷的安全风控解决方案。 本文 6386 字 阅读 12 分钟 背景简介 ZOLOZ[1]是蚂蚁集团旗","tags":["SOFAStack"],"title":"蚂蚁安全科技 Nydus 镜像加速实践","type":"blog","url":"/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","wordcount":8656},{"author":null,"categories":"SOFA WEEKLY","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：4 月 19 日 14:00 - 15:00\n会议内容：\n本次社区会议根据议题探讨了 2023 开源之夏申报课题的具体方式和内容，并号召同学踊跃参与报名；对于自建组件问题，方案已经敲定，感兴趣的同学可以尝试；Layotto 在升级 gRPC 版本时出现前置依赖问题，并在会议中同步进展；关于 CLA 机器人出现的问题，社区同学共同讨论了提供解决的思路。\n「Layotto」：https://github.com/mosn/layotto/issues/907\n「会议回放」：https://www.bilibili.com/video/BV1aT411p7cr/?share_source=copy_web\u0026amp;amp;vd_source=802e089175dbc2ea677914f78683b18a\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 2023-04-26 社区会议\n时间：4 月 26 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2344343024\n议题：\n 2023 开源之夏-课题/导师招募#894\n Discussion：自建各种 Component#902\n 希望 Layotto 提供高性能的通信交互能力#867\n 「Layotto」：https://github.com/mosn/layotto/issues/907\nSOFA 五周年资料已上传 SOFAStack 官网\n回复公众号：“SOFA 五周年”\n即可获取链接啦～\n还可戳“阅读原文”跳转哦！\nSOFAStack 社区本周贡献\nSOFARPC 5.10.0 版本发布\n发布 SOFARPC 5.10.0 版本，主要变更如下:\n 重构了自定义序列化器的注册模式，使得主站版可以覆盖开源版的注册#1296\n 修改了反序列化时 Request Header 的处理逻辑#1325\n 更新了 Javassist Proxy 构造 class 时的 API 使之能在 JDK17 环境下运行#1316\n 详细发布报告：https://github.com/sofastack/sofa-rpc/compare/v5.9.2\u0026amp;hellip;v5.10.0\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n @LY1806620741 #1061 com.alipay.sofa.rpc.enable-swagger 是否已经废弃？在 3.16.3\ncom.alipay.sofa.rpc.enable-swagger=true 配置使用了 Objectway 的 ASM，与 Spring Boot 的 ASM 冲突。\n A：可以手动增加一个依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.ow2.asm\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;asm\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;9.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 看起来是 https://github.com/sofastack/sofa-rpc/blob/5.8.3.1/all/pom.xml 少添加了一个 ASM 的依赖，导致出现上面的问题。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n @Estom#642 多 Host 模式下，动态部署，无法启动第二个 Tomcat。需要添加特殊的配置吗？\n A：多 Host 模式配置建议看一下这份文档 https://www.sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/中的“6.多 Host 与单 Host 模式”。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/642\n","date":1682060400,"description":"SOFA Weekly｜SOFARPC 5.10.0 版本发布、SOFA 五周年回顾、Layotto 社区会议回顾与预告","dir":"blog/sofa-weekly-0421/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4477f615201d81a1e6578f20f910a5d2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0421/","publishdate":"2023-04-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0421/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA WEEKLY"],"title":"SOFA Weekly｜SOFARPC 5.10.0 版本发布、SOFA 五周年回顾、Layotto 社区会议回顾与预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0421/","wordcount":1547},{"author":null,"categories":"SOFAStack","content":"文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 1445 字 阅读 5 分钟\n上一篇我们用一个简单的示例，体验了用 Golang 扩展 Envoy 的极速上手。\n这次我们再通过一个示例，来体验 Golang 扩展的一个强大的特性：\n从 Envoy 接收配置。\nBasic Auth\n我们还是从一个小示例来体验，这次我们实现标准的 Basic Auth 的认证，与上一次示例不同的是，这次认证的用户密码信息，需要从 Envoy 传给 Go，不能在 Go 代码中写死了。\n完整的代码可以看 example-basic-auth[1]，下面我们展开介绍一番。\n获取配置\n为了更加灵活，在设计上，Envoy 传给 Go 的配置是 Protobuf 的 Any 类型，也就是说，配置内容对于 Envoy 是透明的，我们在 Go 侧注册一个解析器，来完成这个 Any 配置的解析。\n如下示例：\nfunc init() { // 注册 parser http.RegisterHttpFilterConfigParser(\u0026amp;amp;parser{}) } func (p *parser) Parse(any *anypb.Any) interface{} { configStruct := \u0026amp;amp;xds.TypedStruct{} if err := any.UnmarshalTo(configStruct); err != nil { panic(err) } v := configStruct.Value conf := \u0026amp;amp;config{} if username, ok := v.AsMap()[\u0026amp;quot;username\u0026amp;quot;].(string); ok { conf.username = username } if password, ok := v.AsMap()[\u0026amp;quot;password\u0026amp;quot;].(string); ok { conf.password = password } return conf } 这里为了方便，Any 中的类型是 Envoy 定义的 TypedStruct 类型，这样我们可以直接使用现成的 Go pb 库。\n值得一提的是，这个配置解析，只有在首次加载的时候需要执行，后续在 Go 使用的是解析后的配置，所以，我们解析到一个 Go map 可以拥有更好的运行时性能。\n同时，由于 Envoy 的配置，也是有层级关系的，比如 http-filter, virtual host, router, virtual clusters 这四级，我们也支持这四个层级同时有配置，在 Go 侧来组织 merge。\n当然，这个只有在 Go 侧有复杂的 filter 组织逻辑的时候用得上，后面我们在 MOSN 的上层封装的时候，可以看到这种用法，这里暂时不做展开介绍。\n认证\n具体的 Basic Auth 认证逻辑，我们可以参考 Go 标准 net/http 库中的 Basic Auth 实现。\nfunc (f *filter) verify(header api.RequestHeaderMap) (bool, string) { auth, ok := header.Get(\u0026amp;quot;authorization\u0026amp;quot;) if !ok { return false, \u0026amp;quot;no Authorization\u0026amp;quot; } username, password, ok := parseBasicAuth(auth) if !ok { return false, \u0026amp;quot;invalid Authorization format\u0026amp;quot; } if f.config.username == username \u0026amp;amp;\u0026amp;amp; f.config.password == password { return true, \u0026amp;quot;\u0026amp;quot; } return false, \u0026amp;quot;invalid username or password\u0026amp;quot; } 这里面的 parseBasicAuth 就是从 net/http 库中的实现，是不是很方便呢。\n配置\n简单起见，这次我们使用本地文件的配置方式。如下是关键的配置：\nhttp_filters: - name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config library_id: example library_path: /etc/envoy/libgolang.so plugin_name: basic-auth plugin_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/xds.type.v3.TypedStruct value: username: \u0026amp;quot;foo\u0026amp;quot; password: \u0026amp;quot;bar\u0026amp;quot; 这里我们配置了用户名密码：foo:bar。\n预告一下，下一篇我们会体验通过 Istio 来推送配置，体会一番动态更新配置的全流程。\n测试\n编译，运行，跟上篇一样，我们还是使用 Envoy 官方提供的镜像即可。\n跑起来之后，我们测试一下：\n$ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; HTTP/1.1 401 Unauthorized # invalid username:password $ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;Authorization: basic invalid\u0026#39; HTTP/1.1 401 Unauthorized # valid foo:bar $ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39; HTTP/1.1 200 OK 是不是很简单呢，一个标准的 Basic Auth 扩展就完成了。\n总结\nEnvoy 是面向云原生的架构设计，提供了配置动态变更的机制，Go 扩展可以从 Envoy 接受配置，也就意味着 Go 扩展也可以很好的利用这套机制。\nGo 扩展的开发者，不需要关心配置的动态更新，只需要解析配置即可，非常的方便~\n下一篇我们会介绍，配合 Istio 来动态更新用户名密码，体验一番云原生的配置变更体验。\n后续还有更多 Golang 扩展的特性介绍，原理解析，以及，更上层的 MOSN 集成体验，欢迎持续关注。\n[1]example-basic-auth： …","date":1681801200,"description":"MoE 系列（二）｜Golang 扩展从 Envoy 接收配置","dir":"blog/moe-series (2)｜golang-extensions-receive-configuration-from-envoy/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1681801200,"objectID":"f19954b7d5ae3122eec6e6599e9d1be2","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","publishdate":"2023-04-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 1445 字 阅读 5 分钟 上一篇我","tags":["SOFAStack"],"title":"MoE 系列（二）｜Golang 扩展从 Envoy 接收配置","type":"blog","url":"/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","wordcount":1147},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFA 五周年，Live Long and Prosper！\n 活动时间：04 月 15 日 12:00\u0026amp;ndash;17:00\n 活动形式：线下 Meetup + 线上直播\n 资料下载：\n 《SOFAStack 的下一个五年》\n《京东搜索基于Service Mesh的微服务治理探索与实践》\n《顺丰应用运行时落地实践》\n《Seata发展之路——昨天、今天、明天》\n《蚂蚁注册中心建设的思考与实践》\n B 站直播间地址：http://live.bilibili.com/21954520 介绍 2018 年 4 月 19 日，我们在北京启程，伴随种下希望的种子，举办了 SOFAStack 社区的第一个开放日。\n转眼来到 2023 年，瑞兔送福又逢春暖花开，怀揣着新的愿景，我们于 4 月 15 日回到北京庆祝 SOFA 的五岁生日。🎂\n今年的主题「Live Long and Prosper」相信对于不少“星际迷航”粉丝来说都已经耳熟能详了。这是瓦肯人在举瓦肯手礼的时候会说的祝词，却也非常符合 SOFAStack 开源社区的愿景。\n我们希望无论是 SOFAStack 社区项目，还是 SOFA 的生态伙伴，都能够“Live Long and Prosper”！👽\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 宋顺（花名：齐天），SOFAStack 社区开源负责人\n 王志龙，京东集团架构师、MOSN Contributor\n 杨定朝，顺丰集团高级研发工程师、Layotto 用户\n 李宗杰（花名：白鹰），Seata 蚂蚁开源负责人\n 肖健（花名：昱恒），SOFARegistry Maintainer\n 议程 直播回放 https://www.bilibili.com/video/BV1vL411e78B/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1681542000,"description":"2023 年 4 月 15 日，我们在北京一起庆祝了 SOFA 社区的五岁生日。","dir":"activities/sofa-anniversary-5/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3e1d3b14932e3e3e091b5cbce4868d80","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-anniversary-5/","publishdate":"2023-04-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-anniversary-5/","summary":"概要 活动主题：SOFA 五周年，Live Long and Prosper！ 活动时间：04 月 15 日 12:00\u0026ndash;17:00 活动形式：线下 Meetup + 线上直播 资料下载： 《SOFAStack 的下","tags":["SOFAStack","开源五周年"],"title":"SOFA 五周年，Live Long and Prosper！","type":"activities","url":"/sofastack.tech/activities/sofa-anniversary-5/","wordcount":633},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n**1.@SOFAJRaft **#965 提问：\n@a364176773\n RheaKV 中的 RocksDB 为何不支持选择其他压缩方式和压缩风格？\n貌似可以靠StorageOptionsFactory.registerRocksDBOptions注册进去，这样就不会走 default 了？\n A：是的，可以设置自己的选项。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/965\n2.@SOFARPC#1320\n@Misakami\n Spring Boot 3.1 + JDK 17 SOFARPC 显示发布成功但是客户端获取不到服务。\n A：看上去获取不到服务和 JDK17 并没有直接的联系。可以先确认:\n 服务端是否将自身地址发布到注册中心；\n 客户端是否接收到注册中心的推送。\n 「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1320\n本周推荐阅读\n缘起｜蚂蚁应用级服务发现的实践之路\nSOFARegistry | 聊一聊服务发现的数据一致性\nGo 语言，如何做逆向类型推导\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n","date":1681455600,"description":"SOFA Weekly｜SOFA 开源五周年来自社区家人的祝福、社区本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230414/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4e553c30969c289fec68bf7f78424e0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230414/","publishdate":"2023-04-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230414/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 开源五周年来自社区家人的祝福、社区本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230414/","wordcount":657},{"author":null,"categories":"SOFAStack","content":"文｜肖健（花名：昱恒）\n蚂蚁集团技术专家、SOFARegistry Maintainer\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。\n本文 8339 字 阅读 15 分钟\nPART. 1\n前言\n什么是服务发现？\n我们今天主要聊的话题是“应用级服务发现”的实践，聊这个话题之前，我们先简单介绍一下什么是“服务发现”，然后再聊聊，为什么需要“应用级服务发现”。\n在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信，而这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\n图 1（点击图片查看大图）\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑了蚂蚁庞大的服务集群，具有分布式可支撑海量数据、可云原生部署、推送延迟低、高可用等特点。\nPART. 2\n应用级服务发现的设想\n介绍完什么是服务发现之后，我们来看看什么是“接口级服务发现”，以及与之相对应的“应用级服务发现”。\n从 RPC 框架说起\n根据上述描述，我们先看看业界常用的 RPC 框架，是如何进行服务的发布和订阅的。以 SOFARPC 编程界面为例：\n｜服务发布\npackage com.alipay.rpc.sample; @SofaService(interfaceType = FooService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class FooServiceImpl implements FooService { @Override public String foo(String string) { return string; } } @SofaService(interfaceType = BarService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class BarServiceImpl implements BarService { @Override public String bar(String string) { return string; } } ｜服务使用\n@Service public class SampleClientImpl { @SofaReference(interfaceType = FooService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private FooService fooService; @SofaReference(interfaceType = BarService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private BarService barService; public String foo(String str) { return fooService.foo(str); } public String bar(String str) { return barService.bar(str); } } 上述两个编程界面，完成了两个服务 FooService 和 BarService 的发布、订阅、调用。\n微服务面临的挑战\n上述的服务发布、订阅、调用功能，离不开注册中心的服务发现提供准确的服务地址。将图 1 的服务发现场景进一步展开，此时的工作原理如下图：\n图 2（点击图片查看大图）\n服务发布者\n- 集群内部署了 100 个 pod，IP 分别为：1.1.1.1 ~ 1.1.1.100；\n- 服务发布者的 URL：1.1.1.1:12200?app=applicationB\u0026amp;amp;_SERIALIZETYPE=hessian2\u0026amp;amp;_TIMEOUT=3000\u0026amp;amp;zone=zone1\u0026amp;amp;version=1\u0026amp;amp;_WARMUPTIME=0，12200 端口为 sofarpc-bolt 协议默认的端口。\n服务订阅者：集群内部署了 100 个 pod，IP 分别为：2.1.1.1 ~ 2.1.1.100。\n基于上述的集群部署情况，我们来看看微服务的场景面临的挑战。\n｜挑战 1：注册中心 publisher 存储的挑战\n在上面的集群部署中，可以看到注册中心的数据存储模型，集群内部署了 100 个 provider pod，每个 provider 发布了 2 个服务，即每个 pod 有 2 个 publisher，以 provider1 为例：\n如果在每个 provider 提供更多服务的情况下呢？比如每个 provider 提供了 50 个服务，这样的量级在微服务场景中并不少见，那么此时注册中心对于 provider1，就需要存储 50 个 publisher，分别是：\n可以看到，随着 provider 的扩容，注册中心存储的 publisher 数据量是以 50 倍于 provider 的速度在增长。\n如果您对 SOFARegistry 有过了解，就会知道 SOFARegistry 是支持数据存储分片，可以存储海量数据的。\n但是数据量上涨带来的是 SOFARegistry 本身的服务器数量增涨，如果我们有办法可以降低 SOFARegistry 的数据存储量，那么就能节约 SOFARegistry 本身的服务器成本，同时 SOFARegistry 整个集群的稳定性也会得到提升。\n｜挑战 2：注册中心 subscriber 存储的挑战\n在上述的集群部署中，集群内部署了 100 个 consumer pod，每个 consumer 订阅了 2 个服务，即每个 pod 有 2 个 subscriber，同理于 publisher 的存储挑战，随着 consumer 订阅的接口持续增加，例如 consumer 订阅了 provider 的 10 个 service，此时注册中心存储 consumer1 的 10 个 subscriber 如下：\n随着 consumer 的扩容，注册中心内的 subscriber 存储同样面临着挑战。\n｜挑战 3：服务变更通知的挑战\n随着 publisher 和 subscriber 数量增长，除了对存储的挑战以外，对于数据变更通知同样面临着极大的挑战，让我们来看看如下的场景：provider 下线了 1 台，从 100 台减少到了 99 台，次数集群内发生了哪些变化呢？\n1、首先是在注册中心存储方面，需要将 provide 50 个 service …","date":1681196400,"description":"缘起｜蚂蚁应用级服务发现的实践之路","dir":"blog/origins｜ant's-practical-path-to-application-level-service-discovery/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1681196400,"objectID":"961f22ae0d2c39d1338da028adc43cbb","permalink":"https://sofastack.github.io/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","publishdate":"2023-04-11T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家、SOFARegistry Maintainer 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。 本文 8339 字 阅","tags":["SOFAStack"],"title":"缘起｜蚂蚁应用级服务发现的实践之路","type":"blog","url":"/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","wordcount":3973},{"author":"肖健","categories":["SOFARegistry"],"content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家、SOFARegistry Maintainer\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。\n本文 8339 字阅读 15分钟\nPART. 1\n前言 什么是服务发现？ 我们今天主要聊的话题是“应用级服务发现”的实践，聊这个话题之前，我们先简单介绍一下什么是“服务发现”，然后再聊聊，为什么需要“应用级服务发现”。\n在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信，而这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\n图 1\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑了蚂蚁庞大的服务集群，具有分布式可支撑海量数据、可云原生部署、推送延迟低、高可用等特点。\nPART. 2\n应用级服务发现的设想 介绍完什么是服务发现之后，我们来看看什么是“接口级服务发现”，以及与之相对应的“应用级服务发现”。\n从 RPC 框架说起 根据上述描述，我们先看看业界常用的 RPC 框架，是如何进行服务的发布和订阅的。以 SOFARPC 编程界面[1]为例：\n服务发布 package com.alipay.rpc.sample; @SofaService(interfaceType = FooService.class, bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class FooServiceImpl implements FooService { @Override public String foo(String string) { return string; } } @SofaService(interfaceType = BarService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class BarServiceImpl implements BarService { @Override public String bar(String string) { return string; } } 服务使用 @Service public class SampleClientImpl { @SofaReference(interfaceType = FooService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private FooService fooService; @SofaReference(interfaceType = BarService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private BarService barService; public String foo(String str) { return fooService.foo(str); } public String bar(String str) { return barService.bar(str); } } 上述两个编程界面，完成了两个服务 FooService 和 BarService 的发布、订阅、调用。\n微服务面临的挑战 上述的服务发布、订阅、调用功能，离不开注册中心的服务发现提供准确的服务地址。将图 1 的服务发现场景进一步展开，此时的工作原理如下图：\n图 2（点击图片查看大图）\n服务发布者：\n- 集群内部署了 100 个 pod，IP 分别为：1.1.1.1 ~ 1.1.1.100；\n- 服务发布者的 URL：1.1.1.1:12200?app=applicationB\u0026amp;amp;_SERIALIZETYPE=hessian2\u0026amp;amp;_TIMEOUT=3000\u0026amp;amp;zone=zone1\u0026amp;amp;version=1\u0026amp;amp;_WARMUPTIME=0，12200 端口为 sofarpc-bolt 协议默认的端口。\n服务订阅者：集群内部署了 100 个 pod，IP 分别为：2.1.1.1 ~ 2.1.1.100。\n基于上述的集群部署情况，我们来看看微服务的场景面临的挑战。\n挑战 1：注册中心 publisher 存储的挑战 在上面的集群部署中，可以看到注册中心的数据存储模型，集群内部署了 100 个 provider pod，每个 provider 发布了 2 个服务，即每个 pod 有 2 个 publisher，以 provider1 为例：\n如果在每个 provider 提供更多服务的情况下呢？比如每个 provider 提供了 50 个服务，这样的量级在微服务场景中并不少见，那么此时注册中心对于 provider1，就需要存储 50 个 publisher，分别是：\n可以看到，随着 provider 的扩容，注册中心存储的 publisher 数据量是以 50 倍于 provider 的速度在增长。\n如果您对 SOFARegistry 有过了解，就会知道 SOFARegistry 是支持数据存储分片，可以存储海量数据的。\n但是数据量上涨带来的是 SOFARegistry 本身的服务器数量增涨，如果我们有办法可以降低 SOFARegistry 的数据存储量，那么就能节约 SOFARegistry 本身的服务器成本，同时 SOFARegistry 整个集群的稳定性也会得到提升。\n挑战 2：注册中心 subscriber 存储的挑战 在上述的集群部署中，集群内部署了 100 个 consumer pod，每个 consumer 订阅了 2 个服务，即每个 pod 有 2 个 subscriber，同理于 publisher 的存储挑战，随着 consumer 订阅的接口持续增加，例如 consumer 订阅了 provider 的 10 个 service，此时注册中心存储 consumer1 的 10 个 subscriber 如下：\n随着 consumer 的扩容，注册中心内的 subscriber 存储同样面临着挑战。\n挑战 3：服务变更通知的挑战 随着 publisher 和 subscriber 数量增长，除了对存储的挑战以外，对于数据变更通知同样面临着极大的挑战，让我们来看看如下的场景：provider 下线了 1 台，从 100 台减少到了 99 台，次数集群内发生了哪些变化呢？\n1、首先是在注册中心存储方面，需要将 provide 50 个 service 中的 publishers 列表都减 …","date":1681196400,"description":"缘起｜蚂蚁应用级服务发现的实践之路","dir":"projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c9a51341a37418edfd01dc26b64f56e4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","publishdate":"2023-04-11T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家、SOFARegistry Maintainer 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。 本文 8339 字阅","tags":["SOFAStack","SOFARegistry"],"title":"缘起｜蚂蚁应用级服务发现的实践之路","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","wordcount":4116},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 会议预告\nLayotto：\n主题：Layotto 2023-04-12 社区会议\n时间：4 月 12 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2344343024\n议题：\n- 2023开源之夏-课题/导师招募 #894；\n- Discussion: 自建各种 Component #902；\n- 希望 layotto 提供高性能的通信交互能力 #867。\n「Layotto」：\nhttps://github.com/mosn/layotto/issues/907\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@LSQGUANLIVV #1322\n 从 sofa2.3.5 升级到 3.6.3 的时候，启动应用报错，如下图所示。\n 按照报错的点去找发现是 applicationContext 为 null，这里是需要新增加什么配置吗？还是原来的什么地方需要改呢？\n A：有可能是 sofa-boot / sofa-rpc-starter / sofa-rpc 这三个包的兼容性问题。升级了 sofa-rpc，需要同时升级这三个包。可以通过 pom 依赖看下是否有版本冲突。\n 是用的 sofaboot-enterprise-dependencies 的父依赖的默认的，这个也会冲突吗？\n A：使用默认的一般不会有问题，担心有些配置把默认配置覆盖了。另外商业版需要咨询商业版客服，开源社区这边能提供的帮助有限。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1322\n2.@hanzhihua #956\n readCommittedUserLog 可能获得不到刚写入的数据。我在做 NodeTest 测试过程中，在测试 readCommittedUserLog 方法中，出现了错误。\n 我发现主要是日志写入后，但 lastAppliedIndex 没有原子级别更新，造成了读取不到错误。\n A：因为onApply中是可以回滚的，所以没法去实时更新 lastAppliedIndex，只有确认这一批次没有回滚或者回滚的正确 log index，才能去更新。如果你需要在onApply过程中去 commit，可以调用日志迭代器的Iterator#commit方法，将当前 apply 的 log index 确认提交。然后就可以调用readCommittedUserLog确保可以读取到，代价就是无法回滚到 commit 之前的位置了。\n 问一下，onApply 回滚是什么意思，是指状态机 apply 发生异常，还是获取日志为 null，另外怎么回滚呢？\n A：这个方法：\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/956\n本周推荐阅读\n《MoE 系列（一）｜如何使用 Golang 扩展 Envoy》\n《SOFAJRaft 在同程旅游中的实践》\n《Tongsuo/铜锁｜「开放原子开源基金会」拜访篇》\n《如何看待 Dapr、Layotto 这种多运行时架构？》\n","date":1680850800,"description":"SOFA Weekly｜SOFA 开源五周年活动报名、Layotto 会议预告、社区本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230407/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5deb7a12ba899d85e14ea36b8d21dec4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230407/","publishdate":"2023-04-07T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230407/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 开源五周年活动报名、Layotto 会议预告、社区本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230407/","wordcount":1357},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区会议 SOFAArk 背景：SOFAArk 在社区开源将近 5 年，从最初的一个类隔离框架，逐步演进为支持合并部署与热部署的 “Serverless” 运行时框架。尤其在去年我们完成了 SOFAArk 1.0 到 2.0 架构的演进，在蚂蚁也基于 SOFAArk 2.0 完成了 Serverless 研发模式初步的规模化落地。\n主题：SOFAArk 社区化运作方式 KO（暨第一次月会） 时间：4 月 3 日（下周一）20:00 入会口令（钉钉）：683 550 26227 电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆） 入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题： - SOFAArk 社区化运作计划同步与讨论； - 版本维护策略公告； - 项目 CY23 开源规划（含新人培养计划）； - 本次月会 issue 讨论。\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。\n「SOFAArk」：\nhttps://github.com/sofastack/sofa-ark/issues/635\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@Misakami #1321\n 请问 sofa-rpc 有支持 jdk 17 的计划么？现在虽然能正常使用，但是需要在启动参数加上 \u0026amp;ndash;add-opens java.base/java.lang=ALL-UNNAMED。\n A：有的，近期也正在做兼容 jdk 17 的开发。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1321\n2.@googlefan #939\n jraft-spring-boot-starter || NodeManager 设计目的的作用? 看到 jraft-core 有提供 NodeManage.nodeMap 这个针对 Node 节点进行管理的实例，我以为可以通过 NodeManage.nodeMap 来获取所有集群节点的 RPC 服务，如果是这样的话，这个类的设计的目的是?\n A：NodeManager 是 jraft 内部为了实现单个进程内多个 raft group 共享同一个网络端口设计的，不是给集成着或者用户使用的。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/939\n本周推荐阅读 应用运行时 Layotto 进入 CNCF 云原生全景图\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1680246000,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230331/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a01ecd144b06b6b3399f4474a92ab677","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230331/","publishdate":"2023-03-31T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230331/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230331/","wordcount":1071},{"author":null,"categories":"SOFAStack","content":"本文作为 MoE 系列第一篇，主要介绍用 Golang 扩展 Envoy 的极速开发体验。\n一、背景\nMoE*（MOSN on Envoy）*是 MOSN 团队提出的技术架构，经过近两年的发展，在蚂蚁内部已经得到了很好的验证；并且去年我们也将底层的 Envoy Go 七层扩展贡献了 Envoy 官方，MOSN 也初步支持了使用 Envoy 作为网络底座的能力。\n借此准备写一系列的文章，逐一介绍这里面的技术。本文作为开篇，将重点介绍 MoE 中的基础技术，Envoy Go 扩展。\n二、FAQ\n开始前，先给大家解答下几个基本的问题：\n 1、MoE 与 Envoy Go 扩展有什么区别？\n A：MoE 是技术架构，Envoy Go 扩展是连接 MOSN 和 Envoy 的基础技术。\n 2、Envoy Go 扩展，与用 Go 来编译 Wasm 有什么区别？\n A：Envoy Go 支持 Go 语言的所有特性，包括 Goroutine；Go Wasm 则只能使用少量的 Go 语言特性，尤其是没有 Goroutine 的支持。\n 3、Go 是静态链接到 Envoy 么？\n A：不是的，Go 扩展编译成为 so，Envoy 动态加载 so，不需要重新编译 Envoy\n 4、Envoy Go 支持流式处理么？\n A：支持的。\n由于 Go 扩展提供的是底层的 API，非常的灵活，使用上相对会稍微复杂一些；如果只想简单的使用，可以使用 MOSN 的 filter，后面我们也会介绍。\n三、需求\n我们先实现一个小需求，来实际体会一下：\n对请求需要进行验签，大致是从 URI 上的某些参数，以及私钥计算一个 token，然后和 header 中的 token 进行对比，对不上就返回 403。\n很简单的需求，仅仅作为示例，主要是体验一下过程。\n四、代码实现\n完整的代码可以看 envoy-go-filter-example[1] 这个仓库，这里摘录最核心的两个函数：\nconst secretKey = \u0026amp;quot;secret\u0026amp;quot; func verify(header api.RequestHeaderMap) (bool, string) { token, ok := header.Get(\u0026amp;quot;token\u0026amp;quot;) if ok { return false, \u0026amp;quot;missing token\u0026amp;quot; } path, _ := header.Get(\u0026amp;quot;:path\u0026amp;quot;) hash := md5.Sum([]byte(path + secretKey)) if hex.EncodeToString(hash[:]) != token { return false, \u0026amp;quot;invalid token\u0026amp;quot; } return true, \u0026amp;quot;\u0026amp;quot; } func (f *filter) DecodeHeaders(header api.RequestHeaderMap, endStream bool) api.StatusType { if ok, msg := verify(header); !ok { f.callbacks.SendLocalReply(403, msg, map[string]string{}, 0, \u0026amp;quot;bad-request\u0026amp;quot;) return api.LocalReply } return api.Continue } DecodeHeaders 是扩展 filter 必须实现的方法，我们就是在这个阶段对请求 header 进行校验。\nverify 是校验函数，这里的 RequestHeaderMap 是 Go 扩展提供的 interface，我们可以通过它来读写 header，其他都是常见的 Go 代码写法。\n五、编译\n编译很简单，与常见的 Go 编译一样，这里我们使用 Golang 官方的 docker 镜像来编译：\ndocker run --rm -v `pwd`:/go/src/go-filter -w /go/src/go-filter \\ -e GOPROXY=https://goproxy.cn \\ golang:1.19 \\ go build -v -o libgolang.so -buildmode=c-shared . Go 编译还是很快的，只需要几秒钟，当前目录下，就会产生一个 libgolang.so 的文件。反观 Envoy 的编译速度，一次全量编译动辄几十分钟，或者上小时的，这幸福感提升了不止一个档次。🥰\n六、运行\n我们可以使用 Envoy 官方提供的镜像来运行，如下示例：\ndocker run --rm -v `pwd`/envoy.yaml:/etc/envoy/envoy.yaml \\ -v `pwd`/libgolang.so:/etc/envoy/libgolang.so \\ -p 10000:10000 \\ envoyproxy/envoy:contrib-dev \\ envoy -c /etc/envoy/envoy.yaml 只需要把上一步编译的 libgolang.so 和 envoy.yaml 挂载进去就可以了。\n值得一提的是，我们需要在 envoy.yaml 配置中启用 Go 扩展，具体是这段配置：\nhttp_filters: - name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config library_id: example library_path: /etc/envoy/libgolang.so plugin_name: example-1 跑起来之后，我们测试一下：\n$ curl \u0026#39;http://localhost:10000/\u0026#39; missing token $ curl -s \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;token: c64319d06364528120a9f96af62ea83d\u0026#39; -I HTTP/1.1 200 OK 符合期望，是不是很简单呢？\n七、后续\n什么？这个示例太简单？\n是的，这里主要是体验下开发流程，下篇我们将再介绍更高级的玩法：\nGo 接受来自 Envoy 侧的配置、异步 Goroutine，以及与 Istio 配合的用法。\n｜相关链接｜\n[1]envoy-go-filter-example 仓库：\nhttps://github.com/doujiang24/envoy-go-filter-example/tree/master/example-1\n了解更多…\nMOSN Star 一下✨： https://github.com/mosn/mosn\n","date":1679986800,"description":"MoE 系列（一）｜如何使用 Golang 扩展 Envoy","dir":"blog/moe-series (1)|how-to-extend-envoy-with-golang/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e45d3681cf3bc1ea80ee4b37621b372a","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","publishdate":"2023-03-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","summary":"本文作为 MoE 系列第一篇，主要介绍用 Golang 扩展 Envoy 的极速开发体验。 一、背景 MoE*（MOSN on Envoy）*是 MOSN 团队提出的技术架构，经过近两年的发展，","tags":["SOFAStack"],"title":"MoE 系列（一）｜如何使用 Golang 扩展 Envoy","type":"blog","url":"/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","wordcount":1163},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区会议 Layotto 主题：Layotto 社区会议 时间：3 月 29 号（下周三）下午 14 点 钉钉会议令：688 824 34655 电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆） 钉钉入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2316789049\n议题： - 2023 开源之夏-课题/导师招募 #894 - Discussion: 自建各种 Component #902 - 希望 Layotto 提供高性能的通信交互能力 #867\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。 想要参加社区建设的同学可以关注社区的新手任务列表，总有一个适合你。\n「Layotto」：\nhttps://github.com/mosn/layotto/issues/907\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@kunple-w #916\n SpringBoot 2.2 废弃了 logging.path，2.3 已删除该属性，应使用 logging.file.pat。 Steps to reproduce the behavior： - 使用 SOFA 3.10.0，按照 SOFA guides 配置 logging.path，启动后并没有出现文档中的一些日志文件。 - 降级为 sample 中的 3.2.0 版本，日志文件出现。 截图如下（2个属性同时配置）: A：SOFA 中间件中使用 sofa-common-tools 打印的日志，日志空间和 SOFABoot 应用程序是隔离的。因此可以同时使用 logging.path 以及 logging.file.path 属性分别定义 SOFA 中间件和 SOFABoot 应用程序的日志路径。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n2.@shuangchengsun #263\n 客户端的上下线，Client1 处于下线过程，此时 Client1 在路由表中的状态是如何维护的？ A：data 上有一个定时器去维护每个 Session 相关数据的，如果 Session 挂了，data 大约 30s 后把挂掉的 Session 的数据清理掉，同时链接挂掉的 Session 上的的 Client（除掉了下的 Client） 会自动重新连接到其他 Session 上，然后会把数据增加一个版本重新注册到 Session 上，Session 会再发到那台数据上。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/issues/263\n本周推荐阅读 应用运行时 Layotto 进入 CNCF 云原生全景图\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1679641200,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230324/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"84510ab87fdbaaab0b53efb84b3e8d41","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230324/","publishdate":"2023-03-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230324/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230324/","wordcount":1242},{"author":null,"categories":"SOFAStack","content":"文｜黄逸炀\nDragonfly Maintainer\n字节跳动火山引擎软件工程师\n专注于镜像存储及镜像 P2P 分发\nPART. 0\n背景\n火山引擎镜像仓库 CR 使用 TOS 来存储容器镜像。目前在一定程度上能满足并发大规模的镜像拉取。然而最终拉取的并发量受限于 TOS 的带宽和 QPS。\n这里简单介绍一下目前针对于大规模拉镜像遇到的两个场景的问题：\n1、客户端数量越来越多，镜像越来越大，TOS 带宽最终无法满足需求。 2、如果客户端使用了 Nydus 对镜像格式做转换之后，对 TOS 的请求量会有数量级的增加，TOS API 的 QPS 限制导致无法满足需求。\n不论是镜像仓库服务本身还是背后的存储，最终肯定是有带宽和 QPS 限制的。如果单纯依赖服务端提供的带宽和 QPS，很容易就无法满足需求。因此需要引入 P2P ，减轻服务端压力，进而满足大规模并发拉取镜像的需求。\nPART. 1\n基于 P2P 技术镜像分发系统调研\n目前开源社区有几个 P2P 项目，这里对这些项目进行简单介绍。\nDragonfly\n架构图\n术语\nManager\n1、存储动态配置供 Seed Peer 集群、Scheduler 集群以及 Dfdaemon 消费。\n2、维护 Seed Peer 集群和 Scheduler 集群之间关联关系。\n3、提供统一异步任务管理，用作预热等功能。\n4、监听各模块是否健康运行。\n5、为 Dfdaemon 筛选最优 Scheduler 集群调度使用。\n6、提供可视化控制台，方便用户操作管理 P2P 集群。\nScheduler\n1、基于机器学习的多场景自适应智能 P2P 节点调度, 为当前下载节点选择最优父节点。\n2、构建 P2P 下载网络的有向无环图。\n3、根据不同特征值评估节点下载能力, 剔除异常节点。\n4、当下载失败情况，主动通知 Dfdaemon 进行回源下载。\nDfdaemon\n1、基于 gRPC 提供下载功能, 并提供多源适配能力。\n2、开启 Seed Peer 模式可以作为 P2P 集群中回源下载节点, 也就是整个集群中下载的根节点。\n3、为镜像仓库或者其他 HTTP 下载任务提供代理服务。\n4、下载任务基于 HTTP 或 HTTPS 或其他自定义协议。\nKraken\n架构图\n术语\nAgent\n1、是 P2P 网络中的对等节点，需要在每个节点上部署。\n2、实现了 Docker Registry interface。\n3、通知 tracker 自己拥有的数据。\n4、下载其他 agent 的数据（tracker 会告诉该 agent 需要下载这块数据需要到哪个 agent 上下载）\nOrigin\n1、负责从存储中读取数据做种。\n2、支持不同的存储。\n3、通过 Hash 环的形式保证高可用。\nTracker\n1、P2P 网络中的协调者，追踪谁是 Peer，谁是 Seeder。\n2、追踪 Peer 拥有的数据。\n3、提供有序的 Peer 节点供 Peer 下载数据。\n4、通过 Hash 环的形式保证高可用。\nProxy\n1、实现了 Docker Registry Interface。\n2、将镜像层传给 Origin 组件。\n3、将 Tag 传给 BUILD INDEX 组件。\nBuild-Index\n1、Tag 和 digest 映射，agent 下载对应 Tag 数据时向 Build-Index 获取对应的 Digest 值。\n2、集群之间镜像复制。\n3、保存 Tag 数据在存储中。\n4、通过 Hash 环的形式保证高可用。\nDragonfly vs Kraken\nPART. 2\n方案\n在火山引擎上，主要考虑 VKE 和 VCI 通过 CR 拉取镜像。\n1、VKE 的产品特点是基于 ECS 部署的 K8S，因此十分适合每个节点部署 Dfdaemon，充分利用每个节点的带宽，进而充分利用 P2P 的能力。\n2、VCI 的产品特点是底层有一些资源很充足虚拟节点。上层的服务是以 POD 为载体，因此无法像 VKE 那样每个节点部署 Dfdaemon，所以部署的形式部署几个 Dfdaemon 作为缓存，利用缓存的能力。\n3、VKE 或 VCI 客户端拉取经过 Nydus 格式转化过的镜像。在该场景下，需要使用 Dfdaemon 作为缓存，不宜使用过多的节点，避免对 Scheduler 造成过大的调度压力。\n基于火山引擎对于以上产品的需求，以及结合 Dragonfly 的特点，需要设计一套兼容诸多因素的部署方案。部署 Dagonfly 的方案设计如下。\nPART. 3\n整体架构图\n1、火山引擎上的资源都是归属于主账号下。P2P 控制组件以主账号级别隔离，每个主账号下一套 P2P 控制组件。服务端实现 P2P Manager Controller，通过该 Controller 来管控控制面所有 P2P 控制组件。\n2、P2P 控制组件部署在镜像仓库数据面 VPC，通过 LB 与用户集群打通。\n3、在 VKE 集群上，Dfdaemon 以 DaemonSet 方式部署，每个节点上部署一个 Dfdaemon。\n4、在 VCI 上，Dfdaemon 以 Deployment 方式部署。\n5、ECS 上 Containerd 通过 127.0.0.1:65001 访问本节点上的 Dfdaemon。\n6、通过在用户集群部署一个 controller 组件，基于 PrivateZone 功能，在用户集群生成.p2p.volces.com 域名， controller 会根据一定的规则挑选特定节点*（包括 VKE、VCI）*的 Dfdaemon pod，以 A 记录的形式解析到上述域名。\n ECS 上 Nydusd 通过.p2p.volces.com 域名访问 Dfdaemon。 VCI 上镜像服务客户端和 Nydusd 通过.p2p.volces.com 域名访问 Dfdaemon。 PART. 4\n压测数据\n环境\n镜像仓库：带宽 10Gbit/s。\nECS: 4C8G，挂载本地盘，带宽 6Gbit/s。\n镜像\nNginx (500M)\nTensorFlow (3G)\n组件版本\nDragonfly v2.0.8。\nQuota\nDfdaemon: Limit 2C6G。\nScheduler: 2 Replicas，Request 1C2G，Limit 4C8G。\nManager: 2 Replicas，Request 1C2G，Limit 4C8G。\nPOD 启动时间对比\nNginx Pod 分别并发 50、100、200、500 的所有 Pod 从创建到启动消耗时间。\nTensorFlow Pod 分别并发 50、100、200、500 的所有 Pod 从创建到启动消耗时间。\n在大规模拉镜像的场景下，在使用 Dragonfly 和 Dragonfly \u0026amp;amp; Nydus 场景对比 OCIv1 场景能够节省 90% 以上的容器启动时间。使用 Nydus 之后启动时间更短是因为镜像 lazyload 的特性，只需要拉取很小的一部分元数据 Pod 就能启动。\n存储源端带宽峰值对比\nNginx Pod …","date":1679382000,"description":"火山引擎基于 Dragonfly 加速实践","dir":"blog/volcano-engine-based-on-dragonfly-acceleration-practices/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"21e4e09162503066e2909a462942331d","permalink":"https://sofastack.github.io/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","publishdate":"2023-03-21T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","summary":"文｜黄逸炀 Dragonfly Maintainer 字节跳动火山引擎软件工程师 专注于镜像存储及镜像 P2P 分发 PART. 0 背景 火山引擎镜像仓库 CR 使用 TOS 来存储容器镜像。目前在一定程度上能满足并发","tags":["SOFAStack"],"title":"火山引擎基于 Dragonfly 加速实践","type":"blog","url":"/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","wordcount":3113},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议\nMOSN\n主题：MOSN 2023 社区会议 时间：3 月 23 号（下周四）晚上 19 点 钉钉会议号：689 448 86753 电话呼入：+862759771614（中国大陆） 钉钉入会链接：https://meeting.dingtalk.com/j/vvE0uCA0vQT\n议题： 回顾 MOSN 去年进展及今年的规划。 邀请部分 MOSN 用户来分享落地经验、发展规划。 共商 MOSN 2023 发展大计。\n另外，还邀请了 Higress 社区来互动交流，探讨合作空间。 Service Mesh、Gateway、Envoy、Istio、ztunnel 等等大家关注的话题，也可以在这里交流。欢迎大家参会讨论~\n「 MOSN 」：https://github.com/mosn/mosn\nLayotto\n主题：Layotto 社区会议 时间：3 月 22 号（下周三）下午 14 点 钉钉会议令：688 824 34655 电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆） 钉钉入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2299840541\n议题： Discussion: 自建各种 Component #902 希望 Layotto 提供高性能的通信交互能力 #867\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。 想要参加社区建设的同学可以关注社区的新手任务列表，总有一个适合你。\n「Layotto」： https://github.com/mosn/layotto/issues/902 https://github.com/mosn/layotto/issues/867\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@LY1806620741 #1061\ncom.alipay.sofa.rpc.enable-swagger 在 3.16.3 是否已经废弃\n配置使用了 Objectway 的 asm，与 Springboot 的 asm 冲突。 另外，没有在 SOFABoot 文档上找到所有的属性说明。\n重现该行为的步骤：\n运动单 SOFABoot\n配置 com.alipay.sofa.rpc.enable-swagger=true\n启动并访问*http://localhost:8341/swagger/bolt/api *\ndebug 可以看到找不到 class objectway.classvisitor\n引入 asm.jar 后会与 sping 框架的 asm org.springframework.asm.ClassVisitor 冲突\nA：看起来是 https:/github.com/sofastack/sofa-rpc/blob/5.8.3.1/all/pom.xml 少添加了一个 asm 的依赖，导致出现上面的问题。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n2.@springcoco #589\n关于多部网站代码解析的一些疑问，在多网站这一章节，发现这样说： 我的疑惑是 Spring 是如何判定 ArkTomcatEmbeddedWebappClassLoader 类存在呢？ 在加载 ArkTomcatServletWebServerFactory 的时候，我发现也会加载 Tomcat 默认的 Server Factory，如何最终判定周 WebServer 使用 ArkWebServerFacticServletTomcat 使用 Ark。 A：ArkTomcatEmbeddedWebappClassLoader 作为一个判断条件，如果没有使用 web-ark-plugin，意味着没有 ArkTomcatEmbeddedWebappCl\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/589\nMOSN 1.0 发布，开启新架构演进\n社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析\nMOSN 反向通道详解\n蚂蚁集团境外站点 Seata 实践与探索\n","date":1679036400,"description":"SOFA Weekly | MOSN、Layotto 社区会议通知、Seata 版本发布","dir":"blog/sofa-weekly-230317/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1827a7e4749437ae2082098f18a52e18","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230317/","publishdate":"2023-03-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230317/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、Layotto 社区会议通知、Seata 版本发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230317/","wordcount":1402},{"author":null,"categories":"SOFAStack","content":" 发布概览 Seata-go 1.1.0 版本补齐了 AT 模式下对 Multi Delete、Multi Update、Insert on Update 和 Select for Update 的支持。至此 Seata-go 的 AT 模式与 Seata AT 模式全面对齐。\n此版本给出了在 Dubbo-go/Gin/gRPC 中使用 Seata-go TCC/AT 两种模式的示例。\n示例链接：https://github.com/seata/seata-go-samples/tree/main/at\nAT 模式:\n AT 模式支持并集成了 Multi Delete SQL 语法 AT 模式支持并集成了 Multi Update SQL 语法 AT 模式支持并集成了 Insert on Update SQL 语法 AT 模式支持并集成了 Select for Update SQL 语法 配置文件：\n完善了更多地方读取配置文件功能\n版本的主要更新如下 Feature： [#491] 支持查询全局事务锁 https://github.com/seata/seata-go/pull/491\n[#482] 支持 AT 模式 Multi Delete SQL 执行器 https://github.com/seata/seata-go/pull/482\n[#481] 支持 AT 模式 Multi Update SQL 执行器 https://github.com/seata/seata-go/pull/481\n[#478] 支持 AT 模式 Select for Update SQL 执行器 https://github.com/seata/seata-go/pull/478\n[#477] 支持 Undo Log 的 Json 序列化方式 https://github.com/seata/seata-go/pull/477\n[#456] 支持 AT 模式 Insert on Update SQL 执行器 https://github.com/seata/seata-go/pull/456\n[#444] 支持 BZip 压缩算法 https://github.com/seata/seata-go/pull/444\n[#436] 支持读取 RM 相关的配置文件 https://github.com/seata/seata-go/pull/436\n[#433] 支持 XA 连接管理器 https://github.com/seata/seata-go/pull/433\n[#430] 支持读取 Getty 相关的配置文件 https://github.com/seata/seata-go/pull/430\nBugfix：\n[#509] 修复 AT 模式下执行 Insert on Update 时 Undo Log 的 SQLType 字段的问题 https://github.com/seata/seata-go/pull/509\n[#495] 修复 Undo Log 的 SQLType 字段的问题 https://github.com/seata/seata-go/pull/495\n[#487] 修复 AT 执行时出现的问题 https://github.com/seata/seata-go/pull/487\n[#472] 修复全局事务中上下文丢失值问题 https://github.com/seata/seata-go/pull/472\n[#461] 修复 Error_Code_test 中变量未定义导致的 CI 失败问题 https://github.com/seata/seata-go/pull/461\n[#459] 修复 Error 日志重复打印问题 https://github.com/seata/seata-go/pull/459\n[#452] 修复 AT 模式执行 Insert SQL 时 ID 增的报错问题 https://github.com/seata/seata-go/pull/452\nOptimize：\nSeata-go 的示例项目已经全部迁移到新的仓库：https://github.com/seata/seata-go-samples\n[#507] 优化 AT 模式 Multiple Update SQL 执行器 https://github.com/seata/seata-go/pull/507\n[#505] 优化 AT 模式 Multi SQL 执行器 https://github.com/seata/seata-go/pull/505\n[#453] 优化 Message Type 和 Transaction error Code 枚举值 https://github.com/seata/seata-go/pull/453\n[#447] 优化数据源初始化流程 https://github.com/seata/seata-go/pull/447\n[#466] 优化变量的命名 https://github.com/seata/seata-go/pull/466\nTest:\n[#445] 添加 Transaction error Code 的单元测试 https://github.com/seata/seata-go/pull/445\nDoc:\n[#492] 更新 Readme 文件的已完成功能列表 https://github.com/seata/seata-go/pull/492\n[#489] 添加 1.1.0 版本的 Change Log https://github.com/seata/seata-go/pull/489\n英文版：https://github.com/seata/seata-go/releases/tag/v1.1.0\n致谢\n非常感谢以下 Contributors 的代码贡献。若有无意遗漏，请报告。\n@luky116 https://github.com/luky116\n@georgehao https://github.com/georgehao\n@lxfeng1997 https://github.com/lxfeng1997 @106umao https://github.com/106umao @wang1309 https://github.com/wang1309 @iSuperCoder https://github.com/iSuperCoder @Charlie17Li https://github.com/Charlie17Li @Code-Fight https://github.com/Code-Fight @Kirhaku https://github.com/Kirhaku @Vaderkai https://github.com/VaderKai @springrain https://github.com/springrain @Shaozhou Hu https://github.com/raspberry-hu …","date":1678777200,"description":"Seata-go 1.1.0 发布，补齐 AT 模式支持","dir":"blog/seata-go-1-1-0-released-completes-at-mode-support/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e92a21aaa50425c14c2a8462c1d96e2e","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","publishdate":"2023-03-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","summary":"发布概览 Seata-go 1.1.0 版本补齐了 AT 模式下对 Multi Delete、Multi Update、Insert on Update 和 Select for Update 的支持。至此 Seata-go 的 AT 模式与 Seata AT 模式全面对齐。 此","tags":["SOFAStack"],"title":"Seata-go 1.1.0 发布，补齐 AT 模式支持","type":"blog","url":"/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","wordcount":1353},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@linkoog #602\n 首先我使用了 Ark-Guides 和 Ark-biz 的示例进行操作。 可以正常加载模板，但配置文件加载不到。 Start 是启动模块， Config 是配置的存储释放模块。 试了下面两种方式，都读到不到配置文件 1、直接打包 Config 的 Jar 中 2、在 Start 模板下面放 Conf/Ark/ 环境 沙发方舟版本：2.0.8 JVM 版本（例如 Java -Version ）：1.8.333 操作系统版本（例如 Uname -a ）：macOS 行家版本： 集成开发环境版本\n A：配置文件的配置应和 Spring Boot 应用保持一致，建议把配置文件放至 Resources 目录下。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/602\n2.@SpringLin97 #928\n Jraft 支持 IPV6 组建集群吗？\n A：1.3.5 以后版本支持 IPV6。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/928\n本周推荐阅读 DLRover：蚂蚁开源大规模智能分布式训练系统\nNydus 在约苗平台的容器镜像加速实践\nWasm 原生时代已经来到\nGo 语言，如何做逆向类型推导?\n","date":1678431600,"description":"SOFA Weekly | SOFANews、开源人 \u0026 issue 精选","dir":"blog/sofa-weekly-20230310/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c8fb3a67d5797275149ca3410ab9631e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230310/","publishdate":"2023-03-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230310/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、开源人 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230310/","wordcount":684},{"author":null,"categories":"SOFAStack","content":" 文｜沙剑 蚂蚁集团高级技术专家 专注分布式深度学习领域 主要负责蚂蚁大规模分布式训练引擎的设计和开发\n 本文 4491 字 阅读 12 分钟\n本文整体介绍了 DLRover 的项目动机与核心能力，未来我们会发布一系列文章，来从同步/异步弹性训练，优化策略服务，多种集群和训练框架对接，策略定制开发等多个角度来介绍 DLRover 的更多细节，敬请期待。\n技术背景 2022 年 6 月，蚂蚁集团决定全面引入 ESG 框架，启动并确立了“数字普惠”、“绿色低碳”、“科技创新”、“开放生态”四位一体的可持续发展战略。针对“绿色低碳”，设立了 4 个子议题，包括绿色运营、科技助力产业碳中和、生态保护与修复绿色低碳生活。\n在此背景下，绿色 AI 也成为蚂蚁 AI Infra 团队的一个重要工作方向。作为绿色 AI 的重要板块，工程提效项目致力于打造高性能离在线 AI 工程体系，通过提升算力效率和资源利用率，最终达到节省资源降低碳排放的目的。\n当前，用户提交分布式训练作业的工具有 Yarn 或者 KubeFlow/Training-Operator。在提交作业时，用户需要在作业中指定作业资源，包括不同角色的节点数量和资源规格（CPU 核数、内存、GPU 等）。\n在训练作业提交后，作业可能遇到如下问题： - 集群资源不足以启动作业的所有节点，作业只能等待。 - 训练作业的节点可能会出错，比如被高优任务抢占、机器故障、IO 故障等，导致作业失败。\n出现这些问题后，用户只能修改作业资源来重新提交作业。\n针对这两个问题，蚂蚁集团早期基于 Kubernetes 开源了 ElasticDL 项目来支持 K8s 上 TF 2.x 分布式训练的弹性容错。在项目落地过程中我们又发现了如下问题： - 用户配置的资源可能过少引起 OOM 和训练性能差。 - 用户为了保障作业成功率和速度，通常会配置超额资源导致利用率低。 - 越来越多的用户使用 PyTorch 或其他 TF 之外的框架来开发和训练模型。 - 越来越多的分布式集群开始支持 AI 作业，比如 Ray、Spark 集群，能否适配任意计算集群？ - 在线学习越来越被广泛采用的情况下，如何运用一套系统同时解决兼容离在线训练？\n前两个问题使得集群 CPU 利用率通常只有 20% 上下，同时算法开发人员需要投入很多人工运维成本，为了解决训练端资源提效的需求，支持在不同集群上针对在离线多种训练模式，给不同框架的分布式训练作业自动地寻找最优资源配置。\n蚂蚁 AI Infra 团队基于 ElasticDL 弹性容错的思路，升级扩展并开源了 DLRover，其目标在于提升分布式模型训练的智能性，目前很多公司的训练作业都是跑在混部的集群中，运行环境复杂多变，正如其名，DLRover 作为分布式训练领域的 “路虎”，不管多么崎岖的地形，都可以轻松驾驭。\n整体方案 DLRover 提出了 “ML for System” 的理念来提升分布式训练的智能性，那么这样的系统应该具备哪些能力呢？\n我们认为主要体现在如下几个方面： - 解耦：不和底层训练框架耦合在一起，只依赖接口抽象，遵循依赖倒置原则。（*i.e. Elastic Runtime*） - 资源调度：具备上帝视角的资源调度管控能力。和建立在对作业精准画像的决策能力。 - 数据驱动：同时收集掌握集群资源数据，也掌握训练作业数据。以数据驱动智能。 - 作业交互：以对训练作业以及模型白盒化的理解，动态根据实际情况，对训练作业进行优化调整。超越简单机械的弹性容错！ - 智能：通过对集群以及作业信息的收集，结合算法模型+固定策略产出精准的作业优化策略。\n我们希望设计并实现一个系统，让用户完全摆脱资源配置的束缚，专注于模型训练本身。在没有任何资源配置输入的情况下，DLRover 仍然可以为每个训练作业提供最佳资源配置。考虑到用户可能会以不同的方式运行他们的训练作业，DLRover 除了面向训练平台进行作业统一管理的 Cluster Mode，也提供 Single-Job Mode 方便独立的算法开发者也能享受到弹性容错等基本特性。\n系统架构 DLRover 由四个主要组件组成：ElasticJob、Elastic Trainer、Brain 服务和 Cluster Monitor。\n上图显示了 DLRover 如何在 K8s 集群上管理深度学习训练作业。DLRover 以 ElasticJob CRD 的形式将作业提交到集群。收到 CRD 后，ElasticJob Operator 会拉起一个 Master Pod 作为 Elastic Trainer。其从 Brain 服务中获取初始资源计划。Elastic Trainer 用它来创建 Scale CRD，并应用 Scale CRD 通知 ElasticJob Controller 启动所需的 Pod，每个 Pod 将在其上启动一个 Elastic Agent。\n在训练过程中，Elastic Trainer 的 Training Master 将数据分片分发给 Worker。同时，Cluster Monitor 监控每个作业的运行状态（*i.e.每个节点的 Workload*）和集群状态（*i.e. 资源水位*）。这些数据将定期报告给 Brain，Brain 将数据持久化到数据库中。\n然后 DLRover Brain 根据作业的运行状态，选择合适的算法生成新的资源计划，并通知 Elastic Trainer 开始资源调整。\n总的来讲，DLRover 可以帮助分布式训练作业自动化运行在集群中，可以看作分布式作业的自动驾驶，模型开发者只需要关注模型的算法设计，DLRover 目前开源版则可以为用户提供如下能力： - 自动资源推导：帮助用户自动初始化训练资源，提升资源利用率与作业稳定性。 - 动态训练数据分片：针对不同 Worker 性能不通造成的木桶效应，根据实际消费速度分配训练数据，可配合 Failover 记录消费位点，数据不丢失。 - 单点容错：提供单点容错的能力，不需要完整重启作业。 - 资源弹性：支持运行时 Pod 级和 CPU/Memory 级的资源弹性扩缩容，动态全局优化决策。\nDLRover 能带来什么 1.作业零资源参数配置 用户提交分布式作业时无需提供任何资源信息，DLRover 会自动对作业进行画像，推导出最优的资源配置，同时运行时可以根据实际情况（*集群资源、样本流量、当前利用率、\u0026amp;hellip;*）自动对资源进行调整。下面展示了两种提交脚本的配置对比：\n2.单点容错提升作业稳定性与恢复效率 DLRover 支持单点恢复 Parameter Server 和 Worker 角色的失败退出而不需要整体作业重启，对于非用户代码和数据类型的错误可以实现用户无感的重启。例如集群中，很常见的一类错误是由于用户配置了不足的内存，导致训练 OOM。在 DLRover 的帮助下，我们可以自动拉起一个优化配置的节点来恢复失败的 Node。在真实环境下，DLRover 管理的训练作业，相比基线的 Kubeflow TF-Operator 作业，训练成功率从 84% 提升到了 95% 以上。 …","date":1678172400,"description":"DLRover：蚂蚁开源大规模智能分布式训练系统","dir":"blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d19aa2ffa0b2368819bac80add901dfb","permalink":"https://sofastack.github.io/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","publishdate":"2023-03-07T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","summary":"文｜沙剑 蚂蚁集团高级技术专家 专注分布式深度学习领域 主要负责蚂蚁大规模分布式训练引擎的设计和开发 本文 4491 字 阅读 12 分钟 本文整体介绍了 DLRover 的项目动机与","tags":["SOFAStack"],"title":"DLRover：蚂蚁开源大规模智能分布式训练系统","type":"blog","url":"/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","wordcount":3919},{"author":null,"categories":"SOFAStack","content":" SOFA Weekly｜铜锁探「密」、本周贡献 \u0026amp;amp; issue 精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@ZhengweiHou #1313\n 同一台机器启动两个 SOFA 进程，开启端口自适应（AdaptivePort），但是两个进程服务注册端口一致，但实际生效端口不一致。通过验证端口自适应逻辑发现我的机器上（ServerSocket.bind) 预期结果不一致。详细情况如图所示：\n A：AdaptivePort 的逻辑在 可以看下这块代码。\ncom.alipay.sofa.rpc.server.ServerFactory#resolveServerConfig\n和你理解的应该不太一样。\n「SOFARPC」: https://github.com/sofastack/sofa-rpc/issues/1313\n**2.@hanzhihua ** #934\n 咨询一个问题，Closure Threadpool 使用 SynchronousQueue 而不使用其他的有缓存的 Queue，是怎么考虑的呢？\n A：主要是原因是希望在任务量大 Core Thread 饱和的时候尽快新增线程来更快的处理任务，中间加一个 Queue 会影响到，Java Threadpool 的策略你懂的，需要 Queue 满了后 MaximumThreads 参数的值才发挥作用。\n「SOFAJRaft」： https://github.com/sofastack/sofa-jraft/issues/934\n3.@penglinzhang #612\n 静态合并部署时，为什么宿主应用会把子业务应用中的 Bean 也会扫描注册到自己的 ApplicationContext 中，而不是仅仅把子应用作为一个特殊 Jar 包？\n A：由于你的宿主应用 @ComPonentScan 扫描了 “com.alipay.sofa”，并且你的业务 Bean 也是 com/alipay/sofa 路径下的，你可以尝试将业务包 Spring-Boot-Ark-Biz 的路径改成自定义的。\n「SOFAArk」： https://github.com/sofastack/sofa-ark/issues/612\n本周推荐阅读\nSOFARegistry | 聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1677826800,"description":"","dir":"blog/sofa-weekly-20230303/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1b93b164611c557c53757d288b2e2d77","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230303/","publishdate":"2023-03-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230303/","summary":"SOFA Weekly｜铜锁探「密」、本周贡献 \u0026amp; issue 精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Sta","tags":["SOFAStack"],"title":"SOFA Weekly｜铜锁探「密」、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230303/","wordcount":802},{"author":null,"categories":"SOFAStack","content":" 文 | 向申 约苗平台运维工程师 关注云原生领域\n本文字数 9574 阅读时间 24 分钟\n 本文是来自向申同学的分享，介绍了其在 K8s 生产环境集群部署 Nydus 的相关实践。\nNydus 是蚂蚁集团，阿里云和字节等共建的开源容器镜像加速项目，是 CNCF Dragonfly 的子项目，Nydus 在 OCI Image Spec 基础上重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。详情文档请参考如下地址：\n Nydus 官方网站：https://nydus.dev/\n Nydus Github：https://github.com/dragonflyoss/image-service\n PART.1\n容器镜像的概念 1. 容器镜像 容器镜像有一个官方的类比，\u0026amp;rdquo;生活中常见的集装箱\u0026amp;rdquo;，虽然拥有不同的规格，但箱子本身是不可变的（*Immutable*），只是其中装的内容不同。\n对于镜像来说，不变的部分包含了运行一个应用软件（如 MySQL ）所需要的所有元素。开发者可以使用一些工具（*如 Dockerfile*）构建出自己的容器镜像，签名并上传到互联网上，然后需要运行这些软件的人可以通过指定名称（*如 example.com/my-app*）下载、验证和运行这些容器。\n2. OCI 标准镜像规范 在 OCI 标准镜像规范出台之前，其实有两套广泛使用的镜像规范，分别是 Appc 和 Docker v2.2，但“合久必分，分久必合”，有意思的是两者的内容已经在各自的发展中逐步同化了，所以 OCI 组织顺水推舟地在 Docker v2.2 的基础上推出了 OCI Image Format Spec，规定了对于符合规范的镜像，允许开发者只要对容器打包和签名一次，就可以在所有的容器引擎上运行该容器。\n这份规范给出了 OCI Image 的定义：\nThis specification defines an OCI Image, consisting of a manifest, an Image Index (optional), a set of filesystem layers, and a Configuration.\n3. 容器的工作流程 一个典型的容器工作流程是从由 Developers 制作容器镜像开始的（*Build*），然后上传到镜像存储中心（*Ship*），最后部署在集群中（*RUN*）。\nPART.2\nOCI 镜像格式 通常所说的镜像文件其实指的是一个包含了多个文件的“包”，“包”中的这些文件提供了启动一个容器所需要的所有需要信息，其中包括但不限于，容器所使用的文件系统等数据文件，镜像所适用的平台、数据完整性校验信息等配置文件。当我们使用 Docker pull 或者 Nerdctl pull 从镜像中心拉取镜像时，其实就是在依次拉取该镜像所包含的这些文件。\nNerdctl 依次拉取了一个 Index 文件、一个 Manifest 文件、一个 Config 文件和若干个 Layer 数据文件。实际上，一个标准的 OCI 镜像通常就是由这几部分构成的。\n其中，Layer 文件一般是 tar 包或者压缩后的 tar 包，其包含着镜像具体的数据文件。这些 Layer 文件会共同组成一个完整的文件系统（*也就是从该镜像启动容器后，进入容器中看到的文件系统*） 。\nConfig 文件是一个 JSON 文件。其中包含镜像的一些配置信息，比如镜像时间、修改记录、环境变量、镜像的启动命令等等。\nManifest 文件也是一个 JSON 文件。它可以看作是镜像文件的清单，即说明了该镜像包含了哪些 Layer 文件和哪个 Config 文件。\n下面是一个 Manifest 文件的典型例子：\n\u0026amp;quot;schemaVersion\u0026amp;quot;: 2, \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.manifest.v1+json\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.config.v1+json\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:0584b370e957bf9d09e10f424859a02ab0fda255103f75b3f8c7d410a4e96ed5\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 7636 }, \u0026amp;quot;layers\u0026amp;quot;: [ { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:214ca5fb90323fe769c63a12af092f2572bf1c6b300263e09883909fc865d260\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 31379476 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:50836501937ff210a4ee8eedcb17b49b3b7627c5b7104397b2a6198c569d9231\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 25338790 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:d838e0361e8efc1fb3ec2b7aed16ba935ee9b62b6631c304256b0326c048a330\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 600 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:fcc7a415e354b2e1a2fcf80005278d0439a2f87556e683bb98891414339f9bee\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 893 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: …","date":1677567600,"description":"Nydus 在约苗平台的容器镜像加速实践","dir":"blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7e9b91c041e413e6e7587da7c34f0e22","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","publishdate":"2023-02-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","summary":"文 | 向申 约苗平台运维工程师 关注云原生领域 本文字数 9574 阅读时间 24 分钟 本文是来自向申同学的分享，介绍了其在 K8s 生产环境集群部署 Nydus 的相关实践。 Nydus 是蚂蚁","tags":["SOFAStak"],"title":"Nydus 在约苗平台的容器镜像加速实践","type":"blog","url":"/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","wordcount":4215},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 4 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@linkoog #602\n SOFAArk 2.0 合并部署时，ark-biz 无法读取配置文件\n A：配置文件的配置应该和 Spring Boot 应用保持一致，建议把配置文件放置到 resources 目录下。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.@tdxafpdq #925\n 消息中间件业务场景下，如何使用 Snapshot 服务，以解决磁盘占用持续增长以及全量回放变慢。\n A：消息场景下，还是控制消息的总量，通过 TTL 等机制来及时删除过期的消息，如果是同步数据库的场景，可以使用 Snapshot 来做检查点（Checkpoint），Snapshot 本身可能只做一些数据库状态校验的动作，确保 Snapshot log index 之前的日志都已经同步复制完成，然后 JRaft 就可以释放之前的日志。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 SOFARegistry｜聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1676617200,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230217/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f937156cef65231cd51d07b5c8c4f9c7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230217/","publishdate":"2023-02-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230217/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230217/","wordcount":695},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区\n 活动时间：02 月 25 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：待直播后更新\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#32 你的开源入门指南——Kata Containers 社区 如今“参与开源”已然成为很多技术人追赶的浪潮。但有些人苦于找不到参加途径，有些人畏畏缩缩不敢发声，或者是由于开源项目众多，不知道该如何挑选\u0026amp;hellip;\u0026amp;hellip;在本期 SOFAChannel#32 的节目中，我们邀请到了 Kata Containers 社区新星姚胤楠同学，给大家带来开源入门指南！Kata Containers 是一种基于硬件虚拟化技术、兼容 OCI/CRI 等协议的容器运行时技术，可以完美地运行在 Kubernetes 集群之上。Kata Containers 比传统容器提供了更高的安全性和更强的隔离性，同时具备快速启动和部署的优势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 姚胤楠\n Kata Containers Contributor\n 议程 直播回放 待直播后更新\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1676530800,"description":"2023 年 02 月 25 日 19：00 - 20：00 ，线上直播第 32 期。","dir":"activities/sofa-channel-32/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7ece90c394a1f25d260f0d79aa6a80b0","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-32/","publishdate":"2023-02-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-32/","summary":"概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区 活动时间：02 月 25 日，周四晚 19 点 活动形式：线上直播 资料下载：待","tags":["SOFAChannel","Kata Containers","你的开源入门指南"],"title":"SOFAChannel#32 你的开源入门指南——Kata Containers 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-32/","wordcount":569},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区\n 活动时间：02 月 25 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：待直播后更新\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#32 你的开源入门指南——Kata Containers 社区 如今“参与开源”已然成为很多技术人追赶的浪潮。但有些人苦于找不到参加途径，有些人畏畏缩缩不敢发声，或者是由于开源项目众多，不知道该如何挑选\u0026amp;hellip;\u0026amp;hellip;在本期 SOFAChannel#32 的节目中，我们邀请到了 Kata Containers 社区新星姚胤楠同学，给大家带来开源入门指南！Kata Containers 是一种基于硬件虚拟化技术、兼容 OCI/CRI 等协议的容器运行时技术，可以完美地运行在 Kubernetes 集群之上。Kata Containers 比传统容器提供了更高的安全性和更强的隔离性，同时具备快速启动和部署的优势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 姚胤楠\n Kata Containers Contributor\n 议程 直播回放 待直播后更新\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1676444400,"description":"2023 年 02 月 16 日 19：00 - 20：00 ，线上直播第 32 期。","dir":"activities/sofachannel-32/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f529a5fffabf35600dcecdc9b513fe85","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofachannel-32/","publishdate":"2023-02-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofachannel-32/","summary":"概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区 活动时间：02 月 25 日，周四晚 19 点 活动形式：线上直播 资料下载：待","tags":["SOFAChannel","Kata Containers","你的开源入门指南"],"title":"SOFAChannel#32 你的开源入门指南——Kata Containers 社区","type":"activities","url":"/sofastack.tech/activities/sofachannel-32/","wordcount":569},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者蚂蚁集团技术专家\n专注于云原生网关研发的相关工作。\n本文 224 字 阅读 8 分钟\nPART. 1\n引言 在上回的文章《Go 内存泄漏，pprof 够用了么？》中说到，从一个 core 文件生成内存引用关系火焰图时，虽然可以从 core 文件中读到所有的内存对象，但是并不知道它们的类型信息。\n这是因为 Go 作为静态类型语言，在运行时，内存对象的类型是已知的。也就是说，并不需要想动态类型语言那样，为每个内存对象在内存中存储其类型信息 （有点例外的是 interface） 。\n比如这个 Go 语言例子：\ntype Foo struct { a uint64 b int64} func foo(f *Foo) int64 { return f.b} Foo 函数在使用 f 这个指针时，并不需要判断其类型，直接读一个带偏移量地址就能得到 f.b，也就是一条指令：mov rax, qword ptr [rax + 8]，就是这么简单直接。\n再看 Lua 语言这个例子：\nfunction foo(f) return f.bendfoo({ b = 1 }) Foo 函数在执行的时候，首先得判断 f 的类型，如果是 table，则按照 key 取 b 的值；如果不是，则抛运行时 error。\n能够运行时判断 f 的类型，是因为 Lua 中变量是用 TValue 来表示的，这个 TValue 结构中，就有一个信息用来存储变量类型。\nPART. 2\n逆向类型推导 逆向类型推导的逻辑是：根据已知内存的类型信息，推导被引用的内存对象的类型信息。\n比如这个例子：\ntype Foo struct { a uint64 b int64}type Bar struct { f *Foo}var b Bar 如果我们知道了 b 的类型是 Bar，那么 b 中第一个 field 指向的内存对象，就是 Foo 类型了 （前提是合法的内存对象地址） 。\n既然存在推导，那我们怎么知道一些初始值呢？\n一共有两类来源：\n1.全局变量；\n2.协程中每一帧函数的局部变量。\nPART. 3\n全局变量 Go 在编译的时候，默认会生成一些调试信息，按照 DWARF 标准格式，放在 ELF 文件中 .debug_* 这样的段里。\n这些调试信息中，我们关注两类关键信息：\n 类型信息： 包括了源码中定义的类型，比如某个 struct 的名字、大小、以及各个 field 类型信息；\n 全局变量： 包括变量名、地址、类型，调试信息中的、全局变量的地址、以及其类型信息，也就是构成推导的初始值。\n 函数局部变量，要复杂一些，不过基本原理是类似的，这里就不细说了~\nPART. 4\n推导过程 推导过程，跟 GC-Mark 的过程类似，甚至初始值也跟 GC-Root 一样。\n所以，全部推导完毕之后，GC-Mark 认为是 alive 的内存对象，其类型信息都会被推导出来。\ninterface\nGo 语言中 interface 比较类似动态类型，如下是空接口的内存结构，每个对象都存储了其类型信息：\ntype eface struct { _type *_type data unsafe.Pointer} 按照类型推导，我们能知道一个对象是 interface{}，但是其中 Data 指向对象，是什么类型，我们则需要读取 _type 中的信息了。\n_type 中有两个信息，对我们比较有用：\n1.名字\n不过比较坑的是，只存了 pkg.Name 并没有存完整的 Include Path 这个也合理的，毕竟 Go 运行时并不需要那么精确，也就是异常时，输出错误信息中用一下。不过在类型推导的时候，就容易踩坑了。\n2.指针信息\n具体存储形式有点绕，不过也就是表示这个对象中，有哪些偏移量是指针。\n有了这两个信息之后，就可以从全量的类型中，筛选出符合上面两个信息的类型。\n通常情况下，会选出一个正确的答案，不过有时候选出多个，仅仅根据这两个信息还不能区分出来，一旦一步错了，后面可能就全推导不出来了。\n我们给 Go 官方 Debug 贡献了一个补丁，可以进一步的筛选，有兴趣的可以看 CL 419176[1]。\nunsafe.pointer\n其实，在上面的 interface 示例中，最根源的原因，也就是 data unsafe.pointer，这个指针并没有类型信息，只是 interface 的实现中，有另外的字段来存储类型信息。\n不过，在 Go Runtime 中还有其它的 unsafe.pointer，就没有那么幸运了。\n比如 map 和 sync.map 的实现都有 unsafe.pointer，这种就没有办法像 interface 那样统一来处理了，只能 case-by-case，根据 map/sync.map 的结构特征来逆向写死了\u0026amp;hellip;\n我们给 Go 官方 Debug 贡献了 sync.map 的逆向实现，有兴趣的可以看 CL 419177[2]。\nPART. 5\n隐藏类型 除了源码中显示定义的类型，还有一些隐藏的类型，比如：Method Value、Closure 的实现中，也都是用 struct 来表示的，这些属于不太容易被关注到的“隐藏”类型。\nMethod Value 在逆向推导中，还是比较容易踩坑的，我们给 Go 官方 Debug 贡献了这块的实现，有兴趣的可以看 CL 419179[3]。\n相比 Method Value 这种固定结构的，Closure 这种会更难搞一些，不过幸运的是，我们目前的使用过程中，还没有踩坑的经历。\nPART. 6\n逆向推导风险 这种逆向推导要做到 100% 完备还是挺难的，根本原因还是 unsafe.pointer。\n在 reflect.Value 中也有 unsafe.pointer，据我所知，这个是还没有逆向推导实现的，类似的应该也还有其它未知的。\n甚至，如果是标准库中的类型，我们还是可以一个个按需加上，如果是上层应用代码用到的 unsafe.pointer，那就很难搞了。\n还有一种可能，推导不出来的原因，就是内存泄漏的来源，我们就碰到这样一个例子，以后有机会再分享~\n幸运的是：如果是只是少量的对象没有推导出来，对于全局内存泄漏分析这种场景，通常影响其实也不大。\n另外，对于一个对象，只需要有一个路径可以推导出来也就够了。\n也就是说，如果一条推导线索因为 unsafe.pointer 断了，如果另外有一个线索可以推导到这个对象，那也是不影响的。因为从 GC root 到一个 GC obj 的引用关系链，可能会不止一条。\nPART. 7\n小结 Go 虽然是静态类型语言，不过由于提供了 unsafe.pointer，给逆向类型推导带来了很大的麻烦。好在 Go 对于 unsafe.pointer 的使用还是比较克制，把标准库中常用到的 unsafe.pointer 搞定了，基本也够用了。\n理论上来说，逆向推导这一套也适用于 C 语言，只不过 C 语言这种指针漫天飞的，动不动就来个强制类型转换，就很难搞了。\n｜相关链接｜\n[1]CL …","date":1676358000,"description":"Go 语言，如何做逆向类型推导?","dir":"blog/Go-language-how-to-do-inverse-type-derivation/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"38703e8299b15a8a7e65645ff69c5926","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","publishdate":"2023-02-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者蚂蚁集团技术专家 专注于云原生网关研发的相关工作。 本文 224 字 阅读 8 分钟 PART. 1 引","tags":["MOSN"],"title":"Go 语言，如何做逆向类型推导?","type":"blog","url":"/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","wordcount":2248},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 8 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@shuangchengsun #266\n 我想知道对于 SOFARegistry 这样的系统是如何定义 SLA 的，以及有没有一个参考值。\n A：一般 SLA 的定义和系统的关键指标相关，类似 Registry 的核心就是 Pub Sub 模型，Pub 列表变化后及时推送给 Sub；那么 SLA 的定义就可以从类似 Pub 变更后在多长的周期内能推送给所有的 Sub，这个成功率应该高于多少。参考值这个看系统维护者对这个系统的要求吧，这个没什么标准值。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/\n2.@郑长青 #2197\n 我在宿主应用使用 Ark Biz，采用 Maven 依赖方式静态合并部署，但是通过 biz-a 查看，没有启动业务应用，这个问题遇到过吗？\n A：是打包业务 Biz 的 declared-libraries 赋值问题，所以动态部署和静态部署使用 2.1.0 版本的 sofa-ark-maven-plugin 插件无法正常运行。Bug 修复的 PR 已经合并，预计周五（2 月 10 日）发布新 2.1.1 版本。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/\n本周推荐阅读 Special Weekly | 瑞兔送福，Live Long and Prosper\nSOFARegistry | 大规模集群优化实践\nNydus 加速镜像一致性校验增强\n一个 go-sql-driver 的离奇 bug\n欢迎扫码关注：\n","date":1676012400,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230210/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4c87dfeed2681923e2afaa93b04009bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230210/","publishdate":"2023-02-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230210/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230210/","wordcount":728},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@wwg2017 #5222\n 如果二阶段提交 ：1.服务端没有接收到 TM 请求 report ；2. 服务端请求没有下发下来客户端没有接收到；3.客户端接收到了执行失败了。请问上面三种情况的话，对数据订单影响是什么？\n A：第一种情况会等到超时时间，默认是 60 秒后进行回滚。在 AT 模式下，订单数据由于是一个一阶段提交会有短暂的读未提交问题，这个需要按 @globallock 注解 +select for update 达到分布式下读已提交，但是会被阻塞到事务回滚后才可读到（默认 60s）。后面两种情况都会进行无限间隔 1s 的重试直至成功回滚/提交。\n「Seata」：https://github.com/seata/seata\n2.@antjack #2197\n Allow Setting Cluster Idle Timeout to Zero to Indicate Never Timeout.This issue requests the ability to set an idle_timeout = 0, to indicate the indefinite idle timeout for upstream connection timeout.\n 「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 Special Weekly | 瑞兔送福，Live Long and Prosper\nSOFARegistry | 大规模集群优化实践\nNydus 加速镜像一致性校验增强\n一个 go-sql-driver 的离奇 bug\n欢迎扫码关注：\n","date":1675407600,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230203/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"17cef13c896ee0712ff7fad78ebafe52","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230203/","publishdate":"2023-02-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230203/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230203/","wordcount":656},{"author":null,"categories":"SOFAStack","content":" 导言：\n GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。这是去年（2022）的夏令营活动中，王瑞同学参加 Nydus 开源项目的总结，主要介绍了为 Nydus 支持镜像与文件系统一致性校验所做的相关工作。\n Nydus 简介 Nydus 是 CNCF 孵化项目 Dragonfly 的子项目，它提供了容器镜像，代码包，数据分析按需加载的能力，无需等待整个数据下载完成便可开始服务。\nNydus 在生产环境已经支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，网络带宽效率，端到端数据一致性等方面相比 OCIv1 格式有着巨大优势，并可扩展至例如 NPM 包懒加载等数据分发场景。\n目前 Nydus 由蚂蚁集团，阿里云，字节跳动联合开发，Containerd，Podman 社区接受了 Nydus 运行时作为其社区子项目，也是 KataContainers 以及 Linux v5.19 内核态原生支持的镜像加速方案。\nNydus 架构及原理 OCI 容器镜像是当前容器镜像的实现标准。它采用了分层的设计，每个镜像可包含多个镜像层。新层包含的是在旧层的基础上，新增加或者修改的文件或者被删除的文件。这种设计方式比较简单，不过也有着一定的缺陷。如需要镜像层全部堆叠后才能看到整个文件系统的视图，但不是所有数据都会被读取;同时可能已经删除或者被修改旧层中的文件，但是仍需要完整地下载和解压旧层;文件元数据修改导致整个镜像层被重新存储等。 Nydus 兼容目前的 OCI 生态，旨在通过细粒度的数据分割、去重和按需加载机制加速容器 的启动和分发，同时降低资源的消耗。\nNydus 的整体架构如下图所示。它可以通过 FUSE 给 runc 容器提供运行时的按需加载能力，也可以通过 virtiofs 承载 FUSE 协议，给 Kata Containers 等基于 VM 的容器运行时提供按需加载的能力。它可以从容器 Registry，OSS，NAS，Dragonfly supernode 等多个镜像源拉取镜像，同时内部会有本地的缓存加速容器的创建。\n在用户空间文件系统，Nydus 采用了数据和元数据分离的设计思想，元数据的修改不会导致整个镜像层的更新。原先的镜像层只存储文件的数据部分，同时数据被分块存储。拉取镜像是不需要拉取整层，只需要拉取所需文件对应的数据块即可。这也使得层与层之间，镜像与镜像之间共享数据块更加容易。上图展示了 Nydus 数据和元数据的存储格式。其中元数据以 merkle tree 的形式存储在 bootstrap 中，包含了容器启动所需要的信息。数据以 1MB 分块存储，不同镜像可以共享同一数据块。\nNydus 镜像校验意义及流程 Nydus 镜像在构建完成后，由于网络、磁盘等故障或者镜像被恶意修改，无法保证容器启动前镜像是合法的，所以需要对镜像的格式进行校验。当前的校验使用 nydusify 工具。主要分为三个部分:\n 对 Nydus 镜像的 bootstrap 进行校验，会通过 BootstrapRule 调用 nydus-image 二进制文件。nydus-image 首先检查 bootstrap 的 SuperBlock 格式是否正确，然后会从根结点开始按照文件系统层级结构检查文件或者目录的 inode 是否合法或被修改。\n 对镜像的 manifest 进行校验，会通过 ManifestRule 检验 Nydus 的 manifest 是否合法，ImageConfig 是否与原始 OCI 镜像一致等。\n 对镜像进行文件系统校验，会通过 FilesystemRule 分别挂载原始 OCI 镜像和 Nydus 镜像，然后进行校验。对于原始镜像，会使用 docker pull 拉取镜像，然后指定 lowerdir 和 upperdir，通过 OverlayFS 挂载 Rootfs；对于 Nydus 镜像，会使用 Nydusd 挂载。挂载完成后，会分别遍历两个目录，比较元数据和数据是否一致。\n 目前 Nydus 的校验方式仍有一定的限制，如元数据检查不完全，需要 docker 拉取镜像等。该项目旨在增强 nydusify 和 nydus-image 的校验功能，使校验更加易用和全面。\n文件系统校验方案 该项目当前分为以下三部分:\n 当前 nydusify check 在应用 FilesystemRule 进行校验时，对于文件元数据只检查文件路径、大小、模式和权限位以及 xattrs 是否和原始镜像一致，同时对文件数据用 blake3 计算得到哈希值并进行比较。但是由于校验内容不完整，可能会出现元数据不一致校验通过的情况。故对该结构体添加 dev、rdev、symlink、project id、uid、gid、nlink、ctime 等字段，实现对文件元数据更全面的检查。 当前 nydusify check 在应用 FilesystemRule 进行校验时，需要手动指定 source 和 Backend Type, Backend Config 才能成功应用 Nydusd 挂载并进行文件系统校验，在校验数据时，也会再次检查 Backend Type 是否指定。在大多数情况下，Backend Type 为 Registry，Backend Config 可以通过查看 Registry 的 config 文件获取相关信息，如 http.addr 字段获取地址，auth 字段获取认证信息等获取。因而用户在很多情况下并不需要手动输入上述参数。该任务旨在简化该命令，实现 Backend Type，Backend Config 的自动推断，使得用户更方便地进行校验。 (3) 当前 nydusify check 在应用 FilesystemRule 进行校验时，需要用户安装 docker，因为要使用 docker pull 命令拉取镜像。在没有 docker 的环境下，无法完成校验。可以修改该部分代码，手动下载、解压镜像，并使用 OverlayFS 挂载，从而去除对 docker 的依赖。\n文件系统校验实现细节 增加校验字段 该部分的实现较为简单。首先在原 Node 结构体增加 rdev, symlink, uid, gid, mtime 等字段。\n然后在遍历文件系统时，使用 Readlink 获取文件的软链接，通过 Lstat 系统调用获取 文件更详细的元数据信息（rdev, uid, gid, mtime 等），从而在进行比较时增加对上述字段的校验。值得注意的是 dev 不同是正常的，nlink 由于 OverlayFS 的问题无法进行校验。此外，还需要修改异常错误信息，从而遇到不一致时能够打印完整的文件元数据信息。\n简化校验参数 该部分需要实现 Backend Type 和 Backend Config 的自动推断，即如果镜像存储在 registry 中，用户无需指定上述两个参数即可完成校验。\n首先，我们需要添加上述结构体，即镜像源为 Registry 时的 Backend Config。对 …","date":1675148400,"description":"Nydus 加速镜像一致性校验增强","dir":"blog/nudus-20230131/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"483248448e3baf3c9667fae7d625f0e5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nudus-20230131/","publishdate":"2023-01-31T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/nudus-20230131/","summary":"导言： GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。这是去年（2022）的","tags":["SOFAStack"],"title":"Nydus 加速镜像一致性校验增强","type":"blog","url":"/sofastack.tech/blog/nudus-20230131/","wordcount":3175},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack GitHub issue 精选 本周各项目回复 issue 共计 5 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @fengjiachun #951\n 怎么通过GitHub Action 自动发布新版本 jar 到 maven 库？\n A：把 autoReleaseAfterClose 设置为 true，可以非常方便。\n「SOFAJraft」：https://github.com/sofastack/sofa-jraft/\n2. @canaan-wang #859\n Layotto 为什么要开发 SDK ？SDK 中的功能代码为什么不可以迁移到 Server 端？\n A：对于一些熟悉 gRPC 的用户来说，Client 端直接裸用 gRPC 都可以，但这种方式对于应用开发者是有理解成本的，所以 Layotto 的 SDK 提供的更多的是接口定义，让用户编程的时候不需要直接面向裸漏的 gRPC。举个简单的例子：假设用户可以往 gRPC 的 header 里面塞一个字段 “rpc-remote-address” 该字段用来指定 RPC 访问的远端目标地址，那么如果没 SDK，用户就得知道两件事：字段名和如何塞字段到 gRPC 的 header。但如果有 SDK，你可以提供一个函数 SetRpcTargetAddress（Address String）来直接给用户使用。\n「Layotto」：https://github.com/mosn/layotto/\n本周推荐阅读 WASM 将引领下一代计算范式[译]\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1674802800,"description":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230127/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7f4e9f1a38f28d522bf4684610397dfa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230127/","publishdate":"2023-01-27T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230127/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230127/","wordcount":762},{"author":null,"categories":"SOFA Weekly","content":"送虎迎兔\n各位 SOFAStack 社区的朋友好：\n我是 SOFAStack 社区的负责人鲁直，度过了令人难忘的虎年，我们即将迈入充满希望的兔年，在这里给大家拜个早年，祝大家兔年吉祥。\n虎年虽然有诸多的不便与艰难，但是好在开源本就是倡导异步沟通、在线协作；无论你在世界的哪个角落，只要连上互联网，都可以参与到开源社区中来。在过去的一年中，SOFAStack 社区新增了 100 多位的 Committer；他们有来自腾讯、Shoppee、MiHoYo、华信永道、同程旅行等公司的员工；也有来自高校的学生，这些 Committer 和我们已有的 Committer 一起发布了大量的新 Feature，也修复了很多深藏的 Bug。\n不过，通过线上的协作虽然能够正常进行开源项目的开发，但是联络感情最好的方式一定还是线下的 Meetup。\n在虎年出行各种不便的情况下，我们和各个社区联合，在杭州、成都、广州、合肥和上海举行了 Meetup，不过遗憾的是 SOFAStack 社区开源四周年的活动没有能够在线下举办。\n伴随着兔年的即将到来，SOFAStack 社区的开源也即将迈入第五年，没有了出行的各种限制，SOFAStack 社区的五周年活动也将在线下和大家相见。\n兔年展望\n回望 SOFAStack 社区将近五年的开源时间，一开始我们只是按照自己的粗浅理解来做开源，把代码放到 GitHub 上面去，举办一些 Meetup。\n随着和开源社区朋友们的深入沟通，我们对于开源的理解、对于社区的理解也一步步深入和加强，意识到想要让 SOFAStack 社区长期发展，除了项目本身的优秀想法之外，更需要一个开放的、活跃的社区，只有两者结合一起才能够长久地经营下去。基于此我们设计了完善的社区晋升机制，也和项目的上下游保持良好的沟通和合作关系，融入到更大的开源大家庭中。\n今年我们也会在继续在开放和有趣方面做进一步的深入，包括会把部分的项目推进到基金会孵化，使它们能够更加健康地长期发展，也会把更多有趣的活动带给大家。\n兔年准备做的几件事\nSOFABoot 4.0\nSOFABoot 将会发布 4.0 版本，适配最新发布的 Spring Boot 3.0。回想 2019 年，我们在配套设施并不完善的情况下，尝试了使用 GraalVM 做 SOFABoot 的静态化，初步感受到了 Native 能够带来的启动速度的提升。随着 Spring Boot 3.0 的发布与 Spring 对于 GraalVM 支持的完善，我们终于有机会能够把 SOFABoot 的静态化做地更加完善。\nMOSN 2.0\nMOSN 将会发布 2.0 的版本，MoE 架构将会正式和大家见面。随着我们和 Envoy 社区的重要的合作点Envoy\u0026amp;rsquo;s L7 Go extension API，我们 MOSN 2.0 的开发和测试工作也已经接近尾声，新的架构将会给 MOSN 带来更多的可能性。\nLayotto 1.0\nLayotto 将会发布 1.0 的版本，提供更多的组件支持，并且进一步完善多云与多语言的支持。\nSeata\nSeata 将会继续丰富多语言的支持，也会走向更加开放的社区。\n除了上面的项目之外，SOFAStack 社区其他的一些项目在年后也会陆陆续续公布 RoadMap，期待大家一起加入进来玩。\nLive Long and Prosper\n星际迷航里面的瓦肯人在举瓦肯手礼的时候会说著名的瓦肯祝词：“Live Long and Prosper”，这句话也非常符合 SOFAStack 开源社区的愿景，我们希望无论是 SOFAStack 的项目还是 SOFAStack 的社区，都能够“Live Long and Prosper”。\n期待与大家在兔年线下相见，Let\u0026amp;rsquo;s build the community together! Live long and prosper!\n","date":1674284400,"description":"Special Weekly | 瑞兔送福，Live Long and Prosper","dir":"blog/sofa-special-weekly/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9bce67dda0b127c88ba3f0413516f2f7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-special-weekly/","publishdate":"2023-01-21T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-special-weekly/","summary":"送虎迎兔 各位 SOFAStack 社区的朋友好： 我是 SOFAStack 社区的负责人鲁直，度过了令人难忘的虎年，我们即将迈入充满希望的兔年，在这里给大家拜个早年，祝大家兔年吉祥。","tags":["SOFA Weekly"],"title":"Special Weekly | 瑞兔送福，Live Long and Prosper","type":"blog","url":"/sofastack.tech/blog/sofa-special-weekly/","wordcount":1241},{"author":null,"categories":"SOFAStack","content":" 文｜郝洪范\n京东技术专家\nSeata-go 项目共同发起人\n微服务底层技术的探索与研究。\n本文 3482 字 阅读 7 分钟\n 对于 Go CURD Boy 来说，相信 github.com/go-sql-driver/mysql 这个库都不会陌生。基本上 Go 的 CURD 都离不开这个特别重要的库。我们在开发 Seata-go 时也使用了这个库。不过最近在使用 go-sql-driver/mysql 查询 MySQL 的时候，就出现一个很有意思的 bug, 觉得有必要分享出来，以防止后来者再次踩坑。\n PART. 1 问题详述 为了说明问题，这里不详述 Seata-go 的相关代码，用一个单独的 demo 把问题详细描述清楚。\n1.1 环境准备 在一个 MySQL 实例上准备如下环境：\nCREATE TABLE `Test1` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `create_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, -PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=101 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; 从这个 SQL 语句中可以看出来， create_time 是 timestamp 类型，这里要特别留意 timestamp 这个类型。\n现在插入一条数据，然后查看刚插入的数据的值。\ninsert into Test1 values (1, \u0026#39;2022-01-01 00:00:00\u0026#39;) 查看下 MySQL 当前的时区。请记好相关值，草蛇灰线，伏笔于此。\nshow VARIABLES like \u0026#39;%time_zone%\u0026#39;; 查询结果：\n接下来使用 MySQL unix_timestamp 查看 create_time 的时间戳：\nSELECT unix_timestamp(create_time) from Test1 where id = 1; 查询结果：\n1.2 测试程序 有如下 demo 程序，示例使用 go-sql-driver 读取 create_time 的值：\npackage main import ( \u0026amp;quot;database/sql\u0026amp;quot; \u0026amp;quot;fmt\u0026amp;quot; \u0026amp;quot;time\u0026amp;quot; _ \u0026amp;quot;github.com/go-sql-driver/mysql\u0026amp;quot; ) func main() { var user = \u0026amp;quot;user\u0026amp;quot; var pwd = \u0026amp;quot;password\u0026amp;quot; var dbName = \u0026amp;quot;dbname\u0026amp;quot; dsn := fmt.Sprintf(\u0026amp;quot;%s:%s@tcp(localhost:3306)/%stimeout=100s\u0026amp;amp;parseTime=true\u0026amp;amp;interpolateParams=true\u0026amp;quot;, user, pwd, dbName) db, err := sql.Open(\u0026amp;quot;mysql\u0026amp;quot;, dsn) if err != nil { panic(err) } defer db.Close() rows, err := db.Query(\u0026amp;quot;select create_time from Test1 limit 1\u0026amp;quot;) if err != nil { panic(err) } for rows.Next() { t := time.Time{} rows.Scan(\u0026amp;amp;t) fmt.Println(t) fmt.Println(t.Unix()) }} 我们运行个程序会输出下面的结果:\n2022-01-01 00:00:00 +0000 UTC1640995200 1.3 问题详述 发现问题所在了吗？有图如下，把结果放在一块，可以详细说明问题。\n图中红色箭头指向的两个结果，用 go-sql-driver 读取的结果和在 MySQL 中用 unix_timestamp 获取的结果明显是不一样的。\nPART. 2 问题探案 1.3 小节中最后示图可以看出，数据库中 create_time 的值 2022-01-01 00:00:00 是东八区的时间，也就是北京时间，这个时间对应的时间戳就是 1640966400 。但是 go-sql-driver 示例程序读出来的却是 1640995200 ， 这是什么值？这是 0 时区的 2022-01-01 00:00:00。\n对问题的直白描述就是：MySQL 的 create_time 是 2022-01-01 00:00:00 +008 ，而读取到的是 2022-01-01 00:00:00 +000 ，他俩压根就不是一个值。\n基本能看出来 bug 是如何发生的了。那就需要剖析下 go-sql-driver 源码，追查问题的根源。\n2.1 go-sq-driver 源码分析 这里就不粘贴 \u0026amp;quot;github.com/go-sql-driver/mysql\u0026amp;quot; 的详细源码了，只贴关键的路径。\nDebug 的时候详细关注调用路径中红色的两个方块的内存中的值。\n// https://github.com/go-sql-driver/mysql/blob/master/packets.go#L788- L798 func (rows *textRows) readRow(dest []driver.Value) error { // ... // Parse time field switch rows.rs.columns[i].fieldType { case fieldTypeTimestamp, fieldTypeDateTime, fieldTypeDate, fieldTypeNewDate: if dest[i], err = parseDateTime(dest[i].([]byte), mc.cfg.Loc); err != nil { return err } }} func parseDateTime(b []byte, loc *time.Location) (time.Time, error) { const base = \u0026amp;quot;0000-00-00 00:00:00.000000\u0026amp;quot; switch len(b) { case 10, 19, 21, 22, 23, 24, 25, 26: // up to \u0026amp;quot;YYYY-MM-DD HH:MM:SS.MMMMMM\u0026amp;quot; year, err := parseByteYear(b) month := time.Month(m) day, err := parseByte2Digits(b[8], b[9]) hour, err …","date":1673938800,"description":"一个 go-sql-driver 的离奇 bug","dir":"blog/go-sql-driver-amazing-bug/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d7361909c70b2dd88fad050699609660","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-sql-driver-amazing-bug/","publishdate":"2023-01-17T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/go-sql-driver-amazing-bug/","summary":"文｜郝洪范 京东技术专家 Seata-go 项目共同发起人 微服务底层技术的探索与研究。 本文 3482 字 阅读 7 分钟 对于 Go CURD Boy 来说，相信 github.com/go-sql-driver/mysql 这个库都不会陌生。基本上 Go 的 CURD 都离","tags":["SOFAStack"],"title":"一个 go-sql-driver 的离奇 bug","type":"blog","url":"/sofastack.tech/blog/go-sql-driver-amazing-bug/","wordcount":1881},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 6 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @dengqian #2203\n 是否支持应用级服务发现，若支持能够给提供者和消费者的代号示例吗？\n A：SOFARegistry 本身是比较存粹的服务发布和订阅功能，应用级和接口级的区别在于 Client 发送给 Registry 的是应用级的 Publisher 还是接口级的 Publisher。所以相关的应用级 Publisher 聚合以及应用级 Subscriber 订阅的逻辑主要是在 Mesh 端，而这部分 Mesh 代码暂时还没开源。稍后我们会整理完整的应用级服务上线的过程以及设计方案，发布到社区文档中。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/\n2. @yemoli #1290\n 请问 MOSN 支持增加订阅 xDS 吗？gRPC DeltaAggregatedResources。\n A：xDS 这个块还不支持，不过底层的资源是支持增加更新的，感兴趣的话语，欢迎共建~\n「MOSN」：https://github.com//mosn/mosn/\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1673593200,"description":"SOFA Weekly | 铜锁探「密」、本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20220113/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5558f66f4c819ff525bcb4708fab5700","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220113/","publishdate":"2023-01-13T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220113/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 铜锁探「密」、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220113/","wordcount":715},{"author":null,"categories":"SOFAStack","content":" 文｜李楠（GitHub ID : @loheagn）\n北京航空航天大学 21 级研究生\n云原生底层系统的开发和探索工作。\n本文 6369 字 阅读 16 分钟\nOSPP 开源之夏是由中科院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动。旨在鼓励在校学生积极参与开源软件的开发维护、促进优秀开源软件社区的蓬勃发展、培养和发掘更多优秀的开发者。\n这是去年（2022）的开源活动中，李楠同学参加 Nydus 容器开源生态集成课题的相关工作。\n| 作者有话说 |\n 大家好！我是来自北京航空航天大学的 2021 级研究生李楠，对云原生技术很感兴趣，GitHub ID 是 @loheagn。在今年上半年，我参加了 Linux 基金会的春季实习，完成了 CNCF - Kubevela: Management of Terraform state 项目的工作，并因此培养了对开源工作的兴趣。在开源之夏 2022 开放题目后，我了解到了 Nydus 项目，感觉这是一个很酷的项目，由于我之前对容器和镜像的底层技术并不是很熟悉，觉得这是个很不错的学习机会。于是便尝试投递了简历申请，最终很幸运地通过了筛选，并在严松老师的帮助下顺利完成了题目。\n PART. 1 项目背景 Nerdctl Nerdctl 是一个对标 Docker CLI 和 Docker Compose 的、用于与 Containerd （当下最流行的容器运行时，Docker 的后端也是调用的 Containerd，通常作为守护进程出现） 交互的命令行工具。\n用户可以像使用 Docker CLI 一样使用 Nerdctl 与 Containerd 进行交互，比如使用 nerdctl pull \u0026amp;lt;image_name\u0026amp;gt; 来拉取镜像、使用 nerdctl run \u0026amp;lt;image_name\u0026amp;gt; 来运行容器等等。\n相比于 Containerd 本身提供的 CTR 工具，Nerdctl 默认提供了更友好的用户体验，并尽量保持其使用方式与 Docker 一致。对于从 Docker 迁移到 Containerd 的用户，往往只需要 alias docker=nerdctl 就可以与之前获得一致的使用体验。\nOCI 镜像格式 OCI 镜像格式是 OCI （Open Container Initiative，开放容器计划） 的重要组成部分。它给出了一个厂商无关的镜像格式规范，即一个镜像应该包含哪些部分、每个部分的数据结构是如何的、这些各个部分应该以怎样的方式进行组织等等。\nOCI 镜像格式脱胎于 Docker 镜像格式，它与 Docker 镜像格式有着非常类似的结构；但它比 Docker 镜像格式有更好的兼容性，并得到了各个厂商的普遍认同。\n因此，在这里主要介绍一下 OCI 镜像格式的主要内容。\n通常所说的镜像文件其实指的是一个包含了多个文件的“包”，“包”中的这些文件提供了启动一个容器所需要的所有需要信息，其中包括但不限于，容器所使用的文件系统等数据文件，镜像所适用的平台、数据完整性校验信息等配置文件。当我们使用 docker pull 或 nerdctl pull 从镜像中心拉取镜像时，其实就是在依次拉取该镜像所包含的这些文件。\n例如，当我们使用 nerdctl pull 拉取一个 OCI 镜像时：\n从 Log 中可以清晰地看到，Nerdctl 依次拉取了一个 index 文件、一个 manifest 文件、一个 config 文件和若干个 layer 数据文件。实际上，一个标准的 OCI 镜像通常就是由这几部分构成的。\n其中，layer 文件一般是 tar 包或者压缩后的 tar 包，其包含着镜像具体的数据文件。这些 layer 文件会共同组成一个完整的文件系统（也就是从该镜像启动容器后，进入容器中看到的文件系统） 。\nconfig 文件是一个 JSON 文件。其中包含镜像的一些配置信息，比如镜像时间、修改记录、环境变量、镜像的启动命令等等。\nmanifest 文件也是一个 JSON 文件。它可以看作是镜像文件的清单，即说明了该镜像包含了哪些 layer 文件和哪个 config 文件。\n下面是一个 manifest 文件的典型例子：\n{ \u0026amp;quot;schemaVersion\u0026amp;quot;: 2, \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.manifest.v1+json\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.config.v1+json\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:0584b370e957bf9d09e10f424859a02ab0fda255103f75b3f8c7d410a4e96ed5\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 7636 }, \u0026amp;quot;layers\u0026amp;quot;: [ { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:214ca5fb90323fe769c63a12af092f2572bf1c6b300263e09883909fc865d260\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 31379476 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:50836501937ff210a4ee8eedcb17b49b3b7627c5b7104397b2a6198c569d9231\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 25338790 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:d838e0361e8efc1fb3ec2b7aed16ba935ee9b62b6631c304256b0326c048a330\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 600 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:fcc7a415e354b2e1a2fcf80005278d0439a2f87556e683bb98891414339f9bee\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: …","date":1673334000,"description":"Nerdctl 原生支持 Nydus 加速镜像","dir":"blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ef25c9d4c042e6feeca78cb7919f6fa5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","publishdate":"2023-01-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","summary":"文｜李楠（GitHub ID : @loheagn） 北京航空航天大学 21 级研究生 云原生底层系统的开发和探索工作。 本文 6369 字 阅读 16 分钟 OSPP 开源之夏是由中科院","tags":["SOFAStack"],"title":"Nerdctl 原生支持 Nydus 加速镜像","type":"blog","url":"/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","wordcount":5660},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @dengqian #2203\n Why pprof debug server do not support hot upgrade?\n A：Debug server init here：\nfunc DefaultInitStage(c *v2.MOSNConfig) { InitDefaultPath(c) InitDebugServe(c) InitializePidFile(c) InitializeTracing(c) InitializePlugin(c) InitializeWasm(c) InitializeThirdPartCodec(c) } And started here:\nfunc (m *Mosn) inheritConfig(c *v2.MOSNConfig) (err error) { m.Config = c server.EnableInheritOldMosnconfig(c.InheritOldMosnconfig) // default is graceful mode, turn graceful off by set it to false if !c.DisableUpgrade \u0026amp;amp;\u0026amp;amp; server.IsReconfigure() { m.isFromUpgrade = true if err = m.inheritHandler(); err != nil { return } } log.StartLogger.Infof(\u0026amp;quot;[mosn] [NewMosn] new mosn created\u0026amp;quot;) // start init services if err = store.StartService(nil); err != nil { log.StartLogger.Errorf(\u0026amp;quot;[mosn] [NewMosn] start service failed: %v, exit\u0026amp;quot;, err) } return } 「MOSN」：https://github.com//mosn/mosn/\n2. @yemoli #1290\n SOFARPC 发现了安全漏洞在哪提交呢？\n A：可以邮件给：khotyn.huangt@antgroup.com。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/\n本周推荐阅读 SOFARegistry | 聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1672988400,"description":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","dir":"blog/sofaweekly-20230106/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f7cd3e95e772fe4b498452c1594986a2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaweekly-20230106/","publishdate":"2023-01-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofaweekly-20230106/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofaweekly-20230106/","wordcount":596},{"author":null,"categories":"SOFAStack","content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。\n本文 9492字 阅读 24 分钟\nPART. 1 前言 1.1 什么是服务发现 在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信。这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群；具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n1.2 服务发现的考量 设计和考量一个服务发现系统，可以从下面这些指标展开：\n各个指标之间并不是相互独立的。例如对于数据一致性方案的选型也会影响到数据分区、数据复制、集群容灾、多集群同步等方案的决策，也在很大程度上决定这个服务发现系统的整体架构。\n这篇文章重点分析了各个服务发现系统的数据一致性方案，以及基于这个方案延伸出来的特性，帮助大家初步了解服务发现系统。\nPART. 2 开源产品分析 2.1 为什么需要数据一致性 根据上述描述，数据一致性在服务发现系统中如此重要，甚至会影响到整个服务发现系统的各方面架构考量，那我们到底为什么需要数据一致性呢？\n要回答这个问题，让我们从单点故障说起：早期我们使用的服务，以及服务数据存储，它们往往是部署在单节点上的。但是单节点存在单点故障，一旦单节点宕机就整个服务不可用，对业务影响非常大。随后，为了解决单点问题，软件系统引入了数据复制技术，实现多副本。\n通过数据复制方案，一方面我们可以提高服务可用性，避免单点故障；另一方面，多副本可以提升读吞吐量、甚至就近部署在业务所在的地理位置，降低访问延迟。\n随着多副本的引入，就会涉及到多个副本之间的数据怎样保持一致的问题，于是数据一致性随之而来。\n2.2 开源产品分析\n对于多个副本之间进行数据同步，一致性关系从强到弱依次是：\n 线性一致性 （Linearizability consistency）\n 顺序一致性 （Sequential consistency）\n 因果一致性 （Causal consistency）\n 最终一致性 （Eventual consistency）\n 我们对比一下目前开源的比较典型的服务发现产品，在数据一致性上的方案实现：\nPART. 3 Etcd 数据一致性 3.1 Etcd 读数据流程 1. Client：Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： Client 发送 RPC 请求到了 Server 后，KV Server 基于拦截器记录所有请求的执行耗时及错误码、来源 IP 等，也可控制请求是否允许通过；\n3. Raft： Etcd 收到读请求后，向 Etcd Raft 模块发起 Read Index 读数据请求，返回最新的 ReadState 结构体数据；\n4. MVCC：KV Server 获取到 Read State 数据后，从 MVCC 模块的 Tree Index 读取基于 Key-Version 的唯一标识 Revision；再以 Revision 作为 Key 从 Boltdb 中读取数据。\n3.2 Etcd 写数据流程 1. Client： Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： 通过一系列检查之后，然后向 Raft 模块发起 （Propose） 一个提案 （Proposal） ，提案内容为存储的 value；\n3. Raft：\na.向 Raft 模块发起提案后，KV Server 模块会等待此 put 请求；如果一个请求超时未返回结果，会出现的 EtcdServer：request timed out 错误。\nb.Raft 模块收到提案后，如果当前节点是 Follower，它会转发给 Leader，只有 Leader 才能处理写请求。Leader 收到提案后，通过 Raft 模块将 put 提案消息广播给集群各个节点，同时需要把集群 Leader 任期号、投票信息、已提交索引、提案内容持久化到一个 WAL （Write Ahead Log） 日志文件中，用于保证集群的一致性、可恢复性。\n4. Raft 模块提交 Proposal 完成后，向 MVCC 模块提交写数据。\n3.3 Raft 功能分解 共识算法的祖师爷是 Paxos， 但是由于它过于复杂、难于理解，工程实践上也较难落地，导致在工程界落地较慢。\nStandford 大学的 Diego 提出的 Raft 算法正是为了可理解性、易实现而诞生的，它通过问题分解，将复杂的共识问题拆分成三个子问题，分别是：\n Leader 选举： Leader 故障后集群能快速选出新 Leader；\n 日志复制：集群只有 Leader 能写入日志， Leader 负责复制日志到 Follower 节点，并强制 Follower 节点与自己保持相同；\n 安全性： 一个任期内集群只能产生一个 Leader、已提交的日志条目在发生 Leader 选举时，一定会存在更高任期的新 Leader 日志中、各个节点的状态机应用的任意位置的日志条目内容应一样等。\n 下面以实际场景为案例，分别深入讨论这三个子问题，看看 Raft 是如何解决这三个问题，以及在 Etcd 中的应用实现。\n关于 Raft 的 Leader 选举与日志复制，可以从 *http://www.kailing.pub/raft/index.html* 动画中进一步了解。\n3.4 Etcd 读写一致性 3.4.1 线性一致性写 所有的 Read/Write 都会来到 Leader，Write 会有 Oplog Leader 被序列化，依次顺序往后 commit，并 Apply 然后在返回，那么一旦一个 Write 被 committed，那么其前面的 Write 的 Oplog 一定就被 committed 了。所有的 Write 都是有严格的顺序的，一旦被 committed 就可见了，所以 Raft 是线性一致性写。\n3.4.2 线性一致性读 Etcd 默认的读数据流程是 Linearizability Read，那么怎么样才能读取到 Leader 已经完成提交的数据呢？\n读请求走一遍 Raft 协议\n每个 Read 都生成一个对应的 Oplog，和 Write 一样，都会走一遍一致性协议的流程，会在此 Read Oplog 被 Apply 的时候读，那么这个 Read Oplog 之前的 Write Oplog 肯定也被 Applied 了，那么一定能够被读取到，读到的也一定是最新的。\n 有什么问题?\n 不仅有日志写盘开销，还有日志复制的 RPC 开销，在读比重较大的系统中是无法接受的；\n 还多了一堆的 Raft \u0026amp;lsquo;读日志\u0026amp;rsquo;。 …","date":1672729200,"description":"SOFARegistry | 聊一聊服务发现的数据一致性","dir":"blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","fuzzywordcount":7400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"87d55af6b45db61d5fb44c2096813f0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","publishdate":"2023-01-03T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。 本文 9492字 阅读 24 分钟 PART. 1 前言 1.1 什么是","tags":["SOFAStack"],"title":"SOFARegistry | 聊一聊服务发现的数据一致性","type":"blog","url":"/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","wordcount":7378},{"author":"肖健","categories":["SOFAStack"],"content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。\n本文 9492字 阅读 24 分钟\nPART. 1 前言 1.1 什么是服务发现 在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信。这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群；具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n1.2 服务发现的考量 设计和考量一个服务发现系统，可以从下面这些指标展开：\n各个指标之间并不是相互独立的。例如对于数据一致性方案的选型也会影响到数据分区、数据复制、集群容灾、多集群同步等方案的决策，也在很大程度上决定这个服务发现系统的整体架构。\n这篇文章重点分析了各个服务发现系统的数据一致性方案，以及基于这个方案延伸出来的特性，帮助大家初步了解服务发现系统。\nPART. 2 开源产品分析 2.1 为什么需要数据一致性 根据上述描述，数据一致性在服务发现系统中如此重要，甚至会影响到整个服务发现系统的各方面架构考量，那我们到底为什么需要数据一致性呢？\n要回答这个问题，让我们从单点故障说起：早期我们使用的服务，以及服务数据存储，它们往往是部署在单节点上的。但是单节点存在单点故障，一旦单节点宕机就整个服务不可用，对业务影响非常大。随后，为了解决单点问题，软件系统引入了数据复制技术，实现多副本。\n通过数据复制方案，一方面我们可以提高服务可用性，避免单点故障；另一方面，多副本可以提升读吞吐量、甚至就近部署在业务所在的地理位置，降低访问延迟。\n随着多副本的引入，就会涉及到多个副本之间的数据怎样保持一致的问题，于是数据一致性随之而来。\n2.2 开源产品分析\n对于多个副本之间进行数据同步，一致性关系从强到弱依次是：\n 线性一致性 （Linearizability consistency）\n 顺序一致性 （Sequential consistency）\n 因果一致性 （Causal consistency）\n 最终一致性 （Eventual consistency）\n 我们对比一下目前开源的比较典型的服务发现产品，在数据一致性上的方案实现：\nPART. 3 Etcd 数据一致性 3.1 Etcd 读数据流程 1. Client：Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： Client 发送 RPC 请求到了 Server 后，KV Server 基于拦截器记录所有请求的执行耗时及错误码、来源 IP 等，也可控制请求是否允许通过；\n3. Raft： Etcd 收到读请求后，向 Etcd Raft 模块发起 Read Index 读数据请求，返回最新的 ReadState 结构体数据；\n4. MVCC：KV Server 获取到 Read State 数据后，从 MVCC 模块的 Tree Index 读取基于 Key-Version 的唯一标识 Revision；再以 Revision 作为 Key 从 Boltdb 中读取数据。\n3.2 Etcd 写数据流程 1. Client： Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： 通过一系列检查之后，然后向 Raft 模块发起 （Propose） 一个提案 （Proposal） ，提案内容为存储的 value；\n3. Raft：\na.向 Raft 模块发起提案后，KV Server 模块会等待此 put 请求；如果一个请求超时未返回结果，会出现的 EtcdServer：request timed out 错误。\nb.Raft 模块收到提案后，如果当前节点是 Follower，它会转发给 Leader，只有 Leader 才能处理写请求。Leader 收到提案后，通过 Raft 模块将 put 提案消息广播给集群各个节点，同时需要把集群 Leader 任期号、投票信息、已提交索引、提案内容持久化到一个 WAL （Write Ahead Log） 日志文件中，用于保证集群的一致性、可恢复性。\n4. Raft 模块提交 Proposal 完成后，向 MVCC 模块提交写数据。\n3.3 Raft 功能分解 共识算法的祖师爷是 Paxos， 但是由于它过于复杂、难于理解，工程实践上也较难落地，导致在工程界落地较慢。\nStandford 大学的 Diego 提出的 Raft 算法正是为了可理解性、易实现而诞生的，它通过问题分解，将复杂的共识问题拆分成三个子问题，分别是：\n Leader 选举： Leader 故障后集群能快速选出新 Leader；\n 日志复制：集群只有 Leader 能写入日志， Leader 负责复制日志到 Follower 节点，并强制 Follower 节点与自己保持相同；\n 安全性： 一个任期内集群只能产生一个 Leader、已提交的日志条目在发生 Leader 选举时，一定会存在更高任期的新 Leader 日志中、各个节点的状态机应用的任意位置的日志条目内容应一样等。\n 下面以实际场景为案例，分别深入讨论这三个子问题，看看 Raft 是如何解决这三个问题，以及在 Etcd 中的应用实现。\n关于 Raft 的 Leader 选举与日志复制，可以从 *http://www.kailing.pub/raft/index.html* 动画中进一步了解。\n3.4 Etcd 读写一致性 3.4.1 线性一致性写 所有的 Read/Write 都会来到 Leader，Write 会有 Oplog Leader 被序列化，依次顺序往后 commit，并 Apply 然后在返回，那么一旦一个 Write 被 committed，那么其前面的 Write 的 Oplog 一定就被 committed 了。所有的 Write 都是有严格的顺序的，一旦被 committed 就可见了，所以 Raft 是线性一致性写。\n3.4.2 线性一致性读 Etcd 默认的读数据流程是 Linearizability Read，那么怎么样才能读取到 Leader 已经完成提交的数据呢？\n读请求走一遍 Raft 协议\n每个 Read 都生成一个对应的 Oplog，和 Write 一样，都会走一遍一致性协议的流程，会在此 Read Oplog 被 Apply 的时候读，那么这个 Read Oplog 之前的 Write Oplog 肯定也被 Applied 了，那么一定能够被读取到，读到的也一定是最新的。\n 有什么问题?\n 不仅有日志写盘开销，还有日志复制的 RPC 开销，在读比重较大的系统中是无法接受的；\n 还多了一堆的 Raft \u0026amp;lsquo;读日志\u0026amp;rsquo;。 …","date":1672729200,"description":"SOFARegistry | 聊一聊服务发现的数据一致性","dir":"projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","fuzzywordcount":7400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"27d048a94346192098907dd51a25e4ba","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","publishdate":"2023-01-03T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。 本文 9492字 阅读 24 分钟 PART. 1 前言 1.1 什么是","tags":["SOFAStack","SOFARegistry"],"title":"SOFARegistry | 聊一聊服务发现的数据一致性","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","wordcount":7378},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 小白\n 在蚂蚁内部目前中间件升级采用的是业务方修改 POM 依赖的方式吗？\n A：是以这个方式为主的\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2. 肖文璧 提问\n Unrecognized VM option \u0026amp;lsquo;CMSParallelRemarkEnabled\u0026amp;rsquo; Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.导致 Seata-Server 无法启动是怎么回事？\n A：A：这个是因为使用了高版本的 JDK 导致。高版本的 JDK 取消了 CMS 处理器，转而采用了 ZGC 代替它。 解决方案有两个，选其中之一便可：1、降级 JDK 版本；2、在 Seata 的启动脚本中删除 CMS 的 JDK 命令。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1672383600,"description":"SOFA Weekly | 2023 我们一起加油、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221230/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"75c5a4519ec5c68e190926415dd7e767","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221230/","publishdate":"2022-12-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221230/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 2023 我们一起加油、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221230/","wordcount":607},{"author":null,"categories":"SOFAStack","content":" 文｜余硕\n上海交通大学22届毕业生阿里云开发工程师\n从事云原生底层系统的开发和探索工作。\n本文 6369 字 阅读 16 分钟\n GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。 这是今年的夏令营活动中，余硕同学参加 Nydus 开源项目的总结，主要介绍了 Nydus 为支持镜像扫描与修复所做的研究与相关工作。\n PART. 1 课题背景 Nydus 开源镜像加速框架 Nydus 是 CNCF 孵化项目 Dragonfly 的子项目，它提供了容器镜像，代码包按需加载的能力。Nydus 应用时无需等待全部数据下载完成便可开始服务。\nNydus 在生产环境中已经支撑了每日百万级别的加速镜像容器创建。它在容器启动性能、镜像空间占用、网络带宽效率、端到端数据一致性等方面相比 OCI v1 格式有着巨大优势，并可扩展至其它数据分发场景，比如 NPM 包懒加载等。\n目前 Nydus 由蚂蚁集团、阿里云、字节跳动联合开发。Containerd、Podman 社区已经接受了 Nydus 运行时作为其社区子项目，它也是 Kata Containers 以及 Linux v5.19 内核态原生支持的镜像加速方案。\n有关 Nydus 镜像加速开源项目的详细介绍，可以参考：Nydus——下一代容器镜像的探索实践。\n项目描述 为 Nydus 镜像增加一个扫描和修复的命令行工具，包含以下功能：\n 提供一个 Nydus 镜像 url 和需要替换的文件列表；\n 使用工具拉取镜像 Bootstrap；\n 找到镜像中对应的文件并替换；\n 打包成新的镜像并上传回 Registry。\n 概括来说，原有项目目标是为 Nydus 镜像实现一个扫描和修复的命令行工具，其中这些功能是这个工具或者工具组的实现流程。\n但此项目具有一定的实验性，其核心是为 Nydus 格式的镜像提供扫描和修复的功能或者指引。如果存在更好的方式，项目最终不一定要按照原有项目描述去实现。因此在接下来的课题完成过程中，我们首先对已有镜像扫描/修复的工具与服务进行了调研，来确定此课题方案的最终形态。\n镜像扫描工具及服务 扫描和修复 镜像扫描和修复可以被拆解为两个过程。扫描不更改原有的镜像内容，只需要寻找扫描目标是否存在某种缺陷；镜像修复则需要根据缺陷改动镜像，包括但不限于镜像内容，镜像层级组织等。我们调研发现，当前主流开源镜像扫描引擎包括云厂商镜像安全服务都只涉及镜像扫描的功能， 不会主动添加镜像修复的功能。\n我们分析主要的原因有：\n 直接进行镜像修复可能引入新的安全问题；\n 镜像扫描的内容存在不同种类，很可能需要为不同种类的镜像安全问题设计不同的修复方式；\n 镜像修复功能可以通过重新打包镜像替代。\n 所以，镜像安全服务暂时只是提供扫描结果的安全报告，具体的修复操作由用户自行决定。我们也准备沿用这样的思路：在本课题中，为镜像实现安全扫描的功能，并提供报告作为用户镜像修复的参考依据。\n 我们也探索讨论了镜像修复的支持，或者 Nydus 特性在镜像修复场景下的增强，比如镜像内包替换后的去重与重组等，或许这些可以是未来 Nydus 中增加的功能特性。\n 镜像扫描介绍 镜像扫描的原因与内容 容器镜像是当前容器/软件分发的基础，里面包含了容器隔离环境以及软件执行环境的相关内容。因此保障其安全性变得十分重要。镜像扫描即是要扫描镜像中的所有内容，及时发现可能包含的安全漏洞或者隐私泄露。\n综合来看，镜像扫描需要关注镜像的安全性与健壮性，扫描的内容主要分为三类：\n1. 安全漏洞。 包括系统软件包和应用软件库中可能存在的安全漏洞。可以通过比对镜像中这些库/软件包的来源、版本等与 CVE 数据库中报告的漏洞的包的来源、版本来定位可能存在的安全漏洞。\n2. 配置。 包括镜像运行的环境配置和镜像中相关内容组合可能带来的问题。帮助尽早定位配置错误以及配置错误可能带来的安全风险。\n3. 隐私。 需要扫描的是用户指定的一些隐私信息。比如用户不小心将密钥等信息存入镜像。如果在扫描配置中进行指定，扫描过程可能发现这些隐私信息，避免隐私泄露以及可能带来的安全问题。\n扫描引擎 常见的扫描引擎有 Trivy、Synk 等。Docker 官方使用的是 Synk，但它比较商业化；Trivy 是 CNCF 的项目，开放性较好。\n镜像扫描的使用方式 在我们的调研中，镜像扫描主要应用方式有三种：\n1. 基础使用。 镜像扫描的过程可以直接通过集成了镜像扫描引擎的容器运行时或者镜像扫描引擎命令行触发。比如运行 $ docker scan image-url ，可以扫描镜像，并输出相应的报告。\nsource：https://docs.docker.com/engine/scan/\n2. 流程集成。 镜像扫描的过程可以集成到镜像中心或者 CI/CD 流程中。比如将镜像扫描集成到数据中心，在每次镜像上传到数据中心时触发镜像扫描，可以保证从数据中心下载的镜像总是经过安全扫描的；集成在 CI/CD 流程中，设置触发条件，可以保证镜像生成，镜像部署等过程所使用的镜像的安全性。\nsource: https://www.containiq.com/post/container-image-scanning\n3. 扫描服务。 云厂商提供了镜像安全的服务。它们背后可能是基于前两种使用方式实现，但是还可以有很多种功能的增强。用户想使用镜像扫描的功能也可以直接购买类似的安全服务，并进行灵活的配置。\nsource: https://cloud.google.com/container-analysis/docs/on-demand-scanning-howto\nPART. 2 课题解决思路 基本思路 课题首先要解决的基本思路是，如项目描述一般为 Nydus 实现一个专属的镜像扫描工具；还是复用已有的镜像扫描引擎，在 Nydus 侧实现对接支持，从而完成 Nydus 镜像扫描的功能实现。\n我们最终选择了结合已有镜像扫描引擎的实现思路。尽管为 Nydus 实现一个专属的镜像扫描工具可以更好的利用 Nydus 的特性，但是从镜像功能生态上考虑，这并不是一个很好的方式。复用或者集成到现有的镜像扫描工具，一方面可以直接使用已实现的镜像扫描引擎中全面的内容扫描能力；另一方面，与上层镜像安全服务的对接也不用再重写相关接口。这样也可以减少一些功能定制，减少用户使用的负担。因此此课题选择了后一种实现的基本思路。\n扫描思路：FileSystem vs Image Trivy 扫描功能实现的框架 1. 控制路径。\nTrivy 在镜像扫描上由以下路径控制，每触发一次命令，会由一个 Scanner 控制。其中关键的是 artifact 和 driver 。扫描引擎一般可以支持多种格式的扫描，比如 OCI v1 镜像或者镜像 Rootfs，同时一般也支持本地或者远端存储信息等。这些一般可由 ScannerConfig 配置或者自动解析。\natifact 存储着镜像 (包括文件系统) 元信息，如果已经扫描过其中的内容，还可以存储部分解析后的信息。另外，load …","date":1672124400,"description":"Nydus 镜像扫描加速","dir":"blog/nydus-mirror-scan-acceleration/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c1a6786f703b2475c84aad66b06e85b5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-mirror-scan-acceleration/","publishdate":"2022-12-27T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/nydus-mirror-scan-acceleration/","summary":"文｜余硕 上海交通大学22届毕业生阿里云开发工程师 从事云原生底层系统的开发和探索工作。 本文 6369 字 阅读 16 分钟 GitLink 编程夏令营是在 CCF 中国计算机学会指导下","tags":["SOFAStack"],"title":"Nydus 镜像扫描加速","type":"blog","url":"/sofastack.tech/blog/nydus-mirror-scan-acceleration/","wordcount":5496},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 小白\n SOFAArk 可以把 2 个端口不一样的 Spring Boot 微服务合并到一起部署吗？比如一个是 8080 另一个端口是 8081，2 个服务都有各自的接口， 合并部署后还可以通过对应的端口来进行访问嘛？\n A：不使用 Web-Ark-Plugin 插件，每个模块会启动新的 Tomcat 实例，可以让服务用不同的 port。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2. 肖文璧 提问\n Seata 对 Java17 的版本有支持吗？\n A：A：需要 v1.6.0 版本。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1671778800,"description":"SOFA Weekly | 新年礼包已就位、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-202211223/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"af3eb0769d6765dd7994becf03bd4a1c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-202211223/","publishdate":"2022-12-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-202211223/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 新年礼包已就位、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-202211223/","wordcount":578},{"author":null,"categories":"SOFAStack","content":" 文｜戚文博 （花名：百蓦）\nDragonfly Maintainer蚂蚁集团软件工程师\n主要负责「基于 P2P 的文件以及镜像加速系统」。\n本文 2175 字 阅读 15 分钟\nPART. 1 背景 自 17 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 18 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会 （TOC） 投票决定接受 Dragonfly 作为孵化级别的托管项目。Dragonfly 多年生产实践经验打磨的下一代产品，它汲取了上一代 Dragonfly1.x[1] 的优点并针对已知问题做了大量的优化。\nNydus 作为 Dragonfly 的子项目优化了 OCIv1 镜像格式，并以此设计了一个用户态文件系统，使容器可以按需下载镜像，不再需要下载完整镜像即可启动容器。在最新版本中 Dragonfly 完成了和子项目 Nydus 的集成，让容器启动即可以按需下载镜像，减少下载量。也可以在传输过程中利用 Dragonfly P2P 的传输方式，降低回源流量并且提升下载速度。\nPART. 2 实践 注:如果没有可用的 Kubernetes 集群进行测试，推荐使用 Kind[2]。\n安装 Dragonfly\n基于 Kubernetes cluster 详细安装文档可以参考：\nhttps://d7y.io/docs/next/getting-started/quick-start/kubernetes/ 。\n使用 Kind 安装 Kubernetes 集群\n创建 Kind 多节点集群配置文件 kind-config.yaml ，配置如下:\nkind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker extraPortMappings: - containerPort: 30950 hostPort: 65001 - role: worker 使用配置文件创建 Kind 集群:\nkind create cluster --config kind-config.yaml 切换 Kubectl 的 context 到 Kind 集群:\nkubectl config use-context kind-kind Kind 加载 Dragonfly 镜像\n下载 Dragonfly latest 镜像:\ndocker pull dragonflyoss/scheduler:latest docker pull dragonflyoss/manager:latest docker pull dragonflyoss/dfdaemon:latest Kind 集群加载 Dragonfly latest 镜像:\nkind load docker-image dragonflyoss/scheduler:latest kind load docker-image dragonflyoss/manager:latest kind load docker-image dragonflyoss/dfdaemon:latest 基于 Helm Charts\n创建 Dragonfly P2P 集群\n创建 Helm Charts 配置文件 charts-config.yaml 并且开启 Peer 的预取功能, 配置如下:\nscheduler: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 seedPeer: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 download: prefetch: true dfdaemon: hostNetwork: true config: verbose: true pprofPort: 18066 metrics: :8000 download: prefetch: true proxy: defaultFilter: \u0026#39;Expires\u0026amp;amp;Signature\u0026amp;amp;ns\u0026#39; security: insecure: true tcpListen: listen: 0.0.0.0 port: 65001 registryMirror: dynamic: true url: https://index.docker.io proxies: - regx: blobs/sha256.* manager: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 使用配置文件部署 Dragonfly Helm Charts:\n$ helm repo add dragonfly https://dragonflyoss.github.io/helm-charts/$ helm install --wait --create-namespace --namespace dragonfly-system dragonfly dragonfly/dragonfly -f charts-config.yamlNAME: dragonflyLAST DEPLOYED: Wed Oct 19 04:23:22 2022NAMESPACE: dragonfly-system STATUS: deployedREVISION: 1TEST SUITE: None NOTES: 1. Get the scheduler address by running these commands: export SCHEDULER_POD_NAME=$(kubectl get pods --namespace dragonfly-system -l \u0026amp;quot;app=dragonfly,release=dragonfly,component=scheduler\u0026amp;quot; -o jsonpath={.items[0].metadata.name}) export SCHEDULER_CONTAINER_PORT=$(kubectl get pod --namespace dragonfly-system $SCHEDULER_POD_NAME -o jsonpath=\u0026amp;quot;{.spec.containers[0].ports[0].containerPort}\u0026amp;quot;) kubectl --namespace dragonfly-system port-forward $SCHEDULER_POD_NAME 8002:$SCHEDULER_CONTAINER_PORT echo \u0026amp;quot;Visit http://127.0.0.1:8002 to use your …","date":1671519600,"description":"Dragonfly 和 Nydus Mirror 模式集成实践","dir":"blog/dragonfly-and-nydus-mirror-mode-integration-practice/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"75467253523cbbd18d6aef01e3449eb4","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","publishdate":"2022-12-20T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","summary":"文｜戚文博 （花名：百蓦） Dragonfly Maintainer蚂蚁集团软件工程师 主要负责「基于 P2P 的文件以及镜像加速系统」。 本文 2175 字 阅读 15 分钟 PART. 1 背景 自 17 年开","tags":["SOFAStack"],"title":"Dragonfly 和 Nydus Mirror 模式集成实践","type":"blog","url":"/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","wordcount":2729},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.小白 提问：\n 运行之后我发现和文档写的不一样 biz 和宿主的 Spring Boot 没有隔开，文档上写的是 2.6.6 和 2.5.0 但是实际启动都是 2.6.6，这是怎么回事？\n A：不建议用不同 Spring Boot，多 host 模式只要不使用 Web-Ark-Plugin 是可以的；我用 Sofa-Ark-Spring-Guides 试了一下，可以设置不同的 host。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.吴东梁 提问：\n 保存在内存里的事务信息多久会删除一次，来避免 OOM？\n A：结束就删。\n 那如果在事务结束之后只删内存的数据，不删除数据库里面数据会不会产生问题？\n A：没有内存和数据库共用的版本，不会的。\n「Seata」：https://github.com/seata/seata\nTongsuo 8.3.2 版本发布 主要变更如下：\n1.修复 C90 下的编译问题；\n2.修复 SSL_CTX_dup() 函数的 bug；\n3.修复 NTLS ServerKeyExchange 消息的 RSA 签名问题；\n4.修复 apps/x509 的 SM2 证书签名 bug；\n5.支持新特性 - 添加导出符号前缀。\n下载地址：\nhttps://github.com/Tongsuo-Project/Tongsuo/releases/tag/8.3.2\n本周推荐阅读 Tongsuo 支持半同态加密算法 Paillier\n金融级应用开发｜SOFABoot 框架剖析\nSeata AT 模式代码级详解\nSOFA 飞船 Layotto 星球登陆计划最新进展\n欢迎扫码关注：\n","date":1671174000,"description":"SOFA Weekly | Tongsuo 8.3.2 版本发布、C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221216/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a5844a518eb6396a88e6c0ad05c590bc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221216/","publishdate":"2022-12-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221216/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Tongsuo 8.3.2 版本发布、C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221216/","wordcount":728},{"author":null,"categories":"SOFAStack","content":" 文｜李大元 （花名：达远）\nKusion 项目负责人\n来自蚂蚁集团 PaaS 核心团队，PaaS IaC 基础平台负责人。\n本文 4331 字 阅读 11 分钟\nPART. 1 后云原生时代 距离 Kubernetes 第一个 commit 已经过去八年多了，以其为代表的云原生技术早已不再是什么新技术，而是现代化应用的“标配”。现代化应用依赖的基础服务远不止 Kubernetes 一种，稍微复杂点的应用往往会同时使用到 Kubernetes 生态云原生技术、IaaS 云服务、企业内部自建系统等各种异构基础设施，可能还会有多云、混合云的部署需求，我们已经进入到了 ”后云原生时代”，只针对 Kubernetes 的运维工具早已不能满足我们的诉求。\n更复杂的是，在企业内部，这些服务一般是由不同团队维护的，一次规模化运维需要多个团队的成员互相配合才能完成，但是 App Dev、Platform Dev、SRE 各个团队之间缺少高效的协作方式。技术自身的复杂性加上低效的团队协作，使得 “后云原生时代” 的规模化运维难度有了指数级的提高。\nPART. 2 规模化运维的问题一直都在 复杂异构基础设施的规模化运维，这并不是后云原生时代特有的问题，自分布式系统诞生以来，一直都是一个难题，只是在后云原生时代，这个问题变得更加困难。十多年前业界提出了 DevOps 理念，无数企业基于此理念构建了自己的 DevOps 平台，希望解决此问题，但在实际落地的过程中往往不尽人意，Dev 团队和 Ops 团队之间如何合作？职责如何划分？几十人的平台团队，如何支持几万工程师的运维诉求？底层基础设施复杂多样，能力日新月异，如何快速让一线 Dev 享受到技术红利？这些问题一直没有得到很好的解决，最近又有人提出了 DevOps 已死，Platform Engineering 才是未来的说法。抛开概念定义，无论是 DevOps 还是 Platform Engineering，本质上都是企业规模化运维这同一命题下的不同理念，我们更需要的是一个符合技术发展趋势，能解决当前问题的解决方案。\nPART. 3 传统架构不再适用 在传统的运维思路中，解决上述问题的方法一般是构建一个 PaaS 平台，例如我们早期的蚂蚁 PaaS 平台，他是一个 Web 控制台，有 UI 界面，用户（通常是 App Dev 或 SRE）通过 UI 交互可以完成诸如发布、重启、扩缩容等操作。在技术实现上大体可以分为三部分，一个前端系统，提供用户交互的能力，作为系统入口；中间是一个后端系统，对接各个基础设施；底层是各个基础设的 API。这种架构运行了近十年，一直运行的很好，既有用户友好的交互界面，又可以屏蔽基础设施复杂性，而且各个团队之间还职责分明，但是到了如今后云原生时代，这种架构不再适用，暴露出有两个致命缺点， “费人” 、 “费时” 。\n举一个常见的例子，网络团队为其负责的 Loadbalancer（负载均衡器）开发了一种新的负载算法，需要提供给用户使用。\n在上述架构下，整个工作流程是这个样子：\n1.网络团队开发好能力，提供出 API；\n2.PaaS 后端通过编码对接底层 API，进行互联互通，屏蔽复杂性，提供面向用户的更高级别 API；\n3.PaaS 前端根据新功能修改 UI，利用后端 API 把能力透出给最终用户。\n这里存在一个问题，即使一个再小的功能，也需要 PaaS 后端和前端修改代码，整个流程下来最快也要一周才能上线，而且涉及的基础设施团队越多，效率越低。这个问题在十年前并不算是一个问题，但是在今天就是一个很大的问题，一个后云原生时代的现代化应用，使用三个云原生技术（Kubernetes + Istio + Prometheus），两个云服务（Loadbalancer + Database），一个内部自建服务，已经是一个很常见的形态了，复杂应用只会依赖的更多。如果每个基础设施都由 PaaS 团队硬编码对接一遍，PaaS 团队的人再扩大十倍也不够用。\n“费人”讲完了，我们再看看“费时”的问题。上面例子里的一个小功能，需要进行两次跨团队的协作，一次基础设施和 PaaS 后端，另一次是 PaaS 后端与 PaaS 前端。团队协作是一个很难的问题，有时候比技术本身还要难。应用的架构已经很复杂了，如果要做一次规模化运维，一次运维 100 个应用，这要和多少个团队沟通协作？要花费多少时间？没有好的协作机制，这就变成了一个不可能完成的任务。\nPART. 4 探索与实践 我们在蚂蚁集团内部进行了近两年的探索，kustomize、helm、argoCD、Terraform 这些常见的工具我们都实践过，甚至还为一些工具自研了一些辅助系统，但结果并不尽人意。这些工具要么太局限于 Kubernetes 生态，运维不了其他类型的基础设施，要么就是支持了异构基础设施，但对于 Kubernetes 生态支持的不友好，无法发挥出云原生技术的优势，而且只是运维工具的升级对于团队协作效率几乎没有提升，我们需要一套更加体系化的方案。\n回到问题本身，针对“费人”、“费时”的问题，我们提出两个思路：\n1.能否不让 PaaS 做中转，而是由 App Dev 通过一种高效自助的方式，使用到互联互通的各种基础设施能力？\n2.能否构建一个中心化的协作平台，用技术的手段规范大家的行为，标准化的进行沟通？\n从技术的角度来看，PaaS 平台需要提供灵活的工具链和工作流，基础设施所有能力都通过模块化的方式暴露出来，App Dev 利用这些平台的基本能力，自己组合、编排来解决自己的问题，过程中不需要平台层的参与。并且整个过程中涉及的所有团队，都使用统一的语言和接口进行交流，全程无需人工参与。\nPART. 5 我们的实践 经过在蚂蚁内部 PaaS 平台近两年的探索与实践，沉淀出一套端到端的完整方案， 取名为 KusionStack，目前已经开源。试图从统一异构基础设施运维与团队协作两个角度解决传统 PaaS “费人”、“费时”的问题。\n整个体系主要分为三个部分：\n1.Konfig：Git 大库，是多团队协作的中心化平台，存放着各个团队的运维意图；\n2.KCL：蚂蚁自研的配置策略 DSL，所有团队间交流的工具；\n3.Kusion：KusionStack 引擎，负责所有的运维操作。\nPlatform Dev 通过 KCL 定义好基础能力模型，App Dev 通过 import、mixin 等语言特性在应用配置模型（AppConfig）里复用这些预定义好的能力，快速在 Konfig 里描述运维意图。AppConfig 是一个精心设计过的模型，只暴露 App Dev 需要关心的属性，屏蔽基础设施的复杂性。\n永远不要低估基础设施的专业性与复杂性，即使已经成为云原生技术标准的 Kubernetes，对普通用户来说依然有很高的门槛，一个 Deployment 就有几十个字段，再加上自定义的 labels、annotations 就更多了，普通用户根本无法全部理解。或者说普通 AppDev 不应该去了解 Kubernetes，他们需要的只是发布，甚至不需要关心底层是不是 Kubernetes。\nAppConfig 经过编译 …","date":1671174000,"description":"已来到 “后云原生时代” 的我们，如何规模化运维？","dir":"blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"79ce4a433a89df3cd7edcf19c450a1f0","permalink":"https://sofastack.github.io/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","publishdate":"2022-12-16T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","summary":"文｜李大元 （花名：达远） Kusion 项目负责人 来自蚂蚁集团 PaaS 核心团队，PaaS IaC 基础平台负责人。 本文 4331 字 阅读 11 分钟 PART. 1 后云原生时代 距离 Kubernetes 第一个 commit 已经过","tags":["SOFAStack"],"title":"已来到 “后云原生时代” 的我们，如何规模化运维？","type":"blog","url":"/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","wordcount":3707},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#31:RPC 框架设计的考和量\n 活动时间：12 月 15 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#31 RPC 框架设计的考和量 本议题主要介绍 RPC 相关的概念和知识，和设计一个 RPC 框架需要关注的方面，以及从服务治理角度再谈 RPC 框架的设计，同时介绍 SOFARPC 在这些方面是如何实现的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 刘建军（花名：保义）\n SOFARPC Maintainer\n 蚂蚁集团基础组件研发，SOFARPC 开发者和维护者\n 议程 直播回放 https://www.bilibili.com/video/BV1pD4y187Gh/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1671087600,"description":"2022 年 12 月 15 日 19：00 - 20：00 ，线上直播第 31 期。","dir":"activities/sofachannel-31/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e59afb3aad30a8e2d7bc88251a256b03","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofachannel-31/","publishdate":"2022-12-15T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofachannel-31/","summary":"概要 活动主题：SOFAChannel#31:RPC 框架设计的考和量 活动时间：12 月 15 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播","tags":["SOFAChannel","SOFARPC","RPC 框架设计的考和量"],"title":"SOFAChannel#31 RPC 框架设计的考和量","type":"activities","url":"/sofastack.tech/activities/sofachannel-31/","wordcount":433},{"author":null,"categories":"SOFAStack","content":" 文｜王发康 （花名：毅松 ）\n蚂蚁集团技术专家、MOSN 项目核心开发者\n深耕于高性能网络服务器研发，目前专注于云原生 ServiceMesh、Nginx、MOSN、Envoy、Istio 等相关领域。\n本文 5574 字 阅读 14 分钟\n前言 从单体到分布式，解决了日益增长的业务在单体架构下的系统臃肿问题；从分布式到微服务，解决了服务化后的服务治理问题；从微服务到服务网格，解决了应用和基础设施耦合下的研发效能及稳定性问题。\n从微服务架构的演进历史来看，任何架构都不是一成不变，总是随着应用在不同阶段的痛点以及周边技术的发展而持续演进，而服务网格 （ServiceMesh） 概念从提出到生产落地至今已 6 年多了，那它的下一代架构应该是什么样？对此业界也有不同的声音 Service Mesh 的下一站是 Sidecarless 吗[1] ，本文主要介绍蚂蚁在这方面的探索和实践，最终如何帮业务降本增效，提升安全保障水位。\n一、 问题及挑战 谈起 ServiceMesh，大家的脑海中应该会呈现出下面这幅图，即 ServiceMesh 的 Sidecar 形态，它非常好的解决了应用和基础设施耦合下的系列问题，为业务的提效及稳定性等方面然禹功不可没。\n但是随着 ServiceMesh 的规模化增大，Sidecar 架构也随之暴露了一些劣势，譬如应用和 Sidecar 资源耦合导致相互抢占、生命周期绑定，导致应用扩缩容涉及额外 Sidecar 容器的创建及销毁开销、Sidecar 数量随着应用 Pod 数等比增加，导致其资源无法充分复用等。\n引用 redhat.com/architect/why-when-service-mesh\n1.1 资源耦合 Sidecar 形态虽然从代码维度是解耦了基础设施与应用的耦合，但是在资源方面目前仍然是和应用 Pod 绑定在一起，这就导致其资源管理成为一个难题。对此蚂蚁 ServiceMesh 在 Sidecar 资源管理[2] 进行改善，解决了初期的资源分配及管理。但随着业务的发展也暴露一些隐患，一方面 Sidecar 和应用相互抢占 CPU 可能导致引发时延毛刺问题，另一方面固定的 1\u0026amp;frasl;4 内存资源可能无法满足机房规模增大引发的网络连接数膨胀等系列问题。\n1.2 生命周期绑定 Sidecar 和应用属于同一个 Pod，而 K8s 是以 Pod 为最小单位进行管理的。这导致应用在扩缩容操作时会涉及额外 Sidecar 容器的创建及销毁开销，而 Sidecar 中的进程是基础设施软件本不应该随着应用的销毁而销毁。\n1.3 资源复用不充分 Sidecar 数量随着应用 Pod 数等比增加，而 Sidecar 上运行的都是基础设施通用能力，这将导致 Sidecar 中应用无关逻辑的 CPU 和内存等开销都在每个 Pod 中重复消耗。另外对于一些本能通过软件集中优化或硬件集中卸载的计数也无法充分施展。\n1.4 安全及业务侵入性 Sidecar 同应用同属一个 Pod，这无论对于 Sidecar 还是应用自身都是增大了安全攻击切面，另一方面 Sidecar 形态的服务治理也不算是完全业务无感的，至少要做一次 Sidecar 的注入，然后重启应用 Pod 才生效。\n二、思考及分析 对于上述 Sidecar 形态下的四个痛点：资源耦合、生命周期绑定、资源复用不充分、安全及业务侵入性，其实归根结底还是其架构导致。\n如果将 Sidecar 从应用 Pod 中剥离出来，对于资源耦合、生命周期绑定、安全侵入性问题都会迎刃而解，而资源复用粒度取决于剥离后部署的集中化程度。对于剥离后的集中化程度也并不是越集中越好，因为中心化后会增加交互时延以及能力的完整性缺失，所以在中心化和 Sidecar 化之间做一次折中，即通过 Node 化部署形态来解决，这样既可以做到同 Node 上的 Mesh 资源复用，又可以做到网络交互不跨 Node 的相关优化。\n虽然解决了 Sidecar 形态下的痛点，但是 Node 化后也引入了一些新的 “问题”。对于问题我们需要用辩证的眼光去看待，有时问题的背后可能是一个新机会。\n譬如 Sidecar 形态下的服务发现都是 Pod 级别，随着 Pod 规模的增大其服务条目成倍速增加，如果 Node 化后服务发现使用 Node IP 这样是不是可以成本的缩减服务条目，亦达到网络连接数的复用及收敛。\n- 隔离性、多租户： 多个应用共享 Mesh 后，涉及的一些应用维度的配置、内存、CPU 等资源如何相互隔离，另外对于 Sidecar 中各种基础设施组件如果自身来支持多租户，则改造成本是不可预估的。\n- 服务 pub/sub： 之前 Sidecar 形态下，Sidecar 和 APP 的 IP 是同一个 （Container 网络模式） ，Node 化后 IP 变成 Daemonset 容器的 IP，服务发现应如何管理？以及 Pod 和 Node 之间的流量如何管理。\n- 运维及安全合规\n a. Node 化后涉及到 Daemonset 自身以及应用维度的配置升级发布流程如何管控，同时出现故障时如何缩小爆炸半径；\n b. Node 化后涉及到的安全合规问题如何保证，如网络连通性如何隔离、身份等；\n c. Node 化后，Daemonset 所占用的机器成本如何规划 （超卖？独占？） 以及各个应用的资源消耗如何计算。\n三、方案介绍 将应用 Pod 中的 Sidecar 下沉到 Node，以 Daemonset 方式在每个 Node 部署。我们将该 Daemonset 命名为 NodeSentry，其定位是作为 Node 的网络基础设施，承载网络安全、流量治理、Mesh 下沉、连接收敛等 Node 相关网络治理平台。\n本文主要介绍 NodeSentry 承载 Mesh 下沉相关方案，Node 化后需要数据面 Proxy 能够高效、稳定的承载多个 Pod 的流量治理。这就要求数据面 Proxy 具备高处理性能及高研发效能，为此我们在 2021 年就其做了相关技术布局 MOSN2.0，详细介绍见 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态[3] 。\nMesh 下沉至 NodeSentry 其架构如上图所示，在新的架构下不仅能解决 Sidecar 形态的痛点，同时也具备了如下收益：\n- 资源解耦：解耦应用和基础设施的资源配额，多应用的 Mesh 资源池化、削峰填谷；\n- 资源复用：同 Node 同应用 Mesh 共享，ingress 方向连接收敛 、egress 方向连接共享、Node 级粒度 cache 命中率更高等；\n- Node 服务发现体系：解决注册中心等基础设施服务端压力以及调用端的内存消耗；\n- 提升启动速度：新架构下应用无需每次都启动 Mesh 的容器及镜像下载、SDK 初始化共享等额外操作；\n- 集中优化：云原生 L7 网络协议栈，软硬件结合性能优化，支持 IPV6，蚂蚁卡，RDMA or QUIC 等；\n- 解耦应用和网络： 同 Zero Trust Networking[4] 相关技术结合实现全局调度，有限互通等。 …","date":1670914800,"description":"降本增效：蚂蚁在Sidecarless 的探索和实践","dir":"blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7ece9ce602bb943fa14d61d09a0114a1","permalink":"https://sofastack.github.io/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","publishdate":"2022-12-13T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","summary":"文｜王发康 （花名：毅松 ） 蚂蚁集团技术专家、MOSN 项目核心开发者 深耕于高性能网络服务器研发，目前专注于云原生 ServiceMesh、Ngin","tags":["SOFAStack"],"title":"降本增效：蚂蚁在 Sidecarless 的探索和实践","type":"blog","url":"/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","wordcount":4731},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.小白 提问：\n 这个配置是起到什么作用？true\n A：declaredMode 是指：如果 biz 和宿主 biz 依赖相同的包，biz 会使用宿主 biz 内的包。即：biz 该包设置成 provided 时，安装 biz 至宿主 biz 可以正常使用，从而减小了 biz 的体积。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.肖才稳 提问：\n Seata 的回滚模式，如果数据库被其他应用改了，是不是不能回滚了？Seata 必须保证数据库只有自己一个应用用了是吗？\n A：那你可以用 XA，AT 是要保证所有操作数据库的动作都在 Seata 事务的全局事务覆盖下。也就是说，如果你这个库的这个表被其他应用用了，让这个应用也集成 Seata 就行了。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 cgo 机制 - 从 c 调用 go\nGo 内存泄漏，pprof 够用了么?\nSeata AT 模式代码级详解\nSOFA 飞船 Layotto 星球登陆计划最新进展\n欢迎扫码关注：\n","date":1670569200,"description":"SOFA Weekly | MOSN v1.3.0 版本发布、公众号半自助投稿、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221209/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c276f5a6fa8b10d73ba44cb43b79ea22","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221209/","publishdate":"2022-12-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221209/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.3.0 版本发布、公众号半自助投稿、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221209/","wordcount":664},{"author":null,"categories":"SOFAStack","content":" 文｜田阳 （花名：烈元）\nMOSN Maintainer\n专注云原生等技术领域\n本文3042字 阅读 10 分钟\n1. 背景 Service Mesh 被越来越多的公司认可并实践，在实际落地过程中也遇到了形形色色的问题，同时架构也在持续演进去解决这些问题：有的从初始的 DaemonSet mode 转变为 Sidecar mode，如 Linkerd ；有的从做 CNI 延伸到 Service Mesh 场景， 结合 eBPF 使用 DaemonSet mode，如 Cilium ；如今 Istio 也新增了 Ambient Mesh ，支持 DaemonSet mode 作为其主推模式。\n不难看出一个演进趋势就是围绕着是否需要 Sidecar 而展开，那么 Service Mesh 的下一站将会是 Sidecarless 吗？本文将对目前的社区趋势做一个简要分析， 最后也将介绍蚂蚁在这方面的探索和实践。\n2. 社区趋势 2.1 Cilium Cilium[1] 是目前最火的云原生网络技术之一，基于革命性的内核技术 eBPF，提供、保护和观察容器工作负载之间的网络连接。\n在 6 月份，Cilium 发布了 1.12 版本，其中发布了 Service Mesh 能力、Sidecarless 架构，它提供了两种模式：\n通过图表我们可以发现：针对 L3/L4 的能力，Cilium 使用内核的 eBPF 直接支持；对于 L7 的部分能力，将使用 DaemonSet 部署的 Envoy 来支持。Cilium 认为大部分能力都不需要 L7 的参与，通过 eBPF 就能满足，所以 Cilium 也称自己为内核级服务网格。\n针对于此 Cilium 也有一个解释，结合应用程序 TCPD 最终被合入 linux kernel 发展为 iptables 为例，认为 Mesh 也应该作为基础能力下沉到 linux kernel 作为网络的基础组件，就类似于 TCP，作为 Linux 的一部分透明地提供的服务。\n在当需要 L7 代理能力的时候，会构建 DaemonSet Envoy 处理 L7 的能力。Envoy 也已经有了 Namespace 的初步概念，它们被称为监听器。监听器可以携带单独的配置并独立运行，从而可以支持多租户的配置隔离 (但目前还做不到资源和故障的隔离） 。\nCilium 认为 DaemonSet 相比 Sidecar 最明显的好处就是代理数大大减少，减少资源和管理成本。\n可以看出 Cilium Service Mesh 的发展历程是由下而上，从内核层慢慢向业务层扩展自己的服务边界，由 eBPF 来支持服务网络也是有一定的立场因素。但 eBPF 并不是银弹，DaemonSet mode 也是有一些其他的问题，收益和损失都是相对的。\n2.2 Linkerd 当然，Cilium 这个架构也不乏有挑战者，其中来头最大的就是 Linkerd[2] （Service Mesh 概念的提出者） 的创始人 William Morgan ，比较有意思的是 Linkerd 最开始的架构是 DaemonSet mode ，在后面的版本才换成 Sidecar mode ，对于此，作为逆行者的他应该最有发言权。\n在 William Morgan 的最新文章[3] 中也客观提出了 eBPF 的一些局限性，为了保证 eBPF 的安全执行而不影响 kernel ，需要通过验证器验证是否有不正确的行为，这就导致 eBPF 的编写存在一定的潜规则，比如不能有无界循环；不能超过预设的大小等，代码的复杂性也就受到了一定限制。所以较复杂的逻辑用 eBPF 来实现也是有较高的成本的。\n文章中也提到了 DaemonSet 的一些弊端：\n- 资源管理不可评估：这取决于 K8s 调度多少 Pod 到该 Node；\n- 隔离性：所有应用公用一个 Proxy ，相互影响稳定性；\n- 爆炸半径变大：影响整个 Node 的 Pod 实例；\n- 安全问题更复杂：比如 Proxy 保存有整个 Node 的秘钥。\n简而言之，Sidecar 模式继续贯彻了容器级别的隔离保护 —— 内核可以在容器级别执行所有安全保护和公平的多租户调度。容器的隔离仍然可以完美的运行，而 DaemonSet 模式却破坏了这一切，重新引入了争抢式的多租户隔离问题。\n当然他也认为 eBPF 可以更好的促进 Mesh 的发展，eBPF+Sidecar 的结合是 Mesh 的未来。\n 我们也比较认可他对于 eBPF 的看法， eBPF 就像是一把瑞士军刀，小巧精湛，作为胶水把各种网络数据面连接起来，提供基础网络能力，比如提供访问加速，透明劫持，网络可观察性等能力。但要开发复杂的业务能力，在实操之后，感觉还是有点力不从心。目前我们团队也正在使用 eBPF 开发 K8s Service 和透明拦截等基础网络能力。\n William Morgan 的说法看着也不无道理，我们先不急着站队，再来看看 Istio 是怎么做的，看是否会有新的想法~\n2.3 Istio 在 9 月份，Service Mesh 领域的当家花旦 Istio 毫无征兆的发布了 Ambient Mesh ，并作为自己后续的主推架构，简单来讲就是把数据面从 Sidecar 中剥离出来独立部署，Sidecarless 架构，以彻底解决 Mesh 基础设施和应用部署耦合的问题。\n 比较好奇 Istio 在没有经过社区讨论和落地案例的情况下，是怎样决策笃定这个新的架构方向的呢？\n Istio 认为 Sidecar mode 存在如下三个问题：\n- 侵入性\n必须通过修改应用程序的 Kubernetes pod spec 来将 Sidecar 代理 “注入” 到应用程序中，并且需要将 Pod 中应用的流量重定向到 Sidecar 。因此安装或升级 Sidecar 需要重新启动应用 Pod ，这对工作负载来说可能是破坏性的。\n- 资源利用不足\n由于每个 Sidecar 代理只用于其 Pod 中相关的工作负载，因此必须针对每个 Pod 可能的最坏情况保守地配置 Sidecar 的 CPU 和内存资源。这导致了大量的资源预留，可能导致整个集群的资源利用不足。\n- 流量中断\n流量捕获和 HTTP 处理 通常由 Sidecar 完成，这些操作的计算成本很高，并且可能会破坏一些实现和 HTTP 协议不完全兼容的应用程序。\nEnvoy 的创始人也来凑了个热闹，他对 Sidecar 架构也是颇有微词。\n我们在落地过程中也是遇到了类似的痛点，比如随着机房规模和应用规模的变大，应用的连接数继续膨胀导致 CPU 和 MEM 资源占用也在持续增加，但这一切都不是应用本身想去关心的。\n那么让我们来解开 Ambient Mesh 架构真面目，是怎样来解决 Sidecar mode 的问题， 架构主要提出了分层：\n从图中可以看出，跟 Cilium 有一些类似，这儿的两层数据面都是基于 Envoy 来构建的，Secure Overlay Layer 主要处理 L4 场景，DaemonSet 部署，L7 processing Layer 主要处理 L7 场景， …","date":1669705200,"description":"Service Mesh 的下一站是 Sidecarless 吗？","dir":"blog/is-sidecarless-the-next-stop-for-servicemesh/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"620c3d0c618cffbc58020852e1ed722d","permalink":"https://sofastack.github.io/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","publishdate":"2022-11-29T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","summary":"文｜田阳 （花名：烈元） MOSN Maintainer 专注云原生等技术领域 本文3042字 阅读 10 分钟 1. 背景 Service Mesh 被越来越多的公司认可并实践，在实际落地过程中也遇到了形形色色","tags":["SOFAStack"],"title":"Service Mesh 的下一站是 Sidecarless 吗？","type":"blog","url":"/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","wordcount":3215},{"author":null,"categories":"SOFAStack","content":" 文｜王祖熙（花名：金九 )\n蚂蚁集团开发工程师\n负责国产化密码库 Tongsuo 的开发和维护\n专注于密码学、高性能网络、网络安全等领域\n本文 4316 字 阅读10 分钟\n1. 背景 在《Tongsuo 支持半同态加密算法 EC-ElGamal》中，已经阐述了同态和半同态加密算法的背景和原理，可以移步查阅。总之，同态算法在隐私计算领域有着重要的作用，目前应用比较广泛的是 Paillier 和 EC-ElGamal 半同态加密算法，它们接口类似且只支持加法同态。\n但是它们两者的性能和原理有很大的差异：\n原理方面，Paillier 是基于复合剩余类的困难性问题 （大数分解难题） 的公钥加密算法，有点类似 RSA；而 EC-ElGamal 是基于椭圆曲线数学理论的公钥加密算法，其安全性理论上要比 Paillier 要更好。\n性能方面，EC-ElGamal 的加密和密文加法性能要比 Paillier 好；而 Paillier 的解密和密文标量乘法性能要比起 EC-ElGamal 要更好更稳定 （EC-ElGamal 的解密性能与解密的数字大小有关系，数字越大可能需要解密的时间越长，这与 EC-ElGamal 解密用到的解密表有关系，而 Paillier 的解密就没有这个问题。） 。\n所以这两个产品各有优劣，大家可以根据自己的业务特点选择使用 Paillier 还是 EC-ElGamal。\n2. Paillier 原理 2.1 密钥生成 1.随机选择两个大素数 p、q，满足 ，且满足 p 和 q 的长度相等；\n2.计算以及 ，表示最小公倍数；\n3.随机选择整数，一般 g 的计算公式如下： a. 随机选择整数； b. 计算：，为了简化和提高性能，k 一般选 1，g=1+n；\n4.定义 L 函数：，计算：；\n5.公钥：(n, g)，私钥：(λ, μ)。\n2.2 加密 明文 m，满足 −n\u0026amp;lt;m\u0026amp;lt;n；\n 选择随机数 r，满足 0≤r\u0026amp;lt;n 且 ；\n 计算密文：。\n 2.3 解密\n 密文 c，满足；\n 计算明文：。\n 2.4 密文加法\n 密文：c1 和 c2，，c 就是密文加法的结果。 2.5 密文减法\n 密文：c1 和 c2，计算：，c 就是密文减法的结果。 2.6 密文标量乘法\n 密文：c1，明文标量：a，计算：，c 就是密文标量乘法的结果。 3. 正确性 3.1 加解密正确性 公式推导需要用到 Carmichael 函数和确定合数剩余的公式，下面简单说明一下：\n● Carmichael 函数\na. 设 n=pq，其中：p、q 为大素数；\nb. 欧拉函数：ϕ(n) ，Carmichael 函数：λ(n)；\nc. 当 和时，\n其中：。\n对于任意 ，有如下性质：。\n● 判定合数剩余\na. 判定合数剩余类问题是指 n=pq，其中：p、q 为大素数，任意给定，使得，则说 z 是模 的第 n 次剩余；\nb. 第 n 项剩余的集合是 的一个阶乘法子集；\nc. 每个第 n 项剩余 z 都正好拥有 n 个 n 阶的根，其中只有一个是严格小于 n 的 （即 ） ；d. 第n项剩余都可以写成 的形式。\n● 正确性验证\n解密：\n3.2 密文加法正确性 3.3 密文减法正确性 3.4 密文标量乘法正确性 4. 算法实现 4.1 接口定义 ●对象相关接口\n○公/私钥对象：PAILLIER_KEY ，该对象用来保存 Paillier 公钥和私钥的基本信息，比如 p、q、n、g、λ、μ 等信息，私钥保存所有字段，公钥只保存 n、g，其他字段为空或者 0。相关接口如下：\n// 创建 PAILLIER_KEY 对象 \\PAILLIER_KEY *PAILLIER_KEY_new(void); // 释放 PAILLIER_KEY 对象 void PAILLIER_KEY_free(PAILLIER_KEY *key); // 拷贝 PAILLIER_KEY 对象，将 src 拷贝到 dest 中 PAILLIER_KEY *PAILLIER_KEY_copy(PAILLIER_KEY *dest, PAILLIER_KEY *src); // 复制 PAILLIER_KEY 对象 PAILLIER_KEY *PAILLIER_KEY_dup(PAILLIER_KEY *key); // 将 PAILLIER_KEY 对象引用计数加1，释放 PAILLIER_KEY 对象时若引用计数不为0则不能释放其内存 intPAILLIER_KEY_up_ref(PAILLIER_KEY *key); // 生成 PAILLIER_KEY 对象中的参数，bits 为随机大素数 p、q 的二进制位长度 int PAILLIER_KEY_generate_key(PAILLIER_KEY *key, int bits); // 获取 key 的类型：公钥 or 私钥 // PAILLIER_KEY_TYPE_PUBLIC 为私钥，PAILLIER_KEY_TYPE_PRIVATE 为私钥 int PAILLIER_KEY_type(PAILLIER_KEY *key); ○上下文对象：PAILLIER_CTX，该对象用来保存公私钥对象以及一些其他内部用到的信息，是 Paillier 算法其他接口的第一个参数。相关接口如下：\n// 创建 PAILLIER_CTX 对象，key 为 paillier 公钥或者私钥，threshold 为支持最大的数字阈值，加密场景可设置为 0，解密场景可使用默认值： PAILLIER_MAX_THRESHOLDPAILLIER_CTX *PAILLIER_CTX_new(PAILLIER_KEY *key, int64_t threshold); // 释放 PAILLIER_CTX 对象 void PAILLIER_CTX_free(PAILLIER_CTX *ctx); // 拷贝 PAILLIER_CTX 对象，将 src 拷贝到 dest 中 PAILLIER_CTX *PAILLIER_CTX_copy(PAILLIER_CTX *dest, PAILLIER_CTX *src); // 复制 PAILLIER_CTX 对象 PAILLIER_CTX *PAILLIER_CTX_dup(PAILLIER_CTX *src); ○密文对象： PAILLIER_CIPHERTEXT ，该对象是用来保存 Paillier 加密后的结果信息，用到 PAILLIER_CIPHERTEXT 的地方，可调用如下接口：\n// 创建 PAILLIER_CIPHERTEXT 对象 PAILLIER_CIPHERTEXT *PAILLIER_CIPHERTEXT_new(PAILLIER_CTX *ctx); // 释放 PAILLIER_CIPHERTEXT 对象 void PAILLIER_CIPHERTEXT_free(PAILLIER_CIPHERTEXT *ciphertext); ●加密/解密接口\n// 加密，将明文 m 进行加密，结果保存到 PAILLIER_CIPHERTEXT 对象 …","date":1669100400,"description":"Tongsuo 支持半同态加密算法 Paillier","dir":"blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c3860b700dec4c686121bd9ef3565472","permalink":"https://sofastack.github.io/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","publishdate":"2022-11-22T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","summary":"文｜王祖熙（花名：金九 ) 蚂蚁集团开发工程师 负责国产化密码库 Tongsuo 的开发和维护 专注于密码学、高性能网络、网络安全等领域 本文 4316 字 阅读10 分钟 1. 背景 在","tags":["SOFAStack"],"title":"Tongsuo 支持半同态加密算法 Paillier","type":"blog","url":"/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","wordcount":3758},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.卓俊良 提问：\n Q: 22. AT 模式和 Spring @Transactional 注解连用时需要注意什么 ？\n A：@Transactional 可与 DataSourceTransactionManager 和 JTATransactionManager 连用，分别表示本地事务和 XA 分布式事务，大家常用的是与本地事务结合。当与本地事务结合时， @Transactional 和 @GlobalTransaction 连用，@Transactional 只能位于标注在 @GlobalTransaction 的同一方法层次或者位于 @GlobalTransaction 标注方法的内层。这里分布式事务的概念要大于本地事务，若将 @Transactional 标注在外层会导致分布式事务空提交，当 @Transactional 对应的 connection 提交时会报全局事务正在提交或者全局事务的 xid 不存在。\n 如果要支持 istio1.14 是需要重新适配吗？还是说有其他简化的方式？\n A：是需要适配下的，主要看新增了多少改动。\n「Seata」：https://github.com/seata/seata\n2.快叫我去学习 提问：\n Q: 34.Seata 的 JDK 版本要求是什么？\n A：目前 Seata 支持的 JDK 版本为 JDK8、11。其余版本不确保 100% 兼容。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Dragonfly 中 P2P 传输协议优化\nNydus | 容器镜像基础\nSOFARegistry | 大规模集群优化实践\n开源项目文档社区化！Tongsuo/铜锁实践\n欢迎扫码关注：\n","date":1668754800,"description":"SOFA Weekly |开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221122/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a317262c02b5a9ed70ec67cae8b88892","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221122/","publishdate":"2022-11-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221122/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221122/","wordcount":726},{"author":null,"categories":"SOFAStack","content":" 文｜孙珩珂\n上海交通大学\n本文1987字 阅读 10 分钟\n01 优化背景 此前 Dragonfly 的 P2P 下载采用静态限流策略，相关配置项在 dfget.yaml 配置文件中：\n# 下载服务选项。 download: # 总下载限速。 totalRateLimit: 1024Mi # 单个任务下载限速。 perPeerRateLimit: 512Mi 其中 perPeerRateLimit 为单个任务设置流量上限， totalRateLimit 为单个节点的所有任务设置流量上限。\n静态限流策略的理想情况是： perPeerRateLimit 设置为20M ， totalRateLimit 设置为 100M ，且该节点目前运行了 5 个或更多的 P2P 下载任务，这种情况下可以确保所有任务总带宽不会超过 100M ，且带宽会被有效利用。\n这种限流策略的缺点是：若perPeerRateLimit 设置为 20M ， totalRateLimit 设置为 100M ，并且当前该节点只运行了一个下载任务，那么该任务的最大下载速度为 20M ，和最大带宽 100M 相比，浪费了 80% 的带宽。\n因此，为了最大限度地利用带宽，需要使用动态限流来确保任务数量少时能能充分利用总带宽，而任务数量多时也能公平分配带宽。最终，我们设计出一套根据上下文进行动态限流的算法，其中上下文指各任务在过去一秒内使用的带宽，此外，算法还考虑到了任务数量、任务剩余大小、任务保底带宽等因素，性能相比原来的静态限流算法有显著提升。\n02 相关代码分析 perPeerRateLimit 配置项最终赋值给 peerTaskConductor 的pt.limiter ，由 peerTaskConductor 的 DownloadPiece() 函数里进行限速，pt.waitLimit() 进行实际限流工作，底层调用 Go 自带的限流函数 WaitN() 。\nTotalRateLimit 配置项则在创建 Daemon 时被赋值给 pieceManager 的pm.limiter ，在 pieceManager 的 DownloadPiece() 和 processPieceFromSource() 函数中用到的 pm.limiter ，而这两个函数都会由 peerTaskConductor 调用，也就是说 P2P 下载会先进行总限速，之后再进行每个任务单独限速。\n根据以上分析，Dragonfly 进行任务限速的逻辑为，每个peer task（peerTaskConductor）会有单独的限速 perPeerRateLimit ，同时 pieceManager 会有 TotalRateLimit 的总限速，以此达到单任务单独限流，同时限制所有任务总带宽的效果。\n03 优化方案 为了解决此前静态限流算法总带宽利用率不佳的缺点，需要将其改进为动态限流算法，即总带宽限速仍恒定，但每个任务的单独带宽限速需要根据上下文适度、定期调整，已达到最大化利用总带宽、同时相对公平分配带宽的目的。\n在经过数个改版后，最终我们确定了根据上下文进行限流的 sampling traffic shaper 动态限流算法。具体方案为，每个任务的单任务限流交由 TrafficShaper 组建进行统一管理， TrafficShaper 维护当前正在运行的所有任务，并且定期（每秒）更新这些任务的带宽。\n具体来说，上下文指每个任务在上一秒使用的带宽、每个任务的剩余大小、任务数量、任务保底带宽（不能低于 pieceSize ）等因素， TrafficShaper 会根据这些上下文公平地、效率最大化地为每个任务分配其下一秒的带宽（具体分配方案详见下一小节），实现动态限流的效果。\n04 优化实现 定义 TrafficShaper 接口如下：\n// TrafficShaper allocates bandwidth for running tasks dynamically type TrafficShaper interface { // Start starts the TrafficShaper Start() // Stop stops the TrafficShaper Stop() // AddTask starts managing the new task AddTask(taskID string, ptc *peerTaskConductor) // RemoveTask removes completed task RemoveTask(taskID string) // Record records task\u0026#39;s used bandwidth Record(taskID string, n int) // GetBandwidth gets the total download bandwidth in the past second GetBandwidth() int64 } 该接口有两种实现，第一种是 samplingTrafficShaper 即基于上下文的 traffic shaper ，第二种是 plainTrafficShaper 只记录带宽使用情况，除此之外不做任何动态限流工作，用于和 samplingTrafficShaper 对比性能提升。\n同时，将相关配置项修改为如下内容：\n# 下载服务选项。 download: # 总下载限速。 totalRateLimit: 1024Mi # 单个任务下载限速。 perPeerRateLimit: 512Mi # traffic shaper类型，有sampling和plain两种可选 trafficShaperType: sampling Traffic shaper 的具体运行逻辑为，由peerTaskManager维护trafficShaper，在创建peerTaskManager时，根据配置初始化trafficShaper，并且调用Start()函数，启动trafficShaper，具体来说，新建time.NewTicker，跨度为 1 秒，也即每秒trafficShaper都会调用updateLimit()函数以动态更新所有任务的带宽限流。\nupdateLimit() 函数会遍历所有运行中的任务，得出每个任务上一秒消耗的带宽以及所有任务消耗的总带宽，随后根据任务上一秒使用的带宽、任务剩余大小等因素，按比例分配带宽，具体来说首先根据上一秒该任务使用带宽以及该任务剩余大小的最大值确定下一秒该任务带宽，接着所有任务带宽根据总带宽按比例缩放，得到下一秒的真实带宽；同时需要确保每个任务的带宽不低于该任务的 pieceSize ，以免出现持续饥饿状态。\n在 peerTaskManager 的 getOrCreatePeerTaskConductor() 函数中，若新建任务，需要带宽，那么调用 AddTask() 更新所有任务的带宽，即按照已有任务的平均任务分配带宽，然后再根据总带宽上限将所有任务的带宽等比例进行缩放；根据平均带宽分配新任务带宽的优势为，避免了已经有一个任务占满了所有带 …","date":1668495600,"description":"Dragonfly 中 P2P 传输协议优化","dir":"blog/p2p-transfer-protocol-optimization-in-dragonfly/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9af455951fd545b7e7fa74b3eca908ce","permalink":"https://sofastack.github.io/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","publishdate":"2022-11-15T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","summary":"文｜孙珩珂 上海交通大学 本文1987字 阅读 10 分钟 01 优化背景 此前 Dragonfly 的 P2P 下载采用静态限流策略，相关配置项在 dfget.yaml 配置文件中： # 下载服务选项。 download: # 总下载","tags":["SOFAStack"],"title":"Dragonfly 中 P2P 传输协议优化","type":"blog","url":"/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","wordcount":2220},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. 奇奇 提问：\n Seata 可以用于生产环境吗？\n A：0.4.2 版本之后就可以上生产环境。\n「Seata」：https://github.com/seata/seata\n2. 牛康龙 提问：\n 在使用时遇到了如下图这个问题，请问该如何解决啊？ A：换 Hikari Durid 的 bug 。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读\ncgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\nGo 内存泄漏，pprof 够用了么？\nSeata AT 模式代码级详解\n欢迎扫码关注\n","date":1668150000,"description":"SOFA Weekly |本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221111/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a95c87454a97852938da43731c348498","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221111/","publishdate":"2022-11-11T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221111/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221111/","wordcount":497},{"author":null,"categories":"SOFAStack","content":" 文｜唐斌\n字节跳动基础架构研发工程师\nNydus 与 Nydus snapshotter 社区贡献者，专注存储，云原生技术。\n本文 6964 字 阅读 15 分钟\n1 Nydus 1.1 存在的问题 对于容器镜像使用者\n问题一： 启动容器慢：容器启动慢的情况普遍发生在当用户启动一个很大的容器镜像时，由于在容器准备阶段需要三步（以 overlayfs 为例）：\n- 下载镜像；\n- 解压镜像；\n- 使用 overlayfs 将容器可写层和镜像中的只读层聚合起来提供容器运行环境。\n其中，下载镜像阶段需要下载整个镜像文件，不能实现文件数据按需加载。再加上下载镜像本身受限于网络带宽，当容器镜像达到 GB 级别时，下载时间会较长，破坏了容器原本优秀的用户体验。\n问题二： 较高的本地存储成本：不同镜像之间可以共享的最小单位是镜像中的层，缺点之一是重复数据的处理效率较低。\n原因如下：\n- 首先，层内部存在重复的数据；\n- 其次，层与层之间可能存在大量重复的数据，即使有微小的差别，也会被作为不同的层；\n- 再次，根据 OCI imagespec 对删除文件和 hardlink 的设计，镜像内部已经被上层删除的文件可能仍然存在于下层，并包含在镜像中。\n对于镜像提供者\n这里的提供者主要指容器服务的镜像中心。\n问题一： 巨大的存储资源浪费。\n- 存在大量相似镜像，造成这种情况有两个原因：\n 首先，上面提到的层的缺点，导致在容器镜像中心存在许多相似镜像；\n 其次，OCI image 使用了 tar+gzip 格式来表示镜像中的层，而 tar 格式并不区分 tar archive entries ordering，这带来一个问题，如果用户在不同机器上 build 同一个镜像，最终可能会因为使用了不同的文件系统而得到不同的镜像，用户上传之后，镜像中心中会存在若干不同镜像的实质内容是完全相同的情况。\n - 镜像去重效率低\n虽然镜像中心有垃圾回收机制来实现去重功能，但其仍然以层为单位，所以只能在有完全相同 hash value 的层之间去重。\n问题二： 云原生软件供应链带来的新需求。\n随着时间推移，和软件供应链一起发展的还有对软件供应链环节的多样性攻击手段。安全防护是软件供应链中非常重要的组成，不光体现在对软件本身的安全增强，也体现在对供应链的安全增强。因为应用运行环境被前置到了容器镜像中，所以对容器镜像的安全，包括对镜像的漏洞扫描和签名成为了容器服务提供者的必要能力。\nOCI 镜像规范的缺陷\n主要的缺陷有两点：\n- tar 格式标准\n tar 格式并不区分 tar archive entries ordering，这带来一个问题，即如果用户在不同机器上 ；build 同一个镜像，最终可能会因为使用了不同的文件系统而得到不同的镜像，比如在文件系统 A 上的 order 是 foo 在 bar 之前进入 tar ，在文件系统 B 上的 order 是 bar 在 foo 之前进入tar ，那么这两个镜像是不同的；\n 当 tar 被 gzip 压缩过之后不支持 seek ，导致运行之前必须先下载并解压 targz 的 image layers，而不能实现文件数据按需加载。\n - 以层为镜像的基本单位\n 内容冗余：不同层之间相同信息在传输和存储时都是冗余内容，在不读取内容的时候无法判断到这些冗余的存在；\n 无法并行：每一层是一个整体，对同一个层既无法并行传输，也不能并行提取；\n 无法进行小块数据的校验，只有完整的层下载完成之后，才能对整个层的数据做完整性校验；\n 其他一些问题：比如，跨层数据删除难以完美处理。\n 1.2 Nydus 基础 在容器的生产实践中，偏小的容器镜像能够很快部署启动。当应用的镜像达到 GB 级以上的时候，在节点上下载镜像通常会消耗大量的时间。Dragonfly 通过引入 P2P 网络有效地提升了容器镜像大规模分发的效率。然而，用户必须等待镜像数据完整下载到本地，然后才能创建自己的容器。\nNydus 是在最新的 OCI Image-Spec 基础之上设计的容器镜像加速服务，重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。Nydus 由阿里云和蚂蚁集团的工程师合作开发，并大规模部署在内部的 生产环境中。\nNydus 优化了现有的 OCI 镜像标准格式，并以此设计了一个用户态的文件系统。通过这些优化，Nydus 能够提供这些特性：\n 容器镜像按需下载，用户不再需要下载完整镜像就能启动容器\n 块级别的镜像数据去重，最大限度为用户节省存储资源\n 镜像只有最终可用的数据，不需要保存和下载过期数据\n 端到端的数据一致性校验，为用户提供更好的数据保护\n 兼容 OCI 分发标准和 artifacts 标准，开箱即可用\n 支持不同的镜像存储后端，镜像数据不只可以存放在镜像仓库，还可以放到 NAS 或者类似 S3 的对象存储上\n 与 Dragonfly 的良好集成 1.3 Nydus 架构 Nydus 的架构主要包含两部分内容：\n- 新的镜像格式（Rafs）\n- 负责解析容器镜像的 FUSE 用户态文件系统进程\nNydus 兼容多种文件系统，能够解析 FUSE 和 virtiofs 协议来支持传统的 runc 容器、 Kata容器。对于存储后端，支持使用容器仓库（ Registery ）、OSS 对象存储 、NAS、Dragonfly 的超级节点和 Peer 节点作为 Nydus 的镜像数据存储后端。此外，为了加速启动速度，Nydus 还可以配置一个本地缓存，避免每次启动容器时都从远端数据源拉取数据。\n1.4 Nydus 特性 容器启动速度变快\n用户部署了 Nydus 镜像服务后，由于使用了按需加载镜像数据的特性，容器的启动时间明显缩短。在官网的测试数据中，Nydus 能够把常见镜像的启动时间，从数分钟缩短到数秒钟。理论上来说，容器镜像越大，Nydus 体现出来的效果越明显。\n提供运行时数据一致校验\n在传统的镜像中，镜像数据会先被解压到本地文件系统，再由容器应用去访问使用。解压前，镜像数据是完整校验的。但是解压之后，镜像数据不再能够被校验。这带来的一个问题就是，如果解压后的镜像数据被无意或者恶意地修改， 用户是无法感知的。而 Nydus 镜像不会被解压到本地，同时可以对每一次数据访问进行校验，如果数据被篡改，则可以从远端数据源重新拉取。\n从图中可以看出，对容器镜像数据进行运行时一致性校验是通过对每个数据块计算 SHA 256 实现的，这得益于 Nydus 采用分块的方式管理镜像数据。如果在镜像文件非常大的时候，对整个镜像文件计算哈希值非常不现实。\n1.5 Nydus 镜像格式：RAFS RAFS 是对 EROFS 文件系统的增强，拓展在云原生场景下的能力，使其适应容器镜像存储场景。RAFS v6 是内核态的容器镜像格式，除了将镜像格式下沉到内核态，还在镜像格式上进行了一系列优化，例如块对齐、更加精简的元数据等。\nRAFS v6 镜像格式\n1.6 Nydus -snapshotter Nydus snapshotter 是 containerd 的一个外部插件， …","date":1667977200,"description":"Nydus | 容器镜像基础","dir":"blog/container-image-basics/","fuzzywordcount":6100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa785f9400252d3285438e7ad8a39218","permalink":"https://sofastack.github.io/sofastack.tech/blog/container-image-basics/","publishdate":"2022-11-09T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/container-image-basics/","summary":"文｜唐斌 字节跳动基础架构研发工程师 Nydus 与 Nydus snapshotter 社区贡献者，专注存储，云原生技术。 本文 6964 字 阅读 15 分钟 1 Nydus 1.1 存在的问题 对于容器镜像使用者 问题一： 启动","tags":["SOFAStack"],"title":"Nydus | 容器镜像基础","type":"blog","url":"/sofastack.tech/blog/container-image-basics/","wordcount":6057},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.康政恒 提问：\n MOSN 做链路追踪是否需要 APP 配合传递 traceID、spanID 这些吗? A：链路追踪都需要 APP 配合的，这是业务决定，跟是不是 MOSN 没关系。\n 「MOSN」：https://github.com/mosn/mosn/\n2.康政恒 提问：\n MOSN 是否和 APP 也保持长链接呀，这样可以知道 APP 的存活状态。 A：保持长链接。\n 「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 SOFARegistry | 大规模集群优化实践\ncgo 机制 - 从 c 调用 go\nSeata AT 模式代码级详解\nGo 内存泄漏，pprof 够用了么？\n欢迎扫码关注：\n","date":1667545200,"description":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221104/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"32dcc5c5b6f04360aa073fe5820a4d12","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221104/","publishdate":"2022-11-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221104/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221104/","wordcount":519},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#30:Nydus 开源容器镜像加速服务的演进与未来\n 活动时间：11 月 03 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#30 Nydus 开源容器镜像加速服务的演进与未来 Nydus 在生产环境已经支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，网络带宽效率，端到端数据一致性等方面相比 OCIv1 格式有着巨大优势，并可扩展至例如 NPM 包懒加载等数据分发场景。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 严松（花名：井守）\n Nydus 镜像加速开源项目 Maintainer\n 负责蚂蚁集团基础设施研发，专注于云原生镜像与容器运行时生态。\n 议程 直播回放 https://b23.tv/Gnz9y6D\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1667458800,"description":"2022 年 11 月 03 日 19：00 - 20：00 ，线上直播第 30 期。","dir":"activities/sofa-channel-30/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"51b6ca632e0cf11ccff50820a472a320","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-30/","publishdate":"2022-11-03T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-30/","summary":"概要 活动主题：SOFAChannel#30:Nydus 开源容器镜像加速服务的演进与未来 活动时间：11 月 03 日，周四晚 19 点 活动形式：线上直播 资料","tags":["SOFAChannel","Nydus","开源容器镜像加速服务的演进与未来"],"title":"SOFAChannel#30 Nydus 开源容器镜像加速服务的演进与未来","type":"activities","url":"/sofastack.tech/activities/sofa-channel-30/","wordcount":485},{"author":null,"categories":"SOFARegistry","content":" 文｜李旭东\n专注于 SOFARegistry 及其周边基础设施的开发与优化\n本文 7016 字 阅读 15 分钟\n1 前言 SOFARegistry 在蚂蚁内部迭代升级过程中，每年大促都会引来一些新的挑战，通过不断的优化这些在大规模集群遇到的性能瓶颈，我们总结出一些优化方案，来解决大规模集群遇到的性能问题。\n通过阅读这篇文章，读者可以学习到一些 Java 和 Go 语言系统的优化技巧，在系统遇到瓶颈的时候，能够知道有哪些优化手段针对性的进行优化。\n2 大规模集群的挑战 随着业务的发展，业务的实例数在不断增长，注册中心所需要承载的数据量也在快速的增长 ，以其中 1 个集群为例，2019 年的数据为基准数据，在 2020 年 pub 接近千万级。下图是该集群历年双 11 时的数据对比。 相比 2019 年双 11，2021 年双 11 接口级的 pub 增长 200%，sub 增长 80%。实例数和数据量的增长带来推送量的二次方形式的增长，SOFARegistry 每一年大促都会经历新的挑战。\n比如，在某一年的新机房压测过程中，由于新机房规模特别大（普通机房的 4 倍），导致注册中心的推送压力变大了十倍多，出现了 ：\n- DataServer 的网络被打爆，导致大量数据变更没有及时通知到 Session ，推送延迟飙升；\n- 因为数据包过大， SessionServer 与客户端之间出现了大量的 channel overflow 推送失败，推送延迟飙升；\n- 由于实例数量过多，注册中心的推送包以及内部传输的数据包过大，很容易打满单机的网络处理上限，序列化数据也会占用大量的 CPU ；\n- 由于地址列表扩大了几倍，导致对应推送接收端 MOSN 也出现了问题，大量机器出现 OOM ， 出现大量 CPU 毛刺影响请求延迟；\n- 注册中心常见瞬间大量并发的请求，比如业务大规模重启，很容易导致瞬时注册中心自身处理能不足，如何进行限流，以及如何快速达到数据最终一致。\n3 优化方案 针对上述大规模集群遇到的挑战，我们做了以下的优化方案：\n3.1 横向扩展支撑大规模集群 在大规模集群场景下，单纯采用扩大机器规格的纵向扩展方式往往会遇到瓶颈，单机的配置是有上限的，超大的 heap gc 时也可能产生较高的暂停时间，而且恢复与备份会花费很长时间。\n3.1.1 双层数据架构进行数据分片 双层数据架构: Session (会话层：分散链接)、Data （数据层：分散数据）来实现横线扩展的能力，通过对链接和数据进行分片，SOFARegistry 可以通过横向扩容很容易的支撑更大的集群。单机采用小规格的机器，在容灾以及恢复方面也可以取得很好的效果。\nSOFARegistry 的架构可以参见： https://www.sofastack.tech/blog/explore-sofaregistry-1-infrastructure/\n3.2 应对瞬时大量请求 注册中心存在瞬时处理大量请求的场景，比如当在大量应用同时发生运维或者注册中心自身发生运维的时候，会有大量的注册请求发送到 Session 。\n同时有一些依赖注册中心的基础设施会通过变更发布数据到注册中心来通知到每一个订阅端。为了应对这种不可预见的瞬时大量请求变更，注册中心需要有一定的策略进行削峰。\n3.2.1 队列攒批处理 贴合蚂蚁的业务，为大规模集群而生，在大数据量，高并发写入下提供稳定的推送延迟，通过添加队列并进行攒批处理，提高吞吐量，对瞬间高并发请求进行削峰。\n举例：\n- Session 接收到大量 Publisher ，攒批发请求到 Data [1]\na.利用 BlockingQueue 存储需要发送 的请求，同时会配置最大容量防止 OOM\nb.独立的 Worker 线程从 BlockingQueue 中取出多个请求，创建多个 BlockingQueue 和 Worker 提高并发度\nc.按照分片规则进行分组，打包成一个请求发往不同的 DataServer\n- Session 接收到大量 Subscriber ，聚合去重后创建推送任务 *[2]*\na.Subscriber 存储到 Map的数据结构中，可以进行去重的避免短时间一个实例重复注册创建大量推送任务\nb.定时从 Map 中取出 Subscribers ，进行分组创建推送任务\nc.最大数据量是 Session 单机的所有 Subscriber ，容量可控\n- 用 Map 存储 DataServer 上发生变化数据的 DataInfoId ，聚合通知 Session 进行推送[3]\na.短时间 DataServer 的数据可能变化多次，比如大量 Publisher ，数据修复定时任务等等\nb.对这些数据变化记录 DataInfoId ， 短时间只会对 Session 通知一次变更创建推送任务\nc.最大数据量是 Data 单机全部的 DataInfoId\n- 用 Map 存储 PushTask 进行去重，避免数据连续变化触发大量推送任务[4]\na.添加了 Map size 的检查，过多的推送任务会直接丢弃，防止 OOM\nb.同样的推送任务高版本会替换掉低版本\n3.3 减少网络通讯开销 3.3.1 LocalCache Session 和 Data 之间会有大量的数据通讯，通过添加 LocalCache 可以在不增加代码架构复杂度的前提下大幅度提升系统的性能。\n对于注册中心，服务数据可以通过 dataInfoId + version 唯一标识。Session 在创建推送任务时会从 Data 拉取最新的服务数据，利用 Guava 的 LoadingCache ,大量推送任务被创建时，缓存的利用率会比较高，可以减少很多从 Data 拉取数据的开销。\n- Session 利用 LoadingCache 从 Data 拉取数据[5]\na.会传入创建推送任务时的版本（一般由 Data 的变更通知带过来）对比 Cache 内的数据是否足够新；\nb.如果不够新，清理缓存后利用 LoadingCache 从 Data 拉取一次数据；\nc. LoadingCache 会配置 maximumWeight 防止数据过多导致 OOM 。\n3.3.2 压缩推送 在集群规模比较大的时候，比如有一个应用发布了 100 个接口，每个接口的发布数据有 150B ，该应用有 8000 个实例，每个接口有 2w 订阅方。那么每次变更这个应用的机器造成的全量推送，每个推送包 1MB ， 累积需要发出 200w 个推送包，即使 Session 可以横向扩容到 100 台， Session 单机也需要在 7 秒内发出 20GB 的流量，严重阻塞 Session 的网络队列，也会很快打爆 netty buffer ，造成大量的推送失败，这么多推送包的序列化也会耗费 Session 大量的 CPU 。\n对于 Data ，如果 Session 的数量过多，每次变更需要给每台 Session 返回大量的大数据包，也会产生大量的出口流量，影响其他请求的成功率。\n由于每个实例发布的数据的相似度很高，几乎只有 IP 不一致，所以当采用压缩推送时压缩率会非常高，能压 …","date":1667458800,"description":"SOFARegistry | 大规模集群优化实践","dir":"blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"56b7649b36ba3889527d68dc2214c31d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","publishdate":"2022-11-03T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","summary":"文｜李旭东 专注于 SOFARegistry 及其周边基础设施的开发与优化 本文 7016 字 阅读 15 分钟 1 前言 SOFARegistry 在蚂蚁内部迭代升级过程中，每年大促都会引来一些新的挑战，通过不断的优","tags":["SOFARegistry"],"title":"SOFARegistry | 大规模集群优化实践","type":"blog","url":"/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","wordcount":5846},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.康恒政 提问：\n MOSN 之间是维持长链接的吗，然后像 Spring Cloud、Dubbo、Bolt 协议的数据在这个长链接上面传递吗？\n A：支持的，MOSN 原生就支持 Dubbo，Bolt 协议。\n「MOSN」：https://github.com/mosn/mosn/\n2.康恒政 提问：\n 注册中心是不是可以支持其他种类的，比如 ZooKeeper、Eureka 什么的？\n A：可以的，可以自己扩展，默认支持了 ZK 。\n「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 cgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\n从规模化平台工程实践，我们学到了什么？\n直播预告丨SOFAChannel#30《Nydus 开源容器镜像加速服务的演进与未来》\n欢迎扫码关注：\n","date":1666940400,"description":"SOFA Weekly | MOSN v1.2.0 版本发布、开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly/20221028/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8890ddd864d60166dc508e0ec80d9049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly/20221028/","publishdate":"2022-10-28T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly/20221028/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.2.0 版本发布、开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly/20221028/","wordcount":605},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 4656 字 阅读 12 分钟\n一、前言 去年刚学 go 语言的时候，写了这篇 cgo 实现机制[1] ，介绍了 cgo 的基本情况。主要介绍的是 go=\u0026amp;gt;c 这个调用方式，属于比较浅的层次。随着了解的深入，发现 c=\u0026amp;gt;go 的复杂度又高了一级，所以有了这篇文章。\n二、两个方向 首先，cgo 包含了两个方向， c=\u0026amp;gt;go ，go=\u0026amp;gt;c 。\n相对来说，go=\u0026amp;gt;c 是更简单的，是在 go runtime 创建的线程中，调用执行 c 函数。对 go 调度器而言，调用 c 函数，就相当于系统调用。执行环境还是在本线程，只是调用栈有切换，还多了一个函数调用的 ABI 对齐，对于 go runtime 依赖的 GMP 环境，都是现有的，并没有太大的区别。\n而 c=\u0026amp;gt;go 则复杂很多，是在一个 c 宿主创建的线程上，调用执行 go 函数。这意味着，需要在 c 线程中，准备好 go runtime 所需要的 GMP 环境，才能运行 go 函数。以及，go 和 c 对于线程掌控的不同，主要是信号这块。所以，复杂度又高了一级。\n三、GMP 从哪里来 首先简单解释一下，为什么需要 GMP ，因为在 go 函数运行的时候，总是假设是运行在一个 goroutine 环境中，以及绑定有对应的 M 和 P 。比如，要申请内存的时候，则会先从 P 这一层 cache 的 span 中的获取，如果这些没有的话，go runtime 就没法运行了。\n虽然 M 是线程，但是具体实现上，其实就是一个 M 的数据结构来表示，对于 c 创建的协程，获取的是 extra M ，也就是单独的表示线程的 M 数据结构。\n简单来说，c 线程需要获取的 GMP ，就是三个数据对象。在具体的实现过程中，是分为两步来的：\n1. needm 获取一个 extra M\n开启了 cgo 的情况下，go runtime 会预先创建好额外的 M ，同时还会创建一个 goroutine，跟这个 M 绑定。所以，获取到 M，也就同时得到了 G。\n而且，go runtime 对于 M 并没有限制，可以认为是无限的，也就不存在获取不到 M 的情况。\n2.exitsyscall 获取 P\n是的，这个就是 go=\u0026amp;gt;c 的反向过程。只是 P 资源是有限的，可能会出现抢不到 P 的情况，此时就得看调度机制了。\n四、调度机制 简单情况下，M 和 P 资源都顺利拿到了，这个 c 线程，就可以在 M 绑定的 goroutine 中运行指定的 go 函数了。更进一步，如果 go 函数很简单，只是简单的做点纯 CPU 计算就结束了，那么这期间则不依赖 go 的调度了。\n有两种情况，会发生调度：\n1. exitsyscall 获取不到 P 此时没法继续执行了，只能：\n1.将当前 extra M 上绑定的 g ，放入全局 g 等待队列\n2.将当前 c 线程挂起，等待 g 被唤起执行\n在 g 被唤起执行的时候，因为 g 和 M 是绑定关系：\n1.执行 g 的那个线程，会挂起，让出 P ，唤起等待的 c 线程\n2.c 线程被唤起之后，拿到 P 继续执行\n2. go 函数执行过程中发生了协程挂起 比如，go 函数中发起了网络调用，需要等待网络响应，按照之前介绍的文章，Goroutine 调度 - 网络调用[2] 。当前 g 会挂起，唤醒下一个 g ，继续执行。\n但是，因为 M 和 g 是绑定关系，此时会：\n1. g 放入等待队列\n2.当前 c 线程被挂起，等待 g 被唤醒\n3. P 被释放\n在 g 被唤醒的时候，此时肯定不是在原来的 c 线程上了\n1.当前线程挂起，让出 P，唤醒等待的 c 线程\n2.c 线程被唤醒后，拿到 P，继续执行\n直观来说，也就是在 c 线程上执行的 goroutine，并不像普通的 go 线程一样，参与 go runtime 的调度。对于 go runtime 而言，协程中的网络任务，还是以非阻塞的方式在执行，只是对于 c 线程而言，则完全是以阻塞的方式来执行了。\n为什么需要这样，还是因为线程的调用栈，只有一个，没有办法并发，需要把线程挂起，保护好调用栈。\nPS：这里的执行流程，其实跟上面抢不到 P 的流程，很类似，底层也是同一套函数在跑（核心还是 schedule）。\n五、信号处理 另外一大差异是，信号处理。\n c 语言世界里，把信号处理的权利/责任，完全交给用户了。\n go 语言，则在 runtime 做了一层处理。\n 比如，一个具体的问题，当程序运行过程中，发生了 segfault 信号，此时是应该由 go 来处理，还是 c 来响应信号呢？\n答案是，看发生 segfault 时的上下文：\n1.如果正在运行 go 代码，则交给 go runtime 来处理\n2.如果正在运行 c 代码，则还是 c 来响应\n那具体是怎么实现的呢？信号处理还是比较复杂的，有比较多的细节，这里我们只介绍几个核心点。\n1. sighandler 注册 首先，对于操作系统而言，同一个信号，只能有一个 handler 。再看 go 和 c 发生 sighandler 注册的时机：\n go 编译产生的 so 文件，被加载的时候，会注册 sighandler（仅针对 go 需要用的信号），并且会把原始的 sighandler 保存下来。\n c 可以在任意的时间，注册 sighandler，可以是任意的信号。\n 所以，推荐的做法是，在加载 go so 之前，c 先完成信号注册，在 go so 加载之后，不要再注册 sighandler 了，避免覆盖 go 注册 sighandler。\n2.信号处理 对于最简单的情况，如果一个信号，只有 c 注册了 sighandler，那么还是按照常规 c 信号处理的方式来。\n对于 sigfault 这种，go 也注册了 sighandler 的信号，按照这个流程来：\n1.操作系统触发信号时，会调用 go 注册的 sighandler（最佳实践中，go 的信号注册在后面）；\n2.go sighandler 先判断是否在 c 上下文中（简单的理解，也就是没有 g，实际上还是挺复杂的）；\n3.如果，在 c 上下文中，会调用之前保存的原始 sighandler（没有原始的 sighandler，则会临时恢复 signal 配置，重新触发信号）；\n4.如果，在 go 上下文中，则会执行普通的信号处理流程。\n其中，2 和 3 是最复杂的，因为 cgo 包含了两个方向，以及信号还有 sigmask 等等额外的因素，所以这里细节是非常多的，不过思路方向还是比较清晰的。\n六、优化 上篇 cgo 实现机制[1] ，提过优化一些思路，不过主要针对 go =\u0026amp;gt; c 这个方向。因为 c =\u0026amp;gt; go 的场景中，还有其他更重要的优化点。\n1.复用 extra M 通常情况下，最大的性能消耗点在获取/释放 M。\n1.上面提到，从 c 进入 go，需要通过 needm 来获取 M 。这期间有 5 个信 …","date":1665212400,"description":"cgo 机制 - 从 c 调用 go","dir":"blog/c-go-mechanism-calling-go-from-c/20221008/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a233624b1a608f5d80599295f0599d5b","permalink":"https://sofastack.github.io/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","publishdate":"2022-10-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 4656 字 阅读 12 分钟 一、前言","tags":["SOFAStack"],"title":"cgo 机制 - 从 c 调用 go","type":"blog","url":"/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","wordcount":4794},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. greedying 提问：\n 我发现 MOSN 去 cookie 时候，如果取不到，则返回中横线。这里万一 cookie 值就是中横线怎么办呢？\n A：你用啥接口取的？\n 用变量取的,前缀加 cookie 的 key。 \u0026amp;gt;\u0026amp;gt;MOSN 代码就是这么写的，那个 ValueNotFound 是一个短横，这是一个 feature 还是 bug？\n A：哦 确实，这儿应该返回 error 就行了，不然任何值都有可能不对。 要这样处理才合理，通过 error 来判断了。\n「MOSN」：https://github.com/mosn/mosn\n2. 卿同学 提问：\n 我看 Layotto 也在推动和 Envoy 的融合，这一块现在有进展吗？\n A：今年我们首先会开源 Envoy 的 cgo 插件，然后基于这个插件，可以把 Layotto 跑在 Envoy 上。\n「Layotto」：https://github.com/mosn/layotto\n本周推荐阅读\ncgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\nGo 内存泄漏，pprof 够用了么？\nSeata AT 模式代码级详解\n欢迎扫码关注\n","date":1665126000,"description":"SOFA Weekly | C 位大咖说 \u0026 QA","dir":"blog/sofa-weekly-20221007/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2d8af727a21b1ea54ab966afa87a0c03","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221007/","publishdate":"2022-10-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221007/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说 \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221007/","wordcount":623},{"author":null,"categories":"SOFAStack","content":"文｜杨洋（花名：凯申 )\n铜锁开源密码库创始人蚂蚁集团高级技术专家\n本文 1284 字 阅读 5 分钟\n1 前言\n如大家所见，针对铜锁开源密码库（ *https://github.com/Tongsuo-Project*）的文档，我们正在逐步地进行一些改革。\n其中，最大的一个变化是：我们把原来放在 readthedocs.org（简记 rtfd.io）上的教程和说明文档转移到了语雀上。\n为此有必要和大家解释一下，这其中的原因以及背后的一些想法。\n2 说说历史原因\n铜锁开源项目自诞生以来，其文档管理不是那么的严格和统一。\n铜锁派生自 OpenSSL ，而 OpenSSL 的文档则是以 perldoc 体系为核心，且混合了一部分的纯文本和 markdown 。OpenSSL 的这些文档内容均散落在 OpenSSL 源代码仓库的各个目录中。\n对于 perldoc 所支持的 pod 格式的文件，可以被编译成多种不同最终格式的文档，这其中以 man 手册和 html 文件为主。\n综上所述，所以铜锁项目在早期延续了编写 pod 文件并编译成 html 和 man 手册的这种模式，随着项目的发展，我们发现此模式存在若干不足，例如：\n perldoc 这套体系过于古老，文档的编写依旧停留在“非可视化”的状态。且编译过程较为复杂，和 markdown 等相比不具备优势，也不够通用；\n man 手册也比较古老，是单机的本地模式。查询文档的功能较弱，效率较低，不如 readthedocs 这种可视化的查询文档的方式来得便捷；\n OpenSSL 的文档组织形式更多的是以 API 为出发点，而不是以“教程”为出发点，这对于很多新手用户来说无从下手。\n 3 早前的一些改进\n为了解决这些不足之处，铜锁项目将文档的重心从 API 视角切换到了教程视角，即以教会用户如何通过使用铜锁来完成某种功能为核心目标，重新组织了文档的形态，并以 markdown 写了若干教程类的文档。\n这些文档需要一个呈现平台，因此我们选择了成熟的 readthdocs.org 作为铜锁文档的发布地（https://tongsuo.rtfd.io ），并持续运行了一段时间。\n在这之后，我们又发现了一些问题：\n1.访问不便。readthedocs.org 是海外的文档托管网站，国内会出现访问比较慢甚至无法访问的状况；\n2.不容易交互。更多的是单方面的信息展示，用户真有问题还是要到 Github 上提交 issue，效率比较低。\n4 “文档社区化”的诞生\n前段时间，我机缘巧合的参与了一档播客节目的录制\n*（https://www.ximalaya.com/zhubo/343307074）*。\n在录制过程中，大家也讨论到：是否可以将互动引入到开源社区的文档体系中，将开源项目的文档“社区化”，进而形成除了代码托管平台之外的、更加贴近最终用户的社区交流讨论形式。\n受此启发，我们最后决定尝试将铜锁的全部文档迁移到语雀上，利用语雀的社区化能力，增强铜锁和其用户间的互动。具体来说有如下几点：\n1.新的文档网站地址为：*https://yuque.com/tsdoc* 。目前有两个知识库，铜锁的各种文档均分类到这些知识库中，而且都是对全网公开的，后续我们也会根据需要对知识库去做一些调整；\n2.用户可以在这些文档中进行评论；3.上述知识库的文档会每天同步备份到 Github 的指定仓库中；\n4.现有的 *https://tongsuo.rtfd.io* 将不再更新。\n此外，对于 API ，我们也会重新进行梳理，将铜锁特有的 API 整理后供用户检索查询。希望大家能和我们一起参与这场“文档社区化”的试验，欢迎伙伴们充分发表自己的意见、建议以及想法，一起将这次试验更好地落地。\n本周推荐阅读\n你好，我的新名字叫“铜锁/Tongsuo”\nBabaSSL：支持半同态加密算法 EC-ElGamal\nBabaSSL 发布 8.3.0｜实现相应隐私计算的需求\nSeata AT 模式代码级详解\n","date":1664434800,"description":"开源项目文档社区化！Tongsuo/铜锁实践","dir":"blog/20220929/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8f7a5b72bc271ef963ccea749cb0e888","permalink":"https://sofastack.github.io/sofastack.tech/blog/20220929/","publishdate":"2022-09-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/20220929/","summary":"文｜杨洋（花名：凯申 ) 铜锁开源密码库创始人蚂蚁集团高级技术专家 本文 1284 字 阅读 5 分钟 1 前言 如大家所见，针对铜锁开源密码库（ *https://gi","tags":["SOFAStack"],"title":"开源项目文档社区化！Tongsuo/铜锁实践","type":"blog","url":"/sofastack.tech/blog/20220929/","wordcount":1401},{"author":null,"categories":"SOFAStack","content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。\n本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同；\n- 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。\n平台工程旨在帮助企业构建面向应用研发者的自服务运维体系，尝试通过工程化的技术手段和工作流程解决以下关键问题：\n- 设计合理的抽象层次，帮助应用研发者降低对 Infra 、platform 等技术以及运维、稳定性工作的认知负担；\n- 为应用研发者提供统一的工作界面和空间，避免用户陷入割裂的平台产品界面、复杂的工作流中；\n- 帮助研发者通过有效的工作流程和推荐路径基于 内部工程平台[4] 快速开展工作；\n- 帮助研发者通过配套的 CI 、CD 、CDRA 等产品自服务管理应用生命周期；\n- 帮助平台产品研发团队简单、高效、一致的开放其平台基础能力；\n- 通过培训、布道、运营等手段营造协同工作和分享的文化。\n事实上，不是所有人都应该或者能够成为这个领域的专家，这非常困难！\n实际上平台技术团队的专家通常也仅擅长自己的专业领域而已，特别是在云原生理念和技术广泛应用的今天，面向大量高度开放、可配置的平台技术带来的成百上千的应用配置，PaaS 领域的业务复杂性，以及高稳定性和统一治理的要求，而平台工程的目的正是为了让应用研发者尽可能简单无痛的参与到这样规模化的 DevOps 工作中。\n在蚂蚁的实践中，我们更趋向于以下这种合作状态，在团队架构和工作模式上更靠近 Google 的最佳实践。平台研发者及 SRE 成为 “ Enabler ” 支持应用研发者自服务的完成研发及交付运维，同时应用研发者使其应用可交付运维的工作结果也成为运维人员可以接手应用运维工作的基础。最终 SRE 、应用研发及运维人员把工作过程中的问题和痛点反馈给平台研发者形成正向循环。\n三、专用语言：工程化方式的一极 有什么比一种专用语言更适合开放的、自服务的、面向领域业务的问题定义，同时需要满足自动化、低安全风险、低噪音、易治理的企业内部要求吗？正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在平台工程的特定问题域内，一批配置和策略语言用于编写和管理规模化复杂配置及策略。\n不同于混合编写范式、混合工程能力的高级通用语言，这类专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将规模化复杂配置和策略编写思路和方式沉淀到语言特性中。\n在蚂蚁的平台工程实践中，我们强化了客户端的工作方式，将围绕应用运维生命周期的模型、编排、约束和策略稳定、可扩展的通过专用语言 KCL[5] 编写维护在共享仓库 Konfig[6] 中。\nKCL 是一种面向有编程能力的应用研发者的静态强类型语言，提供现代高级语言的编写体验和围绕领域目的有限功能。在平台工程实践中 KCL 不是一种仅用于编写 K-V 对的语言，而是一种面向平台工程领域的专用语言。应用研发者、 SRE 、平台研发者面向 Konfig 协同研发，通过 KCL 原生功能编写应用配置，以及在 PaaS 领域更为高频和复杂的 模型抽象[7] 、 功能函数[8] 和 约束规则[9] ，即编写稳定、可扩展的业务模型、业务逻辑、防错约束和环境规则。\nKonfig 仓库则成为统一的编程界面，工作空间和业务层载体，而基于 KCL 的安全、低噪音、低副作用、一致的编写范式更有利于长期管理和治理。\n四、分治：解构规模化问题 分治思路是解决规模化问题的钥匙，从 MapReduce 到 Kubernetes 无不体现其功效。在规模化交付运维领域，经典运维平台试图在统一的黑盒平台产品中，以内置的统一模型、编排、 provision 技术来应对全量业务场景。这样的实践可以快速启动，在小范围内奏效，但随着不同业务主体采用率提升引入差异化需求，同时随着持续变化的平台技术逐渐进入疲态。\n在蚂蚁的实践中，Konfig monorepo 是内部工程平台向研发者开放的编程界面和工作空间，帮助应用研发者以统一的编程界面编写围绕应用运维生命周期的配置和策略，从而编排和使用存量和新增的平台基础设施，按需创建管理云原生环境以及基于 RBAC 的权限，并通过 GitOps 方式管理交付过程。\nKonfig monorepo 为不同场景、项目、应用提供了独立的白盒的编程空间，其内生的扩展性来源于：\n- 灵活、可扩展、独立的客户端的 工程结构设计[10] ；\n- 独立配置块自动合并技术[11] 支持任意分块、可扩展的配置块组织；\n- 静态类型系统[12] 技术提供现代编程语言可复用、可扩展的类型化建模和约束功能；\n- 项目粒度的 GitOps CI 工作流程定义支持；\n- 基于 Kusion[13] 引擎的 provision 技术选择。\nKonfig monorepo 提供了分治的、可组合的工程结构设计、代码组织、建模方式、工作流程定义和 provision 技术选择支持，同时又以一致的研发模式和工作流承载了可扩展的业务需求。这样客户端的工作方式在保证灵活性、可扩展性、可移植性的同时也降低了对服务 …","date":1664262000,"description":"从规模化平台工程实践，我们学到了什么？","dir":"blog/sofastack20220927/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa7d711a2d4e1a4f7c4242cbfe473fa2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack20220927/","publishdate":"2022-09-27T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofastack20220927/","summary":"文｜朵晓东（花名：奕杉 ) KusionStack 负责人、蚂蚁集团资深技术专家 在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作 一、摘要 本文尝试从平台","tags":["SOFAStack"],"title":"从规模化平台工程实践，我们学到了什么？","type":"blog","url":"/sofastack.tech/blog/sofastack20220927/","wordcount":6378},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.刘家燕 提问：\n MOSN 现在支持 TCP 服务按照端口灰度么？譬如：应用场景：接入了一个 TCP 服务，分别暴露了三个端口是 60403，60269，60129，每一个端口对应不同的业务来源，调用之后会对应不同的业务处理。目的：现在对其中一个端口例如 60403 逻辑处理做了一些调整，发版验证是否顺利调用。因此，将该服务进行灰度，创建 v1，v2 版本。当监听到 60403 端口调用时，路由到v2 ；其他端口，路由到v1 。\n A：最简单的就是你建两个 listener，不同端口的 listener 的路由对应不同的 cluster，比如 cluster_v1，cluster_v2。\n 意思是给创建灰度的版本各自创建一个 listener 吗？\n A：因为本来就要监听不同的端口，所以不同端口的 listener 配置不同的 router 就行了哦。\n「MOSN」：https://github.com/mosn/mosn/\n2.Lewise Liu \u0026amp;amp; 赵宇 提问：\n 请问，MOSN 可以与新版本 Istio 控制面集成吗？\n A：目前是支持的 1.10 ，新版本的话要做一些适配。\n 具体需要哪些适配？比如 1.14 。\n A：我的理解，主要是新版本的 xDS 会新增一些 feature，如果依赖这些新 feature 的话，就需要做一些对应的适配或许也有一些在新版本里，被废弃或者调整了的（这些应该不多的）。\n「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 Seata AT 模式代码级详解\nGo 内存泄漏，pprof 够用了么？\n社区文章｜MOSN 构建 Subset 优化思路分享\nGo 代码城市上云——KusionStack 实践\n欢迎扫码关注：\n","date":1663916400,"description":"SOFA Weekly |开源人、本周 QA、本周 Contributor","dir":"blog/sofa-weekly/20220923/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0aeda2b5aff95f678add334d82d2e2b0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly/20220923/","publishdate":"2022-09-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly/20220923/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly |开源人、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly/20220923/","wordcount":879},{"author":null,"categories":"SOFAStack","content":" 文｜\n刘月财\nseata-go 项目负责人\n北京小桔科技有限公司【滴滴】开发工程师\n赵新（花名：于雨 )\n蚂蚁集团 Seata 项目开源负责人\n本文5343字 阅读 14分钟\n背景 Seata 四种事务模式中，AT 事务模式是阿里体系独创的事务模式，对业务无侵入，也是 Seata 用户最多的一种事务模式，兼具易用性与高性能。\n目前，Seata 社区正大力推进其多语言版本建设，Go、PHP、JS 和 Python 四个语言版本基本完成了 TCC 事务模式的实现。参照 Seata v1.5.2 版本的 AT 模式的实现，并结合 Seata 官方文档，本文尝试从代码角度详解 Seata AT 事务模式的详细流程，目的是梳理 Seata Java 版本 AT 模式的实现细节后，在多语言版本后续开发中，优先实现 AT 事务模式。\n1、什么是 AT 模式？ AT 模式是一种二阶段提交的分布式事务模式，它采用了本地 undo log 的方式来数据在修改前后的状态，并用它来实现回滚。从性能上来说，AT 模式由于有 undo log 的存在，一阶段执行完可以立即释放锁和连接资源，吞吐量比 XA 模式高。用户在使用 AT 模式的时候，只需要配置好对应的数据源即可，事务提交、回滚的流程都由 Seata 自动完成，对用户业务几乎没有入侵，使用便利。\n2、AT 模式与 ACID 和 CAP 谈论数据库的事务模式，一般都会先谈论事务相关的 ACID 特性，但在分布式场景下，还需要考虑其 CAP 性质。\n2.1 AT 与 ACID 数据库事务要满足原子性、一致性、持久性以及隔离性四个性质，即 ACID 。在分布式事务场景下，一般地，首先保证原子性和持久性，其次保证一致性，隔离性则因为其使用的不同数据库的锁、数据 MVCC 机制以及相关事务模式的差异， 具有多种隔离级别，如 MySQL 自身事务就有读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）、序列化（Serializable）等四种隔离级别。\n2.1.1 AT模式的读隔离 在数据库本地事务隔离级别读已提交（Read Committed） 或以上的基础上，Seata（AT 模式）的默认全局隔离级别是读未提交（Read Uncommitted） 。\n如果应用在特定场景下，必须要求全局的读已提交，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。 SELECT FOR UPDATE 语句的执行会查询全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到全局锁拿到，即读取的相关数据是已提交的，才返回。\n出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。\n详细例子参考 Seata 官网：https://seata.io/zh-cn/docs/dev/mode/at-mode.html\n2.1.2 AT 模式的写隔离 AT 会对写操作的 SQL 进行拦截，提交本地事务前，会向 TC 获取全局锁，未获取到全局锁的情况下，不能进行写，以此来保证不会发生写冲突：\n- 一阶段本地事务提交前，需要确保先拿到全局锁；\n- 拿不到全局锁，不能提交本地事务；\n- 拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。\n详细例子参考 Seata 官网：https://seata.io/zh-cn/docs/dev/mode/at-mode.html\n2.2 AT 与 CAP Seata 所有的事务模式在一般情况下，是需要保证 CP，即一致性和分区容错性，因为分布式事务的核心就是要保证数据的一致性（包括弱一致性）。比如，在一些交易场景下，涉及到多个系统的金额的变化，保证一致性可以避免系统产生资损。\n分布式系统不可避免地会出现服务不可用的情况，如 Seata 的 TC 出现不可用时，用户可能希望通过服务降级，优先保证整个服务的可用性，此时 Seata 需要从 CP 系统转换为一个保证 AP 的系统。\n比如，有一个服务是给用户端提供用户修改信息的功能，假如此时 TC 服务出现问题，为了不影响用户的使用体验，我们希望服务仍然可用，只不过所有的 SQL 的执行降级为不走全局事务，而是当做本地事务执行。\nAT 模式默认优先保证 CP，但提供了配置通道让用户在 CP 和 AP 两种模式下进行切换：\n- 配置文件的 tm.degrade-check 参数，其值为 true 则分支事务保证 AP，反之保证 CP；\n- 手动修改配置中心的 service.disableGlobalTransaction 属性为 true，则关闭全局事务实现 AP。\n3、AT 数据源代理 在 AT 模式中，用户只需要配置好 AT 的代理数据源即可， AT 的所有流程都在代理数据源中完成，对用户无感知。 AT 数据源代理的整体类结构如下图：\n AT 事务数据源代理类结构图【from *https://seata.io/zh-cn/docs/dev/mode/xa-mode.html*】\nAT 的数据源代理中，分别对目标数据库的 DataSource 、 Connection 和 Statement 进行了代理，在执行目标 SQL 动作之前，完成了 RM 资源注册、 undo log 生成、分支事务注册、分支事务提交/回滚等操作，而这些操作对用户并无感知。\n下面的时序图中，展示了 AT 模式在执行过程中，这几个代理类的动作细节：\n注：图片建议在 PC 端查看\n4、AT 模式流程 以下是 AT 模式的整体流程，从这里可以看到分布式事务各个关键动作的执行时机，每个动作细节，我们后面来讨论：\n注：图片建议在 PC 端查看\n4.1 一阶段 在 AT 模式的第一阶段， Seata 会通过代理数据源，拦截用户执行的业务 SQL ，假如用户没有开启事务，会自动开启一个新事务。如果业务 SQL 是写操作（增、删、改操作）类型，会解析业务 SQL 的语法，生成 SELECT SQL 语句，把要被修改的记录查出来，保存为 “before image” 。然后执行业务 SQL ，执行完后用同样的原理，将已经被修改的记录查出来，保存为 “after image” ，至此一个 undo log 记录就完整了。随后 RM 会向 TC 注册分支事务， TC 侧会新加锁记录，锁可以保证 AT 模式的读、写隔离。RM 再将 undo log 和业务 SQL 的本地事务提交，保证业务 SQL 和保存 undo log 记录 SQL 的原子性。\n4.2 二阶段提交 AT 模式的二阶段提交，TC 侧会将该事务的锁删除，然后通知 RM 异步删除 undo log 记录即可。\n4.3 二阶段回滚 如果 AT 模式的二阶段是回滚，那么 RM 侧需要根据一阶段保存的 undo log 数据中的 before image 记录，通过逆向 SQL 的方式，对 …","date":1663657200,"description":"Seata AT 模式代码级详解","dir":"blog/20220920/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6769242244447e5e61c3cd74b1d4fbbb","permalink":"https://sofastack.github.io/sofastack.tech/blog/20220920/","publishdate":"2022-09-20T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/20220920/","summary":"文｜ 刘月财 seata-go 项目负责人 北京小桔科技有限公司【滴滴】开发工程师 赵新（花名：于雨 ) 蚂蚁集团 Seata 项目开源负责人 本文5343字 阅读 14分钟 背景 Seata 四种事","tags":["SOFAStack"],"title":"Seata AT 模式代码级详解","type":"blog","url":"/sofastack.tech/blog/20220920/","wordcount":4292},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.杜鑫 提问：\n 想问下 MOSN 的基于 Go plugin 实现的插件机制，有相关文档介绍嘛，源码大概在哪个部分呀？想接入下试试。\n A：有好几种，有 Go plugin 独立进程的，有 Go so 编译的，我发你文档先看看。\n 这个看啦，我看文档里说 so 的方式还在 beta，没有详细介绍，想了解下 so 方式的介绍。\n A：so 的，我们最近有位同学才分享了，干货满满：https://mp.weixin.qq.com/s/VAYrtYBdzvcAOa7G_cMZRg ，这里有个 demo，https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions 以及一些插件的实现，https://github.com/mosn/extensions/tree/master/go-plugin\n「MOSN」：https://github.com/mosn/mosn/\n2.林楠 提问：\n 有一个问题，动态部署时报找不到 CommonLoggingApplicationListener 类，这个类在基座中有这个类 https://github.com/sofastack/sofa-ark/issues/561\n A：说明这个类没有成功委托给基座加载，可以断下 BizClassLoader.loadClassInternal 方法，看下模块类加载的寻找过程。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 MOSN｜Go 原生插件使用问题全解析\nGo 内存泄漏，pprof 够用了么？\n如何看待 Dapr、Layotto 这种多运行时架构？\nSOFAServerless 助力业务极速研发\n欢迎扫码关注：\n","date":1663311600,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220916/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"810dfae8641310109a14ebe511d3d818","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220916/","publishdate":"2022-09-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220916/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220916/","wordcount":864},{"author":"SOFA 团队","categories":"SOFATalk","content":" 概要 活动主题：SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 活动时间：09 月 14 日，周三晚 19 点 活动形式：线上直播 直播回放：点击观看 资料下载：戳这里 查看文章：SOFARegistry 源码解析｜推送延迟 tracre 介绍 | SOFATalk \u0026amp;lt;SOFA:Talk/\u0026amp;gt; SOFATalk 系列活动是 SOFAStack 社区开展的全新直播栏目，与以往的直播不同的是，SOFATalk 为大家搭建了一个更加自由开放的交流环境，参与者不仅可以在直播间发送弹幕讨论，还能够进入钉钉会议与嘉宾直接连麦讨论！茶余饭后，跟着 SOFA Talk 一下～\n| SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 对于分布式注册中心，整个推送过程涉及到很多的流程和节点。如何计算从发布端变更到广播给全集群所有的订阅方的延迟？以及每个阶段的延迟分别是多少？这对排查集群内部的问题及注册中心的负载具有比较大的价值，因此需要对整个推送过程进行延迟链路跟踪。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n分享嘉宾 张晨\n SOFARegistry Contributor，开源爱好者。\n 嘉宾海报 了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1663138800,"description":"2022 年 9 月 14 日 19：00 - 20：00 ，Talk 第 1 期。","dir":"activities/sofa-talk-1/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7a05d225a66088112646cb4424d8f344","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-talk-1/","publishdate":"2022-09-14T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-talk-1/","summary":"概要 活动主题：SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 活动时间：09 月 14 日，周三晚 19 点 活动形式：线上直播 直播回放：点击观看 资料下载：戳这里","tags":["SOFATalk","SOFARegistry","源码解析"],"title":"SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace","type":"activities","url":"/sofastack.tech/activities/sofa-talk-1/","wordcount":473},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者、蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 2651 字 阅读 8 分钟\nMOSN 是主要使用 Go 语言开发的云原生网络代理平台，在蚂蚁集团有着几十万容器的大规模生产应用。在这种大规模的应用中，经常会遇到各种内存问题，通常情况下 pprof heap profile 可以很好帮助分析问题。不过，有时候 pprof 也不够用，也就需要我们有更合适的工具了。\nPart.1\u0026amp;ndash;出生证 vs 暂住证 首先 pprof 确实很好用，设计实现也都很精巧，有兴趣的可以查看这篇《Go 语言 pprof heap profile 实现机制》[1]。\n用 pprof 来分析内存泄漏，通常情况下是够用了，不过有时候，也会不够用。\n这是为什么呢？因为 pprof 只是记录了内存对象被创建时的调用栈，并没有引用关系。也就是说，没有办法知道，内存对象是因为被谁引用了而导致没有被释放。对此，我的同事\u0026amp;ndash;烈元同学有一个很形象的比喻，pprof 只能看到出生证，却查不了暂住证。\nPart.2\u0026amp;ndash;需要引用关系 有些场景下，我们知道了泄漏的内存是从哪里申请的，但是翻了半天代码，也搞不清楚内存为什么没有释放。比如，内存对象经过复杂的调用传递，或者复杂的内存池复用机制，又或者传给了某个不熟悉的第三方库，在第三方库中有非预期的使用……\n在这些情况下，我们会有一个很直觉的想法是，想看看这些内存对象的引用关系。\nPart.3\u0026amp;ndash;内存引用关系火焰图 内存引用关系火焰图，是一种内存对象引用关系的可视化方式，最早应用于 OpenResty XRay 产品。这个工具确实是内存分析神器，给不少的客户定位过内存问题，感兴趣的可以移步 OpenResty 官方博客[2]。\n下图是由一个 MOSN 服务产生的，自下而上表示的是从 GC root 到 GC object 的引用关系链，宽度表示的是对象大小 （也包括其引用的对象的大小之和） 。\n有了这样的可视化结果，我们就可以直观的看到内存对象的引用关系。\n比如下图最宽的部分，表示的是 MOSN 中 cluster_manager 全局变量中引用的 cluster 内存对象：\nhttps://github.com/mosn/mosn/blob/aecc93c4b2b4801e7992387f245fe9eefa45733d/pkg/upstream/cluster/cluster_manager.go#L82\nPart.4\u0026amp;ndash;实现原理 在生成火焰图之前，首先我们需要提取两个关键信息：\n- 每个内存对象之间的引用关系；\n- 每个内存对象的类型。\n引用关系 获取引用关系比较简单，首先，我们可以在 heap 中找到所有的 GC 对象。然后遍历所有的对象，再结合 bitmap 信息，获取这个对象引用的其他对象。基本原理跟 GC mark 是类似的，虽然实现上很不一样，但因为这个是离线工具，可以简单粗暴的实现。\n类型推导 Go 语言作为编译型静态语言，是不需要为每个内存对象存储类型信息的 （有点例外的是 interface） 。如果是动态类型语言，比如 Lua，则会方便很多，每个 GC 对象都存储了对象的类型。\n所以，要获取每个对象的类型，还是比较麻烦的，也是投入时间最多的一块。当然，还是有解决办法的，简单来说就是做逆向类型推导，根据已知内存的类型信息，推导被引用的内存对象的类型信息。\n这块还是比较复杂的，有兴趣的可以看这篇《Go 语言，如何做逆向类型推导》[3]的介绍。\n生成过程 有了这两个关键信息之后，生成过程如下还是比较清晰的：\n1. 获取所有的内存对象，包括类型、大小，以及他们之间的引用关系，形成一个图；\n2. 从 root 对象出发，按照层次遍历，形成一棵树 （也就是剪枝过程，每个对象只能被引用一次） ；\n3. 将这棵树的完整引用关系，当做 backtrace dump 下来，count 是当前节点的总大小 （包括所有子节点） ，也就是火焰图上的宽度；\n4. 从 bt 文件生成 svg，这一步是 brendangregg 的 FlameGraph 标准工具链。\nPart.5\u0026amp;ndash;使用方式 这个工具是基于 Go 官方的 viewcore 改进来的。不过，鉴于 Go 官方不那么热心维护 viewcore 了，MOSN 社区先 fork 了一份，搞了个 mosn 分支，作为 MOSN 社区维护的主分支。\n之前也给 Go 官方 debug 提交了好几个 bugfix，等后面有空，我们再去提交这个 feature。\n所以，使用方式如下：\n# 编译 mosn 维护的 viewcore git clone git@github.com:mosn/debug.git cd debug/cmd/viewcore go build . # 假设已经有了一个 core 文件（CORE-FILE） # 以及对应的可执行程序文件（BIN-FILE） viewcore CORE-FILE --exe BIN-FILE objref ref.bt # 下载 FlameGraph 工具 git clone git@github.com:brendangregg/FlameGraph.git ../FlameGraph/stackcollapse-stap.pl ref.bt | ../FlameGraph/flamegraph.pl\u0026amp;gt; ref.svg # 浏览器打开 ref.svg 即可看到火焰图 如果使用碰到问题，可以随时联系我们或提交 issue（https://github.com/mosn/mosn/issues）。\n当然，倘若你成功定位了某个问题，也欢迎与我们共同分享，Let\u0026amp;rsquo;s have fun together！\nMOSN 用户钉钉群：33547952\n相关链接 [1] 《Go 语言 pprof heap profile 实现机制》：https://uncledou.site/2022/go-pprof-heap/\n[2] OpenResty 官方博客：https://blog.openresty.com.cn/cn/openresty-xray-case-yundun/\n[3] 《Go 语言，如何做逆向类型推导》：https://uncledou.site/2022/go-type-derivation/\n了解更多… MOSN Star 一下✨： https://github.com/mosn/mosn\n插播一条好消息！🤩\n对 Go 语言开发感兴趣的小伙伴们,欢迎大家参与到近期正热的 GoCity 项目体验\n点击此处查看演示视频，快速入门吧🥳\n本周推荐阅读 MOSN 反向通道详解\nGo 原生插件使用问题全解析\nGo 代码城市上云\u0026amp;ndash;KusionStack 实践\nMOSN 文档使用指南\n欢迎扫码关注：\n","date":1663052400,"description":"Go 内存泄漏，pprof 够用了吗？","dir":"blog/is-pprof-enough-for-go-memory-leak/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c96e193420c2f17fd7653b33766f4296","permalink":"https://sofastack.github.io/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","publishdate":"2022-09-13T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者、蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 2651 字 阅读 8 分钟 MOSN 是主","tags":["SOFAStack"],"title":"Go 内存泄漏，pprof 够用了吗？","type":"blog","url":"/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","wordcount":2059},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过\u0026amp;rdquo;SOFA WEEKLY\u0026amp;rdquo;的形式回复\n1.我是一个小胖子 提问：\n MOSN 现在是已经完整支持 xDS 协议了吗？\n A：支持 istio1.10。\n 如果要支持 istio1.14 是需要重新适配吗？还是说有其他简化的方式？\n A：是需要适配下的，主要看新增了多少改动。\n「MOSN」：https://github.com/mosn/mosn/\n2.林楠 提问：\n 关在 uninstall biz 包的时候，没有从内嵌 Tomcat 卸载掉，接口仍能访问。看到 demo 中的提示是由于未注册 BeforeBizStopEvent，所以不具备动态卸载能力。想问下 SOFAArk 是否有计划做 Tomcat 的动态卸载，如果想自行实现的话，是不是调用 ArkTomcatWebServer 实例的 stop 方法就能够实现动态卸载？\n A：Spring Boot 模块没有动态卸载能力：https://github.com/sofastack/sofa-ark/issues/554#issuecomment-1207183454\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 MOSN｜Go 原生插件使用问题全解析\n社区文章｜MOSN反向通道详解\nMOSN 文档使用指南\nSOFAServerless 助力业务极速研发\n欢迎扫码关注：\n","date":1662706800,"description":"SOFA Weekly | Go 代码城市、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220909/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b48f13a6692060ffac5ff1eeb1886fb2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220909/","publishdate":"2022-09-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220909/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Go 代码城市、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220909/","wordcount":749},{"author":null,"categories":"SOFAStack","content":"导语\nKusionStack 是面向 Kubernetes 云原生场景的 IaC 配置代码化实践的开源一站式可编程协议栈。其基本思想是让「应用方+平台方」的同学能够共同基于 IaC 构建的 Konfig 模型库同一平面进行 DevOps 协同工作。今天我们和大家分享一个好玩的 Go 代码城市应用，以及 KusionStack 是如何一键将其部署到 K8s 云原生环境的。\nKusionStack 项目主仓库：\nhttps://github.com/KusionStack/kusion\nPART. 1\n什么是代码城市（CodeCity）\nCodeCity 代码城市是瑞典工程师 Richard Wettel 开发的创意应用，可以通过类似数字城市的视觉形式展示和度量代码的复杂性。其效果如图：\n在 3D 形式展示的代码城市中的中心地标非常直观——最大、最高的建筑总是容易追踪的焦点。因为这个极具特色的创意，CodeCity 获得了 2008 年的\u0026amp;rdquo;Riconoscimento ated-ICT Ticino\u0026amp;rdquo; 一等奖，同时也可以免费用于非商业的科研和学习用途。\n今天要展示的 GoCity 是 Go 语言版本的代码城市，我们可以通过这种方式评估 KusionStack 等 Go 语言项目的代码复杂度。也可以通过在线的 GoCity 查看 KusionStack/kusion 仓库的展示效果。\nPART. 2\n本地执行 GO 代码城市\n之前的 GoCity 还是在 2021 年 10 月更新的，在最新的 Docker 和 Go1.18 环境有一些小问题，还好 KusionStack 相关同学为其提交了补丁进行了修复（_这也是开源项目的魅力所在，也希望开源社区小伙伴能够参与 KusionStack 的共建_），现在可以执行以下命令安装：go install github.com/rodrigo-brito/gocity@latest。然后通过 gocity open 打开 Github 或本地仓库。\n- 比如打开本地的 KusionStack/kusion 仓库\n- 然后浏览器打开对应页面\n本地执行一切正常！\nPART. 3\nGo 代码城市一键上云\n作为一个类似数字城市的应用，在云原生、元宇宙等背景下，部署上云也是一个自然的需求。同时我们也希望通过 GoCity 展示下 KusionStack 的基本用法。在 GoCity 上云之前，我们先尝试如何本地执行该应用。\n相应的容器镜像已经推送到 Docker Hubhttps://hub.docker.com/r/yuanhao1223/gocity，运行命令如下：\n运行成功后，可打开本地地址http://localhost:4000/查看 Go 项目的数字城市 3D 效果。\n容器化成功后，现在准备上云。从本地执行容器的方式可以看出，想要在 Kubernetes 部署，至少需要 Deployment 和 Service 两种资源。其中 Deployment 用来部署 Go 代码城市，Service 暴露端口，访问无状态应用。\n首先参考安装文档https://kusionstack.io/docs/user_docs/getting-started/install/安装好本地 Kusion 命令，然后通过 kusion init 的在线仓库提供了相应的模板。Kusion 命令支持一键初始化配置：\n输出类似以下信息：\n为了方便展示，Kusion 模板已经内置了 CodeCity 的例子。其中 code-city 模板依赖 konfig 大库中抽象化的前/后端模型，code-city 模板无依赖，可以自闭环。我们选择后者：\n初始化过程中，指定了容器镜像，并且容器端口和 Service 端口均为 4000，现在进入配置目录，目录结构如下：\n- 完整的代码可以参考 ：\nhttps://github.com/KusionStack/kusion-templates/tree/main/code-city-demo\n为了方便本地测试，可以通过 minikube start 本地启动 MiniKube 服务。然后命令行模式切换到 code-city-kcl 目录，然后执行 kusion apply 命令生效配置。到此，开始正式上云： kusion apply main.k\n输出类似于：\n检查 Deployment 的状态：\n输出类似于：\n使用 kubectl 端口转发：\n访问本地地址https://localhost:4000/)，点击 Example 处的链接 “KusionStack/kusion”，可以看到和本地执行一样的效果：\n至此，完成了 Go 代码城市的一键上云。有兴趣的读者，可以基于模型库 Konfig，选择其他模板，探索 KusionStack 支持的其它运维场景，下面我们将探索代码城市内部的原理。\nPART. 4\n认识数字城市中的建筑含义\n说实话代码城市第一眼看上去更像一个电路板，要理解其中的含义需要了解几个基本的参数映射关系，如预览页面的右下角图所示：\n以上的对应关系在其官方文档中也说明，如下图所示：\n其中地面的粉红色表示 Go 包对应的目录（_因为包的依赖关系可能再产生叠加_），灰色表示目录内部的文件，而蓝色表示结构体。其中表示文件的灰色建筑物的大小即文件的大小，表示结构体的蓝色建筑物的高度即方法的数量，建筑物的长宽表示结构体中属性的数量，蓝色颜色的深度表示相关代码行数。\n我们可以选择 DiffOptions 结构体对应建筑物查看其相关的属性参数：\n可以看到该结构体中有 15 个属性、3 个方法、共 156 行代码。通过点击其中的 “Github 链接” 按钮可以跳转到对应的位置：\n因此通过这种方式我们可以很容易查看全局有无特别高大的建筑，从而判断是否存在某些文件和结构体的代码需要改进。可以说 GoCity 是一个很有趣的代码分析工具，甚至可以集成到 Github PR 代码评审流程中。\nPART. 5\n分析 GoCity 的代码架构\nGoCity 代码架构主要分为代码数据提取和前端模型展示两块，如图所示：\n首先 Codebase 表示要展示的代码，通过 Git Service 被拉取，然后通过 Parser 和 Position 服务提取得到对应的参数信息，然后通过前端展示。Go 语言代码主要集中在模型数据提取部分，而前端展示主要为 JS 等实现。前端展示资源文件通过 embed.FS 内嵌到程序中，GoCity 命令启动 Web 服务展示页面。代码架构比较清晰，也是一个比较理想可用于 Go 语言学习的开源项目。\nPART. 6\n展望\n我们通过 KusionStack 的方式，配合少量的 KCL 配置代码，完成了 Go 代码城市一键上云的操作。虽然云上的 Go 代码城市和本地的版本看不出什么区别，但是云上程序的整个生命周期管理将大为不同。在后面的例子中我们将展示如何通过 KusionStack 结合 KCL 配置语言进行 IaC 方式的云原生应用的运维操作。感谢关注🙏\n参考链接\n● …","date":1661842800,"description":"Go 代码城市上云——KusionStack 实践","dir":"blog/go-code-city-cloud-kusionstack-practice/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"577810f0ec8cee7a80e6717647a67bbe","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","publishdate":"2022-08-30T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","summary":"导语 KusionStack 是面向 Kubernetes 云原生场景的 IaC 配置代码化实践的开源一站式可编程协议栈。其基本思想是让「应用方+平台方」的同学能够共同基于 IaC 构建的 Konfig 模型库同一平","tags":["SOFAStack"],"title":"Go 代码城市上云——KusionStack 实践","type":"blog","url":"/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","wordcount":2203},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. 孙春明 提问：\n 请问这个 mosnd 是做什么的？我如果想重新做 mosnio/proxyv2:v1.0.0-1.10.6 镜像，需要怎么处理呢？\n A：这个 mosnd 只是 mosn 的拷贝，可以看下这个文档：https://mosn.io/docs/user-guide/start/istio/#mosn-%E4%B8%8E-istio-%E7%9A%84-proxyv2-%E9%95%9C%E5%83%8F-build-%E6%96%B9%E6%B3%95\n「MOSN」：https://github.com/mosn/mosn\n2. 胡 提问：\n 请问这边有现成用 SOFAStack 搭建的框架包吗，内容涉及 SOFABoot、SOFARegistry、SOFARPC 的？\n A：现成的框架包的话，你可以从 SOFABoot 开始，参考这个：https://www.sofastack.tech/projects/sofa-boot/quick-start/\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n「SOFARegistry」： https://github.com/sofastack/sofa-registry\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nMOSN v1.1.0 版本发布\n发布 MOSN v1.1.0 版本，主要变更如下：\n 支持反向建连，云边互联场景，细节可以参考博客： https://mosn.io/blog/posts/mosn-tunnel/\n 支持自定义 xDS 解析扩展\n trace 支持 zipkin 扩展\n 优化创建 subset 负载均衡的算法，降低内存占用\n 详细发布报告：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md\n本周推荐阅读\nMOSN 构建 Subset 优化思路分享\nMOSN 1.0 发布，开启新架构演进\nMOSN 社区性能分析利器——Holmes 原理浅析\nMOSN 反向通道详解\n欢迎扫码关注\n","date":1661497200,"description":"SOFA Weekly | MOSN v1.1.0 版本发布、C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220826/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"60009aeca74279e2fb1f880466fa50dd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220826/","publishdate":"2022-08-26T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220826/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.1.0 版本发布、C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220826/","wordcount":951},{"author":null,"categories":"SOFAStack","content":"文｜史贵明（花名：莫城)\n蚂蚁集团技术专家\n蚂蚁集团多云配置管理系统技术负责人\n云原生基础设施领域，容器服务、配置管理、IaC、PaC、GitOps 等方向\n本文 2369 字 阅读 7 分钟\n背景\n要讲 Kusion 在蚂蚁集团的实践，我们首先来了解下蚂蚁集团在此之前的配置管理状况。\n如上图所示，图中展示的是在结合 Kusion 之前的应用基线配置管理系统。这里提到的 “应用基线配置” 非应用动态开关，而是注入应用依赖的软件版本、中间件配置、网络数据库等基础设施配置。\n从上图可以看到，应用基线管理系统是标准 BS 架构，对用户提供 Console 和 API，历经 6、7 年发展历史，承担起蚂蚁集团历史上绝大多数应用基线配置需求，功能丰富且拥有极其复杂的配置计算能力。目前已经支撑了 15000+ 应用、近 400 项应用配置、50+ 全局配置。\n在这个架构下，最上层用户通过表单或者集成系统 API 来与系统交互，以 RDBMS 为存储介质，将应用的配置以类 Key-Value 形式存储。能力层主要包含通用的角色管理、认证鉴权、版本与配置审计等通用能力，还提供模板化的方式来计算应用配置，如将 Deployment 模板化，最终将用户的基线配置渲染为 Deployment，同时模板与基线配置都存在非常复杂而又灵活的继承能力，举个例子，可以给应用配置 Zone_（逻辑机房）_级别的基线，也可以配置环境级别的基线，或者应用级别的基线，前者可以继承后者，就像子类和父类的集成关系。\n除了应用本身的基线配置，同时也管理了全局配置，如全局的 DNS 配置、Load Balance、网路配置等等。这个架构非常经典，并且有效支持了历史上各种配置需求及各种 618、双 11 等场景，这些都是毋庸置疑的。但是随着蚂蚁集团云原生化进程的推进，上面的经典架构也逐渐出现一些瓶颈。 不知道大家对于这种架构的配置管理，或者架构有没有遇到这样的问题？我来举几个例子：\n● 灵活性： 业务越来越多，应用的基础设施配置也更加的灵活，各种定制化需求越来越多，原有架构主要解决标准应用的场景和通用场景；\n● 开放性： 基线系统的核心能力主要代码在 PaaS 同学这边负责，对于多种多样的需求需要内部排期支持，开放性不足，无法复用和沉淀强大的 SRE 团队的经验；\n● 透明性： 配置计算黑盒，很多配置的计算逻辑都 hardcoding 在代码中，一个配置的变更最终会影响什么、影响有多大无法确定。比如修改了全局 sidecar 版本，导致线上应用批量异常。\n业界对标\n带着上面这些问题，我们在业界做了一些对标和学习:\n1.在 Google的《The Site Reliability Workbook》这本书中，Google 同学从自身的实践中总结出一些常见问题，其中非常重要的一点是：在做配置管理过程中，没有意识到，大规模配置管理问题的本质是编程语言问题。配置需求的声明、校验都可以通过语言来解决。\n2.从 Google 自身的实践来讲，K8s 是基于 Google 多年大规模集群管理经验贡献的开源产品，但是其内部主要使用的是 Borg，Borg 团队是在 Borg master 之上研发的，Borg 接入的三件套分别是：\n● BCL： 用户通过编写 BCL 代码实现对基础设施需要的配置；\n● Borgcfg： 通过 Borgcfg 将配置执行到 Borg 集群；\n● Webconsole： 通过 Webconsole 查看发布情况。\n经过调研，我们了解到 Google 大量的运维能力、产品、质量生态都是基于上述三件套演进多年。\n基于上述的一些总结，我们推演出类 Borg 的思路来解决蚂蚁集团的基础设施配置管理，我们尝试用语言和工具及服务实现蚂蚁集团下一代配置管理架构。\n下一代配置管理架构\n在这个新的架构下，我们可以看到整体架构不仅仅是一个简单的 BS 架构，配置的用户界面也从浏览器 Form 表单演进为中央开放配置大库。而配置大库所使用的就是 Kusion，Kusion 的用户使用前面的同学已经讲过了，对于配置大库本身的技术细节我不做过多的展开，这里强调的是大库在设计上支持多站点交付的架构。\n新配置管理架构主要分为以下几个特点：\n● 基于配置代码化理念抽象建设统一的应用配置模型，沉淀可重用模型组件，实现配置代码一次编写多站点可迁移。抽象领域模型：Stack 是配置的最小集合，Project 是一组 Stack 的抽象，不仅囊括 App 的应用基线配置, 也支持其他如 DataBase 配置、负载均衡配置，甚至 Network Policy 等非应用配置。\n● 通过策略控制器机制，创建与组织独特的安全性，合规性和治理要求相对应的防护规则。\n● 声明式自动化，持续监控运行状态并确保符合 Git 中定义的期望状态。\n应用发布案例\n接下来结合一个具体产品案例做阐述，在这个案例中以应用迭代发布为例：\n1.用户在业务迭代中，修改业务代码、提交代码、CI 测试、构建镜像，并将构建的镜像推送到远程镜像中心。然后通过配置管理服务层——这里是 auto-image-updater 组件——自动将配置更新到配置大库对应的配置文件中。\n2.触发大库的变更扫描、测试、审核等一些列的质保手段，同时触发一次应用发布流程，应用发布流程是具有风险体系的、可视化的发布流程，包括推进流程要从预发、仿真、灰度逐步推进，最后进入生产环境。\n在每个推进阶段，需要从配置大库获取到配置代码并同时使用配置管理服务层获取 KCL 的编译结果，也就是 Spec 模型，然后通过产品化方式将 Spec 与生产环境中真实的 Runtime 进行“Live Diff”以供参与人更好地识别变更内容和变更范围，然后以分组发布等具有风险防控的手段变更到对应环境，如 apply 到 K8s 集群。\n3.我们看下过程中的具体可视化产品，可以看到发布进度、应用配置的 Diff，以及可以看到历史版本的配置。\n问题与展望\n回顾下我们开始提到的几个问题：\n1. 灵活性： 即对各种灵活定制化需求的支持;\n2. 开放性： 通过 KCL 语言及开放配置大库，用户的基础设施配置通过新的用户界面即可自主完成，不需要等待配置管理平台开发人员进行开发；\n3. 透明性： 变更过程可以通过产品化的“Live Diff”来识别变更风险；\n我们通过上述的一些探索，一定程度上解决了蚂蚁集团在推进云原生进程中的问题，过程中也遇到了方方面面的困难，比如如何从老架构切换到新架构？架构代际演进时新老系统并存问题是必须要解决的，可以通过如双写等方式解决。在新架构下更值得探讨的有如下问题，全局配置如何管理以及如何更好的扩展配置的维度。\n站点的全局配置，在老的基线配置的全局配置不仅仅是简单的 Key-Value， 在使用上是非常复杂的，比如 DNSConfig 配置，按照租户、环境、Zone 等做了不同的优先级编排，对于这些的描述比较复杂，使用 KCL 描述如此复杂的配置很困难。\n针对于配置的继承和扩展，以 APP 基线配置为例，目前更多的是支持应用和应用环境级别的配置，针对 Zone 等细粒度的配置需要在 KCL 代码中通过写 if else 来实现，这对 …","date":1661238000,"description":"KusionStack 在蚂蚁集团的探索实践 (上)","dir":"blog/kusionstack-in-practice-at-ant-group-first/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8bfaea9639af72bb640f142108de2d90","permalink":"https://sofastack.github.io/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","publishdate":"2022-08-23T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","summary":"文｜史贵明（花名：莫城) 蚂蚁集团技术专家 蚂蚁集团多云配置管理系统技术负责人 云原生基础设施领域，容器服务、配置管理、IaC、PaC、GitOp","tags":["SOFAStack"],"title":"KusionStack 在蚂蚁集团的探索实践 (上)","type":"blog","url":"/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","wordcount":2774},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 卿同学 提问：\n 想咨询一下，目前蚂蚁内部使用 MOSN 外有使用到 Envoy 吗？\n A：目前蚂蚁的东西向网关是 MOSN on Envoy 的，Layotto on Envoy 也在试点中，所以没有直接使用 Envoy，不过很多场景是跑在 Envoy 上的。\n 那在 RPC、MQ、DB 流量这块都走 MOSN 流量拦截的方式吗？还是基于 Layotto API 的方式呢？\n A：目前主要是 MOSN，多语言和多云场景在走 Layotto 的方式。\n 我看 Layotto 也在推动和 Envoy 的融合，这一块现在有进展吗？\n A：今年我们首先会开源 Envoy 的 cgo 插件，然后基于这个插件，可以把 Layotto 跑在 Envoy 上。\n「MOSN」：https://github.com/mosn/mosn\n「Layotto」：https://github.com/mosn/layotto\n2. 古寒 提问：\n 咨询下， MOSN 部署有指导文档嘛？\n A：有的，看下这个文档，https://mosn.io/docs/user-guide/start/proxy/\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 社区文章｜MOSN 构建 Subset 优化思路分享\n如何看待 Dapr、Layotto 这种多运行时架构\nMOSN 文档使用指南\nMOSN 社区性能分析利器——Holmes 原理浅析\n欢迎扫码关注：\n","date":1660892400,"description":"SOFA Weekly | C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220819/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"187a873747e511ae312c36058eb71f8c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220819/","publishdate":"2022-08-19T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220819/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220819/","wordcount":758},{"author":null,"categories":"SOFAStack","content":" 文｜\n赵新（花名：于雨)：蚂蚁集团 Seata 项目开源负责人、开放原子开源基金会代码贡献之星\n郭成（花名：星北)：Seata-php 项目共同发起人、蚂蚁集团技术专家\n刘岳健：Seata-php 项目共同发起人、Hyperf 开发组成员、广东快客电子商务有限公司高级后端工程师\n本文 5894 字 阅读 12 分钟\n导语 通俗地讲，seata-php 是 Seata 的 PHP 语言实现，它实现了 Java 和 PHP 之间的互通，让 PHPer 也能使用 seata-php 来实现分布式事务。\nSeata 是一个非常成熟的分布式事务框架，在 Java 领域是事实上的分布式事务技术标准平台。Seata 目前正在构建其多语言体系[1]，整个体系包含了目前常用的五大类语言：Java、Go、Python、JS 和 PHP。目前的态势是后四种语言都依据 Seata Java 版本构建起对应语言的实现。\n除了追求 Seata 多语言体系过程中因为开源价值要求构建 Seata 的 PHP 版本这个原因外，作为构建起 Web 1.0 时代技术基础 LAMP 架构中的要角，PHP 语言在电商和金融交易场景下依然被广泛使用。而这些场景对数据一致性要求非常强烈，这是构建 seata-php 最大的诱因，也是其技术价值所在。\nPART. 1\u0026amp;ndash;Seata 架构与多语言体系 图片来自 Seata 官网\n Seata 总体架构由如下角色构成：\n- 事务协调器 Transaction Coordinator\n简称 TC，维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n- 事务管理器 Transaction Manager\n简称 TM，定义全局事务的范围，提交或者回滚全局事务。\n- 资源管理器 Resource Manager\n简称 RM，和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\n从 C/S 通信架构角度来看，TC 是服务端，TM 和 RM 是客户端。TC 与 TM 以及各个 RM 之间使用 Netty 框架进行长链接通信。具体而言，Seata Java 版本的通信协议是在四层 TCP 协议之上又定义了一套私有的二进制双向通信协议，通信框架使用了 Netty。其他四种语言只要依据 Seata 的通信协议标准实现其通信功能，即可在多语言生态体系内任何语言之间进行通信和服务调用。\n三个角色中，TM 和 RM 以 SDK API 形式供上层 APP 调用，而 TC 是独立进程部署，使用任何语言实现都可以。据说懒惰是程序员的第一美德，在 Seata Java 已经实现了 Java 版本的 TC 的情况下，多语言体系内其他语言就没必要再做重复工作，只需要构建其对应语言的 TM 和 RM 的 SDK API 包，与 Seata Java TC 通信即可。\nPART. 2\u0026amp;ndash;Seata 与 PHP 技术 分布式事务技术是微服务技术体系的一环，构建 Seata PHP 首先需要选择其微服务技术平台，seata-php 目前使用的微服务框架是 Hyperf。\nPHP 在业界以入门门槛低著称，目前常用的微服务框架有 Laravel 以及在其上构建的 Lumen。Laravel 框架的最大优点就是其生态丰富，各种组件应有尽有，如果 Laravel 可以和 Spring 框架类比，Lumen 就是 Spring Boot。但其缺点是性能堪忧，例如在普通的 8C 机器上，空跑一个只运行 echo 逻辑的 HTTP 服务，其吞吐量仅有 1K QPS。\nHyperf 框架是近年内出现的由国人基于 Swoole 开发的一个微服务框架，特点如下：\n1. 类似于 Nginx，Hyperf 以多进程形式常驻内存，每个进程内都有一个弹性线程池。正常情况下 Hyperf 收到调用请求后，可以保证 1ms 之内分配服务线程，而 Lumen 的响应时间常在 10ms 左右；\n2. 因为 Hyperf 服务常驻内存的特点，其稳定性好，资源利用率当然比以 CGI 机制运行的 Lumen 低很多；\n3. Hyperf 的对请求的处理过程借鉴了 Go 语言机制，其 runtime 层面以异步方式执行上层的用户同步调用，相比 Lumen 其吞吐率高而延迟低。例如在同样环境下使用 Hyperf 实现同样的 echo HTTP 服务，可以轻松达到 60K QPS；\n除了 Hyperf 自身稳定性与高性能外，依赖于 Hyperf 服务进程常驻内存的特点，TC 可以很方便的对seata-php 的 RM 发起二阶段事务处理，即作为 Server 的 Java TC 对作为 Client 的 PHP 版本的 RM 发起 RPC 回调。如果使用 Lumen 作为 seata-php 的微服务框架，几乎不可能实现这个技术点。\nPART. 3\u0026amp;ndash;快速入门 seata-php 基于 Hyperf 微服务框架，seata-php 已经实现了 AT 事务模式，并给出了测试用例。本章节的目的是基于现有实现，让对 seata-php 这个项目感兴趣的同学能够快速入门 seata-php。\n3.1\u0026amp;ndash;搭建 PHP 开发环境 使用 Hyperf/Box 这个工具能够快速创建开发环境，并且能够与其他自建开发工具链隔离，避免污染日常的开发环境。\n3.1.1 下载 Hyperf/Box # Mac wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_x86_64_macos -O box # Linux x86_64 wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_x86_64_linux -O box # Linux aarch64 wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_aarch64_linux -O box sudo mv ./box /usr/local/bin/box sudo chmod +x /usr/local/bin/box # 在 https://github.com/settings/tokens/new 创建 token 后，配置到 box 中 box config set github.access-token \u0026amp;lt;Your Token\u0026amp;gt; 注意：\n- 如果你是 Mac 用户首次使用的话，需要在“系统偏好设置”\u0026amp;ndash;\u0026amp;gt;“安全性与隐私”中给 Box 工具进行授权；\n- 已经测试过，X86 的 Box，可以在 M1 版本的 Mac 上使用；\n- 使用 Box 时，创建 GitHub access token 权限需要 repo、workflow。\n3.1.2 配置 PHP 环境 当 Box 下载好后，继续下载 PHP 8.0 版本\n# 下载 php8.0 box get …","date":1660633200,"description":"让 PHPer 也能使用 seata-php 来实现分布式事务","dir":"blog/seata-php-semi-annual-planning/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ee9381666d88165cad305e1b3880d181","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-php-semi-annual-planning/","publishdate":"2022-08-16T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/seata-php-semi-annual-planning/","summary":"文｜ 赵新（花名：于雨)：蚂蚁集团 Seata 项目开源负责人、开放原子开源基金会代码贡献之星 郭成（花名：星北)：Seata-php 项目共同发起人、蚂蚁集","tags":["SOFAStack"],"title":"Seata-php 半年规划","type":"blog","url":"/sofastack.tech/blog/seata-php-semi-annual-planning/","wordcount":4330},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup 合肥站-云原生技术沙龙\n 活动时间：2022 年 08 月 13 日（周六）13:30-17:00\n 活动地点：合肥市高新区创新创业园 D8 栋一楼集思空间\n 活动形式：线下活动\n 资料下载：\n《SOFA Serverless 体系助力业务极速研发》\n《KusionStack 在蚂蚁规模化运维的探索和总结》\n 本次分享涉及的项目地址：\n【SOFAArk】https://github.com/sofastack/sofa-ark\n【KusionStack】https://github.com/kusionstack/kusion\n 活动介绍 活动议程 直播回放 SOFA Serverless 体系助力业务极速研发\nKusionStack 在蚂蚁规模化运维的探索和总结\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1660374000,"description":"SOFA Meetup 合肥站-云原生技术沙龙","dir":"activities/sofa-meetup-17/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"717c5211a439598278a7cbb834d09bb0","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-17/","publishdate":"2022-08-13T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-17/","summary":"概要 活动主题：SOFA Meetup 合肥站-云原生技术沙龙 活动时间：2022 年 08 月 13 日（周六）13:30-17:00 活动地点：合肥市高新区创新创业园 D8 栋","tags":["SOFAMeetup"],"title":"SOFA Meetup 合肥站-云原生技术沙龙","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-17/","wordcount":346},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 信广健 提问：\n 经过十分曲折的故事了解到了 Layotto ， 进群后想看看后续发展，有什么好的文档可以学习下吗？\n A：目前还在活跃开发中，可以看下 https://github.com/mosn/layotto 了解下，相关的文档也在 https://mosn.io/layotto/\n「Layotto」：https://github.com/mosn/layotto\n2. 清源 提问：\n 现在 MOSN 除了适配 XDS 做到动态规则下发之外？有没有其他的动态规则下发办法？\n A：你可以自己实现的，XDS 也是调用 MOSN 的更新 API。\n「MOSN」：https://github.com/mosn/mosn\n3. 樊志超 提问：\n 问一下，MOSN 与业务容器间的信息交互是采用 socket 方式吗？\n A：这个看你怎么用了，自己选择。\n 默认的是哪种方式呢？\n A：TCP、UDS 都可以。\n「MOSN」：https://github.com/mosn/mosn\nSOFARPC 5.8.6 版本发布 SOFARPC 5.8.6 是一个功能优化、Bug 修复版本，建议使用 5.7.10 ~ 5.8.5 版本的用户都升级到 5.8.6。\n主要变更如下：\n- 功能优化：\n1.支持用户自定义 tracer 中 callerAppName\n2.添加 DomainRegistry 订阅域名数据, 支持 direct url 功能\n- BUG 修复：\n1.修复了 Triple 协议在多 classLoader 环境下的序列化问题\n详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.8.6\n本周推荐阅读 蚂蚁开源：开放自研核心基础软件技术，携手探索技术高地\n\nGo 原生插件使用问题全解析\n\nMOSN 反向通道详解\n\n如何看待 Dapr、Layotto 这种多运行时架构\n\n欢迎扫码关注：\n","date":1660287600,"description":"SOFA Weekly | SOFARPC 5.8.6 版本发布、Meetup 合肥站、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220812/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"06f5bddaf802462077c913d20d2f9d15","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220812/","publishdate":"2022-08-12T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220812/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 5.8.6 版本发布、Meetup 合肥站、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220812/","wordcount":861},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup 广州站-云原生技术交流\n 活动时间：2022 年 08 月 06 日（周六）14:00-18:00\n 活动地点：广州市海珠区阅江西路 88 号阿里中心北塔 4F 万松书院\n 活动形式：线下活动\n 资料下载：\n《基于 P2P 的文件和镜像加速系统 Dragonfly》\n《Buildpacks \u0026amp;amp; Argo CD GitOps》\n《KusionStack 实践探秘｜技术、角色与应用场景篇》\n《KubeSphere 在青花瓷的落地实践与展望》\n《Holmes｜Go 应用性能异常诊断定位利器》\n《云原生应用灾备最佳实践》\n 本次分享涉及的项目地址：\n【Dragonfly】https://github.com/dragonflyoss\n【KusionStack】https://github.com/kusionstack/kusion\n【MOSN】https://github.com/mosn/mosn\n 活动介绍 活动议程 直播回放 Dragonfly：基于 P2P 的文件和镜像加速系统\nKusionStack 实践探秘｜技术、角色与应用场景篇\nHolmes｜Go 应用性能异常诊断定位利器\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1659769200,"description":"SOFA Meetup 广州站-云原生技术交流","dir":"activities/sofa-meetup-16/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cc936d9167acee9569070c076ab0da31","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-16/","publishdate":"2022-08-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-meetup-16/","summary":"概要 活动主题：SOFA Meetup 广州站-云原生技术交流 活动时间：2022 年 08 月 06 日（周六）14:00-18:00 活动地点：广州市海珠区阅江西路 88 号阿","tags":["SOFAMeetup"],"title":"SOFA Meetup 广州站-云原生技术交流","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-16/","wordcount":504},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 吴宇奇 提问：\n 请问下，Bolt 协议里面的这个 cmdCode，除了心跳、request、response，还有别的用法吗？ A：举个例子，新增 goaway 扩展。https://github.com/sofastack/sofa-bolt/issues/278\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\n2. bobtthp 提问：\n 大佬们问下动态路由这块，有 example 可以看看嘛？ A：这篇文章就是例子哟，https://mosn.io/blog/posts/how-use-dynamic-metadata/#%E5%8A%A8%E6%80%81%E8%B7%AF%E7%94%B1-cluster ，原理就是 route 的配置是变量，然后 streamfilter 根据业务逻辑修改这个变量的值，很方便试试。\n 好的，这个我有一个疑问。这个变量如何注入进去呢？我理解应该每一个节点的变量都不一样嘛？还有一个疑问是，如果需要和配置中心交互这块是怎么做的，可以借鉴一下吗？\n A：变量就是 streamfilter 模块分配的，然后他来设置这个变量的值，值就是 cluster 的名字；后面那个问题指的是 cluster host 的更新吗？\n 指的是如果需要外部的配置中心那可能需要监听配置的动态变化；第一个这块我好像没理解好，我举个例子：如果是多个应用，那是不是我要设置多个变量？\n A：比如你 A 应用的 cluster 名字是 A，B 应用的 cluster 名字是 B， 那么这个变量只需要一个，只是 value 你可以根据逻辑设置为 A 或者 B。\n这个就是一些复杂的路由场景，用配置不能表达，就可以用代码的方式来做这个事。我们内部的一些复杂路由场景也是这样做的。\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 云原生 Meetup 广州站，等你来！\n\nGo 原生插件使用问题全解析\n\nMOSN 反向通道详解\n\nKusionStack｜Kusion 模型库和工具链的探索实践\n\n欢迎扫码关注公众号：\n","date":1659682800,"description":"SOFA Weekly | Meetup 广州站参会指南、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220805/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"51544dab85fa7fe78001737602f2536b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220805/","publishdate":"2022-08-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220805/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Meetup 广州站参会指南、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220805/","wordcount":1038},{"author":null,"categories":"SOFAStack","content":" 文｜郑泽超（GitHub ID：CodingSinger )\n字节跳动高级工程师\n热衷于微服务和 ServiceMesh 开源社区\n本文 6802 字，阅读 15 分钟\nPart.1\u0026amp;ndash;贡献者前言 说起来非常的抓马，当时和 MOSN 的相遇是在给于雨负责的开源项目 Dubbo-go 贡献代码那阵。在自己顺利当上了 Dubbo 开源社区的 Committer 之后，心想着能更深入的学习 Golang 语言，机缘巧合之下碰到了 MOSN 的老大哥烈元 （也是元总领我进了 MOSN 社区的大门） 。\n作为一款目标对齐 Envoy 的高性能可扩展安全网络代理，MOSN 支持的生态能力更贴近国内互联网公司的技术栈，并且对新功能的响应也很迅速。其次 MOSN 有着很多值得借鉴的巧妙设计和进阶的使用技巧，能充分满足自己在工作之外深入学习 Golang 语言的诉求。\n目前，我在社区里陆续参与了 EDF Scheduler、LAR、WRR 负载均衡、DSL 路由能力、UDS Listener、Plugin 模式的 Filter 扩展以及反向通道等一些比较大的 feature 能力建设。再次感谢雨哥、元总、鹏总、毅松等社区内一众大佬们帮我考究方案并且帮我 Review 代码。\n本文主要介绍之前新合入 master 分支的「反向通道」的使用场景和设计原理，欢迎大家留言探讨。\nMOSN 项目概述 MOSN（Modular Open Smart Network）是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并经过双 11 大促几十万容器的生产级验证，具备高性能、易扩展的特点。MOSN 可以和 Istio 集成构建 Service Mesh，也可以作为独立的四、七层负载均衡、API Gateway、云原生 Ingress 等使用。\nPart.2\u0026amp;ndash;MOSN 的反向通道实现 在云边协同的网络场景，通常都是单向网络，云侧节点无法主动发起连接与边缘节点通讯。这种限制虽然在极大程度上保证了边缘节点的安全，但缺点也很明显，即只允许边缘节点主动发起访问云端节点。\n云边隧道旨在解决云端无法主动访问边缘节点的问题，其本质是一个反向通道 （后文统称为反向通道） 。通过在边缘侧主动发起建连的方式与云端节点之间构建一条专用的全双工连接，用来传输云端节点的请求数据和回传最终的响应结果。\n目前例如 SuperEdge、Yurttunnel 等业界知名云边协同开源框架，对于云边通信的实现方案都是基于反向通道。\n本文将着重介绍 MOSN 之上的反向通道运作流程和原理。总体架构如下所示 (图中箭头表示 TCP 建连反向) ：\n整个运作流程可以简单概括为：\n1. 边缘侧的 MOSN 实例 （后文统称为 Tunnel Agent） 在启动时 Tunnel Agent 相关服务协程。\n2. 通过指定的静态配置或者动态服务发现方式拿到需要反向建连的公有云侧的 MOSN Server 地址列表 （后文统称 Tunnel Server ） ，并且建立反向连接。\n3. 云侧的 Frontend 与 Tunnel Server 侧的转发端口进行数据交互，这部分数据会被托管到之前建立的反向连接进行发送。\n4. 边缘节点接受到请求之后，再将请求转发给实际的后端目标节点，回包过程则远路返回。\nPart.3\u0026amp;ndash;反向通道启动过程 MOSN Agent 通过 ExtendConfig 特性，在 MOSN 启动时加载和完成初始化 Tunnel Agent 的工作。\nExtendConfig 中定义 AgentBootstrapConfig 结构如下：\ntype AgentBootstrapConfig struct { Enable bool `json:\u0026amp;quot;enable\u0026amp;quot;` // The number of connections established between the agent and each server ConnectionNum int `json:\u0026amp;quot;connection_num\u0026amp;quot;` // The cluster of remote server Cluster string `json:\u0026amp;quot;cluster\u0026amp;quot;` // After the connection is established, the data transmission is processed by this listener HostingListener string `json:\u0026amp;quot;hosting_listener\u0026amp;quot;` // Static remote server list StaticServerList []string `json:\u0026amp;quot;server_list\u0026amp;quot;` // DynamicServerListConfig is used to specify dynamic server configuration DynamicServerListConfig struct { DynamicServerLister string `json:\u0026amp;quot;dynamic_server_lister\u0026amp;quot;` } // ConnectRetryTimes ConnectRetryTimes int `json:\u0026amp;quot;connect_retry_times\u0026amp;quot;` // ReconnectBaseDuration ReconnectBaseDurationMs int `json:\u0026amp;quot;reconnect_base_duration_ms\u0026amp;quot;` // ConnectTimeoutDurationMs specifies the timeout for establishing a connection and initializing the agent ConnectTimeoutDurationMs int `json:\u0026amp;quot;connect_timeout_duration_ms\u0026amp;quot;` CredentialPolicy string `json:\u0026amp;quot;credential_policy\u0026amp;quot;` // GracefulCloseMaxWaitDurationMs specifies the maximum waiting time to close conn gracefully GracefulCloseMaxWaitDurationMs int `json:\u0026amp;quot;graceful_close_max_wait_duration_ms\u0026amp;quot;` TLSContext *v2.TLSConfig `json:\u0026amp;quot;tls_context\u0026amp;quot;` } - ConnectionNum：Tunnel Agent 和每个 Tunnel Server 建立的物理连接数量。\n- HostingListener：指定 Agent 建立连接之后托管的 MOSN …","date":1659423600,"description":"本文主要介绍之前新合入 master 分支的「反向通道」的使用场景和设计原理，欢迎大家留言探讨。","dir":"blog/mosn-reverse-channel-explained/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7e5e0314310caad88df4a18ccf8bb436","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-reverse-channel-explained/","publishdate":"2022-08-02T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-reverse-channel-explained/","summary":"文｜郑泽超（GitHub ID：CodingSinger ) 字节跳动高级工程师 热衷于微服务和 ServiceMesh 开源社区 本文 6802 字，阅读 15 分钟 Part.1\u0026ndas","tags":["SOFAStack"],"title":"MOSN 反向通道详解","type":"blog","url":"/sofastack.tech/blog/mosn-reverse-channel-explained/","wordcount":3101},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. bobtthp 提问：\n 请教下 MOSN 转发 HTTP/2 协议，listener filter 和 router match 两个部分要怎么写呀？\n A：就用这个 exmple 就行了。\nhttps://github.com/mosn/mosn/blob/master/configs/mosn_config_dev.json\n「MOSN」：https://github.com/mosn/mosn\n2. 黄大宇 提问：\n Biz 版本更新时，如果不卸载旧版本，安装新版本时会报 webContextPath 冲突异常。比如现在运行 1.0.0，而我要升级到 2.0.0，那么能否先安装 2.0.0，然后再切换，再把 1.0.0 卸载。目前是这一过程出现了 webContextPath 冲突的问题。\n A：有两种解法，一种是让流量走宿主，然后分发给 Biz。另一种是 context path 挂钩版本，调用时带上版本，类似 v1，v2 这样。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n3. 黄润良 提问：\n Cluster Manager 这块配置，如果要实现动态配置，有没有什么最佳实践之类的？MOSN 有开放 API 或者接入配置中心的案例吗？\n A：直接使用 XDS 协议就行了，获取你也可以直接调用 MOSN 的 API，这里有个 ZK 的例子：\nhttps://github.com/mosn/mosn/tree/master/pkg/upstream/servicediscovery/dubbod\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 Go 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\nSOFAServerless 助力业务极速研发\n\nSeata 在蚂蚁国际银行业务落地实践\n\n欢迎扫码关注公众号：\n","date":1659078000,"description":"SOFA Weekly | Meetup 广州站、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220729/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"876d0f78f149dc93f464e53e5474a250","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220729/","publishdate":"2022-07-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220729/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Meetup 广州站、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220729/","wordcount":760},{"author":null,"categories":"SOFAStack","content":" 文｜杨洋（花名：凯申 )\n铜锁开源密码库创始人、蚂蚁集团高级技术专家\n本文 2816 字，阅读 8 分钟\n再见 BabaSSL ，你好 Tongsuo!\n BabaSSL 这个名字由于其历史上的若干特殊原因，导致了其看起来是主要 SSL/TLS 协议的密码学产品，这其实并不符合整个产品的功能特性，名字本身也不够中立，这会让用户产生一定程度的误解。\n目前 BabaSSL 在积极推进向开放原子开源基金会的捐赠行动，并结合社区未来发展的方向，现决定对 BabaSSL 项目进行更名。新名字需要更加中立化，而且需要体现项目的功能特性。基于这些考虑，计划取新名字为：铜锁，对应拉丁字母名称为铜锁的汉语拼音“Tongsuo”。铜锁是在中华文明 5000 年历史的进程中得到了广泛应用的安全设施，且小巧、设计精妙，极具中国传统特色，符合密码库的产品特色和发展目标。\n 一、BabaSSL 从何而来，为何而改？ BabaSSL 于 2019 年诞生在蚂蚁和阿里集团内部，是基于 OpenSSL 1.1.1 版本 fork 而来的一个变种版本。创建 BabaSSL 项目的动机是在蚂蚁和阿里内部得到一个统一的 OpenSSL 变种版本，以便使用此统一版本来支撑蚂蚁和阿里内部的各种业务。这样可以减小各个业务方维护 OpenSSL 的成本，实现密码学能力的统一管理和维护，进而降低潜在的安全风险。\n针对蚂蚁和阿里内部的业务特点，BabaSSL 需要采用和 OpenSSL 完全不同的发展路线。简单来说，BabaSSL 需要覆盖的场景非常的多样化，包括移动端、服务器端、资源受限的嵌入式环境等。而且在算法和密码学特性的支持上，蚂蚁和阿里的业务对前沿的技术存在较大需求，因此要求 BabaSSL 需要采用相对激进的演进策略，但还要确保很高的质量标准以应对蚂蚁和阿里的业务规模。所以我们当年使用 Brisk and Better Assured Cryptography and SSL/TLS toolkit 来命名这个密码学基础库，并缩写为 BabaSSL。\n随着 BabaSSL 项目的发展，我们发现除了蚂蚁和阿里内部的业务对其有着重大的依赖之外，业界也对国密合规和前沿密码学技术存在较大需求。因此在 2020 年 10 月份，我们将 BabaSSL 进行了开源，并维持 BabaSSL 名称不变。随着 BabaSSL 开源社区的发展、用户数量的增多，我们逐渐发现 BabaSSL 这个名称已经无法继续肩负整个社区更大的目标和使命，因此取一个新名字就十分必要。\n二、我的新名字——\u0026amp;rdquo;铜锁/Tongsuo\u0026amp;rdquo; 经过与开源社区小伙伴们共同探讨，并与开放原子开源基金会沟通后，我们最终选定了 “铜锁/Tongsuo” 作为 BabaSSL 开源项目的新名字，其含义如下：\n1. 铜锁的设计形象和密码学的锁形象异曲同工，都是保障安全的技术\n2. 铜锁的历史悠久，应用十分广泛\n3. 铜锁诞生于中国汉代，流行至明清，极具中国特色，代表了中国的传统文化\n4. 铜锁设计精妙、体积小巧，安全性高\n铜锁的这些特点，符合 BabaSSL 的项目定位和发展目标：适应场景最广、性能最好、可靠性最高且监管合规的开源密码学基础库。正如铜锁是中国 5000 年历史长河中为人民生命财产提供保证的最基础元素，“铜锁密码库”作为信息安全领域基础组件、中国网络空间安全和数据安全的核心基础元素，也希望能为中国人民的信息和财产安全贡献力量。\n铜锁的拉丁字母名称则直接采用铜锁的汉语拼音：Tongsuo，除此之外不再赋予其他含义解释，目的是集中体现中国的品牌名称和文化价值。\n三、更名后的一系列操作 我们近期会针对 BabaSSL 开源项目进行如下的更名举措，其中部分举措可能会对用户造成影响，需额外注意：\n「代码库名称变更」\n1. 在 Github 上创建新的 Tongsuo 组织，并将 BabaSSL 代码仓库更名为 Tongsuo 后迁移其下；\n2. BabaSSL 代码仓库的转地址会在 Github 上自动跳转到新的 Tongsuo 仓库地址，方便已有用户访问；\n3. 新的 Tongsuo 代码仓库的 master 分支变更为基于 OpenSSL 3.0 代码基础，并整体迁移为 Apache License 2.0 开源许可证。由此进行相关分支变更如下：\na. 现有的 master 分支更名为 master-babassl，并设置为只读模式，即不再接受新的代码合并，只留做参考用；\nb. 将 master-tongsuo 分支更名为 master，作为下个大版本 tongsuo-8.4.0 的开发分支。由于新的 master 分支和旧的 master 分支之间没有代码提交的逻辑关系，因此需要用户手动重新检出新的master 分支并覆盖本地的旧 master 分支内容。在此过程中如果你的本地 master 分支存在代码修改，请注意保存以免代码修改丢失。\n「网站改名」\n1. 启动 tongsuo.net 网站，并更新网站内容/品牌；\n2. 将对 babassl.cn 网站的访问重定向到 tongsuo.net；\n3. 新增 tongsuo.readthedocs.org 网站，作为铜锁项目的文档库。\n「Release 改名和版本策略」\n1. 在 8.3.x 版本中将沿用 BabaSSL 名称，即 BabaSSL 8.3.1 等后续版本；\n2. 从 8.4.0 开始更名为 Tongsuo。Tongsuo 延续 BabaSSL 的版本编号，不再重新定义编号。主要是考虑软件版本的升级和比较的前后兼容性问题。新的 release 包名称为：tongsuo-a.b.c.tar.gz 或 tongsuo-a.b.c.zip。\n「代码 API 命名修改」\n需要考虑兼容问题，因此 BABASSL_ 开头的 API 还需持续保留，直到 9.0 大版本发布。\n四、期待与你共“铜”成长 经过这一年的努力，铜锁/Tongsuo 开源密码库项目通过了开放原子开源基金会的 TOC 答辩。接下来我们的重心是继续推进铜锁 8.4.0 版本的研发工作，该版本会在半同态加密算法等前沿密码学领域进行相关特性的大力支持，为铜锁的用户带来隐私计算领域的底层密码学原语能力。\n希望能有更多朋友参与进来，与我们共同去完善铜锁/Tongsuo，不论你所处哪一个研究领域，我们都非常期待和欢迎你的加入。此外，我们于近期建立了铜锁 （BabaSSL） 的开源项目钉钉群，方便铜锁密码库的用户们进行沟通交流，期待着能有更多的社区朋友在铜锁 （BabaSSL） 共同成长！\n钉钉用户交流群群号：44810299\n 铜锁（BabaSSL）的更名涉及到较多的现有资产名称变更事宜，例如代码库改名、文档内容名称替换等。具体的相关进展和状态，我们会及时在上述钉钉群中向大家通告。\n 了解更多…\n铜锁/Tongsuo Star 一下✨： https://github.com/BabaSSL/BabaSSL\n本周推荐阅读 BabaSSL：支持半同态加密算法 EC-ElGamal\n\nBabaSSL 发布 8.3.0｜ …","date":1659078000,"description":"再见 BabaSSL ，你好 Tongsuo!","dir":"blog/my-new-name-is-tongsuo/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b06ddb637930e9c54104c4e1f05501d7","permalink":"https://sofastack.github.io/sofastack.tech/blog/my-new-name-is-tongsuo/","publishdate":"2022-07-29T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/my-new-name-is-tongsuo/","summary":"文｜杨洋（花名：凯申 ) 铜锁开源密码库创始人、蚂蚁集团高级技术专家 本文 2816 字，阅读 8 分钟 再见 BabaSSL ，你好 Tongsuo! BabaSSL 这个名字由于其历史上的若干特殊原因，导致","tags":["SOFAStack"],"title":"你好，我的新名字叫“铜锁/Tongsuo”","type":"blog","url":"/sofastack.tech/blog/my-new-name-is-tongsuo/","wordcount":2336},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#29:基于 P2P 的文件和镜像加速系统 Dragonfly\n 活动时间：07 月 28 日，周四晚 19 点\n 活动形式：线上直播\n 直播回放：点击观看\n 资料下载：戳这里\n 推荐阅读：Dragonfly\u0026amp;ndash;基于 P2P 的文件和镜像分发系统\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”等多种形式期待你的参与！\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#29 基于 P2P 的文件和镜像加速系统 Dragonfly Dragonfly 是一款基于 P2P 的智能镜像和文件分发工具。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在应用分发、缓存分发、日志分发和镜像分发等领域被大规模使用。自 17 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 18 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为孵化级别的托管项目。分享主要介绍 Dragonfly 项目，并与大家共同分享开发过程中的设计思想以及最佳实践。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 戚文博（花名：百蓦）\n Dragonfly Maintainer\n 基于 P2P 的文件以及镜像加速系统, 负责 Scheduler 以及 Manager 子模块\n 马金晶（花名：楚贤）\n Dragonfly Maintainer\n 基于 P2P 的文件以及镜像加速系统, 负责 Dfdaemon 子模块\n 议程 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1658818800,"description":"2022 年 7 月 26 日 19：00 - 20：00 ，线上直播第 29 期。","dir":"activities/sofa-channel-29/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d3727242c6f0f12aead78985904e20bb","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-29/","publishdate":"2022-07-26T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-29/","summary":"概要 活动主题：SOFAChannel#29:基于 P2P 的文件和镜像加速系统 Dragonfly 活动时间：07 月 28 日，周四晚 19 点 活动形式：线上直播 直播回放：点击观看","tags":["SOFAChannel","Dragonfly","文件和镜像加速系统"],"title":"SOFAChannel#29 基于 P2P 的文件和镜像加速系统 Dragonfly","type":"activities","url":"/sofastack.tech/activities/sofa-channel-29/","wordcount":623},{"author":null,"categories":"SOFAStack","content":" 文｜李乔（花名：南桥)、李宗杰（花名：白鹰)\n李乔：蚂蚁集团高级开发工程师，负责蚂蚁境外银行支付结算系统开发\n李宗杰：蚂蚁集团技术专家，负责蚂蚁分布式事务中间件研发\n本文 11580 字 阅读 25 分钟\nPART. 1\u0026amp;ndash;背景 蚂蚁国际境外银行业务正在部分迁移至阿里云，原内部使用的 SOFA 技术栈无法在阿里云上得到支持。为了满足银行业务快速发展、简化银行系统技术栈的目标，我们采用了 Spring+Dubbo 等一套开源的技术方案重新构建起了新的技术栈。蚂蚁集团作为金融机构，内部应用采用了微服务架构，数据间的一致性极其重要，但蚂蚁内部原有的分布式事务框架，在阿里云上也无法提供技术支持。\nSeata 是分布式事务解决方案，囊括了阿里集团的 TXC （阿里云版本称为 GTS） 和蚂蚁集团的 TCC/SAGA 等多种模式，是一款经过多年双十一大规模流量验证的金融级分布式事务框架。因此在综合比较各个现有的分布式事务框架之后，我们选择了 Seata。\n本文介绍了蚂蚁集团境外银行技术部在国际站点建设过程中，使用开源的 Seata 1.4.2 版本进行分布式事务管理的详细方案。同时本文也介绍如何在客户端实现对事务悬挂、幂等、空提交以及空回滚等情形的处理方法。\nPART. 2\u0026amp;ndash;调研 Seata 经过四年建设后，已经形成了一个非常庞大的技术体系。但不管其如何演进，Seata 整体保持了架构的稳定性与使用接口的向后兼容性。\n2.1\u0026amp;ndash;Seata 架构 Seata 官网给出了其如下架构图：\n总体由如下角色构成：\n●TC: Transaction Coordinator\n事务协调器：维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n●TM: Transaction Manager\n事务管理器：定义全局事务的范围，提交或者回滚全局事务。\n●RM：Resource Manager\n资源管理器：和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\nTC 与 TM 以及各个 RM 之间使用 netty 框架进行长链接通信，通信协议是在四层 TCP 协议之上自定义的一套二进制双向通信协议，所以 Seata 总体的通信效率非常高。\n2.2\u0026amp;ndash;事务模式 在这套架构之上，Seata 提供了 TCC、AT、SAGA 和 XA 四种事务模式：\nTCC 模式\n参与者需要实现 Prepare/Commit/Rollback 接口，在一阶段实现数据资源的预处理，在二阶段实现提交和回滚逻辑完成两阶段的提交。优点是通过业务逻辑实现数据可见性和隔离性，快速释放本地事务，提高对同一个资源的并发度，缺点是引入了中间数据的预处理过程，增加了业务复杂度。因此 TCC 模式具有很好的性能与隔离性，尤其适合在银行金融场景下同一个账户的并发交易处理。\nAT 模式\n在一阶段时通过解析 SQL，生成二阶段回滚日志：二阶段提交时，删除回滚日志；二阶段回滚时，通过回滚日志来恢复记录到一阶段之前的状态。类似于 TCC 的两阶段，不过二阶段的 Commit/Rollback 由框架自动生成，自动实现了二阶段操作，易用性好于 TCC。但 AT 模式通过全局锁来实现数据的隔离性，因此对于同一个资源的事务处理只能串行操作，所以性能逊于 TCC。当然如果不存在并发使用同一个资源的场景，则 AT 模式可以很好的兼顾性能和隔离性，以及更好的开发效率。\nSAGA 模式\n是一种长事务解决方案，其一阶段正向服务和二阶段补偿服务都由业务开发实现，它在微服务编排领域有大量应用。但其数据隔离性不好，业务数据有被脏写的风险。\nXA 模式\n其使用接口与 AT 模式一致，提供了最严格的隔离性，可以保证了用户不会出现脏读。XA 模式的缺点是其事务范围较长，其性能较低。\n2.3\u0026amp;ndash;小结 Seata 四种模式都是二阶段事务的技术实现。结合 Seata 自身的技术架构，其事务模型总体有如下特点：\nPART. 3\u0026amp;ndash;实践 进行总体技术调研后，我们认为 Seata 的总体技术栈可以满足我们所有金融业务场景的需求。在实施过程中，在不同的业务场景下根据不同的技术需求进行了取舍，我们在发起者本地的交易流水部分使用了 AT 模式，在下游账户相关的服务中使用了 TCC 模式。本章接下来我们将以业务中最经典的账务余额模型为例详述本次实践，包括为了适配相应的事务模型所做的工作。\n3.1\u0026amp;ndash;交易流水使用 AT 模式 为了记录每次的交易流水状态，在发起每笔交易前，我们都要将本次交易流水做记录，交易状态流水简化模型如下：\n在接收到请求时，首先记录初始化状态的交易流水，然后发起分布式事务。本次交易的分布式事务执行成功后，预期该笔交易流水需要是执行成功状态。为了对失败的交易发起重试，我们启动了一个定时任务，定时扫描交易流水状态，扫描到一定时间后未完成的记录需要重新发起重试。\n从上面的场景可以看出，在发起者的交易流水记录的状态变更中，也需要参与到整个分布式事务中。分布式事务成功，则流水状态需要更新为成功，如果分布式事务失败，则需要更新为失败。同时交易流水记录之间是独立的，不存在并发操作的可能，只有异步任务的扫描才会和交易中的事务做抢锁处理。\n针对这个场景，就非常适合使用 AT 模式，无需通过业务代码记录事务执行状态，而是直接在发起者中通过 AT 模式提供的代理数据源执行修改流水状态为“执行成功”状态，由框架自动完成 AT 模式下的一二阶段的提交和回滚，保证交易流水状态和整体分布式事务的状态一致，同时可以保持简洁的代码和更高的开发效率。\n3.2\u0026amp;ndash;账户使用 TCC 模式 从业务原理上来分析，账户的余额是不能凭空增加或者减少的，每个余额变动必须有明细对应。所以账户余额模型应该具备以下几个关键要素：账户 （明确到底是谁的账户）、 余额 （承载的客户资产具体数值）、 账务明细 （记载账户余额变动的数值、时间和原因） 。这三个其实构成了最朴素的账户余额模型。\n根据从业务原理的分析，我们就产生了一个最简单的账户余额基础数据模型：\n账户（ip_account）\n账户模型确定了基本的账户信息：\n●账号：该账号与会员的信息映射在一起，作为会员的余额资产；\n●账户类型：对公 （商户账号） ，对私 （个人账号） ，平台户、营销户、商户待结算账户等类型；\n●余额：记录当前客户资产具体数据的余额；\n●交易状态：控制四种交易方式：流入、流出、充值、提现，这是在账务层做的一个资金安全兜底保障。每一种类型用 T/F 来表示是否可以进行此类交易，T 是可以，F 是不可以 ；\n●核算主体：用于表示当前账号在那个核算主体下面进行核算。\n账户明细（ip_account_log,ip_trans_log）\nip_trans_log 是指账户的交易明细，用于解释为什么这个账户是要发生这笔记账请求。可以理解为业务原始凭证，用于和业务系统数据关联校验。以你用支付宝在便利店买了一瓶矿泉水为例，就是记录的这花 2 元买水的原始信息。\nip_account_log 是指账务明细，用于解释这个账户到底扣减了多少钱，记账的对方账户是谁。仍然以你用支付宝在便利店 …","date":1658818800,"description":"蚂蚁国际境外银行业务正在部分迁移至阿里云，原内部使用的 SOFA 技术栈无法在阿里云上得到支持。为了满足银行业务快速发展、简化银行系统技术栈的目标，我们采用了 Spring+Dubbo 等一套开源的技术方案重新构建起了新的技术栈。","dir":"blog/seata-in-practice-in-ant-international-banking/","fuzzywordcount":9000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8c90a02142b9bb70cfc93d7828e502ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","publishdate":"2022-07-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","summary":"文｜李乔（花名：南桥)、李宗杰（花名：白鹰) 李乔：蚂蚁集团高级开发工程师，负责蚂蚁境外银行支付结算系统开发 李宗杰：蚂蚁集团技术专家，负责蚂蚁","tags":["SOFAStack"],"title":"Seata 在蚂蚁国际银行业务的落地实践","type":"blog","url":"/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","wordcount":8943},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 罗坤 提问：\n 您好，请问一下可以用 SOFATracer 的摘要日志是 result.code 判断交易是否成功来告警么？result.code 有哪些状态？\n A：是可以的，如果是监控，可以用 stat 日志。\n「SOFATracer」： https://github.com/sofastack/sofa-tracer\n2. xiaoyu 提问：\n 咨询一个问题，现在使用 MOSN 作为 Istio 数据面，还是只能使用 Istio 1.10.6 版本吗？\n A：是的，目前支持的这个版本。\n「MOSN」： https://github.com/mosn/mosn\n3. 高岩 提问：\n 请教下， MOSN 官网的集成 Istio 的例子，在 Katacoda 上练习 step 4 的测试 curl productpage 时失败，然后在我本地 Minikube 的环境测试结果也一样，请问下这个 demo 问题怎么排查？\n A：我试了一下，这个 Katacode 上执行 grep 会报错，但是不执行就没问题。\n 好的，我再试一下，感谢。\n A：如果遇到问题，可以看一下 MOSN 的日志。kubectl logs $pod -c istio-proxy 就可以了，还有问题可以建个 issue。\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 Kusion 模型库和工具链的探索实践\n\nSeata 多语言体系建设\n\nGo 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\n欢迎扫码关注：\n","date":1658473200,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220722/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"077f31118a42474e52018a9f6b870b4f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220722/","publishdate":"2022-07-22T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220722/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220722/","wordcount":675},{"author":"梁倍宁","categories":"SOFAStack","content":" 前言 SOFABoot的isle模块为Spring Boot应用提供了上下文隔离的能力以更好的支持模块化开发。借助该能力，可以很好的解决不同模块中的Bean冲突问题，有效的提高了团队协作开发的效率，尽可能的避免因冲突带来的额外时间成本\n SOFABoot的模块隔离能力，也叫做Spring上下文隔离能力，相较于类加载器隔离的实现方式，Spring上下文隔离的实现更为简单。SOFA给每一个模块都提供了一个独立的Spring上下文，这样各模块之间的Bean就无法直接引用，直接引用时通常会出现NoSuchBeanDefinitionException表示当前容器没有指定的Bean，以达到各模块在运行时隔离的效果。\n模块化启动相关类 类名 描述 com.alipay.sofa.isle.stage.PipelineStage 该接口是PipelineContext中一个步骤的描述，SOFA将启动行为抽象成了一条流水线中的各个步骤 com.alipay.sofa.isle.stage.ModelCreatingStage 该类是PipelineStage实现之一，其主要作用是创建模块 com.alipay.sofa.isle.stage.SpringContextInstallStage 该类是PipelineStage实现之一，其主要作用是将SOFA定义的“模块”安装到Spring的上下文中，也是SOFA模块化中最关键的一个步骤 com.alipay.sofa.isle.stage.ModuleLogOutputStage 该类是PipelineStage实现之一，其主要作用只是模块化的相关日志 com.alipay.sofa.isle.spring.SofaModuleContextLifecycle 该类是SOFA模块化核心实现的入口类，实现了SmartLifecycle接口，会在Spring发布ContextRefreshed事件之前调用 主体流程 SofaModuleContextLifecycle SOFABoot的模块化能力主要是基于Spring的Lifecycle来实现的，核心的入口类为com.alipay.sofa.isle.spring.SofaModuleContextLifecycle，该类实现了Spring的org.springframework.context.SmartLifecycle接口，会在ContextRefreshedEvent事件发布之前调用。当Spring的上下文刷新时会触发SOFA模块化的装配流程，其源码如下：\npublic void start() { if (isleRefreshed.compareAndSet(false, true)) { try { pipelineContext.process(); } catch (Throwable t) { SofaLogger.error(ErrorCode.convert(\u0026amp;quot;01-10000\u0026amp;quot;), t); throw new RuntimeException(t); } } } 检查当前状态是否是已经调用，如已调用则直接返回。 如果是Root上下文，则直接调用PipelineContext的process，该调用会顺序执行模块化流水线上的各个步骤ModelCreatingStage、SpringContextInstallStage、ModuleLogOutputStage 接下来我们逐个解析PipelineStage的行为。\nModelCreatingStage 顾名思义模型构造阶段，该阶段会对应用程序构造一个应用模型，用以描述应用的基本属性以及所拥有的模块。ModelCreatingStage的process源码码如下：\nprotected void doProcess() throws Exception { ApplicationRuntimeModel application = new ApplicationRuntimeModel(); application.setAppName(appName); SofaRuntimeManager sofaRuntimeManager = applicationContext .getBean(SofaRuntimeManager.class); application.setSofaRuntimeContext(sofaRuntimeManager.getSofaRuntimeContext()); application.setModuleDeploymentValidator(new DefaultModuleDeploymentValidator()); getAllDeployments(application); applicationContext.getBeanFactory().registerSingleton(SofaBootConstants.APPLICATION, application); } 为应用构造运行时模型ApplicationRuntimeModel\n 为ApplicationRuntimeModel设置应用名，即环境变量中的spring.application.name对应的值\n 为应用模型设置SOFA运行时上下文\n 读取所有的Deployment并装载到ApplicationRuntimeModel中\n 将该ApplicationRuntimeModel注册到应用程序的Root Spring上下文中\n 这里详细说明一下第3步中是如何加载Deployment的，以下是getAllDeployments的代码:\nprotected void getAllDeployments(ApplicationRuntimeModel application) throws IOException, DeploymentException { Enumeration\u0026amp;lt;URL\u0026amp;gt; urls = appClassLoader.getResources(SofaBootConstants.SOFA_MODULE_FILE); if (urls == null || !urls.hasMoreElements()) { return; } while (urls.hasMoreElements()) { URL url = urls.nextElement(); UrlResource urlResource = new UrlResource(url); Properties props = new Properties(); props.load(urlResource.getInputStream()); DeploymentDescriptorConfiguration deploymentDescriptorConfiguration = new DeploymentDescriptorConfiguration( …","date":1658473200,"description":"源码解析｜SOFABoot 上下文隔离机制解析","dir":"projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e980cc3e12470d9a9f803973bb5c1a48","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","publishdate":"2022-07-22T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","summary":"前言 SOFABoot的isle模块为Spring Boot应用提供了上下文隔离的能力以更好的支持模块化开发。借助该能力，可以很好的解决不同模块","tags":["“源码解析”"],"title":"源码解析｜SOFABoot 上下文隔离机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","wordcount":5953},{"author":null,"categories":"SOFAStack","content":" 文｜杨英明（花名：向野)\nKusionStack 核心贡献者、蚂蚁集团高级研发工程师\n在基础设施技术领域深耕，专注 IaC/XaC、GitOps 等方向\n本文 4912 字 阅读 12 分钟\n前言 KusionStack 最早是为了解决蚂蚁内部复杂的运维场景而诞生的解决方案。思路是通过自研的 DSL （KCL） 沉淀运维模型 （Kusion Model） ，将基础设施部分能力的使用方式从白屏转为代码化，同时结合 DevOps 工具链 （Kusion CLI） 实现配置快速验证和生效，以此提升基础设施的开放性和运维效率。\n其中，Kusion Model 就是题中所说的 Kusion 模型库，而 Kusion CLI 就是 Kusion 工具链了。具体概念如下：\nKusion 模型库 Kusion 模型库是基于 KCL 抽象的配置模型。它的特点包括了开箱即用、用户友好、以及业务抽象。其实模型库最初朴素的出发点就是改善 YAML 用户的编写效率和体验，因为目前其实有不少配置是基于 YAML 描述的，比如 Kubernetes 在成为容器编排的事实标准之后，基于 K8s 的声明式配置就越来越多了起来。\n但是由于 K8s 本身的复杂性导致 YAML 配置越来越冗长、复杂。我们希望通过将复杂的配置描述通过 KCL 这门配置语言抽象封装到统一的模型中，从而简化用户侧配置代码的编写。\nKusion 工具链 Kusion 工具链是基于 KCL 的 DevOps 工具集合，它是用来辅助用户在 Kusion 生态里更好的生成、驱动他们的 KCL 配置。\n简单来说，Kusion 模型库是用 KCL 语言沉淀下来的可复用组件，工具链是 Kusion 模型的驱动器。\n本文主要介绍 KusionStack 中 Kusion 模型库和工具链在蚂蚁内部的实践探索和总结，重点阐述了如何利用 KusionStack 提升复杂基础设施的开放性和运维效率，希望对同样面临此类困境的伙伴有所启示。\nPART. 1\u0026amp;ndash;为什么要做 Kusion 模型库和工具链？ 我们可以先来看一张“现象\u0026amp;ndash;问题”图：\n在这张图中，我们列出了一些在内部大规模场景下的实践过程中会遇到的问题。\n举个应用部署的例子，应用 A 有 10+ 组件，内部对于这种非标应用没有提供很好的支持，每次部署需要经历繁多的步骤，比如元数据准备、申请证书、VIP、域名、手动部署 CRD、RBAC、Webhook、监控配置等。这个过程没有自动化，交付部署复杂，定制程度高，其中任何一个步骤出现问题，都需要找对应的研发同学沟通，应用部署的人工成本很高。\n总体来说，当时蚂蚁内部在大规模场景下利用现有基础设施进行运维的困境，主要就是来源于以上列出的这些现象，所以去解决这些现象背后的问题，成了亟待我们去做的事情。\nPART. 2\u0026amp;ndash;困境中的应对思路 经过反复的探讨和一致认同，我们最终摸索出一套解决方案，即通过 Kusion 模型库和工具链，从以下几个方面解决上述复杂基础设施运维困境的问题。\n可读性 面向业务 \u0026amp;amp; 屏蔽底层实现\n我们基于 KCL 抽象了 Kusion 模型库，其中包含一些开箱即用的模型，这些模型针对业务进行了抽象和提炼，面向用户的这层模型界面暴露的都是用户关心的属性，一些实现的细节被屏蔽掉了，所以它是面向业务的，也更容易被用户所接受和上手使用。\n符合工程直觉\nKusion 模型库作为用 KCL 编写的模型集合，更加符合工程直觉。因为 KCL 既然作为一门语言，它支持定义变量，编写条件判断，比如你可以通过 if-else 编写一些差异化的配置。\n解决的问题\n本节介绍的可读性的提升主要分为两个方面。一方面是 KCL 这门 KusionStack 自研的配置语言本身足够强的表达力，使得通过 KCL 描述配置和抽象模型更加丝滑；另一方面，使用 KCL 定义的 Kusion Model 封装了复杂的配置转换逻辑，屏蔽业务细节，抽象出清晰易懂的用户界面。这两方面的带来的可读性的优势可以比较好的解决使用传统配置语言维护困难的问题。\n工程性 前后端模型解耦\n我们对 Kusion 模型库根据功能，区分了前端模型和后端模型。为什么要区分前端模型和后端模型？直接目的是将「用户界面」和「模型实现」进行分离：\n前端模型\n前端模型即「用户界面」。包含平台侧暴露给用户的所有可配置属性，其中省略了一些重复的、可推导的配置，抽象出必要属性暴露给用户。\n用户只需要像实例化一个类 （Class） 一样，传入必要参数构成一份应用的「配置清单」，再经过工具链编译即可得到完整的面向基础设施的配置描述，比如说 K8s 的 YAML；\n后端模型\n后端模型是「模型实现」。后端模型和前端模型不同，是对用户不感知，刚才提到前端模型可以构成用户的配置清单，那么怎么让用户的配置清单生效呢？\n我们将属性的渲染逻辑全部下沉到后端模型中，后端模型中可借助 KCL 编写校验、逻辑判断、代码片段复用等逻辑，提高配置代码复用性和健壮性。\nMixin 复用\nMixin 是 KCL 提供的一种复用代码片段的方式。举个具体的例子，比如说有个模型的属性叫做超卖，开启超卖开关可以将 Pod 调度到可以超卖的机器当中，应用一般在发布线下环境的时候会开启超卖，以充分利用集群的资源。这段超卖配置生效的逻辑可能会被不同的应用运维模型使用，那么就可以借助 Mixin 机制实现一个 OverQuotaMixin，OverQuotaMixin 可以被不同后端模型引用，解决复用性的问题，无需重复造轮子。\nAppConfiguration 沉淀\n我们针对不同应用运维场景或者部署场景抽象为不同的应用运维模型，这些应用运维模型我们叫做 AppConfiguration。\n它们暴露的属性是不一样的，比如适应于标准基础设施的标准应用模型，适应于网络应用的网络应用模型。这些不同的应用运维模型暴露给用户可配置的属性是不同的，这些模型沉淀下来可以描述越来越多场景的应用运维配置，沉淀为在推动配置代码化过程中重要的资产。\n解决的问题\n本节介绍的是团队在建设蚂蚁的 Kusion 模型库过程中形成的一套最佳实践，它是推动建设 Kusion 模型库和工具链的一站式和开放性的基础。\n一站式 全生命周期配置描述 \u0026amp;amp; Single Source of Truth\n我们在完善可读性和工程性的过程中实现了全生命周期配置描述。我们将应用的部署配置、网络配置、监控配置等等和应用生命周期相关的配置尽可能的放到了一个模型中。\n这样做的好处是，将散落在各个系统的配置片段收集到了一起，用户可以在一个统一界面中维护他的应用配置，同时对于第三方系统，也不需要对接不同系统，他只需要运维一份统一的配置即可。\n「全生命周期配置描述」其实在做一件事情，就是业界经常提到的 Single Source of Truth，也就是所谓的“唯一真实来源”。这是实现 IaC 的重要前提之一。\n从下图可以看到，Kusion 模型库中的前后端模型将不同维度的运维能力通过 KCL 模块化，并灵活组织在各种 AppConfiguration 模型中。同时基于 AppConfiguration 实例化出的 …","date":1658214000,"description":"KusionStack 最早是为了解决蚂蚁内部复杂的运维场景而诞生的解决方案。思路是通过自研的 DSL（KCL）沉淀运维模型（Kusion Model），将基础设施部分能力的使用方式从白屏转为代码化，同时结合 DevOps 工具链（Kusion CLI）实现配置快速验证和生效，以此提升基础设施的开放性和运维效率。","dir":"blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e4c34198e41bd1986c646cf6f0ab041b","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","summary":"文｜杨英明（花名：向野) KusionStack 核心贡献者、蚂蚁集团高级研发工程师 在基础设施技术领域深耕，专注 IaC/XaC、GitOps 等方向 本文 4912 字 阅读 12 分钟","tags":["SOFAStack"],"title":"KusionStack 开源｜Kusion 模型库和工具链的探索实践","type":"blog","url":"/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","wordcount":5102},{"author":null,"categories":"SOFAStack","content":" 文｜赵新（花名：于雨 )\n蚂蚁集团可信原生部工程师阿里开源先锋人物、阿里开源大使\n负责蚂蚁可信原生技术部 DB Mesh 系统开发，以及容器和分布式事务开源工作\n本文 3846 字，阅读 10 分钟\n｜引语｜ 分布式事务是微服务技术体系中非常关键的的一个技术节点，当下最流行且经过大规模生产验证的高质量分布式事务实现无疑是 Seata。Seata 社区过去四年长期专注于 Java 语言实现，在 Java 领域是事实上的分布式事务技术标准平台。\n在诸如 gRPC 等微服务体系都在进行多语言建设的当下，分布式事务也应该有多种语言支持。所以在规划 2022 年 Seata Roadmap 时，其中一个非常的关键点就是 Seata 的多语言技术体系建设。在经过半年的准备特别是完成了 Seata v1.5.2 发版后，社区在今年 （2022年） 下半年的重点任务就是全力建设 Seata 的多语言实现。\nPART. 1\u0026amp;ndash;关键技术点 Seata Java 版本经过四年建设后，已经形成了一个非常庞大的技术体系。在进行多语言建设时，想要在半年内让多语言版本 Seata 的功能与 Seata Java 完全对齐，是不可能的。社区需要综合考量当下的实际迫切需求以及未来的发展方向，先找出 Seata 多语言版本的关键技术点。\n1. 事务模式 Seata 提供了 TCC、SAGA、AT 和 XA 四种经典事务模式。下图是四种模式的发布时间。\n各种模式有其各样的特点：\nAT 模式\n算是阿里体系独创的事务模式，其本质属于两阶段事务，其二阶段的 commit/rollback 由框架自动生成，对业务没有侵入，用户友好度高于 TCC 模式，可完美接续 Spring 事务，开发效率也较高，也是当前用户最多的一种模式。在 v1.5.2 已经发版的当下时间节点来看，AT 模式下通过全局锁来实现数据的隔离性，对于同一个资源的事务处理只能串行操作，性能一般。\nTCC 模式\n需要业务层参与者实现 prepare/commit/rollback 接口，其性能在四种模式下最好，数据可见性、隔离性也不错，流行程度仅次于 AT。特别适用于对吞吐、性能、隔离性要求都比较高的金融业务。\nSAGA 模式\n是一种长事务解决方案，其一阶段正向服务和二阶段补偿服务都由业务开发实现，可以很方便地与微服务框架进行结合，其性能仅次于 TCC 模式。因为其方便编排的特点，它在微服务编排领域有大量应用，当然使用时需要用户写 JSON 文件对服务进行编排。但其数据隔离性不好，业务数据有被脏写的风险。社区目前正在进行 SAGA 注解化工作（https://github.com/seata/seata/pull/4577），可进一步提升其性能与易用性。\nXA 模式\n不同于其他三种「补偿型」事务，它提供了最严格的隔离性：可以保证全局视角的数据一致性，即保证了用户不会出现脏读。Seata XA 模式的接口与 AT 模式基本一致，算是对用户比较友好的一种事务模式，它是对 XA 协议的严格实现。XA 模式的缺点是其事务范围比较长，其性能最低。\n四种模式的发版顺序如下：\n每种事务模式在阿里体系内都有各自的业务场景，其出现与演进都是迎合了各自业务场景现有的痛点。AT 和 XA 是不需要理解业务语义的，作用于 DB driver + DB 层面，TCC 和 SAGA 则需要业务层面自实现回滚幂等类逻辑，按照数据面和业务面来切分，依据对业务的入侵程度，四种模式归类如下图。\n分布式事务的基石是通信框架、SQL 解析以及数据库连接驱动实现等。得益于 Java 语言丰富的生态，Seata Java 版本可以很方便地站在这些 “巨人” 肩上展开相应的工作，这也是其他语言无法望其项背的。例如，主流数据库都提供了其 Java 版本的 DB driver。但当把工作背景放到多语言场景下时，就需要考量各个语言相关技术点的实现程度了。\n四种事务模式，AT 模式本质是应用层的事务，需要把数据库层面做过的 Redo/Undo 在应用层再做一遍，其中非常关键的一个技术点是：AT 模式需要介入数据源做 SQL 拦截，对 SQL 进行解析。单单考量 SQL 解析这个单技术点，Java 和 Python 语言有 antlr，Go 语言有 TiDB 提供的可自由使用的 pingcap/parser，但目前很多其他语言在这块都是空白的。\n所以社区在考量现实情况后，除了 Go 和 Python 版本，在进行多语言版本建设时，没有 SQL 解析包的语言版本先不提供 AT 模式的实现。\n2. 通信协议 不论哪种事务模式，都构建在 Seata 独有的架构之上。\n图片来自 seata 官网\nSeata 总体架构由如下角色构成：\n事务协调器 Transaction Coordinator\n简称 TC，维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n事务管理器 Transaction Manager\n简称 TM，定义全局事务的范围，提交或者回滚全局事务。\n资源管理器 Resource Manager\n简称 RM，和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\nTC 与 TM 以及各个 RM 之间使用 netty 框架进行长链接通信。具体而言，Seata Java 版本的通信协议是在四层 TCP 协议之上又定义了一套私有的二进制双向通信协议。其关键点在于 Seata Java 版本站在了 netty 这个巨人肩上。\n回到多语言这个背景下，很多语言并没有提供一套成熟的 TCP 通信框架。譬如 Dubbo 在建设其 Go 版本 dubbo-go 时，为了在 TCP 之上实现与 Dubbo 的私有二进制协议通信，本人前期的工作重点是先实现 TCP 通信框架 getty（https://github.com/apache/dubbo-getty），然后再实现其序列化协议 dubbo-go-hessian2（https://github.com/apache/dubbo-go-hessian2）。如果把语言切换成 JS、PHP 或者 Python，相关通信协议建设需要耗费社区大量精力。\nSeata 2019 年就在 API 层适配了 gRPC 的事务上下文传递，为了方便 Seata 多语言版本的建设，Seata Java 框架本身正在进行一项重要工作：Seata Client （包括 TM 和 RM） 基于 gRPC 与 Seata Server （TC） 集群进行通信。希望借助于 gRPC 的多语言优势，节省多语言版本在通信层面的工作量。\n3. 配置和注册中心 类似于其他微服务框架，Seata 自身除了上一节提到的内部组件外，还依赖于注册中心和配置中心。微服务上层的应用通过配置中心找到注册中心，再通过注册中心发现 Seata 的各个服务组件。一个典型的完备的 Seata 服务架构如下图。\nSeata Java 这套架构可以很方便的嵌入注入 Dubbo、SOFARPC 以及 Spring 等 Java 微服务框架中。其中两种非常重要的外部依赖组件是：\nConfig …","date":1658214000,"description":"在诸如 gRPC 等微服务体系都在进行多语言建设的当下，分布式事务也应该有多种语言支持。所以在规划 2022 年 Seata Roadmap 时，其中一个非常的关键点就是 Seata 的多语言技术体系建设。在经过半年的准备特别是完成了 Seata v1.5.2 发版后，社区在今年 （2022 年） 下半年的重点任务就是全力建设 Seata 的多语言实现。","dir":"blog/seata-multi-programming-language-system-construction/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"60da96ebbdbc644758f505352c5e2d13","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-multi-programming-language-system-construction/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/seata-multi-programming-language-system-construction/","summary":"文｜赵新（花名：于雨 ) 蚂蚁集团可信原生部工程师阿里开源先锋人物、阿里开源大使 负责蚂蚁可信原生技术部 DB Mesh 系统开发，以及容器和分布式事务开源工作","tags":["SOFAStack"],"title":"Seata 多语言体系建设","type":"blog","url":"/sofastack.tech/blog/seata-multi-programming-language-system-construction/","wordcount":4266},{"author":"林楠","categories":"SOFAStack","content":" 前言 SOFABoot 提供两种服务通信能力，一种是 JVM 服务，用于同一应用内不同模块间的通信，一种是 RPC 服务，用于不同应用间的通信。SOFABoot 提供三种方式实现服务的发布和引用，分别是XML 配置文件、注解和 API 的方式，本文从源码角度解析从服务的发布和引用到组件协议 binding 机制的实现原理。\n服务发布与引用 在了解组件协议 binding 机制之前，我们先简单了解一下服务的发布与引用的源码。\nXML 通过 XML 方式发布或引用服务时，使用 sofa:service 发布服务，使用 sofa:reference 引用服务，示例代码如下：\n\u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleJvmService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.isle.sample.SampleJvmService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; \u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleJvmService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.isle.sample.SampleJvmService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 我们可以看到在 xml 中使用 xmlns:sofa，将 sofa 前缀的命名空间定义为 http://sofastack.io/schema/sofaboot ，Spring 在解析 sofa:* 标签时会与该命名空间相关联。对于 xml 的解析，SOFABoot 在 sofa-boot 模块中使用 spring.handlers 配置文件中注册了 sofa 命名空间的 XML 处理器。\nhttp\\://sofastack.io/schema/sofaboot=com.alipay.sofa.boot.spring.namespace.handler.SofaBootNamespaceHandler SofaBootNamespaceHandler 在初始化阶段，基于 SPI 机制查找所有标签解析器，调用 registerTagParser 方法注册标签解析器。\npublic void init() { ServiceLoader\u0026amp;lt;SofaBootTagNameSupport\u0026amp;gt; serviceLoaderSofaBoot = ServiceLoader.load(SofaBootTagNameSupport.class); serviceLoaderSofaBoot.forEach(this::registerTagParser); } 注册标签解析器时，调用解析器的 supportTagName 方法获取标签名，将解析器与标签名关联起来。\nprivate void registerTagParser(SofaBootTagNameSupport tagNameSupport) { if (tagNameSupport instanceof BeanDefinitionParser) { registerBeanDefinitionParser(tagNameSupport.supportTagName(), (BeanDefinitionParser) tagNameSupport); } else if (tagNameSupport instanceof BeanDefinitionDecorator) { registerBeanDefinitionDecoratorForAttribute(tagNameSupport.supportTagName(), (BeanDefinitionDecorator) tagNameSupport); } else { ... } } sofa:service 标签的解析器是 ServiceDefinitionParser，使用 doParseInternal 方法读取 xml 标签属性值，并解析为 bean 定义，根据 getBeanClass 定义的类型，将 sofa:service 标签定义的服务转换为 ServiceFactoryBean，并注册到 Spring 上下文中。\npublic class ServiceDefinitionParser extends AbstractContractDefinitionParser { ... @Override protected void doParseInternal(Element element, ParserContext parserContext, BeanDefinitionBuilder builder) { String ref = element.getAttribute(REF); builder.addPropertyReference(REF, ref); if (element.hasAttribute(\u0026amp;quot;id\u0026amp;quot;)) { String id = element.getAttribute(\u0026amp;quot;id\u0026amp;quot;); builder.addPropertyValue(BEAN_ID, id); } else { builder.addPropertyValue(BEAN_ID, ref); } } @Override protected Class getBeanClass(Element element) { return ServiceFactoryBean.class; } @Override public String supportTagName() { return \u0026amp;quot;service\u0026amp;quot;; } } 根据 Spring 的机制，在注册 bean 时，对 bean 的属性赋值后会调用 bean …","date":1658214000,"description":"源码解析 | SOFABoot 组件协议 binding 机制解析","dir":"projects/sofa-boot/sofaboot-component-protocol-binding/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"acfba7d02af62462b2f1c32fb39c9265","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","summary":"前言 SOFABoot 提供两种服务通信能力，一种是 JVM 服务，用于同一应用内不同模块间的通信，一种是 RPC 服务，用于不同应用间的通信。SOFABoot 提供三种方式实","tags":["“源码解析”"],"title":"源码解析：SOFABoot 组件协议 binding 机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","wordcount":5465},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展\n欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 清源 提问：\n 咨询个问题，MOSN 能做协议转换吗？类似于 API 网关那种功能，像 HTTP 调 Dubbo 的服务。\n A：可以的哈，这里是一个 HTTP 到 SOFA 的例子，\nhttps://github.com/mosn/mosn/tree/master/pkg/filter/stream/transcoder/http2bolt\n 我看了下，例子中并没有对 buf 做编解码，是 Bolt 自动识别 HTTP 的报文吗？\n A：这个 filter 就是把 HTTP 的字段转换为 Bolt 的哟，这还有个 Spring Cloud 到 Dubbo 的转换，MOSN 已经对 buf 解码好了，暴露给你的是 HTTP 解码之后的 header 和 body，\nhttps://www.github.com/mosn/extensions/tree/master/go-plugin%2Fplugins%2Ftranscoders%2Fspringcloud2dubbo%2Fmain\n「MOSN」：\nhttps://github.com/mosn/mosn\n2. 国奇 提问：\n 你好，请问有能用的 SOFARegistry 安装步骤吗？\n A：用 start_dev 启动 integrate 模式，registry-run.sh 是给其他脚本调用的：\n也可以参考下面这个文档，fatjar docker 的部署模式都可以：\n*https://www.sofastack.tech/projects/sofa-registry/deployment/***\n「SOFARegistry」：\nhttps://github.com/sofastack/sofa-registry\n3. 国奇 提问：\n 你好，发现一个问题，比如 A 应用 1.0 升级到 2.0 得改 webContextPath 才可以。也就是说要升级版本，要改版本号，还需要改 webContextPath 对吧？\n A：按这里文章介绍的，不引入 web-ark-plugin 的话，就用不同的端口来部署多个 web 服务。你们可以保留这个使用方式，就不需要改 webContextPath，\nhttps://github.com/WuHang1/sofa-ark/blob/code_analyse_multi_web_deploy/doc/CODE_ANALYSE_MULTI_WEB.md\n 发布就会更改不同的端口号，否则端口号被占用。可不可以，我自己不用改端口号，也不用改 webContextPath？\n A：目前不可以，你可以看下之前介绍 SOFAArk Web 插件的文档，里面介绍了必须要改这两个中的其中一个。如果有方案能做到这点那是挺好的，可以提个 proposal。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 Go 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\n社区文章｜MOSN 构建 Subset 优化思路分享\n\nNydus —— 下一代容器镜像的探索实践\n\n欢迎关注：\n","date":1657868400,"description":"SOFA Weekly | 开源人—牛学蔚、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220715/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f60972f54e7daee19a80b6022c644290","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220715/","publishdate":"2022-07-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220715/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展 欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人—牛学蔚、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220715/","wordcount":912},{"author":null,"categories":"SOFAStack","content":" 文｜丁飞（花名：路德 )\n蚂蚁集团高级工程师\n深耕于 SOFAMesh 产品的商业化落地\n主要方向为基于服务网格技术的系统架构升级方案设计与落地\n本文 4394 字 阅读 10 分钟\n｜前言｜ MOSN 作为蚂蚁集团在 ServiceMesh 解决方案中的数据面组件，从设计之初就考虑到了第三方的扩展开发需求。目前，MOSN 支持通过 gRPC、WASM、以及 Go 原生插件三种机制对其进行扩展。\n我在主导设计和落地基于 Go 原生插件机制的扩展能力时遇到了很多问题，鉴于这方面的相关资料很少，因而就有了这个想法来做一个非常粗浅的总结，希望能对大家有所帮助。\n注：本文只说问题和解决方案，不读代码，文章最后会给出核心源码的 checklist。\nPART. 1\u0026amp;ndash;文章技术背景 一、运行时 通常而言，在计算机编程语言领域，“运行时”的概念和一些需要使用到 VM 的语言相关。程序的运行由两个部分组成：目标代码和“虚拟机”。比如最为典型的 JAVA，即 Java Class + JRE。\n对于一些看似不需要“虚拟机”的编程语言，就不太会有“运行时”的概念，程序的运行只需要一个部分，即目标代码。但事实上，即使是 C/C++，也有“运行时”，即它所运行平台的 OS/Lib。\nGo 也是一样，因为运行 Go 程序不需要前置部署类似于 JRE 的“运行时”，所以它看起来似乎跟“虚拟机”或者“运行时”没啥关系。但事实上，Go 语言的“运行时”被编译器编译成了二进制目标代码的一部分。\n图 1-1. Java 程序、runtime 和 OS 关系\n图 1-2. C/C++ 程序、runtime 和 OS 关系\n图 1-3. Go 程序、runtime 和 OS 关系\n二、Go 原生插件机制 作为一个看起来更贴近 C/C++ 技术栈的 Go 语言来说，支持类似动态链接库的扩展一直是社区中较为强烈的诉求。\n如图 1-5，Go 在标准库中专门提供了一个 plugin 包，作为插件的语言级编程界面，src/plugin 包的本质是使用 cgo 机制调用 unix 的标准接口：dlopen() 和 dlsym() 。因此，它给 C/C++ 背景的程序员一种“这题我会”的错觉。\n图 1-4. C/C++ 程序加载动态链接库\n图 1-5. Go 程序加载动态链接库\nPART. 2\u0026amp;ndash;典型问题解决 很遗憾，与 C/C++ 技术栈相比，Go 的插件的产出物虽然也是一个动态链接库文件，但它对于插件的开发、使用有一系列很复杂的内置约束。更令人头大的是，Go 语言不但没有对这些约束进行系统性的介绍，甚至写了一些比较差的设计和实现，导致插件相关问题的排错非常反人类。\n本章节重点跟大家一起看下，在开发、使用 Go 插件，主要是编译、加载插件的时候，最常见、但必须定位到 Go 标准库 （主要包括编译器、链接器、打包器和运行时部分） 源码才能完全弄明白的几个问题，及对应的解决方法。\n简而言之，Go 的主程序在加载 plugin 时，会在“runtime”里对两者进行一堆约束检查，包括但不限于：\n- go version 一致\n- go path 一致\n- go dependency 的交集一致\n 代码一致 path 一致 - go build 某些 flag 一致\n一、不一致的标准库版本 主程序加载插件时报错：\nplugin was built with a different version of package runtime/internal/sys\n从这个报错的文本可以得知，具体有问题的库是 runtime/internal/sys ，很显然这是一个 go 的内置标准库。看到这里，你可能会有很大的疑惑：我明明用的是同一个本地环境编译主程序和插件，为什么报标准库不是一个版本？\n答案是，Go 的 error 日志描述不准确。而这个报错出现的根本原因可以归结为：主程序和插件的某些关键编译 flag 不一致，跟“版本”没啥关系。\n比如，你使用下面的命令编译插件：\nGO111MODULE=on go build \u0026amp;ndash;buildmode=plugin -mod readonly -o ./codec.so ./codec.go\n但是你使用 goland 的 debug 模式调试主程序，此时，goland 会帮你把 go build 命令按下面的例子组装好：\n注意，goland 组装的编译命令里包含关键的 -gcflags all=-N -l 参数，但是插件编译的命令里没有。此时，你在尝试拉起插件时就会得到一个有关 runtime/internal/sys 的报错。\n图 2-1. 编译 flag 不一致导致的加载失败\n解决这一类标准库版本不一致问题的方案比较简单：尽可能对齐主程序和插件编译的 flag。事实上，有一些 flag 是不影响插件加载的，你可以在具体的实践中慢慢摸索。\n二、不一致的第三方库版本 如果使用 vendor 来管理 Go 的依赖库，那么当解决上一节的问题之后，你 100% 会立即遇到以下这个报错：\nplugin was built with a different version of package xxxxxxxx\n其中，xxxxxxxx 指的是某一个具体的三方库，比如 github.com/stretchr/testify。这个报错有几个非常典型的原因，如果没有相关的排查经验，其中几个可能会烧掉开发人员不少时间。\nCase 1. 版本不一致\n如报错所示，似乎原因很明确，即主程序和插件所共同依赖的某个第三方库版本不一致，报错中会明确告诉你哪一个库有问题。此时，你可以对比排查主程序和插件的 go.mod 文件，分别找到问题库的版本，看看他们是否一致。如果这时候你发现主程和插件确实有 commitid 或 tag 的不一致问题，那解决的方法也很简单：对齐它们。\n但是在很多场景下，你只会用到三方库的一部分：如一个 package，或者只是引了某些 interface。这一部分的代码在不同的版本里可能根本就没有变更，但其他没用到的代码的变更，同样会导致整个三方库版本的变更，进而导致你成为那个“版本不一致”的无辜受害者。\n而且，此时你可能立即会遇到另一个问题：以谁为基准对齐？主程序？还是插件？\n从常理上来说，以主程序为基线进行对齐是一个比较好的策略，毕竟插件是新添加的“附属品”，且主程序与插件通常是“一对多”的关系。但是，如果插件的三方库依赖因为任何原因就是不能和主程序对齐怎么办？在尝试了很久以后，我暂时没有找到一个完美解决这个问题的办法。\n如果版本无法对齐，就只能从根本上放弃走插件这条路。\nGo 语言的这种对三方库的、几乎无脑的强一致性约束，从一方面来说，避免了运行时因为版本不一致带来的潜在问题；从另一方面来说，这种刻意不给程序员灵活度的设计，对插件化、定制化、扩展化开发非常的不友好。\n图 2-2. 共同依赖的三方库版本不一致导致的加载失败\nCase 2. 版本号一致，代码不一致\n当你按照 case 1 的思路排查 go.mod 文件，但是惊讶的发现报错的库版本是一致的时候，事情就会变得复杂起来。你可 …","date":1657609200,"description":"作者在主导设计和落地基于 Go 原生插件机制的扩展能力时遇到了很多问题，鉴于这方面的相关资料很少，因而就有了这个想法来做一个非常粗浅的总结，希望能对大家有所帮助。","dir":"blog/go-native-plug-in-use-problem-full-analysis/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"734cc212a753d53c15717c92d859d34c","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","publishdate":"2022-07-12T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","summary":"文｜丁飞（花名：路德 ) 蚂蚁集团高级工程师 深耕于 SOFAMesh 产品的商业化落地 主要方向为基于服务网格技术的系统架构升级方案设计与落地 本文 4394 字 阅读 10 分钟 ｜前","tags":["SOFAStack"],"title":"Go 原生插件使用问题全解析","type":"blog","url":"/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","wordcount":4545},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 何烨 提问：\n 请问一下这个配置现在支持 Nacos 了吗？\n A：SOFABoot 已经支持 Nacos 了。\n「SOFABoot」： https://github.com/sofastack/sofa-boot\n2. 鲍之知 提问：\n 下图中这个 SOFATracer 日志默认是生成在哪里呀？\n A：~/logs。\n「SOFATracer」： https://github.com/sofastack/sofa-tracer\n3. Philip Guan 提问：\n 请问 biz 可以独立引入 master biz 中没有的依赖吗？例如 Hutool、master biz 没有，希望在 biz 里使用。\n A：可以的，打包完后可以 check 一下是否 /biz/ 里有这个包。如果没有的话，可以在 master biz 里引入这个依赖，在 biz 里引入但设置 为 provided 也可以使用。\n 期望是 master biz 不引入 Hutool 的情况下，在 biz 里使用 Hutool。\n A：可以的。\n「SOFAArk」： https://github.com/sofastack/sofa-ark\n本周推荐阅读 KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境 \n GLCC｜Kata Containers、Nydus、Layotto、KusionStack 中选名单公示！ \n SOFARegistry 源码｜数据同步模块解析 \n 社区文章｜MOSN 构建 Subset 优化思路分享 \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1657263600,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220708/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"897429d0434f7577dd9a8efd3b70056f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220708/","publishdate":"2022-07-08T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220708/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220708/","wordcount":661},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@魏顺利 提问：\n runtime-sofa-boot-starter 和 rpc-sofa-boot-starter 区别是什么？\n A：runtime-sofa-boot-starter 是 SOFA 的核心能力 starter，rpc-sofa-boot-starter 是 SOFARPC 能力的 starter。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n2.@寒鸦少年 提问：\n 请问 Plugin 是一个微服务的概念吗，是否提供 HTTP 接口呢？\n A：Plugin 自己管理的依赖，通过 ark 中提到的 导出机制，将其自己管理的类能够暴露给 biz 使用 （多 biz 可以共享某个 plugin 导出的类） ；plugin 和 biz 之间更多说的是类加载的委托关系，biz 之间是通信。\n 那 biz 的 class loader 的加载逻辑应该很复杂吧，因为它要区分什么类自己加载，什么类委托 plugin 加载。\n A：可以看下这个，https://www.sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/\n「SOFAArk」https://github.com/sofastack/sofa-ark\n本周推荐阅读 社区文章｜MOSN 构建 Subset 优化思路分享 \n SOFA 星球”闯关计划 2.0——Layotto 飞船焕新出发 \n Nydus —— 下一代容器镜像的探索实践 \n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1656054000,"description":"SOFA Weekly | 开源人-于雨、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220624/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bc4cc62919a28554b99dc8a812b88dcc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220624/","publishdate":"2022-06-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220624/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人-于雨、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220624/","wordcount":813},{"author":null,"categories":"SOFAStack","content":" 文｜李旭东（花名：向旭 )\n蚂蚁集团技术专家\n蚂蚁中间件研发，专注于 SOFARegistry 及其周边基础设施的开发与优化\n本文 2098 字 阅读 8 分钟\n｜前言｜ MOSN 使用了 Subset 算法作为其标签匹配路由负载均衡的方式。本文主要介绍 Subset 的原理，包括了在超大规模集群下 MOSN 的 Subset 所遇到的一些性能瓶颈与采用的优化算法。\n首先，为什么要优化 Subset 呢？\n总体而言，性能瓶颈往往会由于集群规模的增大逐渐暴露出来。在蚂蚁的超大规模的集群上，注册中心推送地址列表会对应用造成一定的开销。\n在我所参与过的某一次大规模压测中，核心应用的机器数目非常庞大，当进行发布或者运维的时候，它的地址列表会被推送给所有调用它的应用。\n而 MOSN 会接收这份地址列表重新构建自己的路由。当地址列表非常庞大的时候，MOSN 更新 cluster 的性能瓶颈逐渐地暴露出来，出现了较高的 CPU 毛刺，内存在短时间内出现了上涨，gc 频率也大幅度增加。\n通过下方的火焰图，我们可以看到这次压测期间对某应用的 MOSN 的 pprof：\n- Alloc：\n- CPU：\n从 pprof 可以看到，无论是 CPU 还是 alloc 的开销， 构建 SubsetLoadBalancer 都明显占了大头，所以优化这部分的构建是亟待去做的一件事。\n最终通过探索优化，我们可以减少 SubsetLoadBalancer 构建过程中 95% 的 CPU 开销和 75% 的 alloc 开销。\n下面让我们一起回顾下本次优化的过程与思路。\nPART. 1\u0026amp;ndash;Subset 基本原理介绍 在一个集群里，通常机器会有不同的标签，那么如何将一个请求路由到指定标签的一组机器呢？\nMOSN 的做法是把一个服务下的机器按照机标签组合进行预先分组，形成多个子集。在请求的时候，根据请求中的 metadata 信息可以快速查询到这个请求对应应该匹配到的子集。\n如下图所示，可以看到当前有 4 个节点：\n标签匹配规则会根据 zone 、mosn_aig 、mosn_version 这 3 个字段进行匹配路由，根据这 3 个 key 的排序进行组合得到以下匹配路径：\n相对应的匹配树如下：\n假设需要访问 {zone: zone1, mosn_aig: aig1}，那么经过排序后查找顺序为 mosn_aig:aig1 -\u0026amp;gt; zone:zone1，查找到 [h1, h2]。\n以上就是 Subset 的基本原理介绍。\nPART. 2\u0026amp;ndash;MOSN 对 Subset 的构建 首先需要输入的参数有两个：\n- 带标签的机器列表 hosts，比如 [h1, h2, h3, h4]；\n- 用于匹配的 subSetKeys, 如下图：\n接着我们先带上思路，然后阅读源码来看一下 MOSN 的 SubsetLoadBalancer 是如何构建这棵树的。\n核心思路如下：\n- 遍历每一个 host 的 labels 和 subSetKeys 递归去创建一棵树；\n- 对于树的每一个节点，都会遍历一次 hosts 列表，过滤出匹配这个节点的 kvs 的 subHosts，每个节点创建一个子 load balancer。\n我们来看源码图：\n整体的构建复杂度是 O *(M*NK) (M: Subset 树节点个数，N: Hosts 个数, K: 匹配的 Keys）\nPART. 3\u0026amp;ndash;构建性能瓶颈分析 通过对生产的 profile 分析，我们发现 SubsetLoadBalancer 的 createSubsets 在 CPU 和 alloc 的火焰图中的占比都较高。所以下面我们开始编写 benchmark，来优化这一部分的性能。\n我们的输入参数为：\n- subSetKeys：\n- 8000 个 hosts （每个 hosts 都有 4 个 label, 每个 label 对应 3 种 value） ：\n接着，我们来看 CPU 和 alloc_space 的占用情况。\n- CPU：\n- alloc_space：\n从上面两张火焰图中，我们可以看出 HostMatches 和 setFinalHost 占用了较多的 CPU_time 和 alloc_space。我们首先来看下 HostMatches：\n它的作用是判断一个 host 是不是完全匹配给定的键值对，且判断这个 host 是否匹配这个匹配树节点。\n它的开销主要在于执行次数过多：treeNodes * len(hosts) ，所以在集群变大时，这边的运行开销会大幅度上升。\n然后我们再来看一下 setFinalHost：\n他的主要逻辑是按 IP 进行去重，同时会附带 copy。如果我们在 SubsetLoadBalancer 的顶层进行去重，那么它的任意 Subset 都不需要再次去重。因此，这边可以把它改成不去重。\nPART. 4\u0026amp;ndash;倒排索引优化构建 在 HostMatches 的这么多次匹配中，实际上有很多的重复操作，比如对 host label 中某个 kv 判断 equals，在构建过程中重复的次数相当之多。\n所以优化的思路可以基于避免这部分重复的开销，从预先构建倒排索引出发。具体步骤展开如下：\n1. 输入两项参数:\n- subSetKeys：\n- hosts：\n2. 遍历一次 hosts，针对每个 kv 我们用 bitmap 构建倒排索引：\n3. 根据 subSetKeys 和倒排索引中的 kvs，构建出匹配树，因为索引中是去重的与 hosts 数目无关，这个操作开销占比很低；\n4. 对于树的每个节点，利用倒排索引中的 bitmap 做交集快速得到匹配全部 kv 的 hosts 的索引 bitmap；\n5. 使用 bitmap 中存储的 index 从 hosts 中取出对应 subHosts 构建子 load balancer，同时注意此处不需要使用 setFinalHosts 进行去重。\n基于上述思路过程开发新的 Subset preIndex 构建算法，可以在 MOSN 的对应 Pull Request 页面查看详情：\nhttps://github.com/mosn/mosn/pull/2010\n再分享下添加 benchmark 进行测试的地址：\nhttps://github.com/mosn/mosn/blob/b0da8a69137cea3a60cdc6dfc0784d29c4c2e25a/pkg/upstream/cluster/subset_loadbalancer_test.go#L891\n可以看到相对之前的构建方式，构建速度快了 20 倍，alloc_space 减小了 75% 。同时，alloc 次数出现了少量的上升，这是因为需要额外的构建一次倒排索引所致。\n下面观察一下 gc：\n我们可以发现，相较于之前的构建方式，运行期间的内存更小了，而且 CPU 回收的内存也变少了，同时 gc 并行扫描的时长小幅上涨，STW 时间变的更短。\n最后，测试一下在不同 hosts 数目下的优化程度，可以看到在 hosts …","date":1655708400,"description":"MOSN 使用了 Subset 算法作为其标签匹配路由负载均衡的方式。本文主要介绍 Subset 的原理，包括了在超大规模集群下 MOSN 的 Subset 所遇到的一些性能瓶颈与采用的优化算法。","dir":"blog/build-subset-optimization/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d1475506aa7ef2b35d302df89924b72d","permalink":"https://sofastack.github.io/sofastack.tech/blog/build-subset-optimization/","publishdate":"2022-06-20T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/build-subset-optimization/","summary":"文｜李旭东（花名：向旭 ) 蚂蚁集团技术专家 蚂蚁中间件研发，专注于 SOFARegistry 及其周边基础设施的开发与优化 本文 2098 字 阅读 8 分钟 ｜前言｜ MOSN 使用了 Subset 算法作为其标","tags":["SOFAStack"],"title":"社区文章｜MOSN 构建 Subset 优化思路分享","type":"blog","url":"/sofastack.tech/blog/build-subset-optimization/","wordcount":2243},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@魏顺利 提问：\n 生成的 ark-biz.jar 这个怎么打到 maven 仓库？\n A：加上true配置然后 mvn install/deploy，参考：\nhttps://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.@寒鸦少年 提问：\n 请教个问题，SOFAStack 商业版里面，SOFABoot 在集成中间件的时候，中间件的客户端咱这边有自己封装的版本，还是纯走开源的那些客户端比如 Jedis 之类的。\n A：SOFAStack 有些中间件会有自己的封装，也会有独立的客户端。\n 可以给个列表么，具体有哪些独立的客户端和开源版本的升级点对比之类的？\n A：可以看下这个：\n「SOFABoot」https://github.com/sofastack/sofa-boot\n本周推荐阅读 「开源之夏」SOFASTack \u0026amp;amp; MOSN 社区项目中选结果 \n SOFA 星球”闯关计划 2.0——Layotto 飞船焕新出发 \n Nydus —— 下一代容器镜像的探索实践 \n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1655449200,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220617/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3d55fba6e2019654f9dccb079b67ba5d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220617/","publishdate":"2022-06-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220617/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220617/","wordcount":699},{"author":"吴航","categories":"SOFAStack","content":" 背景 原生springboot-web应用部署流程 两种合并部署模式 支持单Host合并部署的关键点 多Biz共用tomcat实例 多Biz接口区分 总结 背景 SOFAArk基于java类加载机制，为我们提供了一种java进程内多模块隔离的方案。每个业务模块——Ark Biz，都是一个完整的springboot项目，可独立运行；也可作为一个maven依赖或远程jar包，引入被称为Master Biz的基座Biz，随着Master Biz的启动合并部署运行，并由专属的BizClassLoader加载来实现隔离。\n当多个合并部署的Biz为web应用时，则面临着更多的挑战，这里我们可以对比独立tomcat部署多个webapp的实现，其除了各webapp之间的隔离外，还要保证tomcat自身资源的共享和统一管控。SOFAArk从0.6.0开始支持基于springboot embedded tomcat的多web应用合并部署，它是如何做到的，是否可以继续扩展支持其它类型web容器应用，下文将会进行具体分析。\n原生springboot-web应用部署流程 我们先从原生的springboot构建的基于内置tomcat的web应用说起。其在运行main函数初始化时，使用TomcatServletWebServerFactory#getWebServer这一工厂方法，创建了一个实现WebServer接口的TomcatWebServer实例，用来控制一个tomcat服务器，其中包括了一个Catalina Server的实现StandardServer，Server中的Engine、Host、Context容器也都是一个，Context中包含了唯一的contextPath。\nspringboot自身还有jetty、netty等WebServer的实现，同样由其对应的工厂方法创建。对应的工厂bean基于springboot的自动装配机制加载。\n两种合并部署模式 首先我们可以参考非Web的多Biz合并部署，SOFAArk使用不同的类加载器加载不同的Biz，其中Master Biz为LaunchedURLClassLoader加载，非Master Biz有其专属的BizClassLoader加载。对于每个Web Biz，也会使用其类加载器完成上述原生springboot web应用的启动流程，创建自己的Server、Host等。\n这种情况下，为了区分不同Biz的接口，需要为每个Biz配置不同的port。\n这种方式由于一个Jvm进程中包含了多个Server及其Host，因此被称为多Host模式。\n多Host模式的问题首先在于重复创建了tomcat相关的资源，造成资源的浪费；其次是每个Biz有自己的端口，不利于整个Ark包应用整体对外提供服务。因此SOFAArk提供了类似独立tomcat部署多webapp的方式。所有Biz共用同一个Server及Host，每个Biz只创建自己的Context，通过Context中的contextPath将自身接口与其它Biz接口做区分。\n这种方式由于一个Jvm进程中共用一个Server及其Host，因此被称为单Host（多Context）模式。下面将就其实现做重点介绍。\n支持单Host合并部署的关键点 相较于单纯的springboot应用，一个Ark包的复杂之处在于，它可以包含多个Ark Biz，其中每个Ark Biz都是一个完整的springboot项目。因此在使用单个内置tomcat实例部署时会面临以下问题：\n 多个Biz(springboot项目)需要共用tomcat实例；\n 需要像独立tomcat下部署多webapp一样，通过添加前缀的方式区分不同Biz的http接口。\n 因此sofa-ark对springboot的相关实现做了替换，具体如下：\n sofa-ark springboot ArkTomcatServletWebServerFactory TomcatServletWebServerFactory ArkTomcatEmbeddedWebappClassLoader TomcatEmbeddedWebappClassLoader ArkTomcatWebServer TomcatWebServer 并使用其插件机制来扩展，ArkTomcatEmbeddedWebappClassLoader位于web-ark-plugin插件中，当maven依赖该插件时，springboot判断ArkTomcatEmbeddedWebappClassLoader类存在，加载ArkTomcatServletWebServerFactory，该Factory再创建ArkTomcatWebServer，由此使用单Host模式合并部署。\n若未依赖该插件，则ArkTomcatEmbeddedWebappClassLoader不存在，springboot自动加载其原生实现，使用多Host模式合并部署。\n多Biz共用tomcat实例 针对第一个问题——多个Biz要共用tomcat实例，sofa-ark定义了EmbeddedServerService接口，插件web-ark-plugin里包含了接口的实现EmbeddedServerServiceImpl，来持有公共tomcat实例。\npackage com.alipay.sofa.ark.web.embed.tomcat; //作为ark plugin导出 public class EmbeddedServerServiceImpl implements EmbeddedServerService\u0026amp;lt;Tomcat\u0026amp;gt; { //共享tomcat private Tomcat tomcat; private Object lock = new Object(); @Override public Tomcat getEmbedServer() { return tomcat; } @Override public void setEmbedServer(Tomcat tomcat) { if (this.tomcat == null) { //通过加锁，避免多Web Biz并发启动加载时重复创建tomcat实例 synchronized (lock) { if (this.tomcat == null) { this.tomcat = tomcat; } } } } } 如果Biz引入了web-ark-plugin，则在ArkTomcatServletWebServerFactory中注入EmbeddedServerServiceImpl，持有最先初始化的Web Biz创建的Tomcat实例(TomcatWebServer的核心)，并在后续初始化的其它Biz调用getWebServer获取tomcat实例时，返回持有的同一个实例，以此来保证多个Biz运行在同一个tomcat中。\npackage com.alipay.sofa.ark.springboot.web; //每个Web Biz启动中都会创建一 …","date":1655362800,"description":"SOFAArk 源码解析-多 Web 应用合并部署","dir":"projects/sofa-boot/sofa-ark-multi-web-component-deploy/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e279d4b44741b8b88e22bf6420d8b5a6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","publishdate":"2022-06-16T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","summary":"背景 原生springboot-web应用部署流程 两种合并部署模式 支持单Host合并部署的关键点 多Biz共用tomcat实例 多Biz接口区分 总","tags":["“源码解析”"],"title":"SOFAArk 源码解析-多 Web 应用合并部署","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","wordcount":3703},{"author":"林楠","categories":"SOFAStack","content":" 前言 spring-boot-starter-actuator模块为 Spring Boot 应用提供了监控能力，内置一系列健康指标，如数据源、磁盘空间等，并且允许开发者自定义健康指标。Spring Boot 提供 health 端点，将所有健康指标聚合，当应用中有一个组件状态异常，那么应用的整体状态视为down，开发者可以访问 health 端点来了解应用当前的运行状况。\n SOFABoot 基于 actuator 模块扩展了健康指标，为应用提供 SOFA 组件的健康检查能力。同时，在 Spring Boot 原生的健康检查能力基础之上，增加了 Readiness Check 的能力。在这里我们做一个区分，Spring Boot 原生的健康检查称为 Liveness Check，SOFABoot 增加的健康检查称为 Readiness Check。Liveness Check 关注应用运行是否正常，如果 Liveness 状态异常，表示这个应用已经无法对外提供服务；Readiness Check 则关注的是应用有没有启动完成，是否进入“准备就绪”状态，能否对外提供服务。\n Readiness Check 只在应用启动阶段执行一次，通过请求 readiness 端点获取就绪状态，准备就绪后流量将进入应用。Readiness Check 完成后，多次请求 readiness 端点，不会重新发起检查。因此，在运行阶段应使用 Liveness Check 检查应用健康情况。\n 总体流程 在介绍总体流程前，先看一下 SOFABoot 健康检查机制中的一些重要接口：\n 接口类 说明 org.springframework.boot.actuate.health.HealthIndicator Spring Boot 原生的健康检查接口，想要新增一个自定义健康指标，可以直接扩展此接口 com.alipay.sofa.healthcheck.core.HealthChecker SOFABoot 提供的健康检查接口，相比 HealthIndicator 接口，增加了一些扩展参数，如失败重试次数，超时时间等 com.alipay.sofa.boot.health.NonReadinessCheck SOFABoot 默认会将所有 HealthIndicator 和 HealthChecker 纳入 Readiness Check 中，可以实现该接口将指标项标记为不参与 Readiness Check com.alipay.sofa.healthcheck.startup.ReadinessCheckCallback SOFABoot在 Readiness Check 之后会回调这个接口，如果想要在健康检查后做一些处理，可以直接扩展此接口 SOFABoot 的健康检查是基于 Spring 事件机制实现的，核心是 com.alipay.sofa.healthcheck.ReadinessCheckListener。ReadinessCheckListener 类实现了 GenericApplicationListener 接口，并监听 ContextRefreshedEvent事件，当 Spring 上下文刷新时触发健康检查流程：\npublic void onContextRefreshedEvent(ContextRefreshedEvent event) { if (applicationContext.equals(event.getApplicationContext())) { healthCheckerProcessor.init(); healthIndicatorProcessor.init(); afterReadinessCheckCallbackProcessor.init(); readinessHealthCheck(); readinessCheckFinish = true; } } 初始化 HealthCheckerProcessor：在 Spring 上下文中查找所有 HealthChecker 类型的 Bean； 初始化 HealthIndicatorProcessor：在 Spring 上下文中查找所有 HealthIndicator 类型的 Bean，并排除掉不参与 Readiness Check 的Bean。默认会排除 NonReadinessCheck 类型的 Bean，还可以通过参数com.alipay.sofa.boot.excludedIndicators 配置要排除的类型； 初始化 AfterReadinessCheckCallbackProcessor：在 Spring 上下文中查找所有 ReadinessCheckCallback 类型的 Bean ； 执行 Readiness Check 从上文中可以看出，readinessHealthCheck 方法是 Readiness Check 的入口：\npublic void readinessHealthCheck() { ...... healthCheckerStatus = healthCheckerProcessor .readinessHealthCheck(healthCheckerDetails); ...... healthIndicatorStatus = healthIndicatorProcessor .readinessHealthCheck(healthIndicatorDetails); ...... if (healthCheckerStatus \u0026amp;amp;\u0026amp;amp; healthIndicatorStatus) { ...... healthCallbackStatus = afterReadinessCheckCallbackProcessor .afterReadinessCheckCallback(healthCallbackDetails); } determineReadinessState(); } Readiness Check 的主要流程是依次执行 HealthChecker 和 HealthIndicator 的检查，如果所有健康指标状态均正常，才会执行ReadinessCheckCallback 回调。最后聚合所有指标状态，判断应用是否准备就绪。 健康检查的核心逻辑就在三个处理器HealthCheckerProcessor、HealthIndicatorProcessor和AfterReadinessCheckCallbackProcessor中，接下来我们依次分析一下。\nHealthCheckerProcessor 首先看一下 HealthChecker 接口为开发者提了哪些方法：\n 方法签名 说明 Health isHealthy() 指标项检查，返回值标识指标项状态是否正常 String getComponentName() 指标项名称 int getRetryCount() 失败重试次 …","date":1655276400,"description":"源码解析 | SOFABoot HealthCheck 机制解析","dir":"projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"33693ca9474cc5e3a509fca7935b1cbb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","publishdate":"2022-06-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","summary":"前言 spring-boot-starter-actuator模块为 Spring Boot 应用提供了监控能力，内置一系列健康指标，如数据源、磁盘空间等，并且允许","tags":["“源码解析”"],"title":"源码解析：SOFABoot HealthCheck 机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","wordcount":5393},{"author":null,"categories":"SOFAStack","content":" 文｜严松（花名：井守）\nNydus 镜像开源项目 Maintainer蚂蚁集团技术专家\n蚂蚁集团基础设施研发，专注云原生镜像与容器运行时生态\n本文 7060 字 阅读 15 分钟\n｜前言｜ 容器镜像是云原生的基础设施之一，作为容器运行时文件系统视图基础，从它诞生到现在，衍生出了镜像构建、存储、分发到运行时的整个镜像生命周期的各种生态。\n然而，虽然镜像生态众多，但自它诞生以来，镜像设计本身并没有多少改进。这篇文章要探讨的就是对容器镜像未来发展的一些思考，以及 Nydus 容器镜像的探索和实践。\n读完这篇文章，你能够了解到：\n- 容器镜像的基本原理，以及它的组成格式；\n- 目前的镜像设计有哪些问题，应该如何改进；\n- Nydus 容器镜像做了哪些探索，以及怎么实践。\nPART. 1 容器镜像 OCI 容器镜像规范 容器提供给了应用一个快速、轻量且有着基本隔离环境的运行时，而镜像提供给了容器 RootFS，也就是容器内能看到的整个 Filesystem 视图，其中至少包括了文件目录树结构、文件元数据以及数据部分。镜像的特点如下：\n- 易于传输，例如通过网络以 HTTP 的方式从 Registry 上传或下载；\n- 易于存储，例如可以打包成 Tar Gzip 格式，存储在 Registry 上；\n- 具备不可变特性，整个镜像有一个唯一 Hash，只要镜像内容发生变化，镜像 Hash 也会被改变。\n早期的镜像格式是由 Docker 设计的，经历了从 Image Manifest V1[1]、V2 Scheme 1[2]到 V2 Scheme 2[3]的演进。后来出现了诸如 CoreOS 推出的其他容器运行时后，为了避免竞争和生态混乱，OCI 标准化社区成立。它定义了容器在运行时、镜像以及分发相关的实现标准，我们目前用的镜像格式基本都是 OCI 兼容的。\n镜像主要是由镜像层和容器配置两大部分组成的。\n什么是镜像层？\n可以回想下平时写的 Dockerfile 文件：每条 ADD、COPY、RUN 指令都可能会产生新的镜像层，新层包含的是在旧层的基础上，新增加或修改的文件 （包含元数据和数据） ，或被删除的文件 （用称之为  Whiteout **[4] 的特殊文件表示删除） 。\n所以简单来说镜像的每一层存储的是 Lower 与 Upper 之间的 Diff，非常类似 Git Commit。这层 Diff 通常会被压缩成 Tar Gzip 格式后上传到 Registry。\n在运行时，所有 Diff 堆叠起来后，就组成了提供给容器的整个文件系统视图，也就是 RootFS。镜像的另外一部分是容器运行时配置，这部分包含了命令、环境变量、端口等信息。\n镜像层和运行时配置各自有一个唯一 Hash （通常是 SHA256） ，这些 Hash 会被写进一个叫 Manifest[5]的 JSON 文件里，在 Pull 镜像时实际就是先拉取 Manifest 文件，然后再根据 Hash 去 Registry 拉取对应的镜像层/容器运行时配置。\n目前的镜像设计问题 第一，我们注意到镜像层需要全部堆叠后，容器才能看到整个文件系统视图，所以容器需要等到镜像的每一层都下载并解压之后才能启动。有一篇 FAST 论文研究分析[6]说镜像拉取占了大约容器 76% 的启动时间，但却只有 6.4% 的数据是会被容器读取的。这个结果很有趣，它激发了我们可以通过按需加载的方式来提高容器启动速度。另外，在层数较多的情况下，运行时也会有 Overlay 堆叠的开销。\n第二，每层镜像是由元数据和数据组成的，那么这就导致某层镜像中只要有一个文件元数据发生变化，例如修改了权限位，就会导致层的 Hash 发生变化，然后导致整个镜像层需要被重新存储，或重新下载。\n第三，假如某个文件在 Upper 层里被删除或者被修改，旧版本文件依然留存在 Lower 层里不会被删除。在拉取新镜像时，旧版本还是会被下载和解压，但实际上这些文件是容器不再需要的了。当然我们可以认为这是因为镜像优化做的不够好，但在复杂场景下却很难避免出现这样的问题。\n第四，镜像 Hash 能够保证镜像在上传和下载时候的不可变，但在镜像被解压落盘后，很难保证运行时数据不被篡改，这也就意味着运行时的数据是不可信的。\n第五，镜像是以层为基本存储单位，数据去重是通过层的 Hash，这也导致了数据去重的粒度较粗。从整个 Registry 存储上看，镜像中的层与层之间，镜像与镜像之间存在大量重复数据，占用了存储和传输成本。\n镜像设计应该如何改进 我们看到了 OCI 镜像设计的诸多问题，在大规模集群场景下，存储与网络负载压力会被放大，这些问题的影响尤为明显，因此镜像设计急需从格式、构建、分发、运行、安全等各方面做优化。\n首先，我们需要实现按需加载。 在容器启动时，容器内业务 IO 请求了哪些文件的数据，我们再从远端 Registry 拉取这些数据，通过这种方式，可以避免镜像大量数据拉取阻塞容器的启动。\n其次，我们需要用一个索引文件记录某个文件的数据块在层的 Offset 偏移位置。 因为现在的问题是，Tar 格式是不可寻址的，也就是说需要某个文件时，只能从头顺序读取整个 Tar 流才能找到这部分数据，那么我们自然就想到了可以用这种方式来实现。\n接着，我们改造层的格式以支持更简单的寻址。 由于 Tar 是会被 Gzip 压缩的，这导致了就算知道 Offset 也比较难 Unzip。\n我们让原来的镜像层只存储文件的数据部分 （也就是图中的 Blob 层） 。Blob 层存储的是文件数据的切块 （Chunk） ，例如将一个 10MB 的文件，切割成 10 个 1MB 的块。这样的好处是我们可以将 Chunk 的 Offset 记录在一个索引中，容器在请求文件的部分数据时，我们可以只从远端 Registry 拉取需要的一部分 Chunks，如此一来节省不必要的网络开销。\n另外，按 Chunk 切割的另外一个优势是细化了去重粒度，Chunk 级别的去重让层与层之间，镜像与镜像之间共享数据更容易。\n最后，我们将元数据和数据分离 。 这样可以避免出现因元数据更新导致的数据层更新的情况，通过这种方式来节省存储和传输成本。\n元数据和 Chunk 的索引加在一起，就组成了上图中的 Meta 层，它是所有镜像层堆叠后容器能看到的整个 Filesystem 结构，包含目录树结构，文件元数据，Chunk 信息等。\n另外，Meta 层包含了 Hash 树以及 Chunk 数据块的 Hash，以此来保证我们可以在运行时对整颗文件树校验，以及针对某个 Chunk 数据块做校验，并且可以对整个 Meta 层签名，以保证运行时数据被篡改后依然能够被检查出来。\n如上所述，我们在 Nydus 镜像格式中引入了这些特性，总结下来如下：\n- 镜像元数据和数据分离，用户态按需加载与解压；\n- 更细粒度的块级别数据切割与去重；\n- 扁平化元数据层 （移除中间层） ，直接呈现 Filesystem 视图；\n- 端到端的文件系统元数据树与数据校验。\nPART. 2 Nydus 解决方案 镜像加速框架 Nydus 镜像加速框架是 Dragonfly[7] …","date":1655190000,"description":"容器镜像是云原生的基础设施之一，虽然镜像生态众多，但自它诞生以来，镜像设计本身并没有多少改进。这篇文章要探讨的就是对容器镜像未来发展的一些思考，以及 Nydus 容器镜像的探索和实践。","dir":"blog/nydus-exploratory-practice-of-next-generation-container-images/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"66c30936f5c0aa0e2bdf61ffdb88288e","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","publishdate":"2022-06-14T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","summary":"文｜严松（花名：井守） Nydus 镜像开源项目 Maintainer蚂蚁集团技术专家 蚂蚁集团基础设施研发，专注云原生镜像与容器运行时生态 本文 7060 字 阅读 15 分","tags":["SOFAStack"],"title":"Nydus —— 下一代容器镜像的探索实践","type":"blog","url":"/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","wordcount":8779},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@有时候 提问：\n SOFARPC 注册服务和订阅服务用到的 interface，Java 类文件内容是一样的，但如果包路径不是完全一样有问题么？\n A：路径不一样就是不同接口，注册中心不感知到 method 这层。dataid 不一样的，https://www.sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/ 。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n2.@啥也不是 提问：\n 大佬们，在现有协议拓展框架下，在 choose host 以后根据节点信息动态选择上游的协议，实现起来感觉不是很方便，有大佬指点一下吗？\n A：你是上下游协议不一样吗？\n 是的，而且同一个集群里面协议也可能不一样。我们自己的 RPC 协议存在多个版本，上下游的版本我们没办法控制，想着每个版本分别作为一种协议，利用框架能力，让协议版本的选择跟序列化解偶，每个 host 的版本是通过我们自己配置中心获取的。cluster 中 host 协议版本不受我们控制。\n A：Upstream 的协议本来就是在 filter 里面转换，你在 choose host 之后进行 filter 设置就行了。这个是一个协议转换框架 filter，根据配置的协议转换，你可以复用这个，区别就是 upstream 的协议是动态指定的，但没有本质区别：https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ftranscoder\n「MOSN」https://github.com/mosn/mosn\n3.@曹飞 提问：\n 大佬，监控指标可以显示到应用维度吗？ A：Metric 可以自定义输出的。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 ID API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 Wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 蚂蚁集团获得 OpenInfra Superuser 2022 年度大奖！\n KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境\n 如何看待 Dapr、Layotto 这种多运行时架构？\n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers！\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1654844400,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220610/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2b864568ab02c9da5090b213d0ff984a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220610/","publishdate":"2022-06-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220610/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220610/","wordcount":1483},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#28:SOFAArk 类隔离框架设计\n 活动时间：06 月 09 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#28 SOFAArk 类隔离框架设计 SOFAArk 是一款基于 Java 实现的轻量级类隔离框架，主要提供类隔离、动态部署、合并部署能力。本次分享将用 30 分钟的时间，带你深入 SOFAArk 框架，一起剖析其技术背景及设计思想，并展望其未来的发展趋势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 张冯君（花名：远远）\n 蚂蚁集团开发工程师\n 负责蚂蚁集团 SOFAArk 框架方向的相关工作\n 议程 直播回放 https://www.bilibili.com/video/BV1gS4y1i7Fg/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1654758000,"description":"2022 年 6 月 09 日 19：00 - 20：00 ，线上直播第 28 期。","dir":"activities/sofa-channel-28/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bfe5796985a7bfb85eb7b19614b05a57","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-28/","publishdate":"2022-06-09T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-28/","summary":"概要 活动主题：SOFAChannel#28:SOFAArk 类隔离框架设计 活动时间：06 月 09 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B","tags":["SOFAChannel","SOFAArk","类隔离框架"],"title":"SOFAChannel#28 SOFAArk 类隔离框架设计","type":"activities","url":"/sofastack.tech/activities/sofa-channel-28/","wordcount":452},{"author":null,"categories":"SOFAStack","content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团高级技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n本文 2580 字 阅读 6 分钟\n｜前言｜ 本文撰写于 KusionStack 开源前夕，作者有感而发，回顾了团队从 Kusion 项目开发之初到现今成功走上开源之路的艰辛历程。当中既描述了作者及其团队做 Kusion 项目的初心和项目发展至今的成果，也表达了作者自身对团队的由衷感激，字里行间都散发着真情实感。\nKusionStack 是什么？\nKusionStack 是开源的可编程云原生协议栈！\nKusion 一词来源于 fusion （意为融合） ，希望通过一站式的技术栈融合运维体系的多个角色，提升运维基础设施的开放性、扩展性，从整体上降本增效。KusionStack 通过定义云原生可编程接入层，提供包括配置语言 KCL、模型界面、自动化工具、最佳实践在内的一整套解决方案，连通云原生基础设施与业务应用，连接定义和使用基础设施的各个团队，串联应用生命周期的研发、测试、集成、发布各个阶段，服务于云原生自动化系统建设，加速云原生落地。\nPART. 1 为了一个理想的运维体系 2019 年秋，MOSN 的工作已持续了近两年，期间我们逐步完成了在支付宝核心链路的形态验证。整个过程中除了 MOSN 本身面对的种种技术挑战和困难，所谓的云原生技术红利，实际上也已经掣肘于运维系统固化所造成的效率制约。\n有一天主管找我吃饭 （下套） ，期间向我描述了他理想中的运维体系：\n他希望 SRE 能通过一种专用语言来编写需求，通过写代码来定义基础设施的状态，而不是花费极大的精力在检查、发现、修复的循环上。基础设施团队则通过提供开放的可编程语言和工具支撑不同诉求的 SRE 团队，达到更高的整体 ROI。\n我立刻意识到这和 Hashicorp 的 Terraform 神之相似 （后来 Hashicorp 在 2021 年底上市，以超过 150 亿美元的市值成为迄今为止市值最高的一次开源 IPO） 。另一方面，不同于 IaaS 交付场景，蚂蚁面对着大量更规模化、复杂度更高的云原生 PaaS 场景，又让我想到了 Google 内部运用专用语言、工具等技术开放 Borg[1]运维能力的实践[2]，当时感觉这是一个既有意思又有挑战的事[3]。\n饭桌上我们聊了一些思路以及一些还不太确定的挑战，他问我想不想搞一个试试，搞不成也没关系。当时没想太多，饭没吃完就答应了。\nPART. 2 漫长的学习、探索与实践 隔行如隔山。\n没有过语言设计研发的经验，也没有过开放自动化系统设计的经验，项目开展之初，我们就陷入了举步维艰的困境。\n经历了一段漫长时间的学习、摸索和实践的反复循环之后，项目依旧没有大的起色，更困难的是我们不但要面对蚂蚁内部复杂又耦合的场景和问题，还要经受「这种高度工程化的方式在蚂蚁是否有生存土壤」的质疑。\n屋漏偏逢连夜雨，期间又令人惋惜且无奈的经历了一些人事变化，同时由于种种原因，项目一度陷入了各种困境。整个 2020 年，我们在未知、纠结、无奈中度过……\n感谢瓴熙、庭坚和我的主管，感谢你们当时没有放弃这个项目，依然与我一同坚守。\nPART. 3 痛并快乐的孵化之旅 通过持续地布道、交流和沟通，我们逐步在基础设施技术团队和 SRE 团队找到了更多有共识的朋友。\n同时在技术上，我们亦脱离了迷茫，真正意义上地启动了 Kusion 项目，也成功地从 PoC 过渡到了 MVP 的阶段。\n最终，我们以“非标”应用为切入点，开始了痛并快乐着的孵化之旅。\n感谢零执、青河、子波、李丰、毋涯、向野、达远……在这里无法一一列举，感谢你们的坚持让这个想法逐步成为现实。\nPART. 4 突破与进展 略过中间的种种探索和实践，回顾这段历程，在这一年多的时间里我们结合了编译技术、运维及平台技术，成功建立了一个基于 Kusion 可编程技术栈的运维体系。\n在业务场景上，项目覆盖了从 IaaS 到 SaaS 的大量运维场景，截至目前共接入了 800+ 应用，覆盖 9 个 BG，21 个 BU，其中典型案例交付运维提效 90% 以上，这也是蚂蚁内部第一次将大量异构应用纳入到一整套运维技术栈。\n在蚂蚁我们基于云原生容器和微服务技术深入探索了 DevOps、CICD 实践，完善了蚂蚁的云原生技术体系，逐步释放了云原生效率红利，同时形成了一个近 300 人的虚拟运维研发团队。\n不同职能不同团队的参与者凝聚在一起解决各自所面对的问题，贡献了 3W+ commit 和 35W+ 行代码，有一些参与者自发成为 Kusion 的研发者 。我认为这些工程师文化理念和领域知识的积累带来了远超运维业务本身的价值。\n此外，Kusion 也成为了可编程基线产品、云原生运维产品、多云交付产品等新一代运维产品的基础技术，成为蚂蚁运维体系架构升级的一部分。\n不忘初心，我们希望通过技术手段促进与运维参与方的合作关系的合理化、基于开放技术栈的自动化，以及运维数据与知识的沉淀积累，以达到整体协作运维效率的不断提升。\n同时，因蚂蚁内部运维场景较多且链路复杂，每个环节都需要最懂运维业务的 SRE 密切参与，与平台、应用研发协同工作，最终各环节联合在一起形成了一套完整的运维体系，在这样的思路下开放技术也会越来越重要。\n平台研发、SRE、应用研发等多种角色协同编写的代码是一种数据的沉淀，亦是一种业务知识的沉淀，基于这些数据和知识，未来会有更多的可能性。\nPART. 5 走上开源之路 在历经了一段内部探索之后，我们希望把 KusionStack 开源到技术社区。因为我们意识到自身面对的问题，其他公司、团队其实也同样正在面对。借助开源这件事，我们希望团队的这些工作成果能对更多人有所帮助。\n当然，也受限于自身能力以及精力和资源的投入，我们希望能有更多朋友参与进来，与我们共同去完善 KusionStack，不论你是工作在云原生、运维自动化、编程语言或者是编译器中的哪一个领域，我们都非常期待和欢迎你的加入。\nPART. 6 期待与你共成长 这段经历对我来说异常宝贵，不仅仅是在于自身再一次在新的技术领域和蚂蚁的技术升级方面尝试了新的探索并实现了突破，更宝贵的是，自己还拥有了一段与一群人均 95 后的小伙伴一起将想法落地实现的奇幻历程。\n在未来， Kusion 的朋友圈不再局限于蚂蚁内部，面向开源，我们期待着能有更多的社区朋友在 KusionStack 与我们共同成长！\n了解更多\u0026amp;hellip;\nKusionStack Star 一下✨：\nhttps://github.com/KusionStack\nKusionStack 的开源，希望能对大家有所帮助，也希望能跟更多朋友共同完善 KusionStack。欢迎对云原生、运维自动化、编程语言、编译器感兴趣的同学一起参与社区共建，在新的技术领域升级方面进行探索和突破，实现更多新的想法。\n点击文末阅读原文直达项目地址。\n【参考链接】\n[1]《Large-scale cluster management at Google with …","date":1654585200,"description":"KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境","dir":"blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"688d35ea65772596c3a0115a62a63b53","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","publishdate":"2022-06-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","summary":"文｜朵晓东（花名：奕杉 ) KusionStack 负责人、蚂蚁集团高级技术专家 在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作 本文 2580 字 阅读 6 分钟 ｜前","tags":["SOFAStack"],"title":"KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境","type":"blog","url":"/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","wordcount":2772},{"author":"周群力","categories":"SOFAStack","content":" 文｜周群力（花名：仪式 )\nLayotto PMC；Layotto 和 SOFAStack 开源社区的建设，Dapr 贡献者，Dapr sig-api 的 Co-chair\n本文 10963 字 阅读 20 分钟\n2019 年，微软开源了 Dapr 项目。2021 年，蚂蚁参照 Dapr 思想开源了 Layotto 项目。如今，蚂蚁已落地 Layotto，服务了很多应用。从理想落地到现实的过程中，我们遇到了不少问题，也对项目做了很多改变。回过头再看，如何看待 Dapr、Layotto 这种多运行时架构？我们能从中学到什么？\n本次我将从以下几个方面，分享蚂蚁在落地多运行时架构之后的思考：\n1. 如何看待“可移植性”\n2. 多运行时架构能带来哪些价值\n3. 与 Service Mesh、Event Mesh 的区别\n4. 如何看待不同的部署形态\nPART. 1 快速回顾\n如果你熟悉 Multi-Runtime、Dapr 和 Layotto 的概念，可以跳过这一章节，直接进入下一章节。\n快速回顾：什么是 Multi-Runtime 架构？\nMulti-Runtime 是一种服务端架构思路，如果用一句话来概括，就是把应用里的所有中间件挪到 Sidecar 里，使得“业务运行时”和“技术运行时”分离开。\n更详细的解释如下：首先来看 Service Mesh，和传统 RPC 框架相比，Service Mesh 的创新之处在于引入了 Sidecar 模式。Service Mesh 只解决了服务间通讯的需求，而现实中的分布式应用存在更多需求，比如“协议转换”、“状态管理”等。Multi-Runtime 架构提出将各种各样的分布式能力外移到独立 Runtime，最后和应用 Runtime 共同组成微服务，形成所谓的“Multi-Runtime” （多运行时） 架构。\n具体细节可以详阅《Multi-Runtime Microservices Architecture》和《Mecha：将 Mesh 进行到底》。\n哪些项目实现了 Multi-Runtime 架构？\nDapr\nDapr 的全称是“Distributed Application Runtime”，即“分布式应用运行时”，是一个由微软发起的开源项目。\nDapr 项目是业界第一个 Multi-Runtime 实践项目，Dapr 的 Sidecar，除了可以和 Service Mesh 一样支持服务间通讯，还可以支持更多的功能，如 state （状态管理） 、pub-sub （消息通讯） ，resource binding （资源绑定，包括输入和输出） 。Dapr 将每种功能抽象出标准化的 API （如 state API） ，每个 API 都有多种实现，比如用户可以面向 state API 编程，但是可以随意切换存储组件，今年用 Redis，明年改成用 MongoDB，业务代码不用改。\n如果之前没有接触过 Dapr，更详细的介绍可以阅读《Dapr v1.0 展望：从 Service Mesh 到云原生》这篇文章。\nLayotto\nLayotto 是由蚂蚁集团 2021 年开源的一个实现 Multi-Runtime 架构的项目，核心思想是在 Service Mesh 的数据面（MOSN里支持 Dapr API 和 WebAssembly 运行时，实现一个 Sidecar 同时作为 Service Mesh 数据面、多运行时 Runtime、FaaS 运行时。项目地址为：https://github.com/mosn/layotto\n以上是本文背景，接下来是本次主题分享。\nPART. 2 你真的需要这种“可移植性”吗？\n社区比较关注 Dapr API 的“可移植性”，但在落地过程中，我们不禁反思：你真的需要这种“可移植性”吗？\n标准化 API 能满足所有需求吗？\n数据库领域曾出现过一个有趣的讨论：同一个数据库能否适用于所有场景，满足所有需求？ 比如，一个数据库能否同时支持 OLAP+OLTP+ACID 等等需求？\n今天，我们在建设 Dapr API 的过程中也遇到了有趣的问题：在某个产品领域 （比如消息队列） ，能否定义一套“标准 API”同时适用于所有的消息队列？\n当然，这两个问题不能混为一谈：即使是两种不同类型的数据库，比如两个数据库，一个只做 OLAP，另一个只做 OLTP，它们都可以支持 SQL 协议。两个差距那么大的数据库都能用同样的协议，我们有理由相信：在特定领域，设计一个适用于所有产品的“标准 API”是可行的。\n可行，但现在还不完全行。\n现在的 Dapr API 还比较简单，简单场景足以胜任，但在复杂的业务场景下，做不到“帮助应用 Write once,run on any cloud”。对这个问题，敖小剑老师的文章《死生之地不可不察：论 API 标准化对 Dapr 的重要性》有过详细描述，大意是说：\n现在的 Dapr API 比较简单，在生产落地的时候满足不了复杂需求，于是开发者只能添加很多自定义的扩展字段，在 Sidecar 的组件里做特殊处理。比如下面是用 State API 时候的一些自定义扩展字段：\n（图片摘自敖小剑老师的文章）\n这些自定义的扩展字段会破坏可移植性：如果你换一个组件，新组件肯定不认识这些字段，所以你得改代码。\n之所以出现这个问题，背后的根本原因是 Dapr API 的设计哲学。\n社区在设计 Dapr API 时，为了可移植性，设计出的 API 倾向于 “功能交集” 。比如在设计 Configuration API 时，会考察各种配置中心 A、B、C，如果 A、B、C 都有同一个功能，那么这个功能才会出现在 Dapr API 中：\n然而，在现实世界中，人们的需求可能是 A 和 B 的交集，B 和 C 的交集 （如下图红色部分） ，而不是 A、B、C 的交集：\n或者更常见，用户的需求是“B 的所有功能”，其中必然包括一些 B 独有的功能，Dapr API 无法覆盖：\nDapr 提供“标准 API”、“语言 SDK”和“Runtime”，需要应用进行适配 （这意味着老应用需要进行改造） ，侵入性比较大。\n因此 Dapr 更适合新应用开发 （所谓 Green Field） ，对于现有的老应用 （所谓 Brown Field） 则需要付出较高的改造代价。但在付出这些代价之后，Dapr 就可以提供跨云跨平台的可移植性，这是 Dapr 的核心价值之一。\n这些听起来是解决不了的问题。那怎么办？\n跨云部署时，你真的需要从 Redis 换成 Memcached 吗？\n在设计 API 时，常常出现类似的讨论：\nA：嘿，这个功能只有 Redis 和 xxx 有，但是 Memcached 和其他存储系统没有。我们该怎么办，要不要把这个功能纳入 API 规范里？\nB：如果我们把这个功能纳入 API 里，会有什么问题？\nA：那样的话，使用我们 API 的用户就没法从 Redis 迁移到 Memcached 了，这破坏了可移植性！\n等一等……你真的需要从 Redis 换成 Memcached 吗？\n你真的需要这种“可移植性”吗？\n不需要吧！如果 …","date":1653980400,"description":"本文讨论了 Layotto 落地之后，关于 Multi-Runtime 架构“可移植性”、落地价值以及部署形态等方面的思考。","dir":"blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","fuzzywordcount":9200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d0732e32f9b202c205fb1e03b195eb8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","publishdate":"2022-05-31T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","summary":"文｜周群力（花名：仪式 ) Layotto PMC；Layotto 和 SOFAStack 开源社区的建设，Dapr 贡献者，Dapr sig-api 的 Co-chair 本文 10963 字 阅读 20 分钟 2019 年，微软开源了 Dapr 项目。","tags":["SOFAStack"],"title":"如何看待 Dapr、Layotto 这种多运行时架构","type":"blog","url":"/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","wordcount":9182},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@周衡 提问：\n 请问一下，我需要调度 RPC 的上下文是哪一个类？有一些参数想直接通过上下文传递。\n A：RpcInvokeContextv6\n「SOFARegistry」：https://github.com/sofastack/sofa-rpc\n@bobtthp 提问：\n MOSN 对接 dubbo 目前注册中心支持 zk 吗？\n A：FaaS 示例么？那个还没上过生产，还在探索阶段。支持的，可以参考这个文档：https://www.github.com/mosn/mosn/tree/master/pkg%2Fupstream%2Fservicediscovery%2Fdubbod%2Fcommon.go\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n 深入 HTTP/3（2）｜不那么 Boring 的 SSL\n 【2022 开源之夏】欢迎报名 MOSN 社区项目！\n 蚂蚁集团 Service Mesh 进展回顾与展望\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1653634800,"description":"SOFA Weekly | Kusion 开源啦、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220527/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1f1971d6ef1280f9bc0fa21d099dfd99","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220527/","publishdate":"2022-05-27T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220527/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | Kusion 开源啦、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220527/","wordcount":1025},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#27:深入 HTTP/3｜从QUIC-TLS 看协议的安全设计\n 活动时间：05 月 26 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#27 深入 HTTP/3｜从 QUIC-TLS 看协议的安全设计 安全通信是网络技术中绕不开的话题，而 QUIC 作为目前炙手可热的协议技术，在这上面也理所应当的有着非常多的优秀实践，本次分享将用 50 分钟的时间，带你深入 QUIC-TLS，一起剖析其技术背景及设计思想，并展望其未来的发展趋势。\n当然，本次直播也分享一些蚂蚁自己的工程实践经验及相关的产品。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 曾柯（花名：毅丝）\n 蚂蚁集团高级工程师\n 负责蚂蚁集团的接入层建设工作，主要方向为高性能安全网络协议的设计及优化\n 议程 直播回放 https://www.bilibili.com/video/BV1xg411o7Jo/\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1653634800,"description":"2022 年 5 月 26 日 19：00 - 20：00 ，线上直播第 27 期。","dir":"activities/sofa-channel-27/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cdb2bb81c619db029bb9a62a1374b721","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-27/","publishdate":"2022-05-27T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-27/","summary":"概要 活动主题：SOFAChannel#27:深入 HTTP/3｜从QUIC-TLS 看协议的安全设计 活动时间：05 月 26 日，周四晚 19 点 活动形式：线","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#27 深入 HTTP/3｜从 QUIC-TLS 看协议的安全设计","type":"activities","url":"/sofastack.tech/activities/sofa-channel-27/","wordcount":543},{"author":"曾柯","categories":"SOFAStack","content":" 文｜曾柯（花名：毅丝 )\n蚂蚁集团高级工程师*负责蚂蚁集团的接入层建设工作* 主要方向为高性能安全网络协议的设计及优化\n本文 10924 字，阅读 20 分钟\nPART. 1 引言 从前一篇文章《深入 HTTP/3（1）｜从 QUIC 链接的建立与关闭看协议的演进》对于 QUIC 的浅述中我们了解到，QUIC 的优化很大程度上是一种基于 TLS 流程的优化，由此也可见 TLS 对于 QUIC 的重要性，那么今天我们就来聊一聊 QUIC-TLS。为了表述尽量没有歧义，我们先来规范下文章中各个术语的意义。\n本文目前既然已经提到了 SSL、TLS 这两个术语，我们不妨先来简短回顾下安全协议的发展史，这既可以帮我们理清两个术语的关系，也能帮助我们对这项技术的进化有一个简短的概念。\nSSL (Secure Sockets Layer) 协议本身是网景公司为了保证互联网上数据传输的安全性，在 1994 年设计的一套协议。这套协议在当时被广泛使用在各大浏览器上，但 SSL 协议最初的几个版本安全性都非常堪忧，初期的更迭非常频繁，从 1994 年到 1995 年连续迭代了 3 个大版本，而现在大家最耳熟能详的应该就是 SSLv3.0 了。可惜 SSLv3.0 也没有逃脱更迭的厄运，由于硬件算力的迭代，大量 SSLv3.0 中广泛使用的加密算法不再安全，并且协议交互流程也存在不安全之处。1999 年，IETF 正式介入安全协议的设计及开发，并推出了 TLS (Transport Layer Security) 协议的第一个版本 TLS1.0，随后 TLS 协议的发展开始变得迟缓，在 2006 年 IETF 组织推出了 TLS1.1，并在 2008 年再次发布了 TLS1.2，两个版本都是针对一些握手交互过程中的细节的安全提升，握手流程其实是没有大的变化的。\n直到 2013 年，Google 在推出 gquic 的同时，也推出了其设计的安全交互流程 quic-crypto，quic-crypto 是一次交互流程的重大创新，也以此成为了 TLS1.3 的前身。TLS1.3 从某种意义上来说，应该被称作 TLS2.0，因为其革新力度非常大，当然这也导致其标准化流程非常长，TLS1.3 的标准化整整历经了 4 年，直到 2018 年才正式成为 RFC。而 TLS1.3 本身也成为了 IETF-QUIC 的安全交互技术的基础，所以这条时间线里也揉杂了 QUIC-TLS 的设计历程，我们来简单理一下：\n图 1. TLS 发展简史\n当然 DTLS 等相关安全技术的进化也融合在这条时间线中，限于篇幅问题，这里暂时不表。说了这么多废话，我们现在来正式标准化一下我们的名词：\n【SSL、TLS】 ：在本文中都指安全传输协议，后续的文章中只会使用 TLS 作为相关技术的代名词\n【QUIC-crypto】 ：Google quic 中使用的握手流程，本文不对其进行具体分析\n【QUIC-TLS】 ：本文指 IETF-QUIC 使用的安全交互流程，即 RFC9001 中标准化的流程，也是本文详细描述的重点\n【PTO】 ：全称为 Probe Timeout，定义于 RFC9002 中，留待下一篇文章来对其进行详细分析，本文将其理解成一个通信端设置的针对报文的超时重传的时间即可\n【DTLS】 ：全称为 Datagram Transport Layer Security，即面向报文的 TLS 协议，限于篇幅的问题，本文并不详细对其分析，而 DTLS 中存在有很多和 QUIC-TLS 类似思路的设计，感兴趣的同学可以参见 RFC9147\n“make infrastructure boring”是 Google 一直以来的口号，BoringSSL 这个开源产品则是他们在安全通信领域的行动，而文章的标题既然叫“不那么 Boring 的 SSL”，除了蹭一蹭 BoringSSL 和 OpenSSL 这些著名的 SSL 开源项目的热度之外，也是想给文章制造一点悬念：Boring 往往意味着相关技术简单好用到了令人发指的地步，而 QUIC 到底遇见了什么问题，才让本身相对成熟的 TLS 协议用起来不再 Boring？\n本文后续也将围绕这个话题展开，来看看 QUIC-TLS 设计中那些值得玩味的地方。\nPART. 2 浅看 TLS 本着由浅入深的思路，在开始介绍 QUIC-TLS 之前，我们也先浅析一下 TLS，这也非常有助于我们后面对于 QUIC-TLS 的理解。\nTLS 协议从某种程度上来说解决了几个哲学问题：你是谁？你怎么证明你是你？\n当然这些问题的答案还不足以保证整个的安全\u0026amp;hellip;\n1. 我们还需要一种技术来保证中间人无法获取到我们的数据，这也就是我们相对比较熟悉的 「对称加密技术」，比如 AES、SM4 等加密技术；\n2. 为了加密的数据也能证明通信一端的身份，我们引入了 「AEAD 加密即认证的模式」；\n3. 为了协商出这种对称加密的密钥，TLS 引入了 「非对称密钥交换技术」，典型如 ECDHE、RSA 等密钥交换算法；\n4. 为了身份管理的统一及身份的有效携带，TLS 引入了 「数字证书技术」，包括整个 pki 公钥体系及 X509 数字证书标准；\n5. 为了数据的不可篡改，TLS 引入了 「数字签名技术」，典型如 ECDSA、RSA 等签名算法；\n6. 为了各个阶段的加密密钥独立及签名流程的简洁，TLS 引入了 「Hash 算法」，典型如 SHA 系列算法。\n上述的各种机制再整个 TLS 协议中被抽象为两部分协议：\n一层是 Handshake 协议，负责核心密钥的交互及身份认证；一层是 Record 协议，负责数据的安全，完整性及握手完成后数据的可信证明，而 Handshake 协议则坐落于 Record 协议之上，这也就形成了这样的协议栈。\n图 2. TLS 协议栈简图\n简而言之，Handshake 过程中的数据也依赖 Record 层来进行数据加密，而 Record 层加密的 key 则依赖 Handshake 层进行交互得到。这看似是个逻辑死锁，实际上是通过一个层层递进的状态机完成的，抛开繁琐的 TLS 状态机本身，这个流程基本可以用下图来表述：\n图 3. TLS 密钥状态更新流程图\n至于 TLS 的初始阶段使用明文传输的数据，也并不违背这个流程，我们可以将其理解为 TLS 初始阶段对应一个值为空的 key。而从上图中我们也可以看到，实现和虚线部分对应的两个阶段切换，必须有严格的先后顺序，如果发生乱序，一端是无法完成数据的解析的，所以 TLS 协议非常依赖底层传输协议来保证数据的有序到达，而这也是 TLS 的设计区别于 DTLS 和 QUIC-TLS 的最大根因之一。有了这部分知识储备，我们再来看 TLS 的握手 (以 TLS1.3 的 0-RTT 交互场景为例) ，就会清晰很多：\n图 4. TLS 握手流程图\n可以看到，明文\u0026amp;rdquo;()\u0026amp;ldquo;,\u0026amp;rdquo;{}\u0026amp;ldquo;,\u0026amp;rdquo;[]\u0026amp;ldquo;对应的加密状态的切换，和上面的图的流程基本是一致的，而典型如 EndOfEarlyData 这种标 …","date":1653375600,"description":"深入 HTTP/3（2）｜不那么 Boring 的 SSL","dir":"blog/deeperinto-http-3-2-the-not-so-boring-ssl/","fuzzywordcount":9500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e7a8be2c91c093af30cba5045b0b6516","permalink":"https://sofastack.github.io/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","publishdate":"2022-05-24T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","summary":"文｜曾柯（花名：毅丝 ) 蚂蚁集团高级工程师*负责蚂蚁集团的接入层建设工作* 主要方向为高性能安全网络协议的设计及优化 本文 10924 字，阅读 20 分钟 PART. 1 引言","tags":["SOFAStack"],"title":"深入 HTTP/3（2）｜不那么 Boring 的 SSL","type":"blog","url":"/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","wordcount":9435},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@林楠 提问：\n SOFARegistry 使用数据库做存储，未来有没有计划做一个简洁版，不依赖数据库？\n A：v6 使用存储主要是存放元数据而不是服务数据，元数据存储接口未来计划使用 jraft 作为存储。这也是 v5—\u0026amp;gt;v6 的过程中去掉的一个功能，因为在内部，引入 jraft 有一定运维成本，需要 operator 这种非标组件。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@jiaxin shan 提问：\n 想知道 Layotto 的成熟案例，有没有一些大公司进行使用呢？体量是多少？1.miscro-service 方向 2.FaaS 方向也有一些落地实例吗？\n A：目前蚂蚁在生产环境使用，另外也有某大厂准备上测试环境了。官网的 WASM 跑 FaaS 示例么？那个还没上过生产，还在探索阶段。\n 我理解目前像 FaaS、WASM 等更多是从社区角度，开源侧进行牵引，慢慢孵化一些场景？\n A：对，结合 WASM 做 FaaS 是开源社区探索方向；其他的 runtime、service mesh 属于生产需求驱动，更严肃一些。属于蚂蚁发起、社区共建，如果担心独裁，可以关注下 contributor 数、月活跃贡献者数这些指标，现在活跃贡献者有腾讯、同程等公司的朋友，3个 committor 都不是蚂蚁的。我们每周五有社区周会，你感兴趣可以来聊聊。钉钉群码：41585216\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 【2022 开源之夏】欢迎报名 SOFAStack 社区项目！\n 恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n 【2022 开源之夏】欢迎报名 MOSN 社区项目！\n 蚂蚁集团 Service Mesh 进展回顾与展望\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1653030000,"description":"SOFA Weekly | 我是开源人、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220520/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"27d18203e02fa487e39f1f9e1032271d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220520/","publishdate":"2022-05-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220520/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | 我是开源人、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220520/","wordcount":1274},{"author":"石建伟","categories":"SOFAStack","content":" 一、引言 继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么，值此 SOFAStack 开源 4 周年之际，欢迎大家一起进入《蚂蚁集团 Service Mesh 进展回顾与展望》章节探讨交流。\n本次交流将以如下次序展开：\n二、蚂蚁集团 Service Mesh 发展史 2018 年 3 月份蚂蚁集团的 Service Mesh 起步，MOSN 数据面诞生，起步就坚持走核心开源，内部能力走扩展的道路。 2019 年 6.18 我们在三大合并部署应用上接入了 MOSN 并且顺利支撑了 6.18 大促。 2019 年双 11 蚂蚁所有大促应用平稳的度过双大促。 2020 年 MOSN 对内沉稳发展把接入应用覆盖率提升至 90%，对外商业化开始展露头角。蚂蚁集团全站 90% 标准应用完成 Mesh 化接入。在商业版本中，SOFAStack“双模微服务”架构也在江西农信、中信银行等众多大型金融机构成功落地实践。 2021 年随着 Mesh 化的逐步成熟，多语言场景的逐步丰富，Mesh 化的对中间件协议的直接支撑带来的扩展性问题也逐步凸显，Dapr 的应用运行时概念也逐步崛起，这一年我们开源了 Layotto，期望通过对应用运行时 API 的统一来解决应用和后端中间件具体实现耦合的问题，进一步解耦应用和基础设施，解决应用在多云运行时的厂商绑定问题。 2022 年随着 Mesh 化落地的基础设施能力逐步完善，我们开始考虑 Mesh 化如果给业务带来更多价值，在 Mesh 1.0 时代，我们把中间件相关的能力尽可能做了下沉，提升了基础设施的迭代效率，在 Mesh 2.0 时代，我们期望能有一种机制可以让业务侧相对通用的能力，也可以做到按需下沉，并且具备一定的隔离性，避免下沉的能力影响 Mesh 数据代理主链路。这部分将在看未来部分做一些介绍。 图示的方式简诉一下 Service Mesh 架构演进的几个阶段：\n SOA 时代，中间件的客户端均直接集成在业务进程内： Mesh 化阶段一：中间件能力下沉，应用和基础设施实现部分解耦： 应用运行时阶段：将应用和具体基础设施的类型解耦，仅依赖标准 API 编程： 三、东西向流量规模化挑战 Mesh 化后的数据面 MOSN 承载了应用间非常核心的东西向通信链路，目前在蚂蚁集团内部覆盖应用数千，覆盖容器数十W+，海量的规模带来了如长连接膨胀、服务发现数据量巨大、服务治理困难等问题。接下来我们来聊一聊我们在演进的过程中遇到并解决掉的一些经典问题。\n3.1 长连接膨胀问题 在海量规模的应用背后存在着复杂的调用关系，部分基础性服务被大部分应用所依赖，由于调用方全连服务提供方的机制存在，一个基础性服务的单 Pod 需要日常承载近 10W 长连接，单机 QPS 一般还是有上限的，我们以 1000 QPS 的 Pod 举例，10w 长连接的场景下，每条长连接上的 QPS 是非常低的，假设所有连接的请求均等，平均每条长连接每 100s 仅有一次请求产生。\n为了保证长连接的可用性，SOFA RPC 的通信协议 Bolt 有定义心跳包，默认心跳包是 15s 一次，那么一条长连接上的请求分布大概如下图所示：\n在上诉场景中，一条长连接上，心跳包的请求数量远大于业务请求的数量，MOSN 在日常运行中，用于维护长连接可用句柄持有内存的开销，还有心跳包发送的 CPU 开销，在海量规模集群下不可忽视。\n基于以上问题，我们找到了两个解法：\n 在保证连接可用的前提下减少心跳频率 在保证负载均衡的前提下降低应用间的连接数 3.1.1 心跳退避 由于心跳的主要作用是尽可能早的发现长连接是否已不可用，通常我们认为经过 3 次心跳超时即可判定一条长连接不可用，在一条长连接的生命周期里，不可用的场景占比是非常低的，如果我们把长连接的检测周期拉长一倍就可以减少50%的心跳 CPU 损耗。为了保障检测的及时性，当出现心跳异常（如心跳超时等）场景时，再通过降低心跳周期来提高长连接不可用时的判定效率，基于以上思路我们设计了 MOSN 里的长连接心跳退避策略：\n 当长连接上无业务请求且心跳正常响应时，逐步将心跳周期拉长 15s -\u0026amp;gt; 90s 当长连接上出现请求失败或心跳超时的场景时，将心跳周期重置回 15s 当长连接上存在正常业务请求时，降级本次心跳周期内的心跳请求 通过以上心跳退避的手段，MOSN 的常态心跳 CPU 消耗降低至原来的 25%。\n3.1.2 服务列表分片 从心跳退避的优化可以看出，在海量长连接的场景下，单长连接上的请求频率是很低的，那么维护这么多长连接除了对负载均衡比较友好之外，其他的收益并不大，那么我们还有另外一个优化方向，就是减少客户端和服务端之间建立的长连接数量。\nMOSN 使用一致性哈希的策略对服务端机器进行分组：在客户端的内存中，首先将全量的服务端机器列表加入到一致性哈希环中，然后基于配置计算预期分片情况下的机器列表数 N，随后根据客户端机器 IP，从一致性哈希环中获取 N 个机器列表作为本机器的分片列表。每个客户端计算的哈希环都是一样的，不同的机器 IP 使得最终选择的机器分片列表是不同的。实现了不同客户端机器持有不同的服务端集群分片的效果。\n通过对服务列表的分片优化，客户端向服务端建立的长连接数量急剧减小，在 6w 长连接且采用 50% 的负载均衡分片的场景下：单机 CPU 降低约 0.4 Core，内存降低约 500M。\n3.2 海量服务发现问题 MOSN 的服务发现能力没有使用 Pilot，而是在内部直接和 SOFARegistry（服务注册中心） 对接，使用这种架构的原因之一就是 RPC 的接口级服务发现，节点的 Pub、Sub 量巨大，海量应用的频繁运维产生的节点变更推送对 Pilot 的性能和及时性挑战都很大，社区有使用 Pilot 在稍大规模下做 CDS 下发的过程中也发现非常多的性能问题并提交 PR 解决，但对于蚂蚁集团一个机房就有 200W Pub，2000W Sub 的规模下，Pilot 是完全无法承载的。SOFARegistry 的架构是存储和连接层分离，存储为内存分片存储，连接层也可以无限水平扩容，在内部海量节点变更下也能实现秒级变更推送。\n虽然 SOFARegistry 的推送能力没什么问题，不过海量节点变更后产生的推送数据，会导致 MOSN 内有大量的 Cluster 重构，列表下发后到 Cluster 构建成功的过程中，会有大量的临时内存产生，以及 CPU 计算消耗。这些尖刺型内存申请和 CPU 占用，是可能直接影响请求代理链路稳定性的。为了解决这个问题，我们也考虑过两个优化方向：\n SOFARegistry 和 MOSN 之间把全量推送改造为增量推送 服务发现模型从接口级切换为应用级 其中第一点能带来的效果是每次列表推送变化为原推送规模的 1/N，N 取决于应用变更时的分组数。第二点能带来的变化是更加明显的，我们假设一个应用会发布 20个接口，100个应用的 Pod 产生的服 …","date":1652770800,"description":"继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么，值此 SOFAStack 开源 4 周年之际，欢迎大家一起进入《蚂蚁集团 Service Mesh 进展回顾与展望》章节探讨交流。","dir":"blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8c0eeb7a88e858fcfef4b4c9824ebb3f","permalink":"https://sofastack.github.io/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","publishdate":"2022-05-17T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","summary":"一、引言 继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么","tags":["SOFAStack","Service mesh"],"title":"蚂蚁集团 Service Mesh 进展回顾与展望","type":"blog","url":"/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","wordcount":5542},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFAMeetup 成都站-云原生技术交流专场\n 活动时间：2022 年 05 月 14 日（周六）14:00-18:00\n 活动形式：线上直播\n 资料下载：\n 《Nydus-面向下一代的容器镜像》\n《云原生应用配置代码化实践》\n活动回顾 直播回放：\nNydus-面向下一代的容器镜像\n云原生应用配置代码化实践\n活动议程 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1652511600,"description":"SOFAMeetup 成都站-云原生技术交流专场","dir":"activities/sofa-meetup-15/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f637fdc7cae0e17bb6c6cf1302cd7f80","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-15/","publishdate":"2022-05-14T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-15/","summary":"概要 活动主题：SOFAMeetup 成都站-云原生技术交流专场 活动时间：2022 年 05 月 14 日（周六）14:00-18:00 活动形式：线上直播 资料","tags":["SOFA"],"title":"【活动回顾】《SOFAMeetup 成都站-云原生技术交流专场》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-15/","wordcount":211},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@曹飞提问：\n MOSN 集成 prometheus 是怎么使用呢？看到读取相应配置，是在自定义配置里面吗？\n A：你可以自定义收集指标，然后通过 promoetheus 格式输出。在配置加这个 metric 的就行了。https://github.com/mosn/mosn/blob/f3248bf2ed6c5d13635e8ce4af921f665ccdf96c/configs/mosn_config_dev.json#L69\n「MOSN」：https://github.com/mosn\n@沈冰 提问：\n SOFAArk 2.0 怎么创建 ark-plugin? 使用的场景是做类隔离。\n A：当前这个还和 1.0 的使用方式一致的，完全按照 1.0 的方式来。https://developer.aliyun.com/article/625338\n「SOFAArk」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto v0.4.0 版本 发布 Layotto v0.4.0 版本，主要变更如下：\n1.文件能力增加了七牛云 oss、hdfs、腾讯云 oss 的实现；\n同时增加了Java SDK 的实现\n2.支持 API 插件和自定义组件能力\n3.支持 SkyWalking\n4.支持基于内存的和 mongo 的分布式锁和分布式自增 ID\n5.支持 secret 接口\n6.支持 Dapr 的 state、InvokeService、InvokeBinding API\n7.优化了当前 CI 流程\n7.修复及优化若干 bug\n详细发布报告:https://github.com/mosn/layotto/releases/tag/v0.4.0\n本周推荐阅读 【2022 开源之夏】欢迎报名 SOFAStack 社区项目！\n 恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n SOFAServerless 体系助力业务极速研发\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1652425200,"description":"SOFA Weekly | Layotto v0.4.0 版本发布、开源之夏项目讲解、本周 Contributor","dir":"blog/sofa-weekly-20220513/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0d42b166bf83ba9a3cc657d29b0b64b2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220513/","publishdate":"2022-05-13T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220513/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto v0.4.0 版本发布、开源之夏项目讲解、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220513/","wordcount":1311},{"author":"Webster-Yang","categories":"SOFAStack","content":" 背景 SOFARgeistry 分为 Session、Data 和 Meta 三个模块。Session 模块用于 client 交互，可以横向扩容，可以承受大量 client 连接请求；Data 是数据存储模块，利用 slot 分片机制来均衡负载，使用备份来解决高可用问题；Meta 是 Session、Data 的注册中心，采用分布式锁来选举 leader，本文详细阐述 Meta 如何选主。\n基于 MySQL 的分布式锁 MySQL 表\ndrop table if exists distribute_lock; CREATE TABLE distribute_lock ( id bigint(20) NOT NULL AUTO_INCREMENT primary key, data_center varchar(128) NOT NULL, lock_name varchar(1024) NOT NULL, owner varchar(512) NOT NULL, duration bigint(20) NOT NULL, term bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT \u0026#39;任期\u0026#39;, term_duration bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT \u0026#39;租期\u0026#39;, gmt_create timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, gmt_modified timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_data_center_lock` (`data_center`, `lock_name`), KEY `idx_lock_owner` (`owner`) ); 表的增改查等操作\npublic interface DistributeLockMapper { /** * query by dataCenter and lockName * * @param dataCenter * @param lockName * @return */ public DistributeLockDomain queryDistLock( @Param(\u0026amp;quot;dataCenter\u0026amp;quot;) String dataCenter, @Param(\u0026amp;quot;lockName\u0026amp;quot;) String lockName); /** * compete lock, it will throw exception if lockName existed * * @param lock */ public void competeLockOnInsert(DistributeLockDomain lock) throws Exception; /** * compete lock with cas * * @param competeLock * @return */ public void competeLockOnUpdate(FollowCompeteLockDomain competeLock); /** renew lock last update time */ public void ownerHeartbeat(DistributeLockDomain lock); /** force reset owner and duration */ public void forceRefresh(DistributeLockDomain lock); } 整体流程 step1：启动时创建锁记录，\n\u0026amp;lt;insert id=\u0026amp;quot;competeLockOnInsert\u0026amp;quot; parameterType=\u0026amp;quot;com.alipay.sofa.registry.jdbc.domain.DistributeLockDomain\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;![CDATA[ INSERT /*+ QUERY_TIMEOUT(2000000) */ INTO distribute_lock ( data_center, lock_name, owner, duration, gmt_create, gmt_modified, `term`, `term_duration` ) VALUES ( #{dataCenter}, #{lockName}, #{owner}, #{duration}, NOW(3), NOW(3), 1, 0 ) ON DUPLICATE KEY UPDATE lock_name = #{lockName} ]]\u0026amp;gt; \u0026amp;lt;/insert\u0026amp;gt; step2：leader 每秒提交心跳，更新表\n\u0026amp;lt;update id=\u0026amp;quot;ownerHeartbeat\u0026amp;quot; parameterType=\u0026amp;quot;com.alipay.sofa.registry.jdbc.domain.DistributeLockDomain\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;![CDATA[ update /*+ QUERY_TIMEOUT(2000000) */ distribute_lock set owner = #{owner}, gmt_modified = NOW(3), `term_duration` = (`term_duration` + 1) where data_center = #{dataCenter} and lock_name = #{lockName} and owner = #{owner} and term = #{term} and `term_duration` = #{termDuration} and timestampdiff(SECOND, gmt_modified, NOW()) \u0026amp;lt; #{duration}/1000 ]]\u0026amp;gt; \u0026amp;lt;/update\u0026amp;gt; step3：follower 每秒判断锁是否过期，如果过期，则 cas 竞选 leader\npublic DistributeLockDomain onFollowWorking(DistributeLockDomain lock, String myself) { /** as follow, do compete if lock expire */ if (lock.expire()) { LOG.info(\u0026amp;quot;lock expire: {}, meta elector start: {}\u0026amp;quot;, lock, myself); distributeLockMapper.competeLockOnUpdate( new FollowCompeteLockDomain( lock.getDataCenter(), lock.getLockName(), lock.getOwner(), …","date":1652252400,"description":"源码解析｜registry meta选主","dir":"projects/sofa-registry/code-analyze/code-analyze-registry-meta/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1ed6ac5b5251011241bc8ec391f4e720","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","publishdate":"2022-05-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","summary":"背景 SOFARgeistry 分为 Session、Data 和 Meta 三个模块。Session 模块用于 client 交互，可以横向扩容，可以承受大量 client 连接请求；Data 是数据存储模块，","tags":["“源码解析”"],"title":"源码解析｜registry meta 选主","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","wordcount":1236},{"author":"赵真灵、刘晶","categories":"SOFAStack","content":" 文｜赵真灵（花名：有济）蚂蚁集团技术专家、刘晶（花名：飞廉） 蚂蚁集团技术专家\n以下内容整理自 SOFAStack 四周年的分享\n本文 5332 字 阅读 10 分钟\nSOFAServerless 研发运维平台是蚂蚁集团随着业务发展、研发运维的复杂性和成本不断增加的情况下，为帮助应用又快又稳地迭代而研发。从细化研发运维粒度和屏蔽基础设施的角度出发，演进出的一套解决方案。\n核心方式是通过类隔离和热部署技术，将应用从代码结构和开发者阵型拆分为两个层次：业务模块和基座，基座为业务模块提供计算环境并屏蔽基础设施，模块开发者不感知机器、容量等基础设施，专注于业务研发帮助业务快速向前发展。\nPART. 1 背 景 当前 Serverless 的发展有两个演进方向，一个是从面向函数计算的架构往在线应用演进，另一种是面向在线应用的架构往类函数计算方向演进。\nSOFAServerless 体系选择了后者，是从面向应用研发运维过程中遇到的一些问题展开的。在应用架构领域，不可避免的问题是应用随着业务的复杂度不断增加，研发运维的过程中的问题会不断暴露出来。\n首先我们先看一下对于普通应用，研发和运维过程中的流程是什么样的？\n如图所示，从需求到设计、开发、线下测试，再到发布线上的研发运维不断反馈、循环迭代的过程。可以简化为开发同学提交代码到代码仓库，在线下做并行的验证测试，测试通过之后在线上发布，发布过程是串行的，只能够有一个发布窗口，这样的过程在应用体量业务还不太复杂的情况下问题，并不是很明显。\n但当业务复杂度不断增加，普通应用迭代过程在会出现一些新的问题，如下图：\n1.管理成本高：需求管理、代码管理、人员管理\n2.时间成本高：线上验证与发布互相阻塞；单次启动慢\n3.变更风险高： 一次变更涉及所有代码；一次变更涉及所有机器\n4.可扩展性不够\n另外，由于这些问题是因为多业务单元与研发任务耦合在某些单点上导致的，这些研发运维的成本随着业务的复杂度，呈现出指数增长的特点。\nPART. 2 SOFAServerless 研发运维体系 解决方案介绍\n对于这些问题，业界已经发展并演进出了多种应用架构，从单体架构 -\u0026amp;gt; 垂直架构 -\u0026amp;gt; SOA 架构 -\u0026amp;gt; 分布式微服务架构 -\u0026amp;gt; 服务网格架构等，我们分析这些演进过程为解决遇到的研发运维问题提出 SOFAServerless 研发运维体系，主要的核心思路是：\n 研发运维力度的细化 通过细化的方式，让多人协作之间不互相 block；\n迭代的范围变小，速度变快。\n 屏蔽基础设施 屏蔽基础设施，让业务开发同学只关注代码服务和流量。\n对于这两点，我们采用了 SOFAArk ClassLoader 类隔离和热部署能力，将应用拆分成基座和模块。\n基座和模块 从这张图里面可以看到我们拆分的形态，把一个普通的 JVM 应用拆出多个模块，进一步对模块进行了一些分工：基座和模块，对应的研发人员也分为基座开发者和模块开发者。\n基座沉淀通用的逻辑，为模块提供计算和环境，并会模块开发者屏蔽基础设施，让模块开发者不需要关心容量、资源、环境。各个模块是独立的代码仓库，可以进行独立的研发运维，这样研发运维粒度得到细化，并且由于基座为模块屏蔽了环境与基础设施，模块开发者可以专注业务开发，提高整体效率。\n如何共享和通信 应用如果只是做拆分，没有共享和通信能力是不完整的方案也难以解决实际问题。对于共享和通信，基座作为共享的一层，能帮模块预热 RPC 数据库缓存通用类、通用方法、通用逻辑，可以供安装一些模块去复用。这样模块实现的比较轻，所以模块的部署密度也可以做得很高。\n对于模块通信，当前模块之间的通信可以支持任意的通信方式，比如说基座调模块、模块调基座模块和模块之间调用。由于模块通信是 JVM 内跨 ClassLoader 调用，与普通 JVM 内方法调用增加了序列化与反序列化的开销，目前这部分开销已经优化到约等于 JVM 内部的方法调用。\n在这一能力建设之后，可以较大降低模块的接入改造成本并扩大可适用的业务范围。\n如何解决业务痛点 管理成本\n相较于原来的研发模式，研发人员拆分成不同小组，代码仓库也拆分出多个模块仓库，并且可以独立并行的发布到线上，整个 pipelien 都可以做到独立进行。\n如此一来，需求管理、代码管理、人员管理的成本就得到下降了，线上发布过程中也不会再有互相阻塞的问题存在。\n当然这些成本下降不代表这些问题完全没有了，只是从原来的指数增长转变成了这种线性增长。随业务的复杂度不断增加，它的收益会更加的明显。\n时间成本 相对于普通应用的镜像构建需要 3 分钟，发布需要镜像下载、启动、挂载流量大概 3 分钟，总共平均需要 6 分钟；模块构建只需要 10 秒，启动大概 1~10 秒 （模块大小可大可小，对于较小的模块，速度可以做到毫秒级别） 。\n把一次发布耗时从原来的 6 分钟下降到 15 秒，一次迭代从原来 2 周下降到了 2 天，最快可以 5 分钟上线的。\n可扩展性 对于线上集群的部署形态，不同的机器上部署的模块不尽相同。例如对于模块 1，只安装在了第一第二台机器上，那么模块升级时只会涉及到这两台机器本身，变更的机器范围就比较小了。另外，模块 1 如果要扩容的话，可以从集群内筛选出较空闲的机器进行模块热部署即可，一般也就是 10s 级别，所以能做大快速的水平扩展能力。\n变更风险 对于一次模块的升级变更，只会涉及模块自身的代码本身不会设计整个应用代码。模块变更需要更新的机器也只是模块安装过的机器本身，不会涉及到整个集群，所以变更范围大大缩小，变更风险也相较普通应用能得到明显减少。\n高可用和配套能力 SOFAServerless 体系在解决业务研发运维痛点基础上，建设了高可用和配套的能力。\n资源隔离 资源隔离体现在单个 JVM 内部的，这里采用了我们公司内部 AliJDK 多租户隔离能力，每一个模块可以指定自己的资源使用的上限。\n比如说，其中一个模块的逻辑有一些问题，消耗的资源比较大，不会影响到其他的模块，相当于得到了故障的隔离。\n流量隔离能力 对于单个集群内部，我们做了一些精细化的流量路由。主要是因为发服务时能够动态增加 tag，流量路由时能够配一些规则，推送到 MOSN、Layotto 里，能让流量根据对应的 tag 进行一些精细化路由，这样就具备了流量的精细化路由和流量隔离能力。\n可观测性能力与变更防御能力 具备模块粒度的健康检查、资源监控、日志监控还有排障能力，在此基础上建设模块粒度的变更防御。\n一个模块可以同时存在多个版本，可以做一些快速的 A/B 测试、灰度、回滚这些能力。\nPART. 3 业务的落地形态** SOFAServerless 发展到现在，已经在蚂蚁内部接入了 700 多个 Java、nodejs 应用，基本涵盖了蚂蚁所有业务线，支撑了 1 万多次的完整的生产研发迭代。线下可以做到秒级发布，支付宝应用内很多业务就是跑在 SOFAServerless 上的，比如投放展位、公益游戏、营销玩法。\n去年 SOFAServerless 成功支撑了 618、双 12、五福等重量级大促和活动，经受住了大流量高并发场景下的考验，托管在 SOFAServerless 的资 …","date":1652166000,"description":"SOFAServerless 体系助力业务极速研发","dir":"blog/sofaserverless-system-for-speedy-business-development/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"760d9079310bd5202d52c369c1603bec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","publishdate":"2022-05-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","summary":"文｜赵真灵（花名：有济）蚂蚁集团技术专家、刘晶（花名：飞廉） 蚂蚁集团技术专家 以下内容整理自 SOFAStack 四周年的分享 本文 5332 字 阅读 10 分钟 SOFAServerless 研发运维平台是蚂","tags":["SOFAStack"],"title":"SOFAServerless 体系助力业务极速研发","type":"blog","url":"/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","wordcount":5533},{"author":"范明柯","categories":"SOFAStack","content":" 前言 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析\n 一、架构流程图 二、订阅流程 以客户端首次订阅，且服务发布方已注册的场景为例，订阅流程主要分为三步，\n 客户端发起订阅 session server 处理订阅任务，从缓存（或 data server）拉取地址列表 向客户端推送地址列表 2.1 客户端发起订阅 客户端发起订阅的方式是异步的，首先将订阅注册的任务添加到客户端的内存队列中。\n2.2 session server 处理订阅请求 session server 接收到订阅注册任务后，主要是通过 SessionRegistry#regsiter 方法处理的，判断当前是服务消费方，添加到订阅者缓存中； case SUBSCRIBER: Subscriber subscriber = (Subscriber) storeData; // if (!sessionInterests.add(subscriber)) { break; } sessionRegistryStrategy.afterSubscriberRegister(subscriber); break; 触发RegProcessor#fireOnReg方法，将订阅者放入buffer中，参考源码如下： boolean fireOnReg(Subscriber subscriber) { final String dataInfoId = subscriber.getDataInfoId(); // 从若干个BufferWorker数组找到其中一个 BufferWorker worker = indexOf(subscriber.getDataInfoId()); // 将dataInfoId和subscriber存到BufferWorker线程中的subMap中 // subMap的key为dataInfoId，value为SubBuffer SubBuffer buffer = worker.subMap.computeIfAbsent(dataInfoId, k -\u0026amp;gt; new SubBuffer()); return buffer.add(subscriber); } 2.3 session server 拉取地址列表 BufferWorker 线程循环处理 map 缓存中的订阅注册任务，处理流程如下：\n 从 worker 的 subMap 取出所有 dataInfoId 和订阅者列表，并对每个 dataInfoId 分别处理 通过 RegProcessor#processBuffer 方法处理每个 dataInfoId 和对应的订阅者 int processBuffer(Ref ref, int hitSize) { List\u0026amp;lt;Subscriber\u0026amp;gt; subscribers = Lists.newArrayListWithCapacity(hitSize); for (Map.Entry\u0026amp;lt;String, Subscriber\u0026amp;gt; e : ref.subscriberMap.entrySet()) { final Subscriber sub = e.getValue(); // 若订阅者已经推送过，直接忽略 if (!sub.hasPushed()) { subscribers.add(sub); } // 这里因为subscriberMap是引用，没有锁保护，所以sub可能已经被新的subscriber替换掉 // try to remove the sub, but subs maybe changes ref.subscriberMap.remove(sub.getRegisterId(), sub); } if (!subscribers.isEmpty()) { // 从缓存中获取dataInfoId的地址列表，并推送给subscribers regHandler.onReg(ref.dataInfoId, subscribers); } // 返回推送地址列表的订阅者数量 return subscribers.size(); } 通过 FirePushService#getDatum 方法从缓存中获取地址列表。该缓存使用 Guava Cache 的LoadingCache，当缓存中没有 dataInfoId 的地址列表时，会自动从 data server 获取地址列表，并放在缓存中。\n 通过 FirePushService#processPush 方法将地址列表推送给所有订阅者\n 首先通过 firePush 方法将 PushTas k放入 buffer 等待 PushTaskBuffer.BufferWorker 线程异步处理任务 2.4 session server 推送地址列表 PushProcessor 初始化时默认创建 4 个 PushTaskBuffer.BufferWorker 线程； BufferWorker 线程循环执行 watchBuffer 方法，将 worker 中缓存的过期任务删除后进行处理，具体逻辑见下边源码； int watchBuffer(BufferWorker worker) { int bufferedSize = worker.bufferMap.size(); if (bufferedSize \u0026amp;gt;= MAX_BUFFERED_SIZE) { LOGGER.warn(\u0026amp;quot;arrived max buffered size: buffered={}\u0026amp;quot;, bufferedSize); } // 获取推送任务 List\u0026amp;lt;PushTask\u0026amp;gt; pending = worker.transferAndMerge(); int count = 0; for (PushTask task : pending) { // 将任务放进线程池执行 if (task.commit()) { count++; } } if (pending.size() \u0026amp;gt; 0 || count \u0026amp;gt; 0) { LOGGER.info(\u0026amp;quot;buffers={},commits={}\u0026amp;quot;, pending.size(), count); } return count; } 推送地址列表给客户端。 三、发布流程 服务发布流程主要分为下面5步：\n 客户端服务注册 session server 处理服务发布请求 data server 保存服务注册数据，并生成数据变更通知 session server 接收数据变更通知，拉取数据 session server 推送地址列表 3.1 服务注册 客户端进行发布注册，与上面客户端订阅的逻辑一样，都是先将请求放在队列里，等待异步处理，此处不再赘述。\n3.2 session server 处理服务发布请求 SessionRegistry#register 方法判断请求来自服务发布方； …","date":1652079600,"description":"源码解析｜发布订阅推送","dir":"projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","fuzzywordcount":3100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"981d3695a0bbf202fbb64b22687b1f25","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","publishdate":"2022-05-09T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","summary":"前言 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析 一、架构流程图 二、订阅流程 以客户端首次订阅，且服务发布方已注册的场景为例，订阅流程主要分为三步， 客户端发起订","tags":["“源码解析”"],"title":"源码解析｜发布订阅推送","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","wordcount":3020},{"author":null,"categories":"SOFA Weekly","content":" 开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2022 年，SOFAStack 和 MOSN 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2022”，为大家准备了六个任务，涉及 Cloud Native、Micro Service、Distributed System、Kubernetes、Container 等多个领域。\n活动规则 进入：https://summer-ospp.ac.cn/#/homepage\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\n项目任务 1.SOFARegistry 客户端负载均衡\nSOFARegistry 的客户端目前采用长连接与其中一台 Session 相连，随后会用这根链接注册和订阅服务，在注册中心进行运维期间，客户端会断链重连到别的机器上，经过一轮滚动升级，就会造成 Session 上链接分布的不均衡，一是数据不均衡，二是推送压力不均衡，严重的时候会造成单机热点，影响推送的效率。\n由于长连接快速检测节点宕机的机制，主动断链会造成节点数据下线，因此客户端链接的稳定性也是一个很重要的考虑。\n对服务发现来说，发布和订阅对链接稳定性的要求不同：\n 对发布，链接断开会造成服务数据下线\n 对订阅，会造成轻微的数据推送延迟，延迟时间通常是重连间隔\n 项目社区导师：dzdxdzidaxie@gmail.com\n2.增强 layotto-java-sdk 和 layotto-spring-boot\n项目编号：2295a0213\n任务难度：基础/Basic\n1.增强 Layotto 的 java-sdk 的功能，使其与 go-sdk 对齐。现在的 java-sdk 有 file、lock、pubsub、sequencer、state 的 API，缺少 secret、config 等 API。\n 完善 layotto-sdk-springboot, 将 Layotto 的更多功能集成进 spring-boot。layotto-sdk-springboot 的设计目标是帮助 spring-boot 的用户低成本接入 Layotto，比如用户在代码中添加一个 Java 注解后，就能方便的进行消息监听、收到新消息后自动调用方法。\n 在 layotto-sdk-springboot 的基础上，开发 layotto-sdk-sofaboot, 方便 SOFABoot 用户使用 Layotto。\n 项目社区导师：张立斌1098294815@qq.com\n3.Layotto 中实现 ceph 文件系统，同时打通 SOFABoot\n项目编号：2295a0214\n任务难度：基础/Basic\n用 ceph 实现 Layotto 的 file API 组件，并通过 SOFABoot 调通。\n 首先熟悉 Layotto 的架构设计，基于现在的 file 接口实现 ceph 文件系统。（此处需要调研 Layotto 的 file 组件的可移植性以及 ceph 文件系统，判断当前的 Layotto 接口能否满足 ceph 文件系统）\n 通过 SOFABoot 和 Layotto 打通，可以通过 SOFABoot 应用调通 Layotto 的 file 接口。\n 项目社区导师：wenxuwanwangwx_junction@163.com\n4.SOFATracer upgrade opentracing api version \u0026amp;amp; adapter opentelemetry api\n项目编号：2295a0196\n任务难度：进阶/Advanced\nCurrently, sofa-tracer relies on the openTracing version 0.22.0. This version has been out of date for a long time and we need to update to the official recommended stable version. In addition, we need to provide an API layer to accommodate OpentElemetry.\nTasks:\n1、upgrade opentracing version torelease-0.33.0\n2、adapter https://opentelemetry.io/docs/migration/opentracing/\n3、provide intergration doc and guides\n项目社区导师：卫恒（宋国磊）glmapper_2018@163.com\n5.为 MOSN 适配社区 Proxy-Wasm v2 开源规范\n项目编号：22f080190\n任务难度：进阶/Advanced\nWebAssembly(Wasm) 是近几年从 Web 领域诞生，并快速出圈的一项虚拟机指令格式，是一种可移植的、语言无关并兼容 Web 的全新格式，支持在浏览器和非 Web 环境运行不同语言编写的应用程序。\nMOSN 是一款主要使用 Go 语言开发的网络代理 (类似 Envoy、Nginx)，融合了大量云原生通用插件，为服务提供了多协议、模块化、智能化、安全的代理能力。\n如何为这些插件提供一个安全隔离的运行环境，甚至支持不同语言编写的插件，成为了一个非常具有挑战性的课题。Wasm 技术和 Proxy-Wasm 规范的诞生为解决上述问题提供了一种全新的思路。\n本题目将基于 MOSN 中已有的 Wasm 框架，适配开源社区专门为网络代理场景提出的 Proxy-Wasm v2 规范，使 MOSN 具备运行符合 v2 规范的 Wasm 插件的能力。\n项目社区导师：叶永杰yongjie.yyj@antgroup.com\n6.Layotto 集成 Istio\n项目编号：22f080198\n任务难度：进阶/Advanced\n1.Istio 是 ServiceMesh 方向上一个非常火热的解决方案，默认使用 envoy 作为数据面。\n MOSN 作为一个对标 envoy 的另一种数据面实现，也可以跟 Istio 集成，作为 envoy 的一种替代方案。\n Layotto 作为 Application Runtime 的一种实现，基于 MOSN 开发，期望可以结合 Service Mesh 跟 Application Runtime 两种思想。\n 既然 Istio 可以集成 MOSN ，且 Layotto 跟 MOSN 是一体的，因此本次的任务是把 Layotto 作为数据面跟 Istio 进行集成，以服务调用为例，在应用通过 Layotto …","date":1651906800,"description":"【2022 开源之夏】欢迎报名 SOFAStack 社区和 MOSN 社区项目！","dir":"blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"38cfc44c56af96fa7b7700c470ce5931","permalink":"https://sofastack.github.io/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","publishdate":"2022-05-07T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["SOFA Weekly"],"title":"【2022 开源之夏】欢迎报名 SOFAStack 社区和 MOSN 社区项目！","type":"blog","url":"/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","wordcount":2100},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@尚之 提问：\n SOFARegistry 和应用绑定有多深，Serverless 场景下有没有更动态的方案和应用解绑？\n A：其实不需要和应用进行绑定，更准确的说法是节点级的服务发现，就算应用下面每个节点之间发布的服务不一样，应用级的这个方案也是可以支持的。而且目前蚂蚁的 Serverless 的场景实际上已经是应用级了，只是对于业务 owner 没有感知。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@沄澈|che 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?\n A：要看 SerializerFactory 对 Localdatetime 的支持了。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 MOSN 1.0 发布，开启新架构演进\n HAVE FUN | SOFABoot 源码解析活动\n SOFARegistry 源码｜数据分片之核心-路由表 SlotTable 剖析\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1651820400,"description":"SOFA Weekly | 神奇技术、本周贡献者、新手任务","dir":"blog/sofa-weekly-20220506/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d89becc4edace0dc4e93d5a8b39f9e61","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220506/","publishdate":"2022-05-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220506/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 神奇技术、本周贡献者、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220506/","wordcount":1010},{"author":"周书伟","categories":"SOFAStack","content":" 源码解析：无损运维 SOFARegistry 是一个基于内存存储的分布式注册中心，数据是分散存储在各个节点，为了做到注册中心自身运维期间依然能够对外正常提供服务，需要进行节点下线快速感知和数据迁移。\n session 存储 client 发送的发布和订阅数据，由于 client 断连重放的特性，session 单机下线后 client 会重放数据到其他节点。\n data 会接收 session 发送的发布数据，data 单机下线后，meta 会通过 SlotTable 的变更把对应 Slot 的所有权移交其他 data，data 启动后会进行数据同步到达数据完整可对外提供服务的状态。\n session、data下线的过程，如何避免下线期间数据丢失和抖动 SessionServer 和 DataServer 下线的相关代码都位于各自 bootstrap 类的 dostop 方法中。\n首先讨论 SessionServer 的下线过程：\nprivate void doStop() { try { LOGGER.info(\u0026amp;quot;{} Shutting down Session Server..\u0026amp;quot;, new Date().toString()); stopHttpServer(); clientNodeConnectionHandler.stop(); // stop process disconnect event stopServer(); // stop http server and client bolt server before add blacklist // make sure client reconnect to other sessions and data gracefulShutdown(); stopDataSyncServer(); stopConsoleServer(); executorManager.stopScheduler(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Shutting down Session Server error!\u0026amp;quot;, e); } LOGGER.info(\u0026amp;quot;{} Session server is now shutdown...\u0026amp;quot;, new Date().toString()); } 从代码中可以看出，SessionServer 服务在下线时，首先会停掉 HttpServer，HttpServer 提供一系列 REST 接口，用于 dashboard 管理、数据查询等；然后停掉 clientNodeConnectionHandler，clientNodeConnectionHandler 是 Exchange 设置的一系列 ChannelHandler 之一，Exchange 作为 Client / Server 连接的抽象，负责节点之间的连接。gracefulShutdown 方法则是通知 Meta（元数据服务器）将本节点加入 Meta 的黑名单中。HttpServer 和客户端的 bolt Server 是在本节点加入黑名单前关停，以保证 client 已经重连到了其他 session 节点上。这样就保证了运维的 session 节点下线期间，client 的数据不会因为 session 节点的不可用，导致数据丢失和抖动。接下来又依次关停了 DataSyncServer，ConsoleServer。\nDataServer 下线过程的代码如下：\nprivate void doStop() { try { LOGGER.info(\u0026amp;quot;{} Shutting down Data Server..\u0026amp;quot;, new Date().toString()); gracefulShutdown(); stopHttpServer(); stopServer(); stopDataSyncServer(); stopNotifyServer(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Shutting down Data Server error!\u0026amp;quot;, e); } LOGGER.info(\u0026amp;quot;{} Data server is now shutdown...\u0026amp;quot;, new Date().toString()); } DataServer 的下线则和 Session 的下线有些区别，由于 DataServer 数据服务器，负责存储具体的服务数据，而且 Slot 均匀地分配给每个节点上，所以下线前需要检测 DataServer 上的插槽状态，所以 doStop 的方法中，首先调用了如下的优雅下线的方法，其中代码中的主要内容如下：\naddBlacklistRetryer.call( () -\u0026amp;gt; { LOGGER.info(\u0026amp;quot;[GracefulShutdown] add self to blacklist\u0026amp;quot;); metaServerService.addSelfToMetaBlacklist(); return true; }); addBlacklistRetryer.call( () -\u0026amp;gt; { if (fetchStopPushService.isStopPushSwitch()) { return true; } SlotTableStatusResponse statusResponse = metaServerService.getSlotTableStatus(); if (statusResponse.isProtectionMode()) { return true; } LOGGER.info(\u0026amp;quot;[GracefulShutdown] wait no slot\u0026amp;quot;); if (slotManager.hasSlot()) { throw new RuntimeException(\u0026amp;quot;current data server still own slot, waiting...\u0026amp;quot;); } return true; }); LOGGER.info(\u0026amp;quot;add data self to blacklist successfully\u0026amp;quot;); 首先节点通知 Meta 加入黑名单，stopmetaServerService.getSlotTableStatus() 获取节点上 SlotTable 的状态，当 Slot 重新分配给其他节点后，该 Data 节点才会成功加入黑名单，并进行接下来 HttpServer、DataSyncServer、NotifyServer 的下线动作。\n整体流程是 Data 上的 Slot 逐步迁移，期间仍然对外提供服务。\n迁移完成后主动从列表中剔除并设置节点黑名单并下线。\n以下图为例，假设要下线的节点是 DataServer-1： …","date":1651820400,"description":"源码解析｜无损运维","dir":"projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ffe7f76f483d5fbc2827a237b6c48093","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","publishdate":"2022-05-06T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","summary":"源码解析：无损运维 SOFARegistry 是一个基于内存存储的分布式注册中心，数据是分散存储在各个节点，为了做到注册中心自身运维期间依然能够对外正常提供服务，需要","tags":["“源码解析”"],"title":"源码解析｜无损运维","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","wordcount":3684},{"author":"朱德江","categories":"SOFAStack","content":" 文｜朱德江（花名：人德）\n蚂蚁集团技术专家 负责 MOSN 核心开发，关注云原生流量网关的演进\n以下内容整理自 SOFAStack 四周年的分享\n本文 5332字 阅读 10 分钟\nMOSN 1.0 发布 MOSN 是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源，经过双 11 大促几十万容器的生产级验证。\n经过 4 年的蓬勃发展，在 11 位 commiter，100 多个 contributor 和整个社区的共同努力下，经历 27 个小版本的迭代，MOSN 1.0 版本正式发布了。\n一个足够成熟稳定，有开源用户共建、有商业化落地、有社区，拥抱云原生生态的 MOSN 1.0 来了。\n除了在蚂蚁集团的全面落地，MOSN 在业界也有较广泛的应用，比如有工商银行的商业化落地，还有阿里云、去哪儿网、时速云等企业的生产实践。\n同时，随着 1.0 的发布，进入少年期的 MOSN 也将开启新一代 MOE 架构演进，奔向星辰大海。\n发展历史 MOSN 起源于 Service Mesh，原本在微服务之间的调用是通过比较重的 SDK 来完成的，当 SDK 升级的时候，需要应用配合一起升级，有比较强的打扰。\nMOSN 为了解决这一痛点，向着把 SDK 剥离出来的方向演进。在应用所在的 Pod 内，单独有一个运行 MOSN 的 sidecar，那么应用本身只需要跟 MOSN 去通讯，就可以完成整个的服务调用的流程。把 SDK 剥离出来，相当于 MOSN 作为一个独立的组件去演进，其演进过程对应用本身没有打扰。这在蚂蚁内部的收益其实是非常明显的。\n在整个演进的过程中，有两个比较深的体会：一个比较明显的是，有一个独立的 sidecar，可以去跟业务逻辑做解耦；另外一个标准化，在云原生的时代里，控制面和数据面被拆分为两个独立的组件，MOSN 作为数据面的组件，演进过程中要跟很多控制面的服务对接，这期间标准化是一个很重要的。在整个标准化的过程中，它并不像业务解耦那么直观，但是用的时间越长，对其越深有体会。\n现在 MOSN 已经在蚂蚁内部全面的铺开，部署有几十万 Pod，峰值 QPS 千万级。\nMOSN 的演进历程 2018 年： 开始创建；\n2019 年： 在双 11 完成了核心链路的覆盖，在 19 年底的时候，MOSN 开始独立运营；\n2020 年： 7 月份获得 Istio 官方的推荐。同时，MOSN 开启了商业化的探索，年底完成了江西农信的落地；\n2021 年： 对接了 Envoy、Dapr、WASM 生态，和主流的社区合作。同年 12 月份， 在工商银行完成了商业化的落地，树立了业界新标杆。\nMOSN 除了在蚂蚁内部全面铺开，以及商业化的落地实践，还有逐渐完善的社区。MOSN 社区目前有 11 个 Committer，其中超过 70% 是非蚂蚁的 Committer，有 100 多位的 Contributor，经过了 28 个小版本的迭代。MOSN 还有很多开源的用户，他们将 MOSN 在自己公司落地，也对 MOSN 有很多的贡献。\n社区除了在 MOSN 项目的贡献之外，还有对其他项目/社区的贡献，包括Holmes、BabaSSL、Proxy-Wasm 等项目，以及跟其他生态项目的对接。\n总体来说，MOSN 现在足够成熟稳定，有商业化的落地，有社区、有周边、有生态，所以我们选择这个时间点发布 MOSN 1.0 版本。\n1.0 的核心能力以及扩展生态 MOSN 1.0 版本标志性的成果是已经集成了 Istio 的 1.10 版本。\nMOSN 作为网络代理的软件，在核心转发方面已经支持了 TCP、UDP、透明劫持的模式。MOSN 所处在东西向网关场景下，有很多内部的、私有的非标协议，MOSN 除了支持 HTTP 标准协议以外，还有很重要的 XProtocol 框架，可以非常简单、方便支持私有的非标协议，内置的 Bolt、 Dubbo 协议，也是通过 XProtocol 框架来实现的。我们还支持了多协议的自动识别，也是在东西向流量网关里面比较核心的、比较特别的能力支持。\n后端管理和负载均衡是在网络代理情况下，比较基本的常规能力。MOSN 也支持了连接池、主动健康检查、各种各样的负载均衡的策略。\n在核心路由上，MOSN 支持基于 Domain 的 VirtualHost，引入了一个非常强大的变量支持，通过变量做复杂的路由规则，也支持了 Metadata 的分组路由。还有路由级别的超时、重试的配置，以及请求头、响应头的处理。\n简单来说，作为一个网络代理的平台，通用的核心能力 MOSN 都已经完全具备了。\n同时在网络代理的场景，通常需要做很多扩展，MOSN 的扩展生态做到了什么样的程度了呢？\nRPC 协议： 有 Dubbo 和 SOFABolt 的支持，同时基于 BabaSSL 做了国密的支持；\n控制面： MOSN 已经做了 Istio 的支持；\n注册中心： SOFARegistry；\n可观测性：Skywalking 以及 Holmes 针对 Go 运行时期间，资源使用异常的自动分析和诊断。\n在网关场景里，有很多的逻辑是需要做定制的。除了常规的用 Go 写一些 filter 扩展之外，还支持 Go Plugin 这种轻量级的模式，也支持 Proxy-Wasm 标准的 Wasm 扩展运行在 MOSN 中，服务治理方面也对接了 Sentinel。\nIstio 1.10 MOSN 会通过标准的 xDS 协议和 Istio 通讯，这是一个非常标准的使用方式，同时我们也在积极的参与标准的建设。\n我们在标准的制定过程中，积极提案参与讨论，比如说限流的和路由的 proto，也正是我们和 Istio 有非常多的合作，才能够获得 Istio 官方的推荐。\nMOSN 起源于 ServiceMesh 东西向流量的场景，我们经过了四年的努力，选择在今天这个时间点发布 MOSN 1.0 版本，作为一个成熟稳定、有商业化落地、有社区、有生态的一个版本呈现出来，我们欢迎更多的人来使用 MOSN，也欢迎大家一起来共建和成长。\n二、MoE 新架构 做这个的愿景初衷是什么？\n这样做的优势是什么？\nMoE 新架构的探索有什么新的进展？\n首先 Enovy 和 MOSN 是作为目前市面上的两个数据面，它们都各有特点， Enovy 是 C++写的，处理性能会比较高。MOSN 的研发性和效能高，有很好的生态。\nMoE 就是 MOSN 加 Enovy。我们希望能够做把两者的优势给融合起来，相互融合，各取所长，把高性能和高研发效能结合到一起，支持我们做大做强，走得更远。\nMoE 架构在 Enovy 的角度来看，MOSN 作为 Enovy 的一个插件扩展，在所有的 Enovy 的扩展方式里面，做一个横向的对比。\n1.首先第一个是 Lua\n嵌入式的脚本语言有比较强的优势，它操作简单。但是作为相对小众的语言，劣势也很明显——生态不好。我们目的是为了提高研发效能， Lua 无法让我们达到目标。\n2.WASM 是比较诱人的方案\nWASM 在发展初期，有很多东西还只是停留在愿景上。很多的语言支持不友好，以及 runtime 性能不够好，这都是很现实的痛点。\n3. …","date":1650956400,"description":"MOSN 1.0 发布，开启新架构演进","dir":"blog/mosn-1-0-released-starting-a-new-architectural-evolution/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6319d8cdb62702760f6c4d04c3f996a7","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","publishdate":"2022-04-26T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","summary":"文｜朱德江（花名：人德） 蚂蚁集团技术专家 负责 MOSN 核心开发，关注云原生流量网关的演进 以下内容整理自 SOFAStack 四周年的分享 本文 5332字 阅读 10 分钟 MOSN 1.0 发布","tags":["SOFAStack"],"title":"MOSN 1.0 发布，开启新架构演进","type":"blog","url":"/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","wordcount":4640},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@黄昊 提问：\n 同一个网格里，不同的 Pod 可以注入不同版本的 Sidecar 吗？\n A：去改 inject 程序可以实现，相关资料可以搜索：K8s准入控制。\n 利用 webhook，动态匹配返回 sidecar-image 是这个意思吗？看代码，貌似 Istio 里面可以通过sidecar.istio.io/proxyImage 这个 annotation 来指定。\n A：是的。\n「MOSN」：https://github.com/mosn\n@service mesh 提问：\n gateway 有开源计划吗？\n A：有考虑，但是目前还没有具体的时间点，可以看下这个初期的 issue，有个demo.\nhttps://github.com/mosn/mosn/issues/1563\n「MOSN」：https://github.com/mosn\n@Tom 提问：\n Wasm 还有啥好玩的待实现的特性吗？\n A：目前关于 Wasm 主要想尝试两个方向：\n 以 Wasm 作为用户开发函数的载体，可以参考下：https://github.com/mosn/layotto/issues/191\n 以 Wasm 作为开发 Layotto 各个组件的载体，可以参考下：https://github.com/mosn/layotto/issues/476\n 第二个应该需要尝试使用 Rust 为 Layotto 的 API 开发一个组件然后编译成 Wasm。\n「Layotto」：https://github.com/layotto\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 金融级应用开发｜SOFABoot 框架剖析\n “SOFA 星球”闯关计划 ——Layotto 飞船\n HAVE FUN | 飞船计划、源码解析活动最新进展\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1650610800,"description":"SOFA Weekly | 年度优秀 Committer 、本周 Contributor、本周 QA","dir":"blog/sofa-weekly-20210422/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a78268fffd513c90682e116743a482e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210422/","publishdate":"2022-04-22T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210422/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 年度优秀 Committer 、本周 Contributor、本周 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210422/","wordcount":1213},{"author":"顾叶宸","categories":"SOFAStack","content":" 前言 某些场景下 SOFARegistry 需要暂时关闭推送功能，这样集群内的业务可以利用 client 的缓存继续工作，比如说 SOFARegistry 需要进行不兼容升级，需要全集群下线，更新版本后再拉起。\n推送开关的状态存储在数据库中，通过 Meta 修改数据后，Session 可以通过读取到推送开关的变更通知，并在对应的推送流程上进行切断。\n本文将聚焦推送开关功能的三个关键问题：\n meta 如何存储开关配置数据。 session 如何获取到开关配置的变更并触发更新（通知、定时）。 session 关闭推送功能的实现。 总体流程 关闭推送的请求，主要由 StopPushDataResource类下的closePush负责处理。我们来看看它的实现：\npublic Result closePush() { boolean ret; Result result = new Result(); // 1.重设灰度推送开关 ret = resetGrayOpenPushSwitch(); if (!ret) { result.setSuccess(false); return result; } PersistenceData persistenceData = PersistenceDataBuilder.createPersistenceData( ValueConstants.STOP_PUSH_DATA_SWITCH_DATA_ID, \u0026amp;quot;true\u0026amp;quot;); try { // 2.重设全局推送开关 ret = provideDataService.saveProvideData(persistenceData); ...... } catch (Throwable e) { ...... } if (ret) { // 3.发送数据变更通知 fireDataChangeNotify( persistenceData.getVersion(), ValueConstants.STOP_PUSH_DATA_SWITCH_DATA_ID); } result.setSuccess(ret); return result; } 可以看到，closePush函数主要做了三件事：\n 重设灰度推送开关 灰度推送开关中，存储着一个 IP 列表。灰度推送允许 SOFARegistry 即使在全局推送关闭的情况下，仍满足特定 IP 的推送请求。因此想要完全关闭推送功能，需要重设该开关，清空其中的 IP 列表。\n 重设全局推送开关 关闭推送功能，需要重设全局推送开关，保存开关配置为关闭的新数据。\n 发送数据变更通知 数据变更通知将告诉 Session，开关配置已经改变，需要进行更新。\nMeta存储开关配置数据 我们以重设全局推送开关中，开关数据的存储为例：\n meta 首先从内存中读取旧的开关配置版本号，并与当前数据版本号进行比较。  只有确定是更新的数据，才会进行后续存储。\n 存储新的开关配置数据，并更新数据库中该数据的版本号。\n 更新内存中的开关配置数据。\n public boolean saveProvideData(PersistenceData persistenceData, long expectVersion) { // 1.比较版本号 if (persistenceData.getVersion() \u0026amp;lt;= expectVersion) { ...... return false; } // 2.更新数据库 boolean success = provideDataRepository.put(persistenceData, expectVersion); if (success) { lock.writeLock().lock(); try { // 3.更新内存 provideDataCache.put( PersistenceDataBuilder.getDataInfoId(persistenceData), persistenceData); } catch (Throwable t) { ...... return false; } finally { lock.writeLock().unlock(); } } return success; } 重设灰度开关中的步骤与之类似，因此这里不再赘述。\nSession 获取开关配置 通知更新 继续上文，closePush会调用fireDataChangeNotify函数，通知外界开关配置发生了更新。\nprivate void fireDataChangeNotify(Long version, String dataInfoId) { ...... if (TASK_LOGGER.isInfoEnabled()) { ...... } provideDataNotifier.notifyProvideDataChange(provideDataChangeEvent); } 这一通知首先会进行判断，是哪一种事件类型。在本例中，开关配置的更新是与 Session 有关的事件。 public void notifyProvideDataChange(ProvideDataChangeEvent event) { Set\u0026amp;lt;Node.NodeType\u0026amp;gt; notifyTypes = event.getNodeTypes(); // 判断事件类型 if (notifyTypes.contains(Node.NodeType.DATA)) { defaultDataServerService.notifyProvideDataChange(event); } if (notifyTypes.contains(Node.NodeType.SESSION)) { defaultSessionServerService.notifyProvideDataChange(event); } } 随后，通知会被交付给 Session 相关的消息交换类，并进行Request请求。 public void notifyProvideDataChange(ProvideDataChangeEvent event) { new NotifyTemplate\u0026amp;lt;ProvideDataChangeEvent\u0026amp;gt;().broadcast(event); } public void broadcast(E event) { ...... getNodeExchanger().request(new NotifyRequest(event, connection, executors)); ...... } 在消息交换类中，系统使用getClientHandlers得到了负责消息响应的handler。 public Response request(Request request) throws RequestException { final URL url = …","date":1650610800,"description":"源码解析｜推送开关","dir":"projects/sofa-registry/code-analyze/code-analyze-push-switch/","fuzzywordcount":2900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"38175885eb9d257b9f176246010b34b3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","publishdate":"2022-04-22T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","summary":"前言 某些场景下 SOFARegistry 需要暂时关闭推送功能，这样集群内的业务可以利用 client 的缓存继续工作，比如说 SOFARegistry 需要进行不兼容升级，需要全集群下线，更新版本后再拉起","tags":["“源码解析”"],"title":"源码解析｜推送开关","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","wordcount":2840},{"author":"SOFA 团队","categories":"周年庆","content":" 概要 活动主题：见证 SOFAStack 社区开源四周年!\n 活动时间： 2022 年 04 月 16 日 （14:00-17:40）\n 活动形式：线上直播\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | 一、宋顺四周年致辞 点击下载资料\n| 二、《蚂蚁服务发现的大规模实践和展望》 讲师：蚂蚁集团技术专家李旭东（花名：向旭）\n点击下载资料\n议题简介\nnaming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。\n蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。\n本次将会分享蚂蚁内部实践经验，以及 naming 在云原生时代下的发展方向及趋势。\n| 三、《蚂蚁集团 Service Mesh 进展回顾与展望》 讲师：蚂蚁集团高级技术专家 石建伟（花名：卓与）\n点击下载资料\n议题简介\n练内功：内部集群规模化扩张带来的技术挑战，长连接膨胀，服务治理智能化演进和人工介入说再见\n定标准：Mesh 化是终点么？应用运行时标准\n建通路：让业务飞速发展的秘诀\n看未来：云原生运行时的下一个五年\n| 四、《MOSN 1.0 发布，开启新一代架构演进》 讲师：MOSN 核心成员 朱德江（花名：人德）\n点击下载资料\n议题简介\n一、MOSN 1.0 发布\n回顾 MOSN 的发展历史、新版本的特性介绍\n二、新架构演进\n发力南北向网关数据面、整合控制面，开源新产品\n| 五、《Ark Serverless 体系助力业务极速研发》 讲师：蚂蚁集团技术专家 赵真灵（花名：有济）\n讲师：蚂蚁集团技术专家刘晶（花名：飞廉）\n点击下载资料\n议题简介\nArk Serverless 技术体系让用户以开发模块（代码块）的方式快速上线新功能，同时让模块开发者不感知机器、环境与容量等基础设施，助力企业实现业务的快速发展。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1650092400,"description":"见证 SOFAStack 社区开源四周年!","dir":"activities/sofastack-four-years-of-open-source/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"08b0bec521b5328d71dcc39370feb260","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofastack-four-years-of-open-source/","publishdate":"2022-04-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofastack-four-years-of-open-source/","summary":"概要 活动主题：见证 SOFAStack 社区开源四周年! 活动时间： 2022 年 04 月 16 日 （14:00-17:40） 活动形式：线上直播 B 站直播间地址：http://live","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFA 四周年，开源正当时！","type":"activities","url":"/sofastack.tech/activities/sofastack-four-years-of-open-source/","wordcount":827},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@ 尚之 提问：\n SOFARegistry 和应用绑定有多深，Serverless 场景下有没有更动态的方案和应用解绑？\n A：其实不需要和应用进行绑定，更准确的说法是节点级的服务发现，就算应用下面每个节点之间发布的服务不一样，应用级的这个方案也是可以支持的。而且目前蚂蚁的 Serverless 的场景实际上已经是应用级了，只是对于业务 owner 没有感知。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@ 黄润良 提问：\n 两个组合为什么不生效呢？按照时间轮转，就不需要管理日志数量了吗？\n A：按照时间轮转还没有支持这个日志数量。\n 按时间轮转的，轮转后的文件名应该是带日期时间字符串的把，配个定制任务清理一下就可以了吗？\n A：我们也是用的这个库，然后根据时间轮转是我们扩展的，我们是统一平台做这个事，就没在 MOSN 里实现。\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto Java-sdk 本周发布 Layotto Java-sdk 发布 v1.1.0 版本，主要变更如下：\n 支持 File API\n 支持 Sequencer API\n 新增 layotto-springboot\n 「发布报告」：https://github.com/layotto/java-sdk/releases/tag/v1.1.0\n本周推荐阅读 HAVE FUN | Layotto 源码解析\n 异构注册中心机制在中国工商银行的探索实践\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1649401200,"description":"SOFA Weekly |开源新知、本周 QA、Layotto Java-sdk 本周发布","dir":"blog/sofa-weekly-20220408/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c70e2662ec9434d8229f900636d39af1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220408/","publishdate":"2022-04-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220408/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |开源新知、本周 QA、Layotto Java-sdk 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220408/","wordcount":1202},{"author":"行动","categories":"SOFAStack","content":" SOFARegistry 对于服务数据是分片进行存储的，因此每一个 data server 只会承担一部分的服务数据，具体哪份数据存储在哪个 data server 是有一个称为 SlotTable 的路由表提供的，session 可以通过 SlotTable 对对应的 data derver 进行读写服务数据， slot 对应的 data follower 可以通过 SlotTable 寻址 leader 进行数据同步。\n维护 SlotTable 是由 Meta 的 leader 负责的，Meta 会维护 data 的列表，会利用这份列表以及 data 上报的监控数据创建 SlotTable，后续 data 的上下线会触发 Meta 修改 SlotTable， SlotTable 会通过心跳分发给集群中各个节点。\n1. DataServer 更新SlotTable 路由表过程。 如上图所示 session 和 data 节点定时会向 Meta 节点上报心跳、Meta节点维护了 data 以及 session 节点列表信息、并且在心跳请求中将返回 SlotTable 路由表信息、data 节点将路由表 SlotTable 保存在本地中。\n2. SlotTable 更新平衡算法 由前文可知、SOFARegistry 采用了数据分片存储在 DataServer 节点之上、那么随之而来的问题就是数据如何分片呢?\nSOFARegistry 采用预分配的方式。\n传统的一致性 Hash 算法有数据分布范围不固定的特性，该特性使得服务注册数据在服务器节点宕机、下线、扩容之后，需要重新存储排布，这为数据的同步带来了困难。大多数的数据同步操作是利用操作日志记录的内容来进行的，传统的一致性 Hash 算法中，数据的操作日志是以节点分片来划分的，节点变化导致数据分布范围的变化。\n在计算机领域，大多数难题都可以通过增加一个中间层来解决，那么对于数据分布范围不固定所导致的数据同步难题，也可以通过同样的思路来解决。\n这里的问题在于，当节点下线后，若再以当前存活节点 ID 一致性 Hash 值去同步数据，就会导致已失效节点的数据操作日志无法获取到，既然数据存储在会变化的地方无法进行数据同步，那么如果把数据存储在不会变化的地方是否就能保证数据同步的可行性呢？答案是肯定的，这个中间层就是预分片层，通过把数据与预分片这个不会变化的层相互对应就能解决这个数据同步的难题。\n目前业界主要代表项目如 Dynamo、Casandra、Tair、Codis、Redis cluster 等，都采用了预分片机制来实现这个不会变化的层。\n事先将数据存储范围等分为 N 个 slot 槽位，数据直接与 slot 相对应，数据的操作日志与相应的 solt 对应，slot 的数目不会因为节点的上下线而产生变化，由此保证了数据同步的可行性。除此之外，还需要引进“路由表”的概念，如图 13，“路由表”负责存放每个节点和 N 个 slot 的映射关系，并保证尽量把所有 slot 均匀地分配给每个节点。这样，当节点上下线时，只需要修改路由表内容即可。保持 slot 不变，即保证了弹性扩缩容，也大大降低了数据同步的难度。\n实际上上述 Slot 和 **节点 **的映射关系在源码中以 **SlotTable 和 Slot **的方式进行表达。源码如下代码块所示。\npublic final class SlotTable implements Serializable { public static final SlotTable INIT = new SlotTable(-1, Collections.emptyList()); // 最后一次更新的时间 epoch private final long epoch; //保存了 所有的 slot 信息； slotId ---\u0026amp;gt; slot 对象的映射 private final Map\u0026amp;lt;Integer, Slot\u0026amp;gt; slots; } public final class Slot implements Serializable, Cloneable { public enum Role { Leader, Follower, } private final int id; //当前slot的leader节点 private final String leader; //最近更新时间 private final long leaderEpoch; //当前slot的follow节点 private final Set\u0026amp;lt;String\u0026amp;gt; followers; } 由于节点在动态变化中、所以 Slot 和 节点的映射也在时刻变化中、那么我们接下来的重点就是 SlotTable 的变更过程。SlotTable 的变更是在 Meta 节点中触发、当有服务上下线的时候会触发SlotTable 的变更、除此之外也会定期执执行 SlotTable的变更。\nSlotTable的整个同步更新步骤如图所示。\n代码参考 com.alipay.sofa.registry.server.Meta.slot.arrange.ScheduledSlotArranger#arrangeSync.\nSlotTable 的定期变更是通过在初始化 ScheduledSlotArranger 时候实例化守护线程不断的 定期执行 内部任务 Arranger 的 arrangeSync 方法来实现 SlotTable 变更的。大致流程如下所示。\n因为负责 SlotTable 的更新是在 MetaServer 中的主节点更新的。\n所以更新 SlotTable的第一步就是判断是否是主节点。主节点才负责真正的 SlotTable 变更步骤。\n第二步是获取最新的 DataServer 节点，因为 重新分配 SlotTable 本质上是 对 DataServer 节点和 slot 槽位之间的映射关系进行重新分配。所以肯定需要获取到当前正在存活的 DataServer 节点信息，从而方便的对之进行 slot 分配。\n(这里获取正在存活的 DataServer 也就是有和 MetaServer 维持心跳的 DataServer, 底层是从 com.alipay.sofa.registry.server.Meta.lease.impl.SimpleLeaseManager中获取，感兴趣可以查看相关源码) 。\n第三部是分配前置校验，实际上一些边界条件的判断、例如 DataServer 是否为空、 DataServer 的大小是否大于配置的 minDataNodeNum，只有满足这些条件才进行变更。\n第四步 执行 trayArrageSlot 方法、进入到该方法内部之中。\n首先获取进程内部锁、实际上是一个 ReentrantLock，这里主要是为了避免定时任务多次同时执行 SlotTable 的分配工作。\nprivate final Lock lock = new ReentrantLock(); 随后便是根据当前的 Data …","date":1649401200,"description":"源码解析｜SlotTable","dir":"projects/sofa-registry/code-analyze/code-analyze-slottable/","fuzzywordcount":8900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8705a6ead8d88f09270c5c19a3f6e6e6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","publishdate":"2022-04-08T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","summary":"SOFARegistry 对于服务数据是分片进行存储的，因此每一个 data server 只会承担一部分的服务数据，具体哪份数据存储在哪个 data server 是有一个称为 SlotTable 的路由表提供的，sessio","tags":["“源码解析”"],"title":"源码解析｜SlotTable","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","wordcount":8810},{"author":"宋国磊","categories":"SOFAStack","content":" 本篇主要对 SOFARegistry 的数据同步模块进行解析，对于注册中心的概念以及 SOFARegistry 的基础架构不做过多阐述，相关介绍可以见海量数据下的注册中心 - SOFARegistry 架构介绍\n本文主要写作思路大致分为下面 2 个部分：第一部分借助 SOFARegistry 中的角色分类来说明哪些角色之间会进行数据同步，第二部分对数据同步的具体实现进行解析。\nSOFARegistry 的角色分类 如上图，SOFARegistry 包含 4 个角色：\n 角色 说明 Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。 SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。 DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。 MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。 在这 4 个角色中，MetaServer 作为元数据服务器本身不处理实际的业务数据，仅负责维护集群 SessionServer 和 DataServer 的一致列表，不涉及数据同步问题；Client 与 SessionServer 之间的核心动作是订阅和发布，从广义上来说，属于用户侧客户端与 SOFARegistry 集群的数据同步，可以见：https://github.com/sofastack/sofa-registry/issues/195，因此不在本文讨论范畴之内。\nSessionServer 作为会话服务，它主要解决海量客户端连接问题，其次是缓存客户端发布的所有 pub 数据；session 本身不持久化服务数据，而是将数据转写到 DataServer。DataServer 存储服务数据是按照 dataInfoId 进行一致性 Hash 分片存储的，支持多副本备份，保证数据高可用。\n从 SessionServer 和 DataServer 的功能分析中可以得出：\n SessionServer 缓存的服务数据需要与 DataServer 存储的服务数据保持一致 DataServer 支持多副本来保证高可用，因此 DataServer 多副本之间需要保持服务数据一致。 SOFARegistry 中对于上述两个对于数据一致性保证就是通过数据同步机制来实现的。\n数据同步的具体实现 下面主要介绍数据同步的实现细节，主要包括 SessionServer 和 DataServer 之间的数据同步 和 DataServer 多副本之间的数据同步两块。\nSessionServer 和 DataServer 之间的数据同步 SessionServer 和 DataServer 之间的数据同步，是基于推拉结合的机制\n 推：DataServer 在数据有变化时，会主动通知 SessionServer，SessionServer 检查确认需要更新（对比 version） 后主动向 DataServer 获取数据。\n 拉：除了上述的 DataServer 主动推以外，SessionServer 每隔一定的时间间隔，会主动向 DataServer 查询所有 dataInfoId 的 version 信息，然后再与 SessionServer 内存的 version 作比较，若发现 version 有变化，则主动向 DataServer 获取数据。这个“拉”的逻辑，主要是对“推”的一个补充，若在“推”的过程有错漏的情况可以在这个时候及时弥补。\n 关于推和拉两种模式检查的 version 有一些差异，可以详见下面 推模式下的数据同步 和 拉模式下的数据同步 中的具体介绍\n 推模式下的数据同步流程 推模式是通过 SyncingWatchDog 这个守护线程不断 loop 执行来实现数据变更检查和通知发起的。\n// 这里遍历所有的 slot for (SlotState slotState : slotTableStates.slotStates.values()) { try { sync(slotState, syncSessionIntervalMs, syncLeaderIntervalMs, slotTableEpoch); } catch (Throwable e) { SYNC_ERROR_LOGGER.error( \u0026amp;quot;[syncCommit]failed to do sync slot {}, migrated={}\u0026amp;quot;, slotState.slot, slotState.migrated, e); } } 按 slot 分组汇总数据版本。data 与每个 session 的连接都对应一个 SyncSessionTask，SyncSessionTask 负责执行同步数据的任务，核心同步逻辑在com.alipay.sofa.registry.server.data.slot.SlotDiffSyncer#sync\n方法中完成，大致流程如下面时序图所示：\n这上图圈红部分的逻辑第四步，根据 dataInfoId diff 更新 data 内存数据，这里仅处理了被移除的 dataInfoId，对于新增和更新的没有做任务处理，而是通过后面的第 5 -7 步来完成；这么做的主要原因在于避免产生空推送导致一些危险情况发生。\n第 5 步中，比较的是所有变更 dataInfoId 的 pub version，具体比较逻辑参考后面 diffPublisher 小节中的介绍。\n数据变更的事件通知处理 数据变更事件会被收集在 DataChangeEventCenter 的 dataCenter2Changes 缓存中，然后由一个守护线程 ChangeMerger 负责从 dataCenter2Changes 缓存中不断的读取，这些被捞到的事件源会被组装成 ChangeNotifier 任务，提交给一个单独的线程池(notifyExecutor)处理，整个过程全部是异步的。\n拉模式下的数据同步流程 拉模式下，由 SessionServer 负责发起， com.alipay.sofa.registry.server.session.registry.SessionRegistry.VersionWatchDog\n默认情况下每 5 秒扫描一次版本数据，如果版本有发生变更，则主动进行拉取一次，流程大致如下：\n需要注意的是，拉模式对推送流程的补充，这里的 version 是每个 sub …","date":1649228400,"description":"源码解析｜数据同步","dir":"projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b78da7b0c10e92e61edba8aeb05d8bac","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","publishdate":"2022-04-06T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","summary":"本篇主要对 SOFARegistry 的数据同步模块进行解析，对于注册中心的概念以及 SOFARegistry 的基础架构不做过多阐述，相关介绍可以见海量数据下的注册中心 - SOFARegistry 架构介绍 本文主要写","tags":["“源码解析”"],"title":"源码解析｜数据同步","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","wordcount":3696},{"author":"Junlong Liu","categories":"SOFAStack","content":" 文｜Junlong Liu\nShopee Digital Purchase \u0026amp;amp; Local Services Engineering\n本文1743字 阅读 6分钟\n贡献者前言 我是在开发工作过程中了解到 Holmes 的，为了保障系统稳定性需要一个性能排查工具，因此也需要一个保留现场的性能监控工具。当我在网上查询该方面的开源库时，发现可用的并不多。后续找到 MOSN 社区的 Holmes ，发现这个开源库功能基本齐全、扩展性也高，特别是 GCHeapDump 这个业界领先的功能，对解决内存升高的问题十分有用。\n2021 年年末了解到的 Holmes 组件，然后开始了解 Holmes 所在的 MOSN 社区。Holmes 作为性能排查工具，核心功能是及时发现性能指标异常，并对系统进行 Profiling。\n由于 Holmes 还处于萌芽期，除了 Readme 之外的文档资料并不多。还有一些 Holmes 当时不支持的功能，比如动态配置调整与上报。Holmes 当时也还没发布第一个版本，但是自己对这方面也有兴趣和理解，于是在 GitHub 上提了几个 Issue 讨论，社区回复的速度十分快。后续在社区前辈们的指导下提了 PR，也因此通过 Holmes 的代码设计学习到了很多关于开源组件的设计理念。\n因此我决定参与开源社区并贡献代码，以解决实际需求。有了一定的了解和经验之后，通过和人德前辈讨论，总结这样一篇分享文章。\n本文将介绍 Holmes 的使用场景、快速开始案例、多个监控类型、设计原理、扩展功能与如何借助 Holmes 搭建起一套简单的性能排查系统，欢迎大家留言指导。\nHolmes 使用场景 对于系统的性能尖刺问题，我们通常使用 Go 官方内置的 pprof 包进行分析，但是难点是对于一闪而过的“尖刺”，开发人员很难及时保存现场：当你收到告警信息，从被窝中爬起来，打开电脑链接 VPN，系统说不定都已经重启三四趟了。\nMOSN 社区的 Holmes 是一个基于 Golang 实现的轻量级性能监控系统，当应用的性能指标发生了异常波动时，Holmes 会在第一时间保留现场，让你第二天上班可以一边从容地喝着枸杞茶，一边追查问题的根因。\nQuick Start 使用 Holmes 的方式十分简单，只需要在您的系统初始化逻辑内添加以下代码：\n// 配置规则 h, _ := holmes.New( holmes.WithCollectInterval(\u0026amp;quot;5s\u0026amp;quot;), // 指标采集时间间隔 holmes.WithDumpPath(\u0026amp;quot;/tmp\u0026amp;quot;), // profile保存路径 holmes.WithCPUDump(10, 25, 80, 2 * time.Minute), // 配置CPU的性能监控规则 holmes.WithMemDump(30, 25, 80, 2 * time.Minute),// 配置Heap Memory 性能监控规则 holmes.WithGCHeapDump(10, 20, 40, 2 * time.Minute), // 配置基于GC周期的Heap Memory 性能监控规则 holmes.WithGoroutineDump(500, 25, 20000, 100*1000, 2 * time.Minute), //配置Goroutine数量的监控规则 ) // enable all h.EnableCPUDump(). EnableGoroutineDump(). EnableMemDump(). EnableGCHeapDump().Start() 类似于 holmes.WithGoroutineDump(min, diff, abs,max,2 * time.Minute) 的 API 含义为:\n当 Goroutine 指标满足以下条件时，将会触发 Dump 操作。\n当 Goroutine 数大于 Max 时，Holmes 会跳过本次 Dump 操作，因为当 Goroutine 数过大时，Goroutine Dump 操作成本很高。\n2 * time.Minute 是两次 Dump 操作之间最小时间间隔，避免频繁 Profiling 对性能产生的影响。\n更多使用案例见文末的 Holmes 使用案例文档。\nProfile Types Holmes 支持以下五种 Profile 类型，用户可以按需配置。\nMem: 内存分配\nCPU: CPU 使用率\nThread: 线程数\nGoroutine: 协程数\nGCHeap: 基于 GC 周期监控的内存分配\n指标采集 Mem、CPU、Thread、Goroutine 这四种类型是根据用户配置的 CollectInterval，每隔一段时间采集一次应用当前的性能指标，而 gcHeap 时基于 GC 周期采集性能指标。\n本小节会分析一下两种指标。\n根据 CollectInterval 周期采集 Holmes 每隔一段时间采集应用各项指标，并使用一个固定大小的循环链表来存储它们。\n根据 GC 周期采集 在一些场景下，我们无法通过定时的 memory dump 保留到现场。比如应用在一个 CollectInterval 周期内分配了大量内存，又快速回收了它们。此时 Holmes 在周期前后的采集到内存使用率没有产生过大波动，与实际情况不符。\n为了解决这种情况，Holmes 开发了基于 GC 周期的 Profile 类型，它会在堆内存使用率飙高的前后两个 GC 周期内各 Dump 一次 Profile，然后开发人员可以使用 pprof \u0026amp;ndash;base 命令去对比两个时刻堆内存之间的差异。\n根据 GC 周期采集到的数据也会放在循环列表中。\n规则判断 本小节介绍 Holmes 是如何根据规则判断系统出现异常的。\n阈值含义 每个 Profile 都可以配置 min、diff、abs、coolDown 四个指标，含义如下:\n当前指标小于 min 时，不视为异常。\n当前指标大于 (100+diff)100% 历史指标，说明系统此时产生了波动，视为异常。\n当前指标大于 abs (绝对值)时，视为异常。\nCPU 和 Goroutine 这两个 Profile 类型提供 Max 参数配置，基于以下考虑：\nCPU 的 Profiling 操作大约会有 5% 的性能损耗，所以当在 CPU 过高时，不应当进行 Profiling 操作，否则会拖垮系统。\n当 Goroutine 数过大时，Goroutine Dump 操作成本很高，会进行 STW 操作，从而拖垮系统。（详情见文末参考文章）\nWarming up 当 Holmes 启动时，会根据 CollectInterval 周期采集十次各项指标，在这期间内采集到的指标只会存入循环链表中，不会进行规则判断。\n扩展功能 除了基本的监控之外，Holmes 还提供了一些扩展功能：\n事件上报 您可以通过实现 Reporter 来实现以下功能：\n发送告警信息，当 Holmes 触发 Dump 操作时。\n将 Profiles 上传到其他地方，以防实例被销毁，从而导 …","date":1649142000,"description":"社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析","dir":"blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"87409f8ec80db088a42f856f0baf16da","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","publishdate":"2022-04-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","summary":"文｜Junlong Liu Shopee Digital Purchase \u0026amp; Local Services Engineering 本文1743字 阅读 6分钟 贡献者前言 我是在开发工作过程中了解到 Holmes 的，为了保障系统稳定性需要一个性能排查工具，","tags":["SOFAStack"],"title":"社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析","type":"blog","url":"/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","wordcount":2934},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@ 毛晨斌 提问：\n 使用 Layotto 是不是客户端代码需要重新实现，全部调用 Layotto 提供的API？多少正式的项目正在使用 Layotto?\n A：目前蚂蚁的落地用户将客户端 SDK，改成调用 Layotto；现在在搞无侵入方案。\n 开源版服务器端支持哪些中间件，客户端无侵入支持哪些中间件？\n A：1. 已经落地的方案是：将各种中间件的 Java SDK，改成调用 Layotto （比如把 xxx-MQ-sdk 内部逻辑改成调layotto pubsub API，但是对业务代码暴露的接口不变)。业务系统需要升级下 SDK，业务代码不用改。这部分没开源，因为是改内部中间件的 SDK，这些中间件本身没开源。 2. 开源版服务器端支持那些中间件：每类 API 有支持的组件列表。 https://mosn.io/layotto/#/zh/component_specs/sequencer/common 其中 state API、pubsub API 因为复用了 Dapr 的组件，所有 Dapr 组件都支持。https://docs.dapr.io/zh-hans/reference/components-reference/supported-state-stores/\n3.客户端支持哪些：目前有 .net java go 的 Layotto SDK，有个 layotto-springboot 刚合并。SDK 在 https://github.com/layotto\n 关于无侵入方案：后面想把协议转换的事情放到 Layotto 做、让用户接入 Layotto 时不用改客户端 SDK，不过方案还在讨论，最近会写个 proposal。 5.现在还没有现成的客户端无侵入 SDK，老系统接入 Layotto 需要改原来的 SDK。\n「SOFABolt」：https://github.com/sofastack/sofa-boot\n黄润良 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?upstream 的 ip access 日志怎么打印来访日志呢，主要是负载均衡后访问到后段的哪个 IP?\n A：你要在 errorlog 打印吗？你可以配置 accesslog，一个请求一条的。你的 tracelog 也可以打印的。https://github.com/mosn/mosn/blob/master/pkg/log/accesslog.go\n [WARN][downStream]reset stream reason ConnectionTermination[proxy][downstream]processError=downstreamReset proxyld:2204350,reason:ConnectionTermination\n A：downstream 的连接断链了。比如你 curl 访问 MOSN，在 reponse 回复之前 Ctrl+C 终止断链接，MOSN 就会打印这个日志，也就是还没有回复请求，client 就断链了。 然后 client 自己有超时，可能就断链了。\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nHolmes 本周发布 Holmes 发布 v1.0 版本\nHolmes 是 MOSN 社区开源的 go 语言 continous profiling 组件，可以自动发现 cpu、 memory、goroutine 等资源的异常，并自动 dump 异常现场 profile，用于事后分析定位。也支持上传 profile 到自动分析平台，实现自动问题诊断、报警。\n「发布报告」：https://github.com/mosn/holmes/releases/tag/v1.0.0\n「Holmes 原理介绍」：https://mosn.io/blog/posts/mosn-holmes-design/\n本周推荐阅读 HAVE FUN | Layotto 源码解析\n 异构注册中心机制在中国工商银行的探索实践\n Nydus 镜像加速插件迁入 Containerd 旗下\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1648796400,"description":"SOFA Weekly | 开源新知、本周 QA、新手任务","dir":"blog/sofa-weekly-20220401/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b94eecd772ed0839dc842cdafb587990","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220401/","publishdate":"2022-04-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220401/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源新知、本周 QA、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220401/","wordcount":1838},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFAMeetup\u0026amp;amp;木兰技术开放日（云原生专场）\n 活动时间：2022 年 04 月 01 日（周五）09:30-12:00\n 活动形式：线上直播\n 资料下载：\n 《如何建立云原生时代的 DevOps 工具链》\n《在大规模集群中落地 Layotto 这种多运行时架构是一种什么样的体验》\n《云原生多集群治理实践》\n《蚂蚁服务发现的大规模实践与展望》\n活动议程 活动回顾 直播主题：木兰技术开放日\u0026amp;amp;SOFAMeetup（云原生专场）\n直播时间：2022 年 4 月 1 日 上午 9:30\n议题分享：\n《中国木兰社区助力云原生扬帆远航》 王庆 英特尔研发总监、木兰开源社区技术委员会成员\n 嘉宾简介：\n王庆，英特尔软件与先进技术事业部云基础设施软件研发总监、开放基础设施基金会个人独立董事、Linux 基金会下属 SODA 基金会外联委员会主席。木兰开源社区技术委员会成员、中国计算机学会CCF开源发展委员会常务委员。\n曾经参与或领导团队开发 Xen、tboot、Yocto、OpenStack 等开源项目。 目前，他和他的团队正在积极致力于云计算、云原生、边缘计算、网络和存储、以及云性能评估与优化等方向，涵盖 Kubernetes、Containerd、Istio、Envoy、Ceph、Akraino 等等。该团队多年来和业界建立了良好的合作关系，是开源云计算软件的一支中坚力量。\n《如何建立云原生时代的 DevOps 工具链》 刘新 都广科技创始人、建木核心开发者。\n 嘉宾简介：\n刘新，都广科技创始人、建木核心开发者。\n从事软件开发与架构设计工作超过 10 年。 曾在通讯、金融、医疗与云计算等行业担任过首席架构师、技术总监、产品总监和CTO等技术职务。\n个人主要兴趣在分布式架构、DevOps、系统优化、工程质量提升等方面。 目前主要精力在开源建木社区运营并负责后端代码的开发贡献。\n议题简介：\n云原生离不开 DevOps，DevOps 作为云原生架构落地的三驾马车的重要性不言而喻。而 DevOps 的成功实施，往往依赖一组集成化的工具链。那么在当前 DevOps 工具百花齐放的情况下，云原生时代的 DevOps 工具链又应该如何建立呢？\n《在大规模集群中落地 dapr 或 Layotto 这种多运行时架构是什么样的体验》 周群力（目前在蚂蚁集团中间件团队负责 Layotto 项目研发）\n 嘉宾简介：\n周群力（花名：仪式）目前在蚂蚁集团中间件团队负责 Layotto 项目研发\n议题简介：\n随着 Service Mesh 在蚂蚁集团内部的大规模落地，我们逐渐遇到了新的挑战，这让我们迫切的寻找新的解决方案。 Service Mesh 通过引入 sidecar 来简化服务治理，而 dapr 这种“多运行时”项目告诉大家：sidecar 能做的事情远不止于此。\n\u0026amp;ldquo;多运行时\u0026amp;rdquo;这种架构真的有这么好么？会不会太过理想化？\n实际落地时会踩什么坑，怎么解决，最终又能带来什么价值？\n在大规模集群中，落地 dapr或layotto 这种多运行时架构是什么样的体验？\n听众收益：\n了解蚂蚁集团在Service Mesh大规模落地以后遇到的新问题以及对于如何解决这些问题的思考。\n了解“多运行时架构”是什么，解决什么问题 了解目前“多运行时架构”相关开源项目在大规模集群落地时会遇到什么问题，有什么不足，如何解决，以及最终带来什么收益 帮助同样在做“多运行时架构”项目的朋友们躲坑、少走弯路。\n《云原生多集群治理实践》 徐迪 腾讯云技术专家，Clusternet 项目发起人。\n 嘉宾简介：\n腾讯云技术专家，Clusternet 项目发起人。在云原生领域有着丰富的经验，也是国内较早参与 Kubernetes 社区的开发者。热爱开源，拥抱开源，并多次在 KubeCon 各大峰会上发表演讲。\n议题简介：\n在过去的数年里，云计算领域经历了多次巨大的变革，当前越来越多的组织将应用部署在本地和云上的多个基础设施平台上，这些平台可能是两个公共云服务提供商，或者两个私有云，或者多地域的边缘云。新的形态导致基础设施的管理和应用治理的方式发生变化，传统的技术架构与管理方式增加了复杂性和风险，难以满足跨多个平台的应用服务部署和治理的挑战，代表业内最新理念的 Clusternet 项目应运而生。在这次演讲中，你将了解到 Clusternet 的最新进展和先进特性。\n《蚂蚁服务发现的大规模实践与展望》 肖健 目前在蚂蚁集团中间件团队负责 SOFARegistry 项目研发\n 嘉宾简介：肖健（花名：昱恒）目前在蚂蚁集团中间件团队负责 SOFARegistry 项目研发\n议题简介：\nnaming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。\n本次分享将会包含以下内容：\n 蚂蚁内部实践\n naming在云原生时代下的发展方向及趋势\n 总结和展望\n 听众收益：\n 了解蚂蚁集团在SOFARegistry新挑战及云原生时代的思考。\n 了解SOFARegistry实践经验。\n 了解蚂蚁集团对未来naming的思考及naming在云原生方向上的探索。\n 了解未来SOFARegistry的发展和相关的社区动向。\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1648796400,"description":"SOFAMeetup\u0026木兰技术开放日-云原生专场","dir":"activities/sofa-meetup-14/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"89cf0108c9b9e15c842c69bdc4a95876","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-14/","publishdate":"2022-04-01T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-14/","summary":"概要 活动主题：SOFAMeetup\u0026amp;木兰技术开放日（云原生专场） 活动时间：2022 年 04 月 01 日（周五）09:30-12:00 活动形式：","tags":["SOFA"],"title":"【活动回顾】《SOFAMeetup\u0026木兰技术开放日-云原生专场》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-14/","wordcount":2074},{"author":"Carver_007","categories":"SOFAStack","content":" 为了支撑超大规模集群以及大内容传输的支持，增加传输效率，减少网络带宽，考虑对消息进行压缩处理，SOFARegistry的data和session以及session和client (目前只有go支持）添加了对压缩数据传输的支持，同时增加缓存来减少压缩带来的较高的cpu的消耗。\n SOFARegistry 通讯默认支持了哪些压缩算法 目前 SOFARegistry 默认支持了 gzip 和 zstd 两种压缩算法。 gzip 是目前使用最广泛，压缩比较高的一种压缩算法。 zstd 是由 Facebook 的 Yann Collet 开发的一个无损数据压缩算法，Zstandard 在设计上与DEFLATE（.zip、gzip）算法有着差不多的压缩比，但是相比 gzip 有更高的压缩和解压缩速度。\n 两种压缩的基本实现代码如下： 整体结构如下如： CompressUtils 工具类采用静态 Map 对象（compressorMap），以编码方式为 key，以具体编码对应的压缩对象为 value 进行装载，然后待其使用的时候通过编码方式进行获取对应的编码对象实现类。 启动的时候装载到一个 Map 对象，key 为上图的两种编码常量，value 为具体实现类。当需要压缩的时候通过一下 find 方法或者重载方法进行获取具体压缩对象。代码如下：\n缓存的使用 由于压缩和解压缩的对资源的消耗极大，SOFARegistry采用了Google的Guava缓存来提升部分性能，当需要获取压缩的时候首选从缓存中获取，缓存中没有, 才进行压缩操作，同时将压缩结果缓存起来，以便下次获取的时候能直接获取。 具体代码细节参考如下：\n 小注：默认采用hession进行序列化\n 3.数据推送以及通讯两端的数据协商机制 发送端压缩对象的选择由订阅者接收端配置信息决定，所以可以保证发送端和接收端的压缩格式的统一。\n小结： SOFARegistry 是一种定位大型金融级分布式注册中心，数据通信定位偏向于大数据包大流量，因此对于数据传输效率和数据安全较为关注，采用高效的压缩方式，能有效的增加传输效率和使用安全性。目前支持的两种压缩方式都是市面上主流的压缩算法，同时配合这缓存的机制，极好的解决了大数据包带来大流量对网络带宽的压力，因此非常适合大型项目，但是相较于小型项目，这种压缩机制就显得很多余，压缩带来较高的 cpu 压力，因此 SOFARegistry 同时支持关闭压缩传输方式，以支持一些小型项目，具体使用根据业务来定。\n","date":1648623600,"description":"源码解析｜通讯数据压缩","dir":"projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1eea84eb058815d251783d98ba763865","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","publishdate":"2022-03-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","summary":"为了支撑超大规模集群以及大内容传输的支持，增加传输效率，减少网络带宽，考虑对消息进行压缩处理，SOFARegistry的data和sessi","tags":["“源码解析”"],"title":"源码解析｜通讯数据压缩","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","wordcount":901},{"author":"SOFAStack","categories":"SOFAStack","content":" 文｜颜高飞\n【工商银行】金融科技研究院云计算实验室\n本文 2651 字 阅读 5 分钟\n前言 中国工商银行于 2014 年率先启动银行核心业务系统的分布式架构转型探索，自主研发了同业领先的分布式服务平台。\n注册中心为服务平台提供了核心的服务发现功能，其健壮性对服务调用的成功率起着至关重要的作用。近年来，随着服务架构落地范围迅速扩大，注册中心性能容量支撑能力面临更高挑战。\n工商银行结合金融业实际运行场景，对注册中心架构进行了深度定制及优化，不断探索性能容量和高可用能力极限。\nPART. 1 问题及挑战 工商银行分布式服务平台选用 zookeeper 作为分布式服务注册中心。\nzookeeper 在业界分布式系统中使用广泛，具有大规模应用场景，为用户提供高效、稳定的分布式协调服务。zookeeper 支持集群化部署、性能可扩展，可用性也较高，主要表现有：\n1、半数存活即可用特性，使其容灾性能较强\n只要选举节点中有过半节点正常工作，集群即可正常对外提供服务。若集群内个别服务器宕机，客户端会自动切换连接至其他可用服务器。\n2、会话机制，使客户端注册信息保持稳定\n客户端与 zookeeper 服务端之间通过心跳保持会话，默认会话超时 40s。若集群正常对外服务，在会话超时后，zookeeper 服务端将剔除客户端注册信息。而若集群整体不可用，会话不会过期，在注册中心集群恢复后，能自动从快照中重新恢复故障前的会话和注册信息，无需外部干预。\n3、集群提供 observer 机制，实现读写分离、流量隔离\nobserver 节点不参与集群选举，只承担客户端连接和请求，提升整体吞吐量；分担选举节点压力，提升集群稳定性。在实施 observer 分组的情况下，还可实现客户端流量隔离。\n在金融业务实际运行场景中，工商银行搭建了以选举节点为核心、扩展部署 observer 节点的 zookeeper 注册中心集群，并在工商银行稳定运行多年。\n理论上，当 zookeeper 注册中心集群出现故障时，服务调用不会受到影响。\n但在实际混沌工程故障演练过程中，我们发现：偶发场景下，分布式服务平台存在因 zookeeper 系统资源故障或其他问题导致影响业务交易的现象。\n具体问题列举如下：\n 问题一：单服务扩容后提供方节点数过多 触及 zookeeper 推送报文 4M 的上限，从而导致 zookeeper 服务器性能压力过大，未能及时处理其他服务注册请求，影响交易。\n 问题二：zookeeper 集群 leader 服务器内存故障 进程僵死后集群重新选举产生新 leader，但集群内部分服务器未及时感知新 leader，导致部分服务提供方掉线，影响交易。\n 问题三：zookeeper 注册数据大幅增大后 集群故障重新选举后 leader 向其他节点同步的数据量过大，服务器网络到达瓶颈，导致部分服务器未及时加入新集群，影响交易。\n基于以上问题，工商银行一方面对 zookeeper 源码进行了深度定制，另一方面开始着手研究提升服务注册和服务发现高可用能力的机制。\nPART. 2 建设多注册多订阅机制，提升服务调用稳定性 为规避单注册中心集群故障而影响服务调用的问题，工商银行构建了多点接入的高可用注册模型（如图 1 所示）。\n说明：上图中 DC1 和 DC2 为 2 个机房，分别部署有 2 个独立的注册中心集群。DC1 和 DC2 中部署的提供方和消费方均注册、订阅自两个注册中心集群。DC1 中的消费方优先使用 DC1 注册中心推送的提供方列表，DC2 中的消费方优先使用 DC2 注册中心推送的提供方列表。\n在同城双机房内独立部署两个 zookeeper 集群，提供方注册服务至双注册中心，消费方也从双注册中心订阅服务。消费方优先使用与其在同一机房内的注册中心推送的数据，当同机房注册中心集群发生故障时，其他机房的注册中心可接管。注册中心集群故障接管过程中，服务正常调用。\n双注册双订阅机制建成后，分布式服务平台多次完美应对了底层系统资源故障、网络隔离等问题，分布式服务注册和服务发现稳定性显著提升。\n基于双 zookeeper 集群部署的双活架构，因双集群注册中心组件技术栈相同，极小概率下仍存在系统性交易风险——若两个 zookeeper 注册中心集群在同一时刻均出现同一类型故障时（比如同时达到性能瓶颈），业务交易仍然可能会受到影响。\n因此，为规避极小概率的系统性风险，工商银行进一步开展异构注册中心建设，追求极致的服务注册和发现高可用能力。\nPART. 3 建设异构注册中心，规避单一技术栈风险 注册中心异构部署，进一步提升高可用能力\n工商银行开展异构注册中心建设，在部署 zookeeper 集群的同时对等部署一套独立的异构注册中心集群。业务系统同时向 zookeeper 和异构注册中心两个集群注册并进行服务订阅（如图 2 所示）。\n异构注册中心与 zookeeper 协同工作，提升注册中心整体对外服务能力。当 zookeeper 集群与异构注册中心任一集群发生系统性故障时，另一注册中心集群可接管（如图 3 所示数据表结构）。\n说明：上图中 zookeeper 集群故障，异构注册中心正常工作，服务仍可正常注册、订阅及调用。\n提出合并订阅机制，使注册中心故障时迁移更加平滑\n工商银行原有多注册中心订阅机制，消费方优先使用某一注册中心推送的提供方列表，仅当该注册中心上无任一可用提供方，消费方才切换使用下一注册中心推送的数据。此时若优先使用的注册中心因故障推送了不完整的提供方列表，消费方集中调用这些提供方，可能导致“提供方负载不均”、“触发并发限流”等问题。\n为保障建设异构注册中心后注册中心故障时迁移更加平滑，工商银行研究并提出了消费方合并订阅机制：在消费方侧合并 zookeeper 和异构注册中心的订阅视图，各注册中心订阅数据合并后再刷新 invoker 缓存。\n即使某注册中心故障推送了空或者不完整的提供方列表，合并后的数据仍是有效的，提高了消费方筛选提供方的效率，提升交易成功率。\n注册中心异构部署和消费方合并订阅机制建成后，混沌模拟注册中心 CPU 满载、内存高负荷、磁盘故障、网络抖动、网络隔离等故障场景，提供方负载均衡，交易无失败，符合预期。同时，合并订阅机制还能额外降低多注册中心模式下消费方缓存提供方列表所占用的内存。\n基于以上技术储备及基础建设，工商银行于 2020 年开展异构注册中心建设，规避行内注册中心单一技术栈风险，进一步提升了注册中心核心组件在整个分布式体系中的高可用能力。\nPART. 4 未来展望 为满足分布式服务平台金融级高可用的需求，工商银行探索并提出异构注册高可用方案，消除了大规模服务注册场景下单一注册中心存在的系统性风险，保障金融系统的稳健运行。\n未来，工商银行将在异构注册的基础上进一步推动单元化部署运维转型，打破注册中心为全局唯一流量枢纽的现状，实现交易流量在单元内部最大限度完成闭环，辅以单元自动切换实现故障隔离，进一步控制区域性故障场景下的故障爆炸半径，全面提升分布式服务平台流量控制、高可用接管能力，为同业微服务架构规模化应用提供最佳实践和范例。\n本周推荐阅读 “SOFA 星球” …","date":1648537200,"description":"异构注册中心机制在中国工商银行的探索实践","dir":"blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"29e6ac47144c6efb8a23731c2f6351d2","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","publishdate":"2022-03-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","summary":"文｜颜高飞 【工商银行】金融科技研究院云计算实验室 本文 2651 字 阅读 5 分钟 前言 中国工商银行于 2014 年率先启动银行核心业务系统的分布式架构转型探索，自主研","tags":["SOFAStack"],"title":"异构注册中心机制在中国工商银行的探索实践","type":"blog","url":"/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","wordcount":2684},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@韩升 提问：\n 问下 SOFABolt 是否可以单独集成到 Spring Cloud 体系中？不依赖与 SOFABoot？还是直接引用 Bolt 的组件，然后使用原生的方式处理？\n A：直接用 Bolt 自己的 API 就行。\n「SOFABolt」：https://github.com/sofastack/sofa-boot\n**沄澈|che ** 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?\n A：要看 SerializerFactory 对 Localdatetime 的支持了。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nHolmes 本周发布 Holmes 发布 v1.0 版本\nHolmes 是 MOSN 社区开源的 go 语言 continous profiling 组件，可以自动发现 cpu、 memory、goroutine 等资源的异常，并自动 dump 异常现场 profile，用于事后分析定位。也支持上传 profile 到自动分析平台，实现自动问题诊断、报警。\n「发布报告」：https://github.com/mosn/holmes/releases/tag/v1.0.0\n「Holmes 原理介绍」：https://mosn.io/blog/posts/mosn-holmes-design/\n本周推荐阅读 SOFAArk Committer 专访｜看它不爽，就直接动手改！\n “SOFA 星球”闯关计划 ——Layotto 飞船\n 探索 SOFARegistry（一）｜基础架构篇\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1648278000,"description":"SOFA Weekly | 开源新知、Holmes 本周发布、新手任务","dir":"blog/sofa-weekly-20220329/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b4b14b0e38ee5d01c12019bbab406c50","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220329/","publishdate":"2022-03-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220329/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源新知、Holmes 本周发布、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220329/","wordcount":1205},{"author":"kuaile-zc","categories":"SOFAStack","content":" 大致代码流程 推送延迟的计算方式 首次订阅和后续推送延迟计算的区分 如何统计各个阶段的耗时 前言： 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析\n 1、大致代码流转流程 起源于此类 com.alipay.sofa.registry.server.session.push.PushProcessor @PostConstruct 注解由 java 源码提供初始化类会运行此方法，那么就从 init() 函数开始我们今天的故事！\n1.初始化 KeyedThreadPoolExecutor 类（com.alipay.sofa.registry.task.KeyedThreadPoolExecutor）\n2.初始化 initTaskBuffer()\n3.创建针对 push 的 cleaner 者创建过程中会将此线程设置为守护者线程 t.setDaemon(true)\n守护者线程：是指在程序运行的时候在后台提供一种通用服务的线程，比如垃圾回收线程就是一个很称职的守护者，并且这种线程并不属于程序中不可或缺的部分。因此，当所有的非守护线程结束时，程序也就终止了，同时会杀死进程中的所有守护线程。反过来说，只要任何非守护线程还在运行，程序就不会终止。\n源码给的默认值\ncoreSize = OsUtils.getCpuCount() * 3 CPU 数量 * 3\ncoreBufferSize = coreSize * 3000\n让我们来看看初始 KeyedThreadPoolExecutor 会发生的故事。\n1.设置基本参数，添加 Prometheus 监控。\n2.通过配置创建 AbstractWorker[] workers 数组类型。\n3.设置每个 worker 线程为\n让我们来看一下 createWorkers（） 这个方法干了什么事。\n1.创建阻塞队列\n2.创建多个 worker 数量根据 coreSize 并且所以的 worker 都共享所有队列\n阻塞队列被包装了一层详解如下：\n前置知识原生阻塞队列具有以下特性 ArrayBlockingQueue：基于数组的阻塞队列实现，在 ArrayBlockingQueue 内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外， ArrayBlockingQueue 内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。\nLinkedBlockingQueue：基于链表的阻塞队列，同 ArrayListBlockingQueue 类似，其内部也维持着一个数据缓冲队列（该队列由一个链表构成），当生产者往队列中放入一个数据时，队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时（LinkedBlockingQueue 可以通过构造函数指定该值），才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而 LinkedBlockingQueue 之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。\ncom.alipay.sofa.registry.task.BlockingQueues 存储队列的变量是 BlockingQueue[] queues 因为入参 array（false）所以最终生成的是数组类型的 LinkedBlockingQueue 阻塞队列 coreSize 个数组 coreBufferSize 个初始队列大小。\n我们可以看到 WorkerImpl 类的结构如下\n我们用图来解析一下 WorkerImpl 的工作原理\n所以当有服务订阅之后会生成订阅任务 WorkerImpl 将会执行任务，然后在任务执行过程中延迟链路跟踪。整个推送结束之后会有回调函数进行统计。\n2.推送延迟的计算方式 创建推送任务的时候 PushTask（）\nPushProcessor 中的都 push（）开启 push 任务\n1.检查是否是停止的推送任务和是否是灰度推送功能。\n2.task.trace.startPush() 开始任务记录当前开始时间值 PushTrace.pushStartTimestamp\n3.检查 push 任务运行情况 如果没有记录则表示正常， 如果已经有记录则：一种情况超时删除任务第二则是重试\n4.task.createPushData() 创建 Push data\n5.放入 push 记录为了未来重试或者异常情况获取记录做判断\n6.创建回调函数，完成 push 任务之后回调函数生效\n回调函数代码如下\nPushClientCallback.onCallback\n回调函数 PushClientCallback(task) onCallback(Channel channel, Object message) 调用了 this.pushTask.trace.finishPush（）结束了整个 push 链路追踪。\n最后算出大量的数据进行追踪 PushTrace.finish()\n3.首次订阅和后续推送延迟计算的区分 见下表/图统计\n4.如何统计各个阶段的耗时 此图为理解链路追踪过程：\n 字段 字段解释 表达式 根据上图分析步骤 首次订阅和后续推送计算方式是否有区别（默认不填为否） 注解 subRegTimestamp 订阅者订阅请求的时候的时间戳 pushStartTimestamp push 推送开始的时间戳 System.currentTimeMillis() 任务开始获取当前时间戳 pushFinishTimestamp push 推送完成的时间戳 System.currentTimeMillis() 结束之后调用结束方法之后获取当前时间戳 pushCause.triggerPushCtx.firstTraceTimes 第一次通知 seesion 数据变更的时间 lastTriggerSession(pushCause.triggerPushCtx.lastTraceTimes) 最后一次触发session(SOFARegistry 的组件之一）进行变更推送 pushCause.datumTimestamp 主动 pub：那时间就是在 data 端触发修改 datum 的时间如果是主动 sub：那时间就是 sub 注册的当前时间 是 lastPushTimestamp 上一次 push 的时间首次订阅：如果是首次订阅，就是订阅注册的时间，用于后续的过滤，防止重复计算已经推送过的数据的延迟。后续推送：上一次 push 的时间 是 lastPushTimestamp 上一次 push 的时间首次订阅：如果是首次订阅，就是订阅注册的时间，用于后续的过滤，防止重复计算已经推送过的数据的延迟。后续推送：上一次 push …","date":1648018800,"description":"源码解析｜推送延迟 trace","dir":"projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"585ac9eb55d6cd8f21a0fd12a313e8d8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","publishdate":"2022-03-23T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","summary":"大致代码流程 推送延迟的计算方式 首次订阅和后续推送延迟计算的区分 如何统计各个阶段的耗时 前言： 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析 1、大致代码流转流程 起","tags":["“源码解析”"],"title":"源码解析｜推送延迟 trace","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","wordcount":2584},{"author":"行动","categories":"SOFAStack","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁集团开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁集团的业务发展驱动下，近十年间已经演进至第六代。\n 本文为《源码解析｜数据倒排索引》，作者行动，来自高德。\n 《源码解析》系列由 SOFA 团队和源码爱好者们出品。\n GitHub 地址：https://github.com/sofastack/sofa-registry\nSOFARegistry 分层设计 我们知道一个典型的服务发布流程是这样的。\n 图1 服务发布流程\n 如上图、服务注册中心在RPC远程调用中的通常是中间协调者的角色，服务发布者Publisher将服务的发布信息（服务名称、ip、端口号等信息)）发布到注册中心 Registry 中、通常保存在 Registry 内部的数据结构中。服务订阅者在第一次调用服务的时候、会通过 Registry 找到所要调用服务的提供者列表。缓存在本地然后通过负载均衡算法找到一个具体的服务提供者。调用这个具体的服务提供者接口。\n了解了一个典型的 RPC 调用的流程、我们来看看 SOFARegistry 作为一个注册中心内部包含哪几种角色。\n Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\n SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\n DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。\n MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n 图2 SOFARegistry 分层设计 如图 2 所示、在 SOFARegistry 中、客户端 client 直接和 session 通讯，而不是传统意义上的Data节点、这种添加中间一层隔离 DataServer 和客户端的做法。主要是为了处理客户端连接风暴。对这种分层设计。\n感兴趣的可以参考 《海量数据下的注册中心 - SOFARegistry 架构介绍》的 “如何支持海量客户端” 章节，这里不再赘述。文章下面也是主要围绕 Session层展开。\nSessionServer 启动过程 SessionServer 模块的各个 bean 在 JavaConfig 中统一配置，JavaConfig 类为 SessionServerConfiguration，启动入口类为 SessionServerInitializer，该类不由 JavaConfig 管理配置，而是继承了 SmartLifecycle 接口，在启动时由 Spring 框架调用其 start 方法。 该方法中调用了 SessionServerBootstrap#start 方法（图 3），用于启动一系列的初始化服务。 从代码中可以看出，SessionServer 服务在启动时，会启动 SessionServer、SessionSyncServer、HttpServer 三个 bolt 服务。在启动这些 Server 之时，DataServer 注册了一系列 bolt Handler 来处理各类消息。\npublic void start() { try { openSessionSyncServer(); startupRetryer.call( () -\u0026amp;gt; { connectMetaServer(); return true; }); startupRetryer.call( () -\u0026amp;gt; systemPropertyProcessorManager.startFetchPersistenceSystemProperty()); startScheduler(); openHttpServer(); startupRetryer.call( () -\u0026amp;gt; { connectDataServer(); return true; }); sessionRegistryStrategy.start(); configProvideDataWatcher.start(); openSessionServer(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Cannot bootstrap session server :\u0026amp;quot;, e); throw new RuntimeException(\u0026amp;quot;Cannot bootstrap session server :\u0026amp;quot;, e); } } SessionServer 保存了哪些数据 在了解了 SessionServer 的启动过程、明白 SessionServer 作为 DataServer 的代理层、有着非常重要的位置。能够分摊一部分对 DataServer 的压力。那么在 SessionServer 在注册的时候会保存了哪些数据呢?\n SessionCacheService 从名称可以看出是缓存数据，当 Subscriber 注册到 SessionServer 中的时候、我们会给 Client 推送 Client 感兴趣的服务提供者信息列表。但是我们不可能在每次 Client 有变化的时候都去 Data层获取数据、这样对 Data 层的压力会很大。在 SessionServer 上缓存数据服务提供者信息可以对 DataServer 层屏蔽 Client 的变化，从而有效减轻 DataServer 的压力。SessionCacheService 内部的 readWriteCacheMap 缓存了服务提供者列表信息。使用 guava cache 缓存数据。数据有 ttl ，除此之外 Data 层有数据变化也会通知 cache 数据失效。\n Subscriber 和 Publisher 会话缓存信息正排索引信息。 SessionServer 的设计之初就是为了和 Client 直接通讯。通过 SessionServer 来负责与 Client 的连接，将每个 Client 的连接数收敛到 1，每个 SessionServer 负责与若干个 Client 连接，这样当 Client 数量增长时，只需要扩容 SessionServer 集群就可以了。 …","date":1648018800,"description":"源码解析｜数据倒排索引","dir":"projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"40d37578e58543cd340847fbdef907c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","publishdate":"2022-03-23T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["“源码解析”"],"title":"源码解析｜数据倒排索引","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","wordcount":4102},{"author":"葛长伟","categories":"SOFAStack","content":" 文｜葛长伟（花名：川朗 )\n蚂蚁集团技术专家\n负责容器镜像加速项目 Nydus 的开发和维护，专注于容器镜像存储、持久存储和文件系统领域。\n本文 1344 字 阅读 4 分钟\n前言 今年 1 月 ，Containerd 社区通过投票接收 Nydus-snapshotter 成为 Containerd 社区的子项目。这是继 ttrpc-rust 之后，蚂蚁容器团队再次向 Containerd 捐赠子项目。\n此举将方便 Nydus 和 Containerd 的开发协同，减少项目迭代过程中可能出现的不兼容问题，也让用户可以更容易地使用 Nydus 镜像加速服务。\n目前 Nydus 已经将 Nydus-snapshotter 的代码迁移到了 Containerd 组织下的新仓库[1]。\nNydus 简介 Nydus 是蚂蚁集团和阿里云共同开源的容器镜像加速项目，属于 CNCF Dragonfly 项目，是其中的镜像服务部分。\nNydus 是在最新的 OCI Image-Spec 基础之上设计的容器镜像加速服务，重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。\nNydus 设计了一个为镜像优化的文件系统—Rafs。\nNydus 镜像可以推送和保存在标准的容器镜像中心，Nydus 镜像格式完全兼容 OCI Image Spec 和 Distribution Spec。成功转换或者创建镜像后，Nydus 镜像会生成一个元数据文件 Bootstrap、若干个数据文件 blob、manifest.json、config.json。\n目前可以通过 Nydusify 、Acceld 或者 Buildkit 创建 Nydus 加速镜像。\n其中，Acceld[2] 是 Nydus 和 eStargz 的开发者正在合作开发的 Harbor 开源企业级镜像中心的一个子项目，它提供了一个通用的加速镜像转换服务和框架。基于 Acceld，Nydus 和 eStargz 可以方便地从 Harbor 触发加速镜像转换。\n与此同时，Nydus 也在开发 Buildkit 相关的支持，在未来也可以直接通过 Buildkit 从 Dockerfile 直接创建加速镜像。\nNydus-snapshotter 是 Containerd 的 Remote Snapshotter 插件，它是一个独立于 Containerd 的进程。\n当集成 Nydus-snapshotter 到 Containerd 后，Nydus-napshotter 在容器镜像准备阶段，只会将 Nydus 镜像的元数据部分 Bootstrap 从镜像中心下载下来，并且创建了一个新的进程 Nydusd。Nydusd 是处理文件系统操作的用户态进程。通过配置，Nydusd 可以作为基于 Linux FUSE 的用户态文件系统 Virtio-fs Vhost-user Backend，甚至可以是 Linux Fscache 的用户态进程。\nNydusd 负责从镜像中心或者对象存储下载文件数据以响应读文件的请求，并可以将文件数据块缓存在 Host 的本地文件系统。\nNydus 特性 Nydus 有如下重要的特性：\n1、镜像层间块级数据去重，可以减少镜像中心的存储成本，降低数据传输的带宽消耗。\n2、Whiteout 文件不会再被打包进 Nydus 镜像。\n3、端到端的数据完整性校验。\n4、作为 CNCF 孵化项目 Dragonfly 的子项目，Nydus 可以接入 P2P 分发系统，以此降低对镜像中心的压力。\n5、支持数据和元数据分离存储。可以将数据保存在 NAS、阿里云 OSS 或者 AWS S3。\n6、支持文件访问行为记录，这样就可以审计和分析容器内应用的访问行为。增强安全能力、优化镜像数据排布。\n除了以上的关键特性，Nydus 可以灵活地配置成 Linux FUSE 用户态文件系统、基于轻量虚拟化技术容器的 Virtio-fs daemon，或者 Linux 内核磁盘文件系统 EROFS 的用户态 on-demand 数据下载服务：\n1、轻量化地集成到 vm-based 容器运行时。现在 KataContainers 正在考虑原生地支持 Nydus 作为容器镜像加速方案。\n2、Nydus 和 EROFS 紧密合作，期望可以直接使用 EROFS 作为容器镜像的文件系统。相关修改的第一部分已经合并入 Linux Kernel v5.16。\nNydus 部署形态 支持 Runc 时，Nydus 作为 FUSE 用户态文件系统进程：\n支持 KataContainers 时，Nydus 作为 Virtio-fs daemon：\n目前 EROFS 正在尝试联合 Fscache 一起，以内核文件系统 EROFS 直接作为容器 Rootfs：\nNydus 将与 Containerd 社区紧密合作，致力于提供更优秀的容器镜像加速方案，提高镜像的存储和分发效率，提供安全可靠的容器镜像服务。\n求贤若渴： 关于蚂蚁集团可信原生技术部安全容器和存储团队\n在蚂蚁集团内部主要负责公司内部容器运行时和云原生存储技术，是公司数据链路的守护者，运行时环境的看门人。我们团队也是 Kata Containers 的创立者，镜像加速服务 Nydus 的发起者，分布式事务服务 Seata 的维护者，也维护着公司内数据访问组件 ZDal/ZCache/XTS 等产品。\n我们是开源精神的信徒，也是实现开源软件和公司业务双赢的践行者。我们是一个关注业务、关注业界前沿、关注基础设施技术，更关心成员成长的团队。目前我们正在招收 2023 届实习生，有兴趣的可以参考蚂蚁集团2023届实习生招聘。\n联系邮箱：liyuming.lym@antgroup.com\n本周推荐阅读 恭喜 李志强 成为 Layotto committer！\n社区文章｜MOSN 路由框架详解\nHAVE FUN | SOFARegistry 源码解析\nBabaSSL：支持半同态加密算法 EC-ElGamal\n","date":1647932400,"description":"Nydus 镜像加速插件迁入 Containerd 旗下","dir":"blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ad4cca5257474169e5ca87f15437235d","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","publishdate":"2022-03-22T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","summary":"文｜葛长伟（花名：川朗 ) 蚂蚁集团技术专家 负责容器镜像加速项目 Nydus 的开发和维护，专注于容器镜像存储、持久存储和文件系统领域。 本文 1344 字 阅读 4 分钟 前","tags":["SOFAStack"],"title":"Nydus 镜像加速插件迁入 Containerd 旗下","type":"blog","url":"/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","wordcount":1715},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@rust-rust 提问：\n 建议开发各种语言的 API。\n A：Java 和 Python 在设计中，争取注册到 jsse 里。\nBabaSSL：https://github.com/BabaSSL\n@会飞的小胖子 提问：\n tengine 现在可使用 BabaSSL 了吗？\n A：tengine master 已经支持，稳定版还得等等。\nBabaSSL：https://github.com/BabaSSL\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nSOFAJRaft 本周发布 发布 1.3.10 版本，主要变更如下：\nFeatures： 优化 read-index 读，增加 maxReadIndexLag 参数设置快速失败阈值\nLogEntry 增加切片读取 API\n在删除 rocksdb 大 range 数据时，优化空间回收速度\n在节点过载时，将原有的快速失败策略修改为反压策略，依赖于这个特性的用户推荐升级\nBug Fixes： 升级 Log4j 以解决安全漏洞\nsnapshot 文件使用 atomic move 避免文件重新命名是被损坏\n修复 Counter demo 不兼容 gRPC 的问题\n修复对 snapshot 并行压缩/解压的配置项错误\n修复在某种竞争条件下 Replicator 可能停止发送心跳的 bug\n「详细参考」：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.10\n本周推荐阅读 SOFAArk Committer 专访｜看它不爽，就直接动手改！\n HAVE FUN | SOFARegistry 源码解析\n 探索 SOFARegistry（一）｜基础架构篇\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1647586800,"description":"SOFA Weekly | Committer 聊天室、SOFAJRaft 本周发布、新手任务","dir":"blog/sofa-weekly-20220318/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"71d080ef0a61bca724b03bf0f44daa07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220318/","publishdate":"2022-03-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220318/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Committer 聊天室、SOFAJRaft 本周发布、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220318/","wordcount":1155},{"author":"连文湧","categories":"SOFAStack","content":" 数据表结构要求 以应用级服务发现元数据表为例\n param type description data_center String local data center revision String revision app_name String appName client_version String clientVersion base_params String base_params service_params String service_params deleted boolean delete or no gmt_create Date create time gmt_modified Date last update time 写入 写入缓存 cachedExecutor.execute 执行缓存写入操作防止无法瞬间处理大量相同数据写入操作。防止大量节点上报相同的应用级服务发现元数据。\npublic V execute(K key, Callable\u0026amp;lt;V\u0026amp;gt; callable) throws Exception { V v = cache.getIfPresent(key); if (v != null) { //发现元素，命中+1 hitCount.increment(); return v; } return cache.get( key, () -\u0026amp;gt; { //未发现元素，未命中+1 missingCount.increment(); onMiss(key); return callable.call(); }); } 二参数的 execute 统计修订号revision的命中和未命中次数统计 metrics，在通讯数据压缩暴露到 prometheus。\n写入数据 protected void refreshEntryToStorage(AppRevisionDomain entry) { try { cachedExecutor.execute( entry.getRevision(), () -\u0026amp;gt; { //判断是否执行replace写入数据 if (appRevisionMapper.heartbeat(entry.getDataCenter(), entry.getRevision()) == 0) { appRevisionMapper.replace(entry); } //省略日志操作 } } cachedExecutor 默认指定 silentMs=10s，当缓存项在指定的时间段内没有更新就会被回收（移除 key），需要等待获取新值才会返回。10s 内没有更新说明数据量不大，也不需要进行写入缓存的操作。\n通过 hearbeat() 底层通过 update 原子判断数据是否存在。刷新 gmt_modified 字段时间防止被误删。\nupdate app_revision set gmt_modified=CURRENT_TIMESTAMP where data_center = #{dataCenter} and revision=#{revision} and deleted = \u0026#39;0\u0026#39; 当 update 没有命中的时候，使用 replace，保证能生成一个新的 id，用于后续的 watch 方法监听表获取元素更新变化，并刷新 gmt_modified 防止字段超时被删除。\nreplace into app_revision( data_center, revision, app_name, client_version, base_params, service_params, deleted, gmt_create, gmt_modified ) values ( #{dataCenter}, #{revision}, #{appName}, #{clientVersion}, #{baseParams}, #{serviceParams}, #{deleted}, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP ) 获取数据增量改变 Watch 数据库没有提供订阅的操作，watch 方法缓存最新 id 值，增量读取数据库中更新的 id 值并更新最新的 id 值保证 lastLoadId 一直保持最新的状态\nprivate void watch() { syncStart(); try { long start = lastLoadId; if (listStableEntries(start, 1).size() == 0) { return; } logger.info(\u0026amp;quot;start watch from {}\u0026amp;quot;, start); long maxId = listToTail( (T entry) -\u0026amp;gt; { container.onEntry(entry); logger.info(\u0026amp;quot;watch received entry: {}\u0026amp;quot;, entry); }, start, 100); logger.info(\u0026amp;quot;end watch to {}\u0026amp;quot;, maxId); lastLoadId = maxId; } finally { syncEnd(); } } listStableEntries 提供从数据库获取最新数据的 id 值的方法，写入数据的方法底层通过 replace 写入，因此一定会有新的 id 生成。\n机制存在问题：如果数据中间出现不连续的间断，无法得到更新后存在间隔的 id 值。\n此方法主要列出所有创建完成 1s 后更新的元素。\nif (entry.getGmtCreate().getTime() \u0026amp;gt;= now.getTime() - DB_INSERT_DELAY_MS) { break; } 其中 DB_INSERT_DELAY_MS=1s\n为什么是 1s？\n内部是分布式数据库，表内数据会被拆分到多个机器上，每台机器批量获取 id 属性，此时如果大量并发插入，可能产生 id 值高的已经入库，而低 id 还没有完全写入，这时 watch 方式会出现问题，漏掉低 id 值的数据，直到 list 调用才能被重新填入。而这种问题产生的间隔很短，因此 1s 的间隔能保证id值较低的数据已经被填入。\nlistToTail 方法返回当前最大可靠 id 值\nprivate long listToTail(EntryCallable\u0026amp;lt;T\u0026amp;gt; callable, final long start, final int page) { long curStart = start; while (true) { List\u0026amp;lt;T\u0026amp;gt; entries = listStableEntries(curStart, page); if (CollectionUtils.isEmpty(entries)) { break; } for (T entry : …","date":1647586800,"description":"源码解析｜数据表监听","dir":"projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1343a0bf78782bc53e05233bbdcde0cf","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","publishdate":"2022-03-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","summary":"数据表结构要求 以应用级服务发现元数据表为例 param type description data_center String local data center revision String revision app_name String appName client_version String clientVersion base_params String base_params service_params String service_params deleted boolean delete or no gmt_create Date create time gmt_modified Date last update time 写入 写入缓存 cachedExecutor.execute 执行缓存写","tags":["“源码解析”"],"title":"源码解析｜数据表监听","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","wordcount":1597},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展\n 活动时间：03 月 17 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#26 解读 BabaSSL ：项目概况和最新进展 从数据存储到网络通信，从密码合规再到隐私计算，这些场景都离不开密码学算法和协议。\nBabaSSL 密码库作为蚂蚁和阿里的统一基础密码库，广泛的应用在各类蚂蚁和阿里的业务当中，提供了 TLS 通信、数据加密、国密合规等关键的密码学相关能力，确保了各项业务平稳、安全、合规的运行。\nBabaSSL 自 2020 年开源以来，在行业内得到了广大用户的使用和验证。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 张成龙（花名：刻一） -蚂蚁集团技术专家\n-负责蚂蚁 BabaSSL 密码库核心研发\n议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:50 BabaSSL 项目的概况和最新进展 张成龙（花名：刻一），蚂蚁集团技术专家，负责蚂蚁 BabaSSL 密码库核心研发\n你将收获 1.了解 BabaSSL 项目的诞生背景\n2.了解 BabaSSL 密码库的主要功能和技术特点\n3.了解 BabaSSL 8.3.0 新功能\n4.了解 BabaSSL 的未来发展趋势\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1647500400,"description":"03 月 17 日周四晚 19 点，线上直播第 26 期。","dir":"activities/sofa-channel-26/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e998e41cd8ea96210efdbecbb3ae0e95","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-26/","publishdate":"2022-03-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-26/","summary":"概要 活动主题：SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展 活动时间：03 月 17 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展","type":"activities","url":"/sofastack.tech/activities/sofa-channel-26/","wordcount":633},{"author":"曹先胜","categories":"SOFAStack","content":" 文｜曹先胜\ne签宝中间件开发\n负责e签宝中间件开发和维护，包括 MQ、网关、微服务、数据同步、全链路压测等\n贡献者前言 「 开源就是在使用中，共同成长的过程 」\n从 2018 年学习 SOFAStack 的一些开源项目，到如今深入使用 MOSN，伴随着 SOFA 走到四周年。\n因为兴趣也接触了不少的开源社区，唯独对 SOFA 社区的组件体验颇多， 例如 SOFAArk、SOFARPC、MOSN。长年混迹在钉钉群里提问题，都能得到及时回复，这对我们研究 MOSN 有很大的帮助。也因此通过 MOSN 的代码设计，学习到了很多关于 Sidecar 的设计理念。\n我们使用 MOSN 的出发点是公司框架使用了很多的中间件，每个中间件有自己的依赖，这些依赖经常性的会发生冲突。虽然我们使用了类似 Spring Boot 的 Pom 管理机制，但升级框架过程中，如果有同学自行引入了 jar 包，就不可避免的会发生 jar 冲突。为了解决这个问题，我们调研了很多方案，最终认为 Service Mesh 是解决这个问题的一个比较合适的方案。\n同时，也调研了一些其他的开源产品，经过内部讨论和各种取舍，我们选择了MOSN。\n在使用 MOSN 时，因为要对接 Eureka，需要进行动态路由，而官网关于路由的文章不是很多。因此，在自己和烈元老师学习后，总结了这样一篇路由分享文章。\nMOSN 作为网络边缘代理组件，路由功能是核心功能，本文将介绍 MOSN 路由如何使用，以及 MOSN 路由的一些高级使用技巧，欢迎大家留言指导。\n路由基本设计 在 MOSN 的路由设计中，Cluster 和 Route 是高度关联的，说白了 Route 的配置，就是为了表达如何准确找到你想找到的 Cluster，另外一个 Cluster 可以有多个 Host 机器。\n例如一个 Cluster 有 100 台机器，其中有 50 台是 v1 版本，50 台是 v2 版本，如何根据一些特定的规则，准确地把请求路由到 v1 版本或者 v2 版本呢？\n再例如，我想根据 Header 里的某个值，再将这个值和“配置中心”里的某个值进行计算，才能找到 Cluster，那么我该如何配置呢？\n 首先，我们看最简单的路由设置。 上图是一个简单的 Json 配置。其中，Cluster Manager 和 Routers 的配置是路由的关键。我们可以根据 Cluster Manager 配置多个 Cluster，每个 Cluster 配置多个 Host。\n然后在 Routers 配置中，根据一些规则，告诉 MOSN 如何将请求路由到 Cluster 中。\n如下图：\n此配置表示，现在有一个 Rouer 配置名为 Server_Router，有一个虚拟主机，可配置多个域名，这里匹配所有域名。\n同时，这个域名有多个路由配置，这里暂且配置了一个路由配置：前缀匹配，只要是 / 开头的，就转发到 ServerCluster 里的 Host 中，也就是下面的 Cluster Manager 配置里的 ServerCluster。\n这样，就实现了一个简单的 MOSN 路由的配置。\n动态路由 Cluster 大部分情况下，如果我们的路由逻辑很简单，例如根据 Header 里的某个名字，找到对应的 Cluster，代码或者配置就是这么写的：\n、、、java router := v2.Router{ // header 匹配 RouterConfig: v2.RouterConfig{ Match: v2.RouterMatch{ Headers: []v2.HeaderMatcher{ // 这个 header 匹配, 就转发到 app.Name cluster. { Name: \u0026amp;ldquo;X-service-id\u0026amp;rdquo;, Value: app.Name, }, }, }, // cluster 名称匹配. Route: v2.RouteAction{ RouterActionConfig: v2.RouterActionConfig{ ClusterName: app.Name, }, }, }, } r.VirtualHosts[0].Routers = append(r.VirtualHosts[0].Routers, router) 、、、\n上面代码的意思是如果 Header 里有 X-service-id 这个 kv，那么就能找到下面 RouteAction 对应的 Cluster 了。\n那如果是更复杂的逻辑呢？\n比如利用请求里的 Header 和“配置中心”的某个值进行计算，如何才能找到 Cluster呢？\n此时，通过配置已经无法解决这个需求，因为这其中涉及到了计算逻辑，MOSN 通过动态配置可以支持该需求。\n如下图配置：\n我们设置了一个（\u0026amp;rdquo;Cluster_Variable\u0026amp;rdquo;: \u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;） 的 KV 配置。\n同时，我们还需要在 StreamFilter 中，利用变量机制设置 key 为 “My-ClusterVariable” 的 Value ，这个 Value 就是计算出来的 Cluster 名称。\n代码如下：\n、、、Java // 先注册这个 key 到变量表中。 func init() { variable.Register(variable.NewStringVariable(\u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;, nil, nil, variable.DefaultStringSetter, 0)) }\nvar clusterMap = make(map[int]string, 0)\nfunc (f *MyFilter) OnReceive(ctx context.Context, headers api.HeaderMap, buf buffer.IoBuffer, trailers api.HeaderMap) api.StreamFilterStatus { l := len(clusterMap) // 找 Cluster cluster := // 执行一些计算 // 设置到上下文变量中。这个 key 必须和配置文件中保持一致。 variable.SetString(ctx, \u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;, cluster) return api.StreamFilterContinue } 、、、\nMOSN Subset 如上面所述，我们经常有在一个集群里有多个版本，如何根据某些标签将请求路由到指定的版本呢？\n通常，我们会使用 Subset 方案，即“子集合”。可在一个 Cluster 里面，为每个应用打标。同时我们的路由也配置相关的配置（MOSN 称为 Metadata），实现较为复杂的路由。\nMOSN 官方文档中，简单介绍了 Metadata 的使用。\n下面让我们更详细的介绍 Subset 的使用：\n上图中左边是 Cluster Host 配置，右边是 Router 配置。\n这个路由配 …","date":1647327600,"description":"社区文章｜MOSN 路由框架详解","dir":"blog/community-article-mosn-routing-framework-explained/","fuzzywordcount":3100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5de6ebad45acd0c8edc9e9b104c8c333","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","publishdate":"2022-03-15T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","summary":"文｜曹先胜 e签宝中间件开发 负责e签宝中间件开发和维护，包括 MQ、网关、微服务、数据同步、全链路压测等 贡献者前言 「 开源就是在使用中，共同成长的","tags":["SOFAStack"],"title":"社区文章｜MOSN 路由框架详解","type":"blog","url":"/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","wordcount":3087},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@麦兜兜 提问：\n 我这边在 MOSN 上新增了一种私有协议，基本路由功能已经跑通了，其他的流量治理相关配置有样例吗？\n A：治理如果是说的限流限速的话，通常 MOSN 里面的 stream filter 基本上都是和协议无关的，都是可以使用的。\n@张宁 提问：\n snapshot 做起来，打快照后会删除日志的，所以调一下打快照的时间间隔。\n SOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 HAVE FUN | SOFARegistry 源码解析\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\nBabaSSL：支持半同态加密算法 EC-ElGamal\n","date":1646982000,"description":"SOFA Weekly | MOSN 社区会议、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220311/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"58a24de0efaa2ed6d21cbdd80894b214","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220311/","publishdate":"2022-03-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220311/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 社区会议、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220311/","wordcount":697},{"author":"王祖熙","categories":"SOFAStack","content":" 文｜王祖熙（花名：金九 )\n蚂蚁集团开发工程师\n负责蚂蚁 Kubernetes 集群容器交付专注于集群交付能力、交付性能及交付 Trace 等相关领域\n—— 数据不出域、可用不可见\n01背 景 随着大数据与人工智能的快速发展，个人隐私数据泄露和滥用时有发生，隐私安全问题也越来越被重视。\n国家于 2020 年施行密码法、2021 年施行个人信息保护法，对个人隐私数据和数据安全加密有更高的要求。\n因此，隐私计算也不断地被提及和关注，源于其有优秀的数据保护作用，使得『数据不出域、可用不可见』，限定了数据的使用场景，防止了数据的泄露，而引起了业界的热捧。\n隐私计算是指在保护数据本身不对外泄露的前提下，实现数据共享和计算的技术集合，共享数据价值，而非源数据本身，实现数据可用不可见。\n 隐私计算对于个人用户来说，有助于保障个人信息安全；\n 对于企业来说，隐私计算是数据协作过程中履行数据保护义务的关键路径；\n 对于政府来说，隐私计算实现数据价值最大化的重要支撑。\n 隐私计算目前在金融、医疗、电信、政务等领域均在开展应用试验，比如：\n银行和金融机构\n在不泄露各方原始数据的前提下，进行分布式模型训练，可以有效降低信贷、欺诈等风险；\n医疗机构\n无需共享原始数据便可进行联合建模和数据分析，数据使用方在不侵犯用户隐私的情况下，可以使用建模运算结果数据，有效推动医疗行业数据高效利用。\n隐私计算的相关技术有多方安全计算 （MPC） 、可信执行环境 （TEE） 、联邦学习 （FL） 、同态加密 （HE） 、差分隐私 （DP） 、零知识证明 （ZKP） 、区块链 （BC） 等等。\n这些技术各有优缺点，隐私计算的产品或者平台也是由这些技术来搭建。\n其中与密码学明显相关的是同态加密，目前同态加密算法的开源项目各有千秋，用户使用比较复杂。BabaSSL 作为基础密码库，应该提供一套简单易用和高效的同态加密算法实现和接口，让上层应用更方便简单地使用同态加密算法。\n此外，随着隐私计算技术的兴起，蚂蚁集团推出了开箱即用、软硬件结合的隐私计算基础设施，一站式解决方案，即可信原生一体机。\nBabaSSL 作为蚂蚁可信原生一体机中的核心基础软件密码库，将同态加密等隐私计算所需的相关密码学能力整合其中，为可信原生一体机的用户带来更加便捷高效的使用体验。\n02 同态加密 同态加密 （Homomorphic Encryption, HE） 是指满足密文同态运算性质的加密算法，按性质分为加法同态和乘法同态：\n加法同态\n乘法同态\n同态加密后得到密文数据，对密文数据进行同态加法或者乘法得到密文结果，将密文结果同态解密后可以得到原始数据直接加法或者乘法的计算结果。\n如下图：\n根据满足加法和乘法的运算次数又分为：全同态加密和半同态加密。\n全同态加密\n（ Fully Homomorphic Encryption, FHE ）\n1.支持任意次的加法和乘法运算\n2.难实现、性能差 （密钥过大，运行效率低，密文过大）\n3.主流算法：Gentry、BFV、BGV、CKKS\n4.需要实现的接口\n半同态加密\n（Partially Homomorphic Encryption, PHE）\n1.只支持加法或乘法中的一种运算，或者可同时支持有限次数的加法和乘法运算\n2.原理简单、易实现、性能好\n3.主流算法：RSA、ElGamal、Paillier\n4.需要实现的接口：\n*（1）KeyGen()： 密钥生成算法，用于产生加密数据的公钥 PK（* Public Key）和私钥 SK（Secret Key），以及一些公共参数 PP（Public Parameter）。\n*（2）Encrypt()： 加密算法，使用 PK 对用户数据 Data 进行加密，得到密文 CT（Ciphertext）。*\n*（3）Decrypt()： 解密算法，使用 SK 对密文 CT 解密得到数据原文 PT（Plaintext）。*\n*（4）Add()： 密文同态加法，输入两个 CT 进行同态加运算。*\n*（5）Sub()： 密文同态减法，输入两个 CT 进行同态减法算。*\n*（6）ScalaMul() 或者 Mul() ：密文同态标量乘法，输入一个 CT 和一个标量 PT，计算 CT 的标量乘结果。*\nEC-ElGamal 原理\nElGamal 加密算法是基于 Diffie-Hellman 密钥交换的非对称加密算法，EC-ElGamal 是 ECC 的一种，是把 ElGamal 移植到椭圆曲线上来的实现，主要计算有：椭圆曲线点加、点减、点乘、模逆和离散对数。\n以下是 EC-ElGamal 的算法原理：\n公共参数\n1.G：椭圆曲线基点\n2.SK：私钥，SK=d\n（d 是 0 到椭圆曲线的阶 q 之间的随机数）\n3.PK：公钥，PK=dG\n加密\n1.明文 m，随机数 r\n2.计算密文 C：\n（3）明文 m 的取值范围为模 order(G) 的模空间，但实际使用时 m 需限制为较小的数 （例如 32 比特长度） ，否则椭圆曲线离散对数问题 （ECDLP） 无法求解。\n解密\n1.计算 rPK：\n2.计算 mG：\n3.计算 mG 的 ECDLP，获得明文 m。\n密文加法、密文减法\n1.两个密文：\n2 .密文加：\n对 2 个密文的 2 个 ECC 点分别做点加，共 2 个点加，公式如下：\n3.密文减：\n对 2 个密文的 2 个 ECC 点分别做点减，共 2 个点减，公式如下：\n密文标量乘法\n1.密文\n2.对密文的 2 个 ECC 点分别用 𝑚_2 做点乘，共 2 个点乘，公式如下：\n3.如上公式与明文m2m1的同态加密结果一致：\n这里 r=m2r1\n03 算法实现 接口定义\n对象相关接口\n1.上下文对象：\nEC_ELGAMAL_CTX，该对象用来保存公私钥以及一些其他内部用到的信息，是 EC-ElGamal 算法其他接口的第一个参数。\n接口如下：\n//创建 EC_ELGAMAL_CTX 对象，key 为 ECC 公钥或者私钥的 EC_KEY 对象 2.解密表对象：\nEC_ELGAMAL_DECRYPT_TABLE，该对象用来保存解密表的内部信息。椭圆曲线离散对数问题（ECDLP）只有爆力破解的方法可求解，而爆力破解的速度比较慢，通常的做法是使用小步大步算法（Baby-Step，Giant-Step，BSGS）。总体思想是提前将所有可能的明文结果提前运算后，保存到 hash 表中，下次只需要进行少量的运算和 hash 表查找就可以得到结果，大大提高 ECDLP 的解密效率，但解密表的初始化可能比较慢，而且解密表的实现事关解密速度，后面考虑可以开放接口的实现给上层应用，所以这里先定义了一个解密表的对象和默认实现。\n接口如下：\n//创建 EC_ELGAMAL_DECRYPT_TABLE 对象 //decrypt_negative 为 1 时表示该解密表可以解密负数，初始化解密表时将可能的负数运算后插入到 hash 中。 EC_ELGAMAL_DECRYPT_TABLE *EC_ELGAMAL_DECRYPT_TABLE_new(EC_ELGAMAL_CTX *ctx, int32_t …","date":1646809200,"description":"BabaSSL：支持半同态加密算法 EC-ElGamal进","dir":"blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"efc7daaf960e5998f9fee0a1457a986e","permalink":"https://sofastack.github.io/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","publishdate":"2022-03-09T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","summary":"文｜王祖熙（花名：金九 ) 蚂蚁集团开发工程师 负责蚂蚁 Kubernetes 集群容器交付专注于集群交付能力、交付性能及交付 Trace 等相关领域 —— 数据不出域、可用不可见 01","tags":["SOFAStack"],"title":"BabaSSL：支持半同态加密算法 EC-ElGamal","type":"blog","url":"/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","wordcount":3244},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@冷建伟 提问：\n 启动 SOFABoot 报错：Can not found binding converter for binding type bolt。跟到源码发现：bindingTypeBindingConverterMap 只有 jvm，没有 bolt。跟到源码发现 SPI load 的 converter 只有 JVM。版本：runtime-sofa-boot-starter-3.1.4.jar。想问下是不是要升级我的 SOFA SDK 版本 ？\n A：这个引入 rpc starter 即可。\n@leon 提问：\n SOFARegistry 是不需要用 K8s 吗？\n A：SOFARegistry 在内部是基于 K8s 部署的，提供更细粒度更高性能的服务发现。\n 为什么不是想办法优化 K8s 服务发现性能，而是搞代码侵入性的方案？\n A：基于 K8s 的实现的无侵入式服务发现是云原生下的一套较为后期和理想的方案，这也是 SOFARegistry 后续演进的规划之一。\n目前依然采用侵入的发布订阅模式，一是性能的考量，现有的 K8s 很难支撑起数千万级别数量的服务以及稳定推送延迟的要求；二是迁移有一个过程，对大量现有应用进行服务发现的改造是一个很长周期，无侵入式服务发现会采用逐渐接入的方式。\n目前重点还在于如何更好更稳定的支撑起超大规模集群的问题上。\n@来永国 提问：\n SOFATracer 加了 sofa-tracer-rocketmq-plugin 扩展包，还需要做什么配置吗？\n A：需要配置一下 SendMessageHook 和 ConsumeMessageHook 这两个 hook，分别是：SofaTracerSendMessageHook、SofaTracerConsumeMessageHook。\n本周发布 BabaSSL 开源发布 8.3.0 版本，主要更新如下：\n修复 CVE-2021-4160\nopenssl enc 命令支持 wrap 模式\nASYNC: 支持 job 的嵌套\n支持 TLS 证书压缩 (RFC 8879)\n发行版上游 patch 集合合并 [hustliyilin]\n支持 NTLS session ticket\n支持祖冲之消息完整性算法 128-EIA3\n支持 NTLS 客户端认证\n移除 ARIA 算法\n支持国密合规的软随机数生成器\n支持半同态加密算法 EC-ElGamal\n在 NTLS 中支持 RSA_SM4 加密套件\nARM 平台上提供 SM3 和 SM4 的性能优化\nSM4 算法逻辑优化以提升性能 [zzl360]\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nMOSN 本周发布 发布 MOSN V0.26.0 版本，主要变更如下：\n主要更新如下：\n XProtocol 进行了重构，XProtocol 不再是一种协议，而是便于协议扩展实现的框架\n 新增 ip_access filter，基于来源 IP 的 ACL 控制器\n 支持 go plugin 加载协议转化插件，并支持动态选择协议转换插件\n 支持动态设置上游协议，使用 transcoder filter 来替换 Proxy 中的协议转换\n 其他优化与BUG Fix\n 「详细参考」：\nhttps://mosn.io/blog/releases/v0.26.0/\n本周推荐阅读 BabaSSL 发布 8.3.0｜实现相应隐私计算的需求\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1646377200,"description":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","dir":"blog/sofa-weekly-20220304/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9e14d6832e36d94e116c499a9ef62278","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220304/","publishdate":"2022-03-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220304/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |BabaSSL 发布新版本、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220304/","wordcount":1478},{"author":"小蚂蚁","categories":"SOFAStack","content":" 在近日中国科协召开的 2022“科创中国”年度会议上，中国工程院院士周济发布了 2021“科创中国”开源创新榜单。\n蚂蚁集团开发的可信执行环境隐私计算操作系统 Occlum 入选“科创中国”开源创新榜年度优秀开源产品。\n其中，可信执行环境隐私计算操作系统 Occlum 也是该榜单中唯一聚焦隐私计算领域的入选产品。\nOcclum 发展里程 2015 年 蚂蚁集团开始布局隐私计算，成功推出了 TEE 开源操作系统 Occlum。目前，Occlum 也是蚂蚁集团所有隐私计算业务的 TEE 底座，支撑了蚂蚁隐私计算的核心场景。\n2019 年 Occlum 正式开源，是国内第一个面向可信执行环境(Trusted Execution Environments，简称 TEE)的隐私计算操作系统，解决了云端 TEE 技术额外的功能限制和兼容性问题，降低了隐私计算应用开发门槛。\n目 前 Occlum 已捐赠到由微软、谷歌、IBM、阿里巴巴、腾讯等领先科技公司成立的隐私计算联盟(Confidential Computing Consortium,The LinuxFoundation)，是联盟中唯一由中国发起的项目。\n开源隐私计算操作系统 Occlum 还支持了阿里巴巴、微软等公司的云端隐私计算业务场景和大批隐私计算创业公司的隐私计算平台。国际著名开源项目也在使用 Occlum 开源产品，如 Hyperledger Avalon、Inclavare Container 等。\nOcclum 获得了产、学、研多方认可，相关技术成果已在操作系统领域顶级会议 ASPLOS 2020 发表。\n从 1869 项开源产品中被推选出来，Occlum 长期以来在基础技术领域的努力和坚持得到了认可。\n开源路漫漫，我们也很开心地看到，中国开发者正在成为全球开源社区的重要力量。\n对 SOFAStack - Occlum 感兴趣的话\n👏 等你加入我们！\n本周推荐阅读 BabaSSL 发布 8.3.0｜实现相应隐私计算的需求\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n从 generator 的角度看 Rust 异步代码\n","date":1646290800,"description":"Occlum 入选 2021“科创中国”开源创新榜","dir":"blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3d995f09ef72a3b41105b1315cb3c29f","permalink":"https://sofastack.github.io/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","publishdate":"2022-03-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","summary":"在近日中国科协召开的 2022“科创中国”年度会议上，中国工程院院士周济发布了 2021“科创中国”开源创新榜单。 蚂蚁集团开发的可信执行环境隐私","tags":["SOFAStack"],"title":"Occlum 入选 2021“科创中国”开源创新榜","type":"blog","url":"/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","wordcount":723},{"author":"SOFAStack","categories":"SOFAStack","content":" BabaSSL 8.3.0 稳定版本发布！ 密码学开源项目 BabaSSL 近日发布了 8.3.0 稳定版本，该版本中提供了若干 bug 修复以及较多的新特性支持。\n从具体特性角度来看，BabaSSL 8.3.0 版本在国际前沿技术标准、国内密码合规能力以及国密算法的性能优化上均进行了能力的提升。其中：\n前沿技术标准： RFC8879 所定义的 TLS 证书压缩功能为 TLS 握手带来了很大的性能提升、进一步降低了 TLS 加密通信时的延迟，对于提升用户体验起到了很好的增强，可直接降低 TLS 握手带宽 80% 以上。\n国内密码合规能力： 支持 NTLS session ticket、客户端认证以及 RSA_SM4 加密套件，为目前国内各行业也在进行的国密改造提供了功能上的大力支持；\n而对国密合规的软随机数生成器的支持，更是满足了国密改造过程中的合规性要求。\n国密算法性能优化： 此次 BabaSSL 连同 ARM、阿里云对国密 SM3 和 SM4 算法在 ARM v8 架构上进行了特殊硬件指令的优化，使得 BabaSSL 在具备相关指令集的 ARM 架构 CPU 上可以取得更好的 SM3 和 SM4 的计算性能。\n例如，在阿里云倚天 710上，SM3 获得最高 74% 以及 SM4 算法最高 36 倍的性能提升；此外，SM4 算法逻辑的 C 语言优化，也实现了在通用 CPU 上性能的提升。\nBabaSSL 8.3.0 主要存在如下方面的更新： 修复 CVE-2021-4160\n openssl enc 命令支持 wrap 模式\n ASYNC: 支持 job 的嵌套\n 支持 TLS 证书压缩 (RFC 8879)\n 发行版上游 patch 集合合并 [hustliyilin]\n 支持 NTLS session ticket\n 支持祖冲之消息完整性算法 128-EIA3\n 支持 NTLS 客户端认证\n 移除 ARIA 算法\n 支持国密合规的软随机数生成器\n 支持半同态加密算法 EC-ElGamal\n 在 NTLS 中支持 RSA_SM4 加密套件\n ARM 平台上提供 SM3 和 SM4 的性能优化\n SM4 算法逻辑优化以提升性能 [zzl360]\n 值得一提的是，针对数据安全和隐私保护市场的兴起，BabaSSL 8.3.0 中实现了对半同态加密算法 EC-ElGamal 的支持，隐私计算领域的用户可以便捷的使用该算法实现相应隐私计算的需求，并同时利用 BabaSSL 提供的国密能力实现技术合规。\n此外，BabaSSL 目前作为蚂蚁隐私计算一体机中默认集成的软件密码库，为蚂蚁隐私计算一体机的用户提供统一的密码学 API 接口，方便隐私计算应用程序的开发和调试。\n欢迎下载 BabaSSL 8.3.0 版本，下载地址：\nhttps://github.com/BabaSSL/BabaSSL/releases/tag/8.3.0\nBabaSSL 是什么 ？ BabaSSL 是一个提供现代密码学算法和安全通信协议的开源基础密码库，为存储、网络、密钥管理、隐私计算等诸多业务场景提供底层的密码学基础能力。实现数据在传输、使用、存储等过程中的私密性、完整性和可认证性的保证，为数据生命周期中的隐私和安全提供保护能力。\n作为国内稀缺的密码学开源项目，BabaSSL 填补了国内信息基础设施领域相关产品的空白，是我国建设国产密码学大生态、解决密码学技术“卡脖子”问题、发展前沿密码学技术的关键一环。\n除了在国家商用密码算法领域之外，BabaSSL 还在前沿密码学领域进行了支持，包括隐私计算场景下所需的各种密码学算法以及为了应对量子计算而产生的后量子密码学算法等。\nBabaSSL 对国际和国内的新型技术标准采用快速跟进的策略，因此支持的功能十分丰富。同时基于蚂蚁和阿里海量的用户场景，其性能和稳定性也达到了互联网生产级别。\n自 2020 年开源以来，BabaSSL 也在行业内得到了广大用户的使用和验证，并应用到了众多业务场景里。\nBabaSSL 的前世今生 BabaSSL 诞生于蚂蚁集团和阿里集团内部，目前作为蚂蚁和阿里的统一基础密码库，广泛应用在各类蚂蚁和阿里的业务当中，提供了 TLS、数据存储、国密合规等关键的密码学相关能力，确保了各项业务平稳、安全、合规的运行。\n2020 年进行开源以来，BabaSSL 将蚂蚁和阿里内部所积累的密码学技术能力提供给业界使用，同时在申请商用密码产品软件密码模块一级资质，也是首个有望获得商用密码产品型号证书的开源密码学产品。\n从具体场景来看，有如下三个方面，分别是存储、网络和端上的设备。其中网络服务的场景，是 BabaSSL 最大的支撑场景，例如淘宝、天猫、阿里云等各种涉及到链路加密的服务器端。此外移动端 App，例如支付宝手机 App 中集成了 BabaSSL 来实现多种密码学的能力。\n1. 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了 有了基础国密算法支持，我们在 AnolisOS 上构建出一个围绕国密算法展开的基础软件生态，同时它也是一个全栈国密解决方案：从底层固件，内核，到基础密码学库，在主要链路上做国密改造，最终形成一个完整的基于国密的安全信任链条。\n2. RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海 TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。随着 TLS 1.3+ 国密正式成为了国家/国际层面均认可的标准（RFC8998），我们也正式在 BabaSSL 中支持了相关能力并将其开源，并建设了 BabaSSL 社区。\n3. TLS 握手带宽直降 80%，BabaSSL 是怎么做到的 为了保障数据的安全性，通常使用 TLS/SSL 进行加密传输。当客户端访问服务器后台时，客户端会先和服务器进行 TLS 握手。RFC 8879 TLS Certificate Compression 就是为了解决这个问题，在 TLS 1.3 握手时提供证书压缩功能，大大降低数据传输，减少 TLS 握手的带宽消耗呢。\n4. Tengine + BabaSSL ，让国密更易用！ 国内著名 Web 服务器和反向代理开源软件 Tengine 完成了对 BabaSSL的适配工作。Tengine 对 BabaSSL 提供的特殊 API 进行了适配，并增加对 NTLS 相关能力的支持。无需额外的 patch 或者代码改动，从用户使用的角度进一步提升了便利性。\n对密码学、隐私计算感兴趣的话\n等你加入我们！\n本周推荐阅读 Tengine + BabaSSL ，让国密更易用！\nTLS 握手带宽直降 80%，BabaSSL 是怎么做到的\nRFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n","date":1646204400,"description":"BabaSSL 发布 8.3.0｜实现相应隐私计算的需求","dir":"blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f9693f85dce6fd979f0323ae3797b3cc","permalink":"https://sofastack.github.io/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","publishdate":"2022-03-02T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","summary":"BabaSSL 8.3.0 稳定版本发布！ 密码学开源项目 BabaSSL 近日发布了 8.3.0 稳定版本，该版本中提供了若干 bug 修复以及较多的新特性支持。 从具体特性角度来看，BabaSSL 8.3.0 版","tags":["SOFAStack"],"title":"BabaSSL 发布 8.3.0｜实现相应隐私计算的需求","type":"blog","url":"/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","wordcount":2108},{"author":"李旭东","categories":"SOFAStack","content":" 简介 SOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群，具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n蚂蚁生产集群 — SOFARegistry 支撑 1000 万服务发布者、4000 万服务订阅者，在业务应用大规模变更触发千万级别推送量的场景下，推送延迟的 p99 依然能够保持在 7s 以下。\n《认识 SOFARegistry》 这一系列文章将会基于 SOFARegistry 新版本（V6）的代码，讲解注册中心在超大规模集群场景下落地的解析与实践，同时介绍 SOFARegistry 的各项功能，方便业务落地。\n部署架构 SOFARegistry 现有的架构设计：采用双层存储架构，外加一个负责内部元数据管理的 meta 组件。\nSOFARegistry 的角色分为 4 个: client、session、data、meta。\n角色分工如下：\nClient\n提供应用接入服务注册中心的基本 API 能力，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\nSessionServer ｜ 会话服务器\n负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\nDataServer ｜ 数据服务器\n负责存储具体的服务数据，数据按 dataInfoId 进行分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模增长而扩容。\nMetaServer ｜ 元数据服务器\n负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n借助双层数据分片的架构，SOFARegistry 具有了支撑海量数据的基石\n● 支持海量数据：每台 DataServer 只存储一部分的分片数据，随数据规模的增长，只要扩容 DataServer 服务器即可。\n● 支持海量客户端：连接层的 SessionServer 只负责跟 Client 打交道，SessionServer 之间没有任何通信或数据复制，所以随着业务规模的增长，SessionServer 可以较轻量地扩容，不会对集群造成额外负担。\n数据结构 作为注册中心的基础功能，SOFARegistry 提供发布订阅的接口：Subscriber、Publisher。\n在服务发现场景下，Subscriber 需要通过服务名称从注册中心订阅到多个服务方的地址，进行负载均衡的访问。\n当存在服务方机器宕机时，注册中心通知所有的订阅方从服务列表中摘除这个 IP 地址，这样就不会再访问宕机的机器。\n下面给出简化后的发布者和订阅者的字段，贴合上述服务发现的需求。\nclass Subscriber{ String dataId; // 服务名称 String group; // 业务类型，比如RPC、MSG等等 String instanceId; // 租户名称 String zone; // 所在分区，结合scope实现逻辑隔离 ScopeEnum scope; // 订阅范围: zone、dataCenter、global } class Publisher{ String dataId; String group; String instanceId; String zone; List\u0026amp;lt;String\u0026amp;gt; dataList; // 发布的数据, sofarpc 用法中常见url } 常见用法（JAVA SDK）\n发布者\n// 构造发布者注册表 PublisherRegistration registration = new PublisherRegistration(\u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); // 将注册表注册进客户端并发布数据 Publisher publisher = registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); // 如需覆盖上次发布的数据可以使用发布者模型重新发布数据 publisher.republish(\u0026amp;quot;10.10.1.1:12200?xx=zz\u0026amp;quot;); 订阅者\n// 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { @Override public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, global String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); registration.setScopeEnum(ScopeEnum.global); // 将注册表注册进客户端并订阅数据，订阅到的数据会以回调的方式通知 SubscriberDataObserver Subscriber subscriber = registryClient.register(registration); 更详细的用法文档参考官方文档: https://www.sofastack.tech/projects/sofa-registry/java-sdk/\n特点与优势 这是一张 SOFARegistry 和其他注册中心产品的特性对比图，可以看出相比其他产品，SOFARegistry 在功能特性方面还是不足（未来 SOFARegistry 在特性方面会进行完善）。 SOFARegistry 的主要优势还是在于支撑超大规模集 …","date":1646118000,"description":"探索 SOFARegistry（一）｜基础架构篇","dir":"blog/explore-sofaregistry-1-infrastructure/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ae1a4db92cf2dea8d057ba7dede8c440","permalink":"https://sofastack.github.io/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","publishdate":"2022-03-01T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","summary":"简介 SOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群，具有分布式可水平扩容、容量大、推送延迟低、高可","tags":["SOFAStack"],"title":"探索 SOFARegistry（一）｜基础架构篇","type":"blog","url":"/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","wordcount":3704},{"author":"SOFA 团队","categories":"SOFAStack","content":" 2 月 24 日，MOSN 举办了 2022 年首次的社区会议。\nMOSN 社区在会议上提出了新一年的 Roadmap，社区成员分享了 MOSN 在不同场景下落地实践的经验，以及大家一起大开脑洞，探讨了更多我们可以创造的可能性。\nMOSN 社区 Roadmap MOSN 在 2022 年主要的目标是发布 MOSN 1.0，以及开源一个新的开箱即用的产品。同时推动 MOE （ MOSN 2.0 架构）演进，对接更多的生态组件。\n随着 MOSN 的落地用户越来越多，稳定性建设也是今年的重点发展方向，让大家用得放心。\n社区会议分享嘉宾 来自探探科技、阿里云、去哪儿网的用户，在本次会议中都积极分享了自己的使用案例，供大家借鉴参考。\n探探科技 谢正尧同学详细地列出了 MOSN 落地过程中遇到的问题和踩到的坑，给 MOSN 的后续优化提供了很好的思路。\n有不少坑我们都已经安排上了日程，MOSN 的开发者都赶在填坑的路上。\n阿里云 沐沂同学列出了新财年的规划，和大家分享了边缘的跨集群服务发现场景的租户拆分，以及新的部署形式。\n去哪儿网 佳龙同学比较关注 Roadmap 中的 GC 方面，希望可以引入一些高性能的网络框架，对性能优化方面有更多的需求。\n以及很期待 MOSN 社区的 holmes，希望可以解决查问题时的难题。\nQA 回顾 1.Q：MOE 的落地场景、最佳实践的博客有哪些？\nA：具体内容我们会在 Service Mesh Summit 2022 首届服务网格峰会进行分享。今年会有更多的落地场景，在尝试替换接入层网关，也会试点上线的，可以期待一下！\n2.Q：我可不可以理解为——假如 MOE 在 Envoy 被接收后，可以通过 Go 代码去写一个 filter，让它跑在 Envoy 上，之后我的数据链直接用 Envoy 就可以？\nA：是的，就这个意思。现在我们的 demo 就可以玩起来了，只是有些接口还没标准化，现在我们内部落地的 sofagw 就是这个架构。\n「demo文档」⬇️： https://github.com/mosn/mosn/blob/master/pkg/networkextention/README-cn.md\n3.关于 GC 优化方式的讨论\nA：（1）降低 GC 频率确实是有效的，可以减少长期存活对象的重复 mark。（2）不过这种预分配的，其实不是很灵活，最好的还是动态调整 GC Percent，保持 GC goal 在预期的水位。\n本质上是一个内存换 CPU 的方案，在内存够用的时候，提高 GC goal 的水位。\n我们搞 holmes 内存异常捕获的时候，也考虑过这种情况。https://uncledou.site/2022/go-pprof-heap/\n大家在本次会议中畅所欲言，大开脑洞。也正是与使用用户的沟通交流，让 MOSN 的发展规划和用户需求相辅相承。\n感谢大家的积极配合，在你们的帮助下，MOSN 社区会持续推动性能优化、技术落地，与用户共同成长。\n我们之后还会举办社区会议，比如在 MOSN 发布新版本或者有大进展时。听取用户反馈，同步业界动态，期待下次会议啦～\n想要预定下次的社区会议,了解更多 MOSN 社区动态,钉钉搜索:21992058\n本周推荐阅读 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\nMOSN 多协议扩展开发实践\nService Mesh 在中国工商银行的探索与实践\n云原生运行时的下一个五年\n","date":1646031600,"description":"社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进","dir":"blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ee484f870924be25bf5ccddd91840b89","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","publishdate":"2022-02-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","summary":"2 月 24 日，MOSN 举办了 2022 年首次的社区会议。 MOSN 社区在会议上提出了新一年的 Roadmap，社区成员分享了 MOSN 在不同场景下落地实践的经验，以及大家","tags":["SOFAStack"],"title":"社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进","type":"blog","url":"/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","wordcount":1114},{"author":"陈岸琦","categories":"SOFAStack","content":" 文｜陈岸琦（花名：敖清 )\n蚂蚁集团高级开发工程师\n负责蚂蚁 Prometheus 监控原生功能，在蚂蚁集团的落地与产品化建设\n本文 6566 字 阅读 15 分钟\n前 言 日志和指标是监控不可或缺的两种数据源，为应用系统提供完整的可观测性。\nAntMonitor 作为蚂蚁的统一监控平台，是一款主要以日志方式采集监控数据的监控产品。在社区，开源的云原生监控，主要以 Metrics （指标）的方式实现监控，其中以 Prometheus 为代表。\n并且 Prometheus 监控因其强大的用户功能、结合 PromQL 的数据后分析能力，在业界有广泛的用户群体。实际上已成为开源标准，广泛用于开源 Kubernetes 的集群监控。\nPrometheus 本身是一款单机监控产品，在蚂蚁庞大的高可用集群场景落地，具有一定的局限性和困难，包括但不限于：\n Prometheus 没有提供稳定的、长期的数据存储功能，无法满足蚂蚁场景下对历史数据的查询；\n Prometheus 是有损监控，不保证数据的完整性，无法满足蚂蚁场景下对交易笔数等数据的精确性要求；\n Prometheus 不支持日志监控。\n 但是为了满足用户对 Metrics 监控的需求，经过近两年的努力，我们成功地将 Prometheus 的主要功能融合进了 AntMonitor 的现有架构，提供了一套具有蚂蚁场景特色的集群化解决方案。\n今年大促，我们成功地将 Sigma 集群监控（蚂蚁原生的集群管理和资源调度平台）完整迁移至 AntMonitor。配合告警和大盘，实现了 Sigma 监控的覆盖。AntMonitor 凭借 Sigma 监控的迁移，成功孵化了完善的的云原生 Prometheus 监控能力。\n本文简要介绍了AntMonitor 对 Prometheus 监控功能的支持，以及 Sigma 监控的落地实践。\nPART. 1 海量数据下的采集架构 以下是一段 Prometheus metrics 数据的样例：\nMetrics（指标）数据和日志数据拥有较大差别，包括但不限于：\n第一、日志数据写在磁盘上，每条日志都有标准时间戳，而 Prometheus metrics 是存在内存里，采集时间以拉取的时间为准，因此数据的准确性对调度的准确性有较高要求。\n第二、日志的每次采集均采集增量即可，每次采集的数据量有限，但是 Metrics 数据每次采集均要采集全量，数据的文本大小动辄上百 MB，因此 Metrics 数据量巨大，很容易超限。\n第三、日志数据均需要按照某些固定 schema（数据表结构）作切分清洗、计算聚合，但是原生 Metrics 通常存储单机原始数据。\nAntMonitor 现有的数据链路大致为由 agent 采集日志数据缓存于内存，由 Spark 计算集群从 agent 内存中拉取数据，进行聚合，存储于 CeresDB。\n然而 Metrics 数据不同于日志数据，单机明细数据通常具备可观测性，具备完整的信息。因此通常 Metrics 数据，可以跳过计算步骤，直接进行存储。因此，Metrics 数据在保留单机明细数据的情况下，由 agent 内存和 Spark 拉取的方式已经不合时宜，不仅浪费了计算资源，agent 内存也无法支撑住庞大的 Metrics 数据量。\n因此，我们根据用户的业务需求，提供了两条数据链路：\n 在需要保留单机明细数据的情况下，走基于网关的明细数据采集链路；\n 在需要数据聚合的情况下，走基于 Spark 的聚合数据采集。\n 1.1 基于网关的明细数据采集 为了使保留明细数据跳过计算集群直接存储，我们研发上线了一套专门服务 Metrics 数据的中心化采集 + push 存储的链路。\n中心化采集相对于传统的 agent 采集，不再需要依赖于部署在每台物理机，而是只通过 HTTP 请求的方式采集 Metrics 数据。中心化采集对 Metrics 的采集配置进行结构化的下发和调度，以此满足了 Metrics 采集对时间戳调度精确性的要求。并且，中心采集对采集到的数据不存内存，而是直接以 push 的方式推送给 PushGateway，由 gateway 直接存储至底层 CeresDB。\n这套采集方案，满足了 Metrics 对时间精度和存储单机数据的要求。并且将 Metrics 数据采集与现有的日志采集接耦，使二者互不干扰，解放了对 agent 内存和计算资源的高消耗。\n该套方案已经成功用于蚂蚁 Sigma 等多个技术栈和基础设施的 Prometheus 采集，目前每分钟处理上亿条指标数据。\n1.2 基于 Spark 的聚合数据采集 以 Sigma 为代表的基础设施监控，对单机明细数据有较大需求。但是保留明细数据也有较大的缺点，例如：数据量庞大，对存储消耗较高；数据查询时，耗时和数据读取量巨大。\n但是对于一些业务应用用户，对单机明细数据并不关注，只关注于一些维度的聚合数据。例如，以机房维度、集群维度等。因此在这种场景下，存储明细数据，会造成较大的存储浪费，并且在数据查询时，会带来很差的用户体验。因此在这种场景下，我们保留了目前 AntMonitor 传统的日志链路，对采集的 Metrics 单机明细数据进行了聚合进行存储。在业务不关注单机明细数据的场景下，这条链路拥有明显的好处，节省了存储空间，提升了用户查询的速度。\n但是不同于日志监控的数据聚合，必须由用户配置聚合规则，由于 Metrics 数据本身就包含 schema 信息，我们通过自动化的配置项，自动对 Gauge、Counter、Histogram 等 metric type 自动为用户生成了聚合配置，免去了用户手动配置聚合的繁琐：\n下图总结对比了数据聚合与不聚合的区别和优劣：\nPART. 2 维表体系下的元数据统一 原生 Prometheus 提供多种服务发现机制，如 K8s 服务发现通过 apiserver 可以自动获取发现采集的 targets。但是，AntMonitor 作为一个蚂蚁统一监控系统，显然是不能通过 apiserver 自动发现监控目标。\nAntMonitor 在日志监控的现有基础上，建设有一套较为完善的元数据维表体系，包含了 SOFA、Spanner、OB 等多个蚂蚁技术栈元数据。元数据告诉我们去哪里采集监控数据，对应原生的服务发现机制。为了拉齐原生功能，我们对部分维表进行了必要改造，此处我们以 Sigma 监控的落地实践为例，简要介绍下我们的元数据同步流程。\n2.1 Sigma 元数据同步 AntMonitor 进行 Sigma 监控的前提是要获取元数据，元数据告诉我们去哪里采集监控数据。\n为此，我们设计了基于 RMC（蚂蚁的统一元数据平台） 的 “全量同步+增量同步” 元数据同步方案。前者保证元数据齐全可靠，后者基于 AntQ 实现，保证了元数据的实时性。\n从图中可以看到，为了对齐原生的 staleness 功能，Sigma pod 元数据统一添加了下线 (offline) 这个中间状态。\n原生 Prometheus 通过 relabeling 功能实现采集目标过滤等，还可以通过 metric relabeling 对拉取到 …","date":1645772400,"description":"2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践","dir":"blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a8d933b0202e682ad456783714a58ed6","permalink":"https://sofastack.github.io/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","publishdate":"2022-02-25T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","summary":"文｜陈岸琦（花名：敖清 ) 蚂蚁集团高级开发工程师 负责蚂蚁 Prometheus 监控原生功能，在蚂蚁集团的落地与产品化建设 本文 6566 字 阅读 15 分钟 前 言 日志和指标是监控不可","tags":["SOFAStack"],"title":"2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践","type":"blog","url":"/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","wordcount":4491},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@徐豪 提问：\n 想了解 Ark 动态模块，如何在 IDEA 里面进行开发调试？\n A：这个和普通工程基于 idea 调试没有什么区别的，你的 issue 里面提到要调试模块，那就在安装模块的时候，将断点打在你关注的代码行。\n 目前我没有看到相关的 guide，然后自行尝试，先启动容器，再手工启动模块，感觉没成功，不清楚问题出在哪？\n A：～/logs/sofa-ark 看看有日志吗？\n@孙英雄 提问：\n 请问伙伴们有在用 SOFA 技术栈在非金融的项目开发吗？\n A：有的哈，可以看下使用者登记 https://github.com/sofastack/sofa-rpc/issues/375https://github.com/sofastack/sofastack.tech/issues/5\n@来永国 提问：\n 升 SpringBoot to 2.4.x 还有计划吗？\n A：GitHub 上有一些 exmaple，你可以先玩玩。这个今年在规划了，下个 SOFABoot 版本 3.11.0 将会升级到 Spring Boot 2.4.13。\nhttps://www.github.com/mosn/mosn/tree/master/examples%2Fcn_readme%2Fdubbo-examples\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 技术人聊开源：这并不只是用爱发电\n应用运行时 Layotto 进入 CNCF 云原生全景图\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\n","date":1645772400,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220228/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a61ff0d87e7608cc95b2de68338812bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220228/","publishdate":"2022-02-25T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220228/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220228/","wordcount":838},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践\n 活动时间：02 月 24 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践 Kubernetes 已经成为行业内，容器编排的标准。越来越多的企业开始在生产中使用 Kubernetes，拥抱云原生。\nKubernetes 为什么要持续迭代升级？大规模集群下升级过程将面临哪些问题？如何在复杂问题中找到一条无损升级路子？本次分享将用40分钟时间带你一起庖丁解牛 Kubernetes 的升级难题。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 王连平（花名：烨川） 蚂蚁集团高级工程师。 负责蚂蚁 Kubernetes 集群容器交付方面工作，专注于集群交付能力、交付性能及交付Trace等相关领域。 议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:50 蚂蚁大规模 Kubernetes 集群无损升级实践 王连平（花名：烨川），蚂蚁集团高级工程师\n你将收获 了解大规模 Kubernetes 集群升级核心问题 了解核心问题背后的 Kubernetes 设计理念 了解蚂蚁在解决这些问题的一些思路 一起探讨 Kubernetes 这个庞然大物的未来升级之道 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1645686000,"description":"02 月 24 日周四晚 19 点，线上直播第 25 期。","dir":"activities/sofa-channel-25/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4e7019a0dffc50381dc10af4c627eaf6","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-25/","publishdate":"2022-02-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-25/","summary":"概要 活动主题：SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践 活动时间：02 月 24 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践","type":"activities","url":"/sofastack.tech/activities/sofa-channel-25/","wordcount":655},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区获奖啦 SOFAStack 团队在 segmentfault 思否颁布的2021 年中国技术先锋年度评选中，荣获“中国技术品牌影响力企业” 。\n SOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@Nothing 提问：\n 请教个问题，一个服务的订阅者实例数很多的情况下，如果所有订阅者都与 provider 建立连接，provider 的连接数压力大，SOFARegistry 是怎么考虑这种情况的?\n A：目前正在做 host subset 的设计，注册中心端会直接进行分片，减少客户端压力。现在开源版本的 SOFARegistry 还不具备这个的能力，我们内部也是采用全链接。可以了解一下 MOSN ，MOSN 有类似分片功能，内部也有大规模落地。\n@老段 提问：\n 如果启动三个节点的话，停掉一个节点，系统就会一直选举，不再提供服务了；如果启动五个节点的话，停掉两个节点，系统就会一直选举，也不再提供服务了。这个正常么？\n A：不正常，我这边 3 个节点，kill 一个 follower 完全没影响，kill leader 也可以很快选举完成。不会一直选举，服务可以提供，只不过日志里会去找那个挂了的节点。\n@张永欣 提问：\n MOSN 怎么配置 dubbo 连接，支持自发现 dubbo 服务吗？\n A：github 上有一些 exmaple，你可以先玩玩：\nhttps://www.github.com/mosn/mosn/tree/master/examples%2Fcn_readme%2Fdubbo-examples\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 技术人聊开源：这并不只是用爱发电\n应用运行时 Layotto 进入 CNCF 云原生全景图\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\n","date":1645167600,"description":"SOFA Weekly |荣获“中国技术品牌影响力企业”、开发者的搬砖日常、QA 整理","dir":"blog/sofa-weekly-20220218/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ba96ccb01c0806da34a4f846db7ccdec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220218/","publishdate":"2022-02-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220218/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |荣获“中国技术品牌影响力企业”、开发者的搬砖日常、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220218/","wordcount":990},{"author":"金融级分布式架构","categories":"SOFAStack","content":" 2022 年 2 月 10 日，CNCF 发布了最新版本的 Landscape。\nLayotto 正式加入 CNCF 云原生全景图!\n分类在 Serverless framework 板块下，详情见 ：https://l.cncf.io/serverless\n意味着 Layotto 正式成为了CNCF 认可的构建云原生最佳实践中的一环。\nCNCF 简介 云原生计算基金会（CNCF, Cloud Native Computing Foundation）致力于云原生技术的普及和可持续发展。\nCNCF Landscape 意图从云原生的层次结构，以及不同的功能组成上，让用户了解云原生体系的全貌。同时，也受到广大开发者和使用者对该项目的关注和重视。\nLayotto 简介 Layotto(/leɪˈɒtəʊ/) 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。\n它为应用提供了各种分布式能力，比如状态管理、配置管理、事件发布订阅等能力，以简化应用的开发。\n更多关于 Layotto 的内容可以查看：\n云原生运行时的下一个五年\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\nLayotto Star 一下✨： https://github.com/mosn/layotto\n新的一年 Layotto 除了继续优化 service mesh 和 multi-runtime 方面的功能外，也会投入精力融入开源 serverless 生态。\n接下来会和大家分享下 2021 年 Layotto 的落地总结，以及新一年的 roadmap，欢迎关注!\n想要初步接触 Layotto 的技术同学，可以从我们的技术任务入手，欢迎大家一起来玩～\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n想要了解更多关于 Layotto 的最新动态\n👐 欢迎添加微信小助手进群，随时提问 👐\n本周推荐\n云原生运行时的下一个五年\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n","date":1644822000,"description":"应用运行时 Layotto 进入 CNCF 云原生全景图","dir":"blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6521f348ceee0dc3067e03c8209f4a01","permalink":"https://sofastack.github.io/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","publishdate":"2022-02-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","summary":"2022 年 2 月 10 日，CNCF 发布了最新版本的 Landscape。 Layotto 正式加入 CNCF 云原生全景图! 分类在 Serverless framework 板块下，详情见 ：https://l.cncf.","tags":["SOFAStack"],"title":"应用运行时 Layotto 进入 CNCF 云原生全景图","type":"blog","url":"/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","wordcount":742},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@小楼 提问：\n 请问 session 是如何支持 Dubbo 的元数据的？\n A：Registery 的元数据现在不是通用的，只针对 SOFARPC。\n session 之间应该是没有数据同步的吧，跨 session 节点怎么办呢？\n A：现在会同步两个信息，一个是元数据，一个是接口级订阅，接口级订阅是用于兼容没升级的应用。同步的路径是通过存储，类似 K8 的 listwatch 机制，内部落地存储的插件实现是 db，这个块数据比较少，就几千行吧，而且变化很小。\n「SOFARegistery」：https://github.com/sofastack/sofa-registry\n@来永国 提问：\n 为什么我起了 RPC 服务端客户端和注册中心，然后连接调用是可以的，然后我把注册中心关了，它还是跑得通？\n A：client 会有缓存的。\n 获取注册中心的服务有 API 接口吗?\n A：有的，有个从单机 session 获取数据的接口 curl localhost:9603/digest/pub/data/query?dataInfoId=com.test.SimpleService#@#DEFAULT_INSTANCE_ID#@#DEFAULT_GROUP dataInfoId 参数需要进行 url encode 应该还没公开的 API 文档，获取数据的 HTTP 接口也不太易用，我最近会补一下文档还有方便使用的接口。\n 那看样子这个相当于是指定搜索了吗？\n A：是的，目前没有模糊查询的接口， curl localhost:9603/digest/getDataInfoIdList 你可以用这个 API grep 一下。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@东仔 提问：\n SOFABolt 的最新分支是哪个？\n A：https://github.com/sofastack/sofa-bolt master 就是最新分支。\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n","date":1644562800,"description":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220211/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b55336c3e1f02336f659e4eedb771ea7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220211/","publishdate":"2022-02-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220211/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220211/","wordcount":1170},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@来永国 提问：\n 想问下，发现在 SOFA 的 spi 加载扩展的时候，是有做到 getExtensionLoader 遍历 META-INF 的，但是没搞懂是怎么做到的。br/ A：在这个方法里: com.alipay.sofa.rpc.ext.ExtensionLoader#loadFromFile，getResource 这边可以获得多个文件。\n@半个馒头 提问：\n 多次提交 raft 日志会自动触发 jraft 的 leader 转移吗？\n A：不会，可能是其他场景触发的。\n steps down when alive nodes don\u0026amp;rsquo;t satisfy quorum.\n A：是 leader 中发现半数节点在心跳周期内没有心跳了。\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 喜迎虎年｜开源正当时！\n2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n","date":1643958000,"description":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20220204/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b8eaeb7040dab97c5de595df79e1bc7c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220204/","publishdate":"2022-02-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220204/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220204/","wordcount":747},{"author":"金融级分布式架构","categories":"SOFAStack","content":" Awesome SOFAer 👋:\n大家好，\n我是 SOFAStack 社区的负责人——齐天\n虎年伊始，我谨代表 SOFAStack 社区\n祝大家新年快乐！\n在新的一年事事如意，虎虎有生气！\nPart 01 开源正当下！ 回想起 6 年前，在 Github 写下第一行 Apollo 的代码时。\n那时国内的开源社区是这样一番景象：\nDubbo 还没被唤醒、很多现在耳熟能详的项目还在襁褓中、开源社区的贡献者寥寥无几、少量的活跃项目凭着核心个人开发者对技术的热爱维持着。虽然使用开源产品的公司很多，但是做开源产品却是一种非常小众的行为。\n然而最近几年开源却一下子火了起来，成为了技术圈的时髦热词，在各种场合被频频提起。\n究其原因，我想一方面是开源商业化的模式诞生了以 Confluent、GitLab、HashiCorp 为代表的百亿美元上市公司群体，证明了开源的商业价值，吸引到了资本的关注；\n另一方面从政策层面，工业和信息化部印发了《“十四五”软件和信息技术服务业发展规划》，其中提到了要提升关键软件供给能力，加快繁荣开源生态，建设 2-3 个有国际影响力的开源社区。\n在这些因素的刺激影响下，国内的开源行业得到了迅猛的发展，诞生了开放原子基金会以及以木兰社区为代表的诸多综合性开源社区，众多基于开源项目的创业公司也纷纷获得融资，不完全统计列表如下：\n● 2021 年 3 月深圳支流科技 API7 完成 Pre-A 轮（基于 Apache APISIX 项目）\n● 2021 年 4 月上海硅智信息技术 Kyligence 完成 D 轮融资（基于 Apache Kylin 项目）\n● 2021 年 5 月北京思斐软件 SphereEx 完成天使轮融资（基于 Apache ShardingSphere 项目）\n● 2021 年 5 月涛思数据 TaosData 完成 B 轮融资（开源物联网大数据平台 TDengine）\n● 2021 年 10 月 StreamNative 获得 A 轮融资（基于 Apache Pulsar 项目）\n● 2021 年 11 月白鲸开源获得数百万美元种子轮融资（基于 Apache DolphinScheduler）\n● 2021 年 11 月开源数据库结构变更和版本管理 ByteBase 获得三百万美元种子轮融资\n● 2022 年 1 月 SphereEx 又完成了 Pre-A 轮融资\n可以说，「开源正当时！」\nPart 02 如何正确对待开源？ 然而，繁华之下也有隐忧。\n很多企业看到了开源的商业价值，所以纷纷投入大量资源，有了投入自然对回报就有着期待。在这种情形下一个不合理的 KPI 很容易就会让开源动作走样，诸如点 star 拿礼物、大量提交修改错别字的 commit 等行为也屡见不鲜。\n而另一方面有些底层开源项目如 Log4j2 虽然很重要，但是由于没有明显的商业价值，企业没有动力投入资源，以至于只有少数开发者无偿、自愿地进行维护，在曝出严重漏洞后大家才意识到原来开源软件供应链的根基竟是如此脆弱。\n那么，回到我们自身\u0026amp;hellip;\n应该如何正确对待开源呢？ 我的思绪再次拉回到 6 年前，当时的我对开源还懵懵懂懂，把代码贡献到 GitHub 的出发点非常纯粹：作为一名软件工程师，写了一份自己认为还过得去的代码，解决了一些通用问题，就希望让这份代码发挥更大的作用，同时也能通过代码会友，大家一起交流技术、分享心得，岂不乐哉？至于能获得多大的影响力、有多大的商业价值，当时是没有任何概念的。\n现在想来，似乎是有一分盲目和冲动在，一种想把好东西分享出去的冲动。\n当然了，要把开源项目做好，光有一时的冲动是不够的。做过开源项目的朋友基本都有一个共识，那就是做开源项目非常枯燥，日复一日地处理 issue、review pr，时不时还会遇到伸手党不合理的需求，稍有怠慢还会招来无端的指责。\n那到底是什么支撑我投入开源这么多年呢？ 想来想去应该还是兴趣吧\u0026amp;hellip;\n对技术的兴趣让这些重复性的事情显得不那么枯燥，而通过开源又结交了很多志趣相投的朋友，大家在一起既可以聊技术，也可以聊生活，虽然身处五湖四海，甚至素未谋面，但相谈甚欢，正是这样开放、有趣的社区让兴趣得以持续保鲜。\n而这也正是 SOFAStack 的开源理念，我们希望在喧嚣中依然保持乐于分享的初心，打造开放、有趣的技术社区。通过开放让更多的人加入进来，通过有趣让大家留下来并持续分享、交流，相互学习、相互成长。\n比如在开放方面，我们通过 Github、Meetup、直播、公众号、视频号等多种渠道和大家进行技术交流。\n 在社区治理上，我们也是完善了社区的晋升机制，鼓励贡献者以不同形式来影响社区走向，不少项目如 MOSN、Layotto 都有较大比例的外部 Committer。\n 在社区合作方面，我们和包括 Envoy、Dapr、Seata 等国内外社区进行了深度的技术共建，在传播方面也是和云原生社区、字节码联盟的 WAMR 社区等一起联合举办了多场 Meetup，为社区带来了精彩的技术分享。\n 而在有趣方面，虽然我们这些工程师平时看上去都挺严谨的，但其实私下里还都有好玩的一面。所以我们的视频号也是不断尝试新的视频形式，就是希望营造一个比较轻松、有趣的环境来和大家进行技术交流，在快乐中学习和成长。\n虎年准备做的几件事 SOFARegistry V6 虽然 SOFARegistry V5 版本早已在 GitHub 上开源，其性能、容量、稳定性上也都达到了比较高的水平，不过在日常运行中还是存在不少痛点。所以我们对 V6 版本做了大幅重构，在性能、稳定性、可运维性等方面都取得了较大的突破并在生产环境完成全量上线（降本提效！注册中心在蚂蚁集团的蜕变之路），相信不管是一家中小规模的公司还是一家大型企业，SOFARegistry 都会是一个比较靠谱的选项。\n而在研发这个版本的过程中我们也沉淀了针对注册中心场景的混沌测试工具，也将于近期和大家见面，希望能帮大家更好地评估各类开源注册中心的能力极限，以便选择最适合自己的产品。\nMOSN 目前 MOSN 作为 Service Mesh 的数据面在蚂蚁生产环境已经覆盖了数十万容器，切实解决了我们在基础设施独立演进上的痛点，在社区也有将近 20 家公司登记使用。不过总体来看，使用门槛还是比较高。\n所以今年我们会开源一个 MOSN 的管控面产品，从而端到端打通 MOSN 的使用场景，降低使用难度，造福更多的用户。\nLayotto Layotto 作为云原生运行时的下一个五年的重要载体，今年我们会继续投入精力和 Dapr 社区一起推动 API 标准化向前演进，重新定义基础设施的边界。同时也会探索 Layotto on Envoy 的运行方式，从而只需运维一个 Sidecar 即可同时具备 Service Mesh 和应用运行时的能力。\n在函数运行时方面，去年我们在 KubeCon 演示了通过 K8s 标准语义把一个 WASM 模块调度到 Layotto 进程中运行，今年在这个方向也会继续向前探索更多可能性。\n去年 4 月，SOFAStack 社区在北京和大家度过了一个愉快的三周岁生日，也标志着社区逐渐走向成 …","date":1643871600,"description":"喜迎虎年｜开源正当时！","dir":"blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d95d0ce2c5f132fcd207d1701c64c415","permalink":"https://sofastack.github.io/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","publishdate":"2022-02-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","summary":"Awesome SOFAer 👋: 大家好， 我是 SOFAStack 社区的负责人——齐天 虎年伊始，我谨代表 SOFAStack 社区 祝大家新年快乐！ 在新的一年事事如意，虎虎有生气！ Part 01 开源正当下！ 回想起 6 年","tags":["SOFAStack"],"title":"喜迎虎年｜开源正当时！","type":"blog","url":"/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","wordcount":2729},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@李雪涛 提问：\n 请问 MOSN 插件的管理接口应该怎么调用，里面的 IP 和 port，IP 应该指的是 Pod 的 IP 吧，那 port 指的是什么呢?br/ A：通过 admin 得配置。 https://www.github.com/mosn/mosn/tree/master/configs%2Fmosn_config.jso\n「MOSN」：https://github.com/mosn/mosn\n@李雪涛 提问：\n 我的插件参考的： https://github.com/mosn/mosn/blob/istio-1.10/examples/codes/plugin/pluginfilter/pluginfilter.go\n 但是我利用 admin 接口 enable 的时候输出的是插件未注册的错误，能帮我看一下我的插件注册部分哪里写的不对吗？\n插件的 client 的注册相关的代码： https://www.codepile.net/pile/EK6Om3A6\nA：镜像的配置有这个 plugin 吗？或者你先别用那个 Istio，现本地打包测试下，直接二进制启动试试： 1. 看配置，有没有 paper 的 filter 配置 2. MOSN 的 main 文件需要 import 你的 paper 文件，因为注册用的 init 3. 看下启动日志： https://github.com/mosn/mosn/blob/master/cmd/mosn/main/mosn.go\n「MOSN」：https://github.com/mosn/mosn\n@来永国 提问：\n 我把透传写在 SOFARPC 拦截器里，服务端接收不到客户端透传的参数。\n A：确实是这样，baggage 处理在 filter 之前。\n 还有什么更优雅的方式吗？那我非要只在 filter 里加透传要怎么做呢？\n A：非要在 filter 里面处理 baggage 的话,可以直接操作 SOFARequest 对象的 RequestProp. RemotingConstants.RPC_REQUEST_BAGGAGE，可以参考 com.alipay.sofa.rpc.context.BaggageResolver#carryWithRequest 类。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n","date":1643439600,"description":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220129/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"930109d877cef64f3e5441f23528dd16","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220129/","publishdate":"2022-01-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220129/","wordcount":1066},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王辉 提问：\n 那 6.x 版本相比 5.x 版本，缺失了哪些功能，有列表么？\n A：providedata 的功能还在，但通过 session 透出的 watcher 还没有支持，其他的功能没有缺失。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@李雪涛 提问：\n 请问自定义一个 streamfilter，可以在这个 filter 中获取当前请求的目的 IP 吗?\n A：可以的哈，通过变量就可以获取 。\n具体内容可以参考下方文档：\nhttps://www.github.com/mosn/mosn/tree/master/pkg%2Fproxy%2Fvar.go\n「MOSN」：https://github.com/mosn/mosn\n@王宇阳 提问：\n 请教一下 MOSN 做网关会对 HTTP 协议中没有带 content-type 的请求头做处理吗，比如加一个默认的这样？\n A：如果响应 header 没有携带 content-type 的话则默认加一个 “text/plain; charset=utf-8” 的 content-type。\n（注：MOSN 中的 HTTP 解析这块使用的 fasthttp 的库，目前这块会有这个默认操作。）\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 叮，你有一份开发者问卷到了\n一图看懂 SOFAStack 社区的 2021 ｜文末有“彩蛋”\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n","date":1642748400,"description":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220121/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e77bc7011b07dcfa07b22d729631a09d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220121/","publishdate":"2022-01-21T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220121/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220121/","wordcount":971},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#24：漫谈 HTTP/3 进化史\n 活动时间：01 月 20 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#24：漫谈 HTTP/3 进化史 HTTP/3 协议栈可以说是当前 4\u0026amp;frasl;7 层协议的集大成者，它浓缩了大量现有协议的最佳实践及优化技巧。\n那么 HTTP/3 是如何一步一步发展成今天这个样子的呢？它解决了什么样的问题？未来又还会走向何方？\n本次分享将用 50 分钟的时间，带你走近 HTTP/3 的世界，一一解读这些问题\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 曾柯（花名：毅丝） 蚂蚁集团高级工程师。 负责蚂蚁集团的接入层建设工作，主要方向为高性能安全网络协议的设计及优化 议程 18:50-19:00 主持人开场 SOFA 社区小助手-泡椒 主持人\n19:00-19:50 漫谈 HTTP/3 进化史 曾柯（花名：毅丝），蚂蚁集团高级工程师\n你将收获 了解4/7层协议的发展历程 了解HTTP/3解决的问题 一起展望HTTP/3的未来 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1642662000,"description":"01 月 20 日周四晚 19 点，线上直播第 24 期。","dir":"activities/sofa-channel-24/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2f719fc9371adf2f0f5a9de7f21c47cd","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-24/","publishdate":"2022-01-20T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-24/","summary":"概要 活动主题：SOFAChannel#24：漫谈 HTTP/3 进化史 活动时间：01 月 20 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播间地址：h","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#24：漫谈 HTTP/3 进化史","type":"activities","url":"/sofastack.tech/activities/sofa-channel-24/","wordcount":584},{"author":"杜克伟","categories":"SOFAStack","content":" 文｜杜克伟（花名：苏麟 )\n蚂蚁集团高级开发工程师\n负责蚂蚁 Kubernetes 集群的稳定性方面的工作，专注于集群组件变更、稳定性风险保障\n本文 15738 字 阅读 20 分钟\n前 言 为了支撑蚂蚁业务的迭代升级，蚂蚁基础设施今年启动了 Gzone 全面云化项目。要求 Gzone 需与已经云化的 Rzone 合并部署在同一个集群，Sigma 单集群实际管理的节点规模将超过万台，单集群承担的业务也将更加复杂。\n因此我们启动了大规模 Sigma 集群的性能优化方案，在请求延迟上期望能够对齐社区标准，不因规模增长的原因下降。\netcd 作为 Sigma 集群的数据存储数据库，是整个集群的基石，能够直接决定性能天花板。社区建议的单 etcd 集群存储限制是 8G, 而蚂蚁 Sigma 集群的单 etcd 集群存储量早已超过了这个限制，Gzone 上云项目势必会加重 etcd 的负担。\n首先，蚂蚁业务混合了流失计算、离线计算和在线业务，混合大量的生命周期在分钟级甚至是秒级的 Pod，单集群每天的 Pod 创建量也提升到了数十万, 都需要 etcd 来支撑；\n其次，复杂的业务需求催生了大量的 List (list all、list by namespace、list by label)、watch、create、update、delete 请求，针对 etcd 的存储特性，这些请求性能均会随着 etcd 存储规模的增大而严重衰减，甚至导致 etcd OOM，请求超时等异常；\n最后，请求量的增长也加剧了 etcd 由于 compact、defrag 操作对请求 RT P99 的暴涨，甚至请求超时，从而导致集群关键组件调度器、CNI 服务等 Operator 类组件间断性丢失，造成集群不可用。\n根据前人的经验，针对 etcd 集群进行数据水平拆分是一个有效的优化手段，典型的拆分是把 Pod 等重要数据单独 etcd 集群来存储，从而降低单 etcd 存储和请求处理的压力，降低请求处理延迟。但是 Pod 资源数据针对 Kubernetes 集群具有特殊性，具有其他资源没有的高要求，尤其是针对已颇具规模正在服务的 K8s 集群进行拆分更是需要万分谨慎小心。\n本文主要记录了蚂蚁集团在进行 Pod 资源数据拆分过程中一些实践经验和心得。\n抛砖引玉，请大家多多指教！\nPART. 1 面临的挑战 从前人的 Pod 数据拆分经验了解到，Pod 数据拆分是一个高危且复杂的流程，原因来自于 Pod 数据自身的特殊性。\nPod 是一组容器的组合，是 Sigma 集群中可调度的最小单位，是业务 workload 的最终承载体。Sigma 集群的最核心最终的交付资源就是 Pod 资源。\nSigma 集群最核心的 SLO 也是 Pod 的创建删除升级等指标。Pod 资源数据可以说是 Sigma 集群最重要的资源数据。同时 Sigma 集群又是由事件驱动的，面向终态体系设计，所以 Pod 资源数据拆分除了考虑基本的前后数据一致性问题外，还要考虑拆分过程中对其他组件的影响。\n前人的拆分经验流程中最核心的操作是数据完整性校验和关键服务组件停机。数据完整性校验顾名思义是为了保证数据前后的一致性，而关键服务组件停机是为了避免拆分过程中如果组件不停机造成的非预期后果，可能会有 Pod 非预期删除，Pod 状态被破坏等。但是如果照搬这套流程到蚂蚁 Sigma 集群，问题就来了。\n蚂蚁 Sigma 作为蚂蚁集团核心的基础设施，经过 2 年多的发展已经成为拥有 80+ 集群、单集群节点数可达到 1.2w+ 规模的云底座。在如此规模的集群上，运行着蚂蚁内部百万级别的 Pod，其中短运行时长 Pod 每天的创建量在 20w+次。为了满足各种业务发展需求，Sigma 团队与蚂蚁存储、网络、PaaS 等多个云原生团队合作，截止目前 Sigma 共建的第三方组件量已经达到上百个。如果 Pod 拆分要重启组件，需要大量的与业务方的沟通工作，需要多人共同操作。如果操作不慎，梳理不完全漏掉几个组件就有可能造成非预期的后果。\n从蚂蚁 Sigma 集群现状总结一下已有的 Pod 数据拆分经验流程的问题：\n1. 人工操作大量组件重启时间长、易出错 潜在需要重启的组件高达数十个，需要与各个组件 owner 进行沟通确认，梳理出需要重启的组件，需要耗费大量的沟通时间。万一遗漏就可能造成非预期的后果，比如资源残留、脏数据等。\n2. 完全停机持续时间长打破 SLO 数据拆分期间组件完全停机，集群功能完全不可用，且拆分操作极为耗时，根据前人经验，持续时间可能长达 1~2 小时，完全打破了 Sigma 集群对外的 SLO 承诺。\n3. 数据完整性校验手段薄弱 拆分过程中使用 etcd 开源工具 make-mirror 工具来迁移数据，该工具实现比较简单，就是读取一个 etcd 的 key 数据然后重新写到另一个 etcd，不支持断点续传，同时因重新写入 etcd 造成原有 key 的重要字段 revision 被破坏，影响 Pod 数据的 resourceVersion, 可能会造成非预期后果。关于 revision 后文会详细说明。最后的校验手段是检验 keys 的数量是否前后一致，如果中间 key 的数据被破坏，也无法发现。\nPART. 2 问题解析 美好的期望 作为一个懒人，不想和那么多的组件 owner 沟通重启问题，大量组件重启也易造成操作遗漏，造成非预期问题。同时是否有更好的数据完整性校验的手段呢？\n如果组件不重启，那么整个过程后演变为下面的流程，预期将简化流程，同时保障安全性。\n为了达成美好的期望，我们来追本溯源重新 review 整个流程。\n数据拆分是在做什么？ 众所周知，etcd 存储了 Kubernetes 集群中的各种资源数据，如 Pod、Services、Configmaps、Deployment 等等。\nKube-apiserver 默认是所有的资源数据都存储在一套 etcd 集群中，随着存储规模的增长，etcd 集群会面临性能瓶颈。以资源维度进行 etcd 的数据拆分来提升 Kube-apiserver 访问 etcd 的性能是业内所共识的经验优化思路，本质是降低单 etcd 集群的数据规模，减少单 etcd 集群的访问 QPS。\n针对蚂蚁 Sigma 集群自身的规模和需求，需拆分为 4 个独立的 etcd 集群，分别存储 Pods、Leases、event 和其他资源数据，下面分别简要说明这前三类(Pods、Lease、event)需要拆分出去的资源数据。\nEvent 资源 K8s event 资源数据并不是 watch 中的 event，一般是表示关联对象发生的事件，比如 Pod 拉取镜像，容器启动等。在业务上一般是 CI/CD 需要流水式展示状态时间轴，需要频繁拉取 event 资源数据。\nevent 资源数据本身就是有效期的（默认是 2 小时），除了通过 event 观测资源对象生命周期变化外，一般没有重要的业务依赖，所以说 event 数据一般认为是可以丢弃，不需要保障数据前后一致性的。\n因为上述的数据特点，event 的拆分是最为简 …","date":1642489200,"description":"蚂蚁大规模 Sigma 集群 Etcd 拆分实践","dir":"blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d2c7a90fb1f46225bb634988b092d058","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","publishdate":"2022-01-18T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","summary":"文｜杜克伟（花名：苏麟 ) 蚂蚁集团高级开发工程师 负责蚂蚁 Kubernetes 集群的稳定性方面的工作，专注于集群组件变更、稳定性风险保障 本文 15738 字 阅读 20 分钟 前 言 为了","tags":["SOFAStack"],"title":"蚂蚁大规模 Sigma 集群 Etcd 拆分实践","type":"blog","url":"/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","wordcount":8750},{"author":"杨洋","categories":"SOFAStack","content":" 文｜杨洋（花名：凯申 )\n蚂蚁集团高级技术专家\n负责密码学工程能力建设、BabaSSL 开源社区建设\n本文 2366 字 阅读 5 分钟\n近日，国内著名 Web 服务器和反向代理开源软件 TengineBabaSSL 完成了对 BabaSSL的适配工作。\nTengine 对 BabaSSL 提供的特殊 API 进行了适配，并增加对 NTLS 相关能力的支持。\n「详细 Pull Request 请见」：https://github.com/alibaba/tengine/pull/1595\n至此，对我国密码行业相关安全通信协议，有使用需求的用户可以直接使用 Tengine + BabaSSL 的组合。而无需额外的 patch 或者代码改动，从用户使用的角度进一步提升了便利性。\nPART. 1 NTLS 目前，我国密码行业中有两个主要的通信协议相关的技术标准。一个是由信安标委于 2020 年发布的 TLCP 协议，即传输层密码协议；另外一个则是由密标委在 2012 年发布的 GM/T 0024《SSL VPN 技术规范》（以下简称 0024）。\nTLCP 和 0024 的具体内容差别不大，均是从 TLS 协议发展而来，他们的主要特点是将商用密码算法 SM2、SM3 和 SM4 应用到了 TLS 协议中，并使用 SM2 密钥交换机制替换掉了 TLS 协议原有的密钥交换流程。\nTLCP 和 0024 另外一个显著的特点将 TLS 协议中使用的数字证书拆分成了加密和签名两种用途的证书，加密证书和签名证书以及对应私钥均需要进行配置使用，所以 TLCP 和 0024 也俗称“国密双证书”协议。\nBabaSSL 对上述国密双证书协议进行了支持，并统称为 NTLS。\nNTLS 的全名为 National TLS，即我国核准的传输层安全协议，所以也可以叫做国密 TLS。\n由此可见，NTLS 并不是指某一种具体的符合商用密码相关技术标准要求的网络协议，而是多个协议的统称。在 BabaSSL 中代指 TLCP 和 0024 国密双证书协议，因为 NTLS 和标准 TLS 协议存在工作方式的不同，因此 BabaSSL 中增加了一些新的 API 来对其进行支持。而应用程序若想使用 NTLS 功能，就需要调用这些新增 API，给现有基于 OpenSSL API 进行适配的应用程序带来了额外的开发工作量。\nPART. 2 Tengine + BabaSSL Tengine 是由淘宝网发起的 Web 服务器项目，它在 Nginx 的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。\nTengine 的性能和稳定性已经在大型的网站(如淘宝网，天猫商城等)得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的 Web 平台。\nTengine 作为国内知名的开源 Web 服务器软件，在各领域均得到了广泛的使用且享有很高的知名度。\nBabaSSL 是一款轻巧、灵活且靠谱的密码学和 TLS 协议工具集。BabaSSL 是蚂蚁集团和阿里集团的各主要业务中所使用的底层密码库，目前开源出来供业界使用。BabaSSL 广泛的应用在包括网络、存储、移动端 App 等场景中。\nTengine 来源于 Nginx，所以默认使用的是 OpenSSL。此次 Tengine 针对 BabaSSL 中的 NTLS 功能进行了适配，用户如果选择使用 BabaSSL 作为 Tengine 的底层密码库来实现通信加密的能力，则可以无需对 Tengine 进行任何代码改动，原生开启 NTLS 能力。\nPART. 3 Tengine 启用 NTLS 具体来说，此次在 Tengine 中增加了几个新的指令，对 NTLS 进行支持。\n1. 下载 BabaSSL 和 Tengine 前往 👇 下载 BabaSSL 的源代码包: https://github.com/BabaSSL/BabaSSL/releases\n 前往 👇 获取 Tengine 的最新代码: 「git clone」\nhttps://github.com/alibaba/tengine.git\n2. 编译 BabaSSL 和 Tengine 使用如下配置：\n./configure --add-module=modules/ngx_openssl_ntls \\ --with-openssl=../path/to/BabaSSL \\ --with-openssl-opt=\u0026amp;quot;--strict-warnings enable-ntls\u0026amp;quot; \\ --with-http_ssl_module --with-stream \\ --with-stream_ssl_module --with-stream_sni 3. 配置 Tengine 开启 NTLS 一个开启了 NTLS 的 Tengine 配置文件的例子：\nworker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; server { listen 443 ssl; server_name localhost; enable_ntls on; ssl_sign_certificate server_sign.crt; ssl_sign_certificate_key server_sign.key; ssl_enc_certificate server_enc.crt; ssl_enc_certificate_key server_enc.key; location / { return 200 \u0026amp;quot;body $ssl_protocol:$ssl_cipher\u0026amp;quot;; } } } stream { server { listen 8443 ssl; enable_ntls on; ssl_sign_certificate server_sign.crt; ssl_sign_certificate_key server_sign.key; ssl_enc_certificate server_enc.crt; ssl_enc_certificate_key server_enc.key; return \u0026amp;quot;body $ssl_protocol:$ssl_cipher\u0026amp;quot;; } } 4. 测试 NTLS 可以使用 BabaSSL 的 s_client 工具对开启了 NTLS 的 Tengine 进行测试。\n「具体可以参考」：\nhttps://babassl.readthedocs.io/zh/latest/Tutorial/SM/ntls/\nPART. 4 总 结 随着互联网业务的发展，在新时期下，数据成为了影响人们正常生活的核心要素。\n因此数据安全和个人信息保护等问题变得更加需要重视，国家近期也针对数据安全领域进行了相关立法。\n密码学技术作为整个信息安全领域的基础技术能力，对数据安全也存在着很大的影响。同时 …","date":1641884400,"description":"Tengine + BabaSSL ，让国密更易用！","dir":"blog/tengine-babassl-making-state-secrets-easier-to-use/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"45a5b2c753bc2a5c371c606d1177571e","permalink":"https://sofastack.github.io/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","publishdate":"2022-01-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","summary":"文｜杨洋（花名：凯申 ) 蚂蚁集团高级技术专家 负责密码学工程能力建设、BabaSSL 开源社区建设 本文 2366 字 阅读 5 分钟 近日，国内著名 Web 服务器和反向代","tags":["SOFAStack"],"title":"Tengine + BabaSSL ，让国密更易用！","type":"blog","url":"/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","wordcount":1930},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王勇旭 提问：\n com.alipay.sofa.rpc.boot.runtime.adapter.processor.ConsumerConfigProcessor 没有提供注解上的支持，自己实现来处理吗？Cluster 指定 failover、failfast 或者自己实现，这种在 SOFA 中是怎么使用的呢？ A：这种的话，单个注解的 API 是不支持的。不过可以通过调整整体的 RPC 的配置，来实现切换到你想使用的 Cluster 上。具体如何配置可以看代码这里，支持自定义的配置文件，也支持 -D 环境变量的方式传入，key 为 consumer.Cluster。\n 为啥不支持单个 API 的配置啊，是出于某种考虑吗?\n A：单个 API 的话，可以单独通过 ConsumerConfig 的 setCluster(String Cluster)去设置。但是不是通用功能，所以没加到 annotation 上。\n 感觉和 loadbalance 是差不多同一级的，注解上 lD 支持，Cluster 不支持\u0026amp;hellip;\n A：这个功能感觉更偏全局一些，当然也是有单个 API 自定义的需求，之前的设计可能也是基于这个考量。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@崔伟协 提问：\n 所有整个流程里的异常返回（那些没转发到 Upstream/或者转发失败的，直接返回给 client)都会经过这里吗？ https://github.com/mosn/mosn/blob/master/pkg/proxy/downstream.go#L1359\n A：也不一定，你的诉求是啥呢？但是所有请求基本都会走 filter，你可以在 append filter 劫持返回的请求。\n 就是捕获一波没转发的或者转发失败的，不包括已经转发的然后返回失败的。\n A：这个可能还不太好区分，超时也算是转发的了，但超时之后也会调用 hijack。返回的包是不是 Upstream 发过来是可以判断的， 你写一个 append filter，然后判断 types.VarProxyIsDirectResponse 这个变量。\n「MOSN」：https://github.com/mosn/mosn\n@我是一个小胖子 提问：\n 这个统一路由框架，已经 ready，还是在计划中？\n A：https://mosn.io/blog/posts/how-use-dynamic-metadata/\n可以参考这篇文章，是更加灵活的方案。还有一部分没在文档里，就是路由的 match 规则也支持变量和 DSL。\n「MOSN」：https://github.com/mosn/mosn\n@Noob Xu 提问：\n 请问一下，MOSN 的国密 TLS 支持，是不是先用 \u0026amp;ndash;prefix=/usr/local/BabaSSL/linux_BabaSSL_lib 构建 BabaSSL，然后用 CGO_ENABLED=1 go build -tags BabaSSL 构建 MOSN，是不是就支持 TLS 1.3 + 国密单证书了 ？\n A：在/usr/local/BabaSSL/linux_BabaSSL_lib 这个路径下放上 BabaSSL 的 lib，比如/usr/local/BabaSSL/linux_BabaSSL_lib，然后 CGO_ENABLED=1 go build -tags=BabaSSL 之后配置里 TLS 的 CipherSuite 按照 MOSN 支持的几种格式配置，比如 ECDHE-RSA-SM4-SM3 就可以了。在 MOSN 和 MOSN 之间的 TLS 通信就可以走 1.3 和国密了。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 叮，你有一份开发者问卷到了\n一图看懂 SOFAStack 社区的 2021 ｜文末有“彩蛋”\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n","date":1641538800,"description":"SOFA Weekly |SOFA 社区插话小剧场、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220107/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e8f7168b6d3204a6c3f130a563ead237","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220107/","publishdate":"2022-01-07T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220107/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |SOFA 社区插话小剧场、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220107/","wordcount":1625},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@东仔 提问：\n SOFARegistry 的 client、meta、data、session 的四个模块间怎么交互的？\n A：client API 参考 :\nhttps://www.sofastack.tech/projects/sofa-registry/java-sdk/\nmeta、data、session 没有提供 API 文档, 相关介绍可以看下:\nhttps://github.com/sofastack/sofa-registry/releases/tag/v6.1.4\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@刚刚 提问：\n 获取有效链接，这个方法不是每次 new 一个 TCP 链接？\n A：会复用的，为 0 的时候才新建，不为 0 的时候我看是去到一个，直接把那个位置重置为 nil 了。\n 复用是体现在？还是我 down 大代码不是最新的。\n A：用完了会放回这个 avliableclients 的数组里，你的代码不是最新，但大致逻辑也就这样。\n「MOSN」：https://github.com/mosn/mosn\n3、之前有同学问到 OpenKruise 怎么热升级 MOSN，欢迎大家阅读这篇文档试用反馈！\nhttps://mosn.io/blog/posts/mosn-sidecarset-hotupgrade/\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nMOSN 本周发布 发布 MOSN V0.26.0 版本，主要变更如下：\n主要更新如下：\n XProtocol 进行了重构，XProtocol 不再是一种协议，而是便于协议扩展实现的框架\n 新增 ip_access filter，基于来源 IP 的 ACL 控制器\n 支持 go plugin 加载协议转化插件，并支持动态选择协议转换插件\n 支持动态设置上游协议，使用 transcoder filter 来替换 Proxy 中的协议转换\n 其他优化与BUG Fix\n 「详细参考」：\nhttps://mosn.io/blog/releases/v0.26.0/\n本周推荐阅读 一行降低 100000kg 碳排放量的代码！\nSOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1640934000,"description":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","dir":"blog/sofa-weekly-20211231/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1e143008505428e2046bc3c99bd99e51","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211231/","publishdate":"2021-12-31T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211231/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211231/","wordcount":1172},{"author":"张稀虹","categories":"SOFAStack","content":" 文｜张稀虹（花名：止语 )\n蚂蚁集团技术专家\n负责蚂蚁集团云原生架构下的高可用能力的建设 主要技术领域包括 ServiceMesh、Serverless 等\n本文 3631 字 阅读 8 分钟\nPART. 1 故事背景 今年双十一大促后，按照惯例我们对大促期间的系统运行数据进行了详细的分析，对比去年同期的性能数据发现，MOSN 的 CPU 使用率有大约 1% 的上涨。\n为什么增加了？\n是合理的吗？\n可以优化吗？\n是不可避免的熵增，还是人为的浪费？\n带着这一些列灵魂拷问我们对系统进行了分析\nPART. 2 问题定位 我们从监控上发现，这部分额外的开销是在系统空闲时已有，并且不会随着压测流量增加而降低，CPU 总消耗增加 1.2%，其中 0.8% 是由 cpu_sys 带来。\n通过 perf 分析发现新版本的 MOSN 相较于老版本， syscall 有明显的增加。\n经过层层分析，发现其中一部分原因是 MOSN 依赖的 sentinel-golang 中的一个StartTimeTicker 的 func 中的 Sleep 产生了大量的系统调用，这是个什么逻辑？\nPART. 3 理论分析 查看源码发现有一个毫秒级别的时间戳缓存逻辑，设计的目的是为了降低高调用频率下的性能开销，但空闲状态下频繁的获取时间戳和 Sleep 会产生大量的系统调用，导致 cpu sys util 上涨。我们先从理论上分析一下为什么这部分优化在工程上通常是无效的，先来看看 Sentinel 的代码：\npackage util import ( \u0026amp;quot;sync/atomic\u0026amp;quot; \u0026amp;quot;time\u0026amp;quot; ) var nowInMs = uint64(0) // StartTimeTicker starts a background task that caches current timestamp per millisecond, // which may provide better performance in high-concurrency scenarios. func StartTimeTicker() { atomic.StoreUint64(\u0026amp;amp;nowInMs, uint64(time.Now().UnixNano())/UnixTimeUnitOffset) go func() { for { now := uint64(time.Now().UnixNano()) / UnixTimeUnitOffset atomic.StoreUint64(\u0026amp;amp;nowInMs, now) time.Sleep(time.Millisecond) } }() } func CurrentTimeMillsWithTicker() uint64 { return atomic.LoadUint64(\u0026amp;amp;nowInMs) } 从上面的代码可以看到，Sentinel 内部用了一个 goroutine 循环的获取时间戳存到 atomic 变量里，然后调用 Sleep 休眠 1ms，通过这种方式缓存了毫秒级别的时间戳。外部有一个开关控制这段逻辑是否要启用，默认情况下是启用的。从这段代码上看，性能开销最大的应该是 Sleep，因为 Sleep 会产生 syscall，众所周知 syscall 的代价是比较高的。\ntime.Sleep 和 time.Now 对比开销到底大多少呢？ 查证资料（1）后我发现一个反直觉的事实，由于 Golang 特殊的调度机制，在 Golang 中一次 time.Sleep 可能会产生 7 次 syscall，而 time.Now 则是 vDSO 实现的，那么问题来了 vDSO 和 7 次系统调用相比提升应该是多少呢？\n我找到了可以佐证的资料，恰好有一个 Golang 的优化（2），其中提到在老版本的 Golang 中（golang 1.9-)，Linux/386 下没有这个 vDSO 的优化，此时会有 2 次 syscall，新版本经过优化后理论性能提高 5～7x+，可以约等于一次 time.Now \u0026amp;lt;= 0.3 次 syscall 的开销。\nCache 设计的目的是为了减少 time.Now 的调用，所以理论上这里调用量足够大的情况下可能会有收益，按照上面的分析，假设 time.Now 和 Sleep 系统调用的开销比是 0.3:7.3（7+0.3），Sleep 每秒会执行 1000 次（不考虑系统精度损失的情况下），这意味着一秒内 CurrentTimeMillsWithTicker 的调用总次数要超过 2.4W 才会有收益。\n所以我们再分析一下 CurrentTimeMillsWithTicker 的调用次数，我在这个地方加了一个 counter 进行验证，然后模拟请求调用 Sentinel 的 Entry，经过测试发现：\n 当首次创建资源点时，Entry 和 CurrentTimeMillsWithTicker 的放大比为 20，这主要是因为创建底层滑动窗口时需要大量的时间戳计算\n 当相同的 resource 调用 Entry 时，调用的放大比⁰为 5:1\n ｜注 0: 内部使用的 MOSN 版本基于原版 Sentinel 做了一些定制化，社区版本放大比理论上低于该比值。\n考虑到创建资源点是低频的，我们可以近似认为此处调用放大比为 5。所以理论上当单机 QPS 至少超过 4800 以上才可能会取得收益\u0026amp;hellip;\u0026amp;hellip;我们动辄听说什么 C10K、C100K、C1000K 问题，这个值看上去似乎并不很高？但在实际业务系统中，这实际上是一个很高的量。\n我随机抽取了多个日常请求量相对大的应用查看 QPS（这里的 QPS 包含所有类型的资源点，入口/出口调用以及子资源点等，总之就是所有会经过 Sentinel Entry 调用的请求量），日常峰值也未超过 4800QPS，可见实际的业务系统中，单机请求量超过这个值的场景是非常罕见的。¹\n｜注 1: 此处监控为分钟级的数据监控，可能与秒级监控存在一定的出入，仅用于指导日常请求量评估。\n考虑到这个优化还有一个好处，是可以降低同步请求时间戳时的耗时，所以我们可以再对比一下直接从 atomic 变量读取缓存值和通过 time.Now() 读取时间戳的速度。\n可以看到单次直接获取时间戳确实比从内存读取开销大很多，但是仍然是 ns 级别的，这种级别的耗时增长对于一笔请求而言是可以忽略不计的。\n大概是 0.06 微秒，即使乘以 5，也就是 0.3 微秒的增加。在 4000QPS 这个流量档位下我们也可以看一下 MOSN 实际 RT。\n两台机器的 MOSN RT 也没有明显的差异，毕竟只有 0.3 微秒\u0026amp;hellip;\nPART. 4 测试结论 同时我们也找了两台机器，分别禁用/启用这个 Cache 进行测试，测试结果佐证了上述分析的结论。\n从上图的数据可以看出来，启用 Cache 的情况下 cpu sys util 始终比不启用 Cache 的版本要大，随着请求量增加，性能差距在逐步缩小， …","date":1640674800,"description":"一行降低 100000kg 碳排放量的代码！","dir":"blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"93ce5b0bb923a249ebd161465f032ce8","permalink":"https://sofastack.github.io/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","publishdate":"2021-12-28T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","summary":"文｜张稀虹（花名：止语 ) 蚂蚁集团技术专家 负责蚂蚁集团云原生架构下的高可用能力的建设 主要技术领域包括 ServiceMesh、Serverles","tags":["SOFAStack"],"title":"一行降低 100000kg 碳排放量的代码！","type":"blog","url":"/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","wordcount":3103},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@微光 提问：\n 有一个嵌入式分布式 KV 存储需求，JRaft RheaKV 能用在生产吗？\n A：我们的时序数据库集群基于 RheaKV 做元数据存储和集群调度。\n有关内容可以参考这个文件：《\u0026amp;rdquo;使用组件及场景：时序数据库集群基于 RheaKV 做元数据存储和集群调度\u0026amp;rdquo;》\nhttps://github.com/sofastack/sofa-jraft/issues/524\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@微光 提问：\n RheaKV 中这样移除一个节点 Node，好像不行。在 DefaultRheaKVCliService 中是否可以提供动态上线 Node 和下线 Node 的 API？\n A：你提的都支持。所谓动态，不是说 JRaft 决定的，是你的运维系统可以使用 JRaft API 动态执行。\nissue 详细回复：https://github.com/sofastack/sofa-jraft/issues/747\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@苏泽东 提问：\n 哪位老师帮我解答下这个 Endstream 方法?\n A：这个主要是请求发出去后，一直等到收到响应后，记录下 RT 时间等监控数据。\n「MOSN」：https://github.com/mosn/mosn\n@火种 提问：\n 咨询一个问题：看 MOSN 的源码，如果非 netpoll，是通过在 startRWLoop 来实现的，如果是使用 netpoll 的情况下，长链接是怎么迁移的？\n A：https://mp.weixin.qq.com/s/ts_qsUee6mUFv0FpykaOXQ 推荐你看下这个文件。\n startRWloop 会调用 startreadloop 和 startwriteloop，在这两个函数中进行了长链接的数据的交换，但是使用 netpoll 后，代码分支就变成 netpoll 相应的分支了，不会进入上述两个函数了。\n A：没有支持 netpoll 模式的迁移。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n网商双十一基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\n","date":1640329200,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211224/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9977b0cb01909a1c2ef21e4a2026b36b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211224/","publishdate":"2021-12-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211224/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211224/","wordcount":1292},{"author":"马振雄","categories":"SOFAStack","content":" 近几年云计算的发展如火箭般迅猛，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施的统一资源调度带来了极大挑战。\n在越来越复杂的异构基础设施上，存量应用和增量应用应该如何上云？面对大量异构基础设施带来的挑战，企业如何最大化上云价值？\n12 月 15 日，在以“引领分布式云变革，助力湾区数字经济”为主题的全球分布式云大会上，蚂蚁集团数字科技事业部产品总监马振雄分享了分布式云异构基础设施之上，蚂蚁集团在构建分布式云 PaaS 平台 SOFAStack 背后的实践和思考。\nPART. 1 服务网格定义新的应用上云路径 随着云原生的发展，企业在技术升级的过程中伴随着大量的历史包袱，这些历史包袱是所有存量的异构功能，这些异构功能有以下几个特征：技术架构异构、通信协议异构、开发框架异构。\n这些存量的应用如何在异构的基础设施上统一纳管，背后就涉及到了应用的全生命周期，从研发时的应用改造成本，到运行时如何对异构应用做统一服务治理，再到运维时如何对基础设施进行统一元数据管理、统一变更、统一容灾、统一应急以及资金安全，这些都是存在于 PaaS 层的挑战。\n如果说 IaaS 层的统一资源调度以资源为视角和出发点，那么在上层 PaaS 则需要以应用为视角思考整个分布式基础设施的复杂度到底会带来哪些挑战，以及企业应该如何应对。\n企业存在大量的历史包袱，历史包袱五花八门，如果要把这些历史包袱全部改造成分布式应用或者云原生应用，背后需要的代价非常昂贵，很难有一家企业在短时间内愿意负担起这样的时间和成本，彻底将所有的历史包袱云原生化。\n相比于其他上云方式，Service Mesh 能够实现跨平台、跨协议，并且业务代码无侵入改造，从而快速地将应用植入 Sidecar 完成 Mesh 化，获得分布式红利、安全可观测，并且整个架构平滑演进。企业在架构升级过程中可以按部就班、循序渐进，并且实现端到端的安全可信以及全链路可观测能力。\n总体来说网格服务首先降低了传统应用改造成分布式、云原生应用的成本问题；其次是解决了所有企业新老系统的互联互通和统一纳管的问题；第三是让企业应用架构在升级过程变得更平滑；第四是让所有企业保留自己存量系统的技术栈，且保留了企业自身自主可控性要求。\nForrester 长期以来对蚂蚁集团的创新技术保持关注，Forrester 首席分析师、Serving Technology Executives 服务技术决策者戴鲲发布《蚂蚁集团服务网格总体经济影响》，并分享了他对于 Mesh 的研究，\n未来要实现开发的智能化，需要通过微服务来进行智能化进程，不再像以前一样零敲碎打。对传统应用进行定制化，要通过网格服务动态地组装，实现云上开发。\n通过对蚂蚁集团客户的访谈，Forrester 发现无论是传统金融机构还是互联网金融机构，都面临在混合架构下存在的共性挑战，包括基础设施升级换代、应用开发升级、云上云下交互等方方面面。Forrester 发现网格服务从单体应用改造成本节省到运维安全管理效率提升等方面都有明显的收益，通过研究三年数据测算，使用蚂蚁服务网格产品后，客户的投资回报率达到 99%。\nPART. 2 SOFAStack 实现异构统一运维与弹性容灾 基于自身的技术积累和场景打磨，蚂蚁数字科技定义了分布式云 PaaS 平台在运维态的六大能力，包括统一元数据管理、统一集群资源管理、统一变更能力、统一应急能力、统一容灾能力，和统一端到端从业务、应用到基础设施的可观测能力。在此基础上，蚂蚁数字科技重新定义 SRE，实现统一应用运维能力。\n行业一般认为 SRE 中的“R”（Reliability）是可靠性，蚂蚁数字科技结合自身十几年来对业务可用性和连续性的极致追求，经历了十多次双十一大规模验证，对 SRE 进行重新定义，将 SRE 里的 R 从 Reliability 转变为 Risk，意味着蚂蚁自身的保障体系是以风险为核心。最终通过十几年来的技术沉淀，打造了自己的技术风险保障平台 TRaaS。也正是因为这十几年沉淀的精华，才能让蚂蚁做到业务、应用、基础设施的运维无人值守，运维“自动驾驶”。\n蚂蚁的技术风险防控体系从上到下分别代表了三个目标：高可用、资金安全、低成本。三个组织保障：团队、文化、制度。再到需求、研发、发布以及监控的四条防线，最终沉淀出一套完整的技术风险保障体系的平台能力，整个平台由四个能力板块组成，包括了从应急、变更到容量、资金安全。\n应急平台建立起了以风险为核心的事前、事中、事后的故障风险保障体系，分别对应故障风险检测能力、故障定位能力、故障应急和自愈能力，以及故障的回溯能力。变更平台建立起了以变更为核心的事前、事中、事后的变更风险自动分析、防御、阻断能力。容量平台建立起了对于全局数据中心和系统整体瓶颈的自动探测、容量规划和容量保鲜能力。最后的资金平台，通过对业务应用无侵入地建立起了资金核对第二道防线，帮助企业彻底规避资金安全风险，减少资损。\n如果说第一个核心的挑战解决的是研发态和运行态的问题，第二个核心挑战解决运维态问题，第三个核心挑战，要解决的是从整体架构上解决容灾态的问题。\n随着分布式云基础设施的蓬勃发展，企业数据中心从集中化走向离散化，这意味着企业任何一个应用随时随地可以跑在全国的任何一家数据中心机房的任何一个节点。这种变化背后，从应用视角来看，迫切需要整体的系统应用架构，支撑业务突破地域和城市级别的无限可扩展能力。基于蚂蚁对于业务连续性的极致追求，蚂蚁在支撑业务发展过程中，建立起了金融行业超大规模的三地五中心，并沉淀了一套异地多活单元化架构，解决企业在容灾、弹性、灰度方面的三大痛点。\n容灾方面，可以支撑企业的数据中心架构彻底从单活走向同城双活、两地三中心、再走向多地多活。一个业务单元发生故障不会影响到另外一个业务单元，从架构本身原生保障了业务的可靠性和连续性。\n弹性方面，由于灵活部署和快速扩容机制，能够结合灵活的流量调拨机制，支撑企业的数据中心突破城市和地域级别的扩展，做到真正意义上的无限可扩展。\n灰度，结合跨单元的路由分发，可以轻易地做到蓝绿单元这样具有创新的业务灰度方式。\n多地多活的架构非常复杂，从上至下包含了四层，从接入层做路由规则和路由分发，到应用层的中间件路由，再到数据层的数据分片和数据路由，最后到运维层的统一容灾、统一监控、单元拓扑。\n以金融行业为例，大型银行在主机下移过程中，需要面临的重要课题就是如何将核心系统下沉到分布式集群，在分布式集群下移过程中如何匹配主机系统性能和稳定性，背后很重要的能力就是多地多活架构。\n最终，蚂蚁在以上三个核心挑战的实践过程中，沉淀出新一代分布式云 PaaS 平台 SOFAStack。平台在金融行业有非常多的头部客户案例，从原生能力就满足了金融行业远高于其他行业在容量、性能、规模、高可用、合规、降本提效等方面的高标准要求。更重要的是 SOFAStack 来源于金融行业，但不止于金融行业，蚂蚁希望通过 SOFAStack 赋能到更多的行业，完成更多企业的数字化转型。\nPART. 3 SOFAStack 未来演进方向 Mesh 的未来会经历三个重要的发展阶段：\n第一个阶段，不止是 Service …","date":1640242800,"description":"SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验","dir":"blog/the-practice-and-thinking-behind-sofastack/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cb8e3ab2323cb918eeb7a4cb68408c61","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","publishdate":"2021-12-23T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","summary":"近几年云计算的发展如火箭般迅猛，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施","tags":["SOFAStack"],"title":"SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验","type":"blog","url":"/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","wordcount":3335},{"author":"吕冰洁","categories":"SOFAStack","content":" 吕冰洁（花名：尚之）蚂蚁集团技术专家\n我们团队是在做蚂蚁集团内部 Serverless 项目，深度依赖 SOFAArk。SOFAArk 作为 Serverless 项目的核心热部署组件，在无感接入、快速启动方面有很大的诉求。\n因此为 SOFAArk 2.0 提供了最核心的内嵌式运行模式，同时对 1.0 版本存在的一些问题做了较多的性能优化。\n2022 年 03 月 07 日，吕冰洁@zjulbj 被投票选为，SOFAArk Committer。\nBefore 我主要是负责让传统的 SOFABoot 的应用平滑迁移到 SOFAArk 上。\n开始走了很多弯路，接入成本上可能需要半个月到一个月。最初选择了新建应用切流这种比较间接的方案，基于这个方案做迁移过程中的平滑迁移、切流工具。\n但是没解决根本问题，只是通过工具减少了部分工作量。\n过程 我们就尝试通过修改架构把这些问题解掉，推动自己深入了解底层，思考它为什么是这么设计的，为什么导致现在的问题？\n通过研究之后，发现最开始 SOFAArk 是面向终态去设计的，是比较理想化的容器。但实际落地过程中，业务是逐步演进而来的。刚接入就要感知特别大的变化，涉及部署脚本、镜像、测试脚本等一系列的改造，导致业务无法快速享受 SOFAArk 带来的红利。\n我们就借鉴之前的经验，比如 Tomcat 最开始是一个容器，后面往内嵌化发展。我们内部的 CloudEngine 最开始也是一个容器，后面往 SOFABoot 演进也是一个往内嵌化的发展。\nAfter 所以从我们整个迁移和落地的角度，设计了这套方案，修改其中的相关代码。\n从原来需要 2~3 周到现在的一天，降低迁移的成本，省去了大量迁移工作。也为我们后面全站规模化、商业化的一键开启 ark 奠定了基础。\n作为业务研发深入中间件开发底层 Q:如何看待自己作为业务研发的身份接触到开源？\nA:作为业务研发，深入到开源组件的底层设计，不仅对我们自己使用组件有很大的帮助，也能让我们和开源社区的组件同步节奏，不至于脱节。\n另外我们解决了实际问题，其他的使用方肯定也会遇到同样的问题。那我们是不是可以把已有的经验，回馈到开源社区帮助到更多的人。我觉得这是一个良性循环的开源环境，而不是向开发者提一些需求 pr 就结束了。\nQ:你觉得解决这个问题的难点在哪里？\nA:主要的难点还是我以业务研发的身份，参与到整个 SOFAArk 中间件的开发中。\n首先我需要对它的整个设计有清晰的把握，尽管之前有半年的使用经验，也依然花费了一周的时间才搞懂了核心架构。还好 ark 的文档写得很详细，大大降低了我的理解成本。\nQ:在沟通的过程中有没有什么困难的？\nA:沟通没有困难，毕竟大家都是技术，其实都是相通的。只要把自己的使用场景说清楚，中间过程遇到的一些具体问题说清楚。然后结合整个社区的生态，思考一下自己的需求处于什么样的定位，毕竟大家都是基于问题出发。\n也是通过这次深入开发底层，让我们更清晰的认识到大家都是绑在一条船上的，也更理解开发者，毕竟大家初心都是为了共同的目标去努力。\n业务研发和开发者的双重身份是否有可持续性？ Q:这个状态还会一直持续下去吗？\nA:目前我已经成为了 SOFAArk 2.0 的核心开发人员，还会推进 SOFAArk 在蚂蚁主站大规模落地，作为开发的角色维护下去的。本身我们的 Serverless 产品它下面依赖的部署组建就是 SOFAArk，我们要去大规模落地的过程中，涉及到对 ark 的一些支持问题，所以我们可能需要深入到底层去剖析，让组件真正的更易用。\nQ:业务研发深入到中间件底层设计，在开源社区是一个普遍的现象吗？\nA:我理解应该是都有这样的现象，比如说我们用到动态热部署的能力，那我们对启动优化的东西，后面也会把它那个反馈到 SOFABoot、 Spring Boot 社区。\n在我们自己落地过程中遇到的问题，想到的创新解决方案，如果是通用的话，会往各个社区去提 pr、做一些反馈的进行同步。\n比如，我们在 SOFAArk 启动加速这一块，针对 Classloader 做了启动类加载的优化，启动速度平均提升了 50% 左右。\n目前这个已经在 Spring Boot 提了 pr，他们那边正在跟进；\nSOFABoot 这边也有相关的同学在保持跟进，之后我们会在我们主站率先去做一个 backport 的支持。\n业务研发专属经验分享 A:SOFAArk 负责人说你是一个追求细节、追求极致的同学。\nQ:我们团队是做 Serverless 产品的，产品的要求是“更快、更高效、性能更好、体验更好”。\n这就要求了我们在做代码优化的过程中去追求细节、追求极致，也是我们整个团队的风格。\nA:有了这种特殊经历后，有哪些经验可以分享给其他业务研发的吗？\nQ:作为业务研发，最开始我对 ark 也不是很了解的，刚接手 ark 的迁移的东西，也没敢想说去对 ark 做这么大的改造。\n一切基于我们团队的问题出发，一步步深入了解它的原理，去尝试实践自己想法，最终做出了开源的贡献，回过头来看才发现自己做了这么多。\n大部分业务研发不太愿意去参与这种开源贡献，可能就是把它想得比较难了。\n大家不用担心深入底层开发是很有门槛的事情，只要你带着问题出发，其他的都不是问题！\n看他不爽，就直接动手改吧！\n本周推荐阅读 社区文章｜MOSN 路由框架详解\nHAVE FUN | SOFARegistry 源码解析\nBabaSSL：支持半同态加密算法 EC-ElGamal\n恭喜 吕冰洁 成为 SOFAStack committer！\n","date":1640070000,"description":"SOFAArk Committer 专访｜看它不爽，就直接动手改！","dir":"blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"af2c0c99370a29c6e191e9a912277670","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","publishdate":"2021-12-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","summary":"吕冰洁（花名：尚之）蚂蚁集团技术专家 我们团队是在做蚂蚁集团内部 Serverless 项目，深度依赖 SOFAArk。SOFAArk 作为 Serverless 项目的核心热部署组件，在无","tags":["SOFAStack"],"title":"SOFAArk Committer 专访｜看它不爽，就直接动手改！","type":"blog","url":"/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","wordcount":1947},{"author":"曾柯","categories":"SOFAStack","content":" 文｜曾柯（花名：毅丝 )\n蚂蚁集团高级工程师\n负责蚂蚁集团的接入层建设工作,主要方向为高性能安全网络协议的设计及优化\n本文 10279 字 阅读 18 分钟\nPART. 1 引言 作为系列文章的第一篇，引言部分就先稍微繁琐一点，让大家对这个系列文章有一些简单的认知。\n先介绍下这个系列文章的诞生背景。QUIC、HTTP/3 等字眼想来对大家而言并不陌生。从个人的视角来看，大部分开发者其实都已经有了一些背景知识，比如 HTTP/3 的核心是依赖 QUIC 来实现传输层及 TLS 层的能力。而谈及其中细节之时，大家却又知之甚少，相关的文章大多只是浅尝辄止的对一些 HTTP/3 中的机制和特性做了介绍，少有深入的分析，而对于这些机制背后诞生原因，设计思路的分析，就更难得一见了。\n从个人并不大量的 RFC 阅读及 draft 写作经历来看，和撰写论文文献一样，为了保证一份 RFC 的精简以及表述准确，当然也是为了编写过程的简单。在涉及到其他相关协议时，作者往往是通过直接引用的方式来进行表述。这也就意味着直接通过阅读 RFC 来学习和了解网络协议是一个曲线相对比较陡峭的过程，往往读者在阅读到一个关键部分的时候，就不得不跳转到其他文档，然后重复这个令人头痛的过程，而当读者再次回到原始文档时，可能都已经忘了之前的上下文是什么。\n而 HTTP/3，涉及到 QUIC、TLS、HTTP/2、QPACK 等标准文档，而这些标准文档各自又有大量的关联文档，所以学习起来并不是一个容易的事。\n当然，系列文章的立题为“深入 HTTP/3”，而不是“深入 QUIC”，其背后的原因就是 HTTP/3 并不仅仅只是 QUIC 这么一个点，其中还包含有大量现有 HTTP 协议和 QUIC 的有机结合。在系列文章的后续，也会对这一部分做大篇幅的深入分析。\n一个协议的性能优秀与否，除了本身的设计之外，也离不开大量的软硬件优化，架构落地，专项设计等工程实践经验，所以本系列除了会针对 HTTP/3 本身特性进行分享之外，也会针对 HTTP/3 在蚂蚁落地的方案进行分享。\n引言的最后，也是本文的正式开始。\n据统计，人类在学习新的知识时，比较习惯从已有的知识去类比和推断，以产生更深刻的感性和理性认识。我想对大部分同学而言，“TCP 为什么要三次握手以及四次挥手？”这个问题，颇有点经典的不能再经典的味道，所以今天这篇文章也将从 QUIC 链接的建立流程及关闭流程入手，开始我们系列的第一篇文章。\nPART. 2 链接建立 2.1 重温 TCP “TCP 为什么要三次握手？”\n在回答问题之前我们需要了解 TCP 的本质，TCP 协议被设计为一种面向连接的、可靠的、基于字节流的全双工传输层通信协议。\n“可靠”意味着使用 TCP 协议传输数据时，如果 TCP 协议返回发送成功，那么数据一定已经成功的传输到了对端，为了保证数据的“可靠”传输，我们首先需要一个应答机制来确认对端已经收到了数据，而这就是我们熟悉的 ACK 机制。\n“流式”则是一种使用上的抽象(即收发端不用关注底层的传输，只需将数据当作持续不断的字节流去发送和读取就好了)。“流式”的使用方式强依赖于数据的有序传输，为了这种使用上的抽象，我们需要一个机制来保证数据的有序，TCP 协议栈的设计则是给每个发送的字节标示其对应的 seq(实际应用中 seq 是一个范围，但其真实效果就是做到了每个字节都被有序标示)，接收端通过检视当前收到数据的 seq，并与自身记录的对端当前 seq 进行比对，以此确认数据的顺序。\n“全双工”则意味着通信的一端的收发过程都是可靠且流式的，并且收和发是两个完全独立，互不干扰的两个行为。\n可以看到，TCP 的这些特性，都是以 seq 和 ACK 字段作为载体来实现的，而所有 TCP 的交互流程，都是在为了上述特性服务，当然三次握手也不例外，我们再来看 TCP 的三次握手的示意图：\n为了保证通信双方都能确认对端数据的发送顺序，收发端都需要各自记录对端的当前 seq，并确认对端已经同步了自己的 seq 才可以实现，为了保证这个过程，起码需要 3 个 RTT。而实际的实现为了效率考虑，将 seq 和 ACK 放在了一个报文里，这也就形成了我们熟知的三次握手。\n当然，三次握手不仅仅是同步了 seq，还可以用来验证客户端是一个正常的客户端，比如 TCP 可能会面临这些问题：\n(1)有一些 TCP 的攻击请求，只发 syn 请求，但不回数据，浪费 socket 资源；\n(2)已失效的连接请求报文段突然又传送到了服务端，这些数据不再会有后续的响应，如何防止这样的请求浪费资源？\n而这些问题只是三次握手顺手解决的问题，不是专门为了它们设计的三次握手。\n细心的你，可能已经发现了一个问题，如果我们约定好 client 和 server 的 seq 都是从 0(或者某个大家都知道的固定值)开始，是不是就可以不用同步 seq 了呢？这样似乎也就不需要三次握手那么麻烦了？可以直接开始发送数据？\n当然，协议的设计者肯定也想过这个方案，至于为什么没这么实现，我们在下一章来看看 TCP 面临什么样的问题。\n2.2 TCP 面临的问题 2.2.1 seq 攻击 在上一节我们提到，TCP 依赖 seq 和 ACK 来实现可靠，流式以及全双工的传输模式，而实际过程中却需要通过三次握手来同步双端的 seq，如果我们提前约定好通信双方初始 seq，其实是可以避免三次握手的，那么为什么没有这么做呢？答案是安全问题。\n我们知道，TCP 的数据是没有经过任何安全保护的，无论是其 header 还是 payload，对于一个攻击者而言，他可以在世界的任何角落，伪造一个合法 TCP 报文。\n一个典型的例子就是攻击者可以伪造一个 reset 报文强制关闭一条 TCP 链接，而攻击成功的关键则是 TCP 字段里的 seq 及 ACK 字段，只要报文中这两项位于接收者的滑动窗口内，该报文就是合法的，而 TCP 握手采用随机 seq 的方式（不完全随机，而是随着时间流逝而线性增长，到了 2^32 尽头再回滚）来提升攻击者猜测 seq 的难度，以增加安全性。\n为此，TCP 也不得不进行三次握手来同步各自的 seq。当然，这样的方式对于 off-path 的攻击者有一定效果，对于 on-path 的攻击者是完全无效的，一个 on-path 的攻击者仍然可以随意 reset 链接，甚至伪造报文，篡改用户的数据。\n所以，虽然 TCP 为了安全做出过一些努力，但由于其本质上只是一个传输协议，安全并不是其原生的考量，在当前的网络环境中，TCP 会遇到大量的安全问题。\n2.2.2 不可避免的数据安全问题 相信 SSL/TLS/HTTPS 这一类的字眼大家都不陌生，整个 TLS(传输安全层)实际上解决的是 TCP 的 payload 安全问题，当然这也是最紧要的问题。\n比如对一个用户而言，他可能能容忍一次转账失败，但他肯定无法容忍钱被转到攻击者手上去了。TLS 的出现，为用户提供了一种机制来保证中间人无法读取，篡改的 TCP 的 payload 数据，TLS 同时还提供了一套安全的身份认证体系，来防止攻击者冒充 Web 服务提供者。然而 TCP …","date":1640070000,"description":"深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进","dir":"blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","fuzzywordcount":9100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"399aa26268182488b3d65e0618367a35","permalink":"https://sofastack.github.io/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","publishdate":"2021-12-21T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","summary":"文｜曾柯（花名：毅丝 ) 蚂蚁集团高级工程师 负责蚂蚁集团的接入层建设工作,主要方向为高性能安全网络协议的设计及优化 本文 10279 字 阅读 18 分钟 PART. 1 引言 作为","tags":["SOFAStack"],"title":"深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进","type":"blog","url":"/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","wordcount":9072},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFA x 字节码联盟 WAMR 社区「WebAssembly Open Day」\n 活动时间：2021 年 12 月 18 日（周六）13:00-17:00\n 活动形式：线上直播\n 资料下载：\n 《蚂蚁集团 WASM 编译器虚拟机基础能力建设》 \n《WebAssembly Micro Runtime 开源技术解析与展望》\n《Waft: 基于 WebAssembly 的 AIoT 应用框架实践》\n《WASM 中的 GC 遐想》\n《WebAssembly 在区块链中的实践》\n《Wasm \u0026amp;amp; WAMR 在 AIOT 领域的应用》\n活动议程 活动回顾 嘉宾简介：\n《字节码联盟与 WAMR 开源社区进展介绍》\n王鑫 intel 技术经理 任职英特尔公司，关注计算机语言与运行引擎，可信计算和物联网等技术领域。开发与创建开源项目 WebAssembly Micro Runtime，参与推动英特尔、微软、Mozilla 等公司成立字节码联盟（Bytecode-Alliance），任字节码联盟技术管理委员会（TSC）成员。\n杨斌（花名：凯撒） 蚂蚁集团技术总监 任职蚂蚁集团技术总监，关注操作系统，计算机语言与运行引擎等技术领域。\nTill Schneidereit 字节码联盟董事会主席\nRalph Squillace 微软高级总监 字节码联盟董事会成员\n汤伟\n蚂蚁集团资深技术专家\n《蚂蚁集团 WASM 编译器虚拟机基础能力建设》\n嘉宾简介：\n汤伟，一直从事编译器和虚拟机相关工作，2020年11月加入蚂蚁金服，主导webassembly相关工具链的设计与开发。\n议题简介： 作为面向蚂蚁的 wasm 编译器、虚拟机基础平台团队，面向蚂蚁 wasm 用户核心诉求，针对开发效率、性能提升以及生态拓展，确定 wasm 编译器、虚拟机上的技术选型，探索未来编译器、虚拟机协同设计空间。\n听众收益： 了解wasm在蚂蚁的业务场景中的需求和我们的编译器、虚拟机技术能力建设上的一些探索。\n何良\nintel 资深软件工程师\n《WebAssembly Micro Runtime 开源技术解析与展望》\n嘉宾简介：何良，INTEL 资深软件工程师， WAMR开源项目核心开发者\n议题简介：主要介绍 WebAssembly Micro Runtime(WAMR) 的技术特性，发展历程以及路线图。面对嵌入式设备独特的资源条件和使用场景，WAMR进行了有针对性的特性开发，比如选用不同的运行模式适应不同的资源水平，利用XIP在文件系统中直接执行，在RUNTIME中支持 Sensor API 等。此外，WAMR努力打造高效的开发环境，提供源码级调试的功能框架和VSCODE插件。目前，支持高级语言（比如JAVA,KOTLIN等）和SOCKET APIs的功能开发正在有序展开。\n唐兹源\n阿里巴巴前端技术专家\n《Waft: 基于 WebAssembly 的 AIoT 应用框架实践》\n嘉宾简介：\n唐兹源，天猫精灵工程技术前端团队负责人，在智能硬件应用研发领域拥有超过 4 年的经验，专注于 AIoT 体验技术创新\n议题简介：\n本次分享将为大家带来天猫精灵技术团队基于 WAMR 和自研渲染引擎打造的应用框架实践经验，介绍 WebAssembly 在天猫精灵智能音箱以及生态硬件（如电视大屏、投影仪等）的应用场景，以及 Waft 应用框架体系的设计和思考\n听众收益：\n了解 WebAssembly 在智能音箱及电视大屏中的应用场景 了解天猫精灵技术团队如何结合 WAMR 和自研渲染引擎设计动态化容器 了解如何运用 AssemblyScript 设计适合 Web 开发者的应用框架及工具链建设\n臧琳\n腾讯云高级工程师\n《WASM中的GC遐想》\n嘉宾简介：腾讯云编程语言团队高级工程师，OpenJDK committer，专注于编程语言 Runtime 技术在云计算领域的优化与应用。\n议题简介：内存管理及垃圾回收技术是现代高级语言的核心技术之一，也是webassembly承载多语言支持的必经之路， wasm社区已经将GC proposal提上日程，本话题和大家一起进行一次头脑风暴，探讨未来wasm的内存管理及垃圾收集技术可能的发展方向。\n张磊\n蚂蚁集团技术专家\n《WebAssembly在区块链中的实践》\n嘉宾简介：毕业于北京大学，曾就职于华为编译器实验室。目前在蚂蚁链智能合约团队，从事编译器和虚拟机相关研发工作。\n议题简介：Wasm 的安全性、高性能和跨平台等优点，使其天然适合用作区块链智能合约的执行环境。另一方面，区块链对于安全性和确定性的极致要求，也对 Wasm 本身提出了一些技术挑战。本次分享将会结合蚂蚁链的实践经验，介绍 Wasm与区块链之间的各种奇妙“化学反应”。\n听众收益：将会了解到wasm在区块链领域的应用现状和面临的技术挑战。\n黄齐\n小米软件工程师/Vela OS 框架业务技术负责人\n《Wasm \u0026amp;amp; WAMR在AIOT领域的应用》\n嘉宾简介：负责小米Vela OS内核、中间件的研发和在不同架构上的落地，带领团队完成了基于Wasm的应用开发框架的开发和落地，支撑了小米内部多项业务发展\n议题简介：Wasm 作为诞生于浏览器的技术，为何能在 IoT 领域大放异彩？在内存只有数十 KB 级别的运行环境里使用 Wasm，我们将面临怎样的挑战和困难？本次向大家分享小米对 Wasm 技术在 IoT 应用中的实践与思考\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1639810800,"description":"【活动回顾】《WebAssembly Open Day》","dir":"activities/sofa-meetup-13/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6055a6cf6a48ee5bfe63e2c249c2e3d4","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-13/","publishdate":"2021-12-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-13/","summary":"概要 活动主题：SOFA x 字节码联盟 WAMR 社区「WebAssembly Open Day」 活动时间：2021 年 12 月 18 日（周六）13:00-17:00 活动形式","tags":["SOFA"],"title":"【活动回顾】《WebAssembly Open Day》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-13/","wordcount":1931},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@孙军超 提问：\n 请教一下 JRaft 里， Bolt 的 logback 日志怎么关掉 ?\n A：可以参考这个文件。https://github.com/sofastack/sofa-jraft/issues/724\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@超 提问：\n 这种方式运行 Wasm 的时候，Layotto 自身加上运行时部分初始化需要加载 Dapr 组件时间可能总共要 1-2s（还没有实测，因为目前只用过 Dapr，后面会实际运行一下）。这方面冷启动延迟一方面可以精简 Wasm 的 runtime 仅包括 Dapr 或者 Layotto 的 SDK 通过网络来通信；另一方面就是优化运行时的启动时间。作者对这方面问题有想法吗？\n A:这个问题属于 Layotto 自身如何快速初始化，目前我们也在这方面做一些尝试，比如优化调度算法，让某些特征的函数调度到特定的 Layotto 上，这样就可以让 Layotto 提前初始化好资源。不过这只是函数急速调度中的一个环节，实际落地过程中还有调度算法执行耗时，Pod 启动耗时，函数自身启动耗时等等因素，这也是我们目前正在努力的方向。\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Python 或 C++ 、SDK\n开发 Spring-Boot-Layotto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 让用户使用@SofaService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nSOFARegistry 本周发布 SOFARegistry V6 正式发布的第一个版本。\n主要更新如下：\n 运维难度大幅度降低 自身元数据存储插件化，如果不希望引入 raft 运维的复杂性，支持基于 db 实现。meta、session 无状态化，data 弱状态化。\n 性能和可扩展能力大幅提升 横向扩展能力大幅度提升，能够横向扩展至 300+ session 节点，能够承载亿级服务数据。\n「详细参考」：https://github.com/sofastack/sofa-registry/releases/tag/v6.1.4\n网商双十一基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\n降本提效！注册中心在蚂蚁集团的蜕变之路\n","date":1639724400,"description":"开发者的搬砖日常、社区本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211217/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"42ba6063d3d0ebea2b80a70c23e77497","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211217/","publishdate":"2021-12-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211217/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 本周 Contributor、QA 整理、SOFARegistry 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211217/","wordcount":1387},{"author":"张化仁","categories":"SOFAStack","content":" 文｜张化仁（花名：花伦 )\n网商银行基础技术架构部架构师\n校对｜阚广稳(花名：空门)\n本文 4832 字 阅读 10 分钟\n｜引言｜ 微服务架构下，服务之间的调用错综复杂，一个应用可能会承载着多种不同的业务流量。由于运行在同一个应用进程内，多种业务流量之间势必会存在相互影响的情况。\n如果某种业务流量陡增，导致应用进程负载激增，进而请求排队，其它业务流量也势必会受影响。多数时候这种相互影响的情况都是在容忍范围以内或者可以规避的，特定场景下我们可能就需要考虑通过隔离某些业务流量的方式，来消除业务之间相互影响的风险：\n 例如，当后台调度型的流量影响了在线用户请求；\n 再如，当低敏的甚至可失败的业务影响了高敏的需要重保的业务。\n 业务链路隔离的诉求是业内普遍存在的。通常的方案是新创建一个应用，然后将需要隔离的业务迁移到这个新应用上。\n新建应用的方式，研发运维等都需要付出成倍的成本，相关应用还需要配合改造和迁移。对于只有单个应用需要创建的情况或许还能勉强接受，网商银行部分应用例如高保极简网关、高保客户视图等当前就是采用的这种方案。这种方式是非常笨重的，而且当我们期望特定业务关联的整条链路上的多个应用都进行业务隔离的话，这种方案的成本将非线性上升进而变得难以接受。\n云原生架构下，对容器和流量可以进行更精细化的管控，对于上述业务流量隔离的场景，我们有了更简洁、更灵活、更通用的替代方案\u0026amp;ndash;我们称之为「业务单元隔离」，可以在不创建新应用的情况下实现上述诉求。此方案当前已在包括核心链路在内的网商多个业务场景得到应用，也顺利通过了今年双十一大促的考验。\n那么「业务单元隔离」具体是什么？我们是如何借助「业务单元隔离」实现业务链路的隔离呢？本文将和大家细述。\nPART. 1 概念及基本原理 概念及运维模型 「业务单元隔离」是一套流量染色和资源隔离的方案，可以帮助业务相对简单地实现业务链路隔离。在调研和验证的过程我们也提出了优化改进方案并推进落地，最终进一步减轻了业务接入的成本。\n「业务单元隔离」需要结合两个新的概念来阐述：「AIG」和「业务单元」。\nAIG 是某个应用为了支撑某些业务而隔离出来的一组资源。由一个或多个应用的 AIG 组成的、服务与某个或某类特定业务的业务链路我们称为一个业务单元。保证有且只有符合特征的流量引流到某个业务单元，我们称之为「业务单元的隔离部署」。\n主要任务及配套设施 从「业务单元隔离」的概念中我们不难看出：要实现某个业务链路的流量隔离，至少需要做有以下几件事情：\n1.业务单元构建：给链路上的应用分别创建 AIG 组成一个业务单元，且须保证不能有流量流入新建的业务单元。\n2.业务流量识别：需要通过某种方式识别出上游应用流入的特定业务的流量。\n3.特定业务引流：对于识别到的特定业务的流量，需要有机制让这些流量流向新创建的业务单元。\n很显然，上述的这些事情，必然需要基础设施侧和应用侧相互配合才可实现。如下图所示，相关的基础设施及作用如下：\n1.业务单元构建：需要为 AIG 提供完整的研发/运维/监控支持；\n2.流量识别（RPC）：链路中业务单元上游的应用（A）需要接入打标染色 SDK，以便通过染色管控平台下发打标染色规则；\n3.流量识别（调度）：复杂调度（消息触发，应用单 LDC 内自主分发批任务）通过转换成基于 SOFARPC 的流式任务，从而实现染色和隔离。\n4.特定业务引流：MOSN 侧的精细化路由需要支持 AIG，让流量可以流入到新特定的业务单元。\n业务单元构建 业务单元实际是一个相对抽象的概念，对应一条业务链路。\n网商的实践中，为了让业务单元更加具象化，我们规定一个业务单元内的多个应用，其 AIG 名称（appname-aigcode）中的 aigcode 部分必须尽可能一致。\n因此，构建一个特定的业务单元，本质上是要给链路上相关的应用，都创建出服务于特定业务隔离的资源组（AIG）。\n对于单个应用，构建 AIG 包含两部分：\n一是初始化 AIG 元数据；\n其次是围绕此 AIG 的各种运维操作（扩缩容、上下线、重启、sidecar 注入升级等）。\n可以看到要支持 AIG，PaaS 侧几乎所有运维操作都需要适配，工作量非常很大。所以 PaaS 侧在支持 AIG 这件事情上也必须权衡取舍，决定只在终态的 workload 运维模式下支持了 AIG，这也导致 AIG 强依赖应用从现有的 image 的模式迁移到 workload 的模式。\nworkload 运维模式下，PaaS 将发布和运维的内容都编排成 CRD 资源，交给底层 sigma（K8s）做运维。切换到 workload 运维模式有利于集团统一发布运维体系，也可以更好的支持弹性扩缩容、自愈等场景。\n但相比 image 模式，workload 模式对用户使用习惯和体验上冲击很大，初期相关的问题也非常多。因此尽管网商 workload 一直在有序推进，在后续核心业务接入 AIG 的项目中，为了避免强制切换到 workload 运维模式影响核心业务运维应急，我们也给 PaaS 提了支持仅对 AIG 机器开启了 workload 的诉求，并且针对这种情况做了完备的混合运维验证。\nRPC 流量隔离 业务单元创建好之后，如何确保新的业务单元在不引流的情况下默认没有 RPC 流量流入呢？\n应用的机器之所以有 RPC 流量流入，是因为注册中心（SOFARegistry）和跨机房负载均衡（AntVip）中挂载了机器 IP：应用进程启动成功 MOSN 感知到后，MOSN 会将服务信息注册到 SOFARegistry，发布运维过程机器健康检查通过后 PaaS 侧会调用接口往 AntVip 上挂载机器的 IP。\n所以，要确保新的 AIG 机器默认没有流量流入，就需要 MOSN 和 PaaS 侧做出调整。\n整体调整方案如下图所示：\n如何识别特定业务的 RPC 流量呢？\n上游应用接入打标染色 SDK 之后，其在作为服务端被其它应用调用、作为客户端调用其它应用的时候，都可以被 SDK 中的 RPC 拦截器拦截，拦截器对比 RPC 请求和下发的打标染色规则，一旦 match 就会在 RPC Header 中增加业务请求标识。\n最后，就是将流量引流到特定业务单元。\n借助 MOSN 强大的精细化路由能力，我们可以让流量路由到指定的业务单元,并在业务单元内部收敛。业务单元隔离主要用到了 MOSN 的客户端路由能力，在客户端应用发起调用、请求流经当前 Pod 的 MOSN 时，可以按我们下发的路由规则控制流量的走向。\n调度流量隔离 调度本质是消息，简单的调度场景通常也不会有隔离的诉求。很多有隔离诉求的场景当前都是“消息任务+三层分发”的模式，利用调度触发批处理逻辑。\n三层分发协议是基于 tb-remoting 协议分发请求的，不是标准的 SOFARPC 协议，不经过 MOSN，因此 MOSN 也无法控制这种请求的走向。\n为了解决这个问题，AntScheduler 推出了全新的流式调度模式，通过将三层分发模式转变成多次标准 SOFARPC 调用，从而和 MOSN 无缝配合，满足流量隔离的诉求。\n对于希望调度流量直接路由到 AIG 的场 …","date":1639465200,"description":"网商双十一-基于 ServiceMesh 技术的业务链路隔离技术及实践","dir":"blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"472fb3f3bcfec5e7e03683b781646824","permalink":"https://sofastack.github.io/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","publishdate":"2021-12-14T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","summary":"文｜张化仁（花名：花伦 ) 网商银行基础技术架构部架构师 校对｜阚广稳(花名：空门) 本文 4832 字 阅读 10 分钟 ｜引言｜ 微服务架构下，服务之间的调用错综复杂","tags":["SOFAStack"],"title":"网商双十一-基于 ServiceMesh 技术的业务链路隔离技术及实践","type":"blog","url":"/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","wordcount":4521},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@证道者 提问：\n MOSN 的网络性有做新的技术尝试吗?\n A：这个是我们今年在网络性能上的尝试，内部也在网关场景落地，后续也会开源出来。iouringv 之前我们做过测试，在我们的场景提升有限。\nhttps://mp.weixin.qq.com/s/ioewVcwiB5QA8w3A3gaikg\n「MOSN」：https://github.com/mosn/mosn\n@赵一凡 提问：\n 问下 SOFALookout 的客户端可以直接把默认已有度量指标推送到 ES 吗？\n A：一般客户端是上报到 lookout 服务端, 再由服务端决定要写到哪。\n「SOFALookout」：https://github.com/sofastack/sofa-lookout\n@开发者 提问：\n 这个 Test 模块是用来开发者做测试的还是做自动化测试的？\n A：用于 jraft 的 jepsen 验证，参考这个项目：\nhttps://github.com/sofastack/sofa-jraft-jepsen\njraft 每次发版前要确保通过 jepsen 验证。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@小楼 提问：\n 请问 session 是如何支持 Dubbo 的元数据的？\n A：Registery 的元数据现在不是通用的，只针对 SOFARPC。\n session 之间应该是没有数据同步的吧，跨 session 节点怎么办呢？\n A：现在会同步两个信息，一个是元数据，一个是接口级订阅，接口级订阅是用于兼容没升级的应用。同步的路径是通过存储，类似 K8 的 listwatch 机制，内部落地存储的插件实现是 db，这个块数据比较少，就几千行吧，而且变化很小。\n「SOFARegistery」：https://github.com/sofastack/sofa-jraft\n@小楼 提问：\n 是用什么 db 存储的?\n A：蚂蚁内部的 db 普遍都是 ob，不过代码是兼容 mysql 的。\n「SOFARegistery」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API、分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 Service Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\nService Mesh 双十一后的探索和思考(下)\n蚂蚁 Service Mesh 大规模落地实践与展望\n","date":1639119600,"description":"开发者的搬砖日常、社区本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211210/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c8ef24b5957863311a11eff48080bc30","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211210/","publishdate":"2021-12-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211210/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开发者的搬砖日常、社区本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211210/","wordcount":1289},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#23：蚂蚁服务发现的大规模实践与展望\n 活动时间：12 月 09 日，周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#23：蚂蚁服务发现的大规模实践与展望 naming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。本次分享将会包含以下内容：\n 蚂蚁内部实践 naming 在云原生时代下的发展方向及趋势 总结和展望 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 林育智 蚂蚁集团高级技术专家。 目前在蚂蚁集团中间件团队负责 naming 等项目的研发工作 议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:30 蚂蚁服务发现的大规模实践与展望 林育智，蚂蚁集团高级技术专家\n你将收获 了解蚂蚁集团在 SOFARegistry 新挑战及云原生时代的思考。\n了解 SOFARegistry 实践经验。\n了解蚂蚁集团对未来 naming 的思考及 naming 在云原生方向上的探索。\n了解未来 SOFARegistry 的发展和相关的社区动向。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1639033200,"description":"12 月 09 日周三晚 19 点，线上直播第 23 期。","dir":"activities/sofa-channel-23/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"781a397af19af21ad03eef254f28fe69","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-23/","publishdate":"2021-12-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-23/","summary":"概要 活动主题：SOFAChannel#23：蚂蚁服务发现的大规模实践与展望 活动时间：12 月 09 日，周三晚 19 点 活动形式：线上直播 资料下载：戳这里","tags":["SOFAChannel","SOFARegistry"],"title":"SOFAChannel#23：蚂蚁服务发现的大规模实践与展望","type":"activities","url":"/sofastack.tech/activities/sofa-channel-23/","wordcount":709},{"author":"顾欣","categories":"SOFAStack","content":" Service Mesh 是下一代的微服务架构基础。蚂蚁集团从 2018 年初就开始了技术探索并进行了落地试点。目前， Service Mesh 覆盖了蚂蚁数千个应用，实现了核心链路全覆盖。\n蚂蚁集团通过 Service Mesh 的大规模落地，向云原生走出了坚实的一步，验证了可行性，真切看到了基础设施下沉后无论是对业务还是对基础设施团队都带来了研发和运维效率的提升，成本的降低。\n与此同时，蚂蚁也在积极将成熟的技术开放给社会，目前已将自研数据面 MOSN 开源，欢迎开源爱好者一起共建。\nhttps://github.com/mosn/mosn\n｜前言｜ 微服务架构是当今互联网和金融机构渐趋主流的系统架构模式，其核心是集成服务通信、服务治理功能的服务框架，微服务框架在持续演进同时，服务网格（Service Mesh）作为一种新型的微服务架构，因架构灵活、普适性强，被认为具有较好发展前景。\n中国工商银行（后简称工行）主动探索服务网格领域，从 2019 年开始服务网格技术预研工作，通过对服务网格技术深入研究和实践后，于 2021 年建设了服务网格平台。服务网格与现有微服务架构融合发展，助力工行应用架构向分布式、服务化转型，承载未来开放平台核心银行系统。\nPART. 1 业界服务网格发展现状 自 2016 年服务网格技术诞生以来，业界涌现了诸多的开源产品，如 Istio（Google + IBM + Lyft）、Linkerd（Twitter）、Consul（Hashicorp）等。其中以 Istio 社区活跃度和认可度最高，被作为服务网格的标杆开源产品。\n服务网格是一个专门处理服务通讯的基础设施层。它通过在业务 Pod 中注入 Sidecar 容器，接管业务容器的通信流量，同时 Sidecar 容器与网格平台的控制平面对接，基于控制平面下发的策略，对代理流量实施治理和管控，将原有服务框架的治理能力下层到 Sidecar 容器中，从而实现了基础框架能力的下沉，与业务系统解耦。\n图 1：服务网格示意图\nSidecar 容器接管后端服务通信的进出流量后，通过标准协议进行服务间通信，可实现跨语言、跨协议的服务互访。此外，Sidecar 容器可对代理的流量进行管控，如统一的服务路由、安全加密、监控采集等。\n图 2：服务网格请求流转过程示意图\nPART. 2 服务网格技术在工行的 探索与实践 工行从 2015 年开启了 IT 架构转型工程，截止目前分布式体系已覆盖 240 余个关键应用，生产已有约超 48 万个提供方分布式服务节点，日均服务调用量超 127 亿，逐步实现了超越主机性能容量的集群处理能力。工行分布式服务平台在稳定支撑已有业务系统的平稳运行同时，也存在一些业界共性的挑战，诸如：\n（1）跨语言技术栈的互联互通需研发多套基础框架，技术研发和维护成本高。\n（2）多产品线下，各应用使用了不同版本的基础框架，推动各应用升级框架周期较长，生产并行运行多版本的基础框架，兼容压力较大。\n为解决当前痛点，工行积极引入服务网格技术，探索解耦业务系统与基础设施，完善服务治理能力。\n与微服务框架融合发展，构建企业级服务网格平台 服务网格（Service Mesh）平台在建设过程中，集成了原有分布式体系的注册中心、服务监控等基础设施，将原服务框架客户端中最基础的通讯协议编解码能力以轻量级客户端的形式保留在业务系统中，其余服务框架客户端的能力均下沉至 Sidecar 中，可与服务框架兼容发展，平滑过渡。\n目前工行已完成服务网格（Service Mesh）平台的建设，在与分布式服务平台融合发展过程中，打通了异构语言系统的服务治理与监控体系，解耦了业务与中间件系统，丰富了流量治理能力，并已在智能投顾、文字识别等应用完成业务试点。\n图 3：服务网格边车（Sidecar）与微服务 SDK 对比图\n服务网格控制平面包含了配置中心、注册中心、安全中心、管控中心、监控中心、日志中心等模块。数据平面 Sidecar 与原服务框架使用相同的通讯协议（Dubbo/Spring Cloud），支持服务网格系统与原服务框架系统互联互通，平滑迁移。\n图 4：工行服务网格架构图\n探索企业级方案，支持规模化部署和平滑迁移 工行服务网格在大数据、高频联机等服务场景下，对流量代理部署模式、平滑迁移、性能优化等方面开展了落地实践。\n（1）大数据场景下的无侵入流量代理部署模式\n工行应用开发语言主要使用 Java，但在大数据领域 Python 语言也被广泛使用。针对异构语言场景，服务网格平台提供了无侵入透明劫持的流量代理方案，简化了异构语言应用接入难度。无侵入流量代理的核心是通过修改网络 Iptables 规则，强制拦截进出业务容器的流量，并将这部分流量重定向至 Sidecar 容器。\n其具体实现为：在启动业务 Pod 时，通过 Init Container（初始化容器）修改业务 Pod 的网络 Iptables 规则，该规则让进出业务容器的流量都强制重定向至 Sidecar 容器，实现 Sidecar 容器对业务容器的流量接管。\n图 5：透明劫持流量代理示意图\n但是 Iptables 对性能和可维护性都存在较大的挑战，故在联机高频服务场景，我们提供了轻量级客户端与 Sidecar 协作的流量代理方案。\n（2）高频联机场景下的低侵入流量代理部署模式\n在联机高频服务场景，我们通过对业务应用引入轻量级的客户端，该客户端在对业务透明的前提下，改变业务应用的服务注册发现行为，将原往注册中心发起的服务注册与订阅的行为转变为往本地 127.0.0.1 的 Sidecar 地址发起服务注册与订阅，并由 Sidecar 代理向注册中心发起服务注册与订阅。业务容器通过 Sidecar 代理订阅后，本地获取的服务目的地址则为 127.0.0.1 的 Sidecar 地址，后续所有请求将会直接发往 Sidecar，再由 Sidecar 转发至真实的服务目的地址，实现流量代理能力。\n图 6：端口流量代理示意图\n（3）传统部署向网格化部署的平滑迁移\n目前工行微服务主要有基于 Dubbo 和 Spring Cloud 两种服务实例组成，且已在生产环境大规模运行，在引入服务网格系统时需具备与原微服务系统的平滑过渡能力。工行通过服务网格系统同时支持 Dubbo 与 Spring cloud 协议，服务网格实例可与原服务框架实例通过相同协议互相访问。使在同一注册中心下，服务网格系统与原分布式服务系统可融合发展，平滑过渡。\n图 7：平滑迁移示意图\n（4）规模化部署后的性能挑战与优化\n目前工行最大的注册中心集群上有超 48 万提供者的超大规模业务场景，而在开源 Isito 架构中，服务发现的目的地址、配置信息等会通过 Pilot 的 Xds API 进行全量下发。在大量服务实例的情况下，全量下发会影响 Pilot 和 Sidecar 的性能和稳定性。服务网格平台通过引入第三方注册中心与配置中心。由 Sidecar 直接对接注册中心与配置中心，支持按需订阅，配置精准下发，大幅降低 Pilot 和 Sidecar 压力。通过压测，控制平面具备支持百万级实例的性能容量能力。\n图 8：工行控制面组件演进 …","date":1639033200,"description":"Service Mesh 在中国工商银行的探索与实践","dir":"blog/exploration-and-practice-of-service-mesh-in-icbc/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a597abc497eb1d695c4aa838d6cb6545","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","publishdate":"2021-12-09T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","summary":"Service Mesh 是下一代的微服务架构基础。蚂蚁集团从 2018 年初就开始了技术探索并进行了落地试点。目前， Service Mesh 覆盖了蚂蚁数千个应用，实现了核心链路全覆盖。 蚂蚁集","tags":["SOFAStack"],"title":"Service Mesh 在中国工商银行的探索与实践","type":"blog","url":"/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","wordcount":3781},{"author":"马振军","categories":"SOFAStack","content":" 文｜马振军（花名：古今 )\n在基础架构领域耕耘多年\n目前在蚂蚁集团中间件团队\n负责 MOSN、Layotto 等项目的开发工作\n校对｜卓与、齐天\n本文 9053 字 阅读 18 分钟\n｜前言｜ 在过去几年里，蚂蚁集团的基础设施进行了广受瞩目的大规模 Mesh 化改造，成为业内服务网格化的一个标杆。在收获了基础架构团队掌握数据平面带来业务敏捷性的同时，也享受到了将基础设施 SDK 从应用中剥离出来后，带来的应用和基础设施双方更高的易维护性。\n然而服务网格并不是银弹，大规模落地后也面临着新的问题。\n适逢其时，微软牵头的 Dapr 横空出世，把分布式应用运行时的概念带入了大众视野，我们也尝试使用这种思路来解决 Mesh 化后遗留的问题。\n本文通过回顾蚂蚁集团一路从微服务架构到 Service Mesh 再到分布式应用运行时的整个演进历程，结合生产落地过程中遇到的各种问题及思考，尝试探讨一下未来五年，云原生运行时可能的发展方向。\nPART. 1 从 Service Mesh 到应用运行时 2018 年，蚂蚁集团在 Service Mesh 刚刚开始流行的时候，就在这个方向上大力投入，如今已三年有余。Sevice Mesh 早已在公司内大规模落地，支持了生产环境数十万容器的日常运行。\n19 年下半年，Dapr 项目正式开源并持续火爆，应用运行时的概念引起了人们的关注，蚂蚁集团也踏上了从 Service Mesh 到应用运行时的演进道路。\nA、蚂蚁 Service Mesh 实践的收获与遗留问题 在传统的微服务架构下，基础架构团队一般会为应用提供一个封装了各种服务治理能力的 SDK，这种做法虽然保障了应用的正常运行。但缺点也非常明显，每次基础架构团队迭代一个新功能都需要业务方参与升级才能使用，而遇到 bugfix 版本，往往需要强推业务方升级，这里面的痛苦程度基础架构团队的每一个成员都深有体会。\n伴随着升级的困难，随之而来的就是应用使用的 SDK 版本差别非常大。生产环境同时跑着各种版本的 SDK ，这种现象又会让新功能的迭代必须考虑各种兼容，时间一长就会让代码维护非常困难，有些祖传逻辑更是不敢改也不敢删。\n同时这种“重” SDK 的开发模式，导致异构语言的治理能力始终很难对标主语言，各种保障高可用的能力都无法作用于异构语言应用。\n后来有人提出了 Service Mesh 的理念，这种理念旨在把服务治理能力跟业务解耦，让两者通过进程级别的通信方式进行交互。在这种架构下，各种服务治理能力从应用中剥离，运行在独立的进程中，让业务团队跟基础架构团队可以各自进行迭代更新，大幅度提升效率。\n同时 SDK 因为功能减少而变“轻”则降低了异构语言的接入门槛，让这些语言开发的应用有机会对标主语言的治理能力。\n在看到 Service Mesh 理念的巨大潜力之后，蚂蚁集团很快就在这个方向上进行了大力投入，如上图所示，首先是使用 Go 语言自研了可以对标 envoy 的数据面。然后把 RPC 中各种治理能力下沉了到 MOSN 中，这样 RPC 的 SDK 变“轻”，而其他基础设施的 SDK 则依旧维持现状。\n在 RPC 能力完成 Mesh 化改造之后，我们进行了快速推广，如今达到了数千个应用，数十万个容器的生产规模。与此同时，全站升级频率最快可以达到 1~2 次/月，这跟传统微服务架构下 1~2 次/年的升级频率相比达到了一个质的提升。\nB、蚂蚁初步泛 Mesh 化的探索 在 RPC 能力完成 Mesh 化改造并且验证了这种架构的可行性以及体验到 Mesh 化带来的迭代效率大幅度提升的收益以后，我们正式走上了整个基础设施泛 Mesh 化改造的道路。\n如上图所示，在泛 Mesh 化改造的大趋势下，除了 RPC 以外，缓存、消息、配置等一些常用的基础设施能力迅速从应用中剥离，下沉到 MOSN 中，这套架构极大的提高了整个基础架构团队的迭代效率。\n正如软件工程没有银弹说的那样，随着泛 Mesh 化落地规模逐渐扩大，我们逐渐意识到它遗留的问题，如上图所示。\n在这种架构下，虽然应用跟基础设施之间加了一层网络代理，但对于基础设施协议部分的处理依然保留在 SDK 中，这就导致应用本质上还是要面向某个基础设施做开发，比如想使用 Redis 作为缓存实现，那么应用需要引入 Redis 的 SDK，未来如果想切换到 Memcache 等其他缓存实现，则必须对应用进行改造。\n除了替换 SDK 之外，甚至还涉及到调用 API 的调整，因此这种架构完全无法满足当前公司面临的同一个应用在多个平台部署的需求。\n与上述问题类似，泛 Mesh 化改造后，“轻” SDK 的低开发成本让各种异构语言都有机会接入到整个基础设施体系中来，享受多年基础设施建设的红利。\n但由于 SDK 里仍然保留了通信、序列化等协议的处理逻辑，因此随着接入的语言越来越多样化，这里依然存在不能忽视的开发成本。换句话说，泛 Mesh 化改造带来的“轻” SDK 跟传统微服务架构相比虽然降低了异构语言接入基础设施的门槛，但是随着接入语言越来越多样，依赖的中间件能力越来越丰富，我们还需要尝试进一步降低这种门槛。\n如果对上述两个问题做一层抽象，本质上都可以归结为应用跟基础设施之间的边界不够清晰，或者说应用中始终嵌入了某种基础设施实现中特有的处理逻辑，导致两者一直耦合在一起。\n因此如何定义应用跟基础设施之间的边界，让两者彻底解绑是我们当下必须要思考解决的问题。\nPART. 2 重新定义基础设施边界 A、如何看待 Dapr Dapr 项目由微软牵头，于 19 年下半年正式开源，作为分布式应用运行时的一种实现方案登上舞台，引起了广泛关注，它向我们展示了如何定义应用跟基础设施之间的边界。\n上图是 Dapr 官方提供的架构图，跟 Service Mesh 架构类似，Dapr 采用 Sidecar 的模型部署在应用跟基础设施之间。但与之不同的是，Dapr 基于 HTTP/gRPC 这类标准协议向应用提供了一套语义明确、面向能力的 API ，让应用可以不再关心基础设施的实现细节，只需专注业务本身依赖哪些能力即可。\n目前 Dapr 已经提供了较为丰富的 API，包括状态管理、发布订阅、服务调用等常见基础设施能力，基本能够覆盖业务日常开发的需求，并且每种能力都对应了多种具体的基础设施实现，开发者可以按需自由切换且这种切换对应用完全透明。\n除了能力之外，Dapr 官方也给出了 Dapr 跟 Service Mesh 之间的异同点，如上图所示。\n两者虽然有一些交集，但本质不同，Service Mesh 强调的是透明的网络代理，它并不关心数据本身，而 Dapr 强调的是提供能力，是真正站在应用的角度来思考如何降低应用的开发成本。\nDapr 本身的优势非常明显，不过 Service Mesh 所提供的丰富的网络治理能力，也是保障应用生产稳定性的关键点。\n与此同时 Dapr 跟基础设施的交互也无法离不开网络，因此有没有一种解决方案可以让应用运行时跟 Service Mesh 双剑合璧，降低应用开发成本的同时保留丰富的网络治理能力？\nB、Layotto：Servcie Mesh \u0026amp;amp; …","date":1638860400,"description":"云原生运行时的下一个五年","dir":"blog/the-next-five-years-of-cloud-native-runtime/","fuzzywordcount":8100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2498666960b384ded6da40a6158f9535","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","publishdate":"2021-12-07T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","summary":"文｜马振军（花名：古今 ) 在基础架构领域耕耘多年 目前在蚂蚁集团中间件团队 负责 MOSN、Layotto 等项目的开发工作 校对｜卓与、齐天 本文 9053 字 阅","tags":["SOFAStack"],"title":"云原生运行时的下一个五年","type":"blog","url":"/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","wordcount":8008},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@xj 提问：\n 请问在 UseNetpollMode 模式下，for 循环读取链接里面的数据，那么如果遇到链接数据源源不断的情况：比如刚 readOnce 读取完毕所有数据后，再下一个循环，又有数据被写入到链接接收缓冲区里面，那么又会继续读取到。此时会损耗很多时间处理这个链接的 io 事件，影响其他链接的处理。\n A：执行久了这个协程会被 runtime 调度走哟,当然也可以多少次 read 就主动 schedule, 这个可能就要看压测数据了，配置多少合适。最开始 nginx 也是存在类似问题。\nhttps://github.com/nginx/nginx/commit/fac4c7bdf53ee7d8fec6568f1e9fecefcde6feba#diff-8f5c3450fb35200b97b96bb249ca15d6\n「MOSN」：https://github.com/mosn/mosn\n@子旦 提问：\n 请教下群里的大佬，SOFARPC 相较于 Dubbo RPC 的优势在哪？有没有相关资料，求分享～\n A：可以看下 FAQ 里面有描述。\nhttps://www.sofastack.tech/projects/sofa-rpc/faq/\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@福自奇 提问：\n 5 个 jraft 节点，一个节点挂了没及时维修，剩下四个节点两两网络分区，2|2，此时集群是不是不可用了。\n A：是，因为已经多数派不可用了（最多只有 2 个节点可用）。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@福自奇 提问：\n bolt 下面输出的日志，jraft 提供了归档或者自动删除的选项吗？现在发现 bolt 下面的日志占用内存 7g 了，是要自己写脚本定时删除吗？\n A：日志没有自动删，可以自己用脚本删。\n 这个如果没有节点异常，好像不会打？只有节点挂了才会打？\n A：bolt 日志正常都会有，如果想关掉可以看下 GitHub 上最新被 close 的 issue。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy 开发 in-memory 组件\nfail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 降本提效！注册中心在蚂蚁集团的蜕变之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1638514800,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211203/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3866acfa6aee9d270af2995d820dcb64","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211203/","publishdate":"2021-12-03T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211203/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211203/","wordcount":1289},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@洪艺辉 提问：\n 无损迁移 TCP Listener 之后，在新 MOSN 上重新 server.Serve(net.Listener)，老 MOSN 那个 Listenr 能马上死掉的 API?\n A：New MOSN 启动成功之后，就关闭老的。\n「MOSN」：https://github.com/mosn/mosn\n@大白 提问：\n MOSN 借助 FastHTTP 解析，是不是就没考虑大的请求了。这边不做处理的考虑是什么呢？\n A：MOSN 有个地方限制太大的请求，好像还可以配置来着。\n 是的，注意到有限制最大 body 大小，但是遇到一些大请求对 Sidecar 压力会很大吧。\n A：RPC 场景一般没有大包，我们有个 issue 是直接 Stream。FastHTTP 也支持流式，要适配下，有兴趣可以一起来搞搞。\nhttps://github.com/mosn/mosn/issues/1676\n「MOSN」：https://github.com/mosn/mosn\n@xj 提问：\n 咨询下 MOSN 在做 gRPC 代理的时候，如何解决代理识别客户端新增的 proto ？难道客户端多一个 proto 代理也要增加？ 还是说直接在 HTTP2.0 层面做？\n A：就是 HTTP2.0 层面，代理一般不需要识别 body。\n「MOSN」：https://github.com/mosn/mosn\n@TyCoding 提问：\n 请问 SOFARPC 不使用 SOFABoot 的话，就只能用这种方式发布服务和消费吗？那如果多个接口呢?\n A：多个接口，就多个 providerconfig 即可。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@王金鹏 提问：\n 有个问题想请教一下 SOFABoot 和 bolt 之间版本兼容的问题，SOFABoot 版本 2.3.4，bolt 原版本 1.4.2 升级到 1.5.8 会不会有兼容性的问题？\n A：最好不要这么升级，bolt 不同版本 API 可能存在差异，最好直接把 SOFABoot 版本升级上去，对应的依赖都是我们测试过的。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy 开发 in-memory 组件\nfail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 降本提效！注册中心在蚂蚁集团的蜕变之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1637910000,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211126/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"134422b15d1bd92c49604b5b45687076","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211126/","publishdate":"2021-11-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211126/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211126/","wordcount":1331},{"author":"林育智","categories":"SOFAStack","content":" 文｜林育智（花名：源三 )\n蚂蚁集团高级专家 专注微服务/服务发现相关领域\n校对｜李旭东\n本文 8624 字 阅读 18 分钟\n｜引 言｜ 服务发现是构建分布式系统的最重要的依赖之一， 在蚂蚁集团承担该职责的是注册中心和 Antvip，其中注册中心提供机房内的服务发现能力，Antvip 提供跨机房的服务发现能力。\n本文讨论的重点是注册中心和多集群部署形态（IDC 维度），集群和集群之间不涉及到数据同步。\nPART. 1 背 景 回顾注册中心在蚂蚁集团的演进，大概起始于 2007\u0026amp;frasl;2008 年，至今演进超过 13 年。时至今日，无论是业务形态还是自身的能力都发生了巨大的变化。\n简单回顾一下注册中心的历代发展：\nV1：引进淘宝的 configserver V2：横向扩展 从这个版本开始，蚂蚁和阿里开始独立的演进，最主要的差异点是在数据存储的方向选择上。蚂蚁选择了横向扩展，数据分片存储。阿里选择了纵向扩展，加大 data 节点的内存规格。\n这个选择影响到若干年后的 SOFARegistry 和 Nacos 的存储架构。\nV3 / V4：LDC 支持和容灾 V3 支持 LDC 单元化。\nV4 增加了决策机制和运行时列表，解决了单机宕机时需要人工介入处理的问题，一定程度上提升高可用和减少运维成本。\nV5：SOFARegistry 前四个版本是 confreg，17 年启动 V5 项目 SOFARegistry，目标是：\n1.代码可维护性：confreg 代码历史包袱较重\n 少量模块使用 guice 做依赖管理，但大部分模块是静态类交互，不容易分离核心模块和扩展模块，不利于产品开源。\n 客户端与服务端的交互模型嵌套复杂，理解成本极高且对多语言不友好。\n 2.运维痛点：引入 Raft 解决 serverlist 的维护问题，整个集群的运维包括 Raft，通过 operator 来简化。\n3.鲁棒性：在一致性 hash 环增加多节点备份机制（默认 3 副本），2 副本宕机业务无感。\n4.跨集群服务发现：站内跨集群服务发现额外需要 antvip 支撑，希望可以统一 2 套设施的能力，同时商业化场景也有跨机房数据同步的需求。\n这些目标部分实现了，部分实现的还不够好，例如运维痛点还残留一部分，跨集群服务发现在面对主站的大规模数据下稳定性挑战很大。\nV6：SOFARegistry 6.0 2020 年 11 月，SOFARegistry 总结和吸收内部/商业化打磨的经验，同时为了应对未来的挑战，启动了 6.0 版本大规模重构计划。\n历时 10 个月，完成新版本的开发和升级工作，同时铺开了应用级服务发现。\nPART. 2 挑 战 当下面临的问题 集群规模的挑战 数据增长：随着业务的发展，业务的实例数在不断增长，pub/sub 的数量也相应增长。以其中一个集群为例，2019 年的数据为基准数据，在 2020 年 pub 接近千万级。 下图是该集群历年双十一时的数据对比和切换应用级的优化效果。相比 2019 年双十一，2021 年双十一接口级的 pub 增长 200%，sub 增长 80%。\n 故障爆炸半径增长：集群接入的实例越多，故障影响的业务和实例数也就越多，保障业务的稳定是最基础也是优先级最高的要求。\n 考验横向扩展能力：集群达到一定的规模后，是否还具备继续横向扩展的能力，需要集群具备良好的横向扩展能力，从 10 扩到 100 和从 100 扩到 500 是不一样的难度。\n HA 能力：集群实例数多了后，面临的节点总体的硬件故障率也相应增高，各种机器故障集群是否能快速恢复？有运维经验的同学都知道，运维一个小集群和运维一个大集群面临的困难简直是指数级增长。\n 推送性能：大多数服务发现的产品都选择了数据的最终一致性，但是这个最终在不同集群的规模下到底是多久？相关的产品其实都没有给出明确的数据。\n 但是实际上，我们认为这个指标是服务发现产品的核心指标。这个时长对调用有影响：新加的地址没有流量；删除的地址没有及时摘除等。蚂蚁集团的 PaaS 对注册中心的推送时延是有 SLO 约束的：如果变更推送列表延时超过约定值，业务端的地址列表就是错误的。我们历史上也曾发生过因推送不及时导致的故障。\n业务实例规模增加的同时也带来推送的性能压力：发布端 pub 下面的实例数增加；订阅端业务实例数增加；一个简单的估算，pub/sub 增长 2 倍，推送的数据量是 2*2，增长 4 倍，是一个乘积的关系。同时推送的性能也决定了同一时间可以支持的最大运维业务实例数，例如应急场景下，业务大规模重启。如果这个是瓶颈，就会影响故障的恢复时间。\n集群规模可以认为是最有挑战性的，核心的架构决定了它的上限，确定后改造成本非常高。而且往往等到发现瓶颈的时候已经是兵临城下了，我们要选择能拉高产品技术天花板的架构。\n运维的挑战 SOFARegistryX 立项时的一个主要目标是具备比 confreg 更好的运维能力：引入 meta 角色，通过 Raft 选举和存储元信息，提供集群的控制面能力。但是事实证明，我们还是低估了可运维的重要性，正如鲁迅先生说：【程序员的工作只有两件事情，一件是运维，另一件还是运维】。\n三年前的目标放到今天已经严重滞后了。\n 集群数增长：蚂蚁集团内部的业务是分站点部署的（简单理解为每个站点是一块相对比较独立的业务，需要不同级别的隔离），同时一个站点需要部署多套集群：容灾需要分机房部署；开发需要分多环境。部署站点的数目增长超出我们的想像。现在已经达到数百个集群了，还在迅速增长中，增长速度参考最近几年美联储的货币供应量增长速度。以前认为有些运维工作可以苟且，人肉顶一下，集群数增长后，苟且次数太多了，挤占了开发/运维同学的精力，完全没资源去规划诗和远方。 业务打扰：业务的运维是全天候 7*24 的，容量自适应/自愈/MOSN 每月一版本把全站应用犁一遍等等。下图是每分钟运维的机器批数，可以看到，就算是周末和深夜，运维任务也是不断的。 蚂蚁集团的同学对注册中心的运维公告应该是比较熟悉和痛恨的。因为业务的敏感性，注册中心之前一直是停机发布和运维，这个时候需要锁定全站的发布/重启动作。为了尽量少影响业务，注册中心相关的同学只能献祭一头黑发，在深夜低峰期做相关的操作。即使这样，仍然没办法做到对业务零打扰。\n云原生时代 naming 的挑战 云原生的技术时代下，可以观察到一些趋势：\n 微服务/FaaS 的推广导致轻型应用增多：实例数增多，需要能支撑更大的业务规模\n 应用实例的生命周期更短：FaaS 按需使用，autoscale 容量自适应等手段导致实例的涨潮退潮更频繁，注册中心的性能主要体现在实例变更的响应速度上\n 多语言支持：在过去，蚂蚁集团主要的开发体系是 Java，非 Java 语言对接基础设施都是二等公民，随着 AI 和创新性业务的需求，非 Java 体系的场景越来越多。如果按照每种语言一个 SDK，维护成本会是个噩梦，当然 sidecar（MOSN）是个解法，但是自身是否能支持低侵入性的接入方式，甚至 sdk-free 的能力？\n 服务路由：在过去绝大部分的场景都可以认为 endpoint 是平等的，注册中心只提 …","date":1637650800,"description":"降本提效！注册中心在蚂蚁集团的蜕变之路","dir":"blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","fuzzywordcount":7800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f75ce63f7162ca26342a52f74ce577ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","publishdate":"2021-11-23T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","summary":"文｜林育智（花名：源三 ) 蚂蚁集团高级专家 专注微服务/服务发现相关领域 校对｜李旭东 本文 8624 字 阅读 18 分钟 ｜引 言｜ 服务发现是构建分布式系统的最重要的","tags":["SOFAStack"],"title":"降本提效！注册中心在蚂蚁集团的蜕变之路","type":"blog","url":"/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","wordcount":7736},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@黄润良 提问：\n 有什么办法可以获取日志的这两个值吗？\n A：可以参考下图\n MOSN：https://github.com/mosn/mosn\n@爱德华 提问：\n 请教一下，SOFAJRaft 在 leader 晋升后，给每个 follower 发送的探测请求是什么？是 Raft 论文中，为了“提交上一个 term 日志项”，才发送的空请求吗？\n A：是为了探测该 follower 与 leader 的日志差异。找对 nextIndex 对吧？提交上一个 term 要通过 noop 日志。Raft 论文里有个 nextIndex，你可以看看相关内容， 日志复制那个小节。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@Bazingga 提问：\n 源码里面是怎么支持的呀，RheaKV 是使用了这个功能是吧。\n A：可以参考下这个 https://blog.csdn.net/SOFAStack/article/details/91458041\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@爱德华 提问：\n 我请教一下关于 follower 截断日志的问题。leader 拥有日志：101,102,103，它们的 term 为 2；follower 拥有日志：101,102,103,104，它们的 term 为 2；按照正常逻辑，follower 应该截断 104 的日志。根据上面的代码，在探测消息中，这种情况，follower 会返回了 success=true，并携带 lastLogIndex=104。那么 follower 是在什么时候截断 104 的呢？\n A：checkAndResolveConflict 方法。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 在服务注册时，使用枚举值替代字符串硬编码\n优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n开发 spring-boot-laytto\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 rometheus on CeresDB 演进之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1637305200,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211119/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"05f1b91614900f1434b7748905df364b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211119/","publishdate":"2021-11-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211119/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211119/","wordcount":1249},{"author":"刘家财","categories":"SOFAStack","content":" 文｜刘家财（花名：尘香 )\n蚂蚁集团高级开发工程师 专注时序存储领域\n校对｜冯家纯\n本文 7035 字 阅读 10 分钟\nCeresDB 在早期设计时的目标之一就是对接开源协议，目前系统已经支持 OpenTSDB 与 Prometheus 两种协议。Prometheus 协议相比 OpenTSDB 来说，非常灵活性，类似于时序领域的 SQL。\n随着内部使用场景的增加，查询性能、服务稳定性逐渐暴露出一些问题，这篇文章就来回顾一下 CeresDB 在改善 PromQL 查询引擎方面做的一些工作，希望能起到抛砖引玉的作用，不足之处请指出。\nPART. 1 内存控制 对于一个查询引擎来说，大部分情况下性能的瓶颈在 IO 上。为了解决 IO 问题，一般会把数据缓存在内存中，对于 CeresDB 来说，主要包括以下几部分：\n MTSDB：按数据时间维度缓存数据，相应的也是按时间范围进行淘汰\n Column Cache：按时间线维度缓存数据，当内存使用达到指定阈值时，按时间线访问的 LRU 进行淘汰\n Index Cache：按照访问频率做 LRU 淘汰\n 上面这几个部分，内存使用相对来说比较固定，影响内存波动最大的是查询的中间结果。如果控制不好，服务很容易触发 OOM 。\n中间结果的大小可以用两个维度来衡量：横向的时间线和纵向的时间线。\n控制中间结果最简单的方式是限制这两个维度的大小，在构建查询计划时直接拒绝掉，但会影响用户体验。比如在 SLO 场景中，会对指标求月的统计数据，对应的 PromQL 一般类似 sum_over_time(success_reqs[30d]) ，如果不能支持月范围查询，就需要业务层去适配。\n要解决这个问题需要先了解 CeresDB 中数据组织与查询方式，对于一条时间线中的数据，按照三十分钟一个压缩块存放。查询引擎采用了向量化的火山模型，在不同任务间 next 调用时，数据按三十分钟一个批次进行传递。\n在进行上述的 sum_over_time 函数执行时，会先把三十天的数据依次查出来，之后进行解压，再做一个求和操作，这种方式会导致内存使用量随查询区间线性增长。如果能去掉这个线性关系，那么查询数量即使翻倍，内存使用也不会受到太大影响。\n为了达到这个目的，可以针对具备累加性的函数操作，比如 sum/max/min/count 等函数实现流式计算，即每一个压缩块解压后，立即进行函数求值，中间结果用一个临时变量保存起来，在所有数据块计算完成后返回结果。采用这种方式后，之前 GB 级别的中间结果，最终可能只有几 KB。\nPART. 2 函数下推 不同于单机版本的 Prometheus ，CeresDB 是采用 share-nothing 的分布式架构，集群中有主要有三个角色：\n datanode：存储具体 metric 数据，一般会被分配若干分片(sharding)，有状态\n proxy：写入/查询路由，无状态\n meta：存储分片、租户等信息，有状态。\n 一个 PromQL 查询的大概执行流程：\n1.proxy 首先把一个 PromQL 查询语句解析成语法树，同时根据 meta 中的分片信息查出涉及到的 datanode\n2.通过 RPC 把语法树中可以下推执行的节点发送给 datanode\n3.proxy 接受所有 datanode 的返回值，执行语法树中不可下推的计算节点，最终结果返回给客户端\nsum(rate(write_duration_sum[5m])) / sum(rate(write_duration_count[5m])) 的执行示意图如下：\n为了尽可能减少 proxy 与 datanode 之间的 IO 传输，CeresDB 会尽量把语法树中的节点推到 datanode 层中，比如对于查询 sum(rate(http_requests[3m])) ，理想的效果是把 sum、rate 这两个函数都推到 datanode 中执行，这样返回给 proxy 的数据会极大减少，这与传统关系型数据库中的“下推选择”思路是一致的，即减少运算涉及的数据量。\n按照 PromQL 中涉及到的分片数，可以将下推优化分为两类：单分片下推与多分片下推。\n单分片下推 对于单分片来说，数据存在于一台机器中，所以只需把 Prometheus 中的函数在 datanode 层实现后，即可进行下推。这里重点介绍一下 subquery【1】 的下推支持，因为它的下推有别于一般函数，其他不了解其用法的读者可以参考 Subquery Support【2】。\nsubquery 和 query_range【3】 接口（也称为区间查询）类似，主要有 start/end/step 三个参数，表示查询的区间以及数据的步长。对于 instant 查询来说，其 time 参数就是 subquery 中的 end ，没有什么争议，但是对于区间查询来说，它本身也有 start/end/step 这三个参数，怎么和 subquery 中的参数对应呢？\n假设有一个步长为 10s 、查询区间为 1h 的区间查询，查询语句是\n那么对于每一步，都需要计算 3600\u0026amp;frasl;10=360 个数据点，按照一个小时的区间来算，总共会涉及到 360*360=129600 的点，但是由于 subquery 和区间查询的步长一致，所以有一部分点是可以复用的，真正涉及到的点仅为 720 个，即 2h 对应 subquery 的数据量。\n可以看到，对于步长不一致的情况，涉及到的数据会非常大，Prometheus 在 2.3.0 版本后做了个改进，当 subquery 的步长不能整除区间查询的步长时，忽略区间查询的步长，直接复用 subquery 的结果。这里举例分析一下：\n假设区间查询 start 为 t=100，step 为 3s，subquery 的区间是 20s，步长是 5s，对于区间查询，正常来说：\n1.第一步\n需要 t=80, 85, 90, 95, 100 这五个时刻的点\n2.第二步\n需要 t=83, 88, 83, 98, 103 这五个时刻的点\n可以看到每一步都需要错开的点，但是如果忽略区间查询的步长，先计算 subquery ，之后再把 subquery 的结果作为 range vector 传给上一层，区间查询的每一步看到的点都是 t=80, 85, 90, 95, 100, 105…，这样就又和步长一致的逻辑相同了。此外，这么处理后，subquery 和其他的返回 range vector 的函数没有什么区别，在下推时，只需要把它封装为一个 call （即函数）节点来处理，只不过这个 call 节点没有具体的计算，只是重新根据步长来组织数据而已。\ncall: avg_over_time step:3 └─ call: subquery step:5 └─ binary: == ├─ selector: a_gauge └─ literal: 2 在上线该优化前，带有 subquery 的查询无法下推，这样不仅耗时长，而且还会生产大量中间结果，内存波动较大；上线该功能后，不仅有利于内存控制， …","date":1637046000,"description":"Prometheus on CeresDB 演进之路","dir":"blog/prometheus-on-ceresdb-evolutionary-path/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c56a0b61329eb6462295f7bfb16ee6b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","publishdate":"2021-11-16T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","summary":"文｜刘家财（花名：尘香 ) 蚂蚁集团高级开发工程师 专注时序存储领域 校对｜冯家纯 本文 7035 字 阅读 10 分钟 CeresDB 在早期设计时的目标之一就是对接开源协议，目前系","tags":["SOFAStack"],"title":"Prometheus on CeresDB 演进之路","type":"blog","url":"/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","wordcount":4807},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@zjw 提问：\n 请教个 SOFARegistry 的问题，sessionServer 启动后，地址是上报给 Meta 的吗？如果 sessionServer 意外关闭，地址是什么时候怎么摘除的？\n A：session 会定时向 Meta 发送请求对自己的地址进行心跳续约，session 宕机后，Meta 端一段时间接收不到心跳就会摘除宕机的 session，然后广播给所有其他的 session。目前是靠心跳，超时之后 Meta 会把 session 或者 data 剔除。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@滕川 提问：\n 如果 leader 节点挂了，新选举的 leader 节点如何知道各个 follower 节点的 match index。\n A：leader 不需要知道，leader 节点就直接发 appendEtries 即可。如果哪个 follower 还缺更之前的 log，那么它拒绝掉这次 appendEntries 就可以了， leader 会有相应的回退处理逻辑。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@橙橙不是澄澄 提问：\n Raft 里面为什么不要 observer 呢？恰好之前看到 ZooKeeper 里面有这个角色。\n A：Raft 里面可以有类似的角色，叫 learner。learner 不参与选举，只接收 leader 日志，JRaft 也支持 learner。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@邓君武 提问：\n SOFAJRaft 文档中说支持 MULTI-RAFT-GROUP，目前 SOFAJRaft-RheaKV 这个存储组件中用到了。那么如果我想根据 SOFAJRaft 实现一个分布式的业务系统，MULTI-RAFT-GROUP 该怎么用呢？\n A：MULTI-RAFT-GROUP 主要用于解决 SIGLE-RAFT-GROUP 单点瓶颈问题（存储或是吞吐），多个 group 中每个 group 都有一个 leader，可以把 leader 打散到不同的机器上，提高并发度。JRaft 天然支持 MULTI-RAFT-GROUP ，使用的话可以参考 RheaKV。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 在服务引用和发布时，使用枚举值替代字符串硬编码\n优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n升级由 Rust 开发的 Wasm demo\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n 蚂蚁集团技术风险代码化平台实践（MaaS）\n ","date":1636700400,"description":"SOFA WEEKLY | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211112/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"801d338b492a06363ed6a129c2da9774","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211112/","publishdate":"2021-11-12T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211112/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211112/","wordcount":1544},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft\n 活动时间：11月10日,周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft SOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 冯家纯 蚂蚁集团高级技术专家。 蚂蚁集团-智能监控-技术中台（存储）团队技术负责人，团队负责时序数据库相关。 分布式服务框架 Jupiter 作者。 基于 Raft 的分布式共识算法库 SOFAJRaft 开源负责人、核心开发者。 议程 18:50-19:00 主持人开场 小助手-泡椒 主持人\n19:00-19:30 分布式共识：Raft 与 SOFAJRaft 冯家纯，蚂蚁集团高级技术专家\n你将收获 对 Raft 共识算法有所了解，还可以了解到 SOFAJRaft 基于 Raft 算法做了哪些优化，以及实现 Raft 算法的一些好的实践经验。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1636527600,"description":"11 月 10 日周三晚 19 点，线上直播第 22 期。","dir":"activities/sofa-channel-22/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"896e421f2df319f46ec573a77343446c","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-22/","publishdate":"2021-11-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-22/","summary":"概要 活动主题：SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft 活动时间：11月10日,周三晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站","tags":["SOFAChannel","HTTP/3"],"title":"SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft","type":"activities","url":"/sofastack.tech/activities/sofa-channel-22/","wordcount":643},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@玄灭 提问：\n 大佬，关于 downStream 和 upStream，你看看我这个理解对不对哈？一个 MOSN 进程，既会代理当前 pod 的业务进程流量请求，此时 downStream 是当前 pod 进程；同时，这个 MOSN 进程也会代理其他 pod 请求当前 pod 的流量，此时当前 pod 就不能成为 downStream；也就是说，角色会互换。从另一个角度，从 server 端口进来的，都是 downStream，使用 client 向外其他进程发送数据，都是 upStream。 A：一般来说，downStream 就是 server listen 请求，upStream 是 client，发送请求。你说的第一种，一般用 Ingress、Egress 来区分。\n 在 MOSN 里，downStream 永远是 side 进程吗？\n A：MOSN 里面，downStream 就是 server 端，接收请求的。\n MOSN 两个端口的话，server 端可能是 side 进程，也可能是其他 MOSN 进程。所以 downStream 可以是 side 进程的请求，也可以是其他 MOSN 进程的请求。\n A：站在 MOSN 角度，给我发请求的就是 downStream。\n「MOSN」：https://github.com/mosn/mosn\n@zzzZ 提问：\n 怎么将实现的 Eventhandler 注册进容器中，监听容器启动和停止事件？\n A：这里有具体讲解，https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/\n 事件能传播吗？比如 master 传播给子模块内。 A：容器级别的会传播。\n 「SOFABoot」：https://github.com/sofastack/sofa-boot\n@苏千 提问：\n 如何让 Layotto 打印日志，将 metadata 打印出来，我传递了没有生效，想看看是否传递错误。\n A：Layotto 现在默认 log 就是打印的，但没打印 metadata 里面的值，现在 oss 的实现就没传 prefix，所以不生效吧。\n可以试一下这个方法，如果这样的话，你 SDK 测需要适配一下。https://github.com/mosn/layotto/issues/98#issuecomment-957479097\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n升级由 Rust 开发的 Wasm demo\n Hard 集成 Skywalking、Jaeger 等系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 如何在生产环境排查 Rust 内存占用过高问题\n 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1636095600,"description":"SOFA Weekly |Layotto 本周 Contributor、QA 整理、新手任务","dir":"blog/sofa-weekly-20211105/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f2607e9479571a83a8453798866de8f9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211105/","publishdate":"2021-11-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211105/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly |Layotto 本周 Contributor、QA 整理、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211105/","wordcount":1382},{"author":"魏熙凯","categories":"SOFAStack","content":" 📄\n文｜魏熙凯（蚂蚁集团技术专家）\n本文 6320 字 阅读 10 分钟\n▼\n内存安全的 Rust，虽然基本不会出现内存泄漏，但如何合理分配内存，是每个复杂应用都要面临的问题。往往随着业务的不同，相同的代码可能会产生不同的内存占用。因此，有不小的概率会出现内存使用过多、内存逐渐增长不释放的问题。\n本文我想分享一下，我们在实践过程中遇到的关于内存占用过高的问题。对于这些内存问题，在本文中会做出简单的分类，以及提供我们在生产环境下进行排查定位的方法给大家参考。\n 本文最先发表于 RustMagazine 中文月刊\n(https://rustmagazine.github.io/rust_magazine_2021/chapter_5/rust-memory-troubleshootting.html）\n 内存分配器 首先在生产环境中，我们往往不会选择默认的内存分配器（malloc），而是会选择 jemalloc，可以提供更好的多核性能以及更好的避免内存碎片（详细原因可以参考[1]）。Rust 的生态中，对于 jemalloc 的封装有很多优秀的库，这里我们就不纠结于哪一个库更好，我们更关心如何使用 jemalloc 提供的分析能力，帮助我们诊断内存问题。\n阅读 jemalloc 的使用文档，可以知道其提供了基于采样方式的内存 profile 能力，而且可以通过 mallctl 可以设置 prof.active 和 prof.dump 这两个选项，来达到动态控制内存 profile 的开关和输出内存 profile 信息的效果。\n内存快速增长直至 oom 这样的情况一般是相同的代码在面对不同的业务场景时会出现，因为某种特定的输入（往往是大量的数据）引起程序的内存快速增长。\n不过有了上面提到的 memory profiling 功能，快速的内存增长其实一个非常容易解决的情况，为我们可以在快速增长的过程中打开 profile 开关，一段时间后，输出 profile 结果，通过相应的工具进行可视化，就可以清楚地了解到哪些函数被调用，进行了哪些结构的内存分配。\n不过这里分为两种情况：可以复现以及难以复现，对于两种情况的处理手段是不一样的，下面对于这两种情况分别给出可操作的方案。\n**可以复现\n可以复现的场景其实是最容易的解决的问题，因为我们可以在复现期间采用动态打开 profile，在短时间内的获得大量的内存分配信息即可。\n下面给出一个完整的 demo，展示一下在 Rust 应用中如何进行动态的内存 profile。\n本文章，我会采用jemalloc-sys jemallocator jemalloc-ctl 这三个 Rust 库来进行内存的 profile，这三个库的功能主要是：\n```jemallocator```: 实现了 Rust 的 ```GlobalAlloc```，用来替换默认的内存分配器。 ```jemalloc-ctl```: 提供了对于 mallctl 的封装，可以用来进行 tuning、动态配置分配器的配置、以及获取分配器的统计信息等。 下面是 demo 工程的依赖： ``` java [dependencies] jemallocator = \u0026amp;quot;0.3.2\u0026amp;quot; jemalloc-ctl = \u0026amp;quot;0.3.2\u0026amp;quot; [dependencies.jemalloc-sys] version = \u0026amp;quot;0.3.2\u0026amp;quot; features = [\u0026amp;quot;stats\u0026amp;quot;, \u0026amp;quot;profiling\u0026amp;quot;, \u0026amp;quot;unprefixed_malloc_on_supported_platforms\u0026amp;quot;] [profile.release] debug = true 其中比较关键的是jemalloc-sys 的几个 features 需要打开，否则后续的 profile 会遇到失败的情况，另外需要强调的是 demo 的运行环境是在 Linux 环境下运行的。\n然后 demo 的 src/main.rs 的代码如下：\nuse jemallocator; use jemalloc_ctl::{AsName, Access}; use std::collections::HashMap; #[global_allocator] static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc; const PROF_ACTIVE: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;prof.active\\0\u0026amp;quot;; const PROF_DUMP: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;prof.dump\\0\u0026amp;quot;; const PROFILE_OUTPUT: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;profile.out\\0\u0026amp;quot;; fn set_prof_active(active: bool) { let name = PROF_ACTIVE.name(); name.write(active).expect(\u0026amp;quot;Should succeed to set prof\u0026amp;quot;); } fn dump_profile() { let name = PROF_DUMP.name(); name.write(PROFILE_OUTPUT).expect(\u0026amp;quot;Should succeed to dump profile\u0026amp;quot;) } fn main() { set_prof_active(true); let mut buffers: Vec\u0026amp;lt;HashMap\u0026amp;lt;i32, i32\u0026amp;gt;\u0026amp;gt; = Vec::new(); for _ in 0..100 { buffers.push(HashMap::with_capacity(1024)); } set_prof_active(false); dump_profile(); } demo 已经是非常简化的测试用例了，主要做如下的说明：\n编译完成之后，直接运行程序是不行的，需要设置好环境变量（开启内存 profile 功能）： export MALLOC_CONF=prof:true 然后再运行程序，就会输出一份 memory profile 文件，demo 中文件名字已经写死 —— ```profile.out```，这个是一份文本文件，不利于直接观察（没有直观的 symbol）。 通过 jeprof 等工具，可以直接将其转化成可视化的图形： ```jeprof --show_bytes --pdf \u0026amp;lt;path_to_binary\u0026amp;gt; ./profile.out \u0026amp;gt; ./profile.pdf``` 这样就可以将其可视化，从下图中，我们可以清晰地看到所有的内存来源： …","date":1635836400,"description":"如何在生产环境排查 Rust 内存占用过高问题","dir":"blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a2811b69df2016f531d4d42a431a7683","permalink":"https://sofastack.github.io/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","publishdate":"2021-11-02T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","summary":"📄 文｜魏熙凯（蚂蚁集团技术专家） 本文 6320 字 阅读 10 分钟 ▼ 内存安全的 Rust，虽然基本不会出现内存泄漏，但如何合理分配内存，是每个复杂应用都要面临","tags":["SOFAStack"],"title":"如何在生产环境排查 Rust 内存占用过高问题","type":"blog","url":"/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","wordcount":3930},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@崔伟协 提问：\n PingPong 是类似 HTTP 的 req/resp 吗? Multiplex 是类似 HTTP2.0 的没有队头阻塞吗？ A：是的。\n 自己实现的 xprotocol 自定义子协议，要怎么配置 downstream 是 PingPong 还是 Multiplex 呢，PoolMode() api.PoolMode 这个方法似乎只影响 upstream 的 conn pool?\n A：downstream 不用感知，这个访问你的 client 就决定他的行为。\n「MOSN」：https://github.com/mosn/mosn\n2.@玄灭 提问：\n 请教下 MOSN 可以同时支持多个协议吗？比如同时支持 HTTP1.1、rocketmq 协议。\n A：可以的，一个端口都可以。协议可以做自动识别，协议配置就可以配置 Auto。\n「MOSN」：https://github.com/mosn/mosn\n3.@玄灭 提问：\n 业务层的 SDK 用的什么协议呢？比如 mq 用的是私有协议，还是和 RPC 统一是一个协议啊？\n A：我们两种模式，一种是私有协议，一种是统一协议都有再用，统一协议是用 Layotto 支持的。\n 你们的大方向是统一协议，还是私有协议啊？我理解的私有协议对于上游改造成本，会比较小吧；统一协议的话，成本比较大。\n A：私有协议你认为是 Mesh 了，现有业务的支持；统一协议就是类似 Dapr 这种，新业务使用不同场景。\n「MOSN」：https://github.com/mosn/mosn\n4.@晓辰 提问：\n 请问一下 MOSN 有支持 windows 的计划吗？\n A：Go 语言跨平台应该支持的，你提个 pr 看看，是不是有些 Linux 需要跳过？\n「MOSN」：https://github.com/mosn/mosn\n5.@王磊 提问：\n MOSN 目前支持的 Istio 版本是 1.5.2 吗？更高的 Istio 版本支持有计划吗？\n A：这个分支，近期会合到 Master。\nhttps://github.com/mosn/mosn/tree/istio-1.10\n「MOSN」：https://github.com/mosn/mosn\n6.@孙力 提问：\n MOSN 有剔除上游故障节点的功能吗? 比如上游服务有 5 台服务器，访问其中一台总报错，下次就不选这台了。\n https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ffaulttolerance\n 这个 stream_filter 应该是只要上游 host 返回的状态码代表异常就会统计，达到一定比例就会 healthFlag 置为 false。但我们其实想做接口 + host 的，比如访问上游的某个 HTTP 接口总失败，只是针对下次访问这个接口时，才剔除节点，这样是不是需要自己定制一下 InvocationKey ？\n A：还是有区别的，这个是把 host 置为失败了，是全局的，其他接口也会失败。删除了之后，其他访问这个接口请求也不会访问这个 host 了。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n用某种存储实现 File API 组件（例如本地文件系统、hdfs、ftp 等）\n升级由 rust 开发的 wasm demo\nSOFARPC 本周发布 本周 SOFARPC 发布 v5.8.0 版本代码。\n主要更新如下：\n RpcInvokeContext 中增加调用时精细化耗时埋点信息\n Java 集合的使用优化\n 修复 RouterChain 加入不存在的 Router 时 NPE 问题\n 增加泛型修复配置类中类型传递问题\n bolt 版本从 1.5.6 升级到 1.5.9\n hessian 版本从 3.3.7 升级到 3.3.13\n nacos 版本从 1.0.0 升级到 2.0.3\n httpclient 版本从 4.5.11 升级到 4.5.13\n commons-io 版本从 2.4 升级到 2.7\n 「详细参考」：https://github.com/sofastack/sofa-rpc/releases/tag/v5.8.0\n本周推荐阅读 蚂蚁集团技术风险代码化平台实践（MaaS）\n 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1635490800,"description":"SOFA WEEKLY |Layotto 本周 Contributor、QA 整理、 SOFARPC 本周发布","dir":"blog/sofa-weekly-20211029/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dc10182aab6b4170339c958ac73dd2bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211029/","publishdate":"2021-10-29T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211029/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、 SOFARPC 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211029/","wordcount":1667},{"author":"黄章衡","categories":"SOFAStack","content":" 📄\n文｜黄章衡（SOFAJRaft 项目组）\n福州大学 19 级计算机系\n研究方向｜分布式中间件、分布式数据库\nGithub 主页｜https://github.com/hzh0425\n校对｜冯家纯（SOFAJRaft 开源社区负责人）\n本文 9402 字 阅读 18 分钟\n▼\nPART. 1 项目介绍 1.1 SOFAJRaft 介绍 SOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\nGithub 地址：\nhttps://github.com/sofastack/sofa-jraft\n1.2 任务要求 目标：当前 LogStorage 的实现，采用 index 与 data 分离的设计，我们将 key 和 value 的 offset 作为索引写入 rocksdb，同时日志条目（data）写入 Segment Log。因为使用 SOFAJRaft 的用户经常也使用了不同版本的 rocksdb，这就要求用户不得不更换自己的 rocksdb 版本来适应 SOFAJRaft， 所以我们希望做一个改进：移除对 rocksdb 的依赖，构建出一个纯 Java 实现的索引模块。\nPART. 2 前置知识 Log Structured File Systems\n如果学习过类似 Kafka 等消息队列的同学，对日志型系统应该并不陌生。\n如图所示，我们可以在单机磁盘上存储一些日志型文件，这些文件中一般包含了旧文件和新文件的集合。区别在于 Active Data File 一般是映射到内存中的并且正在写入的新文件(基于 mmap 内存映射技术)，而 Older Data File 是已经写完了，并且都 Flush 到磁盘上的旧文件，当一块 Active File 写完之后，就会将其关闭，并打开一个新的 Active File 继续写。\n并且每一次的写入，每个 Log Entry 都会被 Append 到 Active File 的尾部，而 Active File 往往会用 mmap 内存映射技术，将文件映射到 os Page Cache 里，因此每一次的写入都是内存顺序写，性能非常高。\n终上所述，一块 File 无非就是一些 Log Entry 的集合，如图所示:\n同时，仅仅将日志写入到 File 中还不够，因为当需要搜索日志的时候，我们不可能顺序遍历每一块文件去搜索，这样性能就太差了。所以我们还需要构建这些文件的 “目录”，也即索引文件。这里的索引本质上也是一些文件的集合，其存储的索引项一般是固定大小的，并提供了 LogEntry 的元信息，如:\n- File_Id : 其对应的 LogEntry 存储在哪一块 File 中\n- Value_sz : LogEntry 的数据大小\n(注: LogEntry 是被序列化后, 以二进制的方式存储的)\n- Value_pos: 存储在对应 File 中的哪个位置开始\n- 其他的可能还有 crc，时间戳等\u0026amp;hellip;\u0026amp;hellip;\n那么依据索引文件的特性，就能够非常方便的查找 IndexEntry。\n- 日志项 IndexEntry 是固定大小的\n- IndexEntry 存储了 LogEntry 的元信息\n- IndexEntry 具有单调递增的特性\n举例，如果要查找 LogIndex = 4 的日志:\n- 第一步，根据 LogIndex = 4，可以知道索引存储的位置：IndexPos = IndexEntrySize * 4\n- 第二步，根据 IndexPos，去索引文件中，取出对应的索引项 IndexEntry\n- 第三步，根据 IndexEntry 中的元信息，如 File_Id、Pos 等，到对应的 Data File 中搜索\n- 第四步，找到对应的 LogEntry\n内存映射技术 mmap\n上文一直提到了一个技术：将文件映射到内存中，在内存中写 Active 文件，这也是日志型系统的一个关键技术，在 Unix/Linux 系统下读写文件，一般有两种方式。\n传统文件 IO 模型\n一种标准的 IO 流程, 是 Open 一个文件，然后使用 Read 系统调用读取文件的一部分或全部。这个 Read 过程是这样的：内核将文件中的数据从磁盘区域读取到内核页高速缓冲区，再从内核的高速缓冲区读取到用户进程的地址空间。这里就涉及到了数据的两次拷贝：磁盘-\u0026amp;gt;内核，内核-\u0026amp;gt;用户态。\n而且当存在多个进程同时读取同一个文件时，每一个进程中的地址空间都会保存一份副本，这样肯定不是最优方式的，造成了物理内存的浪费，看下图：\n内存映射技术\n第二种方式就是使用内存映射的方式\n具体操作方式是：Open 一个文件，然后调用 mmap 系统调用，将文件内容的全部或一部分直接映射到进程的地址空间(直接将用户进程私有地址空间中的一块区域与文件对象建立映射关系)，映射完成后，进程可以像访问普通内存一样做其他的操作，比如 memcpy 等等。mmap 并不会预先分配物理地址空间，它只是占有进程的虚拟地址空间。\n当第一个进程访问内核中的缓冲区时，因为并没有实际拷贝数据，这时 MMU 在地址映射表中是无法找到与地址空间相对应的物理地址的，也就是 MMU 失败，就会触发缺页中断。内核将文件的这一页数据读入到内核高速缓冲区中，并更新进程的页表，使页表指向内核缓冲中 Page Cache 的这一页。之后有其他的进程再次访问这一页的时候，该页已经在内存中了，内核只需要将进程的页表登记并且指向内核的页高速缓冲区即可，如下图所示：\n对于容量较大的文件来说（文件大小一般需要限制在 1.5~2G 以下），采用 mmap 的方式其读/写的效率和性能都非常高。\n当然，需要如果采用了 mmap 内存映射，此时调用 Write 并不是写入磁盘，而是写入 Page Cache 里。因此，如果想让写入的数据保存到硬盘上，我们还需要考虑在什么时间点 Flush 最合适(后文会讲述)。\nPART. 3 架构设计 3.1 SOFAJRaft 原有日志系统架构 下图是 SOFAJRaft 原有日志系统整体上的设计：\n其中 LogManager 提供了和日志相关的接口，如:\n/** * Append log entry vector and wait until it\u0026#39;s stable (NOT COMMITTED!) * * @param entries log entries * @param done callback */ void appendEntries(final Listentries, StableClosure done); /** * Get the log entry at index. * * @param index the index of log entry * @return the …","date":1635231600,"description":"新一代日志型系统在 SOFAJRaft 中的应用","dir":"blog/a-new-generation-of-log-based-systems-in-sofajraft/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0d3a13e7ed41a72bee7fe7973424e4e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","publishdate":"2021-10-26T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","summary":"📄 文｜黄章衡（SOFAJRaft 项目组） 福州大学 19 级计算机系 研究方向｜分布式中间件、分布式数据库 Github 主页｜https://github.com","tags":["SOFAStack"],"title":"新一代日志型系统在 SOFAJRaft 中的应用","type":"blog","url":"/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","wordcount":5282},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）\n 活动时间：2021 年 10 月 23 日（周六）13:30-17:30\n 活动地点：上海市浦东新区南泉北路 447 号蚂蚁 S 空间 1210 明月台\n 活动形式：线下活动\n 资料下载： 《攀登规模化的高峰蚂蚁集团大规模 Sigma 集 ApiServer 优化实践》\n 活动回顾 《攀登规模化的高峰蚂蚁集团大规模 Sigma 集 ApiServer 优化实践》\n嘉宾介绍\n唐博：蚂蚁集团技术专家，目前主要致力于 Kubernetes 性能和规模化方向，在资源编排调度，以及机器学习平台等领域有所涉猎，是 Kubernetes/istio/volcano 等云原生相关项目的代码贡献者。\n谭崇康：蚂蚁集团高级技术专家，负责大规模 K8s 集群设计、集群性能及 Pod 交付成功率及吞吐保障。长期从事云平台领域的新架构研发工作，研究兴趣包括 Kubernetes 领域的最新技术、操作系统、大数据、AIOps 等。\n议题简介\n 蚂蚁集团运行着全球最大的 Kubernetes（内部称为 Sigma） 集群之一，本次分享将介绍蚂蚁集团构建万级节点的大规模 Kubernetes 集群以及优化 Kubernetes apiserver 的过程当中的挑战和解决方案. 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1634972400,"description":"【活动回顾】SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）","dir":"activities/sofa-meetup-12/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"590a0e1f5b8a6a4035844058f4361490","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-12/","publishdate":"2021-10-23T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-12/","summary":"概要 活动主题：SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day） 活动时间：2021 年 10 月 23 日（周六）13:30-17:30 活","tags":["SOFAMeetup"],"title":"【活动回顾】SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-12/","wordcount":479},{"author":"赵陈","categories":"SOFAStack","content":" 📄\n文｜赵陈（SOFA 开源之夏链路项目组)\n武汉理工大学计算机工程硕士在读\n研究方向：唐卡线稿的自动上色\n校对｜宋国磊（SOFATracer commiter)\n本文 6971 字 阅读 18 分钟\n▼\n背 景 有幸参与开源软件供应链点亮计划——暑期 2021 支持的开源项目，目前 SOFATracer 已经能够将埋点数据上报到 Zipkin 中，本项目的主要目标是将产生的埋点数据上报给 Jaeger 和 SkyWalking 中进行可视化展示。\nPART. 1 SOFATracer SOFATracer 是蚂蚁集团基于 OpenTracing 规范开发的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer 提供了异步落地磁盘的日志打印能力和将链路跟踪数据上报到开源产品 Zipkin 做分布式链路跟踪展示的能力。这次参加开源之夏活动的任务是要把链路跟踪数据上报到 Jaeger 和 SkyWalking 中进行展示。\nSOFATracer 数据上报 上图是 SOFATracer 中的链路上报流程，Span#finish 是 span 生命周期的最后一个执行方法，这是整个数据上报的入口，SOFATracer 的 report span 方法中含有上报链路展示端和日志落盘两个部分。SOFATracer 中没有把上报数据采集器和日志落盘分开只是在日志落盘之前调用 SOFATracer#invokeReporListeners 方法，找到系统中所有实现了 SpanReportListener 接口并加入了 SpanReportListenersHolder 的实例，调用其 onSpanReport 方法完成链路数据上报至数据采集器。下面的代码片段是 invokeReportListeners 方法的具体实现。\nprotected void invokeReportListeners(SofaTracerSpan sofaTracerSpan) { List\u0026amp;lt;SpanReportListener\u0026amp;gt; listeners = SpanReportListenerHolder .getSpanReportListenersHolder(); if (listeners != null \u0026amp;amp;\u0026amp;amp; listeners.size() \u0026amp;gt; 0) { for (SpanReportListener listener : listeners) { listener.onSpanReport(sofaTracerSpan); } } } SpanReportListenerHolder 中的实例在项目启动的时候加入，且分为 Spring Boot 应用和 Spring 应用两种情况：\n 在 Spring Boot 应用中自动配置类 SOFATracerSpanRemoteReporter 会将当前所有 SpanReportListener 类型的 bean 实例保存到 SpanReportListenerHolder 的 List 对象中。SpanReportListener 的实例对象会在各自的 AutoConfiguration 自动配置类中注入到 IOC 容器中。\n 在 Spring 应用中通过实现 Spring 提供的 bean 生命周期接口 InitializingBean，在 afterPropertiesSet 方法中实例化 SpanReportListener 的实例对象并且加入到 SpanReportListenerHolder 中。\n 要实现把 SOFATracer 中的 trace 数据上传到 Jaeger 和 SkyWalking 需要实现 SpanReportListener 接口并在应用启动的时候把对应实例加入到 SpanReportListenersHolder 中。\nPART. 2 Jaeger 数据上报 下图是 Jaeger 中数据上报的部分图示，图中 CommandQueue 中存放的是刷新或添加指令，生产者是采样器和 flush 定时器，消费者是队列处理器。采样器判断一个 span 需要上报后向 CommandQueue 中添加一个 AppendCommand，flush 定时器根据设置的 flushInterval 不断向队列中添加 FlushCommand，队列处理器不断从 CommandQueue 中读取指令判断是 AppendCommand 还是 FlushCommand，如果刷新指令把当前 byteBuffer 中的数据发送到接受端，如果是添加指令把这个 span 添加到 byteBuffer 中暂存。\n在实现上报到 Jaeger 过程中主要工作是 Jaeger Span 和 SOFATracer Span 模型的转换，转换过后利用上面的逻辑发送 span 到后端。\n上图是 Jaeger 中 Sender 的 UML 图，从图中可以看到有两种类型的 Sender 分别是 HTTPSender 和 UDPSender 。分别对应用 HTTP 发送数据和 UDP 发送数据，在实现 SOFATracer 上报 Jaeger 中使用 UDPSender 发送 span 数据到 Jaeger Agent 中，使用 HTTPSender 直接发送数据到 Jaeger-Collector 中。\nJaeger Span 与 SOFATracer Span 模型的转换 模型转换对照 TraceId 和 SpanId 的处理 TraceId 的转换：\n 问题在 SOFATracer 中的 TracerId 的产生规则是：服务器 IP + ID 产生的时间 + 自增序列 + 当前进程号 例如 ：0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，您也可以根据这个规律来查找到请求经过的第一个服务器。后面的 13 位 1403169275002 是产生 TraceId 的时间。之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。——TraceId 和 SpanId 生成规则\n 在 SOFATracer 中 TraceId 是 String 类型，但是在 Jaeger 中 TraceId 是使用的两个 Long 型的整数来构成最终的 TraceId。\n解决方案 在 Jaeger …","date":1634626800,"description":"终于！SOFATracer 完成了它的链路可视化之旅","dir":"blog/sofatracer-completes-its-link-visualisation-journey/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"260c9a0bc64d5f84afc37ee442e347c6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","publishdate":"2021-10-19T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","summary":"📄 文｜赵陈（SOFA 开源之夏链路项目组) 武汉理工大学计算机工程硕士在读 研究方向：唐卡线稿的自动上色 校对｜宋国磊（SOFATracer commiter) 本文 6971","tags":["SOFAStack"],"title":"终于！SOFATracer 完成了它的链路可视化之旅","type":"blog","url":"/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","wordcount":4273},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@崔伟协 提问：\n 我们的项目基于 MOSN，请问这里 panic了，要怎么解决？\n https://github.com/mosn/mosn/blob/master/pkg/proxy/downstream.go#L393-L399\nA：有异常的时候可以直接返回一个异常的数据包，m.receiveHandler.SendHijackReply(api.SuccessCode, m.headers) 在 filter 里面可以直接返回一个包。\n「MOSN」：https://github.com/mosn/mosn\n@玄灭 提问：\n 请问 MOSN 有计划支持 eureka 注册中心吗？\n A：目前没有，欢迎 pr，有个 zk 的例子，实现起来也简单。\nhttps://www.github.com/mosn/mosn/tree/master/pkg%2Fupstream%2Fservicediscovery%2Fdubbod\n「MOSN」：https://github.com/mosn/mosn\n@张昊 提问：\n 仓库中 /jarslink-samples/spring-boot-transform-sample 对照文档启动后，telnet 中 install -b *ark-biz.jar，控制台报错，大家有遇到类似问题嘛？\n A：这个项目不维护了，相关功能已经 merge 到 SOFAArk 里面去了，以后建议直接用 SOFAArk。\nSOFAArk 有相关的适应样例：https://github.com/sofastack-guides\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n@春少 提问：\n 这一段逻辑，是为了避免在执行 add peer 的时候，出现 raft 选举的情况吗？ A：是的，所以这个时候就交给新的 leader 负责继续推进新的成员节点变更。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN : 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n-Easy\n为 Layotto 中的关键模块添加注释（例如限流/分布式锁等模块）\n添加 nodejs sdk\n-Medium\n用某种存储实现 File API 组件（例如本地文件系统、hdfs、ftp 等）\n升级由 rust 开发的 wasm demo\n升级由 AssemblyScript 开发的 wasm demo\n详见： https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n另外最近更新了社区晋升规则，大家贡献 pr 后只要满足条件即可晋升，成为社区的维护者之一。\n详见： https://mosn.io/layotto/#/zh/community/promote\n本周推荐阅读 蚂蚁集团技术风险代码化平台实践（MaaS）\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1634281200,"description":"SOFA Weekly | QA 整理、SOFAStack\u0026MOSN 新手任务","dir":"blog/sofa-weekly-20211015/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"498a7a535dc938be0783eab5c808d792","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211015/","publishdate":"2021-10-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211015/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly | QA 整理、SOFAStack\u0026MOSN 新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211015/","wordcount":1130},{"author":"吴成辉","categories":"SOFAStack","content":" 📄\n文｜吴成辉（花名：清霄 蚂蚁集团高级技术专家)\n校对｜陈真、庄晓丹、冯家纯\n本文 6250 字 阅读 11 分钟\n▼\n我们一起回顾下监控上层业务曾经面临的问题：\n 烟囱式的监控分析重复建设 在技术风险领域，一度有超过 5 个系统在做监控分析的能力建设，大致逻辑基本都是拉监控的 Raw Data，做基础的聚合、分析处理后（类似同环比、阈值类的方式），根据一些当前的场景输入，结合一些算法能力，得出一个结论并触发一系列的 Action。类似这种烟囱式的监控分析场景，都是比较初级的重复建设，缺乏智能化、体系化。\n SRE 经验标准化沉淀的问题 在分析场景里也面临 SRE 经验无法标准化沉淀复用的问题，什么是 SRE 经验？拿交易付款下跌来举例，如果当前交易付款下跌 10%，SRE 通常有这么几个分析路径，首先看下淘宝交易是否下跌（来源），再看交易创建，收银台渲染是不是下跌等，这一类我们称为业务依赖。从全局看是否有大规模的压测、变更等动作，这一类称为变更关联，以及如何根据当前故障情况决策进行切流、限流等恢复措施，我们称为分析后置操作。\n 长尾需求 比如比较常见的，算多数据之间的成功率，流量损耗等等需求，通过产品化解决的成本非常高，而且用户不能快速修改、定制相关能力。\n同时我们看到当前监控系统自身面临的问题：\n 监控的数据使用复杂 包含了几万张数据表、十几万张自定义数据表，数据类型超过 20+，以及跨站点、数据源异构等等问题。\n 监控服务不够开放 如何动态日志清洗计算、如何做分析后的时序存储、监控的时序检测能力如何复用等等。我们需要把监控的数据、能力完全服务化出来。\n 高效的可编程代码化平台缺失 没有一个高效平台帮助 SRE 先沉淀经验、再促进经验的标准化、复用，最后产品化。\n基于上面问题，我们提出了 MaaS 的设想（Monitoring as a Service), 监控能力服务化，开放、融合监控能力到技术风险各个领域，快速完成 SRE 场景建设，沉淀可复用能力，主要包含以下 4 个阶段目标：\n1.开放服务把监控的计算、存储、算法、视图等等能力开放出来。\n2.核心共建几个重点的技术风险领域场景，比如变更防御、压测引流、无损注入、定位应急等等。\n3.促进服务的标准化沉淀，让更多的场景可以复用、共同建设这部分的能力。\n4.解决“监”与“控”之间的链接问题。\n（我们的这里的 AIOPS 更多指的是\n一系列专家经验的集合、沉淀、持续维护优化）\nPART. 1 平台技术概览 能力服务化\n监控的服务化能力整体包含这么几部分，数据服务化、配置服务化、计算、存储服务化、算法服务化、通知、云原生服务化等等，也包括一些外部能力集成比如消息缓存等等。\n我简单举两个服务化的例子来介绍下什么是服务化：\n比如视图服务，当某个变更发起后，这个变更关联的 100 个应用指标、20 个业务指标中的 10 个指标出现了问题，这个时候，我们需要动态为这个 10 个指标创建一个数据视图，来分析业务影响范围，这个时候就会用到我们的视图服务。\n动态计算服务，比如我需要实时计算下某个应用在 A 机房（或某个 ZONE 如：GZXXX）的其中 5 台机器在 11:00~12:00 的接口方法调用情况，动态的计算服务就会派得上用场。\n数据服务化\n能力服务化中非常重要的一环就是数据服务化，因为数据是所有监控分析的基础，数据服务化主要分成两部分。\n 第一步是监控数据模型化 我们从数据的使用视角把数据抽象出数据虚拟表、虚拟表列定义、列关系。以及虚拟表的实现绑定，包含指标数据，也包含关系元数据，最后把这些物理实现映射到监控具体的数据指标或者底层的元数据服务上。\n 第二步是服务模板化 我们把一个数据服务抽象出三类：\n实体查询，比如查询一个应用或者一个 Tbase 的集群；\n数据查询，比如查询一个应用的 Sofa Service 在 APP 聚合维度上的数据；\n关系查询，查询一个实体的关联实体，比如 cif 关联的 Tbase 集群等。\n 最后，我们实现了 5w+ 数据服务自动生成，分钟级别 SDK 更新的能力，我们可以通过非常语义化的访问方式来访问监控的所有数据，我们可以做到只要是监控体系内的数据，都可以通过我们这套能力访问到对应的数据服务，从而达到整个监控数据的服务化开放。 研发效能\n 大库管理，我们设计了一种可以支持服务沉淀、权限隔离（可以独立按目录管理 CR）、逻辑复用的代码结构，比如缓存 Tbase 的研发 + SRE 可以共同在 cache 目录里面定义缓存问题的发现、分析、恢复。同时可以复用到 core-service 里面的比如容器是否健康，网络是否异常等标准服务。平台能够提供一致的多环境调试能力，方便监控分析逻辑可以直接运行在本地 IDE 环境中，我们通过动态代理的模式把本地访问的数据、函数服务代理到服务端，从而达到了本地跟线上完全一致的研发体验。这项能力极大地提高了研发效率，研发过程中可以直接 debug 线上数据，比传统的日志模式的调试方式有非常大的效率提升，一个基础的分析函数基本可以在小时级别内完成。\n 一站式发布运维，传统的 Serverless 发布模式大致要经历这么几个阶段，从工程打包到 Jar 文件，耗时 1min，大概在 100-300MB，从 Jar 文件打包 Build 出镜像，大致 10min，最后做镜像化发布整体耗时约 20min, 整体流程大概耗费半个小时。我们研发了一套基于函数粒度的发布运维模式，以 MaaSFunction 为入口，做跨文件 Linker，如何做 Linker，看这个示意图，我们从 MaasFunction 入口开始解析本类依赖的文件，比如这边依赖的其他函数，到下面的 service，再到 util 层的相互依赖，从而通过这种方式解析出业务代码片段，通过动态编译完 Jar 大小目前最大在 500KB 左右，根据代码大小一般在 5s 内，再通过热加载到目标机器上，整体可以做到 5s 级发布，1s 回滚，其他还有配套的日志、监控等等能力。\n 多语言 Runtime\n我们在初期建设的时候函数是都运行在一个集群里面，经常会遇到例如：死循环、OOM、线程频繁创建等等性能问题，因为业务代码不可控，CR 不能完全杜绝这类问题，这样我们就需要完全隔离的函数运行环境，从图中可以看到，每个函数至少具备 2 个独立的容器（容灾的需要），函数 1OOM（Out Of Memory），不会影响到函数 2。这样我们就可以基本做到函数级别的执行层隔离，我们通过 SLO 的度量，平台稳定性有了非常大的提升。\n当我们按照函数级别隔离的模式大规模上线的时候遇到了成本问题，底层 sigma 支持的 pod 调度的最小规模是 0.5c（底层物理网卡等等限制），如果 2 台容灾，基本上一个函数至少占用 1c 的物理资源，随着函数业务的大规模使用，这块成本是很难持续的。通过我们的观察，绝大多数函数占用实际的 CPU10% 不到，甚至更低。我们同 Serverless Paas 团队一起共建了函数的高密度部署模式，通过 0.5c 的 pod 中隔离 5 个 0.1c 的容器，然后通过容器 IP + 端口的方式绑定 …","date":1634022000,"description":"蚂蚁集团技术风险代码化平台实践（MaaS）","dir":"blog/ant-group-technical-risk-coding-platform-in-practice-maas/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"87ede64d8d98af4c1bf7bf4d51ee9cdf","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","publishdate":"2021-10-12T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","summary":"📄 文｜吴成辉（花名：清霄 蚂蚁集团高级技术专家) 校对｜陈真、庄晓丹、冯家纯 本文 6250 字 阅读 11 分钟 ▼ 我们一起回顾下监控上层业务曾经面临的问题： 烟囱式","tags":["SOFAStack"],"title":"蚂蚁集团技术风险代码化平台实践（MaaS）","type":"blog","url":"/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","wordcount":5838},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@风 提问：\n 麻烦问下 SOFA 中的 consumerConfig 的 uniqueId 和 application 分别起什么作用，有什么区别呀？\n A：发布 RPC 服务的时候做配置，uniqueId 是服务的唯一标识，比如你想同一个 service 类发两个服务，就起两个 uniqueId。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@郑楚齐 提问：\n 我在 K8s 上测试将使用 spring-cloud-feign 的服务接入 MOSN Proxy，但是目前 consumer 端一直访问不到 provider，我还在排查问题，想问一下，如果要调用的话，FeignClient 这边是不是需要直接将 URL 指向代理？ A：不是透明劫持的话，就要直接指向 Proxy 的端口。\n「MOSN」：https://github.com/mosn/mosn\n@东仔 提问：\n MOSN 在 Linux 上的 idea 如何启动？\n A：参考下图，\n 「MOSN」：https://github.com/mosn/mosn\n@王逸飞 提问：\n A -\u0026amp;gt; B, A 没有问题，执行到 B 的更新操作时候， Could not found global transaction xid = 192.168.0.112:8091:1893025023560908，会是什么原因产生的？\n A：debug 到 b 的时候看下 TC 的 global table 里面数据存不存在。可能是服务重试或者网络超时造成，自己看下 tm 的决议是什么?\n java.time.LocalDateTime 序列化失败，这样的情况一般如何解决呢? A：改数据库类型，mkyro + datatime 改为时间戳类型，或者等 1.5。\n「Seata」：https://github.com/seata/seata\n本周发布 Layotto 发布了0.2.0 版本，包括以下功能：\n 支持 File API\n 支持 Binding API\n Tracing 和 metrics\n 为已有 API 添加更多组件\n 修复安全问题以及减少 panic 风险\n 不同组件之间保证数据隔离、代码复用\n WASM 模块支持热加载\n go sdk 添加更多 feature\n 一个简单的 Java sdk\n 添加更多文档、修复文档错误\n 添加社区治理和晋升规则\n 详细参考：\nhttps://github.com/mosn/layotto/releases/tag/v0.2.0\n本周推荐阅读 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁智能监控\n ","date":1633676400,"description":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、Layotto 发布新版本","dir":"blog/sofa-weekly-20211008/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b71750e53df5357dc922e1a7d952c265","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211008/","publishdate":"2021-10-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211008/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、Layotto 发布新版本","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211008/","wordcount":1050},{"author":"金敏、邱见","categories":"SOFAStack","content":" 文｜金敏（蚂蚁集团技术专家)\\邱见（Red Hat)\n校对｜ 冯泳（蚂蚁集团资深技术专家)\n本文 3311 字 阅读 6 分钟\n从最初 Kubernetes 技术问世，业界一遍一遍的质疑它能否能经得住生产级的考验，到今天许多大型企业已经采用 Kubernetes 技术“云化”之前大规模的基础设施，在企业内部创建了数十个甚至数百个集群。\nKubernetes 原生的管理能力目前仍然停留在单集群级别。每一个集群可以稳定地自治运行，但是却缺乏横贯多个集群的统筹管理能力。基础设施的建立者需要协调分散在各处的管理组件，形成一个统一的管理平台。\n通过它，运维管理人员能够获知多集群水位的变化，节点健康状态的震荡等信息；业务应用负责人能够决策如何调配应用服务在各个集群中的部署分布；应用的运维人员能够获知服务状态，下发腾挪的策略。\n与多集群相关的创新正在不断涌现。例如 ClusterAPI 和 Submariner 就是处理特定多集群管理问题比较成功的项目。\n而本文要讨论的是那些试图解决企业在面对多集群管理时遇到的所有问题的技术探索。\n在过去五年中，中国的技术公司蚂蚁集团在多集群管理的思考、使用和实施等方面学习到了很多宝贵的经验。\n蚂蚁集团管理着遍布全球的数十个 Kubernetes 集群，每个集群平均拥有数千个节点（服务器）。他们将应用程序及其所需组件（包括中间件，数据库，负载均衡等等）在架构层面组织成逻辑数据中心（LDC）的弹性逻辑单元中，并将它们规划部署到物理基础设施上。这种架构设计帮助他们实现基础设施运维的两个关键目标：高可用性和事务性。\n 首先，部署在某个 LDC 上的业务应用的可用性在所属 LDC 内能够得到保障。\n 其次，部署在 LDC 内的应用组件可以被验证，并在故障发生时，可以被回滚。\n 蚂蚁集团 PaaS 团队的资深技术专家冯泳表示：\n “蚂蚁集团拥有数十个 Kubernetes 集群、数十万个节点和数千个关键应用的基础设施。在这样的云原生基础设施中，每天都会有数以万计的 Pod 被创建和删除。构建一个高度可用、可扩展且安全的平台来管理这些集群和应用程序是一项挑战。”\n PART. 1 始于 KubeFed 在 Kubernetes 项目生态中，多集群功能主要由与之同名的 SIG-Multicluster 团队处理。这个团队在 2017 年开发了一个集群联邦技术叫做 KubeFed。\n联邦最初被认为是 Kubernetes 的一个内置特性，但很快就遇到了实现以及用户诉求分裂的问题，Federation v1 可以将服务分发到多个 Kubernetes 集群，但不能处理其他类型的对象，也不能真正的以任何方式“管理”集群。一些有相当专业需求的用户——尤其是几个学术实验室——仍在使用它，但该项目已被 Kubernetes 归档，从未成为核心功能。\n然后，Federation v1 很快被一种名为“ KubeFed v2 ”的重构设计所取代，世界各地的运营人员都在使用该设计。它允许单个 Kubernetes 集群将多种对象部署到多个其他 Kubernetes 集群。KubeFed v2 还允许“控制平面”主集群管理其他集群，包括它们的大量资源和策略。这是蚂蚁集团多集群管理平台的第一代方案。\n蚂蚁集团使用多集群联邦的首要任务之一是资源弹性，不止包括节点级别弹性也包括站点级别弹性。通过在需要时添加节点和整个集群起到提高效率和扩展系统的能力。例如年度性的资源弹性，每年 11 月 11 日是中国一年一度的光棍节，蚂蚁集团通常需要快速部署大量额外容量来支持高峰在线购物工作负载。然而，可惜的是正如他们发现的那样 KubeFed 添加新集群的速度很慢，而且在管理大量集群方面效率低下。\n在 KubeFed v2 集群中，一个中枢 Kubernetes 集群会充当所有其他集群的单一“控制平面”。蚂蚁集团发现，在管理托管集群和托管集群中应用程序的时候，中枢集群的资源使用率都非常高。\n在管理仅占蚂蚁集团总量 3% 的应用程序工作负载的测试中，他们发现由中等规模的云实例构成的中枢集群就已经饱和了，并且响应时间很差。因此，他们从未在 KubeFed 上运行全部工作负载。\n第二个限制与 Kubernetes 的扩展功能有关，称为自定义资源定义或 CRD。类似蚂蚁集团这样的“高级用户”往往会开发众多的自定义资源来扩充管理能力。为了要在多集群间分发 CRD，KubeFed 要求为每个 CRD 都创建一个“联合 CRD”。这不仅使集群中的对象数量增加了一倍，也为在集群间维护 CRD 版本和 API 版本一致性方面带来了严重的问题，并且会造成应用程序因为不能兼容不同的 DRD 或者 API 版本而无法顺利升级。\nCRD 的这种数量激增也导致了严重的故障排除问题，同时 CRD 的使用定义不规范/字段变更随意等坏习惯会使 KubeFed 控制面的鲁棒性雪上加霜。在本地集群有自定义资源的地方，联邦控制平面上也有一个代表该本地集群资源的图形聚合视图。但是如果本地集群出现问题，很难从联邦控制平面开始知道问题出在哪里。本地集群上的操作日志和资源事件在联邦级别也是不可见的。\nPART. 2 转向 Open Cluster Management Open Cluster Management 项目（OCM）是由 IBM 最初研发，并由红帽在去年开源。OCM 在蚂蚁集团和其他合作伙伴的经验基础上，改进了多集群管理的方法。它将管理开销从中枢集群下放到每个被管理集群上的代理（Agent）上，让它在整个基础设施中分布式自治并维护稳定。这使得 OCM 理论上能管理的集群数量至少比 KubeFed 多一个数量级。到目前为止，用户已经测试了同时管理多达 1000 个集群。\nOCM 还能够利用 Kubernetes 本身的发展来提高自身的能力。例如，那些以 CRD 封装的能力扩展可以使用 OCM 的 WorkAPI（一个正在向 SIG-Multicluster 提议的子项目）在集群之间分发 Kubernetes 对象。WorkAPI 将本地 Kubernetes 资源的子集嵌入其中，作为要部署的对象的定义，并将其留给代理进行部署。此模型更加灵活，并且最大限度地减少了对任何中央控制平面的部署需求。WorkAPI 可以一起定义一个资源的多个版本，支持应用程序的升级路径。同时 WorkAPI 兼顾了中枢集群和被管理集群网络链接故障时的状态保持问题，并可以在重连的情况下保障资源状态的最终一致性。\n最重要的是，OCM 在集群部署中实现了更多的自动化。在 KubeFed 中，集群的纳管是一个“双向握手”的过程，以中枢集群和被管理集群之间“零信任”作为基础，在此过程中涉及许多手动步骤来保障安全性。新平台能够简化这一过程。例如，因为它在 “PULL” 的基础上运行，不再需要多阶段手动证书注册，也不需要任何明文的 KubeConfig 证书的流通，就可以做到让被管理集群获取中枢集群的管理命令。\n尽管注册的流程注重双向的“信任性”，但是在 OCM 中添加新集群只需要很少的操作；工作人员可以简单地在目标 Kubernetes 集群上部署 “Klusterlet” 代理实现自动纳 …","date":1633330800,"description":"下一个 Kubernetes 前沿：多集群管理","dir":"blog/next-kubernetes-frontier-multi-cluster-management/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7120f96fca72cfca3c6fbfd9ab9e3172","permalink":"https://sofastack.github.io/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","publishdate":"2021-10-04T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","summary":"文｜金敏（蚂蚁集团技术专家)\\邱见（Red Hat) 校对｜ 冯泳（蚂蚁集团资深技术专家) 本文 3311 字 阅读 6 分钟 从最初 Kubernetes 技术问世，业界一遍一遍的质疑它能否能","tags":["SOFAStack"],"title":"下一个 Kubernetes 前沿：多集群管理","type":"blog","url":"/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","wordcount":2933},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周新晋 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@郑楚齐 提问：\n 我们在 Istio 环境下，因为 MOSN 是自动 sidecar 注入的，我怎么控制他读取我的配置文件内容呢？而且我看官方的 Istio 案例也是可以通过 virsual service 进行流量控制的，我们这个 config.json 也是可以进行流量控制的，是不是我理解的 config.json 是在 virsualService.yaml 的功能上进行拓展的功能(比如这种 tag 路由是 virsualService 不能控制的)。\n A：Istio 场景下对应的 sidecar 的静态配置是一些通用的模板（如 pilot 地址渲染等）。关于 service 相关的路由及治理控制都是通过 Istio 定义的 CRD 控制：\nhttps://istio.io/latest/docs/reference/config/networking/\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n MOSN 执行的这个 config.json 是如何使用呢？因为目前 Istio 的这个配置 DestinationRule VirsualService 是不满足需求的，或者说 MOSN 收到我们订制的DestinationRule VirsualService，会自动转为 config.json 供给 MOSN 使用呢？\n A：cluster subset 配置目前 Istio 的 Destination Rule 还不支持，不过目前是可以通过 Envoy Filter 来给对应的 cluster 打 patch 实现（比较麻烦点）。\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n 如果是在 Envoy Filter 打 patch 的话，有没有什么例子吗?\n A：这个就是上面说的 cluster subset 配置。目前 Istio 的 Destination Rule 里面还不支持这个（详细见上面的那个讨论 issue），目前唯一的方法就是使用 Envoy Filter 的这个 CRD 打 patch 实现。\n可参考文档：https://istio.io/latest/docs/reference/config/networking/envoy-filter/#EnvoyFilter-ClusterMatch\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n 看了官方的 EnvoyFilter，不过感觉跟我们 MOSN 的 config.json 里面的内容想对照匹配起来确实很难。\n A：你可以用 xds 动态更新或者扩展用我们的 API 更新，不需要直接用这个配置文件。直接调用 MOSN 自己的 API，xds 其实也是 adapt 到这些 API 接口的，如果你们不用 Istio 的话，自己封装可能更简单，主要就 route 和 cluster 两个 API 就行了。\n这是一个用 zk 更新 Dubbo 的例子：\nhttps://github.com/mosn/mosn/blob/38b3b922b59500acc082e0ac9d705e41944c94ee/pkg/upstream/servicediscovery/dubbod/common.go#L99\nMOSN：https://github.com/mosn/mosn\n@孤若 提问：\n 当空回滚时，如果是因为远程方法调用 try 响应超时，怎么解决终止 try 执行？比如 rollback 执行远比 try 阶段快，rollback 结束 try 还在执行。\n A：我之前有参考这个，有提到 TCC 异常控制：\nhttps://www.infoq.cn/article/g33hcc-qosjplkt4e64e\nSeata：https://github.com/seata/seata\n@林祥标 提问：\n Seata 1.3.0 jdk 1.8 使用 jackson 对 localDateTime 进行序列化时报错，有大佬知道怎么解决吗？\n A：如果数据库用 datetime，实体又是 localdatetime，目前我发现只能 spi、替换序列化方式、依赖等等都没用。通过 spi 定义三个序列化方式就行了：LocalDate、LocalDateTime、LocalTime\u0026amp;hellip;反正如果数据库不是时间戳，目前给的适配方式是无用的(个人用下来的结果)。\nSeata：https://github.com/seata/seata\nSOFAStack：新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nEasy\n为 Layotto 中的关键模块添加注释（例如限流/分布式锁等模块）、添加 nodejs sdk。\nMedium\n用某种存储实现 File API 组件（例如本地文件系统、minio、hdfs、ftp 等）。\n「详见」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁智能监控\n 2021 年云原生技术发展现状及未来趋势\n ","date":1633071600,"description":"SOFA Weekly | Layotto 本周新晋 Contributor、QA 整理、新手任务）","dir":"blog/sofa-weekly-20211001/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8a010b34f9a0dbd849f07463c4b6c9b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211001/","publishdate":"2021-10-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211001/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto 本周新晋 Contributor、QA 整理、新手任务）","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211001/","wordcount":1710},{"author":"唐博、谭崇康","categories":"SOFAStack","content":" 文｜唐博（花名：博易 蚂蚁集团技术专家)\n谭崇康（花名：见云 蚂蚁集团高级技术家)\n本文 10316 字 阅读 18 分钟\n▼\n蚂蚁集团运行着全球最大的 Kubernetes（内部称为 Sigma) 集群之一。Kubernetes 社区官方以 5K node 作为 Kubernetes 规模化的事实标准，而蚂蚁集团在 2019 年的时候，就已经维护着单集群规模超过 1W node 的 Kubernetes 集群。\n这不仅仅是单集群节点量级上的差异，更是业务规模的差异，业务多样化和复杂度上的差异。\n一个形象化的比喻就是，如果官方以及跟着官方的 Kubernetes 使用者能想象到的 Kubernetes 的集群规模是泰山，那么蚂蚁集团在官方的解决方案之上已经实现了一个珠穆朗玛峰。\n蚂蚁集团的 Kubernetes 的演进，从 2018 年至今已经走过了 3 年多的岁月，虽然在 2019 年的时候就构建了万台集群的规模，但时至今日，无论是业务形态还是集群的服务器都发生了巨大的变化。\n 首先，当时的集群万台节点，主要还是偏小规格的服务器，而如今都是大机型，虽然机器的数量也是万台，实际管理的 CPU 数量已经成倍增长。\n 其次是当时集群里面几乎全量是 Long running 的在线业务，Pod 的创建频率每天只有几千个，如今我们的集群上几乎跑满了流式计算和离线计算业务等按需分配的 Pod，因此在 Pod 数量上成倍增长，实际管理的 Pod 数量超过了百万。\n 最后，是 Serverless 的业务快速发展，Serverless Pod 的生命周期基本在分钟级甚至是秒级，集群每天的 Pod 创建量也超过了几十万，伴随着大量的 Kubernetes list watch 和 CRUD 请求，集群的 apiserver 承受了数倍于以往的压力。\n 因此在业务 Serverless 的大背景下，我们在蚂蚁启动了大规模 Sigma 集群的性能优化方案，根据业务的增长趋势，我们设定的目标是，构建 1.4W 个节点规模的集群，同时通过技术优化，期望达成在请求延迟上不会因为规模的原因有所下降，能够对齐社区标准，即 create/update/delete 请求的天级别 P99 RT 在 1s 之内。\n可想而知，挑战是非常巨大的。\nPART. 1 大规模集群的挑战 毋庸置疑，大规模集群带来了很多挑战：\n 随着集群规模增大，故障的爆炸半径也将扩大。Sigma 集群承载了蚂蚁集团诸多重要应用，保障集群的稳定和业务的稳定是最基础也是优先级最高的要求。\n 用户大量的 list 操作，包括 list all，list by namespace，list by label 等，均会随着集群的规模增大而开销变大。这些合理或者不合理的 list 请求，将让 apiserver 的内存在短时间内快速增长，出现 OOM 异常，无法对外响应请求。此外，业务方的 list 请求也会因为 apiserver 无法处理请求而不断重试，造成 apiserver 重启后因过载不可恢复服务能力，影响整个集群的可用性。\n 大量 List 请求透过 apiserver 直接访问 etcd 服务，也会让 etcd 实例的内存剧增而出现 OOM 异常。\n 随着业务量的增长，特别是离线任务的增多，create/update/delete 等请求的数量也迅速增加，导致客户端请求 apiserver 的 RT 极速上升，进而使得调度器和一些控制器因为选主请求超时而丢主。\n 业务量增长将加剧 etcd 由于 compact 等操作自身存在的性能问题，而使 etcd 的 P99 RT 暴涨，进而导致 apiserver 无法响应请求。\n 集群中的控制器服务，包括 Kubernetes 社区自带的控制器例如 service controller，cronjob controller 以及业务的 operator 等，自身存在的性能问题都将在大规模集群面前被进一步放大。这些问题将进一步传导到线上业务，导致业务受损。\n 如计算机学科的古老格言所说：\n「 All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection\u0026amp;hellip; and the performance problems. 」\n大规模集群既是照妖镜，也是试金石。\nPART. 2 大规模集群的收益 诚然，构建一个大规模的 Kubernetes 集群也提供了诸多收益：\n 为运行大型服务提供更为便利的基础设施 ，便于应对业务扩容时大幅飙升的资源需求。例如在双十一等电商大促活动期间，可以通过扩展现有集群而不是新建其它小集群来应对业务的增长。同时集群管理者可以管理更少的集群，并且以此来简化基础架构管理 。\n 为大数据和机器学习的离线计算任务提供更多的资源，为分时复用/分时调度等调度手段提供更大的施展空间，让离线的计算任务在在线业务的低峰期时可以使用更多的资源进行计算，享受极致弹性和极速交付。\n 还有非常重要的一点，在更大的集群中可以通过更加丰富的编排调度手段来更为有效地提升集群整体的资源利用率。\n PART. 3 SigmaApiServer性能优化 Sigma apiserver 组件是 Kubernetes 集群的所有外部请求访问入口，以及 Kubernetes 集群内部所有组件的协作枢纽。apiserver 具备了以下几方面的功能:\n 屏蔽后端数据持久化组件 etcd 的存储细节，并且引入了数据缓存，在此基础上对于数据提供了更多种类的访问机制。\n 通过提供标准 API，使外部访问客户端可以对集群中的资源进行 CRUD 操作。\n 提供了 list-watch 原语，使客户端可以实时获取到资源中资源的状态。\n 我们对于 apiserver 性能提升来说可以从两个层面进行拆解，分别是 apiserver 的启动阶段和 apiserver 的运行阶段。\napiserver 启动阶段 的性能优化有助于：\n 减少升级变更影响时长/故障恢复时长，减少用户可感知的不可用时间，给 Sigma 终端用户提供优质的服务体验（面向业务的整体目标是 Sigma 月度可用性 SLO 达到 99.9%，单次故障不可用时间 \u0026amp;lt; 10min）。\n 减少因为发布时客户端重新 list 全量资源而导致的 apiserver 压力过大情况出现。\n apiserver 运行阶段 的性能优化的意义在于：\n 稳定支持更大规模的 Kubernetes 集群。\n 提高 apiserver 在正常平稳运行的状态中，单位资源的服务能力；即提高可以承受的请求并发和 qps， 降低请求 RT。\n 减少客户端的超时以及超时导致的各种问题；在现有资源下提供更多的流量接入能力；\n 整体优化思路\n构建一个大规模的 Kubernetes 集群以及性能优化不是一件容易的事，如 Google Kubernetes Engine K8s 规模化文章所 …","date":1632812400,"description":"攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践","dir":"blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b6cc47242239f350d5aca9717037f061","permalink":"https://sofastack.github.io/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","publishdate":"2021-09-28T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","summary":"文｜唐博（花名：博易 蚂蚁集团技术专家) 谭崇康（花名：见云 蚂蚁集团高级技术家) 本文 10316 字 阅读 18 分钟 ▼ 蚂蚁集团运行着全球最大的 Kubernetes","tags":["SOFAStack"],"title":"攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践","type":"blog","url":"/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","wordcount":7129},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@证道者 提问：\n MOSN 怎么将 HTTP 转到 Dubbo 的数据,怎么实现新的协议？\n A：这个你要写个 filter ，因为每个 HTTP 字段怎么对应 Dubbo 的字段，是没有固定标准的。\nA：「HTTP 转 SOFA 的例子」 https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ftranscoder%2Fhttp2bolt\nA：这个需要 client 满足这个字段对应规范，所以一般就自己实现了。\n 公司很多这种 RPC 的接口，每一个接口都要写一下 filter 吗？没有通用的转换吗？\n A：一个协议就一个吧，比如 HTTP 的 header：service 对应 Dubbo 的 service。你也可以用其他的 HTTP header 来对应，比如用 dubbo-service，所以没有一个标准，就需要自己简单做个对应关系。\nMOSN：https://github.com/mosn/mosn\n@王夕 提问：\n 咨询一个问题，TCC 的嵌套子事务，如果发生重试的话，如下图中的 2、6，会产生不同的 branch 记录吗？ A：有可能,要么关了重试,要么做幂等\n 也就是说根据 xid 做幂等，而不要根据 branchid 做幂等对吗？\n A：branchid 进来一次就变一次,肯定不行,该分支同入参同 xid 一般就可以作为幂等的校验条件。\nSeata：https://github.com/seata/seata\n@江培泉 提问：\n 请教下，oracle 用户没获取到行信息，导致 undo_log 无法插入，也无法回滚。 主键字段类型和 JAVA 的类型： A：主键的 Long 改成 BigDecimal，Oracle 的 number 长度超过 19 之后，用 Long 的话，setObject 会查不出数据来。\nSeata：https://github.com/seata/seata\n本周推荐阅读 SOFAJRaft 在同程旅游中的实践\n 技术风口上的限流\n 蚂蚁智能监控\n 2021 年云原生技术发展现状及未来趋势\n ","date":1632466800,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210924/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"88a73b7a463bc79a5bcb81ae4e0a4fee","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210924/","publishdate":"2021-09-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210924/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210924/","wordcount":903},{"author":"赵延","categories":"SOFAStack","content":"文｜赵延（SOFAJRaft Committer)\n校对｜冯家纯（SOFAJRaft Committer)\n本文 15717 字 阅读 23 分钟\n▼\n同程艺龙作为对 Raft 研究较早的公司，早在 14 年算法的 paper 刚发布的时候，便已经对其进行了调研。同时也与 paxos 、zab 等算法进行了详细的对比，并在公司内部的计数器、任务调度元信息存储等场景进行试点。\n不过早期对于 Raft 的尝试较多的是在 C++ 技术栈试水，在 Java 技术栈里却很少有涉及。\n近期刚好有基于 etcd 的老项目由于需要自定义的数据结构需要重构，原有的 etcd 无法在底层数据结构层面满足需求，因此决定采用 Java 技术栈结合开源项目 SOFAJRaft 进行底层数据存储的开发，以期解决多节点数据强一致的问题。\n本文假设读者对 Raft 及强一致的概念已经有了较深的理解，详细介绍了公司内部如何使用 *JRaft* 的进行老系统的改造以及使用过程中遇到的工程问题，希望其他对 Raft 有兴趣的同学可以一起讨论。\nPART. 1\n背 景\n公司内部原本存在一个系统 mdb (metadata database)，go 语言编写，用于管理所有的实例元数据信息，元数据的内容就是一个 map。\n该组件提供对元数据增删改查的接口，并且使用 go 语言编写，在检索数据时引入了 K8s selector 的包，使用 K8s selector 的解析规则筛选特定标签的元数据信息。\n数据持久化则是实用了强一致组件 etcd 进行存储，key 为元数据的 ID，保证唯一，value 为具体的元信息，包含各个标签以及对应的值。\n该系统大体架构如图 -1 所示:\n 图-1：原来的架构\n「该架构的弊端」\n 每隔一段时间需要去拉取 etcd 的全量数据，担心单次请求数据量太大的情况，对数据 ID 进行了 hash 分片，依次获取每个分片下个 key，再通过 key 去获取 value，导致 etcd 的查询频率非常高。\n 非 ID 查询条件的一致性查询，和上面的问题一样，也需要做拉取全量数据的操作。\n 更新删除操作也是一样，需要拉取全量数据再操作。\n 分析以上问题可以发现，使用 etcd 作为强一致存储，但 etcd 是基于 KV 存储的组件，并且解析组件 mdb 和 etcd 是分离的，在需要保证数据最新的情况下，必须得去 etcd 拿最新的数据到本地再进行操作。\n而 etcd 基于 KV，就得拿到 etcd 的全量数据都给拉到本地后再做操作。\n如果有一个组件，提供强一致的存储能力，又能直接去解析 K8s selector 的规则，存储的数据结构和元数据信息更加亲和，那么中间的那一层 mdb 就可以直接去掉了，由这个组件来解析对应的 crud 规则，将解析过后的规则直接在本地查询，那么以上问题就能够直接解决了。\nPART. 2\n改 造\n基于以上问题，我们准备自己开发一个强一致存储的组件，能够自己解析 K8s selector 的规则，并且将数据保存在自己本地。\n因为个人对 Java 语言比较了解，并且之前使用 Nacos 时，对 SOFAJRaft 也有一定了解，最终选择了 SOFAJRaft 来构建强一致存储组件，将它命名为 mdb-store。\n主要改造点：\n 使用 SOFAJRaft 编程模型构建业务状态机，业务状态机中根据 Raft log 中的 data 类型，进行 crud 的操作。\n mdb-store 提供与原来 mdb 相同的 api，让改造对用户透明，改造完成后只需要切换域名对应的实例即可。\n 迁移 K8s selector 的解析逻辑，这里用 Java 写了一套和 go 版本 K8s selector 一样解析逻辑的组件 K8s-selector-Java。\n 改造过后的架构如图-2所示:\n 图-2：重构后的架构\n通过改造过后，将 mdb 移除，让用户直接和 mdb-store 进行通信，中间的通信少了一跳，加快了访问效率。将 mdb 和 etcd 也进行了移除，减少了整个系统的组件，降低运维成本。\nPART. 3\nSOFAJRaft 的具体使用\n将写操作转换成 Raft log\n在 SOFAJRaft 中，编程模型和通常的 Spring MVC 的编程模式不太一样。\n在 Spring MVC 中，一个请求到达了后端，通常会通过 Controller -\u0026amp;gt; Service -\u0026amp;gt; Processor 这么几层。Controller 负责本次 http 请求的资源映射， 再由 Controller 去调用特定的 Service 方法，在 Service 层中，对参数进行一些处理和转换，再交由 Processor 层去对请求做真正的处理。\n大体逻辑如图 -3 所示，\n 图-3：通常的编程模型\n在 SOFAJRaft 中，所有的写操作都要通过状态机去执行（读操作不需要经过状态机）。需要将写操作转换成 task，状态机去应用 task 然后再进行业务处理。\ntask 中包含两个属性是需要关注的，一个是 done，一个是 data。\n- done 就是本次 task 被状态机处理完成后的回调，比如在 done 的回调逻辑中，将 response flush 到客户端。\n- data 就是 Raft log 中的具体数据，比如要执行一条插入元数据的命令。data 就会包含本次操作的类型（插入），以及本次操作的具体数据。\nprivate ByteBuffer data = LogEntry.EMPTY_DATA; private Closure done; /// 省略部分代码 } 大体逻辑如图 -4 所示，\n 图-4：SOFAJRaft 的编程模型\n所有的操作都抽象成一个实体 Operation，在 Service 层，就根据业务把参数转换成不同的 Operation，然后再将 Operation 序列化，设置到 Task 中的 data 属性，再由 Node 将 task 提交。\n这里可以将 task 看成是一个 Raft log，一旦 Raft log 被半数的机器给提交。状态机就会应用 Raft log，应用完成之后就会触发 done 中的回调。\n· 抽象过后的实体类\n//操作类型，比如增删改查 int type; //操作的哪个表，某些类型不需要此字段 String table; //具体的操作数据，根据 type 的不同，数据类型也会不同 T params;} · 构建 task 并通过 node 提交给状态机\n//定义回调的逻辑，当该 Raft log 被状态机应用后，会进行回调 task.setDone(new StoreClosure(operation, status -\u0026amp;gt; { StoreStatus storageStatus = (StoreStatus) status; closure.setThrowable(storageStatus.getThrowable()); …","date":1632207600,"description":"SOFAJRaft 在同程旅游中的实践","dir":"blog/sofajraft-in-practice-in-the-same-tour/","fuzzywordcount":7500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7c319b747ce3bc0df7adbd820d690ed3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","publishdate":"2021-09-21T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","summary":"文｜赵延（SOFAJRaft Committer) 校对｜冯家纯（SOFAJRaft Committer) 本文 15717 字 阅读 23 分钟 ▼ 同程艺龙作为对 Raft 研究较早的公司，早在 14 年算法的 paper 刚发布的","tags":["SOFAStack"],"title":"SOFAJRaft 在同程旅游中的实践","type":"blog","url":"/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","wordcount":7461},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@证道者 提问：\n 今天看了文章，好像蚂蚁 MOSN 结合 envoy，性能更好，不知道有没有开源这个？\n A：有开源，有个镜像可以玩。\nhttps://mp.weixin.qq.com/s/ioewVcwiB5QA8w3A3gaikg，\n今年 GopherChina 的文字版, 可以了解下。我们内部已经落地，线上跑飞起来了，适合不同的场景了。目前我们用在南北和网关，比较大规模的场景。这个目前也在跟 envoy 官方共建合作，还有场景就是本来就是 envoy 的用户，也可以更简单的写扩展。\n2、@朱仕智 提问：\n 请问这个限流在开源版本 MOSN 里面吗？\n A：在开源，内部的做了一些业务相关的扩展。\n3、@Glennxu 提问：\n请问下现在统一限流中心能使用么？\n A：现在开源版本还用不了集群限流，自适应限流的实现也和我们的有一些差异,后面我们会考虑移植到开源版本的。\n4、@朱仕智 提问：\n 今天正好在看 kratos 里面限流的文章，那个限流就是自适应限流，这里提到统一限流中心，这个哪里能看到？\n A：这个短期我们估计不会开源的，主要是这部分功能本身比较简单，而我们内部的规则和开源的模型也有所不同，加上现在我们跟自己的基础设施绑定了，不太方便直接开源。\n5、@魏小亮 提问：\n 是不是简单理解为 MOSN 作为 cpp 的动态库，作为一个插件给 envoy 调用？\n A：可以这么简单认为，对于一般用户的话就是用关心 MOSN 就行了，写 MOSN 的 filter，不需要了解底层机制。就像大家用 openresty，也很少去关心 nginx 和 luajit。\n 我以为要实现一个 envoy 的 filter 需要 c++ 代码来实现。\n A：其实 lua 也可以， 比如用 go 你可以启动一个 zk，然后去调用 envoy 的 xds 做服务发现可以做的事情就很多了。\n6、@茄子 提问：\n请教一下，在使用 rheakv 的过程中出现这个问题要怎么排查?\n A：可以看下 bolt 怎么设置写入的高低水位线，这应该是触发了 netty 的 channel 写入水位线。\ncom.alipay.remoting.config.BoltGenericOption#NETTY_BUFFER_HIGH_WATER_MARK com.alipay.remoting.config.BoltGenericOption#NETTY_BUFFER_LOW_WATER_MARK\n刚才找了下，你看些这个类的 options。\n com.alipay.sofa.jraft.rpc.impl.BoltRaftRpcFactory#CHANNEL_WRITE_BUF_LOW_WATER_MARK com.alipay.sofa.jraft.rpc.impl.BoltRaftRpcFactory#CHANNEL_WRITE_BUF_HIGH_WATER_MARK\njraft 也开放了设置。\n本周发布 SOFABoot 开源发布 3.9.0 版本，\\主要更新如下\\：\n SOFABoot 异常日志添加错误码；\n 去除 AbstractContractDefinitionParser 对 Autowire 注解的使用；\n 为 RPC 服务提供方添加开关，可以不注册到服务注册容器中；\n 添加健康检查进度；\n 去除 SOFARuntimeManager 对 Value 注解的使用；\n 优化 Spring 上下文并行启动的线程池配置。\n 详细参考：\nhttps://github.com/sofastack/sofa-boot/releases/tag/v3.9.0\n**SOFARPC 发布 v5.7.10 版本代码，主要更新如下：\n SOFARPC 支持接口中静态方法的使用；\n 使用 TransmittableThreadLocal 解决 RpcInternalContext 中 ThreadLocal 值传递问题；\n 优化超时时间的获取与校；\n 反序列化过程中正确感知 header 变化；\n 修复 RpcInvokeContext 中线程安全问题；\n 修复 ProviderInfo中getAttr 类型转换问题。\n 详细参考：\nhttps://github.com/sofastack/sofa-rpc/releases/tag/v5.7.10\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1631862000,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210917/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"83215c365789c806399a2ca00fc114e9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210917/","publishdate":"2021-09-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210917/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210917/","wordcount":1344},{"author":"张稀虹","categories":"SOFAStack","content":" 站在风口上 要问近两年最火的技术话题是什么？\nService Mesh 一定不会缺席。\n如果用一句话来解释什么是 Service Mesh。\n可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。*\n对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关心服务之间的那些原本通过服务框架实现的事情，只要交给 Service Mesh 就可以了。\nService Mesh 作为 sidecar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在 Serivce Mesh 中实现，这对于限流熔断而言就是一个天然的流量劫持点。\n如今蚂蚁 80% 以上的应用都已经完成了 Mesh 化，Mesh 统一限流熔断的建设自然是水到渠成了。\n服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。\n在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。\n 相较于传统的限流组件，Mesh 限流具备很多优势，在研发效能和研发成本上都取得了明显的收益：\n- MOSN 架构天然的流量劫持让应用无需逐个接入 SDK\n- 也无需为特定语言开发不同版本的限流组件\n- 限流能力的升级也无需业务同步升级\n「背景业务」\n 在 Mesh 统一限流实现前，蚂蚁集团内部存在多个不同的限流产品，分别提供不同的流量控制策略：\n不同类型的流量（SOFARPC、无线网关 RPC、HTTP、消息等）限流配置分散在不同的平台，由不同的团队维护，产品质量和文档质量参差不齐，学习成本高、使用体验差。\n不同的限流策略需要接入不同的 SDK，引入很多间接依赖，安全漏洞引起的升级频繁，维护成本高。\n不仅在开发建设上存在不必要的人力投入，也给业务方使用造成了困扰和不便。\n另一方面，我们的业务规模越来越大，但大量服务仍在使用最简单的单机限流策略。没有通用的自适应限流、热点限流、精细化限流、集群限流等能力。\n因为限流能力缺失、限流漏配、错误的限流配置等问题引起的故障频发。\nMesh 架构下，sidecar 对流量管理具备天然的优势，业务无需在应用中接入或升级限流组件，中间件也无需针对不同的技术栈开发或维护多个版本的限流组件。\n在目前 Service Mesh 蚂蚁内部大规模接入完成的背景下，将多种不同的限流能力统一收口至 MOSN，将所有限流规则配置统一收口至“统一限流中心”，可以进一步提高 MOSN 的流量管理能力，同时大幅降低业务限流接入及配置成本。\n基于这样的背景下，我们在 MOSN 中进行了统一限流能力建设。\n站在巨人肩膀上 在建设统一限流能力的过程中，我们调研了许多成熟的产品，既包括我们自己的 Guardian、Shiva、都江堰等，也包括开源社区的 concurrency-limits 、Hystrix、Sentinel 等产品。\n我们发现阿里巴巴集团开源的 Sentinel 是其中的集大成者。\n之前我们在打造 Shiva 的过程中也与集团 Sentinel 的同学进行过交流学习，他们也正在积极建设 Golang 版本的 sentinel-golang。\nMOSN 作为一款蚂蚁自研的基于 Golang 技术建设的 Mesh 开源框架，如果搭配上 Sentinel 的强大的流控能力和较为出色的社区影响力，简直是强强联合、如虎添翼、珠联璧合、相得益彰\u0026amp;hellip;啊。\n不过 Sentinel 对于我们而言也并不是开箱即用的，我们并不是完全没有历史包袱的全新业务，必须要考虑到蚂蚁的基础设施和历史限流产品的兼容，经过我们调研发现主要存在几个需要投入建设的点：\n 控制面规则下发需要走蚂蚁的基础设施\n *Sentinel-golang 的单机限流、熔断等逻辑，*和我们之前的产品有较大差异\n 集群限流也要用蚂蚁的基础设施实现\n *Sentinel 自适应限流粒度太粗，*蚂蚁有更加精细化的需求\n 日志采集方案需要调整\n 综合考虑后，我们决定基于 Sentinel 做扩展，站在巨人的肩膀上打造蚂蚁自己的 Mesh 限流能力。\n基于 Sentinel 良好的扩展能力，我们对单机限流、服务熔断、集群限流、自适应限流等都做了蚂蚁自己的实现，也将部分通用的改动反哺到了开源社区，同时配套建设了统一的日志监控报警、统一限流中心。\n 最终我们在 MOSN 里将各种能力都完成了建设，下表展示了 MOSN 限流和其他限流组件的能力对比：\n 奥卡姆剃刀 Pluralitas non est ponenda sine necessitate.\n如无必要，勿增实体\n 一个限流策略就配套一个 SDK 和一个管理后台七零八落，交互体验参差不齐，文档和操作手册质量也良莠不齐，交由不同的团队维护和答疑，如果你全都体验过一遍一定会深恶痛绝。\n而 Mesh 统一限流的核心目的之一就是砍掉这些东西，化繁为简，降低业务同学的学习成本和使用成本，降低我们自己的维护成本。\n- 流量控制的能力全部集成到 MOSN 里，取众家之长，去其糟粕\n- 流量控制的管控台全部收口到统一限流中心\n 这应该是我们造的最后一个限流轮子了吧\n青出于蓝而胜于蓝\n上文提到了我们是站在 Sentinel 的肩膀上实现的 Mesh 统一限流，那我们又做了什么 Sentinel 所不具备的能力呢？\n实际上我们对几乎所有的 Sentinel 提供的限流能力都做了一套自己的实现，其中也有不少的亮点和增强。\n下面分享几个我们的技术亮点。\n自适应限流\n- 对于业务同学而言逐个接口做容量评估和压测回归费时费心，有限的精力只能投入到重点的接口保障上，难免会漏配一些小流量接口的限流。\n- 而负责质量和稳定性保障的同学经常在故障复盘时看到各种漏配限流、错配限流、压测故障、线程阻塞等造成的各种故障。\n我们希望即使在系统漏配错配限流的情况下，在系统资源严重不足时 MOSN 能够精准的找到导致系统资源不足的罪魁祸首，并实时根据系统水位自动调节异常流量。\n在此需求背景下我们实现了一套符合成熟云原生定义的自检测、自调节的限流策略。\n 自适应限流的实现原理并不复杂，朴素的解释就是，触发限流后实时检测系统整体水位，同时秒级按比例调节流量。\n核心逻辑如下：\n- 系统资源检测：秒级检测系统资源占用情况，如果连续超过阈值 N 秒（默认 5 秒）则触发基线计算，同时将压测流量阻断腾挪出资源给线上业务使用；\n- 基线计算：将当前所有的接口统计数据遍历一遍，通过一系列算法找出资源消耗大户，再把这些大户里明显上涨的异常流量找出来，把他们当前的资源占用做个快照存入基线数据中；\n- 基线调节器：将上一步骤存入的基线数据根据实际情况进行调整，根据系统资源检测的结果秒级的调整基线值，仍然超过系统阈值则按比例下调基线值，否则按比例恢复基线值，如此反复；\n- 限流决策：\n系统流量不断经过自适应限流模块，会尝试获取该接口的基线数据，如果没有说明 …","date":1631602800,"description":"技术风口上的限流","dir":"blog/restricted-flow-on-the-technology-windfall/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cb0fcdbcc898f63e21810897fcd0a0d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","publishdate":"2021-09-14T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","summary":"站在风口上 要问近两年最火的技术话题是什么？ Service Mesh 一定不会缺席。 如果用一句话来解释什么是 Service Mesh。 可以将它比作是应用程序或者说微服务间的 TCP","tags":["SOFAStack"],"title":"技术风口上的限流","type":"blog","url":"/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","wordcount":4850},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA x Erda Meetup#8 成都站，云原生基础设施建设的现在及未来\n 活动时间：2021 年 09 月 11 日（周六）13:30-17:00\n 活动地点：四川省成都市武侯区蚂蚁 C 空间 101 猎户座\n 活动形式：线下活动\n 资料下载： 《从云原生视角，解读 Erda 微服务观测系统的实现》 《Service Mesh落地之后：为 sidecar 注入灵魂》 《技术风口上的限流—蚂蚁集团的 Mesh 限流落地与实践 》 《Erda 关于云原生数据开发平台的思考和实践》\n 活动议程 活动回顾 《从云原生视角，解读 Erda 微服务观测系统的实现》\n嘉宾介绍\n刘浩杨，Erda 微服务和监控团队负责人，主要负责云原生 PaaS 的架构设计、微服务观测治理平台的产品技术规划等工作，对分布式、可观察性、云原生等方向有深入的研究和实践经验。同时也是开源爱好者，Apache SkyWalking PMC 成员，在 Apache SkyWalking 的多语言生态和社区建设中起到重要作用。\n议题简介\n 在云原生架构下，基于 DevOps、微服务、容器化等云原生的能力，可以帮助业务团队快速、持续、可靠和规模化地交付系统，同时也使得系统的复杂度成倍提升，由此带来了前所未有的运维挑战。 在此背景下，对分布式系统的“可观测性”应运而生，可观察性提供了一套理念来监控、诊断云原生应用系统。和监控相比，可观察性从单一的度量扩展为 Metrics、Tracing、Logging 三大支柱，Erda MSP (MicroService Platform) 中的 APM 系统也在逐渐演进为以可观察性分析诊断为核心的微服务观测平台，本次主题将会解读 Erda 对微服务观测系统的探索和实践。 听众收获\n可快速了解监控和可观测性技术的发展历程，了解云原生场景下可观测性的痛点和解决方案，及获取 Erda 微服务观测平台的功能特性。\n《Service Mesh落地之后：为 sidecar 注入灵魂》\n嘉宾介绍\n周群力（花名：仪式），开源爱好者, co-founder of Layotto，Dapr contributor。目前在蚂蚁中间件团队工作，对SOFAStack和MOSN的开源影响力负责。虽然工作是做云原生基础设施，但业余时间也喜欢折腾前端和数据。\n议题简介\n 随着Service Mesh在蚂蚁集团内部的大规模落地，我们逐渐遇到了新的挑战，这让我们迫切的寻找新的解决方案。 Service Mesh通过引入sidecar来简化服务治理，但是随着探索实践，我们发现 sidecar 能做的事情远不止于此。一方面，给 sidecar 添加 Multi-Runtime 能力可以帮助基础设施团队更好的和业务团队解耦，简化多语言治理；另一方面，中立的 Runtime API 可以抽象基础设施、简化编程，帮助 K8s 生态成为真正的“分布式操作系统”，也帮助应用彻底和厂商解绑，保证多云环境的可移植性；与此同时，在 WebAssembly 日益火爆的当下，WASM 也能帮助 sidecar 实现 FaaS、业务系统 sdk 下沉等功能。 那么，Service Mesh落地之后，架构演进的思路是什么？我们的思路是：为sidecar注入灵魂。 听众收获\n 了解蚂蚁集团在Service Mesh大规模落地以后遇到的新问题以及对于如何解决这些问题的思考。 了解Multi-Runtime解决的问题及实践经验。 了解中立的Runtime API解决什么问题，以及相关实践经验 了解WASM在FaaS等方向的探索。 《技术风口上的限流—蚂蚁集团的 Mesh 限流落地与实践 》\n嘉宾介绍\n张稀虹，蚂蚁集团技术专家，专注于云原生相关技术在业务生产中的落地与实践，开源项目 MOSN 核心成员，目前关注云原生 ServiceMesh、Serverless 等相关领域。\n议题简介\n ServiceMesh 可谓是站在风口上的技术热点，流量控制正是 Mesh 架构下的核心功能。Mesh 的架构优势使得业务可以更低成本的使用上通用的限流熔断能力，本次分享为大家介绍蚂蚁集团的 Mesh 限流能力的建设以及业务落地推广的实践经验。 听众收获\n 了解 Mesh 架构下的限流熔断技术优势 分享蚂蚁集团 Mesh 限流熔断能力建设经验 拓宽思路了解限流熔断未来的探索方向 《Erda 关于云原生数据开发平台的思考和实践》\n嘉宾介绍\n侯璐瑶，高级技术专家，Erda 数据团队负责人，主要负责基于云原生的数据平台的架构设计、负责数据应用产品架构和产品演进，对于大数据领域数据组件和数据应用等方向有比较深入的研究和实践经验。\n议题简介\n 数据 on 云原生是必然的路径，云原生对于数据平台带来了比传统平台更容易的扩展性和便捷性。本次分享主要介绍 Erda 数据开发平台在云原生上的建设和实战经验。 听众收获\n 了解云原生的整体数据架构； 分享 Erda 的落地实践经验。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1631343600,"description":"【活动回顾】SOFAMeetup#8 成都站 云原生基础设施建设的现在及未来","dir":"activities/sofa-meetup-10/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"270d57821d3a01ac4bc85082d157f6d9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-10/","publishdate":"2021-09-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-10/","summary":"概要 活动主题：SOFA x Erda Meetup#8 成都站，云原生基础设施建设的现在及未来 活动时间：2021 年 09 月 11 日（周六）13:30-17:00 活动地点：四川省","tags":["SOFAMeetup"],"title":"【活动回顾】SOFAMeetup#8 成都站 云原生基础设施建设的现在及未来","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-10/","wordcount":1791},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@胡希国 提问：\n 这个 start 函数在父进程执行完 WaitConnectionsDone()之后在哪调用的，新的子进程在迁移长连接的时候监听 conn.sock 等着老进程调 startRWloop 去连接和发送 connfd，看源码一直到 WaitConnectionsDone() 就断了，实在没找到接下来在哪执行的 ReadLoop 和 WriteLoop。\n https://github.com/mosn/mosn/blob/0ea3e3b4b2abfde2a845edc006a3e866ff0b1201/pkg/network/connection.go#L186\nA：迁移连接之后，创建连接最后就会 start 了。\n 2、@胡希国 提问：\n 父进程的每个长连接 connection fd 里面都有一个 readloop 逻辑是吗？一旦 WaitConnectionsDone() 触发了 stopchan 那个条件，就自动做迁移了是吧。\n A：是的，每个连接都有 readloop 的， WaitConnectionsDone 就是等他们迁移完。\nhttps://mosn.io/docs/concept/smooth-upgrade/\n这篇文章里面有写的。\n 3、@汪晓涛 提问：\n 镜像地址有吗？可以对接 dapr 吗？\n A：目前是七层扩展哈，对接 dapr 是四层，这个月底应该就可以支持了。\nhttps://github.com/mosn/mosn/issues/1563\n4、@徐泽唯 提问：\n 大佬帮我看下这是什么问题？xid in change during RPC from 192.168.2.115:8091:178170994535436288 to null。\n A：不影响，直接升级最新的 spring-cloud-starter-alibaba-seata 和最新的 seata-all 或者 seata-spring-boot-starter 即可，只是一个日志警告。\n5、@北京jht 提问：\n 如果想了解一下这个组件对系统带来的开销和性能，可能会出现在哪个问题上。\n A：没有实际的业务场景，结果出入比较大。RPC 开销应该是最大的消耗。\n 咱们这个 Seata-Server 的回查和提交都是异步的吧，会对 RPC 本身的耗时产生影响吗？\n A：你算 RPC 一次 1ms tm begin 1ms rmregisty 1ms 如果有 3 个 rm，就是 4ms。然后 tm 决议发给 tc，5ms。如果是 tcc，那么就是 5ms + tc 下发到 3 个 rm 执行，rm 执行二阶段业务也要时间。\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1631257200,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210910/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e29e1740eb32b19f715b92a21a2dfd02","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210910/","publishdate":"2021-09-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210910/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210910/","wordcount":907},{"author":"向万鹏","categories":"SOFAStack","content":" AntMonitor简介 AntMonitor 是蚂蚁集团的智能监控系统，通过构建面向监控可观测数据的、实时的、稳定的采集、清洗、计算及存储数据链路，为技术风险大脑及体系提供实时、稳定、可靠、丰富的可观测数据与告警服务。\nAntMonitor 日常服务于蚂蚁全站 100+ 业务域，分钟峰值数据清洗量 20TB、数据聚合量 1TB、数据存储量 1.5 亿条，大促期间这些指标更是成倍增长，如此庞大且复杂的系统是如何对自身的稳定性进行保障的，这篇文章将从思考、策略与实现的角度带领大家一探究竟。\n系统构架 系统架构上，AntMonitor 可以分为产品、告警、计算和存储等四个子系统，各个子系统可以独立提供服务，又相互协调配合，承担起了蚂蚁技术风险的数据底盘角色。\n 产品系统 产品系统直接为用户提供各项可视化服务，包括 monitormeta 和 monitorprod 两个组件。\n monitormeta 负责元数据的管理与同步，例如计算配置、告警规则以及各类运维元数据等；\n monitorprod 为产品中台核心服务，对外提供数据服务；对内支持数据模型定义，数据模型抽象，数据模型转换等能力。\n 计算系统 计算系统提供一体化的数据采集、清洗、聚合与数据生命周期管理服务。计算系统内组件较多，可以分为服务层、计算层和采集层进行介绍。\n一、服务层\n tableapi 对外提供标准的数据服务接口；\n dimservice 为列式的元数据缓存服务中心。\n 二、计算层\n global-scheduler（gs） 为全局任务调度组件，负责对注册过来的 compute-space 计算集群进行生命周期管理，并基于配置生成任务拓扑，随后投递到计算集群。\n compute-space（cspace） 为一个抽象的计算能力资源池，负责对gs投递过来的任务拓扑进行解析执行以产出数据，写入存储系统，并将任务状态反馈给 gs ，cspace 并不与具体的数据计算资源池绑定，底层的实现可以是任意计算引擎。当前，一个 cspace 节点的实现为一个 spark 集群。\n三、采集层\n gaea-registry为整个采集侧的管控中心，它将采集配置下发给 agent 和 vessel ，同时也负责维护所有 agent 和 vessel 的健康状态与路由信息等。\n agent为部署在物理机上的采集服务进程，负责对日志、系统指标、事件等原始数据进行读取。\n vessel为数据清洗集群，负责拉群 agent 采集的原始数据进行结构化清洗，并以 rpc 形式返回给 cspace 。\n 告警系统 告警系统基于用户配置的告警规则对计算产出的指标数据进行巡检，产出告警事件并推送给订阅者。告警系统的组件与计算系统有些类似，包括：\n alarm-global-scheduler（alarm-gs）为告警调度组件；\n alarm-compute-space（alarm-cspace）为告警计算资源池；\n alarm-gateway 为告警推送网关。\n 如果将告警系统和计算系统进行类比的话，可以抽象地认为：告警的输入不是采集，而是计算系统产出的数据；告警的输出也不是存储系统，而是告警通知网关 alarm-gateway 。\n存储系统 存储系统（ceresdb）为 AntMonitor 提供时序数据的读写服务。\n ceresdbconsole 为可视化的运维管控组件；\n ceresmeta 为元数据管理组件，负责存储集群的主备切换、扩缩容等协调工作；\n ceresproxy 与 ceresbase 为部署在同一个容器内的两个伴随进程，其中 ceresproxy 为路由层，负责对查询或写入的数据进行汇总，并将结果返回给客户端，同时提供租户校验、流控、黑名单等能力；ceresbase 为数据存储节点，负责时序数据的存储、索引维护等功能。\n 稳定性建设 监控系统在整个蚂蚁的体系架构内是一个特殊的角色，它在承载所有业务系统的可观测与告警能力的同时，还为容量、自愈、故障应急等技术风险其他子域提供着数据服务。\n因此，监控对自身的稳定性要求更加严苛，在诸如大规模宕机、机房网络中断或更极端情况下，监控也需要保障自身是可以稳定运行的。\n针对蚂蚁智能监控自身的稳定性建设，我们主要从两方面进行推进，包括稳定性架构的设计与运行时的稳定性保障，整体如下图所示。\n 稳定性架构 稳定性架构是建设稳定性中最重要的一环，一个经过缜密设计的稳定性架构，可以使我们后期尽可能优雅从容地处理各类稳定性问题，而不是疲于奔命地打地鼠。\n具体来说，在设计稳定性架构之初，我们首先应该意识到系统的运行时环境和输入都不会是稳定的。\n运行时环境的不稳定 ，主要体现在机器的故障宕机、网络的抖动，或者更极端的机房光纤被挖断、城市自然灾害等客观因素影响。处理这类问题通常从两方面出发：\n第一、尽可能地提升系统的容灾等级。\n例如单点、机房级容灾、城市级容灾等，以最基础的去单点来说，我们需要保证所有的调度或同步类节点（例如 monitormeta、gs）都是基于主备架构的，所有的服务类节点（例如 monitorprod、tableapi）都是无状态的，所有的分片节点（例如 gaea-registry、ceresbase）都是存在冗余副本的，所有的工作类节点（例如 cspace、alarm-cspace），宕机后也都是可以自行恢复的。\n第二、所有的数据处理流程都应该面向失败进行设计。\n因为当故障发生后，可能某几个周期的任务已经失败，这时候需要有能力驱动这些任务进行重试，例如 cspace 需要有能力对某一个计算任务的采集失败进行容忍和重试、alarm-gs 需要对告警任务的执行失败进行重新调度等。\n针对系统输入的不确定性 ，我们也分两种情况进行处理：\n第一种情况是入口数据的错乱。\n例如脏配置、脏元数据、不合法的数据类型等，错误的数据流入系统可能会导致不可预期的行为，针对此类问题，我们通常需要在入口处进行校验，拒绝非预期的数据流入系统。\n第二种情况是入口数据量级管控。\n任何系统，其性能都是和容量挂钩的，其设计也都是在一定的性能容量平衡假设下进行的。监控系统的输入通常是业务日志，而且监控配置的定义是直面用户的，那么很可能一个随意定义的配置将导致海量的服务调用明细日志流入监控系统，导致集群崩溃，所以对流量的限制与管控非常重要。在 AntMonitor 中，各个关键的入口例如采集入口、计算入口、存储入口、数据查询入口等都有严格的流量管控校验规则，确保监控系统在预期容量下能够稳定运行，而不会被突发的流量所压垮。\n综上，我们将重点从容灾架构和架构单元化两方面出发来阐述 AntMonitor 稳定性架构的设计思路。\n容灾架构 前文简要提及了架构去单点问题的解决思路，这足以覆盖日常可能发生的节点宕机、网络抖动等小规模故障场景，但是当真正的毁灭性灾难来临时，还需要更高层面的容灾方案来应对。\n目前基于不同租户保障等级的区分以及资源配额等客观因素的权衡，AntMonitor 实施了两套不同等级的容灾策略，即针对常规业务域租户的机房级容灾和针对高保业务域租户的城市级容灾。\n机房级容灾 对于常规的业务域租 …","date":1630998000,"description":"蚂蚁智能监控","dir":"blog/ant-intelligent-monitoring/","fuzzywordcount":6700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3529d1b46b4e16c43414a1cd3e89fb02","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-intelligent-monitoring/","publishdate":"2021-09-07T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/ant-intelligent-monitoring/","summary":"AntMonitor简介 AntMonitor 是蚂蚁集团的智能监控系统，通过构建面向监控可观测数据的、实时的、稳定的采集、清洗、计算及存储数据链路，为技术风险大","tags":["SOFAStack"],"title":"蚂蚁智能监控","type":"blog","url":"/sofastack.tech/blog/ant-intelligent-monitoring/","wordcount":6622},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;ldquo;SOFA WEEKLY\u0026amp;rdquo; 的形式回复\n1、@黄润良 提问：\n 在写 filter 扩展的时候，如何获取一些请求的信息？比如请求 ip 之类的。\n A：*pkg/server/handler.go*，这里面可以看到设置进去的。\n MOSN：https://github.com/mosn/mosn\n2、@黄润良 提问：\n 一些 filter 只能用于某些协议的，但从配置来看，filter 应该是对所有协议都生效的吧？那我在设计 filter 的是需要考虑协议的兼容性吗？\n A：你配置的 listener 块里面有协议，就可以和 filter 对应上了。\n如果你怕别人误用，可以简单处理绕过。比如 dubbofilter 就是 Dubbo 协议自有的，怕其他协议误配置了，可以在代码跳过。\n MOSN：https://github.com/mosn/mosn\n3、@黄润良 提问：\n 目前有方法可以控制 filter 的执行的先后顺序吗？\n A：按照配置的顺序。\n 4、@楼政浩 提问： 往 raft 集群提交数据，都得通过 RPC 吗？ 如果我的 raft 节点的 fsm 又输出了 log，我想往集群提交这个 log，可以通过什么接口？\n A：jraft 通过 raft log 将数据复制到你各个节点的 fsm，fsm 的输入数据全部来自 raft log，你说的 fsm 又输出了 log 如果我没理解错的话，就是说本质上 fsm log 的输入全部来自 raft log，那么你这个所谓 log 就存在你自己的 fsm 就行，本来就是每个节点都会有的，不要再提交。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n5、@陈华洋 提问：\n SOFABoot 的模块化是怎么解决数据库链接的问题。 就是 SOFABoot 模块化之后，我把 mybatis 配置到了公共模块里面，然后其他模块父上下文指定为公共模块，但是其他模块内的 @Mapper 在项目启动的时候都扫描不到。\n A：建议把所有数据库相关的操作都放同一个模块，封装成 dal 层。可以配一个配置,让一个 spring 上下文里的 bean 暴露出来、能给别的 Spring 上下文用。\nSOFABoot：https://github.com/sofastack/sofa-boot\n6、@Z 提问：\n 请问在大数据量操作的时候，配置上有什么建议吗？\n A：把 6000 多条数据的操作在一个本地事务中完成，合并成一个分支注册。\nSeata：https://github.com/seata/seata\n7、@金箍 提问：\n 请问全局事务提交成功或者失败之后，有回调方法可以用吗？\n A：tm 有个 hook，其他没有。源码搜索「transactionlHook」有相关的文档。\nSeata：https://github.com/seata/seata\n8、@仪式 提问：\n 如果事务进行的过程中事务发起者（TM）宕机了，Seata 会怎么做故障处理呀。\n A：超时回滚，如果 TM 是决议提交给了 TC，那么“是”提交，“否”就只能等待超时回滚。TC 里的定时任务来做超时回滚。\nSeata：https://github.com/seata/seata\nSOFAStack \u0026amp;amp; MOSN：新手任务计划\n作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nSOFA-Boot\n设计实现一个新的配置项，用于判断 SOFA-Boot 是否由 IDE 启动。\nhttps://github.com/sofastack/sofa-boot/issues/861\nLayotto\n减少 panic 风险，给所有创建新协程的代码加上 recover。 设计实现 actuator metrics API，用于统计、展示 metrics 指标 WASM 通过 State API 访问存储：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n","date":1630652400,"description":"SOFA WEEKLY | QA 整理，新手计划","dir":"blog/sofa-weekly-20210903/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b8e03b60dc613f8a724cc3f95441bc2e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210903/","publishdate":"2021-09-03T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210903/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理，新手计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210903/","wordcount":1569},{"author":"SOFA 团队","categories":"SOFAStack","content":" 真的吗？真的吗？\nSOFA 志愿者开始招募啦？\n直视他！直视他！\nSOFA 星球在等你加入呀！\n我们正式启动“SOFA 星途者”计划\n只差一个你 即可成团出道\n不要感觉成团困难\n只要我们一起就能所向披靡\n谁是SOFA“星途者” SOFA 星途者是一群对开源宇宙感兴趣，希望在这片“宇宙”其中探索到更多“星辰”的人。SOFA 星途者们能够为千千万万的开发者们，提供丰富的 Meetup 及线上直播等交流平台。\n现在面向一切有理想、有追求的你们进行招募。\n“星”字代表 SOFA 星球，“途”代表在开源宇宙的征途。所以“星途”的意思即 SOFA 星球在开源宇宙的探索与征途。\n那么“星途者”就是加入 SOFA 星球的你们，让我们一起在开源宇宙中驰骋探索。\n“SOFA 星途者，探索开源宇宙中的星辰大海”\n即将进入，SOFA 社区 SOFAStack™（Scalable Open Financial Architecture Stack）是一套用于快速构建金融级云原生架构的中间件，也是在金融场景里锤炼出来的最佳实践，并且具备以下特点：\n开放：技术栈全面开源共建、 保持社区中立、兼容社区、兼容开源生态，组件可插拔， SOFAStack 组件与其它开源组件可相互集成或替换。\n金融级：包含构建金融级云原生架构所需的各个组件，让用户更加专注于业务开发，满足用户场景的现状和未来需求，经历过大规模场景的锤炼，特别是严苛的金融场景。\n云原生：基于 SOFAStack 可快速搭建云原生微服务体系，快速开发更具可靠性和扩展性、更加易于维护的云原生应用。\n开启 SOFA 征途 SOFA 陆续在全国各地组织了多场 Meetup 活动，活动全程直播，线上线下参与人数累计破万。Meetup 为 SOFA 星途者提供面对面沟通探讨的机会，收到了业界人士的一致好评。\n目前在北京、上海、杭州、合肥举办过 Meetup 活动，后续的还会点亮更多城市（成都、深圳、广州、南京等），欢迎你作为 SOFA 星途者加入我们的征途。\n杭州站\n 上海站\n 北京站\n 合肥站\n 召唤装备！ 在 SOFA 星球，大家不仅能够与每个领域的技术大牛面对面交流技术、认识新朋友，更能够收获 SOFA 星途者的周边衣服、杯子、双肩包等……\n最重要的是可以收获 SOFA 社区颁发的专属证书。\nSOFA 星途者的成员在参加 SOFA 的活动时可享受 VIP 通道，也会获得一些特大活动的 VIP 门票赠送～\n如果你是大学生“星途者”，那么你有可能会获得互联网大厂的实习推荐机会，在你感兴趣的星辰领域继续探索成长，有机会获得更多的学习机会。\n想成为一名“星途者”需要做些什么？\n扫描下方二维码\n 勇敢迈出成为“星途者”的第一步\n剩下的九十九步\n我们一起走\n","date":1630393200,"description":"SOFA 星球招募啦～","dir":"blog/sofa-star-is-recruiting/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d889b6b480fa6731f51805443e5ca5db","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-star-is-recruiting/","publishdate":"2021-08-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-star-is-recruiting/","summary":"真的吗？真的吗？ SOFA 志愿者开始招募啦？ 直视他！直视他！ SOFA 星球在等你加入呀！ 我们正式启动“SOFA 星途者”计划 只差一个你 即可成团出道 不要感觉成团","tags":["SOFAStack"],"title":"SOFA 星球招募啦～","type":"blog","url":"/sofastack.tech/blog/sofa-star-is-recruiting/","wordcount":960},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@胡希国 提问：\n 想和大家请教一下 MOSN 的热升级方案，就是我看到 MOSN 也是通过接收到 hup 信号然后 fork 的方式生成的一个新的子进程，（确切来说是 forkexec），和 Envoy 的解决方案应该是相同的，那为什么说和 Nginx 不一样呢？这种也是存在父子进程关系的吧（我看到 Envoy 是存在的），那为什么说没有继承 listenerfd 而需要通过 uds 来传递呢？\n A：Nginx reload 的过程是 master 不会退出，只是新 fork 了子进程。MOSN 是先启动一个 MOSN 进程，然后通过 socket 把 fd 继承过去之后，老的 MOSN 会退出。\nMOSN：https://github.com/mosn/mosn\n2、@鹏程万里 提问：\n FailureHandler 怎么实现自定义类呢？需要做回滚失败的通知。\n A：自己创建一个 Failurehandler bean return 一个实现类。\nSeata：https://github.com/seata/seata\n3、@随风 提问：\n 请问下，如果 A 方法和 B 方法上都有注解 GlobalTransactional，那么 A 方法可以直接调用 B 方法吗？\n A：可以的，用的还是一个 xid。\nSeata：https://github.com/seata/seata\n4、@zero 提问：\n 有分布式数据库了还需要用 Seata 吗？\n A：分布式数据库解决的是单个 connection 中每个 SQL 请求到了不同的库上的事务。一个分布式数据库背后可能有 N 个数据库被操作，内部用 xa 保证了事务。\nSeata：https://github.com/seata/seata\n本周发布 本周 SOFAJRaft 发布 1.3.8v版本。主要更新如下：\n Snapshot 支持并行压缩/解压缩，充分利用多核，加速在 snapshot 较大的时的 load 和 save 速度；\n CliService 提供 learner 到 follower 的转换 API；\n 修复 install snapshot retry 失败的 bug；\n 修复 RheaKV 在成员发生变更时没有刷新路由表的 bug。\n 详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.8\n新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nSOFA-Boot\n 发布服务时 增加 interfaceType 校验；\n 增加 SOFATracer 插件。\n 详见：\nhttps://github.com/sofastack/sofa-boot/issues/841\nLayotto\n 选择喜欢的组件实现分布式锁和分布式自增 id；\n 让 Layotto 能够简单方便的部署在 Kubernetes 上；\n 提供 Dockerfile，以便用户用 docker 部署 Layotto 。\n 详见：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1629442800,"description":"SOFA WEEKLY | SOFAJRaft 发布新版本,QA 整理","dir":"blog/sofa-weekly-20210820/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"60274ff33263cdb109e3d4342c35a45a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210820/","publishdate":"2021-08-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210820/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本,QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210820/","wordcount":1223},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#21：走进下一代互联网：HTTP/3\n 活动时间：08月18日,周三晚19点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#21：走进下一代互联网：HTTP/3 近年来，具备优秀基因的 QUIC 协议成为互联网领域炙手可热的传输技术。基于 QUIC 承载的 HTTP/2 也被正式命名为下一代传输协议： HTTP/3。这次直播会给大家介绍 QUIC，HTTP/3 的核心设计理念，以及在蚂蚁的应用实践。​\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 孔令涛（花名：伯琴） 蚂蚁集团技术专家，主要从事四七层协议优化，网关开发等工作。 议程 19:00-19:05 主持人开场 小助手-泡椒 主持人\n19:05-20:00 用安全计算保护关键业务 伯琴 蚂蚁集团技术专家，主要从事四七层协议优化，网关开发等工作。\n你将收获 你将了解 QUIC/HTTP/3 协议的前世今生、优良特性、落地实践、普及情况、与未来发展趋势等。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1629270000,"description":"8 月 18 日周三晚 19 点，线上直播第 21 期。","dir":"activities/sofa-channel-21-1/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b77dae9fff7d781959845f53872d0eee","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-21-1/","publishdate":"2021-08-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-21-1/","summary":"概要 活动主题：SOFAChannel#21：走进下一代互联网：HTTP/3 活动时间：08月18日,周三晚19点 活动形式：线上直播 资料下载：戳","tags":["SOFAChannel","HTTP/3"],"title":"SOFAChannel#21：走进下一代互联网：HTTP/3","type":"activities","url":"/sofastack.tech/activities/sofa-channel-21-1/","wordcount":588},{"author":"于雨","categories":"SOFAStack","content":" 个人有幸担任了 2021 年 GIAC 会议云原生专场的出品人兼讲师，组织了前后四个场子的演讲，在这个过程中个人同时作为听众从这些同行的演讲中学到了很多非常有用的知识。本文算是对 2021 GIAC 云原生专场的侧记，管中窥豹，以观 2021 年云原生技术发展现状及未来一段时间内的趋势。\n 云原生这个词含义广泛，涉及到资源的高效利用、交付、部署及运维等方方面面。从系统层次分可以区分出云原生基础设置【如存储、网络、管理平台 K8s】、云原生中间件、云原生应用架构以及云原生交付运维体系，本次专场的四个议题也基本涵盖了这四大方向：\n 亚马逊的资深技术专家黄帅的 《一个云原生服务的爆炸半径治理》 快手基础架构中心服务网格负责人姜涛的 《快手中间件 Mesh 化实践》 Tetrate 可观测性工程师柯振旭的 《使用 SkyWalking 监控 Kubernetes 事件》 本人以 Dubbogo 社区负责人出品的《Dubbogo 3.0：Dubbo 在云原生时代的基石》 下面根据个人现场笔记以及个人回忆分别记述各个议题的要点。因时间以及本人能力有限，一些错误难免，还请行家多多指正。\n云原生服务的爆炸半径 个人理解，黄的这个议题属于云原生应用架构范畴。\n其演讲内容首先从亚马逊 AWS 十年前的一个故障说开：AWS 某服务的配置中心是一个 CP 系统，一次人为的网络变更导致配置中心的冗余备份节点被打垮，当运维人员紧急恢复变更后，由于配置中心不可用【有效副本数少于一半】导致了整个存储系统其他数据节点认为配置数据一致性不正确拒绝服务，最终导致整个系统服务崩溃。\n复盘整个事故的直接原因是：CAP 定理对可用性和一致性的定义限定非常严格，并不适合应用于实际的生产系统。因此作为线上控制面的配置中心的数据应该在保证最终一致性的前提下，首先保证可用性。\n更进一步，现代分布式系统的人为操作错误、网络异常、软件 Bug、网络/存储/计算资源耗尽等都是不可避免的，分布式时代的设计人员一般都是通过各种冗余【如多存储分区、多服务副本】手段保证系统的可靠性，在不可靠的软硬件体系之上构建可靠的服务。\n但是这中间有一个误区：有时候一些冗余手段可能因为雪崩效应反而会导致系统可靠性地降低。如上面的事故，人为的配置错误导致了一连串的软件体系故障，且这些故障之间是高度强相关的，最终导致了雪崩效应，可以称之为 “水平扩展的毒药效应”。此时思考的维度就从 “在不可靠软硬件体系上提供可靠服务” 进一步拓展为 “通过各种隔离手段减小事故的爆炸半径”：当不可避免的故障发生时，尽量把故障损失控制到最小，保障在可接受范围内，保证服务可用。\n针对这个思路，黄给出了如下故障隔离手段：\n 服务粒度适中 微服务的服务粒度并不是拆分的越细越好。如果服务粒度过细，会导致服务数量过多，其第一个后果就是导致一个组织内几乎无人能搞清楚服务整体逻辑的来龙去脉，增加维护人员的负担：大家只敢小修小补无人敢做出大幅度的优化改进。\n服务粒度过细的第二个后果是造成整体微服务单元体指数级增加，造成容器编排部署成本上升。适中的服务粒度要兼顾架构体系的进化与部署成本的降低。\n 充分隔离 进行服务编排时，获取数据中心的电源和网络拓扑信息，保证强相关系统之间部署做到 “不远” 且 “不近”。\n“不近”是指同一个服务的副本不在使用同一个电源的同一个机柜部署，也不在使用了同一个网络平面的 Azone 内部署。“不远” 是指部署距离不能太远，例如多副本可以同城多 IDC 部署。使用这两个原则兼顾性能与系统可靠性。\n 随机分区 、所谓的随机分区这块，其实质就是在混合服务请求，保证某个服务的请求可以走多通道【队列】，保证在某些通道挂掉的情况下不影响某个服务的请求处理，应用随机分区技术，将用户打散在多个 Cell 中，大幅度降低爆炸半径。\n与 K8s APF 公平限流算法中的洗牌分片（Shuffle Sharding）颇为相似。\n 混沌工程 通过持续内化的混沌工程实践，提前踩雷，尽量减少 “故障点”，提升系统可靠性。\n使用 SkyWalking 监控 Kubernetes 事件 这个议题虽然被安排在第三场演讲，属于云原生交付运维体系，但是与上个议题关联性比较强，所以先在此记述。\n如何提升 K8s 系统的可观测性，一直是各大云平台的中心技术难题。K8s 系统可观测性的基础数据是 K8s event，这些事件包含了 Pod 等资源从请求到调度以及资源分配的全链路信息。\n SkyWalking 提供了 logging/metrics/tracing 等多维度可观测性能力，原来只是被用于观测微服务系统，今年提供了 skywalking-kubernetes-event-exporter 接口，专门用于监听 K8s 的 event，对事件进行提纯、收集、发送至 SkyWalking 后端进行分析和存储。\n 柯同学在演讲过程中花费了相当多的精力演讲整个系统的可视化效果如何丰富，个人感兴趣的点如下图所示：以类似于大数据流式编程的手段对 event 进行过滤分析。\n 其可视化效果与流式分析手段都是蚂蚁 Kubernetes 平台可借鉴的。\n快手中间件mesh化实践 快手的姜涛在这个议题中主要讲解了快手 Service Mesh 技术的实践。\n 姜把 Service Mesh 分为三个世代。其实划分标准有很多，如何划分都有道理。很明显，姜把 Dapr 划入了第三个世代。\n 上图是快手的 Service Mesh 架构图，很明显借鉴了 Dapr 的思想：下沉基础组件的能力到数据平面，把请求协议和接口标准化。一些具体的工作有：\n 1 统一运维，提高可观测性与稳定性，进行故障注入和流量录制等 2 对 Enovy 等做了二次开发，只传输变更的数据、按需获取，解决单实例服务数过多的问题 3 对协议栈和序列化协议做了大量的优化 4 实施了面向失败设计，Service Mesh 可以 fallback 为直连模式 个人感兴趣的是姜提到了 Service Mesh 技术在快手落地时面临的三个挑战：\n 成本问题：复杂环境下的统一部署与运维。 复杂度问题：规模大、性能要求高、策略复杂。 落地推广：对业务来说不是强需求。 特别是第三个挑战，Service Mesh 一般的直接收益方不在业务端，而是基础架构团队，所以对业务不是强需求，而且快手这种实时业务平台对性能非常敏感，Service Mesh 技术又不可避免地带来了延迟的增加。\n为了推动 Service Mesh 技术的落地，快手的解决手段是：\n 1 首先务必保证系统稳定性，不急于铺开业务量； 2 搭车公司重大项目，积极参与业务架构升级； 3 基于 WASM 扩展性，与业务共建； 4 选取典型落地场景，树立标杆项目。 姜在最后给出了快手下半年的 Service Mesh 工作：\n 很显然这个路线也是深受 Dapr 影响，理论或者架构上创新性不大，更侧重于对开源产品进行标准化并在快手落地。\n在演讲中姜提到了 Serivce Mesh 技术落地的两个标杆：蚂蚁集团和字节跳动。其实他们成功的很重要原因之一就是高层对先进技术的重视以及业务侧的大力配合。 …","date":1629183600,"description":"2021 年云原生技术发展现状及未来趋势","dir":"blog/2021-cloud-native-technology-development-status-and-future-trends/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ee44d71749f600f689656893c5b607af","permalink":"https://sofastack.github.io/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","publishdate":"2021-08-17T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","summary":"个人有幸担任了 2021 年 GIAC 会议云原生专场的出品人兼讲师，组织了前后四个场子的演讲，在这个过程中个人同时作为听众从这些同行的演讲中学到了很多非常有用","tags":["SOFAStack"],"title":"2021 年云原生技术发展现状及未来趋势","type":"blog","url":"/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","wordcount":3976},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙运盛 提问：\n 我想咨询大家一个问题，假如二阶段提交或者回滚的方法里，再发生异常的话，应该如何处理呢？\n A：这个异常后，重新捞取之前没结束的事务，重试就可以了吧，二阶段反正已经不阻塞其它一阶段的流程了。\nSeata：https://github.com/seata/seata\n2、@胡希国 提问：\n 我想请教一个问题，这里 New MOSN 收到 Old MOSN 传来的监听文件描述符之后，利用 filelistener 函数产生一个 listener 的作用是和 bind 一样么？就在 New MOSN 上开始监听了是吗？那这时候 Old MOSN 不也同时在监听么，这里的内部逻辑是什么样的？\n A：跟 bind 不一样，这儿是同一个 fd，两个进程都监听，常规操作。你可以想象成 Nginx 的多个进程都可以监听一个 listen 一样。\nMOSN：https://github.com/mosn/mosn\n3、@胡希国 提问：\n MOSN 的 forkexec 是个怎么样的方式呢？它也和 Envoy 一样有一个独立的 python（envoy）进程来负责产生新的 MOSN 进程么？\n A：MOSN 启动起来之后检查到有 socket 文件，然后和 Old MOSN 通信继承 fd，继承完了通知 Old MOSN 退出，所以你可以直接启动一个 MOSN 来。\nMOSN：https://github.com/mosn/mosn\n4、@胡希国 提问：\n 想请问下 MOSN 实现的过程为什么没有采用直接 fork 父进程的方式呢？\n A：容器间升级是不能 fork 的。\nMOSN：https://github.com/mosn/mosn\n5、@ch 提问：\n 今天发生了一个 rollback status: TimeoutRollbacking 超时问题。 描述: Seata 提示 rollback status: TimeoutRollbacking。 出现原因：全局事务在执行 order 库和 account 库，因为 account 库被 IO 堵死 导致业务超时执行了 70s。 然后 Seata 就报 timeout 导致 order 库回滚了数据 account 没有回滚数据（account 已经被 IO 流撑死,无法读写数据）。 版本：client 1.3.0 server 1.3.0。\n A：account 没有回滚诗句，tc 会重试。回滚事务，只要注册了的事务就一定能回滚，没注册的本地事务就会回滚，所以其实没有任何问题。\nSeata：https://github.com/seata/seata\nSOFAStack \u0026amp;amp; MOSN：新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发，但是不知道从何下手“的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing！\nLayotto 新手任务：\n 支持运行多个 Wasm 模块，以便让 Layotto 成为 FaaS 容器；\n 提供 Dockerfile，以便用户用 docker 部署 Layotto；\n 看懂 Wasm 模块的实现并为 Wasm 模块编写单元测试。\n 详见 ：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1628838000,"description":"SOFA Weekly | SOFAStack \u0026 MOSN：新手任务计划，QA 整理","dir":"blog/sofa-weekly-20210813/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"84929b0bd678bf23739507e3920d0293","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210813/","publishdate":"2021-08-13T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210813/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAStack \u0026 MOSN：新手任务计划，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210813/","wordcount":1357},{"author":"郑志雄（纶珥）","categories":"SOFAStack","content":" 背景 微服务架构带来很多好处的同时也让系统的复杂度提升了，传统的单体应用按照不同的维度拆分成一个一个分布式微服务，不同的微服务甚至可能采用不同的语言编写；此外，服务的部署往往都是分布式的，可能有几千台服务器，横跨多个不同的城市数据中心。下图是一个典型的微服务架构，图中的节点数还比较少，在支付宝，一个线下支付整体交易付款链路，涉及上百个节点。\n 图片来源：https://www.splunk.com/en_us/data-insider/what-is-distributed-tracing.html#benefits-of-distributed-tracing\n微服务化引入了以下几个典型问题：\n 故障定位难，一次请求往往需要涉及到多个服务，排查问题甚至需要拉上多个团队;\n 完整调用链路梳理难，节点调用关系分析;\n 性能分析难，性能短板节点.\n 以上这几个问题其实都是应用的可观测性问题：\n Log；\n Trace；\n Metrics。\n 本文将会专注于 Trace 方面，完整地说是分布式链路跟踪 (Distributed tracing)。2010 年谷歌发表了 Dapper 的论文，分享了他们的解决方案，算是业界比较早的分布式链路追踪系统。之后各大互联网公司纷纷参照 Dapper 的思想推出各自的链路跟踪系统，包括 Twitter 的 Zipkin、阿里的鹰眼，还有 PinPoint，Apache 的 HTrace 和 Uber 的 Jaeger；当然，也有我们的本文的主角：SOFATracer。分布式链路的实现有多种多样，因此也催生了分布式链路追踪的规范：OpenTracing，2019 年 OpenTracing 和 OpenCensus 合并成为了 OpenTelemetry。\nOpenTracing 在深入 SOFATracer 之前先简单解释一下 OpenTracing，因为 SOFATTracer 是基于 OpenTracing 规范（基于 0.22.0 的 OpenTracing，新版的规范 API 有所不同）构建的。一个 Trace 由服务调用生成的 Span 及其之间的引用构成，一个 Span 是一个时间跨度，一次服务调用创建一个新 Span，分为调用 Span 和被调 Span，每个 Span 包含：\n TraceId and SpanId\n 操作名称\n 耗时\n 服务调用结果\n 一个 Trace 链路中一般会有多个服务调用，那么也就会有多个 Span，Span 之间的关系由引用声明，引用从调用者指向服务提供者，OpenTracing 中指定了两个引用类型：\n ChildOf，同步服务调用，客户端需要服务端的结果返回才能进行后续处理；\n FollowsFrom，异步服务调用，客户端不等待服务端结果。\n 一个 Trace 是一个有向无环图，一次调用的拓扑可以如下展示：\n 图中的 SpanContext 是一次请求中会共享的数据，因此叫做 Span 上下文，一个服务节点在上下文中放入的数据对于后续的所有节点都可见，因此可以用来做信息传递。\nSOFATracer TraceId 生成 TraceId 收集一次请求中的所有服务节点。其生成规则需要避免不同 TraceId 之间的冲突，并且开销不能很高，毕竟 Trace 链路的生成是业务逻辑之外的额外开销。SOFATracer 中的 TraceId 生成规则是：服务器 IP + 产生 ID 时候的时间 + 自增序列 + 当前进程号，比如：\n0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，大家也可以根据这个规律来查找到请求经过的第一个服务器。 后面的 13 位 1403169275002 是产生 TraceId 的时间。 之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。 最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。\n 伪代码如下：\nTraceIdStr.append(ip).append(System.currentTimeMillis()) append(getNextId()).append(getPID()); SpanId 生成 SpanId 记录服务调用拓扑，在 SOFATracer 中：\n 点代表调用深度\n 数字代表调用顺序\n SpanId 由客户端创建\n SOFATracer 中 TraceId 和 SpanId 的生成规则参考了阿里的鹰眼组件\n 合并调用 Span 和被调 Span，结合 TraceId 和 SpanId 就能构建完整的服务调用拓扑：\n Trace 埋点 但是，我们如何生成并获取到 Trace 数据呢？这就得 Trace 采集器（Instrumentation Framework）登场了，其负责：\n Trace 数据的生成、传递和上报\n Trace 上下文的解析和注入\n 并且 Trace 采集器还要做到自动、低侵入和低开销等。典型的 Trace 采集器结构如下，其在业务逻辑之前埋点：\n Server Received (SR), 创建一个新的父 Span 或者从上下文中提取\n 调用业务代码\n 业务代码再次发起远程服务调用\n Client Send (CS) 创建一个子 Span，传递 TraceId、SpanId 和透传数据\n Client Received (CR), 结束当前子 Span，记录/上报 Span\n Server Send (SS) 结束父 Span，记录/上报 Span\n 步骤 3-5 可能没有，也可能重复多次。\n埋点逻辑的实现多种多样，目前主流的有如下几种方式：\n Filter，请求过滤器 (dubbo, SOFARPC, Spring MVC)\n AOP 切面 (DataSource, Redis, MongoDB)\n a.Proxy\nb.ByteCode generating\n Hook 机制 (Spring Message, RocketMQ) Java 语言中，SkyWalking 和 PinPoint 都使用 javaagent 方式做到自动、无侵入埋点。典型的，SOFATracer 实现 Spring MVC 的 Trace 埋点如下：\n SOFATracer 的 Span 100% 创建，只是 log/report 支持采样，相对来说，log/report 的 overhead 更高，更容易在大流量/负载下成为性能瓶颈。而其他 Trace 系统，Span 是采样生成的，但为了在调用出错的情况下能 100% 有 Trace，他们采用了逆向采样的策略。\nSOFATracer 默认把 Trace …","date":1628578800,"description":"蚂蚁集团 SOFATracer 原理与实践","dir":"blog/ant-group-sofatracer-principles-and-practices/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"235d67352aa5a94ae53bf00b4e8c1730","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","publishdate":"2021-08-10T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","summary":"背景 微服务架构带来很多好处的同时也让系统的复杂度提升了，传统的单体应用按照不同的维度拆分成一个一个分布式微服务，不同的微服务甚至可能采用不同","tags":["SOFAStack"],"title":"蚂蚁集团 SOFATracer 原理与实践","type":"blog","url":"/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","wordcount":3268},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定 时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@非余 提问：\n 我有个需求，就是我们有自己的配置中心，我的配置加载不想用默认的文件配置，这里如果我要开发的话应该怎么样加会比较漂亮？\n A：把 config.Load 重写成你自己的配置解析，configmanager.RegisterConfigLoadFunc。\nMOSN：https://github.com/mosn/mosn\n@飒 提问：\n 一个方法先 insert 而后另一个方法 update 事物回滚失败怎么解决？\n A：不会，可能你没有保证写函数被 @GlobalTransactional 注解覆盖或建表语句不是最新的导致了你回滚顺序变了。\nSeata：https://github.com/seata/seata\n@飒 提问：\n A 服务使用了 @GlobalTransactional（rollbackFor = Exception.class），调用了 B 服务，B 服务报错了，结果都提交成功，数据库数据也更新了，一般是什么原因？\n A：应该是你被调用的服务，没有加入到全局事务中去（也就是说，被调用的服务没加上 @GlobalTransactional）。\nSeata：https://github.com/seata/seata\n@冯仁彬 提问：\n 被调用的服务也必须添加 @GlobalTransactional?\n A：被调用的服务如果自身不会有任何地方访问自己身的写库方法，那么仅需集成 Seata，如果自身有，那么自身的写库操作全部要被带有 @GlobalTransactional 注解的地方调用，至于这个入库你自己设计。\nSeata：https://github.com/seata/seata\n本周推荐阅读 KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周发布详情如下：\n本周 MOSN 发布了 v0.24.0 版本。主要更新如下：\n 支持 jaeger tracing；\n grpc 框架支持热升级；\n 变量机制支持 interface 类型的变量；\n 路由模块优化，支持端口匹配、支持变量模式；\n 负载均衡模块多处优化；\n 其他优化与 Bug Fix。\n 详细发布报告：https://github.com/mosn/mosn/releases/tag/v0.24.0\n更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1628233200,"description":"SOFA WEEKLY | MOSN 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210806/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"29e513237a11de947612fdc004f8ddde","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210806/","publishdate":"2021-08-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210806/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210806/","wordcount":1125},{"author":"柴树杉","categories":"SOFAStack","content":" 楔子: 以蚂蚁典型的建站场景为例，在接入 Kusion 后，用户侧配置代码减少到 5.5%，用户面对的 4 个平台通过接入统一代码库而消减，在无其他异常的情况下交付时间从 2 天下降到 2 小时……\n注：本文是柴树杉在 2021 GIAC 大会上分享的内容。相关 PPT 内容请点击下方自行下载\n GIAC 大会 PPT 下载：KCL声明式的云原生配置策略语言 \n0. 你好GIAC 大家好，我是来自蚂蚁的同学，很高兴能在GIAC的编程语言新范式板块和大家分享《KCL配置策略语言》。KCL语言是蚂蚁内部的Kusion解决方案中针对云原生基础设施配置代码化自研的DSL语言，目前已经在建站场景等一些场景开始小范围推广试用。\n我们先看一下简单的KCL代码：\nschema GIACInvitation[name: str]: Name: str = name Topic: str = \u0026amp;quot;分享主题\u0026amp;quot; Company?: str = None Type: str = \u0026amp;quot;分享嘉宾\u0026amp;quot; Address: str = \u0026amp;quot;深圳\u0026amp;quot; invitation = GIACInvitation(\u0026amp;quot;姓名\u0026amp;quot;) { Topic: \u0026amp;quot;KCL配置策略语言\u0026amp;quot; Company: \u0026amp;quot;蚂蚁集团\u0026amp;quot; } 这个例子代码先通过 schema 定义了一个 GIACInvitation 结构体：该结构体有一个 str 类型的 name 参数，同时还有一组标注了类型和默认值的属性。然后通过声明式的语法构造了GIACInvitation 的实例 invitation。\n这个例子虽然简单，但是包含了 KCL 最重要的 schema 语言结构。从例子可以看出 KCL 尝试通过声明式的语法、静态类型检查特性来改进配置代码的编写和维护工作。这也是设计 KCL 语言的初衷，我们希望通过编程领域成熟的技术理论来解决云原生领域的配置代码化的问题。\n1. KCL语言的诞生背景 在经典的 Linux/UNIX 操作系统中，我们通过 Shell 和系统内置的各种工具和内核进行交互，同时通过 Shell 脚本来管理更上层的 App。可以说 Shell 语言极大地简化了内核的编程界面，不仅仅提升了操作系统易用性也简化了上层 App 的管理和运维，也提高了生产效率。而 Kubernetes 作为容器管理领域的事实标准，已经成为云计算时代的Linux/UNIX。类比 UNIX 系统，Kubernetes 目前还缺少一种符合其声明式、开放、共享设计理念的交互语言及工具。\n 1.1 为何要设计KCL语言？ K8s已经成为云计算的操作系统，但是目前尚缺少功能完备的SHELL交互界面。目前虽然有很多而且开源方案，但是还没有像UNIX的Shell那种出现比较成熟的方案，特别是尚无法满足头部互联网企业大规模工程化的要求。云原生技术与企业落地之间存在Gap需要填补，这正是云原生工程化要解决的问题，也是设计KCL语言的出发点。\n1.2 目前是一个好时机 云原生的思路是高度的开放化和民主化，结果就是万物可配置，一切配置都是代码。带配置代码面前人人平等，每个用户都可以通过调整配置代码和基础平台设施进行交互。因此对配置的编写和维护正在成为云计算时代软件工程师的必备的技能和需求。基于对云原生配置代码化需求的日益旺盛，硅谷的诸多头部公司已经对这个方向进行了大规模的实践和验证，这些都给了我们大量可以参考的经验。\n因此蚂蚁的 Kusion 项目尝试通过 KCL 配置策略语言正是为了简化云原生技术设施的接入方式设计，其设计目标不仅仅是为了提升蚂蚁基础设施的开放程度及使用效率，同时希望能够优化共享、协同的开发流程，可以说其定位正是云原生时代的 Shell 语言。虽然目前还处于探索和实践阶段，我们通过此文和大家分享下 KCL 语言的设计与实现的一些理念，为云原生的快速到来贡献一点绵薄之力。\n1.3 KCL诞生历史 KCL 语言从2019年开始初期的调研和设计工作。到2020年3月发布kcl-0.1，基于Python定制语法，采用Go版本的Grumpy和AntLR等工具开发。2020年下半年改用Python语言并加快了开发和迭代速度，发布的kcl-0.2.x引入了大量语言特性、增加了Plugin扩展支持、同时支持IDEA插件。2021年上半年开始统一优化和整合语言特性，发布的kcl-0.3优化类型系统、集成单元测试工具、优化执行性能并提供了Go等多语言的API支持、同时通过LSP为VSCode提供支持。2021年下半年开始在建站等常见落地，同时引入静态类型检查和优化性能，完善语言的文档支持。\n2. KCL语言的设计原则 基于蚂蚁践行多年的经典运维中台沉淀的经验和对各种问题利弊的思考，Kusion 项目对如何充分利用云原生技术带来的红利，打造一个开放、透明、声明式、可协同的运维体系进行了探索和思考，提出并实践了基于基础设施代码化的云原生协同开发的模型。而 KCL 语言正是 Kusion 项目为了解决云原生协同开发而设计的声明式的配置编程语言，简单、稳定、高效和工程化是 KCL 语言设计的设计理念。\n 2.1 简单为王 简单不仅仅可以降低学习和沟通的成本，而且可以减少代码出问题的风险。不论是 UNIX 奉行的 KISS 原则还是 Go语言推崇的 Less is more 设计理念，简化易用的界面始终是各种成功产品追求的一个目标。同样从简单原则出发，KCL 语言在参考现代编程语言之上只保留了必要的元素，同时通过类型自动推导、引入受限的控制流和 schema 提供了基础灵活的配置定义编写能力，删减语言特性始终是 KCL 语言设计工作的一个重要目标。\n2.1.1 声明式语法 声明式编程是和命令式编程并列的一种编程范式，声明式编程只告诉你想要的结果，执行引擎负责执行的过程。声明式编程使用更加简单，可以降低命令式拼装造成的复杂性和副作用，保持配置代码清晰可读，而复杂的执行逻辑已经由 Kubernetes 系统提供支持。KCL 语言通过简化对 schema 结构体实例化的语法结构对声明式语法提供支持，通过仅提供少量的语句来减少命令过程式编程带来的复杂性。 围绕 schema 和配置相关的语法，KCL 希望每种配置需求尽可能通过固定的写法完成，使得配置代码尽可能的统一化。\n比如作为 KCL 声明式语法的核心结构 schema 可以采用声明式方式实例化：\nschema Name: firstName: str lastName: str schema Person: name: Name = { firstName: \u0026amp;quot;John\u0026amp;quot; lastName: \u0026amp;quot;default\u0026amp;quot; } JohnDoe = Person { name.lastName: \u0026amp;quot;Doe\u0026amp;quot; } 首先通过schema定义了一个 Name 结构，结构包含2个字符串类型的必填属性。然后在 Person 中复用 Name 类型声明一个name属性，并且给name属性设置了默认值以简化用户使用。最终 …","date":1627974000,"description":"KCL：声明式的云原生配置策略语言","dir":"blog/kcl-a-declarative-cloud-native-configuration-policy-language/","fuzzywordcount":8200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"30b5034f7ce40b32a13a09cfe141b101","permalink":"https://sofastack.github.io/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","publishdate":"2021-08-03T15:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","summary":"楔子: 以蚂蚁典型的建站场景为例，在接入 Kusion 后，用户侧配置代码减少到 5.5%，用户面对的 4 个平台通过接入统一代码库而消减，在无其他异常的情况下交","tags":["SOFAStack"],"title":"KCL：声明式的云原生配置策略语言","type":"blog","url":"/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","wordcount":8120},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张鹏 提问：\n 比如我在新模块中添加 Service 实现，宿主应用没有调用相关的 Service 啊，我其实想实现代码的热部署通过 SOFAArk 可以？\n A：可以动态部署的（所有的 bean 会刷新，服务会发布），跟宿主应用有没有调用没有关系的。\nSOFAArk：https://github.com/sofastack/sofa-ark\n2、@周永平 提问：\n 我想请教下，SOFABoot 如果使用 Spring 的 event，跨模块会被通知到吗？\n A：默认情况下，Spring 事件只在本模块中，不会传递的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@孙力 提问：\n 蚂蚁内部与 MOSN 对应的应该是有统一的控制面吗？其中熔断限流组件是使用的 sentinel 吗？控制面与 MOSN 中的 sentinel-client 对接更新限流规则，使用的 sentienl 的 dynamic-rule，还是 xds 下发的？\n A：我们内部是有统一的控制面的，我们的限流熔断算法是基于 sentinel 去扩展实现的，底层的限流框架是基于 sentinel 的，更新规则时我们用的是我们内部的一套配置管理中间件。\nMOSN：https://github.com/mosn/mosn\n4、@孟晓冬 提问：\n 目前的问题是，Dubbo 应用在注入 MOSN 时，MOSN 启动时，要么报权限问题，要么报各种 not support，想请教一下是什么原因？\n A：你用的 1.7.x 的 Istio 的话，那要用对应分支的 MOSN 版本镜像。\nMOSN：https://github.com/mosn/mosn\n本周发布 本周 Layotto 发布了 v0.1.0\n这是 Layotto 的第一次发布，包含功能：\n 支持 configuration API\n 支持 pubsub API\n 支持 state API\n 支持 distributed lock API\n 支持 sequencer API\n 支持 rpc API\n 支持通过 4 层或者 7 层进行流量治理（例如 dump 流量,限流等功能)\n 支持 Actuator API，用于健康检查和运行时元数据查询\n 支持集成 Istio\n 支持基于 WASM 进行多语言编程\n Go sdk\n 感谢各位贡献者这段时间的付出！\n详细参考：https://github.com/mosn/layotto/\n文章解读： https://mosn.io/layotto/#/zh/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/index\n本周 SOFABoot 发布了 3.8.0 版本。主要更新如下：\n 支持 JDK11\n 添加 proxyBeanMethods=false 字段在 @Configuration 类上\n 调整 SOFARPC 注解的超时优先级\n 修复 Ark 环境处理注解时抛出 TypeNotPresentExceptionProxy 异常的问题\n 详细参考： https://github.com/sofastack/sofa-boot\n本周推荐阅读 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 还在为多集群管理烦恼吗？OCM来啦！\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1627628400,"description":"SOFA Weekly | Layotto、SOFABoot 发布新版本、QA 整理","dir":"blog/sofa-weekly-20210730/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa875b307e883aea56f46eab071f52d0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210730/","publishdate":"2021-07-30T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210730/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto、SOFABoot 发布新版本、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210730/","wordcount":1199},{"author":"祝辰（忘禅）","categories":"SOFAStack","content":" 开篇 这篇文章是基于SOFA Meetup合肥站的分享总结，主要针对于注册中心的定位以及功能介绍，通过对蚂蚁注册中心发展史的分析，带领大家了解，蚂蚁的注册中心是如何一步一步演变为现在的规模和特性的。\n更多深入的技术细节，欢迎大家加入到SOFA和SOFARegistry的社区中，探寻结果。\n注册中心是什么 服务发现 \u0026amp;amp; 服务注册 注册中心简单来说，是为了解决分布式场景下，服务之间互相发现的问题。\n如下图所示，服务A想要调用服务B的时候，需要知道B的地址在哪里，如何解决这个问题？\n 一般来说，分为两个点：\n 服务发现可以有一个中心化的组件或者说是存储，它承载了所有服务的地址，同时提供出来一个可供查询和订阅的能力，服务的消费方可以通过和这个中心化的存储交互，获取服务提供方的地址列表。 服务注册：同样是上文中中心化的组件，但是，这个时候的服务信息可以有两种措施 服务连接注册中心，同时上报自身的服务以及元数据（也是今天本文讲述的重点） 有一个集中的控制面（control plane）将用户定义的服务和IP的映射写入注册中心，例如AWS的CloudMap 调用流程 如上图所示，就是目前一种主流的注册中心模式，SOFARegistry和Nacos都是这种模式。\n 服务A，服务B通过SDK或者REST将自身的服务信息上报给注册中心 服务A需要调用服务B的时候，就对注册中心发起请求，拉取和服务B相关的服务IP列表以及信息 在获取到服务B的列表之后，就可以通过自身定义的负载均衡算法访问服务B 心跳 心跳是注册中心用于解决服务不可用时，及时拉出服务降低影响的默认方式，如下图所示\n 服务B的一个节点断网或是hang住，引发心跳超时；或是宕机、断链直接引发心跳失败 注册中心把问题节点从自身的存储中拉出（这里拉出根据具体实现：有的是直接删除，有的是标记为不健康） 服务A收到注册中心的通知，获取到服务B最新的列表 DUBBO 注册中心 下面通过DUBBO的例子，我们来看一下注册中心是如何使用的，以及流程\n首先，DUBBO在2.7和3.0中的配置略有不同，但是都是简单易懂的，这里都放上来\nDUBBO-2.7\n DUBBO-3.0\n 在RPC客户端只需要配置一个注册中心的地址即可，地址中包含了基础三元素\n protocol（协议类型）比如，zookeeper host port 基于此，dubbo的注册流程如下图所示\n 服务的生产方通过DUBBO客户端向注册中心（Registry）发起注册行为（register） 服务的消费方通过DUBBO客户端订阅信息（subscribe） 注册中心通过通知的方式，下发服务列表给服务消费方 注册中心的本质 通过前文的讲解，以及DUBBO组件的具体例子，我们大概可以归纳注册中心的本质\n“存储” + “可运维”\n 一方面，注册中心需要存储能力去记录服务的信息，比如应用列表 另一方面，注册中心在实践过程中，需要提供必需的运维手段，比如关闭某一服务流量 蚂蚁注册中心编年史 史前时代 史前时代的蚂蚁是相当久远的架构，当时所有的服务部署在同一台物理机上或者JVM上，服务之间不存在有跨机器调用的场景，这里略过不表\n 硬负载时代 后来，为了解决应用之间的耦合带来的部署难，运维难问题，我们对服务进行了拆分，拆分后的服务，遇到了一个问题，就是如何处理服务之间的调用关系，这个时候，蚂蚁用了两种硬负载 F5 或是 LVS。\n通过简单的4层代理，我们可以把服务部署在代理的后面，服务与服务之间通过代理互相访问，达到了跨机调用的目的\n 第一代注册中心 \u0026amp;ndash; 硬负载到软负载的演变 通过硬负载访问的方式，一方面解决了服务之间互相调用的问题，部署架构也简单易懂；另一方面，在业务快速增长之后，却带来了一定的问题：\n 单点的问题（所有调用都走F5的话，F5一旦挂了，很多服务会不可用） 容量问题（F5承载的流量太高，本身会到一个性能瓶颈） 这个时候，蚂蚁引进了阿里集团的一款产品叫ConfigServer，作为注册中心进行使用，这个注册中心的架构就和开头提到的架构很像了，服务之间可以通过IP直接访问，而降低了对负载均衡产品的强依赖，减少了单点风险。\n 第二代注册中心 \u0026amp;ndash; ScaleUp？ScaleOut？It\u0026amp;rsquo;s a problem 但是，问题还在持续，那就是注册中心，本身是一个单点，那么，他就会继续遇到上文中所说的两个问题\n 单点风险（注册中心本身是单机应用） 容量瓶颈（单台注册中心的连接数和存储数据的容量是有限的） 解决的方式有两种\n scale-up（淘宝）：通过增加机器的配置，来增强容量以及扛链接能力；同时，通过主-备这样的架构，来保障可用性 scale-out（蚂蚁）：通过分片机制，将数据和链接均匀分布在多个节点上，做到水平拓展；通过分片之后的备份，做到高可用 蚂蚁和淘宝走了两条不同的路，也推进了蚂蚁后面演进出一套独立的生态系统\n蚂蚁的演进架构如下，产生了两种不同的应用节点\n session节点，专门用来抗链接使用，本身无状态可以快速扩展，单机对资源的占用很小 data节点，专门用来存储数据，通过分片的方式降低单个节点的存储量，控制资源占用 第五代注册中心 \u0026amp;ndash; Meta节点的诞生 上面的架构已经很符合目前主流的分布式架构了，但是在运维过程中，产生了一系列问题，比如\n 所有data都是分布式的，data之间的服务发现需要通过启动时给定一个配置文件，这样就和标准运维脱钩 data节点的上下线需要去及时修改配置文件，否则集群重启会受到影响 分布式存储一致性问题，每次迭代发布，需要锁定paas平台，防止节点变动带来的不一致 所有这些问题的产生，我们发现可以引入一个元数据管理中心（Meta）节点来，解决对data和session管理的问题，data和session通过4层负载或是7层负载对meta访问即可.\n对比业界的解决方案，都有类似的模型，比如HDFS的Name Node、Kafka依赖于ZK，Oceanbase依赖于RootServer 或者 配置中心Apollo依赖于Euraka。\nMeta节点的出现，缓解了手工运维注册中心的瓶颈，但是，依然没有从根本上解决问题，那么问题在哪里？详见下文分析。\n 第六代注册中心 \u0026amp;ndash; 面向运维的注册中心 上文说道，Meta节点的出现，承接了Data以及Session之间服务发现的问题，但是，丛云未测来讲，还是有很多问题解决不了，比如\n Data节点的发布在数据量大的前提下，依然是个痛点 Session节点的新加节点上，可能很久都没有流量 等等，对于这些问题，在SOFARegistry5.x的基础上，我们快速迭代了6.0版本，主要是面向运维的注册中心。\nData节点发布难的问题，说到底是一个影响范围的问题，如何控制单一data节点发布或者挂掉对数据的影响面，是解决问题的本源，这里我们采用了两个措施\n 改进数据存储算法（consistent-hash -\u0026amp;gt; hash-slot） 应用级服务发现 存储算法的演进 之前我们使用了一致性hash的算法，如下图所示， …","date":1627369200,"description":"我们做出了一个分布式注册中心","dir":"blog/we-made-a-distributed-registry/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"991c52c34e8dc2370ae08263b297cbe0","permalink":"https://sofastack.github.io/sofastack.tech/blog/we-made-a-distributed-registry/","publishdate":"2021-07-27T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/we-made-a-distributed-registry/","summary":"开篇 这篇文章是基于SOFA Meetup合肥站的分享总结，主要针对于注册中心的定位以及功能介绍，通过对蚂蚁注册中心发展史的分析，带领大家了解，","tags":["SOFAStack"],"title":"我们做出了一个分布式注册中心","type":"blog","url":"/sofastack.tech/blog/we-made-a-distributed-registry/","wordcount":4390},{"author":"","categories":"SOFAStack","content":" 蚂蚁集团运维着可能是全球最大的 K8s 集群：K8s 官方以 5k node 作为 K8s 规模化的顶峰，而蚂蚁集团事实上运维着规模达到 10k node 规模的 K8s 集群。一个形象的比喻就是，如果官方以及跟着官方的 K8s 使用者能想象到的 K8s 的集群规模是泰山，那么蚂蚁集团在官方的解决方案之上已经实现了一个珠穆朗玛峰，引领了 K8s 规模化技术的提升。\n这个量级的差异，不仅仅是量的差异，更是 K8s 管理维护的质的提升。能维护有如此巨大挑战巨量规模的 K8s 集群，其背后原因是蚂蚁集团付出了远大于 K8s 官方的优化努力。\n所谓万丈高楼平地起，本文着重讨论下蚂蚁集团的在 K8s 的基石 \u0026amp;mdash; etcd 层面做出的高可用建设工作：只有 etcd 这个基石稳当了，K8s 这栋高楼大厦才保持稳定性，有 tidb 大佬黄东旭朋友圈佐证【图片已获黄总授权】。\n 面临的挑战 etcd 首先是 K8s 集群的 KV 数据库。 从数据库的角度来看，K8s 整体集群架构各个角色如下：\n etcd 集群的数据库\n kube-apiserver etcd 的 API 接口代理、数据缓存层\n kubelet 数据的生产者和消费者\n kube-controller-manager 数据的消费者和生产者\n kube-scheduler 数据的消费者和生产者\n etcd 本质是一个 KV 数据库，存储了 K8s 自身资源 、用户自定义的 CRD 以及 K8s 系统的 event 等数据。每种数据的一致性和数据安全性要求不一致，如 event 数据的安全性小于 K8s 自身的资源数据以及 CRD 数据。\nK8s 的早期拥护者在推广 K8s 时，宣称其比 OpenStack 的优势之一是 K8s 没有使用消息队列，其延迟比 OpenStack 低。这其实是一个误解，无论是 etcd 提供的 watch 接口，还是 K8s client 包中的 informer 机制，无不表明 K8s 是把 etcd 当做了消息队列，K8s 消息的载体很多，譬如 K8s event。\n从消息队列的角度来看，K8s 整体集群架构各个角色如下：\n etcd 消息路由器\n kube-apiserver etcd 生产者消息代理和消息广播【或者成为次级消息路由器、消费者代理】\n kubelet 消息的生产者和消费者\n kube-controller-manager 消息的消费者和生产者\n kube-scheduler 消息的消费者和生产者\n etcd 是推模式的消息队列。etcd 是 K8s 集群的 KV 数据库和消息路由器，充当了 OpenStack 集群中的 MySQL 和 MQ 两个角色，这样的实现貌似简化了集群的结构，但其实不然。在 large scale 规模 K8s 集群中，一般经验，首先都会使用一个单独 etcd 集群存储 event 数据：把 KV 数据和一部分 MQ 数据物理隔离开，实现了 KV 和 MQ 角色的部分分离。 如 参考文档 2 中提到美团 “针对 etcd 的运营，通过拆分出独立的 event 集群降低主库的压力”。\n当 K8s 集群规模扩大时，etcd 承载着 KV 数据剧增、event 消息暴增以及消息写放大的三种压力。 为了证明所言非虚，特引用部分数据为佐证：\n etcd KV 数据量级在 100 万以上；\n etcd event 数据量在 10 万以上；\n etcd 读流量压力峰值在 30 万 pqm 以上，其中读 event 在 10k qpm 以上；\n etcd 写流量压力峰值在 20 万 pqm 以上，其中写 event 在 15k qpm 以上；\n etcd CPU 经常性飙升到 900% 以上；\n etcd 内存 RSS 在 60 GiB 以上；\n etcd 磁盘使用量可达 100 GiB 以上；\n etcd 自身的 goroutine 数量 9k 以上；\n etcd 使用的用户态线程达 1.6k 以上；\n etcd gc 单次耗时常态下可达 15ms。\n 使用 Go 语言实现的 etcd 管理这些数据非常吃力，无论是 CPU、内存、gc、goroutine 数量还是线程使用量，基本上都接近 go runtime 管理能力极限：经常在 CPU profile 中观测到 go runtime 和 gc 占用资源超过 50% 以上。\n蚂蚁的 K8s 集群在经历高可用项目维护之前，当集群规模突破 7 千节点规模时，曾出现如下性能瓶颈问题：\n etcd 出现大量的读写延迟，延迟甚至可达分钟级；\n kube-apiserver 查询 pods / nodes / configmap / crd 延时很高，导致 etcd oom；\n etcd list-all pods 时长可达 30 分钟以上；\n 2020 年 etcd 集群曾因 list-all 压力被打垮导致的事故就达好几起；\n 控制器无法及时感知数据变化，如出现 watch 数据延迟可达 30s 以上。\n 如果说这种状况下的 etcd 集群是在刀锋上跳舞， 此时的整个 K8s 集群就是一个活火山：稍不留神就有可能背个 P 级故障， 彼时的整个 K8s master 运维工作大概是整个蚂蚁集团最危险的工种之一。\n高可用策略 实现一个分布式系统高可用能力的提升，大概有如下手段：\n 提升自身稳定性与性能；\n 精细管理上游流量；\n 保证服务下游服务 SLO。\n etcd 经过社区与各方使用者这么多年的锤炼，其自身的稳定性足够。蚂蚁人能做到的，无非是使出周扒皮的本事，提高集群资源整体利用率，scale out 和 scale up 两种技术手段双管齐下，尽可能的提升其性能。\netcd 自身作为 K8s 的基石，其并无下游服务。如果说有，那也是其自身所使用的物理 node 环境了。下面分别从 etcd 集群性能提升、请求流量管理等角度阐述我们在 etcd 层面所做出的高可用能力提升工作。\n文件系统升级 在山窝里飞出金凤凰，诚非易事。让 etcd 跑的更快这件事，没有什么手段比提供一个高性能的机器更短平快地见效了。\n1.使用 NVMe ssd etcd 自身 = etcd 程序 + 其运行环境。早期 etcd 服务器使用的磁盘是 SATA 盘，经过简单地测试发现 etcd 读磁盘速率非常慢，老板豪横地把机器鸟枪换炮 \u0026amp;mdash; 升级到使用了 NVMe SSD 的 f53 规格的机器：etcd 使用 NVMe ssd 存储 boltdb 数据后，随机写速率可提升到 70 MiB/s 以上。\n参考文档 2 中提到美团 “基于高配的 SSD 物理机器部署可以达到日常 5 倍的高流量访问”，可见提升硬件性能是大厂的首选，能折腾机器千万别浪费人力。\n2.使用 tmpfs NVMe ssd 虽好，理论上其读写极限性能跟内存比还是差一个数量级。我们测试发现使用 tmpfs【未禁止 swap out】替换 NVMe ssd 后，etcd 在读写并发的情况下性能仍然能提升 20% 之多。考察 K8s 各种数据类型的特点后，考虑到 event …","date":1627282800,"description":"蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路","dir":"blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"49c1cbed799517497d7760e5717c5843","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","publishdate":"2021-07-26T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","summary":"蚂蚁集团运维着可能是全球最大的 K8s 集群：K8s 官方以 5k node 作为 K8s 规模化的顶峰，而蚂蚁集团事实上运维着规模达到 10k node 规模的 K8s 集群。一个形象的比喻就是","tags":["SOFAStack"],"title":"蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路","type":"blog","url":"/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","wordcount":7144},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践\n 活动时间：2021 年 07 月 24 日（周六）13:30-17:30\n 活动地点：合肥高新区创新产业园D8栋一楼集思空间\n 活动形式：线下活动\n 资料下载： 《蚂蚁注册中心 SOFARegistry 分享》 《基于API 网关的微服务治理演进与架构实践》 《蚂蚁集团分布式链路组件 SOFATracer 原理与实践》 《准实时的日志聚合平台》 《Service Mesh在蚂蚁集团的实践》\n 本次分享涉及的项目地址\n sofa-registry开箱即用计划 https://github.com/sofastack/sofa-registry/projects/5\nsofa-registry深度解析计划 https://github.com/sofastack/sofa-registry/projects/4\n(这两个计划想帮助对参与开源项目感兴趣的同学由浅入深的上手，成为社区的一员)\nsofa-tracer https://github.com/sofastack/sofa-tracer\nmosn https://github.com/mosn/mosn\n活动介绍 活动议程 本期议题以及嘉宾详解 《蚂蚁注册中心 SOFARegistry 分享》\n嘉宾介绍\n祝辰（花名忘禅），蚂蚁集团技术专家，2020年加入蚂蚁集团致力于服务发现领域的技术建设，开源项目sofa-registry、x-pipe核心开发人员。\n议题简介\n大规模微服务场景下的注册中心：SOFARegistry v6 新特性介绍 SOFARegistry 是蚂蚁集团内部在使用的服务注册中心，它支撑起了蚂蚁集团海量规模的业务服务。 但随着蚂蚁集团业务规模的日渐庞大，SOFARegistry 在资源、容量、运维等方面也遇到了一些挑战，针对这一系列的挑战，我们对 SOFARegistry 进行了大量的改造，开发了 v6 版本的 SOFARegistry。\n项目地址\nsofa-registry开箱即用计划 https://github.com/sofastack/sofa-registry/projects/5\nsofa-registry深度解析计划 https://github.com/sofastack/sofa-registry/projects/4\n(这两个计划想帮助对参与开源项目感兴趣的同学由浅入深的上手，成为社区的一员)\n听众收获\n1、全面了解不同注册中心的设计及架构；\n2、深入了解千万级别微服务场景下服务发现的问题和解法。\n《基于API 网关的微服务治理演进与架构实践》\n嘉宾介绍\n王晔倞，现任API7 VP，Apache APISIX Contributor。公众号「头哥侃码」作者，曾在好买财富、大智慧、中通服软件、东方购物任职，21年IT从业经验，对技术管理和架构设计有一定的经验。TGO 鲲鹏会上海理事会成员，腾讯云TVP，QCon北京2017明星讲师，QCon北京2018优秀出品人。\n议题简介\n内容讲述随着业务的发展，规模扩大，服务颗粒越来越细，数量也越来越多。 我们在过程中有过很多经验和探索，并将系统从一个服务于单个业务方的后台系统逐渐改造成为一个支持海量内容，服务多个业务方，业务规则复杂多变的微服务治理架构。 通过API网关，我们有效协调线上运行的各个服务，保障服务的SLA。基于服务调用的性能KPI数据进行容量管理，并通过对技术中台的升级，对故障进行降级、熔断、限流等一系列升级。\n听众收获\n1、微服务治理当前面临的问题；\n2、API网关在微服务治理中的价值；\n3、从“单体“到”微服务“的转型过程中，该如何使用API网关实现微服务治理。\n《蚂蚁集团分布式链路组件 SOFATracer 原理与实践》\n嘉宾介绍\n郑志雄（花名纶珥），SOFABoot 开源负责人，主要负责蚂蚁集团应用研发框架的开发。\n议题简介\n当下的微服务技术架构，应用的各种服务通常都比较复杂、分布在不同的机器上；同时，这些应用可能又构建在不同的软件模块上，这些软件模块有可能是由不同的团队开发，可能使用不同的编程语言来实现、有可能部署了几千台服务器。为了能够分析应用的线上调用行为以及调用性能，蚂蚁金服基于 OpenTracing 规范，提供了分布式链路跟踪 SOFATracer 的解决方案，帮助理解各个应用的调用行为，并可以分析远程调用性能的组件。\n项目地址\nhttps://github.com/sofastack/sofa-tracer\n听众收获\n1、了解微服务场景下分布式链路组件的作用及价值；\n2、了解蚂蚁集团 SOFATracer 组件的基本原理。\n《准实时的日志聚合平台》\n嘉宾介绍\n吕思泉是思科 Webex 产品线 MATS（媒体分析与问题诊断服务）团队的技术专家，热爱开源，热爱分享，热爱生活，在MATS团队主要工作方向为基础技术的研究与应用，在分布式系统和微服务方面有丰富的经验，由其本人编写并开源的jgossip项目解决了MATS分布式Job Engine的水平扩展难题，由其本人研究并实践的基于Loki+Promtail+Grafana的日志平台大幅度提高了MATS团队在分布式系统日志管理与监控方面的效率。\n议题简介\n简要介绍基于 Loki 的日志可视化套件，以及思科内部如何使用该技术进行监控和告警。\n听众收获\n通过讲师介绍，大家可以了解到一种轻巧灵活的日志聚合系统，帮助开发人员快速定位问题以及实时了解系统状况。\n《Service Mesh 在蚂蚁集团的实践》\n嘉宾介绍\n李唯（良恩），蚂蚁集团技术专家。2017 年加入蚂蚁集团中间件团队。参与了 Service Mesh 在蚂蚁的落地建设，目前主要负责 MOSN 在蚂蚁内部的设计开发。\n议题简介\n随着业务发展，越来越多公司选择了微服务架构，它帮助业务解决了很多问题，但是在实践过程中也不免会遇到一些问题。在这些利与弊的权衡之中，Service Mesh 能够帮助到我们什么呢？本次内容分享 Service Mesh 在微服务的实践中解决的一些问题以及其背后的思考。\n项目地址\nhttps://github.com/mosn/mosn\n听众收获\n1、了解 Service Mesh 在微服务中的实践场景和意义；\n2、了解 Service Mesh 在蚂蚁实践中为业务带来的价值。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1627110000,"description":"SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践","dir":"activities/sofa-meetup-8/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4f05d75ae1c87e74010079dc175e3420","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-8/","publishdate":"2021-07-24T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-8/","summary":"概要 活动主题：SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践 活动时间：2021 年 07 月 24 日（周六）13:30-17:30 活动地点","tags":["SOFAMeetup"],"title":"SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-8/","wordcount":2084},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@王辉 提问：\n SOFARegistry 的 data 节点，连接 meta 节点，为什么设计成随机选择一个节点连接，如果 meta 节点 3 个节点，其中有一个节点挂了，而 data 节点又随机选择到这个挂的节点，就启动失败了。\n A：通过 slb 查询到主节点，然后所有的 session 和 data 都连接 meta 主节点。不是随机连接一个 meta。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n2、@刚刚 提问：\n SOFARPC 是通过 MOSN 转发协议？SOFARPC 对外注册的 IP 在 k8 的容器是什么策略？\n A：MOSN 支持 SOFARPC 协议的转发。服务发布订阅没有做啥特殊的，就和原来是一样的。\nMOSN：https://github.com/mosn/mosn\n3、@证道者 提问：\n Layotto 中 wasm 是怎么设置 cpu 和内存的？\n A：目前官方提供的 Wasm 运行时还不支持对 cpu 内存等资源进行限制，不过我们已经在跟 WasmEdge 社区沟通了，他们是可以支持这种场景的，所以后面同时会支持 WasmEdge 作为 Layotto 的 Wasm 运行时。\nLayotto：https://github.com/mosn/layotto\n3、@Q 提问：\n 两个 tc 节点，就有两套 global，branch，lock 表，当一个事物的调用链中，不同的 rm 连接的是不同的 tc 节点时，是不是会在各自 tc 的 branch 表里生成分支事物啊，这个时候怎么保证一致性呢？\n A：tc 集群无状态的，共用一套 db 数据。\nSeata：https://github.com/seata/seata\n本周推荐阅读 RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n 还在为多集群管理烦恼吗？OCM来啦！\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1627023600,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210723/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2d78986f9ca335444ed265e7bfac0648","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210723/","publishdate":"2021-07-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210723/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210723/","wordcount":972},{"author":"","categories":"SOFAStack","content":" 作者简介：冯泳（花名鹿惊），资深技术专家，拥有西北工业大学计算机科学博士学位，在高性能计算，大数据和云计算领域拥有十多年的设计开发经验，专注于调度，资源和应用管理领域。也深度参与相关开源项目的开发和商业化，例如 OpenStack, Mesos, Swarm, Kubernetes, Spark 等，曾在 IBM 领导过相关的开发团队。\n 前言 在云计算领域如果还有人没听过 Kubernetes，就好像有人不知道重庆火锅必须有辣椒。Kubernetes 已经像手机上的 Android，笔记本上的 Windows 一样成为管理数据中心事实上的标准平台了。围绕着 Kubernetes，开源社区构建了丰富的技术生态，无论是 CI/CD、监控运维，还是应用框架、安全反入侵，用户都能找到适合自己的项目和产品。可是，一旦将场景扩展到多集群、混合云环境时，用户能够依赖的开源技术就屈指可数，而且往往都不够成熟、全面。\n为了让开发者、用户在多集群和混合环境下也能像在单个 Kubernetes 集群平台上一样，使用自己熟悉的开源项目和产品轻松开发功能，RedHat 和蚂蚁、阿里云共同发起并开源了 OCM（Open Cluster Management）旨在解决多集群、混合环境下资源、应用、配置、策略等对象的生命周期管理问题。目前，OCM 已向 CNCF TOC 提交 Sandbox 级别项目的孵化申请。\n项目官网：https://open-cluster-management.io/\n 多集群管理发展历史 让我们把时间拉回到几年前，当业界关注/争论的焦点还在 Kubernetes 是否生产级可用的时候，就出现了最早一批登陆“多集群联邦“技术的玩家。它们大都是体量上远超平均水准的 Kubernetes 实践先驱，从最早 Redhat、谷歌入场做了 KubeFed v1 的尝试，再到后来携手 IBM 吸取经验又推出 KubeFed v2。除了这些大型企业在生产实践 Kuberentes 的场景中探索多集群联邦技术，在商业市场上，各个厂商基于 Kubernetes 包装的服务产品也大多经历了从单集群产品服务到多集群形态、混合云场景进化的过程。其实，无论是企业自身还是商业用户都有共性的需求，聚焦在以下几个方面：\n多地域问题：当集群需要在异构基础设施上或者横跨更广地域进行部署\nKubernetes 集群依赖 etcd 作为数据持久层，而 etcd 作为分布式系统对系统中各个成员之间的网络延迟上有要求，对成员的数量也有一些限制，虽然在延迟能够容忍的情况下可以通过调整心跳等参数适配，但是不能满足跨国跨洲的全球性部署需求，也不能保证规模化场景下可用区的数量，于是为了让 etcd 至少可以稳定运行，一般会按地域将 etcd 规划为多个集群。此外，以业务可用和安全性为前提，混合云架构越来越多地被用户接受。跨越云服务提供商很难部署单一 etcd 集群，随之对应的，Kubernetes 集群也被分裂为多个。当集群的数量逐渐增多，管理员疲于应对时，自然就需要一个聚合的管控系统同时管理协调多个集群。\n规模性问题：当单集群规模性遇到瓶颈\n诚然，Kubernetes 开源版本有着明显的规模性瓶颈，然而更糟糕是，我们很难真正量化 Kubernetes 的规模。社区一开始提供了 kubemark 套件去验证集群的性能，可是现实很骨感，kubemark 所做的事情基于局限于在不同节点数量下反复对 Workload 进行扩缩容调度。可是实践中造成 Kubernetes 性能瓶颈的原因复杂、场景众多，kubemark 很难全面客观描述多集群的规模性，只能作为非常粗粒度下的参考方案。后来社区支持以规模性信封来多维度衡量集群容量，再之后有了更高级的集群压测套件 perf-tests。当用户更清晰地认识到规模性的问题之后，就可以根据实际场景（比如 IDC 规模、网络拓扑等）提前规划好多个 Kubernetes 集群的分布，多集群联邦的需求也随之浮出水面。\n容灾/隔离性问题：当出现更多粒度的隔离和容灾需求\n业务应用的容灾通过集群内的调度策略，将应用部署到不同粒度的基础设施可用区来实现。结合网络路由、存储、访问控制等技术，可以解决可用区失效后业务的连续性问题。但是如何解决集群级别，甚至是集群管理控制平台自身的故障呢？\netcd 作为分布式系统可以天然解决大部分节点失败的问题，可是不幸的是实践中 etcd 服务也还是可能出现宕机的状况，可能是管理的操作失误，也可能是出现了网路分区。为了防止 etcd 出现问题时“毁灭世界”，往往通过缩小“爆炸半径”来提供更粒度的容灾策略。比如实践上更倾向于在单个数据中心内部搭建多集群以规避脑裂问题，同时让每集群成为独立的自治系统，即使在出现网络分区或者更上层管控离线的情况下可以完整运行，至少稳定保持现场。这样自然就形成了同时管控多个 Kubernetes 集群的需求。\n另一方面，隔离性需求也来自于集群在多租户能力上的不足，所以直接采取集群级别的隔离策略。顺带一提的好消息是 Kubernetes 的控制面公平性/多租户隔离性正在一砖一瓦建设起来，通过在 1.20 版本进入 Beta 的 APIPriorityAndFairness 特性，可以根据场景主动定制流量软隔离策略，而不是被动的通过类似 ACL 进行流量的惩罚限流。如果在最开始进行集群规划的时候划分为多个集群，那么隔离性的问题自然就解决了，比如我们可以根据业务给大数据分配独占集群，或者特定业务应用分配独占请集群等等。\nOCM 的主要功能和架构 OCM 旨在简化部署在混合环境下的多 Kubernetes 集群的管理工作。可以用来为 Kubernetes 生态圈不同管理工具拓展多集群管理能力。OCM 总结了多集群管理所需的基础概念，认为在多集群管理中，任何管理工具都需要具备以下几点能力：\n1.理解集群的定义；\n2.通过某种调度方式选择一个或多个集群；\n3.分发配置或者工作负载到一个或多个集群；\n4.治理用户对集群的访问控制；\n5.部署管理探针到多个集群中。\nOCM 采用了 hub-agent 的架构，包含了几项多集群管理的原语和基础组件来达到以上的要求：\n●通过 ManagedCluster API 定义被管理的集群，同时 OCM 会安装名为 Klusterlet 的 agent 在每个集群里来完成集群注册，生命周期管理等功能。\n●通过 Placement API 定义如何将配置或工作负载调度到哪些集群中。调度结果会存放在 PlacementDecision API 中。其他的配置管理和应用部署工具可以通过 PlacementDecisiono 决定哪些集群需要进行配置和应用部署。\n●通过 ManifestWork API 定义分发到某个集群的配置和资源信息。\n●通过 ManagedClusterSet API 对集群进行分组，并提供用户访问集群的界限。\n●通过 ManagedClusterAddon API 定义管理探针如何部署到多个集群中以及其如何与 hub 端的控制面进行安全可靠的通信。\n架构如下图所示，其中 registration 负责集群注册、集群生命周期管 …","date":1626764400,"description":"还在为多集群管理烦恼吗？OCM来啦！","dir":"blog/still-worried-about-multi-cluster-management/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"aef61122b990c692c05ed45907471ef8","permalink":"https://sofastack.github.io/sofastack.tech/blog/still-worried-about-multi-cluster-management/","publishdate":"2021-07-20T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/still-worried-about-multi-cluster-management/","summary":"作者简介：冯泳（花名鹿惊），资深技术专家，拥有西北工业大学计算机科学博士学位，在高性能计算，大数据和云计算领域拥有十多年的设计开发经验，专注","tags":["SOFAStack"],"title":"还在为多集群管理烦恼吗？OCM来啦！","type":"blog","url":"/sofastack.tech/blog/still-worried-about-multi-cluster-management/","wordcount":5878},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈拥军 提问：\n 我想求教一个问题，非 Spring 工程中使用 SOFARPC 的泛化调用是否可行？\n A：使用 SOFARPC 的 API 方式构造 泛化 Reference 就可以。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@孙明 提问：\n 请教大家，SOFARPC 可以相互依赖吗？比如 a 依赖 b，同时 b 也依赖 a。\n A：只要不是应用启动期的循环依赖，都是可以的。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n3、@周杰慧 提问：\n 请教个问题，使用 shardingsphere 与 Seata AT 模式结合，我看 Seata 源代码回滚时用主键更新，但对于数据库分片来讲更新时 where 条件需要带上分片的列，这样的话我应该怎么解决这个问题呢？\n A：看他们的 demo 来集成。\nSeata：https://github.com/seata/seata\n4、@Q 提问：\n eureka 做注册中心，TC 高可用时，如何在 TC 端覆盖 eureka 属性？\n A：在 seata\\conf 目录下新增 eureka-client.properties 文件，添加要覆盖的 eureka 属性即可。例如，要覆盖 eureka.instance.lease-renewal-interval-in-seconds 和 eureka.instance.lease-expiration-duration-in-seconds添加如下内容：\neureka.lease.renewalInterval=1\neureka.lease.duration=2\n属性前缀为 eureka，其后的属性名可以参考类 com.netflix.appinfo.PropertyBasedInstanceConfigConstants，也可研究 Seata 源码中的 discovery 模块的 seata-discovery-eureka 工程。\nSeata：https://github.com/seata/seata\n本周推荐阅读 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\n RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1626418800,"description":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210716/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cd4f09022c5b4338855eea46f50d5a9a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210716/","publishdate":"2021-07-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210716/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210716/","wordcount":993},{"author":"曾柯","categories":"SOFAStack","content":" 01 引言-TLS 1.3 协议及 SM 算法 说起 TLS，大家一定不会陌生，TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。自从 2014 年 Heartbleed 漏洞被发现以来，网络安全受人关注的程度越来越高，出于更安全更快捷的需求，TLS 1.3 协议也随之被提出，其相应的 RFC 于 2018 年正式发布。随着网络安全越来越受到重视，安全战略也逐步上升到国家战略的高度，国家密码局在 2010 年底公布了我国自主研制的“椭圆曲线公钥密码算法”（SM2 算法），并随后陆续发布了国密算法 SM1-SM9（SM 代表商密的拼音大写）。今天我们要分享的东西，就和 TLS 1.3 及国密有关。\n首先先让大家对这两者之间的关系有一个基本的概念，我们以一个典型的 TLS 1.2 中的密钥套件为例：\n 对应到我们的国密的算法上，则各个算法对应的套件如下：\n1、密钥交换算法：ECC-SM2，ECDHE-SM2（这里先不详细展开，只简单介绍一下，国密的密钥交换算法基于当前的椭圆曲线算法设计了两种专门的算法，而对应的曲线则是 SM2 曲线）；\n2、数字签名算法：SM2（SM2 既是签名算法的名称，同时在椭圆曲线算法中对应的曲线名也叫 SM2，有的博客文档里也将密钥交换算法称作 SM2，读者请注意不要混淆）；\n3、对称加密算法：SM4；\n4、hash 算法：SM3。\n也就是说，国密局针对安全握手各个阶段所需要的算法都出台了一份自主可控的算法。\n02 why 国密？why not 国密？ 先说说为什么要用国密，国密算法作为国密局的主力产品，肯定是在很多地方有优势的，先来总结下国密的典型优势：\n1、更安全：SM2 作为一种 ECC 算法（256 位）的安全性是要高于 2048 位的 RSA 的。同时 SM3 的摘要长度为 256 bit，安全强度也是要高于当时主流的 MD5 算法及 SHA1 算法的。\n2、更快速：在通讯过程中，256 位的 SM2 算法相比于 2048 位的 RSA 算法（国密算法在设计时，RSA2048 是主流签名算法，所以这里暂不讨论ECDSA等算法），可以传输更少的数据，也就意味着更少的传输时间，并且在理论上来说，SM2 签名算法的计算速度是要快过 RSA2048 不少的。\n3、自主可控：在目前这个国际形势下，这是最最最关键的一点！\n国密听起来像是中国密码的一次革新，但这些年却一直没有大面积推行开来，说明其本身肯定有一些问题的，这里抛开一些细节的小问题，谈一谈国密算法在大规模落地过程中遇到的一些比较棘手的问题：\n1.速度不够快（麻烦指数★★★）\n国密整个 TLS 会话流程中涉及到的几个算法，相对主流国际算法来说，大部分情况下性能均相对弱势，这里针对一些给出一些简单的性能对比表：\n对称加密算法性能对比：\n 签名算法性能对比：\n hash 算法性能对比：\n 从对比中我们可以看到，国密的这些算法目前和国际算法性能常常不在一个量级，无论是对称加密还是非对称加密的部分。究极根本原因，还是由于各种通用的国际算法普及程度太大，在工程上有着相应的多层次的优化（硬件计算和各种软加速手段），以对称加密为例：国密对称加密算法 SM4 对标的算法是 aes-128，从本身的加密原理上来看，SM4 在理论上不会和 aes-128 产生如此大的差距，然而 AES 由于普遍性实在太强，典型的 AES 实现都基于 Intel 的 SIMD 指令集对其进行了并行化加速，而 SM4 目前只有纯软的实现，性能上自然有不小的差距。不仅如此，目前的主流对称加密模式为 GCM 及 CCM 模式，其背后的思想为加密即认证技术（AEAD），而国密算法尚不支持这种模式，在安全性上也存在着一些弱点。\n2.需要双证书（★★★★）\n要把双证书讲清楚首先需要大家理解下 PKI 密钥协商机制，典型的密钥协商算法分为两种：RSA，ECDHE。国密的 ECC-SM2 密钥协商流程和 RSA 比较类似，算法核心的性质在于用公钥加密的数据可以用私钥解密，整个密钥协商流程简化如下图：\n 而 ECDHE-SM2 比较类似 ECDHE 算法，均是基于 DH 和 ECC 的算法，理解起来更加容易，流程简化如下图：\n 我们再来谈双证书这个事情，双证书分为签名证书和加密证书，这套体系的目的是满足国家对于敏感数据强管控诉求，即只要能抓到所有数据包，则管控机构则可以在理论上恢复出所有明文数据，由此催生出了加密证书这个东西，加密证书的私钥需要在专门的机构留底。我们来看 RSA 的密钥交换流程，只要拥有了私钥，则中间的密钥生成的材料（随机数）也就可以在理论上进行导出。而对于 ECDHE-SM2 来说，对称密钥的导出流程不仅仅只由随机数 a/c 来决定，同时也需要加密证书对应的私钥参与到计算中（具体流程比较繁琐，这里不展开，读者可参考 GM/T 0024 标准阅读详细的细节），也就意味着当私钥被监管，则对称密钥可以理论上被导出。\n这套体系很强悍，但难就难在目前所有主流密码库如 openssl，boringssl 都不支持，那么这也就意味着如果要推进这套体系的普适度，要么基于主流密码库开发，并推进开源社区接受，进而慢慢渗透到国内用户把这套体系用起来，要么在尽可能兼容目前密码体系的情况下开发一套新的密码库并强制国内用户替换，每一种办法都存在不小的难度。\n3.需要客户端也持有证书（★★★★★）\n国密在 GM/T 0024 标准里面定义了基于 ECDHE-SM2 算法的密钥交换流程，但这个算法的要求十分苛刻，必须要求 Client 也持有证书，的确这对于安全性有一定提升，但麻烦也就随之而来，支付宝的客户端目前没有证书，如果加上证书会让 App 更重，握手交互的数据更多，极大降低用户体验。这些问题还不够致命，如何管理海量的端上证书，才是真正令人头疼的麻烦。\n也许你会问：不用 ECDHE 不就好了嘛，但从技术的演进趋势来看，高效/安全是我们孜孜不倦的追求，而类 RSA 的握手流程则从根源上限制了国密 ECC 密钥交换流程无法演进到 1-RTT 握手，0-RTT 信息传输。不仅如此，ECHDE 的安全性及性能，也要好很多。在 TLS 1.3 的 1RTT 标准握手流程中，明确定义了废除 RSA 握手，只支持 ECDHE。目前这个情况就造成了一个死锁，想用 TLS 1.3-\u0026amp;gt;需要 ECDHE-\u0026amp;gt;需要 Client 有证书-\u0026amp;gt;没有证书且不想用证书-\u0026amp;gt;问题无解。\n03 重磅推出，TLS 1.3+ 国密算法套件 针对国密落地过程中的这些痛点问题，2019 年 8 月份，由蚂蚁的同学牵头，撰写了一份 TLS 1.3+ 国密算法 draft，并最终成为了一份 IETF 标准文档：\n 整个标准设计的核心思想是：整合目前国密算法优势，全面贴合国际上的安全技术思路，把不好用的东西先暂时剔除掉，提升国密算法在国内及国际上的影响力，从而让更多组织及个人参与到国密算法的使用和建设中来。基于这个思路，我们联合了 360 等公司，经过和国密局的多次沟通，正式推出了相关标准。在整个流程上，我们在 ECDHE 算法上取消了 Client 证书的要求，并暂时放 …","date":1626159600,"description":"RFC8998+BabaSSL---让国密驶向更远的星辰大海","dir":"blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"54dc71c8ea8dcfb0408a430934cb90c3","permalink":"https://sofastack.github.io/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","publishdate":"2021-07-13T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","summary":"01 引言-TLS 1.3 协议及 SM 算法 说起 TLS，大家一定不会陌生，TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。自从 2014 年 Heartbleed 漏洞被发","tags":["SOFAStack"],"title":"RFC8998+BabaSSL---让国密驶向更远的星辰大海","type":"blog","url":"/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","wordcount":3534},{"author":"王发康","categories":"SOFAStack","content":" 注：本文是王发康（毅松）在 2021 GopherChina 上演讲的文字稿，相关分享 PPT 可自行到 MOSN meetup 下载。MOSN meetup 地址；MOSN 官方 Github 地址；GitHub 地址。\n 前言 MOSN 在 Service Mesh 领域作为东西向服务治理网络在蚂蚁集团双 11 、春节红包等活动及开源社区都得到了一定实践。为了能够让社区用户更好的享受到这一技术红利，MOSN 从 2018 年开源以来在社区开发者、用户的共同努力下，使得 MOSN 在云原生演进方面做了很多探索和实践。比如 Istio 下另一个数据面 — MOSN、WebAssembly 在 MOSN 中的探索与实践、MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章、MOSN 基于 Sentinel 的限流实践、MOSN 中玩转 Dubbo-go 等周边生态展开合作。\n2021 年为了更好的为业务提效，MOSN 开启了将云原生进行到底的决心。本文介绍了 MOSN 在网络扩展层的思考和技术选型，以及最终是如何通过使用 Envoy 作为 MOSN 的网络层扩展，从而实现 MOSN 和 Envoy 生态打通。使得网络层具备 C++ 高性能的同时，上层业务治理能力也能借助 GoLang 进行高效的定制化开发。\n 面临的问题及挑战 一、社区生态，如何最大化求同存异 最近几年 Service Mesh 技术在云原生社区也是百花齐放，虽然 MOSN 在开源社区也是备受开发者的关注，但是 Envoy 经过长久的发展其社区的活跃度和用户量的积累这点是不可忽略的。另外选择 MOSN 的用户都是看重其二次开发的便捷性以及 GoLang 的生态丰富，选择 Envoy 的用户主要是看重其高性能的网络处理能力及社区的活跃度。那我们是否能够通过技术的手段将其二者优势融为一体，发挥各自的特长，不要让用户顾此失彼。\n二、单一的 Proxy，无法支撑其架构的演进 在 Proxy 层面，无论是 MOSN 还是 Envoy 都是在各自领域中发挥优势。随着云原生技术的快速发展和成熟以及业务的增长，既要 Proxy 能够具备高研发效能，还要具备高处理性能，而单一的 Proxy 已经无法满足当前业务架构上的持续演进。\n东西向和南北向数据面 Proxy 逐步统一：两套数据面定位不同但功能上存在一定重叠，导致维护成本高，未来需要逐步收敛。这就要求 Proxy 不仅具备易扩展性方便业务方扩展东西向业务上的流量治理能力，而且还要具备抗高并发的能力满足南北向高流量转发。\nService Mesh 部署形态逐步向 Node 化架构演进：Service Mesh 规模化后，由于多出的 Proxy 势必会导致一定资源上的浪费，那在中心化和 Mesh 化之间做一次折中，即通过 Node 化部署形态来解决。Node 化后就要求 Proxy 能够高效、稳定的承载多个 POD 的流量治理。\nService Mesh 需要同时具备 Application Runtime 能力：虽然 Service Mesh 解决了微服务治理的痛点，但在实际业务开发中，缓存、数据库、消息队列、配置管理等，仍然需要维护一套重量级的 SDK 并且侵入应用代码。目前业界的解决方案是在 Service Mesh 的基础上多引入一个 Proxy 如 Dapr 来解决，这就导致应用的 POD 需要维护多个容器，所以如何让 Service Mesh 的 Proxy 具备快速复用 Dapr 能力成为解决该问题的关键。\n我们的思考 针对上述问题分析过后，其实背后的原因是有共性的。比如将其统一为一个 sidecar，如果单纯的从一个数据面改为另一个，那其中的改造成本是巨大的。那是否可以换个思路，为 MOSN 的网络层增加可扩展性，即可以让 MOSN 的网络处理直接下沉至 Envoy，同时将这个能力剥离出来成为 Envoy 在 GoLang 上的一个标准能力，这样就能够让 Envoy 和 MOSN 互相复用已有的能力。二者相互融合，各取所长，使其同时具备高研发效能和处理性能高，自然而然就解决上述“单一的 Proxy，无法支撑架构的演进”和“社区生态，如何最大化求同存异”所面临的问题。相互融合后，不仅融合了各种的优势，而且也能够把两边的生态打通，借此 MOSN 社区和 Envoy 社区能形成双赢的局面。\n 方案调研与分析 知道当前面临问题的原因后，便有了一个宏观的解决方向。于是就对此展开了相关调研，梳理了业界针对此问题的一些解决方案，综合各种方案的优劣势并结合蚂蚁业务现状以及开源社区用户的痛点进行了分析和评估。\n扩展方案调研\n 扩展方案评估\n 通过上述方案优劣势的对比以及评估，MOE（MOSN on Envoy） 相比 ext-proc 无需跨进程 gRPC 通信，性能高，易管理；相比 Envoy WASM 扩展无需网络 IO 操作转换成本；相比 Lua 扩展生态好、能复用现有的 SDK，对于处理上层业务更合适。\n同时我们将 Envoy 中增加 GoLang 扩展的这个方案也在 Envoy 社区进行了讨论，也得到了 Envoy 社区 Maintainer 的赞同。其中依赖的技术 CGO 是 GoLang 官方出品，该技术基本上在 GoLang 每个 release notes 中都有提到，说明也一直在维护的。另外业界也有很多项目在使用这项技术（比如：NanoVisor、Cilium、NginxUnit、Dragonboat、Badger、Go withOpenCV etc）其稳定性已经过一定的考验了，同时我们自己也测试了 CGO 自身的开销在 0.08 ~ 1.626 微秒，而且调用开销也是属于线性增长而非指数增长趋势。\n 所以综合稳定性、性能、改造成本以及社区生态等因素评估，MOE 解决方案无论在当前阶段还是未来都具备一定优势。\n方案介绍 一、整体架构 如下是 MOE 的整体架构图，最下面是各种高性能数据面，目前我们主要适配的是 Envoy。在数据面之上剥离了一层 GoLang L7 extension filter 的抽象，用于和底层的数据面连通；然后在 MOSN 侧通过 GoLang L7 extension SDK 将 MOSN 连通；最后通过 CGO 这个通道将 Envoy 和 MOSN 打通。\n 整体架构如上图所示，其核心包括如下三部分组成：\n1、GoLang L4/L7 extension filter\n使用 C++ 实现的 Envoy 侧的 GoLang L4/L7 filter ，该模块通过 CGO API 来调用 GoLang 实现的 L4/L7 extension filter。\n2、GoLang L4/L7 extension SDK\nGoLang L4/L7 extension SDK 会导出一些 CGO API，用于 Golang L4/L7 extension filter 和 L4/L7 extension GoLang filter 交互。\n3、L4/L7 extension filter via GoLang\nL4/L7 …","date":1625554800,"description":"开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态","dir":"blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e570e9fb3aba7b066d2e3b332ae18dbc","permalink":"https://sofastack.github.io/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","publishdate":"2021-07-06T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","summary":"注：本文是王发康（毅松）在 2021 GopherChina 上演讲的文字稿，相关分享 PPT 可自行到 MOSN meetup 下载。MOSN meetup 地址；MOSN 官方 Github 地址；GitHub 地址。 前言 MOSN 在 Service Mesh","tags":["SOFAStack"],"title":"开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态","type":"blog","url":"/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","wordcount":5977},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@刘世杰 提问：\n 新接触 SOFABoot，有 2 个问题想请教一下： 1.如何根据不同的贡献方选择对应的扩展实现？贡献方有多个的情况下，覆盖了原始的对象，没看到如何根据身份定位具体实现的逻辑，不知道是遗漏了什么说明文档，我看的这个文档：https://www.sofastack.tech/projects/sofa-boot/extension/\n2.如何确保贡献方提供的 jar 包不对服务提供方产生影响？如果多个贡献方提供的 jar 包里间接依赖了不同版本的二三方的 jar 包。在同一个 classloader 下只能加载一个版本的 class，那对某些贡献方的逻辑处理可能会出现 NoClassDefFoundError 类的异常。SOFAArk 是具备了这种隔离的能力的，是否需要引入这种方式？\n A：1.如果有多个扩展点 x 的扩展地方，那么 A 的 registerExtension 就会被调用多次（与被扩展的次数一样，这个方法需要线程安全）；框架无法获知扩展者的身份，这个就需要扩展点提供方自行甄别。\n2.第二种情况，其实不仅限于 SOFABoot 中的扩展点，仅有一个 class loader 的情况下，会出现这种情况。个人认为在没有动态性要求的情况下，优先解决 maven 依赖冲突。\nSOFABoot：https://github.com/sofastack/sofa-boot\n2、@刘世杰 提问：\n 1.按照官网的 Demo，如果有多个贡献方 A、B、C，按照顺序执行了 registerExtension 方法，那 word 的值会以 C 为准吗？意思是不是说在运行时一个扩展点只有一个贡献方？\n2.如果贡献方比较多的话，这个后期的解决冲突的成本会不会比较高。还有些比较隐蔽的实现，可能不是太好测试出来，到生产才发现问题。另外，如果做动态的话在 SOFABoot 的技术栈里是扩展点 +Ark 的方式？\n A：1.这个顺序是没有保证的，SOFABoot 为了启动速度，并行化了上下文刷新的，因此可能是 A、B、C 顺序，也有可能是 C、B、A；运行时可以有多个实现的，这个取决于你的服务类型，以及如何实现的。\n2.可以这么理解，SOFAArk 就是一种动态扩展的方案。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@证道者 提问：\n MOSN mirror 功能是只能转发 Dubbo 的流量么？\n A：不是只能转发 Dubbo，都可以的。\nMOSN：https://github.com/mosn/mosn/\n本周推荐阅读 【感谢有你，SOFAer】一图看懂 SOFAStack 2021 半年报\n MOSN 多协议扩展开发实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1625209200,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210702/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5808aa4a754ad5a4024b619e1d61cba8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210702/","publishdate":"2021-07-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210702/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210702/","wordcount":1290},{"author":"永鹏","categories":"SOFAStack","content":" Service Mesh 是当今云原生的关键部分，蚂蚁已经在生产环境完成了大规模的落地，但是业界整体 Service Mesh 改造程度还不高。其中平稳的进行 Mesh 化改造是可以对已上线的业务进行 Mesh 化改造的前提，在平稳改造过程中，协议的支持又是最基础的部分。MOSN 提供的多协议扩展开发框架旨在降低使用私有协议的场景进行 Mesh 化改造的成本，帮助业务快速落地。\n MOSN 是蚂蚁自研的一款高性能网络代理，主要用于 Service Mesh 的数据面 Sidecar。Service Mesh，是近几年来云原生方向比较热门的话题，其主旨就是构建一个基础设施层，用来负责服务之间的通信。主要就是有一个和服务应用共同部署的 Sidecar 来实现各种中间件的基础能力，实现基础设施的标准化、和业务逻辑解耦，做到业务无感知的基础能力快速演进。目前国内很多公司都开始拥抱 Service Mesh，和蚂蚁合作的一些企业，如中信银行、江西农信等也基于 MOSN 完成了 Mesh 化的改造。\nService Mesh 架构的目的就是为了降低基础设施改造升级对业务造成的影响，但是如何平滑的从传统微服务架构转向 Service Mesh 架构也是一个非常有挑战的工作，这里涉及的细节很多，但是无论如何有一个最基础的问题就是我们在进行灰度 Mesh 化改造的时候，已经 Mesh 化的节点需要能和没有 Mesh 化的节点维持正常通信。而不同的公司选择的通信协议都有所不同，这就直接导致在技术选型的时候，选择的 Sidecar 需要能够支持所使用的协议。一些受到广泛应用的协议可能还会被陆续的支持，而有的协议可能还是公司自己定制的，因此不可避免的是需要基于 Sidecar 的扩展能力，进行二次开发以支持私有的协议。\n 多协议扩展框架 谈到 Service Mesh 的 Sidecar，就不得不提到 Envoy，这是一款被广泛应用的 Service Mesh Sidecar 代理。Envoy 的扩展框架支持开发者进行二次开发扩展，其中 Envoy 目前支持的不少协议就是基于其扩展框架开发实现的。在 Envoy 的扩展框架下，要扩展一个协议可以参考 Envoy 中 HTTP 协议处理的流程，包括 4 层 Filter 实现编解码部分与 Connection Manager 部分，在 Connection Manager 的基础上再实现 7 层的 Filter 用于支持额外的业务扩展、路由的能力、和 Upstream 的连接池能力。可以看到一个协议处理的流程几乎是贯穿了各种模块，实现一个协议扩展成本还是比较高的。\n 再来看一下 MOSN 的框架。MOSN 在一次协议处理上可以划分为四个层次，除开基本的从网络 IO 中获取数据的网络层以外，还可以划分为 protocol 层、stream 层与 proxy 层。其中 protocol 层负责协议解析相关编解码的工作，负责将数据流解析成 MOSN 可以理解的协议帧，或者将协议帧编码成二进制流；stream 层负责的内容就比较多了，包括处理不同的请求类型，初始化请求的上下文，关联事件，响应与请求之间的关联，还有 upstream 连接池相关的处理等，不同的协议处理的细节也会有所不同；proxy 层是一个协议无关的代理转发层，负责请求的路由与负责均衡等能力，同时也具备七层的扩展能力用于不同业务实现的扩展。根据这个架构，可以看到协议处理的核心就在于 protocol 层和 stream 层，相比于 Envoy 的设计来说，路由、七层扩展等部分是具备多协议复用的能力的。但是同时也可以看到 stream 层涉及的细节比较多，实现起来难度也是比较大的，为此 MOSN 在此基础上又提出了一个多协议扩展的框架，用于简化协议的实现。\n MOSN 的多协议框架主要就是针对 stream 层的复用扩展能力，在 MOSN 的协议处理分层设计中， network 层和 proxy 层在设计上就是协议无关可复用的，如果能做到 stream 层也进行复用，那么协议实现就只需要关注 protocol 层的编解码本身，实现难度就会大大降低了。那么 stream 层是不是具备可复用的能力的呢，我们认为对于大部分协议，尤其是 RPC 协议来说是可以的。首先我们对协议进行一个抽象，定义成 XProtocol 接口，表示任意的协议。每个协议实现都是实现一个 XProtocol 接口，它包括基础的编解码接口、一些特殊请求响应的构造接口（如心跳、异常）、还有协议的模型（如类似 HTTP 的 pingpong 模型，常见的 RPC 多路复用模型等），以及协议匹配的接口。所有的 XProtocol 协议实现通过 XProtocol Engine 关联起来，除了通过配置指定使用哪种协议进行处理以外，对于实现了协议匹配接口的协议来说，可以基于请求特征进行自动识别。然后我们对于 XProtocol 解析出的协议帧也进行统一的抽象，包括多路复用相关的接口、协议类型的判断（是请求，还是响应，或者是类似 Goaway 一类的控制帧，请求又可以细分为心跳请求、无响应的 oneway 请求等）、支持对协议帧的数据进行修改（Header/Body 的修改）、还有统一的状态码管理映射等。\n 在 MOSN 的协议处理分层机制下，以及有了以 XProtocol 和 XFrame 的抽象定义为核心的多协议扩展框架以后，我们在 stream 层就可以完全基于接口进行协议的处理，而不同的协议扩展实现者只需要专注于协议编解码本身，以及对编解码后的结果进行简单的接口适配，就可以完成在 MOSN 中的接入，由此获得 MOSN 中各种通用能力的支持，如限流扩展、路由引流等。对比 Envoy 中扩展协议实现部分可以看到是简化了不少的。当然 MOSN 这个多协议框架不能满足所有的协议情况，但是对于目前我们看到的大部分 RPC 协议，在配合上 proxy 层中七层 stream filter 扩展的基础上，都是可以很好的满足的。\n实践案例 下面以 MOSN 在社区合作伙伴中 Dubbo 协议落地的案例来详细的了解 MOSN 的多协议扩展。这里很多代码也是 MOSN 社区的同学贡献的。 在这个案例中，除了要求协议需要支持 Dubbo 以外，还希望使用像限流等这些基础的扩展能力，同时需要蓝绿分组等路由的能力，选择的控制面是 Istio，用于动态配置的下发。那这些需求在 MOSN 中是如何实现的呢？\n首先是协议解析部分，这里采用了基于开源的 dubbo-go 框架做协议实现，基于 dubbo-go 封装出了 MOSN 的 XProtocol 和 XFrame 模型；限流、xDS 等能力直接复用 MOSN 已有的实现，无需额外实现。但是这里有一个问题点就是 Istio 动态下发的路由配置是 HTTP 相关的，HTTP 的路由配置模型与 Dubbo 还是存在一定差异的，而修改 Istio 的成本会比较高，在这里就做了另外一层扩展。基于 MOSN 七层的 StreamFilters，在进行路由匹配之前对 Dubbo 协议进行定制化的处理，用来满足 HTTP 的 …","date":1624950000,"description":"MOSN 多协议扩展开发实践","dir":"blog/mosn-multi-protocol-extension-development-practice/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d5691b6aa90017e49d9726b702475306","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","publishdate":"2021-06-29T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","summary":"Service Mesh 是当今云原生的关键部分，蚂蚁已经在生产环境完成了大规模的落地，但是业界整体 Service Mesh 改造程度还不高。其中平稳的进行 Mesh 化改造是可以对已上线的业务","tags":["SOFAStack"],"title":"MOSN 多协议扩展开发实践","type":"blog","url":"/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","wordcount":4141},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@证道者 提问：\n 应用调用端多语言可以，Layotto 服务能力是不是目前只能 golang 开发，java 可以开发服务能力集成到 Layotto 里吗？还有就是 Layotto 底座是 MOSN 可以不用这个吗？我目前有一个需要处理，就是数据库单表 crud，跨表的 crud，自己分页检索这个能力可以用 Layotto 吗？\n A：如果想用别的语言给 Layotto 做扩展的话，目前感觉可行的方法就是借助 wasm，但具体的方案我们还得调研一下，目前是只能用 golang 开发。 至于你说的这个需求，可应该以作为 Layotto state API 的一种实现组件。\nLayotto：https://github.com/mosn/layotto\n2、@证道者 提问：\n 目前提供 pub/sub 能力，流 stream 能力，状态能力，以后也会将一些通用的业务能力抽象下移到 Layotto 吗？我觉得有点像组件化，面向能力编程。\n A：是的，主要就是希望业务同学可以面向能力编程，比如只需要考虑自己是否需要 pub/sub 能力就行，而不需要管背后是 kafka 还是 rocketMQ 之类的，我们目前在规划的有分布式锁、可观测性能力的下沉，其他的能力会参考社区的反馈。\nLayotto：https://github.com/mosn/layotto\n3、@证道者 提问：\n 所有的都在 Layotto 里面跑，pubsub PRC 不会相互干扰吗?\n A：你指的是资源使用上的互相争抢是吧，目前我们 Service Mesh 落地，Sidecar 也是集成的有 RPC 和 消息能力的，Sidecar 本身主要还是一个转发通道，本身资源占用还是极少的，目前生产上也没有因为同时 Run RPC 和 消息导致互相干扰的现象产生。在 Layotto 这也是类似的场景，大部分业务在单机维度很难跑到极限性能峰值，基本上不会有互相干扰的情况出现。\nLayotto：https://github.com/mosn/layotto\n本周推荐阅读 MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1624604400,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210625/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"edfd61aa9405dccf65be9b8703fa5a1f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210625/","publishdate":"2021-06-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210625/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210625/","wordcount":1070},{"author":"SOFAStack","categories":"SOFAStack","content":" 作者简介： 马振军，花名古今，在基础架构领域耕耘多年，对 Service Mesh 有深度实践经验，目前在蚂蚁集团中间件团队负责 MOSN、Layotto 等项目的开发工作。\n Layotto 官方 GitHub 地址:https://github.com/mosn/layotto\n点击链接即可观看现场视频：https://www.bilibili.com/video/BV1hq4y1L7FY/\nService Mesh 在微服务领域已经非常流行，越来越多的公司开始在内部落地，蚂蚁从 Service Mesh 刚出现的时候开始，就一直在这个方向上大力投入，到目前为止，内部的 Mesh 方案已经覆盖数千个应用、数十万容器并且经过了多次大促考验，Service Mesh 带来的业务解耦，平滑升级等优势大大提高了中间件的迭代效率。\n在大规模落地以后，我们又遇到了新的问题，本文主要对 Service Mesh 在蚂蚁内部落地情况进行回顾总结，并分享对 Service Mesh 落地后遇到的新问题的解决方案。\n一、Service Mesh 回顾与总结 A、Service Mesh 的初衷 在微服务架构下，基础架构团队一般会为应用提供一个封装了各种服务治理能力的 SDK，这种做法虽然保障了应用的正常运行，但缺点也非常明显，每次基础架构团队迭代一个新功能都需要业务方参与升级才能使用，尤其是 bugfix 版本，往往需要强推业务方升级，这里面的痛苦程度每一个基础架构团队成员都深有体会。\n伴随着升级的困难，随之而来的就是应用使用的 SDK 版本差别非常大，生产环境同时跑着各种版本的 SDK，这种现象又会让新功能的迭代必须考虑各种兼容，就好像带着枷锁前进一般，这样随着不断迭代，会让代码维护非常困难，有些祖传逻辑更是一不小心就会掉坑里。\n同时这种“重”SDK 的开发模式，导致异构语言的治理能力非常薄弱，如果想为各种编程语言都提供一个功能完整且能持续迭代的 SDK 其中的成本可想而知。\n18 年的时候，Service Mesh 在国内持续火爆，这种架构理念旨在把服务治理能力跟业务解耦，让两者通过进程级别的通信方式进行交互。在这种架构模式下，服务治理能力从应用中剥离，运行在独立的进程中，迭代升级跟业务进程无关，这就可以让各种服务治理能力快速迭代，并且由于升级成本低，因此每个版本都可以全部升级，解决了历史包袱问题，同时 SDK 变“轻”直接降低了异构语言的治理门槛，再也不用为需要给各个语言开发相同服务治理能力的 SDK 头疼了。\nB、Service Mesh 落地现状 蚂蚁很快意识到了 Service Mesh 的价值，全力投入到这个方向，用 Go 语言开发了 MOSN 这样可以对标 envoy 的优秀数据面，全权负责服务路由，负载均衡，熔断限流等能力的建设，大大加快了公司内部落地 Service Mesh 的进度。\n现在 MOSN 在蚂蚁内部已经覆盖了数千个应用、数十万容器，新创建的应用默认接入 MOSN，形成闭环。而且在大家最关心的资源占用、性能损耗方面 MOSN 也交出了一份让人满意的答卷： 1. RT 小于 0.2ms\n CPU 占用增加 0%~2%\n 内存消耗增长小于 15M\n 由于 Service Mesh 降低了异构语言的服务治理门槛，NodeJS、C++等异构技术栈也在持续接入到 MOSN 中。\n在看到 RPC 能力 Mesh 化带来的巨大收益之后，蚂蚁内部还把 MQ，Cache，Config 等中间件能力都进行了 Mesh 化改造，下沉到 MOSN，提高了中间件产品整体的迭代效率。\nC、新的挑战 应用跟基础设施强绑定 一个现代分布式应用，往往会同时依赖 RPC、Cache、MQ、Config 等各种分布式能力来完成业务逻辑的处理。\n当初看到 RPC 下沉的红利以后，其他各种能力也都快速下沉。初期，大家都会以自己最熟悉的方式来开发，这就导致没有统一的规划管理，如上图所示，应用依赖了各种基础设施的 SDK，而每种 SDK 又以自己特有的方式跟 MOSN 进行交互，使用的往往都是由原生基础设施提供的私有协议，这直接导致了复杂的中间件能力虽然下沉，但应用本质上还是被绑定到了基础设施，比如想把缓存从 Redis 迁移到 Memcache 的话，仍旧需要业务方升级 SDK，这种问题在应用上云的大趋势下表现的更为突出，试想一下，如果一个应用要部署在云上，由于该应用依赖了各种基础设施，势必要先把整个基础设施搬到云上才能让应用顺利部署，这其中的成本可想而知。 因此如何让应用跟基础设施解绑，使其具备可移植能力，能够无感知跨平台部署是我们面临的第一个问题。\n 异构语言接入成本高 事实证明 Service Mesh 确实降低了异构语言的接入门槛，但在越来越多的基础能力下沉到 MOSN 以后，我们逐渐意识到为了让应用跟 MOSN 交互，各种 SDK 里都需要对通信协议，序列化协议进行开发，如果再加上需要对各种异构语言都提供相同的功能，那维护难度就会成倍上涨，\nService Mesh 让重 SDK 成为了历史，但对于现在各种编程语言百花齐放、各种应用又强依赖基础设施的场景来说，我们发现现有的 SDK 还不够薄，异构语言接入的门槛还不够低，如何进一步降低异构语言的接入门槛是我们面临的第二个问题。\n二、Multi Runtime 理论概述 A、什么是 Runtime? 20 年初的时候，Bilgin lbryam 发表了一篇名为 Multi-Runtime Microservices Architecture 的文章，里面对微服务架构下一阶段的形态进行了讨论。\n如上图所示，作者把分布式服务的需求进行了抽象，总共分为了四大类： 1. 生命周期（Lifecycle） 主要指应用的编译、打包、部署等事情，在云原生的大趋势下基本被 docker、kubernetes 承包。\n 网络（Networking） 可靠的网络是微服务之间进行通信的基本保障，Service Mesh 正是在这方面做了尝试，目前 MOSN、envoy 等流行的数据面的稳定性、实用性都已经得到了充分验证。\n 状态（State） 分布式系统需要的服务编排，工作流，分布式单例，调度，幂等性，有状态的错误恢复，缓存等操作都可以统一归为底层的状态管理。\n 绑定（Binding） 在分布式系统中，不仅需要跟其他系统通信，还需要集成各种外部系统，因此对于协议转换，多种交互模型、错误恢复流程等功能也都有强依赖。\n 明确了需求以后，借鉴了 Service Mesh 的思路，作者对分布式服务的架构演进进行了如下总结：\n 第一阶段就是把各种基础设施能力从应用中剥离解耦，通通变成独立 sidecar 模型伴随着应用一起运行。\n第二阶段是把各种 sidecar 提供的能力统一抽象成若干个 Runtime，这样应用从面向基础组件开发就演变成了面向各种分布式能力开发，彻底屏蔽掉了底层实现细节，而且由于是面向能力，除了调用提供各种能力的 API 之外，应用再也不需要依赖各种各样基础设施提供的 SDK 了。\n作者的思路跟我们希望解决的问题一致， …","date":1624258800,"description":"MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章","dir":"blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","fuzzywordcount":7600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4ea3e26c4f2e5422816a186691849af5","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","publishdate":"2021-06-21T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","summary":"作者简介： 马振军，花名古今，在基础架构领域耕耘多年，对 Service Mesh 有深度实践经验，目前在蚂蚁集团中间件团队负责 MOSN、Layotto 等项目的开发工","tags":["SOFAStack"],"title":"MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章","type":"blog","url":"/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","wordcount":7525},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙力 提问：\n 请问和 MOSN 相关的健康检查有什么可行的方案吗？比如如何检查 MOSN 的健康状态，MOSN 检查业务容器健康，检查失败后有什么降级或动作？\n A：MOSN 有获取运行状态的 API ，\nhttps://github.com/mosn/mosn/blob/master/pkg/admin/server/apis.go#L301\n检查业务容器健康通常来说需要自己扩展。\nhttps://github.com/mosn/mosn/blob/9a53d7239d8d5ca987410c15d791e780b5809558/pkg/upstream/healthcheck/factory.go#L53\n健康检查也有回调可以注册，可以实现自己的降级逻辑。\nMOSN：https://github.com/mosn/mosn\n2、@许玉杰 提问：\n AT 模式是怎么做到的空回滚、防悬挂和幂等的啊？\n A：幂等是用户自己做的，防悬挂和空回滚有 undolog，AT 的幂等等于接口幂等，自己的接口保证即可。\nSeata：https://github.com/seata/seata\n3、@jueming 提问：\n Seata 支持 mybatis 的注解开发吗？目前用的 seata1.0 的版本，需要配置代理数据源，但是配置之后，影响了其他 sql 的执行，代理执行了 sql 的方法，打印了相关 sql 语句（数据库里有数据），但是得到的实体却为空。我把代理关闭以后则不影响 sql 的查询，这种情况应该怎么解决？\n A：这里的问题是添加代理数据源的时候，使之前的 datasource 自动失效，没有读取 mybatis 的配置，解决方法是在设置新的 sqlsessionfactory 的时候，把需要配置的属性通过 ibatis 包下的 Configuration 注入进去。\nSeata：https://github.com/seata/seata\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623999600,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210618/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c8d740f2b60544b872580120fd456cde","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210618/","publishdate":"2021-06-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210618/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210618/","wordcount":902},{"author":"SOFAStack","categories":"SOFAStack","content":" GoCN：贵司从什么时候开始用 Go，基于什么原因，还记得第一个用 Go 的项目是什么吗?\n宋顺：早在 2015 年，蚂蚁的基础设施团队就已经使用 Go 来尝试优化资源调度能力，当时还是基于 Docker Swarm 做的一些调度平台，这个时期没有持续太长就逐步切换到了 Kubernetes，蚂蚁内部的版本叫 Sigma，当前 Sigma 已经承担起了蚂蚁内部所有集群的资源调度，并且也在逐年提升资源利用率，为公司节省了不少的成本。\nGoCN：现在有多少人用 Go，或者 Go 开发比例占到多少？\n宋顺：目前 Go 主要用于蚂蚁的基础设施团队，在资源调度、弹性伸缩、安全容器、日志无盘、Service Mesh、Serverless 等场景中广泛应用，Go 的开发人员在基础设施团队内部占比高达 50% 以上，业务团队大部分还是以 Java 为主。\nGoCN：Go 有哪些特性是非常匹配贵司业务和开发需求的，有哪些是让人很抓马的，希望有哪些改进？\n宋顺：Go 的简单易学、安全编码、研发效率、活跃生态等特性是非常符合我们的需求的。抓马的主要还是性能，如大规模下 gc 抖动，调度延迟等。改进方面希望能够有比 channel 更轻量的 Go block/wake 机制，这块我们也在和社区讨论中：https://github.com/golang/go/issues/46431\nGoCN：目前来看 Go 在项目中普及的难度是什么，在招聘方面有困难吗?\n宋顺：在基础设施层面普及没有太大难度，后续如果在业务团队中也能顺畅的使用 Go 还是需要我们的 Service Mesh 体系对多语言体系的支撑更加完善，让业务能更少的感知底层能力从而专注业务开发。我们即将开源的 Layotto 就是希望在 Runtime 层面通过统一的 API 定义，从而可以让各种语言都非常简单的享受到分布式架构的红利，为业务提效。 在招聘方面由于目前 Go 主要用于基础设施，所以我们需要的是对网络、系统内核、高性能有较多经验的人才，不过眼下这类人才还是比较稀缺的。\nGoCN：希望招到具备哪方面能力的 Go 工程师？\n宋顺：有高性能网络编程和性能优化经验，对分布式系统有较深理解，对 Go Runtime 有一定研究的 Gopher 工程师。\nGoCN：对本次大会的期待是什么？\n宋顺：希望了解 Go 在更多公司的实践经验、学习 Go 语言自身的特性演进以及和更多的 Gopher 现场交流。\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623740400,"description":"Gopher China 2021 专访之宋顺：Go 在蚂蚁集团的应用、实践","dir":"blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e6d1f215ee12ebb60c2cc4fda0b64d82","permalink":"https://sofastack.github.io/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","publishdate":"2021-06-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","summary":"GoCN：贵司从什么时候开始用 Go，基于什么原因，还记得第一个用 Go 的项目是什么吗? 宋顺：早在 2015 年，蚂蚁的基础设施团队就已经使用 Go 来尝试优化资","tags":["SOFAStack"],"title":"Gopher China 2021 专访之宋顺：Go 在蚂蚁集团的应用、实践","type":"blog","url":"/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","wordcount":990},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙军超 提问：\n 实际项目中，怎么动态的配置 # 集群列表中所有节点的地址列表initialServerList: 127.0.0.1:8181,127.0.0.1:8182,127.0.0.1:8183比如加一个节点 这个列表怎么自动刷新 。\n A：通过 CliService 动态增上改节点。\nSOFAJraft：https://github.com/sofastack/sofa-jraft\n2、@王国鑫 提问：\n 请教一下，其中一个 follow 机器，在状态机 onApply 里执行任务，有一些异常，这个异常状态如何上报给 leader？\n A：异常分两种，跟上不上报 leader 没什么关系，也不需要上报 leader。leader 只负责感知对应 follower 能不能跟上 raft log， 不论 raft 还是 paxos，都可以理解为分布式日志状态机，你这个异常是你自己的业务状态机里的事情了，raft 只保证 raft log 一致，你自己需要保证相同的 raft log 你要产生相同的结果。\nSOFAJraft：https://github.com/sofastack/sofa-jraft\n3、@陈泽胜 提问：\n 我想问一下我这个是什么问题？ 这是偶发的，两三天会出现一次，有时候一小时内会出现多次。\n Seata：https://github.com/seata/seata\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623394800,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-0611/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"74bd4ee2b575599848e566b632980c07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0611/","publishdate":"2021-06-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0611/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0611/","wordcount":896},{"author":"","categories":"SOFAStack","content":" 主题：从数据库到架构，我们来聊透分布式\n时间：2021年6 月 19 日（周六）13：00 -17：30\n活动地点：北京海淀中关村创业大街 72 号拓荒族众创空间\n报名方式：点击http://hdxu.cn/Iq6Ef 即可报名。\n扫描海报上面的二维码，即可报名。\n【重要提醒】2021 年 6 月 19 日将有惊喜送出，欲知惊喜为何，请待 619 给您分解。\n6月初， OceanBase 诚意开源，正式揭开 300 万 C++ 数据库内核代码的神秘面纱。\n本次线下 Meetup，由 OceanBase \u0026amp;amp; SOFAStack 联合举办，也是 OceanBase 开源之后的首次线下活动。\n本次分享将邀请来自 OceanBase 和 SOFAStack 两个开源项目的四位专家，分别从云原生分布式架构、分布式 HTAP 数据库，以及新发布的时序数据库 CeresDB 来层层解开分布式的魅力。\n 报名方式：\n1、 扫描海报二维码，立即报名；\n2、 点击http://hdxu.cn/Iq6Ef 即可报名。\n在活动现场不仅仅可以和讲师面对面交流\n还有精美礼品发放，快来现场吧~\n","date":1623135600,"description":"【活动报名】SOFAMeetup#6 北京站，从数据库到架构，聊透分布式，玩转 Layotto","dir":"activities/sofa-meetup-7/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"884ed3d8cfc6d7b0784dbda5a27315b1","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-7/","publishdate":"2021-06-08T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-7/","summary":"主题：从数据库到架构，我们来聊透分布式 时间：2021年6 月 19 日（周六）13：00 -17：30 活动地点：北京海淀中关村创业大街 72 号拓荒族众创空","tags":["SOFAStack"],"title":"【活动报名】SOFAMeetup#6 北京站，从数据库到架构，聊透分布式，玩转 Layotto","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-7/","wordcount":371},{"author":"","categories":"SOFAStack","content":" 此文原系 2021 年阿里云开发者大会，开源操作系统社区和生态分论坛，题为《国密技术开发与实践》的分享会后解读。 AnolisOS 国密是社区在 AnolisOS 上做的国密技术解决方案，非常欢迎业界有兴趣的开发者能够参与到 OpenAnolis 社区，为国内的基础软件生态添砖加瓦。\n演讲嘉宾： 杨洋：蚂蚁集团高级技术专家，主导开发了 BabaSSL，也是国内唯一的一个 OpenSSL maintainer，参与起草并推动 RFC8998 标准国际化。 张天佳：阿里云技术专家，主要负责 AnolisOS 上国密技术的开发和应用，参与实现了 libgcrypt 中的国密算法和 linux 内核中的 SM2 算法。\n 让我们穿越回现场： \u0026amp;gt;\u0026amp;gt;缘起 说到密码算法，大家一定很熟悉 MD5，AES，RSA 这些通用的国际标准算法，这也是目前我们普遍采用的密码学算法，它们在数据安全、通信、区块链等众多领域都有着广泛的应用。\n众所周知，这些算法标准都是国外制定的，在某些情况下这会对国内信息安全有不利影响。当下有实力的国家，甚至有些大公司都制定了自己的算法标准。\n顾名思义，国密就是密码算法的国产化，跟其它领域一样，密码算法的国产化已经势不可挡，这也是我们必须要做的事情。中国的国密算法为我们提供了一个新的选择，在必要的场合中可以选择替代那些国际主流算法，尤其是当下国际贸易冲突，技术封锁不可忽视的大环境下，大规模推广和采用国密算法将为国内重要的网络基础设施提供可靠的数据安全保障。\n国密简介 我是谁，从哪里来\n国密是一个口语化的称呼，官方名称是国家商用密码，简称商密，拼音缩写是 SM，这也是国密标准中具体算法名字的来源。国密是用于商用的、不涉及国家秘密的密码技术。\n国密标准完全由中国密码管理局制定，主要的技术实现也基本是国内开发人员完成的，这对摆脱国外的密码技术和产品依赖是非常有利的。\n到哪里去\n自 2012 年以来，SM2/3/4 的国密标准陆续公布，目前国密技术生态基本处于一个正在逐步走向成熟的阶段，但国内密码基础软件在采用国密算法方面仍处于碎片化的状态，比如我们经常可以看到各种个人或组织名义开源的支持国密算法的库；此外这些开源项目的安全更新和社区活跃也都做的不好。国密的推广仍然需要我们中国基础软件的开发者和用户共同努力。\n2020 年 1 月 1 日，《中华人民共和国密码法》正式实施，从法律层面规范了国家商用密码的应用和管理，这也为推广和应用国密提供了必要的法律保障。\n与国际算法的对比\n这里是国密算法和国际通用算法的一个对比，可以直观地看到国密的一个基本情况：\n 针对各种常用的国际能用算法类型，比如对称算法，公钥算法和消息摘要算法，国密标准都定义了对应的相同功能的国密算法，比如 SM4 提供了与 AES 同样的加密强度，并且支持各种加密模式； SM2 是基于椭圆曲线的公钥算法，同时定义了非对称加解密，数字签名和密钥交换标准，相对于 RSA，SM2 的密钥更短，但支持的加密强度却更高；SM3 是国密定义的消息摘要算法标准，摘要长度是固定的 256 位，强度等同于 SHA256。\n除了基础的算法，国密标准也定义了 TLCP 国密双证书协议，用以支持国内的传输层安全协议。这里还有一个好消息，今年三月份，TLS1.3+国密单证书协议正式被国际标准所承认，并且以 RFC8998 标准发布，这意味着我们可以选择在 TLS1.3 协议中使用完整的国密套件，目前我们也在联系正规浏览器厂商支持这个标准的实施和应用。\n同时国密也定义了使用国密算法的 X509 证书，使用 SM3 哈希算法，SM2 算法作为数字签名，证书类型是 SM2-with-SM3。\n对开发者来说，国密提供了一个选择，可以选择从国际通用算法平滑迁移过来。除此之外，国密还有其它一些算法标准，是不太常用的，比如 SM9，ZUC 算法等。\nBabaSSL 前世今生 BabaSSL 是主打国密的密码算法库，与 OpenSSL 1.1.1 保持兼容，作为国密的密码算法解决方案而诞生。\nBabaSSL 是基于之前蚂蚁集团和阿里集团内部的 OpenSSL 版本合并而来，并首次进行了开源。BabaSSL 的含义是：灵巧、轻快且靠谱的密码学和 SSL/TLS 工具库。\nBabaSSL 的绿色商标，是基于阿里的橙色和蚂蚁的蓝色混合而来，也意味着我们希望将 BabaSSL 打造成一个灵活、小巧并且健壮的基础密码学库。\nBabaSSL 目前在阿里集团和蚂蚁集团内部得到了非常广泛的使用。从具体场景来看，有如下三个方面，分别是存储、网络和端上的设备。其中网络服务的场景，是 BabaSSL 最大的支撑场景，例如淘宝、天猫、阿里云等各种涉及到链路加密的服务器端。此外移动端 App，例如支付宝手机 App 中集成了 BabaSSL 来实现多种密码学的能力。\n开源 BabaSSL 已经在去年的 10 月份进行了开源，目前代码是托管在 OpenAnolis 上，当前开源的版本是 8.2.0，也是我们目前最新的稳定版本。\n目前 BabaSSL 在阿里内部使用的版本和开源版本之间存在一定的差异，我们目前正在逐步把内部版本的功能特性迁移到开源版本上进行开源，最终变成一个统一的开源版本，那么届时阿里内部也完全依赖于这个开源的版本，而不会再保留内部的闭源版本。\n特色功能 以下是 BabaSSL 当前最新稳定版本 8.2.0 的主要特色功能特性：\n 基于 OpenSSL 1.1.1，具备 OpenSSL 1.1.1 的全部能力并且保持兼容 支持国密 SM2, SM3 和 SM4，并对 OpenSSL 1.1.1 中所欠缺的 SM2 能力，比如 X509 证书的签发和验证功能进行了补全 GM/T 0024 和 TLCP 国密双证书 TLS 协议 支持 RFC 8998：TLS 1.3+国密单证书 提供了对 IETF 正在标准化过程中的 Delegated Credentials 支持 IETF QUIC API 底层密码学能力 更加完善的 SM2 算法支持，比如 X.509 证书签发、验签的支持 正在申请软件密码模块一级资质 与 OpenSSL 对比 接下来是大家很关心的 BabaSSL 和 OpenSSL 这种老牌的密码算法库之间的区别：\n 从图上可以看到一些主要区别：\n对于一些新的密码学技术标准，BabaSSL 会采取一种相对激进的策略快速跟进，比如在 IETF 中一些正在标准化流程中的技术方案，例如 delegated credentials, compact TLS 等，会进行原型的实现和快速跟进，而 OpenSSL 则是相对保守，因为 OpenSSL 社区的策略是原则上只实现已经发布了的国际标准和国家标准。 在对于国密算法、国密协议、国密的监管合规、云计算厂商的深度集成、以及国产化硬件等方面， BabaSSL 会进行更加深度和广泛的支持，而 OpenSSL 则支持的比较有限。 对于 API 的易用程度，由于没有历史包袱，所以 BabaSSL 可以提供更加简单易用的 API，而OpenSSL 的 API 则相对复杂。对于资源受限的嵌入式设备，BabaSSL 会进行体积裁剪和内 …","date":1623135600,"description":"揭秘 AnolisOS 国密生态，想要看懂这一篇就够了","dir":"blog/the-secret-of-anolisos/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"447fa6eedb1d5ccdea4c37803a2b0dc3","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-secret-of-anolisos/","publishdate":"2021-06-08T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/the-secret-of-anolisos/","summary":"此文原系 2021 年阿里云开发者大会，开源操作系统社区和生态分论坛，题为《国密技术开发与实践》的分享会后解读。 AnolisOS 国密是社区在 AnolisOS 上做的国密技术解决方案","tags":["SOFAStack"],"title":"揭秘 AnolisOS 国密生态，想要看懂这一篇就够了","type":"blog","url":"/sofastack.tech/blog/the-secret-of-anolisos/","wordcount":3702},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@郭晶晶 提问：\n 蚂蚁内部的 SOFAMesh 对 Istio 的 pilot 进行了哪些扩展？是不是内部的 SOFAMesh 才支持 zk 注册中心。\n A：蚂蚁内部用的注册中心是 https://github.com/sofastack/sofa-registry 在服务发现这块是有跟 SOFARegistry 做对接，内部的模块更多还是适应内部的各种配套设置和架构做的一些定制。\nMOSN：https://github.com/mosn/mosn\n2、@王庆振 提问：\n https://github.com/sofastack/sofa-bolt/issuse/257 Connection 对象不应该是对应一个 poolkey（ip:port）吗？为什么 Connection 中还会持有 poolkey 的集合\n A：这个是因为 Bolt 还要服务消息中间件的，消息这边有一个 Connection 对应多个上层对象的场景，poolKey 不是 ip:port 的形式。\nSOFABolt：https://github.com/sofastack/sofa-bolt\n3、@jueming 提问：\n 这一步如果抛出异常，那么是不是不会释放 connection 连接？导致长期占有数据库连接。 A: 会释放，close 是框架层面出现异常自动就会调，如果你自己写 jdbc，你也肯定捕获一次做 rollback close了，这属于框架和业务上的处理，Seata 只不过把异常抛出去。\nSeata：https://github.com/seata/seata\n本周推荐阅读 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案\n 用安全计算保护关键业务\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 本周发布 本周发布详情如下：\n本周发布 MOSN v0.23.0 版本，主要变更如下： 1.新增基于 networkfilter 的 grpc server 扩展实现能力；\n2.新增 TLS 连接的证书缓存，降低内存占用；\n3.修复 HTTP1 协议的 URL 编码与大小写敏感问题；\n4.新增 so plugin 扩展协议实现的示例；\n5.其他 BUG Fix 与优化。\n详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.23.0\n更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1622790000,"description":"SOFA Weekly | MOSN 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210604/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"47a5a019bacbf28f24ea5e9cbad7fc20","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210604/","publishdate":"2021-06-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210604/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210604/","wordcount":951},{"author":"","categories":"SOFAStack","content":" 机器学习（ML）和深度学习（DL）在众多真实的应用场景中愈发重要。这些模型使用已知数据进行训练，并部署在图像分类、内容推荐等场景中进行新数据的处理。总体而言，数据越多，ML/DL 模型就越完善。但囤积和处理海量数据也带来了隐私、安全和监管等风险。 隐私保护机器学习（PPML）有助于化解这些风险。其采用加密技术差分隐私、硬件技术等，旨在处理机器学习任务的同时保护敏感用户数据和训练模型的隐私。 在英特尔® 软件防护扩展（英特尔® SGX）和蚂蚁集团用于英特尔® SGX 的内存安全多进程用户态操作系统 Occlum 的基础上，蚂蚁集团与英特尔合作搭建了 PPML 平台。在本篇博客中，我们将介绍这项运行在 Analytics Zoo 上的解决方案，并展示该解决方案在第三代英特尔® 至强® 可扩展处理器上得到英特尔® 深度学习加速（英特尔® DL Boost）技术助力时的性能优势。\n 英特尔® SGX 是英特尔的受信任执行环境（TEE），它提供基于硬件的内存加密，隔离内存中的特定应用代码和数据。英特尔® SGX 使得用户层代码可以分配内存中的受保护区域，即 “飞地”，这些区域不受更高权限等级程序运行的任何影响（如图一所示）。\n 图一 通过英特尔® SGX 加强防护\n 与同态加密和差分隐私相比，英特尔® SGX 在操作系统、驱动、BIOS、虚拟机管理器或系统管理模型已瘫痪的情况下仍可帮助防御软件攻击。因此，英特尔® SGX 在攻击者完全控制平台的情况下仍可增强对隐私数据和密钥的保护。第三代英特尔® 至强® 可扩展处理器可使 CPU 受信任内存区域增加到 512GB，使得英特尔® SGX 技术能够为隐私保护机器学习解决方案打下坚实的基础。\n2014 年正式成立的蚂蚁集团服务于超 10 亿用户，是全球领先的金融科技企业之一。蚂蚁集团一直积极探索隐私保护机器学习领域，并发起了开源项目 Occlum。Occlum 是用于英特尔® SGX 的内存安全多进程用户态操作系统（LibOS）。使用 Occlum 后，机器学习工作负载等只需修改极少量（甚至无需修改）源代码即可在英特尔® SGX 上运行，以高度透明的方式保护了用户数据的机密性和完整性。用于英特尔® SGX 的 Occlum 架构如图二所示。\n 图二 用于英特尔® SGX 的 Occlum 架构（图片来源：Occlum · GitHub）\n Analytics Zoo 赋能端到端 PPML 解决方案 Analytics Zoo 是面向基于 Apache Spark、Flink 和 Ray 的分布式 TensorFlow、Keras 和 PyTorch 的统一的大数据分析和人工智能平台。使用 Analytics Zoo 后，分析框架、ML/DL 框架和 Python 库可以在 Occlum LibOS 以受保护的方式作为一个整体运行。此外，Analytics Zoo 还提供安全数据访问、安全梯度与参数管理等安全性功能，赋能联邦学习等隐私保护机器学习用例。端到端 Analytics Zoo PPML 解决方案如图三所示。\n 图三 端到端 PPML 解决方案为金融服务、医疗卫生、云服务等应用领域提供安全分布式计算\n 在 Analytics Zoo PPML 平台上，蚂蚁集团与英特尔共同打造了一个更加安全的分布式端到端推理服务流水线（如图四所示）。 该流水线采用 Analytics Zoo Cluster Serving 打造，后者是轻量级分布式实时服务解决方案，支持多种深度学习模型，包括 TensorFlow、PyTorch、Caffe、BigDL 和 OpenVINOTM。 Analytics Zoo Cluster Serving 包括 web 前端、内存数据结构存储 Redis、推理引擎（如面向英特尔® 架构优化的 TensorFlow 或 OpenVINO™ 工具套件），以及分布式流处理框架（如 Apache Flink）。 推理引擎和流处理框架在 Occlum 和英特尔® SGX “飞地” 上运行。web 前端和 Redis 受到传输层安全（TLS）协议加密，因此推理流水线中的数据（包括用户数据和模型）在存储、传输、使用的过程中都受到更多地保护。\n 图四 推理服务流水线\n 共创美好未来：英特尔® DL Boost 加速端到端 PPML 解决方案 1.该解决方案执行如下端到端推理流水线： RESTful http API 接收用户输入，Analytics Zoo pub/sub API 将用户输入转化成输入队列，并由 Redis 管理。用户数据受加密保护。 2.Analytics Zoo 从输入队列中抓取数据。它在分布式流处理框架（如 Apache Flink）上采用推理引擎进行推理。英特尔® SGX 使用 Occlum 来保护推理引擎和分布式流处理框架。英特尔® oneAPI 深度神经网络库（oneDNN）利用支持 Int8 指令集的英特尔® DL Boost 提高分布式推理流水线的性能。 3.Analytics Zoo 从分布式环境中收集推理输出，并送回到由 Redis 管理的输出队列。随后，解决方案使用 RESTful http API 将推理结果作为预测返回给用户。输出队列中的数据和 http 通信内容都被加密。\n性能分析 Analytics Zoo PPML 解决方案的性能进行了验证。\n 表一 测试配置\n 图五为测试结果。与不受英特尔® SGX 保护的推理流水线相比，当推理解决方案受到英特尔® SGX 保护，ResNet50 推理流水线的吞吐量会有少许损失。而采用支持 INT8 指令集的英特尔® DL Boost 后，受英特尔® SGX 保护的推理流水线吞吐量翻了一番。\n 图五 英特尔® SGX、英特尔® DL Boost 和第三代英特尔® 至强® 可扩展处理器提供高性能安全能力\n 基于英特尔® SGX 打造的 Analytics Zoo PPML 解决方案继承了受信任执行环境（TEE）的优点。和其它数据安全解决方案相比，它的安全性和数据效用性十分突出，性能方面仅略逊于纯文本。英特尔® DL Boost 和英特尔® oneDNN 则进一步提升了 Analytics Zoo PPML 推理解决方案的性能。表二总结了该解决方案（TEE）相对于同态加密（HE）、差分隐私（DP）、安全多方计算（MPC）和纯文本的优势。\n 表二 Analytics Zoo PPML 解决方案（TEE）与其他方案的比较\n 总结 在日益复杂的法律和监管环境中，对于企业和组织来说，保护客户数据隐私比以往任何时候都更加重要。在隐私保护机器学习的助力下，企业和组织就能在继续探索强大的人工智能技术的同时，面对大量敏感数据处理降低安全性风险。 Analytics Zoo 隐私保护机器学习解决方案基于 Occlum、英特尔® SGX、英特尔® DL Boost 和 Analytics Zoo 打造，为助力确保数据的安全性和大数据人工智能工作负载性能提供了平台解决方案。蚂蚁集团和英特尔共同打造并验证了这一 PPML 解决方案，并将继续合作探索人工智能和数据安全性领域的最佳实践。\n测试 …","date":1622530800,"description":"助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案","dir":"blog/Helping data security: Ant and Intel work together to create a verified PPML solution/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ccebaadae29c36d85ccb2d8216b6f9b4","permalink":"https://sofastack.github.io/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","publishdate":"2021-06-01T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","summary":"机器学习（ML）和深度学习（DL）在众多真实的应用场景中愈发重要。这些模型使用已知数据进行训练，并部署在图像分类、内容推荐等场景中进行新数据","tags":["SOFAStack"],"title":"助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案","type":"blog","url":"/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","wordcount":2757},{"author":"顾宗敏","categories":"SOFAStack","content":" 什么是安全计算？ Linux 基金会旗下的安全计算联盟对安全计算下了一个定义：\n Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential Computing Consortium\n 在这个定义中强调了这么几点：\n1.安全计算保护的是运算过程中的数据安全;\n2.安全计算需要借助硬件的能力。\n下面就对这两点做一个阐述： 在云计算场景，我们可以把云计算简化为三个部分：数据的传输，数据的运算和数据的存储。\n 这个三个部分的安全解决方案的完整度是有差别的。在数据的传输环节，业界有很完整的安全标准和实现比如 SSL， TLS。在数据存储环节，密码学也提供了非常好的解决方案，我们可以将数据用恰当的方式加密以后保存，防止在存储环节泄密。在数据的运算环节，还没有和其他两个环节那样完整的解决方案。安全计算正是以解决这个问题为目标的。\n安全计算是如何实现的呢？ 我们以英特尔的 SGX 技术为例来看一下具体的技术方案。\n 英特尔的 SGX 技术是将 CPU 作为运算的信任起点，在应用程序中构建安全的运算环境（飞地）。从计算机发明的那一天起，我们就假设 CPU 会按照软件的指令正确地执行，只是没有强调这一点。在软件大发展的今天，各种软件在一台硬件上协作运行，整个生态越来越复杂，恶意软件也出现了。为了防止恶意软件的破坏，CPU 为需要保护的应用隔离出一个独立的飞地环境。飞地外的应用既不能观察也不能修改飞地中的代码和数据，从而保证了飞地中的数据安全。CPU 对飞地的保护非常强，即使是拥有高特权的操作系统和虚拟化管理软件也无法突破这种保护。事实上，不仅仅可以防软件的攻击，哪怕是外围硬件提供者（比如：主板制造者，内存提供者）都无法突破这个保护。\n英特尔 SGX 是目前最成熟的安全计算产品，但并不是唯一的安全计算产品。其他硬件厂商如 AMD，ARM，Nvidia 都在推出安全计算产品。所有这些产品都是软硬件一体的解决方案，总结起来有以下这些特点：\n 在了解了安全计算的概念后，介绍一些安全计算的典型场景：\n 有了安全计算环境，用户可以放心地将应用放到共有云计算环境中，计算中用到的数据和计算的结果都可以加密传输。这样可以统一基础设施的架构，避免复杂的混合云部署方式。\n 云上的数据交易和数据服务也成为了可能。数据拥有方和算法提供方可以分别提供数据和算法至安全计算平台完成计算而不用担心机密泄露的问题。\n 安全计算也可以促成更多的数据合作。各方数据可以在一个安全的环境中做融合运算，让数据产生更大的价值。\n 在边缘计算场景中，计算节点部署在非常复杂的环境中，机器不受控。安全计算可以有效地保护用户数据和隐私。\n安全计算这么多的应用场景，为什么还没有看到大规模部署呢？这是因为安全计算目前还有一个非常大的短板：易用性不强。具体表现为3点：\n应用分割难：将一个现有的应用改造为一个安全计算应用的改造难度很大。需要做代码分割。\n场景部署难：安全计算是要依托于硬件的。在实际部署中需要对应用调度系统做改造。\n安全分析难：一个应用使用了安全计算是不是就一定安全了呢？答案是不确定。这需要对整个应用做非常细致的安全分析。\n针对这些难题，蚂蚁集团和阿里巴巴集团的工程师提出了独到的解决方案。 首先是解决应用分割难的问题。\n 蚂蚁集团开源的 Occlum 项目在飞地中开发了 LibOS 适配层，让 Linux 下的应用可以无修改地运行在 SGX 环境中，彻底解决了应用分割的问题。Occlum 使用 Rust 语言开发，保证内存了安全性；支持多进程和加密文件系统，应用无需修改。 例如：基于蚂蚁集团金融级云原生框架 SOFABoot 开发的应用可以完全无修改的运行在 Occlum 环境中。\n👇网站链接🔗： https://github.com/occlum/occlum/tree/master/demos/sofaboot\n针对部署难的问题，阿里云推出了 Inclavare 开源项目。\n Inclavare 基于 Occlum，为用户提供了安全计算容器。用户只需将关注的重点放在应用本身即可，Inclavare 会将计算调度至合适的计算节点。 针对安全分析难，蚂蚁集团的 MORSE 多方安全计算引擎和 MYTF 区块链计算平台分别为不同的计算场景提供了解决方案。用户无需再承担高昂的安全分析成本。\n 蚂蚁集团在安全计算领域持续投入，用科技的力量来保护数据安全，保护用户隐私，给用户提供更安全的服务。蚂蚁集团开源了 TEE 安全 LibOS Occlum。 用户可以在 https://github.com/occlum/occlum 找到所有的实现代码。用户既可以审查 Occlum 的源代码，以确保整体方案的安全性；也可以参考已有的 demo 来学习 Occlum 的使用方法，快速上手安全计算。\n本周推荐阅读 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 金融级能力成核心竞争力，服务网格驱动企业创新\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1622530800,"description":"用安全计算保护关键业务","dir":"blog/Protecting Critical Operations with Secure Computing/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"800c9227ecb01253319dc8df2eb14d68","permalink":"https://sofastack.github.io/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","publishdate":"2021-06-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","summary":"什么是安全计算？ Linux 基金会旗下的安全计算联盟对安全计算下了一个定义： Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential Computing Consortium 在这个定义中强调了这么几点： 1.安全计","tags":["SOFAStack"],"title":"用安全计算保护关键业务","type":"blog","url":"/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","wordcount":1810},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@非余 提问：\n 对于 Kata 我有些地方还是不太理解，我现在说说我的理解，麻烦你看对不 对，我的理解是 Kata 有两个缓存： 1. virtiofs 需要一个缓存。virtiofsd 和 guest 交互需要缓存做文件系统 buffer ，这个缓存的对应 qemu 的参数就是 memory-backend-file 。（这个缓存和 vhost-user 使用的 vring 是不是同一个？每一个 vm 有自己的缓存空间 ） 在 Kata 配置文件对应的是 default_memory。缓存策略是 virtio_fs_cache。 2. dax 缓存，对应的参数是 virtio_fs_cache_size，没有缓存策略控制。\n A：1、是的；2、dax的缓存控制是依靠guest的文件系统语义实现的。\nSOFAStack：https://github.com/sofastack\n2、@张鹏科 提问：\n SofaReferenceBinding 这个注解有一个属性：serializeType，默认序列化协议使用的是 Hessian2，我想替换成 protobuf，我看文档说这个目前不支持在注解中替换，只能以 xml 的方式。有点蒙，到底支持不支持？\n A：支持。\nSOFAStack：https://github.com/sofastack\n3、@jueming 提问：\n 请问一下 sofa-rpc和 Dubbo 区别在哪呢，是不是可以无缝接入 mosn sidecar？\n A: 核心差别目前主要是在协议上吧，协议的可扩展性双方都有，SOFARPC 的 Bolt 协议是基于最早 HSF 协议的一些痛点做了改良设计，整个协议的请求头是能包含更多信息，比如在 MOSN 里支持 Bolt 协议，整个请求在 MOSN 内只解析 header 就可以拿到足够信息做路由，header 的解析也是类似简单 kv 的方式，Dubbo 使用的协议在 Mosn 或者 Envoy 里需要做 Hessian 反序列化才能拿到足够的信息，性能损耗会稍微大一点，其他方面的扩展性上机制略有不同，但是都有比较强的扩展能力。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n4、@汪辉 提问\n Caused by:io.seata.core.exception.TmTransactionException: TransactionException[begin global request failed. xid=null, msg=Communications link failure. 请问这个 突然没有 xid 是什么情况？\n A：因为是 begin 时的异常，所以没有 xid，begin 成功了才有 Communications link failure。\nSeata：https://github.com/seata/seata\n5、@贾云森 提问\n 常见的就是并没有对 Select 语句进行 forupdate,如果你不开启 forupdate,Seata 默认是遇到并发性竞争锁并不会去尝试重试,导致拿不到 lock 当前事务进行回滚.不影响一致性,如果你想没 forupdate 也开启竞争锁client.rm.lock.retryPolicyBranchRollbackOnConflict 设置为 false（有死锁风险）。 请问是参数开启会出现死锁风险，还是自己手动添加 forupdate ，也会出现死锁风险呢？\n A：不加for update，也会竞争锁。但是因为可能存在二阶段需要回滚的事务，所以retryPolicyBranchRollbackOnConflict 为 true 的时候，优先会给需要回滚的事务进行回滚，所以需要放弃锁，这是 at 模式的一个缺陷。因为 at 就是 2 个锁，1 先获取数据库本地锁，2 获取全局，此事后如果获取全局锁后会释放本地锁，造成了死锁。所以 at 上出现 get global lock fail 是正常的，自己应该在业务上做好重试，当一个全局事务因为获取锁失败的时候，应该重新完整的发起，所谓的完整应该是从 globaltransational 的 tm 端重新发起。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周 sofa-rpc 发布 v5.7.8 版本代码。主要更新如下：\n 支持 Dubbo service version 设置 修复 tracer 采样标志位无法正确透传的问题 修复重试逻辑中丢失最初异常的问题 详细参考： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.8\n","date":1622185200,"description":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20200528/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c1c3882d7e68e5fce4c25a088adaa109","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200528/","publishdate":"2021-05-28T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200528/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200528/","wordcount":1758},{"author":"章耿","categories":"SOFAStack","content":" Mesh 模式的引入是实现应用云原生的关键路径，蚂蚁集团已在内部实现大规模落地。随着 Message、DB、Cache Mesh 等更多的中间件能力的下沉，从 Mesh 演进而来的应用运行时将是中间件技术的未来形态。应用运行时旨在帮助开发人员快速的构建云原生应用，帮助应用和基础设施进一步解耦，而应用运行时最核心是 API 标准，期望社区一起共建。\n 蚂蚁集团 Mesh 化介绍 蚂蚁是一家技术和创新驱动的公司，从最早淘宝里的一个支付应用，到现在服务 全球十二亿用户的大型公司，蚂蚁的技术架构演进大概会分为如下几个阶段：\n2006 之前，最早的支付宝就是一个集中式的单体应用，不同的业务做了模块化的开发。\n2007 年的时候，随着更多场景支付的推广，开始做了一下应用、数据的拆分，做了 SOA 化的一些改造。\n2010 年之后，推出了快捷支付，移动支付，支撑双十一，还有余额宝等现象级产品，用户数到了亿这个级别，蚂蚁的应用数也数量级的增长，蚂蚁自研了很多全套的微服务中间件去支撑蚂蚁的业务；\n2014 年，像借呗花呗、线下支付、更多场景更多业务形态的出现，对蚂蚁的可用性和稳定性提出更高的要求，蚂蚁对微服务中间件进行了 LDC 单元化的支持，支撑业务的异地多活，以及为了支撑双十一超大流量的混合云上的弹性扩缩容。\n2018 年，蚂蚁的业务不仅仅是数字金融，还有数字生活、国际化等一些新战略的出现，促使我们要有更加高效的技术架构能让业务跑得更快更稳，所以蚂蚁结合业界比较流行的云原生的理念，在内部进行了 Service Mesh、Serverless、可信原生方向的一些落地。\n 可以看到蚂蚁的技术架构也是跟随公司的业务创新不断演进的，前面的从集中式到 SOA 再到微服务的过程，相信搞过微服务的同学都深有体会，而从微服务到云原生的实践是蚂蚁近几年自己探索出来的。\n为什么要引入 Service Mesh 蚂蚁既然有一套完整的微服务治理中间件，那为什么还需要引入 Service Mesh 呢？\n 拿蚂蚁自研的服务框架 SOFARPC 为例，它是一个功能强大的 SDK，包含了服务发现、路由、熔断限流等一系列能力。在一个基本的 SOFA(Java) 应用里，业务代码集成了 SOFARPC 的 SDK，两者在一个进程里运行。在蚂蚁的大规模落地微服务之后，我们就面临了如下的一些问题：\n升级成本高：SDK 是需要业务代码引入的，每次的升级都需要应用修改代码进行发布。由于应用规模较大，在一些大的技术变更或者安全问题修复的时候。每次需要数千个应用一起升级，费时费力。 版本碎片化：由于升级成本高，SDK 版本碎片化严重，这就导致我们写代码的时候需要兼容历史逻辑，整体技术演进困难。 跨语言无法治理：蚂蚁的中后台在线应用大多使用 Java 作为技术栈，但是在前台、AI、大数据等领域有很多的跨语言应用，例如 C++/Python/Golang 等等，由于没有对应语言的 SDK，他们的服务治理能力其实是缺失的。\n我们注意到云原生里有 Service Mesh 一些理念开始出现，所以开始往这个方向探索。在 Service Mesh 的理念里，有两个概念，一个是 Control Plane 控制平面，一个是 Data Plane 数据平面。控制面这里暂时不展开，其中数据平面的核心思想就是解耦，将一些业务无需关系的复杂逻辑（如 RPC 调用里的服务发现、服务路由、熔断限流、安全）抽象到一个独立进程里去。只要保持业务和独立进程的通信协议不变，这些能力的演进可以跟随这个独立的进程自主升级，整个 Mesh 就可以做到统一演进。而我们的跨语言应用，只要流量是经过我们的 Data Plane 的，都可以享受到刚才提到的各种服务治理相关的能力，应用对底层的基础设施能力是透明的，真正的云原生的。\n蚂蚁 Mesh 落地过程 所以从 2017 年底开始，蚂蚁就开始探索 Service Mesh 的技术方向，并提出了 基础设施统一，业务无感升级 的愿景。主要的里程碑就是：\n2017 年底开始技术预研 Service Mesh 技术，并确定为未来发展方向；\n2018 年初开始用 Golang 自研 Sidecar MOSN 并开源，主要支持 RPC 在双十一小范围试点；\n2019 年 618，新增 Message Mesh 和 DB Mesh 的形态，覆盖若干核心链路，支撑 618 大促；\n2019 年双十一，覆盖了所有大促核心链路几百个应用，支撑当时的双十一大促；\n2020 年双十一，全站超过 80% 的在线应用接入了 Mesh 化，整套 Mesh 体系也具备了 2 个月从能力开发到全站升级完成的能力。\n蚂蚁 Mesh 落地架构 目前 Mesh 化在蚂蚁落地规模是应用约数千个，容器数十万的级别，这个规模的落地，在业界是数一数二的，根本就没有前人的路可以学习，所以蚂蚁在落地过程中，也建设一套完整的研发运维体系去支撑蚂蚁的 Mesh 化。\n 蚂蚁 Mesh 架构大概如图所示，底下是我们的控制平面，里面部署了服务治理中心、PaaS、监控中心等平台的服务端，都是现有的一些产品。还有就是我们的运维体系，包括研发平台和 PaaS 平台。那中间是我们的主角数据平面 MOSN，里面管理了 RPC、消息、MVC、任务四种流量，还有健康检查、监控、配置、安全、技术风险都下沉的基础能力，同时 MOSN 也屏蔽了业务和基础平台的一些交互。DBMesh 在蚂蚁是一个独立的产品，图里就没画出来。然后最上层是我们的一些应用，目前支持 Java、Nodejs 等多种语言的接入。 对应用来说，Mesh 虽然能做到基础设施解耦，但是接入还是需要一次额外的升级成本，所以为了推进应用的接入，蚂蚁做了整个研发运维流程的打通，包括在现有框架上做最简化的接入，通过分批推进把控风险和进度，让新应用默认接入 Mesh 化等一些事情。\n同时随着下沉能力的越来越多，各个能力之前也面临了研发协作的一些问题，甚至互相影响性能和稳定性的问题，所以对于 Mesh 自身的研发效能，我们也做了一下模块化隔离、新能力动态插拔、自动回归等改进，目前一个下沉能力从开发到全站推广完成可以在 2 个月内完成。\n云原生应用运行时上的探索 大规模落地后的新问题与思考\n蚂蚁 Mesh 大规模落地之后，目前我们遇到了一些新的问题： 跨语言 SDK 的维护成本高：拿 RPC 举例，大部分逻辑已经下沉到了 MOSN 里，但是还有一部分通信编解码协议的逻辑是在 Java 的一个轻量级 SDK 里的，这个 SDK 还是有一定的维护成本的，有多少个语言就有多少个轻量级 SDK，一个团队不可能有精通所有语言的研发，所以这个轻量级 SDK 的代码质量就是一个问题。\n业务兼容不同环境的新场景：蚂蚁的一部分应用是既部署在蚂蚁内部，也对外输出到金融机构的。当它们部署到蚂蚁时，对接的是蚂蚁的控制面，当对接到银行的时候，对接的是银行已有的控制面。目前大多数应用的做法是自己在代码里封装一层，遇到不支持的组件就临时支持对接一下。\n从 Service Mesh 到 Multi-Mesh：蚂蚁最早的场景是 Service Mesh，MOSN 通过网络连接代理的方式进行了 …","date":1621926000,"description":"蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海 ","dir":"blog/Exploration and Practice of AntCloud Native Application Runtime - ArchSummit Shanghai/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"da69750163f92aa73f15821202ee07e6","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","publishdate":"2021-05-25T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","summary":"Mesh 模式的引入是实现应用云原生的关键路径，蚂蚁集团已在内部实现大规模落地。随着 Message、DB、Cache Mesh 等更多的中间件能力的下沉，从 Mesh","tags":["SOFAStack"],"title":"蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海 ","type":"blog","url":"/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","wordcount":4840},{"author":"SOFAStack社区","categories":"Summer 2021","content":"警告警告⚠️暑期即将到来，\n在暑期到来之前你有没有考虑过这样一个问题？\n那就是这个夏天怎么过？\n我相信你读完问题后脑海里浮现出了 N 多个想法，我相信那都是对你有意义的，但是你有没有考虑过让这个夏天过的更有“意义”一些。\n让你在这个夏天不仅可以让还是学生的你参与到知名开源项目，体验开源文化，与开源社区导师一同交流探讨的同时又可以收获一笔不菲的奖金，最重要的是可以获得一份特别亮眼的项目经历！！！\n动没动心？？？❤️\n 2021年的夏天被称为“开源之夏”\n那么什么是“开源之夏”？\n“开源之夏”全名开源软件供应链计划-暑期2021，是由中国科学院软件研究所与 openEuler 社区共同举办的一项面向高校学生的暑期活动，是一项专门面向高校学生的开源项目开发活动，旨在鼓励在校学生积极参与开源软件的开发维护。主办方联合各大开源社区，针对对重要开源软件的开发与维护提供项目任务，学生根据兴趣申请项目，中选后将在社区导师指导下进行开发，并将成果贡献给社区。根据项目的难易程度和完成情况，学生将获得 6000、9000、12000元不等的项目奖金。完成SOFAStack社区项目的优秀贡献者可以获得蚂蚁内推机会（蚂蚁中间件团队很多优秀的工程师都是被挖过来的开源社区贡献者🤫）\n活动官网：https://summer.iscas.ac.cn/\n暑期 2021 项目任务活动自发布以来，众多开源社区踊跃报名，5 月 20 日社区报名截止，共有 109 家海内外社区报名，并上线了 877 个开源项目任务。其中 SOFAStack 社区上线了 9 个项目任务，包含云计算、云原生、分布式系统、微服务中间件、前端等多个方向结合的项目任务，涉及的开源项目包括：JRaft、SOFA-RPC、SOFA-Registry、SOFADashboard、SOFATracer，有中、高等级不同难度的任务以供选择。\nSOFAStack 社区项目任务列表：https://summer.iscas.ac.cn/#/org/orgdetail/s\nsofastack 学生指南：https://summer.iscas.ac.cn/help/student/\n学生如何申请？\n学生申请通道 5 月 24 号正式开放啦！\n申请时间：5 月 24 日\u0026amp;ndash; 6 月 13 日\nSTEP 1 ：查看项目任务列表，你感兴趣的任务。可同步在官网报名系统注册账号进行报名。\n报名系统：\nhttps://portal.summer-ospp.ac.cn/summer/login\n STEP 2：就感兴趣的任务与对应的导师取得联系，沟通清楚项目需求，也可就项目方案和导师讨论。\nSTEP 3：撰写项目申请书，并在报名系统提交项目申请书和个人简历。\nSTEP 4：6 月 30 号公布中选结果，中选学生在导师指导下，按计划在 7-9 月进行开发。\nSTEP 5：完成开发，获得项目奖金和证书。\n详情可进一步阅读暑期 2021 学生指南：https://summer.iscas.ac.cn/help/student/\n暑期 2021 面向人群 本活动面向年满 18 周岁在校学生，不限国籍暑期即将毕业的学生，只要在申请时学生证处在有效期内，就可以提交申请海外学生可提供录取通知书/学生卡/在读证明证明学生身份\n ","date":1621839600,"description":"“开源之夏” SOFAStack 社区 9 个项目任务上线，学生申请正式开始！","dir":"activities/Summer 2021 of Open Source Promotion Plan/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9917f037c993814f23d2049396c438eb","permalink":"https://sofastack.github.io/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","publishdate":"2021-05-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","summary":"警告警告⚠️暑期即将到来， 在暑期到来之前你有没有考虑过这样一个问题？ 那就是这个夏天怎么过？ 我相信你读完问题后脑海里浮现出了 N 多个想法，我相信","tags":["Summer 2021"],"title":"“开源之夏” SOFAStack 社区 9 个项目任务上线，学生申请正式开始！","type":"activities","url":"/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","wordcount":1198},{"author":"朵晓东","categories":"SOFAStack","content":" 本文是云原生开放协同技术探索与实践一阶段的总结和综述。\n蚂蚁基础技术在过去3年多以来持续、深入推进全面的云原生化技术演进，我们将在线、离线计算资源装进了一台计算机，将服务体系通过 mesh 的思路和技术手段进行了下沉解耦，可以说比较充分的拥抱了云原生技术，并获取了其带来的技术红利。\n当完成了资源、服务的云原生化，我们发现在云原生基础能力之上的运维体系与云原生技术开放、共享的思路有较大的距离，在技术体系上也与云原生技术声明式、白盒化的思路相悖，同时由于缺少匹配的技术支撑，历史包袱等问题也成为了云原生运维难以真正代际演进的障碍。今天我要介绍的就是蚂蚁在这样的背景下在云原生运维方向进行的技术探索和实践。\n规模化云原生运维探索 我们先来回顾一下在蚂蚁真实的实践方式和面对的问题。首先，我们来看看蚂蚁践行多年的经典运维中台，这类运维平台一般包括了控制器、业务模型、编排引擎、原子任务及管道，在蚂蚁这样的平台是一系列服务的集合，他们较好的满足了集中式、标准化、低变更频率的应用发布及运维需求。但这种模式在实践中也存在着明显的不足。\n首先对于非标准应用、应用个性化需求、高成本需求、非紧急需求、技改类需求，往往无法较好的满足。在蚂蚁的实践中，非标运维需求、对核心应用模型及运维模型冲击较大的高成本改造需求、大量基础能力或运维功能的透出需求等长期无法得到较好的满足，需求往往是合理的，是难以获得足够的优先级执行落地。在研发阶段，运维平台长期积累了高复杂度的业务逻辑，修改测试涉及跨系统的长改造链路，同时基础能力的透出、运维能力的产品化依赖前端、服务端研发资源。这些问题使得运维平台研发日渐吃力，特别是在产品 GUI、业务模型、编排引擎等变更热点上，受限于扩展机制能力不足，内部实践中甚至出现过线上不断修改代码、发布服务以满足需求的情况。平台上线后，统一的质保和线上全链路功能验证同样面对较大的压力。对于最终的使用者，命令式按钮背后的黑盒计算透明度低，审计难，结果难预测，同时激情操作、操作界面不熟悉等问题也一直影响着线上的稳定性。这些问题长期存在，我们寄希望于代际的技术演进来解决这些问题。 \u0026amp;gt;当云原生基础服务逐渐稳定后，对于自身场景不在运维平台管理范围内的应用，研发同学自发的借助云原生社区工具链解决问题。基于 Kubernetes 生态高度开放、高度可配置的特点，研发者可以自助、灵活、透明的声明式应用运行、运维需求，以应用粒度完成发布、运维操作。\n用户通过 kustomize 等社区技术缩短了对接基础设施的路径，并通过如 velocity 等文本模板技术部分解决了静态 YAML 文件在较多变量时维度爆炸的问题，解决了默认值设定的问题，同时通过 code review 的方式进行多因子变更及评审。由于 Kubernetes 及其生态提供了面向资源、服务、运维、安全的横向能力，使得这种简单的方式可有很好的普遍性和适用性，通过对不同的 Kubernetes 集群 “播放” 这些数据即可完成对基础设施的变更，本质上是一种声明数据的流转。面向 git 仓库的研发方式和 gitops 流程支持对运维产品研发资源的诉求较低，往往可以比较简单的搭建起来，不强依赖产品研发资源投入。相比经典运维中台，这些好处清晰明确，但从工程视角缺点也非常明显。 \u0026amp;gt;首先 Kubernetes API 的设计较为复杂，仅是 Kubernetes 原生提供的 low level API 就暴露了 500 多种模型，2000 多字段，场景上几乎涵盖了基础设施应用层的方方面面，即使是专业同学也很难理解所有细节。其次这种方式的工程化程度很低，违反 DRY 原则，违反各团队职责能力高内聚低耦合的原则，即使在有一定的工具支持的情况下，在内部的典型案例中一个多应用的 infra 项目仍然维护了多达 5 万多行 YAML，同时由于团队边界造成的多个割裂的平台，用户需在多个平台间切换，每个平台的操作方式各异，加上跳板机黑屏命令，完成一次完整的发布需要 2 天时间。\n由于低工程化程度的问题，各团队间协同依赖人肉拉群同步，最终 YAML 由多个团队定义的部分组合而成，其中一大部分属于 Kubernetes 及运维平台团队的定义，这些内容需要持续跟踪同步避免腐化，长期维护成本高。\nKUSION: 云原生开放协同技术栈 以上两种模式各有利弊，优势和问题都比较清晰。那么能不能既要也要呢，能不能在继承经典运维平台优势的情况下，充分利用云原生技术带来的红利，打造一个开放、透明、可协同的运维体系？\n带着这样的问题，我们进行了探索和实践，并创建了基于基础设施代码化思路的云原生可编程技术栈 Kusion。\n大家都知道 Kubernetes 提供了声明式的 low level API，提倡其上生态能力通过 CRD 扩展的方式定义并提供服务，整个生态遵循统一的 API 规范约束，复用 API 技术和工具。Kubernetes API 规范提倡 low level API 对象松耦合、可复用，以支持 high level API 由 low level API “组合” 而成。Kubernetes 自身提供了利于开源传播的极简方案，并不包括 API 之上的技术和方案。\n回到云原生技术的本源，我们回看了 Kubernetes 前身 Borg 的应用技术生态。如下图示，在 BorgMaster 之上，Borg 团队研发了 Borg 接入三件套，即 BCL（Borg Configuration Language），Command-line tools，以及相应的 web service。用户可以通过 BCL 声明式编写需求，通过 Command-line tools 将 BCL 文件执行到 Borg 集群，并通过 web GUI 视图查看任务细节。经过大量的调研，我们了解到 Google 内部的运维能力及产品生态、质量技术生态都依赖这三件套构建而成，在内部也进行了多年的迭代演进。 \u0026amp;gt;这给了我们启发，今天我们有了容器技术、服务体系，有了大量用户和差异化的需求，有了一定数量的自动化运维平台，我们希望能通过云原生专用的语言和工具来链接 Kubernetes 生态、各个运维平台以及大量的用户，通过唯一事实定义消除运维平台孤岛，完成云原生基础设施在应用、运维层面的代际演进，达到 “Fusion on Kubernetes” 的目标。\n带着这样的目标，我们持续地进行做技术探索和实践，目前已经形成了 Kusion 技术栈，并在蚂蚁的生产实践中进行应用。 \u0026amp;gt;Kusion 技术栈基于这样的基础能力而工作，包括如下组成部分：\n云原生配置策略专用语言 KCL (Kusion Configuration Language)\nKCL 解释器及其 Plugin 扩展机制\nKCL 研发工具集: Lint, Format, Doc-Gen，IDE Plugin(IDEA, VsCode)\nKusion Kubernetes 生态工具: OpenAPI-tool, KusionCtl(Srv)\nKonfig 配置代码库，其中包括平台侧及用户侧代码\nOCMP (Open CloudNative Management …","date":1621321200,"description":"带你走进云原生技术：云原生开放运维体系探索和实践","dir":"blog/Take you into cloud-native technology: cloud-native open operation and maintenance system exploration and practice/","fuzzywordcount":10400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"365cd296d63b8ea2fa2e70b06830c734","permalink":"https://sofastack.github.io/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","publishdate":"2021-05-18T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","summary":"本文是云原生开放协同技术探索与实践一阶段的总结和综述。 蚂蚁基础技术在过去3年多以来持续、深入推进全面的云原生化技术演进，我们将在线、离线计算","tags":["SOFAStack"],"title":"带你走进云原生技术：云原生开放运维体系探索和实践","type":"blog","url":"/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","wordcount":10395},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@姚远 提问：\n 请问下 SOFAArk，master-biz 是个 Spring Boot 应用，A-biz 是个普通的Spring，一起打成一个 Executable-Ark 包。那么 Spring 相关的 Jar 是不是就要加载 2 次。 A：如果没有下沉插件的话，是会加载两次。\n SOFAArk：https://github.com/sofastack/sofa-ark\n@colin 提问：\n 内部服务之间的路由策略，是推荐用 service-mesh 来做吗？还是内部服务之间也用服务网关？ A：内部东西向流量推荐走 mesh ，一般来说网关更适合做南北向网络边界上的出入口。\n MOSN：https://github.com/mosn/mosn/\n@colin 提问：\n 这种场景，推荐用网关还是 service-mesh？目前我们是自己的内部网关来做的，网络不隔离，只是 jvm 进程隔离。 A：如果逻辑上也不隔离，互相能够服务发现，互相信任不需要额外鉴权的话，可以认为是内部流量，走 mesh 比走集中式的网关更合适。如果逻辑隔离，那么走网关比较合理。\n MOSN：https://github.com/mosn/mosn/\n@骆伟康 提问：\n 请问一下 这里我使用 dynamic 多数据源 结合 Seata 但是为啥只回滚了主库的数据 另外的库回滚失败？ A：看官网 FAQ，关闭 Seata 的自动代理，mp 的 dynamic 组件你开启他的 Seata 开关他自己会代理的。\n Seata：https://github.com/seata/seata\n@贾云森 提问：\n Could not commit JDBC transaction; nested exception is io.seata.rm.datasource.exec.LockConflictException: get global lock fail, xid:192.168.3.239:8092:138223831620784128, lockKeys:outpat_medical:135231296034705408,135231296034705409,135231296034705410,135231296034705411,135231296034705412,135231296034705413)\u0026amp;ldquo;,\u0026amp;ldquo;code\u0026amp;rdquo;:85550,\u0026amp;ldquo;data\u0026amp;rdquo;:null,\u0026amp;ldquo;time\u0026amp;rdquo;:\u0026amp;ldquo;2021-05-19 10:12:10\u0026amp;rdquo; 想问一下为什么会发生这种异常啊？ A：正常输出，竞争锁没竞争到。\n Seata：https://github.com/seata/seata\n@winyQ 提问：\n 项目里 Seata 用 AT 模式，可以在项目里再集成 JTA 吗，两个并存有没有什么问题？ A：JTA 是 XA ，无法跟 AT 兼容。\n Seata：https://github.com/seata/seata\n本周推荐阅读 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 金融级能力成核心竞争力，服务网格驱动企业创新\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n 本周发布 本周发布详情如下：\n本周 SOFAJRaft 发布 1.3.7 版本，主要更新如下：\n 1.修复 TCP 建连被 block 导致选主超时 2.升级 commons.io 到 2.8.0 以修复安全漏洞\n详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.7\n ","date":1621234800,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210521/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d7be1cbefe37ff9c846ea84f7ad52755","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210521/","publishdate":"2021-05-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210521/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210521/","wordcount":1146},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张思雨提问：\n 我配置中心里加了 transport.threadFactory.clientSelectorThreadSize\u0026amp;hellip;设置了个 100，这个值是不是一般设置成 cpu 核数*2 就够了啊？ 我之前遇到了 tc 调客户端的 commit 超时。我就把这种值都调大了试试效果 ， transport.threadFactory.clientSelectorThreadSize 100 transport.threadFactory.workerThreadSize 3000\n A：线程数这个东西这不该开放出去，很危险，对 netty 了解一点应该也知道 NioEventLoopGroup 的最多应该就核心数的两倍。 Seata：https://github.com/seata/seata\n2、@林南行提问：\n 大家好，请教一个问题：我现在用的 seata-server 的 1.3.0 的版本，客户端用的是 1.4.1 版本。当同时启动 10+个微服务连接 seata-server 的时候，只有 10 个能注册成功，剩余的必须重启后才能重新注册成功，这个是什么问题呢？\n A：试一下把 logSerialization 改成 kyro。 Seata：https://github.com/seata/seata\n3、@林南行提问：\n seata-server-1.3.0 和 seata-server-1.4.2 在配置上有什么区别吗？ 两边的 registry.conf 配置是一样的，但是 1.3.0 能正常启动，1.4.2 就报错，global_table 找不到。\n A：没区别，说明配置有问题，看看 global_table 写了没，写了的话，写的是什么，配置中心是什么，检查清除。 Seata：https://github.com/seata/seata\n4、@潘顾昌提问：\n 请问什么情况这个状态会是 Finished？现在导致这部分数据没有提交，但是也没有报错，正常的数据提交后看到的都是这个。 现在有些情况会返回 Finished，导致没有正常提交。\n A：事务结束了不就是 Finished，自己服务降级了吧，导致没回滚，部分插入部分没插入了。 Seata：https://github.com/seata/seata\n5、@潘顾昌提问：\n Finished 已经插入的数据会回滚丢失吗？我们后台实时监控到，一开始是插入到数据库的，确实是有的，但是结束以后数据就丢失了\n A：seata 没有执行二阶段回滚，不会消失数据，数据丢失要么是本地事务发生异常，你们捕获异常了，用 spring API 来回滚了本地事务，导致异常没抛出去，事务回滚了，要么发生异常，被你们的全局异常捕获器捕获了，导致决议了提交，实际上数据已经被本地事务回滚，seata 在二阶段不是 rollback 相关状态的时候不会干预业务数据。 Seata：https://github.com/seata/seata\n本周推荐阅读\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n Rust 大展拳脚的新兴领域：机密计算\n 开源项目是如何让这个世界更安全的？\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周发布详情如下：\n本周 sofa-registry 发布 V6-alpha 代码，本版本不建议生产使用，正式版本会在近期 release。主要更新如下：\n 支持应用级服务发现 基于 slot 分配的数据分片存储 详细参考：https://github.com/sofastack/sofa-registry/tree/v6-alpha1 文章解读：https://mp.weixin.qq.com/s/-5oK-EuZWpvIATvTzSMRAw\n","date":1620975600,"description":"SOFA WEEKLY | SOFARegistry 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210514/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7c193377953cba7840c05a3ff7d6d4ec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210514/","publishdate":"2021-05-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210514/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARegistry 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210514/","wordcount":1488},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@Chrosing 提问：\n Seata 被锁的 xid 数据 一直卡住的时候， 为啥丢失了一部分 undo_log 语句？导致直接删除 lock_table 的 xid 时候，没有回滚数据回去，当前版本 1.3.0。\n A：不会丢 undolog，只可能回滚了部分，部分因为脏写了导致没法回滚，这部分的 undolog 留着；所以看起来 undolog 少了，其实是分支回滚调了，留着的都是没有回滚的。\nSeata：https://github.com/seata/seata\n2、@洪波森 提问：\n 这算一个 bug 吗，永远跑不进来？\n A：不是，读不到你事务分组对应的值，就是 null。\nSeata：https://github.com/seata/seata\n3、@陈承邦 提问：\n sharding-transaction-base-seata-at 这个包只对 Seata 做了代理，我看了一早上源码，直接用 Seata 包 好像也不影响 分布式事务\n A：Seata 无法找到具体那个 datasource，Seata 只能代理 sharding-jdbc 最外层的 datasource，这个 datasource 里面有 N 个 datasource 来实现分库分表的功能，这个才是真正对数据库的 Seata：https://github.com/seata/seata\n4、@杨政伟 提问：\n 请教一个问题，如果 A 方法调用 B 方法，B 方法启用了事务，并发生异常时，但 B 方法并没有回滚，怎么能实现 B 方法的回滚？\n A：在同一个类里面被其他方法调用，是不能开启事务的，看一下 aop 的机制。a 是个实例 cglib 代理了 a 成为了一个包装了它的实例，此时你直接调了内部的实例，怎么走到它的切面去呢？\nSeata：https://github.com/seata/seata\n本周推荐阅读 下一代机密计算即将到来：性能比肩普通应用\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n Rust 大展拳脚的新兴领域：机密计算\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n ","date":1620370800,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-20210507/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4606adcc9195341f35c6dd05b0e93da1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210507/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210507/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210507/","wordcount":957},{"author":"英花","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#20：用安全计算保护关键业务\n 活动时间：05 月 19 日周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#20：用安全计算保护关键业务 随着全社会对隐私保护越来越关注安全计算也成了近期的热点。蚂蚁做为一家金融科技公司，特别注重用科技的方法来保护用户隐私。这次直播会介绍蚂蚁在安全计算方面的一些方法和实践。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 相和 蚂蚁集团安全计算团队 Occlum 项目负责人 （从事 Intel SGX 相关开发工作十多年，期间设计和主持开发了 Intel SGX SDK） 议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 用安全计算保护关键业务 相和 蚂蚁集团安全计算团队 Occlum 项目负责人\n你将收获 了解Intel SGX 技术和蚂蚁开源的 Occlum 产品。 了解如何用 Occlum 来保护已有的 SOFABoot 应用。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1620370800,"description":"05 月 19 日周三晚 19 点，线上直播第 20 期。","dir":"activities/sofa-channel-20/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f41faefa3f35c17635d73634cf7a50f5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-20/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-20/","summary":"概要 活动主题：SOFAChannel#20：用安全计算保护关键业务 活动时间：05 月 19 日周三晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播间","tags":["SOFAChannel","Occlum"],"title":"SOFAChannel#20：用安全计算保护关键业务","type":"activities","url":"/sofastack.tech/activities/sofa-channel-20/","wordcount":551},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAStack Meetup#5 上海站 容器沙箱专场\n 活动时间：2021 年 05 月 22 日（周六）14:00-17:00\n 活动地点：上海市浦东新区蚂蚁 S 空间 南泉北路 447 号 201\n 活动形式：线下活动\n 资料下载： 《边缘计算中的 Kata Containers\u0026amp;gt; 《快速闪电：Nydus 镜像加速服务》 《WebAssembly Micro Runtime：云原生时代的超轻量级新型沙箱》 《WebAssembly 在 MOSN 中的探索与实践》\n 活动介绍 活动议程 本期议题以及嘉宾详解 《边缘计算中的 Kata Containers》\n嘉宾介绍\n李枫，先后就职于摩托罗拉, 三星等IT公司, 现为独立开发者。在移动平台上积累了十年以上的研发经验, 近几年主要专注于云计算/边缘计算基础设施领域。是《灰帽黑客 第4版：正义黑客的道德规范、渗透测试、攻击方法和漏洞分析技术》和《恶意网络环境下的Linux防御之道 》中文版的主要译者。对技术创新具有浓厚的兴趣和实践能力，热心参与开源社区的各种活动，多次参加各种IT会议并作技术分享。\n议题简介\n Kata Containers 具有的轻量和高安全等特性使它在资源受限和安全性需求的物联网/边缘计算领域有很好的应用前景, 并且可以与其他轻量级解决方案（如 K3S 等）进一步结合使用。本话题包含下列子话题： 1) LF Edge（由 Akraino 和 EdgeX 合并而成）中的 Kata Containers； 2) 打造轻量级 K8S 集群\u0026amp;ndash;Kata-Containers 与 K3S 的结合； 3) 在 ACRN 中运行 Kata Containers； 4) 将 Kata Containers 应用于边缘云。 听众收获\n 了解 Kata Containers 的基本情况 了解 Kata Containers 在边缘计算场景的应用前景 《快速闪电：Nydus 镜像加速服务》\n嘉宾介绍\n彭涛，蚂蚁集团可信原生技术部高级技术专家，Linux 内核和文件系统开发者，近年来主要关注容器运行时相关技术，是 Kata Containers 维护者和架构委员会成员，Dragonfly 镜像服务 nydus 的作者之一，云原生技术浪潮的坚定支持者。\n徐佶辉，蚂蚁集团可信原生技术部技术专家，Dragonfly 镜像服务 nydus 的作者之一，负责 nydus 在蚂蚁的落地。\n议题简介\n 有研究表明，容器镜像拉取占据了容器启动时间的 70%，而容器启动实际上只需要访问容器镜像不到 6% 的数据量。基于此，我们设计实现了可以按需加载容器镜像的 nydus 镜像加速服务，在内部大规模部署，并开源贡献给 Dragonfly 社区。本话题将向大家介绍 nydus 项目的背景，架构和技术细节，以及我们对容器镜像生态的展望。 听众收获\n 了解当前 OCI 容器镜像格式优缺点 了解 nydus 项目的背景，架构和技术细节 了解容器镜像生态的发展趋势 《WebAssembly Micro Runtime：云原生时代的超轻量级新型沙箱》\n嘉宾介绍\n王鑫，英特尔高级工程经理，WAMR(WebAssembly Micro Runtime)项目的创建者，主要工作集中在管理语言运行时和Web技术，2009年以来领导了Java和WebAssembly虚拟机运行时开发、V8 JavaScript引擎的性能优化等相关工作。加入英特尔之前，在摩托罗拉主要作为技术Leader，负责无线基站系统相关的工作。\n议题简介\n 近年来WebAssembly在服务器侧及云原生场景中越来越流行，WAMR(WebAssembly Micro Runtime)是字节码联盟(Bytecode Alliance)旗下的WebAssembly独立运行时开源项目，支持多种软硬件平台，支持解释器/AOT/JIT等多种执行方式，性能优异，资源占用少，对多线程和SIMD也有良好的支持。这次分享将介绍WAMR的架构、特性、社区合作及在云原生场景中的应用。 听众收获\n 了解WebAssembly这一新兴技术 了解WAMR开源项目的架构、特性及社区合作 了解WAMR在云原生场景中的应用实例 《WebAssembly 在 MOSN 中的探索与实践》\n嘉宾介绍\n叶永杰，蚂蚁集团可信原生技术部软件工程师，开源项目 MOSN 核心成员，目前关注云原生 ServiceMesh、WebAssembly 等相关领域。\n议题简介\n 随着云原生数据面 MOSN 在蚂蚁金服内部的大规模落地，安全隔离逐渐成为急需解决的问题之一。为此，我们利用 WebAssembly 基于给定资源的安全模型，依托于社区 Proxy-Wasm 开源规范，为 MOSN 中的扩展插件提供了一个独立隔离的沙箱环境。这次分享将介绍 MOSN 的背景，WebAssembly 在 MOSN 中的实践、以及我们在 Proxy-Wasm 开源规范上的贡献。 听众收获\n 了解云原生数据平面 MOSN 的基本情况 了解 Proxy-Wasm 开源规范的基本情况 了解 WebAssembly 技术在云原生数据平面的实践案例 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1620370800,"description":"SOFAStack Meetup#5 上海站 容器沙箱专场","dir":"activities/sofa-meetup-6/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"411a4b0f323c4d5ced46847b710a948d","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-6/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-6/","summary":"概要 活动主题：SOFAStack Meetup#5 上海站 容器沙箱专场 活动时间：2021 年 05 月 22 日（周六）14:00-17:00 活动地点：上海市浦东新区蚂蚁 S","tags":["SOFAMeetup"],"title":"SOFAStack Meetup#5 上海站 容器沙箱专场","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-6/","wordcount":1805},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@李明 提问：\n 请教一下： SOFATracer 用 3.1.0 版本对应 SOFABoot，应该使用 3.1. 版本吗？\n A：都可以，不依赖 SOFABoot 版本。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@黄海淇 提问：\n 有没有 SOFABoot 从零开始的文档哇？这家公司用的 SOFA 相关的组件做的银行项目。\n A：https://www.sofastack.tech/projects/sofa-boot/overview/ ，在我们社区各个项目的主页介绍里面都是有文档的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@陈承邦 提问：\n undo_log 日志当时回滚删除，还是过一段时间批量删除？ A：回滚删除，status 为 1 的 7 天删除。\nSeata：https://github.com/seata/seata\n4、@贾云森 提问：\n @GlobalTransactional 这个注解下的，不同 Service 的数据库操作，都要加本地事务吗？\n A：AT 模式下不需要。\nSeata：https://github.com/seata/seata\n5、@天成 提问：\n 问下：生产跟预发感觉也得搭建 2 个 seata-server，不能共用一个对吧？\n A：可以共用一个，因为锁需要共享才能排他；也可以分开，但是要用表共享，具体看官网事务分组。\nSeata：https://github.com/seata/seata\n本周推荐阅读 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 开发 Wasm 协议插件指南\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n ","date":1619766000,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-0430/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8225fa5618621f7b6ea3e7504b74610a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0430/","publishdate":"2021-04-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0430/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0430/","wordcount":903},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谭新宇 提问：\n 请教 SOFAJRaft 的问题：默认的 election timeout 这么小嘛？业务压力比较大的话感觉很可能发生超过 1s 的 STW GC 吧，这时会不会导致频繁换主。\n A：最好调整下默认参数，不过 1s 的 STW 实际上也不太正常，需要优化。\nSOFAJRaft：https://github.com/sofastack/sofa-jrafta\n2、@刚刚 提问：\n SOFARPC 是通过 MOSN 转发协议？SOFA RPC 对外注册的 IP 在 k8 的容器是什么策略？\n A：：MOSN 支持 SOFARPC 协议的转发。\nA：服务发布订阅没有做啥特殊的，就和原来是一样的。\nMOSN:https://github.com/mosn/mosn\n3、@王哲 提问：\n 问下 MOSN 对 Kubernetes 版本有限制么？\n A：MOSN 对 K8s 没有强制版本要求，不过 Istio 是对其有版本要求的，具体可以看文档：https://istio.io/latest/about/supported-releases/#support-status-of-istio-releases。\nMOSN:https://github.com/mosn/mosn\n4、@王哲 提问：\n 我试了下 mosn bookinfo出现了这个问题：那个 demo Istio 注入后 yaml 文件是 OK 的，但是运行时 describe pod 看 binaryPath 又变成了 envoy，下面是运行时的，不知道是不是因为这个问题？\n A：看起来是你修改的路径没有生效，可以先在 configmap 里面修改下这个 binarypath 。\nMOSN:https://github.com/mosn/mosn\n5、@朱闯 提问：\n 请教个问题：saga 模式下是无锁的，一阶段就提交了本地事务，那么也会出现脏写而导致没法正常回滚事务的情况吧。\n A：所以允许向前重试，最终一致。向前是最终一致，没有脏写。\nSeata：https://github.com/seata/seata\n6、@何凯博 提问：\n 请教下各位大佬，xa 模式下 Seata 是怎么实现事务隔离的？\n A：xa 就是本地事务隔离，把本地事务 prepare，到二阶段再提交或者回滚。\nSeata：https://github.com/seata/seata\n7、@谢太阳 提问：\n A 项目独立库，B 项目用 sharding jdbc 分库分表，A 项目发起分布式事务，出现异常，B 项目不回滚，请教这个一般是什么问题呢？上面是 A 调用 B 的日志，没有分支的回滚记录。下面 B 调用 A 是正常的。\n A：xid 传递检查一下，数据源代理没成功，或者 xid 没传递。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Rust 大展拳脚的新兴领域：机密计算\n 开发 Wasm 协议插件指南\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n 本周发布 本周发布详情如下：\n1、Occlum 发布了 0.22.0 版本，主要变更如下：\n 三个新的 demo：redis，Flink 和 Enclave RA_TLS 支持 /dev/shm 文件子系统 支持 golang1.16.3 详细参考：\nhttps://github.com/occlum/occlum/releases/tag/0.22.0\n","date":1619161200,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-20210423/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"30345ac491d8918983986d2f4cf1d058","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210423/","publishdate":"2021-04-23T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210423/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210423/","wordcount":1277},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@藜蒿 提问：\n 请问一下，SOFATracer+SpringBoot 如何在 spring-mvc-digest.log 增加 rest 请求的请求体数据在 json 日志中。需要打印 request 数据，不单单是 url 上的，可能是 post 请求放在 body 里面的。A：可以用这里的命名空间：\n A：这个暂时不行，不过你可以通过手动埋点的方式去拿这些信息，可以提个 issue ，详细描述下场景诉求。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@南桥 提问：\n 请问下 select * for update, 在 Seata 的事务中，除了会加一个全局的锁，还会加数据库锁吗？ 如果一条记录在分布式事务中，已经加了 for update 读。 那么这条记录再在数据库本地事务中，不加 @GlobalLock，加 for update 读，能读到吗？\n A：不会加全局锁，先加本地锁。\nA：如果要根据读的结果来写，为了得到分布式事务下的已提交数据，需要 for update。数据库层面可以快照读，但是无法当前读（for update 会阻塞），上了分布式事务后，结果都是二阶段后才是准确的，因为有了分布式事务的概念，在此之下的所有本地事务，也就是数据库方的数据已经不能算是准确的了，因为在 AT 模式下随时都有会回滚数据。\nSeata：https://github.com/seata/seata\n3、@姜广兴 提问：\n saga 模式 demo 中的服务都有对应的补偿服务，如果对接外部系统，没有提供相应的补偿服务，还可以使用 saga 模式吗？\n A：可以，没有补偿服务就不补偿，可以向前重试。\nSeata：https://github.com/seata/seata\n4、@彭勃 提问：\n 看到这段，我请教一下。目前，我们自己通过再加一个 mysql MGR 集群去回避这个外部持久化单点故障的问题请问有人有过相关实践吗？您觉得可行吗？\n A：可以这么做，MGR 的话性能应该就比单 DB 要下降了，但是比主备要靠谱，主备的话还是有可能丢数据，MGR 有一致性协议存在，理论上没什么大问题。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Rust 大展拳脚的新兴领域：机密计算\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n 本周发布 本周发布详情如下：\n1、SOFATracer **** 发布 v3.1.1 版本，主要变更如下：\n 添加数据脱敏扩展点，默认无对应的开源实现，用户可以自定义；商业版则提供了该实现 。\n详细参考：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.1.1 ","date":1618556400,"description":"SOFA WEEKLY |SOFATracer 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210416/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6e17e1cbdfbb154ddbe2066aa24dabfa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210416/","publishdate":"2021-04-16T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210416/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210416/","wordcount":1212},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA开源三周年，Let\u0026amp;rsquo;s have fun together\n 活动时间：2021 年 04 月 24 日（周六）14:00-17:00\n 活动地点：北京海淀中关村创业大街72号拓荒族众创空间（三层路演厅）\n 活动形式：线下活动\n 资料下载：\n 《SOFAStack 三周年分享》下载链接\n 《Enabling Financial-Grade Secure Infrastructure with Confidential Computing》下载链接\n 《云原生网络代理 MOSN 新的助推器—Envoy》下载链接\n 《注册中心 6.0 新特性》下载链接\n 《服务网格在企业落地的典型场景与实践》下载链接\n 活动介绍 SOFA 开源三周年， Let\u0026amp;rsquo;s have fun together！北京，我们来啦！\n不知不觉，我们已相识三年，\n很开心能邀请你一起来见证 SOFAStack 社区三周年，\n三年的时间，见证了 SOFAStack 在各个行业环境中的成长，是我们 SOFA 星球的骄傲。\n我们将在北京迎来 SOFA 三周岁的生日，期待与你一同分享！\n活动议程 本期议题以及嘉宾详解 《SOFA 三周年 \u0026amp;mdash;- 一起做些有趣的事儿吧！》\n嘉宾介绍\n黄挺，蚂蚁集团资深技术专家，目前主要负责蚂蚁中间件团队，推动了蚂蚁 Service Mesh，Serverless 等云原生技术在蚂蚁落地。\n议题简介\n SOFA 开源已经进行了三年的时间，在本次分享中，将会带大家了解 SOFA 开源三周年以来的一些心路历程，介绍 SOFA 开源未来的发展方向. 听众收获\n 了解 SOFA 开源的现状 了解 SOFA 开源的未来的发展方向\n 《机密计算如何为金融级基础设施保驾护航》\n嘉宾介绍\n田洪亮，蚂蚁集团高级技术专家，在机密计算、可信执行环境（TEE）和系统软件方面拥有丰富的经验，是蚂蚁自主研发的开源 TEE 操作系统 Occlum 的架构师。在加入蚂蚁之前，供职于 Intel 中国研究院。他于清华大学获得博士学位。\n议题简介\n 构建金融级基础设施的重要一环就是金融级安全性，而这正是 SOFAStack 技术栈中的 Occlum 项目所瞄准的目标。本次演讲将介绍蚂蚁集团在机密计算（Confidential Computing）和可信执行环境（TEE）方面所做的努力，尤其是如何通过蚂蚁自研的、开源TEE操作系统 Occlum 来实现零门槛、高性能的机密计算。 听众收获\n 了解机密计算这一激动人心的新兴技术方向；\n 了解机密计算领域的重要进展\n 《云原生网络代理 MOSN 新的助推器 —Envoy》\n嘉宾介绍\n王发康，蚂蚁集团技术专家，专注于高性能网络服务器研发，MOSN、Tengine 开源项目核心成员，目前关注云原生 ServiceMesh、Nginx、Envoy、Istio 等相关领域。\n议题简介\n MOSN 在 Service Mesh 领域作为东西向服务治理网络在蚂蚁集团双 11 、红包等活动及开源社区都得到了实践，为进一步节省研发及运维等相关成本，目前业界也有东西和南北向数据面进行统一的趋势。该演讲主题介绍了如何使用 Envoy 作为 MOSN 的网络层扩展，将 MOSN 和 Envoy 生态打通，同时使得 MOSN 底层网络处理能力具备 C/C++ 同等高性能、满足南北向高并发场景，又能复用 MOSN 的服务治理能力及 GoLang 的高研发效率。 听众收获\n 可快速了解如何使用 MOSN/GoLang 来扩展 Envoy 的服务治理能力\n 收获 MOSN 扩展 Envoy 时遇到的踩坑事项\n 了解 MOSN 开源社区进展\n 《新版 SOFARegistry 的多个 10X 提升》\n嘉宾介绍\n李旭东，蚂蚁集团中间件高级开发工程师，SOFARegistry Committer，专注于分布式中间件开发与优化。毕业后先后参与分布式服务发现体系构建和企业级 ServiceMesh 平台的开发。\n议题简介\n 随着集群的规模越来越大，服务注册中心的压力也越来越大。如何通过应用级服务发现改造减少服务数据一到两个数量级。现有服务如何利用 MOSN 无感知平滑迁移到应用级服务发现。分布式注册中心如何提高稳定性，如何利用混沌测试提前发现问题。SOFARegistry未来的发展方向。 听众收获\n 了解应用级服务发现如何进行实现和改造以及迁移的方案\n 分布式注册中心的质量和稳定性如何保障\n 《服务网格在企业落地的典型场景与实践》\n嘉宾介绍\n王磊，时速云CTO，负责时速云企业级容器 PaaS、中间件、DevOps、微服务治理、API 网关等多个云原生产品及相关解决方案的架构、产品和研发管理工作，对云原生相关领域有较深的理解及丰富的落地经验，致力于为企业构建新一代以应用为中心的云原生基础平台。曾在IBM中国开发实验室从事IBM中间件、Bluemix PaaS平台等产品的研发和设计工作。\n议题简介\n 当前，应用的微服务改造正在许多企业中如火如荼地进行，然而，微服务改造后的治理问题成了其进一步发展的障碍。在这一背景下，Service Mesh 应运而生，通过将治理能力下沉到基础设施层的方式来降低对业务应用的侵入。从实际需求出发，时速云基于 MOSN 等技术研发了自己的服务网格产品，克服了落地中的各种障碍，目前已在金融客户的核心生产系统中运行了1年多的时间，算是较早落地服务网格的典型案例。在这个过程中我们也感悟到，技术的先进性是持续追求的方向，而如何更好的结合实际场景才是推进服务网格落地的关键。本次分享主要介绍一下我们在落地服务网格时碰到的一些典型需求场景及实践经验。 听众收获\n 了解企业对于服务网格的典型诉求\n 了解服务网格落地时面临的主要问题与相关解决方案\n 服务网格的典型使用场景及未来展望\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1618210800,"description":"SSOFA 开源三周年，Let's have fun together！","dir":"activities/sofa-meetup-5/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"aee1e29a3825c8fdcafee69bc8a1613e","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-5/","publishdate":"2021-04-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-5/","summary":"概要 活动主题：SOFA开源三周年，Let\u0026rsquo;s have fun together 活动时间：2021 年 04 月 24 日（周六）14:00-17:00 活动地点：北京海淀中","tags":["SOFAMeetup"],"title":"SOFA 开源三周年，Let's have fun together！","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-5/","wordcount":2041},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@闫文超 提问：\n 问下 SOFARPC 注册到 nacos 上，可以指定 group 的名字吗？想用于不同租户的隔离的功能。\n A：可以用这里的命名空间：\nnamespace :com.alipay.sofa.rpc.registry.nacos.NacosRegistry。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@霂白 提问：\n 注解方式发布的服务，有插件能自动生成给其他语言使用的 protobuf 的文件吗？Java 已经写了接口和 bean 的结构，直接转换为对应 pb 的文件。现在有 pb的定义文件转换注解方式的，Java 的代码的 maven 插件吗？写 pb 转 Java 或者写 Java 转 pb 两个方向总有一个通的吧，不然又写 Java，又写pb？\n A：这个我理解目前应该是没有的，不过确实是一个比较有意思的方向。\nA：pb 转 Java 问题不大，有现成的工具， 自己写一个也不是很复杂，Java 转 pb 不太兼容；pb 不支持两个参数，这里的问题在于传输协议，不在于代码格式，有需要我们开个 issue 详细聊下 ，鉴权这块后续应该会交给 MOSN 来做。 SOFAStack：https://github.com/sofastack/sofastack.tech\n3、@阿怪 提问：\n 请教大佬一个问题：TCC 模式，事务异常，回滚走自定义实现的 cancel 方法，这个方法里面操作了数据库回滚并且报错，有两个问题： 1.重试次数如何配置？ 2.线程的 ThreadLocal 的数据无法获取，BusinessActionContext 这个类获取不到，可不可以配置？\n A：那就用 localtcc，一开始的 TCC 不支持 spring cloud，后续开发了个 localtcc 的注解和功能来满足。 Seata：https://github.com/seata/seata\n4、@冯明明 提问：\n 我用的是最新版的 spring-cloud-ablibaba rpc 使用的 Dubbo 。截图中这种依赖方式，必须在接口上增加@LocalTcc 才能应用 TCC 模式。我看源码 这种依赖生成的是 xxx.proxy0 这种实现类不能被 RemotingParser解析，接口提供者倒是能被解析，但 DubboRemotingParser 生成的 RemoteSpec 的 protocol 属性是 Dubbo，源码中只有 injvm 能走 TCC 的相关逻辑，请问我是哪里没有配置正确吗 ?\n A：1.方便以后出控制台可以实时查看分支事务状态； 2.比如某些分支吞了异常后，有 report 的情况下方便判断。比如：a 调 b 再调 c，b 其实已经出现异常并且本地事务下已经回滚了，此时 c 响应给 a，a 做后续处理的时候异常，此时 TC 发现 b 已经由本地事务回滚了，就无需驱动了，这样就减少了下发的数量。 Seata：https://github.com/seata/seata\n5、@张红亮 提问：\n 能在 service 实现里再次调用的方法上加 @GlobalTransactional 吗？\n A：可以的，跟本地事务注解一样，支持事务传播。 Seata：https://github.com/seata/seata\n本周推荐阅读 Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n 本周发布 本周发布详情如下：\n1、SOFAJRaft 发布 v1.3.6 版本，主要变更如下：\n 增加 Replicator 的状态变化监听器  RheaKV 增加批量原子更新 API  Grpc 模块支持 max_inbound_message_size 配置  优化 RheaKV 内存占用  详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.6\n","date":1617951600,"description":"SOFA WEEKLY | SOFAJRaft 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210409/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"403b28d70a485885d5c8b391175a5f81","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210409/","publishdate":"2021-04-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210409/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210409/","wordcount":1512},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 请教一下：为什么 KVStoreStateMachine#onSnapshotLoad 是 leader 的时候，不去做；leader 节点如果之前进行过 snapshot 之后，raft log 应该会被删除吧；后续集群重启的时候，leader 不用 snapshot 怎么保证数据还原呢？\n A：想一下，如果它还需要 load snapshot 的话，它是怎么变成 leader 的，如果已经是 leader 了，肯定不需要 load snapshot；理论上不会走到这个分支，只是防御性的代码，如果走到这个分支，就直接报错停止状态机了。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@明惑 提问：\n 现在创建 Grpc Server 的时候，只提供了 port 配置，考虑放开一些参数可以用户配置吗？比如 grpc 的 messageSize。\n A：helper.config看一下。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@刘明明 提问：\n 请教一下：我现在想用 Go 去写一个组件当一个简易的 Sidecar 去对其他服务做健康检查。这个 Go 组件要整合 nacos 注册发现和元数据管理，后期也会整合 Istio，这个组件干的事情应该和 MOSN 类似，Go 这边 0 基础，我是写 JAVA 的，就比如这个用 JAVA 实现只需要 springboot 就好了，Go 这边我调研了下准备用 go-Micro，请问各位这个方向是否正确？\n A：可以参考这个实现： https://github.com/mosn/mosn/issues/1087 这个是直接对接 zk 做的。\nMOSN：https://github.com/mosn/mosn\n4、@彭勃 提问：\n 请教一下，关于 TCC 模式下，会有发生空回滚，资源悬挂，幂等性等问题，需要通过事务控制表去管理。我此前看到同学介绍它们会将事务控制表变成 TCC 模式的一部分（2020 年初），让业务开发者不用自己关注这些问题，请问现在 TCC 模式已经做了吗？\n A：目前只能支持单数据源下的防悬挂，直接利用开启 spring 本地事务，然后做一些前置操作来预防。\nSeata：https://github.com/seata/seata\n5、@王译锌 提问：\n 请教一下：既然回滚依赖于异常上报给 TM，那为什么分支事务的状态还要上报给 TC 呢？一直没想通这个问题。\n A：1.方便以后出控制台可以实时查看分支事务状态； 2.比如某些分支吞了异常后，有 report 的情况下方便判断。比如：a 调 b 再调 c，b 其实已经出现异常并且本地事务下已经回滚了，此时 c 响应给 a，a 做后续处理的时候异常，此时 TC 发现 b 已经由本地事务回滚了，就无需驱动了，这样就减少了下发的数量。\nSeata：https://github.com/seata/seata\n本周推荐阅读 WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n ","date":1617346800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210402/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"99c3b3c82b2f3fb86b66e6632aef8a20","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210402/","publishdate":"2021-04-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210402/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210402/","wordcount":1337},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 使用 jraft 跨 IDC 搭建了集群，一旦读 follower 节点，有 13ms 的网络延迟，用了lease read，读 leader 还好，直接返回。读 follower，要和 leader 通信，hreadb 有跨机房部署的场景吗？\n A：ollower 节点提供读能力，属于额外赠送的能力，其实 readIndex 的实现必须要和 leader 现有一个通信，这个没办法；我们不开 follower 读，从 leader 读；etcd 的 read-index 也是一样的原理，都需要请求一次 leader， zk 我了解貌似还不支持 follower 读；当然如果你不要求线性一致读，那么你绕开 raft 状态机，直接从你的存储里面读就好，如果你要的是最终一致性，那么你直接从 follower 节点上绕过 raft 直接读。 A：核心就是：follower 节点必须知道 leader 此时的 applyIndex 到哪里，然后需要再等待自己状态机的 applyIndex 也到达这个位置了才能提供读，否则就有可能一个数据 leader 上有，follower 上没有，这就很明显违背了线性一致读，所以和 leader 的这一次通信必须有，不过数据包很小，通常应该很快。 SOFAJRaft：https://github.com/sofastack/sofa-jraft 2、@吴岳奇 提问：\n 需求场景：AbstractRoutingDataSource 动态切换数据源，同一方法下，对两个不同服务器上数据表新增，涉及分布式事务。 问题: springboot 整合 Seata AT 模式 ，但无法动态代理数据源，一直代理的 yml 配置的默认的数据源。\n A：多数据源关闭自动代理；bstractRoutingDataSource 内部的多个数据源手动代理后放进去。 Seata：https://github.com/seata/seata 3、@彭勃 提问：\n 我在启动 Seata server 的时候，日志里报告了这种找不到 zookeeper 相关节点的异常；KeeperErrorCode = NoNode for /seata/store.mode。\n A：应该是用了zk 当配置中心，但是又没有写配置进去。 Seata：https://github.com/seata/seata \n本周推荐阅读 MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n ","date":1616742000,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210326/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"617144edd18f95b94e5860ed416ed165","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210326/","publishdate":"2021-03-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210326/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210326/","wordcount":1116},{"author":"嘉祁","categories":"Service mesh","content":" 本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。主要分为 3 个部分： -介绍 MOSN 在规模化运维中遇到的挑战 -无人值守上的实践 -MOSN 与技术风险方面的思考\n MOSN 规模化后的运维挑战 MOSN 早期在内部推进的时候，变更方面的支持是比较传统的。早期的变更工具只有基础的 pod 粒度的 MOSN 升级的能力。变更过程中的问题，最初依赖于上层业务系统的监控和反馈，稍后我们又在 MOSN 内建设了错误码。发布控制上，将版本区分为稳定版和灰度版本，升级的灰度过程和大范围的覆盖过程都由人工控制。这些方式在小范围、大量人力投入的情况下，保证了 MOSN 早期的快速演进和范围覆盖，也兼顾了基本的稳定性需求。\n随着 MOSN 的成熟，MOSN 的接入规模快速增长到了覆盖多个技术栈，数千应用的数十万 pod，涉及蚂蚁内部几乎所有的业务，早期的这些做法也遇到了很多问题。我们接入的应用不再只是 SOFA 技术栈的某些版本，业务也不再局限在某几条链路，大范围变更影响范围数倍甚至数十倍增长，风险变得极高，需要投入大量的人力评估每一个版本变更的影响。 举个例子，早期的 MOSN 几乎只需要考虑与较新版本的 SOFA 的对接。而当 node.js 应用开始接入时，MOSN 的变更也需要相应的考虑对 node.js 应用的影响。\n同样是为了减小风险，变更过程中尽可能减少单位时间的可能的影响范围，变更时长不可避免被拉长。\n早期的 MOSN 可能只需发布数十个应用，当范围扩大到过千时，如果单位时间发布的 pod 数据不变，那么变更时长即增加数十倍，变更的总时长变得荒谬。而如果总时长不变，则影响面和风险增加数十倍，风险不可控，业务也无法接受。\n最终结果是平衡单位时间的影响面和变更时长，风险放大无法避免，整体的迭代周期同样变长。更糟糕的是，新的特性不断堆积在下一个大版本，bugfix 也难以及时上线。这些问题最终不仅推高了下一次变更的风险，甚至直接影响当前生产的稳定。\n这么一个负向的循环需要如何打破呢。我们希望跳出传统的运维模式，既要变更的高效率，又要整体的稳定性。我们希望用技术来解决问题。\nMOSN 的无人值守变更 关于无人值守，一个可以借鉴的定义来源于近年火热的自动驾驶领域。同样都是希望把人从乏味的工作中解放出来，同样都需要面临复杂的环境问题。\n自动驾驶领域的等级定义方式也给了无人值守变更一个很好的参考点。最低级别的是 L0，一切都是人工操作，像云时代之前的时代，从装系统到应用部署，都依赖于人工命令行处理。 然后是 L1，平台提供了原子粒度的变更工具支持和基础的观察工具支持，如同早期的 MOSN。\n当这些工具更完善，提供一些基本的流程编排能力之后，开始进入自动化的时代，但可能随时需要人工介入处理。在此基础上，加上自动化的观测规则，把人工观察介入变成系统自动阻断，变更开始具备了无人值守的基本能力。 历经一年多的演进，MOSN 当前就处于这个阶段。我们也还在持续的完善和打磨，向着完全无人干预的方向演进。\n接下来我们来看 MOSN 是如何逐步达到无人值守的。 首先来看下风险的防控。前面我们提到，在传统的变更流程里面，需要人工介入的有变更范围控制；还有变更准入的检查，变更批次完成后，还要抽查确认变更结果以及业务异常情况。 也就是图上标红的这些内容。\n但是人本身是不可靠的。人为控制变更范围意味着灰度过程无法保证，准入的检查会存在比如信息不同步，规则遗漏的情况，完成情况的检查在大量应用或 pod 同步变更时，也只能做到少量抽检，无法避免问题被漏过。 把人工介入的部分交给系统，我们就有了一个初步可以脱离手动操作和人工观察的流程。\n上图展示了变更防御的介入流程。 变更范围改为由算法来自动产生的带有强度灰度的批次范围。前置准入与后置检查通过将变更类型与变更范围传递给变更防御的检查，通过检查才能继续执行。\n举一个简单的场景。MOSN 覆盖很多不同业务的链路，各业务有不同的变更保护时段，怎么来解决呢？\n首先在已经业务有保护时段的情况下，我们当然不能不管业务的风险强行变更。在有变更自动防控之前，我们只能找个共同的可变更时段，很多时候这就是半夜，但对于 MOSN 这么大规模的变更，半夜变更不仅仅是影响研发和运维幸福感的问题，只有半夜能变更的话，效率也无法接受。而有了变更的自动准入阻断规则，这个时间选择的问题立即就不存在了，我们只需要把所有应用的变更都跑起来，系统自动判断各自的可执行时段，甚至不需要参与变更的各方都知道所有业务的可变更时段。\n变更防控上线以后，极大的解决了我们的变更风险问题。但它并没有解决效率问题，一段时间来看，我们的效率甚至下降了。为什么? 我们分析了自身的变更过程，注意到两点：一是我们引用的业务错误的检查标准不一，部分业务的敏感度偏高或是阈值不合理，导致变更被持续阻断，无法继续；二则我们的全面检查放大了上面的问题，多个批次下来被中断的的概率也极大的提高了\n仔细来看业务的错误检查。这些检查不仅说明了 MOSN 自身的检查，还包括了业务的自身的错误和其它中间件、基础设施的问题。这些检查无法直接说明 MOSN 自身的健康情况。怎么解决呢？我们决定不再依赖这个不靠谱的检查，由 MOSN 自己来说明自己的健康情况。\n我们在 MOSN 中建设了两个层面的健康度观测能力。第一层是静态健康度，主要是 MOSN 的启动自检，在流量进入前完成，体现 MOSN 运行环境和基本启动依赖的健康情况；第二层是动态健康度，主要是 error metrics 日志，体现核心功能运行状态。结合这两层健康层，MOSN 就具备了完整了自身状态的观察能力，可以把业务的错误检查从变更检查中移除。\n我们还做了一个进一步提升变更效率的事情，彻底解决业务冷启动消耗的时间。\n无论是传统的原地升级或者是滚动升级的模式，过程都无法避免业务需要冷启动。由于业务依赖比较多，大部分业务的启动速度和成功率是大幅低于 MOSN 的，因此业务的冷启动时间一直是 MOSN 变更时间的大头。\n一个很好的解决方案是热升级。MOSN 自身是具备热升级能力的，下图展示了热升级的过程。 稍微解释一下的 MOSN 热升级过程。sidecar operator 会给待升级的 pod 注入一个新版本的 MOSN sidecar，旧版本的 MOSN 会收到连接迁移的请求，所有的长连接会被新版本的 MOSN 接管，完成之后旧版本 MOSN 会停止，sidecar container 被删除。\n热升级是一个很理想的升级方式，但是完善的热升级需要的条件和环境都比较复杂，需要 k8s 和 operator 的相应支持，而且被迁移的长连接需要同步的迁移状态，对于 MOSN 内的有状态协议也带来比较大的研发压力。\n我们的选择是把复杂做到了运维侧，做一个相对折中的方式。相对于热升级，这个方案没有那么热，我们称为温升级。 上图展示了温升级的过程。概括起来是三步：关闭待运维 pod 的所有入流量，升级 MOSN 的容器，打开流量。\n温升级去掉了业务的冷启动时间，避免了业务重启失败。MOSN 只需要做好配置的向下兼容，升级过程和传统升级过程几乎完全一样，但成倍的提升了升级效率。\n最后，我们说 …","date":1616677200,"description":" 本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。","dir":"blog/mosn-meetup-4-deploy-automation-at-large-scale/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"aec6af134a0e93f3576b7d5f3fd9101d","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","publishdate":"2021-03-25T21:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","summary":"本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。主要分为 3 个部分： -介绍 MOSN 在规模化运维中遇到的挑战 -无人值守上的实践 -MOSN 与技术风险","tags":["Service mesh","Service Mesh 落地实践"],"title":"mosn的无人值守变更实践","type":"blog","url":"/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","wordcount":3465},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 请教一下：JRaft 的 StateMachine 的 onApply 方法是线程安全的吗？如果在 onApply 里面有一些耗时操作的话，整个应用吞吐会下降很明显吧。\n A：是，对于同一个 st，onApply 必须由 JRaft 的单线程去执行，因为 raft 算法本身需要保证 raft log 被顺序 apply，所以这里没有线程安全问题；把结果同步了就好了，计算别放里头。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@孙军超 提问：\n 请教个问题：我现在直接跑 jraft-example 的 rheakv 的测试代码 PutExample，第一次调用 Rocksdb put 函数总会先阻塞整整 5 秒钟，server 端也没有任何报错。 A：猜测是 DefaultChannelId 里的 getProcessId() 太慢了，或者是 NetUtil 里获取 loopback 地址太慢，有一个办法可以证实：在 main 方法最开始提前 Class.forName 去加载这俩个类，应该会先卡住 5 秒，等到 rheakv 的逻辑执行时就不会卡住了；试一下我上面说的方法，猜测就是这两个类其中之一导致的：https://stackoverflow.com/questions/33289695/inetaddress-getlocalhost-slow-to-run-30-seconds； 配 etc/hosts 生效后可以解决。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@明惑 提问：\n 请教一下：状态机中 onApply 和 onSnapshot 的方式是线程安全的吗，我在这两个方法中操作同一个数据，会不会出现并发问题呢？\n A：onSnapshot 会暂停其他线程；不会有影响，onApply 又是单线程执行的。\nSOFAStack：https://github.com/sofastack/sofastack.tech\n4、@胡志奇 提问：\n Snapshot 的 save/load 方法都将阻塞状态机，应该尽力优化，避免阻塞。Snapshot 的保存如果可以做到增强备份更好。 onSnapshotSave 需要在保存后调用传入的参数 closure.run(status) 告知保存成功或者失败，推荐的实现类似：\n @Override public void onSnapshotSave(SnapshotWriter writer, Closure done) { // 同步获取状态机的当前镜像状态 state // 异步保存 state // 保存成功或者失败都通过 done.run(status) 通知到 jraft } 官网上说的，异步保存也会阻塞？\n A：没有问题，安全的；你截取的内容其实已经说得很清楚了，异步是指存储操作，同步是指获取当前状态机的镜像必须是同步操作；就是说：你必须在状态机被后续的 raft log 更改之前，拿到镜像，也就是拿镜像和 apply 是串行操作，一旦拿到镜像，你可以用异步的方式把镜像保存的磁盘上，甚至再压缩一下。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n5、@闫文超 提问：\n 问下大佬，SOFABoot 启动服务端暴露两个接口，但是 nacos 注册中心只注册了一个 RPC 端口，客户端调用接口报错\n A：SOFARPC + NACOS 有实践案例：https://www.sofastack.tech/projects/sofa-rpc/registry-nacos/ 如果还是解决不了可以上传一个可以复现问题的 demo 工程到 GitHub。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n6、@游侠 提问：\n 请教一下：在 SOFAJRaft，Learner 这种复制器，怎么理解？表示这个节点，只读？\n A：learner 不参与选举，可理解为冷备。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n 可信原生负责人入选“2021年度全球青年领袖”名单\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n ","date":1616137200,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210319/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"196034de19b2d4c77fbe5c88e6721a8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210319/","publishdate":"2021-03-19T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210319/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210319/","wordcount":1712},{"author":"SOFA 团队","categories":"sofagw","content":" 简介：本周将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会重点说明如何解决在安全、互通、接入成本、高效等几方面问题，接着介绍了SOFAGW网关的内部实现架构，最后是SOFAGW网关达成的业务成果。\n 1. 业务痛点 随着业务发展越来越多元化，部分业务域相对比较独立，或因其业务属性，会建立成独立的站点（租户），比如：国际业务和蚂蚁保等。这些站点之间网络是隔离的，但实际业务上会存在一些通信的需求，所以我们碰到的核心问题是：网络互相隔离的多个站点之间怎么做高效可信的通信？对此我们有两种针对站点间互通的解决思路：\n思路1：为每个业务创建跨域 VIP 为每个业务创建跨域 VIP，站点的业务通过 VIP 来做通信。这种方式，运维管理员要在两个网络间开很多 VIP，加访问白名单，最终网络拓扑会变成如下；将面临网络口子多、运维成本高、业务接入成本高、安全阈值低等问题。\n这个方案有以下几个问题：\n 很多服务需要开 VIP 口子，服务多了之后，VIP 难以维护； VIP 的 ACL 控制很弱，只能基于 IP 端口或 IP 段控制，不能按业务应用或服务来做控制； 安全管控能力很弱，对请求不可审计； 业务适配改造工作量大，技术栈不统一，存在多种 RPC 框架。 思路2：实现一个高效可信的互通网关，来承接站点之间的通信代理 这就是我们采用的多站点互相通信的解决方案，下面详细介绍我们的互通方案和重点解决的问题。\n2. 解决方案：SOFAGW 互通网关 鉴于上面提到的问题，我们研发了 SOFAGW 互通网关，致力于实现一个简单高效、安全可信的跨域 RPC/消息 互通网关。\n如上面的整体架构图所示，我们的解决方案是各站点部署一套 SOFAGW 网关，把站点间的通信都收敛到 SOFAGW 上，由 SOFAGW 来保证安全通信，而在研发体验上，业务方同学按照本地服务做开发，不用为跨域通信做特殊处理，做到无缝接入。\nRPC互通过程： 在 SOFAGW 网关上，申请接入需要互通的 RPC 服务。接入后，消费方 SOFAGW 网关会把这个 RPC 服务发布到本站点注册中心上，服务方 SOFAGW 网关会从注册中心订阅这个 RPC 服务提供方地址。 消费方应用通过注册中心订阅到目标服务是本站点的 SOFAGW，把请求发送到本站点的 SOFAGW。 本站点的 SOFAGW 根据 API 配置信息，把请求转发到对端站点的 SOFAGW。 对端站点的 SOFAGW 根据注册中心订阅到的地址，把请求发送给真实的服务提供方。 完成跨展达 RPC 通信。 消息互通过程： 消息的互通和 RPC 互通非常类似，差别主要在于需要通过消息中心来收发消息。\n 在 SOFAGW 网关上，申请需要接入互通的消息服务。 客户端把消息投递到本站点的消息中心，消息中心把消息封装成 RPC 请求发送到本站点 SOFAGW。 本站点的 SOFAGW 根据API配置信息，把请求转发到对端站点的 SOFAGW。 对端站点的 SOFAGW 把请求发送到消息中心，消息中心再把消息投递到真实的消费方。 完成跨站点消息投递。 SOFAGW 互通网关重点解决以下几个痛点：\n2.1 安全通信 首先我们要解决网络不可达问题。从图里可以看到：每个站点都部署了 SOFAGW 网关，网关之间可以用专线或 VIP 之类的产品打通，这样站点间把流量就收敛到了 SOFAGW 网关，避免到处开网络通道口子，便于安全管理。\n网络安全 为了保证 SOFAGW 网关之间的通信安全可信，我们开启了 mTLS 双向认证，既能对数据做加密，也能确认对方的身份可信，从而确保通信安全。\n数据安全 一个站点（租户）会给其他多个站点提供服务，这些暴露的服务首先要确保租户级别的水平权限隔离，也就是说，A 站点暴露给 B 站点的服务，不能被 C 站点的应用调用到。如何做到这点？\n SOFAGW 网关会给不同站点提供不同的访问域名（这些域名都会解析到 SOFAGW 的 VIP 上）。 SOFAGW 之间通过 mTLS 双向认证通过后，可以确认请求的域名（ host ）可信，也就是 C 站点的应用无法用 B 站点的域名与 A 站点的 SOFAGW 网关建立 TLS 连接。 SOFAGW 会通过请求头里的 host + path 路由做路由转发，C 站点的请求无法匹配上提供给 B 站点的域名，也就无法访问到提供给 B 站点的服务。 除了要确保租户级别的水平权限控制，SOFAGW 还具备应用级别的 ACL 权限控制，如果一个 API 服务只暴露给某特定应用，那其他的应用是无法访问这个 API 服务的。\n另外，站点间的通信数据不是任意的，目前在业务 API 接入过程中，我们会有严格的数据安全审计流程。\n2.2 统一技术栈，跨域 RPC/消息 互通 不同的业务方会使用不同 RPC 框架，如 SOFARPC、HSF、Dubbo，底层用的通信协议和序列化协议也不一样，很难直接通信，如果做协议转化适配又会有很大的成本。在性能、扩展性和新特性支持等方面，老的各种协议难以满足发展需求，也很难在原有协议的基础上扩展以支持新的功能。为了更好的支持业务发展，对齐各 RPC 框架通用能力，需要设计一种新的通用的协议，从协议层解决以上问题。\n所以，阿里巴巴及蚂蚁集团共同制定了 Triple 协议，让内部使用的编程框架都支持 Triple 协议，这样大家互通时就会很顺畅。\nTriple 协议是什么？\nTriple 协议本身，是基于 gRPC-over-HTTP2 扩展的 RPC 协议，与现有的其他 RPC 协议比较， 有以下优势：\n 多种 RPC 模式 ( P2P/ Reactive Streams/ Bidirectional / Pub-Sub ) 基于 protobuf 提供统一的服务定义以及 API 治理 更好的性能 ( Protobuf / Protostuff / Back Pressure ) 原生跨语言支持 ( C++/ Dart/ Go/ Java/ Python/ Ruby/ C# / OC / JS / PHP )，原生兼容 gRPC 客户端 易于升级和修改协议 兼容现有的 RPC 框架，易于协议升级和互通 ( gRPC / SOFA-RPC / HSF / Dubbo \u0026amp;hellip;) 对网关型应用友好，原生支持 gRPC-over-HTTP2 支持移动设备原生调用 Triple 遵循 gRPC-over-HTTP2 协议规范，使用 CUSTOM-METADATA 扩展元数据。对于已经存在的 grpc- 开头的 Header 保持不变，保证与原生 gRPC 客户端/服务端互通，对于协议中不存在需要新扩展的 Header，将以tri- 开头。另外，去年发布的 Dubbo 3.0 也是以gRPC为基础，Triple 能和 Dubbo 3.0 保持良好兼容。\n举例，当前我们约定的 Triple 协议头：\n2.3 无缝接入 为了让业务方无缝接入，SOFAGW 网关和注册中心专门做了联动，具体原理从上面的整体架构图可以看到：\n 在调用 …","date":1615878000,"description":"将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会重点说明如何解决在安全、互通、接入成本、高效等几方面问题，接着介绍了SOFAGW网关的内部实现架构，最后是SOFAGW网关达成的业务成果。","dir":"blog/sofagw-cross-domain-communication-solution/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"158827766506b1c5f49729b31a6f66e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","publishdate":"2021-03-16T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","summary":"简介：本周将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会","tags":["Service mesh","Service Mesh 落地实践"],"title":"SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案","type":"blog","url":"/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","wordcount":4308},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@孙军超 提问：\n 请教一下 jraft-rheakv rocksdb 的 get put 操作，耗时要 5 秒钟，是服务端配置需要优化吗？ 以下是我的服务端配置截图。 A：kill -s sigusr2 可以看到性能指标度量，官方文档请看一下有相关说明。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@戚金奎 提问：\n 请教一个问题：如图，目前服务都是通过 openfeign 远程调用，如果 setScore 所在的服务抛出了异常，是能直接出发事务回滚吗（我本地的无法出发回滚），还是需要在这个 seata1 里面接受一下返回值然后抛出异常才可以回滚吗（目前我这边是这种可以回滚）？\n A：决议全局提交/回滚的只能是\n@GlobalTransactional 注解的发起者，它 catch 到异常才会触发回滚；远端的异常应该是没抛给调用者，或者被框架拦截了异常。\nSeata：https://github.com/seata/seata\n@谭玖朋 提问：\n 这两个地方调用 rollback 有特殊意义吗？我发现在此之前没有更新操作啊。 A：这个地方应该是一个编码的习惯，在 autocommit=false 的时候，返回前都做一次 commit 或者 rollback 操作，确保当前的事务能够提交或者回滚，同时释放数据库的锁（哪怕前面并没有事务和锁）。\nSeata：https://github.com/seata/seata\n@戚金奎 提问：\n 请教一个问题：如果出现如图的这种情况， 执行的这个全局事务在获取全局锁之后，会获取 m 字段最新的值，再和自己的 before_image 里面记录的值去比较，发现不一致，全局事务失败并回滚。 A：所有写场景要被 globaltransational 覆盖，不允许直接去数据库改数据。否则就会出现在全局事务被决议回滚的时候，别的地方把这个数据改了。\nSeata：https://github.com/seata/seata\n@姜世存 提问：\n 请教一个问题，这个 LoadLevel 注解有什么作用\n A：所以别的业务要继承 Seata，写入口加入 globaltransational 注解，只读无需加注解。\nSeata：https://github.com/seata/seata\n@winyQ 提问：\n 项目里 Seata 用 AT 模式，可以在项目里再集成 JTA 吗，两个并存有没有什么问题？\n A：JTA 是 XA ，无法跟 AT 兼容。\nSeata：https://github.com/seata/seata\n本周推荐阅读 可信原生负责人入选“2021年度全球青年领袖”名单\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 本周发布 本周发布详情如下：\n1、sofa-common-tools 发布 v1.3.3 版本，主要变更如下：\n 修复 log space factory 的懒初始化模型问题  详细参考：\nhttps://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.3\n","date":1615532400,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210312/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f2a08527a8868ee63936378b903d5b07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210312/","publishdate":"2021-03-12T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210312/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | sofa-common-tools 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210312/","wordcount":1269},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望\n 活动时间：2021 年 03 月 21 日（周日）14:00-17:00\n 活动地点：浙江杭州西湖区学院路77号黄龙万科中心-I座\n 活动形式：线下活动\n 资料地址：点击链接\n 活动介绍 SOFAMeetup 牛年首站：3月21日 杭州见！\n久别重逢，朋友们，SOFAMeetup 回来了。 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁集团超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n本期 SOFA Meetup 将带来 Service Mesh专题： Service Mesh 在蚂蚁、美团的落地后，如何开展能力及基础设施的建设？如何更好的支撑业务发展？在Service Mesh 大规模落地后，MOSN 如何解决变更风险和效率问题？ 如何支撑 Service Mesh 的演进与优化？本次分享将会提供我们一些思考和实践！\n活动议程 本期议题以及嘉宾详解 《Service Mesh 在蚂蚁落地后的探索与实践》\n嘉宾介绍\n李唯，蚂蚁集团技术专家，2017 年加入蚂蚁集团中间件团队。参与了 Service Mesh 在蚂蚁的落地建设，目前主要负责 MOSN 在蚂蚁内部的设计开发。\n议题简介\n Service Mesh 在蚂蚁落地之后的能力建设，结合 MOSN 在蚂蚁的实践和探索，分析 Service Mesh 在大规模场景下持续向前演进的挑战及其背后的思考。 听众收获\n 了解 Service Mesh 在蚂蚁实践过程中遇到的困难和思考 收获 Service Mesh 在赋能业务方面的案例经验与启发\n 收获 Service Mesh 在研发效能方面的最佳实践\n 《MOSN 的无人值守变更实践》\n嘉宾介绍\n黄家琦，蚂蚁金服技术专家，SRE，专注于基础设施与中间件稳定性建设。深度参与了 Service Mesh 在蚂蚁内部大规模生产落地过程中的技术风险能力建设。SOFABolt-Python 组件维护者。\n议题简介\n 自 Service Mesh 在蚂蚁大规模落地之后，MOSN 的变更风险和效率问题愈发突出，本次将介绍从 SRE 视角下对于 MOSN 变更问题的思考，以及对于无人值守变更的实践。 听众收获\n 了解大规模 Service Mesh 下的变更问题与思考\n 收获 Service Mesh 在无人值守变更方面的经验与启发\n 《Service Mesh 在美团的落地挑战与实践》\n嘉宾介绍\n薛晨，美团基础架构团队技术专家，一直专注于分布式系统架构、服务治理领域和基础软件产品化。毕业以来先后深度参与了分布式调度系统、分布式配置服务、PaaS 平台构建和 Service Mesh 方向的探索和实践，在相关领域有较多的思考和沉淀。\n议题简介\n 云原生时代的到来，美团的服务治理系统 OCTO 也向 Service Mesh 的方向演进。作为集团的标准化基础设施，覆盖所有业务线和日均万亿调用，在演进的过程中我们面临着诸多挑战。 如何支撑和更好的支撑业务的发展？如何尽可能的保证演进过程的可靠和丝滑？如何更好的兼顾效率与稳定性？ 听众收获\n 了解超大规模服务治理系统 Mesh 化的最新进展\n 了解 Service Mesh 规模化落地的挑战和应对方案\n 对服务治理和 Service Mesh 未来的一些思考\n 《过往可鉴，未来可期 — MOSN 社区周年回顾与展望》\n嘉宾介绍\n田阳，蚂蚁金服高级技术专家，专注于高性能网络服务器研发，MOSN 开源项目维护者，Tengine 项目成员。\n议题简介\n MOSN 开启开源社区，独立运营已一年有余。在这期间，社区持续投入开源生态建设和云原生演进，并成为了 Istio 官方推荐的数据平面。本次我们将对过去一年的成绩进行回顾与总结，对未来社区的发展进行探讨与展望。 听众收获\n 了解 MOSN 的核心能力和支撑的业务场景\n 了解 MOSN 怎样支撑蚂蚁 Mesh 的演进和大规模落地所做的优化\n 了解 MOSN 后续规划，与 Envoy 社区的合作进展等\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1615273200,"description":"SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望","dir":"activities/sofa-meetup-4/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2619f4f8ba15ac0f4fe43a82ef297db1","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-4/","publishdate":"2021-03-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-4/","summary":"概要 活动主题：SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望 活动时间：2021 年 03 月 21 日（周日）14:00-17:00 活动地","tags":["SOFAMeetup"],"title":"SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-4/","wordcount":1552},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@刘嘉伟 提问：\n 请教一下：我在纯 TCC 事务 a、b、c个服务调用中 c 服务异常了，b 服务回滚日志是 rm handle undo log process: UndoLogDeleteRequest{resourceId=\u0026amp;lsquo;insert\u0026amp;rsquo;, saveDays=7, branchType=AT} 明明是纯 TCC 事务，怎么 AT 都出来了，导致了一个问题：TCC 数据源也没有代理的，也没有相应的 undo log表，然后 AT 事务回滚肯定无效的，TCC 的 cancel 也没有执行。\n A：这个理论上来说是没影响的，定时触发的，跟你本身的回滚逻辑应该没关系；这个 pr 会优化这个点：https://github.com/seata/seata/pull/3501。\nSeata：https://github.com/seata/seata\n@刘嘉伟 提问：\n 请问 AT 模式中如何防止事务回滚时，系统中一闪而过的脏数据，有时页面刚好打开，被用户感知到这些脏数据了；人工处理很麻烦，触发异常因为回滚操作有耗时，脏数据通常怎么处理；TCC 就没有这个问题，隔离的资源用户感知不到。\n A：数据在数据库，在数据库写被隔离的；前端本身就会有脏读出现，要靠后端保证。\nSeata：https://github.com/seata/seata\n@赵勇 提问：\n 比如这个图：A、B、C 各自都有自己的代码、自己的数据库，分开部署的；A 调用 B、C 提供的服务，那 undo_log 要在 db-a、db-b、db-c 里都建一份，然后 A、B、C 的代码里都要引入全局事务相关的类、包， 再加上把 GlobalTransaction 标到 A 的代码上，是这样实现吗；我看 GTS 的文档，感觉 undo_log 是 A 的代码引入的类包去写的，不是 B、C 自己写的，B、C 的代码还是该怎么写怎么写，不需要接全局事务相关的东西。 A：Undo_log 是每一个微服务的业务数据库都要建立，各自维护自己的 Undo_log；如果刚入门了解的话，先看看官网和跑一跑 demo。\nSeata：https://github.com/seata/seata\n@吴宗杰 提问：\n 2020 年 4 月份 Seata 从 1.2.0 支持 XA 协议，Mycat 支持 XA 分布式事务，是不是说明 Seata 和 Mycat 可以一起用？不过看到 19 年 slievrly 有和 Mycat 方沟通，后面应该也会支持的吧。\n A：可以试试，因为 Seata 所谓的 XA 模式是对支持了 XA 协议的数据库的 API 进行自动化的，XA 事务开启和统一提交回滚，Mycat 是属于一种 proxy，伪装的数据库层来代理背后的数据库，不知道这种结合会不会有什么问题存在，特别是 XA 这种出现中间层和 Seata 的兼容问题导致 XA 死锁就麻烦大了。\nSeata：https://github.com/seata/seata\n@谭玖鹏 提问：\n 请教一个问题，这个 LoadLevel 注解有什么作用\n A：看一下 EnhancedServiceLoader#getUnloadedExtensionDefinition 这个函数，跟一下 spi 那块加载的代码就知道了，跟 dubbo 那边差不多，dubbo 有个博客解析：https://dubbo.apache.org/zh/docs/v2.7/dev/source/dubbo-spi/。\nSeata：https://github.com/seata/seata\n@winyQ 提问：\n 不用 Seata 事务的数据操作方法里用的 datasource 还是代理数据源对象，这个没办法改吗，一旦设置 datasourceproxy，好像就一直只能用这个了。\n A：虽然拿到的都是 datasourceproxy，但是没有 globaltransational 和线程中没有 xid 的时候都是不会干预的；内部还是原来的 datasource 做操作，如果你确定没有 2 个服务以上参与的函数，可以用 globallock+ 对要修改的数据进行 for update 先再做写操作，会比直接加 globaltransational 注解效率高，但是相对而言入侵也高了。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 蚂蚁 Service Mesh 大规模落地实践与展望\n ","date":1614927600,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210305/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c5c658590a95eee0eb2c13cfb67d7d49","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210305/","publishdate":"2021-03-05T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210305/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210305/","wordcount":1701},{"author":"雪连","categories":"MOSN","content":" Serverless Task 是蚂蚁集团在分布式调度和批处理中间件发展而来的解决方案。通过 ServiceMesh 的精细化引流能力，再利用研发框架的“服务分组”配置能力，将 Serverless Task 流量全部收敛在指定的“服务分组”集群内。结合定时任务本身具备的周期、可预测等特点，根据任务执行情况弹性伸缩“服务分组”内的机器资源从而提升资源利用率和系统稳定性。\n 分布式调度在蚂蚁的场景和遇到的问题 在单体架构中，为了解决一台机器在固定的周期间隔执行相同的任务，避免人工干预过多，有了基于 Cron 的单机调度；随着企业级应用的发展和微服务化以及云原生架构的逐渐演进，原先的单体架构逐渐演变为服务化或者云原生架构。在此背景下，既要解决原先单机要解决的定时调度问题，还需要解决任务管理、负载均衡以及高可用、容灾等问题，同时兼顾用户体验的简单高效，分布式调度产品就应运而生。\n在蚂蚁域内，分布式调度广泛应用于各个 BU 的业务场景中，举例：如在支付宝上购买基金的用户每天需要计算基金收益，那么就需要在分布式调度的基础上结合批处理的能力，充分利用应用集群的处理能力，完成每一个用户基金净值的收益计算，典型处理场景如下：\n为了充分利用集群的能力，业务会采用按照业务各个维度拆分的方式对数据进行分片，然后根据分片原则加载数据，最后尽可能的将数据分散在集群机器上完成每一个用户基金净值的计算。通过类似上述集群执行的方式，结合分布式调度及批处理的能力，可以完成业务的计算诉求，但是由于这部分计算逻辑被原有的应用集群承载，随着业务的发展和数据量的不断增加，就会有如下的问题：\n稳定性问题：在线流量如 RPC/MSG 等与任务调度流量（简称异步任务流量）在 CPU/MEM/线程池 资源共享而引发的相互抢占导致的稳定性问题。\n资源利用率问题：异步任务流量最常用 Cron 表达式来描述，对于一天 24 小时只需要运行 7 个小时的任务来说，剩余的 17 个小时的资源就是浪费掉的。\n效率问题：业务同学在接入任务调度以及对批处理执行的控制，数据量统计、异常归类和动态调整参数等复杂性导致的研发效率较低；发布上线后，对处理速度、资源容量评估以及稳定性投入导致的运维效率较低。\nServerless Task 解决方案 为了解决上文分布式调度在蚂蚁的多年实践中遇到的问题，我们提供了 Serverless Task 的解决方案。\n通过故障隔离的方式来提高稳定性。Serverless Task 在不影响大家研发习惯的前提下，业务同学只需要通过在 PaaS 平台中，在同一个集群下申请“服务分组”集群，这些机器用于达到只承担异步任务的流量，而屏蔽其他在线流量的访问的目的。机器资源承载的流量做区分后，再配合 ServiceMesh 的精细化引流能力能够将流量收敛在指定的“服务分组”内，同时结合框架的“服务分组”配置能力，能够指定 Bean、消息、任务或者服务是否注册或者启动。通过上述的方式，最终能够实现，指定的异步任务收敛在指定的“服务分组”机器资源内，以此实现在线流量和异步任务流量的故障隔离，避免相互影响，而提升系统的整体稳定性。\n通过弹性伸缩的方式来提高资源利用率。基于可控弹性伸缩 HPA 技术，通过分析任务的 Cron 表达式或者基于 CPU/Mem/线程池等各项正常或者异常指标，能够将隔离在指定“服务分组”内运行异步任务的机器动态调整其 Pod 数量，在满足业务处理诉求的前提下，通过弹性伸缩技术最大化的提升资源利用率。\n提供更加产品化的能力。Serverless Task 支持处理器编排、支持迭代隔离、自定义参数和自定义限流等能力以提升业务的研发效率；同时，异步任务在故障隔离的基础上，利用弹性伸缩技术动态调整业务的 Pod 资源数量，可以让业务研发同学尽可能少的关注资源而只需关注任务的运行情况，以此极大的提升运维效率。\nServerless Task 关键能力介绍 弹性伸缩技术 上文介绍了 Serverless Task 的解决方案思路，为了真正实现 Serverless ，让业务同学不关注容量只关注业务逻辑，一个很重要的技术能力就是弹性伸缩。\n弹性伸缩技术，通过分析任务的 Cron 表达式或者基于 CPU/Mem 等各项指标计算出来的画像（每个时刻期望的 Pod 副本数量），来确定每个时刻的应该 Ready 的 Pod 数量，当在流量低峰或者任务没有在运行的时间就可以将机器缩容到相对较小的副本数。同时为了能够在最短的时间内恢复业务 Pod 的运行，启动速度是一个至关重要的指标，采用基于 ServiceMesh、JVM Elastic Heap 和内存 swap 的容器保活技术实现极速启动，来保证业务容器再恢复到期望的副本数时，有足够快的速度。\n 任务链路隔离与伸缩能力 通过上面描述的 Serverless Task 的解决方案，能够将异步任务的流量收敛在一个业务集群指定的“服务分组”集群内，并能够在弹性伸缩的基础上充分利用机器资源。但是，这样就会导致新的问题，当上游系统被隔离后，其处理速度和稳定性都会一定程度的增加，但是对下游的调用量就会激增，导致下游出现热点或者稳定性问题。基于此，我们提供了任务链路的解决方案，期望将 Serverless Task 触发异步任务的门面系统以及对下游系统的调用，都能够通过“服务分组”的方式隔离开，期望组合成一条异步任务流量作为入口流量的任务链路，具体的实现方案如下所示。\n每一个 Serverless Task 在周期触发时都会自动携带染色标识（每一个异步任务的唯一标识），通过在任务调度平台选择当前异步任务要引流到的“服务分组”，就可以完成门面系统的 Serverless Task 到指定“服务分组”的引流。每一次 Serverless Task 调用门面系统均携带染色标识，门面系统紧接着对下游系统再发起调用，门面系统结合控制面的业务引流能力，就可以在控制面对门面系统下发引流规则，并配置流量比例，便可以将门面系统对下游系统的调用也收敛在指定的“服务分组”集群内。以此类推，下游系统如果继续有对后续系统的调用，也可以采用类似的方式推送引流规则来完成指定调用流量的“服务分组”集群收敛，以此来完成一条 Serverless Task 作为入口流量的任务链路的流量隔离，并具有单独的业务语义，比如：批扣链路、计价链路。\n在完成了任务链路的隔离之后，由于入口的流量是由异步任务驱动或者触发的，流量是能够通过 Cron 或者运行状态做比较准确的预测，那么在任务链路执行完毕后，就可以将整个链路的资源全部伸缩掉，同样当异步任务的流量高峰到来之前时再扩容出足够的机器资源，以此在隔离出任务链路的同时，还能提升整体任务链路的稳定性以及整个任务链路的资源利用率。\n总结与展望 通过 ServiceMesh 的精细化引流能力，可以将 Serverless Task 流量收敛在指定的“服务分组”集群内，再利用框架（如 SOFA Boot）的“服务分组”配置能力，控制非期望的 Bean 和服务在“服务分组”集群内关闭，最终就能够做到将 Serverless Task 流量完整的收敛在指定的服务器集群内，达到流量收敛的目的后，再结 …","date":1614668400,"description":"如何实现任务调度和存量应用的 Serverless 化，本文为大家介绍 Serverless Task 是如何实现这一解决方案。","dir":"blog/antgroup-serverless-task/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cb83515191621dc518d49a84ac297f0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-serverless-task/","publishdate":"2021-03-02T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/antgroup-serverless-task/","summary":"Serverless Task 是蚂蚁集团在分布式调度和批处理中间件发展而来的解决方案。通过 ServiceMesh 的精细化引流能力，再利用研发框架的“服务分组”配置能力，将 Serverless Task 流量全部收敛","tags":["Serverless","任务调度","弹性伸缩","ServerlessTask","Service Mesh"],"title":"Serverless 给任务调度带来的变化及蚂蚁集团落地实践","type":"blog","url":"/sofastack.tech/blog/antgroup-serverless-task/","wordcount":2748},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@宓文明 提问：\n 请教：大家有没有遇到过 SOFAArk 工程这样的情况：双机房集群部署（检查模块 jar 大小相同、MD5 相同、部署时间相同），其中一台服务器中报错 NoClassDefFoundError（调用模块工具类的静态方法时，工具类找不到），其余的服务器都 OK。 A：你们登录到机器上去，堆栈是有的；这种问题可能是因为底层有 class 没找到，两个思路： - 版本冲突 ，不一定局限在你的 JsonUtil 这个类，里面的类也有可能引发 。 - 通过 arthas ，分析下不同 bizClassLoader 加载 JsonUtil 的情况。\nSOFAArk:https://github.com/sofastack/sofa-ark\n@郭强 提问：\n MOSN 是如何保证一定是先于业务容器启动，并且保证是后于业务容器销毁呢？\n A：启动就是按 pod 里的容器顺序启动，MOSN 容器在 APP 容器前。APP 容器内的应用进程启动前会检查 MOSN 的端口是否存活，得等到 MOSN 进程启动完成才能继续。销毁 pod 的时候没有特别处理，就是摘了pod 的流量整个销毁。\nMOSN:https://github.com/mosn/mosn\n@郭强 提问：\n APP 容器内的应用进程启动前会检查 MOSN 的端口是否存活。 这个是怎么做到的呢，是自动修改应用容器的 command 配置？还是说需要应用进程的 dockerfile 保证一定规范吗？\n A：蚂蚁内部的 Kubernetes 有针对性的做一些定制改造支持，标准 k8s 目前是控制不了容器启动顺序的； 最好的方式还是 k8s 原生支持 sidecar lifecycle，没有这个的话，相对折中的方式就是在应用启动脚本前 check 下了。\nMOSN:https://github.com/mosn/mosn\n@饶文强 提问：\n 请教一下：我不是很理解这一步锁撤销的步骤：线程 A 进入同步代码块方法，尝试获取偏向锁，此时若 CAS 线程 id 替换失败，为什么涉及一个偏向锁撤销，线程 A 不是没有获取到锁。我的理解是此时锁对象的偏向锁线程 id 不是线程A本身，为什么还需要偏向锁撤销？ A：因为偏向锁可以被降级，其他的不可以，这个时候需要升级锁或降级锁；偏向锁持有者是不会做降级操作的，只有前来竞争锁的线程会去判断。\nSeata:https://github.com/seata/seata\n@莹 提问：\n 有个场景：tcc 模式，try 方法创建订单记录，插入到数据库，然后异常回滚，在 rollback 方法中把这个订单记录根据主键删除，请问数据库主键字段怎么传过去？\n A：可以通过一阶段把 xid 对应业务信息存在 redis 中，二阶段通过 xid 拿出来使用。\nSeata:https://github.com/seata/seata\n@敲跃 提问：\n 问个问题：Seata 的 at 和 saga 模式 一阶段本地事务已提交，为了防止这部分数据被其他事务读到，文档给的解决方案 \u0026amp;gt; 脏读 select 语句加 for update，代理方法增加 @GlobalLock+@Transactional 或 @GlobalTransaction ； \u0026amp;gt; 实际操作的时候：涉及到本地事务的表的所有 sql 和方法都要这么改造，会不会成本太大，有没有其他好点的解决方案？\n A：涉及到所有的写入口加上 @GlobalTransaction 即可；只读场景 @GlobalLock +for update 即可；读了就写场景一定要 @GlobalTransaction，只读了给前端展示之类的。\nSeata:https://github.com/seata/seata\n本周推荐阅读 Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 蚂蚁 Service Mesh 大规模落地实践与展望\n 基于 MOSN 和 Istio Service Mesh 的服务治理实践\n ","date":1614322800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly20210226/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fff3af65c30bb18078a3222b86261205","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly20210226/","publishdate":"2021-02-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly20210226/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly20210226/","wordcount":1351},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@王盛 提问：\n 这个配置在 sidecar 里面怎么改，这个怎么配到 Istio 里面?\n A：在 Istio 中关于 tracing 这块的 driver 目前是通过配置 xxx_bootstrap.json 静态配置的，然后通过 istioctl 命令参数来选择使用哪个 driver。当前由于 skywalking 自身配置还没作为 bootstrap 的静态默认配置，所以需要你自己修改下 xxx_bootstrap.json，这个配置就好了（即把上面的那个配置加进去）。简单说就是修改下 sidecar 的静态默认配置文件，增加 skywalking 为 tracing 的 driver 配置。\nMOSN：https://github.com/mosn/mosn\n@卞平超 提问：\n TCC 多阶段；rollback 可以设置顺序吗？比如被调用的服务，先回滚，再回滚主服务的，A-\u0026amp;gt;B，想先回滚 B 的数据，commit 和 rollback；方法中的业务代码有异常，是会不断的重复执行。\n A：TC 的表字段 datetime 看下精度，二阶段都决议了，没有从 commit 异常，直接到 rollback。如果 10 个参与方，就 1 个 commit 异常，不去重试保证最终一致的话，数据不就乱了；已经决议了，就要保证起码能最终一致，而不应该串改结果，参考消息队列设计，为什么消费异常要重试。\nSeata：https://github.com/seata/seata\n@方舟 提问：\n 请问一下，在 TCC 模式中，如果 TM 和 TC 断开连接，能够保证全局事务的回滚吗，重连超时后，全局事务会回滚吗？\n A：会重连，然后重试；需要你自己保证幂等和悬挂，会等你连上之后再重试。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁集团轻量级类隔离框架概述 | SOFAArk 源码解析\n 蚂蚁集团研发框架总览 | SOFABoot 框架剖析\n SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理\n 蚂蚁集团 API Gateway Mesh 思考与实践\n 本周发布 本周发布详情如下：\n1、SOFARPC发布 v5.7.7版本，主要变更如下：\n 使用 Github Action 替代 Travis 进行持续集成 升级 jackson-datebind 到 2.9.10.7 升级 junit 到 4.13.1 修复了Rest中，当请求经过代理源IP获取不准确的问题 修复了内置 Protobuf Compiler 的 BUG 详细参考：https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.7\n","date":1613718000,"description":"SOFA WEEKLY | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210219/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"29b9f9ae46cecd6979ce334f8e11baf0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210219/","publishdate":"2021-02-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210219/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210219/","wordcount":1096},{"author":"李唯","categories":"云原生","content":" Service Mesh 双十一后的探索和思考(上) 引言 2019 年 Service Mesh 在蚂蚁大规模落地并完美支撑双十一核心链路，对于落地过程在去年已经有系列文章解读。而在此之后的一年多时间，Service Mesh 在蚂蚁又在如何演进呢。本文介绍蚂蚁 Service Mesh 在双十一落地之后所做的探索和思考。\n能力建设 得益于 Service Mesh 将业务和基础设施解耦，在过去一年中我们的基础设施能力得到了飞快的发展。大量能力大规模落地蚂蚁。例如链路加密，可信身份认证，服务鉴权，自适应限流，集群限流，精细化引流，服务自愈等。这里先对四个能力进行解读，其它能力后续再有文章讲述。\n链路加密 为了达到一个更高的安全水位，我们预期在蚂蚁内部所有的通信 100% 加密覆盖，这就是链路加密。\n设计 链路加密落地最大的挑战就是加密对业务不能造成影响，包括几个问题：\n 必须简化大规模场景下的运维复杂度问题，需要具备可灰度、可回滚的能力； 灰度运行期间，明文和加密切换不能对业务请求造成影响，需要进行热切换； 开启加密以后，对性能的影响必须控制在可接受的范围内； 基于这些需求，完成了链路加密的架构设计，主要思路包括：\n 通过统一的管控面控制服务端应用的配置，基于动态服务发布与订阅机制，在服务端支持加密能力以后，客户端自动进行加密的切换，运维人员只需要控制服务端配置节奏完成灰度；在灰度运行期间，服务端同一个端口需要同时支持明文和加密的能力； 相比于明文通信，基于 TLS 加密的通信主要消耗在连接建立的握手期间，服务端和客户端采用长连接的方式，减少连接的建立，以减少开启加密对性能的影响； 客户端在感知到服务端明文和加密状态变化以后，需要在不同的长连接之间进行稳定的切换，后文会详细介绍； 完整的一个加密开启流程如图所示，首先运维人员在管控面选择需要开启加密的应用，通过 XDS 完成配置下发。MOSN 在收到配置以后，会基于 SDS 机制获取到证书和私钥在内存中，证书和私钥由统一的 Secret 进行管理，应用侧不持久化保存。收到证书和私钥以后，会向注册中心发布本机已经支持了加密，注册中心会向所有订阅的客户端进行推送，客户端收到推送以后，与服务端的通信切换到加密状态。\n加密状态热切换：连接淘汰机制 我们的加密通信是基于 TLS 进行的实现，一个连接在建立好并且开始传输数据以后，连接上的数据是 TLS 加密的还是明文的就已经固定了，不存在将一个明文通信的连接变成 TLS 加密连接的情况。基于 TLS 这个机制，通信从明文切换到加密时，一定是需要新建一个连接，并且成功完成 TLS 握手。\n为了做到在连接切换期间业务请求不受影响，MOSN 实现了一个连接淘汰机制，用于连接加密状态的热切换。 每一个请求在 MOSN 中经过了路由和负载均衡以后，会选择到一个后端地址，基于这个地址从连接池中选择对应的长连接转发请求，在引入了加密切换以后，每次选择到连接以后，都需要判断当前预期的加密状态和连接的加密状态是否匹配，如果不匹配，则会创建新的连接进行加密状态的切换，并且使用新连接将连接池中的旧连接代替，这样就可以确保后续的请求都使用状态匹配的连接。对于被替换的旧连接，我们需要进行淘汰，但是这个淘汰不是简单的断开连接，因为旧连接上可能还有正在处理的请求，如果直接将连接断开就会导致请求有损，这是不能接受的。\n那么是如何淘汰旧连接的呢？这里就要讲到 MOSN 的长连接保持机制了。为了避免因为异常断网等导致连接“假死”的情况，在连接空闲时，会主动发起心跳请求，确保连接处于活跃状态，而如果服务端一段时间内都没有收到心跳，则会主动将连接断开。连接淘汰就是利用这个机制，对于准备淘汰的连接，我们将停止该连接的心跳发送，当连接上的请求处理结束后，这个连接上就不再会有任何数据的传输，经过一段时间后，服务端就会主动将这个连接断开，此时连接断开是安全的，不会影响任何请求。 优化 对应用无感知开启加密，除了指开启过程中不需要重启、请求无损等，还包括在开启以后的资源消耗、RT 影响也需要是无感知的。在实际落地应用过程中，由于我们都是使用长连接，TLS 握手带来的建连消耗只占用了很少一部分，在长连接通信过程中的对称加密消耗经过实际测试几乎可以忽略不计，看上去链路加密对性能的指标没有什么问题。\n但是在实际大规模落地以后，我们发现部分应用开启了加密以后，内存占用有显著的上涨，经过排查，定位到属于Golang TLS 标准库实现问题（ MOSN 是使用 Golang 编写的），我们自行优化以后，也向 Golang 官方提了 PR回馈社区，目前该 PR 已经被 Golang 官方所接受，预计在 go1.16 中发布，具体实现可以见 crypto/tls: pool Conn\u0026amp;rsquo;s outBuf to reduce memory cost of idle connections\n自适应限流 流量管理本身就是 Mesh 架构最为核心的功能之一，我们在 MOSN 中实现了多种策略的限流能力，包括单机 QPS限流、集群限流、热点限流、接口熔断、自适应限流等，其中自适应限流是一大亮点。\n限流是每个技术同学都不陌生的名词，同时也是很多不同角色的同学头疼的事情。对于业务同学而言逐个接口做容量评估和压测回归费时费心，有限的精力只能投入到重点的接口保障上，难免会漏配一些小流量接口的限流；而负责质量和稳定性保障的同学经常在故障复盘时看到各种漏配限流、错配限流、压测故障、线程阻塞等造成的各种故障\u0026amp;hellip;\u0026amp;hellip;\n我们希望即使在系统漏配错配限流的情况下，在系统资源严重不足时 MOSN 能够精准的找到导致系统资源不足的罪魁祸首，并实时根据系统水位自动调节异常流量。这就是自适应限流想要实现的效果。\n技术原理 能用一句话说清楚你们的技术原理吗？ 类 PID 控制流量闭环自适应调节 朴素的解释就是，触发限流后一边观察系统整体水位，一边秒级按比例调节流量的策略，用一张图来解释具体的原理： 1.系统资源检测：秒级检测系统资源占用情况，如果连续超过阈值N秒则触发基线计算，同时开始拒绝压测流量进入； 2.基线计算：将当前所有的接口统计数据遍历一遍，通过一系列算法找出资源消耗大户，再把这些大户里明显上涨的流量找出来，把他们当前的资源占用做个快照存入基线数据中； 3.基线调节器：将上一步骤存入的基线数据根据实际情况进行调整，根据系统资源检测的结果秒级的调整基线值，若系统水位超过阈值则按比例下调基线值，否则按比例恢复基线值，如此反复； 4.限流决策：根据上述步骤生产的基线数据决策是否限流；\n自适应限流已在全站线上应用中大规模启用，成功防范了多起业务故障。为新春红包压测和线上业务保驾护航。\n技术优势 相较于传统的限流组件，MOSN 中的自适应限流具备很多优势，MOSN 架构天然的流量劫持让应用无需逐个接入SDK，也无需为特定语言开发不同版本的限流组件，同时给业务同学降低了配置的难度，也为业务实现了兜底保护。在研发效能和研发成本上都取得了明显的收益。\n MOSN 自适应限流 传统 QPS …","date":1613548800,"description":"本文介绍蚂蚁 Service Mesh 在双十一落地之后所做的探索和思考。","dir":"blog/service-mesh-exploration-thinking-after-1111-1/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3a08e94a57454e3ef36f8eee6da6795e","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","publishdate":"2021-02-17T16:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","summary":"Service Mesh 双十一后的探索和思考(上) 引言 2019 年 Service Mesh 在蚂蚁大规模落地并完美支撑双十一核心链路，对于落地过程在去年已经有系列文章解读。而在此之后的一年多","tags":["云原生"],"title":"Service Mesh 双十一后的探索和思考(上)","type":"blog","url":"/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","wordcount":5691},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" 本文作者：蚂蚁集团黄挺（花名鲁直），SOFAStack 社区主理人，同时负责蚂蚁集团云原生方向的推动和落地，包括 Service Mesh、Serverless、消息、微服务等领域，带领 SOFA 团队扎根技术完成很多落地实践。\n 大家好，我是鲁直，有段时间没有和大家见面，今天是农历一年的起点，首先祝大家新年快乐，在新的一年牛气冲天！在这样特别的日子里，我想和大家分享对于 Service Mesh 未来方向的思考，再谈谈 SOFAStack 社区接下来计划做的一些事情，希望大家接下来能够在社区里面玩得开心，let\u0026amp;rsquo;s have fun together! Service Mesh 是否已经解决了所有问题？ 2020 年， SOFA 团队宋顺（花名齐天，当前蚂蚁集团 Service Mesh 负责人）在 QCon 上海站分享了《蚂蚁 Service Mesh 大规模落地实践与展望》，详细讲述了 Service Mesh 在蚂蚁集团的进展和未来规划。 在过去的几年里面，Service Mesh 在整个云原生社区如火如荼地发展，从刚开始的 Linkerd，到后面的 Istio，不断地有大公司加入到 Service Mesh 的领域的开拓之中，随着小剑、净超等同学在国内布道 Service Mesh，Service Mesh 从 2017 开始在国内火热程度也不断升温，SOFA 团队也在这个时候开始关注到 Service Mesh 这个领域，并且开始在内部尝试做落地的事情，也和业界的很多朋友一起举办了一场又一场的 Service Mesh Meetup。\n应该说我们是幸运的，成功在 2019 年实现了 Service Mesh 在蚂蚁大促业务链路上的全面落地，获得了大规模落地 Service Mesh 的经验，并且在这之后持续应对 Service Mesh 大规模落地之后的遇到的各种挑战，截止到 2020 年底，蚂蚁集团已经基本上实现了在线业务的全面 Service Mesh 化，在一部分网关场景上，也采用了 Service Mesh 的架构，实现了南北向和东西向流量架构的统一。\n但是随着 Mesh 化的进程不断地往前推进，一直在我们心中萦绕这一个问题，Service Mesh 在一定程度上解决了基础设施和业务耦合的问题，但是是否已经把所有的问题都解决完毕了？这个问题的答案显然是没有全部解决完毕，这个尚待解决的问题还是基础设施和业务耦合的问题。\n目前包括蚂蚁集团在内的各种各样的 Service Mesh 的解决方案，都是会选择采用尽量透明的方式去适配应用已有的协议，让业务尽量减少接入 Service Mesh 的成本，即使不是全透明的方式，而是采用瘦 SDK 的方式接入（蚂蚁集团目前采用了这种方式），也是为了这个目的。在这种形态下，应用固然可以透明地获得非常多的能力，包括限流，服务发现，安全通信等等，但是一旦涉及到 RPC 协议的变化（从 SOFARPC 到 gRPC），后端缓存的变化（从 Memcached 到 Redis），应用还是需要去修改代码适配新框架的 SDK，这又是一件无论让应用还是让基础设施团队非常痛苦的事情，本质上还是应用去适配基础设施的变化，而不是反过来。\n###\nService Mesh 的未来方向：Cloud Native Application Runtime 那么我们应该如何去解决这个问题？在一次内部的会议上，我们和几个同事在讨论如何对 K8s 里面我们自定义的 Operator 进行规范化的问题，防止一个有问题的 Operator 把整个 K8s 搞挂了，但是一个同事提出了 Operator Framework 的想法，在 Operator 里面运行一个 Sidecar，这个 Sidecar 提供 Operator Framwork 的能力，这里面给了我们一个启发，可以用 Sidecar 这种模式去实现一个开发框架，一个运行时，来更好地帮助业务屏蔽掉对于后端基础设施的访问，我们看到业界也出现了这样的一些产品，比如 Dapr，CloudState 等，在这种模式下 Sidecar 已经不是一个简简单单的 Proxy，而是一个 Runtime，我们把这种形态称之为 Cloud Native Application Runtime。\n这种模式之所以可以称之为 Cloud Native Application Runtime，关键还是 Sidecar 定义了一套面向应用的 API，这套 API 正是解耦应用和基础设施的关键。有了这套 API Spec，就相当于在应用和基础设施之间构建了一层防腐层，只要这一层 API Spec 能够持续往前保持兼容，后面的基础设施不断地演进和变化，都不会动到应用侧，基础设施和应用之间才能够实现更加彻底的分离，未来基础设施无缝升级才会成为可能。未来云原生的应用在不同的云之间迁移，甚至基于多朵云来构建应用，应用这一侧也不用重复进行适配的工作，应该说，这种模式也是符合未来混合云的方向的。所以，我们大胆的预测，未来 Service Mesh 持续往前继续演进，必然会发展到 Cloud Native Application Runtime 这样的方向。\n基于这样的思考，在 2021 年，SOFAStack 社区一方面会继续推进已有的项目的健康发展，另一方面在继续在Service Mesh 的方向上深耕：继续分享在 Service Mesh 领域上的一些新思考之外，比如 Service Mesh 大规模落地之后的研发效率和运维效率的解决思路，我们也会和社区中的其他的组织一起通过 Service Mesh 的 Meetup 等活动继续推动 Service Mesh 的理念在国内的影响力，以及企业落地实践。（PS：最近 MOSN 刚刚公布了 2021 年的 RoadMap，欢迎大家关注：https://github.com/mosn/mosn/issues/1559，其他项目的 RoadMap 也会在春节后陆续和社区讨论然后公布；我们计划在 3 月份举办一次 Service Mesh 的 Meetup，欢迎感兴趣的社区同学报名)。\nSOFAStack 开源社区即将成立三周年，SOFA 团队深刻地体会到一个开源项目的持续健康地发展，关键在于社区和社区中的每一位开发者，是你们每一个 star，每一个 issue 和 PR 推动着项目的成长。特别感谢接近三年时间，大家一同参与社区建设，感谢一起帮助社区成长的小伙伴们。SOFAStack 开源社区还有很长的路要和你们走，我们也会联合其他社区一起推动 Cloud Native Application Runtime 的理念的落地和实践，希望有更多开发者可以和我们一起去探索 Service Mesh 的未来形态，一起推动其成为云原生应用构建的一种标准方式。\nAwesome SOFAer, then awesome SOFAStack， Let\u0026amp;rsquo;s have fun together！\n","date":1613113200,"description":"Special Weekly | SOFAStack 社区牛年展望，Let's have fun together!","dir":"blog/sofa-weekly-20210212/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3ef0208984bc034e62f2db51cf66a8e4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210212/","publishdate":"2021-02-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210212/","summary":"本文作者：蚂蚁集团黄挺（花名鲁直），SOFAStack 社区主理人，同时负责蚂蚁集团云原生方向的推动和落地，包括 Service Mesh、Serverles","tags":["SOFA Weekly"],"title":"Special Weekly | SOFAStack 社区牛年展望，Let's have fun together!","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210212/","wordcount":2162},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@李明阳 提问：\n SOFAArk 的项目里面 controller 层可以是 Biz 包么，这样 mng 里面引入 one，然后启动 mng 访问不到 one 里面的接口呢？ A：SOFAArk 的项目里面 controller 层不限制的，biz 包部署普通的依赖包，它是一个可执行的 jar，ark包 = biz + plugin + container，动态部署你可以通过 telnet 指令的方式去动态安装，不建议直接塞到 pom 里面去。\nSOFAArk：https://github.com/sofastack/sofa-ark\n@王盛 提问：\n 请教个问题：\u0026amp;ndash;set meshConfig.defaultConfig.binaryPath=\u0026amp;ldquo;/usr/local/bin/mosn\u0026amp;rdquo; 这个不起作用，有谁碰见过这个情况？ A：你用的是 istio1.5.2 吧，这个是不行的，istio 代码写死了的。这种手动注入应该可以的。这一块儿有些细节没有说明，你可以重新提交一下 pr。 MOSN：https://github.com/mosn/mosn\n@杨星 提问：\n 如果 Seata 使用注册中心的话，Client 端的 registry.type，与 config.type 需要改成对应的注册中心吧，Client 端的这两项配置的作用是什么？SeataServer 的这两项配置倒好理解，Client 端的config.type 目的是读取client端的配置信息，那 registry.type 是干什么的呢？\n A：我认为，registry.type 指的是注册中心的类型，config.type 指的是配置中心的类型。注册和配置中心是 2 个东西，我认为是从注册中心里拿 seata-server 实例，客户端找协调者。\nSeata：https://github.com/seata/seata\n本周推荐阅读 干货 | 蚂蚁集团是如何实现经典服务化架构往 Service Mesh 方向的演进的？\n 开源 | SOFAMesh 的通用协议扩展\n 【剖析 | SOFAMosn】系列之 SOFAMosn 的诞生和特性总览\n Service Mesh 发展趋势：云原生中流砥柱\n MOSN 项目进展 本月我们还认证了一位新的 Committer，是来自字节跳动的 郑泽超 同学，感谢 郑泽超 同学为 MOSN 社区做出的贡献。\n本周发布详情如下：\n1、MOSN发布 v0.21.0 版本，主要变更如下：\n 限流模块升级与优化，支持自定义过滤条件等能力 为适配路由支持变量机制对部分常量名进行了不兼容的删除和新增，可能会影响部分基于 MOSN 的代码编写 新增了 DSL(Domain-Specific Language)的路由支持 StreamFilter 模块支持加载基于 Go 动态连接库编写的 Filter 基于 XProtocol 实现了 DubboThrift 协议的支持 其他 BUG Fix 与优化 详细参考：https://github.com/mosn/mosn/releases/tag/v0.21.0\nSOFABoot 项目进展 本周发布详情如下：\n1、SOFABoot发布 v3.6.0 版本，主要变更如下：\n 支持本地开发时自动将 SOFABoot 日志输出到控制台 startup endpoint 采用新的数据格式，支持按时间轴分析 修复 baen 加载耗时的图形化展示问题 修复 ReadinessCheckListener 的启动顺序问题 SOFARPC 升级版本至 5.7.7 SOFATracer 升级版本至 3.1.0 SOFA-common-tools 升级版本至 1.3.2 Tomcat 升级版本至 9.0.37 使用 Github Action 进行CI 移除默认的 Maven Profile 配置 详细参考：https://github.com/sofastack/sofa-boot/releases/tag/v3.6.0\nSOFATracer 项目进展 本周发布详情如下：\n1、SOFATracer 发布 v3.1.0 版本，主要变更如下：\n 修复 flexible result.code 返回成功、失败 code 码 修复 DubboSofaTracerFilter Server span tag value error 修复 SofaTracerFeignClient 中 UnsupportedOperationException 问题 优化 spring mvc filter 的 error tag 支持 kafka 支持 RabbitMQ 支持 oracle rac JDBC URL 支持 hikari 详细参考： https://github.com/sofastack/sofa-tracer/releases/tag/v3.1.0\n","date":1612508400,"description":"SOFA WEEKLY | MOSN、SOFABoot、SOFATracer 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210205/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4cde1d3e68e2e13cbca7278164a4ab12","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210205/","publishdate":"2021-02-05T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210205/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、SOFABoot、SOFATracer 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210205/","wordcount":1518},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@潘麒安 提问：\n 请教下 session-server 报这个错，是需要扩更多的 session 么，但是 session进程本身 CPU 和内存占用不高。 A：看错误是把 session 发向 data 的处理队列打满了，可以排查一下，检查一下使用的版本，data 的资源使用和common-error.log 下的错误日志。\n SOFARegistry：https://github.com/sofastack/sofa-registry\n@刘达 提问：\n MOSN 怎么配置监听一个端口，这个端口上会接受有多种协议的数据，根据协议转发到不同的集群地址。ISTIO+MOSN， 用户 http 请求 gateway，通过 gateway 调 dubbo，每个应用自动注入 sidecar，测试没跑起来。 A：配置 Auto，支持协议自动识别，转发不同的集群，那就看路由了；用新版本，然后这样配置。 MOSN：https://github.com/mosn/mosn\n本周推荐阅读 剖析 | 详谈 SOFABoot 模块化原理\n 网商银行是如何建设金融级云原生分布式架构的？\n 实操 | 基于 SOFABoot 进行模块化开发\n 开源 | SOFABoot 类隔离原理剖析\n SOFABolt 项目进展 本周发布详情如下：\n1、SOFABolt 发布 v1.5.7 版本，主要变更如下：\n 优化 log4j2 日志配置，解决在异常场景下的性能问题 详细参考：https://github.com/sofastack/sofa-bolt/releases/tag/v1.5.7\nsofa-common-tools 项目进展 本周发布详情如下：\n1、sofa-common-tools 发布 v1.3.2 版本，主要变更如下：\n 修复 LogCode2Description 性能问题 详细参考：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.2\n","date":1611903600,"description":"SOFA WEEKLY | SOFABolt、 sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210129/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4f4f43ac764d4c99010c408e4d53c92e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210129/","publishdate":"2021-01-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt、 sofa-common-tools 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210129/","wordcount":934},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@叶毅威 提问：\n 请教下 SOFARegistry 数据持久化在哪里啊?\n A：SOFARegistry 的元数据（注册中心自身的 IP 列表之类的数据）存储在 meta 角色内，使用 JRaft 进行存储。 应用的发布数据保存在 data 角色的内存中，采用三副本（可配置）的方式实现高可用。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n@叶毅威 提问：\n 我用 SDK 调用注册了一个 datainfo 但是关掉之后 这个并没有下线，是哪里需要配置么，不是默认链接断开就下线么？\n A：session 上采用 HTTP 方式获取的数据都是当前节点的注册数据，只有 data 上才会做数据聚合。 dataInfo 是不会被删除的，连接断开后对应 dataInfo 下的对应 Publisher 会被自动移除。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n@田冲 提问：\n 现象：canal 监听到某个被分布式事务控制的表的 insert-binlog 日志后再去查询 MySQL 表里数据时发现这条数据不存在，延迟1秒钟左右再查询就能查询到。 疑问：seata-at 模式-两阶段提交的设计会出现 MySQL 先生成了 binlog 日志，后提交事务的情况吗？\n A：这个问题其实很简单，你 canal 读不到，那你自己应用本地事务提交后马上读这个 insert 的数据看能不能读到；如果读到，理论上来说这个过程不可能超过一秒，所以如果你应用能查到，你canal查不到，排查canal的问题，而不是 Seata 的问题；Seata 最后也只不过做了 connection.commit；最后事务的提交落库是数据库方本地事务流程落库，Seata 不会起到任何干扰，Seata 代理的是 jdbc 层的处理；redo 后写 binlog 时马上就会广播的，而不是事务提交才把 binlog 广播出去；所以内 xa 的二阶段没提交你就去查主库，由于隔离级别不一定查得到。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Kubernetes 是下一代操作系统 | 面向 Kubernetes 编程\n 蚂蚁集团生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理\n 蚂蚁集团服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析\n 开箱即用的 Java Kubernetes Operator 运行时\n ","date":1611298800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210122/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"16aa2c7282629fe75b244cdce08845e7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210122/","publishdate":"2021-01-22T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210122/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210122/","wordcount":1098},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@吴小彬 提问：\n 请教下，如果分支事务中使用了分库分表中间件（shardingsphere-proxy、mycat 等），Seata-AT 模式是不是不能用的？是只可以用 TCC 模式吗？现在的 shardingsphereProxy 中间件（不是 shardingsphereJdbc ）用 AT 模式，它对微服务来说就是一个 MySQL 连接，它是怎么知道微服务调用链中的 xid 的？\n A：可以用，shardingsphere 4.1 支持 Seata AT， proxy 我估摸着有点悬，因为他属于一个代理层。Jdbc 是直接在应用的 Jdbc 层提供服务的，所以 AT 可以很好的支持。\n@谭玖朋 提问：\n 在关于 AT 模式，第一阶段执行完后生成行锁然后注册分支事务，其中的行锁具体是指什么锁呢？因为发现第一阶段执行完后，其实再查数据的话是已经改变了。所以关于这个行锁这么解释？\n A：Select for update 的时候，首先 Seata 会代理这个语句，去查询 TC 这个行有没有锁住，如果没锁住，客户端业务用了 for update 那么就拿到了本地锁，此时因为本地锁排他，这个时候没有全局锁的 for update 就是分布式下的读已提交。 不是允许脏读，是读已提交。读未提交是默认的，所以只有在你 update 的时候（update 是当前读），但是如果你的 update 是基于快照度的 select 结果，可能会出现事与愿违的结果，如果你要基于某个数据来 update，要么 for update 来读分布式下的已提交，要么就用 update x=x-1 之类的写法，因为提交时会抢占全局锁，没抢到会 rollback，释放当前锁进行重试，这样就能保证抢到锁的时候，update 的数据当前读是分布式下的读已提交并修改 目前好像没人写关于 AT 行锁及全局锁部分源码有分析讲解的资料，如果感兴趣可以去阅读一下，写出来投稿给我们。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Mecha：将 Mesh 进行到底 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 Service Mesh 和 API Gateway 关系深度探讨 Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍 Occlum 项目进展 Occlum 发布 v0.19.1 版本，主要变更如下：\ni.同时兼容 Glibc 和 musl libc的应用\nii. 支持基于 DCAP (Intel SGX Data Center Attestation Primitives) 的远程验证\niii. 修复了内存泄漏问题\n详细发布报告： https://github.com/occlum/occlum/releases/tag/0.19.1\n","date":1610694000,"description":"SOFA WEEKLY | Occlum 发布新版本，Seata QA 整理","dir":"blog/sofa-weekly-20210115/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"48d18f44f20f4b6d5f8b219e383bfa51","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210115/","publishdate":"2021-01-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210115/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Occlum 发布新版本，Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210115/","wordcount":1106},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王家爵 提问：\n SOFABoot 项目要一两分钟才能启动，目前这边有监控工具可以看到启动过程中各个步骤的耗时吗？\n A：3.6.0 之后可以通过 actuator/startup 查看启动的耗时分布。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n@东仔 提问：\n SOFABolt 的最新分支是哪个？\n A：master 就是最新分支。https://github.com/sofastack/sofa-bolt\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\n我是一个小胖子 提问：\n 请问现在已经支持自适应限流了吗？\n A：开源版本里有基于 sentinel 的自适应限流，这个你可以看看 sentinel-golang 的文档，但是和我们内部用的自适应限流有一些差异。\n 你们内部不用 sentinel 是吗？\n A：也用，我们基于 sentinel 做了一些扩展。\n「MOSN」：https://github.com/mosn/mosn\n来永国 提问：\n 为什么我起了 RPC 服务端客户端和注册中心，然后连接调用是可以的，然后我把注册中心关了，它还是跑得通？\n A：client 会有缓存的。\n 获取注册中心的服务有 API 接口吗?\n A：有的，有个从单机 session 获取数据的接口 curl localhost:9603/digest/pub/data/query?dataInfoId=com.test.SimpleService#@#DEFAULT_INSTANCE_ID#@#DEFAULT_GROUP dataInfoId 参数需要进行 url encode 应该还没公开的 API 文档，获取数据的 HTTP 接口也不太易用，我最近会补一下文档还有方便使用的接口。\n 那看样子这个相当于是指定搜索了吗？\n A：是的，目前没有模糊查询的接口， curl localhost:9603/digest/getDataInfoIdList 你可以用这个 API grep 一下。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1610607600,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20220114/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7e0323f9034710384e38cbb6f2176adf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220114/","publishdate":"2021-01-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220114/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220114/","wordcount":1222},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@梁俊 提问：\n 有一台物理服务器，没有安装 OS，是不是可以把 Occlum LibOS 像通用操作系统一样当做 host OS 用，运行 Occlum LibOS，需不需要在物理服务器上安装 host OS?\n A：Occlum 对硬件也是有要求的。这个机器需要支持 Intel SGX 技术。简单得说，就是必须可以安装 SGX 驱动。 Guest OS 是虚拟机的概念，从 guest OS 的角度看，OS 依然运行在 kernel 态。简单来说，如果想使用 Occlum，那么建议方案： 1 . 找一台 SGX 机器 （比如 W55）； 2. 安装一个OS，并且装上 SGX 驱动； 3. 安装 Occlum；\n Occlum 相对于 Docker 有哪些优势，比 Docker 快吗?\n A：Occlum 的优势是安全。外界无法探测运行在 Occlum 中的程序和这个程序使用的内存以及寄存器。也就是说，可以把机密信息（比如密钥）放在 Occlum 中而不用担心信息泄露。\nOcclum：https://github.com/occlum/occlum\n2、@李天宇 提问：\n 可不可以定义一个这样的准则每个 RPC 后面，必须得有一个 TM，每个 TM 维护一个 TM 块，RPC +1，就应该等于 TM 块？ A：这样一个完整的链路有多少个参与者，发起者可以获得，校验规则就是 spanid 是否与参与者数量 +1，是否相等？认为 RPC 向下的服务资源都是一个完整的事务，不管它是否与 db 交互，即可以无 RM ，我的想法就是让 TM 发起者，可以随着链路信息感知所有的 TM。 Tm 可以在每个微服务上都标注下 注解，默认是加入到之前的事务中。TraceId 可以塞到 Seata 的协议中传递到 RPC 下游。\n3、@李天宇 提问：\n 支持不同 branch 不同的 type 吗？\n A：AT 和 TCC 可以共存，Saga 不行。比如 a 数据在 AT 下被改，又被 Saga 或者 xa 分支改动，因为它们不是 AT 无法通过全局锁保证隔离性，除非所有的模式只要内部含有 AT 分支，都去获取全局锁，这样带来了一个问题，如何提前知晓某个 TM 的调用链路中有 AT 分支，靠用户注解上写，那入侵性就有点大了。\nSeata：https://github.com/seata/seata\n本周推荐阅读 SOFAEnclave：蚂蚁机密计算如何解决现实挑战？ 蚂蚁集团宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 开源项目是如何让这个世界更安全的？ 网商银行是如何建设金融级云原生分布式架构的？ MOSN 项目进展 本周发布详情如下：\n1、MOSN 发布 v0.20.0 版本，主要变更如下：\n 路由模块进行了优化与重构，支持变量机制与可配置的扩展模式 使用的 Go 版本升级到了 1.14.13 支持 XDS 非持久化模式下配置的热升级 完善支持了 Netpoll 模式 其他一些新功能、优化与 Bug Fix 详细参考：https://github.com/mosn/mosn/releases/tag/v0.20.0\n","date":1610089200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20210108/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"86ee4a89adc2c475c6f406d2774743c8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210108/","publishdate":"2021-01-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210108/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210108/","wordcount":1294},{"author":"小蚂蚁","categories":"SOFAStack","content":" Forrester 认为：\n包括容器、微服务与服务网格等领域在内的云原生平台，将成为构建适应未来的现代企业的核心引擎。\n在常态化混合异构环境下，面对云原生应用路径的多样化趋势与全维度挑战，企业必须将服务网格技术与微服务有效结合，才能真正释放云原生技术的红利。\n近几年云计算发展如火如荼，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施的统一资源调度带来了极大挑战。\n在越来越复杂的异构基础设施上，存量应用和增量应用应该如何上云？面对大量异构基础设施带来的挑战，企业如何最大化上云价值？\n服务网格（SOFAStack Mesh）是蚂蚁集团自主研发的基于金融级生产实践的增强版服务网格平台，将传统微服务和 Service Mesh 技术进行了深度融合，其核心技术经过了蚂蚁集团的大规模生产实践验证。\n它深度、无缝对接了 SOFAStack 经典应用服务和容器应用服务，为客户提供了简单易用的 Service Mesh 架构的支撑平台。目前， 服务网格已经广泛应用在大型金融机构。\n近日，蚂蚁集团联合 Forrester 公司发布了《蚂蚁集团服务网格总体经济影响》（以下简称白皮书）。\n白皮书基于蚂蚁集团云原生分布式架构 SOFAStack，结合客户使用的成本节省情况和业务收益，为企业上云提供新的路径方法与参考实践。\n白皮书首先系统地分析了全球企业在资产现代化、数字化等市场趋势下面临的风险与挑战，面对挑战。Forrester 提出适应未来 (Future Fit) 的技术战略模型。\n即以客户为中心，帮助企业快速重构业务结构和能力，调整运营方式，以自适应性、创造力和韧性满足未来客户和员工的需求。而平台、实践与合作伙伴将成为构建这一技术战略的关键因素。\nForrester 认为，包括容器、微服务与服务网格等领域在内的云原生平台将成为构建适应未来的现代企业的核心引擎。\nForrester 在报告中指出，在常态化混合异构环境下，面对云原生采用路径的多样化趋势与全维度挑战，企业必须将服务网格技术与微服务有效结合，才能真正释放云原生技术的红利。\n具体而言，企业技术决策者与实践者应当积极拥抱服务网格技术，并致力于在以下四个方面实现异构分布式环境下的策略化、平台化赋能：可观测性、微服务治理、灰度发布与部署、微服务框架可管理性。\n 可观测性 通过服务网格，Sidecar 代理可以主动观测相关微服务的调用关系，并将链路信息进行统一日志记录。而企业级的服务网格监控工具，应当可以对服务网格产生的遥测数据进行分析与关联。为企业开发与运维团队提供可视化的链路拓扑、实时的监控报告、基于策略的告警，以及分布式追踪与故障定位能力。\n 微服务治理微服务 主要治理能力还包括服务发现、流量治理、安全通信和应用弹性伸缩。服务网格通过基于策略的运行状况检查、动态路由、自动重试、服务熔断、服务降级、服务限流等机制提升微服务运行时的可配置性与健壮性，从而显著简化异构环境下微服务治理的技术复杂性。\n 灰度发布与部署 服务网格提供对调用方与服务方透明的灰度代理开启机制和有效的回滚机制，从而实现一体化、精细化与智能化的灰度发布与部署能力。在保障业务连续性与客户体验稳定性的同时，加速客户价值交付。\n 微服务框架可管理性 借助服务网格，企业能够将服务治理能力从各类异构的微服务框架下沉到服务网格所在的基础设施层面。而微服务框架自身只需要聚焦业务核心实现和语言差异性，从而实现微服务框架在服务治理层面的轻量化。\n面对技术发展和市场需求，蚂蚁集团在近十多年五代架构的演进过程中，经过充分的迭代和验证，逐渐沉淀出了一套金融级分布式架构 SOFAStack。\n其中的服务网格产品 SOFA Mesh 是基于 Istio 开源项目研发的企业级云原生网络通信方案，为分布式应用提供流量管理、安全加密、可观察性、服务治理等能力，实现灰度发布、蓝绿部署、滚动升级，助力企业数字化转型。\n蚂蚁集团数字科技事业部产品总监马振雄认为，相比于其他上云方式，Service Mesh 能够实现跨平台、跨协议，并且业务代码无侵入改造。从而快速地将应用植入 Sidecar 完成 Mesh 化，获得分布式红利、安全可观测，并且整个架构平滑演进。企业在架构升级过程中可以按部就班、循序渐进，并且实现端到端的安全可信以及全链路可观测能力。\n蚂蚁集团客户的访谈提到，Forrester 发现无论是传统金融机构还是互联网金融机构，都面临在混合架构下存在的共性挑战，包括基础设施升级换代、应用开发升级、云上云下交互等方方面面。\nForrester 表示，对于金融机构而言，网格服务在单体应用改造成本、云原生环境开发人员效率提升、运维安全管理效率提升以及替代旧有系统等方面能实现明显的降本增效。通过研究三年数据测算，使用蚂蚁服务网格产品后，其客户的投资回报率达到 99%。\n以某资产总额超一万亿的省级农信为例。\n随着金融科技的迅速发展，该银行积极加速数字化转型。在转型过程中，遇到了异构系统难以统一治理，技术栈绑定等一系列问题。蚂蚁集团 SOFA Mesh 帮助该用户：\n构建全行级通信网络，异构系统服务治理， 低成本云原生落地，实现无侵入平滑上云，无需修改业务代码，无需考虑依赖关系；\n同时支持架构灵活演进，兼容 ESB 等传统异构系统，帮助客户最大化上云价值。\n此外，SOFA Mesh 还能够实现以下重要的非量化重要收益：\n 统一监控能力 SOFA Mesh 能够实现传统技术栈和云原生环境的统一监控，提升问题定位效率。\n 精准故障定位 对于已完成了微服务化改造的服务云原生环境来说，服务网格提供了强大的流量管控能力，通过调用链精准定位故障。\n 故障复盘资源消耗节省 对于监管要求极高的金融企业，在故障出现后要进行全面复盘，以确保系统未来的可用性，避免类似事故发生。但复盘也消耗大量开发运维人员的时间，对工作效率产生影响。\n 组件能力提升 解耦后的微服务的公共组件、业务组件、及安全组件都得以实现性能上的提升。\n未来，蚂蚁集团希望和更多合作伙伴一起，借助 SOFAStack 以及服务网格的成功实践经验，让更多企业用户低成本上云，迈向数字化云原生的新时代。\nSOFAStack 社区为了能提供更好更优质的内容来满足大家的需求、口味\n特别设计了本次的问卷，大概占用您 2 分钟的时间～\n我们会选取 5 份认真回答的问卷送出SOFAStack 社区的 2022 限量新年礼物\n快扫描二维码一起写问卷吧～\nhttps://www.wjx.cn/vj/rXjIC9b.aspx\n本周推荐阅读 「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\nService Mesh 双十一后的探索和思考(下)\n","date":1609743600,"description":"服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书","dir":"blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9fdc287491ed68fe45196c70d88a67c9","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","publishdate":"2021-01-04T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","summary":"Forrester 认为： 包括容器、微服务与服务网格等领域在内的云原生平台，将成为构建适应未来的现代企业的核心引擎。 在常态化混合异构环境下，面对云原生应用路径","tags":["SOFAStack"],"title":"服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书","type":"blog","url":"/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","wordcount":2531},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News  SOFA 社群元旦快乐！新的一年我们也要在一起哦！\n同时，也有一个好消息要和大家共享： MOSN 荣获 「2020 年中国优秀开源项目」，感谢所有开发者们的支持和喜爱，MOSN 团队会继续努力，提供更好的开源产品和服务，也期待大家的持续共建。\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@苏榴结 提问：\n 对于某个全局事务来说，向 tc 注册说你是 tm 也是 rm，但因为这个全局事务已经有了 tm，所以它就会被认定为rm 是吗？\n A :服务起来的时候就跟 TC 说了你可以做 TM ，也可以做 RM (分别建立一个长连接与 TC 通信)，然后在需要进行某个全局事务的时候，如果他是发起全局事务的那个，那么他就发挥了他 TM 那部分职能，如果他是负责操作数据库，那他就发挥了 RM 那部分的职能。\n2、@刘亚飞 提问：\n 为什么图 1 中描述用协程池来处理可读 conn，图 2 中，又说每一个 conn 有一个读协程呢？是因为图 1 描述的是 rawpoll 模型下的代码方式，而图 2 是 goroutine-per-connection 模式下的一个 write goroutine 池化吗？\n 图1\n图2\nA：图 1 图 2 属于两种模型。Rawpoll 模型的话就是自己做 epoll_wait，有可读事件从协程池拿一个协程来读取数据；协程模型的话就是一个连接一个协程，标准的 go 编码模式，runtime 来处理 epoll_wait，可配置选择不同模式。\n本周推荐阅读 云原生网络代理 MOSN 的进化之路 基于 MOSN 和 Istio Service Mesh 的服务治理实践 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 SOFA项目进展 本周发布详情如下：\n1、SOFA-Common-Tools 发布 1.3.1 版本：\n 修复多 classloader 场景下 commons-logging 的兼容性 修复 SOFAThreadPoolExecutor 被删除的方法，提高向下兼容性 详细参考: https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.1\n2、SOFA-Ark 发布 1.1.6 版本：\n 支持插件扩展，通过宿主动态扩展指定 plugin 依赖和导出关系 SOFA-Ark-manve-plugin 支持打包按规则排除依赖（from file） 详细参考： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.6\n","date":1609398000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201231/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ca60ed7c9ac011477c8861c0f5650629","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201231/","publishdate":"2020-12-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201231/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA 社区元旦快乐，MOSN 荣获 2020 中国优秀开源项目","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201231/","wordcount":994},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@薛帅领 提问：\n 多数据源切换后，增加事务但不起作用（切数据源是执行方法后才切换的），本地事务及 Seate 分布式事务也不行，这个有什么好的解决方案吗？\n A：Spring 本地事务注解本身就不支持多数据源事务，且如果你开启了本地事务，之后并不会进入你的切换数据源的切面。 在多数据源下，去掉本地事务注解就好了。用 globaltransactional 注解在多数据源的入口加上，多个数据源都被 Seata 代理的话，就会保证多数据源的事务。\n2、@李天宇 提问\n 如果在分布式事务中，另一个线程做批处理 update 之类的，是否会锁住呢?\n A：不会，另一个线程也要记得加上 globaltransactional 注解就行了。在 a 线程要提交之前要去尝试拿到它修改数据的全局锁的，如果 a 拿到了，但是还没到二阶段提交，b 也是要去尝试拿，拿不到就会不执行 SQL，等待全局锁释放了，也就是 a 发起的事务结束了，b 才能执行 SQL 提交。这样就保证了利用全局锁（粒度行级），来达到隔离性。\nSeata：https://github.com/seata/seata\n相关推荐阅读 Kubernetes: 微内核的分布式操作系统 走出微服务误区：避免从单体到分布式单体\n 网商银行是如何建设金融级云原生分布式架构的？\n 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构\n SOFA 项目进展 本周发布详情如下：\nSOFA-Common-Tools 发布1.3.0 版本，主要变更如下：\n SOFA 线程池支持 ScheduledThreadPoolExecutor 与 ThreadPoolTaskScheduler 新增 SofaConfigs 支持统一的配置获取 新增 LogCode2Description 支持统一的错误码获取 重构线程池实现，支持更丰富的监控数据 所有组件统一 spce 属性获取逻辑 修复配置日志输出到控制台时不生效的问题 详细参考：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.0\n祝大家圣诞节快乐！\n","date":1608879600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201225/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"59bc2ae2a6b06f7ca356aeb61a6c78fd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201225/","publishdate":"2020-12-25T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201225/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA-Common-Tools 发布新版本， QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201225/","wordcount":963},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@缪文 提问:\n SOFA-Boot 框架，模块隔离时，子 module 中引入 mybatis 框架，@MapperScan 注解是在RootContext 中扫描，还是在子 module 中扫描？\n A: 非 auto 的 configuration 都是在对应模块进行解析的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n2、@李扬 提问：\n 分支事务被回滚是同步还是异步的,如果是异步的,能加监听方法吗?\n A：可以实现 transactionhook 这个类，然后在 tm 发起者里加入到 Transaction HookManager#registerHook 。这样在二阶段决议后，可以做一些小动作，比如二阶段提交的时候，再执行 redis ，mongo 的数据插入。\n3、@吴国柱 提问：\n 本地事务与全局事务一起开启会有问题吗？\n A：全局事务要在本地事务的外层,就是包裹本地事务，不能由本地事务包裹全局事务。本地事务出异常都不会进行注册，也就代表本地事务如果出问题本地事务自行会回滚(基础知识)，如果本地事务提交了，其它服务的本地事务出现异常，或者业务代码出现异常，将有 Seata来负责把已提交的事务回滚。\nSeata：https://github.com/seata/seata\nSOFAChannel 部分合辑 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 蚂蚁集团分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁集团分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 相关推荐阅读 剖析 | 详谈 SOFABoot 模块化原理 蚂蚁集团研发框架日志隔离解析 | SOFABoot 框架剖析 蚂蚁集团研发框架总览 | SOFABoot 框架剖析 ","date":1608274800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201218/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"712d560758c60f16cc7d2651bb781e65","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201218/","publishdate":"2020-12-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201218/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 线上直播合辑整理，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201218/","wordcount":949},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 【12/07 - 12/11】每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@bruce 提问：\n SOFAJRaft 可以实现在三个节点中选出一个 leader , 其他逻辑由自己实现吗?\n A：可以，可以不用状态机，也不用加载和持久化快照, 只需要选个 leader。 \u0026amp;gt; 各个节点如何知道自己是主还是从?\nA：示例 2、@李明 提问:\n 全局事务执行过程中，有其他线程操作数据库，这时全局事务执行失败，在回滚的时校验数据发现数据被修改过，导致回滚失败，这种情况怎么避免?\n A：其他线程也加上 global transactional 注解。分布式事务下，没有单个分支是独立的个体存在，需要拿到全局事务中，让其他事务知晓他的存在，从而避免在分布式调用链路中，恰好遇到同一个数据进行修改时，发生的脏写脏读 globallock 是在更新前去 tc 看下这个时候这个数据有没有被其他事务锁定，没有的话就说明这个数据没有被其他事务使用，是提交的数据，所以这叫读分布式事务下的已提交。 但是他并没有去注册分支，也就是他没有去占有这个全局锁，来达到分布式事务下的排他性。他在得到 tc 响应的时候，去执行 update 是有时间的，此时有个分布式事务下的分支 update 后，拿到了全局锁，然后他的链路二阶段是回滚 ，但是数据就被你这个认为没有全局锁的本地线程给改了，这就导致被干扰无法回滚。 所以 globallock 需要配合 sql 语句，在 update 前，先做 for update 这个数据，拿到这个数据的本地锁，拿到本地锁之后，再去 tc 判断有没有全局锁，如果 tc 没有锁，因为本地已经拿到本地锁了，具有本地事务的排他性，其他分支事务拿不到该数据的本地锁，是无法去注册分支去拿到全局锁，也就是禁止了其他分支事务的干扰，所以不会脏写。 目前 tcc 下一般就是 globallock+select for update 来防止被其他 at 事务改动后，进行了脏写。\n3、@ 尚攀 提问:\n Raft 是为了解决目前的什么问题？\n A: 依赖外部存储。AT 有 before 镜像、after 镜像，after 镜像是在 undo_log 表里存储，那么 before 在哪里存着了？未来的 Raft 模式，集群支持动态扩缩容，事务信息存储在内存中（测试下来比 redis 快），现在的全局事务信息，分支事务信息，全局锁都是持久化到 db，或者 redis 去的。如果这个时候持久化用的 db 宕机了，Seata-Server会不可用，而集成了 Raft ，leader 宕机后自动选举新 leader，继续运转。所以，利用 raft 一致性算法，可以让多个Seata集群内存中的数据保持一致。\n相关推荐阅读 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑\n 蚂蚁集团生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理\n 蚂蚁集团 SOFAJRaft 优先级选举剖析 | 特性解析\n 剖析 | 蚂蚁集团生产级 Raft 算法 SOFAJRaft 合辑\n Seata 项目进展 本周发布详情如下： 发布 Seata 1.4.0 版本，主要变更如下：\n 支持 yml 配置文件 支持 Oracle nclob 类型 支持客户端最少的活动负载均衡 支持客户端一致性哈希的负载均衡 支持 Spring Boot 使用自定义配置中心和注册中心 支持配置默认全局事务超时时间 多处 BUG 修复和功能优化 详细参考：https://github.com/seata/seata/releases/tag/v1.4.0\n","date":1607670000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201211/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dc10639aea7c443d918ac8f8355ed64c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201211/","publishdate":"2020-12-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201211/","summary":"SOFA WEEKLY | 【12/07 - 12/11】每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是","tags":["SOFA Weekly"],"title":"SOFA Weekly | Seata 发布新版本， QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201211/","wordcount":1418},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@刘江涛 提问： \u0026amp;gt; 已知在同一个分布式事务中，各个 RM 的模式都应该与对应 TM 模式相同。那同一个微服务可以多种模式并存吗？比如 AT , XA , Saga 并存，然后 A 业务使用 AT 模式，B 业务使用其他模式之类的。\nA：不可以，隔离性无法得到保证。如果要一起用，就要保证一条调用链路中所有数据的隔离性，也就是跟 AT 一样都得去竞争锁，而且 Saga，TCC 之类的对 SQL 没要求，可能在跟 AT 一起使用的时候就有要求了，得不偿失。\n 如果公司要引入多种模式的话，微服务之间的关系是这样的吗？\n A ：是的，当然 AT 集群是可以调 Saga 集群的，但是他们不能属于同一个全局事务,也就是 AT 那个事务提交了，Saga 的如果回滚了，是 Saga 集群的问题，等于有 2 个全局事务的诞生。 Seata：https://github.com/seata/seata\n相关推荐阅读 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化\n 云原生网络代理 MOSN 透明劫持技术解读 | 开源\n 基于 MOSN 和 Istio Service Mesh 的服务治理实践\n 云原生网络代理 MOSN 的进化之路\n MOSN 项目进展 本周发布详情如下： 1、MOSN 发布了 v0.19.0 版本： - 重构了 StreamFilter 框架，提供更强的可复用的能力 - 支持 MaxProcs 可基于 CPU 使用限制自动识别的能力 - 支持指定 Istio cluster 的网络 - 针对高并发场景的内存使用进行了优化 - 多处BUG修复\n详细参考：https://github.com/mosn/mosn/releases/tag/v0.19.0\n","date":1607065200,"description":"SOFA WEEKLY | 【11/30 - 12/04】每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201204/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4123f0805fdf3799cbafcc143f8d6bac","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201204/","publishdate":"2020-12-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201204/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本、 Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201204/","wordcount":843},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech\n SOFAStack：https://github.com/sofastack\n 社区 Big News  SOFAStack 获得 2020 年度 OSC 中国开源项目评选「优秀 Gitee 组织」，感谢所有开发者们的支持和喜爱，SOFA 团队会继续努力，提供更好的开源产品和服务，也期待大家的持续共建。 2020 年度 OSC 中国开源项目评选结果公布\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张松 提问： \u0026amp;gt; SOFARPC 支持提供者注册的时候配置一个标识，然后消费者根据这个标识来获取到对应的服务提供者吗？类似于对服务提供者做一个分组。\nA：你是指 SOFARPC 的 unique-id 吧，支持的。 \u0026amp;gt; 不是，类似于分组的配置，因为我这边现在需要多环境，要来区分同一个注册中心下的同一个接口的不同分组。\nA：SOFARPC 就是用 uniqueId 来区分同一个接口，不同实现的。SOFARPC 没有 group 的概念，只有一个 uniqueId，需要服务方和调用方配置一样，强隔离的。 SOFARPC：https://github.com/sofastack/sofa-rpc\n2、@徐泽唯 提问： \u0026amp;gt; 自动降级以后如果调用的服务抛错了 数据是不是就不对了？\nA：自动降级只是发起者那边发现 SeataServer 不可用后，不去走 begin 。你业务数据就完全没全局事务的允许运行，是会出现数据不一致。比如seata-server宕机了，后续的服务因为 Seata-Server 宕机，不走分布式事务，此时全局事务有部分数据是需要回滚的，但是由于Seata-Server宕机了，导致没法回滚，这个时候不经过全局事务的事务执行就会导致数据不一致。所以说，tc 最好集群搭建，以免宕机后，降级代表了你允许 at 模式下数据不一致。 Seata：https://github.com/seata/seata\n相关推荐阅读 蚂蚁金服微服务实践 | 开源中国年终盛典分享实录 火了 2 年的服务网格究竟给微服务带来了什么？ 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下： 1、SOFAJRaft 发布了 1.3.5 版本： - 增加对IPv6的支持＃526 ＃527 - 升级\u0026amp;rsquo;rocksdb\u0026amp;rsquo;到5.18.4以支持AArch64\n- 优化：心跳响应不经过管道直接发送，避免管道影响心跳响应的及时性 详细参考：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.5 2、SOFABoot 发布 3.4.6 版本: - 支持手动 readiness 回调（健康检查二阶段） - 扩展点失败反馈健康检查，默认为否 - 提供上下文隔离场景下获取所有 Spring 上下文的标准方法 - Bean 加载时间和层级树形分层显示\n详细参考：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.6\n","date":1606460400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201127/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f379c4483cff2807f5cfe8c6bbab5d8c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201127/","publishdate":"2020-11-27T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201127/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/23 - 11/27】SOFA Weekly | SOFAJRaft 、SOFABoot发布新版本，SOFAStack 获优秀 Gitee 组织奖","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201127/","wordcount":1352},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech\n SOFAStack：https://github.com/sofastack\n 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@小刘 提问： \u0026amp;gt; 刚开始用 Seata ，方法上用了 @GlobalTrasactional + mybatis 插入一条数据的时候返回的自增id不正确,取消@GlobalTrasactional用普通的事务@Trasactiona 插入数据的时候返回的自增 id 正常了。\nA: 这个基础是有问题的。全局锁的作用是锁定并发修改时的数据的，不是针对接口。接口并发肯定是多线程走的，不可能阻塞等待排队。 Seata：https://github.com/seata/seata\n2、@初识 提问： \u0026amp;gt; 防悬挂是怎么理解的？能简单说说吗？\nA: 保证一致性，幂等用的。比如a-\u0026amp;gt;b，因为特殊原因，比如全局事务超时，b注册上了分支事务，本地事务的 commit 还没执行的时候，全局事务回滚下发到了，如果这个时候本地事务 commit 了，那么数据就不一致了，所以全局事务回滚下发到了，会插入一个 undolog ，让本地事务 commit 的时候因为 undolog 唯一索引冲突使本地事务提交失败，触发回滚，保证了当全局事务状态是回滚时，分支事务都是回滚的。 当然，如果是 commit 了，再收到下发回滚，因为 commit 了已经有 undolog了，那么会通过 undolog 回滚，这个针对的是没有 undolog 时的情况。\n**3、@StevenCheney **提问： \u0026amp;gt; Nmosn 的版本 和 Istio 有对应关系吗？\nA：目前的 Master 支持 1.5._，但是上次看1.5._的时候有一些注入的问题，你可以看一下 feature-istio_adapter 这个分支，最近应该会合并一些pr进来，到时候可以直接适配1.7._，理论上1.6._也是可以支持的，需要测试一下。 \u0026amp;gt; Docker image 会同步更新吗？\nA：主要是看你的需求，如果你是只要 MOSN ，不要 Envoy，就直接使用https://github.com/istio/istio/issues/23753 这个来打包，如果你都需要的话或者说不介意多一个 Envoy，就直接使用 proxyv2 打一个就好了。 MOSN：https://github.com/mosn/mosn\n本周推荐阅读 蚂蚁智能运维：单指标异常检测算法初探 蚂蚁宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 企业数字化转型指南，《SOFAStack 解决方案白皮书》正式发布 SOFA 项目进展** 本周发布详情如下： 1、SOFA-Common-Tools 发布1.2.1版本：\n 重构了本地控制台输出日志逻辑； 移除了 log-sofa-boot-starter 相关代码； 详细参考： https://github.com/sofastack/sofa-common-tools/releases/tag/v1.2.1\n","date":1605855600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201120/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a81d6649eb11649a90e54eef8a5a57e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201120/","publishdate":"2020-11-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201120/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/16 - 11/20】SOFA-Common-Tools 项目发布新版本、Seata、MOSN 相关 QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201120/","wordcount":1234},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@杨文鹏 提问：\n 感觉 SOFAArk 在静态合并部署情况下,和 SOFABoot 的类隔离起到的作用是一样的？不知道我理解对不对。\n A：SOFABoot 没类隔离，它的类隔离就是继续 SOFAArk。 \u0026amp;gt; 比如新建一个 SOFABoot 应用，需要再手动集成 SOFAArk 吗？\nA：需要的。\n SOFABoot：https://github.com/sofastack/sofa-boot SOFAArk：https://github.com/sofastack/sofa-ark 2、@倪绍东 提问：\n 如果是提交阶段有数据库失败了，其他成功的怎么办呢，没办法了吧？\n A：一阶段提交,二阶段不可能提交的情况下还失败，XA 本地事务一阶段持久化在数据库层面不可能丢失，本地事务undolog跟redolog了解一下。对 Seata-server 来说保存了事务状态，如果二阶段有节点执行失败，就重试，直到成功。也就是你节点二阶段执行失败，自己了解下为什么你数据库出问题了，而不是分布式事务有什么问题。 \u0026amp;gt; 会不会出现重试过程中，其他事务修改了现有数据，而最终又被重试成功的情况?\n A：二阶段提交代表了什么？代表了整个调用链是成功的，一个成功的分布式事务，一阶段已经持久化了，你再去改，这个数据又不是脏的有什么问题？XA 来说，本地事务的本地锁先了解一下，一阶段不提了，锁被本地持有，如何修改？本地排它锁都没释放，何来脏写。\n3、@李艺渊 提问：\n Seata TCC 模式下，订单微服务和库存微服务。订单微服务try阶段添加订单信息，现阶段可以支持在库存微服务try阶段获取订单信息吗？或者说能把创建好的订单信息存储到 Seata-server ，然后在其他微服务可以获取到吗？\n  A：我理解 Server只负责全局事务的流转，try 出错就 cancel ，成功就 commit。Try 里面对两个库操作，正常是可以拿到数据吧。 \u0026amp;gt; 这2个微服务是分开部署的，数据库也是分开的。像订单微服务的 try 阶段，把订单信息存储到 order 数据库了。那库存微服务是不会去访问 order 数据库的。现在就是看库存微服务如何获取到新增的订单信息，看有没有什么 好的方式。\n Seata：https://github.com/seata/seata Service Mesh 相关推荐阅读 Service Mesh 中的可观察性实践 陌陌的 Service Mesh 探索与实践 - 直播回顾 Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 Apache SkyWalking 在 Service Mesh 中的可观察性应用 ","date":1605254400,"description":"【11/9-11/13】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201113/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"59cb50e2977d5e0b3ad675ca234c2b0f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201113/","publishdate":"2020-11-13T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201113/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 相关阅读合集、SOFABoot 以及 Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201113/","wordcount":1270},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、《Service Mesh Webinar#4:阿里云 CDN 微服务架构演进之路》直播回顾以及 QA 整理 视频回顾地址：https://www.bilibili.com/video/BV13D4y1R7do/\n@道酉 提问： \u0026amp;gt; 请问阿里云 MOSN 两个容器的热更新怎么实现的，就是怎么在pod内添加一个容器再去掉一个\nA：我们其实也没用跨容器热升级的方式，两个 Pod 挂载相同目录的方式是支持的。\n@陈鹏 提问：\n 请问一下同一个容器的热升级是怎么做的呢？\n A：我们是通过 RPM 升级的方式，容器内 systemd 管理的进程。\n@梁昌泰 提问：\n 重启不叫热升级吧？\n A：没有重启哈，直接起来一个新的进程。\n2、@谢子华 提问：\n Seata Saga 中，TC 的作用是什么？在 Saga 执行过程中 TM、TC、RM 和状态机的交互过程是怎样的？\n A：1）发起重试。2）根据分支响应状态，判断是否切换重试方向。目前，Sage 的分支默认情况下不会注册到 TC 了的，因为 Saga 本地库里有各 RM 的数据。 只有全局事务注册和全局事务提交或回滚时，与 TC 交互。\n 现在二阶段重试失败不断发起重试在 1.4.0 版本解决了吗？判断是否切换重试方向是只有可能 TC 会决定向后或者向前重试？\n A：是由 RM 端返回的状态为依据，由 TC 端切换重试方向，决定权在 RM 端。\n 我的理解是 RM 告诉 TC 回滚失败，然后有可回滚和不可回滚两个状态，TC 根据这个决定是否继续重试？那如何在 RM 进行配置？\n A：我刚才的截图是 TC 端发起全局提交时，RM 返回“回滚”失败重试回滚，这种情况，默认情况下不存在了，因为 Saga 不会注册分支到 TC。 实际上，应该是在 SagaCore 的全局回滚时，RM 端如果返回“提交”失败，重试提交状态时，会切换到向前重试。\n看了下源码，只有全局事务是因超时而进入全局回滚时，才会切换重试方向。\n 切换重试方向是指本来流程图配置是向后重试，然后超时了，TC 会切换为向前重试？\n A：意思是全局事务正在运行时，因超时60秒，TC 端自动将全局事务标记为超时回滚状态，然后会异步发起全局回滚请求。 这种情况下，碰到回滚失败时，会切换为向前重试。\n 哦哦，原来是这个样子。默认情况下，本地只会把全局的 RM，状态发送给 TC?\n A：默认情况下，RM 的数据只会存在本地。TC 端可以说是不管 Saga 分支的情况的。TC 只管接收 1）TM 的开始全局事务、完成全局事务；2）超时进入全局回滚；3）根据状态判断是否继续重试，还是切换重试方向。\n 1)是 TM 监测到所有 RM 都已完成然后告诉 TC 全局事务结束？3)TC 根据状态判断是否重试，现在 RM 不把状态发送给 TC，那这个状态是从哪里来?\n A：1）是的。 3）这个请求是从 TC 向 RM 端发起的。RM 只是返回一个状态而已。\n 我在实践中的问题就是在二阶段执行出现异常会不断地重试，如之前跟你聊过的补偿触发后补偿服务执行异常会不断重试。上述 TC 发起的全局回滚如果回滚过程中出现异常是不是也会不断地重试？不断地重试感觉比较占用资源？是否有应对策略让他能够只是有限次重试？\n A：重试策略的 PR 已经有了，但是因为 PR 依赖关系较多，暂时还没有合并，后续我会精简 PR 代码，单单引入重试策略的功能及其配置的功能。到时候会能够配置重试策略。目前，基本上是1秒钟就会发起一次重试。\n 现在没有重试策略的情况下，是否有其他的应对方法？\n A：将重试时间间隔配置稍微大一些，默认1秒。\n本周推荐阅读 云原生网络代理 MOSN 的进化之路 基于 MOSN 和 Istio Service Mesh 的服务治理实践 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 云原生网络代理 MOSN 平滑升级原理解析 | 开源 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.18.0 版本，主要变更如下：\n 新增 MOSN 配置文件扩展机制； 新增 MOSN 配置工具，提升用户配置体验； 优化 HTTP 协议处理对内存的占用； TLS 模块优化，增加了客户端降级配置逻辑、降低了 TLS 内存占用； 支持大于 4M 的 XDS 消息； 部分 API 接口进行了重构； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.18.0\n2、发布 Seata v1.4.0 版本，主要变更如下：\n 支持 yml 配置文件； 支持 Oracle nclob 类型； 支持客户端最少的活动负载均衡； 支持客户端一致性哈希的负载均衡； 支持 Spring Boot 使用自定义配置中心和注册中心； 支持 Apollo 密钥 key 配置； 修复禁止执行更新主键值的 SQL； 重构 Redis 存储模式下 session 的存储结构； 详细发布报告： https://github.com/seata/seata/releases/tag/v1.4.0\n","date":1604646000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201106/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dc199415476133ea6f6ee6adf2bf91fa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201106/","publishdate":"2020-11-06T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201106/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、Seata 发布新版本、MOSN 相关阅读整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201106/","wordcount":2032},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@王钢 提问： \u0026amp;gt; https://github.com/sofastack-guides/kc-sofastack-dynamic-demo/issues/11 基于 SOFAArk 和 SOFADashboard 实现动态模块管控时遇到宿主应用能够下载biz安装成功，但是不能在zookeeper下生成对应的/apps/biz节点，导致管理端不能更新状态，不知道应该怎么排查解决。使用的 ZK 版本是 3.4.10。\nA：可以 debug 下写 /apps/biz 的逻辑，这里是不是宿主客户端没有连接上来，具体可以看一下：https://github.com/sofastack/sofa-dashboard-client SOFADashboard 之前只做了一个简单的模型，后面陆续其他同学也在上面做了一些开发，如果有兴趣可以一起参与共建哈。\nSOFADashboard：https://github.com/sofastack/sofa-dashboard\n2、@钟文豪 提问： \u0026amp;gt; SOFAJRaft 是如何计算 commitIndex 的呢？\nA：可以看看这个文档：https://www.sofastack.tech/projects/sofa-jraft/raft-introduction/\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@张潇 提问： \u0026amp;gt; 各位好 问个概念的问题。我三个服务 A,B,C，在 A 服务方法加了 @GlobalTransactional，调用 B ，C。启动三个服务的时候看 Seata 日志 ,A,B,C 服务每一个都是 RM 也是 TM。是这样的吗？不是 A 服务才是 TM 吗？\nA：在你这个事务当中，A 是对应着 TM，B、C 对应着 RM。 但是在注册的时候，他们都同时向 seata-server 注册了 TM 和 RM，意味着他们可以作为 TM，也可以作为 RM。 比如你有一个全局事务从 B 发起的，那这个时候他就是 TM。如果你认为你的业务场景中 B、C 这两个服务不会作为 TM 存在，你也可以把 TM 相关的配置删了，然后他就不会去注册 TM 了。可以从定义上去看 TM 和 RM，会发起全局事务的就是 TM，对应着数据库资源的就是 RM。一个服务可能只是 TM，也可能只是 RM，也可能都是。\nSeata：https://github.com/seata/seata\n本周推荐阅读 网商银行是如何建设金融级云原生分布式架构的？ 开源项目是如何让这个世界更安全的？ SOFA 项目进展 本周发布详情如下：\n开源 MOSN Golang 系统诊断工具 holmes beta 版：\n 支持基于 goroutine 波动的自动 goroutine profile dump； 支持基于 RSS 统计的 heap profile dump； 支持基于 CPU 使用率的自动 cpu profile dump； 详细参考： https://github.com/mosn/holmes/blob/master/readme.md\nSOFA 直播预告 传统 CDN 节点内组件间通信通过 IP 分组渲染的方式实现，当更多参差不齐的异构节点资源出现的时候则不再能很好地满足我们的需求。\n本期主要分享阿里云将传统的 CDN 节点改造成微服务架构的落地过程，主要使用了蚂蚁 SOFAStack–Service Mesh 的数据面 MOSN，主要分为两个阶段，第一个阶段是由传统 CDN 节点到数据面先行的微服务架构，通过数据面 MOSN+coredns 实现服务发现；第二个阶段是由数据面先行到数据面+控制面的标准 Service Mesh 架构。根据我们的落地和改造经验，介绍基于 MOSN+coredns/Istio 的 Service Mesh 架构改造的实际案例。上期分享了《Service Mesh 在 CDN 边缘场景的落地实践》，大家也可以温故一下～ 视频回顾地址：https://tech.antfin.com/community/live/1289\n分享主题：《Service Mesh Webinar#4:阿里云 CDN 节点微服务架构演进之路》\n分享嘉宾：邓茜（花名沐沂），阿里云高级开发工程师\n听众收获：\n 了解边缘场景下，使用 Service Mesh 架构的好处； 了解如何利用 MOSN + coredns 实现简单的服务发现； 了解如何利用 MOSN+ Istio 配置 http/tcp/udp 的转发规则以及如何动态配置持久化； 线上直播时间：2020 年 11 月 4 日（周三）20:00-21:00\n欢迎报名：点击“这里”，即可报名。\n","date":1604041200,"description":"【10/26-10/30】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201030/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a67a4e194b658ba2f0427011c0b56dba","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201030/","publishdate":"2020-10-30T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201030/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 项目更新及直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201030/","wordcount":1772},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@廖虹剑 提问：\n 我们想扩展一下 Dubbo 的 thrift 协议，遇到一个问题，consumer -\u0026amp;gt; mosn-client -\u0026amp;gt; provider，现在请求可以正常 decode -\u0026amp;gt; encode 到达 provider，并且 provider 可以正常调用，在返回的时候，数据包已经发回 MOSN，并且成功 decode，但是会阻塞在 read 处直到超时，没办法 write 回 consumer。 请问有什么排查思路吗？MOSN 里面这个网络模型看得有点晕。\n A：先 read 再 decode 的呀，你说的阻塞在 read 是阻塞在哪？\n read 方法已经正常调用，并且 decode了，但是没有触发写事件，consumer端 会一直在等待。 然后又会到这里卡住直到超时 A：数据 read 了没有新数据，这里就是会超时啊。你要看 decode 之后做了什么。\n 我打断点看到的 remote ip 和端口是 provider 端的。或者我换一个问法，MOSN 在获取到 upstream 的响应数据并且 decode 之后，是如何怎么触发 encodeResponse 并写回 writebuffer 的。我调试发现它 read 完数据之后无法进入到 endStream 方法。 也没看到什么异常日志。 我对 go 还不是特别了解，如果有什么问题还请多指正，辛苦了。\n A：你从 Decode 的逻辑往下跟一下就可以了，Dubbo 目前是 xprotocol 协议的实现 Decode 以后会经过 proxy 的流程最后再 encode，然后 write。read 是异步的，这个有点简单的介绍： https://mosn.io/blog/code/mosn-eventloop/\n 找到问题了，是 encode 的时候 replace requestId 的时候出了点问题，导致找不到对应的 stream，感谢~\n MOSN：https://github.com/mosn/mosn\n2、@Bernie G 提问：\n 我这边项目是 Spring Boot，没有用 Dubbo， 这种情况可以用 Seata 做 Saga 事务吗？\n A：你的服务调用是通过 feign，resttemplate？Saga 跟 RPC 框架不是强绑定的，你的远程服务可用在被调用方作为类似 reference bean 的形式调用就可以。\n 我们这边主要用的是 RestfulApi 还有 gRPC 来作为微服务之间的调用， Seata 能支持吗？ 如果能给个代码 Sample 最好。\n A：Test 中有 gRPC 的实例，看下是否满足需求。 https://github.com/seata/seata/tree/develop/integration/grpc\nSeata：https://github.com/seata/seata\n本周推荐阅读 开源项目是如何让这个世界更安全的？ Hey，邀请你加入我们一起玩耍 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.4.5 版本，主要变更如下：\n 支持 triple 线程监控； 升级 sofa-ark 版本至 1.1.5； 升级 junit 版本至 4.13.1； 修复 jvm filter npe 问题； 修复http server 线程池配置问题； 详细发布报告： https://github.com/sofastack/sofa-boot/releases/tag/v3.4.5\n2、发布 SOFAArk v1.1.5 版本，主要变更如下：\n 修复 web 模块并发安装问题； 修复支持 web 环境测试 webContext 默认为 null 导致的 NPE 问题； 详细发布报告： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.5\nSOFA 直播预告 在边缘计算和 5G 商业化风起云涌的当下，阿里云 CDN 开展了节点全面云原生化的改造，在此背景下，我们尝试利用 CDN 资源池为底座，在大规模复杂边缘场景下建设 Service Mesh 的基础能力，打造边缘 PaaS 平台。落地实践过程中我们使用了蚂蚁 SOFAStack–Service Mesh 体系中的 MOSN 作为数据面，Istio 作为控制面。本次分享将从 Service Mesh 技术以及 CDN 边缘场景介绍入手，重点分析 Istio 和 MOSN 结合的落地实战过程。\n分享主题：《Service Mesh Webinar#3：Service Mesh 在 CDN 边缘场景的落地实践》\n分享嘉宾：肖源（花名萧源），阿里云技术专家\n听众收获：\n 了解 Service Mesh 技术； 了解 Service Mesh 在阿里云 CDN 边缘场景的落地实践； 给到想要落地 Service Mesh 的同学一些案例与建议； 线上直播时间：2020 年 10 月 28 日（周三）20:00-21:00\n欢迎报名：点击“这里”，即可报名。\n","date":1603436400,"description":"【10/19-10/23】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201023/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cf0c4a06a60155202353fe19c3185072","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201023/","publishdate":"2020-10-23T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201023/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAArk、SOFABoot 发版、10月28日线上直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201023/","wordcount":1640},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谢子华 提问：\n SOFARPC 客户端A调用服务端 B，B在方法中想异步调用C（不同步等结果），在callback里面才响应结果返回给A。这种有 Demo 吗？\n A：链路异步吗？ 可直接看测试用例 https://github.com/sofastack/sofa-rpc/blob/master/test/test-integration/src/test/java/com/alipay/sofa/rpc/test/async/AsyncChainTest.java\n 谢谢，看了下用例。我理解是 服务端接口执行时在 RpcInvokeContext 设置了 SendableResponseCallback 类型的 callback。SOFA 就会忽略接口的返回值。然后在 callback 中主动调用 sendAppResponse 返回结果。对吗？\n A：对的。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@明丽 提问：\n 有没有存在经常锁表的童鞋？lock_table 里存在锁表数据和 undo_log 里面有历史几天的数据没有被删除掉？\n A：locktable 如果没删除，说明可能遇到脏数据导致分支事务无法回滚，此时就会有锁无法释放，这时候要根据 locktable 的信息去找对应的分支事务是那个应用，去看下日志提示，如果是脏数据会说镜像校验不通过\n 这里的脏数据具体是指什么样的数据？\n A：全局事务是回滚时，需要回滚的数据被改动。\n 通常报错的就是并发情况下扣减库存，操作同一条 update 库存数量语句。\n A：比如 a=1，update 后时 a=2。此时其他的分支事务异常，导致全局事务决议时回滚，这个时候 a 被改为了3，这个 a 的数据脏了，隔离性没被保证。此时回滚的时候会校验 a 还是不是当前事务修改的值，如果不是，说明这个数据脏了，已经不正确了，不能盲目的直接回滚成1，说明隔离性没保证，有数据被 Seata 全局事务外的地方修改了，如果想保证隔离性，就需要保证任何一个写场景，都被全局事务注解覆盖。\n 我们这边的更新场景都有加全局事务的注解，好像没有起作用，还有别的不起作用的情况吗？\n A：那就检查是否都覆盖了，比如定时任务，或者会不会有认为的去数据库层面直接修改。\n 另外一个问题，我在订单服务下单的时候发起扣库存请求，这个时候只需要在订单服务的方法加上全局注解就可以了，对吗？不需要在库存服务被调用的方法加注解？\n A：只要保证 xid 传递跟数据源代理即可，但是如果有订单服务之外，没有被全局事务注解覆盖的地方操作了库存，一样会脏。这个文章我借鉴了清铭、屹远、煊意的博客，总结了一下 XA 跟 AT 的关系，也谈到了隔离性方面的问题，希望你看过后可以理解 AT 的隔离性是如何保证的。 https://blog.csdn.net/qq_35721287/article/details/108982806\nSeata：https://github.com/seata/seata\n剖析 SOFAJRaft 实现原理合集 SOFAJRaft 实现原理 - 生产级 Raft 算法库存储模块剖析原理 SOFAJRaft 实现原理 - SOFAJRaft-RheaKV 是如何使用 Raft 的 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析 | SOFAJRaft 实现原理 SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.5.Alpha1 版本，主要变更如下：\n 升级 \u0026amp;lsquo;rocksdb\u0026amp;rsquo; 到 5.18.4 以支持 AArch64； 优化：心跳响应不经过 pipeline 直接发送，避免 pipeline 影响心跳响应的及时性； 修复使用 grpc 时，在一定情况下无法自动重连的问题； 修复使用 grpc 时，在 error response 处理的错误； 致谢（排名不分先后）：@cmonkey @odidev 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.5.Alpha1\nSOFA 团队欢迎你加入 蚂蚁集团招聘技术运营专家啦～欢迎加入我们一起为可信技术带来更多的想象。\n岗位名称：可信原生技术运营专家\n岗位描述：\n 挖掘技术内容和业务价值，并形成体系，构建传播矩阵，形成并提高产品和技术的行业美誉度； 完整策划并执行线上、线下的技术活动、大赛，构建围绕可信原生技术的开发者活跃群体，并有更多创造性的技术玩法，使技术可感知； 维护重点 KOL，并吸纳行业专业意见，加大行业贡献，并深化行业影响力。 岗位要求：\n 具备用户细分、市场定位、产品规划、产品包装的能力中的一项或多项； 具备良好的创新思维、有技术前瞻性； 良好的沟通协作能力，及横向驱动能力； 有线上市场推广经验，或线下活动策划经验者优先考虑； 对于云计算领域有较深入的了解，有相关工作背景者优先考虑。 欢迎简历投递至：khotyn.huangt@antgroup.com\n","date":1602831600,"description":"【10/12-10/16】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201016/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a7a2f16f7c62d777b8aff0f90a85ba7b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201016/","publishdate":"2020-10-16T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201016/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布、SOFAJRaft 源码解析文章合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201016/","wordcount":1951},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@叶翔宇 提问： \u0026amp;gt; 想请教一个问题，使用 MOSN 的过程中，我们想通过 request 的 header 中带的 version 信息来实现灰度的机制。比如：目标 service 有 3 个 host，其中一台版本1.0，其他两个版本2.0。\nA：你这个加一个 route 的判断就可以路由到不同的 cluster 了。\n 我们的是同一个 cluster 里面的不同 hosts\u0026amp;hellip;\n A：你就把不同版本的 hosts 归为不同的 cluster 就可以啦。\n2、@李样兵 提问： \u0026amp;gt; 我们现在生产环境中没有使用 K8s, 只使用 MOSN+自定义配置和注册中心，可行吗？\nA：你们是 Dubbo 么？\n 对，dubbo+http， 生产环境是 docker 还没有 K8s。\n A：你可以用这个方案，MOSN 直接连接注册中心。 https://github.com/mosn/mosn/issues/1087 MOSN：https://github.com/mosn/mosn\n线上直播 SOFAChannel 合集 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 蚂蚁金服分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 ","date":1602226800,"description":"【10/05-10/09】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201009/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a83b0d192a605f994a1379ab41578403","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201009/","publishdate":"2020-10-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201009/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN QA 整理、SOFAChannel 线上直播合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201009/","wordcount":938},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@周爽 提问： \u0026amp;gt; 我现在基于springcloud 集成 nacos,sentinel,zipkin,jpa,shardingjdbc，昨天说的做了防止重复代理，如果我是多数据源呢？后续1.3.1是配置也需要开启，代码也需要写代理吗？\nA：多数据源就关掉自动代理，自己手动\n 就在我多数据源里面加上右边的 DataSourceProxy 就可以了吗？ @Primary 这个只需DataSource1Config加上，DataSource2Config是否需要加呢？\n A：代理这个 reresult；\n AT 和 XA 1.3版本可以理解为代码“使用”上就一个 new poxy 不同吗？\n A：一个是 new DataSourceProxy，一个是 new DataSourceXAProxy\n Seata “实现”一个是二阶，一个是基于 XA 事务规范？\n A：都是二阶段，一个模式是自研，一个是基于数据库底层实现。 Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 SOFAEnclave：蚂蚁金服新一代可信编程环境，让机密计算为金融业务保驾护航102年 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.7.6 版本，主要变更如下：\n 支持精细化配置 Jackson 序列化； Triple 协议支持用户自定义元数据； Triple 协议支持 SPI 编程模式； 升级 hibernate-validator 版本到 5.3.6.Final； TripleServer 启动时发送启动事件； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.6\n2、发布 MOSN v0.17.0 版本，主要变更如下：\n 重构 XProtocol 连接池，支持 pingpong 模式、多路复用模式与连接绑定模式； 优化 XProtocol 多路复用模式，支持单机 Host 连接数可配置； Listener 配置新增对 UDS 的支持； 新增在 Dubbo 协议下通过 xDS HTTP 配置进行转换的过滤器； 部分框架实现优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.17.0\n","date":1601622000,"description":"【09/28-10/02】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201002/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bc9b38b8088d82138a46a8318e944840","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201002/","publishdate":"2020-10-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201002/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":" SOFA Weekly | MOSN、SOFARPC 发版、Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201002/","wordcount":1018},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@刘源远 提问：\n 请教一下大家，这个本地事务提交，是指这个本地事务在分布式事务中提交，还是指在自己的事务中提交啊？ 如果是指分布式事务中提交，那不就应该在分支事务提交之前，才存在回滚嘛？如果是指自己的事务中提交，那我断点下来，本地业务事务已经提交了，为什么还产生这条记录呢？ A：只要二阶段回滚的时候，发现你的 undolog 没插入就会做一条防御性的 undolog，你可以认为你没产生资源悬挂，但是二阶段确实没读到你的 undolog。所以才会插入一个防御性，你完全不需要理会 status=1 的记录。\n 奇怪的是，我断点下来，在一阶段会产生 undolog 记录（两条），然后抛异常回滚之后，一阶段的 undolog 记录（两条）被删除了，产生一条 status=1 的记录。会不会是因为某些原因，一阶段会产生 undolog 记录被删除了，所有二阶段没有查询到？\n A： 多数据源？\n 对的，多数据源。\n A：确认下是不是重复代理了？把自动代理关了，一般多数据源都是已经手动代理了，因为二阶段的时候，下发找 datasource，找到的不是你当时操作数据库的 datasource，导致没发现 undolog，就插了一条 status=1。\n 我现在手动配置代理，有两个数据源，一个用了 DataSourceProxy，一个没有。现在处于分布式事务中是使用了 DataSourceProxy 的数据源，但是回滚后还是会产生一条 status=1 的 undolog。\n A： 自动代理关了吗，看下怎么代理的。\n 你指的自动代理是 springboot-start 吗？还是其他的？\n A：Seata 的数据源自动代理，设置 Seata: enable-auto-data-source-proxy: false\n OK，好啦\n Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服通信框架 SOFABolt 解析 | 超时控制机制及心跳机制 蚂蚁金服通信框架 SOFABolt 解析 | 连接管理剖析 蚂蚁金服通信框架 SOFABolt 解析 | 协议框架解析 蚂蚁金服通信框架 SOFABolt 解析 | 序列化机制(Serializer) 蚂蚁金服通信框架 SOFABolt 解析 | 编解码机制 社区活动预告 CSDI summit 中国软件研发管理行业技术峰会（Software development management industry technology summit）由国内专业咨询机构百林哲匠心打造的软件行业技术领域顶级盛会，将于2020年9月24-27日举办。 话题涵盖：组织数字化转型、研发效能、产品创新、用户增长、云原生、架构创新、微服务、AI 大数据、数据安全和云安全、AIOT 实践等方面。蚂蚁集团也应邀参与本次大会分享。\n分享主题：金融级云原生 PaaS 实践之路\n分享嘉宾：成旻 蚂蚁金服高级技术专家\n分享时间：2020-09-26 16:40 - 18:00\n分享亮点：\n 蚂蚁 PaaS 产品的缘起； 经典应用服务的能力和特色； 容器应用服务的进阶能力； 面向未来\u0026amp;ndash;混合云发展发向； 活动形式：线上峰会\n活动详情：点击“这里”，了解日程详情\n","date":1601017200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200925/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c7562a535d9b34b23d0b559dd756ef6a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200925/","publishdate":"2020-09-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200925/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt 源码解析合辑、CSDI summit 活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200925/","wordcount":1385},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 社区大事件 MOSN 支持 Istio 啦～详见链接：\n 英文版：《Using MOSN with Istio: an alternative data plane》 中文版：《在 Istio 中使用 MOSN：另一个数据平面》 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@梓郁 提问：\n 我最近刚刚接触分布式链路监控，看了 SOFATracer 的 slf4j 的 demo。现在有一个问题。就是我想在日志里面打印出 span 的 parentid，但是我不想在我自己的代码里面显性地用 MDC 添加，有什么其他方法吗？（我现在是打算在 MDCSpanExtension 里面用 mdc.put 添加;再重新打包添加依赖这样可行吗？）\n A：自己扩展下这个接口 SpanExtension。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@石评 提问：\n 我有个关于 Seata 的疑问：A -\u0026amp;gt; B-\u0026amp;gt;C 的时候，不管 B 有没有本地事务，如果 C 失败了 B 的都会回滚，那么 B 的本地事务的作用是什么呢？\n A：分布式事务认为由若干个分支事务（本地事务）构成的，如果加了 autocommit=false，那么 B 服务的几条 sql构成一个本地事务，如果不加那么每条 DML 语句都是一个本地事务。本地事务越少那么与 TC 的交互次数越少。\n3、@徐成阳 提问：\n Seata 的 TCC 强一致的嘛？\n A：AT、XA、TCC 应该都属于强一致性。 SAGA 无法保证事务隔离性，在部分情况下可能会存在无法回滚，而选择向前继续重试来保证事务最终一致性。 四种模式都是属于最终一致性。SAGA 性能更高，因为没有二阶段提交，而且分支数据都是保存在本地的。\nSeata：https://github.com/seata/seata\n本周推荐阅读 来了！2020 云栖大会 蚂蚁金融科技产品能力再升级 企业数字化转型指南，《SOFAStack 解决方案白皮书》正式发布 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.4.bugfix_2 版本，主要变更如下：\n 修复使用 grpc 时，在一定情况下无法自动重连的问题； 详细发布报告： https://github.com/sofastack/sofa-jraft/releases/tag/1.3.4.bugfix_2\n社区活动预告 这里有一个您的专属日程提醒，请查收：\n日程主题：OceanBaseDev Meetup#1 上海站「深入分布式数据库：事务·高可用·云原生」\n出品人： - 杨传辉（花名：日照）蚂蚁集团研究员、OceanBase 总架构师 - 韩富晟（花名：颜然）蚂蚁集团资深技术专家、OceanBase 事务研发负责人\n日程时间：2020-09-20 本周日 13:00-17:30\n日程地点：上海市杨浦区政学路77号 InnoSpace+\n日程详情：点击“这里”，了解日程详情\n","date":1600412400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200918/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d3e2feb22ec7504b5fc6648eeba4769f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200918/","publishdate":"2020-09-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200918/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFAWeekly｜MOSN 支持 Istio、SOFAJRaft 发布、本周日您有一条待办日程","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200918/","wordcount":1251},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈健斌 提问：\n Seata 使用注册中心只存储个地址列表，引入 SOFAJRaft 后感觉注册中心没必要了？用户用起来就跟 zk 集群、kafka 集群一样，ip:port,ip:port 这样。\n A：这个 看需求了，都可以啊。我感觉还是可以继续使用注册中心，然后 SOFAJRaft 的地址从注册中心回去，动态构建 SOFAJRaft 集群。\n 可以噢，这样 client 端不需要设置 server 的集群了，通过注册中心来就可以了，自动组装了。 我目前是这么设计的，有空的话还望指点一二。\n A：Sesta server 经常会经常替换吗？\n 这个得看用户了，要不咱假设2个情况吧，如果不经常替换，此方案适用不。经常替换下要做哪些改进？\n A：经常替换的话要考虑 raft 集群的替换，要处理 addpeer removepeer 这是要走 raft 协议的（用 cliservice 这个接口），就是换一台 server 不是换个地址就完事了，需要调用 addpeer把新机器加入 raftgroup 然后 SOFAJRaft 会自动同步数据，移除一个节点需要调用 removepeer。\n 也就是，如果我现在扩容，比如我原来的节点是127.0.0.1:7091，127.0.0.1:7092，127.0.0.1:7093 然后我现在要加一个127.0.0.1:7094，我能不能直接跟 zk 那边扩容一样，我新加入进来的节点设置的地址是127.0.0.1:7091，127.0.0.1:7092，127.0.0.1:7093，127.0.0.1:7094，先让他加入进去，然后手动挨个重启其余3台。目前这样的扩缩容，我的设计方案能满足吗？\n A：不需要重启，需要 addpeer，参考第11小结，最有效的排查 SOFAJRaft 问题工具 https://www.sofastack.tech/projects/sofa-jraft/jraft-user-guide/ SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@koutatu 提问： \u0026amp;gt; 想咨询下，Seata Saga 模式下，TC 的作用是什么呢，回滚操作还是 TC 触发吗？感觉 Saga 状态机模式下，状态机可以控制回滚，TC 是不是只是记录下状态，不做什么实际处理了呢？\nA：你说的应该是对的，Saga 脱离 TC 理论上都是可行的。\n 目前的回滚操作是不是也是状态机自身控制的，也就是链路里面的每一步都需要有一个状态机。TC 只负责接收消息，而不是像 TCC 或者拦截器式的 Saga 一样，回滚由 TC 统一控制。\n A：TC 在 Saga 模式的作用就是记录全局事务分支事务状态。 Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析 SOFABoot 扩展点初体验 | SOFALab 实践系列 剖析 | 详谈 SOFABoot 模块化原理 实操 | 基于 SOFABoot 进行模块化开发 开源 | SOFABoot 类隔离原理剖析 SOFA 项目进展 1、发布 SOFAArk v1.1.4 版本，主要变更如下：\n 支持动态替换 biz name； TestClassLoader 导出 mockito 包以支持 mockito 测试框架； 修复 AfterBizStopEvent 事件处理时机问题导致的 NPE； 修复 web 模块卸载问题； 支持 ark telnet 使用安全模式启动； 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.1.4\n2、发布 SOFABoot v3.4.4 版本，主要变更如下：\n 提供 jvm 调用拦截扩展； 修复若干测试用例； 修复在 ark 环境使用 sofa:reference 引用 jvm 服务出现 NPE bug； 修复健康检查通过但 ExtensionComponent activate 失败 bug； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.4\n社区活动预告 近几年，越来越多的传统企业面临互联网化，IOT、区块链、AI、5G 等技术也在高速发展，任何一个技术的推广到成熟都会带来数据量的指数级增长，都会对存储带来巨大的冲击。相信随着这些技术的突破，未来越来越多的核心场景会走向分布式的领域。国内很多团队也在进行分布式数据库的探索与实践。\nOceanBaseDev Meetup 是以城市站展开的数据库技术交流活动，旨在为关注分布式数据库技术的同学提供技术交流、分享、探讨的空间与平台。\nOceanBaseDev Meetup#1 上海站，将邀请蚂蚁集团 OceanBase 团队的三位核心研发专家以及网易杭研资深研发工程师，针对分布式数据库的分布式事务以及落地实践展开分享。现场更有外滩大会门票等你来拿～\n活动主题：**OceanBaseDev Meetup#1 上海站「深入分布式数据库：事务·高可用·云原生」\n出品人： - 杨传辉（花名：日照）蚂蚁集团研究员、OceanBase 总架构师 - 韩富晟（花名：颜然）蚂蚁集团资深技术专家、OceanBase 事务研发负责人\n活动时间：2020-09-20 13:00-17:30\n活动地点：上海市杨浦区政学路77号 InnoSpace+\n活动报名：点击“[阅读原文**](https://www.huodongxing.com/event/5562442480600)”，了解活动详细议题并锁定席位\n","date":1599807600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200911/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"25ab3501e7db2cd836d05f86bb6c17ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200911/","publishdate":"2020-09-11T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200911/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot、SOFAArk 发布、9/20 上海线下活动推荐","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200911/","wordcount":2145},{"author":"王发康（毅松）","categories":"MOSN","content":" 本文根据 2020 年 8 月 15 号在深圳 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会云原生专场现场实录整理。\n分享嘉宾：王发康（毅松）蚂蚁集团可信原生技术部 技术专家，专注于高性能网络服务器研发，是 MOSN、Tengine 开源项目核心成员，目前关注云原生 Service Mesh、Nginx、Istio 等相关领域，喜欢开源，乐于分享。\nGItHub：https://github.com/wangfakang\n以下是分享全文。\n前言 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，本文就其在演进过程中遇到的问题及思考进行展开。对接 UDPA，实现 Istio 融合，并增强 MOSN 服务治理及流量控制能力对接云原生周边组件，实现 MOSN 开箱即用。\n大家下午好，我叫王发康，来自蚂蚁集团可信云原生应用网络团队，之前几年一直从事南北向网关（接入层）的开发和维护，说来也是和流量有着别样的渊缘，现在主要做东西向的流量网关（Service Mesh）开发和设计。今天演讲的主题是《云原生网络代理 MOSN 的进化之路》，主要从如下几点介绍：\n MOSN 介绍； 云原生演进； 总结与展望； MOSN 介绍 接下来，就 MOSN 的诞生背景、发展历程、MOSN 具备的功能和架构以及内部的落地情况这几个维度介绍下 MOSN。\nMOSN 诞生背景 随着云计算、物联网等技术迅速发展，也促使着微服务的架构一直在进化，其演进过程通常经历了如下四个阶段：\n单体：一般起始阶段业务很简单，流量也不大，所有的处理都可以在一个服务中完成；\n分布式：随着业务操作的多样化以及流量的日益增长，不得不按照服务维度进行拆分，这样相同的服务资源消耗可对等，方便容量评估及管理；\n微服务：随着服务的拆分粒度越来越细，其服务的数量一直在增加，由此出现各种微服务治理的需求（限流、鉴权、路由等），于是便出现各种治理组件并以 SDK 插件的方式集成到不同应用中；\nService Mesh：伴随着服务治理的 SDK 种类、版本、重复等一系列问题，于是把 SDK 的能力剥离到 Sidecar，和业务进行解耦，从而实现业务和中间件能力的并行迭代；\n业务痛点\n 多语言，中间件组件开发适配成本高； SDK 升级困难； 服务治理能力弱； 技术不通用，无法复用； 业界解决方案\n Envoy (C++)； Linkerd (活跃度较低)； NginxMesh (活跃度低)； 综合以上业务痛点以及业界现有方案的评估，于是 MOSN 就诞生了。MOSN（Modular Open Smart Network）是用 GoLang 编写的网络代理服务器。作为 Sidecar、API Gateway、云原生 Ingress、Layer 4 或 Layer 7 负载均衡器等场景构建的。随着时间的推移，我们添加了额外的功能，例如多协议框架，多进程插件机制，DSL 以及对 xDS API 等的支持，支持 xDS 意味着我们现在可以将 MOSN 用作 Istio 的数据平面。\nMOSN 发展历程 从 2017 年底开始 Service Mesh 技术调研，2018 年 3 月份 MOSN 雏形问世并进行了小规模试点，秉着让更多的用户能够享受这一技术红利的思路，于是 2018 年 6 月正式开源 MOSN。2019 年 618 进行了规模化落地，并在同年的双 11 大促达到了核心支付链路的全覆盖。在通过大规模验证后，MOSN 社区开始在其标准化以及生态方面进行发展和演进。\nMOSN 功能视图 MOSN 作为一个通用的数据转发平面，提供多协议卸载、动态服务发现、服务治理（Trace、限流、重试、重写、超时控制等）、丰富的负载均衡算法等功能，可用于 Sidecar、API Gateway、云原生 Ingress、Layer 4 或 Layer 7 负载均衡器等场景。\nMOSN 架构解析 MOSN 采用的是分层的体系结构，其系统分为 NET/IO、Protocol、Stream、Proxy 四层：\n NET/IO 作为网络层，监测连接和数据包的到来，同时作为 listener filter 和 network filter 的挂载点; Protocol 作为多协议引擎层，对数据包进行检测，并使用对应协议做 decode/encode 处理; Stream 对 decode 的数据包做二次封装为 stream，作为 stream filter 的挂载点; Proxy 作为 MOSN 的转发框架，对封装的 stream 做 proxy 处理; 其中，每一层通过工厂设计模式向外暴露其接口，方便用户灵活地注册自身的需求。通过协程池的方式使得用户以同步的编码风格实现异步功能特性。通过区分协程类型，MOSN 实现了 read 和 proxy worker 两大类协程，read 协程主要是处理网络的读取及协议解析，proxy worker 协程用来完成读取后数据的加工、路由、转发等。其架构如下图所示：\nMOSN 为了降低 Runtime GC 带来的卡顿，自身做了内存池的封装方便多种对象高效地复用，另外为了提升服务网格之间的建连性能还设计了多种协议的连接池从而方便地实现连接复用及管理。\n在连接管理方面，MOSN 设计了多协议连接池， 当 Proxy 模块在 Downstream 收到 Request 的时候，在经过路由、负载均衡等模块处理获取到 Upstream Host 以及对应的转发协议时，通过 Cluster Manager 获取对应协议的连接池 ，如果连接池不存在则创建并加入缓存中，之后在长连接上创建 Stream，并发送数据，如下图所示：\n在内存管理方面，MOSN 在 sync.Pool 之上封装了一层资源对的注册管理模块，可以方便的扩展各种类型的对象进行复用和管理。其中 bpool 是用来存储各类对象的构建方法，vpool 用来存放 bpool 中各个实例对象具体的值。运行时通过 bpool 里保存的构建方法来创建对应的对象通过 index 关联记录到 vpool 中，使用完后通过 sync.Pool 进行空闲对象的管理达到复用，如下图所示：\nMOSN 落地情况 服务在做了 Mesh 化后，有人可能会质疑，增加一跳 Sidecar 转发是否会导致性能下降，其实不然，在蚂蚁的部分业务场景中，部分业务上了 Mesh 后，其 CPU 消耗还比之前低了，原因是之前的一些通用 SDK 能力都下沉到 Sidecar 中，并统一做了一定的优化。另一个好处是，由于 MOSN 使用 GoLang 开发，天然具备其高开发效率，所以也大大的提升了中间件相关能力的研发速度。\nMOSN 云原生演进 在 MOSN 大规模落地并通过双 11 大考后，MOSN 也开始在实践的道路上进行标准化演进。并通过和 Istio 社区的合作，MOSN 实现了 xDS 的适配，可方便的实现 Istio 作为 MOSN 的控制面进行服务配置的管理。另一方面， …","date":1599022800,"description":"MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，本文就其在演进过程中遇到的问题及思考进行展开。","dir":"blog/cloud-native-network proxy-mosn-evolutionary-path/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"080e78e9d0103daed414ee3a8b5b7996","permalink":"https://sofastack.github.io/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","publishdate":"2020-09-02T13:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","summary":"本文根据 2020 年 8 月 15 号在深圳 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会云原生专场现场实录整理。 分享嘉宾：王发康（毅松）","tags":["MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 的进化之路","type":"blog","url":"/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","wordcount":5065},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@晏伦 提问：\n 请问 Seata 的全局锁粒度是数据库级别还是表级别？全局锁会带来并发的问题吧？如何权衡的呢？\n A：全局锁是行级别的；如果2个事务在同时更新同一行，会出现锁竞争问题，所以 AT 模式的适用场景是并发请求较低，不会产生行锁竞争的业务场景。\nSeata：https://github.com/seata/seata\n本周推荐阅读 少年五年升阿里 P8，他如何从低谷登上“光明顶”？ 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构 Forrester中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求 组件解析部分合辑 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 SOFA 项目进展 发布 sofa-common-tools v1.2.0 版本，主要变更如下：\n 修复多线程日期打印问题； SOFAThreadPool 支持一个 Runnable 在多个 thread 运行； 停止 JDK6 支持； 详细发布报告：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.2.0\n社区活动预告 CSDI summit 中国软件研发管理行业技术峰会（Software development management industry technology summit）是软件行业技术领域顶级盛会，协同国内外知名软件、互联网等企业研发一线技术专家从 AI 和大数据、产业变革、技术创新、生态发展、业务创新、商业模式等方面重点研讨软件研发趋势。蚂蚁集团也受邀参与本次峰会分享“云原生”相关主题。\n分享主题：金融级云原生 PaaS 实践之路\n分享嘉宾：成旻 蚂蚁集团高级技术专家\n分享时间：2020-09-26 16:40-18:00\n听众收获：\n 蚂蚁 PaaS 产品的缘起； 经典应用服务的能力和特色； 容器应用服务的进阶能力； 面向未来\u0026amp;ndash;混合云发展发向； 活动地点： 线上活动\n活动报名： 点击“这里\n","date":1598598000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200828/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"474484cd88c8a1971016217eb9c1438d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200828/","publishdate":"2020-08-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200828/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | sofa-common-tools 发布、组件解析合辑、云原生活动推荐","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200828/","wordcount":1038},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谢小东 提问：\n 请教一个问题，在使用 AT 模式的时候，新增的一条数据，回滚之前我在 db 改了我刚新增的数据，这个时候如果我抛出异常，但是就不发回滚，该怎么处理？\n A：不要在全局事务包裹之外进行对数据的并发操作，如果你这样做，就跳过了 AT 的全局锁，隔离性无法保证，如果你有这方面需求的，可以用 XA 模式，并且使用数据库自身带有排它锁的操作，数据库的自身支持了 XA 模式，就可以帮你保证隔离性。\n 你的意思就是我在这种情况下 XA 模式适合？XA 模式是行锁么？\n A：XA 是数据库自身实现的隔离机制，AT 是统一到 TC 去竞争行锁，而没用到 AT 的地方修改数据库当然就不会去 TC 竞争行锁，隔离性只能保证再全局事务注解下的操作生效。\n2、@彭兴家 提问：\n 请问 Seata 里说的全局锁和本地锁对应 MySQL 的什么锁呀？\n A：全局锁就是从 TC 竞争的锁，本地锁就是参与方自己本地的 MySQL 连接，比如 update 不就有排他锁的作用吗，因为一阶段提交，连接释放了，这个本地数据库的锁就解开了。而全局锁是从 TC 拿的，这个锁保证了你的入口只要是分布式事务注解下，就会去竞争这个全局锁。保证了再分布式事务注解下的全局事务间的隔离性\n 谢谢，明白了。但这样的话，Seata 通过前置镜像回滚。在全局事物执行的过程中，要是其他项目(没在全局事物下的项目)对该条数据进行了修改，那么按照 Seata 的机制，前置镜像对比不同了就不能回滚，需要手动处理？\n A：是的，需要人工介入，因为只有人为分析才能校准数据了。对 Seata 来说他只知道要把数据回滚到发生前，但是数据被干扰了，就无法回滚了。\n 理论上来说这种情况出现的几率很大呀，多个不同项目操作同一条数据。\n A：全局事务，字面意思要理解一下。你让他不全局了，让它不覆盖到，如何保证隔离性？要么涉及到的库对应的应用全局使用 Seata AT，要么就换 XA，修改的数据，用 select for update，这个本地锁在二阶段下发通知前不会释放，保证了隔离性。\n3、@苏龙飞 提问：\n 请问，现在我们的 cloud 项目中用了 Seata，数据库只有一个，然后发现性能不够，所以想换成多主从数据库，并且能和 Seata 兼容，有没有好的方案呀？\n A：主从方案本就应该是允许暂时的不一致，只要你保证读写都需要的时候，一定是主库，并把主库的 datasource 代理掉就好了，保证需要读后马上写的，一定要是主库操作。 Seata：https://github.com/seata/seata\nSOFAChannel 部分合辑 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 [链接]()蚂蚁金服分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 本周推荐阅读 蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO？ 蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？ ","date":1597993200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200821/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"34ac475f8a4ec2435b62a9bf4d520e2a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200821/","publishdate":"2020-08-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200821/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 线上直播合辑整理、Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200821/","wordcount":1515},{"author":"樱桃","categories":"Occlum","content":" \u0026amp;lt; SOFA:Channel/ \u0026amp;gt;，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 本文根据 SOFAChannel#18 直播分享整理，主题：零门槛的机密计算：Occlum LibOS 使用入门和技术揭秘。\n大家好，我是今天的讲师田洪亮（花名：樱桃），蚂蚁集团技术专家，也是 Occlum 开源负责人。今天我和大家分享一下如何使用 Occlum 的轻松开发机密计算应用以及 Occlum 技术架构和特色。\n前言 云计算、大数据、人工智能，我们正处在一个数据爆炸的时代。如何能够在享受和利用海量数据所产生的价值的同时，保证数据的安全和用户的隐私呢？这无异是一个用户、企业和监管部门共同关注的问题。\n近年来兴起的机密计算（Confidential Computing），正是为了解决这个问题而来。利用可信执行环境（Trusted Execution Environments，简称 TEE）技术，机密计算使得数据始终保持加密和强隔离状态，从而确保了用户数据的安全和隐私。机密计算可以解决诸多应用场景中“信任”难题，比如多个不互信组织之间的数据融合与联合分析、区块链上的智能合约的机密性保护、公有云平台对外部或内部攻击的防御、高敏感信息（比如密码学材料、医疗档案等）的安全保护等等。\n但是，机密计算底层依赖的 TEE 技术——比如目前最成熟的云端 TEE 技术 Intel SGX——也带来了额外的功能限制和兼容问题。这使得机密计算的开发者面领一个巨大的阻碍：应用开发难。\n在本文中，我们会首先分析当前 SGX 应用开发者会遇到的各种挑战和痛点，然后介绍蚂蚁集团自研的开源 TEE OS 系统 Occlum 如何大幅降低 SGX 应用开发的门槛，真正做到人人都可以玩转机密计算。\n为什么 SGX 应用开发难？ SGX 应用程序是一种基于划分的模型：在用户态的（不可信）应用程序（上图红色部分）可以嵌入 SGX TEE 保护的区域（上图绿色部分），被称为 Enclave。支持 SGX 的 Intel CPU 保证 Enclave 中的受保护内容是在内存中加密的，并且与外界强隔离。外界的代码如果想进入 Enclave 中执行其中的可信代码必须通过指定的入口点，后者可以实施访问控制和安全检查以保证 Enclave 无法被外界滥用。\n由于 SGX 应用程序是基于这种划分的架构，应用开发者通常需要使用某种 SGX SDK，比如 Intel SGX SDK、Open Enclave SDK、Google Asylo 或 Apache Rust SGX SDK。但无论使用上述哪种 SDK，开发者会遭遇下面的开发困境：\n 必须将目标应用做二分：开发者需要决定哪些组件应该置于 Enclave 内部，哪些置于 Enclave 外部，以及双方如何通信。对于复杂的应用，确定高效、合理且安全的划分方案本身就是一件颇具挑战的工作，更不要说实施划分所需的工程量。 被限定在某个编程语言：无论使用上述哪种 SDK 开发，一个开发者都将被限定在该 SDK 所支持的语言，这通常意味着 C/C++（当使用 Intel SGX SDK、Open Enclave SDK 或 Google Asylo 时），而无法使用 Java、Python、Go 等更加友好的编程语言。 只能获得很有限的功能：处于硬件限制和安全考虑，Enclave 中是无法直接访问 Enclave 外的（不可信）OS 的。由于 Enclave 中缺乏 OS 的支持，各种 SDK 只能提供普通不可信环境下的一个很小的功能子集，这使得很多现有的软件库或工具都无法在 Enclave 中运行。 上述困境使得为 SGX 开发应用成为一件十分痛苦的事，制约了 SGX 和机密计算的普及度和接受度。\n学会 Occlum 的“三板斧” Occlum 是一款蚂蚁集团开源的 TEE OS，可以大幅降低 SGX 应用的开发门槛。那到底多低呢？只需要学会 Occlum的三条命令：new、build和run。本节我们以利用 Occlum 在 SGX 中运行一个 Hello World 程序为例进行说明。\n这里有一个非常简单的 Hello World 程序。\n$ cat hello_world.c #include \u0026amp;lt;stdio.h\u0026amp;gt; int main() { printf(\u0026amp;quot;Hello World!\\n\u0026amp;quot;); return 0; } 首先，我们用 Occlum 提供的 GCC 工具链（occlum-gcc）编译这个程序，并验证它在 Linux 上能正常工作。\n$ occlum-gcc hello_world.c -o hello_world $ ./hello_world Hello World! 然后，我们为这个程序创建一个 Occlum 的实例目录（使用 occlum new 命令）。\n$ occlum new occlum_hello $ cd occlum_hello 该命令会创建一个名为 occlum_hello 的目录，并在该目录中准备一些必要的文件（如 Occlum.json 配置文件）子目录（如 image/）。\n接下来，我们基于刚刚编译好的 hello_world 制作一个 Occlum 的 Enclave 文件和可信镜像（使用 occlum build 命令）。\n$ cp ../hello_world image/bin $ occlum build 最后，我们在 SGX 中运行 hello_world（使用 occlum run 命令）。\n$ occlum run /bin/hello_world Hello World! 更复杂的程序也可以用类似上面的流程通过 Occlum 移植进 SGX 中。用户无需理解 SGX 的二分编程模型，无需或只需少量修改应用代码，还可以自由选择编程语言（比如 Java、Python、Go 等）。使用 Occlum，应用开发者可以将宝贵的精力集中在编写应用上，而非为 SGX 做应用移植。\n用起来像 Docker 的 TEE OS 在了解了 Occlum 的基本用法和体验之后，很自然地会好奇 Occlum 的技术原理：Occlum 的用户接口为什么这样设计？而简单接口背后的技术架构又是怎样的？本节就试图回答这些问题。\nOcclum 的一个设计理念是 Enclave-as-a-Container。在云原生时代，容器至关重要，容器无处不在。容器最常见的实现方式是基于 Linux 的 cgroup 和 namespace（比如 Docker），但也有基于虚拟化的实现（比如 Kata）。我们观察到，TEE 或者 Enclave 也可以作为一种容器的实现手段。因此，为了传达这种理念，同时给用户提供一种熟悉的体验，我们特意将 Occlum 的用户接口设计成与 Docker 和 OCI 标准接近。除了前面提到的 new、build和run 三个命令，Occlum 还提供 start、exec、stop、kill 等命令，其语意与 Docker 同 …","date":1597906800,"description":"本文分享如何使用 Occlum 的轻松开发机密计算应用以及 Occlum 技术架构和特色。","dir":"blog/sofa-channel-18-retrospect/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a1d55e5deb00aa8cde8d14f250569013","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-18-retrospect/","publishdate":"2020-08-20T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-channel-18-retrospect/","summary":"\u0026lt; SOFA:Channel/ \u0026gt;，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。 本文根据 SOFAChannel#18 直","tags":["Occlum","SOFAchannel"],"title":"人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | SOFAChannel#18 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-18-retrospect/","wordcount":2939},{"author":"田晓旭","categories":"Kubernetes","content":" 随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。\n 根据 CNCF 2019 Kubernetes 使用调查报告的显示：目前 84% 的用户已经在生产环境中使用 Kubernetes，生产环境中容器部署规模超过 1000 的比例是 34%，其中超过 5000 的大规模应用比例是 19%。当集群越来越大、越来越复杂，集群可用性就会面临挑战。\n 整体指标：集群是否健康，所有组件是否正常工作，集群中 Pod 创建的失败数量有多少等等； 追踪能力：集群中发生了什么，是否有异常，用户做了什么事情等等； 原因定位：出现异常之后，找到是哪个组件出了问题； 想要解决这些问题，比较好的一个方法就是 SLO，通过定义 SLO 来描述集群的可用性，追踪集群中 Pod 的生命周期，一旦出现失败 Pod，快速定位异常组件。本文采访了蚂蚁集团技术专家范康和姚菁华来分享蚂蚁集团的 SLO 体系是如何建立的。\n大家常会听到 SLA，其实 SLA 是 SLO 衍生出来的协议，SLA 协议会形成具有法律效力的合同，通常是服务供应商和外部客户之间签订的，而 SLO 是用于内部服务之间，定义服务所提供功能的一种期望状态。\n1 SLO 指标定义 如果我们要通过定义来描述集群的可用性，那么具体的描述指标就成为了需要解决的关键问题。在蚂蚁 集团 内部，集群可用性的关键指标包含五个：集群健康度、Pod 创建成功率、残留 Terminating Pod 的数量、服务在线率和故障机数量。\n 集群健康度：通常使用 Healthy，Warning，Fatal 三个值来描述，其中 Warning 和 Fatal 对应告警体系，例如 P2 告警发生，那集群就是 Warning，而 P0 告警发生，那集群就是 Fatal，必须进行处理； Pod 创建成功率：这是一个非常重要的指标，蚂蚁集团一周的 Pod 创建量在百万级别，如果成功率波动会造成大量 Pod 失败，同时 Pod 成功率下跌也是集群异常的最直观反映； 残留 Terminating Pod 的数量：有人可能会好奇为什么使用残留 Terminating Pod 的数量，而不用删除成功率？这是因为当 Pod 数量达到百万级别后，即使删除成功率达到了 99.9%，Terminating Pod 的数量也有数千，残留这么多 Pod 占用应用容量，在生产环境中是不可接受的； 服务在线率：这个指标是通过探针来衡量的，探针失败则意味着集群不可用； 故障机数量：这是一个节点维度的指标，故障机通常是指无法正确交付 Pod 的物理机，集群故障机需要做到“快速发现，快速隔离，及时修复”，否则会对集群容量造成影响； 以上指标的阈值和 SLO 性能目标都是根据业务方的增长来定义的，随着业务的不断增长，这些指标的定义也可能需要跟着做调整。\n以 Pod 创建成功率为例，蚂蚁集团将 Pod 分为了普通 Pod 和 Job 类 Pob，普通 Pod 的 RestartPolicy 为 Never，Job 类 Pod 的 RestartPlicy 为 Never 或 OnFailure，两者都设定有交付时间，普通 Pod 的交付标准是 1min 内 Pod 已经 Ready；Job 类 Pod 的交付标准是 1min 内 Pod 的状态已达 Running、Succeeded 或 Failed。最开始 Pod 创建成功率的定义是成功创建的 Pod 和总 Pod 的比值，但是很快就发现在排查原因时，系统很难分辨，所以又将 Pod 失败原因调整成用户和系统两部分，创建成功率的定义就变成了创建成功的 Pod 和总的 Pod 减去用户失败 Pod 的比值。\n2 蚂蚁集团的 SLO 体系 确定好 SLO 各项关键指标的定义之后，接下来就是构建 SLO 体系。\n据范康介绍，蚂蚁集团 SLO 系统主要包括两个方面，一个方面用于向终端用户 / 运维人员展示当前集群各项指标状，另一方面是各个组件相互协作，分析当前集群状态，获取影响 SLO 的各项因素，为提升集群 pod 交付成功率提供数据支持。\n蚂蚁集团 SLO 体系架构图\n自顶向下而看，蚂蚁集团 SLO 的分层架构包括 SLO、Trace system、Increase of SLO、Target 和 The unhealthy node。\n其中，顶层组件主要面向各种指标数据，如集群健康状态、pod 创建、删除、升级成功率、残留 pods 数量、不健康节点数量等指标。其中 Display Board 是指监控大盘，可能不会实时查看，为避免错过处理紧急事件的最佳时机，同时构建了 Alert 告警子系统，支持配置多种告警方式；Analysis System 通过分析指标历史数据以及采集到的节点 metrics 和 master 组件指标，给出更详细的集群运营报告；Weekly Report 子系统给出当前集群本周 pod 创建 / 删除 / 升级的数据统计，以及失败案例原因汇总；Terminating Pods Number 给出一段时间内集群内新增的无法通过 Kubernetes 机制删除的 Pods 列表和 Pods 残留原因；Unhealthy Nodes 则给出一个周期内集群所有节点的总可用时间占比，每个节点的可用时间、运维记录、以及不能自动恢复，需要人工介入恢复的节点列表。\n为了支撑上述这些功能，蚂蚁集团还开发了 Trace System，用来分析展示单个 pod 创建 / 删除 / 升级失败的具体原因。其中包含日志和事件采集、数据分析、pod 生命周期展示三个模块。日志和事件采集模块采集各 master 组件以及节点组件的运行日志和 pod、node 事件，分别以 pod/node 为索引存储日志和事件；数据分析模块分析还原出 pod 生命周期中各阶段用时，判断 pod 失败原因，节点不可用原因。最后，由 Report 模块向终端用户暴露接口和 UI，向终端用户展示 pod 生命周期以及出错原因。\n3 经验总结 目前蚂蚁集团的 SLO 实践不仅提高了集群 pod 的交付成功率，同时通过构建 tracing 系统，分析到集群内 pod 交付关键链路的耗时，整理失败原因，实现了数据分析 / 诊断平台。对于如何实现高 SLO，范康也给出了自己的五点经验。\n 在提升成功率的进程中，SLO 治理团队面临最大的问题是镜像下载。Pod 必须在规定时间内交付，而镜像下载通常需要非常多的时间。所以，团队通过计算镜像下载时间，专门设置了一个 ImagePullCostTime 的错误，即镜像下载时间太长，导致 Pod 无法按时交付。另外，阿里镜像分发平台蜻蜓支持了 Image lazyload 技术，在 Kubelet 创建容器时，不用再下载镜像，大大加速了 Pod 的交付速度； 提升单个 Pod 成功率：随着成功率的提升，再提升的难度会越来越大，这是可以引入 workload 进行重试。蚂蚁集团内部的 PaaS 平台会不断重试，直到 Pod 成功交付或者超时。需要注意的是，重试时要先排除之前的失败节点； 检查关键 Daemonset： …","date":1597820400,"description":"随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。本文分享蚂蚁集团的 SLO 体系是如何建立的。","dir":"blog/antgroup-kubernetes-high-slo/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f15367978d8b820ec3fcddf3ab6d7779","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-kubernetes-high-slo/","publishdate":"2020-08-19T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/antgroup-kubernetes-high-slo/","summary":"随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。 根据 CNCF 2019 Kubernetes 使用调查报告的显示：目前 84% 的用户已经在生产环境中使用 Kubernetes，生","tags":["Kubernetes"],"title":"蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO？","type":"blog","url":"/sofastack.tech/blog/antgroup-kubernetes-high-slo/","wordcount":2530},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈亚兵 提问：\n 我想单独使用注册中心 SOFARegistry，可能的服务有 Java 和 Python，SOFARegistry 支持 Python 服务接口的注册吗？\n A：SOFARegistry 注册中心是支持各个语言的服务发现和订阅的，目前开源版中只有 Java client。实现其他语言的服务发现和订阅，需要自己实现相关语言的 Registry client。\n sofa-bolt-python 也有服务发现和发布，它和 sofa-registry 的发现有什么不同吗？\n A：sofa-bolt-python 只做了使用 MOSN 的服务接口的客户端。sofa-registry 是服务端。 SOFARegistry：https://github.com/sofastack/sofa-registry\n2、@刘明 提问：\n Seata 的 XA 模式做了一个压测，tps=1000，开始报错，ORA-24756：事务处理不存在。 看了下数据库global_table，状态是 3。 3 是 CommitRetrying ， 这说明 phase 1 阶段过了，2 阶段提交报事务不存在。 目前 global_table 里有700多条记录，95%是状态3，还有状态1的。\n A：应该是一个原因，很可能就是2阶段提交失败了。begin 的你查看下他的分支事务状态是什么。\n begin 的分支表里没有数据，可能注册就失败了。\n A：是的，有可能，TC 收到了，然后 TM 超时了，我建议你 1000tps 的测试，搞个 TC 集群，就一台可能撑不住。\n 我想在出错的时候，有个日志轨迹，可以知道数据目前是不是脏的？\n A：select for update 或者 update x=x+n 这样写法一般没事。\n 会不会锁住记录呢？\n A：不锁住怎么保证隔离性。这个 for update xa 没提交前会锁住的，这个锁由数据库方自己已经实现了。\n 是的，那1阶段已经过了，记录会一直锁在那里了吗？\n A：二阶段没提交，锁在数据库肯定没释放。不过看起来你应该提交了吧，因为已经提示你事务不存在了。\n 是的，事务提示不存在，但是数据没有提交。 我研究下。\n A：可以的，seata-xa 现在还不是特别完善，可以多研究下，发现问题可以提交 PR 来贡献，一起让 XA 更稳定更好。\n 并发情况下，事务已经提交，TCC 发起 global commit 请求超时导致了 commitRetry，因此事务不再存在，只是 TCC 会一直去重试。 这导致了性能下降很快，不断重复已经不存在事务的 commit 动作，使用 Oralce 测试下来耗时很大，MySQL 可能也不会更好。考虑在 RM 端做 xaCommit 的时候，引入一个 Redis 检查 xid 是否已经提交，已经提交返回提交成功。\n Seata：https://github.com/seata/seata\n本周推荐阅读 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？ SOFA 项目进展 本周发布详情如下：\n发布 SOFABoot v3.4.3 版本，主要变更如下：\n 新增 endpoint，支持展示启动耗时信息； 升级 Tomcat 版本，修复安全隐患 CVE-2020-11996； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.3\n社区活动报名 A2M 峰会旨在发现全球互联网领域在人工智能、大数据、互联网架构等领域的创新工程和杰出团队，整合国际最佳技术实践，构建行业案例研究智库，帮助中国企业在人工智能时代成功转型、升级。蚂蚁集团受邀进行云原生构建之路的专题分享。\n分享主题：Dubbo 基于 MOSN 在 Service Mesh 场景下的落地实践\n分享嘉宾：曹春晖 蚂蚁集团 可信原生技术部技术专家\n蚂蚁集团技术专家，对 Go 语言有深入的研究，《Go 语言高级编程》作者。在后端业务开发、数据平台等领域有多年的实践经验。目前正在领导 MOSN 社区进行 Dubbo 生态在 Service Mesh 场景下的落地工作。\n背景介绍：过去一段时间，云原生和 Service Mesh 大火。很多公司希望借着东风推动公司的微服务架构演进到下一阶段。然而在实践过程中不会事事如意，问题接踵而至。\n在使用 Dubbo 来做微服务框架的公司中，因为每个公司发展阶段不同，上云的进度不同，社区方案却要求必须要在完全上云之后才能沐浴 Service Mesh 的春风，这着实令人失望。\n解决思路：借助前人的落地经验，在 MOSN 与 Dubbo 结合的探索中，我们思考出一些可供处于不同上云阶段的公司参考的落地方案。经过对数据面的简单改造，在控制风险的前提下，能够渐进地将 Service Mesh 落地到公司内。\n成果：基于 MOSN 和 Dubbo-go，实现 Service Mesh 在 Dubbo 场景下的落地。\n听众收益：\n 了解落地 Service Mesh 对于整体架构的收益； 了解 MOSN 社区的发展现状和规划； 了解 Dubbo 在各种业务场景和上云发展阶段中如何优雅落地 Service Mesh； 分享时间：2020-09-05 16:50-17:50\n活动地点：上海\n活动报名：点击“这里”锁定席位\n","date":1597388400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200814/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"68d4b22d401ef51b62f39c8680895b36","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200814/","publishdate":"2020-08-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200814/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot 发布、SOFAJRaft 以及 SOFARPC 内容合辑、MOSN 活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200814/","wordcount":2113},{"author":"万佳","categories":"Kubernetes","content":" 在 Kubernetes 中，Secret 显得尤其重要。因为它是 K8s 中存储所有敏感信息的对象。据悉，这些敏感信息包含密码、集群的证书、OAuth token、ssh key 以及其他用户自定义的敏感文件等。因此，一旦 K8s 中 Secret 出现安全问题，后果将非常严重。此外，虽然社区提供了一定的安全防护方案，但是依然存在诸多问题。\nK8s Secret 面临着哪些安全问题？这些安全问题会带来什么影响？社区提供的解决方案存在哪些不足？\u0026amp;hellip;\u0026amp;hellip;针对这些问题，InfoQ 记者采访了蚂蚁集团高级工程师秦凯伦，他专注于可信计算、系统安全和虚拟化等领域，对 K8s Secret 有着深入的研究和探索。\nK8s Secret 的安全问题 根据 Kubernetes 文档，Secret 是 K8s 中存储所有敏感信息的对象。事实上，如果敏感信息直接存放于 K8s 的 Pod spec 或镜像中，不仅管控困难，而且存在较大的安全隐患。因此，K8s 通过创建、管理、应用 Secret 对象，可以更好地控制敏感信息的用途，并降低其意外暴露的风险。\n秦凯伦称，虽然引入 K8s Secret 对象，这在一定程度上降低了意外泄露的风险（更多地是通过集中式的管理），但是 K8s Secret 对象自身的安全性，“社区默认方案中仍存在许多安全问题”。\n一般来说，K8s 中，Secret 数据以纯文本的方式存储在 etcd 中，默认只有 base64 编码，未经加密。同时，共享该文件或将其检入代码库，密码容易泄露。\n社区解决方案的不足 针对此问题，K8s 社区提供了基于 KMS 的 K8s Secret 加密方案，谷歌云、AWS 和 Azure 均支持该方案。他说，“这虽然解决了 etcd 中 Secret 明文存储问题，但依然有一些问题。”\n Secret、加密 Secret 的密钥在内存中明文存放、易被攻破； 攻击者可以假冒合法用户，调用解密接口，窃取密钥； 密钥一旦泄露，将导致所有数据的泄露，从而引起用户对整个系统的信任崩溃。“为此，社区和一些公司尝试为该方案中的 Plugin 加上基于硬件的安全保护，从而提升攻击难度。但对某些特定用户来说，保护的覆盖面和程度依然不够”。\n实际上，我们可以从 K8s Secret 的整个生命周期来看：\n Secret 的生成及访问 Secret 的身份证书明文存放在用户侧内存中，用户侧环境复杂，容易被攻击者攻破； 加密 Secret 的密钥的生成、cache 等在 K8s API server 中明文存放在内存中，安全根易被窃取或破坏； 与 KMS 交互的 Plugin 的加解密接口无法防止攻击者假冒，存在泄漏风险； Secret 在 Node 中消费，依然明文内存存放，暴露出一定攻击面； 在秦凯伦看来，理想中，对 K8s 中 Secret 的保护程度应该考虑其整个生命周期的安全、可信，做到端到端的安全防护。\n蚂蚁集团的探索 为此，他们基于 TEE 技术，将 K8s Secret 整个生命周期和端到端使用过程中的关键组件、步骤保护起来。整体方案大致如下：\n 将 API Server 端与 KMS 交互的 KMS Plugin 用 TEE 保护，在保障了 Plugin 中根密钥（安全根）、数据加密密钥无泄漏风险的前提下，降低了性能开销； 将 API Server 端的 KMS provider 用 TEE 保护，避免数据密钥及 Secret 在任何时候明文直接暴露在内存中；同时，通过 TEE 的本地证明机制能够认证解密数据密钥接口的调用者，防止攻击者假冒，确保密钥的安全； 将用户端的 kubectl、kubeconfig 等使用 TEE 保护，一方面 kubeconfig 不落盘同时被硬件保护，提升了安全水位；另一方面，用户的 Secret 通过安全信道直通到 TEE 中进行处理，避免了直接暴露在内存中，规避了被恶意窃取的风险，且用户对 API Server 进行 TEE 远程证明，可以帮助用户确信他正在把自己的 Secret 托付给可信的软件实体（没有含有故意泄露用户秘密的恶意逻辑），建立对 API Server 的信任； 将 Node 端的 kubelet 中 Secret 的消费过程用 TEE 保护，进一步避免了 Secret直接暴露在内存中，规避了被恶意窃取的风险； 秦凯伦向 InfoQ 记者指出，“这种方案是基于 TEE 的端到端 K8s Secret 保护，还引入 LibOS 技术，实现 TEE 保护对用户、开发者和运维团队完全透明。”\n据悉，KMS Plugin 和 TEE-based KMS Plugin 没有标准和开源的社区实现，因此他们设计并开发了自己的 KMS Plugin，并在灰度发布、应急处理、监控管理等方面进行了生产增强。“在与 TEE 结合的过程中，我们为了应对 SGX 机型存在的性能问题，提供了 standalone 和服务化 KMS Plugin 两套方案”。\n同样，TEE-based kubectl 也没有标准和开源的社区实现，他说：“我们基于 kubeproxy 开发了自己的安全 kubectl，实现了 kubeconfig 对用户透明、与用户身份绑定、不落盘并采用TEE保护内存安全等设计目标。”\n此外，考虑到 TEE 保护的易用性、可靠性、可扩展性和可维护性等，他们在评估多套方案后，引入了由蚂蚁开源的 Occlum LibOS，屏蔽了 TEE 对用户、开发者和运维团队的影响，大大降低了 TEE 开发的门槛和成本。\n在秦凯伦看来，K8s 作为蚂蚁大规模容器集群的管控根基，应用基于 TEE 的端到端 K8s Secret 保护防护方案，增强了其自身安全和可信，提升了蚂蚁核心管控平面的安全水位，“这对于金融场景下高标准的数据安全和隐私保护来说不可或缺”。\nK8s 相关阅读 备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？ Kubernetes: 微内核的分布式操作系统 开箱即用的 Java Kubernetes Operator 运行时 深入Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统 深度 | 蚂蚁金服自动化运维大规模 Kubernetes 集群的实践之路 ","date":1597215600,"description":"K8s Secret 面临着哪些安全问题？这些安全问题会带来什么影响？社区提供的解决方案存在哪些不足？","dir":"blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"39e435e749635a88bce9e36771e5b2e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","publishdate":"2020-08-12T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","summary":"在 Kubernetes 中，Secret 显得尤其重要。因为它是 K8s 中存储所有敏感信息的对象。据悉，这些敏感信息包含密码、集群的证书、OAuth token、ssh key","tags":["Kubernetes"],"title":"蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？","type":"blog","url":"/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","wordcount":1958},{"author":"SOFA 团队","categories":"SOFAStack","content":" PS：阅读本文大约需要 15 分钟，或者您可以选择直接拉至文末投递简历，加入云上江湖。\n 有人说，历史是由懒汉推动的。\n科技的演进史，其实就是人类不断偷懒的过程。我们懒得浪费体力，于是有了蒸汽机；我们懒得动笔演算，于是有了电子计算机；我们懒得随身携带现钞，于是有了线上交易和无接触支付……程序和信息成为这个时代的基底，服务和应用围绕着我们的指尖打转。\n我们从网络上索取一切，海量的数据和代码在赛博空间里奔流不息。\n突然有一天，构筑代码世界的工人们也犯懒了。为首的“懒汉”开始思考，能不能把一些通用的代码模块打包起来，供给上层随时取用，这样就省下了重复“造轮子”的力气，让敲代码也成为一种模块化的工作？\n这一“偷懒”，就偷出了一个新概念：中间件。\n无人探索的道路 对普通人来说，“中间件”是一个很遥远的词汇。\n从技术层面来讲，中间件是介于基础设施和业务系统之间的特殊软件。程序员们别出心裁地构思了各种比喻：有人说它是建筑工地上的“预制件”，让工人不必从头开始搅拌水泥；有人说它是整合货源的“中间商”，让商家免于一次次询价比价的操劳……\n“基础设施和业务系统之间，有很多通信和集成方面的要求，让每个业务系统都去做一遍是很浪费人力的。”蚂蚁集团高级产品专家马振雄这么说，“大家都有这样的诉求。”\n时势造英雄，SOFAStack 在蚂蚁集团应运而生。\n它诞生得悄无声息，初衷只是为了“解救”支付宝。那还是青涩年代的支付宝，没有琳琅满目的蚂蚁森林、花呗和健康码，用4个“一”就能概括它的全部：一个简单的应用，装在一台应用服务器上，使用一个数据库，服务一个大客户——淘宝。\n简单、轻快、便捷，这个系统支撑了支付宝从2004年到2006年早期的发展。但是随着交易量的攀升、业务的复杂化，支付宝很快遭遇了成长中的阵痛。\n“从刚开始几十个人，后来几百人，到现在几千人的技术团队，在不同规模下的研发方式和组织方式都是不一样的。”蚂蚁集团高级技术专家黄挺说，“人一多，你发现不同的人写的代码会不一样，冲突也越来越多。”\n概而言之，研发效率出现了问题。\n如果说从前的支付宝是一间平房，如今则要发展成一座城市。而每搭建一座建筑，工人都必须从头开始烧制砖块、搅拌水泥——没有挖掘机，没有液压锤，一切从手无寸铁开始，对以“建设城市”为己任的团队来说，这是完全不可接受的。\n举个例子，当时支付宝的一个电子钱包系统 iWallet，每次启动需要五六分钟，足够开发人员下楼抽一支烟。如果发现错误，就得修改后重新启动，开发人员每天深陷在代码编译和重启的“死循环”之中。\n究其原因，就是因为 iWallet 系统包含了几十个工程，有十多个团队并行开发。支付宝原本的系统无法支撑这么复杂的业务逻辑，也难以让那么多工程师在一起并行工作，大家把它称为 monolithic——庞大的单体系统。\n支付宝的诉求显而易见：第一，希望成百上千个项目并行进行，每个工程师可以不受干扰地工作；第二，当业务逻辑增加的时候，系统的复杂度不要成指数级上升。 它需要一套能够力挽狂澜的“中间件”。\n2006年，契机来临。技术团队在这一年开了一连串的会，会议的核心议题只有一个：决定支付宝未来的技术架构。团队内部分成两派：第一派提议向银行老大哥学习，走集中式架构的老路；第二派则认为分布式架构才能支撑未来的交易支付系统，而且不是客户端/服务器时代那种小规模架构，是互联网时代的超大规模分布式架构。\n毫无疑问，这是一条无人探索过的道路。\n当然，你知道阿里人的秉性，退缩和守成从来不是他们的标签。经过长达一年左右的思考和论证，技术团队果断驶入第二条赛道。2007年起，支付宝率先启动了对交易系统、商户系统、会员系统、支付清算系统的改造，一个全新的架构正在孕育之中。\n这套分布式架构就叫“SOFA”。\n为什么叫这个名字？其一是源于当时正火的“SOA”概念，即 Service-Oriented Architecture，“面向服务的架构”，在此基础上加入金融业务，就构成了 SOFA 的全称：Service-Oriented Fabric Architecture。\n其二则是开发者的私心，“希望能够像沙发（Sofa）一样，让工程师可以非常爽地工作。” 从“连接器”到“工具库” 什么是 SOA？用偏技术的语言表述，就是把企业的 IT 系统以“服务”的方式重新组织，再通过“服务总线”连接起来，形成可插拔式的企业 IT 架构，这个架构就是 SOA。\n你或许觉得这个释义很难懂，没关系，因为在那个年代，SOA 纯粹只是一套面向传统企业 IT 架构的思想，换句话说，一套理论框架罢了。\n你问业界具体的成功实践？抱歉，没有。\n初次试水，蚂蚁的“探路者”们走得非常谨慎：第一代 SOFA 只解决两个问题，一是充当一个类似于“胶水”、“连接器”的机制，把分布式系统连接成整体；二是做到每一个服务组件化，让每个工程师专注做好各自的组件，最后把组件拼装在一起成为“服务”，再把“服务”拼装在一起组成整个系统。\n用黄挺的话来说，“SOFA 能够隔离出一些不同的模块，由不同的人去做开发，每个人有了更加细致的分工，不会跟别人出现太多的交叉。”\n第一代 SOFA 清晰地定义了团队之间的边界，何时分工协作，何时紧密联合，安排得明明白白。黄挺举了个例子：简单的一次转账业务，系统需要调用用户的通讯录，调用账务相关的子系统——可能还得去问银行，账户余额到底够不够？整个流程涉及到非常复杂的系统交互，这些由不同团队开发和运维的系统，怎样才能高效交互、稳定完成每一笔业务呢？这就仰赖 SOFA 从中协调和沟通了。\n燃眉之急解决了，但初生的分布式中间件 SOFA 并不能处理所有问题。它还需要打怪升级，积累经验，向下一代、再下一代演化。\n无人探索的道路上没有先驱者，只有野蛮生长的技术难题在横冲直撞。\n在 SOFA 的加持下，支付宝一边拆分金融业务系统（后来的业务中台）一边拆分底层 IT 系统（后来的数据中台和计算中台），在拆分过程中还要应对历年双十一的海量数据冲刷，以及不断涌现、千奇百怪的技术问题。甚至在解决分布式服务一致性问题时，由于业界提出的两个 SOA 事务标准都无法支撑支付宝核心系统的交易量，团队干脆一狠心一咬牙：现有的标准都不可行，要不我们自己提一个吧！\n逢山开路，遇水搭桥。很难说清 SOFA 这些年来的演进中，他们遭遇过多少类似的阻碍，又有多少奇思妙想和技术实践沉淀下来，最后凝练成 SOFA 内部的几行代码。\n他们在无人区设下哨塔，漫漫长夜被灯火点亮。\n第一代 SOFA，做到了模块化。\n第二代 SOFA，完成了服务化。\n第三代 SOFA 的亮点，则是被誉为“蚂蚁黑科技”的单元化，“异地多活”架构让服务器资源水平扩容的难度大大下降，保障了用户的每一笔订单平稳顺滑。团队坦诚，面向超大规模互联网金融交易的分布化改造，单元化这一技术构想完全是被业务倒逼的，业界没有先例可循。\n“我们找到过一些论文、一些概念，但以支付宝这么大的体量，没有人确定这事儿真的能做成。”团队成员感慨。\n就这样，随着支付宝架构的逐次优化，SOFA 也在不断迭代和成长。从最初仅是一个简单的框架，到后来强化通讯性能、提升容灾效率、建设异地容灾架构、单元化改造、添加 LDC 逻辑数据中心项目……SOFA 羽 …","date":1597042800,"description":"从初试锋芒到大展拳脚，从无人区的前哨到数字化转型的领航员，云上自有江湖，欢迎加入云上江湖","dir":"blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","fuzzywordcount":8900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dc1065f8e3a2e016a6fc8750bbfab2c2","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","publishdate":"2020-08-10T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","summary":"PS：阅读本文大约需要 15 分钟，或者您可以选择直接拉至文末投递简历，加入云上江湖。 有人说，历史是由懒汉推动的。 科技的演进史，其实就是人类不断偷","tags":["SOFAStack"],"title":"蚂蚁 SOFAStack：云上自有江湖","type":"blog","url":"/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","wordcount":8849},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@丁浪 提问：\n 这个跟 TCP 长链接的心跳没根本区别啊！也只能保证链路上的通畅，应用僵死或者苟延残喘了可能发现不了，可以补充从注册中心去主动探测 URL，反正现在 SpringBoot 和 SOFABoot 应用都可以开启 healthcheck 的 endpoint，为啥不从注册中心发探测请求，反正都有 healthcheck 的 endpoint。链路上的保活那只是基本生存需求，稍微高级一点就不行了，应用僵死或者苟延残喘那种可能还有心跳的。我看你们把这个问题交给 RPC 框架去做了，让 RPC 框架去做故障剔除和容错。 A：SOFARegistry 目前设计是比较依赖网络连接的，网络连接只要出发了断链事件（这个目前监听是靠 Netty 的事件通知过来的）就会进行数据清理，这个敏感性也决定了服务发现比较快，但是对于抖动和其他大面积不稳定情况处理确实显得不足。我们说的 RPC 框架剔除是对于经常性的链接不通地址采取自动降级不进行调用处理，至于 Spring 那种心跳检测机制，我们开始实现也考虑过，因为这个健康检查机制和网络断连触发的敏感性差别较大，健康检是定期轮训的可能确定服务下线没有这么快速发现，所以没有采用，后续也想过兼容两种模式解决这个断链处理，引入类似 ZK 那种 Session 过期等机制可以在快速发现和稳定性做一个取舍。\n 那种应用进程僵死、较长时间 fullgc 之类的，长链接心跳还在注册中心发现不了流量过来就有问题的，RPC 框架的剔除机制我个人认为只能是种兜底降级。我目前是结合 K8s 探针去请求应用的 healthcheck 路径的，K8s 健康检查不通过就会杀进程重启 Pod，这样注册中心也会感知到 RPC 流量也就剔了。\n SOFARegistry：https://github.com/sofastack/sofa-registry\n2、@倪美俭 提问：\n 这是 AT 模式，store:db，rollback 的交互图，麻烦帮忙瞅瞅有问题吗？ A：是的，一阶段都是提交的，二阶段如果是回滚就会把之前的本地 commit 回滚掉。\n 这种场景是否要优化下，直接发起二阶段回滚，就不再进行这个本地事务一阶段的提交呢？这里为什么会进入到本地事务的 commit 方法里，而不是 rollback 方法里呢？\n A：这种你把本地的事务注解加到全局事务注解下面就好了，这样发起方所在的本地事务是直接走 rollback，其余参与方才是二阶段决议通知下来。\n 强一致性需求的场景，Seata 里只能用 XA，但 XA 是依赖数据库本身对 XA 协议的支持来实现的，那是不是这种模式下性能上会比 LCN 要逊色一些呢？\n A：首先 LCN 的原理是通过 connection 的代理，使之做空提交，二阶段决议后，把 hold 住的 connection 进行真正的 commit 或者 rollback，然而这个方式的隔离性交由本地事务来实现，因为 connection 未提交，所以事务还未提交，强依赖了本地事务。其次除非你的服务不会宕机，否则不建议你使用 LCN 模式，因为如果在二阶段决议后，宕机了一个参与者，那么 LCN 是无法恢复之前的数据，导致数据丢失。\n而 XA 你可以认为他跟 LCN 也很像，但是 LCN 面对的是数据源连接，而 XA 你会发现这个才是由数据库真正意义上去支持的一个协议，即使宕机了，Seata XA 也是做了 XA 的预提交，持久化提交数据在数据库层面，但未真正提交，从而可达到宕机后重启也可以提交事务。\n这是我做在 Seata 中 LCN 原理实现的 PR：https://github.com/seata/seata/pull/2772 ，你可以阅读下，很容易发现他的缺陷，LCN 的性能高是基于啥也基本没干，就多了个几个 RPC 通信的消耗，无需解析 SQL，做镜像校验，全局锁解锁等操作，他仅仅只是把本地事务的提交延迟到其余的参与者都完成了业务并且没发生异常的情况下。看过这个 PR 或者 LCN 的源码后，你就会真正的理解为什么 LCN 说自己不产生事务，而是事务的协调者而已。\n 去年看过 LCN 的源码，它也是代理了数据库连接，在一阶段会 hold 住所有的数据库连接，并不真正提交，二阶段会全部一起提交或回滚，那么有参与者宕机的话不应该会全部回滚吗？\n A：因为是基于本地连接的回滚，连接断开会自动回滚，所以即使二阶段决议形成提交时，若应用或网络出问题，连接断开就自动回滚了，不能保证极端一致性。 Seata：https://github.com/seata/seata\n本周推荐阅读 少年五年升阿里 P8，他如何从低谷登上“光明顶”？ 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.15.0 版本，主要变更如下：\n 新增 UDP Listener 的支持； 新增配置扩展能力，Dubbo 服务发现可通过扩展配置扩展，支持 Yaml 格式的配置解析； 新增流量镜像功能的扩展实现； 支持了更多路由配置； Skywalking 升级到 0.5.0 版本； 针对 Upstream 与 XProtocol 进行了优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.15.0\n同时，恭喜邓茜（@dengqian）成为 MOSN Committer，感谢她为 MOSN 社区所做的贡献。\n2、发布 SOFARPC v5.7.5 版本，主要变更如下：\n 修复日志打印的问题； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.5\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题： …","date":1596783600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200807/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3ae77ff6536d0104b38d51679b7f078b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200807/","publishdate":"2020-08-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200807/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN \u0026 SOFARPC 发布、MOSN 社区活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200807/","wordcount":2576},{"author":"陈伟荣","categories":"智能监控","content":" 电影《太空旅客》里，无人驾驶的阿瓦隆号飞船去往家园2号要经历120年，飞船的顺利抵达必须依赖一套高端智能运维系统。在蚂蚁，技术风险部的智能监控就好比那个智能运维系统，而智能监控团队便是背后那群看不见的守护飞船的人。\n 2019年双十一的凌晨三四点，阿里西溪园区附近的某家网咖里门客冷清，只有几个神色淡定的青年小伙聚在一排座位上愉快地进行 DOTA 游戏， 他们时不时看一眼手机上发来的消息，像是在守着什么不敢掉以轻心，但脸上又流露出胜券在握的信心。\n就在几个小时前，这群看似“不务正业”的网咖少年还坐在阿里双十一最核心的作战室“光明顶”，与阿里众大佬高管一起值班，助力双十一决胜千里。\n他们正是蚂蚁集团技术风险部智能监控团队。\n对于阿里人来说，“光明顶之战”为每年大促中的巅峰一战，能够登上“光明顶”的非泰山北斗即拥有超强武功的高手。作为该团队主力之一的陈伟荣说，光明顶上各路阿里大神、大佬汇聚一堂，每年的双十一就是智能监控团队的“高光时刻”。\n从象牙塔走向“光明顶” 在蚂蚁技术大事记上，智能监控团队于2012年就曾被留名：首次实现秒级交易监控。之后，他们每隔一段时间就会有技术突破。2014年至2016年期间，蚂蚁监控就用一套 xflush 系列产品成功走出蚂蚁实现与阿里集团监控团队的合作，为当时的淘系赋能。之后的 sunfire 监控、新一代阿里集团网络监控与 IDC 监控均是在此基础上迭代而来，并且沿用至今。\n这期间，一位青涩少年正从象牙塔走向阿里。他就是陈伟荣，2015年以应届毕业生身份加入阿里监控团队成为一名工程师。\n和很多刚毕业的同学一样，陈伟荣对互联网公司的技术体系并不熟悉，彼时他眼中的监控团队更像是一个运维工具组，日常工作就是服务器上看看日志，看看 CPU、内存指标，再做下数据展现就完事了。相较于消息中间件、数据中间件、虚拟化、块存储等各种基础技术团队相比，初入职场的陈伟荣偶尔也会觉得智能监控好像并没有那么高端大气上档次。因此才刚工作几个月，他就判定自己在监控团队肯定呆不了多久就会转岗。\n但是随着进一步深入工作领域，他发现大家工作对标的是各类流式计算，加之团队重视底层引擎研发，在对计算框架和时序存储研究一番后，陈伟荣意识到团队在做的事一点都不比其他基础技术团队简单：这是一个非常典型的垂直领域大数据应用，技术和业务上都非常具有相当挑战性。\n在技术层面上，实时、稳定、低成本、高精度都是对监控的要求，这些约束条件做到一点两点不难，但是要同时做到，极难。但陈伟荣所在的团队就是落地了这样一个高度稳定，秒级延迟，PB 级吞吐的监控平台，他透露后面团队还将重点发力算法和智能化能力。\n2016年发生了很多让陈伟荣迄今难忘的事，有一些事情的影响至今存留。\n那年支付宝新春红包登上了央视春晚，春晚直播屏幕前是全国人民一双双充满期待的眼睛。对于春节红包项目组的技术同学来说自然是严阵以待、不允许有丝毫差池。入职仅半年的陈伟荣有幸和团队其他精兵强将一起加入项目组，承担实时数据计算部分的任务，他主动提出要做项目内相对复杂的内存缓存部分研发。\n但代码写出来后陈伟荣被师兄狠狠痛批了。本来对于自己的技术和工作态度都很有信心的陈伟荣看到师兄一边改 bug 一边骂、一副恨铁不成钢的架势，心中的底气彻底被击碎。\n此后，少年卸下傲气，行路时步步夯实。\n2016年的双十一如约而至，这是陈伟荣在监控团队的第二年，面孔依旧很新，但是双十一活动却已经迎来了第八年。恰逢又一年的光明顶之战，团队却正好缺位，陈伟荣主动挺身而出，承担起阿里16年双十一监控系统稳定性负责人的角色。\n那次双十一，陈伟荣首次挑大梁，最终拼尽全力不负众望完成任务。双十一交易巅峰来临的那十几分钟也成为陈伟荣至今回忆起来最难忘的一段时间。据后来公布的数据了解到，2016年的双十一支付宝支付峰值已达到12万笔/秒，全天交易量达十亿，但是没有一笔交易异常。\n“平时研发中只要我认定这个事情从长期，或者更高视角看能帮助到团队和用户，我就愿意去做一些非常危险的，甚至短期都看不到收益的研发工作，”陈伟荣说。\n2017年，陈伟荣从阿里集团转到了蚂蚁集团，随后逐步切入工作，带领着蚂蚁技术风险部监控技术中台，负责数据的采集链路和实时计算的架构，并在此基础上构筑监控的数据服务体系。猛将加持，蚂蚁监控团队持续发力，2018年后，他们便结合自身的定位和业务目标，重新审视监控这个领域，又推出了 Antmonitor 系列的监控产品，现已发展到了2.0版本。 五年升P8，回首依然是少年 十年前，高考在陈伟荣生命里落下帷幕。只不过这场尽力准备了三年的考试，结果并不如意。\n高考成绩出来后陈伟荣大失所望，比正常发挥时几乎掉了一个层次，最后被南开大学德语专业录取，几乎等同于被调剂。高考后的暑假，难以接受打击的陈伟荣一度靠游戏度日。在复读和将就之间纠结了很久后，最终他决定向前看，并开始着手调研和规划大学的学习计划，为转专业作准备。\n高考失意，大学时奋起直追，陈伟荣通过各种努力走出了一条独特的发展道路：从文科的德语专业到软件工程专业，期间还修了金融学学位。\n毕业前的校招季，不少互联网公司开始招实习生，陈伟荣把简历投递给了阿里。但那时他心里更想走的是继续出国深造的路，所以当年投的简历更多是无心插柳之举。\n经过几轮紧张的现场面试后，没想到第二天阿里面试官就电话通知陈伟荣面试通过了。人生就是这样不可预料，同期报名的同学中仅他一个临时起意投递简历的被录取了。来了阿里后，陈伟荣一下子被阿里技术体系的先进性吸引了，实习转正后，他便决定不再继续读书直接工作了。\n他不知道自己本科拼命几年扭转的人生方向是否正确，只携一身热血前往，不回头。\n从2015年加入阿里开始，陈伟荣一直在监控领域做事，但是工作范围逐渐放大，从最初采集 agent 研发到逐步深入理解整个数链路、开始掌握数据技术架构，到现在能带领团队推进技术架构演进，他不断挑战自己的极限。\n五年时间弹指一挥间，说起过去，陈伟荣的回忆里酸甜苦辣翻涌。但要说最开心的时刻，他觉得是今年年初完成 pontus2.0 项目研发并最终上线支撑业务监控场景这个事。这次的技术升级突破了先前的监控技术框架，真正统一了监控数据层模型为未来数据建设铺平了道路，大家一起攻克艰难让项目按时落地，过程中的不易最后都变成了开心的回忆。\n团队里同事们年龄相仿，组队打篮球或者去网吧开黑打 DOTA 成为大家最放松的时刻，或嬉笑怒骂，或相互扶持，抛去工作上的对接合作与依赖关系，他们可以聊天南地北，聊海阔天空……\n最近，有一件事让 92 年的陈伟荣比较开心，那就是他专门定制的电吉他终于到货了。\n原来，这位少年还是一位重金属音乐爱好者。说着，他给我发来一个 Arch Enemy 在 2016 年 wacken 音乐节现场的视频链接，还提醒我要关小声音听。\n“我去过两次这个乐队在上海的 live，还跟主唱的那个妹子击过掌。”\n我眼前浮现这样一幅画面：“光明顶”少年与 Arch Enemy 歌曲中那些真实直白歌词达成了共识——人生也要“不断突破，向死而生”。\n","date":1596438000,"description":"坐在光明顶的少年。","dir":"blog/five-years-to-ali-p8/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"80f2d7c63c3dfb1ee561e79745630a68","permalink":"https://sofastack.github.io/sofastack.tech/blog/five-years-to-ali-p8/","publishdate":"2020-08-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/five-years-to-ali-p8/","summary":"电影《太空旅客》里，无人驾驶的阿瓦隆号飞船去往家园2号要经历120年，飞船的顺利抵达必须依赖一套高端智能运维系统。在蚂蚁，技术风险部的智能监","tags":["智能监控"],"title":"少年五年升阿里 P8，他如何从低谷登上“光明顶”？","type":"blog","url":"/sofastack.tech/blog/five-years-to-ali-p8/","wordcount":2786},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@刘明 提问\n 请问，分支事务在回滚过程中，服务器宕机了，重新启动后，TC 如果发送过来的回滚请求，是否还能继续回滚？\n A：可以。\n 是使用 XA 模式的 Oracle 数据库，分支服务器即使宕机了，回滚日志还在 Oracle 上是么？\n A：是的，xa_prepare 在 DB 实现 XA 层面做了持久化，MySQL 要求 5.7.7+。\n 刚测试了下 Oracle 的，xid 就像一个字符串 key 一样，任何时候只要告诉 Oracled 对 xid 做 rollback 都可以成功。我以为需要在 start/end 同一个连接里才行，是我理解错了。\n A：lcn 才需要这样，xa 不需要一个连接，所以 lcn 那种宕机了数据就没了。\n LCN 没有了解，他难道不是基于数据库自带的 XA 实现的？\n A：lcn 是 lcn 框架的一个原理，就是通过 connection 来统一提交和回滚。\n 我是用 jdbc 直接操作 Oracle 测试的，用 Oracle 的 XAResource。 这个特性是数据库自带的？\n A：XA 协议本来就是由数据库方进行的支持。\n 使用 DatabaseSessionManager 去存储 globalsession，这个 lockAndExecute 方法没有 lock 的逻辑，多个进程在获取 global 会话做超时、重试提交等时，会有资源冲突吗？\n A：多个 TC 会出现资源争抢冲突，倒是不影响一致性。\n 多个 TC 会对同一个 XID 做 retryCommitingg 操作吧，2个 TC 会做2次，3个 TC 会做3次？\n A：是的，没有分布式任务调度。\n 2个事务分支，TC 在发起提交请求后，分支一正常提交，分支二网络波动没有收到提交请求。 这个时候 TC 会尝试重试提交。 如果一直重试失败，会因为全局事务 timeout 发起回滚请求吗？\n A：提交一阶段就是持久化了，不会影响。\n 但是全局事务会有个超时检查，超时的事务处理方式就是回滚，会不会这样？分支二的提交重试一直不能成功，最后global 会话超时的吧？这时候分支一已经 commit，再做 rollback 肯定不行了。\n A：二阶段结果已经出现了，已经决议好了的，二阶段的提交只不过是空提交而已，异步的。\n 二阶段 TC 成功发送 commit，RM 接收到了后，执行 XA 提交动作，这时候数据才真正可以看到，如果 RM 接收不到 commit 请求，他本地数据时没有提交的吧？\n A：XA 模式确实是这样的。\n 那参与者中有人收到 commit 请求了，有人没收到，最后 global 超时，是不是也没法回滚了？\n A：XA 一阶段只是做了预备数据的持久化，保持操作，并没有真正入库，等到 commit 的时候才会入库，每个模式2阶段都不一样。 Seata：https://github.com/seata/seata\n本周推荐阅读 Kata Containers 2.0 的进击之路 Kata Containers 创始人：安全容器导论 Kata创始人王旭：远程工作可以从开源中借鉴哪些经验？ SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.4.2 版本，主要变更如下：\n 修复 ServiceComponent 和 ReferenceComponent 的健康检查结果不包含抛出的内部异常； 修复默认情况下 SOFA runtime 忽略组件抛出的内部异常； 增加引流操作的阻断性，fail fast； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.2\n2、发布 SOFAJRaft v1.3.4 版本，主要变更如下：\n 升级 SOFABolt 到 1.6.2（支持异步非阻塞建连机制）； 移除对 log4j 的直接依赖； RouteTable、RegionEngine、StoreEngine 实现 Describer 以提供更详细的调试信息； 修复 snapshot 文件创建漏洞，禁止跳出 snapshot 目录之外创建文件； 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.4\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题：云原生网络代理 MOSN 的进化之路 分享嘉宾：王发康（毅松）蚂蚁集团 可信原生技术部 技术专家 背景介绍：网络通信代理 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，增强 MOSN 服务治理及流量控制能力，对接云原生周边组件，实现 MOSN 开箱即用，MOSN 成为云原生 Service Mesh 的标准 Sidecar 之一，从而借力开源，反哺开源。 听众收益：可快速基于 MOSN 和 Istio 进行 Service Mesh 实践，了解微服务的发展历程、遇到的痛点以及解决方案，获取 MOSN 的功能特性，解决微服务常见的问题。 分享时间：2020-08-15 13:30-14:30 活动地点：深圳 活动报名：点击“这里” ","date":1596178800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200731/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ba067c1a03b386adff832962bb27dd52","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200731/","publishdate":"2020-07-31T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200731/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 以及 SOFABoot 发布、MOSN 社区活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200731/","wordcount":1941},{"author":"李昊阳","categories":"Kata Containers","content":" Kata Containers 开源项目于2017年底正式启动，其目标是将虚拟机（VM）的安全优势与容器的高速及可管理性相结合，为用户带来出色的容器解决方案。该项目在过去两年取得了哪些进展？下一版本的路线图包含什么特性？首先让我们快速回顾一下 Kata Containers 项目的奋进之路… 缘起：Kata Containers 2013 年，Docker 问世，容器成为热门新事物，全球的开发者为之着迷。也难怪，容器以标准格式封装，将运行于标准操作系统环境上的应用打包，使应用程序可从一个计算环境快速可靠的切换至另一个计算环境，这对于那些想要快速构建、测试和部署软件的开发者而言至关重要。容器具有轻量化、低开销的特性，几乎可以立即被调度和启动，可在任何环境中运行，为微服务提供便利，扩展资源等（以上仅列举了一些流行的优势）。 尽管有许多技术优势，但容器有一个缺点 - 容器与宿主机共享内核，这可能会引发严重的安全漏洞问题。理论上，如果您在单个主机上部署了多个容器，一旦其中某个容器被恶意代码利用，由于共享namespace，该主机上的其他所有容器也容易受到攻击，在这种情况下，可能会对云基础设施整体构成严重的安全威胁。如果您是云供应商，安全威胁可能会扩展到云端客户的数据和业务，这是绝对要避免的。\n图1. 传统容器：主要通过共享内核的 Cgroup 和 Namespace 来达到容器隔离和资源限制的目的\n因此，许多负责大规模容器运行的运维人员将容器“嵌套”在虚拟机中，从逻辑上将其与运行在同一主机上的其他进程隔离开，但在虚拟机中运行容器会丧失容器的速度和敏捷性优势。Intel 和 Hyper.sh（已加入蚂蚁集团）的开发人员意识到了这个问题，同时开始独立研发解决方案，两家公司都希望容器可以摆脱传统虚机的所有包袱，换言之，就是开发“面向云原生的虚拟化”技术：\n 来自 Intel 开源技术中心的工程师在 Intel Clear Containers 项目中运用 Intel Virtualization Technology（Intel VT）技术来强化性能和安全隔离； 与此同时，Hyper.sh 的工程师采用相似的策略启动了开源项目 runV，将容器放在一个安全“沙箱”中，通过支持多种 CPU 架构和管理程序，侧重于开发技术中立的解决方案； 2017年，两家公司将项目合并，互为补充，创建了开源项目 Kata Containers。Intel 和 Hyper.sh 联合开发者社区，希望在各方的共同努力下，兼顾性能和兼容性，在为终端用户提供出色应用体验的同时，加速开发新的功能特性以满足未来新兴用例的需求。Kata Containers 成为 OpenStack 基金会（OSF）除 OpenStack 之外的首个托管项目，该项目于2017年12月在北美 KubeCon 上正式公开亮相，社区座右铭是“快如容器，稳似虚机”。 其实质是，通过 Kata Containers 让每个容器/pod 采用其单独的内核，运行在一个轻量级的虚拟机中。由于每个容器/pod 现在都运行在专属虚拟机中，恶意代码无法再利用共享内核来访问邻近的容器，因此，容器即服务(CaaS)供应商能够更安全的提供在裸金属上运行容器的服务。由于容器之间的硬件隔离，Kata Containers 允许互不信任的租户，甚至生产应用及未经认证的生产应用程序都能在同一集群内安全运行。\n图2. Kata Containers: 每个容器/pod 被隔离在各自的轻量级虚拟机中\n因此，Kata Containers 与容器一样轻便快捷，并且可与容器生态系统无缝集成（包括流行的编排工具，如 Docker 和 Kubernetes），同时还具有虚拟机的安全优势。\n社区进展 Kata Containers 项目成立的第一年，社区主要致力于合并 Intel 及 Hyper.sh 的代码，并在全球的行业活动中介绍该项目独特的硬件隔离方案，这是其他容器运行时所缺乏的功能，同时也邀请了大量的社区开发者共同推进该项目。 Kata Containers 社区如今已经拥有众多的贡献者和支持者，包括来自九州云、阿里巴巴、AMD、AWS、百度、Canonical、中国移动、CityNetwork、戴尔易安信、易捷行云、烽火通信、谷歌、华为、IBM、微软、红帽、SUSE、腾讯、同方有云、中兴、英伟达、Mirantis、NetApp、PackageCloud、Packet、Vexxhost 等许多有影响力公司的开发者。随着社区的不断壮大，该项目正在稳步发展中。 社区成就包括：\n 加入开放容器倡议（OCI）规范，Kata Containers 社区持续与 OCI 和 Kubernetes 社区紧密合作，并在 AWS、Azure、GCP 和 OpenStack 公有云环境以及所有主要 Linux 发行版中对 Kata Containers 进行定期测试； 添加了对主要架构的支持，除 x86_64 外，还包括 AMD64，ARM，IBM p- 系列和 IBM z- 系列等架构； 无缝集成上游 Kubernetes 生态系统，Kata Containers 现在可以立即连接到大多数开箱即用的 Kubernetes 网络； 删除不必要的间接层，社区已经去掉了 kata-proxy 组件，并在 KubernetesSIG-Node 开发者和 containerd 社区的帮助下引入了 shim-v2，从而减少了 Kata Containers 辅助进程的数量； 降低开销，提升速度，社区正努力提升启动速度，减少内存消耗，并朝着创建（几乎）“零开销”沙箱技术的目标迈进。为此引入多个虚拟机管理程序，包括 QEMU，QEMU-lite，NEMU和AWSFirecracker。还与 containerd 项目整合，推动建立了 rust-vmm 项目，2019年，社区用 Rust 重写了一个沙箱内的 agent，显著减少了匿名页。总之，社区正通过一系列的改进工作来最大限度地减少开销，通过引入 FirecrackerVMM 将内存开销减少到 10MB，而通过 rust-agent 的合并将 agent 的匿名页从10MB减少到1.1MB； “面向云原生的虚拟化”，与面向虚拟机领域不同，容器领域是以应用为中心的，为了解决这种差异，社区引入了 virtio-vsock 和 virtio-fs，后续将引入更灵活的内存弹性技术virtio-mem； 如需详细了解项目进展，可查看王旭的系列博客：KataContainers: 两年而立 百度智能云的 Kata Containers 应用实践 百度，中国领先的搜索引擎运营商，全球最大的中文网站托管商，全球领先的 AI 公司-正在其百度智能云中大规模（超过 43k CPU 内核！）应用 Kata Containers，包括百度智能云函数计算（CFC）、百度智能云容器实例（BCI）、百度边缘计算等多种实践场景。 百度智能云是百度面向企业和开发人员的智能云计算平台，致力于为各行各业的企业提供一体化的人工智能、大数据和云计算服务。根据 Synergy Research Group 发布 …","date":1595919600,"description":"Kata Containers 项目的奋进之路","dir":"blog/kata-container-2.0-road-to-attack/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2eaaa668460266fb66b2b44f5611c472","permalink":"https://sofastack.github.io/sofastack.tech/blog/kata-container-2.0-road-to-attack/","publishdate":"2020-07-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/kata-container-2.0-road-to-attack/","summary":"Kata Containers 开源项目于2017年底正式启动，其目标是将虚拟机（VM）的安全优势与容器的高速及可管理性相结合，为用户带来出色的容器解决方案。该项目在过","tags":["Kata Containers"],"title":"Kata Containers 2.0 的进击之路","type":"blog","url":"/sofastack.tech/blog/kata-container-2.0-road-to-attack/","wordcount":4042},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网https://www.sofastack.tech SOFAStack:https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@Zhengguang 提问：\n 想问下，默认的 RMClient.init(applicationId, txServiceGroup); 这个方式启动 RM 的时候有个问题，它传递的 resourceId 为 null 也就是说 RM 初始化的时候虽然在 TC 注册了，但是注册的信并非之前断开始后那个 resourceId，所以 RM 重启后并不会立即收到来自 TC 的 retry。 以下是日志，可以看到默认 RM 初始化的时候 resourceIds 是空的： [timeoutChecker_2] INFO io.seata.core.rpc.netty.NettyPoolableFactory - NettyPool create channel to transactionRole:RMROLE,address:127.0.0.1:8091,msg:\u0026amp;lt; RegisterRMRequest{resourceIds=\u0026amp;lsquo;null\u0026amp;rsquo;, applicationId=\u0026amp;lsquo;api\u0026amp;rsquo;, transactionServiceGroup=\u0026amp;lsquo;my_test_tx_group\u0026amp;rsquo;} \u0026amp;gt;\n使用 API 方式，跑的是 seata-sample-api 这个 demo，AT 模式。\n A：1.其实 RMClient.init 的时候，并不会进行注册，真正进行注册的是初始化 DataSourceProxy的 时候。 2.如果注册的时候 resourceIds=\u0026amp;lsquo;null\u0026amp;rsquo;，很有可能你的 DataSourceProxy 没有初始化，也即是数据源没代理成功。\n 是的我观察到的就是这个现象，我这边项目更希望在 API 模式下使用 Seata，所以并没有通过 spring 启动，可能 DataSourceProxy 没有自动初始化，所以这里是不是应该有什么方式可以手动触发 DataSourceProxy 初始化的过程。\n A：手动配置一样就可以了，像这样子：\n\u0026amp;lt;bean id=\u0026amp;quot;dataSourceProxy\u0026amp;quot; class=\u0026amp;quot;io.seata.rm.datasource.DataSourceProxy\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;constructor-arg ref=\u0026amp;quot;dataSource\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; 哦哦，所以我要在 RMClient.init 启动后，马上手动获取一次 DataSourceProxy。Demo 中的这个 DataSourceUtil 要在第一次 getDataSource 的时候才会初始化 proxy，所以我要在 RMClient.init 启动后马上 get 一次数据源就好了， 测试通过。\n Seata：https://github.com/seata/seata\n本周推荐阅读 基于 MOSN 和 Istio Service Mesh 的服务治理实践 再启程，Service Mesh 前路虽长，尤可期许 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 SOFA 项目进展 本周发布详情如下：\n发布 SOFABolt v1.6.2 版本，主要变更如下：\n 支持检查连接并异步创建连接； 支持用户设置 UserProcessor 的 ClassLoader； 修复 URL 对象默认连接数为0导致不创建连接的问题； 修复无可用连接的 ConnectionPool 无法被回收的问题； 详细发布报告：https://github.com/sofastack/sofa-bolt/releases/tag/v1.6.2\n社区活动报名 机密计算（Confidential Computig）是近年来发展迅速的一种安全技术，它利用可信执行环境（TEE）——如 Intel SGX——来保证内存数据始终处于加密状态，因而将安全性提高到前所未有的程度，并赋能了诸多新型应用场景，比如多方联合数据分析、隐私保护的机器学习、保证机密性的区块链合约等等。虽然技术本身令人兴奋，但机密计算对应用开发者有比较高的门槛，令人望而却步。\n针对上面的问题，蚂蚁集团开源了 Occlum 项目，一款使用 Rust 语言开发的、面向机密计算的 TEE OS，可使得任何语言的任何应用程序轻松地移植进 TEE 环境。本次分享既会从用户角度介绍如何使用 Occlum 的轻松开发机密计算应用，也会从技术角度分享 Occlum 技术架构和特色。\nOcclum 网站：https://occlum.io\nOcclum Github：https://github.com/occlum/occlum\n本期主题：《SOFAChannel#18：零门槛的机密计算：Occlum LibOS 使用入门和技术揭秘》\n分享嘉宾：田洪亮（花名：樱桃） 蚂蚁集团技术专家 Occlum 开源负责人\n你将收获：\n 了解机密计算领域的最新进展； 了解 Occlum 的技术架构； 了解使用 Rust 语言开发安全软件的一手经验； 了解如何将创新工作转化为实用系统； 直播时间：2020-07-30 19:00-20:00\n报名方式：点击“这里”，即可报名\n","date":1595574000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200724/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6efe8af3dfb578bdfd495367e78b60e4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200724/","publishdate":"2020-07-24T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200724/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt 发布新版本、MOSN 相关文章整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200724/","wordcount":1603},{"author":"姚昌宇","categories":"Service Mesh","content":" Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。\n 本文根据7月22日晚 Service Mesh Webinar#2 有米科技高级后端工程师、MOSN Committer 姚昌宇，线上主题分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》整理，文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 大家好, 欢迎大家参加第二期 Service Mesh Webinar。本期的分享主题是《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。我是今天的分享嘉宾姚昌宇，来自有米科技，目前在公司也是负责服务治理相关的工作，我本身也是一名云原生爱好者，在空余时间关注和参与 Service Mesh 社区，最近参与了 MOSN 新版本的开发，也是有了很多收获。这次受社区邀请来给大家做这次分享，希望能给大家带来收获。\n今天的分享将从以下几个方面进行：\n 第一部分会简单介绍一下什么是 Service Mesh、Service Mesh 可以给我们带来什么红利以及我参与社区的过程和一些收获； 第二部分是这次分享的重点，我会从一个开发者的角度，说说如何基于 MOSN 和 Istio 去做服务治理，中间会包括 MOSN 源码的分析和 Istio 功能的实操，也是比较多 Service Mesh 爱好者关注的如何落地的问题，比如流量的控制啊、服务监控等等的功能； 第三部分会总结一下今天的分享以及 MOSN 一些近况和未来愿景的介绍； Service Mesh 简介以及社区共建实践分享 Service Mesh 简介 首先，什么是 Service Mesh 呢？相信这是众多爱好者刚接触 Service Mesh 时的最初疑问。Service Mesh 发展了这么多年，网上介绍和分析的文章也是很多，在这里我也再啰嗦一句。如果用一句话来概括 Service Mesh，我会说，它是一种微服务的通信方案，是不断演进而成的。\n大家都知道，服务端架构经历了一系列的演进，从最开始的单体服务到 SOA，再到微服务，服务间通信也从最开始的无需通信、到集成在代码里、再到胖客户端库，再演进为 Service Mesh 的 network stub 模式，又或者称为 sidecar 模式。\nService Mesh 主要解决了之前的服务间通信方案的几个问题：\n 语言绑定； 升级困难； 重复开发、标准不一； 语言绑定：在将服务治理逻辑抽离到 Sidecar 之前，这些治理逻辑需要集成在代码里面。这就容易导致业务要么要绑死在同一种开发语言上，要么就要相同的逻辑不同语言维护多份。这样既不灵活，维护起来成本也比较大。\n升级困难：企业里的基础设施团队，在升级服务治理逻辑之后，需要推动各个业务去重启他们的服务，这样一个周期通常会拖的非常长，重启过程也会有各种问题，导致线上各个版本的治理功能不一致，落地起来相当费劲。\n重复开发、标准不一：每个公司都会根据他们的实际情况落地微服务，有的会使用各个语言比较成熟的微服务框架，比如 Java 的 Spring Cloud、Dubbo；或者 Golang 的 go-micro 之类的框架。有的团队或者会使用集成组件的方式，在各个语言的基础上，加上一些成熟的服务治理组件，比如 Consul、Zookeeper、Hytrix、Vault 等。通常，通过对接这些组件来抽象出一个类似于微服务控制平面需要一定的开发成本，而且这些框架和组件标准也是不一致的，维护起来也会有不少成本。\n那么，Service Mesh 是如何解决这些问题的呢？\n首先，Service Mesh 架构将服务治理的逻辑抽离到一个单独的 Sidecar 进程中，而 Sidecar 进程是与语言无关的。Sidecar 通过代理的形式劫持业务进程的流量，从而做到与具体的业务开发语言解耦。\n其次，Sidecar 通过边车模式和业务进程部署在一起，但是又与业务进程分离。Sidecar 进程可以随时重启更新，业务进程无需感知这个过程。这样可以加速治理逻辑更新换代的过程，解决了传统服务治理，升级困难的问题。\n最后，Service Mesh 定义了控制面和数据面的概念。控制面提供 UI 给操作者去控制整个集群的流量，数据面，顾名思义就是数据流动的平面，负责接收这些配置信息，表现出对应的代理行为。控制面和数据面通过统一的协议进行通信，也就是 Service Mesh 里的 xDS 协议来交换配置信息。通过这样的方式，理论上实现了 xDS 协议的控制面/数据面可以互相插拔替换，这就统一了标准，解决了第三点重复开发和标准不一的问题。\n社区共建经历分享 那了这么多，那我是如何从关注 Service Mesh 社区，到参与到 MOSN 开源共建的呢？觉得整个过程可以概括成3点：\n 找到组织； 知识积累； 参与贡献； 其实一开始我也是一个初学者，刚接触到 Service Mesh 也会被一大堆不知名的名词砸得晕头转向的，像是 xDS、控制面、metrics tracing 之类的名词。所幸的是，ServiceMesher 的中文社区相当完善和活跃。我相信有了解过 Service mesh 的同学，肯定有加过2个微信 \u0026amp;ndash; 一个就是宋净超宋大的微信，一个就是 ServiceMesher 社区的微信群。也是得益于众多的前辈将 ServiceMesher 中文社区维护的这么好，将各种内部实践分享出去，以及外部一手资讯搬运甚至翻译过来，乃至是这样子的不定期的线上线下分享。这些都是非常好的资源。只要你想去学，就肯定有方法的。而对于新人的疑问，社区里的大神们也是非常乐意解答。\n既然有了目标和资源，那就差去做了。接下来我通过不断的去理解这些新领域的概念，理解它们的含义和背后的设计目的以及应用场景，再加上源码分析和动手实践，慢慢也就搭建起了整个关于 Service Mesh 的知识体系。\n在摸清门道之后，其实参与开发也不是什么难事了。那为什么我会选择 MOSN 呢？其实蚂蚁集团有整个 SOFAStack，也就是金融级云原生架构的开源共建计划，其中有服务注册、流量跟踪、rpc 协议、分布式事务等等的项目。我选择 MOSN 主要是有两点考虑：\n 第一是 MOSN 是使用 Golang 实现的，这一点和个人的技术栈比较吻合； 那第二点，我认为 Sidecar 在 Mesh 的位置是比较关键的。在大型的集群里，上百万的 Sidecar 在集群里互相通信，为业务进程转发处理数据包，其稳定性、性能要求和灵活性都是比较高的； 近期我也参与到了 MOSN 的 Istio Roadmap 开发中，主要目标是将 MOSN无 缝地接入到 Istio 里，成为在里面可以工作的 Sidecar。我主要做的几个功能是pilot-agent 的适配以及一致性哈希负载均衡功能的开发。其实和做业务需求是类似的，首先要知道功能要达到什么目的，然后预演改动的地方，最后实践：fork 一份 MOSN、开发 …","date":1595498400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/mosn-istio-service-mesh/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"03b066886bc7e069eca5654ee35e4782","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-istio-service-mesh/","publishdate":"2020-07-23T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/mosn-istio-service-mesh/","summary":"Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。 本文根据7月22日晚 Service Mesh Webinar#2 有米科技高级后端","tags":["Service Mesh","MOSN"],"title":"基于 MOSN 和 Istio Service Mesh 的服务治理实践","type":"blog","url":"/sofastack.tech/blog/mosn-istio-service-mesh/","wordcount":4565},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@古月 提问：\n 请问 SOFARPC 可以在 Spring MVC 环境 XML 配置使用?老项目 ssm，非 Spring Boot 环境。\n A：可以的。和直接用 SOFARPC 没区别。 SOFARPC 相关 Demo：https://www.sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@伍月 提问：\n 工程使用 OperatingSystemMXBean（osBean）类对系统 CPU 情况进行监控。 osBean.getSystemCpuLoad() = -1 ？？？ osBean.getProcessCpuLoad() = -1 ？？？ 有没有人知道是怎么回事。 注：正常情况下 CPU 返回值在 0 到 1 之间。\n A：抛出异常的时候会返回 -1，之前记得 arthas 也会返回 -1。\n 感谢回答。 工程在 Linux 服务器上运行时获取 CPU 数据正常。只是在本地 Windows 上运行时获取 CPU 数据返回 -1。后来百度得知可能由于本地 Windows 用户没有获取系统 CPU 数据的权限。\n Seata：https://github.com/seata/seata\n本周推荐阅读 我们需要什么样的端到端 AI 系统？蚂蚁 SQLFlow 的思考与答案 火了 2 年的服务网格究竟给微服务带来了什么？ Kubernetes: 微内核的分布式操作系统 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.7.4版本，主要变更如下：\n 允许用户设置 Triple 服务的版本； protobuf 编译器升级到 0.0.2； hibernate-validator 升级到 5.3.5.Final； jackson-databind 升级到 2.9.10.5； 修复了 Hessian over triple 不支持基本类型的问题； 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.4\n2、发布 Seata v1.3.0 版本，主要变更如下：\n AT 模式支持了像多主键，自动升降级，redis 存储等大量 feature； TCC 模式支持了模式支持 Dubbo 和 SOFARPC 注解调用； Saga 模式支持 Groovy 脚本任务、支持 jackson 序列化、代码重构将内部扩展点 SPI 化； 整体性能得到大幅度提升，修复了旧版本的存量 bug； 本次 release 变动文件数：442，代码变动：+17062 −8419，参与代码 commit 人数：31，合并 PR 数：90，其中：feature：20，bugfix：29，代码优化重构：41； 详细发布报告：https://github.com/seata/seata/releases/tag/v1.3.0\n社区活动报名 Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#2，邀请有米科技高级后端工程师姚昌宇，带来分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。本期分享可以收获对 Service Mesh 技术以及如何落地有更多的认识。\n分享主题：基于 MOSN 和 Istio Service Mesh 的服务治理实践\n分享嘉宾：姚昌宇 有米科技高级后端工程师、MOSN committer\n你将收获：\n 了解如何参与到 MOSN 开源社区共建中； 了解如何使用 MOSN 在 Istio 场景下的服务治理实践 ; 了解 MOSN 新版本的功能以及未来远景； 结合 Istio 各个场景的 Demo，分享 MSON 的多协议/私有协议实现； 直播时间：2020-07-22 20:00-21:00\n直播间地址：关注直播间，7月22日不见不散\n","date":1594969200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200717/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"54ea1b69911fe82c9674739a421a0ce5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200717/","publishdate":"2020-07-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200717/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC、Seata 组件发布以及社区 QA 整理、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200717/","wordcount":1475},{"author":"沈凋墨","categories":"Kubernetes","content":" 如今，Kubernetes 已经成为分布式集群管理系统和公有云/私有云的事实标准。实际上，Kubernetes 是一个分布式操作系统，它是 Google 在分布式操作系统领域十余年工程经验和智慧的结晶，而 Google 一直以来都管理着世界上最大的分布式集群，在分布式操作系统领域的研究和认识领先于全世界。因此，2014年发布的 Kubernetes 能在短短几年时间内就超越了诸多前辈，大获成功。\n作为分布式操作系统，Kubernetes（包括其前代产品 Google Borg）的出现远远晚于 UNIX、Linux、Windows 等著名的单机操作系统，Kubernetes 架构设计自然地继承了很多单机操作系统的珍贵遗产，微内核架构就是这些遗产中最重要的一份。在本文接下来的部分，我们将专注于微内核（microkernel）这个概念及其对 Kubernetes 架构的影响。\n什么是微内核？ 在介绍微内核的时候，我们有必要同时回顾一下单机操作系统的历史，以理解其价值所在。本章中以「操作系统」指代「单机操作系统」。\nUNIX 的兴起 电子计算机诞生之后，在上个世纪70年代以前，出现过许许多多的操作系统，DOS、OS/360、Multics 是其中的知名代表，这是操作系统领域的拓荒时代。20年来的拓荒孕育出了伟大的成果：随着 CPU 技术的发展，UNIX 于1969年诞生了，这是一个真正意义上的分时操作系统。\n图片来源：维基百科\n借助新的 CPU 技术的支持，UNIX 将软件系统划分为内核（kernel）和用户态程序（userland programs）两部分。内核是一组中断处理程序的集合，把硬件的能力封装为操作系统功能调用（system calls），用户态程序通过系统调用使用硬件功能，用户态程序运行于各自的进程中，所有用户态进程都共享同一个内核，每当系统调用或中断发生，UNIX 便陷入（trap）内核，内核执行系统调用，与此同时，内核中的分时调度算法将决定把 CPU 交给哪个进程，并管理进程的上下文切换。另外，UNIX 把（几乎）所有硬件都封装为文件。UNIX 还提供了一个特殊的用户态程序 shell，供用户直接使用系统，通过内核提供的进程间通信能力，shell让 用户可以把一系列应用程序组合起来，处理复杂的需求，作者称这个设计思想为「KISS」（Keep It Simple and Stupld）。UNIX 的所有设计思想在当时是都是非常了不起的创举。\nUNIX 不但自身对业界产生了巨大的直接贡献，还成为所有现代操作系统的蓝本，两位作者 Ken Tompson 和 Dennis Ritchie 因此荣获1983年度的图灵奖。\nUNIX 诞生于贝尔实验室，该实验室属于美国国家电信电报公司（AT\u0026amp;amp;T），见识到 UNIX 的强大威力之后，AT\u0026amp;amp;T 做出了一个看似无私的决定：将 UNIX 开源（初期只对大学开源），这使得所有现代操作系统得以诞生。虽然 AT\u0026amp;amp;T 最终被分拆，辉煌不再，但这个决定对人们的贡献绵延至今。在21世纪20年代的今天，无论是 MacOS、Windows、Linux，都直接受到 UNIX 的影响，而 iOS 来自 MacOS，Android 来自 Linux，因此 UNIX 的灵魂仍然活在每个人的手机中、活在每个手机 App 后台的服务中。\n此外，UNIX 诞生之时，还附送了一项比操作系统本身价值更大的副产品：Dennis Ritchie 为开发 UNIX 设计了C语言，C语言成为了所有流行的现代编程语言的主要设计来源，不仅如此，C语言在其诞生近40年后的今天，仍然是最重要的编程语言之一。\n值得一提的是，当时 UNIX 的主要开放对象是伯克利、卡内基梅隆等研究型大学，文理学院规模较小，没有研究生项目，不属于 AT\u0026amp;amp;T 的主要开放目标，因此 Olivet College 毕业的一位小哥未受到 UNIX 思潮的影响。这位名叫 David Cutler 的软件天才于1975年在 DEC 设计了 VMS 操作系统，VMS 和最初的 UNIX 一样，运行在 PDP-11 上，但并不是基于 UNIX，而是独立设计的。VMS 在业界没有掀起大浪，以兼容 UNIX 告终。后来 David Cutler 离开 DEC，加入微软，在那里谱写了属于他自己的传奇。有趣的是，乔布斯也曾在文理学院就读，看来美国文理学院的学生是不走寻常路的。\n微内核的兴起 UNIX「一切皆文件」的设计带来了用户程序设计的很多便利，但它要求所有对硬件的封装都要在内核态，因此内核中模块的 bug 会让整个系统受到影响，比如说，如果某个设备驱动有内存泄漏，所有使用该设备的用户态进程都会有内存泄漏，如果某个内核模块有安全漏洞，整个系统的安全性将不再可控。\n为了解决这类问题，上个世纪70年代，操作系统研究者们开始发展「微内核」的概念，微内核的本质是让操作系统的内核态只保留内存地址管理、线程管理和进程间通讯（IPC）这些基本功能，而把其它功能如文件系统、设备驱动、网络协议栈、GUI 系统等都作为单独的服务，这类服务一般是单独的用户态 daemon 进程。\n用户态应用程序通过 IPC 访问这些服务，从而访问操作系统的全部功能，如此一来，需要陷入内核的系统调用数量将大大减少，系统的模块化更加清晰。同时系统更加健壮，只有内核中的少量系统调用才有权限访问硬件的全部能力，如设备驱动的问题只会影响对应服务，而不是影响整个系统。和 micro kernel 相对，UNIX 的设计被称为 monolithic kernel。\nUNIX 开放后，AT\u0026amp;amp;T 继续着版本迭代，而各大学基于 AT\u0026amp;amp;T 的 UNIX 开发了很多新的操作系统内核，其中较为知名的有：\n BSD，monolithic，由伯克利的传奇人物 Bill Joy 于1974年发布（据说 Bill Joy 花三天便完成了 BSD 内核的第一个版本开发，Bill Joy 的作品还包含第一个 TCP/IP 协议栈、vi、Solaris、SPARK 芯片等等）。该内核对业界影响非常之大，后来发展为 FreeBSD、OpenBSD、NetBSD 等分支。现代操作系统如 Solaris、MacOS X、Windows NT 对其多有借鉴。 Mach，微内核，由卡内基梅隆大学于1984年发布，主要作者是 CMU 的两位研究生 Avie Tevanian 和 Rick Rashid。该内核对业界影响也很大，GNU Hurd、MacOS X 对其多有借鉴，但该项目本身以失败告终。 MINIX，微内核，由阿姆斯特丹自由大学（Vrije Universiteit Amsterdam）的 Andrew Tanenbaum 教授于1987年发布。无数计算机系学生通过 MINIX 及其配套教材掌握了操作系统的设计原理，Linux 的初始版本就是基于 MINIX 复刻的。MINIX 虽然著名，但主要用于教学，从未在工业界获得一席之地。 微内核的沉寂 从上世纪90年代至本世纪10年代，UNIX 和 VMS 的后裔们展开了一场混战，从结果来看，微内核的概念虽然美好，但现实非常 …","date":1594882800,"description":"本文将专注于微内核（microkernel）这个概念及其对 Kubernetes 架构的影响分享。","dir":"blog/microkernel-distributed-operating-system-kubernetes/","fuzzywordcount":7100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9fc5956b0fc0551dfdcf50df35ee8a84","permalink":"https://sofastack.github.io/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","publishdate":"2020-07-16T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","summary":"如今，Kubernetes 已经成为分布式集群管理系统和公有云/私有云的事实标准。实际上，Kubernetes 是一个分布式操作系统，它是 Google 在分","tags":["Kubernetes"],"title":"Kubernetes: 微内核的分布式操作系统","type":"blog","url":"/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","wordcount":7097},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践\n 活动时间：7 月 22 日周四晚 8 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 Service Mesh Webinar Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#2 Service Mesh Webinar#2，邀请有米科技高级后端工程师姚昌宇，带来分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。\n本期嘉宾将为大家分享从关注 ServiceMesher 社区，到参与 MOSN 开源共建的心路历程，包括 Service Mesh 技术的相关介绍、如何参与社区共建以及如何将 MOSN 结合 Istio 根据实际场景落地的示范。本期分享可以使你对 Service Mesh 技术，以及如何落地有更多的认识。\n分享主题：\n《基于 MOSN 和 Istio Service Mesh 的服务治理实践》\n分享嘉宾：\n姚昌宇 有米科技高级后端工程师、MOSN committer。多年后端开发经验、云原生爱好者。目前负责公司内部数据和算法能力接口的服务治理相关的开发工作，2018年起关注并参与 ServiceMesher 社区发起的各种活动，近期参与 MOSN v0.14.0 版本功能的开发。\n直播时间：2020年5月28日（周四）20:00-21:00\n大纲：\n Service Mesh 带来的红利 参与 MOSN 开源共建给我带来的收获 如何参与 MOSN 开源共建 找到组织：进入 MOSN 开发者群 熟悉 MOSN \u0026amp;amp; 搭建本地调试环境：现场演示（http、grpc 服务流量控制演示，指标收集，请求跟踪演示） 发现优化点/参与 Roadmap 感悟总结，以及 MOSN 近况\u0026amp;amp;未来远景介绍 用户收获：\n 了解如何参与到 MOSN 开源社区共建中； 了解如何使用 MOSN 在 Istio 场景下的服务治理实践 ; 了解 MOSN 新版本的功能以及未来远景； 结合 Istio 各个场景的 Demo，分享 MSON 的多协议/私有协议实现； ","date":1594710000,"description":"7 月 22 日周四晚 8 点，Service Mesh Webinar#2 线上直播。","dir":"activities/service-mesh-webinar-2/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"856529bdb9666c8bad4c59a80444662f","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-webinar-2/","publishdate":"2020-07-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-webinar-2/","summary":"概要 活动主题：Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践 活动时间：7 月 22 日周四晚 8 点 活动形式：线上直播 报名方式：戳这里","tags":["MOSN","Service Mesh Webinar"],"title":"Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践","type":"activities","url":"/sofastack.tech/activities/service-mesh-webinar-2/","wordcount":657},{"author":"罗广明","categories":"Service Mesh","content":" 本文节选自 ServiceMesher 社区出品的开源电子书《Istio Handbook——Istio 服务网格进阶实战》，作者罗广明，来自百度。\n 在过去几年中，微服务成为了业界技术热点，大量的互联网公司都在使用微服务架构，也有很多传统企业开始实践互联网技术转型，基本上也是以微服务和容器为核心。本文将主要介绍微服务架构的概述以及云原生环境下的 Service Mesh 和传统微服务应用的区别。\n微服务架构概述 微服务架构可谓是当前软件开发领域的技术热点，在各种博客、社交媒体和会议演讲上的出镜率非常之高，无论是做基础架构还是做业务系统的工程师，对微服务都相当关注，而这个现象与热度到目前为止，已经持续了近 5 年之久。\n尤其是近些年来，微服务架构逐渐发展成熟，从最初的星星之火到现在的大规模落地与实践，几乎已经成为分布式环境下的首选架构。微服务成为时下技术热点，大量互联网公司都在做微服务架构的落地和推广。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。\n而在这个技术转型中，国内有一个趋势，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。然而软件开发没有银弹，基于这些传统微服务框架构建的应用系统在享受其优势的同时，痛点也越加明显。这些痛点包括但不限于以下几点：\n 侵入性强。想要集成 SDK 的能力，除了需要添加相关依赖，往往还需要在业务代码中增加一部分的代码、或注解、或配置；业务代码与治理层代码界限不清晰。 升级成本高。每次升级都需要业务应用修改 SDK 版本，重新进行功能回归测试，并且对每一台机器进行部署上线，而这对于业务方来说，与业务的快速迭代开发是有冲突的，大多不愿意停下来做这些与业务目标不太相关的事情。 版本碎片化严重。由于升级成本高，而中间件却不会停止向前发展的步伐，久而久之，就会导致线上不同服务引用的 SDK 版本不统一、能力参差不齐，造成很难统一治理。 中间件演变困难。由于版本碎片化严重，导致中间件向前演进的过程中就需要在代码中兼容各种各样的老版本逻辑，带着 “枷锁” 前行，无法实现快速迭代。 内容多、门槛高。Spring Cloud 被称为微服务治理的全家桶，包含大大小小几十个组件，内容相当之多，往往需要几年时间去熟悉其中的关键组件。而要想使用 Spring Cloud 作为完整的治理框架，则需要深入了解其中原理与实现，否则遇到问题还是很难定位。 治理功能不全。不同于 RPC 框架，Spring Cloud 作为治理全家桶的典型，也不是万能的，诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。而这些功能往往是企业大规模落地不可获缺的功能，因此公司往往还需要投入其它人力进行相关功能的自研或者调研其它组件作为补充。 以上列出了传统微服务框架的局限性，但这并不意味着它们就一无是处了。在中小企业，采用 Spring Cloud 这样的传统微服务框架已经可以满足绝大部分服务治理的需求，并且借此快速推进微服务化改造。这些痛点往往是技术发展到一定的程度必然要经历的阶段，这些痛点促使技术不断发展、不断前进。\n在众多热门技术趋势中，云原生的关注度居高不下，很多开发者都对由此兴起的一众技术十分追捧，众多企业又开始探索云原生架构的转型与落地。这一年，中国的开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变。而 Service Mesh 技术也因此越来越火热，受到越来越多开发者的关注，并拥有了大批拥趸。那么 Service Mesh 是什么呢？它为什么会受到开发者的关注？它和传统微服务应用有什么区别？\nService Mesh 定义 Service Mesh 一词最早由开发 Linkerd 的 Buoyant 公司提出，并于 2016 年 9 月29 日第一次公开使用了这一术语。William Morgan，Buoyant CEO，对 Service Mesh 这一概念定义如下：\n A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.\n 翻译成中文如下：\nService Mesh 是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。\n以上这段话有四个关键点：\n 本质：基础设施层； 功能：请求分发； 部署形式：网络代理； 特点：透明； 2017 年，随着 Linkerd 的传入，Service Mesh 进入国内社区的视野，并且由国内的技术布道师们翻译成“服务网格”。\n服务网格概述 服务网格从总体架构上来讲比较简单，不过是一堆紧挨着各项服务的用户代理，外加一组任务管理流程组成。代理在服务网格中被称为数据层或数据平面（data plane），管理流程被称为控制层或控制平面（control plane）。数据层截获不同服务之间的调用并对其进行“处理”；控制层协调代理的行为，并为运维人员提供 API，用来操控和测量整个网络。\n更进一步地说，服务网格是一个专用的基础设施层，旨在“在微服务架构中实现可靠、快速和安全的服务间调用”。它不是一个“服务”的网格，而是一个“代理”的网格，服务可以插入这个代理，从而使网络抽象化。在典型的服务网格中，这些代理作为一个 sidecar（边车）被注入到每个服务部署中。服务不直接通过网络调用服务，而是调用它们本地的 sidecar 代理，而 sidecar 代理又代表服务管理请求，从而封装了服务间通信的复杂性。相互连接的 sidecar 代理集实现了所谓的数据平面，这与用于配置代理和收集指标的服务网格组件（控制平面）形成对比。\n总而言之，Service Mesh 的基础设施层主要分为两部分：控制平面与数据平面。当前流行的两款开源服务网格 Istio 和 Linkerd 实际上都是这种构造。\n控制平面的特点：\n 不直接解析数据包。 与控制平面中的代理通信，下发策略和配置。 负责网络行为的可视化。 通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。 数据平面的特点：\n 通常是按照无状态目标设计的，但实际上为了提高流量转发性能， …","date":1594710000,"description":"本文将主要介绍微服务架构的概述以及云原生环境下的 Service Mesh 和传统微服务应用的区别。","dir":"blog/microservices-service-mesh/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f6d713862b049df801c82f5c52ec6ed1","permalink":"https://sofastack.github.io/sofastack.tech/blog/microservices-service-mesh/","publishdate":"2020-07-14T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/microservices-service-mesh/","summary":"本文节选自 ServiceMesher 社区出品的开源电子书《Istio Handbook——Istio 服务网格进阶实战》，作者罗广明，来自百度。 在过去几年中，微服务成为","tags":["Service Mesh"],"title":"火了 2 年的服务网格究竟给微服务带来了什么？","type":"blog","url":"/sofastack.tech/blog/microservices-service-mesh/","wordcount":5219},{"author":"SOFA 团队","categories":"SQLFlow","content":" 端到端机器学习是一种由输入端的数据直接得到输出端结果的AI系统，它可以对业务人员屏蔽复杂技术细节，同时给模型以更多自动调节空间，增加模型整体契合度。近两年来，端到端机器学习成为 AI 领域研发热点，蚂蚁集团于2019年5月发布端到端 AI 系统 SQLFlow 开源项目，受到业界广泛关注。今天，就让我们来看看它对端到端 AI 的思考与解答。\n SQLFlow 是蚂蚁集团开源的使用 SQL 完成 AI 工作流构建的编译系统。SQLFlow 将多种数据库系统（MySQL, Hive, MaxCompute）和多种机器学习引擎（Tensorflow, Keras, XGBoost）连接起来，将 SQL 程序编译成可以分布式执行的工作流，完成从数据的抽取，预处理，模型训练，评估，预测，模型解释，运筹规划等工作流的构建。\n接下来我们会根据以下内容逐步介绍 SQLFlow：\n 为什么要使用 SQL 语言描述端到端 AI 任务； 使用 SQLFlow SQL 语句构建 AI 任务； 使用 SQL 程序构建端到端 AI 工作流； 使用 SQLFlow Model Zoo 沉淀模型； 应用 SQLFlow 的场景案例； 为什么要使用 SQL 语言描述端到端 AI 任务 首先，思考一个问题，人工智能和金融有哪些耳熟能详的结合呢？  在智能征信风控方向，可以运用大数据进行机器学习，刻画用户画像，抽取个性化典型特征，推进反欺诈评估、用户征信评估。 用到的技术：聚类（将有相似特征的群体聚类，确定人群标签）、分类（学习已有分类标签的用户特征，识别新用户所属的类型、标签）、模型解释\n 在智能投资顾问方向，我们以人工智能算法为基础，为客户提供自动化投资管理解决方案，包括提供投资资讯、构建投资组合、直接投资管理等服务。 用到的技术：时序模型、回归、运筹规划\n 智能营销方向，上世纪90年代沃尔玛超市将「啤酒」与「尿布」摆在同一区域的做法，大大增加了商品销售收入，成为借助数据分析实现智能营销的经典案例。而今天，在人工智能等新技术的加持下，数据分析技术正在不断进化，千人千面的智能营销已有广泛的应用。 用到的技术：推荐算法、Ranking、CTR、运筹规划\n然而，构建传统的机器学习工作流程，需要经历非常多的步骤并使用复杂的技术栈： 构建完整的 AI 应用，首先需要获取用于构建模型的数据，这些数据通常可以从日志、订单数据、交易记录等获得。之后通过数据抽取，将其中我们需要用到的部分信息，从多个存储位置抽取出来。抽取数据之后需要进行数据预处理，比如去掉错误的数据，填充缺失的数据，整理，排序等。预处理完成之后，我们需要从这部分数据中得到用于训练模型的特征，比如提取时间序列的周期性特征，获取交叉特征等，最后将构建的特征转换成训练框架可以接收的数据格式，才能开始训练。 另外，在开始训练之前，我们还需要确定使用哪个模型，XGBoost 模型还是深度学习模型，哪个模型更适合当前的场景？模型可以从现有模型库中获取并根据需要修改，或者从头编写新的模型使用。另外在构建机器学习模型时，我们需要不断的评估模型的表现如何，以获得最优的模型，这时就要使用各种评价指标描述训练好的模型。当模型评估结果验证达标之后，就需要将模型代码发布一个新的版本，部署到线上环境。发布之前还要通过线下测试，小流量 ABTest，然后推全部署。如果是离线任务则需要更新定时任务使用新的模型代码。\n当模型的时效性比较强的时候，我们还需要不断的使用新的数据更新模型，就是“增量训练“，这样每次增量训练就不得不再次从头走一次完整的流程。\n要完成这一整套流程，需要用到复杂的技术栈。\n我们需要的数据可能存储在磁盘，或者像 HDFS 这样的分布式文件系统，或者可以从结构化的数据库系统中获得，或者是 NoSQL 引擎（比如 mongodb）存储的数据；在预处理阶段，有可能需要编写 MapReduce Job 来处理 HDFS 上的大量的数据，或者使用 Hive 编写 SQL 语句完成处理，亦或直接编写 Python 代码处理数据；在特征工程阶段，又需要使用类似 statsmodels, tsfresh 或者编写 Python 程序使用诸如 Pandas 之类的库完成预处理；在模型训练阶段，算法工程师首先需要掌握各种建模的能力，算法原理和基础知识，也需要熟练使用各种机器学习引擎如 sklearn, XGBoost, Tensorflow, Pytorch 等；最后在上线部署阶段，还需要了解模型如何接入 Serving 系统，怎么样做 ABTest，怎么编写 CI/CD 任务保证模型上线不影响线上业务。\n构建 AI 应用，不仅需要冗长的链路和复杂的技术，从业务需求到 AI 系统上线也需要特别长的沟通链路。\n比如业务同学和产品同学在构建产品思路的时候，在他的脑海中的 AI 系统需要完成的任务，传达给开发同学之后，有可能传达不到位，需要反复的沟通。有时甚至做了一半还需要重做。\n另外从需求到上线，为了保证线上服务和数据产出的稳定，也需要通过许多的步骤。比如业务同学说：「活动要上线了，时间点很关键，明天必须发布！」开发同学接到需求，加班加点，开发验证完成之后，模型准确率提升10个点，准备发布模型。SRE 同学则会把控上线之前的各项准备，包括预发测试是否通过，压力测试是否通过，CPU 负载是否有提升，硬件资源是否能承载新的模型，模型预测延迟是否提升了等……完成流程也需要很长时间。然而如果没有 SRE 的把关，线上的服务很难保证稳定性。\n使用 SQL 作为描述和构建 AI 任务的语言，可以降低构建 AI 应用的门槛，提升效率。\n首先需要区分编程语言主要的两种描述方法：描述意图和描述过程。简而言之，描述意图是在描述「做什么」，描述过程是描述「怎么做」。比如，夏天大家有空喜欢吃点烧烤喝点啤酒，描述意图的方式，说「我想去撸串」这一句就够了。而描述过程，就需要说「我今天晚上下班后，叫上老王小李，去公司楼下的烧烤店，点100个串和10个啤酒，最后用支付宝扫码付款」。可以看到描述意图可以非常简洁，而具体的执行方案，可以根据意图中构建得出。这点也是 SQL 不同于其他语言的关键点。\n在描述模型训练任务时，使用 SQLFlow SQL 只需要编写 SELECT * FROM iris.train TO TRAIN DNNClassifier LABEL class INTO my_dnn_model; 即可，如果使用 Python 完成相同的任务则需要编写如下图这样的较长的代码。\nSQL 语言除了有非常简洁的优势之外，在数据科学领域，SQL 语言的已有用户量大，并且在不断的增加。这里也有两个统计图，统计了数据科学类任务所使用的工具的流行程度和增长趋势。SQL 语言流行程度排名第三，增量排在第四名。数据科学领域正在更多的使用 SQL 是我们希望使用 SQL 语言描述 AI 任务的原因。除了在表达能力上 SQL 语言有非常简洁的优势之外，在蚂蚁内 MaxCompute 被广泛使用也是我们选择 SQL 的一个原因。\n如何使用 SQLFlow SQL 语句构建 AI 任务 SQLFlow 是一个开源项目， …","date":1594623600,"description":"近两年来，端到端机器学习成为 AI 领域研发热点，蚂蚁集团于2019年5月发布端到端 AI 系统 SQLFlow 开源项目，受到业界广泛关注。今天，就让我们来看看它对端到端 AI 的思考与解答。","dir":"blog/end-to-end-ai-system-sqlflow/","fuzzywordcount":6700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"667a8ff160a9c7f54a5ceba7c20b7437","permalink":"https://sofastack.github.io/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","publishdate":"2020-07-13T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","summary":"端到端机器学习是一种由输入端的数据直接得到输出端结果的AI系统，它可以对业务人员屏蔽复杂技术细节，同时给模型以更多自动调节空间，增加模型整体","tags":["SQLFlow"],"title":"我们需要什么样的端到端 AI 系统？蚂蚁 SQLFlow 的思考与答案","type":"blog","url":"/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","wordcount":6621},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网:https://www.sofastack.tech SOFAStack:https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@郝连帅 提问： \u0026amp;gt; 如果回滚失败有没有告警机制实现？比如钉钉告警。\nA：可以的，实现 FailureHandler 接口。\n本周推荐阅读 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.3，主要变更如下：\n RheaKV 允许不同分片各自配置不同的 learner 节点； 在只有一个成员变更的情况下，仍然使用 raft 联合一致性算法； 替换基于 GPL-2.0 licence 的 Bits.java； 升级 jackson.databind 版本到 2.10.4 已修复安全漏洞； 修复在 node panic 后可能因为未及时刷盘导致快照元数据丢失的 bug； 致谢（排名不分先后）：@zongtanghu\n此版本强烈建议升级 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.3\n社区活动报名 CNCF 的旗舰会议聚集了全球领先开源社区和云原生社区的使用者和技术大咖参加线上峰会。相约 2020 年 7 月 30 日 - 8 月 1 日三天的线上峰会，共同探讨云原生计算的未来和方向。蚂蚁集团也受邀进行两个云原生主题分享。\n分享主题：在大规模 Kubernetes 集群上实现高 SLO 的方法\n 分享嘉宾：霜林 蚂蚁集团技术专家、散樗 蚂蚁集团高级开发工程师 议题介绍：随着 Kubernetes 集群的规模和复杂性的增加，集群越来越难以提供高成功率和低延迟的合格 pod。在本次演讲中，蚂蚁集团的工程师将分享他们在设计 SLO架构和实现高服务水平目标的方法的经验。他们将引入适当的指标，首先衡量 Kubernetes 集群是否健康。然后，他们将解释如何设计和实现跟踪和分析平台，以收集有效的度量和计算这些指标。有了跟踪分析平台，pod 提供过程中出现的问题可以很容易的被诊断出来。最后，他们将展示如何沉淀人工体验到自我修复系统，以自动修复已知的问题。 分享时间：2020-07-30 20:10-20:40 报名方式：点击“这里”，即可报名 分享主题：为 Kubernetes 的秘密披上无形的盾牌\n 分享嘉宾：柯粟 蚂蚁集团高级开发工程师 议题介绍：K8s 的秘密广泛应用于生产中，用于对敏感信息进行存储管理。与 KMS 的集成，甚至与基于硬件的插件，确实增强了保护，但还远远不够，特别是对于财务级的安全需求。由于缺乏端到端的秘密加固解决方案，攻击面在很大程度上在 K8s 集群中其他关键元素/流的威胁中仍然不受保护。通过聚合可信执行环境（TEE）和增强的身份验证，本讲座探索在使用、静止和传输中保护 K8s 秘密的答案。对 kubectl、K8S主节点和节点进行了更改，以保证可用性和机密性。TEE 对开发人员和用户的透明性将通过一个演示进行阐述和演示。最后，将分享在蚂蚁集团的实践经验和 KEP 给社区。 分享时间：2020-07-31 20:10-20:40 报名方式：点击“这里”，即可报名 ","date":1594364400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200710/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"304a9dc50d507f12e1b562491d6b5546","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200710/","publishdate":"2020-07-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200710/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布、CNCF 旗舰会议活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200710/","wordcount":1362},{"author":"尹博学","categories":"分布式架构","content":" 过去几年是云原生理念高速普及的黄金时期。微服务、容器、无服务器架构、服务网格等新技术的出现，在技术社区中激起了一浪又一浪的创新热潮。然而由于金融行业对性能和安全的严苛要求，云原生技术在企业实际场景中的实施落地，特别是在金融场景的实施落地，仍然面临诸多挑战。\n本文整理自2020阿里云线上峰会蚂蚁集团资深技术专家尹博学的主题演讲，为大家分享蚂蚁关于金融级 IT 架构及分布式架构的思考和应用实践。关注本网站，蚂蚁 SOFAStack 白皮书即将发布，不要错过哦～\n 以下为演讲整理全文：\n大家好，我是蚂蚁集团的尹博学，今天和大家分享一下蚂蚁关于金融级 IT 架构及分布式架构的一些思考和应用案例，主要包含三个部分，分别是行业常见的分布式架构介绍、蚂蚁单元化架构的介绍以及单元化架构的应用案例。\n行业常见分布式架构 行业常见的分布式架构主要包含，单活架构、双活架构和冷备架构。从容灾能力角度来看，双活架构和冷备架构均能做到应用级跨机房容灾，但是数据库因为使用了异步复制的技术，无法做到机房级 RPU=0 的容灾。再看灰度发布的能力，冷备架构和双活架构都只能做到机房级灰度发布，无法做到更细粒度的灰度发布。\n蚂蚁集团单元化架构介绍 在介绍完行业常见的分布式架构后，我们来看一下蚂蚁的分布式架构发展历程，和单元化架构的详细介绍。\n这是蚂蚁分布式架构发展历程。蚂蚁也经历了单活、同城双活、两地三中心三个阶段。其中两地三中心是同城双活加一个冷备。随着蚂蚁业务和业务量复杂度的越来越高，业务对于基础架构的要求也越来越高，即扩展能力、容灾能力、灰度能力要求越来越高。最终蚂蚁发展到了单元化架构，将主要业务拆分单元即分片，装入不同的逻辑单元内，每个分片的数据库实现三地五中心部署即三地五中心的单元化架构。\n首先我们来看一下蚂蚁单元化架构的整体架构设计，整体架构包含 RZone、GZone 和 CZone。其中 GZone 部署的是无法拆分的数据和业务，GZone 的数据和业务被 RZone 依赖，GZone 全局只部署一份，而 RZone 部署的是可拆分的业务和对应的数据。每个 RZone 内的数据分片如图所示有五副本，实现三地五中心部署，每个分片内只有一个可写入的主副本，其余副本按照 Paxos 协议做数据强一致。每个 RZone 内实现业务单元封闭，独立完成自己的所有业务。而 CZone 的出现是因为 GZone 全局只有一份，不同城市的 RZone 可能依赖 GZone 服务和数据的时候需要远距离调用，延迟比较大，所以在每个城市部署一个 CZone 作为 GZone 的只读副本，为本城市的 RZone 提供服务。\n介绍完单元化架构的整体设计之后，我们从容灾、灰度发布、弹性三个方面详细看一下该架构的能力。\n首先看容灾能力，容灾能力分为同城容灾和异地容灾，以图中所示为例，RZone1 出现故障先看同城容灾能力，我们目标将 RZone1 切换至同城容灾 RZone2。先做数据库分片切换，RZone1 对应的分片为分片1，把分片1在 RZone2 的副本提升为主副本，数据库副本提升完毕后将 RZone1 的流量切换至 RZone2，实现同城容灾 RPO=0、RTO\u0026amp;lt;1min。\n再看异地容灾，同样以 RZone1 故障为例。目标切换至 RZone3，先做数据库切换，分片1在 RZone3 的副本切换成主副本，完成后将 RZone1 的流量切换至 RZone3，实现异地容灾，该过程 RPO=0、RTO\u0026amp;lt;1min。\n接下来我们看弹性。弹性的背景是业务在大促、节假日等流量出现大幅上涨的过程，我们可以短期租借新的城市和新的 IDC。如图所示，我们租借城市 X 的 IDCX 作为 RZoneX，将 RZone5 的部分流量弹出至 RZoneX，对应流量的数据也弹出至 RZoneX 内。在节假日大促结束之后，将 RZoneX 内的流量和数据弹回至 RZone5，然后回收 RZoneX，这样大幅节约了机房成本。\n介绍完弹性之后，我们来看灰度能力。如图所示，我们将四个 RZone（RZone1、RZone2、RZone3、RZone4）的业务和应用分为 A、B 组，日常 A 组和 B 组各承担50%的应用流量。在应用新版本发布时，我们将 A 组的流量全部切换至 B 组，此时在 A 组上部署新版本，部署完毕后将 B 组的流量按粒度切换至 A 组上，切换粒度等于数据分片的粒度。在切换的过程中可以做 A 组和 B 组的服务对比，如果发现 A 组的服务异常，可以快速将流量切换回 B 组。在 A 组服务一段时间后无异常发生，最终可以将 B 组的流量全部切换至 A 组，把 B 组的版本更新为新的版本，在整个切换的过程中实现了可灰度、可回滚、可监控。\n我们再深入到架构内部，来阐释一下架构内关键模块是如何支撑该架构的。\n首先我们看流量路由模块。流量路由模块的核心是将用户的 uid 信息和对应的 Zone 信息植入到 cookie 中，供流量路由模块做精准路由。我们以用户 uid=68、RZone=RZ03 为例来看流量路由模块是如何工作的，首次用户接入时 cookie 内无 Zone 信息，流量接入模块会随即将该请求发到一个 RZone 内，如发到 RZone1 内，RZone1 通过 zoneClinet 会准确计算该请求应发至 RZone3，即通过 RouteClinet 将该请求发送。发送过程中将计算出的 uid 信息和对应的 Zone 信息植入 cookie 内转发至 RZone3，RZone3 完成本次业务请求后将结果返回给用户，其后用户同意 session 内的其它请求，因为在 cookie 内已经有了准确的路由信息，会被流量路由模块准确的发至 RZone3 完成业务请求。\n接着我们再看一下服务路由，服务路由分为本机房服务路由和跨机房服务路由调用。先看本机房服务路由，服务调用端向本机房服务注册中心订阅服务，发现服务地址后做本机房服务路由调用。再看跨机房服务路由调用，服务调用端向其他 IDC 的注册中心订阅服务地址，发现服务地址后做跨机房服务调用。\n最后我们看数据是如何实现高可靠的。蚂蚁使用自研的分布式关系数据库 OceanBase，每个分片的数据库做5副本部署，部署地域实现三地五中心部署，5副本中有3副本实现强一致，如图所示可以实现同城、IDC 容灾和异地容灾。\n单元化架构实践场景 介绍完蚂蚁单元化架构的主要概念即关键模块信息之后，我们看一下单元化架构在外部客户实施的一些案例。\n第一个案例是一家城商行，它的业务系统、IT系统历史比较长，无法一步跨越到单元化架构，我们为其推荐了大 GZone 的模式，即把城商行的所有服务和数据不做拆分，直接装入一个 GZone 内，在 GZone 的基础上实现同城双活即应用同城双中心部署，数据库同城三中心部署，从而实现同城容灾能力，RPO=0、RTO\u0026amp;lt;1min，但无法实现异地容灾能力，其可灰度能力和弹性能力都无法做到更细力度。\n再看第二个区域银行的案例。我们为这家区域银行实现了同城单元化，即将这家区域银行的主要业务拆分成两个逻辑业务单元两个分片，将其装入一个城市的两个 IDC 内，在另外一个城市建设冷 …","date":1594278000,"description":"本文整理自2020阿里云线上峰会蚂蚁集团资深技术专家尹博学的主题演讲，为大家分享蚂蚁关于金融级 IT 架构及分布式架构的思考和应用实践。","dir":"blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dec27e85a58fcb573b33b9de6125bbc5","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","publishdate":"2020-07-09T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","summary":"过去几年是云原生理念高速普及的黄金时期。微服务、容器、无服务器架构、服务网格等新技术的出现，在技术社区中激起了一浪又一浪的创新热潮。然而由于","tags":["分布式架构"],"title":"支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构","type":"blog","url":"/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","wordcount":3642},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@guotaisu 提问：\n 根据 jraft-example, 使用“fake PD”, 怎样手动 rebalance。使用 PD 自管理体现在哪？\n A：手动 API： https://github.com/sofastack/sofa-jraft/blob/master/jraft-core/src/main/java/com/alipay/sofa/jraft/CliService.java#L190\nPD 目前只实现了 leader 平衡和自动分裂，支持很容易基于 SPI 扩展增加自己的逻辑(增加并实现自己的 com.alipay.sofa.jraft.rhea.util.pipeline.Handler 即可)，文档见：https://www.sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/\n regionEngineOptionsList 配置：实例中的 regionId 的 startKey：01000000-endKey：23000000 根据什么来定义的，假设我一个 store 节点只部署 1-3 个 region，可以自定义上下界是吗，依据什么来定义？\n A：rheakv multi group 按照 range 分片，左闭右开，可以自定义，怎么定义取决于你对自己场景 key 分布的评估。\n yaml 配置中 regionEngineOptionsList.RegionEngineOptions 中的 serverAddress、initialServerList 等配置和外部与 regionEngineOptionsList 平级的 serverAddress 配置以及与 storeEngineOptions 平级的 initialServerList 是什么关系，谁覆盖谁？\n A：store 和 region 为1：n， region 包含在 store 中，store 的参数会 copy 传递到 region。\n jraft-example 展示，Rhea-kv 是客户端+服务端模式，其中 benchmark 使用分片集群部署模式，需要先同时使用 BenchmarkClient、BenchmarkServer 拉启后台服务，而后面的 rheakv 使用分节点配置和启动，如何区分二者的场景和使用姿势。\n A：rheakv 可以作为 client+server 部署，也可以单独作为 client 部署，通常你不想在每个节点提供服务但是还需要调用服务，那么就只 client 部署即可（配置的区别就在于是否配置了 StoreEngineOptions）。\n 本人项目使用 SOFAJRaft 场景是分布式单体服务快速便捷存储业务元数据，实现一致性访问。请问后台需要拉取这么多服务如何还能保证我的应用轻量快捷？另外，这些后台 jraft-kv 选举和存储服务启动后，是独立进程吗，整合到自己到项目中后，可否一个进程并且其服务生命周期随同我的母体应用的生命周期。\n A：SOFAJRaft 是一个 jar 包，是不是独立进程完全取决于你自己的意愿，都可以。\n 参考 jraft-example 实例，基于 rheakv 部署 multi group，加减 learnner 节点等，应该是以分组为单位操作，目前只看到 NodeOptions 中有 groupId 属性，多组时怎么配置和分别操作。\n A：这应该是两个问题。 问题1（groupId 多组如何配置）：在 rheakv 里，groupId 是 clusterName + ‘-’ regionId。 问题2（多组如何配置 learner）：目前没有很灵活，我们内部使用还是单独指定几台机器，上面的节点全部是 learner 节点，只要配置 initialServerList: 127.0.0.1:8181,127.0.0.1:8182,127.0.0.1:8183/learner 即所有 group 的 learner 都在 127.0.0.1:8183/learner 一个节点上，你的需求收到了，下个版本会增加每个 region 单独指定 learner，需要修改 RegionEngineOptions.initialServerList 在不为空的时候不被 StoreEngineOptions 的值覆盖即可。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 网络通信框架 SOFABolt 功能介绍及协议框架解析 | SOFAChannel#17 直播回顾 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.14.0，主要变更如下：\n 支持 Istio 1.5.x 版本； 升级了一些依赖库，如 FastHTTP、Dubbo-go、Tars； 支持 Maglev 负载均衡、支持 HostRewrite Header； 新增了一些 Metrics 输出与查询接口； 部分实现优化与 Bug 修复； 详细发布报告：https://mosn.io/zh/blog/releases/v0.14.0/\n同时，恭喜姚昌宇（@trainyao）成为 MOSN Committer，感谢他为 MOSN 社区所做的贡献。\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题：云原生网络代理 MOSN 的进化之路 分享嘉宾：王发康（毅松）蚂蚁集团 可信原生技术部 技术专家 背景介绍：网络通信代理 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，增强 MOSN 服务治理及流量控制能力，对接云原生周边组件，实现 MOSN 开箱即用，MOSN …","date":1593759600,"description":"【06/29-07/03】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200703/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6f65c94a70fdd3d222fb510cbec05abf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200703/","publishdate":"2020-07-03T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200703/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 版本发布以及社区活动预告、SOFABolt 直播回顾整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200703/","wordcount":1989},{"author":"丞一","categories":"SOFAChannel","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 大家好，我是本期 SOFAChannel 的分享讲师丞一，来自蚂蚁集团，是 SOFABolt 的开源负责人。今天我们来聊一下蚂蚁集团开源的网络通信框架 SOFABolt 的框架解析以及功能介绍。本期分享将从以下四个方面展开：\n SOFABolt 简介； 基础通信能力解析； 协议框架解析； 私有协议实现解析； SOFABolt 是什么 SOFABolt 产生背景 相信大家都知道 SOFAStack，SOFAStack(Scalable Open Financial Architecture Stack)是一套用于快速构建金融级云原生架构的中间件，也是在金融场景里锤炼出来的最佳实践。\nSOFABolt 则是 SOFAStack 中的网络通信框架，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架，他的名字 Bolt 取自迪士尼动画《闪电狗》。他一开始是怎么在蚂蚁集团内部产生的，我们可以类比一下 Netty 的产生原因：\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生； 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生； 这些年，在微服务与消息中间件在网络通信上，蚂蚁集团解决过很多问题、积累了很多经验并持续进行着优化和完善，我们把总结的解决方案沉淀到 SOFABolt 这个基础组件里并反馈到开源社区，希望能够让更多使用网络通信的场景受益。目前该组件已经运用在了蚂蚁集团中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n同时，已有数家企业在生产环境中使用了 SOFABolt，感谢大家的肯定，也希望 SOFABolt 可以给更多的企业带来实践价值。\n以上企业信息根据企业用户 Github 上反馈统计 — 截止 2020.06。\nSOFABolt：https://github.com/sofastack/sofa-bolt\nSOFABolt 框架组成 SOFABolt 整体可以分为三个部分：\n 基础通信能力（基于 Netty 高效的网络 IO 与线程模型、连接管理、超时控制）； 协议框架（命令与命令处理器、编解码处理器）； 私有协议实现（私有 RPC 通信协议的实现）； 下面，我们分别介绍一下 SOFABolt 每个部分的具体能力。\n基础通信能力 基础通信模型 如上图所示，SOFABolt 有多种通信模型，分别为：oneway、sync、future、callback。下面，我们介绍一下每个通信模型以及他们的使用场景。\n oneway：不关注结果，即客户端发起调用后不关注服务端返回的结果，适用于发起调用的一方不需要拿到请求的处理结果，或者说请求或处理结果可以丢失的场景； sync：同步调用，调用线程会被阻塞，直到拿到响应结果或者超时，是最常用的方式，适用于发起调用方需要同步等待响应的场景； future：异步调用，调用线程不会被阻塞，通过 future 获取调用结果时才会被阻塞，适用于需要并发调用的场景，比如调用多个服务端并等待所有结果返回后执行特定逻辑的场景； callback：异步调用，调用线程不会被阻塞，调用结果在 callback 线程中被处理，适用于高并发要求的场景； oneway 调用的场景非常明确，当调用方不需要拿到调用结果的时候就可以使用这种模式，但是当需要处理调用结果的时候，选择使用同步的 sync 还是使用异步的 future 和 callback？都是异步调用，又如何在 future、callback 两种模式中选择？\n显然同步能做的事情异步也能做，但是异步调用会涉及到线程上下文的切换、异步线程池的设置等等，较为复杂。如果你的场景比较简单，比如整个流程就一个调用并处理结果，那么建议使用同步的方式处理；如果整个过程需要分几个步骤执行，可以拆分不同的步骤异步执行，给耗时的操作分配更多的资源来提升系统整体的吞吐。\n在 future 和 callback 的选择中，callback 是更彻底的异步调用，future 适用于需要协调多个异步调用的场景。比如需要调用多个服务，并且根据多个服务端响应结果执行逻辑时，可以采用 future 的模式给多个服务发送请求，在统一对所有的 future 进行处理完成协同操作。\n超时控制机制 在上一部分的通信模型中，除了 oneway 之后，其他三种（sync、future、callback）都需要进行超时控制，因为用户需要在预期的时间内拿到结果。超时控制简单来说就是在用户发起调用后，在预期的时间内如果没有拿到服务端响应的结果，那么这次调用就超时了，需要让用户感知到超时，避免一直阻塞调用线程或者 callback 永远得不到执行。\n在通信框架中，超时控制必须要满足高效、准确的要求，因为通信框架是分布式系统的基础组件，一旦通信框架出现性能问题，那么上层系统的性能显然是无法提升的。超时控制的准确性也非常重要，比如用户预期一次调用最多只能执行3秒，因为超时控制不准确导致用户调用时线程被阻塞了4秒，这显然是不能接受的。\nSOFABolt 的超时控制采用了 Netty 中的 HashedWheelTimer，其原理如上图。假设一次 tick 表示100毫秒，那么上面的时间轮 tick 一轮表示800毫秒，如果需要在300毫秒后触发超时，那么这个超时任务会被放到\u0026amp;rsquo;2\u0026amp;rsquo;的 bucket 中，等到 tick 到\u0026amp;rsquo;2\u0026amp;rsquo;时则被触发。如果一个超时任务需要在900毫秒后触发，那么它会被放到如\u0026amp;rsquo;0\u0026amp;rsquo;的 bucket 中，并标记 task 的 remainingRounds=1，当第一次 tick 到\u0026amp;rsquo;0\u0026amp;rsquo;时发现 remainingRounds 不等于0，会对 remainingRounds 进行减1操作，当第二次 tick 到\u0026amp;rsquo;0\u0026amp;rsquo;，发现这个任务的 remainingRounds 是0，则触发这个任务。\n如果将时间轮的一次 tick 设置为1秒，ticksPerWheel 设置为60，那么就是现实时钟的秒针，走完一圈代表一分钟。如果一个任务需要再1分15秒后执行，就是标记为秒针走一轮之后指向第15格时触发。关于时间轮的原理推荐阅读下面这篇论文： 《Hashed and Hierarchical Timing Wheels: data structures to efficiently implement a timer facility》。\n快速失败机制 超时控制机制可以保证客户端的调用在一个预期时间之后一定会拿到一个响应，无论这个响应是由服务端返回的真实响应，还是触发了超时。如果因为某些原因导致客户端的调用超时了，而服务端在超时之后实际将响 …","date":1593694800,"description":"开源网络通信框架 SOFABolt 首次线上直播文字回顾。","dir":"blog/sofa-channel-17-retrospect/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9f88cb52dccf190278f16c9eab448644","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-17-retrospect/","publishdate":"2020-07-02T21:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-17-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播","tags":["SOFAChannel","SOFABolt"],"title":"网络通信框架 SOFABolt 功能介绍及协议框架解析 | SOFAChannel#17 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-17-retrospect/","wordcount":5457},{"author":"敖小剑","categories":"微服务","content":" 最近社区频繁出现的对微服务的各种质疑和反思的声音，甚至放弃微服务回归单体。本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Event/EDA 来走出微服务实践误区：从单体到微服务，却最后沦为分布式单体。\n 回顾：从单体到微服务到 Function 在过去几年间，微服务架构成为业界主流，很多公司开始采用微服务，并迁移原有的单体应用迁移到微服务架构。从架构上，微服务和单体最大的变化在于微服务架构下应用的粒度被“拆小”：将所有业务逻辑都在一起的单体应用，按照领域模型拆分为多个内聚而自治的“更小”的应用。而 Function 则在拆分上更进一步，拆分粒度变成了“单个操作”，基于 Function 逐渐演进出现 FaaS 形态和 Serverless 架构。\n在微服务和 Serverless 的喧嚣中，也逐渐出现了很多质疑和反对的声音：越来越多的人发现，当他们兴冲冲的迁移单体应用到微服务和 Serverless 架构之后，得到的收益并没有期望中的那么理想。最近，出现了对微服务的各种质疑、反思的声音，甚至放弃微服务回归单体。举例，我在 InfoQ 中国网站 简单搜索关键字“微服务”，前三页中就出现了如下的内容：\n 我们为什么停用微服务？ 这些公司为什么放弃微服务？ 什么？你的团队没有100人，那就不要用微服务了！ 致传统企业朋友：不够痛就别微服务，有坑 微服务带来的心理阴影 微服务到底该多大？如何设计微服务的粒度？ Uber 团队放弃微服务改用宏服务，网友评论炸锅了 为什么 Segment 从微服务回归单体 无论是支持还是反对微服务的声音，大多都是着眼于组织架构（康威定律，对应用和代码的 ownership）、微服务拆分（粒度大小，如何识别领域模型和业务边界）、分布式事务（跨多个微服务调用时维持一致性），工具（自动化构建、部署，可测试性，监控，分布式链路跟踪，CI/CD），数据库分离（避免多个微服务尤其是领域模型外的微服务共享数据库）等方面进行合理性分析和观点阐述，相信大家都对这些问题都有了解。\n而我今天的文章，将从另外一个角度来看待微服务（也包括 Serverless）实践中存在的误区——辛辛苦苦从单体走到微服务，却最后沦为分布式单体。\n分布式单体 “Distributed Monolith”，分布式单体，这真是一个悲伤的技术术语。而这偏偏是企业采用微服务后通常最容易踏进去的一个“陷阱”，事实上我看到的很多微服务落地最终都是以\u0026amp;rdquo;分布式单体\u0026amp;rdquo;收场，无法获得微服务的完整收益。\n问题源于微服务实施的方式 —— 按照业务逻辑拆解单体，划分为多个微服务，定义 API 接口，然后通过 REST 或者 RPC 进行远程调用，最终把这些微服务组合起来提供各种业务功能。简单说，就是在业务拆分的基础上，用进程间的远程调用简单替代原来进程内的方法调用。期间，对于原来使用的各种分布式能力，继续沿用之前的方式，简单说：方式不变，只是粒度变小。\n从方法论说这样做无可厚非，这也是微服务采用过程中非常标准的做法。但问题在于，止步于此是不够的 —— 至少存在两个有待继续努力改进的地方。\n分布式单体起因之一：通过共享库和网络客户端访问分布式能力 分布式能力的共享库和网络客户端是造成分布式单体问题的原因之一，关于这一点，来自 verizon 的 Mohamad Byan 在他的名为 Avoid the Distributed Monolith!! 的演讲中有详细的阐述，我这里援引他的图片和观点：\n上图是微服务体系的逻辑架构，由两部分组成：\n 内层架构（图上浅蓝色部分），是每个微服务的实现架构； 外层架构（图上黄色部分），是构建强大微服务架构所需要的各种能力，这里通常有大家熟悉的各种分布式能力； 特别提示：这里说的“网络客户端”是各种分布式能力的客户端，如服务注册发现/ MQ 中间件/ Redis 等 key-value 存储/数据库/监控日志追踪系统/安全体系等，不是服务间通讯如 RPC 的客户端。\n 而内层的微服务是通过 共享类库 和 网络客户端 来访问外层架构提供的分布式能力：\n分布式能力的 共享类库 和 网络客户端 会迫使内层微服务和外层架构的各种分布式能力之间产生强耦合，增加运维的复杂性（如升级困难造成版本碎片化），多语言受限于类库和网络客户端支持的语言，各种组件（如消息中间件）往往使用自定义数据格式和通讯协议 —— 所有这些迫使内层微服务不得不实质性受限于外层架构的技术选型。\n对于 Function，这个问题就更加明显了：Function 的粒度更小，更专注业务逻辑。某些简短的 Function 可能只有几百行代码，但是，为了让这几百行代码运转起来而需要引入的共享类库和网络客户端可能相比之下就规模惊人了。援引一张网上图片作为示意：\n分布式单体起因之二：简单用远程调用替代进程内方法调用 在微服务架构改造过程中，熟悉单体系统和架构的开发人员，习惯性的会将这些单体时代的知识和经验重用到新的微服务架构之中。其中最典型的做法就是：在遵循领域模型将现有单体应用按照业务边界拆分为多个微服务时，往往选择用 REST 或者 RPC 等远程调用方式简单替代原有的进程内方法调用。\n当两个逻辑上的业务模块存在协作需求时：\n从单体到微服务，直接方法调用被替换为远程调用（REST 或者 RPC），即使采用 Service Mesh 也只是在链路中多增加了 Sidecar 节点，并未改变远程调用的性质：\n这导致了前面所说的 “分布式单体”：\n 在微服务之前：应用程序由多个耦合在一起的模块组成，这些模块通过内存空间进行方法调用….. 在微服务之后：应用程序由多个耦合在一起的微服务组成，这些微服务通过网络进行远程调用….. 抛开调用方式的差异来看采用微服务前后的系统架构，会发现：两者几乎是完全一样的！！\n而微服务版本在某些情况下可能表现的更糟糕：因为调用方式更脆弱，因为网络远比内存不可靠。而我们将网络当成 “胶水” 来使用，试图把分散的业务逻辑模块（已经拆分为微服务）按照单体时代的同样方式简单粘在一起，这当然比单体在同一个进程内直接方法调用更加的不可靠。\n 关于这一点，在 \u0026amp;ldquo;The Eight Fallacies of Distributed Computing/分布式计算的8个谬论\u0026amp;rdquo; 一文中有详细阐述。\n 类似的，在采用 Function 时，如果依然沿用上面的方式，以单体或微服务架构的思维方式和设计模式来创建 FaaS/Serverless 架构：\n其本质不会发生变化 —— 不过是将微服务变成粒度更小的函数，导致系统中的远程调用数量大为增加：\n系统内的耦合并没有发生变化，Serverless 并不能改变微服务中存在的这个内部耦合问题：调用在哪里，则耦合就在哪里！只是把将组件的粒度从 “微服务“换成了 “Function/函数”。\n耦合的存在是源于系统不同组件之间的通讯模式，而不是实现通讯的技术。\n如果让两个组件通过“调用”（后面再展开讲何为调用）进行远程通信，那么不管调用是如何实现的，这两个组件都是紧密耦合。因此，当系统从单体到微服务到 Serverless，如果止步于简单的用远程调 …","date":1593414000,"description":"本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Event/EDA 来走出微服务实践误区：从单体到微服务，却最后沦为分布式单体。","dir":"blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","fuzzywordcount":9800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9ab906cecb82200b18dceb4ab43ba46a","permalink":"https://sofastack.github.io/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","publishdate":"2020-06-29T15:00:00+08:00","readingtime":20,"relpermalink":"/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","summary":"最近社区频繁出现的对微服务的各种质疑和反思的声音，甚至放弃微服务回归单体。本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Eve","tags":["微服务","分布式"],"title":"走出微服务误区：避免从单体到分布式单体","type":"blog","url":"/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","wordcount":9732},{"author":"王旭","categories":"镜像","content":" 众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知道，最初的 Docker = LXC + aufs，前者就是所谓的 Linux 容器了，而后者则是我今天要聊的镜像。\n 千禧年：惊艳的 Live CD 说到 Linux distro，除了做差异化的界面主题之外，核心差异一般都在于：\n 如何更方便地安装； 如何更方便地升级； 而在 distro 界却有一股清流，超脱于这两件事情之外，它们就是 Live CD，它们装在一张光盘里，或者是一个 U盘上，不需要安装、也不会改变。之前创业的时候，我司的运维大佬——彤哥曾经说过：\n 第一次见到 liveCD 时我内心是震惊的。。\n 这我当然是赞同的，那时我也是震惊的同学之一，要知道 Knoppix 在 2000 千禧年就来到了世界，而它所基于的著名的 Debian，直到2005年6月，Sarge (3.1) 发布的时候才正式在 stable release 里带上了图形界面的安装程序 debian-installer （简称 d-i），此前版本的安装还在用文本菜单。就在这个年代，这样一个开光盘即用、启动起来就是图形界面的系统，给我们这些玩家带来的震撼，当然是可想而知的。那时候的 Live CD 就是十三年后的 Docker，绝对配得上“惊艳”两个字。\n要知道，一张 700MB 左右的光盘里塞下个完整的操作系统并不容易（当然有人开头之后也不太难，后来我爱的 DSL 可以做到 50MB）。Knoppix 有个很棒的想法——把装好的操作系统给压缩一下，放在光盘里， 随用随解压，这样，一张 700MB 光盘里可以放下大约 2GB 的根文件系统，这样就跑 KDE 桌面也就没啥问题了，当是时，distrowatch.com 上可以看到，一大片 distro 都是基于 Knoppix 魔改的，足见其影响力。\n进化：可读写层与 UnionFS Knoppix 在诞生之初的一个执念是“绝不碰本地存储一根指头”，而光盘，CD-ROM，所使用的 ISO9600 文件系统也是只读的，这无疑暗合了当今流行的“不可变基础设施”的潮流，但是，即使在今天，没有可写文件系统对于很多 Linux 软件仍然是非常困难的，毕竟随随便便一个程序也要写一点配置文件、状态信息、锁、日志之类的嘛。而诞生之初的 Knoppix 是不可写的，那么，要有什么东西要罗盘，就得手工挖掘出本地硬盘来挂上，或者是挂个 NAS 到 /home 或其他挂载点上来，当你不想只是做个紧急启动盘的时候，这就有点麻烦了。\n如果我们从今天穿越回去，毫不费力就可以指出，用 overlayfs 加上一个 tmpfs 做可写层嘛。但是，overlayfs 要到2010年才首次提交 patchset，2014年才被合并到 3.18内核（这中间，当时的淘宝内核组也有不少贡献和踩坑呢）。当然，比 overlay 早的类似的 unionfs 还是有的，Docker 最早采用的 Aufs 就是其中之一，它是2006年出现的，这里 AUFS 的 A，可以理解成 Advanced，但它最早的意思实际是 Another——是的，“另一个 UFS”，而它的前身就是 UnionFS。\n在2005年5月，也就是十五年前，Knoppix 创造性地引入了 UnionFS，而在一年半以后的 5.1 版本中，Knoppix 引入了当年诞生的更稳定的 aufs，此后，包括大家熟悉的 Ubuntu LiveCD、Gentoo LiveCD 全都使用了 aufs。可以说，正是 Live CD 们，提前了8年，为 Docker 和 Docker Image 的诞生，做好了存储上的准备。\n这里简单说一句给不了解的人听，所谓 union fs，是指多个不同文件系统联合（堆叠）在一起，呈现为一个文件系统，它和一般的 FHS 规定的那种树装组织方式是不同的，如下图，对于左边的标准的目录树结构，任何一个文件系统，挂载在树上的一个挂载点，根据路径，就可以指到一个确定的文件系统，比如，下图中，所有的 /usr/local/ 下面的路径都在一个文件系统上，而其他 /usr 就会在另一个文件系统上；而 UnionFS 是多层堆叠的，你写的文件会停留在最上层，比如图中，你修改过的 /etc/passwd 就会在最上的可写层，其他的文件就要去下面的层中去找，也就是说，它允许同一个目录中的不同文件在不同层中，这样，Live CD 操作系统跑起来就像真正的本地操作系统一样可以读写所有路径了。\n块或文件：Cloop 与 SquashFS 让我们把目光放在只读层上，这一层是 Live CD 的基础，在 Live CD 还没有 union FS 来做分层的时候就已经存在这个只读 rootfs 了。对 Knoppix 来说，这一层是不能直接放完整、无压缩的操作系统的，因为在21世纪初，大家都还在用 24x 到 40x 速光驱的时代，Knoppix Live CD 面临的一个大问题是 700MB 的光盘和庞大的桌面操作系统之间的矛盾。\n开头我们提到了，Knoppix 的想法就是“把装好的操作系统给压缩一下，放在光盘里， 随用随解压”，这样精心选择后的 2GB 的 Distro 就可以压到一张光盘里了，不过“随用随解压“不是说有就有的，文件系统访问块设备，是要找到块的偏移量的，压缩了之后，这个偏移量就并不那么好找了，全解压到内存里再找偏移并不那么容易。\n回到2000年，那时候还是2.2内核，Knoppix 的作者 Klaus Knopper 在创立 Knoppix 之初就引入了一种压缩的(compressed) loop 设备，称为 cloop，这种设备是一种特殊的格式，它包含了一个索引，从而让解压缩的过程对用户来说是透明的，Knoppix 的 cloop 设备看起来就是一个大约 2GB 大的块设备，当应用读写一个偏移的数据的时候，它只需要根据索引解压缩对应的数据块，并返回数据给用户就可以了，无需全盘解压缩。\n尽管 Knoppix 把众多 distro 带上了 Live CD 的船，但是，众多后继者，诸如 arch、Debian、Fedora、Gentoo、Ubuntu 等等 distro 的 LiveCD，以及大家熟悉的路由器上玩的 OpenWrt，都并没有选择 cloop 文件，它们选择了和应用语义更接近的文件系统级的解决方案——Squashfs。Squashfs 压缩了文件、inode 和目录，并支持从 4K 到 1M 的压缩单元尺寸。同样，它也是根据索引按需解压的，和 cloop 的不同之处是，当用户访问一个文件的时候，它来根据索引解压相应的文件所在的块，而非再经过一层本地文件系统到压缩块的寻址，更加简单直接。事实上，Knoppix 里也一直有呼声想要切换到 squashfs，比如，2004年就有开发者在转换 knoppix 到squashfs 上，而且，一些测试数据似乎也表明 Squashfs 的性能似乎要更好一些，尤其在元数据操作方面。\n在 wiki 上是这么评价 cloop 的缺点的： …","date":1592895600,"description":"众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知道，最初的 Docker = LXC + aufs，前者就是所谓的 Linux 容器了，而后者则是今天要聊的镜像。","dir":"blog/twenty-years-of-image-format-from-Knoppix-to-OCI-Image-v2/","fuzzywordcount":6100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f918e4318b9157894559ba289b29553d","permalink":"https://sofastack.github.io/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","publishdate":"2020-06-23T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","summary":"众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知","tags":["镜像"],"title":"镜像格式二十年：从 Knoppix 到 OCI-Image-v2","type":"blog","url":"/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","wordcount":6095},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@雷霆 提问：\n 各位大佬 请问 TCC 拦截器这块为什么 xid 要先解绑，再绑定呢，这样做是有什么考虑吗？ A：执行 TCC 分支时，首先会解绑 xid，这是因为在 TCC 分支内，是不需要执行 AT 的 SQL 解析和自动补偿的（可以在 seata-rm-datasource 的 ExecuteTemplate 里看下实现），同时需要绑定下当前的拦截类型 TCC，这个拦截器类型在跨服务传递时也有特殊处理，建议也看下跨服务传递的源码。最后然后执行完 TCC 分支后的解绑、还原 xid 的操作，就是一个事务上下文的还原了。你目前看到的这个源码，后续我们还会优化下，更方便理解。这一系列操作是为了根据分支类型来区分分支事务的行为：AT 分支的行为是自动补偿，会走 SQL 解析和 undo 回滚，TCC 分支的行为是手动补偿，不会走 undo，而是执行用户自定义的 try 和 confirm。\n2、@taking 提问：\n 为何 TCC 模式的分支事务 commit 需要同步呢？\n A：因为如果异步 commit 会存在，退款的问题，如果没有 commit 那么事务没有完成，这时来了一笔退款交易，则原交易状态没有完成，会失败。当然也可以异步化，但是需要能够容忍一些反向交易的失败，或对反向交易做特殊处理。\n 如果 commit 被阻塞，退款请求也一样还是会失败吧？\n A：commit 被阻塞，说明支付还没有成功，前面不会发起退款的。\n 可以考虑在 LocalTCC 注解上加个属性表示是否允许异步执行。\n A：也可以的，然后在反向交易时需要能判断这个正交易是否已经完成，没有完成，触发一次事务恢复，进行 commit，然后再执行反交易。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服智能监控云原生可观测大盘设计概览 再启程，Service Mesh 前路虽长，尤可期许 蚂蚁金服在 Service Mesh 监控落地经验分享 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFAJRaft v1.3.2 版本，主要变更如下：\n 抽象出网络通信层，增加 GRPC 实现并支持 Replication Pipeline，用户亦可自行对通信层进行其他实现的扩展； RheaKV 增加 reverseScan API ； 提供 Replicator 与 RPC 的线程池隔离，避免相互影响； read-index 线性一致读请求提供请求超时（timeout）配置； 几个 corner case 修复，比如 replicate logs 如果比 appliedIndex（follower）更小，那么可以认为是成功的； 致谢（排名不分先后） @shibd 、@SteNicholas 、@killme2008 、@zongtanghu 详细发布报告： https://github.com/sofastack/sofa-jraft/releases/tag/1.3.2\n2、发布 Occlum v0.13.0 版本，主要变更如下：\n 扩展了Occlum.json的配置格式，更强大，更易读； 增加了3个新的系统调用； 增强了编程语言支持：支持了 Rust、改进了 Python 和 Go 的 demo； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.13.0\n社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1592550000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200619/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4b795b006dbfdc77ff65a693f80f1e6c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200619/","publishdate":"2020-06-19T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200619/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft、Occlum 发布、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200619/","wordcount":1726},{"author":"申尘","categories":"智能监控","content":" 背景 蚂蚁金服业务自定义监控是蚂蚁金服监控产品中的一个重要功能，主要是通过自定义日志数据源并配置大盘的方式来解决蚂蚁金服业务实时监控的需求。在产品功能上，用户可以通过对一系列日志数据源的创建、组织、管理及表单配置化的方式，简单、快速组织出一个多维监控大盘。这项能力在当时是一个具有创新性的能力，从功能到产品体验上很好解决了当时蚂蚁金服复杂业务监控的痛点。\n但是，随着蚂蚁金服监控产品的不断迭代更新，以及云原生可观测性对于监控大盘的高要求，大家对自定义监控的体验诉求也越来越多，包括更便捷的交互方式、更丰富的图表、更丰富的数据源、更多扩展点等，因此对监控大盘的升级也势在必行。\n本文将介绍蚂蚁金服监控产品在监控大盘方面的创新设计与尝试，新版自定义监控大盘 Barad-Dur 目标成为业界体验最优秀的自定义监控大盘，在交互、体验与设计理念上有诸多创新点，同时将以模块的形式发布，支持二次开发，可以同时为蚂蚁金服内外监控系统服务。\n产品体验 WYSIWYG 当前优秀的监控大盘产品都标配一个“所见即所得（WYSIWYG）”编辑器，这方面能力是蚂蚁金服监控产品一直缺失的。在蚂蚁金服监控产品中配置大盘还是通过传统的表单方式，对用户非常不友好、学习曲线陡峭、配置效率不高。导致用户经常将配置大盘作为一项需求提给监控团队，由监控团队的“大盘配置专家”来进行配置，不仅存在较高的沟通成本，也给监控团队增加了很大的负担。\n在新版监控大盘 Barad-Dur 中，对 WYSIWYG 编辑器的交互体验进行了大量工作，力求做到市面上最优秀的编辑体验。\n体验1：缩放 Barad-Dur 的缩放是可以在四周以及四角上进行的，而市面上常见的大盘产品只支持右下角的缩放。由于坐标系统一般采用的是 (left, top, width, height) 来定义一个矩形，最容易实现的就是右下角缩放，只需要变动 width 和 height 两个参数即可。最难实现的是左上角的缩放，四个参数需要同时变动，且关系比较复杂。特别是在引入网格布局后，缩放时要自动“吸附”临近的网格点，难上加难。\n体验2：拖动 Barad-Dur 的图表拖动可以实现图表位置的一步交换，而市面上常见的大盘产品需要进行多次拖动才能实现两个图表的交换。且在拖动过程中，图表的整体布局会被打乱，而 Barad-Dur 不会存在这样的问题。\n体验3：自动重布局 Barad-Dur 的自动重布局功能非常强大，可以支持实时布局预览（当然市面上常见的大盘产品也支持），同时大盘的布局调整会根据具体操作（缩放、拖动）的方向进行。而市面上常见的大盘产品只能在垂直方向上进行布局调整，因为所用的算法非常简单，只是粗暴地把所有图表向页面上“推”。\n体验4：任意位置 Barad-Dur 的布局支持图表在任意位置摆放，而市面上常见的大盘产品由于上述的简陋算法，不支持此功能，所有的图表必须堆叠在页面的顶部。\n体验5：布局复位 Barad-Dur 的自动重布局能够在对单个图表进行调整时将其他图表“推开”，然后更强大的是可以再将被推开的图表复位。这里找到了市面上常见的大盘产品直接拿来用的开源布局框架进行对比。该框架其实提供了上述的任意位置功能，然而由于没有布局复位的功能，导致该功能一旦启用，会令整个大盘在编辑过程中布局被扰乱，对用户起不到任何帮助，所以市面上常见的大盘产品没有启用这个功能。\n体验6：文字编辑 Barad-Dur 支持在大盘中添加静态文字以及对于文字的编辑。静态文字可用于公告、标题、说明等一些常见的大盘场景。\n功能对比 Barad-Dur 市面上常见的大盘产品 任意拖动 ✔︎ ✔︎ 任意缩放 ✔︎ ✘ 多样图表 ✔︎ ✔︎ 图表实时编辑 ✔︎ ✔︎ 图表导入导出 ✔︎ ✔︎ 任意布局 ✔︎ ✘ 添加文字 ✔︎ ✘ 综上对比，可以看出 Barad-Dur 的 WYSIWYG 编辑器在各项功能上已经领先于市面上常见的大盘产品。\n控制器 大盘，即 Dashboard (in an automobile or similar vehicle) a panel beneath the front window having various gauges and accessories for the use of the driver; instrument panel。其本意是指汽车上的仪表板，这里的仪表板包括了两类组成部分：监视器、控制器。在仪表板上不仅能看到汽车的当前状态，也能对汽车进行各种控制。这是大盘的本意，但是就目前看来，市面上所有的监控大盘产品都缺失了控制器这个重要的组成部分，导致监控大盘其实只是监视大盘。如果只是用来监视的，那大盘独立存在就没有意义，就像汽车的仪表板上只有转速表、时速表、里程表，却没有油门、刹车、换挡杆。\n我们再来看几个工业产品的大盘：\n面向普通消费者的量产产品\n面向专业消费者的量产产品\n面向专家的定制产品\n控制器是不可或缺的组成部分，甚至比监视器更加重要。Barad-Dur 提供了在大盘中设置控制按钮的功能，可以实现一些简单的控制，比如关闭/启动报警、打开钉钉聊天窗口、启动控制预案等。日后会不断加入更加强大的控制功能，让蚂蚁金服监控大盘变成一个完整的监控系统。\n技术实现 自定义数据源 上文提到 Barad-Dur 支持二次开发，支持自定义数据源，仅需一点点工作即可接入自己的数据源：\n 继承 AbstractDatasource，并实现 doRequestData 接口； 调用 registerDatasource 将数据源注册至 Barad-Dur（如果使用 Barad-Dur 的数据源编辑器，可在注册时指定自定义的数据源的编辑器）； Barad-Dur 会对所有的数据源进行包装，提供缓存、增量加载、请求合并等功能。\n统一时序数据源 为了实现自定义数据源能够在任意图表中正确展现，Barad-Dur 定义了一种 universal 的时序数据格式，支持多 key 以及多 value。所有的时序数据源（以后可能会支持非时序数据源）都会将查询结果转换为这种格式，所有的图表也都会使用这种数据格式进行展现。\n使用统一数据格式的优势在于，图表和数据源都是按照同样的数据接口（约定）来实现的，所以图表和数据源是可以独立变化的。即图表可以任意切换而不需要改动数据源配置，数据源也可以任意切换而不需要调整图表配置。这是市面上常见的大盘产品做不到的。\n另一大优势在于计算。Barad-Dur 支持数据源的简单前端计算（如计算比率的场景需要将数据 A 与数据 B 相除），在使用了统一的数据格式之后，将计算也视为一个时序数据源，它的输入是一组时序数据源，也就是说一个计算数据源可以引用另一个计算数据源。这也是市面上常见的大盘产品做不到的。\nScene Graph Scene Graph 的概念常用于游戏引擎对于场景的渲染。由于场景中各个节点有父子关系且子节点的空间关系常常用相对于父节点的量来表示，所以需要一种数据结构来将这些 local 空间的量（translation、rotation）转变为 global 空间的量，才能最终转换成屏幕空间的量用于渲染。 …","date":1592463600,"description":"本文将介绍蚂蚁金服监控产品在监控大盘方面的创新设计与尝试。","dir":"blog/antfin-monitoring-cloud-native-observable-market-design-overview/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"30e37e5824f0c80a9aef838c5db03a3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","publishdate":"2020-06-18T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","summary":"背景 蚂蚁金服业务自定义监控是蚂蚁金服监控产品中的一个重要功能，主要是通过自定义日志数据源并配置大盘的方式来解决蚂蚁金服业务实时监控的需求。在","tags":["智能监控"],"title":"蚂蚁金服智能监控云原生可观测大盘设计概览","type":"blog","url":"/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","wordcount":3490},{"author":"涵畅","categories":"Service Mesh","content":" 前言 几乎所有人都在说 Service Mesh；貌似没人知道怎么落地 Service Mesh；但是大家都觉得其他人在大力做 Service Mesh；所以大家都宣称自己在做 Service Mesh。\n上面只是开一个玩笑，但是从某种程度反映了一些实际情况：Service Mesh 是一种设计思想和理念，而不是具体的架构或者实现方式，虽然 Istio+Envoy 的配置似乎已经成了事实标准，当我们环顾四周，却发现理想太丰满，现实太骨感，因为各企业当前切实原因，导致各种形态的 Service Mesh 百花齐放。\n蚂蚁金服的 Service Mesh 就属于上面提到的百花齐放中的一员，我们已经渡过探索期，全面进入生产应用。去年的双十一完成了交易支付核心链路，几十万容器规模的生产级验证。但是业界对于 Service Mesh 仍然有很多种不同的声音，一方面是众星捧月式的支持，另一方面是困惑和质疑，包括对价值、架构以及性能的质疑。那么我们对此是什么态度？双十一深度实践之后蚂蚁金服的 Service Mesh 路又在何方？Service Mesh 架构是终点吗？\n本文将结合蚂蚁金服内部实际场景以及思考，讲述继 2019 双十一之后，蚂蚁金服在 Service Mesh 路上的规划和持续演进。\n蚂蚁金服 Service Mesh 实践回顾 上图是 2019 年蚂蚁金服双十一的实践架构，云原生网络代理 MOSN（https://github.com/mosn）作为蚂蚁金服自研数据面产品，承载了 Mesh 架构的东西向流量。对于控制平面，基于务实的前提我们探索出一套当前阶段切实可行的方案，基于传统服务发现体系落地了 Service Mesh 架构。\n这里是数据化的落地总结，在满足业务的同时，我们真正做到了对业务的低侵入：极低的资源消耗以及快速迭代能力，业务和基础技术都享受到云原生 Mesh 化所带来的红利。\nService Mesh 前路漫漫 我们再来看看 InfoQ 发布的 2020 年 4 月份 Software Architecture and Design 趋势报告，Service Mesh 目前处于 Early Adoption 代，在云原生技术圈仍处于大热阶段，各种技术论坛我们都能见到 Mesh 架构的专场，本篇文章我们不过多讨论 Service Mesh 的选型、使用场景、合理性等等问题，需要的同学可以参考一下文末历史文章，有很多蚂蚁金服对 Service Mesh 的思考。\n对于我们来说，既然在深度思考后选择了这条路，并且在去年双十一进行了深度实践，那么棋到中盘，下一步应该如何落子，除了务实落地之外，我们还要仰望星空，必须知道离诗和远方还有哪些 Gap：\n非全面云原生 前面提到我们落地 Service Mesh 时，仍然采用了传统微服务体系，虽然整体架构基于 K8s，但在控制面上并没有采用社区的方案，当然这些是有考虑的，但是随着整体架构的演进，非全面云原生化势必会成为我们持续享受云原生红利的最大障碍。\n平台能力不足 Service Mesh 的定位是解耦基础设施与业务，但是目前看来，不管是社区 Istio+Envoy 的组合，还是蚂蚁金服传统微服务+MOSN 的实践，均是把东西流量的治理作为了重点，离诗和远方还有很长的路。目前还有大量的基础设施逻辑作为 SDK 镶嵌在业务系统中，我们仍然要面临基础设施升级对业务带来的影响。\n边界流量覆盖不全 随着云原生在数据中心内部愈演愈烈，但是对于数据中心边界以及边缘网络，七层应用网络流量仍然没有形成一个全局体系，由于体系的缺失我们不得不在边界网关与 Mesh 网络两者之间各自分裂发展，均有独立的流量调度体系以及安全可信体系。\n生态融合度低 传统服务体系发展了这么多年，积累了大量宝贵的财富，Service Mesh 作为新贵出现，从两个方面来说：Service Mesh 需要传统服务体系的融入支撑，才能使现有业务迁移到 Mesh 体系；同时传统服务体系的组件也需要有和 Mesh 体系融合的能力才能持续保持竞争力。\n性能 性能是一个老生常谈的问题，Mesh 架构中质疑性能的声音也层出不穷 ，包括 Mixer 控制面，还有引入 Sidecar 造成的额外网络消耗、编解码消耗等等。不过我们可以看到社区一直在解决这些问题，包括对 Mixer 架构的重构，引入 ebpf 来加速流量劫持等等。\n综上所述，我们在 Service Mesh 上任重道远。\n将 Service Mesh 进行到底 今年我们的目标是 Mesh 全面覆盖主要业务，这将面临非常大的挑战：\n 金融级安全可信的要求，需要我们做到全链路加密与服务鉴权； 统一 Sidecar 与 Ingress Web Server； 云原生控制面的落地； 透明劫持能力； 需要承载更多的中间件能力下沉； 上面分析了目前存在的各种问题，同时结合蚂蚁金服自身的业务发展需求，那么我们可以很清晰的对症下药了，我们将上述问题抽象成三类，并进行专项攻坚：\n 以开源生态建设，来应对生态融合问题； 通过云原生标准演进，来解决非全面云原生问题； 最后通过基础核心能力增强，来治理平台能力，覆盖场景以及性能的不足的问题； 开源生态建设 我们再来回顾一下双十一之后我们做的第一个动作：在 2019 年 12 月 28 日由蚂蚁金服主办的第九期 Service Mesh Meetup 上，我们对外宣布了 MOSN 完成在 SOFAStack 的孵化，开始独立运营，以更加开放的姿态寻求合作共建伙伴：\n我们认为，未来会更多地属于那些告别大教堂、拥抱集市的人们。《大教堂与集市》\n在宣布独立运营的同时，我们也做了一系列措施：\n 独立的项目域名：mosn.io 项目地址：github.com/mosn/mosn 社区组织：MOSN Community Organization 项目管理条例：PMC、Committer 选举晋升机制等等 接下来，开源社区我们也持续做了非常多的事情，包括专题 Working Group的创建，例如 Isito WG， Dubbo WG 等等。\n同时也寻求了非常多的外部合作，超过一半的 contributor 均来自外部，接受了第一个来自 BOSS 直聘的 Committer 等等，针对生态融合，我们同Skywalking，Sentinel和Dubbo-go社区进行了深度合作。\nSkywalking 调用依赖以及服务与服务之间的调用状态，是微服务管理中一个重要指标。Skywalking 是该领域非常优秀的一款 APM 软件，MOSN 与 Skywalking 社区展开了合作，进行了两个系统的深度整合工作，目前支持：\n 调用链路拓扑展示； QPS 监控； 细粒度 RT 展示； 在今年五月份，SkyWalking 8.0 版本进行了一次全面升级，采用新的探针协议和分析逻辑，探针将更具互感知能力，更好的在 Service Mesh 下使用探针进行监控。同时，SkyWalking 将开放之前仅存在于内核中的 Metrics 指标分析体系。Prmoetheus、Spring Cloud Sleuth、Zabbix …","date":1592298000,"description":"本文将结合蚂蚁金服内部实际场景以及思考，讲述继 2019 双十一之后，蚂蚁金服在 Service Mesh 路上的规划和持续演进。","dir":"blog/service-mesh-the-road-ahead-long/","fuzzywordcount":7300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"81941474b0c2d163a199a461aaa3f2f3","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-the-road-ahead-long/","publishdate":"2020-06-16T17:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/service-mesh-the-road-ahead-long/","summary":"前言 几乎所有人都在说 Service Mesh；貌似没人知道怎么落地 Service Mesh；但是大家都觉得其他人在大力做 Service Mesh；所以大家都宣称自己在做 Service Mesh。 上","tags":["Service Mesh","源创会"],"title":"再启程，Service Mesh 前路虽长，尤可期许","type":"blog","url":"/sofastack.tech/blog/service-mesh-the-road-ahead-long/","wordcount":7212},{"author":"霄鸿","categories":"Service Mesh","content":" 引言 Service Mesh 是目前社区最为炙手可热的技术方向，去年双11在蚂蚁金服得到全面的应用，并平稳顺滑的支撑了大促服务。作为目前规模最大的 Service Mesh 集群，本文从监控的领域对 Service Mesh 落地进行经验总结，主要从以下几方面进行介绍：\n 云原生监控，介绍蚂蚁金服 Metrics 监控的落地； 用户视角分析，介绍从应用 owner 的角度对这一基础服务设施的体验以及 SRE 从全站服务的稳定性对监控提出的要求； 未来的思考，介绍后续发展方向； 云原生监控 云原生应用的设计理念已经被越来越多的开发者接受与认可，今年蚂蚁金服应用服务全面云原生化，对我们监控服务提出更高的要求。目前 Metrics 指标监控服务也逐渐形成体系，如下图所示基于社区原生 Prometheus 采集方案在蚂蚁金服监控场景下落地。\n怎么采集 蚂蚁金服监控采集 AGENT 是部署在物理机上，支持多个采集插件，如下图，包括执行命令、日志、HTTP 请求、动态 SQL 采集、系统指标采集、JVM 采集以及进程监控等，同时支持多个解析插件自定义解析、单行文本解析、Lua 脚本解析、JSON 解析以及 Prometheus 解析等。\n在Service Mesh 监控落地中，业务方参考业界标准输出 Metrics 指标数据，监控采集该物理机不同 Pod、App 和 Sidecar 的各项指标，包含 Metrics 指标和系统服务指标（CPU、MEM、DISK、JVM、IO 等），然后计算清洗集群节点通过拉取最近周期数据进行数据汇总、groupby 等，数据采集周期又分为：5秒级数据和分钟级数据。 对于 Service Mesh 来说，主要关注的指标有系统指标和 Metrics 指标：\n 系统指标（包括 Pod、App 和 MOSN 等 Sidecar 多个维度的系统指标）： 系统指标, 包含 CPU、LOAD、MEM、BYTES、TCP、UCP 等信息； 磁盘，包含分区可用空间、使用率等信息； IO，包含 IOPS 等信息； Metrics 指标： PROCESSOR，包含 MOSN 进程打开的 fd 数量、申请的虚拟内存大小等进程资源信息； GO，包含 MOSN 进程 goroutine 数量(G)、thread 数量(M)以及 memstats 等 go runtime 信息； Downstream，包含全局下游累计建链数、总读取字节数、累计请求数、请求耗时等； Upstream，包含上游请求失败次数、集群累计建链数、累计断链数、异常断链次数、上游请求平均耗时等； MQ Mesh，包含发送消息总数、耗时、失败数等以及消费消息总数、耗时、失败数等； Gateway Mesh，包含 qps、rt、限流以及多维度的成功数和失败数等； 数据计算 对于 Agent 采集的数据需要从不同维度向上汇聚，满足不同用户对不同视角（LDC、IDC、APP、架构域、站点等视角）的数据需求，以适配蚂蚁金服运维架构体系。\n此时对于这么大规模的数据体系，我们团队建设蚂蚁金服统一的监控数据计算平台。\n 使用统一的监控数据标准、插件化的数据采集接入、通用的数据服务 API 服务来帮助不同的监控产品的快速迭代； 建立一套健全的数据质量体系、高可用计算集群来保障监控数据质量； 通过类 SQL 任务定义、自定义计算任务、插件化来提供丰富、开放的数据分析能力，来满足技术风险业务领域下各种复杂数据分析的需求； 其中计算任务调度（spark）执行的关键组件包括 GS(Global-Scheduler 全局图调度)和 CS (Compute-Space 计算空间)。\nGS 是平台的任务调度中心，如下图所示，它收集了所有业务的数据源配置，根据数据源之间的计算关系，构建出全局计算任务拓扑模型(GlobalGraph)。再根据不同的任务执行策略，将全局任务拓扑图切割成小范围的任务拓扑(Graph)。主要特性有：\n GS 根据任务优先级、资源质量、负载情况等策略，将 Graph 分发到不同的计算空间进行计算(Cspace)； 同一个 Graph 内部的数据依赖是计算过程中直接依赖的； 不同的 Graph 之间的数据依赖会通过存储进行数据解耦； GS 会管理所有 Graph 及计算节点的任务状态，根据 Graph 的依赖关系和依赖 Graph 的执行状态，控制 Graph 的执行时间； CS 是计算平台抽象的计算任务执行空间，如下图所示，主要负责 Graph 的解析和具体计算任务的提交执行，适用于不同的计算引擎，如 Spark/Flink。以 Spark 为例，CS 接收到 GS 发出的 GraphTask，根据 GraphTask 中的 Node(Transform) 解析成 Spark 的 Transfomation 算子和 Action 算子，组成计算 DAG 并提交到 Spark 集群执行。\n在任务执行过程中，CS 会向 GS 同步各任务的执行状态，用于任务跟踪监控。\n多个 CSpace 组成一个 CSpaceGroup，CSpace 之间可以根据负载均衡、资源等级、蓝绿发布等具体场景划分不同的计算分组，多个 CSpace 之间的任务切流可以满足负载均衡、资源隔离、蓝绿发布、灰度等高可用的要求。\n规模化问题 对于蚂蚁金服这么大规模的 Service Mesh 集群数据，产品请求无法都通过 PromQL 方式实时查询结果，以及报警及时通知。此时我们对于监控数据进行分类，其中应用、机房、站点等维度数据进行预计算聚合，例如不同机房的 QPS、RPC 转发成功量、Error 错误等等，前端通过自定义配置出自己关注的大盘视图。\n其中今年大促 MOSN 容器达到几十万，在频繁的发布部署，上线下线过程中，对监控查看的实时性提出更高的要求。其中 Meta 元数据模块对接 K8s 集群，部署监控 operator 监控容器状态变化，达到秒级将最新采集配置通过 Agent registry 更新到 Agent 模块。\n大促保障 我们一方面对监控高可用进行保障，做到采集计算水平扩缩容，另一方面对容量进行评估，通过对不同任务进行分级处理，在大促的时候对高优先级任务进行重点保障，对低优先级任务和业务方进行沟通做降级处理。这样在监控计算资源紧张的情况下，保障核心数据稳定。\n产品视角 Service Mesh 是蚂蚁金服内部应用服务所使用的基础服务设施，对不同的用户看的视角不一样。在监控产品上，用户对产品的使用主要集中在“配、看、用”数据这三个层面。我们早期也做过类似的用户分析。在蚂蚁金服按使用方式将用户分为全局关注者，产品 owner、SRE、领域专家和普通用户等，这里监控产品对于 Service Mesh 也提供不同的视角满足不同的用户需求，举例来说：\n 产品 Owner 视角：特指 MOSN 产品的开发们，他们重点负责 MOSN 的监控指标数据覆盖、数据准确性以及重点调优目标； 普通用户视角：特指应用 Owner，应用 Owner 主要看 MOSN 服务对应用 RPC 调用的影响以及该应用使用 MOSN 服务带来的效率提升； SRE 视角：他们 …","date":1592204400,"description":"作为目前规模最大的 Service Mesh 集群，本文从监控的领域对 Service Mesh 落地进行经验总结","dir":"blog/antfin-service-mesh-monitor-landing-experience/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5728ecea53b7505a29fdd8d498a8f111","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","publishdate":"2020-06-15T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","summary":"引言 Service Mesh 是目前社区最为炙手可热的技术方向，去年双11在蚂蚁金服得到全面的应用，并平稳顺滑的支撑了大促服务。作为目前规模最大的 Service Mesh 集群，本文从","tags":["Service Mesh","智能运维"],"title":"蚂蚁金服在 Service Mesh 监控落地经验总结","type":"blog","url":"/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","wordcount":3749},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 这里有个机会和 SOFAStack 一起玩，你要不要来？ 阿里巴巴编程之夏（Alibaba Summer of Code，以下简称 ASoC）是面向全球18岁及以上本科、硕士、博士高校学生的编程普惠计划，鼓励高校学生深度参与开源开发活动，以第一视角感受开源世界的魅力，成为开源社区新鲜“血液”。\n今年 SOFAStack 开源社区也加入了选题，有兴趣的同学可以尝试下以下 feature：\nSOFAJRaft\n是基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用。\n Feature1:当前 LogStorage 的实现，采用 index 与 data 分离的设计，我们将 key 和 value 的 offset 作为索引写入 rocksdb，同时日志条目（data）写入 Segnemt Log，因为使用 SOFAJRaft 的用户经常也使用了不同版本的 rocksdb，这就要求用户不得不更换自己的 rocksdb 版本来适应 SOFAJRaft， 所以我们希望做一个改进：移除对 rocksdb 的依赖，构建出一个纯 java 实现的索引模块。这个 feature 难度适中，https://github.com/sofastack/sofa-jraft/issues/453\n Feature2:这个 feature 更有挑战些，在 multi raft group 场景中，可能有多个 raft node 在同一个进程中并且很多都是 leader，当他们各自向自己的 followers 发送心跳时会过多的消耗 CPU 和网络 IO。例如我们可以在同一个进程内共享心跳计时器并将这些 leaders 发往同一台机器的心跳请求合并起来发送出去，以此来减少系统消耗，当然你还可以提供更多的优化方案。欢迎尝试 https://github.com/sofastack/sofa-jraft/issues/454\n SOFABolt\n是基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，我们把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。\n Feature：当前的SOFABolt实现中私有协议是直接和整体框架耦合在一起的，在使用SOFABolt的同时需要使用提供的私有协议，当用户希望使用自己的自定义协议时需要进行比较有挑战的代码拓展才能实现。因此我们希望对SOFABolt的协议框架做一些重构以支持快速方便的集成用户的自定义协议。这个 feature 稍有难度，欢迎尝试，https://github.com/sofastack/sofa-bolt/issues/224 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明詹 提问：\n 问下 SOFATracer 现在支持 RabbitMQ 吗？\n A：原生 RabbitMQ API ，Tracer 是没有埋点的；如果和 Spring 集成的，可以基于 Spring Message 方式埋点。使用最新版本即可。 SOFATracer：https://github.com/sofastack/sofa-tracer\n2、@雷霆 提问：\n 请问一下，如果 TCC 在提交全局事务时失败了，比如网络或者 TC 服务异常，导致 TC 压根没有收到全局事务提交的通知，此时 TM 会抛一个异常，导致整个业务处理失败，这个时候已经在一阶段冻结的资源还会回滚吗？看了 Seata 源码，对于这种情况没有看到有触发回滚的操作。\n A：TCC 先注册分支再执行 Try，如果注册分支失败那么 Try 不会执行，如果注册分支成功了 Try 方法失败了，那应该抛出异常触发主动回滚或者触发 Server 超时回滚。\n 那如果分支已经注册成功，且 Try 也执行成功了，就是在 TM 向 TC 发起 global commit 时失败了，TM 多次重试失败后抛了异常，TC 没有收到 commit，这种情况下还会有 rollback 吗？\n A：这种情况触发超时回滚，TC 主动来回滚超时的事务。\n 明白了 谢谢~\n Seata：https://github.com/seata/seata\n本周推荐阅读 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 Forrester 中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求 社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1591945200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200612/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a85bdf92bd596c0809df4b4464b8a85b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200612/","publishdate":"2020-06-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200612/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 绝妙的机会与 SOFAStack 一起玩、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200612/","wordcount":2201},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析\n 活动时间：7 月 2 日周四晚 7 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#16：不得不说的云原生隔离性 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。本期分享将介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1265\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 不得不说的云原生隔离性 丞一 SOFABolt 开源负责人\n你将收获 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 嘉宾 SOFAGirl 主持人 丞一 SOFABolt 开源负责人 ","date":1591945200,"description":"7 月 2 日周四晚 7 点，线上直播第 17 期。","dir":"activities/sofa-channel-17/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6b021a35ee168e2bc4cb3350c6828d68","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-17/","publishdate":"2020-06-12T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-17/","summary":"概要 活动主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 活动时间：7 月 2 日周四晚 7 点 活动形式：线上直播 报名方式：戳","tags":["SOFAChannel","SOFABolt"],"title":"SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-17/","wordcount":574},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" 6月9日，在2020阿里云线上峰会上，蚂蚁联合全球知名市场研究与咨询机构 Forrester 发布《蚂蚁 SOFAStack 总体经济影响报告——金融级云原生市场趋势以及云原生平台带来的成本节省和业务优势》（以下简称“白皮书”）。《白皮书》指出，随着云计算在各行各业的落地不断深化，被技术赋能的企业早已加速构建企业级平台，通过推进数字化转型来塑造可持续的竞争力。其中云平台使能新型基础设施，赋能数字商业模式，成为了社会经济新旧动能转换和信息化应用创新发展的重要数字底座。\n云原生技术已趋向成熟 为金融企业带来全新业务价值与技术优势 Forrester 首席分析师戴鲲表示，越来越多的企业正在借助以云计算为代表的数字技术的巨大潜力，不断提供数字化的客户体验，改进卓越运营能力，加速数字创新进程，构建和扩展数字生态体系，从而加速数字化转型来塑造可持续的竞争力。\n他指出，尤其是一些积极采用新兴技术的泛金融企业，更在加速构建企业级云平台，取得了显著的早期业务成果。而伴随着在应用基础设施、应用软件架构、开发模式与部署架构四个层面协同进化与趋向成熟，云原生技术已为包括金融行业在内的各行各业的企业与机构带来了全新的业务价值与技术优势，具体表现在：\n应用基础设施 从物理机和虚拟机向大规模容器集群进化 容器技术可以实现更高密度的宿主机部署能力和伸缩性，提供更好的性能、更低的空间占用率以及更高的资源利用率，可以实现基础架构的自动化与高效率，帮助金融企业更好地满足大规模互联网业务的动态工作负载支撑要求，从而为客户获得一致的差异化体验提供有效保障。\n应用软件架构 从集中式单体和多层架构向分布式微服务架构进化 微服务框架进一步增强了应用架构伸缩性，通过模块化的复用能力与渐进式的变更能力加速应用价值交付；服务网格为微服务应用带来更为强大的服务间网络连接、可见性和安全性；无服务器计算以全新的编程模型实现应用松耦合和自动伸缩性，有效屏蔽基础架构的复杂性；而边缘计算与物联网技术的发展也使得企业计算架构从中心化向分布式演进，加速洞察的获得与决策反馈的闭环。\n开发模式 从瀑布式和敏捷式向 DevOps 进化 容器技术可以提供良好定义、一致的、高度可迁移的应用软件包，帮助改善开发和运营团队之间的协作过程。而微服务架构的细粒度可重用模块化特性可以帮助技术部门通过技术组件与业务服务的动态组装，通过与持续集成和持续交付流水线的有效集成，实现面向 DevOps 的软件交付，从而加速企业创新进程，有效提升市场响应效率，迅速满足企业内部不同业务部门与区域环境的差异化客户与业务需求。\n运营模式 从单一云环境向混合私有云与公有云的多云环境进化 根据 Forrester 的研究，面向多云、混合云环境的云平台管理能力已经成为了中国乃至全球企业的常态化需求。企业不仅需要在基础架构层面实现跨集群发布部署和跨云平台管控，而且需要具备面向异构资源的一体化管理能力，包括虚机与容器集群的混合管控、经典多层架构与微服务架构的混合支持、传统开发框架与包括大数据和机器学习等在内的新兴技术框架混合使能等。\n如何借助合作伙伴力量 以平台化方式构建金融级云原生能力？ 在迈向云原生的路上，新兴技术带来战略业务价值的同时，也必然引入更多的不确定性。一方面云原生技术依然处在快速演进阶段，距离金融行业所需要的在云端运行关键任务系统的金融级特性仍存在显著差距，另一方面，云原生技术本身在应用架构、开发测试部署过程、应用重构与迁移路径以及系统运维等各个领域都具有技术和管理复杂性。\n戴鲲指出，金融机构在云原生技术的落地实践过程中，必须通过审慎务实的整体战略规划，以平台化的方式有效构建金融级云原生能力，借助合作伙伴的技术深度、生态系统广度以及相关行业实践的专业度，加速可持续的信息化应用创新，真正释放数字基础设施的巨大潜能，需要从以下三大领域进行考虑。\n面向架构敏捷性 构建稳健的集成技术平台，打造业务创新引擎 金融行业的传统企业在长期发展历程中往往积累了大量的技术资产，因此，金融级云原生平台不仅必须具备融合支持能力，还应当以工具化、产品化的方式，帮助开发与运维团队实现云原生应用的快速开发迭代与对存量应用资产的平滑迁移，从而加速金融业务创新进程。\n聚焦业务连续性 基于金融技术风险防控，保障业务稳妥演进 金融级云原生平台必须能够在混合环境下，具备业务同城双活甚至异地多活的高可用容灾能力，而且能够基于单元化架构和数据分片等技术，实现多活容灾的单元化。同时，还应当具备灵活可控的应用发布进程，通过按需暂停回滚、分组灰度发布和原地升级等能力，实现应用的平滑演进；并具备可定制的流程编排能力，实现巡检诊断与容灾应急的自动化。\n追求运维精益性 关注安全可信稳定连续，降低运维保障成本 首先，金融级云原生平台必须具备基于策略的弹性规则配置能力，并通过多维度资源分析、网络流量调拨、实时指标评估以及灵活的回滚方式支持等技术，实现优雅的弹性伸缩。其次，平台必须为全链路可观测性提供支持，不仅提供多维度的监控数据，而且具备场景化的支持能力。最后，平台必须从应用视角出发，结合服务目录、服务网格、日志服务、链路跟踪等技术组件，为大规模分布式业务系统提供可视化的自动化运维能力，有效简化云原生运维过程。\nForrester 为众多希望推动完成数字化转型的金融企业和机构在云计算发展领域提出了以上有关发展方向的战略建议。蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）作为构建金融级云原生架构的应用平台，沉淀了金融场景的最佳实践。在企业面向金融级环境采用云原生技术过程中面临困难时，蚂蚁 SOFAStack 能够提供从服务构建、应用开发、部署发布、服务治理、监控运维、容灾高可用等全生命周期、全栈式解决方案，兼容 Dubbo、Spring Cloud 等微服务运行环境，助力客户各类应用轻松转型分布式架构。\n点击，获取完整 《白皮书》\n","date":1591858800,"description":"云原生技术已趋向成熟 为金融企业带来全新业务价值与技术优势","dir":"blog/forrester-daipeng-white-paper-cloud-native/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"eb590c61c39c7b48afdb5abd95889b99","permalink":"https://sofastack.github.io/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","publishdate":"2020-06-11T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","summary":"6月9日，在2020阿里云线上峰会上，蚂蚁联合全球知名市场研究与咨询机构 Forrester 发布《蚂蚁 SOFAStack 总体经济影响报告——金融级云原生市场趋势以及云原生平台","tags":["SOFAStack","云原生"],"title":"Forrester 中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求","type":"blog","url":"/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","wordcount":2340},{"author":"诣极","categories":"MOSN","content":" 背景 蚂蚁金服内部对 Service Mesh 的稳定性和性能要求是比较高的，内部 MOSN 广泛用于生产环境。在云上和开源社区，RPC 领域 Dubbo 和 Spring Cloud 同样广泛用于生产环境，我们在 MOSN 基础上，支持了 Dubbo 和 Spring Cloud 流量代理。我们发现在支持 Dubbo 协议过程中，经过 Mesh 流量代理后，性能有非常大的性能损耗，在大商户落地 Mesh 中也对性能有较高要求，因此本文会重点描述在基于 Go 语言库 dubbo-go-hessian2 、Dubbo 协议中对 MOSN 所做的性能优化。\n性能优化概述 根据实际业务部署场景，并没有选用高性能机器，使用普通 Linux 机器，配置和压测参数如下：\n Intel\u0026amp;reg; Xeon\u0026amp;reg; Platinum 8163 CPU @ 2.50GHz 4核16G； pod 配置 2c、1g，jvm 参数 -server -Xms1024m -Xmx1024m； 网络延迟 0.23ms, 2台 Linux 机器，分别部署 server+MOSN, 压测程序 rpc-perfomance； 经过3轮性能优化后，使用优化版本 MOSN 将会获得以下性能收益(框架随机512和1k字节压测)：\n 512字节：MOSN+Dubbo 服务调用 tps 整体提升55-82.8%，rt 降低45%左右，内存占用 40M； 1k数据：MOSN+Dubbo 服务调用 tps 整体提升51.1-69.3%，rt 降低41%左右, 内存占用 41M； 性能优化工具 pprof 磨刀不误砍柴工，在性能优化前首先要找到性能卡点，找到性能卡点后，另一个难点就是如何用高效代码优化替代 slow code。因为蚂蚁金服 Service Mesh 是基于 Go 语言实现的，我们首选 Go 自带的 pprof 性能工具，我们简要介绍这个工具如何使用。如果我们 Go 库自带 http.Server 时并且在 main 头部导入import _ \u0026amp;quot;net/http/pprof\u0026amp;quot;，Go 会帮我们挂载对应的 handler, 详细可以参考 godoc 。\n因为 MOSN 默认会在34902端口暴露 http 服务，通过以下命令轻松获取 MOSN 的性能诊断文件：\ngo tool pprof -seconds 60 http://benchmark-server-ip:34902/debug/pprof/profile # 会生成类似以下文件，该命令采样cpu 60秒 # pprof.mosn.samples.cpu.001.pb.gz 然后继续用 pprof 打开诊断文件，方便在浏览器查看，在图1-1给出压测后 profiler 火焰图：\n# http=:8000代表pprof打开8000端口然后用于web浏览器分析 # mosnd代表mosn的二进制可执行文件，用于分析代码符号 # pprof.mosn.samples.cpu.001.pb.gz是cpu诊断文件 go tool pprof -http=:8000 mosnd pprof.mosn.samples.cpu.001.pb.gz 在获得诊断数据后，可以切到浏览器 Flame Graph(火焰图，Go 1.11以上版本自带)，火焰图的 X 轴坐标代表 CPU 消耗情况，Y 轴代码方法调用堆栈。在优化开始之前，我们借助 Go 工具 pprof 可以诊断出大致的性能卡点在以下几个方面(直接压 Server 端 MOSN)：\n MOSN 在接收 Dubbo 请求，CPU 卡点在streamConnection.Dispatch； MOSN 在转发 Dubbo 请求，CPU 卡点在 downStream.Receive； 可以点击火焰图任意横条，进去查看长方块耗时和堆栈明细（请参考图1-2和1-3所示）：\n性能优化思路 本文重点记录优化了哪些 case 才能提升 50%+ 的吞吐量和降低 rt，因此后面直接分析当前优化了哪些 case。在此之前，我们以 Dispatch 为例，看下它为啥那么吃性能 。在 terminal 中通过以下命令可以查看代码行耗费 CPU 数据（代码有删减）：\ngo tool pprof mosnd pprof.mosn.samples.cpu.001.pb.gz (pprof) list Dispatch Total: 1.75mins 370ms 37.15s (flat, cum) 35.46% of Total 10ms 10ms 123:func (conn *streamConnection) Dispatch(buffer types.IoBuffer) { 40ms 630ms 125:\tlog.DefaultLogger.Tracef(\u0026amp;quot;stream connection dispatch data string = %v\u0026amp;quot;, buffer.String()) . . 126: . . 127:\t// get sub protocol codec . 250ms 128:\trequestList := conn.codec.SplitFrame(buffer.Bytes()) 20ms 20ms 129:\tfor _, request := range requestList { 10ms 160ms 134:\theaders := make(map[string]string) . . 135:\t// support dynamic route 50ms 920ms 136:\theaders[strings.ToLower(protocol.MosnHeaderHostKey)] = conn.connection.RemoteAddr().String() . . 149: . . 150:\t// get stream id 10ms 440ms 151:\tstreamID := conn.codec.GetStreamID(request) . . 156:\t// request route . 50ms 157:\trequestRouteCodec, ok := conn.codec.(xprotocol.RequestRouting) . . 158:\tif ok { . 20.11s 159:\trouteHeaders := requestRouteCodec.GetMetas(request) . . 165:\t} . . 166: . . 167:\t// tracing 10ms 80ms 168:\ttracingCodec, ok := conn.codec.(xprotocol.Tracing) . . 169:\tvar span types.Span . . 170:\tif ok { 10ms 1.91s 171:\tserviceName := tracingCodec.GetServiceName(request) . 2.17s 172: …","date":1591686000,"description":"本文将重点描述在基于 Go 语言库 dubbo-go-hessian2、Dubbo 协议中对 MOSN 所做的性能优化。","dir":"blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2584f4b7cd5bf07fb458ef9fbe60433c","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","publishdate":"2020-06-09T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","summary":"背景 蚂蚁金服内部对 Service Mesh 的稳定性和性能要求是比较高的，内部 MOSN 广泛用于生产环境。在云上和开源社区，RPC 领域 Dubbo 和 Spring Cloud 同样广泛用于生产环境，我们在","tags":["MOSN"],"title":"记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化","type":"blog","url":"/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","wordcount":4450},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@林尤庆 提问：\n 请问 SOFARPC 支持 fegin 不？\n A：SOFARPC 发的 rest 服务，feign 的方式是可以调用的，但是跟 ribbon 是没打通的。\n 有具体的例子不？\n A：https://github.com/sofastack/spring-cloud-sofastack-samples\n 我想问下 SOFARegistry 能像 Nacos 那样注册的是整个服务的名称么，现在 SOFARegistry 是细到接口。Spring Cloud是以整个应用注册的，SOFARegistry 是以每一个SofaServicce 注册的。\n A：SOFARegistry 和 Nacos 都是注册中心服务端产品，存的都是 key: list\u0026amp;lt; string \u0026amp;gt; 这样的数据结构，里面存什么数据是由他们的客户端决定的。SOFARPC 就算是注册中心的客户端。\n SOFARegistry 是以每一个 SofaServicce 注册的，fegin 访问的话也是每一个 SofaServicce 去访问的，不是整个应用访问的？\n A：跟 SOFARegistry 没关系，是 SOFARPC 的实现，目前按接口维度注册的。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n2、@姜哲 提问：\n SOFARPC 能发布一个 https 协议的服务吗？\n A：https 不行，h2（http/2+tls）是可以的。\n SOFABoot 环境下怎么发布？有 Demo 吗？\n A：基于 SOFABoot 可能没有适配， 可以先看下 API 方式的： https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/http2/Http2WithSSLServerMain.java\nSOFARPC：https://github.com/sofastack/sofa-rpc\n本周推荐阅读 多点生活在 Service Mesh 上的实践 | 线上直播整理 Service Mesh 中的可观察性实践 | 线上直播整理 Apache SkyWalking 在 Service Mesh 中的可观察性应用 | 线上直播回顾 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 陌陌的 Service Mesh 探索与实践 | 线上直播回顾 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.13.0 版本，主要变更如下：\n 新增 Strict DNS Cluster、GZIP 处理、单机故障隔离； 集成 Sentinel 实现限流能力； 优化 EDF 算法，使用 EDF 算法重新实现 WRR 算法； 支持 Dubbo 服务发现 Beta 版本，优化 Dubbo Decode 性能； 部分实现优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.13.0\n社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1591340400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200605/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9ba8595438771312ed9c187e57789bad","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200605/","publishdate":"2020-06-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200605/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发版、Service Mesh 相关文章整理、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200605/","wordcount":1488},{"author":"陈鹏","categories":"Service Mesh","content":" Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。\n 本文根据5月28日晚 Service Mesh Webinar#1 多点生活平台架构组研发工程师陈鹏，线上主题分享《多点生活在 Service Mesh 上的实践 \u0026amp;ndash; Istio + Mosn 在 Dubbo 场景下的探索之路》整理，文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处。如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点。\n今天主要给大家分享一下 Service Mesh 的一些技术点以及多点生活在 Service Mesh 落地过程中适配 Dubbo 的一些探索。\n首先我们从三个方面入手：\n 为什么需要 Service Mesh 改造； 探索 Istio 技术点； Dubbo 场景下的改造； 为什么需要 Service Mesh 改造 说到为什么需要改造，应该先说一下 Service Mesh 和传统微服务架构的一些特点。\n微服务 微服务一般有这些模块：\n 安全； 配置中心； 调用链监控； 网关； 监控告警； 注册和发现； 容错和限流； 这些模块在传统的微服务架构中有的是和 SDK 结合在一起，有的是一个独立的中间件。\n特点：\n 独立部署； 模块的边界； 技术多样性； 正是由于技术多样性，我的微服务系统可以使用不同的语言进行开发，比如我一个商城系统，订单系统使用 Java 开发，库存系统使用 Go 开发，支付系统使用 Python 开发，微服务之间通过轻量级通信机制协作，比如：HTTP/GRPC 等。比如目前多点使用的 Dubbo(服务治理框架)，随着多点生活的业务发展，目前遇到最棘手的问题就是中间件在升级过程中，推进很慢，需要业务方进行配合，接下来我们看看 Service Mesh。\nService Mesh 优点：\n 统一的服务治理； 服务治理和业务逻辑解藕； 缺点：\n 增加运维复杂度； 引入延时； 需要更多技术栈； 看了 Service Mesh 的优缺点，如果我们 Mesh 化了之后就可以解决我们目前的痛点，升级中间件只需要重新发布一下 Sidecar 就好了，不同语言开发的微服务系统可以采用同样的服务治理逻辑，业务方就可以尝试更多的技术。\n探索 Istio 技术点 在谈 Dubbo 场景下的改造之前我们先介绍一下 Istio 相关的技术点，然后结合 Dubbo 场景应该如何进行适配\nMCP MCP（Mesh Configuration Protocol）提供了一套用于订阅(Watch)、推送(Push)的 API，分为 Source 和 Sink 两个角色。\n Source 是资源提供方(server)，资源变化了之后推送给订阅者(Pilot)，Istio 1.5 之前这个角色就是 Galley 或者自定义 MCP Server； Sink 是资源的订阅者(client)，在 Istio 1.5 之前这个角色就是 Pilot 和 Mixer，都是订阅 Galley 或者自定义 MCP Server 的资源 MCP 的订阅、推送流程图:\n为了和实际情况结合，我们就以 MCPServer 作为 Source，Pilot 作为 Sink 来介绍订阅、推送流程，其中 MCP 通信过程中所传输的「资源」就是 Istio 定义的 CRD 资源，如：VirtualService、DestinationRules 等。\n订阅 Pilot 启动后会读取 Configmap 的内容，里面有一个 configSources 的一个数组配置（Istio 1.5 之后没有这个配置，需要自己添加）、存放的是 MCP Server 的地址； Pilot 连接 MCPServer 之后发送所关注的资源请求； MCPServer 收到资源请求，检查请求的版本信息（可能为空），判断版本信息和当前最新维护的版本信息是否一致，不一致则触发 Push 操作，一致则不处理； Pilot 收到 Push 数据，处理返回的数据（数据列表可能为空，为空也标示处理成功），根据处理结果返回 ACK（成功）/ NACK（失败），返回的应答中包含返回数据的版本信息，如果返回的是 NACK，Pilot 会继续请求当前资源； MCPServer 收到 ACK（和资源请求一致）之后对比版本号，如果一致则不推送，否则继续推送最新数据； 推送 MCPServer 自身数据发生变化，主动推送变化的资源给 Pilot； Pilot 收到之后处理这些数据，并根据处理结果返回 ACK / NACK； MCPServer 收到 ACK（和资源请求一致） 之后对比版本号，如果一致则不推送，否则继续推送最新数据； 这样的订阅、推送流程就保证了 MCPServer 和 Pilot 资源的一致。MCPServer 只能通过 MCP 协议告诉 Pilot 资源发生变化了么？当然不是，MCPServer 可以使用创建 CR 的方式，Pilot 通过 Kubernetes 的 Informer 机制也能感知到资源发生变化了，只是通过 MCP 传输的资源在 Kubernetes 里面看不到，只是存在于 Pilot 的内存里面，当然也可以通过 Pilot 提供的 HTTP debug 接口（istiod_ip:8080/debug/configz）来查。\nhttps://github.com/champly/mcpserver 提供了一个 MCPServer 的一个 demo，如果需要更加细致的了解 MCP 原理可以看一看。\n 更多 debug 接口可以查看: https://github.com/istio/istio/blob/5b926ddd5f0411aa50fa25c0a6f54178b758cec5/pilot/pkg/proxy/envoy/v2/debug.go#L103\n Pilot Pilot 负责网格中的流量管理以及控制面和数据面之前的配置下发，在 Istio 1.5 之后合并了 Galley、Citadel、Sidecar-Inject 和 Pilot 成为 Istiod。我们这里说的是之前 Pilot 的功能，源码里面 pilot-discovery 的内容。\n功能 根据不同平台（Kubernetes、Console）获取一些资源，Kubernetes 中使用 Informer 机制获取 Node、Endpoint、Service、Pod 变化； 根据用户的配置（CR、MCP 推送、文件）触发推送流程； 启动 gRPC server 用于接受 Sidecar 的连接； 推送流程 记录变化的资源类型； 根据变化的资源类型(数组)整理本地数据； 根据变化的资源类型判断需要下发的 xDS 资源； 构建 xDS 资源， …","date":1591264800,"description":"本文主要给分享 Service Mesh 的一些技术点以及多点生活在 Service Mesh 落地过程中适配 Dubbo 的一些探索。","dir":"blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"99f4c0638c5fbd0b762ce8d373142ae0","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","publishdate":"2020-06-04T18:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","summary":"Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。 本文根据5月28日晚 Service Mesh Webinar#1 多点生活平台架构","tags":["Service Mesh","Service Mesh Webinar"],"title":"多点生活在 Service Mesh 上的实践 -- Istio + Mosn 在 Dubbo 场景下的探索之路","type":"blog","url":"/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","wordcount":5590},{"author":"叶志远","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖如何使用 SkyWalking 来观测 Service Mesh，来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务监控的区别。\n本文根据5月14日晚，G7 微服务架构师叶志远的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 谈到 Service Mesh，人们总是想起微服务和服务治理，从 Dubbo 到 Spring Cloud (2016开始进入国内研发的视野，2017年繁荣)再到 Service Mesh (2018年开始被大家所熟悉)，正所谓长江后浪推前浪，作为后浪，Service Mesh 别无选择，而 Spring Cloud 对 Service Mesh 满怀羡慕，微服务架构的出现与繁荣，是互联网时代架构形式的巨大突破。Service Mesh 具有一定的学习成本，实际上在国内的落地案例不多，大多是云商与头部企业，随着性能与生态的完善以及各大社区推动容器化场景的落地，Service Mesh 也开始在大小公司生根发芽，弥补容器层与 Kubernetes 在服务治理方面的短缺之处。本次将以一个选型调研者的视角，来看看 Service Mesh 中的可观察性主流实践方案。\n可观察性的哲学 可观察性（Observability）不是一个新名词，它在很久之前就已经诞生了，但是它在 IT 领域却是一个新兴事物。可观察性在维基百科中原文是这样定义的：“In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. ”。云原生领域第一次出现这个词，是在云原生理念方兴未艾的2017年，在云原生的思潮之下，运用传统的描述方式已经不足以概括这个时代的监控诉求，而 Observability 就显得贴切许多。\n回想一下传统的监控方式，除去运维层面的主机监控、JVM 监控、消息队列监控之外，有多少监控是事先就想好怎么做的？很少！其实很多时候，我们做的事情就是在故障发生之后，对故障复盘的过程中，除了 bug 重现与修复，也会去定制加一些监控，以期望下次发生同样的情况时有一个实时的告警。研发人员收到告警之后得以快速地处理问题，尽可能地减少损失。所以，传统的监控模式大多都是在做亡羊补牢的事情，缺少一个主动性。\n在云原生时代的容器化体系当中就不一样了，容器和服务的生命周期是紧密联系在一起的，加上容器完美的隔离特性，再加上 Kubernetes 的容器管理层，应用服务跑在容器当中就显得更加地黑盒化，相较在传统物理主机或者虚拟机当中，排查问题的时候显得非常不便。所以在云原生时代强调的是可观察性，这样的监控永远都是兵马未动而粮草先行的，需要提前想好我们要如何观察容器内的服务以及服务之间的拓扑信息、各式指标的搜集等，这些监测能力相当重要。\n关于可观察性在云原生领域是何时开始流行起来的，没有一个很明确的时间。业界认为可观察性最早是由 Cindy Sridharan 提出的，其实一位德国柏林的工程师 Peter Bourgon 早在2017年2月就已经有文章在讨论可观察性了，Peter 算是业界最早讨论可观察性的开发者，他写的著名的博文《Metrics, Tracing, and Logging》被翻译成了多种语言。真正可观察性成为一种标准，是来自 Pivotal 公司的 Matt Stine 定义的云原生标准，可观察性位列其中，由此可观察性就成为了云原生时代一个标准主题。\nPeter Bourgon 提出的可观察性三大支柱围绕 Metrics、Tracing 和 Logging 展开，这三个维度几乎涵盖了应用程序的各种表征行为，开发人员通过收集并查看这三个维度的数据就可以做各种各样的事情，时刻掌握应用程序的运行情况，关于三大支柱的理解如下：\n Metrics：Metrics 是一种聚合态的数据形式，日常中经常会接触到的 QPS、TP99、TP95 等等都属于Metrics 的范畴，它和统计学的关系最为密切，往往需要使用统计学的原理来做一些设计； Tracing：Tracing 这个概念几乎是由 SOA 时代带来的复杂性补偿，服务化带来的长调用链，仅仅依靠日志是很难去定位问题的，因此它的表现形式比 Metrics 更复杂，好在业界涌现出来了多个协议以支撑 Tracing 维度的统一实现； Logging：Logging 是由请求或者事件触发，应用程序当中用以记录状态快照信息的一种形式，简单说就是日志，但这个日志不仅仅是打印出来这么简单，它的统一收集、存储以及解析都是一个有挑战的事情，比如结构化(Structured)与非结构化(Unstructed)的日志处理，往往需要一个高性能的解析器与缓冲器； 此外，Peter Bourgon 在博文中还提到了三大支柱结合态的一些理想输出形式，以及对存储的依赖，Metrics、Tracing、Logging 由于聚合程度的不同，对存储依赖由低到高。更多细节，感兴趣的同学可以查看文末的原文链接。\nPeter Bourgon 关于可观察性三大支柱的思考不止于此，他还在2018年的 GopherCon EU 的分享上面再次讨论了 Metrics、Tracing 和 Logging 在工业生产当中的深层次意义，这次他探讨了4个维度。\n CapEx：表示指标初始收集成本，很明显日志的成本最低，埋点即可；其次是 Metrics，最难是 Tracing 数据，在有了协议支撑的情况下，依然要定义许多数据点，以完成链路追踪必须的元数据定义收集； OpEx：表示运维成本，一般指存储成本，这个之前已经讨论过； Reaction：表示异常情况的响应灵敏度，显然聚合之后的数据可以呈现出波动情况，因此 Metrics 是对异常情况最灵敏的；Logging 次之，也可以从 Logging 清洗之中发现异常量；而 Tracing 在响应灵敏度上面似乎沾不上边，最多还是用在排障定位的场景； Investigation：标准故障定位能力，这个维度是 Tracing 的强项，可以直观看出链路当中的故障，精确定位；Logging 次之；Metrics 维度只能反馈波动，对定位故障帮助不大； 在 CNCF Landscape 当中，有一块区域专门用作展示云原生场景下的可观察性解决方案，里面又分为好几个维度，图中是截至2020年5月14日的最新版图，未来还会有更多优秀的解决方案涌现出来。CNCF 目前毕业的10个项目库当中，有3个是和可观察性有关的， …","date":1591092000,"description":"本文根据 G7 微服务架构师叶志远线上分享整理，以一个选型调研者的视角，来看看 Service Mesh 中的可观察性主流实践方案。","dir":"blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a4bde9dc8721fabf285171be403d7f5a","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","publishdate":"2020-06-02T18:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖如何使","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Service Mesh 中的可观察性实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","wordcount":8781},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@钱德鹏 提问：\n 官网的泛化调用 Demo 地址为https://www.sofastack.tech/projects/sofa-rpc/generic-invoke，代码如下： 这段代码里 consumerConfig 没有指定 directUrl，那么是如何获取服务地址的？自己测试时，如果不指定 directUrl，那么会报找不到服务的错误；如果指定 directUrl，可以正常调用。所以想问一下到底需不需要指定？\n ConsumerConfig consumerConfig = new ConsumerConfig() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); A：你这个跟是否跟泛化调用没关系。 RPC 调用肯定是要拿到对方的服务端地址的，这里要么走注册中心去做服务发现，要么走指定直连地址。\n 明白，我的意思是官网的 Demo 里面没指定 URL，那么他是怎么调用成功的？既然官网没有指定，为什么我不指定就调用不到？另外附加一个问题，如果说一定要指定地址，那么我指定成 SLB 地址，由 SLB 去分发，是否可行？\n A：你说官网的 Demo 是哪个？\n https://www.sofastack.tech/projects/sofa-rpc/generic-invoke\n A：这里应该是代码片段，不是完整 Demo。Example 可以参加 https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/invoke/generic/GenericClientMain.java 指定成 SLB 地址是可以的，不过是 slb 跟服务端是长连接，建立了就不断了，服务端负载不一定会均衡。\n 好的，是否可以认为如果像 Demo 里这样调用，就必须指定 directUrl？\n A：对，使用 ZK 为注册中心的例子就是： https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/zookeeper/start/ZookeeperBoltClientMain.java\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@王振 提问：\n 请问，配置 Nacos，如果 Nacos 是集群部署的话，那 Seata 配置 Nacos 地址的时候是不是只需要填写 Nacos 集群地址就行了，不要三个都填的吧？\n A：Nacos 集群不是填3个地址嘛？你自己做了前端负载？\n 用 Nginx 去做了，在 Nacos 之上加入了 Nginx 做了负载均衡，那在 Seata 配置上是不是只需要配置负载均衡的地址就可以了是吗？如果不做负载的话，那填三个地址是逗号隔开吗？\n A：是的，跟直接使用 Nacos 集群写法一致，我们把这个属性透传给 Nacos。\n 是 ip:port,ip:port,ip:port 这种形式对吧？\n A：是的。\n 另外，请问 Seata 对服务器有最低要求吗？\n A：server 推荐 2C4G+ 吧，jvm 内存2G+。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Apache SkyWalking 在 Service Mesh 中的可观察性应用 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 陌陌的 Service Mesh 探索与实践 - 直播回顾 剖析 SOFARPC 框架 【剖析 | SOFARPC 框架】系列之SOFARPC 序列化比较 【剖析 | SOFARPC 框架】系列之SOFARPC跨语言支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 路由实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 优雅关闭剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 数据透传剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 泛化调用实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 单机故障剔除剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 线程模型剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 同步异步实现剖析 【剖析 | SOFARPC 框架】系列之连接管理与心跳剖析 【剖析 | SOFARPC 框架】系列之链路追踪剖析 【剖析 | SOFARPC 框架】系列之总体设计与扩展机制 ","date":1590735600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200529/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2009de6439107016241e7f8efc5a665c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200529/","publishdate":"2020-05-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200529/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 系列直播回顾、SOFARPC 剖析回顾","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200529/","wordcount":1431},{"author":"高洪涛","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖 Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh，来自陌陌和百度的 Service Mesh 生产实践。\n本文根据5月7日晚，美国 Service Mesh 服务商 Tetrate 创始工程师高洪涛的主题分享《Apache SkyWalking 在 Service Mesh 中的可观察性应用》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 本次演讲为大家分享的是 Apache SkyWalking 对 Service Mesh 可观测性方面的应用实践，共分为三个部分：\n 第一部分是 Apache SkyWalking 的相关背景； 第二部分是 Service Mesh 场景下 SkyWalking 所面临的挑战； 最后是针对 Service Mesh 场景方案的演化； SkyWalking 的历史沿革及其特点 SkyWalking 项目的建设目的是为了解决在微服务环境下，如何快速的定位系统稳定性问题。创始团队于2016年启动项目，经过一年的努力完善了最初的版本。2017年，团队启动将项目捐献给 Apache 基金会的流程。在 Apache 基金会孵化器内，经过了多轮系统升级迭代，并获得近乎翻倍的贡献者和关注度，于2019年顺利毕业。经过经年的升级与维护，SkyWalking 从最开始专注于分布式追踪系统的单一平台，发展为包含多个门类并拥有丰富的功能的全领域 APM 系统。\nSkyWalking 整体的系统架构包括有三个部分:\n 第一个是数据采集端，可以使用语言探针对系统的监控指标进行采集，同时也提供了一套完整的数据采集协议。第三方系统可以使用协议将相关的监控数据上报到分析平台。 第二部是分析平台，主要包括对监控指标数据的搜集，流式化处理，最终将数据写到存储引擎之中。存储引擎可使用Elasticsearch，MySQL数据库等多种方案。 第三部分是 UI。UI 组件有丰富的数据展示功能，包含指标展板，调用拓扑图，跟踪数据查询，指标比较和告警等功能。 在此基础上，SkyWalking 本身组件具有丰富的定制功能，方便用户去进行二次开发以支持自己特有的场景。\nSkyWalking 定义了三个维度用来绑定相关的监控指标数据。\n 服务(Service)：表示对请求提供相同行为的一系列或一组工作负载。在使用打点代理或 SDK 的时候, 你可以定义服务的名字。如果不定义的话，SkyWalking 将会使用你在平台上定义的名字, 如 Istio。 实例(Instance)：上述的一组工作负载中的每一个工作负载称为一个实例。就像 Kubernetes 中的 Pod 一样, 服务实例未必就是操作系统上的一个进程。但当你在使用打点代理的时候，一个服务实例实际就是操作系统上的一个真实进程。 端点(Endpoint)：对于特定服务所接收的请求路径，如 HTTP 的 URL 路径和 gRPC 服务的类名 + 方法签名。 预定义的维度可以方便的进行数据预汇集操作，是 SkyWalking 分析引擎重要的组成部分。虽然其相对的会有使用不够灵活的缺点，但在 APM 场景下，指标往往都是预先经过精心设计的，而性能才是关键因素。故 SkyWalking 采用这种预定义维度模式来进行数据汇集操作。\nService Mesh 场景下 SkyWalking 面对的挑战 在描述 Service Mesh 的场景下所面临的挑战之前，需要去解释可观测性所包含的含义。可观测性一般包含有三个部分:\n 第一点，日志系统。由其可以构建出系统运行的实时状态。故日志成为非常方便的观测手段。 第二点，分布式追踪。这部分数据在微服务场景下具有强大的生命力，可以提供给用户分布式系统观测指标。 第三点，指标监控。相比于日志和分布式追踪，其具有消耗小，处理简便等特点，通常作为系统监测告警的重要数据来源。 如上所示是 Istio1.5 的架构图。重点看一下他对可观测性的支持。从图上看，所有的监控指标都汇聚到中间的 Mixer 组件，然后由 Mixer 再发送给他左右的 Adapter，通过 Adapter 再将这些指标发送给外围的监控平台，如 SkyWalking 后端分析平台。在监控数据流经 Mixer 的时候，Istio 的元数据会被附加到这些指标中。另一种新的基于 Telemetry V2 观测体系是通过 Envoy 的 Proxy 直接将监控指标发送给分析平台，这种模式目前还处于快速的演进和开发中，但是它代表着未来的一种趋势。\n从架构图中我们可以看到，这里面的第一个挑战就是 Service Mesh 场景下，对于可观测性的技术体系的支持是非常多变的。\nIstio 本身就包括两种不融合的体系，第一种是基于 Mixer 的场景，第二种是 Mixerless 场景。\nMixer 是基于访问日志进行指标生成的，也就是说服务与服务之间的访问日志经过 Mixer 增加相关的原数据后再发给外围分析系统。其特点是这个模式非常的成熟、稳定，但是性能会非常的低。它的低效源于两个方面，第一点是他的数据发送通道很长，中间节点过多。可以看到数据需要到从 Proxy 发送到 Mixer 节点，再发送给外围的 Adapter 节点。另一个效能低下的原因主要是体现在它发送的是原始访问日志，其数据量是非常大的，会消耗过多的带宽，这对整体的数据搜集与分析提出了非常大的挑战。\n另一种模式是 Mixerless，它完全是基于 Metrics 指标的。通过可观测性包含的技术及其特点分析可知，它是一种消耗比较小的技术，对带宽以及分析后台都是非常友好的。但是它同时也有自己的问题，第一个问题就是他需要的技术门槛是比较高的（使用 WASM 插件来实现），并且对于 Proxy 端的性能消耗也是比较大的。同时由于是新的技术，稳定性较差，相关接口与规范并不完整。\n第二个挑战就是无 Tracing 数据。SkyWalking 最早是为了收集处理跟踪数据（Tracing）而设计的一套系统，但是我们可以从右边的图发现，对于 Service Mesh 上报的数据其实是基于调用的，也就是说它不存在一条完整的跟踪链路。这样就对后台的分析模型有比较大的挑战，如何才能同时支持好这两种模式成为后端分析系统所要处理的棘手问题。\n第三个挑战就是维度匹配的问题。我们从前一章可以看到 SkyWalking 是包括三个维度的，其中对于实例和端点，在 Service Mesh 场景下都是有比较好的支持。这里多说一句，不仅仅是对 Mesh 场景，对于大部分场景都可以很好的去匹配它们。但是对于服务的匹配是有相当大难度的，因为 SkyWalking 只有服务这一层的概念，而在 Istio 中有好几个概念可以称之为“服 …","date":1590649200,"description":"本文根据5月7日晚，美国 Service Mesh 服务商 Tetrate 创始工程师高洪涛的主题分享《Apache SkyWalking 在 Service Mesh 中的可观察性应用》整理。","dir":"blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2414682129ca15d4cfc86bffc6694aaa","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","publishdate":"2020-05-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖 Service Mesh 的","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Apache SkyWalking 在 Service Mesh 中的可观察性应用","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","wordcount":4356},{"author":"罗广明","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。\n本文根据5月13日晚，百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 Service Mesh 在企业落地中有诸多挑战，当与传统微服务应用共同部署治理时可用性挑战更为严峻。本次分享将以 Service Mesh 与 Spring Cloud 应用互联互通共同治理为前提，着重介绍基于 Consul 的注册中心高可用方案，通过各种限流、熔断策略保证后端服务的高可用，以及通过智能路由策略（负载均衡、实例容错等）实现服务间调用的高可用。\nService Mesh 与 Spring Cloud 应用的互通、互联 微服务是时下技术热点，大量互联网公司都在做微服务架构的推广和落地。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。而在这个技术转型中，国内有一个现象，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。近年来，新兴的 Service Mesh 技术也越来越火热，受到越来越多开发者的关注，大有后来居上的趋势。\n在听到社区里很多人谈到微服务技术选型时，注意到他们讨论一个非此即彼的问题：采用 Spring Cloud 还是以 Istio 为代表的 Service Mesh 技术？然而这个答案并非非黑即白、非你即我，一部分应用采用 Spring Cloud，另一部分采用 Service Mesh（Istio）是完全可能的。今天我就和大家一起来讨论这个问题。\n首先，我们来看一下 Spring Cloud 这个传统侵入式微服务框架。它包含以下优点：\n 集大成者，Spring Cloud 包含了微服务架构的方方面面；选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架； 轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者； 开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发； 开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件； 特别感谢 Netflix，这家很早就成功实践微服务的公司，几年前把自家几乎整个微服务框架栈贡献给了社区，早期的 Spring Cloud 主要是对 Netflix 开源组件的进一步封装。不过近两年，Spring Cloud 社区开始自研了很多新的组件，也接入了其他一些互联网公司的优秀实践。\n接下来，我们简单看一下 Service Mesh 框架。它带来了两大变革：微服务治理与业务逻辑的解耦，异构系统的统一治理。此外，服务网格相对于传统微服务框架，还拥有三大技术优势：可观察性、流量控制、安全。服务网格带来了巨大变革并且拥有其强大的技术优势，被称为第二代“微服务架构”。\n然而就像之前说的软件开发没有银弹，传统微服务架构有许多痛点，而服务网格也不例外，也有它的局限性。这些局限性包括：增加了链路与运维的复杂度、需要更专业的运维技能、带来了一定的延迟以及对平台的适配。\n更多关于 Spring Cloud 与 Service Mesh 的优缺点与比较，请阅读 Istio-Handbook [Service Mesh 概述]。\n前面提到过，对于传统微服务框架 Spring Cloud 与新兴微服务框架 Service Mesh，并非是个非黑即白，非你即我，延伸到微服务与单体架构，它们也是可以共存的。\n也可以将其与混合云相类比，混合云中包含了公有云、私有云，可能还有其它的自有基础设施。目前来看，混合云是一种流行的实践方式；实际上，可能很难找到一个完全单一云模式的组织。对多数组织来说，将一个单体应用完全重构为微服务的过程中，对开发资源的调动是一个很严峻的问题；采用混合微服务策略是一个较好的方式，对开发团队来说，这种方式让微服务架构触手可及；否则的话，开发团队可能会因为时间、经验等方面的欠缺，无法接受对单体应用的重构工作。\n构建混合微服务架构的最佳实践：\n 最大化收益的部分优先重构； 非 Java 应用优先采用 Service Mesh 框架； 混合微服务出现的原因是为了更好的支持平滑迁移，最大限度的提升服务治理水平，降低运维通信成本等，并且可能会在一个较长的周期存在着。而实现这一架构的前提，就是各服务的“互联互通”。\n要想实现上述“混合微服务架构”，运行时支撑服务必不可少，它主要包括服务注册中心、服务网关和集中式配置中心三个产品。\n传统微服务和 Service Mesh 双剑合璧（双模微服务），即“基于 SDK 的传统微服务”可以和“基于 Sidecar 的 Service Mesh 微服务”实现下列目标：\n 互联互通：两个体系中的应用可以相互访问； 平滑迁移：应用可以在两个体系中迁移，对于调用该应用的其他应用，做到透明无感知； 灵活演进：在互联互通和平滑迁移实现之后，我们就可以根据实际情况进行灵活的应用改造和架构演进； 这里还包括对应用运行平台的要求，即两个体系下的应用，既可以运行在虚拟机之上，也可以运行在容器/K8s 之上。我们不希望把用户绑定在 K8s 上，因此 Service Mesh 没有采用 K8s 的 Service 机制来做服务注册与发现，这里就突出了注册中心的重要性。\n百度智能云 CNAP 团队实现了上述混合微服务架构，即实现了两个微服务体系的应用互联互通、平滑迁移、灵活演进。上述混合微服务架构图包括以下几个组件：\n API Server：前后端解耦，接口权限控制、请求转发、异常本地化处理等等； 微服务控制中心：微服务治理的主要逻辑，包括服务注册的多租户处理、治理规则（路由、限流、熔断）的创建和转换、微服务配置的管理； 监控数据存储、消息队列：主要是基于 Trace 的监控方案使用的组件； 配置中心：微服务配置中心，最主要的功能是支持配置管理，包括治理规则、用户配置等所有微服务配置的存储和下发，微服务配置中心的特色是借助 SDK 可以实现配置/规则热更新； 接下来主要看一下注册中心的服务注册和发现机制：\n Spring Cloud 应用通过 SDK、Service Mesh 应用实现 Sidecar 分别向注册中心注册，注册的请求先通过微服务控制中心进行认证处理与多租户隔离； Mesh 控制面直接对接注册中心获取服务实例、Spring Cloud 应用通过 SDK 获取服务实例； 双模异构，支持容器与虚机两种模型； 注册中心与高可用方案 前面提到过，要想实现实现混合微服务架构，注册中心很关键。谈到注册中心，目前主流的开源注 …","date":1590476400,"description":"本文根据5月13日晚，百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。","dir":"blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","fuzzywordcount":9100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2cea7fee830cbfcc69ee7732909b231c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","publishdate":"2020-05-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","wordcount":9014},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张晓明 提问：\n 关于 SOFATracer 采样率的配置，只在请求经过的第一个服务配置采样率就可以吗，还是每个服务都需要配置采样率，每个服务都配置的话，要求各服务采样率必须一致吗？\n A：第一个，只在请求经过的第一个服务配置采样率就可以。\n 上报 Zipkin 的话，也只在第一个服务配置就可以吧，其他服务只需要引入 tracer-sofa-boot-starter 就行吧？\n A：上报每个服务节点都要配，不然你下游链路数据拿不到。\n 采样率支持动态更新吗，就是修改后需要重启服务吗？\n A：可以通过自定义采样，配合个配置中心就可以。\n 采样模式用 PercentageBasedSampler，配合配置中心可以吗？\n A：可以，比较麻烦，要反射去改配置类的值，配置类初始化时采样率就确定了，如果要动态改只能通过反射去改。或者通过拿到配置类对象去设置也行，思路差不多。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@李振鸿 提问：\n 请问，分布式事务执行 (只插入两条数据) 执行时间 0.3 会不会比较慢？\n A：嗯，Seata 是消耗了不少性能，尤其是跟 TC 通信、TC 那边的处理。 Seata：https://github.com/seata/seata\n本周推荐阅读 云原生网络代理 MOSN 透明劫持技术解读 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.12.0版，主要更新如下：\n 支持 Go 语言，并增加了 Demo； 新增三个命令行子命令：start, exec 和 stop； 新增 signal 子系统； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.12.0\n社区直播报名 随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处？如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点？服务之间主要通过 Dubbo 交互。本次分享将探索 Istio + MOSN 在 Dubbo 场景下的改造方案，结合现有业务场景和可切入点，明确需要修改的场景，制定符合自己业务场景的 Service Mesh 落地方案，介绍多点生活在 Dubbo 案例的探索及改造方案。\n将从以下几个方面，与大家交流分享：\n 传统微服务架构与 Service Mesh 架构 传统微服务架构在多点遇到的痛点； Service Mesh 架构能带来的福利； Istio 技术点介绍 在 Dubbo 场景下的改造分析 对比 MOSN 和 Envoy 对现有场景的支持； Istio+MOSN 和 Istio+Envoy 在 Dubbo 场景下如何改造； MOSN + Istio 具体实现探索 MOSN 配置文件介绍、从一个流量进来到转发到具体的远端的流程分析； Provider 配置信息如何下发到 Sidecar； 从多点现在的实际场景对现有的 Dubbo 改造方案； Demo 演示 直播主题： Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路\n分享嘉宾：陈鹏，多点生活平台架构组研发工程师，开源项目与云原生爱好者，有多年的网上商城、支付系统相关开发经验，2019年至今从事云原生和 Service Mesh 相关开发工作。\n直播时间：2020/5/28（周四）20:00-21:00\n直播间：点击“这里”，关注直播间即可\n","date":1590138000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200522/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b5778b2bc8e9e6cd92abd8bd7bfc387b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200522/","publishdate":"2020-05-22T17:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200522/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Occlum 发布、技术直播回顾\u0026预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200522/","wordcount":1432},{"author":"巴德","categories":"Kata Containers","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 本文根据 SOFAChannel#16 直播分享整理，主题：不得不说的云原生隔离性。\n大家好，我是今天的讲师巴德，来自蚂蚁金服，主要从事 Kata 容器相关的开发，也是 Kata Containers 项目的维护者之一。今天我和大家分享一下云原生场景下容器隔离性的需求以及我们如何运用 Kata Containers 来提升容器的隔离性。\n从 Kubernetes Pod 说起 在讲云原生隔离性之前，我们先来回顾一下历史。这张图是生产环境应用部署形态的变迁过程。从最左边的物理机上直接部署，到后来的虚拟化兴起，大家把应用部署在虚拟机里，再到 Docker 兴起，大家都把应用部署到容器里面，到现在 Kubernetes 成为主流，大家都把应用部署在 Pod 里面。\n我们看一下 Kubernetes 的一个基本架构，它本身是一个容器的编排系统，主要角色是管理和调度 Pod 以及相关的资源。今天我们主要关注的就是在节点上部署的 Pod，这也是 Kubernetes 资源调度的基本单位。\nKubernetes 官方对 Pod 的定义是一个应用的逻辑主机，其中包含了一个或者多个应用容器，这些容器在资源上是相对紧密的耦合在一起的。Pod 包含了这些容器共享的网络和存储以及如何运行这些容器的声明。Pod 中的内容总是放置在一起并且一同调度，并在共享的上下文中运行。\n这段定义有些抽象，其目的是为了说明 Pod 是可以用不同的隔离技术来实现的。我们先来看一下一个经典的 Pod 实现，基于 Linux namespace 和 cgroups 做抽象的 Pod 实现。\n这个示意图中，我们在一台主机上运行了两个 Pod，这两个 Pod 之间通过主机内核提供的 namespace 和 cgroups 能力来进行隔离。他们之间的所有 namespace 资源都是隔离的。然后在 pod 内部，不同容器之间的 IPC 和网络 namespace 是共享的，但是他们的 mnt/pid/user/uts namespace 又是相互隔离的。这就是一个经典的基于 Linux namespace 和 cgroups 来做隔离的 Pod 的实现。\n对于这种 Pod 的实现，我们可以关注到这两个 Pod 虽然所有的 namespace 都是隔离的，但是他们共享了同一个内核。\n共享内核引入的问题 那么，我们来看一下 Pod 共享同一个内核可能造成什么问题。\n首先我们关注到的是安全问题。也就是说 Pod 中的容器应用会不会通过共享内核的漏洞逃逸出 Pod 的资源隔离？这里我们列了两个近几年的内核 bug，一个是 CVE-2016-5915，另外一个是 CVE-2017-5123，这两个 bug 都曾经造成容器应用通过触发内核 bug 获取宿主机 root 权限并逃逸出 Pod 资源隔离限制。\n另外一个点是故障影响。这个好理解，如果一个 Pod 中的容器应用触发了一个严重的内核 bug，造成内核 panic，这时候同一台宿主机上的所有 Pod 都会被牵连。\n还有一个我们非常关注的点，是共享内核造成的内核资源竞争。同一个宿主机上的不同 Pod，实际上是不同的用户态进程的集合，这些用户态进程虽然在 namespace 上是相互隔离的，但他们还是会共享很多内核资源，比如调度器、某些内核线程或者对象。这种级别的资源共享会引入很多可以观测到的性能抖动，对在线业务的影响也很明显。\n如何避免共享内核造成的这些问题呢？大家最直接的想法就是，把 Kubernetes 装到虚拟机里不就可以更好的隔离起来了吗？如图所示，这本质上是通过增加一个 VM 间接层来解决隔离性问题。\n看起来问题解决了，不是吗？这时候我们就需要抛出计算机届大佬 David Wheeler 的一个名言，“计算机科学中的所有问题都可以通过增加一个间接层来解决，当然，除了间接层过多的问题”。\n那么增加 VM 间接层的方案有什么问题呢？第一，同一个 VM 内的 Pod 之间还是共享内核的。第二，整个集群里出现了虚拟机和 Pod 两层调度系统。\n上帝说，要有光；我们说，要有 Kata 面对这些问题，我们要怎么做呢？我们要部署 Kata 容器 ：)\nKata 容器的一个基本思路是，用虚拟机来作为 Pod 的一种隔离方式。我们把 Pod 中的多个容器资源，放到同一个虚拟机里面，利用虚拟机来实现不同 Pod 独占内核的目的。而 Pod 仍然是 Kubernetes 的基本调度单位，集群里也不会有虚拟机和 Pod 两层调度系统。\n我们简单介绍一下 Kata Containers 这个项目，这是 Openstack 基金会管理下的开放基础设施顶级项目。Kata Containers 的 slogen 是 The speed of containers, the security of VMs。其设计是基于虚拟机完美符合 Pod 抽象这个理念，为用户提供强隔离，易用的容器基础设施。\nKata Containers：https://github.com/kata-containers/kata-containers\n这是 Kata Containers 项目的发展历史概要。在 2015 年的五月，一帮国内的创业者(就是我们) 和 Intel 的同学们分别独立发布了两个叫 runV 和 Clear Containers 的虚拟化容器项目，这就是 Kata Containers 的前身。这两个项目互相有很多交流，在分别独立发展了两年半之后，在 2017 年底，合并成了 Kata Containers 项目，并把这个项目捐给 Openstack 基金会管理，这也是 Openstack 基金会的第一个 Pilot 项目，有一些探索转型的味道。在去年的四月，Kata Containers 被 Openstack 基金会认可为其第二个顶级项目，在这之前的十多年里，Openstack 基金会都只有 Openstack 一个顶级项目。\n目前 Kata Containers 的稳定版本发布到了 1.10.0，而且 2.0 也正在紧锣密鼓地开发中。\n我们再简单介绍下 Kata Containers 的架构。左边蓝色部分是 Kata Containers 对接的上游组件，也就是 Kubernetes 通过 CRI 接口访问 CRI daemon，这里是用 containerd 做展示。 Containerd 通过一个 Shim API 来访问 Kata Containers。右边的就都是 Kata 的组件了。对每一个 Pod，我们有一个名叫 containerd-shim-kata-v2 的服务进程，这个服务进程会负责基于虚拟机的 Pod 的生命周期管理。最后边的 Pod Sandbox 就是我们基于虚拟机来实现的一个 Pod 抽象。在里面我们要运行一个叫 kata-agent 的服务进程，来负责 Pod 内容器的生命周期管理。\nKata 容器特性大放送 介绍了 Kata …","date":1590123600,"description":"本文根据线上直播整理，一起来看看云原生场景下容器隔离性的需求以及我们如何运用 Kata Containers 来提升容器的隔离性。欢迎阅读","dir":"blog/sofa-channel-16-retrospect/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c57953062af87158c42de61e48d1676f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-16-retrospect/","publishdate":"2020-05-22T13:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-channel-16-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播","tags":["Kata Containers","SOFAChannel"],"title":"不得不说的云原生隔离性 | SOFAChannel#16 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-16-retrospect/","wordcount":3573},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路\n 活动时间：5 月 28 日周四晚 8 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 Service Mesh Webinar Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#1 Service Mesh Webinar#1，邀请多点生活平台架构组研发工程师陈鹏，带来分享《多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路》。\n随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处。如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点。服务之间主要通过 Dubbo 交互，本次分享将探索 Istio + MOSN 在 Dubbo 场景下的改造方案。\n分享主题：\n《多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路》\n分享嘉宾：\n陈鹏，多点生活平台架构组研发工程师，开源项目与云原生爱好者，有多年的网上商城、支付系统相关开发经验，2019年至今从事云原生和 Service Mesh 相关开发工作。\n直播时间：2020年5月28日（周四）20:00-21:00\n解决思路:\n从 MCP、Pilot、xDS、MOSN 技术，对 Service Mesh 的可切入点分析。\n成果：\n结合现有业务场景和可切入点，明确需要修改的场景，制定符合自己业务场景的 Service Mesh 落地方案，介绍多点生活在 Dubbo 案例的探索及改造方案。\n大纲：\n 传统微服务架构与 Service Mesh 架构 传统微服务架构在多点遇到的痛点 Service Mesh 架构能带来的福利 Istio 技术点介绍 在 Dubbo 场景下的改造分析 对比 MOSN 和 Envoy 对现有场景的支持 Istio+MOSN 和 Istio+Envoy 在 Dubbo 场景下如何改造 MOSN + Istio 具体实现探索 MOSN 配置文件介绍、从一个流量进来到转发到具体的远端的流程分析 Provider 配置信息如何下发到 Sidecar 从多点现在的实际场景对现有的 Dubbo 改造方案 Demo 演示 ","date":1589958000,"description":"5 月 28 日周四晚 8 点，Service Mesh Webinar#1 线上直播。","dir":"activities/service-mesh-webinar-1/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d146e6a876059c0f8da819f408add6fa","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-webinar-1/","publishdate":"2020-05-20T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-webinar-1/","summary":"概要 活动主题：Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路 活动时间：5 月 28 日周四晚 8 点 活","tags":["MOSN","Service Mesh Webinar"],"title":"Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践","type":"activities","url":"/sofastack.tech/activities/service-mesh-webinar-1/","wordcount":742},{"author":"无在","categories":"MOSN","content":" MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称，可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡、API Gateway、云原生 Ingress 等使用。 MOSN：https://github.com/mosn/mosn\n 在由 Istio 定义的 Service Mesh 体系中，服务治理相关逻辑由独立的 Sidecar 进程处理，如服务发现、故障注入、限流熔断等等。这些处理逻辑是 Service Mesh 着重要解决的问题。通常在谈论到 Service Mesh 时，会优先关注在这些点上，但是在落地过程中，有一个问题同等重要但往往容易被忽视。这个问题概括起来，就是流量是如何被导入到 Sidecar 的监听端口的。\n在数据平面的 Sidecar 中拦截进出应用容器的流量，这一直以来就是 Istio Service Mesh 中一切功能的基础，如何实现透明高效的拦截也是 Service Mesh 设计中的一大难点，本文为大家介绍云原生网络代理 MOSN 是如何做到这一点的。\n流量接管 如果服务注册/发布过程能够允许适当的修改，这个问题会得到极大的简化，比如 Sidecar 将服务发布方的监听地址修改为 127.0.0.1:20882，订阅方 Sidecar 监听本机 20882 端口，当订阅方访问 127.0.0.1:20882 时，流量就自然到达了本端 Sidecar。在这种情况下，无需在网络层面使用重定向技术就可以达到目的。\n服务发布订阅修改逻辑框图\n流量转发流程图\n如上图中，在发布服务时，Sidecar 将服务端原本的地址转换为 Sidecar 自身的端口；服务订阅时，订阅方获取到的端口则是本地 Sidecar 监听的端口。这一方案的优势很明显，逻辑都收敛在了 Sidecar 中，除了需要对 Sidecar 服务注册/发布流程进行改造外，不需要其他组件的参与，但是缺点也很明显，如果业务模型不存在注册中心，或者是服务发布/订阅 SDK 不能进行改造，这个方案就行不通了，而在 Mesh 落地场景中，这个条件恰恰较难满足。\n目前大多数业务的逻辑架构都不符合 Istio 定义的云原生体系，为了享受到 Service Mesh 在服务治理方面的优势，需要选择合适的流量劫持方案。一般而言，流量劫持工作在 L4 层，在进行劫持技术选型时需要考虑三个方面的问题：\n 第一是环境适配，包括容器、虚拟机、物理机、内核、系统发行版等方面的考虑，确保劫持方案在运行环境中能够正常工作； 第二是控制灵活简单，包括如何维护劫持规则，劫持规则如何下发等； 第三是性能，确保在业务运行期间，劫持本身不会带来过大的开销； 下面将从这三个层面分析 MOSN 在落地过程中的一些思考。\n环境适配 在环境适配性上，最容易想到的是 iptables，作为一项古典网络技术，iptables 使用简单，功能灵活，几乎所有现代生产级内核版本与 OS 发行版都默认具备使用条件，Istio 社区也使用 iptables 做流量透明劫持。\niptables 流量劫持原理图\n尽管环境适应性强，但是基于 iptables 实现透明劫持存在以下问题：\n DNAT 模式下，需要借助于 conntrack 模块实现连接跟踪，在连接数较多的情况下，会造成较大的消耗，同时可能会造成 track 表满的情况。为了避免这个问题，可以使用 TProxy 取代 DNAT，但受限于内核版本，TProxy 应用于 outbound 存在一定缺陷。 iptables 属于常用模块，全局生效，不能显式的禁止相关联的修改，可管控性比较差。 iptables 重定向流量本质上是通过 loopback 交换数据，outbond 流量将两次穿越协议栈，在大并发场景下会损失转发性能。 针对 oubound 流量，还可以使用 hook connect 来实现，如图所示：\nhook connect 逻辑框图\n无论采用哪种透明劫持方案，均需要解决获取真实目的 IP/端口的问题，使用 iptables 方案通过 getsockopt 方式获取，TProxy 可以直接读取目的地址，通过修改调用接口，hook connect 方案读取方式类似于 TProxy。\n由于 MOSN 落地的场景十分复杂，有容器与 VM 甚至物理机环境，有基于 K8s 的云原生应用，有基于注册中心的微服务，也存在单体应用，有些场景对性能要求非常高，有些则是够用即可，针对不同的场景，我们选择不同的劫持方案进行适配。如果应用程序通过注册中心发布/订阅服务时，可以结合注册中心劫持流量；在需要用到透明劫持的场景，如果性能压力不大，使用 iptables DNAT 即可，大并发压力下使用 TProxy 与 sockmap 改善性能。\n配置管理 通常基于申明式体系构建的服务在部署时能够得到全局信息，而非申明式体系往往需要在运行期间进行动态的配置修改，由于缺乏全局信息，在运行期间很难获取到准确的服务间调用信息。在生成透明劫持规则时，我们需要明确哪些流量要被重定向到 Sidecar，否则一旦出错，而 Sidecar 又无法处理这部分流量时，将会使得 Sidecar 变成流量黑洞，比如，某一个容器内的 TCP 流量全部被重定向至 Sidecar，而该容器中存在一个使用私有协议承载应用数据的监控 Agent，而 Sidecar 不能识别该协议导致无法争取转发，只能选择丢弃。\n通常情况下，为了确保 Sidecar 能够正确的转发流量，需要满足两个条件，首先是要能够正确识别协议，其次是需要配置转发规则，明确下一跳。对于不满足这两个条件的流量，不应将其重定向至 Sidecar。对于现有的非云原生应用，同时满足这两个条件的代价非常高，比如，某个虚拟机上运行了一个业务，同时还运行了收集 Metrics 的 Agent、日志采集工具、健康检查工具等等。而基于 L4 规则很难精确的将业务流量重定向至 Sidecar，如果多个业务混部，可能导致无法在 L4 层进行业务流量的区分。总结起来，为了精确的把流量引至 Sidecar，需要获得全局的调用关系，这一目标原本应该由 Service Mesh 来完成，而在流量劫持的场景下，却成为了 Service Mesh 的前提。\n为了使用 Service Mesh 而引入大量的部署运维开销是得不偿失的。在落地的过程中，MOSN 引入了多项手段来降低流量劫持的配置难度。我们将需要精确配置重定向规则的工作模式定义为精确匹配，与之相对应的是模糊匹配，即不要求精确区分出需要劫持的流量。降低配置难度的关键在于取消对于精确规则的依赖，在配置模糊规则的前提下，既做到对于关心的业务流量的治理，同时也不影响非业务流量的正常流程。\n我们采用 L4 规则与 L7 规则融合的方式下发模糊的匹配规则，此规则下除了包含关心的业务流量外，还可能包含预期之外的非业务流量。对于业务流量，Sidecar 根据相应的服务治 …","date":1589871600,"description":"如何实现透明高效的拦截也是 Service Mesh 设计中的一大难点，本文为大家介绍云原生网络代理 MOSN 是如何做到这一点的。","dir":"blog/mosn-transparent-hijacking/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c2505ec6bd3034e6cf3222dca8e1b83e","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-transparent-hijacking/","publishdate":"2020-05-19T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-transparent-hijacking/","summary":"MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简","tags":["MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 透明劫持技术解读 | 开源","type":"blog","url":"/sofastack.tech/blog/mosn-transparent-hijacking/","wordcount":3410},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n**1、@黄泽宏 **提问：\n SOFAJRaft 中 rheakv 不实现 region 新增删除，是因为分片迁移比较复杂么？\n A：不知道您说的新增删除是指什么？ 分裂与合并？ 分裂是有的，合并没有，不过分裂还没有经过严格的验证，也暂时不建议使用，分裂和合并确实比较复杂，复杂的不是分片迁移，分片迁移只要 raft 协议实现的没问题就是很自然的事情了。\n 对，sharding 合并分裂迁移，代码大概在哪个位置呢，想先看下实现。\n A：com.alipay.sofa.jraft.rhea.StoreEngine#applySplit 从这里看吧。 SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@廖景楷 提问：\n 请教 Seata 在做超时处理时怎么协调多个节点不会同时对某个事务做多次处理？还是说要求业务容许多次commit，rollback，Seata 就不协调了？ 我在测试 seata-server 多节点 HA 部署，用 MySQL 存储，看代码貌似所有节点都是无差别无状态的，在多个实例的 DefaultCoordiantor 里头有定时器去扫描超时的事务进行重试或者回滚，打开 general log 也发现有多个客户端 IP 在用同样的语句在扫描 global_table 表进行超时等处理。想确认一下多节点间是否有协调机制？ 我在 K8s下面部署3节点的 seata-server statefulset，镜像 docker.io/seataio/seata-server:latest 使用 Nacos 作为 registry。\n A：目前没有，多次不会导致数据问题，不过确实浪费资源，可以考虑引入分布式 job。\n 也就是说比如同一个超时的未 commit Global Session 被多个节点同时扫描到，可能会调用业务做多次 commit，然后由业务自己去重？\n A：是的，不过不是业务处理，框架会处理。\n3、@Cheng cheng 提问：\n 最近正在做 Seata 跟我们产品集成到研究，问一个小白问题，我们需要把 Seata 部署到 K8s 里，那么如果 Seata server 的一个 pod 突然挂了，那在途的调用会突然中断，这样依然可以完美控制事务达成数据一致性吗？\n A：如果 Server 是公用的一个 DB，理论上没问题的。\n 没有理解你说的公用 DB\u0026amp;hellip;. Seata Server 在 K8s 上用独立的几个 pod 部署，那相应的我们会给它单独创建数据库。\n A：Seata 高可用要求就是需要 server 的集群共用同一个 Seata 库，不然无法数据共享，也就是无法知晓当前运作的事务信息。首先你要保证 Server 集群用的同一个注册中心集群，并且共用同一个 Seata 库，这样才能保障数据共享、高可用。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Mecha：将 Mesh 进行到底 陌陌的 Service Mesh 探索与实践 | 线上直播回顾 《Service Mesh Virtual Meetup#1》：视频回顾 *SOFA 项目进展* 本周发布详情如下：\n1、发布 SOFABoot v3.4.0 版本，主要变更如下：\n 支持基于 gRPC 的 triple 协议； 修复 bolt callback 方式的兼容问题； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.0\n2、发布 SOFAHessian v4.0.4 版本，主要变更如下：\n 修复 JDK 判断逻辑有锁问题； 修复 _staticTypeMap 为 ConcurrentMap，和 v3.x 对齐； 详细发布报告： https://github.com/sofastack/sofa-hessian/releases/tag/v4.0.4\n社区直播报名 在云原生时代，容器和 Kubernetes 在日常工作和实际生产中越来越普遍，随之而来的隔离性问题在不断被提起同时也受到了越来越多的关注。\nSOFAChannel#16 线上直播带来《不得不说的云原生隔离性》分享，将邀请 Kata Containers 维护者彭涛（花名：巴德）带我们走近云原生基础设施 \u0026amp;ndash; Kata Containers，详细分享它是如何在云原生框架下解决容器隔离性问题的。\n将从以下几个方面，与大家交流分享：\n 从 Kubernetes Pod 说起，经典容器场景下的 Pod 分享； 共享内核存在的问题以及解决办法； 上帝说，要有光；我们说，要有 Kata； The speed of containers, the security of VMs； Kata Containers 特性大放送； What? 你刚说过增加一个 VM 间接层的问题？ 活动详情：\n 直播主题：SOFAChannel#16：不得不说的云原生隔离性 直播时间：2020/5/21（周四）19:00-20:00 报名方式：点击“这里”，即可报名 ","date":1589533200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200515/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f02bec7b5443778e602b655210ee33fb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200515/","publishdate":"2020-05-15T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200515/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot\u0026SOFAHessian 发布、5/21 社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200515/","wordcount":1781},{"author":"敖小剑","categories":"Service Mesh","content":" 内容摘要：Service Mesh 落地实践三年，效果一直并不理想，到了该反思的时候了。Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化版本，预计也将是云原生化和 Mesh 化的必然趋势，让我们将 Mesh 进行到底。\nMecha 介绍 什么是 Macha？ Mecha 一词，相信爱好动漫的同学应该都不陌生。是的，就是大家熟悉的那个 Mecha（机甲）：\nMecha 这个词之所以出现在这里，主要是因为 Bilgin Ibryam 的这个博客文章 “Multi-Runtime Microservices Architecture”，提出了微服务架构的一个新的设想：Multiple Runtime。\n 备注：这篇博客文章强烈推荐阅读，我甚至建议在阅读本文之前先阅读这篇文章，因为我今天的内容，可以视为对这个文章的深度解读和思考。为了方便，这里提供一份中文翻译版本 多运行时微服务架构。\n 在这篇博客中，Bilgin Ibryam 首先分析并总结了分布式应用的四大需求:\n 生命周期（Lifecycle） 网络（Networking） 状态（State） 捆绑（Binding） 由于每种需求存在的问题和局限性，导致传统解决方案如企业服务总线（ESB）及其变体（例如面向消息的中间件，更轻量级的集成框架等）不再适用。随着微服务架构的发展，以及容器和 Kubernetes 的普及和广泛使用，云原生思想开始影响这些需求的实现方式。未来的架构趋势是通过将所有传统的中间件功能移至其他运行时来全面发展，最后的目标是在服务中只需编写业务逻辑。\n 备注：详情请见原文，为了节约篇幅，这里只做简单概述，不完全引用原文内容。\n 下图是传统中间件平台和云原生平台的对比，传统中间件以各种SDK的方式提供能力，而云原生平台则通过各种外围Runtime（典型如大家熟悉的Servicemesh/Istio）：\n因此作者引入了 Multiple Runtime 的概念：\n作者提出：很可能在将来，我们最终将使用多个运行时来实现分布式系统。多个运行时，不是因为有多个微服务，而是因为每个微服务都将由多个运行时组成，最有可能是两个运行时-自定义业务逻辑运行时和分布式原语运行时。\n对多运行时微服务架构和 Mecha 的说明：\n 您还记得电影《阿凡达》和科学家们制作的用于去野外探索潘多拉的 Amplified Mobility Platform (AMP)“机车服”吗？这个多运行时架构类似于这些 Mecha-套装，为人形驾驶员赋予超能力。在电影中，您要穿上套装才能获得力量并获得破坏性武器。在这个软件架构中，您将拥有构成应用核心的业务逻辑（称为微逻辑/micrologic）和提供强大的开箱即用的分布式原语的 Sidecar Mecha 组件。Micrologic 与 Mecha 功能相结合，形成多运行时微服务，该服务将进程外功能用于其分布式系统需求。最棒的是，Avatar 2 即将面世，以帮助推广这种架构。我们最终可以在所有软件会议上用令人赞叹的机甲图片代替老式的边车摩托车；-)。接下来，让我们看看该软件架构的详细信息。 这是一个类似于客户端-服务器体系结构的双组件模型，其中每个组件都是独立的运行时。它与纯客户端-服务器架构的不同之处在于，这两个组件都位于同一主机上，彼此之间有可靠的网络连接。这两个组件的重要性相当，它们可以在任一方向上发起操作并充当客户端或服务器。其中的一个组件称为 Micrologic，拥有非常少的业务逻辑，把几乎所有分布式系统问题都剥离出去了。另一个伴随的组件是 Mecha，提供了我们在本文中一直讨论的所有分布式系统功能（生命周期除外，它是平台功能）。\n 作者在这里正式提出了 Mecha 的理念：\n思路大体是：Smart Runtime， Dumb Pipes。\n我对 Mecha 的理解是：业务逻辑在编码开始阶段应该是“裸奔”的，专注于业务逻辑的实现，而尽量不涉及到底层实现逻辑；而在运行时，则应该装备“机甲”，全副武装，大杀四方。熟悉的味道是吧？标准而地道的云原生思想。\nMecha 的本质 作者在原文中探讨了 Mecha 运行时的特性：\n Mecha 是通用的，高度可配置的，可重用的组件，提供分布式原语作为现成的能力。 Mecha 可以与单个 Micrologic 组件一起部署(Sidecar 模式)，也可以部署为多个共享(注：我称之为 Node 模式)。 Mecha 不对 Micrologic 运行时做任何假设，它与使用开放协议和格式（例如 HTTP/gRPC、JSON、Protobuf、CloudEvents）的多语言微服务甚至单体一起使用。 Mecha 以简单的文本格式（例如 YAML、JSON）声明式地配置，指示要启用的功能以及如何将其绑定到Micrologic 端点。 与其依靠多个代理来实现不同的目的（例如网络代理、缓存代理、绑定代理），不如使用一个 Mecha 提供所有这些能力。 下面是我对上述特性的个人理解：\n Mecha 提供的是能力，以分布式原语体现的各种能力，而不局限于单纯的网络代理。 Mecha 的部署模型，不局限于 Sidecar 模式，Node 模式在某些场景下（如 Edge/IoT，Serverless FaaS）可能会是更好的方式。至少，Mecha下有机会按需选择，而不是绑死在 Sidecar 模式上。 Mecha 和 Micrologic 之间的交互是开放而有 API 标准的，Mecha 和 Micrologic 之间的“协议”体现在 API 上，而不是 TCP 通讯协议。这提供了一个契机：一个统一 Micrologic 和 Mecha 之间通讯方式的契机。 Mecha 可以以声明式的方式进行配置和控制，这非常符合云原生的理念，同样也使得 API 更关注于能力本身，而不是能力如何配置。 应用需要的能力如此之多（参见上面的图：分布式应用的四大需求），如果每个能力都对应一个代理（不管是 Node 还是 Sidecar），数量会非常夸张，带来的运维压力会很可怕。因此，如 Mecha 这个名字暗示的，运行时应该是整套的形式提供能力，而不是分散。 如果用一句话来总结，那么我认为 Mecha 的本质应该是：\n“面向应用的分布式能力抽象层”\n如 Service Mesh 的本质是服务间通讯的抽象层一样，Mecha 的本质是应用需要的各种分布式能力和原语，包括但不限于服务间通讯。\n从这个角度上说，Mecha 覆盖的范围是 Service Mesh 的超集：毕竟 Service Mesh 只覆盖到应用的部分需求（服务间通讯，还只限于同步/一对一/request-response 模式），还有更多的分布式能力和原语有待覆盖。\n换一句话说，Mecha 的目标应该是：“将 Mesh 进行到底！”\nMecha 的优势和未来 作者指出：Mecha 的好处是业务逻辑和越来越多的分布式系统问题之间的松耦合。\n下图是业务逻辑和分布式系统问题在不同架构中的耦合：\n其实思路和 Service Mesh 是一脉相承的，只是覆盖的分布式能力更广泛一些。\n有一个问题：Mecha 会不会成为微 …","date":1589364000,"description":"Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化版本，预计也将是云原生化和 Mesh 化的必然趋势，让我们将 Mesh 进行到底。","dir":"blog/mecha-carry-mesh-to-the-end/","fuzzywordcount":7500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2ef4b817d0dc0018551a25d24b174ee0","permalink":"https://sofastack.github.io/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","publishdate":"2020-05-13T18:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","summary":"内容摘要：Service Mesh 落地实践三年，效果一直并不理想，到了该反思的时候了。Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化","tags":["Service Mesh"],"title":"Mecha：将 Mesh 进行到底","type":"blog","url":"/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","wordcount":7479},{"author":"高飞航","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。\n本文根据5月6日晚，陌陌中间件架构师高飞航的主题分享《陌陌的 Service Mesh 探索与实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 本次演讲为大家分享的是陌陌目前正在进行的 Service Mesh 实践的相关内容。共分为三个部分：\n 第一部分是原有微服务架构的相关背景； 第二部分是原有架构遇到的问题以及决定采用 Service Mesh 方案的思考过程； 最后的部分对Service Mesh落地实践的方案进行介绍； 陌陌微服务体系演进历程 单体应用到微服务 各个应用的发展过程，都会经历从单体应用、到应用拆分再到微服务架构这样一个过程。陌陌的这个演进过程，有一点比较特别的是，在应用拆分时加入了由 PHP 开发、与客户端 App 进行对接的 API 层，并采用 Java 开发底层具有复杂运算的业务逻辑，这样能够兼得 PHP 的开发效率与 Java 高性能的优势。\n但这个选择的影响也是十分深远的，由于 PHP 在业务中的比重很高，我们在后续进行微服务改造和服务治理时，需要不断地去应对多语言架构带来的挑战。\n微服务体系演进 陌陌的微服务架构改造从 2013 年就开始了，在当时还没有较为完善的服务框架产品的情况下，我们自研了服务框架产品 MOA，支撑了陌陌 IM、附近动态、直播、短视频等核心业务的高速发展历程。\n在多年的迭代发展中，我们逐步完善了服务框架产品功能，同时也扩充了其他基础架构产品，最终形成了一个完善的微服务体系。其他基础架构产品也都是采用了自研的方案，因此整体是一个非常定制化的架构。这一点也成为后续 Service Mesh 落地选型时重点要考量的因素。\n微服务体系整体架构 下面对微服务体系的整体架构进行介绍。我们采用了一个 Redis 作为底层存储的注册中心。服务实例的存活检测主要依赖一个中心化的检测应用 MOA Watcher，能够将无法连通的实例从注册中心的在线列表中移除、摘除实例的业务流量。\n在多语言支持方面，我们除了支持最核心的 Java 与 PHP 应用之外，后续还支持了 Python、C++、Go、NodeJS 等非常多的语言接入微服务体系。由于陌陌的中间件团队是以 Java 工程师为主导的，服务框架组件的核心产品也是一个 Java 的 SDK。在没有足够的资源投入到其他语言 SDK 开发的情况下，我们采用了很多能够简化多语言开发工作的方案。\n例如跨语言调用和 Java 应用内部调用会采用不同的协议，Java 内部是较为传统的自定义二进制传输协议与 Hessian 序列化，跨语言则采用了 Redis 传输协议与 JSON 序列化。Redis 协议分别利用 GET 命令的 key 和 value 的位置传递 Request 和 Response，这样每种语言都可以基于成熟的 Redis 客户端开发 SDK，避免重复编写复杂的网络通信逻辑。此外还增加了一个地址发现服务 Lookup，使其他语言能够像调用普通服务的方式，轮询获取目标服务地址。跨语言场景的这些方案虽然简化了开发工作，但却不是最优方案。这也为整体架构的长期发展埋下了隐患。\n微服务体系的其他产品还包括统一的配置中心、监控平台、日志采集平台、分布式跟踪系统等，这些都是为微服务体系保驾护航的重要基础架构能力。\n流量代理机制 在多语言支持的场景中，我们很早就采用了两个和 Service Mesh 非常相近的方案。一个是为了支持多语言发布服务的入流量代理方案，使用 Java 开发的 Proxy 复用了 Java SDK 注册发现与监控等诸多服务治理能力，使得其他语言仅简单处理本地请求后就能实现发布服务。这些 Java Proxy 与多语言的业务进程是 1:1 部署的，但当时的方案是和业务进程放在一个容器里，升级时需要和业务进程一起重新发布。\n另外一个方案是为了解决 PHP 并行调用下游服务而实现的出流量代理，但这个方案中代理层的进程是运行在独立的服务器上，没有部署在与调用端相同的服务器。\n我们将流量代理机制应用于多语言服务治理的经历，在某种程度上突显了 Service Mesh 的价值，我们可能想到类似的方案去解决问题，但都没有像 Service Mesh 一样系统地给出一种最佳方案。不过这些相近方案的经验是有助于我们后续去推进 Service Mesh 落地的。\n微服务体系规模 随着业务的发展，整个微服务体系也达到了一个很具有挑战的量级。特别是在服务数量大幅增长后，Java 应用的服务治理问题也逐步暴露出来，其中最难以解决的是 SDK 升级的问题，这一点也是进一步推动我们转向 Service Mesh 架构的原因。\n借助 Service Mesh 解决现有架构痛点 架构痛点分析  前面我们提到的各种问题，其实都可以归结为微服务体系中服务治理能力滞后的问题。对于非 Java 的应用，由于没有足够的开发资源，会导致服务框架的 SDK 迭代进度非常缓慢。对于 Java 应用，虽然 SDK 具备最完善的功能，但使全量应用完成升级需要耗费大量人力和时间。根据以往的经验来看，一次推广至少需要一个季度的时间，并且为业务团队带来很多不必要的负担。\n两种场景最终的危害是一致的，都会导致架构能力上无法实现统一，先进的功能无法覆盖到全部应用，使应用稳定性受到损失，甚至引发故障。我们在多语言方案中依赖的中心化的 Lookup 服务，曾经就因为一次服务异常导致整个 API 层不可用，原因就是 PHP 的 SDK 采用了一种有缺陷的机制没有升级。在我们设计新方案时，也会因为架构能力无法统一而无法采用最佳的方案。例如我们在设计多机房架构时，由于流量调度机制无法快速覆盖到全部应用，因此只能采用从应用入口整体调度流量的一种粗粒度的方案。\n引入 Service Mesh Service Mesh 将基础架构逻辑与业务逻辑解耦、并支持独立升级的方式，能够很好地解决前面描述的架构痛点。但引入 Service Mesh 是一项非常重大的架构变更，并且需要多方面的成本投入。因此在实际落地实施前，我们必须思考以下几个问题，并在不同阶段完成对应的工作。\n 第一个是方案是否足够成熟。这里的方案不局限于 Service Mesh 本身，也依赖公司内其他基础设施的演进积累。例如我们在观察阶段实现了应用容化的推广覆盖、日志 Agent 方案的经验积累等。 第二个是遇到的问题是否有其他替代方案。例如我们之前急需在多语言场景覆盖的一个能力是流量调度机制，尝试过一个只提供地址路由机制，不代理流量的 Agent 方案。 …","date":1589266800,"description":"本文根据5月6日晚，陌陌中间件架构师高飞航的主题分享《陌陌的 Service Mesh 探索与实践》整理。","dir":"blog/momo-service-mesh-exploration-and-practice/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9c4d2df383550d5412e3de24312862ed","permalink":"https://sofastack.github.io/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","publishdate":"2020-05-12T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌","tags":["Service Mesh"],"title":"陌陌的 Service Mesh 探索与实践 - 直播回顾","type":"blog","url":"/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","wordcount":6499},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n**SOFAStack 官网: **https://www.sofastack.tech\n**SOFAStack: **https://github.com/sofastack\n社区大事件 MOSN 社区新认证一位 Committer\n孙福泽（@peacocktrain）认证成为 MOSN Committer：\n主要贡献： 贡献 3 个 feature PR\n 使 MOSN 支持 Istio 1.4； 协议支持 HTTP2 双向流式； 添加管道缓冲区； MOSN：https://github.com/mosn/mosn\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n**1、@chromosome **提问：\n 这个视频中提到因为 log server 中存储得到 commitedId 和 applyId 不是任意时刻都同步的，这样的话，如果说状态机的 apply 速度较慢，很可能 client 的 read request 并不能读取到状态机最新 committed 的操作的结果。 https://tech.antfin.com/community/live/821/data/902\n A：commitedIndex 和 applyIndex 的不完全同步，并不影响 read request 的结果，所以上面的后半句理解还是有点问题，可以看一下 SOFAJRaft 线性一致读的原理介绍，参考这个链接线性一致读章节 https://www.sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/\n 所以 counter 例子中的 readindex 写法就是为了读线性一致性吗？例如 this.counterServer.getNode().readindex\n A：是的。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、**@王勇 **提问：\n 在 AT 模式下，事务的回滚如何补偿三方的缓存操作呢？有没有额外的接口，还是只能是变成 TC 模式，或是自己写 aop？\n A：TCC 嵌套 AT，TCC 二阶段行为做补充。\n TCC 内应该说是不存在 AT 吧。\n A：AT 保证数据库的一致性，TCC 做来二阶段时的三方处理，比如发出 MQ 消息、缓存之类的。\n 就是 AT 和 TCC 在同一全局事务中一起使用是吧。这个 TCC 一阶段可以是空的，二阶段回滚时清理缓存嘛？\n A：嗯。\n OK，我明白了。就是让 TCC 嵌套 AT，通常情况下 TCC 为空，需要补偿的时候向 TCC 里写入东西。\n A：可以这么说，如果 TCC 触发二阶段是回滚，你就把缓存删掉，如果是提交就啥也不干，大概是这么个意思。\n TCC 模式下 AT 是默认的吗？对于大事务，Saga 模式，您用过吗？\n A：一、首先需要创建状态机引擎的 bean。 1.2.0里，状态机引擎的 bean 需要自己创建的。 1.3.0里，spring-boot-starter-seata 里会提供自动配置类。（可以先参考我修改过的代码吧。https://github.com/wangliang1986/seata） 二、需要创建 Saga 模式所需的三张表。github 上可以找到建表 SQL。 三、使用 Seata 的在线状态机设计器来定义流程。地址：http://seata.io/saga_designer/index.html 四、将设计器生成的 json 文件放到自己项目的 resources 中，由状态机引擎去加载它。状态机配置类中有一个配置项可以配置 json 文件路径。 五、使用状态机引擎启动 Saga 事务即可。（要注意的是 1.2.0 版本中，Saga 无法与 AT 一起启用。1.3.0 将修复此问题。） Seata：https://github.com/seata/seata\n本周推荐阅读 （含直播报名）Kata Containers 创始人：安全容器导论 蚂蚁金服 SOFAJRaft 优先级选举剖析 | 特性解析 Service Mesh 和 API Gateway 关系深度探讨 SOFA 项目进展 本周发布详情如下：\n1、发布SOFARPC v5.7.0,主要变更如下：\n 支持基于 grpc 的 triple 协议； 重构项目模块结构； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.0\n2、发布 SOFA MOSN v0.12.0，主要变更如下：\n 支持 SkyWalking； 支持流式 HTTP2； 熔断功能、负载均衡逻辑优化，负载均衡新增 ActiveRequest 和 WRR 算法； 优化 HTTP 连接建立性能； 底层实现优化； Bug Fix； 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/v0.12.0\n社区直播报名 本期为第一期 Service Mesh Virtual Meetup 线上系列直播第一期，邀请了四位来自不同公司的嘉宾，从四个角度对 Service Mesh 的应用实践展开分享。\n本次线直播分享涵盖 Service Mesh 的可观察性和生产实践，为大家介绍 Service Mesh 中的可观察性与传统微服务中可观察性的区别，如何使用 SkyWalking 来观测 Service Mesh，还有来自百度和陌陌的 Service Mesh 生产实践。\n本系列采用线上直播的形式，从 5 月 6 日开始到 5 月 14 日，每周三、周四晚上 19:00-20:00 我们相约进行一个主题分享。\n 时间 分享主题 分享嘉宾 嘉宾介绍 5\u0026amp;frasl;6 陌陌的 Service Mesh 实践 高飞航 陌陌中间件架构师 5\u0026amp;frasl;7 Apache SkyWalking 在 Service Mesh 中的可观察性应用 高洪涛 Tetrate 创始工程师 5\u0026amp;frasl;13 Servicre Mesh 高可用在企业级生产中的实践 罗广明 百度高级研发工程师 5\u0026amp;frasl;14 Servicre Mesh 中的可观察性实践 叶志远 G7 微服务架构师 观看直播方式：点击“这里”，关注直播 …","date":1588928400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200508/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c743041c871c1b4fdd685334ab29add6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200508/","publishdate":"2020-05-08T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200508/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN\u0026amp;SOFARPC 发布、社区活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200508/","wordcount":1872},{"author":"王旭","categories":"Kata Container","content":" 从2015年5月初开始创业开发 HyperContainer (runV) 到现在，也快五年了，在这个时候还来写一篇什么是安全容器，显得略有尴尬。不过，也正是经过这五年，越来越多到人开始感到，我需要它却说不清它，这个时候来给大家重新解释 “\u0026amp;gt; 安全容器” 也正是时候。\n缘起：安全容器的命名 Phil Karlton 有一句名言—— _计算机科学界只有两个真正的难题——缓存失效和命名。_ 就容器圈而言，我相信命名绝对配得上这句话，这毫无疑问是一件让老开发者沉默，让新人落泪的事情。\n仅就系统软件而言，我们当今比较通行地称为 Linux 容器（LinuxContainer）的这个概念，曾经用过的名字大概还有——jail, zone, virtualserver, sandbox\u0026amp;hellip; 而同样，在早期的虚拟化技术栈里，也曾经把一个虚拟机环境叫做容器。毕竟这个词本身就指代着那些用来包容、封装和隔离的器物，实在是太过常见。以至于，以严谨著称的 Wikipedia 里，这类技术的词条叫做“系统级虚拟化”，从而回避了“什么是容器”这个问题。\n当2013年 Docker 问世之后，容器这个概念伴随着“不可变基础设施”、“云原生”这一系列概念，在随后的几年间，以摧枯拉朽之势颠覆了基于“软件包+配置”的细粒度组合的应用部署困境，用简单地声明式策略+不可变容器就清爽地描述了软件栈。应用怎么部署似乎离题了，我们这里想要强调的是——\n云原生语境下的容器，实质是“应用容器”——以标准格式封装的，运行于标准操作系统环境（常常是 Linux ABI）上的应用打包——或运行这一应用打包的程序/技术。\n这个定义是我在这里写下的，但是它并不是我的个人意志，这是基于 OCI (Open ContainerInitiative) 规范这一共识的，这个规范规定了容器之中的应用将被放置在什么环境中，如何运行，比如启动容器根文件系统上的哪个可执行文件，用什么用户，需要什么样的 CPU、内存资源，有什么外置存储，有什么样的共享需求等等。\n有了这一共识做基础，我们来说安全容器，这又是一段命名血泪史。当年，我的联合创始人赵鹏是用“虚拟化容器”命名的我们的技术的，为了搏人眼球，用了“Secure as VM, Fast asContainer”的大字标语，自此，被容器安全性问题戳中心坎的人们立刻用“Secure Container”来称呼这类东西，一发而不可收。而我们的内心中，这项技术提供了一层额外的隔离，隔离可能意味着安全性中的一环，也意味着某些运维效率、某些优化可能或者其他的功能。实际上，给安全容器这样的定义更合理——\n一种运行时技术，为容器应用提供一个完整的操作系统执行环境（常常是 LinuxABI），但将应用的执行与宿主机操作系统隔离开，避免应用直接访问主机资源，从而可以在容器主机之间或容器之间提供额外的保护。\n间接层：安全容器的精髓 安全问题的唯一正解在于允许那些（导致安全问题的）Bug 发生，但通过额外的隔离层来阻挡住它们。 —— LinuxCon NA 2015, Linus Torvalds 为了安全，为什么要引入间接层？因为以 Linux 之类的目前主流宿主机操作系统的规模，是无法从理论上验证程序是没有 Bug 的，而一旦合适的 Bug 被合适地利用，安全性风险就变成了安全性问题了，框架和修补并不能确保安全，所以，进行额外的隔离、缩减攻击面，就成了缓解安全问题的法宝——我们不能确保没有漏洞，但我们通过组合来减少漏洞被彻底攻破的风险。\nKata: 云原生化的虚拟化 2017年12月，我们在 KubeCon上对外发布了 Kata Containers 安全容器项目，这个项目的两个前身——我们发起的的 runV 和Intel 发起的 Clear Container 都发布于2015年5月（是的，早于上面 Linus 的引语）。这组项目的思路很简单 ——   操作系统本身的容器机制没办法解决安全性问题，需要一个隔离层；  虚拟机是一个现成的隔离层，AWS 这样的云服务已经让全世界相信，对户来说，\u0026amp;rdquo;secure of VM\u0026amp;rdquo; 是可以满足需求的；  虚机里面只要有个内核，就可以支持 OCI 规范的语义，在内核上跑个 Linux 应用这并不太难实现；  虚机可能不够快，阻碍了它在容器环境的应用，那么可不可以拥有 \u0026amp;ldquo;speed of container\u0026amp;rdquo; 呢？  现在，如果最后一个问题可以解决，那么它就是我们要的“安全的容器”了——这就是 Kata Containers。 目前 Kata Containers 通常是在 Kubernetes 环境中使用的，Kubelet 通过CRI 接口让 containerd 或 CRI-O 执行运行时操作，通常镜像操作由这些 CRI Daemon 来进行，而根据请求，把 Runtime 操作写成一个 OCI Spec 交给 OCI Runtime 执行。这里，对于 1.2 以上的 containerd 和 1.5 版本上后的 Kata Containers（对应 ），通常是利用 containerd 来完成的：\n 每个 Pod 会有一个 shim-v2 进程来为 containerd/CRI-O 执行各种运行时操作，这个进程和整个 Pod 的生命周期一致，通过一个 ttRPC 接口为 containerd/CRI-O 提供服务； Shim-v2 会为 Pod 启动一个虚拟机作为 PodSandbox提供隔离性，其中运行着一个 Linux 内核，通常这个 Linux 内核是一个裁剪过的内核，不会支持没有必要的设备； 这里用的虚拟机可以是 Qemu 或是 Firecracker，如果是 Firecracker，那么根本就没有模拟的设备，而如果是 Qemu，通过配置和补丁，也会让它尽量小一些，支持的其他虚拟机还包括 ACRN 和 cloud-hypervisor，未来后者可能会被越来越多的用到； 这个虚拟机在启动的时候可能根本就是一个 initrd 而没有完整操作系统，或者有个极小的操作系统，总之，它完全不是按照一台模拟机的操作系统来配置的，它只是支撑容器应用运行的基础设施，以及相关的应用环境 Metrics 采集或应用跟踪调试需要的资源； 容器本身的 rootfs 会在 Sandbox 启动之后，在收到 contaienrd/CRI-O 的创建容器的 OCI 请求之后，以热插拔的方式动态插入到虚机中，容器的 rootfs 准备和虚机本身的启动是可以并行的； 依照 CRI 语义和 OCI 规范，Pod 里可以启动多个相关联的容器，它们被放在同一个虚机里，并且可以互相共享 namespace； 外来的存储卷可以以块设备或文件系统共享的方式插入到 PodSandbox 中，但对于 Pod 里的容器来说，它们都是加载好的文件系统，目前开始逐渐普及的文件系统方式是专为 Kata 这样的场景设计的 virtio-fs，它不仅比传统的 9pfs 更快、有更完整的 POSIX 文件系统的支持，而且借由所谓 vhost-user 和 DAX 技术，它还可以在不 …","date":1588921200,"description":"隔离，让云原生基础设施更完美。","dir":"blog/kata-container-introduction-to-safe-containers/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6075ee3441970bada70f11c633f4ba85","permalink":"https://sofastack.github.io/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","publishdate":"2020-05-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","summary":"从2015年5月初开始创业开发 HyperContainer (runV) 到现在，也快五年了，在这个时候还来写一篇什么是安全容器，显得略有尴尬。不过，也正是经过这五年，越来越多到人","tags":["Kata Container"],"title":"（含直播报名）Kata Containers 创始人：安全容器导论","type":"blog","url":"/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","wordcount":4686},{"author":"Committer 胡宗棠","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文作者胡宗棠，SOFAJRaft Committer，来自中国移动。本文主要介绍 SOFAJRaft 在 Leader 选举过程中的重要优化方案—一种半确定性的优先级选举机制，将会先简单地介绍下原 Raft 算法中随机超时选举机制的大致内容，如果读者对这块内容理解得不够深入，建议可以先阅读下《SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理》。阅读完这篇文章后，再来看本篇的内容会对半确定性的优先级选举机制有更为深刻的理解。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n一、Raft 算法中选举机制的概念与特点 Raft 算法是一种“共识性”算法，这里所谓的“共识性”主要体现在让多个参与者针对某一件事达成完全一致：一件事一个结论，同时对已达成一致的结论，是不可推翻的。基于这个根本特征，就决定了 Raft 算法具有以下几个主要特点：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成。这是主要为了保证在任何的时间段内，Raft 集群最多只能存在一个 Leader 角色的节点； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务； 在 Raft 算法中，选举是很重要的一部分。所谓选举就是在由多个节点组成的一个 Raft 集群中选出一个 Leader 节点，由他来对外提供写服务 （以及默认情况下的读服务）。\n这里先介绍一个任期的概念—Term， 其用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。同时，该 Term ID 的值是按照时间轴单调递增的，它构成了 Raft Leader 选举的必要属性。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。为了让 Raft 集群中的所有节点尽可能的客观公平公正，采用了随机超时时间触发选举，来避免若干个节点在同一时刻尝试选举而导致选票被瓜分的情况，保证选举的顺利完成。SOFAJRaft 的做法是，在 Node 触发选举的定时任务— electionTimer 中的设置每次定时执行的时间点：时间区间 [electionTimeoutMs，electionTimeoutMs + maxElectionDelayMs) 中的任何时间点。\n在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求； 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳； 同时，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。当选举 Leader 选举成功后，整个 Raft 集群就可以正常地向外提供读写服务了，如上图所示，集群由一个 Leader 和两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳和将日志 Log 复制给 Follower。\n但 Raft 算法的“随机超时时间选举机制”存在如下问题和限制：\n 下一个任期 Term，Raft 集群中谁会成为 Leader 角色是不确定的，集群中的其他节点成为 Leader 角色的随机性较强，无法预估。试想这样的一个场景：假设部署 Raft 集群的服务器采用不同性能规格，业务用户总是期望 Leader 角色节点总是在性能最强的服务器上，这样能够为客户端提供较好的读写能力，而上面这种“随机超时时间选举机制”将不能满足需求； 如上图所示，由于会存在选票被瓜分的场景，集群中的各个 Candidate 角色节点将在下一个周期内重新发起选举。而在这个极短的时间内，由于集群中不存在 Leader 角色所以是无法正常向客户端提供读写能力，因此业务用户需要通过其他方式来避免短时间的不可用造成的影响； 二、SOFAJRaft 基于优先级的半确定性选举机制 2.1 SOFAJRaft 基于优先级选举机制的原理 为了解决原本 Raft 算法“随机超时时间选举机制”带来的问题，增加选举的确定性，作者贡献了一种“基于优先级的半确定性选举机制”。主要的算法思想是：通过配置参数的方式预先定义 Raft 集群中各个节点的 priority 选举优先级的值，每个 Raft 节点进程在启动运行后是能够知道集群中所有节点的 priority 的值（包括它自身的、本地会维护 priority 变量）。\n对每个 Raft 节点的配置如下（下面以其中一个节点的配置举例），其中 PeerId 的字符串值的具体形式为：{ip}:{port}:{index}:{priority}；\n在 Raft 节点进程初始化阶段，通过对所有节点 priority 值求最大值来设置至节点自身维护的 targetPriority 本地全局变量里。在上面这个例子中，节点的 targetPriority 本地全局变量值就被设置为 160，而自身的 priority 值为 100。\n在每个 Raft 节点通过随机超时机制触发 PreVote 预选举阶段之前，会通过先比较自身的 priority 值和 targetPriority 值来决定是否参加本轮的 Leader 选举投票。所以，一组 Raft 节点组成的集群在刚启动运行的阶段，priority 值最大的节点（上面例子中 160 的那个节点）必然会优先被选择成为这个集群中 Leader 角色的节点向外提供读和写的服务。\n2.2 SOFAJRaft 优先级选 …","date":1588759200,"description":"继源码解析系列后，推出特性解析系列，本文为 SOFAJRaft 特性解析第一篇，主要介绍 SOFAJRaft 在 Leader 选举过程中的重要优化方案—一种半确定性的优先级选举机制。","dir":"blog/sofa-jraft-priority-election/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d867df257326471e46ce05ed548f72e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-priority-election/","publishdate":"2020-05-06T18:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-jraft-priority-election/","summary":"SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFAJRaft 特性解析"],"title":"蚂蚁金服 SOFAJRaft 优先级选举剖析 | 特性解析","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-priority-election/","wordcount":5415},{"author":"敖小剑","categories":"Service Mesh","content":" 前言 关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做一个资料的整理和汇总，结合个人的理解给出一些看法。另外在本文最后，介绍蚂蚁金服在 Service Mesh 和 API Gateway 融合的这个最新领域的一些开创性的实践和探索，希望给大家一个更有体感的认知。\n 备注1：为了节约篇幅，我们将直奔主题，假定读者对 Service Mesh 和 API Gateway 已有基本的了解。 备注2: 这边文章更关注于梳理整个脉络，内容不会展开的特别细，尤其是其他文章已经详细阐述的部分。如果您在浏览本文之后，还想更深入的了解细节，请继续阅读文章最后的参考资料和推荐阅读。\n 原本清晰的界限：定位和职责 首先，Service Mesh 和 API Gateway 在功能定位和承担的职责上有非常清晰的界限：\n Service Mesh：微服务的网络通信基础设施，负责（系统内部的）服务间的通讯； API Gateway： 负责将服务以 API 的形式暴露（给系统外部），以实现业务功能； 如上图所示：\n从功能和职责上说：\n 位于最底层的是拆分好的原子微服务，以服务的形式提供各种能力； 在原子微服务上是（可选的）组合服务，某些场景下需要将若干微服务的能力组合起来形成新的服务； 原子微服务和组合服务部署于 系统内部，在采用 Service Mesh 的情况下，由 Service Mesh 提供服务间通讯的能力； API Gateway 用于将系统内部的这些服务暴露给 系统外部，以 API 的形式接受外部请求； 从部署上说：\n Service Mesh 部署在系统内部：因为原子微服务和组合服务通常不会直接暴露给外部系统； API Gateway 部署在系统的边缘：一方面暴露在系统之外，对外提供 API 供外部系统访问；一方面部署在系统内部，以访问内部的各种服务。 在这里引入两个使用非常广泛的术语：\n 东西向通讯：指服务间的相互访问，其通讯流量在服务间流转，流量都位于系统内部； 南北向通讯：指服务对外部提供访问，通常是通过 API Gateway 提供的 API 对外部保罗，其通讯流量是从系统外部进入系统内部； 解释一下“东西南北”的由来：如上图所示，通常在地图上习惯性的遵循“上北下南，左东右西”的原则。\n 总结：Service Mesh 和 API Gateway 在功能和职责上分工明确，界限清晰。但如果事情就这么结束，也就不会出现 Service Mesh 和 API Gateway 关系的讨论了，自然也不会有本文。\n问题的根源在哪里？\n 强烈推荐阅读：附录中 Christian Posta 的文章 \u0026amp;ldquo;Do I Need an API Gateway if I Use a Service Mesh?\u0026amp;ldquo;对此有深度分析和讲解。\n 哲学问题：网关访问内部服务，算东西向还是南北向？ 如下图所示，图中黄色的线条表示的是 API Gateway 访问内部服务：\n问题来了，从流量走向看：这是外部流量进入系统后，开始访问对外暴露的服务，应该属于“南北向”通讯，典型如上图的画法。但从另外一个角度，如果我们将 API Gateway 逻辑上拆分为两个部分，先忽略对外暴露的部分，单独只看 API Gateway 访问内部服务的部分，这时可以视 API Gateway 为一个普通的客户端服务，它和内部服务的通讯更像是“东西向”通讯：\n所以，API Gateway 作为一个客户端访问内部服务时，到底算南北向还是东西向，就成为一个哲学问题：完全取决于我们如何看待 API Gateway ，是作为一个整体，还是逻辑上分拆为对内对外两个部分。\n这个哲学问题并非无厘头，在 API Gateway 的各种产品中，关于如何实现 “API Gateway 作为一个客户端访问内部服务” ，就通常分成两个流派：\n 泾渭分明：视 API Gateway 和内部服务为两个独立事物，API Gateway 访问内部服务的通讯机制自行实现，独立于服务间通讯的机制； 兼容并济：视 API Gateway 为一个普通的内部服务的客户端，重用其内部服务间通讯的机制； 而最终决策通常也和产品的定位有关：如果希望维持 API Gateway 的独立产品定位，希望可以在不同的服务间通讯方案下都可以使用，则通常选择前者，典型如 Kong；如果和服务间通讯方案有非常深的渊源，则通常选择后者，典型如 Spring Cloud 生态下的 Zuul 和 SpringCloud Gateway。\n但无论选择哪个流派，都改变不了一个事实，当 “API Gateway 作为一个客户端访问内部服务” 时，它的确和一个普通内部服务作为客户端去访问其他服务没有本质差异：服务发现、负载均衡、流量路由、熔断、限流、服务降级、故障注入、日志、监控、链路追踪、访问控制、加密、身份认证\u0026amp;hellip;\u0026amp;hellip; 当我们把网关访问内部服务的功能一一列出来时，发现几乎所有的这些功能都是和服务间调用重复。\n这也就造成了一个普遍现象：如果已有一个成熟的服务间通讯框架，再去考虑实现 API Gateway，重用这些重复的能力就成为自然而然的选择。典型如前面提到的 Spring Cloud 生态下的 Zuul 以及后面开发的 Spring Cloud Gateway，就是以重用类库的方式实现了这些能力的重用。\n这里又是一个类似的哲学问题：当 “API Gateway 作为一个客户端访问内部服务” 时，它以重用类库的方式实现了代码级别的能力重用，相当于自行实现了一个和普通服务间通讯方案完全一样的客户端，那这个“客户端”发出来的流量算东西向还是南北向？\n答案不重要。\nSidecar：真正的重合点 在进入 Service Mesh 时代之后，Service Mesh 和 API Gateway 的关系开始是这样：\n 功能和职责清晰划分； 客户端访问服务的功能高度重叠； 此时两者的关系很清晰，而且由于当时 Service Mesh 和 API Gateway 是不同的产品，两者的重合点只是在功能上。\n而随着时间的推移，当 Service Mesh 产品和 API Gateway 产品开始出现相互渗透时，两者的关系就开始变得暧昧。\n在 Service Mesh 出现之后，如何为基于 Service Mesh 的服务选择合适的 API Gateway 方案，就慢慢开始提上日程，而其中选择重用 Service Mesh 的能力也自然成为一个探索的方向，并逐步出现新式 API Gateway 产品，其想法很直接：\n如何融合东西向和南北向的通讯方案？\n其中的一个做法就是基于 Service Mesh 的 Sidecar 来实现 API Gateway，从而在南北向通讯中引入 Service Mesh 这种东西向通讯的方案。这里我们不展开细节，我这里援引一个图片(鸣谢赵化冰同学)来解释这个方案的思路：\n这个时候 Service …","date":1588143600,"description":"Service Mesh 和 API Gateway 之间的关系，是“泾渭分明”还是“兼容并进”？","dir":"blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"17986a3e65f4db0f66b6ba707cf27a40","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","publishdate":"2020-04-29T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","summary":"前言 关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做","tags":["Service Mesh","API Gateway "],"title":"Service Mesh 和 API Gateway 关系深度探讨","type":"blog","url":"/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","wordcount":5306},{"author":"卫恒","categories":"SOFATracer","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。\n 本文根据 SOFAChannel#15 直播分享整理，主题：分布式链路组件 SOFATracer 埋点机制解析。\n大家好，我是宋国磊，花名卫恒，是 SOFATracer 的开源负责人。今天要和大家分享的是分布式链路组件 SOFATracer 埋点机制解析，将通过具体 Demo 演示快速上手 SOFATracer，同时介绍 SOFATracer 功能点，并详细介绍其核心关键「埋点机制」的原理。\nSOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFATracer：https://github.com/sofastack/sofa-tracer\nSOFATracer 作为 SOFAStack 中的分布式链路组件，也伴随着 SOFAStack 走过了两年的时间，在此首先对两年来对 SOFATracer 保持关注并且参与社区建设的同学表示感谢，也希望大家能够继续关注 SOFAStack 的发展，也欢迎更多的同学加入到 SOFAStack 的社区参与中来。\n今天的分享内容主要将会围绕以下三个部分展开：\n SOFATracer 功能点详细介绍； SOFATracer 埋点机制原理详解； 快速上手 SOFATracer 演示； 关于 SOFATracer 更多的问题也欢迎在 Github 上跟我们交流。\nSOFATracer 简介 首先简单介绍一下 SOFATracer。上图展示的是 SOFATracer 目前所包括的基本能力和所支持的插件。下面虚线框中绿色背景部分，是 SOFATracer 提供的基本功能，具体可以参考官方文档描述。上面虚线框中是 SOFATracer 目前所支持的组件，大概分了以下几种类型：客户端、Web、数据存储、消息、RPC、Spring Cloud。\n之前社区也发起过 剖析 | SOFATracer 框架 的源码解析系列文章，在此系列中对 SOFATracer 所提供的能力及实现原理都做了比较全面的分析，有兴趣的同学可以看下。\n今天主要聊一下埋点机制。不同组件的埋点机制也是有很大的差异，SOFATracer 是如何实现对上述组件进行埋点的，下面就详细分析下不同组件的埋点机制。\n埋点机制 目前 SOFATracer 已经支持了对以下开源组件的埋点支持：Spring MVC、RestTemplate、HttpClient、OkHttp3、JDBC、Dubbo(2.6\u0026amp;frasl;2.7)、SOFARPC、Redis、MongoDB、Spring Message、Spring Cloud Stream (基于 Spring Message 的埋点)、RocketMQ、Spring Cloud FeignClient、Hystrix。\n 大多数能力提供在 3.x 版本，2.x 版本从官方 issue 中可以看到后续将不再继续提供新的功能更新；这也是和 SpringBoot 宣布不再继续维护 1.x 版本有关系。\n 标准 Servlet 规范埋点原理 SOFATracer 支持对标准 Servlet 规范的 Web MVC 埋点，包括普通的 Servlet 和 Spring MVC 等，基本原理就是基于 Servelt 规范所提供的 javax.servlet.Filter 过滤器接口扩展实现。\n 过滤器位于 Client 和 Web 应用程序之间，用于检查和修改两者之间流过的请求和响应信息。在请求到达 Servlet 之前，过滤器截获请求。在响应送给客户端之前，过滤器截获响应。多个过滤器形成一个 FilterChain，FilterChain 中不同过滤器的先后顺序由部署文件 web.xml 中过滤器映射的顺序决定。最先截获客户端请求的过滤器将最后截获 Servlet 的响应信息。\n Web 应用程序一般作为请求的接收方，在 SOFATracer 中应用是作为 Server 存在的，其在解析 SpanContext 时所对应的事件为 sr (server receive)。\nSOFATracer 在 sofa-tracer-springmvc-plugin 插件中解析及产生 Span 的过程大致如下：\n Servlet Filter 拦截到 request 请求； 从请求中解析 SpanContext； 通过 SpanContext 构建当前 MVC 的 Span； 给当前 Span 设置 tag、log； 在 Filter 处理的最后，结束 Span； 当然这里面还会设计到其他很多细节，比如给 Span 设置哪些 tag 属性、如果处理异步线程透传等等。本次分享就不展开细节探讨，有兴趣的同学可以自行阅读代码或者和我们交流。\nDubbo 埋点原理 Dubbo 埋点在 SOFATracer 中实际上提供了两个插件，分别用于支持 Dubbo 2.6.x 和 Dubbo 2.7.x；Dubbo 埋点也是基于 Filter ，此 Filter 是 Dubbo 提供的 SPI 扩展-调用拦截扩展 机制实现。\n像 Dubbo 或者 SOFARPC 等 RPC 框架的埋点，通常需要考虑的点比较多。首先， RPC 框架分客户端和服务端，所以在埋点时 RPC 的客户端和服务端必须要有所区分；再者就是 RPC 的调用方式包括很多种，如常见的同步调用、异步调用、oneway 等等，调用方式不同，所对应的 Span 的结束时机也不同，重要的是基本所有的 RPC 框架都会使用线程池用来发起和处理请求，那么如何保证 SOFATracer 在多线程环境下不串也很重要。\n另外 Dubbo 2.6.x 和 Dubbo 2.7.x 在异步回调处理上差异比较大，Dubbo 2.7.x 中提供了 onResponse 方法（后面又升级为 Listener，包括 onResponse 和 onError 两个方法）；而 Dubbo 2.6.x 中则并未提供相应的机制，只能通过对 Future 的硬编码处理来完成埋点和上报。\n 这个问题 Zipkin Brave 对 Dubbo 2.6.x 的埋点时其实也没有考虑到，在做 SOFATracer 支持 Dubbo 2.6.x 时发现了这个 bug，并做了修复。\n SOFATracer 中提供的 DubboSofaTracerFilter 类：\n@Activate(group = { CommonConstants.PROVIDER, CommonConstants.CONSUMER }, value = \u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;, order = 1) public class …","date":1588068000,"description":"SOFATracer 埋点机制解析直播文字回顾。","dir":"blog/sofa-channel-15-retrospect/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4e4c9d4539119eb12ece83c8228ee4a3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-15-retrospect/","publishdate":"2020-04-28T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-channel-15-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["SOFATracer","SOFAChannel"],"title":"分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-15-retrospect/","wordcount":4579},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#16：不得不说的云原生隔离性\n 活动时间：5 月 21 日周四晚 7 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#16：不得不说的云原生隔离性 在云原生时代，容器和 Kubernetes 在日常工作和实际生产中越来越普遍，随之而来的隔离性问题在不断被提起同时也受到了越来越多的关注。\nKata Containers 是 OpenStack 基金会旗下又独立于 OpenStack 项目之外的开放基础设施顶级项目，旨在把虚拟机的安全隔离优势与容器的速度和可管理性统一起来，为用户提供安全快速易用的容器基础设施。\n本期直播，将邀请 Kata Containers 维护者彭涛（花名：巴德）带我们走近云原生的一项基础设施 \u0026amp;ndash; Kata Containers，看它是如何在云原生框架下解决容器隔离性问题的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1197\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 不得不说的云原生隔离性 卫恒 SOFATracer 开源负责人\n你将收获 从 Kubernetes Pod 说起，经典容器场景下的 Pod 分享； 共享内核存在的问题以及解决办法； 上帝说，要有光；我们说，要有 Kata； The speed of containers, the security of VMs； Kata Containers 特性大放送； What? 你刚说过增加一个 VM 间接层的问题？ 嘉宾 SOFAGirl 主持人 卫恒 SOFATracer 开源负责人 ","date":1588057200,"description":"5 月 21 日周四晚 7 点，线上直播第 16 期。","dir":"activities/sofa-channel-16/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4756bc76f718255ad5fc4fd172a706b4","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-16/","publishdate":"2020-04-28T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-16/","summary":"概要 活动主题：SOFAChannel#16：不得不说的云原生隔离性 活动时间：5 月 21 日周四晚 7 点 活动形式：线上直播 报名方式：戳这里 介绍 | SOFAChannel \u0026lt;SOFA:Channel/\u0026gt; 有","tags":["SOFAChannel","Kata Container"],"title":"SOFAChannel#16：不得不说的云原生隔离性","type":"activities","url":"/sofastack.tech/activities/sofa-channel-16/","wordcount":568},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n**SOFAStack 官网: **https://www.sofastack.tech\n**SOFAStack: **https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@闫圣哲 提问：\n 请问：关于 SOFAJRaft 线性读，为什么读失败了要应用到状态机呢，是为了拉齐 readindex 吗？\n A：线性一直读不走 raft log （应该是你说的状态机的意思），在 rheakv 里面，如果线性一直读失败了，那么会和write操作一样通过 raft log 达成一致再走状态机读，这是个兜底策略，否则 readIndex 失败了能怎么办呢？ 另一只方式就是直接返回用户失败了。可以具体看一下「JRaft 实现细节解析之高效的线性一致读」这一小节的内容～\nhttps://www.sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFA 项目进展 本周发布详情如下：\n发布 Seata v1.2.0 版本，主要变更如下：\n 支持 XA 事务模式； 支持事务传播机制； 支持批量更新和删除 SQL； TCC 模式支持 hsf 服务调用； Saga 模式性能优化默认不注册分支事务等； 本次发布涉及代码改动文件数 324个，代码行 +11,907 −3,437。 此版本在 feature 和稳定性相对 1.1.0 版本都有较大幅度增强，强烈推荐大家验证和升级到此版本。 详细发布报告：https://seata.io/zh-cn/blog/download.html\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 社区直播报名 本期为第一期 Service Mesh Virtual Meetup 线上系列直播第一期，邀请了四位来自不同公司的嘉宾，从四个角度对 Service Mesh 的应用实践展开分享。\n本次线上 meetup 分享涵盖 Service Mesh 的可观察性和生产实践。为大家介绍 Service Mesh 中的可观察性与传统微服务中可观察性的区别，如何使用 SkyWalking 来观测 Service Mesh，还有来自百度和陌陌的 Service Mesh 生产实践。\n本系列采用线上直播的形式，从 5 月 6 日开始到 5 月 14 日，每周三、周四晚上 19:00-20:00 我们相约进行一个主题分享。\n观看直播方式：保存图片扫码 或 点击“这里”，关注直播间，即可观看直播\n","date":1587722400,"description":"【04/20-04/24】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200424/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"455d22426589849b45f59083c641ee7c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200424/","publishdate":"2020-04-24T18:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200424/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 系列直播预告、Seata 发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200424/","wordcount":1092},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析\n 活动时间：4 月 23 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1167\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 分布式链路组件 SOFATracer 埋点机制解析 卫恒 SOFATracer 开源负责人\n你将收获 带你快速上手 SOFATracer； SOFATracer 功能点详细介绍； SOFATracer 埋点机制原理详解； 嘉宾 SOFAGirl 主持人 卫恒 SOFATracer 开源负责人 ","date":1587114000,"description":"4 月 23 日周四晚 7 点，线上直播第 15 期。","dir":"activities/sofa-channel-15/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e1323556a7e34b0937a8d3c1f6815a77","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-15/","publishdate":"2020-04-17T17:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-15/","summary":"概要 活动主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 活动时间：4 月 23 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍 |","tags":["SOFAChannel","SOFATracer"],"title":"SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-15/","wordcount":442},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@杨俊 提问：\n AT 模式下，当 seata-server 挂掉之后，有未完成的全局事务还在 undo_log 表中，这里有两个问题问一下： 1. seata-server 再次重启后，之前未完成的全局事务偶尔会出现回滚失败的问题，就是一直重试，但始终回滚失败，这个问题如何解决？ 1. seata-server 再次重启后，大多数情况下会成功回滚，但是等待时间过长，感觉要至少3-5分钟才会回滚，这期间涉及到的相关业务服务无法处理其他请求，直至之前的未完成全局事务成功回滚了，才能处理其他请求，请问这个问题如何解决，还有回滚时间在哪里配置能够缩短？ ※上述两个问题都是基于 seata-sample 产生的。\n A：1. 要确认下客户端日志中回滚失败的原因，重启后会恢复重启前未完成的事务。一般是出现脏写数据了，需要人工订正。如果单纯跳过可以删除 server 或 undo_log 对应记录。 2. server.recovery.rollbackingRetryPeriod , 是不是重启前未完成事务过多？\n 好的，谢谢。 1. seata-sample 中三个服务，Account、Order 回滚成功，Storage 回滚失败，然后 seata-server 就一直反复重试，seata 和 storage 及其他服务重启也无用，然后手工将日志删除，依然不停重试，最后重启 seata 服务，系统把删掉的日志又给重写到日志表了，但是 log_status 为1，至此不再重试，但是事务未能成功回滚。 1. 重启未完成的事务只有那么三个而已，并不多。\n A：问题1，你还是要看下回滚失败的原因，客户端日志会打印。 问题2，你提个 issue ，我们排查下。\n2、@吕布 提问：\n 请教一下, AT 下分支事务提交后释放资源, 虽然资源释放了, 但别的事务操作它时还是被全局锁了, 这种释放的好处体现在哪些方面？ A：即使你数据库本地事务也是排队执行的，全局锁是 AT 模式的排队机制，所以如果是相同数据主键的这个与连接无关。释放连接是因为数据库连接资源是宝贵的，不会因为连接池连接数不够导致的其他数据无关的事务得不到执行，从更大的层面认为是一定程度提高了吞吐。\n 明白了，一方面就是说提高吞吐, 然后一方面是避免本地事务的间隙锁和表锁, 导致其他不相关数据被锁, 可以说锁粒度变小了。谢谢。\n Seata：https://github.com/seata/seata\nSOFATracerLab 系列阅读 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览 | 剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码分析 | 剖析 蚂蚁金服分布式链路跟踪组件链路透传原理与SLF4J MDC的扩展能力分析 | 剖析 蚂蚁金服分布式链路跟踪组件采样策略和源码 | 剖析 蚂蚁金服分布式链路跟踪组件埋点机制 | 剖析 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.1 版本，主要变更如下：\n multi raft group 之间共享 timer 和 scheduler 等较重的线程资源，优化 multi group 场景中的多余资源占用； 提供 RPC adapter，用户可基于 SPI 扩展不同的 RPC 实现； 正式提供稳定的 RocksDBSegmentLogStorage，适合 value 较大的数据存储； SOFABolt 升级到 1.6.1，支持 SSL 以及具有更好的小数据包传输能力； 引入一个新的数据结构 segment list 来解决 LogManager 中过多的 log memory copy； 采纳 nacos 建议，对 raft Task 增加 join API； 修复 learner 启动晚于 leader 选举成功时无法复制日志的 bug； 致谢（排名不分先后） @jovany-wang 、@SteNicholas 、@zongtanghu 、@OpenOpened\n详细发布报告：https://github.com/sofastack/sofa-jraft/issues/420\n社区直播报名 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n本期直播将通过具体 Demo 带你快速上手 SOFATracer，同时将介绍 SOFATracer 具体功能，并详细介绍其核心关键「埋点机制」的原理。\n 主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 时间：2020年4月23日（周四）19:00-20:00 嘉宾：卫恒 SOFATracer 开源负责人 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1587106800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200417/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1bb16db78404cb9d09dd18ec48374246","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200417/","publishdate":"2020-04-17T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200417/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 直播预告、SOFAJRaft 组件发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200417/","wordcount":1836},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@熊胜 提问：\n 请教个问题，biz 卸载中的关闭 ApplicationContext 这一步是哪里处理的呢？我在 com.alipay.sofa.ark.container.model.BizModel#stop 方法中没看到相应的实现。\n A： biz stop 会发出一个事件，这个时间会被 runtime 拿到处理，可以看下 sofa-boot runtime 里面有处理 biz 卸载事件的 handler。\nSOFAArk：https://github.com/sofastack/sofa-ark\n2、@揭印泉 提问：\n 请问 registry.conf 中的 registry 作用是向 Seata 服务器注册分支事务？\n A：registry 是注册中心，seata server 和 client 都需要的，server 往注册中心注册服务，client 往注册中心找寻 server 服务。\n seata server 和 client 是共用 nacos-config.sh 脚本跑到 Nacos 配置？ 如果他们都配置了 Nacos。\n A：随你，你也可以分开，配置中心没约束，你可以 server 用 nacos，client 用 file，只要读取到即可。\n 服务器端配置了 store.mode=\u0026amp;ldquo;db\u0026amp;rdquo;, 启动参数需要加参数：-m db ?\n A：可以不加，优先级启动参数\u0026amp;gt;配置。\nSeata：https://github.com/seata/seata\nSOFARegistryLab 系列阅读 服务注册中心如何实现 DataServer 平滑扩缩容 | SOFARegistry 解析 服务注册中心数据一致性方案分析 | SOFARegistry 解析 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFAChannel 线上直播合集 SOFAChannel#14：云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 SOFAChannel#13：云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 SOFAChannel#12：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 SOFATracer v3.0.12 版本，主要变更如下：\n 2个 Dubbo 插件融合, 新的用户请直接使用 sofa-tracer-dubbo-common-plugin； 修复 Dubbo 插件传递错误 spanId 的问题； 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.12\n社区直播报名 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n本期直播将通过具体 Demo 带你快速上手 SOFATracer，同时将介绍 SOFATracer 具体功能，并详细介绍其核心关键「埋点机制」的原理。\n 主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 时间：2020年4月23日（周四）19:00-20:00 嘉宾：卫恒 SOFATracer 开源负责人 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1586509200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200410/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9f805804c54d097bea99536c21da6387","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200410/","publishdate":"2020-04-10T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200410/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 直播预告、SOFARegistry 解析系列合集、线上直播回顾合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200410/","wordcount":1705},{"author":"永鹏","categories":"SOFAChannel","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。\n 本文根据 SOFAChannel#14 直播分享整理，主题：云原生网络代理 MOSN 扩展机制解析。\n大家好，我是今天的讲师永鹏，来自蚂蚁金服，目前主要负责 MOSN 的开发，也是 MOSN 的Committer。今天我为大家分享的是云原生网络代理 MOSN 的扩展机制，希望通过这次分享以后，能让大家了解 MOSN 的可编程扩展能力，可以基于 MOSN 的扩展能力，按照自己实际的业务需求进行二次开发。\n前言 今天我们将从以下几个方面，对 MOSN 的扩展机制进行介绍：\n MOSN 扩展能力和扩展机制的详细介绍； 结合示例对 MOSN 的 Filter 扩展机制与插件扩展机制进行详细介绍； MOSN 后续扩展能力规划与展望； 欢迎大家有兴趣一起共建 MOSN。在本次演讲中涉及到的示例就在我们的 Github 的 examples/codes/mosn-extensions 目录下，大家有兴趣的也可以下载下来运行一下，关于这些示例我们还做了一些小活动，也希望大家可以踊跃参与。\nMOSN：https://github.com/mosn/mosn\nMOSN 简介 MOSN 作为云原生的网络代理，旨在为服务提供多协议、模块化、智能化、安全的代理能力。在实际生产使用中，不同的厂商会有不同的使用场景，通用的网络代理能力面对具体的业务场景会显得有些不足，通常都需要进行二次开发以满足业务需求。MOSN 在核心框架中，提供了一系列的扩展机制和扩展点，就是为了满足需要基于业务进行二次开发的场景，同时 MOSN 提供的部分通用逻辑也是基于扩展机制和扩展点的实现。\n比如通过 MOSN “内置实现”的透明劫持的能力，就是通过 MOSN Filter 机制实现。而要实现消息的代理，则可以通过类似的扩展实现。在通用代理的情况下，可以通过 Filter 机制实现业务的认证鉴权，也可以实现定制的负载均衡逻辑；除了转发流程可以扩展实现以外，MOSN 还可以扩展日志的实现，用于对标已有的日志系统，也可以扩展 XDS 实现定制的配置更新；根据不同的业务场景还会有很多具体的扩展情况，就不在此展开了，有兴趣的可以关注MOSN 社区正在建设的源代码分析系列文章与文档。\nMOSN 作为一款网络代理，在转发链路上的网络层、协议层、转发层，在非转发链路上的配置、日志、Admin API 等都提供了扩展能力，对于协议扩展的部分，有兴趣的可以看一下上期直播讲的 MOSN 多协议机制解析，我们今天将重点介绍一下转发层的 Stream Filter 扩展机制与 MOSN 的插件机制。\nStream Filter 机制 在实际业务场景中，在转发请求之前或者回写响应之前，都可能需要对请求/响应做一些处理，如判断是否需要进行转发的认证/鉴权，是否需要限流，又或者需要对请求/响应做一些具有业务语义的记录，需要对协议进行转换等。这些场景都与具体的业务高度耦合，是一个典型的需要进行二次开发的情况。MOSN 的 Stream Filter 机制就是为了满足这样的扩展场景所设计的，它也成为目前 MOSN 扩展中使用频率最高的扩展点。\n在目前的内置 MOSN 实现中，Stream Filter 机制暂时与内置的 network filter: proxy 是绑定的，后面我们也考虑将这部分能力进行抽象，让其他 network filter 也可以复用这部分能力。\n关于 Stream Filter，今天会为大家讲解两个部分的内容： 1. 一个 Stream Filter 包含哪些部分以及在 MOSN 中是如何工作的； 2. 通过一个 Demo 演示来加深对 Stream Filter 的实现与应用；\n一个完整的 Stream Filter 一个完整的 StreamFilter，包含三个部分的内容：\n 一个 StreamFilter 对象，存在于每一个请求/响应当中，在 MOSN 收到请求的时候发挥作用，我们称为 ReceiverFilter，在 MOSN 收到响应时发挥作用，我们称为 SenderFilter。一个 StreamFilter 可以是其中任意一种，也可以是两种都是； 一个 StreamFilterFactory 对象，用于 MOSN 在每次收到请求时，生成 StreamFilter 对象。在 Listener 配置解析时，一个 StreamFilter 的配置会生成一个其对于的 StreamFilterFactory。同一个 StreamFilter 在不同的 Listener 下可能对应不同的 StreamFilterFactory，但是也有的特殊情况下，StreamFilterFactory 可能需要实现为单例； 一个 CreateStreamFilterFactory 方法，配置解析时生成 StreamFilterFactory 就是调用它； Stream Filter 在 MOSN 中是如何工作的 接下来，我们看下 Stream Filter 在 MOSN 中是如何工作的。\n当 MOSN 经过协议解析，收到一个完整的请求时，会创建一个 Stream。此时收到请求的 Listener 中每存在 StreamFilterFactory，就会生成一个 StreamFilter 对象，随后进入到 proxy 流程。\n进入 proxy 流程以后，如果存在 ReceiverFilter，那么就会执行对应的逻辑，ReceiverFilter 包括两个阶段，“路由前”和“路由后”，在每个 Filter 处理完成以后，会返回一个状态，如果是 Stop 则会中止后续尚未执行的 ReceiverFilter，通常情况下，返回 Stop 状态的 Filter 都会回写一个响应。如果是 Continue 则会执行下一个 ReceiverFilter，直到本阶段的 ReceiverFilter 都执行完成或中止；路由前阶段的 ReceiverFIlter 执行完成后，就会执行路由后阶段，其逻辑和路由前一致。如果是正常转发，那么随后 MOSN 会收到一个响应或者发现其他异常直接回写一个响应，此时就会进入到 SenderFilter 的流程中，完成 SenderFilter 的处理。SenderFilter 处理完成以后，MOSN 会写响应给 Client，并且完成最后的收尾工作，收尾工作包括一些数据的回收、日志的记录，以及 StreamFilter 的“销毁”（调用 OnDestroy）。\nStream Filter Demo 对 Stream Filter 有了一个基本的认识以后，我们来看一个实际的 Demo 代码来看下如何实现一个 StreamFilter 并且让它在 MOSN 中发挥作用。\n按照刚才我们的介绍，一个 StreamFIlter 要包含三部分：Filter、Factory、CreateFactory。\n 首先我们实现一个 Filter，其逻辑是模拟一个鉴权的 Filter： …","date":1586437200,"description":"本文根据 SOFAChannel#14 直播分享整理，主题：云原生网络代理 MOSN 扩展机制解析。","dir":"blog/sofa-channel-14-retrospect/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"54f04c153ed4827819de6a6716ad46e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-14-retrospect/","publishdate":"2020-04-09T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-14-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["SOFAChannel","MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-14-retrospect/","wordcount":6144},{"author":"404P","categories":"SOFARegistry ","content":" SOFAStack（Scalable Open Financial Architecture Stack ）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。  SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》最后一篇，本篇作者404P(花名岩途)。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n前言 在微服务架构体系下，服务注册中心致力于解决微服务之间服务发现的问题。在服务数量不多的情况下，服务注册中心集群中每台机器都保存着全量的服务数据，但随着蚂蚁金服海量服务的出现，单机已无法存储所有的服务数据，数据分片成为了必然的选择。数据分片之后，每台机器只保存一部分服务数据，节点上下线就容易造成数据波动，很容易影响应用的正常运行。本文通过介绍 SOFARegistry 的分片算法和相关的核心源码来展示蚂蚁金服是如何解决上述问题的。~~\n服务注册中心简介 在微服务架构下，一个互联网应用的服务端背后往往存在大量服务间的相互调用。例如服务 A 在链路上依赖于服务 B，那么在业务发生时，服务 A 需要知道服务 B 的地址，才能完成服务调用。而分布式架构下，每个服务往往都是集群部署的，集群中的机器也是经常变化的，所以服务 B 的地址不是固定不变的。如果要保证业务的可靠性，服务调用者则需要感知被调用服务的地址变化。\n图1 微服务架构下的服务寻址\n既然成千上万的服务调用者都要感知这样的变化，那这种感知能力便下沉成为微服务中一种固定的架构模式：服务注册中心。\n图2 服务注册中心\n服务注册中心里，有服务提供者和服务消费者两种重要的角色，服务调用方是消费者，服务被调方是提供者。对于同一台机器，往往兼具两者角色，既被其它服务调用，也调用其它服务。服务提供者将自身提供的服务信息发布到服务注册中心，服务消费者通过订阅的方式感知所依赖服务的信息是否发生变化。\nSOFARegistry 总体架构 SOFARegistry 的架构中包括4种角色：Client、Session、Data、Meta，如图3所示：\n图3 SOFARegistry 总体架构\n Client 层 应用服务器集群。Client 层是应用层，每个应用系统通过依赖注册中心相关的客户端 jar 包，通过编程方式来使用服务注册中心的服务发布和服务订阅能力。\n Session 层 Session 服务器集群。顾名思义，Session 层是会话层，通过长连接和 Client 层的应用服务器保持通讯，负责接收 Client 的服务发布和服务订阅请求。该层只在内存中保存各个服务的发布订阅关系，对于具体的服务信息，只在 Client 层和 Data 层之间透传转发。Session 层是无状态的，可以随着 Client 层应用规模的增长而扩容。\n Data 层 数据服务器集群。Data 层通过分片存储的方式保存着所用应用的服务注册数据。数据按照 dataInfoId（每一份服务数据的唯一标识）进行一致性 Hash 分片，多副本备份，保证数据的高可用。下文的重点也在于随着数据规模的增长，Data 层如何在不影响业务的前提下实现平滑的扩缩容。\n Meta 层 元数据服务器集群。这个集群管辖的范围是 Session 服务器集群和 Data 服务器集群的服务器信息，其角色就相当于 SOFARegistry 架构内部的服务注册中心，只不过 SOFARegistry 作为服务注册中心是服务于广大应用服务层，而 Meta 集群是服务于 SOFARegistry 内部的 Session 集群和 Data 集群，Meta 层能够感知到 Session 节点和 Data 节点的变化，并通知集群的其它节点。\nSOFARegistry 如何突破单机存储瓶颈 在蚂蚁金服的业务规模下，单台服务器已经无法存储所有的服务注册数据，SOFARegistry 采用了数据分片的方案，每台机器只保存一部分数据，同时每台机器有多副本备份，这样理论上可以无限扩容。根据不同的数据路由方式，常见的数据分片主要分为两大类：范围分片和 Hash（哈希）分片。\n图4 数据分片\n 范围分片 每一个数据分片负责存储某一键值区间范围的值。例如按照时间段进行分区，每个小时的 Key 放在对应的节点上。区间范围分片的优势在于数据分片具有连续性，可以实现区间范围查询，但是缺点在于没有对数据进行随机打散，容易存在热点数据问题。\n Hash （哈希）分片 Hash 分片则是通过特定的 Hash 函数将数据随机均匀地分散在各个节点中，不支持范围查询，只支持点查询，即根据某个数据的 Key 获取数据的内容。业界大多 KV（Key-Value）存储系统都支持这种方式，包括 cassandra、dynamo、membase 等。业界常见的 Hash 分片算法有哈希取模法、一致性哈希法和虚拟桶法。\n哈希取模 哈希取模的 Hash 函数如下：\nH(Key) = hash(key) mod K; 这是一个 key-machine 的函数。key 是数据主键，K 是物理机数量，通过数据的 key 能够直接路由到物理机器。当 K 发生变化时，会影响全体数据分布。所有节点上的数据会被重新分布，这个过程是难以在系统无感知的情况下平滑完成的。\n图5 哈希取模\n一致性哈希 分布式哈希表（DHT）是 P2P 网络和分布式存储中一项常见的技术，是哈希表的分布式扩展，即在每台机器存储部分数据的前提下，如何通过哈希的方式来对数据进行读写路由。其核心在于每个节点不仅只保存一部分数据，而且也只维护一部分路由，从而实现 P2P 网络节点去中心化的分布式寻址和分布式存储。DHT 是一个技术概念，其中业界最常见的一种实现方式就是一致性哈希的 Chord 算法实现。\n 哈希空间 一致性哈希中的哈希空间是一个数据和节点共用的一个逻辑环形空间，数据和机器通过各自的 Hash 算法得出各自在哈希空间的位置。\n图6 数据项和数据节点共用哈希空间\n图7是一个二进制长度为5的哈希空间，该空间可以表达的数值范围是0～31（2^5），是一个首尾相接的环状序列。环上的大圈表示不同的机器节点（一般是虚拟节点），用 $$Ni$$ 来表示，$$i$$ 代表着节点在哈希空间的位置。例如，某个节点根据 IP 地址和端口号进行哈希计算后得出的值是7，那么 N7 则代表则该节点在哈希空间中的位置。由于每个物理机的配置不一样，通常配置高的物理节点会虚拟成环上的多个节点。\n图7 长度为5的哈希空间\n环上的节点把哈希空间分成多个区间，每个节点负责存储其中一个区间的数据。例如 N14 节点负责存储 Hash 值为8～14范围内 …","date":1586340000,"description":"本文介绍 SOFARegistry 分片算法和相关核心源码来展示蚂蚁金服是如何解决数据分片带来的节点上下线数据波动的问题。","dir":"blog/sofa-registry-dataserver-smooth-expansion-contraction/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"35c77b7278ad2675b56540b1f97ecf8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","publishdate":"2020-04-08T18:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","summary":"SOFAStack（Scalable Open Financial Architecture Stack ）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里","tags":["SOFARegistry ","剖析 | SOFARegistry 框架","SOFALab"],"title":"蚂蚁金服服务注册中心如何实现 DataServer 平滑扩缩容 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","wordcount":6179},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@王磊 提问：\n SOFARPC 注册的 Dubbo 服务和通过 Dubbo 组件注册的服务可以互通的吧？\n A：可以的， Dubbo 是桥接模式。\n 这个怎么配置的。现在注册的 Dubbo 服务 generic=false。 A：现在只支持泛化调用不支持泛化服务，可以关注一下这个 Issue，后期会排期做，也欢迎共建。 https://github.com/sofastack/sofa-rpc/issues/894\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@黄振祥 提问：\n 使用 SOFAStack 快速构建微服务的 Demo 时遇到的一些问题，可以怎么解决呢？ https://github.com/sofastack-guides/kc-sofastack-demo\n A：可以详细看一下这个 issue： https://github.com/sofastack-guides/kc-sofastack-demo/issues/9\n3、@哈哈哈 提问：\n AT 和 Saga 有什么区别吗，AT 我感觉是自动的 Saga。\n A：也可以这么说，Saga 框架上没有加锁，AT 有加锁，事实上 Seata Saga 是一个具备“服务编排”和“Saga 分布式事务”能力的产品。\n4、@全 提问：\n 麻烦问一下，Seata TCC 只支持 Dubbo、SOFARPC 吗？\n A：还有 local，其他的 rpc 框架可以基于 local 包装一下或者扩展下 parser，也欢迎大家贡献。\n 如果通过 spring-cloud 整合的话需要扩展这个 Parser 是吧？\n A：是的，但是像 resttemplate 这种 rest 请求没办法走 parser，需要你 local 包一下。 Seata：https://github.com/seata/seata\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n发布 SOFA MOSN v0.11.0 版本，主要变更如下：\n 重构 XProtocol Engine，优化了协议层的实现； 支持 Listener Filter 的扩展，基于 Listener Filter 重新实现了透明劫持能力； 优化了 LDS 接口，修改了路由配置结构，完善了变量机制； 完善了 TraceLog 的实现； Bug Fix； 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/v0.11.0\n社区直播报名 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n本期直播包含 Demo，可以先下载 Demo，提前体验 MOSN 拓展机制的使用（报名页面有详细 Demo 链接）。\n 主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 时间：2020年4月9日（下周四）19:00-20:00 嘉宾：永鹏 蚂蚁金服高级开发工程师、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1585908000,"description":"【03/30-04/03】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200403/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e109585632269dffffd2819dd121da2b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200403/","publishdate":"2020-04-03T18:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200403/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告 \u0026 发布更新、Service Mesh 落地实践解析合辑","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200403/","wordcount":1376},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@John Deng 提问：\n 现在 MOSN 对 Dubbo 协议支持怎样？\n A：这儿，协议支持了：https://github.com/mosn/mosn/tree/master/pkg/protocol/xprotocol/dubbo 完整的支持，我们已经创建了 Dubbo WG 专门来做这个事情，https://github.com/mosn/community/blob/master/wg-dubbo.md\n 已经生产就绪了吗？\n A：如果是 Dubbo 的话，目前还没有生产可用，主要是相关生态还没对齐，我们正在推进 Dubbo WG kick off，有兴趣可以加入一起完善。 如果指 MOSN 的话，我们去年双11已经线上部署几十万容器，生产可用。 MOSN：https://github.com/mosn/mosn\n2、@Liang 提问：\n SOFAJRaft 的 Leader 节点执行完状态机，把这次的 index 提交之后，什么时候通知的 Follower 节点也提交呢？ 我看现象是 Follower 也立刻跟着提交了，但是这块代码没有找到。想问下具体是怎么实现的，谢谢~\n A：Leader 会往 Follower 发送 lastCommittedIndex， 详情见：\ncom.alipay.sofa.jraft.core.NodeImpl#handleAppendEntriesRequest com.alipay.sofa.jraft.core.BallotBox#setLastCommittedIndex SOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@琦玉 提问：\n 这种情况下，状态机怎么确定是执行回滚，还是执行重试呢？ A：这个是由开发者决定的。 Server 事务恢复的逻辑是：\n 当提交失败时，重试提交； 补偿失败时，重试补偿； 如果超时默认是进行重试补偿，如果配置了这个\u0026amp;rdquo;RecoverStrategy\u0026amp;rdquo;: \u0026amp;ldquo;Forward\u0026amp;rdquo;则进行重试向前执行； 这个\u0026amp;rdquo;RecoverStrategy\u0026amp;rdquo;: \u0026amp;ldquo;Forward\u0026amp;rdquo;配置是告诉状态机默认的事务恢复策略。如果发现这条事务无法向前，也可以通过手动调状态机“补偿”。\n 这种是否最终成功可能有其它业务上的条件，比如取决于另外一个步骤的成功与否。没法在状态语言里面定义。如果 A 充值成功，事务失败，B 就不能回退，必须重试到最终成功。如果 A 充值失败，事务失败，B 就可以回退。这种具体是要怎么去处理呢？分布式事务内先给用户 A 充值, 然后给用户 B 扣减余额, 如果在给 A 用户充值成功, 在事务提交以前, A 用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了\n A：不允许这样设计，业务流水，必须先扣，再充，必须要遵循“宁可长款，不可短款”的原则。\n 意思是分成两个独立的事务，Saga 模式中不定义在同一个状态机流程里？先把B的扣钱流程执行完，再去执行 A 的充值流程 ？\n A：不是，是在同一个事务里，同一个流程，要先进行扣 B 的款，再给 A 充值，那和如果充值失败，可以回滚 B。\n 假如同时给 B 和 C 充值呢？\n A：那就都向前重试，因为充钱业务上不会失败。\n 如果做重试的话，是不是整个流程其它做回退的动作都要在充值动作之前完成?在重试动作之后的动作都只能做重试?\n A：也不是完全只能这样，要根据业务场景来吧。做一个合理的流程设计。 相关阅读：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 Seata：https://github.com/seata/seata\n本周推荐阅读 Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 SOFARegistry v5.4.2 版本，主要变更如下：\n 修复 cloud 模式推送时客户端 cell 设置错误的问题； 详细发布报告： https://github.com/sofastack/sofa-registry/releases/tag/v5.4.2\n社区直播报名 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n本期直播包含 Demo，可以先下载 Demo，提前体验 MOSN 拓展机制的使用（报名页面有详细 Demo 链接）。\n 主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 时间：2020年4月9日（周四）19:00-20:00 嘉宾：永鹏 蚂蚁金服高级开发工程师、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1585299600,"description":"【03/23-03/27】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-0327/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0c6b194e66eeb4c95efa4260e279bab7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0327/","publishdate":"2020-03-27T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0327/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告、本周直播回顾整理、SOFARegistry 发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0327/","wordcount":1980},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析\n 活动时间：4 月 9 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n欢迎先下载 Demo，提前体验 MOSN 拓展机制的使用，成功完成预习作业—— Demo 完整操作的，有机会获得小礼物哟（记得留下完成的证明，获得方式在直播中公布），我们将在直播中公布答案——进行 Demo 的详细演示。PS：在直播中也会发布闯关任务，完成闯关任务也有机会获得小礼物哟～\nDemo：https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions\nDemo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions\n欢迎了解 MOSN：https://github.com/mosn/mosn\n| 针对人群 对云原生、Service Mesh、网络代理有基本了解，想要了解云原生以及对云原生网络代理 MOSN 有二次开发需求的人群\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：21992058（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1131\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 永鹏 蚂蚁金服高级开发工程师， MOSN Committer\n你将收获 快速了解 MOSN 的多种扩展能力 3 个案例，实际体验 MOSN 扩展能力 多案例多形式，使用 MOSN 实现个性化业务需求 嘉宾 SOFAGirl 主持人 永鹏 蚂蚁金服高级开发工程师， MOSN Committer ","date":1585299600,"description":"4 月 9 日周四晚 7 点，线上直播第 14 期。","dir":"activities/sofa-channel-14/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0e1d5c0ea19ec82218fbf675b891ee5a","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-14/","publishdate":"2020-03-27T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-14/","summary":"概要 活动主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 活动时间：4 月 9 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍","tags":["SOFAChannel","MOSN"],"title":"SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-14/","wordcount":901},{"author":"无钩","categories":"MOSN","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。 本文根据 SOFAChannel#13 直播分享整理，主题：云原生网络代理 MOSN 多协议机制解析。\n 大家好，我是今天的讲师无钩，目前主要从事蚂蚁金服网络代理相关的研发工作，也是 MOSN 的 Committer。今天要和大家分享的是《云原生网络代理 MOSN 多协议机制解析》，并介绍对应的私有协议快速接入实践案例以及对 MOSN 实现多协议低成本接入的设计进行解读。\n我们将按以下顺序进行介绍：\n 多协议机制产生的背景与实践痛点； 常见的协议扩展思路初探； SOFABolt 协议接入实践；（重点） MOSN 多协议机制设计解读；（重点） 后续规划及展望； 其中第三点「接入实践」是今天分享的重点，希望能给大家就「如何在 MOSN 中快速扩展私有协议接入」有一个具体的感受。另外「MOSN 如何实现多协议框架」也是很多人关心和问题，我们将摘选几个技术功能，对其背后的设计思考进行解读。\nMOSN 简介 云原生网络代理 MOSN 定位是一个全栈的网络代理，支持包括网络接入层(Ingress)、API Gateway、Service Mesh 等场景，目前在蚂蚁金服内部的核心业务集群已经实现全面落地，并经受了 2019 年双十一大促的考验。今天要向大家介绍的是云原生网络代理 MOSN 核心特性之一的多协议扩展机制，目前已经支持了包括 SOFABolt、Dubbo、TARS 等多个协议的快速接入。\nMOSN：https://github.com/mosn\n多协议机制产生的背景与实践痛点 首先介绍一下多协议机制产生的背景。\n前面提到，蚂蚁金服 2019 年双十一核心链路百分之百 Mesh 化，是业界当时已知的最大规模的 Service Mesh 落地，为什么我们敢这么做？因为我们具备能够让架构平滑迁移的方案。\u0026amp;rdquo;兼容性\u0026amp;rdquo;是任何架构演进升级都必然要面对的一个问题，这在早已实践微服务化架构的蚂蚁金服内部同样如此。为了实现架构的平滑迁移，需要让新老节点的外在行为尽可能的表现一致，从而让依赖方无感知，这其中很重要的一点就是保持协议兼容性。\n因此，我们需要在 Service Mesh 架构下，兼容现有微服务体系中的通信协议——也就是说需要在 MOSN 内实现对目前蚂蚁金服内部通信协议的扩展支持。\n基于 MOSN 本身的扩展机制，我们完成了最初版本的协议扩展接入。但是在实践过程中，我们发现这并不是一件容易的事情：\n 相比编解码，协议自身的处理以及与框架集成才是其中最困难的环节，需要理解并实现包括请求生命周期、多路复用处理、链接池等等机制； 社区主流的 xDS 路由配置是面向 HTTP 协议的，无法直接支持私有协议，存在适配成本； 基于这些实践痛点，我们设计了 MOSN 多协议框架，希望可以降低私有协议的接入成本，加快普及 ServiceMesh 架构的落地推进。\n常见的协议扩展思路初探 前面介绍了背景，那么具体协议扩展框架要怎么设计呢？我们先来看一下业界的思路与做法。\n协议扩展框架 - Envoy 注：图片来自 Envoy 分享资料\n第一个要介绍的是目前发展势头强劲的 Envoy。从图上可以看出，Envoy 支持四层的读写过滤器扩展、基于 HTTP 的七层读写过滤器扩展以及对应的 Router/Upstream 实现。如果想要基于 Envoy 的扩展框架实现 L7 协议接入，目前的普遍做法是基于 L4 filter 封装相应的 L7 codec，在此基础之上再实现对应的协议路由等能力，无法复用 HTTP L7 的扩展框架。 协议扩展框架 - Nginx 第二个则是老牌的反向代理软件 Nginx，其核心模块是基于 Epoll/Kqueue 等 I/O 多路复用技术之上的离散事件框架，基于事件框架之上构建了 Mail、Http 等协议模块。与 Envoy 类似，如果要基于 Nginx 扩展私有协议，那么也需要自行对接事件框架，并完整实现包括编解码、协议处理等能力。\n协议扩展框架 - MOSN 最后回过头来，我们看一下 MOSN 是怎么做的。实际上，MOSN 的底层机制与 Envoy、Nginx 并没有核心差异，同样支持基于 I/O 多路复用的 L4 读写过滤器扩展，并在此基础之上再封装 L7 的处理。但是与前两者不同的是，MOSN 针对典型的微服务通信场景，抽象出了一套适用于基于多路复用 RPC 协议的扩展框架，屏蔽了 MOSN 内部复杂的协议处理及框架流程，开发者只需要关注协议本身，并实现对应的框架接口能力即可实现快速接入扩展。\n三种框架成本对比 最后对比一下，典型微服务通信框架协议接入的成本，由于 MOSN 针对此类场景进行了框架层面的封装支持，因此可以节省开发者大量的研发成本。\nSOFABolt 协议接入实践 初步了解多协议框架的设计思路之后，让我们以 SOFABolt 协议为例来实际体验一下协议接入的过程。\nSOFABolt 简介 这里先对 SOFABolt 进行一个简单介绍，SOFABolt 是一个开源的轻量、易用、高性能、易扩展的 RPC 通信框架，广泛应用于蚂蚁金服内部。\nSOFABolt：https://github.com/sofastack/sofa-bolt\n基于 MOSN 的多协议框架，实际编写了 7 个代码文件，一共 925 行代码(包括 liscence、comment 在内)就完成了接入。如果对于协议本身较为熟悉，且具备一定的 MOSN/Golang 开发经验，甚至可以在一天内就完成整个协议的扩展，可以说接入成本是非常之低。\nGithub: https://github.com/mosn/mosn/tree/master/pkg/protocol/xprotocol/bolt\n下面让我们进入正题，一步一步了解接入过程。\nStep1：确认协议格式 第一步，需要确认要接入的协议格式。为什么首先要做这个，因为协议格式是一个协议最基本的部分，有以下两个层面的考虑：\n 任何协议特性以及协议功能都能在上面得到一些体现，例如有无 requestId/streamId 就直接关联到协议是否支持连接多路复用； 协议格式与报文模型直接相关，两者可以构成逻辑上的映射关系；而这个映射关系也就是所谓的编解码逻辑； 以 SOFABolt 为例，其第一个字节是协议 magic，可以用于校验当前报文是否属于 SOFABolt 协议，并可以用于协议自动识别匹配的场景；第二个字节是 type，用于标识当前报文的传输类型，可以是 Request / RequestOneway / Response 中的一种；第三个字节则是当前报文的业务类型，可以是心跳帧，RPC 请求/响应等类型。后面的字段就不一一介绍了，可以发现，理解了协议格式本身，其实对于协议的特性支持和模型编解码就理解了一大半，因此第一步协议格式的确认了解是重中之重，是后续一切工作开展的前提。\nStep2：确认报文模型 顺应第一步，第二步的主要工作是确认报文编程模型。一般地，在第 …","date":1585227600,"description":"本文根据昨晚直播整理，主要分享云原生网络代理 MOSN 多协议机制解析，并介绍对应私有协议快速接入实践案例以及对其实现多协议低成本接入的设计进行解读。","dir":"blog/sofa-channel-13-retrospect/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"683f36d11af9e48e910e694bf1a119fc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-13-retrospect/","publishdate":"2020-03-26T21:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-channel-13-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["MOSN","Service Mesh","SOFAChannel"],"title":"云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-13-retrospect/","wordcount":6523},{"author":"敖小剑","categories":"Service Mesh","content":" 在2019年5月，CNCF 筹建通用数据平面 API 工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API。\n当时我写了一个博客文章 “CNCF 正在筹建通用数据平面 API 工作组，以制定数据平面的标准 API” 对此进行了介绍。当时 UDPA 还处于非常早期的筹备阶段，信息非常的少。\n现在9个月过去了，我最近收集并整理了一下 UDPA 目前的情况和信息，给大家介绍一下 UDPA 目前最新的进展（截止2020年2月24日）。\n另外蚂蚁金服开源的云原生网络代理 MOSN 目前已经支持 xDS v2 API，后面也会逐步向着 UDPA 的方向去演进，兼容标准 Istio，感兴趣的读者可以去了解下。\nMOSN：https://github.com/mosn/mon\nUDPA 介绍 首先快速介绍一下什么是 UDPA：\n UDPA ：“Universal Data Plane API”的缩写， “通用数据平面 API” UDPA-WG：”Universal Data Plane API Working Group”的缩写，这是 CNCF 下的一个工作组，负责制定 UDPA； UDPA 的目标，援引自 https://github.com/cncf/udpa 的描述：\n 通用数据平面 API 工作组（UDPA-WG）的目标是召集对数据平面代理和负载均衡器的通用控制和配置 API 感兴趣的业界人士。\n UDPA 的愿景，同样援引：\n 通用数据平面 API（UDPA）的愿景在 https://blog.envoyproxy.io/the-universal-data-plane-api-d15cec7a 中阐明。我们将寻求一组 API，它们为 L4/L7 数据平面配置提供事实上的标准，类似于 SDN 中 L2/L3/L4 的 OpenFlow 所扮演的角色。 这些 API 将在 proto3 中规范定义，并通过定义良好的、稳定 API 版本控制策略，从现有的 Envoy xDS API 逐步演进。API 将涵盖服务发现、负载均衡分配、路由发现、监听器配置、安全发现、负载报告、运行状况检查委托等。 我们将对 API 进行改进和成型，以支持客户端 lookaside 负载均衡（例如 gRPC-LB），Envoy 之外的数据平面代理，硬件 LB，移动客户端以及其他范围。我们将努力尽可能与供应商和实现无关，同时坚持支持已投入生产的 UDPA 的项目（到目前为止，Envoy 和 gRPC-LB）。\n 对 UDPA 感兴趣的同学，可以通过以下两个途径进一步深入了解：\n UDPA @ GitHub：UDPA 在 github 上的项目，UDPA API 定义的代码都在这里； Universal Data Plane API Working Group (UDPA-WG)：CNCF 的 UDPA 工作组，可以通过加入工作组的方式了解更多信息； UDPA 和 xDS 的关系 在展开 UDPA 的细节之前，有必要先解释清楚 UDPA 和 xDS 的关系，因为这对理解 UDPA 会有很大帮助。\n在2019年11月的 EnvoyCon 上，Envoy 的开发者，也是目前 UDPA 最主要的负责人之一，来自 Google 的 Harvey Tuch，有一个演讲非常详细而清晰的解答了这个问题，这个演讲的标题是：“The Universal Dataplane API (UDPA): Envoy’s Next Generation APIs”。\n 备注：这里我直接援引这份演讲的部分内容，以下两张图片均出自 这份演讲的PPT 。鸣谢 Harvey。\n 下图展示了近年来 xDS 协议的演进历程和未来规划：\n 2017年，xDS v2 引入 proto3 和 gRPC，同年 Istio 项目启动； 2018和2019年，xDS v2 API 继续发展，陆续引入了新的 API 定义，如 HDS / LRS / SDS 等，尤其是为了改进 Pilot 下发性能，开始引入增量推送机制； xDS v3 API 原计划于2019年年底推出，但目前看技术推迟，目前 v3 还是 alpha1 状态，预计在即将发布的 Istio 1.5 中会有更多的 v3 API 引入。同时 v3 API 也引入了 UDPA 的部分内容，但是由于 UDPA 目前进展缓慢，对 xDS 的影响并不大，主要还是 xDS 自身的发展，比如对 API 和技术债务的清理； 但在2020年，预计 UDPA 会有很大的进展，尤其是下面我们将会展开的 UDPA-TP 和 UDPA-DM 的设计开始正式制定为 API 之后。而 xDS v4 预计将基于 UDPA ，因此 xDS v4 可能会迎来比较大的变动； 简单总结说：xDS 将逐渐向 UDPA 靠拢，未来将基于 UDPA 。\n下图则展示了 Envoy 在 xDS 版本支持上的时间线：\n目前看这个计划在执行时稍微有一点点延误，原计划于2019年年底推出的 v3 的 stable 版本实际上是在1月中定稿的。（备注：具体可参考 Envoy PR api: freeze v3 API ）。然后目前正在广泛使用的 v2 API 将被标记为 depreated。而且在2020年底，v3 API 预计被 v4 API 取代（注意 v4 API 将会是基于 UDPA），而目前我们最熟悉的 v2 API 将计划在2020年底移除，不再支持！\n上图也展示了未来 xDS 协议的大版本演进和更替的方式，总的来说规律是这样：\n 一年一个大版本：2019 v2 -\u0026amp;gt; 2020 v3 -\u0026amp;gt; 2021 v4 -\u0026amp;gt;2022 v5； 每个大版本都要经历 alpha -\u0026amp;gt; stable -\u0026amp;gt; deprecated -\u0026amp;gt; removed 四个阶段，每个阶段历时一年； 稳定后 Envoy 会同时存在三个 API 大版本：正在使用的稳定版本，已经弃用的上一个稳定版本，准备开发的新的下一个大版本（但只会是Alpha）； 发布一个新的 stable 的大版本，就一定会 deprecated 上一个稳定的大版本，同时 remove 更前一个已经 deprecated 的大版本； 所谓 “长江后浪推前浪，前浪死在沙滩上”，又或者说，“江山代有新版出，各领风骚12个月”。\n 备注：Envoy 具体的稳定 API 版本控制策略，可以参见 Envoy 的设计文档 “Stable Envoy API versioning” ，不过这个文档长的有点过分，嫌长的同学可以直接看这个文档的缩减版本 API versioning guidelines。\n UDPA API 进展 言归正传，我们来看一下 UDPA 目前的最新进展。从 https://github.com/cncf/udpa ，可以看到目前 UDPA 中已经定义好的部分 API 内容：\n类型定义 目前只定义了一个类型 TypedStruct。\nTypedStruct 包含任意 JSON …","date":1585130400,"description":"本文收集并整理了一下 UDPA 目前的情况和信息，给大家介绍一下 UDPA 目前最新的进展。","dir":"blog/service-mesh-api-udpa-follow-up/","fuzzywordcount":11000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7293f926580393ddac18da73da056d07","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","publishdate":"2020-03-25T18:00:00+08:00","readingtime":22,"relpermalink":"/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","summary":"在2019年5月，CNCF 筹建通用数据平面 API 工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API。 当时我写了一","tags":["Service Mesh"],"title":"Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍","type":"blog","url":"/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","wordcount":10901},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@木易 提问：\n 请问，这个并发隔离是怎么做到的？二阶段是一阶段的最后去做的对吧，在 TCC 模式下的，RPC 调用二阶段失败了或者 MQ 异步调二阶段失败了，那二阶段失败了可咋整？ A：一阶段如果都成功了，说明所有分支的事务的“资源”已经预留成功了，这时候的失败都是“技术上”的失败比如网络抖动，这时会要重试提交。举个例子，如果二阶段一部份服务 commit 成功了，然后有一个失败了，这时只能重试提交，不能回滚，因为那些二阶段已经成功的服务，不能回滚了。\n 是不是一阶段的发起方还得根据业务编号记录一条 response，然后参与方定时去扫状态未更新的记录，然后根据业务编号去查 response 中的状态再更新自己的状态？\n A：业务流水是肯定要记的。\n 有行锁可用余额肯定没问题，就是这个预扣冻结字段如果放这行数据里，一阶段一释放锁，另一个事务给他改了就不对了，所以我感觉表里加这个字段不行啊，还是得用业务流水加这个预扣字段形成一条记录，这样事务之间的这个才是隔离的 。\n A：是的，是在业务上还要记录一条流水，一来为是业务上的要求，二来可以做幂等和防悬挂控制，三也是在回滚的时候需要这条流水才知道要回滚多少金额。\n相关阅读：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理\nSeata：https://github.com/seata/seata\n2、@邓从宝 提问：\n 您好，合并部署是个什么概念？什么时候会用到合并部署？\n A： 就是将原本独立开发的应用部署在一起，比如资源有限要高密度部署的时候，比如两个微服务应用频繁 rpc 交互想要部署到一个进程里提高性能的时候。\n3、@苏东东 提问：\n SOFAJRaft 能不能不通过 rpcserver 注册 GetValueRequestProcessor，我想用自己的 RPC 框架。\n A：暂时不能，请关注这个 pr 合并以后就可以了 https://github.com/sofastack/sofa-jraft/pull/402 详细 issue： https://github.com/sofastack/sofa-jraft/issues/268 SOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFAArk 解析文章集合 蚂蚁金服轻量级类隔离框架 Maven 打包插件解析 | SOFAArk 源码解析 蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFATracer 解析文章集合 蚂蚁金服分布式链路跟踪组件 SOFATracer 中 Disruptor 实践（含源码） 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 埋点机制剖析 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 采样策略和源码剖析 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 链路透传原理与SLF4J MDC 的扩展能力剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析 社区直播报名 作为云原生网络代理，Service Mesh 是 MOSN 的重要应用场景。随着 Service Mesh 概念的日益推广，大家对这套体系都已经不再陌生，有了较为深入的认知。但是与理论传播相对应的是，生产级别的大规模落地实践案例却并不多见。这其中有多方面的原因，包括社区方案饱受诟病的“大规模场景性能问题”、“配套的运维监控基础设施演进速度跟不上”、“存量服务化体系的兼容方案”等等。\n现实场景中，大部分国内厂商都有一套自研 RPC 的服务化体系，属于「存量服务化体系的兼容方案」中的协议适配问题。为此，MOSN 设计了一套多协议框架，用于降低自研体系的协议适配及接入成本，加速 Service Mesh 的落地普及。SOFAChannel#13，将向大家介绍 MOSN 实现多协议低成本接入的设计思路以及相应的快速接入实践案例。\n 主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 时间：2020年3月26日（周四）19:00-20:00 嘉宾：无钩，蚂蚁金服技术专家、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 欢迎参与投票 MOSN Logo 社区投票，在本期直播结束将公布投票结果，确定最新 Logo。\n 投票方式：回复 issue 你喜欢的方案编号以及原因 ","date":1584691200,"description":"【03/16-03/20】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200320/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e2add88606de2be4ddcf9c9ac2e4bbef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200320/","publishdate":"2020-03-20T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200320/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告、SOFAArk\u0026SOFATracer 解析文章合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200320/","wordcount":1761},{"author":"盲僧","categories":"SOFAArk","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAArk 实现原理》第二篇，本篇作者盲僧，来自 OYO。《剖析 | SOFAArk 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附系列共建列表，目前已完成领取。\n前言 SOFAArk 是 SOFA 团队开源的又一款扛鼎力作，它是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署的能力。\n从 2016 年底开始，蚂蚁金服内部开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构，也是为系列文章做好铺垫。\nSOFAArk biz 的打包插件是 sofa-ark-maven-plugin ，它可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式的 Ark 包或者 Ark Biz 包，关于 Ark 包和 Ark Biz 包可以参考这里：\n Ark 包：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/ Ark Biz：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/ 本文将从如下三个方面进行介绍：先对插件的使用和打包出来的产物做一个简单介绍，然后告诉大家调试插件的方法，最后对整个插件的原理做一个流程图和阐述。\nSOFAArk ：https://github.com/sofastack/sofa-ark\nSOFAArk 插件使用 文中的示例代码可以参考 我的 github\n 插件使用 先将 Spring Boot 的打包插件 spring-boot-maven-plugin 删除或者注释，然后再引入如下插件即可：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 执行 mvn package 命令后，将会打出如下结构的 3 个 jar 包，大家可以自行解压这三个 jar 包，看一看里面的具体内容，下面我们简单分析一下：\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT.jar ：它是 maven 插件打出来的原生 jar 包，只包含我们写的代码和 manifest 文件，无特殊意义。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-biz.jar ：这个 jar 包称之为 Ark Biz 包，因为 SOFAArk 容器是支持运行多个 Ark Biz 的，所以打成这种包是为了和别的项目一起合并部署使用，另外 Ark 包里也包含了这个。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-executable.jar ：这个 jar 包称之为 Ark 包，从字面上来看它是一个可执行的 jar 包，即意味着它是一个可以用 java-jar 命令来单独运行的 Fat Jar，类似于我们用 Spring Boot 插件打出来的包。\n后面的分析主要是围绕 Ark 包来做讲解，因为它包含了 Ark Biz 包，所以只要搞明白它是如何生成的，那么对整个插件的原理也就基本了解了。\n与 Spring Boot 插件对比 要想分析出 sofa-ark-maven-plugin 插件的作用，我们需要先和 Spring Boot 的插件进行对比，从打包产物上直观的感受一下两者的区别。\nspring-boot-maven-plugin 插件 spring-boot-maven-plugin 是 SpringBoot 默认提供的打包插件，其功能就是将工程打包成一个可执行的 FATJAR。spring-boot-maven-plugin 打包产物的目录结构如下：\n. ├── BOOT-INF │ ├── classes # 应用的字节码目录 │ └── lib # 应用所依赖的 jar 包 ├── META-INF │ ├── MANIFEST.MF # manifest 文件信息 │ └── maven # 应用的坐标信息 └── org └── springframework └── boot └── loader # 存放的是 Spring Boot Loader 的 class 文件 ├── JarLauncher.class # Spring Boot 启动类 ├── archive ├── data ├── jar └── util MANIFEST.MF 文件内容：\nManifest-Version: 1.0 Archiver-Version: Plexus Archiver Built-By: rrz Start-Class: pers.masteryourself.tutorial.sofa.ark.maven.plugin.MavenP luginApplication Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Spring-Boot-Version: 2.1.4.RELEASE Created-By: Apache Maven 3.5.3 Build-Jdk: 1.8.0_101 Main-Class: org.springframework.boot.loader.JarLauncher MANIFEST.MF 文件中可以看到，描述了当前 jar 的一些核心元素，包括启动类、class 文件路径、lib 依赖路径、jdk 版本等等，这里需要关注的是 Main-Class，SpringBoot 就是通过该类来引导启动的。SOFAArk 应用也提供了类似的引导类及其自身特殊的结构， …","date":1584612000,"description":"本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构","dir":"blog/sofa-ark-maven- packaging-plugins/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dd530d14f20a460c2f49300c0d784c32","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","publishdate":"2020-03-19T18:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAArk","SOFAArkLab"],"title":"蚂蚁金服轻量级类隔离框架 Maven 打包插件解析 | SOFAArk 源码解析","type":"blog","url":"/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","wordcount":3304},{"author":"卫恒","categories":"SOFATracer","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n Disruptor 简介 Disruptor 旨在在异步事件处理体系结构中提供低延迟，高吞吐量的工作队列。它确保任何数据仅由一个线程拥有以进行写访问，因此与其他结构相比，减少了写争用。目前，包括 Apache Storm、Camel、Log4j 2 在内的很多知名项目都应用了 Disruptor 以获取高性能。\nSOFATracer 也是基于 Disruptor 高性能无锁循环队列来提供异步打印日志到本地磁盘能力的，SOFATracer 提供两种类似的日志打印类型即摘要日志和统计日志，摘要日志：每一次调用均会落地磁盘的日志；统计日志：每隔一定时间间隔进行统计输出的日志；无论是哪种日志的输出，对于 SOFATracer 来说都需要保证较高的性能，以降低对于业务整体流程耗时的影响。\n关于 Disruptor 的 一些原理分析可以参考：Disruptor 。\n A High Performance Inter-Thread Messaging Library 高性能的线程间消息传递库\n 案例 先通过 Disruptor 的一个小例子来有个直观的认识；先看下它的构造函数：\npublic Disruptor( final EventFactory\u0026amp;lt;T\u0026amp;gt; eventFactory, final int ringBufferSize, final ThreadFactory threadFactory, final ProducerType producerType, final WaitStrategy waitStrategy) { this( RingBuffer.create(producerType, eventFactory, ringBufferSize, waitStrategy), new BasicExecutor(threadFactory)); } eventFactory : 在环形缓冲区中创建事件的 factory； ringBufferSize:环形缓冲区的大小，必须是2的幂； threadFactory：用于为处理器创建线程； producerType：生成器类型以支持使用正确的sequencer和publisher创建RingBuffer；枚举类型，SINGLE、MULTI两个项。对应于 SingleProducerSequencer和MultiProducerSequencer两种Sequencer； waitStrategy : 等待策略； 如果我们想构造一个 disruptor，那么我们就需要上面的这些组件。从 eventFactory 来看，还需要一个具体的 Event 来作为消息事件的载体。【下面按照官方给的案例进行简单的修改作为示例】\n消息事件 LongEvent ，能够被消费的数据载体 public class LongEvent { private long value; public void set(long value) { this.value = value; } public long getValue() { return value; } } 创建消息事件的 factory public class LongEventFactory implements EventFactory\u0026amp;lt;LongEvent\u0026amp;gt; { @Override public LongEvent newInstance() { return new LongEvent(); } } ConsumerThreadFactory public class ConsumerThreadFactory implements ThreadFactory { private final AtomicInteger index = new AtomicInteger(1); @Override public Thread newThread(Runnable r) { return new Thread(r, \u0026amp;quot;disruptor-thread-\u0026amp;quot; + index.getAndIncrement()); } } OK ，上面的这些可以满足创建一个 disruptor 了：\nprivate int ringBufferCapacity = 8; //消息事件生产Factory LongEventFactory longEventFactory = new LongEventFactory(); //执行事件处理器线程Factory ConsumerThreadFactory consumerThreadFactory = new ConsumerThreadFactory(); //用于环形缓冲区的等待策略。 WaitStrategy waitStrategy = new BlockingWaitStrategy(); //构建disruptor Disruptor\u0026amp;lt;LongEvent\u0026amp;gt; disruptor = new Disruptor\u0026amp;lt;\u0026amp;gt;( longEventFactory, ringBufferCapacity, longEventThreadFactory, ProducerType.SINGLE, waitStrategy); 现在是已经有了 disruptor 了，然后通过：start 来启动：\n//启动 disruptor disruptor.start(); 到这里，已经构建了一个disruptor；但是目前怎么使用它来发布消息和消费消息呢？\n发布消息 下面在 for 循环中 发布 5 条数据：\nRingBuffer\u0026amp;lt;LongEvent\u0026amp;gt; ringBuffer = disruptor.getRingBuffer(); for (long l = 0; l \u0026amp;lt; 5; l++) { long sequence = ringBuffer.next(); LongEvent event = ringBuffer.get(sequence); event.set(100+l); System.out.println(\u0026amp;quot;publish event :\u0026amp;quot; + l); ringBuffer.publish(sequence); Thread.sleep(1000); } 消息已经发布，下面需要设定当前 disruptor 的消费处理 …","date":1584439200,"description":"本文将对 SOFATracer 中使用 Disruptor 来进行日志输出的代码进行了具体的分析。","dir":"blog/sofa-trcaer-disruptor-practice/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a97d804a20a7af180c889c55210ab2fa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","publishdate":"2020-03-17T18:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFATracer"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 中 Disruptor 实践（含源码）","type":"blog","url":"/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","wordcount":5441},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析\n 活动时间：3 月 26 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 作为云原生网络代理，Service Mesh 是 MOSN 的重要应用场景。随着 Service Mesh 概念的日益推广，大家对这套体系都已经不再陌生，有了较为深入的认知。但是与理论传播相对应的是，生产级别的大规模落地实践案例却并不多见。这其中有多方面的原因，包括社区方案饱受诟病的“大规模场景性能问题”、“配套的运维监控基础设施演进速度跟不上”、“存量服务化体系的兼容方案”等等。\n现实场景中，大部分国内厂商都有一套自研 RPC 的服务化体系，属于「存量服务化体系的兼容方案」中的协议适配问题。为此，MOSN 设计了一套多协议框架，用于降低自研体系的协议适配及接入成本，加速 Service Mesh 的落地普及。本次演讲将向大家介绍 MOSN 实现多协议低成本接入的设计思路，以及相应的快速接入实践案例。\n本期为 SOFAChannel 线上直播第 13 期，将邀请蚂蚁金服技术专家\u0026amp;amp; MOSN Committer 无钩分享《云原生网络代理 MOSN 的多协议机制解析》。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：21992058（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1131\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 无钩 蚂蚁金服技术专家 MOSN Committer\n本期分享大纲 一个请求的 MOSN 之旅 如何在 MOSN 中接入新的协议 SOFABolt 协议接入实践 未来发展：统一路由框架 嘉宾 SOFAGirl 主持人 无钩 蚂蚁金服技术专家 MOSN Committer ","date":1584349200,"description":"3 月 26 日周四晚 7 点，线上直播第 13 期。","dir":"activities/sofa-channel-13/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ba88bba5176867c90fb18dc045408d84","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-13/","publishdate":"2020-03-16T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-13/","summary":"概要 活动主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 活动时间：3 月 26 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介","tags":["SOFAChannel","MOSN"],"title":"SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-13/","wordcount":692},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@胡秋林 提问：\n 请教一个问题，服务拆分然后使用分布式事务，会不会事务链路过长，然后整体性能下降很大呢？\n A：用了分布式事务性能肯定会下降，这是大家对一致性和性能的取舍。在性能对比这块我建议大家去和同类的分布式事务框架对比，而不是只和不用分布式事务去对比。分布式事务很大一部分是处理的系统异常时的一致性，如果针对系统异常这个点，大家如果相信自己的框架 100% 正常的，不会出现超时，网络和宕机等问题，那可以不使用分布式事务，所以保证一致性的很多场景是极端情况下的一致性，在同类框架的对比中，一定是看框架一致性场景的覆盖，如果场景覆盖不全的基础上和我们对比性能我觉得这个没太大意义。这就好比我系统有 1% 几率出现极端情况，我不用 Seata 和使用 Seata 的对比是一样的。\n2、@吴攀 提问：\n 麻烦问下，我现在做的一个销售订单的流程。需要监听审批的状态变化，然后状态机才往下进行流转。Saga 能否满足呢？  A：目前是不支持的，因为 Saga 的状态机定位是服务编排的事务处理，不应该包含人工审批动作，建议做成两个流程，包含人工审批动作，中间状态时间会很长。\n 我来状态想能否把“状态”配置成“IsAsync = true”来实现，然后异步任务来监听审批状态的变化。感觉有些负责。所以来咨询下？有没有更好其他的推荐的方案呢？Netflix Conductor 能满足这个场景么？我现在的场景是：一个销售单出库的流程。销售单建立成功后，要经过审批流程进行审批，然后进入仓库进行库存分配。分配成功后，进行分拣，然后进行打包。最后进行出库。老板想把这些状态流转编制成一个 Saga 支持的状态机。\n A：isAsync 是这个服务异步调用，应该解决不了你这个问题。我的建议是把这个流程差分一下，拆分成两个，或者，销售订单不要纳入状态机，只是插入一条记录，审批通过后，把后面的流程配置成状态机，而且我理解你们这流程是每一步都是人工做完，然后在系统里点一下，然后继续，如果是这样，这不是服务编排的需求，为是工作流的需求。\nSeata：https://github.com/seata/seata\n3、@兴元 提问：\n SOFABoot 版本 v3.3.0，目前官网文档里只有整合 Nacos 0.6.0 版本的，请问怎么使用 Nacos 的命名空间功能？SOFABoot 版本 v3.3.0，maven 引用里 nacos-client 版本是 1.0.0，请问现在支持 nacos 最新版本是多少。\n A：Nacos 配置格式参考：https://www.sofastack.tech/projects/sofa-rpc/registry-nacos/ 对于 namespace 的，可以配置成这样即可：namespace nacos://yyy:8848/namespaceNacos 客户端应该是兼容的，你可以直接升级这个包的版本。\n 命名空间问题解决了，感谢。因为我使用的时候指定了 nacos client 版本为0.6.0，升级到 0.8.0 以上nacos://yyy:8848/namespace 这种形式是可以的，而且只能使用 nacos://yyy:8848/namespace 这种形式，nacos://yyy:8848 是不行的。还望官方文档可以及时更新一下。\n A：这里应该是要配置成：nacos://yyy:8848/ 后面有个/。好的，最近我们升级一下 Nacos 的 client 版本。文档我们同步修改下。\n 刚试了nacos://yyy:8848/，服务依然无法发布到默认命名空间。Nacos server 是1.2.0，客户端是使用SOFABoot v3.3.0。\n A：不会发到默认的，这个会发到的是 SOFARPC 这个 Namespace：private static final String DEFAULT_NAMESPACE = \u0026amp;quot;sofa-rpc\u0026amp;quot;;\nSOFARPC：https://github.com/sofastack/sofa-rpc\n期待见到，每一个精彩的你 蚂蚁金服云原生团队实习生招聘开始啦 【岗位继续增了】蚂蚁金服云原生团队招聘~欢迎加入我们 SOFAChannel 直播回顾 SOFAChannel#12：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.3.1 版本，主要变更如下：\n 升级 Spring Boot 至 2.1.13.RELEASE； 修复 Tomcat AJP 漏洞； …","date":1584086400,"description":"【03/09-03/13】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200313/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cd22bd67fe25923bca65eae188627da8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200313/","publishdate":"2020-03-13T16:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200313/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 3/26 直播预告、多个组件发布、云原生团队校招社招信息汇总","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200313/","wordcount":2967},{"author":"仁空","categories":"SOFA Weekly","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#12 直播分享整理，主题：蚂蚁金服分布式事务实践解析。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 大家好，我是今天分享的讲师仁空，目前是蚂蚁金服分布式事务产品的研发。今天跟大家分享的是蚂蚁金服分布式事务实践解析，也就是分布式事务 Seata 在蚂蚁金服内部的实践。\n今天我们将从以下 4 个主题进行详细介绍：\n 为什么会有分布式事务产品的需求； 理论界针对这个需求提出的一些理论和解决方案； 蚂蚁金服在工程上是如何解决这个问题的； 针对蚂蚁金服业务场景的性能优化； 分布式事务产生背景 首先是分布式事务产生的背景。\n支付宝支付产品在 2003 年上线的时候，那时候的软件形态是单体应用，在一个应用内完成所有的业务逻辑操作。随着软件的工业化，场景越来越复杂，软件也越做越大，所有的业务在一个应用内去完成变的不可能，出现了软件模块化、服务化。\n在从单体应用升级到分布式架构过程中，很自然得需要进行业务服务拆分，将原来糅在一个系统中的业务进行梳理，拆分出能独立成体系的各个子系统，例如交易系统、支付系统、账务系统等，这个过程就是服务化。业务服务拆分之后，原来一个服务就能完成的业务操作现在需要跨多个服务进行了。\n另一个就是数据库拆分，分库分表。原来的单体数据库存不下的这么多信息，按服务维度拆库，比如把用户相关的存一起，形成用户库，订单放一块形成订单库，这个是拆库的过程；另一个是拆表，用户信息按照用户 ID 散列到不同的 DB 中，水平拆分，数据库的容量增大了。这样分库分表之后，写操作就会跨多个数据库了。\n分布式事务理论基础 我们可以看到，在分布式架构中，跨数据库、跨服务的问题是天然存在的。一个业务操作的完成，需要经过多个服务配合完成，这些服务操作的数据可能在一个机房中，也可能跨机房存在，如果中间某一个服务因为网络或机房硬件的问题发生了抖动，怎么保证这笔业务最终的状态是正确的，比如支付场景，怎么防止我转钱给你的过程中，我的钱扣了，而对方的账户并没有收到钱。这个就是业务最终一致性的问题，是分布式事务需要解决的问题。\n2PC 协议 针对这个问题，理论界也提出了解决方案，其中最为人熟知的就是二阶段协议了，简称2PC（Two Phase Commitment Protocol）两阶段提交协议。\n两阶段提交协议，就是把整个过程分成了两个阶段，这其中，它把参与整个过程的实体分成了两类角色，一个叫事务管理器或事务协调者，一个叫资源管理器，事务管理器我们也把它叫做事务发起方，资源管理器称为事务参与者。\n两个阶段，第一个阶段是资源准备阶段，比如我要转账，我要先查询下我的余额够不够，够的话我就把余额资源预留起来，然后告诉发起方“我准备好了”，第二个阶段，事务发起方根据各个参与者的反馈，决定事务的二阶段操作是提交还是取消。\nTCC 协议 另一个协议是 TCC 协议，各个参与者需要实现3个操作：Try、Confirm 和 Cancel，3个操作对应2个阶段，Try 方法是一阶段的资源检测和预留阶段，Confirm 和 Cancel 对应二阶段的提交和回滚。\n图中，事务开启的时候，由发起方去触发一阶段的方法，然后根据各个参与者的返回状态，决定二阶段是调 Confirm 还是 Cancel 方法。\n蚂蚁金服分布式事务介绍 2019年，蚂蚁金服跟阿里巴巴共同开源了分布式事务 Seata ，目前 Seata 已经有 TCC、AT、Saga 模式，Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。今天的分享也是 Seata 在蚂蚁金服内部的实践。\n分布式事务在蚂蚁金服的发展 基于上述的理论，接下来我们详细看下蚂蚁金服的分布式事务实现。\n经过多年的发展，蚂蚁金服内部针对不同的场景发展了几种不同的模式，最早的是 TCC 模式，也就是上面讲的 Try - confirm - Cancel，我们定义接口规范，业务自己实现这3个操作。这个模式提供了更多的灵活性，因为是业务自己实现的，用户可以介入两阶段提交过程，以达到特殊场景下的自定义优化及特殊功能的实现，这个模式能几乎满足任何我们想到的事务场景，比如自定义补偿型事务、自定义资源预留型事务、消息事务等场景。TCC 模式广泛用于蚂蚁金服内部各金融核心系统。\n这里要强调一点的是，TCC 模式与底层数据库事务实现无关，是一个抽象的基于 Service 层的概念，也就是说，在 TCC 的范围内，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，或者列式存储数据库 HBase，只要将对它们的操作包装成 TCC 的参与者，就可以接入到 TCC 事务范围内。\nTCC 模式的好处是灵活性，弊端是牺牲了易用性，接入难度比较大，所有参与者需要进行改造提供 Try - Confirm - Cancel 三个方法。为了解决 TCC 模式的易用性问题，蚂蚁金服分布式事务推出了框架管理事务模式（Framework - Managed Transactions，简称 FMT），也就是 Seata 中的 AT 模式。FMT 模式解决分布式事务的易用性问题，最大的特点是易于使用、快速接入、对业务代码无侵入。\nXA 模式是依赖于底层数据库实现的。\nSaga 模式是基于冲正模型实现的一个事务模式，现在的银行业金融机构普遍用的是冲正模型。\n这期我们重点讲 TCC 和 FMT，关于 Saga 模式，之前 Saga 模式也有专场直播分享过，感兴趣的可以看一下之前的直播回顾：《Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾》。\nTCC 模式在蚂蚁金服内的使用 首先看下 TCC 模式，主要包含一下几个模块：\n 参与者，它要实现全部的三个方法，Try、Confirm 和 Cancel； 发起方，主要是作为协调者的角色，编排各个参与者，比如调用参与者的一阶段方法，决策二阶段是执行提交还是回滚； 举个例子，比如在这个流程图中，存在一个发起方和两个参与者，两个参与者分别实现了 Try、Confirm 和 Cancel 接口，第一阶段被包含在发起方的本地事务模版中（图中黄颜色的两条虚线就是发起方本地事务的范围），也就是说发起方负责调用各个参与者的一阶段方法，发起方的本地事务结束后，开始执行二阶段操作，二阶段结束则整个分布式事务结束。\n二阶段是通过 Spring 提供的事务同步器实现的，发起方在发起一个分布式事务的时候，会注册一个事务同步器，当发起方本地事务结束的时候，会进入事务同步器的回调方法中。如果发起方的本地事务失败，则在回调中自动回滚所有参与者。如果发起方的本地事务成功，则二阶段自动提交所有参与者。二阶段结束后，删除所有事务记录。\n总结一下：\n 事务发起方是分布式事务的协调者； 分布式事务必须在本地事务模板中进行，发起方本地事务的最终状态（提交或回滚）决定整个分布式事务的最终状态； 发起方主职责：开启一个分布式事务 + 调用参 …","date":1584016200,"description":"分布式事务 TCC、FMT 模式在蚂蚁金服内部的实践分享。","dir":"blog/sofa-channel-12-retrospect/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1aaf09602548f4204f00c7b02260e180","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-12-retrospect/","publishdate":"2020-03-12T20:30:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-channel-12-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#12 直播分享整理，主题：蚂蚁金服分布式事务实践解析。 回顾视频以及 PPT 查看地址见文末","tags":["SOFAChannel","分布式事务"],"title":"蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-12-retrospect/","wordcount":6522},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@水木今山 提问：\n 请问下 SOFAJRaft 能否在日志复制到大多数后就响应客户端？我看 rhea 和 counter 的例子好像都是应用到状态机后才通过 closure 响应客户端。\n A：SOFAJRaft 没有限制，可以在自己的 statemachine 里不直接返回客户端再应用， rheakv 不能。举个例子， compareAndSet 操作，需要先读取再设置，最后返回 client，那么怎么能做到不应用状态机就返回呢，对吧？\n 有道理，但直接返回客户端的逻辑只能在 StateMachine 提供的 onApply 方法里实现吗，因为 onApply 的调用应该会滞后许久吧？\n A：onApply 里面实现就可以，onApply 就可以理解为和达成多数派之间没有延迟。\n 我在文档中有看到 TaskClosure 这么一个接口，在它的 onCommitted 方法里响应客户端会不会更高效？据我所知，raft 仅需写入日志就可保证强一致性，可以异步去 apply，所以在复制日志给大多数后就通过 onCommitted方法响应客户端（尽管还没有任何一个节点 apply 了该日志），这样效率好像会高一点，不知道我对这个接口理解有没有误。\n A：com.alipay.sofa.jraft.core.FSMCallerImpl#doCommitted\n可以看看这个方法，里面会在调用状态机之前调用 TaskClosure，想用 TaskClosure 也可以，不过两者没什么延迟区别。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@匿名 提问：\n MOSN 支持 Istio 的什么版本？什么时候可以在 Istio 中可用？\n A：目前 MOSN 可基于 Istio 1.1.4 跑通 bookinfo example，由于最新版本的 Istio 对 XDS 协议进行了升级以及部分能力增强，MOSN 当前正在适配中，预计 2020 年 10 月份会完整支持高版本 Istio 的 HTTP 系能力；同时我们一直在关注 UDPA 的发展，也在尝试参与到标准的制定中。控制平面方面，我们和社区一直保持紧密沟通与合作，大力发展控制平面，MOSN 也将与控制平面共同前进。\nMOSN：https://github.com/mosn/mosn\n3、@孙俊 提问：\n 请问下，全局事务开启后，全局事务锁未释放时，此时又来个操作同一个数据的本地请求，这个请求没有开启全局事务，是可以修改这个数据的呀。\n A：全局事务的分支事务结束后，不在全局事务的本地数据请求可修改数据。\n 那这样，全局事务的其他分支出现异常，分支事务回滚，从undo里读，发现数据已经被修改了，就得人工处理了？\n A：是，从业务设计上来说如果使用 AT 模式要把数据修改都交给 AT 来管理来避免这类问题。 Seata：https://github.com/seata/seata\n剖析 SOFARegistry 系列 服务注册中心数据一致性方案分析 | SOFARegistry 解析 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 1、发布 SOFARegistry v5.4.0 版本，主要变更如下：\n SessionServer 与 DataServer 通讯性能优化； jraft 从 1.2.5 更新到 1.2.7.beta1； 解决 MethodHandle 在某些 jdk 版本存在内存泄露的 bug； Bug Fix； 详细发布报告：https://github.com/sofastack/sofa-registry/releases/tag/v5.4.0\n2、发布 SOFAArk v1.1.1 版本，主要变更如下：\n 优化biz 卸载，清理临时文件； 支持 biz 打包 指定 bizName -D 参数； 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.1.1\n社区直播预告 SOFAChannel#12 线上直播将邀请蚂蚁金服分布式事务核心开发仁空分享介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1583481600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200306/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"762ff425feef89f406716a6c0c4fff9d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200306/","publishdate":"2020-03-06T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200306/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARegistry 发版以及源码系列合辑、SOFAArk 发版、3/12直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200306/","wordcount":1922},{"author":"SOFA 团队","categories":"云原生","content":" 2月19日-2月26日，蚂蚁金服开展了“共战‘疫情’，技术破局”数字课堂线上直播，邀请资深专家从“云原生”、“研发效能”、“数据库”三方面分享蚂蚁金服的实践经验并在线答疑，解析 PaaS 在金融场景的落地建设实践，解析支付宝移动端弹性动态架构，分享 OceanBase 2.2版本的特性和实践。\n 本文根据 蚂蚁金服 SOFAStack 产品专家俞仁杰，在蚂蚁金服数字课堂直播间分享的云原生应用 PaaS 平台的建设实践内容整理，以下为演讲整理全文：\n大家好，欢迎来到蚂蚁金服数字课堂直播间。今年 2 月，SOFAStack 金融分布式架构产品已经在阿里云上完成了商业化发布，为了让更多朋友了解到我们的产品的能力、定位以及背后的设计思路，后续我们会有一系列的直播分享。我们今天想分享给大家的话题叫《云原生应用 PaaS 平台的建设实践》，主要会围绕 PaaS 产品能力在一些需要稳妥创新的金融场景下的落地思路，并且能够更好地与云原生架构做好链接。\n金融场景云原生落地面临挑战 云原生是业务快速变化背景下的必然技术趋势 回顾 IT 的发展史，云计算分类为 IaaS PaaS 和 SaaS 已经有十几年了。而事实上，整个云计算行业的发展，我们能够明显看到企业在落地云计算战略的时候经历的三个阶段，Cloud-Based, Cloud-Ready, Cloud-Native。这三个阶段其实是因为业务的变化越来越敏捷，要求企业关注重心上移，把更多的精力和人才投入到业务逻辑的建设上，而把下层自已并不擅长并且越来越复杂的基础设施、中间件逐渐交给云计算厂商去实现，专业的人做专业的事。\n这本质是社会分工的进一步细化，也符合人类社会发展的规律。在云原生时代，业界所提出的容器技术，Service Mesh 技术，Serverless 技术都是希望让业务研发与基础技术更加的解耦，让业务创新和基础技术创新都更容易的发生。\n容器技术带来的是一种应用交付模式的变革 云原生就是业务快速变化背景下的必然技术趋势。而这个趋势背后的实质载体，就是我们所说的云原生、Kubernetes 以及以 Docker 为代表的容器技术，这些所带来的，本质是一种应用交付模式的变革。而为了真正能够使业界、社区所倡导的新兴应用交付模式落地到实际的企业环境，我们需要一个以应用为中心的平台来进行承载，贯穿应用运维的各项生命周期。\n围绕“云原生”这个关键词，其实在社区和业界已经有了非常多的交流和资料，围绕Docker/K8S 的最佳实践、DevOps CICD、容器网络存储设计、日志监控对接优化等等等等，而我们今天的分享，主要想表达的是我们围绕在 K8S 之上塑造一个 PaaS 平台的产品价值主张。Kubernetes 是一个非常好的编排和调度框架，它核心的贡献是让应用的编排和资源的调度更加的标准化，同时提供了一个高度可扩展的架构，方便上层进行各种控制器和调度器的定制。但是，它并不是一个 PaaS。PaaS 底层可以基于 Kubernetes 去实现，但是在上层要补足非常多的能力才能真正把 Kubernetes 用于生产环境，特别是金融行业的生产环境。\n金融场景需要“稳妥创新” 生产环境落地云原生需要着重考虑哪些挑战？\n我们之前做过一些调研和客户访谈。就现在 2020 年来说，绝大多数金融机构都展现出了对 Kubernetes、容器等技术的极大兴趣，有不少机构也已经在一些非关键的业务、或开发测试环境搭建了开源或商业版的集群。驱动力很简单，金融机构非常希望这一整套新的交付模式帮助到业务飞速迭代。然而对比落差非常明显的是，真正敢于在核心生产环境落地云原生架构的，又少之又少。因为金融业务创新的前提，是要保障稳妥。\n我们团队在服务蚂蚁内部业务、外部金融机构的过程中，总结了以上这几个方面，事实上这六大方面也是我们内部 SRE 不断挑战的几点。我们在今天以及未来的分享中，会逐步总结深化应对这些挑战的产品思路。\nK8S 体系下的应用变更与发布管控 我们今天分享的一个核心内容，就是我们如何在产品层面做应用变更的风险保障的。并围绕此话题向大家介绍变更“三板斧”的背景、K8S 原生部署能力、我们产品围绕变更需求做的扩展并向大家介绍我们在开源方面的规划。\n需求背景：变更“三板斧” 所谓“三板斧”就是可灰度、可监控、可应急。这是蚂蚁内部运维的一条红线准则，所有的变更，都必须要遵从这个规则，即使再细小的变更，再严密的测试，也不能忽略这条规则。为了满足这个需求，我们在 PaaS 产品层设计了各种各样的精细化发布策略，比如分组发布、beta 发布，灰度发布，蓝绿发布等。这些发布策略跟我们在做传统运维时用的手段是非常相似的，但很多使用容器的用户认为在 K8S 里实现会非常的困难。\n有些时候，由于对业务连续性的极高要求，也很难接受原生 K8S 模型标准化模式，比如原生 Deployment 做灰度或者金丝雀发布时，默认情况下在 Pod 变更和流量治理层面的管控还稍显不足，无法完全做到无损发布或按需过程管控。因此，我们在 PaaS 产品层面做了定制，在 Kubernetes 层面做了自定义资源的扩展，目的是能够在云原生的场景下，依然对整个发布过程实现精细化管控，使得大规模集群发布、灰度、回滚时更加优雅，符合技术风险三板斧原则。 Kubernetes 原生发布能力 我们先来回顾一下 K8S 的原生 Deployment 对象，及其背后的 ReplicaSet，其实已经是在最近好几个大版本中已经逐渐的稳定了。 简单的来说，最常见的 K8S 发布场景，我们会通过 Deployment 的对象，声明出我希望的发布模式以及 Pod Spec 定义。在运行时，会有 ReplicaSet 对象来管理 Pod 数量的预期，默认情况下会提供滚动发布或重建发布能力。\nimage.png\n这幅图的下半部分，是围绕 Deployment 作滚动发布时的示意图，这里不再做过多的展开，它的本质根据用户根据我们的运维需求设定好一定的步长，创建新的 Pod，销毁旧的 Pod，因此能做到整个应用版本的变更和发布过程中，都能有对应的容器对外提供服务。 对大部分场景来说，它是够用的，而且整个过程也是非常好的理解，事实上在 K8S 体系，大家除了 Pod/Node，看的最多的就是 Deployment了。\nCAFEDeployment：感知底层拓扑和领域模型 回顾完 Deployment，我们可以再给大家看一下我们根据实际需求作的 CRD 扩展，CAFEDeployment。CAFE 是我们 SOFAStack PaaS 产品线的名称，本文的最后会作一些介绍。\nCAFEDeployment 有一个很重要的能力，就是能够感知到底层拓扑，这个拓扑是什么意思呢？能够知道我想把我的 Pod 发布到哪里，哪边的 Node，不只是基于亲和性的规则作绑定，而是真正能把高可用、容灾、以及部署策略等场景息息相关的信息，带到整个围绕发布的领域模型中。对此，我们提出了一个叫部署单元的领域模型，他是一个逻辑概念，在 yaml 中简单的叫做 Cell。在实际使用中，Cell 的背后，可以是不同的 AZ 不同的物理机房，不同的机架，一切都是围绕着不同级别的高可 …","date":1583395200,"description":"云原生应用 PaaS 平台的建设实践","dir":"blog/distributed-architecture-and-cloud-native/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6c1ff3975ace44ac5189b1f845a43fcb","permalink":"https://sofastack.github.io/sofastack.tech/blog/distributed-architecture-and-cloud-native/","publishdate":"2020-03-05T16:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/distributed-architecture-and-cloud-native/","summary":"2月19日-2月26日，蚂蚁金服开展了“共战‘疫情’，技术破局”数字课堂线上直播，邀请资深专家从“云原生”、“研发效能”、“数据库”三方面分","tags":["云原生"],"title":"技术破局：如何实现分布式架构与云原生？| 含 ppt 下载","type":"blog","url":"/sofastack.tech/blog/distributed-architecture-and-cloud-native/","wordcount":5553},{"author":"明不二","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第七篇，本篇作者明不二。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 在前面的文章已经做过介绍，与其他注册中心相比，SOFARegistry 主要特点在于支持海量数据、支持海量客户端、秒级的服务上下线通知以及高可用特性。本文将从如下几个方面来讲述 SOFARegistry 的一致性方案：\n MetaServer 数据一致性 为支持高可用特性，对于 MetaServer 来说，存储了 SOFARegistry 的元数据，为了保障 MetaServer 集群的一致性，其采用了 Raft 协议来进行选举和复制。\n SessionServer 数据一致性 为支持海量客户端的连接，SOFARegistry 在客户端与 DataServer 之间添加了一个 SessionServer 层，客户端与 SessionServer 连接，避免了客户端与 DataServer 之间存在大量连接所导致的连接数过多不可控的问题。客户端通过 SessionServer 与 DataServer 连接的时候，Publisher 数据同时会缓存在 SessionServer 中，此时就需要解决 DataServer 与 SessionServer 之间数据一致性的问题。\n DataServer 数据一致性 为支持海量数据，SOFARegistry 采用了一致性 Hash 来分片存储 Publisher 数据，避免了单个服务器存储全量数据时产生的容量瓶颈问题。而在这个模型中，每个数据分片拥有多个副本，当存储注册数的 DataServer 进行扩容、缩容时，MetaServer 会把这个变更通知到 DataServer 和 SessionServer，数据分片会在集群内部进行数据迁移与同步，此时就出现了 DataServer 内部数据的一致性问题。\nMetaServer 数据一致性 MetaServer 在 SOFARegistry 中，承担着集群元数据管理的角色，用来维护集群成员列表，可以认为是 SOFARegistry 注册中心的注册中心。当 SessionServer 和 DataServer 需要知道集群列表，并且需要扩缩容时，MetaServer 将会提供相应的数据。\n图1 MetaServer 内部结构 图源自 《蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析》\n因为 SOFARegistry 集群节点列表数据并不是很多，因此不需要使用数据分片的方式在 MetaServer 中存储。如图 1 所示，集群节点列表存储在 Repository 中，上面通过 Raft 强一致性协议对外提供节点注册、续约、列表查询等 Bolt 请求，从而保障集群获得的数据是强一致性的。\nRaft 协议 关于 Raft 协议算法，具体可以参考 The Raft Consensus Algorithm 中的解释。在 SOFA 体系中，对于 Raft 协议有 SOFAJRaft 实现。下面对 Raft 协议算法的原理进行简要介绍。\nRaft 协议由三个部分组成，领导人选举（Leader Election）、日志复制（Log Replication）、安全性（Safety）。\n 领导人选举 通过一定的算法选举出领导人，用于接受客户端请求，并且把指令追加到日志中。\n图2 Raft 状态机状态转换图 图源自Understanding the Raft consensus algorithm: an academic article summary\n 日志复制 领导人接受到客户端请求之后，把操作追加到日志中，同时与其他追随者同步消息，最终 Commit 日志，并且把结果返回给客户端。\n图3 复制状态机 图源自 Raft一致性算法笔记\n 安全性 安全性保证了数据的一致性。\n基于 Raft 协议的数据一致性保障 图4 SOFARegistry 中的 Raft 存储过程 图源自 《蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析》\n如图 4 所示，SOFARegistry 中的 Raft 协议数据存储经历了如上的一些流程。客户端发起 Raft 协议调用，进行数据注册、续约、查询等操作时，会通过动态代理实现 ProxyHandler 类进行代理，通过 RaftClient 把数据发送给 RaftServer ，并且通过内部的状态机 Statemachine ，最终实现数据的操作，从而保证了 MetaServer 内部的数据一致性。\nSessionServer 数据一致性 SessionServer 在 SOFARegistry 中，承担着会话管理及连接的功能。同时，Subscriber 需要通过 SessionServer 来订阅 DataServer 的服务数据，Publisher 需要通过 SessionServer 来把服务数据发布到 DataServer 中。\n在这个场景下，SessionServer 作为中间代理层，缓存从 DataServer 中获取的数据成了必然。DataServer 的数据需要通过 SessionServer 推送到 Subscriber 中，触发 SessionServer 推送的场景有两个：一个是 Publisher 到 DataServer 的数据发生变化；另外一个是 Subscriber 有了新增。\n而在实际的场景中，Subscriber 新增的情况更多，在这种场景下，直接把 SessionServer 缓存的数据推送到 Subscriber 中即可，能够大大减轻 SessionServer 从 DataServer 获取数据对 DataServer 的压力。因此，这也进一步确认了在 SessionServer 缓存数据的必要性。\n图5 两种场景的数据推送对比图\nSessionServer 与 DataServer 数据对比机制 当服务 Publisher 上下线或者断连时，相应的数据会通过 SessionServer 注册到 DataServer 中。此时，DataServer 的数据与 SessionServer 会出现短暂的不一致性。为了保障这个数据的一致性，DataServer 与 SessionServer 之间通过 推 和 拉 两种方式实 …","date":1583224200,"description":" 本文为《剖析 | SOFARegistry 框架》第七篇，作者明不二","dir":"blog/sofa-registry-data-consistency/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"356cd2beadad494a22e2d480948fce8d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-data-consistency/","publishdate":"2020-03-03T16:30:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-data-consistency/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心数据一致性方案分析 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-data-consistency/","wordcount":4336},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:BootLab/\u0026amp;gt;是《剖析 | SOFABoot 框架》系列，会逐步详细介绍 SOFABoot 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFABoot SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\nSOFABoot :https://github.com/sofastack/sofa-boot\n| SOFA:Boot Lab 认领列表：\n 【已认领】《SOFABoot 总览》 【已认领】《SOFABoot runtime 机制解析》 【已认领】《SOFABoot HealthCheck 机制解析》 【已认领】《SOFABoot 日志隔离解析》 【已认领】《SOFABoot 上下文隔离机制解析》 领取方式：关注 「金融级分布式架构」 回复可领取的文章标题，我们将会主动联系你，确认资质后，即可加入 SOFA:BootLab/，It\u0026amp;rsquo;s your show time！\n 如果有同学对以上某个主题特别感兴趣的，可以留言讨论，我们会适当根据大家的反馈调整文章的顺序，谢谢大家关注 SOFAStack ，关注 SOFABoot，我们会一直与大家一起成长的。\n除了源码解析，也欢迎提交 issue 和 PR： SOFABoot：https://github.com/sofastack/sofa-boot\n欢迎领取，参与共建~\n","date":1583208000,"description":"","dir":"activities/sofa-boot-lab/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ee08908ed6148190ca7ebcc0cdc5a3fc","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-boot-lab/","publishdate":"2020-03-03T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-boot-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:BootLab/\u0026gt;是《剖析 | SOFABoot 框架》系列，会逐步详细","tags":["SOFALab","SOFABoot","剖析 | SOFABoot 框架"],"title":"\u003cSOFA:BootLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-boot-lab/","wordcount":542},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@朱楠 提问：\n SpringBoot 集成 Seata Saga 模式后启动报了这个错，有谁知道是什么情况吗？不知道问题出在哪，我就参照Saga 的 demo 来配置的。 A：这个事务异常了，然后 server 端出发了事务恢复，但是这条事务在客户端已经没有了。\n @Reference 这个注解没有 id 或者 name 的属性，试了几次还是不行，实在不行我就用配置文件的方式主入 Dubbo 服务了。 A：其实这也合理，因为 @Reference 是作用在一个类的 field 或 method 上面的，而状态机引擎它不是一个 field 或 method，所以状态机引擎不应该用访问这个类的 reference，而是应该访问一个 spring 上下文作用域的 reference 。我看了一下 Dubbo 的源码 @Reference 这种它并不会注册成为一个 bean，只是生成一个代理然后注入到这个引用它的属性里。所以状态机默认是取 bean 的形式拿不到 bean，你用 xml 的方式引用一个服务。状态机的编排本来就不是用 Java 代码上编排的，而 @Reference 是用于编程方式使用的。 Seata：https://github.com/seata/seata\n2、@魏敏 提问：\n 请问一下，关于 tomcat 的 ajp 漏洞，使用的 SOFABoot 是否受影响呢？https://www.cnvd.org.cn/webinfo/show/5415\n A：针对此次 Tomcat 的 AJP 协议漏洞，SOFABoot 内置的 Tomcat 默认是不会打开 AJP Connector 的，也就是说默认情况下所有版本的 SOFABoot 都是安全的。但是如果你自行打开了 AJP Connector，或者认为风险较大，可以通过覆盖 SOFABoot 管控的 Tomcat 版本进行升级，在主 pom 中的 properties section 指定 Tomcat 版本：\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;!-- other properties goes here --\u0026amp;gt; \u0026amp;lt;tomcat.version\u0026amp;gt;9.0.31\u0026amp;lt;/tomcat.version\u0026amp;gt; \u0026amp;lt;!-- Tomcat 升级规则如下： - 9.x 版本升级至 9.0.31 及以上 - 8.x 版本升级至 8.5.51 及以上 - 7.x 版本升级至 7.0.100 及以上 --\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; SOFABoot：https://github.com/sofastack/sofa-boot\n3、@jinn 提问：\n MOSN 与 Envoy 不同点是什么？优势在哪里？\n A：简单描述一下：\n 语言栈的不同：MOSN 使用 Go 语言技能栈对于使用 Java 语言的公司和个人心智成本更低。 核心能力的差异化： MOSN 支持多协议框架，用户可以比较容易的接入私有协议，具有统一的路由框架； 多进程的插件机制，可以通过插件框架很方便的扩展独立 MOSN 进程的插件，做一些其他管理，旁路等的功能模块扩展； 具备中国密码合规的传输层国密算法支持； MOSN：https://github.com/mosn/mosn\nSOFAChannel 线上直播集锦 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.10.0 版本，主要变更如下：\n 分离部分 MOSN 基础库代码到 mosn.io/pkg； 分离部分 MOSN 接口定义到 mosn.io/api； 支持多进程插件模式； 部分代码实现细节优化； Bug Fix； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.10.0\n社区直播预告 SOFAChannel#12 线上直播将邀请蚂蚁金服分布式事务核心开发仁空分享介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1582873200,"description":"【02/24-02/28】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200228/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"825d23ac19f5c5ae4cfaca517a9a87fd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200228/","publishdate":"2020-02-28T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200228/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布、直播系列整理、0312直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200228/","wordcount":1935},{"author":"SOFA 团队","categories":"SOFAArk","content":" SOFA:Channel/，有趣实用的分布式架构频道。\n本文根据 SOFAChannel#11 直播分享整理，主题：从一个例子开始体验轻量级类隔离容器 SOFAArk。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群：23372465，不错过每场直播。\n 大家好，我是玄北，SOFAArk 开源负责人，今天跟大家分享的主题是《从一个例子开始体验轻量级类隔离容器 SOFAArk》，会跟大家一起解读 SOFAArk ，也会讲解一个 Demo 案例，希望大家可以跟我一起实际操作，体验 SOFAArk 具体操作以及功能实现。\nSOFAArk：https://github.com/sofastack/sofa-ark\n今天的分享将从一下面三个方面展开：\n 初识 SOFAArk； 组件运行时； 动手实践； 今天的重点是最后一个部分的动手实践，前面两部分会跟大家简单介绍一下 SOFAArk 的基础概念，希望在最后一个实践部分，大家可以跟着我一起通过 Demo 实际操作体验 SOFAArk，也可以在实践过程中帮助大家更好得了解前面介绍到的概念。\n一、初识 SOFAArk 现在我们就开始了解 SOFAArk，在实践之前，我们先来了解一下什么是 SOFAArk。SOFAArk 是蚂蚁金服开源的一款基于 Java 实现的轻量级类隔离容器，欢迎大家关注并 Star SOFAArk。\nSOFAArk：https://github.com/sofastack/sofa-ark\n在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案。产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin）； 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz)； 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制； 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz； SOFAArk 可以帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\nSOFAArk 中有三个最主要的概念，分别是 Ark 包、Ark Biz 包、Ark Plugin 包：\nArk 包：类似 Spring Boot 的打包产物，是一个 Fat Jar，即应用交付终态，一个 Ark 包，可以通过 Java-jar 的方式把它运行起来。\nArk Biz 包: 简称 Biz，是组件的交付终态，大家通过名字也可以理解，里面主要封装了一些业务逻辑。\nArk Plugin 包: 简称 Plugin，提供把非业务基础组件下沉的能力，比如 RPC、消息等。\n接下来按照上述三个的顺序，我们来看一下这三个包里主要是什么。\nArk 包目录结构 下图是 Ark 包的目录结构，Ark 包下有 Biz 目录，Container 目录，Plugin 目录，Biz 目录中就是一个一个的 Ark Biz，Plugin 目录保存了所有的 Ark Plugin，Container 是 Ark 容器，Ark 容器会负责启动 Ark Plugin 及 Ark Biz。\nArk Biz 包目录格式 介绍完 Ark 包的目录格式，接下来介绍 Ark Biz 包的格式：\n在 Ark Biz 包的目录格式里同样有几个比较关键的目录格式，分别是：\n application.properties：标准 Spring Boot/SOFABoot 工程配置文件； lib 目录：应用依赖目录； META-INF/MANIFEST：Biz 配置文件。 Ark Plugin 包目录结构 接下来跟大家介绍 Ark Plugin 包，Ark Plugin 包的目录结构与 Ark Biz 包的目录结构类似，但是 Ark Plugin 包的 META-INF/MANIFEST.MF 文件会比 Ark Biz 包复杂一点，Ark Plugin 支持在 META-INF/MANIFEST.MF 文件中定义 Import package、Export package、Import classes 以及 Export classes 等属性，这些属性支持 Plugin ClassLoader 在加载类或者资源文件时可以委托给其他 Plugin 加载。\n上文介绍了 Ark 包、Ark Biz 包、Ark Plugin 包的目录结构，接下来我们介绍下 Ark 包运行时的整个运行时结构。通过下面这张图我们可以看到，在整个运行时，Ark 包分为三层，底层是 Ark Container，中间层是 Ark Plugin，上层是 Ark Biz。Ark Container 负责启动所有 Ark Plugin 及 Ark Biz，Ark Plugin 支持类导入导出能力，所以 Ark Plugin 之间有双向箭头相互委托。为了简化 Ark Biz 的使用，Ark Biz 不支持导入导出类，Ark Biz默认会导入所有 Ark Plugin 的类。\nSOFAArk 的不同 Plugin 相互委托类加载的能力可以帮助我们解决一个文件场景，那就是依赖冲突：\n以上图的场景为例，有一个 Project，依赖了 Dependency A 以及 Dependency B，这两个依赖依赖了不同版本的 Hessian，Dependency A 依赖了 Hessian 3，Dependency B 依赖了 Hessian 4，Hessian 3 与 Hessian 4 是不兼容的，会出现冲突，那么要如何解决这个问题呢？\nSOFAArk 就给出了一个解决方案。如果我们的 Dependency A 跟 Dependency B 的 Hessian 依赖有冲突的话，我们可以把 Dependency A 作为一个整体打包成一个 Ark Plugin， Dependency B 作为一个整体打包成一个 Ark Plugin，每个 Ark plugin 都是一个单独的 Classloader，这样 Dependency A 使用的 Hessian 3 和 Dependency B 使用的 Hessian 4 将不再冲突。\n解决依赖冲突是 SOFAArk 的一个主要使用场景，但是今天我们不详细介绍这个场景，今天主要介绍 SOFAArk 的另一个能力，即组件运行时能力。\n二、组件运行时 组件运行时提供了一种能力，它能够在不重启应用的前提下，通过动态安装、卸载、切换 Biz 模块，实现修改应用运行方式的目的。下图展示了组件运行时的运行时结构，整个运行时结构与上文的 Ark 包运行时结 …","date":1582700400,"description":"本文根据 SOFAChannel#11 直播分享整理。","dir":"blog/sofa-channel-11-retrospect/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a3216377eb47b27325f279f124c2bfd8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-11-retrospect/","publishdate":"2020-02-26T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-channel-11-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#11 直播分享整理，主题：从一个例子开始体验轻量级类隔离容器 SOFAArk。 回顾视","tags":["SOFAArk","SOFAChannel"],"title":"从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-11-retrospect/","wordcount":4342},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@朱楠 提问：\n 请教下，我看文档上有说json可以热部署，有demo吗，没怎么看明白如何热部署 A：就是用这个回答里的这个方法 registerByResource，Java 代码的热部署可以用 SOFAArk，stateMachineEngine 是一个 bean，可以在代码里注入这个 bean，然后你可以实现一个 web 页面，可以上传 json 文件和 jar 包，调用图片中的方法注册状态机，用 SOFAArk 注册 jar 包。\n 我在看 registryByResources 这个方法的源码，注册状态机是不是就不需要修改本地的 json 文件了？\n A：注册了 json，如果数据库里有名称相同的，它会对比字节码，如果不一样，则创建新版本，一样则不注册，新启动的状态机实例用新版本，已启动的状态机实例用老的。\n 懂了，你这里说的上传 jar 包是什么意思？\n A：因为状态机里定义了要调用服务，这个服务可能是目前在系统里没有引用，所以需要上传 jar。\n2、@刘川江 提问：\n Seata Saga 模式服务（ServiceTask）之间如何在运行时传递业务参数？如将服务A运行后的生成的业务对象传递到后续的服务中进行处理。\n A：用 Output 和 Input 属性： Input: 调用服务的输入参数列表, 是一个数组, 对应于服务方法的参数列表, $.表示使用表达式从状态机上下文中取参数，表达使用的 SpringEL, 如果是常量直接写值即可； Ouput: 将服务返回的参数赋值到状态机上下文中, 是一个 map 结构，key 为放入到状态机上文时的 key（状态机上下文也是一个 map），value 中$.是表示 SpringEL 表达式，表示从服务的返回参数中取值，#root 表示服务的整个返回参数。\n 是否支持根据业务参数中的某些值作为条件判断状态机中的服务（ServiceTask）是否执行？\n A: 支持的，可以用 Status 属性来判断 Service 是否执行成功。 Status: 服务执行状态映射，框架定义了三个状态，SU 成功、FA 失败、UN 未知, 我们需要把服务执行的状态映射成这三个状态，帮助框架判断整个事务的一致性，是一个 map 结构，key 是条件表达式，一般是取服务的返回值或抛出的异常进行判断，默认是 SpringEL 表达式判断服务返回参数，带 $Exception{ 开头表示判断异常类型。value 是当这个条件表达式成立时则将服务执行状态映射成这个值。\n 是否支持状态机中的部分服务开启事务。如状态机配置了服务流程A-\u0026amp;gt;B-\u0026amp;gt;C，只在服务B和C上开启分布式事务。\n A：可以，比如 A 是一个查询类的服务，可以将 A 设置成 IsForUpdate=false，如果这个服务不想记录执行日志，可以设置这个服务为 IsPersist=false。\nSeata：https://github.com/seata/seata\n3、@SUNBIAO 提问：\n 请问 SOFA 消费者端可以同时配置多个注册中心嘛？例如一个 web 控制器接入端当作消费者，配置连接多个注册中心，订阅不同注册中心上的生产者服务，但是这个消费者端不同的具体消费者调用不同注册中心的服务，前提是注册中心不能合成一个，现实有多个不同的注册中心。\n A：可以的，可以看这个类 com.alipay.sofa.rpc.config.AbstractInterfaceConfig#registry， 是个 list。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n4、@七美 提问：\n SOFATracer 目前落盘的摘要 log 是固定格式的，能否直接以 zipkin 的 json 数据格式落盘？如果可以如何操作？\n A：使用自定义 reporter ： https://www.sofastack.tech/projects/sofa-tracer/reporter-custom/ + ZipkinV2SpanAdapter 来实现。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n每周读者问答提炼 蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 SOFA 项目进展 本周发布详情如下：\n1、发布 Seata v1.1.0 版本，主要变更如下：\n 支持 postgreSQL； 支持自定义 Saga 恢复策略超时时间； 支持 Saga 模式跳过成功分支事务的 report； 支持httpClient 自动集成； 详情发布报告：https://seata.io/zh-cn/blog/download.html\n2、发布 SOFARPC v5.6.4 版本，主要变更如下：\n 试验性支持 RPC 可能的多版本发布； 升级 Dubbo 依赖版本到2.6.7； 优化 gRPC 支持代码； 升级 Netty 版本4.1.44.final，解决安全问题； 修复 Tracer 采样兼容问题； 修复注册中心虚拟端口的问题； 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.4\n3、发布 SOFABoot v3.3.0 版本，主要变更如下：\n 健康检查页面显示组件的具体绑定类型； RPC XML 超时配置支持字符串变量； 修复无法使用 zk 以外注册中心的 bug； 修复控制台大量输出的 bug； 升级 Spring Boot 依赖版本至 2.1.11.RELEASE； 升级 RPC 版本至 5.6.4； 升级 sofa-common-tools 版本至 1.0.21； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.3.0\n4、发布 sofa-common-tools v1.0.21 版本，主要变更如下：\n 修复类隔离情况下 classloader 加载问题； 详 …","date":1582268400,"description":"【02/17-02/23】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200221/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b82b9b4c82bc3905d736962bd157238c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200221/","publishdate":"2020-02-21T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200221/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 3/12直播预告、SOFARPC、SOFABoot 组件发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200221/","wordcount":2625},{"author":"盲僧","categories":"SOFABoot","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFABoot 框架》第二篇，本篇作者盲僧，来自遨游酒店信息技术。《剖析 | SOFABoot 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:BootLab/]()，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFABoot 是蚂蚁金服开源的基于 SpringBoot 的研发框架，提供了诸如 Readiness Check、类隔离、日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\n本文将从 Java 的日志体系谈起，对 JCL、SLF4J 两个经典的日志框架做一个阐述，引出 SOFABoot 开源的日志隔离框架 sofa-common-tools ，并且有实战 Demo，能够帮助我们快速上手和了解这款框架的使用和作用，最后从源码角度对其进行分析，不仅知其然，还要知其所以然。\nSOFABoot ：https://github.com/sofastack/sofa-boot\nsofa-common-tools ：https://github.com/sofastack/sofa-common-tools\nJava 日志问题 业务开发对日志的选择 众所周知，Java 的日志体系非常复杂，有 Log4j、Log4j2、Logback、JUL 等实现，这么多的日志实现让开发人员在选择上不得不犯晕，因为每个日志实现都对外提供了不同的 API，而且还要担心与项目中现有的第三方框架依赖的日志实现产生冲突问题，甚至还要去维护第三方框架带来的日志依赖。在这些问题的基础上，Java 日志框架应运而生，典型的有 JCL 和 SLF4J。\nJCL JCL 即 Apache Commons Logging，它的原理是提供了一套接口，用户使用了它的接口进行编程，具体实现交由它的 LogFactoryImpl 去动态查找， 但是它并不能绑定所有的日志实现，因为查找绑定的日志实现是放在 classesToDiscover 数组里写死的，导致扩展起来比较麻烦，当前最新版本是 1.2 版本，还不支持绑定 Log4j2 和 Logback。\nSLF4J 于是乎，大名鼎鼎的 SLF4J 出现了，它的存在就是为了替换 JCL，所以肯定提供了比 JCL 更强大的功能。同样是面向接口编程的设计，但是 SLF4J 充分考虑到了后期的扩展问题：一旦市面上有新的日志实现，那么只需要提供新的绑定包即可，相对于 JCL 的动态绑定，SLF4J 实际上是静态绑定，因为应用程序具体要选用哪种日志组件是由开发人员使用哪个绑定包决定的。绑定原理请看下图：\n除此之外，SLF4J 还提供了桥接包，它的意思是指可以把使用某个具体 Log 组件的 API 重定向到 SLF4J 的 API 里（前提需要排除具体实现包，然后引入桥接包），然后 SLF4J 会根据具体的绑定包输出内容，从而达到多种日志实现统一输出的目的。绑定原理请看下图：\n中间件对日志的选择 上面解决了业务开发人员的问题，那么对于从事中间件的开发者来说呢？日志依旧是一个痛点。参考一些中间件项目，如 zookeeper 使用的是 log4j ，hibernate-validator 使用的是 jboss-logging，当业务开发人员去集成这些第三方组件时，就会感到头疼，因为这些组件的日志实现很有可能会和当前业务自身的日志依赖产生冲突。常用的解决方法就是排除某一种日志实现依赖，然后修改 appender 和 logger 达到日志隔离。但这并不是一个一劳永逸的方法，因为每次引入新的 jar 包，你都需要考虑是否有日志冲突。\n那么市面上是否有成熟的框架来解决这个问题呢？当然是有的，蚂蚁金服开源的 SOFABoot 就提供了这样的功能，底层主要是通过 sofa-common-tools 实现的。那么 sofa-common-tools 又是个啥呢？借用官网的描述： sofa-common-tools 是 SOFAStack 中间件依赖的一个通用工具包，通过自动感知应用的日志实现，提供中间件与应用隔离的日志空间打印能力。\n本篇将通过一个案例 demo 先来直观的体验下 sofa-common-tools 所能解决的问题，然后再在此基础上，通过源码解析了解其内部的具体实现原理，以帮助大家更好的认识和了解 sofa-common-tools 这个“小而美”的日志工具包。\n日志隔离实战 完整项目已经上传到 https://github.com/masteryourself/study-sofa.git ，工程是 study-sofa-common-tools\n 有这样一个场景：公司的中间件团队做了一款 middleware-apm 监控系统，并且通过以输出日志的方式向监控系统提供基础数据。由于公司并没有制定统一的日志规范，各个业务方所使用的日志也是千差万别；如：如订单系统使用的是 log4j，账务系统用的 Logback，用户中心用的是 Log4j2； 如果期望 apm 提供的日志输出和业务的不冲突，可以独立的并且完整的兼容业务日志的不同实现，此时便可以使用 SOFABoot 提供的日志隔离框架；其可以帮助我们解决日志实现冲突、日志文件隔离以及动态调试日志级别等功能。下面就先来看下 apm 是如何使用 sofa-commons-tools 来实现的。\nmiddleware-apm 项目 新建 middleware-apm 工程，然后执行 mvn clean install 命令，安装到本地仓库。具体代码可以参考 middleware-apm ，下面对一些核心代码进行简单的说明和分析。代码结构如下：\n日志资源文件配置 这里主要是在 pers.masteryourself.study.sofa.apm.log 目录下创建 log4j、log4j2、logback 的配置文件，详情请参考 github 链接。\n核心日志工厂类-ApmLoggerFactory ApmLoggerFactory 主要是对外提供获取 Logger 实例的 API 方法，其作用类似于 slf4j 中的 LoggerFactory 类；对于想使用 SOFABoot 日志特性的类，只要使用它调用 getLogger 方法获得的 Logger 实例即可。\nLoggerFactory 和 ApmLoggerFactory 的最本质区别在于 ApmLoggerFactory 引入了 LOG_SPACE 的概念。\npublic class ApmLoggerFactory { // 日志空间 private static final String APM_LOG_SPACE = \u0026amp;quot;pers.masteryourself.study.sofa.apm\u0026amp;quot;; static { if …","date":1582016400,"description":"本文将从 Java 的日志体系谈起，对 JCL、SLF4J 两个经典的日志框架做一个阐述，引出 SOFABoot 开源的日志隔离框架 sofa-common-tools，并且有实战 Demo，能够帮助我们快速上手和了解这款框架的使用和作用，最后从源码角度对其进行分析，不仅知其然，还要知其所以然。","dir":"blog/sofa-boot- log-isolation/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a428e36a94180c1e33920579423b4402","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-log-isolation/","publishdate":"2020-02-18T17:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-boot-log-isolation/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFABoot","剖析 | SOFABoot 框架","SOFALab"],"title":"蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-log-isolation/","wordcount":4632},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@乘疯破浪 提问：\n 咨询一个性能问题，一个 2C 的业务场景：本地库操作多次 db，再调用分布式服务，再 TC 端注册多个分支事务耗时较多，用户 C 端等待时间较长，这种问题有处理方案吗？client 已设置 report 分支状态 =false。\n A：确实比较长，个人建议从架构入手去改良，可以通过存入 redis 等一个消息，告诉用户正在插入-\u0026amp;gt;然后一步出力业务，出现异常同样 redis 里的信息改为异常。如果成功就为成功存储 id 或者其它看业务具体情况,然后用户端页面做个倒计时，或者转圈圈，或者直接告诉他正在插入稍等。比如以前用 MQ 削峰就差不多是这个思路吧。长事务尝试用用 Saga、AT 上手快，但是因为锁的存在，效率比较低，后续会逐步优化，性能高入侵也高的 TCC 如果能尝试也可以试试。\n2、@孟昊 提问：\n 请问一下，我今天看了一下文档，好像 cloud 通过 feign 调用方式只能使用 AT 模式, 在并发量比较高的场景下会有问题么(小事务)。\n A：微服务框架跟分布式事务模式没有绑定，还可以用 TCC、Saga。Saga 目前理论上支持所有 RPC 框架，只要是个 bean 即可。\n3、@小孟 提问：\n MOSN 是否支持了 Dubbo 协议？\n A：MOSN 在本周已通过 x-protocol 支持了 Dubbo 和 Tars 协议，具体可见： https://github.com/mosn/mosn/pull/950\n4、关于线上直播 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk 提问回答\n直播视频回顾：https://tech.antfin.com/community/live/1096\n@鸿关 提问：\n 用 SOFAArk 的话，能直接集成到 SOFABoot 工程不？还是说必须要建个 SOFAArk 的工程？SOFAArk 可以运用于非 SOFABoot 的项目么？\n A： 能直接继承到 SOFABoot 工程，不需要新建 SOFAArk 工程，也可以用于非 SOFABoot 工程，只要是 Spring Boot 工程即可，但是不引入 SOFA 相关依赖的话，@SofaService 及 @SofaReference 等注解就没法用了。\n@盲僧 提问：\n 运行期间安装 biz，然后激活模块这一过程做了哪些事情 ，如果这个 biz jar 包放在远程仓库怎么加载里面的代码呢？是拉下来放到本地的一个磁盘用 classloader 去加载使用吗？\n A：安装和激活是的两个操作，安装支持两种协议获取 biz 包：http 和 file，激活只是在内部调整了同 biz 不同版本的状态。\n 运行期间安装 biz 后，那个 execute jar 包里会有这个 biz 包吗？ A：可以尝试用插件打个包出来解压看下哦。\n @曾鹏 提问：\n SOFAArk 有什么实际的应用场景吗？\nA：可以看下这个：蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析\n SOFAArk：https://github.com/sofastack/sofa-ark\n本周推荐阅读 SOFAStack Community | 欢迎加入 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFATracer v2.4.5\u0026amp;frasl;3.0.9 版本，主要变更如下：\ni. 默认禁用上报数据到zipkin, 需要显式设置 com.alipay.sofa.tracer.zipkin.enabled=true 才能开启； 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.5 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.9\n2、发布 SOFATracer v2.4.6v/v3.0.10 版本，主要变更如下：\ni. 支持使用 JVM系统属性 或 环境变量 SOFA_TRACER_LOGGING_PATH 来定制 tracelog 的路径 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.6 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.10\n社区直播预告 本期为 SOFAChannel 线上直播第 12 期，将邀请蚂蚁金服分布式事务核心开发仁空分享《蚂蚁金服分布式事务实践解析》。\n软件开发模式从原来的单应用，到现在的微服务、分布式架构，一个大型分布式系统内，单业务链路往往需要编排多个不同的微服务，如何实现分布式场景下业务一致性，是摆在软件工程师面前的一个技术难题。\n本期分享将介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1581667200,"description":"【02/10-02/14】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200214/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3deaf12dd1b6589f41c57291d9061534","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200214/","publishdate":"2020-02-14T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200214/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 2/13直播回顾、3/12直播预告、SOFATracer 发版","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200214/","wordcount":1781},{"author":"SOFA 团队","categories":"Service Mesh","content":" 2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。\n参与问卷调查的人员情况 共收集到 516 份问卷结果，问卷填写者 94.2% 来自 ServiceMesher 社区，21.7% 的人参与过社区线上活动，27.5% 的人参与过社区 meetup，86.6% 看好 Service Mesh 的未来发展前景。\n下面是参与问卷调查人员的基本情况。\n公司所属行业\n所在公司的 Service Mesh 使用情况\n工作年限\n在公司中担任的职务\n关注 Service Mesh 技术的时长\n周围关注或了解 Service Mesh 技术的人员情况\n学习 Service Mesh 技术的方式\n关注的 Service Mesh 相关开源项目\n除了 Service Mesh 外关注的其他云原生领域\n对 Service Mesh 的了解程度\n关注 Service Mesh 技术中的哪部分\n社区参与 了解社区活动的情况\n对社区的建议\n还有很多对社区的建议，反馈比较多的如下：\n 更多落地实践和指南 发布一些入门级的文章，结合案例，让技术在中小企业中落地 组织一些线上或线下活动 对普通开发者的职业发展的建议 出系列教程 结论 从结果中可以看出，Service Mesh 在互联网公司中关注的比例最高，但是它仍然还在高速发展中，还缺乏完善的教程和案例。\n本次问卷调查旨在了解 ServiceMesher 社区成员对 Service Mesh 的了解及社区参与程度，帮助 ServiceMesher 社区做的更好，还需要社区成员们共同的努力。\n欢迎关注 Service Mesh 技术的小伙伴们加入 ServiceMesher 社区，共同交流学习和成长。\n关于本次调查问卷的最终解释权归 ServiceMesher 社区所有。\n","date":1581667200,"description":"2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。","dir":"blog/service-mesh-end-user-survey-report/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e2f1dc19ca9ab916db565bdd2bd5a50f","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-end-user-survey-report/","publishdate":"2020-02-14T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/service-mesh-end-user-survey-report/","summary":"2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。 参与问卷调查的人员情况 共收集到 516 份问卷结","tags":["Service Mesh"],"title":"Service Mesh 终端用户调查报告","type":"blog","url":"/sofastack.tech/blog/service-mesh-end-user-survey-report/","wordcount":530},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n 活动时间：3 月 12 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#12：蚂蚁金服分布式事务实践解析 软件开发模式从原来的单应用，到现在的微服务、分布式架构，一个大型分布式系统内，单业务链路往往需要编排多个不同的微服务，如何实现分布式场景下业务一致性，是摆在软件工程师面前的一个技术难题。\n蚂蚁金服作为一家金融科技公司，业务涉及金融核心的各个领域，从2007年开始就自主研发了分布式事务框架，解决跨数据库、跨服务的业务一致性问题；随着13来年的不断打磨和沉淀，历经双十一、双十二等大促的洗礼，如今所有核心业务都已经在使用这套框架来保障交易的完整性和最终一致性，做到知托付，让用户放心。\n本期分享将介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n本期为 SOFAChannel 线上直播第 12 期，将邀请蚂蚁金服分布式事务核心开发仁空分享《蚂蚁金服分布式事务实践解析》。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1096\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 仁空，蚂蚁金服分布式事务核心开发\n本期分享大纲 分布式事务产生的背景； 蚂蚁金服分布式事务理论与实践； TCC 模式 FMT 模式 蚂蚁金服分布式事务极致性能提升； 蚂蚁金服分布式事务开源与展望； 嘉宾 SOFAGirl 主持人 仁空，蚂蚁金服分布式事务核心开发 ","date":1581498000,"description":"3 月 12 日周四晚 7 点，线上直播第 12 期。","dir":"activities/sofa-channel-12/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c80a24fd4e76747f0ed57c139a2bfae9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-12/","publishdate":"2020-02-12T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-12/","summary":"概要 活动主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析 活动时间：3 月 12 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍 | SOFAChannel","tags":["SOFAChannel","分布式事务"],"title":"SOFAChannel#12：蚂蚁金服分布式事务实践解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-12/","wordcount":784},{"author":"纶珥","categories":"SOFALab","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFABoot 框架》第一篇，本篇作者纶珥，来自蚂蚁金服。《剖析 | SOFABoot 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:BootLab/]()，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFABoot 是蚂蚁金服开源的基于 SpringBoot 的研发框架，提供了诸如 Readiness Check、类隔离、日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\nSpringBoot 基于 Spring 的按条件配置（Conditional Configuration），结合 starter 依赖机制提供了快捷、方便开发 Spring 项目的体验，获得了极大的成功；SOFABoot 同样在这两个能力上基于 SpringBoot 扩展出适应于金融级应用开发框架。作为脱胎于蚂蚁金服内部对于 SpringBoot 的实践，SOFABoot 补充了 SpringBoot 在大规模金融级生产场景下一些不足的地方，例如 Readiness 检查、类隔离和日志空间隔离等等能力。在增强了 SpringBoot 的同时，SOFABoot 还提供了让用户可以在 SpringBoot 中非常方便地使用 SOFAStack 中间件的能力。\nSOFABoot ：https://github.com/sofastack/sofa-boot\n功能点概览 SOFABoot 完全兼容 SpringBoot，SpringBoot 技术栈可以快速切换到 SOFABoot 技术栈：修改项目 pom 依赖的 \u0026amp;lt;parent/\u0026amp;gt; 节点，例如将：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 当前 SOFABoot 的最新版本为 v3.2.2。\n应用 Readiness 检查 一个应用启动之后，是否是“准备”好能够处理外部请求呢？作为应用流量入口的组件是否可以接收外部连接？这就很有必要引入应用 Readiness 的检查，SOFABoot 提供除 SpringBoot 健康检查之外的应用 Readiness 检查能力，保证应用组件的正常启动、应用安全上线。\nSOFABoot 通过 HealthChecker 检查各组件的 ready 情况。在 Spring 上下文刷新完成之后（所有的 Spring Bean 已经实例化完成），SOFABoot 会获取 IoC 容器中所有的 HealthChecker 实现类，检查其返回的组件健康状况；在应用开启了模块化隔离之后，模块 HealthChecker 还会 kicks in，检查模块的健康状况。Spring 原生的 HealthIndicator 作为 Readiness 的一部分也会纳入 Readiness 的结果中，若 HealthIndicator 出现了失败的情况，那么应用的 Readiness 也是不通过。\nReadiness 检查包含组件的后置检查，流量入口组件（例如：RPC、REST）需要保证后置检查通过之后能接受外部流量的请求，应用才是真正 ready 了。\n应用 Readiness 与 Liveliness 不同的是 Readiness 表示的是应用启动完成之后是否“准备”好的状态，启动完成之后是不变的；两次部署间的 Readiness 的所有请求结果是一致的。\n应用模块化 应用模块化的方案多种多样。传统方案是以应用功能为边界做模块划分；研发期间，不同职责的类放在不同的模块下，但在运行期间都在同一个 classpath 下，没有任何隔离。而与传统的模块划分方案不同，人们发现可以利用 Java 的 ClassLoader 机制，将模块与模块间的类完全隔离；当某个模块需要与另一个模块通信时，可以通过类的导入和导出来实现。OSGi 和 SOFAArk 都是基于 ClassLoader 隔离的模块化实践方案。\n传统的模块化方案没有任何的隔离手段，模块间的边界得不到保障，容易出现模块间的紧耦合；而基于 ClassLoader 的模块化方案则过于彻底，研发人员必须十分清楚类的导入与导出、Java 的类加载体系，模块划分的负担转嫁到了普通研发人员身上。\nSOFABoot 综合以上两种方案的利弊，引入了介于两者之间的模块化方案：每个模块有独立的 Spring 上下文，通过上下文的隔离，让不同模块之间的 Bean 的引用无法直接进行，达到模块在运行时的隔离。这样既保证了不引入过多的复杂性，也避免了没有任何隔离措施的模块边界保障。如下图所示：\n所有的 SOFABoot 模块都会有一个相同的 Spring Context 的 Parent，称之为 Root Application Context。对于所有模块都需要引入的 Bean，可以选择将其放置于 Root Application Context 中，在所有的模块间共享。此外，SOFABoot 框架提供两种 Spring 上下文隔离方案后的模块间通信能力：\n JVM 服务的发布和引用：同一个应用内不同模块间的通信 // Publish a JVM service @Component @SofaService public class MyServiceImpl implements MyService { // implementation goes here } // Reference a JVM service public class AnyClass { @SofaReference private MyService myService; } RPC 服务的发布和引用：不同应用间的通信 // Publish a RPC service @Component @SofaService(interfaceType = MyService.class, bindings = { …","date":1581321600,"description":"本文为《剖析 | SOFABoot 框架》第一篇，主要介绍 SOFABoot 的基础特效。","dir":"blog/sofa-boot-overview/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d1a5fa7654f26a159c65061d4f7712d7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-overview/","publishdate":"2020-02-10T16:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-boot-overview/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFALab","剖析 | SOFABoot 框架","SOFABoot"],"title":"蚂蚁金服研发框架总览 | SOFABoot 框架剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-overview/","wordcount":3219},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@张一心 提问：\n 建议 Seata 全局加锁时候支持快速抢占机制，在不同重要程度事务处理中优先满足重要业务的加锁处理以优先保证紧急重要逻辑的处理，实现方式有多种的，可以根据情况直接回滚干掉非紧急事务也可以在等待加锁队列中做插队处理。\n A：不是通用场景，这个不是通过 API 来实现，后续添加控制台后，在控制台页面对活动事务可以进行控制，可单个事务降级或 redo。\n 之前我是通过改造其值来源于 Nacos 配置的全局事务注解完成的，有了单独事务控制台能起到各司其职更好，既然后续补充了控制台，是不是事务处理的各类统计也能在控制台上面看得到，作为一系列资源分配的参考指标。\n A：控制台主要包括监控统计和事务控制介入，你说的应该是动态降级，这个是全局的，细化不到刚才说的那种抢占机制比如手动在控制台的具体某个事务进行降级释放锁，直接通过 API 这个数据破坏性无法控制，对于这种需要人工去介入并且有 trace。\n 实际生产中涉及金钱交易的优先级往往高于非金钱交易的优先级。破坏性来源主要是加锁中的破坏性回滚，实际业务中往往会存在不能锁刚好被加在队列中等待一阵的现象，这时候完全可以根据全局标记做全局性插队，在处理中加快相关业务处理。监控粒度不应该忽视锁的名称，全局业务的加锁顺序和持有时间，不然当业务量大且相互交叉发生全局性死锁也是会存在的。确切说是业务量大并且分布在不同 TC 上加锁情况下可能会产生哲学家就餐问题带来的死锁。\n A：这里不存在死锁，先拿的是数据库的 X 锁，在拿的是全局锁，你可以举个栗子。一种优先级是处理前优先级类似于 mq 的优先级队列，这种是哪个事务优先被处理，这种是需要兼顾顺序和锁优先级排序，高优先级事务分支优先被处理。 一种是处理中的锁被剥夺，这种是破坏性的，如果在一个不重要的事务中分支1执行完成，另外一个重要事务请求分支1同样的锁，这个锁这时可被剥夺，不重要事务释放锁降级非分布式事务。大多数冲突的情况应该属于处理中而不是处理前。\n 根据测试经验，量小的时候会等，量大的时候会直接碰撞，量进一步加大则除了碰撞而且跑队列里一起挤挤的概率就会飙上去。这时候会遇到几个难点，1队列下是不是插队（这个通过认为设置比较好解决）2抢占是否必要，这时候需要通过对之前加锁的统计（包括业务处理时间与网络通信等综合指标）和潜在破坏性做评估，如果破坏性较小或无且不抢占下对业务预等待时间较长且其他回滚表较为独立则直接回滚抢占，最典型场景就是扣钱的时候充值，或者出货的时候补货。\n A：第2中的破坏性来源于不重要事务锁被剥夺降级为非分布式事务，但是由于后续事务分支出现异常，会导致这个事务分支无法参与回滚，若参与回滚必会导致重要事务全局回滚时数据校验不通过而无法回滚。\n 对，校验不通过关键在于目前采用的是全量型业务，而不是基于对 sql 语句解析之后的增量型业务（即 TCC 的 cancel 步骤里反向对冲）。\n A：对于 AT 模式都是基于数据的不是基于 sql 的，与 binlog 同步方式类型同理。\n 下面问题来了，数据破坏是因为先去 TC 报道还是先去数据库加锁造成的。如果先去 TC 报道，等报道成功再去 DB 加锁就不会发生数据破坏的问题，因为报道失败就直接返回了不会对 DB 造成影响。\n A：那个锁的范围更大些，肯定是 DB 的 X 锁。服务是操作 DB 的，如果连 DB 锁拿不到，拿全局锁有什么意义，假设先拿全局锁，数据库锁拿不到时是不是又需要 RPC 去释放全局锁？\n 不知道有没必要添加对全局读写锁的支持，这个个人未实践过，纯属个人观点，也不知道现在是否已经实现了？\n A：这个说的是类似 JUC 的读写锁嘛？如果单纯这样没什么实际意义，现在是类似数据库 select for update 的 X 锁上升到全局锁。\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.9.0 版本，主要变更如下：\n 引入嵌入模式； 升级 SGX SDK 依赖到最新版； 大幅提升网络 I/O 的性能； 正式支持 Python 语言的应用； 正式支持 Ubuntu 18.04 和 CentOS 7.2； 修复了多个 bug； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.9.0\n社区直播预告 春节后直播预告来啦～本期为 SOFAChannel 线上直播第 11 期，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n时间：2020年2月13日（周四）19:00-20:00\n嘉宾：玄北，蚂蚁金服技术专家 SOFAArk 开源负责人\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1581066000,"description":"【02/03 - 02/07】 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200207/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4e10f9b05976b3f0f8ce4d9128fa8d79","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200207/","publishdate":"2020-02-07T17:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200207/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 落地系列文章、2/13直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200207/","wordcount":2288},{"author":"柑橘、西经、柏翘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，该系列从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n前言 Service Mesh 在蚂蚁金服内部已经大规模落地，经历刚刚双十一的检阅，将现有的体系快速演进至 Service Mesh 架构，无异于给飞机换发动机。本主题主要分享在蚂蚁金服当前的体量下，我们如何做到给飞机换发动机，还确保不出问题。同时在 Mesh 对外客户输出同样有高质量的保障。\n本文结合蚂蚁金服 Mesh 化落地质量保障落地的思考，给大家带来如下三个方面的一些质量保障的分享：\n Mesh 化质量保障体系； Mesh 化测试技术； Mesh 化双十一大规模落地的性能保障； 质量保障体系 首先给大家介绍下我们的质量保障体系。\n测试保障体系\n我们从测试环境、测试用例、基础功能测试原子镜像能力、测试工具平台、测试场景组合调度、测试方案制定、线上巡检监控、灰度发布三板斧、交付验证、性能、自动化测试等多个方面进行系统性测试保障。通过内外部的质量数据度量和双十一大促来检阅我们的质量能力。\nMesh 测试技术 在开始介绍测试技术之前，我们先了解一下什么是 Service Mesh 以及 Service Mesh 是如何工作的，在蚂蚁金服的技术架构中是以什么形式存在，发挥着怎样的作用。\n简单的说 Service Mesh 存在两个面，一个面叫数据面（比如 MOSN），就是处理应用数据请求的一个独立代理模块，脱离于应用，为应用提供请求代理及一些复杂通信逻辑处理，另外一个叫控制面（比如 SOFAMesh），管理应用配置及业务规则等（比如业务开关/服务路由规则），通过下发配置“指挥”数据面去执行，满足不同阶段实现不同的业务支持。\nMesh 框架简图\n我们先简单介绍下经典微服务请求路由。\n经典微服务模式请求路由\n经典微服务模式下 Docker 镜像化服务在一个 Pod 一般只有一个业务应用容器在运行，这种情况下测试框架只要关心业务应用即可。\n经典微服务测试架构\nMesh 测试架构改进 Mesh 测试架构在经典微服务测试架构上也做了新的演进。MOSN 作为 Sidecar 与业务容器共存在一个 Pod，资源与业务应用容器共享，每个业务逻辑都需要通过 MOSN 去处理，因而只关心业务应用肯定不够，需要再扩展支持到 MOSN 这类 Sidecar 的测试验证。在 MOSN 中集成了控制面 xds client，与控制面 pilot 建立通信，用于接收 pilot 下发的配置信息。在蚂蚁金服技术架构存在三地五中心/同城双活等容灾能力，因而产生了 LDC，一个集群多个 zone 情况，控制面 pilot下发是可以配置集群+zone+应用+ip 组合粒度，要验证这个多 zone 下发规则准确性，那就需要创建多个 xds client（或者 MOSN）。另外 Sidecar 是不能直接访问的，通过测试应用暴露出接口，给上层测试。\nMesh 化测试架构\n构建高仿真测试环境 那么，我们测试环境要做到足够仿真，面临哪些挑战呢？首先看下我们自研的 MOSN 具备的能力和技术复杂性。\n MOSN 能力大图\n应对 MOSN 测试场景复杂性，我们搭建了一套高仿真测试环境，这里以 MOSN 中的 RPC 功能为例，阐述这套环境的构成要素及环境部署架构。\n集成测试环境构成要素\n这里可以举一个 RPC 路由的例子来详细讲述。我们知道，业务在做跨 IDC 路由时，主要通过跨域 VIP 实现，这就需要业务在自己的代码中设置 VIP 地址，例如：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.APPNAME.facade.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleRpcService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.tr\u0026amp;gt; \u0026amp;lt;sofa:vip url=\u0026amp;quot;APPNAME-pool.zone.alipay.net:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.tr\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 这时候假如业务配置了不合法的 URL，如：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.APPNAME.facade.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleRpcService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.tr\u0026amp;gt; \u0026amp;lt;sofa:vip url=\u0026amp;quot;http://APPNAME-pool.zone.alipay.net:12200?_TIMEOUT=3000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.tr\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上述 VIP URL 指定了 12200 端口，却又同时指定了 http，这种配置是不合法的，就会出现问题，这时候测试环境就需要跨 zone、跨 LDC 的测试环境。我们在多数复杂产品测试里都会遇到，极度复杂测试场景无法 100% 分析充分。一般对于这种场景，我们可以借助于线上流量回放的能力，将线上的真实流量复制到线下，作为我们测试场景的补充。这也需要非常仿真的测试环境做 MOSN 的流量回放支撑。\n兼容性测试 MOSN 兼容性验证\n我们通过一个例子来详细阐述：老版本的 RPC 中我们支持 TR 协议，后续的新版支持 BOLT 协议，应用升级过程中，存在同时提供 TR 协议和 BOLT 协议服务的情况，如下图：\n应用升级过程中，相同接口提供不同协议的服务\n首先，应用向 MOSN 发布服务订阅的请求，MOSN 向配置中心订阅，配置中心返回给 MOSN 两个地址，分别支持 TR 和 BOLT，MOSN 从两个地址中选出一个返回给应用 APP。\n这里兼容性风险是：MOSN 返回给 APP 的地址是直接取配置中心返回的第一条数据，这里可能是 TR 也可能是 BOLT。\n如果 MOSN 返回给应用的地址是支持 BOLT 协议的服务端，那么后续应用发起服调用时，会直接以 BOLT 协议请求 MOSN，MOSN 选址时，会以轮询的方式两个服务提供方，如果调用到 Server1，就会出现协议不支持的报错。 因此我们针对各种兼容性具体场景都要做好分析和相应的测试。\nMOSN 的鲁棒测试（稳定性、健壮性） 从 MOSN 的视角来看，其外部依赖如下：\nMOSN 外部依赖图\n除了验证 MOSN 自身的功能外，我们还通过故障注入的方式，对 MOSN 的外部依赖做了专项测试。通过这种方式，我们发现了一些上述功能测试未覆盖的场景，这里以应用和 MOSN 之间的 12199 端口举例。\n应用 APP 接入 MOSN 后，原先应用对外提供的 12200 端口改由 MOSN 去监听，应用的端口修改为 12199，MOSN 会向应用的 12199 端口发送心跳，检测应用是否存活。\n如果应 …","date":1579514400,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，结合蚂蚁金服 Mesh 化落地质量保障落地的思考，给大家带来一些质量保障的分享。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8dfd6e1dabd16bc85d9876ce9764e3ab","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","publishdate":"2020-01-20T18:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，该系列从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","wordcount":3163},{"author":"嘉祁","categories":"Service mesh","content":" 本文根据蚂蚁金服中间件 SRE技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。\n背景 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。而在具体部署上，保守的做法是以独立进程的方式与业务进程共同存在于业务容器内。蚂蚁金服的做法是从开始就选择了拥抱云原生。\n大规模落地的过程中，我们在看到 Service Mesh 带来的巨大红利的同时，也面临过很多的挑战。为此，蚂蚁金服配备了“豪华”的技术团队阵容，除了熟悉的 SOFA 中间件团队，还有安全、无线网关以及专门配备了专属的 SRE 团队，使得 MOSN 能力更加全面更加可靠。\n今天我们详细聊聊技术风险这个方面。对于一个新的中间件技术，在落地过程中总会面临稳定性、运维模式变化等等很多的问题与挑战，需要建设相应的技术风险能力，确保整个落地过程以及长期运行的稳定和可靠。\n本次分享主要从以下三个方面展开：\n 落地过程中对于部署模式和资源分配的思考； 变更包括接入、升级的支持、问题与思考； 整个生产生命周期中稳定性面临的挑战与技术风险保障； Sidecar 部署模式 业务容器内独立进程的好处在于与传统的部署模式兼容，易于快速上线；但独立进程强侵入业务容器，对于镜像化的容器更难于管理。而云原生化，则可以将 Service Mesh 本身的运维与业务容器解耦开来，实现中间件运维能力的下沉。在业务镜像内，仅仅保留长期稳定的 Service Mesh 相关 JVM 参数，从而仅通过少量环境变量完成与 Service Mesh 的联结。同时考虑到面向容器的运维模式的演进，接入 Service Mesh 还同时要求业务完成镜像化，为进一步的云原生演进打下基础。\n 优 劣 独立进程 兼容传统的部署模式；改造成本低；快速上线 侵入业务容器； 镜像化难于运维 Sidecar 面向终态；运维解耦 依赖 K8s 基础设施；运维环境改造成本高；应用需要镜像化改造 在接入 Service Mesh 之后，一个典型的 POD 结构可能包含多个 Sidecar：\n MOSN：RPC Mesh, MSG Mesh, \u0026amp;hellip;（扩展中）； 其它 Sidecar； MOSN：https://github.com/mosn/mosn\n这些 Sidecar 容器与业务容器共享相同的网络 Namespace，使得业务进程可以以本地端口访问 Service Mesh 提供的服务，保证了与保守做法一致的体验。\n基础设施云原生支撑 我们也在基础设施层面同步推进了面向云原生的改造，以支撑 Service Mesh 的落地。\n运维平台模型支撑 首先是运维平台需要能够理解 Sidecar，支撑 Sidecar 模型的新增元数据，包括基于 POD 的 Sidecar 的多种标签，以及 Sidecar 基线配置的支持。\n业务全面镜像化 其次我们在蚂蚁金服内部推进了全面的镜像化，我们完成了内部核心应用的全量容器的镜像化改造。改造点包括：\n 基础镜像层面增加对于 Service Mesh 的环境变量支撑； 应用 Dockerfile 对于 Service Mesh 的适配； 推进解决了存量前后端分离管理的静态文件的镜像化改造； 推进了大量使用前端区块分发的应用进行了推改拉的改造； 大批量的 VM 模式的容器升级与替换； 容器 POD 化 除了业务镜像层面的改造，Sidecar 模式还需要业务容器全部跑在 POD 上，来适应多容器共享网络。由于直接升级的开发和试错成本很高，我们最终选择将接入 Service Mesh 的 数百个应用的数万个非 K8s 容器，通过大规模扩缩容的方式，全部更换成了 K8s PODs。\n经过这两轮改造，我们在基础设施层面同步完成了面向云原生的改造。\n资源的演进 Sidecar 模式的带来一个重要的问题，如何分配资源。\n理想比例的假设独占资源模型 最初的资源设计基于内存无法超卖的现实。我们做了一个假设：\n MOSN 的基本资源占用与业务选择的规格同比例这一假设。 CPU 和 Memory 申请与业务容器相应比例的额外资源。这一比例最后设定在了 CPU 1/4，Memory 1/16。\n此时一个典型 Pod 的资源分配如下图示：\n独占资源模型的问题 这一方式带来了两个问题：\n 蚂蚁金服已经实现了业务资源的 Quota 管控，但 Sidecar 并不在业务容器内，Service Mesh 容器成为了一个资源泄漏点； 业务很多样，部分高流量应用的 Service Mesh 容器出现了严重的内存不足和 OOM 情况； 共享资源模型 讨论之后，我们追加了一个假设：\n Service Mesh 容器占用的资源实质是在接入 Service Mesh 之前业务已使用的资源。接入 Service Mesh 的过程，同时也是一次资源置换。 基于这个假设，推进了调度层面支持 POD 内的资源超卖，新的资源分配方案如下图，Service Mesh 容器的 CPU、MEM 都从 POD 中超卖出来，业务容器内仍然可以看到全部的资源。\n考虑到内存超卖也引入了 POD OOM 的风险，因此对于 Sidecar 容器还调整了 OOM Score，保证在内存不足时，Service Mesh 进程能够发挥启动比 Java 业务进程更快的优势，降低影响。\n新的分配方案解决了同时解决了以上两个问题，并且平稳支持了蚂蚁金服的双十一大促。\n变更-Service Mesh 是如何在蚂蚁金服内部做变更的 Service Mesh 的变更包括了接入与升级，所有变更底层都是由 Operator 组件来接受上层写入到 POD annotation 上的标识，对相应 POD Spec 进行修改来完成，这是典型的云原生的方式。\n接入-从无至有 标准的云原生的接入方式，是在创建时通过 sidecar-operator webhook 注入一个 Sidecar 容器。\n这个方式的固有缺陷在于：\n 滚动替换过程需要 Buffer 资源； 过程缓慢； 回滚慢，应急时间长； 原地接入 原地接入是为了支撑大规模的快速接入与回滚，通过在存量的 POD 上操作修改 POD Spec。\n尽管看起来不太云原生，但期望能绕过以上几个痛点，从而可以：\n 不需要重新分配资源； 可原地回滚； 升级 Service Mesh 是深度参与业务流量的，最初的 Sidecar 的升级方式也需要业务伴随重启。\n带流量的平滑升级 为了规避 Java 应用重启带来的重新预热等问题，MOSN 提供了更为灵活的平滑升级机制：由 Operator 控制启动第二个 MOSN Sidecar，完成连接迁移，再退出旧的 Sidecar。整个过程业务可以做到流量不中断，几近无感。\n变更能力的取舍 虽然提供了原地接入与平滑升级，但从实践的效果来看，对存量 POD spec 的修改带来的问题，比收益要多得多。\n 创建时注入/普通升级 原地注入/平滑升级 不改变现存 POD spec 改变现存 POD 资源预分配，不影响调度； 逻辑简单，成功率高；与原有业务升级逻辑一致； …","date":1579514400,"description":" 本文根据蚂蚁金服中间件 SRE 技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。","dir":"blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7e1941c7099e109de92394b49df59a2b","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","publishdate":"2020-01-20T18:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","summary":"本文根据蚂蚁金服中间件 SRE技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。 背景 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。","tags":["Service mesh","Service Mesh Meetup"],"title":"蚂蚁金服 Service Mesh 技术风险思考和实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","wordcount":4057},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n 活动时间：2 月 13 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本期为 SOFAChannel 线上直播第 11 期，将邀请 SOFAArk 开源负责人玄北和大家一起解读 SOFAArk ，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk：https://github.com/sofastack/sofa-ark\n你将收获：\n 快速认识轻量级类隔离容器 SOFAArk； Demo 案例实操，了解如何使用 SOFAArk 实现类隔离； SOFAArk 完整功能详解； | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1096\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 从一个例子开始体验轻量级类隔离容器 SOFAArk 玄北，蚂蚁金服技术专家 、SOFAArk 开源负责人\n本期分享大纲： 快速认识轻量级类隔离容器 SOFAArk； Demo 案例实操，了解如何使用 SOFAArk 实现类隔离； SOFAArk 完整功能详解； 嘉宾 SOFAGirl 主持人 玄北，蚂蚁金服技术专家 、SOFAArk 开源负责人 ","date":1579251600,"description":"2 月 13 日周四晚 7 点，线上直播第 11 期。","dir":"activities/sofa-channel-11/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b110f76087d52e5c6d8ccbe31c76a7f5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-11/","publishdate":"2020-01-17T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-11/","summary":"概要 活动主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk 活动时间：2 月 13 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这","tags":["SOFAChannel","SOFAArk"],"title":"SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk","type":"activities","url":"/sofastack.tech/activities/sofa-channel-11/","wordcount":709},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@J~杰 提问：\n 咨询一下，Seata TCC 中这个 BusinessActivityContext 是用于做什么的？\n A：比如说在 rollback 服务里需要用到 try 服务里的参数时，可以放到 BusinessActivityContext，然后在 rollback 和 comfirm 服务里可以取到这个参数。\n 那是要自己在 try 阶段需要手动实例化 BusinessActivityContext？\n A：不需要，可以在 try 方法上的参数加注解，它会自动把这个参数放入 BusinessActivityContext。\nSeata：https://github.com/seata/seata\n2、王国柱 提问：\n 有一个问题想要请教一下： HBX：如果是 spanner - \u0026amp;gt; gateway -\u0026amp;gt; app1 这种架构，每次上新的应用，应该是需要在 geteway 中配置新应用的 ip 地址路由信息。 如果是 spanner -\u0026amp;gt; gateway.jar,app1 这种架构，如果新增加 app2， spanner 如何知道新的应用地址在哪里。\nHBX：我理解集中式的 gateway，应该会把后端 app 的应用地址信息配置在集中式的 gateway 中。如果做成 jar，那 app 和 jar 的地址信息，该如何被 spanner 知道？\n A：Spanner 其实就是 ingress，不管是 gateway 还是 app x，都可以通过服务发现来发现服务器的 ip 信息。\n 那像这种的话，就是后台服务上线，可以自己注册到 spanner 上，然后外部应用就可以直接访问了。\n A：是的。 MOSN：https://github.com/mosn/mosn\nKubeCon NA2019 回顾 开箱即用的 Java Kubernetes Operator 运行时 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 本周推荐文章 10年后，阿里给千万开源人写了一封信 蚂蚁金服消息队列 SOFAMQ 加入 OpenMessaging 开源标准社区 蚂蚁金服 API Gateway Mesh 思考与实践 社区直播预告 春节后直播预告来啦～本期为 SOFAChannel 线上直播第 11 期，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n时间：2020年2月13日（周四）19:00-20:00\n嘉宾：玄北，蚂蚁金服技术专家 SOFAArk 开源负责人\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1579248000,"description":"【01/13-01/17】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200117/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2fd8dd14cb119400890ef134622ad4d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200117/","publishdate":"2020-01-17T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200117/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":" SOFA Weekly | 2.13直播预告、KubeCon NA2019 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200117/","wordcount":1210},{"author":"何子波、金敏","categories":null,"content":" 本篇分享的内容难度为“初学者/Beginner”级别，以下是阅读本文前推荐您了解的背景知识：\n Java 语言编程基础； 了解过 Kubernetes 平台上的 Operator/Controller 工作机制； 也可以同步参考 Kubernetes 官方博客内容：https://kubernetes.io/blog/2019/11/26/develop-a-kubernetes-controller-in-java\n图为何子波和金敏在 KubeCon NA2019 大会分享后的交流\n何子波 蚂蚁金服技术专家： _(adohe@github) _Kubernetes 维护者，SIG CLI Co-Chair（包括 Kubectl 及其扩展插件，Kustomize 以及客户端运行时），同时关注安全容器，多租户等领域。\n金敏 蚂蚁金服软件工程师： _(yue9944882@github) _Kubernetes SIG API-Machinery 维护者及其子领域 Owner（CRD 服务实现，APIAggregation SDK 套件，控制面流控，OpenAPIv2/3，Java SDK 等），同时也是 OpenAPI 开源生态工具链openapitools.org 的 Techincal Committee。\n本文根据两位在 KubeCon NA2019 的分享内容整理。本次演讲与大家分享蚂蚁金服金融科技扩展云原生 Java 能力到云的实践和改造，并将收获的产出回馈开放给 Kubernetes 社区。\n分享概要 在 Kubernetes 平台上开发部署运行 Operator 已经是在 Kubernetes 上拓展开发能力的默认范式。最早是 CoreOS 的工程师们创新提出了 Operator 的开发理念并且在社区收获了良好的反响，在经过一段时间的波折、打磨和实践之后，我们今天才看到丰富多样的 Operator 层出不穷。实际上 Operator 的效力往往要结合 Kubernetes API 的扩展能力才能更好发挥。所以其广泛传播反过来锤炼演进了 Kubernetes 上 CustomResourceDefinition 承载第三方 API 模型的能力。水涨船高，这也是社区集中投入人力从 v1.14 开始启动 Extensibility GA Sprint 小组冲刺 Kubernetes 扩展性建设的推动原因。\n图为何子波和金敏在 KubeCon NA2019 大会现场演示\n随着 Operator 的受众越来越多，社区也衍生出了面向 Operator 开发提效的工具链项目比如 operator-sdk、kubebuilder、metacontroller 等等优秀的开源项目。可是这些项目大都是面向 Go 语言研发者的，虽然越来越多的研发者向 Go 靠扰已是事实，但是 Go 语言尚不及其他主流编程语言成熟，倒是慢慢铺开的 Kubernetes 等其他开源项目的工业实践在“倒逼”Go 语言底层库的修复和稳固，比如 http2 的底层网络库[1]。与此相似的，我们最早内部孵化的 Java 语言的 Operator 运行时框架也是被实际业务“倒逼”出来的，并在 Kubernetes 社区露头试水之初便收获了许多反馈推动发展直到今天走到全面开放。\n你为什么需要使用 Java 开发 Operator 如果你在犹豫不决是否要使用 Java 开发 Operator 并应用到实际中来，我们从以下几个方面进行对比看看哪一点是足够吸引你尝鲜：\n 适配存量系统：如果在登陆 Kubernetes 之前你的基础设施底层系统都是通过 Java 开发的，那么恭喜你已经有了使用 Java Operator 的天然土壤。反过来把存量系统接口逐个“翻译”为 Go 语言既消耗大量人力又引出持续同步维护 Go 语言库的成本。 堆内存快照：相比于 Java，Go 语言很难将运行中的程序的内存进行完整的快照分析，PProf 相关工具链能做的只是将内存的使用概况汇总输出，虽然也可以帮助分析锁定出泄漏的对象类型，但是粒度有限。反过来 Java 程序的堆内存进行快照分析已经具有成熟的工具链支持，研发者通过一份完整的堆快照可以直接锁定出比如 WorkQueue 中积压的内容，甚至限流器中逐个 Key 的瞬时状态，也可以在 Operator 静默不响应的场景下快速锁定问题。 性能诊断/在线调试：结合比如 JMX Exporter 等工具链的帮助，我们直接将 Java 虚拟机的细节运行状态以 Prometheus Metrics 的形式收集起来，虽然 Go 程序也可以暴露出其运行时的 Metrics，但是对比后我们发现 Java 的 Metrics 在分析 GC 状态和堆分布上更加强大。除此之外，Java Operator 的远程调试更加方便上手。 线程模型：与 Java 显著不同的是，Go 语言中的 Routine 不具有直接从外部“杀死”的功能，你需要结合 Channel/Context 等模型间接实现。而在 Java 虚拟机上的线程模型有和操作系统类似的生命周期管理，开发者可以白盒的操作干涉线程的生命周期。这对于某些业务场景是重要的。 OOP 范型编程接口： Go 语言本身的设计哲学是不认可面向对象编程的，尽管好处很多但是在 API 模型繁多的 Kubernetes 项目中，维护者不得己转向使用代码生成器批量为这些模型生成大量模版代码。Java 的优势之一是范型编程，这可以彻底取代代码生成器的工作，同一套代码可以自由地适配在各种模型，比如 Pod 到 Service 等等。 第三方研发者库生态：经过数十年的演进，Java 积累的第三方工具库远比 Go 语言丰富的多，至少目前而已可以算得上是一个优势。 示例代码速览 下面两张代码片段为你展示了具体开发 Java Operator 所需要的全部工作，相信接触过 Kubernetes Client-Go 的开发者通过名字大致了解如何使用了：\n（如何构造出一个 Informer 实例） https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/InformerExample.java\n（如何构造出一个 Operator 实例） https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/ControllerExample.java\n开发 Java Operator 需要额外注意什么 仅仅是通过代码开发 Operator 显然不是大结局，你还需要注意其他的问题，以下是我们在实际运用的获得的经验总结：\n 严谨管理 CRD Yaml 定义：如最开始提到的，当 Java Operator 操作的是自定义资源比如 CRD 时，我们自然需要操作/维护该 CRD 对应的 Java 模型。 …","date":1579176000,"description":" 本文介绍了如何快速上手使用 Java 开发 Operator，感兴趣的读者可以根据官方实例在本地开发环境体验。","dir":"blog/java-kubernetes-operator-kubecon-na2019/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4af2ef3082aeed080e87501fd71134d9","permalink":"https://sofastack.github.io/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","publishdate":"2020-01-16T20:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","summary":"本篇分享的内容难度为“初学者/Beginner”级别，以下是阅读本文前推荐您了解的背景知识： Java 语言编程基础； 了解过 Kubernetes 平台上的 Operator/Controller 工作机制； 也可","tags":["Kubernetes"],"title":" 开箱即用的 Java Kubernetes Operator 运行时","type":"blog","url":"/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","wordcount":2778},{"author":"贾岛","categories":"Service Mesh","content":" 本文整理自蚂蚁金服高级技术专家贾岛在 12 月 28 日 Service Mesh Meetup 杭州站现场分享。\nMOSN 完成孵化， 启用独立 Group 2020.2019.12.18，MOSN 项目负责人、蚂蚁金服应用网络组负责人涵畅宣布 MOSN 完成从 SOFAStack 的孵化，将启用独立 Group 进行后续运作，欢迎大家共同建设社区。\nMOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称，可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡，API Gateway，云原生 Ingress 等使用。\n项目地址：https://github.com/mosn/mosn\n导语 在 Service Mesh 微服务架构中，我们常常会听到东西流量和南北流量两个术语。蚂蚁金服开源的 Service Mesh Sidecar：MOSN（Modular Observable Smart Network）已经多次与大家见面交流，以往的议题重点在东西流量的服务发现与路由，那么蚂蚁金服在南北流量上的思考是怎样的？\n本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的、解决了什么问题、双十一的实践表现以及我们对未来的思考。\n今天的分享分为三个部分：\n API Gateway Mesh 的定义：我在 Google 上搜了下 API Gateway Mesh 这个词，找到的都是 API Gateway vs Service Mesh，大家估计也会很好奇：这个词具体的定义是怎样的呢？所以我们下面会做将 API Gateway 和 Service Mesh 做个对比，然后讲一下我个人对这个词有理解和思考。 API Gateway Mesh 在蚂蚁金服的实践：今年阿里巴巴核心系统 100% 云原生化，撑住了双11的世界级流量洪峰，这其中，蚂蚁金服的 Service Mesh 大放光彩，核心链路全上 Mesh，数万容器规模，我们 API Gateway 在其中也承担了部分钱包链路和支付链路 100% 的请求。这个章节，我会从蚂蚁金服 API 网关的发展历程来看，我们为什么做 API Gateway Mesh，我们的架构是如何的，以及我们在过程中的一些风险和考验。 云原生下 API Gateway 的思考：大家现在都在讲云原生，但是真正实践云原生的过程中，会越到各种各样的问题，怎么样的 API Gateway 方案和形态是最合适你们的业务的？在云原生的架构中，Service Mesh，API Gateway 都是最核心的组件之一，我们对于云原生下的 API Gateway 在 Service Mesh 架构中的定位是如何思考的？还有，未来我们的一些计划是怎样的？都会在这个章节跟大家分享一下。 API Gateway Mesh 的定义 上面这张图是一个云原生，南北+东西流量的架构图，这里面包含了核心的一些组件，我快速介绍一下：\n LB\\ingress：负责 ssl 卸载、入口流量的负载均衡，通常会做一些简单的路由； API Gateway：负责更偏向业务的 API 验签、限流、协议转换、用户会话、负载均衡等逻辑； Sidecar in POD：业务系统中的 Sidecar，代理机房内东西流量的转发，一般走内部的 RPC（比如SOFARPC \\ Dubbo \\ Thrift \\ SpringCloud），这里面的流量全部通过 Service Mesh 的 Sidecar Proxy 来承载，这个 Sidecar 负责路由（单元化\\灰度\\金丝雀），负载均衡、服务鉴权等等； Control Plane：流量控制「大管家」，云原生里目前最主流的方案是 Istio，负责路由策略、安全、鉴权等等下发和控制； 上面的架构大家都比较了解了，从上面的描述大家也看出来了，API Gateway 和 Service Mesh 的 Sidecar 很多能力都是类似的，比如都是一个网络代理，都具备负载均衡，都具备一些限流和鉴权能力。下面，我们将做一个 API Gateway 和 Service Mesh 的对比。\nAPI Gateway vs Service Mesh  从本质概念上来讲，API Gateway 用一句话概括：「Exposes your services as managed APIs」，将内部的服务以更加可控可管理的方式暴露出去，这里的关键词是「暴露」和「可控」。Service Mesh 用一句话概括：「A infrastructure to decouple the application network from your service code」，一种将服务代码与应用网络解耦的基础设施，这里的关键词是「解耦」。\n在流量上，API Gateway 是管理南北流量的，而 Servcie Mesh 中的 Sidecar 一般情况下是用来负载东西流量的Proxy。两者都具备负责均衡的能力，API Gateway 一般情况下是通过 lvs 、nginx 中心化的一个负载均衡器，我们管这个叫硬负载；而 Service Mesh 一般情况下是通过服务发现，Sidecar 之间是点对点的调用，我们叫软负载。\n通信协议上，API Gateway 一般对外接收开放的通信协议，一般是 HTTP、gRPC 等，而且可能涉及到协议的转换，将 HTTP 转换成内部的 RPC 协议，而 Service Mesh 代理的内部流量一般是内部的私有 RPC 协议（WebService、Dubbo、SOFABolt、Thrift 等等）。在鉴权、流控、安全等控制流量的层面上，对于 API Gateway 来讲都是强依赖的，这样才体现「可控」的特点，而 Service Mesh 代理的内部流量，由于一般处于内网环境，这些控制一般情况下都是弱依赖。\n我们对 Service Mesh 的真正理解 大家可以看到，API Gateway 和 Service Mesh 实际上有很多共同点，也有很多区别。那 API Gateway Mesh 到底是如何定义的呢？那要介绍下，我们对 Service Mesh 的真正理解！\nService Mesh 中的 Sidecar 就是这样一辆边车摩托车，Sidecar 将 Service Code 和内部通信 RPC 逻辑解耦掉。但是 Sidecar 的座位上，不仅仅可以坐「内部通信的 RPC」，也可以将其他中间件放到这辆 Sidecar 中，API Gateway + Sidecar = API Gateway Mesh，我们也可以把 MessageQueue Client 放在 Sidecar 中，就是 Message Mesh。\n所以，大家看，其实 Service Mesh 是一种模式和架构，关键词就是「解耦」你的服务代码和你的「中间件」。\nAPI Gateway Mesh …","date":1579078800,"description":" 本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的、解决了什么问题、双十一的实践表现以及我们对未来的思考。","dir":"blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"370ccd30a2edcf559eb2c82976bcb8a0","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","publishdate":"2020-01-15T17:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","summary":"本文整理自蚂蚁金服高级技术专家贾岛在 12 月 28 日 Service Mesh Meetup 杭州站现场分享。 MOSN 完成孵化， 启用独立 Group 2020.2019.12.18，MOSN 项目负责人、","tags":["Service Mesh","MOSN","Service Mesh Meetup"],"title":"蚂蚁金服 API Gateway Mesh 思考与实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","wordcount":5174},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@李彦迎 提问：\n TCC 模式我可以作为 Saga 模式使用不？譬如 try 为空，永远成功。\n A：可以，不过应该是 confirm 为空，不是 try 为空。\n 请问 Seata 的 Saga 模式能支持 DB2 数据库吗？\n A：可以支持 DB2。\n 请教基础问题：Gateway 调用微服务 A、B，B内部失败了，补偿交易应该回退A的，这个补偿交易应该定义在微服A里面还是微服务B里面？\n A：原服务是谁提供的，补偿服务就应该谁提供。\n 请问能否 Client 用 DB2，Server 用 MySQL? Client 的必须和业务数据库保持一致吧？\n A：也可以的。是的，Client端必须与业务数据库保持一致。\n2、@米晓飞 提问：\n Saga 和现有框架有啥区别呢，优劣比较？\n A：我们在实践中发现，长流程的业务场景，往往有服务编排的需求，同时又要保证服务之间的数据一致性。目前开源社区也有一些 Saga 事务框架，也有一些服务编排的框架，但是它们要么只有 Saga 事务处理能力、要么只有服务编排能力，Seata Saga 是将这两者能力非常优雅的结合在一起，为用户提供一个简化研发、降低异常处理难度、高性能事件驱动的产品。\n3、@张春雨 提问：\n Saga 的模式补偿和 XA 回滚有啥区别呀？\n A：XA 是数据库提交的两阶段提交协议，Saga 的是需要业务层来实现的。\n Seata server 端使用 mysql 去记录事务日志,感觉性能上不是很好、 有没有其他的可替代的持久化方案吗？\n A：Seata 每个模块都设计有 SPI，持久化也一样，未来可以扩展更多持久化方式。 Seata：https://github.com/seata/seata 更多关于 Seata Saga 的内容可以看下文直播回顾。\n4、@FAN 提问：\n MOSN 的平滑升级原理是什么？跟 Nginx 和 Envoy 的区别是什么？\n A：MOSN 的平滑升级方案和 Envoy 类似，都是通过 UDS 来传递 listener fd。但是其比 Envoy 更厉害的地方在于它可以把老的连接从 Old MOSN 上迁移到 New MOSN 上。也就是说把一个连接从进程 A 迁移到进程 B，而保持连接不断！Nginx 的实现是兼容性最强的。 可以详细阅读：https://ms2008.github.io/2019/12/28/hot-upgrade/ MOSN：https://github.com/mosn/mosn\nSOFAArkLab 系列 蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析 本篇开始将正式启动SOFA:ArkLab/源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。文中附共建列表，欢迎领取共建~\nSOFAChannel 集锦 Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v3.2.2 版本，主要变更如下：\n ReadinessCheckListener 的 Order 过高 删除 jaxrs-api 依赖项 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.2.2\n","date":1578643200,"description":"【01/05-01/10】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200110/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1143431da4314982069d5d5465391dc5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200110/","publishdate":"2020-01-10T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200110/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot 发版、直播回顾、SOFAArkLab共建启动","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200110/","wordcount":1463},{"author":"屹远","categories":"Seata","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#10 直播分享整理，主题：分布式事务 Seata 长事务解决方案 Saga 模式详解。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群：23372465，不错过每场直播。\n 大家好，我是陈龙，花名: 屹远（_long187@github_），是蚂蚁金服分布式事务核心研发，也是 Seata Committer。今天分享的主题是《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\nSeata：https://github.com/seata/seata\n金融分布式应用开发的痛点 分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。\u0026amp;mdash;《左耳听风-弹力设计之“补偿事务”》\n而在金融领域微服务架构下的业务流程往往会更复杂，流程很长，比如一个互联网微贷业务流程调十几个服务很正常，再加上异常处理的流程那就更复杂了，做过金融业务开发的同学会很有体感。\n所以在金融分布式应用开发过程中我们面临一些痛点：\n 业务一致性难以保障 我们接触到的大多数业务（比如在渠道层、产品层、集成层的系统），为了保障业务最终一致性，往往会采用“补偿”的方式来做，如果没有一个协调器来支持，开发难度是比较大的，每一步都要在 catch 里去处理前面所有的“回滚”操作，这将会形成“箭头形”的代码，可读性及维护性差。或者重试异常的操作，如果重试不成功可能要转异步重试，甚至最后转人工处理。这些都给开发人员带来极大的负担，开发效率低，且容易出错。\n 业务状态难以管理 业务实体很多、实体的状态也很多，往往做完一个业务活动后就将实体的状态更新到了数据库里，没有一个状态机来管理整个状态的变迁过程，不直观，容易出错，造成业务进入一个不正确的状态。\n 业务监控运维难 业务的执行情况监控一般通过打印日志，再基于日志监控平台查看，大多数情况是没有问题的，但是如果业务出错，这些监控缺乏当时的业务上下文，对排查问题不友好，往往需要再去数据库里查。同时日志的打印也依赖于开发，容易遗漏。\n 缺乏统一的差错守护能力 对于补偿事务往往需要有“差错守护触发补偿”、“人工触发补偿”操作，没有统一的差错守护和处理规范，这些都要开发者逐个开发，负担沉重。\n理论基础 对于事务我们都知道 ACID，也很熟悉 CAP 理论最多只能满足其中两个，所以，为了提高性能，出现了 ACID 的一个变种 BASE。ACID 强调的是一致性（CAP 中的 C），而 BASE 强调的是可用性（CAP 中的 A）。在很多情况下，我们是无法做到强一致性的 ACID 的。特别是我们需要跨多个系统的时候，而且这些系统还不是由一个公司所提供的。BASE 的系统倾向于设计出更加有弹力的系统，在短时间内，就算是有数据不同步的风险，我们也应该允许新的交易可以发生，而后面我们在业务上将可能出现问题的事务通过补偿的方式处理掉，以保证最终的一致性。\n所以我们在实际开发中会进行取舍，对于更多的金融核心以上的业务系统可以采用补偿事务，补偿事务处理方面在30多年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较也公认 Saga 是作为长事务的解决方案。\n https://github.com/aphyr/dist-sagas/blob/master/sagas.pdf http://microservices.io/patterns/data/saga.html\n Saga 模式用一种非常纯朴的方式来处理一致性：补偿。上图左侧是正常的事务流程，当执行到 T3 时发生了错误，则开始执行右边的事务补偿流程，返向执行T3、T2、T1 的补偿服务，其中 C3 是 T3 的补偿服务、C2 是 T2 的补偿服务、C1 是 T1 的补偿服务，将T3、T2、T1 已经修改的数据补偿掉。\n使用场景 一些场景下，我们对数据有强一致性的需求时，会采用在业务层上需要使用“两阶段提交”这样的分布式事务方案。而在另外一些场景下，我们并不需要这么强的一致性，那就只需要保证最终一致性就可以了。\n例如蚂蚁金服目前在金融核心系统使用的就是 TCC 模式，金融核心系统的特点是一致性要求高（业务上的隔离性）、短流程、并发高。\n而在很多金融核心以上的业务（比如在渠道层、产品层、集成层的系统），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务（如金融网络）。这是如果每个服务都开发 Try、Confirm、Cancel 三个方法成本高。如果事务中有其它公司的服务，也无法要求其它公司的服务也遵循 TCC 这种开发模式。同时流程长，事务边界太长，加锁时间长，会影响并发性能。\n所以 Saga 模式的适用场景是：\n 业务流程长、业务流程多； 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口； 典型业务系统：如金融网路（与外部机构对接）、互联网微贷、渠道整合、分布式架构下服务集成等业务系统； 银行业金融机构使用广泛； 其优势：\n 一阶段提交本地事务，无锁，高性能； 参与者可异步执行，高吞吐； 补偿服务易于实现，因为一个更新操作的反向操作是比较容易理解的； 其缺点：\n 不保证隔离性，后面我们会讲到如何应对隔离性的缺失。 基于状态机引擎的 Saga 实现 基于状态机引擎的 Saga 实现的基本原理：\n 通过状态图来定义服务调用的流程并生成 json 定义文件； 状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点（虚线关联的节点）； 状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚； 异常发生时是否进行补偿也可由用户自定义决定； 可以实现服务编排需求，路由、异步、重试、参数转换、参数映射、服务执行状态判断、异常捕获等功能 ； Seata 目前的 Saga 模式采用了状态机+DSL 方案来实现，原因有以下几个：\n 状态机+DSL 方案在实际生产中应用更广泛； 可以使用 Actor 模型或 SEDA 架构等异步处理引擎来执行，提高整体吞吐量； 通常在核心系统以上层的业务系统会伴随有“服务编排”的需求，而服务编排又有事务最终一致性要求，两者很难分割开，状态机+DSL 方案可以同时满足这两个需求； 由于 Saga 模式在理论上是不保证隔离性的，在极端情况下可能由于脏写无法完成回滚操作，比如举一个极端的例子，分布式事务内先给用户 A 充值，然后给用户 B 扣减余额，如果在给A用户充值成功，在事务提交以前，A 用户把线消费掉了，如果事务发生回滚，这时则没有办法进行补偿了，有些业务场景可 …","date":1578574800,"description":"本文根据 SOFAChannel#10 直播分享整理，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用","dir":"blog/sofa-channel-10-retrospect/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2ba15ca1c710e1be2e6758950246d1ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-10-retrospect/","publishdate":"2020-01-09T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-10-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#10 直播分享整理，主题：分布式事务 Seata 长事务解决方案 Saga 模式详解。 回顾视频以及 PPT 查看","tags":["Seata","SOFAChannel"],"title":"Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-10-retrospect/","wordcount":6186},{"author":"卫恒","categories":"SOFAArk","content":" 本篇开始将正式启动 SOFAArk:Lab/ 源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。\n本文为《剖析 | SOFAArk 源码》第一篇，本篇作者卫恒，SOFAArk 开源负责人。《剖析 | SOFAArk 源码》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附共建列表，欢迎领取共建~\n 在大型软件开发过程中，通常会推荐底层功能插件化、业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。对于模块化，从语言层面，原计划在 Java7 就有的模块化特性，终于在 Java9 里面提供了。在 Java语言级对模块化提供支持之前，业界内最知名的 Java 模块化规范当属 OSGi 了，直至到今天，OSGi 在众多企业、厂商中被广泛使用，比如我们常用的 Web 应用服务器、Eclipse 等均采用了 OSGi 规范。\n蚂蚁金服内部，CE 作为使用了 10 年的\u0026amp;rdquo;元老级\u0026amp;rdquo;容器组件，见证了和支撑了每年的大促、新春红包等流量场景。作为中间件的常青树，CE 以足够的稳定性为业务保驾护航。CE 容器也是基于 OSGi 实现了模块化，但是由于 CE 背负了太多包袱，使得其自身变得太重，在云原生及商业化输出上逐渐失去了优势。\n从 2016 年底开始，框架组内部开始在 CE 的基础上进行抽离和整合，开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\nSOFAArk 简介 SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin） 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz) 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz。 SOFAArk：https://github.com/sofastack/sofa-ark\n应用场景 基于模块化及模块的动态能力，SOFAArk 有非常丰富的落地场景，如：通过从 classloader 层面解决 依赖冲突问题、基于 arkcontainer 的多应用合并部署，基于动态 biz 的 SOFAServerless 等等。\n依赖冲突 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError、NoSuchMethodError 等；实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法，统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突；这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题；如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题； OSGi 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGi 框架太过臃肿，功能繁杂；为了解决包冲突问题，引入 OSGi 框架，有牛刀杀鸡之嫌，且反而使工程变得更加复杂，不利于开发。\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 – Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如果工程需要引入两个三方包：A 和 B，但是 A 需要依赖版本号为 0.1 的 C 包，而恰好 B 需要依赖版本号为 0.2 的 C 包，且 C 包的这两个版本无法兼容：\n此时，即可使用 SOFAArk 解决该依赖冲突问题；只需要把 A 和版本为 0.1 的 C 包一起打包成一个 Ark 插件，然后让应用工程引入该插件依赖即可。\n合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 - Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成可执行 Fat Jar 时，可以将其他应用 Biz 包一并打入，启动时，则会根据优先级依次启动各应用。每个 Biz 使用独立的 BizClassLoader 加载，不需要考虑相互依赖冲突问题，Biz 之间则通过 SofaService / SofaReference JVM 服务进行交互。\n 静态合并部署是将多个应用打包在一个 ARK 可执行 JAR 包中，然后通过 java -jar 启动，这种方式可以在 ARK 容器内同时运行多个应用，对于一些资源要求不高、流量较少的应用可以使用这种方式部署以节省资源。\n 动态模块 模块是 ark biz 在动态模型场景下的一种别名，其实质就是一个 ark biz 包。\n 动态模块相对于静态合并部署最大的不同点是，运行时通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态模块的设计理念图如下：\n无论是静态合并部署还是动态模块都会有宿主应用（master biz）的概念, 如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主应用不允许被卸载，一般而言，宿主应用 …","date":1578398400,"description":" 本文为《剖析 | SOFAArk 源码》第一篇，作者卫恒","dir":"blog/sofa-ark-overview/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"56bc84e9737dbad9c77b9700b12bf63d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-overview/","publishdate":"2020-01-07T20:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-ark-overview/","summary":"本篇开始将正式启动 SOFAArk:Lab/ 源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。 本文为《剖析 | SOFAArk 源码》第一篇，本篇作者卫恒，SOFAArk 开源负责人","tags":["SOFAArk","剖析 | SOFAArk 源码 ","SOFALab"],"title":"蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析","type":"blog","url":"/sofastack.tech/blog/sofa-ark-overview/","wordcount":3810},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\nSeata：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，其中长事务解决方案 Saga 模式有着无锁高性能、异步架构高吞吐的优势。\nSeata：https://github.com/seata/seata\nSaga 状态机在线设计器：http://seata.io/saga_designer/index.html\nSaga 状态机设计器视频教程：http://seata.io/saga_designer/vedio.html\n1、@李宇博 提问：\n 您好，我这边看视频直接把 Catch 直接拖到 serviceTask 上，好像没有生效，需要连线还是配置什么属性吗？\n A：没有生效是指什么？Catch 要连一个线到一个其它的 state，意思是捕获到异常后，去执行一个分支，这个 state可以是任何类型的 state，比如 CompensationTrigger、ServiceTask，通常是 CompensationTrigger，立即触发补偿。\n 我是直接连接到 compensateTrigger 上的，然后我手动抛出异常，并没有执行补偿方法，而是在不停的重试调用之前抛出异常的方法。\n A：需要在线上配置异常类型：\n2、@J～杰 提问：\n 咨询一个问题，AT 模式分支事物注册的时候会获取锁，锁名就是和 table+主键有关系的，由于压力测试的时候，有个 check 去数据库查询同一个 rowkey，导致直接获取锁失败，在业务上就是业务失败回滚了，这种有啥办法？\n A：你的意思是热点数据问题吗？\n 可以理解成热点数据，我这边的测试场景就是下单减库存，2个微服务，库存由于基本上是同一行库存数据。\n A：热点数据撞锁是正常的，你可以用自旋锁，让其它事务等待一下再获取锁，而不是立即失败。http://seata.io/zh-cn/docs/user/configurations.html\n 本地调用 Dubbo 微服务是可以的，用 Saga 状态机就报这个问题，报服务没有提供者。\n A：你的 Service 是用的 XML 注册的还是用的注解注册的？\n 注解的方式。\n A：嗯嗯。你尝试用 XML 方法注册一个 Bean 看看行不行，机制上可能有不一样，因为 Saga 状态机是通过 getBean 反射去调方法。而 Dubbo 的注解是通过代理的方式来注入一个对象，这个对象是不是一个有完全成功的 Bean，不确定。之前我遇到过 TCC 用注解不好使，用 XML 好使的问题。\n本周推荐阅读 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 SOFARegistryLab 系列 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 蚂蚁金服服务注册中心 Session 存储策略 | SOFARegistry 解析 蚂蚁金服服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.9.0 版本，主要变更如下： i. 重构了包引用路径，从 sofastack.io/sofa-mosn 变更为 mosn.io/mosn； ii. 支持变量机制，accesslog 修改为使用变量机制获取信息； iii. 修复在 proxy 协程 panic 时导致的内存泄漏； iv. 修复在特定的场景下，读写协程卡死导致的内存泄漏； v. 修复 HTTP2 Stream 计数错误的 bug；\n详细发布报告：https://github.com/mosn/mosn/releases/tag/0.9.0\n社区直播预告 新年快乐~2020年第一期线上直播来啦，SOFAChannel#10 将和大家一起探讨 《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\n主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解\n时间：2020年1月9日（下周四）19:00-20:00\n嘉宾：陈龙（花名：屹远） 蚂蚁金服分布式事务核心研发、Seata Committer\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1578038400,"description":"【12/31-01/03】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200103/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"aa8f76ccca9d7d700e3d9b16c2b0df21","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200103/","publishdate":"2020-01-03T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200103/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 1.9直播预告、MOSN 发版、Saga 状态机设计器视频教程","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200103/","wordcount":1862},{"author":"米麒麟","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第六篇，本篇作者子懿，来自阿里云。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n前言 微服务架构为了保证所有服务可用，当服务发生问题时能及时摘除有问题的服务，需要定期检测服务可用性即健康检测。健康检测包括客户端心跳和服务端主动探测两种方式，定期发送 TCP 或 HTTP 请求根据响应确定服务是否正常。服务注册中心提供服务注册和订阅服务，在服务发布者服务信息发生变化、或者节点上下线时通知变更，动态更新消费方的服务地址列表信息，支持服务注册和下线的快速变更通知。\n本文重点围绕服务的健康检测、SOFARegistry 的健康检测以及基于 SOFARegistry 实现秒级服务注册下线等方面剖析 SOFARegistry 如何实现秒级服务上下线通知原理，阐述如何使用 SOFARegistry 对于服务的注册下线场景通过推送机制快速实现端到端的传达功能：\n 如何实现服务的健康检测？业界服务注册中心的健康机制是怎样的？SOFARegistry 的健康检测实现方式？ SOFARegistry 服务注册下线数据流转过程是怎样的？SOFARegistry 内部角色如何实现秒级服务上下线通知？ 服务的健康检测 服务的健康检测是如何实现？健康检测分为客户端心跳和服务端主动探测两种方式：\n 客户端心跳 客户端采取每隔一定时间间隔主动发送心跳方式向服务端表明自己的服务状态正常，心跳是 TCP 或者 HTTP 的形式； 通过维持客户端和服务端的 Socket 长连接自己实现客户端心跳的方式； ZooKeeper 没有主动的发送心跳，而是依赖组件本身提供的临时节点的特性，通过 ZooKeeper 连接的 Session 维持临时节点； 客户端心跳中长连接的维持和客户端的主动心跳偏重服务链路是否正常，不一定是服务状态正常；服务端主动调用服务健康检查是比较准确的方式，通过返回结果成功判断服务状态健康情况； 服务端主动探测 服务端调用服务发布者 HTTP 接口来完成健康检测； 对于没有提供 HTTP 服务的 RPC 应用，服务端调用服务发布者的接口来实现健康检测； 通过执行脚本形式来进行定时检测； 服务端主动探测依然存在问题。服务注册中心主动调用 RPC 服务的某个接口无法做到通用性；在很多场景下服务注册中心到服务发布者的网络是不通的，服务端无法主动发起健康检查； 注册中心的健康检测 业界服务注册中心的健康检测机制：\n Eureka：定期有 Renew 心跳，数据具有 TTL（Time To Live）；并且支持自定义 HealthCheck 机制，当 HealthCheck 检测出系统不健康时主动更新 Instance 的状态； Zookeeper：定期发送连接心跳以保持会话 （Session），会话本身 （Session） 具有TTL； Etcd：定期通过 HTTP 对数据进行 Refresh，数据具有 TTL。申请 Lease 租约，设置服务生存周期TTL； Consul：Agent 定期对服务进行 healthcheck，支持 HTTP/TCP/Script/Docker；由服务主动定期向 agent 更新 TTL； SOFARegistry 的健康检测 业界服务注册中心的健康检测都有个共同的关键词：“定期”。定期检测的时间周期通常设置为秒级，比如 3 秒、5 秒或 10 秒，甚至更长，也就是说服务的健康状态总是滞后的。蚂蚁金服的注册中心从最初的版本设计开始，就把健康状态的及时感知，当做一个重要的设计目标，特别是需要做到“服务宕机能被及时发现”。因此 SOFARegistry 在健康检测的设计方面决定“服务数据与服务发布者的实体连接绑定在一起，断连马上清数据”，简称此特点叫做连接敏感性。连接敏感性是指在 SOFARegistry 里所有 Client 都与 SessionServer 保持长连接，每条长连接都设置基于 SOFABolt 的连接心跳，如果长连接断连客户端立即发起重新建连，时刻保持 Client 与 SessionServer 之间可靠的连接。\nSOFARegistry 将服务数据 （PublisherRegister） 和服务发布者 （Publisher） 的连接的生命周期绑定在一起：每个 PublisherRegister 定义属性 connId，connId 由注册本次服务的 Publisher 的连接标识 （IP 和 Port）构成，也就是只要该 Publisher 和 SessionServer 断连，服务信息数据即失效。客户端重新建连成功后重新注册服务数据，重新注册的服务数据会被当成新的数据，考虑更换长连接后 Publisher 的 connId 是 Renew 新生成的。\n譬如当服务的进程宕机时，一般情况下 OS 立刻断开进程相关的连接（即发送 FIN），因此 SessionServer 能够实时感知连接断开事件，然后把该 connId 相关的所有 PublisherRegister 都清除，并且及时推送给所有服务订阅者 （Subscriber）。如果只是网络问题导致连接断开，实际的服务进程没有宕机，此时客户端立即发起重新连接 SessionServer 并且重新注册所有服务数据。对服务订阅者本身来说接收到的是服务发布者经历短暂的服务下线后以及再次重新上线。假如此过程耗时足够短暂（例如 500ms 内发生断连和重连），服务订阅者可能感受不到服务下线，因为 DataServer 内部的数据通过 mergeDatum 延迟合并变更的 Publisher 服务信息，version 是合并后最新的版本号。\n服务上下线过程 服务的上下线过程是指服务通过代码调用执行常规注册（Publisher#register） 和下线（Publisher#unregister）操作，不考虑因为服务宕机等意外情况导致的下线场景。\n“一次服务注册过程”的服务数据在 SOFARegistry 内部流转过程：\n 客户端 Client 调用服务发布者 Publisher 的 register 向 SessionServer 注册服务。 SessionServer 接收到服务数据即 PublisherRegister 写入内存 （SessionServer 存储 Client 的服务数据到内存，用于后续跟 DataServer 做定期检查）， …","date":1577955600,"description":" 本文为《剖析 | SOFARegistry 框架》第六篇，作者米麒麟","dir":"blog/sofa-registry-service-offline-notification/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"289ee5ccb8ee61cdd0a42ce60874284b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-service-offline-notification/","publishdate":"2020-01-02T17:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-service-offline-notification/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-service-offline-notification/","wordcount":4114},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解\n 活动时间：1 月 9 日周四晚 7 点\n 活动形式：线上直播\n 活动回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，其中长事务解决方案 Saga 模式有着无锁高性能、异步架构高吞吐的优势。\n本期为 SOFAChannel 线上直播第 10 期，将邀请 蚂蚁金服 分布式事务核心研发 \u0026amp;amp; Seata Committer 屹远 和大家一起探讨 《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1076\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服 Service Mesh 双十一落地详解 屹远 蚂蚁金服分布式事务核心研发、Seata Committer\n本期分享大纲： 金融分布式应用开发的痛点 Seata Saga 理论基础以及使用场景 基于状态机引擎的 Saga 实现 Seata Saga 模式最佳实践以及优势 嘉宾 SOFAGirl 主持人 屹远 蚂蚁金服分布式事务核心研发、Seata Committer ","date":1577765400,"description":"1 月 9 日周四晚 7 点，线上直播第 10 期。","dir":"activities/sofa-channel-10/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a2f7bb983d4cbad1bda1a48a3c99abb7","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-10/","publishdate":"2019-12-31T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-10/","summary":"概要 活动主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解 活动时间：1 月 9 日周四晚 7 点 活动形式：线上直播 活动回顾：戳这","tags":["SOFAChannel","Seata"],"title":"SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解","type":"activities","url":"/sofastack.tech/activities/sofa-channel-10/","wordcount":627},{"author":"董一韬、王轲","categories":null,"content":" 本文推荐知道的背景知识：\n Kubernetes 的基本原理和各大组件的职责； Serverless 计算的基本概念和它的优势； Plus: 对社区 Knative 项目的基本了解； 本文根据董一韬和王轲在 KubeCon NA 2019 大会分享整理。\n董一韬 蚂蚁金服，产品经理，致力于驱动云计算相关产品，包括云原生 PaaS 平台、容器与 Serverless 产品等，与最终顾客紧密合作，帮助客户在规模化的金融场景下采用与落地云原生相关解决方案。\n王轲 蚂蚁金服，软件工程师，建设基于 Kubernetes/Knative 的企业级 Serverless 产品，Knative 的早期使用者，Kubernetes 社区成员、控制面流控早期维护者，长期致力于用创新的方式优化、落地云原生技术。\n一. 分享概要 Knative 是 Google 主导的基于 Kubernetes 的 Serverless 平台，在社区上有较高的知名度。然而，身为社区项目的 Knative 主要关心的是标准、架构。虽有先进的理念，却离可在生产上使用有不少的差距。\n本次 KubeCon 的演讲中，来自蚂蚁金服 SOFAStack-PaaS 平台产品技术团队的隐秀和仲乐与大家分享蚂蚁金服金融科技 Knative 的实践和改造：基于 Knative 构建一个优秀的 Serverless 计算平台，详细分析如何用独特的技术，解决性能、容量、成本三大问题。\n从 Serverless 计算的应用场景开始，提炼客户真正的 Use Case，分公有云、私有云、行业云等，讲述 Serverless 计算的多种用途。之后我们将介绍在 Kubernetes 上运行 Knative 平台的方案，详细介绍要使其生产可用，不得不克服的问题。演讲最后，将刚刚的这些问题一一攻破，做出一个比社区版本优秀的 Knative 平台。\n二. 解决性能问题：使用 Pod 预热池 熟悉 Kubernetes 的同学可能知道，Kubernetes 的首要目标并不是性能。\n在一个大规模的 Kubernetes 集群下，要创建一个新的 Pod 并让它跑起来，是很慢的。这是因为这整个链路很长：先要向 APIServer 发一个 POST 请求，再要等 Scheduler 收到新 Pod 资源被创建的事件，再等 Scheduler 在所有的 Node 上运行一遍筛选、优选算法并把调度结果返回给 API Server，再到被选中 Node 的 Kubelet 收到事件，再到Docker 镜像拉取、容器运行，再到通过安全检查并把新的容器注册到 Service Mesh 上…\n任何一个步骤都有可能出现延时、丢事件，或失败（如调度时资源不足是很常见的）。就算一切都正常工作，在一个大规模的 Kubernetes 集群里，整个链路延时达到20s，也是很常见的。\n这便导致在 Kubernetes 上做 Serverless 的窘境：Serverless 的一大特点是自动扩缩容，尤其是自动从0到1，不使用时不占任何资源。但如果一个用户用 Serverless 跑自己的网站/后端，但用户的首个请求花费20s才成功，这是无法接受的。\n为了解决冷启性能问题，我们团队提出了一个创造性的解决方案：使用 Pod 预热池（Pod Pool）。\n我们的产品会预先创建许多个 Pod 并让它们运行起来，当 Kubernetes 的控制器希望创建一个新的 Pod 的时候，我们不再是从零开始新建一个 Pod，而是找到一个处于待命状态的符合条件的 Pod，并把代码注入这个 Pod，直接使用。\n在演讲中，我们分享了一定技术实现的细节，例如如何创建 CRD 并 fork Kubernetes 的 ControllerManager，来以较小的成本实现新 Workload；如何自动根据历史的使用数据来自动伸缩 Pod 池的水位；如何做代码注入等。我们提了3种方式，分别是给容器发指令让容器中的进程下载并执行代码包、使用 Ephemeral Container、魔改 Kubelet允许替换 Container。\n实际的实现比这个还要复杂，要考虑的问题更多，例如如何响应 Pod 中不同的资源 request、limit。我们实际上也实现了一个调度器。当某个预热好的 Pod 不能满足，会看那个 Pod 所在 Node 上的资源余量，如果余量够则动态改 Kubernetes 控制面数据和 cgroups，实现“垂直扩容”。\n实际操作证明，这个冷启优化的效果非常好，当 Pod 大小固定、代码包缓存存在时，启动一个最简单的 HTTP 服务器类型应用的耗时从近20秒优化到了2秒，而且由于不需要当场调度 Pod，从0到1的稳定性也提升了很多。\n这个优化主要是跳过了若干次 API Server 的交互、Pod Schedule 的过程和 Service Mesh 注册的过程，用户程序从零到一的体验得到极大的提升，又不会招致过多的额外成本。一般来讲多预留10-20个 Pod 就可以应付绝大多数情况，对于少见的短时间大量应用流量激增，最坏情况也只是 fallback 到原先的新创建 Pod 的链路。\nPod 预热池不光可以用来做冷启优化，还有很多其他的应用场景。演讲中我呼吁将这种技术标准化，来解决 Kubernetes 数据面性能的问题。会后有观众提出 cncf/wg-serverless 可能有兴趣做这件事情。\n三. 降低成本：共享控制面组件 在成本方面，我们和大家分享了多租户改造和其他的降低成本的方式。\n如果以单租户的方式运行社区版的 Knative，成本是昂贵的：需要部署 Kubernetes 控制面和 Service Mesh 控制面，因为这些都是 Knative 的依赖，Knative 本身的控制面也很占资源。十几C几十G 的机器就这样被使用了，不产生任何业务价值。因此，共享这些控制面的组件是非常必要的。\n通过共享，用户不必再单独为基础设施买单。控制面的成本也只和每个租户创建的应用的数量之和有关，而不会再和租户多少产生关联。\n我们推荐两种共享的方式，一种是 Namespace 隔离+ RBAC 权限控制，这种控制面共享的方法是最简单、Kubernetes 原生支持，也广为使用的一种方法。另一种方法是蚂蚁金服金融科技自研 Kubernetes 实现的多租户方案，通过在 etcd 中多加一级目录并把每个用户的数据存在他们自己的目录中，实现真正全方位多租户的 Kubernetes。\n演讲中还提到了其他的一些降低成本的方法，如通过 Virtual Kubelet 对接阿里云的 ECI（按需的容器服务）、通过 Cluster AutoScaler 来自动释放使用率低的 Kubernetes 节点或从阿里云购置 ECS 来增加新的节点以水平扩容等。还简单提了一下多个租户的容器共享同一个宿主机可能面临的安全问题，如 Docker 逃逸。一种可能的解决方法是使用 Kata Container（虚拟机）以避免共享 Linux 内核。\n四. 解决容量问题：每个层级都做好对分片的支持 容量方面的挑战在于当 Workload 数量增多后， …","date":1577707200,"description":" 本文基于 Knative 构建一个优秀的 Serverless 计算平台，详细分析如何用独特的技术，解决性能、容量、成本三大问题。","dir":"blog/knative-serverless-kubecon-na2019/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ceeb7bee775048b0c23fe553fc5cd335","permalink":"https://sofastack.github.io/sofastack.tech/blog/knative-serverless-kubecon-na2019/","publishdate":"2019-12-30T20:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/knative-serverless-kubecon-na2019/","summary":"本文推荐知道的背景知识： Kubernetes 的基本原理和各大组件的职责； Serverless 计算的基本概念和它的优势； Plus: 对社区 Knative 项目的基本了解； 本文根据董一韬和王轲在 KubeCon NA 2019 大会","tags":["Knative","Serverless"],"title":" 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019","type":"blog","url":"/sofastack.tech/blog/knative-serverless-kubecon-na2019/","wordcount":3400},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News SOFAStack 社区上线了 SOFA Community 试运行方案，欢迎社区内更多的同学参与我们，加入共建❤\n社区随时都欢迎各种贡献，无论是简单的错别字修正、bug 修复还是增加新功能，欢迎提 issue 或 pull request 至 Github 社区。\nSOFA Community 期待你的加入：https://www.sofastack.tech/community/\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@包和平 提问：\n 请问 Seata Saga 状态机可以跨服务来配置吗？案例中的 springcloud-eureka-feign-mybatis-seata 这个和我们的情况类似。这个默认的不是 AT 模式吗？我想使用 Saga 的状态机来配置整个流程，这个情况就涉及了三个服务 storage order account，我看 demo 中都是在单个服务中配置的状态机，所以想询问一下怎么配置。 A：可以跨服务调用，而且服务用不同的 RPC 框架也是可以的，Saga 的事例在 seata-sample 仓库有，Seata 仓库的 test 模块也有很多事例。文档地址：http://seata.io/zh-cn/docs/user/saga.html\n 有 Saga 模式的 spring feign 方式的配置 demo 吗？\n A：没有，不过 Seata Saga 只需要是一个 bean 就可以调用，理论上和什么 RPC 框架无关。\n A 服务的状态机 a_state.json 设置的子状态机是在 B 服务上配置的 b_state.json，可以这样设置吗？\n A：A 服务如果是通过状态机实现的，例如 a_state.json，这个状态机可以调用 B 服务，B 服务也可以是状态机实现的，例如 b_state.json，这两个状态机都不是子状态机，而 a_state.json 其实只知道调到了一个服务，而它内部是什么实现的它不知道。子状态机是要再同一个应用内，才可以被其它状态机调用，跨了应用，则认为只是一个服务。\n Seata 还支持其他方式实现 Saga？ 我看好像都是状态机呢，是我遗漏了哪里吗?\n A：目前是只有状态机。未来会有通过注解+拦截器实现。我所说的“A 服务如果是通过状态机实现的”，服务的实现是可以任何方式的，不是 Saga 的实现。实现一个服务，自己编码也能实现，和框架无关。\n 这个意思其实只是在 A 中调用了 feignClient 是这个意思吧?\n A：是的。\n2、@李宇博 提问：\n Saga 状态机设计器很多属性和文档不太一样呢。\n A：没有和文档不一致的属性吧。你看到的设计器生成的 json，是因为它带了布局信息，它的 stateProps 是和文档是一致的，其它属性是设计器生成的，不需要关心。\n 我没有找到 startState 属性，然后我以为要自己写 next 属性，好像是连线解决了这个问题，还有一点不太明白，就是一个事务只用设计一个 compensationTrigger么？\n A：是的，是用 Start 后面的连线解决，所以不需要 startState 属性了。 compensationTrigger 可以有任意多个，看怎么画好看就行。\n start、success、fail、choice 节点都省去了配置么？还有 compensationtrigger。\n A： Start 里有配置状态机的名称，描述，版本什么的、fail 里可以配置错误码和错误信息，succed 和 choice 应该只有一个名称，没其他的了。\n 嗯嗯，compensationTrigger 是不是也不用配置了?\n A：不用，也是 id 不重就行。\n3、@赵润泽 提问：\n TCC 模式下的事务发起者和 AT 模式下的事务发起者，被代理后执行的操作是一样的吗？\n A：TccActionInterceptor 拦截的是 TwoPhaseBusinessAction 注解也就是拦截的是分支事务，在之前 TM 已经做了 begin，这个是通过 GlobalTransactional 的 intercept 开启的。\n TCC 事务的开启和 AT 事务的开启流程是一样的吗，毕竟都是一个注解？\n A： 是一样的，都是发起方加 GlobalTransactional 注解，对于 TCC 分支来说都要额外加一个 TwoPhaseBusinessAction 注解。\n本周推荐阅读 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 社区活动预告 就在明天，Service Mesh Meetup 第9期杭州站，本期与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用，现场还有机会获得 Istio 官方 T 恤 以及 相关技术书籍。明天，不见不散~\n主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond\n时间：2019年12月28日（明天）13:00-17:30\n地点：杭州西湖区紫霞路西溪谷G座8楼\n报名方式：点击“这里”，即可报名\n","date":1577430000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191227/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"026916366f7c75abaf698dabaed81047","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191227/","publishdate":"2019-12-27T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191227/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 明日活动信息、社区方案上线、落地系列阅读","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191227/","wordcount":1949},{"author":"封尘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，本次主题主要分享在蚂蚁金服当前的体量下，控制面平稳支撑大规模 Sidecar 的落地实践。聚焦控制面核心组件 Pilot 和 Citadel，分享蚂蚁金服双十一控制面如何管理并服务好全站 Sidecar。\n本次分享主要分为两大部分，分别是：\n Pilot 落地实践； Citadel 安全加固； Pilot 落地实践 在开始分享落地实践之前，我们先来看看 Istio 的架构图：\n理想很丰满，现实很骨感。由于性能等方面的综合考虑，我们在落地过程中，将控制面的组件精简为 Pilot 和 Citadel 两个组件了，不使用因性能问题争议不断的 Mixer，不引入 Galley 来避免多一跳的开销。\n在架构图中，控制面组件 Pilot 是与 Sidecar 交互最重要的组件，负责配置转化和下发，直面 Sidecar 规模化带来的挑战。这也是双十一大促中，控制面最大的挑战。\n规模化的问题在生产实践中，是一个组件走向生产可用级的必经之路。接下来将会分别从稳定性、性能优化、监控这三个方面分别展开。\n稳定性增强 我们先梳理下 Pilot 提供的服务能力，从功能实现上来看，Pilot 是一个 Controller + gRPC Server 的服务，通过 List/Watch 各类 K8s 资源，进行整合计算生成 XDS 协议的下发内容，并提供 gRPC 接口服务。本次分享我们先把关注点放在 gRPC 接口服务这个环节，如何保证接口服务支撑大规模 Sidecar 实例，是规模化的一道难题。\n负载均衡\n要具备规模化能力，横向扩展能力是基础。Pilot 的访问方式我们采用常用的 DNSRR 方案，Sidecar 随机访问 Pilot 实例。由于是长连接访问，所以在扩容时，原有的连接没有重连，会造成负载不均。为解决这个问题，我们给 Pilot 增加了连接限流、熔断、定期重置连接功能，并配合 Sidecar 散列重连逻辑，避免产生连接风暴。\n 连接限流 为了降低大量 MOSN 同时连接同一个 Pilot 实例的风险，在 gRPC 首次连接时，Pilot 增加基于令牌桶方案的流控能力，控制新连接的处理响应，并将等待超时的连接主动断连，等待 Sidecar 下一次重连。\n 熔断 基于使用场景的压测数据，限制单实例 Pilot 同时可服务的 Sidecar 数量上限，超过熔断值的新连接会被Pilot 主动拒绝。\n 定期重置 为了实现负载均衡，对于已经存在的旧连接，应该怎么处理呢？我们选择了 Pilot 主动断开连接，不过断开连接的周期怎么定是个技术活。要考虑错开大促峰值，退避扩缩容窗口之类，这个具体值就不列出来了，大家按各自的业务场景来决定就好了。\n Sidecar 散列重连 最后还有一点是 Client 端的配合，我们会控制 Sidecar 重连 Pilot 时，采用退避式重试逻辑，避免对 DNS 和 Pilot 造成负载压力。\n性能优化 规模化的另一道难题是怎么保证服务的性能。在 Pilot 的场景，我们最关注的当然是配置下发的时效性了。性能优化离不开细节，其中部分优化是通用的，也有部分优化是面向业务场景定制的，接下来会分享下我们优化的一些细节点。\n 首次请求优化 社区方案里 Pilot 是通过 Pod.Status 来获取 Pod 的 IP 信息，在小集群的测试中，这个时间基本秒级内可以完成。然而在大集群生产环境中，我们发现 Status 的更新事件时间较慢，甚至出现超过 10s 以上的情况，而且延迟时间不稳定，会增加 Pilot 首次下发的时延。我们通过与基础设施 K8s 打通，由 PaaS 侧将 Pod 分配到的 IP 直接标记到Pod.Annotation 上，从而实现在第一次获取 Pod 事件时，就可以获取到 IP，将该环节的时延减少到0。\n 按需获取 \u0026amp;amp; Custom Resource 缓存 这是一个面向 DBMesh 业务场景的定制性优化，是基于按需获取的逻辑来实现的。其目的在于解决 DBMesh CR 数量过多，过大导致的性能问题，同时避免 Pilot 由于 List/Watch CR 资源导致 OOM 问题，Pilot 采用按需缓存和过期失效的策略来优化内存占用。  局部推送 社区方案中当 Pilot List/Watch 的资源发生变更时，会触发全部 Sidecar 的配置推送，这种方案在生产环境大规模集群下，性能开销是巨大的。举个具体例子，如果单个集群有 10W 以上的 Pod 数量，任何一个 Pod 的变更事件都会触发全部 Sidecar 的下发，这样的性能开销是不可接受的。\n优化的思路也比较简单，如果能够控制下发范围，那就可以将配置下发限制在需要感知变更的 Sidecar 范围里。为此，我们定义了 ScopeConfig CRD 用于描述各类资源信息与哪些 Pod 相关，这样 Pilot 就可以预先计算出配置变更的影响范围，然后只针对受影响的 Sidecar 推送配置。\n 其他优化 强管控能力是大促基本配备，我们给 Pilot Admin API 补充了一些额外能力，支持动态变更推送频率、推送限流、日志级别等功能。\n监控能力 安全生产的基本要求是要具备快速定位和及时止血能力，那么对于 Pilot 来说，我们需要关注的核心功能是配置下发能力，该能力有两个核心监控指标：\n 下发时效性 针对下发的时效性，我们在社区的基础上补充完善了部分下发性能指标，如下发的配置大小分布，下发时延等。\n 配置准确性 而对于配置准确性验证是相对比较复杂的，因为配置的准确性需要依赖 Sidecar 和 Pilot 的配置双方进行检验，因此我们在控制面里引入了 Inspector 组件，定位于配置巡检，版本扫描等运维相关功能模块。\n配置巡检的流程如下：\n Pilot 下发配置时，将配置的摘要信息与配置内容同步下发； MOSN 接收配置时，缓存新配置的摘要信息，并通过 Admin API 暴露查询接口； Inspector 基于控制面的 CR 和 Pod 等信息，计算出对应 MOSN 的配置摘要信息，然后请求 MOSN 接口，对比配置摘要信息是否一致； 由于 Sidecar 的数量较大，Inspector 在巡检时，支持基于不同的巡检策略执行。大体可以分为以下两类：\n 周期性自动巡检，一般使用抽样巡检； SRE 主动触发检查机制； Citadel 安全方案 证书方案 Sidecar 基于社区 SDS 方案 （Secret Discovery Service），支持证书动态发现和热更新能力。同时蚂蚁金服是一家金融科技公司，对安全有更高的要求，不使用 Citadel 的证书自签发能力，而是通过对接内部 KMS 系统获取证书。同时提供证书缓存和证书推送更新能力。\n我们先来看看架构图，请看图：\n对整 …","date":1577271600,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，聚焦控制面核心组件 Pilot 和 Citadel，分享蚂蚁金服双十一控制面如何管理并服务好全站 Sidecar。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f7e9ad6fafaa6db46864cf0704d2b145","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","publishdate":"2019-12-25T19:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","wordcount":3783},{"author":"徐迪、张晓宇","categories":null,"content":" 图为 KubeCon NA 2019 大会分享现场照\nSpeaker:\n 徐迪 蚂蚁金服技术专家：负责蚂蚁金融云PaaS平台建设，Kubernetes 社区老兵，核心代码库贡献量社区前50； 张晓宇 阿里云技术专家：负责阿里巴巴云原生应用容器平台的生态建设，主要设计和研发节点稳定性和资源利用率相关解决方案，同时也是 Kubernetes 社区热心的成员和贡献者。 本文根据徐迪和张晓宇在 KubeCon NA2019 大会分享整理。分享将会从以下几个方面进行切入：首先会简单介绍一下什么是 Sidecar 容器；其次，我们会分享几个蚂蚁金服和阿里巴巴集团的通用场景，以及我们是如何解决这些挑战的。当然，现在还是有很多的挑战需要后续继续解决，邀请大家与我们一同努力。\nSidecar 简介 Sidecar 容器并不是一个新鲜事物。它是一种设计模式，主要用来做一些辅助的工作，比如网络连通性、下载拷贝文件之类的事情；如果大家熟悉 Docker Swarm 的话，就会发现 Docker Ambassador 其实就是 Sidecar。\n看看如上这个例子，Service Consumer 和 Redis Provider 强耦合，部署在同一个节点上。如果这个时候，Redis Provider 出现问题，需要连接到另外一个 Redis 实例上，需要重新配置，并重启 Service Provider。\n那么在引入了 Ambassador 以后，问题变得相对简单些，只需要重启这里的 Redis Ambassador 即可，并不需要 Service Consumer 进行任何变动。\n当然这种模式，还可以进行跨节点通信，比如下图。这样 Service Consumer 和 Redis Provider 就可以部署在不同的节点上。在某种程度上，很容易地就将两种服务进行了解耦。\nSidecar 案例分享 Sidecar 容器能用来干什么？ 一般来讲，Sidecar 容器可以：\n 日志代理/转发，例如 fluentd； Service Mesh，比如 Istio，Linkerd； 代理，比如 Docker Ambassador； 探活：检查某些组件是不是正常工作； 其他辅助性的工作，比如拷贝文件，下载文件等； \u0026amp;hellip; 仅此而已？ 事实上，Sidecar 越来越被大家接受，并且使用越来越广泛。Sidecar 容器通常和业务容器（非 Sidecar 容器）部署在同一个 Pod 里，共享相同的生命周期，为业务容器提供辅助功能。这是一个非常好的模式，能够极大程度解耦应用，并且支持异构组件，降低技术壁垒。\n但目前 Kubernetes 对 Sidecar 的管理还不完善，越来越不满足我们的使用，尤其是在生产环境中使用 Sidecar。\n几个典型案例 1. 顺序依赖 假设我们在一个 Pod 内注入了多个 Sidecar，但是 Sidecar 之间或者 Sidecar 和业务容器之间有相互依赖关系。\n如下这个例子，我们需要先启动 proxy Sidecar 容器用于建立网络连接，这样 mysql client 才能连接到远端的 mysql 集群，并在本地暴露服务。而后主的业务容器才能正常工作。\n#1 proxy_container (sidecar) #2 mysql_client #3 svc_container 当然，有的人会觉得这个地方，可以通过诸如更改镜像启动脚本延迟启动等方法来解决。但是这些方法侵入性太强，不利于扩展，还很难进行准确的配置。\n2. Sidecar 管理 我们来看看另外一个案例。Sidecar 容器和业务容器耦合在同一个 Pod 内，共享相同的生命周期。因此，单独来管控 Sidecar 容器非常不方，比如更新 Sidecar 的镜像。\n比如，我们已经给很多 Pod 注入了 Istio Proxy 这样的 Sidecar 容器，目前运行状态良好。但是如果这个时候我们想升级这个 Proxy 镜像的话，该怎么办？\n如果按照 Istio 社区官方的文档，我们需要重新注入这些 Sidecar 容器。具体来说，需要删除原有 Pod，重新生成一份新的 Pod（有些 workload 关联的 Pod，会由相应的 workload 控制器自动生成）。\n那如果我们有很多个这样的 Pod 需要处理的话，怎么办？通过命令行的话，太不方便，而且容易出错。通过自己单独写的代码的话，可扩展性是个问题，需要频繁更改这些代码。\n而且这里还有另外一个问题，我们肯定不会一下子升级所有的 Sidecar，肯定要有个灰度的过程，也就是只升级一部分 Sidecar，这个时候又该怎么办呢？\n社区进展 上游社区 这里我们非常感谢 Joseph Irving (@Joseph-Irving) 提出了一个 Sidecar kep，通过定义 LifecycleType 来区分是否是 Sidecar 容器。\ntype Lifecycle struct { // Type // One of Standard, Sidecar. // Defaults to Standard // +optional Type LifecycleType `json:\u0026amp;quot;type,omitempty\u0026amp;quot; protobuf:\u0026amp;quot;bytes,3,opt,name=type,casttype=LifecycleType\u0026amp;quot;` } // LifecycleType describes the lifecycle behaviour of the container type LifecycleType string const ( // LifecycleTypeStandard is the default container lifecycle behaviour LifecycleTypeStandard LifecycleType = \u0026amp;quot;Standard\u0026amp;quot; // LifecycleTypeSidecar means that the container will start up before standard containers and be terminated after LifecycleTypeSidecar LifecycleType = \u0026amp;quot;Sidecar\u0026amp;quot; ) 未来只需要在 Pod Spec 中，按如下方式标记即可：\nname: sidecarContainer image: foo lifecycle: type: Sidecar Pod 内容器的启动顺序按照：初始化容器-\u0026amp;gt;Sidecar 容器-\u0026amp;gt;业务容器 的顺序依次启动。\n其中上述 kep 的 kubelet 端实现 正在进行中。\n为了支持 Sidecar 更多的使用场景，我们以此为基础提出了 PreSidecar 和 PostSidecar，分别用于在业务容器之前和之后启动。具体的使用场景见 我们的 PR。\n为什么我们觉得 Sidecar 应该区分前置和后置呢？\n这是因为在一些场景下， …","date":1577188800,"description":" 本文主要介绍了什么是 Sidecar 容器，蚂蚁金服和阿里巴巴集团的通用场景，以及我们是如何解决这些挑战的。","dir":"blog/sidacar-kubecon-na2019/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"db0769ed83607e39fba6020d4eba87b8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sidacar-kubecon-na2019/","publishdate":"2019-12-24T20:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sidacar-kubecon-na2019/","summary":"图为 KubeCon NA 2019 大会分享现场照 Speaker: 徐迪 蚂蚁金服技术专家：负责蚂蚁金融云PaaS平台建设，Kubernetes 社区老兵，核心代码库贡献量社区前50； 张","tags":["Sidecar 容器"],"title":" 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019","type":"blog","url":"/sofastack.tech/blog/sidacar-kubecon-na2019/","wordcount":2993},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@番番 提问：\n MOSN 的配置信息在哪里呢？\n A：MOSN 配置信息已更新到文档中：https://www.sofastack.tech/projects/sofa-mosn/configuration/overview/\n2、@古月 提问：\n 请问 SOFARPC 服务注册 ip 怎么使用主机 ip，不使用分配给容器的 ip？开发时调用容器内的服务调用不到，容器内的服务注册 ip 为 docker 分配的 ip。\n A：https://www.sofastack.tech/projects/sofa-rpc/application-rpc-config/ com.alipay.sofa.rpc.enabled.ip.range # 多网卡 ip 范围 com.alipay.sofa.rpc.bind.network.interface # 绑定网卡 可以通过网卡/ip段过滤；\nSOFARPC：https://github.com/sofastack/sofa-rpc\n SOFABoot 的服务运行在容器内，注册到注册中心的 ip 为容器的 ip，开发机器的调用不到。\n A：下面的两个参数，容器内端口映射到宿主机，virtual.host 用宿主机的去注册， com.alipay.sofa.rpc.virtual.host com.alipay.sofa.rpc.virtual.port\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@聂风 提问：\n SpringCloud 的项目怎么迁移到 SOFA 有这方面的教程文档吗？\n A：可以先参考下这个工程 https://github.com/sofastack/spring-cloud-sofastack-samples ，SOFAStack 集成 SpringCloud 的案例工程，不知道是不是对你有帮助。\n4、@周小斌 提问：\n Seata 以后会考虑集成分库分表和读写分离功能吗（无业务入侵的方式）？\n A：一般是分库分表组件内部中集成 Seata，负载均衡本质上是在切换数据源，一种是通过 DB URL 这种对外是个黑盒，Seata 不需要关注。另外一种是分库分表组件中使用配置中心做对等库物理库配置，这种需要通过 Resource 的 Group 来定义，比如我在一个节点上执行完一阶段，但是在进行二阶段的时候进行了主备切换，这时候需要在新主节点完成回滚。\n5、@温明磊 提问：\n Saga 项目开启时间长了后，会报 java.sql.SQLException: No operations allowed after statement closed. 这个错误。这个类 DbAndReportTcStateLogStore 方法 recordStateMachineStarted。\n A：是不是因为你的数据源连接池配置有问题呢？可能没有配置 testOnBorrow 或者 testOnReturn。\n 是没有。\n A：你配置一个 testOnBorrow。\n 那能不能在数据库连接的代码里判断，还是必须配置 testOnBorrow？Seata Saga 的数据库连接那代码处理异常。\n A：testOnBorrow 是数据源连接池的配置，和 Seata Saga 无关的，连接池你可以用任何连接池，比如 durid，dbcp。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服 ZSearch 在向量检索上的探索 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.8.0 版本，主要变更如下：\n 重构 futex 实现，增加 FUTEX_REQUEUE 支持 支持 SGX 远程证明 增加 sendmsg 和 recvmsg 系统调用 增加 gRPC demo 增加 Intel OpenVINO demo 增加 SGX 远程证明 demo 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.8.0\n2、发布 SOFABolt v1.6.1 版本，主要变更如下：\n 支持 SSL 支持 UserProcessor 生命周期的方法 支持用户自定义 SO_SND_BUF 和 SO_RCV_BUF 支持 RejectedException 的处理策略 优化了生命周期的检查，避免组件在关闭或启动前后仍然能够提供服务 优化了 DefaultConnectionManager 的构造方法以及其它的部分代码 修复 DefaultConnectionManager#check(Connection) 异常信息不完整的问题 修复 AbstractLifeCycle 启动/关闭的并发问题 详细发布报告： https://github.com/sofastack/sofa-bolt/releases/tag/v1.6.1\n社区活动预告 下周六 Service Mesh Meetup 第9期杭州站来啦，本期与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。欢迎参加~\n主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond\n时间：2019年12月28日（下周六）13:00-17:30\n地点：杭州西湖区紫霞路西溪谷G座8楼\n报名方式：点击“这里”，即可报名\n","date":1576825200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191220/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c9e61e735545e48bd341dd6da7310440","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191220/","publishdate":"2019-12-20T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191220/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 配置文档、SOFABolt 等组件发布、社区活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191220/","wordcount":1781},{"author":"十倍","categories":null,"content":" 图为 ZSearch 基础架构负责人十倍 2019 Elastic Dev Day 现场分享\n引言 ElasticSearch（简称 ES）是一个非常受欢迎的分布式全文检索系统，常用于数据分析，搜索，多维过滤等场景。蚂蚁金服从2017年开始向内部业务方提供 ElasticSearch 服务，我们在蚂蚁金服的金融级场景下，总结了不少经验，此次主要给大家分享我们在向量检索上的探索。\nElasticSearch 的痛点 ElasticSearch 广泛应用于蚂蚁金服内部的日志分析、多维分析、搜索等场景。当我们的 ElasticSearch 集群越来越多，用户场景越来越丰富，我们会面临越来越多的痛点：\n 如何管理集群； 如何方便用户接入和管理用户； 如何支持用户不同的个性化需求； \u0026amp;hellip; 为了解决这些痛点，我们开发了 ZSearch 通用搜索平台：\n 基于 K8s 底座，快速创建 ZSearch 组件，快捷运维，故障机自动替换； 跨机房复制，重要业务方高保； 插件平台，用户自定义插件热加载； SmartSearch 简化用户搜索，开箱即用； Router 配合 ES 内部多租户插件，提高资源利用率； 向量检索需求 基于 ElasticSearch 的通用搜索平台 ZSearch 日趋完善，用户越来越多，场景更加丰富。\n随着业务的飞速发展，对于搜索的需求也会增加，比如：搜索图片、语音、相似向量。\n为了解决这个需求，我们是加入一个向量检索引擎还是扩展 ElasticSearch 的能力使其支持向量检索呢？\n我们选择了后者，因为这样我们可以更方便的利用 ElasticSearch 良好的插件规范、丰富的查询函数、分布式可扩展的能力。\n接下来，我来给大家介绍向量检索的基本概念和我们在这上面的实践。\n向量检索基本概念 向量从表现形式上就是一个一维数组。我们需要解决的问题是使用下面的公式度量距离寻找最相似的 K 个向量。\n 欧式距离： 两点间的真实距离，值越小，说明距离越近； 余弦距离： 就是两个向量围成夹角的 cosine 值，cosine 值越大，越相似； 汉明距离： 一般作用于二值化向量，二值化的意思是向量的每一列只有0或者1两种取值。 汉明距离的值就两个向量每列数值的异或和，值越小说明越相似，一般用于图片识别； 杰卡德相似系数： 把向量作为一个集合，所以它可以不仅仅是数字代表，也可以是其他编码，比如词，该值越大说明越相似，一般用于相似语句识别； 因为向量检索场景的向量都是维度很高的，比如256，512位等，计算量很大，所以接下来介绍相应的算法去实现 topN 的相似度召回。\n向量检索算法 KNN 算法 KNN 算法表示的是准确的召回 topK 的向量，这里主要有两种算法，一种是 KDTtree，一种是 Brute Force。我们首先分析了 KDTree 的算法，发现 KDTree 并不适合高维向量召回，于是我们实现的 ES 的 Brute Force 插件，并使用了一些 Java 技巧进行加速运算。\nKDTree 算法 简单来讲，就是把数据按照平面分割，并构造二叉树代表这种分割，在检索的时候，可以通过剪枝减少搜索次数。\n构建树\n以二维平面点(x,y)的集合(2,3)，(5,4)，(9,6)，(4,7)，(8,1)，(7,2)为例：\n图片来源\n 按照 x 排序，确定中间值7，其他坐标分两边； 第二层按照 y 排序，第三层按照 x 排序； 并且在构建时维护每个节点中的 x 最大最小，y 最大最小四个值； 查找最近点\n图片来源\n搜索(3,5)的最近邻：\n 到根节点距离为5； 遍历到右节点(9,6)，发现整棵右子树的x轴，最小值是8，所以所有右子树的节点到查询节点的距离一定都大于8-3=5，于是所有右子树的节点都不需要遍历； 同理，在左子树，跟(5，4)节点比较，(7,2)被排除； 遍历完(2,3),(4,7)，最近点(5,4) 返回； 结论 Lucene 中实现了 BKDTree，可以理解为分块的 KDTree，并且从源码中可以看到 MAX_DIMS = 8，因为 KDTree 的查询复杂度为 O(kn^((k-1)/k))，k 表示维度，n 表示数据量。说明 k 越大，复杂度越接近于线性，所以它并不适合高维向量召回。\nBrute Force 顾名思义，就是暴力比对每一条向量的距离，我们使用 BinaryDocValues 实现了 ES 上的 BF 插件。更进一步，我们要加速计算，所以使用了 JAVA Vector API 。JAVA Vector API 是在 openJDK project Panama 项目中的，它使用了 SIMD 指令优化。\n结论 使用 avx2 指令优化，100w 的 256 维向量，单分片比对，RT 在 260ms，是常规 BF 的 1/6。 ElasticSearch 官方在7.3版本也发布了向量检索功能，底层也是基于 Lucene 的 BinaryDocValues，并且它还集成入了 painless 语法中，使用起来更加灵活。\nANN 算法 可以看到 KNN 的算法会随着数据的增长，时间复杂度也是线性增长。例如在推荐场景中，需要更快的响应时间，允许损失一些召回率。\nANN 的意思就是近似 K 邻近，不一定会召回全部的最近点。ANN 的算法较多，有开源的 ES ANN 插件实现的包括以下这些：\n 基于 Hash 的 LSH； 基于编码的 IVFPQ； 基于图的 HNSW； ZSearch 依据自己的业务场景也开发了 ANN 插件（适配达摩院 Proxima 向量检索引擎的 HNSW 算法）。\nLSH 算法 Local Sensitive Hashing 局部敏感 hash，我们可以把向量通过平面分割做 hash。例如下面图例，0表示点在平面的左侧，1表示点在平面的右侧，然后对向量进行多次 hash，可以看到 hash 值相同的点都比较靠近，所以在 hash 以后，我们只需要计算 hash 值类似的向量，就能较准确的召回 topK。\nIVF-PQ 算法 PQ 是一种编码，例如图中的128维向量，先把向量分成4份，对每一份数据做 kmeans 聚类，每份聚类出256个聚类中心，这样，原始向量就可以使用聚类中心的编号重新编码，可以看出，现在表示一个向量，只需要用4个字节就行。然后当然要记录下聚类中心的向量，它被称之为码本。\n图片来源\nPQ 编码压缩后，要取得好的效果，查询量还是很大，所以前面可以加一层粗过滤，如图，把向量先用 kmeans 聚类成1024个类中心，构成倒排索引，并且计算出每个原始向量与其中心的残差后，对这个残差数据集进行 PQ 量化。用 PQ 处理残差，而不是原始数据的原因是残差的方差能量比原始数据的方差能量要小。\n这样在查询的时候，我们先找出查询出靠近查询向量的几个中心点，然后再在这些中心点中去计算 PQ 量化后的 top 向量，最后把过滤出来的向量再做一次精确计算，返回 topN 结果。\n图片来源\nHNSW 算法 讲 HNSW 算法之前，我们先来讲 NSW 算法，如下图，它是一个顺序构建图流程：\n 例如第5次构造 D …","date":1576670400,"description":" 本文整理自 2019 Elastic Dev Day 现场分享，主要给大家分享蚂蚁金服在向量检索上的探索。","dir":"blog/antfin-zsearch-vector-search/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"194a0b7104c5147b2fd54e8c74b17e22","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-zsearch-vector-search/","publishdate":"2019-12-18T20:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/antfin-zsearch-vector-search/","summary":"图为 ZSearch 基础架构负责人十倍 2019 Elastic Dev Day 现场分享 引言 ElasticSearch（简称 ES）是一个非常受欢迎的分布式全文检索系统，常用于数据分析，搜索","tags":["ZSearch"],"title":" 蚂蚁金服 ZSearch 在向量检索上的探索","type":"blog","url":"/sofastack.tech/blog/antfin-zsearch-vector-search/","wordcount":4634},{"author":"应明","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第六篇 - Operator 篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 是蚂蚁金服下一代技术架构的核心，也是蚂蚁金服内部双十一应用云化的重要一环，本文主要分享在蚂蚁金服当前的体量下，如何支撑应用从现有微服务体系大规模演进到 Service Mesh 架构并平稳落地。\n本文作者：杜宏伟（花名：应明），蚂蚁金服技术专家，关注 API 网关，Service Mesh 和容器网络，蚂蚁金服 Service Mesh 核心成员。\n为什么需要 Service Mesh 在此之前，SOFAStack 作为蚂蚁金服微服务体系下服务治理的核心技术栈，通过提供 Cloud Engine 应用容器、SOFABoot 编程框架（已开源）、SOFARPC（已开源） 等中间件，来实现服务发现和流量管控等能力。经过若干年的严苛金融场景的锤炼，SOFAStack 已经具备极高的可靠性和可扩展性，通过开源共建，也已形成了良好的社区生态，能够与其他开源组件相互替换和集成。在研发迭代上，中间件类库已经与业务解耦，不过避免不了的是，运行时两者在同一个进程内，意味着基础库的升级需要推动业务方升级对应的中间件版本。\n我们一直在探索更好的技术实现方式。我们发现，Service Mesh 通过将原先通过类库形式提供的服务治理能力进行提炼和优化后，下沉到与业务进程协同，但独立运行的 Sidecar Proxy 进程中，大量的 Sidecar Proxy 构成了一张规模庞大的服务网络，为业务提供一致的，高质量的用户体验的同时，也实现了服务治理能力在业务无感的条件下独立进行版本迭代的目标。\n应用 Service Mesh 的挑战 Service Mesh 带给我们的能力很美好，但现实为我们带来的挑战同样很多。比方说数据面技术选型和私有协议支持，控制面与蚂蚁金服内部现有系统对接，配套监控运维体系建设，以及在调用链路增加两跳的情况下如何优化请求延迟和资源使用率等等。\n本文着重从 MOSN（Sidecar Proxy）的运维和风险管控方面，分享我们的实践经验，其他方面的挑战及应对方案，请参考系列分享中的其他文章。\nMOSN：https://github.com/sofastack/sofa-mosn\nSidecar 注入 创建注入 已经完成容器化改造，运行在 Kubernetes 中的应用，如何接入到 Service Mesh 体系中？最简单的方式，也是以 Istio 为代表的 Service Mesh 社区方案所采用的方式，即是在应用发布阶段，通过 mutating webhook 拦截 Pod 创建请求，在原始 Pod Spec 的基础上，为 Pod 注入一个新的 MOSN 容器。\n值得注意的是，在资源分配上，起初我们依据经验值，在应用 8G 内存的场景下，为 Sidecar 分配 512M 内存，即：\nApp: req=8G, limit=8G Sidecar: req=512M, limit=512M\n很快我们就发现了这种分配方案带来的问题，一方面部分流量比较高的应用的 MOSN 容器，出现了严重的内存不足甚至 OOM；另一方面注入进去的 Sidecar 容器额外向调度器申请了一部分内存资源，这部分资源脱离了业务的 quota 管控。\n因此，为了消除内存 OOM 风险和避免业务资源容量规划上的偏差，我们制定了新的“共享内存”策略。在这个策略下，Sidecar 的内存 request 被置为0，不再向调度器额外申请资源；同时 limit 被设置为应用的 1/4，保障 Sidecar 在正常运行的情况下，有充足的内存可用。为了确实达到“共享”的效果，蚂蚁金服 sigma 团队针对 kubelet 做了调整，使之在设置 Sidecar 容器 cgroups limit 为应用 1\u0026amp;frasl;4 的同时，保证整个 Pod 的 limit 没有额外增加（细节这里不展开）。\n当然，Sidecar 与应用“共享”分配到的内存资源，也导致了在异常情况（比如内存泄露）下，sidecar 跟应用抢内存资源的风险。如何应对这个风险？我们的做法是，通过扩展 Pod Spec（及相应的 apiserver, kubelet 链路），我们为 Sidecar 容器额外设置了 Linux oom_score_adj 这个属性，以保障在内存耗尽的情况下，Sidecar 容器会被 OOM Killer 更优先选中，以发挥 sidecar 比应用能够更快速重启，从而更快恢复到正常服务的优势。\n此外，在 CPU 资源的分配上，我们也遇到过在一些场景下，MOSN 抢占不到 CPU 资源从而导致请求延迟大幅抖动，解决方案是确保在注入 Sidecar 时，根据 Pod 内的容器数量，为每个 Sidecar 容器计算出相应的 cpushare 权重，并通过工具扫描并修复全站所有未正确设置的 Pod。\n原地注入 在创建 Pod 的时候注入 Sidecar，是一件相对比较“舒服“的接入方式，因为这种做法，操作起来相对比较简单，应用只需先扩容，再缩容，就可以逐步用带有 Sidecar 的 Pod，替换掉旧的没有 Sidecar 的 Pod。可问题是，在大量应用，大规模接入的时候，需要集群有较大的资源 buffer 来供应用实例进行滚动替换，否则替换过程将变得十分艰难且漫长。而蚂蚁金服走向云原生的目标之一则是，双十一大促不加机器，提高机器使用率。如果说我们要花更多的钱购买更多的机器来支持云原生，就多少有点事与愿违了。\n为了解决这个问题，我们提出了“原地注入”的概念，也就是说在 Pod 不销毁，不重建的情况下，原地把 Sidecar 注入进去。\n如图所示，原地注入由以下步骤构成：\n 在 PaaS 提交工单，选择一批需要原地注入的 Pod； PaaS 调用中间件接口，关闭业务流量并停止应用容器； PaaS 以 annotation 的形式打开 Pod 上的原地注入开关； Operator 观察到 Pod 原地注入开关打开，渲染 sidecar 模版，注入到 Pod 中并调整 cpu/memory 等参数； Operator 将 Pod 内容器期望状态置为运行； kubelet 将 Pod 内容器重新拉起； PaaS 调用中间件接口，打开业务流量； Sidecar 升级 我们将 RPC 等能力从基础库下沉到 Sidecar 之后，基础库升级与业务绑定的问题虽然消除了，但是这部分能力的迭代需求依然存在，只是从升级基础库变成了如何升级 Sidecar。\n最简单的升级就是替换，即销毁 Pod 重新创建出一个新的，这样新建出来的 Pod 所注入的 Sidecar 自然就是新版本了。但通过替换的升级方式，与创建注入存在相似的问题，就是需要大量的资源 buffer，并且，这种升级方式对业务的影响最大，也最慢。\n非平滑升级 为了避免销毁重建 Pod，我们通过 Operator 实现了“非平滑升级” …","date":1576501200,"description":" 本文着重从 MOSN（Sidecar Proxy）的运维和风险管控方面，分享我们的实践经验。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3528d4d6bd82bd170eccd20d98f5f7e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","publishdate":"2019-12-16T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第六篇 - Operator 篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模","tags":["Service mesh","Service Mesh 落地实践"],"title":" 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","wordcount":3725},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@温明磊 提问：\n 我用的 ShardingSqhere 分库分表，按照各个业务方分库。\u0026amp;gt; 所以我们项目里所有分库的表都带了业务方字段biz_code，这个字段的值也就是虚库的名字，都是写在配置里的。 A：从你的需求看，比较简单只是需要按业务方进行分库，而 biz_code 不在状态机日志表的字段里，你可以考虑先算好分库位，然后用 ShadingJDBC 的 hint 功能来设置分库位即可。\n A：我看了一下 ShardingJDBC 也是用的 ThreadLocal 来设置 hint：https://shardingsphere.apache.org/document/current/cn/manual/sharding-jdbc/usage/hint/\n ShadingJDBC 的 hint 功能是基于 ThreadLocal 的，Saga 异步的方式不能用 sharding jdbc 的吗?\n A：有一个优雅的办法：你实现 StateLogStore 接口，然后代理 Seata Saga 的DbAndReportTcStateLogStore，在每个方法前后加上：hintManager.addDatabaseShardingValue();、hintManager.close()，这样就和同步异步没有关系了，因为设置 hint 和 sql 执行都在同一个线程。\n另外，DbAndReportTcStateLogStore 如何传到你自己实现的 StateLogStore 里，你需要继承 DbStateMachineConfig，然后在 afterProperties 方法，先调 super.afterProperties 方法，然后 getStateLogStore()，传入你自己实现的 StateLogStore 里，然后把自己实现的 StateLogStore 调 setStateLogStore 覆盖。\n2、@Purge yao 提问：\n Saga 状态机在线设计器： http://seata.io/saga_designer/index.html 这个状态机可以让流程引擎用吗？\n A：不可以当工作流用，没有人工节点。\n Seata 用这个流程是干嘛用的？\n A：事实上 Seata Saga 模式 是一个具备“服务编排”和“Saga 分布式事务”能力的产品，总结下来它的适用场景是：\n 适用于微服务架构下的“长事务”处理； 适用于微服务架构下的“服务编排”需求； 适用于金融核心系统以上的有大量组合服务的业务系统（比如在渠道层、产品层、集成层的系统）； 适用于业务流程中需要集成遗留系统或外部机构提供的服务的场景（这些服务不可变不能对其提出改造要求）。 Seata：https://github.com/seata/seata\n3、@anorqiu9 提问：\n 关于 MOSN 我们目前遇到一个架构方面的问题，就是原基于 Dubbo 的服务和现在基于 Spring Cloud 的服务互调如何做？一种方案设计服务同时开启两个服务框架的服务接口为两个框架的服务同时提供服务;另一种方案是异构系统基于网关交互.这两种方案有什么优缺点？大家有没有碰到过类似的场景，是如何处理的？谢谢！\n A：Dubbo 和 Spring Cloud 互相调用，需要使用的是 http 接口来调用，个人推荐用网关来做交互，这样 API 的管理上更方便，当然也可以通过 Sidecar 来解决。\n 是的，我也倾向于网关交互，由网关完成协议的转换，进行包括流量控制、安全访问控制等在内的 API 管理工作。如果一个服务同时处于两种服务框架治理之下，就意味着对这个服务的治理（如限流、熔断及安全访问等）必须在两个地方进行，这将会是一个挑战。 当然，如果使用 Service Mesh 架构，通过 Sidecar 如 MOSN 来实现多 RPC 协议的支持，同时又能通过 Service Mesh 的控制平面实现服务治理的统一，这样就不存在上述说的挑战。 MOSN：https://github.com/sofastack/sofa-mosn\n 本周推荐阅读 蚂蚁金服 DB Mesh 的探索与实践 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布SOFARPC v5.6.3，主要变更如下：\n 试验性支持 grpc； 试验性支持 H2 的 tls； 序列化方式支持 msgpack； 修复直接通过线程上下文指定的地址调用； 扩展加载过程日志改为 debug，防止错误信息过多； 升级 jackson 和 netty 的小版本； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.3\n2、发布 SOFAArk v1.1.0，主要变更如下：\n 支持在 Biz 中使用 Ark 扩展点机制； 修复遗漏处理加载 ark spi 类资源 bug； 提供全新的biz/plugin 生命周期事件； 优化SOFAArk 自身日志输出； 优化 SOFAArk 与 SOFABoot 日志依赖管控； telnet 服务支持退出指令； 升级 netty 版本到 4.1.42.Final； 迁移 sofa-ark-samples 到 https://github.com/sofastack-guides/sofa-ark-samples 详细发布报告： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.0\n3、发布 SOFABoot v3.2.1，主要变更如下：\n 版本升级： …","date":1576220400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191213/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"37b96cc1a849775521b4d2b78d6602ce","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191213/","publishdate":"2019-12-13T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191213/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"活动报名、本周 QA、组件发布 | SOFA Weekly","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191213/","wordcount":2258},{"author":"潘潘","categories":"Service Mesh","content":" 概要 活动主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond 活动时间：时间：2019 年 12 月 28 日（周六）13:00-17:30 活动地点：杭州西湖区紫霞路西溪谷G座8楼 活动形式：线下活动 活动回顾：请戳这里 活动介绍 关于 Service Mesh\n服务网格（Service Mesh）是致力于解决服务间通讯的基础设施层。它负责在现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，Service Mesh 通常是通过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一起来实现，而无需感知应用程序本身。\n关于 ServiceMesher 社区\nServiceMesher 社区，专注于 Service Mesh 和云原生技术，立足开源，分享技术资讯和实践，致力于新技术的推广和普及。\nService Mesh Meetup #9 杭州站\nService Mesh Meetup 是由蚂蚁金服联合 CNCF 官方共同出品，ServiceMesher 社区主办，主题围绕服务网格、Kubernetes 及云原生，在全国各地循环举办的技术沙龙。\n本期 Meetup 与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。\n活动议程 时间 环节（分享主题） 分享嘉宾 13:00-13:30 签到 13:30-14:15 《蚂蚁金服 API Gateway Mesh 的思考与实践》 贾岛 蚂蚁金服 高级技术专家 14:15-15:00 《酷家乐的 Istio 与 Knative 踩坑实录》 付铖 酷家乐 容器化负责人 15:00-15:10 MOSN 社区化发布 涵畅 15:10-15:20 茶歇 15:20-16:00 圆桌环节-《Service Mesh 落地的务实与创新》 鲁直 16:00-16:45 《蚂蚁金服 Service Mesh 技术风险思考和实践》 嘉祁 蚂蚁金服 技术专家 16:45-17:30 《网易严选的 Service Mesh 实践》 王国云 网易严选 架构师 本期议题以及嘉宾详解 13:30-14:15《蚂蚁金服 API Gateway Mesh 的思考与实践》\n 讲师：贾岛 蚂蚁金服 高级技术专家 讲师介绍：靳文祥（花名贾岛），2011年毕业后加入支付宝无线团队，一直从事移动网络接入、API 网关、微服务等相关的研发工作，目前负责蚂蚁金服移动网络接入架构设计与优化。 Topic 介绍：在 Service Mesh 微服务架构中，我们常常会听到东西流量和南北流量两个术语。蚂蚁金服开源的Service Mesh Sidecar MOSN 已经多次与大家见面交流了，以往的议题重点在东西流量的服务发现与路由，那么蚂蚁金服在南北流量上的思考是怎样的？本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的，解决了什么问题，双十一的实践表现，以及我们对未来的思考。 14:15-15:00《酷家乐的 Istio 与 Knative 踩坑实录》\n 讲师：付铖 酷家乐 技术专家 讲师介绍：先后负责酷家乐户型图, 渲染引擎等模块，目前负责酷家乐国际站的研发。在业务开发过程中推动和布道云原生技术，并在部分业务落地了 Istio 服务治理和基于 Knative 的 Serverless 基础设施。 Topic 介绍：酷家乐在部分业务模块，自2018年使用了 Istio 进行服务治理，自2019年使用了 Knative 作为 FaaS 基础设施，在实践过程中解决了大量问题，也积累了不少第一手经验。本次分享，将重点讨论服务网格的性能损耗，存量业务迁移难题，函数计算的冷启动时间问题以及解决方案等。 15:20-16:00 圆桌环节《Service Mesh 落地的务实与创新》\n 主持人：鲁直 蚂蚁金服云原生落地负责人 嘉宾： 涵畅 蚂蚁金服高级技术专家 张超盟 华为云微服务平台架构师 付铖 酷家乐技术专家 王国云 网易严选架构师 16:00-16:45《蚂蚁金服 Service Mesh 技术风险思考和实践》\n 讲师：嘉祁 蚂蚁金服 技术专家 讲师介绍：黄家琦（花名：嘉祁）2012年毕业后加入阿里巴巴技术保障，2015年转入蚂蚁金服SRE，长期从事稳定性相关工作，当前重点关注于中间件，Service Mesh 与云原生基础设施的稳定性。 Topic 介绍：Servish Mesh 是微服务架构与云原生碰撞出的火花，对于传统的中间件体系与运维支撑能力是极大的挑战。本次分享的主题主要关注于在蚂蚁金服内部如何应对这些挑战，并建设相应的技术风险能力来保障其稳定。 16:45-17:30《网易严选的 Service Mesh 实践》\n 讲师：王国云 网易高级技术专家、网易严选架构师 讲师介绍：2008年加入网易，长期从事一线的研发与管理工作，曾参与或负责过网易博客、网易邮箱、网易有钱等多个核心产品的研发工作，擅长服务端架构及技术体系建设，现任严选支持业务研发部技术负责人，负责严选的容器化及 Service Mesh 演进。 Topic 介绍：网易严选在2016年选择了 Service Mesh 作为未来微服务改造的基础架构，并在过去几年支持了业务的持续快速增长。本次分享主要介绍 Service Mesh 在严选的落地和演进情况，讨论 Service Mesh 在混合云架构下落地遇到的挑战和我们的解决方案，同时也希望和大家交流一下在架构方面的一些思考。 加入 SOFA 钉钉互动群 群号：23390449，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n主办方与合作伙伴 主办方：CNCF、ServiceMesher 协办方：蚂蚁金服、SOFAStack、滴滴 合作伙伴：掘金社区、开源中国、养码场、SegmentFault、麦思博、开源社 ","date":1576051200,"description":"本次 Meetup 与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。","dir":"activities/service-mesh-meetup-9/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a7103ed15ed823b9156082c37b7d464a","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-meetup-9/","publishdate":"2019-12-11T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/service-mesh-meetup-9/","summary":"概要 活动主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond 活动时间：时间：2019 年 12 月 28 日（周六）13:00-17:30 活动地点：杭州西湖区紫霞路","tags":["Meetup","Service Mesh"],"title":"Service Mesh Meetup#9 杭州站：To Infinity and Beyond","type":"activities","url":"/sofastack.tech/activities/service-mesh-meetup-9/","wordcount":1855},{"author":"改之","categories":"Service mesh","content":" 蚂蚁金服数据访问层有三个核心组件：数据访问框架 ZDAL、数据访问代理 DBP 和 OceanBase 代理服务器 OBProxy。本篇主要涉及 ZDAL 和 OBProxy 两个组件。ZDAL 作为全站数据访问的标准组件，不仅提供了分库分表、读写分离、分布式 Sequence等标准的应用能力，还提供了链路跟踪、影子压测、单元化、容灾切换等技术风险能力 。OBProxy 作为 OceanBase 的访问入口，提供了 OceanBase 路由寻址、读写分离等数据库能力，同时从执行效率和资源成本角度考虑，从 OBProxy 诞生那天我们就采用了近应用的独立进程部署模式，目前生产环境上保持在几十万级别的进程数。\n本篇文章通过介绍当前蚂蚁金服数据访问层遇到的问题，解决的思路，演进的方向三个方面，期望能够用阐述下 DB Mesh 发展的一些思考并让更多同学认识到 DB Mesh。期望能够 DB Mesh 的方式将数据访问层下沉到统一的基础设施之上，让新业务快速使用上全站多年的技术风险能力，并能够持续享受到更多的性能、资源等技术红利。\n背景 随着业务的快速发展，ZDAL 作为客户端模式的组件，一直存在业务耦合、版本迭代推进、多语言支持等问题。OBProxy 是为 OceanBase 数据库专门量身定制的代理服务器，天然就是业务无耦合、支持多语言。用户的数据在 OceanBase 上以多副本的形式存放在各个 OBServer 上，OBProxy 则负责接收用户发过来的 SQL 请求，解析 SQL 请求并计算分区信息后，将用户请求转发到最佳目标 OBServer 上，并将执行结果给用户。在蚂蚁金服内部也存在分库分表组件 ZDAL，用在多 OceanBase 集群以及单元化的场景。两者配合使用，分库分表组件 ZDAL 做业务层的流量调拨，OceanBase 分区功能支持数据库的水平扩容能力。\n我们进一步看 ZDAL 和 OBProxy 这两个组件的核心逻辑。\nZDAL 的核心逻辑：\n SQL 解析器：获得表名及分库分表字段； 规则引擎：计算分库分表结果； 执行层：将 SQL 改写发给数据库，并做结果集合并用户； OBProxy 的核心逻辑：\n 协议解析器：解析协议中的 SQL，Parse 后获得表名及分区字段； 路由器：计算分区表所在的 OBServer； IO 层：将请求转发给 OBServer，将结果集返回给客户端； 可以看出，OBProxy 和 ZDAL 这两个组件的执行路径有一定的重复度，比如两个组件都做了 SQL 解析，并分析表名和字段。这对性能带来一定的损耗，而且这种重复给研发迭代带来更多的工作量。\n基于前面的考虑将 ZDAL 和 OBProxy 两者合并成一个组件的是一个自然的方案，通过将 ZDAL 逻辑下沉到 OBProxy 中，让 OBProxy 提供了分库分表、读写分离、分布式序列等中间件能力，这个组件我们命名为 ODP（Open Database Proxy）。\nODP 作为近业务端部署的进程，虽然逻辑独立出来，升级时但是依然需要去改动业务的容器，所以迭代过程中的升级推进工作也是比较费时费力，而且 ODP 只是整个产品的冰山一角，需要大量的精力来构建冰山之下的基础设施，比如说如何解决 ODP 的运维问题、用户透明切换的方案、复杂配置的推送问题、金融级数据库密钥管理问题等。我们发现这部分与蚂蚁金服内部大规模实践的 ServiceMesh 遇到的问题有比较大的重合度，所以与 ServiceMesh 一起共建底层基础设施，为这块的完整产品方案命名为 DBMesh。下文会简单介绍一下我们的演进路线和发展方向。\n解决思路 Sidecar 模式以解耦部署 从执行效率和资源成本角度考虑，OBProxy 在蚂蚁金服一直都在采用近业务端部署的方式，日常保有的服务数在数十万的级别。近业务端部署虽然提供了高效率，但是也带来了运维上的复杂度，同时需要升级版本时，也需要和通知业务一起来做发布和升级。要让单个应用升级，基本都是按月计，如果涉及到全站层面的升级，时间基本不太好估算。\n但是随着云原生以及 Kubernetes 的发展，让 Sidecar 模式更为成熟，即在业务的容器旁边再运行一个容器，这个非常贴合我们近业务端部署的 OBProxy 进程，只需要将 OBProxy 进程改造成 OBProxy Sidecar，即可进行独立升级、发布、运维等。同时蚂蚁金服在云原生领域有非常深的实践，有着世界上最大规模的 Kubernetes 集群和 ServiceMesh 集群，将 OBProxy 变成 Sidecar 也是比较合理和方便实施的了。\n今年双十一切了约 10% 的数万个的 PODs 到 ODP Sidecar 模式，通过 Sidecar 的方式能够让业务快速享受到基础软件迭代的好处，本次双十一 ODP 修复了一个非预期日志打印导致某个机房出现慢 SQL 问题，在传统的本地进程方式，需要推动所有的业务进行拉迭代、发布、打包时间周期基本不太可控。而今年让所有涉及应用独立的灰度、升级仅花费两天时间。\n合并重复逻辑拿技术红利 解决了部署模式的问题，通过快速迭代并且独立升级的方式，才能让功能下沉的落地成为可能。我们将分库分表组件的大多数功能都下沉到了 ODP 上，比如：分库分表功能、读写分离功能、分布式 Sequence 功能、全链路跟踪等。如下图：\n整个分库分表组件功能下沉之后，在今年双十一我们在核心系统上线，拿到了一些非常可观的技术红利：\n 性能提升：通过功能的合并可以省去额外的 SQL 解析和路由计算过程，双十一上线的系统 SQL 平均响应时间可以下降上百微秒； 启动速度：应用只需要和 ODP 建立连接即可，无需初始化多个分库的数据源，初始化时间从数十秒降到数十毫秒； 内存下降：和启动速度一样，由于应用和 ODP 的连接数减少了，同样也可以节省应用端的内存使用，生产上能够下降上百 MB； 共建 Mesh 基础设施完善技术风险 研发同学会将更多的关注点放在 ODP 数据链路上，如何提高数据平面的性能，如何增加更多的 SQL 特性，而会忽略非 SQL 执行链路上的诉求。DBMesh 作为应用侧的基础设施，更多的要考虑如何更好的管理 Sidecar、数据访问高安全防控、满足配置变更的三板斧要求、最大程度的节省资源成本等。\n我们在与蚂蚁金服 ServiceMesh 团队共建整个云原生下 Mesh 的技术风险能力，优先完善 Sidecar 的运维能力和变更三板斧能力，后续会将 ODP Sidecar 部署到宿主机上以最大程度优化 ODP 的资源占用，也会逐步下沉更多如影子压测、灰度机房、流量镜像等的技术风险能力。\n总结 DBMesh 让数据访问从客户端模式切换到代理模式，给应用带来了启动速度的极大优化。Sidecar 的部署模式则是 SQL 平均响应时间、资源利用的最优模式。将更多的技术风险能力沉淀进来，让新应用快速享受到金融级的技术风险能力，存量应用的技术风险指标更完善。我们期望通过统一的数据访问基础设施，让业务都使用标准的技术组件，降低学习以及维护成本，仅专注在业务开发和创新上。\n作者介绍 易鸿伟（花名：改 …","date":1575982800,"description":" 本篇文章通过介绍当前蚂蚁金服数据访问层遇到的问题，解决的思路，演进的方向三个方面，期望能够用阐述下 DB Mesh 发展的一些思考并让更多同学认识到 DB Mesh。","dir":"blog/ant-financial-db-mesh-explore-practice/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9732786e2e2be0688d1e6a594838f87e","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","publishdate":"2019-12-10T21:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","summary":"蚂蚁金服数据访问层有三个核心组件：数据访问框架 ZDAL、数据访问代理 DBP 和 OceanBase 代理服务器 OBProxy。本篇主要涉及 ZDAL 和 OBProxy 两个组件。ZDAL 作为","tags":["Service mesh","DB Mesh"],"title":"蚂蚁金服 DB Mesh 的演进之路","type":"blog","url":"/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","wordcount":2561},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@温明磊 提问：\n 我们还是想用 redis 存状态机上下文一个大的实体，输入输出只放 id，我想问下，redis 宕机或者其它情况下，状态机 redis 宕机节点之前的节点都是幂等可重复的，那我怎样让它重新跑一边状态机？只能人工干预吗？\n A：你的意思是因为参数没有了，所以你想重跑状态机回放参数？\n 是的。从最开始跑，因为之前的节点幂等， 也没有变更数据，或者数据已经被 catch 住然后补偿了。\n A：我理解是你可以新启动一个状态机事例，把之前的生成的 id 传进上下文，这样和从新开始没有区别吧？不然你人工处理的话，需要把 state_inst 表里的数据删除。\n 嗯 ，我明白 ，通过定时就可以，因为在状态机开始之前 数据已经落库了。redis 宕机捕获异常后，可以给最开始的数据设置状态，然后定时开启状态机。但是 Saga 确实不能帮我完成定时重启状态机这个事情对吧，或者我就设置个补偿节点，专门用来重启新状态机实例的？这样可以？\n A：我建议是不要搞个补偿节点来处理非补偿的事，我觉得可以自己做个定时任务，然后处理这种情况。\nSeata：https://github.com/seata/seata\n2、@李林 提问：\n 数据面默认是能感知到所有服务的变更么？\n A：是的，因为对接了 SOFARegistry。\n 那当集群规模比较大的时候，是不是会出现感知较慢的情况呢？\n A：SOFARegistry 里有全量的服务订阅信息，MOSN 和 SOFARegistry 对接只会感知当前 MOSN 必须的服务信息，所以 MOSN 内的数据总量不会很大。\n Istio 控制面占用的资源比较多，MOSN 是做了优化么？\n A：你指的 Istio 控制面占用资源比较多指的是哪一部分？Mixer 么？\n 可以理解为只告知当前服务需要依赖的信息吧，这样的话数据量就小多了。\n A：是的。\n Pilot 在我们自己的集群里部署了，占用资源也挺多的，不过比 Mixer 小。 另外我查看数据面 Envoy 从 Pilot 拿到的数据信息挺多的，config_dump 的信息有 30 万行左右。\n A：我们暂时没有从 Pilot 拿服务注册数据，只有一些服务流量管控的配置从 Pilot 下发，Mixer 的能力是集成在 MOSN 内部的所以控制面的消耗还好，不是很重。\n 那应该是做了挺多优化调整的吧。\n A：是的，集成后省去了 Mixer 的两跳，Metrics 数据可以直接被采集。\n 那服务的依赖关系需要通过配置提供才能做到只感知需要依赖的服务吧？Metrics 的直接采集是通过 prometheus 直接抓取每个数据面节点的数据么？\n A：是的，通过 prometheus 协议定时有专门的 agent 抓取的数据。\nMOSN：https://github.com/sofastack/sofa-mosn\n3、@NameHaibinZhang 提问：\n 将 MOSN 按照容器化的方式部署，通过读取默认配置，暴露 15001 端口，MOSN 能够同时在一个端口接收不同协议的请求么，如 Http、SOFARPC 请求。\n A：MOSN 的默认配置都是一些 example，没有 15001 端口，你需要按照你的需求写你的配置。一个 listener 目前不能同时处理两种协议，listener 中 proxy 的配置指定了可以处理的协议。\n 15001 端口是按 Sidecar 方式部署的时候开启的端口，比如通过 Istio 来部署，iptables 中 Envoy 开启 15001 端口。\n A：目前同一个端口支持 tls/明文自定识别， http1/http2 的自动识别，协议哪儿配置 Auto。Http 和 SOFA 的识别目前不支持，有需求的话支持也很方便。\n 嗯，因为作为 Sidecar 部署的时候，http 的接口和 SOFA 接口都希望能通过 Sidecar 来做流量劫持，Auto 可以做 rpc 协议的支持和识别不？\n A：如果是做流量劫持的话，其实是不需要支持识别的，这个 15001 不会实际处理请求，会转发给正确的端口来处理。\n Sidecar 内部做一个转发是吧，开另外2个端口，那15001这个端口配置 TCP 协议了，然后接收到之前做判断是什么协议，转给对应的端口。\n A：可以看一下这篇文章：《SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案》。\nSOFA 项目进展 本周发布详情如下：\n发布 Occlum v0.7.0 版本，主要变更如下：\n 重构了 ioctl 的实现； 增加了 socketpair； 实现了与Alpine Linux的二进制兼容性； 增加了 nanosleep； 增加了外部可调用命令的路径检查（即 occlum run 的）； 增加了 XGBoost 的 demo； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.7.0\n社区活动 回顾： 11月24日 Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动回顾（含现场PPT以及视频回顾）：\n Service Mesh 在『路口』的产品思考与实践：务实是根本 深入Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统 12月5日 SOFAChannel#9 直播回顾：\n https://tech.antfin.com/community/live/1021/data/957 预告-专享福利： “剑指源码，尖峰对话”2019 OSC源创会是由 OSCHINA 主办的线下技术沙龙，理念为“自由、开放、分享”，SOFAStack 也受邀参加本次年终盛会，并带来主题分享。\n主题：《蚂蚁金服 Service Mesh 超大规模实践以及开源》\n嘉宾：卓与，蚂蚁金服 Mesh 化落地负责人\n时间：2019年12月15日下午14:05-14:40（架构分会场）\n专享福利：点击“这里”，验证码填写“SOFAStack”即可获得大会免费票。\nTopic 简 …","date":1575615600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191206/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"aa9ec52b9b85a6c8830ff752423d1248","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191206/","publishdate":"2019-12-06T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191206/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【12/2 - 12/6】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191206/","wordcount":2358},{"author":"曹寅","categories":"Kubernetes","content":" 一、前言 经过超过半年的研发，蚂蚁金服在今年完成了 Kubernetes 的全面落地，并使得核心链路100% 运行在 Kubernetes。到今年双十一，蚂蚁金服内部通过 Kubernetes 管理了数以万计的机器以及数十万的业务实例，超过90%的业务已经平稳运行在 Kubernetes 上。整个技术切换过程平稳透明，为云原生的资源基础设施演进迈好了关键的一步。\n本文主要介绍 Kubernetes 在蚂蚁金服的使用情况，双十一大促对 Kubernetes 带来史无前例的挑战以及我们的最佳实践。希望通过分享这些我们在实践过程中的思考，让大家在应用 Kubernetes 时能够更加轻松自如。\n二、蚂蚁金服的 Kubernetes 现状 2.1 发展历程与落地规模 Kubernetes 在蚂蚁金服落地主要经历了四个阶段：\n 平台研发阶段：2018年下半年蚂蚁金服和阿里集团共同投入 Kubernetes 技术生态的研发，力求通过 Kubernetes 替换内部自研平台； 灰度验证：2019年初 Kubernetes 在蚂蚁金服灰度落地，通过对部分资源集群进行架构升级以及灰度替换生产实例两种方式，让 Kubernetes 得以小规模的验证； 云化落地（蚂蚁金服内部基础设施云原生化）：2019年4月蚂蚁金服内部完成 Kubernetes 适配云化环境的目标，并于618之前完成云化机房100% 使用 Kubernetes 的目标，这是 Kubernetes 第一次在蚂蚁金服内部得到规模化的验证； 规模化落地：2019年618之后，蚂蚁金服内部开始全面推动 Kubernetes 落地，在大促之前完成核心链路100% 运行在 Kubernetes的目标，并完美支撑了双十一大考。 2.2 统一资源调度平台 Kubernetes 承载了蚂蚁金服在云原生时代对资源调度的技术目标：统一资源调度。通过统一资源调度，可以有效提升资源利用率，极大的节省资源成本。要做到统一调度，关键在于从资源层面将各个二层平台的调度能力下沉，让资源在 Kubernetes 统一分配。\n蚂蚁金服在落地 Kubernetes 实现统一调度目标时遵循了标准化的扩展方式：\n 一切业务扩展均围绕 Kubernetes APIServer，通过CRD + Operator方式完成业务功能的适配和扩展； 基础服务通过 Node 层定义的资源接口完成个性化适配，有益于形成资源接入的最佳实践。 得益于持续的标准化工作，我们在落地 Kubernetes 的大半年内应用了多项技术，包含安全容器，统一日志，GPU 精细调度，网络安全隔离及安全可信计算等，并通过 Kubernetes 统一使用和管理这些资源服务了大量在线业务以及计算任务型业务。\n三、双十一 Kubernetes 实践 下面我们通过以下几种场景介绍蚂蚁金服内部是如何使用 Kubernetes，以及在此过程中我们面对的挑战和实践之路。\n3.1 资源分时复用 在大促过程中，不同业务域的洪峰流量通常都是在不同时间段来临，而应对这些不同时间到来的业务流量往往都需要大量的额外计算资源做保障。在以往的几次活动中，我们尝试了通过应用快速腾挪的方式来做到资源上的分时复用，但是服务实例上下线需要预热，腾挪耗时不可控，大规模调度的稳定性等因素都影响了最终腾挪方案的实践效果。\n今年双十一我们采用了资源共享调度加精细化切流的技术以达到资源分时利用的目标，为了达到资源充分利用和极速切换的目标，我们在以下方面做了增强：\n 在内部的调度系统引入了联合资源管理（Union-Resource Management），他可以将波峰波谷不重叠的业务实例摆放在相同的资源集合内，达到最大化的资源利用。 研发了一套融合资源更新，流量切换及风险控制的应用分时复用平台，通过该平台SRE可以快速稳定的完成资源切换以应对不同的业务洪峰。 整套平台和技术最终实现了令人激动的成果：蚂蚁金服内部不同业务链路数以万计的实例实现了最大程度的资源共享，这些共享资源的实例可分钟级完成平滑切换。这种技术能力也突破了当下资源水平伸缩能力的效率限制，为资源的分时复用打开了想象空间。\n3.2 计算型任务混部 Kubernetes 社区的落地案例中，我们往往看到的都是各种各样的在线业务，计算型业务往往通过“圈地”式的资源申请和独立的二层调度跑在 Kuberentes 集群中。但是在蚂蚁内部我们从决定使用 Kubernetes 的第一天起，就将 Kubernetes 融合计算型业务实现资源的统一调度作为我们的目标。\n在蚂蚁金服内部我们持续的使用 Kubernetes 支持各类计算业务，例如各类AI 训练任务框架，批处理任务和流式计算等。他们都有一个共同的特点：资源按需申请，即用即走。\n我们通过 Operator 模型适配计算型任务，让任务在真正执行时才会调用 Kubernetes API 申请 Pod 等资源，并在任务退出时删除 Pod 释放资源。同时我们在调度引擎中引入了动态资源调度能力和任务画像系统，这为在线和计算的不同等级业务提供了分级资源保障能力，使在线业务不受影响的情况下资源被最大化的利用。\n今年双十一除了洪峰时间段（00：00~02：00），蚂蚁金服 Kubernetes 上运行的任务均未做降级，每分钟仍有数以百计的计算任务在 Kubernetes 上申请和释放。未来蚂蚁金服内部将会持续推动业务调度融合，将 Kubernetes 打造成为资源调度的航空母舰。\n3.3 规模化核心 蚂蚁金服是目前少数运行了全球最大规模的 Kubernetes 集群的公司之一，单集群机器规模过万，Pods 数量数十万。随着类似计算型任务混部和资源分时复用这类业务的落地，资源的动态使用以及业务自动化运维都对 Kubernetes 的稳定性和性能带来的巨大的挑战。\n首先需要面对的挑战是调度性能，社区的调度器在5k规模测试中调度性能只有1~2 pods/s，这显然无法满足蚂蚁金服的调度性能需求。\n针对同类业务的资源需求往往相同的特点，我们自研了批量调度功能，再加上例如局部的filters性能优化等工作，最终达到了百倍的调度性能提升！\n在解决了调度性能问题后，我们发现规模化场景下 APIServer 逐渐成为了影响 Kubernetes 可用性的关键组件，CRD+Operator 的灵活扩展能力更是对集群造成巨大的压力。业务方有100种方法可以玩垮生产集群，让人防不胜防。 造成这种现象一方面是由于社区今年以前在规模化上的投入较少 APIServer 能力较弱，另一方面也是由 Operator 模式的灵活性决定。开发者在收益于 Operator 高灵活度的同时，往往为集群管理者带来业务不受控制的风险。即使对 Kubernetes 有一定熟悉程度的开发者，也很难保障自己写出的 Operator 在生产中不会引爆大规模的集群。\n面对这种“核按钮”不在集群管理员手上的情况，蚂蚁内部通过两方面入手解决规模化带来的问题：\n 我们通过持续总结迭代过程中的经验，形成了内部的最佳实践原则，以帮助业务更好的设计Operator CRD 在定义时需要明确未来的最大数量，大量CR …","date":1575464400,"description":"本文主要介绍 Kubernetes 在蚂蚁金服的使用情况，双十一大促对 Kubernetes 带来史无前例的挑战以及我们的最佳实践。","dir":"blog/kubernetes-practice-antfinal-shopping-festival/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5e1572fd3da2309cb49050bc05e24450","permalink":"https://sofastack.github.io/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","publishdate":"2019-12-04T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","summary":"一、前言 经过超过半年的研发，蚂蚁金服在今年完成了 Kubernetes 的全面落地，并使得核心链路100% 运行在 Kubernetes。到今年双十一，蚂蚁金服内部通","tags":["Kubernetes"],"title":"深入 Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统","type":"blog","url":"/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","wordcount":3956},{"author":"齐天","categories":"Service mesh","content":" 一、引言 Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』，我们在产品设计上的思考和实践，希望能给大家带来一些启发。\n二、为什么需要 Service Mesh? 2.1 微服务治理与业务逻辑解耦 在 Service Mesh 之前，微服务体系的玩法都是由中间件团队提供一个 SDK 给业务应用使用，在 SDK 中会集成各种服务治理的能力，如：服务发现、负载均衡、熔断限流、服务路由等。\n在运行时，SDK 和业务应用的代码其实是混合在一个进程中运行的，耦合度非常高，这就带来了一系列的问题：\n 升级成本高 每次升级都需要业务应用修改 SDK 版本号，重新发布； 在业务飞速往前跑的时候，是不太愿意停下来做这些和自身业务目标不太相关的事情的； 版本碎片化严重 由于升级成本高，但中间件还是会向前发展，久而久之，就会导致线上 SDK 版本各不统一、能力参差不齐，造成很难统一治理； 中间件演进困难 由于版本碎片化严重，导致中间件向前演进过程中就需要在代码中兼容各种各样的老版本逻辑，戴着『枷锁』前行，无法实现快速迭代； 有了 Service Mesh 之后，我们就可以把 SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以 Sidecar 的模式部署。通过将服务治理能力下沉到基础设施，可以让业务更加专注于业务逻辑，中间件团队则更加专注于各种通用能力，真正实现独立演进，透明升级，提升整体效率。\n2.2 异构系统统一治理 随着新技术的发展和人员更替，在同一家公司中往往会出现使用各种不同语言、不同框架的应用和服务，为了能够统一管控这些服务，以往的做法是为每种语言、每种框架都重新开发一套完整的 SDK，维护成本非常高，而且对中间件团队的人员结构也带来了很大的挑战。\n有了 Service Mesh 之后，通过将主体的服务治理能力下沉到基础设施，多语言的支持就轻松很多了，只需要提供一个非常轻量的 SDK、甚至很多情况都不需要一个单独的 SDK，就可以方便地实现多语言、多协议的统一流量管控、监控等治理需求。\n图片来源\n2.3 金融级网络安全 当前很多公司的微服务体系建设都建立在『内网可信』的假设之上，然而这个原则在当前大规模上云的背景下可能显得有点不合时宜，尤其是涉及到一些金融场景的时候。\n通过 Service Mesh，我们可以更方便地实现应用的身份标识和访问控制，辅之以数据加密，就能实现全链路可信，从而使得服务可以运行于零信任网络中，提升整体安全水位。\n三、在当下『路口』的思考 3.1 云原生方案？ 正因为 Service Mesh 带来了上述种种的好处，所以这两年社区中对 Service Mesh 的关注度越来越高，也涌现出了很多优秀的 Service Mesh 产品，Istio 就是其中一款非常典型的标杆产品。\nIstio 以其前瞻的设计结合云原生的概念，一出现就让人眼前一亮，心之向往。不过深入进去看了之后发现，在目前阶段要落地的话，还是存在一些 gap 的。\n图片来源\n3.2 Greenfield vs Brownfield 在正式展开讨论之前，我们先来看一副漫画。\n图片来源\n上面这幅漫画描绘了这样一个场景：\n 有两个工人在工作，其中一个在绿色的草地（Greenfield）上，另一个在棕色的土地（Brownfield）上； 在绿色草地上的工人对在棕色土地上的工人说：“如果你没有给自己挖这么深的坑，那么你也可以像我一样做一些很棒的新东西”； 然后在棕色土地上的工人回答道：“你倒是下来试试！”； 这是一幅很有意思的漫画，从表面上看我们可以认为在绿色草地上的工人是站着说话不腰疼，不过其实本质的原因还是两者所处的环境不同。\n在一片未开发过的土地上施工确实是很舒服的，因为空间很大，也没有周遭各种限制，可以使用各种新技术、新理念，我们国家近几十年来的一些新区新城的建设就属于这类。而在一片已经开发过的土地上施工就大不一样了，周围环境会有各种限制，比如地下可能有各种管线，一不小心就挖断了，附近还有各种大楼，稍有不慎就可能把楼给挖塌了，所以做起事来就要非常小心，设计方案时也会受到各种约束，无法自由发挥。\n对于软件工程，其实也是一样的，Greenfield 对应着全新的项目或新的系统，Brownfield 对应着成熟的项目或遗留系统。\n我相信大部分程序员都是喜欢做全新的项目的，包括我自己也是一样。因为可以使用新的技术、新的框架，可以按照事物本来的样子去做系统设计，自由度很高。而在开发/维护一个成熟的项目时就不太一样了，一方面项目已经稳定运行，逻辑也非常复杂，所以无法很方便地换成新的技术、新的框架，在设计新功能时也会碍于已有的架构和代码实现做很多妥协，另一方面前人可能不知不觉挖了很多坑，稍有不慎就会掉进坑里，所以行事必须要非常小心，尤其是在做大的架构改变的时候。\n3.3 现实场景 3.3.1 Brownfield 应用当道 在现实中，我们发现目前大部分的公司还没有走向云原生，或者还刚刚在开始探索，所以大量的应用其实还跑在非 k8s 的体系中，比如跑在虚拟机上或者是基于独立的服务注册中心构建微服务体系。\n虽然确实有少量 Greenfield 应用已经在基于云原生来构建了，但现实是那些大量的 Brownfield 应用是公司业务的顶梁柱，承载着更大的业务价值，所以如何把它们纳入 Service Mesh 统一管控，从而带来更大的价值，也就成了更需要优先考虑的话题。\n图片来源 独立的服务注册中心\n3.3.2 云原生方案离生产级尚有一定距离 另一方面，目前 Istio 在整体性能上还存在一些有待解决的点（引述小剑老师在蚂蚁金服 Service Mesh 深度实践中的观点）：\n Mixer Mixer 的性能问题，一直都是 Istio 中最被人诟病的地方； 尤其在 Istio 1.1\u0026amp;frasl;1.2 版本之后引入了 Out-Of-Process Adapter，更是雪上加霜； 从落地的角度看，Mixer V1 糟糕至极的性能，已经是“生命无法承受之重”。对于一般规模的生产级落地而言，Mixer 性能已经是难于接受，更不要提大规模落地…… Mixer V2 方案则给了社区希望：将 Mixer 合并进 Sidecar，引入 web assembly 进行 Adapter 扩展，这是我们期待的 Mixer 落地的正确姿势，是 Mixer 的未来，是 Mixer 的『诗和远方』。然而社区望穿秋水，但Mixer V2 迟迟未能启动，长期处于 In Review 状态，远水解不了近渴； Pilot Pilot 是一个被 Mixer 掩盖的重灾区：长期以来大家的性能关注点都在 Mixer，表现糟糕而且问题明显的Mixer 一直在吸引火力。但是当选择放弃 Mixer（典型如官方在 Istio 新版本中提供的关闭 Mixer 的配置开关）之后，Pilot 的性能问题也就很快浮出水面； 我们实践下来发现 Pilot 目前主要有两大问题：1）无法支撑海量数据 2）每次变化都会触发全量推送，性能较差； 图片来源\n3.4 当 …","date":1575291600,"description":"Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』，我们在产品设计上的思考和实践。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-wushi/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"30414154356f38408eac8044657b5d63","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","publishdate":"2019-12-02T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","summary":"一、引言 Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』","tags":["Service mesh","Service Mesh 落地实践"],"title":"Service Mesh 在『路口』的产品思考与实践：务实是根本","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","wordcount":6226},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News NO.1 社区新认证一位 Committer\nGithub ID @zongtanghu 成为 SOFAJRaft Committer：\n主要贡献：\n 贡献了两个重要 Feature： 基于优先级配置的自动选举； 为 Replicator 日志复制实现 ReplicatorStateListener 监听器； 添加一些优化功能和 Bugfix： 优化 SOFAJRaft 的工具类，减少冗余代码，增加单元测试用例代码； 优化常量类，实现 Copiable 接口； 原创文章贡献 《SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理》; 《中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说》; 目前，社区已经认证超过四十位 Committer。\n感谢对 SOFAStack 的支持和帮助，也欢迎你加入 SOFAStack community~ SOFAStack 社区：https://www.sofastack.tech/awesome/\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@kaka19ace 提问：\n 为什么 MOSN 热重启机制需要新老进程，两个 unix domain socket server 通信交互? 目前分为 旧进程 reconfigerServer 新进程 transferServer, 1. reconfigerServer 只是新进程主动判断 isReconfigure() 就结束了连接； 1. 迁移 listener fd 以及 connection fd 让旧进程作为 client 角色；\n如果仅使用 reconfigerServer 作为交互通信会存在哪些问题？\n A：你的意思就是旧进程 reconfigerServer在收到 isReconfigure() 后，直接传输旧进程的fd给新进程。原理上也是可以的。这儿其实有个历史原因，最开始支持信号 fork 子进程的方式，是不需要 isReconfigure() 来判断是否存在旧进程的，通过环境变量就可以了，后来为了支持容器升级的方式，单独启一个新的进程，才需要一个机制来判断是否存在旧进程，为了改动更小，之前的逻辑不受影响，才加了这个新的 us 来通讯。\n 翻了老版本代码阅读： reconfigure 这块是基于环境变量设置 fd. fork exec 参数使用 sys.ProcAttr 继承 fd 信息。 这块有一个问题确认，老版本场景里如果升级新版的二进制文件，也是基于同目录下替换了相同的 bin 文件，然后再给老进程 hup 信号触发重启吧？\n A：是的，老版本是发送 hup 信号，然后 fork 一个子进程来做二进制升级，这个适用于虚拟机升级。而基于容器的话，是重新拉起一个容器，一个新的进程，就需要跟老的进程来交互。\n 早期版本和 Envoy uds 迁移方式不同，当时设计是有什么考虑吗？后续基于 SCM_RIGHTS 传输 fd 方式与 Envoy 类似，这块重构原因有哪些?想了解代码演进的过程。\n A：你看到代码是 listen fd 的迁移，和 Envoy 最大的不同是我们会把存量的长链接也做迁移。 代码演进是： 第一阶段， 只支持 listen fd 的迁移。 第二阶段， 支持存量长链接的迁移，hup 信号，然后 fork 的方式。 第三阶段， 支持容器间存量长链接的迁移，通过 uds 查找子进程。\n 非常感谢丰富的演进说明。重新拉起容器这块不太明白，对 Envoy 的场景理解： - 热重启是同一个容器内，Sidecar 新老进程的交接，业务进程继续运行； - Sidecar 进程管理是由 pilot-agent 进行管理，当前容器内 agent 发送热重启信号，非重新拉起容器；\nMOSN 这里指的是拉起新容器, 容器间迁移数据？uds 的路径是挂载盘?\n A：Envoy 的方式不能用镜像来管理二进制了。MOSN 除了支持 Envoy 这种容器内热升级，也支持容器间。MOSN 会拉起新容器，然后做容器间的连接迁移，uds 的路径是共享卷，2个 container 共享。\n 容器间迁移是否和业务场景有关，为何不是让旧容器自己销毁（摘掉服务发现, 并延迟一段时间自己销毁）？\n A：是的，就是为了 Sidecar 的发布对用户无感知，连接不断，升级 Sidecar 的时候服务也一直在运行。 MOSN：https://github.com/sofastack/sofa-mosn\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFAJRaft v1.3.0 版本，主要变更如下：\n 新增 Read-only member(learner) 角色，支持 learner 节点上的线性一致读 实现优先级选举 在 multi-raft-group 的场景中，随机打散每个 group 的第一次 snapshot timeout 时间，避免一个进程内多个 group 同时 snapshot RheaKV 实现 snapshot checksum 以及异步 snapshot 致谢（排名不分先后）：@zongtanghu @devYun @masaimu @SteNicholas @yetingsky 详细发布报告： https://github.com/sofastack/sofa-jraft/issues/362\n社区活动 回顾 11月24日 Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动回顾：\n 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇（文末含分享视频回顾以及 PPT 查看地址） 预告 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔 …","date":1575010800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191129/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"af340bf3bee03aa71221229aee4c986b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191129/","publishdate":"2019-11-29T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/25 - 11/29】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191129/","wordcount":2060},{"author":"鲁直、碧远","categories":"Service mesh","content":" 蚂蚁金服云原生负责人鲁直 双十一后首次线下分享\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA（service-oriented architecture，面向服务的架构）体系快速演进至 Service Mesh 架构。聚焦 RPC 层面的设计和改造方案，本次将分享蚂蚁金服双十一核心应用是如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本。\n蚂蚁金服每年双十一大促会面临非常大的流量挑战，在已有 LDC（Logical Data Center，逻辑数据中心，是蚂蚁金服原创的一种“异地多活单元化架构”实现方案）微服务架构下已支撑起弹性扩容能力。本次分享主要分为 5 部分：\n Service Mesh 简介； 为什么要 Service Mesh； 方案落地； 分时调度案例； 思考与未来； 作者简介 黄挺（花名：鲁直）：蚂蚁金服云原生负责人 主要 Focus 领域：\n SOFAStack 微服务领域； Service Mesh，Serverless 等云原生领域； 雷志远（花名：碧远）：蚂蚁金服 RPC 框架负责人 主要 Focus 领域：\n 服务框架：SOFARPC（已开源）； Service Mesh：MOSN（已开源）； SOFARPC：https://github.com/sofastack/sofa-rpc\nMOSN：https://github.com/sofastack/sofa-mosn\nService Mesh 简介 在讲具体的蚂蚁金服落地之前，想先和大家对齐一下 Service Mesh 的概念，和蚂蚁金服对应的产品。这张图大家可能不陌生，这是业界普遍认可的 Service Mesh 架构，对应到蚂蚁金服的 Service Mesh 也分为控制面和数据面，分别叫做 SOFAMesh 和 MOSN，其中 SOFAMesh 后面会以更加开放的姿态参与到 Istio 里面去。\n今天我们讲的实践主要集中在 MOSN 上，以下我的分享中提到的主要就是集中在数据面上的落地，这里面大家可以看到，我们有支持 HTTP/SOFARPC/Dubbo/WebService。\n为什么我们要 Service Mesh 有了一个初步的了解之后，可能大家都会有这样一个疑问，你们为什么要 Service Mesh，我先给出结论：\n因为我们要解决在 SOA 下面，没有解决但亟待解决的：基础架构和业务研发的耦合，以及未来无限的对业务透明的稳定性与高可用相关诉求。\n那么接下来，我们一起先看看在没有 Service Mesh 之前的状况。\n在没有 Service Mesh 之前，整个 SOFAStack 技术演进的过程中，框架和业务的结合相当紧密，对于一些 RPC 层面的需求，比如流量调度，流量镜像，灰度引流等，是需要在 RPC 层面进行升级开发支持，同时，需要业务方来升级对应的中间件版本，这给我们带来了一些困扰和挑战。如图所示：\n 线上客户端框架版本不统一； 业务和框架耦合，升级成本高，很多需求由于在客户端无法推动，需要在服务端做相应的功能，方案不够优雅； 机器逐年增加，如果不增加机器，如何度过双十一； 在基础框架准备完成后，对于新功能，不再升级给用户的 API 层是否可行；  流量调拨，灰度引流，蓝绿发布，AB Test 等新的诉求； 这些都困扰着我们。我们知道在 SOA 的架构下，负责每个服务的团队都可以独立地去负责一个或者多个服务，这些服务的升级维护也不需要其他的团队的接入，SOA 其实做到了团队之间可以按照接口的契约来接耦。但是长期以来，基础设施团队需要推动很多事情，都需要业务团队进行紧密的配合，帮忙升级 JAR 包，基础设施团队和业务团队在工作上的耦合非常严重，上面提到的各种问题，包括线上客户端版本的不一致，升级成本高等等，都是这个问题带来的后果。\n而 Service Mesh 提供了一种可能性，能够将基础设施下沉，让基础设施团队和业务团队能够解耦，让基础设施和业务都可以更加快步地往前跑。\n我们的方案 说了这么多，那我们怎么解决呢？我们经历了这样的选型思考。\n总体目标架构 我们的 MOSN 支持了 Pilot、自有服务发现 SOFARegistry 和自有的消息组件，还有一些 DB 的组件。在产品层，提供给开发者不同的能力，包括运维、监控、安全等能力，这个是目前我们的一个线上的状态。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n 看上去很美好，要走到这个状态，我们要回答业务的三个灵魂拷问。\n这三个问题后面，分别对应着业务的几大诉求，大家做过基础框架的应该比较有感触。\n框架升级方案 准备开始升级之后，我们要分析目前我们的线上情况，而我们现在线上的情况，应用代码和框架有一定程度的解耦，用户面向的是一个 API，最终代码会被打包，在 SOFABoot 中运行起来。\n SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n 那么，我们就可以在风险评估可控的情况下，直接升级底层的 SOFABoot。在这里，我们的 RPC 会检测一些信息，来确定当前 Pod 是否需要开启 MOSN 的能力。然后我们完成如下的步骤。\n我们通过检测 PaaS 传递的容器标识，知道自己是否开启了 MOSN，则将发布和订阅给 MOSN，然后调用不再寻址，直接完成调用。\n可以看到，通过批量的运维操作，我们直接修改了线上的 SOFABoot 版本，以此，来直接使得现有的应用具备了 MOSN 的能力。有些同学可能会问，那你一直这么做不行吗？不行，因为这个操作是要配合流量关闭等操作来运行的，也不具备平滑升级的能力，而且直接和业务代码强相关，不适合长期操作。\n这里我们来详细回答一下，为什么不采用社区的流量劫持方案？\n主要的原因是一方面 iptables 在规则配置较多时，性能下滑严重。另一个更为重要的方面是它的管控性和可观测性不好，出了问题比较难排查。蚂蚁金服在引入 Service Mesh 的时候，就是以全站落地为目标的，而不是简单的“玩具”，所以我们对性能和运维方面的要求非常高，特别是造成业务有损或者资源利用率下降的情况，都是不能接受的。\n容器替换方案 解决了刚刚提到的第一个难题，也只是解决了可以做，而并不能做得好，更没有做得快，面对线上数十万带着流量的业务容器， 我们如何立刻开始实现这些容器的快速稳定接入？\n这么大的量，按照传统的替换接入显然是很耗接入成本的事情，于是我们选择了原地接入，我们可以来看下两者的区别：\n在之前，我们做一些升级操作之类的，都是需要有一定的资源 Buffer，然后批量的进行操作， …","date":1574946000,"description":" 聚焦 RPC 层面的设计和改造方案，本次将分享蚂蚁金服双十一核心应用是如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3d67d3c4d38ced6f9de8a92364c0827c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","publishdate":"2019-11-28T21:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","summary":"蚂蚁金服云原生负责人鲁直 双十一后首次线下分享 引言 Service Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","wordcount":4496},{"author":"悟尘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第五篇 - 网关篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 本文结合无线网关的发展历程，解读进行 Service Mesh 改造的缘由和价值，同时介绍在双十一落地过程中如何保障业务流量平滑迁移至新架构下的 Mesh 网关。分享将从如下三个方面展开：\n 网关的前世今生，解释网关为什么要 Mesh 化； 网关 Mesh 化，阐述如何进行 Mesh 化改造； 双十一落地，介绍在此过程中实现三板斧能力； 前世今生 蚂蚁金服无线网关当前接入数百个业务系统，提供数万个 API 服务，是蚂蚁金服客户端绝对的流量入口，支持的业务横跨支付宝、网商、财富、微贷、芝麻和国际 A+ 等多种场景。面对多种业务形态、复杂网络结构，无线网关的架构也在不断演进。\n中心化网关 在 All In 无线的年代，随着通用能力的沉淀，形成了中心化网关 Gateway。\n 客户端连接到网关接入层集群 Spanner ； Spanner 会把客户端请求转发到无线网关集群 Gateway； Gateway 提供通用能力如鉴权、限流等处理请求，并根据服务标识将请求路由到正确的后端服务；服务处理完请求，响应原路返回； 2016 年新春红包爆发，蚂蚁森林等新兴业务发展壮大，网关集群机器数不断增长。这加剧了运维层面的复杂性，IT成本也不能承受之重。同时，一些核心链路的业务如无线收银台、扫一扫等，迫切需要与其他业务隔离，避免不可预知的突发流量影响到这些高保业务的可用性。因此，2016 年下半年开始建设和推广去中心化网关。\n去中心化网关 去中心化网关将原先集中式网关的能力进行了拆分：\n 转发逻辑：将 Gateway 中根据服务标识转发的能力迁移到 Spanner 上； 网关逻辑：将网关通用能力如鉴权、限流、LDC 等功能，抽成一个 mgw jar 集成到业务系统中，与后端服务同JVM 进程运行； 此时，客户端请求的处理流程如下：\n 客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务的 mgw 中； mgw 进行通用网关能力处理，90% 的请求随即进行 JVM 内部调用； 去中心化网关与集中式网关相比，具有如下优点：\n 提升性能： 少一层网关链路，网关 jar 调用业务是 JVM 内部调用； 大促期间，无需关心网关的容量，有多少业务就有多少网关； 提高稳定性： 集中式网关形态下，网关出现问题，所有业务都会收到影响； 去中心化后，网关的问题，不会影响去中心化的应用； 但凡事具有两面性，随着在 TOP30 的网关应用中落地铺开，去中心化网关的缺点也逐步显现：\n 研发效能低： 接入难：需要引入 15+ pom 依赖、20+ 的配置，深度侵入业务配置； 版本收敛难：当前 mgw.jar 已迭代了 40+ 版本，当前还有业务使用的是初版，难以收敛； 新功能推广难：新能力上线要推动业务升级和发布，往往需要一个月甚至更久时间； 干扰业务稳定性： 依赖冲突，干扰业务稳定性，这种情况发生了不止一次； 网关功能无法灰度、独立监测，资源占用无法评估和隔离； 不支持异构接入：财富域大部分系统是 Node 技术栈，无法使用去中心化网关；  Mesh 网关 去中心化网关存在的诸多问题，多数是由于网关功能与业务进程捆绑在一起造成的。这引发了我们的思考：如果网关功能从业务进程中抽离出来，这些问题是否就可以迎刃而解了？这种想法，与 Service Mesh 的 Sidecar 模式不谋而合。因此在去中心化网关发展了三年后，我们再出发对蚂蚁金服无线网关进行了 Mesh 化改造，以期籍此解决相关痛点。\nMesh 网关与后端服务同 Pod 部署，即 Mesh 网关与业务系统同服务器、不同进程，具备网关的全量能力。客户端请求的处理流程如下：\n 客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务同 Pod 中的 Mesh 网关； Mesh 网关执行通用逻辑后调用同机不同进程的业务服务，完成业务处理； 对比去中心化网关的问题，我们来分析下 Mesh 网关所带来的优势：\n 研发效能： 接入方便：业务无需引入繁杂的依赖和配置，即可接入 Mesh 网关； 版本容易收敛、新功能推广快：新版本在灰度验证通过后，即可全网推广升级，无需维护和排查多版本带来的各种问题； 业务稳定性： 无损升级：业务系统无需感知网关的升级变更，且网关的迭代升级将可利用 MOSN 现有的特性进行细粒度的灰度和验证，做到无损升级； 独立监测：由于和业务系统在不同进程，可以实时遥测 Mesh 网关进程的表现，并据此评估和优化，增强后端服务稳定性； 异构系统接入：Mesh 网关相当于一个代理，对前端屏蔽后端的差异，将支持 SOFARPC、Dubbo 和 gRPC 等主流 RPC 协议，并支持非 SOFA 体系的异构系统接入； 至此，我们卖瓜自夸式地讲完了无线网关的前世今生，解释了为何要撸起袖子进行网关 Mesh 化。但细心的你想必怀疑：\n Mesh 化之后的请求处理流程不是同进程调用，比起去中心化网关多了一跳，是否有性能损耗？ 毕竟进行了大刀阔斧的变革，在上线过程中如何保障稳定性？ 接下来的章节将对上述问题进行解释。\nMesh 化 架构 首先，从架构层面详细介绍网关 Mesh 化所做的相关工作。依照 Service Mesh 的分层模型，Mesh 网关分为数据面和控制面。\n解读：\n 蓝色箭头线是客户端请求的处理流程，Mesh 网关数据面在蚂蚁金服内部 MOSN 的 Sidecar 中； 绿色箭头线是网关配置下发过程，Mesh 网关控制面当前还是由网关管控平台来承载； 红色箭头线条是 MOSN Sidecar 的运维体系； MOSN：https://github.com/sofastack/sofa-mosn\n数据面 采用 Go 语言实现了原先网关的全量能力，融合进 MOSN 的模型中，复用了其他组件已有的能力。 同时网络接入层 Spanner 也实现了请求分发决策能力。\n数据转换 将客户端的请求数据转换成后端请求数据，将后端响应数据转换成客户端响应。利用 MOSN 协议层扩展能力，实现了对网关自有协议 Mmtp 的解析能力。\n通用功能 授权、安全、限流、LDC 和重试等网关通用能力。利用 MOSN Stream Filter 注册机制以及统一的 Stream Send/Receive Filter 接口扩展而来。\n请求路由 客户端请求按照特定规则路由到正确的后端系统。在网关层面实现 LDC 逻辑后，复用 MOSN RPC 组件的路由匹配能力。其中大部分请求都会路由到当前 Zone，从而直接请求到当前 Pod 的业务进程端口。\n后端调用 支持调用多种类型的后端服务，支持对 SOFARPC、Chair 等后端，后期计划支持更多的 RPC 框架和异构系统。\n控制面 为网关用户提供新增、配置 API 等服务的管控系统，可将网关配置数据下发至 Mesh …","date":1574946000,"description":" 本文结合无线网关的发展历程，解读进行 Service Mesh 改造的缘由和价值，同时介绍在双十一落地过程中如何保障业务流量平滑迁移至新架构下的 Mesh 网关。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a51651ca16ad1df8e867f4e25296c50b","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","publishdate":"2019-11-28T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第五篇 - 网关篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","wordcount":3545},{"author":"嘉祁","categories":"Service mesh","content":" 《蚂蚁金服 Service Mesh 大规模落地系列》将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析，文末包含往期系列文章。本文为该系列文章的第三篇 - 运维篇。\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，也是蚂蚁金服内部向云原生演进的重要一环。本文为 Service Mesh 系列文章的运维篇，作者：黄家琦 （花名：嘉祁），蚂蚁金服运维专家，Service Mesh SRE，主要关注云原生基础设施、中间件及 Service Mesh 的稳定性，同时也是 Pythoner，sofa-bolt-python 作者。\n本文将主要分享大规模服务网格在蚂蚁金服当前体量下落地到支撑蚂蚁金服双十一大促过程中，运维角度所面临的挑战与演进。内容包括云原生化的选择与问题，对资源模型的挑战，大规模下运维设施的演进，以及周边技术风险能力的建设。\nService Mesh 在2019年得到了大规模的应用与落地，截止目前，蚂蚁金服的 Service Mesh 数据平面 MOSN 已接入应用数百个，接入容器数量达数十万，是目前已知的全世界最大的 Service Mesh 集群。同时，在刚刚结束的双十一大促中，Service Mesh 的表现也十分亮眼，RPC 峰值 QPS 达到了几千万，消息峰值 TPS 达到了几百万，且引入 Service Mesh 后的平均 RT 增长幅度控制在 0.2 ms 以内。\n拥抱云原生 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。而在具体部署上，保守的做法是以独立进程的方式与业务进程共同存在于业务容器内。我们在蚂蚁金服内部的做法，则从开始，就选择了拥抱云原生。\nSidecar 模式 业务容器内独立进程的好处在于与传统的部署模式兼容，易于快速上线；但独立进程强侵入业务容器，对于镜像化的容器更难于管理。而云原生化，则可以将 Service Mesh 本身的运维与业务容器解耦开来，实现中间件运维能力的下沉。在业务镜像内，仅仅保留长期稳定的 Service Mesh 相关 JVM 参数，从而仅通过少量环境变量完成与 Service Mesh 的联结。同时考虑到面向容器的运维模式的演进，接入 Service Mesh 还同时要求业务完成镜像化，为进一步的云原生演进打下基础。\n 优 劣 独立进程 兼容传统的部署模式；改造成本低；快速上线 侵入业务容器；镜像化难于运维 Sidecar 面向终态；运维解耦 依赖 K8s 基础设施；运维环境改造成本高；应用需要镜像化改造 在接入 Service Mesh 之后，一个典型的 POD 结构可能包含多个 Sidecar：\n MOSN：RPC Mesh, MSG Mesh, \u0026amp;hellip;（扩展中）； 其它 Sidecar； MOSN：https://github.com/sofastack/sofa-mosn\n这些 Sidecar 容器，与业务容器共享相同的网络 Namespace，使得业务进程可以以本地端口访问 Service Mesh 提供的服务，保证了与保守做法一致的体验。\n基础设施云原生支撑 我们也在基础设施层面同步推进了面向云原生的改造，以支撑 Service Mesh 的落地。\n业务全面镜像化 首先是在蚂蚁金服内部推进了全面的镜像化，我们完成了内部核心应用的全量容器的镜像化改造。改造点包括：\n 基础镜像层面增加对于 Service Mesh 的环境变量支撑； 应用 Dockerfile 对于 Service Mesh 的适配； 推进解决了存量前后端分离管理的静态文件的镜像化改造； 推进了大量使用前端区块分发的应用进行了推改拉的改造； 大批量的 VM 模式的容器升级与替换； 容器 POD 化 除了业务镜像层面的改造，Sidecar 模式还需要业务容器全部跑在 POD 上，来适应多容器共享网络。由于直接升级的开发和试错成本很高，我们最终选择将接入 Service Mesh 的 数百个应用的数万个非 K8s 容器，通过大规模扩缩容的方式，全部更换成了 K8s PODs。\n经过这两轮改造，我们在基础设施层面同步完成了面向云原生的改造。\n资源的演进 Sidecar 模式的带来一个重要的问题，如何分配资源。\n理想比例的假设 最初的资源设计基于内存无法超卖的现实。我们做了一个假设：\n MOSN 的基本资源占用与业务选择的规格同比例这一假设。 CPU 和 Memory 申请与业务容器相应比例的额外资源。这一比例最后设定在了 CPU 1/4，Memory 1/16。\n此时一个典型 Pod 的资源分配如下图示：\n这一方式带来了两个问题：\n 蚂蚁金服已经实现了业务资源的 Quota 管控，但 Sidecar 并不在业务容器内，Service Mesh 容器成为了一个资源泄漏点； 业务很多样，部分高流量应用的 Service Mesh 容器出现了严重的内存不足和 OOM 情况； 完美分割的不完美 不止于此，为了快速支撑 Service Mesh 在非云环境的铺开，上线了原地接入 Service Mesh。而原地接入 Service Mesh 的资源无法额外分配，在内存不能超卖的情况下，采取了二次分割的分配方式。此时的 POD 内存资源被切分为1/16内存给 Sidecar，与15/16给业务容器。除了以上两个问题，还带来一些新的问题：\n 业务可见内存不一致，业务监控偏差，业务进程 OOM 风险。 讨论之后，我们追加了一个假设：\n Service Mesh 容器占用的资源实质是在接入 Service Mesh 之前业务已使用的资源。接入 Service Mesh 的过程，同时也是一次资源置换。 共享 基于这个假设，推进了调度层面支持 POD 内的资源超卖，新的资源分配方案如下图，Service Mesh 容器的 CPU、MEM 都从 POD 中超卖出来，业务容器内仍然可以看到全部的资源。\n考虑到内存超卖也引入了 POD OOM 的风险，因此对于 Sidecar 容器还调整了 OOM Score，保证在内存不足时，Service Mesh 进程能够发挥启动比 Java 业务进程更快的优势，降低影响。\n新的分配方案解决了同时解决了以上两个问题，并且平稳支持了大促前的多轮压测。\n重建 但新的分配方案上线时，Service Mesh 已经在弹性建站时同步上线。同时我们还发现在一些场景下，Service Mesh 容器无法抢占到 CPU 资源，导致业务 RT 出现了大幅抖动，原因是在 CPU Share 模式下，POD 内默认并没有等额的分配 CPU Quota 给 Sidecar。\n于是还有两个问题待解决：\n 存量的已分配 Sidecar 仍有 OOM 风险； Sidecar 无法抢占到 CPU； 我们已经无法承受更换全部 POD 的代价。最终在调度的支持下，通过对 Pod Annotation 的手动重新计算+修改，在 POD 内进行了全部资源的重分配，来修复这两个风险。最终的修复容器总数约 25w 个。 …","date":1574859600,"description":" 本文将主要分享大规模服务网格在蚂蚁金服当前体量下落地到支撑蚂蚁金服双十一大促过程中，运维角度所面临的挑战与演进。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b4428f1c979dfa574a7ec8b4d96bc191","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","publishdate":"2019-11-27T21:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","summary":"《蚂蚁金服 Service Mesh 大规模落地系列》将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析，文末","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","wordcount":4049},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解\n 活动时间：12 月 5 日周四晚 7 点\n 活动形式：线上直播\n 直播回看：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。\n12 月 5 日周四晚 7 点，将邀请蚂蚁金服技术专家卓与 ，聚焦 RPC 层面的设计和改造方案，分享蚂蚁金服双十一核心应用如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本，并从核心、RPC、消息等模块展开本次双十一落地实践的实现细节分享。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1021\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服 Service Mesh 双十一落地详解 卓与 蚂蚁金服 Service Mesh 落地负责人\n本期分享大纲： 蚂蚁金服 Service Mesh 架构双十一大规模落地实践案例分析； 从核心、RPC、消息等模块分享蚂蚁金服 Service Mesh 落地实践细节； 欢迎先阅读Service Mesh 落地系列文章，收看直播收获更好的效果； 嘉宾 SOFAGirl 主持人 卓与 蚂蚁金服 Service Mesh 落地负责人 ","date":1574741400,"description":"12 月 5 日周四晚 7 点，线上直播第 9 期。","dir":"activities/sofa-channel-9/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"33ec75a1b0e23d96934a7ec43dfa5df5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-9/","publishdate":"2019-11-26T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-9/","summary":"概要 活动主题：SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解 活动时间：12 月 5 日周四晚 7 点 活动形式：线上直播 直播回看：戳这里 介绍 | SOFAChannel","tags":["SOFAChannel","Service Mesh"],"title":"SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解","type":"activities","url":"/sofastack.tech/activities/sofa-channel-9/","wordcount":554},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@J～杰 提问：\n 帮我看个问题，标红的这个状态没执行是啥原因？ A：没有 Next 属性，可以下载 seata-sample，里面有例子，https://github.com/seata/seata-samples。\n 好的，CompensateState 这个属性是正向失败后，重试这个状态？\n A：正向失败后，触发这个补偿状态。 https://github.com/seata/seata/tree/develop/test/src/test/java/io/seata/saga/engine 为里有很多单元测试案例，代码对应的json在：https://github.com/seata/seata/tree/develop/test/src/test/resources/saga/statelang。 正向失败后，触发这个 CompensateState 状态，但失败后并不会默认就触发补偿流程，需要在 Catch 属性里，Next 到一个 CompensateTrigger。\n 那 Saga 模式下，如果 TC 端发出回滚命令，Saga 怎么处理，没发现有回滚状态？\n A：Saga 模式的 TCC 模式有点不一样的是，Saga 的回滚不是由 TC 来协调，而是只 TC 触发，回滚流程是由状态机执行的。 https://github.com/seata/seata/blob/develop/test/src/test/resources/saga/statelang/simple_statelang_with_compensation.json\n这里是 Catch 到异常后，可以自定义捕获某些异常，然后 Next 到一个处理 state，这个 state 可以是任何 state，如果是 CompensateTrigger 则立即进行回滚。\n Saga 是通过检测异常来识别回滚命令？\n A：Catch 属性是用来检测异常的，但异常的处理可能不仅仅是进行回滚，可能有别的处理逻辑，因业务不同而不同，catch 到这些异常处理，你可以 Next 到任何一个 state 来处理异常；如果希望回滚，框架提供了 CompensateTrigger 这种一个特定的 state，Next 到 CompensateTrigger，则立即进行回滚。\n 如果一个 Saga 状态失败后，RM 一直会重试，这个重试有没有次数限制的？\n A：https://github.com/seata/seata/blob/develop/server/src/main/resources/file.conf.example 重试间隔和重试超时时间, -1是无限重试，比如可以配置成 1d ，只重度一天。\n 还有个问题，发现 catch 没有捕捉到 RuntimeExcepeion 异常： A：它走到 Fail 那个状态去了吗？另外就是 Status 是会执行的，catch 异常和状态判断是两个互不干扰的事情。\n 就是没有走到 Fail 那个状态才奇怪，刚开始我是把 Status 给去掉的，也没走，后来就加上的。这个重试是状态为 un 的时候，TC 就会一直发起重试的吧？\n A：如果没有发起过回滚（补偿流程），失败后 TC 会重试继续完成状态机正向执行，如果发了回滚，回滚失败后 TC 会重试回滚。\n 那如果发生回滚，是从哪个状态节点开始回滚的？\n A：从失败的节点开始。\n 是通过读这张表的数据 seata_state_inst？\n A：对。\nSeata：https://github.com/seata/seata\n2、@胡文伟 提问：\n 双模微服务是指什么？\n A：所谓双模，是指 SOFA 微服务和 Service Mesh 技术的双剑合璧，即“基于 SDK 的 SOFA 微服务”可以和“基于 Sidecar 的 Service Mesh 微服务”实现下列目标： 互联互通：两个体系中的应用可以相互访问； 平滑迁移：应用可以在两个体系中迁移，对于调用该应用的其他应用，做到透明无感知； 异构演进：在互联互通和平滑迁移实现之后，我们就可以根据实际情况进行灵活的应用改造和架构演进。\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.8.1，主要变更如下：\n 新增 MOSN 处理失败请求数的统计； 提升写共享内存时的性能； 优化内存占用与日志输出； 修复日志文件轮转的 Bug； 详细发布报告：https://github.com/sofastack/sofa-mosn/releases/tag/0.8.1\nSOFAChannel 直播推荐 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。聚焦 RPC 层面的设计和改造方案，分享蚂蚁金服双十一核心应用如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本，并从核心、RPC、消息等模块展开分享本次双十一落地实践的实现细节。\n你将收获：\n 蚂蚁金服 Service Mesh 架构双十一大规模落地实践案例分析； 从核心、RPC、消息等模块分享蚂蚁金服 Service Mesh 落地实践细节； 时间：2019年12月5日（周四）19:00-20:00 形式：线上直播 报名方式：点击“这里”即可报名\n","date":1574406000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191122/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d1021e16b4acefdf05a527584900ba69","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191122/","publishdate":"2019-11-22T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191122/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/18 - 11/22】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191122/","wordcount":2007},{"author":"无勤","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 作为蚂蚁金服向下一代云原生架构演进的核心基础设施，在2019年得到了大规模的应用与落地，截止目前，蚂蚁金服的 Service Mesh 数据平面 MOSN 已接入应用数百个，接入容器数量达数十万，一举成为全世界最大的 Service Mesh 集群。同时，在刚刚结束的双十一大促中，Service Mesh 的表现也十分亮眼，RPC 峰值 QPS 达到了几千万，消息峰值 TPS 达到了几百万，且引入 Service Mesh 后的平均 RT 增长幅度控制在 0.2 ms 以内。\n本文作为整个 Service Mesh 系列文章的消息篇，作者：刘翔（花名：无勤），蚂蚁金服消息 Mesh 负责人， 消息中间件核心研发成员，专注于高吞吐、低延迟的消息中间件研发，以及云原生时代下一代消息系统的架构设计与研发。本文将从以下几个方面对消息 Mesh 进行解读：\n 对消息 Mesh 进行介绍，解答消息 Mesh 在整个 Service Mesh 中的地位是什么，它又能为业务带来哪些价值； 结合蚂蚁金服消息中间件团队 Mesh 化的实践与思考，阐述如何在消息领域进行 Mesh 化改造； 消息 Mesh 在蚂蚁金服内部大规模落地过程中遇到的问题与挑战，以及对应的解决方案； 消息流量精细化调度上的思考与在 Mesh 上的实现与落地； 消息 Mesh 简介 Service Mesh 作为云原生场景下微服务架构的基础设施（轻量级的网络代理），正受到越来越多的关注。Service Mesh 不仅负责在微服务架构的复杂拓扑中可靠地传递请求，也将限流、熔断、监控、链路追踪、服务发现、负载均衡、异常处理等与业务逻辑无关的流量控制或服务治理行为下沉，让应用程序能更好地关注自身业务逻辑。\n微服务架构中的通信模式实际上是多种多样的，既包含同步的请求调用，也包含异步的消息/事件驱动，然而流行的 Service Mesh 实现（Istio，Linkerd，Consul Connect等），都仍局限在对微服务中同步请求调用的关注，却无法管理和追踪异步消息流量。而消息 Mesh 则是对这一块的重要补充，通过将消息 Mesh 有机地融合到 Service Mesh 中，可以帮助 Service Mesh 实现对所有微服务流量的管控和追踪，从而进一步完善其架构目标。\n消息 Mesh 的价值 在传统的消息中间件领域，我们更关注的是消息服务端的性能、服务可用性、数据可靠性等核心指标，而与业务应用密切相关的一些能力，包括消息的流量控制（限流、熔断、灰度、着色、分组等），消息的服务治理（消息量级与消息应用拓扑等），消息链路的追踪（消息轨迹）却往往不尽如人意。\n这不仅是因为传统模式下上述能力的提供和优化都涉及客户端的改造与大规模升级，整个过程常常比较漫长，难以快速根据有效反馈不断优化，更重要的是缺乏一个统一的架构指导思想，混乱无序地向客户端叠加相关功能只会让消息客户端变得越来越臃肿和难以维护，也变向增加了业务系统的接入、调试和排查问题的成本。而消息 Mesh 作为 Service Mesh 的补充，能显著带来如下价值和收益：\n 快速升级 - 通过将与业务逻辑无关的一些核心关键能力下沉到 Sidecar 中，使这些能力的单独快速迭代与升级成为可能； 流量控制 - 可以向 Sidecar 中集成各种流量控制策略，例如可根据消息类型、消息数量、消息大小等多种参数来控制消息的发送和消费速率； 流量调度 - 通过打通 Sidecar 节点之间的通信链路，可以利用 Sidecar 的流量转发来实现任意精度的消息流量调度，帮助基于事件驱动的微服务应用进行多版本流量管理、流量着色、分组路由、细粒度的流量灰度与A/B策略等； 消息验证 - 消息验证在基于事件驱动的微服务架构中正变得越来越重要，通过将这部分能力下沉到 Sidecar，不仅可以让业务系统无缝集成消息验证能力，也可以让 Sidecar 通过 Schema 理解消息内容，并进一步具备恶意内容识别等安全管控能力； 可观测性 - 由于所有的消息流量都必须通过 Sidecar，因此可以为 Sidecar 上的消息流量按需增加 Trace 日志，Metrics 采集，消息轨迹数据采集等能力，并借此进一步丰富消息服务的治理能力； 消息 Mesh 化改造 在蚂蚁金服内部，Msgbroker 基于推模型提供高可靠、高实时、事务消息、header 订阅等特性，帮助核心链路进行异步解耦，提升业务的可扩展能力，并先后伴随蚂蚁金服众多核心系统一起经历了分布式改造、单元化改造与弹性改造，目前主要承载蚂蚁内部交易、账务、会员、消费记录等核心在线业务的异步消息流量。\n由于 Service Mesh 的推进目标也是优先覆盖交易支付等核心链路，为在线业务赋能，因此我们优先选择对 Msgbroker 系统进行 Mesh 化改造。下面将以 Msgbroker 为例，重点剖析 Mesh 化后在整体架构和核心交互流程上的变化，为消息领域的 Mesh 化改造提供参考。\n整体架构 消息 Mesh 化后的整体架构如上图所示，与原有的消息架构相比，主要的变化有：\n 客户端不再与服务端直连，而是通过 Sidecar 进行请求的中转，对客户端而言，Sidecar 实际上是它唯一能感知到的消息服务端，对服务端而言，Sidecar 则扮演着客户端的角色； 所有 Sidecar 都会与控制平面交互，接收服务端地址列表、流量管控和调度配置、运行时动态配置等的下发，从而使数据平面具备限流、熔断、异常重试、服务发现、负载均衡、精细化流量调度等能力； 核心交互流程 当 Sidecar 代理了消息客户端的所有请求后，一旦 Sidecar 完成消息服务的发现与服务端/客户端路由数据的缓存，无论是客户端的发消息请求还是服务端的推消息请求，都能由 Sidecar 进行正确的代理转发，而这一切的关键，则是 Sidecar 与消息客户端协同完成一系列的初始化操作。\n消息 Mesh 化后具体的初始化流程如下所示，与原有的初始化流程相对比，主要有如下不同：\n 在经过 Mesh 化改造后，消息客户端不再直接向 SOFARegistry 订阅消息服务端的地址，而是将所有消息元数据（包含业务应用声明的消息 Topic、发送/订阅组 GroupId 等关键信息）通过 HTTP 请求上报给 MOSN，由 MOSN 进行元数据的持久化（用于 MOSN 异常 Crash 后的恢复）以及消息服务端地址的订阅和处理； 当客户端收到 MOSN 对于注册请求的响应时，会主动与 MOSN 建立连接，并将与该连接相关的 Group 集合信息通过控制指令发送给 MOSN，由于客户端与 MOSN 可能存在多个连接，且不同连接上的 Group 集合可以不同，而 MOSN 与同一个消息服务端只维持一个连接，因此控制指令无法向消息数据一样直接进行转发，而是需要 …","date":1574326800,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇-消息篇","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1778dffdda6a839ad3e72183df3393d6","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","publishdate":"2019-11-21T17:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","wordcount":4722},{"author":"卓与","categories":"Service mesh","content":" 2019 年的双十一是蚂蚁金服的重要时刻，大规模落地了 Service Mesh 并顺利保障双十一平稳渡过。我们第一时间与这次的落地负责人进行了交流。\n采访的开头： 花肉：“这次大规模上了 Service Mesh ，双十一值班感觉是什么？” 卓与：“Service Mesh 真的稳。”\n 图为卓与 TOP100 北京峰会分享现场图\n落地负责人介绍 Service Mesh 是蚂蚁金服下一代架构的核心，今年蚂蚁金服大规模的 Service Mesh 落地，我有幸带领并面对了这个挑战，并非常平稳的通过了双十一的大考。\n我个人主要专注在微服务领域，在服务注册与服务框架方向深耕多年，主导过第五代服务注册中心（SOFARegistry）设计与实施，在微服务的架构演进中持续探索新方向，并在蚂蚁金服第五代架构演进中负责内部 Service Mesh 方向的架构设计与落地。\nSOFAStack：https://github.com/sofastack SOFAMosn：https://github.com/sofastack/sofa-mosn\nService Mesh 在蚂蚁金服 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已经渡过探索期，今年已经全面进入深水区探索。\n2019 年的双十一是我们的重要时刻，我们进行了大规模的落地，可能是目前业界最大规模的实践。作为技术人能面对世界级的流量挑战，是非常紧张和兴奋的。当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？我们借助四个“双十一考题”一一为大家揭晓。\nService Mesh 背景知识 Service Mesh 这个概念社区已经火了很久，相关的背景知识从我们的公众号内可以找到非常多的文章，我在这里不做过于冗余的介绍，仅把几个核心概念统一，便于后续理解。\n图1. Service Mesh 开源架构来自 https://istio.io/\nIstio 的架构图上清晰的描述了 Service Mesh 最核心的两个概念：数据面与控制面。数据面负责做网络代理，在服务请求的链路上做一层拦截与转发，可以在链路中做服务路由、链路加密、服务鉴权等，控制面负责做服务发现、服务路由管理、请求度量（放在控制面颇受争议）等。\nService Mesh 带来的好处不再赘述，我们来看下蚂蚁金服的数据面和控制面产品，如下图：\n图2. 蚂蚁金服 Service Mesh 示意架构\n数据面：SOFAMosn。蚂蚁金服使用 Golang 研发的高性能网络代理，作为 Service Mesh 的数据面，承载了蚂蚁金服双十一海量的核心应用流量。\n控制面：SOFAMesh。Istio 改造版，落地过程中精简为 Pilot 和 Citadel，Mixer 直接集成在数据面中避免多一跳的开销。\n2019 Service Mesh 双十一大考揭秘 双十一 SOFAMosn 与 SOFAMesh 经历海量规模大考，顺利保障双十一平稳渡过。今年双十一蚂蚁金服的百十多个核心应用全面接入 SOFAMosn，生产 Mesh 化容器几十万台，双十一峰值 SOFAMosn 承载数据规模数千万 QPS，SOFAMosn 转发平均处理耗时 0.2ms。\n图3. 双十一落地数据\n在如此大规模的接入场景下，我们面对的是极端复杂的场景，同时需要多方全力合作，更要保障数据面的性能稳定性满足大促诉求，整个过程极具挑战。下面我们将从几个方面来分享下我们在这个历程中遇到的问题及解决方案。\n双十一考题 如何让 Service Mesh 发挥最大的业务价值？ 如何达成几十万容器接入 SOFAMosn 的目标？ 如何处理几十万容器 SOFAMosn 的版本升级问题？ 如何保障 Service Mesh 的性能与稳定性达标？ 落地架构 为了更加方便的理解以上问题的解决与后续介绍中可能涉及的术语等，我们先来看下 Service Mesh 落地的主要架构：\n图4. Service Mesh 落地架构\n以上架构图中主要分几部分：\n 数据面：借助 Kubernetes 中的 Pod 模型，SOFAMosn 以独立镜像和 App 镜像共同编排在同一个 Pod 内，共享相同的 Network Namespace、CPU、Memory，接入 SOFAMosn 后所有的 App RPC 流量、消息流量均不在直接对外，而是直接和 SOFAMosn 交互，由 SOFAMosn 直接对接服务注册中心做服务发现，对接 Pilot 做配置下发，对接 MQ Server 做消息收发等； 控制面：由 Pilot、Citadel 和服务注册中心等组件组成，负责服务地址下发、服务路由下发、证书下发等； 底层支撑：Sidecar 的接入与升级等均依赖 Kubernetes 能力，通过 webhook 做 Sidecar 的注入，通过 Operator 做 Sidecar 的版本升级等，相关运维动作均离不开底层的支撑； 产品层：结合底层提供的原子能力做运维能力封装，监控对接，采集 Sidecar 暴露的 Metrics 数据做监控与预警，流量调控，安全等产品化能力； 蚂蚁金服的答卷 1. 如何让 Service Mesh 发挥最大的业务价值？ 作为一个技术人，我们非常坚持不要为了技术革新本身去做技术革新，一定要让技术帮助业务，用技术驱动业务。这几年随着大家消费习惯以及网络行为的改变，双十一面对的业务场景远比想象中复杂。举个例子大家感受下，大家有没有发现你的女友或者老婆每天对着李佳琦的淘宝直播购物，主播们不断的、实时的红包、上新等等，带来了远比秒杀更复杂的业务场景和体量。大促的模式也更加丰富，不同场景下的大促涉及的应用是不同的，每一类应用在应对独特的洪峰时都需要有足够的资源。\n假如运营同学在不同时间点设计了两种活动，两种活动分别会对应两类不同的应用，如果这两类应用都在大促前准备充足的资源自然是轻松渡过大促峰值，但大促洪峰时间短暂，大量的资源投入有很长一段时间都处于空闲状态，这自然不符合技术人的追求。\n那么如何在不增加资源的场景下渡过各种大促呢？\n核心问题就是如何在足够短的时间内做到大规模资源腾挪，让一批机器资源可以在不同时间点承载起不同的大促洪峰。\n面对这样的挑战，我们会有怎样的解法呢？\nService Mesh 618 大促落地试点时，我们有介绍到为什么要做这个事情，核心价值是业务与基础设施解耦，双方可以并行发展，快速往前走。那么并行发展究竟能为业务带来哪些实际的价值？除了降低基础组件的升级难度之外，我们还在资源调度方向做了以下探索：\n1.1 腾挪调度 说到资源调度，最简单的自然是直接做资源腾挪，比如大促A峰值过后，大促A对应的应用通过缩容把资源释放出来，大促B对应的应用再去申请资源做扩容，这种方式非常简单，难点在于当资源规模非常庞大时，缩容扩容的效率极低，应用需要把资源申请出来并启动应用，耗时很长，假如多个大促 …","date":1574154000,"description":" 当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？我们借助四个“双十一考题”一一为大家揭晓。","dir":"blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"269c9444948a5f83a5a17f907b72ce4a","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","publishdate":"2019-11-19T17:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","summary":"2019 年的双十一是蚂蚁金服的重要时刻，大规模落地了 Service Mesh 并顺利保障双十一平稳渡过。我们第一时间与这次的落地负责人进行了交流。 采访的开头： 花肉：“这","tags":["Service mesh","Service Mesh 落地实践"],"title":"Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","wordcount":6239},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@瀚墨 提问：\n 请问 SOFARPC 本地多人开发有没有最佳实践分享一下了？\n A：你说的多人开发具体是指啥协作场景？\n 开发人员开发本地的服务时，需要依赖的服务可以来自一个开发环境！这样的开发人员就不需要启动自己本地所有的服务了。我们已经有一个开发环境，会部署所有的服务，但是当开发人员开发某一个功能时，可能只希望其中几个接口走本地，其他的接口走开发环境！\n A：你的这个开发环境是一组不确定的机器，还是一台指定 IP 的机器？\nSOFARPC：https://github.com/sofastack/sofa-rpc\n 指定的 IP 地址。\n A：一种方法本地调用方直接配开发环境的机器直连调用， 另外一个方法就是开发环境统一使用一个 uniqueId，和本地用不同的uniqueId。\n2、@温明磊 提问：\n Seata Saga 向前重试状态机 json 该怎么配置，节点代码内部和节点 json 的 catch 都不捕获异常吗，这样就会一直调用该节点。\n A：运行过程中向前重试：通过 Catch 到异常然后 Next 到当前节点（这种实现了 Retry 配置之后就不需要了），事后向前重试：直接调 forward 方法即可（一般不需要自己调，server 端会自动触发）。\n Retry 配置什么时候实现，事后向前重试是一定会发生的吗？\n A：Retry 配置正在做了。事后向前重试目前 server 端的逻辑是这样的：失败时，如果没有触发回滚，那么 server 端会不断发起重试，如果触发过回滚（也就是回滚失败了）server 端会不断触发 compensate。\n 这个没用触发回滚，是不是像我上面说的这个出错节点，代码内部没用捕获异常，json 也没有 catch 异常，然后就不断重试了。\n A：是的。\n3、@金雷-上海 提问：\n 看代码，Saga 二阶段提交成功不删分支事务？回滚也是不删，有特殊原因？\n A：你是 server 端的分支事务吗？客户端的状态机日志不会删，server 端没有显示删除分支事务，只是提交或回滚全局事务。\n 嗯，我看了代码是这样，不清楚为什么这么操作。 全局事务表删了，分支事务不删。\n A：是这样的，Saga 模式的回滚是在客户端状态机协调的，不是用 TC 协调的，TC 只是触发，客户端回滚或成功后会调 server 端上报回滚成功。所以我理解是 server 端这时会删除全局事务记录，而没有删除分支事务记录。因为是客户端协调，所以 TC 也没有循环去调每一个分支事务的 rollback，所以分支事务实际上是留下了，没有被删除。\n 既然全局事务都删除了，如果留着没有什么意义，我觉得可以删除分支事务。\n A：是的。提个 issue，修改一下。\n你提的那个 issue 修复了 ，https://github.com/seata/seata/pull/1893 同时做了一个优化，重试和补偿服务不向 Seata server 注册分支事务，仅原始服务注册分支事务，重试和补偿服务执行完成时向原始服务注册的分支事务上报成功与否的状态。\nRetry 功能，\u0026amp;rdquo;BackoffRate\u0026amp;rdquo;: 1.5，表示重试间隔增量，1.5表示本次重试间隔是上次的1.5倍：https://github.com/seata/seata/issues/1899\n还有一个点，当重试过程中生了别的异常，框架会重新匹配这个异常对应的重试规则，并按新规则来重试，但同一种规则的总次数的不会超过它配置的 MaxAttempts，避免不同异常来回切换而一直重试。\n 新规则就是下面这个配置吗？\n A： 就是你可以配置多个重试规则，根据 Exceptions 属性来匹配，下面那个没有带 Exceptions 表示框架自动匹配网络超时异常。\n 配置了 Exceptions，不只是可以匹配节点的异常，还可以匹配重试的异常，执行新的重试规则。\n A：对的。\n4、@J～杰 提问：\n 我看整个 Saga 流程引擎都是自己开发的，那个 json 的参数属性含义哪里可以参考？\n A：这是官网文档，每个属性的含义，可以看 State language referance 节。 http://seata.io/zh-cn/docs/user/saga.html\n 如果用了 @GlobalTransactional，在并发场景中，是不是还要用 @GlobalLock 保证数据的隔离性？\n A：@GlobalLock 是用于非分布式事务场景下的读分布式事务中数据。在分布式事务的场景本身有全局锁来隔离。\nSeata：https://github.com/seata/seata\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 万字长文丨1分36秒，100亿，支付宝技术双11答卷：没有不可能 SOFA 项目进展 本周发布详情如下：\n发布 SOFATracer v2.4.2\u0026amp;frasl;3.0.8，主要变更如下：\n 迁移 samples 到 sofastack-guides空间下 修复 Server Receive 阶段出现 spanId 增长问题 优化 Zipkin 远程上报问题 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.2 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.8\n云原生活动推荐  本期为 Service Mesh Meetup#8 特别场，联合 CNCF、阿里巴巴及蚂蚁金服共同举办。\n不是任何一朵云都撑得住双 11。\n成交 2684 亿，阿里巴巴核心系统 100% 上云。\n蚂蚁金服的核心交易链路大规模上线 Service Mesh。\n这次，让双 11 狂欢继续，让云原生经得起双 11 大考，也让云原生走到开发者身边。\n你将收获 3 大经验加持：\n 双 11 洗礼下的阿里巴巴 K8s 超大规模实践经验 蚂蚁金服首次 Service Mesh 大规模落地经验 阿里巴巴超大规模神龙裸金属 K8s …","date":1573801200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191115/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c08a41ec62ae153bbc0ce35958093192","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191115/","publishdate":"2019-11-15T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191115/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/11 - 11/15】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191115/","wordcount":2326},{"author":"烈元","categories":"Service mesh","content":" 揭秘 2019 Service Mesh 双十一大考 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已经渡过探索期，今年已经全面进入深水区探索。\n2019 年的双十一是我们的重要时刻，我们进行了大规模的落地。作为技术人能面对世界级的流量挑战，是非常紧张和兴奋的。当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？让我们一起来揭秘蚂蚁金服 Service Mesh 双十一实战。\nService Mesh 基础概念 Istio 清晰的描述了 Service Mesh 最核心的两个概念：数据面与控制面。数据面负责做网络代理，在服务请求的链路上做一层拦截与转发，可以在链路中做服务路由、链路加密、服务鉴权等，控制面负责做服务发现、服务路由管理、请求度量（放在控制面颇受争议）等。\nService Mesh 带来的好处不再赘述，我们来看下蚂蚁金服的数据面和控制面产品：\n 数据面：SOFAMosn。蚂蚁金服使用 Golang 研发的高性能网络代理，作为 Service Mesh 的数据面，承载了蚂蚁金服双十一海量的核心应用流量。\n 控制面：SOFAMesh。Istio 改造版，落地过程中精简为 Pilot 和 Citadel，Mixer 直接集成在数据面中避免多一跳的开销。\n 双十一落地情况概览 今年，蚂蚁金服的核心应用全面接入 SOFAMosn，生产 Mesh 化容器几十万台，双十一峰值 SOFAMosn 承载数据规模数千万 QPS，SOFAMosn 转发平均处理耗时 0.2ms。\n在如此大规模的接入场景下，我们面对的是极端复杂的场景，同时需要多方全力合作，更要保障数据面的性能稳定性满足大促诉求，整个过程极具挑战。\n同时，Service Mesh 的落地也是一个跨团队合作的典范案例，集合了核心、RPC、消息、无线网关、控制面、安全、运维、测试等团队的精诚合作，接下来我们会按照以上几个模块来解析 Service Mesh 的双十一落地情况，更多解析关注本网站。\n本文为《蚂蚁金服 Service Mesh 落地实践系列》第一篇 - 核心篇，作者：田阳（花名：烈元），蚂蚁金服技术专家，专注于高性能网络服务器研发，Tengine 开源项目核心成员，蚂蚁金服开源 SOFAMosn 项目核心成员。\n基础能力建设 SOFAMosn 的能力大图 SOFAMosn 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 XDS 等云原生能力。\n业务支持 SOFAMosn 作为底层的高性能安全网络代理，支撑了 RPC，MSG，GATEWAY 等业务场景。\nIO 模型 SOFAMosn 支持两种 IO 模型，一个是 Golang 经典模型，goroutine-per-connection；一个是 RawEpoll 模型，也就是 Reactor 模式，I/O 多路复用(I/O multiplexing) + 非阻塞 I/O(non-blocking I/O)的模式。\n在蚂蚁金服内部的落地场景，连接数不是瓶颈，都在几千或者上万的量级，我们选择了 Golang 经典模型。而对于接入层和网关有大量长链接的场景，更加适合于 RawEpoll 模型。\n协程模型 一条 TCP 连接对应一个 Read 协程，执行收包，协议解析； 一个请求对应一个 worker 协程，执行业务处理，proxy 和 Write 逻辑； 常规模型一个 TCP 连接将有 Read/Write 两个协程，我们取消了单独的 Write 协程，让 workerpool 工作协程代替，减少了调度延迟和内存占用。\n能力扩展 协议扩展\nSOFAMosn 通过使用同一的编解码引擎以及编/解码器核心接口，提供协议的 plugin 机制，包括支持：\n SOFARPC； HTTP1.x/HTTP2.0； Dubbo； NetworkFilter 扩展\nSOFAMosn 通过提供 network filter 注册机制以及统一的 packet read/write filter 接口，实现了 Network filter 扩展机制，当前支持：\n TCP proxy； Fault injection； StreamFilter 扩展\nSOFAMosn 通过提供 stream filter 注册机制以及统一的 stream send/receive filter 接口，实现了 Stream filter 扩展机制，包括支持：\n 流量镜像； RBAC鉴权； TLS 安全链路 作为金融科技公司，资金安全是最重要的一环，链路加密又是其中最基础的能力，在 TLS 安全链路上我们进行了大量的调研测试。\n通过测试，原生的 Go 的 TLS 经过了大量的汇编优化，在性能上是 Nginx(OpenSSL）的80%，Boring 版本的 Go(使用 cgo 调用 BoringSSL) 因为 cgo 的性能问题， 并不占优势，所以我们最后选型原生 Go 的 TLS，相信 Go Runtime 团队后续会有更多的优化，我们也会有一些优化计划。\n go 在 RSA 上没有太多优化，go-boring（CGO）的能力是 go 的1倍； p256 在 go 上有汇编优化，ECDSA 优于go-boring； 在 AES-GCM 对称加密上，go 的能力是 go-boring 的20倍； 在 SHA、MD 等 HASH 算法也有对应的汇编优化； 为了满足金融场景的安全合规，我们同时也对国产密码进行了开发支持，这个是 Go Runtime 所没有的。虽然目前的性能相比国际标准 AES-GCM 还是有一些差距，大概是 50%，但是我们已经有了后续的一些优化计划，敬请期待。\n平滑升级能力 为了让 SOFAMosn 的发布对应用无感知，我们调研开发了平滑升级方案，类似 Nginx 的二进制热升级能力，但是有个最大的区别就是 SOFAMosn 老进程的连接不会断，而是迁移给新的进程，包括底层的 socket FD 和上层的应用数据，保证整个二进制发布过程中业务不受损，对业务无感知。除了支持 SOFARPC、Dubbo、消息等协议，我们还支持 TLS 加密链路的迁移。\n容器升级\n基于容器平滑升级 SOFAMosn 给了我们很多挑战，我们会先注入一个新的 SOFAMosn，然后他会通过共享卷的 UnixSocket 去检查是否存在老的 SOFAMosn，如果存在就和老的 SOFAMosn 进行连接迁移，然后老的 SOFAMosn 退出。这一块的细节较多，涉及 SOFAMosn 自身和 Operator 的交互。\nSOFAMosn 的连接迁移\n连接迁移的核心主要是内核 Socket 的迁移和应用数据的迁移，连接不断，对用户无感知。\nSOFAMosn 的 metric 迁移\n我们使用了共享内存来共享新老进程的 metric 数据，保证在迁移的过程中 metric 数据也是 …","date":1573779600,"description":" 当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？让我们一起来揭秘蚂蚁金服 Service Mesh 双十一实战。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f758a3d4476cd3e8516947fa6fff5747","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","publishdate":"2019-11-15T09:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","summary":"揭秘 2019 Service Mesh 双十一大考 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","wordcount":3391},{"author":"潘潘","categories":"Service Mesh","content":" 概要 活动主题：Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动时间：2019 年 11 月 24 日（星期日）9:30-16:30 活动地点：北京朝阳大望京科技商务园区宏泰东街浦项中心B座2层多功能厅 活动形式：线下活动 活动报名：请戳这里 活动介绍 Service Mesh Meetup#8 特别场 本期为 Service Mesh Meetup#8 特别场，联合 CNCF、阿里巴巴及蚂蚁金服 共同举办。\n不是任何一朵云都撑得住双 11。\n成交 2684 亿，阿里巴巴核心系统 100% 上云。\n蚂蚁金服的核心交易链路大规模上线 Service Mesh。\n这次，让双 11 狂欢继续，让云原生经得起双 11 大考，也让云原生走到开发者身边。\n你将收获 3 大经验加持：\n 双 11 洗礼下的阿里巴巴 K8s 超大规模实践经验； 蚂蚁金服首次 Service Mesh 大规模落地经验； 阿里巴巴超大规模神龙裸金属 K8s 集群运维实践经验； 错过一次，再等一年哦。\n议程 时间 环节（分享主题） 分享嘉宾 9:00-9:30 签到 9:30-10:10 《释放云原生价值，双 11 洗礼下的阿里巴巴 K8s 超大规模实践》 曾凡松（逐灵），阿里巴巴高级技术专家；汪萌海（木苏），阿里巴巴技术专家 10:10-10:50 《蚂蚁金服双十一Service Mesh超大规模落地揭秘》 黄挺（鲁直），蚂蚁金服云原生负责人；雷志远（碧远），蚂蚁金服技术专家 10:50-11:30 《阿里巴巴超大规模神龙裸金属 K8s 集群运维实践》 周涛 （广侯），阿里巴巴高级技术专家 11:30-12:10  《深入Kubernetes的“无人区” — 蚂蚁金服双十一的调度系统》 曹寅，蚂蚁金服 Kubernetes 落地负责人 12:10-13:30 午休 13:30-14:10  《服务网格在“路口”的产品思考与实践》 宋顺（齐天），蚂蚁金服高级技术专家，开源配置中心Apollo作者 14:10-14:50 《阿里集团核心应用落地 Service Mesh 的挑战与机遇》 李云（至简），阿里巴巴高级技术专家 14:50-13:10 茶歇 15:10-15:50 《蚂蚁金服云原生 PaaS 实践之路》 王成昌（晙曦），蚂蚁金服技术专家 15:50-16:30 《函数计算在双十一小程序场景的应用》 吴天龙（木吴），阿里云函数计算技术专家 加入 SOFA 钉钉互动群 群号：23390449，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n","date":1573639200,"description":"11月24日，Service Mesh Meetup#8 双十一特别场邀您参加，本期联合 CNCF、阿里巴巴及蚂蚁金服共同举办。","dir":"activities/service-mesh-meetup-8/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f127ede30ff37760f648b79ecf887ffa","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-meetup-8/","publishdate":"2019-11-13T18:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-meetup-8/","summary":"概要 活动主题：Kubernetes \u0026amp; Cloud Native X Service Mesh Meetup 活动时间：2019 年 11 月 24 日（星期日）9:30-16:30 活动地点：北京朝阳大望京科技商务园","tags":["Meetup","Service Mesh","Kubernetes"],"title":"Kubernetes \u0026 Cloud Native X Service Mesh Meetup","type":"activities","url":"/sofastack.tech/activities/service-mesh-meetup-8/","wordcount":758},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@温明磊 提问： \u0026amp;gt; 出参入参都放在 Saga 的上下文中，如果参数内容较多较大，业务量又大的话，对内存有限制吗?\nA: 没有做限制，建议无关的参数不要放到上下文。下一个服务需要用的参数、或用于分支判断的参数可以放入上下文。\n 确认个事情：每个节点，要么自己方法内部 Catch 异常处理，使最终有返回信息。要么自己内部可以不处理，交由状态机引擎捕获异常，在 json 中定义 Catch 属性。 而不是补偿节点能够自动触发补偿，需要补偿必须手动在 json，由 Catch 或者 Choices 属性路由到 CompensationTrigger。\n A：对的，这个是为了提高灵活性。用户可以自己控制是否进行回滚，因为并不是所有异常都要回滚，可能有一些自定义处理手段。\n 所以 Catch 和 Choices 可以随便路由到想要的 state 对吧？\n A：是的。这种自定义出发补偿的设计是参考了 bpmn2.0 的。\n 还有关于 json 文件，我打算一条流程，就定义一个 json，虽然有的流程很像，用 Choices，可以解决。但是感觉 json 还是要尽量简单。这样考虑对吗？\n A：你可以考虑用子状态机来复用，子状态机会多生成一行 stateMachineInstance 记录，但对性能影响应该不大。\nService Mesh 相关阅读 从网络接入层到 Service Mesh，蚂蚁金服网络代理的演进之路\n 诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录\n Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录\n 蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录\n Service Mesh 发展趋势：云原生中流砥柱\n 企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录\n 蚂蚁金服Service Mesh新型网络代理的思考与实践 | GIAC 分享实录\n 蚂蚁金服 Service Mesh 渐进式迁移方案|Service Mesh Meetup 实录\n 蚂蚁金服 Service Mesh 实践探索 | Qcon 实录\n 干货 | 蚂蚁金服是如何实现经典服务化架构往 Service Mesh 方向的演进的？\n 活动推荐 2019年度TOP100全球软件案例研究峰会即将举行，蚂蚁金服也受邀参与本次案例分享。\nService Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。RPC、消息、DB、安全、运维等每一个环节均充满挑战。本次实战分享蚂蚁金服双十一核心应用如何大规模落地 Service Mesh 架构并降低大促成本。\n主题：《蚂蚁金服 Service Mesh 双十一实战》\n嘉宾：石建伟，花名：卓与，蚂蚁金服中间件技术专家，主要负责蚂蚁金服服务注册中心、配置中心与 Service Mesh 的研发与架构。当前专注在蚂蚁金服 Service Mesh 内部落地。\n时间：2019年11月15日（周五）16:50-17:50\n地点：北京国际会议中心\n报名方式：点击“这里”即可锁定席位\n","date":1573196400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191108/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4615f39bbae97f3f8b4b1705fcbc5d2f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191108/","publishdate":"2019-11-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191108/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/04 - 11/08】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191108/","wordcount":1255},{"author":"涵畅","categories":"Service mesh","content":" 本文作者：肖涵（涵畅）\n上篇文章《诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录》中，介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，帮助大家了解 Service Mesh 未来发展方向和前景。蚂蚁金服持续在进行 Service Mesh 布道和交流。本文内容整理自 10 月 26 日 Service Mesh Meetup#7 成都站主题演讲，现场视频以及分享 PPT 获取方式见文章底部。\n从网络硬件设备到自研平台，从传统服务治理到 Service Mesh，本文将介绍蚂蚁金服网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑起秒级百万支付，千万春晚咻一咻的。\n前言 在云计算和 SDN 下，我们经常听到流量的东西南北向概念，简单来说从外部 Internet 等到数据中心内部的流量走向被称为南北流量，数据中心内部的 VM 之间的流量被称为东西流量。\n当我们追踪南北向的网络流，请求通常会经过四层负载均衡，七层负载均衡等，这通常被我们称为网络接入层代理。当数据中心内部主动访问公网时候，流量通常也会经过 NAT 网关等做网络地址的转换，这也被我们称为网络代理。当我们把视角转向数据中心内部，网络代理的存在感似乎不是那么强，随着 SOA 的发展我们形成了各种成熟的服务通信框架，例如蚂蚁金服的 SOFAStack，阿里集团的 HSF，Google 的 gRPC 等等，网络代理功能被集成进了各种通信框架中，似乎已经 Proxyless 化了，但是随着微服务以及 Service Mesh 的架构提出，东西向的网络代理以独立的姿态又出现了。\n本文将围绕蚂蚁金服近十年网络代理的变迁，揭示整个蚂蚁金服接入层网络以及 Service Mesh 的演进过程，同时带来我们的思考。\n旧瓶新装 我们先来看看业界情况，传统四层负载均衡的代表产品当然是 IPVS，百度阿里等公司早年均对 IPVS 做了非常深度的定制功能，支撑了早期业务的飞速发展。接着也有 DPDK(阿里云 SLB)，类 DPDK 技术的代表 Google 的 Maglev 以及 eBPF 技术的代表 Facebook 的 Katran 出现。\n七层网络代理各个大厂均有产品代表，Google 的 GFE、百度 的 BFE、腾讯 的 TGW，阿里经济体内部也因为场景等原因有众多，例如手淘的 Aserver，集团 web 统一接入 Tengine，当然还有蚂蚁金服的 Spanner（后面会详细介绍）。同时随着 Service Mesh 概念的提出和技术的逐渐成熟，Mesh 中 Sidecar 角色的网络代理也像雨后春笋一样多了起来，包括蚂蚁金服的 SOFAMosn，Istio 社区方案的 Envoy 以及 Rust 编写的 Linkerd，当然 Service Mesh 场景的网络代理和网络接入层的代理我认为没有本质的差别，随着云原生的深入化，大家终将会形成合力并保持一致的形态。\n上图是2019年 Gartner Networking 方向的曲线，可以看到在上升和爆发区有着非常多的网络代理的影子（Secure Access Service Edge，Service Mesh，Edge Networking，Firewall as a Service etc.），虽然网络代理是一项古老的技术以及产品形态，但是仍然随着基础设施以及业务的变化以新的能力和角色展现在世人眼前。\n网络代理的十年 网络代理技术一直围绕“高效接入，访问加速，稳定高可用，安全合规”四个关键词，不断升级核心能力，架构以及运维能力，底层基础网络物理带宽从1G到10G、25G、100G；阿里骨干广域网络走出杭州扩展到全国、全球规模，不断地通过前瞻技术架构研发，技术自主能力的提升和转变，助力业务发展。\n蚂蚁金服应用网络架构概览 产品理念 我们应该以什么样的业务设计来满足上层业务以及市场的需要？产品理念决定了产品的走向，我们设定了网络产品的核心理念模型：\n网络产品设计理念\n接入层代理十年变迁 接入层网络代理的十年变迁之路，我们可以总结为三个时代，四个阶段：PC 时代、移动时代和万物互联云原生时代，伴随着这三个时代，我们经历了四个关键路径。\n前世 2010年前蚂蚁金服网络代理是商用设备的时代，包括 F5 的 bigip，Netscaler 等产品，对于商业设备白盒化，大家比较熟知的是去 IOE，其实网络设备走在了更前面。使用商用设备主要有几个问题，厂商的 Lockin，成本以及灵活扩展等问题，所以从2010年蚂蚁金服开始向自主研发演进。\n自主研发 我们同时开启了四七层网络接入的自研之路，四七层网络由于场景的不同，在整个演进路线上也有较大的差异。\n四层负载均衡 四层网络由于不理解业务语义，主要进化路线是伴随着系统技术，硬件技术的变化，围绕提高吞吐，降低延迟的目标而演进。2014年全面使用 DPDK 进行技术重构，将传统基于内核技术的 IPVS 新建，转发指标分别从万级，十万级提高到百万和千万级的每秒包转发。\n同时随着 Ebpf，Xdp 技术的出现，基于内核的高速转发平面产品又横空出世（包括 Facebook 开源的 Katran）打破了 DPDK 技术的垄断，同时可编程交换芯片以及 P4 语言也加入了这一站场，这里不具体讨论每种技术的优劣。\nSpanner Spanner 是蚂蚁金服的统一接入网关，其意为扳手，主要是为蚂蚁金服 SSL 卸载和网络接入提供了白盒化解决方案，承载了蚂蚁金服所有的业务流量，包括支付宝 App，Web，商户等的终端访问。\n金融级三地五中心架构的流量调度\n上图展示了 Spanner 的编年史，在2013年蚂蚁金服上架了自己的逻辑数据中心架构 LDC，同时随着演进支持了目前的蚂蚁金服金融级的三地五中心容灾架构：\n为了支持这套架构，蚂蚁金服的所有基础设施都进行了改造和技术升级，流量调拨能力作为最基础的能力，是一个基本盘，Spanner 通过对请求头的识别以及全站转发规则映射来实现流量调度，支撑并不限于以下场景：\n 机房内随机路由； 蓝绿发布； 容灾： 逻辑机房内容灾； 机房级别； 城市级别； 弹性调度； 压测流量调度； 灰度流量调度； SSL/TLS 实践\n蚂蚁金服作为全集团最早实践 https 全站的 BU，一直围绕着安全，合规，性能的主题进行全站加密体系的建设。\n成本之战\n前面提到2012年 Spanner 全面上线后，我们接入层具备了定制业务逻辑的能力，在2013年很好支撑了 LDC 的上线，同时我们在性能成本方面也有机会去进行持续的提升，同年我们引入 SSL 加速卡软硬件一体解决方案，从现在来看该套方案已经非常成熟了，集团 Tengine，Openssl 都提供了非常方便的接入框架，但是当年这一块还一直处于探索阶段。我们在 Spanner 里做了 Nginx 的 SSL 握手异步化改造，改造了 Openssl 同 Cavium 的 SSL 加速卡进行适配，整套方案在当时的机型上较 CPU 提升了基于 RSA2048 算法的 SSL 握手3倍的性能，同时也对后续各大厂商在这方面的实践产生了指导性意 …","date":1573030800,"description":" 从网络硬件设备到自研平台，从传统服务治理到 Service Mesh，本文将介绍蚂蚁金服网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑起秒级百万支付，千万春晚咻一咻的。","dir":"blog/antfin-service-mesh-network-agents/","fuzzywordcount":7600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b539a4c29754f9e761c2027426566250","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-service-mesh-network-agents/","publishdate":"2019-11-06T17:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/antfin-service-mesh-network-agents/","summary":"本文作者：肖涵（涵畅） 上篇文章《诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录》中，介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，帮助大家了","tags":["Service mesh"],"title":"从网络接入层到 Service Mesh，蚂蚁金服网络代理的演进之路","type":"blog","url":"/sofastack.tech/blog/antfin-service-mesh-network-agents/","wordcount":7507},{"author":"敖小剑","categories":"Service mesh","content":" 2019 年，蚂蚁金服在 Service Mesh 领域继续高歌猛进，进入大规模落地的深水区。本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的演讲，他介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，以及大规模落地时遇到的困难和解决方案，助你了解 Service Mesh 的未来发展方向和前景。\n 前言 大家好，我是敖小剑，来自蚂蚁金服中间件团队，今天带来的主题是“诗和远方：蚂蚁金服 Service Mesh 深度实践”。\n在过去两年，我先后在 QCon 做过两次 Service Mesh 的演讲：\n 2017年，当时 Service Mesh 在国内还属于蛮荒时代，我当时做了一个名为“Service Mesh: 下一代微服务”的演讲，开始在国内布道 Service Mesh 技术； 2018年，做了名为“长路漫漫踏歌而行：蚂蚁金服 Service Mesh 实践探索”的演讲，介绍蚂蚁金服在 Service Mesh 领域的探索性的实践，当时蚂蚁金服刚开始在 Service Mesh 探索。 今天，有幸第三次来到 QCon，给大家带来的依然是蚂蚁金服在 Service Mesh 领域的实践分享。和去年不同的是，今年蚂蚁金服进入了 Service Mesh 落地的深水区，规模巨大，而且即将迎来双十一大促考验。\n 备注：现场做了一个调研，了解听众对 Servicve Mesh 的了解程度，结果不太理想：在此之前对 Service Mesh 有了解的同学目测只有10%多点（肯定不到20%）。Service Mesh 的技术布道，依然任重道远。\n 今天给大家带来的内容主要有三块：\n 蚂蚁金服落地情况介绍：包括大家最关心的双十一落地情况； 大规模落地的困难和挑战：分享一下我们过去一年中在大规模落地上遇到的问题； 是否采用 Service Mesh 的建议：这个问题经常被人问起，所以借这个机会给出一些中肯的建议供大家参考； 蚂蚁金服落地情况介绍 发展历程和落地规模 Service Mesh 技术在蚂蚁金服的落地，先后经历过如下几个阶段：\n 技术预研 阶段：2017年底开始调研并探索 Service Mesh 技术，并确定为未来发展方向； 技术探索 阶段：2018年初开始用 Golang 开发 Sidecar SOFAMosn，年中开源基于 Istio 的 SOFAMesh； 小规模落地 阶段：2018年开始内部落地，第一批场景是替代 Java 语言之外的其他语言的客户端 SDK，之后开始内部小范围试点； 规模落地 阶段：2019年上半年，作为蚂蚁金融级云原生架构升级的主要内容之一，逐渐铺开到蚂蚁金服内部的业务应用，并平稳支撑了618大促； 全面大规模落地 阶段：2019年下半年，在蚂蚁金服内部的业务中全面铺开，落地规模非常庞大，而且准备迎接双十一大促； 目前 ServiceMesh 正在蚂蚁金服内部大面积铺开，我这里给出的数据是前段时间（大概9月中）在云栖大会上公布的数据：应用数百个，容器数量（pod 数）超过10万。当然目前落地的pod数量已经远超过10万，这已经是目前全球最大的 Service Mesh 集群，但这仅仅是一个开始，这个集群的规模后续会继续扩大，明年蚂蚁金服会有更多的应用迁移到 Service Mesh。\n主要落地场景 目前 Service Mesh 在蚂蚁金服内部大量落地，包括支付宝的部分核心链路，落地的主要场景有：\n 多语言支持：目前除了支持 Java 之外，还支持 Golang，Python，C++，NodeJS 等语言的相互通信和服务治理； 应用无感知的升级：关于这一点我们后面会有特别的说明； 流量控制：经典的 Istio 精准细粒度流量控制； RPC 协议支持：和 Istio 不同，我们内部使用的主要是 RPC 协议； 可观测性； Service Mesh 的实际性能数据 之前和一些朋友、客户交流过，目前在 Service Mesh 方面大家最关心的是 Service Mesh 的性能表现，包括对于这次蚂蚁金服 Service Mesh 上双十一，大家最想看到的也是性能指标。\n为什么大家对性能这么关注？\n因为在 Service Mesh 工作原理的各种介绍中，都会提到 Service Mesh 是将原来的一次远程调用，改为走 Sidecar（而且像 Istio 是客户端和服务器端两次 Sidecar，如上图所示），这样一次远程调用就会变成三次远程调用，对性能的担忧也就自然而然的产生了：一次远程调用变三次远程调用，性能会下降多少？延迟会增加多少？\n下图是我们内部的大促压测数据，对比带 SOFAMosn 和不带 SOFAMosn 的情况（实现相同的功能）。其中 SOFAMosn 是我们蚂蚁金服自行开发的基于 Golang 的 Sidecar/数据平面，我们用它替代了 Envoy，在去年的演讲中我有做过详细的介绍。\nSOFAMosn：https://github.com/sofastack/sofa-mosn\n CPU：CPU 使用在峰值情况下增加8%，均值约增加2%。在最新的一次压测中，CPU 已经优化到基本持平（低于1%）； 内存：带 SOFAMosn 的节点比不带 SOFAMosn 的节点内存占用平均多 15M； 延迟：延迟增加平均约0.2ms。部分场景带 SOFAMosn 比不带 SOFAMosn RT 增加约5%，但是有部分特殊场景带 SOFAMosn 比不带 SOFAMosn RT 反而降低7.5%； 这个性能表现，和前面\u0026amp;rdquo;一次远程调用变三次远程调用\u0026amp;rdquo;的背景和担忧相比有很大的反差。尤其是上面延迟的这个特殊场景，居然出现带 SOFAMosn（三次远程调用）比不带 SOFAMosn（一次远程调用） 延迟反而降低的情况。\n是不是感觉不科学？\nService Mesh 的基本思路 我们来快速回顾一下 Service Mesh 实现的基本思路：\n在基于 SDK 的方案中，应用既有业务逻辑，也有各种非业务功能。虽然通过 SDK 实现了代码重用，但是在部署时，这些功能还是混合在一个进程内的。\n在 Service Mesh 中，我们将 SDK 客户端的功能从应用中剥离出来，拆解为独立进程，以 Sidecar 的模式部署，让业务进程专注于业务逻辑：\n 业务进程：专注业务实现，无需感知 Mesh； Sidecar 进程：专注服务间通讯和相关能力，与业务逻辑无关； 我们称之为\u0026amp;rdquo;关注点分离\u0026amp;ldquo;：业务开发团队可以专注于业务逻辑，而底层的中间件团队（或者基础设施团队）可以专注于业务逻辑之外的各种通用功能。\n通过 Sidecar 拆分为两个独立进程之后，业务应用和 Sidecar 就可以实现“独立维护”：我们可以单独更新/升级业务应用或者 Sidecar。\n性能数据背后的情景分析 我们回到前面的蚂蚁金服 Service Mesh 落地后的性能对比数据：从原理上说，Sidecar 拆分之后，原来 SDK 中的各种功能只是拆分到 Sidecar 中。整体上并没有增减，因 …","date":1572922800,"description":" 本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的演讲。","dir":"blog/service-mesh-antfin-deep-practice-qcon/","fuzzywordcount":12500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"561edcf88763b36e72894da214d2b123","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","publishdate":"2019-11-05T11:00:00+08:00","readingtime":25,"relpermalink":"/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","summary":"2019 年，蚂蚁金服在 Service Mesh 领域继续高歌猛进，进入大规模落地的深水区。本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的","tags":["Service mesh"],"title":"诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","wordcount":12438},{"author":"屹远","categories":"Seata","content":" Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的 Saga 模式。 项目地址：https://github.com/seata/seata\n本文作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。\n金融分布式应用开发的痛点 分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。\u0026amp;mdash;《左耳听风-弹力设计之“补偿事务”》\n而在金融领域微服务架构下的业务流程往往会更复杂，流程很长，比如一个互联网微贷业务流程调十几个服务很正常，再加上异常处理的流程那就更复杂了，做过金融业务开发的同学会很有体感。\n所以在金融分布式应用开发过程中我们面临一些痛点：\n 业务一致性难以保障 我们接触到的大多数业务（比如在渠道层、产品层、集成层的系统），为了保障业务最终一致性，往往会采用“补偿”的方式来做，如果没有一个协调器来支持，开发难度是比较大的，每一步都要在 catch 里去处理前面所有的“回滚”操作，这将会形成“箭头形”的代码，可读性及维护性差。或者重试异常的操作，如果重试不成功可能要转异步重试，甚至最后转人工处理。这些都给开发人员带来极大的负担，开发效率低，且容易出错。\n 业务状态难以管理 业务实体很多、实体的状态也很多，往往做完一个业务活动后就将实体的状态更新到了数据库里，没有一个状态机来管理整个状态的变迁过程，不直观，容易出错，造成业务进入一个不正确的状态。\n 幂等性难以保障 服务的幂等性是分布式环境下的基本要求，为了保证服务的幂等性往往需要服务开发者逐个去设计，有用数据库唯一键实现的，有用分布式缓存实现的，没有一个统一的方案，开发人员负担大，也容易遗漏，从而造成资损。\n 业务监控运维难，缺乏统一的差错守护能力 业务的执行情况监控一般通过打印日志，再基于日志监控平台查看，大多数情况是没有问题的，但是如果业务出错，这些监控缺乏当时的业务上下文，对排查问题不友好，往往需要再去数据库里查。同时日志的打印也依赖于开发，容易遗漏。对于补偿事务往往需要有“差错守护触发补偿”、“工人触发补偿”操作，没有统一的差错守护和处理规范，这些都要开发者逐个开发，负担沉重。\n理论基础 一些场景下，我们对数据有强一致性的需求时，会采用在业务层上需要使用“两阶段提交”这样的分布式事务方案。而在另外一些场景下，我们并不需要这么强的一致性，那就只需要保证最终一致性就可以了。\n例如蚂蚁金服目前在金融核心系统使用的就是 TCC 模式，金融核心系统的特点是一致性要求高（业务上的隔离性）、短流程、并发高。\n而在很多金融核心以上的业务（比如在渠道层、产品层、集成层的系统），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务（如金融网络）。这是如果每个服务都开发 Try、Confirm、Cancel 三个方法成本高。如果事务中有其它公司的服务，也无法要求其它公司的服务也遵循 TCC 这种开发模式。同时流程长，事务边界太长会影响性能。\n对于事务我们都知道 ACID，也很熟悉 CAP 理论最多只能满足其中两个，所以，为了提高性能，出现了 ACID 的一个变种 BASE。ACID 强调的是一致性（CAP 中的 C），而 BASE 强调的是可用性（CAP 中的 A）。我们知道，在很多情况下，我们是无法做到强一致性的 ACID 的。特别是我们需要跨多个系统的时候，而且这些系统还不是由一个公司所提供的。BASE 的系统倾向于设计出更加有弹力的系统，在短时间内，就算是有数据不同步的风险，我们也应该允许新的交易可以发生，而后面我们在业务上将可能出现问题的事务通过补偿的方式处理掉，以保证最终的一致性。\n所以我们在实际开发中会进行取舍，对于更多的金融核心以上的业务系统可以采用补偿事务，补偿事务处理方面在30年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较也公认 Saga 是作为长事务的解决方案。 \u0026amp;gt; https://github.com/aphyr/dist-sagas/blob/master/sagas.pdf \u0026amp;gt; http://microservices.io/patterns/data/saga.html\n社区和业界的方案 Apache Camel Saga Camel 是实现 EIP（Enterprise Integration Patterns）企业集成模式的一款开源产品，它基于事件驱动的架构，有着良好的性能和吞吐量，它在2.21版本新增加了 Saga EIP。\nSaga EIP 提供了一种方式可以通过 camel route 定义一系列有关联关系的 Action，这些 Action 要么都执行成功，要么都回滚，Saga 可以协调任何通讯协议的分布式服务或本地服务，并达到全局的最终一致性。Saga 不要求整个处理在短时间内完成，因为它不占用任何数据库锁，它可以支持需要长时间处理的请求，从几秒到几天，Camel 的 Saga EIP 是基于 Microprofile 的 LRA（Long Running Action），同样也是支持协调任何通讯协议任何语言实现的分布式服务。\nSaga 的实现不会对数据进行加锁，而是在给操作定义它的“补偿操作”，当正常流程执行出错的时候触发那些已经执行过的操作的“补偿操作”，将流程回滚掉。“补偿操作”可以在 Camel route 上用 Java 或 XML DSL（Definition Specific Language）来定义。\n下面是一个 Java DSL 示例：\n// action from(\u0026amp;quot;direct:reserveCredit\u0026amp;quot;) .bean(idService, \u0026amp;quot;generateCustomId\u0026amp;quot;) // generate a custom Id and set it in the body .to(\u0026amp;quot;direct:creditReservation\u0026amp;quot;) // delegate action from(\u0026amp;quot;direct:creditReservation\u0026amp;quot;) .saga() .propagation(SagaPropagation.SUPPORTS) .option(\u0026amp;quot;CreditId\u0026amp;quot;, body()) // mark the current body as needed in the compensating action .compensation(\u0026amp;quot;direct:creditRefund\u0026amp;quot;) .bean(creditService, \u0026amp;quot;reserveCredit\u0026amp;quot;) .log(\u0026amp;quot;Credit ${header.amount} …","date":1572861600,"description":" 一起来解读 Seata Saga 模式到底解决了什么问题。","dir":"blog/seata-saga-flexible-financial-applications/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9c17449b81e0f1fe51d46bbaeaaa5516","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-saga-flexible-financial-applications/","publishdate":"2019-11-04T18:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/seata-saga-flexible-financial-applications/","summary":"Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的","tags":["Seata"],"title":"基于 Seata Saga 设计更有弹性的金融应用","type":"blog","url":"/sofastack.tech/blog/seata-saga-flexible-financial-applications/","wordcount":6384},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@罗健 提问： \u0026amp;gt; SOFAJRaft 跨机房支持吗？\nA： 跨机房不需要特殊支持，只是网络延时大一点而已。\n 延时大了，读写性能就会降低了吧？ 像 ZooKeeper 一样。\n A：1. SOFAJRaft 支持 transfer leader，把 leader transfer 到和业务就近的机房（目前需要手动调用 cli 服务）； 2. SOFAJRaft 1.3.0 会增加一个选举优先级特性，可以将指定机房节点优先级调高，尽量保证 leader 在指定机房。 SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@阮仁照 提问： \u0026amp;gt; SOFAArk 在打多个 ark-biz 包时，如果有多个 biz 包之间互相调用，默认是会走 injvm 协议的，这是如何做到的。我看了 SOFABoot 那块对 injvm 的支持，是通过 sofaRuntimeContext 来查找实现类，sofaRuntimeContext 是被 spring 容器管理的 bean，这就要求多个 biz 包之间是共用一套 spring 环境（或者说有个统一的父容器），是这样的吗？还是有什么其他实现的思路？\nA：可以看下 com.alipay.sofa.runtime.invoke.DynamicJvmServiceProxyFinder 这个类。\n 懂了，原来在这之上还有个 SofaFramework维护一个静态变量，真巧妙，用这个来解决多个 spring 容器里的 rpc 调用问题吗？\n A：多个 spring 容器之间的调用，不是 rpc 调用，是进程内调用。\n 对的， 这里不是 rpc 调用了， 所以这里也是 filter 会失效的原因。这样的话，那 SofaFramework 这个类就要被所有子容器都共享才对，但是我看打出来的 executable-ark 包，并没有在 classpath 下加载这个类啊，子容器咋共享的？\n A：这个会打包成一个插件，放在 ark plugin 层。 既然说插件之间是隔离的，那你把 SofaFramework 打在插件里，别的 biz 包启动时从会从 plugin里拿一个 SofaFramework ，互相不可见，这不是有问题吗？\n A：不同 biz 会共享同一个。 SOFAArk：https://github.com/sofastack/sofa-ark\n3、@温明磊 提问： \u0026amp;gt; Seata 的 Saga 模式的 json 文件，支持热部署吗？\nA：支持，stateMachineEngine.getStateMachineConfig().getStateMachineRepository().registryByResources()。不过 Java 代码和服务需要自己实现支持热部署。\n Seata 服务部署集群是需要怎么配置? 还是现在不支持\n A：异步执行一个服务，已实现。https://github.com/seata/seata/issues/1843\n Saga 的参数是不是只能在状态机启动时定义。如果第二个服务，依赖第一个服务返回的信息，或者里面组装好的信息怎么办？\n A：有个 Output 参数定义，可以把服务返回的参数映射到状态机上下文，然后在下一个服务的 Input 里定义参数引用。\n 异步执行服务的话，需要在 file 加上这个配置吗? A：这个是状态机定义的 Json 文件，不是 Seata 的客户端配置文件。 Seata：https://github.com/seata/seata\n本周推荐阅读 备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？\n K8s 1.14 发布了，Release Note 该怎么读？\n SOFA 项目进展 本周发布详情如下：\n发布 SOFAMosn v0.8.0，主要变更如下： i. 内存占用优化，优化在连接数、并发数较多的场景下的内存占用 ii. Metrics 统计优化，RPC 心跳场景不计入 QPS 等 Metrics 统计 iii. XDS 处理优化，修改为完全无阻塞启动，并且降低了重试的频率 详细发布报告，请见： https://github.com/sofastack/sofa-mosn/releases/tag/0.8.0\n","date":1572591600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191101/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cd5f758d6d5d28784524b55169ae0a98","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191101/","publishdate":"2019-11-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191101/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/28 - 11/01】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191101/","wordcount":1512},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:ArkLab/\u0026amp;gt;是《剖析 | SOFAArk 源码》系列，会逐步详细介绍 SOFAArk 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFAArk SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力。在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\nSOFAArk :https://github.com/sofastack/sofa-ark\n|\u0026amp;lt; SOFA:ArkLab/\u0026amp;gt; 认领列表：\n 【已完成】轻量级类隔离框架 SOFAArk 简介 【已认领】 SOFAArk 容器模型解析 【已认领】 SOFAArk 类加载模型机制解析 【已认领】 SOFAArk 合并部署能力解析 【已认领】 SOFAArk SPI 机制和 ClassLoaderHook 机制解析 【已认领】 SOFAArk 动态配置机制解析 【已认领】 SOFAArk maven 打包插件解析 【已认领】 （实践）SOFAArk 插件化机制解析与实践 领取方式：关注「金融级分布式架构」 回复可领取的文章标题，我们将会主动联系你，确认资质后，即可加入 SOFA:ArkLab/，It\u0026amp;rsquo;s your show time！\n 如果有同学对以上某个主题特别感兴趣的，可以留言讨论，我们会适当根据大家的反馈调整文章的顺序，谢谢大家关注 SOFAStack ，关注 SOFAArk，我们会一直与大家一起成长的。\n除了源码解析，也欢迎提交 issue 和 PR： SOFAArk :https://github.com/sofastack/sofa-ark\n欢迎领取，参与共建~\n","date":1572408000,"description":"欢迎参与 SOFAArk 源码解析系列文章共建。","dir":"activities/sofa-ark-lab/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"02869baa65a4730cea247cf1763d920c","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-ark-lab/","publishdate":"2019-10-30T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-ark-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:ArkLab/\u0026gt;是《剖析 | SOFAArk 源码》系列，会逐步详细介","tags":["SOFALab","SOFAArk","剖析 | SOFAArk 源码"],"title":"\u003cSOFA:ArkLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-ark-lab/","wordcount":572},{"author":"沧漠","categories":"Kubernetes","content":" 本文 PPT 下载\n导读：Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统，它大幅降低了容器化应用部署的门槛，但运维和管理一个生产级的高可用 Kubernetes 集群仍十分困难。本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。\nKubernetes 以其超前的设计理念和优秀的技术架构，在容器编排领域拔得头筹。越来越多的公司开始在生产环境部署实践 Kubernetes，在阿里巴巴和蚂蚁金服 Kubernetes 已被大规模用于生产环境。\n系统概览 Kubernetes 集群管理系统需要具备便捷的集群生命周期管理能力，完成集群的创建、升级和工作节点的管理。在大规模场景下，集群变更的可控性直接关系到集群的稳定性，因此管理系统可监控、可灰度、可回滚的能力是系统设计的重点之一。除此之外，超大规模集群中，节点数量已经达到 10K 量级，节点硬件故障、组件异常等问题会常态出现。面向大规模集群的管理系统在设计之初就需要充分考虑这些异常场景，并能够从这些异常场景中自恢复。\n设计模式 基于这些背景，我们设计了一个面向终态的集群管理系统。系统定时检测集群当前状态，判断是否与目标状态一致，出现不一致时，Operators 会发起一系列操作，驱动集群达到目标状态。这一设计参考控制理论中常见的负反馈闭环控制系统，系统实现闭环，可以有效抵御系统外部的干扰，在我们的场景下，干扰对应于节点软硬件故障。\n架构设计 如上图，元集群是一个高可用的 Kubernetes 集群，用于管理 N 个业务集群的 Master 节点。业务集群是一个服务生产业务的 Kubernetes 集群。SigmaBoss 是集群管理入口，为用户提供便捷的交互界面和可控的变更流程。元集群中部署的 Cluster-Operator 提供了业务集群集群创建、删除和升级能力，Cluster-Operator 面向终态设计，当业务集群 Master 节点或组件异常时，会自动隔离并进行修复，以保证业务集群 Master 节点达到稳定的终态。这种采用 Kubernetes 管理 Kubernetes 的方案，我们称作 Kube on Kube 方案，简称 KOK 方案。业务集群中部署有 Machine-Operator 和节点故障自愈组件用于管理业务集群的工作节点，提供节点新增、删除、升级和故障处理能力。在 Machine-Operator 提供的单节点终态保持的能力上，SigmaBoss 上构建了集群维度灰度变更和回滚能力。\n核心组件 集群终态保持器 基于 K8s CRD，在元集群中定义了 Cluster CRD 来描述业务集群终态，每个业务集群对应一个 Cluster 资源，创建、删除、更新 Cluster 资源对应于实现业务集群创建、删除和升级。Cluster-Operator watch Cluster 资源，驱动业务集群 Master 组件达到 Cluster 资源描述的终态。业务集群 Master 组件版本集中维护在 ClusterPackageVersion CRD 中，ClusterPackageVersion 资源记录了 Master 组件（如：api-server、controller-manager、scheduler、operators 等）的镜像、默认启动参数等信息。Cluster 资源唯一关联一个 ClusterPackageVersion，修改 Cluster CRD 中记录的 ClusterPackageVersion 版本即可完成业务集群 Master 组件发布和回滚。\n节点终态保持器 Kubernetes 集群工作节点的管理任务主要有：\n 节点系统配置、内核补丁管理； docker / kubelet 等组件安装、升级、卸载； 节点终态和可调度状态管理（如关键 DaemonSet 部署完成后才允许开启调度）； 节点故障自愈。 为实现上述管理任务，在业务集群中定义了 Machine CRD 来描述工作节点终态，每一个工作节点对应一个 Machine 资源，通过修改 Machine 资源来管理工作节点。\nMachine CRD 定义如下图所示，spec 中描述了节点需要安装的组件名和版本，status 中记录有当前这个工作节点各组件安装运行状态。除此之外，Machine CRD 还提供了插件式终态管理能力，用于与其它节点管理 Operators 协作，这部分会在后文详细介绍。\n工作节点上的组件版本管理由 MachinePackageVersion CRD 完成。MachinePackageVersion 维护了每个组件的 rpm 版本、配置和安装方法等信息。一个 Machine 资源会关联 N 个不同的 MachinePackageVersion，用来实现安装多个组件。\n在 Machine、MachinePackageVersion CRD 基础上，设计实现了节点终态控制器 Machine-Operator。Machine-Operator watch Machine 资源，解析 MachinePackageVersion，在节点上执行运维操作来驱动节点达到终态，并持续守护终态。\n节点终态管理 随着业务诉求的变化，节点管理已不再局限于安装 docker / kubelet 等组件，我们需要实现如等待日志采集 DaemonSet 部署完成才可以开启调度的需求，而且这类需求变得越来越多。如果将终态统一交由 Machine-Operator 管理，势必会增加 Machine-Operator 与其它组件的耦合性，而且系统的扩展性会受到影响。因此，我们设计了一套节点终态管理的机制，来协调 Machine-Operator 和其它节点运维 Operators。设计如下图所示：\n 全量 ReadinessGates: 记录节点可调度需要检查的 Condition 列表； Condition ConfigMap: 各节点运维 Operators 终态状态上报 ConfigMap； 协作关系：\n 外部节点运维 Operators 检测并上报与自己相关的子终态数据至对应的 Condition ConfigMap； Machine-Operator 根据标签获取节点相关的所有子终态 Condition ConfigMap，并同步至 Machine status 的 conditions 中； Machine-Operator 根据全量 ReadinessGates 中记录的 Condition 列表，检查节点是否达到终态，未达到终态的节点不开启调度。 节点故障自愈 我们都知道物理机硬件存在一定的故障概率，随着集群节点规模的增加，集群中会常态出现故障节点，如果不及时修复上线，这部分物理机的资源将会被闲置。\n为解决这一问题，我们设计了一套故障发现、隔离、修复的闭环自愈系统。\n如下图所示，故障发现方面，采取 Agent 上报和监控系统主动探测相结合的方式，保证了故障发现的实时性和可靠性（Agent 上报实时性比较好，监控系统主动探测可以覆盖 Agent 异常未上 …","date":1572246000,"description":"本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。","dir":"blog/ant-financial-managing-large-scale-kubernetes-clusters/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0fbce82d736863f9039c6a8f15c6f5d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","publishdate":"2019-10-28T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","summary":"本文 PPT 下载 导读：Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统，它大幅降低了容器化应用部署的门槛，但运维和管理一个生产级","tags":["Kubernetes"],"title":"备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？","type":"blog","url":"/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","wordcount":4899},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@罗健 提问：\n 请问，SOFAJRaft 跨机房支持吗？\n A：跨机房不需要特殊支持，只是网络延时大一点而已。\n 延时大了，读写性能就会降低了吧？ 像 ZooKeeper 一样。\n A：1. SOFAJRaft 支持 transfer leader，把 leader transfer 到和业务就近的机房（目前需要手动调用 cli 服务） 2. SOFAJRaft 1.3.0 会增加一个选举优先级特性，可以将指定机房节点优先级调高，尽量保证 leader 在指定机房。\n2、@梁开心 提问：\n 使用 Seata 的时候，现在是 AT 模式 如果改成 Saga 模式的话，改造会大吗？\n A：AT 模式完全是透明的，Saga 是有侵入性的，要配置状态机 json，如果服务多改造会比较大。\n Saga 模式是不是基于 AT 来加强的长事务处理呢？\n A：没有基于 AT，客户端完全是两套，Server 端是复用的。你也可以看 Saga 的单元测试，那里有很多示例：https://github.com/seata/seata/tree/develop/test/src/test/java/io/seata/saga/engine\n Saga 服务流程可以不配置吗，使用全局事务 id 串起来，这样省去配置的工作量，再加上人工配置难免会配置错误。\n A：Saga 一般有两种实现，一种是基于状态机定义，比如 apache camel saga、eventuate，一种是基于注解+拦截器实现，比如 service comb saga，后者是不需要配置状态图的。由于 Saga 事务不保证隔离性, 在极端情况下可能由于脏写无法完成回滚操作, 比如举一个极端的例子, 分布式事务内先给用户 A 充值, 然后给用户B扣减余额, 如果在给 A 用户充值成功, 在事务提交以前, A 用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了，有些业务场景可以允许让业务最终成功, 在回滚不了的情况下可以继续重试完成后面的流程, 基于状态机引擎除可以提供“回滚”能力外, 还可以提供“向前”恢复上下文继续执行的能力, 让业务最终执行成功, 达到最终一致性的目的，所以在实际生产中基于状态机的实现应用更多。后续也会提供基于注解+拦截器实现。\n3、@温明磊 提问：\n 关于 Saga 的使用，有两个问题咨询下 1、比如有服务 A 在系统1里面，服务 B 在系统2里面。全局事务由 A 开启，流程调用 B 开启子事务，那系统2也需要维护 Saga 状态机的三个表吗，也需要在 Spring Bean 配置文件中配置一个 StateMachineEngine 吗？\n2、如果 系统1和系统2里面的服务，可以相互调用。系统12都可以开启全局事务，可以这样使用吗。那1和2 都需要维护Saga状态机的三个表，也需要在Spring Bean配置文件中配置一个StateMachineEngine。\n A：1、不需要，只在发起方记录日志。由于只在发起方记录日志同时对参与者服务没有接口参数的要求，使得Saga可以方便集成其它机构或遗留系统的服务。 2、可以这样使用，如果两个系统都开启 Saga 事务，那就要记录那三个表配置 StateMachineEngine。\n 这个 EventQueue 只是开启分布式事务的系统 来进行事件驱动，调用其它系统服务像调用本地一样。系统之间还是 RPC 调用是吧，而不是系统之前也是纯事件驱动的？ A：是的。你指的\u0026amp;rdquo;系统之间也是纯事件驱动的\u0026amp;rdquo; 是不是说 RPC 也是非阻塞的？\n 是的，也可以是异步的。\n A：那 RPC 的非阻塞需要 rpc client 支持，理论上也是可以的。rpc client 如果也是非阻塞 IO，那么所有环节都是异步了。\n 就是考虑一个业务流程， 它后续的子流程， 不管谁先运行都不会相互影响，可以异步调用。子流程是其它系统服务。Seata Saga 是不是实现了这点，其实我没看明白 ，Seata Saga 异步调用具体是不是各个节点异步了。是不是两个 ServiceTask 类型，可以同时 process ？\n A：你说的是并发节点类型，还未实现，接下来会实现。目前的事件驱动是指的节点的执行是事件驱动的，流程的顺序是同步的。上一个节点执行完成后，产生事件，触发下一个节点执行。如果要满足你刚说的需求要扩展并发节点。\n 那目前区分同步 BUS 和异步 BUS 是什么作用？\n A：同步 BUS 是线程阻塞的，等整个状态机执行完毕才返回，异步 BUS 是非线程阻塞的，调用后立即返回，状态机执行完毕后回调你的 Callback。\n IsPersist: 执行日志是否进行存储，默认是 true，有一些查询类的服务可以配置在 false，执行日志不进行存储提高性能，因为当异常恢复时可以重复执行？\n A：是的，可以配置成 false, 不过建议先保持默认，这样在查询执行日志比较全，真的要做性能调优再配，一般不会有性能问题。\n每周推荐阅读 蚂蚁金服开源背后的“有意思”工程师 | 1024快乐 蚂蚁金服云原生专家招聘 | 1024有你更快乐 SOFA 项目进展 本周发布详情如下：\n1、Occlum 是一个多任务、内存安全的库操作系统，专门针对可信执行环境（如 Intel SGX）。\n发布 Occlum v0.6.0，主要变更如下： i. 支持 release 模式运行 enclave，轻松发布基于 Occlum 的 SGX 应用； ii. 给 SEFS 增加额外的 MAC 和权限检查，保证 Occlum 的 FS 镜像的完整性； iii. 重构底层错误处理机制，使得报错对用户友好，且附带详细的调试信息； iv. 增加3个新 demo，包括 Bazel、HTTPS file server 和 Tensorflow Lite； v. 在 Docker 镜像中默认安装 Occlum，使得用户开箱即用； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.6.0\n2、发布SOFARPC v5.5.9，主要变更如下： …","date":1571986800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191025/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7927ee3392339de5283b8c4e75f9b4e9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191025/","publishdate":"2019-10-25T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191025/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/21 - 10/25】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191025/","wordcount":2571},{"author":"SOFAStack","categories":"1024","content":" !important 希望我们是最早给你祝福的朋友\n去年的1024，我们回顾了第一代到第五代架构 去年的今天，我们和大家分享了 SOFAStack 背后的这群工程师。比如程立，花名鲁肃，蚂蚁金服 CTO。胡喜，蚂蚁金服副总裁、副CTO。杨冰，蚂蚁金服智能科技产品技术部总监。\n也与大家分享了从第一代到第五代架构的进化历程，详解了 SOFAStack 走的这一条跟传统金融行业不同的分布式架构之路。要基于不可靠的硬件系统实现金融级的性能和可靠性，要应对支付宝这样的超大规模互联网金融应用，有很多难题要解决。蚂蚁金服构建了一整套处理金融级交易的分布式架构与平台，在金融级的一致性要求和海量并发处理能力上达到了很好的平衡，并在快速容灾恢复、弹性伸缩能力、多地多活高可用保证能力和按需供给的精细化资源调度能力方面沉淀了丰富的实践经验。\n前往去年此刻的时光机：蚂蚁金服自研架构SOFA背后的工程师|1024快乐\n今年，SOFAStack 团队在忙什么呢？ 近几年来，“云原生架构”的相关话题讨论比较热烈，我们也相信这也将是金融 IT 架构的关键发展趋势之一。IT 架构转型绝不是一蹴而就的，积极探索和应用以“云原生”为代表的新兴技术的同时，还需考虑与传统模式和技术融合并存，沿着一条稳妥的可落地路径进行创新变革，确保架构转型的价值交付能够稳妥支撑甚至积极引领业务创新。\nService Mesh 是蚂蚁金服下一代架构的核心，这一年，我们在奔跑的火车上换轮子，将现有的微服务架构快速演进到云原生架构。RPC、消息、DB、安全、运维等每一个环节均充满挑战。\n蚂蚁金服每年双十一大促会面临非常大的流量挑战，在已有 LDC 微服务架构下已支撑起弹性扩容能力。当有多个大促分阶段进行时，如何在架构上保障资源最大程度复用降低大促成本极具挑战。期望在最小规模的资源集群下可通过灵活的架构来支撑起快速的资源腾挪来达成多个大促链路最大化利用资源的目的。通过 Service Mesh 架构的支持，基础设施层在应用外具备更强的管控能力，通过流量的调拨，JVM 内存的动态 Swap 等手段可以使用技术手段达成节省资源的目的。 今年即将到来的双十一，蚂蚁金服这套 Service Mesh 将迎来第一次大考 — 双十一实战，也或许是业界第一个如此大规模的实战，请持续关注本公众号，我们会逐步进行技术揭秘。\n今天，我们想介绍蚂蚁金服开源背后的这位“有意思”工程师： 对于蚂蚁金服研究员王益而言，2019年是个颇有纪念意义的年份。今年他整40岁。从10岁开始，写代码整30年。这30年来，他当过“不务正业”的学生，创纪录地在大一就考下系统分析员，“单枪匹马”闯荡过从国内到硅谷的多家知名互联网科技公司，和AI领域许多传奇人物都有所交集。不惑之年对于许多工程师来说，或许已是需要焦虑的年龄，但40岁的王益在蚂蚁金服每天都过得很充实：起床，自由泳一千米，然后去做他最喜欢的事——写代码和组织大家一起写代码。\n 2019年9月11日，在上海举办的Google开发者大会上，蚂蚁金服研究员王益分享了新开发的分布式深度学习系统ElasticDL。这是他来到蚂蚁金服的一年之中所做的第二个开源项目，主要用于大幅提升集群总体利用率以及深度学习团队的工作效能。之前开源的 SQLFlow系统在短短的几个月之间，已经在GitHub上获得了三千多颗星星。\n2019对于王益而言是个颇有纪念意义的年份，今年他整40岁，写代码整30年。 这听上去是一件不可思议的事——30年前，上世纪的80年代末，他在⻓沙上小学，全城都很难找出一位能教编程的老师，个人电脑更是一个陌生名词，一台以苹果2为原型、可以用BASIC语言编程的 “中华学习机”售价7000人民币，在当时几乎可以买下一套房子。\n幸运的是，王益在10岁那年得到了这样一件贵重的礼物，从这台学习机和一本BASIC语言教材开始，他开启了与代码结缘的人生。\n“我那时不是个好学生，经常受‘别人家的孩子’打击，老师和同学都觉得写代码是不务正业。”回想起30年来的经历，这位清华博士、足迹从国内到硅谷历经多家知名互联网科技公司的学霸笑谈自己“活得比较任性”，“但我就是想做与众不同的事。别人越说这样不行，我就越想用这种方式证明自己。”\n初中毕业那年的暑假，他用“中华学习机”和自己焊接的电路板，把自家的老式“威力牌”双筒洗衣机改造成了自动洗衣机。同时，他用Apple BASIC语言和6502汇编混合编程，写了人生中第一个游戏。高中三年，其他同学努力备考，他却加班加点自学了大学计算机系所有课程，随后参加计算机水平考试，先后获得了程序员、高级程序员、以及最高级别系统分析员资格。2018年，他获得Google APAC Innovation Award。从不断摸索代码世界的少年时代，到专注于AI基础架构和系统开发的求学工作生涯，这份“任性”一直伴随他走到今天。\n“我经常从零开始。选择去做什么的一大标准是‘有意思’。”\n相比于规划一条稳妥的职业发展道路，王益更愿意顺应自己强烈的好奇心，去选择最困难但最有意思的探索方向。他在中国和美国互联网公司都工作过，也分别在美国公司的中国分部和中国公司的美国分部工作过。他的足迹遍及国内BAT三家。任性的是，每次跳槽， 他都从一个人coding一个创新项目开始，吸引同事们加入，从而组建团队。虽然2011年就在腾讯作为广告系统技术总监，但是他从不在跳槽时要求带何等规模的团队。\n2014年，王益带着妻子和两个月大的女儿离开腾讯移居硅谷。“一切都归零了。工资减半。”他笑笑说。不过凭着多位学界和业界领袖的推荐，他很快就安顿下来，不到一年就开始在硅谷创业，作为Head of Research Scienets 参与创建了AI创业公司 ScaledInference。这是一家人才济济的创业公司。人工智能行业的领袖人物、加州大学伯克利分校的Michael Jordan教授是这家公司顾问。陆奇曾代表微软到访，讨论技术合作。“可惜我们不够关注业务落地，做的不够好。技术研发一定要有落地的能力。”事后，王益不无遗憾的说。\n在加入蚂蚁金服之前，王益在百度硅谷研究院工作，负责开源深度学习系统PaddlePaddle。在历经两年的艰苦开发，新一代技术Fluid开始系统地落地百度各个业务之后，他发起了他在 PaddlePaddle的最后一个子项目——一条太阳能驱动的无人驾驶船。这是一条双体船，由他和五岁女儿的两条划艇构成。船上的笔记本电脑运行基于immitation learning的人工智能系统，自动学习驾驶者的技巧。为了船体稳定，他在自家车库里焊接了连接两条划艇的金属框架。便于拆装的结构，可以装上他的皮卡，方便下水测试。\n做出加入蚂蚁金服的决定，也是出于同样的理由——“有意思”。“这里的业务很新颖，对AI 有着更加多样化的需求。”如何用AI解决金融行业的问题，是和他以往所面对的完全不同的全新挑战。 SQLFlow：分析师与AI模型间的翻译  加入蚂蚁金服不久，王益就意识到自己之前的朦胧猜想越来越清晰地被验证：和主要依靠流量与广告赚钱的传统互联网公司不同，蚂蚁金服不是纯互联网公司，它有独特的商业模式和对于工具的独到需求。\n此前的十多年中，他的大部分经历是在传统互联网 …","date":1571883840,"description":"不管世界如何，永远永远希望开发者能感觉技术“有意思”，永远希望开发者快乐不复杂。","dir":"blog/ant-financial-happy-1024/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c89decd5fb9b75c59f487dc58bac0365","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-happy-1024/","publishdate":"2019-10-24T10:24:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/ant-financial-happy-1024/","summary":"!important 希望我们是最早给你祝福的朋友 去年的1024，我们回顾了第一代到第五代架构 去年的今天，我们和大家分享了 SOFAStack 背后的这群工程师。比如程立，花名鲁肃","tags":["1024"],"title":"蚂蚁金服开源背后的“有意思”工程师 | 1024快乐","type":"blog","url":"/sofastack.tech/blog/ant-financial-happy-1024/","wordcount":5806},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@温明磊 提问： \u0026amp;gt; 最近在选型 Zeebe 还是 Seata Saga 来实现微服务编排。Zeebe 使用了基于行业标准 BPMN 2.0 的可视工作流。 但是考虑到 Seata 的开源和生态，如果 Seata 能实现流程可视就好了。\nA：未来我们会做可视化的也可以社区贡献。另外给一个调研服务编排选型的建议，遵循 bpmn 2.0 行业标准没有问题的，不过 bmpn2.0 xml 格式太复杂了，我们微服务的编排不需要那么多标签，另外微服务的编排里有很重要一块就是要保证编排的服务的事务一致性，所以需有能支持分布式事务的处理能力，这里面就会涉及服务的状态判断定义，异常处理定义，复杂服务参数的映射，这些在 bpmn 2.0 标准里是没有定义的（当然框架可以在扩展节点里自己扩展）。用 json 定义之后，你会发现其实有没有可视化开发工具没有那么重要了，只是如果有个可视化监控更好。\n 是的，json 我们都可以自己组装。只要把业务接口做成可视可配，完全可以用配置信息组装 json。这样说不知道对不对。但是像您说的，有个可视化的工具 肯定要更好点。\n A：是的，json 还有一个好处是，服务调用的参数可以直接在 json 里组织好。\nSOFARegistryLab 系列阅读 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 云原生推荐阅读 云原生时代，什么是蚂蚁金服推荐的金融架构？ 当金融科技遇上云原生，蚂蚁金服是怎么做安全架构的？ SOFA 项目进展 发布 Seata v0.9.0，主要变更如下：\ni. 长事务解决方案: Saga 模式（基于状态机实现） ii. 支持自定义配置和注册中心类型 iii. 支持 spring cloud config 配置中心 iv. 修复对象锁和全局锁可能造成的死锁和优化锁的粒度 v. 修复 oracle 的批量获取问题 vi. 优化了一些基于 java5 的语法结构 vii. 抽象 undologManager 的通用方法\n详细发布报告： https://github.com/seata/seata/releases/tag/v0.9.0\n云原生活动推荐 Service Mesh Meetup 是由蚂蚁金服联合 CNCF 官方共同出品，ServiceMesher 社区主办，主题围绕服务网格、Kubernetes 及云原生，在全国各地循环举办的技术沙龙。\n本期 Meetup 邀请社区大咖，从服务网格下微服务架构设计、在 5G 时代的应用、如何使用开源的 Traefik 构建云原生边缘路由及蚂蚁金服的服务网格代理演进角度给大家带来精彩分享。\n时间：2019年10月26日（周六）13:00-17:0 0地点：成都武侯区蚂蚁C空间 报名方式：点击这里，即可锁定席位\n","date":1571382000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191018/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"91ccf1c351bfb03d7e18f70fad5f5224","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191018/","publishdate":"2019-10-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191018/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/14 - 10/18】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191018/","wordcount":1198},{"author":"力鲲","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第五篇，本篇作者力鲲，来自蚂蚁金服。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n回顾：服务注册 SOFARegistry 作为服务注册中心，面临的一个很重要的挑战就是如何解决海量的客户端连接问题，这也是本文要剖析的内容。不过作为一篇完整的文章，我们还是会先花一点时间介绍 SOFARegistry 的相关信息，以便读者了解其背景。\n服务注册中心在服务调用的场景中，扮演一个“中介”的角色，服务发布者 (Publisher) 将服务发布到服务注册中心，服务调用方 (Subscriber) 通过访问服务注册中心就能够获取到服务信息，进而实现调用。\n图1 - 服务的“中介”\n流程：订阅 / 发布 在《海量数据下的注册中心 - SOFARegistry 架构介绍》一文中，我们提到了一个典型的 “RPC 调用的服务寻址” 应用场景，服务的提供方通过如下两个步骤完成服务发布：\n 注册，将自己以 Publisher 的角色注册到 SOFARegistry； 发布，将需要发布的数据 (通常是IP 地址、端口、调用方式等) 发布到 SOFARegistry； 与此相对应的，服务的调用方通过如下步骤实现服务调用：\n 注册，将自己以 Subscriber 的角色注册到 SOFARegistry； 订阅，收到 SOFARegistry 推送的服务数据； 从上面我们可以看到，整个流程中很重要的一个步骤就是注册，不管是 Publisher 还是 Subscriber 都只能在注册成功后才能实现发布订阅的需求。因此 SOFARegistry 要解决的一个问题就是如何维护与 Client 连接而产生的 Session，尤其是当 Client 数量众多的时候。\n图2 - 海量啊海量\n设计：分层隔离 在 SOFARegistry 的应用场景中，体量庞大的数据主要有两类：Session 数据、服务信息数据。两类数据的相同之处在于其数据量都会不断扩展，而不同的是其扩展的原因并不相同：Session 是对应于 Client 的连接，其数据量是随着业务机器规模的扩展而增长，而服务信息数据量的增长是由 Publisher 的发布所决定。所以 SOFARegistry 通过分层设计，将两种数据隔离，从而使二者的扩容互不影响。\n图3 - 分层，扩容互不影响\n当然，对于分层设计的概念介绍，在《海量数据下的注册中心 - SOFARegistry 架构介绍》的 “如何支持海量客户端” 章节已经有了很完整的介绍，这里不再赘述。本文是想从代码层面来看看其设计实现的方式。\n通信 Exchange Exchange 作为 Client / Server 连接的抽象，负责节点之间的连接。在建立连接中，可以设置一系列应对不同任务的 handler (称之为 ChannelHandler)，这些 ChannelHandler 有的作为 Listener 用来处理连接事件，有的作为 Processor 用来处理各种指定的事件，比如服务信息数据变化、Subscriber 注册等事件。\n图4 - 每一层各司其职，协同实现节点通信\nSession 节点在启动的时候，利用 Exchange 设置了一系列 ChannelHandler：\n PublisherHandler SubscriberHandler\n WatcherHandler\n ClientNodeConnectionHandler\n CancelAddressRequestHandler\n SyncConfigHandler\n 其中 SubscriberHandler 和 PublisherHandler 主要是与服务发布方 (Publisher) 以及服务调用方 (Subscriber) 的行为相关，我们在下面说明。\n任务处理 由于 SubscriberHandler 在 Session 节点启动时就已经初始化并设置，所以当有 Subscriber 注册时，就由 SubscriberHandler 负责后续一系列的处理逻辑。\n图5 - Subscriber 的注册过程\n上面的流程图展示了 Subscriber 注册的处理过程，SessionSever 在处理注册请求时，除了保存 Subscriber 的会话信息，还要为新注册的 Subscriber 提供其所订阅的服务信息数据，最后通过推送的方式将数据发送 Subscriber。\n下面是上述流程在代码模块上的实现，我们依然用图的方式展示出来，大家按图索骥也便于查阅相关源码中的细节。\n图6 - 代码流转：Subscriber 注册\n可以看到，SOFARegistry 采用了 Handler - Task \u0026amp;amp; Strategy - Listener 的方式来应对服务注册中的各种场景和任务，这样的处理模型能够尽可能的让代码和架构清晰整洁。\nPublisher 的注册过程和 Subscriber 基本一致，略有不同的是 Publisher 在注册完毕之后将要发布的数据写到 DataServer 上。\n图7 - Publisher 的注册过程\n这个过程也是采用了 Handler - Task \u0026amp;amp; Strategy - Listener 的方式来处理，任务在代码内部的处理流程和订阅过程基本一致。\n图8 - 代码流转：Publisher 注册\n会话缓存 在二层架构中 (即 Client 直接连接 DataServer)，连接数是一个很难收敛的指标，因为当一个 Subscriber 订阅的服务位于不同 DataServer 上时，他就会与多个 DataServer 同时保持连接，这样“每台 DataServer 承载的连接数会随 Client 数量的增长而增长，每台 Client 极端的情况下需要与每台 DataServer 都建连，因此通过 DataServer 的扩容并不能线性的分摊 Client 连接数”。\n图9 - 两层结构中，扩容无法减少连接数\n这也是 SOFARegistry 设计三层模型的原因，通过 SessionServer 来负责与 Client 的连接，将每个 Client 的连接数收敛到 1，这样当 Client 数量增长时，只需要扩容 SessionServer 集群就可以了。 所以从设计初衷上我们就能够看出来 SessionServer 必须要满足的两个主要能力： …","date":1571223600,"description":" 本文为《剖析 | SOFARegistry 框架》第五篇，作者力鲲","dir":"blog/sofa-registry-session-storage/","fuzzywordcount":2900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5ae2be3be1d395dd7ccb2bddc97b346f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-session-storage/","publishdate":"2019-10-16T19:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-registry-session-storage/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心 Session 存储策略 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-session-storage/","wordcount":2821},{"author":"杨延昭","categories":"云原生","content":" 蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀，以及面向未来的金融技术创新和参会者分享。我们将其中的优秀演讲整理成文并将陆续发布在本网站，本文为其中一篇。\n 本文作者：杨延昭（杨冰），蚂蚁金服智能科技产品技术部总监\n互联网技术发展日新月异，我们正在进入云原生时代，这个过程中金融行业要如何拥抱云原生？在近两年蚂蚁金服将云原生在金融领域落地，沉淀下一些实践经验，接下来我想分享在蚂蚁的演进过程当中，我们心中的云原生是什么样的，在金融领域落地的时候遇到什么问题，以及我们是怎么解决的。\n经过多年云计算的蓬勃发展，上云已经不是太大问题，接下来的问题是怎么把云用好，用得更高效。RightScale 2019年最新数据显示，现在公有云规模占22%，只使用私有云的客户占3%，更多客户通过混合的模式去使用云，通过混合云取得数据隐私、安全与效率、弹性的平衡。\n再看全球整个 IT 行业，公有云的比例只占整个基础 IT 市场的10%，市场空间仍然很大，IT 市场中剩下很多都是传统企业客户。为什么传统行业无法很好地利用公有云，一个重要的原因是因为他们的 IT 系统经过很长时间建设，很多都有自己的机房。另外有些则业务比较稳定，对上公有云没有很强的需求。它们通常会发展混合云策略，把一些核心业务留在私有云，而把一些边缘业务或创新业务放在公有云上。\n这些特点在金融行业也非常明显，除此之外金融行业还有两个特征：\n 业务形态走向开放和互联网化：随着互联网和数字化经济的发展，金融机构需要进行数字化转型，以及业务敏捷化、服务场景化，以应对新的商业模式带来的冲击； 监管合规的诉求：金融行业的业务特点决定了必须是强隔离，强监管的，所以公有云上的资源共享模式在监管方面会有比较大的挑战。 因此，混合云战略对金融机构更为适用。这一结论也得到研究支持，根据调研机构 Nutanix 的报告，全球金融业在混合云应用方面的发展速度超过其它行业，目前部署普及率达到21%，而全球平均水平为18.5%。\n那么，什么样的混合云是适合金融机构的呢？以蚂蚁的演进历程为例。\n蚂蚁在第四代架构的时候演变成为云平台架构，而且为了应对互联网业务形态下突发性业务对资源的弹性需求，蚂蚁也在同一阶段将架构直接进化成弹性混合云架构。现在蚂蚁已经演进到第五代云原生架构。蚂蚁又是如何在云原生的架构下，把混合云变成金融级的混合云，我想会对各位有些启发。在这个发展过程中，有一条主线，是不同阶段蚂蚁对研发的标准和要求，包括：自主、成本、安全、稳定、海量、敏捷，这也是在在线金融的时代，我们对云原生架构的要求。\n从分布式到云原生 建立金融级交易支付系统  建立金融级的在线交易系统，第一步是要实现金融级分布式的架构，蚂蚁在这方面的代表技术是 SOFAStack 和 OceanBase，目前都已对外商业化，并有丰富的案例。SOFAStack 代表的是，在整个应用层或者无状态服务这个层面上，如何去做可伸缩、可扩展的一套架构。OceanBase 代表的是以数据库为代表的存储或者是有状态服务层面，如何在架构上面去进行分布式。它们拥有四个特性：\n 高可用，99.99%+的可用性保证，确保系统始终连续运行不中断； 一致性，在任何异常情况下数据最终一致，确保资金安全； 可扩展，支持应用级、数据库级、机房级、地域级的快速扩展； 高性能，存储采用读写分离架构，计算引擎全链路性能优化，准内存数据库性能。 而这四个关键的特性都是金融业务最为看重的，而且需要在应用和存储上端到端实现。 以一致性为例，在单个数据库内是可以确保数据一致性的，但在大规模应用的情况下，单个数据库总是会出现瓶颈，数据往往会像服务或者应用一样，按照类似交易、支付、账目等粒度垂直拆开，当这些数据分别存储在不同的数据库集群后，就需要在应用层来解决一致性问题了，同时为了支持海量数据，数据库集群内部也会做分别和多副本，OceanBase 就是这样一套分布式数据库，在其内部也要实现分布式事务。只有这样上下配合才能解掉所有分布式架构下的一致性问题，缺一不可。\n再比如可扩展性方面，有些系统号称做了分布式架构，实际可能只是用了微服务框架，做了应用层的服务化改造，但数据库层既没有用水平扩展的技术，也没用分布式数据库，整个系统的可扩展性就卡在数据层的短板上。\n所以，真正的分布式系统，需要实现端到端的分布式，才能实现无限可扩展和高性能，而真正的金融级分布式系统则要实现端到端的高可用和一致性。\n蚂蚁金服三地五中心异地多活架构我们认为，高可用架构最关键的目标是数据不丢，业务不停。在这个目标的基础上，我们设计并实施了三地五中心的异地多活架构。它的核心优势包括城市级容灾，低成本交易，无限可扩展，以及 RPO=0，PTO\u0026amp;lt;30s. 大家知道我们在去年云栖大会上做了一次剪网线的demo，它演示了整个架构层面上怎么样做到跨城市多活和灾难情况下的恢复快速恢复能力。同时在高可用达标的情况下，我们也做了很多风险相关的事情，总结起来就是在高可用的基础上还要做到资金的安全、变更的免疫和故障的快速恢复。\n解决了高可用的问题，其实金融级最被高频提到的话题就是安全，在云原生时代，我们要解决的是全链路、端到端的安全风险。具体分为三个层面：\n 云原生网络安全，包括策略化高效流量控制，全链路加密，流量劫持与分析； 云原生基础设施安全，包括安全容器，不共享内核，以及安全沙箱； 云原生业务安全，包括 SOFAEnclave 机密计算中间件，以及内存安全的、多任务 Enclave LibOS Occlum。  这个部分我的同事在《金融服务的云原生安全架构》演讲中会详细介绍。小结一下，所谓金融级的能力，最主要是要实现端到端的金融级的高可用，同时实现端到端的安全。接下来我想分享的是，在云原生这个阶段往前走遇到了哪些问题。\n从单元化到弹性架构 应对互联网爆炸式的流量脉冲  从单元化到云原生下的弹性架构\n首先解释下什么是单元化，大家可能比较容易理解数据库层的分库分表或者说 Sharding，能够通过分片的方式解决集中存储计算性能问题，单元化的核心思想是把数据的分片提前到了入口请求的分片，在机房的网络接入层将用户请求根据某个纬度（比如用户 ID）进行 Sharding，这就好比把每个机房就当做了一个巨大无比的有状态的数据库分片，当你是一个 ID 尾号为007或者008用户的时候，当请求通过手机端或者网页域名发送到机房，接入层就已经识别出应该将你路由到华东地区还是在华南地区。当你进入到某个地区的机房时，大部分请求处理工作可以在机房内部完成。偶尔会有一些业务可能会发生跨机房的服务调用，比如说数据在 A 机房的用户给数据在 B 机房的用户转账。这个时候就需要在这个机房上去做有状态的设计。\n我们走向云原生时代的时候，在大的架构上面用 Kubernetes 为基础来设计，在单元化架构下，我们选择在每个单元里部署一个 Kubernetes 集群，将支持多 K8s 集群管理和管控指令下发的 Federated APIServer 做逻辑上的全局部署，其中管控元数据是存储在一个 ETCD 集群的，以保持全局数据一 …","date":1571209200,"description":"本文将分享在蚂蚁金服的演进过程当中，我们心中的云原生是什么样的，在金融领域落地的时候遇到什么问题，以及我们是怎么解决的。","dir":"blog/ant-financial-native-cloud-financial-architecture/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b0fce431d72c523e27e31f1fe831fdee","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","publishdate":"2019-10-16T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","summary":"蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀","tags":["云原生"],"title":"云原生时代，什么是蚂蚁金服推荐的金融架构？","type":"blog","url":"/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","wordcount":5366},{"author":"何征宇","categories":"云原生","content":" 蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀，以及面向未来的金融技术创新和参会者分享。我们将其中的优秀演讲整理成文并将陆续发布在“ 金融级分布式架构”公众号上，本文为其中一篇。\n 本文作者：何征宇，gVisor 创始人，蚂蚁金服研究员\n在云原生发展趋势之下，金融行业想要应用云原生技术，安全问题是一个非常大的拦路虎，而云原生社区对安全问题的重视程度远远不够。蚂蚁金服在落地云原生的时候，解决安全问题是重中之重，经过探索与实践，我们沉淀出了一套从底层硬件到软件、从系统到应用层的全链路金融级云原生安全架构。\n金融行业最重要的就是信任，我们认为，安全所带来的信任，是一种无形的产品，支撑着所有金融业务。\n顺应互联网时代发展，金融行业与机构也发生了很多的变化，包括 App、小程序等更多的访问渠道，更快的业务变化，更多的第三方供应商。但是，不管怎么变化，金融行业有一点始终不变，那就是 Zero Fault，对错误的零容忍，也就是对稳定性和安全性的极高要求。\n这里，我还想澄清大家对金融行业的一个错误看法，就是，大家都说金融机构有很多遗留系统，很多技术是十几年前的，就认为金融机构的技术是落后的。但其实，金融行业一直是科技含量非常高的。前段时间有一部电影上映，叫《蜂鸟计划》，根据真实事件改编，讲一帮做高频交易的人，为了降低从堪萨斯到纽约交易所的时间，建造了一条上千英里直通两地的光纤，想尽办法去争取那最后一毫秒。所以，金融行业并不只有平庸保守的科技，它同样也在追逐最前沿最先进的技术，我们的使命就是要用科技来进一步武装金融行业，为金融科技注入更多的活力。\n云原生架构其实代表一种新的生产力，金融行业肯定是需要云原生的，它为我们带来了节约成本和敏捷开发的能力，但是在它前面还需要加一个定语，就是安全的云原生架构，它里面不仅仅包含之前的相对简单的安全方案，而是一个从端到端的全链路可信的安全解决方案。包括明晰代码所有权，做到可信启动，对镜像的制作和发布收口，配合账号体系，明晰应用的所有权和访问权限；以及安全可独立部署的精细化隔离方案，将安全策略和实施集成在基础架构中，对软件开发和测试透明。\n这里我们着重分享蚂蚁金服正在实践的几项云原生安全技术，包括云原生网络安全 Service Mesh，安全容器，以及机密计算。\n云原生网络安全：SOFAMesh  当前，云原生里除了容器之外第二大技术其实就是 Service Mesh，从蚂蚁的实践来看，其实它对金融安全有非常高的帮助。它至少可以做到三点：\n 策略化高效流量控制，可以帮助运维迅速适应业务快速变化； 全链路加密，保护端到端数据安全； 流量劫持与分析，当发现异常流量与容器时，进行流量阻断。 并且，这些工作对业务是透明的，不需要给业务开发增加负担，同时我们还可以对流量进行实时的语义分析等等，做比传统的防火墙更多的事情。\n蚂蚁金服在对 Service Mesh 的探索中，推出了自己用 Golang 打造的 SOFAMesh，并且已经对外开源，希望和社区一起努力，让 Service Mesh 的理念和技术更加普及。\nSOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强大功能和丰富特性的基础上，为满足大规模部署下的性能要求以及应对落地实践中的实际情况，所做的改进包括采用 Golang 编写的 SOFAMosn 取代 Envoy，极大降低了 Mesh 本身的开发难度，并做了一些创新性工作，例如合并Mixer到数据平面以解决性能瓶颈，增强 Pilot 以实现更灵活的服务发现机制，增加对 SOFARPC、Dubbo 的支持，等等。\n更多详情可查看 SOFAMesh 的 GitHub 主页：https://github.com/sofastack/sofa-mesh\n蚂蚁金服率先在生产环境中大规模落地 SOFAMesh，超过 10W+ 容器做到了 Mesh 化，平稳支撑了 618 大促，给我们带来了多协议支持、UDPA、平滑升级、安全等多方面的好处，并且对性能仅有轻微的影响，单跳 CPU 增加 5% 损耗，RT增加不到 0.2ms，甚至部分业务经过 Mesh 化改造将业务链路下沉，RT 反而下降 7%。\n安全容器：Kata Containers  传统容器架构\n提云原生大家肯定都会提容器，传统容器从虚拟机到容器，其实是牺牲了隔离性的，从上图可以很清楚的看到，当我们的应用在容器里，其实共享着同一个 CPU、内存、网络和存储，只是从外面看起来是不同的。这会导致安全上的问题，就是不同的容器之间不存在真正的隔离，一旦一个容器发生安全问题，很可能影响到其它容器，甚至入侵整个系统。蚂蚁金服在这方面做的工作就是安全容器，具体就是 Kata Containers。\n安全容器架构\nKata Containers 安全容器是 OpenStack 基金会的顶级开放基础设施项目，由蚂蚁金服和 Intel 共同主导开发。在安全容器里，每个 Pod 运行在独立的沙箱中，彼此不共享内核，提供强安全保障。这里给大家分享一下 Kata Containers 的近期进展，针对大家最关注的性能问题有了非常大的提升：\n 引入 shimv2 每 Pod 辅助进程数量从 2N+2 减少到 1 个； 引入 virtiofs，提升文件系统性能约 70% 到 90%； 引入 Firecracker， VMM 内存开销从 60MB 降到约 15MB； 改用 rust 实现 agent，占用内存从 11MB 下降到约 1MB。 我们也会和社区一起继续共建 Kata Containers，让安全容器成为云原生的标配。\n安全容器可以有效的保护主机，但是，金融业务本身仍然需要更强的隔离保护，蚂蚁金服引入了机密计算，并根据实际场景研发了大规模落地解决方案 SOFAEnclave。\n机密计算中间件：SOFAEnclave 所谓机密计算，也就是基于例如 Inte SGX，ARM Trustzone 等可信执行环境（Trusted Execution Environment, TEE），也称为 Enclave ，访问计算机内存时隔离用户数据，以避免将数据暴露给其他应用程序、操作系统或其他云服务器租户的解决方案。\nEnclave架构\nEnclave 是运行时的双向保护，比如说你的金融业务跑在 Enclave 上的时候，操作系统都看不到 Enclave 里的内存，同时会进行完整性检查，保证访问 Enclave 的代码不被替换。\n但是 Enclave 目前存在一些问题，阻碍了它在实际生产环境中的应用。总结这些问题包括：\n第一，需要改写应用，因为可信执行环境里面没有内核和基础库，所以没法把应用直接在 Enclave 中执行；第二，需要分割应用，需要把业务程序划分为 Enclave 内和 Enclave 外的部分；第三，未集群化，与客户端场景不同，Enclave 中的应用如何 failover，容灾也是阻止其在数据中心中大规模使用的一个原因。 …","date":1571036400,"description":"本文着重分享蚂蚁金服正在实践的几项云原生安全技术，包括云原生网络安全 Service Mesh，安全容器，以及机密计算。","dir":"blog/ant-financial-native-cloud-security-architecture/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d65835b57ec0e3e24af2c65db5f41824","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","publishdate":"2019-10-14T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","summary":"蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀","tags":["云原生"],"title":"当金融科技遇上云原生，蚂蚁金服是怎么做安全架构的？","type":"blog","url":"/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","wordcount":3402},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@陈文龙 提问：\n 请问一下，使用 Seata 时，undo_log 表的 rollback_info 字典的内容为｛｝（相当于空），事务回滚后记录又没被清除，而服务的日志打出的是成功回滚，log_status 是 1，这是什么原因呢？\n A：1 是防御性的，是收到 globalrollback 回滚请求，但是不确定某个事务分支的本地事务是否已经执行完成了，这时事先插入一条 branchid 相同的数据，插入的假数据成功了，本地事务继续执行就会报主键冲突自动回滚。假如插入不成功说明表里有数据这个本地事务已经执行完成了，那么取出这条 undolog 数据做反向回滚操作。\n相关阅读：分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾\nSOFARegistryLab 系列阅读 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 活动推荐 2019中国开源年会 (COSCon\u0026amp;rsquo;19) 正式启动啦~\n时间： 2019-11-02 09:00 ~ 11-03 17:00\n地址： 上海普陀区中山北路3663号华东师范大学（中北校区）\n本次大会的主题是“开源无疆、携手出航”（Let’s Cross the Boundaries Together!），这也代表主办方对于中国开源，走向世界，走向辉煌的殷切期望。\nSOFAStack 开源社区也受到主办方的邀请参加此次开源年会。\n更多重磅议题与开源嘉宾，点击“这里”，即可了解。\n","date":1570777200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191011/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"98ed37338b0cd1036114b205bcb980c2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191011/","publishdate":"2019-10-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191011/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/7 - 10/11】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191011/","wordcount":776},{"author":"明不二","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第四篇，本篇作者明不二。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 在前面的章节中我们已经提到，SOFARegistry 与其他服务发现领域的产品相比，最大的不同点在于支持海量数据。本章即将讲述 SOFARegistry 在支撑海量数据上的一些特性。\n本文将从如下几个方面进行讲解：\n DataServer 总体架构：对 SOFARegistry 中支持海量数据的总体架构做一个简述，讲解数据分片和同步方案中所涉及到的关键技术点； DataServer 启动：讲解 DataServer 启动的服务，从而为接下来更直观地理解数据分片、数据同步的触发时机以及触发方式等做一个铺垫； 数据分片：讲解 SOFARegistry 中采用的一致性 Hash 算法进行数据分片的缘由以及具体实现方法； 数据同步方案：讲解 SOFARegistry 采用的数据同步方案； DataServer 总体架构 在大部分的服务注册中心系统中，每台服务器都存储着全量的服务注册数据，服务器之间通过一致性协议（paxos、Raft 等）实现数据的复制，或者采用只保障最终一致性的算法，来实现异步数据复制。这样的设计对于一般业务规模的系统来说没有问题，而当应用于有着海量服务的庞大的业务系统来说，就会遇到性能瓶颈。\n为解决这一问题，SOFARegistry 采用了数据分片的方法。全量服务注册数据不再保存在单机里，而是分布于每个节点中，每台服务器保存一定量的服务注册数据，同时进行多副本备份，从理论上实现了服务无限扩容，且实现了高可用，最终达到支撑海量数据的目的。\n在各种数据分片算法中，SOFARegistry 采用了业界主流的一致性 Hash 算法做数据分片，当节点动态扩缩容时，数据仍能均匀分布，维持数据的平衡。\n在数据同步时，没有采用与 Dynamo、Casandra、Tair、Codis、Redis cluster 等项目中类似的预分片机制，而是在 DataServer 内存里以 dataInfoId 为粒度进行操作日志记录，这种实现方式在某种程度上也实现了“预分片”，从而保障了数据同步的有效性。\n图 1 SOFARegistry 总体架构图\nDataServer 启动 启动入口 DataServer 模块的各个 bean 在 JavaConfig 中统一配置，JavaConfig 类为 DataServerBeanConfiguration， 启动入口类为 DataServerInitializer，该类不由 JavaConfig 管理配置，而是继承了 SmartLifecycle 接口，在启动时由 Spring 框架调用其 start 方法。\n该方法中调用了 DataServerBootstrap#start 方法（图 2），用于启动一系列的初始化服务。\n从代码中可以看出，DataServer 服务在启动时，会启动 DataServer、DataSyncServer、HttpServer 三个 bolt 服务。在启动这些 Server 之时，DataServer 注册了一系列 Handler 来处理各类消息。\n图2 DataServerBootstrap 中的 start 方法\n这几个 Server 的作用如下：\n DataServer：数据服务，获取数据的推送，服务上下线通知等； DataSyncServer：数据同步服务； HttpServer：提供一系列 REST 接口，用于 dashboard 管理、数据查询等； 各 Handler 具体作用如图 3 所示：\n图 3 各 Handler 作用\n同时启动了 RaftClient 用于保障 DataServer 节点之间的分布式一致性，启动了各项启动任务，具体内容如图 4 所示：\n图 4 DataServer 各项启动任务\n各个服务的启动监听端口如图 5 所示：\n图5 监听端口\n其他初始化 Bean 除上述的启动服务之外，还有一些 bean 在模块启动时被初始化, 系统初始化时的 bean 都在 DataServerBeanConfiguration 里面通过 JavaConfig 来注册，主要以如下几个配置类体现（配置类会有变更，具体内容可以参照源码实现）：\n DataServerBootstrapConfigConfiguration：该配置类主要作用是提供一些 DataServer 服务启动时基本的 Bean，比如 DataServerConfig 基础配置 Bean、DataNodeStatus 节点状态 Bean、DatumCache 缓存 Bean 等；\n LogTaskConfigConfiguration：该配置类主要用于提供一些日志处理相关的 Bean；\n SessionRemotingConfiguration：该配置类主要作用是提供一些与 SessionServer 相互通信的 Bean，以及连接过程中的一些请求处理 Bean。比如 BoltExchange、JerseyExchange 等用于启动服务的 Bean，还有节点上下线、数据发布等的 Bean，为关键配置类；\n DataServerNotifyBeanConfiguration：该配置类中配置的 Bean 主要用于进行事件通知，如用于处理数据变更的 DataChangeHandler 等；\n DataServerSyncBeanConfiguration：该配置类中配置的 Bean 主要用于数据同步操作；\n DataServerEventBeanConfiguration：该配置类中配置的 Bean 主要用于处理与数据节点相关的事件，如事件中心 EventCenter、数据变化事件中心 DataChangeEventCenter 等；\n DataServerRemotingBeanConfiguration：该配置类中配置的 Bean 主要用于 DataServer 的连接管理；\n ResourceConfiguration：该配置类中配置的 Bean 主要用于提供一些 Rest 接口资源；\n AfterWorkingProcessConfiguration：该配置类中配置一些后处理 Handler Bean，用于处理一些业务逻辑结束后的后处理动作；\n ExecutorConfiguration： …","date":1570690800,"description":" 本文为《剖析 | SOFARegistry 框架》第四篇，作者明不二","dir":"blog/sofa-registry-data-fragmentation-synchronization-scheme/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e4e0cf21756799897553099d37f73100","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","publishdate":"2019-10-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心数据分片和同步方案详解 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","wordcount":5784},{"author":"闫守孟等","categories":"SOFAEnclave","content":" 近日，Linux 基金会宣布全球多家巨头企业成立机密计算联盟（Confidential Computing Consortium），在对于数据安全和隐私担忧的不断增长下，基于可信执行环境技术的机密计算作为一种可行的解决方案，成为互联网巨头关注的焦点。 蚂蚁金服很早就关注此类技术，并基于机密计算打造了蚂蚁金服新一代可信编程中间件 SOFAEnclave，为金融业务保驾护航。 机密计算是蚂蚁安全计算的一环，也是金融级云原生的一块重要版图，蚂蚁金服表示：相信未来机密计算将和 HTTPS 一样，成为云计算的标配。\n 作者 | 闫守孟、肖俊贤、田洪亮 引言 互联网金融本质上是对大量敏感数据的处理以及由此沉淀的关键业务智能。近年来涌现出来的新业态更是将数据处理的范畴从单方数据扩展到了涉及合作方的多方数据。\n另一方面，从 GDPR 到 HIPAA，数据隐私监管保护的范围愈加扩大，力度日益增强。可见，对金融数据和关键业务智能的安全保护，不仅是互联网金融业务的基础，也是其创新发展的依托，更是攸关合规的关键因素。\n近年来迅速发展的机密计算技术是一种创新的数据隔离和加密处理技术，其重要特点是，TCB(trusted computing base 可信计算基) 中仅包含应用自身和基础硬件，即使 OS kernel、Hypervisor、甚至 BIOS 等特权软件都已经遭到破坏甚至本来就是恶意的，敏感数据和代码依然能安全无虞。\n蚂蚁金服在自身的实践过程中，基于机密计算底层技术发展出金融级的机密计算中间件，确保金融应用数据和代码的机密性和完整性，为关键业务提供易用、安全、集群化的计算环境。\n本文从机密计算的技术背景、关键问题、蚂蚁的技术突破、以及典型应用场景等方面展开。\n机密计算的技术背景 随着云计算的快速发展，越来越多的关键性服务和高价值数据被迁移到了云端。云安全也因此成为学术界和工业界关注的一个焦点。\n近年来，云安全领域最重要的一项技术进展名为机密计算（Confidential Computing）。机密计算填补了当前云安全的一项空白——使用中数据（Data-in-use）的加密。过去通行的做法是对数据在存储中（比如硬盘）和传输中（比如网络）加密，而在使用中（比如内存）解密，以便处理。而机密计算可以保护使用中数据的机密性和完整性。\n目前，多家云计算巨头都在不约而同地推广这项技术：微软已于 2017 年 7 月宣布开始接受 Azure 机密计算的早期试用申请；IBM 于 2017 年 12 月宣布 IBM 云数据保护（Cloud Data Guard）的预览版；谷歌也于 2018 年 5 月开源了名为 Asylo 的机密计算框架。\n那么，机密计算究竟是如何实现的呢？\n实际上，上述所有云计算巨头在实现机密计算时都离不开一种称为“可信执行环境（TEE）”的技术。\n顾名思义，TEE 提供一种与不可信环境隔离的安全计算环境，正是这种隔离和可信验证机制使得机密计算成为可能。\nTEE 一般是直接基于硬件实现的，比如 Intel SGX，AMD SEV，ARM TrustZone，以及 RISC-V Keystone 等；基于虚拟化技术也可以构造 TEE，比如微软的 VSM，Intel 的 Trusty for iKGT \u0026amp;amp; ACRN，但尚不能匹敌硬件 TEE 的安全性。\n其中，Intel 软件防护拓展（Software Guard Extensions，简称 SGX）是目前商用 CPU 中最为先进的 TEE 实现，它提供了一套新的指令集使得用户可以定义称为 Enclave 的安全内存区域。CPU 保证 Enclave 与外界隔离，从而保护其中的代码和数据的机密性、完整性和可验证性。不同于之前的 TEE 实现，比如 ARM TrustZone，SGX 每个 APP 都可以有自己独立的 TEE，甚至可以创建多个 TEE，而 TrustZone 是整个系统有一个 TEE；这里也省去了向设备厂商申请将 TA 装入 TEE 的过程。由于 SGX 的先进性，目前云端机密计算领域甚至已公认用 Enclave 这个词来指代 TEE。\n典型 TEE 安全特性和使用流程 [1]\n典型的 Enclave 达到的安全目标可以用 CIA 概括，即机密性（Confidentiality）、完整性（Integrity）和真实性（Authenticity）。在实现上具有以下基本要求：\n1) Enclave 内存保护\nEnclave 内存只有 Enclave 本身的代码可以访问。CPU 通过内存隔离和加密来防止对安全内存的软件攻击和硬件嗅探。SGX 更通过内存控制器的 integrity tree 防止了对 Enclave 内存的物理篡改。\n2) Enclave 的可信验证\nCPU 支持对 Enclave 中数据和代码的测量，以及对 Enclave 合法性的本地或远程验证。有了测量和验证，本地的 Enclave 之间、客户端与远程 Enclave 之间，就可以认证身份，进而建立安全的通信信道。\n如何开发受 Enclave 保护的应用程序呢？\n以 SGX 为例，其中一种方法是利用 Intel SGX SDK。如下图所示，基于 SGX SDK 的应用程序分为两部分：Enclave 外的不可信组件（左边黄色部分）和 Enclave 内的可信组件（右边绿色部分）。两边可以通过跨 Enclave 的函数调用通信：不可信组件可以通过 ECall 调用可信组件中定义的函数；反之，可信组件也可以通过 OCall 调用不可信组件中定义的函数。\nEnclave 编程模型 [2]\n机密计算面临的关键问题 Enclave 给我们带来了前文所谓 CIA 的安全保障，但是目前面临较大的易用性问题。主要体现在几个方面。\n第一，需要将原有应用分割成两部分，一部分是 enclave 外的 untrusted 部分，一部分在 enclave 里面作为 trusted 部分；\n第二，需要精心设计两部分之间的接口，规划好什么时候进入 Enclave，什么时候退出 Enclave——这存在一定技术门槛，而且比较繁琐容易出错；\n第三，即使我们做了完美的分割， Enclave 里面的环境相对于我们熟悉的通常的 Linux 运行环境来说是非常受限的。例如，enclave 里面不能进行系统调用，libc、pthread 不完整，没有 openmp，多进程支持欠缺等等。\n可见，把应用移植到 Enclave 里面是极具挑战的，在某些时候甚至是不可能做到的。而且，由于开发过程中必须考虑业务无关的繁杂琐细的方面，即使最终能完成应用开发移植目标，也会导致低下的开发效率，极高的开发成本，这对于快节奏的互联网业务来说是难以接受的。\n机密计算走向工程实用面临的另一较大问题是，如何将机密计算从单节点向集群扩展。由于缺乏标准的做法，或者没有一个 best practice 作为参考，很多时候各个业务不得不各自从头造轮子，搭建跟业务逻辑过度耦合的 Enclave 集群基础设施。从而导致低下的开发效率和重复的资源投入。\n另一方面，互联网业务日趋云原生化， …","date":1570258800,"description":"基于机密计算打造的新一代可信编程中间件。","dir":"blog/sofa-enclave-confidential-computing/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f994d83c7c4b263b08e4d2fd22a461b4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-enclave-confidential-computing/","publishdate":"2019-10-05T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-enclave-confidential-computing/","summary":"近日，Linux 基金会宣布全球多家巨头企业成立机密计算联盟（Confidential Computing Consortium），在对于数据安全和隐私担忧的不断","tags":["SOFAEnclave"],"title":"SOFAEnclave：蚂蚁金服新一代可信编程环境，让机密计算为金融业务保驾护航102年","type":"blog","url":"/sofastack.tech/blog/sofa-enclave-confidential-computing/","wordcount":6249},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFALab 系列文章 十一特刊带来 SOFALab 系列源码解析文章集合~\nSOFA:RPCLab/ 系列文章 【剖析 | SOFARPC 框架】系列之总体设计与扩展机制 【剖析 | SOFARPC 框架】系列之链路追踪剖析 【剖析 | SOFARPC 框架】系列之连接管理与心跳剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 同步异步实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 线程模型剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 单机故障剔除剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 泛化调用实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 数据透传剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 优雅关闭剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 路由实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 跨语言支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 序列化比较 SOFA:BoltLab/ 系列文章 蚂蚁金服通信框架SOFABolt解析 | 编解码机制 蚂蚁金服通信框架SOFABolt解析 | 序列化机制(Serializer) 蚂蚁金服通信框架SOFABolt解析 | 协议框架解析 蚂蚁金服通信框架SOFABolt解析 | 连接管理剖析 蚂蚁金服通信框架SOFABolt解析 | 超时控制机制及心跳机制 SOFA:TracerLab/ 系列文章 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览 | 剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码分析 | 剖析 蚂蚁金服分布式链路跟踪组件链路透传原理与SLF4J MDC的扩展能力分析 | 剖析 蚂蚁金服分布式链路跟踪组件采样策略和源码 | 剖析 蚂蚁金服分布式链路跟踪组件埋点机制 | 剖析 SOFA:JRaftLab/ 系列文章 SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.5.8，主要变更如下：\n 优化 log4j2 日志异步化 修复故障剔除模块的事件接收问题 修复 tracelog 日志 local 地址打印不正确的问题 优化泛化调用的方法名显示 修复特殊场景下的泛化调用超时设置 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.5.8\n","date":1570172400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191004/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"81a2a8115038fb193b50618c4d845bf4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191004/","publishdate":"2019-10-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191004/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/30 - 10/4】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191004/","wordcount":1056},{"author":"SQLFlow","categories":"SQLFlow","content":" 2018 年 1 月，Oracle 的官方博客上发表了一篇文章，标题是“It\u0026amp;rsquo;s Pervasive：AI Is Everywhere”。作为全球最著名的商业数据库系统提供商，Oracle 在这篇文章里历数了 AI 在企业信息系统中的发展空间。在面向最终用户的互联网行业，巨头们招募 AI 专家，用 Python 和 C++ 打造服务大众的特定 AI 能力——搜索、推荐、以及精准定向的互联网广告系统。在企业业务中，使用 SQL 的分析师是大多数。\n滴滴首席数据科学家谢梁（左）与蚂蚁金服研究员王益开启共建SQLFlow之旅\n2019 年 7 月，滴滴的数据科学（Data Science）团队的几名数据科学家在北京新澄海大厦见到了来自蚂蚁金服的几位工程师。在那之前两个月，蚂蚁金服从事 AI 基础架构研发的王益团队开源了一款机器学习工具 SQLFLow，将 SQL 程序翻译成 Python 程序，调用数据库和 AI 引擎，实现端到端的 AI。滴滴首席数据科学家谢梁敏锐地关注到这个项目。这次拜访双方一拍即合，开启了共建 SQLFlow 之旅。\n用 SQLFlow 构建 AI 的训练和预测任务\n数据分析师的普适 AI  数据驱动决策是很多公司的追求，在国内很多业务人员都了解 SQL，但是对于 AI、深度学习模型的训练，需要长时间系统性的学习，有一定的门槛。SQLFLow 的出现让包括数据分析师在内的业务人员通过写简单的 SQL 去调用 AI 模型成为了可能。滴滴数据科学团队长期地直面一线业务，了解业务需求，也沉淀了很多常用模型。本次合作双方希望优势互补共同助力 AI 的落地，据悉合作分为三步，第一步滴滴为蚂蚁金服贡献更多针对于业务产品的理解和洞见；第二步滴滴将公司自身业务场景最有价值用的最好的模型贡献到 SQLFLow；第三步滴滴加入到建设到整个 SQLFLow 开源社区的建设，双方要在模型、社区、文化等全方位共建。\nSQLFlow的技术架构\n一个多月的时间，滴滴已经为 SQLFLow 贡献了基于 DNN 分类预测模型、可解释模型和无监督聚类模型三个高价值模型。这三个模型覆盖的场景非常广泛，对于滴滴内部来说，包括网约车、单车、金融等在内的诸多业务场景都可应用起来，于外部而言，“因为整个模型它是一种基础能力，其实它不会局限于某一个公司或某一个行业，它具有普适性。”滴滴高级数据科学家高梓尧强调。\nSQLFlow 和滴滴数据的整合逻辑\n比如分类预测模型，适用于做产品增长的场景，对特定人群进行定向推荐。而无监督聚类模型，也就是模式识别，在滴滴的产品的应用非常广，比如会根据司机出车时长分布，去整合归纳司机出车的偏好，更好地为司机提供调度建议，进而帮助缓解出行供需。\n滴滴首席数据科学家谢梁认为在共建 SQLFlow 过程中，充分体现了算法和数据科学在对数据的理解和应用上的两个不同，以及双方优势互补形成 1+1 大于 2 的合力效果。因为对于传统的算法来讲主要强调对于预测一个给定事件的预测精准性。但是数据科学在预测精准性之上，还强调预测的可解释性。实际上在更广泛的商业层面上，比如运营、营销等更需要了解为什么会这这样发生，这对于业务战略制定、营销方案的确定，以及整个产品序列的设计都有非常大的帮助。\n滴滴数据科学团队在过去不到两个月的共建工作中显著扩大了 SQLFlow 的应用场景。根据蚂蚁金服 SQLFlow 项目的产品负责人刘勇峰介绍，滴滴的同事们建议并且参与研发了 SQLFlow 对接 XGBoost 的功能，从而在深度学习模型之外支持树模型；以及对接 unsupervised learning 的能力，支持聚类分析。此外，SQLFlow 基于 SHAP 支持了深度学习模型和树模型的图示化解释。SQLFlow 也支持了滴滴常用的 Hive 数据库系统。\n基于 XGBoost 的汽车价格预测模型（数据来自 Kaggle）的 SHAP 解释图（注：SHAP 值表征了每个特征对模型输出的影响，如图中，较小的 engine_hp“引擎马力”值会降低汽车的预测价格）\n“我们是希望通过 SQLFlow 真正能够把数据驱动业务、科学决策的思想，能够在中国传播得更好更远，也希望就是能够通过我们自己的努力，真正让 AI 模型能力大众化和普及化，然后使得我们整个国内的数据分析的科学性、合理性和洞察性，能够逐步提升，甚至达到国际领先。”高梓尧说。\n而所有参与项目的同事们对 SQLFlow 的未来都有更大的期待，这是对于开源社区作为一种高效率的工作模式的信任。\n打造一个 SQL 花园生态 在强调数据驱动的滴滴其实一直积极参与到开源建设中，截至目前，滴滴和蚂蚁金服分别开源了数十个项目。SQLFlow 是双方开源共建的首秀。\n对于双方仅一个多月的时间就能够共建三个高价值的模型，谢梁认为很重要的原因是 SQLFlow 已经给滴滴搭建好了底层能力，滴滴相当于做了一个交通领域的几个核心插件，并且通过滴滴插件能力，对整个 SQLFlow 覆盖面和深度方面的底层能力进行了验证和提升，“那么再把这个基础打好之后，我们就相当于造了一个大的花园，我们把土都铺好了，需要什么营养的土，要种什么类型的花，都给他做好了，之后就需要有更多的农民伯伯一起来种田，他们要去种向日葵，我们毕竟精力有限可能就是以种小麦和种主粮为主，更多的经济作物就需要其他开源社区的同学一起来贡献。”\n在整个 SQLFlow 开源社区建设方面双方都有更大的愿景，滴滴的分析团队总结的很多模型在 BI 领域具备普适性，而 SQLFlow 在蚂蚁的场景使用模型在金融领域颇有普适性，未来要让更多的人去用上普适的 AI 能力，在 SQLFlow 社区之上会形成一个开源货架式的交易市场，更多懂业务的人把更多商业场景抽象成模型打造成模型库，模型库是 SQLFlow 生态中的重要一环，双方正在讨论如何共建。“你就像走进一个超市，里面有 10万个 SQL，每一个 SQL 就是一个实现了你商业逻辑的模型，你就拿来用就行了，这是终极的一个目标”，谢梁兴奋地谈到。\n当然现在的 SQLFlow 还是一个非常年轻的开源项目，需要更多的呵护。虽然目前在开源合作方面中国相比美国还有不少差距，但正是因为越来越多的公司和个人去投身其中为之贡献，差距正在缩小。实际上，几乎所有的 SQLFlow 项目成员都是利用业余时间参与到开源项目中。比如滴滴资深算法工程师陈祥，他平时负责数据治理和应用方向上数据、应用与算法的结合和落地, 在 8 月初听到 SQLFlow 项目就决定参与进来，未来他也会号召很多的人参与到开源建设中。\n“开源社区所说的构建大生态，其实大生态还包含着另外一层，就是大家互相学习，然后行业内的所有从业人员进行知识交流。所以当各行各业的同学都在里面贡献自己的经验、技能时，我们其实也能从其他的同学那学习到很多处理数据，或者解决实际问题的方法。”高梓尧所言恰如其分地诠释了开源社区众人拾柴火焰高的魅力。\nGartner 预测“到 2020 年，AI 技术将普遍出现在几乎每一个新的软件产品和服务中。”这其中有蚂蚁金服与滴滴 DS 团队的一份力。\n项目地址 欢迎感兴趣的同学加入社区讨论： 项目官 …","date":1569740400,"description":"让AI 像 SQL 查询一样简单。","dir":"blog/sqlflow-ai-didi-antfin-open-source-construction/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d8e2fdbfc1d48f984a2adf17474cb983","permalink":"https://sofastack.github.io/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","publishdate":"2019-09-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","summary":"2018 年 1 月，Oracle 的官方博客上发表了一篇文章，标题是“It\u0026rsquo;s Pervasive：AI Is Everywhere”。作为全球最著","tags":["SQLFlow"],"title":"让 AI 无处不在：滴滴与蚂蚁金服开源共建 SQLFlow","type":"blog","url":"/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","wordcount":2732},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、关于 SOFAJRaft 的提问：\n@LoFi 提问：\n 关于 SOFAJRaft，请教几个问题：不管 raft log 是并行，batch 还是 pipeline 复制，都是为了提高 throughput，但对 latency 没有好处，因为最终日志必须要顺序 commit 和顺序 Apply ，这是 Raft 论文的要求。但是在某些简单的 KV 场景，上层业务可以根据需求去乱序 commit 和 Apply 么？这样可以降低 latency 。\n A：pipeline 对 latency 会有一些好处，总体上讲 batch 对吞吐有好处，SOFAJRaft 里的 batch 设计也不会对 latency 有坏处，所以它还是好的，乱序 apply 理论上影响一致性。\n 如果 raft log commit 成功，但是 apply 失败，系统目前的处理方式是什么？直接 crash?\n A：apply 异常失败会阻塞住状态机，只有重启才可能恢复，为了保证一致性。\n 如果 leader 本地磁盘 error 或者本地 log flush 失败, 但收到了多数派的响应，日志会 commit 么？怎么处理这种情况？\n A：你说的这种异常状态机就挂掉了，原因同上一条。\n关于扩容：\n 扩容时，新节点的角色不能为 follow 吧？会影响 ballot，不应该先增加一个 Follow 角色，等 snapshot 加载成功后再变为 follow 么？\n A：新加节点首先要求日志追上才行，你说的这个不存在。\n 扩容时，如果是 follow 的话，根据论文就会影响 leader 的投票吧\n A：那首先得你说的这个 follower 在这个组里呀。首先要追上数据，才能变更配置，这个节点才会进入 group，另外再退一步，没有最新日志的 follower 也无法影响投票。SOFAJRaft 比 Raft 论文里面多了一个 preVote。\n 明白，就是先追上数据，然后才能再走一遍 addpeer raftlog ?\n A：不是额，是 addPeer 的流程里第一步就是要先追数据。\n 你的意思是：当新的节点加入集群时，会先追日志 , 然后再把这个节点加入到 raft goup 中，成为投票中的一员 是么？ 也就是说在追日志的过程中，这个新的节点是不会参与 raft log 的投票么？那如果说我只是为一个 raft goup 增加副本数，比如从 3 副本变成 4 副本时，这个时候是怎么处理的呢？反正就是不管哪种情况，都是先追数据，然后再加入到 Goup 里？\n A：新加的 follower 一启动，就会 electiontimeout 发起选举，但是不会成功，然后 leader 会为这个节点新起一个 replicator 开始复制数据日志（通常包含 snapshot），等到数据追上后，leader 会再提交一条配置变更日志，此时这个节点就正式加入到 group 了。\n2、关于 Seata 的提问：\n@姜伟锋 提问：\n 最近在看 Seata 的源码，发现 rpc 相关的 Request、Response 网络传输对象太多了，在保证扩展性的基础上是不是可以优化下，因为主要参数也就是事务组 id、事务组 status、分支事务 id、分支事务 status，再加上附加信息字段，感觉这块设计还有相关序列化设计有点复杂了，这样设计的目的是什么呢，求大佬解。\n A：是指字段冗余还是指外层的包装协议复杂了？\n rpc 传输对象感觉有点冗余，一些 request response 对象是不是可以合并，主要字段应该是固定的，这样设计的目的扩展性是很好，复用性是不是还有优化空间呢？\n A： 这里是按照非事务消息（注册鉴权之类）和事务消息，事务消息又按照 RM，TM 角色以及传输的方向做了分类，你说的冗余能举个栗子嘛？\n 看到是按角色定义的 rpc req，res 传输对象，这些词传输对象中主要的字段是全库事务 id，全库事务状态，分支事务 id，分支事务状态，资源 id，还有一些附加字段，TM、TC、RM 交互时为什么不设计成一个 req res 对象公用或者是否可以在现有框架上提高下复用性，个人是觉得这块设计了好多传输对象，每个对象有对应的序列化和反序列化，有点复杂，这样设计扩展性这个点我明白，复用性不是太好，还有其他考虑吗？\n A：每个消息都有一个名称（code），消息名对于整个事务的链路流程上理解比较清晰，结合着我们的事务流程图来看，每个阶段的 rpc 都有一个确切的含义，即使从字段上来说是相同的比如GlobalRollbackRequest，GlobalCommitRequest 从名称上来看不一样，但从传输层面来看除了code 不一样其他的是一样的。但是大部分消息的字段还是不一样的，对于这种通用字段比如 xid begin 消息就是空的，设计成通用这里只能是 null，非通用比如 lockkey 那这里如果使用通用消息就可能直接塞到一个 applicationData 的扩展字段里，这种写法我觉得不确切，同时有增加了我私有协议序列化时不必要的长度标识字段，每条消息都是由确切的所需的字段，宁愿复杂一些，也要从设计上更清晰些。\nSeata：https://github.com/seata/seata\nSOFAJRaft 解析文章全系列 《剖析 | SOFAJRaft 实现原理》系列文章完结啦，感谢 SOFAStack 社区的核心贡献者们的编写，也欢迎更多感兴趣的技术同学加入。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft …","date":1569567600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190927/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d1709ae51d5099a6263d7269a435e264","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190927/","publishdate":"2019-09-27T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190927/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/23 - 9/27】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190927/","wordcount":2458},{"author":"胡宗棠","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》最后一篇，本篇作者胡宗棠，来自中国移动。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文末包含往期系列文章。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n导读 本文主要介绍 SOFAJRaft 在日志复制和管理中所采用的快照机制。考虑到单独介绍 SOFAJRaft 中的快照机制原理和实现或许有一些唐突，我会先通过一个读者都能够看得明白的例子作为切入点，让大家对快照这个概念、它可以解决的主要问题，先有一个比较深刻的理解。\n一、快照的概念与特点 SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法，就不可避免的要对需要达成共识的内容，在多个服务器节点之间进行传输，一般将这些共识的内容称之为日志块（LogEntry）。如果读过《剖析 | SOFAJRaft 实现原理》系列前面几篇文章的同学，应该了解到在 SOFAJRaft 中，可以通过“节点之间并发复制日志”、“批量化复制日志”和“复制日志pipeline机制”等优化手段来保证服务器节点之间日志复制效率达到最大化。\n但如果遇到下面的两个场景，仅依靠上面的优化方法并不能有效地根本解决问题：\n 当对某个 SOFAJRaft Group 集群以新增节点方式来扩容，新节点需要从当前的 Leader 中获取所有的日志并重放到本身的状态机中，这对 Leader 和网络带宽都会带来不小的开销，还有其他方法可以优化或解决这个问题么？ 因为服务器节点需要存储的日志不断增加，但是磁盘空间有限，除了对磁盘卷大小扩容外，还有其他方式来解决么？ 带着上面两个疑问，我们可以先来看一个大家日常生活中都会遇到的场景—重新安装操作系统，然后再通俗易懂地为大家介绍快照的概念与特点。\n有一天，你的笔记本电脑的 Windows 操作系统因为某一些原因出现启动后多次崩溃问题，不管通过任何方式都没办法解决。这时候，我们想到解决问题的第一个方案就是为这台电脑重新安装操作系统。如果，我们平时偶尔为自己电脑的操作系统做过镜像，直接用之前的镜像文件即可快速还原系统至之前的某一时间点的状态，而无需从零开始安装 Windows 操作系统后，再花大量时间来重新安装一些自己所需要的系统软件（比如 Chrome 浏览器、印象笔记和 FoxMail 邮件客户端等）。\n在上面的例子中，电脑操作系统的镜像就是系统某一时刻的“快照”，因为它包含了这一时刻，系统当前状态机的值（对于用户来说，就是安装了哪些的应用软件）。在需要重新安装操作系统时候，通过镜像这一“快照”，可以很高效地完成还原电脑操作系统这个任务，而无需从零开始安装系统和相应的应用软件。所以，我们这里可以为“快照”下一个简单的定义：一种通过某种数据格式文件来保存系统当前的状态值的一个副本。\n“快照”的特点，就如同它字面意思一样，可以分为“快”和“照”：\n “快”：高效快捷，通过快照可以很方便的将系统还原至某一时刻的状态； “照”：通过快照机制是保存系统某一时刻的状态值； 二、SOFAJRaft 的 Snapshot 机制 2.1 SOFAJRaft Snapshot 机制的原理 读到这里，再去回顾第一节内容开头提出的两个问题，大家应该可以想到解决问题的方法就是通过引入快照机制。\n1. 解决日志复制与节点扩容的瓶颈问题 在 SOFAJRaft 中，Snapshot 为当前 Raft 节点状态机的最新状态打了一个“镜像”单独保存，保存成功后在这个时刻之前的日志即可删除，减少了日志文件在磁盘中的占用空间。而在 Raft 节点启动时，可以直接加载最新的 Snapshot 镜像，直接重放在此之后的日志文件即可。如果设置保存 Snapshot 的时间间隔比较合理，那么节点加载镜像后重放的日志文件较少，启动速度也会比较快。对于新 Raft 节点加入某个 SOFAJRaft Group 集群的场景，新节点可先从 Leader 节点上拷贝最新的 Snapshot 安装到本地状态机，然后拷贝后续的日志数据即可，这样可以在快速跟上整个 SOFAJRaft Group 集群进度的同时，又不会占用 Leader 节点较大的网络带宽资源。\n2. 解决 Raft 节点故障恢复中的时效问题 在一个正常运行的 SOFAJRaft Group 集群中，当其中某一个 Raft 节点出现故障了（假设该故障的原因不是由磁盘损坏等不可逆因素导致的），该 Raft 节点修复故障重新启动时，如果节点禁用 Snapshot 快照机制，那么会重放所有本地的日志到状态机以跟上最新的日志，这样节点启动和达到日志备份完整的耗时均会比较长。但是，如果此时节点开启了 Snapshot 快照机制，那么一切就会变得非常高效，节点只需要加载最新的 Snapshot 至状态机，然后以 Snapshot 数据的日志为起点开始继续回放日志至状态机，直到使得状态机达到最新状态。\n图1 在 Snapshot 禁用情况下集群节点扩容\n图2 在 Snapshot 启用情况下集群节点扩容\n从上面两张 SOFAJRaft 集群的结构图上，可以很明显地看出在开启和禁用 Snapshot 时，扩容的新 Raft 节点需要从 Leader 节点传输过来不同的日志数量。在禁用 Snapshot 情况下，新 Raft 节点需要把 Leade 节点内从起始的 T1 时刻至当前 T3 时刻这一时间范围内的所有日志都重新传至本地后提交给状态机。而在开启 Snapshot 情况下，新 Raft 节点则无需像 图1 中那么逐条复制 T1~T3 时刻内的所有日志，而只需先从 Leader 节点加载最新的镜像文件 Snapshot_Index_File 至本地，然后仅复制 T3 时刻以后的日志至本地并提交状态机即可。\n在这里可能有同学会有疑问：“在 图 1 中，从 Leader 节点传给新扩容的 Raft 节点的数据是 T1~T3 的日志，而 图2 中取而代之的是 Snapshot_Index_File 快照镜像文件，似乎还是不可避免额外的数据传输么？”仔细看下图 2，会发现其中 Snapshot_Index_File 快照镜像文件是对 T1~T3 时刻内日志数据指令的合并（包括数集合[Add 1,Add 6,Add 4,Sub 3,Sub 4,Add 3]），也即为最终的数据状态值。\n2.2 SOFAJRaft Snapshot 机制的实践应用 如果用户需开启 SOFAJRaft 的 Snapshot 机制，则需要在其客户端中设置配置参数类 NodeOptions …","date":1569232800,"description":"本文为《剖析 | SOFAJRaft 实现原理》最后一篇，本篇作者胡宗棠。","dir":"blog/sofa-jraft-snapshot-principle-analysis/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"39ff132d4c11bccb0059665f6e9c4b31","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","publishdate":"2019-09-23T18:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","wordcount":4407},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@wy223170 提问：\n 你好，请问下 SOFAJRaft 如何在虚拟化环境下使用，比如部署三个实例，三个实例都是 docker 的。因为虚拟化实例可能漂移，怎么保证 snapshot 的迁移呢？另外怎么控制多个实例的同时漂移，导致集群不可用的问题？\n A：SOFAJRaft 本身是有状态的，你说的实例漂移就可以理解为这个节点挂掉并新拉起了一个节点，我们内部的做法是通过一个 manager 节点监听容器上下线并执行 CliService removePeer 和 addPeer，利用 raft 协议本身的能力达到数据迁移的目的，但是对于半数以上节点同时漂移是无解的，可能出现丢数据的情况。这是 etcd 的一个解决类似问题的方式，供参考：https://github.com/coreos/etcd-operator\n 感谢回答，是不是只要 manager 节点监听到容器变化就会立刻进行 removePeer 或 addPeer，需不需等待容器已经达到某种状态，比如迁移完 snapshot 等才进行 addPeer 之类的，这可能就需要实例迁移后完成一个打标记的功能标志迁移完成了。\n A：流程是先 addPeer 成功以后再 removePeer。其中 addPeer 在追数据成功后才会返回成功。看到你多次强调 snapshot，其实这里你不用关注 snapshot，这是 SOFAJRaft 内部会考虑的 raft 层的东西，不需要额外做特殊处理。\n开源项目 ElasticDL：蚂蚁金服开源基于 TensorFlow 的弹性分布式深度学习系统 蚂蚁金服开源机器学习工具 SQLFlow，技术架构独家解读 SOFA 项目进展 本周发布详情如下：\n发布 Seata v0.8.1，主要变更如下：\n 支持配置文件使用绝对路径 支持 DataSource 的自动代理 支持通信协议的 kryo 编解码 修复 file 存储模式的 selectForUpdate lockQuery exception 修复数据库连接使用后的 autocommit 问题 优化 etcd3 中 watcher 订阅的效率 优化当数据表无索引时抛出显式异常 详细发布报告： https://github.com/seata/seata/releases/tag/v0.8.1\nSOFAJRaftLab 系列阅读 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 ","date":1568962800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190920/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4519012918ba68bf9e39b0daed78cfc4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190920/","publishdate":"2019-09-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190920/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/16 - 9/20】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190920/","wordcount":1043},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第七篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文末包含往期系列文章。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 在分布式部署、高并发、多线程场景下，我们经常会遇到资源的互斥访问的问题，最有效、最普遍的方法是给共享资源或者对共享资源的操作加一把锁。在 JDK 中我们可以使用 ReentrantLock 重入锁或者 synchronized 关键字达成资源互斥访问目的，但是由于分布式系统的分布性（即多线程和多进程并且分布在不同机器中），使得两种锁失去原有锁的效果，需要用户自定义来实现分布式锁。\n本文重点围绕分布式锁概览、实现方式以及基于 SOFAJRaft 实现等方面剖析 SOFAJRaft-RheaKV 基于 SOFAJRaft 实现分布式锁原理，阐述如何使用 SOFAJRaft 组件提供分布式锁服务功能：\n 什么是分布式锁？分布式锁具备哪些条件？分布式锁有哪些实现方式？ RheaKV 基于 SOFAJRaft 如何实现分布式锁？解决分布式锁哪些问题？ 分布式锁 分布式锁是控制分布式系统之间同步访问共享资源的一种方式，用于在分布式系统中协调他们之间的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下便需要使用到分布式锁。分布式锁通过共享标识确定其唯一性，对共享标识进行修改时能够保证原子性和对锁服务调用方的可见性。\n分布式锁概览 Martin Kleppmann 是英国剑桥大学的分布式系统研究员，之前和 Redis 之父 Antirez 关于 RedLock 红锁是否安全的问题激烈讨论过。Martin 认为一般我们使用分布式锁有两个场景：\n 效率：使用分布式锁能够避免不同节点重复相同的工作导致浪费资源，譬如用户付款之后有可能不同节点发出多条短信； 正确性：添加分布式锁同样避免破坏正确性事件的发生，如果两个节点在同一条数据上面操作，譬如多个节点机器对同一个订单操作不同的流程有可能导致该笔订单最后状态出现错误造成资金损失； 分布式锁需要具备的条件包括：\n 获取锁和释放锁的性能要好； 判断获得锁是否是原子性的，否则可能导致多个请求都能获取到锁； 网络中断或者宕机无法释放锁时，锁必须被清除； 可重入一个线程中多次获取同一把锁，譬如一个线程在执行带锁的方法，该方法调用另一个需要相同锁的方法，则该线程直接执行调用的方法，而无需重新获得锁； 阻塞锁和非阻塞锁，阻塞锁即没有获取到锁，则继续等待获取锁；非阻塞锁即没有获取到锁，不继续等待直接返回获取锁失败； 分布式锁实现 分布式 CAP 理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance），最多只能同时满足两项。”，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。在很多场景中为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候需要保证一个方法在同一时间内只能被同一个线程执行。 分布式锁一般有三种实现方式：\n 基于数据库实现分布式锁； 基于缓存（Redis，Memcached，Tair）实现分布式锁； 基于 ZooKeeper 实现分布式锁； 基于数据库实现分布式锁 基于数据库实现分布式锁的核心思想：在数据库中创建一张表，表里包含方法名等字段，并且在方法名字段上面创建唯一索引，执行某个方法需要使用此方法名向表中插入数据，成功插入则获取锁，执行结束则删除对应的行数据释放锁。\n基于缓存实现分布式锁 基于缓存通常选用 Redis 实现分布式锁，考虑到 Redis 有非常高的性能，Redis 命令对分布式锁支持友好，并且实现方便。基于单 Redis 节点的分布式锁在 Failover 的时候产生解决不了的安全性问题，Redlock 是 Redis 的作者 Antirez 提出的集群模式 Redis 分布式锁，基于 N 个完全独立的 Redis 节点（通常情况下 N 可以设置成5），运行 Redlock 算法依次执行下面各个步骤完成获取锁的操作\n 获取当前时间（毫秒数）； 按顺序依次向 N 个 Redis 节点执行获取锁的操作。此获取操作包含随机字符串 my_random_value，也包含过期时间(比如 PX 30000，即锁的有效时间)。为了保证在某个 Redis 节点不可用的时候算法能够继续运行，获取锁的操作还有超时时间(time out)，它要远小于锁的有效时间（几十毫秒量级）。客户端在向某个 Redis 节点获取锁失败以后应该立即尝试下一个Redis 节点。这里的失败包含任何类型的失败，比如该 Redis 节点不可用，或者该 Redis 节点上的锁已经被其它客户端持有（注：Redlock 原文中这里只提及 Redis 节点不可用的情况，但也应该包含其它的失败情况）； 计算整个获取锁的过程总共消耗了多长时间，计算方法是用当前时间减去第1步记录的时间。如果客户端从大多数 Redis 节点（\u0026amp;gt;= N/2+1）成功获取到了锁，并且获取锁总共消耗的时间没有超过锁的有效时间（lock validity time），那么这时客户端才认为最终获取锁成功；否则认为最终获取锁失败； 如果最终获取锁成功了，那么此锁的有效时间应该重新计算，它等于最初锁的有效时间减去第3步计算出来的获取锁消耗的时间； 如果最终获取锁失败（可能由于获取到锁的 Redis 节点个数少于 N/2+1，或者整个获取锁的过程消耗的时间超过了锁的最初有效时间），那么客户端立即向所有 Redis 节点发起释放锁的操作； 基于 ZooKeeper 实现分布式锁 ZooKeeper 是以 Paxos 算法为基础的分布式应用程序协调服务，为分布式应用提供一致性服务的开源组件，其内部是分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于 ZooKeeper 实现分布式锁步骤包括：\n 创建一个锁目录 lock； 希望获得锁的线程 A 在 lock 目录下创建临时顺序节点； 当前线程获取锁目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在表示当前线程顺序号最小，获得锁； 线程 B 获取所有节点，判断自己不是最 …","date":1568721600,"description":"本文为《剖析 | SOFAJRaft 实现原理》第七篇，本篇作者米麒麟。","dir":"blog/sofa-jraft--rheakv-distributedLock/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"be578aa3941f24a603a7053e7c7e1107","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","publishdate":"2019-09-17T20:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","剖析 | SOFAJRaft 实现原理","SOFALab"],"title":"SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","wordcount":6176},{"author":"Oschina","categories":"ElasticDL","content":" 9 月 11 日，蚂蚁金服在2019谷歌开发者大会上海站上开源了 ElasticDL 项目，这是业界首个基于 TensorFlow 实现弹性深度学习的开源系统。\n开源地址为：https://github.com/sql-machine-learning/elasticdl/\n开源中国采访了 ElasticDL 项目负责人王益，对该深度学习系统的技术细节进行了全面介绍。\n基于 TensorFlow 2.0 和 Kubernetes实现弹性深度学习 这个基于 Eager Execution 模式的开源项目名为“ElasticDL”，它是一个Kubernetes 原生深度学习框架，根据介绍，ElasticDL 主要有四大特点：\n 容错性 弹性调度 易用性 高效 其中又以容错与弹性调度特性最具特色。\nElasticDL 实现了容错和弹性调度的分布式深度学习，可以极大提升集群的总体利用率，同时显著减少用户提交作业之后等待作业启动的时间（pending time）。\n王益介绍：“ElasticDL 是我们知道的第一个基于 TensorFlow 实现弹性深度学习的开源系统。具体地说，ElasticDL 是基于 TensorFlow 2.0 和 Kubernetes 实现弹性深度学习的。”\n集群效用从 1/N 到 N/N 在深度学习技术研发的早期，公用一个计算集群的人相对少， 计算作业之间的协调可以通过口头交流实现。开发者更关心缩短运行时间，也就是从作业启动到结束的这段时间。高性能计算技术（HPC）是解决这个问题的有效途径，比如 NVIDIA 的 cuBLAS 和 cuDNN 优化高性能数学计算、NCCL 优化 GPU 之间的通信效率。\n随着深度学习技术的大规模应用，在许多工程师和研究员公用一个集群的情况下，通过商量来协调调度显然不可行，于是大家开始使用集群管理系统调度分布式作业。\nKubernetes 近年来已经逐渐成为集群管理的重要工具，目前已经在各大公有云中广泛采用。因此，让 TensorFlow 能更好地运行在 Kubernetes 集群上，同时提升利用集群进行深度学习的效率和资源利用率（效用），显得非常具有实际意义。\n关于提升集群资源利用率，王益举了一个比较极端的例子：假设一个集群有 N 个 GPU，而一个任务只使用其中一个，现在有一个任务占用了一个 GPU。当没有弹性调度机制时，一个要求所有 N 个 GPU 的任务需要等待前一个任务结束才能开始，这个等待时间可能高达数天甚至数周，在等待期间，集群的效用是 1/N；而拥有弹性调度能力之后，新的任务可以在 N-1 个 GPU 上立即运行，并且 Kubernetes 可以在第一个任务完成后将占用的 GPU 赋予这个任务，这种情况下，集群整体效用是 100%。\nElasticDL 在容错与弹性调度上都有不错的表现，它的现实意义便是高效解决集群效用问题。\nElasticDL 如何实现？ 前边讲到集群资源利用率提高的前提其实就是ElasticDL 的“弹性调度”特性带来的，而弹性调度依赖于容错能力。\n容错是指作业不受其中进程数量变化的影响，在弹性调度过程中，作业里的进程数量会随集群 workload 情况相应增减，所以作业必须是容错的，才能配合调度系统，实现弹性调度。\n在这个过程中，容错通常由分布式框架实现，比如 Spark 和 ElasticDL 都可以做到当有进程挂掉，或者新的进程加入时，作业不会暂停或者重启，而是平滑地继续。而弹性调度是由分布式框架和分布式操作系统（集群管理系统）一起实现的。比如，当有进程挂掉的时候，分布式框架应该通知集群管理系统新启进程来补位 —— 至于集群管理系统能不能启动起来，取决于用户剩余 quota 和集群的忙碌情况。\n1. 基于 Kubernetes-native 通常使用 Keras 的 model-fit API 和 Estimator，开发者只需要调用 API 即可进行分布式训练或预测，然而 ElasticDL 不依赖于 TensorFlow runtime 实现分布式计算，它的实现在 runtime 之外。\nElasticDL 通过 Kubernetes-native 机制来完成分布式计算，而这也为其带来了容错性与弹性调度的能力。\n所谓 Kubernetes-native指的是一个程序调用 Kubernetes API 来起止进程，它与 Google MapReduce 的机制类似。MapReduce 是一个 Borg-native 的分布式计算框架，用户通过运行一个 Borg 客户端程序启动一个 MapReduce 作业；Borg 客户端调用 Borg API 提交作业，并且启动一个 master 进程；这个 master 调用 Borg API 启动其它 workers 进程。\n在 ElasticDL 中，用户调用 ElasticDL 的命令行客户端程序启动作业；这个客户端程序调用Kubernetes API 启动 master 进程，master进程继续调用 Kubernetes API 启动其它进程。\n“ElasticDL 的整个容错和弹性调度机制都依赖于 Kubernetes-native 架构”，王益介绍：“如果 worker 挂了，按照分布式深度学习训练算法的数学特性，可以不用处理，即可确保训练过程继续。如果一个 parameter server 进程挂了，master会选择一个 worker 进程，让它转换角色替补上挂掉的parameter server 进程。”\n在这两种情况下，master 都会调用 Kubernetes API，请它再启动一个额外的 worker 进程。如果启动成功，master 会带其加入到与其它进程的协作中。master 进程的状态（主要是三个 task queues：todo、doing与 done）可以保留在 Kubernetes 集群的 etcd 存储系统中。\n“这样，万一 master 挂了，重启的 master 进程可以从 etcd 继承前世的状态。任何进程挂了，master 都会请 Kubernetes 去启动一个新的进程代替挂掉的进程。而 Kubernetes 是否能完成使命取决于用户剩余 quota 和集群剩余资源情况。”\n2. 基于 TensorFlow 2.0 EagerExecution 为什么 ElasticDL 又基于 TensorFlow 2.0 呢？王益介绍，这是因为 TensorFlow 2.0 带来了 Eager Execution 特性，正是针对这一特性的尝试，让开发团队实现了Kubernetes-native 的调度方式，从而让 ElasticDL 支持容错和弹性调度。\n分布式学习需要了解每个进程根据局部训练数据计算得到的 gradients，才能汇总这些 gradients 来更新模型。\nTensorFlow 1.x 的执行方式被称为 Graph Mode —— 深度学习计算步骤被表示成一个 graph 数据结构，TensorFlow runtime 会解释执行这个 graph。其中，gradients 的计算过程是 graph …","date":1568635200,"description":"业界首个基于 TensorFlow 实现弹性深度学习的开源系统 ElasticDL 项目的技术细节全面介绍。","dir":"blog/alipay-deep-learning-tensorflow-elasticdl/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"74eedc82d0b4a438d332dd5443605318","permalink":"https://sofastack.github.io/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","publishdate":"2019-09-16T20:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","summary":"9 月 11 日，蚂蚁金服在2019谷歌开发者大会上海站上开源了 ElasticDL 项目，这是业界首个基于 TensorFlow 实现弹性深度学习的开源系统。 开源地址为：https://g","tags":["ElasticDL"],"title":"ElasticDL：蚂蚁金服开源基于 TensorFlow 的弹性分布式深度学习系统","type":"blog","url":"/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","wordcount":4705},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n中秋特辑推荐阅读 【中秋特辑】（含视频回顾）SOFAStack 活动回顾整理集合 SOFARegistry 系列解析文章 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 本周发布详情如下：\n发布 SOFARPC v5.6.1，主要变更如下：\n 升级 sofa-bolt 的版本到 1.5.6 修复 com.alipay.sofa.rpc.log.LoggerFactory 提供的 Logger 实现方案在多 classloader 场景下存在会出现类型不匹配的问题 修复 providerInfo 中可能出现的 staticAttrs 空指针问题 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.1\nHey，中秋快乐呀 ","date":1568271600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190913/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"85b998cb10df30ee42c04a8571b73598","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190913/","publishdate":"2019-09-12T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190913/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/9 - 9/13】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190913/","wordcount":423},{"author":"Yavin","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第三篇，本篇作者 Yavin，来自考拉海购。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n导读 集群成员管理是分布式系统中绕不开的话题。MetaServer 在 SOFARegistry 中，承担着集群元数据管理的角色，用来维护集群成员列表。本文希望从 MetaServer 的功能和部分源码切入剖析，为学习研究、或者项目中使用SOFARegistry 的开发者带来一些启发，分为三个部分：\n 功能介绍 内部架构 源码分析 功能介绍 MetaServer 作为 SOFARegistry 的元数据中心，其核心功能可以概括为集群成员管理。分布式系统中，如何知道集群中有哪些节点列表，如何处理集群扩所容，如何处理集群节点异常，都是不得不考虑的问题。MetaServer 的存在就是解决这些问题，其在 SOFARegistry 中位置如图所示： MetaServer 通过 SOFAJRaft 保证高可用和一致性，类似于注册中心，管理着集群内部的成员列表：\n 节点列表的注册与存储 节点列表的变更通知 节点健康监测 内部架构 内部架构如下图所示：\nMetaServer 基于 Bolt, 通过 TCP 私有协议的形式对外提供服务，包括 DataServer, SessionServer 等，处理节点的注册，续约和列表查询等请求。\n同时也基于 Http 协议提供控制接口，比如可以控制 session 节点是否开启变更通知, 健康检查接口等。\n成员列表数据存储在 Repository 中，Repository 被一致性协议层进行包装，作为 SOFAJRaft 的状态机实现，所有对 Repository 的操作都会同步到其他节点, 通过Rgistry来操作存储层。\nMetaServer 使用 Raft 协议保证数据一致性， 同时也会保持与注册的节点的心跳，对于心跳超时没有续约的节点进行驱逐，来保证数据的有效性。\n在可用性方面，只要未超过半数节点挂掉，集群都可以正常对外提供服务， 半数以上挂掉，Raft 协议无法选主和日志复制，因此无法保证注册的成员数据的一致性和有效性。整个集群不可用 不会影响 Data 和 Session 节点的正常功能，只是无法感知节点列表变化。\n源码分析 服务启动 MetaServer 在启动时，会启动三个 Bolt Server，并且注册 Processor Handler，处理对应的请求, 如下图所示：\n DataServer：处理 DataNode 相关的请求； SessionServer：处理 SessionNode 相关的请求； MetaServer：处理MetaNode相关的请求； 然后启动 HttpServer, 用于处理 Admin 请求，提供推送开关，集群数据查询等 Http 接口。\n最后启动 Raft 服务， 每个节点同时作为 RaftClient 和 RaftServer, 用于集群间的变更和数据同步。\n各个 Server 的默认端口分别为：\nmeta.server.sessionServerPort=9610 meta.server.dataServerPort=9611 meta.server.metaServerPort=9612 meta.server.raftServerPort=9614 meta.server.httpServerPort=9615 节点注册 由上节可知，DataServer 和 SessionServer 都有处理节点注册请求的 Handler。注册行为由 Registry 完成。注册接口实现为：\n@Override public NodeChangeResult register(Node node) { StoreService storeService = ServiceFactory.getStoreService(node.getNodeType()); return storeService.addNode(node); } Regitsry 根据不同的节点类型，获取对应的StoreService，比如DataNode，其实现为 DataStoreService 然后由 StoreService 存储到 Repository 中，具体实现为：\n// 存储节点信息 dataRepositoryService.put(ipAddress, new RenewDecorate(dataNode, RenewDecorate.DEFAULT_DURATION_SECS)); //... // 存储变更事件 dataConfirmStatusService.putConfirmNode(dataNode, DataOperator.ADD); 调用 RepositoryService#put 接口存储后，同时会存储一个变更事件到队列中，主要用于数据推送，消费处理。\n节点数据的存储，其本质上是存储在内存的哈希表中，其存储结构为：\n// RepositoryService 底层存储 Map\u0026amp;lt;String/*dataCenter*/, NodeRepository\u0026amp;gt; registry; // NodeRepository 底层存储 Map\u0026amp;lt;String/*ipAddress*/, RenewDecorate\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; nodeMap; 将RenewDecorate存储到该 Map 中，整个节点注册的流程就完成了，至于如何和 Raft 协议进行结合和数据同步，下文介绍。\n节点移除的逻辑类似，将节点信息从该 Map 中删除，也会存储一个变更事件到队列。\n注册信息续约和驱逐 不知道有没有注意到，节点注册的时候，节点信息被 RenewDecorate 包装起来了，这个就是实现注册信息续约和驱逐的关键：\nprivate T renewal; // 节点对象封装 private long beginTimestamp; // 注册事件 private volatile long lastUpdateTimestamp; // 续约时间 private long duration; // 超时时间 该对象为注册节点信息，附加了注册时间、上次续约时间、过期时间。那么续约操作就是修改lastUpdateTimestamp，是否过期就是判 …","date":1568271600,"description":" 本文为《剖析 | SOFARegistry 框架》第三篇，作者 Yavin ，来自考拉海购。","dir":"blog/sofa-registry-metaserver-function-introduction/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6e08281a1d2851d95121fc739cf80669","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","publishdate":"2019-09-12T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","wordcount":3311},{"author":"潘潘","categories":"SOFAStack","content":" SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时任务、限流/熔断框架、动态配置推送、分布式链路追踪、Metrics 监控度量、分布式高可用消息队列、分布式事务框架和分布式数据库代理层等。\nSOFAStack：https://github.com/sofastack\n本文为 SOFAStack 相关线上线下活动的回顾集合，并且会不定时更新。\n/ SOFAChannel 线上直播系列 / SOFAChannel#8 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 视频回顾资料 SOFAChannel#7 自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 视频回顾资料 SOFAChannel#6 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 视频回顾资料 SOFAChannel#5 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 视频回顾资料 SOFAChannel#4 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 视频回顾资料 SOFAChannel#3 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 视频回顾资料 SOFAChannel#2 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 视频回顾资料 SOFAChannel#1 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 视频回顾资料 / SOFAMeetup 系列 / SOFAMeetup#3\u0026amp;lt;广州站\u0026amp;gt; 分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾 视频回顾资料\n 蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾 视频回顾资料\n SOFAMeetup#2\u0026amp;lt;上海站\u0026amp;gt; 当 Spring Cloud 遇上 SOFAStack | Meetup#2 回顾 视频回顾资料\n 基于 SOFAArk 和 SOFADashboard 实现动态模块管控 | Meetup#2 回顾 视频回顾资料\n SOFAMeetup#1\u0026amp;lt;北京站\u0026amp;gt; 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼 视频回顾资料\n 蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼 视频回顾资料\n 详解蚂蚁金服 SOFAJRaft | 生产级高性能 Java 实现 视频回顾资料\n / 技术大会系列 / 2019 年技术大会实录集合 五小时构建云原生电商平台 | KubeCon SOFAStack Workshop 详解\n 蚂蚁金服大规模分布式事务实践和开源历程 | GIAC 实录\n 蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录\n 2018 年技术大会实录集合 企业实施分布式架构的挑战以及应对建议 | 上海 ATEC 大会实录\n 企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录\n Knative：重新定义 Serverless | GIAC 实录\n 蚂蚁金服微服务实践 | 开源中国年终盛典分享实录\n 蚂蚁金服Service Mesh新型网络代理的思考与实践 | GIAC 分享实录\n 蚂蚁金服 Service Mesh 渐进式迁移方案|Service Mesh Meetup 实录\n 蚂蚁金服SOFAMesh在多语言上的实践 | CNUTCon 实录\n 从平台到中台 | Elaticsearch 在蚂蚁金服的实践经验\n 从“挖光缆”到“剪网线”|蚂蚁金服异地多活单元化架构下的微服务体系\n 蚂蚁金服 Service Mesh 实践探索 | Qcon 实录\n ","date":1568260800,"description":"本文为 SOFAStack 相关线上线下活动的回顾集合，并且会不定时更新。","dir":"blog/sofa-activity-retrospect-collection/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b1f0034b1e2c249a33c57be88f5a184c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-activity-retrospect-collection/","publishdate":"2019-09-12T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-activity-retrospect-collection/","summary":"SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时","tags":["SOFAStack"],"title":"（含视频回顾）SOFAStack 活动回顾整理集合","type":"blog","url":"/sofastack.tech/blog/sofa-activity-retrospect-collection/","wordcount":986},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@王冰 提问：\n 请问个问题，SOFATracer 在采样计算时 rootSpan 为什么会计算两次，第一次是生成 span 时，第二次是在上报前又计算了一次？\n A：这种是考虑到产生 span 的逻辑是业务自己来构建，非正常逻辑情况下的一种兼容处理。对于 Tracer 来说，所有的上报是必须 SOFATracer 的行为，因此在 report 之前也会基于当前采样策略计算一次计算。默认情况下产生跟 span 时的计算更多是 span 或者说 span context 的，这个会作为向下透传的。另外产生不一致的情况不会出现，上报那段逻辑会先检查当前 span 的父 span，如果父 span 是 null 也就意味着当前 span 是 root span，所以也必须要计算。\n2、@迟广文 提问：\n 在使用 Seata 的时候，使用了 restful 框架，我的 TCC 调通了，是在接口上加了 @LocalTCC，实现类加 @Component，本以为会冲突，结果没有。\n A：TCC 的代理会代理二种类型的分支：在本地标注为 localTcc，第二种是 RPC 框架（dubbo、sofa-rpc）当 consumer 端使用作为 reference bean 且在 provider 端标注了二阶段注解时，这二种类型时互斥的，一个 TCC 分支只属于其一类型。\nSOFAChannel 回顾集合 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、SOFATracer v2.4.1/v3.0.6 版本发布，主要变更如下：\n 支持自定义埋点 (FlexibleTracer) 支持 Dubbo 2.6.x 日志输出支持非 json 格式(xstringbuilder)\n 支持自定义扩展 Repoter 上报\n Dubbo 2.7.x 系列支持 2.7.3 版本\n 修复 BasePreparedStatement 初始化问题\n 修复 SQLException 被覆盖问题\n 优化常量命名及代码注释等\n 更新案例及官方文档\n 详细发布报告：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v2.4.1\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.0.6\n官方文档：\nhttps://www.sofastack.tech/projects/sofa-tracer/overview/\n2、SOFABoot v3.2.0 版本发布，主要变更如下：\n 升级 sofa-bolt 版本至 1.5.6 根据 Spring Boot 官方文档建议重构工程代码和组织结构 详细发布报告：\nhttps://github.com/sofastack/sofa-boot/releases/tag/v3.2.0\n官方文档：\nhttps://www.sofastack.tech/projects/sofa-boot/overview/\nSOFA 用户召集 如果您已经在生产环境使用了 SOFAStack 相关组件，请在下方链接登记告诉我们，方便我们更好地为您服务，我们将会把您加入到 “SOFAStack金牌用户服务群【邀约制】”里面，以便更加快捷的沟通和更加高效的线上使用问题支持。 https://github.com/sofastack/sofastack.tech/issues/5 已有用户查看： https://www.sofastack.tech/awesome\n","date":1567753200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190906/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"94743dfe34353e1f6910291d127a73d6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190906/","publishdate":"2019-09-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190906/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/2 - 9/6】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190906/","wordcount":1296},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:RegistryLab/\u0026amp;gt;是《剖析 | SOFARegistry 实现原理》系列，会逐步详细介绍 SOFARegistry 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFARegistry SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nSOFARegistry:https://github.com/sofastack/sofa-registry\n| SOFA:RegistryLab 认领列表：\n 【已完成】海量数据下的注册中心 - SOFARegistry 架构介绍 【已完成】SOFARegistry 服务发现优化之路 【已完成】SOFARegistry 数据分片和同步方案详解 【已完成】SOFARegistry MetaServer 功能介绍和实现剖析 【已完成】SOFARegistry Session 存储策略 【已领取】SOFARegistry 如何实现秒级服务上下线通知 【已领取】SOFARegistry 如何实现 DataServer 平滑扩缩容 参与方式：关注「金融级分布式架构」回复可领取的文章标题，会有相关同学联系进行确认。\n 欢迎领取，参与共建~\n","date":1567483200,"description":"","dir":"activities/sofa-registry-lab/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ebbc0e9574d88e21f39926e750c848e9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-registry-lab/","publishdate":"2019-09-03T12:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-registry-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:RegistryLab/\u0026gt;是《剖析 | SOFARegistry 实现原理》系列","tags":["SOFALab","SOFARegistry"],"title":"\u003cSOFA:RegistryLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-registry-lab/","wordcount":435},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFA:Channel/，有趣实用的分布式架构频道。\n本文根据 SOFAChannel#8 直播分享整理，主题：从一个例子开始体验 SOFAJRaft。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23390449，不错过每场直播。\n 大家好，我是力鲲，来自蚂蚁金服， 现在是 SOFAJRaft 的开源负责人。今天分享主题是《从一个例子开始体验 SOFAJRaft》，其实从这个题目大家也能看出来，今天是要从一个用户而非 owner 的视角来了解 SOFAJRaft。这么设计题目的原因是 SOFAJRaft 作为一种共识算法的实现，涉及到了一些概念和术语，而这些内容更适合通过一系列文章进行阐述，而在直播中我们希望能够分享对用户更有用、更容易理解的信息——SOFAJRaft 是什么，以及我们怎么去用它。\n首先介绍一下 SOFAJRaft 的背景知识，接下来说说这个例子源于什么需求，第三部分是架构的选型，第四部分来看看我们如何使用 SOFAJRaft，最后运行代码，看看 SOFAJRaft 是如何支撑业务运行的。\n欢迎加入社区成为 Contributor，SOFAJRaft。\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务； 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\n图1 - 复制状态机\nSOFAJRaft SOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统。\n图2 - SOFAJRaft 结构\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依然用之前的银行账户系统举例来说明 SOFAJRaft 的各模块是如何工作的。\n当 Client 向 SOFAJRaft 发来一个“存 100 元”的命令之后，Node 的 Log 存储模块首先将这个命令以 Log 的形式存储到本地，同时 Replicator 会把这个 Log 复制给其他的 Node，Replicator 是有多个的，集群中有多少个 Follower 就会有多少个 Replicator，这样就能实现并发的日志复制。当 Node 收到集群中半数以上的 Follower 返回的“复制成功” 的响应之后，就可以把这条 Log 以及之前的 Log 有序的送到状态机里去执行了。状态机是由用户来实现的，比如我们现在举的例子是银行账户系统，所以状态机执行的就是账户金额的借贷操作。如果 SOFAJRaft 在别的场景中使用，状态机就会有其他的执行方式。\nSnapshot 是快照，所谓快照就是对数据当前值的一个记录，Leader 生成快照有这么几个作用：\n 当有新的 Node 加入集群的时候，不用只靠日志复制、回放去和 Leader 保持数据一致，而是通过安装 Leader 的快照来跳过早期大量日志的回放； Leader 用快照替代 Log 复制可以减少网络上的数据量； 用快照替代早期的 Log 可以节省存储空间； 图3 - 需要用户实现：StateMachine、Client\nSOFAJRaft 需要用户去实现两部分：StateMachine 和 Client。\n因为 SOFAJRaft 只是一个工具，他的目的是帮助我们在集群内达成共识，而具体要对什么业务逻辑达成共识是需要用户自己去定义的，我们将用户需要去实现的部分定义为 StateMachine 接口。比如账务系统和分布式存储这两种业务就需要用户去实现不同的 StateMachine 逻辑。而 Client 也很好理解，根据业务的不同，用户需要去定义不同的消息类型和客户端的处理逻辑。\n图4 - 需要用户实现一些接口\n前面介绍了这么多，我们引出今天的主题：如何用 SOFAJRaft 实现一个分布式计数器？\n需求 我们的需求其实很简单，用一句话来说就是：提供一个 Counter，Client 每次计数时可以指定步幅，也可以随时发起查询。\n我们对这个需求稍作分析后，将它翻译成具体的功能点，主要有三部分：\n 实现：Counter server，具备计数功能，具体运算公式为：Cn = Cn-1 + delta； 提供写服务，写入 delta 触发计数器运算； 提供读服务，读取当前 Cn 值； 除此之外，我们还有一个可用性的可选需求，需要有备份机器，读写服务不能不可用。\n系统架构 根据刚才分析出来的功能需求，我们设计出 1.0 的架构，这个架构很简单，一个节点 Counter Server 提供计数功能，接收客户端发起的计数请求和查询请求。\n图5 - 架构 1.0\n但是这样的架构设计存在这样两个问题：一是 Server 是一个单点，一旦 Server 节点故障服务就不可用了；二是运算结果都存储在内存当中，节点故障会导致数据丢失。\n图6 - 架构 1.0 的不足：单点\n针对第二个问题，我们优化一下，加一个本地文件存储。这样每次计数器完成运算之后都将数据落盘，当节点故障之时，我们要新起一台备用机器，将文件数据拷贝过来，然后接替故障机器对外提供服务。这样就解决了数据丢失的风险，但是同时也引来另外的问题：磁盘 IO 很频繁，同时这种冷备的模式也依然会导致一段时间的服务不可用。\n图7 - 架构 1.0 的不足：冷备\n所以我们提出架构 2.0，采用集群的模式提供服务。我们用三个节点组成集群，由一个节点对外提供服务，当 Server 接收到 Client 发来的写请求之后，Server 运算出结果，然后将结果复制给另外两台机器，当收到其他所有节点的成功响应之后，Server 向 Client 返回运算结果。\n图8 - 架构 2.0\n但是这样的架构 …","date":1567400400,"description":"本文根据 SOFAChannel#8 直播分享整理，以 Counter 为例，介绍 SOFAJRaft 的概念，并从需求提出开始，一步步完善架构，明确业务要实现哪些接口，最后启动日志观察 SOFAJRaft 如何支撑业务执行。","dir":"blog/sofa-channel-8-retrospect/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7eab29bc73ad095706ad2daef197b1bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-8-retrospect/","publishdate":"2019-09-02T13:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-channel-8-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#8 直播分享整理，主题：从一个例子开始体验 SOFAJRaft。 回顾视频以及 PPT 查看","tags":["SOFAJRaft","SOFAChannel"],"title":"从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-8-retrospect/","wordcount":5541},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@柴炜晨 提问：\n 求问下 SOFAJRaft rhea split 后，原片1 [0,100) 分裂为 1 [0, 50) , 新片 2[50, 100)，新片 2 上的初始数据是从怎么来的呢？\n A：一个 store 里的所有 region 实际上是共享一个存储，split 只是新增一个逻辑 region 并修改被分裂的和新 region 的 range，后续的 snoapshot ，副本迁移等就均以新的 region 为最小单位了。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、关于 SOFARegistry 的几个问题：\n@虞家成 提问：\n 服务 Sub 数据的一致性问题，其中主要的机制是通过 client, session 对缓存的逐级回放和比对，再加上版本号机制来实现最终一致性，问题是：这个版本号的生成，与递增是由谁来管理与维护？client? session? 还是 data ?\n A：这个版本号主要是在 data 上产生，版本号和最终写入内存时间戳关联产生，所有数据是指服务发布数据保证一致性。\n 对于每条服务的 Pub 数据，是否需要维护一个 ttl 值，否则在某些情况下，这条数据不能释放？\n A：如果你说的 ttl 值是指 pub 数据的生存时间，是有的，我们 pub 数据会有租约机制进行定时更新保证一致性，如果过期会进行清理释放。\n Data 节点是通过广播的方式来通知每个 session 节点？那每个 session 节点是否会存在所有服务的全量 Pub 数据？ 这对内存及网络资源消耗会不会过大？\n A：Data 是通过广播方式通知每个 session 节点，session上有订阅关系按照自己订阅关系判断是否需要推送给客户端。每个 session 没有全量的 pub 数据，但会存在和其连接部分客户端发布数据作为一致性备份回放使用。这个堆内存目前看压力还是可以的。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n3、@黄剑 提问：\n 关于 Seata 有一个问题，全局锁用进去之后，意思就是要等 2 阶段完成后，进行当前资源释放，全局锁那边的接口才进行调用到，如果业务有很多地方都操作到相同表的某一条数据，那岂不是每个业务上面加全局锁？可是我并不知道哪些业务可能会有冲突的哇！\n A：目前只查锁不加锁。\n 我需要查到最终 2 阶段的那张表数据，意思自己的业务上面全部都要使用 @GlobalLock 注解？是这个意思么？\n A：如果你查询的业务接口没有 GlobalTransactional 包裹，也就是这个方法上压根没有分布式事务的需求，这时你可以在方法上标注 @GlobalLock 注解，并且在查询语句上加 for update。如果你查询的接口在事务链路上外层有 GlobalTransactional 注解，那么你查询的语句只要加 for update 就行。设计这个注解的原因是在没有这个注解之前，需要查询分布式事务读已提交的数据，但业务本身不需要分布式事务。若使用 GlobalTransactional 注解就会增加一些没用的额外的 rpc 开销比如 begin 返回 xid，提交事务等。GlobalLock 简化了 rpc 过程，使其做到更高的性能。\n 好的，感谢回复，因为现在出现了一个业务，但是不同接口，上游有全局事务来调用，然后又有其他业务操作了相同的表，所以现在导致我现在根本不知道哪些业务要考虑使用 GlobalLock。\n Seata：https://github.com/seata/seata\n本周推荐阅读 Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录 Service Mesh 发展趋势：云原生中流砥柱 SOFA 项目进展 本周发布详情如下：\n发布 SOFA Mosn v0.7.0，主要变更如下：\n 新增 FeatureGates 的支持 新增一项 Metrics 统计:mosn_process_time 支持 Listener 重启 升级 Go 版本到 1.12.7 修改 XDS Client 启动时机，优先于 MOSN Server 的启动 BUG 修复 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/0.7.0\n","date":1567148400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190830/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"afd535d1a14ed1fc010e93bcff36553d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190830/","publishdate":"2019-08-30T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190830/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/26 - 8/30】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190830/","wordcount":1599},{"author":"敖小剑","categories":"Service Mesh","content":" 敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。\n本文内容整理自 8 月 11 日 Service Mesher Meetup 广州站主题演讲，完整的分享 PPT 获取方式见文章底部。\n 前言 标题“Service Mesh发展趋势(续)”中的“续”是指在今年5月底，我在 CloudNative Meetup上做了一个“Service Mesh发展趋势：云原生中流砥柱”的演讲，当时主要讲了三块内容：Service Mesh 产品动态、发展趋势、与云原生的关系。后来有同学反应希望部分感兴趣的内容能讲的更深一些，所以今天将继续“Service Mesh 发展趋势”这个话题。\n今天给大家分享的内容有部分是上次演讲内容的深度展开，如社区关心的 Mixer v2 以及最近看到的一些业界新的技术方向，如 web assembly 技术，还有产品形态上的创新，如 google traffic director 对 Service Mesh 的虚拟机形态的创新支持。\n在 Service Mesh 出道四年之际，也希望和大家一起带着问题来对 Service Mesh 未来的发展进行一些深度思考。\n在正式开始分享之前，让我们先轻松一下，下面是最近流行的梗，各种灵魂拷问：\n我们今天的分享内容，将效仿上面的方式，对 Servic Mesh 进行四个深入灵魂的拷问。\nService Mesh 灵魂拷问一：要架构还是要性能？ 第一个灵魂拷问针对 Istio 的：要架构还是要性能？\nIstio 的回答：要架构 Istio 的回答很明确：架构优先，性能靠边。\n左边是 Istio 的架构图，从 2017 年的 0.1 版本开始，一直到 Istio1.0，控制平面和数据平面完全物理分离，包括我们今天要关注的 Mixer 模块。Sidecar 通过和 Mixer 的交互实现策略检查和遥测报告。\n右边是 Mixer 的架构图，在 Mixer 内部提供了很多 Adapter 实现，用来提供各种功能。这些 Adapter 运行在 Mixer 进程中，因此被称为进程内适配器（In-Process Adapter）。\n为什么 Istio 选择 Mixer 和 Proxy 分离的架构？\n我们先来看这个架构的优点，概括地说优点主要体现为：\n 架构优雅 职责分明 边界清晰 特别指出，上图右侧的红色竖线，是 Istio0.1 到 Istio1.0 版本中 Istio 和后台基础设施的边界。这意味着，从 k8s API Server 中读取 Adapter 相关的配置信息 （以 Istio CRD 的形式存在），是作为 Istio 功能的一部分。\n具体的优点是：\n Mixer 的变动不影响 Sidecar：包括 Mixer 的部署调整和版本升级； Sidecar 无需和 Adapter 耦合，具体有： Sidecar 不需要读取配置，因此也无需直接连接到 k8s AP Server/Istio Galley； Adapter 的运行时资源开销和 Sidecar 无关； Sidecar 不受 Adapter 增减/更新/升级影响； 保持 Sidecar 代码简单：数以几十计的 Adapter 的代码无需直接进入 Sidecar 代码； 数据平面可替换原则：如果有替换数据平面的需求，则 Mixer 分离的架构会让事情简单很多； 至于缺点，只有一个：性能不好。\n而 1.1 版本之后，Istio 给出了新的回答：架构继续优先，性能继续靠边。\n上图是 Istio1.1 版本之后新的架构图，和之前的差异在于 Mixer 发生了变化，增加了进程外适配器（Out-of-Process Adapter），而 Mixer 和新的 Out-of-Process Adapter 之前依然是远程调用。\n为什么 Istio 改而选择 Out-of-Process Adapter?\n下图是采用 Out-of-Process Adapter 之后的请求处理流程图，Mixer 通过 Bypass Adapter 选择需要的属性列表，然后通过远程调用发送给 Out-of-Process Adapter。Out-of-Process Adapter 实现和之前的 In-Process Adapter 类似的功能，但是改为独立于 Mixer 的单独进程。\n采用 Out-of-Process Adapter 之后，Istio 的优点更加明显了，简单说就是：架构更优雅，职责更分明，边界更清晰。\n而且，请注意：按照 Istio 的设想，此时 Out-of-Process Adapter 已经不再作为 Istio 的组成部分，它的代码实现、安装部署、配置、维护等职责也不再由 Istio 承担，请留意上图中的红色竖线位置。Out-of-Process Adapter 的引入，对于 Istio 来说职责和边界的改变会让 Istio 简单，但是对于使用者（主要指运维）来说则增加了额外的负担，因此造成了很大的争议。\n至于缺点，除了上述的职责转移造成争议外，依然只有一个：性能不好，原来 Sidecar 和 Mixer 之间的远程调用已经让性能变得非常糟糕，现在 Mixer 和 Out-of-Process Adapter 之间再增多加一次远程调用，可谓雪上加霜。\nMixer v1 架构的优缺点分析 Mixer v1 架构的优点主要体现为：\n 集中式服务：提高基础设施后端的可用性，为前置条件检查结果提供集群级别的全局 2 级缓存； 灵活的适配器模型，使其以下操作变得简单： 运维添加、使用和删除适配器； 开发人员创建新的适配器（超过20个适配器）； 而 Mixer v1 架构的缺点，则主要体现为：\n 管理开销： 管理 Mixer 是许多客户不想负担的； 而进程外适配器强制运维管理适配器，让这个负担更加重； 性能： 即使使用缓存，在数据路径中同步调用 Mixer 也会增加端到端延迟； 进程外适配器进一步增加了延迟； 授权和认证功能是天然适合 mixer pipeline 的，但是由于 mixer 设计的延迟和 SPOF（单点故障）特性，导致直接在 Envoy 中实现(Envoy SDS)； 复杂性： Mixer 使用一组称为模板的核心抽象，来描述传递给适配器的数据。这些包括“metrics”，“logentry”，“tracepan”等。这些抽象与后端想要消费的数据不匹配，导致运维需要编写一些手动配置，以便在规范的 Istio 样式和后端特定的样式之间进行映射。原本期望这种映射可以在适配器中实现很大程度上的自动化，但是最终还是太复杂并需要手动配置。 备注：上述优点和缺点的描述摘录自 mixer v2 proposal 。\n 其中，Mixer 性能问题一直以来都是 Istio 最被人诟病的地方。\n那问题来了：如果要性能，该怎么做？\n下图是 Mixer v1 的调用流程，Proxy/Sidecar 是请求数据的起点，Infrastructure Backend 是终点。Mixer v1 …","date":1566972000,"description":"继续探讨 Service Mesh 发展趋势：深度分析 Istio 的重大革新 Mixer v2，Envoy 支持 Web Assembly 的意义所在；深入介绍 Google Traffic Director 对虚拟机模式的创新支持方式，以及最近围绕 SMI 发生的故事。","dir":"blog/service-mesh-development-trend-2/","fuzzywordcount":8100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"51e4af6a0771823fe055c5aebd2e76bd","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-development-trend-2/","publishdate":"2019-08-28T14:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/service-mesh-development-trend-2/","summary":"敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。 本文内容整理","tags":["Service mesh"],"title":"Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-development-trend-2/","wordcount":8088},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@廖春涛 提问：\n 在 SOFAJRaft 中，snapshot load 后应该会有个日志重放的实现，但是我目前看代码没看到说 snapshot 和 LogEntry 有关联的地方，请问是什么关系呢？\n A：snapshot 就是为了压缩日志，以及加快新节点加入。snapshot 后，会将上上次的 snapshot 当时对应的日志级之前的删掉，为什么是上上次？ 因为本次 snapshot 的日志，可能还没有复制到所有 follower，这是一个小优化。 具体到日志重放，如果启动是 leader，会写入一条当前配置的日志，触发 fsm caller 的 onCommitted，然后去重放从 snapshot 的日志到最新的 committed 的日志到状态机。如果是 follower，安装 snapshot 后， leader 会发送该 snapshot 对应的日志之后的日志，走正常的复制流程，因此也会重放到最新的状态机。\n SOFAJRaft 当 Leader 的 Node 执行 apply 后，将 LogEntry 提交给 follower 是通过通知来进行的吗？是不是在 LogManagerImpl 里面的这串代码 A：这段是 wakeup replicators，复制日志到 follower 都是在 Replicator 中实现的。\n2、关于 Seata 的 grouplist 问题：\n 什么时候会用到 file.conf 中的 default.grouplist？\n A：当 registry.type=file 时会用到，其他时候不读。\n default.grouplist 的值列表是否可以配置多个？\n A：可以配置多个，配置多个意味着集群，但当 store.mode=file 时，会报错。原因是在 file 存储模式下未提供本地文件的同步，所以需要使用 store.mode=db，通过 db 来共享 TC 集群间数据\n 是否推荐使用 default.grouplist？\n A：不推荐，如问题1，当 registry.type=file 时会用到，也就是说这里用的不是真正的注册中心，不具体服务的健康检查机制当tc不可用时无法自动剔除列表，推荐使用 nacos 、eureka、redis、zk、consul、etcd3、sofa。registry.type=file 或 config.type=file 设计的初衷是让用户再不依赖第三方注册中心或配置中心的前提下，通过直连的方式，快速验证 Seata 服务。\n3、关于 Seata 事务分组：\n 什么是事务分组？\n A：事务分组是 Seata 的资源逻辑，类似于服务实例。在 file.conf 中的 my_test_tx_group 就是一个事务分组。\n 通过事务分组如何找到后端集群？\n A：首先程序中配置了事务分组（GlobalTransactionScanner 构造方法的 txServiceGroup 参数），程序会通过用户配置的配置中心去寻找 service.vgroup_mapping. 事务分组配置项，取得配置项的值就是 TC 集群的名称。拿到集群名称程序通过一定的前后缀+集群名称去构造服务名，各配置中心的服务名实现不同。拿到服务名去相应的注册中心去拉取相应服务名的服务列表，获得后端真实的 TC 服务列表。\n 为什么这么设计，不直接取服务名？\n A：这里多了一层获取事务分组到映射集群的配置。这样设计后，事务分组可以作为资源的逻辑隔离单位，当发生故障时可以快速 failover。\nSOFA 项目进展 本周发布详情如下：\n1、发布 Seata v0.8.0 版本，主要变更如下：\n 支持 oracle 数据库的 AT 模式 支持 oracle 数据库的批量操作 支持 undo_log 表名可配置 修复 xid 在 db 模式可重复的问题 优化数据镜像比对日志 详细参考发布报告：https://github.com/seata/seata/releases/tag/v0.8.0\n2、发布 SOFAARK v1.0.0 版本，主要变更如下：\n 支持插件批量导出资源和 ark-biz 禁止批量导入资源 支持指定版本调用，解决对于非激活状态的ark-biz服务访问问题（主要用于灰度验证，测试等） 支持打包时跳过打ark-executable 包的过程（优化） 支持从目录运行启动 ArkClient api 支持指定 biz 的 arguments 参数 使用 netty 代替 java NIO 实现 telnet server 支持 SpringBoot testNG 优化示例工程 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.0.0 SOFA 活动推荐 SOFA:Channel/线上直播第 8 期报名中~ 8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。\n 本期主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft 直播时间：8 月 29 日下周四晚 7点 你将收获： 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 报名方式：点击“这里” 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可） ","date":1566543600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190823/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"067db1c93be21087cc809be0294c1b32","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190823/","publishdate":"2019-08-23T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190823/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/19 - 8/23】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190823/","wordcount":1855},{"author":"苟利","categories":"SOFAMeetup","content":" 作者：苟利（陈自欣），蚂蚁金服中间件产品专家， 负责蚂蚁金服分布式链路跟踪系统的产品化工作，在日志分析、监控领域有多年工作经验。\n本文根据 8 月 11 日 SOFA Meetup#3 广州站 《蚂蚁金服在云原生架构下的可观察性的探索和实践》主题分享整理。现场回顾视频以及 PPT 查看地址见文末链接。\n前言 随着应用架构往云原生的方向发展，传统监控技术已经不能满足云原生时代运维的需求，因此，可观察性的理念被引入了 IT 领域。\n下面我将会就可观察性在云原生的起源，可观察性发展动力， 可观察性与监控的关系，可观察性的三大支柱，社区发展方向及产品现状，以及蚂蚁金服对相关问题的理解及实践进行探讨。\n才疏学浅，欢迎拍砖。\n为什么云原生时代需要可观察性 可观察性的由来 在云原生语境下的可观察性这个词，最早出现于2017年7月， Cindy Sridharan 在 Medium 写的一篇博客， \u0026amp;ldquo;Monitoring and Observability\u0026amp;ldquo;，谈到了可观察性与云原生监控的关系。\n而在2017年10月， 来自 Pivotal 公司的 Matt Stine，在接受 InfoQ 采访的时候，对云原生的定义进行了调整， 将Cloud Native Architectures 定义为具有以下六个特质：\n 模块化 （Modularity） (通过微服务) 可观察性 （Observability） 可部署性 （Deployability） 可测试性 （Testability） 可处理性 （Disposability） 可替换性 （Replaceability） 可见，在2017年下半年， 可观察性成为了一个 buzzword（时髦词） ，正式出现在了云计算领域。\n可观察性的定义 虽然“可观察性”这个词在 IT 行业是一个新的术语，但它其实是在上世纪60年代，由匈牙利裔工程师鲁道夫·卡尔曼提出的概念。\n术语“可观察性”，源于控制论，是指系统可以由其外部输出推断其内部状态的程度。\n这个外部输出， 在云原生的语境下，即 Telemetry ，遥测，通常由服务（services）产生，划分为三个维度或者说支柱， Tracing（跟踪），Metrics（指标） , Logging（日志）。\n为什么云原生需要可观察性 近年可以看到，云计算对基础架构改变甚为巨大，无论是互联网行业，还是传统行业，云化在提升资源利用率，提高业务敏捷性的价值已经成为了公式。而在应用层面，由于业务特性的原因，互联网公司大部分已经完成云化，应用架构也不同程度上，完成了从单体应用向微服务应用演进。 在转型后，整体系统复杂性大大增加，倒逼相应的工具及方法论进行升级改造， 去 hold 住这么复杂的局面。\n上图为 Uber 展示的总体调用链图。考虑到业务多样性及复杂度，在蚂蚁金服内部，相关调用关系只会更为复杂，用人类的智力，已经没有办法去理解如此复杂的调用关系。而上图只是展示了可观察性的链路调用， 如果再加上指标及日志， 不对工具及方法论进行革新， 是难以实现对复杂微服务架构的管控的。\n微服务只是云原生的模块化特性的体现， 再考虑到近年被广泛应用容器，Kubernetes , 以及大家关注度极高的 Service Mesh , Istio， 每一个新的技术的出现，在带来了更优雅的架构、更灵活的调度、更完善的治理的同时，也带来更多新的复杂性。\n因此，可观察性对于云原生的应用架构，是必不可少的特性。\n可观察性和传统监控的区别 说半天，不少同学就会说，这个可观察性与我们谈的最多的监控有什么区别。 虽然有不少的人认为， 这词就是个buzzword，就是赶时髦的，没有太大的意义， 但是我结合网上的讨论， 个人认为可观察性与监控， 含义上虽然接近，但是也有一些理念上的差别，使得讨论可观察性这个词，是有具有现实意义，并能真正产生相应的价值。\n 监控更多关注的是基础设施，更多与运维工程师相关，更强调是从外部通过各种技术手段去看内部，打开黑盒系统。 可观察性更多的是描述应用，在我们谈论具体某应用，或者是某些应用是否具备客观性的时候，通常与开发人员相关，因为在常见的可观察性的实践之中，开发人员需要在应用的开发过程中嵌入例如 statd 或者是 opentracing，或者是 opencensus 等所提供的库，对相关的 telemetry 进行输出，或者是俗话说的埋点。通过埋点，将服务内部的状态白盒化，使得其在运维阶段具备可观察性。某种程度上可以说，可观察性遵循了 DevOps 及 SRE 的理念，即研发运维一体化，从开发侧就考虑系统的可运维性。  这里值得补充说明的是，目前市面上，有商用或者开源APM 方案，通过入侵 JVM 或者其他技术手段，对应用进行自动埋点的，输出 trace 及 metrics 信息。 这同样也是一种可观察性的实现方式，这样做的最大的好处是，不需要对现有的应用进行改造，但是相应的 agent 对应用进行实时的监控， 必然会或多或少的增加资源的占用，例如每实例额外 30+MB 内存，5~10% 的 CPU 占用，在大规模的运行环境之中， 会有不少的成本增加。\n可观察性的三大支柱及社区进展 可观察性的三大支柱 可观察性的三大支柱及其之间的关系， Peter Bourgon 在2017年2月撰写了一篇简明扼要的文章， 叫 \u0026amp;ldquo;Metrics, tracing, and logging\u0026amp;rdquo; ， 有兴趣的可以去看一下， 以下仅为简单的提及。\n指标数据（Metrics Data） 描述具体某个对象某个时间点的值。在 Prometheus 中， 指标有四种类型，分别 Counter（计数器）、Gauge（瞬时值）、Histogram（直方图）和 Summary （概要）， 通过这四种类型，可以实现指标的高效传输和存储。\n日志数据 ( Logging Data） 描述某个对象的是离散的事情，例如有个应用出错，抛出了 NullPointerExcepction，或者是完成了一笔转账，个人认为 Logging Data 大约等同于 Event Data，所以告警信息在我认为，也是一种 Logging Data。 但是也有技术团队认为，告警应该算是可观察性的其中一个支柱。 跟踪数据（Tracing Data） Tracing Data 这词貌似现在还没有一个权威的翻译范式，有人翻译成跟踪数据，有人翻译成调用数据，我尽量用Tracing 这个词。 Tracing 的特点就是在单次请求的范围内处理信息，任何的数据、元数据信息都被绑定到系统中的单个事务上。 一个Trace 有一个唯一的Trace ID ，并由多个Span 组成。\n社区方案进展 由于可观察性在云原生中，是一个非常重要的特性， 因此，在开源世界中，先后出现了两个定位都比较类似的项目，分别是源自 Google 的 OpenCensus （定位上报 Tracing + metris） 和由 CNCF 孵化的 OpenTracing（定位上报 Tracing）。 两者都定位于提供厂商中立的技术规范，及实现该规范各种编程语言遥测库，使得用户在使用了相关的库以后，可 …","date":1566381600,"description":"本文根据 8 月 11 日 SOFA Meetup#3 广州站 《蚂蚁金服在云原生架构下的可观察性的探索和实践》主题分享整理，文中包含本次分享视频回顾以及 PPT 查看地址。","dir":"blog/sofa-meetup-3-cloud-original-retrospect/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"85eba21fd9adf73841d7b7ee103723ae","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","publishdate":"2019-08-21T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","summary":"作者：苟利（陈自欣），蚂蚁金服中间件产品专家， 负责蚂蚁金服分布式链路跟踪系统的产品化工作，在日志分析、监控领域有多年工作经验。 本文根据 8 月 11","tags":["SOFAMeetup"],"title":"蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","wordcount":4758},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n本周推荐阅读 分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾 中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说 溢米教育推荐平台的效率与稳定性建设 | SOFAStack 用户说 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.2.6, 主要变更如下： - i. 修复 ReadIndex 并发情况下可能出现的读超时 - ii. 保存 raft meta 失败后终止状态机 - iii. 增加 LogEntry checksum validation - iv. 优化 log replication 线程模型减少锁竞争 - v. 优化 RheaKV multi group snapshot - vi. 致谢（排名不分先后）@SteNicholas @zongtanghu\n详细参考发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.2.6\nSOFA 活动推荐  SOFA:Channel/线上直播第 8 期《从一个例子开始体验 SOFAJRaft》报名中~\n8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。 在本次直播中，我们将重点放在如何去使用这个工具上，用示例来说明如何使用 SOFAJRaft 实现自己的分布式应用。在此过程中，我们会对涉及到的一些 SOFAJRaft 经典概念进行讲解。\n| 点击“这里”即可报名\n| 本期将带来：\n 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可）\n","date":1565942400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190816/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"277754f72430d4473dc3920edbaf2ddb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190816/","publishdate":"2019-08-16T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190816/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/12 - 8/16】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190816/","wordcount":724},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft\n 活动时间：8 月 29 日周四晚 7 点\n 活动形式：线上直播\n 视频回顾：https://tech.antfin.com/community/live/821\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#8：从一个例子开始体验 SOFAJRaft SOFAJRaft 是 Raft 算法的 Java 实现，其本质是一个工具项目。在本次直播中，我们将重点放在如何去使用这个工具上，用示例来说明如何使用 SOFAJRaft 实现自己的分布式应用。在此过程中，我们会对涉及到的一些 SOFAJRaft 经典概念进行讲解。\n为了更好地直播体验，可以在直播前，预习 SOFAJRaft 相关源码解析文章，文章集合：https://www.sofastack.tech/tags/sofajraft/\n8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/737\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 SOFAChannel#8：从一个例子开始体验 SOFAJRaft 力鲲 SOFAJRaft 开源负责人\n本期分享大纲： 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 嘉宾 SOFAGirl 主持人 力鲲 SOFAJRaft 开源负责人 ","date":1565842200,"description":"8 月 29 日周四晚 7 点，线上直播第 8 期。","dir":"activities/sofa-channel-8/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"92590333a35992bc201c798645cbf7ea","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-8/","publishdate":"2019-08-15T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-8/","summary":"概要 活动主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft 活动时间：8 月 29 日周四晚 7 点 活动形式：线上直播 视频回顾：https://tec","tags":["SOFAChannel","SOFAJRaft"],"title":"SOFAChannel#8：从一个例子开始体验 SOFAJRaft","type":"activities","url":"/sofastack.tech/activities/sofa-channel-8/","wordcount":561},{"author":"屹远","categories":"Seata","content":" 作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。 本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，着重分享分布式事务产生的背景、理论基础，以及 Seata 分布式事务的原理以及三种模式（AT、TCC、Saga）的分布式事务实现。\n本次分享的视频回顾以及 PPT 查看地址：https://tech.antfin.com/community/activities/779/review\n一、分布式事务产生的背景 1.1 分布式架构演进之 - 数据库的水平拆分 蚂蚁金服的业务数据库起初是单库单表，但随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。所以我们对数据库进行了水平拆分，将原单库单表拆分成数据库分片。\n如下图所示，分库分表之后，原来在一个数据库上就能完成的写操作，可能就会跨多个数据库，这就产生了跨数据库事务问题。\n1.2 分布式架构演进之 - 业务服务化拆分 在业务发展初期，“一块大饼”的单业务系统架构，能满足基本的业务需求。但是随着业务的快速发展，系统的访问量和业务复杂程度都在快速增长，单系统架构逐渐成为业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。\n如下图所示，蚂蚁金服按照面向服务架构（SOA）的设计原则，将单业务系统拆分成多个业务系统，降低了各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。\n业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，如何保证多个服务间的数据一致性成为一个难题。\n二、分布式事务理论基础 2.1 两阶段提交协议 两阶段提交协议：事务管理器分两个阶段来协调资源管理器，第一阶段准备资源，也就是预留事务所需的资源，如果每个资源管理器都资源预留成功，则进行第二阶段资源提交，否则协调资源管理器回滚资源。\n2.2 TCC TCC（Try-Confirm-Cancel） 实际上是服务化的两阶段提交协议，业务开发者需要实现这三个服务接口，第一阶段服务由业务代码编排来调用 Try 接口进行资源预留，所有参与者的 Try 接口都成功了，事务管理器会提交事务，并调用每个参与者的 Confirm 接口真正提交业务操作，否则调用每个参与者的 Cancel 接口回滚事务。\n2.3 Saga Saga 是一种补偿协议，在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。\n分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。\nSaga 理论出自 Hector \u0026amp;amp; Kenneth 1987发表的论文 Sagas。\nSaga 正向服务与补偿服务也需要业务开发者实现。\n三、Seata 及其三种模式详解 3.1 分布式事务 Seata 介绍 Seata（Simple Extensible Autonomous Transaction Architecture，一站式分布式事务解决方案）是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。Seata 开源半年左右，目前已经有超过 1.1 万 star，社区非常活跃。我们热忱欢迎大家参与到 Seata 社区建设中，一同将 Seata 打造成开源分布式事务标杆产品。\nSeata：https://github.com/seata/seata\n3.2 分布式事务 Seata 产品模块 如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。\n在 Seata 中，分布式事务的执行流程：\n TM 开启分布式事务（TM 向 TC 注册全局事务记录）； 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）； TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）； TC 汇总事务信息，决定分布式事务是提交还是回滚； TC 通知所有 RM 提交/回滚 资源，事务二阶段结束； 3.3 分布式事务 Seata 解决方案 Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。\n3.3.1 AT 模式 今年 1 月份，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。\nAT 模式如何做到对业务的无侵入 ： 一阶段： 在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。\n 二阶段提交： 二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。\n 二阶段回滚： 二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。\nAT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。\n3.3.2 TCC 模式 2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。\nTCC 三个方法描述：\n Try：资源的检测和预留； Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功； Cancel：预留资源释放； 蚂蚁金服在 TCC 的实践经验\n1 TCC 设计 - 业务模型分 2 阶段设计：\n用户接入 TCC ，最重要的是考虑如何将自己的业务模型拆成两阶段来实现。\n以“扣钱”场景为例，在接入 TCC 前，对 A 账户的扣钱，只需一条更新账户余额的 SQL 便能完成；但是在接入 TCC 之后，用户就需要考虑如何将原来一步就能完 …","date":1565776800,"description":"本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，文中包含本次分享视频回顾以及 PPT 查看地址。","dir":"blog/sofa-meetup-3-seata-retrospect/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"841ac02b2ce20e10748bf97db9d644ec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","publishdate":"2019-08-14T18:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","summary":"作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。 本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，着重分享分布式事务","tags":["Seata","SOFAMeetup"],"title":"分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","wordcount":5793},{"author":"胡宗棠","categories":"SOFAJRaft","content":" 文章摘要：BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云服务中的最佳应用实践。\n前言： 高可用的定义，指的是“一个系统经过特有的设计与改造，减少因不确定故障停服的时间，从而对业务使用方来说可以保证其服务的高度可用性”。在生产环境中，往往会存在很多不可预知的故障因素，比如虚拟机宕机、磁盘损坏和网络故障等，因此系统自身的高可用是任何工业级产品所需重点考虑的因素。\n对于消息队列服务来说，考虑到故障切换和业务感知等问题，传统的高可用方式（冷备或者热备）一般都不太适用。在经过多种技术方案对比后，我们发现采用基于 Raft 共识算法的多副本设计方案可以满足我们产品的要求，因此在鉴权认证组件和API计量服务组件中，我们集成了蚂蚁金服开源的 SOFAJRaft 库，实现这两个组件应对单点故障的高可用。\nGitHub 地址：https://github.com/sofastack/sofa-jraft\n一、背景知识：Raft 共识性算法是什么？ Raft 是一种分布式系统中易于理解的共识算法，该协议本质上是 Paxos 算法的精简版，而不同的是依靠 Raft 模块化的拆分以及更加简化的设计，其实现起来更加容易和方便。[1]\n模块化的拆分主要体现在 Raft 把一致性协议划分为如下几部分：\n Leader 选举； Membership 变更； 日志复制； Snapshot。 而更加简化的设计则体现在：Raft 不允许类似 Paxos 中的乱序提交、简化系统中的角色状态（算法定义 Leader、Follower 和 Candidate 三种角色）、限制仅 Leader 可写入、采用随机超时触发 Leader Election 机制来避免“瓜分选票”等等。[2]\n1.1 Raft 算法的整体结构概览 从上面的 Raft 算法整体结构图中可以看出，整个分布式系统中同一时刻有且仅有一个 Leader 角色的节点（如图最右边的服务器），只有 Leader 节点可以接受 Client 发送过来的请求。Leader 节点负责主动与所有 Follower 节点进行网络通信（如图左边两个服务器），负责将本地的日志发送给所有 Follower 节点，并收集分布式系统中多数派的 Follower 节点的响应。此外，Leader 节点，还需向所有 Follower 节点主动发送心跳维持领导地位（即：保持存在感）。\n所以，只要各个节点上的日志保持内容和顺序是一致的，那么节点上的状态机就能以相同的顺序执行相同的命令，这样它们执行的结果也都是一样的。\n1.2 Raft 算法的三种角色及转换 Follower：完全被动，不能发送任何请求，只接受并响应来自 Leader 和 Candidate 的 Message，每个节点启动后的初始状态一般都是 Follower； Leader：处理所有来自客户端的请求、复制 Log 到所有 Follower，并且与 Follower 保持心跳请求； Candidate：节点竞选 Leader 时的状态。Follower 节点在参与选举之前，会将自己的状态转换为 Candidate。 1.3 任期与逻辑时钟概念 时间被划分为多个任期 term（如同总统选举一样），term id 按时间轴单调递增； 每一个任期开始后要做的第一件事都是选举 Leader 节点，选举成功之后，Leader 负责在该任期内管理整个分布式集群，“日志复制”、“通过心跳维护自己的角色”； 每个任期至多只有一个 Leader 节点，也可能没有 Leader (由于“分票”导致)。 1.4 Raft 算法的实际应用实现 目前，Raft 算法已经成熟地应用于诸多知名的开源项目中。业界非常著名的 Etcd(Kubernetes 高可用强一致性的服务发现组件)和 TiKV (高性能开源 KV 存储)均是 Raft 算法的实现。\n二、BC-MQ 基于 Raft 的高可用设计 为满足企业上云和构建万物相连的物联网业务需求，中国移动苏州研发中心结合自身在云计算产品和技术的较多积累，研发了大云消息队列中间件产品 BC-MQ。该产品基于 Apache 开源社区的 RocketMQ 内核，同时结合云端 PAAS 产品架构和消息中间件的应用业务需求进行深度优化和定制化的研发，提供了一款可以满足于云端场景的高性能、高可靠、低延迟和高可用的工业级产品。\n本节从解决原有高可用技术方案的问题视角出发，同时结合选型 SOFAJRaft 库的缘由，将详细阐述 BC-MQ 产品中的安全认证和 API 计量采集服务的高可用设计方案（注：这里不会涉及到安全认证和 API 计量采集组件本身的技术方案细节）。\n2.1 GlusterFS+Keepalived 高可用方案与问题 1. GlusterFS+Keepalived 高可用设计方案 在BC-MQ原有的方案中，多组安全认证服务各自独立部署组建集群，各个安全认证服务相互独立，没有主从关联，服务本身无状态，可水平任意扩展。安全认证服务的高可用依赖于RPC通信的客户端保证，其主要通过负载均衡算法从安全认证服务集群选择一个节点发送RPC请求来实现租户级鉴权认证元数据的获取。在生产环境中，如果出现其中一个安全认证节点宕机不可用时，客户端的RPC通信层能够及时感知并从本地的Node列表中剔除不可用节点。\n集群中有状态的租户级安全认证元数据的强一致性由GlusterFS分布式文件存储的同步机制来保证。安全认证服务组建高可用集群的具体设计方案图如下所示：\n而 BC-MQ 中 API 计量采集服务组件的高可用性则是依靠 Keepalived 组件的冷备模式结合 GlusterFS 分布式文件存储的同步机制共同保证，从而在一定程度上解决了 API 计量采集服务的单点不可用问题。API 计量采集服务的具体高可用设计方案图如下所示：\n2. GlusterFS+Keepalived 高可用方案遇到的问题 初步看上面的这种高可用技术方案挺完美的。但是经过验证和仔细推敲后就发现在生产环境中可能会存在如下几个问题：\n 上面所述的高可用设计方案中引入了 GlusterFS 分布式文件存储系统和 Keepalived 组件，这增加了系统整体的运维复杂度，给运维人员带来很多人工介入排查和部署的工作负担；另一方面，GlusterFS 和 Keepalived 本身的可靠性、稳定性和性能指标等问题也需要软件研发人员重点关注，这增加了系统整体设计的复杂度； 在实际的生产环境中，Keepalived 组件采用冷备方式作为高可用方案需要考虑主机故障宕机后切换到备机的时间成本消耗。在这段时间内，API 计量服务是短暂不可用的。因此，Keepalived 组件的主备切换会造成业务感知影响，导致一些业务的风险发生。 2.2 基于 SOFAJRaft 库的高可用设计方案 由于“GlusterFS+Keepalived”的高可用方案存在上一节阐述的两个问题，所以我们考虑是否可以采用其他的高可用方案来解决这两个问题？目标：即使生产环境出现部分节点故障后， …","date":1565694000,"description":"BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云服务中的最佳应用实践。","dir":"blog/sofa-jraft-user-china-mobile/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a7eb984bdb11d8c0b47133af4c16f48f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-user-china-mobile/","publishdate":"2019-08-13T19:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-user-china-mobile/","summary":"文章摘要：BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云","tags":["SOFAJRaft"],"title":"中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-user-china-mobile/","wordcount":6179},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n关于 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 的讨论： @龚小涛 提问： \u0026amp;gt; 对于快照部分讲解是对某一刻时间点的数据做的快照吗，然后此快照最新的记录下 logindex term 等信息？\nA：快照里记录的数据不是日志复制的数据，而是状态机执行的结果，这个快照数据保存的动作是由用户通过实现这个接口来实现的： com.alipay.sofa.jraft.StateMachine#onSnapshotSave 。当然，里面的快照里面还包括了一些 index、term 等元信息。所以如果你理解的数据是由状态机执行的结果，那理解是对的。\n 关于快照的解决方案中是对数据集合的快照，这里可以细说下吗？\n A：快照中保存的是用户自定义的状态机的当前的状态，具体内容需要用户自己去实现，你可以看下这个接口： com.alipay.sofa.jraft.StateMachine#onSnapshotSave，比如 Counter 这个 example 中，保存的就是计数器当前的 value。\nSOFAJRaftLab 系列阅读 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n发布 SOFARegistry 5.2.1, 主要变更如下： i. 安全修改，升级 Jettyserver 版本到 9.4.17.v20190418. ii. jraft bug 修正版本到1.2.5 iii. 修复 dataServer 启动没有 working 时刻一些操作延迟处理问题 iv. data 重连 meta 逻辑 bug 导致所有 data 无法连接 meta 修改 v. data 从 working 状态变回 init 状态 bug 修改 详细发布报告： https://github.com/sofastack/sofa-registry/releases/tag/v5.2.1\nSOFA 活动推荐 SOFA Meetup #3《从开源技术到产品能力》，本周日我们在广州等你~\n本期活动将为大家带来蚂蚁金服在这些方面的探索和实践，解析 SOFARPC、分布式事务 Seata、无线自动化测试框架 SoloPi 等开源项目的内部大规模落地和社区发展，并且通过可观察性的理念，实现对微服务，Service Mesh 以至未来的 Serverless 架构的应用进行监控，帮助大家应对从应用架构过渡到云原生架构的挑战。\n报名方式：点击“这里”了解活动详情。\n","date":1565337600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190809/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"31aa100cb2b1edaacaa1874644af50ff","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190809/","publishdate":"2019-08-09T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190809/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/5 - 8/9】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190809/","wordcount":1018},{"author":"力鲲、徐家锋","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第六篇，本篇作者徐家锋，来自专伟信息，力鲲，来自蚂蚁金服。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：\u0026amp;lt;SOFA:JRaftLab/\u0026amp;gt;，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n本文的目的是要介绍 SOFAJRaft 在日志复制中所采用的 pipeline 机制，但是作者落笔时突然觉得这个题目有些唐突，我们不应该假设读者理所应当的对日志复制这个概念已经了然于胸，所以作为一篇解析，我觉得还是应该先介绍一下 SOFAJRaft 中的日志复制是要解决什么问题。\n概念介绍 SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法，就不可避免的要对需要达成共识的内容在多个服务器节点之间进行传输，在 SOFAJRaft 中我们将这些内容封装成一个个日志块 (LogEntry)，这种服务器节点间的日志传输行为在 SOFAJRaft 中也就有了专门的术语：日志复制。\n为了便于阅读理解，我们用一个象棋的故事来类比日志复制的流程和可能遇到的问题。\n假设我们穿越到古代，要为一场即将举办的象棋比赛设计直播方案。当然所有电子通讯技术此时都已经不可用了，幸好象棋比赛是一种能用精简的文字描述赛况的项目，比如：“炮二平五”, “马８进７”, “车２退３”等，我们将这些描述性文字称为棋谱。这样只要我们在场外同样摆上棋盘 (可能很大，方便围观)，通过棋谱就可以把棋手的对弈过程直播出来。\n图1 - 通过棋谱直播\n所以我们的直播方案就是：赛场内两位棋手正常对弈，设一个专门的记录员来记录棋手走出的每一步，安排一个旗童飞奔于赛场内外，棋手每走一步，旗童就将其以棋谱的方式传递给场外，这样观众就能在场外准实时的观看对弈的过程，获得同观看直播相同的体验。\n图2 - 一个简单的直播方案\n这便是 SOFAJRaft 日志复制的人肉版，接下来我们完善一下这个“直播系统”，让它逐步对齐真实的日志复制。\n改进1. 增加记录员的数量 假设我们的比赛获得了很高的关注度，我们需要在赛场外摆出更多的直播场地以供更多的观众观看。\n这样我们就要安排更多的旗童来传递棋谱，场外的每一台直播都需要一个旗童来负责，这些旗童不停的在赛场内外奔跑传递棋谱信息。有的直播平台离赛场远一些，旗童要跑很久才行，相应的直播延迟就会大一些，而有些直播平台离得很近，对应的旗童就能很快的将对弈情况同步到直播。\n随着直播场地的增加，负责记录棋局的记录员的压力就会增加，因为他要针对不同的旗童每次提供不同的棋谱内容，有的慢有的快。如果记录员一旦记混了或者眼花了，就会出现严重的直播事故(观众看到的不再是棋手真正的棋局)。\n图4 - 压力很大的记录员\n为此我们要作出一些优化，为每个场外的直播平台安排一个专门的记录员，这样 “赛局-记录员-旗童-直播局” 就构成了单线模式，专人专职高效可靠。\n图5 - “赛局-记录员-旗童-直播棋局”\n改进2. 增加旗童每次传递的信息量 起初我们要求棋手每走一步，旗童就向外传递一次棋谱。可是随着比赛进行，其弊端也逐渐显现，一方面记录员记录了很多棋局信息没有传递出去，以至于不得不请求棋手停下来等待 (不可思议)；另一方面，场外的观众对于这种“卡帧”的直播模式也很不满意。\n所以我们做出改进，要求旗童每次多记几步棋，这样记录员不会积攒太多的待直播信息，观众也能一次看到好几步，而这对于聪明的旗童来说并不是什么难事，如此改进达到了共赢的局面。\n图6 - 旗童批量携带信息\n改进3. 增加快照模式 棋局愈发精彩，应棋迷的强烈要求，我们临时增加了几个直播场地，这时棋手已经走了很多步了，按照我们的常规手段，负责新直播的记录员和旗童需要把过去的每一步都在直播棋盘上还原一遍(回放的过程)，与此同时棋手还在不断下出新的内容。\n从直觉上来说这也是一种很不聪明的方式，所以这时我们采用快照模式，不再要求旗童传递过去的每一步棋谱，而是把当前的棋局图直接描下来，旗童将图带出去后，按照图谱直接摆子。这样新直播平台就能快速追上棋局进度，让观众欣赏到赛场同步的棋局对弈了。\n图7 - 采用快照模式\n改进4. 每一个直播平台用多个旗童传递信息 虽然我们之前已经在改进 2 中增加了旗童每次携带的信息量，但是在一些情况下(棋手下快棋、直播平台很远等)，记录员依然无法将信息及时同步给场外。这时我们需要增加多个旗童，各旗童有次序的将信息携带到场外，这样记录员就可以更快速的把信息同步给场外直播平台。\n图8 - 利用多个旗童传递信息，实现 pipeline 效果\n现在这个人肉的直播平台在我们的逐步改进下已经具备了 SOFAJRaft 日志复制的下面几个主要特点：\n特点1: 被复制的日志是有序且连续的 如果棋谱传递的顺序不一样，最后下出的棋局可能也是完全不同的。而 SOFAJRaft 在日志复制时，其日志传输的顺序也要保证严格的顺序，所有日志既不能乱序也不能有空洞 (也就是说不能被漏掉)。\n图9 - 日志保持严格有序且连续\n特点2: 复制日志是并发的 SOFAJRaft 中 Leader 节点会同时向多个 Follower 节点复制日志，在 Leader 中为每一个 Follower 分配一个 Replicator，专用来处理复制日志任务。在棋局中我们也针对每个直播平台安排一个记录员，用来将对弈棋谱同步给对应的直播平台。\n图10 - 并发复制日志\n特点3: 复制日志是批量的 SOFAJRaft 中 Leader 节点会将日志成批的复制给 Follower，就像旗童会每次携带多步棋信息到场外。\n图11 - 日志被批量复制\n特点4: 日志复制中的快照 在改进 3 中，我们让新加入的直播平台直接复制当前的棋局，而不再回放过去的每一步棋谱，这就是 SOFAJRaft 中的快照 (Snapshot) 机制。用 Snapshot 能够让 Follower 快速跟上 Leader 的日志进度，不再回放很早以前的日志信息，即缓解了网络的吞吐量，又提升了日志同步的效率。\n特点5: 复制日志的 pipeline 机制 在改进 4 中，我们让多个旗童参与信息传递，这样记录员和直播平台间就可以以“流式”的方式传递信息，这样既能保证信息传递有序也能保证信息传递持续。\n在 SOFAJRaft 中我们也有类似的机制来保证日志复制流式的进行，这种机制就是 pipeline。Pipeline 使得 Leader 和 Follower 双方不再需要严格遵从 “Request - Response - Request” 的交互模式，Leader …","date":1565080200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第六篇，本篇作者徐家锋、力鲲。","dir":"blog/sofa-jraft-pipeline-principle/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c88030d7b6620240943e8326565b0ec2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-pipeline-principle/","publishdate":"2019-08-06T16:30:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-jraft-pipeline-principle/","summary":"SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-pipeline-principle/","wordcount":3903},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@屈冉 提问：\n SOFAJRaft 目前支持 Multi-Raft 嘛?\n A：支持的，可以参考 rheakv 实现，就是用的 multi raft group。\n 好的，另外想问一下，SOFAJRaft 有没有和 Braft 的性能比较数据，或者同类实现的？\n A：这里有一份 Benchmark 数据可以参考一下，我们暂时没有计划和同类实现对比性能：\nhttps://github.com/sofastack/sofa-jraft/wiki/Benchmark-%E6%95%B0%E6%8D%AE\nSOFA 开源系列 SoloPi：支付宝 Android 专项测试工具 | 开源 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源 蚂蚁金服分布式事务开源以及实践 | SOFA 开源 蚂蚁金服开源自动化测试框架 SOFAACTS 蚂蚁金服开源 SOFAJRaft：生产级 Java Raft 算法库 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFATracer 2.4.1\u0026amp;frasl;3.0.6, 主要变更如下：\ni. 升级 Dubbo 版本至 2.7.3.\nii. 修复 Dubbo 插件中相关埋点参数获取问题\niii. 修复 Datasource 埋点中的若干问题\niv. Cheery pick 代码优化至 3.x 分支\n详细发布报告：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v2.4.1\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.0.6\n2、发布 SOFA MOSN v0.6.0，主要变更如下：\ni. Listener 支持配置空闲连接超时关闭\nii. 日志新增 Alertf 接口\niii. 支持 SDS 方式获取证书\niv. Metrics统计与输出优化\nv. IO 协程优化\nvi. 后端模块实现重构，提升了动态更新性能，降低了内存的使用\nvii. racer 模块实现重构，支持更完善的扩展机制\n详细发布报告：\nhttps://github.com/sofastack/sofa-mosn/releases/tag/0.6.0\nSOFA 活动推荐 SOFA Meetup #3 广州站《从开源技术到产品能力》报名进行中~\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 SoloPi 的首秀分享~\n8 月 11 日，我们广州见~\n报名方式：点击“这里”即可报名。\n","date":1564732800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190802/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4edd066a5855f1a118fd562cfc299571","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190802/","publishdate":"2019-08-02T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190802/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【7/29- 8/2】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190802/","wordcount":818},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n本周推荐阅读 大公司开源怎么做？SOFAStack 给出了一个很好的例子 对话鲁直：蚂蚁金服中间件的开源头羊 | 穿山甲专访 SOFAJRaftLab 系列阅读 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 活动推荐  SOFA Meetup #3 广州站《从开源技术到产品能力》报名开始啦~\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 Soloπ 的首秀分享~\n8 月 11 日，我们广州见~\n报名方式：点击“这里”了解活动详情。\n","date":1564124400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190726/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"70e3dace7979772fdf90f9f5a47d2e13","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190726/","publishdate":"2019-07-26T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190726/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"（含活动报名）SOFA Weekly | 每周精选【7/22 - 7/26】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190726/","wordcount":485},{"author":"潘潘","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#3 广州站-从开源技术到产品能力 活动时间：8 月 11 日周日下午 13 点 活动地点：广州市广电平云 B 塔 15F 活动形式：线下活动 报名方式：https://tech.antfin.com/community/activities/779 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n欢迎 Star 我：https://github.com/sofastack\nSOFA Meetup#3 广州站-从开源技术到产品能力 适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 Soloπ 的首秀分享~\n随着应用架构往云原生的方向发展，传统监控手段已经不能满足云原生时代运维的需求，因此，可观察性的理念被引入了 IT 领域。如何通过可观察性的理念，对微服务，Service Mesh 以至未来的 Serverless 架构的应用进行监控， 将是应用架构往云原生迁移过程中的一个重要命题。\n加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n点击即可报名 https://tech.antfin.com/community/activities/779\n议程 时间 环节 分享大纲 分享嘉宾 13:00-13:30 签到 13:30-14:15 《RPC 服务框架 SOFARPC 在蚂蚁金服的发展与进化》 - SOFARPC 在蚂蚁金服的应用现状\n- 协议和通信层的变化与设计\n- 跨机房与弹性的挑战\n- RPC 框架发展中的经验与教训\n- 拥抱开源，SOFARPC 的未来\n 碧远@SOFARPC 开源负责人 14:15-15:00 《蚂蚁金服在云原生架构下的可观察性的探索和实践》 \n- 为什么云原生时代需要可观察性\n- 可观察性的三大支柱\n- 现在社区方案的缺陷\n- 蚂蚁金服对云原生的可观察性的理解及实践\n 苟利@蚂蚁金服中间件团队产品专家 15:00-15:10 茶歇 15:10-15:55 《分布式事务 Seata 三种模式详解》 \n- 分布式事务产生的背景\n- 分布式事务理论基础\n- 蚂蚁金服分布式事务实践\n- 开源分布式事务 Seata 简介(AT，TCC，SAGA)\n 屹远@Seata 核心贡献者 15:55-16:40 《无线自动化测试框架 Soloπ 的跨平台实践》 \n- 移动端自动化测试转向轻量化\n- “Android+iOS”双端核心功能介绍\n- “Android+iOS”双端功能打通介绍\n- 结合云测平台、用例管理、IDE 的自动化测试解决方案\n 茅舍@Soloπ 核心作者\n不溯@Soloπ 核心作者 ","date":1564038000,"description":"SOFA Meetup#3 广州站-从开源技术到产品能力，8 月 11 日周日下午 13 点，广州市广电平云 B 塔 15F 等你。","dir":"activities/sofa-meetup-3/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0e50b11d1a8e52f8cefbac0bb4826ffe","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-3/","publishdate":"2019-07-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofa-meetup-3/","summary":"概要 活动主题：SOFA Meetup#3 广州站-从开源技术到产品能力 活动时间：8 月 11 日周日下午 13 点 活动地点：广州市广电平云 B 塔 15F 活动形式：线下活动 报名方式：","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#3 广州站-从开源技术到产品能力","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-3/","wordcount":1067},{"author":"袖扣","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第五篇，本篇作者袖扣，来自蚂蚁金服。\n《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：\u0026amp;lt;SOFA:JRaftLab/\u0026amp;gt;，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/alipay/sofa-jraft\n前言 RheaKV 是首个以 JRaft 为基础实现的一个原生支持分布式的嵌入式键值（key、value）数据库，现在本文将从 RheaKV 是如何利用 MULTI-RAFT-GROUP 的方式实现 RheaKV 的高性能及容量的可扩展性的，从而进行全面的源码、实例剖析。\nMULTI-RAFT-GROUP 通过对 Raft 协议的描述我们知道：用户在对一组 Raft 系统进行更新操作时必须先经过 Leader，再由 Leader 同步给大多数 Follower。而在实际运用中，一组 Raft 的 Leader 往往存在单点的流量瓶颈，流量高便无法承载，同时每个节点都是全量数据，所以会受到节点的存储限制而导致容量瓶颈，无法扩展。\nMULTI-RAFT-GROUP 正是通过把整个数据从横向做切分，分为多个 Region 来解决磁盘瓶颈，然后每个 Region 都对应有独立的 Leader 和一个或多个 Follower 的 Raft 组进行横向扩展，此时系统便有多个写入的节点，从而分担写入压力，图如下：\n此时磁盘及 I/O 瓶颈解决了，那多个 Raft Group 是如何协作的呢，我们接着往下看。\n选举及复制 RheaKV 主要由 3 个角色组成：PlacementDriver（以下成为 PD） 、Store、Region。由于 RheaKV 支持多组 Raft，所以比单组场景多出一个 PD 角色，用来调度以及收集每个 Store 及 Region 的基础信息。\nPlacementDriver PD 负责整个集群的管理调度、Region ID 生成等。此组件非必须的，如果不使用 PD，设置 PlacementDriverOptions 的 fake 属性为 true 即可。PD 一般通过 Region 的心跳返回信息进行对 Region 调度，Region 处理完后，PD 则会在下一个心跳返回中收到 Region 的变更信息来更新路由及状态表。\nStore 通常一个 Node 负责一个 Store，Store 可以被看作是 Region 的容器，里面存储着多个分片数据。Store 会向 PD 主动上报 StoreHeartbeatRequest 心跳，心跳交由 PD 的 handleStoreHeartbeat 处理，里面包含该 Store 的基本信息，比如，包含多少 Region，有哪些 Region 的 Leader 在该 Store 等。\nRegion Region 是数据存储、搬迁的最小单元，对应的是 Store 里某个实际的数据区间。每个 Region 会有多个副本，每个副本存储在不同的 Store，一起组成一个Raft Group。Region 中的 Leader 会向 PD 主动上报 RegionHeartbeatRequest 心跳，交由 PD 的 handleRegionHeartbeat 处理，而 PD 是通过 Region的Epoch 感知 Region 是否有变化。\nRegionRouteTable 路由表组件 MULTI-RAFT-GROUP 的多 Region 是通过 RegionRouteTable 路由表组件进行管理的，可通过 addOrUpdateRegion、removeRegion 进行添加、更新、移除 Region，也包括 Region 的拆分。目前暂时还未实现 Region 的聚合，后面会考虑实现。\n分区逻辑与算法 Shard “让每组 Raft 负责一部分数据。”\n数据分区或者分片算法通常就是 Range 和 Hash，RheaKV 是通过 Range 进行数据分片的，分成一个个 Raft Group，也称为 Region。这里为何要设计成 Range 呢？原因是 Range 切分是按照对 Key 进行字节排序后再做每段每段切分，像类似 scan 等操作对相近 key 的查询会尽可能集中在某个 Region，这个是 Hash 无法支持的，就算遇到单个 Region 的拆分也会更好处理一些，只用修改部分元数据，不会涉及到大范围的数据挪动。\n当然 Range 也会有一个问题那就是，可能会存在某个 Region 被频繁操作成为热点 Region。不过也有一些优化方案，比如 PD 调度热点 Region 到更空闲的机器上，或者提供 Follower 分担读的压力等。\nRegion 和 RegionEpoch 结构如下：\nclass Region { long id; // region id // Region key range [startKey, endKey) byte[] startKey; // inclusive byte[] endKey; // exclusive RegionEpoch regionEpoch; // region term List\u0026amp;lt;Peer\u0026amp;gt; peers; // all peers in the region } class RegionEpoch { // Conf change version, auto increment when add or remove peer long confVer; // Region version, auto increment when split or merge long version; } class Peer { long id; long storeId; Endpoint endpoint; } Region.id：为 Region 的唯一标识，通过 PD 全局唯一分配。\nRegion.startKey、Region.endKey：这个表示的是 Region 的 key 的区间范围 [startKey, endKey)，特别值得注意的是针对最开始 Region 的 startKey，和最后 Region 的 endKey 都为空。\nRegion.regionEpoch：当 Region 添加和删除 Peer，或者 split 等，此时 regionEpoch 就会发生变化，其中 confVer 会在配置修改后递增，version 则是每次有 split 、merge（还未实现）等操作时递增。 …","date":1563955200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第五篇，本篇作者袖扣，来自蚂蚁金服。","dir":"blog/sofa-jraft-rheaKV-multi-raft-group/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fbebe45fe1ffaa4e8f134c2531cde55c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","publishdate":"2019-07-24T16:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","wordcount":4503},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n社区 Big News NO.1 社区新认证一位 Committer\n@SteNicholas 成为 SOFAJRaft Committer。\n主要贡献\n一、贡献了 SOFAJRaft 源码剖析系列一共三篇文章\n 蚂蚁金服生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 二、贡献了 4 个 feature PR\n Multi-raft-group 的手动集群 Leader 平衡实现 实现了 RheaKV 的 CompareAndPut API 实现了 RheaKV 的 putIfAbsent batch 优化 实现了 RheaKV 的 batch delete API 目前，社区已经认证超过四十位 Committer。 感谢对 SOFAStack 的支持和帮助~\n也欢迎你加入 SOFAStack community，指南：\nhttps://github.com/sofastack/community\nSOFARegistryLab 系列阅读 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼 SOFAChannel 回顾集合 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下\nSOFAActs 1.0.1 版本发布，主要变更如下：\n 插件兼容性问题修复 详细参考 发布报告\n","date":1563519600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190719/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"03bd5ad0ca023620792ed7ee60d4c448","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190719/","publishdate":"2019-07-19T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190719/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【7/15 - 7/19】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190719/","wordcount":776},{"author":"枫晟","categories":"CafeDeployment","content":" 本文简单介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。\n相关直播视频以及 PPT 查看地址\n背景介绍 Kubernetes 原生社区 Deployment 和 StatefulSet 解决了“服务节点版本一致性”的问题，并且通过 Rolling Update 实现了滚动升级，提供了基本的回滚策略。对于高可用建设要求不高的“年轻”业务，是一个不错的选择。\n但是，在金融场景下，要解决的场景复杂得多。因此我们在金融分布式架构-云应用引擎（SOFAStack-CAFE，参见《金融级云原生探索实践系列——开篇》）中提出了 CafeDeployment 的云原生模型，致力于解决以下问题：\n1. IP 不可变\n对于很多运维体系建设较为早期的用户，使用的服务框架、监控、安全策略，大量依赖 IP 作为唯一标识而被广泛使用。迁移到 Kubernetes 最大的改变就是 IP 会飘，而这对于他们来说，无异于运维、服务框架的推倒重来。\n2. 金融体系下的高可用\nDeployment/StatefulSet 无法根据特定属性进行差异化部署。而在以同城双活为建设基础的金融领域，为了强管控 Pod 的部署结构（即保证每个机房/部署单元都有副本运行），若通过原生组件进行部署，我们不得不维护多个几乎一模一样的 Deployment/StatefulSet，来保证 Pod 一定会飘到指定机房/部署单元的 node 上。在规模上到一定程度后，这无疑加大了运维管控的复杂度和成本。\n3. 灵活的部署策略\nDeployment 无法控制发布步长，StatefulSet 虽然可以控制步长，但是每次都需要人工计算最新版本需要的副本数并修改 Partition，在多机房/部署单元的情况下，光想想发布要做的操作都脑袋炸裂。\n在面对以上这些问题的时候，我们思考：能不能有一个类似 Deployment 的东西，不仅可以实现副本保持，并且能协助用户管控应用节点部署结构、做 Beta 验证、分批发布，减少用户干预流程，实现最大限度减少发布风险的目标，做到快速止损，并进行修正干预。这就是我们为什么选择定义了自己的资源——CafeDeployment。\n模型定义 CafeDeployment 主要提供跨部署单元的管理功能，其下管理多个 InPlaceSet。每个 InPlaceSet 对应一个部署单元。部署单元是逻辑概念，他通过 Node 上的 label 来划分集群中的节点，而 InPlaceSet 则通过 NodeAffinity 能力，将其下的 Pod 部署到同一个部署单元的机器上。由此实现 CafeDeployment 跨部署单元的管理。\nCafeDeployment 作为多个部署单元的上层，除了提供副本保持，历史版本维护等基本功能，还提供了跨部署单元的分组扩容，分组发布，Pod 调度等功能。模型定义如下：\napiVersion: apps.cafe.cloud.alipay.com/v1alpha1 kind: CafeDeployment metadata: ...... spec: historyLimit: 20 podSetType: InPlaceSet\t# 目前支持底层PodSet：InPlaceSet，ReplicaSet，StatefulSet replicas: 10 selector: matchLabels: instance: productpage name: bookinfo strategy: batchSize: 4\t# 分组发布时，每组更新的Pod数目 minReadySeconds: 30 needWaitingForConfirm: true\t# 分组发布中，每组结束时是否需要等待确认 upgradeType: Beta\t# 目前支持发布策略：Beta发布，分组发布 pause: false template: ...... volumeClaimTemplates:\t# 用于支持statefulSet serviceName:\t# 用于支持statefulSet topology: autoReschedule: enable: true\t# 是否启动Pod自动重调度 initialDelaySeconds: 10 unitType: Cell\t# 部署单元类型：Cell，Zone，None unitReplicas: CellA: 4\t# 固定某部署单元的Pod数目 values:\t# 部署单元 - CellA - CellB 因为我们将大部分的控制逻辑都抽取到上层 CafeDeployment 中，因此我们重新设计了 InPlaceSet，将它做得足够简单，只关注于“InPlace”相关的功能，即副本保持和原地升级，保持 IP 不变的能力，模型定义如下：\nspec: minReadySeconds: 30 replicas: 6 selector: matchLabels: instance: productpage name: bookinfo deployUnit: CellB strategy: partition: 6\t# 控制发布时更新Pod的进度 template: ...... 功能特性 灵活的分组定义 CafeDeployment 支持跨部署单元的分组扩容，Pod 调度，分组发布。分组策略主要分为两种，Beta 分组和 Batch 分组：\n Batch 分组 即根据 BatchSize 将 Pod 分为多个批次，每批中的 Pod 会同时发布。待用户确认（needWaitingForConfirm=true时）无误时，或当前批次所有 Pod 都 ready 后（needWaitingForConfirm=false 时），则会开始进行下一组的发布。\n在分组暂停时，CafeDeployment 会被打上 Annotation: cafe.sofastack.io/upgrade-confirmed=false，用户可通过将 Annotation 的值改为 true，确认当前分组。\n Beta 分组 相比 Batch 发布，会在第一组发布之前多一步 Beta 分组。此组会在每个部署单元内选择一个 Pod 进行发布，以减小错误配置带来的影响。若用户确认无误，可以确认继续，以进入正常的 Batch 发布流程。\n安全的分组扩容和发布能力 分组扩容 为预防不正确的配置造成大量错误 Pod 同时创建，占用大量资源等意外情况出现，CafeDeployment 支持分组扩容，以降低风险。\n在如下配置时，CafeDeployment 会创建两个 InPlaceSet 实例，并开始分组创建（扩容）Pod。\nspec: ...... replicas: 10\t# 副本数为10 strategy: upgradeType: Beta\t# Beta发布 batchSize: 4\t# 每组Pod数为4 needWaitingForConfirm: true\t# 分组暂停 topology: ...... values:\t# …","date":1563454800,"description":"本文根据 SOFAChannel#7 直播分享整理，介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。","dir":"blog/sofa-channel-7-retrospect/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a1185b6bb7c21fd49c4118950c16a2a9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-7-retrospect/","publishdate":"2019-07-18T21:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-channel-7-retrospect/","summary":"本文简单介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。 相关直播视频以及 PPT 查看地址 背景介绍 Kubernetes 原生社区 Deployment 和 StatefulSet 解决了“服务节点版本一致性”","tags":["CafeDeployment","SOFAChannel"],"title":"自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-7-retrospect/","wordcount":3476},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第二篇，本篇作者尚彧，是 SOFARegistry 开源负责人。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末附共建列表，欢迎领取共建~\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 无论传统的 SOA 还是目前的微服务架构，都离不开分布式的特性，既然服务是分布的就必须解决服务寻址的问题。服务注册中心是这个过程最主要的组件，通过服务注册和服务发现特性收集服务供求关系，解耦服务消费方对服务提供方的服务定位问题。\n服务注册中心的最主要能力是服务注册和服务发现两个过程。服务注册的过程最重要是对服务发布的信息进行存储，服务发现的过程是把服务发布端的所有变化（包括节点变化和服务信息变化）及时准确的通知到订阅方的过程。\n本文详细描述服务注册中心 SOFARegistry 对于服务发现的实现和技术演进过程，主要涉及 SOFARegistry 的服务发现实现模式以及服务数据变化后及时推送到海量客户端感知的优化过程。\n服务发现分类 分布式理论最重要的一个理论是 CAP 原理。关于注册中心的解决方案，根据存储数据一致性维度划分业界有很多实现，比如最有代表性的强一致性 CP 系统 ZooKeeper 和最终一致性 AP 系统 Eureka。SOFARegistry 在数据存储层面采用了类似 Eureka 的最终一致性的过程，但是存储内容上和 Eureka 在每个节点存储相同内容特性不同，采用每个节点上的内容按照一致性 Hash 数据分片来达到数据容量无限水平扩展能力。\n服务端发现和客户端发现 抛开数据存储的一致性，我们从服务发现的实现维度考虑服务注册中心的分类，业界也按照服务地址选择发生主体和负载均衡策略实现主体分为客户端服务发现和服务端服务发现。\n 客户端服务发现：即由客户端负责决定可用的服务实例的\u0026amp;rdquo;位置\u0026amp;rdquo;以及与其相关的负载均衡策略，就是服务发现的地址列表在客户端缓存后由客户端自己根据负载均衡策略进行选址完成最终调用，地址列表定期进行刷新或服务端主动通知变更。最主要的缺点是需要有客户端实现，对于各种异构系统不同语言不同结构的实现必须要进行对应的客户端开发，不够灵活，成本较高。 服务端服务发现：在服务端引入了专门的负载均衡层，将客户端与服务发现相关的逻辑搬离到了负载均衡层来做。客户端所有的请求只会通过负载均衡模块，其并不需要知会微服务实例在哪里，地址是多少。负载均衡模块会查询服务注册中心，并将客户端的请求路由到相关可用的微服务实例上。这样可以解决大量不同实现应用对客户端的依赖，只要对服务端的负载均衡模块发请求就可以了，由负载均衡层获取服务发现的地址列表并最终确定目标地址进行调用。 SOFARegistry 服务发现模式：以客户端服务发现模式为主。这样的模式实现比较直接，因为在同一个公司内部实践面对的绝大多数应用基本上都是同一个语言实现的，客户端实现也只需要确定一套，每个客户端通过业务内嵌依赖方式部署，并且可以根据业务需求进行定制负载均衡策略进行选址调用。当然也会遇到特殊的异构系统，这个随着微服务架构 RPC 调用等通信能力下沉到 Mesh 执行也得到解决，可以在 Mesh 层进行特定的服务注册中心客户端嵌入，选择路由都在这里统一进行，对不同语言实现的系统进行无感知。 服务发现的推、拉模型 服务发现最重要的过程是获取服务发布方地址列表的过程，这个过程可以分为两种实现模式：客户端主动获取的拉模式和服务端主动变更通知的推送模式：\n 拉模式主要是在客户端按照订阅关系发起主动拉取过程。客户端在首次订阅可以进行一次相关服务 ID 的服务列表查询，并拉取到本地缓存，后续通过长轮询定期进行服务端服务 ID 的版本变更检测，如果有新版本变更则及时拉取更新本地缓存达到和服务端一致。这种模式在服务端可以不进行订阅关系的存储，只需要存储和更新服务发布数据。由客户端主动发起的数据获取过程，对于客户端实现较重，需要主动获取和定时轮训，服务端只需要关注服务注册信息的变更和健康情况及时更新内存。这个过程由于存在轮训周期，对于时效性要求不高的情况比较适用。 推模式主要是从服务端发起的主动变更推送。这个模式主要数据压力集中在服务端，对于服务注册数据的变更和提供方，节点每一次变更情况都需要及时准确的推送到客户端，更新客户端缓存。这个数据推送量较大，在数据发布频繁变更的过程，对于大量订阅方的大量数据推送频繁执行，数据压力巨大，但是数据变更信息及时，对于每次变更都准确反映到客户端。 SOFARegistry 服务发现模式采用的是推拉结合方式。客户端订阅信息发布到服务端时可以进行一次地址列表查询，获取到全量数据，并且把对应的服务 ID 版本信息存储在 Session 回话层，后续如果服务端发布数据变更，通过服务 ID 版本变更通知回话层 Session，Session 因为存储客户端订阅关系，了解哪些客户端需要这个服务信息，再根据版本号大小决定是否需要推送给这个版本较旧的订阅者，客户端也通过版本比较确定是否更新本次推送的结果覆盖内存。此外，为了避免某次变更通知获取失败，定期还会进行版本号差异比较，定期去拉取版本低的订阅者所需的数据进行推送保证数据最终一致。 SOFARegistry 服务发现模式 数据分层 前面的文章介绍过 SOFARegistry 内部进行了数据分层，在服务注册中心的服务端因为每个存储节点对应的客户端的链接数据量有限，必须进行特殊的一层划分用于专门收敛无限扩充的客户端连接，然后在透传相应的请求到存储层，这一层是一个无数据状态的代理层，我们称之为 Session 层。\n此外，Session 还承载了服务数据的订阅关系，因为 SOFARegistry 的服务发现需要较高的时效性，对外表现为主动推送变更到客户端，所以推送的主体实现也集中在 Session 层，内部的推拉结合主要是通过 Data 存储层的数据版本变更推送到所有 Session 节点，各个 Session 节点根据存储的订阅关系和首次订阅获取的数据版本信息进行比对，最终确定推送给那些服务消费方客户端。\n触发服务推送的场景 直观上服务推送既然是主动的，必然发生在主动获取服务时刻和服务提供方变更时刻：\n 主动获取：服务订阅信息注册到服务端时，需要查询所有的服务提供方地址，并且需要将查询结果推送到客户端。这个主动查询并且拉取的过程，推送端是一个固定的客户端订阅方，不涉及服务 ID 版本信息判定，直接获取列表进 …","date":1563433200,"description":"本文为《剖析 | SOFARegistry 框架》第二篇，本篇作者尚彧，来自蚂蚁金服。","dir":"blog/sofa-registry-service-discovery-optimization/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f99d259a0c323df2ddaaea719da2f93c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","publishdate":"2019-07-18T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路","type":"blog","url":"/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","wordcount":5056},{"author":"隐秀","categories":"SOFAStack","content":" \u0026amp;gt; KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。\n市场观察 当我们回顾云计算的发展历程，会看到基础架构经历了从物理机到虚拟机，从虚拟机再到容器的演进过程。在这大势之下，应用架构也在同步演进，从单体过渡到多层，再到当下的微服务。在变化的背后，有一股持续的动力，它来自于三个不变的追求：提高资源利用率，优化开发运维体验，以及更好地支持业务发展。\n目前， Serverless 已成为云原生社区关注的重点之一，它的发展也不例外。相比容器技术，Serverless 可以将资源管理的粒度更加细化，使开发者更快上手云原生，并且倡导事件驱动模型支持业务发展。从而帮助用户解决了资源管理复杂、低频业务资源占用等问题；实现面向资源使用，以取代面向资源分配的模式。根据 CNCF 在2018年底基于 2400 人的一份统计报告，已有 38% 的组织正在使用 Serverless 技术，相比 2017 同期增长了 22%。(数据来源：CNCF Survey)\n\u0026amp;gt; 图片来源：Gartner Report: China Summary Translation Evolution of Server Computing - VMs to Containers to Serverless - Which to Use When\n目前市场上，云厂商提供了多种 Serverless 产品和解决方案，大致可划分为：\n 函数计算服务：如 AWS Lambda，特点是以代码片段为单位运行，并对代码风格有一定要求。 面向应用的 Serverless 服务：如 Knative，特点是基于容器服务，并提供了从代码包到镜像的构建能力。 容器托管服务：如 AWS Fargate，特点是以容器镜像为单元运行，但用户仍需感知容器。 从社区来看，CNCF 云原生基金会正通过 Serverless 工作组协调社区讨论并促进规范和标准的形成，工作组产出了 Serverless 白皮书和全景图等重要内容。其中，全景图将目前的生态划分为了平台层，框架层，工具链层和安全层这四个模块。\n\u0026amp;gt; 图片来源：https://landscape.cncf.io/\n落地挑战 在交流过程中，我们发现 Serverless 很好地解决了客户的一些诉求：包括通过 0-1-0 的伸缩能力来提高资源时用率，降低成本；支持代码包出发，从而让客户无感化实现云原生，历史应用无需经过容器化改造；支持灵活的触发器配置，引导用户对应用进行事件驱动的改造，从而适应业务的高速发展等。这些优势，使得 Serverless 在小程序开发的场景下大放异彩。\n同时，对于在企业级应用的生产环境落地 Serverless，各方也有了很多探索和突破。在本周刚结束的 KubeCon China 2019 大会上，Serverless 工作组会议也以此为话题展开了讨论。目前的核心挑战可归纳为：\n平台可迁移\n目前众多平台都推出了自己的 Serverless 标准，包括代码格式、框架和运维工具等，用户既面临较高的学习成本和选择压力，也担心无法在平台之间灵活迁移 Serverless 应用。\n0-M-N 性能\n线上应用对控制请求延迟有严格的要求，因此，用户需要谨慎地验证 Serverless 0-1 冷启动速度、M-N 扩容速度以及稳定性都达到了生产要求。\n调试和监控\n用户对底层资源无感知，只能借助平台能力对应用进行调试和监控，用户需要平台提供强大的日志功能进行排错，和多维度的监控功能时刻了解应用状态。\n事件源集成\n采用 Serverless 架构后，应用往往进行更细粒度的拆分，并通过事件串联。因此用户希望平台能集成大多数通用的事件源，并支持自定义事件，使得触发机制更加灵活。\n工作流支持\n完成某个业务，往往涉及多个 Serverless 应用之间的配合，当数目较多时，用户希望可以用工作流工具来进行统一编排和状态查看，提高效率。\n蚂蚁金服实践 SOFAStack 致力于通过产品技术解决云上客户实际痛点，沉淀蚂蚁金服技术实践，帮助用户以高效、低成本的方式迁移到云原生架构。Serverless 应用服务（Serverless Application Service，简称 SOFA SAS）是一款源自蚂蚁金服实践的一站式 Serverless 平台。SAS 基于 SOFAStack CAFE 云应用引擎 （Cloud Application Fabric Engine 简称 CAFE），CAFE 的容器服务已经通过了 CNCF 的一致性认证，是一个标准的 Kubernetes。\nServerless 应用服务产品在兼容标准 Knative 同时，融入了源自蚂蚁金服实践的应用全生命周期管理能力，提供了 Serverless 引擎管理、应用与服务管理、版本管理与流控、根据业务请求或事件触发较快的 0-M-N-0 自动伸缩、计量、日志及监控等配套能力。同时结合金融云上客户实际痛点，产品独居匠心的提供独占版与共享版两种形态，以及传统代码包、容器镜像与纯函数三种研发模式，以解决用户的不同需求，降低客户准入门槛。\n 一键部署：用户可以通过代码包或容器镜像的方式一键部署应用并在任意时刻测试执行。 引擎管理：SAS 提供了丰富的引擎全生命周期管理、诊断、监测等能力，为独占版客户赋能 Serverless 引擎数据面的全方位管理与运维运营能力。 服务及版本：SAS 提供应用管理、应用服务管理以及版本管理。版本可以采用容器镜像方式部署也可以采用传统VM发布模式下的代码包部署，很多情况下用户代码无需修改也无需编写维护 Dockerfile 即可迁移。 0-M-N：SAS 提供 0-M-N-M-0 的 Serverelss 快速伸缩能力，支持事件触发或流量触发的 0-M，多种指标的 M-N（如 QPS、CPU、MEM 等等） 日志监控计量：产品内置了日志、监控、计量等配套设施能力，帮助用户进行调试和应用状态监控。 流量控制：基于 SOFAMesh，SAS提供基本流控能力，后续会与服务网格进一步深度集成提供大规模多维跨地域及混合云的流控能力。 触发器管理：产品支持基于常见周期以及秒级精度的cron表达式触发器，可关联并触发无服务器应用，后续将支持更多 IaaS、PaaS 管控型与数据型事件。 性能简析：横轴为完全在同一时刻触发冷启的Java应用个数，纵轴为冷启应用的平均与最小耗时。随着压力增大，50个Java应用同一时刻调度加冷启平均耗时2.5秒左右，100个Java应用同一时刻调度冷启平均耗时3-4秒，最短耗时1.5到2秒。\n 性能简析：Pooling 快弹慢缩时序算法，池容量和实际单位时间申请量关系可做到如图所示（蓝色为实际申请量，绿色为池容量）\n 目前产品已顺利支撑生产环境小程序 Serverless 模式。同时通过 0-M-N-M-0 的能力在很大程度上降低了小程序的运营成本。在行业客户领域，某保险公司决定近期迁移部分日结前置和长尾应用到 Serverless 产品平台，这也是我们产品又一个重要突破。未来， …","date":1562828400,"description":"KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。","dir":"blog/serverless-market-challenge/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e2a95cbe3e0343e3908f17bea5a55d70","permalink":"https://sofastack.github.io/sofastack.tech/blog/serverless-market-challenge/","publishdate":"2019-07-11T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/serverless-market-challenge/","summary":"\u0026gt; KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。 市场观察 当我们回顾云计算的发展历程，会看到基础架构经历了从物理机到","tags":["SOFAStack","Serverless"],"title":"Serverless 市场观察和落地挑战","type":"blog","url":"/sofastack.tech/blog/serverless-market-challenge/","wordcount":2537},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，ServiceMesh，Serverless，安全容器等方向，并发挥自己的力量。SOFAStack 作为蚂蚁金服重要的开源项目，最近也与 CNCF 有故事发生。\n 近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nCNCF \u0026amp;amp; CNCF Cloud Native Landscape CNCF(Cloud Native Computing Foundation)，是由 Google 牵头创立的云原生计算开源软件基金会。它致力于云原生(Cloud Native)技术的普及和可持续发展。2016 年 11 月，CNCF 开始维护 Cloud Native Landscape，汇总流行热门的云原生技术与工具，并加以分类，为企业构建云原生体系提供参考，在云生态研发、运维领域具有广泛影响力。\nSOFAStack \u0026amp;amp; CNCF Cloud Native Landscape 蚂蚁金服金融级分布式架构 SOFAStack 中的 3 个项目加入这次最新版本的 Cloud Native Landscape ，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 **SOFATracer ** 和 RPC 服务框架 SOFARPC。\nSOFAMosn Star 一下✨： https://github.com/sofastack/sofa-mosn\nSOFAMosn(Modular Observable Smart Network)，是一款采用 GoLang 开发的 Service Mesh 数据平面代理， 功能和定位类似 Envoy ，旨在提供分布式，模块化，可观察，智能化的代理能力。 SOFAMosn 支持 Envoy 和 Istio 的 API，可以和 Istio 集成，在 SOFAMesh 中，我们使用 SOFAMosn 替代 Envoy。 SOFAMosn 初始版本由蚂蚁金服和阿里大文娱 UC 事业部携手贡献，期待社区一起来参与后续开发，共建一个开源精品项目。\nSOFARPC Star 一下✨： https://github.com/sofastack/sofa-rpc\nSOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有业务相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括Bolt， RESTful ， Dubbo ， H2C 协议进行通信。其中 Bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\nSOFATracer Star 一下✨： https://github.com/sofastack/sofa-tracer\nSOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFAStack 开源家族 SOFAStack™（Scalable Open Financial Architecture Stack）是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n图为 SOFAStack 开源全景图，其中橙色部分为 SOFAStack 包含的开源组件，白色部分为兼容或集成开源社区其它优秀的开源产品\n特别感谢 SOFAStack 开源社区的每一个你 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。 到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期认证了两位社区 Committer，再次感谢开发者和企业的信任和认可，因为你们，SOFAStack 社区才能会更好。\n","date":1562749200,"description":"Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC 加入 CNCF 云原生全景图","dir":"blog/sofastack-projects-joined-cncf-landscape/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"219e8daac9b49b95c7d5afd94d9ee791","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","publishdate":"2019-07-10T17:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","summary":"2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kuberne","tags":["SOFAStack","CNCF","开源"],"title":"蚂蚁金服 3 个项目进入 CNCF 云原生全景图 | 开源","type":"blog","url":"/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","wordcount":1278},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第四篇，本篇作者力鲲，来自蚂蚁金服。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 在 Raft 算法中，选举是很重要的一部分，所谓选举也就是在多个节点中选出一个 Leader 节点，由他来对外提供写服务 （以及默认情况下的读服务）。\n在剖析源码时，对选举机制的理解经常会遇到两极分化的情况，对于了解 Raft 算法基本原理的同学，阅读源码就是品味实现之巧妙的过程，而对初体验的同学，却会陷入丈二和尚的窘境，仿佛坠入云里雾里。\n为了提升文章的可读性，我还是希望花一部分篇幅讲清楚选举机制的基本原理，以便后面集中注意力于代码实现。下面是一段图文比喻，帮助理解的同时也让整篇文章不至于过早陷入细节的讨论。\n问题1：选举要解决什么 一个分布式集群可以看成是由多条战船组成的一支舰队，各船之间通过旗语来保持信息交流。这样的一支舰队中，各船既不会互相完全隔离，但也没法像陆地上那样保持非常密切的联系，天气、海况、船距、船只战损情况导致船舰之间的联系存在但不可靠。\n舰队作为一个统一的作战集群，需要有统一的共识、步调一致的命令，这些都要依赖于旗舰指挥。各舰船要服从于旗舰发出的指令，当旗舰不能继续工作后，需要有别的战舰接替旗舰的角色。\n图1 - 所有船有责任随时准备接替旗舰\n如何在舰队中，选出一艘得到大家认可的旗舰，这就是 SOFAJRaft 中选举要解决的问题。\n问题2：何时可以发起选举 何时可以发起选举？换句话说，触发选举的标准是什么？这个标准必须对所有战舰一致，这样就能够在标准得到满足时，所有舰船公平的参与竞选。在 SOFAJRaft 中，触发标准就是通信超时，当旗舰在规定的一段时间内没有与 Follower 舰船进行通信时，Follower 就可以认为旗舰已经不能正常担任旗舰的职责，则 Follower 可以去尝试接替旗舰的角色。这段通信超时被称为 Election Timeout （简称 ET）， Follower 接替旗舰的尝试也就是发起选举请求。\n图2 - ET 触发其他船竞选旗舰\n问题3：何时真正发起选举 在选举中，只有当舰队中超过一半的船都同意，发起选举的船才能够成为旗舰，否则就只能开始一轮新的选举。所以如果 Follower 采取尽快发起选举的策略，试图尽早为舰队选出可用的旗舰，就可能引发一个潜在的风险：可能多艘船几乎同时发起选举，结果其中任何一支船都没能获得超过半数选票，导致这一轮选举无果，然后失败的 Follower 们再一次几乎同时发起选举，又一次失败，再选举 again，再失败 again ···\n图3 - 同时发起选举，选票被瓜分\n为避免这种情况，我们采用随机的选举触发时间，当 Follower 发现旗舰失联之后，会选择等待一段随机的时间 Random(0, ET) ，如果等待期间没有选出旗舰，则 Follower 再发起选举。\n图4 - 随机等待时间\n问题4：哪些候选者值得选票 SOFAJRaft 的选举中包含了对两个属性的判断：LogIndex 和 Term，这是整个选举算法的核心部分，也是容易让人产生困惑的地方，因此我们做一下解释：\n Term：我们会对舰队中旗舰的历史进行编号，比如舰队的第1任旗舰、第2任旗舰，这个数字我们就用 Term 来表示。由于舰队中同时最多只能有一艘舰船担任旗舰，所以每一个 Term 只归属于一艘舰船，显然 Term 是单调递增的。 LogIndex：每任旗舰在职期间都会发布一些指令（称其为“旗舰令”，类比“总统令”），这些旗舰令当然也是要编号归档的，这个编号我们用 Term 和 LogIndex 两个维度来标识，表示“第 Term 任旗舰发布的第 LogIndex 号旗舰令”。不同于现实中的总统令，我们的旗舰令中的 LogIndex 是一直递增的，不会因为旗舰的更迭而从头开始计算。 图5 - 总统令 Vs 旗舰令，LogIndex 稍有区别\n所有的舰船都尽可能保存了过去从旗舰接收到的旗舰令，所以我们选举的标准就是哪艘船保存了最完整的旗舰令，那他就最有资格接任旗舰。具体来说，参与投票的船 V 不会对下面两种候选者 C 投票：一种是 lastTermC \u0026amp;lt; lastTermV；另一种是 (lastTermV == lastTermC) \u0026amp;amp;\u0026amp;amp; (lastLogIndexV \u0026amp;gt; lastLogIndexC)。\n稍作解释，第一种情况说明候选者 C 最后一次通信过的旗舰已经不是最新的旗舰了，至少比 V 更滞后，所以它所知道的旗舰令也不可能比 V 更完整。第二种情况说明，虽然 C 和 V 都与同一个旗舰有过通信，但是候选者 C 从旗舰处获得的旗舰令不如 V 完整 (lastLogIndexV \u0026amp;gt; lastLogIndexC)，所以 V 不会投票给它。\n图6 - Follower 船 b 拒绝了船 c 而投票给船 a，船 a 旗舰令有一个空白框表示“第 Term 任旗舰”没有发布过任何旗舰令\n问题5：如何避免不够格的候选者“捣乱” 如上一小节所说，SOFAJRaft 将 LogIndex 和 Term 作为选举的评选标准，所以当一艘船发起选举之前，会自增 Term 然后填到选举请求里发给其他船只 （可能是一段很复杂的旗语），表示自己竞选“第 Term + 1 任”旗舰。\n这里要先说明一个机制，它被用来保证各船只的 Term 同步递增：当参与投票的 Follower 船收到这个投票请求后，如果发现自己的 Term 比投票请求里的小，就会自觉更新自己的 Term 向候选者看齐，这样能够很方便的将 Term 递增的信息同步到整个舰队中。\n图7 - Follower 船根据投票请求更新自己的 Term\n但是这种机制也带来一个麻烦，如果一艘船因为自己的原因没有看到旗舰发出的旗语，他就会自以为是的试图竞选成为新的旗舰，虽然不断发起选举且一直未能当选（因为旗舰和其他船都正常通信），但是它却通过自己的投票请求实际抬升了全局的 Term，这在 SOFAJRaft 算法中会迫使旗舰 stepdown （从旗舰的位置上退下来）。\n图8 - 自以为是的捣乱者，迫使旗舰 stepdown\n所以我们需要一种机制阻止这种“捣乱”，这就是预投票 (pre-vote) 环节。候选者在发起投票之前，先发起预投票，如果没有得到半数以上节点的反馈，则候选者就会识趣的放弃参选，也就不会抬升全局的 Term。\n图9 - Pre-vote 预 …","date":1562742000,"description":"本文为《剖析 | SOFAJRaft 实现原理》第四篇，本篇作者力鲲，来自蚂蚁金服","dir":"blog/sofa-jraft-election-mechanism/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e40fefafd980ac2308a3ba6f3fda9cdd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-election-mechanism/","publishdate":"2019-07-10T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-jraft-election-mechanism/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-election-mechanism/","wordcount":3152},{"author":"SOFAStack","categories":"SOFAStack","content":" 本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。\n 2019 年 6 月 25 日，在 KubeCon China 2019，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，Service Mesh，Serverless，安全容器等方向，并发挥自己的力量。\n在本次大会，蚂蚁金服也与数百名云原生爱好者用五个小时搭建了一个云原生的电商平台，具体怎么做？希望本文能提供一些思路。\n近二十年技术发展：从集中式架构到云原生架构 过去的十几年里，技术发生了翻天覆地的变化，先来简单回顾下：在二十一世纪初，大部分企业的应用还处于集中式架构。这个阶段企业开始做一些信息化的建设工作，典型的一些技术例如集群部署（Tomcat 集群、Weblogic 集群）来保证系统的高可用，以及采购 IOE（IBM，Oracle，EMC）等这些商业化的软硬件产品，通过更高的配置、更好的性能等方式来抗住业务的增长。\n慢慢的，随着公司规模的扩大，集中式架构已经不足以再支撑复杂的业务系统，很多企业开始做一些系统拆分的改造，典型的技术例如 SOA 化。当系统拆分后，就不再需要使用之前昂贵的小型机去部署服务，慢慢的虚拟机的部署方式变成了主流。同样的，服务化后数据库和存储也不再必须采用商业化软硬件的解决方案，企业转为一些开源的解决方案，例如把 Oracle 换成了 MySQL。\n系统的拆分虽然可以带来很多好处，例如使业务内聚，系统之间松耦合，方便快速迭代等。但是随之带来的问题也很明显，例如拆分后系统越来越多，系统间的交互也会变得更加复杂，调用链路变长可能引起性能问题，分布式后数据存储等数据一致性也有不少挑战，还有服务化后带来资源分配、隔离等问题。这时候一些虚拟化和容器化的技术开始涌现，典型技术就是 OpenStack 和 Docker，OpenStack 帮助我们解决了 IaaS 层的建设与管理问题，而 Docker 给了我们资源隔离的最佳实践，但这些并没有解决掉运维复杂的一些问题。\n而近几年，新的云原生的一些技术产品和理念开始出现，例如 Kubernetes、Service Mesh、Serverless 等，这些可以解决应用部署、运维复杂的一些实际问题。\n技术发展下的蚂蚁金服 蚂蚁金服从 2007 年开始从集中式架构走向分布式架构。我们把过去十多年的技术演进过程中自主研发的一套金融级分布式架构沉淀成为 SOFAStack™（Scalable Open Financial Architecture Stack）。\n从 2007 年到 2012 年，蚂蚁金服完成所有业务系统的模块化、服务化改造。通过 TCC 模式解决了服务化、数据拆分等带来的数据一致性的问题，通过注册中心解决了服务单点的问题。\n在完成服务化改造后，随着服务集群的增大，系统的伸缩性遇到了瓶颈，另外为了满足金融级的属性，蚂蚁金服对系统可用性、数据一致性提出了更高的要求。蚂蚁金服从 2013 年开始摸索出了一套单元化的思想，并基于此，推出了同城双活、异地多活、弹性调度等能力，保证业务不停机，数据不丢失。\n再之后随着国内互联网金融的崛起、蚂蚁金服的国际化，蚂蚁金服也将自己的能力和技术开放出来，在金融云上以云产品的形式存在，开发者可以基于此快速搭建金融级能力的分布式系统，同时我们也将内部的一些实践开源出来。\n从 2017 年开始，我们注意到云原生的理念正在快速发展，面对云原生带来的机会和改变，蚂蚁金服的策略是积极拥抱云原生。 因为云原生带来的思想和理念刚好可以用来解决蚂蚁金服内部遇到的一些场景和问题。\n例如 Service Mesh 可以解决中间件等基础能力下层的问题，Serverless 可以解决研发效能的问题，可以让业务开发更专注于业务。这些新的技术和理念蚂蚁金服都会在内部探索并在生产落地，最近我们在深圳 GIAC 首次分享了大规模落地的实践总结，蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录。同时，我们也会将这些云原生落地实践开源出来，并和社区一起共同推进和建设金融级的云原生标准。\nSOFAStack 开源版本： 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期也认证了两位社区 Committer，这里想再次感谢开发者和企业的信任和认可，我们将持续优化和扩大开源版图。\n我们看下这张图，这里可以看到 SOFAStack 体系下开源了很多微服务相关的技术组件，例如 SOFABoot、SOFARPC 等，我们也和社区其它优秀的开源产品进行了兼容或者集成，利用这些组件可以快速的搭建出金融级分布式架构系统。开源的源码可以在这张图下面的 Github 地址上找到。本次的 Workshop 我们就会利用到开源的一些技术组件。\nSOFAStack 云产品： 上图是云上 SOFAStack 的架构图，我们可以看到 SOFAStack 商业化对外输出的是完整的解决方案。支撑解决方案的就是本次要体验的分布式中间件和云应用引擎等等能力。除此之外还有完善的研发效能平台服务以及技术风险防控平台。关于这部分内容，在本次下午场会有更详细的介绍和体验。\nLet\u0026amp;rsquo;s get started! 刚聊了这么多，大家是不是想动手试试了呢？本次 Demo 将带领大家综合利用开源版本的 SOFAStack 和云上产品，五小时实现一个在线电商平台。\n下面简单介绍下本次 Workshop 的内容，如下图：\n上午\n 构建基础电商平台（书店） ，并改造为微服务架构； 基于 SOFABoot 动态模块能力实时的电商平台（书店）增加智能推荐的能力； 用分布式事务 Seata 来解决微服务拆分后的分布式事务的问题，保证购买和余额的数据一致性； 下午\n 通过 Serverless 快速上云，利用 SOFA SAS 发布书店到云环境上，根据流量自动扩缩容； 通过 Service Mesh 的方式来实现精度灰度和流控的能力； 这是提到的是在线书店的系统架构图，最上面是部署好的一些基础设施，包括注册中心 SOFARegistry，服务管控台 SOFADashboard，监控度量 SOFALookout 等，我们已经提前准备好了这部分内容。\n下面就是业务的内容。为了方便，我们不再做前后端分类部署，本次大家只需要操作 2 个应用：\n左边是网页系统和库存系统，提供库存操作服务，右边是账务系统，提供余额相关服务，当用户的请求进来时，库存系统需要通过 RPC 调到账务系统。\n另外库存服务和余额服务分别对应的是独立的数据库，这个后面会用分布式事务 Seata 去解决分布式事务的问题。\nSOFAStack Cloud …","date":1562742000,"description":"本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。","dir":"blog/sofastack-cloud-native-workshop-show/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bed45f24a92c60ca5b141952abdc2049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","publishdate":"2019-07-10T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","summary":"本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。 2019 年 6 月 25 日，在 KubeCon China 2019，全球知名开源组织云原生计","tags":["分布式事务","SOFABoot","Service Mesh","开源","Seata"],"title":"五小时构建云原生电商平台 | KubeCon SOFAStack Workshop 详解","type":"blog","url":"/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","wordcount":2648},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 活动时间：7 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 在 6 月 KubeCon 大会期间，蚂蚁金服正式宣布加入了 CNCF 成为黄金会员，同时 SOFAStack-CAFE 云应用引擎产品也通过了 K8S 一致性认证，旨在向广大金融机构提供云原生的可落地路径。\n为满足金融级云原生发布部署、变更管控场景对于可灰度、可监控、可应急的需求，SOFAStack 产品研发团队在 Kubernetes 基础上实现了自定义资源 CAFEDeployment ，它能够通过可靠而灵活的分发、风险控制的部署策略以及高性能的原地升级更新扩展部署能力。它尤其消除了金融服务行业所面临的技术障碍，使用户能够专心发展核心业务。\n与 Kubernetes 原生工作负载对象 Deployment 所提供的简洁轻量的滚动发布相比，CAFEDeployment 旨在满足金融场景对分批发布、多活容灾、原地升级等方面的诉求。\n7 月 18 日周四晚 7 点，将邀请 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人 枫晟 为大家分享《扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进》。\n在此次分享中，将介绍对此 Kubernetes 扩展能力的相关观点主张、产品探索和实际演示。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/737\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 枫晟 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人\n本期分享大纲： Kubernetes Deployment 发展历史与现状 Kubernetes Deployment 在互联网金融云场景下的问题与挑战 CafeDeployment 适配互联网金融发布的工作负载 CafeDeployment 的运行机制 CafeDeployment 功能演示 嘉宾 SOFAGirl 主持人 枫晟 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人 ","date":1562573400,"description":"7 月 18 日周四晚 7 点，线上直播第 7 期。","dir":"activities/sofa-channel-7/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"51c929733c988190de480a3a0dc5e735","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-7/","publishdate":"2019-07-08T16:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-7/","summary":"概要 活动主题：SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 活动时间：7 月 18 日周四晚 7 点 活动形式","tags":["SOFAChannel","CAFEDeployment"],"title":"SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进","type":"activities","url":"/sofastack.tech/activities/sofa-channel-7/","wordcount":813},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，ServiceMesh，Serverless，安全容器等方向，并发挥自己的力量。SOFAStack 作为蚂蚁金服重要的开源项目，最近也与 CNCF 有故事发生。\n 近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nCNCF \u0026amp;amp; CNCF Cloud Native Landscape CNCF(Cloud Native Computing Foundation)，是由 Google 牵头创立的云原生计算开源软件基金会。它致力于云原生(Cloud Native)技术的普及和可持续发展。2016 年 11 月，CNCF 开始维护 Cloud Native Landscape，汇总流行热门的云原生技术与工具，并加以分类，为企业构建云原生体系提供参考，在云生态研发、运维领域具有广泛影响力。\nSOFAStack \u0026amp;amp; CNCF Cloud Native Landscape 蚂蚁金服金融级分布式架构 SOFAStack 中的 3 个项目加入这次最新版本的 Cloud Native Landscape，分别是 Service Mesh 数据平面代理 SOFAMosn 、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nSOFAMosn Star 一下✨：https://github.com/sofastack/sofa-mosn\nSOFAMosn(Modular Observable Smart Network)，是一款采用 GoLang 开发的 Service Mesh 数据平面代理， 功能和定位类似 Envoy ，旨在提供分布式，模块化，可观察，智能化的代理能力。 SOFAMosn 支持 Envoy 和 Istio 的 API，可以和 Istio 集成，在 SOFAMesh 中，我们使用 SOFAMosn 替代 Envoy。 SOFAMosn 初始版本由蚂蚁金服和阿里大文娱 UC 事业部携手贡献，期待社区一起来参与后续开发，共建一个开源精品项目。\nSOFARPC Star 一下✨：https://github.com/sofastack/sofa-rpc\nSOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有业务相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括Bolt， RESTful ， Dubbo ， H2C 协议进行通信。其中 Bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\nSOFATracer Star 一下✨：https://github.com/sofastack/sofa-tracer\nSOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFAStack 开源家族 SOFAStack™（Scalable Open Financial Architecture Stack）是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n图为 SOFAStack 开源全景图，其中橙色部分为 SOFAStack 包含的开源组件，白色部分为兼容或集成开源社区其它优秀的开源产品\n特别感谢 SOFAStack 开源社区的每一个你 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期认证了两位社区 Committer，再次感谢开发者和企业的信任和认可，因为你们，SOFAStack 社区才能会更好。\n文中涉及的相关链接：\n SOFAMosn：https://github.com/sofastack/sofa-mosn SOFARPC：https://github.com/sofastack/sofa-rpc SOFATracer：https://github.com/sofastack/sofa-tracer SOFAMesh：https://github.com/sofastack/sofa-mesh ","date":1562569200,"description":"近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入。","dir":"blog/sofastack-cncf-cloud-native-landscape/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7146cdd7e74b9901a8ac20cb3e80cf6e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","publishdate":"2019-07-08T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","summary":"2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kuberne","tags":["SOFAStack"],"title":"蚂蚁金服 3 个项目进入 CNCF 云原生全景图 | 开源","type":"blog","url":"/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","wordcount":1590},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 7 月 3 日，在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开源技术创新奖（自主研发）。云计算开源产业大会由中国信息通信研究院主办，是中国云计算开源领域最权威和专业的行业盛会。\n本次大会上，中国信息通信研究院还发布了《混合云白皮书（2019年）》，该白皮书梳理了混合云的最新发展现状、关键能力、应用案例和技术发展趋势。基于完全自主研发的 SOFAStack 金融级分布式架构的网商银行三地五中心异地多活部署方案被作为典型应用案例入选其中。\n完全自主研发的金融级分布式架构 SOFAStack SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时任务、限流/熔断框架、动态配置推送、分布式链路追踪、Metrics 监控度量、分布式高可用消息队列、分布式事务框架和分布式数据库代理层等。\n据了解，经过数代架构演进和“双十一”考验的 SOFAStack，已于 2018 年 4 月正式对外开源，仅一年时间，SOFAStack 所有相关的开源代码，累计获得 16,000+ 个 Star，并有 110+ 个代码贡献者参与其中。\nSOFAStack 助力客户数字化转型 作为一套分布式架构的完整的解决方案，SOFAStack 在真实的金融场景里锤炼出不少最佳实践。\n2017 年 10 月，SOFAStack 与南京银行共同打造出“鑫云+”互金开放平台。该平台具备高性能承载、敏捷开发、强数据一致性和容灾能力等特性，从而使得南京银行互金核心系统在贷款交易处理能力、成本控制和对接效率都得到了极大的提升。南京银行与互联网平台合作开展线上业务仅一年时间，业务量就已经达到了过去十年传统线下消费金融业务的总和。南京银行“鑫云+”平台上线后，业务快速增长，贷款交易处理量增长了数倍。\n据介绍，SOFAStack 还帮助中国人保健康打造行业领先的互联网保险云核心业务系统，助力网商银行成为中国第一家将核心系统架构在金融云上的银行。\nSOFAStack 引领开源技术创新 2019 年 6 月 25 日，蚂蚁金服正式成为 CNCF 云原生计算基金会黄金会员，SOFAStack 云应用引擎产品 CAFE 已通过 CNCF 一致性认证，积极拥抱云原生的同时，满足严苛金融业务场景需求、保障金融技术风险。\n蚂蚁金服是金融级云原生的首倡者，主张金融级的云原生容器产品必须拥有稳定性与高可用保障、无限弹性扩展、运行时安全的能力，这些理念也集中体现在蚂蚁金服的金融级分布式开源项目 SOFAStack 里。\n蚂蚁金服一直积极参与开源社区共建。截至目前，蚂蚁金服已经有 400 多个开源项目。除了 SOFAStack 系列，Ant Design、SQLFlow、EggJS、Seata（与阿里巴巴共建）等也成为社区热门。\n蚂蚁金服金融科技产品技术总监杨冰表示：“开源是一种可以使客户和上下游产业共同参与和发展的可行模式，是个共赢的模式。在贡献蚂蚁金服的技术沉淀给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。只有开放才能求同存异，共同发展。”\n","date":1562223600,"description":"在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开源技术创新奖（自主研发）。","dir":"blog/sofastack-2019-oscar/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"21da7fc5e118681336c84d2dc46fe6bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-2019-oscar/","publishdate":"2019-07-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofastack-2019-oscar/","summary":"2019 年 7 月 3 日，在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开","tags":["SOFAStack"],"title":"蚂蚁金服 SOFAStack 荣获云计算开源产业大会尖峰开源技术创新奖","type":"blog","url":"/sofastack.tech/blog/sofastack-2019-oscar/","wordcount":1223},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第三篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 线性一致读是在分布式系统中实现 Java volatile 语义，当客户端向集群发起写操作的请求并且获得成功响应之后，该写操作的结果要对所有后来的读请求可见。实现线性一致读常规手段是走 Raft 协议，将读请求同样按照 Log 处理，通过日志复制和状态机执行获取读结果返回给客户端，SOFAJRaft 采用 ReadIndex 替代走 Raft 状态机的方案。本文将围绕 Raft Log Read，ReadIndex Read 以及 Lease Read 等方面剖析线性一致读原理，阐述 SOFAJRaft 如何使用 ReadIndex 和 Lease Read 实现线性一致读：\n 什么是线性一致读？共识算法只能保证多个节点对某个对象的状态是一致的，以 Raft 为例只能保证不同节点对 Raft Log 达成一致，那么 Log 后面的状态机的一致性呢？ 基于 ReadIndex 和 Lease Read 方式 SOFAJRaft 如何实现高效的线性一致读？ 线性一致读 什么是线性一致读? 所谓线性一致读，一个简单的例子是在 t1 的时刻我们写入了一个值，那么在 t1 之后，我们一定能读到这个值，不可能读到 t1 之前的旧值(想想 Java 中的 volatile 关键字，即线性一致读就是在分布式系统中实现 Java volatile 语义)。简而言之是需要在分布式环境中实现 Java volatile 语义效果，即当 Client 向集群发起写操作的请求并且获得成功响应之后，该写操作的结果要对所有后来的读请求可见。和 volatile 的区别在于 volatile 是实现线程之间的可见，而 SOFAJRaft 需要实现 Server 之间的可见。\n如上图 Client A、B、C、D 均符合线性一致读，其中 D 看起来是 Stale Read，其实并不是，D 请求横跨 3 个阶段，而 Read 可能发生在任意时刻，所以读到 1 或 2 都行。\nRaft Log read 实现线性一致读最常规的办法是走 Raft 协议，将读请求同样按照 Log 处理，通过 Log 复制和状态机执行来获取读结果，然后再把读取的结果返回给 Client。因为 Raft 本来就是一个为了实现分布式环境下线性一致性的算法，所以通过 Raft 非常方便的实现线性 Read，也就是将任何的读请求走一次 Raft Log，等此 Log 提交之后在 apply 的时候从状态机里面读取值，一定能够保证这个读取到的值是满足线性要求的。\n当然，因为每次 Read 都需要走 Raft 流程，Raft Log 存储、复制带来刷盘开销、存储开销、网络开销，走 Raft Log不仅仅有日志落盘的开销，还有日志复制的网络开销，另外还有一堆的 Raft “读日志” 造成的磁盘占用开销，导致 Read 操作性能是非常低效的，所以在读操作很多的场景下对性能影响很大，在读比重很大的系统中是无法被接受的，通常都不会使用。\n在 Raft 里面，节点有三个状态：Leader，Candidate 和 Follower，任何 Raft 的写入操作都必须经过 Leader，只有 Leader 将对应的 Raft Log 复制到 Majority 的节点上面认为此次写入是成功的。所以如果当前 Leader 能确定一定是 Leader，那么能够直接在此 Leader 上面读取数据，因为对于 Leader 来说，如果确认一个 Log 已经提交到大多数节点，在 t1 的时候 apply 写入到状态机，那么在 t1 后的 Read 就一定能读取到这个新写入的数据。\n那么如何确认 Leader 在处理这次 Read 的时候一定是 Leader 呢？在 Raft 论文里面，提到两种方法：\n ReadIndex Read Lease Read ReadIndex Read 第一种是 ReadIndex Read，当 Leader 需要处理 Read 请求时，Leader 与过半机器交换心跳信息确定自己仍然是 Leader 后可提供线性一致读：\n Leader 将自己当前 Log 的 commitIndex 记录到一个 Local 变量 ReadIndex 里面； 接着向 Followers 节点发起一轮 Heartbeat，如果半数以上节点返回对应的 Heartbeat Response，那么 Leader就能够确定现在自己仍然是 Leader； Leader 等待自己的 StateMachine 状态机执行，至少应用到 ReadIndex 记录的 Log，直到 applyIndex 超过 ReadIndex，这样就能够安全提供 Linearizable Read，也不必管读的时刻是否 Leader 已飘走； Leader 执行 Read 请求，将结果返回给 Client。 使用 ReadIndex Read 提供 Follower Read 的功能，很容易在 Followers 节点上面提供线性一致读，Follower 收到 Read 请求之后：\n Follower 节点向 Leader 请求最新的 ReadIndex； Leader 仍然走一遍之前的流程，执行上面前 3 步的过程(确定自己真的是 Leader)，并且返回 ReadIndex 给 Follower； Follower 等待当前的状态机的 applyIndex 超过 ReadIndex； Follower 执行 Read 请求，将结果返回给 Client。 不同于通过 Raft Log 的 Read，ReadIndex Read 使用 Heartbeat 方式来让 Leader 确认自己是 Leader，省去 Raft Log 流程。相比较于走 Raft Log 方式，ReadIndex Read 省去磁盘的开销，能够大幅度提升吞吐量。虽然仍然会有网络开销，但是 Heartbeat 本来就很小，所以性能还是非常好的。\nLease Read 虽然 ReadIndex Read 比原来的 Raft Log Read 快很多，但毕竟还是存在 Heartbeat 网络开销，所以考虑做更进一步的优化。Raft 论文里面提及一种通过 Clock + Heartbeat 的 Lease Read  …","date":1562050800,"description":"本文为《剖析 | SOFAJRaft 实现原理》第三篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-jraft-linear-consistent-read-implementation/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cfa43268e0ca8424ff44bd4397f720b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","publishdate":"2019-07-02T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","wordcount":4732},{"author":"绍辉","categories":"Seata","content":" 获取本次分享完整 PPT：下载地址\n本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。详细讲解了在分布式架构演进中，蚂蚁金服面对的跨服务、跨数据库的业务数据一致性问题以及应对措施，并分享了分布式事务 Seata 的 AT、TCC、Saga 和 XA 四种模式。\nSeata：https://github.com/seata/seata\n一、自研分布式事务解决数据一致性问题 1.1 分布式事务问题产生原因 1.1.1 数据库的水平拆分 蚂蚁金服的业务数据库起初是单库单表，但随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。所以我们对数据库进行了水平拆分，将原单库单表拆分成数据库分片。\n如下图所示，分库分表之后，原来在一个数据库上就能完成的写操作，可能就会跨多个数据库，这就产生了跨数据库事务问题。\n1.1.2 业务服务化拆分 在业务发展初期，“一块大饼”的单业务系统架构，能满足基本的业务需求。但是随着业务的快速发展，系统的访问量和业务复杂程度都在快速增长，单系统架构逐渐成为业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。\n如下图所示，蚂蚁金服按照面向服务（SOA）的架构的设计原则，将单业务系统拆分成多个业务系统，降低了各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。\n业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，如何保证多个服务间的数据一致性成为一个难题。\n1.2 蚂蚁金服遇到的数据一致性问题 在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。在分布式网络环境下，我们无法保障所有服务、数据库都百分百可用，一定会出现部分服务、数据库执行成功，另一部分执行失败的问题。\n当出现部分业务操作成功、部分业务操作失败时，业务数据就会出现不一致。以金融业务中比较常见的“转账”场景为例：\n如下图所示，在支付宝的“转账”操作中，要分别完成 4 个动作：\n 创建交易订单； 创建支付订单； A 账户扣钱； B 账户加钱； 而完成以上操作要分别访问 3 个服务和 4 个数据库。\n在分布式环境下，肯定会出现部分操作成功、部分操作失败的问题，比如：A 账户的钱扣了，但是 B 账户的钱没加上，这就造成了资金损失，影响资金安全。\n在金融业务场景下，我们必须保证“转账”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象。\n为了解决跨数据库、跨服务的业务数据一致性问题，蚂蚁金服自主研发了分布式事务中间件。\n从 2007 年开始做分布式事务并支持双十一，至今已经有 12 年。\n2013 年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014 年，蚂蚁金服分布式事务中间件 DTX(Distributed Transaction-eXtended)开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户。在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。所以在 2015 年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务（Distributed Transaction-eXtended，简称 DTX）链接：\nhttps://tech.antfin.com/products/DTX\n二、投入开源社区，共建开源分布式事务 Seata  2.1 分布式事务 Seata 介绍 Seata（Simple Extensible Autonomous Transaction Architecture，简单可扩展自治事务框架）是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。Seata 开源半年左右，目前已经有接近一万 star，社区非常活跃。我们热忱欢迎大家参与到 Seata 社区建设中，一同将 Seata 打造成开源分布式事务标杆产品。\nSeata：https://github.com/seata/seata\n2.2 分布式事务 Seata 产品模块 如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。\n在 Seata 中，分布式事务的执行流程：\n TM 开启分布式事务（TM 向 TC 注册全局事务记录）； 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）； TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）； TC 汇总事务信息，决定分布式事务是提交还是回滚； TC 通知所有 RM 提交/回滚 资源，事务二阶段结束。 2.3 分布式事务 Seata 解决方案 Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。\n2.3.1 AT 模式 今年 1 月份，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。\nAT 模式如何做到对业务的无侵入 ： 一阶段： 在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。\n 二阶段提交： 二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。\n 二阶段回滚： 二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。\nAT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。\n2.3.2 TCC 模式 2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段 执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。\nTCC 三个方法描述：\n Try： …","date":1562050800,"description":"本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。","dir":"blog/seata-distributed-transaction-deep-dive/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d87c4d85b8c16bfc24a0b9bea52b604d","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","publishdate":"2019-07-02T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","summary":"获取本次分享完整 PPT：下载地址 本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。详细讲解了","tags":["分布式事务","实践","开源","Seata"],"title":"Seata 分布式事务实践和开源详解 | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","wordcount":5775},{"author":"响风","categories":"SOFALookout","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23195297，不错过每场直播。\n 大家好，我是响风，来自蚂蚁金服， 现在是 SOFALookout 的开源负责人。本期 SOFAChannel 我给大家带来主题是《轻量级监控分析系统 SOFALookout 原理讲解和功能演示》的分享。本期的讲解内容如下将从以下四个部分展开：\n 监控预警基本概念介绍 SOFALookout 的客户端使用（包括系统设计简介与实现） SOFALookout 的服务端使用（包括系统设计简介与实现） SOFALookout 发展规划 欢迎大家 Star 我，SOFALookout：https://github.com/sofastack/sofa-lookout\n1 监控预警基本概念介绍 1.1 什么是 SOFALookout 现在我们开始第一部分，先介绍一些基本概念。6 月初，SOFALookout 服务端开源，具体内容可以查看相关文章：蚂蚁金服轻量级监控分析系统 SOFALookout 服务端开源，SOFALookout 客户端在之前也已经开源。目前整个系统是真正地可以玩转起来的，这里先介绍一下 SOFALookout。\nSOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。开源版本只提供对 Metrics 的处理部分：涵盖 Metrics 数据的产生，也就是 Metrics 的埋点、收集、加工、存储与查询等一系列服务。\n1.2 Metrics 的前置知识 介绍一些 Metrics 的前置知识：\n第一是时序数据，比较正式的解释是“基于稳定频率持续产生的一系列指标监测数据”。简单说横轴是时间，纵轴是数值的情况下，第一印象可以做成走势图的数据通常就是时序数据。比如 2009 年到 2018 年每年双十一天猫的成交额，就构成了时序数据。\n第二是标签（Tag），它用于表明指标项监测针对的具体对象。还是以刚才的成交额为例子，其实我们要监测的指标是“成交额”，但是“成交额”并没有标明要监测的对象，即谁的成交额，哪个省的成交额，也就是缺少“定语”。标签的作用就相当于是“定语”。比如“天猫的 浙江省的 成交额”，在代码中通常会有键值对来描述，比如 type=\u0026amp;ldquo;天猫\u0026amp;rdquo;，province=\u0026amp;ldquo;浙江\u0026amp;rdquo;。\n第三是时序数据库，即专门为存查时序数据而设计的数据管理系统。主要有以下几个特点：\n 写多读少 数据多维度，无 schema，需要多维度查询或聚合 通常无删除和更新操作， 或受限 以下是一些常见的开源时序数据库，由于篇幅关系，就不一一介绍了。\n Graphite InfluxDB OpenTSDB Prometheus 1.3 传统 Metrics 和 Metrics 2.0 的对比 下面再来看一下传统 Metrics 和 Metrics 2.0 的对比。\n1.3.1 传统 Metrics 传统 Metrics 是我对它的称呼，简单来说它只有 Name 和 Value，没有显式的 Tags 概念。比如 \u0026amp;ldquo;temperature = 29\u0026amp;rdquo;，温度=29，当然这里都省略了时间戳。这个表达式并没有指出监测对象，传统 Metrics 的做法是，将监测对象的信息编码到 Name 里，因此可能就变成了 \u0026amp;ldquo;temperature.hangzhou=29\u0026amp;rdquo;。这里是有一些隐式的 Tags 信息的，只是被编码到 Name 里了。\n这种做法很快会导致一个问题，我们来看下一个例子： shanghai.host1.foo.exporter.bar 。 只看这个名字的话几乎很难知道这个 Metrics 统计的是什么。这是因为它并没有把字段对应的 Key 编码到名字里，所以在缺少一些上下文的情况下，我们很难读懂它的含义。\n另外，字段的顺序也是很重要的，不能写错，这是因为编码到 Name 里的只有 Tag 的 Value，Key 不在里面，于是又有了另外一种编码方式：zone.shanghai.host.host1.app.foo.counters.exporter.bar 。这种方式将 Tag 的 Key 也编码在Name 里。但带来的问题也很明显：Name 越来越长。\n我们再看下一个例子： login.success.h5，它想表达来自 H5 平台登录成功的次数。假设我们还有其他平台，比如安卓、IOS，我们想求所有平台的总登录成功次数，那么就需要做一个聚合操作。通常时序数据库会提供型号来匹配所有值。\n其实上面这些都是旧版本 Graphite 的例子, 不过它在 2017 年底的版本支持了 Tags 概念，所以已经不能拿新版来当反面教材了。\n这是 Dropwizard 客户端的一个简单 Demo，它是一个很流行的 Metrics 埋点客户端，但是只能支持传统 Metrics 的概念。\nMetricRegistry registry = new MetricRegistry(); Counter h5Counter = registry.counter(\u0026amp;quot;login.success.h5\u0026amp;quot;); h5Counter.inc(); 1.3.2 Metrics 2.0 我们再来看 Metrics 2.0，其实 Metrics 2.0 也就只是多了 Tags 的概念，这里同样省略了 Timestamp。\n这是 OpenTSDB 风格的数据描述。\n{ \u0026amp;quot;metric\u0026amp;quot;: \u0026amp;quot;login.counter\u0026amp;quot;, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;result\u0026amp;quot;: \u0026amp;quot;success\u0026amp;quot;, \u0026amp;quot;platform\u0026amp;quot;: \u0026amp;quot;h5\u0026amp;quot; }, \u0026amp;quot;timestamp\u0026amp;quot;: 1560597254000, \u0026amp;quot;value\u0026amp;quot;: 100 } 这是 Prometheus 的描述方式。\ntemperature{city=\u0026amp;quot;hangzhou\u0026amp;quot;}=29 这是对应的 lookout-client 的埋点代码。\nRegistry registry = …; Id loginCounter = registry.createId(\u0026amp;quot;login.counter\u0026amp;quot;); Id id = loginCounter.withTags( \u0026amp;quot;result\u0026amp;quot;, \u0026amp;quot;success\u0026amp;quot;, \u0026amp;quot;platform\u0026amp;quot;, \u0026amp;quot;ios\u0026amp;quot; ); registry.counter(reqId).increment(); 可以看到它们都显式支持了 Metrics 2.0 的概念。\n这里我们花了点时间强调传统 Metrics …","date":1561705200,"description":"本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。","dir":"blog/sofa-channel-6-retrospect/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"27fcb53174efd0b72fcee578993cae38","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-6-retrospect/","publishdate":"2019-06-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-channel-6-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。 回顾视频以及 PPT 查","tags":["SOFALookout","SOFAChannel"],"title":"蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-6-retrospect/","wordcount":4165},{"author":"卓与","categories":"SOFAStack","content":" 本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。分享基于 Service Mesh 的理念，结合蚂蚁金服内部实际场景，将中间件、数据层、安全层等能力从应用中剥离出来后下沉至独立的 Sidecar SOFAMosn 中，结合 Kubernetes 运维体系，提供应用无感知的情况下升级基础设施层能力的案例。\n本次分享将从以如下次序展开进行：\n蚂蚁金服当前的服务化现状 在看蚂蚁金服的服务化架构之前我们先从一个简单的服务化调用示例说起，下图是 SOFARPC 基本原理：\n我们从上图可以看出，构建一个服务化框架需要有服务注册中心，有服务定义，调用方和服务提供方使用相同的服务定义来互相通讯。通过服务注册中心，调用方可以直接订阅到服务提供方的地址，采用点对点的方式直接发起请求。客户端内可实现服务发现、路由寻址、负载均衡、限流熔断等能力来增强服务通讯能力。通过我们开源的 SOFARPC、SOFARegistry、SOFABoot，用户已经可以直接构建起微服务体系，助力业务发展。\n蚂蚁金服发展至今，双 11 系统需要应对的交易洪峰逐年递增：\n每秒 26.5 万笔交易是 2017 年双 11 的峰值数据，这个数据背后有非常复杂的架构支持，LDC 单元化架构是蚂蚁金服沉淀多年的核心架构，依靠这个架构实现每年峰值交易量飞速增长下系统依然能平滑渡过。我们来简要看下 LDC 架构：\n上图摘自 金融级分布式架构 中的 素描单元化 一文，这里不详细展开。LDC 的单元化架构给应用的服务化带来更多的规范与抽象，服务路由中需要考虑单元间的调用，跨机房调用等更多场景。这里主要希望表达的是 LDC 架构给 RPC 调用带来更高的复杂度。\n服务化痛点 中间件版本升级 在上面介绍背景时，有介绍到目前 LDC 架构下服务调用的复杂度，这些复杂度目前是直接体现在应用的代码中。对于业务同学来讲，一个应用的关注重点是如何实现业务逻辑，至于高可用、容灾等能力更多是整体架构层面会考虑的点。应用内通过引入 RPC 的 jar 包即可获得 LDC 架构下服务调用各种能力的支撑，带来便利的同时也可以看到这种模式的缺点：\n应用内除业务逻辑之外，由中间件的 SDK 引入大量外部依赖，来完成服务发现、路由寻址、负载均衡、限流熔断、序列化、通讯等能力，每个组件的引入都可能带来稳定性风险，以及更高的升级成本。\n根据目前 SOFARPC 在内部的版本举例，服务发现依赖 SOFARegistry 的客户端做 IDC 内的服务发现，依赖 Antvip 做跨 IDC 的服务发现，ZoneClient 集成 LDC 架构的单元化信息，路由寻址需要根据请求的入参计算目前 Zone 然后确定调用目标，限流熔断依赖 Guardian 组件，通讯协议与序列化协议相对稳定，变更较少。仅为了完成服务调用，应用需要额外引入 7+ 客户端包。\n每年双 11 需要涉及到架构调整时：比如支持弹性架构，需要做很多中间件客户端的版本升级来支撑更优的架构，对于业务同学来讲，这些升级是很耗费精力的，拿 200 个核心应用举例，每个应用升级中间件版本经过研发、测试、再到部署预发、灰度、生产等环境需要 5个人日的话，200 个核心应用中间件升级需要耗费 1000 人日，如果这部分时间可以节省出来，每年架构升级可以节约大量人力资源。\n跨语言通讯 蚂蚁金服发展至今，内部业务百花齐放，搜索推荐、人工智能、安全等各种业务使用到的技术栈非常多样化，跨语言的服务通讯能力也十分重要。早在几年前，Java 之外规模最大的就是 NodeJS 应用，为了让 Java 和 NodeJS 应用之间可以复用蚂蚁金服内部的各种中间件和基础设施，前端团队使用 NodeJS 逐步重写了各种中间件客户端，让整个 NodeJS 和 Java 体系可以完美互通。\n中间件 SDK 跨语言重写与维护成本极高，随着语言种类的增多，跨语言通讯的诉求也越来越多。\nJava, NodeJS, Go, Python, C++ 等，5+ 语言，中间件 SDK 全部重写成本极高。这些问题不得不激励我们寻找更优的解法。\n解决痛点 SDK 能力下沉 依然以上述 RPC SDK 举例，SDK 中的能力我们可以根据稳定性与不可剥离等特性来看，哪些是可以从应用中抽出来的，尽量把 SDK 做薄，做的足够稳定无需变更，那么升级成本将不复存在。\nRPC SDK 中的服务发现、路由寻址、限流熔断等特性，是更易于变更的，我们将这部分能力下沉至独立的 Sidecar 中，可以复用这部分能力，让多语言的 SDK 只实现最基本的序列化与通讯协议，而这些能力是很轻量且易于实现的。这里的 Sidecar 我们是希望它作为独立进程存在，和业务应用的进程剥离，并和业务应用的升级解耦开来，实现业务和基础设施并行发展，互不干扰的愿景。\n除了 RPC 通讯，我们还可以下沉消息、数据源等能力至 Sidecar 中，业务应用可以越来越薄，SDK 实现成本也降低到可接受的程度，基础设施层与业务剥离，双方均可独立演进。\n落地架构 整体架构 不同于开源的 Istio 体系，蚂蚁金服内部版 Service Mesh 落地优先考虑数据面的实现与落地，控制面在逐步建设中，整体的架构上看，我们使用数据面直接和内部的各种中间件服务端对接，来完成 RPC、消息等能力的下沉，给业务应用减负。由上图可以看出，我们将不同的 Sidecar 与业务应用编排在同一个 Pod 中，App 与 Mosn 直接通讯，Mosn 来负责目标接口的服务发现、路由寻址，并且由 Mosn 内置的安全模块来做应用间调用的加密鉴权。通过 DBMesh 的 Sidecar 来实现数据层的下沉，App 不在需要与多个数据源建立连接，只需要连接本 Pod 内的 DBMesh 即可完成数据层调用，数据库的用户名、密码、分库分表规则等均不再需要关心。\n图中名词解析：\nConfigServer：配置中心，负责各种元数据配置、动态开关等。\nRegistry：服务注册中心，负责 IDC 内服务发现。\nAntVip：类 DNS 解析的产品，可通过域名解析一组目标地址，用于跨 IDC 服务发现。\nMQ：消息中心服务端，用于收发消息。\n落地数据 目前这套架构已经在支付核心链路中做试点，618 大促 Mesh 化应用对比无 Mesh 化应用 CPU 损耗增长 1.7%，单笔交易整体耗时增长 5ms。CPU 增长是由于多出一个进程，请求增加一条之后，RT 会有稳定的小幅增长，但这些成本相比于整体架构带来的红利，微乎其微，并且针对整个数据面的持续优化是有望逐步减少资源占用，提升资源利用率。\n降低打扰度 中间件能力下沉在架构上看是可行的，实际落地如何做到无打扰的在奔跑的火车上换轮子，低打扰是一个非常重要的考量点。借助于 Kubernetes 的优秀实践，将业务容器与 Sidecar 容器编排在同一个 Pod 中是比较合理的架构，Sidecar 与业务容器互不干扰，互相升级均可做到双方无感。\n我们为了让业务应用升级尽可能如丝般顺滑，主要做了 …","date":1561359600,"description":"本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。","dir":"blog/service-mesh-giac-2019/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7cfc7c8a7b735c31418186aae0ca99a2","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-giac-2019/","publishdate":"2019-06-24T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/service-mesh-giac-2019/","summary":"本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。","tags":["SOFAStack","Service mesh"],"title":"蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-giac-2019/","wordcount":4572},{"author":"雾渊","categories":"SOFAArk","content":"  本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。感谢溢米教育对 SOFAStack 的支持，同时也欢迎更多用户投稿 Join us。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服开源贡献。\n写在前面 个性化推荐，相信大家都不陌生，简单来说就是根据每个人的偏好经过模型计算推荐出适合的东西，这些东西可以是视频、商品、文章、电影等。经过互联网这几年的发展，个性化推荐已经无处不在，不管是电商、教育、游戏、金融行业，推荐系统对业务的提升都有着非常重要的帮助。溢米教育作为一家互联网教育平台，近几年推荐业务发展非常迅速，技术团队也在持续的进行能力提升。业务快速增长的同时，亟需一个高效率、高稳定的推荐系统来支持推荐场景。\n本文是根据我们内部推荐平台效率与稳定性建设的实际经验整理，介绍了溢米教育推荐系统的改造优化。在整个过程中我们基于公司架构做了分析，确认了技术选型和改造方案，最终选择基于 SOFAStack 社区开源的 SOFAArk 组件开发框架，极大的提升了我们推荐系统的开发效率和稳定性。希望能给有同样困扰的技术团队参考。\n背景 一次完整的个性化推荐，通常包括召回、过滤、排序等步骤。虽然步骤不多，但是涉及到的逻辑是非常多的，包括 abtest、用户画像、物品画像、离线数据、在线数据、模型系统、字段补全等等。个性化推荐极为依赖场景定制化，不同的场景对应不同的处理逻辑。\n我们可以想象，把这一堆处理逻辑都放在一个系统里面，应用会变得十分臃肿和复杂，随着业务系统不断的迭代更新，逐渐会变得难以维护，开发效率和系统稳定性都会面临不小的挑战。不幸的是，随着溢米业务快速发展，内部的推荐平台已经变得 “过劳肥”。不管是迭代效率、性能、稳定性都遇到了瓶颈，比如：\n 发布耗时：算法团队一个人跟进一条业务线，导致业务迭代频繁、应用发布非常频繁，由于系统本身复杂性，这么一个庞然大物发布一次非常慢，降低了工程师效率；\n 系统臃肿：所有模块统一维护，包含了存储、算法、业务等，几乎每次迭代都是只增不减，降低了系统可维护性；\n 覆盖风险：多个团队共同维护一份代码，分支上容易存在冲突，合并代码存在覆盖风险，降低了团队合作效率；\n 版本不一致：不同业务团队使用的 jar 包版本不一致，每次升级一个 jar 包都会引起很多问题，导致各个团队在开发期间都要花费不少精力解决依赖冲突；\n 基于上述背景，溢米推荐平台不得不进行应用瘦身和系统改造，从而提升平台的开发效率和稳定性。然而在实际的改造过程中，我们不难发现这两者其实是互相冲突的。为了提高稳定性，我们肯定要做到流程上的把控，比如测试、灰度、发布等流程的规范，这势必会影响业务迭代效率；反过来如果要提升效率，那么在流程上肯定会有一定的舍弃，随之而来的是稳定性的潜在风险。 但是人总是需要梦想驱动的，每个工程师都希望能用一种架构或者方案，同时解决很多通用的问题，节约成本，提升效率， 让设计人员能够不至于疲于奔命， 解放生产力来完成更多有创新有挑战的工作。\n调研 效率和稳定性并非一定是二选一，在进行推荐平台升级改造之前，我们梳理了溢米内部影响业务效率和系统稳定性的主要因素。\n 开发效率 系统稳定 影响因素 业务复杂度+开发复杂度 业务变更：代码变更+数据变更 业务迭代流程+开发流程 非业务变更：配置变更+代码变更 业务变更+服务变更上线 流量变化 稳定性流程 硬件故障 关于开发效率，从上面可以看出来除了开发部分是依赖平台所能提供的便利和开发者个人技术能力之外，其余大部分都是流程上的把控。这些流程上的把控一是为了保障业务迭代的正确性，二是为了提升业务迭代带来的线上服务稳定性，但是简单的流程不足以把控住这些点，而过度复杂的流程会很大程度上影响业务迭代效率，所以我们需要思考并且寻求一种平衡，比如如何降低业务开发复杂度？如何提升平台提供的便利？如何在不影响稳定性的情况下简化业务迭代和维护流程？\n关于稳定性，我列举几个在溢米内部遇到的几个类似案例：\n 推荐服务性能优化上线，功能性测试没有问题，但是没有经过压测导致高峰期服务能力下降，最终导致整个服务不可用，而上游由于没有做好服务治理也受影响变成了服务不可用； 推荐服务所依赖的某个数据源或者 RPC 响应从 10ms 突然增长到 100ms，从而导致推荐服务主要线程池耗尽，最终导致服务不可用； 上游压测或者流量推广或者爬虫导致流量激增，但是推荐服务没有做好限流导致服务被打垮而不可用； 推荐系统依赖业务系统提供的RPC服务进行过滤，由于此RPC服务变更导致响应变慢，而推荐服务没有区分强弱依赖导致整体服务超时； 某个业务由于排期时间紧张，测试周期太短，上线后导致其它业务异常； 结合这些案例和上文总结的系统稳定性影响因素，可以发现除了硬件故障是不可控之外，其余几点基本都是因为变更而引起的。那么如何不受变更影响而提升稳定性呢？上面我们介绍过最主要也是最有效的是变更流程控制，通过测试、灰度、发布流程规范，其余也可以通过技术手段来控制，比如性能优化、服务治理、业务隔离、强弱依赖区分、多机房容灾、扩容等等。\n针对以上开发效率和稳定性分析，最开始确定如下了改造目标：\n 场景模块化 系统瘦身，拆分模块，提高系统可维护性 模块复用，提升开发效率 模块开发时隔离 各模块单独迭代开发，解决之前统一迭代开发的代码冲突问题 各模块单独测试，提升测试效率 模块运行时隔离 模块运行时类隔离，解决模块间包冲突问题 模块间有明确的服务边界，一定程度的故障隔离 模块动态可插拔 动态升级，秒级发布回滚 改造 为了满足改造目标，我们初步确认了三个选择：\n 采用自定义 SPI 的 ServiceLoader 动态加载实现； 采用自定义 Classloader 实现； 寻求开源软件支持。 基于资源成本、时间成本的考虑，我们选择了寻求开源支持，蚂蚁金服开源其分布式架构吸引了我们的关注，经过技术判断，我们最终决定使用 SOFAStack 社区开源的 SOFAArk 组件开发框架。\nSOFAArk 定义了一套相对简单的类加载模型、特殊的打包格式、统一的编程界面、事件机制、易扩展的插件机制等，从而提供了一套较为规范化的插件化、组件化的开发方案。更多内容可以参考官方文档：\nSOFA JVM 服务： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-ark-jvm\nSOFAArk 官方文档： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-readme\nSOFAArk 源码： https://github.com/sofastack/sofa-ark\n通过 SOFAArk+SOFABoot 的组合，我们将应用进行拆分，分为宿主应用+数据模块+业务模块：\n 主应用：负责整个容器的状态保持； 数据模块：负责数据通信，包括 Redis，DB，RPC 等基础服务； 业务模块：只需要负责调用数据模块进行业务实现， …","date":1560409200,"description":"本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。","dir":"blog/sofastack-user-yimi/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"967e9a815b24a3b000d5ecd90c59b8fb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-user-yimi/","publishdate":"2019-06-13T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofastack-user-yimi/","summary":"本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。感谢溢米教育对 SOFAStack 的支持，同时也欢迎更多用户","tags":["SOFAArk"],"title":"溢米教育推荐平台的效率与稳定性建设 | SOFAStack 用户说","type":"blog","url":"/sofastack.tech/blog/sofastack-user-yimi/","wordcount":3303},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 活动时间：6 月 12 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 6 月 27 日周四晚 7 点，将邀请 蚂蚁金服 SOFALookout 开源负责人 响风 为大家分享，通过对多个模块的剖析，详解 SOFALookout 服务端以及客户端，带你了解 SOFALookout 具体是如何支持主流 Metrics协议的数据收集、存储、查询计算和可视化的。欢迎报名参加~\nSOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务，提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\n本期分享大纲：\n 监控预警基本概念介绍 SOFALookout 客户端使用 Gateway - 多协议数据收集与处理的设计与实现 Server - PromQL 与多种存储层的设计与实现 SOFALookout 发展路线 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/687\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 轻量级监控分析系统 SOFALookout 原理讲解和功能演示 响风 蚂蚁金服轻量级监控分析系统 SOFALookout 开源负责人\n本期分享大纲： 监控预警基本概念介绍 SOFALookout 客户端使用 Gateway - 多协议数据收集与处理的设计与实现 Server - PromQL 与多种存储层的设计与实现 SOFALookout 发展路线 嘉宾 SOFAGirl 主持人 响风 蚂蚁金服轻量级监控分析系统 SOFALookout 开源负责人 ","date":1560312000,"description":"6 月 12 日周四晚 7 点，线上直播第 6 期。","dir":"activities/sofa-channel-6/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"29a5673d4608770bbe7598954fcecc78","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-6/","publishdate":"2019-06-12T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-6/","summary":"概要 活动主题：SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 活动时间：6 月 12 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直","tags":["SOFAChannel","SOFALookout"],"title":"SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示","type":"activities","url":"/sofastack.tech/activities/sofa-channel-6/","wordcount":637},{"author":"卿祤、 首仁","categories":"SOFAStack","content":" 由蚂蚁金服主办的 SOFAStack Cloud Native Workshop 将在 6月24日于 KubeCon + CloudNativeCon + Open Source Summit China 大会的同场活动中进行，欢迎报名参与，更多信息可见此链接。 欢迎加入 SOFA 钉钉互动群（钉钉搜索群号）：23195297\n 楔子 为支撑业务高速发展并积极拥抱主流技术，我们从 2017 年开始探索并构建以Kubernetes为核心的云原生应用 PaaS 平台。在 2018 年，我们已在网商银行顺利落地了 K8S 容器引擎，并顺利支撑了 2018 年双十一。2019 年伊始，国泰产险作为互金行业的典型代表，正基于 SOFAStack 容器应用服务和监控分析产品探索云原生架构转型。时至今日，已完成了关键业务 SOFABoot 应用的容器化改造，在开发、测试乃至灰度生产环境践行云原生的运维实践。\n这将是一系列技术分享文章的开端，基于在实际金融机构和场景中落地的云原生产品项目经验，我们希望和大家一起分享从中获得的洞察和总结，探讨我们的产品观点、技术实现，并非常期待大家的建议和指点，欢迎一起交流共创。\n云原生容器产品的金融机构落地挑战 从去年开始，云原生、Kubernetes、容器这些关键字逐渐从社区走向金融科技圈，越来越多的金融机构客户开始向我们咨询，云原生技术是什么，能够给企业带来什么价值，对现有业务有什么影响？落地的路径可能会是哪些？\n我们的观点是，金融场景下的云原生，绝对不止是 12Factors，亦不止是 CNCF TOC 所定义的 5 大件，我们不仅要提供标准、通过一致性认证的 Kubernetes 产品，还需要满足更多金融场景需求，创造实际业务价值。\n经过很长一段时间的产品研发实践、深挖内外容器平台落地诉求，金融客户的关注点可能包括但不限于以下几点：\n 业务采用了云原生能否节省资源，提升工程效率？ 发现问题后如何做到快速止损，甚至线上零故障？ 如何在云原生下做到业务同城双活甚至异地多活的高可用容灾能力？ 能否和现有业务能无缝集成，如何做平滑升级？ 采用了云原生平台能否保证和现有云上一致的安全性？ 云原生能否支撑大规模分布式系统的架构？ \u0026amp;hellip; 而基于以上实际场景下的落地挑战，我们对自身容器平台产品的设计和实施，提出了以下六大关键价值主张：\n云原生容器产品的价值主张 一 使用 Immutable Infrastructure 的思想进行设计 在 PaaS 平台中，核心是应用。在之前的经典运维体系中，要对应用打一个全量快照不是件容易的事情，但在云原生世界中，会方便许多。从描述流量接入层的 Service 到描述应用配置和代码包的 Pod template，这些已是 kubernetes 的标准 Resources。\n为了解决应用管理需求，我们定义了一个 CafeAppService 对象，用于整体描述上述内容，并通过 Revision 对象属性作版本控制（和 Knative 中的 Revision 类似）。用户每次的修改都是一个 Revision，发布一个应用本质上是发布该应用的一个 Revision，故可做到快速的弹性扩缩容，并且可以方便回滚到之前发布成功过的 Revision。相比之前基于包的经典发布运维体系，效率有极大提升。\n二 可审计和无损应用发布的能力 发布变更是 PaaS 平台提供的重要能力。对于金融客户来说，每次发布必须要有据可查，而且要保证安全无损。这里，我们将蚂蚁的安全生产理念融入其中，在产品层面上提供“可灰度，可回滚（应急），可监控”的能力。\n为了做到上述能力，我们提供了发布单的概念，并定义了一个原生的 CRD：CafeDeployment。接下来逐一介绍。\n发布单 主要两个用途：做应用发布的审查记录，用于统计分析，故障复盘回顾等；协调多个应用的发布顺序，这是由于金融业务对系统的可靠性要求高，尤其在涉及资金的主链路，另外，不少系统由于业务原因，存在依赖关系，必须做有序发布。\nCafeDeployment 在这里只做简单介绍，后续会有专题介绍。该 CRD 拥有三种能力：\n 原地升级（InplaceSet）:升级过程中 Pod 的 IP 保持不变，可和经典的运维监控体系做无缝集成。 替换升级（ReplicaSet）:和社区版本的 ReplicaSet 能力保持一致。 有状态应用（StatefulSet）:和社区版本的 StatefulSet 能力保持一致。 除此之外，相比社区的 deployment，还具备 beta 验证，自定义分组策略，分组暂停，引流验证（配合 ServiceMesh）的能力。\n三 具有高可用容灾能力的工作负载 金融业由于监管的要求对系统可用性和容灾能力具有很高的要求。从应用的生命周期来看，最主要有两个状态：发布态 和 运行态。\n对于发布态，由于存在 Pod 上下线的过程，线上有抖动不可避免，要做的是尽可能的降低抖动幅度以及降低系统报错率。kubernetes 的 deployment 在发布一个 pod 时，pod 里容器的 kill 和对应 endpoint 的销毁是异步的，这就意味着可能出现 pod 里应用容器已经 kill 了，但仍然会有流量打到该 Pod，导致出现报错，甚至故障。为了防止这种情况，我们采用 finalizer 的机制，保证在南北流量和东西流量（7 层协议）都切断的情况下才对 Pod 进行更新。\n同时，还通过 CafeDeployment 里的灰度发布策略，保证发布态时线上系统的水位不会过低，防止出现流量过载，造成系统异常。\n对于运行态，要考虑以下几个方面：Pod 异常退出后的重新上线，Node 故障后的 Pod 的迁移，机房级故障后系统仍然可用。对于第一点，Kubernetes 本身已经有了较好的机制；第二点，我们做了增强，使用自定义的 NodeLifecycle Controller 结合更加详细的监控信息来判断Node是否出现故障，然后做 Pod 迁移；第三点，从 Scheduler 方面进行保障，CafeDeployment 可以定义相应的高可用拓扑结构，以同城双活为例，在创建 Pod 时，调度器会根据定义好的拓扑信息尽量将 Pod 均分到不同的可用区，达到同城双活的状态。\n四 一致的验证授权体验 蚂蚁金服 PaaS 平台在近 4 年的时间里，已经有了一套完整的 IAM 体系，并且许多客户已经基于此定义了许多的角色，用做安全防护。我们从两方面来提供一致性的体验：\n首先，在产品上的操作上提供和原先一样的验证授权机制。只要客户将 K8S 内预先定义好的角色或者权限分配相应的用户或用户组，那该用户或者属于该用户组的用户就能在产品上做相应的操作。\n其次，IAM 的权限和角色与 Kubernetes 的 RBAC 做映射。根据用户在 IAM 所具备的角色，在 Kubernetes 集群中创建相应的 ClusterRole，并生成访问 Kubernetes 集群的 token，创建 ClusterRoleBinding 与 token 绑定。这样用户使用 kubectl 操作集群时也可以具备相同的权限，保证权限 …","date":1559890800,"description":"这将是一系列技术分享文章的开端，基于在实际金融机构和场景中落地的云原生产品项目经验，我们希望和大家一起分享从中获得的洞察和总结，探讨我们的产品观点、技术实现，并非常期待大家的建议和指点，欢迎一起交流共创。","dir":"blog/sofa-financial-cloud-native-exploration/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9c93781d7d4b980b1990e4655445d4bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","publishdate":"2019-06-07T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","summary":"由蚂蚁金服主办的 SOFAStack Cloud Native Workshop 将在 6月24日于 KubeCon + CloudNativeCon + Open Source Summit China 大会的同场活动中进行，欢迎报名参与，更多信息可见此链接。 欢迎加入 SOFA 钉钉互动群（钉钉搜","tags":["SOFAStack"],"title":"金融级云原生探索实践系列 - 开篇","type":"blog","url":"/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","wordcount":3874},{"author":"墨睿","categories":"SOFALookout","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFALookout 是在 SOFAStack 体系内研发开源的一款解决系统的度量和监控问题的轻量级中间件服务。本文给大家介绍下 SOFALookout 服务器端主要提供的特性以及使用方式。 SOFALookout：https://github.com/sofastack/sofa-lookout\n 前言 容器，K8S，微服务，Mesh 以及 Serverless 这些新技术方向正在根本的变革我们运行软件的方式。我们构建的系统更加分布式化，另外由于容器，系统的生命周期更加短，变得易逝。针对这些变化，SOFALookout 希望提供一套轻量级解决方案。之前 SOFALookout 已经开源客户端的能力。今天，SOFALookout 服务器端 Metrics 部分的代码终于正式开源啦！本文给大家介绍下 SOFALookout 服务器端的主要特性以及使用方法。\n什么是 SOFALookout SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\nSOFALookout 目标是打造一套轻量级 Observability 实时工具平台，帮助用户解决基础设施、应用和服务等的监控和分析的问题。SOFALookout（目前已开源部分） 是一个利用多维度的 metrics 对目标系统进行度量和监控的项目。SOFALookout 的多维度 metrics 参考 Metrics2.0 标准。\nSOFALookout ：https://github.com/sofastack/sofa-lookout\nSOFALookout 安装文档：https://www.sofastack.tech/sofa-lookout/docs/quickstart-metrics-server\n SOFALookout 服务器端的主要特性:\n 适配社区主要 Metrics 数据源协议写入（比如: Prometheus，Metricbeat 等）； 数据的存储支持扩展，暂时开源版默认支持 Elasticsearch， 并且透明和自动化了相关运维操作； 遵循 Prometheus 查询 API 的标准以及支持 PromQL，并进行了适当改进； 自带数据查询的控制台，并支持 Grafana 进行数据可视化； 使用简单，支持单一进程运行整个服务器端模块。 随着 SOFALookout （metrics）服务器端代码开源，metrics 数据的处理已经形成闭环。后续我们将会进一步开源 Trace 和 Event 相关的服务能力，敬请期待。\nSOFALookout 项目结构 服务器端代码分别包括两部分：Gateway 模块和 Server 模块。如下图所示（展示了 SOFALookout 源码项目的模块概要结构）\n├── boot ├── client ├── gateway └── server 项目中的 boot 模块作用是方便集成和运行服务端的模块，既可以单独运行 Gateway 和 Server 的服务，也可以借助 SOFAArk 完成（Gateway 和 Server）的 All in One 的合并为单一进程运行。\nSOFALookout 工作机制 下图完整展示了 SOFALookout 如何从 metrics 数据采集、上报、存储到最终展示的完整流程路径。\n目前 SOFALookout 支持灵活的 metrics 数据存储选型。但开源版本我们暂时只支持了 Elasticsearch 作为存储的方案（后续可能继续支持 Cassandra,InfluxDB\u0026amp;hellip;），其他存储地适配我们希望更多同学能参与共建和支持。优先支持 Elasticsearch 是因为我们考虑到了 ELK 解决方案在业界已经广泛使用，尤其是日志数据。\n为了开箱即用，同时考虑到不熟悉 Elasticsearch 的同学的使用，SOFALookout已经内置了关于 metrics 数据存储的自动化运维工具，可以免除大家自己建 Index，和日常维护 ES Index 的麻烦，更多细节后续单独讲解。\n本次新增开源模块 一、SOFALookout Gateway 模块 SOFALookout Gateway 轻量的数据管道，它提供丰富的协议接入支持，包括自有SDK（SOFALookout Client）上报协议，还支持 Prometheus 的数据协议（推模式和拉模式），Metricbeat 协议（版本是6），OpenTSDB 写入协议。每种数据来源对应于一个 Importer 的概念。\nSOFALookout Gateway 对于远程（推模式）上报提供本地硬盘缓冲的支持。Gateway 总体设计是围绕数据加工的Pipeline 形式，包括前置后置的数据过滤器方便进行开发者数据加工。 另外 Gateway 可以支持自定义 Exporter，默认提供了 Elasticsearch Exporter，Standard Exporter(用于 Gateway 间数据中继)，开发者也可以自定义其他存储的 或 Kafka 等各式各样 Exporter。\n二、SOFALookout Server 模块 SOFALookout Server 兼容和增强了 Prometheus 的数据及元数据查询的 RESTful API。同样对应 PromQL 我们也基本实现了兼容和增强（不包括 Alert 相关语法），SOFALookout 的 promQL 相关解析逻辑是从 Prometheus 移植而来，做了一些优化和改进， 感谢 Prometheus 开源了如此易用和强大的 golang 版本的 QL 实现。\n为了方便方便开发者做数据探索和试验，我们也提供了自有 Web-UI 的支持，能够满足基本功能使用。\n我们还是推荐大家使用 Grafana 进行数据展示。Grafana 集成 SOFALookout 很简单，只需要选择 Prometheus 作为数据源协议即可（SOFALookout默认查询端口也是: 9090）。下图展示 Grafana 新增数据源配置：\n近期计划 下图是近期的 Roadmap：\n非常欢迎更多同学参与 SOFALookout 共建，尤其是支持更多的 Metrics 存储库。\n","date":1559804400,"description":"本文给大家介绍下 SOFALookout 服务器端主要提供的特性以及使用方式。","dir":"blog/sofa-lookout-server-open-source/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d80fe27f8652b6e8a8da8d712a90a027","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-lookout-server-open-source/","publishdate":"2019-06-06T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-lookout-server-open-source/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFALookout 是在 SOFAStack 体系内","tags":["SOFALookout"],"title":"轻量级监控分析系统 SOFALookout 服务端开源","type":"blog","url":"/sofastack.tech/blog/sofa-lookout-server-open-source/","wordcount":1970},{"author":"Jimmy Song","categories":null,"content":" SOFAStack Cloud Native Workshop hosted by Ant Financial (KubeCon China 2019 Co-Located Event) Date: Monday, 24 June, 2019 Time: 9:00 – 16:00 Location: Shanghai Expo Centre Room 616 Registration Fees: Complimentary Register here: https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop Note: This event is hands-on, please bring your personal computer. The language of communication in this workshop is Chinese. SOFAStack (Scalable Open Financial Architecture Stack) is a financial-grade distributed architecture independently developed and open sourced by Ant Financial. It contains the components required to build a financial-grade cloud native architecture. It is a best practice tempered in financial scenarios. SOFAStack official website: https://www.sofastack.tech/\nAttendees can get:\n Rapidly build microservices based on SOFAStack Best Practices for Distributed Transactions in Financial Scenarios Cloud native deployment experience based on Kubernetes Service Mesh basic usage scenario experience on the cloud Get started on Serverless apps Easily build applications on the cloud based on Serverless How to Register: Pre-registration is required. To register for SOFAStack Cloud Native Workshop, add it on during your KubeCon + CloudNativeCon + Open Source Summit registration. You can get KubeCon half price tickets with KCCN19COMATF coupon code!\nFor questions regarding this event, please reach out to jingchao.sjc@antfin.com.\nEvent details 9:00 - 9:20 Opening speech SOFAStack Cloud Native\n9:20 - 10:10 Quickly build microservices with SOFAStack by Jie Cao\nBuilding a microservices application based on the SOFAStack. Through this workshop, you can learn how to report application monitoring data, service link data, and publish and subscribe services in the SOFAStack.\n10:15 - 11:05 SOFABoot dynamic module practice by Guolei Song\nIn this workshop, you can implement the combined deployment and dynamic module push capabilities provided by SOFAArk based on the ARK control capabilities of SOFADashboard.\n11:10 - 12:00 Using Seata to guarantee the consistency of payment by Long Chen\nUnder the microservice architecture, the distributed transaction problem is an industry problem. Through this workshop, you can understand the background of distributed transaction problems under distributed architecture, as well as common distributed transaction solutions and experience on how to use the open source distributed transaction framework - Seata\u0026amp;rsquo;s AT mode, TCC mode to solve the ultimate consistency of the business data.\n12:00 - 13:00 Lunch time\n13:00 - 13:30 Cloud Native exlporation and practice in Ant Fnancial by Renjie Yu\n13:30 - 14:40 Migrating to cloud based on Serverless by Yitao Dong\nAs one of the pioneering technologies of cloud technology, Serverless architecture allows you to further improve resource utilization and focus on business development. Through our workshop, you can experience new product …","date":1559643600,"description":"","dir":"activities/sofastack-cloud-native-workshop/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"57c6b0262af34c2010179000834d8363","permalink":"https://sofastack.github.io/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","publishdate":"2019-06-04T10:20:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","summary":"SOFAStack Cloud Native Workshop hosted by Ant Financial (KubeCon China 2019 Co-Located Event) Date: Monday, 24 June, 2019 Time: 9:00 – 16:00 Location: Shanghai Expo Centre Room 616 Registration Fees: Complimentary Register here: https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop Note: This event is hands-on, please bring your personal computer. The language of communication in this workshop is Chinese. SOFAStack (Scalable Open Financial Architecture Stack) is a financial-grade distributed architecture independently developed and open sourced by Ant Financial.","tags":["KubeCon","Workshop","Cloud Native"],"title":"KubeCon China 2019 Co-Located Event SOFAStack Cloud Native Workshop","type":"activities","url":"/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","wordcount":515},{"author":"宋净超","categories":null,"content":" 蚂蚁金服 SOFAStack 云原生工作坊（KubeCon China 2019 同场活动） 日期：2019年6月24日，星期一 时间：9:00 – 16:00 地点：上海世博中心 616 房间 注册费：免费 注册地址：https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop 备注：本次活动为动手实践，请携带个人电脑。本沙龙沟通语言为中文。 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发并开源的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。SOFAStack 官方网站：https://www.sofastack.tech/\n参加此次 Meetup 您将获得：\n 基于 SOFAStack 快速构建微服务 金融场景下的分布式事务最佳实践 基于 Kubernetes 的云原生部署体验 云上的 Service Mesh 基本使用场景体验 基于 Serverless 轻松构建云上应用 如何注册：此活动须提前注册。请将 SOFAStack Cloud Native Workshop 添加到您 KubeCon + CloudNativeCon + Open Source Summit 的注册表里。您可以使用 KCCN19COMATF 折扣码获取 KubeCon 半价门票！\n如果对此活动有任何疑问，请发送邮件至 jingchao.sjc@antfin.com。\n活动详情 9:00 - 9:20 开场演讲 SOFAStack 云原生开源体系介绍 by 余淮\n9:20 - 10:10 使用 SOFAStack 快速构建微服务 by 玄北\n基于 SOFA 技术栈构建微服务应用。通过本 workshop ，您可以了解在 SOFA 体系中如何上报应用监控数据、服务链路数据以及发布及订阅服务。\n10:15 - 11:05 SOFABoot 动态模块实践 by 卫恒\n在本 workshop 中，您可以基于 SOFADashboard 的 ARK 管控能力来实现 SOFAArk 提供的合并部署和动态模块推送的功能。\n11:10 - 12:00 使用 Seata 保障支付一致性 by 屹远\n微服务架构下，分布式事务问题是一个业界难题。通过本workshop，您可以了解到分布式架构下，分布式事务问题产生的背景，以及常见的分布式事务解决方案；并亲身体验到如何使用开源分布式事务框架Seata的AT模式、TCC模式解决业务数据的最终一致性问题。\n12:00 - 13:00 午餐时间\n13:00 - 13:30 蚂蚁金服的云原生探索与实践 by 首仁\n13:30 - 14:40 通过 Serverless 快速上云 by 隐秀\n作为云原生技术前进方向之一，Serverless 架构让您进一步提高资源利用率，更专注于业务研发。通过我们的 workshop，您可以体验到快速创建 Serveless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错、按时间触发应用等产品新功能。\n14:50 - 16:00 使用 CloudMesh 轻松实践 Service Mesh by 敖小剑\nService Mesh 将服务间通信能力下沉到基础设施，让应用解耦并轻量化。但 Service Mesh 本身的复杂度依然存在，CloudMesh 通过将 Service Mesh 托管在云上，使得您可以轻松的实践 Service Mesh 技术。通过我们的 workshop，您可以快速部署应用到 CloudMesh ，对服务进行访问，通过监控查看流量，体验服务治理、Sidecar管理和对服务的新版本进行灰度发布等实用功能。\n","date":1559643600,"description":"","dir":"activities/sofastack-cloud-native-workshop/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"57c6b0262af34c2010179000834d8363","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofastack-cloud-native-workshop/","publishdate":"2019-06-04T10:20:00Z","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofastack-cloud-native-workshop/","summary":"蚂蚁金服 SOFAStack 云原生工作坊（KubeCon China 2019 同场活动） 日期：2019年6月24日，星期一 时间：9:00 – 16:00 地点：上海世博中心 616 房间 注册费：免费","tags":["KubeCon","Workshop","Cloud Native"],"title":"KubeCon 上海同场活动 SOFAStack Cloud Native Workshop","type":"activities","url":"/sofastack.tech/activities/sofastack-cloud-native-workshop/","wordcount":1134},{"author":"卫恒","categories":"SOFAMeetup","content":" 作者：卫恒（宋国磊），SOFATracer 以及 SOFADashboard 开源负责人。\n本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，着重分享如何使用 SOFADashboard 来管控 SOFAArk ，对于 SOFAArk 中的一些基础概念和知识不过多涉及；建议大家在阅读之前，先了解下 SOFAArk 的相关基本知识。\n现场回顾视频以及 PPT 见文末链接。\n前言 SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署能力，由蚂蚁金服开源贡献。SOFAArk 在 0.6.0 版本 提供了非常丰富的功能特性，其中最核心的当属多应用（模块）合并部署这个能力。SOFAArk 本身提供了多种方式来支持多应用（模块）合并部署 ，包括基于命令行的管控，基于 API 的管控等。本篇将结合 SOFA 开源的管控端组件 SOFADashboard，来实现 SOFAArk 提供的合并部署和动态模块推送的功能。\n案例工程地址\n背景 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n案例模型 本篇所演示案例是上图的一个简化版，从整体上可以体现 SOFAArk多应用合并部署的能力。主要包括已经几个工程：\n sofa-dashboard-ark-hostapp : 宿主应用 sofa-dashboard-ark-facade : 提供接口 API sofa-dashboard-ark-provider ：提供接口 API 的具体实现，将发布一个 JVM 服务 sofa-dashboard-ark-hostapp 和 sofa-dashboard-ark-provider 均作为 SOFAArk 中的 ark-biz 存在；sofa-dashboard-ark-hostapp 作为宿主应用对外提供服务。\n上图的模型中，在宿主应用不重启的情况下，实现 provider 模块的动态替换，从而实现版本升级。\n 在宿主应用启动时，provider 1.0.0 以静态合并部署方式“寄宿”到宿主应用中，这部分实际上与 SOFADashboard 管控是没有什么关系的，为了案例效果，在下面的案例中，关于静态合并部署的操作也会涉及到。\n 最终的工程结构图如下：\n环境准备 本文需要启动 SOFADashboard 服务端，具体请参考 : Quick Start ；其他基础设施环境如 Zookeeper 、Mysql 等需提前准备。\n工程构建 本篇将通过 step by step 的方式来构建整个工程，为大家在实际的应用过程中提供一种简单的思路，同时也帮助大家更好的理解 SOFAArk 中的一些点。\nsofa-dashboard-ark-facade 基础 API 提供模块，不需要依赖任何其他二方或者三方 JAR，这里仅提供一个接口。\npublic interface SofaJvmService { String test(); } sofa-dashboard-ark-provider 这个模块是 JVM 服务的提供方，也是后面需要在宿主应用中进行替换演示的模块包，这个模块本身也是一个 Web 应用。这里就来一步步分解下，如何将一个普通的 SpringBoot 工程改造成一个 ark-biz 工程。\n1、新建一个 SpringBoot 工程 新建 SpringBoot 工程推荐的方式有两种，一种是在 https://start.spring.io/ 进行下载，另外一种是基于 IDEA 的 Spring 插件来生成；此处不在过多描述过程。\n2、工程基本能力实现 引入 sofa-dashboard-ark-facade 依赖，先将需要提供的 JVM 服务实现： @SofaService @Service public class SofaJvmServiceImpl implements SofaJvmService { @Override public String test() { return \u0026amp;quot;first version biz\u0026amp;quot;; } } NOTE: SofaService 的作用是将一个 Bean 发布成一个 JVM 服务， 所以这里需要加上 Spring 提供的 @Service 注解将 SofaJvmServiceImpl 标注为一个 Bean。\n 配置文件： spring.application.name=biz-ark-test server.port=8800 logging.path=./logs 3、配置打包插件，将应用打包成 ark-biz  根据官方文档，可以使用 sofa-ark-maven-plugin 插件将一个普通的工程打包成一个 ark biz 包。这里直接给出本篇中工程的配置：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!--ark-biz 包的打包配置 --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- ark-biz 包的启动优先级，值越小，优先级越高--\u0026amp;gt; …","date":1559286000,"description":"本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，着重分享如何使用 SOFADashboard 来管控 SOFAArk ，对于 SOFAArk 中的一些基础概念和知识不过多涉及。","dir":"blog/sofa-meetup-2-2-retrospect/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"61a156b1a9f1a80f555200bfea5a20b6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","publishdate":"2019-05-31T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","summary":"作者：卫恒（宋国磊），SOFATracer 以及 SOFADashboard 开源负责人。 本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，","tags":["SOFAMeetup","SOFAArk","SOFADashboard"],"title":"基于 SOFAArk 和 SOFADashboard 实现动态模块管控 | Meetup#2 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","wordcount":3608},{"author":"玄北","categories":"SOFAStack","content":" 本文作者：玄北（曹杰），蚂蚁金服 SOFAStack 开源组核心成员。\n本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理，主要来聊聊 spring-cloud-antfin 包含的主要特性及如何使用 SOFAStack 和 SpringCloud 快读构建微服务系统。\n现场回顾视频以及 PPT 见文末链接。\n概念 Spring Cloud 是 Spring 社区开源的一套微服务开发框架，帮助开发人员快速构建分布式应用，Spring Cloud 的官网介绍如下：\n Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state).\n 蚂蚁金服从 2007 年开始在公司内部使用 SOFAStack 框架，2014 年基于 Spring Boot 研发了 SOFABoot，2016 年将 SOFAStack 在公有云输出，2018 年 4 月，蚂蚁金服宣布开源 SOFAStack。SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服开源的，用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。SOFAStack ：https://github.com/sofastack\nSOFAStack 包含以下主要特性：\n 全面：覆盖多种场景，让用户更加专注于业务开发； 可靠：经历过大规模场景的锤炼，特别是严苛的金融场景； 丰富：包含构建金融级云原生架构所需的各个组件，满足用户场景的现状和未来需求； 开放：兼容开源生态，组件可插拔， SOFAStack 组件与其它开源组件可相互集成或替换。 SOFAStack 开源全景图涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的 Nacos、Sentinel 等，为用户提供更加广泛地选择。\nSOFAStack 开源已经超过一年，Spring Cloud 作为当下流行的微服务框架，社区用户以及公司内部用户迫切希望能够将这两个优秀的框架进行整合，将 SOFAStack 中间件适配 Spring Cloud 规范也就产生了我们今天的主角——spring-cloud-antfin。\nspring-cloud-antfin 全景图 Spring 官网提供了一份 Spring Cloud 的架构图：\n从 Spring Cloud 的架构图可以看到，Spring Cloud 框架涵盖了分布式应用开发的方方面面，包括：\n API 网关  熔断与限流 服务发现 分布式配置 分布式链路 spring-cloud-antfin 是 Spring Cloud 微服务规范的 antfin 实现，同样的，我们也有一份 spring-cloud-antfin 全景图，涵盖了蚂蚁金服所有中间件：\n与 Spring Cloud 全景图不同，在 spring-cloud-antfin 中每种分布式组件都有具体的蚂蚁中间件实现：\n API 网关：SOFAGateway 熔断与限流：Guardian 服务发现：SOFARegistry 分布式配置：DRM 分布式链路：SOFATracer 在 spring-cloud-antfin 适配 Spring Cloud 的过程中，我们发现 Spring Cloud 制定的规范并不完整，对于一些 Spring Cloud 规范并未涵盖的方面，spring-cloud-antfin 进行了扩展。\n扩展 Spring Cloud 虽然 Spring Cloud 定义了很多微服务规范，但是在具体业务开发过程中，我们发现 Spring Cloud 还有很多不足，例如 Spring Cloud 对以下能力没有进行规范化：\n 属性级别动态配置 事务消息 Big Table 分布式事务 属性级别动态配置 Spring Cloud 的动态配置基于 RefreshScope 接口，默认 RefreshScope 会对整个 Bean 进行刷新，而且实现自动刷新需要配合 spring-cloud-bus，我们认为与 Apollo、Nacos 等属性级别刷新相比，这个是明显的退步，所以 spring-cloud-antfin 定义一个 DynamicConfig 注解，对于打有这个注解的 Bean，spring-cloud-antfin 支持属性级别动态配置：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) public @interface DynamicConfig { } 事务消息 spring-cloud-stream 默认不支持事务消息，但是在金融级场景中事务消息是必不可少的，所以 spring-cloud-antfin 扩展了 spring-cloud-stream 的定义，对事务消息进行了支持：\n MQ 支持事务：对于使用 MQ 本身就支持事务消息的，spring-cloud-antfin 会在 MessageHeaders 中增加 Transcation 相关属性，以此支持事务消息； MQ 不支持事务：对于使用 MQ 本身不支持事务的，spring-cloud-antfin 支持用本地事件表的模式支持事务消息。 消息发送端在同一个本地事务中记录业务数据和消息事件； 事件恢复服务定时从事件表中恢复未发布成功的事件，重新发布成功后删除记录的事件。 通过事件恢复服务的不停执行，我们保证了本地事件和消息发送到 Message Broker 必定同时成功或者同时失败。\nBig Table 一些 SOFAStack 的使用者，一套代码会在多种技术栈使用，当使用开源技术栈时，Big Table 的实现会使用 HBase，在使用商业技术栈时，Big Table 会使用阿里云的 TableStore，为了让用户实现不修改代码在不同技术栈使用，spring-cloud-antfin 会定义一套统一接口，然后让用户针对 spring-cloud-antfin 的接口进行编程，这样在替换底层实现时用户代码不需要修改：\npublic interface BigTableService { Result get(Get get) throws StoreException; Result[] get(List\u0026amp;lt;Get\u0026amp;gt; get) …","date":1559113200,"description":"本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理。","dir":"blog/sofa-meetup-2-1-retrospect/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ffc229811fe6c3065b010a9730e6d895","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","publishdate":"2019-05-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","summary":"本文作者：玄北（曹杰），蚂蚁金服 SOFAStack 开源组核心成员。 本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理，主要来聊聊 spring-cloud-antfin 包含","tags":["SOFAStack","SOFAMeetup"],"title":"当 Spring Cloud 遇上 SOFAStack | Meetup#2 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","wordcount":2918},{"author":"敖小剑","categories":"Service Mesh","content":" 前言 本文内容整理自5月25日在 Kubernetes \u0026amp;amp; Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 ServiceMesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁金服的上云实践，阐述在云原生背景下 Service Mesh 的核心价值，以及对云原生落地的关键作用。\n内容主要有三个部分：\n Service Mesh 产品动态：介绍最近半年 Service Mesh 的产品动态，包括开源项目和云厂商推出的云上服务 Service Mesh 发展趋势：根据最近的产品动态，总结 Service Mesh 的发展趋势，推断未来的走向 Service Mesh 与云原生：结合云原生，更好的理解 Service Mesh 的价值和作用 Service Mesh 产品动态 Istio1.1 发布 Istio 是目前 Service Mesh 社区最引人注目的开源项目，在今年的3月份发布了期待已久的 Istio 1.1 版本，我们来看看 Istio 最近几个版本的发布情况：\n 2018年6月1日，Istio 发布了 0.8 版本，这是 Istio 历史上第一个 LTS 版本，也是 Istio 历史上变动最大的一个版本； 2018年7月31日，Istio 发布了 1.0 版本，号称 \u0026amp;ldquo;Product Ready\u0026amp;rdquo;； 然后就是漫长的等待，Istio 1.0 系列以每个月一个小版本的方式一路发布了 1.0.1 到 1.0.6，然后才开始 1.1.0 snapshot 1 到 6，再 1.1.0-rc 1 到 6，终于在 2019年3月20日 发布了 1.1 版本，号称 \u0026amp;ldquo;Enterprise Ready\u0026amp;rdquo;。 从 Istio 1.0 到 Istio 1.1，中间的时间跨度高达9个月！我们来看看经过这漫长的开发时间才发布的 Istio 1.1 版本带来了哪些新的东西：\n图中标红的部分，涉及到 Istio 的架构调整，下面将详细介绍 Istio 1.1 版本中带来的架构变化。\nIstio 1.1 架构变化 下图是 Istio 1.0 和 Istio 1.1 的架构图对比：\nIstio 1.1 的第一个架构变化来自 Galley：在 Istio 1.1 的架构图中增加了 Galley 组件。但是实际上在 Istio 1.0 版本中 Gallay 组件就已经存在，只是当时 Galley 的功能非常简单，只是做配置更新之后的验证（Validation），在 Istio 1.0 的架构图中都没有出现。而在 Istio 1.1 版本之后，Galley 的定位发生了巨大的变化：Galley开始分担 Pilot/Mixer 的职责。\n在 Istio 1.1 版本之前的设计中，Istio 的三大组件 Pilot/Mixer/Citadel 都需要访问 Kubernetes 的 API Server，以获取服务注册信息和配置信息，包括 Kubernetes 原生资源如 service/deployment/pod 等，还有 Istio 的自定义资源（数量多达50多个的 CRD） 。这个设计导致 Istio 的各个组件都不得不和 Kubernetes 的 API Server产生强绑定，不仅仅代码大量冗余，而且在测试中也因为需要和 Kubernetes 的 API Server 交互导致 Pilot/Mixer 模块测试困难。\n为了解决这个问题，在 Istio 1.1 之后，访问 Kubernetes 的 API Server 的工作将逐渐交给 Galley 组件，而其他组件如 Pilot/Mixer 就会和 Kubernetes 解耦。\n这个工作还在进行中，目前 Istio 的 CRD 已经修改为由 Galley 读取，而 K8s 的原生资源（Service / Deployment / Pod等），暂时还是由 Pilot 读取。\n为了方便在各个组件中同步数据，Istio 引入了MCP（Mesh Configuration Protocol）协议。在 Istio 1.1 版本中，Pilot 通过 MCP 协议从 Galley 同步数据。MCP 是受 xDS v2 协议（准确说是 aDS）的启发而制定的新协议，用于在Istio 各模块之间同步数据。\nIstio 1.1 的第二个架构变化来自于 Mixer，在 Istio 1.1 版本中，推荐使用 Out-of-Process Adapter，即进程外适配器。Istio 预计下一个版本将弃用 In-Proxy Adapter，目前所有的 Adapter 都将改为 Out-of-Process adapter。\n什么是 In-Proxy Adapter？下图是 Mixer 的架构图，在 Istio 的设计中，Mixer 是一个独立进程，Proxy 通过远程调用来和 Mixer 交互。而 Mixer 的实现了 Adapter 模式，定义了 Adapter API，然后内建了数量非常多的各种Adapter。这些 Adatper 的代码存放在 Mixer 代码中，运行时也在 Mixer 的进程内，因此称为 In-Process Adapter。\nIn-Process Adapter 的问题在于所有的 Adapter 的实现都和 Mixer 直接绑定，包括代码和运行时。因此当 Adapter 需要更新时就需要更新整个 Mixer，任意一个 Adapter 的实现出现问题也会影响整个 Mixer，而且数量众多的 Adapter 也带来了数量众多的CRD。为此，Istio 1.1 版本中通过引入 Out-of-Process Adapter 来解决这个问题。\nOut-of-Process Adapter 以独立进程的方式运行在 Mixer 进程之外，因此 Out-of-Process Adapter 的开发/部署和配置都可以独立于 Mixer，从而将 Mixer 从 Adaper 的实现细节中解脱出来。\n但是，Out-of-Process Adapter 的引入，会导致新的性能问题：原来 Mixer 和 In-Process Adapter 之间是方法调用，现在改成 Out-of-Process Adapter 之后就变成远程调用了。而 Mixer 一直以来都是 Istio 架构设计中最大的争议，之前 Proxy 和 Mixer 之间的远程调用，已经造成非常大的性能瓶颈，而引入 Out-of-Process Adapter 之后远程调用会从一次会变成多次（每个配置生效的 Out-of-Process Adapter 就意味着一次远程调用），这会让性能雪上加霜。\n总结 Out-of-Process Adapter 的引入：架构更加的优雅，性能更加的糟糕。\n在 Istio 1.1 为了架构而不顾性能的同时，Istio 内部也有其他的声音传出，如正在规划中的 Mixer v2。这个规划最重要的决策就是放弃 Mixer 独立进程的想法，改为将 Mixer 的功能合并到 Envoy 中，从而避免 Envoy …","date":1559026800,"description":"本文内容整理自5月25日在 Kubernetes \u0026 Cloud Native Meetup 上海站发表的主题演讲。","dir":"blog/service-mesh-development-trend-1/","fuzzywordcount":8400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8756e6985e0df28a5150ebd3af0e48c5","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-development-trend-1/","publishdate":"2019-05-28T15:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/service-mesh-development-trend-1/","summary":"前言 本文内容整理自5月25日在 Kubernetes \u0026amp; Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 ServiceMesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁金服的上云实践，","tags":["Service Mesh"],"title":"Service Mesh 发展趋势：云原生中流砥柱","type":"blog","url":"/sofastack.tech/blog/service-mesh-development-trend-1/","wordcount":8383},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第二篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 SOFAJRaft-RheaKV 是基于 SOFAJRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库，SOFAJRaft 是基于 Raft 一致性算法的生产级高性能 Java 实现，支持 Multi-Raft-Group。SOFAJRaft-RheaKV 集群主要包括三个核心组件：PD，Store 和 Region。本文将围绕 SOFAJRaft-RheaKV 架构设计，存储概览，核心模块，使用场景以及基于 Raft 实现等方面剖析 SOFAJRaft-RheaKV 基于 SOFAJRaft 实现原理，阐述如何使用 Raft 协议支持 KV 存储类库功能特性：\n SOFAJRaft-RheaKV 基础架构如何设计？核心组件负责哪些功能？模块内部处理流程是怎样？ 基于 SOFAJRaft 如何使用 Raft 实现 SOFAJRaft-RheaKV 强一致性和自驱动等特性？  SOFAJRaft-RheaKV 概览 SOFAJRaft-RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 Library， RheaKV 包含在 SOFAJRaft 项目里，是 SOFAJRaft 的子模块。SOFAJRaft-RheaKV 定位是嵌入式 jar 包方式嵌入到应用中，涵盖以下功能特性：\n 强一致性，基于 Multi-Raft 分布式一致性协议保证数据可靠性和一致性； 自驱动，自诊断，自优化，自决策，自恢复； 可监控基于节点自动上报到 PD 的元信息和状态信息； 基本 API get/put/delete 和跨分区 scan/batch put，distributed lock 等。 架构设计 SOFAJRaft-RheaKV 存储类库主要包括 PD，Store 和 Region 三个核心组件，支持轻量级的状态/元信息存储以及集群同步，分布式锁服务使用场景：\n PD 是全局的中心总控节点，负责整个集群的调度管理，维护 RegionRouteTable 路由表。一个 PDServer 管理多个集群，集群之间基于 clusterId 隔离；PD Server 需要单独部署，很多场景其实并不需要自管理，RheaKV 也支持不启用 PD，不需要自管理的集群可不启用 PD，设置 PlacementDriverOptions 的 fake选项为 true 即可。 Store 是集群中的一个物理存储节点，一个 Store 包含一个或多个 Region。 Region 是最小的 KV 数据单元，可理解为一个数据分区或者分片，每个 Region 都有一个左闭右开的区间 [startKey, endKey)，能够根据请求流量/负载/数据量大小等指标自动分裂以及自动副本搬迁。Region 有多个副本 Replication 构建 Raft Groups 存储在不同的 Store 节点，通过 Raft 协议日志复制功能数据同步到同 Group 的全部节点。 存储设计 SOFAJRaft-RheaKV 存储层为可插拔设计，实现 RawKVStore 存储接口，目前 StoreEngine 存储引擎支持 MemoryDB 和 RocksDB 两种实现：\n MemoryRawKVStore：MemoryDB 基于 ConcurrentSkipListMap 实现，有更好的性能，但是单机存储容量受内存限制； RocksRawKVStore：RocksDB 在存储容量上只受磁盘限制，适合更大数据量的场景。 SOFAJRaft-RheaKV 存储引擎基于 MemoryDB 和 RocksDB 实现 KV 存储入口：\ncom.alipay.sofa.jraft.rhea.storage.RawKVStore com.alipay.sofa.jraft.rhea.storage.MemoryRawKVStore com.alipay.sofa.jraft.rhea.storage.RocksRawKVStore SOFAJRaft-RheaKV 数据强一致性依靠 SOFAJRaft 同步数据到其他副本 Replication, 每个数据变更都会落地为一条 Raft 日志, 通过 Raft 协议日志复制功能将数据安全可靠地同步到同 Raft Group 的全部节点里。\n核心设计 SOFAJRaft-RheaKV 核心模块包括 KV 模块[RheaKVStore 基于 RegionRouteTable 路由表使用 RaftRawKVStore 存储 KeyValue]，PD 模块[PlacementDriverServer 基于 StoreHeartbeat/RegionHeartbeat 心跳平衡节点分区 Leader 以及分裂]。\nKV 模块内部处理 RheaKVStore：最上层 User API，默认实现为 DefaultRheaKVStore， RheaKVStore 为纯异步实现，所以通常阻塞调用导致的客户端出现瓶颈，理论上不会在 RheaKV 上遭遇，DefaultRheaKVStore 实现包括请求路由、Request 分裂、Response 聚合以及失败重试等功能。 PlacementDriverClient：非必须，作为与 PlacementDriver Server 集群沟通的客户端，通过它获取集群完整信息包括但不仅限于\u0026amp;rdquo;请求路由表\u0026amp;rdquo;，对于无 PD 场景， RheaKV 提供 Fake PD Client。 RegionRouteTable：分片逻辑基于 RegionRouteTable 路由表结构，最适合的数据结构便是跳表或者二叉树(最接近匹配项查询)。作为本地路由表缓存组件，RegionRouteTable 根据 KV 请求的具体失败原因来决策是否从 PD Server 集群刷新数据，并且提供对单个 Key、多个 Key 列表以及 Key Range 进行计算返回对应的分区 ID。选择 Region 的 StartKey 作为 RegionRouteTable 的 Key ，主要取决于 Region Split 的方式，父 Region 分裂成两个子 Region 导致其中一个子 Region 的 StartKey …","date":1558681200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第二篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-jraft-rheakv/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4d79102c8300ca628483bdba44c13049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv/","publishdate":"2019-05-24T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 实现原理 - SOFAJRaft-RheaKV 是如何使用 Raft 的","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv/","wordcount":5817},{"author":"Linux 中国老王","categories":"SOFAStack","content":" — 本文转载自 Linux 中国老王\n蚂蚁金服的 SOFAStack 作为一个成功地将企业私有项目转化为开源核心模式的知名案例，我们之前对背后的思考和推动力做过专题分析，但是具体这件事是如何在蚂蚁金服内部发生的、是如何实操的，有很多读者向我们表示非常感兴趣，而我觉得这也是其它技术公司所正在探索和思考的方向。\n因此，上个月底，老王在参加上海举办的 KubeCon 2019 时，遇到了蚂蚁金服 SOFA 团队的余淮，他目前在蚂蚁金服中间件团队服务与框架组具体负责开发框架与 SOFAStack 的开源工作。于是，参会之余，我和余淮就 SOFA 开源的实操方面进行了深入的沟通，现将谈话所得整理给大家。\nSOFA 与开源 继去年开始开源 SOFAStack 以来，今年上半年他们又开源了分布式事务框架 Seata 和服务注册中心 SOFARegistry，之前我曾经向蚂蚁金服中间件负责人杨冰了解过为什么要将 SOFA 开源的背后思考，以及 SOFA 发展迭代的历程，详情可以看之前的文章《蚂蚁金服技术总监杨冰：金融科技公司为什么要拥抱开源？ 》进行了解。\n目前，SOFA 的架构已经发展到 SOFA 5 阶段，在今年 2 月，前任 SOFA 开源负责人鲁直还向我分享了 SOFA 5 中重点推进的方向，主要包括 Service Mesh 和 Serverless，以及分布式事务 Seata 的落地，具体内容见文章《蚂蚁金服开源负责人鲁直：不只是中间件，未来会开源更多》。\n作为一个成功的开源核心模式的项目，我非常关注 SOFA 开源的实操是如何进行的，是如何进行开源治理的，作为 SOFA 团队的老朋友，我们话题就直接从 SOFA 的开源治理聊起。\n以 SOFA 为例：公司内部软件的开源流程 余淮说，从 2015 年开始，蚂蚁金服开启了金融科技对外输出的战略，SOFAStack 也走出了蚂蚁金服，甚至跨越了国界，被更多金融机构与合作伙伴所使用，如天弘基金、信美互信、南京银行、PayTM、DANA 钱包等。\n在与合作伙伴以及客户的沟通、合作过程中，他们发现了 SOFAStack 的理念和能力也正是很多金融行业的企业所需要的。在蚂蚁金融科技对外输出的过程中，内部已经对 SOFAStack 进行了一定程度的代码重构，例如历史兼容逻辑的剥离等，但是并未能达到直接开源的标准。\n关于开源，内部一直有开源的讨论，到 2017 年双十一结束后正式决定开源。经过了一系列的准备，2018 年 4 月，完成了对 SOFA 项目的满足了开源改造的标准后，SOFAStack 马上宣布正式开源框架中部分重要组件。\nSOFA 团队采用的开源策略叫「Open Core」，顾名思义就是要将接口层以及核心实现都开源，以可扩展化的方式来层层构建 SOFAStack 的能力，保证 SOFAStack 的内部版本和开源的版本采用的是同一个内核。为此 SOFAStack 做了大量的改造和重构工作。\n在开源的具体考量上，余淮表示，SOFAStack 的开源改造基本上有三条原则，分别是高可扩展性、对内兼容历史版本、对外兼容业界标准。\n以 SOFARPC 重构为例，大概经历了这样的过程：\n 首先需要将 SOFARPC 进行了一次核心接口和模型抽象，然后增加了扩展点机制和事件总线机制，所有的对内对外实现都基于这些核心接口和模型去扩展，并且保证这些扩展能力都是平等的、可选的； 接着将核心的处理逻辑实现迁移到这套接口和模型上来，保证 SOFARPC 能力完整可用； 然后需要将 SOFARPC 里一些对接内部系统的、兼容历史逻辑的代码做成内部扩展，并进行全量测试验证，确保和已有线上的历史方案的兼容，发布上线； 最后会调研业界的一些开源标准方案和实现，并对其进行兼容，例如 SOFARPC 不仅对接自己的 SOFARegistry 的实现，还兼容了 Zookeeper、Etcd、Nacos 等业界优秀的注册中心方案。 虽然上面重构过程听上去没那么复杂，但是在实际过程中还是非常考验团队的技术能力的，特别是在抽象核心接口和模型的时候，为了做到既兼容内部又兼容外部，这需要进行大量的调研工作，才能做好这层较为通用抽象。其次在对内逻辑兼容的时候，由于内部的历史负担还是比较重的，为了能让重构的代码安全上线，团队也做了很多事情。\n还是举 SOFARPC 的例子，蚂蚁金服内部的服务路由过程比开源是要复杂很多的，特别是配合蚂蚁金服特有的单元化部署以及异地多活的能力，有时候需要多层路由才能找到目标地址。为了验证重构后逻辑的正确性，除了在开源代码里有单元测试用例外，SOFA 团队在内部也构建了一套非常完善的集成框架，专门用来测试已有逻辑的兼容性及正确性。\n基于 Open Core 这套思想建设 SOFAStack 以后，其实对开发同学的工作量来不会变少，反而可能是增多的。这是因为在写代码的同时，需要更多的考虑内部外部的使用情况，对代码质量也提出了更高的要求，开发流程会变得更加复杂。\n例如，内部新增一个特性，在以前可能直接修改代码经过测试就发布上线了，但现在的话会去思考这其中哪些能力是通用的，把这些能力抽象一下放到开源版本里去，然后开源版测试后发布，这个时候内部版本在基于这个开源版进行扩展，再经过测试后发布上线。\n虽然开发同学工作变多了，但是这样的话可以让 SOFAStack 的核心代码被更多的开发者 Review，在更多的系统中运行，在更多的场景下进行验证，对 SOFAStack 的品质保证有非常大的帮助。\n此外在开源进度上，余淮表示， SOFAStack 并不追求开源全部内部的组件，而是会根据产品的特性和开源准备的情况有选择的开源。\n例如 SOFAStack 下的分库分表组件，因为产品特性和 OB 等内部结合紧密就暂时不会开源。金融级分布式架构下未开源部分能力，SOFAStack 会和与业界其它优秀的开源项目做集成，保证整个金融级分布式架构功能的完整性和多样性。\n所以对于 SOFAStack 来说，并不只有自己开源的产品，而更多关注的是，和整个社区里所有开源优秀的产品一起，打造一套快速构建金融级分布式架构的套件。\n开源项目管理 开源一个项目，作为背后推动的公司事实上要付出相当多的人力和资金成本，同时，也不可避免的会涉及到审批流程。随着蚂蚁金服越来越多领域的项目开源，包括 SOFAStack，AI，区块链等，蚂蚁金服内部出台了相应的严格的审核机制，包括技术、合规、法务、安全等部门进行审核，同时还会考察项目开源对公司的意义，以及是否对社区有价值，在审核通过之后项目就会正式开源与大家见面了。\n蚂蚁金服对于开源文化是十分友好的，其内部的代码也大多都是公开在内网的 GitLab 仓库，经常会有业务团队对 SOFAStack 提交一些合并请求（拉取请求）来帮助项目的发展。\n同时，蚂蚁金服的工程师也普遍地拥抱开源，开源能够帮助项目产生更多、更好的想法，同时也可以吸收来自社区的贡献，让项目本身能够做的更好，这是大家所喜闻乐见的。 SOFA 的社区治理 开源项目并不是开放源代码就是终点，事实上，这只是开始，之后持续不断的开源治理才是开源之路。而如何将一个开源项目从最开始的由开源项目背后的公司主导转变为社 …","date":1558681200,"description":"SOFAStack 开源如何在蚂蚁金服内部发生、是如何实操的、如何运营，Lunix中国老王进行了采访和分析，欢迎阅读","dir":"blog/sofastack-linux-china/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c1896b9b50b60432bb345d583a9be24a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-linux-china/","publishdate":"2019-05-24T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofastack-linux-china/","summary":"— 本文转载自 Linux 中国老王 蚂蚁金服的 SOFAStack 作为一个成功地将企业私有项目转化为开源核心模式的知名案例，我们之前对背后的思考和推动力做过专题分析，但是具","tags":["SOFAStack"],"title":"大公司开源怎么做？SOFAStack给出了一个很好的例子","type":"blog","url":"/sofastack.tech/blog/sofastack-linux-china/","wordcount":3968},{"author":"花肉","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 活动时间：5 月 26 日周日下午 13 点 活动地点：上海市徐汇区田林路200号A7栋一楼 活动形式：线下活动 报名方式：https://tech.antfin.com/community/activities/576 活动介绍 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n欢迎 Star 我：https://github.com/sofastack\nSOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n5 月 26 日，SOFAMeetup#2 上海站，SOFAStack 开源核心成员集体出动。本期我们将侧重于各个落地的实际场景进行架构解析。\n分布式事务 Seata 详解、与 Spring Cloud 生态的融合案例、使用 SOFAStack 快速构建微服务 Demo 实操、更有最新开源的《让 AI 像 SQL 一样简单 — SQLFlow Demo 》首秀，期待与你不见不散~\n建议：参会者可带上电脑，现场有 Demo 实操环节~\n加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n点击即可报名 https://tech.antfin.com/community/activities/576\n议程 时间 环节 讲师 13:00 - 13:30 签到 13:30 - 14:15 《研发框架 SOFABoot 的特性及落地场景介绍》 蚂蚁金服 SOFABoot 负责人 善逝 14 :15 - 15:00 《谈注册中心 SOFARegistry 架构设计 》 蚂蚁金服 SOFARegistry 负责人 琪祥 15:00 - 15:05 茶歇休息 15:05 - 15:15 《SOFALab 社区共建分享》 SOFALab 杰出贡献者 米麒麟 15:15 - 16:00 《当 SpringCloud 遇上 SOFAStack》 蚂蚁金服 SOFAStack 开源组核心负责人 玄北 16:00 - 16:45 《分布式事务 Seata 实现原理及实践详解》 Seata Committer 绍辉 16:45 - 17:30 《使用 SOFAStack 快速构建微服务》SOFADashboard 演示 + SOFARegistry + SOFARPC + SOFAArk 蚂蚁金服 SOFADashboard 负责人 卫恒 17:30 - 17:45 《让 AI 像 SQL 一样简单 — SQLFlow Demo 演示》 蚂蚁金服深度学习引擎开源产品负责人 三平 ","date":1558437600,"description":"SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务，5 月 26 日周日下午 13 点，上海市徐汇区田林路200号A7栋一楼。","dir":"activities/sofa-meetup-2/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5765309cb693fc8cc45958ecab5a9c3b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-2/","publishdate":"2019-05-21T11:20:00Z","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-meetup-2/","summary":"概要 活动主题：SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 活动时间：5 月 26 日周日下午 13 点 活动地点：上海市徐汇区田林路200号A7栋一楼 活动形式：线","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#2 上海站——使用 SOFAStack 快速构建微服务","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-2/","wordcount":849},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFAStack 启用独立 Group ，社区更加开放 今日，SOFAStack 将启用独立 Group： https://github.com/sofastack\n感谢大家的一路支持，未来，我们继续相伴~\n背景：分布式架构 SOFAStack 开源历史 金融级分布式架构 SOFAStack 产生于蚂蚁金服内部需求，起初是为了解决高速发展下的业务问题。到 2019 年，已经历12年的业务锤炼，变成了一套成熟的金融级最佳实践。\nSOFAStack 的发展受益于开源社区的优秀产品，我们也决定结合我们的实践积累，把这些技术反馈给开源社区。\n2018 年 4 月，SOFAStack 宣布开源。这一年，SOFAStack 逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFABolt、SOFAMosn、SOFAMesh、SOFAJRaft、SOFAActs、SOFARegistry、SOFADashboard 等组件。2019 年 3 月，蚂蚁金服加入分布式事务Seata的社区共建中，并贡献其 TCC 模式。\nSOFAStack 未来也将持续开源，丰富生态。\nSOFA 开源全景图，涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的 Nacos、Sentinel 等，为用户提供更加广泛地选择。\nSOFAStack 启用独立 Group 和邮件订阅列表 为了开源管理更加清晰，更社区化的运作，更中立的技术态度，开放给更多的开发者和企业参与，SOFAStack 将启用独立 Group：\n SOFAStack 项目地址： https://github.com/sofastack 原项目地址： https://github.com/alipay 继续可访问，会跳转到新的地址上。\n 邮件订阅列表 加入 SOFAStack 邮件组 https://groups.google.com/forum/#!forum/sofastack 获取邮件订阅。\n感谢大家的一路支持，未来，我们继续相伴~\n","date":1557990000,"description":"SOFAStack 将启用独立 Group，社区更加开放今日。感谢大家的一路支持，未来，我们继续相伴","dir":"blog/sofastack-independent-droup/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f25b8521e498ebce982a98b882f941b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-independent-droup/","publishdate":"2019-05-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofastack-independent-droup/","summary":"SOFAStack 启用独立 Group ，社区更加开放 今日，SOFAStack 将启用独立 Group： https://github.com/sofastack 感谢大家的一路支持，未来，我们继续相伴~ 背景：分布式架构 SOFAStack 开源历史","tags":["SOFAStack"],"title":"持续技术开放 | SOFAStack 启用独立 Group","type":"blog","url":"/sofastack.tech/blog/sofastack-independent-droup/","wordcount":617},{"author":"SQLFlow","categories":"SQLFlow","content":" 5 月 6 日，在 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow，他在演讲中表示：“未来三年，AI 能力会成为每一位技术人员的基本能力。我们希望通过开源 SQLFlow，降低人工智能应用的技术门槛，让技术人员调用 AI 像 SQL 一样简单。”\nSQLFlow 的目标是将 SQL 引擎和 AI 引擎连接起来，让用户仅需几行 SQL 代码就能描述整个应用或者产品背后的数据流和 AI 构造。其中所涉及的 SQL 引擎包括 MySQL、Oracle、Hive、SparkSQL、Flink 等支持用 SQL 或其某个变种语言描述数据，以及描述对数据的操作的系统。而这里所指的 AI 引擎包括 TensorFlow、PyTorch 等深度学习系统，也包括 XGBoost、LibLinear、LibSVM 等传统机器学习系统。\nSQLFlow 开源项目链接：https://sqlflow.org/sqlflow\n5 月 26 日，将在上海迎来 SQLFlow 线下首秀 —《让 AI 像 SQL 一样简单— SQLFlow Demo》，还有 SOFAStack 开源生态交流分享，点击链接，即可报名~期待你的到来~\nhttps://tech.antfin.com/community/activities/576\nSQLFlow 的研发团队认为，在 SQLFlow 和 AI 引擎之间存在一个很大的空隙——如何把数据变成 AI 模型需要的输入。谷歌开源的 TensorFlow 项目开了一个好头，TFX Data Transform 和 feature column API 都是意图填补这个空缺的项目。但是这个空缺很大，是各种 SQL 引擎和各种 AI 引擎的笛卡尔积，远不是 TensorFlow 的这两个子项目就足以填补的，需要一个开源社区才行。要填补好这个空缺，需要先让用户意识到其重要性，这也是蚂蚁金服开源 SQLFlow 的意图之一。\nSQLFlow 位于 AI 软件系统生态的最顶端，最接近用户，它也位于数据和数据流软件生态之上。\n其实，将 SQL 和 AI 连接起来这个想法并非 SQLFlow 原创。谷歌于 2018 年年中发布的 BigQueryML 同样旨在“让数据科学家和分析师只用 SQL 语言就可以实现流行的机器学习功能并执行预测分析”。除了 Google 的 BigQueryML，微软基于 SQL Server 的 AI 扩展，以及 Teradata 的 SQL for DL 同样旨在连接 SQL 和 AI，让人工智能的应用变得像 SQL 一样简单。而 SQLFlow 与上述各个系统最根本的差异在于：SQLFlow 是开源的，以上系统都不是。\n开发 SQLFlow 的初衷 蚂蚁金服和很多互联网公司一样，不同产品背后有很多功能都依赖于 AI，比如用户信用的评估就是一套预测模型。到目前为止，每一个这样的功能的实现，都依赖一个工程师团队开发多个子系统——读取数据库或者在线日志流、这两类数据的 join、各种数据筛选、数据到模型输入（常说的 features）的映射、训练模型、用训练好的模型来做预测。整个过程下来耗时往往以月计，如果加班加点放弃写 unit test 代码，可能缩短到以周记。\n以上问题正是 SQLFlow 系统希望替工程师们解决的问题。蚂蚁金服拥有数千数据分析师，他们日常工作用的就是 SQL 语言。虽然数据分析师在互联网行业往往不像用 Python、Java、C++ 的工程师那样醒目，但是在很多有面向商业伙伴的业务的公司里，比如 LinkedIn，他们的贡献和人数都能与工程师相匹敌。SQLFlow 最早的初衷，就是希望解决分析师既要操作数据又要使用 AI、往往需要在两个甚至更多的系统之间切换、工作效率低的窘境。\nSQLFlow 旨在大幅提升效率，让上述功能实现所花费的时间进一步缩短到能以日计，甚至以小时计的程度。\n要达到这样的效率，必须有一种效率极高的描述工作意图的方式。SQL 是一种典型的描述意图，而不描述过程的编程语言。用户可以说我要 join 两个表，但是不需要写循环和构造 hash map 来描述如何 join 两个表。这个特性使得 SQL 能极大地提升开发效率，这正是 SQLFlow 选择扩展 SQL 语法支持 AI 这条思路的原因。\n不过，高效率的背后是更大的工程技术挑战。SQLFlow 需要做到能根据用户的意图，自动生成达到意图的 Python、C++、Go 语言的程序。\nSQLFlow 的架构设计 设计目标 在连接 SQL 和 AI 应用这一方向上，业内已有相关工作。开发者可以使用像 DOT_PRODUCT 这样的运算符在 SQL 中编写简单的机器学习预测（或评分）算法。但是，从训练程序到 SQL 语句需要进行大量的模型参数复制粘贴的工作。目前在一些商业软件中，已经有部分专有 SQL 引擎提供了支持机器学习功能的扩展。\n Microsoft SQL Server：Microsoft SQL Server 支持机器学习服务，可以将 R 或 Python 编写的机器学习程序作为外部脚本运行。 Teradata SQL for DL：Teradata 也提供了 RESTful 服务，可以通过扩展的 SQL SELECT 语法调用。 Google BigQuery：Google BigQuery 通过引入 CREATE MODEL 语句让用 SQL 实现机器学习成为可能。 但上述已有的解决方案都无法解决蚂蚁金服团队的痛点，他们的目标是打造一个完全可扩展的解决方案。\n 这一解决方案应与许多 SQL 引擎都兼容，而不是只能兼容特定版本或类型的 SQL 引擎。 它应该支持复杂的机器学习模型，包括用于深度学习的 TensorFlow 和用于树模型的 XGBoost。 能够灵活地配置和运行前沿机器学习算法，包括指定特征交叉，无需在 SQL 语句中嵌入 Python 或 R 代码，以及完全集成超参数估计等。 应对上述挑战的关键在于打造一套 SQL 扩展语法。研发团队首先从仅支持 MySQL 和 TensorFlow 的原型开发开始，后续计划支持更多 SQL 引擎和机器学习工具包。\n从 SQL 到机器学习 SQLFlow 可以看作一个翻译器，它把扩展语法的 SQL 程序翻译成一个被称为 submitter 的程序，然后执行。 SQLFlow 提供一个抽象层，把各种 SQL 引擎抽象成一样的。SQLFlow 还提供一个可扩展的机制，使得大家可以插入各种翻译机制，得到基于不同 AI 引擎的 submitter 程序。\nSQLFlow 对 SQL 语法的扩展意图很简单：在 SELECT 语句后面，加上一个扩展语法的 TRAIN 从句，即可实现 AI 模型的训练。或者加上一个 PREDICT 从句即可实现用现有模型做预测。这样的设计大大简化了数据分析师的学习路径。\n此外，SQLFlow 也提供一些基本功能，可以供各种 submitter 翻译插件使用，用来根据数据的特点，推导如何自动地把数据转换成 features。这样用户 …","date":1557903600,"description":"本文整理于 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow 的现场演讲。","dir":"blog/sqlflow-open-source/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fcd6535619144aec695ee9afbf2fc36b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sqlflow-open-source/","publishdate":"2019-05-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sqlflow-open-source/","summary":"5 月 6 日，在 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow，他在演讲中表示：“未来三年，AI","tags":["SQLFlow"],"title":"蚂蚁金服开源机器学习工具 SQLFlow，技术架构独家解读","type":"blog","url":"/sofastack.tech/blog/sqlflow-open-source/","wordcount":5106},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs\n活动时间：5 月 16 日周四晚 7 点\n活动形式：线上直播\n报名方式：https://tech.antfin.com/activities/552\n介绍 | SOFAChannel\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs\n如何自动生成测试用例？\n如何减少测试用例设计过程中的阻力？\n如何进行精细化校验以及用例的高效管理，从而保障代码质量，有效提高测试效率？\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 线上直播第 5 期《给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs》报名开启！\n5 月 16 日周四晚 7 点，围绕蚂蚁金服的多年测试实践的积累与沉淀，自动化测试框架 SOFAActs 核心成员青勤将为大家带来精彩分享，不要错过哦。\nSOFAActs 是基于数据模型驱动测试引擎的的新一代测试框架，它的数据以 YAML 为载体，在此上构建基于数据模型的驱动引擎，适配 TestNg+SOFABoot 的测试上下文环境；支持高效、标准化构建用例，可视化编辑测试数据，精细化校验结果数据和自动清理 DB 数据，可以有效降低人工录入用例数据的成本，同时支持 API 重写提高测试代码的可扩展可复用性，提供特有注解提高测试代码编排的灵活性。\n| 加入 SOFA 钉钉互动群\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n| 点击即可报名\nhttps://tech.antfin.com/activities/552\n议程 19:00-19:05 主持人开场\nSOFAGirl 主持人\n19:05-20:00 给研发工程师的代码质量利器 — 自动化测试框架 SOFAActs\n青勤 蚂蚁金服自动化测试框架 SOFAActs 核心成员\n本期分享大纲：\n 蚂蚁金服接口自动化测试理念 如何接入 SOFAActs 自动化测试框架 SOFAActs 自动化测试框架的基本使用 嘉宾 SOFAGirl 主持人 青勤 蚂蚁金服自动化测试框架 SOFAActs 核心成员 ","date":1557310800,"description":"5 月 16 日周四晚 7 点，线上直播。","dir":"activities/sofa-channel-5/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e000553c2c76f43ed8df5b8e56491a7b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-5/","publishdate":"2019-05-08T10:20:00Z","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-5/","summary":"概要 活动主题：SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs 活动时间：5 月 16 日周四晚 7 点 活动形式：线上直播 报名方","tags":["SOFAChannel","SOFAActs"],"title":"SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs","type":"activities","url":"/sofastack.tech/activities/sofa-channel-5/","wordcount":733},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第一篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft 存储模块分为：\n Log 存储记录 Raft 配置变更和用户提交任务日志； Meta 存储即元信息存储记录 Raft 实现的内部状态； Snapshot 存储用于存放用户的状态机 Snapshot 及元信息。 本文将围绕日志存储，元信息存储以及快照存储等方面剖析 SOFAJRaft 存储模块原理，阐述如何解决 Raft 协议存储问题以及存储模块实现：\n Raft 配置变更和用户提交任务日志如何存储？如何调用管理日志存储？ SOFAJRaft Server 节点 Node 是如何存储 Raft 内部配置？ Raft 状态机快照 Snapshot 机制如何实现？如何存储安装镜像？ 日志存储 Log 存储，记录 Raft 配置变更和用户提交任务的日志，把日志从 Leader 复制到其他节点上面。\n LogStorage 是日志存储实现，默认实现基于 RocksDB 存储，通过 LogStorage 接口扩展自定义日志存储实现； LogManager 负责调用底层日志存储 LogStorage，针对日志存储调用进行缓存、批量提交、必要的检查和优化。 LogStorage 存储实现 LogStorage 日志存储实现，定义 Raft 分组节点 Node 的 Log 存储模块核心 API 接口包括：\n 返回日志里的首/末个日志索引； 按照日志索引获取 Log Entry 及其任期； 把单个/批量 Log Entry 添加到日志存储； 从 Log 存储头部/末尾删除日志； 删除所有现有日志，重置下任日志索引。 Log Index 提交到 Raft Group 中的任务序列化为日志存储，每条日志一个编号，在整个 Raft Group 内单调递增并复制到每个 Raft 节点。LogStorage 日志存储实现接口定义入口：\ncom.alipay.sofa.jraft.storage.LogStorage RocksDBLogStorage 基于 RocksDB 实现 Log Structured Merge Tree 简称 LSM ，把一颗大树拆分成 N 棵小树，数据首先写入内存，内存里构建一颗有序小树，随着小树越来越大，内存的小树 Flush 到磁盘，磁盘中的树定期做合并操作合并成一棵大树以优化读性能，通过把磁盘的随机写转化为顺序写提高写性能，RocksDB 就是基于 LSM-Tree 数据结构使用 C++ 编写的嵌入式 KV 存储引擎，其键值均允许使用二进制流。RocksDB 按顺序组织所有数据，通用操作包括 get(key), put(key), delete(Key) 以及 newIterator()。RocksDB 有三种基本的数据结构：memtable，sstfile 以及 logfile。memtable 是一种内存数据结构\u0026amp;ndash;所有写入请求都会进入 memtable，然后选择性进入 logfile。logfile 是一种有序写存储结构，当 memtable 被填满的时候被刷到 sstfile 文件并存储起来，然后相关的 logfile 在之后被安全地删除。sstfile 内的数据都是排序好的，以便于根据 key 快速搜索。\nLogStorage 默认实现 RocksDBLogStorage 是基于 RocksDB 存储日志，初始化日志存储 StorageFactory 根据 Raft节点日志存储路径和 Raft 内部实现是否调用 fsync 配置默认创建 RocksDBLogStorage 日志存储。基于 RocksDB 存储实现 RocksDBLogStorage 核心操作包括：\n init()：创建 RocksDB 配置选项调用 RocksDB#open() 方法构建 RocksDB 实例，添加 default 默认列族及其配置选项获取列族处理器，通过 newIterator() 生成 RocksDB 迭代器遍历 KeyValue 数据检查 Value 类型加载 Raft 配置变更到配置管理器 ConfigurationManager。RocksDB 引入列族 ColumnFamily 概念，所谓列族是指一系列 KeyValue 组成的数据集，RocksDB 读写操作需要指定列族，创建 RocksDB 默认构建命名为default 的列族。 shutdown()：首先关闭列族处理器以及 RocksDB 实例，其次遍历列族配置选项执行关闭操作，接着关闭RocksDB 配置选项，最后清除强引用以达到 Help GC 垃圾回收 RocksDB 实例及其配置选项对象。 getFirstLogIndex()：基于处理器 defaultHandle 和读选项 totalOrderReadOptions 方法构建 RocksDB 迭代器 RocksIterator，检查是否加载过日志里第一个日志索引，未加载需调用 seekToFirst() 方法获取缓存 RocksDB 存储日志数据的第一个日志索引。 getLastLogIndex()：基于处理器 defaultHandle 和读选项 totalOrderReadOptions 构建 RocksDB 迭代器 RocksIterator，调用 seekToLast() 方法返回 RocksDB 存储日志记录的最后一个日志索引。 getEntry(index)：基于处理器 defaultHandle 和指定日志索引调用 RocksDB#get() 操作返回 RocksDB 索引位置日志 LogEntry。 getTerm(index)：基于处理器 defaultHandle 和指定日志索引调用 RocksDB#get() 操作获取 RocksDB 索引位置日志并且返回其 LogEntry 的任期。 appendEntry(entry)：检查日志 LogEntry 类型是否为配置变更，配置变更类型调用 RocksDB#write() 方法执行批量写入，用户提交任务的日志基于处理器 defaultHandle 和 LogEntry 对象调 …","date":1557066600,"description":"本文为《剖析 | SOFAJRaft 实现原理》第一篇，本篇作者米麒麟，来自陆金所。。","dir":"blog/sofa-jraft-algorithm-storage-module-deep-dive/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b48c76bf76b0c77d11af1a6265c9b78b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","publishdate":"2019-05-05T14:30:00Z","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 实现原理 - 生产级 Raft 算法库存储模块剖析","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","wordcount":6384},{"author":"卫恒","categories":"SOFADashboard","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 为了建设更完整的 SOFAStack 微服务体系，我们计划发起 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。欢迎共建~ SOFADashboard：https://github.com/sofastack/sofa-dashboard  背景 从 2018 年 4 月 19 日宣布开源至今，SOFAStack 目前已经开源了包括 SOFABoot、 SOFARPC、SOFALookout、SOFATracer、SOFARegistry 等在内的一系列微服务相关的项目，并投入分布式事务 Seata 进行重要贡献。随着 SOFAStack 架构体系的不断丰富和完善，外部对于 SOFAStack 的管控平台的需求也愈加强烈。\n由于 SOFAStack 内部的管控平台依赖众多的内部基础设施，为了建设更完整的 SOFAStack 微服务体系，我们计划发起全新的 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。\n能力大图 SOFADashboard 作为一站式 SOFAStack 管控台，希望对 SOFAStack 各个组件的使用等进行统一管理。为此我们为 SOFADashboard 规划一版能力图，包含了微服务里的一些能力点，例如应用信息管理、服务治理、配置管控、动态模块等等。见下图所示：\n每个能力点对应的实现我们都做了一层抽象。例如服务查看需要从注册中心获取数据，我们封装了一层服务列表获取接口，底层可以是从 Zookeeper 或者 SOFARegistry 等不同的注册中心实现读取服务列表。\n技术栈选择 为了最大限度的降低开发成本、部署成本及运维成本，SOFADashboard 会基于开源社区优秀的产品来进行开发构建。经过讨论，最终选择社区主流的前后端分离思路，具体的组件包括：\n Ant Design：基于 React封装的一套 Ant Design 的组件库，主要用于研发企业级中后台产品。从产品成熟度、社区活跃度、框架上手难易程度等各个方面均有很好的表现。 SOFABoot：蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。 MyBatis：Mybatis 相对于 JPA 来说，上手难度略低，JPA 更加倾向于结合 DDD 使用(业务越复杂，对于DDD 的需求越高)；对于简单的增删改查业务操作，Mybatis 相对来说更灵活和可控。 v1.0 发布 4 月 30 日，我们上传了第一个 SOFADashboard 版本，主要能力包括：应用信息、服务查看、动态模块管控等。\n目前演示地址：http://dashboard.dev.sofastack.tech:8000/ 详细设计图 基础依赖 从架构图中可以看到，目前 SOFADashboard 中的服务治理、SOFAArk 管控等需要依赖于 Zookeeper 和 MySQL；它们承担的解决如下：\n 外部依赖 作用 备注 Zookeeper 注册中心 SOFARPC 服务治理 配置推送 SOFAArk 管控 MySql 资源存储 注册的 ark-biz 信息，插件与应用的关联信息，插件版本信息等 应用面板 SOFADashboard 支持查看应用的 IP、端口、健康检查状态等基本信息，此功能依赖 SOFADashboard client。SOFADashboard client 用于向 SOFADashboard 服务端注册 IP、端口、健康检查状态等应用基本信息；SOFADashboard client 并非是直接通过 API 调用的方式将自身应用信息直接注册到 SOFADashboard 服务端 ，而是借助于 Zookeeper 来完成。\n客户端向 Zookeeper 中如上图所示的节点中写入数据，每一个 ip:port 节点代表一个应用实例，应用本身信息将写入当前节点的 data 中。\n如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可，具体使用参考 SOFADashboard client 快速开始 。\n服务治理 SOFADashboard 服务治理是对 SOFARPC 的服务进行管理，服务治理管控台部分，主要包括基于服务名查询和服务信息列表展示两个基础能力。在服务治理管控台界面，可以直观的看到当前服务的一些基本元数据信息：\n当点击 服务 ID 对应的超链接时，会进入到当前服务的详情页；服务提供者详情页中，可以看到当前服务所有的提供方信息列表，每个 item 行对应一个服务提供方实例，通过此界面可以快速查看服务的 providers 信息。\n服务消费者详情页中，可以看到当前服务所有的消费方信息列表。\nSOFAArk 管控 SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAArk 管控是 SOFADashboard 针对 API 管控的一种实现。通过面向 Zookeeper 进行命令的推送和命令的解析执行。SOFAArk 管控主要包括以下功能：\n 插件注册 将 ark-biz 插件注册到 SOFADashboard，作为基础数据，统一管控。\n插件基本信息录入：\n插件列表：\n 关联应用 将 ark-biz 插件与宿主应用进行绑定，此关联信息在 SOFAArk 多应用（模块）合并部署中作为重要的基础信息存在。在后续的操作中，可以通过此关联关系查看到某个插件下挂载的应用信息。\n 插件详情 通过插件详情页，可以看下当前 ark-biz 插件下所有关联的宿主应用信息，以及宿主应用中的 ark-biz 状态信息，插件详情页中，可以查看所有关联此插件的应用中，插件的状态信息。\n 命令推送 命令推送是 SOFADashboard 中提供 SOFAArk 管控的核心能力，通过面向 Zookeeper 编程的方式，将指令信息传递给各个宿主应用中的 ark-biz 模块，ark-biz 在接收到相关指令之后再进行相应的行为，如安装、切换、卸载等。\n可以针对应用维度、IP 维度推送一些指令，比如 install、uninstall 等等，当这些命令被写入到 Zookeeper 的某个节点上时，所有监听此节点的宿主应用均会解析此指令，并进行相关的操作。\n基于 IP 维度推送如图例所示，每个应用实例表单默认会有对应的操作，可以通过展示的命令按钮操作当前实例行为：\n点击 安装按钮，延迟 1~1.5s 之后 界面将会刷 …","date":1557039600,"description":"为了建设更完整的 SOFAStack 微服务体系，我们计划发起 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。欢迎共建~","dir":"blog/sofa-dashboard-open-source/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f9a78639fd427da4c3ea19d32e8420e7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-dashboard-open-source/","publishdate":"2019-05-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-dashboard-open-source/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 为了建设更完整","tags":["SOFADashboard"],"title":"SOFADashboard 启动开源共建 | SOFAStack 一站式管控平台","type":"blog","url":"/sofastack.tech/blog/sofa-dashboard-open-source/","wordcount":2602},{"author":"老王","categories":"SOFAStack","content":" 本文转自 Linux 中国\n谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。\u0026amp;ndash; 老王\n二月初春，在西子湖畔的细雨中，我拜访了蚂蚁金服中间件团队，和 SOFA 技术负责人鲁直做了一次深入交谈，更妙的是，鲁直也是负责 SOFA 开源事务推进的人，而这样一个切实践行开放核心模式的开源项目，也正是我非常感兴趣的。\n两个技术人的谈话，自然是朴实而直白的，话题主要围绕着 SOFA 和开源主题展开，希望也能一样引起同是技术人的你的共鸣。\n 人物介绍 受访者：鲁直，蚂蚁金服 SOFA 开源负责人。 采访者：老王，开源布道人，有 20 年互联网从业经历的技术老兵。\n 虽然我和鲁直在微信上已经联系很久了，但这还是第一次见面。交谈中，我了解到鲁直是 2009 年加入阿里巴巴工作，已经有十年了。刚开始是在 1688.COM 做业务系统，对中间件技术非常感兴趣，也会经常研究各种中间件的实现和功能。后来在 2013年时，为了更深入地学习研究中间件框架，转到了蚂蚁金服中间件团队，从那个时候开始就一直在做 SOFA。\n目前鲁直在 SOFA 的团队主要负责的工作包括几个部分。其中一个主要部分就是 SOFA 开源相关的工作。SOFA 的产品体系非常广，包括已经对外开源的部分、内部整个微服务体系，以及 SOFA 框架等等——而这些开源相关的工作主要是由鲁直负责推动的。\n当然，作为技术负责人，鲁直既要带技术团队也要做技术工作。谈及这一点，鲁直说：\n“我觉得做技术管理，跟普通的管理不太一样，因为技术管理最重要的一个点是除了管理之外，还要保持一定的技术判断力和敏锐度。对一些新技术，包括团队中遇到一些重大的技术问题，你都要有一些方向性的判断。虽然最后不一定是你具体解决的，但是在整个团队的技术攻坚和技术选型上，要一起确立方向。”\n我以前也做过十余年的技术管理，我很能够感受这种情况，重大问题技术负责人更要迎难而上。\nSOFA 5 落子 Service Mesh 就我了解的情况，现在 SOFA 已经发展到了 SOFA5 了。在 SOFA4 阶段，主要的任务是将开源体系捋清楚了，然后开始按步骤地开源；到现在发展到了 SOFA5。我想知道从 SOFA4 发展到 SOFA5，是什么让蚂蚁金服中间件团队判断 SOFA4 的阶段性目标已经达成，可以迈进到新的 SOFA5 阶段了呢？\n “从整个业界趋势上来讲，SOFA4 的架构相对来说还是偏传统一些，更多是对我们之前的技术框架的整理和梳理。在这个阶段，SOFA 的代码经过了非常多的优化和重构，才达到了对外开源的要求，从而 SOFA 走上了开源核心的模式，逐步分阶段的将各个部分进行了开源。”鲁直讲到，“但是，从我们对业界的整体判断上来说，未来无疑是云的时代，所以说要考虑怎么让所有的业务系统能够提供云的能力，比如说 Serverless。”\n接着这个话题，鲁直讲了他对云计算的理解：“一方面云计算肯定要为整个业务的发展提供更加方便的基础资源，可以不用去关心底层的基础设施。Serverless 字面的意思就是说‘无服务器’——我不用关心服务器怎么来的，不用关心基础设施，只要关心业务代码就可以了。那反过来对于云服务商来说，经过了这一层抽象，其资源利用率会更高，可以有更多的利润空间，这是一个双赢的局面。对于用户来讲，这种好处是实实在在的，可以更少关注基础设施，只关心代码就可以了。”\n  “我们希望在 SOFA5 的方向上，在这个新的迭代中，去让业务——包括让未来我们开源出来各种功能、各样服务模式——都更多地去关心自己的业务代码，而不用再过多地关心基础设施。”鲁直说。\n 在 SOFA5 中，一个重要的方向就是 Service Mesh 这个方向，这将是 SOFA5 中非常重要的特性。鲁直强调了其对 Service Mesh 技术的看好：“我认为 Service Mesh 是迈向未来往前走的非常关键的一步，让业务不用再关心基础设施。通过 Service Mesh，我们可以将很多技术能力直接放到基础设施里面，而业务可以不用感知到这一层。原来可能需要花几个小时或者更多的时间解决的基础设施问题，现在可以通过 Service Mesh 解决掉。”\n“目前我们我们已经在生产环境中应用了 Service Mesh。我们在这方面有非常大的决心，我们希望能够在今年，在更大的范围中去落地 Service Mesh。当前这个阶段更聚焦在这种技术的内部落地上，希望用好了，再给社区做更多的贡献。”\n Service Mesh 这个词最早是由开发 Linkerd 的 Buoyant 公司于 2016 年提出的，随着 Linkerd 的传入，Service Mesh 也进入国内技术社区的视野。Service Mesh 也被翻译为“服务网格”。Linkerd 则是业界第一个 Service Mesh。 Service Mesh 是一个基础设施层，用于处理服务间通信，负责实现请求的可靠传递。在实践中，服务网格通常实现为轻量级网络代理，通常与应用程序部署在一起，但是对应用程序透明。\nService Mesh 的部署模型，有两种情况： ◈ 对于一个简单请求，作为请求发起者的客户端应用实例，会首先用简单方式将请求发送到本地的 Service Mesh 实例。这是两个独立进程，它们之间是远程调用。Service Mesh 会完成完整的服务间调用流程，如服务发现负载均衡，最后将请求发送给目标服务。这就是 Sidecar，它在原有的客户端和服务端之间加多了一个代理。 ◈ 多个服务调用的情况，Service Mesh 出现在所有的服务的下面，这一层被称之为服务间通讯专用基础设施层。Service Mesh 会接管整个网络，把所有的请求在服务之间做转发。在这种情况下，上面的服务不再负责传递请求的具体逻辑，只负责完成业务处理。服务间通讯的环节就从应用里面剥离出来，呈现出一个抽象层。\n如果有大量的服务，Sidecar 之间的连接就会形成一个网络，这个就是服务网格名字的由来。\n “我们将以 Service Mesh 为跳板再往前走。”鲁直表示，“Serverless 更多的还是应该聚焦在其字面本身，其含义就是‘无服务器’，后面的技术都是为了让无服务器承载具体的业务。”\nServerless 这个概念虽然提出来已经有几年了，目前 AWS 在 Serverless 和 FaaS 方面处于比较前沿的位置，但是在国内，Serverless、FaaS 这些技术的发展还是相对比较滞后。\n鲁直指出，“我觉得 Serverless 想要成功，还是要从覆盖业务的整个广度上打开，否则可能还是停留在 FaaS 上，那场景就比较受限。”\n Service Mesh 将是微服务的下一个时代，关于它还在持续进行理论研究和实践探索。\n 鲁直说：“坦白来讲，我觉得 istio 的理念非常好，但是在整个工程设计上，如果放到蚂蚁金服这样体量较大的环境里面，可能跑起来还需要做一些工作。我们希望今年 Service Mesh 在蚂蚁金服有了更大规模落地之后，可以把我们在 Service Mesh 方面的一些实践经验用到产品环境的工程中去实践，然后贡献出去。目前更多的一些工作，是将整个 …","date":1556607600,"description":"谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。-- 老王","dir":"blog/antfin-middleware-open-source-key-figure-luzhi/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6779f59b05648131b0d635a71cd95d0d","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","publishdate":"2019-04-30T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","summary":"本文转自 Linux 中国 谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。\u0026ndash; 老王 二月初春，在西子湖畔的细雨中，我拜访了蚂蚁金服中间","tags":["SOFAStack"],"title":"对话鲁直：蚂蚁金服中间件的开源头羊 | 穿山甲专访","type":"blog","url":"/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","wordcount":5979},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nGitHub 地址：https://github.com/sofastack/sofa-jraft\n之前，我们有一篇介绍 SOFAJRaft 的文章，可在文末获得链接，延续这个内容，今天的演讲分为三部分，先简要介绍 Raft 算法，然后介绍 SOFAJRaft 的设计，最后说说它的优化。\n分享嘉宾：力鲲 蚂蚁金服 SOFAJRaft 核心成员\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务。 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\nLeader 选举 复制状态机集群在利用 Raft 算法保证一致性时，要做的第一件事情就是 Leader 选举。在讲 Leader 选举之前我们先要说一个重要的概念：Term。Term 用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求；\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳；\n 当然了，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。\n当选举 Leader 成功之后，整个集群就可以向外提供正常读写服务了，如图所示，集群由一个 Leader 两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳或者把 Log 复制给 Follower。\nLog 复制 下面我们就详细说一下 Log 复制。我们之前已经说了 Log 就是 Client 发送给复制状态机的一系列命令。这里我们再举例解释一下 Log，比如我们的复制状态机要实现的是一个银行账户系统，那么这个 Log 就可以是 Client 发给账户系统的一条存钱的命令，比如“存 100 元钱”。\nLeader 与 Follower 之间的日志复制是共识算法运用于复制状态机的重要目的，在 Raft 算法中 Log 由 TermId、LogIndex、LogValue 这三要素构成，在这张图上每一个小格代表一个 Log。当 Leader 在向 Follower 复制 Log 的时候，Follower 还需要对收到的 Log 做检查，以确保这些 Log 能和本地已有的 Log 保持连续。我们之前说了，Raft 算法是要严格保证 Log 的连续性的，所以 Follower 会拒绝无法和本地已有 Log 保持连续的复制请求，那么这种情况下就需要走 Log 恢复的流程。总之，Log 复制的目的就是要让所有的 Server 上的 Log 无论在内容上还是在顺序上都要保持完全一致，这样才能保证所有状态机执行结果一致。\n目前已经有一些很优秀的对 Raft 的实现，比如 C++ 写的 braft，Go 写的 etcd，Rust 写的 TiKV。当然了，SOFAJRaft 并不是 Raft 算法的第一个 Java 实现，在我们之前已经有了很多项目。但是经过我们的评估，觉得目前还是没有一个 Raft 的 Java 实现库类能够满足蚂蚁生产环境的要求，这也是我们去写 SOFAJRaft 的主要原因。\nSOFAJRaft 介绍 接下来我们介绍 SOFAJRaft。 SOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。从去年 3 月开发到今年 2 月完成，并在今年 3 月开源。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统，目前使用案例有 RheaKV，这是 SOFAJRaft 中自带的一个分布式 KV 存储，还有今天开源的 SOFA 服务注册中心中的元信息管理模块也是用到了 SOFAJRaft，除此之外还有一些内部的项目也有使用，但是因为没有开源，所以就不再详述了。\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依 …","date":1556202600,"description":"本文根据 SOFAChannel#4 直播分享整理，主题：SOFAJRaft 详解。","dir":"blog/sofa-jraft-deep-dive/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f2d4559ece4184ef09b96899a1aeb900","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-deep-dive/","publishdate":"2019-04-25T14:30:00Z","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-jraft-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFAJRaft","剖析 | SOFAJRaft 实现原理","SOFALab"],"title":"蚂蚁金服开源 SOFAJRaft 详解| 生产级高性能 Java 实现","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-deep-dive/","wordcount":5688},{"author":"琪祥","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。 GitHub 地址：https://github.com/sofastack/sofa-registry \n 3 月 31 日，蚂蚁金服正式开源了内部演进了近 10 年的注册中心产品-SOFARegistry。先前的文章介绍了 SOFARegistry 的演进之路，而本文主要对 SOFARegistry 整体架构设计进行剖析，并着重介绍一些关键的设计特点，期望能帮助读者对 SOFARegistry 有更直接的认识。\n如有兴趣，也欢迎加入《剖析 | SOFARegistry 实现原理》系列的共建，认领列表见文末。\n服务注册中心是什么 不可免俗地，先介绍一下服务注册中心的概念。对此概念已经了解的读者，可选择跳过本节。\n如上图，服务注册中心最常见的应用场景是用于 RPC 调用的服务寻址，在 RPC 远程过程调用中，存在 2 个角色，一个服务发布者（Publisher）、另一个是服务订阅者（Subscriber）。Publisher 需要把服务注册到服务注册中心（Registry），发布的内容通常是该 Publisher 的 IP 地址、端口、调用方式 （协议、序列化方式）等。而 Subscriber 在第一次调用服务时，会通过 Registry 找到相应的服务的 IP 地址列表，通过负载均衡算法从 IP 列表中取一个服务提供者的服务器调用服务。同时 Subscriber 会将 Publisher 的服务列表数据缓存到本地，供后续使用。当 Subscriber 后续再调用 Publisher 时，优先使用缓存的地址列表，不需要再去请求Registry。\n如上图，Subscriber 还需要能感知到 Publisher 的动态变化。比如当有 Publisher 服务下线时， Registry 会将其摘除，随后 Subscriber 感知到新的服务地址列表后，不会再调用该已下线的 Publisher。同理，当有新的 Publisher 上线时，Subscriber 也会感知到这个新的 Publisher。\n初步认识 在理解了常见的服务注册中心的概念之后，我们来看看蚂蚁金服的 SOFARegistry 长什么样子。如上图，SOFARegistry 包含 4 个角色：\n Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\n SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\n DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。\n MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n产品特点 （图片改编自 https://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products ）\n首先放一张常见的服务注册中心的特性对比，可以看出，在这些 Feature 方面，SOFARegistry 并不占任何优势。那么，我们为什么还开源这样的一个系统？SOFARegistry 开源的优势是什么？下面将着重介绍 SOFARegistry 的特点。\n支持海量数据 大部分的服务注册中心系统，每台服务器都是存储着全量的服务注册数据，服务器之间依靠一致性协议（如 Paxos/Raft/2PC 等）实现数据的复制，或者只保证最终一致性的异步数据复制。“每台服务器都存储着全量的服务注册数据”，在一般规模下是没问题的。但是在蚂蚁金服庞大的业务规模下，服务注册的数据总量早就超过了单台服务器的容量瓶颈。\nSOFARegistry 基于一致性 Hash 做了数据分片，每台 DataServer 只存储一部分的分片数据，随数据规模的增长，只要扩容 DataServer 服务器即可。这是相对服务发现领域的其他竞品来说最大的特点，详细介绍见后面《如何支持海量数据》一节。\n支持海量客户端 SOFARegistry 集群内部使用分层的架构，分别为连接会话层（SessionServer）和数据存储层（DataServer）。SessionServer 功能很纯粹，只负责跟 Client 打交道，SessionServer 之间没有任何通信或数据复制，所以随着业务规模（即 Client 数量）的增长，SessionServer 可以很轻量地扩容，不会对集群造成额外负担。\n相比之下，其他大多数的服务发现组件，如 eureka，每台服务器都存储着全量的数据，依靠 eurekaServer 之间的数据复制来传播到整个集群，所以每扩容 1 台 eurekaServer，集群内部相互复制的数据量就会增多一份。再如 Zookeeper 和 Etcd 等强一致性的系统，它们的复制协议（Zab/Raft）要求所有写操作被复制到大多数服务器后才能返回成功，那么增加服务器还会影响写操作的效率。\n秒级的服务上下线通知 对于服务的上下线变化，SOFARegistry 使用推送机制，快速地实现端到端的传达。详细介绍见后面《秒级服务上下线通知》一节。\n接下来，我将围绕这些特点，讲解 SOFARegistry 的关键架构设计原理。\n高可用 各个角色都有 failover 机制：\n MetaServer 集群部署，内部基于 Raft 协议选举和复制，只要不超过 1\u0026amp;frasl;2 节点宕机，就可以对外服务。 DataServer 集群部署，基于一致性 Hash 承担不同的数据分片，数据分片拥有多个副本，一个主副本和多个备副本。如果 DataServer 宕机，MetaServer 能感知，并通知所有 DataServer 和 SessionServer，数据分片可 failover 到其他副本，同时 DataServer 集群内部会进行分片数据的迁移。 SessionServer 集群部署，任何一台 SessionServer 宕机时 Client 会自动 failover 到其他 SessionServer，并且 Client …","date":1556175600,"description":"本文为《剖析 | SOFARegistry 框架》第一篇，本篇作者琪祥。","dir":"blog/sofa-registry-introduction/","fuzzywordcount":11100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"04394de7d7b0ecba5303baa6949a40d4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-introduction/","publishdate":"2019-04-25T15:00:00+08:00","readingtime":23,"relpermalink":"/sofastack.tech/blog/sofa-registry-introduction/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"海量数据下的注册中心 - SOFARegistry 架构介绍","type":"blog","url":"/sofastack.tech/blog/sofa-registry-introduction/","wordcount":11079},{"author":"觉生","categories":"Seata","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。 Seata：https://github.com/seata/seata 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23127468，不错过每场直播。\n 2019 年 3 月，蚂蚁金服加入分布式事务 Seata 的社区共建中，并贡献其 TCC 模式。本期是 SOFAChannel 第四期，主题：分布式事务 Seata TCC 模式深度解析，本文根据觉生的直播整理。\n大家晚上好，我是 Seata Committer 觉生，来自蚂蚁金服数据中间件团队。今天的内容主要分为以下四个部分：\n Seata TCC 模式的原理解析； 从 TCC 的业务模型与并发控制分享如何设计一个 TCC 接口，并且适配 TCC 模型； 如何控制异常； 性能优化，使得 TCC 模式能够满足更高的业务需求。 1、 Seata 的 TCC 模式 1.1 服务化拆分 下面我们就进入第一个主题，Seata 的 TCC 模式。蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个系统中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，而网络、机器等不可靠，数据一致性的问题很容易出现，与可扩展性、高可用容灾等要求并肩成为金融 IT 架构支撑业务转型升级的最大挑战之一。\n从图中可以看到，从单系统到微服务转变，其实是一个资源横向扩展的过程，资源的横向扩展是指当单台机器达到资源性能瓶颈，无法满足业务增长需求时，就需要横向扩展资源，形成集群。通过横向扩展资源，提升非热点数据的并发性能，这对于大体量的互联网产品来说，是至关重要的。服务的拆分，也可以认为是资源的横向扩展，只不过方向不同而已。\n资源横向扩展可能沿着两个方向发展，包括业务拆分和数据分片：\n 业务拆分。根据功能对数据进行分组，并将不同的微服务分布在多个不同的数据库上，这实际上就是 SOA 架构下的服务化。业务拆分就是把业务逻辑从一个单系统拆分到多个微服务中。\n 数据分片。在微服务内部将数据拆分到多个数据库上，为横向扩展增加一个新的维度。数据分片就是把一个微服务下的单个 DB 拆分成多个 DB，具备一个 Sharding 的功能。通过这样的拆解，相当于一种资源的横向扩展，从而使得整个架构可以承载更高的吞吐。\n 横向扩展的两种方法可以同时进行运用：交易、支付与账务三个不同微服务可以存储在不同的数据库中。另外，每个微服务内根据其业务量可以再拆分到多个数据库中，各微服务可以相互独立地进行扩展。\nSeata 关注的就是微服务架构下的数据一致性问题，是一整套的分布式事务解决方案。Seata 框架包含两种模式，一种是 AT 模式。AT 模式主要从数据分片的角度，关注多 DB 访问的数据一致性，当然也包括多服务下的多 DB 数据访问一致性问题。\n另外一个就是 TCC 模式，TCC 模式主要关注业务拆分，在按照业务横向扩展资源时，解决微服务间调用的一致性问题，保证读资源访问的事务属性。\n今天我们主要讲的就是TCC模式。在讲 TCC 之前，我们先回顾一下 AT 模式，这样有助于我们理解后面的 TCC 模式。\n1.2. AT 模式 对于 AT 模式，之前其他同学已经分享过很多次，大家也应该比较熟悉了。AT 模式下，把每个数据库被当做是一个 Resource，Seata 里称为 DataSource Resource。业务通过 JDBC 标准接口访问数据库资源时，Seata 框架会对所有请求进行拦截，做一些操作。每个本地事务提交时，Seata RM（Resource Manager，资源管理器） 都会向 TC（Transaction Coordinator，事务协调器） 注册一个分支事务。当请求链路调用完成后，发起方通知 TC 提交或回滚分布式事务，进入二阶段调用流程。此时，TC 会根据之前注册的分支事务回调到对应参与者去执行对应资源的第二阶段。TC 是怎么找到分支事务与资源的对应关系呢？每个资源都有一个全局唯一的资源 ID，并且在初始化时用该 ID 向 TC 注册资源。在运行时，每个分支事务的注册都会带上其资源 ID。这样 TC 就能在二阶段调用时正确找到对应的资源。\n这就是我们的 AT 模式。简单总结一下，就是把每个数据库当做一个 Resource，在本地事务提交时会去注册一个分支事务。\n1.3 TCC 模式 那么对应到 TCC 模式里，也是一样的，Seata 框架把每组 TCC 接口当做一个 Resource，称为 TCC Resource。这套 TCC 接口可以是 RPC，也以是服务内 JVM 调用。在业务启动时，Seata 框架会自动扫描识别到 TCC 接口的调用方和发布方。如果是 RPC 的话，就是 sofa:reference、sofa:service、dubbo:reference、dubbo:service 等。\n扫描到 TCC 接口的调用方和发布方之后。如果是发布方，会在业务启动时向 TC 注册 TCC Resource，与DataSource Resource 一样，每个资源也会带有一个资源 ID。\n如果是调用方，Seata 框架会给调用方加上切面，与 AT 模式一样，在运行时，该切面会拦截所有对 TCC 接口的调用。每调用一次 Try 接口，切面会先向 TC 注册一个分支事务，然后才去执行原来的 RPC 调用。当请求链路调用完成后，TC 通过分支事务的资源ID回调到正确的参与者去执行对应 TCC 资源的 Confirm 或 Cancel 方法。\n在讲完了整个框架模型以后，大家可能会问 TCC 三个接口怎么实现。因为框架本身很简单，主要是扫描 TCC 接口，注册资源，拦截接口调用，注册分支事务，最后回调二阶段接口。最核心的实际上是 TCC 接口的实现逻辑。下面我将根据蚂蚁金服内部多年的实践来为大家分析怎么实现一个完备的 TCC 接口。\n2、 TCC 业务模型与并发控制 2.1 TCC 设计原则 从 TCC 模型的框架可以发现，TCC 模型的核心在于 TCC 接口的设计。用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。下面我会分享蚂蚁金服内多年的 TCC 应用实践以及在 TCC 设计和实现过程中的注意事项。\n设计一套 TCC 接口最重要的是什么？主要有两点，第一点，需要将操作分成两阶段完成。TCC（Try-Confirm-Cancel）分布式事务模型相对于 XA 等传统模型，其特征在于它不依赖 RM 对分布式事务的支持，而是通过对业务逻辑的分解来实现分布式事务。\nTCC 模型认为对于业务系统中一个特定的业务逻辑 ，其对外提供服务时，必须接受一些不确定性，即对业务逻辑初步操作的调用仅是一个临时性操作，调用它的主业务服务保留了后续的取消权。如果主业务服务认为全局事务应该回滚，它会要求取消之前的临时性操作，这就对应从业 …","date":1556089200,"description":"本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。","dir":"blog/sofa-channel-4-retrospect/","fuzzywordcount":10500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"75094c50f180bcd31d84bc687e4c93e0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-4-retrospect/","publishdate":"2019-04-24T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/sofa-channel-4-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。 Seata：https://","tags":["Seata","SOFAChannel"],"title":"分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-4-retrospect/","wordcount":10459},{"author":"青勤","categories":"SOFAActs","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23195297，不错过每场直播。\n 大家晚上好，我是蚂蚁金服自动化测试框架 SOFAActs 开源核心成员青勤，目前从事测试技术相关的研发工作，今晚将由我来给大家分享交流自动化测试框架 SOFAActs 的基本原理和使用，今天的内容主要分为以下四个章节：\n 项目介绍 SOFAActs 接入 功能介绍与使用 升阶功能使用 欢迎大家 Star 我，SOFAActs：https://github.com/sofastack/sofa-acts\n1 项目介绍 在分享使用操作前，我将引导大家来熟悉下 SOFAActs 的项目背景、基本原理等。\n对于研发质量保障而言，金融系统和金融业务的多样性、复杂性同样也会在测试场景、测试验证和测试流程的复杂程度上得到充分体现。\n譬如，对于包含出参、RPC 调用、DB 变更和异常等多个测试验证点的用例而言，在研发和测试人员维护和验证用例场景的过程中，时常发生业务结果校验遗漏，对我们及早发现和纠错问题造成干扰，进而无法严格保障产品质量。这些问题对研发质量保障提出了很高的挑战，相应的自动化、精细化的白盒测试工具需求日益增长，这其中就包括 SOFAActs。\n为了解决上述痛点、满足精细化测试需要，在多年测试实践积累与沉淀下，我们研发了基于模型驱动的 SOFAActs 测试框架，它可以灵活、可扩展的提供一站式用例管理，标准化测试执行和精细化校验。目前 SOFAActs 测试框架逐渐成熟并在蚂蚁金服内部得到广泛应用。\n1.1 项目架构 介绍完背景，我们来看下 SOFAActs 的大体框架，SOFAActs 底层封装并集成适配 SOFABoot 等运行环境。\n在重要的引擎层，SOFAActs 封装了工具类和数据模型，并将测试模式的过程进行了标准化，提供通用测试能力和扩展点。对于有自动化测试经验的同学来讲，测试模式其实并不复杂，这其中有很多工作是可以抽象和固定的，SOFAActs 将这部分内容内聚到引擎层，封装成标准测试流程等，尤其是模型驱动和精细化校验等，从而释放精力，将更多关注点聚焦在待测目标上。\n引擎层之上，是 SOFAActs 提供的可视化用例管理功能，可以一站式的维护测试脚本、测试数据和数据模型，借助可视化编辑器可成倍提高用例管理等等操作效率，整体而言 SOFAActs 围绕模型驱动引擎和可视化编辑器，将测试代码的编写工作量极尽降低，目标聚焦在测试对象上。\n这里我们示例看下，SOFAActs 对测试代码和效率的优化。这里以 Credit 接口为例，业务处理开始之前会检查传参，构造上下文、随后发起业务处理，涉及对三张表的读取或变更，并在数据库事物结束之后，返回业务处理结果。\n 针对这一业务逻辑，这里我们构造一个 Credit 接口的完整测试用例，在代码驱动测试时，它需要一下 9 个步骤，手动准备依赖数据、构造请求参数、执行业务逻辑、校验业务结果以及数据清理等等，人工介入成本居高，尤其当存在多个用例时，测试代码可复用性低，测试效率是难以得到有效提升。而与之对比，在模型驱动测试下，Credit 接口的 SOFAActs 测试脚本会对固有的测试模式进行封装，用例复杂度得到极大精简，众多用例数据可以得到高效的可视化管理。\n1.2 执行原理 在开始使用 SOFAActs 之前，我们来了解一下有关 SOFAActs 执行引擎的运作原理。SOFAActs 框架也提供了非常多的扩展点，如果需要个性化的定义，可以对每一个环节进行扩展。\n上文中已提到过 SOFAActs 执行引擎是对测试模式过程的封装，Setup 方法是引擎入口，用于加载初始化 SOFAActs 运行时的必需资源，如获取数据源。\n以下是主体测试过程：clear、prepare、execute、check 这 4 个方法依次负责环境清理、依赖准备、执行、结果校验等。这些内容是代码驱动测试时需要手写的测试代码和内容，每个测试脚本的完成意味着上面的过程会被我们重复一遍，于是 SOFAActs 将这部分内容进行了封装，实现了最通用基础的功能。\n右侧，我们对高频数据如方法入参、出参、异常和依赖DB数据进行了抽象，给出 SOFAActs 的模型，这是代码驱动转向模型驱动、精细化校验的基础。左侧的数据总线会贯穿每个用例的执行生命周期，即贯穿中间的主体测试过程，如果大家对框架封装的基础功能有自定义需要，可以通过数据总线对 SOFAActs 的对象、方法进行获取、重写，以便更灵活的控制框架行为。当然 SOFAActs 对这些内容作了较好的封装，覆盖了大部分的测试需求，无需大家过度关注。\n以上就是 SOFAActs 的执行原理，接下来我会给大家详细介绍 SOFAActs 的接入和使用。\n2 SOFAActs 接入 SOFAActs 分为两部分，其一是可视化编辑器，在 [SOFAStack 官网上 1 我们可以获取该编辑器的安装包，并通过 IDEA 的插件管理进行安装。其二是 SOFAActs 的基础 jar，它提供了 SOFAActs 用例运行的环境支持，在 test 模块 pom 中添加下列依赖即可，有关 test 模块或者多模块详细内容大家可以参考 [SOFAActs 的快速开始文档 1 。\n3 功能介绍和使用 下面，我们进入 SOFAActs 的功能介绍和使用章节，这部分我将分为三小节展开：一站式构建、SOFAActs 核心的模型驱动以及 SOFAActs 提供的精准校验。\n3.1 一站式构建 一站式构建中，SOFAActs 通过可视化编辑器为我们提供了便捷操作，以帮助一键配置初始化、构建测试脚本与模型，可视化管理用例数据等等。借助可视化编辑器，在整个过程中我们可以替换大部分手工编写代码的工作，进行一站式操作。\n一键初始化\n这里我们示例看下，如何操作一键初始化以及一键初始化做哪些内容。首先一键初始化框架只需要 3 个鼠标点击步骤。在 Package 视图下选中测试模块并右键选择 SOFAActs 功能，一键初始化，输入该应用的应用名称和工程编码格式。在一键初始化完成后，SOFAActs 将会在 test 模块写入 SOFAActs 配置文件，DB 连接配置文件，测试套件配置文件以及创建模型存储目录等。\n acts-config 配置文件是 SOFAActs 的核心配置，提供了测试环境切换、数据库连接切换、冒烟测试以及预跑反填等配置，来开关 SOFAActs 的相关功能；model 目录用于存放对象模型、数据模型，以便对模型进行统一管理；DB 配置文件指明了数据库连接信息，用于生成数据模型时自动填充表结构和模版数据。\n一键生成测试脚本\n在完成配置初始化操作后，我们可以开始第一个用例的编写，SOFAActs 提供了一键测试脚本生成功能。以待测的 getMessage 接口为例，在其方法定义上右键选择 SOFAActs 功能，生成测试用例，在弹出框中检查用例信息，修正无误后点击确定可以生成该 …","date":1556089200,"description":"本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。","dir":"blog/sofa-channel-5-retrospect/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1f088b226caf9430dc6aafb3f248316d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-5-retrospect/","publishdate":"2019-04-24T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-5-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAAc","tags":["SOFAActs","SOFAChannel"],"title":"给研发工程师的代码质量利器 | SOFAChannel#5 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-5-retrospect/","wordcount":5492},{"author":"SOFAStack","categories":"SOFAStack","content":"Hey, SOFAer！有些话想对你说：\n“开源”二字代表的不仅仅是一个项目，更是代表了整个技术社区，代表了隐藏在背后的工程师们。\n很幸运，这一年遇到你们。\n生于蚂蚁金服，经历 12 年的业务锤炼，这是金融级分布式架构 SOFAStack。SOFAStack 的发展受益于开源社区的优秀产品，我们也决定结合我们的实践积累，把这些技术反馈给开源社区。\n于是，2018 年 4 月，SOFAStack 宣布开源，项目地址：https://github.com/alipay 。\n这一年，SOFAStack 逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFABolt、SOFAMosn、SOFAMesh、SOFAJRaft、SOFAActs、SOFARegistry 等组件。2019 年 3 月，蚂蚁金服加入分布式事务 Seata 的社区共建中，并贡献其 TCC 模式。\n这一年，我们获得了 14,000+ Star，超过 100 位贡献者参与，并有超过 30 家企业用户将 SOFAStack 应用在了生产环境上。\n这一年，SOFAStack 团队从电脑屏幕前，走到了开源社区里，与大家讨论并吸纳社区的建议。\n这一年，尝试了很多的“第一次”：第一次与大家编写 SOFALab 源码解析系列文章，第一次做 SOFAChannel 技术直播，第一次组织 SOFAMeetup，第一次在开源技术大会演讲。\n嘿，或许你见过我们紧张的样子。\n这一年，我们得到了太多来自社区的帮助，因为你们，SOFAStack 团队能一直享受“Make something people want”的乐趣。\n这一年，感谢有你。Hey, SOFAer~有些话想对你说：\n戳这里\n","date":1555333200,"description":"这一年，感谢有你。","dir":"blog/sofastack-anniversary-1/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"82d2afd98352ab185691773fcd616233","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-anniversary-1/","publishdate":"2019-04-15T21:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofastack-anniversary-1/","summary":"Hey, SOFAer！有些话想对你说： “开源”二字代表的不仅仅是一个项目，更是代表了整个技术社区，代表了隐藏在背后的工程师们。 很幸运，这一年遇到你","tags":["SOFAStack"],"title":"Hey, SOFAer！有些话想对你说：","type":"blog","url":"/sofastack.tech/blog/sofastack-anniversary-1/","wordcount":639},{"author":"李钊","categories":"Seata","content":" 本文作者李钊，公众号「咖啡拿铁」作者，分布式事务 Seata 社区 Contributor。\n1.关于 Seata 在前不久，我写了一篇关于分布式事务中间件 Fescar 的解析，没过几天 Fescar 团队对其进行了品牌升级，取名为 Seata(Simpe Extensible Autonomous Transcaction Architecture)，而以前的 Fescar 的英文全称为 Fast \u0026amp;amp; EaSy Commit And Rollback。可以看见 Fescar 从名字上来看更加局限于 Commit 和 Rollback，而新的品牌名字 Seata 旨在打造一套一站式分布式事务解决方案。更换名字之后，我对其未来的发展更有信心。\n这里先大概回忆一下 Seata 的整个过程模型：\n TM：事务的发起者。用来告诉 TC，全局事务的开始，提交，回滚。 RM：具体的事务资源，每一个 RM 都会作为一个分支事务注册在 TC。 TC 事务的协调者。也可以看做是 Fescar-server，用于接收我们的事务的注册，提交和回滚。 在之前的文章中对整个角色有个大体的介绍，在这篇文章中我将重点介绍其中的核心角色 TC，也就是事务协调器。\n2.Transaction Coordinator 为什么之前一直强调 TC 是核心呢？那因为 TC 这个角色就好像上帝一样，管控着芸芸众生的 RM 和 TM。如果 TC 一旦不好使，那么 RM 和 TM 一旦出现小问题，那必定会乱的一塌糊涂。所以要想了解 Seata，那么必须要了解他的 TC。\n那么一个优秀的事务协调者应该具备哪些能力呢？我觉得应该有以下几个：\n 正确的协调：能正确的协调 RM 和 TM 接下来应该做什么，做错了应该怎么办，做对了应该怎么办。 高可用：事务协调器在分布式事务中很重要，如果不能保证高可用，那么他也没有存在的必要了。 高性能：事务协调器的性能一定要高，如果事务协调器性能有瓶颈，那么他所管理的 RM 和 TM 会经常遇到超时，从而引起回滚频繁。 高扩展性：这个特点是属于代码层面的，如果是一个优秀的框架，那么需要给使用方很多自定义扩展，比如服务注册/发现，读取配置等等。 下面我也将逐步阐述 Seata 是如何做到上面四点。\n2.1 Seata-Server 的设计 Seata-Server 整体的模块图如上所示：\n Coordinator Core：最下面的模块是事务协调器核心代码，主要用来处理事务协调的逻辑，如是否 Commit、Rollback 等协调活动。 Store：存储模块，用来将我们的数据持久化，防止重启或者宕机数据丢失。 Discover：服务注册/发现模块，用于将 Server 地址暴露给 Client。 Config：用来存储和查找服务端的配置。 Lock：锁模块，用于给 Seata 提供全局锁的功能。 Rpc：用于和其他端通信。 HA-Cluster：高可用集群，目前还没开源。为 Seata 提供可靠的高可用功能。 2.2 Discover 首先来讲讲比较基础的 Discover 模块，又称服务注册/发现模块。我们将 Seata-Server 启动之后，需要将自己的地址暴露给其他使用者，那么就需要这个模块帮忙。\n这个模块有个核心接口 RegistryService，如上图所示：\n register：服务端使用，进行服务注册。 unregister：服务端使用，一般在 JVM 关闭钩子，ShutdownHook 中调用。 subscribe：客户端使用，注册监听事件，用来监听地址的变化。 unsubscribe：客户端使用，取消注册监听事件。 lookup：客户端使用，根据 Key 查找服务地址列表。 close：都可以使用，用于关闭 Register 资源。 如果需要添加自己定义的服务注册/发现，那么实现这个接口即可。截止目前在社区的不断开发推动下，已经有四种服务注册/发现，分别是 redis、zk、nacos、eruka。下面简单介绍下 Nacos 的实现：\n2.2.1 register 接口 step1：校验地址是否合法；\nstep2：获取 Nacos 的 Name 实例，然后将地址注册到当前 Cluster 名称上面。\nunregister 接口类似，这里不做详解。\n2.2.2 lookup 接口 step1：获取当前 clusterName 名字；\nstep2：判断当前 Cluster 是否已经获取过了，如果获取过就从 Map 中取；\nstep3：从 Nacos 拿到地址数据，将其转换成我们所需要的；\nstep4：将我们事件变动的 Listener 注册到 Nacos。\n2.2.3 subscribe 接口 这个接口比较简单，具体分两步：\nstep1：将 Clstuer 和 Listener 添加进 Map 中；\nstep2：向 Nacos 注册。\n2.3 Config 配置模块也是一个比较基础，比较简单的模块。我们需要配置一些常用的参数比如：Netty 的 Select 线程数量，Work 线程数量，Session 允许最大为多少等等，当然这些参数在 Seata 中都有自己的默认设置。\n同样的在 Seata 中也提供了一个接口 Configuration，用来自定义我们需要的获取配置的地方：\n getInt/Long/Boolean/Config()：通过 DataId 来获取对应的值。 putConfig：用于添加配置。 removeConfig：删除一个配置。 add/remove/get ConfigListener：添加/删除/获取 配置监听器，一般用来监听配置的变更。 目前为止有四种方式获取 Config：File（文件获取）、Nacos、Apollo、ZK。在 Seata 中首先需要配置 registry.conf，来配置 conf 的类型。实现 conf 比较简单这里就不深入分析。\n2.4 Store 存储层的实现对于 Seata 是否高性能，是否可靠非常关键。\n如果存储层没有实现好，那么如果发生宕机，在 TC 中正在进行分布式事务处理的数据将会被丢失。既然使用了分布式事务，那么其肯定不能容忍丢失。如果存储层实现好了，但是其性能有很大问题，RM 可能会发生频繁回滚那么其完全无法应对高并发的场景。\n在 Seata 中默认提供了文件方式的存储，下面定义存储的数据为 Session，而 TM 创造的全局事务数据叫 GloabSession，RM 创造的分支事务叫 BranchSession，一个 GloabSession 可以拥有多个 BranchSession。我们的目的就是要将这么多 Session 存储下来。\n在 FileTransactionStoreManager#writeSession 代码中：\n上面的代码主要分为下面几步：\nstep1：生成一个 TransactionWriteFuture。\nstep2：将这个 futureRequest 丢进一个 LinkedBlockingQueue 中。为什么需要将所有数据都丢进队列中呢？当然这里其实也可以用锁来实现，在 …","date":1554793200,"description":"在这篇文章，将重点介绍 Seata 其中的核心角色 TC，也就是事务协调器。","dir":"blog/seata-server-deep-analysis/","fuzzywordcount":6900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3354370f3ca29297c819c279994e0a0d","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-server-deep-analysis/","publishdate":"2019-04-09T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/seata-server-deep-analysis/","summary":"本文作者李钊，公众号「咖啡拿铁」作者，分布式事务 Seata 社区 Contributor。 1.关于 Seata 在前不久，我写了一篇关于分布式事务中间件 Fescar 的解析，没","tags":["Seata"],"title":"深度剖析一站式分布式事务方案 Seata-Server","type":"blog","url":"/sofastack.tech/blog/seata-server-deep-analysis/","wordcount":6831},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 活动时间：4 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 4月初，分布式事务 Fescar 宣布进行品牌升级为 Seata，Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n本期为 SOFAChannel 线上直播第 4 期，将邀请 蚂蚁金服 技术专家 \u0026amp;amp; Seata Committer 觉生 和大家一起探讨 《分布式事务 Seata TCC 模式深度解析》。\n本期分享大纲：\n TCC 模式基本原理解析 分布式事务并发控制解析 分布式事务空回滚与幂等解析 分布式事务防悬挂解析 分布式事务异步化解析 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/462\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 分布式事务 Seata TCC 模式深度解析 觉生 蚂蚁金服 技术专家 / Seata Committer\n本期分享大纲： TCC 模式基本原理解析 分布式事务并发控制解析 分布式事务空回滚与幂等解析 分布式事务防悬挂解析 分布式事务异步化解析 嘉宾 SOFAGirl 主持人 觉生 蚂蚁金服 技术专家 / Seata Committer ","date":1554783000,"description":"4 月 18 日周四晚 7 点，线上直播第 4 期。","dir":"activities/sofa-channel-4/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0e0d4d4a75723cc408567a65aab0c3df","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-4/","publishdate":"2019-04-09T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-4/","summary":"概要 活动主题：SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 活动时间：4 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介","tags":["SOFAChannel","Seata"],"title":"SOFAChannel#4：分布式事务 Seata TCC 模式深度解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-4/","wordcount":551},{"author":"绍辉","categories":"Seata","content":" 上周，分布式事务 Fescar 宣布进行品牌升级：\nThanks, Fescar ❤️，\nHello, Seata 🚀。\nSeata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。\n项目地址：https://github.com/seata/seata\n蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n为了帮助大家理解，分布式事务开源负责人绍辉进行了一次线下分享，详细讲述了分布式事务在蚂蚁金服的发展，希望可以帮助大家理解分布式事务，以下为分享的文字整理版本。\n前言 今天的分享将从以下三个部分展开：分布式事务问题产生的背景、蚂蚁金服分布式事务以及分布式事务 Seata 的 Roadmap。\n分享嘉宾：绍辉 蚂蚁金服 分布式事务开源负责人\n1、分布式事务问题产生的背景 1.1、数据库的水平拆分 蚂蚁金服早期，业务量比较小，单库单表便能满足业务需求；但是随着业务的发展，单库单表数据库逐渐成为瓶颈。为了解决数据库的瓶颈问题，我们对数据库进行了水平拆分。拆分所带来的一个问题就是以前一个数据库上便能完成的写操作现在要跨多个数据库，由此带来了跨库事务问题。\n1.2、业务的服务化拆分 蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个 APP 中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，由此产生了跨服务事务问题。\n1.3、转账案例说明数据一致性问题 数据库的水分拆分以及服务的垂直拆分，所带来的问题是一个业务活动通常要调用多个服务、访问多个数据库才能完成。\n以金融业务场景下的转账场景为例，转账服务要完成以下操作：\n 调用交易系统服务创建交易订单； 调用支付系统记录支付明细； 调用账务系统执行 A 扣钱； 调用账务系统执行 B 加钱。 以上 4 个操作要跨 3 个系统，访问 4 个数据库。而网络、数据库、机器等都具有不可靠性，我们很难保证以上 4 个操作能 100% 全部成功。\n在金融属性的业务中，不允许 A 账户的钱扣了，而 B 账户的钱没有加上的现象出现，所以我们必须想办法保证 1 ~ 4 这四个操作要么全部成功，要么全部失败；所以蚂蚁金服自主研发了分布式事务中间件，解决跨服务、跨数据库的数据一致性问题。\n2、蚂蚁金服分布式事务 2.1、分布式事务理论基础 在介绍蚂蚁金服的分布式事务中间件之前，先介绍一些分布式事务的理论背景。\n 2PC 两阶段提交协议（Two Phase Commitment Protocol）是分布式事务最基本的协议。在两阶段提交协议中，有一个事务管理器和多个资源管理器，事务管理器分两阶段协调资源管理器。在第一阶段，事务管理器询问所有资源管理器准备是否成功。如果所有资源均准备成功，那么在第二阶段事务管理器会要求所有资源管理器执行提交操作；如果任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求所有资源管理器在第二阶段执行回滚操作。通过事务管理器的两阶段协调，最终所有资源管理器要么全部提交，要么全部回滚，最终状态都是一致的。\n TCC 资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现。TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题。TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中。事务管理器分两个阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法，最终所有 TCC 服务要么全部都是提交的、要么全部都是回滚的。\n2.2、蚂蚁金服分布式产品介绍 蚂蚁金服从 2007 年开始做分布式事务，至今已经有 12 年历史。蚂蚁金服的分布式事务最初是采用 TCC 实现的，TCC 模式帮蚂蚁业务解决了各类金融核心场景下的数据一致性问题。\n2007 年我们开始支持双十一，为了满足双十一的高性能需求，我们对分布式事务做了一系列的性能优化。\n2013年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014年，蚂蚁金服分布式事务中间件开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户；在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。\n所以在 2015年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务中间件经过长期演进，目前积累了 TCC、FMT 和 XA 三种模式，具有丰富的应用场景。下面分别介绍这三种模式。\n2.3、TCC 模式 蚂蚁金服的 TCC 模式和前面介绍 TCC 理论中提的 TCC 原理是一致的。不同的是，我们在整个分布式事务执行过程中，会去记录事务日志，一个分布式事务会产生一条主事务记录（对应发起方）和若干分支事务记录（对应 TCC 参与者）。记录事务日志的目的是，当分布式事务执行过程中出现异常中断时，事务恢复服务通过轮询事务日志，找出这个异常中断的事务，补偿执行该异常事务剩余未完成的动作，整个分布式事务的最终状态要么全部提交，要么全部回滚。\nTCC 设计规范和注意事项：\n用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。经过蚂蚁金服多年的 TCC 应用实践，总结如下在 TCC 设计和实现过程中的注意事项：\n1、业务操作分两阶段完成： 接入 TCC 前，业务操作只需要一步就能完成。但是在接入 TCC 之后，需要考虑如何将其分成两个阶段完成：把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户 A 的余额中有 100 元，需要扣除其中 30 元”。\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成两步完成：\n Try 操作：资源的检查和预留。 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交。 在扣款场景下，Confirm 阶段 …","date":1554706800,"description":"本文根据 SOFAMeetup#1 分享整理，详细讲述了分布式事务在蚂蚁金服的发展。","dir":"blog/sofa-meetup-1-seata/","fuzzywordcount":5000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fd2c8c1c6ee4231c6987a1d556ce4089","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-seata/","publishdate":"2019-04-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-seata/","summary":"上周，分布式事务 Fescar 宣布进行品牌升级： Thanks, Fescar ❤️， Hello, Seata 🚀。 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。 项","tags":["Seata","SOFAMeetup"],"title":"蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-seata/","wordcount":4909},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享视频回顾获取方式见文章底部。\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nGitHub 地址：https://github.com/alipay/sofa-jraft\n之前，我们有一篇介绍 SOFAJRaft 的文章，可在文末获得链接，延续这个内容，今天的演讲分为三部分，先简要介绍 Raft 算法，然后介绍 SOFAJRaft 的设计，最后说说它的优化。\n分享嘉宾：力鲲 蚂蚁金服 SOFAJRaft 核心成员\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务。 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\nLeader 选举 复制状态机集群在利用 Raft 算法保证一致性时，要做的第一件事情就是 Leader 选举。在讲 Leader 选举之前我们先要说一个重要的概念：Term。Term 用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求； 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳； 当然了，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。\n当选举 Leader 成功之后，整个集群就可以向外提供正常读写服务了，如图所示，集群由一个 Leader 两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳或者把 Log 复制给 Follower。\nLog 复制 下面我们就详细说一下 Log 复制。我们之前已经说了 Log 就是 Client 发送给复制状态机的一系列命令。这里我们再举例解释一下 Log，比如我们的复制状态机要实现的是一个银行账户系统，那么这个 Log 就可以是 Client 发给账户系统的一条存钱的命令，比如“存 100 元钱”。\nLeader 与 Follower 之间的日志复制是共识算法运用于复制状态机的重要目的，在 Raft 算法中 Log 由 TermId、LogIndex、LogValue 这三要素构成，在这张图上每一个小格代表一个 Log。当 Leader 在向 Follower 复制 Log 的时候，Follower 还需要对收到的 Log 做检查，以确保这些 Log 能和本地已有的 Log 保持连续。我们之前说了，Raft 算法是要严格保证 Log 的连续性的，所以 Follower 会拒绝无法和本地已有 Log 保持连续的复制请求，那么这种情况下就需要走 Log 恢复的流程。总之，Log 复制的目的就是要让所有的 Server 上的 Log 无论在内容上还是在顺序上都要保持完全一致，这样才能保证所有状态机执行结果一致。\n目前已经有一些很优秀的对 Raft 的实现，比如 C++ 写的 braft，Go 写的 etcd，Rust 写的 TiKV。当然了，SOFAJRaft 并不是 Raft 算法的第一个 Java 实现，在我们之前已经有了很多项目。但是经过我们的评估，觉得目前还是没有一个 Raft 的 Java 实现库类能够满足蚂蚁生产环境的要求，这也是我们去写 SOFAJRaft 的主要原因。\nSOFAJRaft 介绍 接下来我们介绍 SOFAJRaft。\nSOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。从去年 3 月开发到今年 2 月完成，并在今年 3 月开源。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统，目前使用案例有 RheaKV，这是 SOFAJRaft 中自带的一个分布式 KV 存储，还有今天开源的 SOFA 服务注册中心中的元信息管理模块也是用到了 SOFAJRaft，除此之外还有一些内部的项目也有使用，但是因为没有开源，所以就不再详述了。\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依然用之前的银 …","date":1554188400,"description":"本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享视频回顾获取方式见文章底部。","dir":"blog/sofa-meetup-1-jraft/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"614c6031770d98ed7d0c23c3276d72ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-jraft/","publishdate":"2019-04-02T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-jraft/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFAJRaft","SOFAMeetup"],"title":"详解蚂蚁金服 SOFAJRaft | 生产级高性能 Java 实现","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-jraft/","wordcount":5507},{"author":"张磊、心贵、临石、徙远、衷源、浔鸣","categories":"Kubernetes","content":" 本文由张磊、心贵、临石、徙远、衷源、浔鸣等同学联合撰写。\nKubernetes 1.14.0 Release 已经于 3 月 25 日正式发布。相信你也已经注意到，相比于1.13 和 1.12 版本，这次发布包含的重要变非常多，其对应的 Release Note 的篇幅长度也创下了“新高”。\n面对这样一份“海量信息”的 Release Note，我们该如何从这份文档里进行高效的信息过滤和挖掘，帮助团队更精准、快速的梳理出这次发布最主要的技术脉络呢？\n在本篇文章中，我们将 1.14 的 Release Note 按照主题进行了重新归纳和梳理，按照类别对重要变更进行了技术剖析和讨论。希望这种“分类解读”的方式，能够帮助大家更好的理解 1.14 这个发布的核心内容。\nWindows Node 正式生产可用 随着1.14的发布，Kubernetes 对windows节点的生产级支持无疑是一个重要的里程碑。具体来说，1.14 版本针对 Windows 做了大量增强；\n Pod：Pod内支持 readiness 和 liveness 探针；支持进程隔离和 volume 共享的多容器 Pod；Pod 支持原生configmap 和 sercret；Pod 支持emptyDir；支持对 Pod 进行资源配额等；但是像优雅删除、Termination message、Privileged Containers、HugePages、Pod 驱逐策略等部分特性还未在 1.14 版本提供； Service：支持服务环境变量提供 DNS 解析；支持 NodePort、ClusterIP、LoadBalancer、Headless service；暂不支持 Pod 的 hostnetwork 模式； 常规 Workload controller：RS、deployment、statefulset、daemonset、job、cronjob 均支持 windows 容器； 除此之外，支持 Pod 和 container 维度的metrics、HPA、“kubectl exec”、调度抢占、resource quotas、CNI 网络支持等多种特性让 windows workload 更加云原生；由于 windows 的特殊兼容性，目前 host OS 的版本必须和容器镜像 OS 版本一致，1.14 版本支持 win server 2019；未来版本中会考虑使用 Hyper-V 隔离机制来解决版本兼容性问题。 而伴随着 Windows 容器的生态正在慢慢壮大，能够在生产级别支持 Windows 节点的容器服务开始见诸各大云厂商。阿里云容器服务（ACK）近期已经推出了 Windows Container 的支持，提供了 linux/windows 应用混合部署的统一管理能力。\n参见：Support for Windows Nodes is Graduating to Stable (#116 )\n本地持久化数据卷（Local PV） 正式可用 长期以来，能够让 Kubernetes 直接用宿主机的本地存储设备（比如：本地 SSD 硬盘）来提供持久化数据卷（即：Local PV 功能），一直是社区里非常强烈的一个诉求。这个原因很容易理解：相对于远程存储（网络存储），Local PV 在时延性、易用性、稳定性和费用上具有独特的优势，尤其是对于相关特性比较敏感的应用，如数据库应用和搜索引擎应用来说，有着重要的意义。\n而在 1.14 中，Local PV 终于正式宣布 GA，为云上的持久化存储选择增加了一种重要的的可能。\n不过，必须要明确的是， 选择使用 Local PV，也意味着用户必须自己承担一些潜在的风险，这包括：\n 目前社区的开源方案无法动态创建卷 调度器需要由额外的调度逻辑工作，以确保调度的节点可以分配出足够的磁盘容量 容错性差，如果 Pod 正在运行的宿主机宕机或者磁盘发生异常，那么它的持久化卷里的信息可能丢失 第一个问题，可以通过比如阿里云的 local-volume-provisioner 实现本地 SSD Nvme 实例自动创建数据卷来解决，但对于容错性和健壮性的问题，就是比较棘手的了。\n参见：Durable Local Storage Management is Now GA (#121)\nPod 优先级与抢占机制稳定可用 Kubernetes 里的任务优先级（priority）和抢占机制（preemption）的目的十分明确：保证高优先级的任务可以在需要的时候通过抢占低优先级任务的方式得到运行。\n这其中，优先级定义了一个 Pod 在集群中的重要程度，这个重要程度体现且仅体现在两个地方： 1. 高优先级的Pod 在调度阶段更容易被优先调度（K8s 采用队列调度模型），注意这里并不保证高优先级 Pod 永远被优先调度，实际影响调度顺序的因素有很多； 2. 在集群整体负载较高时，如果出现高优先级 Pod 无法被调度的情况（集群中没有满足条件的 Node 供 Pod 运行），K8s 会启动抢占机制，通过抢占已经运行的低优先级的 Pod 的方式，让高优先级的 Pod 可以运行起来。抢占机制便是在这里引入的。\n抢占机制指当调度器发现某个Pod（如 Pod-A）无法在集群中找到合适的节点部署时（所有节点 Predicates 全部失败），会试图通过删除一些优先级低于 Pod-A 的 Pod 来“腾出空间”部署 Pod-A，这样 Pod-A 就可以被调度了。这样一个“看似简单”的需求在分布式环境中实施起来有很多细节，例如：如何决定删除哪个节点的哪些 Pod、如何保证为 Pod-A 腾出的空间不被其它 Pod 占用、如何保证 Pod-A 不被饿死（Starvation）、如何处理有亲和性需求的 Pod 调度约束、是否需要支持跨节点 Preemption 以支持某些特定的约束（例如某 Failure Domain 的反亲和约束）等等。\n参见：Pod Priority and Preemption in Kubernetes (#564) 你一定要知道什么是 Pod Ready++ 在 1.14 版本之前，Kubernetes 判断一个 Pod 是否 Ready，就是检查这个 Pod 的容器是否全部正常运行。但是这里有个问题，那就是容器或者说里面的主进程 Ready，并不一定意味着这个应用副本就一定是就绪的。为了确认 Pod 确实可以正常可用，我们希望给它增加一些外部指标（比如，该 Pod 需要的 Service，DNS，存储等服务全部就绪），来反应这个Pod是否“真正”Ready。\n这个特性，就是1.14 里一个叫做“Pod Readiness Gates”、也叫做 Pod Ready ++ 的特性。它为pod的“Ready 状态” 提供了一个非常强大的扩展点。需要注意的是，用户需要编写一个外部控制器（Controller）来为这个Pod Readiness Gates 字段对应的指标设置值。\n参见：Pod Ready++ (#580) Kubernetes 原生应用管理能力 1.14之后，Kubernetes 项目本身 …","date":1553756400,"description":"在本篇文章中，我们将 1.14 的 Release Note 按照主题进行了重新归纳和梳理，按照类别对重要变更进行了技术剖析和讨论。希望这种“分类解读”的方式，能够帮助大家更好的理解 1.14 这个发布的核心内容。","dir":"blog/k8s-1.14-release-note/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8dddcb73179e656ccebedbba2d4e9131","permalink":"https://sofastack.github.io/sofastack.tech/blog/k8s-1.14-release-note/","publishdate":"2019-03-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/k8s-1.14-release-note/","summary":"本文由张磊、心贵、临石、徙远、衷源、浔鸣等同学联合撰写。 Kubernetes 1.14.0 Release 已经于 3 月 25 日正式发布。相信你也已经注意到，相比于1.13 和 1.12 版本，这次发布包","tags":["Kubernetes"],"title":"Kubernetes 1.14 发布了，Release Note 该怎么读？","type":"blog","url":"/sofastack.tech/blog/k8s-1.14-release-note/","wordcount":4012},{"author":"Yu Shuqiang","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》最后一篇，本篇作者yushuqiang，来自小象生鲜。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:TracerLab/]，目前领取已经完成，感谢大家的参与。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n 前言 自 Google《Dapper，大规模分布式系统的跟踪系统》论文发表以来，开源 Tracer 系统如雨后春笋般相继面市，各显神通，但都是用于分布式系统调用跟踪的组件，通过统一的 traceId 将调用链路中的各种网络调用情况记录下来，以达到透视化网络调用的目的。本文介绍的 SOFATracer 是以日志的形式来记录的，这些日志可用于故障的快速定位，服务治理等。目前来看 SOFATracer 团队已经为我们搭建了一个完整的 Tracer 框架内核，包括数据模型、编码器、跨进程透传 traceId、采样、日志落盘与上报等核心机制，并提供了扩展 API 及基于开源组件实现的部分插件，为我们基于该框架打造自己的 Tracer 平台提供了极大便利。\n作为一个开源实现，SOFATracer 也尽可能提供大而全的插件实现，但由于多数公司都有自己配套的技术体系，完全依赖官方提供的插件可能无法满足自身的需要，因此如何基于 SOFATracer 自身 API 的组件埋点机制进行扩展，实现自己的插件是必须掌握的一项本领。\n本文将根据 SOFATracer 自身 AP I的扩展点及已提供的插件源码来分析下 SOFATracer 插件的埋点机制。\nSOFATracer 的插件埋点机制 对一个应用的跟踪要关注的无非就是 客户端-\u0026amp;gt;web 层-\u0026amp;gt;rpc 服务-\u0026amp;gt;dao 后端存储、cache 缓存、消息队列 mq 等这些基础组件。SOFATracer 插件的作用实际上也就是对不同组件进行埋点，以便基于这些组件采集应用的链路数据。\n不同组件有不同的应用场景和扩展点，因此对插件的实现也要因地制宜，SOFATracer 埋点方式一般是通过 Filter、Interceptor 机制实现的。\n组件扩展入口之 Filter or Interceptor SOFATracer 目前已实现的插件中，像 SpringMVC 插件是基于 Filter 进行埋点的，httpclient、resttemplate 等是基于 Interceptor 机制进行埋点的。在实现插件时，要根据不同插件的特性和扩展点来选择具体的埋点方式。正所谓条条大路通罗马，不管怎么实现埋点，都是依赖 SOFATracer 自身 API 的扩展机制来实现。\nAPI 扩展点之 AbstractTracer API SOFATracer 中所有的插件均需要实现自己的 Tracer 实例，如 SpringMVC 的 SpringMvcTracer 、HttpClient 的 HttpClientTracer 等。\n 基于 SOFATracer API 埋点方式插件扩展如下： AbstractTracer 是 SOFATracer 用于插件扩展使用的一个抽象类，根据插件类型不同，又可以分为 clientTracer 和 serverTracer，分别对应于 AbstractClientTracer 和 AbstractServerTracer；再通过 AbstractClientTracer 和 AbstractServerTracer 衍生出具体的组件 Tracer 实现，比如上图中提到的 HttpClientTracer 、RestTemplateTracer 、SpringMvcTracer 等插件 Tracer 实现。\nAbstractTracer 这里先来看下 AbstractTracer 这个抽象类中具体提供了哪些抽象方法，也就是对于 AbstractClientTracer 和 AbstractServerTracer 需要分别扩展哪些能力。\n从上图 AbstractTracer 类提供的抽象方法来看，不管是 client 还是 server，在具体的 Tracer 插件实现中，都必须提供以下实现：\n DigestReporterLogName ：当前组件摘要日志的日志名称 DigestReporterRollingKey : 当前组件摘要日志的滚动策略 SpanEncoder：对摘要日志进行编码的编码器实现 AbstractSofaTracerStatisticReporter : 统计日志 reporter 类的实现类 基于 SOFATracer 自身 API 埋点最大的优势在于可以通过上面的这些参数来实现不同组件日志之间的隔离，上述需要实现的这些点是实现一个组件埋点常规的扩展点，是不可缺少的。\n上面分析了 SOFATracer API 的埋点机制，并且对于一些需要扩展的核心点进行了说明。SOFATracer 自身提供的内核非常简单，其基于自身 API 的埋点扩展机制为外部用户定制组件埋点提供了极大的便利。下面以 Thrift 扩展，具体分析如何实现一个组件埋点。\n PS : Thrift 是外部用户基于 SOFATracer API 扩展实现的，目前仅用于其公司内部使用，SOFATracer 官方组件中暂不支持，请知悉；后续会沟通作者提供 PR ，在此先表示感谢。\n Thrift 插件埋点分析 这里我们以 Thrift RPC 插件实现为例，分析如何实现一个埋点插件。\n1、实例工程的分包结构\n从上图插件的工程的包结构可以看出，整个插件实现比较简单，代码量不多，但从类的定义来看，直观的体现了SOFATracer 插件埋点机制所介绍的套路。下面将进行详细的分析与介绍。\n2、实现 Tracer 实例\nRpcThriftTracer 继承了 AbstractTracer 类，是对 clientTracer、serverTracer 的扩展。\n AbstractTracer RpcThriftTracer PS：如何确定一个组件是 client 端还是 server 端呢？就是看当前组件是请求的发起方还是请求的接受方，如果是请求发起方则一般是 client 端，如果是请求接收方则是 server 端。那么对于 RPC 来说，即是请求的发起方也是请求的接受方，因此这里实现了 AbstractTracer 类。\n 3、扩展点类实现\n DigestReporterLogName RpcTracerLogEnum …","date":1553697000,"description":"本文为《剖析 | SOFATracer 框架》最后一篇，本篇作者 Yu Shuqiang，来自小象生鲜。","dir":"blog/sofa-tracer-event-tracing-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"35dc2221b95ec62fd2aa03fca6367554","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","publishdate":"2019-03-27T14:30:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 埋点机制剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","wordcount":4338},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack\nScalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n SOFAStack 开源一周年，继续补充开源大图 2018 年 4 月， 蚂蚁金服宣布开源 SOFAStack 金融级分布式架构。这一年的时间，感谢社区的信任和支持，目前已经累积超过一万的 Star 数目，超过 30 家企业用户。 2019 年 3 月 24 日，SOFA 在北京举办了首场 Meetup，我们有幸见到了关心SOFA 的朋友们。 此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。 SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概念 注册中心在微服务架构中位置 服务发现，并非新鲜名词，在早期的 SOA 框架和现在主流的微服务框架中，每个服务实例都需要对外提供服务，同时也需要依赖外部服务。如何找到依赖的服务（即服务定位），最初我们思考了很多方式，比如直接在 Consumer 上配置所依赖的具体的服务地址列表，或者使用 LVS、F5 以及 DNS（域名指向所有后端服务的 IP）等负载均衡。\n但是以上方式都有明显的缺点，比如无法动态感知服务提供方节点变更的情况，另外基于负载均衡的话还需要考虑它的瓶颈问题。所以需要借助第三方的组件，即服务注册中心来提供服务注册和订阅服务，在服务提供方服务信息发生变化、或者节点上下线时，可以动态更新消费方的服务地址列表信息，最终解耦服务调用方和服务提供方。\n能力 服务注册中心的主要能力：\n 服务注册 服务订阅 演进 蚂蚁金服的服务注册中心，经历了 5 代技术架构演进，才最终形成了如今足以支撑蚂蚁海量服务注册订阅的，具有高可用、高扩展性和高时效性的架构。\n数据结构 SOFARegistry 的存储模型比较简单，主要基于 KV 存储两类数据，一类是订阅关系，体现为多个订阅方关心的 Topic（或服务键值）和他们的监听器列表，另一类是同一个 Topic（或服务键值）的发布者列表。基于观察者模式，在服务提供方发生变化时（比如服务提供方的节点上下线），会从订阅关系中寻找相应的订阅者，最终推送最新的服务列表给订阅者。\n存储扩展 主备模式 既然服务注册中心最主要能力之一是存储，那么就要思考：怎么存？存哪儿？存了会不会丢？ 怎么存，主要是由存什么数据来决定的，由于 SOFARegistry 所存储的数据结构比较简单( KV），因为并没有基于关系数据库；另外由于服务发现对变更推送的时效性要求高，但并没有很高的持久化要求(数据可以从服务提供方恢复)，所以最终我们决定自己实现存储能力。 SOFARegistry 的存储节点，最初是主备模式。 强一致集群 随着蚂蚁的服务数据量不断增长，我们将存储改为集群方式，每个存储节点的数据是一样的，每一次写入都保证所有节点写入成功后才算成功。这种模式的特点是每台服务器都存储了全量的服务数据，在当时数据规模比较小的情况下，尚可接受。\n这样的部署结构有两个问题：\n 首先，根据 CAP 原理，在分区容忍性（P）的前提下，为了保持强一致（C），必然牺牲高可用（A）为代价，比如 Zookeeper 是 CP 系统，它在内部选举期间是无法对外提供服务的，另外由于需要保证 C（顺序一致性），写的效率会有所牺牲。 其次，每个节点都存储全量的服务数据，随着业务的发展就有很大的瓶颈问题。 数据分片 如果要实现容量可无限扩展，需要把所有数据按照一定维度进行拆分，并存储到不同节点，当然还需要尽可能地保证数据存储的均匀分布。我们很自然地想到可以进行 Hash 取余，但简单的取余算法在节点数增减时会影响全局数据的分布，所以最终采用了一致性 Hash 算法（这个算法在业界很多场景已经被大量使用，具体不再进行介绍）。\n每个服务数据，经过一致性 Hash 算法计算后会存储到某个具体的 Data 上，整体形成环形的结构。理论上基于一致性 Hash 对数据进行分片，集群可以根据数据量进行无限地扩展。\n内部分层 连接承载 我们知道单机的 TCP 连接数是有限制的，业务应用不断的增多，为了避免单机连接数过多，我们需要将存储节点与业务应用数量成正比地扩容，而我们实际上希望存储节点的数量只跟数据量成正比。所以我们选择从存储节点上把承载连接职责的能力独立抽离出来成为新的一个角色，称之为 Session 节点，Session 节点负责承载来自业务应用的连接。这么一来，SOFARegistry 就由单个存储角色被分为了 Session 和 Data 两个角色，Session 承载连接，Data 承载数据，并且理论上 Session 和 Data 都支持无限扩展。\n如图，客户端直接和 Session 层建立连接，每个客户端只选择连接其中一个 Session 节点，所有原本直接到达 Data层的连接被收敛到 Session 层。Session 层只进行数据透传，不存储数据。客户端随机连接一台 Session 节点，当遇到 Session 不可用时重新选择新的 Session 节点进行重连即可。\n读写分离 分离出 Session 这一层负责承载连接，引起一个新的问题：数据到最终存储节点 Data 的路径变长了，整个集群结构也变的复杂了，怎么办呢？\n我们知道，服务注册中心的一个主要职责是将服务数据推送到客户端，推送需要依赖订阅关系，而这个订阅关系目前是存储到 Data 节点上。在 Data 上存储订阅关系，但是 Client 并没有直接和 Data 连接，那必须要在 Session 上保存映射后才确定推送目标，这样的映射关系占据了大量存储，并且还会随 Session 节点变化进行大量变更，会引起很多不一致问题。\n因此，我们后来决定，把订阅关系信息（Sub）直接存储在 Session 上，并且通过这个关系 Session 直接承担把数据变化推送给客户端的职责。而对于服务的发布信息（Pub）还是通过 Session 直接透传最终在 Data 存储节点上进行汇聚，即同一个服务 ID 的数据来自于不同的客户端和不同的 Session 最终在 Data 的一个节点存储。\n这样划分了 Sub 和 Pub 数据之后，通过订阅关系（Sub）进行推送的过程就有点类似于对服务数据读取的过程，服务发布进行存储的过程有点类似数据写的过程。数据读取的过程，如果有订阅关系就可以确定推送目标，迁移订阅关系数据到 Session，不会影响整个集群服务数据的状态，并且 Client 节点连接新的 Session 时，也会回放所有订阅关系，Session 就可以无状态的 …","date":1553697000,"description":"此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。","dir":"blog/sofa-registry-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"86b3010d0f85f6711d60de29a244ed7e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-deep-dive/","publishdate":"2019-03-27T14:30:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFARegistry","SOFAMeetup"],"title":"蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-registry-deep-dive/","wordcount":4313},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n SOFAStack 开源一周年，继续补充开源大图 2018 年 4 月， 蚂蚁金服宣布开源 SOFAStack 金融级分布式架构。这一年的时间，感谢社区的信任和支持，目前已经累积超过一万的 Star 数目，超过 30 家企业用户。\n2019 年 3 月 24 日，SOFA 在北京举办了首场 Meetup，我们有幸见到了关心 SOFA 的朋友们。\n此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。\nSOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nGitHub 地址：https://github.com/alipay/sofa-registry 概念 注册中心在微服务架构中位置 服务发现，并非新鲜名词，在早期的 SOA 框架和现在主流的微服务框架中，每个服务实例都需要对外提供服务，同时也需要依赖外部服务。如何找到依赖的服务（即服务定位），最初我们思考了很多方式，比如直接在 Consumer 上配置所依赖的具体的服务地址列表，或者使用 LVS、F5 以及 DNS（域名指向所有后端服务的 IP）等负载均衡。\n但是以上方式都有明显的缺点，比如无法动态感知服务提供方节点变更的情况，另外基于负载均衡的话还需要考虑它的瓶颈问题。所以需要借助第三方的组件，即服务注册中心来提供服务注册和订阅服务，在服务提供方服务信息发生变化、或者节点上下线时，可以动态更新消费方的服务地址列表信息，最终解耦服务调用方和服务提供方。\n能力 服务注册中心的主要能力：\n 服务注册 服务订阅 演进 蚂蚁金服的服务注册中心，经历了 5 代技术架构演进，才最终形成了如今足以支撑蚂蚁海量服务注册订阅的，具有高可用、高扩展性和高时效性的架构。\n数据结构 SOFARegistry 的存储模型比较简单，主要基于 KV 存储两类数据，一类是订阅关系，体现为多个订阅方关心的 Topic（或服务键值）和他们的监听器列表，另一类是同一个 Topic（或服务键值）的发布者列表。基于观察者模式，在服务提供方发生变化时（比如服务提供方的节点上下线），会从订阅关系中寻找相应的订阅者，最终推送最新的服务列表给订阅者。\n存储扩展 主备模式 既然服务注册中心最主要能力之一是存储，那么就要思考：怎么存？存哪儿？存了会不会丢？ 怎么存，主要是由存什么数据来决定的，由于 SOFARegistry 所存储的数据结构比较简单( KV），因为并没有基于关系数据库；另外由于服务发现对变更推送的时效性要求高，但并没有很高的持久化要求(数据可以从服务提供方恢复)，所以最终我们决定自己实现存储能力。 SOFARegistry 的存储节点，最初是主备模式。 强一致集群 随着蚂蚁金服的服务数据量不断增长，我们将存储改为集群方式，每个存储节点的数据是一样的，每一次写入都保证所有节点写入成功后才算成功。这种模式的特点是每台服务器都存储了全量的服务数据，在当时数据规模比较小的情况下，尚可接受。\n这样的部署结构有两个问题：\n 首先，根据 CAP 原理，在分区容忍性（P）的前提下，为了保持强一致（C），必然牺牲高可用（A）为代价，比如 Zookeeper 是 CP 系统，它在内部选举期间是无法对外提供服务的，另外由于需要保证 C（顺序一致性），写的效率会有所牺牲。 其次，每个节点都存储全量的服务数据，随着业务的发展就有很大的瓶颈问题。 数据分片 如果要实现容量可无限扩展，需要把所有数据按照一定维度进行拆分，并存储到不同节点，当然还需要尽可能地保证数据存储的均匀分布。我们很自然地想到可以进行 Hash 取余，但简单的取余算法在节点数增减时会影响全局数据的分布，所以最终采用了一致性 Hash 算法（这个算法在业界很多场景已经被大量使用，具体不再进行介绍）。\n每个服务数据，经过一致性 Hash 算法计算后会存储到某个具体的 Data 上，整体形成环形的结构。理论上基于一致性 Hash 对数据进行分片，集群可以根据数据量进行无限地扩展。\n内部分层 连接承载 我们知道单机的 TCP 连接数是有限制的，业务应用不断的增多，为了避免单机连接数过多，我们需要将存储节点与业务应用数量成正比地扩容，而我们实际上希望存储节点的数量只跟数据量成正比。所以我们选择从存储节点上把承载连接职责的能力独立抽离出来成为新的一个角色，称之为 Session 节点，Session 节点负责承载来自业务应用的连接。这么一来，SOFARegistry 就由单个存储角色被分为了 Session 和 Data 两个角色，Session 承载连接，Data 承载数据，并且理论上 Session 和 Data 都支持无限扩展。\n如图，客户端直接和 Session 层建立连接，每个客户端只选择连接其中一个 Session 节点，所有原本直接到达 Data层的连接被收敛到 Session 层。Session 层只进行数据透传，不存储数据。客户端随机连接一台 Session 节点，当遇到 Session 不可用时重新选择新的 Session 节点进行重连即可。\n读写分离 分离出 Session 这一层负责承载连接，引起一个新的问题：数据到最终存储节点 Data 的路径变长了，整个集群结构也变的复杂了，怎么办呢？\n我们知道，服务注册中心的一个主要职责是将服务数据推送到客户端，推送需要依赖订阅关系，而这个订阅关系目前是存储到 Data 节点上。在 Data 上存储订阅关系，但是 Client 并没有直接和 Data 连接，那必须要在 Session 上保存映射后才确定推送目标，这样的映射关系占据了大量存储，并且还会随 Session 节点变化进行大量变更，会引起很多不一致问题。\n因此，我们后来决定，把订阅关系信息（Sub）直接存储在 Session 上，并且通过这个关系 Session 直接承担把数据变化推送给客户端的职责。而对于服务的发布信息（Pub）还是通过 Session 直接透传最终在 Data 存储节点上进行汇聚，即同一个服务 ID 的数据来自于不同的客户端和不同的 Session 最终在 Data 的一个节点存储。\n这样划分了 Sub 和 Pub 数据之后，通过订阅关系（Sub）进行推送的过程就有点类似于对服务数据读取的过程，服务发布进行存储的过程有点类似数据写的过程。数据读取的过程，如果有订阅关系就可以确定推送目标，迁移订阅关系数据到 Session，不会影响整个集群服务数据的状态，并且 Client 节点连接新的 Session 时，也会回放所有订阅关系，Session 就可以无状态的 …","date":1553670000,"description":"本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/sofa-meetup-1-registry/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0e3d1f0cf167e7afea39c2435ceefcfd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-registry/","publishdate":"2019-03-27T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-registry/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFARegistry","SOFAMeetup"],"title":"蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-registry/","wordcount":4318},{"author":"蚂蚁金服团队","categories":"seata","content":" Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。\nSample 地址：https://github.com/fescar-group/fescar-samples/tree/master/tcc\n文末也提供了项目后续的 Roadmap，欢迎关注。\n一、TCC 简介 在两阶段提交协议（2PC，Two Phase Commitment Protocol）中，资源管理器（RM, resource manager）需要提供“准备”、“提交”和“回滚” 3 个操作；而事务管理器（TM, transaction manager）分 2 阶段协调所有资源管理器，在第一阶段询问所有资源管理器“准备”是否成功，如果所有资源均“准备”成功则在第二阶段执行所有资源的“提交”操作，否则在第二阶段执行所有资源的“回滚”操作，保证所有资源的最终状态是一致的，要么全部提交要么全部回滚。\n资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现；TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题；TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中；事务管理器分 2 阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法；最终所有 TCC 服务要么全部都是提交的，要么全部都是回滚的。\n二、TCC 设计 用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上，进过蚂蚁金服多年的 TCC 应用，总结如下主要的TCC 设计和实现主要事项：\n1、业务操作分两阶段完成 接入 TCC 前，业务操作只需要一步就能完成，但是在接入 TCC 之后，需要考虑如何将其分成 2 阶段完成，把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户A的余额中有 100 元，需要扣除其中 30 元”；\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成 2 步完成：\n Try 操作：资源的检查和预留； 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交； 在扣款场景下，Confirm 阶段走的事情就是发生真正的扣款，把A账户中已经冻结的 30 元钱扣掉。\n Cancel 操作：预留资源的是否； 在扣款场景下，扣款取消，Cancel 操作执行的任务是释放 Try 操作冻结的 30 元钱，是 A 账户回到初始状态。\n2、并发控制 用户在实现 TCC 时，应当考虑并发性问题，将锁的粒度降到最低，以最大限度的提高分布式事务的并发性。\n以下还是以A账户扣款为例，“账户 A 上有 100 元，事务 T1 要扣除其中的 30 元，事务 T2 也要扣除 30 元，出现并发”。\n在一阶段 Try 操作中，分布式事务 T1 和分布式事务 T2 分别冻结资金的那一部分资金，相互之间无干扰；这样在分布式事务的二阶段，无论 T1 是提交还是回滚，都不会对 T2 产生影响，这样 T1 和 T2 在同一笔业务数据上并行执行。\n3、允许空回滚 如下图所示，事务协调器在调用 TCC 服务的一阶段 Try 操作时，可能会出现因为丢包而导致的网络超时，此时事务管理器会触发二阶段回滚，调用 TCC 服务的 Cancel 操作，而 Cancel 操作调用未出现超时。\nTCC 服务在未收到 Try 请求的情况下收到 Cancel 请求，这种场景被称为空回滚；空回滚在生产环境经常出现，用户在实现TCC服务时，应允许允许空回滚的执行，即收到空回滚时返回成功。\n4、防悬挂控制 如下图所示，事务协调器在调用 TCC 服务的一阶段 Try 操作时，可能会出现因网络拥堵而导致的超时，此时事务管理器会触发二阶段回滚，调用 TCC 服务的 Cancel 操作，Cancel 调用未超时；在此之后，拥堵在网络上的一阶段 Try 数据包被 TCC 服务收到，出现了二阶段 Cancel 请求比一阶段 Try 请求先执行的情况，此 TCC 服务在执行晚到的 Try 之后，将永远不会再收到二阶段的 Confirm 或者 Cancel ，造成 TCC 服务悬挂。\n用户在实现 TCC 服务时，要允许空回滚，但是要拒绝执行空回滚之后 Try 请求，要避免出现悬挂。\n5、幂等控制 无论是网络数据包重传，还是异常事务的补偿执行，都会导致 TCC 服务的 Try、Confirm 或者 Cancel 操作被重复执行；用户在实现 TCC 服务时，需要考虑幂等控制，即 Try、Confirm、Cancel 执行一次和执行多次的业务结果是一样的。\nRoadmap 当前已经发布到 0.4.0 版本，后续我们会发布 0.5 ~ 1.0 版本，继续对 AT、TCC 模式进行功能完善和和丰富，并解决服务端高可用问题，在 1.0 版本之后，本开源产品将达到生产环境使用的标准。\n","date":1553583600,"description":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。","dir":"blog/seata-tcc-theory-design-realization/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"45ef8a72beefcd26f4f62e7bdb34671c","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-tcc-theory-design-realization/","publishdate":"2019-03-26T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/seata-tcc-theory-design-realization/","summary":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。 Sample 地址：https://github.com/fescar-group/fescar","tags":["seata"],"title":"TCC 理论及设计实现指南介绍","type":"blog","url":"/sofastack.tech/blog/seata-tcc-theory-design-realization/","wordcount":1971},{"author":"蚂蚁金服团队","categories":"seata","content":" Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用，文末也提供了项目后续的 Roadmap，欢迎关注。\n前言：基于 TCC 模型的应用场景 TCC 分布式事务模型直接作用于服务层。不与具体的服务框架耦合，与底层 RPC 协议无关，与底层存储介质无关，可以灵活选择业务资源的锁定粒度，减少资源锁持有时间，可扩展性好，可以说是为独立部署的 SOA 服务而设计的。\n一、TCC 模型优势 对于 TCC 分布式事务模型，笔者认为其在业务场景应用上，有两方面的意义。\n1.1 跨服务的分布式事务 服务的拆分，也可以认为是资源的横向扩展，只不过方向不同而已。\n横向扩展可能沿着两个方向发展：\n 功能扩展，根据功能对数据进行分组，并将不同的功能组分布在多个不同的数据库上，这实际上就是 SOA 架构下的服务化。 数据分片，在功能组内部将数据拆分到多个数据库上，为横向扩展增加一个新的维度。 下图简要阐释了横向数据扩展策略：\n横向扩展的两种方法可以同时进行运用：用户信息（Users）、产品信息（Products）与交易信息（Trans）三个不同功能组可以存储在不同的数据库中。另外，每个功能组内根据其业务量可以再拆分到多个数据库中，各功能组可以相互独立地进行扩展。\n因此，TCC 的其中一个作用就是在按照功能横向扩展资源时，保证多资源访问的事务属性。\n1.2 两阶段拆分 TCC 另一个作用就是把两阶段拆分成了两个独立的阶段，通过资源业务锁定的方式进行关联。资源业务锁定方式的好处在于，既不会阻塞其他事务在第一阶段对于相同资源的继续使用，也不会影响本事务第二阶段的正确执行。\n传统模型的并发事务：\nTCC 模型的并发事务：\n可以发现 TCC 模型进一步减少了资源锁的持有时间。同时，从理论上来说，只要业务允许，事务的第二阶段什么时候执行都可以，反正资源已经业务锁定，不会有其他事务动用该事务锁定的资源。\n这对业务有什么好处呢？拿支付宝的担保交易场景来说，简化情况下，只需要涉及两个服务，交易服务和账务服务。交易作为主业务服务，账务作为从业务服务，提供 Try、Commit、Cancel 接口：\n Try 接口扣除用户可用资金，转移到预冻结资金。预冻结资金就是业务锁定方案，每个事务第二阶段只能使用本事务的预冻结资金，在第一阶段执行结束后，其他并发事务也可以继续处理用户的可用资金。 Commit 接口扣除预冻结资金，增加中间账户可用资金（担保交易不能立即把钱打给商户，需要有一个中间账户来暂存）。 假设只有一个中间账户的情况下，每次调用支付服务的 Commit 接口，都会锁定中间账户，中间账户存在热点性能问题。 但是，在担保交易场景中，七天以后才需要将资金从中间账户划拨给商户，中间账户并不需要对外展示。因此，在执行完支付服务的第一阶段后，就可以认为本次交易的支付环节已经完成，并向用户和商户返回支付成功的结果，并不需要马上执行支付服务二阶段的 Commit 接口，等到低锋期时，再慢慢消化，异步地执行。\n可能部分读者认为担保交易比较特殊，其实直付交易（直接把钱打到商户账户的交易模式，Commit 接口扣除预冻结资金以后，不是转移到中间账务，而是直接转移到商户账户）也可以这样使用，只要提前告知商户，高峰期交易资金不是实时到账，但保证在一定时间之内结算完成，商户应该也是可以理解的。\n这就是 TCC 分布式事务模型的二阶段异步化功能，从业务服务的第一阶段执行成功，主业务服务就可以提交完成，然后再由框架异步的执行各从业务服务的第二阶段。\n二、通用型 TCC 解决方案 通用型 TCC 解决方案就是最典型的 TCC 分布式事务模型实现，所有从业务服务都需要参与到主业务服务的决策当中。\n适用场景 由于从业务服务是同步调用，其结果会影响到主业务服务的决策，因此通用型 TCC 分布式事务解决方案适用于执行时间确定且较短的业务，比如互联网金融企业最核心的三个服务：交易、支付、账务：\n当用户发起一笔交易时，首先访问交易服务，创建交易订单；然后交易服务调用支付服务为该交易创建支付订单，执行收款动作，最后支付服务调用账务服务记录账户流水和记账。\n为了保证三个服务一起完成一笔交易，要么同时成功，要么同时失败，可以使用通用型 TCC 解决方案，将这三个服务放在一个分布式事务中，交易作为主业务服务，支付作为从业务服务，账务作为支付服务的嵌套从业务服务，由 TCC 模型保证事务的原子性。\n支付服务的 Try 接口创建支付订单，开启嵌套分布式事务，并调用账务服务的 Try 接口；账务服务在 Try 接口中冻结买家资金。一阶段调用完成后，交易完成，提交本地事务，由 TCC 框架完成分布式事务各从业务服务二阶段的调用。\n支付服务二阶段先调用账务服务的 Confirm 接口，扣除买家冻结资金；增加卖家可用资金。调用成功后，支付服务修改支付订单为完成状态，完成支付。\n当支付和账务服务二阶段都调用完成后，整个分布式事务结束。\n三、异步确保型 TCC 解决方案 异步确保型 TCC 解决方案的直接从业务服务是可靠消息服务，而真正的从业务服务则通过消息服务解耦，作为消息服务的消费端，异步地执行。\n可靠消息服务需要提供 Try，Confirm，Cancel 三个接口。Try 接口预发送，只负责持久化存储消息数据；Confirm 接口确认发送，这时才开始真正的投递消息；Cancel 接口取消发送，删除消息数据。\n消息服务的消息数据独立存储，独立伸缩，降低从业务服务与消息系统间的耦合，在消息服务可靠的前提下，实现分布式事务的最终一致性。\n此解决方案虽然增加了消息服务的维护成本，但由于消息服务代替从业务服务实现了 TCC 接口，从业务服务不需要任何改造，接入成本非常低。\n适用场景 由于从业务服务消费消息是一个异步的过程，执行时间不确定，可能会导致不一致时间窗口增加。因此，异步确保性 TCC 分布式事务解决方案只适用于对最终一致性时间敏感度较低的一些被动型业务（从业务服务的处理结果不影响主业务服务的决策，只被动的接收主业务服务的决策结果）。比如会员注册服务和邮件发送服务：\n当用户注册会员成功，需要给用户发送一封邮件，告诉用户注册成功，并提示用户激活该会员。但要注意两点：\n 如果用户注册成功，一定要给用户发送一封邮件； 如果用户注册失败，一定不能给用户发送邮件。 因此，这同样需要会员服务和邮件服务保证原子性，要么都执行，要么都不执行。不一样的是，邮件服务只是一种被动型的业务，并不影响用户是否能够注册成功，它只需要在用户注册成功以后发送邮件给用户即可，邮件服务不需要参与到会员服务的活动决策中。\n对于此种业务场景，可以使用异步确保型TCC分布式事务解决方案，如下：\n由可靠消息服务来解耦会员和邮件服务，会员服务与消息服务组成 TCC 事务模型，保证事务原子性。然后通过消息服务的可靠特性，确保消息一定能够被邮件服务消费，从而使得会员与邮件服务在同一个分布式事务中。同时，邮件服务也不会影响会员服务的执行过程，只在会员服务执行成功后被动接收发送邮件的请求。\n四、补偿型 TCC 解决方案 补偿型 TCC 解决方案与通用型 TCC 解决方案的结构相似，其从业务服务也需要参与到主 …","date":1553410800,"description":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。","dir":"blog/seata-tcc-applicable-models-scenarios/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa8436ce2760fafb880427799a763f32","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","publishdate":"2019-03-24T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","summary":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用，文末也提供了项目后续的 Roadmap，欢迎关注。 前言：基于 TCC 模型的应用场景 TCC 分布式事","tags":["seata"],"title":"TCC 适用模型与适用场景分析","type":"blog","url":"/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","wordcount":3912},{"author":"善逝","categories":"SOFAArk","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服在 SOFAStack 体系内研发了一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力\u0026amp;ndash;SOFAArk。本篇文章为 SOFAArk 0.6.0 的新特性介绍。 GitHub 地址：https://github.com/alipay/sofa-ark\n 简介 在大型软件开发过程中，通常会推荐底层功能插件化、业务功能模块化的开发模式，以其达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化开发方案，产品能力主要包括：\n 定义插件开发规范，提供 Maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin）， 适用于将底层组件插件化输出，例如 RPC、富客户端等； 定义模块开发规范，提供 Maven 打包工具，简单快速将应用（Spring Boot/SOFABoot/普通 Java 应用）打包成模块 (Ark Biz，以下简称 Biz)，适用于将业务组件模块化输出，提升业务能力复用； 定义类加载模型，运行时 Plugin、Biz 之间均相互隔离，运行时由不同的 ClassLoader 加载，有效避免相互之间的包冲突，降低 Plugin 和 Biz 对运行环境的要求； 定义标准的编程界面，包括服务、事件、扩展点等机制，方便 Plugin、Biz 交互和扩展； 定义业务模块 (Biz) 生命周期，支持多 Biz 合并部署。开发阶段将多个 Biz 打包成 Executable Ark Jar 包(以下简称 Ark 包)，或者运行时使用 API 或配置中心(Zookeeper)动态地管理 Biz 安装和卸载，满足多应用合并部署及动态升级的需求。 基于以上能力，SOFAArk 可以帮助解决多应用(模块)合并部署、动态升级、依赖包冲突等场景问题。\n场景 场景一：合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件。协调跨团队合作开发会遇到不少问题：比如各自技术栈不统一导致的依赖冲突、往同一个 Git 仓库提交代码常常导致 merge 冲突、组件功能相互依赖影响测试进度。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发和测试，运行时合并部署，那么将有助于提升开发效率及应用可扩展性。\nSOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互，如下：\nBiz 对应用类型没有限制，可以是 Spring Boot/SOFABoot/Java 普通应用类型，Biz 之间采用统一的编程界面-SOFA JVM服务进行交互。发布和引用服务也非常简单，使用 API 或者 Spring 注解/XML 方式：\n合并部署的形式，分为两种 \u0026amp;ndash; 静态合并部署和动态合并部署。\n静态合并部署 在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成 Ark 包时，会将引入的其他 Biz 包一并打入。通过 java -jar 启动 Ark 包时，则会根据优先级依次启动各 Biz，单个 Biz 使用独立的 BizClassLoader 加载，不需要考虑依赖包冲突问题，Biz 之间则通过 SOFA JVM 服务交互。\n动态合并部署 动态合并部署区别于静态合并部署最大的一点是，在运行时可以通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态合并部署的设计理念图如下：\n无论是静态抑或动态合并部署都有存在宿主应用 (master biz) 的概念，如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主 Biz 和其他 Biz 唯一不同在于，宿主 Biz 不允许被卸载。\n一般而言，宿主应用会作为流量入口的中台系统，具体的服务实现会放在不同的动态 Biz 中，供宿主应用调用。宿主应用可以使用 SOFAArk 提供的客户端 API 实现动态应用的部署和卸载。除了 API， SOFAArk 提供了 Config Plugin，用于对接配置中心（目前支持 Zookeeper），运行时接受动态配置；Config Plugin 会解析下发的配置，控制动态应用的部署和卸载。\n场景二：动态升级 SOFAArk 在蚂蚁内部也被用来解决动态升级的场景问题。有时候，因为业务迭代较快，应用依赖的某二方包需要频繁的变更，这将导致应用每次都因为升级二方包版本做变更发布，影响开发效率；而作为二方包的开发者，常常因为推动依赖方应用升级阻力较大，导致新特性无法按时上线，影响业务发展。\n为了加快创新业务的迭代速度，会将需要频繁变更的二方包打包成 Biz 包，供其他应用依赖。作为依赖方，不会直接在 Pom 文件（假设是使用 Maven 构建）定义 Biz 包版本，而是通过配置中心（例如 Zookeeper）下发配置。如此，当应用启动时，会拉取 Biz 版本配置信息，进而拉取正确版本的 Biz 包并启动。如此，当需要依赖方升级 Biz 版本时，只需要在配置中心重新推送配置即可。\n场景三：依赖隔离 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError, NoSuchMethodError 等。实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法：统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突。这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题。如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题。 OSGi 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGi 框架门槛较高，功能繁杂。为了解决包冲突问题，引入 OSGi 框架，有牛刀杀鸡之嫌，反而使工程变得更加复杂，不利于开发。\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如 …","date":1553065200,"description":"本篇文章为 SOFAArk 0.6.0 的新特性介绍。","dir":"blog/sofa-ark-0.6.0/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7a25cfa30d66586c83abafd947447de3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-0.6.0/","publishdate":"2019-03-20T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-ark-0.6.0/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 蚂蚁金服在 SOFAStack 体","tags":["SOFAArk"],"title":"蚂蚁金服 SOFAArk 0.6.0 新特性介绍 | 模块化开发容器","type":"blog","url":"/sofastack.tech/blog/sofa-ark-0.6.0/","wordcount":3490},{"author":"炎竹","categories":"SOFAActs","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服在 SOFAStack 体系内研发了基于模型驱动的自动化接口测试框架 SOFAACTS。 GitHub 地址：https://github.com/alipay/sofa-acts\n 背景 伴随着业务需求的爆发，蚂蚁金服金融级分布式架构质量测试活动变得复杂起来，表现在测试的业务场景复杂，诸如分布式事务处理流程场景、并发性、账户状态多样性、幂等性和兼容性等等。在原有的自动化测试框架下，测试流程编排极易出现测试数据冗余分散、可维护性差、人工编码成本高和测试验证点易遗漏的问题。\n如何解决上面的问题呢？\n蚂蚁金服在 SOFAStack 体系内研发了基于模型驱动的自动化接口测试框架 SOFAACTS。\nSOFAACTS 介绍 SOFAACTS 由 IDE 和测试引擎组成，下图为产品架构图：\n框架适配 TestNg+Spring 的测试上下文环境，以 YAML 为数据载体并在此上构建数据模型驱动，具有契合快速互联网发展和复杂分布式金融系统特点的优良特性：\n 模型驱动和标准执行引擎； 精细化校验和数据的自动回写； 具有灵活的可扩展性； 用例可视化维护。 1.模型驱动和标准化 在测试用例数据与测试代码分离的探索上，很多测试框架采用数据驱动的方式，但这也无法从容应对金融级的复杂业务场景。框架对用例数据进行了深度抽象，提出模型驱动理念，研发出基于模型的数据驱动和标准化执行引擎，实现了数据和代码的分离管理，同时对测试过程中的数据清理、数据准备、用例执行、结果校验阶段进行标准化，做到测试数据维护和测试代码的简洁优雅。用例执行时用户无需关注数据如何加载，结果和期望数据如何比对，只需要关注测试数据和执行结果。\n接下来，我们介绍如何使用 SOFAACTS 来高效率地完成一键生成数据模型生成和一键生成测试脚本。\n数据模型生成 首先进行数据模型的准备，以方便之后模版化地快速创建对象和表，按照如下方式来准备 DB 数据、接口请求参数和返回结果对象模型。\nDB 数据模型生成 任意测试代码中右击-\u0026amp;gt; SOFAACTS 功能-\u0026amp;gt;生成 DB 表结构模板； 选择生成的目标测试工程； 点击确认后选择并添加需要生成模型的表即可生成。 类对象模型生成 待构建模型的类定义的任意方法上右击-\u0026amp;gt; SOFAACTS 功能-\u0026amp;gt;模板生成，生成当前对象的模型； 生成完成后，我们可以在下图位置找到生成的数据对象模型； 按照上述步骤，这样我们就生成了接口对象模板。 现在，我们开始进行脚本一键生成：\n测试脚本生成 SOFAACTS IDE 提供测试脚本自动生成功能，无需手动编码。操作方式如下：\n 被测接口方法上点击，选择 SOFAACTS 功能\u0026amp;ndash;\u0026amp;gt;生成测试用例； 这时会弹出一个文本框，填写脚本生成的位置和编码格式，如下： 填写完成后，点击 OK 即可自动生成如下测试脚本，可以看出模型驱动生成的脚本精简而优雅。 原来数据驱动下的脚本是如下面图这样的，测试数据冗余分散，人工编码成本高维护性差。\n实践证明 SOFAACTS 用例的测试代码构建效率提高 80% ，测试数据精简到 1/case 数。\n2.精细化校验 在解决复杂业务场景下测试验证难、易遗漏等问题时，SOFAACTS 基于代码行为跟踪和分析理念，通过反射机制和日志解析实现结果数据的自动采集，以此做为场景用例校验的数据基线，并在持续集成时进行基线全量因子匹配来达到精细化验证。如下图：\n同时，为了提高自动采集后数据回填的效率，框架支持预校验数据的自动写入能力，进一步实现了数据的自动化精细校验。如下图：一键点击即可采集到校验数据基线，在蚂蚁内部实践中 ACTS 做到了结果校验效率提升至少 80%，场景验证 0 遗漏。\n3.灵活可扩展 框架为了应对各种特殊业务测试情况而不需要过多改动，设计上应用高内聚与低耦合原则，支持既可以复用框架底层代码又可以针对业务个性化情况做扩展的能力。整个框架提供了丰富的 API，测试执行过程每个方法、每个类以便测试执行过程的每个阶段（如下图）都能够在测试脚本里面被重新为其他方法或者被其他多态的子类替换，这样让框架变得更通用，既赋予了框架轻量性又增加了灵活性。\n自定义的 API 如下：\nAPI 的具体使用请详细学习产品使用手册。\n4.用例可视化维护 框架支持研发集成环境的一站式编辑，高效的用例脚本和数据维护，有效减少重复性的数据准备代码。如下图：\n总结 以上便是对 SOFAACTS 测试框架的基本介绍，还有诸多能力各位可以查阅我们详细的使用手册。\n目前，SOFAACTS 已经在蚂蚁金服大范围使用，分钟级用例编写 10 倍效能提升，累计用例个数 10w 以上，高频功能使用可达近 2000 次/日，并持续保持着旺盛的生命力。\n当前，代码已开源托管在 GitHub 上，欢迎关注，同时也欢迎业界爱好者共同创造更好的 SOFAACTS。\nGitHub 项目地址：https://github.com/alipay/sofa-acts\n相关链接 SOFAACTS ：https://github.com/alipay/sofa-acts API 产品使用手册：https://www.sofastack.tech/sofa-acts/docs/Usage-API SOFAACTS 详细使用手册：https://www.sofastack.tech/sofa-acts/docs/Home 招聘 蚂蚁金服金融核心测试技术团队持续寻找对测试自动化、智能风险管控等方向充满热情的小伙伴加入，有意者请联系 zhiqiang.li@antfin.com\n","date":1552546800,"description":"SOFAStack 体系，基于模型驱动的自动化接口测试框架 SOFAACTS。","dir":"blog/sofa-acts-automated-testing-framework/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b76c650b1a69560fe38c8e4f237f6207","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-acts-automated-testing-framework/","publishdate":"2019-03-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-acts-automated-testing-framework/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 蚂蚁金服在 SOFAStack 体","tags":["SOFAActs"],"title":"SOFAStack 开源自动化测试框架 SOFAACTS","type":"blog","url":"/sofastack.tech/blog/sofa-acts-automated-testing-framework/","wordcount":2096},{"author":"家纯","categories":"SOFAJRaft","content":" 什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 Raft 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。 SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\n 基础知识：分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 Paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 Paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等）。 Zab：被应用在 Zookeeper 中，业界使用广泛，但没有抽象成通用的 library。 Raft：以容易理解著称，业界也涌现出很多 Raft 实现，比如大名鼎鼎的 etcd, braft, tikv 等。 什么是 Raft？ Raft 是一种更易于理解的分布式共识算法，核心协议本质上还是师承 Paxos 的精髓，不同的是依靠 Raft 模块化的拆分以及更加简化的设计，Raft 协议相对更容易实现。\n模块化的拆分主要体现在：Raft 把一致性协议划分为 Leader 选举、MemberShip 变更、日志复制、Snapshot 等几个几乎完全解耦的模块。\n更加简化的设计则体现在：Raft 不允许类似 Paxos 中的乱序提交、简化系统中的角色状态（只有 Leader、Follower、Candidate 三种角色）、限制仅 Leader 可写入、使用随机化的超时时间来设计 Leader Election 等等。\n特点：Strong Leader 系统中必须存在且同一时刻只能有一个 Leader，只有 Leader 可以接受 Clients 发过来的请求； Leader 负责主动与所有 Followers 通信，负责将“提案”发送给所有 Followers，同时收集多数派的 Followers 应答； Leader 还需向所有 Followers 主动发送心跳维持领导地位(保持存在感)。 一句话总结 Strong Leader: \u0026amp;ldquo;你们不要 BB! 按我说的做，做完了向我汇报!\u0026amp;rdquo;。另外，身为 Leader 必须保持一直 BB(heartbeat) 的状态，否则就会有别人跳出来想要 BB 。\nRaft 中的基本概念 篇幅有限，这里只对 Raft 中的几个概念做一个简单介绍，详细请参考 Raft paper。\nRaft-node 的 3 种角色/状态 Follower：完全被动，不能发送任何请求，只接受并响应来自 Leader 和 Candidate 的 Message，每个节点启动后的初始状态一定是 Follower； Leader：处理所有来自客户端的请求，以及复制 Log 到所有 Followers； Candidate：用来竞选一个新 Leader （Candidate 由 Follower 触发超时而来）。 Message 的 3 种类型 RequestVote RPC：由 Candidate 发出，用于发送投票请求； AppendEntries (Heartbeat) RPC：由 Leader 发出，用于 Leader 向 Followers 复制日志条目，也会用作 Heartbeat （日志条目为空即为 Heartbeat）； InstallSnapshot RPC：由 Leader 发出，用于快照传输，虽然多数情况都是每个服务器独立创建快照，但是Leader 有时候必须发送快照给一些落后太多的 Follower，这通常发生在 Leader 已经丢弃了下一条要发给该Follower 的日志条目(Log Compaction 时清除掉了) 的情况下。 任期逻辑时钟 时间被划分为一个个任期 (term)，term id 按时间轴单调递增； 每一个任期的开始都是 Leader 选举，选举成功之后，Leader 在任期内管理整个集群，也就是 “选举 + 常规操作”； 每个任期最多一个 Leader，可能没有 Leader (spilt-vote 导致)。 本图出自《Raft: A Consensus Algorithm for Replicated Logs》\n什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 Raft 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\nSOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nSOFAJRaft 整体功能\u0026amp;amp;性能优化 功能支持 Leader election：Leader 选举，这个不多说，上面已介绍过 Raft 中的 Leader 机制。\n Log replication and recovery：日志复制和日志恢复。\n Log replication 就是要保证已经被 commit 的数据一定不会丢失，即一定要成功复制到多数派。 Log recovery 包含两个方面： Current term 日志恢复：主要针对一些 Follower 节点重启加入集群或者是新增 Follower 节点后如何追日志； Prev term 日志恢复：主要针对 Leader 切换前后的日志一致性。 Snapshot and log compaction：定时生成 snapshot，实现 log compaction 加速启动和恢复，以及 InstallSnapshot 给 Followers 拷贝数据，如下图：\n 本图出自《In Search of an Understandable Consensus Algorithm》\n Membership change：用于集群线上配置变更，比如增加节点、删除节点、替换节点等。\n Transfer leader：主动变更 leader，用于重启维护，leader 负载平衡等。\n Symmetric network partition tolerance：对称网络分区容忍性。\n 如上图 S1 为当前 leader，网络分区造成 S2 不断增加本地 term，为了避免网络恢复后 S2 …","date":1552374000,"description":"本文为 SOFAJRaft 的基础解析，欢迎阅读~","dir":"blog/sofa-jraft-production-level-algorithm-library/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a2e98969240f05af10554781f4ab81ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","publishdate":"2019-03-12T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","summary":"什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用","tags":["SOFAJRaft","SOFALab"],"title":"SOFAStack 开源 SOFAJRaft：生产级 Java Raft 算法库","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","wordcount":6481},{"author":"Linux 中国 老王","categories":"SOFAStack","content":" 我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\u0026amp;ndash; 蚂蚁金服总监杨冰\n引言 最近，我听到了一个消息，蚂蚁金服将会开源 SOFA最核心的两个组件——分布式事务框架和服务注册中心。\n熟悉中间件的朋友们都知道，这两个组件都是针对当前最火的微服务架构。其中，分布式事物框架是解决数据一致性问题的关键。服务注册中心则是服务治理的基础。在这两块开源后，SOFA 将成为一套真正完备的分布式解决方案。\n作为开源人士，我对此消息深感兴趣，因此联系到了蚂蚁金服中间件团队的杨冰总监，就此消息向他求证。机缘凑巧之下，杨冰花费了宝贵的时间，和我深入讲述了 SOFA 开源的思考，以及近期的规划。\n通过这次交谈，也让我看到了一个成功的商业公司是如何拥抱开源、并将开源作为其根本战略来撬动技术红利，支持其急速发展的业务需求的。\n以下是正文，我将它分享出来以飨读者。\n如今，开源已经成为主流，可以说，整个信息产业已经从过去的闭源模式转换为现今的开源模式。各种开源公司纷纷创新不同的开源模式，其中以 RedHat、Google、Facebook 等公司所取得的成绩最为耀眼。\n2018 年的时候，我曾经参与“开源社”主持的《2018 中国开源年度报告》的撰写工作，并建立了一个数学分析模型，以此来对中国的互联网公司的开源项目分析其活跃度和健康度。让我既感意外，也不意外的是，阿里系的开源项目占据了活跃度排行榜前五的第一、第二和第四；甚至在前五十个项目中，阿里系的开源项目占据了超过一半的份额！我不意外的是，业界一直对阿里在开源方面的动作和力度颇有感受；意外的是，这种力度还是超乎了我的想象。这其中包括阿里巴巴集团和蚂蚁金服等都贡献了相当可观的开源项目。\n因此，这次遇到杨冰时，我就开源方面和他深入聊了几句，想了解一下蚂蚁金服是如何思考开源和践行开源的，是如何将开源与公司的商业价值有机地结合起来的。\n缘何开源 作为一家商业公司，宣称自己开源，甚至也形式上开源一些代码，其实已经是很常见的事情了。但是，真正能将开源与公司的技术演进相融合，并能有效地助推公司业务发展的，却并不太多。这件事其实并没有那么简单——远非只是上传到 GitHub 那么简单。\n根据业界的经验，在公司的技术产品开源方面，要将现有场景的代码开源，至少需要在已经运行稳定、结构清晰的现有代码基础上多付出 30% 的技术投入，对代码进行梳理、完善和通用化，才能做到初步的代码开源；而进一步要将这些开源代码维护下去，乃至于和公司业务线上的产品代码保持同步发展，多付出的技术成本还远远不止这些。作为一个互联网技术老兵，我对此深以为然。\n那么，蚂蚁金服是如何说服公司决策层在尚未看到开源回报的前景下，同意付出这么多的额外代价来支持开源的呢？推动开源的力量是因何而来的？\n“首先，开源是个共赢的模式，对于蚂蚁金服来说，开源可以扩大技术服务场景，为支付、金融等更多的客户提供服务，提升合作伙伴的效率。”杨冰说，“虽然，蚂蚁金服已经有很多的业务场景，也在很多场景下取得了超大规模的实践经验，但是，依然存在没有覆盖到的金融服务场景。而将技术开源出来，可以供更多的客户应用到其自身的场景下——这些场景有效的补充了蚂蚁金服的技术应用面，也为更完善的技术框架奠定了基础。因此，我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。”\n“其次，对金融服务来说，监管和自主可控的要求更多，”杨冰接着谈到，“客户也希望可以对其所采用的技术有更多的掌控。”开源是一种可以使客户和上下游产业共同参与和发展的可行模式。\n“所以，其实并不是技术部门去说服公司决策层去开源，而是业务发展的自然选择，这也是一种合理的发展方向。”他总结道。这样的结果，其实是和当前流行的开源商业模式所暗合的。\n“另外，如你所说，确实在开源时，我们做了很大的改造。以可扩展化的方式来层层构建 SOFA 框架的能力，保证 SOFA 的内部版本和开源的版本采用的是同一个内核。在开源时，剥离了特定业务的逻辑，而保持了公司内部的业务线上的代码和开源代码的核心是一致的。这样，只要公司的业务在持续发展，开源的代码就会一直维护和演进下去。所以 SOFA 的内部版本就是在开源版本之上扩展了内部逻辑和历史版本的兼容逻辑。开源版本的核心逻辑，内外是一致的，并在蚂蚁金服的生产环境中被广泛使用，同时会随着蚂蚁金服自身业务诉求的驱动不断的演进。”杨冰补充道，“但这是值得的，在为开源代码做改进时，也是为公司自己的业务做改进，这是双赢且可持续发展的。”\n很多公司在初涉开源时，常常有疑虑，将核心技术开放出去，会不会导致竞争对手的技术提升，会不会造成更大的技术竞争压力？\n“事实上，我们在最初准备开源时，也有讨论过这个方面。技术要被更多人用、更多场景用，才会有发展。而开放的技术才能带来团队的发展，因为技术是动态发展的，作为开源的一方，事实上在技术上是相对领先的。开源和掌握是两码事，掌握和用好又是两码事，所以，因开源而带来的竞争，其实是助推整个开源体系的发展的，是良性的、有益的。”杨冰说，“而从社区和行业现状看，大家都在开放，封闭的技术体系会逐渐落后。只有开放才能求同存异，共同发展。”\n 花絮\n我问蚂蚁金服的朋友，在你们开源中有什么有趣的“段子”吗？可以讲来听听。\n我朋友过了几天后，给我发来了这样一段文字：\n“参与双十一的中间件团队的常态是什么呢？\n当晚，团队的常态大概就是喝着茶等零点高峰，高峰期过了之后，当然就是参与买买买啦。 我们很多的一些事情的初始想法都是来自于双十一当天的夜聊，似乎在经历了紧张的零点高峰之后，脑细胞特别活跃。\n对于基础设施团队来说，双十一算是一次大考的结束，考完成绩出来了，我们就想琢磨一些有挑战的事情，于是我们会天马行空地聊一聊对于下一年在技术上需要去做的事情。而在 2017 年的双十一当天，SOFA 的几个同学就围在一起聊了 SOFA 能不能开源？为什么要开源？开源和商业化之间的关系？开源后要做哪些事情等等，这个算是 SOFA 开源的第一次内部讨论。\n从这次内部讨论之后，经过了大约半年的准备时间，我们在 2018 年 4 月份正式宣布开源并一直在逐步开源的进程中。”\n他说，这就是他们憋了半天想出来的“段子”，哈哈哈，这群可爱的技术人啊。\n SOFA 的演进和开源之路 SOFA 中间件框架是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\nSOFA 开源全景图，涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的Nacos、Sentinel等，为用户提供更加广泛地选择。\nSOFA 作为一个演进了几年的框架，也一定程度上代表了蚂蚁金服的技术体系的演变，并且现在形成了开源核心、开放式（组件式）开源的模式。SOFA 从 2018 年开始开源，但是我比较好奇 SOFA 开源之前的发展旅程是怎样的。\n杨冰说，“最早的时候，在蚂蚁金服还没有从淘宝分拆出来时，公司内使用过一个 …","date":1552287600,"description":"我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。","dir":"blog/financial-technology-meet-open-source/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"620bf66a94dd1d8b872cb4cb90ca3028","permalink":"https://sofastack.github.io/sofastack.tech/blog/financial-technology-meet-open-source/","publishdate":"2019-03-11T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/financial-technology-meet-open-source/","summary":"我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\u0026ndas","tags":["SOFAStack"],"title":"蚂蚁金服总监杨冰：金融科技公司为什么要拥抱开源？ | 穿山甲专访","type":"blog","url":"/sofastack.tech/blog/financial-technology-meet-open-source/","wordcount":6192},{"author":"潘潘","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布 活动时间：3 月 24 日周日下午 13 点 活动地点：北京中关村创业大街 氪空间 活动形式：线下活动 活动视频回顾：https://tech.antfin.com/community/activities/382 活动介绍 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。 欢迎 Star 我：https://github.com/alipay\nSOFA Meetup#1 北京站-服务注册中心、分布式事务重磅发布 这次的 Meetup 是 SOFAStack 第一场线下活动，也是 SOFA 开源一周年的线下庆祝会。\n我们将带来重磅发布，继续补充 SOFAStack 的开源大图，届时除了 SOFA 团队的见面交流之外，也安排了周年的庆祝环节，期待与朋友们的见面。\n重磅发布：开源蚂蚁金服分布式事务 蚂蚁金服内部的分布式事务框架已经发展十多年，广泛用于解决各类复杂业务场景的数据一致性问题，同时经受大规模业务挑战，在高性能、高可用等方面也积累了丰富的实践经验。\n这次，将带来蚂蚁金服分布式事务十多年的技术总结分享，同时也会宣布开源版本。\n重磅发布：开源蚂蚁金服注册中心 SOFARegistry SOFARegistry 是蚂蚁金服开源的服务注册中心。\nSOFARegistry： https://github.com/alipay/sofa-registry\nSOFARegistry 最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。目前 SOFARegistry 不仅全面应用于蚂蚁金服的自有业务，还随着蚂蚁金融科技输出，助力广大合作伙伴，同时也兼容开源生态。SOFARegistry 最新一代内部版与商业版，均以开源版为基础内核，在其上开发内部特性插件。\n更多内容，到现场来看\n加入 SOFA 钉钉互动群 群号：23127468，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n议程 时间 环节 嘉宾介绍 13:00 - 13:30  签到 13:40 - 14:20  《SOFAStack 开源这一年》 蚂蚁金服技术总监 杨冰 14:20 - 15:00 《SOFARegistry \u0026amp;ndash; 蚂蚁金服高性能服务注册中心开源》 蚂蚁金服服务注册中心开源负责人 尚彧 15:00 - 15:20 庆祝一周年环节 15:20 - 16:00  《SOFAFescar \u0026amp;ndash; 蚂蚁金服分布式事务开源以及实践》 蚂蚁金服分布式事务开源负责人 绍辉 16:00 - 16:40 《SOFAJRaft \u0026amp;ndash; 蚂蚁金服基于 RAFT 一致性算法的生产级高性能 Java 实现》 蚂蚁金服 SOFAJRaft 核心成员 力鲲 16:40 - 17:00  互动交流 ","date":1552277400,"description":"SOFA Meetup#1 北京站，3 月 24 日周日下午 13 点，北京中关村创业大街氪空间。","dir":"activities/sofa-meetup-1/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dd713adb17a610bef8a0f6ed06cace55","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-1/","publishdate":"2019-03-11T12:10:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofa-meetup-1/","summary":"概要 活动主题：SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布 活动时间：3 月 24 日周日下午 13 点 活动地点：北京中关村创业大街 氪空间 活动形式：","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-1/","wordcount":1037},{"author":"SOFA 团队","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFA 文档: http://www.sofastack.tech/ SOFA: https://github.com/alipay\n 最新的 SOFARPC 5.5.1 已经发布啦，本文给大家介绍下 SOFARPC v5.5.x 系列主要提供的特性以及使用方式。\nSOFARPC 作为成熟的 RPC 框架，一直致力于给用户提供稳定可靠的 RPC 框架 以及最自主的选择权。SOFARPC 的插件扩展机制可以支持各类实现的可插拔实现。\nSOFARPC 5.5 主要给开发者们带来了服务发现的新选择：Nacos 的集成 与 服务容错对 Hystrix 的集成。\n服务注册 Nacos 新选择 Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。根据 Nacos 的 Roadmap，0.8.0 已具备生产使用的能力，截止笔者撰稿时间，Nacos 已发布 0.9.0，距离 1.0.0 越来越近了。\nSOFARPC 5.5.0 开始提供对 Nacos 的集成，以下介绍两种使用方式：\n1、SOFABoot 集成 Nacos SOFABoot 从 2.5.3 开始已集成 SOFARPC 对 Nacos 的配置支持，假如开发者本机已经根据 Nacos 快速开始安装并启动 Nacos Server。\n根据 RPC 的示例工程创建一个 SOFABoot 工程，SOFABoot 工程使用 2.5.3。\n$ git clone git@github.com:alipay/sofa-rpc-boot-projects.git $ git checkout 5.x 在 application.properties 中配置服务注册中心地址信息，就能够使用 Nacos 作为注册中心。\n$ vi sofa-boot-samples/src/main/resources/application.properties com.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 启动 RPC 服务端实例工程：\nrun com.alipay.sofa.rpc.samples.invoke.InvokeServerApplication 启动成功后即可在 Nacos 服务端看到服务注册信息：Nacos 服务列表 （注：如果用户自己部署了nacos 的服务端，可以通过这个地址访问）\n启动 RPC 客户端调用工程：\nrun com.alipay.sofa.rpc.samples.invoke.InvokeClientApplication 可以看到调用成功结果，分别代表同步、异步、回调调用成功：\nsync future callback client process:callback 2、SOFARPC 独立集成 Nacos SOFARPC 独立使用集成 Nacos 也很简单，只需要将注册中心地址设置为 Nacos 服务地址即可。\n引入 SOFARPC：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; API 方式发布服务：\n# 构造服务注册中心配置 RegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;nacos\u0026amp;quot;) .setSubscribe(true) .setAddress(\u0026amp;quot;127.0.0.1:8848\u0026amp;quot;) .setRegister(true); # 构造服务端口配置 ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setHost(\u0026amp;quot;0.0.0.0\u0026amp;quot;) .setPort(12200); # 构造服务发布者 ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRef(new HelloServiceImpl()) .setServer(serverConfig) .setRegister(true) .setRegistry(Lists.newArrayList(registryConfig)); providerConfig.export(); 即可发布服务至 Nacos Server。\n服务容错支持 Hystrix 在大规模的分布式系统中，一个完整的请求链路会跨越多个服务，其中每一个节点出现故障都将放大到全局，轻则造成执行逻辑崩溃，重则消耗掉所有资源拖垮整个系统。\nHystrix 是 Netflix 开源的容错组件，提供以下功能以解决该问题：\n 通过线程池或是信号量对资源进行隔离，避免依赖服务在故障时使用大量资源拖垮整个应用 使用熔断器模式（Circuit Breaker pattern）实现请求故障服务的快速失败（fail-fast），避免故障服务所造成的延时影响整体请求的延时 提供故障降级（Fallback）使用户可以编写优雅降级的策略，防止故障传递到上层 提供准实时的监控指标，使每一个依赖服务的请求结果和延时可观测 在 SOFARPC 中使用 Hystrix Hystrix 本身使用命令模式（Command pattern）实现了 API，我们在 SOFARPC 中对其进行了封装，只需要简单配置即可开启相关功能。\nHystrix 作为 SOFARPC 的可选模块默认不会进行加载，所以首先需要显式在项目中添加 Hystrix 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后通过开关选择开启全局的 Hystrix 支持，或是只对一部分 Consumer 开启：\n// 全局开启 RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // …","date":1551769200,"description":"最新的 SOFARPC 5.5.1 已经发布啦，本文给大家介绍下 SOFARPC v5.5.x 系列主要提供的特性以及使用方式。","dir":"blog/sofarpc-5.5.x-nacos-hystrix/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c712254801354ae1b1bd22cd39b80ec2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","publishdate":"2019-03-05T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFA 文档: http://www.sofastack.tech/ SOFA: https://github.com/alipay","tags":["SOFARPC"],"title":"SOFARPC 5.5.X 新版发布 | 集成 Nacos 与 Hystrix","type":"blog","url":"/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","wordcount":2473},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo） 活动时间：2 月 28 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 SOFA:Channel/，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\nSOFA:Channel/ 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n本期 SOFAChannel 为 SOFARPC 专场，分为上下两篇，将采用内容分享与 Demo 实际操作结合的形式进行。\n本期为上篇，下篇将在 2 月 28 日开展，记得关注哟~\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 时间：2019-02-21 19:00-20:00 《SOFARPC 性能优化（上）—— 详解优化设计点》 蚂蚁金服 SOFA 团队 碧远 在业务规模大并发极高的情况下，RPC 对性能的追求就变得极为重要，任何一点小的优化都会累积提高业务整体性能。 本期手把手带你解读： 自定义通信协议使用有哪些注意细节？ SOFARPC 如何进行连接保持？ 在 IO 线程池中批量解包带来的性能提升有哪些？\n嘉宾 蚂蚁金服 SOFA 团队 碧远\n","date":1551349200,"description":"本次为下半场，2 月 28 日晚 7 点，线上直播。","dir":"activities/sofa-channel-3/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"202f32cfe0c8a1c3aacbf435389a956f","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-3/","publishdate":"2019-02-28T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-3/","summary":"概要 活动主题：SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo） 活动时间：2 月 28 日周四晚 7 点 活动形","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo）","type":"activities","url":"/sofastack.tech/activities/sofa-channel-3/","wordcount":477},{"author":"碧远","categories":"SOFARPC","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第三期，SOFARPC 性能优化（下），进一步分享 SOFARPC 在性能上做的一些优化。 本期你将收获：\n 如何控制序列化和反序列化的时机； 如何通过线程池隔离，避免部分接口对整体性能的影响； 如何进行客户端权重调节，优化启动期和故障时的性能； 服务端 Server Fail Fast 支持，减少无效操作； 在 Netty 内存操作中，如何优化内存使用。 欢迎加入直播互动钉钉群：23127468，不错过每场直播。\n 大家好，今天是 SOFAChannel 第三期，欢迎大家观看。\n我是来自蚂蚁金服中间件的雷志远，花名碧远，目前负责 SOFARPC 框架的相关工作。在上一期直播中，给大家介绍了 SOFARPC 性能优化方面的关于自定义协议、Netty 参数优化、动态代理等的优化。\n 往期的直播回顾，可以在文末获取。\n本期互动中奖名单： @司马懿 @邓从宝 @雾渊，请文章下方回复进行礼品领取\n 今天我们会从序列化控制、内存操作优化、线程池隔离等方面来介绍剩余的部分。\n序列化优化 上次介绍了序列化方式的选择，这次主要介绍序列化和反序列化的时机、处理的位置以及这样的好处，如避免占用 IO 线程，影响 IO 性能等。\n上一节，我们介绍的 BOLT 协议的设计，回顾一下：\n可以看到有这三个地方不是通过原生类型直接写的：ClassName，Header，Content 。其余的，例如 RequestId 是直接写的，或者说跟具体请求对象无关的。所以在选择序列化和反序列化时机的时候，我们根据自己的需求，也精确的控制了协议以上三个部分的时机。\n对于序列化 serializeClazz 是最简单的：\nbyte[] clz = this.requestClass.getBytes(Configs.DEFAULT_CHARSET); 直接将字符串转换成 Byte 数组即可，跟具体的任何序列化方式，比如跟采用 Hessian 还是 Pb 都是无关的。\nserializeHeader 则是序列化 HeaderMap。这时候因为有了前面的 requestClass，就可以根据这个名字拿到SOFARPC 层或者用户自己注册的序列化器。然后进行序列化 Header，这个对应 SOFARPC 框架中的 SofaRpcSerialization 类。在这个类里，我们可以自由使用本次传输的对象，将一些必要信息提取到Header 中，并进行对应的编码。这里也不跟具体的序列化方式有关，是一个简单 Map 的序列化，写 key、写 value、写分隔符。有兴趣的同学可以直接看源码。\n源码链接：https://github.com/alipay/sofa-bolt/blob/531d1c0d872553d92fc55775565b3f7be8661afa/src/main/java/com/alipay/remoting/rpc/protocol/RpcRequestCommand.java#L66\nserializeContent 序列化业务对象的信息，这里 RPC 框架会根据本次用户配置的信息决定如何操作序列化对象，是调用 Hessian 还是调用 Pb 来序列化。\n至此，完成了序列化过程。可以看到，这些操作实际上都是在业务发起的线程里面的，在请求发送阶段，也就是在调用 Netty 的写接口之前，跟 IO 线程池还没什么关系，所以都会在业务线程里先做好序列化。\n对于反序列化 介绍完序列化，反序列化的时机就有一些差异，需要重点考虑。在服务端的请求接收阶段，我们有 IO 线程、业务线程两种线程池。为了最大程度的配合业务特性、保证整体吞吐，SOFABolt 设计了精细的开关来控制反序列化时机。\n具体选择逻辑如下：\n体现在代码的这个类中。\ncom.alipay.remoting.rpc.protocol.RpcRequestProcessor#process 从上图可以看到 反序列化 大致分成以下三种情况，适用于不同的场景。\n IO 线程池动作 业务线程池 使用场景 反序列化 ClassName 反序列化 Header 和 Content 处理业务 一般 RPC 默认场景。IO 线程池识别出来当前是哪个类，调用用户注册的对应处理器 反序列化 ClassName 和 Header 仅反序列化 Content 和业务处理 希望根据 Header 中的信息，选择线程池，而不是直接注册的线程池 一次性反序列化 ClassName、Header 和 Content，并直接处理 没有逻辑 IO 密集型的业务 线程池隔离 经过前面的介绍，可以了解到，由于业务逻辑通常情况下在 SOFARPC 设置的一个默认线程池里面处理，这个线程池是公用的。也就是说， 对于一个应用，当他作为服务端时，所有的调用请求都会在这个线程池中处理。\n举个例子：如果应用 A 对外提供两个接口，S1 和 S2，由于 S2 接口的性能不足，可能是下游系统的拖累，会导致这个默认线程池一直被占用，无法空闲出来被其他请求使用。这会导致 S1 的处理能力受到影响，对外报错，线程池已满，导致整个业务链路不稳定，有时候 S1 的重要性可能比 S2 更高。\n因此，基于上面的设计，SOFARPC 框架允许在序列化的时候，根据用户对当前接口的线程池配置将接口和服务信息放到 Header 中，反序列化的时候，根据这个 Header 信息选择到用户自定义的线程池。这样，用户可以针对不同的服务接口配置不同的业务线程池，可以避免部分接口对整个性能的影响。在系统接口较多的时候，可以有效的提高整体的性能。\n内存操作优化 介绍完线程池隔离之后，我们介绍一下 Netty 内存操作的一些注意事项。在 Netty 内存操作中，如何尽量少的使用内存和避免垃圾回收，来优化性能。先看一些基础概念。\n内存基础 在 JVM 中内存可分为两大块，一个是堆内存，一个是直接内存。\n堆内存是 JVM 所管理的内存。所有的对象实例都要在堆上分配，垃圾收集器可以在堆上回收垃圾，有不同的运行条件和回收区域。\nJVM 使用 Native 函数在堆外分配内存。为什么要在堆外分配内存？主要因为在堆上的话， IO 操作会涉及到频繁的内存分配和销毁，这会导致 GC 频繁，对性能会有比较大的影响。\n注意：直接分配本身也并不见得性能有多好，所以还要有池的概念，减少频繁的分配。\n因此 JVM 中的直接内存，存在堆内存中的其实就是 DirectByteBuffer 类，它本身其实很小，真的内存是在堆外，通过 JVM 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。直接内存不会受到 Java 堆的限制，只受本机内存影响。当然可以设置最大大小。也并不是 Direct 就完全跟 Heap 没什么关系了，因为堆中的这个对象持有了堆外的地址，只有这个对象被回收了，直接内存才能释放。\n其中 DirectByteBuffer 经过几次 young gc 之后，会进入老年代。当老年代满了之后，会触发 Full GC。\n因为本身很小， …","date":1551337200,"description":"本文根据 SOFAChannel#3 直播分享整理，进一步分享 SOFARPC 在性能上做的一些优化。","dir":"blog/sofa-channel-3-retrospect/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7a816fa5f942ce857c10ebb1c416482d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-3-retrospect/","publishdate":"2019-02-28T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-channel-3-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第三期，SOFARPC 性能优化（下），进一步分享 SOFARPC 在性能上做的一些优化。 本期你","tags":["SOFARPC","SOFAChannel"],"title":"SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-3-retrospect/","wordcount":5775},{"author":"心贵","categories":"Kubernetes","content":" 此文章适合没有任何 Kubernetes/容器/Docker 经验的同学 — 在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。此文章阅读耗时大概 15 分钟。\n 蚂蚁金服资源调度组致力于将 Kubernetes 落地到世界上最有价值的金融科技独角兽公司，欢迎联系作者微信： answer1991chen 咨询招聘事宜。\n文章 Markdown 源码位于 https://github.com/answer1991/articles/blob/master/Kubernetes-is-the-next-generation-os.md ，遵从 Apache License 2.0 开源协议。\n导言 此文章着重介绍如何在入门阶段使用 Kubernetes，以及要面向 Kubernetes 编程带来的优势，不会介绍复杂的 Kubernetes 架构、实现。因此此文章适合没有任何 Kubernetes/容器/Docker 经验的同学，对 Kubernetes 有了解的同学也可以从此文章里面获取一些灵感，可以更加酷炫的玩转 Kubernetes。\n希望在阅读完此文章之后，你可以从 “我需要一个 Linux VM 做开发、测试和部署”，变成 “我需要一个 Kubernetes 做开发、测试和部署”。\nKubernetes 是下一代操作系统 Kubernetes 是这几年非常热门的一个词汇，大概所有的软件工程师都已经听说过这个词。\n那么 Kubernetes 到底是什么呢？可能 Google 会告诉你很多，但是我想告诉你的是：Kubernetes 是下一代操作系统；一个 Kubernetes 集群是一个资源无限大(可扩容)的虚拟机。而且，Kubernetes 的接口是是声明式的，是天然面向分布式系统而设计的（下面会详细介绍）。\n说到这里，大家估计立刻就有疑问了。我想大概是这些：\nQ: 那么，Linux、Windows 要被淘汰了？\nA: 不会被淘汰，只是 Linux、Windows 是一个底层的单机操作系统。而我们这些普通的应用软件工程师将来都不会跟Linux 打交道了，都会使用 Kubernetes 这个更上层、同时功能也更强大的操作系统。\nQ: 那么，我不学 Kubernetes 可以吗？\nA: 不行！在未来不久的某一天，也许云厂商只卖 Kubernetes “虚拟机”了：阿里云不单独卖 ecs 了，亚马逊AWS，微软云，Google 云等各种云厂商都不卖 Linux 虚拟机了。如果你想买单机版的 Linux 虚拟机，他们都会一脸惊讶的问你，你买那么底层的、功能那么薄弱的计算机干什么？就像你现在从云厂商那里买不到一个还没有安装 Linux 的虚拟机一样。以后，云厂商交付的 “虚拟机” 必定是 “集群级别的虚拟机” ，而 “集群级别的虚拟机” 的操作系统就是 Kubernetes。\n在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。\nQ: 那这样的话，我买不到 Linux 虚拟机，我连学习 Linux 的机会都没有了？\nA: 当然不是，有了 Kubernetes，你可以在 1秒内自己搞一个任何 Linux 发行版本的 “单机虚拟机” 出来。\nQ: Kubernetes 真的是一个操作系统？ Show me\u0026amp;hellip;.\nA:\n 功能/名词 单机 Linux Kubernetes 说明 Shell, CMD sh, bash kubectl kubectl 是 Kubernetes 的 shell 工具，有了 kubectl 你就可以连接并管理 Kubernetes 这个超级虚拟机了。 用户，登录 Linux User, Group, ssh 登录 kubeconfig 文件类似 Linux ssh 的 .key 文件，用户使用 kubeconfig 访问 Kubernetes 就自带了用户信息。Kubernetes 能根据用户限制权限，也能限制用户能使用的资源。kubectl 使用 kubeconfig 访问 Kubernetes 就好比使用 .ssh key 访问 Linux Kubernetes 集群管理员(或者自动化的申请系统)为用户颁发 kubeconfig 文件。 进程 进程 Pod Pod 就是 Kubernetes 这个 “超级虚拟机” 的进程。 管理进程 ps, kill kubectl get po, kubectl delete pod 发布、升级、管理 “进程”(或者说应用) 配置管理 登录各个 Linux VM，替换机器上的文件。 kubectl apply -f ./cm.yaml 使用 ConfigMap 管理应用的配置文件，一次提交，进程的每个实例自动生效新的配置。由于篇幅管理，使用 ConfigMap 配置应用（“进程”）启动参数不在此文章里面举例。 发布、管理、升级应用 在 Linux 上面发布一个应用，需要一顿疯狂的操作：先阅读如何发布、参数有什么、下载二进制包、搞定一些配置文件，然后运行应用。 kubectl apply -f ./my-app.yaml my-app.yaml 可能是应用提供商提供的、面向 Kubernetes 发布应用的“菜单”文件(为什么叫“菜单”我后面会介绍)。只要提交这个“菜单”，应用就部署好了。Kubernetes 让一切简单，而且，它是分布式，是天然容灾的。只要向 Kubernetes 提交 Deployment 这样的“资源”即可，下文有介绍。 限制应用资源 一顿疯狂的操作，把应用进程的 Cgroup 限制好。 发布应用时已经做了 Kubernetes 让一切简单。 分布式应用发布 在各个 Linux 虚拟机上面发布好应用，然后把他们组网。 发布应用时已经做了 还是那句话，Kubernetes 让一切简单。 分布式应用容灾 搞个监控，监控我们各个 Linux 虚拟机上面的应用是不是不健康了。不健康了的话，我们起床，来一次“一顿操作猛如虎”的故障恢复操作。 / 天然容灾，安心睡你的觉。 数据持久化，故障时数据迁移 “一顿操作猛如虎” 用 PV（持久化存储卷），容灾把应用的一个应用实例从 “节点一” 切换到了 “节点二”，都不用做任何数据迁移。新的应用实例起来就能使用老数据。 还是那句话，Kubernetes 让一切简单。我都不用关心这个事情。（由于篇幅管理，下文的例子中也不会涉及 PV 的例子） “一顿操作猛如虎” 听起来很酷，但是你在做一些没必要的事情，同时你做了这些事情并不讨好你的老板，可能在因为你的失误操作引起更大的故障和问题。\n面向 Kubernetes 做最简单的操作，达到最佳的效果，才是更酷的事情。\nA: 行了行了，别说那么多了，我还是需要一个 Linux VM。\nQ: 好的，我给您一个 Kubernetes，然后给你一个 基础 OS Pod “菜单”文件，然后您自己就可以创建任何一个 Linux 发行版、任何一个 Linux 版本的的 Linux VM …","date":1551078000,"description":"希望在阅读完此文章之后，你可以从 “我需要一个 Linux VM 做开发、测试和部署”，变成 “我需要一个 Kubernetes 做开发、测试和部署”。","dir":"blog/kubernetes-the-next-gen-os/","fuzzywordcount":8600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"09e6dbd10bffdeea13865fc45e3b3ee5","permalink":"https://sofastack.github.io/sofastack.tech/blog/kubernetes-the-next-gen-os/","publishdate":"2019-02-25T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/kubernetes-the-next-gen-os/","summary":"此文章适合没有任何 Kubernetes/容器/Docker 经验的同学 — 在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。","tags":["Kubernetes"],"title":"Kubernetes 是下一代操作系统 | 面向 Kubernetes 编程","type":"blog","url":"/sofastack.tech/blog/kubernetes-the-next-gen-os/","wordcount":8595},{"author":"碧远","categories":"SOFARPC","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第二期，主要分享 SOFARPC 在性能上做的一些优化，这个系列会分成上下两部分进行分享，今天是 SOFARPC 性能优化（上），也会对本次分享中的一些结论，提供部分代码 Demo，供大家了解验证。 欢迎加入直播互动钉钉群：23127468，不错过我们每场直播。\n 大家好，今天是我们 SOFAChannel 第二期。欢迎大家观看。\n我是来自蚂蚁金服中间件的雷志远，花名碧远，目前在负责 SOFARPC 框架相关工作。\n去年的时候，我们和外部的爱好者们一起，做了一个基于 SOFARPC 的源码解析系列，我同事已经发到群里了，大家可以保存，直播之后查看。\nSOFARPC 源码解析系列：（点击【剖析 | SOFARPC 框架】即可查看）\nhttps://www.sofastack.tech/blog/ 今年，基于源码解析的基础，我们来多讲讲实践，如何应用到大家的业务，来帮助大家解决实际问题。在直播过程中有相关的问题想提问，可以在钉钉群互动。\n前言 在上一期中，余淮分享了《从蚂蚁金服微服务实践谈起》。介绍了蚂蚁微服务的起源，以及之后服务化，单元化的情况。同时介绍了 SOFAStack 目前开源的情况。最后也分享了一下整个微服务中 SOFARPC 的设计与实现。\n本期，我们主要分享 SOFARPC 在性能上做的一些优化。这个系列会分成上下两部分进行分享，今天是 SOFARPC 性能优化（上），也会对本次分享中的一些结论，提供部分代码 Demo，供大家了解验证。\n我们先简要介绍一下 SOFARPC 的框架分层。这个在上次的分享中已经进行了介绍。\n下层是网络传输层，依次是协议，序列化，服务发现和 Filter 等。\nTransport 主要负责数据传输，可以是 Http2Transport，也可以是 BoltTransport，还有可能是其他。\nProtocol 层是协议，是 Rest 还是 Bolt ，或者是 Dubbo 。\nSerialization 是序列化，对于每种协议，可以是用不同的序列化方式，比如 hessian，pb，json 等。\nFilter 是通用的过滤器层，主要是为了留出一些扩展，完成一些其他扩展功能，比如 Tracer 的埋点等。\nRouter 是路由层，主要是做寻址，这里可能是 Zk，也可能是 LVS，也可能是直连。Cluster 是客户端集群方式的表示。\n自定义通讯协议使用 首先我想介绍一下自定义通讯协议。\n在说明自定义通讯协议之前，我先简单介绍一下通讯协议。在TCP之上，RPC框架通常还需要将请求和响应数据进行一定的封装，组装成 Packet，然后发送出去。这样，服务端收到之后，才能正确识别整个 TCP 发过来的字节流中，哪一部分是我们可以进行处理的一个完整单位。反之，客户端收到服务端的TCP 数据流也是如此。\n有了上面的共识之后，我们要回答下面两个问题：\n 为什么要自定义，不使用 Http2/Dubbo/Rest/Grpc？ 自定义之后，带来了什么好处呢？ Http2 虽然更为通用，但是一方面，出现较晚，迁移转换成本高，并且通用则意味着传输的辅助数据会变多，会有一些额外的信息需要传递或者判断。对于序列化反序列化的控制上，也不是很好扩展操作。\n而 Dubbo，协议简单强大。但是一些元信息需要解析，Header 中传输的数据太少，很多都需要依赖 body 中的数据反序列化完成后才能使用，头部的信息太少。\n而使用了自研的协议之后，Header 中可自定义传输更多的元信息，序列化方式，Server Fail Fast，服务端线程隔离等也都成为可能。甚至蚂蚁在 ServiceMesh 的场景下，Mesh 本身也能利用 Bolt 的协议，进行部分数据的读取，而不依赖具体的序列化实现。\n经过我们的实践，大致来看，目前给我们带来的好处主要有以下的能力：\n Server Fast 的支持 Header 和 Body 的分开序列化 Crc 校验的支持 版本的支持，预防未来可能出现的更好的设计方案 多种序列化方式的支持 安全认证，Mesh 路由 如果你要自己设计一个通讯协议。可以考虑使用 BOLT 协议，或者参考进行更好的设计和优化。\n关于 SOFABolt 相关的源码解析，也可以通过这个系列来了解。\nSOFABolt 源码解析系列：点击【剖析 | SOFABOLT 框架】即可查看） https://www.sofastack.tech/blog Netty 性能参数优化 在介绍了自定义通讯协议之后，也就是确定好了怎么封包解包之后，还需要确定传输层的开发。一个 RPC 框架从现在的情况来看，一般不太可能完全基于 JAVA 的 NIO 或者其他 IO 进行直接的开发，主要是一些 NIO 原生的问题和使用难度，而成熟的，目前可选的不多。基本上，大家都会基于 Netty 进行开发，HSF/Dubbo/Motan 等都是这样。\n直接使用是比较简单的。在 Netty 的 Bootstrap 的设置中，有一些可选的优化项，有必要跟大家分享一下。\n1. SO_REUSEPORT/SO_REUSEADDR - 端口复用(允许多个 socket 监听同一个IP+端口)\nSO_REUSEPORT 支持多个进程或者线程绑定到同一端口，提高服务器的接收链接的并发能力，由内核层面实现对端口数据的分发的负载均衡，在服务器 socket 上没有了锁的竞争。\n同时 SO_REUSEADDR也要打开，这样针对 time-wait 链接 ，可以确保 server 重启成功。在一些服务端启动很快的情况下，可以防止启动失败。\n2. TCP_FASTOPEN - 3次握手时也用来交换数据\n三次握手的过程中，当用户首次访问服务端时，发送 syn 包，server 根据客户端 IP 生成 cookie ，并与 syn+ack 一同发回客户端；客户端再次访问服务端时，在 syn 包携带 TCP cookie；如果服务端校验合法，则在用户回复 ack 前就可以直接发送数据；否则按照正常三次握手进行。也就是说，如果客户端中途断开，再建联的时候，会同时发送数据，会有一定的性能提升。\nTFO 提高性能的关键是省去了热请求的三次握手，这在小对象传输较多的移动应用场景中，能够极大提升性能。\nNetty 中仅在 Epoll 的时候可用 Linux特性，不能在 Mac/Windows 上使用，SOFARPC 未开启。\n3. TCP_NODELAY-关闭 (纳格) Nagle 算法，再小的包也发送，而不是等待\nTCP/IP 协议中针对 TCP 默认开启了 Nagle 算法。Nagle 算法通过减少需要传输的数据包个数，来优化网络。但是现在的环境下，网络带宽足够，需要进行关闭。这样，对于传输数据量小的场景，能很好的提高性能，不至于出现数据包等待。\n4. SO_KEEPALIVE –开启 TCP 层面的 Keep Alive 能力\n这个不多说，开启一下 TCP 层面的 Keep Alive 的能力。\n5. WRITE_BUFFER_WATER_MARK …","date":1551078000,"description":"本文根据 SOFAChannel#2 直播分享整理，主要分享 SOFARPC 在性能上做的一些优化。","dir":"blog/sofa-channel-2-retrospect/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6751c882f7879a7dd9c9f49823410ffc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-2-retrospect/","publishdate":"2019-02-25T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-2-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第二期，主要分享 SOFARPC 在性能上做的一些优化，这个系列会分成上下两部分进行分享，今天","tags":["SOFARPC","SOFAChannel"],"title":"SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-2-retrospect/","wordcount":5077},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 活动时间：2 月 21 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 SOFA:Channel/，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\nSOFA:Channel/ 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n本期 SOFAChannel 为 SOFARPC 专场，分为上下两篇，将采用内容分享与 Demo 实际操作结合的形式进行。\n本期为上篇，下篇将在 2 月 28 日开展，记得关注哟~\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 时间：2019-02-21 19:00-20:00 《SOFARPC 性能优化（上）—— 详解优化设计点》 蚂蚁金服 SOFA 团队 碧远 在业务规模大并发极高的情况下，RPC 对性能的追求就变得极为重要，任何一点小的优化都会累积提高业务整体性能。 本期手把手带你解读： 自定义通信协议使用有哪些注意细节？ SOFARPC 如何进行连接保持？ 在 IO 线程池中批量解包带来的性能提升有哪些？\n嘉宾 蚂蚁金服 SOFA 团队 碧远\n","date":1550744400,"description":"本次为上半场，2 月 21 日晚 7 点，线上直播。","dir":"activities/sofa-channel-2/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3140990819c0601c041bf5091405220b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-2/","publishdate":"2019-02-21T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-2/","summary":"概要 活动主题：SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 活动时间：2 月 21 日周四晚 7 点 活动形式：线上直播 直播视","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点","type":"activities","url":"/sofastack.tech/activities/sofa-channel-2/","wordcount":468},{"author":"卫恒","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n本文为《剖析 | SOFATracer 框架》第一篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\n 0、前言 在单体应用时代，我们不需要花费时间去关心调用链路这个东西。但是链路跟踪不仅仅是在分布式场景下才会有，即使是单体应用，同样也会存在调用链路。例如，我们把应用中的每个服务接口作为一个链路节点，那么从请求进来到返回响应，把这个过程中多历经的所有的方法接口串联起来，就能组成一条完整的链路，如下图所示：\n对于单体应用而言，如果访问一个资源没有成功，那么我们可以很快的锁定是哪一台机器，然后通过查询这台机器上的日志就能定位问题。\n但是在微服务体系架构下，这种方式会显得非常无力。对于一个稍具规模的应用来说，一次请求可能会跨越相当多的服务节点，在这种情况下，如果一个请求没有得到成功的响应，就不能确定到底是哪个节点出了问题。\n因此在面对这种复杂的大规模分布式集群来实现的服务体系来说，就需要一些可以帮助理解各个应用的线上调用行为、并可以分析远程调用的组件。\n基于上述背景，蚂蚁金服开源了基于 OpenTracing 规范实现的 SOFATracer 分布式链路跟踪组件，为实施大规模服务化体系架构场景下提供了链路跟踪的解决方案。\n在介绍 SOFATracer 之前，先来了解一下 Opentracing 规范。\n1、Opentracing 简介 首先来解释下 OpenTracing 是什么OpenTracing 致力于为分布式跟踪创建更标准化的API和工具，它由完整的API规范、实现该规范的框架、库以及项目文档组成。\nOpenTracing 提供了一套平台无关、厂商无关的 API，这样不同的组织或者开发人员就能够更加方便的添加或更换追踪系统的实现。 OpenTracing API 中的一些概念和术语，在不同的语言环境下都是共享的。\n1.1、数据模型 Opentracing 规范中，一条 trace 链路是由多个与之关联的 span 组成，一条链路整体可以看做是一张有向无环图，各个span之间的边缘关系被称之为“References”。下面是官方提供的示例：\n如果已时间轴维度来看的话，也可以表现为下面的形式(官方示例)：\n root span : 当前链路中的第一个 span ChildOf 和 FollowFrom 是目前被定义的两种 References 类型 ChildOf : 父级 span某种程度上取决于子span （子span的结果可能会对父span产生影响） FollowFrom : 父 Span不以任何方式依赖子 Span 但是为了简化 span 之间的这种依赖关系，在具体实现时通常会将具有嵌套关系的作为 ChildOf，平行执行的作为FollowFrom，比如：\na、ChildOf 示例\n在 methodA 中调用了 method B :\nmethodA(){ // spanA start methodB(); } // spanA finish methodB(){ // spanB start } // spanB finish 产生的 span在时间维度上展现的视角如下：\n这种关系一般会 表示为 SpanB ChildOf SpanA 。\nb、FollowFrom 示例\nmethod 方法中，methodA执行之后 methodB 执行 :\nmethod(){ methodA(); methodB(); } 产生的 span在时间维度上展现的视角如下：\n这种关系一般会 表示为 SpanB FollowFrom SpanA 。\n1.2、API Opentracing API 是对分布式链路中涉及到的一些列操作的高度抽象集合。Opentracing 中将所有核心的组件都声明为接口，例如 Tracer、Span、SpanContext、Format（高版本中还包括 Scope 和 ScopeManager）等。SOFATracer 使用的版本是 0.22.0 ，主要是对 Tracer、Span、SpanContext 三个概念模型的实现。下面就针对这三个组件结合 SOFATracer 来分析。\n1.3、SOFATracer 标准实现 下图为 SOFATracer 中对于这三个核心接口实现的类图结构：\n 由于篇幅原因，下面的介绍过程中一些点不会展开说明，有兴趣的同学可以自行官网查看完整的 OpenTracing-api 规范 （https://opentracing.io/specification/）。\n a、Tracer \u0026amp;amp; SofaTracer\nTracer 是一个简单、广义的接口，它的作用就是构建 span 和传输 span 。核心接口列表如下：\n 接口 描述 SpanBuilder buildSpan(String operationName) 根据指定的operationName构建一个新的span void inject(SpanContext spanContext, Format format, C carrier); 将 spanContext 以 format 的格式注入到 carrier 中 SpanContext extract(Format format, C carrier); 以 format 的格式从carrier中解析出 SpanContext SofaTracer 实现了 Tracer 接口，并扩展了采样、数据上报等能力。\nb、Span \u0026amp;amp; SofaTracerSpan\nSpan 是一个跨度单元，在实际的应用过程中，Span 就是一个完整的数据包，其包含的就是当前节点所需要上报的数据。核心接口列表如下：\n 接口 描述 SpanContext context() 从 span 中获取 SpanContext void finish()/void finish(long finishMicros) 结束一个 span void close() 关闭 span Span setTag(String key, value) 设置 tags Span log(long timestampMicroseconds, String event) 设置 log 事件 Span setOperationName(String operationName) 设 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第一篇。","dir":"blog/sofa-tracer-overview/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ff58d686746c53b81af210eaf17bb154","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-overview/","publishdate":"2019-02-21T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-overview/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-overview/","wordcount":4138},{"author":"卫恒","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第二篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n 0、前言 在《蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析》一文中已经对 SOFATracer 进行了概要性的介绍。从对 SOFATracer 的定义可以了解到，SOFATracer 作为一个分布式系统调用跟踪的组件，是通过统一的 TraceId 将调用链路中的各种网络调用情况以数据上报的方式记录下来，以达到透视化网络调用的目的。\n本篇将针对SOFATracer的数据上报方式进行详细分析，以帮助大家更好的理解 SOFATracer 在数据上报方面的扩展。\n1、Reporter 整体模型 本节将对 SOFATracer 的 Report 模型进行整体介绍，主要包括两个部分：\n Reporter 的接口设计及实现； 数据上报流程。 1.1、Reporter 的接口设计及实现 数据上报是 SofaTracer 基于 OpenTracing Tracer 接口扩展实现出来的功能；Reporter 实例作为 SofaTracer 的属性存在，在构造 SofaTracer 实例时，会初始化 Reporter 实例。\n1.1.1、Reporter 接口设计 Reporter 接口是 SOFATracer 中对于数据上报的顶层抽象，核心接口方法定义如下：\n//获取 Reporter 实例类型 String getReporterType(); //输出 span void report(SofaTracerSpan span); //关闭输出 span 的能力 void close(); Reporter 接口的设计中除了核心的上报功能外，还提供了获取 Reporter 类型的能力，这个是因为 SOFATracer 目前提供的埋点机制方案需要依赖这个实现。\n1.1.2、Reporter 接口实现 Reporter 的类体系结构如下：\nReporter 的实现类有两个，SofaTracerCompositeDigestReporterImpl 和 DiskReporterImpl ：\n SofaTracerCompositeDigestReporterImpl：组合摘要日志上报实现，上报时会遍历当前 SofaTracerCompositeDigestReporterImpl 中所有的 Reporter ，逐一执行 report 操作；可供外部用户扩展使用。 DiskReporterImpl：数据落磁盘的核心实现类，也是目前 SOFATracer 中默认使用的上报器。 1.2、数据上报流程分析 数据上报实际都是由不同的链路组件发起，关于插件扩展机制及埋点方式不是本篇范畴，就不展开了。这里直接来看数据上报的入口。\n在 Opentracing 规范中提到，Span#finish 方法是 span 生命周期的最后一个执行方法，也就意味着一个 span 跨度即将结束。那么当一个 span 即将结束时，也是当前 span 具有最完整状态的时候。所以在 SOFATracer 中，数据上报的入口就是 Span#finish 方法，这里贴一小段代码：\n//SofaTracerSpan#finish @Override public void finish(long endTime) { this.setEndTime(endTime); //关键记录:report span this.sofaTracer.reportSpan(this); SpanExtensionFactory.logStoppedSpan(this); } 在 finish 方法中，通过 SofaTracer#reportSpan 将当前 span 进行了上报处理。以这个为入口，整个数据上报的调用链路如下图所示：\n整个上报调用流程其实并不是很难，这里留两个问题：\n 如何构造 clientRportor 和 serverReporter 的，依据是什么？ 摘要日志和统计日志是怎么落盘的？ 第一个问题会在插件埋点解析篇中给出答案；第二个问题下面来看。\n2、日志落盘 前面已经提到，SOFATracer 本身提供了两种上报模式，一种是落到磁盘，另外一种是上报到zipkin。在实现细节上，SOFATracer 没有将这两种策略分开以提供独立的功能支持，而是将两种上报方式组合在了一起，然后再通过配置参数来控制是否进行具体的上报逻辑，具体参考下图：\n本节将来剖析下日志落盘的实现细节。日志落盘又分为摘要日志落盘 和 统计日志落盘；摘要日志是每一次调用均会落地磁盘的日志；统计日志是每隔一定时间间隔进行统计输出的日志。\n2.1、摘要日志落盘 摘要日志落盘是基于 Disruptor 高性能无锁循环队列实现的。SOFATracer 中，AsyncCommonDigestAppenderManager 类对 disruptor 进行了封装，用于处理外部组件的 Tracer 摘要日志打印。\n 关于 Disruptor 的原理及其自身的事件模型此处不展开分析，有兴趣的同学可以自行查阅相关资料。这里直接看下 SOFATracer 中是如何使用 Disruptor 的。\n 2.1.1、消息事件模型 SOFATracer 使用了两种不同的事件模型，一种是 SOFATracer 内部使用的 StringEvent，一种是外部扩展使用的SofaTacerSpanEvent。详见：SofaTracerSpanEvent \u0026amp;amp; StringEvent 。\n2.1.2、Consumer 消费者 Consumer 是 AsyncCommonDigestAppenderManager 的内部类；实现了 EventHandler 接口，这个 Consumer 作为消费者存在，监听事件，然后通过 TraceAppender 将 span 数据 flush 到磁盘。详见：AsyncCommonDigestAppenderManager\n2.1.3、Disruptor 的初始化 Disruptor 的构建：在 AsyncCommonDigestAppenderManager 的构造函数中完成的。 //构建disruptor，使用的是 ProducerType.MULTI //等待策略是 BlockingWaitStrategy，考虑到的是CPU的 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第二篇。","dir":"blog/sofa-tracer-response-mechanism/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"350b5d9eacee1bc4b3b604236b247a3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-response-mechanism/","publishdate":"2019-02-21T10:20:00Z","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-tracer-response-mechanism/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-response-mechanism/","wordcount":5014},{"author":"米麒麟","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第四篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\nSOFATracer： https://github.com/sofastack/sofa-tracer\n 前言 由于分布式链路追踪涉及到调用的每个环节，而每个环节都会产生大量的数据，为了存储这种数据，可能需要大量的成本，另外在实际的生产过程中并非所有数据都是值得关注的，基于这些原因，SOFATracer 提供链路数据采样功能特性，一方面可以节约 I/O 磁盘空间，另一方面需要把无关数据直接过滤筛选。目前 SOFATracer 内置两种采样策略，一种是基于固定比率的采样，另一种是基于用户扩展实现的自定义采样。自定义采样模式将 SofaTracerSpan 实例作为采样计算的条件，用户可以基于此实现自行扩展自定义的采样规则。\n本篇文章主要介绍 SOFATracer 数据采样策略原理，通过剖析源码实现详细讲述采样规则算法。\nDapper 论文中的采样模型与策略 跟踪采样模型 每个请求都会利用到大量服务器高吞吐量的线上服务，这是对有效跟踪最主要的需求之一。这种情况需要生成大量的跟踪数据，并且他们对性能的影响是最敏感的。延迟和吞吐量带来的损失在把采样率调整到小于1/16之后就能全部在实验误差范围内。\n在实践中，我们发现即便采样率调整到 1\u0026amp;frasl;1024 仍然是有足够量的跟踪数据用来跟踪大量的服务。保持链路跟踪系统的性能损耗基线在一个非常低的水平是很重要的，因为它为那些应用提供了一个宽松的环境使用完整的 Annotation API 而无惧性能损失。使用较低的采样率还有额外好处，可以让持久化到硬盘中的跟踪数据在垃圾回收机制处理之前保留更长时间，这样为链路跟踪系统的收集组件提供更多灵活性。\n分布式链路跟踪系统中任何给定进程的消耗和每个进程单位时间的跟踪采样率成正比。然而，在较低的采样率和较低的传输负载下可能会导致错过重要事件，而想用较高的采样率就需要能接受的相应的性能损耗。我们在部署可变采样的过程中，参数化配置采样率时，不是使用一个统一的采样方案，而是使用一个采样期望率来标识单位时间内采样的追踪。这样一来，低流量低负载会自动提高采样率，而在高流量高负载的情况下会降低采样率，使损耗一直保持在控制之内。实际使用的采样率会随着跟踪本身记录下来，这有利于从跟踪数据里准确分析排查。\n跟踪采样策略 要真正做到应用级别的透明，我们需要把核心跟踪代码做的很轻巧，然后把它植入到那些无所不在的公共组件中，比如线程调用、控制流以及 RPC 库。使用自适应的采样率可以使链路跟踪系统变得可伸缩，并且降低性能损耗。链路跟踪系统的实现要求性能低损耗，尤其在生产环境中不能影响到核心业务的性能，也不可能每次请求都跟踪，所以要进行采样，每个应用和服务可以自己设置采样率。采样率应该是在每个应用自己的配置里设置的，这样每个应用可以动态调整，特别是应用刚上线时可以适当调高采样率。一般在系统峰值流量很大的情况下，只需要采样其中很小一部分请求，例如 1\u0026amp;frasl;1000 的采样率，即分布式跟踪系统只会在 1000 次请求中采样其中的某一次。\n在 Dapper 论文中强调了数据采样的重要性，如果将每条埋点数据都刷新到磁盘上会增大链路追踪框架对原有业务性能的影响。如果采样率太低，可能会导致一些重要数据的丢失。 论文中提到如果在高并发情况下 1\u0026amp;frasl;1024 的采样率是足够的，也不必担心重要事件数据的丢失。因为在高并发环境下，一个异常数据出现一次，那么就会出现1000次。 然而在并发量不是很多的系统，并且对数据极为敏感时需要让业务开发人员手动设置采样率。\n对于高吞吐量服务，积极采样并不妨碍最重要的分析。如果一个显著的操作在系统中出现一次，他就会出现上千次。低吞吐量服务可以负担得起跟踪每一个请求。这是促使我们下决心使用自适应采样率的原因。为了维持物质资源的需求和渐增的吞吐要求之间的灵活性，我们在收集系统自身上增加了额外的采样率支持。\n如果整个跟踪过程和收集系统只使用一个采样率参数确实会简单一些，但是这就不能应对快速调整在所有部署节点上的运行期采样率配置的这个要求。我们选择了运行期采样率，这样就可以优雅的去掉我们无法写入到仓库中的多余数据。我们还可以通过调节收集系统中的二级采样率系数来调整这个运行期采样率。Dapper 的管道维护变得更容易，因为我们可以通过修改二级采样率的配置，直接增加或减少全局覆盖率和写入速度。\nSOFATracer 的采样源码剖析 SOFATracer 提供链路数据采样功能特性，支持两种采样策略：基于固定采样率的采样模式和基于用户扩展实现的自定义采样模式。\n采样接口模型 SOFATracer 提供定义链路追踪数据采样模式接口 com.alipay.common.tracer.core.samplers.Sampler，此接口 sample 方法通过 SofaTracerSpan 实例参数作为采样计算基础条件决定链路是否采样，实现丰富的数据采样规则。SOFATracer 基于 com.alipay.common.tracer.core.samplers.SamplerFactory 生成的采样器执行链路数据采样基本流程：\n 构建链路追踪器，通过采样器工厂 SamplerFactory 根据自定义采样规则实现类全限定名配置生成指定策略采样器 Sampler，其中基于用户扩展实现的采样模式优先级高，默认采样策略为基于固定采样率的采样计算规则； Reporter 数据上报 reportSpan 或者链路跨度 SofaTracerSpan 启动调用采样器 sample 方法检查链路是否需要采样，获取采样状态 SamplingStatus 是否采样标识 isSampled。 采样器的初始化 上面分析到，采样策略实例是通过 SamplerFactory 来创建的，SamplerFactory 中提供了一个 getSampler 方法用于获取采样器： 从代码片段来看，用户自定义的采样策略将会优先被加载，如果在配置文件中没有找到自定义的 ruleClassName ，则构建默认的基于固定采样率的采样器。SamplerProperties 是采样相关的配置属性，默认提供的基于固定比率的采样率是 100%，即默认情况下，所有的 Span 数据都会被记录到日志文件中。关于具体配置，在下文案例中会有详细介绍。\n采样计算 采样是对于整条链路来说的，也就是说从 RootSpan 被创建开始， …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第四篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-tracer-sampling-tracking-deep-dive/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"552e5d7feb431d3ff658a0194ead7b8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","publishdate":"2019-02-21T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 采样策略和源码剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","wordcount":4224},{"author":"J. Queue","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第三篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。 SOFATracer：https://github.com/sofastack/sofa-tracer\n SOFATracer 是一个用于分布式系统调用跟踪的组件，其核心作用就是能够在分布式场景下将请求经过的各个的链路环节的相关数据记录下来，通过这些数据将各个调用链路相关的组件串联起来。\n在日常的开发中，我们除了跟踪链路外，可能还会遇到一些场景：\n例如在线压测，我们在已有的系统中，模拟一些请求（压测流量）对我们的系统进行压力测试，那么在整个链路中我们是如何让所有的系统都识别出当前的请求是压测流量而不是正式流量的呢？压测流量的标记又是如何在整个链路传递的呢？\n又例如我们已经有了链路数据分析能力，能够快速定位到某个请求是在 A 系统里出的问题，那么我们怎么从 A 系统的业务日志里找到当前请求对应的业务日志呢？\n带着这些问题，让我们先来看看 SOFATracer 的链路透传以及支持 SLF4J MDC 扩展能力。\nSOFATracer 链路透传原理 SOFATracer 的链路透传具体包括两个点：\n 跨进程的透传，即如何将链路数据从一个进程传递到下游进程中 线程中的透传 当前请求跨进程调用结束之后，当前如何恢复 tracer 上下文信息 如何实现跨线程的透传，如在当前线程中起一个异步线程的场景 跨进程链路透传原理 跨进程透传就是将上游系统的链路数据透传到下游系统中，以便于提取出全局的链路标记，如 TracerId 、采样标记等，来实现将服务串联起来并且保持传输过程中某些属性的一致性。SOFATracer 基于 Opentracing 规范实现，因此在链路透传部分，也是基于此规范；下面就先从 Opentracing 规范中的透传开始说起。\nOpentracing 中的定义 在 OT 原文有这么一段描述 传送门\n Programmers adding tracing support across process boundaries must understand the Tracer.Inject(...)and Tracer.Extract(...) capabilities of the OpenTracing specification. They are conceptually powerful, allowing the programmer to write correct_general cross-process propagation code without being bound to a particular OpenTracing implementation; that said, with great power comes great opportunity for confusion.\n 大概意思就是：如果开发者要给应用添加跨进程的追踪能力, 首先要理解 OpenTracing 规范中的 Tracer.Inject(...)和 Tracer.Extract(…)的功能。它们在概念抽象上非常强大，而且允许开发者编写正确的、通用的跨进程传输的代码，而不需要绑定到特定的 OpenTracing 实现上去。\n总的来说就是 Opentracing 的 Tracer 接口定义了跨进程的能力，但是就是没具体实现，不同的基于此规范实现的组件，需要遵循此规范来实现具体的透传逻辑，下面是 Tracer 接口定义的用于透传的两个方法：\n 接口 描述 void inject(SpanContext spanContext, Formatformat, C carrier); 把 spanContext 以指定的 format 的格式注入到 carrier 中 SpanContext extract(Format format, C carrier); 以指定的 format 的格式从 carrier 中解析出 SpanContext 进程透传实现分析 SOFATracer 的 Tracer 的实现类是 SofaTracer， UML 图如下：\n从图中可以看出 SofaTracer 除了有跨进程传输的能力，还扩展了数据上报的能力( Reporter )和采样能力( Sampler )。数据上报能力可以参考《SOFATracer 数据上报机制和源码分析|剖析》这篇文章；采样将在下一篇文章中进行剖析。\n跨进程透传的就是 SpanContext 的内容， carrier 为传输的载体， SpanContext 的实现类为 SofaTracerSpanContext， UML 图：\n跨进程透传处理流程 SOFATracer 中跨进程传输的总体流程如下图所示：\n透传原理的实质就是：调用方编码将指定内容传输到被调方， 被调方解码获取内容的过程。\n跨进程透传的方式有很多， 在这里以客户端向服务端发起 HTTP 请求的方式来演示跨进程传输， fork 代码， 打开 sample/tracer-sample-with-httpclient 示例工程运行 HttpClientDemoApplication ，打开 logs/tracelog/spring-mvc-stat.log 即可看到链路日志， 运行结果 ：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-01-07 19:42:50.134\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:1563,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-01-07 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第三篇。","dir":"blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"82a08996dd671b01595748aa2d2fa748","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","publishdate":"2019-02-21T10:20:00Z","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 链路透传原理与SLF4J MDC 的扩展能力剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","wordcount":6294},{"author":"卫恒","categories":"SOFABoot","content":" SOFABoot 是基于 Spring Boot 的一套研发框架。 在完全兼容 Spring Boot 的基础上，SOFABoot 还提供了启动期监控检查，上下文隔离，模块化开发，类隔离，日志空间隔离等等能力 SOFABoot 地址：https://github.com/alipay/sofa-boot 本文工程案例：https://github.com/glmapper/glmapper-sofa-extension\n 春节小长假还没感觉就过去了，对于“热爱工作”的我，也早早的回到了工作岗位；感受下假期中的我和上班时的我。\n 后面拿枪的就是\u0026amp;rdquo;逼着\u0026amp;rdquo;我写文章的五花肉，上次 SOFATracer 采样用的是刀，这次用了枪！\n 模块化与扩展点 言归正传，节前 SOFABoot 发布了 2.6.x 系列版本，新特性也是相当给力，这里简单罗列下新特性：\n 支持扩展和扩展点 在刷新上下文期间支持 spring bean 的并行初始化 支持使用注解方式发布 JVM 服务 之前的文章中有 @玄北 写过的模块化的文章( 传送门 : 剖析 | 详谈 SOFABoot 模块化原理 \u0026amp;amp; 基于 SOFABoot 进行模块化开发 )，这两篇文章中介绍了模块化的几种实现方案（PS：当然主要还是为了宣传一下 SOFABoot 提供的基于 Spring 上下文隔离的模块化能力）。SOFABoot 的模块隔离方案是为了解决传统的模块化方案模块化不彻底的问题，从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化能力，每个 SOFABoot 模块使用独立的 Spring 上下文，每个模块自包含，模块与模块之间通过 JVM Service 进行通信，从而避免模块间的紧耦合。\n在 Spring 上下文隔离的情况下，各个上下文之间的 bean 是互不可见；SOFABoot 中通过发布 JVM 服务的方式使得不同模块 bean 之间的访问得以实现。但是同时又带来了另外一个问题，如果一个模块以独立 jar 的方式对外提供 api ，那么对于其他依赖此模块的模块来说，就无法去改变这个模块中的 bean 实例行为。\n在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项目，并在上面扩展，与 Spring 融合，提供了扩展点的能力。\n本篇将针对 SOFABoot 2.6.x 版本中提供的扩展点进行简单尝试，结合官方文档提供的示例，一步一步实现我们自定义的一个扩展点功能（本文过于简单，可能会引起极度舒适，请备好被子和热水袋）。\n案例背景 这里先抛出一个例子，现在有一个三方 jar ，它定义了获取数据源接口的顶层抽象；不同的业务方如果依赖这个 jar，则需要自己提供一个数据源的实现，当然其本身提供了默认实现（假设是 mysql）。基于此我们大概能够想到的方式就是基于 SPI 来提供这种扩展能力，但是对于在 Spring 上下文隔离的情况下，业务方的 Spring 上下文是无法与引入 jar 的上下文共享 bean 的，这样自然也就无法实现对原有数据源实现的扩展。\n那么这里我们就可以选择使用 SOFABoot 扩展点来实现，这里有两个比较重要的概念，也是扩展点区别于 SPI 的主要特性：\n 可以在基于 Spring 上下文隔离的情况下实现扩展 扩展的是 Spring Bean  下面基于这两个点，来完成自定义扩展点的一个案例。在实现上述案例之前我们需要先构建一个基于 Spring 上下文隔离的模块化工程，然后再简单介绍下扩展点的基本使用方式。\n构建模块化工程 SOFABoot 开源版本中并没有给出扩展点相关的案例工程，只是在测试用例中进行了详细的测试，有兴趣的同学可以看下相关测试用例代码。实际上测试用例中也没有涉及到在模块化的场景下使用扩展点，测试用例都是基于同一个Spring 上下文来完成的。本篇文章将先搭建一个简单的模块化工程，然后基于此工程来实现扩展点的能力。\n本工程主要包括 4 个模块：\n glmapper-sofa-facade // JVM 服务发布与引用的 API 包 glmapper-sofa-provider // Annotation 方式发布 JVM 服务 glmapper-sofa-consumer // Annotation 方式引用 JVM 服务 glmapper-sofa-web // 启动包含 SOFABoot 模块的 SOFA Boot 应用 官方文档及案例 中给的比较复杂，包含了多种使用服务发布和引用的方式，这里我使用了最新提供的基于注解的方式来实现；获取本文工程案例。\n扩展点基本使用 在 SOFABoot 中使用扩展点能力，需要以下三个步骤：\n 定义提供扩展能力的 bean 定义扩展点 定义扩展并使用 这三步中前两步都是由服务提供方来完成，最后一步由具体的业务使用方式来定义。\n定义提供扩展能力的 bean 本案例工程中，是将 glmapper-sofa-provider 作为服务提供方，因此也在此模块下定义一个具有扩展能力的 bean 。\n定义这个接口的实现：\n在模块的 Spring 配置文件 resources/META-INF/service-provider.xml 中，我们把这个 bean 给配置起来：\n定义扩展点 在上面的 bean 中有一个字段 word ，在实际中，我们希望这个字段能够被其他的模块自定义进行覆盖，这里我们将其以扩展点的形式暴露出来。这里先定义一个类去描述这个扩展点：\n然后在模块的 Spring 配置文件 resources/META-INF/service-provider.xml 中定义扩展点：\n name：为扩展点的名字 ref：为扩展点所作用在的 bean object：为扩展点的贡献点具体的描述，这个描述是通过 XMap 的方式来进行的（XMap 的作用是将 Java 对象和 XML 文件进行映射，这里建议通过在网上搜索下 XMap 的文档来了解 XMap） 至此服务提供端已经暴露出了扩展点，那么在服务使用端，也就是需要扩展这个 bean 的使用方就可以扩展这个bean 了。\n定义扩展 上述已经将扩展点定义好了，此时我们就可以对这个 bean 进行扩展了。扩展是具体业务使用方来做的事，在本案例中，glmapper-sofa-web 模块作为使用服务使用方，因此在 resources/META-INF/spring/web-home.xml 下进行扩展定义：\n bean：为扩展所作用在的 bean point：为扩展点的名字 content 里面的内容为扩展的定义，会通过 XMap 将内容解析为：扩展点的贡献点具体的描述对象，在这里即为 com.glmapper.bridge.extension.ExtensionDescriptor 对象 需要注意一点，glmapper-sofa-web 模块不是一个 SOFABoot 模块，这里留坑。\n 编写一个 TestController 类，这里最先 …","date":1550127600,"description":"本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。","dir":"blog/sofa-boot-extension-practice/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4f05313f7adf5401f3b5f499b43bb928","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-extension-practice/","publishdate":"2019-02-14T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-boot-extension-practice/","summary":"SOFABoot 是基于 Spring Boot 的一套研发框架。 在完全兼容 Spring Boot 的基础上，SOFABoot 还提供了启动期监控检查，上下文隔离，模块化开发，类隔离，日志空间隔离等等","tags":["SOFABoot"],"title":"SOFABoot 扩展点初体验 | SOFALab 实践系列","type":"blog","url":"/sofastack.tech/blog/sofa-boot-extension-practice/","wordcount":3773},{"author":"余淮","categories":"SOFAStack","content":" SOFA:Channel/，有趣实用的分布式架构频道。 SOFA:Channel/ 作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）。\n 大家晚上好，今天是 SOFAChannel 第一次线上直播，感谢大家的收看。\n先自我介绍下，我是来自蚂蚁金服中间件的章耿，花名余淮，目前在负责应用框架与 SOFAStack 开源相关的工作。\n今天给大家的分享主要分为三部分，第一部分是蚂蚁金服服务化演进的简介，第二部分是SOFAStack开源的情况。这两部分之前的分享也提到过，我们讲快一点，第三部分会详细介绍下 SOFARPC 的一些设计和实现细节。\n分享过程中如果大家对技术点比较感兴趣，或者其他组件感兴趣，也欢迎留言，后面的直播会安排更多的相关分享。\n蚂蚁服务化架构演进简介 大家现在对蚂蚁金服技术的概念，听得比较多的应该是“余额宝”、“相互宝”、“蚂蚁森林”、“刷脸支付”，“扫描工具地铁”、“双十一”等等这些耳耳熟能详的产品和场景。\n这些产品的背后，是蚂蚁金融科技的一套核心技术，包括 “三地五中心异地多活架构”，“金融级分布式架构”、“国产金融级分布式数据库 OceanBase”，“智能风控”，“区块链” 等诸多黑科技。\n当然，蚂蚁金服的微服务架构体系像其它传统的企业一样，也不是一开始就这么高大上，也是随着业务的发展慢慢演进而来的。下面给大家简单介绍下演进的过程。\n这个支付宝最早的架构示意图，可以看到当时支付宝只是电商后台的一个支付系统，是一个单体应用，里面简单的分了几个业务模块，连的也是一个数据库。但随着业务规模的不断扩展，单系统架构已经无法满足业务需求。\n所以支付宝就对大系统进行了拆分，将原来的一个单体应用内部的多个模块变成了多个独立的子系统，这算是典型的 SOA 化的架构。\n最开始系统之间是使用 F5 的硬件负载设备来做系统间的负载均衡，但由于 F5 设备存在单点的问题，所以后面就在中间引入一个注册中心的组件。服务提供者去注册中心注册服务，服务消费者去注册中心订阅服务列表，服务消费者通过软负载方式通过 RPC 框架直接调用服务提供者。这在现在看来是一种非常显而易见的服务化架构，但当时 07 年就采用这样的架构还是算比较超前的。\n支付宝在做系统拆分的同时，对数据库也按子系统进行了垂直拆分。数据库的拆分就会引入分布式事务的问题，蚂蚁金服中间件就提供了基于 TCC 思想的分布式事务组件 DTX。\n业务还是不断扩展，系统也越来越多，当系统节点到一定数量的时候，单个物理机房已经无法承受。另外考虑到同城容灾的问题，支付宝就在同城再扩建另外一个机房，通过专线部署为一个内部网络，然后将应用部署上去。\n同城多机房会引入一个跨机房远程访问的问题，相比同机房调用，这个延迟损耗一定是更高的。远程访问主要包括两种：RPC 调用和数据库访问。为了解决 RPC 跨机房调用的问题，支付宝的工程师选择的方案是在每个机房都部署注册中心，同机房优先调用本机房服务的方式，也就变成图中的部署模式。但是数据库跨机房访问的问题，在这个阶段并没有解决。\n另外还存在的一个问题就是调用链路混乱以及数据库连接瓶颈的调用。例如这个图里，我们对数据进行了分片，然后图中的 user0 的请求进来后，随机转到 S2，再随机转到B0，在随机到C1，最终跟进数据分配落到了数据库 D0。可以看到这里的调用链路是随机的，而每一个核心层也需要跟所有的分库都建立长连接。\n为了解决上面的跨机房数据访问、数据库连接数瓶颈以及未来数据水平扩展的问题，蚂蚁的工程师们设计了一套单元化的架构，这是单元化的一个示意图。\n在没有单元化的时候，用户请求进入内部后，所有请求链路都是随机走的，例如图里的 S0 到 B1 到 C2 到 D0。首先蚂蚁的请求都是跟用户相关的，所以我们将数据按用户的维度进行水平分片，例如这张示意图我们将所有用户分为三组。然后我们将我们的应用也部署成三组独立的逻辑单元，每个逻辑单元的应用和数据都是独立的，相当于每个逻辑单元都处理1/3总量用户的数据。\n这个时候我们的三个不同终端的用户，不管是在PC端或者手机端或者扫二维码，当请求进入统一接入层的时候，接入层会按上面逻辑单元的分组规则，将用户请求转发到对应的逻辑单元，例如 user0 的请求转到 S0，后面的应用之间的调用、数据都只在逻辑单元 0 内。统一的 user1 只在逻辑单元 1，user2 也只到逻辑单元 2。\n我们把这种逻辑单元称之为 RegionZone。在实际的部署过程中，物理数据中心 IDC 和 逻辑单元的数量没有完全的对等关系。例如图中我们物理机房可以是两地三中心，而 RegionZone 则是分为五个。\n两地三中心是国家对金融机构的一个容灾指导方案，要求在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同时在异地（＞ 200KM ) 建立异地容灾中心。\n有了这套单元化的架构做指导思想，蚂蚁进行大规模的改造，包括应用改造、基础框架改造、数据中心的建设。\n机房建设完成后，同时蚂蚁金服将自己的用户分成了若干份，划了几个逻辑单元，分别部署进了不同的物理机房，同时完成大规模的数据迁移。\n从两地三中心到容灾能力更强大的三地五中心，我们只需要先进行第三个城市的机房建设，然后将部分 RegionZone 部署到第三个城市，最后再完成数据迁移和引流即可。\n每一个 RegionZone 在异地都有备份，当发生城市级的故障时，我们通过统一的管控中心将新的逻辑规则推送到统一接入层以及异地的备 RegionZone 时，就可以做到城市级的整体容灾切换。\n再后面基于单元化思想，蚂蚁工程师还建设了弹性 LDC 的能力，例如大型活动开始的时候，我们将动态的将大促相关应用调度到其它的临时机房（例如是云上的机房）去，然后将流量引入。例如图中实例将 10% 的流量引入了 ZoneX 中。等到活动结束，我们再将流量引回。\nSOFAStack 开源情况 从前面的服务化演进可以看到，蚂蚁的微服务架构面临的场景已经慢慢从简单的远程调用发展到要面临复杂的三地五中心异地多活场景，为了支持这些场景，蚂蚁中间件自研了一套中间件 SOFAStack。\nSOFAStack 中的 SOFA 其实是 Scalable Open Financial Architecture 的首字母缩写，它是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n这是我们内部的技术栈，可以看到微服务领域各个功能点我们都有对应的内部系统或者组件。包括有RPC框架、服务发现、动态配置、熔断限流，还有分布式事务，分库分表等一整套中间件。\n目前 SOFAStack 也在蚂蚁金融科技上进行了技术输出。我们对中间件产品进行了产品化，并在蚂蚁金融云上变成了云上的产品，并提供了诸多例如同城双活之类的解决方案。这个是商业的产品，大家有空可以看下。\n在去年的 4.19 号，SOFAStack 正式宣布开源，我们第一批主要开了SOFABoot …","date":1548680400,"description":"本文根据 SOFAChannel#1 直播分享整理，主题：从蚂蚁金服微服务实践谈起。","dir":"blog/sofa-channel-1-retrospect/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c7997723a3859feb5f4f8fa454b6e00e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-1-retrospect/","publishdate":"2019-01-28T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-1-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 SOFA:Channel/ 作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。欢迎加入直播","tags":["SOFAStack","SOFAChannel"],"title":"从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-1-retrospect/","wordcount":6269},{"author":"花肉","categories":"SOFAChannel","content":" 活动主题：SOFAChannel#1——从蚂蚁金服微服务实践谈起 活动时间：1 月 17 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 \u0026amp;lt;SOFA:Channel/\u0026amp;gt;，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#1 《从蚂蚁金服微服务实践谈起》\n时间：2019-01-17 地点：浙江省杭州市西湖区线上直播 19:00-20:00 《从蚂蚁金服微服务实践谈起》 章耿 花名余淮（蚂蚁金服高级技术专家。目前在蚂蚁金服中间件服务与框架组负责应用框架及 SOFAStack 相关的工作） 嘉宾 蚂蚁金服 SOFA 团队 余淮\n视频回顾地址 https://tech.antfin.com/community/live/148\n","date":1547720400,"description":"首次 SOFAChannel 线上直播，1 月 17 日晚 7 点等你。","dir":"activities/sofa-channel-1/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5c79d2fac126784ef412f107470b2924","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-1/","publishdate":"2019-01-17T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-1/","summary":"活动主题：SOFAChannel#1——从蚂蚁金服微服务实践谈起 活动时间：1 月 17 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 \u0026","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#1——从蚂蚁金服微服务实践谈起","type":"activities","url":"/sofastack.tech/activities/sofa-channel-1/","wordcount":323},{"author":"许文奇","categories":"SOFAStack","content":" 许文奇 蚂蚁金服高级技术专家，SOFAStack 商业化产品技术 Leader，多年分布式架构及中间件研发经验，负责过蚂蚁金服分布式架构在多家金融机构的咨询和落地 本文根据他在 2019 蚂蚁金服 ATEC（Ant Technology Exploration Conference）科技大会上海站的分享整理。\n 本次分享主要会从单体架构和微服务架构的对比开始，后面重点谈一下实施金融级分布式架构的常见三个问题。\n常用架构：单体式架构 目前很多金融机构的架构是典型的单体式架构，一般由反向代理服务器，数据库和应用组成，所有业务模块都打包在一个应用里面运行，一般为了高可用考虑，应用至少会部署两个节点。单体式架构在业务简单的时候有很多它自身的优点：\n 开发，测试简单 部署简单 扩容简单，只要给应用加机器就行 但同样，单体式架构也有很多缺点，尤其是业务规模变得复杂以后，缺点会非常突出：\n 编译慢，启动慢，代码冲突等各种问题，严重影响开发效率 性能扩展有局限性，一定规模后，单纯堆机器已经很难扩展性能了。 蚂蚁金服的架构：分布式架构 微服务架构是目前大家最关注的一种分布式架构。微服务架构除了在性能可扩展性上对比单体式架构有巨大优势，还有一个重要优势体现在复杂业务下的生产效率优势。\n只有在业务复杂度较低的时候，单体式架构的生产效率才能超过微服务架构，但随着业务复杂度上升，尤其过了临界点，单体架构下的生产效率是非常恐怖的急速下坠，而微服务架构生产效率有所下降，但下降趋势非常缓慢，且不会偏离原有生产效率太多，能很好的应对业务复杂性的增长。\n所以实施微服务架构最重要的一个意义是在业务复杂度较高的情况下提升生产效率，更快速的进行业务创新。\n实施金融级分布式架构最常见的三个挑战 基于微服务架构的巨大优势，很多金融机构、企业开始逐渐转型微服务架构，转型总是伴随着挑战，这里选了三个最常见的，最多用户关心的问题，聊聊蚂蚁金服的一些实践心得：\n 如何进行微服务架构拆分及治理？ 新的分布式架构如何兼容老系统？ 如何一步一步构建金融级容灾架构？ 1、微服务架构拆分及治理 微服务拆分模式可以从微服务架构的扩展立方开始讲起，分为X轴，Y轴，Z轴三类拆分。\nX轴代表横向扩展模式。主要通过部署多份应用，负载均衡的方式来扩展性能，这个单体架构也可以做。当然，在微服务架构下，横向扩展模式的实现方式有别于单体架构。\n微服务架构做服务负载均衡不需要通过F5或者LVS集群这样的硬件设备，只需要通过注册中心就可以实现，这样带来的好处是降低了成本，不需要购买大量的硬件设备了；提高了性能，业务干路上少了一个单点风险；降低了维护成本。\n当然支持横向扩展模式还需要应用是无状态的，这个是微服务架构的基本要求，任何涉及状态的数据都应该保存在数据库，缓存或者其他一些存储介质中。更高的要求的话，应用应该要满足著名的12要素的要求。\nY轴代表功能分解模式。我们提倡业务系统在开发的时候就应该按照模块化进行开发，满足高内聚，低耦合的架构要求。为了更好支持模块化开发，以SOFAStack中间件的SOFABoot框架为例，框架支持模块隔离能力，不同的模块使用不同的Spring上下文，这样不同的模块之间就不能直接引用了，如果需要调用别的模块的接口，那么需要走SOFABoot框架规定的特别声明才可以办到。这样极大的规范了模块化开发，使得这些系统将来在进行拆分的时候，成本非常的低。\n关于功能分解，服务拆分，虽然没有一个标准答案告诉我们就该怎么做，但其实也有一些基本指导原则和实践：\n 按照业务领域进行拆解，而不是组织。所有拆分必须按照业务领域模型进行合理划分，因为实体组织不一定能和业务领域完全对应，且组织一般粒度较大，不能作为拆分细粒度微服务的参考。 从数据核心模型拆分开始先拆，而后再往上进行服务拆分。这个主要是进行拆分的一个重要次序问题。一般梳理数据核心模型比较容易，比如很容易梳理出哪些表，哪些数据属于交易，哪些表，哪些数据属于账务，然后按照业务垂直进行拆分。有些业务归属不那么明确的可以按照数据亲和性进行拆分。然后数据核心模型拆分好以后，再往上按照功能模块，所对应的场景，进行服务拆分。 单一职责。这个是微服务架构的一条金科玉律，要求微服务架构必须遵守。一个很主要的原因是为了避免微服务架构重新掉进单体架构的老问题里面。原来单体架构最大的问题就是任何的改动，都要导致整个应用重新的编译打包部署，还包括全量回归测试。试想一个微服务里面有太多的功能、职责，如果任意一个业务模块有需求，需要改动，必然导致该微服务的应用重新编译，打包部署和全量回归测试，频繁变动成本很高，研发效率也会降低。 注意拆分粒度，避免一开始拆得过细，循序渐进。关于拆分粒度，这个也是一个没有标准答案的问题。总的一个原则就是适用最好。任何一家公司的业务都是独一无二的，不存在一模一样业务的两家公司，所以别人的拆分，可以借鉴，但往往很难照抄。所以推荐拆分的时候，一开始不要拆得过细，按照业务发展的规律，循序渐进。举个例子，比如说红包业务，原来可能只是营销系统的一个模块，但如果公司的业务在红包这块发展得足够复杂，是可以考虑拆为单独的微服务，这一切取决于业务发展。 注意服务分级和分层，避免循环依赖。这个要求服务拆分的时候，充分注意到哪些是核心服务，哪些是非核心服务，不能出现核心服务强依赖非核心服务的情况，更不能出现循环依赖的情况。 考虑团队结构。最后微服务拆出来，肯定是要有对应团队去维护的，所以整个拆分的粒度，拆分的逻辑也要考虑团队结构的情况。 Z 轴代表数据分区模式。一般在数据库遇到性能瓶颈的时候，需要进行数据拆分，一般分为垂直拆分和水平拆分。垂直拆分一般就是按照业务划分来进行，比如以前账务和交易放在一个数据库，现在数据库有瓶颈了，那么就可以拆成账务和交易两个数据库，缓解数据库的性能瓶颈。当然，如果按照垂直拆分完毕以后，还是不能满足性能要求，这个时候就需要进行水平拆分了。\n关于水平拆分，也有一些重要的实践原则。在做数据库水平拆分的时候，最好一次性考虑未来十年，甚至二十年的业务的要求，要避免今天做了一个拆5张表的决定，过了两年，发现不行，还要继续拆成10张表，甚至20张表的情况。\n重新分片是个非常复杂的工作，尤其是线上还不允许停机的情况。另外关于确定如何拆多少库，多少表，也有一些实践。一般拆的数据库数量等于未来业务的峰值（TPS）除以单数据库的容量（TPS）。这里并不代表要一步到位，拆那么多实际物理库，一开始可借助SOFAStack分库分表中间件虚拟成逻辑库，只需要少量物理库，等到访问量上来后，再扩容物理库。拆的表的数量等于单表时间业务量乘以存储时长除以单标容量上限。记住表的数量一定要一步拆到位，避免过一两年还要折腾。\n做了数据拆分后，就会遇到分布式事务的问题，需要解决分布式事务的问题，这个也是金融行业区分与别的行业的最大不同。SOFAStack分布式事务中间件目前支持TCC和FMT两种模式（这里主要讨论实践，对于TCC和FMT两种模式的原理，这里不再赘述，有兴趣的可以参考之前的文章）。TCC模式虽然编码复杂，业务有侵入，难度较高，但胜在性能好，所以像核心系统里面的分布式事务都是用该方案。当然，因为复杂，所以实现中有些地 …","date":1547535600,"description":"本次分享主要会从单体架构和微服务架构的对比开始，后面重点谈一下实施金融级分布式架构的常见三个问题。","dir":"blog/distributed-arch-in-the-enterprise/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e2f9f404c5e859e21c65fb3c2f2f0324","permalink":"https://sofastack.github.io/sofastack.tech/blog/distributed-arch-in-the-enterprise/","publishdate":"2019-01-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/distributed-arch-in-the-enterprise/","summary":"许文奇 蚂蚁金服高级技术专家，SOFAStack 商业化产品技术 Leader，多年分布式架构及中间件研发经验，负责过蚂蚁金服分布式架构在多家金融","tags":["SOFAStack"],"title":"企业实施分布式架构的挑战以及应对建议 | 上海 ATEC 科技大会实录","type":"blog","url":"/sofastack.tech/blog/distributed-arch-in-the-enterprise/","wordcount":5455},{"author":"崔秀龙","categories":"Service Mesh","content":" 崔秀龙，HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员。\n本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整理，完整的分享 PPT 获取方式见文章底部。\n本文内容收录在崔秀龙的新书：《深入浅出 Istio - Service Mesh 快速入门与实践》的第十章，该书将于近期由博文视点出版发行，敬请关注。\n Service Mesh 概念在 Linkerd 落地之后，让一直漂浮在空中的微服务治理方案有了一个明确的落地点，给微服务架构的具体实现指出了一个清晰的方向，围绕这一概念逐步开始形成新的技术生态，在业界造成不少震动。这种震动对于企业 IT 转型工作带来的影响，甚至比容器化的影响更加深远。对于承担企业 IT 转型工作的企业服务行业来说，也自然首当其冲感觉到新概念带来的压力。\n企业服务行业和互联网行业相比，业务形态、技术积累和人员结构等方面都大相径庭，举几个常见的差异：\n 开发、运维、基础设施所属 人员结构、水平和年龄 资源使用率差别 架构和平台一致性 负载能力 \u0026amp;hellip; 目前进行 Service Mesh 布道的主力还是互联网行业的旗手们，一味追求跟进互联网同行们的进度和做法，颇有邯郸学步的风险。\n本文中将会针对目前 Service Mesh 方面的一些普遍问题和关注热点发表一些个人意见。并尝试提供一种 Istio 的试用思路，给乙方同行们提供参考。\nIstio 的功能 无需赘述，多数用户都很清楚，Istio 使用和应用共享网络栈的方式，利用 Iptables 劫持应用的网络流量，从而在不修改业务源码的情况下，完成一系列的功能：\n 监控服务质量 控制服务间的访问路由 应对服务故障 在服务间通信之间进行加密 访问控制和频率限制 分布式跟踪和业务紧密相关，无法做到无侵入。\n 这其中最大的优势就是无侵入，这意味着给试用流程留下了全身而退的机会，如果没有回滚的能力，上述种种能力都是空中楼阁。\nIstio 的问题 API 稳定性可能是最严重的一个问题。目前最成熟的功能组别应该是流量控制，其版本号也仅是 v1alpha3，一般来说，alpha 阶段的产品，代表着不提供向后兼容的承诺，流量控制 API 在从 v1alpha2 升级为 v1alpha3 的过程中，API 几乎全部改写，使得很多早期用户的精力投入付诸东流。核心功能尚且如此，遑论相对比较边缘的 Mixer、Citadel 以及 Galley 组件的相关内容。 发布节奏和发布质量的问题也相当严重。Istio并不算长的历史中，出现了多次版本撤回、大版本严重延期、发布质量低下无法使用以及 Bug 反复等状况，这无疑会让每次升级尝试都充满了不确定性，会很大的影响生产过程的连续性。 Mixer 是一个问题焦点，其数据模型较为复杂，并且集中了所有应用的流量于一点，虽然其中加入了各种缓存等技术来降低延迟，但是其独特地位决定了 Mixer 始终处于一个高风险的位置。同时其 API 结构稍显混乱，重构风险较大。 Pilot的性能方面也经常为人诟病，虽然经过几次升级，但是即使是 1.0 之后，还是出现了两次 Pilot 在集群中服务/Pod 过多的情况下会超量消耗资源的问题。 安全、物理机和虚拟机的支持以及网格边缘通信这三组功能，目前用户较少，质量尚不明确。 最后就是 Istio 的 Sidecar 注入模式，这种模式一定会增加服务间调用的网络延迟，在目前阶段这是一个痼疾，Sidecar 的固定延迟和 Mixer 的不确定行为相结合，有可能会产生严重后果。 这里提出的只是被反复提及，或者经常出现在 Issue 列表中的问题，由发布问题来看，面临的风险可能远不止这些。\nIstio 试用工作的理由和规划 试用 Istio，首先应该确定，该技术的采用，是否能够在可控的风险和投入下，得到有效的产出。\n 微服务模式的推进，必须要有相应的管理能力，Service Mesh 目前看来，是一个确定有效的方案，如果不是 Istio，也会有其它替代产品出现。 目前看来，Istio 是 Service Mesh 的标志性产品，有一定可能性成为事实标准。 提供了众多开箱即用的丰富特性，能够迅速进入 Service mesh。 最后是无侵入的优势：如果试用失败，可以退回，控制损失范围。 Istio 的多数功能，在无需对程序进行修改（分布式跟踪除外）的情况下，能对应用提供如此之多的功能支持，无疑是非常有吸引力的。Istio 的功能集，完全可以说是服务网格技术的典范。一旦确认现有环境有可能支持 Istio 的运行，并且在合理的投入下能够获得有效益的产出，那么这个试用就是有价值的。\n结合 Istio 的现状，以及多数企业的运行状态，个人浅见，Istio 的应用在现阶段只能小范围试探性地进行，在进行过程中要严格定义试用范围，严控各个流程。 按照个人经验，笔者将试用过程分为如下 4 个阶段。\n 范围定义：选择进入试用的服务，确定受影响的范围，并根据 Istio 项目现 状决定预备使用的 Istio 相关功能。围绕这些需要，制定试用需求。 方案部署：根据范围定义的决策，制定和执行相关的部署工作。其中包含 Istio 自身的部署和业务服务、后备服务的部署工作。 测试验证：根据既有业务目标对部署结果进行测试。 切换演练：防御措施，用于在业务失败时切回到原有的稳定环境。 Istio 的试用步骤 确定功能范围 在 Istio 中包含了非常多的功能点，从原则上来说，各种功能都是有其实际作用的。然而，Istio 作为一个新产品，本身也有很多不足，我们在 10.1 节中也提到了这些不足。\nIstio 提供的众多功能对每个公司或者项目，都会有不同价值。我们在采用一个新系统时，首先要考虑的就是性价比问题，这里的“价”代表着 Istio 带来的风险、对业务应用的影响，还包括可能出现的服务停机等问题。\n可以根据性价比，做出一个优先级别列表。在制定了优先级列表之后，就可以根据这一列表，结合项目的实际需求，按照效果明显、功能稳定、部署成本低、少改造或者不改造的标准来进行选择，最终确定待测试的功能点。\n在选定功能点之后，应该遵循目前已有的 Istio 文档，对各个功能点进行单项测试和验证，以确保其有效性。并通过官方 GitHub 的 Issue 列表及讨论组内容，了解现有功能是否存在待解决的问题，以及相关的注意事项等。\n选择试用业务 在试用功能点确定之后，就要选择用于试用的业务应用了。Istio 作为一个相对底层的系统，其部署和调试过程必然会对业务产生一定的影响，在运行阶段又有 Sidecar 和各个组件造成的损耗，如下所述：\n 所有网格之间的通信都要经过 Sidecar 的中转，会造成大约 10 毫秒的延迟。 Pilot 对集群规模敏感，集群中的服务数量、Pod 数量都可能对 Pilot 造成较大影响，也会影响到 Istio 各种规则向 Pod 的传输过程。 所有流量都会经由 Mixer 处理，也有造成瓶颈的可能。 安全功能设置不当同样会造成服务中断。 如上所述还只是个概要，对业务来说，对这些风险都是必须正 …","date":1547103600,"description":"本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-meetup-5-istio-retrospect/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"88553acdb286a68c44cc9bf390855f26","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","publishdate":"2019-01-10T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","summary":"崔秀龙，HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员。 本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整","tags":["Service Mesh"],"title":"企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","wordcount":4050},{"author":"敖小剑","categories":"Serverless","content":" Knative 是Google 发起的 Serverless 项目，希望通过提供一套简单易用的 Serverless 开源方案，将 Serverless 标准化。 本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，PPT 获取地址：下载地址\n 前言 大家好，今天给大家来的演讲专题是“Knative：重新定义Serverless”, 我是来自蚂蚁金服中间件的敖小剑。\n这是我的个人资料，有兴趣的同学可以关注的我的个人技术博客网站 https://skyao.io\n这次演讲的内容将会有这些，首先给大家介绍一下 Knative 是什么，然后是 Knative 的主要组件，让大家对 Knative 有一个基本的了解。之后我会简单的对 Knative 做一些分析和探讨，以及介绍一下 Knative 后续的发展。希望本次的内容让大家能够对Knative有一个基本的认知。\n什么是 Knative？ Knative 是 Google 牵头发起的 Serverless 项目。\n这是Knative的项目定义，注意这句话里面几个关键字：Kubernetes，Serverless，Workload。\n这是最近几年 Google 做大型项目的常态：产品刚出来，阵营就已经很强大了，所谓先声夺人。\n是目前Knative项目的进展，可以看到这是一个非常新的项目，刚刚起步。\n 备注：这是截至2018-11-24演讲当天的情况，到2018年12月底，Knative已经发布了v0.2.2和v0.2.3两个bugfix版本。但也还只是 0.2 ……\n 我们来看一下，在Knative出来前， Serverless 领域已有的实现，包括云端提供的产品和各种开源项目。\n这幅图片摘自 The New Stack 的一个 Serverless 调查，我们忽略调查内容，仅仅看看这里列出来的 Serverless 产品的数量——感受是什么？好多Serverless项目，好多选择！\n那问题来了：到底该怎么选？\n这就是目前 Serverless 的问题：由于缺乏标准，市场呈现碎片化。不同厂商，不同项目，各不相同，因此无论怎么选择，都面临一个风险：供应商绑定！\n这段话来自 Knative 的官方介绍，Google 推出 Knative 的理由和动机。其中第一条和第二条针对的是当前 Serverless 市场碎片的现状。而第四条多云战略，则是针对供应商绑定的风险。\nGoogle 描述 Knative 的动机之一，是将云原生中三个领域的最佳实践结合起来。\n小结：\n当前 Serverless 市场产品众多导致碎片化严重，存在厂商绑定风险，而 Google 推出 Knative，希望能提供一套简单易用的 Serverless 方案，实现 Serverless 的标准化和规范化。\nKnative 的主要组件 第二部分，来介绍一下Knative的主要组件。\n前面提到，Google 推出 Knative ，试图将云原生中三个领域的最佳实践结合起来。反应到 Knative 产品中，就是这三大主要组件：Build，Serving，Eventing。\nKnative Build 组件，实现从代码到容器的目标。为什么不直接使用 dockfile 来完成这个事情？\nKnative Build 在实现时，是表现为 Kubernetes 的 CRD，通过 yaml 文件来定义构建过程。这里引入了很多概念如：Build，Builder，Step，Template，Source等。另外支持用 Service Account 做身份验证。\nKnative Serving 组件的职责是运行应用以对外提供服务，即提供服务、函数的运行时支撑。\n注意定义中的三个关键：\n Kubernetes-based：基于 k8s，也仅支持 k8s，好处是可以充分利用k8s平台的能力 scale-to-zero：serverless 最重要的卖点之一，当然要强调 request-driven compute：请求驱动的计算 值得注意的是，除了k8s之外，还有另外一个重要基础：istio！后面会详细聊这个。\nKnative Serving项目同样也提供了自己的中间件原语，以支持如图所示的几个重要特性。\nKnative中有大量的概念抽象，而在这之后的背景，说起来有些意思：Knative 觉得 kubernetes 和 istio 本身的概念非常多，多到难于理解和管理，因此 Knative 决定要自己提供更高一层的抽象。至于这个做法，会是釜底抽薪解决问题，还是雪上加霜让问题更麻烦……\nKnative的这些抽象都是基于 kubernetes 的 CRD 来实现，具体抽象概念有：Service、Route、Configuration 和 Revision。特别提醒的是，右边图中的 Service 是 Knative 中的 Service 概念，service.serving.knative.dev，而不是大家通常最熟悉的 k8s 的 service。\n对于 Knative Serving 组件，最重要的特性就是自动伸缩的能力。目前伸缩边界支持从0到无限，容许通过配置设置。\nKnative 目前是自己实现的 Autoscaler ，原来比较简单：Revision 对应的pod由 k8s deployment 管理，pod上的工作负载上报 metrics，汇总到 Autoscaler 分析判断做决策，在需要时修改 replicas 数量来实现自动伸缩（后面会再讲这块存在的问题）。\n当收缩到0，或者从0扩展到1时，情况会特别一些。Knative在这里提供了名为 Activator 的设计，如图所示：\n Istio Route 控制流量走向，正常情况下规则设置为将流量切到工作负载所在的pod 当没有流量，需要收缩到0时，规则修改为将流量切到 Activator ，如果一直没有流量，则什么都不发生。此时Autoscaler 通过 deployment 将 replicas 设置为0。 当新的流量到来时，流量被 Activator 接收，Activator 随即拉起 pod，在 pod 和工作负载准备好之后，再将流量转发过去 Knative Eventing 组件负责事件绑定和发送，同样提供多个抽象概念：Flow，Source，Bus，以帮助开发人员摆脱概念太多的负担（关于这一点，我保留意见）。\nBus 是对消息总线的抽象。\nSource 是事件数据源的抽象。\nKnative 在事件定义方面遵循了 Cloudevents 规范。\n小结：\n简单介绍了一下 Knative 中的三大组件，让大家对 Knative 的大体架构和功能有个基本的认知。这次就不再继续深入 Knative 的实现细节，以后有机会再展开。\nKnative分析和探讨 在第三部分，我们来分析探讨一下 Knative 的产品定位，顺便也聊一下为什么我们会看好 Knative。\n首先，最重要的一点是：Knative 不是一个 Serverless 实现，而是一个 Serviceless 平台。\n也就是说，Knative 不是在现有市场上的20 …","date":1546498800,"description":"本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，文中有 PPT 获取地址。","dir":"blog/serverless-knative-giac/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"21d3b124a0863acf6481463647b92095","permalink":"https://sofastack.github.io/sofastack.tech/blog/serverless-knative-giac/","publishdate":"2019-01-03T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/serverless-knative-giac/","summary":"Knative 是Google 发起的 Serverless 项目，希望通过提供一套简单易用的 Serverless 开源方案，将 Serverless 标准化。 本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，PPT 获取地址：下载","tags":["Serverless","Knative"],"title":"Knative：重新定义 Serverless | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/serverless-knative-giac/","wordcount":3746},{"author":"余淮","categories":"SOFAStack","content":" 章耿，花名余淮，蚂蚁金服高级技术专家。 2007 年毕业后一直从事服务化相关的工作，最早在国家电网做电子商务平台 SOA 化的工作，之后在京东负责京东的服务化框架 JSF，目前在蚂蚁金服中间件服务与框架组负责应用框架及 SOFAStack 相关的工作。\n本文根据余淮在 2018 开源中国年终盛典的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 本次分享主要分为三部分： 蚂蚁金服服务化架构演进 蚂蚁金服微服务体系 蚂蚁金服 SOFAStack 的开源情况 1、蚂蚁金服服务化架构演进 在开始讲架构演进之前，我们先来看一组数据。 这是历年来的双十一数据图，柱状是双十一的交易额，从最初到20亿到去年的1682亿，今年是2135亿。而这个橙色的折线则是支付宝双十一 0 点的交易峰值，去年是 26.5w笔每秒，今年更高。从这两组数据可以看出蚂蚁的业务每年都是在高速增长，那技术面临的压力更是在不断的增长。但是最近几年，峰值虽然越来越大，但是大家有个体感，就是大促的购物体验更好了，再也不像以前系统会被大促搞挂，系统反而越来越稳了。\n而支撑这些数字的背后，是蚂蚁金融科技的一些核心技术，我们可以看到有三地五中心多活架构，分布式数据库 OceanBase，金融级分布式架构 SOFAStack，还有更多的一些黑科技，例如 Zoloz 生物识别，蚂蚁区块链，第五代智能风控引擎。\n相信大家都听过一句话 “罗马不是一天建成的”。蚂蚁金服科技的技术也不是最早就设计成这样，和所有的大公司发展一样，目前这些技术架构也是随着业务发展、系统的壮大，一步一步演进而来的。\n下面给大家介绍下蚂蚁金服的演进。\n这个是支付宝最早的架构示意图，可以看到当时支付宝只是电商后台的一个支付系统，是一个单体应用，里面简单的分了几个业务模块，连的也是一个数据库。但随着业务规模的不断扩展，单系统架构已经无法满足业务需求。\n所以支付宝就对大系统进行了拆分，将原来的一个单体应用内部的多个模块变成了多个独立的子系统，这算是典型的 SOA 化的架构。最开始系统之间是使用 F5 的硬件负载设备来做系统间的负载均衡，但由于 F5 设备存在单点的问题，所以后面就在中间引入一个注册中心的组件。服务提供者去注册中心注册服务，服务消费者去注册中心订阅服务列表，服务消费者通过软负载方式通过 RPC 框架直接调用服务提供者。这在现在看来是一种非常显而易见的服务化架构，但当时 07 年就采用这样的架构还是算比较超前的。 支付宝在做系统拆分的同时，对数据库也按子系统进行了垂直拆分。数据库的拆分就会引入分布式事务的问题，蚂蚁金服中间件就提供了基于 TCC 思想的 分布式事务组件 DTX。\n业务还是不断扩展，系统也越来越多，当系统节点到一定数量的时候，单个物理机房已经无法承受。另外考虑到同城容灾的问题，支付宝就在同城再扩建另外一个机房，通过专线部署为一个内部网络，然后将应用部署上去。同城多机房会引入一个跨机房远程访问的问题，相比同机房调用，这个延迟损耗一定是更高的。远程访问主要包括两种：RPC 调用和数据库访问。为了解决 RPC 跨机房调用的问题，支付宝的工程师选择的方案是在每个机房都部署注册中心，同机房优先调用本机房服务的方式，也就变成图中的部署模式。但是数据库跨机房访问的问题，在这个阶段并没有解决。\n为了解决上面的跨机房数据访问、数据库连接数瓶颈以及未来数据水平扩展的问题，蚂蚁的工程师们设计了一套单元化的架构，这是单元化的一个示意图。在没有单元化的时候，用户请求进入内部后，所有请求链路都是随机走的，例如图里的 S0 到 B1 到 C2 到 D0。首先蚂蚁的请求都是跟用户相关的，所以我们将数据按用户的维度进行水平分片，例如这张示意图我们将所有用户分为三组。然后我们将我们的应用也部署成三组独立的逻辑单元，每个逻辑单元的应用和数据都是独立的，相当于每个逻辑单元都处理1/3总量用户的数据。\n这个时候我们的三个不同终端的用户，不管是在PC端或者手机端或者扫二维码，当请求进入统一接入层的时候，接入层会按上面逻辑单元的分组规则，将用户请求转发到对应的逻辑单元，例如 user0 的请求转到 S0，后面的应用之间的调用、数据都只在逻辑单元 0 内。统一的 user1 只在逻辑单元 1，user2 也只到逻辑单元 2。\n我们把这种逻辑单元称之为 RegionZone。在实际的部署过程中，物理数据中心 IDC 和 逻辑单元的数量没有完全的对等关系。例如图中我们物理机房可以是两地三中心，而 RegionZone 则是分为五个。\n两地三中心是国家对金融机构的一个容灾指导方案，要求在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同时在异地（＞ 200KM ) 建立异地容灾中心。\n有了这套单元化的架构做指导思想，蚂蚁进行大规模的改造，包括应用改造、基础框架改造、数据中心的建设。\n机房建设完成后，同时蚂蚁金服将自己的用户分成了若干份，划了几个逻辑单元，分别部署进了不同的物理机房，同时完成大规模的数据迁移。\n从两地三中心到容灾能力更强大的三地五中心，我们只需要先进行第三个城市的机房建设，然后将部分 RegionZone 部署到第三个城市，最后再完成数据迁移和引流即可。\n每一个 RegionZone 在异地都有备份，当发生城市级的故障时，我们通过统一的管控中心将新的逻辑规则推送到统一接入层以及异地的备 RegionZone 时，就可以做到城市级的整体容灾切换。\n再后面我们基于单元化的思想做了更多弹性调度等能力，这里就不展开了。\n2015 年 9 月蚂蚁金融云对外正式发布，在今年 9 月的云栖大会，蚂蚁金融云正式升级为蚂蚁金融科技，并宣布技术全面对外开放，其中就包括金融级分布式架构 SOFAStack，左上角就是网址，感兴趣的朋友可以看下：https://tech.antfin.com/sofa\n云上的 SOFAStack 继承了蚂蚁金服内部的能力，有三大特点，分别是开放（全栈开放、开源共建）、云原生（异地多活、无限扩展）、金融级（资金安全、无损容灾），下面是一些核心能力大家可以看下。这一切就使得蚂蚁金服的微服务体系不仅仅在蚂蚁内部玩得转，也需要适应云上例如云原生、多租户等更复杂的场景。\n2、蚂蚁微服务体系 讲到微服务，大家就会看到或者脑子就跳出各种各样的词，例如 RPC 框架、服务安全、路由寻址等等。 除了这些以外，其实还有更多的服务归属、服务测试、服务编排等更多概念。\n那蚂蚁内部围绕微服务体系，也建设了很多的组件和框架对应这些微服务的概念点。\n这是一张蚂蚁内部微服务体系的一张简图，只列了部分主要组件，这些组件都是自研的，部分已经开源。可以看到有配置中心 DRM、注册中心 SOFARegistry，应用开发框架 SOFABoot，应用里的 RPC 框架、分布式链路跟踪组件 Tracer、监控度量组件 Lookout 等微服务组件，应用旁边是我们的 SOFAMosn，也就是 ServiceMesh 里的数据平面 SideCar，会将 RPC 里的路由、限流、鉴权等一些能力集成到这个组件里， …","date":1545030000,"description":"本文根据余淮在 2018 开源中国年终盛典的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/sofastack-oschina-2018/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e636d50f3f49170801c38118bf711adc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-oschina-2018/","publishdate":"2018-12-17T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofastack-oschina-2018/","summary":"章耿，花名余淮，蚂蚁金服高级技术专家。 2007 年毕业后一直从事服务化相关的工作，最早在国家电网做电子商务平台 SOA 化的工作，之后在京东负责京东的服务化","tags":["微服务","开源","实践"],"title":"蚂蚁金服微服务实践- 2018 开源中国年终盛典分享实录","type":"blog","url":"/sofastack.tech/blog/sofastack-oschina-2018/","wordcount":6551},{"author":"颜洄、丞一","categories":"SOFABolt","content":" 1. 前言 为了让中间件开发者们将更多的精力投入到产品的功能特性上，而不是重复的写通信层框架，蚂蚁中间件团队设计并实现了SOFABolt。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。蚂蚁中间件的同学这些年在微服务和消息中间件上解决了很多网络通信的问题，积累了很多经验，并将这些经验、解决方案沉淀到了SOFABolt这个项目中，希望能让更多需要使用网络通信的团队、开发者受益。目前SOFABolt已经运行在蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n2. 主要特性 SOFABolt核心功能包括三大块：\n 网络通信能力 协议框架 私有协议实现 网络通信能力 网络通信能力（remoting-core）可以理解为Netty的最佳实践，并额外进行了一些优化工作，包含：\n 基于Netty的高效的网络IO于线程模型的应用 链接管理（无锁建连、定时断连、自动重连） 通信模型（oneway、sync、callback、future） 超时控制 批量解包和批量提交处理 心跳于IDLE机制 协议框架 协议框架（protocol-skeleton）包含命令处理器、编解码器等，是底层通信能力之上，具体私有协议之下，连接通信能力和私有协议的中间层。网络通信层是SOFABolt对Netty的封装和功能增强，协议框架则是SOFABolt对网络请求处理流程的抽象，是用户可以不关心底层细节快速实现自己的处理器来完成网络请求的处理逻辑，是用户可以进行拓展来实现自定义的私有协议的基础，也是本篇文章分析的内容。\n私有协议实现 由于性能、安全性等等的原因，很多中间件都会采用私有协议进行通信。SOFABolt除了提供基础的通信能力、协议框架之外，还提供了默认的RPC协议的实现，这样它就是一个完整的通信框架，用户可以不关心协议而直接上手使用。本篇文章主要分析SOFABolt的协议框架的设计和实现，不展开对SOFABolt中的RPC协议实现做介绍。\n3. 协议框架 协议框架整体如下：\n Command：协议命令，通讯数据的顶层抽象。从交互的角度可以分为Request（请求）于Response（响应），从功能的角度，分为负载命令（交换业务数据）和控制命令（进行系统的管理、协调等）。 CommandEncoder/CommandDecoder：协议命令的编解码器，自定义协议实现的基础，编解码器完成对象和字节数组之间的相互转换。 CommandHandler：协议命令的处理器，命令处理入口，负责分发、处理命令。 CommandFactory：协议命令工厂类，负责创建协议命令对象。 HeartbeatTrigger：心跳的处理器，用户用户拓展特定的心跳机制的处理。 下面以SOFABolt中默认实现的RPC协议为例来介绍SOFABolt协议框架的实现。 3.1 请求的处理流程 一个请求处理流程大致如下：\n 通过CommandFactory构建请求对象 通过CommandEncoder对请求对象进行编码，写入到网络连接 服务端从连接中读取数据，通过CommandDecoder解析成请求对象 CommandHandler接收请求对象，进行分发和处理 CommandFactory是一个工厂类，比较简单，不展开介绍。编解码相关内容见《SOFABolt编解码机制》。下面介绍一下CommandHandler对请求的分发和处理。\n上面是SOFABolt中RpcHandler的代码片段，这段代码是命令处理的入口：\n 首先从连接的上下文中获取使用的协议的版本ProtocolCode 再根据ProtocolCode从ProtocolManager中获取具体的协议 之后从协议中获取CommandHandler，并构造请求的上下文信息和请求的对象（代码片段中的msg）提交处理 上面的处理逻辑中透露出一个信息：SOFABolt支持同时运行多个版本的协议，通过ProtocolCode来区分协议。这一点可以使得系统在做升级或重构时，需要同时支持新老系统不同协议时变得简单。\n上面是CommandHandler的代码片段，透露出的信息是SOFABolt支持批量提交请求，这在《SOFABolt编解码机制》一文中也有部分介绍。而具体的process流程如下：\n通过Command对象获取CommandCode，根据CommandCode获取对应的RemotingProcessor进行处理。 CommandCode是一个接口，只有一个返回short的value()方法，表示Command的具体类型，每个请求都需要有自己的CommandCode来标识自己的类型。框架通过一个Map来维护CommandCode和RemotingProcessor的关系，每个CommandCode需要有对应的RemotingProcessor进行处理，一个RemotingProcessor可以处理多个CommandCode的请求。\n再往下看一层，请求会被提交到RemotingProcessor中处理。上面是RpcRequestProcessor处理请求的代码片段，处理流程中会通过cmd.getRequestClass()来获取请求的对象的Class名称，再获取对应的UserProcess进行处理（具体处理不再上面的代码片段中）。 对用户来说，只需要实现自己的Command对象、实现自己的UserProcessor并注册到ProcessorManager中，就可以完成自己的网络通信。 以上是一个请求在SOFABolt的协议框架下的处理流程和核心代码的分析。\n3.2 协议框架的拓展机制 通过对请求处理流程的分析可以感受到SOFABolt的协议框架是支持多协议版本运行，能直接使用，也支持进行拓展来实现更丰富和定制化的功能。下面具体介绍SOFABolt的拓展机制。\n上图是RemotingCommand在处理过程中的路由示意图。第一层路由根据ProtocolCode进行，第二层路由根据CmdCode进行，第三层路由则根据RequestClass进行。用户可以在每一层进行扩展来实现自己的处理。 这种设计具有很好的拓展性和灵活性，ProtocolCode用于区分“大版本”的协议，适用于协议发生较大的变化的场景。CmdCode则标识请求类型，比如在RPC场景中CmdCode可能就两个：RPC_REQUEST、RPC_RESPONSE，而在消息场景中CmdCode可能会更丰富一些，比如有发送消息、批量发送消息、投递消息等等。RequestClass是Command上承载的数据的类型，用户根据不同的类名进行不同的业务逻辑的实行。\n实际应用中，以RPC的场景为例，用户更多的是去实现UserProcessor来完成不同的业务逻辑的处理。而在消息的场景中，因为消息承载的是二进制的数据，所以请求的数据类型是固定的，系统更多的是拓展CmdCode来执行不同类型的请求的处理，比如心跳请求的处理、写入消息的处理、批量写入消息的处理等等。SOFABolt协议框架的设计和实现，具备较好的可拓展性，使其能应用于蚂蚁 …","date":1544091600,"description":"本文是对蚂蚁金服开源通信框架 SOFABolt 的协议框架解析。","dir":"blog/sofa-bolt-framework-deep-dive/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"67335ca275995497a5f28340cb13f45b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","summary":"1. 前言 为了让中间件开发者们将更多的精力投入到产品的功能特性上，而不是重复的写通信层框架，蚂蚁中间件团队设计并实现了SOFABolt。 Bolt 名字取","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架 SOFABolt 协议框架解析","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","wordcount":3889},{"author":"鲁道","categories":"SOFABolt","content":" 前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将重点分析 SOFABolt 的序列化机制。\n我们知道，但凡在网络中传输数据，都涉及到序列化以及反序列化。即将数据编码成字节，再把字节解码成数据的过程。\n例如在 RPC 框架中，一个重要的性能优化点是序列化机制的设计。即如何为服务消费者和和服务提供者提供灵活的，高性能的序列化器。\n这里说的序列化器，不仅仅是指“对象”的序列化器，例如 Hessian，Protostuff，JDK 原生这种“对象”级别的序列化器，而是指“协议”级别的序列化器，“对象”的序列化只是其中一部分。通常“协议”级别的序列化器包含更多的信息。\n下面我们将先从 SOFABolt 的设计及实现入手，进而分析 SOFABolt 详细的序列化与分序列化流程，最后介绍 SOFABolt 序列化扩展。\n设计及实现 一个优秀的网络通信框架，必然要有一个灵活的，高性能的序列化机制。那么，SOFABolt 序列化机制的设计目标是什么呢？具体又是如何设计的呢？\n首先说灵活，灵活指的是，框架的使用方（这里指的是网络通信框架的使用方，例如 RPC，消息中心等中间件）能够自定义自己的实现，即用户决定使用什么类型的序列化以及怎么序列化。\n再说高效，序列化和反序列化事实上是一个重量级的操作，阿里 HSF 作者毕玄在著名的 NFS-RPC框架优化过程（从37k到168k） 文章中提到，其优化 RPC 传输性能的第一步就是调整反序列化操作，从而将 TPS 从 37k 提升到 56k。之后又通过更换对象序列化器，又将 TPS 提升了将近 10k。由此可见，合理地设计序列化机制对性能的影响十分巨大。\n而 SOFABolt 和 HSF 有着亲密的血缘关系，不但有着 HSF 的高性能，甚至在某些地方，优化的更为彻底。\n我们现在可以看看 SOFABolt 序列化设计。\n接口设计 SOFABolt 设计了两个接口：\n Serializer 该接口定义 serialize 方法和 deserialize 方法，用于对象的序列化和反序列化。 CustomSerializer 该接口定义了很多方法，主要针对自定义协议中的 header 和 content 进行序列化和反序列化。同时提供上下文，以精细的控制时机。 同时，从框架设计的角度说，他们可以称之为 “核心域”， 他们也被对应的 “服务域” 进行管理。\n这里解释一下服务域和核心域，在框架设计里，通常会有“核心域”，“服务域”， “会话域” 这三部分组成。\n例如在 Spring 中，Bean 就是核心域，是核心领域模型，所有其他模型都向其靠拢；而 BeanFactory 是服务域，即服务“核心域”的模型，通常长期存在于系统中，且是单例；“会话域” 指的是一次会话产生的对象，会话结束则对象销毁，例如 Request，Response。\n在 SOFABolt 序列化机制中，Serializer 和 CustomSerializer 可以认为是核心域，同时，也有服务于他们的 “服务域”，即 SerializerManager 和 CustomSerializerManager。“会话域” RpcCommand 依赖 “服务域” 获取 “核心域” 实例。\nUML 设计图如下：\n其中红色部分就是 SOFABolt 序列化机制的核心接口，同时也是用户的扩展接口，他们被各自的 Manager 服务域进行管理，最后，会话域 RpcCommand 依赖着 Manager 以获取序列化组件。\n这两个接口的使用场景通常在数据被 协议编解码器 编码之前或解码之后，进行处理。\n例如在发送数据之前，协议编码器 根据通信协议（如 bolt 协议）进行编码，编码之前，用户需要将数据的具体内容进行序列化，协议编解码器 再进行更详细的编码。\n同样，协议解码器 在接收到 Socket 发送来的字节后，根据协议将字节解码成对象，但是，对象的内容还是字节，需要用户进行反序列化。\n一个比较简单的流程图就是这样的:\n上图中，假设场景是 Client 发送数据给 Server，那么，编解码器负责将字节流解码成 Command 对象，序列化器负责将 Command 对象里的内容反序列化成业务对象，从设计模式的角度看，这里是 GOF 中 “命令模式”和“职责链模式”的组合设计。\n看完了设计，再看看实现。\n接口实现 我们可以看看这两个接口的实现。\n Serializer Serializer 接口在 SOFABolt 中已有默认实现，即 HessianSerializer，目前使用的是 hessian-3.3.0 版本。通过一个 SerializerManager 管理器进行管理。注意，这个管理器内部使用的是数组，而不是 Map，这在上文毕玄的文章也曾提到：通过使用数组替换成 Map，NFS-RPC 框架的 TPS 从 153k 提升到 160k。事实上，任何对性能非常敏感的框架，能用数组就绝不用 Map，例如 Netty 的 FastThreadLocal，也是如此。\n当然，Serializer 接口用户也是可以扩展的，例如使用 protostuff，FastJson，kryo 等，扩展后，通过 SerializerManager 可以将自己的序列化器添加到 SOFABolt 中。注意：这里的序列化 type 实际就是上面提到的数组的下标，所以不能和其他序列化器的下标有冲突。\n CustomSerializer 再说 CustomSerializer，这个接口也是有默认实现的，用户也可以选择自己实现，我们这里以 SOFARPC 为例。\nSOFARPC 在其扩展模块 sofa-rpc-remoting-bolt 中，通过实现 CustomSerializer 接口，自己实现了序列化 header，content。\n这里稍微扩展讲一下 header 和 content。实际上，header 和 content 类似 http 协议的消息头和消息体，header 和 content 中到底存放什么内容，取决于协议设计者。\n例如在 SOFARPC 的协议中，header 里存放的是一些扩展属性和元信息上下文。而 content 中存放的则是主要的一些信息，比如 request 对象，request 对象里就存放了 RPC 调用中常用信息了，例如参数，类型，方法名称。\n同时，CustomSerializer 接口定义的方法中，提供了 InvokeContext 上下文，例如是否泛化调用等信息，当进行序列化时，将是否泛型的信息放入上下文，反序列化时，再从上下文中取出该属性，即可正确处理泛化调用。\n注意，如果用户已经自己实现了 CustomSerializer 接口，那么 SOFABolt 的 SerializerManager 中设置的序列化器将不起作用！因为 SOFABolt 优先使用用户的序列化器。\n具体代码如下：\n行文至此，讨论的都是“灵活”这个设计，即用户既可以使用 SOFABolt …","date":1544091600,"description":"SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架，本文将重点分析 SOFABolt 的序列化机制。","dir":"blog/sofa-bolt-serialization-deep-dive/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2145bb681760cdf3d1953bf4ed75fa60","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","summary":"前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之序列化机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","wordcount":4630},{"author":"水寒","categories":"SOFABolt","content":" 基础介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生。 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，积累了很多经验，并持续的进行着优化和完善，我们希望能把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。 目前该产品已经运用在了蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n前言 SOFABolt 提供了设计良好、使用便捷的编解码功能。本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。欢迎大家与我们讨论交流。\n编解码介绍 每个网络应用程序都必须定义如何解析在两个节点之间来回传输的原始字节，以及如何将其和目标应用程序的数据格式做相互转换。在一个成熟的通信框架中，我们通常都会通过私有通信协议来描述这种定义，通过编解码技术将理论上的私有通信协议转化为实践。\n通过编解码技术，我们可以方便的做一些逻辑，例如双方可以方便的统一序列化与反序列化方式、解决 TCP 拆包粘包问题等。\n下面，我们先来看一下 TCP 粘包拆包问题的产生，然后分析 Netty 是如何解决粘包拆包问题的，最后分析 SOFABolt 是如何解决粘包拆包问题的。\nTCP 粘包拆包问题 如上图所示，三种拆包原因见黄色标签说明；两种粘包原因见蓝色标签说明。TCP 本身是面向流的，它无法从源源不断涌来的数据流中拆分出或者合并出有意义的信息，通常可以通过以下几种方式来解决：\n 基于分隔符协议：使用定义的字符来标记一个消息的结尾，在编码的时候我们在消息尾部添加指定的分隔符，在解码的时候根据分隔符来拆分或者合并消息。Netty 提供了两种基于分隔符协议的解码器 LineBasedFrameDecoder 和 DelimiterBasedFrameDecoder。LineBasedFrameDecoder 指定以 \\n 或者 \\r\\n 作为消息的分隔符；DelimiterBasedFrameDecoder 使用用户自定义的分隔符来标记消息的结尾。 基于定长消息协议：每一个消息在编码的时候都使用固定的长度，在解码的时候根据这个长度进行消息的拆分和合并。Netty 提供了 FixedLengthFrameDecoder 解码器来实现定长消息解码。 基于变长消息协议：每一个消息分为消息头和消息体两部分，在编码时，将消息体的长度设置到消息头部，在解码的时候，首先解析出消息头部的长度信息，之后拆分或合并出该长度的消息体。Netty 提供了 LengthFieldBasedFrameDecoder 来实现变长消息协议解码。 基于私有通信协议：Netty 提供了 MessageToByteEncoder 和 ByteToMessageDecoder 两个抽象类，这两个抽象类提供了基本的编解码模板。用户可以通过继承这两个类来实现自定义的编解码器。SOFABolt 通过继承 MessageToByteEncoder 实现了自定义的编码器，通过继承修改版的 ByteToMessageDecoder 来实现了解码器。对于处理 TCP 粘包拆包问题，SOFABolt 实际上也是使用变长消息协议，SOFABolt 的私有通信协议将消息体分为三部分 className、header、body，在消息头对应的提供了 classLen、headerLen、bodyContent 分别标识三部分的长度，之后就可以基于这三个长度信息进行消息的拆分和合并。 对于一个成熟的 rpc 框架或者通信框架来讲，编解码器不仅仅是要处理粘包拆包问题，还要实现一些特有的需求，所以必须制定一些私有通信协议，下面来看一下 SOFABolt 的私有通信协议的设计。\nSOFABolt 私有通信协议的设计 以下分析以 SOFABolt 1.5.1 版本为例。SOFABolt 定义了两种协议 RpcProtocol 和 RpcProtocolV2。针对这两种协议，提供了两组不同的编解码器。\n RpcProtocol 协议定义 请求命令（协议头长度：22 byte） ProtocolCode ：这个字段是必须的。因为需要根据 ProtocolCode 来进入不同的核心编解码器。该字段可以在想换协议的时候，方便的进行更换。 RequestType ：请求类型，request / response / oneway 三者之一。oneway 之所以需要单独设置，是因为在处理响应时，需要做特殊判断，来控制响应是否回传。 CommandCode ：请求命令类型，request / response / heartbeat 三者之一。 CommandVersion ：请求命令版本号。该字段用来区分请求命令的不同版本。如果修改 Command 版本，不修改协议，那么就是纯粹代码重构的需求；除此情况，Command 的版本升级，往往会同步做协议的升级。 RequestId ：请求 ID，该字段主要用于异步请求时，保留请求存根使用，便于响应回来时触发回调。另外，在日志打印与问题调试时，也需要该字段。 Codec ：序列化器。该字段用于保存在做业务的序列化时，使用的是哪种序列化器。通信框架不限定序列化方式，可以方便的扩展。 Timeout ：超时字段，客户端发起请求时，所设置的超时时间。 ClassLen ：业务请求类名长度 HeaderLen ：业务请求头长度 ContentLen ：业务请求体长度 ClassName ：业务请求类名。需要注意类名传输的时候，务必指定字符集，不要依赖系统的默认字符集。曾经线上的机器，因为运维误操作，默认的字符集被修改，导致字符的传输出现编解码问题。而我们的通信框架指定了默认字符集，因此躲过一劫。 HeaderContent ：业务请求头 BodyContent ：业务请求体 响应命令（协议头长度：20 byte） ResponseStatus ：响应码。从字段精简的角度，我们不可能每次响应都带上完整的异常栈给客户端排查问题，因此，我们会定义一些响应码，通过编号进行网络传输，方便客户端定位问题。 RpcProtocolV2 协议定义 请求命令（协议头长度：24 byte） ProtocolVersion ：确定了某一种通信协议后，我们还需要考虑协议的微小调整需求，因此需要增加一个 version 的字段，方便在协议上追加新的字段 Switch ：协议开关，用于一些协议级别的开关控制，比如 CRC 校验， …","date":1544091600,"description":"本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。","dir":"blog/sofa-bolt-codec-deep-dive/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9383bfa0b8c9975e3d4b2ed4bc01a593","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","summary":"基础介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之编解码机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","wordcount":3909},{"author":"胡萝卜、丞一","categories":"SOFABolt","content":" 前言 SOFABolt 是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将分析SOFABolt的超时控制和心跳机制。\n超时 在程序中，超时一般指的是程序在特定的等待时间内没有得到响应，网络通信问题、程序BUG等等都会引起超时。系统引入超时机制往往是为了解决资源的问题，比如一个同步RPC请求，在网络不稳定的情况下可能一直无法得到响应，那么请求线程将一直等待结果而无法执行其它任务，最终导致所有线程资源耗尽。超时机制正是为了解决这样的问题，在特定的等待时间之后触发一个“超时事件”来释放资源。\n在一个网络通信框架中，超时问题无处不在，连接的建立、数据的读写都可能遇到超时问题。并且网络通信框架作为分布式系统的底层组件，需要管理大量的连接，如何建立一个高效的超时处理机制就成为了一个问题。\n时间轮（TimeWheel） 在网络通信框架中动辄管理上万的连接，每个连接上都有很多的超时任务，如果每个超时任务都启动一个java.util.Timer，不仅低效而且会占用大量的资源。George Varghese 和 Tony Lauck在1996年发表了一篇论文：《Hashed and Hierarchical Timing Wheels: EfficientData Structures for Implementing a Timer Facility》来高效的管理和维护大量的定时任务。\n时间轮其实就是一种环形的数据结构，可以理解为时钟，每个格子代表一段时间，每次指针跳动一格就表示一段时间的流逝（就像时钟分为60格，秒针没跳动一格代表一秒钟）。时间轮每一格上都是一个链表，表示对应时间对应的超时任务，每次指针跳动到对应的格子上则执行链表中的超时任务。时间轮只需要一个线程执行指针的“跳动”来触发超时任务，且超时任务的插入和取消都是O(1)的操作，显然比java.util.Timer的方式要高效的多。\nSOFABolt的超时控制机制 如上图所示，SOFABolt中支持四中调用方式：\n oneway：不关心调用结果，所以不需要等待响应，那么就没有超时 sync：同步调用，在调用线程中等待响应 future：异步调用，返回future，由用户从future中获取结果 callback：异步调用，异步执行用户的callback 在oneway调用中，因为并不关心响应结果，所以没有超时的概念。下面具体介绍SOFABolt中同步调用（sync）和异步调用（future\\callback）的超时机制实现。 同步调用的超时控制实现 同步调用中，每一次调用都会阻塞调用线程等待服务端的响应，这种场景下同一时刻产生最大的超时任务取决于调用线程的数量。线程资源是非常昂贵的，用户的线程数是相对可控的，所以这种场景下，SOFABolt使用简单的java.util.concurrent.CountDownLatch来实现超时任务的触发。\nSOFABolt同步调用的代码如上，核心逻辑是：\n 创建InvokeFuture 在Netty的ChannelFuture中添加Listener，在写入操作失败的情况下通过future.putResponse方法修改Future状态（正常服务端响应也是通过future.putResponse来改变InvokeFuture的状态的，这个流程不展开说明） 写入出现异常的情况下也是通过future.putResponse方法修改Future状态 通过future.waitResponse来执行等待响应 其中和超时相关的是future.waitResponse的调用，InvokeFuture内部通过java.util.concurrent.CountDownLatch来实现超时触发。 java.util.concurrent.CountDownLatch#await(timeout, timeoutUnit) 方法实现了等待一段时间的逻辑，并且通过countDown方法来提前中断等待，SOFABolt中InvokeFuture通过构建new CountDownLatch(1)的实例，并将await和countDown方法包装为awaitResponse和putResponse来实现同步调用的超时控制。\n异步调用的超时控制实现 相对于同步调用，异步调用并不会阻塞调用线程，那么超时任务的数量并不受限于线程对的数量，用户可能通过一个线程来触发量大的请求，从而产生大量的定时任务。那么我们需要一个机制来管理大量的定时任务，并且作为系统底层的通信框架，需要保证这个机制尽量少的占用资源。上文已经提到TimeWheel是一个非常适合于这种场景的数据结构。\nNetty中实现了TimeWheel数据结构：io.netty.util.HashedWheelTimer，SOFABolt异步调用的超时控制直接依赖于Netty的io.netty.util.HashedWheelTimer实现。\nFuture模式和Callback模式在超时控制机制上一致的，下面以Callback为例分析异步调用的超时控制机制。\nSOFABolt异步调用的代码如上，核心逻辑是：\n 创建InvokeFuture 创建Timeout实例，Timeout实例的run方法中通过future.putResponse来修改InvokeFuture的状态 在Netty的ChannelFuture中添加Listener，在写入操作失败的情况下通过future.cancelTimeout来取消超时任务，通过future.putResponse来修改InvokeFuture的状态 在写入异常的情况下同样通过future.cancelTimeout来取消超时任务，通过future.putResponse来修改InvokeFuture的状态 在异步调用的实现中，通过Timeout来触发超时任务，相当于同步调用中的java.util.concurrent.CountDownLatch#await(timeout, timeoutUnit)。Future#cancelTimeout()方法则是调用了Timeout的cancel来取消超时任务，相当于同步调用中通过 java.util.concurrent.CountDownLatch#countDown() 来提前结束超时任务。具体超时任务的管理则全部委托给了Netty的Timer实现。 另外值得注意的一点是SOFABolt在使用Netty的Timer时采用了单例的模式，因为一般情况下使用一个Timer管理所有的超时任务即可，这样可以节省系统的开销。 Fail-Fast机制 以上关于SOFABolt的超时机制介绍都是关于SOFABolt客户端如何完成高效的超时任务管理的，其实在SOFABolt的服务端同样针对超时的场景做了优化。\n客户端为了应对没有响应的情况，增加了超时机制，那么就可能存在服务端返回一个响应但是客户端在收到这个响应之前已经认为请求超时了，移除了相关的请求上下文，那么这个响应对客户端来说就没有意义 …","date":1544091600,"description":"本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。","dir":"blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8f3ab1ecc952a0fc5ea40576e8b57471","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","summary":"前言 SOFABolt 是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之超时控制机制及心跳机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","wordcount":4303},{"author":"任展","categories":"SOFABolt","content":" 前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将重点分析 SOFABolt 的连接管理功能。\n我们知道，一次 tcp 请求大致分为三个步骤：建立连接、通信、关闭连接。每次建立新连接都会经历三次握手，中间包含三次网络传输，对于高并发的系统，这是一笔不小的负担；关闭连接同样如此。为了减少每次网络调用请求的开销，对连接进行管理、复用，可以极大的提高系统的性能。\n下面我们将介绍 SOFABolt 在连接管理的实现，包括连接生命周期管理、定时断连及自动重连等。\n设计抽象 首先我们将会介绍 SOFABolt 对连接的封装抽象。\n连接封装 SOFABolt 中定义了一个基础的连接类 \u0026amp;ndash; Connection:\n省去 AtributeKey 类型定义以及 Log 配置，以上是Connection中所有的成员变量。包括几个方面:\n 连接：Channel、Url 版本：protocolCode、version 调用：invokeFutureMap 附着：attributes 引用：referenceCount、id2PoolKey、poolKeys 这里提一下 protocolCode 和 version，版本信息会被携带至对端，用于连接的协商。总的来说，通过对于 Channel 的包装，Connection 提供了丰富的上下文及引用信息，是 SOFABolt 连接管理的直接对象。\n连接事件 SOFABolt 定义了连接事件和事件监听器用于处理连接对象。ConnectionEventType 定义了三种事件类型：CONNECT, CLOSE 和 EXCEPTION. 针对不同的连接事件类型，我们可以通过事件监听器 \u0026amp;ndash; ConnectionEventListener 来进行处理，下面来看一下 ConnectionEventListener 类：\n监听器定义了两个方法 onEvent 和 addConnectionEventProcessor, 分别是触发事件和添加事件处理器。整个监听器采用一个 HashMap 来存储事件类型及其对应的处理器集合。在触发相关连接事件后，会遍历处理器集合并调用处理器执行。\nSOFABolt 的连接管理集中在 ConnectionEventHandler 中处理，他继承了 ChannelDuplexHandler，是标准的用来处理Connection连接对象并进行日志打印的一个处理器。先来看一下成员组成：\n其中连接事件监听器上文已经提及，剩下的几个成员从名称上也通俗易懂，先简单介绍一下，后续会详细地展开：\n 连接管理器：管理连接对象，包括创建、添加、删除、检查是否可用等等 连接事件监听器：监听连接事件的触发，然后执行对应的逻辑 连接事件执行器：包装后的线程池，用于异步触发连接事件监听器来处理对应的连接事件，值得一提的是，这个线程池只有一个线程。 重连管理器：顾名思义，管理重连的Url对象以及执行重连任务 全局开关：全局的设置，比如是否需要管理连接对象、是否需要执行重连任务等等 代码中方法都比较简单，大部分的处理逻辑围绕 Connection 对象展开，主要是维护有关本 Channel 对象的 Connection 对象的生命周期(包括connect、close等事件)。下面着重分析两个方法：\nhannelInactive 方法是在连接断开前触发的方法，在 SOFABolt 里的处理逻辑中，会根据globalSwitch 中 CONN_RECONNECT_SWITCH 的开关状态来判定是否开启重连的任务。除此之外，会在最后触发该 Connection 对象的 CLOSE 事件。这个触发事件是在异步线程中执行的，也就是上文提到的连接事件执行器。\n另一个是 userEventTriggered 方法， 用来触发自定义的用户事件，通过查看本方法的调用位置，可以得知，该方法是在连接建立的最初被触发的，一个简单的例子可以在RpcServer类中找到：\n在连接建立触发 fireUserEventTriggered 方法后，我们就开始执行对应此方法中的逻辑，也可以看到，在判定是 CONNECT 事件后，通过attr得到绑定在Channel的Connection对象，然后就同 channelInactive 方法一样，触发 CONNECT 事件异步执行对应的处理器逻辑。\n连接管理 下面来介绍 ConnectionManager，SOFABolt 提供了默认的实现类 DefaultConnectionManager类。顾名思义，主要负责连接对象的管理：\n 通过工厂创建 Connection 连接对象 通过注入的选择策略进行 Connection 连接的选择 管理创建和添加的 Connection 对象和 ConnectionPool 连接池对象（包括检查 Connection 对象、维护 ConnectionPool 的健壮性） 控制 Connection 对象的心跳打开与关闭 创建连接 ConnectionFactory 用于创建连接对象，SOFABolt 提供了两个实现类： DefaultConnectionFactory 和 RpcConnectionFactory。这个工厂类执行了客户端所有 Connection 对象的创建工作，代码也比较简单：\n注意到了吗，在创建完毕 Connection 对象后，执行了 fireUserEventTriggered 方法，这样就保证了每一个 Connection 对象在创建之后都会去触发 CONNECT 事件。\n选择连接 ConnectionSelectStrategy 选择策略的默认实现是随机策略 RandomSelectStrategy, 在执行选择连接时大致分为两步：\n 在开启CONN_MONITOR_SWITCH监控时，会从该连接池所有的连接中做一个简单的filter操作，把CONN_SERVICE_STATUS为ON的连接挑选出来，作为选择池。如果没有开启监控，那么选择池就是连接池。 执行挑选策略，获取选择池中的一个连接。 管理连接和连接池 管理连接和连接池是 ConnectionManager 最主要的作用，用来进行连接和连接池的生命周期管理，包括添加、删除、检查健康、恢复连接数等功能。下面先看一个在添加中常见的方法，用来获取一个连接池对象或者创建一个，限于篇幅，这里不贴代码，有兴趣的同学可以在 GitHub 上查看源码。在执行创建连接池对象时，会有两种逻辑:\n 返回空的连接池 返回一个初始化过的连接池(有一定的连接数) 这两种逻辑其实对应的是两种需求，第一个对应连接已经创建好然后放入连接池的流程，第二个则是对应通过 Url 来创建一个连接池并且在连接池中做新建连接的流程。那么对于第二种情况，由于建立连接需要耗时且有可能抛出异常，所以 ConnectionManager 允许重试两次。\n下面来说说对于连接和连接池的维护方面的功能， …","date":1544091600,"description":"本文将重点分析 SOFABolt 的连接管理功能。","dir":"blog/sofa-blot-connection-management-deep-dive/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"99733a6333604b8aeb8ada37d5705d36","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","summary":"前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之连接管理剖析","type":"blog","url":"/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","wordcount":3490},{"author":"奕杉","categories":"Service Mesh","content":" 朵晓东，花名奕杉，蚂蚁金服高级技术专家。专注企业云计算技术及产品，蚂蚁金融云 PaaS 创始团队核心成员，Antstack 网络产品负责人。开源爱好者，Apache Kylin 创始团队核心成员；SOFAMesh 创始团队核心成员，SOFAMosn 项目负责人。 本文根据晓东在 GIAC 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，我是蚂蚁金服系统部的高级技术专家奕杉，今天分享的内容是: 《蚂蚁金服在 ServiceMesh 推进落地过程中对新型网络代理的思考和实践》\n内容结构： 主要的分享顺序：\n 背景概述 架构设计及功能特性 技术案例 总结展望 1、背景、概览 ServiceMesh 作为云原生之上的服务网格技术在今年引起了业界的广泛关注，首先我们来看一下目前 ServiceMesh 数据平面的一些方案。\n最为大家熟知的是老牌七层代理 Nginx 和 ISTIO 原生的数据平面 Envoy。Nginx 早已在国内外广泛使用，近两年积极探索 K8S、ServiceMesh 微服务场景，并推出了与 ISTIO 集成的微服务解决方案，试图扩展其场景边界，拿下新的领域，从单纯的7层流量代理到云原生时代的智能数据平面转型。但目前看 “NgMesh”研发不够活跃，已知的使用方也不多。Envoy 作为 Google 和 Lyft联合开发的 ISTIO 原生数据平面产品，近两年借助 ServiceMesh 微服务场景快速打开了市场，并在一些互联网公司推广使用，同时引入了一批开发者进行 API 网关等功能网关的开发，发展势头非常好。\n其次 LINKERD 是基于 Rust 的一种高性能数据平面，但其发展空间受到了 Envoy 挤压，业界使用的公司也比较有限。\n蚂蚁金服基于自身诉求自研了基于 Golang 的数据平面 SOFAMosn（后简称MOSN），并在蚂蚁、UC 等公司落地使用。 同时对业界开源，提供了一种新的数据平面产品选择。\n此外国内的华为、新浪等公司都基于自身场景提出了数据平面方案并先后进行了开源，数据平面竞争已经从独霸业界的基于 Nginx 二开方案逐步转变为目前的多样化产品同场竞技的局面。\n为什么众多大厂纷纷投入研发数据平面呢？\n我个人认为新生技术栈、云原生、微服务快速发展等契机对数据平面提出了场景多样化、功能服务化、云原生亲和等多重挑战。\n以往从未像现在这样对数据平面提出过如此多的要求：\n 数据平面需要执行部署运维中的流量切换； 需要提供云亲和的细粒度流量调度功能； 需要提供微服务亲和的服务发现、路由组网特性； 需要以云原生的方式感知资源； 需要支撑服务粒度、高度自定义的压测、故障测试、线上灰度流量管理； 需要提供链路级、服务级的安全隔离保护，需要支持多种语言、多种协议的转换分发能力； 需要能享受系统层面、硬件层面的红利； 需要为复杂的运维架构（如蚂蚁的 LDC 等）提供可扩展的流量调拨能力等等； 当然根据每个公司的业务场景可能还有其他的因素。 最后，如何要将这些能力都汇聚在统一的数据平面产品上，弥合南北向、东西向数据平面由于技术栈、团队等差异带来的鸿沟，变成了另一个更为复杂的问题。这里所提到的问题中任何一点扩展开来都可以是一个丰富独立的 Topic，受限于篇幅本次分享只能介绍我们在解决这些问题中的一小部分思考和实践。\n2、SOFAMesh 架构 \u0026amp;amp; 重点特性 首先，蚂蚁已经将基于 ISTIO 的 ServiceMesh 方案 \u0026amp;ldquo;SOFAMesh\u0026amp;rdquo; 开源，在控制面我们选择克隆 ISTIO 官方版本并研发符合蚂蚁需求的控制面，在数据面我们选择使用 Golang 研发数据平面 MOSN，目前已经支持了微服务场景所需的大量常用功能。\n这里我根据 ISTIO 的 Task 文档总结了目前 SOFAMesh 支持的一些能力，如：透明拦截适配，细粒度的流控，故障注入，双向链路加密等。对于一些暂时存疑的功能，如 Mixer Check 等，暂时没有支持。目前 SOFAMesh 已在 UC 生产环境落地使用，满足了 Sidecar、Ingress、Egress 多种场景的使用需求。在这里附上 SOFAMesh，SOFAMosn 的 Github 地址，也欢迎大家使用交流。\nSOFAMesh: https://github.com/alipay/sofa-mesh SOFAMosn: https://github.com/alipay/sofa-mosn\n再来看看蚂蚁内部，由于目前蚂蚁生产环境尚未大量铺开K8S，并且已经存在一套完善的管控技术体系，加上目前ISTIO 的性能和稳定性还不满足大规模微服务场景等原因，我们暂时没有选择直接升级到 ISTIO，而是通过优先落地Sidecar 的方式来赢得 ServiceMesh 解决方案带来的红利。在蚂蚁内部，MOSN 接管了SOFABoot 应用，代理了服务发现、路由/负载均衡、通信等工作，构成了微服务网格，通过自有的中间件及管控平面进行微服务的管理、治理。同时，我们积极的推进 MOSN 与 SOFA中间件，网络接入层，安全防护及监控体系的整合，以提供更统一更强大的数据平面。\n接下来我将介绍 MOSN 支持多协议的方案。\n为了在内部快速落地试错，我们首先支持了内部使用最广泛的 SOFARPC 协议，并对其进行了深度优化。随后我们根据 UC Mesh 化推进遇到的普遍问题提出了 XProtocol 方案，以在不解包的场景下提供路由能力。最后我们深度改造了三方 HTTP/1.1 实现及官方 HTTP/2.0 实现。到目前为止，MOSN 已提供了多种协议的支持。同时 MOSN 提供了两种自定义协议的能力支持使用者通过扩展的方式自定义协议实现，满足需要解包、不需要解包的协议扩展需求。\n除协议之外，性能是大家比较关心的另一个问题。为了提供满足生产要求的7层转发性能，我们在 IO、协议、内存、协程、网络处理等方面进行了优化，从目前通过 SOFARPC 通信应用的上线情况来看可以满足生产使用要求，在案例分析中我将展示一些性能数据，后续我们也将继续推进性能优化，以达到更好的性能。\n在安全能力上，SOFAMesh 支持 mTLS，并在蚂蚁内部集成蚂蚁内部的 KMS 完成了 mTLS 落地，同时 RBAC 功能在研发中，此外WAF、流量镜像能功能也在规划中。\n在蚂蚁内部基于 MOSN 的网关产品正在研发中，将会在稳定验证后开源。网关场景相对于 Sidecar 场景有一些特性需求，比如说一般会 Hold 住大量长链接，比如说会根据请求内容动态选择后端应用，由于网关可能代理了不同的后端应用，就会需要动态选择后端协议。此外还有一些网关类的通用能力需求，如签名，授权，限流等。\n为了能基于开源版建设蚂蚁内部的 Sidecar 及网关产品，我们充分考虑了开源版 MOSN 的扩展性，在路由、后端管理、TLS、网络、流处理等各方面提供了扩展性支持。对于其他使用 MOSN 的场景，也可以通过类似的方式来满足自身业务定制需求。\n为了更清晰的展示 MOSN 功能特性，这里将 MOSN 0.4.0 的功能特性通过表格的方式展示出来。可 …","date":1543906800,"description":"本文根据晓东在 GIAC 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-giac-2018/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"71d6ede37fa4f1d1e6c99fbd37ff2f52","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-giac-2018/","publishdate":"2018-12-04T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/service-mesh-giac-2018/","summary":"朵晓东，花名奕杉，蚂蚁金服高级技术专家。专注企业云计算技术及产品，蚂蚁金融云 PaaS 创始团队核心成员，Antstack 网络产品负责人。开源爱好者，","tags":["Service Mesh"],"title":"蚂蚁金服 Service Mesh 新型网络代理的思考与实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-giac-2018/","wordcount":7130},{"author":"敖小剑","categories":"Service Mesh","content":" 敖小剑，蚂蚁金服高级技术专家，十六年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher 社区联合创始人。 龙轼，阿里巴巴技术专家、前京东 Hadoop 负责人、Hadoop 代码贡献者、现负责UC 基于 Kubernetes 自研的 PaaS 平台整体的稳定性。 本文根据他们在 Service Mesher Meetup 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，今天给大家带来的演讲主题是《蚂蚁金服 Service Mesh 渐进式迁移方案》，给大家介绍一下我们蚂蚁金服主站的 Service Mesh 迁移方案，在稍后的内容中我会给大家解释什么是“渐进式”。今天的演讲方式有些特殊，将会是两位讲师合作。我是敖小剑，来自蚂蚁金服中间件团队，另外一位讲师 龙轼 ，来自 UC 基础研发部。\nService Mesh 演进路线 今天的内容将会有四块主要内容：\n Service Mesh演进路线：介绍蚂蚁金服计划在主站落地Service Mesh的方案，由于涉及到大量的存量应用和超大规模，又要保证迁移过程的平滑，因此我们的落地方案相比社区方案要复杂的多。 实现平滑迁移的关键：介绍在整个迁移方案中，为了实现平滑迁移的几个关键做法，然后今天我们将详细展开其他的一个关键点：DNS寻址方案。 DNS寻址方案的演进：详细介绍Kubernetes/Istio/SOFAMesh一路演进过来的DNS寻址方式 DNS寻址方案的后续规划：介绍我们在DNS寻址方案上的后续规划。 前两块内容将由我来为大家介绍，后两块内容将由我的同事 龙轼 为大家介绍。\n在展开内容之前，先看一下背景，Service Mesh在蚂蚁金服主站落地的背景：\n 目标：需要满足我们对长期目标的认可，具体指服务间通讯走Service Mesh，而且是Istio这种带完整的控制平面的Service Mesh形态，基础设施要构建在k8s之上，而应用的形态要向微服务靠拢。 现状：而现实是存在很多挑战，首先还有很多应用没有实现微服务化，而且我们的k8s普及程度也不够，还有非常多的应用没有运行在kubernets之上。Istio的成熟程度也稍显不足，不够稳定，更大的挑战的是Istio目前无法原生支持我们蚂蚁金服的规模，我们还在试图对Istio进行改进和扩展。最后，在落地时必须考虑的非常现实的一点：现有系统中为数众多的应用不可能一夜之间全部迁移。 关键需求：因此在落地实施时，非常重要的需求是：要实现平滑迁移。简单说，微服务 + Service Mesh + kubernetes 是我们的目标，但是如何从现有体系出发，向目标平稳和坚实的迈进，必须给出可行的实践指导。 今天演讲的内容，要给大家介绍的就是，在这样的背景下，我们蚂蚁金服选择的Service Mesh主站落地演进方案。这个方案预期会在2019年初全面铺开。\n主站落地方案的实施原则，这是我们在过去半年的实践中，总结归纳出来的行为指导：\n 符合远期规划：一定要有清晰的长期目标，明确的知道未来的大方向。避免走弯路，避免浪费投资，理想状态是计划中的每一步都可以为下一步奠定坚实的基础。即使因为某些原因不得已妥协或绕行，也应该清晰的知道后面应该如何回归，谢绝中途推倒重来——代价太高，无法承受。 循序渐进：认清现实，如此之大的变革，一定是需要分步进行，不要心存一步登天的幻想，现实可行的方式是小步快跑。将整个过程拆解为若干个大步骤，每一步的工作量和复杂度都控制在一个可以接受的范围内，以保证每一步都简单方便，切实可行。 有可操作性：在操作层面上，要有足够的弹性，即每个步骤中的工作内容，都应该是可以分批进行。以步步为营的方式，逐步扩大战果，杜绝一刀切。 在接下来的演进路线中，大家将会体会到这三个原则在实际落地时的指导作用。\n这个图的信息量有点大，描述的是 Service Mesh 和 k8s 落地可能的多种演进路线。\n我们先从最下面开始看，这是当前蚂蚁金服主站大多数应用的现状：即应用\u0026amp;rdquo;部署在非k8s上\u0026amp;rdquo;，应用也\u0026amp;rdquo;不是Service Mesh形态\u0026amp;rdquo;。 然后看最上面，这是我们期望的蚂蚁金服主站未来的应用终极形态：应用\u0026amp;rdquo;部署在k8s上\u0026amp;rdquo;，应用也迁移到了\u0026amp;rdquo;Service Mesh形态\u0026amp;rdquo;。\n这里有个特别的地方，我们将Service Mesh形态细分为两种模式：\n Sidecar模式：只有Sidecar，没有控制平面，和外部系统的各种集成都是在Sidecar中直接进行。这是第一代的Service Mesh，Linkerd/Envoy都是如此，华为基于ServiceComb演进而来的mesher，新浪微博的Mesh，包括我们蚂蚁金服基于MOSN开发的用于取代多语言客户端的Mesh方案。 Istio模式：有完善的控制平面，可以提供强大的控制能力，而且从数据平面分离，这是第二代的Service Mesh，典型如Istio和Conkduit/Linkerd 2.0。 之所以将Service Mesh形态细分，是因为我们有着这样一个特殊背景：目前的原生Istio无法支撑我们蚂蚁金服的规模，因此在改进完善Istio之前，我们不得不暂时在Sidecar模式下短暂停留。另外一个原因就是考虑到存量应用的迁移，多一个Sidecar模式作为中间缓冲，会让整个迁移过程平滑很多。\n现在我们来介绍图中展示的四条演进路线：\n 左边的路线1，思路是先将应用迁移k8s部署，再迁移到Service Mesh形态。这条路线的最大好处，是过程中每个阶段的绝大多数投资都将最终得以保留，因为符合k8s+service mesh的远期目标。 右边的路线2，思路是跳过k8s，先迁移到Service Mesh形态，一路演进到Istio模式，然后最后迁移到k8s。 中间的路线3，直接一步到位，这个路线是Istio默认的方式，或者说Istio根本没有考虑过迁移的问题，默认客户已经有完善的k8s，然后将改造好的应用直接部署在Istio上。这个路线对于蚂蚁金服主站的复杂场景，当然是不现实的。（补充：只是对蚂蚁金服主站不合适，对于大多数公司，规模不是那么巨大，也没有历史负担，也有k8s基础，完全可行。） 还有一条特别的路线4，走位飘忽，先和路线2一样迁移到Sidecar模式，然后走回路线1，上k8s，再在有k8s支持的情况下继续演进到Istio模式。 下面我们来详细分析各条演进路线的优劣和实施条件。\n演进路线2，和路线1的核心差别，在于：是先上k8s，还是先上Service Mesh。而且路线2是在非k8s条件下一路演进Service Mesh到我们期望的终极形态Istio模式，这意味着过程中和最终目标有非常大的偏移。\n演进路线2的好处，在于第一步非常的自然：\n 没有k8s的限制，因此不依赖基础设施，实施方便。毕竟，k8s普及度是个大问题； 在原有的侵入式框架的客户端SDK基础上，通过包裹一个proxy，重用原有SDK的能力，可以非常快速的得到一个基本可用的Sidecar； 除了多一个proxy外，没有引入太多的新概念和新 …","date":1543474800,"description":"本文根据敖小剑、龙轼在 Service Mesher Meetup 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-meetup-5-retrospect/","fuzzywordcount":10300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5031be4287bf1a7d7921bf5133ea414c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","publishdate":"2018-11-29T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","summary":"敖小剑，蚂蚁金服高级技术专家，十六年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher 社区联合创始人。 龙轼，阿里巴","tags":["Service Mesh"],"title":"Service Mesh 渐进式迁移方案 | Service Mesh Meetup 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","wordcount":10259},{"author":"鲁直","categories":"SOFAMesh","content":" 本文作者：黄挺，蚂蚁金服高级技术专家，蚂蚁金服分布式架构 SOFA 的开源负责人。目前在蚂蚁金服中间件团队负责应用框架与服务化相关的工作。 本文根据黄挺在 CNUTCon 全球运维大会的主题分享整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，我是来自于蚂蚁金服的黄挺，花名鲁直，目前在蚂蚁金服负责微服务团队，也是 SOFA 开源的负责人。来到这个场子的朋友们肯定都知道，Service Mesh 在过去一两年之中迅速成长为社区中非常热门的话题，几乎所有的大会中，都多多少少有一些关于 Service Mesh 的话题。在一个月之前，我的同事敖小剑老师在上海的 QCon 中也分享了蚂蚁金服在 Service Mesh 上的探索，包括在前面的场次中，来自华为的巨震老师也分享了华为在 Service Mesh 上的一些思考。在今天的分享中，我不会去花太多时间介绍什么是 Service Mesh，更多地聚焦在蚂蚁金服将 Service Mesh 用在解决多语言的问题上的一些实践，希望在场的各位可以从这些实践中有所收获。\n这个是我今天介绍的主要的内容，首先，我会大家简单介绍一下多语言在蚂蚁金服发展的一些情况，铺垫一下背景，交代各个语言在蚂蚁金服的使用情况，并且之前在多语言通信上面遇到了哪些问题。\n然后，我会给大家简单介绍下 SOFAMesh，SOFAMesh 是蚂蚁金服产出的 Service Mesh 的解决方案。\n接着我会介绍我们在 SOFAMesh 之上架构的多语言通信的方案以及在这个方案的实施过程中遇到的一些技术要点。\n蚂蚁金服多语言发展 不知道在场的同学有没有听说过 SOFA，SOFA 是蚂蚁金服大约 10 年前开始研发的一套分布式中间件，包括了微服务体系，分布式事务，消息中间件，数据访问代理等等组件，这套组件一直以来都是完全用 Java 来构建的，因此基于 SOFA 构建的 SOFA 应用也都是用 Java 写的，在蚂蚁金服，目前大概有接近 2000 个 SOFA 应用，顺带提一下，这套 SOFA 中间件目前已经部分开源在 Github 上面。从这个数据我们也可以显而易见地得出以下的结论，Java 在蚂蚁金服，至少在在线的应用上，占据了绝对主导的地位。\n随着无线技术的发展以及 NodeJS 技术的兴起，在 2013 年，蚂蚁金服开始引入了 NodeJS，研发了 EggJS，目前也已经在 Github 上开源，在蚂蚁金服，我们主要将 EggJS 作为服务于无线以及 PC 的 BFF 层来使用，后端的所有的微服务还都是用基于 Java 的 SOFA 来研发，EggJS 要调用后端的 SOFA 服务，并且对 PC 和无线端提供接口，必然就要遵守 Java 世界的 SOFA 之前定下的种种“规矩”，事实上，蚂蚁金服的 NodeJS 团队完全用 EggJS 适配了所有的 SOFA 中间件的客户端，保证在 EggJS 上，也可以使用所有的 SOFA 中间件，可以和之前基于 Java 研发的 SOFA 应用进行通信。但是，由于 Java 在蚂蚁中间件上的主导地位，导致 SOFA 中间件的某些特性的实现，完全依赖于 Java 特有的语言特性，因此，NodeJS 团队在追赶 SOFA 中间件的过程中，也非常的痛苦，在后面的例子中，我会有一些具体的例子，大家看了之后肯定会感同身受。\n再到最近几年，随着 AI 的兴起，在蚂蚁金服也越来越多地出现 CPP，Python 等系统，而由于 CPP 和 Python 等等语言，在蚂蚁金服并没有一个独立的基础设施团队去研发对应的中间件，因此，他们和基于 Java 的 SOFA 应用的互通就降级成了直接采用 HTTP 来通信，这种方式虽然也可以 Work，但是在通信基础之上的服务调用的能力却完全没有，和原本的 SOFA 的基础设施也完全没法连接在一起。\n基于以上的一些现状，可以看到我们在发展过程中的主要的两个问题，一个是基础设施上的重复投入的消耗，很多 SOFA 中间件的特性，除了用 Java 写了一遍之外，还得用 NodeJS 再写一遍。另一个是以 Java 为中心，以 Java 为中心其实在只有 Java 作为开发语言的时候并没有什么问题，但是当其他的语言需要和你进行通信的时候，就会出现巨大的问题，事实上，很多框架上的特性的研发同学在不经意之间，就直接就用了 Java 的语言特有的特性去进行研发，这种惯性和隐性的思维会对其他语言造成巨大的壁垒。\n基于以上的问题，我们希望能够产出一个方案，一方面，可以尽量做到一次实现，到处可用。另一方面，需要能够保证语言的中立性，最好是能够天然地就可以让框架或者中间件的研发的同学去在做架构设计以及编码的时候，考虑到需要支持多语言。\nSOFAMesh 其实在这之前，我们已经尝试在数据访问层去解决类似的多语言适配的问题，蚂蚁金服有一个 OceanBase 的数据库，当各个语言需要访问 OceanBase 数据库的时候，采用的就是一个本地的 Proxy，这个 Proxy 会负责 Fail Over，容灾等等场景，而对各个语言只要保证 SQL 上的兼容就可以了，这让我们意识到，Proxy 的模式可能是解决多语言的一个方式，然后，在业界就出现了 Service Mesh，如果只是从技术上讲，Service Mesh 的 Sidecar 本质上也就是一个 Proxy，只是每一个服务实例都加上一个 Sidecar，这些 Sidecar 组成了一个网络，在加上一个控制平面，大家把他叫做 Service Mesh。通过 Service Mesh，我们可以将大量原来需要在语言库中实现的特性下沉到 Sidecar 中，从而达到一次实现，到处可用的效果；另外，因为 Sidecar 本身不以 Library 的形式集成到特定语言实现的服务中，因此也就不会说某些关键特性采用特定语言的特性来实现，可以保证良好的中立性。\n看起来 Service Mesh 似乎是一个非常完美的解决方案，但是如果我们探寻一下 Service Mesh 的本质的话，就会发现 Service Mesh 并非完美解决方案，这种不完美主要是体现在 Service Mesh 本质上是一种抽象，它抽象了什么东西，它把原来的服务调用中的一些高可用的能力全部抽象到了基础设施层。在这张 PPT 中，我放了三张图片，都是一棵树，从左到右，越来越抽象，从图中也可以非常直观地看出来，从右到左，细节越来越丰富。不管是什么东西，抽象就意味着细节的丢失，丢失了细节，就意味着在能力上会有所欠缺，所以，在 Service Mesh 的方案下，虽然看起来我们可以通过将能力下层到基础设施层，但是一旦下层下去，某些方面的能力就会受损。\n因此，我们希望能够演化出这样一套多语言通信的方案，它能够以 Service Mesh 为基础，但是我们也会做适当地妥协去弥补因为上了 Service Mesh 之后的一些能力的缺失。首先我们希望有一个语言中立的高效的通信协议，每个语言都能够非常简单地理解这个协议，这个是在一个跨语言的 RPC 通信中避免不了的，无论是否采用 Service Mesh。然后， …","date":1542870000,"description":"本文根据黄挺在 CNUTCon 全球运维大会的主题分享整理，完整的分享 PPT 获取方式见文章底部。。","dir":"blog/sofa-mesh-cnutcon-2018/","fuzzywordcount":7000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5a750edaa8c6a9759fd5e3533dd3fa4d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","publishdate":"2018-11-22T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","summary":"本文作者：黄挺，蚂蚁金服高级技术专家，蚂蚁金服分布式架构 SOFA 的开源负责人。目前在蚂蚁金服中间件团队负责应用框架与服务化相关的工作。 本文根据黄挺","tags":["SOFAMesh"],"title":"蚂蚁金服 SOFAMesh 在多语言上的探索实践","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","wordcount":6910},{"author":"明不二","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》最后一篇，作者明不二，就职于华为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部完成，感谢所有参与的源码爱好者！\n 前言 在应用服务化架构中，RPC 框架是非常重要的基础组件。而在 RPC 框架当中，序列化（以及反序列化）又是必不可少的一环。因为序列化的性能对整体框架性能有比较大的影响，之前的文章中，我们已经详细剖析了 SOFARPC 各个核心功能模块的实现原理，想必大家已经很清楚 RPC 的调用流程。\n在整个 RPC 调用流程当中，序列化及反序列化起到了承上启下的作用。序列化时，RPC客户端把待调用的方法和参数对象转换为网络上可传输的字节序列，为进一步的编解码提供原料。反序列化时，把从网络上接收到且已经解码了的字节序列转换成对象，便于 RPC 服务端调用。\n本文将从序列化概述、序列化协议特性、序列化使用方法分类、SOFARPC 序列化的设计及实现、几种序列化协议对比等方面介绍及对比序列化及其在 SOFARPC 中的应用。\n序列化概述 RPC 调用通过网络传输相关的调用方法及参数，在这个网络传输过程中，内存中的对象是无法直接传输的，只有二进制字节才能在网络上传输。而为了实现调用对象在网络上的传输，必须通过序列化实现对象 -\u0026amp;gt; 字节的过程，以及反序列化实现字节 -\u0026amp;gt; 对象的过程。在网络协议模型中，序列化属于应用层协议的一部分。\n如下列定义：\n序列化：将数据结构或者对象转换成二进制串的过程。\n反序列化：将序列化过程中生成的二进制串转换成数据结构或者对象的过程。\n在上述定义中，二进制字节数组专指 Java 语言中的 byte[]。\n序列化协议特性 每种序列化协议都有其优点和缺点，在对一个序列化协议进行衡量评判时，通常由如下一些指标可以参考：\n 指标 说明 重要性 通用性 是否跨平台，社区如何 中高 可读 序列化格式是否可读 中低 易用性 是否简单易用 中高 性能 序列化后的大小和压缩 CPU消耗 中高 可扩展性 是在允许字段修改 高 安全性 是否存在一些无法修复的漏洞 高 以下逐个来详细说明：\n通用性 在通用性上，主要考察该序列化协议是否支持跨平台、跨语言的使用，同时兼顾考察业界的流行度及社区的活跃性。\n可读/易用性 在可读、易用性上面，主要考察该序列化协议序列化之后是否人眼可读，如 XML 和 JSON 就是人眼可读的序列化框架，这会大大提高调试的效率。同时，需要考察序列化框架所提供的 API 是否容易学习、调用。当然，在远程调用 的场景下，可读性不是一个重要因素。或者说，我们更多希望不可读。来保证一定的安全性。\n性能 性能指标，主要考虑序列化框架的时间复杂度和空间复杂度。\n序列化之后的数据一般都是用于存储或者网络传输，空间占用大小决定了传输的效率。序列化通常情况下要在原有的数据上加上描述字段，如果这个过程中引入的额外开销过大，则在大规模分布式系统中，很可能会造成巨大的额外空间开销。\n同时，为了提高系统的性能，是否耗费 CPU，解析和反解析二进制串的时间也是一个非常重要的指标。\n可扩展性 主要考虑当系统准备升级，需要对实体的属性进行变更，此时序列化协议能否快速支持，并且不会对原有的系统造成影响。如作为服务提供方的 API 接口入参中，增加了一个字段，是否一定要强制所有的客户端进行升级。这个会涉及到线上兼容性的问题。一般我们要求新增字段，在客户端尚未使用的情况下，不应该有序列化问题。\n安全性 需要考察序列化协议是否支持跨局域网之间的安全访问。是否存在一些安全漏洞。可以通过构造一些字节数组，使得服务端反序列化的时候，触发某些安全漏洞，执行一些系统调用，或者越权操作。\n序列化使用方式分类 按照序列化的使用方式，可以分为自描述型序列化以及基于中间格式型序列化。\n自描述型 所谓的自描述型，即在序列化的字节流里有着完整的对象类型信息和属性信息，可以在不依赖任何外界描述信息的前提下，只要拿到这个二进制流，就可以直接还原出原始对象。\n类似的系列化产品有：hessian、JSON、XML 等。\n例如，有如下一个对象 Person，Java 语言定义如下：\npackage com.sofa.test.Person; public class Person { private int age = 15; private String name = “sofa”; } 则使用 hessian 序列化后的字节流如下：\nM**com.sofa.test.PersonS**nameS**sofaS**ageI**b3 b2 b1 b0 z\n上面的*和b3 b2 b1 b0都表示不可打印的二进制。从上面内容可以看出，按照相应规定就能从二进制串中反序列化出对象来。因为这里面已经描述了类型，类型的字段名，以及对应的值，这样就可以直接反序列化了。\n基于中间描述型 一般这种类型的序列化主要用于跨语言当中，比如 Protobuf以及 thrift等等。在使用时都需要事先定义一个中间格式的文件（IDL 文件），然后根据不同语言的生成工具生成一个相应语言的可序列化类。以下是一个简单的 Proto的描述文件\nmessage SofaApp{ string appName = 1; repeated string authList = 2; repeated string serviceList = 3; } 然后当需要反序列化时，根据 IDL 文件及逆行相应的反序列化即可。格式是这样\n其中，图中的用户定义编号就是前面 proto中对每个字段定义的编号。\nSOFARPC 序列化的设计与实现 SOFARPC 支持及将要支持的序列化协议有：hessian、Protobuf、Json。\n序列化接口定义 在目前的 SOFARPC 5.4 分支中，已经支持的序列化协议有 hessian 和 Protobuf。两个序列化实现类继承了 AbstractSerializer抽象类，该抽象类又实现了如下的 Serializer接口：\n/** * 序列化器接口 * * @author \u0026amp;lt;a href=mailto:zhanggeng.zg@antfin.com\u0026amp;gt;GengZhang\u0026amp;lt;/a\u0026amp;gt; */ @Extensible(coded = true) @Unstable public interface Serializer { /** * 序列化 * * @param object 对象 * @param context 上下文 * @return 序列化后的对象 * @throws SofaRpcException 序列化异常 */ public AbstractByteBuf encode(Object object, Map\u0026amp;lt;String, …","date":1541055600,"description":"本文为《剖析 | SOFARPC 框架》最后一篇，作者明不二，就职于华为。","dir":"blog/sofa-rpc-serialization-comparison/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f0a5fd044fa69071a7251518ea7d69f6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-serialization-comparison/","publishdate":"2018-11-01T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-serialization-comparison/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 序列化比较","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-serialization-comparison/","wordcount":3267},{"author":"鸥波","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十二篇，作者鸥波。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 随着 TIOBE 10月份的编程语言排行 的发布，C++重回第三的位置，新兴的 Swift 和 Go 表现出强劲的上升趋势。与此同时，虽然目前 Java 的领头位置尚未出现有力挑战，我们希望能够在基础设施的建设上预留跨语言的可扩展设计。同时，跨语言的挑战也是工程实际面临的现状，蚂蚁内部如 AI、IoT，算法等缺少 JVM 原生支持的领域，往往不可避免地需要涉及到跨语言调用的问题。\n本文将为大家介绍 基于 SOFARPC 的微服务应用在面临跨语言调用时的方案和实现。\n总体设计 经过前面几篇对 SOFARPC 的 BOLT 协议和序列化这些的介绍，相信大家已经对 RPC 有了一些自己的理解，提到跨语言，我们会首先想到其他语言调用 Java，Java 调用其他语言，那么这里的跨，体现在代码上，到底跨在哪里？\n从跨语言的实现上来说，主要解决两个方面的问题：\n 跨语言的通讯协议和序列化协议\n 跨语言服务发现\n 另外从跨语言的落地来说，还得解决一个平滑兼容的问题。\n业界常见的做法是一般是通过 DNS 和 HTTP 来解决跨语言的问题，但是在内部已经有完善技术栈体系的情况下，直接切换一个新的方案显然是不合适的，所以蚂蚁内部是在已有的技术体系基础上进行改进。\n蚂蚁内部使用的通讯协议是Bolt，序列化协议是Hessian。我们知道，服务端和客户端在请求和返回之间携带的结构化的业务数据，需要在传输到达对端后，被本地的语言能够易于解析消费。由于语言本身特性的差异，同一对象的在序列化和反序列化的转换后，结构可能有差异，但是需要保证其转换操作是可逆的。以上这点Hessian做的不是很好，其跨语言的兼容性不能满足跨语言的需求，所以另外一个可行的方案就是就是选择其它基于 IDL 的序列化协议，例如Protobuf。\n现成的服务注册中心一般都有一些多语言解决方案，像Zookeeper、SOFARegistry、Consul、etcd等都有多语言客户端，所以服务发现这块问题不算太大。\n例如下面就是一个基于注册中心 + Bolt 协议 + Protobuf 序列化的设计图。\n通讯协议和序列化协议 通讯协议只要跨语言各方约定清楚，大家安装约定实现即可，而序列化协议则需要较多的考量。\n序列化的协议选择列出一些考虑要点：\n 是否采用具备自我描述能力的序列化方案，如不需要借助一些 schema 或者接口描述文件。\n 是否为语言无关的，包括脚本语言在内。\n 是否压缩比例足够小，满足网络传输场景的要求。\n 是否序列化和反序列化的性能均足够优秀。\n 是否向前/向后兼容，能够处理传输对象的新增属性在服务端和客户端版本不一致的情况。\n 是否支持加密、签名、压缩以及扩展的上下文。\n JSON Over HTTP 首先，说到跨语言，序列化支持，肯定有同学会问，为什么不直接通过 Http的Json来搞定呢？\n虽然得益于JSON和HTTP在各个语言的广泛支持，在多语言场景下改造支持非常便捷，能够低成本的解决网络通讯和序列化的问题。服务发现的过程则可以使用最简单的固定URL（协议+域名+端口+路径）的形式，负载均衡依赖于F5或者LVS等实现。\n但是这个方案的有明显的局限性：\n HTTP 作为无状态的应用层协议，在性能上相比基于传输层协议（TCP）的方案处于劣势。HTTP/1.1后可以通过设置keep-alive使用长连接，可以一定程度上规避建立连接的时间损耗；然而最大的问题是，客户端线程采用了 request-response 的模式，在发送了 request 之后被阻塞，直到拿到 response 之后才能继续发送。这一问题直到 HTTP/2.0 才被解决。\n JSON 是基于明文的序列化，较二进制的序列化方案，其序列化的结果可读性强，但是压缩率和性能仍有差距，这种对于互联网高并发业务场景下，意味着硬件成本的提升。\n 对于网络变化的响应。订阅端处理不够强大。\n Hessian Over BOLT 在否决了上一个方案后，我们继续看，蚂蚁内部，最开始的时候，SOFARPC 还没有支持 Protobuf 作为序列化方式，当时为了跨语言，NodeJs的同学已经在此基础上，用 js 重写了一个 hessian 的版本，完成了序列化。也已经在线上平稳运行。但是当我们要扩展给其他语言的时候，重写 hessian 的成本太高。而且 Java语言提供的接口和参数信息，其他语言也需要自己理解一遍，对应地转换成自己的语言对象。因此该方案在特定场景下是可行的。但不具备推广至其他语言的优势。\nNode的实现版本可以参考：https://github.com/alipay/sofa-rpc-node\nProtobuf Over BOLT Protobuf 基于IDL，本身具备平台无关、跨语言的特性，是一个理想的序列化方案。但是需要先编写proto文件，结构化地描述传输的业务对象，并生成中间代码。\n由于要重点介绍一下这种方案，因此再次回顾一下SOFABolt的协议规范部分，便于后面的解释。\nRequest command protocol for v1 0 1 2 4 6 8 10 12 14 16 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ |proto| type| cmdcode |ver2 | requestId |codec| timeout | classLen | +-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+ |headerLen | contentLen | ... ... | +-----------+-----------+-----------+ + | className + header + content bytes | + + | ... ... | +-----------------------------------------------------------------------------------------------+ codec: code for codec 序列化,hessian 是1,pb 是11,java 是2 Response command protocol for v1 0 1 2 3 4 6 8 10 12 14 16 …","date":1540969200,"description":"本文为《剖析 | SOFARPC 框架》第十二篇，作者鸥波。","dir":"blog/sofa-rpc-cross-language-support/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"28621f1b90e6ce8edf1b3e446fa5be23","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-cross-language-support/","publishdate":"2018-10-31T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-cross-language-support/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之SOFARPC 跨语言支持剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-cross-language-support/","wordcount":3741},{"author":"敏古","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十一篇，作者敏古。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。 SOFARPC：https://github.com/sofastack/sofa-rpc\n 1、前言 在 SOFABoot 环境下，SOFARPC 提供三种方式给开发人员发布和引用 RPC 服务：\n XML 方式（配置）\n Annotation 方式（注解）\n 编程 API 方式（动态）\n 编程 API 方式与Spring 的 ApplicationContextAware 类似。XML的方式依赖于在xml中引入 SOFA 命名空间，利用 Bean 的生命周期管理，进行 Bean 的注入。相比这两种方式，通过 Annotation 方式发布 JVM 服务更加灵活方便，只需要在实现类上加 @SofaService、@SofaRefernce 注解即可进行服务的发布和引用。本文针对 SOFARPC 在注解的支持和使用分原理、源码两部分进行一一介绍。\n2、原理介绍 2.1、注解是什么 注解又称为元数据，可以对代码中添加信息，这是一种形式化的方法，可以在稍后的某个时刻非常方便地使用这些数据。这个时刻可能是编译时，也可能是运行时。\n注解是JDK1.5版本开始引入的一个特性，用于对代码进行说明，可以对包、类、接口、字段、方法参数、局部变量等进行注解。注解的本质就是一个继承了 Annotation 接口的接口。一个注解准确意义上来说，只不过是一种特殊的注释而已，如果没有解析它的代码，它可能连注释都不如。\n一般常用的注解可以分为三类：\n Java自带的标准注解，包括@Override（标明重写某个方法）、@Deprecated（标明某个类或方法过时）和@SuppressWarnings（标明要忽略的警告）。\n 元注解，元注解是用于定义注解的注解。\n 自定义注解，可以根据自己的需求定义注解。\n 2.2、元注解 元注解是用于修饰注解的注解，通常用在注解的定义上。JAVA 中有以下几个元注解：\n @Target：注解的作用目标，也就是指明，你的注解到底是用来修饰方法的？修饰类的？还是用来修饰字段属性的，有以下几种类型： ElementType.TYPE：允许被修饰的注解作用在类、接口和枚举上 ElementType.FIELD：允许作用在属性字段上 ElementType.METHOD：允许作用在方法上 ElementType.PARAMETER：允许作用在方法参数上 ElementType.CONSTRUCTOR：允许作用在构造器上 ElementType.LOCAL_VARIABLE：允许作用在本地局部变量上 ElementType.ANNOTATION_TYPE：允许作用在注解上 ElementType.PACKAGE：允许作用在包上 @Retention：指定了被修饰的注解的生命周期，分以下三种类型： RetentionPolicy.SOURCE：该注解只保留在一个源文件当中，当编译器将源文件编译成class文件时，它不会将源文件中定义的注解保留在class文件中。 RetentionPolicy.CLASS：该注解只保留在一个class文件当中，当加载class文件到内存时，虚拟机会将注解去掉，从而在程序中不能访问。 RetentionPolicy.RUNTIME：该注解在程序运行期间都会存在内存当中。此时，我们可以通过反射来获得定义在某个类上的所有注解。 @Documented：当我们执行 JavaDoc 文档打包时会被保存进 doc 文档，反之将在打包时丢弃。\n @Inherited：解修饰的注解是具有可继承性的，也就说我们的注解修饰了一个类，而该类的子类将自动继承父类的该注解。\n 以 @Override 为例子：\n当编译器检测到某个方法被修饰了 @Override 注解，编译器就会检查当前方法的方法签名是否真正重写了父类的某个方法，也就是比较父类中是否具有一个同样的方法签名。\n@Override 仅被编译器可知，编译器在对 java 文件进行编译成字节码的过程中，一旦检测到某个方法上被修饰了该注解，就会去匹对父类中是否具有一个同样方法签名的函数，否则不能通过编译。\n2.3、注解解析方式 解析一个类或者方法的注解通常有两种形式，一种是编译期直接的扫描，一种是运行期反射。\n2.3.1、编译器的扫描 指的是编译器在对 java 代码编译字节码的过程中会检测到某个类或者方法被一些注解修饰，这时它就会对于这些注解进行某些处理。典型的就是注解 @Override，一旦编译器检测到某个方法被修饰了 @Override 注解，编译器就会检查当前方法的方法签名是否真正重写了父类的某个方法，也就是比较父类中是否具有一个同样的方法签名。\n这一种情况只适用于那些编译器已经熟知的注解类，比如 JDK 内置的几个注解，而你自定义的注解，编译器是不知道你这个注解的作用的，\n2.3.1、运行期反射 首先对虚拟机的几个注解相关的属性表进行介绍，先大体了解注解在字节码文件中是如何存储的。虚拟机规范定义了一系列和注解相关的属性表，也就是说，无论是字段、方法或是类本身，如果被注解修饰了，就可以被写进字节码文件。属性表有以下几种：\n RuntimeVisibleAnnotations：运行时可见的注解 RuntimeInVisibleAnnotations：运行时不可见的注解 RuntimeVisibleParameterAnnotations：运行时可见的方法参数注解 RuntimeInVisibleParameterAnnotations：运行时不可见的方法参数注解 AnnotationDefault：注解类元素的默认值 java.lang.reflect.AnnotatedElement 接口是所有程序元素（Class、Method和Constructor）的父接口，程序通过反射获取了某个类的 AnnotatedElemen t对象之后，利用 Java 的反射机获取程序代码中的注解，然后根据预先设定的处理规则解析处理相关注解以达到主机本身设定的功能目标。\n本质上来说，反射机制就是注解使用的核心，程序可以调用该对象的以下方法来访问 Annotation信息：\n getAnnotation：返回指定的注解 isAnnotationPresent：判定当前元素是否被指定注解修饰 getAnnotations：返回所有的注解 getDeclaredAnnotation：返回本元素的指定注解 getDeclaredAnnotations：返回本元素的所有注解，不包含父类继承而来的 3、源码解析 3.1、 …","date":1540450800,"description":"本文为《剖析 | SOFARPC 框架》第十一篇，作者敏古。","dir":"blog/sofa-rpc-annotation-support/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e68884b2feaf90e26f191de0ef49e945","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-annotation-support/","publishdate":"2018-10-25T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-rpc-annotation-support/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-annotation-support/","wordcount":4359},{"author":"敖小剑","categories":"SOFAMesh","content":" 背景 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，这两个是Istio/Envoy中的一等公民。而基于HTTP/1.1的REST和基于HTTP/2的gRPC，一个是目前社区最主流的通讯协议，一个是未来的主流，google的宠儿，CNCF御用的RPC方案，这两个组成了目前Istio和Envoy（乃至CNCF所有项目）的黄金组合。\n而我们SOFAMesh，在第一时间就遇到和Istio/Envoy不同的情况，我们需要支持REST和gRPC之外的众多协议：\n SOFARPC：这是蚂蚁金服大量使用的RPC协议(已开源) HSF RPC：这是阿里集团内部大量使用的RPC协议(未开源) Dubbo RPC: 这是社区广泛使用的RPC协议(已开源) 其他私有协议：在过去几个月间，我们收到需求，期望在SOFAMesh上运行其他TCP协议，部分是私有协议 为此，我们需要考虑在SOFAMesh和SOFAMosn中增加这些通讯协议的支持，尤其是要可以让我们的客户非常方便的扩展支持各种私有TCP协议：\n实现分析 我们来大体看一下，在SOFAMesh/Istio中要新增一个通讯协议需要有哪些工作：\n protocol decoder：负责解析协议，读取协议字段 protocol encoder：负责生成请求报文，注意通常会有改动，比如修改某些header 在pilot中需要为新协议生成 Virtual Host 等配置，有 inbound 和 outbound 两份，分别下发到Sidecar 在Sidecar中，根据下发的 Virtual Host 等配置，进行请求匹配，以决定请求该转发到何处 备注：实际下发的配置不止 Virtual Host 配置，为了简单起见，我们仅以 Virtual Host 为例做讲解。\n 其中，protocol encoder和protocol decoder是容易理解的，对于新的通讯协议肯定需要有协议编解码层面的工作必须要完成，这块有工作量是很自然的。\n我们来看看第三块的工作量是什么，inbound 和 outbound 的Virtual Host配置示例如下：\noutbound 配置中，注意 domains 字段是各种域名和ClusterIP，而 routes 中，match是通过prefix来匹配。我们结合HTTP/1.1，domains字段是用来和请求的Host header进行域名匹配的，比如 Host: istio-telemetry，这决定了哪些请求是要转发到 istio-telemetry 这个服务的。routes的match用来进行路由匹配的，通过HTTP请求的path进行匹配。\ninbound 配置类似，只是inbound更简单，domains匹配*就可以。\n从上面的例子中可以看到，Istio和Envoy的设计有非常浓重的HTTP协议的味道，各种语义都是和HTTP直接相关。而当我们进行TCP协议的转发时，就需要将请求的协议字段进行映射，映射到HTTP的相应语义。\n比如，最基本的Destination，原始语义是请求的目的地，在前面的文章中我们指出过这是请求转发最关键的字段。在HTTP协议中，通常是通过Host header和Path表示，对于REST而言还有重要的Method字段。\n下面的格式是其他各种协议对这个Destination原始语义的实际实现方式：\n 协议 实现 原始语义 请求的目的地(Destination) HTTP/1.1 Host header，Method，Path HTTP/2 Header帧中的伪header :authority，:path和:method Bolt协议 header map中key为”service”的字段 HSF协议 协议头中的服务接口名和服务方法名 Dubbo协议 data字段（payload）中的path/method 这些通讯协议在下发规则和进行请求匹配时，就需要进行协调：\n 定义好 Virtual Host 配置中的 domains 字段和 route 中的 match 用到的字段在当前通讯协议中的实际语义 在 protocol encoder 中读取请求的协议字段，和上面的字段对应 然后进行请求路由规则匹配（参照HTTP/1.1中的domain和route match的匹配） 而这些都是需要以代码的方式进行实现，以满足新通讯协议的要求。正规的做法，是每次新增一个通讯协议就将上述的工作内容重复一遍。这会直接导致大量的高度类似的重复代码。\nx-protocol的实现 在上述需要在协议扩展时修改的四个内容中，有一块是特别的：生成 Virtual Host 配置的工作是在Pilot中实现的，而其他三个是在Sidecar （Envoy或MOSN）中。考虑到 protocol encoder 和 protocol decoder 的工作是必不可少的，必然会修改Sidecar来增加实现代码，因此简化开发的第一个想法就是：能不能做到不修改Pilot？\n基本思路就是固定好原始语义，避免每个通讯协议都映射一遍。从前面我们列出来的各个协议的映射情况看，对于RPC协议而言，一般目的地信息都是服务名(有些是接口名)+方法名居多，因此可以考虑直接将服务名和方法名固定下来：\n RPC协议在 Virtual Host 配置中就固定为服务名对应 domains 字段，方法名对应 route 中的 match 用到的字段，这样只要修改一次然后各个RPC协议公用此配置，以后就不用再重复修改Pilot。 protocol encoder 在解析通讯协议完成之后，就直接将协议中对应服务名和方法名的字段提取出来，后面的匹配处理过程就可以公用一套通用实现，这样路由匹配这块也可以不用在重复开发。 因此，在x-protocol中，如果需要引入一个新的通讯协议，需要的工作内容只有必不可少的protocol encoder 和 protocol decoder，和实现以下几个接口：\n总结 X-protocol 在支持新通讯协议上的做法并无新奇之处，只是由于需求特殊有众多通讯协议需要支持，在开发时发现大量重复工作，因此我们选择了一条可以让后面更舒服一点的道路。\n目前这个方案在SOFAMesh中采用，我们将进一步检验实际效果，也会和合作的小伙伴时验证，看他们在自行扩展新协议时是否足够理想。这个方案理论上应该可以同样适用于Istio、Envoy体系，随着社区对Istio的接受程度的提高，在Istio上支持各种TCP通讯协议的需求会越来越多，有理由相信Istio后续可能也会出现类似的方案。毕竟，每次都改一大堆类似的东西，不是一个好做法。\n系列文章 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发 ","date":1539500400,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，本文介绍的是TCP协议扩展。","dir":"blog/sofa-mesh-x-protocol-tcp-protocol-extension/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2c2876e9ae6a7a2b374b0d04cc42e6a4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","publishdate":"2018-10-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","summary":"背景 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，这两个是Istio/Envoy中的一等公民。而","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（3）——TCP协议扩展","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","wordcount":2488},{"author":"敖小剑","categories":"SOFAMesh","content":" 前言 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，而我们SOFAMesh，则需要支持以下几个RPC协议：\n SOFARPC：这是蚂蚁金服大量使用的RPC协议（已开源） HSF RPC：这是阿里集团内部大量使用的RPC协议（未开源） Dubbo RPC: 这是社区广泛使用的RPC协议（已开源） 更适合的平衡点：性能和功能 对于服务间通讯解决方案，性能永远是一个值得关注的点。而SOFAMesh在项目启动时就明确要求在性能上要有更高的追求，为此，我们不得不在Istio标准实现之外寻求可以获取更高性能的方式，比如支持各种RPC协议。\n期间有两个发现：\n Istio在处理所有的请求转发如REST/gRPC时，会解码整个请求的header信息，拿到各种数据，提取为Attribute，然后以此为基础，提供各种丰富的功能，典型如Content Based Routing。 而在测试中，我们发现：解码请求协议的header部分，对CPU消耗较大，直接影响性能。 因此，我们有了一个很简单的想法：是不是可以在转发时，不开启部分功能，以此换取转发过程中的更少更快的解码消耗？毕竟，不是每个服务都需要用到Content Based Routing这样的高级特性，大部分服务只使用 Version Based Routing，尤其是使用RPC通讯协议的服务，没有HTTP那么表现力丰富的header，对Content Based Routing的需求要低很多。\n此外，对于部分对性能有极高追求的服务，不开启高级特性而换取更高的性能，也是一种满足性能要求的折中方案。考虑到系统中总存在个别服务对性能非常敏感，我们觉得Service Mesh提供一种性能可以接近直连的方案会是一个有益的补充。为了满足这些特例而不至于因此整体否决Service Mesh方案，我们需要在Service Mesh的大框架下提供一个折中方案。\n请求转发 在我们进一步深入前，我们先来探讨一下实现请求转发的技术细节。\n有一个关键问题：当Envoy/SOFA MOSN这样的代理程序，接收到来自客户端的TCP请求时，需要获得哪些信息，才可以正确的转发请求到上游的服务器端？\n最关键的信息：destination 首先，毫无疑问的，必须拿到destination/目的地，也就是客户端请求必须通过某种方式明确的告之代理该请求的destination，这样代理程序才能根据这个destionation去找到正确的目标服务器，然后才有后续的连接目标服务器和转发请求等操作。\nDestination信息的表述形式可能有：\n1. IP地址\n可能是服务器端实例实际工作的IP地址和端口，也可能是某种转发机制，如Nginx/HAProxy等反向代理的地址或者Kubernetes中的ClusterIP。\n举例：“192.168.1.1:8080”是实际IP地址和端口，“10.2.0.100:80”是ngxin反向代理地址，“172.168.1.105:80”是Kubernetes的ClusterIP。\n2. 目标服务的标识符\n可用于名字查找，如服务名，可能带有各种前缀后缀。然后通过名字查找/服务发现等方式，得到地址列表（通常是IP地址+端口形式）。\n举例：“userservice”是标准服务名， “com.alipay/userservice”是加了域名前缀的服务名， “service.default.svc.cluster.local”是k8s下完整的全限定名。\nDestination信息在请求报文中的携带方式有：\n1. 通过通讯协议传递\n这是最常见的形式，标准做法是通过header头，典型如HTTP/1.1下一般使用 host header，举例如“Host: userservice”。HTTP/2下，类似的使用“:authority” header。\n对于非HTTP协议，通常也会有类似的设计，通过协议中某些字段来承载目标地址信息，只是不同协议中这个字段的名字各有不同。如SOFARPC，HSF等。\n有些通讯协议，可能会将这个信息存放在payload中，比如后面我们会介绍到的dubbo协议，导致需要反序列化payload之后才能拿到这个重要信息。\n2. 通过TCP协议传递\n这是一种非常特殊的方式，通过在TCP option传递，上一节中我们介绍Istio DNS寻址时已经详细介绍过了。\nTCP拆包 如何从请求的通讯协议中获取destination？这涉及到具体通讯协议的解码，其中第一个要解决的问题就是如何在连续的TCP报文中将每个请求内容拆分开，这里就涉及到经典的TCP沾包、拆包问题。\n转发请求时，由于涉及到负载均衡，我们需要将请求发送给多个服务器端实例。因此，有一个非常明确的要求：就是必须以单个请求为单位进行转发。即单个请求必须完整的转发给某台服务器端实例，负载均衡需要以请求为单位，不能将一个请求的多个报文包分别转发到不同的服务器端实例。所以，拆包是请求转发的必备基础。\n由于篇幅和主题限制，我们不在这里展开TCP沾包、拆包的原理。后面针对每个具体的通讯协议进行分析时再具体看各个协议的解决方案。\n多路复用的关键参数：RequestId RequestId用来关联request和对应的response，请求报文中携带一个唯一的id值，应答报文中原值返回，以便在处理response时可以找到对应的request。当然在不同协议中，这个参数的名字可能不同（如streamid等）。\n严格说，RequestId对于请求转发是可选的，也有很多通讯协议不提供支持，比如经典的HTTP1.1就没有支持。但是如果有这个参数，则可以实现多路复用，从而可以大幅度提高TCP连接的使用效率，避免出现大量连接。稍微新一点的通讯协议，基本都会原生支持这个特性，比如SOFARPC、Dubbo、HSF，还有HTTP/2就直接內建了多路复用的支持。\nHTTP/1.1不支持多路复用（http1.1有提过支持幂等方法的pipeline机制但是未能普及），用的是经典的ping-pong模式：在请求发送之后，必须独占当前连接，等待服务器端给出这个请求的应答，然后才能释放连接。因此HTTP/1.1下，并发多个请求就必须采用多连接，为了提升性能通常会使用长连接+连接池的设计。而如果有了requestid和多路复用的支持，客户端和Mesh之间理论上就可以只用一条连接（实践中可能会选择建立多条）来支持并发请求：\n而Mesh与服务器（也可能是对端的Mesh）之间，也同样可以受益于多路复用技术，来自不同客户端而去往同一个目的地的请求可以混杂在同一条连接上发送。通过RequestId的关联，Mesh可以正确将reponse发送到请求来自的客户端。\n由于篇幅和主题限制，我们不在这里展开多路复用的原理。后面针对每个具体的通讯协议进行分析时再具体看各个协议的支持情况。\n请求转发参数总结 上面的分析中，我们可以总结到，对于Sidecar，要正确转发请求：\n 必须获取到destination信息，得到转发的目的地，才能进行服务发现类的寻址 必须要能够正确的拆包，然后以请求为单位进行转发，这是负载均衡的基 …","date":1539154800,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，本文介绍的是快速解码转发方案。","dir":"blog/sofa-mesh-x-protocol-rapid-decode-forward/","fuzzywordcount":6900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"37ad5c3f997c173a4ceb60cc9dfd0532","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","summary":"前言 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，而我们SOFAMesh，则需要支持以下几个RP","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","wordcount":6856},{"author":"米麒麟","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第九篇，作者米麒麟，目前就职于陆金所。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕，文末提供了已完成的文章目录。\n 前言 众所周知，在微服务架构下面，当应用需要进行新功能升级发布，或者异常关闭重启的时候，我们会对应用的进程进行关闭，而在关闭之前，我们希望做一些诸如关闭数据库连接，等待处理任务完成等操作，这个就涉及到我们本文中的优雅关闭功能。假如应用没有支持优雅停机，则会带来譬如数据丢失，交易中断、文件损坏以及服务未下线等情况。\n微服务的优雅停机需要遵循\u0026amp;rdquo;注销发布服务 → 通知注销服务 → 更新服务清单 → 开启请求屏蔽 → 调用销毁业务服务 → 检查所有请求是否完成 → 超时强制停机\u0026amp;rdquo;应用服务停机流程。\nSOFARPC 提供服务端/客户端优雅关闭功能特性，用来解决 kill PID，应用意外自动退出譬如 System.exit() 退出 JVM，使用脚本或命令方式停止应用等使用场景，避免服务版本迭代上线人工干预的工作量，提高微服务架构的服务高可靠性。\n本文将从进程的优雅关闭，SOFARPC 应用服务优雅关闭流程，Netty 的优雅停机等方面出发详细剖析 。\n进程优雅关闭 Kill 结束进程 在 Linux上，kill 命令发送指定的信号到相应进程，不指定信号则默认发送 SIGTERM(15) 终止指定进程。如果无法终止，可以发送 SIGKILL(9) 来强制结束进程。kill 命令信号共有64个信号值，其中常用的是：\n2(SIGINT：中断，Ctrl+C)。\n15(SIGTERM：终止，默认值)。\n9(SIGKILL：强制终止)。\n这里我们重点说一下15和9的情况。\nkill PID/kill -15 PID 命令系统发送 SIGTERM 进程信号给响应的应用程序，当应用程序接收到 SIGTERM 信号，可以进行释放相应资源后再停止，此时程序可能仍然继续运行。\n而kill -9 PID 命令没有给进程遗留善后处理的条件。应用程序将会被直接终止。\n对微服务应用而言其效果等同于突然断电，强行终止可能会导致如下几方面问题：\n 缓存数据尚未持久化到磁盘，导致数据丢失；\n 文件写操作正在进行未更新完成，突然退出进程导致文件损坏；\n 线程消息队列尚有接收到的请求消息，未能及时处理，导致请求消息丢失；\n 数据库事务提交，服务端提供给客户端请求响应，消息尚在通信线程发送队列，进程强制退出导致客户端无法接收到响应，此时发起超时重试带来重复更新。\n 所以支持优雅关闭的前提是关闭的时候，不能被直接 通过发送信号为9的 Kill 来强制结束。当然，其实我们也可以对外统一暴露应用程序管理的 API 来进行控制。本文暂时不做讨论。\nJava 优雅关闭 当应用程序收到信号为15的关闭命令时，可以进行相应的响应，Java 程序的优雅停机通常通过注册 JDK 的 ShutdownHook 来实现，当应用系统接收到退出指令，首先 JVM 标记系统当前处于退出状态，不再接收新的消息，然后逐步处理推积的消息，接着调用资源回收接口进行资源销毁，例如内存清理、对象销毁等，最后各线程退出业务逻辑执行。\n优雅停机需要超时控制机制，即到达超时时间仍然尚未完成退出前资源回收等操作，则通过停机脚本调用kill-9 PID命令强制退出进程。\n其中 JVM 优雅关闭的流程主要的阶段如下图所示：\n如图所示，Java进程优雅退出流程包括如下五个步骤：\n 应用进程启动，初始化 Signal 实例；\n 根据操作系统类型，获取指定进程信号；\n 实现 SignalHandler 接口，实例化并注册到 Signal，当 Java 进程接收到譬如 kill -12 或者 Ctrl+C 命令信号回调其 handle() 方法；\n SignalHandler 的 handle 回调接口初始化 ShutdownHook 线程，并将其注册到 Runtime 的 ShutdownHook。\n Java 进程接收到终止进程信号，调用 Runtime 的exit() 方法退出 JVM 虚拟机，自动检测用户是否注册ShutdownHook 任务，如果有则触发 ShutdownHook 线程执行自定义资源释放等操作。\n SOFARPC 优雅关闭 在进程可以进行优雅关闭后，SOFARPC 如何实现优雅关闭呢？首先 SOFARPC 对于所有可以被优雅关闭的资源设计com.alipay.sofa.rpc.base.Destroyable接口，通过向 JVM 的 ShutdownHook 注册来对这些可被销毁的资源进行优雅关闭，支持销毁前和销毁后操作。\n这里包括两部分：\n 作为服务端注册 JDK 的 ShutdownHook 执行取消服务注册、关闭服务端口等动作实现；\n 作为客户端通过实现 DestroyHook 接口逐步处理正在调用的请求关闭服务调用。\n 总体设计 运行时上下文注册 JDK 的 ShutdownHook 执行销毁 SOFARPC 运行相关环境实现类似发布平台/用户执行kill PID 优雅停机。运行时上下文 RpcRuntimeContext 静态初始化块注册 ShutdownHook 函数：\nstatic { ... // 增加jvm关闭事件 if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } } 注册本身很简单，重要的是 destroy 方法实际上做的事情非常多。按照先后顺序，大致包含如下几个部分。\nRpcRuntimeContext 销毁服务优雅关闭完整流程：\n 设置 RPC 框架运行状态修改为正在关闭，表示当前线程不再处理 RPC 服务请求；\n 遍历运行时上下文关闭资源的销毁钩子，进行注册销毁器清理资源前期准备工作；\n 获取发布的服务配置反注册服务提供者，向指定注册中心批量执行取消服务注册；\n 检查当前服务端连接和队列任务，先把队列任务处理完毕，再缓慢关闭启动端口；\n 关闭发布的服务，到注册中心取消服务发布，取消将处理器注册到服务端，清除服务发布配 …","date":1539154800,"description":"本文为《剖析 | SOFARPC 框架》第九篇，作者米麒麟，目前就职于陆金所。","dir":"blog/sofa-rpc-graceful-exit/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6a1f6847a5ecf97e90a3a06c36f39246","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-graceful-exit/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-graceful-exit/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 优雅关闭剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-graceful-exit/","wordcount":3972},{"author":"明不二","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十篇，作者明不二，就职于华为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 RPC 框架需要创造一种调用远程服务如同调用本地般的体验，因此在实现一个基于 RPC 框架的微服务架构的系统时，服务消费者（客户端）往往只需要知道服务端提供了哪些接口和方法，并不需要知道服务具体由哪些 IP 在提供。RPC 框架本身的服务发现和路由寻址功能解决了如何知道目标地址的问题，该过程对于 RPC 客户端调用方来说应该是完全透明的。\n在这个过程中，RPC 框架需要接入注册中心来完成服务发现和路由寻址的功能。同时，在应用大规模请求时，微服务系统还需要对请求服务集群化，同时通过负载均衡来达到降低访问压力的效果。\n本文我们会先介绍一下注册中心，然后介绍一下 SOFRPC 中的几种路由，最后会介绍一下负载均衡的几种比较。\n注册中心支持 首先我们简要介绍一下注册中心的原理。\n服务端推送地址给注册中心，注册中心将地址进行合并后，推送给客户端。\n其中，注册中心的场景依赖于各类注册中心的实现。在这里，SOFARPC 提供了注册中心的抽象类 Registry，该抽象类提供了注册中心的配置、启动、注册、反注册、订阅等方法。客户端在接入过程中，可以通过配置来激活 Zookeeper、Consul、local 等注册中心注册进启动类中，当请求到来时，可以通过注册中心进行相应的路由。\n注册中心的抽象类如下：\n在这个接口的基础上，目前内置实现了几种注册中心，包括即将合并的。\nLocal注册中心(Local) Local 注册中心是 SOFARPC 自己实现的一个本地注册中心，该注册中心的实现主要由类 LocalRegistry提供，可以调用其 register(ProviderConfig config) 方法实现服务的注册，主要是文件的读写。\n实现原理很简单，通过在本地注册文件来保存服务的发布和订阅信息。\nZookeeper注册中心(Zookeeper) Zookeeper 接入 SOFARPC 的实现类为 ZookeeperRegistry。目前是 SOFARPC 中默认的注册中心实现。也是大多数情况下，可以方便使用的。\nZookeeper 是一个分布式协调服务，用于维护配置信息、命名、提供分布式同步功能以及提供组服务等。Zookeeper 提供了服务注册与发现的解决方案，提供了简单的 API，可以让集成者简洁调用。\n当要发布一个 SOFARPC 服务时，首先需要在 zookeeper 中注册服务提供者的相关信息，包括：该服务接口隶属于哪个系统、服务的 IP 以及端口号、服务的请求 URL 和服务的权重等等。zookeeper 在这个过程中，注意负责对 SOFARPC 中的服务信息进行中心存储，同时负责把服务注册信息的更新及时通知到服务消费者。\n作为服务调用者，SOFARPC 调用端在调用时，若走的路由链路中有注册中心，则会从注册中心中获取到服务注册的相关信息，然后在调用时会根据负载均衡策略来发送请求。\nConsul注册中心(Consul) Consul 注册中心与 SOFARPC 之间的对接主要依赖于 ConsulRegistry类。\n该注册中心在功能表现上与 zookeeper 看起来一致。对比起 Zookeeper 来，Consul 支持多数据中心，同时支持 http 和 dns 等接口，有着多语言的能力。\n其他注册中心 目前已经在开发中的有 Nacos，SOFAMesh 等。也可以根据自己的场景，进行方便的扩展。\n路由设计 路由原理和设计 在阅读本部分之前，请大家注意：路由是为了选中一组地址。\nSOFARPC 通过对各类注册中心的支持，实现了服务发现、路由寻址的功能。访问客户端时，请求的路由可以由以下一些实现类实现：DirectUrlRouter、RegistryRouter、CustomRouter，上述三个路由实现类分别对应了直接地址路由（不需要经过注册中心直接路由直连到某个地址）、注册中心路由、以及客户自定义路由等。路由从 AddressHolder 获取到地址，同时通过各种负载均衡算法进行负载均衡，请求到相应的系统接口。\n首先我们看一下整个路由寻址过程的阶段。\n这 SOFARPC 中，路由可以分为地址直连路由、注册中心路由以及客户定制化路由。这以上三个路由均扩展了 Router 抽象类。服务路由的抽象类代码如下：\n这里的核心代码是 route 这个方法，将本次请求的信息，和服务列表进行计算。当客户端请求到达 Router 时，会根据请求的参数信息从 Router 和连接管理器中获取请求地址，通过调用 route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) 方法达到路由寻址的目的。\n其中，路由并不是一个非此即彼的过程，这些可选的路由是由用户和系统的配置，被构造成一个路由链来执行的。这样。就可以有一些兜底的逻辑，如指定了 IP 地址，那我们就直接路由到这个地址，如果没有，就进行注册中心的路由等等。\n直连(DirectUrlRouter) 直接路由是比较简单的，因为有专门的配置，所以地址列表这些都是可以很方便地进行识别，在客户端配置时，可通过如下方式配置：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); 直接地址路由扩展了 Router 抽象类的实现，在重写的 route 方法中，直接获取配置好的直接路由地址。当请求到来时，直接从地址管理列表中，拿到对应的地址，就实现了直接地址路由的功能。\n注册中心(RegistryRouter) 注册中心路由同样扩展了 Router 抽象方法，这个 Router是大多数情况下使用最多的路由，主要是从本应用使用的注册中心中获取对应的地址，并进行路由寻址等。后面我们会介绍目前注册中心的几个内置实现。\n自定义(CustomRouter) 客户定制化路由可以配置客户自己所定制的路由实现，可以参考直接地址路由或者注册中心路由的实现，扩展 Router 类即可。\n这里的使用场景：\n一种是对于某些用户来说，在注册中心的场景下，用户认为所有的地址并不是等价的。会对地址进行人为拆分，使用方保存了自己的的所有服务提供方地址（或者是通过某种方法查询），然后重写路由定制逻辑，通过方法级别进行地址的选择。\n另一 …","date":1539154800,"description":"本文为《剖析 | SOFARPC 框架》第十篇，作者明不二，就职于华为。","dir":"blog/sofa-rpc-routing-implementation/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dc2f04fd097731619e17f7da6a24ae6a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-routing-implementation/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-routing-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 路由实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-routing-implementation/","wordcount":3769},{"author":"敖小剑","categories":"SOFAMesh","content":" 本文是SOFAMesh中的多协议通用解决方案x-protocol介绍系列文章之一。\n 前言 在2018年上半年，蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决方案，在6月底对外公布了 SOFAMesh，详情请见之前的文章: 大规模微服务架构下的Service Mesh探索之路 。\n在 SOFAMesh 的开发过程中，针对遇到的实际问题，我们给出了一套名为 x-protocol 的解决方案，定位是云原生、高性能、低侵入性的通用 Service Mesh 落地方案，依托 Kubernetes 基座，利用其原生的服务注册和服务发现机制，支持各种私有 RPC 协议低成本、易扩展的接入，快速享受 Service Mesh 所带来的红利。\n具体解决的问题包括：\n 多通讯协议支持问题，减少开发工作量，简单快捷的接入新协议 尽量提升性能，提供更灵活的性能与功能的平衡点选择，满足特定高性能场景 兼容现有SOA体系，提供通过接口进行访问的方式，实现不修改业务代码也能顺利接入 Service Mesh 支持单进程多服务的传统SOA程序，可以在微服务改造之前，先受益于 Service Mesh 带来的强大功能 在本系列文章中，我们将对此进行详细的讲解，首先是“DNS通用寻址方案”。\n背景和需求 SOA的服务模型 在SOFAMesh计划支持的RPC框架中，SOFARPC、HSF、Dubbo都是一脉相承的SOA体系，也都支持经典的SOA服务模型，通常称为”单进程多服务”，或者叫做”单进程多接口”。（备注：由于服务一词使用过于频繁，下文都统一称为接口以便区分）\nSOA标准的服务注册，服务发现和调用流程如下：\n 在单个SOA应用进程内，存在多个接口 服务注册时，以接口为单位进行多次独立的服务注册 当客户端进行调用时，按照接口进行服务发现，然后发起调用 当我们试图将这些SOA架构的应用搬迁到ServiceMesh时，就会遇到服务模型的问题：微服务是单服务模型，也就是一个进程里面只承载一个服务。以Kubernetes的服务注册为例，在单进程单服务的模型下，服务名和应用名可以视为一体，Kubernetes的自动服务注册会将应用名作为服务注册的标示。\n这就直接导致了SOA模型和微服务模型的不匹配问题：\n SOA以接口为单位做服务注册和服务发现，而微服务下是服务名 SOA是”单进程多接口”，而微服务是”单进程单服务” 一步接一步的需求 先上车后补票 最理想的做法当然是先进行微服务改造，实现微服务拆分。但是考虑到现有应用数量众多，我们可能更愿意在大规模微服务改造之前，先想办法让这些应用可以运行在ServiceMesh下，提前受益于Service Mesh带来的强大功能。因此，我们需要找到一个合适的方案，让ServiceMesh支持没有做微服务改造依然是”单进程多接口”形式的传统SOA应用，所谓”先上车后补票”。\n 不修改代码 考虑到原有的SOA应用，相互之间错综复杂的调用关系，最好不要修改代码，即保持客户端依然通过接口名来访问的方式。当然，SOA架构的客户端SDK可能要进行改动，将原有的通过接口名进行服务发现再自行负载均衡进行远程调用的方式，精简为标准的Servicemesh调用（即走Sidecar），因此修改SDK依赖包和重新打包应用是不可避免。\n 支持带特殊字符的接口名 Kubernetes的服务注册，Service名是不能携带”.“号的。而SOA架构下，接口名有时出于管理方便，有可能是加了域名前缀，如”com.alipay.demo.interface-2”。为了实现不修改原有代码，就只能想办法支持这种带特殊字符的接口名。\n参考Kubernetes和Istio 在进一步讨论解决方案之前，我们先来看一下kubernetes和Istio中的标准请求寻址方式。\n 备注：过程稍显复杂，涉及到Kubernetes/Istio的一些底层细节。但是了解这个过程对后续的理解非常重要，也可以帮助大家了解Kubernetes和Kubernetes的工作原理，强烈推荐阅读。\n Kubernetes下的DNS寻址方式 在Kubernetes下，如图所示，假定我们部署了一个名为userservice的应用，有三个实例，分别在三个pod中。则应用部署之后，Kubernetes会为这个应用分配ClusterIP和域名，并在DNS中生成一条DNS记录，将域名映射到ClusterIP：\n当部署在Kubernetes下的某个充当客户端的应用发起请求时，如图中的HTTP GET请求，目标URL地址为 http://userservice/id/1000221。请求的寻址方式和过程如下：\n 首先进行域名解析，分别尝试解析”userservice”/“userservie.default.svc.cluster.local”等域名，得到ClusterIP 然后客户端发出请求的报文，目标地址为ClusterIP，源地址为当前客户端所在的pod IP（简单起见，端口先忽略） 请求报文随即被kube-proxy拦截，kube-proxy根据ClusterIP，拿到ClusterIP对应的多个实际服务实例所在的pod ip，取其中一个，修改目标地址为这个pod IP 请求报文最终就被发送到服务实例所在的pod IP 应答回来的方式类似，userservice发出的应答报文会被kube-proxy拦截并修改为发送到客户端所在的pod IP。\n我们详细看一下请求和应答全称的四个请求包的具体内容（简单起见继续忽略端口）：\n重点关注请求和应答报文的源地址和目标地址：\n 客户端发出的请求，为”客户端到ClusterIP” kube-proxy拦截到请求后，将请求修改为”客户端到服务器端” 服务器端收到请求时，表现为”客户端到服务器端”，ClusterIP被kube-proxy屏蔽 服务器端发送应答，因为收到的请求看似来自客户端，因此应答报文为”服务器端到客户端” 应答报文被kube-proxy拦截，将应答修改为”ClusterIP到服务器端” 客户端收到应答，表现为”ClusterIP到服务器端”，服务器端IP被kube-proxy屏蔽 kube-proxy在客户端和服务器端之间拦截并修改请求和应答的报文，联通两者，但各自屏蔽了一些信息：\n 在客户端看来它是在和ClusterIP交互，userservice的具体服务器端实例对客户端是无感知的 在服务器端看来，客户端是直接在和它交互，ClusterIP的存在对服务器端是无感知的 更深入一步，看kube-proxy在两个拦截和修改报文中的逻辑处理关系，即kube-proxy是如何在收到应答时正确的找回原有的ClusterIP：\n 在拦截并修改请求报文之后，kube-proxy会保存报文修改的5元组对应关系（5元组指源IP地址，源端口，协议，目的地IP地址，目的地端口） 在收到应答报文后，根据应答报文中的5元组，在保存的5元组对应关系中，找到对应信息，得到原有的ClusterIP和端口，然后修改应答报文 总结，通过上述Kubernetes下的寻址方式，客户端只需发送带简单寻址信息的请求（ …","date":1538982000,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，首先介绍的是DNS通用寻址方案。","dir":"blog/sofa-mesh-x-protocol-common-address-solution/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6429061afc56c5832c17b541943498e6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","publishdate":"2018-10-08T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","summary":"本文是SOFAMesh中的多协议通用解决方案x-protocol介绍系列文章之一。 前言 在2018年上半年，蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","wordcount":5813},{"author":"水寒","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第八篇，作者水寒，目前就职于网易。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕，文末提供了已完成的文章目录。\n 前言 在本系列之前的文章中，我们已经介绍了同步，异步，泛化调用等，也介绍了链路追踪的能力，本篇，我们将介绍一下 SOFARPC 中另一种内置的数据透传的能力。会依次介绍，数据透传的概念， SOFARPC 的设计原理，以及各种不同调用方式下的透传使用和详细说明，最后， 还会比较一下和 SOFATracer 的区别。欢迎大家与我们讨论交流。\n数据透传介绍 首先，我们介绍一下数据透传的概念，我们知道，在 RPC调用中，数据的传递，是通过接口方法参数来传递的，需要接口方定义好一些参数允许传递才可以，在一些场景下，我们希望，能够更通用的传递一些参数，比如一些标识性的信息。业务方可能希望，在每一次调用请求中都能够传递一些自定义的信息到下游。甚至也希望下游能够将一些数据传递回来。\n而数据透传功能，就是指数据不需要以作为方法参数的形式在调用链路中进行传递，而是直接存储到调用上下文中，之后通过 RPC 的内置对象，进行传递，调用双端可从上下文中获取数据而不需要去关注数据的传输过程。\nSOFARPC 提供的数据透传支持请求数据透传（客户端向服务端）和响应数据透传（服务端向客户端）。\nSOFARPC 设计原理 这里主要是介绍一下，实现的核心原理，更加具体的每种调用方式的透传，在后文中都会详细介绍。\n 用户通过 SOFARPC 提供的 API 进行数据传递设置\n SOFARPC 在调用传输前，将透传的数据进行打包获取\n 进行正常的序列化和反序列化\n SOFARPC 在反序列化时将用户设置的透传数据写回 Context\n 服务端用户即可进行获取使用\n 不同调用方式的透传 我们知道，SOFARPC 目前支持四种调用模式，如果没有阅读过之前文章的同学，可以阅读一下 SOFARPC 同步异步实现剖析，请求透传数据的原理都是一样的，服务端设置响应透传数据的原理也是一样的，只是客户端获取响应透传数据的方式有所不同（后三种模式只介绍客户端获取响应透传数据的原理）。因此我们会介绍下不同调用方式的透传细节，并介绍其使用方式，方便大家理解。以下为了方便说明，我们会使用如下的接口示例：\n接口服务 public interface HelloService { String sayHello(String string); } 服务实现 public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string) { // 获取请求透传数据并打印 System.out.println(\u0026amp;quot;service receive reqBag -\u0026amp;gt; \u0026amp;quot; + RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;req_bag\u0026amp;quot;)); // 设置响应透传数据到当前线程的上下文中 RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;resp_bag\u0026amp;quot;, \u0026amp;quot;s2c\u0026amp;quot;); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; ！\u0026amp;quot;; } } 后续的所有调用模式都使用HelloServiceImpl这个服务实现。(示例代码在 SOFARPC 的 测试 case 中都要对应的示例，大家可以对应阅读。)\n对用户可见的操作 API 只有一个就是 RpcInvokeContext，在 SOFABoot 和 SOFARPC 下都适用，当然如果你了解 SOFARPC 的 Filter 机制，也可以通过扩展这个来实现。\nsync 调用下的透传 使用示例 原理剖析 请求透传数据 客户端首先在 main 线程（图中的user thread）中设置请求透传数据到其调用上下文RpcInvokeContext.requestBaggage属性中，之后在调用过程中从requestBaggage中取出请求透传数据并设置到SofaRequest.requestProps属性中； 服务端接收到请求SofaRequest对象后，在其调用链中的 ProviderBaggageFilter#invoke 方法中会先从SofaRequest.requestProps中取出请求透传数据并设置到当前服务端线程的调用上下文RpcInvokeContext.requestBaggage属性中，最后业务代码就可以从调用上下文中获取请求透传数据了。 响应透传数据 服务端设置响应透传数据到其调用上下文RpcInvokeContext.responseBaggage属性中，之后在ProviderBaggageFilter#invoke 方法中先从responseBaggage中取出响应透传数据并设置到SofaResponse.responseProps属性中； 客户端main线程被唤醒后，先从SofaResponse.responseProps中获取响应透传数据，之后将响应透传数据设置到其调用上下文RpcInvokeContext.responseBaggage中，最后业务代码就可以从调用上下文中获取响应透传数据了。 oneway 调用下的透传 使用示例 原理剖析 在 oneway 模式下，客户端不接受服务端响应，也不会获取响应透传数据。\nfuture 调用下的透传 使用示例 原理剖析 客户端获取响应透传数据 future 模式在 SOFARPC 内部会被转化为 callback 的方式进行调用，在 callback 对象中会存储main线程的调用上下文；当客户端接收到响应时，会执行该 callback 对象的回调函数，在其回调函数中，对于响应透传数据，会做如下操作：\n 从SofaResponse.responseProps中获取响应透传数据\n 从 callback 对象中获取 main 线程的调用上下文\n 设置响应透传数据到 main 线程的调用上下文\n 将 main 线程上下文拷贝到当前的回调线程中\n 实际上，第三步与第四步在 SOFARPC 源码中顺序相反，本文这样解读是为了更容易理解。这样无论是 future 模式（从 main 线程的调用上下文获取响应透传数据）还是 callback 模式（从回调线程的调用上下文获取响应透传数据），都可以顺利的获取到响应透传数据。\ncallback 调用下的透传 使用示例 原理剖析 与 future 模式原理一样，只是最终业务代码中是从回调线程而不是main …","date":1538550000,"description":"本文为《剖析 | SOFARPC 框架》第八篇，作者水寒，目前就职于网易。","dir":"blog/sofa-rpc-data-transmission/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a26f5f1db99edadf48c406492ccdcaf8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-data-transmission/","publishdate":"2018-10-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-rpc-data-transmission/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 数据透传剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-data-transmission/","wordcount":2528},{"author":"莫那·鲁道","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第七篇，作者莫那·鲁道 ，来自 E签宝。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 我们知道，在 RPC 调用中，客户端需要加载服务端提供的接口定义类，但是，很多情况下，这个并不总是可行的，于是，衍生了泛化调用的需求，一个成熟的，功能完善的 RPC 框架一般都会支持泛化调用，那么什么是泛化调用呢？SOFA RPC 又是如何支持泛化调用的？同时又是如何实现的？ 和其他的 RPC 泛化调用又有何不同？有何优势？我们将在本文一一解答这些问题。\n泛化调用介绍 当客户端因为某种原因无法得到服务提供方的接口 jar 包时，或者是客户端是一个比较通用的系统，并不想依赖每个服务提供方提供的 facade接口，但是又需要进行调用，那么此时就需要进行泛化调用。\n例如： 1. 当分布式系统由多个语言开发，假设是 Node Js ，同时 Node Js 需要调用 Java 语言的 RPC 服务，那么，我们就需要在两者之间架设适配层，让适配层处理 Node Js 的请求后再转发给 Java 的 RPC 服务。 2. 一些中间系统的功能，比如某些内部网关，需要以一个统一的方式实现对其他下游系统的调用（非 SPI的情况），逐个依赖下游的包显然是不可能的。 3. 一些流量回放类的线上系统，可以将数据采集拦截，之后，通过泛化调用回放，而不需要依赖全站的应用。\n那么这种情况下，肯定不能包含所有接口的 jar 文件，否则就太臃肿了。实际上也是不现实的，总不能每增加一个服务端，就增加一个 jar 包依赖，然后应用进行发布重启。\n这个时候就可以使用泛化调用，将相应的请求包装成泛化调用，就能够实现不依赖接口 jar 包，多语言调用 RPC 服务，避免重复开发。\nSOFA RPC 的泛化调用使用 SOFA RPC 的官方文档十分详细，在官方 wiki 泛化调用 中，已有详细介绍。同时，在源码中的 example 模块中，也有现成的 demo 可以跑起来，读者可以自己 clone 源码阅读，这里我们简要说明一下使用方式，以便大家有一个直观的了解。\n接口定义 总的来说，泛化调用有 2 个 API，包含 5 个方法，其中， 2 个方法已经废弃，也就是说，有 3 个主要方法。分别是：\n/** * 泛化调用 * @return 正常类型（不能是GenericObject类型） */ Object $invoke(String methodName, String[] argTypes, Object[] args); /** * 支持参数类型无法在类加载器加载情况的泛化调用 * @return 除了JDK等内置类型，其它对象是GenericObject类型 */ Object $genericInvoke(String methodName, String[] argTypes, Object[] args); /** * 支持参数类型无法在类加载器加载情况的泛化调用 * @return 返回指定的T类型返回对象 */ \u0026amp;lt;T\u0026amp;gt; T $genericInvoke(String methodName, String[] argTypes, Object[] args, Class\u0026amp;lt;T\u0026amp;gt; clazz); \\$invoke 该方法使用场景：用户知道参数类型和返回值类型，那么就可以使用该方法。 \\$genericInvoke 该方法是个重载方法，重载一的使用场景是：如果你的应用不知道接口的参数类型和返回值类型，这个时候，你就需要使用 GenericObject 类，来包装返回值和参数。 \\$genericInvoke 重载二的使用场景是：如果应用不知道接口参数类型，但是知道接口返回值的类型，那么就不需要使用 GenericObject 作为返回值了。 基本上，已经覆盖了常用的集中场景，可以说功能相当全面。\n泛化使用 由于篇幅有限，这里就不贴使用 demo 了，感兴趣的可以通过链接查看官方的 demo 或者源码，包含 SOFARPC 的 API 使用方式和 SOFABoot 的使用方式：\n demo wiki 地址：用户手册-\u0026amp;gt;基本特性-\u0026amp;gt;泛化调用 源码地址：示例源码 SOFARPC 泛化调用的设计与实现 接下来我们重点来介绍 SOFARPC 是如何实现泛化调用的。\n框架调用设计 简单来说，泛化调用的关键就是对象表示和序列化，SOFARPC 提供了 GenericObject 等对象来表示参数对象或者返回值对象，而将 GenericObject 对象序列化成目标对象，或者将返回值反序列化成 GenericObject 对象，是 SOFARPC 实现泛化的关键。\n这里我们先来看一下 SOFARPC 泛化调用的流程图，有助于后面理解泛化实现。\n我们来说一下这个图： 1. 泛化 API 调用时，会加载泛化过滤器，作用是做一些参数转换，同时设置序列化工厂类型。 2. SOFARPC 在使用 SOFABolt 进行网络调用前，会创建 context 上下文并传递给 SOFABolt，上下文中包含着序列化工厂类型信息，这个信息将决定使用何种序列化器，同时这个上下文将流转于整个调用期间。 3. 在 SOFABolt 正式发送数据之前，会将 GenericObject 对象序列化成普通对象的字节流，这样，服务提供方就不必关心是否为泛化调用，从图中可见，提供方不用对泛化调用做任何改变 —— 这是 SOFARPC 泛化区别于其他 RPC 泛化的关键。 4. 当提供方成功接收请求后，使用普通序列化器即可反序列化数据，只需要正常调用并返回即可。 5. 当消费者的 SOFABolt 接收到响应数据后，便根据 context 的序列化类型，对返回值做反序列化，即将普通的字节流反序列化成 GenericObject 对象 —— 因为客户端有可能不知道返回值的 Class 类型。 6. 最终，泛化 API 即可得到 GenericObject 类型的返回值。\n从上面的流程可以看出，序列化器在泛化调用中，占了极大的篇幅和作用。而 SOFARPC 针对泛化调用，对 hessian3 进行了改造，使其支持泛化调用所需要的序列化功能。SOFA-Hessian的改动可以参考这里。\nHessian 泛化实现 SOFA-Hessian 在 hessian 的包中加入了 com.alipay.hessian.generic 包，此包的作用就是处理泛化调用，重写的关键是实现或继承 SerializerFactory 类和 Serializer、Deserializer 等接口。在这里，设计了一下几个类，来描述对应的类型信息，同时实现这几个类的序列化和反序列化。对应关系如下： …","date":1537945200,"description":" 本文为《剖析 | SOFARPC 框架》第七篇，作者莫那·鲁道 ，来自 E签宝。","dir":"blog/sofa-rpc-generalized-call-implementation/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"de327dfe502c28ef0f926f17b29a6c80","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","publishdate":"2018-09-26T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 泛化调用实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","wordcount":3226},{"author":"畅为","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第六篇，作者畅为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 一. 前言 对于金融业务而言每个环节都涉及到大量的资金操作，若因为网络、硬件等原因导致系统不稳定性，不仅影响用户体验，更重要的是可能会引起资损问题，因此系统可用性至关重要。在微服务分布式架构中提高系统可用性的常见方案是 集群（冗余）。 集群方式将一个服务部署在多个机器上，通过硬负载或软负载实现服务的均衡负载，虽然可以有效避免单点问题，但是仍然避免不了某些场景单机故障引起服务调用失败的问题。\nSOFARPC 提供了自动单机故障剔除能力，能够自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复，提高系统可用性。本文将从以下几个方面进行剖析：\n 单机故障和服务降级介绍\n SOFARPC 单机故障剔除原理\n 二. 单机故障和服务降级 在分布式架构中常见可用性方案的是 集群（冗余），即将一个服务部署在多个机器上，通过硬负载或软负载实现服务的均衡负载。硬件负载因每次请求都需要经过硬件负载，承担所有的访问压力，当集群规模增加、流量增多，硬件负载可能因无法支撑所有流量而导致系统不可用。\n软负载则提供注册中心，并将负载能力转移到服务调用方( Consumer )，注册中心只有在 Consumer 首次订阅或服务发生变化时才会发生交互，避免了并发访问下的单点问题。下图是基于软负载的服务调用：\n虽然软负载可以避免单点问题，但可能存在以下场景导致服务不可用：\n Provider 出现单点故障或宕机，与 Consumer 的长连接已断开，但注册中心尚未摘除或未及时通知Consumer。\n Consumer 和 Provider的长连接还在，注册中心未下发摘除，但服务器端由于某些原因，例如长时间的 Full GC, 硬件故障（后文中为避免重复，统一描述为机器假死）等场景，处于假死状态。\n 这两种场景都是服务端出现故障，但由于长连接还保留等原因注册中心未摘除服务，导致服务调用失败。针对第一种情况 Consumer 不应调用出现故障的 Provider，否则会引起部分服务不可用；针对第二种情况，这个 Consumer 应该不调用或少调用该 Provider，可以通过权重的方式来进行控制。目前 SOFARPC 5.3.0 以上的版本支持 RPC 单机故障剔除能力。SOFARPC 通过服务权重控制方式来减少异常服务的调用，将更多流量打到正常服务机器上，提高服务可用性。\n2.1 SOFARPC故障剔除 vs 注册中心故障剔除 SOFARPC 的故障剔除与注册中心故障服务剔除不同，它们从不同的维度来完成故障剔除提高服务可用性。主要两方面的区别：\n 故障剔除的时机\n 故障剔除的细粒度\n 故障剔除的时机 SOFARPC 的故障剔除与注册中心故障服务剔除不同，它们从不同的维度来完成故障剔除提高服务可用性。注册中心服务管理关注 Provider 与注册中心的心跳或长连接。如果 Provider 出现心跳异常或长连接不存在，则及时将服务从注册中心剔除，并告知 Consumer 移除本地缓存的故障 Provider 信息。Comsumer 在负载均衡选择时则不考虑被剔除的 Provider，如图所示：\n而 SOFARPC 单机故障剔除针对的场景不同，针对的是注册中心还未剔除的服务，这些服务与 Consumer 仍然保持长连接，但由于机器假死，不能提供正常服务。 如下图所示：\n故障剔除的细粒度 注册中心剔除的是粒度是针对单机上的某个服务进程，属于进程级别。一旦这个进程和注册中心断开连接或心跳无感应，则将其从注册中心剔除。\nSOFARPC 故障剔除并控制精度会更精细一些，会细致到进程对外暴露的服务，如部署在某个机器上的交易系统对外提供的交易查询服务 TransQueryService. 管理的维度是 IP + 服务， 这里的服务特指进程中的服务接口。\n2.2 服务权重降级 vs 服务降级 服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。这里的降级级别是整个系统服务，而不是针对接口级别。\nSOFARPC 的服务降级，是指当某些个别机器因为存在机器假死，导致处于假死状态，导致一些服务接口响应异常，通过 SOFARPC 的故障剔除和服务权重降级来减少对这些异常机器接口的访问，而将更多的流量打到正常的机器上。 这里针对的维度主要还是 IP + 服务维度，如部署在 xxx 机器上交易系统对外提供的 TransQueryService 服务。\n三. 原理解析 通常一个服务有多个服务提供者，其中部分提供者可能由于机器假死等导致长连接还存活但是程序已经无法正常响应 。 故障剔除功能会将这部分异常的服务提供者进行降级，使得客户端的请求更多地指向健康节点。当异常节点的表现正常后，故障剔除功能会对该节点进行恢复，使得客户端请求逐渐将流量分发到该节点。\nSOFARPC 5.3.0 以上支持故障剔除的功能，故障剔除功能采用自动化监控和降级，因此可以减少人工干预，提供系统可用率。SOFARPC 剔除的维度是服务 + Ip 级别。为了支持单机故障剔除能力，SOFARPC 提供了以下几个方面的设计：\n 入口设计: 进行RPC调用的时候，增加一个信息统计的传递入口。SOFARPC 采用无缝插入设计，在不破坏开放封闭原则前提下引入单机故障剔除能力。\n 信息收集器 : 维护和管理从入口传进来的统计信息。\n 计算策略 : 主要是根据度量结果，判断是否需要执行降级或者恢复服务。如果命中降级规则，则触发降级行为。如果命中恢复规则，则触发恢复行为。\n 度量策略 : 负责按一定维度对调用信息做度量，判断服务正常或异常。\n 降级策略 : 如果服务异常，需要进行降级处理，降级策略指定了处理逻辑，比如按打印日志或降低服务权重。\n 恢复策略 ：当一个异常服务恢复正常时，如何恢复该服务，例如提高服务权重等。\n 3.1 整体结构和入口 《SOFARPC 链路追踪剖析》中已介绍 SOFARPC 的 内核设计和总线设计，和链路追踪功能一样，SOFARPC 单机故障剔除能力也是基于内核设计和总线设计，做到可插拔、零侵入。\nSOFARPC 单机故障剔除模块是 FaultToleranceModule， 通过 SOFARPC 的 SPI 机制完成模块的自动化加载，以完成该功能的插入。 FaultToleranceModule 模块包含了两个重要部分：\n subscriber 事件订阅器 。 通过订阅事件总线 EventBus 的事件，以零侵入方式完成 RPC 调用的统计和信息收集。\n regulator 调节器 。 根据收集的 RPC 调用信息，完成服务调用或服务权重的调节，达到服务 …","date":1537167600,"description":"本文为《剖析 | SOFARPC 框架》第六篇，作者畅为。","dir":"blog/sofa-rpc-single-machine-fault-culling/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3171526788b6f17e3ffa37512918729f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","publishdate":"2018-09-17T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 单机故障剔除剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","wordcount":5281},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第五篇。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 上一篇，我们介绍了 SOFARPC 同步异步的实现，本文我们将会介绍 SOFARPC 中的线程模型。\n本文会从同步异步，阻塞非阻塞开始讲起，进而探讨常见的线程模型设计，之后，我们会介绍下 SOFABolt 中对 Netty 的模型使用，最后 SOFARPC 在一次调用过程中各个步骤执行的线程。\n几种常见的 IO 模型 首先介绍一下 Linux 的几种 IO 模型，以进程从 Socket 中读取数据为例。实际上，进程最终是通过 recvfrom 系统调用来读取数据。这个时候，系统内核在收到之后，根据 IO 模型的不同，处理是不同的。\n注意，图下的红色部分表示阻塞时间。\n阻塞 I/O 阻塞 I/O(blocking I/O) 模型是最流行，最简单易用的 I/O 模型，默认情况下，所有套接字和文件描述符就是阻塞的。阻塞 I/O 将使请求进程阻塞，直到请求完成或出错。\n非阻塞 I/O 非阻塞 I/O(nonblocking I/O)的含义：如果 I/O 操作会导致请求进程休眠，则不要把它挂起，也就是不会让出 CPU，而是返回一个错误告诉它（可能是 EWOULDBLOCK 或者 EAGAIN）。\nI/O 复用 I/O 多路复用(I/O multiplexing)会用到 select 或者 poll 或者 epoll 函数，这几个函数也会使进程阻塞，但是和阻塞 I/O 所不同的的，函数可以同时阻塞多个 I/O 操作。而且可以同时对多个读操作，多个写操作的 I/O 函数进行检测，直到有数据可读或可写时，才真正调用 I/O 操作函数。\n信号驱动式 I/O 信号驱动 I/O(signal-driver I/O)使用信号，让内核在描述符就绪时发送 SIGIO 信号通知我们进行处理，这时候我们就可以开始真正的读了。\n异步 I/O 异步 I/O(asynchronous I/O)由 POSIX 规范定义，包含一系列以 aio 开头的接口。一般地说，这些函数的工作机制是：告知内核启动某个操作，并让内核在整个操作（包括将数据从内核空间拷贝到用户空间）完成后通知我们。\n这种模型与信号驱动模型的主要区别是：信号驱动 I/O 是由内核通知我们何时可以启动一个 I/O 操作，而异步 I/O 模型是由内核通知我们 I/O 操作何时完成。\n汇总 综上，我们给出一个大家比较熟知的比较图。方便理解。\nJAVA BIO \u0026amp;amp; NIO 在了解了内核层面上这几个线程模型之后，我们要给大家介绍下 JAVA BIO 和 JAVA NIO。\nJAVA BIO 首先我们给大家看一个直接使用 JAVA BIO 写得一个服务端。\n传统的BIO里面socket.read()，如果TCP RecvBuffer里没有数据，调用会一直阻塞，直到收到数据，返回读到的数据。\nJAVA NIO 对于 NIO，如果 TCP 的 buffer 中有数据，就把数据从网卡读到内存，并且返回给用户；反之则直接返回0，永远不会阻塞。下面是一段比较典型的 NIO 的处理代码。\n在我们可以将 JAVA NIO 和多路复用结合起来。这里也是最简单的 Reactor 模式：注册所有感兴趣的事件处理器，单线程轮询选择就绪事件，执行事件处理器。\n这里简单比较了一下以前的 BIO 和现在的 NIO，新的 NIO 给我们带来了如下的好处。\n 事件驱动模型\n 单线程处理多任务\n 非阻塞 I/O，I/O 读写不再阻塞，而是返回 0\n 基于快的传输，比基于流的传输更高效\n 更高级的 IO 函数，零拷贝\n 允许 IO 多路复用\n Reactor 线程模型 前面说了，我们有了 JAVA NIO ，可以用多路复用。有些同学可能会问，不能直接使用吗？答案是可以直接使用，\n但是技术层面上的问题虽然解决了，在工程层面，实现一个高效没有问题的架构依然很难，而且这种多路复用，对编程思维有比较大的挑战，所以，工程层面还不够。因此，有了 Reactor 编程模型\n一般情况下，I/O 复用机制需要事件分发器，以上这个分发事件的模型太简单了。实际使用起来会有一些性能问题。目前比较流行的是 Reactor 和 Proactor，本文不介绍 Proactor 模型，有兴趣的同学可以自己学习。\n标准/典型的 Reactor 中定义了三个角色：\n而一个标准的操作流程则是：\n 步骤1：等待事件到来（Reactor 负责）。\n 步骤2：将读就绪事件分发给用户定义的处理器（Reactor 负责）。\n 步骤3：读数据（用户处理器负责）。\n 步骤4：处理数据（用户处理器负责）。\n 在这个标准之下，Reactor 有几种演进模式可以选择。注意 Reactor 重点描述的是 IO 部分的操作，包括两部分，连接建立和 IO 读写。\n单线程模型 Reactor 单线程模型指的是所有的 IO 操作都在同一个NIO 线程上面完成，NIO 线程的职责如下：\n 作为 NIO 服务端，接收客户端的 TCP 连接；\n 作为 NIO 客户端，向服务端发起 TCP 连接；\n 读取通信对端的请求或者应答消息；\n 向通信对端发送消息请求或者应答消息。\n 这是最基本的单 Reactor 单线程模型。其中 Reactor 线程，负责多路分离套接字，有新连接到来触发 connect 事件之后，交由 Acceptor 进行处理，有 IO 读写事件之后交给 hanlder 处理。\nAcceptor 主要任务就是构建 handler，在获取到和 client 相关的 SocketChannel 之后 ，绑定到相应的 handler上，对应的 SocketChannel 有读写事件之后，基于 reactor 分发，hanlder 就可以处理了（所有的 IO 事件都绑定到 selector 上，由 Reactor 分发）。\n该模型 适用于处理器链中业务处理组件能快速完成的场景。不过，这种单线程模型不能充分利用多核资源，所以实际使用的不多。\n多线程模型 Reactor 多线程模型与单线程模型最大的区别就是将 IO 操作和非 IO 操作做了分离。效率提高。\nReactor 多线程模型的特点：\n 有专门一个 NIO 线程-Acceptor 线程用于监听服务端，主要接收客户端的 TCP 连接请求；\n 网络 IO 操作-读、写等由一个单独的 NIO 线程池负责，线程池可以采用标准的 JDK 线程池实现，它包含一个任务队列和 N 个可用的线程，由这些 NIO 线程负责消息的解码、处理和编码；\n 主从多线程模型 这个也是目前大部分 RPC 框架，或者服务端处理的主要选择。\nReactor 主从多线程模型的特点：\n服务端用于接收客户端连接的不再是个1个单独的 NIO 线程，而是一个独立的 NIO 线程池。\n主要的工作流程： …","date":1536735600,"description":"本文为《剖析 | SOFARPC 框架》第五篇。","dir":"blog/sofa-rpc-threading-model/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fbde29dd299a8163dafa9d571d1714e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-threading-model/","publishdate":"2018-09-12T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-threading-model/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 线程模型剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-threading-model/","wordcount":3410},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第四篇。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 这一篇，我们为大家带来了开发过程中，最常接触到的同步异步调用解析。本文会介绍下同步异步的使用场景，以及 SOFARPC 中的代码实现机制，为了方便大家理解和阅读代码。不会过多的设计代码实现细节，更多的还是希望大家从中有所收获，并能够独立阅读核心代码。\n原理剖析 SOFARPC 以基于 Netty 实现的网络通信框架 SOFABolt 用作远程通信框架，使用者不用关心如何实现私有协议的细节，直接使用内置 RPC 通信协议，启动客户端与服务端，同时注册用户请求处理器即可完成远程调用：\nSOFARPC 服务调用提供同步 Sync、异步 Future、回调 Callback 以及单向 Oneway 四种调用类型。\n这里我们先提供一张整体的图，后面每个方式原理介绍的时候，我会进行更加详细的解释。读者可以重点阅读以下部分的图示，根据阻塞时间的长短，会有不同的标识。\nSync 同步调用 同步调用是指的客户端发起调用后，当前线程会被阻塞，直到等待服务端返回结果或者出现了超时异常，再进行后续的操作，是绝大多数 RPC 的默认调用方式，无需进行任何设置即可。\n这种调用方式，当前线程发起调用后阻塞请求线程,需要在指定的超时时间内等到响应结果才能完成本次调用。如果超时时间内没有得到响应结果，那么抛出超时异常。Sync 同步调用模式最常用，注意要根据对端的处理能力合理设置超时时间。\n如上图所示，这里主要是描述了客户端的处理逻辑，其中客户端线程和 RPC 内部部分处理并不在一个线程里。所以这里客户端线程包含其中一部分操作，后文的图中也是类似。其中红色的树状框表示客户端的线程阻塞。\n可以看到，客户端在代码片段2中，发起 RPC 调用，那么除非本次 RPC 彻底完成，或者 RPC 在指定时间内抛出超时异常，否则红框一直阻塞，代码片段3没有机会执行。\nFuture 异步调用 客户端发起调用后不会同步等待服务端的结果，而是获取到 RPC框架给到的一个 Future 对象，调用过程不会阻塞线程，然后继续执行后面的业务逻辑。服务端返回响应结果被 RPC 缓存，当客户端需要响应结果的时候需要主动获取结果，获取结果的过程阻塞线程。\n如上图所示，代码片段2发起 RPC 调用后，RPC 框架会立刻返回一个 Future 对象。给到代码片段2，代码片段2可以选择等待结果，或者也可以继续执行代码片段3，等代码片段3执行完成后，再获取 Future 中的值。\nCallback 回调调用 客户端提前设置回调实现类，在发起调用后不会等待结果，但是注意此时是通过上下文或者其他方式向 RPC 框架注册了一个 Callback 对象，结果处理是在新的线程里执行。RPC在获取到服务端的结果后会自动执行该回调实现。\n如图所示，客户端代码段2发起 RPC 调用后，并不关心结果，此时也不会有结果。只是将自己的一个 Callback 对象传递给 RPC 框架，RPC 框架发起调用后，立即返回。之后自己等待调用结果，在有了调用结果，或者超过业务配置的超时时间后，将响应结果或者超时的异常，进行 callback 的回调。一般的，一个 callback 的结果需要包含两个部分\npublic interface InvokeCallback { /** * Response received. * * @param result */ public void onResponse(final Object result); /** * Exception caught. * * @param e */ public void onException(final Throwable e); } 如果是正常返回，则 RPC 框架回调用户传入 callback 对象的 onResponse 方法，如果是框架层的异常，比如超时，那么会调用 onException 方法。\nOneway 单向调用 客户端发送请求后不会等待服务端返回的结果，并且会忽略服务端的处理结果，\n当前线程发起调用后，用户并不关心调用结果，只要请求已经发出就完成本次调用。单向调用不关心响应结果，请求线程不会被阻塞，使用 Oneway 调用需要注意控制调用节奏防止压垮接收方。注意 Oneway 调用不保证成功，而且发起方无法知道调用结果。因此通常用于可以重试，或者定时通知类的场景，调用过程是有可能因为网络问题、机器故障等原因导致请求失败，业务场景需要能接受这样的异常场景才能够使用。\n调用方式比较 调用方式 优点 不足 使用场景 Sync 简单 同步阻塞 大部分场景 Oneway 简单，不阻塞 无结果 不需要结果，业务不需要保证调用成功的场景 Future 异步，可获取结果 需要再次调用 get 方法获取结果 同线程内多次 RPC 调用。且没有先后关系 Callback 异步，不需要手动获取结果 使用稍微复杂。且不能在当前代码段直接操作结果 当前不关心结果。但是最终依赖结果做一些其他事情的场景 源码剖析 下面我们以 SOFARPC 中的 BOLT 协议为基础，介绍一些 RPC 框架下面的代码层面的设计。主要介绍代码结构和相互的调用关系。\n对 BOLT 的包装主要在\ncom.alipay.sofa.rpc.transport.bolt.BoltClientTransport 业务方并不直接使用 BOLT 定义的一些类型，而是使用 RPC 定义的一些类型。这些类型被适配到 BOLT 的类型上，使得 RPC 框架对用户提供了统一的 API，和底层是否采用 BOLT 不强相关。\nSync 同步调用 SOFARPC 中的的同步调用是由 Bolt 通信框架来实现的。核心代码实现在\ncom.alipay.remoting.BaseRemoting#invokeSync com.alipay.remoting.rpc.protocol.RpcResponseProcessor#doProcess 使用时无需特殊配置。\nFuture 异步调用 使用 Future 异步调用 SOFABoot 配置服务引用需要设置\n\u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; 元素的 type 属性声明调用方式为 future：\n如上设置为 Future 调用的方式。客户端获取响应结果有两种方式：\n1.通过 SofaResponseFuture 直接获取结果。第一个参数是获取结果的超时时间，第二个参数表示是否清除线程上下文中的结果。\nString result =(String)SofaResponseFuture.getResponse(timeout,true); 2.获取原生 Futrue，该种方式获取JDK原生 …","date":1536130800,"description":"本文为《剖析 | SOFARPC 框架》第四篇。","dir":"blog/sofa-rpc-synchronous-asynchronous-implementation/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d7ab7dabc882ef32b491dc6ce551fc39","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","publishdate":"2018-09-05T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 同步异步实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","wordcount":3596},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第三篇，本篇由米麒麟/碧远共同出品。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 在 RPC 调用过程中，我们经常会和多个服务端进行远程调用，如果在每次调用的时候，都进行 TCP 连接，会对 RPC 的性能有比较大的影响，因此，实际的场景中，我们经常要对连接进行管理和保持。\nSOFARPC 应用心跳包以及断线重连实现,结合系统 tcp-keepalive 机制，来实现对 RPC 连接的管理和保持。\n连接管理 首先我们将会介绍连接管理相关的一些背景知识。\n长连接和短连接 短连接，一般是指客户端向服务端发起连接请求。连接建立后，发送数据，接收服务端数据返回，然后触发连接断开，下次再重新重复以上过程。\n长连接，则是在建立连接后，发送数据，接收数据，但是不主动断开，并且主动通过心跳等机制来维持这个连接可用，当再次有数据发送请求时，不需要进行建立连接的过程。\n一般的，长连接多用于数据发送频繁，点对点的通讯，因为每个 TCP 连接都需要进行握手，这是需要时间的，在一些跨城，或者长距离的情况下，如果每个操作都是先连接，再发送数据的话，那么业务处理速度会降低很多，所以每个操作完后都不断开，再次处理时直接发送数据包即可，节省再次建立连接的过程。\n但是，客户端不主动断开，并不是说连接就不会断。因为系统设置原因，网络原因，网络设备防火墙，都可能导致连接断开。因此我们需要实现对长连接的管理。\nTCP 层 keep-alive tcp 的 keep-alive 是什么 tcp-keepalive，顾名思义，它可以尽量让 TCP 连接“活着”，或者让一些对方无响应的 TCP 连接断开，\n使用场景主要是：\n 一些特定环境，比如两个机器之间有防火墙，防火墙能维持的连接有限，可能会自动断开长期无活动的 TCP 连接。\n 还有就是客户端，断电重启，卡死等等，都会导致 TCP 连接无法释放。\n 这会导致：\n一旦有热数据需要传递，若此时连接已经被中介设备断开，应用程序没有及时感知的话，那么就会导致在一个无效的数据链路层面发送业务数据，结果就是发送失败。\n无论是因为客户端意外断电、死机、崩溃、重启，还是中间路由网络无故断开、NAT 超时等，服务器端要做到快速感知失败，减少无效链接操作。\n而 tcp-keepalive 机制可以在连接无活动一段时间后，发送一个空 ack，使 TCP 连接不会被防火墙关闭。\n默认值 tcp-keepalive，操作系统内核支持，但是不默认开启,应用需要自行开启，开启之后有三个参数会生效，来决定一个 keepalive 的行为。\nnet.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 75 可以通过如下命令查看系统 tcp-keepalive 参数配置。\nsysctl -a | grep keepalive cat /proc/sys/net/ipv4/tcp_keepalive_time sysctl net.ipv4.tcp_keepalive_time 系统默认值可以通过这个查看。\ntcp_keepalive_time，在 TCP 保活打开的情况下，最后一次数据交换到 TCP 发送第一个保活探测包的间隔，即允许的持续空闲时长，或者说每次正常发送心跳的周期，默认值为 7200s（2h）。 tcp_keepalive_probes 在 tcp_keepalive_time 之后，没有接收到对方确认，继续发送保活探测包次数，默认值为 9（次）。 tcp_keepalive_intvl，在 tcp_keepalive_time 之后，没有接收到对方确认，继续发送保活探测包的发送频率，默认值为 75s。\n这个不够直观，直接看下面这个图的说明：\n如何使用 应用层，以 Java 的 Netty 为例，服务端和客户端设置即可。\nServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 100) .childOption(ChannelOption.SO_KEEPALIVE, true) .handler(new LoggingHandler(LogLevel.INFO)) .childHandler(new ChannelInitializer\u0026amp;lt;SocketChannel\u0026amp;gt;() { @Override public void initChannel(SocketChannel ch) throws Exception { ch.pipeline().addLast( new EchoServerHandler()); } }); // Start the server. ChannelFuture f = b.bind(port).sync(); // Wait until the server socket is closed. f.channel().closeFuture().sync(); 就是这里面的ChannelOption.SO_KEEPALIVE, true 对应即可打开.\n目前 bolt 中也是默认打开的.\n.childOption(ChannelOption.SO_KEEPALIVE, Boolean.parseBoolean(System.getProperty(Configs.TCP_SO_KEEPALIVE, \u0026amp;quot;true\u0026amp;quot;))); Java 程序只能做到设置 SO_KEEPALIVE 选项，至于 TCP_KEEPCNT，TCP_KEEPIDLE，TCP_KEEPINTVL 等参数配置，只能依赖于 sysctl 配置，系统进行读取。\n检查 查看 tcp 连接 tcp_keepalive 状态\n我们可以用 netstat -no|grep keepalive 命令来查看当前哪些 tcp 连接开启了 tcp keepalive. 应用层 keep-alive 应用层 keep-alive 方案，一般叫做心跳包，跟 tcp-keepalive 类似，心跳包就是用来及时监测是否断线的一种机制，通过每间隔一定时间发送心跳数据，来检测对方是否连接，是属于应用程序协议的一部分。\n心跳是什么 心跳想要实现的和 tcp keep-alive 是一样的。\n由于连接丢失时，TCP 不会立即通知应用程序。比如说，客户端程序断线了，服务端的 TCP 连接不会检测到断线，而是一直处于连接状态。这就带来了很大的麻烦， …","date":1535526000,"description":"本文为《剖析 | SOFARPC 框架》第三篇，本篇由米麒麟/碧远共同出品。","dir":"blog/sofa-rpc-connection-management-heartbeat-analysis/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2f911034e6bec76b8b0496b7f06e10b7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","publishdate":"2018-08-29T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之SOFARPC 连接管理与心跳剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","wordcount":4225},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第二篇，本篇由畅为/碧远/卓与共同出品。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 一. 前言 微服务已经被广泛应用在工业界，微服务带来易于团队并行开发、独立部署、模块化管理等诸多优点。然而微服务将原单体拆分多个模块独立部署，各模块之间链接变得错综复杂，在大规模分布式系统中这种复杂链路给维护带来了诸多困难。 如果对整个微服务架构不能了然于胸，便很难理清各模块之间的调用关系。 例如修改一个服务接口，对哪些服务造成影响不能快速定位。\nSOFARPC 在5.4.0 以后提供了链路追踪技术，可以有效协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。\n如思维导图所示，本文将从以下几个方面介绍目前已经开源的 SOFARPC 的链路追踪技术：\n二. 什么是链路追踪技术 链路追踪技术主要是收集、存储、分析分布式系统中的调用事件数据，协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。 链路追踪技术包含了数据埋点、收集、存储、分析等相关技术，是一套技术体系。 大部分的链路追踪框架都是参考 google链路追踪系统Dapper 的一篇设计论文（《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 ），SOFARPC 的SOFATracer 的设计灵感也是来自这篇著名论文。\n以大规模分布式电商系统为例，用户下单购买某款产品时后端需要调用各系统或子模块进行协作，共同完成一个用户请求。 如下图所示，用户的下单行为涉及到了A、B、C、D、E、F 6个系统的协同工作，这些系统都是以集群形式部署。整个链路中最长的链路调用是3层，如 A-\u0026amp;gt; C -\u0026amp;gt; E 或 A -\u0026amp;gt; C -\u0026amp;gt; F。\n模块的增多加大了系统出错的概率，一旦因某系统/模块出错导致整个请求调用出错，在缺乏链路追踪的条件下很难定位具体出错的模块，只能通过日志搜索定位。 在实际生产环境下比较关注一个请求中的各个模块的耗时情况、连续调用情况、出错的节点等信息。 为了解决上述问题，Dapper提供了一套解决方案。整个方案分为数据收集、存储和分析几个部分。分布式追踪技术会记录一个请求中各模块的调用信息；并通过一个处理集群把所有机器上的日志增量地收集到集群当中进行处理，将同一个请求的日志串联；最后可视化显示调用情况。\n常用的数据收集方式为埋点，通过在公共组件如RPC等注入代码，收集服务调用的相关信息。目前大部分链路调用系统如Dapper、鹰眼、Spring Cloud Sleuth 都在用这种模式。同样SOFARPC 作为一个公共的通讯框架，在金融业务领域被广泛应用，因此适合作为埋点，这样无需业务端自行埋点，可做到对业务代码的无侵入性。\nDapper 将一个调用过程构建成一棵调用树(称为Tracer)，Tracer树中的每个节点表示链路调用中的一个模块或系统。 通过一个全局唯一的 traceId 来标识一个请求调用链。 并定义了span，span表示一个系统的调用，一个span 包含以下阶段：\n Start: 发起调用\n cleint send(cs): 客户端发送请求\n Server Recv(sr)：服务端收到请求\n Server Send(ss): 服务端发送响应\n Client Recv(cr) : 客户端收到服务端响应\n End： 整个链路完成\n 每个span 包含两个重要的信息 span id(当前模块的span id) 和 span parent ID(上一个调用模块的span id)，通过这两个信息可以定位一个span 在调用链的位置。 通过以上信息我们可以定义用户下单过程的调用链：\nSOFARPC中的链路追踪技术主要是作为埋点部分，因此对于链路追踪系统的收集和分析部分本文不做详述，想要深入了解的可参看参考资料内容。链路追踪可以提供我们以下功能:\n 服务耗时、瓶颈分析 ：分析每个服务的耗时情况，可以针对耗时长的服务进行优化，提高服务性能。\n 可视化错误：快速定位服务链路中出错的环境，便于排查和定位问题。一般链路追踪中间件都提供了ZipKin 页面支持。\n 链路优化: 对于调用比较频繁的服务，可以针对这些服务实施一些优化措施。\n 调用链路梳理：通过可视化界面，对整个调用链路有个清晰的认识。\n 在设计分布式链路框架时需要考虑一下几个问题：\n 低损耗、高性能: 追踪系统对在线服务的影响应该做到足够小，不影响线上服务性能。\n 应用透明: 对于业务开发人员来说，应不需要知道有跟踪系统这回事的。\n 可扩展性：虽则业务规则增大、集群增多，监控系统都应该能完全把控住这种快速变化。\n 数据采样设计：如果每条日志都记录，在高并发情况下对系统有一定的损耗。但收集数据太少可能对统计结果有所影响，所以应合理设计采样比例。\n 三. SOFARPC 链路追踪设计原理 SOFARPC 作为一个基础的通讯中间件，对服务调用有很强的感知能力，容易获取链路追踪所需的服务调用信息。因此很多链路追踪系统都会选择RPC 作为埋点对象，通过对RPC中间件的埋点可以轻松做到对用户的无感知、透明化。 SOFARPC在5.4.0 以后开始支持分布式链路追踪，其技术实现主要依赖于所集成的SOFATracer。\nSOFARPC 不仅提供了埋点信息采集的能力, 还支持数据上报zipkin。 通过SOFARPC + SOFATracer + zipKin 可以快速搭建一套完整的链路追踪系统，包括埋点、收集、分析展示等。 收集和分析主要是借用zipKin的能力，本文重点讲SOFARPC中的数据埋点设计。SOFARPC自身具备的微内核设计和可拓展性，使得在SOFARPC在不破坏开放封闭原则的前提下，比较轻松地集合SOFATracer。该部分主要从以下几个方面讨论SOFARPC的链路追踪设计思路：\n 可插拔设计。 SOFARPC采用了微内核设计，使得很容易扩展，增加新功能。\n 总线设计。为数据埋点做提供一种无侵入的扩展方式。\n 调用trace和span\n 数据采样设计\n 异步刷新机制\n 耗时计算：链路调用的耗时统计等信息获取。\n 埋点数据透传，各模块之间的链路调用数据的透传机制。\n 异步线程的链路调用。在异步多线程环境下如何保证traceId和spanId的有序性。\n 链路调用日志数据的文件存储结构\n 3.1 可插拔设计 SOFARPC自身具备的微内核设计和可拓展性，使得在SOFARPC在不破坏开放封闭原则的前提下，比较轻松地集合SOFATracer。SOFARPC 采用了自己实现的一套SPI机制， 通过该SPI机制动态去加载其他模块、过滤器、协议等，实现灵活拓展。SOFARPC 为了集成SOFATracer也采用了这套机制，做到可插拔。\nSofaTracerModule 类实现了Module …","date":1534921200,"description":"本文为《剖析 | SOFARPC 框架》第二篇，本篇由畅为/碧远/卓与共同出品。","dir":"blog/sofa-rpc-link-tracking/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"09e24cfad0d59d40a509e893f26c59ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-link-tracking/","publishdate":"2018-08-22T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-rpc-link-tracking/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 链路追踪剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-link-tracking/","wordcount":6480},{"author":"碧远","categories":"SOFARPC","content":" 前言 RPC 框架作为分布式技术的基石，在分布式和微服务环境下，扮演着非常重要的角色。\n在蚂蚁金服的分布式技术体系下，我们大量的技术产品（非网关类产品），都需要在内网，进行节点间通信。底层通信框架，已经在蚂蚁自研的 BOLT中的进行了实践，BOLT 提供了优秀的通信协议与通信框架，在 BOLT 的基础上，我们研发了自己的 RPC 框架，提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等基础能力，本文将从以下几个方面介绍目前已经开源的 SOFARPC 框架。\n RPC 是什么 通用 RPC 框架原理 SOFARPC 框架设计 RPC是什么 RPC 这个概念术语在上世纪 80 年代由 Bruce Jay Nelson 提出，在 Nelson 的论文 \u0026amp;ldquo;Implementing Remote Procedure Calls\u0026amp;rdquo; 中他提到了几点：\n 简单：RPC 概念的语义清晰,简单，方便建立分布式计算。 高效：在使用方看来,十分简单而且高效。 通用：通用,适用于各种不同的远程通信调用。 这里面Nelson提出了一个 RPC框架应该包含的几个部分。\n User User-stub RPC-Runtime Server-stub Server 如下图示，为了和现在我们通用的术语一致，我将 User 改成 Client 了。\n当 Client 想发起一个远程调用时，实际是通过本地调用 Client-stub，而 Client-stub 负责将调用的接口、方法和参数通过约定的协议规范进行编码并通过本地的 RPC-Runtime 实例传输到远端的实例。远端 RPC-Runtime 实例收到请求后交给 Server-stub 进行解码后发起本地端调用，在 Java中可以认为就是反射调用,调用结果再返回给 Client 端。\n从上文可以看到，一个典型的 RPC 调用过程还是相对简单的。但是实际上，一个真正的 RPC 框架要做的远不止这些。\n通用 RPC 框架原理 相信对 RPC 框架有过一定了解，或者使用过 RPC 产品的同学，在看到了图上之后，会产生几个疑问：\n1.Stub 怎么出现？\n2.怎么打包参数？\n3.怎么传输?\n4.怎么知道目标地址?\n5.怎么发布一个 RPC 服务?\n在解释这些问题之前，这里我画了一张目前通用的 RPC 框架的一个流程图：\n其中：\n1.创建代理解决了 Stub 的问题。\n2.序列化和网络协议编码解决了打包的问题。\n3.服务发现与路由寻址解决了如何知道目标地址的问题。\n4.如何发布一个服务，Registry 来解决。\n Bolt，Netty 等解决了网络传输的问题。 当然 SOFARPC 的功能不止这些,在解决了这些问题之后，根据业务的需求和实际的线上情况，我们也开发了熔断,限流,故障剔除,数据透传等能力，下面我会来介绍 SOFARPC 的框架设计。\nSOFARPC框架设计 SOFARPC RoadMap 首先介绍下目前 SOFARPC 的现状和一些正在做的事情。\n欢迎对相关功能和 feature 有兴趣的同学，一起参与开发~\nSOFARPC 结构设计 原理大家清楚之后，为了方便大家尽快上手开发使用，我先从目前的 RPC 框架结构来简单介绍。\n其中 core和 core-impl 是核心的功能，包含 API 和一些扩展机制，extension-impl 中，则包含了不同的实现和扩展，比如对 http，rest，对 metrics，以及其他注册中心的集成和扩展。\n如 bootstrap 中对协议的支持，remoting 中对网络传输的支持，registry 中对注册中心的支持等。\n在此基础上，由于 RPC 框架涉及服务端和客户端，我会结合 SOFARPC 的处理流程，详细介绍下客户端和服务端的处理。\n客户端调用流程 当使用方对服务进行了引用配置之后：\n1.RPC 生成 Proxy，作为用户可以操作的入口。\n2.向服务中心订阅这个 RPC 的地址信息。\n3.使用方发起调用，经过路由，负载均衡，各类 Filter 发起调用。\n服务端处理流程 在服务端看来,通过 TCP 监听端口后：\n1.接到 RPC 请求后，进行解码和反序列化。\n2.选择线程池，进行分发。\n3.经过 Filter，进行反射调用。\n4.将结果序列化，编码,进行写回。\n可扩展的机制 从上面的流程中，可以看到，每个部分基本都有多种实现可选，这得益于RPC的扩展机制。\n为了对 RPC 各个环节的都有充足的可扩展性，提供 SPI 的能力，所以内部的实现和第三方实现都是绝对平等的。\n相比原生 SPI，我们实现了更强大的功能\n 按需加载\n 可以有别名\n 可以有优先级进行排序和覆盖\n 可以控制是否单例\n 可以在某些场景下使用编码\n 可以指定扩展配置位置\n 可以排斥其他扩展点\n 我们实现了一套自己的 SPI 机制。整个流程如下：\n在启动加载阶段，RPC 会根据对应的配置，加载需要调用方法ExtensionLoader(Class\u0026amp;lt;T\u0026amp;gt; interfaceClass, ExtensionLoaderListener\u0026amp;lt;T\u0026amp;gt; listener) 逻辑如下：\n 首先读取rpc-config-default.json和rpc-config.json，找到扩展描述文件存放的文件夹：extension.load.path属性。\n 找到接口类对应的扩展描述文件的文件名（默认就是接口名，也可以自己指定）。\n 循环加载这个文件下的扩展描述文件，按行读取。（同一个接口的同一个别名对应唯一的一个实现类，可以重复，允许覆盖。）\n 保存扩展实现类的alias和实现类的对应关系。\n 如果 ExtensionLoaderListener 不为空，则通知 Listener。\n 最终，将会构造出各个不同的 Filter，Invoker 等等。\n其中我们首先设计了一个扩展，代表这个类或者接口是可扩展的，默认单例、不需要编码。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * 指定自定义扩展文件名称，默认就是全类名 * * @return 自定义扩展文件名称 */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * 扩展类是否使用单例，默认使用 * * @return 是否使用单例 */ boolean singleton() default true; /** * 扩展类是否需要编码，默认不需要 * * @return 是否需要编码 */ boolean coded() default false; } 同时，针对具体的扩展实现，定义一个扩展注解\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * 扩展点名字 * * …","date":1533193200,"description":"本文为 剖析 SOFARPC 框架第一篇。","dir":"blog/sofa-rpc-framework-overall-extension/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d83b816009377f7f93fcd1edf63c534d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","publishdate":"2018-08-02T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","summary":"前言 RPC 框架作为分布式技术的基石，在分布式和微服务环境下，扮演着非常重要的角色。 在蚂蚁金服的分布式技术体系下，我们大量的技术产品（非网关类产品","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之总体设计与扩展机制","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","wordcount":2629},{"author":"鲁直","categories":"SOFABoot","content":" 无论是什么样的业务系统，多多少少都会去做一些模块化的划分，或横或纵，各种姿势，但是这些姿势真地能帮你划分出良好的模块吗？帮你在模块之间做到高内聚，低耦合吗？模块化对于服务化又有什么样的影响？本来将分析常见的几种模块化方案的利弊，并且介绍蚂蚁金服开源的框架 SOFA 在模块化中发挥的作用。\n传统模块化的陷阱 在一个简单的 Spring/SpringBoot 的系统中，我们常常见到一个系统中的模块会按照如下的方式进行分层，如下图中的左边部分所示，一个系统就简单地分为 Web 层、Service 层、DAL 层。\n当这个系统承载的业务变多了之后，系统可能演化成上图中右边的这种方式。在上图的右边的部分中，一个系统承载了两个业务，一个是 Cashier（收银台），另一个是 Pay（支付），这两个业务可能会有一些依赖的关系，Cashier 需要调用 Pay 提供的能力去做支付。\n但是在这种模块化的方案里面，Spring 的上下文依然是同一个，类也没有任何做隔离，这就意味着，Pay Service 这个模块里面的任何的一个 Bean，都可以被 Cashier Service 这个模块所依赖。极端的情况下，可能会出现下面这种情况：\nCashier Service 错误地调用了 Pay Service 中的一个内部的 Bean，造成了两个模块之间的紧耦合。\n这种传统的模块化的问题在于模块化地不彻底。虽然在研发的时候，通过划分模块，把特定职责的类放到特定的模块里面去，达到了类的「物理位置」的内聚。但是在运行时，由于没有做任何隔离的手段，作为一个模块的开发者，并没有办法清楚地知道对方模块提供的对外的接口到底是什么，哪些 Bean 我是可以直接注入来用的，哪些 Bean 是你的内部的 Bean，我是不能用的。长此以往，模块和模块之间的耦合就会越来越严重，原来的模块的划分形同虚设。当系统越来越大，最后需要做服务化拆分的时候，就需要花费非常大的精力去梳理模块和模块之间的关系。\nOSGi 模块化 提到模块化，不得不提 OSGi，虽然 OSGi 没有成为 Java 官方的模块化的标准，但是由于 Java 在 Java 9 之前，一直没有官方的模块化的标准，所以 OSGi 已经是事实上的标准。\nOSGi 为模块化主要做了两个事情：\n OSGi 的类隔离 OSGi 的声明式服务 下面就给读者们简单地解释一下 OSGi 的这两个方面。\nOSGi 的类隔离 OSGi 通过扩展 Java 的 ClassLoader 机制，将模块和模块之间的类完全隔离开来，当一个模块需要引用另一个模块的类的时候，通过在模块中的 MANIFEST.MF 文件中声明类的导出和导入来解决，如下图所示：\n通过这种方式，可以控制一个模块特定的类才可以被另一个模块所访问，达到了一定程度地模块的隔离。\n但是，光光通过类的导出导入来解决类的引用问题还不够，还需要去解决实例的引用的问题，我们往往希望能够直接使用对方模块提供的某一个类的实例，而不是自己去 new 一个实例出来，所以 OSGi 还提供了声明式服务的方式，让一个模块可以引用到另一个模块提供的服务。\nOSGi 的声明式服务 OSGi 的声明式服务正是为了解决这个实例引用的问题，我们可以在一个 OSGi 的模块（Bundle）中去添加一个 XML 配置文件去声明一个服务，如下面的代码所示：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;scr:component xmlns:scr=\u0026amp;quot;http://www.osgi.org/xmlns/scr/v1.1.0\u0026amp;quot; name=\u0026amp;quot;ITodoService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;implementation class=\u0026amp;quot;com.example.e4.rcp.todo.service.internal.MyTodoServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;service\u0026amp;gt; \u0026amp;lt;provide interface=\u0026amp;quot;com.example.e4.rcp.todo.model.ITodoService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/service\u0026amp;gt; \u0026amp;lt;/scr:component\u0026amp;gt; 也可以同样的通过 XML 配置文件去引用一个其他的模块声明的服务：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;scr:component xmlns:scr=\u0026amp;quot;http://www.osgi.org/xmlns/scr/v1.1.0\u0026amp;quot; name=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;reference name=\u0026amp;quot;ITodoService\u0026amp;quot; interface=\u0026amp;quot;com.example.e4.rcp.todo.model.ITodoService\u0026amp;quot; bind=\u0026amp;quot;setITodoService\u0026amp;quot; cardinality=\u0026amp;quot;0..1\u0026amp;quot; unbind=\u0026amp;quot;unsetITodoService\u0026amp;quot; policy=\u0026amp;quot;dynamic\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;implementation class=\u0026amp;quot;com.example.e4.rcp.todo.service.internal.XXXServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/scr:component\u0026amp;gt; 通过声明式服务的方式，我们就可以直接在一个 OSGi 的 Bundle 中使用另一个 Bundle 中提供的服务实例了。\nOSGi 的模块化的问题 OSGi 通过类隔离的机制解决了模块之间的类隔离的问题，然后通过声明式服务的方式解决了模块之间的服务调用的问题，看起来已经完美的解决了我们在传统的模块化中遇到的问题，通过这两个机制，模块和模块之间的边界变得清晰了起来。\n但是在实践的过程中，OSGi 的模块化却面临着一个非常严峻的问题，这个就是就是 OSGi 的类隔离带来的复杂性，OSGi 把每一个模块都通过独立的 ClassLoader 去加载，这样在开发模块的时候，研发的同学就必须非常清楚地去定义哪些类应该导出，哪些类应该导入，一旦少导出，或者导出错误，就会出现各种各样的错误，比如 LinkageError，NoSuchMethodError 等等，而要解决这些错误，要求研发同学清楚地理解 OSGi 的整个类加载体系，以及 Java 的整个类加载体系，这对普通的研发同学来说实在是一个太高的要求。所以这种方式在实施成本非常高，OSGi 并不是非常适合于业务研发。\nSOFA 模块化 为了解决传统的模块化方案模块化不彻底的问题，以及 OSGi 的彻底的模块化带来的复杂性的问题，SOFA 在早期就开始引入了一种折衷的模块化的方案。\nSOFA 模块化的整体的示意图如下：\nSOFA 模块化的方 …","date":1532520754,"description":"本来将分析常见的几种模块化方案的利弊，并且介绍蚂蚁金服开源的框架 SOFA 在模块化中发挥的作用。","dir":"blog/sofastack-modular-isolation/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"796c3ab365dd1191a7777c4dbf9d0a1b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-modular-isolation/","publishdate":"2018-07-25T12:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-modular-isolation/","summary":"无论是什么样的业务系统，多多少少都会去做一些模块化的划分，或横或纵，各种姿势，但是这些姿势真地能帮你划分出良好的模块吗？帮你在模块之间做到高","tags":["SOFABoot"],"title":"蚂蚁金服的业务系统模块化之模块化隔离方案","type":"blog","url":"/sofastack.tech/blog/sofastack-modular-isolation/","wordcount":2688},{"author":"玄北","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力，SOFABoot 模块除了包括 Java 代码外，还会包含 Spring 配置文件，每个 SOFABoot 模块都是独立的 Spring 上下文。\n1. 背景 为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式：\n 基于代码组织上的模块化：这是最常见的形式，在开发期，将不同功能的代码放在不同 Java 工程下，在编译期被打进不同 jar 包，在运行期，所有 Java 类都在一个 classpath 下且使用同一个 Spring 上下文，没做任何隔离； 基于 Spring 上下文隔离的模块化：使用 Spring 上下文来做不同功能模块的隔离，在开发期和编译期，代码和配置也会分在不同 Java 工程中，但在运行期，不同的 Spring Bean 相互不可见，IoC 只在同一个上下文内部发生，但是所有的 Java 类还是在一个 ClassLoader 下； 基于 ClassLoader 隔离的模块化：借用 ClassLoader 来做隔离，每个模块都有独立的 ClassLoader，模块与模块之间的 classpath 不同，SOFAArk 就是这种模块化的实践方式。 以上三种模块化形式的隔离化程度逐次递进，但模块化就像一把双刃剑，在降低模块间耦合的同时也给模块间交互增加了成本，本文介绍第二种模块化形式 —— 基于 Spring 上下文隔离的模块化。\n与基于代码组织上的模块化相比，每个 SOFABoot 模块不仅仅包括 Java 代码，还会包含 Spring 配置文件，这种全新的包组织方式大大降低了用户接入成本，用户只需要简单的引入 Jar 包即可，由 SOFABoot 框架负责刷新模块上下文，无需在原来 Spring 配置文件中新增任何 Bean 定义，简化了接入流程，降低了出错几率。\n每个 SOFABoot 模块的 Spring 上下文都是隔离的。在 Spring 开发中，保证 Spring BeanId 不冲突是 Spring 运行的基础，这个限制在应用规模较小时很容易解决，只需用户在定义 BeanId 时稍加注意即可。但是随着系统规模越来越大，一个系统的开发往往涉及多个团队，保证每个业务定义 BeanId 不重复的成本也越来越高。在 SOFABoot 中，每个 SOFABoot 模块使用独立的 Spring 上下文，避免了不同 SOFABoot 模块间 BeanId 冲突，有效降低企业级多模块开发时团队间的沟通成本。\n2. 基本原理 在介绍 SOFABoot 模块化开发使用之前，我们简单了解下其背后的实现原理。下图是应用运行时的逻辑视图：\nSOFABoot 模块是模块化开发的最小单元，每个 SOFABoot 模块是一个独立的 Spring 上下文，在 SOFABoot 模块中我们可以定义Bean、发布 RPC 服务、连接数据库等等。\n由于上下文隔离，模块与模块之间的 Bean 无法通过 @Autowired 依赖注入，我们提供了 JVM Service/Reference 的方式进行模块间通信。SOFABoot 提供了两种形式的服务发布和引用，用于解决不同级别的模块间调用问题：\n JVM 服务发布和引用：解决一个 SOFABoot 应用内部各个 SOFABoot 模块之间的调用问题 RPC 服务发布和引用：解决多个 SOFABoot 应用之间的远程调用问题 Spring Boot 应用在调用 SpringApplication.run 时会创建一个 Spring Context，我们把它叫做 Root Application Context，它是每个 SOFABoot 模块创建的 Spring Context 的 Parent。这样设计的目的是为了保证每个 SOFABoot 模块的 Spring Context 都能发现 Root Application Context 中创建的 Bean，这样当应用新增 Starter 时，不仅 Root Application Context 能够使用 Starter 中新增的 Bean，每个 SOFABoot 模块的 Spring Context 也能使用这些 Bean。\n下面我们来演示如何开发一个简单的 SOFABoot 模块。\n3. 编写 SOFABoot 模块 3.1 新建工程 DEMO 工程地址\n运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，并创建两个普通的 Maven 模块：\n service-facade: 定义服务接口 service-provide: 演示新建 SOFABoot 模块并发布 JVM 服务 3.2 定义服务接口 service-facade 模块包含用于演示 SOFABoot 模块发布与引用服务接口:\npublic interface SampleService { String message(); } 3.3 定义 SOFABoot 模块 service-provider 是一个 SOFABoot 模块，它会发布一个 JVM 服务供其他模块使用。首先需要为 service-provider 模块增加 sofa-module.properties 文件，将其定义为 SOFABoot 模块，sofa-module.properties 文件放置在 resources 目录:\nModule-Name=com.alipay.sofa.service-provider 3.4 发布服务 SOFABoot 支持三种形式的服务发布，分别是： XML 方式、Annotation 方式以及 API 编码方式，这里演示的是 XML 方式发布服务。\n首先增加 SampleServiceImpl 类，实现 SampleService 接口：\npublic class SampleServiceImpl implements SampleService { private String message; public String message() { return message; } public String getMessage() { return message; } public void setMessage(String message) { this.message = message; } } 增加 META-INF/spring/service-provide.xml 文件，将 SampleServiceImpl 发布为 JVM 服务:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; …","date":1532175154,"description":"本文是对蚂蚁金服开源的 SOFABoot 模块化开发的介绍。","dir":"blog/sofa-boot-modular-development/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"12a378e9b4d93d3dd89e79964b63d186","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-modular-development/","publishdate":"2018-07-21T12:12:34Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-boot-modular-development/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力，SOFABoot 模块除","tags":["SOFABoot"],"title":"基于 SOFABoot 进行模块化开发","type":"blog","url":"/sofastack.tech/blog/sofa-boot-modular-development/","wordcount":2209},{"author":"善逝","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力，以更好地解决随着工程应用变得臃肿庞大后带来的包冲突问题。类隔离能力天生带来模块化能力，同样给协作开发带来便利。\nSOFABoot 的类隔离能力借助单独的组件 SOFAArk 实现，遵循 Spring Boot 依赖即服务的思想，只要工程中引入了 SOFAArk 组件依赖，类隔离能力即生效。\n在上一篇文章 《在 Spring Boot 中集成 SOFABoot 类隔离能力》中，我们详细介绍了 SOFABoot 类隔离能力的使用背景及其使用方式。本文将介绍 SOFABoot 类隔离组件 SOFAArk 的实现原理。\n理解 SOFAArk 三要素 SOFAArk 类隔离框架定义了三个概念，Ark Container，Ark Plugin，Ark Biz。\n在介绍这三个主角之前，我们先来介绍另一个管家：Ark 包。我们都知道一个标准的 Spring Boot 应用可以借助 Spring 官方提供的打包插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 将应用打包成一个可执行 FatJar。相对应的，Ark 包则是 SOFABoot 官方提供的打包插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 将应用打包成一个具有类隔离能力的可执行 FatJar，称之为 Ark 包。下图是粗略地对比两者的目录结构差别：\n可以看到 Ark 包作为应用部署包的分发格式，它包含有 Ark Container，Ark Plugin 和 Ark Biz 三种格式模块。这里我们不对 Ark 包或者其他格式模块的目录结构作分析，感兴趣的同学可以点开文末附上的相关链接。我们重点介绍这三个角色的功能。\n Ark Container: Ark 容器，是组件 SOFAArk 的核心，运行 Ark 包时，Ark 容器会最先启动，负责应用运行时的管理，主要包括构建 Ark Plugin 和 Ark Biz 的类导入导出关系表、启动并初始化 Ark Plugin 和 Ark Biz、管理 Ark Plugin 服务的发布和引用等等。 Ark Plugin: SOFAArk 定义的一种模块格式，由若干个 Jar 包组成的一个 FatJar，开发人员可以借助官方提供的 maven 打包插件将若干 Jar 包打包成一个 Ark Plugin 供应用依赖。运行时，由独立的类加载器加载，因此有隔离需求的 Jar 包建议打包成 Ark Plugin 供应用依赖。 Ark Biz: SOFAArk 定义的一种模块格式，是应用及其依赖的所有三方包组成的一个 FatJar，需要注意的是，Ark Biz 不会包含应用依赖的 Ark Plugin。运行时，Ark Biz由独立的类加载器加载，借助类导入导出关系表，Ark Biz 可以使用 Ark Plugin 的导出类和资源。 SOFAArk 运行时隔离 根据上一节的描述可以知道 SOFABoot 类隔离关键是理解 SOFAArk 定义的三个概念，Ark Container，Ark Plugin 和 Ark Biz。下图表示的是应用启动后，运行时 Ark Container，Ark Plugin，Ark Biz 的逻辑分层图：\n我们将先以 Ark Plugin 入手来介绍 SOFABoot 类隔离的实现原理。\nArk Plugin 隔离 开发者借助 SOFABoot 官方提供的插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 可以将 Java 模块打包成一个 Ark Plugin，这里我们不讨论该打包插件的配置参数和使用方式，感兴趣的同学可以点开文末附上的相关链接以及学习 SOFABoot 类隔离能力使用篇。只需要知道，Ark Plugin 主要包含元信息有：插件启动器、导出类、导入类、导出资源、导入资源、优先级等，这些元信息保存在 Ark Plugin 中的 META-INF/MANIFEST.MF 中，一份典型的 MANIFEST.MF 文件样式如下：\nManifest-Version: 1.0 groupId: com.alipay.sofa artifactId: sample-ark-plugin version: 0.3.0-SNAPSHOT priority: 1000 pluginName: sample-ark-plugin activator: com.alipay.sofa.ark.sample.activator.SamplePluginActivator import-packages: import-classes: import-resources: export-packages: com.alipay.sofa.ark.sample.common.*,com.alipay.sofa.ark.sample export-classes: com.alipay.sofa.ark.sample.facade.SamplePluginService export-resources: Sample_Resource_Exported 在上面我们提到，运行 Ark 包时，类隔离容器 Ark Container 会最先启动，然后 Ark Container 会接管整个应用的启动过程。针对 Ark Plugin 处理逻辑如下：\n 首先解析 Ark 包中引入的所有 Ark Plugin，读取插件元信息，构建类/资源导入导出关系索引表。 提前生成所有插件类加载器，每个 Ark Plugin 都使用独立的类加载器，管理插件类加载逻辑，借助第一步生成的类导入导出关系表，突破 Java 原生的双亲委派模型，可以委托其他插件加载所需类，构建一个类 OSGi 的网状类加载模型。 根据插件优先级，依次调用插件启动器。在插件启动器中，插件开发者可以向容器注册服务以方便其他插件引用，也可以引用其他插件发布的服务，及插件启动所需的初始化操作。 需要明确一点，为了让类加载模型足够简单，Ark 容器在启动任何插件前，会把所有的插件类加载器提前构建完毕。Ark Plugin 可以相互委托加载，插件优先级只是影响插件的启动顺序，而且也不强制 …","date":1528107154,"description":"本文将介绍 SOFABoot 类隔离组件 SOFAArk 的实现原理。","dir":"blog/sofa-boot-class-isolation-deep-dive/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"84c324f1230d57a0c4009566de91bb3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","publishdate":"2018-06-04T10:12:34Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力，以更好地解决随着工程应用变得臃肿庞大后带来的包冲","tags":["SOFAArk","SOFABoot"],"title":"SOFABoot 类隔离原理剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","wordcount":3540},{"author":"余淮","categories":"SOFAStack","content":" 蚂蚁金服自主研发的分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件），包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\n一个多月前，蚂蚁金服开源了 SOFABoot 和 SOFARPC 两个组件，受到了社区的热烈欢迎，也收到了很多社区的反馈，其中就有提到目前开源的组件太少。\n本次 SOFA 中间件将继续开源微服务体系下的几个组件：包括分布式链路追踪（SOFATracer）客户端、Metrics监控度量（SOFALookout）客户端、SOFARPC 的 Nodejs 版实现。同时还开源了 SOFABoot 下的模块化开发框架，以及 SOFARPC 的 HTTP/2 能力等。\n下面将逐一进行简单介绍。\nSOFATracer SOFATracer 是一个用于分布式系统调用跟踪的中间件，通过统一的 traceId 将调用链路中的各种网络调用信息以日志或者上报的方式记录下来，以达到透视化网络调用的目的。这些日志可用于故障的快速发现，数据统计，服务治理等。为了解决在实施大规模微服务架构时的链路跟踪问题，SOFATracer 基于 OpenTracing（http://opentracing.io） 规范并扩展其能力，包括基于 Disruptor 高性能无锁循环队列的异步落地磁盘的日志打印能力，自定义日志格式，日志自清除和滚动能力，基于 SLF4J MDC 的扩展能力，统一的配置能力等。同时 SOFATracer 也对接了开源生态，可以选择将 Tracer 数据对接到 Zipkin 等开源产品。\nSOFATracer 的 Github 的地址是：https://github.com/sofastack/sofa-tracer ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFALookout SOFALookout 是一个利用多维度的 Metrics 对目标系统进行度量和监控的中间件。Lookout 的多维度 Metrics 参考 Metrics 2.0（http://metrics20.org/spec） 标准，提供一整套 Metrics 的处理，包括数据埋点、收集、加工、存储与查询等。SOFALookout 包括客户端与服务器端服务两部分，本次先开源客户端部分，服务端部分代码在整理中。 SOFALookout 客户端提供了一套 Metrics API 标准，通过它可以方便地对 Java 应用的 Metrics 进行埋点统计。为了方便使用，SOFALookout 客户端默认提供一些扩展模块，它们提供 JVM，OS 等基本 Metrics 信息的统计，遵循该扩展机制，我们可以自定义或集成更多的 Metrics 数据。另外，SOFALookout 客户端除了支持向 SOFALookout 服务端上报数据外，还支持与社区主流的相关产品，包括 Dropwizard,（SpringBoot）Actuator 以及 Prometheus 等进行集成和数据适配。\nSOFALookout 的 Github 的地址是：https://github.com/sofastack/sofa-lookout ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nEggjs 集成 每种语言都有自己最擅长的领域，跨语言友好性对于分布式架构也是非常重要的。在蚂蚁内部还有一套 Nodejs 版本的 SOFA 中间件的实现，包含了绝大部分 Java 版本的功能，并将它们集成到已经开源的企业级 Nodejs 框架 Eggjs（https://eggjs.org） 中，形成了一套完整的 Web MVC 和 BFF (Backend For Frontend) 解决方案。这套架构目前广泛应用于蚂蚁的 Web 开发和多端适配等场景，让各岗位有了更清晰的职责划分，服务端（一般是 Java）提供基于领域模型的 RPC 接口，前端调用接口拿到数据后进行剪裁和格式化，并实现人机交互。领域模型与页面数据是两种思维模式，通过分层可以很好地解耦，让彼此更专业高效。后面我们也会陆续开源 SOFA 中间件的 Nodejs 版本实现，本期会先放出 SOFARPC 相关的两个模块：\nSOFARPC Node 的 Github 的地址是：https://github.com/sofastack/sofa-rpc-node ， SOFABolt Node 的 Github 的地址是：https://github.com/sofastack/sofa-bolt-node ， 欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFABoot 在最新的 SOFABoot 2.4.0 版本中，SOFABoot 新增加了基于 Spring 上下文隔离的模块化开发能力。在企业级应用场景，随着应用系统模块的增多，每个业务模块之间的耦合也会越来越严重，业务模块的自测更加复杂，团队之间的沟通成本增加。模块化开发是该问题的有效解决方案，但是 Spring Boot 默认不支持模块化开发，所有 Bean 共用一个 Spring 上下文。为此，SOFABoot 提出 SOFABoot 模块的概念，每个业务团队专注于开发自己的 SOFABoot 应用模块，模块自包含模块的代码和配置，拥有独立的 Spring 上下文，便于开发及自测，减少团队间的沟通成本。SOFABoot 模块间通信使用 JVM 服务进行通信，避免模块之间的耦合；如果远程服务在本地其它本地模块中存在，可优先调本地提高性能。同时 SOFABoot 提供了模块并行启动及 Bean 异步初始化能力，大幅提高应用启动速度。\nSOFABoot 的 Github 的地址是：https://github.com/sofastack/sofa-boot ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFARPC 在最新的 SOFARPC 5.4.0 版本中，SOFARPC 基于事件扩展机制，集成了 SOFATracer 和 SOFALookout 两个微服务体系产品，完善了自身的服务监控度量以及分布式跟踪功能。用户可以通过 SOFATracer 对接到 Zipkin 查看服务调用跟踪信息，也可以通过 SOFALookout 对接到 Prometheus 查看服务度量信息。新版本的 SOFARPC 中还增加了 HTTP/1.1 和 HTTP/2 协议的支持，在跨语言等场景下可以快速通过标准的 HTTP 协议进行通信。SOFARPC 也与 Eggjs 进行了打通了 Bolt 协议，方面用户在 Java 和 Nodejs 之间高效通信。\nSOFARPC 的 Github 的地址 …","date":1527761554,"description":"本次 SOFA 中间件将继续开源微服务体系下的几个组件：包括分布式链路追踪（SOFATracer）客户端、Metrics监控度量（SOFALookout）客户端、SOFARPC 的 Nodejs 版实现。同时还开源了 SOFABoot 下的模块化开发框架，以及 SOFARPC 的 HTTP/2 能力等。","dir":"blog/sofastack-open-source-doubles/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"00f2a1c85bfe83bf9f25ef1af9c44366","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-open-source-doubles/","publishdate":"2018-05-31T10:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-open-source-doubles/","summary":"蚂蚁金服自主研发的分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件），包含了构建金融级云原生架构所需的各个组件，","tags":["SOFAStack"],"title":"蚂蚁金服分布式中间件开源第二弹：丰富微服务架构体系","type":"blog","url":"/sofastack.tech/blog/sofastack-open-source-doubles/","wordcount":2957},{"author":"善逝","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力。蚂蚁金服内部丰富的实践场景表明，类隔离能力对解决类冲突、版本管控有其特殊的优势。\nSOFABoot 的类隔离能力由单独的组件 SOFAArk 实现，相比业界遵循 OSGi（https://www.osgi.org/） 规范的 Equinox 或者 Felix，SOFAArk 专注于类隔离，简化了类加载模型，是一款更加轻量的类隔离框架。\n本文将介绍 SOFABoot 类隔离能力的背景及其使用方式。\n1. 背景 在 Java 世界中，依赖的 JAR 包之间相互冲突永远是一个痛，Spring Boot 采用统一的依赖管理机制规避了大部分依赖冲突问题。理想很美好，现实却很骨感，作为蚂蚁金服这类大体量的公司，各业务线纷繁复杂、基础服务组件繁多，很难做到对所有 JAR 包做统一管控，尤其涉及到多个跨团队模块组件相互依赖时，因为各自技术栈历史包袱的存在，难以有效统一冲突包版本。\n假设如下场景，工程需要引入两个三方组件：A 和 B，组件 A 需要依赖 Hessian 3，组件 B 需要依赖 Hessian 4，因为 Hessian 3 和 Hessian 4 是不兼容的。作为开发者，遇到这种包冲突问题，如果不借助类隔离框架，只能耗费精力升级到统一版本。\n为了彻底解决类似的包冲突问题，我们需要借助类隔离机制，使用不同的类加载器加载冲突的三方依赖包，进而做到在同一个应用运行时共存。\n基于此背景，SOFABoot 提供了一个轻量级的类隔离框架，也是本文的主角，SOFAArk。\n2. 基本原理 在介绍 SOFAArk 类隔离框架使用之前，我们简单了解下其背后的实现原理。正如前文中描述，SOFAArk 是通过独立的类加载器加载相互冲突的三方依赖包，从而做到隔离包冲突。那么我们不禁要问，SOFAArk 是如何区分应用中哪些依赖包是需要单独的类加载器加载呢？原因是 Ark Plugin，它是 SOFAArk 框架定义的一种特殊的 JAR 包文件格式，SOFAArk 框架会自动识别 Ark Plugin 这种特殊依赖。\n何为 Ark Plugin ? Ark Plugin 本质上是一个 FatJar，借助 SOFABoot 官方提供的 maven 打包插件，开发者可以把若干普通的 JAR 包打包成 Ark Plugin 供应用依赖或者把普通的 Java 模块改造成 Ark Plugin。通常来说，如果把一个普通 JAR 打包成 Ark Plugin，那么该 JAR 包依赖的其他三方包也会被打入同一个 Ark Plugin，默认情况下 SOFABoot 官方打包插件会自动把间接依赖也打入到 Ark Plugin。\n应用使用添加 maven 依赖的方式引入 Ark Plugin，运行时，SOFAArk 框架会自动识别应用的三方依赖包中是否含有 Ark Plugin，进而使用单独的类加载器加载。为了更加直观，下图是应用运行时逻辑分层图：\n可以看到，在应用运行时，SOFAArk 容器处于最底层，负责启动应用。应用依赖的所有 Ark Plugin 处于中间层，每个 Ark Plugin 都由 SOFAArk 容器使用独立的类加载器加载，相互隔离。应用业务代码及其他非 Ark Plugin 的普通三方依赖包，为了描述简单，统称为 Ark Biz，它运行在最上层，需要依赖中间层的 Ark Plugin。\n一个标准 Ark Plugin 会包含一些配置文件，主要包含导出类和导入类配置。导出类即把 Ark Plugin 中的类导出给 Ark Biz 和其他 Ark Plugin 可见。默认情况下，所有 Ark Plugin 的导出类对于 Ark Biz 来说都是可见的，即 Ark Biz 可以使用 Ark Plugin 的导出类。对于 Ark Plugin 来说，如果需要使用其他 Ark Plugin 的导出类，必须声明为自身的导入类。关于 Ark Plugin 详细说明可以参考文末相关链接。\n下面我们来演示如何开发一个简单的 Ark Plugin。\n3. Java 模块改造成 Ark Plugin 3.1 新建工程 Demo 工程参见：https://github.com/QilongZhang/ark-plugin-demo\n运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，并创建三个普通的 Java 模块。以前文描述的 Hessian 冲突为例，在演示工程中定义了三个模快：\n pojo-module: 定义了一个简单的 PoJo 类 SamplePoJo，并设置为导出类，打包成 pojo-ark-plugin 。 hessian3-module：定义了一个服务类 Hessian3Service，实现了简单的序列化和反序列逻辑，使用的版本是 Hessian 3，并导入了 SamplePoJo，打包成 hessian3-ark-plugin 。 hessian4-module：定义了一个服务类 Hessian4Service，和 Hessian3Service 功能类似，使用的版本是 Hessian 4，并导入了 SamplePoJo，打包成 hessian4-ark-plugin 。 该用例是为了演示如何将普通的 Java 模块及其三方依赖包打包成 Ark Plugin，以 hessian3-module 模块为例来讲解打包流程。\n3.2 编写服务类 在 hessian3-module 中，提供了一个简单的序列化和反序列化功能类 Hessian3Service：\npackage com.alipay.sofa.demo.hessian3; import com.caucho.hessian.io.HessianInput; import com.caucho.hessian.io.HessianOutput; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; /** * @author qilong.zql */ public class Hessian3Service { public byte[] serialize(Object obj) throws IOException { if(obj==null) throw new NullPointerException(); ByteArrayOutputStream os = new ByteArrayOutputStream(); HessianOutput ho = new HessianOutput(os); ho.writeObject(obj); return os.toByteArray(); } public Object deserialize(byte[] by) throws …","date":1526465554,"description":"本文将介绍 SOFABoot 类隔离能力的背景及其使用方式。","dir":"blog/spring-boot-sofa-boot-class-isolation-integration/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c22dd2791732b32177419ff678b34546","permalink":"https://sofastack.github.io/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","publishdate":"2018-05-16T10:12:34Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力。蚂蚁金服内部丰富的实践场景表明，类隔离能力对解决","tags":["SOFABoot","SpringBoot","SOFAArk"],"title":"在 Spring Boot 中集成 SOFABoot 类隔离能力","type":"blog","url":"/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","wordcount":3524},{"author":"绍辉","categories":"Seata","content":" 上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。\nSeata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。项目地址：https://github.com/seata/seata\n蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n为了帮助大家理解，分布式事务开源负责人绍辉进行了一次线下分享，详细讲述了分布式事务在蚂蚁金服的发展，希望可以帮助大家理解分布式事务，以下为分享的文字整理版本。\n前言 今天的分享将从以下三个部分展开：分布式事务问题产生的背景、蚂蚁金服分布式事务以及分布式事务 Seata 的 Roadmap。\n分享嘉宾：绍辉 蚂蚁金服 分布式事务开源负责人\n1、分布式事务问题产生的背景 1.1、数据库的水平拆分 蚂蚁金服早期，业务量比较小，单库单表便能满足业务需求；但是随着业务的发展，单库单表数据库逐渐成为瓶颈。为了解决数据库的瓶颈问题，我们对数据库进行了水平拆分。拆分所带来的一个问题就是以前一个数据库上便能完成的写操作现在要跨多个数据库，由此带来了跨库事务问题。\n1.2、业务的服务化拆分 蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个 APP 中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，由此产生了跨服务事务问题。\n1.3、转账案例说明数据一致性问题 数据库的水分拆分以及服务的垂直拆分，所带来的问题是一个业务活动通常要调用多个服务、访问多个数据库才能完成。\n以金融业务场景下的转账场景为例，转账服务要完成以下操作：\n 调用交易系统服务创建交易订单； 调用支付系统记录支付明细； 调用账务系统执行 A 扣钱； 调用账务系统执行 B 加钱。 以上 4 个操作要跨 3 个系统，访问 4 个数据库。而网络、数据库、机器等都具有不可靠性，我们很难保证以上 4 个操作能 100% 全部成功。\n在金融属性的业务中，不允许 A 账户的钱扣了，而 B 账户的钱没有加上的现象出现，所以我们必须想办法保证 1 ~ 4 这四个操作要么全部成功，要么全部失败；所以蚂蚁金服自主研发了分布式事务中间件，解决跨服务、跨数据库的数据一致性问题。\n2、蚂蚁金服分布式事务 2.1、分布式事务理论基础 在介绍蚂蚁金服的分布式事务中间件之前，先介绍一些分布式事务的理论背景。\n 2PC 两阶段提交协议（Two Phase Commitment Protocol）是分布式事务最基本的协议。在两阶段提交协议中，有一个事务管理器和多个资源管理器，事务管理器分两阶段协调资源管理器。在第一阶段，事务管理器询问所有资源管理器准备是否成功。如果所有资源均准备成功，那么在第二阶段事务管理器会要求所有资源管理器执行提交操作；如果任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求所有资源管理器在第二阶段执行回滚操作。通过事务管理器的两阶段协调，最终所有资源管理器要么全部提交，要么全部回滚，最终状态都是一致的。\n TCC 资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现。TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题。TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中。事务管理器分两个阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法，最终所有 TCC 服务要么全部都是提交的、要么全部都是回滚的。\n2.2、蚂蚁金服分布式产品介绍 蚂蚁金服从 2007 年开始做分布式事务，至今已经有 12 年历史。蚂蚁金服的分布式事务最初是采用 TCC 实现的，TCC 模式帮蚂蚁业务解决了各类金融核心场景下的数据一致性问题。\n2007 年我们开始支持双十一，为了满足双十一的高性能需求，我们对分布式事务做了一系列的性能优化。\n2013年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014年，蚂蚁金服分布式事务中间件开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户；在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。\n所以在 2015年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务中间件经过长期演进，目前积累了 TCC、FMT 和 XA 三种模式，具有丰富的应用场景。下面分别介绍这三种模式。\n2.3、TCC 模式 蚂蚁金服的 TCC 模式和前面介绍 TCC 理论中提的 TCC 原理是一致的。不同的是，我们在整个分布式事务执行过程中，会去记录事务日志，一个分布式事务会产生一条主事务记录（对应发起方）和若干分支事务记录（对应 TCC 参与者）。记录事务日志的目的是，当分布式事务执行过程中出现异常中断时，事务恢复服务通过轮询事务日志，找出这个异常中断的事务，补偿执行该异常事务剩余未完成的动作，整个分布式事务的最终状态要么全部提交，要么全部回滚。\nTCC 设计规范和注意事项：\n用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。经过蚂蚁金服多年的 TCC 应用实践，总结如下在 TCC 设计和实现过程中的注意事项：\n1、业务操作分两阶段完成： 接入 TCC 前，业务操作只需要一步就能完成。但是在接入 TCC 之后，需要考虑如何将其分成两个阶段完成：把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户 A 的余额中有 100 元，需要扣除其中 30 元”。\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成两步完成：\n Try 操作：资源的检查和预留。 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交。 在扣款场景下，Confirm 阶段做的事 …","date":1526465554,"description":"上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。","dir":"blog/seata-distributed-transaction-open-source/","fuzzywordcount":5000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"acb90bbbf0e7ec7dfb8c797bbd94efee","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-distributed-transaction-open-source/","publishdate":"2018-05-16T10:12:34Z","readingtime":10,"relpermalink":"/sofastack.tech/blog/seata-distributed-transaction-open-source/","summary":"上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式","tags":["Seata"],"title":"蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/seata-distributed-transaction-open-source/","wordcount":4977},{"author":"鲁直","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 的健康检查的基础上，加上了 Readiness Check 的能力，以更好地适应大规模金融级的服务化场景，防止在应用启动有问题的情况下让外部流量进入应用。在本文中，我们将通过 Kubernetes 来演示 SOFABoot 的 Readiness Check 的能力，主要涉及到两个部分的能力的演示：\n SOFABoot 的 Readiness Check 失败之后，SOFABoot 不会将发布的 RPC 服务的地址注册到 ZooKeeper 上面，防止 RPC 的流量进入。 Kubernetes 通过 http://localhost:8080/health/readiness 访问到 SOFABoot 的 Readiness 检查的结果之后，不会将 Pod 挂到对应的 Service 之上，防止 Kubernetes 上的流量进入。 准备一个 Kubernetes 的环境 为了演示在 Kubernetes 中使用 SOFABoot 的 Readiness Check 的能力，首先需要准备好一个 Kubernetes 的环境，在这个例子中，我们直接选择在本机安装一个 minikube，minikube 是 Kubernetes 为了方便研发人员在自己的研发机器上尝试 Kubernetes 而准备的一个工具，对于学习 Kubernetes 的使用非常方便。关于如何在本机安装 minikube，大家参考这个官方的安装教程即可。\n安装完成以后，大家可以直接终端中使用 minikube start来启动 minikube。\n需要注意的是，由于国内网络环境的问题，直接用 minikube start 可能会无法启动 minikube，如果遇到无法启动 minikube 的问题，可以尝试加上代理的设置，大家可以参考以下的命令来设置代理服务器的地址：\nminikube start --docker-env HTTP_PROXY=http://xxx.xxx.xxx.xxx:6152 --docker-env HTTPS_PROXY=http://xxx.xxx.xxx.xxx:6152 在 Kubernetes 上安装一个 ZooKeeper 在准备好了 Kubernetes 的环境之后，我们接下来需要在 Kubernetes 上安装一个 ZooKeeper 作为 SOFARPC 的服务自动发现的组件。首先我们需要有一个 ZooKeeper 的 Deployment：\napiVersion: apps/v1beta1 kind: Deployment metadata: name: zookeeper-deployment labels: app: zookeeper spec: replicas: 1 selector: matchLabels: app: zookeeper template: metadata: labels: app: zookeeper spec: containers: - name: zookeeper image: zookeeper imagePullPolicy: IfNotPresent ports: - containerPort: 2181 这个 Deployment 会部署一个 ZooKeeper 的实例，并且将 2181 端口暴露出来。\n有了这个 YAML 文件之后，我们再部署一个 Service 来作为 ZooKeeper 的负载均衡，这样我们在应用中就可以直接通过域名来访问，而不用 IP 来访问 ZooKeeper 了。这个 Service 的 Yaml 文件如下：\napiVersion: v1 kind: Service metadata: name: zookeeper-service spec: selector: app: zookeeper ports: - protocol: TCP port: 2181 targetPort: 2181 这个 Service 直接将 2181 端口映射到 ZooKeeper 的 2181 端口上，这样，我们就可以在应用中直接通过 zookeeper-service:2181 来访问了。\n准备一个 SOFABoot 的应用 在前面的两步都 OK 之后，我们需要准备好一个 SOFABoot 的应用，并且在这个应用中发布一个 SOFARPC 的服务。首先，我们需要从 start.spring.io 上生成一个工程，例如 GroupId 设置为 com.alipay.sofa，ArtifactId 设置为 rpcserver。\n生成好了之后，接下来，我们需要把 SOFABoot 的依赖加上，将 pom.xml 中的 parent 修改成：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 然后，增加一个 SOFARPC 的 Starter 的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 接着，在 application.properties 里面加上我们的配置，包括应用名和 ZooKeeper 的地址：\n# Application Name spring.application.name=SOFABoot Demo # ZooKeeper 的地址 com.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 上面的事情准备好之后，我们可以在应用中发布一个服务，首先，我们需要分别声明好一个接口和一个实现：\npackage com.alipay.sofa.rpcserver; public interface SampleService { String hello(); } package com.alipay.sofa.rpcserver; public class SampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } 接下来，将这个接口和实现发布成一个 SOFARPC 的服务，我们可以新建一个 src/main/resources/spring/rpc-server.xml 的文件：\n\u0026amp;lt;?xml …","date":1525428754,"description":"在本文中，我们将通过 Kubernetes 来演示 SOFABoot 的 Readiness Check 的能力。","dir":"blog/sofa-boot-readiness-check-in-kubernetes/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4018d6494df0e7ecde1c4911610fc89c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","publishdate":"2018-05-04T10:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 的健康检查的基础上，加上了 Readiness Check 的能力，以更好地适应大规模金融级的服务化场景，防止","tags":["SOFABoot","Kubernetes"],"title":"在 Kubernetes 中使用 SOFABoot 的 Readiness Check 能力","type":"blog","url":"/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","wordcount":2732},{"author":"余淮","categories":"SOFARPC","content":" SOFARPC 是近期蚂蚁金服开源的一个高可扩展性、高性能、生产级的 Java RPC 框架。在蚂蚁金服 SOFARPC 已经经历了十多年及五代版本的发展。SOFARPC 致力于简化应用之间的 RPC 调用，为应用提供方便透明、稳定高效的点对点远程服务调用方案。为了用户和开发者方便的进行功能扩展，SOFARPC 提供了丰富的模型抽象和可扩展接口，包括过滤器、路由、负载均衡等等。\nSOFARPC 可以集成多种注册中心实现，其中一种就是常用的 ZooKeeper。\nZooKeeper 作为一个开源的分布式应用协调系统，已经用到了许多分布式项目中，用来完成统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等工作。\n本文将介绍 SOFARPC 是使用 ZooKeeper 作为注册中心的用法。\n1. ZooKeeper 注册中心安装 这里介绍下 Zookeeper 单机模式两种安装方式，集群模式请参考下其他文档。\n1.1 基于压缩包安装 第一步：去官网下载 http://zookeeper.apache.org/releases.html#download 例如目前最新版是 v3.4.11，我们下载压缩包zookeeper-3.4.11.tar.gz，然后解压到文件夹下，例如 /home/admin/zookeeper-3.4.11。\n第二步：设置配置文件，可以直接从样例复制一份。\n$ cd /home/admin/zookeeper-3.4.11 $ cp conf/zoo_sample.cfg conf/zoo.cfg 第三步：到 Zookeeper 安装目录下直接启动Zookeeper。\n$ cd /home/admin/zookeeper-3.4.11 $ sh bin/zkServer.sh start ZooKeeper JMX enabled by default Using config: /Users/zhanggeng/dev/zookeeper/bin/../conf/zoo.cfg -n Starting zookeeper ... STARTED 第四步：我们使用四字命令检查下。\n$ echo stat | nc 127.0.0.1 2181 Zookeeper version: 3.4.11-37e277162d567b55a07d1755f0b31c32e93c01a0, built on 11/01/2017 18:06 GMT ... 第五步：如果需要查看数据，直接运行 zkCli.sh，连接后执行 ls /即可。\n$ sh bin/zkCli.sh Connecting to localhost:2181 ...... WatchedEvent state:SyncConnected type:None path:null [zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] 1.2 基于 Docker 安装 如果您已安装了 Docker，那么可以选择使用镜像启动 Zookeeper。\n$ docker image pull zookeeper:3.4.11 $ docker run -i -t --name my_zookeeper -p2181:2181 -d zookeeper:3.4.11 我们查看下启动日志：\n$ docker logs -f my_zookeeper ZooKeeper JMX enabled by default Using config: /conf/zoo.cfg 2018-04-16 07:38:59,373 [myid:] - INFO [main:QuorumPeerConfig@136] - Reading configuration from: /conf/zoo.cfg ...... 2018-04-16 07:23:41,187 [myid:] - INFO [main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:2181 可以看到端口已经启动并发布，我们使用四字命令检查下。\n$ echo stat | nc 127.0.0.1 2181 Zookeeper version: 3.4.11-37e277162d567b55a07d1755f0b31c32e93c01a0, built on 11/01/2017 18:06 GMT ... 我们可以查看启动的容器运行状态、关闭、重启，参考命令如下：\n$ docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 30b13a744254 zookeeper:3.4.11 \u0026amp;quot;/docker-entrypoin...\u0026amp;quot; 23 hours ago Up 42 seconds 2888/tcp, 0.0.0.0:2181-\u0026amp;gt;2181/tcp, 3888/tcp my_zookeeper ## 关闭重启的话 $ docker container stop 30b13a744254 $ docker container start 30b13a744254 如果需要使用 ZooKeeper 客户端查看查看数据，参考命令如下：\n$ docker exec -it 30b13a744254 zkCli.sh Connecting to localhost:2181 ...... WatchedEvent state:SyncConnected type:None path:null [zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] 2. SOFARPC 集成 Zookeeper 注册中心 Demo 工程参见: sofa-rpc-zookeeper-demo\n2.1 新建工程 运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，然后在 pom.xml 中引入如下 RPC 和 Zookeeper 相关依赖：\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.3.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.curator\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;curator-recipes\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.9.1\u0026amp;lt;/version\u0026amp;gt; …","date":1524737554,"description":"本文是 SOFARPC 集成 Zookeeper 的介绍。","dir":"blog/sofa-rpc-zookeeper-integriation/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"34d9ac266c4b2a95cc924705212d2eb0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","publishdate":"2018-04-26T10:12:34Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","summary":"SOFARPC 是近期蚂蚁金服开源的一个高可扩展性、高性能、生产级的 Java RPC 框架。在蚂蚁金服 SOFARPC 已经经历了十多年及五代版本的发展。SOFARPC 致力于简化应用之","tags":["SOFARPC"],"title":"SOFARPC 集成 Zookeeper 注册中心","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","wordcount":2367},{"author":"蚂蚁中间件","categories":"SOFAStack","content":" 我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！\nSOFA 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服期望通过逐步向社区开源 SOFA 中各个组件，来帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，也期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固，并具备更多金融级的属性。所以我们也非常欢迎社区的伙伴和各行业的伙伴能够参与共同探讨、交流和共建。\nWhy（为什么要做） SOFA 中间件在蚂蚁内部经历了十年的发展和四代架构的演进，被广泛应用在包括支付，借贷，信用，基金，保险等全金融场景，支撑着蚂蚁平稳度过历次双十一，双十二，新春红包等大考，创造了25.6 w/s 的交易记录，并还在不断刷新这个记录。\n从 2015 年开始，蚂蚁金服开启了金融科技对外输出的战略，SOFA 也走出了蚂蚁，甚至跨越了国界，被更多金融机构与合作伙伴所使用，如天弘基金，信美互信，南京银行，PayTM、DANA钱包等。\n在与合作伙伴以及客户的沟通、合作过程中，我们发现了 SOFA 的理念和能力也正是很多金融行业的企业所需要的，大家或多或少正在规划或者已经在做类似的东西，但缺乏像蚂蚁金服这么大的流量来提供考验，也缺乏专业团队的长期投入，更缺乏丰富的金融场景和严苛的业务压力来驱动技术持续发展。\n随着近几年蚂蚁金服在生态构建上不断完善，以及不断地有更多的公司加入到蚂蚁金服的金融生态中，我们也发现了整个金融生态地复杂性和多样性，SOFA 中间件也需要在更多地场景下被打磨、被完善、被增强。因此，我们选择将 SOFA 逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\nHow（怎么做） 为了让 SOFA 能够开源出来，我们投入了大量的重构工作，以可扩展化的方式来层层构建 SOFA 的能力，保证 SOFA 的内部版本和开源的版本采用的是同一个内核。所以 SOFA 的内部版本就是在开源版本之上扩展了内部逻辑和历史版本的兼容逻辑。开源版本的核心逻辑，内外是一致的，并在蚂蚁金服的生产环境中被广泛使用的，同时会随着蚂蚁自身业务诉求的驱动，不断的演进。\n开源社区有非常多优秀的技术和丰富的生态，为了更好的能融入和对接现有技术体系，尊重并遵守一些社区标准，SOFA 在设计过程中就充分考虑了兼容性和架构分层，充分兼容适配社区标准，实现组件化、可扩展、可替换。\n所有的 SOFA 中间件中的组件组合起来可以发挥更大的能力，但是每一个组件都是可以被替换的，比如用户可以选择用 Dubbo 来替换 SOFARPC，或者跟 SOFARPC 对接互通；可以选择 Zookeeper 来作为服务注册发现，也可以选择 SOFA 的服务注册中心来做服务发现；分布式链路追踪组件遵守 OpenTracing 的规范，可以直接和 Zipkin 进行对接等等；Metrics组件会遵循 Metrics2.0 标准，适配 Prometheus 体系等等。\nWhat（要做什么） 本次 SOFA 中间件开源的内容包含了 SOFABoot 和 SOFARPC 两个组件。\nSOFABoot 是蚂蚁金服基于 Spring Boot 构建一个研发框架，整体架构上类似于蚂蚁金服之前开源的Egg框架，遵守微内核，可插拔的理念，我们以标准 Spring Boot Starter的方式，扩展了很多企业级特性，以解决大规模团队开发云原生微服务系统中会遇到的问题，如类隔离，ReadinessCheck，日志隔离等等能力，后续会开放更多内部实践过的特性，如 Spring 上下文隔离，合并部署，动态模块，Tracing、Metrics、Streaming、测试框架等。\n同时，蚂蚁的很多技术团队和阿里的技术团队也开放了很多类库和组件，我们都会提供原生的集成能力和 Demo，方便大家更好的整合使用。SOFABoot 100% 兼容 Spring Boot，和 Spring Boot 并非是替代的关系，所有 Spring Boot 中的能力也都可以在 SOFABoot 中使用。\nSOFABoot 的 Github 的地址是：https://github.com/sofastack/sofa-boot ，欢迎大家使用反馈、贡献代码。\nSOFARPC 是一个高效，可靠，可扩展的 RPC 的框架，是蚂蚁金服服务化架构的基石。SOFARPC 最早源于阿里内部的 HSF，经过了蚂蚁金服内部多年的发展，在协议，网络，路由，可扩展性等层面都进行了大量的改造和优化的工作，适配了更多金融级的场景。\nSOFARPC 在蚂蚁金服内部是被所有在线应用的使用的服务调用框架，截止 2017 年双十一，SOFARPC 已经被蚂蚁 2000 多个系统所使用，生产环境发布的服务数量超过了 23000 个。\nSOFARPC 提供了多协议的支持，包括在蚂蚁金服内部被广泛采用，并且高度优化的 Bolt 协议，以及 REST，Dubbo，gRPC 等等主流的协议；也针对内部网关，测试等等场景提供了泛化调用能力；为了解决超大规模流量的预热的问题，提供了服务预热的能力；用户也可以根据 SOFARPC 的扩展机制扩展自己需要的能力。\n在后续的版本中，SOFARPC 将会加上分布式链路追踪，Metrics，更多的服务注册中心的支持，CRC 校验等等能力。\nSOFARPC 的 Github 的地址是：https://github.com/sofastack/sofa-rpc ，欢迎大家使用反馈、贡献代码。\n除了以上的两个 SOFA 中间件中的组件，在接下来，我们将会陆续开源 SOFA 中间件中的其他的组件，目前这些组件正在进行一定程度地重构中，为开源做准备，敬请大家期待~\n附本文中提到的链接：\n Egg：http://eggjs.org SOFABoot：https://github.com/sofastack/sofa-boot SOFARPC：https://github.com/sofastack/sofa-rpc SOFABolt：https://github.com/sofastack/sofa-bolt 彩蛋 最后，我们也为对 SOFA 中间件感兴趣的小伙伴们准备了一个微信交流群，欢迎感兴趣的同学扫描下方二维码联系加群小助手加入我们 SOFA 交流群哦。👇\n","date":1524147739,"description":"我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！","dir":"blog/announcing-sofastack-open-source/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6019b0e0f6e4c9569640bcdb51b5a157","permalink":"https://sofastack.github.io/sofastack.tech/blog/announcing-sofastack-open-source/","publishdate":"2018-04-19T14:22:19Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/announcing-sofastack-open-source/","summary":"我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！ SOFA 是蚂蚁金服自主","tags":["开源"],"title":"蚂蚁金服启动分布式中间件开源计划，用于快速构建金融级云原生架构","type":"blog","url":"/sofastack.tech/blog/announcing-sofastack-open-source/","wordcount":2479},{"author":"程立","categories":"SOFAStack","content":" 声明：本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创，经谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。\n移动互联网、大数据与云计算作为新的基础设施，催生了新的互联网经济，也正在推动各行各业的升级。在过去十多年中，金融服务飞速发展，移动支付支撑了零售业线上线下的变革，基于大数据的信贷服务支持了无数小微企业的创业创新，老百姓可以随时随地享受曾经高门槛的理财、保险等金融服务。以普惠服务为目标、数据与技术驱动、新型信用体系为基础的新金融已经成为新经济的基石。\n伴随着蚂蚁金服在新金融领域的探索，蚂蚁金服技术团队也在金融技术与架构领域不断开拓。从 2005 年每秒处理 1 笔交易到 2015 年双十一每秒处理 8.59 万笔交易，从单一的支付到覆盖微贷、理财、保险、信用、银行等，通过十多年的探索与实践，我们形成了一套包含金融级分布式交易、分布式大数据分析与决策等在内的完整架构与技术体系。\n在本文中，我们将与大家交流金融级分布式交易相关的实践与体会。\n金融级系统的关键目标 如果将建造系统比作盖楼的话，建一个常规的系统要先立稳四根柱子：高可用、安全、性能、成本。但要建一个移动互联网时代的金融级大厦，除了上述四根柱子需要更加牢固，还需要加上两根柱子：资金安全与数据质量。这六根柱子，是我们在架构蚂蚁金服的每一个系统时的首要目标。\n具体来说，我们对一个金融级系统有以下关键目标：\n高可用：具备 99.99% 以上的高可用性。系统能够容忍各种软硬件设施的故障，可以在服务不中断的情况下进行升级，在严苛的应用场景下保证承诺的服务质量，容忍各种人为失误。对于关键系统，还需要具备异地容灾能力。\n安全：具备多层次检测、感知与防御各类安全攻击的能力。系统有能力实时、精细地分析系统行为与数据流发现异常，必要时可以快速调集资源阻断大规模、有组织的攻击。\n性能：对于实时交易业务，要求极快的响应时间与极高并发能力。对于批量业务，要求极大的吞吐量。尤其重要的是，系统必须具备很强的可伸缩性与弹性，在需要时可以快速调集资源应对突发的业务量。\n成本：在满足高可用、安全与性能的前提下，成本是一个重要约束。我们将单笔交易的平均处理成本（月交易总笔数/月成本）、以及峰值交易的处理成本（每提升 1000 交易 TPS 需要追加的成本）作为两个关键指标去持续优化。除了必须在基础软硬件与系统关键链路上做极致的优化外，灵活的资源调度与按需伸缩能力是优化成本的关键。\n资金安全：这是金融级系统与常规系统的一个关键差异。要做到资金处理绝对不出差错，需要交易与数据具备强一致性，需要在任何故障场景数据不丢不错，需要具备准实时的交易资金核对能力，需要在异常场景下有精细化熔断与快速恢复能力。\n数据质量：数据质量是金融服务质量的基础。数据从采集、生成、流转、存储、计算、使用需要经历很多环节，要确保经过这么多环节后，数据依然是准确、完整和及时的，需要系统具备全链路的数据质量管控与治理能力。\n金融交易系统是否可以走分布式路线？如何基于分布式的思想与技术达到以上 6 个关键目标？接下来，我们就以蚂蚁金服的实践为基础，分享对这个问题的观点。\n分布式金融交易架构与技术 1 强一致的微服务：微交易架构 微服务是一种广泛应用的分布式架构。通过将系统分解为单一职责、高内聚、松耦合、独立部署、自主运行的“微“服务，可以极大提升系统的灵活性与扩展能力。但由于每一个微服务是自包含的数据与计算单元，当一个有严格一致性要求的交易，被分布在很多节点上执行时，如何保证数据与服务处理达到金融级的强一致性，成为一个难题。尽管可以用支持分布式事务的数据库或数据中间件来保证数据分布时的一致性，但解决不了当服务分布时的一致性问题。由于分布式事务对资源加锁的时间长、粒度大，也制约了系统的可伸缩性与高可用性。\n为了解决这个难题，我们提出一种使微服务具备强一致性的微交易架构。在这种架构中，涉及到交易操作的微服务具备事务属性。一个微交易提供三种操作TCC（Try-Confirm-Cancel），其中 Try 操作负责业务检查与资源预留，Confirm 操作负责实际操作，Cancel 操作负责释放预留的资源。一次完整的交易由一系列微交易的 Try 操作组成，如果所有的 Try 操作都成功，最终由微交易框架来统一Confirm，否则统一 Cancel，从而实现了类似经典两阶段提交协议（2PC）的强一致性。但不同于 2PC，微交易架构力求高效与可伸缩。TCC 三个操作都是基于本地事务的短事务，Try 操作只预留必须的业务资源，比如一笔交易涉及10元钱，仅预留账户中的 10 元钱，而不是锁定整个账户，TCC 协议在提交时，也没有单独的 Prepare 阶段，将提交协议的成本降到最低。\n从 2008 年初上线至今，微交易架构已经应用到蚂蚁金服的各种金融业务场景，经历过历次大促高峰考验，证明这套架构与技术的可行性。\n2 金融级分布式数据库: OceanBase 目前，主要商业数据库本质上是单机系统，其容量、性能和可靠性均依赖于单个或少量高性能服务器与高可靠存储的组合，成本高昂且扩展困难。尽管通过运用微交易架构，可以将对数据操作的压力分拆多个数据库，解决了水平可扩展的问题，但数据库本身的性能、成本与可靠性依然是一个难点。因此，阿里巴巴与蚂蚁金服从 2010 年起，开始研发专门的金融级分布式数据库 OceanBase。\nOceanBase 在以下几个方面，对传统数据库架构进行了突破：\n高性能：数据库的一个显著特征是总数量比较大，但每天变化(增删改)的数据只是总数据量的很小一部分。因此 OceanBase 将数据划分为基线数据和修改增量。基线数据即数据库在某个时间点的一个快照，存放在每台 OceanBase 服务器的硬盘中，修改增量即快照点之后的增删改数据，相对比较小，通常存放在每台 OceanBase 服务器的内存中。通过这种方式，使得增删改操作基本都在内存中进行，从而获得接近内存数据库的事务处理性能；\n强一致：经典的主库+备库方式的数据库，很难兼具高可用与强一致能力。为了解决这个问题，OceanBase 使用多数据副本（\u0026amp;gt;=3）投票协议，对于每个写事务，OceanBase 只有在事务日志（redo log）到达超过半数服务器后，才应答客户。这样当少数服务器（例如 3 台中的 1 台，或者 5 台中的 2 台）异常时，剩下的服务器至少有一台有事务日志，保证了数据库不因为少数服务器故障而导致数据丢失；\n高可用：关键业务的数据库必须达到 99.999% 的可用性，服务器故障、机房或网络故障都不能导致数据库不可用。OceanBase 通常由分布于多个机房（3 个或以上）的机群组成，每个机群有完整数据，其中一个机群作为主库对外提供读写服务，其余机群作为备库，接收主库的事务日志和回放日志。当主库故障时，剩下的机群会立刻自动发起投票选举，选出新的主库，新主库从其他机群获得可能存在的最新事务日志并回放，完成后对外提供服务。\n目前 OceanBase 已经稳定支撑了支付宝的核心交易、支付与账务，支撑了网商银行的核心系统，经历了多次“双十一”的考验，形成了跨机房、跨区域部署的高可用架构，并在日常运行、应急 …","date":1520578800,"description":"本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创。","dir":"blog/technical-financial-distributed-trading/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e6da780e4d5f611c48ac55795531fb2c","permalink":"https://sofastack.github.io/sofastack.tech/blog/technical-financial-distributed-trading/","publishdate":"2018-03-09T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/technical-financial-distributed-trading/","summary":"声明：本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创，经谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。","tags":["SOFAStack"],"title":"金融级分布式交易的技术路径","type":"blog","url":"/sofastack.tech/blog/technical-financial-distributed-trading/","wordcount":4822},{"author":null,"categories":null,"content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。 本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同； - 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。\n平台工程旨在帮助企业构建面向应用研发者的自服务运维体系，尝试通过工程化的技术手段和工作流程解决以下关键问题：\n- 设计合理的抽象层次，帮助应用研发者降低对 Infra 、platform 等技术以及运维、稳定性工作的认知负担；\n- 为应用研发者提供统一的工作界面和空间，避免用户陷入割裂的平台产品界面、复杂的工作流中；\n- 帮助研发者通过有效的工作流程和推荐路径基于 内部工程平台[4] 快速开展工作；\n- 帮助研发者通过配套的 CI 、CD 、CDRA 等产品自服务管理应用生命周期；\n- 帮助平台产品研发团队简单、高效、一致的开放其平台基础能力；\n- 通过培训、布道、运营等手段营造协同工作和分享的文化。\n事实上，不是所有人都应该或者能够成为这个领域的专家，这非常困难！\n实际上平台技术团队的专家通常也仅擅长自己的专业领域而已，特别是在云原生理念和技术广泛应用的今天，面向大量高度开放、可配置的平台技术带来的成百上千的应用配置，PaaS 领域的业务复杂性，以及高稳定性和统一治理的要求，而平台工程的目的正是为了让应用研发者尽可能简单无痛的参与到这样规模化的 DevOps 工作中。\n在蚂蚁的实践中，我们更趋向于以下这种合作状态，在团队架构和工作模式上更靠近 Google 的最佳实践。平台研发者及 SRE 成为 “ Enabler ” 支持应用研发者自服务的完成研发及交付运维，同时应用研发者使其应用可交付运维的工作结果也成为运维人员可以接手应用运维工作的基础。最终 SRE 、应用研发及运维人员把工作过程中的问题和痛点反馈给平台研发者形成正向循环。\n三、专用语言：工程化方式的一极 有什么比一种专用语言更适合开放的、自服务的、面向领域业务的问题定义，同时需要满足自动化、低安全风险、低噪音、易治理的企业内部要求吗？正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在平台工程的特定问题域内，一批配置和策略语言用于编写和管理规模化复杂配置及策略。\n不同于混合编写范式、混合工程能力的高级通用语言，这类专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将规模化复杂配置和策略编写思路和方式沉淀到语言特性中。\n在蚂蚁的平台工程实践中，我们强化了客户端的工作方式，将围绕应用运维生命周期的模型、编排、约束和策略稳定、可扩展的通过专用语言 KCL[5] 编写维护在共享仓库 Konfig[6] 中。\nKCL 是一种面向有编程能力的应用研发者的静态强类型语言，提供现代高级语言的编写体验和围绕领域目的有限功能。在平台工程实践中 KCL 不是一种仅用于编写 K-V 对的语言，而是一种面向平台工程领域的专用语言。应用研发者、 SRE 、平台研发者面向 Konfig 协同研发，通过 KCL 原生功能编写应用配置，以及在 PaaS 领域更为高频和复杂的 模型抽象[7] 、 功能函数[8] 和 约束规则[9] ，即编写稳定、可扩展的业务模型、业务逻辑、防错约束和环境规则。\nKonfig 仓库则成为统一的编程界面，工作空间和业务层载体，而基于 KCL 的安全、低噪音、低副作用、一致的编写范式更有利于长期管理和治理。\n四、分治：解构规模化问题 分治思路是解决规模化问题的钥匙，从 MapReduce 到 Kubernetes 无不体现其功效。在规模化交付运维领域，经典运维平台试图在统一的黑盒平台产品中，以内置的统一模型、编排、 provision 技术来应对全量业务场景。这样的实践可以快速启动，在小范围内奏效，但随着不同业务主体采用率提升引入差异化需求，同时随着持续变化的平台技术逐渐进入疲态。\n在蚂蚁的实践中，Konfig monorepo 是内部工程平台向研发者开放的编程界面和工作空间，帮助应用研发者以统一的编程界面编写围绕应用运维生命周期的配置和策略，从而编排和使用存量和新增的平台基础设施，按需创建管理云原生环境以及基于 RBAC 的权限，并通过 GitOps 方式管理交付过程。\nKonfig monorepo 为不同场景、项目、应用提供了独立的白盒的编程空间，其内生的扩展性来源于：\n- 灵活、可扩展、独立的客户端的 工程结构设计[10] ；\n- 独立配置块自动合并技术[11] 支持任意分块、可扩展的配置块组织；\n- 静态类型系统[12] 技术提供现代编程语言可复用、可扩展的类型化建模和约束功能；\n- 项目粒度的 GitOps CI 工作流程定义支持；\n- 基于 Kusion[13] 引擎的 provision 技术选择。\nKonfig monorepo 提供了分治的、可组合的工程结构设计、代码组织、建模方式、工作流程定义和 provision 技术选择支持，同时又以一致的研发模式和工作流承载了可扩展的业务需求。这样客户端的工作方式在保证灵活性、可扩展性、可移植性的同时也降低了对服务 …","date":-62135596800,"description":"","dir":"blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":-62135596800,"objectID":"025e2d84d60225a85a714bfd63e2c369","permalink":"https://sofastack.github.io/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","summary":"文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。 本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同； - 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。","tags":null,"title":"","type":"blog","url":"/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","wordcount":422},{"author":null,"categories":null,"content":" Novel features: Strong leader Raft uses a stronger form of leadership than other consensus algorithms. For example, log entries only flow from the leader to other servers. This simplifies the management of replicated logs and makes Raft easier to understand. Leader election Raft uses randomized timers to elect leaders. This reduces election conflicts simply and rapidly. Membership change Raft uses a new joint consensus approach. Replicated state machines 1. Replicated state machines are implemented based on logs. Each server stores a log. Each log entry contains a command. The state machine executes commands in order. 2. Consensus algorithms for practical systems typically have the following properties: They ensure safety. They are highly available. They do not depend on the time sequence to ensure log consistency. A command can be completed as soon as a majority of the cluster has responded to a single round of remote procedure calls (RPCs). Drawbacks of Paxos Paxos is exceptionally difficult to understand. Paxos does not provide a good foundation for building practical implementations. Raft design principles Concept decomposition Leader election Log replication Membership changes Raft reduces the number of states to simplify the state space. Raft does not allow log holes and restricts the possibilities of log inconsistency. Raft uses randomized timers to simplify the leader election. Raft consistency algorithm State Persistent state on all servers (updated on stable storage before responding to RPCs):\n currentTerm The latest term that the server gets (initialized to 0 on initial boot, increasing monotonically) votedFor The candidateId that has received votes in the current term (or null if none). Log[] Log entries. Each entry contains a command for the state machine, and the term when the entry was received by the leader. Volatile state on all servers:\n commitIndex The index of the highest log entry known to be committed. lastApplied The index of the highest log entry applied to the state machine. Volatile state on leaders:\n nextIndex[] The index of the next log entry to be sent to each follower. matchIndex[] The index of the highest log entry known to have been replicated on each follower. AppendEntries RPC (log replication) Called by the leader to replicate log entries or used as heartbeats.\nArguments:\n term leader\u0026amp;rsquo;s term leaderId The leader\u0026amp;rsquo;s ID that can be used to redirect clients to the leader. prevLogIndex The index of the preceding log entry. prevLogTerm The term of the prevLogIndex entry. entries[] The log entries to be stored (empty for heartbeat, and the leader may send more than one for efficiency). leaderCommit The leader\u0026amp;rsquo;s commitIndex (for committed log entries). Results:\n term The currentTerm for the leader to update. success True if the follower contains log entries matching prevLogIndex and prevLogTerm. Receiver …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/raft-introduction/","fuzzywordcount":2600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b811e803d23b40da67657798801f8b51","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","publishdate":"0001-01-01T00:00:00Z","readingtime":13,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","summary":"Novel features: Strong leader Raft uses a stronger form of leadership than other consensus algorithms. For example, log entries only flow from the leader to other servers. This simplifies the management of replicated logs and makes Raft easier to understand. Leader election Raft uses randomized timers to elect leaders. This reduces election conflicts simply and rapidly. Membership change Raft uses a new joint consensus approach.","tags":null,"title":"'Introduction to the Raft algorithm'","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","wordcount":2562},{"author":null,"categories":null,"content":" Open ACTS IDE In the Packages view, right click the function name annotated by @Test, and choose ACTS Function \u0026amp;gt; Edit Test Case as shown in the following figure.\nWrite test data Prepare request parameters Prepare correct request parameter data for the request parameters (type, order, and quantity) of the tested method. The parameters are divided into simple and complex types. Simple parameters include parameter types String, Date, Integer, Float, Double, Long, Short, and Byte (including their corresponding basic types, such as int and float). Complex parameters include parameter types List, Map, Set, custom class, Java defined class, and their nested expressions.\nSimple request parameters Right click Request Parameters, choose Select Model, and click Simple Type in the pop-up to select simple parameters.\nAfter importing simple request parameters, enter their values directly in the field as shown in the preceding figure. Parameters listed top down are the first, second, and third parameters of the tested method. You can right click a parameter to adjust its order.\nComplex parameters As shown in Figure 27, you need to generate request parameter models for the AccountTransRequest class and the BusinessActionContext class. Generally, class models of the tested method\u0026amp;rsquo;s request parameters and responses are automatically generated along with the test script. You can open ACTS IDE to edit class models of request parameters as shown in Figure 28.\nFigure 28\nIf the models of the method\u0026#39;s request parameters and responses are not identified when you generate the test script, first generate models of complex request parameters and responses (for detailed operation steps, see [Generate object model](../usage-model/#generate-object-model)). Then open ACTS IDE, right click Request Parameters, choose Select Model, and click Complex Type in the pop-up to add complex objects. After this, you can view and edit complex objects under Request Parameters. ![Complex type](complex-type.png) ### List ![List example](list-example.png) ![Edit value](edit-value.png) ### Map See example 2 (the Set type is similar). In Figure 32, request parameters of the method shown in sample 2 is the `Map` type. Objects do not belong to a specific type. If you want to set an object as a complex one, edit the YAML file. For example, if you want to set an object as the AccountTransResult class, edit the YAML file as follows: ![Map examples](map-example.png) Figure 32\n![ Change type](change-type.png) ![Set property values](set-value.png) ### enum Example code: ![Example code](sample.png) 1. You can edit the values in ACTS IDE as follows: ![Edit value](change-value.png) 2. If an enum type class is nested in another class, set the value of the enum type to DEBIT in the CSV model of the class. 3. Figure 37 shows the test case data in the YAML file. ```yaml interestRecoverTypeEnum: !!com.alipay.fc.loancore.common.util.enums.InterestRecoverTypeEnum \u0026#39;ALL\u0026#39; ``` ![YAML data](yaml-data.png) …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ide/","fuzzywordcount":2000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"697e7e6d35a2e058f3ca8b0a72032690","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-ide/","publishdate":"0001-01-01T00:00:00Z","readingtime":10,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-ide/","summary":"Open ACTS IDE In the Packages view, right click the function name annotated by @Test, and choose ACTS Function \u0026gt; Edit Test Case as shown in the following figure.\nWrite test data Prepare request parameters Prepare correct request parameter data for the request parameters (type, order, and quantity) of the tested method. The parameters are divided into simple and complex types. Simple parameters include parameter types String, Date, Integer, Float, Double, Long, Short, and Byte (including their corresponding basic types, such as int and float).","tags":null,"title":"All-in-one editor","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-ide/","wordcount":1929},{"author":null,"categories":null,"content":" Introduction To understand the usage mode of Jarslink2.0, you need to have a certain understanding of the SOFAArk framework and the packaging of Ark packages and Ark Biz packages.\nTo ensure the consistency of reading, here is a rough description of the packaging logic of the application\u0026amp;rsquo;s use of Jarslink2.0. The official recommendation is to jump to the above-mentioned link to obtain the necessary background knowledge.\nJarslink2.0 requires an application type of Spring Boot or SOFABoot. Before introducing new modes of application packaging, let\u0026amp;rsquo;s see why it is necessary for Spring Boot/SOFABoot applications to introduce new packaging modes after using Jarslink2.0.\nBackground At runtime, Jarslink2.0 works as an Ark Plugin of the SOFAArk framework, which must be introduced for the use of Jarslink2.0. The Jarslink2.0 plugin will not be loaded and started until the SOFAArk container is started. As we know, when official Spring Boot projects use plugins:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; An executable FatJar will be packaged, which contains all the dependencies, configurations, and other resources required by the running application. The FatJar entry method is the main method of the Spring Boot application. The packaging logic of a SOFABoot project is the same as that of a Spring Boot project.\nAfter the application introduces Jarslink2.0, which needs to depend on the SOFAArk framework, the FatJar that is packaged by a new packaging mode needs to contain a SOFAArk container. The FatJar entry method also needs to be replaced by the SOFAArk container startup method, because the startup of SOFAArk takes precedence over the execution of the FatJar. The SOFAArk container starts all the Ark Plugins in turn before finally starting the application. Therefore, a new packaging mode is needed, and SOFAArk provides a packaging plugin.\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; responsible for packaging Spring Boot/SOFABoot applications into an executable FatJar called Ark package.\nPackaging Type In the previous section, we have described why the use of Jarslink 2.0 needs to introduce a packaging mode that is different from the official Spring Boot packaging mode, and brought out the first packaging type—Ark package. Now let\u0026amp;rsquo;s summarize the features of Ark package:\n Ark package is an executable FatJar package format customized by the SOFAArk framework, the details of which are available in Reference Documents. The Ark package contains all the configurations, dependencies, and other resources required by the running application. Its packaging logic is similar to that of Spring Boot, and it also contains the Ark Plugin and the SOFAArk framework on which the application depends. The SOFAArk framework does not need to be introduced into the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-repackage/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a9cb3c5d3fa32c5f6c476d9ed80c80cb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","summary":"Introduction To understand the usage mode of Jarslink2.0, you need to have a certain understanding of the SOFAArk framework and the packaging of Ark packages and Ark Biz packages.\nTo ensure the consistency of reading, here is a rough description of the packaging logic of the application\u0026rsquo;s use of Jarslink2.0. The official recommendation is to jump to the above-mentioned link to obtain the necessary background knowledge.\nJarslink2.0 requires an application type of Spring Boot or SOFABoot.","tags":null,"title":"Application packaging","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","wordcount":749},{"author":null,"categories":null,"content":" RheaKV: an embedded, distributed, highly available, and strongly consistent KV storage class library that is implemented based on JRaft and RocksDB. AntQ Streams QCoordinator: uses JRaft to implement elections and meta information storage in the Coordinator cluster. Metadata management module of SOFARegistry: an IP address registration. The data held by all nodes must be consistent, and the normal data storage must not be affected when a minority of nodes fail. AntQ NameServer leader election ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/user-stories/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b233be7d9eed33645945293e637e28ea","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/user-stories/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/user-stories/","summary":"RheaKV: an embedded, distributed, highly available, and strongly consistent KV storage class library that is implemented based on JRaft and RocksDB. AntQ Streams QCoordinator: uses JRaft to implement elections and meta information storage in the Coordinator cluster. Metadata management module of SOFARegistry: an IP address registration. The data held by all nodes must be consistent, and the normal data storage must not be affected when a minority of nodes fail.","tags":null,"title":"Application scenarios","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/user-stories/","wordcount":74},{"author":null,"categories":null,"content":" ## Architecture diagram Jarslink 2.0 is an Ark plugin and needs to depend on the SOFAArk container at runtime. Jarslink 2.0 is in the middle layer between the applications and the containers at runtime. Boundary interaction mode: + 1. Application boundaries: Jarslink 2.0 configures export classes that can be directly used by the applications. Such classes are loaded by Jarslink at runtime. + 2. Container boundaries: The Ark plugin can interact with the SOFAArk container by using the exposed extension points and services. Jarslink expanded the BizDeployer implementation and referenced BizManagerService and BizFactoryService container services.\nModule division The implementation classes of each module appear only in their own modules and are generally not cross-dependent. Required cross-dependencies will be moved into the core module. Detailed module descriptions can be found in the following table:\n Module name Sub-module name Description Dependency relationship bom Dependent on version control None core common Common module with log classes None core spi SPI module, defining basic interfaces and commands None core-impl runtime Jarslink runtime management, processing commands Core integration Ark plugin packaging module, implementing SOFAArk container service extension point and referencing container services All ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-structure/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fa09c01de689002edbd0bea7f68fe66e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","summary":"## Architecture diagram Jarslink 2.0 is an Ark plugin and needs to depend on the SOFAArk container at runtime. Jarslink 2.0 is in the middle layer between the applications and the containers at runtime. Boundary interaction mode: + 1. Application boundaries: Jarslink 2.0 configures export classes that can be directly used by the applications. Such classes are loaded by Jarslink at runtime. + 2. Container boundaries: The Ark plugin can interact with the SOFAArk container by using the exposed extension points and services.","tags":null,"title":"Architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","wordcount":188},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-biz/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d7f80ce6a00d914546e642c887d23a01","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","summary":"","tags":null,"title":"Ark Biz","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","wordcount":0},{"author":null,"categories":null,"content":" 简介 本小节将介绍 Ark Biz 目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark Biz。\nArk Biz 包和 Ark 包 都是使用 Maven 插件 sofa-ark-maven-plugin 打包生成；工程应用在配置该插件时，默认情况下只会打包发布 Ark 包， 只有在配置参数 attach 为 true 时，才会打包发布 Ark Biz：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;false\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 那 Ark Biz 和 Ark 包 有什么区别呢？ 简单来说，Ark Biz 是工程应用所有资源的组织单元，它包含了应用启动所需的所有资源，详细可参考下文描述的 Ark Biz 目录格式；而工程应用打出来的 Ark 包，是一个通过 java -jar 启动，运行在 SOFAArk 容器的 Fat Jar，不仅包含应用工程对应的 Ark Biz，也包含 Ark Container，以及应用依赖的 Ark Plugin；\n通常情况，只需要发布 Ark 包 即可，但是 SOFAArk 是支持运行多个 Ark Biz的，因此如果开发者希望自己应用的 Ark Biz 包能够被其他应用直接当成 Jar 包依赖，进而运行在同一个 SOFAArk 容器之上，那么就需要打包发布 Ark Biz 包；\nArk-Biz 典型目录结构 . ├── META-INF │ ├── MANIFEST.MF │ ├── maven │ │ └── me.qlong.tech │ │ └── sofa-boot-demo3-web │ │ ├── pom.properties │ │ └── pom.xml │ └── sofa-boot-demo3 │ └── sofa-boot-demo3-web.xml ├── com │ └── alipay │ └── sofa │ └── ark │ └── biz │ └── mark ├── config │ ├── application-dev.properties │ ├── application-test.properties │ └── application.properties ├── lib │ ├── spring-beans-4.3.4.RELEASE.jar │ ├── spring-boot-1.4.2.RELEASE.jar │ ├── spring-boot-autoconfigure-1.4.2.RELEASE.jar │ ├── spring-boot-devtools-1.4.2.RELEASE.jar │ ├── spring-boot-starter-1.4.2.RELEASE.jar │ ├── spring-boot-starter-logging-1.4.2.RELEASE.jar │ ├── spring-boot-starter-tomcat-1.4.2.RELEASE.jar │ ├── spring-boot-starter-web-1.4.2.RELEASE.jar │ ├── spring-context-4.3.4.RELEASE.jar │ ├── spring-core-4.3.4.RELEASE.jar │ ├── spring-expression-4.3.4.RELEASE.jar │ ├── spring-web-4.3.4.RELEASE.jar │ ├── ... │ ├── ... │ ├── ... │ └── velocity-1.7.jar ├── logback-spring.xml ├── me │ └── qlong │ └── tech │ └── SOFABootWebSpringApplication.class └── static └── index.html 上述目录结构相关文件和目录说明如下：\n普通的 Java 工程或者 Spring Boot Core/Web 工程都可以打包成 Ark Biz；Ark Biz 没有固定的目录格式，它只是在原来 Jar 包结构基础上新增两个目录文件：\n com/alipay/sofa/ark/biz/mark : 标记文件，标记该 Jar 包是 sofa-ark-maven-plugin 打包生成的 Ark Biz 文件；\n lib/ : lib 目录存放工程应用的三方依赖，\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-biz/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d7f80ce6a00d914546e642c887d23a01","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","summary":"简介 本小节将介绍 Ark Biz 目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark Biz。 Ark Biz 包和 Ark 包 都是使用 Maven 插件 sofa-ark-maven-plugin 打包生成；工程应用在配置该插件时，默认情","tags":null,"title":"Ark Biz","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","wordcount":700},{"author":null,"categories":null,"content":" SOFAArk 合并部署时，除了宿主应用，其他 Biz 允许运行时动态部署和卸载。Biz 的状态如下:\n unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时 Biz 包还没有安装或者安装中 activated: Biz 包启动完成，且处于激活状态，可以对外提供服务 deactivated: Biz 包启动完成，但处于未激活状态，模块多个版本时，只有一个版本处于激活状态(注意这个状态只对 JVM 服务生效，对 RPC 等其他中间件无效) broken: Biz 包启动失败后状态 目前 SOFAArk 提供了三种方式操作 Biz:\n 编程 API Zookeeper 动态配置 Telnet 指令 本质上，后两种都是通过编程 API 操作 Biz，所以在这里详细描述通过编程 API 控制 Biz 的生命周期。SOFAArk 提供客户端 ArkClient 操作 Biz, 主要包含三条指令：\n install: 安装 Biz，虽然有多个重载方法，本质是接受 bizFile 文件作为入参 uninstall: 卸载 Biz，运行时 Biz 是由 bizName 和 bizVersion 唯一确定的，因此需要这两个入参 switch: 激活 Biz，SOFAArk 运行部署多个相同名称不同版本的 Biz，但是运行时只有一个 Biz 被激活（JVM 服务对外可用）；当使用 switch 指令激活其他版本时，当前处于激活状态的 Biz 将切换到钝化，同样也需要 bizName 和 bizVersion 作为入参 注意：部署相同名称不同版本 Biz 时，如果已有激活的版本，后续部署的其他版本 Biz 将自动处于钝化状态\n安装 Biz 以 Spring Boot/SOFABoot 为例，应用(模块)安装包含以下流程：\n 解析模块 \u0026amp;gt; SOFAArk 容器会解析文件流，读取 Biz 配置，创建 BizClassLoader 等，生成 Biz 运行时模型\n 注册模块 \u0026amp;gt; 注册解析后的 Biz 模型，设置状态为 resolved\n 启动模块 \u0026amp;gt; 执行 Biz 的入口方法，完成上下文的刷新，如果报错则对外抛出异常\n 健康检查 \u0026amp;gt; 启动完成，此时 Biz 还没有切换至下一个状态，将会执行应用健康检查，健康检查参考 SOFABoot 文档，健康检查失败则抛出异常，如果应用没有引入 SOFABoot 健康检查依赖，则跳过\n 切换状态 \u0026amp;gt; 健康检查成功，会切换 Biz 状态；如果不存在其他版本 Biz 处于激活状态，则切换状态至 Activated，否则切换状态至 DeActivated\n 注意：启动模块时抛出异常，均导致 Biz 启动失败，可以查看 sofa-ark/common-error.log 日志\n卸载 Biz 应用（模块）卸载包含以下流程：\n 切换 Biz 状态至少 deactivated \u0026amp;gt; 钝化 Biz, 防止流量进入正在卸载的 Biz\n 关闭 ApplicationContext \u0026amp;gt; 关闭 Biz 的 Spring 上下文，如果用户需要自定义卸载操作，可以监听 ContextClosedEvent 事件\n 注销 JVM 服务 \u0026amp;gt; SOFAArk 运行时注销 Biz 发布的 JVM 服务\n 发送卸载事件 \u0026amp;gt; 通知所有 Ark Plugin 和 Ark Biz，正在卸载某个 Biz\n 清楚缓存 \u0026amp;gt; SOFAArk 运行时注销所有和该 Biz 相关的缓存\n 切换 Biz 状态为 unresolved \u0026amp;gt; Biz 执行完所有卸载操作时，将状态置为 unresolved\n 卸载面临的挑战 卸载 Biz 最大的挑战在于 ClassLoader 的卸载，如果 ClassLoader 没有卸载干净，极有可能会导致 metaspace OOM. JDK 对 Class 的回收条件非常苛刻，包含：\n 该类所有实例都已经回收 加载该类的 ClassLoader 已经回收 该类对应的 java.lang.Class 对象已经没有在任何地方被引用，无法在任何地方通过反射访问该类的方法 每个 Biz 都由独立的 BizClassLoader 加载，只要该 Biz 的加载的类或对象或 ClassLoader 被其他 Biz 或 Plugin 引用，则会导致 Biz 无法卸载成功\n激活 Biz 激活指令用于设置 Biz 状态为 Activated，如果此时已有其他版本 Biz 处于激活状态，则先设置其为 Deactivated，再激活指定的 Biz 为 Activated. 激活状态是相对 JVM 服务而言，只有被激活的 Biz，其发布的 JVM 服务才能被其他 Biz 引用\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-biz-lifecycle/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"090ee6596c6808339fa3233139903040","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","summary":"SOFAArk 合并部署时，除了宿主应用，其他 Biz 允许运行时动态部署和卸载。Biz 的状态如下: unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时","tags":null,"title":"Ark Biz 生命周期","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","wordcount":1195},{"author":null,"categories":null,"content":" This section will introduce the directory structure of standard Ark package and how to use the maven plugin of sofa-Ark-maven-plugin to package and release an Ark package.\nMaven plugin The officially provided Maven plugin sofa-Ark-maven-plugin can package common Java projects or Spring Boot projects into standard-format Ark packages. Based on Fat Jar technology, we can directly start an Ark package with the java -jar command. The Maven plugin coordinates are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals The sofa-Ark-maven-plugin plugin provides goal: repackage, which can package the project into an executable Ark package, it can be configured as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Configuration information --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Complete configuration template Complete sofa-Ark-maven-plugin configuration template is as follows:\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.1.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--The default packaging storage directory for Ark package and Ark biz is the project build directory--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;../target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--The name of the generated Ark package file is ${artifactId} by default--\u0026amp;gt; \u0026amp;lt;finalName\u0026amp;gt;demo-ark\u0026amp;lt;/finalName\u0026amp;gt; \u0026amp;lt;!--Whether to skip execution of goal:repackage (false by default)--\u0026amp;gt; \u0026amp;lt;skip\u0026amp;gt;false\u0026amp;lt;/skip\u0026amp;gt; \u0026amp;lt;!--Whether to package, install, and release Ark biz (false by default). Refer to the Ark Biz file for details --\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--Set the classifier of Ark package, which is null by default--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;ark-classifier\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- Set the classifier of Ark biz, which is Ark-biz by default --\u0026amp;gt; \u0026amp;lt;bizClassifier\u0026amp;gt;ark-biz-classifier\u0026amp;lt;/bizClassifier\u0026amp;gt; \u0026amp;lt;!--Exclude the specified package dependency when packaging the Ark biz. The format is: ${groupId:artifactId} or ${groupId:artifactId:classifier}--\u0026amp;gt; \u0026amp;lt;excludes\u0026amp;gt; \u0026amp;lt;exclude\u0026amp;gt;org.apache.commons:commons-lang3\u0026amp;lt;/exclude\u0026amp;gt; \u0026amp;lt;/excludes\u0026amp;gt; \u0026amp;lt;!--Exclude the package dependency that is the same as the specified groupId when packaging the Ark biz--\u0026amp;gt; \u0026amp;lt;excludeGroupIds\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jar/","fuzzywordcount":1400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c2a9b8ad142f15b9ee82d7d9d8237850","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","summary":"This section will introduce the directory structure of standard Ark package and how to use the maven plugin of sofa-Ark-maven-plugin to package and release an Ark package.\nMaven plugin The officially provided Maven plugin sofa-Ark-maven-plugin can package common Java projects or Spring Boot projects into standard-format Ark packages. Based on Fat Jar technology, we can directly start an Ark package with the java -jar command. The Maven plugin coordinates are:","tags":null,"title":"Ark JAR package","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","wordcount":1317},{"author":null,"categories":null,"content":" This section will introduce the standard specifications and directory structure of Ark Plugin and how to use the maven plugin of sofa-ark-plugin-maven-plugin to package and release it.\nPlugin Specifications A standard Ark Plugin should meet the following specifications:\n The plugin should have a name (default is ${artifactId}). At runtime, duplicate names are not allowed. In other words, the name will be used as the unique ID of Ark Plugin;\n A plugin must be configured with a priority (default is 1,000): the lower the number, the higher the priority;\n A plugin should be configured with no more than one entry class activator, a portal for the container startup plugin used to implement the com.alipay.sofa.ark.spi.service.PluginActivator interface class in a uniform way. The plugin with higher priority will start up first;\n Import classes support both package and class levels. They are loaded first from other plugins;\n Export classes support package and class levels. Plugins with higher priority will be exported first;\n Support importing resources from the classpath (wildcard is not supported). Specified resources will be searched for from other plugins first;\n Support exporting resources from the classpath (wildcard is not supported); resources with higher priority will be exported first;\n Maven plugins The officially provided Maven plugin sofa-ark-plugin-maven-plugin can package projects into a standard-format Ark Plugin. The coordinates of Maven plugin are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals The sofa-ark-plugin-maven-plugin plugin provides goal: ark-plugin, which can be used to package the project into a standard-format Ark Plugin. Configurations are as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Configuration information --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Complete configuration template The complete configuration template of the sofa-ark-plugin-maven-plugin plugin is shown as follows:\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Specify the directory to package ${pluginName}.ark.plugin (${project. build. directory} is the default location) --\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin/","fuzzywordcount":1300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"684dc1caa0f834eec498905f95913f83","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","summary":"This section will introduce the standard specifications and directory structure of Ark Plugin and how to use the maven plugin of sofa-ark-plugin-maven-plugin to package and release it.\nPlugin Specifications A standard Ark Plugin should meet the following specifications:\n The plugin should have a name (default is ${artifactId}). At runtime, duplicate names are not allowed. In other words, the name will be used as the unique ID of Ark Plugin;","tags":null,"title":"Ark Plugin","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","wordcount":1242},{"author":null,"categories":null,"content":" 本小节将介绍 Ark Plugin 的标准规范和目录结构，以及如何使用官方插件 sofa-ark-plugin-maven-plugin 打包发布 Ark Plugin。\n插件规范 标准的 Ark Plugin 需要满足以下规范：\n 插件必须配置插件名，默认为 ${artifactId} ；运行时，不允许存在同名的插件，可以认为它是 Ark Plugin 的唯一 ID;\n 插件必须配置优先级，默认为1000，数字越低表示优先级越高；\n 插件最多配置一个入口类 activator ，它是容器启动插件的入口，统一实现 com.alipay.sofa.ark.spi.service.PluginActivator 接口类；优先级高的插件优先启动；\n 导入类支持 package 和 class 两个级别；导入类优先从其他的插件加载；\n 导出类支持 package 和 class 两个级别；优先级高的插件优先导出；\n 支持导入 classpath 中资源，不支持通配符；优先从其他插件中查找指定资源；\n 支持导出 classpath 中资源，不支持通配符；优先级高的插件优先导出；\n Maven 插件 官方提供 Maven 插件 sofa-ark-plugin-maven-plugin 可以将工程打包成标准格式的 Ark Plugin ； Maven 插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${demo.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals sofa-ark-plugin-maven-plugin 插件提供 goal: ark-plugin，可以将工程打包成标准格式的 Ark Plugin, 如下配置：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 配置信息 --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 完整配置模板 完整的 sofa-ark-plugin-maven-plugin 插件配置模板如下：\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 指定打包的 ${pluginName}.ark.plugin 存放目录; 默认放在 ${project.build.directory} --\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!-- 是否把 ark plugin 安装、发布到仓库，默认为true --\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!-- ark plugin 最多仅能指定一个 com.alipay.sofa.ark.spi.service.PluginActivator 接口实现类 --\u0026amp;gt; \u0026amp;lt;activator\u0026amp;gt;com.alipay.sofa.ark.service.impl.SampleActivator\u0026amp;lt;/activator\u0026amp;gt; \u0026amp;lt;!-- 配置优先级，数字越小，优先级越高，优先启动，优先导出类，默认1000 --\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;2000\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!-- 配置插件的名字，务必配置对，运行时，是插件的唯一标识 ID。比如 sofa-rpc 插件，可以配置为 sofa-rpc; 默认为 ${artifactId} --\u0026amp;gt; \u0026amp;lt;pluginName\u0026amp;gt;${ark.plugin.name}\u0026amp;lt;/pluginName\u0026amp;gt; \u0026amp;lt;!--设置 ark plugin 的 classifier, 默认为空, 如非必要，建议不用设置--\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;!-- 配置导入类、资源 --\u0026amp;gt; \u0026amp;lt;imported\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的 package --\u0026amp;gt; \u0026amp;lt;packages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;javax.servlet\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework.*\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/packages\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的 class --\u0026amp;gt; \u0026amp;lt;classes\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.rpc.config.ProviderConfig\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/classes\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的资源 --\u0026amp;gt; \u0026amp;lt;resources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/bean.xml\u0026amp;lt;/resource\u0026amp;gt;\u0026amp;gt; \u0026amp;lt;/resources\u0026amp;gt; \u0026amp;lt;/imported\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"684dc1caa0f834eec498905f95913f83","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","summary":"本小节将介绍 Ark Plugin 的标准规范和目录结构，以及如何使用官方插件 sofa-ark-plugin-maven-plugin 打包发布 Ark Plugin。 插件规范 标准的 Ark Plugin 需要满足以下规范： 插件必须配置插件名，","tags":null,"title":"Ark Plugin","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","wordcount":1937},{"author":null,"categories":null,"content":" Ark container class loading mechanism The plugins and business modules are managed in the Ark container. The following figure describes the class loading mechanism:\nClass loading mechanism of Ark container Each Ark plugin has a separate classloader which loads a class in the following order:\n If byte codes generated by reflection are loaded, the system will throw a ClassNotFoundException to terminate the loading process. This primarily comes from our engineering practice: to avoid long time searches for the classes that can never be found. Search for the already loaded classes Search for classes in the JDK, which mainly consists of two parts: 1) the classes to be loaded by ExtClassloader; 2) the classes that are provided by the JDK but fail to be loaded from the ExtClassloader. When running locally, however, these classes will be added to the SystemClassloader\u0026amp;rsquo;s classpath or they might be put into some third-party toolkits such as sun.tools.attach.BsdVirtualMachine in tool.jar at the same time. This part also comes from our engineering practice, avoiding errors caused by loading a class more than once. See if the class is an interface from Sofa Ark, such as com.alipay.sofa.Ark.spi.service.PluginActivator. If so, the class will be delegated to the classloader of the Ark container responsible for loading. See if it is located in the plugin import (including import-classes and import-package). If so, the loading will be delegated to the plugin classloader that will export it. Load in the plugin\u0026amp;rsquo;s own classpath If the above steps have failed, it will try to load the class in SymtemClassloader to deal with the situation that the agent is used. If the class fails to be loaded with all the above steps, the ClassNotFoundException will be thrown.\nArk business class loading mechanism Each Ark business has a separate classloader. Its class loading mechanism is basically consistent with that of Ark plugin, except for the step 5:\nFor Ark business, no import configuration is provided. Instead, it defaults to importing all classes exported by plug-ins. To deal with some particular business scenarios, however, we do provide the Deny-import configuration so that we can exclude the classes exported by some plugins.\nClass loading mechanism of Ark plugin resources The Ark plugin supports importing and exporting resources. To achieve this, we need to configure the corresponding import and export settings in sofa-Ark-plugin-maven-plugin. There are two ways to search for resources when using ClassLoader: ClassLoader.getResource(String) or ClassLoader.getResources(String);\n ClassLoader.getResource(String): When an Ark Plugin is searching for a single resource, it will delegate the Ark Plugin that will export the resource to load the class first. If multiple plugins export the resource at the same time, then the plugin with higher priority will export the resource first. If the loading fails or no other Ark Plugin has exported the resource, it will have a …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-classloader/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5803b870aae47885c37e4bbb02cb0a06","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","summary":"Ark container class loading mechanism The plugins and business modules are managed in the Ark container. The following figure describes the class loading mechanism:\nClass loading mechanism of Ark container Each Ark plugin has a separate classloader which loads a class in the following order:\n If byte codes generated by reflection are loaded, the system will throw a ClassNotFoundException to terminate the loading process. This primarily comes from our engineering practice: to avoid long time searches for the classes that can never be found.","tags":null,"title":"Ark container class loading mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","wordcount":549},{"author":null,"categories":null,"content":" Starting an Ark plug-in Ark provides the interface for starting a plug-in com.alipay.sofa.ark.spi.service.PluginActivator. The definition of the interface is as follows:\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } Once a plug-in implements this interface, and the activator attribute is configured in MANIFEST.MF, the plug-in will use the start method when it starts and the stop method when it stops.\nArk plug-in communication Ark plug-ins communicate using services. The interfaces used by the publishing and reference services are provided in the input parameter type com.alipay.sofa.ark.spi.model.PluginContext of the preceding method of starting an interface.\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param pluginName the name of the plugin which publish the service * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String pluginName); /** * Get Service List publish by plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;ServiceReference\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; referenceServices(Class\u0026amp;lt;T\u0026amp;gt; ifClass); A plug-in service is interface-specific. For one interface, the following descriptions are true: * Only one service can be published for each plug-in. When more than one service is published, the reference of the previously published service will be returned. * If you use referenceService to reference a single service when multiple plug-ins have published services, which service is returned depends on whether pluginName is specified: * When not specified, the service with the highest priority is returned. * When specified, the service published by the plugin with the specified name is returned.\nThe returned service reference ServiceReference is defined as follows:\npublic interface ServiceReference\u0026amp;lt;T\u0026amp;gt; { /** * get Service Object * @return service */ T getService(); /** * get Service Metadata * @return */ ServiceMetadata getServiceMetadata(); } public interface ServiceMetadata { /** * get Service Unique Name * @return service name */ String getServiceName(); /** * get Service Interface Class * @return interface class */ Class\u0026amp;lt;?\u0026amp;gt; getInterfaceClass(); /** * get …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-plugin/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b552fc51eb84cc0fa4c26860bd316490","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","summary":"Starting an Ark plug-in Ark provides the interface for starting a plug-in com.alipay.sofa.ark.spi.service.PluginActivator. The definition of the interface is as follows:\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } Once a plug-in implements this interface, and the activator attribute is configured in MANIFEST.","tags":null,"title":"Ark container plugin mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","wordcount":477},{"author":null,"categories":null,"content":" Ark container start process The startup process of the Ark container is illustrated as follows:\nArkService Ark Service is a service in the Ark container. The underlying layer uses Guice to manage the service. The service is provided with the lifecycle interface com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } After the service implements the preceding lifecycle interface, the Ark Service container invokes the interface when it starts and stops.\nPipeline service Pipeline is also a service registered in the Ark Service container. The service itself has no order or priority. The service is assembled in the Pipeline while the entire Ark container starts.\nArchive parsing At the very beginning of Pipeline, the running fatjar will be resolved into the models required for runtime, including the Ark plug-in model and the Ark business model, which are registered to the PluginManagerService and the BizManagerService in the Ark Service.\nDeploy the Ark plug-in Get all the Ark plug-ins from the PluginManagerService in the order of their priorities: * ClassloaderService prepares for the map mapping of plug-in export class * PluginDeployService starts com.alipay.sofa.Ark.spi.service.PluginActivator\nStart the Ark business Get all the Ark business from the BizManagerService, and execute the entry main function provided by the business configuration in the Main-Class attribute of MANIFEST.MF.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ad60e803febd20607686a1b4ea98efc3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","summary":"Ark container start process The startup process of the Ark container is illustrated as follows:\nArkService Ark Service is a service in the Ark container. The underlying layer uses Guice to manage the service. The service is provided with the lifecycle interface com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } After the service implements the preceding lifecycle interface, the Ark Service container invokes the interface when it starts and stops.","tags":null,"title":"Ark container startup process","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","wordcount":233},{"author":null,"categories":null,"content":" 使用 Ark 事件处理机制 SOFAArk 从 1.1.0 版本开始提供了全新的事件模型，囊括了 SOFAArk 中 biz 和 plugin 的各个生命周期；该版本提供的事件模型参考了 Spring 中的生命周期事件模型。本篇文档将描述如何使用 SOFAArk 的事件机制。\n事件概览 biz 生命周期事件 事件名 描述 AfterBizStartupEvent biz 启动之后发送的事件 AfterBizStopEvent biz 停止之后发送的事件 AfterBizSwitchEvent biz 切换之后发送的事件 BeforeBizStartupEvent biz 启动之前发送的事件 BeforeBizStopEvent biz 停止之前发送的事件 BeforeBizSwitchEvent biz 切换之前发送的事件 plugin 生命周期事件 事件名 描述 AfterPluginStartupEvent plugin 启动之后发送的事件 AfterPluginStopEvent plugin 停止之后发送的事件 BeforePluginStartupEvent plugin 启动之前发送的事件 BeforePluginStopEvent plugin 停止之前发送的事件 容器级别生命周期事件 事件名 描述 AfterFinishDeployEvent 执行完 DeployStage 阶段之后发送的事件 AfterFinishStartupEvent 执行完 Ark 容器启动之后发送的事件 事件监听 监听指定类型的事件 上述提到的各个阶段的事件，我们可以通过编写 EventHandler 来处理，例如，希望监听类型为 BeforeBizStartupEvent 的事件，则可以通过以下方式实现监听：\n@Component public class EventHandlerSample implements EventHandler\u0026amp;lt;BeforeBizStartupEvent\u0026amp;gt; { private static final Logger LOGGER = LoggerFactory.getLogger(\u0026amp;quot;EVENT-HANDLER-LOGGER\u0026amp;quot;); @Override public int getPriority() { return 0; } @Override public void handleEvent(BeforeBizStartupEvent event) { Biz source = event.getSource(); LOGGER.info(\u0026amp;quot;begin to startup biz, current biz is: {}\u0026amp;quot;,source.getIdentity()); } } 日志目录：target/test/logs/host-app/event-handler.log 日志输出： 2019-11-28 15:18:33,248 INFO EVENT-HANDLER-LOGGER - begin to startup biz, current biz is: provider1:2.0.0, bizState: resolved\n 在此基础上，在提供其他几个 event 的处理器：\n AfterBizStartupEvent @Component public class AfterBizStartupEventHandler implements EventHandler\u0026amp;lt;AfterBizStartupEvent\u0026amp;gt; { private static final Logger LOGGER = LoggerFactory.getLogger(\u0026amp;quot;EVENT-HANDLER-LOGGER\u0026amp;quot;); @Override public void handleEvent(AfterBizStartupEvent event) { Biz source = event.getSource(); LOGGER.info(\u0026amp;quot;after startup biz, current biz is: {}, bizState: {}\u0026amp;quot;,source.getIdentity(),source.getBizState() ); } @Override public int getPriority() { return 0; } } 分别启动 基座 -\u0026amp;gt; 安装 ark-provider 模块 -\u0026amp;gt; 卸载 ark-provider 模块 ，然后看到日志输出如下：\n2019-11-28 15:31:42,325 INFO EVENT-HANDLER-LOGGER - after startup biz, current biz is: host-app:2.0.0, bizState: resolved 2019-11-28 15:36:23,956 INFO EVENT-HANDLER-LOGGER - begin to startup biz, current biz is: provider1:2.0.0, bizState: resolved 2019-11-28 15:36:27,216 INFO EVENT-HANDLER-LOGGER - after startup biz, current biz is: provider1:2.0.0, bizState: resolved 2019-11-28 15:53:38,225 INFO EVENT-HANDLER-LOGGER - before stop biz, current biz is: provider1:2.0.0, bizState: deactivated 2019-11-28 15:53:38,233 INFO EVENT-HANDLER-LOGGER - after biz stop, current biz is: provider1:2.0.0, bizState: unresolved 监听不指定类型的事件 某些情况下，如果期望监听所有 biz 或者 plugin 生命周期事件，可以使用以下方式：\n@Component public class AbstractArkEventHandler implements EventHandler\u0026amp;lt;AbstractArkEvent\u0026amp;gt; { @Override public int getPriority() { return 0; } @Override public void handleEvent(AbstractArkEvent event) { System.out.println(\u0026amp;quot;------------ current event topic: \u0026amp;quot; + event.getTopic()); } } 为了 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-event/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b0f233742572536edc8a517cf7547269","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","summary":"使用 Ark 事件处理机制 SOFAArk 从 1.1.0 版本开始提供了全新的事件模型，囊括了 SOFAArk 中 biz 和 plugin 的各个生命周期；该版本提供的事件模型参考了 Spring 中的生命周期事件模型。本篇","tags":null,"title":"Ark 事件机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","wordcount":1254},{"author":null,"categories":null,"content":" 本小节将介绍标准 Ark 包 的目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark 包。\nMaven 插件 官方提供 Maven 插件 sofa-ark-maven-plugin 可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式 Ark 包 ；基于 Fat Jar 技术，使用 java -jar 命令可以直接启动 Ark 包 。 Maven 插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals sofa-ark-maven-plugin 插件提供 goal: repackage， 可以将工程打包成可执行的 Ark 包，如下配置：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 配置信息 --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 完整配置模板 完整的 sofa-ark-maven-plguin 插件配置模板如下：\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--设置应用的根目录，用于读取 ${base.dir}/conf/ark/bootstrap.application 配置文件，默认为 ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;./\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;!--生成 ark 包文件名称，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;finalName\u0026amp;gt;demo-ark\u0026amp;lt;/finalName\u0026amp;gt; \u0026amp;lt;!--是否跳过执行 goal:repackage，默认为false--\u0026amp;gt; \u0026amp;lt;skip\u0026amp;gt;false\u0026amp;lt;/skip\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--设置 ark 包的 classifier，默认为空--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 classifier，默认为 ark-biz--\u0026amp;gt; \u0026amp;lt;bizClassifier\u0026amp;gt;ark-biz\u0026amp;lt;/bizClassifier\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 biz name，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;bizName\u0026amp;gt;demo-ark\u0026amp;lt;/bizName\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 biz version，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;bizVersion\u0026amp;gt;0.0.1\u0026amp;lt;/bizVersion\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 启动优先级，值越小优先级越高，${artifactId}--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;100\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的启动入口，默认会搜索被打 org.springframework.boot.autoconfigure.SpringBootApplication 注解且含有 main 方法的入口类--\u0026amp;gt; \u0026amp;lt;mainClass\u0026amp;gt;com.alipay.sofa.xx.xx.MainEntry\u0026amp;lt;/mainClass\u0026amp;gt; \u0026amp;lt;!--设置是否将 scope=provided 的依赖打包，默认为 false--\u0026amp;gt; \u0026amp;lt;packageProvided\u0026amp;gt;false\u0026amp;lt;/packageProvided\u0026amp;gt; \u0026amp;lt;!--设置是否生成 Biz 包，默认为true--\u0026amp;gt; \u0026amp;lt;keepArkBizJar\u0026amp;gt;true\u0026amp;lt;/keepArkBizJar\u0026amp;gt; \u0026amp;lt;!--针对 Web 应用，设置 context path，默认为 /--\u0026amp;gt; \u0026amp;lt;webContextPath\u0026amp;gt;/\u0026amp;lt;/webContextPath\u0026amp;gt; \u0026amp;lt;!--打包 ark biz 时，排除指定的包依赖；格式为: ${groupId:artifactId} 或者 ${groupId:artifactId:classifier}--\u0026amp;gt; \u0026amp;lt;excludes\u0026amp;gt; \u0026amp;lt;exclude\u0026amp;gt;org.apache.commons:commons-lang3\u0026amp;lt;/exclude\u0026amp;gt; \u0026amp;lt;/excludes\u0026amp;gt; \u0026amp;lt;!--打包 ark biz 时，排除和指定 groupId 相同的包依赖--\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jar/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c2a9b8ad142f15b9ee82d7d9d8237850","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","summary":"本小节将介绍标准 Ark 包 的目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark 包。 Maven 插件 官方提供 Maven 插件 sofa-ark-maven-plugin 可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式 Ark 包 ；","tags":null,"title":"Ark 包","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","wordcount":1626},{"author":null,"categories":null,"content":" Ark 应用的整体启动流程如下图所述：\n当用 java -jar 启动 Ark 包 或者 在 IDE 中通过 SofaArkBootstrap.launch 启动 Ark 应用时，相应 Launcher 入口会负责启动应用，其中会反射调用 ArkContainer 的入口，初始化 ArkService ，然后依次执行 pipeline，来完成整个 Ark 应用的启动。\nArkService Ark Serivce 是 Ark 容器中的服务，底层使用 Guice 对服务进行管理。同时针对服务，提供了生命周期接口 com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } 当服务实现了上述接口时，在 Ark Serivce 容器启动时和停止时会调用相应的生命周期接口\nPipeline 服务 Pipeline 也是注册在 Ark Service 容器中的一个服务，服务本身是没有顺序和优先级的，在 Pipeline 中会对服务进行一些组装，同时完成整个 Ark 容器的启动\nArchive 解析 在 Pipeline 的最开始，会将运行的 fatjar 进行解析，解析成运行时需要的模型，主要包括 Ark 插件模型和 Ark 业务模型，并将这些模型注册到 Ark Service 中的 PluginManagerService 以及 BizManagerService 中\n初始化环境 设置一些运行时需要的默认参数，比如设置 log4j.ignoreTCL 为 true 让 log4j/log4j2 初始化是日志不要从 ThreadContextClassloader 中寻找配置文件(背景)\n注册容器服务 在 Ark 容器中会发布一些服务供其它的插件来使用，比如 BizDeployer 来让 SOFAArk 官方插件 sofa-jarslink 来完成 biz 的动态加载/卸载等\n部署 Ark 插件 从 PluginManagerService 中获取到所有的 Ark 插件，并按照插件优先级顺序： * ClassloaderService 准备插件 export 类的 map 映射 * PluginDeployService 启动插件的 com.alipay.sofa.ark.spi.service.PluginActivator\n启动 Ark 业务 从 BizManagerService 中获取到所有的 Ark 业务，并执行业务配置在 MANIFEST.MF 属性 Main-Class 中提供的入口 main 函数\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ad60e803febd20607686a1b4ea98efc3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","summary":"Ark 应用的整体启动流程如下图所述： 当用 java -jar 启动 Ark 包 或者 在 IDE 中通过 SofaArkBootstrap.launch 启动 Ark 应用时，相应 Launcher 入口会负责启动应用，其中会反射调用 ArkContainer 的入口，初始化 ArkService ，然","tags":null,"title":"Ark 容器启动流程","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","wordcount":523},{"author":null,"categories":null,"content":" Ark 插件启动 Ark 中提供了插件启动的接口 com.alipay.sofa.ark.spi.service.PluginActivator ，其定义如下：\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } 插件只需要实现此接口，并在 MANIFEST.MF 中配置 activator 属性，就会在启动时执行 start 方法，停止时执行 stop 方法\nArk 插件通信 Ark 之间的通信是通过服务来完成的， 在上述启动接口方法的入参类型 com.alipay.sofa.ark.spi.model.PluginContext 中提供了发布服务和引用服务的接口\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param pluginName the name of the plugin which publish the service * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String pluginName); /** * Get Service List publish by plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;ServiceReference\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; referenceServices(Class\u0026amp;lt;T\u0026amp;gt; ifClass); 插件服务是以接口为粒度的，针对同一个接口： * 每一个插件只允许发布一个服务，重复发布则会直接返回已经发布服务的引用 * 当多有个插件发布服务时，若通过 referenceService 引用单个服务 * 当不指定 pluginName 时，则返回优先级最高的服务 * 当指定 pluginName 时，则返回该插件发布的服务\n返回的服务引用 ServiceReference 定义如下:\npublic interface ServiceReference\u0026amp;lt;T\u0026amp;gt; { /** * get Service Object * @return service */ T getService(); /** * get Service Metadata * @return */ ServiceMetadata getServiceMetadata(); } public interface ServiceMetadata { /** * get Service Unique Name * @return service name */ String getServiceName(); /** * get Service Interface Class * @return interface class */ Class\u0026amp;lt;?\u0026amp;gt; getInterfaceClass(); /** * get ServiceProvider * @return */ ServiceProvider getServiceProvider(); } 其中通过 * getService() 可以获取到服务的实体 (也即发布服务时的 implObject) * getServiceMetadata() 可以获取到服务的元数据信息，包括 * 服务名：即服务的接口名 * 服务接口 * 服务的提供方：包括提供方名字(插件名等)、提供方优先级(插件优先级)\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-plugin/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b552fc51eb84cc0fa4c26860bd316490","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","summary":"Ark 插件启动 Ark 中提供了插件启动的接口 com.alipay.sofa.ark.spi.service.PluginActivator ，其定义如下： public interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } 插件只需要实","tags":null,"title":"Ark 容器插件机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","wordcount":574},{"author":null,"categories":null,"content":" Ark 容器类加载机制 Ark 容器中会管理插件和业务，整体的类加载机制可见如下图描述：\nArk 插件类加载机制 每个 Ark 插件都拥有一个独立的类加载器，其类加载的顺序如下：\n 如果是加载反射生成的字节码，那么会直接抛出 ClassNotFoundException，终止类加载。这一部分主要是来源于我们的工程实践，避免一定找不到的类查找路径过长 查找已经被加载过的类 查找 JDK 中的类，这一块主要包含两部分：第一部分是 ExtClassloader 负责加载的类；第二部分是 JDK 提供的类但从 ExtClassloader 中加载不到，但在本地运行时会被加入到 SystemClassloader 的 classpath 中，同时这些类可能会被放到一些三方工具包中，典型的如 tool.jar 中 sun.tools.attach.BsdVirtualMachine,这一部分也主要来源于我们的工程实践，避免类被加载超过一次，从而引发报错 看类是否是由 Sofa Ark 提供的接口类，典型的如: com.alipay.sofa.ark.spi.service.PluginActivator, 如果是，则类会委托给 Ark 容器的类加载器加载 看是否在插件的 import 中(包括 import-classes 和 import-package)， 如果在，则会委托给导出该类的插件类加载器加载 在插件自身的 classpath 中加载 如果上述都失败了，则会尝试在 SymtemClassloader 中加载，这一步主要是为了解决使用 agent 时的情形 如果上述的步骤都加载失败了，则抛出 ClassNotFoundException\nArk 业务类加载机制 每个 Ark 业务都拥有一个独立的类加载器， Ark 业务类加载机制基本上与 Ark 插件保持一致，在上述的7步中，主要是第5步不一样：\n对于 Ark 业务而言，并没有提供 import 的配置，而是认为默认 import 所有插件 export 出来的类；但为了一些特殊的业务场景，我们提供了 Deny-import 的配置让业务可以排除掉某些插件导出的类\nArk 插件资源加载机制 Ark 插件支持导入导出资源，需要在 sofa-ark-plugin-maven-plugin 配置相关的导入导出配置；在使用 ClassLoader 加载资源时，存在两种方式查找资源，ClassLoader.getResource(String) 和 ClassLoader.getResources(String)；\n ClassLoader.getResource(String): Ark Plugin 在查找单个资源时，会优先委托导出该资源的 Ark Plugin 加载，如果有多个插件同时导出，则优先级高的插件优先导出；如果加载失败或者没有其他 Ark Plugin 导出，则尝试在本 Ark Plugin 查找加载；\n ClassLoader.getResources(String): Ark Plugin 在查找多个资源时，会从所有导出该资源的 Ark Plugin 加载，同时也会从本 Ark Plugin 加载资源；\n Ark 业务资源加载机制 默认情况下，Ark Biz 会优先加载 Ark Plugin 导出的资源；如果开发者希望只在工程应用内部查找，则可以通过 sofa-ark-maven-plugin 配置 denyImportResources；如此，Ark Biz 不会从 Ark Plugin 查找该资源，只会在 Ark Biz 内部查找。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-classloader/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5803b870aae47885c37e4bbb02cb0a06","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","summary":"Ark 容器类加载机制 Ark 容器中会管理插件和业务，整体的类加载机制可见如下图描述： Ark 插件类加载机制 每个 Ark 插件都拥有一个独立的类加载器，其类加载的顺序","tags":null,"title":"Ark 容器类加载机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","wordcount":974},{"author":null,"categories":null,"content":" Ark 容器和 Ark Plugin 在运行时由不同的类加载器加载，不能使用常规的 ServiceLoader 提供 SPI 扩展，SOFAArk 自定义扩展点 SPI 机制， Ark Plugin 实现 SPI 机制，考虑到 Biz 卸载问题，Ark Biz 暂时不支持该 SPI 机制，只适用于 Ark Plugin 之间。\n声明扩展接口 使用注解 @Extensible 声明扩展接口，注解定义如下：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Extensible { /** * return specify extensible file name, default value is the * full name of interface. */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * return whether this a singleton, with a single, shared instance * returned on all calls, default value is true. */ boolean singleton() default true; } file 用于声明 SPI 扩展文件名，默认为接口全类名 singleton 用于声明加载扩展类是否为单例模式 声明扩展实现 使用注解 @Extension 声明扩展实现，注解定义如下：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Extension { /** * extension name */ String value(); /** * extension order, Higher values are interpreted as lower priority. * As a consequence, the object with the lowest value has the highest * priority. */ int order() default 100; } value 用于定义扩展实现名称，例如不同的插件扩展同一个接口，可能会取不同的名字。 order 用于决定具体扩展实现的生效顺序 运行时，对于同一个接口的扩展实现生效规则如下： + 规则一：名称相同的扩展实现，只会返回优先级高的扩展实现类，order 数字越小，优先级越高 + 规则二：名称不相同的扩展实现，则返回一个对应的 List 列表，每个名称返回优先级最高的扩展实现\n加载 SPI 实现类 正常情况下，我们使用 ServiceLoader 加载 SPI 接口实现；SOFAArk 提供了工具类 ArkServiceLoader 用于加载扩展实现，工具类定义了两个简单的方法：\npublic class ArkServiceLoader { private static ExtensionLoaderService extensionLoaderService; // 方法一 public static \u0026amp;lt;T\u0026amp;gt; T loadExtension(Class\u0026amp;lt;T\u0026amp;gt; interfaceType, String extensionName) { return extensionLoaderService.getExtensionContributor(interfaceType, extensionName); } // 方法二 public static \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;T\u0026amp;gt; loadExtension(Class\u0026amp;lt;T\u0026amp;gt; interfaceType) { return extensionLoaderService.getExtensionContributor(interfaceType); } } 方法一：用于加载指定接口和名称的扩展实现，返回单个结果。参考上述规则一 方法二：用于加载指定接口的扩展实现，返回列表结果。参考上述规则二 需要注意下，定义 SPI 接口的插件需要导出该接口，负责实现 SPI 接口的插件需要导入该接口。另外 SOFAArk 容器本身也会定义部分用于插件扩展实现的 SPI 接口，例如 ClassLoaderHook\n为什么不支持 Biz 的 SPI 扩展实现加载 考虑到 Biz 会动态的安装和卸载，如果支持 Biz 的扩展实现加载，生命周期容易引起混乱，暂时不考虑支持。如果确实存在 Ark Plugin 需要主动触发 Ark Biz 的逻辑调用，可以通过 SOFAArk 内部事件机制。\nSOFAArk 默认扩展点 SOFAArk 容器目前提供了唯一一个扩展点 ClassLoaderHook，用于其他插件提供扩展实现，自定义类/资源加载逻辑。ClassLoaderHooker 接口定义如下，用于扩展 BizClassLoader 和 PluginClassLoader 类(资源）加载逻辑：\n@Extensible public interface ClassLoaderHook\u0026amp;lt;T\u0026amp;gt; { Class\u0026amp;lt;?\u0026amp;gt; preFindClass(String name, ClassLoaderService classLoaderService, T t) throws ClassNotFoundException; Class\u0026amp;lt;?\u0026amp;gt; postFindClass(String name, ClassLoaderService classLoaderService, T t) throws ClassNotFoundException; URL preFindResource(String name, ClassLoaderService classLoaderService, T t); URL postFindResource(String name, ClassLoaderService classLoaderService, T t); Enumeration\u0026amp;lt;URL\u0026amp;gt; preFindResources(String name, ClassLoaderService classLoaderService, T t) throws IOException; Enumeration\u0026amp;lt;URL\u0026amp;gt; postFindResources(String name, ClassLoaderService classLoaderService, T t) throws IOException; } 通过在插件中扩展该 SPI 接口实现，可以自定义 PluginClassLoader 和 BizClassLoader 的类/资源的加载逻辑。 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-extension/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"685e049f442cde4f3f51fefad5453dae","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","summary":"Ark 容器和 Ark Plugin 在运行时由不同的类加载器加载，不能使用常规的 ServiceLoader 提供 SPI 扩展，SOFAArk 自定义扩展点 SPI 机制， Ark Plugin 实现 SPI 机制，考虑到 Biz 卸载问题，A","tags":null,"title":"Ark 扩展机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","wordcount":1961},{"author":null,"categories":null,"content":"SOFAArk 容器使用了 logback 日志实现，并集成了 sofa-common-tools，日志相关配置可以参考 配置文档, 这里介绍 SOFAArk 三个日志文件：\n sofa-ark/common-default.log \u0026amp;gt; sofa-ark 默认日志，打印 SOFAArk 启动日志等，大概内容如下： 2019-03-12 15:08:55,758 INFO main - Begin to start ArkServiceContainer 2019-03-12 15:08:56,290 INFO main - Init Service: com.alipay.sofa.ark.container.session.StandardTelnetServerImpl 2019-03-12 15:08:56,311 INFO main - Listening on port: 1234 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.plugin.PluginDeployServiceImpl 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.biz.BizDeployServiceImpl 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.classloader.ClassLoaderServiceImpl 2019-03-12 15:08:56,317 INFO main - Finish to start ArkServiceContainer 2019-03-12 15:08:56,338 INFO main - Start to process pipeline stage: com.alipay.sofa.ark.container.pipeline.HandleArchiveStage 2019-03-12 15:08:56,349 INFO main - Finish to process pipeline stage: com.alipay.sofa.ark.container.pipeline.HandleArchiveStage 2019-03-12 15:08:56,349 INFO main - Start to process pipeline stage: com.alipay.sofa.ark.container.pipeline.RegisterServiceStage 2019-03-12 15:08:56,354 INFO main - Service: com.alipay.sofa.ark.spi.service.biz.BizManagerService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,354 INFO main - Service: com.alipay.sofa.ark.spi.service.biz.BizFactoryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,355 INFO main - Service: com.alipay.sofa.ark.spi.service.plugin.PluginManagerService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,356 INFO main - Service: com.alipay.sofa.ark.spi.service.plugin.PluginFactoryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,356 INFO main - Service: com.alipay.sofa.ark.spi.service.event.EventAdminService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,357 INFO main - Service: com.alipay.sofa.ark.spi.service.registry.RegistryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,360 INFO main - Inject {field= bizManagerService} of {service= ServiceMetadata{service=\u0026#39;com.alipay.sofa.ark.spi.service.biz.BizDeployer\u0026#39;, provider=\u0026#39;ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=100}\u0026#39;}} success! sofa-ark/common-error.log \u0026amp;gt; sofa-ark 错误日志，打印 SOFAArk 容器运行时错误日志，例如 biz 启动失败日志等： 2019-03-12 16:38:41,873 ERROR main - Start biz: Startup In IDE meet error java.lang.reflect.InvocationTargetException: null at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-log/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a514225510e53e9bf7173734c1f878e1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","summary":"SOFAArk 容器使用了 logback 日志实现，并集成了 sofa-common-tools，日志相关配置可以参考 配置文档, 这里介绍 SOFAArk 三个日志文件： sofa-ark/common-default.log \u0026gt; sofa-ark 默认日志，打","tags":null,"title":"Ark 日志","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","wordcount":667},{"author":null,"categories":null,"content":" SOFAArk 定义了两种服务类型，用于解决应用和插件，应用和应用之间的通信问题，下面分别介绍这两种服务类型：\n插件服务 SOFAArk 允许在 Plugin 通过 PluginContext 发布和引用服务，也可以使用注解 @ArkInject 引用服务。为了方便开发高级特性，SOFAArk 容器默认将内部功能组件发布成了服务，包括 Biz 管理，Plugin 管理，事件管理，服务注册管理。目前不允许 Biz 发布服务，只能引用插件服务。下面介绍如何发布和引用插件服务，以及 SOFAArk 容器默认发布的服务。\n发布服务 每个 Plugin 都可以定义唯一的插件入口，需要实现 PluginActivator 接口并在打包插件配置中声明，先看下接口定义：\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkRuntimeException */ void start(PluginContext context); /** * Stop Plugin * @param context * @throws ArkRuntimeException */ void stop(PluginContext context); } SOFAArk 容器在启动插件时，会调用插件启动入口(如果有)，因此如果插件实现方需要发布插件服务供其他插件或者 Biz 调用，可以使用入参 PluginContext 发布服务，PluginContext 提供了两个方法发布服务：\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param uniqueId service implementation id * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject, String uniqueId); 这两个方法的区别在于是否指定 uniqueId，因为同一个接口，可能会有多个服务实现，因此需要使用 uniqueId 区别，同样在引用端也需要指定 uniqueId. 默认 uniqueId 为空\n引用服务 SOFAArk 提供了两种方式引用插件服务，在插件内部，可以直接使用 PluginContext 引用服务，PluginContext 提供了两个简单的方法引用服务：\n/** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param uniqueId service implementation * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String uniqueId); 在 Biz 内部，如果是 Spring Boot/SOFABoot 应用，可以直接使用注解 @ArkInject 引用服务，注解声明如下：\n@java.lang.annotation.Target(ElementType.FIELD) @java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME) @java.lang.annotation.Documented public @interface ArkInject { /** * ark service interface * @return */ Class\u0026amp;lt;?\u0026amp;gt; interfaceType() default void.class; /** * ark service uniqueId * * @return return reference unique-id */ String uniqueId() default \u0026amp;quot;\u0026amp;quot;; } SOFAArk 提供集成 Spring Boot/SOFABoot 功能，在 Field 上打上 @ArkInject，指定接口类型和 uniqueId 即可完成自动注入。为了更加方便的使用，如果没有指定 interfacetType 类型，默认使用被打注解的 Field 类型。\n在插件内部，有时候也可以使用 @ArkInject 引用服务，即插件在发布某个服务时，服务内部可以直接使用 @ArkInject 引用服务；需要注意的是，被引用的服务如果是其他插件发布的，则必须满足其他插件优先当前插件启动。\n默认服务 前面提到，为了方便 Plugin 和 Biz 开发高级特性，SOFAArk 将内部功能组件发布成服务，包括：\n BizManageService \u0026amp;gt; Biz 管理器，管理、查询 Biz 信息\n BizFactoryService \u0026amp;gt; Biz 解析器，解析 Biz 文件\n PluginManagerService \u0026amp;gt; Plugin 管理器，管理、查询 Plugin 信息\n PluginFactoryService \u0026amp;gt; Plugin 解析器，解析 Plugin 文件\n EventAdminService \u0026amp;gt; SOFAArk 事件管理器， …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-service/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"81b7e697b890139c03831cdb648e094b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","summary":"SOFAArk 定义了两种服务类型，用于解决应用和插件，应用和应用之间的通信问题，下面分别介绍这两种服务类型： 插件服务 SOFAArk 允许在 Plugin 通过 PluginContext 发布和引用服务，也可","tags":null,"title":"Ark 服务机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","wordcount":1188},{"author":null,"categories":null,"content":" 在 Ark 服务机制 中，我们详细介绍了如何引用和发布插件服务，主要是解决 Plugin 和 Biz 的通信问题；为了解决 Biz 之间的通信问题，SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference 编程界面；下面介绍其使用方法。\n引入依赖 引入 runtime-sofa-boot-plugin 依赖，如果应用基于 Spring Boot 1.x 开发，推荐使用 v2.6.1 版本；如果应用基于 Spring Boot 2.x 开发，推荐使用 v3.1.3 版本；\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 发布和引用 JVM 服务 SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference JVM 服务概念(参考文档)，为了方便文档统一，重复其介绍。\nSOFABoot 提供三种方式给开发人员发布和引用 JVM 服务\n XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上面的 Bean 发布成一个 SOFA JVM 服务。\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 上面的配置中的 interface 指的是需要发布成服务的接口，ref 指向的是需要发布成 JVM 服务的 Bean，至此，我们就已经完成了一个 JVM 服务的发布。\n服务引用 使用 SOFA 提供的 Spring 扩展标签引用服务:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上面的配置中的 interface 是服务的接口，需要和发布服务时配置的 interface 一致。id 属性的含义同 Spring BeanId。上面的配置会生成一个 id 为 sampleServiceRef 的 Spring Bean，你可以将 sampleServiceRef 这个 Bean 注入到当前 SOFABoot 模块 Spring 上下文的任意地方。\n service/reference 标签还支持 RPC 服务发布，相关文档: RPC 服务发布与引用\n Annotation 方式 警告\n如果一个服务已经被加上了 @SofaService 的注解，它就不能再用 XML 的方式去发布服务了，选择一种方式发布服务，而不是两种混用。\n 除了通过 XML 方式发布 JVM 服务和引用之外，SOFABoot 还提供了 Annotation 的方式来发布和引用 JVM 服务。通过 Annotation 方式发布 JVM 服务，只需要在实现类上加一个 @SofaService 注解即可，如下：\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } 提示\n@SofaService 的作用是将一个 Bean 发布成一个 JVM 服务，这意味着虽然你可以不用再写 \u0026amp;lt;sofa:service/\u0026amp;gt; 的配置，但是还是需要事先将 @SofaService 所注解的类配置成一个 Spring Bean。\n 在使用 XML 配置 \u0026amp;lt;sofa:service/\u0026amp;gt; 的时候，我们配置了一个 interface 属性，但是在使用 @SofaService 注解的时候，却没有看到有配置服务接口的地方。这是因为当被 @SofaService 注解的类只有一个接口的时候，框架会直接采用这个接口作为服务的接口。当被 @SofaService 注解的类实现了多个接口时，可以设置 @SofaService 的 interfaceType 字段来指定服务接口，比如下面这样：\n@SofaService(interfaceType = SampleInterface.class) public class SampleImpl implements SampleInterface, Serializable { public void test() { } } 和 @SofaService 对应，Sofa 提供了 @SofaReference 来引用一个 JVM 服务。假设我们需要在一个 Spring Bean 中使用 SampleJvmService 这个 JVM 服务，那么只需要在字段上加上一个 @SofaReference 的注解即可：\npublic class SampleServiceRef { @SofaReference private SampleService sampleService; } 和 @SofaService 类似，我们也没有在 @SofaReference 上指定服务接口，这是因为 @SofaReference 在不指定服务接口的时候，会采用被注解字段的类型作为服务接口，你也可以通过设定 @SofaReference 的 interfaceType 属性来指定：\npublic class SampleServiceRef { @SofaReference(interfaceType = SampleService.class) private SampleService sampleService; } 使用 @SofaService 注解发布服务时，需要在实现类上打上 @SofaService 注解；在 Spring Boot 使用 Bean Method 创建 Bean 时，会导致 @Bean 和 @SofaService 分散在两处，而且无法对同一个实现类使用不同的 unique id。 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jvm/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1bf80b24428da0f91edc6af7b63f6047","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","summary":"在 Ark 服务机制 中，我们详细介绍了如何引用和发布插件服务，主要是解决 Plugin 和 Biz 的通信问题；为了解决 Biz 之间的通信问题，SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference 编","tags":null,"title":"Ark 服务通信","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","wordcount":2430},{"author":null,"categories":null,"content":" Use java.lang.Runnable in thread If you start a thread via java.lang.Runnable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerRunnable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.start(); Use java.util.concurrent.Callable in thread If you start a thread via java.util.concurrent.Callable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerCallable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nExecutorService executor = Executors.newCachedThreadPool(); SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt; sofaTracerSpanSofaTracerCallable = new SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt;(new Callable\u0026amp;lt;Object\u0026amp;gt;() { @Override public Object call() throws Exception { return new Object(); } }); Future\u0026amp;lt;Object\u0026amp;gt; futureResult = executor.submit(sofaTracerSpanSofaTracerCallable); //do something in current thread Thread.sleep(1000); //another thread execute success and get result Object objectReturn = futureResult.get(); This example assumes that the object type returned by java.util.concurrent.Callable is java.lang.Object. You can replace it with the expected type based on actual situation.\nSOFATracer support for thread pool and asynchronous call scenarios Asynchronous Asynchronous invocation, in RPC calls, for example,each time the rpc call request goes out, it will not wait until the result is returned before initiating the next call. There is a time difference here, before the callback of the previous rpc call comes back, another new one begin. At this time, the TracerContext in the current thread is not cleaned up, the spanId will be incremented, and the tracerId is the same.\n For the above situation, when the SOFATracer is processed for the asynchronous situation, it will not wait for the callback to execute, and then the cr phase will be cleaned up. Instead, the current thread\u0026amp;rsquo;s tracerContext context will be cleaned up in advance to ensure the correctness of the link.\nThread Pool For now, whether it\u0026amp;rsquo;s SOFARPC or Dubbo\u0026amp;rsquo;s trace implementation, the situation is the same when using single-thread or thread pools:\n Synchronous call. A thread in the thread pool is allocated to handle the RPC request. This does not cause the next RPC request to take the tracerContext data of the previous request by mistake Asynchronous calls, since the asynchronous callback is not in the callback to clean up the context, but in advance, there is no dirty data problem. callback, which is essentially an …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/async/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e755346c441115663c101638667fe4c0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/async/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/async/","summary":"Use java.lang.Runnable in thread If you start a thread via java.lang.Runnable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerRunnable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.","tags":null,"title":"Asynchronous thread processing","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/async/","wordcount":436},{"author":null,"categories":null,"content":" ## Model\nApplications Jarslink manages the life cycle of multiple applications. During runtime dynamic deployment, it usually converts a Jar file entity into an abstract model Biz. + Biz: abstract model of the application at runtime\nInstruction Currently, Jarslink supports the telnet protocol and accepts the entered instructions. In the future, it will also support instruction execution through APIs. Acceptable instruction types: + InstallCommand: install the application + UninstallCommand: uninstall the application + CheckCommand: check the application state + SwitchCommand: switch the application state\nService The Jarslink plugin has expanded the SOFAArk container\u0026amp;rsquo;s services of BizDeployer and CommandProvider and referenced the SOFAArk container\u0026amp;rsquo;s exposed services of BizManagerService and BizFactoryService. + BizDeployer is the application deployment extension point provided by the SOFAArk container, and it is used to control the Biz startup in the Ark package. Jarslink has registered its own implementation with the SOFAArk container. + CommandProvider is the command processing extension point provided by the SOFAArk container, and it is used to process the commands received by the SOFAArk container through a telnet link. + BizManagerService is the Biz manager exposed by the SOFAArk container, and it is used for registration, deregistration, and other operations. + BizFactoryService is the Biz generator exposed by the SOFAArk container, and it is used to abstract static Biz package files into runtime Biz models.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-model/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"991cb277d50874fa27095b920ac9b736","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","summary":"## Model\nApplications Jarslink manages the life cycle of multiple applications. During runtime dynamic deployment, it usually converts a Jar file entity into an abstract model Biz. + Biz: abstract model of the application at runtime\nInstruction Currently, Jarslink supports the telnet protocol and accepts the entered instructions. In the future, it will also support instruction execution through APIs. Acceptable instruction types: + InstallCommand: install the application + UninstallCommand: uninstall the application + CheckCommand: check the application state + SwitchCommand: switch the application state","tags":null,"title":"Basic model","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","wordcount":221},{"author":null,"categories":null,"content":" Messages All messages are internally passed through SofaRequest and SofaResponse.\nTo convert to other protocols, you need to transform the messages to the objects that are to be actually transferred when calling and receiving requests.\nThe modules that can write SofaRequest and SofaResponse are as follows:\n Invoker Filter ServerHandler Serialization The modules that can only read message bodies are as follows:\n Cluster Router LoadBalance Logs The log initialization is based on the extension mechanism. Since the log loading should be done earliest, there is a separate key in rpc-config.json.\n{ / / Log implementation is done earlier than configuration loading, so it cannot adapt to the extension mechanism \u0026amp;quot;logger.impl\u0026amp;quot;: \u0026amp;quot;com.alipay.sofa.rpc.log.MiddlewareLoggerImpl\u0026amp;quot; } Configuration items RPC configuration for users The user configuration includes port configuration (although the fields for setting port in the objects have been opened, SOFA gets those fields from the configuration file by default), thread pool size configuration, and other configurations.\n Load the configuration via SofaConfigs and call ExternalConfigLoader to read external properties. Get the configuration through the API provided by SofaConfigs. All the internally configured keys are in the SofaOptions class. Priority: System.property \u0026amp;gt; sofa-config.properties (one for each application) \u0026amp;gt; rpc-config.properties. RPC framework configuration The configuration of the framework itself, such as default serialization and default timeout. In the future, SOFARPC may support the configuration for multiple ClassLoaders.\n Load the configuration file via RpcConfigs. Get and listen to data changes via the API provided by RpcConfigs All internally configured keys are in the RpcOptions class Priority: System.property \u0026amp;gt; custom rpc-config.json (There may be multiple custom configuration files which are sorted in certain order) \u0026amp;gt; rpc-config-default.json. Constants The global basic constants are in RpcConstants. For example: Calling method (sync/oneway) Protocol (bolt/grpc/rest); serialization (hessian/java/protobuf) Context key If the extension implements its own constants, you need to maintain the constants yourself. For example:\n The constants of BOLT protocol SERIALIZE_CODE_HESSIAN = 1 PROTOCOL_TR = 13 The constants related with DSR Configuration Center The keys specific for DSR Configuration Center, such as _WEIGHT and _CONNECTTIMEOUT Address The address information of provider is placed in the ProviderInfo class. The value of ProviderInfo is mainly divided into three parts: Fields, which are generally required items, such as IP, port and status. Static fields, such as application name. Dynamic fields, such as warm-up weight. Field enumerations are maintained in the ProviderInfoAttrs class. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/common-model/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b2cc3f7ed134408d6adc25e418e1978b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/common-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/common-model/","summary":"Messages All messages are internally passed through SofaRequest and SofaResponse.\nTo convert to other protocols, you need to transform the messages to the objects that are to be actually transferred when calling and receiving requests.\nThe modules that can write SofaRequest and SofaResponse are as follows:\n Invoker Filter ServerHandler Serialization The modules that can only read message bodies are as follows:\n Cluster Router LoadBalance Logs The log initialization is based on the extension mechanism.","tags":null,"title":"Basic model","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/common-model/","wordcount":386},{"author":null,"categories":null,"content":" Publish Service To use SOFARPC to publish a Bolt-protocol service, you only need to add a Binding named bolt. The ways to add Bolt Binding are as follows:\nXML To publish a Bolt service using XML, simply add the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag to the \u0026amp;lt;sofa:service\u0026amp;gt; tag:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation To publish a Bolt service using Annotation, you only need to set the bindingType of @SofaServiceBinding to bolt:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)}) Public class SampleServiceImpl implements SampleService { } API in Spring environment To publish a Bolt-protocol service in Spring or Spring Boot environment, just add BoltBindingParam to ServiceParam:\nServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(SampleService.class); // Set the service interface serviceParam.setInstance(new SampleServiceImpl()); // Set the implementation of the service interface List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); Params.add(serviceBindingParam); serviceParam.setBindingParams(params); API in non-Spring environment To provide the Bolt-protocol service using the bare API of SOFARPC in a non-Spring environment, just set the ServerConfig whose protocol is Bolt to the corresponding ProviderConfig:\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;); // Create a new ServerConfig with Bolt protocol ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRef(new SampleServiceImpl()) .setServer(serverConfig) // Set ServerConfig to ProviderConfig to indicate that the protocol published by this service is Bolt. .setRegistry(registryConfig); providerConfig.export(); Reference Service To reference a Bolt-protocol service using SOFARPC, just add a Binding named bolt. The ways to use Bolt Binding are as follows:\nXML To reference a Bolt-protocol service using XML, simply add the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag to the \u0026amp;lt;sofa:reference\u0026amp;gt; tag:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation To reference a Bolt-protocol service using Annotation, just set the bindingType of @SofaReferenceBinding to bolt:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) Private SampleService sampleService; API in Spring environment To reference a Bolt-protocol service in a Spring or Spring Boot environment, simply add a BoltBindingParam to ReferenceParam:\nReferenceClient …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-usage/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dd929c0a3cd2f4620ddf0d30d98ba85d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","summary":"Publish Service To use SOFARPC to publish a Bolt-protocol service, you only need to add a Binding named bolt. The ways to add Bolt Binding are as follows:\nXML To publish a Bolt service using XML, simply add the \u0026lt;sofa:binding.bolt\u0026gt; tag to the \u0026lt;sofa:service\u0026gt; tag:\n\u0026lt;sofa:service ref=\u0026quot;sampleService\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.sample.SampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt/\u0026gt; \u0026lt;/sofa:service\u0026gt; Annotation To publish a Bolt service using Annotation, you only need to set the bindingType of @SofaServiceBinding to bolt:","tags":null,"title":"Basic usage of Bolt protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","wordcount":364},{"author":null,"categories":null,"content":" In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the Dubbo protocol, just set Binding to Dubbo. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish a Dubbo service, just set the bindingType of @SofaServiceBinding to dubbo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a Dubbo service, just set the bindingType of @SofaReferenceBinding to dubbo:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; Set the Group of Dubbo Service In the SOFARPC program model, there is no field called Group, but there is a model of uniqueId, which can be directly mapped to the Group in Dubbo model. For example, the following code is to publish a service whose Group is groupDemo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}, uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;) public class SampleServiceImpl implements SampleService { } The following code is to reference a service whose Group is groupDemo:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;, jvmFirst = false) private SampleService sampleService; Note that Dubbo protocol currently only supports Zookeeper as service registry center.\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo-usage/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1bf72c194a20a5dccea70423690191f4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","summary":"In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the Dubbo protocol, just set Binding to Dubbo. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish a Dubbo service, just set the bindingType of @SofaServiceBinding to dubbo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026quot;dubbo\u0026quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a Dubbo service, just set the bindingType of @SofaReferenceBinding to dubbo:","tags":null,"title":"Basic usage of Dubbo protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","wordcount":203},{"author":null,"categories":null,"content":" In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the H2C protocol, just set Binding to H2C. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish an H2C service, just set the bindingType of @SofaServiceBinding to h2c:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a H2C service, just set the bindingType of @SofaReferenceBinding to h2c:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c-usage/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fa75eff1e99b3acad5087160a1b44a09","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","summary":"In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the H2C protocol, just set Binding to H2C. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish an H2C service, just set the bindingType of @SofaServiceBinding to h2c:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026quot;h2c\u0026quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a H2C service, just set the bindingType of @SofaReferenceBinding to h2c:","tags":null,"title":"Basic usage of H2C protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","wordcount":100},{"author":null,"categories":null,"content":" In SOFARPC (Not In SOFABoot/SpringBoot)，when use Http as a protocol of server，we can use Json as the way of serialization，for some basic test scenes.\nSOFARPC API Usage Service Publish ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026amp;quot;serverApp\u0026amp;quot;)) .setServer(serverConfig) .setUniqueId(\u0026amp;quot;uuu\u0026amp;quot;) .setRegister(false); providerConfig.export(); Service Consume Because of the Http+Json，So users can use HttpClient to start a normal call, this is a piece of code in test.\nprivate ObjectMapper mapper = new ObjectMapper(); HttpClient httpclient = HttpClientBuilder.create().build(); // POST normal request String url = \u0026amp;quot;http://127.0.0.1:12300/com.alipay.sofa.rpc.server.http.HttpService:uuu/object\u0026amp;quot;; HttpPost httpPost = new HttpPost(url); httpPost.setHeader(RemotingConstants.HEAD_SERIALIZE_TYPE, \u0026amp;quot;json\u0026amp;quot;); ExampleObj obj = new ExampleObj(); obj.setId(1); obj.setName(\u0026amp;quot;xxx\u0026amp;quot;); byte[] bytes = mapper.writeValueAsBytes(obj); ByteArrayEntity entity = new ByteArrayEntity(bytes, ContentType.create(\u0026amp;quot;application/json\u0026amp;quot;)); httpPost.setEntity(entity); HttpResponse httpResponse = httpclient.execute(httpPost); Assert.assertEquals(200, httpResponse.getStatusLine().getStatusCode()); byte[] data = EntityUtils.toByteArray(httpResponse.getEntity()); ExampleObj result = mapper.readValue(data, ExampleObj.class); Assert.assertEquals(\u0026amp;quot;xxxxx\u0026amp;quot;, result.getName()); You will get some result.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http-json/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"28abdf6369247346bad670c639a422b8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/http-json/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/http-json/","summary":"In SOFARPC (Not In SOFABoot/SpringBoot)，when use Http as a protocol of server，we can use Json as the way of serialization，for some basic test scenes.\nSOFARPC API Usage Service Publish ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); ProviderConfig\u0026lt;HttpService\u0026gt; providerConfig = new ProviderConfig\u0026lt;HttpService\u0026gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026quot;serverApp\u0026quot;)) .setServer(serverConfig) .setUniqueId(\u0026quot;uuu\u0026quot;) .setRegister(false); providerConfig.export(); Service Consume Because of the Http+Json，So users can use HttpClient to start a normal call, this is a piece of code in test.","tags":null,"title":"Basic usage of HTTP protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/http-json/","wordcount":140},{"author":null,"categories":null,"content":" In SOFARPC, using different communication protocols is equal to using different Bindings. If you need to use the RESTful protocol, just set Binding to REST.\nPublish Service When defining a RESTful service interface, you need to add meta information to the interface using the annotations in JAXRS standard, such as the following interface:\n@Path(\u0026amp;quot;sample\u0026amp;quot;) public interface SampleService { @GET @Path(\u0026amp;quot;hello\u0026amp;quot;) String hello(); } The annotations in JAXRS standard can be found in RESTEasy documentation.\n After the interface is defined, you can publish the implementation of the interface as a service, for example, by means of Annotation:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}) public class RestfulSampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } If you want to publish the service by other methods, please refer to Basic usage of Bolt protocol.\nAccess services through browser After the service is published, you can directly access the service through the browser. For the above service, the access address is as follows:\nhttp://localhost:8341/sample/hello The default port for SOFARPC RESTful service is 8341.\nReference Service In addition to accessing RESTful services published by SOFARPC through a browser, you can also reference services through the standard SOFARPC service reference methods, such as Annotation:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)) private SampleService sampleService; If you want to reference the service by other methods, please refer to Basic usage of Bolt protocol.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-basic/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d41f976864ba8f8221f5b5d26f354d1c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-basic/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-basic/","summary":"In SOFARPC, using different communication protocols is equal to using different Bindings. If you need to use the RESTful protocol, just set Binding to REST.\nPublish Service When defining a RESTful service interface, you need to add meta information to the interface using the annotations in JAXRS standard, such as the following interface:\n@Path(\u0026quot;sample\u0026quot;) public interface SampleService { @GET @Path(\u0026quot;hello\u0026quot;) String hello(); } The annotations in JAXRS standard can be found in RESTEasy documentation.","tags":null,"title":"Basic usage of RESTful protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-basic/","wordcount":228},{"author":null,"categories":null,"content":" Benchmark 源码解析任务还在进行中，敬请期待！\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-benchmark/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fdcbd9e5c563ad087756f0703f94db61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","summary":"Benchmark 源码解析任务还在进行中，敬请期待！","tags":null,"title":"Benchmark","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","wordcount":18},{"author":null,"categories":null,"content":" Test code\nTest environment and conditions Three 16-core 20 GB memory Docker containers as the server nodes (3 replicas) Two to eight 8-core Docker containers as clients 24 Raft groups. Each server node has eight leaders responsible for processing read/right requests. Followers do not have the permission to read. The target of stress testing is the RheaKV module of JRaft. Only the put and get APIs are subject to stress testing. Linearizable reads are guaranteed for the get API. The key size and value size are both 16 bytes. The read percentage is 10% and the write percentage is 90%. Currently, the test scenarios are relatively simple. We will add more test scenarios in the future.\nTest scenario 1 Scenario 1: Test conditions Number of clients Client batching Storage type Read/write ratio Replicator pipeline Key size Value size 8 Enabled MemoryDB 1:9 Enabled 16 bytes 16 bytes Scenario 1: Result summary Eight clients achieved 400,000+ ops, and the p95 RT is within 8 ms. Three server nodes didn\u0026amp;rsquo;t reach their maximum load. The load is about 15, and the CPU usage is about 40%. Scenario 1: Load of three servers Scenario 1: Server 1 top - 20:11:14 up 10 days, 23:09, 1 user, load average: 12.29, 6.92, 4.00 Tasks: 36 total, 1 running, 35 sleeping, 0 stopped, 0 zombie %Cpu0 : 24.3 us, 17.7 sy, 0.0 ni, 50.0 id, 2.0 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu1 : 21.9 us, 18.5 sy, 0.0 ni, 49.5 id, 2.0 wa, 0.0 hi, 0.0 si, 8.1 st %Cpu2 : 20.6 us, 18.6 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 5.6 st %Cpu3 : 23.3 us, 20.0 sy, 0.0 ni, 50.3 id, 1.3 wa, 0.0 hi, 0.0 si, 5.0 st %Cpu4 : 24.1 us, 19.1 sy, 0.0 ni, 49.8 id, 2.3 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu5 : 21.3 us, 18.9 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu6 : 24.7 us, 18.4 sy, 0.0 ni, 50.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu7 : 24.8 us, 17.8 sy, 0.0 ni, 50.0 id, 1.7 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu8 : 26.0 us, 18.3 sy, 0.0 ni, 51.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu9 : 26.6 us, 16.9 sy, 0.0 ni, 52.2 id, 2.0 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu10 : 31.7 us, 17.7 sy, 0.0 ni, 46.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu11 : 23.2 us, 18.9 sy, 0.0 ni, 53.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu12 : 25.6 us, 18.3 sy, 0.0 ni, 51.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu13 : 22.6 us, 18.3 sy, 0.0 ni, 54.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu14 : 24.7 us, 17.3 sy, 0.0 ni, 54.0 id, 1.7 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu15 : 61.8 us, 8.3 sy, 0.0 ni, 28.2 id, 0.3 wa, 0.0 hi, 0.0 si, 1.3 st KiB Mem : 62914560 total, 6854596 free, 39128016 used, 16931948 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 6854596 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15682 root 20 0 12.853g 8.859g 24064 S 708.7 14.8 26:49.38 java Scenario 1: Server 2 top - 20:11:47 up 10 days, 23:03, 1 user, load average: 17.68, 8.50, 4.56 Tasks: 33 total, 1 running, 31 sleeping, 0 stopped, 1 zombie %Cpu0 : 22.7 us, 17.3 sy, 0.0 ni, 35.0 id, 8.3 wa, 0.0 hi, 0.0 si, 16.7 st %Cpu1 : 20.1 us, 19.4 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/benchmark-performance/","fuzzywordcount":8900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4530827525ca87732eaf76ae34f03603","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","publishdate":"0001-01-01T00:00:00Z","readingtime":42,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","summary":"Test code\nTest environment and conditions Three 16-core 20 GB memory Docker containers as the server nodes (3 replicas) Two to eight 8-core Docker containers as clients 24 Raft groups. Each server node has eight leaders responsible for processing read/right requests. Followers do not have the permission to read. The target of stress testing is the RheaKV module of JRaft. Only the put and get APIs are subject to stress testing.","tags":null,"title":"Benchmark data","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","wordcount":8817},{"author":null,"categories":null,"content":" 测试代码\n测试环境\u0026amp;amp;条件 3 台 16C 20G 内存的 docker 容器作为 server node (3 副本) 2 ~ 8 台 8C docker 容器 作为 client 24 个 raft 复制组，平均每台 server node 上各自有 8 个 leader 负责读写请求，不开启 follower 读 压测目标为 JRaft 中的 RheaKV 模块，只压测 put、get 两个接口，其中 get 是保证线性一致读的，key 和 value 大小均为 16 字节 读比例 10%，写比例 90% 目前的测试场景比较简单，以后会增加更多测试场景\n测试场景1 场景1: 测试条件 Client 数量 Client-Batching Storage-Type 读写比例 Replicator-Pipeline key 大小 value 大小 8 开启 MemoryDB 1:9 开启 16 字节 16字节 场景1: 结果汇总： 8 个 client 一共达到 40w+ ops，p95 RT 在 8ms 以内 3 个 server 节点负载没达到极限 load 15 左右，cpu 40% 左右 场景1: 3 个 server 机器负载： 场景1: server1 top - 20:11:14 up 10 days, 23:09, 1 user, load average: 12.29, 6.92, 4.00 Tasks: 36 total, 1 running, 35 sleeping, 0 stopped, 0 zombie %Cpu0 : 24.3 us, 17.7 sy, 0.0 ni, 50.0 id, 2.0 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu1 : 21.9 us, 18.5 sy, 0.0 ni, 49.5 id, 2.0 wa, 0.0 hi, 0.0 si, 8.1 st %Cpu2 : 20.6 us, 18.6 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 5.6 st %Cpu3 : 23.3 us, 20.0 sy, 0.0 ni, 50.3 id, 1.3 wa, 0.0 hi, 0.0 si, 5.0 st %Cpu4 : 24.1 us, 19.1 sy, 0.0 ni, 49.8 id, 2.3 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu5 : 21.3 us, 18.9 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu6 : 24.7 us, 18.4 sy, 0.0 ni, 50.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu7 : 24.8 us, 17.8 sy, 0.0 ni, 50.0 id, 1.7 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu8 : 26.0 us, 18.3 sy, 0.0 ni, 51.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu9 : 26.6 us, 16.9 sy, 0.0 ni, 52.2 id, 2.0 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu10 : 31.7 us, 17.7 sy, 0.0 ni, 46.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu11 : 23.2 us, 18.9 sy, 0.0 ni, 53.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu12 : 25.6 us, 18.3 sy, 0.0 ni, 51.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu13 : 22.6 us, 18.3 sy, 0.0 ni, 54.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu14 : 24.7 us, 17.3 sy, 0.0 ni, 54.0 id, 1.7 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu15 : 61.8 us, 8.3 sy, 0.0 ni, 28.2 id, 0.3 wa, 0.0 hi, 0.0 si, 1.3 st KiB Mem : 62914560 total, 6854596 free, 39128016 used, 16931948 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 6854596 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15682 root 20 0 12.853g 8.859g 24064 S 708.7 14.8 26:49.38 java 场景1: server2 top - 20:11:47 up 10 days, 23:03, 1 user, load average: 17.68, 8.50, 4.56 Tasks: 33 total, 1 running, 31 sleeping, 0 stopped, 1 zombie %Cpu0 : 22.7 us, 17.3 sy, 0.0 ni, 35.0 id, 8.3 wa, 0.0 hi, 0.0 si, 16.7 st %Cpu1 : 20.1 us, 19.4 sy, 0.0 ni, 43.8 id, 9.4 wa, 0.0 hi, 0.0 si, 7.4 st %Cpu2 : 23.3 us, 20.0 sy, 0.0 ni, 39.7 id, 10.3 wa, 0.0 hi, 0.0 si, 6.7 st %Cpu3 : 24.1 us, 20.1 sy, 0.0 ni, 40.8 id, 9.4 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu4 : 21.4 us, 17.7 sy, 0.0 ni, 37.1 id, 9.0 wa, 0.0 hi, 0.0 si, 14.7 st %Cpu5 : 22.6 us, 19.6 sy, 0.0 ni, 40.5 id, 10.6 wa, 0.0 hi, 0.0 si, 6.6 st %Cpu6 : 23.6 us, 19.9 sy, 0.0 ni, 40.2 id, 10.3 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu7 : 20.5 us, 19.9 sy, 0.0 ni, 44.4 id, 9.9 wa, 0.0 hi, 0.0 si, 5.3 st %Cpu8 : 40.7 us, 13.3 sy, 0.0 ni, 34.3 id, 9.0 wa, 0.0 hi, 0.0 si, 2.7 st %Cpu9 : 39.9 us, 14.0 sy, 0.0 ni, 35.2 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/benchmark-performance/","fuzzywordcount":9300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4530827525ca87732eaf76ae34f03603","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/benchmark-performance/","publishdate":"0001-01-01T00:00:00Z","readingtime":19,"relpermalink":"/sofastack.tech/projects/sofa-jraft/benchmark-performance/","summary":"测试代码 测试环境\u0026amp;条件 3 台 16C 20G 内存的 docker 容器作为 server node (3 副本) 2 ~ 8 台 8C docker 容器 作为 client 24 个 raft 复制组，平均每台 server node 上各自有 8 个 leader 负责读写请求","tags":null,"title":"Benchmark 数据","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/benchmark-performance/","wordcount":9269},{"author":null,"categories":null,"content":"Bolt protocol is a TCP-based custom protocol that performs better than HTTP. Within Ant Financial, a large number of RPCs use the Bolt protocol to communicate: * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b812f6aadadf38b79140a711ff6aa6cd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt/","summary":"Bolt protocol is a TCP-based custom protocol that performs better than HTTP. Within Ant Financial, a large number of RPCs use the Bolt protocol to communicate: * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool","tags":null,"title":"Bolt protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt/","wordcount":45},{"author":null,"categories":null,"content":"Bolt 协议一个基于 TCP 的自定义的协议，相比 HTTP 来说，性能更好，在蚂蚁金服内部，大量的 RPC 都是采用 Bolt 协议来进行通信： * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化协议 * 自定义线程池\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b812f6aadadf38b79140a711ff6aa6cd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt/","summary":"Bolt 协议一个基于 TCP 的自定义的协议，相比 HTTP 来说，性能更好，在蚂蚁金服内部，大量的 RPC 都是采用 Bolt 协议来进行通信： * 基本使用 * 调用方式 * 超时控制 * 泛化","tags":null,"title":"Bolt 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt/","wordcount":85},{"author":null,"categories":null,"content":" Bolt 协议基本使用 发布服务 使用 SOFARPC 发布一个 Bolt 协议的服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下：\nXML 使用 XML 发布一个 Bolt 协议只需要在 \u0026amp;lt;sofa:service\u0026amp;gt; 标签下增加 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签即可：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation 使用 Annotation 发布一个 Bolt 协议的服务只需要设置 @SofaServiceBinding 的 bindingType 为 bolt 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Spring 环境下 API 方式 在 Spring 或者 Spring Boot 环境下发布一个 Bolt 协议的服务只需要往 ServiceParam 里面增加一个 BoltBindingParam 即可：\nServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(SampleService.class); // 设置服务接口 serviceParam.setInstance(new SampleServiceImpl()); // 设置服务接口的实现 List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); 非 Spring 环境下的 API 方式 在非 Spring 环境下使用 SOFARPC 的裸 API 提供 Bolt 协议的服务，只需要将 Protocol 为 Bolt 的 ServerConfig 设置给对应的 ProviderConfig：\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;); // 新建一个协议为 Bolt 的 ServerConfig ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRef(new SampleServiceImpl()) .setServer(serverConfig) // 将 ServerConfig 设置给 ProviderConfig，表示这个服务发布的协议为 Bolt。 .setRegistry(registryConfig); providerConfig.export(); 引用服务 使用 SOFARPC 引用一个 Bolt 服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下：\nXML 使用 XML 引用一个 Bolt 协议的服务只需要在 \u0026amp;lt;sofa:reference\u0026amp;gt; 标签下增加 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签即可：\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 使用 Annotation 引用一个 Bolt 协议的服务只需要设置 @SofaReferenceBinding 的 bindingType 为 bolt 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private SampleService sampleService; Spring 环境下 API 方式 在 Spring 或者 Spring Boot 环境下引用一个 Bolt 协议的服务只需要往 ReferenceParam 里面增加一个 BoltBindingParam 即可：\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;SampleService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;SampleService\u0026amp;gt;(); referenceParam.setInterfaceType(SampleService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); 非 Spring 环境下的 API 方式 在非 Spring 环境下使用 SOFARPC 的裸 API 引用一个 Bolt 协议的服务，只需要设置 ConsumerConfig 的 Protocol 为 bolt 即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-usage/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dd929c0a3cd2f4620ddf0d30d98ba85d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt-usage/","summary":"Bolt 协议基本使用 发布服务 使用 SOFARPC 发布一个 Bolt 协议的服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下： XML 使用 XML 发布一个 Bolt 协议只需要","tags":null,"title":"Bolt 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt-usage/","wordcount":570},{"author":null,"categories":null,"content":" 泛化调用提供了让客户端在不需要依赖服务端的接口情况下就能够发起调用的能力。目前 SOFARPC 的泛化调用仅支持在 Bolt 通信协议下使用 Hessian2 作为序列化协议，其他的方式并不支持。\nSOFABoot 环境 发布服务 发布服务没有什么特殊的,正常发布服务即可.比如\n\u0026amp;lt;!-- generic --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 引用服务 \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.api.GenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs generic-interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 其中,jvm-first根据实际情况,默认可以不写,接口写泛化调用的通用接口,generic-interface中写上自己要调用的接口名称即可.\n发起调用 GenericService sampleGenericServiceReference = (GenericService) applicationContext .getBean(\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot;); GenericObject genericResult = (GenericObject) sampleGenericServiceReference.$genericInvoke(\u0026amp;quot;sayGeneric\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericParamModel\u0026amp;quot; }, new Object[] { genericObject }); RPC API ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt;() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); 如上通过 setGeneric 设置该服务为泛化服务，设置服务方的接口名。以 GenericService 作为泛化服务，通过 GenericService 就能够发起泛化调用了。发起调用时，需要传入方法名，方法类型，方法参数。\n如果参数或者返回结果在客户端也需要泛化表示。可以通过 GenericObject 来实现。\nGenericObject genericObject = new GenericObject(\u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot;); genericObject.putField(\u0026amp;quot;str\u0026amp;quot;, \u0026amp;quot;xxxx\u0026amp;quot;); genericObject.putField(\u0026amp;quot;num\u0026amp;quot;, 222); GenericObject result = (GenericObject) testService.$genericInvoke(\u0026amp;quot;echoObj\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot; }, new Object[] { genericObject }); String str = result.getField(\u0026amp;quot;str\u0026amp;quot;); String num = result.getField(\u0026amp;quot;num\u0026amp;quot;); 如上就能获得序列化结果。完整的泛化调用方式使用说明如下：\n/** * Java Bean */ public class People { private String name; private int age; // getters and setters } /** * 服务方提供的接口 */ interface SampleService { String hello(String arg); People hello(People people); String[] hello(String[] args); } /** * 客户端 */ public class ConsumerClass { GenericService genericService; public void do() { // 1. $invoke仅支持方法参数类型在当前应用的 ClassLoader 中存在的情况 genericService.$invoke(\u0026amp;quot;hello\u0026amp;quot;, new String[]{ String.class.getName() }, new Object[]{\u0026amp;quot;I\u0026#39;m an arg\u0026amp;quot;}); // 2. $genericInvoke支持方法参数类型在当前应用的 ClassLoader 中不存在的情况。 // 2.1 构造参数 GenericObject genericObject = new …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/generic-invoke/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"84ac624dc99a42a8f89489aa10304ef7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/generic-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/generic-invoke/","summary":"泛化调用提供了让客户端在不需要依赖服务端的接口情况下就能够发起调用的能力。目前 SOFARPC 的泛化调用仅支持在 Bolt 通信协议下使用 Hessian2 作为序列化协议，其他的方","tags":null,"title":"Bolt 协议泛化调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/generic-invoke/","wordcount":710},{"author":null,"categories":null,"content":" 调用方式 SOFARPC 在 Bolt 协议下提供了多种调用方式满足不同的场景。\n同步 在同步的调用方式下，客户端发起调用后会等待服务端返回结果再进行后续的操作。这是 SOFARPC 的默认调用方式，无需进行任何设置即可。\n异步 异步调用的方式下，客户端发起调用后不会等到服务端的结果，继续执行后面的业务逻辑。服务端返回的结果会被 SOFARPC 缓存，当客户端需要结果的时候，再主动调用 API 获取。如果需要将一个服务设置为异步的调用方式，在对应的使用方式下设置 type 属性即可：\nXML 方式 在 XML 方式下，设置 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 type 属性为 future 即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 在 Annotation 方式下，设置 @SofaReferenceBinding 的 invokeType 属性为 future 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, invokeType = \u0026amp;quot;future\u0026amp;quot;)) private SampleService sampleService; Spring 环境下 API 方式 在 Spring 环境下使用 API，设置 BoltBindingParam 的 type 属性即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setType(\u0026amp;quot;future\u0026amp;quot;); 在非 Spring 环境下 API 方式 在非 Spring 环境下使用 SOFARPC 裸 API，设置 ConsumerConfig 的 invokeType 属性即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setInvokeType(\u0026amp;quot;future\u0026amp;quot;); 获取调用结果 使用异步调用的方式，目前提供了两种方式来获取异步调用的结果：\n直接获取结果 用户可以通过以下的方式来直接获取异步调用的结果：\nString result = (String)SofaResponseFuture.getResponse(0, true); 其中第一个参数是获取结果的超时时间，第二个参数表示是否清除线程上下文中的结果。\n获取 JDK 原生 Future 用户可以通过以下的方式来获取 JDK 的原生的 Future 对象，再可以从任意地方去调用这个 Future 对象来获取结果：\nFuture future = SofaResponseFuture.getFuture(true); 其中的第一个参数表示是否清除线程上下文中的结果。\n回调 SOFARPC Bolt 协议的回调方式可以让 SOFARPC 在发起调用后不等待结果，在客户端收到服务端返回的结果后，自动回调用户实现的一个回调接口。\n使用 SOFARPC Bolt 协议的回调方式，首先需要实现一个回调接口，并且在对应的配置中设置回调接口，再将调用方式设置为 callback。\n实现回调接口 SOFARPC 提供了一个回调的接口 com.alipay.sofa.rpc.core.invoke.SofaResponseCallback，用户使用 SOFARPC Bolt 协议的回调方式，首先需要实现这个接口，该接口提供了三个方法：\n onAppResponse：当客户端接收到服务端的正常返回的时候，SOFARPC 会回调这个方法。 onAppException：当客户端接收到服务端的异常响应的时候，SOFARPC 会回调这个方法。 onSofaException：当 SOFARPC 本身出现一些错误，比如路由错误的时候，SOFARPC 会回调这个方法。 设置回调接口 实现回调接口之后，用户需要将实现类设置到对应的服务引用配置中，并且将调用方式设置为 callback。\nSOFARPC 为设置回调接口提供了两种方式，分别为 Callback Class 和 Callback Ref。Callback Class 的方式直接设置回调的类名，SOFARPC 会通过调用回调类的默认构造函数的方式生成回调类的实例。Callback Ref 的方式则为用户直接提供回调类的实例。\nXML 方式 如果通过 XML 的方式引用服务，将 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 type 属性设置为 callback，并且设置 callback-ref 或者 callback-class 属性即可：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleCallback\u0026amp;quot; class=\u0026amp;quot;com.example.demo.SampleCallback\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;callback\u0026amp;quot; callback-ref=\u0026amp;quot;sampleCallback\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 在 XML 的方式下，callback-ref 的值需要是回调类的 Bean 名称。\nAnnotation 方式 如果通过 Annotation 的方式引用服务，设置 @SofaReferenceBinding 注解的 invokeType 属性为 callback，并且设置 callbackClass 或者 callbackRef 属性即可：\n@SofaReference(binding = …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-type/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e296d9344b6aa9f550e6213b97da084b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/invoke-type/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/invoke-type/","summary":"调用方式 SOFARPC 在 Bolt 协议下提供了多种调用方式满足不同的场景。 同步 在同步的调用方式下，客户端发起调用后会等待服务端返回结果再进行后续的操作。这是 SOFARPC 的","tags":null,"title":"Bolt 协议调用方式","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/invoke-type/","wordcount":1619},{"author":null,"categories":null,"content":" 超时控制 使用 Bolt 协议进行通信的时候，SOFARPC 的超时时间默认为 3 秒，用户可以在引用服务的时候去设置超时时间，又分别可以在服务以及方法的维度设置超时时间，SOFARPC 的超时时间的设置的单位都为毫秒。\n服务维度 如果需要在发布服务的时候在服务维度设置超时时间，设置对应的 timeout 参数到对应的值即可。\nXML 方式 如果使用 XML 的方式引用服务，设置 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签下的 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 timeout 属性的值即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 如果使用 Annotation 引用服务，设置 @SofaReferenceBinding 的 timeout 属性的值即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, timeout = 2000)) private SampleService sampleService; Spring 环境 API 方式 如果在 Spring 或者 Spring Boot 的环境下引用服务，设置 BoltBindingParam 的 timeout 属性的值即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setTimeout(2000) 非 Spring 环境下 API 方式 如果在非 Spring 环境下直接使用 SOFARPC 的裸 API 引用服务，设置 ConsumerConfig 的 timeout 属性即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setTimeout(2000); 方法维度 如果想要单独调整一个服务中某一个方法的超时时间，可以通过在方法维度上设置超时时间来实现。\n对于某一个方法来说，优先方法维度的超时时间，如果没有设置，则使用服务维度的超时时间。\nXML 方式 如果使用 XML 的方式引用一个服务，设置对应的 \u0026amp;lt;sofa:method\u0026amp;gt; 标签的 timeout 属性即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 目前暂未提供通过 Annotation 的方式来设置方法级别的超时时间。\nSpring 环境 API 方式 如果在 Spring 或者 Spring Boot 的环境下引用服务，设置 RpcBindingMethodInfo 的 timeout 属性的值即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); RpcBindingMethodInfo rpcBindingMethodInfo = new RpcBindingMethodInfo(); rpcBindingMethodInfo.setName(\u0026amp;quot;hello\u0026amp;quot;); rpcBindingMethodInfo.setTimeout(2000); List\u0026amp;lt;RpcBindingMethodInfo\u0026amp;gt; rpcBindingMethodInfos = new ArrayList\u0026amp;lt;\u0026amp;gt;(); rpcBindingMethodInfos.add(rpcBindingMethodInfo); boltBindingParam.setMethodInfos(rpcBindingMethodInfos); 非 Spring 环境 API 方式 如果在非 Spring 环境下使用 SOFARPC 的裸 API 引用服务，设置 MethodConfig 的 timeout 属性即可：\nMethodConfig methodConfig = new MethodConfig(); methodConfig.setName(\u0026amp;quot;hello\u0026amp;quot;); methodConfig.setTimeout(2000); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfig); ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setMethods(methodConfigs); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-timeout/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cf14f73dc0c4672a9255ef55b56de419","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt-timeout/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt-timeout/","summary":"超时控制 使用 Bolt 协议进行通信的时候，SOFARPC 的超时时间默认为 3 秒，用户可以在引用服务的时候去设置超时时间，又分别可以在服务以及方法的维度","tags":null,"title":"Bolt 协议超时控制","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt-timeout/","wordcount":584},{"author":null,"categories":null,"content":" As one of the developing directions of cloud native technology, Serverless architecture enables you to further improve resource utilization and focus on service development. With our workshop, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, and quick troubleshooting via log viewer.\nWorkshop procedure Flow diagram Preview Preparation Access to Serverless application service address Login with account and password Git clone this project to local Step 1-1: Publish backend Java application Select Create quickly Select Java Runtime Upload the code package balance-mng.jar The entry method can be automatically recognized Port: 8080 Copy and save the backend service address after creation View the number of computing instances of backend service: 0 Step 1-2: Publish frontend NodeJS application Select create an application Select the buildpack NodeJS Upload the code package stock-mng.zip The entry method can be automatically recognized Select nodejs-0.0.1.1-pre at runtime Port: 3000 Set the environment variable BALANCEMNG_URL as the backend service address Step 2: 0-1 cold boot capability Access frontend service View the changes in the number of the computing instances of backend service Step 3: Log and monitoring View application service logs via Log Shell View usage amount via monitoring Step 4: Configure time trigger Configure timing trigger to call application at fixed time View the triggering results via operation records Step 5: Create versions and control traffic Clone the frontend application and create a new version Upload the code package stock-mng-v2.zip Configure router to visit V1 and V2 at 1:1 ratio View the effect in the browser Step 6: Quick M-n capability for high-concurrency Simulate high concurrency situtation via scripts and access the frontend application service Check how the Serverless application perform quick M-N computing instance changes ","date":-62135596800,"description":"With this guide, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, quick troubleshooting via log viewer, and application startup at fixed time.","dir":"guides/kc-serverless-demo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f355d1b598fed47b730bd74ad25f3683","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-serverless-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/guides/kc-serverless-demo/","summary":"As one of the developing directions of cloud native technology, Serverless architecture enables you to further improve resource utilization and focus on service development. With our workshop, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, and quick troubleshooting via log viewer.\nWorkshop procedure Flow diagram Preview Preparation Access to Serverless application service address Login with account and password Git clone this project to local Step 1-1: Publish backend Java application Select Create quickly Select Java Runtime Upload the code package balance-mng.","tags":null,"title":"Build applications on the cloud based on Serverless","type":"guides","url":"/sofastack.tech/en/guides/kc-serverless-demo/","wordcount":290},{"author":null,"categories":null,"content":" Procedure This guide introduces how to quickly build a microservice based on SOFAStack. It mainly includes the following steps.\n Publish service using SOFABoot and SOFARPC Call service using SOFABoot and SOFARPC View Tracer information reported by SOFATracer via ZipKin View Metrics information via SOFALookout Architecture Tasks 1. Preparation Clone the project demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git Import the project into IDEA or Eclipse. After import, the interface is as follows:\n balance-mng: account management system, providing deduction balance service stock-mng: account system, providing deduction inventory service 2. Introduce dependencies Add the following dependencies into the pom.xml files of balance-mng and stock-mng project modules.\n\u0026amp;lt;!--SOFARPC dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFATracer dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFARegistry dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--runtime dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFALookout dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; For balance-mng project, you need to introduce the dependencies into the pom file of balance-mng-imp module.\nFor stock-mng project, you need to introduce the dependencies into the pom file of stock-mng module.\n3. Add configurations Copy the following configurations into the application.properties file of balance-mng and stock-mng project module.\n# 1、Add Service Registry address com.alipay.sofa.rpc.registry.address=sofa://118.31.43.62:9603 # 2、Add the zipkin address where tracer data is reported com.alipay.sofa.tracer.zipkin.base-url=http://139.224.123.199:9411 # 3、Add the server-side address where the metrics data is reported com.alipay.sofa.lookout.agent-host-address=139.224.123.35 For balance-mng project, you need to add configurations to the application.properties file in balance-mng-bootstrap module.\nFor stock-mng project, you need to add configurations to the application.properties file in stock-mng module.\n4. Modify unique id Since everyone shares a set of service discoveries, to differentiate the services published by different users, it is required to add a unique id to the service.\nKubeCon workshop will prepare a SOFAStack account for each user in the format ofuser0@sofastack.io to user99@sofastack.io. The first half of the account, namely …","date":-62135596800,"description":"This guide introduces how to quickly build a microservice based on SOFAStack. ","dir":"guides/sofastack-quick-start/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"78bfd4806a86dc15ac86eee16fb85c82","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/sofastack-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/guides/sofastack-quick-start/","summary":"Procedure This guide introduces how to quickly build a microservice based on SOFAStack. It mainly includes the following steps.\n Publish service using SOFABoot and SOFARPC Call service using SOFABoot and SOFARPC View Tracer information reported by SOFATracer via ZipKin View Metrics information via SOFALookout Architecture Tasks 1. Preparation Clone the project demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git Import the project into IDEA or Eclipse. After import, the interface is as follows:","tags":null,"title":"Build microservices with SOFAStack","type":"guides","url":"/sofastack.tech/en/guides/sofastack-quick-start/","wordcount":586},{"author":null,"categories":null,"content":" SOFARPC provides a variety of calling types under the Bolt protocol to meet different scenarios.\nSynchronous In the synchronous calling type, after the client initiates a call, it will wait for the server to return the result and then perform subsequent operations. This is the default calling type of SOFARPC.\nAsynchronous In the asynchronous calling type, after the client initiates a call, it will not wait for the result from the server but continue to execute the subsequent business logic. The result returned by the server will be cached by SOFARPC. When the client needs the result, it can call the API to get the result. To set a service to be asynchronous, you can configure the type attribute in the corresponding usage mode:\nXML In the XML mode, set the type attribute of the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag to future:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation In Annotation mode, set the invokeType attribute of @SofaReferenceBinding to future:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, invokeType = \u0026amp;quot;future\u0026amp;quot;)) private SampleService sampleService; API in Spring environment When using the API in Spring environment, you just need to set the type attribute of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setType(\u0026amp;quot;future\u0026amp;quot;); API in non-Spring environment When using the bare API of SOFARPC in a non-Spring environment, you just need to set the invokeType attribute of ConsumerConfig:\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setInvokeType(\u0026amp;quot;future\u0026amp;quot;); Get the calling result Currently, there are two ways to get the result of an asynchronous call:\nGet result directly You can directly get the result of an asynchronous call in the following way:\nString result = (String)SofaResponseFuture.getResponse(0, true); The first parameter is the timeout period for getting the result, and the second parameter indicates whether to clear the result in the thread context.\nGet JDK native Future You can get the JDK native Future object in the following way, and then call the Future object from anywhere to get the result:\nFuture future = SofaResponseFuture.getFuture(true); The first parameter indicates whether to clear the result in the thread context.\nCallback By using the callback type of the SOFARPC Bolt protocol, SOFARPC doesn\u0026amp;rsquo;t need to wait for the result after initiating a call. After the client receives the result returned from the server, it can automatically call back a callback interface implemented by the user.\nTo use the callback type of the SOFARPC Bolt protocol, you first need to …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-type/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e296d9344b6aa9f550e6213b97da084b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/invoke-type/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/invoke-type/","summary":"SOFARPC provides a variety of calling types under the Bolt protocol to meet different scenarios.\nSynchronous In the synchronous calling type, after the client initiates a call, it will wait for the server to return the result and then perform subsequent operations. This is the default calling type of SOFARPC.\nAsynchronous In the asynchronous calling type, after the client initiates a call, it will not wait for the result from the server but continue to execute the subsequent business logic.","tags":null,"title":"Calling type","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/invoke-type/","wordcount":908},{"author":null,"categories":null,"content":" Client built-in extension metrics The extension modules currently in effect by default are lookout-ext-jvm and lookout-ext-os (from v1.5.0).\nJVM thread metric name metric tags specification jvm.threads.totalStarted \u0026amp;mdash; jvm.threads.active \u0026amp;mdash; jvm.threads.peak \u0026amp;mdash; jvm.threads.daemon \u0026amp;mdash; JVM class loading metric name metric tags specification jvm.classes.unloaded \u0026amp;mdash; jvm.classes.loaded \u0026amp;mdash; jvm.classes.total \u0026amp;mdash; JVM memory metric name metric tags specification jvm.memory.heap.init \u0026amp;mdash; jvm.memory.heap.used \u0026amp;mdash; jvm.memory.heap.max \u0026amp;mdash; jvm.memory.heap.committed \u0026amp;mdash; JVM garbage recycling metric name metric tags specification jvm.gc.young.time \u0026amp;mdash; jvm.gc.young.count \u0026amp;mdash; jvm.gc.old.time \u0026amp;mdash; jvm.gc.old.count \u0026amp;mdash; Machine file system information metric name metric tags specification instance.file.system.free.space root（the available filesystem roots） \u0026amp;mdash; instance.file.system.total.space root \u0026amp;mdash; instance.file.system.usabe.space root \u0026amp;mdash; Machine information metric name metric tags specification instance.mem.free \u0026amp;mdash; instance.mem.total \u0026amp;mdash; instance.processors \u0026amp;mdash; instance.uptime \u0026amp;mdash; instance.systemload.average \u0026amp;mdash; Linux operating system information (enabled by default after version 1.5.0) metric name metric tags specification os.systemload.average.1min \u0026amp;mdash; os.systemload.average.5min \u0026amp;mdash; os.systemload.average.15min \u0026amp;mdash; os.cpu.idle \u0026amp;mdash; os.cpu.iowait \u0026amp;mdash; os.cpu.irq \u0026amp;mdash; os.cpu.nice \u0026amp;mdash; os.cpu.softirq \u0026amp;mdash; os.cpu.system \u0026amp;mdash; os.cpu.user \u0026amp;mdash; os.disk.usage.percent.used device,root,type \u0026amp;mdash; os.disk.usage.total.bytes device,root,type \u0026amp;mdash; os.disk.usage.used.bytes device,root,type \u0026amp;mdash; os.net.stats.in.bytes intfc \u0026amp;mdash; os.net.stats.in.compressed intfc \u0026amp;mdash; os.net.stats.in.dropped intfc \u0026amp;mdash; os.net.stats.in.errs intfc \u0026amp;mdash; os.net.stats.in.fifo.errs intfc \u0026amp;mdash; os.net.stats.in.frame.errs intfc \u0026amp;mdash; os.net.stats.in.multicast intfc \u0026amp;mdash; os.net.stats.in.packets intfc \u0026amp;mdash; os.net.stats.out.bytes intfc \u0026amp;mdash; os.net.stats.out.carrier.errs intfc \u0026amp;mdash; os.net.stats.out.collisions intfc \u0026amp;mdash; os.net.stats.out.compressed intfc \u0026amp;mdash; os.net.stats.out.dropped intfc \u0026amp;mdash; os.net.stats.out.errs intfc \u0026amp;mdash; os.net.stats.out.fifo.errs intfc \u0026amp;mdash; os.net.stats.out.packets intfc \u0026amp;mdash; os.memory.stats.buffers.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.cached.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.free.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.total.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-ext-metrics/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c8a4fb3d904e359e99db9d4e81e60812","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","summary":"Client built-in extension metrics The extension modules currently in effect by default are lookout-ext-jvm and lookout-ext-os (from v1.5.0).\nJVM thread metric name metric tags specification jvm.threads.totalStarted \u0026mdash; jvm.threads.active \u0026mdash; jvm.threads.peak \u0026mdash; jvm.threads.daemon \u0026mdash; JVM class loading metric name metric tags specification jvm.classes.unloaded \u0026mdash; jvm.","tags":null,"title":"Client built-in extension metrics","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","wordcount":224},{"author":null,"categories":null,"content":"The client module is a complex module which contains cluster, router, address holder，connection holder, and load balancer, and interacts with proxy, registry center and other modules.\nSee the following flow chart:\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/client-invoke-flow/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"310d99d64b808a3b526563e92c699952","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","summary":"The client module is a complex module which contains cluster, router, address holder，connection holder, and load balancer, and interacts with proxy, registry center and other modules.\nSee the following flow chart:","tags":null,"title":"Client call flow","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","wordcount":31},{"author":null,"categories":null,"content":" Client configuration example lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026amp;quot;127.0.0.1\u0026amp;quot;); Description of server configuration item Configuration item Corresponding SpringBoot configuration item Default value Description lookout.enable com.alipay.sofa.lookout.enable true Function switch, it defaults to true. If you change it to false (empty objects and empty methods), then all metrics comsume almost no memory and computing resource lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 Maximum number limit of metrics, over which will be automatically ignored lookout.prometheus.exporter.server.port com.alipay.sofa.lookout.prometheus-exporter-server-port 9494 The port got by Prometheus Lookout.exporter.enable com.alipay.sofa.lookout.exporter-enable false Whether or not to enable services that support passive collection Lookout.agent.host.address com.alipay.sofa.lookout.agent-host-address - Proactively report the annotation address of the Agent server. Multiple addresses are separated by commas Description of client log configuration Configuration item of system property Corresponding SpringBoot configuration item Default Value Description -Dlogging.level.com.alipay.lookout=? logging.level.com.alipay.lookout warn The log level of Lookout client. Debug to see the details of the report data -Dlogging.path=? logging.path Directory of the current user Modify SpringBoot V1 log directory, including \u0026amp;ldquo;lookout/\u0026amp;rdquo; log subdirectory Custom client configuration (suitable for SpringBoot technology stack mode) Use configuration custom extensions: MetricConfigCustomizerConfig\n@Configuration public class MetricConfigCustomizerConfig { @Bean public MetricConfigCustomizer metricConfigCustomizer() { return new MetricConfigCustomizer() { @Override public void customize(MetricConfig metricConfig) { metricConfig.addProperty(\u0026amp;quot;testaa\u0026amp;quot;, \u0026amp;quot;testbb\u0026amp;quot;); } }; } } ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-configuration/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5fd84950d4d565d3fb20781337792bf1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/client-configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/client-configuration/","summary":"Client configuration example lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026quot;127.0.0.1\u0026quot;); Description of server configuration item Configuration item Corresponding SpringBoot configuration item Default value Description lookout.enable com.alipay.sofa.lookout.enable true Function switch, it defaults to true. If you change it to false (empty objects and empty methods), then all metrics comsume almost no memory and computing resource lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 Maximum number limit of metrics, over which will be automatically ignored lookout.","tags":null,"title":"Client configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/client-configuration/","wordcount":192},{"author":null,"categories":null,"content":" 1. Create a Maven project After deploying the servers, we can create a new Maven project to use services provided by SOFARegistry. Create a new Maven project, and then import the following dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. Publish data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create a publisher registry. String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // Register the registry with the client and publish data. registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); Perform the following steps to publish data by using SOFARegistry:\n Create a client instance. Create a publisher registry. Register the registry with the client and publish data. 2.1 Create a client instance The key to creating a client instance is to create a RegistryClientConfig object. When creating a RegistryClientConfig object, you need to specify the RegistryEndpoint and RegistryEndpointPort.\n RegistryEndpoint: the endpoint of any session node of SOFARegistry RegistryEndpointPort: the session.server.httpServerPort port number configured for a session node 2.2 Create a publisher registry To create a publisher registry, you only need to create a PublisherRegistration object and specify the dataId, which is the unique identifier of the publisher service.\n2.3 Publish data You can call the register method of the RegistryClient to publish data. This method requires two parameters: the first is a publisher registry with the specified dataId of a service, and the second is a string type data value.\n3. Subscribe to the data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create SubscriberDataObserver. SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // Create a subscriber registry and specify the subscription level. ScopeEnum covers three subscription levels: zone, dataCenter, and global. String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setScopeEnum(ScopeEnum.global); // Register the registry with …","date":-62135596800,"description":"","dir":"projects/sofa-registry/client-quick-start/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"66e300d44b2f2a903d976bf83eb7c16e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/client-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/client-quick-start/","summary":"1. Create a Maven project After deploying the servers, we can create a new Maven project to use services provided by SOFARegistry. Create a new Maven project, and then import the following dependency:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. Publish data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create a publisher registry. String dataId = \u0026quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // Register the registry with the client and publish data.","tags":null,"title":"Client usage","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/client-quick-start/","wordcount":558},{"author":null,"categories":null,"content":" Project address\n Introduction During merged deployment, Biz packages can communicate with each other by releasing and referencing JVM services apart from using the RPC framework. This sample project is intended to demonstrate how two Biz packages communicate by JVM services.\nWithin the biz-jvm-invocation-sample project, there are three sub-projects whose functions are as follows: + facade: A common Java module that defines the SampleJvmService interface.\npackage me.qlong.tech.service; public interface SampleJvmService { String service(); } app-one: A SOFABoot Web application that defines a simple rest request and use the @SofaReference annotation to reference the SampleJvmService. When a page request is triggered, an attempt is made to call the JVM service. The key code is: package me.qlong.controller; import com.alipay.sofa.runtime.api.annotation.SofaReference; import me.qlong.tech.service.SampleJvmService; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class HelloController { @SofaReference private SampleJvmService sampleJvmService; @RequestMapping(\u0026amp;quot;/hello\u0026amp;quot;) public String hello() { return sampleJvmService.service(); } } app-two: A non-web application in SOFABoot that uses the @SofaService annotation to publish the SampleJvmService. ```java package me.qlong.tech.service.impl; import com.alipay.sofa.runtime.api.annotation.SofaService; import me.qlong.tech.service.SampleJvmService; import org.springframework.stereotype.Component;\n@SofaService @Component public class AppTwoSampleService implements SampleJvmService{ public String service() { return \u0026amp;ldquo;App Two\u0026amp;rdquo;; } }\n ## Dependency To communicate between Biz packages through JVM services, you must add dependencies on the SOFARuntime package and the corresponding Ark Plugin as follows: ```xml \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; For detailed information about publishing and referencing JVM services, see the SOFABoot Documentation. You are advised to use annotations in Jarslink2.0.\nDemo cd biz-jvm-invocation-sample/facade \u0026amp;amp;\u0026amp;amp; mvn clean install Execute the mvn clean install command in the facade root directory, and install the facade package in the local Maven repository so that you can add a facade dependency in app-one and app-two: \u0026amp;lt;!--service facade--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;me.qlong.tech\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;facade\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; cd biz-jvm-invocation-sample/app-one \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-one root directory and …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"59778c5223dc6267bd537be6c79b658a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","summary":"Project address\n Introduction During merged deployment, Biz packages can communicate with each other by releasing and referencing JVM services apart from using the RPC framework. This sample project is intended to demonstrate how two Biz packages communicate by JVM services.\nWithin the biz-jvm-invocation-sample project, there are three sub-projects whose functions are as follows: + facade: A common Java module that defines the SampleJvmService interface.\npackage me.qlong.tech.service; public interface SampleJvmService { String service(); } app-one: A SOFABoot Web application that defines a simple rest request and use the @SofaReference annotation to reference the SampleJvmService.","tags":null,"title":"Communicate across applications","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","wordcount":527},{"author":null,"categories":null,"content":"SOFARPC supports different communication protocols and currently supports Bolt, RESTful and Dubbo. For details, please refer to the corresponding document of each protocol: * Bolt Protocol * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool * RESTful * Basic usage * Custom filter * Integrate Swagger * Dubbo * Basic usage * H2C * Basic usage\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/protocol/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"18f51cb12f7a0384a71ab22349292a08","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/protocol/","summary":"SOFARPC supports different communication protocols and currently supports Bolt, RESTful and Dubbo. For details, please refer to the corresponding document of each protocol: * Bolt Protocol * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool * RESTful * Basic usage * Custom filter * Integrate Swagger * Dubbo * Basic usage * H2C * Basic usage","tags":null,"title":"Communication protocols","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/protocol/","wordcount":66},{"author":null,"categories":null,"content":" How to compile Install JDK7 and above, and Maven 3.2.5 and above.\n Directly download the code and then execute the following command:\ncd sofa-jarslink mvn clean install Note: you cannot compile the code under a sub-directory (i.e., sub-module). Since there are many modules, the configuration is restricted to the root directory only to avoid repetitive configuration of some packaging plugins such as the formatting plugin and License plugin. There will be an error message if you execute the packaging command in a sub-module.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-compile/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"23c8cae6050d7a772f45d3ff2b4ce889","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","summary":"How to compile Install JDK7 and above, and Maven 3.2.5 and above.\n Directly download the code and then execute the following command:\ncd sofa-jarslink mvn clean install Note: you cannot compile the code under a sub-directory (i.e., sub-module). Since there are many modules, the configuration is restricted to the root directory only to avoid repetitive configuration of some packaging plugins such as the formatting plugin and License plugin.","tags":null,"title":"Compile Jarslink project","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","wordcount":83},{"author":null,"categories":null,"content":" Install JDK7 or later and Maven 3.2.5 or later.\n Download the codes directly and execute the following commands:\ncd sofa-rpc mvn clean install Note: You can not build under a subdirectory (namely the submodule). Because there are too many SOFARPC modules, if every submodule needs to be installed and deployed, there will be much useless records in the repository. This issue is considered in the process of designing the SOFARPC project structure. The current structure saves you the trouble of installing and deploying all submodules, and you just have to install and deploy one module, namely the sofa-rpc-all (all) module.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/how-to-build/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"52ad3debb35be8743c97bb4b6b77f22b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/how-to-build/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/how-to-build/","summary":"Install JDK7 or later and Maven 3.2.5 or later.\n Download the codes directly and execute the following commands:\ncd sofa-rpc mvn clean install Note: You can not build under a subdirectory (namely the submodule). Because there are too many SOFARPC modules, if every submodule needs to be installed and deployed, there will be much useless records in the repository. This issue is considered in the process of designing the SOFARPC project structure.","tags":null,"title":"Compile SOFARPC project","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/how-to-build/","wordcount":100},{"author":null,"categories":null,"content":"Provide all the parameters that can be configured. * Service publishing and reference configuration * Warm-up forwarding configuration * Fault tolerance configuration\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b1a8a8c426beab292165716f1dff1ae4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration/","summary":"Provide all the parameters that can be configured. * Service publishing and reference configuration * Warm-up forwarding configuration * Fault tolerance configuration","tags":null,"title":"Configuration parameters","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration/","wordcount":22},{"author":null,"categories":null,"content":"To use Consul as service registry center, you need to add this dependency\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.ecwid.consul\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;consul-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; and need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 The value after consul: is the connection address of the consul. If you need to set some other parameters, you can also configure as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;amp;b=2 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-consul/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e6b0aa843ea0ad401c3184f6ce87649b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-consul/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-consul/","summary":"To use Consul as service registry center, you need to add this dependency\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.ecwid.consul\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;consul-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.4.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; and need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 The value after consul: is the connection address of the consul. If you need to set some other parameters, you can also configure as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;b=2 ","tags":null,"title":"Consul","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-consul/","wordcount":54},{"author":null,"categories":null,"content":" You can visit Development Route first to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n Refer to the Git official books for the Git tool usage. The first few chapters will help you get a quick start. Read Git collaboration process through GitHub Code Contribution Process Submitting an issue Whether you want to fix a bug of SOFAArk or add a new feature of SOFAArk, you have to submit an issue to describe your demand before you submit the code on GitHub address in SOFAArk. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The maintenance personnel of SOFAArk will discuss about the bug or new function you submitted, to determine if the modification is necessary, or if there is any room for improvement or any better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Getting the source code To modify or add a function, click the fork button in the upper left corner to copy a SOFAArk trunk code to your code repository, after submitting an issue.\nPulling a branch Perform all the SOFAArk modifications on the branch, and submit a pull request after the modifications, which will be merged to the trunk by the project maintenance personnel after Code Review.\nTherefore, after getting the introduction to source code steps, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/{your account}/sofa-ark.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\ngit branch -a If you want to switch back to the trunk, execute the following command:\ngit checkout -b master If you want to switch back to the branch, execute the following command:\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally. After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFAArk uses the Maven plug-in to keep the code style consistent. Before submitting the code, execute the following commands locally: mvn clean compile Supplement unit test code. New modifications should have passed existing unit tests. You should provide the new unit test to prove that the previous code has bugs and the new code has fixed such bugs. Execute the following command to run all tests:\nmvn clean test Other do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original style of the code you are editing, especially the spaces and line feeds in the code. Delete useless annotations. Annotate the places where the logic and functionality …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-contribution/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dbf77f98884a71c5c7a3fbb4dd189cfe","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","summary":"You can visit Development Route first to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n Refer to the Git official books for the Git tool usage. The first few chapters will help you get a quick start. Read Git collaboration process through GitHub Code Contribution Process Submitting an issue Whether you want to fix a bug of SOFAArk or add a new feature of SOFAArk, you have to submit an issue to describe your demand before you submit the code on GitHub address in SOFAArk.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","wordcount":795},{"author":null,"categories":null,"content":" You can go into the development route to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n For the use of git tools, refer to official books on git and get familiarized by reading the first few chapters. For the git collaboration process, refer to the article named Git Collaboration Process. GitHub Code Contribution Process Submitting an issue No Matter whether you are fixing a Jarslink bug or adding a Jarslink feature, submit an issue on the Jarslink GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The Jarslink maintenance personnel will discuss the bug or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Getting the source code To modify or add a feature, click the fork button in the upper left corner to copy Jarslink trunk code to your code repository, after submitting an issue.\nPulling a branch Perform all the Jarslink modifications on the branch, and submit a pull request after the modifications, which will be merged into the trunk by the project maintenance personnel after the code review.\nTherefore, after getting the introduction to source code steps, you need to:\n Download the code locally. You may select the git/https mode in this step.\ngit clone https://github.com/your account name/sofa-jarslink.git Pull a branch to prepare for code modification.\ngit branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\n git branch -a If you want to switch back to the trunk, execute the following command:\n git checkout -b master If you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally. After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. Jarslink uses the Maven plugin to keep the code style consistent. Before submitting the code, be sure to execute the following commands locally\nmvn clean compile Supplement unit test code. New modifications should have passed existing unit tests. You should provide the new unit test to prove that the previous code has bugs and the new code has fixed such bugs. Execute the following command to run all tests:\n mvn clean test You can also use the IDE to help execute a command.\nOther do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-contribution/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d4c1185c6a691679f6dc9dba033550ce","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","summary":"You can go into the development route to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n For the use of git tools, refer to official books on git and get familiarized by reading the first few chapters. For the git collaboration process, refer to the article named Git Collaboration Process.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","wordcount":827},{"author":null,"categories":null,"content":" Before you read this document, you are suggested to read the SOFARPC development roadmap to learn about development tasks and future plans.\n Preparations Before you contribute code, you need to learn the basic use of Git tool and GitHub website.\n For how to use the Git tool, see Git official documenation and pay attention to the first few chapters. For Git collaboration process, see Git collaboration process. GitHub code contribution process Submit an issue No matter to fix SOFARPC bugs or add SOFARPC features, before submitting the codes, you must submit an issue on SOFARPC\u0026amp;rsquo;s GitHub to describe the bugs to be fixed and the functions you want to add.\nThere are several benefits of doing this:\n Avoid the conflict with other developers or their plans for this project, thus eliminating repetitive work. SOFARPC operations staff discuss your bugs or new features to determine if the changes are necessary and whether there is space for improvement or a better approach. Reduce communication cost between you and the SOFARPC operations staff, thus reducing the cases that pull request is rejected. Get source codes To modify or add features, after you submit the issue, you can click Fork in the upper left corner to copy the SOFARPC trunk code to your code repository.\nPull branches All SOFARPC modifications are made on the branch. After modification, submit the pull request. After the code review, the project operations staff merge the branches to the trunk.\nTherefore, you must complete the following steps after getting the source codes:\n Download the codes locally through Git or HTTPs.\n git clone https://github.com/your account name/sofa-rpc.git Pull branches for code modifications.\n \t git branch add_xxx_feature \nAfter executing the above command, your code repository switches to the corresponding branch. Execute the following command to see your current branch:\n\t git branch -a \nIf you want to switch back to the trunk, execute the following command:\n git checkout -b master \nIf you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; \nModify and submit codes locally Once the branch is pulled, you can modify the code.\nAttentions for modifying codes Keep a consistent code style.\nSOFARPC keeps the code format consistent through the Maven plugin. You must execute the following command locally before committing the code: mvn clean compile Supplemental unit test code. New modifications should have passed the existing unit tests. Provide new unit tests to prove that the previous code has bugs, and the new code has fixed these bugs.\nYou can run all tests with the following command:\nmvn clean test You can also use IDE to assist the test running.\n Other attentions Keep the original code style, especially the spacing and alignment. Delete the useless comments directly. Add comments for the logics and functions that cannot be easily understood. Update documentation timely. After modification, …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/contributing/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"448a7b9a949bd2d9e2e71ac6c237f9df","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/contributing/","summary":"Before you read this document, you are suggested to read the SOFARPC development roadmap to learn about development tasks and future plans.\n Preparations Before you contribute code, you need to learn the basic use of Git tool and GitHub website.\n For how to use the Git tool, see Git official documenation and pay attention to the first few chapters. For Git collaboration process, see Git collaboration process.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/contributing/","wordcount":751},{"author":null,"categories":null,"content":"SOFARPC uses some third-party open-source components which include but not limited to:\n Major dependencies\n Netty under Apache License 2.0 SLF4j under MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 Extended dependencies\n protobuf under New BSD License Snappy under New BSD License dubbo under Apache License 2.0 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b6c87388d5c1462f13d92012639a08b2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/notice/","summary":"SOFARPC uses some third-party open-source components which include but not limited to:\n Major dependencies\n Netty under Apache License 2.0 SLF4j under MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 Extended dependencies\n protobuf under New BSD License Snappy under New BSD License dubbo under Apache License 2.0 ","tags":null,"title":"Copyright","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/notice/","wordcount":62},{"author":null,"categories":null,"content":" Copyright statement of dependent components SOFADashboard uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFABolt under Apache License 2.0 SOFABolt under Apache License 2.0 Curator under Apache License 2.0 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a9ebe38d245302f94ab7bfa793329926","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/notice/","summary":" Copyright statement of dependent components SOFADashboard uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFABolt under Apache License 2.0 SOFABolt under Apache License 2.0 Curator under Apache License 2.0 ","tags":null,"title":"Copyright statement","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/notice/","wordcount":47},{"author":null,"categories":null,"content":" Copyright statement of dependent components SOFARegistry uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1\n SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 If you find anything we have missed, please let us know.\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c40263ffd56a2f1292756c9fafea55e2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/notice/","summary":"Copyright statement of dependent components SOFARegistry uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1\n SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 If you find anything we have missed, please let us know.","tags":null,"title":"Copyright statement","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/notice/","wordcount":68},{"author":null,"categories":null,"content":" 本文档主要介绍一个基于 jraft 的分布式计数器的例子。\n场景 在多个节点（机器）组成的一个 raft group 中保存一个分布式计数器，该计数器可以递增和获取，并且在所有节点之间保持一致，任何少数节点的挂掉都不会影响对外提供的两个服务：\n incrmentAndGet(delta) 递增 delta 数值并返回递增后的值。 get() 获取最新的值 RPC 请求 jraft 底层使用 bolt 作为通讯框架，定义两个请求\n IncrementAndGetRequest，用于递增 public class IncrementAndGetRequest implements Serializable { private static final long serialVersionUID = -5623664785560971849L; private long delta; public long getDelta() { return this.delta; } public void setDelta(long delta) { this.delta = delta; } } GetValueRequest，用于获取最新值： public class GetValueRequest implements Serializable { private static final long serialVersionUID = 9218253805003988802L; public GetValueRequest() { super(); } } 应答结果 ValueResponse，包括：\n success　是否成功 value 成功情况下返回的最新值 errorMsg 失败情况下的错误信息 redirect　发生了重新选举，需要跳转的新的leader节点。 public class ValueResponse implements Serializable { private static final long serialVersionUID = -4220017686727146773L; private long value; private boolean success; /** * redirect peer id */ private String redirect; private String errorMsg; public String getErrorMsg() { return this.errorMsg; } public void setErrorMsg(String errorMsg) { this.errorMsg = errorMsg; } ...... } IncrementAndGetRequest 用于 Leader 服务端接收 IncrementAndAddClosure 请求后的回调处理： public class IncrementAndAddClosure implements Closure { private CounterServer counterServer; private IncrementAndGetRequest request; private ValueResponse response; private Closure done; // 网络应答callback public IncrementAndAddClosure(CounterServer counterServer, IncrementAndGetRequest request, ValueResponse response, Closure done) { super(); this.counterServer = counterServer; this.request = request; this.response = response; this.done = done; } @Override public void run(Status status) { // 返回应答给客户端 if (this.done != null) { done.run(status); } } public IncrementAndGetRequest getRequest() { return this.request; } public void setRequest(IncrementAndGetRequest request) { this.request = request; } public ValueResponse getResponse() { return this.response; } } 服务端 状态机 CounterStateMachine 首先持有一个初始值：\npublic class CounterStateMachine extends StateMachineAdapter { /** * counter value */ private AtomicLong value = new AtomicLong(0); 实现核心的 onApply(iterator) 方法，应用用户提交的请求到状态机：\n@Override public void onApply(Iterator iter) { // 遍历日志 while (iter.hasNext()) { long delta = 0; IncrementAndAddClosure closure = null; // done 回调不为null，必须在应用日志后调用，如果不为 null，说明当前是leader。 if (iter.done() != null) { // 当前是leader，可以直接从 IncrementAndAddClosure 中获取 delta，避免反序列化 closure = (IncrementAndAddClosure) iter.done(); delta = closure.getRequest().getDelta(); } else { // 其他节点应用此日志，需要反序列化 IncrementAndGetRequest，获取 delta ByteBuffer data = iter.getData(); try { IncrementAndGetRequest request = Codecs.getSerializer(Codecs.Hessian2).decode(data.array(), IncrementAndGetRequest.class.getName()); delta = request.getDelta(); } catch (CodecException e) { LOG.error(\u0026amp;quot;Fail to decode IncrementAndGetRequest\u0026amp;quot;, e); } } long prev = this.value.get(); // 更新状态机 long …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/counter-example/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f9c54b9f7883ccb1d7c259b7101f4674","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/counter-example/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-jraft/counter-example/","summary":"本文档主要介绍一个基于 jraft 的分布式计数器的例子。 场景 在多个节点（机器）组成的一个 raft group 中保存一个分布式计数器，该计数器可以递增和获取，并且在所有","tags":null,"title":"Counter 例子详解","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/counter-example/","wordcount":2404},{"author":null,"categories":null,"content":" Project address\n Introduction Jarslink 2.0 is available for both Spring Boot and SOFABoot; we just need to add the specified dependencies. To be convenient, it is recommended to use Jarslink 2.0 in the form of SOFABoot projects. This sample project is intended to demonstrate how to quickly reform a Spring Boot project into a SOFABoot project.\nReform After creating a Spring Boot project in the official Spring Boot website, we only need to introduce the SOFABoot dependencies. First, modify the configuration file pom.xml of the Maven project.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace as\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.5.0-SNAPSHOT\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Note: Currently Jarslink 2.0.0 is still at its snapshot version, and the SOFABoot 2.5.0 that it depends on will be released in the near future, so for the moment, the SOFABoot 2.5.0-SNAPSHOT version has to be introduced as the dependency. The pull of the SNAPSHOT package requires special configuration, for which you can refer to FAQ: How do I configure for pulling a SNAPSHOT dependency package?\nThen, add a Spring Boot or SOFABoot official Starter, such as:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;!-- Jarslink2.0 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-jarslink-ark-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0-SNAPSHOT\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- Web --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; To package the application into an Ark package or Biz package, we need to configure the sofa-Ark-maven-plugin packaging plugin in the main pom.xml file, and delete the native packaging plugin the Spring Boot configuration.\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Finally, add a parameter that SOFABoot must use under the application.properties file for the project, including spring.application.name (used to mark the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"46cb9153d039f01a375a569c2a9a5535","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","summary":"Project address\n Introduction Jarslink 2.0 is available for both Spring Boot and SOFABoot; we just need to add the specified dependencies. To be convenient, it is recommended to use Jarslink 2.0 in the form of SOFABoot projects. This sample project is intended to demonstrate how to quickly reform a Spring Boot project into a SOFABoot project.\nReform After creating a Spring Boot project in the official Spring Boot website, we only need to introduce the SOFABoot dependencies.","tags":null,"title":"Create a SOFABoot application","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","wordcount":419},{"author":null,"categories":null,"content":" SOFARPC provides a good extensibility mechanism, which provide SPI capabilities for each module. SOFARPC uses multiple filters to intercept requests and responses. These filters can be customized and extended by users. The execution order of custom filters is after the built-in filters. The procedure is as follows:\nBolt filter 1 Create a new custom filter.\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 2 The custom filter will be added into the interceptor chain. There are three specific ways to do this step.\n Method 1: In API. In this way, the custom filter can take effect in the specified provider or consumer. // Service provider providerConfig.setFilterRef(Arrays.asList(new CustomFilter())); // Service caller consumerConfig.setFilterRef(Arrays.asList(new CustomFilter())); Method 2: Add @Extension annotation + configuration extension file to the class. @Extension(\u0026amp;quot;customer\u0026amp;quot;) public class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } Create a new extension file META-INF/services/sofa-rpc/com.alipay.sofa.rpc.filter.Filter with the following content:\ncustomer=com.alipay.sofa.rpc.custom.CustomFilter Code injection.\n// Service provider providerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); // Service caller consumerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); Method 3: Add @Extension annotation + @AutoActive annotation + configuration extension file to the class. In this way, the code injection step in method 2 is replaced with the @AutoActive annotation. The custom filter can take effect in all providers or consumers. The providerSide parameter indicates whether it takes effect on the server, and the consumerSide parameter indicates whether it takes effect on the client. @Extension(\u0026amp;quot;customer\u0026amp;quot;) @AutoActive(providerSide = true, consumerSide = true) public class customerFilter extends Filter { // ... } ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-filter/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"30ff5937b52a7c2dd8028e878979a33d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-filter/","summary":"SOFARPC provides a good extensibility mechanism, which provide SPI capabilities for each module. SOFARPC uses multiple filters to intercept requests and responses. These filters can be customized and extended by users. The execution order of custom filters is after the built-in filters. The procedure is as follows:\nBolt filter 1 Create a new custom filter.\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.","tags":null,"title":"Custom filter","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-filter/","wordcount":285},{"author":null,"categories":null,"content":"The route service address in SOFARPC is abstracted into a processing chain, and is processed by each router. Like filter, SOFARPC provides the same extensibility for router.\n@Extension(value = \u0026amp;quot;customerRouter\u0026amp;quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026amp;lt;ProviderInfo\u0026amp;gt; route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) { return providerInfos; } Create a extension file META-INF/services/sofa-rpc/com.alipay.sofa.rpc.client.Router with the following content:\ncustomerRouter=com.alipay.sofa.rpc.custom.CustomRouter This file customized a CustomerRouter, which takes effect in all consumers. The parameter ConsumerBootstrap in init method is a wrapper class of the referenced service, and can get objects such as ConsumerConfig, proxy class, and service address pool. needToLoad indicates whether the Router is valid, and the route method is the method for filtering addresses.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-router/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"236e8d4bda3e856267a3575853aa900c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-router/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-router/","summary":"The route service address in SOFARPC is abstracted into a processing chain, and is processed by each router. Like filter, SOFARPC provides the same extensibility for router.\n@Extension(value = \u0026quot;customerRouter\u0026quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026lt;ProviderInfo\u0026gt; route(SofaRequest request, List\u0026lt;ProviderInfo\u0026gt; providerInfos) { return providerInfos; } Create a extension file META-INF/services/sofa-rpc/com.","tags":null,"title":"Custom router","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-router/","wordcount":131},{"author":null,"categories":null,"content":" SOFARPC supports custom business thread pools. A separate business thread pool can be set up for the specified service, isolated from SOFARPC\u0026amp;rsquo;s global business thread pool. Multiple services can share a single thread pool.\nSOFARPC requires that the type of custom thread pool must be com.alipay.sofa.rpc.server.UserThreadPool.\nUse XML If you publish the service using XML, you can first set the bean of the thread pool whose class is com.alipay.sofa.rpc.server.UserThreadPool, and then set the bean in the thread-pool-ref attribute of \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag.\n\u0026amp;lt;bean id=\u0026amp;quot;helloService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Customize a thread pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;customExecutor\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.server.UserThreadPool\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;corePoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;maximumPoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;queueSize\u0026amp;quot; value=\u0026amp;quot;0\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloService\u0026amp;quot; interface=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;!-- Set the thread pool to a Service --\u0026amp;gt; \u0026amp;lt;sofa:global-attrs thread-pool-ref=\u0026amp;quot;customExecutor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Use Annotation If you publish the service using Annotation, you can set the bean of the custom thread pool by setting the userThreadPool attribute of @SofaServiceBinding:\n@SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, userThreadPool = \u0026amp;quot;customThreadPool\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Use API in Spring environment If you publish a service using the API in Spring environment, you can configure a custom thread pool by calling the setUserThreadPool method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setUserThreadPool(new UserThreadPool()); Use API in non-Spring environment If you publish service using the API in non-Spring environment, you can set a custom thread pool as follows:\nUserThreadPool threadPool = new UserThreadPool(); threadPool.setCorePoolSize(10); threadPool.setMaximumPoolSize(100); threadPool.setKeepAliveTime(200); threadPool.setPrestartAllCoreThreads(false); threadPool.setAllowCoreThreadTimeOut(false); threadPool.setQueueSize(200); UserThreadPoolManager.registerUserThread(ConfigUniqueNameGenerator.getUniqueName(providerConfig), threadPool); As above, a custom thread pool is set up for the HelloService service.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-thread-pool/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4d582a7894b2381248522f3a1fc400c9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","summary":"SOFARPC supports custom business thread pools. A separate business thread pool can be set up for the specified service, isolated from SOFARPC\u0026rsquo;s global business thread pool. Multiple services can share a single thread pool.\nSOFARPC requires that the type of custom thread pool must be com.alipay.sofa.rpc.server.UserThreadPool.\nUse XML If you publish the service using XML, you can first set the bean of the thread pool whose class is com.alipay.sofa.rpc.server.UserThreadPool, and then set the bean in the thread-pool-ref attribute of \u0026lt;sofa:global-attrs\u0026gt; tag.","tags":null,"title":"Custom thread pool","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","wordcount":252},{"author":null,"categories":null,"content":" You can view basic information of your application on SOFADashboard, including the IP address, ports, and health check status. This feature is dependent on the SOFADashboard client. If you want to display the information about an application on the SOFADashboard control page, import the sofa-dashboard-client dependency.\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-dashboard-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; Function display ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/dashboard-client/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"60586c6dfee1f2afcdac88cbe7a36b83","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","summary":" You can view basic information of your application on SOFADashboard, including the IP address, ports, and health check status. This feature is dependent on the SOFADashboard client. If you want to display the information about an application on the SOFADashboard control page, import the sofa-dashboard-client dependency.\n\u0026lt;denpendency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofa-dashboard-client\u0026lt;/artifactId\u0026gt; \u0026lt;/denpendency\u0026gt; Function display ","tags":null,"title":"Dashboard client","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","wordcount":52},{"author":null,"categories":null,"content":" In this document will demonstrate how to use SOFATracer to track of Datasource.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce SOFATracer Introduce SOFATracer dependency in the new Spring Boot project:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.2.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce h2database dependencies For convenience, we use the h2database memory database for test. So, we need to introduce the following dependencies:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.h2database\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;h2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;runtime\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;mysql\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mysql-connector-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce the required connection pool dependencies Introduce the required connection pool dependency packages, such as druid, c3p0, tomcat, dbcp, Hikari, and so on.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;druid\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;c3p0\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;c3p0\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.9.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.tomcat\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tomcat-jdbc\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;8.5.31\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-dbcp\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-dbcp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.zaxxer\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;HikariCP-java6\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.8\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configure data source Taking HikariCP as the example, we create a new Spring configuration file named datasource.xml, which defines the followings:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- dataSource pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;simpleDataSource\u0026amp;quot; class=\u0026amp;quot;com.zaxxer.hikari.HikariDataSource\u0026amp;quot; destroy-method=\u0026amp;quot;close\u0026amp;quot; primary=\u0026amp;quot;true\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;driverClassName\u0026amp;quot; value=\u0026amp;quot;org.h2.Driver\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;jdbcUrl\u0026amp;quot; value=\u0026amp;quot;jdbc:h2:~/test\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;username\u0026amp;quot; value=\u0026amp;quot;sofa\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;password\u0026amp;quot; value=\u0026amp;quot;123456\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; Application configuration Required configuration It should be noted that it is …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-datasource/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d9d8f6756a294104647067eaa7827f61","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","summary":"In this document will demonstrate how to use SOFATracer to track of Datasource.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce SOFATracer Introduce SOFATracer dependency in the new Spring Boot project:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.2.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Introduce h2database dependencies For convenience, we use the h2database memory database for test. So, we need to introduce the following dependencies:","tags":null,"title":"DataSource Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","wordcount":642},{"author":null,"categories":null,"content":" Datasource Log Format SOFATracer tracks the standard JDBC data source and outputs the chain data of SQL statement execution, in the default JSON format.\nDataSource digest log (datasource-client-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Database.name Database name Sql SQL execution statement Result.code SQL execution status code Total.time SQL statement execution total time Connection.establish.span SQL execution connection establishment time Db.execute.cost SQL execution time Database.type Database type Database.endpoint Database url Current.thread.name Current thread name Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-28 01:11:56.715\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e1bcab91538068316462100111113\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1.2\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;success\u0026amp;quot;,\u0026amp;quot;total.time\u0026amp;quot;:\u0026amp;quot;228ms\u0026amp;quot;,\u0026amp;quot;connection.establish.span\u0026amp;quot;:\u0026amp;quot;220ms\u0026amp;quot;,\u0026amp;quot;db.execute.cost\u0026amp;quot;:\u0026amp;quot;3ms\u0026amp;quot;,\u0026amp;quot;database.type\u0026amp;quot;:\u0026amp;quot;h2\u0026amp;quot;,\u0026amp;quot;database.endpoint\u0026amp;quot;:\u0026amp;quot;jdbc:h2:~/test:-1\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} DataSource statistical Log (datasource-client-stat.log) stat.key is the set of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, database.name, and SQL field.\n Key Meaning time Log printing time stat.key local.app Current application name database.name Database name sql SQL execution statement count SQL execution count in this period total.cost.milliseconds Total duration (ms) for SQL execution in this period success Request result: Y for success; N for failure load.test Pressure mark: T for pressure test; F for non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-28 01:12:43.647\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;, \u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:228,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-datasource/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"647de768aff8ececc8276d247c5afee1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","summary":"Datasource Log Format SOFATracer tracks the standard JDBC data source and outputs the chain data of SQL statement execution, in the default JSON format.\nDataSource digest log (datasource-client-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Database.","tags":null,"title":"DataSource log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","wordcount":202},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 DataSource 进行埋点。\n SOFATracer 2.2.0 基于标准的 JDBC 接口实现，支持对标准的数据库连接池（如 DBCP、Druid、c3p0、tomcat、HikariCP、BoneCP）埋点。下面演示如何接入 SOFATracer 埋点能力。\n 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 引入 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入 h2database 依赖 为了方便，我们使用 h2database 内存数据库测试，引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.h2database\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;h2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;runtime\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;mysql\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mysql-connector-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入所需的连接池依赖 用户引入所需的连接池依赖包，如 druid, c3p0, tomcat, dbcp, Hikari 等。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;druid\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;c3p0\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;c3p0\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.9.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.tomcat\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tomcat-jdbc\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;8.5.31\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-dbcp\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-dbcp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.zaxxer\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;HikariCP-java6\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.8\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置数据源 我们以 HikariCP 为例，新建一个名为datasource.xml Spring 配置文件，定义如下内容:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- dataSource pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;simpleDataSource\u0026amp;quot; class=\u0026amp;quot;com.zaxxer.hikari.HikariDataSource\u0026amp;quot; destroy-method=\u0026amp;quot;close\u0026amp;quot; primary=\u0026amp;quot;true\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;driverClassName\u0026amp;quot; value=\u0026amp;quot;org.h2.Driver\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;jdbcUrl\u0026amp;quot; value=\u0026amp;quot;jdbc:h2:~/test\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;username\u0026amp;quot; value=\u0026amp;quot;sofa\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;password\u0026amp;quot; value=\u0026amp;quot;123456\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 应用配置 必要配置 需要注意一点，引入 SOFATracer 需要强制配置应用名，否则应用启动失败。这一属性和 SOFABoot 框架要求一致，配置如下：\nspring.application.name=SOFATracerDataSource 非必要配置 为了该演示工程正常运行，需要配置 h2database 属性；另为了方便查看日志，配置日志路径。如下：\n# logging path logging.path=./logs # h2 web consloe 路径 spring.h2.console.path=/h2-console # 开启 h2 web consloe，默认为 false spring.h2.console.enabled=true #允许远程访问 h2 web consloe spring.h2.console.settings.web-allow-others=true spring.datasource.username=sofa …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-datasource/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d9d8f6756a294104647067eaa7827f61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","summary":"在本文档将演示如何使用 SOFATracer 对 DataSource 进行埋点。 SOFATracer 2.2.0 基于标准的 JDBC 接口实现，支持对标准的数据库连接池（如 DBCP、Druid、c3p0、tomcat、H","tags":null,"title":"DataSource 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","wordcount":1014},{"author":null,"categories":null,"content":" SOFATracer 对标准的 JDBC 数据源进行埋点，输出 SQL 语句执行链路数据，默认日志输出为 JSON 数据格式。\nDataSource 摘要日志（datasource-client-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 database.name 数据库名称 sql sql执行语句 connection.establish.span sql执行建连时间 db.execute.cost sql执行时间 database.type 数据库类型 database.endpoint 数据库url sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 21:31:31.566\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe91d156743109138810017302\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;15ms\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;DROP TABLE IF EXISTS TEST; CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;,\u0026amp;quot;connection.establish.span\u0026amp;quot;:\u0026amp;quot;128ms\u0026amp;quot;,\u0026amp;quot;db.execute.cost\u0026amp;quot;:\u0026amp;quot;15ms\u0026amp;quot;,\u0026amp;quot;database.type\u0026amp;quot;:\u0026amp;quot;h2\u0026amp;quot;,\u0026amp;quot;database.endpoint\u0026amp;quot;:\u0026amp;quot;jdbc:h2:~/test:-1\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} DataSource 统计日志（datasource-client-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、database.name、和 sql 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 database.name 数据库名称 sql sql执行语句 count 本段时间内sql执行次数 total.cost.milliseconds 本段时间内sql执行总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 21:31:50.435\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;DROP TABLE IF EXISTS TEST; CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:15,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-datasource/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"647de768aff8ececc8276d247c5afee1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-datasource/","summary":"SOFATracer 对标准的 JDBC 数据源进行埋点，输出 SQL 语句执行链路数据，默认日志输出为 JSON 数据格式。 DataSource 摘要日志（datasource-client-digest.","tags":null,"title":"DataSource 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-datasource/","wordcount":427},{"author":null,"categories":null,"content":" SOFABoot is based on Spring Boot. It means SOFABoot manages SOFA middleware dependencies and provides the Starter for Spring Boot, facilitating the use of SOFA middleware in Spring Boot.\nSOFABoot dependency management You must load SOFABoot\u0026amp;rsquo;s management dependencies before using SOFA middleware. In a way similar to use Spring Boot, add the configuration tag \u0026amp;lt;parent/\u0026amp;gt; in the project settings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Where ${sofa.boot.version} represents the SOFABoot version (refer to release history).\nUse Middleware of SOFAStack For SOFABoot, use -sofa-boot-starter suffixes to name middleware components. If you want to use middleware, simply add its dependencies; To use SOFARPC, for example, simply add the following Maven dependencies:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note that there is no version declaration in the above Maven dependencies as the version has already been declared in sofabook-dependencies. This allows for unified upgrade of all SOFA middleware versions, allaying concerns over dependency conflicts or incompatibility brought by upgrade of a single middleware version. The SOFABoot middleware under control is listed as follows:\n Middleware starter SOFARPC rpc-sofa-boot-starter SOFATracer tracer-sofa-boot-starter SOFALookout lookout-sofa-boot-starter Introducing SOFABoot Extension Based on Spring Boot, SOFABoot provides extended capabilities such as health check, module isolation, and class isolation. In accordance with Spring Boot\u0026amp;rsquo;s the dependency-as-a-service principle, the extension capability will be ready immediately after relevant dependencies are added. Currently, there are several extension modules available:\n Extension components starter Health check healthcheck-sofa-boot-starter Module isolation Isle-Sofa-boot-starter Class isolation sofa-Ark-springboot-starter Test extension test-Sofa-boot-starter Introducing the SOFA middleware: the Ark plug-in SOFABoot provides a class isolation component—SOFAArk, which enables users to package third-party packages with dependency conflicts into an Ark plug-in. At run time, the Ark plug-in is loaded with a separate classloader; it is isolated from other Ark plug-ins and business dependencies to address class conflicts. SOFABoot provides SOFARPC and SOFATracer\u0026amp;rsquo;s Ark plug-ins; the Ark plug-in SOFARPC, for example, is loaded into the application to replace SOFARPC starter, to isolate the application from SOFARPC and its indirect dependencies. The controlled Ark plug-ins are listed as follows:\n Ark plug-in plugin SOFARPC rpc-sofa-boot-plugin SOFATracer tracer-sofa-boot-plugin Introducing SOFABoot namespace Before using SOFA middleware, we need to add …","date":-62135596800,"description":"","dir":"projects/sofa-boot/dependency-management/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dabdbd425f20dee4d7ab580d43574456","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/dependency-management/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/dependency-management/","summary":"SOFABoot is based on Spring Boot. It means SOFABoot manages SOFA middleware dependencies and provides the Starter for Spring Boot, facilitating the use of SOFA middleware in Spring Boot.\nSOFABoot dependency management You must load SOFABoot\u0026rsquo;s management dependencies before using SOFA middleware. In a way similar to use Spring Boot, add the configuration tag \u0026lt;parent/\u0026gt; in the project settings:\n\u0026lt;parent\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofaboot-dependencies\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${sofa.boot.version}\u0026lt;/version\u0026gt; \u0026lt;/parent\u0026gt; Where ${sofa.boot.version} represents the SOFABoot version (refer to release history).","tags":null,"title":"Dependency management","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/dependency-management/","wordcount":391},{"author":null,"categories":null,"content":" 1. Environment preparation To use SOFARegistry, you need to prepare the basic environment first. SOFARegistry depends on the following environment:\n Linux, UNIX, Mac are supported. JDK8 Compile it with Apache Maven 3.2.5 or later versions. 2. Resource Quota -cpu: 4c -memory: 8G -disk: 50G\n3. Two deployment modes Integrated deployment Package and integrate the three roles of meta, data, and session into one jvm, which can be deployed on a standalone machine or a cluster. The deployment is simple. Independent deployment Deploy the meta, data, and session roles separately. You can deploy each of them on a standalone machine or a cluster. You can deploy different numbers of servers for each role as needed. We recommend that you use this deployment mode in the production environment. 4. Configuration parameters The deployment of SOFARegistry depends on some public parameters\n properties environment Default value Function nodes.localDataCenter x DefaultDataCenter Cluster name, multiple registry centers use the same database nodes.localRegion x DEFAULT_ZONE Logical region, create multiple groups of sessions jdbc.url JDBC_URL Required Database address jdbc.username JDBC_USERNAME required database user name jdbc.password JDBC_PASSWORD Required Database password Properties can be written in registry-all/conf/application.properties, deployment under kubernetes can also use configmap for file mounting\n5. Packaging jar release page Download the latest registry-all.tgz package\ntar -zxvf registry-all.tgz cd registry-all Or package from source\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all image image hosted at https://hub.docker.com/r/sofaregistry/sofaregistry\nOr build from source code: Modify the image repository in Makefile\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true make image_build make image_push 6. Integrated deployment mode The integrated deployment mode is to package and integrate the three roles of meta/data/session into a JVM to run. It can be deployed on a single machine or in a cluster. It is not recommended for large-scale use\n6.1 jar stand-alone deployment For the stand-alone deployment mode of integrated deployment, you can directly refer to the Quick Start-Server Deployment section.\n6.2 jar cluster deployment Unzip registry-all.tgz and modify the configuration file Cluster deployment, that is, to build a cluster of 2 or more, it is recommended to use at least 3 (note: currently does not support the deployment of multiple SOFARegistry on the same machine, so you must have 3 different machines). The deployment method on each machine is the same as above:\ncp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar …","date":-62135596800,"description":"","dir":"projects/sofa-registry/deployment/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7e28583bc38be66af8d704d7fbcd9dd4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/deployment/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/deployment/","summary":"1. Environment preparation To use SOFARegistry, you need to prepare the basic environment first. SOFARegistry depends on the following environment:\n Linux, UNIX, Mac are supported. JDK8 Compile it with Apache Maven 3.2.5 or later versions. 2. Resource Quota -cpu: 4c -memory: 8G -disk: 50G\n3. Two deployment modes Integrated deployment Package and integrate the three roles of meta, data, and session into one jvm, which can be deployed on a standalone machine or a cluster.","tags":null,"title":"Deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/deployment/","wordcount":1040},{"author":null,"categories":null,"content":" 1. How to compile Install JDK7 or later versions, and Maven 3.2.5 or later versions. Directly download the code, and execute the following command in the code directory:\n mvn clean install 2. Version release Version number ACTS uses a three-digit version number in the form of major, minor, and patch, for example, 1.0.1.\nFor more information, see https://semver.org/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Patch number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application is. Version maintenance At most two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 1.3.0, the BugFix branch of version 1.2.x will be maintained, but bugs in branch 1.1.x will no longer be fixed. Therefore, a version upgrade for 1.1.x is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 1.3.0-SNAPSHOT. Upon formal release, SNAPSHOT is replaced with a formal version number, for example 1.3.0. After the formal release, the next version is pulled, for example, 1.3.1-SNAPSHOT. 3. Testing Unit test Add the unit test case to the model that you have developed. The package name of the test class is identical to that of the tested class.\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/developer-guide/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fcacc7e89b979f3aec8dc3333a7a3c37","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/developer-guide/","summary":"1. How to compile Install JDK7 or later versions, and Maven 3.2.5 or later versions. Directly download the code, and execute the following command in the code directory:\n mvn clean install 2. Version release Version number ACTS uses a three-digit version number in the form of major, minor, and patch, for example, 1.0.1.\nFor more information, see https://semver.org/.\n Major version number: All versions within a major version number must be compatible with each other.","tags":null,"title":"Developer guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/developer-guide/","wordcount":249},{"author":null,"categories":null,"content":" Develope guide of code contribution First refer to the basic Notes for code contribution Note the test case coverage; Note the code format; Verify samples Import the sample Maven project separately; Modify the dependency version in the corresponding Pom file; Verify that samples can work correctly as well. ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/development-use-guide/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"423a54ec3f5fbfc9c0e150eb853738ae","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","summary":" Develope guide of code contribution First refer to the basic Notes for code contribution Note the test case coverage; Note the code format; Verify samples Import the sample Maven project separately; Modify the dependency version in the corresponding Pom file; Verify that samples can work correctly as well. ","tags":null,"title":"Development guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","wordcount":48},{"author":null,"categories":null,"content":"SOFARPC supports scenarios where a specified address is called.\nThe use of direct call in Java API is as follows, only set the direct connection address:\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); The use of direct call in XML is as follows:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sample.HelloService\u0026amp;quot; id=\u0026amp;quot;helloService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; The use of direct call in Annotation is as follows:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, directUrl = \u0026amp;quot;127.0.0.1:12220\u0026amp;quot;)) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/peer-to-peer/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b1815c322f5dc9528f6429d1d5e38369","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","summary":"SOFARPC supports scenarios where a specified address is called.\nThe use of direct call in Java API is as follows, only set the direct connection address:\nConsumerConfig\u0026lt;HelloService\u0026gt; consumer = new ConsumerConfig\u0026lt;HelloService\u0026gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026quot;bolt://127.0.0.1:12201\u0026quot;); The use of direct call in XML is as follows:\n\u0026lt;sofa:reference interface=\u0026quot;com.alipay.sample.HelloService\u0026quot; id=\u0026quot;helloService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:route target-url=\u0026quot;127.0.0.1:12200\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:reference\u0026gt; The use of direct call in Annotation is as follows:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026quot;bolt\u0026quot;, directUrl = \u0026quot;127.","tags":null,"title":"Direct call","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","wordcount":73},{"author":null,"categories":null,"content":" Fault Recover Including Fault-Hystrix and Fault-Tolerance features.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e567dc5e291867e92c8dd1c4f953b768","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault/","summary":"Fault Recover Including Fault-Hystrix and Fault-Tolerance features.","tags":null,"title":"Disaster recovery","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault/","wordcount":7},{"author":null,"categories":null,"content":" Distributed consensus algorithm Understand distributed consensus Multiple participants reach a complete consensus on one thing: one conclusion for one thing. The conclusion cannot be overthrown. Typical distributed consensus algorithms Paxos: It is considered as the foundation of distributed consensus algorithms. Other algorithms are its variants. However, the Paxos paper only provides the process of a single proposal, without describing the details of multi-paxos that is required for state machine replication. Paxos implementation involves high engineering complexity, for example, multiple-point writes and log hole tolerance. Zab: It is applied in ZooKeeper and widely used in the industry. However, it is not available as a universal library. Raft: It is known for being easy to understand. There are many renowned Raft implementations in the industry, such as etcd, Braft, and TiKV. Introduction to Raft Raft is in nature a Paxos-based distributed consensus algorithm that is much easier to understand than Paxos. Unlike Paxos, Raft divides the protocols into independent modules, and uses a streamlined design, making the Raft protocol easier to implement.\nSpecifically, Raft divides consensus protocols into almost completely decoupled modules, such as leader election, membership change, log replication, and snapshot.\nRaft adopts a more streamlined design by preventing reordering commits, simplifying roles (it has only three roles: leader, follower, and candidate), allowing only the leader to write, and using randomized timeout values to design leader election.\nFeature: strong leader The system can have only one leader at the same time, and only the leader can accept requests sent by clients. The leader is responsible for communication with all followers, sending proposals to all followers, and receiving responses from the majority of followers. The leader also needs to send heartbeats to all followers to maintain its leadership. To summarize, a strong leader tells its followers: \u0026amp;ldquo;Do not say anything. Do what I said and let me know when you finish!\u0026amp;rdquo; In addition, a leader must always remain active by sending heartbeats to followers. Otherwise, a follower will take its place.\nReplicated state machine Assume we have an infinitely incrementing sequence (system) a[1, 2, 3…]. If for any integer i, the value of a[i] meets the distributed consensus requirement, the system meets the requirement of a consensus state machine. Basically, all real life systems are subject to continuous operations, and reaching consensus on a single value is definitely not enough. To make sure all replicas of a real life system are consistent, we usually convert the operations into entries of a write-ahead-log(WAL). Then, we make sure all replicas of the system reach a consensus on the WAL entries, so that each replica performs operations of the WAL entries in order. As a result, the replicas are in consistent states.\n A client sent a write (operation) request to …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/consistency-raft-jraft/","fuzzywordcount":4900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a0e98df1bec305cca7db6fc34fc97771","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":23,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","summary":"Distributed consensus algorithm Understand distributed consensus Multiple participants reach a complete consensus on one thing: one conclusion for one thing. The conclusion cannot be overthrown. Typical distributed consensus algorithms Paxos: It is considered as the foundation of distributed consensus algorithms. Other algorithms are its variants. However, the Paxos paper only provides the process of a single proposal, without describing the details of multi-paxos that is required for state machine replication.","tags":null,"title":"Distributed consensus - Raft and JRaft","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","wordcount":4871},{"author":null,"categories":null,"content":"SOFARPC provides support for the Dubbo protocol, making it convenient for you to interface with existing Dubbo service. * Basic usage\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"87d78ed0c2d06fe7e1dbf9cb9d6c1c9d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/dubbo/","summary":"SOFARPC provides support for the Dubbo protocol, making it convenient for you to interface with existing Dubbo service. * Basic usage","tags":null,"title":"Dubbo","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/dubbo/","wordcount":21},{"author":null,"categories":null,"content":" Dubbo Integration In this document will demonstrate how to use SOFATracer to track of Dubbo, this example address.\nPrepare Environment The versions of the framework components used in this case are as follows:\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 This case includes three submodules:\n tracer-sample-with-dubbo-consumer service provider tracer-sample-with-dubbo-provider service consumer tracer-sample-with-dubbo-facade service interface define New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026amp;rsquo;s dependency. First, you need to unzip the generated zip package of Spring Boot project and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more information about SOFABoot versions, refer to Release notes.\nNew tracer-sample-with-dubbo-facade Module provider a service interface\npublic interface HelloService { String SayHello(String name); } New tracer-sample-with-dubbo-provider Module provider SOFATracer dependency\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer versions are controlled by SOFABoot versions. If the SOFABoot versions used do not match, you need to manually specify a tracer version that is higher than 2.4.0.\n application.properties Configuration # Spring boot application spring.application.name=dubbo-provider # Base packages to scan Dubbo Component: @org.apache.dubbo.config.annotation.Service dubbo.scan.base-packages=com.alipay.sofa.tracer.examples.dubbo.impl ## Filter dubbo.provider.filter=dubboSofaTracerFilter # Dubbo Protocol dubbo.protocol.name=dubbo ## Dubbo Registry dubbo.registry.address=zookeeper://localhost:2181 logging.path=./logs Publish the Dubbo service using annotations\n@Service public class HelloServiceImpl implements HelloService { @Override public String SayHello(String name) { return \u0026amp;quot;Hello , \u0026amp;quot;+name; } } New tracer-sample-with-dubbo-consumer Module provider SOFATracer dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; application.properties Configuration\nspring.application.name=dubbo-consumer dubbo.registry.address=zookeeper://localhost:2181 dubbo.consumer.filter=dubboSofaTracerFilter logging.path=./logs Service reference @Reference(async = false) public HelloService …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-dubbo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"03f845606b454a7224333238aeecd9ab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","summary":"Dubbo Integration In this document will demonstrate how to use SOFATracer to track of Dubbo, this example address.\nPrepare Environment The versions of the framework components used in this case are as follows:\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 This case includes three submodules:\n tracer-sample-with-dubbo-consumer service provider tracer-sample-with-dubbo-provider service consumer tracer-sample-with-dubbo-facade service interface define New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026rsquo;s dependency.","tags":null,"title":"Dubbo Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","wordcount":297},{"author":null,"categories":null,"content":" Dubbo Log Format SOFATracer integrates Dubbo and outputs the requested link log data format. The default is JSON data format.\nDubbo service consumer digest log（dubbo-client-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app Current application name protocol protocol service service interface method service method invoke.type invoke type remote.host remote host remote.port remote port local.host local host client.serialize.time request serialize time client.deserialize.time response deserialize time req.size.bytes Request Body Size resp.size.bytes Response Body Size result.code result code current.thread.name Current thread name time.cost.milliseconds Request time (ms) baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-03 11:36:01.909\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8451554262561656100126684\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;dubbo-consumer\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;dubbo\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.dubbo.facade.HelloService\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;SayHello\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.232.69\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;20880\u0026amp;quot;,\u0026amp;quot;local.host\u0026amp;quot;:\u0026amp;quot;10.15.232.69\u0026amp;quot;,\u0026amp;quot;client.serialize.time\u0026amp;quot;:35,\u0026amp;quot;client.deserialize.time\u0026amp;quot;:0,\u0026amp;quot;req.size.bytes\u0026amp;quot;:323,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:323,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:252,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Dubbo service provider digest log（dubbo-server-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app current application name service service inteface method service method local.host local host local.host local port protocol protocol server.serialize.time response serialize time server.deserialize.time request deserialize time result.code result code current.thread.name current thread name time.cost.milliseconds Request time (ms) baggage Transparently transmitted baggage data Example\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-03 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-dubbo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"9bac8256ee1a74546b74799f9f1c0de9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","summary":"Dubbo Log Format SOFATracer integrates Dubbo and outputs the requested link log data format. The default is JSON data format.\nDubbo service consumer digest log（dubbo-client-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app Current application name protocol protocol service service interface method service method invoke.","tags":null,"title":"Dubbo log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","wordcount":275},{"author":null,"categories":null,"content":"SOFARPC 提供了 Dubbo 协议的支持，可以让用户非常方便地和现有的 Dubbo 的系统做对接。 * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"87d78ed0c2d06fe7e1dbf9cb9d6c1c9d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/dubbo/","summary":"SOFARPC 提供了 Dubbo 协议的支持，可以让用户非常方便地和现有的 Dubbo 的系统做对接。 * 基本使用","tags":null,"title":"Dubbo 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/dubbo/","wordcount":38},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 Dubbo 协议，只要将 Binding 设置为 Dubbo 即可。下面使用以注解的方式来例举，其他的使用方式可以参考 Bolt 协议基本使用，这里不再重复说明。：\n发布服务 发布一个 Dubbo 的服务，只需要将 @SofaServiceBinding 的 bindingType 设置为 dubbo 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 引用服务 引用一个 Dubbo 的服务，只需要将 @SofaReferenceBinding 的 bindingType 设置为 dubbo 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; 设置 Dubbo 服务的 Group 在 SOFARPC 的模型中，没有直接的一个字段叫做 Group，但是 SOFARPC 有一个 uniqueId 的模型，可以直接映射到 Dubbo 的模型中的 Group，比如下面的代码，就是发布了一个 Group 为 groupDemo 的服务：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}, uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;) public class SampleServiceImpl implements SampleService { } 如下的代码，就是引用了一个 Group 为 groupDemo 的服务：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;, jvmFirst = false) private SampleService sampleService; 注意，目前 Dubbo 协议只支持 Zookeeper 作为服务注册中心。\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo-usage/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1bf72c194a20a5dccea70423690191f4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/dubbo-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/dubbo-usage/","summary":"在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 Dubbo 协议，只要将 Binding 设置为 Dubbo 即可。下面使用以注解的方式来例举，其他的使用方式可以","tags":null,"title":"Dubbo 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/dubbo-usage/","wordcount":322},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 Dubbo 进行埋点，本示例工程地址。\n基础环境 本案例使用的各框架组件的版本如下：\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 本案例包括三个子模块：\n tracer-sample-with-dubbo-consumer 服务调用方 tracer-sample-with-dubbo-provider 服务提供方 tracer-sample-with-dubbo-facade 接口 原理 SOFATracer 对象 Dubbo 的埋点实现依赖于 Dubbo 的 SPI 机制来实现，Tracer 中基于 调用拦截扩展 自定义了 DubboSofaTracerFilter 用于实现对 Dubbo 的调用埋点。由于 DubboSofaTracerFilter 并没有成为 Dubbo 的官方扩展，因此在使用 SOFATracer 时需要安装 调用拦截扩展 中 所提供的方式进行引用，即：\n\u0026amp;lt;!-- 消费方调用过程拦截 --\u0026amp;gt; \u0026amp;lt;dubbo:reference filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;!-- 消费方调用过程缺省拦截器，将拦截所有reference --\u0026amp;gt; \u0026amp;lt;dubbo:consumer filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- 提供方调用过程拦截 --\u0026amp;gt; \u0026amp;lt;dubbo:service filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;!-- 提供方调用过程缺省拦截器，将拦截所有service --\u0026amp;gt; \u0026amp;lt;dubbo:provider filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;/\u0026amp;gt; 新建 SOFABoot 工程作为父工程 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 Maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n新建 tracer-sample-with-dubbo-facade 提供一个接口\npublic interface HelloService { String SayHello(String name); } 新建 tracer-sample-with-dubbo-provider 在工程模块的 pom 文件中添加 SOFATracer 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer 版本受 SOFABoot 版本管控，如果使用的 SOFABoot 版本不匹配，则需要手动指定 tracer 版本，且版本需高于 2.4.0.\n 在工程的 application.properties 文件下添加相关参数， # Spring boot application spring.application.name=dubbo-provider # Base packages to scan Dubbo Component: @org.apache.dubbo.config.annotation.Service dubbo.scan.base-packages=com.alipay.sofa.tracer.examples.dubbo.impl ## Filter 必须配置 dubbo.provider.filter=dubboSofaTracerFilter # Dubbo Protocol dubbo.protocol.name=dubbo ## Dubbo Registry dubbo.registry.address=zookeeper://localhost:2181 logging.path=./logs 使用注解方式发布 Dubbo 服务\n@Service public class HelloServiceImpl implements HelloService { @Override public String SayHello(String name) { return \u0026amp;quot;Hello , \u0026amp;quot;+name; } } 新建 tracer-sample-with-dubbo-consumer 在工程模块的 pom 文件中添加 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 在工程的 application.properties 文件下添加相关参数\nspring.application.name=dubbo-consumer dubbo.registry.address=zookeeper://localhost:2181 # Filter 必须配置 dubbo.consumer.filter=dubboSofaTracerFilter logging.path=./logs 服务引用 @Reference(async = false) public HelloService helloService; @Bean …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-dubbo/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"03f845606b454a7224333238aeecd9ab","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","summary":"在本文档将演示如何使用 SOFATracer 对 Dubbo 进行埋点，本示例工程地址。 基础环境 本案例使用的各框架组件的版本如下： SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 本案例包括三个子模块： tracer-sample-with-dubbo-consumer 服务调","tags":null,"title":"Dubbo 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","wordcount":760},{"author":null,"categories":null,"content":" SOFATracer 集成 Dubbo 后输出请求的链路数据格式，默认为 JSON 数据格式。\nDubbo 服务消费方摘要日志（dubbo-client-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 protocol 协议 service 服务接口 method 调用方法 invoke.type 调用类型 remote.host 目标主机 remote.port 目标端口 local.host 本地主机 client.serialize.time 请求序列化时间 client.deserialize.time 响应反序列化时间 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 error 错误信息 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:36:08.250\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;dubbo-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e27a79c156743856804410019644\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;205ms\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;dubbo\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.glmapper.bridge.boot.service.HelloService\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;SayHello\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;192.168.2.103\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;20880\u0026amp;quot;,\u0026amp;quot;local.host\u0026amp;quot;:\u0026amp;quot;192.168.2.103\u0026amp;quot;,\u0026amp;quot;client.serialize.time\u0026amp;quot;:35,\u0026amp;quot;client.deserialize.time\u0026amp;quot;:5,\u0026amp;quot;req.size.bytes\u0026amp;quot;:336,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:48,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Dubbo 服务提供方摘要日志（dubbo-server-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 protocol 协议 service 服务接口 method 调用方法 invoke.type 调用类型 local.host 本地主机 local.port 本地端口 server.serialize.time 响应序列化时间 server.deserialize.time 请求反序列化时间 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 error 错误信息 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-dubbo/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9bac8256ee1a74546b74799f9f1c0de9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","summary":"SOFATracer 集成 Dubbo 后输出请求的链路数据格式，默认为 JSON 数据格式。 Dubbo 服务消费方摘要日志（dubbo-client-digest.log） 以 JSON 格式输出的数据","tags":null,"title":"Dubbo 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","wordcount":550},{"author":null,"categories":null,"content":" The engine architecture is shown in the following diagram. Node A node in a Raft cluster connects and encapsulates all underlayer service modules, and main service interfaces that are visible to users. Specifically, the leader node of a raft group calls apply(task) to commit new tasks to the state machine replication cluster made up by the Raft group, which will then apply the task to the business state machine.\nStorage It stores Raft configuration changes and log entries converted from requests submitted by users, and replicates log entries from the leader\u0026amp;rsquo;s log to followers\u0026amp;rsquo; logs. LogStorage stores logs, while LogManager is responsible for calling the underlayer storage, caching and batch submitting storage calls, and conducting necessary checks and optimization. MetaStorage stores the metadata and records the internal states of the Raft implementation, for example, the current term of the node and the node to vote for. Optional. Snapshot storage is used to store users\u0026amp;rsquo; state-machine snapshots and meta information. SnapshotStorage stores snapshots, while SnapshotExecutor manages the actual storage, remote installation, and replication of snapshots. State machine StateMachine is an implementation of users\u0026amp;rsquo; core logic. It calls the onApply(Iterator) method to apply log entries that are submitted with Node#apply(task) to the business state machine. FSMCaller encapsulates state transition calls that are sent to the User StateMachine, writes log entries, implements a finite-state machine (FSM), conducts necessary checks, and merges requests for batch submission and concurrent processing. Replication Replicator is used by the leader to replicate log entries to followers. It does the same thing as an AppendEntries RPC of Raft. Without log entries, it is sent by the leader as heartbeats. ReplicatorGroup is used by a Raft group to manage all replicators, and to perform necessary permission checks and dispatches. RPC The RPC module is used for network communication between nodes.\n The RPC server is built in a node to receive requests from other nodes or clients, and to redirect such requests to the corresponding service modules. The RPC client is used to issue requests to other nodes, such as requests for votes, log replication requests, and heartbeats. ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/engine-architecture/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d2cc9de133aed20695229d0cde5b6ff9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","summary":"The engine architecture is shown in the following diagram. Node A node in a Raft cluster connects and encapsulates all underlayer service modules, and main service interfaces that are visible to users. Specifically, the leader node of a raft group calls apply(task) to commit new tasks to the state machine replication cluster made up by the Raft group, which will then apply the task to the business state machine.","tags":null,"title":"Engine architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","wordcount":347},{"author":null,"categories":null,"content":" ExtensionLoader To ensure that all steps of SOFARPC have sufficient scalability, SOFARPC defines a very flexible extension mechanism in which all extension implementations are equal.\nThis mechanism is very useful for both SOFARPC developers and users. SOFARPC abstracts itself into multiple modules which have no explicit dependencies on each other and interact via SPI.\nThis extension mechanism abstracts the interaction method of SPI. If you have read the documents about Filter and Router, you may have such experience.\nThe following sections introduce how to extend through the SPI interaction method.\nSOFARPC provides the capabilities of ExtensionLoader.\nDesign extension points SOFARPC defines an annotation @Extensible, which is on the interface or abstract class to identify that the class is an extension point. Namely, it informs SOFARPC that the class is extensible and SOFARPC needs to find the implementation of the extension point. In addition, the annotation defines the file name of the implementation class and whether the class is a singleton.\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * Specify the name of the custom extension file, which is the full class name by default * * @return Custom extension file name */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * Whether the extension class uses a singleton, yes by default * * @return Whether to use a singleton */ boolean singleton() default true; /** * Whether the extension class needs to be encoded, not by default * * @return Whether to encode */ boolean coded() default false; } SOFARPC also defines the @Extension annotation, which indicates an extension implementation class. It also defines the name that the extension point uses when looking for an extension implementation in the file.\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * Extension point name * * @return Extension point name */ String value(); /** * Extension point coding, not required by default; it is required when the interface needs to be encoded * * @return Extension point encoding * @see Extensible#coded() */ byte code() default -1; /** * Priority sorting, not required by default, the larger number, the higher priority * * @return Sort */ int order() default 0; /** * Whether to override other extensions with low {@link #order()} * * @return Whether to override other low-order extensions * @since 5.2.0 */ boolean override() default false; /** * Exclude other extensions, namely exclude other extensions with low {@link #order()} * * @return Excludes other extensions * @since 5.2.0 */ String[] rejection() default {}; } Add extension point Define extension points. @Extensible public interface Person { void getName(); } Define the extension implementation. @Extension(\u0026amp;quot;A\u0026amp;quot;) public class PersonA implements Person{ @Override public void getName() { System.out.println(\u0026amp;quot;li wei\u0026amp;quot;); } } …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/extension-loader/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"acc5628da3a7ea2df5eb68bd8ec17159","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/extension-loader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/extension-loader/","summary":"ExtensionLoader To ensure that all steps of SOFARPC have sufficient scalability, SOFARPC defines a very flexible extension mechanism in which all extension implementations are equal.\nThis mechanism is very useful for both SOFARPC developers and users. SOFARPC abstracts itself into multiple modules which have no explicit dependencies on each other and interact via SPI.\nThis extension mechanism abstracts the interaction method of SPI. If you have read the documents about Filter and Router, you may have such experience.","tags":null,"title":"Extension mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/extension-loader/","wordcount":603},{"author":null,"categories":null,"content":" Customize different engine stages You can rewrite APIs provided by ActsTestBase in the test script or in the base class.\n Rewrite the prepare, execute, check, and clear actions. For example, you can add some actions before or after super.prepare(). Rewrite the process method. You can add some actions before or after super.process() to reorchestrate the entire script. For example, you can add some personalized steps in the existing clear \u0026amp;gt; prepare \u0026amp;gt; execute \u0026amp;gt; check process. Rewrite beforeActsTest and afterActsTest to add some personalized actions before or after the running of each test case, such as preparing the context and refreshing the cache. Parameterization In response expectation and database expectation data, you can use $Variable name to define a value as a variable. You can set values of the variable in the test script. Supported scope: request parameters, responses, and database table fields. Supported types: Currently, only string parameterization is supported.\nUsage:\n(1) Add $ before a value to define it as a variable in the interface.\n(2) Assign values to the variables in the test script.\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { actsRuntimeContext.paramMap.put(\u0026amp;quot;roleId\u0026amp;quot;, \u0026amp;quot;123\u0026amp;quot;); actsRuntimeContext.refreshDataParam(); } When you write the database expectation, you can use the equal sign = to assign a value to the variable. This indicates that the value is a query result, and subsequent tables can use this variable as the value.\nAssume that the interface will insert data into two tables.\n id_A value_A 123 abc id_B value_B abc efg When you query these two tables, first query for value_A based on id_A in Table A that is returned by the interface. Then use value_A as a condition for the query in Table B. You can set the values as follows in the plug-in.\n Field Flag Value id_A C $param1 value_A Y =param2 Field Flag Value id_B C $param2 value_B Y efg Operation description:\n =param2 and $param2 indicate that the ACTS framework will first query for value_A in Table A, and then select from B where id_B = value_A to obtain the property value of id_B in Table B. $param1 indicates that you can assign a value to id_A in the code, for example: actsRuntimeContext.paramMap.put(\u0026amp;quot;param1\u0026amp;quot;,\u0026amp;quot;123\u0026amp;quot;); This snippet assigns the value 123 to the variable param1. You can write this snippet to beforeActsTest in the test script to make the ACTS framework query table A before assigning the value 123 to id_A.\nComponentization Currently, only string componentization is supported.\nIf a property is a dynamically generated string, for example, some IDs. You can use the at sign @ to call a component to generate this property. The component must be placed in the component package at the same level as the test module, namely: com.corpname.appname.acts.component (appname is the name of the system, and corpname is the name of the company, for …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-api/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ce7e264713a6f7a3f0672e2432489f59","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-api/","summary":"Customize different engine stages You can rewrite APIs provided by ActsTestBase in the test script or in the base class.\n Rewrite the prepare, execute, check, and clear actions. For example, you can add some actions before or after super.prepare(). Rewrite the process method. You can add some actions before or after super.process() to reorchestrate the entire script. For example, you can add some personalized steps in the existing clear \u0026gt; prepare \u0026gt; execute \u0026gt; check process.","tags":null,"title":"Extensions","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-api/","wordcount":1102},{"author":null,"categories":null,"content":" Q: What should I do if NoSuchMethodError is returned? Generally, this error is returned in the case of dependency conflicts. Commonly known dependency conflicts are listed as follows. Exclude the corresponding dependencies when you encounter relevant conflicts.\nLog conflict commons-logging conflict \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-logging\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; logback-classic conflict Rule out logback-classic by the location of the conflict. For example, application dependencies spring-boot-starter-logging and spring-test conflict with each other.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.3.4.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; snakeyaml conflict java.lang.NoSuchMethodError: org.yaml.snakeyaml.Yaml.\u0026amp;lt;init\u0026amp;gt;(Lorg/yaml/snakeyaml/constructor/BaseConstructor;)V org.yaml referenced in spring-boot-starter-test conflicts with org.yaml referenced in org.testing. In the following sample code, a conflict of org.yaml in spring-boot-starter-test is ruled out (it can also be ruled out at other conflict locations such as org.testing):\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.yaml\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;snakeyaml\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Q: What should I do if NoClassDefFoundError is returned? Generally, this error is returned in the case of missing dependencies or dependency conflicts.\nMockito returns a no class found error While using Mockito with SOFABoot, you do not have to import Mockito if the spring-boot-starter-test dependency already exists.\nQ: What should I do if \u0026amp;ldquo;No bean dataAccessConfigManager available\u0026amp;rdquo; is returned? This error is returned because the application starter class specified by the test script does not have the acts-core.xml file. You can add the acts-core.xml file according to the following figure.\nQ: What should I do if \u0026amp;ldquo;No runnable methods\u0026amp;rdquo; is returned? Generally, this error is caused when you run your Junit test with the ACTS test script. You can use the TestNG framework to run the ACTS test script.\nQ: What should I do in the case of a model …","date":-62135596800,"description":"","dir":"projects/sofa-acts/faq/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5f89d1f5695cbe6b669a8738741529bd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/faq/","summary":"Q: What should I do if NoSuchMethodError is returned? Generally, this error is returned in the case of dependency conflicts. Commonly known dependency conflicts are listed as follows. Exclude the corresponding dependencies when you encounter relevant conflicts.\nLog conflict commons-logging conflict \u0026lt;exclusion\u0026gt; \u0026lt;artifactId\u0026gt;commons-logging\u0026lt;/artifactId\u0026gt; \u0026lt;groupId\u0026gt;commons-logging\u0026lt;/groupId\u0026gt; \u0026lt;/exclusion\u0026gt; logback-classic conflict Rule out logback-classic by the location of the conflict. For example, application dependencies spring-boot-starter-logging and spring-test conflict with each other.\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.","tags":null,"title":"FAQ","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/faq/","wordcount":633},{"author":null,"categories":null,"content":" Common issues Q: Is SOFARPC the version used inside Ant Financial? Yes, SOFARPC has excellent extension interfaces, and the version for internal use just has some additional extension implementations based on the open source version. For example, the cloud-based commercial version integrates the Ant Financial Technology\u0026amp;rsquo;s shared registry center, Distributed System Tracing (DST) and other products. The version for internal use integrates Ant Financial\u0026amp;rsquo;s internal registry center, LDC router and other individual extensions.\nQ: Does SOFARPC use ZooKeeper as the registry center internally? Can it integrate other registry centers such as etcd? Ant Financial uses its self-developed registry products internally. SOFARPC\u0026amp;rsquo;s registry modules are extensible. All the registry modules use the same set of core interfaces for both internal and external use. Currently, the open-source version has integrated with ZooKeeper, and other registry implementation communities are being integrated.\nQ: What is the difference between SOFARPC and Dubbo? Dubbo, developed by Alibaba Group, is an excellent open-source RPC framework featuring high performance and good scalability. Dubbo is a comparatively mature open source framework, with a large number of users and rich open source ecology. Now, it has joined the Apache Foundation for incubation. Dubbo was first widely used in the Alibaba B2B department.\nOriginated from HSF in Alibaba Group, SOFARPC now has grown to an independent product. SOFARPC has carried out a lot of reconstruction and optimization on the aspects of protocol, network, routing, and scalability to meet the large-scale financial business scenarios of Ant Financial. In the Ant Financial\u0026amp;rsquo;s middleware (SOFAStack) ecosystem, SOFARPC is supported by a comprehensive microservices technology stack, including Microservices R\u0026amp;amp;D framework, RPC framework, service registry center, distributed scheduling task, throttling framework, Dynamic Configuration, DST, Metrics and others. By Dec. 11, 2017, SOFARPC has been used by thousands of systems in Ant Financial, and the production environment has released more than tens of thousands of interfaces.\nHowever, in the open source field, SOFARPC is still at the initial stage, and its open source ecosystem is still under construction. With the advancement of the open source plan, various related components will be available in the subsequent versions to improve the microservices stack. You are welcome to build SOFAStack together with us.\nIn terms of performance, the technical points of both products involved in protocols are similar. As for scalability, both products have good scalability. As for other functional differences, here are some features that have been opened source or will be open sourced in the near future for reference:\n SOFARPC supports HTTP/2 and GRPC protocols and provides such capabilities as service warm-up weight, automatic degradation upon fault, negotiation mechanism, and CRC data …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/faq/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a6ec77ce5a423c5345394f42c64a416b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/faq/","summary":"Common issues Q: Is SOFARPC the version used inside Ant Financial? Yes, SOFARPC has excellent extension interfaces, and the version for internal use just has some additional extension implementations based on the open source version. For example, the cloud-based commercial version integrates the Ant Financial Technology\u0026rsquo;s shared registry center, Distributed System Tracing (DST) and other products. The version for internal use integrates Ant Financial\u0026rsquo;s internal registry center, LDC router and other individual extensions.","tags":null,"title":"FAQ","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/faq/","wordcount":742},{"author":null,"categories":null,"content":"Usually, a service have multiple service providers in a cluster. Some of the service providers may have persistent connections still survived due to network, configuration, long-term fullgc, full thread pool, hardware failure and others, but the program cannot respond properly. The stand-alone fault tolerance function can degrade the exceptional service providers so that the client requests can be pointed to the healthy node. When the exceptional nodes become normal, the standalone fault tolerance function will restore the nodes, so that the client requests can gradually distribute traffic to the nodes. The standalone fault tolerance function solves the problem that service failures continue to affect the business, avoids the avalanche effect, reduces the long response time required for manual intervention and increases system availability.\nRunning mechanism:\n Standalone fault tolerance counts the number of calls and the number of exceptions in a time range, and calculates the abnormal rate of IP for each service and the average abnormal rate of the service. When the IP abnormal rate is greater than the service average abnormal rate to a certain ratio, the dimension of the service + ip is degraded. If the weight of the service + ip dimension is not degraded to 0, then when the call of the service + ip dimension is normal, the weight will be restored. The entire calculation and control process proceeds asynchronously, thus not blocking the call. The standalone fault tolerance is used as follows:\nFaultToleranceConfig faultToleranceConfig = new FaultToleranceConfig(); faultToleranceConfig.setRegulationEffective(true); faultToleranceConfig.setDegradeEffective(true); faultToleranceConfig.setTimeWindow(20); faultToleranceConfig.setWeightDegradeRate(0.5); FaultToleranceConfigManager.putAppConfig(\u0026amp;quot;appName\u0026amp;quot;, faultToleranceConfig); As above, after the standalone fault tolerance switch is turned on, the application will calculate the exceptions every 20s time window. If a service + IP calling dimension is determined to be a faulty node, the weight of the service + IP will be degraded to 0.5 times.\nFor more detailed parameters, please refer to Standalone troubleshooting\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-tolerance/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7501b0fac1d1d89c61de0d591e29e1d0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","summary":"Usually, a service have multiple service providers in a cluster. Some of the service providers may have persistent connections still survived due to network, configuration, long-term fullgc, full thread pool, hardware failure and others, but the program cannot respond properly. The stand-alone fault tolerance function can degrade the exceptional service providers so that the client requests can be pointed to the healthy node. When the exceptional nodes become normal, the standalone fault tolerance function will restore the nodes, so that the client requests can gradually distribute traffic to the nodes.","tags":null,"title":"Fault tolerance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","wordcount":306},{"author":null,"categories":null,"content":"Fault tolerance automatically monitors the RPC calls, degrades the weight of the failed node, and recovers the weight when the node restored to normal. The bolt protocol is currently supported.\nIn SOFABoot, you only need to configure fault tolerance parameters to application.properties. You can select not to configure all parameters but only configure the parameters that you care about. Then, the remaining parameters will take the default values. Note that rpc.aft.regulation.effective is a global switch for this function. If it is off, the function will not work and other parameters will not take effect.\n Attribute Description Default value timeWindow Time window size: the period in which statistics are calculated. 10s leastWindowCount Minimum number of calls in the time window: Only data that has reached this minimum value in the time window will be added in calculation and control. 10 times leastWindowExceptionRateMultiple Degradation ratio of the exception rate in the time window to the average exception rate of the service: When calculating the statistical information, the average exception rate of all valid call IPs of the service is calculated. If the exception rate of an IP is greater than or equal to the lowest ratio, the IP will be degraded. 6 times weightDegradeRate Degradation ratio: The rate of degradation of an address when it is degraded. 1\u0026amp;frasl;20 weightRecoverRate Recovery ratio: The recovery ratio of the address when it is weighted. 2 times degradeEffective Degradation switch: If the application turns on this switch, it will degrade the address that matches the degradation criteria; otherwise, only the log will be printed. false (off) degradeLeastWeight Degradation minimum weight: If the address weight is degraded to the weight less than this minimum weight, the minimum weight will be used. 1 degradeMaxIpCount Maximum number of IPs for degradation: The number of IPs in the same service that have been degraded cannot exceed this value. 2 regulationEffective Global switch: If the switch is turned on by the application, the entire standalone fault tolerance function will be turned on; otherwise, this function will not be used at all. false (off) Example\nCom.alipay.sofa.rpc.aft.time.window=20 Com.alipay.sofa.rpc.aft.least.window.count=30 Com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple=6 Com.alipay.sofa.rpc.aft.weight.degrade.rate=0.5 Com.alipay.sofa.rpc.aft.weight.recover.rate=1.2 Com.alipay.sofa.rpc.aft.degrade.effective=ture Com.alipay.sofa.rpc.aft.degrade.least.weight=1 Com.alipay.sofa.rpc.aft.degrade.max.ip.count=2 Com.alipay.sofa.rpc.aft.regulation.effective=true As configured above, the fault tolerance function and degradation switch are enabled. When a node fails too many times, its weight is degraded, and during recovery, the weight will be restored. The node healthy is measured every 20s, and the nodes called for more than 30 times in 20s are recognized as calculation data. If the …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-fault-tolerance/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a132b54b2398534d1773489e2b0db166","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","summary":"Fault tolerance automatically monitors the RPC calls, degrades the weight of the failed node, and recovers the weight when the node restored to normal. The bolt protocol is currently supported.\nIn SOFABoot, you only need to configure fault tolerance parameters to application.properties. You can select not to configure all parameters but only configure the parameters that you care about. Then, the remaining parameters will take the default values. Note that rpc.","tags":null,"title":"Fault tolerance configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","wordcount":487},{"author":null,"categories":null,"content":" Feature architecture SOFABolt provides the following basic features: Basic communication functions (remoting-core) Netty-based, highly-effective network I/O and thread model practice Connection management (lock-free connection establishment, timed disconnection, automatic reconnection) Basic communication models (oneway, sync, future, callback) Timeout control Batch unpacking and batch submission processor Heartbeat and IDLE event processing Protocol framework (protocol-skeleton) Commands and command processor Coding and decoding processor Heartbeat trigger Custom private protocol implementation - RPC communication protocol (protocol-implementation) RPC communication protocol design Flexible deserialization timing control Request processing timeout FailFast mechanism User request processor (UserProcessor) Duplex communication Usage 1 Use SOFABolt as a remote communication framework. You do not need to consider the details of how to implement a private protocol, just use our built-in RPC communication protocol. You can simply enable the client side and the server side, and simultaneously register a user request processor, thereby completing the remote calling. In addition, basic features such as connection management and heartbeat are available by default. Currently supported call types are shown in the figure below:\n For a sample demonstration, refer to our user guide. Usage 2 Use SOFABolt as a protocol framework. You can reuse the basic functions of the basic communication model, the interface definitions included in the protocols, etc. Then, according to the private protocol you designed, you can customize the command types, command processors, decoding processors, etc. The RPC and message command definition structure is as shown in the figure below:\n","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-functions/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fde29139cbd8b786326a6479e52814dd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","summary":"Feature architecture SOFABolt provides the following basic features: Basic communication functions (remoting-core) Netty-based, highly-effective network I/O and thread model practice Connection management (lock-free connection establishment, timed disconnection, automatic reconnection) Basic communication models (oneway, sync, future, callback) Timeout control Batch unpacking and batch submission processor Heartbeat and IDLE event processing Protocol framework (protocol-skeleton) Commands and command processor Coding and decoding processor Heartbeat trigger Custom private protocol implementation - RPC communication protocol (protocol-implementation) RPC communication protocol design Flexible deserialization timing control Request processing timeout FailFast mechanism User request processor (UserProcessor) Duplex communication Usage 1 Use SOFABolt as a remote communication framework.","tags":null,"title":"Features","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","wordcount":237},{"author":null,"categories":null,"content":" Features Service publishing and reference Communication Protocol Bolt protocol Basic usage Calling type Timeout control Generic call Serialization protocol Custom thread pool RESTful protocol Basic usage Custom filter Integrated Swagger Dubbo Basic usage H2C Basic usage Registry center Direct call Load balancing Custom filter Custom router addressing Call retry Tracing SOFATracer Skywalking Custom thread pool Link data transparent transmission Warm-up weight Fault tolerance Node cross-language call Graceful shutdown ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/features/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0059809aed46360e8787e945ff098610","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/features/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/features/","summary":" Features Service publishing and reference Communication Protocol Bolt protocol Basic usage Calling type Timeout control Generic call Serialization protocol Custom thread pool RESTful protocol Basic usage Custom filter Integrated Swagger Dubbo Basic usage H2C Basic usage Registry center Direct call Load balancing Custom filter Custom router addressing Call retry Tracing SOFATracer Skywalking Custom thread pool Link data transparent transmission Warm-up weight Fault tolerance Node cross-language call Graceful shutdown ","tags":null,"title":"Features","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/features/","wordcount":68},{"author":null,"categories":null,"content":" 本文描述的是 MOSN 的 FilterChain 配置。\nFilterChain 是 MOSN Listener 配置中核心逻辑配置，不同的 FilterChain 配置描述了 Listener 会如何处理请求。\n目前 MOSN 一个 Listener 只支持一个 FilterChain。\nFilterChain 的配置结构如下所示。\n{ \u0026amp;quot;tls_context\u0026amp;quot;: {}, \u0026amp;quot;tls_context_set\u0026amp;quot;: [], \u0026amp;quot;filters\u0026amp;quot;: [] } tls_context_set 一组 tls_context 配置，MOSN 默认使用 tls_context_set 来描述 listener 的 TLS 的证书信息。 一个 listener 可同时支持配置多张 TLS 证书。 tls_context 单独配置 tls_context 而不是使用 tls_context_set 是兼容 MOSN 历史配置（只支持一张证书配置时）的场景，这种配置方式后面会逐步废弃。 tls_context 的详细配置说明，参考 tls_context。 filters 一组 network filter 配置。\nnetwork filter network filter 描述了 MOSN 在连接建立以后如何在 4 层处理连接数据。\n{ \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: {} } type 是一个字符串，描述了 filter 的类型。 config 可以是任意 json 配置，描述不同 filter 的配置。 network filter 可自定义扩展实现，默认支持的 type 包括 proxy、tcp proxy、connection_manager。 connection_manager 是一个特殊的 network filter，它需要和 proxy 一起使用，用于描述 proxy 中路由相关的配置，是一个兼容性质的配置，后续可能有修改。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/filter-chain/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d79979b85edad41aa6f0b3d8fe3295ee","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","summary":"本文描述的是 MOSN 的 FilterChain 配置。 FilterChain 是 MOSN Listener 配置中核心逻辑配置，不同的 FilterChain 配置描述了 Listener 会如何处理请求。 目前 MOSN 一个 Listener 只支持一个 FilterChain。 FilterChain 的配","tags":null,"title":"FilterChain 配置","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","wordcount":389},{"author":null,"categories":null,"content":" Framework preparation Before reading, you can download and install ACTS IDE and import the ACTS framework by refering to Quick start.\nThis topic mainly describes the encoding, datasource configuration, and quick configuration to help you use the ACTS framework.\nEncoding Ensure that the encoding of ACTS and that of the system code are consistent, specifically, ensure that the encoding for script generation and the encoding of the IDEA workspace are consistent with the encoding of your application code. Otherwise, the code may get corrupted.\nThe encoding selected for test script generation is shown as follows.\nEncoding of the IDEA workspace:\nDatasource configuration The purpose of configuring data sources in ACTS is to ensure that you can use the system\u0026amp;rsquo;s data sources to properly perform database addition, deletion, and query operations during the preparation, clearance, and check stages.\nDatasource configuration Configure the mapping relationship between the ModuleName, datasource, and tables at the DAL layer in src/test/resource/config/acts-config.properties. The name of datasources starts with ds_ as follows:\ndatasource_bundle_name =com.alipay.testapp.common.dal ds_bean1=table1,table2 ds_bean2=table3,table4 #Configuration format #ds_datasource bean=logical table 1,logical table 2 Bean 1 and bean 2 are the names of the datasource beans at the DAL layer of the application code. Multiple datasources are supported. The table name supports regular expressions and sharding suffixes are not required. In the case of multiple datasources, a table must belong to only one datasource. See the following figure.\nDirect JDBC connection to the database The direct JDBC connection to the database is used to generate the DB data model. The configuration in devdb.conf or testdb.conf under src/test/resource/config/dbConf/ is as follows:\nxxx_url = jdbc:oracle:thin:@localhost:1521:cifdb xxx_username = myname xxx_password = mypswd Quick configuration description The quick test framework configuration mainly generates the basic Java classes and the necessary configuration files:\nJava classes AppNameActsBaseUtils.java The utility class that is commonly used in the test script writing process to get various data from the ACTS framework. The initial version provides only common methods. You can add desired methods by yourself.\n AppNameActsTestBase.java The encapsulated application test base class. If you have special business system requirements, you can encapsulate additional methods based on this class. If not, ignore this file.\nConfiguration files ","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ready/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c3a89cbf42d55c98206a08e94d05ffde","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-ready/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-ready/","summary":"Framework preparation Before reading, you can download and install ACTS IDE and import the ACTS framework by refering to Quick start.\nThis topic mainly describes the encoding, datasource configuration, and quick configuration to help you use the ACTS framework.\nEncoding Ensure that the encoding of ACTS and that of the system code are consistent, specifically, ensure that the encoding for script generation and the encoding of the IDEA workspace are consistent with the encoding of your application code.","tags":null,"title":"Framework preparation","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-ready/","wordcount":358},{"author":null,"categories":null,"content":"Since Java 8, Java has introduced various @FunctionalInterface interfaces to support functional programming. Generally, Java functions will be executed in a ForkJoinPool. If some thread variables of Tracer are not passed in, it will cause the loss of Trace information.\nTherefore, in SOFATracer XXX version, a series of wrapper classes for these @FunctionalInterface interfaces has been added to ensure that trace-related information can be transferred correctly and transparently. The following is an example of the Consumer interface, just need to change the construction of Consumer to SofaTracerConsumer, and pass the original Consumer as the parameter of the constructor of SofaTracerConsumer:\nConsumer\u0026amp;lt;String\u0026amp;gt; consumer = new SofaTracerConsumer\u0026amp;lt;\u0026amp;gt;(System.out::println); All wrapped classes are in the https://github.com/sofastack/sofa-tracer/tree/master/tracer-core/src/main/java/com/alipay/common/tracer/core/async directory.\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/functional-interface-support/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"45e4d21f290976f4206beac2f4712aec","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","summary":"Since Java 8, Java has introduced various @FunctionalInterface interfaces to support functional programming. Generally, Java functions will be executed in a ForkJoinPool. If some thread variables of Tracer are not passed in, it will cause the loss of Trace information.\nTherefore, in SOFATracer XXX version, a series of wrapper classes for these @FunctionalInterface interfaces has been added to ensure that trace-related information can be transferred correctly and transparently. The following is an example of the Consumer interface, just need to change the construction of Consumer to SofaTracerConsumer, and pass the original Consumer as the parameter of the constructor of SofaTracerConsumer:","tags":null,"title":"Functional interface support","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","wordcount":113},{"author":null,"categories":null,"content":"从 Java 8 中，Java 开始引入了各种 @FunctionalInterface 接口，以更好地支持函数式编程，通常，Java 的函数会在一个 ForkJoinPool 中执行，如果这个时候没有把 Tracer 的一些线程变量传递进去的话，就会造成 Trace 信息的丢失。\n因此，在 SOFATracer XXX 版本中增加了对这些 @FunctionalInterface 接口的包装类，以确保 Trace 相关的信息能够正确地传递下面，下面以 Consumer 接口为例进行说明，只需要将原来构造 Consumer 的地方修改成构造 SofaTracerConsumer，并且将原来的 Consumer 传入作为 SofaTracerConsumer 的构造函数的参数即可：\nConsumer\u0026amp;lt;String\u0026amp;gt; consumer = new SofaTracerConsumer\u0026amp;lt;\u0026amp;gt;(System.out::println); 所有做了包装的类都在 https://github.com/sofastack/sofa-tracer/tree/master/tracer-core/src/main/java/com/alipay/common/tracer/core/async 目录下，文档中不一一列举。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/functional-interface-support/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"45e4d21f290976f4206beac2f4712aec","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/functional-interface-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/functional-interface-support/","summary":"从 Java 8 中，Java 开始引入了各种 @FunctionalInterface 接口，以更好地支持函数式编程，通常，Java 的函数会在一个 ForkJoinPool 中执行，如果这个时候没有把 Tracer 的一些线程变量传递","tags":null,"title":"Functional 接口支持","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/functional-interface-support/","wordcount":229},{"author":null,"categories":null,"content":" Generic calls provide the ability for clients to initiate calls without having to rely on the server`s interface. Currently, the generic call of SOFARPC only supports using Hessian2 as the serialization protocol under the Bolt communication protocol.\nSOFABoot environment Publish Service There is nothing special about publishing a service. Just publish the service normally, for example:\n\u0026amp;lt;!-- generic --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Reference Service \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.api.GenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs generic-interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; The jvm-first can be left empty according to the actual situation. The interface should be the general interface of generic call. As for the generic-interface, you can just write in the name of the interface to be called.\nInitiate a call GenericService sampleGenericServiceReference = (GenericService) applicationContext .getBean(\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot;); GenericObject genericResult = (GenericObject) sampleGenericServiceReference.$genericInvoke(\u0026amp;quot;sayGeneric\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericParamModel\u0026amp;quot; }, new Object[] { genericObject }); RPC API ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt;() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); You can set the service as a generic service and set the interface name of the server by setGeneric as above. GenericService is used as a generic service, and GenericService can initiate generic calls. You need to pass in the method name, method type, and method parameters when invoking a call.\nIf the parameter or return result is also required to be generalized on the client side, you can achieve this with GenericObject.\nGenericObject genericObject = new GenericObject(\u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot;); genericObject.putField(\u0026amp;quot;str\u0026amp;quot;, \u0026amp;quot;xxxx\u0026amp;quot;); genericObject.putField(\u0026amp;quot;num\u0026amp;quot;, 222); GenericObject result = (GenericObject) testService.$genericInvoke(\u0026amp;quot;echoObj\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot; }, new Object[] { genericObject }); String str = result.getField(\u0026amp;quot;str\u0026amp;quot;); String …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/generic-invoke/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"84ac624dc99a42a8f89489aa10304ef7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","summary":"Generic calls provide the ability for clients to initiate calls without having to rely on the server`s interface. Currently, the generic call of SOFARPC only supports using Hessian2 as the serialization protocol under the Bolt communication protocol.\nSOFABoot environment Publish Service There is nothing special about publishing a service. Just publish the service normally, for example:\n\u0026lt;!-- generic --\u0026gt; \u0026lt;bean id=\u0026quot;sampleGenericServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;sampleGenericServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt/\u0026gt; \u0026lt;/sofa:service\u0026gt; Reference Service \u0026lt;sofa:reference jvm-first=\u0026quot;false\u0026quot; id=\u0026quot;sampleGenericServiceReference\u0026quot; interface=\u0026quot;com.","tags":null,"title":"Generic call","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","wordcount":501},{"author":null,"categories":null,"content":" This document introduces how to use SOFARPC for service publishing and reference in SOFABoot.\nYou can get the code sample of this document by clicking here. Note that the code sample requires a local installation of the zookeeper environment. If not, you need to remove the com.alipay.sofa.rpc.registry.address configuration in application.properties to use the local file as a registry center.\nCreate a project Prepare environment: SOFABoot requires JDK7 or JDK8 and needs to be compiled with Apache Maven 2.2.5 or above. Build SOFABoot project: SOFABoot is based on Spring Boot. So you can use Spring Boot\u0026amp;rsquo;s project generation tool to generate a standard Spring Boot project. Add SOFABoot dependency: The generated standard Spring Boot project directly uses Spring parent dependency, which should be changed to the parent dependency provided by SOFABoot. The parent dependency provides and manages a variety of starters provided by SOFABoot. \u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa-boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Here, \u0026amp;lsquo;${sofa-boot.version}\u0026amp;rsquo; specifies the specific SOFABoot version. Refer to Release History.\n Configure application.properties: application.properties is the configuration file in SOFABoot project. Here you need to configure the application name. spring.application.name=AppName Introduce RPC starter: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Define service interface and implementation public interface AnnotationService { String sayAnnotation(String string); } Publish service on server Publish the service through \u0026amp;lsquo;@SofaService\u0026amp;rsquo; annotation, as shown in the following code: SOFABoot registers the service implementation on the server, communicates with the client by bolt protocol, and publishes metadata such as address to registry center (local file is used as registry center by default).\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } Reference service by client The reference service is annotated with \u0026amp;lsquo;@SofaReference\u0026amp;rsquo;, as shown in the following code: SOFABoot will generate a RPC proxy bean for \u0026amp;lsquo;AnnotationService\u0026amp;rsquo;, it also …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-sofa-boot/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0dd5e0e5116473aee630cba38679d493","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","summary":"This document introduces how to use SOFARPC for service publishing and reference in SOFABoot.\nYou can get the code sample of this document by clicking here. Note that the code sample requires a local installation of the zookeeper environment. If not, you need to remove the com.alipay.sofa.rpc.registry.address configuration in application.properties to use the local file as a registry center.\nCreate a project Prepare environment: SOFABoot requires JDK7 or JDK8 and needs to be compiled with Apache Maven 2.","tags":null,"title":"Get started with SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","wordcount":501},{"author":null,"categories":null,"content":" This document introduces how to apply SOFARPC for service publishing and reference. This example will simulate a server locally to listen to a port and publish a service, and the client will reference the service for direct call.\nYou can get the code sample of this document by clicking here.\nCreate a project You need to install JDK 6 or above and Maven 3 or above.\nCreate a new Maven project and introduce SOFARPC dependency.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;latest version\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note: The latest version can be found at https://github.com/sofastack/sofa-rpc/releases.\nWrite a server implementation Step 1: Create interface\n/** * Quick Start demo interface */ public interface HelloService { String sayHello(String string); } Step 2: Create interface implementation\n/** * Quick Start demo implement */ public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string { System.out.println(\u0026amp;quot;Server receive: \u0026amp;quot; + string); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; !\u0026amp;quot;; } } Step 3: Write the server code\n/** * Quick Start Server */ public class QuickStartServer { public static void main(String[] args) { ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // Set a protocol, which is bolt by default .setPort(12200) // set a port, which is 12200 by default .setDaemon(false); // non-daemon thread ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // Specify the interface .setRef(new HelloServiceImpl()) // Specify the implementation .setServer(serverConfig); // Specify the server providerConfig.export (); // Publish service } } Write a client implementation Step 1: Get the server interface\nIn general, the server provides the interface class to the client in the form of jar. In this example, this step is skipped since the server and client are in the same project.\nStep 2: Write the client code\n/** * Quick Start client */ public class QuickStartClient { public static void main(String[] args) { ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // Specify the interface .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // Specify the protocol.setDirectUrl .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12200\u0026amp;quot;); // Specify the direct connection address // Generate the proxy class HelloService helloService = consumerConfig.refer(); while (true) { System.out.println(helloService.sayHello(\u0026amp;quot;world\u0026amp;quot;)); try { Thread.sleep(2000); } catch (Exception e) { } } } } Run Start the server and client separately.\nThe server outputs:\n Server receive: The world\n The client outputs:\n hello world !\n More For more examples, please refer to: example\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-rpc/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"192d252b0b36266622284b68d10e9fe4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","summary":"This document introduces how to apply SOFARPC for service publishing and reference. This example will simulate a server locally to listen to a port and publish a service, and the client will reference the service for direct call.\nYou can get the code sample of this document by clicking here.\nCreate a project You need to install JDK 6 or above and Maven 3 or above.\nCreate a new Maven project and introduce SOFARPC dependency.","tags":null,"title":"Get started with SOFARPC","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","wordcount":371},{"author":null,"categories":null,"content":" Graceful shutdown includes two parts. One is the RPC framework as client, and the other is the RPC framework as server.\nAs server As the server, the RPC framework should not be violently shutdown.\ncom.alipay.sofa.rpc.context.RpcRuntimeContext Added a ShutdownHook to the static initialization snippet:\n// Add jvm shutdown event if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } The logic in ShutdownHook is executed first when the publishing platform or users run the following method kill pid. In the destroy operation, the RPC framework first performs actions such as canceling service registration to the registry center and closing the service port.\nprivate static void destroy(boolean active) { RpcRunningState.setShuttingDown (true); for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.preDestroy(); } List\u0026amp;lt;ProviderConfig\u0026amp;gt; providerConfigs = new ArrayList\u0026amp;lt;ProviderConfig\u0026amp;gt;(); for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { providerConfigs.add(bootstrap.getProviderConfig()); } // First, unregister the server List\u0026amp;lt;Registry\u0026amp;gt; registries = RegistryFactory.getRegistries(); if (CommonUtils.isNotEmpty(registries) \u0026amp;amp;\u0026amp;amp; CommonUtils.isNotEmpty(providerConfigs)) { for (Registry registry : registries) { registry.batchUnRegister(providerConfigs); } } / / Shut down the port that has been started ServerFactory.destroyAll(); // Close the published service for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { bootstrap.unExport(); } // Close the called service for (ConsumerBootstrap bootstrap : REFERRED_CONSUMER_CONFIGS) { ConsumerConfig config = bootstrap.getConsumerConfig(); If (!CommonUtils.isFalse(config.getParameter(RpcConstants.HIDDEN_KEY_DESTROY))) { // Unless you do not let the active unrefer bootstrap.unRefer(); } } // Shut down the registry center RegistryFactory.destroyAll(); / / Close some public resources of the client ClientTransportFactory.closeAll(); // Uninstall the module if (!RpcRunningState.isUnitTestMode()) { ModuleFactory.uninstallModules(); } // Uninstall the hook for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.postDestroy(); } // Clean up the cache RpcCacheManager.clearAll(); RpcRunningState.setShuttingDown (false); if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework has been release all resources {}...\u0026amp;quot;, active ? \u0026amp;quot;actively \u0026amp;quot; : \u0026amp;quot;\u0026amp;quot;); } } Taking bolt as an example, closing the port is not an immediate action.\n@Override public void destroy() { if (!started) { return; } int stopTimeout = serverConfig.getStopTimeout(); If (stopTimeout \u0026amp;gt; 0) { // need to wait for the end time AtomicInteger count = …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/graceful-shutdown/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"53af179e23ba184b01eb8234c055b15d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","summary":"Graceful shutdown includes two parts. One is the RPC framework as client, and the other is the RPC framework as server.\nAs server As the server, the RPC framework should not be violently shutdown.\ncom.alipay.sofa.rpc.context.RpcRuntimeContext Added a ShutdownHook to the static initialization snippet:\n// Add jvm shutdown event if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.","tags":null,"title":"Graceful shutdown","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","wordcount":669},{"author":null,"categories":null,"content":" H2C protocol SOFARPC provides support for the H2C protocol, which can be used to publish and reference services.\n Basic usage ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"45b6d6ba0ca1ae7f6d415d79c184f766","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/h2c/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/h2c/","summary":" H2C protocol SOFARPC provides support for the H2C protocol, which can be used to publish and reference services.\n Basic usage ","tags":null,"title":"H2C","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/h2c/","wordcount":20},{"author":null,"categories":null,"content":"SOFARPC 提供了 H2C 协议的支持，可以可以采用 H2C 协议来进行服务的发布和引用 * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"45b6d6ba0ca1ae7f6d415d79c184f766","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/h2c/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/h2c/","summary":"SOFARPC 提供了 H2C 协议的支持，可以可以采用 H2C 协议来进行服务的发布和引用 * 基本使用","tags":null,"title":"H2C","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/h2c/","wordcount":36},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 H2C 协议，只要将 Binding 设置为 H2C 即可。下面使用以注解的方式来例举，其他的使用方式可以参考 Bolt 协议基本使用，这里不再重复说明。：\n发布服务 发布一个 H2C 的服务，只需要将 @SofaServiceBinding 的 bindingType 设置为 h2c 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 引用服务 引用一个 H2C 的服务，只需要将 @SofaReferenceBinding 的 bindingType 设置为 h2c 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c-usage/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa75eff1e99b3acad5087160a1b44a09","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/h2c-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/h2c-usage/","summary":"在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 H2C 协议，只要将 Binding 设置为 H2C 即可。下面使用以注解的方式来例举，其他的使用方式可以","tags":null,"title":"H2C 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/h2c-usage/","wordcount":168},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0e92b5faec8584280cc296255f3a4541","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/http/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/http/","summary":"","tags":null,"title":"HTTP","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/http/","wordcount":0},{"author":null,"categories":null,"content":" SOFABoot provides Readiness Check to enhance Spring Boot\u0026amp;rsquo;s Health Check. If you need to use the SOFA middleware, you are advised to use the Health Check extension of SOFABoot to launch application examples in a more elegant way.\nEnable Health Check To enable the Health Check feature in SOFABoot, you only need to import the following starter:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Without the Health Check extension, users still can perform Liveness Check with native Spring Boot Actuator directly relying on the HealthIndicator interface.\nSecurity alert From SOFABoot 2.3.0 on, the Health Check depends on the Actuator component in SpringBoot 1.4.x, and the component opens a lot of EndPoint such as \u0026amp;lsquo;/dump \u0026amp;rsquo; and \u0026amp;lsquo;/trace\u0026amp;rsquo;. So there may be a security risk. Refer to the Security Recommendations in the official document for settings.\nSpringBoot 1.5.x and SpringBoot 2.x. have fixed some security issues. SOFABoot will be supported by upgrading the SpringBoot kernel.\nView Health Check results After adding the Health Check extension, you can directly browser http://localhost:8080/health/readiness to view the Readiness Check results. To view the Liveness Check results, access the URL of the Spring Boot Health Check results. http://localhost:8080/health。\nIn SOFABoot, you can also view Health Check results by checking the specific logs in the health-check directory. Generally, such logs contain the following content:\n2018-04-06 23:29:50,240 INFO main - Readiness check result: success At present, the SOFA middleware has controlled upstream traffic access through the Readiness Check offered by SOFABoot. But, apart from the middleware, traffic of an application may come from other sources such as the load balancer. To control such traffic, users are advised to view the Readiness Check results by PAAS and determine whether to launch corresponding nodes in the load balancer based on the results.\n** Note: Versions after SOFABoot 2.x no longer indirectly introduce spring-boot-starter-web dependencies. To view Health Check results in the browser, you need to introduce Web container dependencies in the project. **\n** Note: In SOFABoot 3.x, the endpoint path has been changed from health/readiness to actuator/readiness**\nReadiness Check extension SOFABoot allows extension in every phase of the Readiness Check. Applications can be extended according to their needs. In version 2.x, the extendable points are as follows:\n Callback interface Description org.springframework.context.ApplicationListener If you want to do something before the Readiness Check, you can monitor the SofaBootBeforeHealthCheckEvent event of this listener. org.springframework.boot.actuate.health.HealthIndicator If you want to add a check item to the Readiness Check in SOFABoot, you can directly extend this interface of Spring Boot. …","date":-62135596800,"description":"","dir":"projects/sofa-boot/health-check/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a366b25125fa4aedb08a9cef572db1c8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/health-check/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/health-check/","summary":"SOFABoot provides Readiness Check to enhance Spring Boot\u0026rsquo;s Health Check. If you need to use the SOFA middleware, you are advised to use the Health Check extension of SOFABoot to launch application examples in a more elegant way.\nEnable Health Check To enable the Health Check feature in SOFABoot, you only need to import the following starter:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;healthcheck-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Without the Health Check extension, users still can perform Liveness Check with native Spring Boot Actuator directly relying on the HealthIndicator interface.","tags":null,"title":"Health check","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/health-check/","wordcount":707},{"author":null,"categories":null,"content":" Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to the article Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing an ACTS bug or adding an ACTS feature, submit an issue on ACTS GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The ACTS maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All ACTS modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step.\nGit clone https://github.com/your account name/acts.git Pull a branch to prepare for code modification.\ngit branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\n git branch -a If you want to switch back to the master branch, execute the following command:\n git checkout -b master If you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\n After modifying the code, execute the following command to submit all modifications to your local repository:\ngit commit -am \u0026#39;Add xx feature\u0026#39; When modifying the code, note the following: Keep the code style consistent. ACTS uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Supplement unit test code.\n New modifications should have passed existing unit tests.\n Provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. Execute the following command to run all tests:\nmvn clean test You can also use the IDE to help run a test.\nOther do\u0026amp;rsquo;s and …","date":-62135596800,"description":"","dir":"projects/sofa-acts/contributing/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"cd68baede6258921f83665ef0a446f1f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/contributing/","summary":"Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to the article Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing an ACTS bug or adding an ACTS feature, submit an issue on ACTS GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/contributing/","wordcount":808},{"author":null,"categories":null,"content":" We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submitting an issue Regardless of whether you are fixing a SOFADashboard bug or adding a SOFADashboard feature, submit an issue on SOFADashboard GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.\nThere are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFADashboard maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All SOFADashboard modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-dashboard.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to the branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFADashboard uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Add the unit test code.\n Modifications should have passed existing unit tests.\n You should provide a new unit test to prove that the previous code has bugs and the bugs\nhave been fixed in the new code. You can execute the following code to run all tests:\n mvn clean test You can also use the IDE to help run a test. …","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/contribution/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"584584be9c13f2d36c85890dd192368a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/contribution/","summary":"We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/contribution/","wordcount":837},{"author":null,"categories":null,"content":" We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of git tools, refer to official books on gitand get familiarized by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFARegistry bug or adding a SOFARegistry feature, submit an issue on the SOFARegistry GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFARegistry maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All SOFARegistry modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review.\nTherefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-registry.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command:\ngit branch -a If you want to switch back to the master branch, execute the following command:\ngit checkout -b master If you want to switch back to the branch, execute the following command:\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFARegistry uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Add the unit test code. Modifications should have passed existing unit tests. You should provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. You can execute the following code to run all tests: mvn clean test You can also use the IDE to help run a test.\nOther do\u0026amp;rsquo;s …","date":-62135596800,"description":"","dir":"projects/sofa-registry/contributing/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c08b5945719137833634c111c43a8d9e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/contributing/","summary":"We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of git tools, refer to official books on gitand get familiarized by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFARegistry bug or adding a SOFARegistry feature, submit an issue on the SOFARegistry GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/contributing/","wordcount":839},{"author":null,"categories":null,"content":" How to contribute SOFABolt\u0026amp;rsquo;s code is open source. You can submit your contributions to the code after signing the required agreement.\nContributor License Agreement Alterations and modifications made to SOFABolt\u0026amp;rsquo;s code must comply with the Contributor License Agreement.\nPrerequisites Before contributing any code, you need to know how to use the Git tool and the GitHub website.\nFor the use of Git tools, refer to the official Pro Git book and get familiar with the tools by reading the first few chapters.\nFor the Git collaboration process, refer to Git Workflows.\nGitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a Bolt bug or adding a Bolt feature, submit an issue on the Bolt GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The Bolt maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the Bolt\u0026amp;rsquo;s master branch code to your code repository.\nPull a branch All Bolt modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with the getting source code step, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/sofastack/sofa-bolt.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to your branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; If you want to directly pull a branch from GitHub, execute the following command: git clone -b branchname https://xxx.git Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. Bolt uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally. mvn clean package Add the unit test code. Modifications should have passed existing unit …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-contribution/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c044ad534cf99e4d6d400113b490f816","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","summary":"How to contribute SOFABolt\u0026rsquo;s code is open source. You can submit your contributions to the code after signing the required agreement.\nContributor License Agreement Alterations and modifications made to SOFABolt\u0026rsquo;s code must comply with the Contributor License Agreement.\nPrerequisites Before contributing any code, you need to know how to use the Git tool and the GitHub website.\nFor the use of Git tools, refer to the official Pro Git book and get familiar with the tools by reading the first few chapters.","tags":null,"title":"How to contribute to SOFABolt","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","wordcount":1140},{"author":null,"categories":null,"content":" Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFAJRaft bug or adding a SOFAJRaft feature, submit an issue on the SOFAJRaft GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFAJRaft maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch We recommend that you first read the SOFAJRaft Branch management policy.\nAll SOFAJRaft modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-jraft Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to the branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFAJRaft uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally. mvn clean compile Add the unit test code.\n New modifications should have passed existing unit tests.\n Provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. Execute the following command to run all tests:\n mvn clean test You can also use the IDE to help execute a command.\nOther do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original style of the …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"99034715298f73cd835672b872141609","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","summary":"Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFAJRaft bug or adding a SOFAJRaft feature, submit an issue on the SOFAJRaft GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute to SOFAJRaft","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","wordcount":841},{"author":null,"categories":null,"content":" Http 协议基本使用 在 SOFARPC (非SOFABoot 环境)中，当使用Http作为服务端协议的时候，支持Json作为序列化方式，作为一些基础的测试方式使用。\nSOFARPC API 使用 发布服务 // 只有1个线程 执行 ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); // 发布一个服务，每个请求要执行1秒 ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026amp;quot;serverApp\u0026amp;quot;)) .setServer(serverConfig) .setUniqueId(\u0026amp;quot;uuu\u0026amp;quot;) .setRegister(false); providerConfig.export(); 服务引用 因为是Http+Json，所以引用方可以直接通过HttpClient进行调用,以下为一段测试代码。\nprivate ObjectMapper mapper = new ObjectMapper(); HttpClient httpclient = HttpClientBuilder.create().build(); // POST 正常请求 String url = \u0026amp;quot;http://127.0.0.1:12300/com.alipay.sofa.rpc.server.http.HttpService:uuu/object\u0026amp;quot;; HttpPost httpPost = new HttpPost(url); httpPost.setHeader(RemotingConstants.HEAD_SERIALIZE_TYPE, \u0026amp;quot;json\u0026amp;quot;); ExampleObj obj = new ExampleObj(); obj.setId(1); obj.setName(\u0026amp;quot;xxx\u0026amp;quot;); byte[] bytes = mapper.writeValueAsBytes(obj); ByteArrayEntity entity = new ByteArrayEntity(bytes, ContentType.create(\u0026amp;quot;application/json\u0026amp;quot;)); httpPost.setEntity(entity); HttpResponse httpResponse = httpclient.execute(httpPost); Assert.assertEquals(200, httpResponse.getStatusLine().getStatusCode()); byte[] data = EntityUtils.toByteArray(httpResponse.getEntity()); ExampleObj result = mapper.readValue(data, ExampleObj.class); Assert.assertEquals(\u0026amp;quot;xxxxx\u0026amp;quot;, result.getName()); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http-json/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"28abdf6369247346bad670c639a422b8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/http-json/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/http-json/","summary":"Http 协议基本使用 在 SOFARPC (非SOFABoot 环境)中，当使用Http作为服务端协议的时候，支持Json作为序列化方式，作为一些基础的测试方式使用。","tags":null,"title":"Http 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/http-json/","wordcount":242},{"author":null,"categories":null,"content":" HttpClient Integration In this document will demonstrate how to use SOFATracer to track of HttpClient, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;!-- SOFATracer dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- HttpClient dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 4.5.X --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpasyncclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 4.X --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.1.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer under the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the current application name and logging.path that specifies the log output directory.\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs Add a Controller that provides RESTful service @RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8080/httpclient?name= * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/httpclient\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;httpclient\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } Construct HttpClient to initiate a call to the RESTful service above The code example is as follows:\n Construct an HttpClient synchronous call instance: HttpClientBuilder httpClientBuilder = HttpClientBuilder.create(); // SOFATracer SofaTracerHttpClientBuilder.clientBuilder(httpClientBuilder); CloseableHttpClient httpClient = httpClientBuilder.setConnectionManager(connManager).disableAutomaticRetries() .build(); Construct an HttpClient asynchronous call instance: RequestConfig requestConfig = RequestConfig.custom().setSocketTimeout(6000).setConnectTimeout(6000).setConnectionRequestTimeout(6000).build(); HttpAsyncClientBuilder httpAsyncClientBuilder = HttpAsyncClientBuilder.create(); //tracer SofaTracerHttpClientBuilder.asyncClientBuilder(httpAsyncClientBuilder); CloseableHttpAsyncClient asyncHttpclient = httpAsyncClientBuilder.setDefaultRequestConfig(requestConfig).build(); When you construct the HttpClient via the SofaTracerHttpClientBuilder (clientBuilder method for synchronous call instance, and asyncClientBuilder method for asynchronous call instance) to initiate a call to the RESTful service above, the link data of …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-httpclient/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3efb3d0d5bd884665537aa974ec21359","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","summary":"HttpClient Integration In this document will demonstrate how to use SOFATracer to track of HttpClient, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;!-- SOFATracer dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- HttpClient dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.apache.httpcomponents\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;httpclient\u0026lt;/artifactId\u0026gt; \u0026lt;!-- 4.5.X --\u0026gt; \u0026lt;version\u0026gt;4.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.apache.httpcomponents\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;httpasyncclient\u0026lt;/artifactId\u0026gt; \u0026lt;!-- 4.X --\u0026gt; \u0026lt;version\u0026gt;4.1.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer under the project\u0026rsquo;s application.","tags":null,"title":"HttpClient Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","wordcount":498},{"author":null,"categories":null,"content":" HttpClient Log Format After integrating tracer-httpclient-plugin, SOFATracer outputs the link data requested by HttpClient in JSON data by default.\nHttpClient digest log (httpclient-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.code HTTP call returns status code req.size.bytes Request body size resp.size.bytes Response body size Time.cost.milliseconds Request time (ms) Current.thread.name Thread name Remote.app Name of the called application Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-27 21:58:43.067\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8801538056723034100235072\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:33,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;I/O dispatcher 1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Note: The application name can be passed in as a parameter when constructing an HttpClient instance via SofaTracerHttpClientBuilder.\nHttpClient statistical Log (httpclient-stat.log) stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success (the result code starting with 1 and 2 indicates success, and 302 indicates that the redirection is successful, and others indicate failure); N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-27 21:59:42.233\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:562,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-httpclient/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7df3d68ba21f1b2a43c0265fdc4eae3e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","summary":"HttpClient Log Format After integrating tracer-httpclient-plugin, SOFATracer outputs the link data requested by HttpClient in JSON data by default.\nHttpClient digest log (httpclient-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.","tags":null,"title":"HttpClient log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","wordcount":220},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 HttpClient 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;!-- SOFATracer 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- HttpClient 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 版本 4.5.X 系列 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpasyncclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 版本 4.X 系列 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.1.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8080/httpclient?name= * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/httpclient\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;httpclient\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } 构造 HttpClient 发起一次对上文的 RESTful 服务的调用 代码示例如下：\n 构造 HttpClient 同步调用实例： HttpClientBuilder httpClientBuilder = HttpClientBuilder.create(); //SOFATracer SofaTracerHttpClientBuilder.clientBuilder(httpClientBuilder); CloseableHttpClient httpClient = httpClientBuilder.setConnectionManager(connManager).disableAutomaticRetries() .build(); 构造 HttpClient 异步调用实例： RequestConfig requestConfig = RequestConfig.custom().setSocketTimeout(6000).setConnectTimeout(6000).setConnectionRequestTimeout(6000).build(); HttpAsyncClientBuilder httpAsyncClientBuilder = HttpAsyncClientBuilder.create(); //tracer SofaTracerHttpClientBuilder.asyncClientBuilder(httpAsyncClientBuilder); CloseableHttpAsyncClient asyncHttpclient = httpAsyncClientBuilder.setDefaultRequestConfig(requestConfig).build(); 通过 SofaTracerHttpClientBuilder(clientBuilder 方法构造同步，asyncClientBuilder 方法构造异步) 构造的 HttpClient 在发起对上文的 RESTful 服务调用的时候，就会埋点 SOFATracer 的链路的数据。\n运行 启动 SOFABoot 应用，在控制台中看到启动打印的日志如下：\n2018-09-27 20:31:21.465 INFO 33277 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-09-27 20:31:21.599 INFO 33277 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-09-27 20:31:21.608 INFO 33277 --- [ main] c.a.s.t.e.h.HttpClientDemoApplication : Started HttpClientDemoApplication in 5.949 seconds (JVM running for 6.573) 当有类似如下的日志时，说明 HttpClient 的调用成功：\n2018-09-27 20:31:22.336 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-httpclient/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3efb3d0d5bd884665537aa974ec21359","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","summary":"在本文档将演示如何使用 SOFATracer 对 HttpClient 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;!-- SOFATracer 依","tags":null,"title":"HttpClient 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","wordcount":748},{"author":null,"categories":null,"content":" SOFATracer 集成 sofa-tracer-httpclient-plugin 插件后输出 HttpClient 请求的链路数据，默认为 JSON 数据格式。\nHttpClient 摘要日志（httpclient-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:43:13.191\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e27a79c1567438993170100210107\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;I/O dispatcher 1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;21ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} 备注：应用名称可以通过 SofaTracerHttpClientBuilder 构造 HttpClient 实例时以入参的形式传入。\nHttpClient 统计日志（httpclient-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功(1 开头和 2 开头的结果码算是成功的，302表示的重定向算成功，其他算是失败的)；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:44:11.785\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:229,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-httpclient/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7df3d68ba21f1b2a43c0265fdc4eae3e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","summary":"SOFATracer 集成 sofa-tracer-httpclient-plugin 插件后输出 HttpClient 请求的链路数据，默认为 JSON 数据格式。 HttpClient 摘要日志（httpclient-digest.log） 以 JSON 格式输出的数据，相应 key 的含","tags":null,"title":"HttpClient 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","wordcount":407},{"author":null,"categories":null,"content":" SOFARPC is integrated Hystrix provides fuse capability and is currently available in the first preview version. More information about Hystrix can be found in Hystrix Official Documentation, Hystrix integration capabilities are provided primarily by ScienJus, thanks for contribution.\nNext, let\u0026amp;rsquo;s talk about how to experience the fuse capability of Hystrix. The following example uses the SOFARPC 5.5.0 version. More Hystrix configuration and SOFABoot integration usage will be provided in subsequent releases, so stay tuned.\nWork preparation The Hystrix module is not loaded directly as an optional module by default. If you need to use it, you need to actively add the Hystrix maven dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; By explicitly opening Hystrix by configuration, HystrixFilter will be loaded automatically:\n// Open globally RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // Open for a specific Consumer ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); FallbackFactory The FallbackFactory interface mainly provides the injection capability of the Fallback implementation, which is used to automatically perform the degraded logic when Hystrix executes an exception (throws an exception, timeout, thread pool rejection, and blown).\nDefine the interface Fallback implementation:\npublic class HelloServiceFallback implements HelloService { @Override public String sayHello(String name, int age) { return \u0026amp;quot;fallback \u0026amp;quot; + name + \u0026amp;quot; from server! age: \u0026amp;quot; + age; } } Inject Fallback implementation:\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); // You can directly inject Fallback implementation directly using the default FallbackFactory SofaHystrixConfig.registerFallback(consumerConfig, new HelloServiceFallback()); // You can also customize FallbackFactory to directly inject FallbackFactory SofaHystrixConfig.registerFallbackFactory(consumerConfig, new HelloServiceFallbackFactory()); When the server responds with a failure, the client automatically triggers the Fallback logic execution.\nSetterFactory SetterFactory provides Hystrix fine-grained configuration capabilities. SOFARPC has provided the default DefaultSetterFactory to generate the Setter for each caller. If there is a more customized description, it can also be provided for each ConsumerConfig. Customize SetterFactory.\nSofaHystrixConfig.registerSetterFactory(consumerConfig, new CustomSetterFactory()); In the implementation provided by default, GroupKey is InterfaceId, and CommandKey is the …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-hystrix/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7482dc341bf16dd5671634ffa689604a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","summary":"SOFARPC is integrated Hystrix provides fuse capability and is currently available in the first preview version. More information about Hystrix can be found in Hystrix Official Documentation, Hystrix integration capabilities are provided primarily by ScienJus, thanks for contribution.\nNext, let\u0026rsquo;s talk about how to experience the fuse capability of Hystrix. The following example uses the SOFARPC 5.5.0 version. More Hystrix configuration and SOFABoot integration usage will be provided in subsequent releases, so stay tuned.","tags":null,"title":"Hystrix fault tolerance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","wordcount":335},{"author":null,"categories":null,"content":" SOFARPC 已集成 Hystrix 提供熔断能力，当前提供第一个预览版。关于 Hystrix 的更多介绍可以参考 Hystrix 官方文档，Hystrix 集成能力主要由 ScienJus 提供，感谢贡献。\n接下来介绍一下如何体验 Hystrix 带来的熔断能力，以下示例使用 SOFARPC 5.5.0 版本，更多 Hystrix 的配置及 SOFABoot 集成使用方式将在后续版本提供，敬请关注。\n准备工作 Hystrix 模块作为可选模块默认不会直接加载，如需要使用，需要先主动加入 Hystrix maven 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 通过配置显式开启 Hystrix，将会自动加载 HystrixFilter：\n// 全局开启 RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // 对特定 Consumer 开启 ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); FallbackFactory FallbackFactory 接口主要提供 Fallback 实现的注入能力，用于在 Hystrix 执行出现异常（抛出异常、超时、线程池拒绝和熔断等）时自动执行降级逻辑。\n定义接口 Fallback 实现：\npublic class HelloServiceFallback implements HelloService { @Override public String sayHello(String name, int age) { return \u0026amp;quot;fallback \u0026amp;quot; + name + \u0026amp;quot; from server! age: \u0026amp;quot; + age; } } 注入 Fallback 实现：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); // 可以直接使用默认的 FallbackFactory 直接注入 Fallback 实现 SofaHystrixConfig.registerFallback(consumerConfig, new HelloServiceFallback()); // 也可以自定义 FallbackFactory 直接注入 FallbackFactory SofaHystrixConfig.registerFallbackFactory(consumerConfig, new HelloServiceFallbackFactory()); 当服务端响应失败时，客户端会自动触发 Fallback 逻辑执行。\nSetterFactory SetterFactory 提供 Hystrix 细粒度配置能力，SOFARPC 已提供默认的 DefaultSetterFactory 来生成每个调用方对应的 Setter，如有更定制化的述求，也可以针对每个 ConsumerConfig 提供自定义 SetterFactory。\nSofaHystrixConfig.registerSetterFactory(consumerConfig, new CustomSetterFactory()); 默认提供的实现中 GroupKey 为 InterfaceId，CommandKey 为方法的名称。\n支持 Hystrix 的版本信息 SOFARPC: 5.5.0, SOFABoot: 2.5.3。\nSOAF RPC 集成验证 Hystrix 版本：1.5.12。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-hystrix/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7482dc341bf16dd5671634ffa689604a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault-hystrix/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault-hystrix/","summary":"SOFARPC 已集成 Hystrix 提供熔断能力，当前提供第一个预览版。关于 Hystrix 的更多介绍可以参考 Hystrix 官方文档，Hystrix 集成能力主要由 ScienJus 提供，感谢贡献。 接下来介绍一","tags":null,"title":"Hystrix 客户端熔断","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault-hystrix/","wordcount":552},{"author":null,"categories":null,"content":" Installation guide To use Istio in a non-Kubernetes environment, you must complete the following critical tasks first:\n Configure the Istio API server for the Istio control plane. You can also use MemStore to launch Pilot for demonstration purpose. Manually add SOFAMosn to all microservice instances and start in SideCar mode. Make sure that all requests are routed through SOFAMosn. Set control plane The Istio control plane consists of four main services: Pilot, Mixter, Citadel, and API server.\nAPI server Istio\u0026amp;rsquo;s API server, which is based on Kubernetes API server, provides configuration management and role-based access control. The API server requires an etcd cluster as the underlying persistent storage.\nInstall locally Use the following Docker compose file to install an API server for POC:\nversion: \u0026#39;2\u0026#39; services: etcd: image: quay.io/coreos/etcd:latest networks: default: aliases: - etcd ports: - \u0026amp;quot;4001:4001\u0026amp;quot; - \u0026amp;quot;2380:2380\u0026amp;quot; - \u0026amp;quot;2379:2379\u0026amp;quot; environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;/usr/local/bin/etcd\u0026amp;quot;, \u0026amp;quot;-advertise-client-urls=http://0.0.0.0:2379\u0026amp;quot;, \u0026amp;quot;-listen-client-urls=http://0.0.0.0:2379\u0026amp;quot; ] istio-apiserver: image: gcr.io/google_containers/kube-apiserver-amd64:v1.7.3 networks: default: aliases: - apiserver ports: - \u0026amp;quot;8080:8080\u0026amp;quot; privileged: true environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;kube-apiserver\u0026amp;quot;, \u0026amp;quot;--etcd-servers\u0026amp;quot;, \u0026amp;quot;http://etcd:2379\u0026amp;quot;, \u0026amp;quot;--service-cluster-ip-range\u0026amp;quot;, \u0026amp;quot;10.99.0.0/16\u0026amp;quot;, \u0026amp;quot;--insecure-port\u0026amp;quot;, \u0026amp;quot;8080\u0026amp;quot;, \u0026amp;quot;-v\u0026amp;quot;, \u0026amp;quot;2\u0026amp;quot;, \u0026amp;quot;--insecure-bind-address\u0026amp;quot;, \u0026amp;quot;0.0.0.0\u0026amp;quot; ] Other control plane components Currently, SOFAMosn hasn\u0026amp;rsquo;t integrated with the components other than Pilot, so you don\u0026amp;rsquo;t need to install Mixer, Citadel and other components.\nAdd SOFAMosn Sidecar to microservice instances Every microservice application instance must have an associated SOFAMosn instance.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-installation/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4c0bd56673dc8aebef9011a22496392d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","summary":"Installation guide To use Istio in a non-Kubernetes environment, you must complete the following critical tasks first:\n Configure the Istio API server for the Istio control plane. You can also use MemStore to launch Pilot for demonstration purpose. Manually add SOFAMosn to all microservice instances and start in SideCar mode. Make sure that all requests are routed through SOFAMosn. Set control plane The Istio control plane consists of four main services: Pilot, Mixter, Citadel, and API server.","tags":null,"title":"Installation guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","wordcount":221},{"author":null,"categories":null,"content":" Project address\n Introduction SOFABoot extends the Health Check of Spring Boot. For detailed information, see SOFABoot Documentation. This sample project is intended to demonstrate how to integrate the Health Check component of SOFABoot during merged deployment. Differences between the Health Check in merged deployment and that of a single SOFABoot application are as follows: + During static merged deployment, all Biz packages must pass the Health Check before the Ark package can be started normally. + When deploying the Biz packages dynamically in Jarslink2.0, all packages must pass the Health Check before successful deployment. + In merged deployment, a new check item named multiApplicationHealthChecker will be added when you access Spring Boot\u0026amp;rsquo;s default /health. The item is used to check the health of all Biz packages. Only after all Biz packages pass the Health Check can the merged package pass the Health Check.\nDependency To integrate the Health Check capability of SOFABoot in merged deployment, you need to add the following dependencies:\n\u0026amp;lt;!--health check--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note that spring-boot-starter-web is excluded to avoid starting multiple web applications when you introduce the healthcheck-sofa-boot-starter dependency.\nDemo cd biz-health-check-sample/app-one \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-one root directory and package the application into an Ark or Biz package. The file will be exported to the biz-health-check-sample/app-one/target directory.\n cd biz-health-check-sample/app-two \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-two root directory and package the application into an Ark or Biz package. The file will be exported to the biz-health-check-sample/app-two/target directory.\n Use java -jar to start the Ark package for app-one.\n After the Ark package has started, visit http://localhost:8080/health in the browser. This is Spring Boot\u0026amp;rsquo;s default Health Check endpoint. A new check item named multiApplicationHealthChecker is added in the results and there is now only one Biz package. The page is displayed as follows: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"99832d969ec54b925c3dca1205b95165","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","summary":"Project address\n Introduction SOFABoot extends the Health Check of Spring Boot. For detailed information, see SOFABoot Documentation. This sample project is intended to demonstrate how to integrate the Health Check component of SOFABoot during merged deployment. Differences between the Health Check in merged deployment and that of a single SOFABoot application are as follows: + During static merged deployment, all Biz packages must pass the Health Check before the Ark package can be started normally.","tags":null,"title":"Integrate SOFABoot health check","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","wordcount":389},{"author":null,"categories":null,"content":" Since rpc-sofa-boot-starter version 6.0.1, SOFARPC provide the ability to integrate RESTful service with Swagger easily.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment and you want to enable Swagger support, first, you need add Swagger dependencies in your pom.xml:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Then you need add a configuration com.alipay.sofa.rpc.restSwagger=true in application.properties.\nFinally, visit http://localhost:8341/swagger/openapi and you can get all the Swagger OpenAPI information about SOFARPC\u0026amp;rsquo;s RESTful services.\nIf you are not using rpc-sofa-boot-starter or the version of rpc-sofa-boot-starter you depends is smaller then 6.0.1, you can integration SOFARPC RESTful service with Swagger by using the following tutorial.\nCurrently, SOFARPC does not provide the ability to integrate RESTful service with Swagger via one click. The ability will be provided in future versions, but you can refer to this document to integrate RESTful service with Swagger in the existing versions of SOFARPC.\nFirst, you need to add Swagger related dependencies into your application. Since SOFARPC\u0026amp;rsquo;s RESTful protocol is based on the JAXRS, so you just need to add Swagger\u0026amp;rsquo;s JAXRS dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; The 20.0 version of Guava was added to resolve Guava version conflict.\nAdd a Swagger RESTful service To enable Swagger to expose SOFARPC\u0026amp;rsquo;s RESTful services through Swagger OpenAPI, we can provide Swagger\u0026amp;rsquo;s OpenAPI services through SOFARPC\u0026amp;rsquo;s RESTful services. First, you need to create a new interface:\n@Path(\u0026amp;quot;swagger\u0026amp;quot;) public interface OpenApiService { @GET @Path(\u0026amp;quot;openapi\u0026amp;quot;) @Produces(\u0026amp;quot;application/json\u0026amp;quot;) String openApi(); } Then provide an implementation class and publish it as a RESTful service of SOFARPC:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}, interfaceType = OpenApiService.class) public class OpenApiServiceImpl implements OpenApiService, InitializingBean { private OpenAPI openAPI; @Override public String openApi() { return Json.pretty(openAPI); } @Override public void afterPropertiesSet() { List\u0026amp;lt;Package\u0026amp;gt; resources = new ArrayList\u0026amp;lt;\u0026amp;gt;(); Resources.add(this.getClass().getPackage()); // Scan the package of the current class, or scan the packages of other SOFARPC RESTful service …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-swagger/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d068767fe0dd2922eecef69736684be8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","summary":"Since rpc-sofa-boot-starter version 6.0.1, SOFARPC provide the ability to integrate RESTful service with Swagger easily.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment and you want to enable Swagger support, first, you need add Swagger dependencies in your pom.xml:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.swagger.core.v3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;swagger-jaxrs2\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.0.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.guava\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;guava\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;20.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Then you need add a configuration com.alipay.sofa.rpc.restSwagger=true in application.properties.\nFinally, visit http://localhost:8341/swagger/openapi and you can get all the Swagger OpenAPI information about SOFARPC\u0026rsquo;s RESTful services.","tags":null,"title":"Integrate with Swagger","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","wordcount":462},{"author":null,"categories":null,"content":"Jarslink2.0 supports receiving dynamic commands at runtime to manage the Biz package lifecycle. Before starting an Ark package that has introduced the Jarslink2.0 plugin, you can send commands through the telnet connection protocol with port 1234. For example, execute telnet ip 1234 to enter the Jarslink2.0 command interface and type \u0026amp;ldquo;help\u0026amp;rdquo; in the interface to obtain all relevant command manuals. Next we will introduce the syntax of each Jarslink2.0 command.\n Install the Biz package: The installation command is used to dynamically deploy of applications. Its syntax is install -b $bizFile. You can replace -b with -biz. All Jarslink2.0 commands must contain either a –b or –biz. The \u0026amp;ldquo;install\u0026amp;rdquo; command has only one parameter, the Biz package URI, which can either be the path of a local file or the link to a remote file, for example, install -b file:///Users/qilong.zql/sample-ark-biz.jar.\n Uninstall the Biz package: The uninstall command is used to close the application. The services released by the application and the resources that it occupied will be destroyed. Command syntax: uninstall -b -n $bizName -v $bizVersion. The command must specify the name and version number of the Biz package by -n and -v, which can be replaced with -name and -version. The name and version number of a Biz package are determined at the time of packaging. For detailed information, see Application Packaging.\n Switch the Biz package: The switch command is used for the Biz package hot update to ensure service continuity. Jarslink2.0 allows loading different versions of Biz packages with the same name at runtime. However, only one Biz package can deliver services at one time. To upgrade the loaded Biz package that is delivering services at runtime, execute the installation command to install a later version of the Biz package. After installation, the newer version is inactive because the older version is providing services. Execute the switch command to switch to the newer version without suspending the services that the application is delivering. This is called a hot update. The command syntax is switch -b -n $bizName -v $bizVersion. Parameters are the same as the above.\n Query the Biz package: The query command is used to query the Biz packages installed in JVM and their status. The command syntax is check -b -n $bizName -v $bizVersion, where the Biz package\u0026amp;rsquo;s name and version number are optional parameters. If you do not specify the name and the version number, information for all Biz packages will be returned. If you only specify the name, information for all versions with the specified name will be returned.\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-instruction/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c7e69fe8035b59c0e191538c8ef3da18","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","summary":"Jarslink2.0 supports receiving dynamic commands at runtime to manage the Biz package lifecycle. Before starting an Ark package that has introduced the Jarslink2.0 plugin, you can send commands through the telnet connection protocol with port 1234. For example, execute telnet ip 1234 to enter the Jarslink2.0 command interface and type \u0026ldquo;help\u0026rdquo; in the interface to obtain all relevant command manuals. Next we will introduce the syntax of each Jarslink2.0 command.","tags":null,"title":"Interactive instruction","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","wordcount":424},{"author":null,"categories":null,"content":" Introduction Jarslink2.0 is a functional SOFABoot plugin developed based on SOFAArk. It manages the merged deployment of multiple applications on top of the SOFAArk container, with the following features: + It supports runtime dynamic installation and uninstallation of applications. + It supports runtime application hot replacement capability to ensure service continuity. + For cross-application communication, it supports the JVM services publish and reference. Cross-application communication can base on RPC framework or internal JVM services. + It supports application Health Check.\nBackground At Ant Financial, it is common to deploy multiple applications on top of the same JVM. Main advantages of this approach are as follows:\n Merged deployment of unrelated applications: Some applications have no service dependencies on each other when they are deployed independently and their volume of business is small, so it would be a waste of resources to start the Java Virtual Machine just for them. Merged deployment of these applications can save resources.\n Merged deployment of related applications: Some applications have service dependencies between them. When deployed independently, RPC calls are used between applications. Despite the high stability of the distributed architecture, there are still delays caused by network jitter. By merged deployment of these applications, JVM internal calls will replace RPC calls, which reduces the call overhead.\n Not only is there merged deployment between applications, but the near-client package has the same appeal.\nThe near-client package is a three-party component that provides a series of public services, normally introduced by the application as a dependency. This development mode is likely to cause two problems:\n The three-party dependency that is introduced by the near-client package conflicts with the dependency of the application itself, so an isolated deployment is expected.\n Since the near-client package is introduced by the application as a dependency, any upgrade of the near-client package will require upgrade of the application as well. However, as a common functional component, many business applications rely on the near-client package as a dependency, which entails a huge amount of transformation. Consequently, a dynamic upgrade of the near-client package is expected.\n In addition to merged deployment, many Ant Financial business scenarios require hot deployment of modules, that is, when the application is running, a specific module needs to be dynamically replaced without affecting the normal running of other modules.\nJarslink2.0 is designed to solve such problems. It is an Ark Plugin developed based on SOFAArk and used to manage the merged deployment of multiple applications. Before getting to know Jarslink2.0, you need to understand the SOFAArk framework. For detailed information of SOFAArk, visit the link.\nPrinciple Jarslink2.0 is an Ark Plugin developed based on SOFAArk. Assuming that you …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-readme/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"48a4bc23f10f1ecca3960aecfd0a77d5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","summary":"Introduction Jarslink2.0 is a functional SOFABoot plugin developed based on SOFAArk. It manages the merged deployment of multiple applications on top of the SOFAArk container, with the following features: + It supports runtime dynamic installation and uninstallation of applications. + It supports runtime application hot replacement capability to ensure service continuity. + For cross-application communication, it supports the JVM services publish and reference. Cross-application communication can base on RPC framework or internal JVM services.","tags":null,"title":"Introduction to Jarslink","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","wordcount":651},{"author":null,"categories":null,"content":" Pilot introduction The SOFAMesh project forked the Istio project to enhance Pilot\u0026amp;rsquo;s capabilities. Currently, the ongoing enhancements are focused on the following three areas:\n Support ZooKeeper as a registry center, and support SOFA, DUBBO and other microservice frameworks using ZooKeeper as a registry center. Support the common protocol framework. Use a common protocol, and support multiple protocols simultaneously based on Kubernetes DNS. Add register agent to support the container models of SOFA, Dubbo and HSF. Namely, a single application can register multiple service instances. ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-readme/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7b098e394986596d8fb01e1fe2120829","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","summary":"Pilot introduction The SOFAMesh project forked the Istio project to enhance Pilot\u0026rsquo;s capabilities. Currently, the ongoing enhancements are focused on the following three areas:\n Support ZooKeeper as a registry center, and support SOFA, DUBBO and other microservice frameworks using ZooKeeper as a registry center. Support the common protocol framework. Use a common protocol, and support multiple protocols simultaneously based on Kubernetes DNS. Add register agent to support the container models of SOFA, Dubbo and HSF.","tags":null,"title":"Introduction to Pilot","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","wordcount":84},{"author":null,"categories":null,"content":" ## Product description SOFAArk is a light-weight，java based classloader isolation framework open sourced by Ant Financial. Based on Fat Jar technology, the container can pack simple single-module Java applications or Spring Boot applications into a self-contained executable Fat Jar, known as an Ark package. When the java -jar command is used to start an Ark package embedded with the SOFAArk class isolation container, the SOFAArk container will start, and it then starts each Ark plugin and application. If you want to merge multi app into one jvm, please go and refer to koupleless which based on SOFAArk; if you want to just isolate class by classLoader then you can read docs in this site, and focus on sofaArk Plugin.\nBackground In Java world, dependency is always a problem, and can cause various errors, such as LinkageError, NoSuchMethodError etc. There are many ways to solve the dependency problems, the Spring Boot\u0026amp;rsquo;s way is using a dependency management to manage all the dependencies, make sure that all the dependencies in the dependency management will not conflict and can work pretty well. This is quite a simple and efficient way, it can cover most scenario, but there is some exceptions.\nFor example, there is a project that need protobuf version 2 and protobuf version 3, and because protobuf version 3 is not compatible with version 2, so the project can not simply upgrade the protobuf to version 3 to solve the problem. There is same problem for hessian version 3 and version 4.\nTo cover those exceptions, we need to introduce a classloader isolation way, make different version of a framework loaded by different classloader. There are many framework that can do classloader isolation, perhaps the most famous one is OSGi, but OSGi classloader schema is too complex, beside classloader isolation, it also has ability to do hot deploy and a lot of other functionalities that we actually don\u0026amp;rsquo;t want.\nSo this is the origin of SOFAArk, it\u0026amp;rsquo;s goal is to use a light-weight classloader isolation mechanism to solve the problem that Spring Boot did not solve. And just a remind that SOFAArk is not bind to Spring Boot, actually it is a more general classloader isolation framework that can be used with any other frameworks too.\nHow SOFAArk Works There are three concepts in SOFAArk: Ark Container, Ark-Plugin and Ark-Biz; they are organized as what the following graph shows:\n First of all, we explain what roles these concepts play;\n Ark Container: It\u0026amp;rsquo;s the runtime manager of total framework; it will startup in the first place, then it resolves Ark Plugin and Ark Biz in classpath and deploys them.\n Ark Plugin: A fat jar packaged by sofa-ark-plugin-maven-plugin, generally it would bring with a class-index configuration which describes what class would be exported and imported. Ark Plugin can resolve classes from each other.\n Ark Biz: A fat jar packaged by sofa-ark-maven-plugin, it mainly contains all staff what a project need in runtime. Ark Biz …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-readme/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"cdb6729fc7a63954b7559c8ea319f550","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","summary":"## Product description SOFAArk is a light-weight，java based classloader isolation framework open sourced by Ant Financial. Based on Fat Jar technology, the container can pack simple single-module Java applications or Spring Boot applications into a self-contained executable Fat Jar, known as an Ark package. When the java -jar command is used to start an Ark package embedded with the SOFAArk class isolation container, the SOFAArk container will start, and it then starts each Ark plugin and application.","tags":null,"title":"Introduction to SOFAArk","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","wordcount":684},{"author":null,"categories":null,"content":" MOSN, the short name of Modular Observable Smart Network, is a powerful proxy acting as Service Mesh\u0026amp;rsquo;s data plane like Envoy but written in Go. MOSN supports Envoy and Istio\u0026amp;rsquo;s APIs and can be integrated with Istio, so we use MOSN instead of Envoy in SOFAMesh. The initial version of MOSN was jointly contributed by Ant Financial and UC Business Unit of Alibaba, and we look forward to the community to participate in the follow-up development and build an open source excellent project together.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/sofa-mosn-readme/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"11219bb3b9689ec5f328b8281bd62a95","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","summary":"MOSN, the short name of Modular Observable Smart Network, is a powerful proxy acting as Service Mesh\u0026rsquo;s data plane like Envoy but written in Go. MOSN supports Envoy and Istio\u0026rsquo;s APIs and can be integrated with Istio, so we use MOSN instead of Envoy in SOFAMesh. The initial version of MOSN was jointly contributed by Ant Financial and UC Business Unit of Alibaba, and we look forward to the community to participate in the follow-up development and build an open source excellent project together.","tags":null,"title":"Introduction to SOFAMosn","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","wordcount":223},{"author":null,"categories":null,"content":" Introduction to RheaKV RheaKV is a lightweight, distributed, and embedded KV storage library, which is included in the JRaft project as a submodule.\nFeatures\n Embedded: RheaKV is embedded in applications in the form of Jar files. Strong consistency: RheaKV ensures data reliability and consistency based on the multi-raft distributed consensus protocol. Self-driven (not fully implemented at present): RheaKV supports automatic diagnosis, optimization, decision making, and recovery. Monitorable: RheaKV automatically reports meta information and state information by node to the PD. Basic APIs: get, put, and delete; cross-region APIs: scan, batch put, and distributed lock. Architecture design Terms and definitions PD: The global central master node that is responsible for scheduling the entire cluster. A PD server can manage multiple clusters, with each of them isolated by clusterId. The PD server requires separate deployment. Actually, many scenarios do not need automatic cluster management, and RheaKV does not support PD. Store: A physical storage node within a cluster. A store may contain one or more regions. Region: The minimal KV data unit. Each region can be understood as a database partition or database shard, and has a left closed and right open interval [startKey, endKey). Storage design The storage layer adopts a pluggable design and supports both MemoryDB and RocksDB currently: MemoryDB is implemented based on ConcurrentSkipListMap and provides better performance. However, its independent storage capacity is restricted by the memory. RocksDB is suitable for scenarios with large data volumes, because its storage capacity is only restricted by the disk. Strong data consistency is ensured. RheaKV synchronizes data to other replicas with the help of JRaft, and each data change is recorded as a Raft log entry. The log replication feature of Raft ensures all data is securely and reliably synchronized to all nodes within the same Raft group. Scenarios Lightweight state/meta information storage and cluster synchronization Distributed lock service API description Generally, RheaKV APIs are divided into two types: synchronous APIs and asynchronous APIs. Methods whose names start with letter b (block) are synchronous blocking APIs, and the rest are asynchronous APIs. All asynchronous APIs return the same CompletableFuture parameter. The read method may contain another important parameter, that is readOnlySafe. When this parameter is set to true, linearizable read is supported. Read methods that do not contain this parameter provide linearizable read by default.\nget CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key, final boolean readOnlySafe); byte[] bGet(final byte[] key); byte[] bGet(final String key); byte[] bGet(final byte[] key, final boolean …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-rheakv-user-guide/","fuzzywordcount":4100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e6fa7125455982961214dfe82245be4d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":20,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","summary":"Introduction to RheaKV RheaKV is a lightweight, distributed, and embedded KV storage library, which is included in the JRaft project as a submodule.\nFeatures\n Embedded: RheaKV is embedded in applications in the form of Jar files. Strong consistency: RheaKV ensures data reliability and consistency based on the multi-raft distributed consensus protocol. Self-driven (not fully implemented at present): RheaKV supports automatic diagnosis, optimization, decision making, and recovery. Monitorable: RheaKV automatically reports meta information and state information by node to the PD.","tags":null,"title":"JRaft RheaKV user guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","wordcount":4086},{"author":null,"categories":null,"content":" RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 lib， rheaKV 包含在 jraft 项目中，是 jraft 的一个子模块。\n定位与特性\n 嵌入式: jar 包方式嵌入到应用中 强一致性: 基于 multi-raft 分布式一致性协议保证数据可靠性和一致性 自驱动 （目前未完全实现）: 自诊断, 自优化, 自决策, 自恢复 可监控: 基于节点自动上报到PD的元信息和状态信息 基本API: get/put/delete 和跨分区 scan/batch put, distributed lock 等等 架构设计 功能名词 PD: 全局的中心总控节点，负责整个集群的调度，一个 PD server 可以管理多个集群，集群之间基于 clusterId 隔离；PD server 需要单独部署，当然，很多场景其实并不需要自管理，rheaKV 也支持不启用 PD Store: 集群中的一个物理存储节点，一个 store 包含一个或多个 region Region: 最小的 KV 数据单元，可理解为一个数据分区或者分片，每个 region 都有一个左闭右开的区间 [startKey, endKey) 存储设计 存储层为可插拔设计， 目前支持 MemoryDB 和 RocksDB 两种实现： MemoryDB 基于 ConcurrentSkipListMap 实现，有更好的性能，但是单机存储容量受内存限制 RocksDB 在存储容量上只受磁盘限制，适合更大数据量的场景 数据强一致性， 依靠 jraft 来同步数据到其他副本, 每个数据变更都会落地为一条 raft 日志, 通过 raft 的日志复制功能, 将数据安全可靠地同步到同 group 的全部节点中 使用场景 轻量级的状态/元信息存储以及集群同步 分布式锁服务 API 说明 整体上 rheaKV apis 分为异步和同步两类， 其中以 b （block）开头的方法均为同步阻塞方法， 其他为异步方法，异步方法均返回一个 CompletableFuture，对于 read method， 还有一个重要参数 readOnlySafe，为 true 时表示提供线性一致读， 不包含该参数的 read method 均为默认提供线性一致读\nget CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key, final boolean readOnlySafe); byte[] bGet(final byte[] key); byte[] bGet(final String key); byte[] bGet(final byte[] key, final boolean readOnlySafe); byte[] bGet(final String key, final boolean readOnlySafe); String 类型入参，rheaKV 内部提供了更高效的 Utf8String encoder/decoder， 业务 key 为 String 时， 推荐的做法是直接使用 String 参数的接口 不需要线性一致读语义的场景可以将 readOnlySafe 设置为 false， 负载均衡器会优先选择本地调用，本地不能提供服务则轮询选择一台远程机器发起读请求 multiGet CompletableFuture\u0026amp;lt;Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt;\u0026amp;gt; multiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys); CompletableFuture\u0026amp;lt;Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt;\u0026amp;gt; multiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys, final boolean readOnlySafe); Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt; bMultiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys); Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt; bMultiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys, final boolean readOnlySafe); multiGet 支持跨分区查询，rheaKV 内部会自动计算每个 key 的所属分区（region）并行发起调用， 最后合并查询结果 为了可以将 byte[] 放进 HashMap，这里曲线救国，返回值中 Map 的 key 为 ByteArray 对象，是对 byte[] 的一层包装，实现了 byte[] 的 hashCode scan \u0026amp;amp; iterator CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final byte[] startKey, final byte[] endKey); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final String startKey, final String endKey); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final byte[] startKey, final byte[] endKey, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final String startKey, final String endKey, final boolean readOnlySafe); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final byte[] startKey, final byte[] endKey); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final String startKey, final String endKey); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final byte[] startKey, final byte[] endKey, final boolean readOnlySafe); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final String startKey, final String endKey, final boolean readOnlySafe); RheaIterator\u0026amp;lt;KVEntry\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-rheakv-user-guide/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e6fa7125455982961214dfe82245be4d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":13,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","summary":"RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 lib， rheaKV 包含在 jraft 项目中，是 jraft 的一个子模块。 定位与特性 嵌入式: jar 包方式嵌入到应用中 强一致性: 基于 multi-raft 分布","tags":null,"title":"JRaft RheaKV 用户指南","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","wordcount":6408},{"author":null,"categories":null,"content":" 0. Basic concepts Every request submitted by log index to a Raft group is serialized into a log entry. Each log entry has an ID, which monotonically increases within the Raft group, and the log entries are replicated to every Raft node in the group. Term is a long-type number that monotonically increases within the Raft group. You can simply take it as the number of votes. The term of an elected leader is called the leader term. Before this leader steps down, log entries submitted during this period have the same term. 1. Configuration and supporting classes This topic mainly describes the configuration and utility methods and classes. The core objects are:\n Endpoint, which refers to a service address PeerId, which refers to ID of a Raft node Configuration, which refers to the configuration of a Raft group, or a node list in other words. 1.1 Endpoint Endpoint refers to a service address, including the IP address and the port number. Raft nodes must not be started on the IPv4 address 0.0.0.0. The startup IP address must be clearly specified Create a address, and bind it to port 8080 of the local host, as shown in the following example:\nEndpoint addr = new Endpoint(\u0026amp;quot;localhost\u0026amp;quot;, 8080); String s = addr.toString(); // The result is localhost:8080 PeerId peer = new PeerId(); boolean success = peer.parse(s); // Specifies whether parsing the endpoint from a string is supported. The result is true. 1.2 PeerId A PeerId indicates a participant (leader, follower, or candidate) of the Raft protocol. It comprises three elements in the format of ip:port:index, where ip is the IP address of the node, port is the port number, and index is the serial number of the same port. Currently, the index is not used, and is always set to 0. This field is reserved to allow starting different Raft nodes from the same port and to differentiate them by index.\nCreate a PeerId and set the index to 0, the IP to localhost, and the port to 8080:\nPeerId peer = new PeerId(\u0026amp;quot;localhost\u0026amp;quot;, 8080); EndPoint addr = peer.getEndpoint(); // Gets the endpoint of a node int index = peer.getIdx(); // Gets the index of a node, which is always set to 0 currently String s = peer.toString(); // The result is localhost:8080 boolean success = peer.parse(s); // Specifies whether PeerId parsing from a string is supported. The result is true. 1.3 Configuration It refers to the configuration of a Raft group, or a participant list in other words.\nPeerId peer1 = ... PeerId peer2 = ... PeerId peer3 = ... // A Raft group that consists of three nodes Configuration conf = new Configuration(); conf.addPeer(peer1); conf.addPeer(peer2); conf.addPeer(peer3); 1.4 JRaftUtils utility class To enable users conveniently create objects such as Endpoint, PeerId, and Configuration, Jraft provides the JRaftUtils class to help users quickly create the required objects from strings.\nEndpoint addr = JRaftUtils.getEndpoint(\u0026amp;quot;localhost:8080\u0026amp;quot;); PeerId peer = …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-user-guide/","fuzzywordcount":8400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"105dfa34c3b20df1f2c23c112730507d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":39,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","summary":"0. Basic concepts Every request submitted by log index to a Raft group is serialized into a log entry. Each log entry has an ID, which monotonically increases within the Raft group, and the log entries are replicated to every Raft node in the group. Term is a long-type number that monotonically increases within the Raft group. You can simply take it as the number of votes. The term of an elected leader is called the leader term.","tags":null,"title":"JRaft user guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","wordcount":8306},{"author":null,"categories":null,"content":" 1. 基本概念说明 log index 提交到 raft group 中的任务都将序列化为一条日志存储下来，每条日志一个编号，在整个 raft group 内单调递增并复制到每个 raft 节点。 term 在整个 raft group 中单调递增的一个 long 数字，可以简单地认为表示一轮投票的编号，成功选举出来的 leader 对应的 term 称为 leader term，在这个 leader 没有发生变更的阶段内提交的日志都将拥有相同的 term 编号。 2. 配置和辅助类 本节主要介绍 jraft 的配置和辅助工具相关接口和类。核心包括：\n Endpoint 表示一个服务地址。 PeerId 表示一个 raft 参与节点。 Configuration 表示一个 raft group 配置，也就是节点列表。 2.1 地址 Endpoint Endpoint 表示一个服务地址，包括 IP 和端口， raft 节点不允许启动在 0.0.0.0 所有的 IPv4 上，需要明确指定启动的 IP 创建一个地址，绑定在 localhost 的 8080 端口上，如下例：\nEndpoint addr = new Endpoint(\u0026amp;quot;localhost\u0026amp;quot;, 8080); String s = addr.toString(); // 结果为 localhost:8080 PeerId peer = new PeerId(); boolean success = peer.parse(s); // 可以从字符串解析出地址，结果为 true 2.2 节点 PeerId PeerId 表示一个 raft 协议的参与者（leader/follower/candidate etc.)， 它由三元素组成： ip:port:index， IP 就是节点的 IP， port 就是端口， index 表示同一个端口的序列号，目前没有用到，总被认为是 0。预留此字段是为了支持同一个端口启动不同的 raft 节点，通过 index 区分。\n创建一个 PeerId, index 指定为 0， ip 和端口分别是 localhost 和 8080:\nPeerId peer = new PeerId(\u0026amp;quot;localhost\u0026amp;quot;, 8080); Endpoint addr = peer.getEndpoint(); // 获取节点地址 int index = peer.getIdx(); // 获取节点序号，目前一直为 0 String s = peer.toString(); // 结果为 localhost:8080 boolean success = peer.parse(s); // 可以从字符串解析出 PeerId，结果为 true 2.3 配置 Configuration Configuration 表示一个 raft group 的配置，也就是参与者列表：\nPeerId peer1 = ... PeerId peer2 = ... PeerId peer3 = ... // 由 3 个节点组成的 raft group Configuration conf = new Configuration(); conf.addPeer(peer1); conf.addPeer(peer2); conf.addPeer(peer3); 2.4 工具类 JRaftUtils 为了方便创建 Endpoint/PeerId/Configuration 等对象， jraft 提供了 JRaftUtils 来快捷地从字符串创建出所需要的对象：\nEndpoint addr = JRaftUtils.getEndpoint(\u0026amp;quot;localhost:8080\u0026amp;quot;); PeerId peer = JRaftUtils.getPeerId(\u0026amp;quot;localhost:8080\u0026amp;quot;); // 三个节点组成的 raft group 配置，注意节点之间用逗号隔开 Configuration conf = JRaftUtils.getConfiguration(\u0026amp;quot;localhost:8081,localhost:8082,localhost:8083\u0026amp;quot;); 2.5 回调 Closure 和状态 Status Closure 就是一个简单的 callback 接口， jraft 提供的大部分方法都是异步的回调模式，结果通过此接口通知：\npublic interface Closure { /** * Called when task is done. * * @param status the task status. */ void run(Status status); } 结果通过 Status 告知，Status#isOk() 告诉你成功还是失败，错误码和错误信息可以通过另外两个方法获取：\nboolean success= status.isOk(); RaftError error = status.getRaftError(); // 错误码，RaftError 是一个枚举类 String errMsg = status.getErrorMsg(); // 获取错误详情 Status 提供了一些方法来方便地创建：\n// 创建一个成功的状态 Status ok = Status.OK(); // 创建一个失败的错误，错误信息支持字符串模板 String filePath = \u0026amp;quot;/tmp/test\u0026amp;quot;; Status status = new Status(RaftError.EIO, \u0026amp;quot;Fail to read file from %s\u0026amp;quot;, filePath); 2.6 任务 Task Task 是用户使用 jraft 最核心的类之一，用于向一个 raft 复制分组提交一个任务，这个任务提交到 leader，并复制到其他 follower 节点， Task 包括：\n ByteBuffer data 任务的数据，用户应当将要复制的业务数据通过一定序列化方式（比如 java/hessian2) 序列化成一个 ByteBuffer，放到 task 里。 long expectedTerm = -1 任务提交时预期的 leader term，如果不提供(也就是默认值 -1 )，在任务应用到状态机之前不会检查 leader 是否发生了变更，如果提供了（从状态机回调中获取，参见下文），那么在将任务应用到状态机之前，会检查 term 是否匹配，如果不匹配将拒绝该任务。 Closure done 任务的回调，在任务完成的时候通知此对象，无论成功还是失败。这个 closure 将在 StateMachine#onApply(iterator) 方法应用到状态机的时候，可以拿到并调用，一般用于客户端应答的返回。 创建一个简单 Task 实例：\nClosure done = ...; Task task = new …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-user-guide/","fuzzywordcount":13200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"105dfa34c3b20df1f2c23c112730507d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":27,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","summary":"1. 基本概念说明 log index 提交到 raft group 中的任务都将序列化为一条日志存储下来，每条日志一个编号，在整个 raft group 内单调递增并复制到每个 raft 节点。 term 在整个 raft group 中单","tags":null,"title":"JRaft 用户指南","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","wordcount":13134},{"author":null,"categories":null,"content":" SOFABoot 提供三种方式给开发人员发布和引用 JVM 服务\n XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上面的 Bean 发布成一个 SOFA JVM 服务。\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 上面的配置中的 interface 指的是需要发布成服务的接口，ref 指向的是需要发布成 JVM 服务的 Bean，至此，我们就已经完成了一个 JVM 服务的发布。\n服务引用 使用 SOFA 提供的 Spring 扩展标签引用服务:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上面的配置中的 interface 是服务的接口，需要和发布服务时配置的 interface 一致。id 属性的含义同 Spring BeanId。上面的配置会生成一个 id 为 sampleServiceRef 的 Spring Bean，你可以将 sampleServiceRef 这个 Bean 注入到当前 SOFABoot 模块 Spring 上下文的任意地方。\n service/reference 标签还支持 RPC 服务发布，相关文档: RPC 服务发布与引用\n Annotation 方式 警告\n如果一个服务已经被加上了 @SofaService 的注解，它就不能再用 XML 的方式去发布服务了，选择一种方式发布服务，而不是两种混用。\n 除了通过 XML 方式发布 JVM 服务和引用之外，SOFABoot 还提供了 Annotation 的方式来发布和引用 JVM 服务。通过 Annotation 方式发布 JVM 服务，只需要在实现类上加一个 @SofaService 注解即可，如下：\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } 提示\n@SofaService 的作用是将一个 Bean 发布成一个 JVM 服务，这意味着虽然你可以不用再写 \u0026amp;lt;sofa:service/\u0026amp;gt; 的配置，但是还是需要事先将 @SofaService 所注解的类配置成一个 Spring Bean。\n 在使用 XML 配置 \u0026amp;lt;sofa:service/\u0026amp;gt; 的时候，我们配置了一个 interface 属性，但是在使用 @SofaService 注解的时候，却没有看到有配置服务接口的地方。这是因为当被 @SofaService 注解的类只有一个接口的时候，框架会直接采用这个接口作为服务的接口。当被 @SofaService 注解的类实现了多个接口时，可以设置 @SofaService 的 interfaceType 字段来指定服务接口，比如下面这样：\n@SofaService(interfaceType=SampleInterface.class) public class SampleImpl implements SampleInterface, Serializable { public void test() { } } 和 @SofaService 对应，Sofa 提供了 @SofaReference 来引用一个 JVM 服务。假设我们需要在一个 Spring Bean 中使用 SampleJvmService 这个 JVM 服务，那么只需要在字段上加上一个 @SofaReference 的注解即可：\npublic class SampleServiceRef { @SofaReference private SampleService sampleService; } 和 @SofaService 类似，我们也没有在 @SofaReference 上指定服务接口，这是因为 @SofaReference 在不指定服务接口的时候，会采用被注解字段的类型作为服务接口，你也可以通过设定 @SofaReference 的 interfaceType 属性来指定：\npublic class SampleServiceRef { @SofaReference(interfaceType=SampleService.class) private SampleService sampleService; } 使用 @SofaService 注解发布服务时，需要在实现类上打上 @SofaService 注解；在 Spring Boot 使用 Bean Method 创建 Bean 时，会导致 @Bean 和 @SofaService 分散在两处，而且无法对同一个实现类使用不同的 unique id。因此自 SOFABoot v2.6.0 及 v3.1.0 版本起，支持 @SofaService 作用在 Bean Method 之上，例如：\n@Configuration public class SampleSofaServiceConfiguration { @Bean(\u0026amp;quot;sampleSofaService\u0026amp;quot;) @SofaService(uniqueId = \u0026amp;quot;service1\u0026amp;quot;) SampleService service() { return new SampleServiceImpl(\u0026amp;quot;\u0026amp;quot;); } } 同样为了方便在 Spring Boot Bean Method 使用注解 @SofaReference 引用服务，自 SOFABoot v2.6.0 及 v3.1.0 版本起，支持在 Bean Method 参数上使用 @SofaReference 注解引用 JVM 服务，例如：\n@Configuration public class MultiSofaReferenceConfiguration { @Bean(\u0026amp;quot;sampleReference\u0026amp;quot;) TestService …","date":-62135596800,"description":"","dir":"projects/sofa-boot/module-service/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"527472fbe57ce450e4e2b41d878704cb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/module-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/module-service/","summary":"SOFABoot 提供三种方式给开发人员发布和引用 JVM 服务 XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean： \u0026lt;bean id=\u0026quot;sampleService\u0026quot; class=\u0026quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026quot;\u0026gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上","tags":null,"title":"JVM 服务发布与引用","type":"projects","url":"/sofastack.tech/projects/sofa-boot/module-service/","wordcount":1926},{"author":null,"categories":null,"content":" 1. Create a Maven project and import the dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. Create the SOFARegistry client instance The key code for creating the SOFARegistry client instance is as follows:\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); Properties related to SOFARegistry are specified by the DefaultRegistryClientConfigBuilder class, which provides the following key properties:\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } Property Type Description instanceId String The ID of the instance. Default value: DEFAULT_INSTANCE_ID. The same instance ID must be used for data publishing and subscription. The unique data identifier consists of dataId+group+instanceId. zone String The zone where the instance is located. Default value: DEFAULT_ZONE. registryEndpoint String The endpoint of any session node of the servers. registryEndpointPort Integer The session.server.httpServerPort configured for a session node. Default value: 9603. dataCenter String The data center of SOFARegistry. Default value: DefaultDataCenter. appName String The name of the app that accesses SOFARegistry. connectTimeout Integer Specifies the timeout for establishing a connection with a server. Default value: 3000 ms. socketTimeout Integer Specifies the timeout for accessing the servers\u0026amp;rsquo; REST API. Default value: 3000 ms. invokeTimeout Integer Specifies the timeout for calling services on the servers. Default value: 1000 ms. recheckInterval Integer Specifies the interval for checking the task queue. Default value: 500 ms. observerThreadCoreSize Integer Specifies the number of core threads in the thread pool that process data pushed from the servers. Default value: 5. observerThreadMaxSize Integer Specifies the maximum number of threads in the thread pool that process data pushed from the servers. Default value: 10. observerThreadQueueLength Integer Specifies the maximum thread queue length of the thread pool that processes data pushed from the servers. Default value: 1000. syncConfigRetryInterval Integer Specifies the retry interval to synchronize the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/java-sdk/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"32cff5cc5d89ffa85b12c207a1c0c6f3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/java-sdk/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/java-sdk/","summary":"1. Create a Maven project and import the dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. Create the SOFARegistry client instance The key code for creating the SOFARegistry client instance is as follows:\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); Properties related to SOFARegistry are specified by the DefaultRegistryClientConfigBuilder class, which provides the following key properties:\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } Property Type Description instanceId String The ID of the instance.","tags":null,"title":"Java SDK","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/java-sdk/","wordcount":890},{"author":null,"categories":null,"content":" 1. Maven 坐标 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. 创建 SOFARegistry 客户端实例 构建 SOFARegistry 客户端实例的关键代码如下：\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); 其中注册中心相关的属性通过 DefaultRegistryClientConfigBuilder 构建指定，该类包含以下关键属性：\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } 属性名 属性类型 描述 instanceId String 实例ID，发布订阅时需要使用相同值，数据唯一标识由dataId+group+instanceId组成，默认值 DEFAULT_INSTANCE_ID。 zone String 单元化所属 zone，默认值 DEFAULT_ZONE。 registryEndpoint String 服务端任一 Session 节点地址。 registryEndpointPort int Session 节点配置的 session.server.httpServerPort 端口值，默认值 9603。 dataCenter String 数据中心，默认值 DefaultDataCenter。 appName String 应用名。 connectTimeout int 与服务端建立连接超时时间，默认值 3000ms。 socketTimeout int 访问服务端 REST 接口超时时间，默认值 3000ms。 invokeTimeout int 调用服务端服务超时时间，默认值 1000ms。 recheckInterval int 检测任务队列间隔时间，默认值 500ms。 observerThreadCoreSize int 处理服务端推送数据线程池核心线程大小，默认值 5。 observerThreadMaxSize int 处理服务端推送数据线程池最大线程大小，默认值 10。 observerThreadQueueLength int 处理服务端推送数据线程池队列大小，默认值 1000。 syncConfigRetryInterval int 同步服务端列表间隔时间，默认值 30000ms。 3. 发布数据 发布数据的关键代码如下：\n// 构造发布者注册表 PublisherRegistration registration = new PublisherRegistration(\u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); // 将注册表注册进客户端并发布数据 Publisher publisher = registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); // 如需覆盖上次发布的数据可以使用发布者模型重新发布数据 publisher.republish(\u0026amp;quot;10.10.1.1:12200?xx=zz\u0026amp;quot;); 发布数据的关键是构造 PublisherRegistration，该类包含三个属性：\n 属性名 属性类型 描述 dataId String 数据ID，发布订阅时需要使用相同值，数据唯一标识由 dataId + group + instanceId 组成。 group String 数据分组，发布订阅时需要使用相同值，数据唯一标识由 dataId + group + instanceId 组成，默认值 DEFAULT_GROUP。 appName String 应用 appName。 4. 订阅数据 订阅数据的关键代码如下：\n// 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { @Override public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, …","date":-62135596800,"description":"","dir":"projects/sofa-registry/java-sdk/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"32cff5cc5d89ffa85b12c207a1c0c6f3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/java-sdk/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/java-sdk/","summary":"1. Maven 坐标 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. 创建 SOFARegistry 客户端实例 构建 SOFARegistry 客户端实例的关键代码如下： RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); 其中注册中心相关的属性通过 DefaultRegistryClientConfigBuilder 构建指定，该类包含以下关","tags":null,"title":"Java SDK","type":"projects","url":"/sofastack.tech/projects/sofa-registry/java-sdk/","wordcount":1368},{"author":null,"categories":null,"content":"In addition to hundreds of unit tests and some chaos tests, SOFAJRaft also uses a distributed verification and fault injection testing framework Jepsen to simulate many cases, and has passed all these tests:\n Randomized partitioning with two partitions: a big one and a small one Randomly adding and removing nodes Randomly stopping and starting nodes Randomly kill -9 and starting nodes Randomly dividing a cluster into two groups, with one node connection the two to simulate network partitioning Randomly dividing a cluster into different majority groups sofa-jraft-jepsen project address\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jepson-test/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c60bc5083fdf888f6eef5b344b1ad157","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jepson-test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jepson-test/","summary":"In addition to hundreds of unit tests and some chaos tests, SOFAJRaft also uses a distributed verification and fault injection testing framework Jepsen to simulate many cases, and has passed all these tests:\n Randomized partitioning with two partitions: a big one and a small one Randomly adding and removing nodes Randomly stopping and starting nodes Randomly kill -9 and starting nodes Randomly dividing a cluster into two groups, with one node connection the two to simulate network partitioning Randomly dividing a cluster into different majority groups sofa-jraft-jepsen project address","tags":null,"title":"Jepsen tests","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jepson-test/","wordcount":89},{"author":null,"categories":null,"content":"除了几百个单元测试以及部分 chaos 测试之外, SOFAJRaft 还使用 jepsen 这个分布式验证和故障注入测试框架模拟了很多种情况，都已验证通过：\n 随机分区，一大一小两个网络分区 随机增加和移除节点 随机停止和启动节点 随机 kill -9 和启动节点 随机划分为两组，互通一个中间节点，模拟分区情况 随机划分为不同的 majority 分组 sofa-jraft-jepsen 项目地址\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jepson-test/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c60bc5083fdf888f6eef5b344b1ad157","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jepson-test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jepson-test/","summary":"除了几百个单元测试以及部分 chaos 测试之外, SOFAJRaft 还使用 jepsen 这个分布式验证和故障注入测试框架模拟了很多种情况，都已验证通过： 随机分区，一大一小两个网络分","tags":null,"title":"Jepsen 验证","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jepson-test/","wordcount":137},{"author":null,"categories":null,"content":"In the Interactive Instructions section, we have described the set of instructions that Jarslink2.0 supports. In this section, we will focus on all the possible state transitions behind these instructions in the following diagram of a Biz package being loaded from a static file to the runtime and to being uninstalled.\nThe diagram above basically shows the complete life cycle of a Biz package. Now we will explain the direction of each state transition in the diagram:\n Label 1: Execute the install instruction, and Jarslink2.0 will resolve the file format. If the format is correct, it is the Biz package file, and the Biz package will be registered and installed.\n Label 2: When the Biz package is successfully installed, the Biz package\u0026amp;rsquo;s main function is executed, the Spring context is loaded successfully, and passes the health check. If Biz packages with the same name but different versions are detected to be activated, the Biz package state will be set to an inactive state. The JVM services that are published by an inactive Biz package will not be called.\n Label 3: When the Biz package is successfully installed, the Biz package\u0026amp;rsquo;s main function is executed, the Spring context is loaded successfully, and passes the health check. If Biz packages with the same name but different versions are detected to be activated, the Biz package state will be set as active and can provide services.\n Label 4: If there are any exceptions or a health check failure, the Biz package state will be set to broken. During the installation, the resources that the Biz package occupies will be quickly released and unregistered, at which point the Biz state will be set to unresolved.\n Label 5: When running, Jarslink2.0 can load Biz packages with the same name but different versions, but only one Biz package is in the active state and can provide services. Execute the switch instruction, and the two Biz packages\u0026amp;rsquo; states will be interchanged.\n Label 6: Execute the uninstallation instruction, the Biz package will be uninstalled, and its occupied resources and published services will be unregistered.\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0f166dd5388f3dc7d968bce31d0f6e4f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","summary":"In the Interactive Instructions section, we have described the set of instructions that Jarslink2.0 supports. In this section, we will focus on all the possible state transitions behind these instructions in the following diagram of a Biz package being loaded from a static file to the runtime and to being uninstalled.\nThe diagram above basically shows the complete life cycle of a Biz package. Now we will explain the direction of each state transition in the diagram:","tags":null,"title":"Lifecycle","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","wordcount":346},{"author":null,"categories":null,"content":" The link data transparent transmission function allows the applications to store data in the calling context, and then any applications in the entire link can operate the data. This feature is used as follows. Data can be put into the request and response of the link for transparent transmission, and then the applications can get the corresponding data from the link.\nRpcInvokeContext.getContext().putRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;,\u0026amp;quot;value_request\u0026amp;quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;,\u0026amp;quot;value_response\u0026amp;quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;); Example For example, in the scenario of A -\u0026amp;gt; B -\u0026amp;gt; C, the request arguments set by A are transmitted to B and C. On return, response arguments of C and B are transmitted to A.\nRequester A is set as follows:\n// Set the value of the request transparently before calling RpcInvokeContext context = RpcInvokeContext.getContext(); context.putRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;, \u0026amp;quot;a2bbb\u0026amp;quot;); // Call service String result = service.hello(); // Get the result value context.getResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;); Business code for B is as follows:\npublic String hello() { / / Get the value of the request transparent transmission RpcInvokeContext context = RpcInvokeContext.getContext(); String reqBaggage = context.getRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;); // doSomthing(); // result passes a value transparently context.putResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;, \u0026amp;quot;b2aaa\u0026amp;quot;); return result; } If you start the child thread halfway, you need to set the context of the child thread:\nCountDownLatch latch = new CountDownLatch(1); final RpcInvokeContext parentContext = RpcInvokeContext.peekContext(); Thread thread = new Thread(new Runnable(){ public void run(){ Try { RpcInvokeContext.setContext(parentContext); / / Call a remote service xxxService.sayHello(); latch.countDown(); } finally { RpcInvokeContext.removeContext(); } } }, \u0026amp;quot;new-thread\u0026amp;quot;); thread.start(); // If failed to get the transparently transmitted data of the return value. latch.await(); //wait // Return ends, and you can get the value returned by transparent transmission. Compare with SOFATracer SOFATracer is an open-source distributed link tracing system of Ant Finanicial. RPC has been integrated with Tracer and is enabled by default.\nThe differences between data transparent transmission and data transfer by Tracer are as follows:\n RPC data transparent transmission is business-oriented. And it can implement two-way data transmission in the full link. The caller can transmit data to the service provider, and the service provider can also transmit data to the caller. SOFATracer is middleware-oriented and is more suitable for the data transfer without service itself perceving. It can only implement one-way data …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-chain-pass-data/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"96cfb41f07a6a2ad979b53093ff5eee9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","summary":"The link data transparent transmission function allows the applications to store data in the calling context, and then any applications in the entire link can operate the data. This feature is used as follows. Data can be put into the request and response of the link for transparent transmission, and then the applications can get the corresponding data from the link.\nRpcInvokeContext.getContext().putRequestBaggage(\u0026quot;key_request\u0026quot;,\u0026quot;value_request\u0026quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026quot;key_response\u0026quot;,\u0026quot;value_response\u0026quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026quot;key_request\u0026quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026quot;key_response\u0026quot;); Example For example, in the scenario of A -\u0026gt; B -\u0026gt; C, the request arguments set by A are transmitted to B and C.","tags":null,"title":"Link data transparent transmission","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","wordcount":427},{"author":null,"categories":null,"content":" 本文描述的是 MOSN listener 配置。\n Listener 配置详细描述了 MOSN 启动时监听的端口，以及对应的端口对应不同逻辑的配置。 Listener 的配置可以通过Listener动态接口进行添加和修改。 { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;address\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;bind_port\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;use_original_dst\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;access_logs\u0026amp;quot;:[], \u0026amp;quot;filter_chains\u0026amp;quot;:[], \u0026amp;quot;stream_filters\u0026amp;quot;:[], \u0026amp;quot;inspector\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;connection_idle_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } name 用于唯一区分 Listener，如果配置为空，会默认生成一个 UUID 作为 name。在对 Listener 进行动态更新时，使用 name 作为索引，如果 name 不存在，则是新增一个 listener，如果 name 存在则是对 listener 进行更新。\ntype 标记 Listener 的类型，目前支持 ingress 和 egress 两种类型。不同 type 的 Listener 输出的 tracelog 不同。\naddress IP:Port 形式的字符串，Listener 监听的地址，唯一。\nbind_port bool 类型，表示 Listener 是否会占用 address 配置的地址，通常情况下都需要配置为true。\nuse_original_dst bool 类型，用于透明代理。\naccess_logs 一组 access_log 配置。\nfilter_chains 一组 FilterChain 配置，但是目前 MOSN 仅支持一个 filter_chain。\nstream_filters 一组 stream_filter 配置，目前只在 filter_chain 中配置了 filter 包含 proxy 时生效。\ninspector bool 类型，当此值为 true 时，表示即便 listener 在 filter_chain 中配置开启了 TLS 监听，listener 依然可以处理非 TLS 的请求。\nconnection_idle_timeout Duration String，空闲连接超时配置。当 listener 上建立的连接空闲超过配置的超时时间以后，MOSN 会将此连接关闭。\n","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"028e9053b21853890114c38d55d15390","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/overview/","summary":"本文描述的是 MOSN listener 配置。 Listener 配置详细描述了 MOSN 启动时监听的端口，以及对应的端口对应不同逻辑的配置。 Listener 的配置可以通过Listener动态接口进行添加","tags":null,"title":"Listener 配置","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/overview/","wordcount":447},{"author":null,"categories":null,"content":" SOFARPC provides a variety of load balancing algorithms and currently supports the following five types:\n Type Name Description random Random algorithm The default load balancing algorithm. localPref Local preference algorithm Firstly detect whether the service is published locally, if not, random algorithm is used. roundRobin Round Robin algorithm Method-level polling, the polling is carried out separately to each method, without affecting each other. consistentHash Consistent hash algorithm The same method-level request is routed to the same node. weightRoundRobin Weighted Round Robin algorithm Poll nodes by weight. Not recommended due to poor performance. To use a specific load balancing algorithm, you can configure as follows:\nIn XML If you reference the service using XML, you can configure it by setting the loadBalancer property of the sofa:global-attrs tag:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs loadBalancer=\u0026amp;quot;roundRobin\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; In Annotation It is currently not supported to configure a load balancing algorithm for a reference in Annotation. The function will be provided in subsequent releases.\nIn API under Spring environment If you use the API in a Spring or Spring Boot environment, you can configure it by calling the setLoadBalancer method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setLoadBalancer(\u0026amp;quot;roundRobin\u0026amp;quot;); In API under non-Spring environment If you directly use the bare API provided by SOFARPC in a non-Spring environment, you can configure it by calling the setLoadBalancer method of ConsumerConfig:\nConsumerConfig consumerConfig = new ConsumerConfig(); consumerConfig.setLoadbalancer(\u0026amp;quot;random\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/load-balance/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"739984ca9a414429304f85010fd73ad0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/load-balance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/load-balance/","summary":"SOFARPC provides a variety of load balancing algorithms and currently supports the following five types:\n Type Name Description random Random algorithm The default load balancing algorithm. localPref Local preference algorithm Firstly detect whether the service is published locally, if not, random algorithm is used. roundRobin Round Robin algorithm Method-level polling, the polling is carried out separately to each method, without affecting each other.","tags":null,"title":"Load balance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/load-balance/","wordcount":230},{"author":null,"categories":null,"content":"To use local file as service registry center, you can configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg The /home/admin/registry/localRegistry.reg is the directory of the local files to be used.\nOn windows OS, the above path indicates the following directory:\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-local/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"33bc89393392e21b3917f090313c0df5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-local/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-local/","summary":"To use local file as service registry center, you can configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg The /home/admin/registry/localRegistry.reg is the directory of the local files to be used.\nOn windows OS, the above path indicates the following directory:\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","tags":null,"title":"Local","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-local/","wordcount":40},{"author":null,"categories":null,"content":" Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately. For single-core forwarding, in the case of specifying P=1, MOSN binds CPU with cores to improve the call execution efficiency of the system and the locality affinity of cache. For memory, in the case of binding single core, MOSN uses SLAB-style recycling mechanism to improve reuse and reduce memory copy. For IO, MOSN mainly implements optimization by controlling the read/write buffer size, read/write timing, read/write frequency and other parameters. The performance test data is as follows:\nTCP proxy performance data For the same deployment mode, this report compares MOSN 0.1.0 and envoy for the upper-layer protocol Bolt (SOFARPC related protocol) and HTTP1.1 respectively.\nDeployment mode The pressure test is deployed in a pure proxy mode. The client process accesses the server process through the MOSN process and serves as a forwarding proxy. The client process, MOSN process, and server process run on the machines which belong to different network segments. The network delay of the direct access from the client to server is about 2.5ms.\nClient Bolt protocol (send 1K string) The client that sends the Bolt protocol data uses the online pressure generators developed by Ant Financial and deploys the SOFARPC client.\nOn the pressure generator performance page, you can see the QPS, success/failure counts, RT and other parameters.\nHTTP1.1 protocol (send 1K string) Use ApacheBench/2.3. The test instructions are:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Mesh machine specifications The mesh runs in a container where the CPU is an exclusive logical core. The specifications are as follows:\n Category Information OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream machine specifications Category Information OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt protocol test result Performance data Indicators MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% Conclusion For single-core TCP forwarding, there is little difference between MOSN 0.1.0 and Envoy 1.7 in terms of performance in the condition with full load, such as QPS, RTT and success/failure counts. We will continue to optimize in the subsequent versions.\nHTTP/1.1 test result Since the HTTP/1.1 request response model is …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report010/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3cb22950b4be5a25b90f8aa1376786e9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/mosn/reference-performance-report010/","summary":"Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately.","tags":null,"title":"MOSN 0.1.0 performance report","type":"projects","url":"/sofastack.tech/en/projects/mosn/reference-performance-report010/","wordcount":730},{"author":null,"categories":null,"content":" Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately. For single-core forwarding, in the case of specifying P=1, MOSN binds CPU with cores to improve the call execution efficiency of the system and the locality affinity of cache. For memory, in the case of binding single core, MOSN uses SLAB-style recycling mechanism to improve reuse and reduce memory copy. For IO, MOSN mainly implements optimization by controlling the read/write buffer size, read/write timing, read/write frequency and other parameters. The performance test data is as follows:\nTCP proxy performance data For the same deployment mode, this report compares MOSN 0.1.0 and envoy for the upper-layer protocol Bolt (SOFARPC related protocol) and HTTP1.1 respectively.\nDeployment mode The pressure test is deployed in a pure proxy mode. The client process accesses the server process through the MOSN process and serves as a forwarding proxy. The client process, MOSN process, and server process run on the machines which belong to different network segments. The network delay of the direct access from the client to server is about 2.5ms.\nClient Bolt protocol (send 1K string) The client that sends the Bolt protocol data uses the online pressure generators developed by Ant Financial and deploys the SOFARPC client.\nOn the pressure generator performance page, you can see the QPS, success/failure counts, RT and other parameters.\nHTTP1.1 protocol (send 1K string) Use ApacheBench/2.3. The test instructions are:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Mesh machine specifications The mesh runs in a container where the CPU is an exclusive logical core. The specifications are as follows:\n Category Information OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream machine specifications Category Information OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt protocol test result Performance data Indicators MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% Conclusion For single-core TCP forwarding, there is little difference between MOSN 0.1.0 and Envoy 1.7 in terms of performance in the condition with full load, such as QPS, RTT and success/failure counts. We will continue to optimize in the subsequent versions.\nHTTP/1.1 test result Since the HTTP/1.1 request response model is …","date":-62135596800,"description":"","dir":"projects/occlum/reference-performance-report010/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"035dfbc7e310acf31561343432aea680","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/occlum/reference-performance-report010/","summary":"Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately.","tags":null,"title":"MOSN 0.1.0 performance report","type":"projects","url":"/sofastack.tech/en/projects/occlum/reference-performance-report010/","wordcount":730},{"author":null,"categories":null,"content":" 以下的的性能报告为 MOSN 0.1.0 在做 Bolt 与 HTTP1.x 协议的纯 TCP 转发上与 envoy 的一些性能对比数据，主要表现在 QPS、RTT、失败率/成功率等。\n这里需要强调的是，为了提高 MOSN 的转发性能，在 0.1.0 版本中，我们做了如下的一些优化手段：\n 在线程模型优化上，使用 worker 协程池处理 stream 事件，使用两个独立的协程分别处理读写 IO 在单核转发优化上，在指定 P=1 的情况下，我们通过使用 CPU 绑核的形式来提高系统调用的执行效率以及 cache 的 locality affinity 在内存优化上，同样是在单核绑核的情况下，我们通过使用 SLAB-style 的回收机制来提高复用，减少内存 copy 在 IO 优化上，主要是通过读写 buffer 大小以及读写时机和频率等参数的控制上进行调优 以下为具体的性能测试数据。\nTCP 代理性能数据 这里，针对相同的部署模式，我们分别针对上层协议为 \u0026amp;quot;Bolt(SofaRpc相关协议)\u0026amp;quot; 与 \u0026amp;quot;HTTP1.1\u0026amp;quot; 来进行对比。\n部署模式 压测采用纯代理模式部署，client 进程通过 MOSN 进程作为转发代理访问server进程。其中，client 进程，MOSN 进程，server 进程分别运行在属于不同网段的机器中。client 直连访问 server 网络延时为 2.5ms 左右。\n客户端 Bolt 协议（发送 1K 字符串） 发送 Bolt 协议数据的客户端使用 \u0026amp;ldquo;蚂蚁金服\u0026amp;rdquo;内部开发的线上压力机，并部署 sofa rpc client。 通过压力机的性能页面，可反映压测过程中的QPS、成功/失败次数，以及RT等参数。\nHTTP1.1 协议（发送 1K 字符串） 使用 ApacheBench/2.3, 测试指令:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Service mesh 运行机器规格 Service mesh 运行在容器中，其中 CPU 为独占的一个逻辑核，具体规格如下：\n 类别 信息 OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream 运行机器规格 类别 信息 OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt 协议测试结果 性能数据 指标 MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% 结论 可以看到，在单核 TCP 转发场景下，MOSN 0.1.0 版本和 Envoy 1.7版本，在满负载情况下的 QPS、RTT、成功数/失败数等性能数据上相差不大，后续版本我们会继续优化。\nHTTP/1.1 测试结果 由于 HTTP/1.1 的请求响应模型为 PING-PONG，因此 QPS 与并发数会呈现正相关。下面分别进行不同并发数的测试。\n并发20 指标 MOSN Envoy QPS 5600 5600 RT(mean) 3.549ms 3.545ms RT(P99) 4ms 4ms RT(P98) 4ms 4ms RT(P95) 4ms 4ms MEM 24m 23m CPU 40% 20% 并发40 指标 MOSN Envoy QPS 11150 11200 RT(mean) 3.583ms 3.565ms RT(P99) 4ms 4ms RT(P98) 4ms 4ms RT(P95) 4ms 4ms MEM 34m 24m CPU 70% 40% 并发200 指标 MOSN Envoy QPS 29670 38800 RT(mean) 5.715ms 5.068ms RT(P99) 16ms 7ms RT(P98) 13ms 7ms RT(P95) 11ms 6ms MEM 96m 24m CPU 100% 95% 并发220 指标 MOSN Envoy QPS 30367 41070 RT(mean) 8.201ms 5.369ms RT(P99) 20ms 9ms RT(P98) 19ms 8ms RT(P95) 16ms 8ms MEM 100m 24m CPU 100% 100% 结论 可以看到，在上层协议为 HTTP/1.X 时，MOSN 的性能和 Envoy 的性能存在一定差距，对于这种现象我们的初步结论为：在 PING-PONG 的发包模型下，MOSN 无法进行 read/write 系统调用合并，相比 SOFARPC 可以合并的场景，syscall 数量大幅上升，因此导致相比 SOFARPC 的场景，HTTP 性能上相比 Envoy 会存在差距。针对这个问题，在 0.2.0 版本中，我们会进行相应的优化。\n附录 Envoy 版本信息 version：1.7 tag：1ef23d481a4701ad4a414d1ef98036bd2ed322e7 Envoy TCP 测试配置 static_resources: listeners: - address: socket_address: address: 0.0.0.0 port_value: 12200 filter_chains: - filters: - name: envoy.tcp_proxy config: stat_prefix: ingress_tcp cluster: sofa_server clusters: - name: sofa_server connect_timeout: 0.25s type: static lb_policy: round_robin hosts: - socket_address: address: 10.210.168.5 port_value: 12222 - socket_address: address: 10.210.168.5 port_value: 12223 - socket_address: address: 10.210.168.5 port_value: 12224 - socket_address: address: 10.210.168.5 port_value: 12225 admin: access_log_path: …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report010/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3cb22950b4be5a25b90f8aa1376786e9","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/reference-performance-report010/","summary":"以下的的性能报告为 MOSN 0.1.0 在做 Bolt 与 HTTP1.x 协议的纯 TCP 转发上与 envoy 的一些性能对比数据，主要表现在 QPS、RTT、失败率/成功率等。 这里需要强调的是，为了提","tags":null,"title":"MOSN 0.1.0 性能报告","type":"projects","url":"/sofastack.tech/projects/mosn/reference-performance-report010/","wordcount":1229},{"author":null,"categories":null,"content":" 以下性能报告的基准版本为 MOSN 0.2.1。在 0.2.1 版本中，我们进行了如下一些优化手段： - 添加内存复用框架，涵盖 io/protocol/stream/proxy 层级，减少对象分配、内存使用和 GC 压力。 - 针对大量链接场景，新增 Raw Epoll 模式，该模式使用了事件回调机制 + IO 协程池，规避了海量协程带来的堆栈内存消耗以及调度开销。\n需要注意的是，由于目前 SOFARPC 和 H2 的压测工具还没有 pxx 指标的展示，我们在性能报告中选取的数据都为均值。后续需要我们自行进行相关压测环境工具的建设来完善相关指标（P99，P95……）\n总览 本次性能报告在0.1.0 性能报告的基础上，新增了若干场景的覆盖，总体包含以下几部分： - 单核性能（sidecar场景） - 7层代理 - Bolt（串联） - Http/1.1（串联） - Http/2（串联） - 多核性能（gateway场景） - 7层代理 - Bolt（直连） - Http/1.1（直连） - Http/2（直连） - 长连接网关 - Bolt（read/write loop with goroutine/raw epoll）\n单核性能（sidecar 场景） 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2430 0 @ 2.20GHz bolt client client 为压力平台，有 5 台压力机，共计与client MOSN 之间会建立 500 条链接 http1 client（10.210.168.5） ApacheBench/2.3 -n 2000000 -c 500 -k http2 client（10.210.168.5） nghttp.h2load -n1000000 -c5 -m100 -t4 部署结构 压测模式 部署结构 串联 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 请求内容 1K req/resp 7层代理 场景 QPS RT(ms) MEM(K) CPU(%) Bolt 16000 15.8 77184 98 Http/1.1 4610 67 47336 90 Http/2 5219 81 31244 74 多核性能（gateway 场景） 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2430 0 @ 2.20GHz bolt client client为压力平台，有5台压力机，共计与client MOSN之间会建立500条链接 http1 client（10.210.168.5） ApacheBench/2.3 -n 2000000 -c 500 -k http2 client（10.210.168.5） nghttp.h2load -n1000000 -c5 -m100 -t4 部署结构 压测模式 部署结构 直连 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 请求内容 1K req/resp 7层代理 场景 QPS RT(ms) MEM(K) CPU(%) Bolt 45000 23.4 544732 380 Http/1.1 21584 23 42768 380 Http/2 8180 51.7 173180 300 长连接网关 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2430 0 @ 2.20GHz 部署结构 压测模式 部署结构 直连 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 链接数 请求内容 2 台压力机，每台 5w 链接 + 500 QPS，共计10W链接 + 1000 QPS 1K req/resp 长连接网关 场景 QPS MEM(g) CPU(%) goroutine RWLoop + goroutine 1000 3.3 60 200028 Raw epoll 1000 2.5 18 28 总结 MOSN 0.2.1引入了内存复用框架，相比0.1.0，在 bolt 协议转发场景性能表现得到了大幅优化。在提升了20% 的 QPS 的同时，还优化了 30% 的内存占用。\n与此同时，我们对 HTTP/1.1 及 HTTP/2 的场景也进行 …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report021/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7b04a2e6cf1c4f9e732dc1dfdab74c57","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/reference-performance-report021/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/reference-performance-report021/","summary":"以下性能报告的基准版本为 MOSN 0.2.1。在 0.2.1 版本中，我们进行了如下一些优化手段： - 添加内存复用框架，涵盖 io/protocol/stream/proxy 层级，减少对象分配、内存使用和 GC 压力","tags":null,"title":"MOSN 0.2.1 性能报告","type":"projects","url":"/sofastack.tech/projects/mosn/reference-performance-report021/","wordcount":1616},{"author":null,"categories":null,"content":" MOSN 的官方网站 mosn.io 正在建设中，文档临时托管在这里。\nMOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称。MOSN 可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡，API Gateway，云原生 Ingress 等使用。\n快速开始 请参考快速开始。\n核心能力 Istio集成 集成 Istio 1.0 版本与 V4 API，可基于全动态资源配置运行 核心转发 自包含的网络服务器 支持 TCP 代理 支持 TProxy 模式 多协议 支持 HTTP/1.1，HTTP/2 支持 SOFARPC 支持 Dubbo 协议（开发中） 核心路由 支持 Virtual Host 路由 支持 Headers/URL/Prefix 路由 支持基于 Host Metadata 的 Subset 路由 支持重试 后端管理\u0026amp;amp;负载均衡 支持连接池 支持熔断 支持后端主动健康检查 支持 Random/RR 等负载策略 支持基于 Host Metadata 的 Subset 负载策略 可观察性 观察网络数据 观察协议数据 TLS 支持 HTTP/1.1 on TLS 支持 HTTP/2.0 on TLS 支持 SOFARPC on TLS 进程管理 支持平滑 reload 支持平滑升级 扩展能力 支持自定义私有协议 支持在 TCP IO 层，协议层面加入自定义扩展 社区 MOSN 仍处在初级阶段，有很多能力需要补全，所以我们欢迎所有人参与进来与我们一起共建。\n如有任何疑问欢迎提交 Issue。\n","date":-62135596800,"description":"","dir":"projects/mosn/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f25c59cbb758b4dae5de39e1f1c3a2f4","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/overview/","summary":"MOSN 的官方网站 mosn.io 正在建设中，文档临时托管在这里。 MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，","tags":null,"title":"MOSN 介绍","type":"projects","url":"/sofastack.tech/projects/mosn/overview/","wordcount":470},{"author":null,"categories":null,"content":" Service Mesh 中 Sidecar 运维一直是一个比较棘手的问题，数据平面的 Sidecar 升级是常有的事情，如何在升级 Sidecar（MOSN）的时候而不影响业务，对于存量的长连接如何迁移，本文将为你介绍 MOSN 的解决之道。\n背景 本文介绍 MOSN 支持平滑升级的原因和解决方案，对于平滑升级的一些基础概念，大家可以通过 Nginx vs Enovy vs Mosn 平滑升级原理解析了解。\n先简单介绍一下为什么 Nginx 和 Envoy 不需要具备 MOSN 这样的连接无损迁移方案，主要还是跟业务场景相关，Nginx 和 Envoy 主要支持的是 HTTP1 和 HTTP2 协议，HTTP1使用 connection: Close，HTTP2 使用 Goaway Frame 都可以让 Client 端主动断链接，然后新建链接到新的 New process，但是针对 Dubbo、SOFA PRC 等常见的多路复用协议，它们是没有控制帧，Old process 的链接如果断了就会影响请求的。\n一般的升级做法就是切走应用的流量，比如自己UnPub掉服务，等待一段时间没有请求之后，升级MOSN，升级好之后再Pub服务，整个过程比较耗时，并且会有一段时间是不提供服务的，还要考虑应用的水位，在大规模场景下，就很难兼顾评估。MOSN 为了满足自身业务场景，开发了长连接迁移方案，把这条链接迁移到 New process 上，整个过程对 Client 透明，不需要重新建链接，达到请求无损的平滑升级。\n正常流程 Client 发送请求 Request 到 MOSN MOSN 转发请求 Request 到 Server Server 回复响应 Response 到 MOSN MOSN 回复响应 Response 到 Client 上图简单介绍了一个请求的正常流程，我们后面需要迁移的是 TCP1 链接，也就是 Client 到 MOSN 的连接，MOSN 到 Server 的链接 TCP2 不需要迁移，因为 MOSN 访问 Server 是根据 LoadBalance 选择，我们可以主动控制断链建链。\n平滑升级流程 触发条件 有两个方式可以触发平滑升级流程：\n MOSN 对 SIGHUP 做了监听，发送 SIGHUP 信号给 MOSN 进程，通过 ForkExec 生成一个新的 MOSN 进程。 直接重新启动一个新 MOSN 进程。 为什么提供两种方式？最开始我们支持的是方法1，也就是 nginx 和 Envoy 使用的方式，这个在虚拟机或者容器内替换 MOSN 二级制来升级是可行的，但是我们的场景需要满足容器间的升级，所以需要新拉起一个容器，就需要重新启动一个新的 MOSN 进程来做平滑升级，所以后续又支持了方法2。容器间升级还需要 operator 的支持，本文不展开叙述。\n交互流程 首先，老的 MOSN 在启动最后阶段会启动一个协程运行 ReconfigureHandler() 函数监听一个 Domain Socket（reconfig.sock）, 该接口的作用是让新的 MOSN 来感知是否存在老的 MOSN。\nfunc ReconfigureHandler() { l, err := net.Listen(\u0026amp;quot;unix\u0026amp;quot;, types.ReconfigureDomainSocket) for { uc, err := ul.AcceptUnix() _, err = uc.Write([]byte{0}) reconfigure(false) } } 触发平滑升级流程的两种方式最终都是启动一个新的 MOSN 进程，然后调用GetInheritListeners()，通过 isReconfigure() 函数来判断本机是否存在一个老的 MOSN（就是判断是否存在 reconfig.sock 监听），如果存在一个老的 MOSN，就进入迁移流程，反之就是正常的启动流程。\n// 保留了核心流程 func GetInheritListeners() ([]net.Listener, net.Conn, error) { if !isReconfigure() { return nil, nil, nil } l, err := net.Listen(\u0026amp;quot;unix\u0026amp;quot;, types.TransferListenDomainSocket) uc, err := ul.AcceptUnix() _, oobn, _, _, err := uc.ReadMsgUnix(buf, oob) file := os.NewFile(fd, \u0026amp;quot;\u0026amp;quot;) fileListener, err := net.FileListener(file) return listeners, uc, nil } 如果进入迁移流程，新的 MOSN 将监听一个新的 Domain Socket（listen.sock），用于老的 MOSN 传递 listen FD 到新的 MOSN。FD 的传递使用了sendMsg 和 recvMsg。在收到 listen FD 之后，调用 net.FileListener() 函数生产一个 Listener。此时，新老 MOSN 都同时拥有了相同的 Listen 套接字。\n// FileListener returns a copy of the network listener corresponding // to the open file f. // It is the caller\u0026#39;s responsibility to close ln when finished. // Closing ln does not affect f, and closing f does not affect ln. func FileListener(f *os.File) (ln Listener, err error) { ln, err = fileListener(f) if err != nil { err = \u0026amp;amp;OpError{Op: \u0026amp;quot;file\u0026amp;quot;, Net: \u0026amp;quot;file+net\u0026amp;quot;, Source: nil, Addr: fileAddr(f.Name()), Err: err} } return } 这里的迁移和 Nginx 还是有一些区别，Nginx 是 fork 的方式，子进程自动就继承了 listen FD，MOSN 是新启动的进程，不存在父子关系，所以需要通过 sendMsg 的方式来传递。\n在进入迁移流程和 Listen 的迁移过程中，一共使用了两个 Domain Socket：\n reconfig.sock 是 Old MOSN 监听，用于 New MOSN 来判断是否存在 listen.sock 是 New MOSN 监听，用于 Old MOSN 传递 listen FD 两个 sock 其实是可以复用的，也可以用 reconfig.sock …","date":-62135596800,"description":"","dir":"projects/mosn/concept/smooth-upgrade/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2c09c045287c33c760368abe02bb8986","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/smooth-upgrade/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/mosn/concept/smooth-upgrade/","summary":"Service Mesh 中 Sidecar 运维一直是一个比较棘手的问题，数据平面的 Sidecar 升级是常有的事情，如何在升级 Sidecar（MOSN）的时候而不影响业务，对于存量的长连接","tags":null,"title":"MOSN 平滑升级原理解析","type":"projects","url":"/sofastack.tech/projects/mosn/concept/smooth-upgrade/","wordcount":3957},{"author":null,"categories":null,"content":" 1. registry-meta 1.1 Push switch When publishing new SOFARegistry versions, to minimize the impact on services, and avoid large amounts of push messages caused by large-scale service endpoint changes during the server restart process, we will temporarily turn off the push service at the management layer. After publishing the new SOFARegistry version, we can turn on the push service and restore the normal working conditions. Data subscription and service publication information generated for the period when the push service is turned off will be subject to global push for compensation.\nTurn on the push service:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/close\u0026amp;quot; Turn off the push service:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/open\u0026amp;quot; 1.2 Query the endpoint list View the endpoint list of the meta cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/META/node/query\u0026amp;quot; View the endpoint list of the data cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/DATA/node/query\u0026amp;quot; View the endpoint list of the session cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/SESSION/node/query\u0026amp;quot; 1.3 Scale up/down the meta cluster 1.3.1 Modify the cluster: changePeer You can call this operation to modify the Raft cluster list when you have scaled up/down the cluster. This allows you to correctly add nodes to or remove nodes from the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;ip1\u0026amp;gt;,\u0026amp;lt;ip2\u0026amp;gt;,\u0026amp;lt;ip3\u0026amp;gt;\u0026amp;quot; 1.3.2 Reset the cluster: resetPeer When a cluster is unavailable, for example, two of three servers are not functional, the cluster can not carry out leader election. Here, you can call this operation to reset the cluster list. For example, you can reset the cluster to a one-server cluster (with the only functional server) to resume election and restore service.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/manage/resetPeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;ip1\u0026amp;gt;,\u0026amp;lt;ip2\u0026amp;gt;,\u0026amp;lt;ip3\u0026amp;gt;\u0026amp;quot; 2. registry-data 2.1 Query data View the pub count:\ncurl \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/datum/count\u0026amp;quot; You can call this operation to view data published by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;\u0026amp;quot;:\u0026amp;quot;\u0026amp;lt;client port\u0026amp;gt;\u0026amp;quot;}\u0026#39; 3. registry-session 3.1 Query data You can call this operation to view data published by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/pub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client port\u0026amp;gt;\u0026amp;quot;]\u0026#39; You can call this operation to view data subscribed to by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/sub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: …","date":-62135596800,"description":"","dir":"projects/sofa-registry/management-api/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2cf59ac422c84c279d73c1f7f1cd0902","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/management-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/management-api/","summary":"1. registry-meta 1.1 Push switch When publishing new SOFARegistry versions, to minimize the impact on services, and avoid large amounts of push messages caused by large-scale service endpoint changes during the server restart process, we will temporarily turn off the push service at the management layer. After publishing the new SOFARegistry version, we can turn on the push service and restore the normal working conditions. Data subscription and service publication information generated for the period when the push service is turned off will be subject to global push for compensation.","tags":null,"title":"Management commands","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/management-api/","wordcount":406},{"author":null,"categories":null,"content":" pom dependencies \u0026amp;lt;!-- jraft --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jraft-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- jsr305 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.code.findbugs\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jsr305\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- bolt --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hessian\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- log --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.7.21\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- disruptor --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.lmax\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;disruptor\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-io\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-io\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-lang\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-lang\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protobuf --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.protobuf\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protobuf-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protostuff --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-runtime\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- rocksdb --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.rocksdb\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rocksdbjni\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.14.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- java thread affinity --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;net.openhft\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;affinity\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.1.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- metrics --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.dropwizard.metrics\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;metrics-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/maven-dependency/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"abb08cef5ebf1a10a723597a65415313","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","summary":"pom dependencies \u0026lt;!-- jraft --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jraft-core\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- jsr305 --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.code.findbugs\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jsr305\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.0.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- bolt --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;hessian\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- log --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.slf4j\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;slf4j-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.7.21\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- disruptor --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.lmax\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;disruptor\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.7\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-io\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-io\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.4\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-lang\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-lang\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protobuf --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.protobuf\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;protobuf-java\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.5.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protostuff --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.","tags":null,"title":"Maven dependencies","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","wordcount":104},{"author":null,"categories":null,"content":" pom依赖 \u0026amp;lt;!-- jraft --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jraft-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- jsr305 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.code.findbugs\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jsr305\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- bolt --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hessian\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- log --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.7.21\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- disruptor --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.lmax\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;disruptor\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-io\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-io\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-lang\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-lang\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protobuf --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.protobuf\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protobuf-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protostuff --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-runtime\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- rocksdb --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.rocksdb\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rocksdbjni\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.14.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- java thread affinity --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;net.openhft\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;affinity\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.1.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- metrics --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.dropwizard.metrics\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;metrics-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/maven-dependency/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"abb08cef5ebf1a10a723597a65415313","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/maven-dependency/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/maven-dependency/","summary":"pom依赖 \u0026lt;!-- jraft --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jraft-core\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- jsr305 --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.code.findbugs\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jsr305\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.0.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- bolt --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;hessian\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- log --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.slf4j\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;slf4j-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.7.21\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- disruptor --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.lmax\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;disruptor\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.7\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-io\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-io\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.4\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-lang\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-lang\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protobuf --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.protobuf\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;protobuf-java\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.5.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protostuff","tags":null,"title":"Maven 依赖说明","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/maven-dependency/","wordcount":107},{"author":null,"categories":null,"content":" In Jarslink 2.0, merged deployment refers to loading and running multiple Biz packages in the same JVM. In the section Application Packaging, we have described the relationship between the Spring Boot/SOFABoot application and the Biz package. We may think that merged deployment here refers to loading and running multiple Spring Boot/SOFABoot applications in the same JVM.\nIt is mentioned at the end of Application Packaging that a Biz package can be released to a remote repository through the mvn deploy command, similar to releasing common Jar packages. It comes naturally to mind that the advantage of doing so is that the Biz package generated by other applications can be introduced in the form of dependencies, just like introducing common Jar package dependencies. Then, what is the purpose of introducing the Biz package generated by other applications into your application? Also, how do we dynamically install and uninstall Biz packages in Jarslink 2.0?\nTo answer the two questions above is to understand the concepts of static merged deployment and dynamic merged deployment.\nStatic merged deployment To answer the first question: What is the purpose of introducing the Biz package generated by other applications into your application?\nIn the section Application Packaging, we have described how to package an application into an Ark package and offered a rough equation: Ark package = Biz package + SOFAArk framework + Ark Plugin. When a Biz package generated by other applications is introduced in the application, what kind of packaged Ark package will it be? The conclusion is that the packaging plugin will treat special dependency packages like the Biz package differently. The plugin will package all the non-Biz package dependencies into the application\u0026amp;rsquo;s Biz package, but will consider the introduced Biz package as equal to those of the current application. The final Ark package will contain multiple Biz packages. For details, refer to Ark Package Directory Structure. At this point, when you use java -jar to start this Ark package, you will find that all the contained Biz packages will be started as well.\nTo sum up, the application introduces the Biz packages generated by other applications in the form of dependencies, and the Ark package packaged by this application will contain multiple Biz packages. By executing this Ark package, all the Biz packages will be started, known as static merged deployment.\nStatic merged deployment does not depend on Jarslink 2.0 but is available directly with the SOFAArk packaging plugin.\nNote that the startup order of multiple Biz packages is controllable. When each Biz package is generated, you can use the packaging plugin to configure its priority, whose value is 100 by default. The higher the priority, the lower the value is. The priority determines the startup order of the Biz package.\nDynamic merged deployment To answer the second question: how do you dynamically install and uninstall Biz packages in Jarslink …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-deploy/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ce787203d9d834b7f796b3dbb40bf55d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","summary":"In Jarslink 2.0, merged deployment refers to loading and running multiple Biz packages in the same JVM. In the section Application Packaging, we have described the relationship between the Spring Boot/SOFABoot application and the Biz package. We may think that merged deployment here refers to loading and running multiple Spring Boot/SOFABoot applications in the same JVM.\nIt is mentioned at the end of Application Packaging that a Biz package can be released to a remote repository through the mvn deploy command, similar to releasing common Jar packages.","tags":null,"title":"Merged deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","wordcount":749},{"author":null,"categories":null,"content":" Quickly understand of ACTS models When you write a test case, you need to prepare some database tables, request parameter data of methods, or data for validating database tables and responses. You can save such data in models, and import it to preparation data or validation data when you edit the test case. This allows you to conveniently reuse data. Currently, ACTS models can be divided into database models and class models.\nIn conventional test case compilation, data preparation of models, such as database models, request parameter models, and response models, is based on the test code. The complexity of models increases with the business complexity, especially in financial-level business applications, where a class or data table may have dozens of properties or fields, and where class nesting is common. In this case, constructing complex objects is extremely difficult and prone to omissions. Some of the most frequently occurring problems are listed as follows:\n Omissions may occur and troubleshooting takes a lot of time for a large number of tables. Field names of tables are difficult to remember, and spelling errors frequently occur. The large number and complex types of interface request parameters are frustrating. There are so many class properties that important properties are prone to omission. Object construction with nested structures requires continuous effort in creating and setting values. Important properties are easily omitted when the inheritance and implementation relationships are complex. ACTS models can effectively address the above problems by formatting classes and tables in CSV, which makes the structure of classes easier to understand. Class models and data table models can help you quickly create objects, and serialize them into the YAML file. ACTS models allow you to conveniently manage test case data.\nStorage location of models You can view existing models under the resource/model directory of the test module.\nFigure 4\nGenerate data table model Sample data table model Figure 5\n1. Validation flag description\nY: indicates that the data is to be inserted. N: indicates that the data is not to be inserted. C: indicates that ACTS will clean the inserted data by taking this value as the where condition. F: indicates that the value of this column is a database function. L: indicates that a large field data record requires line wrap. The preparation method for this data record is: A=B;C=D. 2. Quickly import data from models during test case editing\nWhen editing database table data (including preparing table data and expectation data) in ACTS IDE, you can right click to add a model of the specified table, to import all fields and values of the specified table directly from the CSV file of the table model for quick editing. For more information about the use of DB models, see Prepare database data.\nGenerate table model Figure 6\nFigure 7\nFigure 8\nClick OK to generate the model as shown in Figure 9.\nFigure 9\nACTS also supports …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-model/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"65aaf62462b3b0ea142ca75a5b61eb0d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-model/","summary":"Quickly understand of ACTS models When you write a test case, you need to prepare some database tables, request parameter data of methods, or data for validating database tables and responses. You can save such data in models, and import it to preparation data or validation data when you edit the test case. This allows you to conveniently reuse data. Currently, ACTS models can be divided into database models and class models.","tags":null,"title":"Models","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-model/","wordcount":752},{"author":null,"categories":null,"content":" Since version 2.4.0, SOFABoot has started to support modular development capability based on Spring context isolation. To better understand the concept of modular development of SOFABoot, let\u0026amp;rsquo;s distinguish several common forms of modularization:\n Modularization based on code organization: This is the most common form. Codes with different functions are placed under different Java projects at development time and into different jar packages at compile time. At runtime, all Java classes are under the same classpath without any isolation; Modularization based on Spring context isolation: Use the Spring context to perform isolation of different function modules. At development and compile time, the codes and configurations are also placed under different Java projects. At runtime, however, if Spring beans are in different Spring contexts, they are invisible to each other, so dependency injection occurs within the same context. But, all the Java classes are still under the same ClassLoader; Modularization based on ClassLoader isolation: Borrow the ClassLoader to perform isolation. Each module has an independent ClassLoader, and the classpath between modules differs. SOFAArk is the practice of such modularization. SOFABoot Modular Development belongs to the second modularization form\u0026amp;ndash;modularization based on Spring context isolation. Each SOFABoot module uses an independent Spring context to avoid BeanId conflicts between different SOFABoot modules and effectively reduces the cost of communication between teams during enterprise-level multi-module development.\nMore details about SOFABoot module is introduced in the article.\nFeature Description Import Dependency To use SOFABoot module, you should import the following dependency: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;isle-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFABoot Module SOFABoot framework has defined the concept of SOFABoot module: A SOFABoot module is a common Jar package including Java code, Spring configuration files, and SOFABoot module identifiers. A SOFABoot application can be comprised of multiple SOFABoot modules, each of which has independent Spring context.\nThe modular development with SOFABoot provides developers with the following features:\n At runtime, the Spring context of each SOFABoot module is isolated, so the defined Beans between modules will not affect each other; Each SOFABoot module is full-featured and self-contained, allowing for easy migration and reuse in different SOFABoot applications. Developers only need to copy the whole SOFABoot module to the application and adjust the Maven dependence before running it. For the format definition of SOFABoot module, see: Module Configuration.\nInvocation between SOFABoot Modules After isolation of context, the Bean between modules cannot be directly injected, so the SOFA service is required for invocation between the modules. Currently, SOFABoot offers …","date":-62135596800,"description":"","dir":"projects/sofa-boot/modular-development/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"95bc080787c3614bfa485d2f3cd0de4c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/modular-development/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/modular-development/","summary":"Since version 2.4.0, SOFABoot has started to support modular development capability based on Spring context isolation. To better understand the concept of modular development of SOFABoot, let\u0026rsquo;s distinguish several common forms of modularization:\n Modularization based on code organization: This is the most common form. Codes with different functions are placed under different Java projects at development time and into different jar packages at compile time. At runtime, all Java classes are under the same classpath without any isolation; Modularization based on Spring context isolation: Use the Spring context to perform isolation of different function modules.","tags":null,"title":"Modular development","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/modular-development/","wordcount":578},{"author":null,"categories":null,"content":" The SOFABoot module combines a regular JAR with some SOFABoot-specific configurations, which enables a JAR to be identified by SOFABoot and modularized.\nThere are two differences between a complete SOFABoot module and a regular JAR:\n A SOFABoot module contains a sofa-module.properties file, where the name and the dependencies of the module are defined. We can place one or more Spring configuration files in the SOFABoot module\u0026amp;rsquo;s META-INF/spring directory; and SOFABoot will automatically load them as Spring configurations for that module. Inside the sofa-module.properties file Let\u0026amp;rsquo;s look at a complete sofa-module.properties file:\nModule-Name=com.alipay.test.biz.service.impl Spring-Parent=com.alipay.test.common.dal Require-Module=com.alipay.test.biz.shared Module-Profile=dev Module-Name This is the name of a SOFABoot module, which is also the unique identifier of the module. In a SOFABoot application, the Module-Name of a SOFABoot module must be different from that of another SOFABoot module. Note that the SOFABoot modules of a SOFABoot application runtime do not only cover the modules of the current application but also the modules introduced by dependency from other applications. When determining whether a module is unique, you must take these SOFABoot modules into consideration.\nRequire-Module This defines the dependency order of different modules. The value contains a comma-separated list of SOFABoot module names. For example, in the preceding configuration, it indicates that the current module depends on the com.alipay.test.biz.shared module. The SOFABoot framework processes this dependency by starting the com.alipay.test.biz.shared module before the current module.\nIn most cases, you do not have to define the Require-Module for a module. It is required only when the startup of a module\u0026amp;rsquo;s Spring context depends on that of another module\u0026amp;rsquo;s. For example, you have published a JVM Service in module A. In the init method of a Bean in module B, you need to call the JVM Service with a SOFA Reference. Assume that module B is started before module A, the Bean of module B will fail because the JVM Service of module A is not published yet and the init method fails. In this case, you can use the Require-Module to force module A to start before module B.\nSpring-Parent In a SOFABoot application, each SOFABoot module has a separate Spring context, and these Spring contexts are isolated from each other. Although this modular approach has many benefits, it can still cause some inconveniences in certain scenarios. For these scenarios, you can use the Spring-Parent to connect the Spring contexts of two SOFABoot modules. The name of a module can be configured with the Spring-Parent property. For example, in the preceding configuration, the Spring context of com.alipay.test.common.dal is set to the parent of the current module\u0026amp;rsquo;s Spring context.\nDue to Spring\u0026amp;rsquo;s limitations, a module\u0026amp;rsquo;s Spring-Parent contains only one …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-module/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2dbb8a536237f21afbee1e3f320b8193","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","summary":"The SOFABoot module combines a regular JAR with some SOFABoot-specific configurations, which enables a JAR to be identified by SOFABoot and modularized.\nThere are two differences between a complete SOFABoot module and a regular JAR:\n A SOFABoot module contains a sofa-module.properties file, where the name and the dependencies of the module are defined. We can place one or more Spring configuration files in the SOFABoot module\u0026rsquo;s META-INF/spring directory; and SOFABoot will automatically load them as Spring configurations for that module.","tags":null,"title":"Module configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","wordcount":565},{"author":null,"categories":null,"content":"SOFABoot will calculate the dependency tree based on the Require-Module. For example, the following dependency tree represents that Modules B and C depend on Module A, Module E depends on Module D, and Module F depends on Module E:\nThe dependency tree guarantees that Module A starts before Modules B and C, Module D before Module E, and Module E before Module F, but without defining the start orders between Modules B and C, or Modules B, C and Modules D, E and F, which can start either in serial or parallel.\nSOFABoot will start the modules in parallel by default. During use, if you want to disable parallel start, you can add the following parameter to application.properties:\ncom.alipay.sofa.boot.module-start-up-parallel=false ","date":-62135596800,"description":"","dir":"projects/sofa-boot/parallel-start/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a6ef51b78d2a4f9af0debbc25ea45e8a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/parallel-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/parallel-start/","summary":"SOFABoot will calculate the dependency tree based on the Require-Module. For example, the following dependency tree represents that Modules B and C depend on Module A, Module E depends on Module D, and Module F depends on Module E:\nThe dependency tree guarantees that Module A starts before Modules B and C, Module D before Module E, and Module E before Module F, but without defining the start orders between Modules B and C, or Modules B, C and Modules D, E and F, which can start either in serial or parallel.","tags":null,"title":"Module parallel startup","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/parallel-start/","wordcount":119},{"author":null,"categories":null,"content":"SOFARPC already supports using Nacos as a service registry. Suppose you have deployed Nacos Server locally according to Nacos\u0026amp;rsquo;s Quick Start, and the service discovery port is set to 8848 by default.\nTo use Nacos as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 If you use SOFARPC directly, not SOFABoot, you need to add dependency of nacos, notice that version is what you want to use in your project.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba.nacos\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;nacos-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; The current version of Nacos is supported:\nSOFARPC: 5.5.0, SOFABoot: 2.5.3。\nSOFARPC integration verification Nacos server version:0.6.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-nacos/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"cc161f22cd2145fe309e63087581adc1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","summary":"SOFARPC already supports using Nacos as a service registry. Suppose you have deployed Nacos Server locally according to Nacos\u0026rsquo;s Quick Start, and the service discovery port is set to 8848 by default.\nTo use Nacos as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 If you use SOFARPC directly, not SOFABoot, you need to add dependency of nacos, notice that version is what you want to use in your project.","tags":null,"title":"Nacos","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","wordcount":100},{"author":null,"categories":null,"content":" 前言 本文是对 Nginx、Envoy 及 MOSN 的平滑升级原理区别的分析，适合对 Nginx 实现原理比较感兴趣的同学阅读，需要具备一定的网络编程知识。\n平滑升级的本质就是 listener fd 的迁移，虽然 Nginx、Envoy、MOSN 都提供了平滑升级支持，但是鉴于它们进程模型的差异，反映在实现上还是有些区别的。这里来探讨下它们其中的区别，并着重介绍 Nginx 的实现。\nNginx 相信有很多人认为 Nginx 的 reload 操作就能完成平滑升级，其实这是个典型的理解错误。实际上 reload 操作仅仅是平滑重启，并没有真正的升级新的二进制文件，也就是说其运行的依然是老的二进制文件。\nNginx 自身也并没有提供平滑升级的命令选项，其只能靠手动触发信号来完成。具体正确的操作步骤可以参考这里：Upgrading Executable on the Fly，这里只分析下其实现原理。\nNginx 的平滑升级是通过 fork + execve 这种经典的处理方式来实现的。准备升级时，Old Master 进程收到信号然后 fork 出一个子进程，注意此时这个子进程运行的依然是老的镜像文件。紧接着这个子进程会通过 execve 调用执行新的二进制文件来替换掉自己，成为 New Master。\n那么问题来了：New Master 启动时按理说会执行 bind + listen 等操作来初始化监听，而这时候 Old Master 还没有退出，端口未释放，执行 execve 时理论上应该会报：Address already in use 错误，但是实际上这里却没有任何问题，这是为什么？\n因为 Nginx 在 execve 的时候压根就没有重新 bind + listen，而是直接把 listener fd 添加到 epoll 的事件表。因为这个 New Master 本来就是从 Old Master 继承而来，自然就继承了 Old Master 的 listener fd，但是这里依然有一个问题：该怎么通知 New Master 呢？\n环境变量。execve 在执行的时候可以传入环境变量。实际上 Old Master 在 fork 之前会将所有 listener fd 添加到 NGINX 环境变量：\nngx_pid_t ngx_exec_new_binary(ngx_cycle_t *cycle, char *const *argv) { ... ctx.path = argv[0]; ctx.name = \u0026amp;quot;new binary process\u0026amp;quot;; ctx.argv = argv; n = 2; env = ngx_set_environment(cycle, \u0026amp;amp;n); ... env[n++] = var; env[n] = NULL; ... ctx.envp = (char *const *) env; ccf = (ngx_core_conf_t *) ngx_get_conf(cycle-\u0026amp;gt;conf_ctx, ngx_core_module); if (ngx_rename_file(ccf-\u0026amp;gt;pid.data, ccf-\u0026amp;gt;oldpid.data) == NGX_FILE_ERROR) { ... return NGX_INVALID_PID; } pid = ngx_execute(cycle, \u0026amp;amp;ctx); return pid; } Nginx 在启动的时候，会解析 NGINX 环境变量：\nstatic ngx_int_t ngx_add_inherited_sockets(ngx_cycle_t *cycle) { ... inherited = (u_char *) getenv(NGINX_VAR); if (inherited == NULL) { return NGX_OK; } if (ngx_array_init(\u0026amp;amp;cycle-\u0026amp;gt;listening, cycle-\u0026amp;gt;pool, 10, sizeof(ngx_listening_t)) != NGX_OK) { return NGX_ERROR; } for (p = inherited, v = p; *p; p++) { if (*p == \u0026#39;:\u0026#39; || *p == \u0026#39;;\u0026#39;) { s = ngx_atoi(v, p - v); ... v = p + 1; ls = ngx_array_push(\u0026amp;amp;cycle-\u0026amp;gt;listening); if (ls == NULL) { return NGX_ERROR; } ngx_memzero(ls, sizeof(ngx_listening_t)); ls-\u0026amp;gt;fd = (ngx_socket_t) s; } } ... ngx_inherited = 1; return ngx_set_inherited_sockets(cycle); } 一旦检测到是继承而来的 socket，那就说明已经打开了，不会再继续 bind + listen 了：\nngx_int_t ngx_open_listening_sockets(ngx_cycle_t *cycle) { ... /* TODO: configurable try number */ for (tries = 5; tries; tries--) { failed = 0; /* for each listening socket */ ls = cycle-\u0026amp;gt;listening.elts; for (i = 0; i \u0026amp;lt; cycle-\u0026amp;gt;listening.nelts; i++) { ... if (ls[i].inherited) { /* TODO: close on exit */ /* TODO: nonblocking */ /* TODO: deferred accept */ continue; } ... ngx_log_debug2(NGX_LOG_DEBUG_CORE, log, 0, \u0026amp;quot;bind() %V #%d \u0026amp;quot;, \u0026amp;amp;ls[i].addr_text, s); if (bind(s, ls[i].sockaddr, ls[i].socklen) == -1) { ... } ... } } if (failed) { ngx_log_error(NGX_LOG_EMERG, log, 0, \u0026amp;quot;still could not bind()\u0026amp;quot;); return NGX_ERROR; } return NGX_OK; } Envoy Envoy 使用的是单进程多线程模型，其局限就是无法通过环境变量来传递 listener fd。因此 Envoy 采用的是 UDS（unix domain sockets）方案。当 New Envoy 启动完成后，会通过 UDS 向 Old Envoy 请求 listener fd 副本， …","date":-62135596800,"description":"","dir":"projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"63ca389b7e6e0a585d0183ad71887f65","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","summary":"前言 本文是对 Nginx、Envoy 及 MOSN 的平滑升级原理区别的分析，适合对 Nginx 实现原理比较感兴趣的同学阅读，需要具备一定的网络编程知识。 平滑升级的","tags":null,"title":"Nginx vs Envoy vs MOSN 平滑升级原理解析","type":"projects","url":"/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","wordcount":1525},{"author":null,"categories":null,"content":" If you need to call SOFARPC through NodeJs, you can start by following this document.\nInstall First install the SOFARPC Node.\nhttps://github.com/sofastack/sofa-rpc-node\nUse the following command:\n$ npm install sofa-rpc-node --save Code sample Expose an RPC service and publish it to registry center \u0026#39;use strict\u0026#39;; const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, Address: \u0026#39;127.0.0.1:2181\u0026#39;, // need to start a zkServer locally }); // 2. Create an RPC Server instance const server = new RpcServer({ logger, Registry, // incoming registry client port: 12200, }); // 3. Add service server.addService({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }, { async plus(a, b) { return a + b; }, }); // 4. Start the server and publish the service server.start() .then(() =\u0026amp;gt; { server.publish(); }); Call RPC service (Get service list from registry center) \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); async function invoke() { // 2. Create an RPC Client instance const client = new RpcClient({ logger, registry, }); // 3. Create a service consumer const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }); // 4. Wait for the consumer ready (subscribe to the service list from registry center...) await consumer.ready(); // 5. Execute generic call const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); Call RPC service (direct call) \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const logger = console; async function invoke() { // No need to pass in the registry instance const client = new RpcClient({ logger, }); const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, serverHost: \u0026#39;127.0.0.1:12200\u0026#39;, // directly specify the service address }); await consumer.ready(); const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); Expose and call the protobuf interface Define interface Define the interface with *.proto\nsyntax = \u0026amp;quot;proto3\u0026amp;quot;; package com.alipay.sofa.rpc.test; // optional option java_multiple_files = false; service ProtoService { rpc echoObj (EchoRequest) returns (EchoResponse) {} } message EchoRequest { string name = 1; Group group = 2; } message EchoResponse { int32 code = 1; string message = 2; } enum Group { A = 0; B = 1; } Server code \u0026#39;use strict\u0026#39;; const antpb = require(\u0026#39;antpb\u0026#39;); const protocol = require(\u0026#39;sofa-bolt-node\u0026#39;); const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/node-and-java-communicate/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3329852e9991868a3cdc473b861ca750","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","summary":"If you need to call SOFARPC through NodeJs, you can start by following this document.\nInstall First install the SOFARPC Node.\nhttps://github.com/sofastack/sofa-rpc-node\nUse the following command:\n$ npm install sofa-rpc-node --save Code sample Expose an RPC service and publish it to registry center 'use strict'; const { RpcServer } = require('sofa-rpc-node').server; const { ZookeeperRegistry } = require('sofa-rpc-node').registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, Address: '127.","tags":null,"title":"NodeJS support","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","wordcount":635},{"author":null,"categories":null,"content":" 快速上手 如果你有通过 NodeJs 调用 SOFARPC 的需求.可以按照如下的文档来开始.\n安装 首先按照文档安装\nhttps://github.com/sofastack/sofa-rpc-node\n使用命令.\n$ npm install sofa-rpc-node --save 代码示例 暴露一个 RPC 服务，并发布到注册中心 \u0026#39;use strict\u0026#39;; const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. 创建 zk 注册中心客户端 const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, // 需要本地启动一个 zkServer }); // 2. 创建 RPC Server 实例 const server = new RpcServer({ logger, registry, // 传入注册中心客户端 port: 12200, }); // 3. 添加服务 server.addService({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }, { async plus(a, b) { return a + b; }, }); // 4. 启动 Server 并发布服务 server.start() .then(() =\u0026amp;gt; { server.publish(); }); 调用 RPC 服务（从注册中心获取服务列表） \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. 创建 zk 注册中心客户端 const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); async function invoke() { // 2. 创建 RPC Client 实例 const client = new RpcClient({ logger, registry, }); // 3. 创建服务的 consumer const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }); // 4. 等待 consumer ready（从注册中心订阅服务列表...） await consumer.ready(); // 5. 执行泛化调用 const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); 调用 RPC 服务（直连模式） \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const logger = console; async function invoke() { // 不需要传入 registry 实例了 const client = new RpcClient({ logger, }); const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, serverHost: \u0026#39;127.0.0.1:12200\u0026#39;, // 直接指定服务地址 }); await consumer.ready(); const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); 暴露和调用 protobuf 接口 接口定义 通过 *.proto 来定义接口\nsyntax = \u0026amp;quot;proto3\u0026amp;quot;; package com.alipay.sofa.rpc.test; // 可选 option java_multiple_files = false; service ProtoService { rpc echoObj (EchoRequest) returns (EchoResponse) {} } message EchoRequest { string name = 1; Group group = 2; } message EchoResponse { int32 code = 1; string message = 2; } enum Group { A = 0; B = 1; } 服务端代码 \u0026#39;use strict\u0026#39;; const antpb = require(\u0026#39;antpb\u0026#39;); const protocol = require(\u0026#39;sofa-bolt-node\u0026#39;); const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 传入 *.proto 文件存放的目录，加载接口定义 const proto = antpb.loadAll(\u0026#39;/path/proto\u0026#39;); // 将 proto 设置到协议中 protocol.setOptions({ proto }); const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); const server = new RpcServer({ logger, protocol, // 覆盖协议 registry, codecType: \u0026#39;protobuf\u0026#39;, // 设置默认的序列化方式为 protobuf port: 12200, }); server.addService({ interfaceName: …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/node-and-java-communicate/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3329852e9991868a3cdc473b861ca750","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","summary":"快速上手 如果你有通过 NodeJs 调用 SOFARPC 的需求.可以按照如下的文档来开始. 安装 首先按照文档安装 https://github.com/sofastack/sofa-rpc-node 使用命令. $ npm install sofa-rpc-node --save 代码示例 暴露一个 RPC 服务，并发布到注册","tags":null,"title":"Node跨语言调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","wordcount":757},{"author":null,"categories":null,"content":" OkHttp Integration In this document will demonstrate how to use SOFATracer to track of OkHttp, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nDependency introduction \u0026amp;lt;!-- SOFATracer dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- okhttp dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.squareup.okhttp3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;okhttp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.12.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs # port server.port=8081 Add a Controller that provides RESTful services In the project, provide a simple Controller, for example:\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8081/okhttp?name=sofa * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/okhttp\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;okhttp\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } Construct OkHttp to initiate a call to the RESTful service above The code example is as follows:\n Construct the OkHttp Client instance: OkHttpClientInstance httpClient = new OkHttpClientInstance(); String httpGetUrl = \u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;; String responseStr = httpClient.executeGet(httpGetUrl); Run Start the SOFABoot app and see the log in the console as follows:\n2019-04-12 13:38:09.896 INFO 51193 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2019-04-12 13:38:09.947 INFO 51193 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8081 (http) 2019-04-12 13:38:09.952 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Started OkHttpDemoApplication in 3.314 seconds (JVM running for 4.157) When there is a log similar to the following, the call to OkHttp is successful:\n2019-04-12 13:38:10.205 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;sofa\u0026amp;quot;} View log In the application.properties, the log printing directory we configured is ./logs, which is the root directory of the current application (we can configure it based on actual situation). In the root directory, you can see log files in the structure similar to …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-okhttp/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2b665b984dd33a4c04b5cd7b4de2410c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","summary":"OkHttp Integration In this document will demonstrate how to use SOFATracer to track of OkHttp, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nDependency introduction \u0026lt;!-- SOFATracer dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- okhttp dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.squareup.okhttp3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;okhttp\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.12.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.","tags":null,"title":"OkHttp Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","wordcount":374},{"author":null,"categories":null,"content":" OkHttp Log Format SOFATracer integrates OkHttp and outputs the requested link log data format. The default is JSON data format.\nOkHttp digest log（okhttp-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code req.size.bytes Request Body Size resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.app remote app baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-12 13:38:10.187\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe85a1555047489980100151193\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:207,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} OkHttp stat log（okhttp-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-12 13:39:09.720\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:207,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-okhttp/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dbc9555f43d0b2eda22f10ed45713fb9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","summary":"OkHttp Log Format SOFATracer integrates OkHttp and outputs the requested link log data format. The default is JSON data format.\nOkHttp digest log（okhttp-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.","tags":null,"title":"OkHttp log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","wordcount":174},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 OkHttp 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;!-- SOFATracer 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- okhttp 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.squareup.okhttp3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;okhttp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.12.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=OkHttpClientDemo # logging path logging.path=./logs # port server.port=8081 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8081/okhttp?name=sofa * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/okhttp\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;okhttp\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } 构造 OkHttp 发起一次对上文的 RESTful 服务的调用 代码示例如下：\n 构造 OkHttp Client 调用实例： OkHttpClientInstance httpClient = new OkHttpClientInstance(); String httpGetUrl = \u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;; String responseStr = httpClient.executeGet(httpGetUrl); 运行 启动 SOFABoot 应用，在控制台中看到启动打印的日志如下：\n2019-04-12 13:38:09.896 INFO 51193 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2019-04-12 13:38:09.947 INFO 51193 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8081 (http) 2019-04-12 13:38:09.952 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Started OkHttpDemoApplication in 3.314 seconds (JVM running for 4.157) 当有类似如下的日志时，说明 OkHttp 的调用成功：\n2019-04-12 13:38:10.205 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;sofa\u0026amp;quot;} 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要进行配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── okhttp-digest.log ├── okhttp-stat.log ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 示例中通过构造 OkHttp 对象发起 RESTful 服务的调用，调用完成后可以在 okhttp-digest.log 中看到类似如下的日志:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-okhttp/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2b665b984dd33a4c04b5cd7b4de2410c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","summary":"在本文档将演示如何使用 SOFATracer 对 OkHttp 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;!-- SOFATracer 依","tags":null,"title":"OkHttp 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","wordcount":578},{"author":null,"categories":null,"content":" SOFATracer 集成 OkHttp 后输出请求的链路数据格式，默认为 JSON 数据格式。\nOkHttp 摘要日志（okhttp-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId request.url 请求 URL method 请求 HTTP 方法 result.code HTTP 返回状态码 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 time.cost.milliseconds 请求耗时（ms） current.thread.name 当前线程名 remote.app 目标应用 baggage 透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 11:35:28.429\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567481728265100112783\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;164ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} OkHttp 统计日志（okhttp-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 11:43:06.975\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:174,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-okhttp/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dbc9555f43d0b2eda22f10ed45713fb9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","summary":"SOFATracer 集成 OkHttp 后输出请求的链路数据格式，默认为 JSON 数据格式。 OkHttp 摘要日志（okhttp-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下","tags":null,"title":"OkHttp 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","wordcount":330},{"author":null,"categories":null,"content":" OpenFeign Integration In this document will demonstrate how to use SOFATracer to track of OpenFeign.\nPrepare Environment The versions of the framework components used in this case are as follows:\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 This case includes two submodules:\n tracer-sample-with-openfeign-provider service provider tracer-sample-with-openfeign-consumer service consumer New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026amp;rsquo;s dependency. First, you need to unzip the generated zip package of Spring Boot project and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more information about SOFABoot versions, refer to Release notes.\nNew tracer-sample-with-openfeign-provider Module Introducing dependence\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer versions are controlled by SOFABoot versions. If the SOFABoot versions used do not match, you need to manually specify a tracer version that is higher than 3.0.4.\n application.properties Configuration spring.application.name=tracer-provider server.port=8800 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-provider Simple resource class\n@RestController public class UserController { @RequestMapping(\u0026amp;quot;/feign\u0026amp;quot;) public String testFeign(HttpServletRequest request) { return \u0026amp;quot;hello tracer feign\u0026amp;quot;; } } New tracer-sample-with-openfeign-consumer Module Introducing dependence \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-openfeign/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"75d9940033ad3b4342eab9d5c7a191f1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","summary":"OpenFeign Integration In this document will demonstrate how to use SOFATracer to track of OpenFeign.\nPrepare Environment The versions of the framework components used in this case are as follows:\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 This case includes two submodules:\n tracer-sample-with-openfeign-provider service provider tracer-sample-with-openfeign-consumer service consumer New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026rsquo;s dependency.","tags":null,"title":"OpenFeign Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","wordcount":368},{"author":null,"categories":null,"content":" OpenFeign Log Format SOFATracer integrates Spring Cloud OpenFeign and outputs the requested link log data format. The default is JSON data format.\nSpring Cloud OpenFeign digest log（feign-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code error error massage req.size.bytes Request Body Size resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.host remote host remote.port remote port component.client.impl component name baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-03-28 18:08:06.800\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe88f1553767685981100124403\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.232.143:8800/feign\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:18,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:206,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8082-exec-1\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.232.143\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;8800\u0026amp;quot;,\u0026amp;quot;component.client.impl\u0026amp;quot;:\u0026amp;quot;open-feign\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring Cloud OpenFeign stat log（feign-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success ; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-03-28 18:09:06.800\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.232.143:8800/feign\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:206,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;Y\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-openfeign/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"81864817e297a7bf019705c72f8ff0a8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","summary":"OpenFeign Log Format SOFATracer integrates Spring Cloud OpenFeign and outputs the requested link log data format. The default is JSON data format.\nSpring Cloud OpenFeign digest log（feign-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.","tags":null,"title":"OpenFeign log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","wordcount":190},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 Spring Cloud OpenFeign 进行埋点。\n基础环境 本案例使用的各框架组件的版本如下：\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 本案例包括两个子工程：\n tracer-sample-with-openfeign-provider 服务提供方 tracer-sample-with-openfeign-consumer 服务调用方 新建 SOFABoot 工程作为父工程 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 Maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n新建 tracer-sample-with-openfeign-provider 在工程模块的 pom 文件中添加 SOFATracer 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer 版本受 SOFABoot 版本管控，如果使用的 SOFABoot 版本不匹配，则需要手动指定 tracer 版本，且版本需高于 3.0.4.\n 在工程的 application.properties 文件下添加相关参数 spring.application.name=tracer-provider server.port=8800 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-provider 简单的资源类\n@RestController public class UserController { @RequestMapping(\u0026amp;quot;/feign\u0026amp;quot;) public String testFeign(HttpServletRequest request) { return \u0026amp;quot;hello tracer feign\u0026amp;quot;; } } 新建 tracer-sample-with-openfeign-consumer 在工程模块的 pom 文件中添加 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 在工程的 application.properties 文件下添加相关参数\nspring.application.name=tracer-consumer server.port=8082 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-consumer 定义 feign 资源 @FeignClient(value = \u0026amp;quot;tracer-provider\u0026amp;quot;,fallback = FeignServiceFallbackFactory.class) public interface FeignService { @RequestMapping(value = \u0026amp;quot;/feign\u0026amp;quot;, method = RequestMethod.GET) …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-openfeign/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"75d9940033ad3b4342eab9d5c7a191f1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","summary":"在本文档将演示如何使用 SOFATracer 对 Spring Cloud OpenFeign 进行埋点。 基础环境 本案例使用的各框架组件的版本如下： Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 本案例包括两个子工程： tracer-sample-with-openfeign-provider 服务提供方 tracer-sample-with-openfeign-consumer","tags":null,"title":"OpenFeign 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","wordcount":602},{"author":null,"categories":null,"content":" SOFATracer 集成 Spring Cloud OpenFeign 后输出请求的链路数据格式，默认为 JSON 数据格式。\nSpring Cloud OpenFeign 摘要日志（feign-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method error 错误信息 req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:28:52.363\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477731347100110969\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8082-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;219ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.233.39:8800/feign\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:18,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.233.39\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;8800\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring Cloud OpenFeign 统计日志（feign-stat.log）ls stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:29:34.528\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.233.39:8800/feign\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:378,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-openfeign/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"81864817e297a7bf019705c72f8ff0a8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","summary":"SOFATracer 集成 Spring Cloud OpenFeign 后输出请求的链路数据格式，默认为 JSON 数据格式。 Spring Cloud OpenFeign 摘要日志（feign-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解","tags":null,"title":"OpenFeign 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","wordcount":341},{"author":null,"categories":null,"content":" MOSN\u0026amp;rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer Acknowledgement MOSN builds on open source projects such as Envoy and Istio, thanks to the efforts of the open source community.\n","date":-62135596800,"description":"","dir":"projects/mosn/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f25c59cbb758b4dae5de39e1f1c3a2f4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/mosn/overview/","summary":"MOSN\u0026rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/mosn/overview/","wordcount":245},{"author":null,"categories":null,"content":" MOSN\u0026amp;rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer Acknowledgement MOSN builds on open source projects such as Envoy and Istio, thanks to the efforts of the open source community.\n","date":-62135596800,"description":"","dir":"projects/occlum/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1d8851c81ed6dacf04ebbe841d1b2835","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/occlum/overview/","summary":"MOSN\u0026rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/occlum/overview/","wordcount":245},{"author":null,"categories":null,"content":" Introduction SOFALookout is a lightweight and open source middleware service of Ant Financial that solves the metrics and monitoring issues of the system. The services it provides include: Event logging, collecting, processing, storing, and querying of Metrics. The open source project consists of two separate parts, the client and server side services.\nClient-side service SOFALookout Client is a Java SDK that helps developers log events of metrics in project code. It also allows you to view real-time status information for the Java application.\n +------------------+ Reg: API: | dimension meters +--------+ +------------------+ | flatmap +---------------------------+ +-----------\u0026amp;gt; | Default/DropwizardMetrics| | +---------------------------+ | | http +--------------+ +-----------\u0026amp;gt; |Lookout server| | +--------------+ +----------------------+ | add common tags dimension EXTS: | JVM,OS,GC... +----+ +----------------------+ Server-side services SOFALookout Server helps you solve system state metrics in a distributed environment. Its data sources include, but not limited to the projects that use the lookout-client package. The server will be available in the next release, so stay tuned.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/overview/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"8a8a8ef02ca95d4d11e3e4b195bbae70","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/overview/","summary":"Introduction SOFALookout is a lightweight and open source middleware service of Ant Financial that solves the metrics and monitoring issues of the system. The services it provides include: Event logging, collecting, processing, storing, and querying of Metrics. The open source project consists of two separate parts, the client and server side services.\nClient-side service SOFALookout Client is a Java SDK that helps developers log events of metrics in project code.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/overview/","wordcount":160},{"author":null,"categories":null,"content":" SOFARPC is a Java-based RPC service framework open sourced by Ant Financial, which provides remote service call between applications, high scalability and fault tolerance features. Currently, all RPC calls of Ant Financial businesses use SOFARPC. SOFARPC provides users with functions such as load balancing, traffic forwarding, link tracing, link data transparent transmission, and fault removal.\nIn addition, SOFARPC supports different protocols, currently including bolt, RESTful, dubbo, and H2C. Bolt is a network communication framework based on Netty developed by Ant Financial Services Group.\nImplementation principle When an SOFARPC application is started, if the current application needs to publish RPC services, SOFARPC will register these services to the service registry center. As shown in the figure, the service points to the Registry. When the SOFARPC application that references this service is started, it subscribes to the metadata information of the corresponding service from the service registry. After receiving the subscription request, the service registry will push the publisher\u0026amp;rsquo;s metadata list to the service reference party in real time. As shown in the figure, Register points to Reference. When the service reference party gets the addresses, it can pick up the address and initiate the call. As shown in the figure, Reference points to Service. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"62f0806ad40fcaaeab6a82470b14a2e2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/overview/","summary":"SOFARPC is a Java-based RPC service framework open sourced by Ant Financial, which provides remote service call between applications, high scalability and fault tolerance features. Currently, all RPC calls of Ant Financial businesses use SOFARPC. SOFARPC provides users with functions such as load balancing, traffic forwarding, link tracing, link data transparent transmission, and fault removal.\nIn addition, SOFARPC supports different protocols, currently including bolt, RESTful, dubbo, and H2C. Bolt is a network communication framework based on Netty developed by Ant Financial Services Group.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/overview/","wordcount":203},{"author":null,"categories":null,"content":" Introduction This sample project shows how to build an executable-ark-jar based on a springboot project with the tool of sofa-ark-maven-plugin.\nPreparation As this project depends on the ark-plugin generated by the project of sample-ark-plugin, please ensure the sample sample-ark-plugin installed in your local maven repository before run this project.\nTools The Maven plugin of sofa-ark-maven-plugin is provided to build a standard executable-ark-jar, and just needs some simple configurations. Its maven coordinates is:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Refer to the document of plugin use for details\n Step By Step Based on the sample project, we will describe step by step how to package a Spring Boot Web project to an executable Ark package\nCreating Spring Boot Web Project Download a standard Spring Boot Web project from the official website https://start.spring.io/\nIntroducing sample-ark-plugin Configure items as follows under the main pom.xml of the project, and add the Ark Plugin dependency generated from another sample project, reference documents\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configuring Packaging Plugin Configure the Maven plugin (sofa-Ark-maven-plugin) as follows under the main pom.xml of the project:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; In this sample project, we have configured only a fraction of the items, but they are enough to generate an executable Ark package. The meaning of each configuration item is shown below: * outputDirectory: the directory for the output Ark package files after packaging of mvn package;\n arkClassifier: the value of classifier included in the Maven coordinates of the Ark specified for release, which is null by default; Note that arkClassifier is null by default. If you do not specify a classifier, the Jar package uploaded to the repository is actually an executable Ark package. If you need to distinguish it from common packaging, you need to configure a value for this …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-demo/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2c97c409788f41051c79836d277997be","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","summary":"Introduction This sample project shows how to build an executable-ark-jar based on a springboot project with the tool of sofa-ark-maven-plugin.\nPreparation As this project depends on the ark-plugin generated by the project of sample-ark-plugin, please ensure the sample sample-ark-plugin installed in your local maven repository before run this project.\nTools The Maven plugin of sofa-ark-maven-plugin is provided to build a standard executable-ark-jar, and just needs some simple configurations. Its maven coordinates is:","tags":null,"title":"Package into Ark JAR","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","wordcount":757},{"author":null,"categories":null,"content":" Introduction This sample project demonstrates how to use Maven plugins to package a general Java project into an Ark plugin that meets the standard specifications.\nBackground In actual development, dependency conflicts often occur. Suppose we have developed a class library named sample-lib, and it might conflict with the existing dependencies when the business application is imported. At this point, we hope the library can be isolated from other business dependencies, without negotiating with each other over dependency package versions. Ark Plugin is exactly the result of our best practice under this demand background. It runs on top of the Ark Container, which is loaded by a container. Any Ark Plugin is loaded by a separate ClassLoader to be isolated from each other. There are four concepts of Ark Plugin: * Import class: When the plugin starts up, a plugin used to export the class is first delegated to load the class. If that fails, it will attempt to load from inside this plugin;\n Export class: If the class has been imported by other plugins, it will be first loaded from this plugin;\n Import resource: When the plugin is searching for resources, a plugin used to export the class is first delegated to load the class. If that fails, it will attempt to load from inside this plugin.\n Export resource: If the resource has been imported by other plugins, it will be first loaded from this plugin;\n Refer to the plugin specifications for more details\n Tools Upon simple configurations, the officially provided Maven plugin sofa-ark-plugin-maven-plugin can package common Java projects into a standard-format Ark Plugin. The coordinates of Maven plugin are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; For more information, see the plugin configuration document\n Getting started Based on this sample project, we will describe how to build an Ark plugin step by step.\nCreate a Standard Maven Project This is a standard Maven project consisting of two modules: * The common module: contains the plugin export class\n The plugin module: contains com.alipay.sofa.ark.spi.service.PluginActivator interface implementation class and a plugin service class. The plugin packaging tool sofa-ark-plugin-maven-plugin can be configured in the module\u0026amp;rsquo;s pom.xml file; Configuring Packaging Plugin Package the plugin in the pom.xml file according to the following configurations:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${project.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--can only configure no more than one activator--\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin-demo/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d8125843ced13352dd228299f222c74d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","summary":"Introduction This sample project demonstrates how to use Maven plugins to package a general Java project into an Ark plugin that meets the standard specifications.\nBackground In actual development, dependency conflicts often occur. Suppose we have developed a class library named sample-lib, and it might conflict with the existing dependencies when the business application is imported. At this point, we hope the library can be isolated from other business dependencies, without negotiating with each other over dependency package versions.","tags":null,"title":"Package into Ark Plugin","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","wordcount":664},{"author":null,"categories":null,"content":"SOFA Mesh 项目 fork 了 Istio 项目，对 Pilot 的能力进行增强，目前在进行中的增强主要集中在下面三个方面： - 支持 Zookeeper 作为注册中心，并在此基础上支持 SOFA、DUBBO 等使用 Zookeeper 作为注册中心的微服务框架。 - 支持通用协议框架，使用一个通用协议，在 Kubernetes DNS 的基础上同时支持多种协议。 - 新增 register agent，支持 SOFA、DUBBO 和 HSF 的容器模型，即支持单个应用注册多个服务实例。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-readme/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7b098e394986596d8fb01e1fe2120829","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-readme/","summary":"SOFA Mesh 项目 fork 了 Istio 项目，对 Pilot 的能力进行增强，目前在进行中的增强主要集中在下面三个方面： - 支持 Zookeeper 作为注册中心，并在此基础上支持 SOFA、DUBBO","tags":null,"title":"Pilot 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-readme/","wordcount":168},{"author":null,"categories":null,"content":" Print traceId And spanId To Application Log SLF4J provides MDC (Mapped Diagnostic Contexts), which supports you to define and modify log output formats and content. This document introduces the SLF4J MDC feature integrated in SOFATracer, which allows you to output the current SOFATracer context TraceId and SpanId with simply modifying the log configuration file.\nPrerequisites In order to properly print the TraceId and SpanId parameters in the logs of the application, the log programming interface needs to be programmed for SLF4J. That is, the programming interface for printing log does not rely on specific log implementation.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce dependency For SOFABoot or Spring Boot application, you need to introduce the specific log implementation. It is recommended to introduce Logback and Log4j2 instead of Log4j. Also, it is suggested to use only one log implementation rather than multiple implementations.\n Logback implementation: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Log4j2 implementation: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-log4j2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!--SOFABoot does not control log4j2 version --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configuration method The corresponding TraceId and SpanId are printed based on SLF4J MDC. First, the log programming interface in application should be oriented to SLF4J, as follows:\n/ / Introduce interface import org.slf4j.Logger; import org.slf4j.LoggerFactory; / / Construct log printing instance private static final Logger logger = LoggerFactory.getLogger(XXX.class); Second, to correctly print the TraceId and SpanId parameters, we also need to configure the extra parameters of PatternLayout in the log configuration file. The two parameters are %X{SOFA-TraceId} and %X. {SOFA-SpanId}, whose values ​​can be obtained from MDC.\npattern parameter configured with Logback as an example:\n\u0026amp;lt;pattern\u0026amp;gt;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId}, %X{SOFA-SpanId}] ---- %m%n\u0026amp;lt;/pattern\u0026amp;gt; Key configuration items: As a part of the Logback pattern, [%X{SOFA-TraceId},%X{SOFA-SpanId}] replaces the placeholders in the pattern with the specific TraceId and SpanId in the current thread process when the corresponding appender is called. If there is no corresponding TraceId and SpanId in the current thread, the placeholder is replaced with \u0026amp;ldquo;null\u0026amp;rdquo;. Log4j2 PatternLayout configuration sample:\n\u0026amp;lt;PatternLayout pattern=\u0026amp;quot;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId},%X{SOFA-SpanId}] ---- %m%n \u0026amp;quot; /\u0026amp;gt; Log4j PatternLayout configuration sample:\n\u0026amp;lt;layout class=\u0026amp;quot;org.apache.log4j.PatternLayout\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;param …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/print-traceid-spanid/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0d8cc680f811d1db2cffddbba269571c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","summary":"Print traceId And spanId To Application Log SLF4J provides MDC (Mapped Diagnostic Contexts), which supports you to define and modify log output formats and content. This document introduces the SLF4J MDC feature integrated in SOFATracer, which allows you to output the current SOFATracer context TraceId and SpanId with simply modifying the log configuration file.\nPrerequisites In order to properly print the TraceId and SpanId parameters in the logs of the application, the log programming interface needs to be programmed for SLF4J.","tags":null,"title":"Print traceId and spanId in application log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","wordcount":360},{"author":null,"categories":null,"content":"Describe several methods to use SOFARPC in different environments. * Use API in non-Spring environment * Use XML in SOFABoot environment * Use Annotation in SOFABoot environment * Use dynamic API in SOFABoot environment\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programming/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"9a947dae761c84aa4d95121c076ac552","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programming/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programming/","summary":"Describe several methods to use SOFARPC in different environments. * Use API in non-Spring environment * Use XML in SOFABoot environment * Use Annotation in SOFABoot environment * Use dynamic API in SOFABoot environment","tags":null,"title":"Programming","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programming/","wordcount":34},{"author":null,"categories":null,"content":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-samples/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"600c182fdee786a59e14899ba0fce8a1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-run-samples/","summary":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-run-samples/","wordcount":42},{"author":null,"categories":null,"content":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-run-samples/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"93784b2fca67986e00aa3bc5ea0dbb6b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-run-samples/","summary":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-run-samples/","wordcount":42},{"author":null,"categories":null,"content":" Some sample projects are provided in the source project to assist in the use of the project. The readme file of the sample project has additional instructions for use, and you need to import these sample projects separately into IDE.\nClient-side sample project lookout-client-samples-java  This sample project demonstrates how to use and configure the client in code form in a normal Java project.\n lookout-client-samples-boot  This sample project demonstrates how to use and configure the client in a SpringBoot (or SofaBoot) project.\n lookout-client-samples-prometheus  The sample project demonstrates how to use and configure the client to use prometheus in a SpringBoot (or SofaBoot) project.\nServer-side sample project ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-samples/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a8a0fcd3f99ce2fb46e4d543e30797c9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","summary":"Some sample projects are provided in the source project to assist in the use of the project. The readme file of the sample project has additional instructions for use, and you need to import these sample projects separately into IDE.\nClient-side sample project lookout-client-samples-java  This sample project demonstrates how to use and configure the client in code form in a normal Java project.\n lookout-client-samples-boot  This sample project demonstrates how to use and configure the client in a SpringBoot (or SofaBoot) project.","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","wordcount":105},{"author":null,"categories":null,"content":" SOFABoot provides developers with three ways to publish and reference JVM services\n XML Annotation Programming API XML Service Publish First, we need to define a Bean:\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; Then, publish the Bean as a SOFA JVM service by using the Spring extension tag provided by SOFA.\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; In the preceding configuration, the interface parameter indicates the interface for releasing services, and the ref parameter indicates the Bean to be published as a JVM service.\nAt this point, we have published a JVM service success.\nService Reference We can also reference a JVM service by using the Spring extension tag provided by SOFA.\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; In the preceding configuration, the interface parameter indicates the service interface, which must be consistent with that configured during the service publish. The meaning of the ID attribute is the same as Spring BeanId. A Spring Bean with the ID sampleServiceRef will be generated from the above configuration. We can inject it anywhere in the Spring context of the current SOFABoot module.\n service/reference tag also supports RPC service publish, with related document: RPC Service Publish and Reference\n Annotation Warning\nIf a service has been annotated with @SofaService, it cannot be published in the mode of XML. Choose one mode to publish the service instead of a mixture of two modes.\n In addition to publishing JVM services and reference through XML, SOFABoot also provides Annotation for JVM services publish and reference. To publish JVM services through Annotation, we only need to add an annotation @SofaService to the implementation class, as follows:\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } Prompt\n@SofaService is used to publish a Spring Bean as a JVM service, which means that although you may not write the configuration of \u0026amp;lt;sofa:service/\u0026amp;gt;, you still need to configure the class annotated with @SofaService as a Spring Bean.\n When configuring \u0026amp;lt;sofa:service/\u0026amp;gt; in the XML mode, you have configured an interface for the service. However, when using the @SofaService annotation, you haven\u0026amp;rsquo;t configured the service interface. This is because when the class annotated with @SofaService has implemented only one interface, the framework directly uses the interface as the service interface. What if the class annotated with @SofaService has implemented multiple interfaces? In this case, you can set the interfaceType field of @SofaService to specify the service interface, as shown below: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/module-service/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"527472fbe57ce450e4e2b41d878704cb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/module-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/module-service/","summary":"SOFABoot provides developers with three ways to publish and reference JVM services\n XML Annotation Programming API XML Service Publish First, we need to define a Bean:\n\u0026lt;bean id=\u0026quot;sampleService\u0026quot; class=\u0026quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026quot;\u0026gt; Then, publish the Bean as a SOFA JVM service by using the Spring extension tag provided by SOFA.\n\u0026lt;sofa:service interface=\u0026quot;com.alipay.sofa.runtime.test.service.SampleService\u0026quot; ref=\u0026quot;sampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.jvm/\u0026gt; \u0026lt;/sofa:service\u0026gt; In the preceding configuration, the interface parameter indicates the interface for releasing services, and the ref parameter indicates the Bean to be published as a JVM service.","tags":null,"title":"Publish and reference JVM services","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/module-service/","wordcount":1001},{"author":null,"categories":null,"content":" To run this demo, you should sign up an Ant Financial technology account. Please see Ant Finanical Official Site to see more details.\nDemo content Service Mesh applies the communication capabilities between services to the infrastructure, thus decoupling and lightweighting applications.\nHowever, Service Mesh itself is still complex. CloudMesh can easily implement Service Mesh technology by hosting Service Mesh on the cloud.\nWith our workshop, you can easily deploy applications developed in multiple programming languages ​​to CloudMesh, thereby experiencing the capabilities of Service Mesh. The capabilities include accessing services, monitoring traffic, experiencing service goverance, managing Sidecar, and gray release of new versions of services.\nThis demo focuses on the powerful traffic control capability of CloudMesh. In the process of gray release, you can precisely control the gray traffic ratio, and monitor the actual traffic trend in CloudMesh:\nThe general gray release function occupies twice capacity in the gray process.\nThe gray release function of CloudMesh does not need to occupy extra capacity in gray release process, and also allows pausing the release process to modify gray ratio multiple times.\nOperation guide For convenience, we have prepared a detailed operation guide for this demo.\nClick here to visit online version.\n","date":-62135596800,"description":"This guide introduces how to quickly deploy applications to CloudMesh, access services, monitor traffic, experience service governance, manage Sidecar, and perform gray release of new versions of services.","dir":"guides/kc-cloud-mesh-demo/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e389a65e6736e909718275cd76505525","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-cloud-mesh-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/guides/kc-cloud-mesh-demo/","summary":"To run this demo, you should sign up an Ant Financial technology account. Please see Ant Finanical Official Site to see more details.\nDemo content Service Mesh applies the communication capabilities between services to the infrastructure, thus decoupling and lightweighting applications.\nHowever, Service Mesh itself is still complex. CloudMesh can easily implement Service Mesh technology by hosting Service Mesh on the cloud.\nWith our workshop, you can easily deploy applications developed in multiple programming languages ​​to CloudMesh, thereby experiencing the capabilities of Service Mesh.","tags":null,"title":"Put Service Mesh into practice with CloudMesh","type":"guides","url":"/sofastack.tech/en/guides/kc-cloud-mesh-demo/","wordcount":199},{"author":null,"categories":null,"content":" This topic comprises four parts:\n Part 1: Install the ACTS IDE visual editor on Intellij IDEA. Part 2: Import the ACTS dependency to a multi-module project. Part 3: Establish the ACTS framework in the test module to manage ACTS test cases. Part 4: Generate the ACTS test script. 1. Install ACTS IDE We recommend that you use Intellij IDEA 2017. For the sake of your data security, please download the ACTS IDE installation package from the following source only: Click to download ACTS IDE.\nLocal installation: Choose Preferences \u0026amp;gt; Plugins. Install the plugin from disk and restart Intellij IDEA. 2. Import the ACTS dependency Before introducing the dependencies, make sure your application is a multi-module project (including the test module). After you import the dependency, ACTS places all test code under the test module for convenient ACTS test case management.\nYou can read the following information based on the actual situation of your application:\nIf your application is a complete multi-module project, you can refer to section 2.1 to import the ACTS dependency. If your application is a multi-module project without a test module, you can refer to section 2.2 to quickly create a test module. If your application is not a multi-module project, you can refer to section 2.3 to quickly create a multi-module project. If you have not created a project yet, you can use SOFABoot to quickly create an application.\n2.1 Multi-module application - with the test module You only need to import acts-bom to the pom.xml file of the test module.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2 Multi-module application - without the test module Here, Intellij IDEA is used to create the submodule.\nRight click the parent project, choose New \u0026amp;gt; Module, and enter the name for the test module, which follows the pattern of appname-test. The step-by-step procedure is illustrated in the following figures.\nStep 1: Create a test module Step 2: Manage the test module Manage the test module that you have created in the pom.xml file under the parent project.\nStep 3: Import the ACTS dependency Find the test module that you just created and import acts-bom to its pom.xml file.\n\u0026amp;lt;! -- Import the pom file that contains SOFABootApplication --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.example\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;example-service\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;! -- Import the ACTS dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.3 Single-module application If you already have a sound single-module SOFABoot application, you can quickly create a multi-module project based on the existing project in the following …","date":-62135596800,"description":"","dir":"projects/sofa-acts/getting-started/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dfc5fb9b394ea14c280568dcb881a8b0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/getting-started/","summary":"This topic comprises four parts:\n Part 1: Install the ACTS IDE visual editor on Intellij IDEA. Part 2: Import the ACTS dependency to a multi-module project. Part 3: Establish the ACTS framework in the test module to manage ACTS test cases. Part 4: Generate the ACTS test script. 1. Install ACTS IDE We recommend that you use Intellij IDEA 2017. For the sake of your data security, please download the ACTS IDE installation package from the following source only: Click to download ACTS IDE.","tags":null,"title":"Quick start","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/getting-started/","wordcount":650},{"author":null,"categories":null,"content":" This topic helps you quickly download, install, and use SOFADashboard on your computer.\nPrepare the environment sofa-dashboard-backend needs to be run in a Java environment. Make sure that it can be used normally in the following runtime environments:\n JDK 1.8+: Download and Configure. Maven 3.2.5+: Download and Configure. sofa-dashboard-frontend uses the Ant Design Pro scaffold. For more information about the frontend environment, see Ant Design.\nInitialize the database MySQL version: 5.6+\n SOFAArk control uses MySQL for resource data storage. You can find the SofaDashboardDB.sql script under the project directory and run this script to initialize database tables.\nZooKeeper ZooKeeper 3.4.x and ZooKeeper 3.5.x\n Service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper, therefore you need to start the ZooKeeper service locally. For more information, see ZooKeeper Document.\nRun the backend project \u0026amp;gt; git clone https://github.com/sofastack/sofa-dashboard.git \u0026amp;gt; cd sofa-dashboard \u0026amp;gt; mvn clean package -DskipTests \u0026amp;gt; cd sofa-dashboard-backend/sofa-dashboard-web/target/ \u0026amp;gt; java -jar sofa-dashboard-web-1.0.0-SNAPSHOT.jar Run the frontend project sofa-dashboard-front is the frontend code-based project of SOFADashboard. It is developed based on the open-source frontend framework antd of Ant Financial.\n\u0026amp;gt; cd sofa-dashboard-front \u0026amp;gt; npm i \u0026amp;gt; npm start ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/quick-start/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fa4c5f48810727f71d675255f19617a3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/quick-start/","summary":"This topic helps you quickly download, install, and use SOFADashboard on your computer.\nPrepare the environment sofa-dashboard-backend needs to be run in a Java environment. Make sure that it can be used normally in the following runtime environments:\n JDK 1.8+: Download and Configure. Maven 3.2.5+: Download and Configure. sofa-dashboard-frontend uses the Ant Design Pro scaffold. For more information about the frontend environment, see Ant Design.\nInitialize the database MySQL version: 5.","tags":null,"title":"Quick start","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/quick-start/","wordcount":186},{"author":null,"categories":null,"content":" This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment. Install Go\u0026amp;rsquo;s build environment. Install dep. See the official installation documentation. Get codes The codes for the MOSN project are hosted in GitHub and can be obtained in the following way:\ngo get mosn.io/mosn If an error occurs when run \u0026amp;ldquo;go get\u0026amp;rdquo;, just create the project manually.\n# Enter src dirctory under GOPATH cd $GOPATH/src # Create mosn.io dirctory mkdir -p mosn.io cd mosn.io # clone MOSN codes git clone git@github.com:mosn/mosn.git cd sofa-mosn The final path of MOSN source codes is $GOPATH/src/mosn.io/mosn.\nImport by using IDE Use the Golang IDE to import the $GOPATH/src/mosn.io/mosn project. Goland is recommended.\nCompile codes In the project root directory, select the following command to compile the MOSN binary file according to your machine type and the environment where you want to execute binary:\nCompile with Docker image\nmake build // compile linux 64bit executable binary non-docker, local compilation\nCompile local executable binary files.\nmake build-local Non-Linux machine compiles Linux 64-bit executable binary files crosswise.\nmake build-linux64 Non-Linux machine compiles Linux 32-bit executable binary files crosswise.\nmake build-linux32 Once compiled, the compiled binary files can be found in the build/bundles/${version}/binary directory.\nCreate image Run the following command to create an image:\nmake image Run test In the project root directory, run the unit test:\nmake unit-test In the project root directory, run the integrate test(slow):\nmake integrate Start MOSN from configuration file ./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; Start MOSN forwarding sample program See the sample project in the examples directory.\nUse MOSN to build a Service Mesh platform See Integrate Istio.\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-setup/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d41615315adb522aa4b84762f113a574","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-setup/","summary":"This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-setup/","wordcount":325},{"author":null,"categories":null,"content":" This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment. Install Go\u0026amp;rsquo;s build environment. Install dep. See the official installation documentation. Get codes The codes for the MOSN project are hosted in GitHub and can be obtained in the following way:\ngo get mosn.io/mosn If an error occurs when run \u0026amp;ldquo;go get\u0026amp;rdquo;, just create the project manually.\n# Enter src dirctory under GOPATH cd $GOPATH/src # Create mosn.io dirctory mkdir -p mosn.io cd mosn.io # clone MOSN codes git clone git@github.com:mosn/mosn.git cd sofa-mosn The final path of MOSN source codes is $GOPATH/src/mosn.io/mosn.\nImport by using IDE Use the Golang IDE to import the $GOPATH/src/mosn.io/mosn project. Goland is recommended.\nCompile codes In the project root directory, select the following command to compile the MOSN binary file according to your machine type and the environment where you want to execute binary:\nCompile with Docker image\nmake build // compile linux 64bit executable binary non-docker, local compilation\nCompile local executable binary files.\nmake build-local Non-Linux machine compiles Linux 64-bit executable binary files crosswise.\nmake build-linux64 Non-Linux machine compiles Linux 32-bit executable binary files crosswise.\nmake build-linux32 Once compiled, the compiled binary files can be found in the build/bundles/${version}/binary directory.\nCreate image Run the following command to create an image:\nmake image Run test In the project root directory, run the unit test:\nmake unit-test In the project root directory, run the integrate test(slow):\nmake integrate Start MOSN from configuration file ./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; Start MOSN forwarding sample program See the sample project in the examples directory.\nUse MOSN to build a Service Mesh platform See Integrate Istio.\n","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-setup/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"cd757e2e2cca38a99b2de1c0be1f6807","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-setup/","summary":"This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-setup/","wordcount":325},{"author":null,"categories":null,"content":" In this document, we will create a Spring Boot project and introduce the basic dependencies of SOFABoot as well as its Health Check expansion capability, to demonstrate how to get started quickly with SOFABoot.\nEnvironment Preparation To use SOFABoot, we need to prepare the basic environment first. SOFABoot depends on the following environment: - JDK7 or JDK8 - Needs to be compiled with Apache Maven 3.2.5 or above\nCreate Project SOFABoot is directly built on Spring Boot, so it can be generated by Spring Boot Generators. In this document, we need to add a web dependency for final view of its effect in the browser.\nAdd SOFABoot dependencies When creating a Spring Boot project, we need to import SOFABoot dependencies. First, extract the \u0026amp;lsquo;zip\u0026amp;rsquo; package of the project generated above and modify the \u0026amp;lsquo;pom.xml\u0026amp;rsquo; file, or the maven project configuration file. Replace\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; as:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Here, ${sofa.boot.version} denotes the SOFABoot version (please refer to release note). Then, add a SOFABoot dependency of Health Check extension and Spring Boot Web Starter.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Finally, configure parameters commonly used in the SOFABoot project in the application.properties file. The spring.application.name parameter is required to name the current application; the logging path specifies the output directory for logging information.\n# Application Name spring.application.name=SOFABoot Demo # logging path logging.path=./logs Advice to refer to the SOFABoot Module document before learn this demo.\nRun it We can import the project into IDE and run the \u0026amp;lsquo;main\u0026amp;rsquo; method in the generated project (generally in the XXXApplication class) to start the application, or we can execute the mvn spring-boot:run command under the project\u0026amp;rsquo;s root directory, which will print the startup logging in the console:\n2018-04-05 21:36:26.572 INFO ---- Initializing ProtocolHandler [\u0026amp;quot;http-nio-8080\u0026amp;quot;] 2018-04-05 21:36:26.587 INFO ---- Starting ProtocolHandler [http-nio-8080] 2018-04-05 21:36:26.608 INFO ---- Using a shared selector for servlet write/read 2018-04-05 21:36:26.659 INFO ---- Tomcat started on port(s): 8080 (http) We can browse http://localhost:8080/sofaboot/versions to view the version summary generated by Maven plugin in SOFABoot. The result is …","date":-62135596800,"description":"","dir":"projects/sofa-boot/quick-start/","fuzzywordcount":1400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7f582b905fde4a56791c03d4dd6b5a57","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/quick-start/","summary":"In this document, we will create a Spring Boot project and introduce the basic dependencies of SOFABoot as well as its Health Check expansion capability, to demonstrate how to get started quickly with SOFABoot.\nEnvironment Preparation To use SOFABoot, we need to prepare the basic environment first. SOFABoot depends on the following environment: - JDK7 or JDK8 - Needs to be compiled with Apache Maven 3.2.5 or above\nCreate Project SOFABoot is directly built on Spring Boot, so it can be generated by Spring Boot Generators.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/quick-start/","wordcount":1381},{"author":null,"categories":null,"content":" SOFATracer integration component list reference:Introduction To SOFATracer, Please pay attention to the SOFATracer version and JDK version of different components when using.\nPrepare Environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: - JDK7 or JDK8 - Apache Maven 3.2.5+ required for compilation\nSamples List The following Samples projects are all SOFABoot projects (also supported in the SpringBoot project). For information on how to create SOFABoot projects, please refer to SOFABoot quick start.\n Component Integration Spring MVC Integration HttpClient Integration DataSource Integration RestTemplate Integration OkHttp Integration SOFARPC Integration Dubbo Integration Spring Cloud OpenFeign Integration Sampling Report Data To Zipkin ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/componentaccess/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"42fbb0f6b6d459b7b04d45cad143d4ff","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/componentaccess/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/componentaccess/","summary":"SOFATracer integration component list reference:Introduction To SOFATracer, Please pay attention to the SOFATracer version and JDK version of different components when using.\nPrepare Environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: - JDK7 or JDK8 - Apache Maven 3.2.5+ required for compilation\nSamples List The following Samples projects are all SOFABoot projects (also supported in the SpringBoot project). For information on how to create SOFABoot projects, please refer to SOFABoot quick start.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/componentaccess/","wordcount":108},{"author":null,"categories":null,"content":" This project demonstrates how to use SOFALookout in SOFABoot and connect to the Actuator of Spring Boot. If you want to connect to Prometheus or other Registry, see the Registry section.\nCreate a SpringBoot (or SofaBoot) project Create a new Spring Boot application (In case of SOFABoot project, import to SOFABoot as described in SOFABoot Documentation - Dependency Management.\nIntroduce Lookout\u0026amp;rsquo;s Starter dependency Introduce the following dependency in pom.xml:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; In case of Spring Boot project, it is required to specify a version.\nCreate a Metrics indicator After completing the introduction of dependencies, you can add the following methods to the startup class in Spring Boot:\n@Autowired private Registry registry; @PostConstruct public void init() { Counter counter = registry.counter(registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;).withTag(\u0026amp;quot;instant\u0026amp;quot;, NetworkUtil.getLocalAddress().getHostName())); counter.inc(); } The above code directly injects a Registry field through @Autowired. Through the Registry field, you can create the corresponding Counter, and then modify the Counter data to generate the Metrics of the SOFALookout.\nAdd configuration item In SOFABoot project, you need to add a configuration item for the application name: spring.application.name=xxx.\nConnect to Spring Boot Actuator After adding a new indicator, you can choose to connect to the Spring Boot Actuator. Then the following dependency is required:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; After adding the above dependency, you can launch the application locally, visit http://localhost:8080/metrics, and you can see the metrics added earlier, as follows:\n\u0026amp;quot;http_requests_total.instant-MacBook-Pro-4.local\u0026amp;quot;: 1, The above codes are at lookout-client-samples-boot, you can Download them as a reference.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-boot/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"27e057f8a8a4ac97f42ea66ca6a17fdd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","summary":"This project demonstrates how to use SOFALookout in SOFABoot and connect to the Actuator of Spring Boot. If you want to connect to Prometheus or other Registry, see the Registry section.\nCreate a SpringBoot (or SofaBoot) project Create a new Spring Boot application (In case of SOFABoot project, import to SOFABoot as described in SOFABoot Documentation - Dependency Management.\nIntroduce Lookout\u0026rsquo;s Starter dependency Introduce the following dependency in pom.xml:","tags":null,"title":"Quick start guide for SOFABoot project","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","wordcount":244},{"author":null,"categories":null,"content":" Quick start for client Common Java Project Add the Maven dependency of the client to the application:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Lookout-client relies on the lookout-reg-server module by default (supports reporting metrics data to the lookout server). If you want to use a different type of registry (such as lookout-reg-prometheus), then add the corresponding dependency.\nBefore starting to use the SOFALookout Client, you must firstly build a global client instance (com.alipay.lookout.client.DefaultLookoutClient).\nLookoutConfig lookoutConfig = new LookoutConfig(); DefaultLookoutClient client = new DefaultLookoutClient(\u0026amp;quot;appName\u0026amp;quot;); // Choose to build the Registry you need to use (if you need multiple registry types, it is recommended to use the same lookoutConfig instance for centralized management). LookoutRegistry lookoutRegistry = new LookoutRegistry(lookoutConfig); // Client can add a registry instance (at least one) after the client is created. client.addRegistry(lookoutRegistry); // (Optional) Uniformly register the metrics of extended modules for the registry instances that have been added or will be added to the client. client.registerExtendedMetrics(); Then get the Registry instance through the client and use it:\n// The registry is a \u0026amp;quot;combination\u0026amp;quot; registry Registry registry = client.getRegistry(); //demo Id id = registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;); Counter counter = registry.counter(id); counter.inc(); For the use of the client, see Project sample.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-java/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5dc476aa21ece4789859f1af598d4445","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","summary":"Quick start for client Common Java Project Add the Maven dependency of the client to the application:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa.lookout\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;lookout-client\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${lookout.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Lookout-client relies on the lookout-reg-server module by default (supports reporting metrics data to the lookout server). If you want to use a different type of registry (such as lookout-reg-prometheus), then add the corresponding dependency.\nBefore starting to use the SOFALookout Client, you must firstly build a global client instance (com.","tags":null,"title":"Quick start guide for common Java project","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","wordcount":197},{"author":null,"categories":null,"content":" For REST，we provide a Filter to support cors now.\nSOFARPC API Usage For users who use SOFARPC API directly，they can add parameters in ServerConfig.\nMap\u0026amp;lt;String,String\u0026amp;gt; parameters=new HashMap\u0026amp;lt;String, String\u0026amp;gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026amp;quot;abc.com,cdf.com\u0026amp;quot;); serverConfig.setParameters(parameters); XML Usage You can add this configuration to application.properties\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-cors/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"549f73920842ebb121abf87566761c47","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-cors/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-cors/","summary":" For REST，we provide a Filter to support cors now.\nSOFARPC API Usage For users who use SOFARPC API directly，they can add parameters in ServerConfig.\nMap\u0026lt;String,String\u0026gt; parameters=new HashMap\u0026lt;String, String\u0026gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026quot;abc.com,cdf.com\u0026quot;); serverConfig.setParameters(parameters); XML Usage You can add this configuration to application.properties\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com ","tags":null,"title":"REST Cors","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-cors/","wordcount":40},{"author":null,"categories":null,"content":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。如果希望有一个通用的 异常处理类，用来处理REST的某中异常类型的信息。可以实现一个REST 的处理类。如下示例是一个拦截SofaRpcException 的通用处理器。\n@PreMatching public class CustomExceptionMapper implements ExceptionMapper\u0026amp;lt;SofaRpcException\u0026amp;gt; { @Override public Response toResponse(SofaRpcException exception) { return Response.status(500).entity(exception.getMessage()).build(); } } 并将该处理器注册到JAXRSProviderManager中，时机可以在Main方法中。具体说明可以参考RESTful-Filter。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-exception/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0ff4ef4139b228537d2ce4d52a213651","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-exception/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-exception/","summary":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。如果希望有一个通用的 异常处理类，用来处理REST的某中异常类型的","tags":null,"title":"REST Exception","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-exception/","wordcount":204},{"author":null,"categories":null,"content":"For REST, we designed a JAXRSProviderManager manager class. It takes effect on the server when the service starts.\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider For the user-defined Filter class, you can call it after the initialization is complete.\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance To register filter, since the custom Filter follows REST specification, you need to implement the following interface:\njavax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.container.ContainerRequestFilter After the REST server is started, if using bare SOFARPC, you need to register filter first before starting the service. In SOFABoot environment, it is similar. The specific encoding method is as follows:\ncom.alipay.sofa.rpc.server.rest.TraceRequestFilter com.alipay.sofa.rpc.server.rest.TraceResponseFilter ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-filter/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"53eb86b2504bf3beda2aca24437d6dab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-filter/","summary":"For REST, we designed a JAXRSProviderManager manager class. It takes effect on the server when the service starts.\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider For the user-defined Filter class, you can call it after the initialization is complete.\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance To register filter, since the custom Filter follows REST specification, you need to implement the following interface:\njavax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.container.ContainerRequestFilter After the REST server is started, if using bare SOFARPC, you need to register filter first before starting the service.","tags":null,"title":"REST filter","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-filter/","wordcount":89},{"author":null,"categories":null,"content":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider 对于用户自定义的 Filter 类，可以在初始化完成后，调用\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance 进行注册，其中自定义的 Filter 遵循 REST 的规范，需要实现如下接口：\njavax.ws.rs.container.ContainerResponseFilter 或者 javax.ws.rs.container.ContainerRequestFilter REST server 启动之后，对于裸 SOFARPC 的使用，需要先注册，再启动服务。对于 SOFABoot 环境下的使用，也是类似的过程，具体的写法可以参考：\ncom.alipay.sofa.rpc.server.rest.TraceRequestFilter com.alipay.sofa.rpc.server.rest.TraceResponseFilter ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-filter/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"53eb86b2504bf3beda2aca24437d6dab","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-filter/","summary":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。 com.alipay.sofa.rpc.server.rest.RestServer#registerProvider 对于用户自定义的 Filter 类，可以在初始化完成后，调用 com.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance 进行注册，其中","tags":null,"title":"REST 自定义 Filter","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-filter/","wordcount":152},{"author":null,"categories":null,"content":" 对于 REST，我们内置了一个跨域 Filter 的支持。\nSOFARPC API 使用 对于使用 SOFARPC API 的用户，可以在 ServerConfig 中添加一个参数表明即可\nMap\u0026amp;lt;String,String\u0026amp;gt; parameters=new HashMap\u0026amp;lt;String, String\u0026amp;gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026amp;quot;abc.com,cdf.com\u0026amp;quot;); serverConfig.setParameters(parameters); XML 方式使用 直接通过配置\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com 即可\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-cors/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"549f73920842ebb121abf87566761c47","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-cors/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-cors/","summary":"对于 REST，我们内置了一个跨域 Filter 的支持。 SOFARPC API 使用 对于使用 SOFARPC API 的用户，可以在 ServerConfig 中添加一个参数表明即可 Map\u0026lt;String,String\u0026gt; parameters=new HashMap\u0026lt;String, String\u0026gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026quot;abc.com,cdf.com\u0026quot;); serverConfig.setParameters(parameters); XML 方式使用 直接通过配置 com.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com 即可","tags":null,"title":"REST 跨域","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-cors/","wordcount":70},{"author":null,"categories":null,"content":"SOFARPC supports RESTful protocol, making it convenient for users to publish an interface in the manner of RESTful. * Basic usage * Custom Filter * Integrate Swagger\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f238d7f58de0c4a0e12d566ea9e09f52","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful/","summary":"SOFARPC supports RESTful protocol, making it convenient for users to publish an interface in the manner of RESTful. * Basic usage * Custom Filter * Integrate Swagger","tags":null,"title":"RESTful","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful/","wordcount":27},{"author":null,"categories":null,"content":"SOFARPC 提供了 RESTful 协议的支持，可以让用户非常方便地将一个接口通过 RESTful 的方式发布出去。 * 基本使用 * 自定义 Filter * 通用异常处理 * 集成 Swagger\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f238d7f58de0c4a0e12d566ea9e09f52","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful/","summary":"SOFARPC 提供了 RESTful 协议的支持，可以让用户非常方便地将一个接口通过 RESTful 的方式发布出去。 * 基本使用 * 自定义 Filter * 通用异常处理 * 集成 Swagger","tags":null,"title":"RESTful 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful/","wordcount":58},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议即使用不同的 Binding 即可，如果需要使用 RESTful 协议，只要将 Binding 设置为 REST 即可。\n发布服务 在定义 RESTful 的服务接口的时候，需要采用 JAXRS 标准的注解在接口上加上元信息，比如下面的接口：\n@Path(\u0026amp;quot;sample\u0026amp;quot;) public interface SampleService { @GET @Path(\u0026amp;quot;hello\u0026amp;quot;) String hello(); } JAXRS 的标准的注解的使用方式可以参考 RESTEasy 的文档。\n 在定义好了接口之后，将接口的实现发布成一个服务，比如，通过 Annotation 的方式：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}) public class RestfulSampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } 如果要通过其他的方式发布服务，请参考 Bolt 协议基本使用。\n通过浏览器访问服务 在发布服务之后，用户可以通过浏览器来直接访问服务，对于上面的服务，访问的地址如下：\nhttp://localhost:8341/sample/hello SOFARPC 的 RESTful 服务的默认端口为 8341。\n引用服务 除了通过浏览器访问 SOFARPC 发布的 RESTful 服务之外，用户也可以通过 SOFARPC 标准的服务引用的方式来引用服务，比如通过 Annotation 的方式：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)) private SampleService sampleService; 如果要使用其他的方式引用服务，请参考 Bolt 协议基本使用。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-basic/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d41f976864ba8f8221f5b5d26f354d1c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-basic/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-basic/","summary":"在 SOFARPC 中，使用不同的通信协议即使用不同的 Binding 即可，如果需要使用 RESTful 协议，只要将 Binding 设置为 REST 即可。 发布服务 在定义 RESTful 的服务接口的时候，需要采用 JAXRS 标准的注","tags":null,"title":"RESTful 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-basic/","wordcount":358},{"author":null,"categories":null,"content":"In SOFABoot, the RPC framework provides some configuration parameters at the application level, and supports application-level parameter configuration, such as port and thread pool, which are bound by Spring Boot\u0026amp;rsquo;s @ConfigurationProperties. The binding attribute class is com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties, and the configuration prefix is as follows:\nstatic final String PREFIX = \u0026amp;quot;com.alipay.sofa.rpc\u0026amp;quot;; Then in the application.properties file, you can currently configure the following options. Also, you can write the codes based on your own coding habits as well as according to the Spring Boot specification, camel, underline and so on.\n#Standalone fault tolerance com.alipay.sofa.rpc.aft.regulation.effective # Whether to enable standalone fault tolerance com.alipay.sofa.rpc.aft.degrade.effective # Whether to enable degradation com.alipay.sofa.rpc.aft.time.window # Time window com.alipay.sofa.rpc.aft.least.window.count # Minimum number of calls com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple # minimum exception rate com.alipay.sofa.rpc.aft.weight.degrade.rate # Degradation rate com.alipay.sofa.rpc.aft.weight.recover.rate # Recovery rate com.alipay.sofa.rpc.aft.degrade.least.weight #Minimum degrading weight com.alipay.sofa.rpc.aft.degrade.max.ip.count # Maximum number of degraded IPs # bolt com.alipay.sofa.rpc.bolt.port # bolt port com.alipay.sofa.rpc.bolt.thread.pool.core.size # Number of bolt core threads com.alipay.sofa.rpc.bolt.thread.pool.max.size # Maximum number of bolt threads com.alipay.sofa.rpc.bolt.thread.pool.queue.size # bolt thread pool queue com.alipay.sofa.rpc.bolt.accepts.size # Number of connections that server allows client to establish # rest com.alipay.sofa.rpc.rest.hostname # rest hostname com.alipay.sofa.rpc.rest.port # rest port com.alipay.sofa.rpc.rest.io.thread.size # Number of rest io threads com.alipay.sofa.rpc.rest.context.path # rest context path com.alipay.sofa.rpc.rest.thread.pool.core.size # Number of rest core threads com.alipay.sofa.rpc.rest.thread.pool.max.size # Maximum number of rest threads com.alipay.sofa.rpc.rest.max.request.size # Maximum rest request size com.alipay.sofa.rpc.rest.telnet # Whether to allow rest telnet com.alipay.sofa.rpc.rest.daemon # Whether to hold the port. If true, exit with the main thread exit # dubbo com.alipay.sofa.rpc.dubbo.port # dubbo port com.alipay.sofa.rpc.dubbo.io.thread.size # dubbo io thread size com.alipay.sofa.rpc.dubbo.thread.pool.max.size # Maximum number of dubbo business threads com.alipay.sofa.rpc.dubbo.accepts.size # Number of connections that server allows client to establish com.alipay.sofa.rpc.dubbo.thread.pool.core.size #Number of dubbo core Threads com.alipay.sofa.rpc.dubbo.thread.pool.queue.size #Maximum number of dubbo threads # registry com.alipay.sofa.rpc.registry.address # Registry center address com.alipay.sofa.rpc.virtual.host # virtual host com.alipay.sofa.rpc.bound.host # bind host …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/application-rpc-config/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"bd19b2ced39a8deb802c13e525093fac","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","summary":"In SOFABoot, the RPC framework provides some configuration parameters at the application level, and supports application-level parameter configuration, such as port and thread pool, which are bound by Spring Boot\u0026rsquo;s @ConfigurationProperties. The binding attribute class is com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties, and the configuration prefix is as follows:\nstatic final String PREFIX = \u0026quot;com.alipay.sofa.rpc\u0026quot;; Then in the application.properties file, you can currently configure the following options. Also, you can write the codes based on your own coding habits as well as according to the Spring Boot specification, camel, underline and so on.","tags":null,"title":"RPC application parameter configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","wordcount":381},{"author":null,"categories":null,"content":" ProviderConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (unique identifier) filterRef Filter configuration example List filter Filter configuration alias separated by commas registry Registry center on the server List methods Method-level configuration Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect. subscribe Whether to subscribe true It depends on the implementation and may not take effect. proxy Proxy type javassist As well as JDK dynamic proxy ref Service interface implementation class server server List, and it can be sent to multiple servers at once delay Time for delaying service publishing Service delay weight Service static weight include Included methods exclude Methods not included dynamic Whether to dynamically register priority Service priority bootstrap Service publishing starter bolt executor Custom thread pool timeout Execution timeout period for server concurrents Concurrent execution request Maximum number of parallel executable requests per method under interface. -1 indicates turning off the concurrent filter, and 0 means that filtering is enabled but not limited cacheRef Result cache implementation class mockRef Mock implementation class mock Whether to enable Mock validation Whether to enable parameter verification (jsr303) compress Whether to start compression false cache Whether to enable result caching false parameters Extra attributes Map\u0026amp;lt;String, String\u0026amp;gt; ConsumerConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (Unique identifier) filterRef Filter configuration example List filter Filter configuration alias List registry Registry center on the server List methods Method-level configuration Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect. subscribe Whether to subscribe true It depends on the implementation and may not take effect. proxy proxy type javassist As well as JDK dynamic proxy protocol Call protocol bolt Currently supports bolt, rest, dubbo directUrl Direct address Directly connected to register generic Whether to generalize calls false connectTimeout Timeout period for connection establishment 3000(cover 5000) disconnectTimeout Timeout period for disconnection 5000(cover …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-common/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2eb5963f4785f5f828f0e15759272971","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration-common/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration-common/","summary":"ProviderConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (unique identifier) filterRef Filter configuration example List filter Filter configuration alias separated by commas registry Registry center on the server List methods Method-level configuration Map\u0026lt;String, MethodConfig\u0026gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect.","tags":null,"title":"RPC publishing and reference configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration-common/","wordcount":1118},{"author":null,"categories":null,"content":" ProviderConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 uniqueId 服务标签（唯一标识元素） filterRef 过滤器配置实例 List filter 过滤器配置别名 多个用逗号隔开 registry 服务端注册中心 List methods 方法级配置 Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization 序列化协议 hessian2 register 是否注册 true 取决于实现，可能不生效。 subscribe 是否订阅 true 取决于实现，可能不生效。 proxy 代理类型 javassist 还有JDK动态代理 ref 服务接口实现类 server 服务端 List，可以一次发到多个服务端 delay 服务延迟发布时间 服务延迟 weight 服务静态权重 include 包含的方法 exclude 不包含的方法 dynamic 是否动态注册 priority 服务优先级 bootstrap 服务发布启动器 bolt executor 自定义线程池 timeout 服务端执行超时时间 concurrents 并发执行请求 接口下每方法的最大可并行执行请求数，配置-1关闭并发过滤器，等于0表示开启过滤但是不限制 cacheRef 结果缓存实现类 mockRef Mock实现类 mock 是否开启Mock validation 是否开启参数验证(jsr303) compress 是否启动压缩 false cache 是否启用结果缓存 false parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; ConsumerConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 uniqueId 服务标签（唯一标识元素） filterRef 过滤器配置实例 List filter 过滤器配置别名 List registry 服务端注册中心 List methods 方法级配置 Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization 序列化协议 hessian2 register 是否注册 true 取决于实现，可能不生效。 subscribe 是否订阅 true 取决于实现，可能不生效。 proxy 代理类型 javassist 还有JDK动态代理 protocol 调用的协议 bolt 目前支持bolt，rest，dubbo directUrl 直连地址 直连后register generic 是否泛化调用 false connectTimeout 建立连接超时时间 3000(cover 5000) disconnectTimeout 断开连接等等超时时间 5000(cover 10000) cluster 集群模式 failover connectionHolder 连接管理器实现 all loadBalancer 负载均衡算法 random lazy 是否延迟建立长连接 false sticky 是否使用粘性连接 false 跳过负载均衡算法使用上一个地址 inJVM 是否转为JVM调用 true JVM发现服务提供者，转为走本地 check 是否检查强依赖 false 无可用服务端启动失败 heartbeat 心跳间隔 30000 客户端给服务端发心跳间隔。取决于实现，可能不生效。 reconnect 重连间隔 10000 客户端重建端口长连接的间隔。取决于实现，可能不生效。 router 路由器配置别名 List routerRef 路由器配置实例 List bootstrap 服务引用启动器 bolt addressWait 等待地址获取时间 -1 取决于实现，可能不生效。 timeout 调用超时时间 3000(cover 5000) retries 失败后重试次数 0 跟集群模式有关，failover读取此参数。 invokeType 调用类型 sync onReturn 并发执行请求数 接口下每方法的最大可并行执行请求数，\n配置-1关闭并发过滤器，等于0表示开启过滤但是不限制 cacheRef 结果缓存实现类 mockRef Mock实现类 cache 是否启用结果缓存 false mock 是否开启Mock validation 是否开启参数验证 基于JSR303 compress 是否启动压缩 false parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; rejectedExecutionPolicy 回调线程池满拒绝策略 DISCARD DISCARD：默认丢弃，CALLER_RUNS：IO 线程继续执行任务，CALLER_HANDLE_EXCEPTION：IO 线程执行异常回调任务 @since 5.8.1 MethodConfig 属性 名称 默认值 备注 name 方法名 timeout 调用超时时间 null retries 失败后重试次数 null invokeType 调用类型 null validation 是否开启参数验证 null 基于JSR303 onReturn 返回时调用的SofaResponseCallback null 用于实现Callback等 concurrent 并发执行请求数 null 接口下每方法的最大可并行执行请求数，配置-1关闭并发过滤器，等于0表示开启过滤但是不限制。 validation 是否开启参数验证 null compress 是否启动压缩 null parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; ServerConfig id Id 默认值 备注 protocol 协议 bolt 目前支持bolt，rest，dubbo host 主机 0.0.0.0 port 端口 12200 默认端口 bolt:12200, rest:8341, h2c:12300, dubbo:20880 contextPath …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-common/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2eb5963f4785f5f828f0e15759272971","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration-common/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration-common/","summary":"ProviderConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置","tags":null,"title":"RPC 发布订阅配置","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration-common/","wordcount":1868},{"author":null,"categories":null,"content":"在 SOFABoot 的使用场景下，RPC 框架在应用层面，提供一些配置参数，支持的应用级别的参数配置，如端口，线程池等信息，都是通过 Spring Boot的@ConfigurationProperties 进行的绑定。绑定属性类是com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties，配置前缀是\nstatic final String PREFIX = \u0026amp;quot;com.alipay.sofa.rpc\u0026amp;quot;; 那么在 application.properties 文件中，目前可以配置以下几个选项。其中使用者也可以根据自己的编码习惯，按照 Spring Boot的规范，按照驼峰，中划线等进行书写。\n单机故障剔除\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.aft.regulation.effective 是否开启单机故障剔除功能 Boolean false com.alipay.sofa.rpc.aft.degrade.effective 是否开启降级 Boolean false com.alipay.sofa.rpc.aft.time.window 时间窗口 Long 10 com.alipay.sofa.rpc.aft.least.window.count 最小调用次数 Long 10 com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple 最小异常率 Double 6.0 com.alipay.sofa.rpc.aft.weight.degrade.rate 降级速率 Double 0.05 com.alipay.sofa.rpc.aft.weight.recover.rate 恢复速率 Double 2.0 com.alipay.sofa.rpc.aft.degrade.least.weight 降级最小权重 Integer 1 com.alipay.sofa.rpc.aft.degrade.max.ip.count 最大降级 ip数量 Integer 2 Bolt\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.bolt.port bolt 端口 Integer 优先生效的是environment中是否设置rpc_tr_port，然后才是此处设置的值。默认12200 com.alipay.sofa.rpc.bolt.thread.pool.core.size bolt 核心线程数 Integer 20 com.alipay.sofa.rpc.bolt.thread.pool.max.size bolt 最大线程数 Integer 200 com.alipay.sofa.rpc.bolt.thread.pool.queue.size bolt 线程池队列 Integer 0 com.alipay.sofa.rpc.bolt.accepts.size bolt 服务端允许客户端建立的连接数 Integer 必须大于0，默认100000 com.alipay.sofa.rpc.bolt.process.in.io.thread bolt 服务端业务处理是否直接在worker中处理 Boolean false com.alipay.sofa.rpc.enable.swagger 是否开启针对bolt协议的swagger文档 Boolean false Rest\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.rest.hostname rest hostname String “” com.alipay.sofa.rpc.rest.port rest port Integer 8341 com.alipay.sofa.rpc.rest.io.thread.size rest io 线程数 Integer 机器cpu核数* 2 com.alipay.sofa.rpc.rest.context.path rest context path String “” com.alipay.sofa.rpc.rest.thread.pool.core.size rest 核心线程数 Integer 目前不可配置，默认20 com.alipay.sofa.rpc.rest.thread.pool.max.size rest 最大线程数 Integer 200 com.alipay.sofa.rpc.rest.max.request.size rest 最大请求大小 Integer 10485760 com.alipay.sofa.rpc.rest.telnet 是否允许 rest telnet Boolean true com.alipay.sofa.rpc.rest.daemon 是否hold住端口，true的话随主线程退出而退出 String true com.alipay.sofa.rpc.rest.allowed.origins 跨域设置 String “” com.alipay.sofa.rpc.rest.swagger 是否开启针对rest协议的swagger文档 boolean false Dubbo\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.dubbo.port dubbo port Integer 20880 com.alipay.sofa.rpc.dubbo.io.thread.size dubbo io 线程大小 Integer 0 com.alipay.sofa.rpc.dubbo.thread.pool.max.size dubbo 业务线程最大数 Integer 200 com.alipay.sofa.rpc.dubbo.accepts.size dubbo 服务端允许客户端建立的连接数 Integer 必须大于0，默认100000 com.alipay.sofa.rpc.dubbo.thread.pool.core.size dubbo 核心线程数 Integer 目前不可配置，默认20 com.alipay.sofa.rpc.dubbo.thread.pool.queue.size dubbo 线程池队列大小 Integer 目前不可配置，默认0 Http\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.http.port http port Integer 12400 com.alipay.sofa.rpc.http.thread.pool.core.size http 核心线程数 Integer 20 com.alipay.sofa.rpc.http.thread.pool.max.size http …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/application-rpc-config/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bd19b2ced39a8deb802c13e525093fac","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/application-rpc-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/application-rpc-config/","summary":"在 SOFABoot 的使用场景下，RPC 框架在应用层面，提供一些配置参数，支持的应用级别的参数配置，如端口，线程池等信息，都是通过 Spring Boot的@Config","tags":null,"title":"RPC 应用参数配置","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/application-rpc-config/","wordcount":1496},{"author":null,"categories":null,"content":" Raft 新特性 Strong Leader 更强的领导形式 例如日志条目只会从领导者发送到其他服务器, 这很大程度上简化了对日志复制的管理 Leader Election 使用随机定时器来选举领导者 用最简单的方式减少了选举冲突的可能性 Membership Change 新的联合一致性 (joint consensus) 方法 复制状态机 1. 复制状态机通过日志实现 每台机器一份日志 每个日志条目包含一条命令 状态机按顺序执行命令 2.应用于实际系统的一致性算法一般有以下特性 确保安全性 高可用性 不依赖时序保证一致性 一条命令能够尽可能快的在大多数节点对一轮RPC调用响应时完成 Paxos 算法的不足 算法复杂度高, 较难理解 工程复杂度高, 难以在实际环境中实现 Raft 设计原则 概念分解 Leader election Log replication Membership changes 通过减少状态数量将状态空间简化 日志不允许出现空洞, 并且 raft 限制了日志不一致的可能性 使用随机化时钟简化了领导选举的算法 Raft 一致性算法 State (状态) 在所有服务器上持久存储的(响应RPC之前稳定存储的)\n currentTerm 服务器最后知道的任期号(从0开始递增) votedFor 在当前任期内收到选票的候选人Id(如果没有就为null) log[] 日志条目, 每个条目包含状态机要执行的命令以及从Leader收到日志时的任期号 在所有服务器上不稳定存在的\n commitIndex 已知被提交的最大日志条目索引 lastApplied 已被状态机执行的最大日志条目索引 在Leader服务器上不稳定存在的\n nextIndex[] 对于每一个follower, 记录需要发给他的下一条日志条目的索引 matchIndex[] 对于每一个follower, 记录已经复制完成的最大日志条目索引 AppendEntries RPC (日志复制) 由leader通过RPC向follower复制日志, 也会用作heartbeat\n入参\n term Leader任期号 leaderId Leader id, 为了能帮助客户端重定向到Leader服务器 prevLogIndex 前一个日志的索引 prevLogTerm 前一个日志所属的任期 entries[] 将要存储的日志条目列表(为空时代表heartbeat, 有时候为了效率会发送超过一条) leaderCommit Leader已提交的日志条目索引 返回值\n term 当前的任期号, 用于leader更新自己的任期号 success 如果其他follower包含能够匹配上prevLogIndex和prevLogTerm的日志, 那么为真 接收日志的follower需要实现的\n 如果term \u0026amp;lt; currentTerm, 不接受日志并返回false 如果索引prevLogIndex处的日志的任期号与prevLogTerm不匹配, 不接受日志并返回false 如果一条已存在的日志与新的冲突(index相同但是term不同), 则删除已经存在的日志条目和他之后所有的日志条目 添加任何在已有日志中不存在的条目 如果leaderCommit \u0026amp;gt; commitIndex, 则设置commitIndex = min(leaderCommit, index of last new entry) RequestVote RPC (投票请求) 入参\n term 候选人的任期号 candidateId 发起投票请求的候选人id lastLogIndex 候选人最新的日志条目索引 lastLogTerm 候选人最新日志条目对应的任期号 返回值\n term 目前的任期号, 用于候选人更新自己 voteGranted 如果候选人收到选票, 那么为true 接收日志的follower需要实现的\n 如果term \u0026amp;lt; currentTerm, 那么拒绝投票并返回false 如果votedFor为空或者与candidateId相同, 并且候选人的日志和自己一样新或者更新, 那么就给候选人投票并返回true 服务器要遵守的规则 所有服务器: 如果commitIndex \u0026amp;gt; lastApplied, 那么将lastApplied自增并把对应日志log[lastApplied]应用到状态机 如果RPC请求或响应包含一个term T大于currentTerm, 那么将currentTerm赋值为T并立即切换状态为follower Follower: 无条件响应来自candidate和leader的RPC 如果在选举超时之前没收到任何来自leader的AppendEntries RPC或RequestVote RPC, 那么自己转换状态为candidate Candidate: 转变为candidate之后开始发起选举 currentTerm自增 \u0026amp;ndash;\u0026amp;gt; 重置选举计时器 \u0026amp;ndash;\u0026amp;gt; 给自己投票 \u0026amp;ndash;\u0026amp;gt; 向其他服务器发起RequestVote RPC 如果收到了来自大多数服务器的投票, 转换状态成为leader 如果收到了来自新leader的AppendEntries RPC(Heartbeat), 转换状态为follower 如果选举超时, 开始新一轮的选举 Leader: 一旦成为leader, 向其他所有服务器发送空的AppendEntries RPC(Heartbeat), 并在空闲时间重复发送以防选举超时 如果收到来自客户端的请求, 向本地日志追加条目并向所有服务器发送AppendEntries RPC, 在收到大多数响应后将该条目应用到状态机并回复响应给客户端 如果leader上一次收到的日志索引大于一个follower的nextIndex, 那么通过AppendEntries RPC将nextIndex之后的所有日志发送出去; 如果发送成功, 将follower的nextIndex和matchIndex更新, 如果由于日志不一致导致失败, 那么将nextIndex递减并重新发送 如果存在一个N \u0026amp;gt; commitIndex和半数以上的matchIndex[i] \u0026amp;gt;= N并且log[N].term == currentTerm, 将commitIndex赋值为N 一致性算法总结 Election Safety 选举安全原则: 一个任期内最多允许有一个leader Leader Append-Only 只增加日志原则: Leader只会增加日志条目, 永远不会覆盖或删除自己的日志 Log Matching 日志匹配原则: 如果两个日志在相同的的索引位置上并且任期号相同, 那么就可以认为这个日志从头到这个索引位置之间的条目完 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/raft-introduction/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b811e803d23b40da67657798801f8b51","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/raft-introduction/","publishdate":"0001-01-01T00:00:00Z","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-jraft/raft-introduction/","summary":"Raft 新特性 Strong Leader 更强的领导形式 例如日志条目只会从领导者发送到其他服务器, 这很大程度上简化了对日志复制的管理 Leader Election 使用随机定时器来选举领导者 用最简单","tags":null,"title":"Raft 算法解读","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/raft-introduction/","wordcount":5182},{"author":null,"categories":null,"content":"TBD\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-register-agent/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"da6c96fadd94eedcf961d50ce7b00600","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","summary":"TBD","tags":null,"title":"Register Agent","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","wordcount":1},{"author":null,"categories":null,"content":" Register agent TBD\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-register-agent/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"da6c96fadd94eedcf961d50ce7b00600","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","summary":"Register agent TBD","tags":null,"title":"Register agent","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","wordcount":3},{"author":null,"categories":null,"content":" Related articles ISSUES User manual Chinese introductory article: Ant communication framework practices ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/related-links/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"6844d2a639b69fa3128132b8631f33e3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/related-links/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/related-links/","summary":" Related articles ISSUES User manual Chinese introductory article: Ant communication framework practices ","tags":null,"title":"Related articles","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/related-links/","wordcount":12},{"author":null,"categories":null,"content":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.\n","date":-62135596800,"description":"","dir":"projects/mosn/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"62efb8e40401ab4612bcccaa6e942c97","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/mosn/release-notes/","summary":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/mosn/release-notes/","wordcount":5},{"author":null,"categories":null,"content":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.\n","date":-62135596800,"description":"","dir":"projects/occlum/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"6b9dec1dd8c196e43129ab36a046a84f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/occlum/release-notes/","summary":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/occlum/release-notes/","wordcount":5},{"author":null,"categories":null,"content":" Release history For more information, refer to: https://github.com/sofastack/sofa-ark/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-release/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"994c3569ea416ee5b0dea253f08af6be","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","summary":"Release history For more information, refer to: https://github.com/sofastack/sofa-ark/releases","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","wordcount":8},{"author":null,"categories":null,"content":"## Release history For more information, refer to: https://github.com/sofastack/sofa-jarslink/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-release/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4554e362f42cbc42b9408d9507cdf689","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","summary":"## Release history For more information, refer to: https://github.com/sofastack/sofa-jarslink/releases","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","wordcount":9},{"author":null,"categories":null,"content":"For more information, see https://github.com/sofastack/sofa-dashboard/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/release-node/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3c8e6985123810c9692f47cc56b50081","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/release-node/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/release-node/","summary":"For more information, see https://github.com/sofastack/sofa-dashboard/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/release-node/","wordcount":5},{"author":null,"categories":null,"content":" 1.2.5 April 1, 2019\n Bugs fixed Fixed the conflict between jmh and the unit test code. Fixed the installation failure bug that would occur when the snapshot is too large. This bug may affect the addition of new nodes. Features Optimized part of the LogManagerImpl code to reduce CPU usage. Corrected some spelling errors. Breaking changes None We strongly recommend that you upgrade to this version.\n1.2.4 March 20, 2019\n Bugs fixed Fixed stale read of lease read in a circumstance. Modified part of timestamps to monotonic time. Fixed the problem of the replicator being blocked in one circumstance. Resolved directory creation failures for some unit tests on Windows. Resolved process crashes caused by improper rocksdb options settings on Windows. Features Made the RocksDB options available for users to set. Optimized the pre-vote process, and used the lease mechanism to avoid the current term\u0026amp;rsquo;s interruption on a disconnected node (caused by network partitioning or no writes in the cluster for a long time) to improve the system availability. Updated SOFABolt to 1.5.3. Modified ReadWriteLock of the BallotBox to StampedLock, and provided the OptimisticRead implementation. Fixed a few spelling errors. Breaking changes None Acknowledgements (in no particular order) @pifuant @huangyunbin @shiftyman @slievrly 1.2.3 March 5, 2019 Released the first open source version.\n1.2.2 February 21, 2019\n Bugs fixed Made PeerId and Endpoint immutable, to avoid concurrency problems on APIs such as getLeaderId. Upgraded sofa-common to 1.0.12. The earlier version 1.0.9 was not released to the public GitHub repository. Features The JRaft-RheaKV implemented auto range split. When placementDriver(pd) is enabled, the pd can calculate and issue the range split command based on state information reported by each node. When pd is disabled, RheaKVCliService is provided to allow users to manually trigger range split by using the CLI service. Provided LogExceptionHandler generic support. Added MetricThreadPoolExecutor (an updated version of LogThreadPoolExecutor) to print the uncaught exception log and record the time for task.run() and replaced all ThreadPoolExecutors in JRaft with MetricThreadPoolExecutor to record time-consumption metric statistics. This metric can be used as an important reference for adjusting the thread pool configuration in actual application. Breaking changes Removed the reset method of Endpoint/PeerId. V1.2.1 January 28, 2019\n Bugs fixed Fixed a bug that RaftGroupService may mistakenly disable the shared rpcServer. Fixed the bug of the apply-order change caused by batch write of the RheaKV state machine. Fixed the time usage API error. Features Merged the code of duplicate functions of Jraft and RheaKV. Reduced memory usage of the log replication request handling process on followers. Optimized the synchronized conf read/write of the RouteTable to the read/write lock. Implemented lock safe with fencing and the automatic lease …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/release-log/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"9e24fb74a3cda6a600252b01f8a85db9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/release-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/release-log/","summary":"1.2.5 April 1, 2019\n Bugs fixed Fixed the conflict between jmh and the unit test code. Fixed the installation failure bug that would occur when the snapshot is too large. This bug may affect the addition of new nodes. Features Optimized part of the LogManagerImpl code to reduce CPU usage. Corrected some spelling errors. Breaking changes None We strongly recommend that you upgrade to this version.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/release-log/","wordcount":855},{"author":null,"categories":null,"content":"For more information, see https://github.com/sofastack/sofa-registry/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d92dddf77bbbd6078f3f96ba2224a53d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/release-notes/","summary":"For more information, see https://github.com/sofastack/sofa-registry/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/release-notes/","wordcount":5},{"author":null,"categories":null,"content":"To learn more, see https://github.com/sofastack/sofa-rpc/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ab7d46caa6906863103b77b742ec7e84","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/release-notes/","summary":"To learn more, see https://github.com/sofastack/sofa-rpc/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/release-notes/","wordcount":5},{"author":null,"categories":null,"content":" This example demonstrates how to remotely report link data to Zipkin by configuring SOFATracer in an application that integrates SOFATracer.\nThe following examples demonstrate how to use them in SOFABoot/SpringBoot projects and non-SOFABoot/SpringBoot projects, respectively.\nPrepare environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: + JDK7 or JDK8 + Apache Maven 3.2.5+ required for compilation\nIntroduce SOFABoot After creating a Spring Boot project, you need to introduce the SOFABoot dependency. First, you need to unzip the zip package of the Spring Boot project generated above and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more about SOFABoot versions, see Release notes.\nAdd SOFATracer starter \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Application configuration Finally, add the properties to be used by SOFATracer under the project\u0026amp;rsquo;s application.properties file, including spring.application.name to indicate the name of the current application; logging.path to specify the output directory of the log.\n# Application Name spring.application.name=SOFATracerReportZipkin # logging path logging.path=./logs # open zipkin report com.alipay.sofa.tracer.zipkin.enabled=true # specify zipkin server address com.alipay.sofa.tracer.zipkin.baseUrl=http://localhost:9411 Configure Zipkin Dependencies Considering that Zipkin\u0026amp;rsquo;s data reporting capability is not the ability of SOFATracer to be enabled by default,it‘s desirable to add the following Zipkin data reporting dependencies when using SOFATracer for data reporting:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.zipkin2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.11.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.reporter2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin-reporter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.7.13\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt;\t Start the Zipkin server Start the Zipkin server to receive the link data reported by SOFATracer and display it. Zipkin Server can be configured with reference to this document.\nRunning You can import the project into IDE and run the main method in the project to start the application. In the console, you can see the log about startup as follows:\n2018-05-12 13:12:05.868 INFO 76572 --- …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/report-to-zipkin/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d28d192386829452262116de9c32b570","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","summary":"This example demonstrates how to remotely report link data to Zipkin by configuring SOFATracer in an application that integrates SOFATracer.\nThe following examples demonstrate how to use them in SOFABoot/SpringBoot projects and non-SOFABoot/SpringBoot projects, respectively.\nPrepare environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: + JDK7 or JDK8 + Apache Maven 3.2.5+ required for compilation\nIntroduce SOFABoot After creating a Spring Boot project, you need to introduce the SOFABoot dependency.","tags":null,"title":"Report data to Zipkin","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","wordcount":465},{"author":null,"categories":null,"content":" RestTemplate Integration In this document will demonstrate how to use SOFATracer to track of RestTemplate, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- SOFABoot version unified management --\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs Add a Controller that provides RESTFul services In the project, provide a simple Controller, for example:\n@RestController public class SampleController { private final AtomicLong counter = new AtomicLong(0); @RequestMapping(\u0026amp;quot;/rest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; rest() { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); return map; } @RequestMapping(\u0026amp;quot;/asyncrest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; asyncrest() throws InterruptedException { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); Thread.sleep(5000); return map; } } Construct the RestTemplate in API model to initiate a call to the RESTful service above Construct a RestTemplate synchronous call instance RestTemplate restTemplate = SofaTracerRestTemplateBuilder.buildRestTemplate(); ResponseEntity\u0026amp;lt;String\u0026amp;gt; responseEntity = restTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;, String.class); Construct a RestTemplate asynchronous call instance AsyncRestTemplate asyncRestTemplate = SofaTracerRestTemplateBuilder .buildAsyncRestTemplate(); ListenableFuture\u0026amp;lt;ResponseEntity\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; forEntity = asyncRestTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/asyncrest\u0026amp;quot;, String.class); Get the RestTemplate in an automatic injection @Autowired RestTemplate restTemplate; Run the project Start the SOFABoot app and see the log in the console as follows:\n2018-10-24 10:45:28.683 INFO 5081 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-10-24 10:45:28.733 INFO 5081 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-10-24 10:45:28.736 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Started RestTemplateDemoApplication in 2.163 seconds (JVM running for 3.603) Successful call：\n2018-10-24 10:45:28.989 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-resttemplate/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"8b66d6ad488bd59ecbf113b37825d58e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","summary":"RestTemplate Integration In this document will demonstrate how to use SOFATracer to track of RestTemplate, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;!-- SOFABoot version unified management --\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.properties file, including spring.","tags":null,"title":"RestTemplate Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","wordcount":434},{"author":null,"categories":null,"content":" RestTemplate Log Format SOFATracer integrates RestTemplate and outputs the requested link log data format. The default is JSON data format.\nRestTemplate digest log（resttemplate-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.app remote app name baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-10-24 10:45:28.977\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8b3154034912878910015081\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:188,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RestTemplate stat log（resttemplate-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success ; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-10-24 10:46:28.769\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5009,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-resttemplate/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c52c919080b467801700a8a1f156c513","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","summary":"RestTemplate Log Format SOFATracer integrates RestTemplate and outputs the requested link log data format. The default is JSON data format.\nRestTemplate digest log（resttemplate-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.","tags":null,"title":"RestTemplate log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","wordcount":172},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 RestTemplate 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括 spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=TestTemplateDemo # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleController { private final AtomicLong counter = new AtomicLong(0); @RequestMapping(\u0026amp;quot;/rest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; rest() { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); return map; } @RequestMapping(\u0026amp;quot;/asyncrest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; asyncrest() throws InterruptedException { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); Thread.sleep(5000); return map; } } 以 API 方式构造 RestTemplate 发起一次对上文的 RESTful 服务的调用 构造 RestTemplate 同步调用实例 RestTemplate restTemplate = SofaTracerRestTemplateBuilder.buildRestTemplate(); ResponseEntity\u0026amp;lt;String\u0026amp;gt; responseEntity = restTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;, String.class); 构造 RestTemplate 异步调用实例 AsyncRestTemplate asyncRestTemplate = SofaTracerRestTemplateBuilder .buildAsyncRestTemplate(); ListenableFuture\u0026amp;lt;ResponseEntity\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; forEntity = asyncRestTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/asyncrest\u0026amp;quot;, String.class); 以自动注入的方式获取 RestTemplate @Autowired RestTemplate restTemplate; 运行 启动 SOFABoot 应用，将会在控制台中看到启动打印的日志：\n2018-10-24 10:45:28.683 INFO 5081 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-10-24 10:45:28.733 INFO 5081 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-10-24 10:45:28.736 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Started RestTemplateDemoApplication in 2.163 seconds (JVM running for 3.603) 调用成功：\n2018-10-24 10:45:28.989 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Async Response is {\u0026amp;quot;count\u0026amp;quot;:2} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : test finish ....... 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要进行配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── resttemplate-digest.log ├── resttemplate-stat.log ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 示例中通过构造两个 RestTemplate（一个同步一个异步） 发起对同一个 RESTful 服务的调用，调用完成后可以在 restTemplate-digest.log 中看到类似如下的日志： …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-resttemplate/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8b66d6ad488bd59ecbf113b37825d58e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","summary":"在本文档将演示如何使用 SOFATracer 对 RestTemplate 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt;","tags":null,"title":"RestTemplate 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","wordcount":610},{"author":null,"categories":null,"content":" SOFATracer 集成 RestTemplate 后输出请求的链路数据格式，默认为 JSON 数据格式。\nRestTemplate 摘要日志（resttemplate-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SimpleAsyncTaskExecutor-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5009ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RestTemplate 统计日志（resttemplate-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:34:04.130\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5009,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-resttemplate/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c52c919080b467801700a8a1f156c513","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","summary":"SOFATracer 集成 RestTemplate 后输出请求的链路数据格式，默认为 JSON 数据格式。 RestTemplate 摘要日志（resttemplate-digest.log） 以 JSON 格式输出的数据，相应 key 的","tags":null,"title":"RestTemplate 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","wordcount":342},{"author":null,"categories":null,"content":" SOFARPC supports a framework-level retry strategy when the cluster mode is FailOver (SOFARPC uses FailOver mode by default). Retry is only initiated if there is a framework-level exception or a timeout exception on the server. If the business itself throws an exception, the service will not be called again. SOFARPC does not perform any retry by default.\n Note: Although the system will retry calling in case of timeout exception, the server still needs to guarantee the idempotency of the service. Otherwise there may be risks.\n Use XML If you subscribe to the service using XML, you can set the number of retries by setting the retries parameter of sofa:global-attrs:\n\u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;retriesServiceReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.retries.RetriesService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs retries=\u0026amp;quot;2\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation If you are using Annotation, you can set the retries attribute of @SofaReferenceBinding annotation:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, retries = 2)) private SampleService sampleService; Use API in Spring environment If you are using the API in Spring environment, you can call the setRetries method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setRetries(2); Use API in non-Spring environment If you are using the bare API of SOFARPC directly in non-Spring environment, you can call the setRetries method of ConsumerConfig:\nConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt;(); consumerConfig.setRetries(2); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/retry-invoke/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d60b44aa8f1b49ab6c1bbc55593a91da","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","summary":"SOFARPC supports a framework-level retry strategy when the cluster mode is FailOver (SOFARPC uses FailOver mode by default). Retry is only initiated if there is a framework-level exception or a timeout exception on the server. If the business itself throws an exception, the service will not be called again. SOFARPC does not perform any retry by default.\n Note: Although the system will retry calling in case of timeout exception, the server still needs to guarantee the idempotency of the service.","tags":null,"title":"Retry strategy","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","wordcount":205},{"author":null,"categories":null,"content":" SOFAJRaft 2019 年 4-7 月开发计划 (p1) Telnet 服务（或其他，越简单越好），作为一种在线排查问题的手段，主要提供以下几个功能 Raft_stat: 以 node 节点为 root，能列出大部分甚至所有相关 stat Metrics: 展示当前节点最新的所有 metrics 指标度量(虽然日志里有相关数据但是相对分散) (p1) 扩展点：引入 SPI 机制，先列出几个扩展点 LogStorage LogEntry codec RaftMetaStorage Metric 指标度量 (p1) 对于 multi-raft-group 场景，提供一个 manual rebalance api 用于平衡各个节点的 leaders 数量 (p2) 文档国际化 (p2) 添加 Learner 角色，只用于同步数据不参与投票 (p3) RheaKV 完成 jepsen 验证\n ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/road-map/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d39cc6e615d623f8dfc320f32dcbdfa6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/road-map/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/road-map/","summary":"SOFAJRaft 2019 年 4-7 月开发计划 (p1) Telnet 服务（或其他，越简单越好），作为一种在线排查问题的手段，主要提供以下几个功能 Raft_stat: 以 node 节点为 root，能列出大部分甚至所有","tags":null,"title":"Road Map","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/road-map/","wordcount":194},{"author":null,"categories":null,"content":" Roadmap Version 1.5.1 Fixed code style problems in the project: https://github.com/alipay/sofa-bolt/issues/85 Fixed known bugs in the project: https://github.com/alipay/sofa-bolt/issues/82 The RPC layer supports message list dispatching from the I/O thread: https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 Overall goal Unify lifecycle APIs for all components Extract and incorporate network component APIs Converge configuration methods and enhance configuration scalability Unify lifecycle APIs for all components In the current Bolt version, APIs of lifecycle management components are named inconsistently, for example:\n ReconnectManager does not need startup or initialization, and the disabling method is stop. The initialization method for DefaultConnectionMonitor of is start, and the disabling method is destroy. The initialization method forRpcClient init, and the disabling method is shutdown. The initialization method forRpcTaskScanner is start, and the disabling method is shutdown. We plan to unify lifecycle APIs of all components in V1.6.0:\n For components that are subject to lifecycle management, which require initialization before use and must release resources after use, their startup/shutdown APIs are to be unified. Extract and incorporate network component APIs Network operations of Bolt are mainly performed by using the remoting class, which is provided as an abstract class. We plan to converge methods of this class, and provide them in the form of APIs in the future. There are a few advantages of doing so:\n Standardized usage Stable service Convenient internal code iteration Taking the ReconnectManager as an example. It provides the public addCancelUrl method, which is not called in the Bolt project. This may cause problems:\n IDE will give a warning. Users may get confused on whether they should delete this method. We plan to solve the these problems in V1.6.0 by extracting a set of stable APIs, which are convenient for users to use, helpful to improve code readability, and can lay a solid foundation for future iterations.\nConverge configuration methods and enhance configuration scalability Currently, Bolt supports the following configuration methods:\n ProtocolSwitch: supports protocol configuration (enabling or disabling CRC validation), and creates configuration objects by static means. GlobalSwitch: offers instance-level configuration, and offers GlobalSwitch configuration items to every AbstractConfigurableInstance. The default value is taken from the SystemProperty, and the configuration can be adjusted through an API. ConfigItem: enumerates Netty-related configuration items that cannot be inherited or extended before you modify the source code. ConfigManager: reads SystemProperty configurations by static means. Configs: defines the configuration item names and specifies their default values. Generally, Bolt\u0026amp;rsquo;s configuration items look to be loose and scattered and are hard for users to extend their usage. …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-roadmap/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3d4eac90b5c8e657d14eb885ab1f9a92","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","summary":"Roadmap Version 1.5.1 Fixed code style problems in the project: https://github.com/alipay/sofa-bolt/issues/85 Fixed known bugs in the project: https://github.com/alipay/sofa-bolt/issues/82 The RPC layer supports message list dispatching from the I/O thread: https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 Overall goal Unify lifecycle APIs for all components Extract and incorporate network component APIs Converge configuration methods and enhance configuration scalability Unify lifecycle APIs for all components In the current Bolt version, APIs of lifecycle management components are named inconsistently, for example:","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","wordcount":539},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c4532d11cef15d8fe3ff5e04c7b08f90","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","summary":"","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","wordcount":0},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f1d0bf15efba08535f9574e1c8344cab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","summary":"","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","wordcount":0},{"author":null,"categories":null,"content":" Development plans of SOFAJRaft from April to July 2019 (p1) Implement the Telnet service (or similar equivalents, the simpler the better) as an online troubleshooting means. It should be able to provide the following functions: Raft_stat: List most or all stats of a Raft node. Metrics: Uniformly display the latest values of all metrics for the current node (the related data is scattered in the log). (p1) Extension points: introduce the SPI mechanism. Some of the extension points are listed as follows: LogStorage LogEntry codec RaftMetaStorage Metrics (p1) Provide a manual rebalance API for the multi-raft-group scenario to balance the number of leaders on each node. (p2) Translate the document into multiple languages. (p2) Add a learner role that only replicates data and does not vote. (p3) Complete jepsen tests for RheaKV. ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/road-map/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d39cc6e615d623f8dfc320f32dcbdfa6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/road-map/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/road-map/","summary":"Development plans of SOFAJRaft from April to July 2019 (p1) Implement the Telnet service (or similar equivalents, the simpler the better) as an online troubleshooting means. It should be able to provide the following functions: Raft_stat: List most or all stats of a Raft node. Metrics: Uniformly display the latest values of all metrics for the current node (the related data is scattered in the log). (p1) Extension points: introduce the SPI mechanism.","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/road-map/","wordcount":132},{"author":null,"categories":null,"content":" Task list Some of the existing internal features will be available in subsequent iterations.\nThe features that have been implemented are listed in the following table. You are welcome to claim the tasks and make contributions.\n Task type Task Degree of difficulty Claimant and time Planned completion time Progress Related issues Documentation Document translation Low Code Flexible persistent connection management Low #56 Code etcd registry center implementation Medium @wynn5a\n2018-6 #153 Code eureka registry center implementation Medium @liufeiit\n2018-4 #52 Code gRPC support High #57 Code CXF protocol High #58 Code TLS support High Version iteration Plan v5.5.0 Support JSON serialization Support H2 TLS Implement flexible connection pool Integrate Hystrix Support Consul registry center v5.6.0 Support GRPC communication layer Support etcd registry center Support SOFAMesh Implement BOLT version negotiation and CRC verification v5.7.0 Support Telnet built-in instructions Support SpringBoot 2.0 Support Mock function Support encryption v5.8.0 Support authorization Support SofaRegistry Support Reactive ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/roadmap/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"6064fc180911f520f6d1590b88595693","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/roadmap/","summary":"Task list Some of the existing internal features will be available in subsequent iterations.\nThe features that have been implemented are listed in the following table. You are welcome to claim the tasks and make contributions.\n Task type Task Degree of difficulty Claimant and time Planned completion time Progress Related issues Documentation Document translation Low Code Flexible persistent connection management Low #56 Code etcd registry center implementation Medium @wynn5a","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/roadmap/","wordcount":152},{"author":null,"categories":null,"content":" Tasks The following table lists the features that have not yet been implemented. We encourage you to claim the tasks and make a contribution.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document SOFADashboard Parameter Configuration Guide Simple Code Support for SOFARegistry Medium Code Support for Docker Medium Code Support for Kubernetes Medium Code Support for Apollo Medium Code Frontend optimization Medium ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a740c874742b504de9011b07f3a4ddb5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/roadmap/","summary":" Tasks The following table lists the features that have not yet been implemented. We encourage you to claim the tasks and make a contribution.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document SOFADashboard Parameter Configuration Guide Simple Code Support for SOFARegistry Medium Code Support for Docker Medium Code Support for Kubernetes Medium Code Support for Apollo Medium Code Frontend optimization Medium ","tags":null,"title":"Roadmap and task claim","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/roadmap/","wordcount":67},{"author":null,"categories":null,"content":" Roadmap Tasks We have some internal implementations of some new features, which will be released along with the iterations when sorted out.\nFeatures that are not implemented yet are listed in the following table. We encourage you to claim the tasks and contribute to SOFARegistry.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document Document Translation Low Code Support for Spring Cloud Medium Code Data self-check High Code Blacklist filtering Medium Code SOFARegistry Dashboard High Code Support for other microservice frameworks Medium Code Support for Docker \u0026amp;amp; Kubernetes High Code Multi-language client support High Version iteration plan v5.3.0 Support for Spring Cloud Data self-check Blacklist filtering v5.4.0 SOFARegistry Dashboard Support for other microservice frameworks v5.5.0 Support for Docker \u0026amp;amp; Kubernetes Multi-language client support ","date":-62135596800,"description":"","dir":"projects/sofa-registry/roadmap/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b0ab45d52ba3eb7db590a4f5e4197c9e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/roadmap/","summary":"Roadmap Tasks We have some internal implementations of some new features, which will be released along with the iterations when sorted out.\nFeatures that are not implemented yet are listed in the following table. We encourage you to claim the tasks and contribute to SOFARegistry.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document Document Translation Low Code Support for Spring Cloud Medium Code Data self-check High Code Blacklist filtering Medium Code SOFARegistry Dashboard High Code Support for other microservice frameworks Medium Code Support for Docker \u0026amp; Kubernetes High Code Multi-language client support High Version iteration plan v5.","tags":null,"title":"Roadmap and task claims","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/roadmap/","wordcount":128},{"author":null,"categories":null,"content":" AntCoreTest (ACTS) is a white-box test framework developed by Ant Financial based on years\u0026amp;rsquo; testing knowledge and experience with the financial-level distributed architecture for the purpose of providing enterprises with a highly efficient, precise, and automated interface testing services. In addition to general testing capabilities such as data-driven testing provided by conventional open source frameworks like TestNG, ACTS offers new features such as model-driven testing, visualized editing, and a standard process engine to assist engineers with efficient and high quality test case compilation as well as standard and precise test validation for interface testing.\nACTS is a next generation testing framework based on the data model-driven testing engine. ACTS is applicable to context environments that require the integration of TestNg and Spring. ACTS uses the YAML file as the data carrier and builds data model drivers upon it, providing features such as the all-in-one editor, precise validation, and efficient test case management to significantly improve testing efficiency.\nOperating principle Upon the start of the test script, ActsDataProvider starts the tested method (the method annotated by @Test), loads the corresponding test case data file (YAML file), and converts the data into corresponding PrepareData objects.\n When runTest starts running, it passes PrepareData and test case names to ACTS. ACTS then assembles such information into the ActsRuntimeContext class, transmits it in the entire process, and initializes the TestUnitHandler. The running period of the runTest process method consists of the following stages:\n | Action | Method | | :\u0026amp;mdash; | :\u0026amp;mdash; | | Clear | clear(actsRuntimeContext) | | Prepare | prepare(actsRuntimeContext) | | Execute | execute(actsRuntimeContext) | | Check | check(actsRuntimeContext) |\nDescription:\n Clear: Clean up the preparation data and validation data to avoid the negative impact of dirty data on the test script. Prepare: Prepare data such as DB data. Execute: Call the tested method, and capture the corresponding information, such as responses and exception messages. Check: Validate the corresponding information such as the responses, DB data, and exception messages based on the test data. Features ACTS provides the following features:\n2.1 All-in-one editor The ACTS framework separates the test data from the test code, and provides the visual editor ACTS IDE. ACTS IDE can help you quickly enter, view, and manage the test case data, which significantly reduces repetitive coding.\n2.2 Precise validation To improve data fill-in efficiency and reduce omission of check points among the expectation data, such as response expectations and database expectations, the ACTS framework provides a run and backfill function. In addition, ACTS uses validation rule flags to implement precise validation of the expectation data.\n2.3 Flexible scalability ACTS provides a rich variety of APIs, which are encapsulated …","date":-62135596800,"description":"","dir":"projects/sofa-acts/overview/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ac57071cd0d40a63359d476d05344c61","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/overview/","summary":"AntCoreTest (ACTS) is a white-box test framework developed by Ant Financial based on years\u0026rsquo; testing knowledge and experience with the financial-level distributed architecture for the purpose of providing enterprises with a highly efficient, precise, and automated interface testing services. In addition to general testing capabilities such as data-driven testing provided by conventional open source frameworks like TestNG, ACTS offers new features such as model-driven testing, visualized editing, and a standard process engine to assist engineers with efficient and high quality test case compilation as well as standard and precise test validation for interface testing.","tags":null,"title":"SOFAActs overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/overview/","wordcount":556},{"author":null,"categories":null,"content":" ACTS（AntCoreTest）源于蚂蚁金服多年金融级分布式架构工程的测试实践的积累与沉淀，是一款白盒测试框架，旨在为企业提供高效、精细化的接口自动化测试。 与现有的诸如 TestNG 等开源框架相比，ACTS 除了具备通用的数据自动化驱动等测试能力外，还具有契合快速的互联网发展和复杂的分布式金融系统特点的模型驱动、可视化编辑和标准流程引擎等新特性，可辅助工程师高效、高质量地完成接口测试用例编写以及标准化精准化测试验证。\nACTS 是基于数据模型驱动测试引擎执行的的新一代测试框架（如图1所示），适配 TestNg+Spring 的测试上下文环境，以 YAML 为数据载体并在此上构建数据模型驱动，实现了一站式编辑、精细化校验和高效用例管理等，可以有效提高测试效率。\n运行原理 测试脚本启动的时，ActsDataProvider 会启动被测方法（被 @Test 注解的方法），加载对应的用例数据文件(以 YAML 文件承载)，然后转换成对应的 PrepareData 对象； runTest 开始执行时会传入 PrepareData 和用例名称，ACTS 根据这些信息组装出 ActsRuntimeContext 上下文并在整个过程中传递，同时初始化 TestUnitHandler 测试处理器。runTest -\u0026amp;gt; process 方法执行期包含如下四个子流程：\n 说明 方法 清理 clear(actsRuntimeContext) 准备 prepare(actsRuntimeContext) 执行 execute(actsRuntimeContext) 检查 check(actsRuntimeContext) 方法功能说明： + 清理阶段：清理准备数据、校验数据，防止脏数据对测试脚本产生影响； + 准备阶段：准备 DB 数据等； + 执行阶段：调用被测方法，捕获返回结果和异常等信息； + 检查阶段：根据测试数据，校验返回结果、DB 数据和异常信息等内容。\n功能描述 ACTS 提供了以下能力：\n2.1 一站式编辑 框架实现了测试数据与测试代码的分离，同时配套提供可视化编辑器 ACTS IDE，通过 ACTS IDE 可以快速地录入、查看和管理用例数据，有效减少重复性编码。\n2.2 精细化校验 为了提高返回结果、DB 数据等期望数据的填写效率和减少检验点遗漏，框架提供了预跑返填功能；同时在 ACTS 校验规则标签的标记下，实现期望 DB 数据、期望结果等数据的精细化校验。\n2.3 灵活可扩展 ACTS 提供了丰富的 API ，其封装于 ActsRuntimeContext 类中，借助 API 可快速获取和设置自定义参数、用例入参、期望结果等，满足用户对用例数据的自定义操作；\n同时，框架的 ActsTestBase 测试基类对外暴露各个执行阶段方法，包括 prepare，execute，check，clear 等，例如在测试类中通过重写 process 方法可将整个测试脚本重新编排。\n2.4 统一配置能力 配置文件中提供丰富的配置能力以定制化框架的个性需求。\n应用场景 基于 SOFABoot 搭建的应用，在 Intellij IDEA 开发环境下快速编写和执行接口测试用例。推荐使用 Intellij IDEA 2017 以便能更好地兼容 ACTS IDE。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/overview/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ac57071cd0d40a63359d476d05344c61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/overview/","summary":"ACTS（AntCoreTest）源于蚂蚁金服多年金融级分布式架构工程的测试实践的积累与沉淀，是一款白盒测试框架，旨在为企业提供高效、精细化","tags":null,"title":"SOFAActs 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-acts/overview/","wordcount":998},{"author":null,"categories":null,"content":" SOFAArk offers a variety of methods to support multi-application (module) consolidation and deployment, including command line-based control and API-based control. SOFAArk control is an implementation of SOFADashboard\u0026amp;rsquo;s control over APIs. SOFAArk control is implemented by pushing commands to and parsing commands in ZooKeeper.\nSOFAArk control mainly provides the following functions:\n Plug-in registration: registers the ark-biz package with SOFADashboard as basic data processors. Application association: binds the ark-biz package with host applications. Plug-in details: On the plug-in details page, you can view the information about all host applications that are associated with the current ark-biz package, as well as the status information of the ark-biz package in these host applications. Command push: On the plug-in details page, you can push some commands for specific applications and IP addresses, such as install and uninstall. When these commands are written to a ZooKeeper node, all host applications that listen to this node will parse the commands and perform related operations. Plug-in registration Register the ark-biz package with SOFADashboard:\nEnter basic information of the plug-in\nAfter successful registration, the plug-in is displayed on the module list as follows.\nApplication association Click Associate application in the Actions column of a plug-in on the module list to associate it with an application.\nClick Associate application in the Actions column of the plug-in to associate it with an application.\nPlug-in details Click Details in the Actions column of a plug-in to view all apps and app instances associated with the current plug-in.\n Version switch After switching the plug-in to V2.0.0, the status information is empty, because the plug-in V2.0.0 has not been installed in the host application.\nCommand push SOFADashboard supports command push in two dimensions:\n Application-based command push, where all instances of the specified application listen to this command IP-based and group-based command push for single-IP address scenarios IP-based command push Click Install. The page is refreshed after about 1s to 1.5s.\n Application-based command push is similar.\n ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/ark-console/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b42cffbb8e55a4c47412e49de0e9b228","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/ark-console/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/ark-console/","summary":"SOFAArk offers a variety of methods to support multi-application (module) consolidation and deployment, including command line-based control and API-based control. SOFAArk control is an implementation of SOFADashboard\u0026rsquo;s control over APIs. SOFAArk control is implemented by pushing commands to and parsing commands in ZooKeeper.\nSOFAArk control mainly provides the following functions:\n Plug-in registration: registers the ark-biz package with SOFADashboard as basic data processors. Application association: binds the ark-biz package with host applications.","tags":null,"title":"SOFAArk control","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/ark-console/","wordcount":321},{"author":null,"categories":null,"content":" SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献，目前已经基于 SOFAArk 提供了模块化合并部署的完整解决方案 koupleless, 如果想要使用合并部署能力，建议查看 Koupleless 使用文档，如果只是想要使用的类隔离能力可以查看 SOFAArk Plugin 能力，继续查看本站点相关文档；\n在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin） 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz) 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz 基于以上能力，SOFAArk 可以帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\n场景 包冲突 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError, NoSuchMethodError 等；实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法，统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突；这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题；如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题； OSGI 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGI 框架太过臃肿，功能繁杂；为了解决包冲突问题，引入 OSGI 框架，有牛刀杀鸡之嫌，且反而使工程变得更加复杂，不利于开发；\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如果工程需要引入两个三方包：A 和 B，但是 A 需要依赖版本号为 0.1 的 C 包，而恰好 B 需要依赖版本号为 0.2 的 C 包，且 C 包的这两个版本无法兼容：\n此时，即可使用 SOFAArk 解决该依赖冲突问题；只需要把 A 和版本为 0.1 的 C 包一起打包成一个 Ark 插件，然后让应用工程引入该插件依赖即可；\n合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n静态合并部署 SOFAArk 提供了静态合并部署能力，在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成可执行 Fat Jar 时，可以将其他应用 Biz 包一并打入，启动时，则会根据优先级依次启动各应用。每个 Biz 使用独立的 BizClassLoader 加载，不需要考虑相互依赖冲突问题，Biz 之间则通过 SofaService/SofaReference JVM 服务进行交互。\n动态合并部署 动态合并部署区别于静态合并部署最大的一点是，运行时通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态合并部署的设计理念图如下：\n无论是静态还是动态合并部署都会有宿主应用（master biz）的概念, 如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主应用不允许被卸载，一般而言，宿主应用会作为流量入口的中台系统，具体的服务实现会放在不同的动态 Biz 中，供宿主应用调用。宿主应用可以使用 SOFAArk 提供的客户端 API 实现动态应用的部署和卸载。除了 API, SOFAArk 提供了 Config Plugin，用于对接配置中心（目前支持 Zookeeper），运行时接受动态配置；Config Plugin 会解析下发的配置，控制动态应用的部署和卸载。\n原理 SOFAArk 包含三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下:\n 在介绍这三个概念之前，先介绍上述 Ark 包概念；Ark 包是满足特定目录格式要求的可运行 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将单个或多个应用打包成标准格式的 Ark 包；使用 java -jar 命令即可在 SOFAArk 容器之上启动所有应用；Ark 包通常包含 Ark Container、Ark Plugin 和 Ark Biz；以下我们针对这三个概念简单做下名词解释：\n Ark Container: SOFAArk 容器，负责 Ark 包启动运行时的管理；Ark Plugin 和 Ark Biz 运行在 SOFAArk 容器之上；容器具备管理插件和应用的功能；容器启动成功后，会自动解析 classpath 包含的 Ark Plugin 和 Ark Biz 依赖，完成隔离加载并按优先级依次启动之；\n Ark Plugin: Ark 插件，满足特定目录格式要求的 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-plugin-maven-plugin 可以将一个或多个普通的 Java jar 打包成一个标准格式的 Ark …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-readme/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cdb6729fc7a63954b7559c8ea319f550","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","summary":"SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献，目前已经基于 SOFAArk 提供了模块化合并部署的","tags":null,"title":"SOFAArk 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","wordcount":2660},{"author":null,"categories":null,"content":" 【SOFAChannel 分享】SOFAArk 类隔离框架设计原理 https://www.bilibili.com/video/BV1gS4y1i7Fg/?spm_id_from=333.999.0.0\n\n【SOFA 开源四周年分享】Serverless 技术简介 https://www.bilibili.com/video/BV1nU4y1B7u3/?spm_id_from=333.999.0.0\n\n【SOFA Meetup 云原生技术沙龙】SOFAServerless 体系助力业务极速研发 https://www.bilibili.com/video/BV1Ld4y1P7VK/?spm_id_from=333.999.0.0\n\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-public-presentation/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c460ccc2d706f49e26eb4f74d5468d63","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","summary":"【SOFAChannel 分享】SOFAArk 类隔离框架设计原理 https://www.bilibili.com/video/BV1gS4y1i7Fg/?spm_id_from=333.999.0.0 【SOFA 开源四周年分享】Serverless 技术简介 https://www.bilibili.com/video/BV1nU4y1B7u3/?spm_id_from=333.999.0.0 【SOFA Meetup 云原生技","tags":null,"title":"SOFAArk 相关公开分享材料","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","wordcount":99},{"author":null,"categories":null,"content":" SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAARK 管控是 SOFADashboard 针对 API 的管控的一种实现。通过面向 Zookeeper 进行命令的推送和命令的解析执行。\nSOFAArk 管控主要包括以下功能：\n 插件注册：将 ark-biz 插件注册到 SOFADashboard，作为基础数据 关联应用：将 ark-biz 插件与宿主应用进行绑定 插件详情：通过插件详情页，可以看下当前 ark-biz 插件下所有关联的宿主应用信息，以及宿主应用中的ark-biz 状态信息 命令推送：插件详情页，可以针对应用维度、分组维度、IP 维度 推送一些指令，比如 install、uninstall 等等，当这些命令被写入到 Zookeeper 的某个节点上时，所有监听此节点的 宿主应用均会解析此指令，并进行相关的操作 插件管理 插件注册 将 ark-biz 插件注册到 SOFADashboard：\n插件删除 添加插件版本 插件版本 biz 包路径 删除版本 关联应用 点击模块列表操作菜单栏中的关联应用，可以将一个应用与插件进行绑定：\n动态管控 点击插件列表后面的 详情 按钮，可以查看当前插件下所有应用信息和应用实例信息。\n命令推送 SOFADashboard 提供三种维度的命令推送\n 基于应用维度，当前应用所有的实例都会监听到此命令变更 基于IP 维度，分组维度的单 ip 场景 动态模块详情 点击 状态详细按钮，左侧栏将会展开 \u0026amp;ldquo;抽屉\u0026amp;rdquo; 展示详情状态数据\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/ark-console/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b42cffbb8e55a4c47412e49de0e9b228","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/ark-console/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/ark-console/","summary":"SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAARK 管控是 SOFADashboard 针对 API 的管控的一种实现。通过面","tags":null,"title":"SOFAArk 管控","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/ark-console/","wordcount":541},{"author":null,"categories":null,"content":" SOFAArk 的配置目录不是必须存在，如果需要，统一放在工程根目录 ${baseDir}/conf/ark 下，执行 sofa-ark-maven-plugin 打包，将会自动将该目录下的配置打包至 Ark 包，例如 Ark 包目录为：\n. ├── META-INF │ └── MANIFEST.MF ├── SOFA-ARK │ ├── biz │ │ └── demo-0.0.1-SNAPSHOT-ark-biz.jar │ └── container │ └── sofa-ark-all-0.6.0-SNAPSHOT.jar ├── com │ └── alipay │ └── sofa │ └── ark │ ├── ... │ └── conf └── ark ├── bootstrap-dev.properties ├── bootstrap.properties └── log └── logback-conf.xml 注意事项：如果应用中包含 SOFAArk 配置，打包时需要注意 baseDir 配置，用于指定工程根目录，具体参考文档\n上述 conf/ark 目录中可以配置 SOFAArk 容器启动配置以及日志配置，下面介绍配置的使用.\nconf/ark/bootstrap.properties 是 SOFAArk 容器默认启动配置文件，配置内容包括：日志配置、plugin 激活和钝化配置、biz 激活和钝化配置.\n日志配置 SOFAArk 容器日志内部实现使用 logback, 日志配置参数包括： + logging.path \u0026amp;gt; 容器日志目录根路径，这里只影响 SOFAArk 容器日志路径，不影响应用日志，应用自身日志由自身配置决定，默认打印在 ${user.admin}/logs 目录\n logging.level.com.alipay.sofa.ark \u0026amp;gt; 设置 SOFAArk 容器日志级别，默认为 INFO\n logging.config.com.alipay.sofa.ark \u0026amp;gt; 指定自定义日志配置文件名，用于覆盖 SOFAArk 容器自带的日志配置文件。建议自定义配置文件放在 conf/ark/log 目录中\n sofa.middleware.log.com.alipay.sofa.ark.console \u0026amp;gt; 配置容器日志是否打印在 console，默认为 false.\n sofa.middleware.log.com.alipay.sofa.ark.console.level \u0026amp;gt; 配合上述配置项使用，如果打印在 console ，该配置项用于配置 SOFAArk 容器打印在 console 的日志级别\n 插件配置 ark.plugin.active.include \u0026amp;gt; 指定激活哪些插件，多个插件使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认激活 Ark 包中所有的插件。\n ark.plugin.active.exclude \u0026amp;gt; 指定排除哪些插件，多个插件使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认为空\n 注：如果同时配置了这两个属性，以 ark.plugin.active.include 为准\nbiz配置 ark.biz.active.include \u0026amp;gt; 指定激活哪些 Biz，多个 Biz 使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认激活 Ark 包中所有的 Biz.\n ark.biz.active.exclude \u0026amp;gt; 指定排除哪些 Biz，多个 Biz 使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认为空\n com.alipay.sofa.ark.master.biz \u0026amp;gt; 指定宿主 Biz 名，如果 Ark 包中只有一个 Biz，则不用设置，默认设置为宿主 Biz; 否则需要显示设置\n 注：如果同时配置了前两个属性，以 ark.biz.active.include 为准\n动态配置 SOFAArk 提供了对接 Zookeeper 的插件，目前用于动态接收 Biz 指令，目前只支持 Zookeeper，配置格式如下：\ncom.alipay.sofa.ark.config.address=zookeeper://ip:port?key1=value1\u0026amp;amp;key2=value2 特别注意，SOFAArk 有一个默认的逻辑，如果用户配置了 com.alipay.sofa.ark.config.address，且 Ark 包中打入了多个 Biz，则只会启动宿主应用(master biz)；这样做的原因是如果配置了动态配置，SOFAArk 会优先根据动态配置控制 Biz 的部署。\nProfile 机制 默认 SOFAArk 容器使用 bootstrap.properties 配置，实际开发中，可能根据运行环境加载不同的配置，SOFAArk 提供了 profile 机制. 指定 profile 值，SOFAArk 容器会加载 bootstrap-${profile}.properties 配置文件。指定 profile 的配置有两种方式： + 通过 -D VM 参数传入，例如：-Dark.profile=dev,dev2 多个值使用 \u0026amp;lsquo;,\u0026amp;rsquo; 隔开。 + 通过应用启动参数传入，例如：java -jar demo-executable-ark.jar -Aprofile=dev,dev2 多个值使用 \u0026amp;lsquo;,\u0026amp;rsquo; 隔开。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-config/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"70dd9c389e65ee3f89573cf93bd466ec","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","summary":"SOFAArk 的配置目录不是必须存在，如果需要，统一放在工程根目录 ${baseDir}/conf/ark 下，执行 sofa-ark-maven-plugin 打包，将会自动将该目录下的配置打包至 Ark 包，例如 Ark 包目录为： . ├── META-INF │ └─","tags":null,"title":"SOFAArk 配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","wordcount":1036},{"author":null,"categories":null,"content":" 背景 SOFAArk 框架包含有三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下：\n 每次应用启动时，首先运行 Ark 包，Ark Container 优先启动，容器自动解析 Ark 包中含有的 Ark Plugin 和 Ark Biz，并读取他们的配置信息，构建类和资源的加载索引表；然后使用独立的 ClassLoader 加载并按优先级配置依次启动；需要指出的是，Ark Plugin 优先 Ark Biz 被加载启动。 详细介绍可阅读： SOFAArk 介绍\n在三层概念的基础上，衍生出复杂的类加载机制，如图：\n详细介绍可阅读：Ark 容器类加载机制\n问题一 由于Ark Plugin的存在，插件在依赖层面的强管控，造成了一些问题 - 业务使用的依赖是被插件管控导出的，但是插件管控导出的版本与业务实际期望的版本不符（比如插件管控的版本是 1.0，而业务需要的是 2.0）。 - 插件对于依赖的强管控，直接堵住了业务扩展插件能力的路；也存在部分依赖，当业务引入时会直接报错（其package 被导出了，但是依赖不在插件中），那么对于业务来说就只能等框架发版解决。 - 业务接入成本，学习成本较高，问题排查困难，需要非常熟悉Ark类加载机制。 - 由于管控依赖的增长，Ark Plugin难以持续维护\n问题二 另外，由于Ark Container先于master biz启动，master biz的启动入口和springboot/sofaboot不一致，导致Ark master biz的的启动在研发运维中需要定制镜像，定制启动入口，造成研发运维困难。\nSOFAArk2.0 针对这些问题，我们尝试从框架层面去优化三层结构，沉淀出了SOFAArk2.0方案，整体优化思路和原则是 Ark Master Biz保持和原生springboot/sofaboot保持一致，弱化复杂的Ark Plugin类管控机制，将Ark Plugin与master biz合并。\nSOFAArk2.0方案整体优化点： - 弱化Ark Plugin层，改为普通pom依赖； - Ark master biz和原生的springboot/sofaboot应用启动方式，类加载方式保持一致； - 优化Ark Biz启动速度；\n升级方式 版本升级 SOFAArk版本号第一位为大版本号，当为1.x.x时为SOFAArk1.0版，当为2.x.x时是SOFAArk2.0版，当前2.0版本已正式release，Release-Notes\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;sofa.ark.version\u0026amp;gt;1.1.6\u0026amp;lt;/sofa.ark.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; 改为\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;sofa.ark.version\u0026amp;gt;2.0.0\u0026amp;lt;/sofa.ark.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; 打包插件 对于基座来说，在SOFAArk1.0中使用sofa-ark-maven-plugin打包，在SOFAArk2.0中采用spring-boot原生打包插件spring-boot-maven-plugin打包对于模块来说，则继续使用 sofa-ark-maven-plugin 来打包。\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 替换为：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 运行启动 方式一：IDEA启动 本地启动需要加上启动参数\n -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二：命令行启动 Ark包是可执行Jar，可直接使用Java -jar的方式启动，先使用 mvn clean package 进行打包，打包得到 ${bizName}-${bizVersion}-ark-biz.jar， …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-migration-guide/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b924edd10ef0e13f7220cff7c019d137","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","summary":"背景 SOFAArk 框架包含有三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下： 每次应用启动时，首先运行 Ark 包，Ark Container 优先启动，容器自动解析 Ark 包中含有的 Ark","tags":null,"title":"SOFAArk2.0 升级","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","wordcount":1286},{"author":null,"categories":null,"content":" Introduction SOFABolt is a network communication framework implemented based on Netty and developed by Ant Finance.\n Netty was developed to let Java programmers focus more on the implementation of network communication-based business logic, and not worry excessively about network low-level NIO implementation or network problems that are difficult to debug. SOFABolt was developed to let middleware developers focus more on the implementation of products\u0026amp;rsquo; functional performance, and not on making the communication framework\u0026amp;rsquo;s wheels over and over again. Bolt takes its name from a Disney movie character. Bolt is a light, easy-to-use, high-performance, and flexibly scalable communication framework based on the Netty best practices. In the past few years, we have solved a lot of problems in terms of network communication for microservices and message oriented middleware. We have accumulated a lot of experience and have been constantly optimizing and improving our solutions. We hope that our solutions can be incorporated into the SOFABolt base component to serve more network communication scenarios. At present, SOFABolt has already been put to use in many Ant Middleware products, such as microservice products (SOFARPC), message queue, distributed transactions, distributed switches, and configuration centers.\nMultiple languages supported node Python cpp ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/overview/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5ee08df7c4bbd2c3be846e16f3bc81b1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/overview/","summary":"Introduction SOFABolt is a network communication framework implemented based on Netty and developed by Ant Finance.\n Netty was developed to let Java programmers focus more on the implementation of network communication-based business logic, and not worry excessively about network low-level NIO implementation or network problems that are difficult to debug. SOFABolt was developed to let middleware developers focus more on the implementation of products\u0026rsquo; functional performance, and not on making the communication framework\u0026rsquo;s wheels over and over again.","tags":null,"title":"SOFABolt overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/overview/","wordcount":196},{"author":null,"categories":null,"content":" 功能架构 SOFABolt　的基础功能： 基础通信功能 ( remoting-core ) 基于 Netty 高效的网络 IO 与线程模型运用 连接管理 (无锁建连，定时断链，自动重连) 基础通信模型 ( oneway，sync，future，callback ) 超时控制 批量解包与批量提交处理器 心跳与 IDLE 事件处理 协议框架 ( protocol-skeleton ) 命令与命令处理器 编解码处理器 心跳触发器 私有协议定制实现 - RPC 通信协议 ( protocol-implementation ) RPC 通信协议的设计 灵活的反序列化时机控制 请求处理超时 FailFast 机制 用户请求处理器 ( UserProcessor ) 双工通信 用法1 将 SOFABolt 用作一个远程通信框架，使用者可以不用关心如何实现一个私有协议的细节，直接使用我们内置的 RPC 通信协议。可以非常简单的启动客户端与服务端，同时注册一个用户请求处理器，即可完成远程调用。同时，像连接管理、心跳等基础功能特性都默认可以使用。 当前支持的调用类型如下图所示：\n 示例 Demo 请参考我们的 用户手册 用法2 将 SOFABolt 用作一个协议框架，使用者可以复用基础的通信模型、协议包含的接口定义等基础功能。然后根据自己设计的私有协议自定义 Command 类型、Command 处理器、编解码处理器等。如下图所示，RPC 和消息的 Command 定义结构：\n","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-functions/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fde29139cbd8b786326a6479e52814dd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","summary":"功能架构 SOFABolt 的基础功能： 基础通信功能 ( remoting-core ) 基于 Netty 高效的网络 IO 与线程模型运用 连接管理 (无锁建连，定时断链，自动重连) 基础通信模型 ( oneway，","tags":null,"title":"SOFABolt 功能介绍","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","wordcount":450},{"author":null,"categories":null,"content":" 参与贡献 开放代码允许在签署协议之后,提交贡献代码.\n版权协议 对 SOFABolt 代码的修改和变更，需要遵守版权协议。\n准备工作 贡献代码前需要先了解git工具的使用和GitHub网站的使用。 git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git协作流程 GitHub 贡献代码流程 提issue 不论你是修复 Bolt 的bug还是新增 Bolt 的功能，在你提交代码之前，在 Bolt 的GitHub上提交一个 issue, 描述你要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突,产生重复工作。Bolt 的维护人员会对你提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提issue后，点击左上角的fork按钮，复制一份 Bolt 主干代码到你的代码仓库。\n拉分支 Bolt 所有修改都在分支上进行，修改完后提交 pull request ， 在code review 后由项目维护人员 merge 到主干。 因此，在获取源码步骤介绍后，你需要：\n 下载代码到本地,这一步你可以选择git/https方式. git clone https://github.com/sofastack/sofa-bolt.git 拉分支准备修改代码 git branch add_xxx_feature 执行完上述命令后，你的代码仓库就切换到相应分支了。执行如下命令可以看到你当前分支： git branch -a 如果你想切换回主干，执行下面命令: git checkout -b master 如果你想切换回分支，执行下面命令： git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 想直接从github上拉取分支到本地 git clone -b branchname https://xxx.git 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 Bolt 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行 mvn clean package 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在bugs，而新的代码已经解决了这些bugs. 你可以用如下命令运行所有测试\nmvn clean test 也可以通过IDE来辅助运行.\n其它注意事项 请保持你编辑的代码的原有风格,尤其是空格换行等. 对于无用的注释, 请直接删除 对逻辑和功能不容易被理解的地方添加注释. 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地: git commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到github上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面你是通过fork来做的,那么那么这里的 origin 是push到你的代码仓库，而不是 Bolt 的代码仓库.\n提交合并代码到主干的请求 在你的代码提交到GitHub后，你就可以发送请求来把你改好的代码合入 Bolt 主干代码了。此时你需要进入你的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是主干master, 系统会通知 Bolt 的人员，Bolt 人员会 review 你的代码，符合要求后就会合入主干，成为 Bolt 主干代码的一部分。\n代码review 在你提交代码后，你的代码会被指派给维护人员review,请保持耐心。如果在数天后，仍然没有人对你的提交给予任何回复，可以在pull request下面留言,并@对应的人员. 对于代码review的意见会提交到对应issue。如果觉得建议是合理的，也请你把这些建议更新到你的补丁中。\n合并代码到主干 在代码 Bolt 通过后，就由 Bolt 维护人员操作合入主干了。这一步不用参与,review合并之后,你会收到合并成功的提示.\nContributing to SOFABolt SOFABolt is released under the Apache 2.0 license, and follows a very standard Github development process, using Github tracker for issues and merging pull requests into master . If you would like to contribute something, or simply want to hack on the code this document should help you get started.\nSign the Contributor License Agreement Before we accept a non-trivial patch or pull request we will need you to sign the Contributor License Agreement. Signing the contributor’s agreement does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do. Active contributors might be asked to join the core team, and given the ability to merge pull requests.\nCode Conventions None of these is essential for a pull request, but they will all help.\n we provided a code formatter file, it will formatting automatically your project when during process of building.\n Make sure all new .java files to have a simple Javadoc class comment with at least an @author tag identifying you, and preferably at least a paragraph on what the class is for.\n Add the …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-contribution/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c044ad534cf99e4d6d400113b490f816","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","summary":"参与贡献 开放代码允许在签署协议之后,提交贡献代码. 版权协议 对 SOFABolt 代码的修改和变更，需要遵守版权协议。 准备工作 贡献代码前需要先了解git工具的使","tags":null,"title":"SOFABolt 参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","wordcount":1650},{"author":null,"categories":null,"content":" 发展路线 Version 1.5.1 修复项目中代码风格的问题：https://github.com/alipay/sofa-bolt/issues/85 修复项目中已知的BUG：https://github.com/alipay/sofa-bolt/issues/82 RPC 层支持从 IO 线程派发 message list：https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 整体目标 统一生命周期组件 抽象并沉淀网络组件的API 收敛配置入口\u0026amp;amp;增强配置的可扩展性 统一生命周期组件 在1.5.x的Bolt版本中，管理组件的生命周期相关的API命名并不统一，比如：\n ReconnectManager不需要启动或者初始化，关闭方法为stop DefaultConnectionMonitor初始化方法为start，关闭的方法为destroy RpcClient初始化方法为init，关闭的方法为shutdown RpcTaskScanner初始化的方法为start，关闭方法为shutdown 在1.6.0版本里，统一了所有组件的生命周期接口：\n 对于有生命周期的组件，即使用前需要进行初始化，使用完毕需要释放资源的，统一提供startup/shutdown接口 抽象并沉淀网络组件的API Bolt中remoting类是网络操作的主要入口，目前以抽象类的形式提供，后续希望对方法进行收敛，暴露对应的接口：\n 标准化，规范使用 沉淀接口，保持稳定 收敛入口，便于内部的代码迭代 在1.5.x的版本中，ReconnectManager类尽管提供了public的addCancelUrl方法，但是这个方法在Bolt项目中没有调用：\n IDE会给出警告 给用户造成困惑：这个方法可否删除？ 在1.6.0版本中解决了以上的问题，抽象出一套稳定的API，便于用户使用、提升代码可读性，同时也为后续的迭代打下基础。\n收敛配置入口\u0026amp;amp;增强配置的可扩展性 1.5.x版本的Bolt配置入口有以下几个：\n ProtocolSwitch：协议配置（是否开启CRC校验），通过静态的方法创建配置对象 GlobalSwitch：实例级配置，每个AbstractConfigurableInstance拥有自己的GlobalSwitch配置，默认值取自SystemProperty，可以通过API调整配置 ConfigItem：Netty相关的配置项的枚举，不可以继承拓展（用户需要修改源码） ConfigManager：配置读取入口，通过静态方法读取SystemProperty的配置 Configs：配置项名称的定义和配置项的默认值 整体上看Bolt的配置项比较零散，且对用户来说难以拓展使用，有以接口暴露的配置项、有以静态方法暴露的配置项，配置项可以通过系统参数配置也可以通过API执行配置。\n且Bolt配置项存在相互影响的问题，比如一个产品同时使用了RPC和消息，而RPC和消息底层都依赖于Bolt，那么基于SystemProperty的配置将无法做到RPC和消息的配置隔离。\n在1.6.0版本中对配置模块进行了调整，在兼容当前版本配置的情况下：\n 收敛配置入口，提供统一的配置的编程界面（以类似Netty的Option的方式进行配置） 支持配置隔离，不同的Bolt实例使用不同的配置项 提升配置的可扩展性 ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-roadmap/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3d4eac90b5c8e657d14eb885ab1f9a92","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","summary":"发展路线 Version 1.5.1 修复项目中代码风格的问题：https://github.com/alipay/sofa-bolt/issues/85 修复项目中已","tags":null,"title":"SOFABolt 发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","wordcount":1356},{"author":null,"categories":null,"content":" 介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生。 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，积累了很多经验，并持续的进行着优化和完善，我们希望能把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。 目前该产品已经运用在了蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n多语言 node python cpp ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/overview/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5ee08df7c4bbd2c3be846e16f3bc81b1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/overview/","summary":"介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于","tags":null,"title":"SOFABolt 概述","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/overview/","wordcount":369},{"author":null,"categories":null,"content":" 用户指南 maven coordinator \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; check release note for version\n 1. 基础功能 1.1 实现用户请求处理器 (UserProcessor) 我们提供了两种用户请求处理器，SyncUserProcessor 与 AsyncUserProcessor。 二者的区别在于，前者需要在当前处理线程以return返回值的形式返回处理结果；而后者，有一个 AsyncContext 存根，可以在当前线程，也可以在异步线程，调用 sendResponse 方法返回处理结果。示例可参考如下两个类：\n 同步请求处理器 异步请求处理器 1.2 实现连接事件处理器 (ConnectionEventProcessor) 我们提供了两种事件监听，建连事件（ConnectionEventType.CONNECT）与断连事件（ConnectionEventType.CLOSE），用户可以创建自己的事件处理器，并注册到客户端或者服务端。客户端与服务端，都可以监听到各自的建连与断连事件。\n 处理连接建立事件 处理连接断开事件 1.3 客户端与服务端初始化 (RpcClient，RpcServer) 我们提供了一个 RpcClient 与 RpcServer，经过简单的必要功能初始化，或者功能开关，即可使用。一个最简单的例子如下：\n 客户端初始化示例 服务端初始化示例 1.4 基础通信模型 我们提供了四种通信模型：\n1.Oneway 调用\n当前线程发起调用后，不关心调用结果，不做超时控制，只要请求已经发出，就完成本次调用。注意 Oneway 调用不保证成功，而且发起方无法知道调用结果。因此通常用于可以重试，或者定时通知类的场景，调用过程是有可能因为网络问题，机器故障等原因，导致请求失败。业务场景需要能接受这样的异常场景，才可以使用。请参考示例。\n2. Sync 同步调用\n当前线程发起调用后，需要在指定的超时时间内，等到响应结果，才能完成本次调用。如果超时时间内没有得到结果，那么会抛出超时异常。这种调用模式最常用。注意要根据对端的处理能力，合理设置超时时间。请参考示例。\n3. Future调用\n当前线程发起调用，得到一个 RpcResponseFuture 对象，当前线程可以继续执行下一次调用。可以在任意时刻，使用 RpcResponseFuture 对象的 get() 方法来获取结果，如果响应已经回来，此时就马上得到结果；如果响应没有回来，则会阻塞住当前线程，直到响应回来，或者超时时间到。请参考示例。\n4. Callback异步调用\n当前线程发起调用，则本次调用马上结束，可以马上执行下一次调用。发起调用时需要注册一个回调，该回调需要分配一个异步线程池。待响应回来后，会在回调的异步线程池，来执行回调逻辑。请参考示例。\n1.5 日志打印 SOFABolt 只依赖 SLF4J 作为日志门面。同时提供了 log4j、log4j2、logback 三种日志模板，使用者只需要在运行时依赖某一种日志实现，我们依赖的 sofa-common-tools 组件，会在运行时动态感知是哪一种日志实现，同时加载正确的日志模板，进行打印。日志会打印在 ~/logs/bolt/ 目录下面，包括如下几种日志：\n common-default.log：默认日志，打印一些客户端、服务器启动、关闭等通信过程的普通日志 common-error.log：异常日志，框架运行过程中出现的异常 connection-event.log：连接事件日志 remoting-rpc.log：RPC 协议相关的日志 关于日志依赖，可以参考日志实现依赖参考\n2. 进阶功能 2.1 请求上下文 在调用过程中，我们还提供了带 InvokeContext 的接口，并一路传递下去，可以在自定义序列化器，用户请求处理器中获得。我们分为两种场景来使用请求上下文：\n 客户端：用户可以设置一些针对本次请求生效的参数，比如序列化类型，是否开启crc等机制。同时可以从上下文中获取建连耗时，连接信息等。 服务端：用户可以从用户请求处理器中获得请求到达后的排队耗时，连接信息等 注意：客户端与服务端的上下文是独立的，即客户端设置的上下文只在客户端可见，对服务端不可见；反之同理。 使用示例 2.2 双工通信 除了服务端可以注册用户请求处理器，我们的客户端也可以注册用户请求处理器。此时，服务端就可以发起对客户端的调用，也可以使用 1.4 提到了任何一种通信模型。\n 示例1：使用 Connection 对象的双工通信，注意使用 Connection 对象的双工通信，服务端需要通过事件监听处理器或者用户请求处理器，自己保存好 Connection 对象。 示例2：使用 Address 的双工通信，注意使用 Address 方式的双工通信，需要在初始化 RpcServer 时，打开 manageConnection 开关，表示服务端会根据客户端发起的建连，维护一份地址与连接的映射关系。默认不需要双工通信的时候，这个功能是关闭的。 2.3 建立多连接与连接预热 通常来说，点对点的直连通信，客户端和服务端，一个 IP 一个连接对象就够用了。不管是吞吐能力还是并发度，都能满足一般业务的通信需求。而有一些场景，比如不是点对点直连通信，而是经过了 LVS VIP，或者 F5 设备的连接，此时，为了负载均衡和容错，会针对一个 URL 地址建立多个连接。我们提供如下方式来建立多连接，即发起调用时传入的 URL 增加如下参数 127.0.0.1:12200?_CONNECTIONNUM=30\u0026amp;amp;_CONNECTIONWARMUP=true，表示针对这个 IP 地址，需要建立30个连接，同时需要预热连接。其中预热与不预热的区别是：\n 预热：即第一次调用（比如 Sync 同步调用），就建立30个连接 不预热：每一次调用，创建一个连接，直到创建满30个连接 使用示例 2.4 自动断连与重连 通常 RPC 调用过程，是不需要断链与重连的。因为每次 RPC 调用过程，都会校验是否有可用连接，如果没有则新建一个。但有一些场景，是需要断链和保持长连接的：\n 自动断连：比如通过 LVS VIP 或者 F5 建立多个连接的场景，因为网络设备的负载均衡机制，有可能某一些连接固定映射到了某几台后端的 RS 上面，此时需要自动断连，然后重连，靠建连过程的随机性来实现最终负载均衡。注意，开启了自动断连的场景，通常需要配合重连使用。 重连：比如客户端发起建连后，由服务端来通过双工通信，发起请求到客户端。此时如果没有重连机制，则无法实现。 使用示例，注意考虑一个进程可能会有多个 SOFABolt 的通信实例，我们提供了全局开关以及用户开关两种开关方式： …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-handbook/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2a0a2e3c7749dbcdceea064f6f850e33","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","summary":"用户指南 maven coordinator \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; check release note for version 1. 基础功能 1.1 实现用户请求处理器 (UserProcessor) 我们提供了两种用户请求处理器，SyncUserProcessor 与 Async","tags":null,"title":"SOFABolt 用户手册","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","wordcount":3516},{"author":null,"categories":null,"content":" 相关链接 ISSUES 用户手册 中文介绍文章: 蚂蚁通信框架实践 ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/related-links/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6844d2a639b69fa3128132b8631f33e3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/related-links/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/related-links/","summary":"相关链接 ISSUES 用户手册 中文介绍文章: 蚂蚁通信框架实践","tags":null,"title":"SOFABolt 相关链接","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/related-links/","wordcount":24},{"author":null,"categories":null,"content":" # Upgrade SOFABoot from 2.3.x/2.4.x to 2.5.x SOFABoot 2.3.x/2.4.x is developed based on Spring Boot 1.4.2.RELEASE, SOFABoot 2.5.x is developed based on Spring Boot 1.5.x. When upgrading SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x, we should pay special attention to the differences between the Spring Boot 1.5.x upgrade and the Spring Boot 1.4.x upgrade.\nRenamed Spring Boot Starters spring-boot-starter-ws \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-data-redis Endpoint Security Control Spring Boot 1.5.x has security control over all sensitive endpoints by default, that is, endpoints such as /beans and /dump, which were previously accessible by default in version 1.4.x, are not accessible in version 1.5.x. To access such endpoints, we need to configure Spring Boot as follows: \u0026amp;gt; management.security.enabled=false\nOnly /health, /info, and /docs are accessible by default in version 1.5.x. Please refer to official description for details: + endpoints + Accessing sensitive endpoints\nApplicationEvent Change ApplicationStartedEvent in 1.4.x has been renamed ApplicationStartingEvent in Spring Boot 1.5.x. The version 1.5.x remains forward compatible. Note that the ApplicationStartedEvent event has a completely different meaning in version 2.x.\n** Users who have upgraded the SOFABoot to the version 2.5.x are strongly advised to change ApplicationStartedEvent to ApplicationStartingEvent to avoid compatibility issues when upgrading SOFABoot to the version 3.0.x in the future.**\nProperty renaming server.max-http-post-size \u0026amp;ndash;\u0026amp;gt; server.tomcat.max-http-post-size spring.data.neo4j.session.scope is removed Refer to the configuration of Spring Boot 1.5.x changelog\nSummary The above are the major points worthy of notice when we upgrade SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x. For detailed information, refer to the Release Report of Spring Boot 1.5.x.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_2_5_x/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4b7dd4287b00106684831d2a8524a6f7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","summary":"# Upgrade SOFABoot from 2.3.x/2.4.x to 2.5.x SOFABoot 2.3.x/2.4.x is developed based on Spring Boot 1.4.2.RELEASE, SOFABoot 2.5.x is developed based on Spring Boot 1.5.x. When upgrading SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x, we should pay special attention to the differences between the Spring Boot 1.5.x upgrade and the Spring Boot 1.4.x upgrade.\nRenamed Spring Boot Starters spring-boot-starter-ws \u0026ndash;\u0026gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026ndash;\u0026gt; spring-boot-starter-data-redis Endpoint Security Control Spring Boot 1.","tags":null,"title":"SOFABoot 2.5.x upgrade","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","wordcount":251},{"author":null,"categories":null,"content":" SOFABoot 2.3.x/2.4.x 升级到 2.5.x SOFABoot 2.3.x/2.4.x 基于 Spring Boot 1.4.2.RELEASE 版本开发，SOFABoot 2.5.x 则是基于 Spring Boot 1.5.x 版本开发。 从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 需要重点考虑 Spring Boot 1.5.x 相较 Spring Boot 1.4.x 的升级注意点。\n重命名的 spring boot starters spring-boot-starter-ws \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-data-redis endpoint 安全性控制 Spring Boot 1.5.x 对所有 Sensitive Endpoint 默认进行了安全管控，即之前在 1.4.x 默认能访问的诸如 /beans, /dump 等 endpoints 在 1.5.x 版本均不能访问。如果需要访问，需要配置： \u0026amp;gt; management.security.enabled=false\n默认情况下，在 1.5.x 只有 /health, /info, /docs 能够访问。详细请参考官方描述： + endpoints + Accessing sensitive endpoints\nApplicationEvent 变更 Spring Boot 1.5.x 将 1.4.x 中的 ApplicationStartedEvent 重命名为 ApplicationStartingEvent，在 1.5.x 仍然保持向前兼容。需要格外注意的是，在 2.x 版本中，ApplicationStartedEvent 事件意义完全不一样。\n强烈建议升级到 SOFABoot 2.5.x 的用户，将应用中使用的 ApplicationStartedEvent 变更为 ApplicationStartingEvent；避免今后升级至 SOFABoot 3.0.x 出现兼容性问题\nProperty 重命名 server.max-http-post-size \u0026amp;ndash;\u0026amp;gt; server.tomcat.max-http-post-size spring.data.neo4j.session.scope 被移除 具体参考 Spring Boot 1.5.x 配置的 changelog\n总结 以上总结了从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 的几个主要注意点，详细可以参考 Spring Boot 1.5.x 的发布报告\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_2_5_x/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4b7dd4287b00106684831d2a8524a6f7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","summary":"SOFABoot 2.3.x/2.4.x 升级到 2.5.x SOFABoot 2.3.x/2.4.x 基于 Spring Boot 1.4.2.RELEASE 版本开发，SOFABoot 2.5.x 则是基于 Spring Boot 1.5.x 版本开发。 从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 需要重点考虑 Spring Boot 1.5.x 相较 Spring Boot 1.4.x 的升级注意点。 重命","tags":null,"title":"SOFABoot 2.5.x 升级注意事项","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","wordcount":404},{"author":null,"categories":null,"content":" ## Preface As a Spring Boot-based development framework open sourced by Ant Financial, SOFABoot provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nWe have received a lot of feedback from community users since SOFABoot was open sourced in April 2018. We are also very pleased to see many community users take an active part in building the SOFAStack open source, which greatly increases our determination to prosper SOFAStack community and ecosystem. Here, we announce the release of the SOFABoot 3.0, which is developed based on Spring Boot 2.0. SOFABoot 3.0 allows us to seamlessly integrate the extension capability of SOFABoot with official components of Spring Boot 2.x. In addition, SOFABoot 3.0 is compatible with Spring Cloud components, which allows us to easily integrate Spring Cloud components like Zuul and Config in the SOFABoot framework.\nBelow are the major changes of SOFABoot 3.0 compared with SOFABoot 2.x.\nUpgrade Spring Boot to version 2.x Upgrade Spring Boot in SOFABoot 3.0 to version 2.0. As the Spring Boot community recently announced that the maintenance for version 1.x will end in August 2019, we will focus on SOFABoot 3.x in the future and will release SOFABoot 3.1 with Spring Boot upgraded to version 2.1 soon.\nSpring Cloud compatible Some components are not compatible with SOFABoot in SOFABoot 2.x. In SOFABoot 3.x, we have run thorough compatibility tests on Spring Cloud components and fixed all problems found to ensure good compatibility between SOFABoot 3.x and Spring Cloud.\nWebFlux framework compatible Spring Boot 2.x introduces the WebFlux framework. SOFABoot 3.x is compatible with WebFlux in two major aspects; + Health Check is compatible with the ReactiveHealthIndicator extension interface. The Readiness Check will include the implementation of the interface extension; + Compatible with buried points of WebFlux web requests. Point burying logs and files are compatible with common MVC requests. For detailed information, refer to MVC point burying request.\nJDK version support SOFABoot 3.x must run on JDK 8 or higher versions and does not support JDK 6 and JDK 7.\nHealth Check SOFABoot adds Readiness Check capability to Spring Boot\u0026amp;rsquo;s Health Check capability, to ensure that all components and operations are in a healthy state before the application goes into services. Compared with SOFABoot 2.x, SOFABoot 3.0 features great adjustments to the Health Check. It abandons some internal compatibility logic of Ant Financial and uses a friendlier coding scheme. Besides, the Health Check of SOFABoot 3.0 offers extensions in various scenarios, supports the \u0026amp;lsquo;ReactiveHealthIndicator\u0026amp;rsquo; extension interface introduced in Spring Boot 2.x, and provides more Health Check extension features.\nAdjust the Readiness Check Endpoint path The Endpoint for checking the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_3_x/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"91ba09adf6bc42aaf70645b9a19b409b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","summary":"## Preface As a Spring Boot-based development framework open sourced by Ant Financial, SOFABoot provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nWe have received a lot of feedback from community users since SOFABoot was open sourced in April 2018. We are also very pleased to see many community users take an active part in building the SOFAStack open source, which greatly increases our determination to prosper SOFAStack community and ecosystem.","tags":null,"title":"SOFABoot 3.0 upgrade","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","wordcount":910},{"author":null,"categories":null,"content":" 前言 SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n自今年 4 月份 SOFABoot 开源至今，我们收到了非常多来自社区同学的反馈，也非常高兴的看到很多社区同学积极的参与到 SOFAStack 开源共建，这极大了鼓舞了我们建设 SOFAStack 开源社区的决心，力图把 SOFAStack 社区和生态建设更加繁荣。在此，我们宣布推出 SOFABoot 3.0 版本，SOFABoot 3.0 是基于 Spring Boot 2.0 版本开发。在 SOFABoot 3.0 中，可以将 SOFABoot 扩展能力和 Spring Boot 2.x 官方组件无缝集成。此外，我们在 SOFABoot 3.0 中兼容了 Spring Cloud 组件集成，可以很方便地在 SOFABoot 框架中集成 Spring Cloud 组件，如 Zuul, Config 等。\n以下，本文将详细介绍 SOFABoot 3.0 相较 SOFABoot 2.x 的变更。\nSpring Boot 升级 2.x SOFABoot 3.0 版本升级 Spring Boot 版本至 2.0。鉴于Spring Boot 社区最近刚公告 1.x 版本将维护至明年 8 月份为止，未来，我们也将主力维护 SOFABoot 3.x 版本，近期也将发布 SOFABoot 3.1 升级 Spring Boot 版本至 2.1。\nSpring Cloud 兼容 在 SOFABoot 2.x 中，存在部分组件和 SOFABoot 兼容性问题。在 SOFABoot 3.x 中，对 Spring Cloud 各组件进行了比较完备的兼容性测试和问题修复，保证了 SOFABoot 3.x 与 Spring Cloud 良好的兼容性。\nWebFlux 框架兼容 Spring Boot 2.x 引入了 WebFlux 框架，SOFABoot 3.x 主要在两个方面兼容了 WebFlux 框架； + 健康检查兼容了 ReactiveHealthIndicator 扩展接口，业务对这个接口的扩展实现将会纳入到 Readiness Check； + 兼容对 WebFlux 网络请求进行埋点，埋点日志格式和文件保持对普通 MVC 请求兼容，详细参考MVC 埋点请求\nJDK 版本支持 SOFABoot 3.x 最低要求运行在 JDK 8 及其以上版本，不支持 JDK 6，7。\n健康检查 SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 能力，以确保应用在正常对外服务前，所有组件及业务本身处于健康状态。相较于与 SOFABoot 2.x, SOFABoot 3.0 在健康检查做了很大的重构，主要是剥离了部分蚂蚁金服内部兼容逻辑，采用更加友好的编码方案；其次，SOFABoot 3.0 健康检查提供了多种不同场景下的健康检查扩展形式，支持 Spring Boot 2.x 引入的 ReactiveHealthIndicator 扩展接口，丰富了健康检查扩展特性。\n调整 Readiness Check Endpoint 路径 在 SOFABoot 2.x 中，查看健康检查结果的 Endpoint 为 /health/readiness，而在 SOFABoot 3.0 中，变更为 /actuator/readiness。\n扩展接口变更 在 SOFABoot 3.x 中，提供四种方式扩展健康检查，分别是 + HealthChecker + HealthIndicator(Spring Boot 原生) + ReactiveHealthIndicator(Spring Boot 原生) + ReadinessCheckCallback\n这四个接口的扩展实现执行顺序是 HealthChecker \u0026amp;gt; HealthIndicator, ReactiveHealthIndicator \u0026amp;gt; ReadinessCheckCallback，相同接口的扩展实现执行顺序则遵循 Spring Boot 标准的方案。即扩展类可以额外实现两个标准的 Order 接口：\n org.springframework.core.Ordered org.springframework.core.PriorityOrdered 或者使用注解\n org.springframework.core.annotation.Order 这些接口的扩展实现处理结果将会在健康检查结果查中展现。\n删除 SofaBootBeforeHealthCheckEvent 事件 在 SOFABoot 2.x 中，我们没有提供支持对健康检查扩展实现进行排序，导致用户无法预期自身扩展执行时机。如上述，SOFABoot 3.x 支持各组件扩展实现的排序，因此该事件可以统一使用 HealthChecker 接口和高优先级顺序实现替代。其次，在 SOFABoot 2.x 中，SofaBootBeforeHealthCheckEvent 事件的处理逻辑结果并不会反应在健康检查结果中，使用 HealthChecker 替代之后，这部分逻辑处理自然变成健康检查的一部分，可供查看。\n删除 DefaultHealthChecker 接口 使用 JDK8 默认方法特性，删除 DefaultHealthChecker 接口，用户可以直接使用 HealthChecker 接口替代 DefaultHealthChecker.\n删除 SofaBootMiddlewareAfterReadinessCheckCallback 和 SofaBootAfterReadinessCheckCallback 接口 在 SOFABoot 2.x 中，这两个接口是两种场景下的健康检查回调；推荐 SOFABoot 官方 Starter 使用 SofaBootMiddlewareAfterReadinessCheckCallback，而业务应用推荐使用SofaBootAfterReadinessCheckCallback，框架将优先执行 SofaBootMiddlewareAfterReadinessCheckCallback 的扩展实现，然后执行 SofaBootAfterReadinessCheckCallback 的扩展实现。这样的设计有两个缺陷： + 两个接口本质没有区别，但是隐藏了先后顺序逻辑，给用户引入了额外的学习成本； + 只考虑了 SofaBootMiddlewareAfterReadinessCheckCallback 和 SofaBootAfterReadinessCheckCallback 两个接口的顺序，但无法保证相同接口实现的执行顺序。\nSOFABoot 3.x …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_3_x/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"91ba09adf6bc42aaf70645b9a19b409b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_3_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_3_x/","summary":"前言 SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFA","tags":null,"title":"SOFABoot 3.0 升级注意事项","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_3_x/","wordcount":1687},{"author":null,"categories":null,"content":" Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开发。\n二方库升级 SOFABoot 4.0 基于 Spring Boot 3.0 与 Spring Framework 6 构建。在 Spring Boot 3.0 与 Spring Framework 6 引入的二方库升级列表可参考文档👉 Spring Boot 3.0 Release Notes\n在 SOFABoot 4.0 引入的二方库升级列表如下：\n Spring Boot 3.0.7 Spring Cloud 4.0.0 Spring Cloud Stream 3.2.6 SOFA Common tools 2.0.0 SOFATracer 4.0.0 SOFARPC 5.10.0 FastJson 1.2.83 Guava 31.1-jre Grpc 1.51.1 Grpc common protos 2.11.0 Druid 1.2.16 ASM 9.4 Javassist 3.29.2-GA Curator 4.3.0 Dubbo 3.1.8 Nacos 2.0.3 Swagger 1.6.7 Swagger2 2.2.8 基于 Jakarta EE Spring Boot 3.0 中依赖 Jakarta EE 规范的部分已经升级到了 Jakarta EE 10 版本。例如，使用 Servlet 6.0 和 JPA 3.1 规范。因此，部分包的命名空间也进行了替换，例如你应该使用：\n✅jakarta.servlet.Filter\n而不是 javax.servlet.Filter。\n同时，如果你使用了自己的依赖提供 Jakarta EE 规范的 API，需注意进行对应的依赖升级，例如你应该使用：\n✅jakarta.servlet:jakarta.servlet-api\n而不是 javax.servlet:javax.servlet-api。\n可参考文档：Migrate to Jakarta EE 9 来修改 Jakarta 相关的包名以及依赖。\n支持 SOFAArk 2.0 SOFAArk 2.0 模式是 SOFAArk 框架的整体优化版本，相较于 SOFAArk 1.0 模式，它的整体优化思路和原则是 Ark Master Biz 保持和原生 SOFABoot 保持一致，弱化复杂的 Ark Plugin 类管控机制，将 Ark Plugin 与 Master Biz 合并。使得 Ark Master Biz 和原生 SOFABoot 应用的启动方式、类加载方式保持一致，大大降低了 Master Biz 应用的编程难度。\nSOFABoot 4.0 版本不再支持 SOFAArk 1.0 模式，如果你想要在 SOFABoot 应用中使用 SOFAArk 2.0 模式，可以按照以下步骤进行操作：\n1、在项目中引入 SOFAArk 组件依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;ark-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2、添加 Spring Boot 的 Package 插件\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 3、启动应用\n 方式一： IDEA 启动，注意需要添加启动参数：-Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二： 命令行启动，先运行 mvn clean package 命令进行打包，生成 ${bizName}-${bizVersion}-ark-biz.jar 的可执行文件，然后在终端运行以下启动参数：\njava -jar -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName} ${bizName}-${bizVersion}-ark-biz.jar\n支持场景化的按配置加载能力 通常情况下，应用在不同的场景下可能需要开启或者关闭不同的功能，Spring Boot 提供了丰富的 Configuration 动态配置能力[4] 能力以支持应用在不同的场景下加载不同的 Bean。\nSOFABoot 在此基础上，对 org.springframework.context.ApplicationContextInitializer 等扩展点进行了增强，支持通过统一风格的配置定制各类 Bean 以及扩展点的开启与关闭，并提供了定制模版配置的开启方式以降低应用配置项的复杂度。\n 通过： com.alipay.sofa.boot.autoconfigure.condition.ConditionalOnSwitch 注解为 Bean 添加按配置开启能力：\n@Configuration(proxyBeanMethods = false) @ConditionalOnSwitch(id=\u0026amp;quot;sample\u0026amp;quot;) public class SampleConfiguration { @Bean public SampleBean sampleBean() { return new SampleBean(); } } 添加：\nsofa.boot.switch.bean.sample.enabled=false 配置后，SampleConfiguration 配置类将不再加载。\n 通过继承： …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_4_x/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5c33e340d1a0200b2dac6aa548142849","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_4_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_4_x/","summary":"Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开","tags":null,"title":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_4_x/","wordcount":3757},{"author":null,"categories":null,"content":" SOFABoot supports modular isolation. But in actual usage scenarios, There is one case that beans in one module sometimes need to open some entries for another module to expand. SOFABoot draws on and uses the Nuxeo Runtime project and the nuxeo project and expands on it, provides the ability to extend points with Spring, We call it Extension Point.\nUsage Using extension point capabilities in SOFABoot requires the following three steps:\nDefine a bean that provides extension capabilities When using the SOFABoot extension point capability, you first need to define an interface that needs to be extended, like:\npackage com.alipay.sofa.boot.test; public interface IExtension { String say(); } Define the implementation of this interface:\npackage com.alipay.sofa.boot.test.impl; public class ExtensionImpl implements IExtension { private String word; @Override public String say() { return word; } public void setWord(String word) { this.word = word; } public void registerExtension(Extension extension) throws Exception { Object[] contributions = extension.getContributions(); String extensionPoint = extension.getExtensionPoint(); if (contributions == null) { return; } for (Object contribution : contributions) { if (\u0026amp;quot;word\u0026amp;quot;.equals(extensionPoint)) { setWord(((ExtensionDescriptor) contribution).getValue()); } } } } Here you can see that there is a method: registerExtension, you can temporarily ignore this method, and later will introduce its specific role.\nIn the module\u0026amp;rsquo;s Spring configuration file, we add configuration of this bean:\n\u0026amp;lt;bean id=\u0026amp;quot;extension\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.test.impl.ExtensionImpl\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;word\u0026amp;quot; value=\u0026amp;quot;Hello, world\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; Defining extension points There is a field word in the above bean. In practice, we want this field to be overridden by other module customizations. Here we expose it as an extension point.\nFirst, you need a class to describe this extension point:\n@XObject(\u0026amp;quot;word\u0026amp;quot;) public class ExtensionDescriptor { @XNode(\u0026amp;quot;value\u0026amp;quot;) private String value; public String getValue() { return value; } } Then define the extension point in xml:\n\u0026amp;lt;sofa:extension-point name=\u0026amp;quot;word\u0026amp;quot; ref=\u0026amp;quot;extension\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:object class=\u0026amp;quot;com.alipay.sofa.boot.test.extension.ExtensionDescriptor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:extension-point\u0026amp;gt; among them: - name is the name of the extension point - ref is the bean to which the extension point is applied - object is a concrete description of the contribution point of the extension point. This description is done by XMap (XMap is used to map Java objects and XML files. It is recommended to search XMap documents on the Internet to understand XMap)\nDefining extension implements The above has defined the extension point, and we can extend this bean at this point:\n\u0026amp;lt;sofa:extension bean=\u0026amp;quot;extension\u0026amp;quot; point=\u0026amp;quot;word\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:content\u0026amp;gt; \u0026amp;lt;word\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/extension/","fuzzywordcount":1300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"93225b6c1f2b68f2047a7cf49b76650b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/extension/","summary":"SOFABoot supports modular isolation. But in actual usage scenarios, There is one case that beans in one module sometimes need to open some entries for another module to expand. SOFABoot draws on and uses the Nuxeo Runtime project and the nuxeo project and expands on it, provides the ability to extend points with Spring, We call it Extension Point. Usage Using extension point capabilities in SOFABoot requires the following three","tags":null,"title":"SOFABoot Extension Point","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/extension/","wordcount":1279},{"author":null,"categories":null,"content":" Spring 框架从 3.1.X 版本开始提供了 profile 功能: Bean Definition Profiles，SOFABoot 支持模块级 profile 能力，即在各个模块启动的时候决定模块是否能够启动。\n使用 Module-Profile 激活 module 使用 SOFABoot 的 profile 功能，需要在 application.properties 文件增加 com.alipay.sofa.boot.active-profiles 字段，该字段的值为逗号分隔的字符串，表示允许激活的 profile 列表，指定该字段后，SOFABoot 会为每个可以激活的模块指定此字段表示的 profile 列表。\nSOFABoot 模块的 sofa-module.properties 文件支持 Module-Profile 字段，该字段的值为逗号分隔的字符串，表示当前模块允许在哪些 profile 激活。Module-Profile 支持取反操作， !dev 表示 com.alipay.sofa.boot.active-profiles 不包含 dev 时被激活。\n当应用未指定 com.alipay.sofa.boot.active-profiles 参数时，表示应用所有模块均可启动。SOFABoot 模块未指定 Module-Profile 时，表示当前 SOFABoot 模块可以在任何 profile 启动。\n使用例子 激活 dev SOFABoot 模块 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev 该配置表示激活 profile 为 dev 的模块。\n在每个需要限定为 dev profile 被激活模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=dev 配置多个激活 profile application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev,test 该配置表示激活 profile 为 dev 或者 test 的模块。\n在 SOFABoot 模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=test,product 该配置表示当 com.alipay.sofa.boot.active-profiles 包含 test 或者 product 时激活模块，由于当前指定的 com.alipay.sofa.boot.active-profiles 为 dev,test ，此模块将被激活。\nModule-Profile 取反 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev 该配置表示激活 profile 为 dev 的模块。\n在 SOFABoot 模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=!product 该配置表示当 com.alipay.sofa.boot.active-profiles 不包含 product 时激活模块，由于当前指定的 com.alipay.sofa.boot.active-profiles 为 dev ，此模块将被激活。\n设置激活模块 Spring 上下文的 spring.profiles.active 属性 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev,test 该配置表示激活 profile 为 dev 或者 test 的模块，当一个模块满足上面的激活条件时，这个模块就会被启动，同时 Spring 上下文的环境信息 spring.profiles.active 也被设置为了 dev,test ，这样如下的配置 beanId 为 devBeanId 和 testBeanId 的bean都会被激活。\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:jdbc=\u0026amp;quot;http://www.springframework.org/schema/jdbc\u0026amp;quot; xmlns:jee=\u0026amp;quot;http://www.springframework.org/schema/jee\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.2.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;beans profile=\u0026amp;quot;dev\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;devBeanId\u0026amp;quot; class=\u0026amp;quot;com.alipay.cloudenginetest.sofaprofilesenv.DemoBean\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;name\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;demoBeanDev\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/property\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; \u0026amp;lt;beans profile=\u0026amp;quot;test\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBeanId\u0026amp;quot; class=\u0026amp;quot;com.alipay.cloudenginetest.sofaprofilesenv.DemoBean\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;name\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;demoBeanTest\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/property\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-profile/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b29d568fa057cad0b440790d5cc65d07","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-profile/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-profile/","summary":"Spring 框架从 3.1.X 版本开始提供了 profile 功能: Bean Definition Profiles，SOFABoot 支持模块级 profile 能力，即在各个模块启动的时候决定模块是否能够启动。 使用 Module-Profile 激","tags":null,"title":"SOFABoot Profile","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-profile/","wordcount":666},{"author":null,"categories":null,"content":" Background kc-sofastack-demo has introduced how to quickly build an e-commerce microservice application and has implemented the service calling link tracking and application status monitoring.\nIn e-commerce system, the platforms often are not satisfied with the default product listing order, and always want to arrange some products in the conspicuous places. Also, there are some cases where the platforms would like to show different products to different users based on the collected user behaviors.\nBased on the background of kc-sofastack-demo, this guide will implement sorting the products dynamically based on the total amount of products of each onsite attendee.\nDemo content Implement the dynamic change of product sorting via the dynamic module capability provided by SOFABoot and the dynamic module control capability of SOFADashboard.\nImplement the change of application behavior without restarting the host and without changing the application configuration.\nThe project architecture is as follows:\nTasks 1. Preparation Clone the demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-dynamic-demo.git Then, import the project into IDEA or Eclipse.\n2. Package SOFABoot project as Ark JAR As shown in the following screenshot, add the Ark package plugin in the POM file and configure it:\nStep 1: Copy the Ark plugin and configuration to the specified positions in the above screenshot \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!-- package configuration of ark-biz JAR --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Whether to package, install and publish ark biz. The default value is false. For details, see Ark Biz documentation.--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!-- The directory for ark package and ark biz package, defaulting to the build directory of project--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- The priority of starting ark-biz package. The smaller the value, the higher the priority.--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;200\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--Set the root directory of application, used to read ${base.dir}/conf/ark/bootstrap.application configuration file and defaulting to ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;../\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Step 2: Run mvn clean package to package the project. The successfully packaged JAR file is as shown in the following screenshot:\n3. Build host application In the downloaded project, dynamic-stock-mng is the host application model. In this task, we will build dynamic-stock-mng as the host application of dynamic module.\nStep 1: Introduce Ark …","date":-62135596800,"description":"This guide introduce how to implement the merged deployment and dynmaic module push provided by SOFAArck based on the Ark control function of SOFADashboard.","dir":"guides/kc-sofastack-dynamic-demo/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"8bfd4a50e21ce9fc867b1cf18a8c9af3","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","summary":"Background kc-sofastack-demo has introduced how to quickly build an e-commerce microservice application and has implemented the service calling link tracking and application status monitoring.\nIn e-commerce system, the platforms often are not satisfied with the default product listing order, and always want to arrange some products in the conspicuous places. Also, there are some cases where the platforms would like to show different products to different users based on the collected user behaviors.","tags":null,"title":"SOFABoot dynamic module practice","type":"guides","url":"/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","wordcount":630},{"author":null,"categories":null,"content":" SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nYou can view all the release notes in Release History. The correspondence between SOFABoot version and Spring Boot version is as follows:\n SOFABoot version Spring Boot version 2.3.x 1.4.2.RELEASE 2.4.x 1.4.2.RELEASE 2.5.x 1.5.16.RELEASE 3.0.x 2.0.3.RELEASE 3.1.0 2.1.0.RELEASE That is, the SOFABoot 2.3.x and 2.4.x series are based on Spring Boot 1.4.2.RELEASE; SOFABoot 2.5.x series are based on Spring Boot 1.5.x; SOFABoot 3.x series are based on Spring Boot 2.x. You can view and get the codes of all revisions in Release History. In addition, to facilitate users in the community to learn the latest development version of SOFABoot, we will release the SNAPSHOT version, which is a branch of the current development. To successfully pull the SNAPSHOT package from the central repository, it\u0026amp;rsquo;s necessary to add the following profile configuration to the local maven setting.xml file:\n\u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; Feature Description Based on Spring Boot, SOFABoot provides the following capabilities:\n Capability of expanding the Health Check of Spring Boot: Provide the Readiness Check based on the Health Check of Spring Boot, to ensure a secure launch of application examples. Capability of log space isolation: The middleware framework automatically finds the application\u0026amp;rsquo;s logs and realizes dependence on the logs and independent log printing, avoiding binding the middleware and the application logs. The capability is achieved through sofa-common-tools. Capability of providing class isolation: Provide class isolation based on the SOFAArk framework, making it easy for users to solve various class conflicts. Capability of providing modular development: Based on the Spring context isolation, provide modular development capability, with a separate Spring context for each SOFABoot module, to avoid BeanId conflicts between different SOFABoot modules. Integrated management of middleware: manage in a unified manner, provide a unified and easy-to-use …","date":-62135596800,"description":"","dir":"projects/sofa-boot/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fe6aed461c61b86dfed846a2dc0b7dcb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/overview/","summary":"SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nYou can view all the release notes in Release History. The correspondence between SOFABoot version and Spring Boot version is as follows:","tags":null,"title":"SOFABoot overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/overview/","wordcount":461},{"author":null,"categories":null,"content":" Since 3.1.X Spring framework has started to support the profile function: Bean Definition Profiles, SOFABoot support modular-level profiling, it will determine whether a module can be started when each module is getting started.\nActivating Module Using Module-Profile To enable the SOFABoot profiling, we need to add the com.alipay.sofa.boot.active-profiles field in the application.properties file. The value of this field is a comma-separated string denoting a list of profiles allowed to be activated. After specifying it, SOFABoot will specify a profile list represented by the field for each module that can be activated.\nThe sofa-module.properties file of the SOFABoot module supports the Module-Profile field, which points to a comma-separated string of values representing which profiles are allowed to be activated. Module-Profile supports the inversion operation, !dev indicates that com.alipay.sofa.boot.active-profiles is activated when it does not contain dev.\nIf the value of the com.alipay.sofa.boot.active-profiles field is not specified in the application, all modules are allowed to be started. If the Module-Profile is not specified in the SOFABoot module, the current SOFABoot module can be started with any profile.\nExample Activating the dev SOFABoot Module Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev With this configuration, the module with dev profile will be activated.\nAdd the following configuration to each sofa-module.properties file where modules with dev profile need to be activated.\nModule-Profile=dev Configuring Multiple Activation Profiles Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev,test With this configuration, the modules with dev or test profile will be activated.\nAdd the following configuration to the SOFABoot\u0026amp;rsquo;s sofa-module.properties file:\nModule-Profile=test,product With this configuration, the module will be activated when the com.alipay.sofa.boot.active-profiles contains test or product. Since the com.alipay.sofa.boot.active-profiles is specified as dev and test, this module will be activated.\nThe Inverted Module-Profile Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev With this configuration, the module with dev profile will be activated.\nAdd the following configuration to the SOFABoot\u0026amp;rsquo;s sofa-module.properties file:\nModule-Profile=!product This will activate the module when the com.alipay.sofa.boot.active-profiles does not contain product. Since it is specified as dev, this module will be activated.\nSet the spring.profiles.active property that is used to activate the Spring context of the module. Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev,test With this configuration, the modules with dev or test profile will be activated. If a module meets those …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-profile/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b29d568fa057cad0b440790d5cc65d07","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","summary":"Since 3.1.X Spring framework has started to support the profile function: Bean Definition Profiles, SOFABoot support modular-level profiling, it will determine whether a module can be started when each module is getting started.\nActivating Module Using Module-Profile To enable the SOFABoot profiling, we need to add the com.alipay.sofa.boot.active-profiles field in the application.properties file. The value of this field is a comma-separated string denoting a list of profiles allowed to be activated.","tags":null,"title":"SOFABoot profile","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","wordcount":450},{"author":null,"categories":null,"content":" SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n你可以在发布历史中查看所有的发布报告，SOFABoot 版本和 Spring Boot 版本对应关系如下：\n SOFABoot 版本 Spring Boot 版本 3.3.0～3.3.1 2.1.11.RELEASE 3.3.2～3.6.0 2.1.13.RELEASE 3.7.0～3.10.0 2.3.9.RELEASE 3.11.0～3.11.1 2.3.12.RELEASE 3.12.0～3.13.0 2.4.13 3.14.0～3.14.1 2.6.9 3.15.0～3.16.3 2.7.3 3.17.0 2.7.8 3.18.0～3.19.1 2.7.10 4.0.0 ～ 4.0.2 3.0.7 4.1.0 3.1.5 4.2.0 3.2.2 4.3.0 3.2.6 SOFABoot 3.x 系列版本将构建在 Spring Boot 2.x 基础之上，SOFABoot 4.x 系列版本将构建在 Spring Boot 3.x 基础之上 。你可以在发布历史中查看获取所有的历史版本代码。另外为了方便社区同学能够基于最新开发版本的 SOFABoot 进行开发学习，我们会发布当前开发分支的 SNAPSHOT 版本。为顺利从中央仓库拉取 SNAPSHOT 包，需要在本地 maven setting.xml 文件增加如下 profile 配置:\n\u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; 目前 SOFABoot 最新版本为 4.0.0，基于 Spring Boot 3.0.7, 支持 JDK17。\n功能描述 SOFABoot 在 Spring Boot 基础上，提供了以下能力：\n 扩展 Spring Boot 健康检查的能力：在 Spring Boot 健康检查能力基础上，提供了 Readiness Check 的能力，保证应用实例安全上线。 提供模块化开发的能力：基于 Spring 上下文隔离提供模块化开发能力，每个 SOFABoot 模块使用独立的 Spring 上下文，避免不同 SOFABoot 模块间的 BeanId 冲突。 增加模块并行加载和 Spring Bean 异步初始化能力，加速应用启动； 增加日志空间隔离的能力：中间件框架自动发现应用的日志实现依赖并独立打印日志，避免中间件和应用日志实现绑定，通过 sofa-common-tools 实现。 增加类隔离的能力：基于 SOFAArk 框架提供类隔离能力，方便使用者解决各种类冲突问题。 增加中间件集成管理的能力：统一管控、提供中间件统一易用的编程接口、每一个 SOFA 中间件都是独立可插拔的组件。 提供完全兼容 Spring Boot的能力：SOFABoot 基于 Spring Boot 的基础上进行构建，并且完全兼容 Spring Boot。 应用场景 SOFABoot 本身就脱胎于蚂蚁金服内部对于 Spring Boot 的实践，补充了 Spring Boot 在大规模金融级生产场景下一些不足的地方，所以 SOFABoot 特别适合于这样的场景。\n当然，SOFABoot 的每个组件都是可选的，用户可以灵活选择其中的功能来使用，比如如果仅仅想在 Spring Boot 下面引入 SOFA 中间件，可以不需引入 SOFABoot 中的类隔离能力。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/overview/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fe6aed461c61b86dfed846a2dc0b7dcb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/overview/","summary":"SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABo","tags":null,"title":"SOFABoot 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-boot/overview/","wordcount":938},{"author":null,"categories":null,"content":" SOFABoot 提供了类隔离框架 SOFAArk, 弥补了 Spring Boot 在类隔离能力上的缺失，用以解决在实际开发中常见的类冲突、包冲突问题，详细请参考 SOFAArk。\n在 SOFABoot 工程中使用类隔离能力，只需两步操作；配置 sofa-ark-maven-plugin 打包插件以及引入 sofa-ark-springboot-starter 类隔离框架依赖；\n配置 Maven 打包插件 官方提供了 Maven 插件 - sofa-ark-maven-plugin ，只需要简单的配置项，即可将 SpringBoot 工程打包成标准格式规范的可执行 Ark 包，插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 配置模板如下：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- all class exported by ark plugin would be resolved by ark biz in default, if configure denyImportClasses, then it would prefer to load them by ark biz itself --\u0026amp;gt; \u0026amp;lt;denyImportClasses\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass1\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass2\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/denyImportClasses\u0026amp;gt; \u0026amp;lt;!-- Corresponding to denyImportClasses, denyImportPackages is package-level --\u0026amp;gt; \u0026amp;lt;denyImportPackages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/denyImportPackages\u0026amp;gt; \u0026amp;lt;!-- denyImportResources can prevent resource exported by ark plugin with accurate name to be resolved --\u0026amp;gt; \u0026amp;lt;denyImportResources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test1.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test2.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;/denyImportResources\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 插件配置项解释：\n outputDirectory: 执行 mvn package 命令后，指定打出来的 ark 包存放目录，默认存放至 ${project.build.directory} arkClassifier: 执行 mvn depleoy 命令后，指定发布到仓库的 ark 包的maven坐标的 classifer 值, 默认为空；我们推荐配置此配置项用于和普通的 Fat Jar 加以名字上区别； denyImportClasses: 默认情况下，应用会优先加载 ark plugin 导出的类，使用该配置项，可以禁止应用从 ark plugin 加载其导出类； denyImportPackages: 对应上述的 denyImportClasses, 提供包级别的禁止导入； denyImportResources: 默认情况下，应用会优先加载 ark plugin 导出的资源，使用该配置项，可以禁止应用从 ark plugin 加载其导出资源； 添加类隔离框架依赖 在实际开发中，为了在跑测试用例时使用 SOFABoot 类隔离能力，需要在 SOFABoot 工程中添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 根据 SpringBoot 依赖即服务的原则，添加该依赖之后，应用启动之前，会优先启动 SOFABoot 类隔离容器；\nSOFABoot 的类隔离框架会自动检测应用中是否有引入 Ark Plugin（即需要被隔离的jar包，详情请参考 SOFAArk）, 并隔离加载；例如为了避免 SOFABoot 官方提供的 SOFARPC 组件和应用产生依赖冲突，SOFABoot提供了 SOFARPC 组件对应的 ark plugin 版，用户如果需要隔离 SOFARPC，只需要添加如下组件：\n\u0026amp;lt;dependency\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/classloader-isolation/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e007416ab008c1dd4b886433dbf8af01","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/classloader-isolation/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/classloader-isolation/","summary":"SOFABoot 提供了类隔离框架 SOFAArk, 弥补了 Spring Boot 在类隔离能力上的缺失，用以解决在实际开发中常见的类冲突、包冲突问题，详细请参考 SOFAArk。 在 SOFABoot 工程中使用类","tags":null,"title":"SOFABoot 使用类隔离","type":"projects","url":"/sofastack.tech/projects/sofa-boot/classloader-isolation/","wordcount":1667},{"author":null,"categories":null,"content":" SOFABoot 动态模块实践 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n 实验背景 实验内容 任务 任务准备 将 SOFABoot 应用打包成 ark 包 修改动态模块名称 配置动态模块的打包插件 构建宿主应用 引入动态模块依赖 宿主应用配置 打包 \u0026amp;amp; 启动宿主应用 SOFADashboard 添加版本\u0026amp;amp;管理应用 查看详情 \u0026amp;amp; 推送安装命令 实验背景 kc-sofastack-demo 分享中已经通过 SOFAStack 快速构建了一个电商微服务应用， 并且完成了对应用服务调用链路的跟踪及应用状态的监控。\n在电商系统中，平台方往往不会满足商品的自然排序展示，必定会根据某种规则来将部分商品放置在列表最瞩目的地方， 当然也可能是平台方通过收集用户行为动态的为每个不同的用户推荐不同的商品展示列表。\n本实验背景就是基于kc-sofastack-demo的基础上， 根据现场同学对每个商品的购买总数（通过订单统计）来对商品列表进行动态排序。\n实验内容 通过 SOFABoot 提供的动态模块能力及 SOFADashboard 的动态模块管控能力，实现商品列表排序策略的动态变更。通过在不重启宿主机，不更改应用配置的情况下实现 应用行为的改变。\n 项目工程架构图如下 任务 1、任务准备 从 github 上将 demo 工程克隆到本地\ngit clone https://github.com/sofastack-guides/kc-sofastack-dynamic-demo.git 然后将工程导入到 IDEA 或者 eclipse。\n2、将 SOFABoot 应用打包成 ark 包 step1 : 修改动态模块名称 在实际的应用场景中，不需要对其进行任何修改\n 如下图所示，对 dynamic-module/pom.xml 中的 artifactId 进行修改，将 {your-number} 修改为当前座位上的编号\nstep2 : 配置动态模块的打包插件 在 dynamic-provider/pom.xml 中，增加 ark 打包插件，并进行配置：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!--ark-biz 包的打包配置 --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- ark-biz 包的启动优先级，值越小，优先级越高--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;200\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--设置应用的根目录，用于读取 ${base.dir}/conf/ark/bootstrap.application 配置文件，默认为 ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;../\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 3、构建宿主应用 在已下载下来的工程中，dynamic-stock-mng 作为实验的宿主应用工程模型。通过此任务，将 dynamic-stock-mng 构建成为动态模块的宿主应用。\nstep1 : 引入动态模块依赖 动态模块是通过 SOFAArk 组件来实现的，因此次数需要引入 SOFAArk 相关的依赖即可。关于 SOFAArk 可以参考SOFABoot 类隔离 一节进行了解。\n SOFAArk 相关依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;web-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;config-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.sofastack\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dynamic-provider-{your-number}\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 将此配置文件中的 {your-number} 替换为当前座位编号\n 宿主应用打包插件 \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; …","date":-62135596800,"description":"本指南将基于 SOFADashboard 的 ARK 管控能力来实现 SOFAArk 提供的合并部署和动态模块推送的功能。","dir":"guides/kc-sofastack-dynamic-demo/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8bfd4a50e21ce9fc867b1cf18a8c9af3","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-sofastack-dynamic-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/guides/kc-sofastack-dynamic-demo/","summary":"SOFABoot 动态模块实践 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 实验背景 实验内容 任务 任务准备 将 SOFABoot 应用打包成 ark 包 修改动态模","tags":null,"title":"SOFABoot 动态模块实践","type":"guides","url":"/sofastack.tech/guides/kc-sofastack-dynamic-demo/","wordcount":2025},{"author":null,"categories":null,"content":" SOFABoot 支持模块化隔离，在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项目，并在上面扩展，与 Spring 融合，提供扩展点的能力。\n使用 在 SOFABoot 中使用扩展点能力，需要以下三个步骤：\n定义提供扩展能力的 bean 在使用 SOFABoot 扩展点能力时，首先需要定一个需要被扩展的 bean，先定一个接口：\npackage com.alipay.sofa.boot.test; public interface IExtension { String say(); } 定义这个接口的实现：\npackage com.alipay.sofa.boot.test.impl; public class ExtensionImpl implements IExtension { private String word; @Override public String say() { return word; } public void setWord(String word) { this.word = word; } public void registerExtension(Extension extension) throws Exception { Object[] contributions = extension.getContributions(); String extensionPoint = extension.getExtensionPoint(); if (contributions == null) { return; } for (Object contribution : contributions) { if (\u0026amp;quot;word\u0026amp;quot;.equals(extensionPoint)) { setWord(((ExtensionDescriptor) contribution).getValue()); } } } } 在这里可以看到有一个方法：registerExtension ，暂时可以先不用管这个方法，后续会介绍其具体的作用。\n在模块的 Spring 配置文件中，我们把这个 bean 给配置起来：\n\u0026amp;lt;bean id=\u0026amp;quot;extension\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.test.impl.ExtensionImpl\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;word\u0026amp;quot; value=\u0026amp;quot;Hello, world\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; 定义扩展点 在上面的 bean 中有一个字段 word ，在实际中，我们希望这个字段能够被其他的模块自定义进行覆盖，这里我们将其以扩展点的形式暴露出来。\n首先需要一个类去描述这个扩展点：\n@XObject(\u0026amp;quot;word\u0026amp;quot;) public class ExtensionDescriptor { @XNode(\u0026amp;quot;value\u0026amp;quot;) private String value; public String getValue() { return value; } } 然后在 xml 中定义扩展点：\n\u0026amp;lt;sofa:extension-point name=\u0026amp;quot;word\u0026amp;quot; ref=\u0026amp;quot;extension\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:object class=\u0026amp;quot;com.alipay.sofa.boot.test.extension.ExtensionDescriptor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:extension-point\u0026amp;gt; 其中： - name 为扩展点的名字 - ref 为扩展点所作用在的 bean - object 为扩展点的贡献点具体的描述，这个描述是通过 XMap 的方式来进行的(XMap 的作用是将 Java 对象和 XML 文件进行映射，这里建议通过在网上搜索下 XMap 的文档来了解 XMap)\n定义扩展 上述已经将扩展点定义好了，此时我们就可以对这个 bean 进行扩展了:\n\u0026amp;lt;sofa:extension bean=\u0026amp;quot;extension\u0026amp;quot; point=\u0026amp;quot;word\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:content\u0026amp;gt; \u0026amp;lt;word\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;newValue\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/word\u0026amp;gt; \u0026amp;lt;/sofa:content\u0026amp;gt; \u0026amp;lt;/sofa:extension\u0026amp;gt; 其中： - bean 为扩展所作用在的 bean - point 为扩展点的名字 - content 里面的内容为扩展的定义，其会通过 XMap 将内容解析为：扩展点的贡献点具体的描述对象，在这里即为 com.alipay.sofa.boot.test.extension.ExtensionDescriptor 对象\n到这里，我们可以回头看一开始在 com.alipay.sofa.boot.test.impl.ExtensionImpl 中定义的 registerExtension 方法了，SOFABoot 在解析到贡献点时，会调用被扩展 bean 的 registerExtension 方法，其中包含了用户定义的贡献点处理逻辑，在上述的例子中，获取用户定义的 value 值，并将其设置到 word 字段中覆盖 bean 中原始定义的值。\n此时，调用 extension bean 的 say() 方法，可以看到返回扩展中定义的值: newValue 。\nXMap 支持和扩展 上述的例子中只是一个很简单的扩展，其实 XMap 包含了非常丰富的描述能力，包括 List, Map 等，这些可以通过查看 XMap 的文档来了解。\n在 SOFABoot 中，除了 XMap 原生的支持以外，还扩展了跟 Spring 集成的能力： - 通过 XNode 扩展出了 XNodeSpring - 通过 XNodeList 扩展出了 XNodeListSpring - 通过 XNodeMap 扩展出了 XNodeMapSpring\n这部分的扩展能力，让扩展点的能力更加丰富，描述对象中可以直接指向一个 SpringBean(用户配置 bean 的名字，SOFABoot 会根据名字从 spring 上下文中获取到 bean)，这里举一个使用 XNodeListSpring 的例子，依然是上述描述的三个步骤：\n定义提供扩展能力的 bean 接口定义：\n在这个接口里，返回一个 list，目标是这个 list 能够被通过扩展的方式填充\npackage com.alipay.sofa.boot.test; public interface IExtension { …","date":-62135596800,"description":"","dir":"projects/sofa-boot/extension/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"93225b6c1f2b68f2047a7cf49b76650b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/extension/","summary":"SOFABoot 支持模块化隔离，在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项","tags":null,"title":"SOFABoot 拓展点","type":"projects","url":"/sofastack.tech/projects/sofa-boot/extension/","wordcount":1959},{"author":null,"categories":null,"content":" 本文档将演示了如何在 SOFABoot 环境下应用 SOFARPC 进行服务的发布和引用。 您可以直接在工程下找到本文档的示例代码。注意，示例代码中需要本地安装 zookeeper 环境，如果没有安装。需要将application.properties中的com.alipay.sofa.rpc.registry.address 配置注释掉，走本地文件注册中心的方式。\n创建工程 环境准备：SOFABoot 需要 JDK7 或者 JDK8 ，需要采用 Apache Maven 2.2.5 或者以上的版本来编译。 工程构建：SOFABoot 构建在 Spring Boot 之上。因此可以使用 Spring\u0026amp;nbsp;Boot\u0026amp;nbsp;的工程生成工具来生成一个标准的Spring Boot 工程。 引入 SOFABoot 环境：生成的 Spring Boot 标准工程直接使用的 Spring Boot 的 parent 依赖，改为 SOFABoot 提供的 parent 依赖，该parent 提供并管控了多种 SOFABoot 提供的 starter。 \u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa-boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa-boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n 配置 application.properties ：application.properties 是 SOFABoot 工程中的配置文件。这里需要配置一个必不可少的配置项，即应用名。 spring.application.name=AppName 引入 RPC Starter： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 定义服务接口 public interface AnnotationService { String sayAnnotation(String string); } 服务端发布服务 通过 @SofaService注解发布服务，如下代码所示：\nSOFABoot 扫描到该注解，就会将该服务实现发布到服务器，同时指定了 bolt 协议与客户端进行通信地址，并将地址等元数据发布到了注册中心（这里默认使用的本地文件作为注册中心）。\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } 客户端引用服务 通过@SofaReference注解引用服务，如下代码所示： SOFABoot 会生成一个 AnnotationService RPC 的代理 bean，同时指定了 bolt 协议与服务端通信。这样就可以直接在代码中使用该 bean 进行远程服务的调用了。\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } 运行 在 SpringBoot 的启动类中编码如下： 启动服务端\n@SpringBootApplication public class AnnotationServerApplication { public static void main(String[] args) { SpringApplication springApplication = new SpringApplication( AnnotationServerApplication.class); ApplicationContext applicationContext = springApplication.run(args); } } 启动客户端，获取AnnotationClientImpl的实现 bean，并调用 sayClientAnnotation，间接通过@SofaReference生成的代理类调用远程服务 AnnotationServiceImpl。\npublic class …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-sofa-boot/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0dd5e0e5116473aee630cba38679d493","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","summary":"本文档将演示了如何在 SOFABoot 环境下应用 SOFARPC 进行服务的发布和引用。 您可以直接在工程下找到本文档的示例代码。注意，示例代码中需要本地安装 zookeeper 环境，如果没有","tags":null,"title":"SOFABoot 方式快速入门","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","wordcount":990},{"author":null,"categories":null,"content":"声明 SOFABoot 的 xsd 文件：在要使用的 XML 配置文件中将头部 xsd 文件的声明设置为如下。这样就能够使用 SOFABoot 定义的 XML 元素进行开发。\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xmlns:context=\u0026amp;quot;http://www.springframework.org/schema/context\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; 在xml方式中发布和引用服务的方式如下。 sofa:service 元素表示发布服务， sofa:reference 元素表示引用服务。 sofa:binding 表示服务发布或引用的协议。\n\u0026amp;lt;bean id=\u0026amp;quot;personServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 一个服务也可以通过多种协议进行发布，如下：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 服务引用\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 也可以是其他的协议\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceRest\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-xml/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9192a93415bee3070a9be62c0f693949","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","summary":"声明 SOFABoot 的 xsd 文件：在要使用的 XML 配置文件中将头部 xsd 文件的声明设置为如下。这样就能够使用 SOFABoot 定义的 XML 元素进行开发。 \u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;beans xmlns=\u0026quot;http://www.springframework.org/schema/beans\u0026quot; xmlns:xsi=\u0026quot;http://www.w3.org/2001/XMLSchema-instance\u0026quot; xmlns:sofa=\u0026quot;http://sofastack.io/schema/sofaboot\u0026quot; xmlns:context=\u0026quot;http://www.springframework.org/schema/context\u0026quot; xsi:schemaLocation=\u0026quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026quot; default-autowire=\u0026quot;byName\u0026quot;\u0026gt; 在xml","tags":null,"title":"SOFABoot 环境 XML 配置使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","wordcount":179},{"author":null,"categories":null,"content":"SOFABoot 为 RPC 服务的发布和引用提供了一套编程 API 方式，方便直接在代码中发布和引用 RPC 服务，与 Spring 的 ApplicationContextAware 类似，为使用编程 API 方式，首先需要实现 ClientFactoryAware 接口获取编程组件 API：\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } 以 DirectService 为例，看下如何使用 clientFactory 通过编程 API 方式发布 RPC 服务：\nServiceClient serviceClient = clientFactory.getClient(ServiceClient.class); ServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(DirectService.class); serviceParam.setInstance(new DirectServiceImpl()); List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); serviceClient.service(serviceParam); 上面的代码中\n 首先通过 clientFactory 获得 ServiceClient 对象 然后构造 ServiceParam 对象，ServiceParam 对象包含发布服务所需参数，通过 setInstance 方法来设置需要被发布成 RPC 服务的对象，setInterfaceType 来设置服务的接口 最后，调用 ServiceClient 的 service 方法，发布一个 RPC 服务 通过编程 API 方式引用 RPC 服务的代码也是类似的：\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt;(); referenceParam.setInterfaceType(DirectService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); DirectService proxy = referenceClient.reference(referenceParam); proxy.sayDirect(\u0026amp;quot;hello\u0026amp;quot;); 同样，引用一个 RPC 服务只需从 ClientFactory 中获取一个 ReferenceClient ，然后和发布一个服务类似，构造出一个 ReferenceParam，然后设置好服务的接口，最后调用 ReferenceClient 的 reference 方法即可。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-api/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2679388dc3459714f869d8f8a71739d7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","summary":"SOFABoot 为 RPC 服务的发布和引用提供了一套编程 API 方式，方便直接在代码中发布和引用 RPC 服务，与 Spring 的 ApplicationContextAware 类似，为使用编程 API 方式，首先需要实现 ClientFactoryAware 接口获取编程组件","tags":null,"title":"SOFABoot 环境动态 API 使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","wordcount":374},{"author":null,"categories":null,"content":" 这部分介绍在 SOFABoot 环境下,完整的 SOFARPC 服务发布与引用说明\n发布服务 \u0026amp;lt;bean id=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; thread-pool-ref=\u0026amp;quot;\u0026amp;quot; warm-up-time=\u0026amp;quot;60000\u0026amp;quot; warm-up-weight=\u0026amp;quot;10\u0026amp;quot; weight=\u0026amp;quot;100\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 属性 名称 默认值 备注 id ID bean名 class 类 无 ref 服务接口实现类 interface 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 unique-id 服务标签（唯一标识元素） filter 过滤器配置别名 多个用逗号隔开 registry 服务端注册中心 逗号分隔 timeout 服务端执行超时时间 serialize-type 序列化协议 hessian2,protobuf thread-pool-ref 服务端当前接口使用的线程池 无 weight 服务静态权重 warm-up-weight 服务预热权重 warm-up-time 服务预热时间 单位毫秒 引用服务 \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;helloSyncServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;sync\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; address-wait-time=\u0026amp;quot;1000\u0026amp;quot; connect.num=\u0026amp;quot;1\u0026amp;quot; check=\u0026amp;quot;false\u0026amp;quot; connect.timeout=\u0026amp;quot;1000\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; generic-interface=\u0026amp;quot;\u0026amp;quot; idle.timeout=\u0026amp;quot;1000\u0026amp;quot; idle.timeout.read=\u0026amp;quot;1000\u0026amp;quot; lazy=\u0026amp;quot;false\u0026amp;quot; loadBalancer=\u0026amp;quot;\u0026amp;quot; registry=\u0026amp;quot;\u0026amp;quot; retries=\u0026amp;quot;1\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;xxx:12200\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; type=\u0026amp;quot;sync\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 属性 名称 默认值 备注 id ID 自动生成 jvm-first 是否优先本地 true interface 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 unique-id 服务标签（唯一标识元素） type 调用方式 sync callback,sync,future,oneway filter 过滤器配置别名 List registry 服务端注册中心 List method 方法级配置 说明同上 serialize-type 序列化协议 hessian2 target-url 直连地址 直连后register generic-interface 泛化接口 connect.timeout 建立连接超时时间 3000(cover 5000) connect.num 连接数 1 idle.timeout 空闲超时时间 idle.timeout.read 读空闲超时时间 loadBalancer 负载均衡算法 random lazy 是否延迟建立长连接 false address-wait-time 等待地址获取时间 -1 取决于实现，可能不生效。 timeout 调用超时时间 3000(cover 5000) retries 失败后重试次数 0 跟集群模式有关，failover读取此参数。 callback-class callback 回调类 无 callback 才可用 callback-ref callback 回调类 无 callback 才可用 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/rpc-config-xml-explain/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4b5110e9eb6cf6c6f287aef0fd210047","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","summary":"这部分介绍在 SOFABoot 环境下,完整的 SOFARPC 服务发布与引用说明 发布服务 \u0026lt;bean id=\u0026quot;helloSyncServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;helloSyncServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026quot; unique-id=\u0026quot;\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs registry=\u0026quot;\u0026quot; serialize-type=\u0026quot;\u0026quot; filter=\u0026quot;\u0026quot; timeout=\u0026quot;3000\u0026quot; thread-pool-ref=\u0026quot;\u0026quot; warm-up-time=\u0026quot;60000\u0026quot; warm-up-weight=\u0026quot;10\u0026quot; weight=\u0026quot;100\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;sofa:binding.rest\u0026gt; \u0026lt;/sofa:binding.rest\u0026gt; \u0026lt;/sofa:service\u0026gt; 属性 名称 默认值 备注 id ID bean名 class 类 无 ref 服","tags":null,"title":"SOFABoot 环境发布订阅说明","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","wordcount":518},{"author":null,"categories":null,"content":" 注解服务发布与服务引用 除了常规的 xml 方式发布服务外，我们也支持在SOFABoot 环境下，注解方式的发布与引用，同 xml 类似，我们有 @SofaService 和 @SofaReference，同时对于多协议，存在@SofaServiceBinding 和 @SofaReferenceBinding 注解。\n服务发布 如果要发布一个 RPC 服务。我们只需要在 Bean 上面打上@SofaService注解。指定接口和协议类型即可。\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } 服务引用 对于需要引用远程服务的 bean, 只需要在属性，或者方法上，打上@SofaReference的注解即可，支持 bolt, dubbo, rest 协议。\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } 使用演示 可以在 sample 工程目录的 annotation 子项目中进行验证测试。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-annotation/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2c3afd33cbce4f5aa2473716b3afe5a6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","summary":"注解服务发布与服务引用 除了常规的 xml 方式发布服务外，我们也支持在SOFABoot 环境下，注解方式的发布与引用，同 xml 类似，我们有 @SofaService 和 @SofaR","tags":null,"title":"SOFABoot 环境注解使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","wordcount":317},{"author":null,"categories":null,"content":" SOFADashboard is designed to implement unified management over SOFA framework components, including service governance and SOFAArk control. All technology stacks used by SOFADashboard are developed and constructed based on open-source community products, such as Ant Design Pro, SOFABoot, Spring, and MyBatis.\nCurrently, service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper. Therefore, you need to ensure the ZooKeeper service is available when you decide to use SOFADashboard. You also need to ensure that MySQL is available, because SOFAArk control and deployment uses MySQL for resource data storage.\nArchitecture Currently, service governance and SOFAArk control of SOFADashboard are implemented upon ZooKeeper-based programming.\n SOFADashboard backend corresponds to the sofa-dashboard-backend project. It is the server end project of SOFADashboard, responsible for data interaction between ZooKeeper and MySQL and for providing the rest API to the SOFADashboard frontend. SOFADashboard frontend corresponds to the sofa-dashboard-frontend project. It is the frontend project of SOFADashboard. It provides UIs for interaction with users. Application rpc provider: service provider of SOFARPC, which registers services with ZooKeeper. rpc consumer: service consumer of SOFARPC, which subscribes to services on ZooKeeper. client: SOFADashboard client, which is available upon the installation of the sofa-dashboard-client package. Currently, the SOFADashboard client only supports registration of health-check status and port information of applications with ZooKeeper. Later on, it will evolve into SOFABoot client, and report more diversified application data. ark-biz host app: see SOFAArk. ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f0664d0ca7fc1fa87e67847525081993","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/overview/","summary":"SOFADashboard is designed to implement unified management over SOFA framework components, including service governance and SOFAArk control. All technology stacks used by SOFADashboard are developed and constructed based on open-source community products, such as Ant Design Pro, SOFABoot, Spring, and MyBatis.\nCurrently, service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper. Therefore, you need to ensure the ZooKeeper service is available when you decide to use SOFADashboard. You also need to ensure that MySQL is available, because SOFAArk control and deployment uses MySQL for resource data storage.","tags":null,"title":"SOFADashboard overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/overview/","wordcount":230},{"author":null,"categories":null,"content":" SOFADashboard 致力于对 SOFA 框架中组件进行统一管理，包括服务治理、SOFAArk 管控等。SOFADashboard 本身所用技术栈均基于开源社区产品来开发构建，包括：Ant Design Pro、SOFABoot、Spring、MyBatis 等。\n目前，SOFADashboard 中的服务治理、SOFAArk 管控等需要依赖于 Zookeeper，因此如果您需要使用 SOFADashboard 那么请确保 Zookeeper 服务可用；另外 SOFAArk 管控部署需要依赖 MySQL 进行资源数据存储，因此也需要保证 MySQL 可以正常使用。\n架构简图 SOFADashboard 目前服务治理与 SOFAArk 管控都是面向 Zookeeper 来编程实现的。\n SOFADashboard backend : 对应 sofa-dashboard-backend 工程，是 SOFADashboard 的服务端工程，负责与 Zookeeper 和 MySQL 进行数据交互，并且为 SOFADashboard frontend 提供 rest 接口。 SOFADashboard frontend : 对应 sofa-dashboard-frontend 工程，是 SOFADashboard 的前端工程，用于提供与用户交互的 UI 界面。 app 应用 rpc provider : SOFARPC 的服务提供方，会将服务注册到 Zookeeper 上。 rpc consumer : SOFARPC 的服务消费方，会从 Zookeeper 上订阅服务。 client : SOFADashboard 客户端，引入 sofa-dashboard-client 包即可。目前仅提供将应用的健康检查状态及端口信息注册到 Zookeeper ，后面将会演化成 SOFABoot client，上报更丰富的应用数据。 ark-biz 宿主应用: 参考 SOFAArk 。 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f0664d0ca7fc1fa87e67847525081993","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/overview/","summary":"SOFADashboard 致力于对 SOFA 框架中组件进行统一管理，包括服务治理、SOFAArk 管控等。SOFADashboard 本身所用技术栈均基于开源社区产品来开发构建","tags":null,"title":"SOFADashboard 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/overview/","wordcount":431},{"author":null,"categories":null,"content":" This topic is a part of the Braft document. To read the Braft document, click here. The Raft algorithm and its application are comprehensively described in the Braft document. As JRaft is designed on the basis of Braft, we strongly recommend that you read the Braft document first to understand the basic principles and application of the Raft algorithm.\nDistributed consensus Distributed consensus is a very fundamental problem in a distributed system. Simply put, it is about how to reach a consensus on a specific value among multiple servers, and ensure that the decision is not overthrown regardless of what failures may occur on these servers. Assume that, all processes of a distributed system needs to determine a value V. If the system has the following properties, we consider it solves the problem of distributed consensus:\n Termination: All normal processes will determine the specific value of V, and there is no process that keeps running in a loop. Validity: A value V\u0026amp;rsquo; determined by normal processes must have been proposed by one of them. For example, a random number generator does not have this property. Agreement: All normal processes choose the same value. Consensus state machine Assume we have an infinitely incrementing sequence (system) a[1, 2, 3…]. If for any integer i, the value of a[i] meets the distributed consensus requirement, the system meets the requirement of a consensus state machine. Basically, all systems are subject to continuous operations, and reaching consensus on a single value is definitely not enough. To make sure all replicas of a real-life system are consistent, we usually convert the operations into entries of a write-ahead-log(WAL). Then, we make sure all replicas of the system reach a consensus on the WAL entries, so that each process will perform operations corresponding to the WAL entries in order. As a result, the replicas are in consistent states.\nRAFT RAFT is a new and easy-to-understand distributed consensus replication protocol proposed by Diego Ongaro and John Ousterhout of Stanford University as a central coordination component of the RAMCloudproject. Raft is a leader-based multi-Paxos variant that provides a more complete and straightforward protocol description than existing protocols such as Paxos, Zab, and Viewstamped Replication. It also provides a clear description for adding and deleting nodes. In Raft, replicated state machines are the most important and fundamental to distributed systems. Raft allows commands to be replicated and executed in order, and ensures that the states of nodes remain consistent when their initial states are the same. A system is fully functional (available) as long as a majority of nodes function properly. It allows non-Byzantine conditions, including network delays, packet loss, and reordering, but does not allow tampering with any messages.\nRaft can solve the distributed consensus and partitioning problems, but cannot solve the availability problem. Raft covers …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/overview/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"eff7088d010aefabdffa2858e88d76c0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/overview/","summary":"This topic is a part of the Braft document. To read the Braft document, click here. The Raft algorithm and its application are comprehensively described in the Braft document. As JRaft is designed on the basis of Braft, we strongly recommend that you read the Braft document first to understand the basic principles and application of the Raft algorithm.\nDistributed consensus Distributed consensus is a very fundamental problem in a distributed system.","tags":null,"title":"SOFAJRaft overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/overview/","wordcount":645},{"author":null,"categories":null,"content":" 本介绍内容来自 braft 文档，原文链接请参见这里。braft 的关于算法和应用本身的文档非常优秀，由于 jraft 脱胎自 braft，我们强烈推荐阅读上述文档以了解 raft 算法的基本原理和应用。\n分布式一致性 分布式一致性 (distributed consensus) 是分布式系统中最基本的问题，用来保证一个分布式系统的可靠性以及容灾能力。简单的来讲，就是如何在多个机器间对某一个值达成一致, 并且当达成一致之后，无论之后这些机器间发生怎样的故障，这个值能保持不变。 抽象定义上， 一个分布式系统里的所有进程要确定一个值 v，如果这个系统满足如下几个性质， 就可以认为它解决了分布式一致性问题, 分别是:\n Termination: 所有正常的进程都会决定 v 具体的值，不会出现一直在循环的进程。 Validity: 任何正常的进程确定的值 v\u0026amp;rsquo;, 那么 v\u0026amp;rsquo; 肯定是某个进程提交的。比如随机数生成器就不满足这个性质。 Agreement: 所有正常的进程选择的值都是一样的。 一致性状态机 对于一个无限增长的序列 a[1, 2, 3…], 如果对于任意整数 i, a[i] 的值满足分布式一致性，这个系统就满足一致性状态机的要求。 基本上所有的系统都会有源源不断的操作, 这时候单独对某个特定的值达成一致是不够的。为了真实系统保证所有的副本的一致性，通常会把操作转化为 write-ahead-log(简称WAL)。然后让系统的所有副本对WAL保持一致，这样每个进程按照顺序执行WAL里的操作，就能保证最终的状态是一致的。\nRAFT RAFT 是一种新型易于理解的分布式一致性复制协议，由斯坦福大学的 Diego Ongaro 和 John Ousterhout 提出，作为 RAMCloud 项目中的中心协调组件。Raft 是一种 Leader-Based 的 Multi-Paxos 变种，相比 Paxos、Zab、View Stamped Replication 等协议提供了更完整更清晰的协议描述，并提供了清晰的节点增删描述。 Raft 作为复制状态机，是分布式系统中最核心最基础的组件，提供命令在多个节点之间有序复制和执行，当多个节点初始状态一致的时候，保证节点之间状态一致。系统只要多数节点存活就可以正常处理，它允许消息的延迟、丢弃和乱序，但是不允许消息的篡改（非拜占庭场景）。\nRaft 可以解决分布式理论中的 CP，即一致性和分区容忍性，并不能解决 Available 的问题。其中包含分布式系统中一些通常的功能：\n Leader Election Log Replication Membership Change Log Compaction RAFT 可以做什么 通过 RAFT 提供的一致性状态机，可以解决复制、修复、节点管理等问题，极大的简化当前分布式系统的设计与实现，让开发者只关注于业务逻辑，将其抽象实现成对应的状态机即可。基于这套框架，可以构建很多分布式应用：\n 分布式锁服务，比如 Zookeeper 分布式存储系统，比如分布式消息队列、分布式块系统、分布式文件系统、分布式表格系统等 高可靠元信息管理，比如各类 Master 模块的 HA JRAFT 一个纯 Java 的 Raft 算法实现库, 基于百度 braft 实现而来, 使用 Java 重写了所有功能, 支持:\n Leader election and priority-based semi-deterministic leader election. Replication and recovery. Snapshot and log compaction. Read-only member (learner). Membership management. Fully concurrent replication. Fault tolerance. Asymmetric network partition tolerance. Workaround when quorate peers are dead. Replication pipeline optimistic Linearizable read, ReadIndex/LeaseRead. 联系我们 更多讨论欢迎加入钉钉讨论群：44858463\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/overview/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"eff7088d010aefabdffa2858e88d76c0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-jraft/overview/","summary":"本介绍内容来自 braft 文档，原文链接请参见这里。braft 的关于算法和应用本身的文档非常优秀，由于 jraft 脱胎自 braft，我们强烈推荐阅读上述文档以了","tags":null,"title":"SOFAJRaft 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/overview/","wordcount":1132},{"author":null,"categories":null,"content":" SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\n1.客户端部分 SOFALookout Client 是一个 Java 的 SDK，可以帮助开发者在项目代码中进行 metrics 埋点。通过它也可以查看该 JAVA 应用的实时的状态信息。\n +------------------+ Reg: API: | dimension meters +--------+ +------------------+ | flatmap +---------------------------+ +-----------\u0026amp;gt; | Default/DropwizardMetrics| | +---------------------------+ | | http +--------------+ +-----------\u0026amp;gt; |Lookout server| | +--------------+ +----------------------+ | add common tags dimension EXTS: | JVM,OS,GC... +----+ +----------------------+ 2.服务器端服务 SOFALookout Server 可以帮助我们解决分布式环境下系统状态度量的问题，它提供丰富的协议接入支持，包括自有SDK（SOFALookout Client）上报协议，还支持 Prometheus 的数据协议（推模式和拉模式），Metricbeat 协议（版本是6），Opentsdb写入协议。 Lookout Server 兼容和增强了 Prometheus 的数据及元数据查询的 RESTful API。同样对应 PromQL 我们也基本实现了兼容和增强（不包括 Alert 相关语法）。\n2.1.Metrics 服务器端主要特性: 适配社区主要 Metrics 数据源协议写入（比如: Prometheus，Metricbeat等）； 数据的存储支持扩展，暂时开源版默认支持 Elasticsearch,并且透明和自动化了相关运维操作； 遵循 Prometheus 查询 API 的标准以及支持 PromQL，并进行了适当改进； 自带数据查询的控制台，并支持 Grafana 进行数据可视化； 使用简单，支持单一进程运行整个服务器端模块。 2.2.Metrics 服务器端工作机制: +----------------+ | Lookout Client +-----+ +----------------+ | +----------------+ | | Prometheus SDK +-----+ +-------------------+ +----------------------+ +------------------+ +-----------+ +----------------+ +--\u0026amp;gt; Lookout Gateway +---\u0026amp;gt; DB(ES/InfluxDB...) \u0026amp;lt;-----+ Lookout Server \u0026amp;lt;----+ Grafana | +----------------+ | +-------------------+ +----------------------+ +------------------+ +-----------+ | Metricbeat +-----+ +----------------+ | +----------------+ | | ... +-----+ +----------------+ ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/overview/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8a8a8ef02ca95d4d11e3e4b195bbae70","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/overview/","summary":"SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项","tags":null,"title":"SOFALookout 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/overview/","wordcount":602},{"author":null,"categories":null,"content":" 1.使用本机 ES 服务 1)本地启动 ES docker run -d --name es -p 9200:9200 -p 9300:9300 -e \u0026amp;quot;discovery.type=single-node\u0026amp;quot; elasticsearch:5.6 版本：V5，V6\n 2)检查 ES 是否健康 http://localhost:9200/_cat/health?v 3)启动 Lookout 服务 执行 all-in-one-bootstrap 编译后的 fat-jar 包，如何获得，见文末备注部分：\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -jar lookout-all-in-one-bootstrap-1.6.0-executable-ark.jar 注意 -Dcom.alipay.sofa.ark.master.biz=lookoutall 是必须的, 用于设置 sofa-ark 的 master biz。\n 4)最后进行功能验证\n 查询 （Gateway）的 metrics 作为功能验证，访问“localhost:9090”，在查询框输入：\njvm.memory.heap.used{app=\u0026amp;quot;gateway\u0026amp;quot;} 最后，也可以使用 grafana\n2.使用远程 ES 服务 总体步骤和“使用本机 ES 服务”类似，唯一不同的是，需要指定配置文件。\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -Dlookoutall.config-file=abc.properties \\ -jar lookout-all-in-one-bootstrap-1.6.0-executable-ark.jar -Dlookoutall.config-file（如果你本地启动 ES 测试的话则该配置项可以忽略！），该配置项制定的文件暂时只能引用文件系统上的 properties 文件(没有像 spring-boot 支持那么丰富），配置项必须以应用名开头，从而提供隔离能力。\n例如：在fat-jar同目录下创建一个abc.properties配置文件, 用于存放存放配置文件(下面列出了必须的配置项,用于指向使用的 ES 服务地址）：\ngateway.metrics.exporter.es.host=localhost gateway.metrics.exporter.es.port=9200 metrics-server.spring.data.jest.uri=http://localhost:9200 备注 如何获得 all-in-one-bootstrap 编译后的 fat-jar。\n方式1：本地编译\n./boot/all-in-one-bootstrap/build.sh 打包结果在boot/all-in-one-bootstrap/target/allinone-executable.jar\n 方式2：发布报告中附件获取\n临时方式（针对 1.6.0）暂时提供一个 v1.6.0的snapshot包，下载后（保证ES服务已经单独启动）运行：\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -jar lookout-all-1.6.0.snapshot.jar 方式3：使用docker镜像\n服务端默认会连接到 localhost:9200 的ES实例, 而我所用的开发机器是MacOS，无法使用 --net=host 模式启动容器，因此在容器内无法通过 localhost:9200 连接ES，需要使用如下方式绕过去：\n编辑一个配置文件，比如 foo.properties：\ngateway.metrics.exporter.es.host=es metrics-server.spring.data.jest.uri=http://es:9200 在 foo.properties 所在的目录下运行 all-in-one 镜像：\ndocker run -it \\ --name allinone \\ --link es:es \\ -p 7200:7200 \\ -p 9090:9090 \\ -v $PWD/foo.properties:/home/admin/deploy/foo.properties \\ -e JAVA_OPTS=\u0026amp;quot;-Dlookoutall.config-file=/home/admin/deploy/foo.properties\u0026amp;quot; \\ -e JAVA_OPTS=\u0026amp;quot;...定制JVM系统属性...\u0026amp;quot; \\ xzchaoo/lookout-allinone:1.6.0-SNAPSHOT 这里利用了docker的\u0026amp;ndash;link参数使得应用可以访问到ES实例 这里做测试用，所以不用-d参数在后台运行\n ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-metrics-server/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7c12565c66342c2f8e963cf1c1e26db5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","summary":"1.使用本机 ES 服务 1)本地启动 ES docker run -d --name es -p 9200:9200 -p 9300:9300 -e \u0026quot;discovery.type=single-node\u0026quot; elasticsearch:5.6 版本：V5，V6 2)检查 ES 是否健康 http://localhost:9200/_cat/health?v 3)启动 Lookout 服务 执行 all-in-one-bootstrap 编译后的 fat-jar 包，如何获得，见文","tags":null,"title":"SOFALookout 服务端快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","wordcount":808},{"author":null,"categories":null,"content":" This repository is deprecated. It will contribute to istio directly instead of developing in a forked repo. Please go to see Istio’s doc.\nSOFAMesh is a large-scale implementation scheme of Service Mesh based on Istio. On the basis of inheriting the powerful functions and rich features of Istio, in order to meet the performance requirements in large-scale deployments and to respond to the actual situation in the implementation, the following improvements are made:\n MOSN written in Golang instead of Envoy Merge Mixer to data plane to resolve performance bottlenecks Enhance Pilot for more flexible service discovery mechanism Added support for SOFA RPC, Dubbo The initial version was contributed by Ant Financial and Alibaba UC Business Unit.\nThe following figure shows the architectural differences between SOFAMesh and Istio:\nMain components MOSN In SOFAMesh, the data pane adopts Golang to write a module called MOSN (Modular Open Smart Network), and replaces Envoy with MOSN to integrate with Istio to implement the functions of Sidecar. MOSN is fully compatible with Envoy\u0026amp;rsquo;s APIs.\nSOFAMesh Pilot SOFAMesh greatly expands and enhances the Pilot module in Istio:\n Add an Adapter for SOFA Registry to provide solutions for super large-scale service registration and discovery; Add data synchronization modules to enable data exchange between multiple service registry centers; Add Open Service Registry API to provide standardized service registration. Together with Pilot and MOSN, SOFAMesh provides the ability to enable traditional intrusive frameworks (such as Spring Cloud, Dubbo and SOFARPC) and Service Mesh products to communicate with each other, thus it can smoothly evolve and transit to Service Mesh.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e44a7cb73f7b68217663bd75655f43d7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/overview/","summary":"This repository is deprecated. It will contribute to istio directly instead of developing in a forked repo. Please go to see Istio’s doc.\nSOFAMesh is a large-scale implementation scheme of Service Mesh based on Istio. On the basis of inheriting the powerful functions and rich features of Istio, in order to meet the performance requirements in large-scale deployments and to respond to the actual situation in the implementation, the following improvements are made:","tags":null,"title":"SOFAMesh overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/overview/","wordcount":260},{"author":null,"categories":null,"content":" 该项目仓库已弃用。该项目将直接向 Istio 贡献，不会继续在 fork 的仓库中开发，请转至 Istio 官网。\nSOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强大功能和丰富特性的基础上，为满足大规模部署下的性能要求以及应对落地实践中的实际情况，有如下改进：\n 采用 Golang 编写的 MOSN 取代 Envoy 合并 Mixer 到数据平面以解决性能瓶颈 增强 Pilot 以实现更灵活的服务发现机制 增加对 SOFA RPC、Dubbo 的支持 初始版本由蚂蚁金服和阿里大文娱UC事业部携手贡献。\n下图展示了SOFAMesh 和 Istio 在架构上的不同：\n主要组件 MOSN 在 SOFAMesh 中，数据面我们采用 Golang 语言编写了名为 MOSN（Modular Open Smart Network）的模块来替代 Envoy 与 Istio 集成以实现 Sidecar 的功能，同时 MOSN 完全兼容 Envoy 的 API。\nSOFA Pilot SOFAMesh 中大幅扩展和增强 Istio 中的 Pilot 模块：\n 增加 SOFA Registry 的 Adapter，提供超大规模服务注册和发现的解决方案 增加数据同步模块，以实现多个服务注册中心之间的数据交换 增加 Open Service Registry API，提供标准化的服务注册功能 MOSN 和 Pilot 配合，将可以提供让传统侵入式框架（如 Spring Cloud、Dubbo、SOFARPC 等）和 Service Mesh 产品可以相互通讯的功能，以便可以平滑的向 Service Mesh 产品演进和过渡。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e44a7cb73f7b68217663bd75655f43d7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/overview/","summary":"该项目仓库已弃用。该项目将直接向 Istio 贡献，不会继续在 fork 的仓库中开发，请转至 Istio 官网。 SOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强","tags":null,"title":"SOFAMesh 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/overview/","wordcount":474},{"author":null,"categories":null,"content":" SOFARPC Metrics SOFARPC currently measures two metrics.\nServer thread pool metric name metric tags specification rpc.bolt.threadpool.config bolt thread pool configuration Mainly includes thread pool configuration information for RPC server rpc.bolt.threadpool.active.count Running thread of the current thread pool rpc.bolt.threadpool.idle.count Idle thread of the current thread pool rpc.bolt.threadpool.queue.size Tasks in the queue of the current thread pool Client call information metric name metric tags specification rpc.consumer.service.stats.fail_count.count app,service,method,protocol,invoke_type,target_app Failure count of a certain interface rpc.consumer.service.stats.fail_count.rate app,service,method,protocol,invoke_type,target_app Number of failures per second of a certain interface rpc.consumer.service.stats.fail_time.elapPerExec app,service,method,protocol,invoke_type,target_app Average time per failed execution of a certain interface rpc.consumer.service.stats.fail_time.max app,service,method,protocol,invoke_type,target_app Maximum failure time of a certain interface rpc.consumer.service.stats.fail_time.totalTime app,service,method,protocol,invoke_type,target_app Total failure time of a certain interface rpc.consumer.service.stats.request_size.max app,service,method,protocol,invoke_type,target_app Maximum request size of a certain interface rpc.consumer.service.stats.request_size.rate app,service,method,protocol,invoke_type,target_app Average request size per second of a certain interface rpc.consumer.service.stats.request_size.totalAmount app,service,method,protocol,invoke_type,target_app Total request amount of a certain interface rpc.consumer.service.stats.response_size.max app,service,method,protocol,invoke_type,target_app Maximum response size of a certain interface rpc.consumer.service.stats.response_size.rate app,service,method,protocol,invoke_type,target_app Average response size per second of a certain interface rpc.consumer.service.stats.response_size.totalAmount app,service,method,protocol,invoke_type,target_app Total response amount of a certain interface rpc.consumer.service.stats.total_count.count app,service,method,protocol,invoke_type,target_app Total number of calls of a certain interface rpc.consumer.service.stats.total_count.count_service_sum_30000 app,service,method,protocol,invoke_type,target_app Total call information of a certain interface rpc.consumer.service.stats.total_count.rate app,service,method,protocol,invoke_type,target_app Number of calls per second of a certain interface rpc.consumer.service.stats.total_time.elapPerExec app,service,method,protocol,invoke_type,target_app Average time per execution of a certain interface rpc.consumer.service.stats.total_time.max app,service,method,protocol,invoke_type,target_app Maximum total time of a certain interface rpc.consumer.service.stats.total_time.totalTime …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/sofarpc-metrics/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1f444349855508f4b111d8f2d2b5e43d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","summary":"SOFARPC Metrics SOFARPC currently measures two metrics.\nServer thread pool metric name metric tags specification rpc.bolt.threadpool.config bolt thread pool configuration Mainly includes thread pool configuration information for RPC server rpc.bolt.threadpool.active.count Running thread of the current thread pool rpc.bolt.threadpool.idle.count Idle thread of the current thread pool rpc.bolt.threadpool.queue.size Tasks in the queue of the current thread pool Client call information metric name metric tags specification rpc.","tags":null,"title":"SOFARPC Metrics","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","wordcount":332},{"author":null,"categories":null,"content":" SOFARPC 目前度量了两个指标。\n 服务端线程池 metric name metric tags specification rpc.bolt.threadpool.config bolt 线程池配置 主要包括 rpc 服务端的线程池配置信息 rpc.bolt.threadpool.active.count 当前线程池的运行线程 rpc.bolt.threadpool.idle.count 当前线程池的空闲线程 rpc.bolt.threadpool.queue.size 当前线程池的队列中的任务 客户端调用信息 metric name metric tags specification rpc.consumer.service.stats.fail_count.count app,service,method,protocol,invoke_type,target_app 某个具体接口失败次数 rpc.consumer.service.stats.fail_count.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒失败 rpc.consumer.service.stats.fail_time.elapPerExec app,service,method,protocol,invoke_type,target_app 某个具体接口每秒执行时间 rpc.consumer.service.stats.fail_time.max app,service,method,protocol,invoke_type,target_app 某个具体接口失败时间最大值 rpc.consumer.service.stats.fail_time.totalTime app,service,method,protocol,invoke_type,target_app 某个具体接口失败时间总值 rpc.consumer.service.stats.request_size.max app,service,method,protocol,invoke_type,target_app 某个具体接口请求大小最大值 rpc.consumer.service.stats.request_size.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒平均请求大小 rpc.consumer.service.stats.request_size.totalAmount app,service,method,protocol,invoke_type,target_app 某个具体接口请求大小总金额 rpc.consumer.service.stats.response_size.max app,service,method,protocol,invoke_type,target_app 某个具体接口响应大小最大值 rpc.consumer.service.stats.response_size.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒平均响应大小 rpc.consumer.service.stats.response_size.totalAmount app,service,method,protocol,invoke_type,target_app 某个具体接口响应大小总金额 rpc.consumer.service.stats.total_count.count app,service,method,protocol,invoke_type,target_app 某个具体接口总的调用数目 rpc.consumer.service.stats.total_count.count_service_sum_30000 app,service,method,protocol,invoke_type,target_app 某个具体接口总的调用信息 rpc.consumer.service.stats.total_count.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒调用次数 rpc.consumer.service.stats.total_time.elapPerExec app,service,method,protocol,invoke_type,target_app 某个具体接口平均每次指定时间 rpc.consumer.service.stats.total_time.max app,service,method,protocol,invoke_type,target_app 某个具体接口总时间最大值 rpc.consumer.service.stats.total_time.totalTime app,service,method,protocol,invoke_type,target_app 某个具体接口总时间 服务端被调用信息 metric name metric tags specification rpc.provider.service.stats.fail_count.count app,service,method,protocol,caller_app 某个具体接口总的被调用失败次数 rpc.provider.service.stats.fail_count.rate app,service,method,protocol,caller_app 某个具体接口每秒失败次数 rpc.provider.service.stats.fail_time.elapPerExec app,service,method,protocol,caller_app 某个具体接口每次失败失败 rpc.provider.service.stats.fail_time.max app,service,method,protocol,caller_app 某个具体接口失败次数最大值 rpc.provider.service.stats.fail_time.totalTime app,service,method,protocol,caller_app 某个具体接口失败总时间 rpc.provider.service.stats.total_count.count app,service,method,protocol,caller_app 某个具体接口总的调用次数 rpc.provider.service.stats.total_count.rate app,service,method,protocol,caller_app 某个具体接口每秒调用次 …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/sofarpc-metrics/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1f444349855508f4b111d8f2d2b5e43d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","summary":"SOFARPC 目前度量了两个指标。 服务端线程池 metric name metric tags specification rpc.bolt.threadpool.config bolt 线程池配置 主要包括 rpc 服务端的线程池配置信息 rpc.bolt.threadpool.active.count 当前线程池的运行线程 rpc.bolt.threadpool.idle.count 当前线程池的空闲线程 rpc.bolt.threadpool.queue.size 当前","tags":null,"title":"SOFARPC Metrics 指标","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","wordcount":487},{"author":null,"categories":null,"content":" SOFARPC is divided into two layers from bottom to top:\n Core layer: It contains the core components of RPC (such as various interfaces, APIs and common packages) and some common implementations (such as random load balancing algorithms). Function implementation layer: All users of the function implementation layer are equal, and all functions are implemented based on the extension mechanism. The internal version specific for Ant Financial just has some internal extension based on the open source version.\nOf course, you can add your own third-party extension. See Extension mechanism for more information.\nModule division The implementation classes of each module only appear in the modules. Generally, the modules don\u0026amp;rsquo;t depend on each other. The modules that require cross dependency have been abstracted into the core or common modules.\nCurrently, SOFARPC is divided into the following modules:\nThe main modules and their corresponding dependencies are as follows:\n Module Submodule Definition Description Dependency all Publish and packing module All modules that need to be packaged bom Dependency control module Control dependency version None example Sample module all test Test module Include integration test all core api API module Include various basic process interfaces, messages, contexts, extension interfaces and others Common core common Public module Include utils and data structure exception core exception Exception module Include various exception interfaces and others common bootstrap Startup implementation module Include start class, service publish or reference logic, and registry operations core proxy Proxy implementation module Generate interface implementation proxy core Client Client implementation module Send request, receive response, maintain connections, routing, and implement load balancing, synchronization, asynchronization and other operations server Server implementation module Start listening, receive requests, send responses, distribute business threads, and implement other operations filter Interceptor implementation module Implement various interceptors for server and client core codec Coding and encoding implementation module Implement compression, serialization and other operations core protocol Protocol implementation module Package and process protocol and conduct negotiation core transport Network transmission implementation module Establish TCP connection, process sticky data packets, and distribute requested response objects registry Registry center implementation module Implement registration centers, such as ZooKeeper core ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/structure-intro/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1902232a50d57df7ab5b2c7eea1f8caa","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/structure-intro/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/structure-intro/","summary":"SOFARPC is divided into two layers from bottom to top:\n Core layer: It contains the core components of RPC (such as various interfaces, APIs and common packages) and some common implementations (such as random load balancing algorithms). Function implementation layer: All users of the function implementation layer are equal, and all functions are implemented based on the extension mechanism. The internal version specific for Ant Financial just has some internal extension based on the open source version.","tags":null,"title":"SOFARPC architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/structure-intro/","wordcount":347},{"author":null,"categories":null,"content":" SOFARPC Log Format After SOFARPC (v5.4.0 and above) is integrated in SOFATracer, the link data is output in JSON format by default. Each field meaning is as follows:\nRPC client digest log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type (bolt, rest) Service interface information Method name Current thread name Calling type (sync, callback, oneway, future) Routing record (DIRECT, REGISTRY) Target IP Target appName Local machine IP Return code (00=success; 01=business exception; 02=RPC logic error; 03=timeout failure;04=routing failure) Request serialization time (in ms) Response deserialization time (in ms) Response size (in Byte) Request size (in Byte) Client connection duration (in ms) Total call duration (in ms) Local client port Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;samples\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC server digest log (rpc-server-digest.log) Log printing time TraceId SpanId Span type Service interface information Method name Source IP Source appName Protocol (bolt, rest) Current appName Current thread name Return code (00=success; 01=business exception; 02=RPC logic error) Server thread pool waiting time (in ms) Business processing duration (in ms) Response serialization time (in ms) Request deserialization time (in ms) Response size (in Byte) Request size (in Byte) Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-sofarpc/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ad45177e2719b9a22f4bfb07a0481905","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","summary":"SOFARPC Log Format After SOFARPC (v5.4.0 and above) is integrated in SOFATracer, the link data is output in JSON format by default. Each field meaning is as follows:\nRPC client digest log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type (bolt, rest) Service interface information Method name Current thread name Calling type (sync, callback, oneway, future) Routing record (DIRECT, REGISTRY) Target IP Target appName Local machine IP Return code (00=success; 01=business exception; 02=RPC logic error; 03=timeout failure;04=routing failure) Request serialization time (in ms) Response deserialization time (in ms) Response size (in Byte) Request size (in Byte) Client connection duration (in ms) Total call duration (in ms) Local client port Transparently transmitted baggage data (kv format) Example:","tags":null,"title":"SOFARPC log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","wordcount":259},{"author":null,"categories":null,"content":" 项目简介 SOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有的业务的相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括 bolt，RESTful，dubbo，H2C 协议进行通信。其中 bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\n基本原理 当一个 SOFARPC 的应用启动的时候，如果发现当前应用需要发布 RPC 服务的话，那么 SOFARPC 会将这些服务注册到服务注册中心上。如图中 Service 指向 Registry。 当引用这个服务的 SOFARPC 应用启动时，会从服务注册中心订阅到相应服务的元数据信息。服务注册中心收到订阅请求后，会将发布方的元数据列表实时推送给服务引用方。如图中 Registry 指向 Reference。 当服务引用方拿到地址以后，就可以从中选取地址发起调用了。如图中 Reference 指向 Service。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"62f0806ad40fcaaeab6a82470b14a2e2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/overview/","summary":"项目简介 SOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有的业务的相互","tags":null,"title":"SOFARPC 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/overview/","wordcount":402},{"author":null,"categories":null,"content":" 架构图 SOFARPC 从下到上分为两层：\n 核心层：包含了我们的 RPC 的核心组件（例如我们的各种接口、API、公共包）以及一些通用的实现（例如随机等负载均衡算法）。 功能实现层：所有的功能实现层的用户都是平等的，都是基于扩展机制实现的。 蚂蚁内部使用的版本也只是开源版本上增加一些内部扩展而已。\n当然你也可以增加自己三方扩展，参见：扩展机制\n模块划分 各个模块的实现类都只在自己模块中出现，一般不交叉依赖。需要交叉依赖的全部已经抽象到core或者common模块中。\n目前模块划分如下:\n主要模块及其依赖如下：\n 模块名 子模块名 中文名 说明 依赖 all 发布打包模块 需要打包的全部模块 bom 依赖管控模块 依赖版本管控 无 example 示例模块 all test 测试模块 包含集成测试 all core api API模块 各种基本流程接口、消息、上下文、扩展接口等 common core common 公共模块 utils、数据结构 exception core exception 异常模块 各种异常接口等 common bootstrap 启动实现模块 启动类，发布或者引用服务逻辑、以及registry的操作 core proxy 代理实现模块 接口实现代理生成 core client 客户端实现模块 发送请求、接收响应、连接维护、路由、负载均衡、同步异步等 core server 服务端实现模块 启动监听、接收请求，发送响应、业务线程分发等 core filter 拦截器实现模块 服务端和客户端的各种拦截器实现 core codec 编解码实现模块 例如压缩，序列化等 core protocol 协议实现模块 协议的包装处理、协商 core transport 网络传输实现模块 TCP连接的建立，数据分包粘包处理，请求响应对象分发等 core registry 注册中心实现模块 实现注册中心，例如zk等 core ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/structure-intro/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1902232a50d57df7ab5b2c7eea1f8caa","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/structure-intro/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/structure-intro/","summary":"架构图 SOFARPC 从下到上分为两层： 核心层：包含了我们的 RPC 的核心组件（例如我们的各种接口、API、公共包）以及一些通用的实现（例如随机等负载均衡算法）","tags":null,"title":"SOFARPC 工程架构介绍","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/structure-intro/","wordcount":598},{"author":null,"categories":null,"content":" 本文档将演示了如何应用 SOFARPC 进行服务的发布和引用。 本例将在本地模拟服务端启动监听一个端口并发布一个服务，客户端引用该服务进行直连调用。\n您可以直接在工程下找到本文档的示例代码。\n创建工程 需要安装 JDK 6 及以上 和 Maven 3 以上.\n我们新建一个 Maven 工程，并引入 SOFARPC 的依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;最新版本\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 注：最新版本可以从 https://github.com/sofastack/sofa-rpc/releases 里找到。\n编写服务端实现 第一步：创建接口\n/** * Quick Start demo interface */ public interface HelloService { String sayHello(String string); } 第二步：创建接口实现\n/** * Quick Start demo implement */ public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string) { System.out.println(\u0026amp;quot;Server receive: \u0026amp;quot; + string); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; ！\u0026amp;quot;; } } 第三步：编写服务端代码\n/** * Quick Start Server */ public class QuickStartServer { public static void main(String[] args) { ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // 设置一个协议，默认bolt .setPort(12200) // 设置一个端口，默认12200 .setDaemon(false); // 非守护线程 ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // 指定接口 .setRef(new HelloServiceImpl()) // 指定实现 .setServer(serverConfig); // 指定服务端 providerConfig.export(); // 发布服务 } } 编写客户端实现 第一步：拿到服务端接口\n一般服务端会通过jar的形式将接口类提供给客户端。而在本例中，由于服务端和客户端在一个工程所以跳过。\n第二步：编程客户端代码\n/** * Quick Start client */ public class QuickStartClient { public static void main(String[] args) { ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // 指定接口 .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // 指定协议 .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12200\u0026amp;quot;); // 指定直连地址 // 生成代理类 HelloService helloService = consumerConfig.refer(); while (true) { System.out.println(helloService.sayHello(\u0026amp;quot;world\u0026amp;quot;)); try { Thread.sleep(2000); } catch (Exception e) { } } } } 运行 分别启动服务端和客户端，观察运行效果。\n服务端将打印：\n Server receive: world\n 客户端将打印：\n hello world ！\n 更多 更多示例请参考：example\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-rpc/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"192d252b0b36266622284b68d10e9fe4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","summary":"本文档将演示了如何应用 SOFARPC 进行服务的发布和引用。 本例将在本地模拟服务端启动监听一个端口并发布一个服务，客户端引用该服务进行直连调用。 您可以直接","tags":null,"title":"SOFARPC 方式快速入门","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","wordcount":563},{"author":null,"categories":null,"content":" SOFATracer 集成在 SOFARPC(5.4.0及之后的版本) 后输出链路数据的格式，默认为 JSON 数据格式，具体的字段含义解释如下：\nRPC 客户端 摘要日志（ rpc-client-digest.log） 日志打印时间 TraceId SpanId Span 类型 当前 appName 协议类型(bolt,rest) 服务接口信息 方法名 当前线程名 调用类型(sync,callback,oneway,future) 路由记录(DIRECT,REGISTRY) 目标ip 目标 appName 本机ip 返回码(00=成功/01=业务异常/02=RPC逻辑错误/03=超时失败/04=路由失败) 请求序列化时间(单位ms) 响应反序列化时间(单位ms) 响应大小(单位Byte) 请求大小(单位Byte) 客户端连接耗时(单位ms) 调用总耗时(单位ms) 本地客户端端口 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;samples\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 服务端 摘要日志（ rpc-server-digest.log） 日志打印时间 TraceId SpanId Span 类型 服务接口信息 方法名 来源ip 来源 appName 协议(bolt,rest) 当前 appName 当前线程名 返回码(00=成功/01=业务异常/02=RPC逻辑错误) 服务端线程池等待时间(单位ms) 业务处理耗时(单位ms) 响应序列化时间(单位ms) 请求反序列化时间(单位ms) 响应大小(单位Byte) 请求大小(单位Byte) 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:00:53.312\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526806853032100185011\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SOFA-BOLT-BIZ-12200-5-T1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;server.pool.wait.time\u0026amp;quot;:\u0026amp;quot;3\u0026amp;quot;,\u0026amp;quot;biz.impl.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;resp.serialize.time\u0026amp;quot;:\u0026amp;quot;4\u0026amp;quot;,\u0026amp;quot;req.deserialize.time\u0026amp;quot;:\u0026amp;quot;38\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 客户端 统计日志（ rpc-client-stat.log） 日志打印时间 日志关键key 方法信息 客户端 appName 服务接口信息 调用次数 总耗时(单位ms) 调用结果(Y/N) 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-05-18 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-sofarpc/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ad45177e2719b9a22f4bfb07a0481905","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","summary":"SOFATracer 集成在 SOFARPC(5.4.0及之后的版本) 后输出链路数据的格式，默认为 JSON 数据格式，具体的字段含义解释如下： RPC 客户端 摘要日志（ rpc-c","tags":null,"title":"SOFARPC 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","wordcount":705},{"author":null,"categories":null,"content":"SOFARPC already supports using SOFARegistry as a service registry. Suppose you have deployed SOFARegistry Server locally according to SOFARegistry\u0026amp;rsquo;s Quick Start, and the service discovery port is set to 9603 by default.\nTo use SOFARegistry as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 The current version of SOFARegistry is supported:\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\nBecause of the time of SOFABoot, users need to specify the version of rpc starter.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFARPC integration verification SOFARegistry server version: 5.2.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-sofa/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"65085018ce2b2b2ef452993bb79a69de","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","summary":"SOFARPC already supports using SOFARegistry as a service registry. Suppose you have deployed SOFARegistry Server locally according to SOFARegistry\u0026rsquo;s Quick Start, and the service discovery port is set to 9603 by default.\nTo use SOFARegistry as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 The current version of SOFARegistry is supported:\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\nBecause of the time of SOFABoot, users need to specify the version of rpc starter.","tags":null,"title":"SOFARegistry","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","wordcount":90},{"author":null,"categories":null,"content":" Product introduction SOFARegistry is a production-level, low-latency, and highly available service registry powered by Ant Financial. SOFARegistry was developed on the basis ConfigServer of Taobao. After more than ten years of business development of Ant Financial, SOFARegistry has evolved into the fifth generation architecture. Currently, SOFARegistry not only provides full support to Ant Financial and its numerous partners, but also embraces the open source community. Built on an AP architecture, SOFARegistry support s message push in seconds. It also adopts a layered architecture to support infinite horizontal scaling.\nFeatures High scalability SOFARegistry adopts a layered architecture and partition-based data storage to break the single machine performance and capacity bottleneck, and to support the theoretical \u0026amp;ldquo;infinite horizontal scaling\u0026amp;rdquo;. It has been providing reliable services to the Ant Financial production environment which has a massive number of nodes and services.\nLow latency By virtue of the SOFABolt communication framework, SOFARegistry implements TCP long connection-based heartbeat detection among nodes, and the customized push mode to send service messages between upstream and downstream nodes in seconds.\nHighly available Unlike CP-architecture based registry products such as ZooKeeper, Consul, and Etcd, SOFARegistry adopts the AP architecture based on the service characteristics of service discovery, which significantly improves the availability of the registry in the case of failures caused by network partitioning. SOFARegistry takes many measures, such as multi-replica clusters, to prevent service unavailability arising from node failures.\nArchitecture SOFARegistry has four roles: Client, SessionServer, DataServer, and MetaServer, each with unique capabilities and responsibilities. They are combined to provide external services. The relationships and structures of them are explained as follows.\nClient A client provides basic APIs to allow applications to access SOFARegistry. The client provides JAR packages to application systems, so that they can call the service subscription and publishing features of SOFARegistry.\nSessionServer The SessionServer grants clients access to SessionServer, and accepts service publishing and subscription requests from clients. It also serves as an intermediate layer to forward the published data to DataServer for storage. The SessionServer can be infinitely scaled up to support connection with large amounts of clients.\nDataServer The DataServer is responsible for storing data published by clients. The data is stored by dataId through consistent hashing. DataServer supports multi-replica backup to ensure high availability of the data. The Data can also be infinitely scaled up to support large amounts of data.\nMetaServer The MetaServer is responsible for maintaining the consistency lists of the SessionServer and DataServer within the cluster, and immediately notify other nodes in the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d444761f1ad8b0c52e3505926176b13f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/overview/","summary":"Product introduction SOFARegistry is a production-level, low-latency, and highly available service registry powered by Ant Financial. SOFARegistry was developed on the basis ConfigServer of Taobao. After more than ten years of business development of Ant Financial, SOFARegistry has evolved into the fifth generation architecture. Currently, SOFARegistry not only provides full support to Ant Financial and its numerous partners, but also embraces the open source community. Built on an AP architecture, SOFARegistry support s message push in seconds.","tags":null,"title":"SOFARegistry overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/overview/","wordcount":429},{"author":null,"categories":null,"content":" 项目简介 SOFARegistry 是蚂蚁集团开源的一个生产级、高时效、高可用的服务注册中心。SOFARegistry 最早源自于淘宝的 ConfigServer，十年来，随着蚂蚁金服的业务发展，注册中心架构已经演进至第六代。目前 SOFARegistry 不仅全面服务于蚂蚁集团的自有业务，还随着蚂蚁金融科技服务众多合作伙伴，同时也兼容开源生态。SOFARegistry 采用 AP 架构，支持秒级时效性推送，同时采用分层架构支持无限水平扩展。\n产品特点 高可扩展性 采用分层架构、数据分片存储等方式，突破单机性能与容量瓶颈，接近理论上的“无限水平扩展”。经受过蚂蚁集团生产环境海量节点数与服务数的考验。\n高时效性 借助 SOFABolt 通信框架，实现基于 TCP 长连接的节点判活与推模式的变更推送，服务上下线通知时效性在秒级以内。\n高可用性 不同于 Zookeeper、Consul、Etcd 等 CP 架构注册中心产品，SOFARegistry 针对服务发现的业务特点，采用 AP 架构，最大限度地保证网络分区故障下注册中心的可用性。通过集群多副本等方式，应对自身节点故障。\n架构 服务注册中心分为四个角色，客户端（Client）、会话服务器（SessionServer）、数据服务器（DataServer）、元数据服务器（MetaServer），每个角色司职不同能力组合后共同提供对外服务能力，各部分关系和结构如下：\nClient 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\nSessionServer 会话服务器，提供客户端接入能力，接受客户端的服务发布及服务订阅请求，并作为一个中间层将发布数据转发 DataServer 存储。SessionServer 可无限扩展以支持海量客户端连接。\nDataServer 数据服务器，负责存储客户端发布数据，数据存储按照数据 ID 进行一致性 hash 分片存储，支持多副本备份，保证数据高可用。DataServer 可无限扩展以支持海量数据量。\nMetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，在节点变更时及时通知集群内其他节点。MetaServer 通过 SOFAJRaft 保证高可用和一致性。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/overview/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d444761f1ad8b0c52e3505926176b13f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/overview/","summary":"项目简介 SOFARegistry 是蚂蚁集团开源的一个生产级、高时效、高可用的服务注册中心。SOFARegistry 最早源自于淘宝的 ConfigServer，十年来","tags":null,"title":"SOFARegistry 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-registry/overview/","wordcount":838},{"author":null,"categories":null,"content":" SOFAStack-Demos 分布式链路组件 SOFATracer 埋点机制 Demo Demo 地址：https://github.com/glmapper/tracers-guides 相关文章：https://www.sofastack.tech/blog/sofa-channel-15-retrospect/ 云原生网络代理 MOSN 扩展机制：MOSN Stream Filter 操作 Demo Demo：https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions Demo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions 操作视频：https://www.bilibili.com/video/BV1SQ4y1K7iw 相关文章：https://www.sofastack.tech/blog/sofa-channel-14-retrospect/ 云原生网络代理 MOSN 多协议机制：接入 SOFABolt 操作 Demo Demo 地址：https://github.com/mosn/mosn/tree/master/examples/codes/sofarpc-with-xprotocol-sample 操作视频：https://www.bilibili.com/video/BV1UZ4y1x7Sj 相关文章：https://www.sofastack.tech/blog/sofa-channel-13-retrospect/ 轻量级类隔离容器 SOFAArk 动态模块操作 Demo Demo：https://github.com/caojie09/sofachannel-demo 操作视频：https://www.bilibili.com/video/BV1wQ4y1T7rt 相关文章：https://www.sofastack.tech/blog/sofa-channel-11-retrospect/ 分布式事务 Seata 长事务解决方案 Saga 模式可视化状态机 Seata Saga 可视化状态机设计器演示地址： http://seata.io/saga_designer/index.html Seata Saga 可视化状态机设计器代码以及运行指南： https://github.com/seata/seata/tree/develop/saga/seata-saga-statemachine-designer 相关文章：https://www.sofastack.tech/blog/sofa-channel-10-retrospect/ SOFAJRaft 的 Counter 例子 Demo Demo 地址：https://www.sofastack.tech/projects/sofa-jraft/counter-example/ 相关文章：https://www.sofastack.tech/blog/sofa-channel-8-retrospect/ 轻量级监控分析系统 SOFALookout 客户端的相关演示操作 Demo Demo 地址：https://github.com/sofastack/sofa-lookout/tree/master/samples/metrics/client 相关文章https://www.sofastack.tech/blog/sofa-channel-6-retrospect/ SOFARPC 内存优化操作 Demo Demo 地址：https://github.com/leizhiyuan/rpcchannel 相关文章：https://www.sofastack.tech/blog/sofa-channel-3-retrospect/ ","date":-62135596800,"description":"本指南为 SOFAStack 多个组件的 Demo 合集。","dir":"guides/sofastack-demos/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6a1fada81ea88116efa0e30539da60a1","permalink":"https://sofastack.github.io/sofastack.tech/guides/sofastack-demos/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/sofastack-demos/","summary":"SOFAStack-Demos 分布式链路组件 SOFATracer 埋点机制 Demo Demo 地址：https://github.com/glmapper/tracers-guides 相关文章：https","tags":null,"title":"SOFAStack Demos","type":"guides","url":"/sofastack.tech/guides/sofastack-demos/","wordcount":1353},{"author":null,"categories":null,"content":" Since SOFARPC 5.4.0, the SOFATracer function is integrated, which is enabled by default. It can output the data information in the link.\nBy default, the output data is in JSON format. The involved fields are as follows:\nRPC client digest Log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type Service interface information Method name Current thread name Calling type Routing record Target IP Local machine IP Return code Request serialization duration Response deserialization duration Response size (in Byte) Request size (in Byte) Client connection duration Total duration for call Local client port Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC server digest log (rpc-server-digest.log) Log printing time TraceId SpanId Span type Service interface information Method name Source IP Source appName Protocol Local appName Current thread name Return code Server thread pool waiting time Business processing duration Response serialization duration Request deserialization duration Response size (in Byte) Request size (in Byte) Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/sofatracer-usage/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dde9dc7a759b7c0c272d67bac1b315d4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","summary":"Since SOFARPC 5.4.0, the SOFATracer function is integrated, which is enabled by default. It can output the data information in the link.\nBy default, the output data is in JSON format. The involved fields are as follows:\nRPC client digest Log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type Service interface information Method name Current thread name Calling type Routing record Target IP Local machine IP Return code Request serialization duration Response deserialization duration Response size (in Byte) Request size (in Byte) Client connection duration Total duration for call Local client port Transparently transmitted baggage data (kv format) Example:","tags":null,"title":"SOFATracer","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","wordcount":222},{"author":null,"categories":null,"content":" SOFATracer Tools Get Span through SOFATracer context In the process of a distributed link call, the component that integrates SOFATracer generates a Span and caches it in the SOFATracer context. And the context is cached in ThreadLocal. You can get the current SOFATracer context in the following way:\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); Through the SOFATracer context SofaTraceContext, you can add, delete, modify, check, and empty the cached Spans. As the developers responsible for integrating components, we will add, delete, modify and check the SOFATracer context to integrate distributed link tracking. However, as the application developer to directly use SOFATracer, you only need to get the corresponding Span. That is to say, you only need to use the following method after getting the context:\nSofaTracerSpan sofaTracerSpan = sofaTraceContext.getCurrentSpan(); Get information through Span When using the SOFATracer plugin component, such as Spring MVC, the component integrates the capabilities of SOFATracer. So it can get all the information in the Span after getting Span. The specific acquisition method example (it demands that Span is not empty, namely that the corresponding component has integrated SOFATracer) is as follow:\nGet TraceId and SpanId: SofaTracerSpanContext sofaTracerSpanContext = currentSpan.getSofaTracerSpanContext(); String traceId = sofaTracerSpanContext.getTraceId(); String spanId = sofaTracerSpanContext.getSpanId(); Get Tags and Logs in OpenTracing specification Get Tags:\nMap\u0026amp;lt;String, String\u0026amp;gt; tagsStr = sofaTracerSpan.getTagsWithStr(); Map\u0026amp;lt;String, Boolean\u0026amp;gt; tagsBool = sofaTracerSpan.getTagsWithBool(); Map\u0026amp;lt;String, Number\u0026amp;gt; tagsNumber = sofaTracerSpan.getTagsWithNumber(); Get Logs:\nList \u0026amp;lt;LogData\u0026amp;gt; logDataList = sofaTracerSpan.getLogs (); Process transparently transmitted data Baggage element is a collection of key-value pairs that carries data to be transparently transmitted. In SOFATracer, Baggage data is divided into sysBaggage and bizBaggage; sysBaggage mainly refers to transparently transmitted system data, and bizBaggage mainly refers to transparently transmitted business data.\nConfigure and get BaggageItem BaggageItem is a data element in the Baggage collection.\n Configure the corresponding BaggageItem data through the standard interface: String baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageVal = \u0026amp;quot;val\u0026amp;quot;; sofaTracerSpan.setBaggageItem(baggageKey,baggageVal); Get the corresponding BaggageItem data through the standard interface: String baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageValue = sofaTracerSpan.getBaggageItem(baggageKey); Note: Configuring and getting Baggage data through the standard interface is actually operated on bizBaggage.\nConfigure and get \u0026amp;lsquo;Baggage\u0026amp;rsquo; data 1, Configure \u0026amp;lsquo;Baggage\u0026amp;rsquo; data\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggage …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/utils/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d40318a5bd3ee5e1573f8770ea649dba","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/utils/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/utils/","summary":"SOFATracer Tools Get Span through SOFATracer context In the process of a distributed link call, the component that integrates SOFATracer generates a Span and caches it in the SOFATracer context. And the context is cached in ThreadLocal. You can get the current SOFATracer context in the following way:\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); Through the SOFATracer context SofaTraceContext, you can add, delete, modify, check, and empty the cached Spans. As the developers responsible for integrating components, we will add, delete, modify and check the SOFATracer context to integrate distributed link tracking.","tags":null,"title":"SOFATracer Tools","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/utils/","wordcount":443},{"author":null,"categories":null,"content":" SOFATracer configuration item After introducing SOFATracer, you can add related configuration items in Spring Boot configuration file application.properties to customize the behaviors of SOFATracer.\nFor SOFATracer log output directory, you can configure logging.path in application.properties, then the log output path is ${logging.path}/tracelog; if logging.path is not configured, the default output path is ${user.home}/logs/tracelog.\n Configuration item Description Default value logging.path log output directory SOFATracer output logs to logging.path directory in priority; If the directory is not configured, log will be output to ${user.home} by default. com.alipay.sofa.tracer.disableDigestLog Disable all integrated SOFATracer summary log printing false com.alipay.sofa.tracer.disableConfiguration[${logType}] Disable specific SOFATracer summary log printing of ${logType}. ${logType} indicates the log type, such as spring-mvc-digest.log false com.alipay.sofa.tracer.tracerGlobalRollingPolicy SOFATracer log rolling policy yyyy-MM-dd：roll by day；yyyy-MM-dd_HH：roll by hour;Logs are not rolled by day by default. com.alipay.sofa.tracer.tracerGlobalLogReserveDay Retention days of SOFATracer logs Retained for 7 days by default. com.alipay.sofa.tracer.statLogInterval Time interval of statistical logs, unit: second Output statistical logs once every 60 seconds by default com.alipay.sofa.tracer.baggageMaxLength Maximum length for retaining penetration data Default: 1024 com.alipay.sofa.tracer.zipkin.enabled Whether to enable SOFATracer remote data reporting to Zipkin true: enable; false: disable. Disabled by default. com.alipay.sofa.tracer.zipkin.baseUrl The address Zipkin address to which SOFATracer remotely reports data, which works only in the case of com.alipay.sofa.tracer.zipkin.enabled=true Format: http: //${host}:${port} com.alipay.sofa.tracer.springmvc.filterOrder Order validated by SOFATrace Filter intergrated in SpringMVC -2147483647(org.springframework.core.Ordered#HIGHEST_PRECEDENCE + 1) com.alipay.sofa.tracer.springmvc.urlPatterns URL Pattern paths validated by SOFATrace Filter intergrated in SpringMVC /*: All validated ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/configuration/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1a6bf2b7aa168440544f8d0d69358869","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/configuration/","summary":"SOFATracer configuration item After introducing SOFATracer, you can add related configuration items in Spring Boot configuration file application.properties to customize the behaviors of SOFATracer.\nFor SOFATracer log output directory, you can configure logging.path in application.properties, then the log output path is ${logging.path}/tracelog; if logging.path is not configured, the default output path is ${user.home}/logs/tracelog.\n Configuration item Description Default value logging.path log output directory SOFATracer output logs to logging.","tags":null,"title":"SOFATracer configuration items","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/configuration/","wordcount":231},{"author":null,"categories":null,"content":" SOFATracer is a distributed link tracing system based on OpenTracing specification developed by Ant Financial. Its core concept is to concatenate the same request distributed on each service node with a global TraceId. By the unified TraceId, it can record the various network call information in the call link in logs, and can remotely report the call records to Zipkin for presentation, thus implementing perspective network call.\nFeatures Distributed link tracing solution based on OpenTracing specification SOFATracer is a solution that provides link tracing based on and improved from the OpenTracing specification. Based on this implementation, each framework or component can provide the ability to link tracking by burying points.\nProvide asynchronous log printing to disks Based on high-performance lock-free loop queue of Disruptor, SOFATracer provides the ability to print logs asynchronously to local disk. The introduced framework or component can customize the output format of the log file under the premise of asynchronous log printing. SOFATracer provides two types of logs, digest log and statistical log. Digest log: logs that are printed to disk upon each call. Statistical log: logs that are printed at regular intervals.\nSupport automatic log cleanup and scrolling Asynchronous SOFATracer log supports automatic cleanup and scrolling, and supports cleaning by day and scrolling by hour or day.\nExtended based on SLF4J MDC SLF4J provides MDC (Mapped Diagnostic Contexts), which supports user to define and modify the output log format and content. SOFATracer integrates the SLF4J MDC function, which allows user to output the TraceId and SpanId of the current Tracer context by simply modifying the log configuration file.\nInterface presentation SOFATracer can remotely report link tracing data to the open-source product Zipkin for distributed link tracing presentation.\nUnified configuration The profile file provides various configuration options for you to customize the individual requirements of the application.\nScenario SOFATracer solves the problem of link tracing when implementing large-scale microservice architecture, achieves perspective network call, and can be used to rapidly Failures Discovery, Service Governance, and so on.\nComponent event tracking At present, SOFATracer supports Spring MVC, database connection pool (DBCP, Druid, c3p0, tomcat, HikariCP, BoneCP) acheived by standard JDBC interface, HttpClient and other open-source components. Event tracking for other open-source components (such as MQ, Redis) is still in development.\n Component Document Version Spring MVC doc link 2.1.0 DBCP doc link 2.2.0 Druid doc link 2.2.0 C3p0 doc link 2.2.0 HikariCP doc link 2.2.0 HttpClient doc link 2.2.0 RestTemplate doc link 2.3.0 OkHttp doc link 2.3.2 Dubbo doc link 2.4.0 OpenFeign doc link 3.0.4 Redis TODO MQ TODO ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e8d6bf5eec6c5ce1e41d461743f2c4f1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/overview/","summary":"SOFATracer is a distributed link tracing system based on OpenTracing specification developed by Ant Financial. Its core concept is to concatenate the same request distributed on each service node with a global TraceId. By the unified TraceId, it can record the various network call information in the call link in logs, and can remotely report the call records to Zipkin for presentation, thus implementing perspective network call.\nFeatures Distributed link tracing solution based on OpenTracing specification SOFATracer is a solution that provides link tracing based on and improved from the OpenTracing specification.","tags":null,"title":"SOFATracer overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/overview/","wordcount":421},{"author":null,"categories":null,"content":" SOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n功能描述 基于 OpenTracing 规范提供分布式链路跟踪解决方案 基于 OpenTracing 规范 并扩展其能力提供链路跟踪的解决方案。各个框架或者组件可以基于此实现，通过在各个组件中埋点的方式来提供链路跟踪的能力。\n提供异步落地磁盘的日志打印能力 基于 Disruptor 高性能无锁循环队列，提供异步打印日志到本地磁盘的能力。框架或者组件能够在接入时，在异步日志打印的前提下可以自定义日志文件的输出格式。SOFATracer 提供两种类似的日志打印类型即摘要日志和统计日志，摘要日志：每一次调用均会落地磁盘的日志；统计日志：每隔一定时间间隔进行统计输出的日志。\n支持日志自清除和滚动能力 异步落地磁盘的 SOFATracer 日志支持自清除和滚动能力，支持按照按照天清除和按照小时或者天滚动的能力\n基于 SLF4J MDC 的扩展能力 SLF4J 提供了 MDC（Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。SOFATracer 集成了 SLF4J MDC 功能，方便用户在只简单修改日志配置文件即可输出当前 Tracer 上下文的 TraceId 和 SpanId。\n界面展示能力 SOFATracer 可以将链路跟踪数据远程上报到开源产品 Zipkin 做分布式链路跟踪的展示。\n统一配置能力 配置文件中提供丰富的配置能力以定制化应用的个性需求。\n应用场景 解决在实施大规模微服务架构时的链路跟踪问题，达到透视化网络调用的目的，并可用于故障的快速发现，服务治理等。\n组件埋点 目前 SOFATracer 支持 Spring MVC、标准 JDBC 接口实现的数据库连接池(DBCP、Druid、c3p0、tomcat、HikariCP、BoneCP)、HttpClient、Dubbo、Spring Cloud OpenFeign 等开源组件，其他开源组件（如 MQ、Redis）埋点支持在开发中。\n 支持组件 接入文档 支持版本 Spring MVC doc link 2.1.0 DBCP doc link 2.2.0 Druid doc link 2.2.0 c3p0 doc link 2.2.0 HikariCP doc link 2.2.0 HttpClient doc link 2.2.0 OkHttp doc link 2.3.2 Dubbo doc link 2.4.0 Redis TODO MQ TODO ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/overview/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e8d6bf5eec6c5ce1e41d461743f2c4f1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/overview/","summary":"SOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调","tags":null,"title":"SOFATracer 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/overview/","wordcount":843},{"author":null,"categories":null,"content":" 通过 SOFATracer 上下文获取 Span 在一次分布式链路调用过程中，在集成了 SOFATracer 的组件会产生一个 Span 并会缓存到 SOFATracer 的上下文中，这个上下文是缓存在 ThreadLocal 中的，作为使用者可以通过如下的方式随时获取到当前 SOFATracer 的上下文：\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); SOFATracer 上下文 SofaTraceContext 通过这个实例，可以对其缓存的 Span 执行增、删、改、查和清空操作。作为组件集成的同学在集成过程中我们会对 SOFATracer 上下文做增、删、改和查等操作来集成分布式链路跟踪的能力；但是作为直接使用 SOFATracer 的应用开发者，我们只需要能够获取相应的 Span 即可，即只需要在获取上下文后使用如下的方法：\nSofaTracerSpan sofaTracerSpan = sofaTraceContext.getCurrentSpan(); 通过 Span 获取信息 在使用相应的组件如 Spring MVC 时，该组件集成了 SOFATracer 的能力后可以在获取到 Span 后获取到 Span 中的所有信息，具体获取方式示例（前提 Span 不为空即相应组件已经集成 SOFATracer）：\n获取 TraceId 和 SpanId ： SofaTracerSpanContext sofaTracerSpanContext = currentSpan.getSofaTracerSpanContext(); String traceId = sofaTracerSpanContext.getTraceId(); String spanId = sofaTracerSpanContext.getSpanId(); 获取 OpenTracing 规范中的 Tags 和 Logs 获取 Tags:\nMap\u0026amp;lt;String, String\u0026amp;gt; tagsStr = sofaTracerSpan.getTagsWithStr(); Map\u0026amp;lt;String, Boolean\u0026amp;gt; tagsBool = sofaTracerSpan.getTagsWithBool(); Map\u0026amp;lt;String, Number\u0026amp;gt; tagsNumber = sofaTracerSpan.getTagsWithNumber(); 获取 Logs:\nList\u0026amp;lt;LogData\u0026amp;gt; logDataList = sofaTracerSpan.getLogs(); 透传数据处理 Baggage 元素是一个键值对集合，其携带的是需要透传的数据。SOFATracer 中将 Baggage 数据分为 sysBaggage 和 bizBaggage；sysBaggage 主要是指系统维度的透传数据，bizBaggage 主要是指业务的透传数据。\n设置和获取 BaggageItem BaggageItem 是 Baggage集合中的数据元素。\n1、通过标准接口设置相应的 BaggageItem 数据：\nString baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageVal = \u0026amp;quot;val\u0026amp;quot;; sofaTracerSpan.setBaggageItem(baggageKey,baggageVal); 2、通过标准接口获取相应的 BaggageItem 数据：\nString baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageValue = sofaTracerSpan.getBaggageItem(baggageKey); 注：当通过标准接口进行设置和获取 Baggage 数据时，实际上操作的对象均为 bizBaggage\n设置和获取 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据 1、设置 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggage = new HashMap\u0026amp;lt;String, String\u0026amp;gt;(); bizBaggage.put(\u0026amp;quot;bizKey\u0026amp;quot;,\u0026amp;quot;bizVal\u0026amp;quot;); sofaTracerSpanContext.addBizBaggage(bizBaggage); Map\u0026amp;lt;String, String\u0026amp;gt; sysBaggage = new HashMap\u0026amp;lt;String, String\u0026amp;gt;(); sysBaggage.put(\u0026amp;quot;sysKey\u0026amp;quot;,\u0026amp;quot;sysVal\u0026amp;quot;); sofaTracerSpanContext.addSysBaggage(sysBaggage); 2、获取 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); //获取 bizBaggage Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggages = sofaTracerSpanContext.getBizBaggage(); //获取 sysBaggage Map\u0026amp;lt;String, String\u0026amp;gt; sysBaggages = sofaTracerSpanContext.getSysBaggage(); 遍历 Baggage 数据 OpenTracing 规范中 SpanContext 接口提供了 baggageItems() 方法，可以通过这个方法来遍历所有的 baggage 元素。SOFATracer 在 SofaTracerSpanContext 类中对 baggageItems() 方法进行了具体实现。\nIterable\u0026amp;lt;Map.Entry\u0026amp;lt;String, String\u0026amp;gt;\u0026amp;gt; entrySet = sofaTracerSpanContext.baggageItems(); 注：遍历 Baggage 数据返回的是 sysBaggage 和 bizBaggage 的合集。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/utils/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d40318a5bd3ee5e1573f8770ea649dba","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/utils/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/utils/","summary":"通过 SOFATracer 上下文获取 Span 在一次分布式链路调用过程中，在集成了 SOFATracer 的组件会产生一个 Span 并会缓存到 SOFATracer 的上下文中，这个上下文是缓存在 ThreadLocal 中的，作为使用者可以通","tags":null,"title":"SOFATracer 工具类","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/utils/","wordcount":738},{"author":null,"categories":null,"content":" 应用在引入 SOFATracer 后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 SOFATracer 的相关行为。\nSOFATracer 的日志输出目录，可以在 application.properties 中配置 logging.path 的路径，那么其日志输出路径为 ${logging.path}/tracelog；如果没有配置 logging.path，那么 SOFATracer 的默认输出路径为 ${user.home}/logs/tracelog。\nSpringBoot 工程配置 SOFATracer 配置项 说明 默认值 logging.path 日志输出目录 SOFATracer 会优先输出到 logging.path 目录下；如果没有配置日志输出目录，那默认输出到 ${user.home} com.alipay.sofa.tracer.disableDigestLog 是否关闭所有集成 SOFATracer 组件摘要日志打印 false com.alipay.sofa.tracer.disableConfiguration[${logType}] 关闭指定 ${logType} 的 SOFATracer 组件摘要日志打印。${logType}是指具体的日志类型，如：spring-mvc-digest.log false com.alipay.sofa.tracer.tracerGlobalRollingPolicy SOFATracer 日志的滚动策略 .yyyy-MM-dd：按照天滚动；.yyyy-MM-dd_HH：按照小时滚动。默认不配置按照天滚动 com.alipay.sofa.tracer.tracerGlobalLogReserveDay SOFATracer 日志的保留天数 默认保留 7 天 com.alipay.sofa.tracer.statLogInterval 统计日志的时间间隔，单位：秒 默认 60 秒统计日志输出一次 com.alipay.sofa.tracer.baggageMaxLength 透传数据能够允许存放的最大长度 默认值 1024 com.alipay.sofa.tracer.zipkin.enabled 是否开启 SOFATracer 远程上报数据到 Zipkin true：开启上报；false：关闭上报。默认不上报 com.alipay.sofa.tracer.zipkin.baseUrl SOFATracer 远程上报数据到 Zipkin 的地址，com.alipay.sofa.tracer.zipkin.enabled=true时配置此地址才有意义 格式：http://${host}:${port} com.alipay.sofa.tracer.springmvc.filterOrder SOFATracer 集成在 SpringMVC 的 Filter 生效的 Order -2147483647（org.springframework.core.Ordered#HIGHEST_PRECEDENCE + 1） com.alipay.sofa.tracer.springmvc.urlPatterns SOFATracer 集成在 SpringMVC 的 Filter 生效的 URL Pattern 路径 /* 全部生效 com.alipay.sofa.tracer.jsonOutput 是否以json格式输出日志 true，如果期望较少日志空间占用，可以使用非 json 格式输出（日志顺序与JSON 格式顺序一致） 非SpringBoot 工程配置 在非 SpringBoot 工程中，可以通过在 classpath 下新建一个 sofa.tracer.properties 配置文件，配置项如下：\n SOFATracer 配置项 说明 默认值 disable_middleware_digest_log 是否关闭中间件组件摘要日志打印 false disable_digest_log 关闭摘要日志打印。 false tracer_global_rolling_policy SOFATracer 日志的滚动策略 .yyyy-MM-dd：按照天滚动；.yyyy-MM-dd_HH：按照小时滚动。默认不配置按照天滚动 tracer_global_log_reserve_day SOFATracer 日志的保留天数 默认保留 7 天 stat_log_interval 统计日志的时间间隔，单位：秒 默认 60 秒统计日志输出一次 tracer_penetrate_attribute_max_length 透传数据能够允许存放的最大长度 默认值 1024 tracer_async_appender_allow_discard 是否允许丢失日志 false tracer_async_appender_is_out_discard_number 丢失日志数 0 spring.application.name 应用名 `` tracer_sampler_strategy_name_key 采样策略名 `` tracer_sampler_strategy_custom_rule_class_name 采样规则 spi 实现的类的全限定名 `` tracer_sampler_strategy_percentage_key 采样比率 com.alipay.sofa.tracer.jsonOutput 是否以json格式输出日志 true，如果期望较少日志空间占用，可以使用非 json 格式输出（日志顺序与JSON 格式顺序一致） ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/configuration/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1a6bf2b7aa168440544f8d0d69358869","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-tracer/configuration/","summary":"应用在引入 SOFATracer 后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 SOFATracer 的相关行为。 SOFATracer 的日志输出目录，可以在 application.properties 中配置 logging.path 的路径，那么其日志输出路径为 ${","tags":null,"title":"SOFATracer 配置项","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/configuration/","wordcount":1004},{"author":null,"categories":null,"content":" 在SOFARPC(5.4.0及之后的版本) 后的版本中，我们集成了SOFATracer的功能，默认开启，可以输出链路中的数据信息。\n默认为 JSON 数据格式，具体的字段含义解释如下：\nRPC 客户端 摘要日志（ rpc-client-digest.log） 日志打印时间 TraceId SpanId Span 类型 当前 appName 协议类型 服务接口信息 方法名 当前线程名 调用类型 路由记录 目标ip 本机ip 返回码 请求序列化时间 响应反序列化时间 响应大小(单位Byte) 请求大小(单位Byte) 客户端连接耗时 调用总耗时 本地客户端端口 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 服务端 摘要日志（ rpc-server-digest.log） 日志打印时间 TraceId SpanId Span 类型 服务接口信息 方法名 来源ip 来源 appName 协议 本应用 appName 当前线程名 返回码 服务端线程池等待时间 业务处理耗时 响应序列化时间 请求反序列化时间 响应大小(单位Byte) 请求大小(单位Byte) 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:00:53.312\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526806853032100185011\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SOFA-BOLT-BIZ-12200-5-T1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;server.pool.wait.time\u0026amp;quot;:\u0026amp;quot;3\u0026amp;quot;,\u0026amp;quot;biz.impl.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;resp.serialize.time\u0026amp;quot;:\u0026amp;quot;4\u0026amp;quot;,\u0026amp;quot;req.deserialize.time\u0026amp;quot;:\u0026amp;quot;38\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/sofatracer-usage/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dde9dc7a759b7c0c272d67bac1b315d4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","summary":"在SOFARPC(5.4.0及之后的版本) 后的版本中，我们集成了SOFATracer的功能，默认开启，可以输出链路中的数据信息。 默认为 JSON 数据","tags":null,"title":"SOFATracer 链路追踪","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","wordcount":529},{"author":null,"categories":null,"content":" Sampling Currently,SOFATracer provides two sampling modes. One is the fixed sampling rate based on BitSet. The other is the sampling provided to the user to customize the implementation sampling.The following example shows how to use it.\nThis example is based on the tracer-sampled-with-springmvc project,Except for application.properties, everything else is the same.\nSampling mode based on fixed sampling rate Add sampling related configuration items in application.properties #Sampling rate 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #Sampling type name com.alipay.sofa.tracer.samplerName=PercentageBasedSampler Verification When the sample rate is set to 100, the digest log is printed each time. When the sample rate is set to 0, the digest log is not printed. Print by probability when the sampling rate is set between 0 and 100. The result is verified by requesting 10 times.\n1、When the sample rate is set to 100, the digest log is printed each time.\nStart the project and enter in the browser:http://localhost:8080/springmvc ,And refresh the address 10 times, check the log as follows:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:47.643\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173568757510019269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:68,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:50.980\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569097710029269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:51.542\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569153910049269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-4\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/sampler/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"48856a040da01abc84213934c1c5fce4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/sampler/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/sampler/","summary":"Sampling Currently,SOFATracer provides two sampling modes. One is the fixed sampling rate based on BitSet. The other is the sampling provided to the user to customize the implementation sampling.The following example shows how to use it.\nThis example is based on the tracer-sampled-with-springmvc project,Except for application.properties, everything else is the same.\nSampling mode based on fixed sampling rate Add sampling related configuration items in application.properties #Sampling rate 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #Sampling type name com.","tags":null,"title":"Sampling modes","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/sampler/","wordcount":426},{"author":null,"categories":null,"content":" 1. Integrated deployment 1.1 Scale up registry-integration Assume that three registry-integration servers have been deployed currently, which are namely node1, node2, and node 3. The new node to be added to the cluster is node 4.\nOperation steps:\nStep 1. Deploy the new registry-integration node\nFirst, deploy registry-integration.tgz on node4 by referencing the Deployment topic. Note that you need to set the nodes.metaNode configuration item on node4 to a 4-server endpoint list:\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt; In this step, after node4 is started, visit curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check. The status will be unhealthy, because node4 has not been added to the cluster yet. To add it to the cluster, perform the next step.\nStep 2. Call the changePeer operation to add a new node to a cluster\nRun the changePeer command on one of the existing servers (node1, node2, and node3), to modify the current cluster from a three-node cluster (node1, node2, and node3) to a four-node cluster (node1, node2, node3, and node4):\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt;\u0026amp;quot; After completing this step, visit curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check. The status will be healthy.\n1.2 Scale down registry-integration Assume that you have three servers in one cluster, which are respectively node1, node2, and node3, and you want to scale down node3.\n1.2.1 Smooth scale-down Operation steps:\nStep 1. Call the changePeer operation to remove a node\nRun the changePeer command on either node1 or node2 to change the cluster list from \u0026amp;ldquo;node1, node2, node3\u0026amp;rdquo; to \u0026amp;ldquo;node1,node2\u0026amp;rdquo;. This removes node3 from the endpoint list of the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; After completing this step, visit curl http://\u0026amp;lt;node3\u0026amp;gt;:9615/health/check. The status will be unhealthy, because node3 has already been removed from the cluster.\nStep 2. Close node3\nThis step is optional, because node3 has already been removed from the cluster, and it does not affect the cluster even if it is still running.\n1.2.2 Handling of node failure If node3 is no longer functional, you need to remove it from the cluster.\nOperation steps:\nStep 1. Call the changePeer operation to remove a node\nRun the changePeer command on either node1 or node2 to change the cluster list from \u0026amp;ldquo;node1, node2, node3\u0026amp;rdquo; to \u0026amp;ldquo;node1,node2\u0026amp;rdquo;. This removes node3 from the endpoint list of the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 2. Independent deployment 2.1 Scale up registry-meta Assume that you have already deployed three registry-meta servers, which are respectively metaNode1, metaNode2, and metaNode3. The new node to be added to the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/scale/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"57de6dc4da1292063ff25ecea9ffbd08","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/scale/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/scale/","summary":"1. Integrated deployment 1.1 Scale up registry-integration Assume that three registry-integration servers have been deployed currently, which are namely node1, node2, and node 3. The new node to be added to the cluster is node 4.\nOperation steps:\nStep 1. Deploy the new registry-integration node\nFirst, deploy registry-integration.tgz on node4 by referencing the Deployment topic. Note that you need to set the nodes.metaNode configuration item on node4 to a 4-server endpoint list:","tags":null,"title":"Scaling","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/scale/","wordcount":954},{"author":null,"categories":null,"content":" Quickly understand ACTS scripts Do you have to frequently compile test cases? Are you frustrated by the following problems?\n You have to repeat assertEquals, which is definitely not creative. Missing an assert may lead to false success, while mistaking one may ruin your mood. If the scenario is complex, the test code may be longer than the service code, which is painful. You have to migrate utility classes every time you start writing test cases for a new application. A TestNG test case is shown on the left side, and an ACTS test case on the right. Repeated coding is gone, and the code size is significantly reduced. Unlike ordinary test scripts, ACTS scripts inherit from the ActsTestBase class, which is encapsulated with data loading methods, driving methods, execution engines, and validation rules. Users do not have to clean or prepare data, run test cases, or validate results. ACTS implements zero coding for simple services, which greatly reduces the coding and maintenance costs.\nGenerate test scripts Prerequisites: Be sure to use Maven to compile your project and generate the object model. Otherwise, ACTS IDE may encounter unexpected errors, such as edit failures and incorrect data.\nRight click a the method defined in the interface and select ACTS Function \u0026amp;gt; Generate Test Case.\nRun test script Method: Right click the tested method in ACTS script, and select TestNG to run the test script as shown in the following figure.\nSpecify a test script to run Set test_only＝^T in src/test/resource/config/acts-config.properties to run only the test case whose name starts with T. You can also replace ^T with other regular expressions.\n In this case, you can modify the name of the test case that you want to run by adding T in front of its name. ACTS only runs a test case whose name starts with T.\n Split test cases of the test script ACTS stores all test case data of a test script in the same YAML file by default. You can determine whether to store test case data by test script or by test case by configuring the option spilt_yaml_by_case. It is set to false by default, which means all test case data of the same test script is stored in one YAML file.\nYou can set spilt_yaml_by_case=true in acts-config.properties to store each test case of a new test script in a separate YAML file that is named after the case ID. This reduces the chances of file conflicts in the case where multiple developers work on the same interface.\nIn addition, ACTS provides a utility class that allows you split a legacy YAML file of a specified test script under a specified path by test case. See the following.\nBaseDataUtil.saveYamlDataToCaseByCase\n Note: Before the split, we recommend that you rename the original YAML file for backup, and then use the test case editor to check whether the content of the split files is correct. The original YAML file must be deleted if the split files are correct, because they cannot coexist. Coding for data preparation ACTS provides context APIs …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-script/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0d20739dedad1f11277bd02ed65329c3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-script/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-script/","summary":"Quickly understand ACTS scripts Do you have to frequently compile test cases? Are you frustrated by the following problems?\n You have to repeat assertEquals, which is definitely not creative. Missing an assert may lead to false success, while mistaking one may ruin your mood. If the scenario is complex, the test code may be longer than the service code, which is painful. You have to migrate utility classes every time you start writing test cases for a new application.","tags":null,"title":"Scripts","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-script/","wordcount":825},{"author":null,"categories":null,"content":" SEATA Demo for SOFAStack Cloud Native Workshop on KubeCon China 2019\nAT mode 1.Introduce maven dependencies Introduce the following dependencies into the POM file of the parent project (seata-demo-at/pom.xml):\n... \u0026amp;lt;properties\u0026amp;gt; ... \u0026amp;lt;seata.version\u0026amp;gt;0.6.1\u0026amp;lt;/seata.version\u0026amp;gt; \u0026amp;lt;netty4.version\u0026amp;gt;4.1.24.Final\u0026amp;lt;/netty4.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; ... \u0026amp;lt;dependencyManagement\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; ... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;javax.servlet\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;servlet-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${netty4.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; \u0026amp;lt;/dependencyManagement\u0026amp;gt; Introduce the following dependencies into the POM file of the stock-mng project (seata-demo-at/stock-mng/pom.xml):\n\u0026amp;lt;dependencies\u0026amp;gt; .... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; Introduce the following dependencies into the POM file of the balance-mng-impl project (seata-demo-at/balance-mng/balance-mng-impl/pom.xml):\n\u0026amp;lt;dependencies\u0026amp;gt; .... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 2. Use Seata\u0026amp;rsquo;s DataSourceProxy to proxy actual data source and configure GlobalTransactionScanner to scan @GlobalTransaction annotation Add the following java snippet to the main methods in BalanceMngApplication and StockMngApplication classes:\n... import io.seata.rm.datasource.DataSourceProxy; import io.seata.spring.annotation.GlobalTransactionScanner; ... @Configuration public static class DataSourceConfig { @Bean @Primary @ConfigurationProperties(prefix = \u0026amp;quot;spring.datasource.hikari\u0026amp;quot;) public DataSource dataSource(DataSourceProperties properties) { HikariDataSource dataSource = createDataSource(properties, HikariDataSource.class); if (StringUtils.hasText(properties.getName())) { dataSource.setPoolName(properties.getName()); } return new DataSourceProxy(dataSource); } @SuppressWarnings(\u0026amp;quot;unchecked\u0026amp;quot;) …","date":-62135596800,"description":"This guide introduces how to use the AT mode and TCC mode of the open-source distributed transaction framework Seata to solve the final consistency of service data.","dir":"guides/kc-seata-demo/","fuzzywordcount":1500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"60071a0eb44bf0901fb187eefd63ccdb","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-seata-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/guides/kc-seata-demo/","summary":"SEATA Demo for SOFAStack Cloud Native Workshop on KubeCon China 2019\nAT mode 1.Introduce maven dependencies Introduce the following dependencies into the POM file of the parent project (seata-demo-at/pom.xml):\n... \u0026lt;properties\u0026gt; ... \u0026lt;seata.version\u0026gt;0.6.1\u0026lt;/seata.version\u0026gt; \u0026lt;netty4.version\u0026gt;4.1.24.Final\u0026lt;/netty4.version\u0026gt; \u0026lt;/properties\u0026gt; ... \u0026lt;dependencyManagement\u0026gt; \u0026lt;dependencies\u0026gt; ... \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.seata\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;seata-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${seata.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.seata\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;seata-server\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${seata.version}\u0026lt;/version\u0026gt; \u0026lt;exclusions\u0026gt; \u0026lt;exclusion\u0026gt; \u0026lt;groupId\u0026gt;javax.servlet\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;servlet-api\u0026lt;/artifactId\u0026gt; \u0026lt;/exclusion\u0026gt; \u0026lt;/exclusions\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.netty\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;netty-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${netty4.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;/dependencies\u0026gt; \u0026lt;/dependencyManagement\u0026gt; Introduce the following dependencies into the POM file of the stock-mng project (seata-demo-at/stock-mng/pom.","tags":null,"title":"Seata distributed transaction practice","type":"guides","url":"/sofastack.tech/en/guides/kc-seata-demo/","wordcount":1464},{"author":null,"categories":null,"content":"SOFABoot RPC Starter provides a variety of registry center options as well as convenient configurations.\nCurrently, bolt, rest, and dubbo all support Zookeeper as registry center. In addition, bolt and rest support the local file system as registry center, which is generally used for testing.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-usage/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5a1a4619c8ac4a9fc27b8576472aed9f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-usage/","summary":"SOFABoot RPC Starter provides a variety of registry center options as well as convenient configurations.\nCurrently, bolt, rest, and dubbo all support Zookeeper as registry center. In addition, bolt and rest support the local file system as registry center, which is generally used for testing.","tags":null,"title":"Select Service Registry","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-usage/","wordcount":45},{"author":null,"categories":null,"content":"When using the Bolt communication protocol, SOFARPC can choose different serialization protocols, which can be hessian2 or protobuf currently.\nBy default, SOFARPC uses hessian2 as the serialization protocol. If you need to set the serialization protocol to protobuf, you need to configure the following settings when publishing the service:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; That is to add the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag to the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag and set the serialize-type attribute to protobuf.\nCorrespondingly, when referencing the service, you also need to change the serialization protocol to protobuf. The setting method is similar to publishing the service:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot; jvm-first=\u0026amp;quot;false\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Currently, when you use Annotation for service reference, it is not yet supported to set serialization protocol. But this will be supported in future versions. For details, see ISSUE: https://github.com/sofastack/sofa-boot/issues/278\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/serialization/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"87e2faa84c2c7a7605243dc096bc4e17","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/serialization/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/serialization/","summary":"When using the Bolt communication protocol, SOFARPC can choose different serialization protocols, which can be hessian2 or protobuf currently.\nBy default, SOFARPC uses hessian2 as the serialization protocol. If you need to set the serialization protocol to protobuf, you need to configure the following settings when publishing the service:\n\u0026lt;sofa:service ref=\u0026quot;sampleService\u0026quot; interface=\u0026quot;com.alipay.sofarpc.demo.SampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs serialize-type=\u0026quot;protobuf\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:service\u0026gt; That is to add the \u0026lt;sofa:global-attrs\u0026gt; tag to the \u0026lt;sofa:binding.bolt\u0026gt; tag and set the serialize-type attribute to protobuf.","tags":null,"title":"Serialization protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/serialization/","wordcount":138},{"author":null,"categories":null,"content":" Local development Starting SOFARegistry locally is to use the H2 database as the configuration database used by the registry, which can be started directly com.alipay.sofa.registry.server.integration.RegistryApplication#main\nBy default, application-dev.properties will be used as the configuration file\nDeployment The deployment of SOFARegistry relies on mysql, which uses mysql as the metadata storage of the registry itself SOFARegistry supports two types of deployment modes, which are integrated deployment and independent deployment. This topic describes the simplest integrated single-node deployment. For more information about deployment modes, see the Deployment topic.\nDeployment steps 1. Download the source code or installation package Download the source code git clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all Download the installation package You can download the latest registry-all.tgz package from Releases.\nrecommended to download v6 or above\ntar -zxvf registry-all.tgz cd registry-all 2. Start registry-integration 2.1 If you start the development registry locally, you can use h2 as the database\nIDEA source code startup: run com.alipay.sofa.registry.server.integration.RegistryApplication#main\nFat jar script start command: sh bin/start_dev.sh\n2.2 MySQL is recommended for the official environment Create database and table\necho \u0026amp;quot;create database registrymetadb \u0026amp;quot; | mysql -u username -p mysql -u username -p registrymetadb \u0026amp;lt; create_table.sql Modify the configuration in conf/application.properties, the database password can also be passed in through the JDBC_PASSWORD environment variable\nStart command: sh bin/integration/start.sh\n3. Check the running status You can access the healthcheck API provided by these three roles, or view logs/registry-startup.log to check the running status.\n# View the healthcheck API of the meta role: $ curl http://localhost:9615/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... raftStatus:Leader\u0026amp;quot;} # View the healthcheck API of the data role: $ curl http://localhost:9622/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... status:WORKING\u0026amp;quot;} # View the healthcheck API of the session role: $ curl http://localhost:9603/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-registry/server-quick-start/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b620900b56ba04f4668838846a97698a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/server-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/server-quick-start/","summary":"Local development Starting SOFARegistry locally is to use the H2 database as the configuration database used by the registry, which can be started directly com.alipay.sofa.registry.server.integration.RegistryApplication#main\nBy default, application-dev.properties will be used as the configuration file\nDeployment The deployment of SOFARegistry relies on mysql, which uses mysql as the metadata storage of the registry itself SOFARegistry supports two types of deployment modes, which are integrated deployment and independent deployment. This topic describes the simplest integrated single-node deployment.","tags":null,"title":"Server deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/server-quick-start/","wordcount":290},{"author":null,"categories":null,"content":" 本文是关于 MOSN server 配置的说明。\n虽然 MOSN 的配置结构里 servers 是一个 server 数组，但是目前最多只支持配置一个server。\nserver 描述的 MOSN 的基本的全局参数如下所示。\n{ \u0026amp;quot;default_log_path\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;default_log_level\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;global_log_roller\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;graceful_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;processor\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;listeners\u0026amp;quot;:[] } default_log_path 默认的错误日志文件路径，支持配置完整的日志路径，以及标准输出（stdout）和标准错误（stderr）。\n 如果配置为空，则默认输出到标准错误（stderr）。 default_log_level 默认的错误日志级别，支持DEBUG、INFO、WARN、ERROR、FATAL。\n 如果配置为空，则默认为 INFO。 global_log_roller 日志轮转配置，会对所有的日志生效，如 tracelog、accesslog、defaultlog。 字符串配置，支持两种模式的配置，一种是按时间轮转，一种是按日志大小轮转。同时只能有一种模式生效。 按照日志大小轮转\n size， 表示日志达到多少 M 进行轮转。 age，表示最多保存多少天的日志。 keep，表示最多保存多少个日志。 compress，表示日志是否压缩，on 为压缩，off 为不压缩。\n\u0026amp;quot;global_log_roller\u0026amp;quot;: \u0026amp;quot;size=100 age=10 keep=10 compress=off\u0026amp;quot; 按照时间轮转\n time，表示每个多少个小时轮转一次。\n\u0026amp;quot;global_log_roller\u0026amp;quot;:\u0026amp;quot;time=1\u0026amp;quot; graceful_timeout Duration String 的字符串配置，表示 MOSN 在进行平滑升级时，等待连接关闭的最大时间。 如果没有配置，默认为 30s。 processor MOSN 使用的 GOMAXPROCS 数量 - 如果没有配置，默认为 CPU 数量。 - 如果配置为 0，等价于没有配置。\nListeners 一组 Listener 的配置。\n","date":-62135596800,"description":"","dir":"projects/mosn/configuration/server/overview/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3b43981b2aebeca5879d566d8264f6b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/server/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/configuration/server/overview/","summary":"本文是关于 MOSN server 配置的说明。 虽然 MOSN 的配置结构里 servers 是一个 server 数组，但是目前最多只支持配置一个server。 server 描述的 MOSN 的基本的全局参数如下所示。 { \u0026quot;default_log_path\u0026quot;:\u0026quot;\u0026quot;,","tags":null,"title":"Server 配置说明","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/server/overview/","wordcount":528},{"author":null,"categories":null,"content":"If you want to extend a registry center, you should take a look at the abstract classes of the registry center.\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026amp;lt;ProviderConfig\u0026amp;gt; configs); public abstract List\u0026amp;lt;ProviderGroup\u0026amp;gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026amp;lt;ConsumerConfig\u0026amp;gt; configs); } You can see the main necessary interfaces.\nStart the registry client and maintain the connection; Destroy the registry client and release resources; Publish service and cache publish information; Unpublish service and delete cache; Subscribe to service list, return data synchronously or asynchronously, and receive notifications upon changes Unsubscribe service list and delete cache Other interfaces:\nWhen the registry center node is disconnected, the local call is not affected. Switch from one disconnected registry center node to another one by itself. After switching to another registry center node, the system resumes the registration and subscription information automatically. The registry data is cached to the local file. Even if no registry center node is connected, the service provider and caller can restart and call normally. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-extension-guide/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c952ecbea16f7ae68ad095ab8baf0583","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","summary":"If you want to extend a registry center, you should take a look at the abstract classes of the registry center.\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026lt;ProviderConfig\u0026gt; configs); public abstract List\u0026lt;ProviderGroup\u0026gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026lt;ConsumerConfig\u0026gt; configs); } You can see the main necessary interfaces.","tags":null,"title":"Service Registry extension guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","wordcount":192},{"author":null,"categories":null,"content":" SOFADashboard\u0026amp;rsquo;s service governance mainly manages SOFARPC services.\nConsole The service governance console mainly provides two basic functions: service name query and service information display. When you click the hyperlink of a service ID, you are redirected to the details page of the service.\nService provider details page Service consumer details page ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/governance/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e547baf489fd5d125be9e67a366854b6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/governance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/governance/","summary":" SOFADashboard\u0026rsquo;s service governance mainly manages SOFARPC services.\nConsole The service governance console mainly provides two basic functions: service name query and service information display. When you click the hyperlink of a service ID, you are redirected to the details page of the service.\nService provider details page Service consumer details page ","tags":null,"title":"Service governance","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/governance/","wordcount":51},{"author":null,"categories":null,"content":" The basic configuration for SOFARPC service publishing and reference is described in the \u0026amp;ldquo;Programming Interface\u0026amp;rdquo; chapter. Here are some of the features of service publishing and referencing.\nOne service publishes multiple protocols In SOFARPC, a service can be published as multiple protocols, which allows the callers to call the service provider using different protocols.\nIf you use the Java API, you can build multiple ServerConfigs as follows to set different protocols for different ServerConfigs and then assign these ServerConfigs to ProviderConfig:\nList\u0026amp;lt;ServerConfig\u0026amp;gt; serverConfigs = new ArrayList\u0026amp;lt;ServerConfig\u0026amp;gt;(); serverConfigs.add(serverConfigA); serverConfigs.add(serverConfigB); providerConfig.setServer(serverConfigs); If you use XML, add multiple bindings directly in the \u0026amp;lt;sofa:service\u0026amp;gt; tag:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; If you use annotation, add multiple bindings in @SofaService:\n@SofaService ( interfaceType = SampleService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;), @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) } ) public class SampleServiceImpl implements SampleService { // ... } One service registers multiple registry centers If you use the API, build multiple RegistryConfigs and assign them to ProviderConfig:\nList\u0026amp;lt;RegistryConfig\u0026amp;gt; registryConfigs = new ArrayList\u0026amp;lt;RegistryConfig\u0026amp;gt;(); registryConfigs.add(registryA); registryConfigs.add(registryB); providerConfig.setRegistry(registryConfigs); Method-level parameter settings In the Java API mode, you can set the corresponding parameters by calling the set method of the MethodConfig object, as shown below:\nMethodConfig methodConfigA = new MethodConfig(); MethodConfig methodConfigB = new MethodConfig(); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfigA); methodConfigs.add(methodConfigB); providerConfig.setMethods(methodConfigs); //server settings consumerConfig.setMethods(methodConfigs); //Client settings In the XML mode, you can use the \u0026amp;lt;sofa:method\u0026amp;gt; tag in the corresponding binding to set the corresponding parameters:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;3000\u0026amp;quot; address-wait-time=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Call timeout; address wait time. --\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:22000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Directly connected address --\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;sayName\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Method level configuration --\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/publish-and-reference/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"6a78b8b84b226eaf1e6d2b1ff1d15fee","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","summary":"The basic configuration for SOFARPC service publishing and reference is described in the \u0026ldquo;Programming Interface\u0026rdquo; chapter. Here are some of the features of service publishing and referencing.\nOne service publishes multiple protocols In SOFARPC, a service can be published as multiple protocols, which allows the callers to call the service provider using different protocols.\nIf you use the Java API, you can build multiple ServerConfigs as follows to set different protocols for different ServerConfigs and then assign these ServerConfigs to ProviderConfig:","tags":null,"title":"Service publishing and reference","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","wordcount":348},{"author":null,"categories":null,"content":" This document describes the complete SOFARPC service publishing and reference in the SOFABoot environment.\nPublish service \u0026amp;lt;bean id=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; thread-pool-ref=\u0026amp;quot;\u0026amp;quot; warm-up-time=\u0026amp;quot;60000\u0026amp;quot; warm-up-weight=\u0026amp;quot;10\u0026amp;quot; weight=\u0026amp;quot;100\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Attribute Name Default value Comment id ID bean名 class Class None ref Service interface implementation class interface Service interface (unique identifier) Use actual interface class for both normal calls and return calls unique-id Service tag (unique identifier) filter Filter configuration alias Separated by commas registry Server registry center Separated by commas timeout Execution timeout period on the server serialize-type Serialization protocol hessian2,protobuf thread-pool-ref Thread pool used by the current interface of the server None weight Service static weight warm-up-weight Service warm-up weight warm-up-time Service warm-up time Unit: millisecond Reference service \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;helloSyncServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;sync\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; address-wait-time=\u0026amp;quot;1000\u0026amp;quot; connect.num=\u0026amp;quot;1\u0026amp;quot; check=\u0026amp;quot;false\u0026amp;quot; connect.timeout=\u0026amp;quot;1000\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; generic-interface=\u0026amp;quot;\u0026amp;quot; idle.timeout=\u0026amp;quot;1000\u0026amp;quot; idle.timeout.read=\u0026amp;quot;1000\u0026amp;quot; lazy=\u0026amp;quot;false\u0026amp;quot; loadBalancer=\u0026amp;quot;\u0026amp;quot; registry=\u0026amp;quot;\u0026amp;quot; retries=\u0026amp;quot;1\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;xxx:12200\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; type=\u0026amp;quot;sync\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Attribute Name Default value Comment id ID Generated automatically jvm-first Whether to call the service of local machine first true interface Service interface (unique identifier) Use actual interface class for both normal calls and return calls unique-id Service tag (unique identifier) local-first whether refer to the service via jvm call true set it to false if this is to call a remote service via rpc type Calling type sync callback,sync,future,oneway filter Filter configuration alias List registry Server …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/rpc-config-xml-explain/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4b5110e9eb6cf6c6f287aef0fd210047","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","summary":"This document describes the complete SOFARPC service publishing and reference in the SOFABoot environment. Publish service \u0026lt;bean id=\u0026quot;helloSyncServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;helloSyncServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026quot; unique-id=\u0026quot;\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs registry=\u0026quot;\u0026quot; serialize-type=\u0026quot;\u0026quot; filter=\u0026quot;\u0026quot; timeout=\u0026quot;3000\u0026quot; thread-pool-ref=\u0026quot;\u0026quot; warm-up-time=\u0026quot;60000\u0026quot; warm-up-weight=\u0026quot;10\u0026quot; weight=\u0026quot;100\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;sofa:binding.rest\u0026gt; \u0026lt;/sofa:binding.rest\u0026gt; \u0026lt;/sofa:service\u0026gt; Attribute Name Default value Comment id ID bean名 class Class None ref Service interface implementation class interface Service interface (unique identifier) Use actual interface class for both normal calls","tags":null,"title":"Service publishing and reference in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","wordcount":356},{"author":null,"categories":null,"content":" Sidecar 模式是 Service Mesh 中习惯采用的模式，是容器设计模式的一种，在 Service Mesh 出现之前该模式就一直存在，本文将为您讲解 Sidecar 模式。\n什么是 Sidecar 模式 将应用程序的功能划分为单独的进程可以被视为 Sidecar 模式。如图所示，Sidecar 模式允许您在应用程序旁边添加更多功能，而无需额外第三方组件配置或修改应用程序代码。\n就像连接了 Sidecar 的三轮摩托车一样，在软件架构中， Sidecar 连接到父应用并且为其添加扩展或者增强功能。Sidecar 应用与主应用程序松散耦合。它可以屏蔽不同编程语言的差异，统一实现微服务的可观察性、监控、日志记录、配置、断路器等功能。\n使用 Sidecar 模式的优势 Sidecar 模式具有以下优势：\n 将与应用业务逻辑无关的功能抽象到共同基础设施降低了微服务代码的复杂度。\n 因为不再需要编写相同的第三方组件配置文件和代码，所以能够降低微服务架构中的代码重复度。\n 降低应用程序代码和底层平台的耦合度。\n Sidecar 模式如何工作 Sidecar 是容器应用模式的一种，也是在 Service Mesh 中发扬光大的一种模式，详见 Service Mesh 架构解析，其中详细描述使用了节点代理和 Sidecar 模式的 Service Mesh 架构。\n使用 Sidecar 模式部署服务网格时，无需在节点上运行代理，但是集群中将运行多个相同的 Sidecar 副本。在 Sidecar 部署方式中，每个应用的容器旁都会部署一个伴生容器，这个容器称之为 Sidecar 容器。Sidecar 接管进出应用容器的所有流量。在 Kubernetes 的 Pod 中，在原有的应用容器旁边注入一个 Sidecar 容器，两个容器共享存储、网络等资源，可以广义的将这个包含了 Sidecar 容器的 Pod 理解为一台主机，两个容器共享主机资源。\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/sidecar-pattern/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"38b45799d69d52f24f26008cd2ad7da5","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/sidecar-pattern/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/concept/sidecar-pattern/","summary":"Sidecar 模式是 Service Mesh 中习惯采用的模式，是容器设计模式的一种，在 Service Mesh 出现之前该模式就一直存在，本文将为您讲解 Sidecar 模式。 什么是 Sidecar 模式 将应用程序的功能划分为","tags":null,"title":"Sidecar 模式","type":"projects","url":"/sofastack.tech/projects/mosn/concept/sidecar-pattern/","wordcount":602},{"author":null,"categories":null,"content":" Since SOFARPC 5.4.0, the link analysis feature of Skywalking is supported. You can use it as needed. The Skywalking must be 6.0.0-alpha and above.\nThis document does not cover the backend deployment. If you need it, please refer to the official Skywalking documentation.\nInstall Java agent Locate the agent directory in the downloaded Skywalking release package.\n Set agent.service_name in config/agent.config, which can be any English character. Generally, it can be your own system name.\n Set the collector.backend_service Skywalking backend address in config/agent.config, which defaults to 127.0.0.1:11800. It is used for local verification.\n Add -javaagent:/path/to/skywalking-package/agenxt/skywalking-agent.jar to the application, which must be placed before the -jar parameter. The skywalking-agent can be gotten in official release package. The new directory structure is as follows:\n+-- agent +-- activations apm-toolkit-log4j-1.x-activation.jar apm-toolkit-log4j-2.x-activation.jar apm-toolkit-logback-1.x-activation.jar ... +-- config agent.config +-- plugins sofa-rpc-plugin-6.0.0-alpha.jar apm-feign-default-http-9.x.jar apm-httpClient-4.x-plugin.jar ..... skywalking-agent.jar Note: Ensure that the plugins/sofa-rpc-plugin-**.jar file exists.\n Start the application. After a period of RPC calls, you can view the UI to observe the calling link.\n More For more relevant documents, please refer to\nSkywalking Agent installation documentation Skywalking Backend deployment documentation\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/skywalking-usage/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3cd5fb45f1b981d0a8c54c8ce43b190b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","summary":"Since SOFARPC 5.4.0, the link analysis feature of Skywalking is supported. You can use it as needed. The Skywalking must be 6.0.0-alpha and above.\nThis document does not cover the backend deployment. If you need it, please refer to the official Skywalking documentation.\nInstall Java agent Locate the agent directory in the downloaded Skywalking release package.\n Set agent.service_name in config/agent.config, which can be any English character. Generally, it can be your own system name.","tags":null,"title":"Skywalking","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","wordcount":181},{"author":null,"categories":null,"content":" SOFARPC 在5.4.0 及之后的版本中，已经支持 Skywalking 的链路分析的功能，用户可以根据需要进行使用，其中Skywalking 的版本 要求6.0.0-alpha及以上。本文档，不涉及后端的部署，如有需要，可查看 Skywalking 官方文档。\n安装 Java agent 1.在下载的 Skywalking 的release 包中找到 agent 目录。\n2.在config/agent.config 中设置 agent.service_name，可以是任何英文字符，一般可以设置为自己的系统名。\n3.在config/agent.config 中设置 collector.backend_service Skywalking 的后端地址，默认指向 127.0.0.1:11800,这个是为了本地验证的。\n4.给应用程序添加 -javaagent:/path/to/skywalking-package/agenxt/skywalking-agent.jar，其中注意，一定要放在 -jar 参数之前。 Agent 在 kywalking 的 官方 release 包. 新的目录结构如下.\n+-- agent +-- activations apm-toolkit-log4j-1.x-activation.jar apm-toolkit-log4j-2.x-activation.jar apm-toolkit-logback-1.x-activation.jar ... +-- config agent.config +-- plugins sofa-rpc-plugin-6.0.0-alpha.jar apm-feign-default-http-9.x.jar apm-httpClient-4.x-plugin.jar ..... skywalking-agent.jar 注意，确保plugins/sofa-rpc-plugin-**.jar 文件存在。\n5.启动应用程序，经过一段时间RPC调用后，可以查看 UI 来观察链路。\n更多 更多文档请参考\n Skywalking Agent 安装文档 Skywalking Backend 部署文档 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/skywalking-usage/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3cd5fb45f1b981d0a8c54c8ce43b190b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/skywalking-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/skywalking-usage/","summary":"SOFARPC 在5.4.0 及之后的版本中，已经支持 Skywalking 的链路分析的功能，用户可以根据需要进行使用，其中Skywalking 的版本 要求6.0.0-alpha","tags":null,"title":"Skywalking 链路分析","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/skywalking-usage/","wordcount":482},{"author":null,"categories":null,"content":" SOFABoot 提供了模块并行启动以及 Spring Bean 异步初始化能力，用于加快应用启动速度。本文介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力以提高应用启动速度。\n使用场景 在实际使用 Spring/Spring Boot 开发中，一些 Bean 在初始化过程中执行准备操作，如拉取远程配置、初始化数据源等等。在应用启动期间，这些 Bean 会增加 Spring 上下文刷新时间，导致应用启动耗时变长。\n为了加速应用启动，SOFABoot 通过配置可选项，将 Bean 的初始化方法（init-method）使用单独线程异步执行，加快 Spring 上下文加载过程，提高应用启动速度。\n引入依赖 在工程的 pom.xml 文件中，引入如下 starter：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 使用方法 异步初始化 Bean 的原理是开启单独线程负责执行 Bean 的初始化方法（init-method）。因此，除了引入上述依赖，还需要在 Bean 的 XML 定义中配置 async-init=\u0026amp;ldquo;true\u0026amp;rdquo; 属性，用于指定是否异步执行该 Bean 的初始化方法，例如：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- async init test --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBean\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.beans.TimeWasteBean\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot; async-init=\u0026amp;quot;true\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 属性配置 SOFABoot 异步初始化能力提供两个属性配置，用于指定负责异步执行 Bean 初始化方法（init-method）的线程池大小：\n com.alipay.sofa.boot.asyncInitBeanCoreSize：线程池基本大小，默认值为 CPU 核数加一。 com.alipay.sofa.boot.asyncInitBeanMaxSize：线程池中允许的最大线程数大小，默认值为 CPU 核数加一。 此配置可以通过 VM -D 参数或者 Spring Boot 配置文件 application.yml 设置。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/bean-async-init/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1b7c2d94076ffb7ac96f64a557067917","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/bean-async-init/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/bean-async-init/","summary":"SOFABoot 提供了模块并行启动以及 Spring Bean 异步初始化能力，用于加快应用启动速度。本文介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力以提高应用启动速度。 使用场景 在实际使用","tags":null,"title":"Spring Bean 异步初始化","type":"projects","url":"/sofastack.tech/projects/sofa-boot/bean-async-init/","wordcount":578},{"author":null,"categories":null,"content":" 借助 SofaArk 框架，一个普通的 Java 应用可拆分为一个宿主应用（master biz，又称“基座”）与多个业务应用（普通 biz，又称“模块”）的模式，细化研发粒度，以此实现更快速的研发运维。本文将介绍 Spring Boot 应用如何结合 SofaArk 框架，以此构建宿主应用与业务应用。文章由以下七点展开：\n 简介 如何构建 Spring Boot 业务应用 如何构建 Spring Boot 宿主应用 如何执行 Spring Boot 宿主应用 如何执行 Spring Boot 业务应用 多 Host 与单 Host 模式 如何动态卸载 Spring Boot 业务应用 1. 简介 宿主应用（master biz）负责沉淀通用的逻辑，为业务应用提供计算和环境，为业务应用的开发者屏蔽基础设施，更新迭代较慢。各个业务应用（普通 biz）是独立的代码仓库，可以进行独立的研发运维，粒度小，更新迭代较快。业务应用将通用的依赖下沉至宿主应用，依赖宿主应用的环境运行，不是一个 可执行 Jar，因此业务应用自身的 jar 包可以不包含该通用依赖，以此得到轻量化的业务应用 jar 包。\n宿主应用与业务应用的运行关系是：宿主应用首先启动，拥有与普通应用相同的类加载器；业务应用 jar 包以热拔插的模式在宿主应用中动态部署，通用依赖通过宿主应用的类加载器加载，其它依赖使用业务自己的BizClassLoader进行加载。\n本文中宿主应用和业务应用均为 Web 应用，采用了单 host 模式，其样例代码地址如下：\n Spring Boot 宿主应用：Spring Boot 宿主应用 Spring Boot 业务应用：Spring Boot 业务应用 2. 如何构建 Spring Boot 业务应用 业务应用是一种普通 Biz，换而言之，“如何构建业务应用”即为“如何构建普通 Ark Biz”，Ark Biz的介绍请详见Ark Biz。\n2.1 依赖配置 首先，我们需要把业务应用构建成一种 SofaArk 框架可识别的Ark Biz，即：使用Ark Biz打包构建的依赖，配置如下：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;{sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;!-- 建议使用最新版本--\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;skipArkExecutable\u0026amp;gt;true\u0026amp;lt;/skipArkExecutable\u0026amp;gt; \u0026amp;lt;!-- 不生成可执行 fat jar--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!-- 生成的 Ark Biz 所在目录--\u0026amp;gt; \u0026amp;lt;bizName\u0026amp;gt;spring-boot-ark-biz\u0026amp;lt;/bizName\u0026amp;gt; \u0026amp;lt;!-- Ark Biz 名字--\u0026amp;gt; \u0026amp;lt;!-- webContextPath 是单 host 模式下的必要配置，详细配置见 5. 多 host 模式与单 host 模式 --\u0026amp;gt; \u0026amp;lt;webContextPath\u0026amp;gt;biz\u0026amp;lt;/webContextPath\u0026amp;gt; \u0026amp;lt;!-- 同一个host中设置不同的webContextPath--\u0026amp;gt; \u0026amp;lt;!-- declaredMode 开启后，业务应用可以使用自己声明过的、且宿主应用拥有的通用依赖--\u0026amp;gt; \u0026amp;lt;declaredMode\u0026amp;gt;true\u0026amp;lt;/declaredMode\u0026amp;gt; \u0026amp;lt;!-- 使用宿主应用的通用依赖--\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;!-- 此处不使用 spring boot 应用的原有构建依赖--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;plugin\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;/plugin\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 其次，由于业务应用运行时使用宿主应用的通用依赖，因此业务应用需要“排除”通用依赖，即：把 scope 设置成 provided。本样例代码中，业务应用直接使用宿主应用的 spring boot 各项依赖，配置如下：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2 打包 首先，使用 maven 打包业务应用，如下：\nmvn clean package -Dmaven.test.skip=true 在之前设定的 outputDirectory 目录下，后缀为ark-biz.jar的包是业务应用的 Ark …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-spring-boot-demo/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa8f11f9f806997290dac0ff5c105ab6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","summary":"借助 SofaArk 框架，一个普通的 Java 应用可拆分为一个宿主应用（master biz，又称“基座”）与多个业务应用（普通 biz，又称“模块”）的模式，细化研","tags":null,"title":"Spring Boot 应用如何结合 SofaArk","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","wordcount":3263},{"author":null,"categories":null,"content":" In this document will demonstrate how to use SOFATracer to track of SpringMVC, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs Add a simple Controller In the project code, add a simple Controller, for example:\n@RestController public class SampleRestController { private static final String TEMPLATE = \u0026amp;quot;Hello, %s!\u0026amp;quot;; private final AtomicLong counter = new AtomicLong(); /** * http://localhost:8080/springmvc * @param name name * @return map */ @RequestMapping(\u0026amp;quot;/springmvc\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; springmvc(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;SOFATracer SpringMVC DEMO\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; resultMap = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); resultMap.put(\u0026amp;quot;success\u0026amp;quot;, true); resultMap.put(\u0026amp;quot;id\u0026amp;quot;, counter.incrementAndGet()); resultMap.put(\u0026amp;quot;content\u0026amp;quot;, String.format(TEMPLATE, name)); return resultMap; } } Run the project Start Current SOFABoot Application. You will see the log about startup in the console:\n2018-05-11 11:55:11.932 INFO 66490 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcOpenTracingFilter\u0026#39; to urls: [/*] 2018-05-11 11:55:13.961 INFO 66490 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-05-11 11:55:13.970 INFO 66490 --- [ main] c.a.s.t.e.springmvc.DemoApplication : Started DemoApplication in 8.361 seconds (JVM running for 9.34) You can access the REST service by visiting http://localhost:8080/springmvc in your browser. You can see the result similar to the followings:\n{ content: \u0026amp;quot;Hello, SOFATracer SpringMVC DEMO!\u0026amp;quot;, id: 1, success: true } View log In the application.properties, the log printing directory we configured is ./logs, which is the root directory of the current application (we can configure it based on actual situation). In the root directory, you can see log files in the structure similar to the followings:\n./logs ├── spring.log └── tracelog ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log Every time you visit http://localhost:8080/springmvc, SOFATracer will log the digest log. You can open the spring-mvc-digest.log file to see the specific log content. As for the meaning of each output field, you can refer to here.\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-05-17 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-mvc/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"6c6389a6f994f43f08cbdf4a49d1755a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","summary":"In this document will demonstrate how to use SOFATracer to track of SpringMVC, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.","tags":null,"title":"Spring MVC Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","wordcount":356},{"author":null,"categories":null,"content":" SpringMVC Log Format After integrating SpringMVC, SOFATracer will output the link data format of the MVC requests, which is JSON by default.\nSpring MVC digest log (spring-mvc-digest.log) Data is ouput in JSON format. The meaning of each key is as follows:\n Key Meaning Time Log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.code HTTP return status code req.size.bytes Request body size resp.size.bytes Response body size Time.cost.milliseconds Request time (ms) Current.thread.name Current thread name Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-06-03 16:44:05.829\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SpringMvcJsonOutput\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;c0a80d9e1528015445828101064625\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:63933/greeting\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:50,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:1,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-auto-1-exec-10\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring MVC statistical log (spring-mvc-stat.log) stat.key is a collection of statistical keywords in this period., which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration for (ms) requests in this period success Request result: Y means success (the result code starting with 1 and 2 indicates success, and 302 indicates that the redirection is successful, and others indicate failure); N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-06-03 16:44:02.473\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:63933/greeting\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SpringMvcJsonOutput\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:5,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:149,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;Y\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-springmvc/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"af13acf5aee90a32f0fa143996063a91","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","summary":"SpringMVC Log Format After integrating SpringMVC, SOFATracer will output the link data format of the MVC requests, which is JSON by default.\nSpring MVC digest log (spring-mvc-digest.log) Data is ouput in JSON format. The meaning of each key is as follows:\n Key Meaning Time Log printing time Local.app Current application name traceId TraceId spanId SpanId Request.","tags":null,"title":"Spring MVC log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","wordcount":200},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 SpringMVC 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private static final String TEMPLATE = \u0026amp;quot;Hello, %s!\u0026amp;quot;; private final AtomicLong counter = new AtomicLong(); /** * http://localhost:8080/springmvc * @param name name * @return map */ @RequestMapping(\u0026amp;quot;/springmvc\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; springmvc(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;SOFATracer SpringMVC DEMO\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; resultMap = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); resultMap.put(\u0026amp;quot;success\u0026amp;quot;, true); resultMap.put(\u0026amp;quot;id\u0026amp;quot;, counter.incrementAndGet()); resultMap.put(\u0026amp;quot;content\u0026amp;quot;, String.format(TEMPLATE, name)); return resultMap; } } 运行 启动 SOFABoot 应用，将会在控制台中看到启动打印的日志：\n2018-05-11 11:55:11.932 INFO 66490 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcOpenTracingFilter\u0026#39; to urls: [/*] 2018-05-11 11:55:13.961 INFO 66490 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-05-11 11:55:13.970 INFO 66490 --- [ main] c.a.s.t.e.springmvc.DemoApplication : Started DemoApplication in 8.361 seconds (JVM running for 9.34) 可以通过在浏览器中输入 http://localhost:8080/springmvc 来访问 REST 服务，结果类似如下：\n{ content: \u0026amp;quot;Hello, SOFATracer SpringMVC DEMO!\u0026amp;quot;, id: 1, success: true } 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 通过访问 http://localhost:8080/springmvc SOFATracer 会记录每一次访问的摘要日志，可以打开 spring-mvc-digest.log 看到具体的输出内容。\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8801-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5006ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-mvc/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6c6389a6f994f43f08cbdf4a49d1755a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","summary":"在本文档将演示如何使用 SOFATracer 对 SpringMVC 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt;","tags":null,"title":"Spring MVC 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","wordcount":514},{"author":null,"categories":null,"content":" SOFATracer 集成 SpringMVC 后输出 MVC 请求的链路数据格式，默认为 JSON 数据格式。\nSpring MVC 摘要日志（spring-mvc-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8801-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5006ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring MVC 统计日志（spring-mvc-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功(1 开头和 2 开头的结果码算是成功的，302表示的重定向算成功，其他算是失败的)；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:34:04.129\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5006,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-springmvc/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"af13acf5aee90a32f0fa143996063a91","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","summary":"SOFATracer 集成 SpringMVC 后输出 MVC 请求的链路数据格式，默认为 JSON 数据格式。 Spring MVC 摘要日志（spring-mvc-digest.log） 以 JSON 格式输出的数据，相应 key 的","tags":null,"title":"Spring MVC 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","wordcount":380},{"author":null,"categories":null,"content":" 本文将向您展示 MOSN 的 TLS 安全能力。\n证书方案 MOSN 支持通过 Istio Citadel 的证书签发方案，基于 Istio 社区的 SDS （Secret Discovery Service）方案为 Sidecar 配置证书，支持证书动态发现和热更新能力。为了支持更高级的安全能力，MOSN 没有使用 Citadel 的证书自签发能力，而是通过对接内部 KMS 系统获取证书。同时提供证书缓存和证书推送更新能力。\n我们先来看看 MOSN 证书方案的架构图，如下图所示：\n各组件职能如下：\n Pilot：负责 Policy、SDS 配置下发，为简化复杂度，图中未标出 Citadel：Citadel 作为 Certificate Provider ，同时作为 MCP Server 为 Citadel Agent 提供 Pod、CR等资源 Citadel Agent：提供 SDS Server 服务，为MOSN、DB Sidecar、Security Sidecar 提供Certificate和CR下发能力 KMS：密钥管理系统负责证书签发 证书获取流程 对整体架构有个大致理解后，我们分解下 Sidecar 获取证书的流程，如下图所示：\n补充说明下图中的每一步环节：\n Citadel 与 Citadel agent（nodeagent）组件通过MCP协议（Mesh Configuration Protocol）同步Pod 和 CR 信息，避免 citadel agent 直接请求 API Server 导致 API Server 负载过高 MOSN 通过Unix Domain Socket 方式向 Citadel Agent 发起 SDS 请求 Citadel Agent 会进行防篡改校验，并提取appkey Citadel Agent 携带 appkey 请求 Citadel 签发证书 Citadel 检查证书是否已缓存，如果缓存证书未过期，Citadel 将直接响应缓存证书 证书不在缓存中，Citadel 会基于 appkey 构造证书签发请求，向 KMS 申请签发证书 KMS 会将签发的证书响应回Citadel，另外 KMS 也支持证书过期轮换通知 Citadel 收到证书后，会将证书传递给到对应的 Citadel Agent Citadel Agent 收到证书后，会在内存中缓存证书，并将证书下发给到 MOSN ","date":-62135596800,"description":"","dir":"projects/mosn/concept/tls/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"47ccccf9690bc65fa437463a8f5e55b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/tls/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/concept/tls/","summary":"本文将向您展示 MOSN 的 TLS 安全能力。 证书方案 MOSN 支持通过 Istio Citadel 的证书签发方案，基于 Istio 社区的 SDS （Secret Discovery Service）方案为 Sidecar 配置证书，支持证书","tags":null,"title":"TLS 安全链路","type":"projects","url":"/sofastack.tech/projects/mosn/concept/tls/","wordcount":654},{"author":null,"categories":null,"content":" SOFAArk 容器提供了一个简单的 telnet 服务端小工具，用于运行时查看容器状态，目前支持查看 Plugin 和 Biz 相关信息。\n使用方式 使用 telnet 连接服务端，端口号为 1234， 例如：\n telnet localhost 1234\n 进入交互界面:\n➜ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is \u0026#39;^]\u0026#39;. sofa-ark\u0026amp;gt; sofa-ark\u0026amp;gt; sofa-ark\u0026amp;gt; 目前支持查看 Plugin 和 Biz 相关信息，相关命令可参考提示信息：\nsofa-ark\u0026amp;gt;h Plugin Command Tips: USAGE: plugin [option...] [pluginName...] SAMPLE: plugin -m plugin-A plugin-B -h Shows the help message. -a Shows all plugin name. -m Shows the meta info of specified pluginName. -s Shows the service info of specified pluginName. -d Shows the detail info of specified pluginName. Biz Command Tips: USAGE: biz [option...] [arguments...] SAMPLE: biz -m bizIdentityA bizIdentityB. -h Shows the help message. -a Shows all biz. -m Shows the meta info of specified bizIdentity. -s Shows the service info of specified bizIdentity. -d Shows the detail info of specified bizIdentity. -i Install biz of specified bizIdentity or bizUrl. -u Uninstall biz of specified bizIdentity. -o Switch biz of specified bizIdentity. sofa-ark\u0026amp;gt; Plugin 命令 如提示信息所说，plugin 支持查看插件相关信息，包括类(资源)导入导出配置、插件打包配置等。例如：\nsofa-ark\u0026amp;gt;plugin -md runtime-sofa-boot-plugin PluginName: runtime-sofa-boot-plugin Version: 3.1.3 Priority: 1500 Activator: com.alipay.sofa.runtime.integration.activator.SofaRuntimeActivator Export Packages: com.alipay.sofa.runtime.api.*,com.alipay.sofa.runtime.client.*,com.alipay.sofa.runtime.component.*,com.alipay.sofa.runtime.constants.*,com.alipay.sofa.runtime.integration.*,com.alipay.sofa.runtime.model.*,com.alipay.sofa.runtime.service.component,com.alipay.sofa.runtime.service.helper,com.alipay.sofa.runtime.spi.client,com.alipay.sofa.runtime.spi.component,com.alipay.sofa.runtime.spi.health,com.alipay.sofa.runtime.spi.log,com.alipay.sofa.runtime.spi.binding,com.alipay.sofa.runtime.spi.util,org.aopalliance.aop,org.aopalliance.intercept Import Packages: \\ Export Classes: com.alipay.sofa.runtime.service.binding.JvmBinding,com.alipay.sofa.runtime.SofaFramework,com.alipay.sofa.runtime.SofaRuntimeProperties,com.alipay.sofa.runtime.service.binding.JvmBindingParam,com.alipay.sofa.runtime.spi.service.ServiceProxy Import Classes: \\ Export Resources: \\ Import Resources: \\ GroupId: com.alipay.sofa ArtifactId: runtime-sofa-boot-plugin Version: 3.1.3 URL: jar:file:/Users/qilong.zql/.m2/repository/com/alipay/sofa/runtime-sofa-boot-plugin/3.1.3/runtime-sofa-boot-plugin-3.1.3.jar!/ ClassLoader: com.alipay.sofa.ark.container.service.classloader.PluginClassLoader@420a63fb ClassPath: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-telnet/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f23d585e5439569b47ed83f7bc955b22","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","summary":"SOFAArk 容器提供了一个简单的 telnet 服务端小工具，用于运行时查看容器状态，目前支持查看 Plugin 和 Biz 相关信息。 使用方式 使用 telnet 连接服务端，端口号为 1234， 例如：","tags":null,"title":"Telnet 指令","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","wordcount":513},{"author":null,"categories":null,"content":" Ark package The Executed Fat Jar that meets the specific directory format requirements can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package the engineering application into a standard-format Ark package. Start the application on top of the SOFAArk container with the java -jar command. The Ark package usually contains the Ark Container, Ark Plugin dependency (if any), merged deployed Ark Biz (if any), and the Ark Biz of the application itself. For details, refer to the Ark package；\nArk Container The Ark container (Ark Plugin and Ark Biz) runs on top of the SOFAArk container. The container has the ability to manage multiple plug-ins and applications. After successful start, the container will resolve the configuration of Ark Plugin and Ark Biz, complete loading of the isolation and start them in turn based on their priorities. For details, refer to SOFAArk container startup；\nArk Plugin The Ark plug-in, which meets the specific fat jar directory format requirements, can use the officially provided Maven plug-in (sofa-Ark-plugin-maven-plugin) to package one or multiple common Java Jar packages into a standard-format Ark Plugin. Ark Plugin will contain a configuration file that usually contains the import and export configuration of plug-in classes and resources and the priority of plug-in startup. When running, the Ark container will use an independent PluginClassLoader to load the plug-ins, and build the index table for class loading according to the plug-in configuration, so that the plug-ins are isolated from each other and from the applications. For details, refer to Ark Plugin；\nArk Biz The Ark module, which meets the specific fat jar directory format requirements, can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package an engineering application into a standard-format Ark Biz package. The Ark Biz package has two roles: one is to be the organizational unit of the engineering application module and its dependent packages, and the other is to be used as a common jar package dependency by other applications to start multiple Ark Biz packages in the same SOFAArk container. Multiple Ark Biz packages share the Ark Container and Ark Plugin. For details, refer to Ark Biz；\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-terminology/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b6d0ed10afe9d04bc00307017ffba7c5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","summary":"Ark package The Executed Fat Jar that meets the specific directory format requirements can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package the engineering application into a standard-format Ark package. Start the application on top of the SOFAArk container with the java -jar command. The Ark package usually contains the Ark Container, Ark Plugin dependency (if any), merged deployed Ark Biz (if any), and the Ark Biz of the application itself.","tags":null,"title":"Terminologies","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","wordcount":351},{"author":null,"categories":null,"content":" Explanation of Terms Terminology Description TraceId TraceId refers to the ID that represents the unique request in SOFATracer. This ID is generally generated by the first system in the cluster that processes the request and is passed over the network to the next requested system in distributed calls. SpanId SpanId represents the location or level of the request in the entire call link. For example, the system A calls system B, C, and D in sequence when processing a request. Then the SpanId of the three calls are respectively: 0.1, 0.2, 0.3. If system B continues to call system E and F, the SpanIds of the two calls are: 0.1.1, 0.1.2. For other related terminologies, see OpenTracing specification.\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/explanation/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"8ba307b0679e918f7ac68c7efb7e53f7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/explanation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/explanation/","summary":"Explanation of Terms Terminology Description TraceId TraceId refers to the ID that represents the unique request in SOFATracer. This ID is generally generated by the first system in the cluster that processes the request and is passed over the network to the next requested system in distributed calls. SpanId SpanId represents the location or level of the request in the entire call link.","tags":null,"title":"Terminologies","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/explanation/","wordcount":118},{"author":null,"categories":null,"content":" General terminology Term Description Service A software function provided over the network with specific business logic processing capabilities. Service provider A computer node that provides services over the network. Service consumer A computer node that receives services through the network. The same computer node can both be the service provider of some services and the service consumer of others. Service discovery The process in which the service consumer obtains the network address of the service provider. Service registry A software system that provides service discovery functions to help service consumers obtain network addresses of service providers. Data center An independent physical area with a fixed physical location, stable power supply, and reliable network. A data center is usually an important factor that you want to consider in high availability design. Generally, deployment in the same data center features higher network quality, lower latency, but limited disaster recovery capability. However, deployment across different data centers features lower network quality, higher latency, but better disaster recovery capability. SOFARegistry terminology Terminology Description SOFARegistry A registry product open sourced by Ant Financial to provide service discovery based on the \u0026amp;ldquo;publishing-subscription\u0026amp;rdquo; mode. In addition to service discovery, SOFARegistry is applicable to more general \u0026amp;ldquo;publishing-subscription\u0026amp;rdquo; scenarios. Data In the context of service discovery, data specifically refers to the network address and some additional information of the service provider. In other circumstances, it also refers to information published to SOFARegistry. Zone The key concept of the zone-based architecture. In the context of service discovery, a zone is a collection of publishing and subscription requests. When you publish or subscribe to a service, you need to specify the zone name. For more information, see Active geo-redundant zone-based architecture solution. Publisher A node that publishes data to SOFARegistry. In the context of service discovery, the service provider is the publisher of the \u0026amp;ldquo;service provider\u0026amp;rsquo;s network address and additional information\u0026amp;rdquo;. Subscriber A node that subscribes to data from SOFARegistry. In the context of service discovery, the service consumer is the subscriber of the \u0026amp;ldquo;service provider\u0026amp;rsquo;s network address and additional information\u0026amp;rdquo;. Data ID A string that is used to identify the data. In the context of service discovery, DataId usually consists of the service port name, protocol, and version number. It is used as an identifier of the service. Group ID A string that is used for grouping data. It can be used in conjunction with DataId and InstanceId as a namespace identifier of data. Two services may be considered one same service only when their DataIds, GroupIds, and InstanceIds are identical. Instance ID A …","date":-62135596800,"description":"","dir":"projects/sofa-registry/terminology/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b678a49547c55f2a70e2d94dbce5b4a2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/terminology/","summary":"General terminology Term Description Service A software function provided over the network with specific business logic processing capabilities. Service provider A computer node that provides services over the network. Service consumer A computer node that receives services through the network. The same computer node can both be the service provider of some services and the service consumer of others.","tags":null,"title":"Terminology","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/terminology/","wordcount":508},{"author":null,"categories":null,"content":" Unit test Place the unit test cases in the modules developed by yourself.\nIf the cases rely on a third-party server (such as ZooKeeper), you must manually add the profile. See the registry-zookeeper module code.\nIf the cases rely on other modules and integration test is required, place them in the test/test-intergrated module.\nIf the cases also rely on a third-party server (such as ZooKeeper), place them in the test-intergrated-3rd module.\nPerformance test Close the following projects that are closed by default:\n-Dcontext.attachment.enable=false -Dserialize.blacklist.enable=false -Ddefault.tracer= -Dlogger.impl=com.alipay.sofa.rpc.log.SLF4JLoggerImpl -Dmultiple.classloader.enable=false -Devent.bus .enable=false\nA pressure test on BOLT+hessian has been done.\n Server: 4C8G virtual machine; gigabit network; jdk1.8.0_111;\n Client: 50 concurrent requests\n Protocol Request Response Server TPS Average RT (ms) bolt+hessian 1KB string 1KB string Directly return 10000 1.93 bolt+hessian 1KB string 1KB string Directly return 20000 4.13 bolt+hessian 1KB string 1KB string Directly return 30000 7.32 bolt+hessian 1KB string 1KB string Directly return 40000 15.78 bolt+hessian 1KB string 1KB string Directly return 50000 (Close to the utmost limit, error rate: 0.3%) 26.51 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/test/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ccda7c2372a7f55d61f682b72d3b1dc2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/test/","summary":"Unit test Place the unit test cases in the modules developed by yourself.\nIf the cases rely on a third-party server (such as ZooKeeper), you must manually add the profile. See the registry-zookeeper module code.\nIf the cases rely on other modules and integration test is required, place them in the test/test-intergrated module.\nIf the cases also rely on a third-party server (such as ZooKeeper), place them in the test-intergrated-3rd module.","tags":null,"title":"Test","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/test/","wordcount":169},{"author":null,"categories":null,"content":" When using the Bolt protocol for communication, invoke timeout defaults is 3 seconds. You can configure the timeout when referencing the service, and can also configure the timeout period from the dimension of service or method respectively. SOFARPC timeout can be set in milliseconds.\nService If you need to set the timeout from the dimension of service when publishing a service, just configure the timeout parameter to the corresponding value.\nUse XML If you reference the service using XML, set the value of the timeout attribute of the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag under the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation If you reference the service using Annotation, set the value of the timeout attribute of @SofaReferenceBinding:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, timeout = 2000)) private SampleService sampleService; Use API in Spring environment If you reference the service in Spring or Spring Boot environment, just set the value of timeout attribute of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setTimeout(2000) Use API in non-Spring environment If you reference service using the bare API of SOFARPC directly in non-Spring environment, just set the timeout attribute of ConsumerConfig:\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setTimeout(2000); Method If you want to adjust the timeout for a certain method in a service individually, you can set the timeout period from the dimension of method.\nFor a method, the timeout period of the method is prioritized. If not set, the timeout period of the service will be used.\nUse XML If you reference service using XML, just set the timeout attribute of the corresponding \u0026amp;lt;sofa: method\u0026amp;gt;:\n\u0026amp;lt;Sofa: Reference interface = \u0026amp;quot;com.example.demo .SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation No method is available for setting the method-level timeout with Annotation currenty.\nUse API in Spring environment To reference a service in Spring or Spring Boot environment, you can just set the value of timeout attribute of RpcBindingMethodInfo\nBoltBindingParam boltBindingParam = new BoltBindingParam(); RpcBindingMethodInfo rpcBindingMethodInfo = new RpcBindingMethodInfo(); rpcBindingMethodInfo.setName(\u0026amp;quot;hello\u0026amp;quot;); rpcBindingMethodInfo.setTimeout(2000); List\u0026amp;lt;RpcBindingMethodInfo\u0026amp;gt; rpcBindingMethodInfos = new ArrayList\u0026amp;lt;\u0026amp;gt;(); …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-timeout/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"cf14f73dc0c4672a9255ef55b56de419","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","summary":"When using the Bolt protocol for communication, invoke timeout defaults is 3 seconds. You can configure the timeout when referencing the service, and can also configure the timeout period from the dimension of service or method respectively. SOFARPC timeout can be set in milliseconds.\nService If you need to set the timeout from the dimension of service when publishing a service, just configure the timeout parameter to the corresponding value.","tags":null,"title":"Timeout control","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","wordcount":388},{"author":null,"categories":null,"content":" TraceId generation rule SOFATracer uses TraceId to concatenate the call logs of a request on each server. The TraceId is typically generated by the first server that receives the request. The generation rule is: server IP + generated time + incremental sequence + current process ID, such as:\n0ad1348f1403169275002100356696 The first 8 digits 0ad1348f is the IP of the machine that generates TraceId. This is a hexadecimal number, in which every two digits represents a part of IP. Based on the number, we can get a common IP address like 10.209.52.143 by converting every two digits into a decimal number. According to this rule, you can also figure out the first server that the request goes through. The next 13 digits 1403169275002 is the time to generate the TraceId. The next 4 digits 1003 is an auto-incrementing sequence that increases from 1000 to 9000. After reaching 9000, it returns to 1000 and then restarts to increase. The last 5 digits 56696 is the current process ID. Its role in tracerId is to prevent the TraceId conflicts caused by multiple processes in a single machine. Currently, TraceId\u0026amp;rsquo;s generated rules refer to Taobao\u0026amp;rsquo;s Hawkeye components.\n SpanId generation rule The SpanId in SOFATracer represents where the current call is in the entire calling link. If a Web system A receives a user request, then in the SOFATracer MVC log of this system, the recorded SpanId is 0, which means the root node of the entire call. If the system A processes this request and needs to call system B, C, and D through RPC, then the SpanIds in the SOFATracer RPC client log of system A are 0.1, 0.2, and 0.3 respectively. And in the SOFATracer RPC server logs of the system B, C, and D, the SpanIds are also 0.1, 0.2 and 0.3 respectively. If system C calls system E and F when processing the request, then in the corresponding SOFATracer RPC client log of system C, the SpanIds are 0.2.1 and 0.2.2. And the SpanIds in the SOFATracer RPC server logs of system E and F are also 0.2.1 and 0.2.2. As we can known from above, if all SpanIds in a call can be collected to compose a complete link tree.\nWe assume that the TraceId generated in a distributed call is 0a1234 (much longer in practice). Then, according to the generation process of SpanId, the call link tree is as shown in the following figure:\n Currently, SpanId\u0026amp;rsquo;s generated rules refer to Taobao\u0026amp;rsquo;s Hawkeye components.\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/traceid-generated-rule/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"8f0ef8df65deec2a4fa6591a316aa5e8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","summary":"TraceId generation rule SOFATracer uses TraceId to concatenate the call logs of a request on each server. The TraceId is typically generated by the first server that receives the request. The generation rule is: server IP + generated time + incremental sequence + current process ID, such as:\n0ad1348f1403169275002100356696 The first 8 digits 0ad1348f is the IP of the machine that generates TraceId. This is a hexadecimal number, in which every two digits represents a part of IP.","tags":null,"title":"TraceId and spanId generation rule","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","wordcount":415},{"author":null,"categories":null,"content":" TraceId 生成规则 SOFATracer 通过 TraceId 来将一个请求在各个服务器上的调用日志串联起来，TraceId 一般由接收请求经过的第一个服务器产生，产生规则是： 服务器 IP + 产生 ID 时候的时间 + 自增序列 + 当前进程号 ，比如：\n0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，大家也可以根据这个规律来查找到请求经过的第一个服务器。 后面的 13 位 1403169275002 是产生 TraceId 的时间。 之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。 最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。\n TraceId 目前的生成的规则参考了阿里的鹰眼组件。\n SpanId 生成规则 SOFATracer 中的 SpanId 代表本次调用在整个调用链路树中的位置，假设一个 Web 系统 A 接收了一次用户请求，那么在这个系统的 SOFATracer MVC 日志中，记录下的 SpanId 是 0，代表是整个调用的根节点，如果 A 系统处理这次请求，需要通过 RPC 依次调用 B，C，D 三个系统，那么在 A 系统的 SOFATracer RPC 客户端日志中，SpanId 分别是 0.1，0.2 和 0.3，在 B，C，D 三个系统的 SOFATracer RPC 服务端日志中，SpanId 也分别是 0.1，0.2 和 0.3；如果 C 系统在处理请求的时候又调用了 E，F 两个系统，那么 C 系统中对应的 SOFATracer RPC 客户端日志是 0.2.1 和 0.2.2，E，F 两个系统对应的 SOFATracer RPC 服务端日志也是 0.2.1 和 0.2.2。根据上面的描述，我们可以知道，如果把一次调用中所有的 SpanId 收集起来，可以组成一棵完整的链路树。\n我们假设一次分布式调用中产生的 TraceId 是 0a1234（实际不会这么短），那么根据上文 SpanId 的产生过程，有下图：\n SpanId 目前的生成的规则参考了阿里的鹰眼组件。\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/traceid-generated-rule/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8f0ef8df65deec2a4fa6591a316aa5e8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","summary":"TraceId 生成规则 SOFATracer 通过 TraceId 来将一个请求在各个服务器上的调用日志串联起来，TraceId 一般由接收请求经过的第一个服务器产生，产生规则是： 服务器 IP + 产","tags":null,"title":"TraceId 和 SpanId 生成规则","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","wordcount":707},{"author":null,"categories":null,"content":"By default, SOFARPC has integrated SOFATracer. Also, you can use other APM products, such as Skywalking, to achieve the corresponding functions. For details, see the relevant documents:\n SOFATracer Skywalking If you want to disable the tracing ability of SOFARPC, you can do it in two ways.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment, you can add a configuration com.alipay.sofa.rpc.defaultTracer= in application.properties.\nIf you are using sofa-rpc-all directly, you can add the following code in the main method of your application before publish any SOFARPC service or create any SOFARPC reference.\nRpcConfigs.putValue(RpcOptions.DEFAULT_TRACER, \u0026amp;quot;\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/tracing-usage/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5f944f87d827ae060fb0528f6715af97","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","summary":"By default, SOFARPC has integrated SOFATracer. Also, you can use other APM products, such as Skywalking, to achieve the corresponding functions. For details, see the relevant documents:\n SOFATracer Skywalking If you want to disable the tracing ability of SOFARPC, you can do it in two ways.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment, you can add a configuration com.alipay.sofa.rpc.defaultTracer= in application.properties.\nIf you are using sofa-rpc-all directly, you can add the following code in the main method of your application before publish any SOFARPC service or create any SOFARPC reference.","tags":null,"title":"Tracing","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","wordcount":96},{"author":null,"categories":null,"content":" Use client API In the design of SOFALookout client, API is decoupled from the implementation. If you need to log the events based on the SOFALookout API, you only need to add the lookout-api Maven dependency to the pom.xml file in your application/project. If the dependencies (such as client dependencies or SOFABoot (Spring Boot) Starter) do not exist, the API package uses NoopRegistry automatically, to replace all the locations of which the events are logged.\n1.Introduce API dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.About ID Compared to the traditional metrics library\u0026amp;rsquo;s single-dimensional information description, Lookout metrics provides tag capability that supports multi-dimensional descriptions. ID class, the unique identification of Lookout metrics, consists of name and tags.\nId basicId = registry.createId(\u0026amp;quot;rpc.provider.service.stats\u0026amp;quot;); id = basicId.withTag(\u0026amp;quot;service\u0026amp;quot;, \u0026amp;quot;com.alipay.demo.demoService\u0026amp;quot;) .withTag(\u0026amp;quot;method\u0026amp;quot;, \u0026amp;quot;sayHi\u0026amp;quot;) .withTag(\u0026amp;quot;protocol\u0026amp;quot;, \u0026amp;quot;tr\u0026amp;quot;) .withTag(\u0026amp;quot;alias\u0026amp;quot;, \u0026amp;quot;group1\u0026amp;quot;); The above is a simple example of ID introducing how to create ID and how to tag. Note that every time you tag, a new ID object is generated and returned.\n Do not proactively cache Id or the specific Metric object, since Lookout\u0026amp;rsquo;s Registry has already recorded. When using a same Id (with the same name and tags), the existing Id and its corresponding Metric object will be reused.\n 2.1 Priority tag (optional) PRIORITY enumeration level: HIGH, NORMAL, LOW.\nid.withTag(LookoutConstants.LOW_PRIORITY_TAG); It is recommended that you do not add this tag, the default level will be NORMAL. The level represents the collection interval (HIGH: 2s, NORMAL: 30s, LOW: 1min).\n2.2 About tags General tags, such as local IP, data center, and other details, will be attached and no need to be specified separately. In a non-SOFABoot project, you must manually add tags to the client, especially the app tag which specifies the app name: app=appName. key contains only lowercase letters, numbers, and underscores. (especially the metrics at runtime, such as Counter, Timer, and DistributeSummary) The values ​​of a tag shall be within a stable finite set. Try to use as few tags as possible to prevent the number of metrics from exceeding the maximum limit. For example: In RPC service, the value of method\u0026amp;rsquo;s two tags shall be as few as possible. The counterexample is that each RPC call has a separate tag-value. Therefore, the overall principle is that there should be as few custom tags as possible, and the number of sets of the values ​​should be as small as possible. Specialized TAG name \u0026amp;ldquo;priority\u0026amp;rdquo; indicates priority. The tag key reserved by the system is _*_. Starting with an underscore and ending with an …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-api/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"76574f2435a3565fe1fc50831ff9ab0c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","summary":"Use client API In the design of SOFALookout client, API is decoupled from the implementation. If you need to log the events based on the SOFALookout API, you only need to add the lookout-api Maven dependency to the pom.xml file in your application/project. If the dependencies (such as client dependencies or SOFABoot (Spring Boot) Starter) do not exist, the API package uses NoopRegistry automatically, to replace all the locations of which the events are logged.","tags":null,"title":"Use API","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","wordcount":911},{"author":null,"categories":null,"content":" SOFARPC Service publishing The process of service publishing involves three classes RegistryConfig, ServerConfig, ProviderConfig.\n RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;) RegistryConfig represents the registry center. As above, the address and port of the service registry center is 127.0.0.1:2181, and the protocol is Zookeeper.\n ServerConfig java ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ServerConfig represents the container where service runs. The above declares a server using the 8803 port and the bolt protocol.\n ProviderConfig\nProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt;() .setInterfaceId(HelloWorldService.class.getName()) .setRef(new HelloWorldServiceImpl()) .setServer(serverConfig) .setRegistry(registryConfig); providerConfig.export(); ProviderConfig represents service publishing. The above declares the interface of the service, implements the server running the service, and eventually publishes the service by the export method.\nService reference Service reference involves two classes, namely RegistryConfig and ConsumerConfig.\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig); HelloService helloService = consumerConfig.refer(); ConsumerConfig represents service reference. The above declares the interface and service registry center of the referenced service interface, and finally references the service by the refer method to get the proxy for the remote call of the service.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-rpc/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ee6f74a4974c7abf72322cef108d5ef0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","summary":"SOFARPC Service publishing The process of service publishing involves three classes RegistryConfig, ServerConfig, ProviderConfig.\n RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026quot;zookeeper\u0026quot;) .setAddress(\u0026quot;127.0.0.1:2181\u0026quot;) RegistryConfig represents the registry center. As above, the address and port of the service registry center is 127.0.0.1:2181, and the protocol is Zookeeper.\n ServerConfig java ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026quot;bolt\u0026quot;); ServerConfig represents the container where service runs. The above declares a server using the 8803 port and the bolt protocol.","tags":null,"title":"Use API in non-Spring environment","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","wordcount":173},{"author":null,"categories":null,"content":" This article describes how to quickly start installing and configuring Istio by using Docker Compose.\nSOFAMosn can not only support the standard Istio deployment mode, but also support the unilateral Inbound Sidecar or Outbound Sidecar deployment mode to meet the various requirements of users.\nPrerequisites Docker Docker Compose Install Istio Download the latest release package. Unzip the installation file and go to the decompressed path. The installation path contains: Sample application path samples/. The istioctl client executable file which is in the /bin path. The istioctl can be used to create routing rules and policies. Configuration file istion.VERSION. Add the Istio\u0026amp;rsquo;s bin path to your system\u0026amp;rsquo;s PATH. For example, execute the following command in the MacOS or Linux operating system:\nexport PATH=$PWD/bin;$PATH Pull up the Istio control plane container: SHELL docker-compose -f install/zookeeper/istio.yaml up -d Ensure that all Docker containers are running:\ndocker ps -a If the Istio pilot container terminates unexpectedly, you can run the istioctl context-create command and re-execute the previous command. 6. Configure istioctl to use the Istio API server:\nistioctl context-create -context istio-local --api-server Deploy application Now, you can start deploying the SOFABoot demo program. The demo program includes a client and a server, which communicate with each other through Bolt protocol.\ndocker-compose up -f sofa-sample-spec.yaml up -d Uninstall Istio docker-compose up -f install/zookeeper/istio.yaml down ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1de4868fa0e9c73d932343847864d7fb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","summary":"This article describes how to quickly start installing and configuring Istio by using Docker Compose.\nSOFAMosn can not only support the standard Istio deployment mode, but also support the unilateral Inbound Sidecar or Outbound Sidecar deployment mode to meet the various requirements of users.\nPrerequisites Docker Docker Compose Install Istio Download the latest release package. Unzip the installation file and go to the decompressed path. The installation path contains: Sample application path samples/.","tags":null,"title":"Use Docker to get started with Istio","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","wordcount":219},{"author":null,"categories":null,"content":" Introduction This section is intended to demonstrate how to use Jarslink 2.0 to dynamically control the life cycle of the Biz package and to complete its installation, uninstallation, and query.\nDemo With reference to How to reform common Spring Boot applications, the reformed spring-boot-transform-sample project has integrated the Jarslink 2.0 component. By executing the Ark package that the application packaged and generated, you can dynamically install or uninstall the application during its running.\n java -jar starts the spring-boot-transform-sample application Ark package. telnet localhost 1234 enters the Jarslink 2.0 command interface, as follows:\n\u0026amp;gt; telnet localhost 1234 s \u0026amp;gt; Trying 127.0.0.1\u0026amp;hellip;\n\u0026amp;gt; Connected to localhost.\n\u0026amp;gt; Escape character is \u0026amp;lsquo;^]\u0026amp;rsquo;.\n\u0026amp;gt; sofa-ark\u0026amp;gt; Execute the check -b query command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=1\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt; With reference to How to reform a common Spring Boot application, create any SOFABoot application of non-Web type, package it into a Biz package, and execute the install -b installation command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;install -b file:///Users/qilong.zql/Desktop/test-ark-biz.jar\n\u0026amp;gt; Biz:\u0026amp;lsquo;test-biz:1.0.0\u0026amp;rsquo; is installing. \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the check -b query command again, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=2\n\u0026amp;gt; bizName=\u0026amp;lsquo;test-biz\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo;\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the uninstall -b -n -v uninstallation command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;uninstall -b -n test-biz -v 1.0.0\n\u0026amp;gt; Uninstall biz:\u0026amp;lsquo;test-biz:1.0.0\u0026amp;rsquo; success. \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the check -b query command again, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=1\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n For use of more commands, refer to Interactive Commands.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"749f6debe73b73b4882477779008bb99","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","summary":"Introduction This section is intended to demonstrate how to use Jarslink 2.0 to dynamically control the life cycle of the Biz package and to complete its installation, uninstallation, and query.\nDemo With reference to How to reform common Spring Boot applications, the reformed spring-boot-transform-sample project has integrated the Jarslink 2.0 component. By executing the Ark package that the application packaged and generated, you can dynamically install or uninstall the application during its running.","tags":null,"title":"Use Jarslink for multi-application dynamic deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","wordcount":277},{"author":null,"categories":null,"content":" This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio. Serving as a critical component of SOFAMesh, MOSN is used to complete data plane forwarding.\nThe following figure shows the workflow chart of MOSN based on the overall SOFAMesh framework.\nNote: Currently, MOSN cannot be directly used in the native Istio.\nPreparations This guide supposes you are using macOS. For other operating systems, you can install the corresponding software.\n1. Install HyperKit Install docker-for-mac, and then install driver.\n1.1 Install Docker Download the Docker software package to install it or run the following command to install it:\n$ brew cask install docker 1.2 Install driver $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. Install Minikube (or purchase the commercial version of k8s cluster) It is recommended to use Minikube V0.28 or later, see https://github.com/kubernetes/minikube.\n$ brew cask install minikube 3. Start Minikube Note that Pilot requires at least 2G memory, so you can add resources to Minikube by adding parameters at startup. If your machine has insufficient resources, it is recommended to use the commercial version of the k8s cluster.\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit Create Istio namespace\n$ kubectl create namespace istio-system 4. Install kubectl command line tool kubectl is a command line interface used to run commands for k8s cluster. For how to install it, see https://kubernetes.io/docs/tasks/tools/install-kubectl.\n$ brew install kubernetes-cli 5. Install Helm Helm is a package management tool for k8s. For how to install it, see https://docs.helm.sh/using_helm/#installing-helm.\n$ brew install kubernetes-helm Deploy SOFAMesh with source codes 1. Download SOFAMesh source codes $ git clone git@github.com:sofastack/sofa-mesh.git 2. Use Helm to install SOFAMesh You should change directory to sofa-mesh source code, and then use helm template to install isito crd and istio\n``` $ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template …","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-with-sofamesh/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"9c6461e92180417d3a8ec4f3f2c723fe","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","summary":"This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio.","tags":null,"title":"Use MOSN to build Service Mesh platform","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","wordcount":1078},{"author":null,"categories":null,"content":" This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio. Serving as a critical component of SOFAMesh, MOSN is used to complete data plane forwarding.\nThe following figure shows the workflow chart of MOSN based on the overall SOFAMesh framework.\nNote: Currently, MOSN cannot be directly used in the native Istio.\nPreparations This guide supposes you are using macOS. For other operating systems, you can install the corresponding software.\n1. Install HyperKit Install docker-for-mac, and then install driver.\n1.1 Install Docker Download the Docker software package to install it or run the following command to install it:\n$ brew cask install docker 1.2 Install driver $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. Install Minikube (or purchase the commercial version of k8s cluster) It is recommended to use Minikube V0.28 or later, see https://github.com/kubernetes/minikube.\n$ brew cask install minikube 3. Start Minikube Note that Pilot requires at least 2G memory, so you can add resources to Minikube by adding parameters at startup. If your machine has insufficient resources, it is recommended to use the commercial version of the k8s cluster.\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit Create Istio namespace\n$ kubectl create namespace istio-system 4. Install kubectl command line tool kubectl is a command line interface used to run commands for k8s cluster. For how to install it, see https://kubernetes.io/docs/tasks/tools/install-kubectl.\n$ brew install kubernetes-cli 5. Install Helm Helm is a package management tool for k8s. For how to install it, see https://docs.helm.sh/using_helm/#installing-helm.\n$ brew install kubernetes-helm Deploy SOFAMesh with source codes 1. Download SOFAMesh source codes $ git clone git@github.com:sofastack/sofa-mesh.git 2. Use Helm to install SOFAMesh You should change directory to sofa-mesh source code, and then use helm template to install isito crd and istio\n``` $ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template …","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-run-with-sofamesh/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7353dfd1d668eb3e2a1c8cd26acca372","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","summary":"This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio.","tags":null,"title":"Use MOSN to build Service Mesh platform","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","wordcount":1078},{"author":null,"categories":null,"content":" Use Registry Different Registry integrations provide different ways to access Metrics.\n1. LookoutRegistry Provides the ability to count metrics by a time window. It is divided into two modes: “active” and “passive”. The passive mode is off currently.\n(1) Active mode\n You can specify the IP address of the remote agent through [Client Configuration], that is, check when start reporting, and regularly report data.\n(2) Passive mode\n This mode can be activated through [Client Configuration], and HTTP service is provided on port 19399.\n2. Connect to Prometheus The data of SOFALookout can be shared with Prometheus. In order to connect to Prometheus, you first need to add dependencies to your project:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-reg-prometheus\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; After adding the dependencies, launch the application, and you can see the data by visiting http://localhost:9494, where 9494 is the default port, you can configure com.alipay.sofa.lookout.prometheus-exporter-server-port in application.properties to change the port.\nOnce you have the URL to access the data, you can edit a prometheus.yml to grab the project information. Assuming that the local IP address is 10.15.232.20, you can configure prometheus.yml as follows:\nscrape_configs: - job_name: \u0026#39;lookout-client\u0026#39; scrape_interval: 5s static_configs: - targets: [\u0026#39;10.15.232.20:9494\u0026#39;] With the above configuration file, you can start Prometheus locally via Docker:\ndocker run -d -p 9090:9090 -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml --name prom prom/prometheus:master Then visit http://localhost:9090 through the browser, and you can query the corresponding Metrics through PromQL.\nAn example of connecting to Prometheus is also available in SOFALookout, so you can go and see it as a reference.\n3. Connect to SpringBoot actuator In addition to Prometheus, SOFALookout can be integrated with the Actuator of SpringBoot 1.x by adding the following dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Then, start and visit http://localhost:8080/metrics to see the data of events logged by the SOFALookout API.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-registry/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3c51ba6519cee542b459a170dabcf32b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","summary":"Use Registry Different Registry integrations provide different ways to access Metrics.\n1. LookoutRegistry Provides the ability to count metrics by a time window. It is divided into two modes: “active” and “passive”. The passive mode is off currently.\n(1) Active mode\n You can specify the IP address of the remote agent through [Client Configuration], that is, check when start reporting, and regularly report data.\n(2) Passive mode\n This mode can be activated through [Client Configuration], and HTTP service is provided on port 19399.","tags":null,"title":"Use Registry","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","wordcount":297},{"author":null,"categories":null,"content":" XML mode Declare the xsd file of SOFABoot: In the XML configuration file to be used, configure the declaration of the header xsd file to the followings. This enables development using the XML elements defined by SOFABoot.\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www .w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xmlns:context=\u0026amp;quot;http://www.springframework.org/schema/context\u0026amp;quot; xsi:schemaLocation =\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack .io/schema/sofaboot.xsd\u0026amp;quot; The way to publish and reference services in xml mode is as follows. sofa:service represents publishing service, and sofa:reference represents referencing service. sofa:binding indicates the protocol for service publishing or reference.\n\u0026amp;lt;bean id=\u0026amp;quot;personServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; A service can also be published through multiple protocols, as follows:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Service reference\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; A service can also be referenced through other protocols:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceRest\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-xml/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"9192a93415bee3070a9be62c0f693949","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","summary":"XML mode Declare the xsd file of SOFABoot: In the XML configuration file to be used, configure the declaration of the header xsd file to the followings. This enables development using the XML elements defined by SOFABoot.\n\u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;beans xmlns=\u0026quot;http://www.springframework.org/schema/beans\u0026quot; xmlns:xsi=\u0026quot;http://www .w3.org/2001/XMLSchema-instance\u0026quot; xmlns:sofa=\u0026quot;http://sofastack.io/schema/sofaboot\u0026quot; xmlns:context=\u0026quot;http://www.springframework.org/schema/context\u0026quot; xsi:schemaLocation =\u0026quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack .io/schema/sofaboot.xsd\u0026quot; The way to publish and reference services in xml mode is as follows. sofa:service represents publishing service, and sofa:reference represents referencing service.","tags":null,"title":"Use XML in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","wordcount":130},{"author":null,"categories":null,"content":" Use annotation for service publishing/reference In addition to the regular xml mode, it is also supported to publish and reference services with annotation in the SOFABoot environment. Similar to xml, we provide @SofaService and @SofaReference as well as @SofaServiceBinding and @SofaReferenceBinding annotation for multi-protocol.\nService publishing To publish an RPC service, you only need to add a @SofaService annotation on the bean to specify the interface and protocol type.\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } Service reference For a bean that needs to reference a remote service, you only need to add the @SofaReference annotation on the attribute or method. This supports the bolt, dubbo, rest protocol.\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } Use the demo You can test in the annotation subproject of the sample project.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-annotation/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2c3afd33cbce4f5aa2473716b3afe5a6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","summary":"Use annotation for service publishing/reference In addition to the regular xml mode, it is also supported to publish and reference services with annotation in the SOFABoot environment. Similar to xml, we provide @SofaService and @SofaReference as well as @SofaServiceBinding and @SofaReferenceBinding annotation for multi-protocol.\nService publishing To publish an RPC service, you only need to add a @SofaService annotation on the bean to specify the interface and protocol type.","tags":null,"title":"Use annotation in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","wordcount":182},{"author":null,"categories":null,"content":" This topic mainly describes a JRaft-based distributed counter.\nScenario Save a distributed counter in a raft group of multiple nodes (servers). The counter can increment and be called while remaining consistent among all nodes. The counter can normally provide two external services when a minority of nodes fail:\n incrmentAndGet(delta): increments the value of delta and returns the incremented value. get(): gets the latest value. Remote procedure calls (RPCs) JRaft adopts the Bolt communication framework at the underlayer, and defines two requests:\n IncrementAndGetRequest: used for incrementing the value public class IncrementAndGetRequest implements Serializable { private static final long serialVersionUID = -5623664785560971849L; private long delta; public long getDelta() { return this.delta; } public void setDelta(long delta) { this.delta = delta; } } GetValueRequest: used for getting the latest value public class GetValueRequest implements Serializable { private static final long serialVersionUID = 9218253805003988802L; public GetValueRequest() { super(); } } ValueResponse responses include:\n success: indicates that the request was successful value: the latest value returned by a successful request errorMsg: the error message of a failed request redirect: indicates that a leader election occurred and the request needs to be sent to the new leader node public class ValueResponse implements Serializable { private static final long serialVersionUID = -4220017686727146773L; private long value; private boolean success; /** * redirect peer id */ private String redirect; private String errorMsg; public String getErrorMsg() { return this.errorMsg; } public void setErrorMsg(String errorMsg) { this.errorMsg = errorMsg; } ...... } IncrementAndAddClosure: used for receiving requests at the leader node IncrementAndGetRequest: used for handling callbacks of the request public class IncrementAndAddClosure implements Closure { private CounterServer counterServer; private IncrementAndGetRequest request; private ValueResponse response; private Closure done; // The network response callback public IncrementAndAddClosure(CounterServer counterServer, IncrementAndGetRequest request, ValueResponse response, Closure done) { super(); this.counterServer = counterServer; this.request = request; this.response = response; this.done = done; } @Override public void run(Status status) { // Return the response to the client if (this.done != null) { done.run(status); } } public IncrementAndGetRequest getRequest() { return this.request; } public void setRequest(IncrementAndGetRequest request) { this.request = request; } public ValueResponse getResponse() { return this.response; } } Server CounterStateMachine First hold an initial value:\npublic class CounterStateMachine extends StateMachineAdapter { /** * counter value */ private AtomicLong value = new AtomicLong(0); Implement the core onApply(iterator) method, and apply the user request to the state machine: …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/counter-example/","fuzzywordcount":1900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f9c54b9f7883ccb1d7c259b7101f4674","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/counter-example/","publishdate":"0001-01-01T00:00:00Z","readingtime":9,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/counter-example/","summary":"This topic mainly describes a JRaft-based distributed counter.\nScenario Save a distributed counter in a raft group of multiple nodes (servers). The counter can increment and be called while remaining consistent among all nodes. The counter can normally provide two external services when a minority of nodes fail:\n incrmentAndGet(delta): increments the value of delta and returns the incremented value. get(): gets the latest value. Remote procedure calls (RPCs) JRaft adopts the Bolt communication framework at the underlayer, and defines two requests:","tags":null,"title":"Use case of a counter","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/counter-example/","wordcount":1859},{"author":null,"categories":null,"content":" SOFABoot provides a class isolation framework SOFAArk, giving Spring Boot a class isolation ability to resolve class or package conflicts in the development. For detailed information, please refer to:SOFAArk\nTo use this feature in SOFABoot projects, we need only two steps: configure the sofa-ark-maven-plugin plugins for packaging and add sofa-ark-springboot-starter dependencies of the class isolation framework.\nConfigure Maven packaging plugins The Maven plugins - sofa-ark-maven-plugin are available on the Central Repository. Through simple configurations, a SpringBoot project can be wrapped into an executable Ark package in the standard format. The coordinate of sofa-ark-maven-plugin is:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; The configuration template is described as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- all class exported by ark plugin would be resolved by ark biz in default, if configure denyImportClasses, then it would prefer to load them by ark biz itself --\u0026amp;gt; \u0026amp;lt;denyImportClasses\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass1\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass2\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/denyImportClasses\u0026amp;gt; \u0026amp;lt;!-- Corresponding to denyImportClasses, denyImportPackages is package-level --\u0026amp;gt; \u0026amp;lt;denyImportPackages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/denyImportPackages\u0026amp;gt; \u0026amp;lt;!-- denyImportResources can prevent resource exported by ark plugin with accurate name to be resolved --\u0026amp;gt; \u0026amp;lt;denyImportResources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test1.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test2.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;/denyImportResources\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Description of plugin configuration:\n outputDirectory: Execute mvn package and then specify a directory to store the Ark package. The default directory is ${project. Build. Directory}. arkClassifier: Execute mvn docleoy, and then specify the coordinates of Maven repositories to locate the Ark package by setting the classfaulter value (the default is empty). We recommend that you configure this to give a different name from the ordinary Fat jar; denyImportClasses: By default, the application will first load …","date":-62135596800,"description":"","dir":"projects/sofa-boot/classloader-isolation/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e007416ab008c1dd4b886433dbf8af01","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","summary":"SOFABoot provides a class isolation framework SOFAArk, giving Spring Boot a class isolation ability to resolve class or package conflicts in the development. For detailed information, please refer to:SOFAArk\nTo use this feature in SOFABoot projects, we need only two steps: configure the sofa-ark-maven-plugin plugins for packaging and add sofa-ark-springboot-starter dependencies of the class isolation framework.\nConfigure Maven packaging plugins The Maven plugins - sofa-ark-maven-plugin are available on the Central Repository.","tags":null,"title":"Use class isolation in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","wordcount":1129},{"author":null,"categories":null,"content":" Use API SOFABoot provides a set of programming APIs for RPC service publishing and reference. It is convenient to publish and reference RPC services directly in the code. Similar to Spring\u0026amp;rsquo;s ApplicationContextAware, in order to use the programming API, you first need to implement the ClientFactoryAware interface to get the programming component API:\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } With DirectService as an example, see how to use the clientFactory to publish an RPC service through the programming API:\nServiceClient serviceClient = clientFactory.getClient(ServiceClient.class); ServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(DirectService.class); serviceParam.setInstance(new DirectServiceImpl()); List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); serviceClient.service (serviceParam); In the code above:\n First, get the ServiceClient object through the clientFactory. Then, construct the ServiceParam object, which contains the parameters required to publish the service, and use the setInstance method to set the object to be published as an RPC service, setInterfaceType to set the interface of the service. Finally, call the service method of ServiceClient to publish an RPC service. The code that references the RPC service through the programming API is similar:\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt;(); referenceParam.setInterfaceType(DirectService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); DirectService proxy = referenceClient.reference(referenceParam); proxy.sayDirect(\u0026amp;quot;hello\u0026amp;quot;); Likewise, to reference an RPC service, the code simply needs to get a ReferenceClient from the ClientFactory and then construct a ReferenceParam similar to publishing a service, next set up the service interface, and finally call the ReferenceClient\u0026amp;rsquo;s reference method.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-api/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2679388dc3459714f869d8f8a71739d7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","summary":"Use API SOFABoot provides a set of programming APIs for RPC service publishing and reference. It is convenient to publish and reference RPC services directly in the code. Similar to Spring\u0026rsquo;s ApplicationContextAware, in order to use the programming API, you first need to implement the ClientFactoryAware interface to get the programming component API:\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } With DirectService as an example, see how to use the clientFactory to publish an RPC service through the programming API:","tags":null,"title":"Use dynamic API in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","wordcount":255},{"author":null,"categories":null,"content":" User guide Maven coordinator \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Check release notes for the version information.\n 1. Basic functions 1.1. Implement user request processor (UserProcessor) We provide two types of user request processors: SyncUserProcessor and AsyncUserProcessor. The difference between them is that the former returns the processing result in the form of a return value in the current processor thread, while the latter has an AsyncContext stub and can call the sendResponsemethod in the current thread or an asynchronous thread to return the processing result. For examples, refer to the following two types:\n Synchronous request processor Asynchronous request processor 1.2 Implement connection event processor (ConnectionEventProcessor) We provide two connection event processors: ConnectionEventType.CONNECT and ConnectionEventType.CLOSE. You can create your own event processors and register them with the client or the server. The client side and server side can each monitor both of their connection and disconnection events.\n Process connection event Process disconnection event 1.3 Client side and server side initialization (RpcClient, RpcServer) We have provided an RpcClient and RpcServer. They can be used after going through a simple initialization of necessary functions, or after switching on the functions. The most simple example is as follows:\n Client side initialization example Server side initialization example 1.4 Basic communication model We have provided four types of communication models:\n1. Oneway calls\nThe current thread initiates a call that is not interested in the call result and is not subject to timeout control. As long as the request is sent out, the call is completed. Note: Oneway calls are not guaranteed to succeed, and the initiator of the call has no way of knowing its result. For that reason, these calls are usually used in scenarios that can be retried or that have fixed-time notifications. Network problems or machine malfunctions during the call process may result in failure. This kind of call should only be used in business scenarios that accept such exceptions. For more information, see Example.\n2. Sync calls\nThe current thread initiates a call that only completes if it receives a result within the set timeout time. If a result is not received within the timeout time, it will generate a timeout error. This is the most commonly used call type. Ensure that the timeout time is set reasonably in accordance with the opposing terminal\u0026amp;rsquo;s processing capacity. For more information, see Example.\n3. Future calls\nThe current thread initiates a call and can then move onto executing the next call after getting an RpcResponseFuture object. The get() method of the RpcResponseFuture object can be used at any time to get the result. If the response has already been returned, the result …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-handbook/","fuzzywordcount":2000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2a0a2e3c7749dbcdceea064f6f850e33","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","publishdate":"0001-01-01T00:00:00Z","readingtime":10,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","summary":"User guide Maven coordinator \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Check release notes for the version information.\n 1. Basic functions 1.1. Implement user request processor (UserProcessor) We provide two types of user request processors: SyncUserProcessor and AsyncUserProcessor. The difference between them is that the former returns the processing result in the form of a return value in the current processor thread, while the latter has an AsyncContext stub and can call the sendResponsemethod in the current thread or an asynchronous thread to return the processing result.","tags":null,"title":"User guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","wordcount":1988},{"author":null,"categories":null,"content":" ## Version release\nVersion No. Major, minor, and revision version numbers are used. For example 2.0.0.\nRefer to: http://semver.org/lang/zh-CN/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Revision version number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance At most two versions can be maintained simultaneously.\nFor example, if the current major version is 2.2.0, the BugFix version 2.1.x will be maintained and bugs in version 2.0.x will no longer be fixed and a version upgrade is recommended.\nRelease process Daily development uses the SNAPSHOT version, such as 2.0.0-SNAPSHOT. When the modified version is officially released, the version number is revised to a formal version, such as 2.0.0. After release, the next version is pulled up, for example, 2.1.0-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-version/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b82f2d74eff3937e10f15b13cb503751","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","summary":"## Version release\nVersion No. Major, minor, and revision version numbers are used. For example 2.0.0.\nRefer to: http://semver.org/lang/zh-CN/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Revision version number: represents the BugFix version.","tags":null,"title":"Version release","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","wordcount":175},{"author":null,"categories":null,"content":" Version number The system adopts a three-digit versioning scheme. The three digits respectively are major version number, minor version number, and revision number, for example: 5.1.2.\nFor more information, see the http://semver.org/lang/zh-CN/.\n Major version number: All versions in the major version number must be compatible with each other. It is not necessary to be fully compatible with other major version numbers, but it is best to have backward compatibility. Minor version number: Represents new feature enhancements. The larger the version number, the richer the feature. Revision number: Represents the BugFix version. The revision number is only for bug fixes. The larger the version number, the more stable it is. Version maintenance You can maintain up to two versions at the same time.\nFor example, the current trunk is 5.3.0, then the bugfix branch of 5.2.x will be maintained. When any bugs arise in 5.1.x, users are prompted to upgrade the system.\nRelease process The daily development branch uses the SNAPSHOT version, for example: 5.3.0-SNAPSHOT. When it comes to official release, you can modify the version to official version, for example: 5.3.0. Pull up the next version after release, for example: 5.3.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/version-release/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"604f113607e6815757f4d1907190c13c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/version-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/version-release/","summary":"Version number The system adopts a three-digit versioning scheme. The three digits respectively are major version number, minor version number, and revision number, for example: 5.1.2.\nFor more information, see the http://semver.org/lang/zh-CN/.\n Major version number: All versions in the major version number must be compatible with each other. It is not necessary to be fully compatible with other major version numbers, but it is best to have backward compatibility.","tags":null,"title":"Version release","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/version-release/","wordcount":191},{"author":null,"categories":null,"content":" Version number Major, minor, and revision version numbers are used. For example, 1.0.0.\nFor more information, see https://semver.org/\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has. Revision version number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance Up to two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 1.2.0, the BugFix branch 1.1.x will be maintained, but bugs in branch 1.0.x will no longer be fixed. In this case, a version upgrade is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 1.0.0-SNAPSHOT. Upon formal release, the snapshot version is modified to the formal version, for example 1.0.0. After the formal release, the next version is pulled, for example, 1.0.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/version-rule/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a2093bdf478bdff0e15a2de70e522d03","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/version-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/version-rule/","summary":"Version number Major, minor, and revision version numbers are used. For example, 1.0.0.\nFor more information, see https://semver.org/\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has.","tags":null,"title":"Version rules","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/version-rule/","wordcount":180},{"author":null,"categories":null,"content":" Version number SOFARegistry uses a three-digit version number in the form of major, minor, and patch. For example, 5.2.0.\nFor more information, see https://semver.org/.\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has. Patch number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance Up to two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 5.4.0, the BugFix branch of version 5.3.x will be maintained, but bugs in branch 5.2.x will no longer be fixed. Therefore, a version upgrade for 5.2.x is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 5.3.0-SNAPSHOT. Upon formal release, SNAPSHOT is replaced with a formal version number, for example 5.3.0. After the formal release, the next version is pulled, for example, 5.3.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-standard/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"71aad9cbc42aba3d9f875ae9169cf005","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/release-standard/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/release-standard/","summary":"Version number SOFARegistry uses a three-digit version number in the form of major, minor, and patch. For example, 5.2.0.\nFor more information, see https://semver.org/.\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has.","tags":null,"title":"Version rules","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/release-standard/","wordcount":186},{"author":null,"categories":null,"content":" With SOFABoot, we can directly view the version of SOFA middleware and other detailed information in the browser.\nIntroducing SOFABoot Infra Dependency To view the version information of the SOFA middleware directly in the browser in SOFABoot, all you need to do is add the following to the Maven dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;infra-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Version Information Viewing After an application started successfully, you can visit http://localhost:8080/sofaboot/versions in the browser to view the version information of the SOFA middleware, the response such as:\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Build-Time: \u0026amp;quot;2018-04-05T20:55:22+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.0\u0026amp;quot; } ] ** Note: In SOFABoot 3.x, the endpoint path has been changed from sofaboot/versions to actuator/versions**.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/view-versions/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c6b6d22e9038aa1f5e4ce74449ba1cda","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/view-versions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/view-versions/","summary":"With SOFABoot, we can directly view the version of SOFA middleware and other detailed information in the browser.\nIntroducing SOFABoot Infra Dependency To view the version information of the SOFA middleware directly in the browser in SOFABoot, all you need to do is add the following to the Maven dependency:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;infra-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Version Information Viewing After an application started successfully, you can visit http://localhost:8080/sofaboot/versions in the browser to view the version information of the SOFA middleware, the response such as:","tags":null,"title":"View version","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/view-versions/","wordcount":115},{"author":null,"categories":null,"content":"The warm-up weight feature allows the client machine to distribute traffic based on the corresponding weight of the server. This feature is also often used in the scenario where a few machines within a cluster are being started. The server machines can be warmed up in a short time with the traffic weight function, and then continue to receive the normal traffic.\nThe operating mechanism is as follows: When the server service starts, it pushes its own warm-up duration, weight during warm-up, and normal weight after warm-up to the Service Registry. As shown above, Service B points to Service Registry.\n When referencing service, the client obtains the warm-up weight information of each service instance. As shown above, Service Registry points to client.\n When calling service, the client distributes the traffic according to the warm-up weight of the address where the service is located. As shown above, the client points to Service A and Service B. Service A has completed warm-up, and its weight is 100 by default. Service B is in the warm-up period, and its weight is 10. Therefore, their traffic is 100%110 and 10%110 respectively.\n This feature is used as follows:\nProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt;() .setWeight(100) .setParameter(ProviderInfoAttrs.ATTR_WARMUP_WEIGHT,\u0026amp;quot;10\u0026amp;quot;) .setParameter(ProviderInfoAttrs.ATTR_WARM_UP_END_TIME, \u0026amp;quot;12000\u0026amp;quot;); As above, the warm-up duration of the service is 12s, the weight is 10 during warm-up, and the normal weight after warm-up is 100. If the service is published on two machines, such as machine A and B, and the machine A is in the warm-up period with the above configuration, while B has already completed warm-up, and the normal weight is 200, then when the client calls the service, the proportion of traffic distribution is 10:200. After the machine A is warmed up, the traffic distribution ratio is 100:200.\nIn SOFABoot, the warm-up duration and the weight during and after warm-up can be configured as follows:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleRestFacadeReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.endpoint.facade.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs weight=\u0026amp;quot;100\u0026amp;quot; warm-up-time=\u0026amp;quot;10000\u0026amp;quot; warm-up-weight=\u0026amp;quot;1000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/provider-warmup-weight/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b9e320dfaa4f9700ecdca67d76e07d54","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","summary":"The warm-up weight feature allows the client machine to distribute traffic based on the corresponding weight of the server. This feature is also often used in the scenario where a few machines within a cluster are being started. The server machines can be warmed up in a short time with the traffic weight function, and then continue to receive the normal traffic.\nThe operating mechanism is as follows: When the server service starts, it pushes its own warm-up duration, weight during warm-up, and normal weight after warm-up to the Service Registry.","tags":null,"title":"Warm-up weight","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","wordcount":319},{"author":null,"categories":null,"content":" X-Protocol X-Protocol is a special common protocol supported by SOFAMesh. It can access different RPC protocols in a unified manner. Because it doesn\u0026amp;rsquo;t require to parse protocols, it can not only provide higher performance, but also reduce the development cost of accessing new protocols.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-x-protocol/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"220f4a76b277463bb1f7201519950450","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","summary":"X-Protocol X-Protocol is a special common protocol supported by SOFAMesh. It can access different RPC protocols in a unified manner. Because it doesn\u0026rsquo;t require to parse protocols, it can not only provide higher performance, but also reduce the development cost of accessing new protocols.","tags":null,"title":"X-Protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","wordcount":44},{"author":null,"categories":null,"content":"X-Protocol 协议是 SOFAMesh 支持的特殊通用协议，能够以统一的方式接入不同的 RPC 协议，因为无需进行协议解析，不仅能够提供更高的性能, 更能降低接入新协议的开发成本。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-x-protocol/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"220f4a76b277463bb1f7201519950450","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","summary":"X-Protocol 协议是 SOFAMesh 支持的特殊通用协议，能够以统一的方式接入不同的 RPC 协议，因为无需进行协议解析，不仅能够提供更高的性能, 更能降低接入新协议的开发成本。","tags":null,"title":"X-Protocol","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","wordcount":70},{"author":null,"categories":null,"content":" ZooKeeper Adapter ZooKeeper Adapter is an Adapter plug-in developed in accordance with the Istio registry center extension mechanism. It is used for docking all microservices frameworks that use ZooKeeper as a registry center. Currently, ZooKeeper Adapter supports SOFARPC and will be available for Dubbo soon.\nZooKeeper Adapter uses ZooKeeper\u0026amp;rsquo;s watch mechanism to listen to the change events of service registration information, providing better real-time performance than polling.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-zookeeper-adapter/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a174a0de8dd47df7c3043f6d49fa1b07","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","summary":"ZooKeeper Adapter ZooKeeper Adapter is an Adapter plug-in developed in accordance with the Istio registry center extension mechanism. It is used for docking all microservices frameworks that use ZooKeeper as a registry center. Currently, ZooKeeper Adapter supports SOFARPC and will be available for Dubbo soon.\nZooKeeper Adapter uses ZooKeeper\u0026rsquo;s watch mechanism to listen to the change events of service registration information, providing better real-time performance than polling.","tags":null,"title":"ZooKeeper Adapter","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","wordcount":67},{"author":null,"categories":null,"content":" To use Zookeeper as service registry center, you only need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 Note: Considering the real-time nature of the service, the following features are not supported currently.\nSOFABoot RPC also provides a cache file (not supported currently), which is used for service discovery when ZooKeeper is not available. The way to configure this cache file is as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth When users need to auth the providers and consumers, they can use a auth key to write or read the dictionary normally, only when they use the same key, zookeeper server will process these requests.\nSOFARPC API Usage If you use SOFARPC API directly, you can add two parameters to registry config.\nparameters.put(\u0026amp;quot;scheme\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;); //if there was multi auth infos, you need to set the value as user1:passwd1,user2:passwd2 parameters.put(\u0026amp;quot;addAuth\u0026amp;quot;, \u0026amp;quot;sofazk:rpc1\u0026amp;quot;); registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181/authtest\u0026amp;quot;) .setParameters(parameters); then if another provider or consumer use a different auth info, they will not access these providers or consumers.\nXML Usage You only need to set it in application.properties\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry\u0026amp;amp;scheme=digest\u0026amp;amp;addAuth=sofazk:rpc1 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-zookeeper/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"71d6486c5577cc85d84c56688cdf2af1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","summary":"To use Zookeeper as service registry center, you only need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 Note: Considering the real-time nature of the service, the following features are not supported currently.\nSOFABoot RPC also provides a cache file (not supported currently), which is used for service discovery when ZooKeeper is not available. The way to configure this cache file is as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth When users need to auth the providers and consumers, they can use a auth key to write or read the dictionary normally, only when they use the same key, zookeeper server will process these requests.","tags":null,"title":"Zookeeper","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","wordcount":174},{"author":null,"categories":null,"content":"Zookeeper Adapter 是按照 Istio 注册中心扩展机制开发的一个 Adapter 插件，用于对接所有使用 Zookeeper 作为注册中心的微服务框架。目前已经支持了 SOFARPC，很快将提供对于 Dubbo 的支持。\nZookeeper Adapter 使用 zk 的 watch 机制监听服务注册信息的变化事件，提供了比轮询机制更好的实时性。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-zookeeper-adapter/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a174a0de8dd47df7c3043f6d49fa1b07","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","summary":"Zookeeper Adapter 是按照 Istio 注册中心扩展机制开发的一个 Adapter 插件，用于对接所有使用 Zookeeper 作为注册中心的微服务框架。目前已经支持了 SOFARPC，很快将提供对于 Dubbo 的支","tags":null,"title":"Zookeeper Adpater","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","wordcount":110},{"author":null,"categories":null,"content":" 在介绍 Biz 生命周期 时，我们提到了有三种方式控制 Biz 的生命周期，并且介绍了使用客户端 API 实现 Biz 的安装、卸载、激活。在这一章节我们介绍如何使用 SOFAArk 提供的动态配置插件，通过 Zookeeper 下发指令，控制 Biz 的生命周期。\n引入依赖 SOFAArk 提供了 config-ark-plugin 对接 Zookeeper 配置中心，用于运行时接受配置，达到控制 Biz 生命周期，引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;config-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置 ZK 地址 参考 SOFAArk 配置，在 SOFAArk 配置文件 conf/ark/bootstrap.properties 增加如下配置：\ncom.alipay.sofa.ark.config.address=zookeeper://ip:port 配置维度 SOFAArk 启动后，会在 ZK 注册两个节点配置，分别是宿主应用维度和 IP 维度：\n sofa-ark/${com.alipay.sofa.ark.master.biz}/ \u0026amp;gt; 宿主应用维度配置，应用启动时，会拉取该维度配置，控制相关 Biz 的部署；应用重启后，配置不会丢失\n sofa-ark/${com.alipay.sofa.ark.master.biz}/ip/ \u0026amp;gt; IP 维度配置，应用重启后丢失，通常用于运行时控制单台机器的 Biz 行为\n 通过写这两个节点的配置，可以控制相关机器和应用的 Biz 运行时状态。\n配置形式 下面介绍配置的形式，动态配置采用状态声明指令，SOFAArk 收到配置后，会根据状态描述解析出具体的指令（包括 install，uninstall, switch），指令格式如下：\nbizName:bizVersion:bizState?k1=v1\u0026amp;amp;k2=v2\n多条指令使用 ; 隔开，单条指令主要由 biz 名称，biz 版本，biz 预期状态及参数组成。简单记住一点，状态配置是描述指令推送之后，所有非宿主 Biz 的状态；\n例如当前 SOFAArk 容器部署了两个应用 A，B，版本均为 1.0，其中 A 应用为宿主应用，因为宿主应用不可卸载，因此不需要考虑宿主应用，可以简单认为当前容器的 Biz 状态声明为：\n B:1.0:Activated\n 如果此时你希望安装 C 应用，版本为 1.0，文件流地址为 urlC，那么推送指令应为：\n B:1.0:Activated;C:1.0:Activated?bizUrl=urlC\n 操作继续，如果你又希望安装安装 B 应用，版本为 2.0，文件流地址为 urlB，且希望 2.0 版本处于激活状态，那么你推送的指令应为：\n B:1.0:Deactivated;B:2.0:Actaivated?bizUrl=urlB;C:1.0:Activated\n解释下为什么是这样配置指令，因为 SOFAArk 只允许应用一个版本处于激活状态，如果存在其他版本，则应处于非激活状态；所以当希望激活 B 应用 2.0 版本时，B 应用 1.0 版本应该声明为非激活状态。另外你可能注意到了 C 应用参数 urlC 不用声明了，原因是目前只有当安装新 Biz 时，才有可能需要配置参数 bizUrl，用于指定 biz 文件流地址，其他场景下，参数的解析没有意义。\n 操作继续，如果你希望卸载 B 应用 2.0 版本，激活 B 应用 1.0 版本，卸载 C 应用，那么推送的指令声明为：\n B:1.0:Activated\n 从上面的操作描述看，在推送动态配置时，只需要声明期望的 Biz 状态即可，SOFAArk 会根据状态声明推断具体的执行指令，并尽可能保持服务的连续性，以上面最后一步操作为例，SOFAArk 推断的执行指令顺序如下： + 执行 switch 指令，激活 B 应用 1.0 版本，钝化 B 应用 2.0 版本，保证服务连续性 + 执行 uninstall 指令，卸载 B 应用 2.0 版本 + 执行 uninstall 指令，卸载 C 应用 1.0 版本\n注意事项 目前只有在安装新 Biz 时才可能使用指令参数 bizUrl，用于指定 Biz 文件流地址。文件流地址字符串是能够直接构建 URL 对象，例如 file://xxx 或者 http://xxx. 安装新 Biz 时，参数 bizUrl 不是必须的，SOFAArk 提供了扩展点：\n@Extensible public interface BizFileGenerator { File createBizFile(String bizName, String bizVersion); } 用于扩展实现，根据 biz 名称和 biz 版本返回 biz 文件。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-zk-config/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c675734b1cb5fa546f96a31d8b9e3533","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","summary":"在介绍 Biz 生命周期 时，我们提到了有三种方式控制 Biz 的生命周期，并且介绍了使用客户端 API 实现 Biz 的安装、卸载、激活。在这一章节我们介绍如何使用 SOFAArk 提供的","tags":null,"title":"Zookeeper 配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","wordcount":1160},{"author":null,"categories":null,"content":" connection_manager 用于描述 MOSN 的路由配置，通常与 proxy 配合使用。\n{ \u0026amp;quot;router_config_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;virtual_hosts\u0026amp;quot;: [ ] } router_config_name，唯一的路由配置标识，与 proxy 中配置的字段对应。 virtual_hosts，描述具体的路由规则细节。 VirtualHost { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;domains\u0026amp;quot;:[], \u0026amp;quot;routers\u0026amp;quot;:[] } name，字符串。用作 virtual host 的唯一标识。 domains，字符串数组。表示一组可以匹配到该 virtual host 的 domain，支持配置通配符。domain 的匹配优先级如下： 首先匹配精确的，如 www.foo.com。 其次匹配最长后缀的通配符，如 *.foo.com、*-bar.foo.com，其中如果一个 domain 是 foo-bar.foo.com，那么会优先匹配 *-bar.foo.com。 最后匹配任意domain的通配符 * 。 routers，一组具体的路由匹配规则。 Router { \u0026amp;quot;match\u0026amp;quot;:{}, \u0026amp;quot;route\u0026amp;quot;:{}, \u0026amp;quot;per_filter_config\u0026amp;quot;:{} } match，路由的匹配参数。 route，路由行为，描述请求将被路由的 upstream 信息。 per_filter_config，是一个 key: json 格式的 json。 其中 key 需要匹配一个 stream filter 的 type，key 对应的 json 是该 stream filter 的 config。 当配置了该字段时，对于某些 stream filter（依赖具体 filter 的实现），可以使用该字段表示的配置覆盖原有 stream filter 的配置，以此做到路由匹配级别的 stream filter 配置。 match { \u0026amp;quot;prefix\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;path\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;regex\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;headers\u0026amp;quot;: [] } 路径（path）匹配 prefix，表示路由会匹配 path 的前缀，该配置的优先级高于 path 和 regex。 如果 prefix 被配置，那么请求首先要满足 path 的前缀与 prefix 配置相符合。 path，表示路由会匹配精确的 path，该配置的优先级高于 regex。如果 path被配置，那么请求首先要满足 path 与 path 配置相符合。 regex，表示路由会按照正则匹配的方式匹配 path。如果 regex 被配置，那么请求首先要满足 path 与 regex 配置相符合。 路径匹配配置同时存在时，只有高优先级的配置会生效。 Heaer 匹配 headers，表示一组请求需要匹配的 header。请求需要满足配置中所有的 Header 配置条件才算匹配成功。 header { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;value\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;regex\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } name，表示 header 的 key。 value，表示 header 对应 key 的 value。 regex，bool 类型，如果为 true，表示 value 支持按照正则表达式的方式进行匹配。 route { \u0026amp;quot;cluster_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;metadata_match\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;retry_policy\u0026amp;quot;:{} } cluster_name，表示请求将路由到的 upstream cluster。 metadata_match，metadata，如果配置了该字段，表示该路由会基于该 metadata 去匹配 upstream cluster 的 subset 。 timeout，Duration String，表示默认情况下请求转发的超时时间。如果请求中明确指定了超时时间，那么这个配置会被忽略。 retry_policy，重试配置，表示如果请求在遇到了特定的错误时采取的重试策略，默认没有配置的情况下，表示没有重试。 retry_policy { \u0026amp;quot;retry_on\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;retry_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;num_retries\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } retry_on，bool 类型，表示是否开启重试。 retry_timeout，Duration String，表示每次重试的超时时间。当 retry_timeout 大于 route 配置的 timeout 或者请求明确指定的 timeout 时，属于无效配置。 num_retries，表示最大的重试次数。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/network-filter/connection-manager/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"88e2d06bd6137225eeebf9015b2192a2","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","summary":"connection_manager 用于描述 MOSN 的路由配置，通常与 proxy 配合使用。 { \u0026quot;router_config_name\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;virtual_hosts\u0026quot;: [ ] } router_config_name，唯一的路由配置标识，与 proxy 中配置的字段对应。 vir","tags":null,"title":"connection_manager","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","wordcount":1188},{"author":null,"categories":null,"content":"proxy 是 MOSN 最常用的 network filter，其配置格式如下。\n{ \u0026amp;quot;downstream_protocol\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;upstream_protocol\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;router_config_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;extend_config\u0026amp;quot;:{} } downstream_protocol 描述 proxy 期望收到的请求协议，在连接收到数据时，会使用此协议去解析数据包并完成转发，如果收到的数据包协议和配置不符，MOSN 会将连接断开。 upstream_protocol 描述 proxy 将以何种协议转发数据，通常情况下应该和downstream_protocol 保持一致，只有特殊的场景会进行对应协议的转换。 router_config_name 描述 proxy 的路由配置的索引，通常情况下，这个配置会和同 listener 下的 connection_manager 中配置的 router_config_name 保持一致。 extend_config 扩展配置，目前仅在 MOSN 的 XProtocol 协议中使用。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/network-filter/proxy/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b04f78179a47a64d7e209b6660bfa80f","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","summary":"proxy 是 MOSN 最常用的 network filter，其配置格式如下。 { \u0026quot;downstream_protocol\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;upstream_protocol\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;router_config_name\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;extend_config\u0026quot;:{} } downstream_protocol 描述 proxy 期望收到的请求协议，在连接收到数据时，会使用此协议去解析数据包并完成转发，","tags":null,"title":"proxy","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","wordcount":221},{"author":null,"categories":null,"content":" 打开 ACTS IDE 在 Package 视图下，右键含 @Test 注解的函数名，ACTS 功能 -\u0026amp;gt; 修改测试用例，如下图：\n编写测试数据 准备入参 根据被测的接口方法的入参（类型、顺序、数量）正确准备入参数据，简单类型包括 String、Date、Integer、Float、Double、Long、Short、Byte（包含其对应的基本类型，即 int、float 等）；复杂类型为 List、Map、Set、自定义类、Java 定义的类以及前面五者的嵌套等。\n简单入参 入参设置上右键 -\u0026amp;gt; 模版选择 -\u0026amp;gt; 简单入参选择：\n导入简单入参后，值直接在这里填写； 自上而下表示被测接口方法的第1个、第2个和第3个参数，右键可以调节顺序。\n复杂入参 如图27所示，AccountTransRequest 和 BusinessActionContext 类需要生成入参模板，一般情况下，在一键生成测试脚本时会自动生成方法的入参和返回结果的类模板，打开 ACTS IDE 可对其进行编辑，如图28。\n图28\n如果生成测试脚本时没有识别出方法的入参和返回结果模版，可先生成复杂入参和结果模版（具体操作参考 对象模型生成），然后打开 ACTS IDE 编辑器，在入参设置上右键 -\u0026amp;gt; 模版选择 -\u0026amp;gt; 复杂类型，添加后可以看到复杂对象，直接进行编辑。\nlist map 以示例2为例（Set 与此类似） 图32中，演示示例2的方法入参为 Map\u0026amp;lt;String,Object\u0026amp;gt; 类型。由于 Object 不是具体类型，如果要设置 Object 为复杂对象，则需要去编辑 YAML。例如设置 Object 为 AccountTransResult 类型，则按照如下编辑：\n图32\nenum 代码样例：\n 在 ACTS IDE 中编辑如下： 如果枚举嵌套在其他类中，则在该类的 CSV 模版中设置枚举的值为 DEBIT；\n 用例数据 YAML 中，如图37：\n interestRecoverTypeEnum: !!com.alipay.fc.loancore.common.util.enums.InterestRecoverTypeEnum \u0026#39;ALL\u0026#39; 图37\n编码方式准备入参 覆盖 prepare 方法，通过 ActsRuntimeContext 的方法，快速获取和设置用例入参，如图38所示：\n 获取所有入参：List getInputParams() 按位置获取：Object getInputParamByPos(int i) 新增用例参数：void addInputParam(Object obj) 图 38\n准备 DB 数据 准备 DB 数据-单列场景 如图39，在数据库准备设置位置右键，选择好要插入的 DB 模板（请先确保该DB模板已经生成），图中1、2、3步骤之后点击 OK 即插入 DB 准备模板，如图41，可对要插入 DB 的数据进行编辑：\n图39\n图40\n图41\n准备 DB 数据-多列场景 选中一列数据，点击复制，按此方法可复制多列数据，然后进行编辑即可：\n图42\n准备 DB 数据-flag说明 数据依赖标记：\nY: 插入 N：不插入 C：以此为where条件对插入后的数据进行清理 F：数据库函数 L: 大字段换行准备，准备方式为A=B;C=D 图43\n准备期望结果数据 生成期望结果的对象模型后，在 ACTS IDE 界面中，期望结果设置右键 -\u0026amp;gt; 模版选择，见下图。\n图44\n期望结果的 flag 说明 Y: 校验 N：不校验 D：时间偏移值比较，如 D200 ME：map 默认全 key 校验，ME则以期望 key 为准，实际值多余期望值的 key 不予校验 对于返回结果的时间 Date 类型字段校验说明： 1. Y | null -\u0026amp;gt; 代表期望为 null 2. Y | 2015-01-01 00:00:00 -\u0026amp;gt; 代表期望为 2015-01-01 00:00:00 3. N | null -\u0026amp;gt; 代表不校验 4. D200 | 2015-01-01 00:00:00/null -\u0026amp;gt; 代表与 2015-01-01 00:00:00/new Date() 相差 200 秒\n编码方式准备期望结果 覆盖 prepare 方法，通过 ActsRuntimeContext 的如下方法，快速获取和设置期望结果。 1. 获取期望结果：Object getExpectResult() 2. 设置期望结果：Boolean setExpectResult(Object objToSet)\n准备期望 DB 数据 准备期望 DB 数据-单列场景 在数据库期望设置里配置，操作参考准备 DB 数据-单列场景\n准备期望 DB 数据-多列场景 在数据库期望设置里配置，操作参考准备 DB 数据-多列场景\n期望 DB 数据的 flag 说明 数据校验标记：\nY: 校验 N：不校验 C：以此为条件 select 然后比较，如果结果有多个，则返回的结果所有记录都要和当前需要校验的数据进行校验 CN： 这个 flag 表示当前这张表中以 C 和 CN 为条件查询出的结果为空 D200：表示对比时间的时候误差 200s 之内都算通过，日期类型的格式为：today L： 数据库大字段换行数据校验，准备方式为 A=B;C=D P：DB 大字段校验，以期望结果的 kv 为基准，对 DB 大字段里的 kv 进行校验，要求 DB 里的 kv 之间是换行分隔 R：正则匹配校验 准备期望异常数据 编码方式准备期望异常数据 部分系统封装的异常类没有默认构造函数，这样通过模版添加的异常结果在加载 YAML 时会有问题（无默认构造函数无法构造当前类），需要通过代码方式，结合自定义参数编写异常脚本，如下图：\n图45\n准备自定义数据 自定义数据-用途 用户自定义的各类型数据，用于测试过程中自由使用。\n自定义数据-数据类型 数据类型可参考 入参 部分\n编码方式准备自定义数据 快速获取和设置自定义参数：\n 获取全部自定义参数：getParamMap getParamMap() 按 key 获取：Object getParamByName(String paraName) 新增自定义参数：void addOneParam(String paraName, Object paraObj) 替换自定义参数：void setParamMap(Map\u0026amp;lt;String,Object\u0026amp;gt; paramMap) 以范型方式获取自定义参数：T getParamByNameWithGeneric(String paraName) 不同数据类型编辑方式 简单类型编辑 以自定义参数设置添加简单类型数据为例。如图46，自定义参数设置右键 -\u0026amp;gt; 模板选择，弹框填写入参名字：\n图46\n图47\n选择 String 类型，在下方编辑框填写值即可，生成后也可自行编辑： ![填写值](enter-value.png) 图48\n图49\n复杂对象编辑 以自定义参数设置添加复杂对象数据为例\n参照 简单类型编辑，在弹框填 …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ide/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"697e7e6d35a2e058f3ca8b0a72032690","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-ide/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-ide/","summary":"打开 ACTS IDE 在 Package 视图下，右键含 @Test 注解的函数名，ACTS 功能 -\u0026gt; 修改测试用例，如下图： 编写测试数据 准备入参 根据被测的接口方法的入参（类型、顺序、数量","tags":null,"title":"一站式编辑","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-ide/","wordcount":2588},{"author":null,"categories":null,"content":" 快速理解 ACTS 的模型 在写测试用例的过程中，需要预先准备一些 DB 表、方法入参的数据，或者需要校验一些 DB 表、返回结果的数据，这些数据可以以模版的形式保存下来，在编辑用例时，可以方便的导入这些数据到准备数据或者校验数据，实现数据复用。目前 ACTS 模型可以分为 DB 模型和类模型。\n常规的测试用例编写，DB 、方法入参、返回结果等领域模型的数据准备是通过测试代码组织的，随着业务复杂度，领域模型复杂度也在不断增加，尤其在金融级业务用，往往一个类或者数据表有数十个属性或者字段，类与类的嵌套也是随处可见，代码构造复杂对象变得十分困难且容易疏漏，问题频现： * 表太多容易遗漏，排查时间太长； * 表的字段名记不住，时不时写错； * 接口入参数量多类型复杂，看见就头疼； * 类的属性太多，容易遗漏重要属性； * 嵌套构造对象，不断的 new 和 set 赋值； * 继承和实现关系复杂，遗漏重要属性；\nACTS 的模版有可以有效应对上述问题，通过将类和表固化为 CSV，类的结构一目了然，通过类、数据表的模版可以快速的模版化地创建对象，并序列化到 YAML 文件中，使用 ACTS IDE 可以方便的管理用例数据。\n模型存储位置 在 test 模块的 resource/model 目录可以查看已经存在的模型。\n图4\n数据表模型生成 数据表模型样例 图5\n1. 校验 flag 说明\n```plain Y: 插入 N：不插入 C：以此为 where 条件对插入后的数据进行清理 F：数据库函数 L: 大字段换行准备，准备方式为 A=B;C=D ``` 2. 用例编辑使用模型快速导入数据\n使用 ACTS IDE 编辑 DB 表数据（包括准备表数据、期望表数据）时，可右键新增指定表的模型，用于直接从表模型的 CSV 中导入表的全部字段和值，以便快速编辑。 DB 模版的使用可参考准备 DB 数据。\n生成表模型 图6\n图7\n图8\n点击 OK 后生成模板，如图9：\n图9\n同时支持不配置直连获取表结构的方式生成表模型，即在 DO 类上右键根据类生成表模型： DO 类上右击 -\u0026amp;gt; ACTS 功能 -\u0026amp;gt; 生成 DO 模型：\n图10\n![生产的模型](generated-do-model.png) 图11\n对象模型生成 对象模型样例 图12\n图13\n一个复杂对象是一个闭包，不但包含其自身模型还包含其嵌套对象的模型。\nACTS 使用模型快速导入数据、编辑复杂对象（包括入参、返回结果和异常等），在 ACTS IDE 中可右键选择类模型，用于构建该类的对象并赋值以便快速编辑。\n生成方法 有两种方式： 1.待构建模型的类定义的任意方法上点击； 1.接口定义的方法上点击，详细操作看下图示例。\n使用 IDEA 的同学请注意：请先确保代码已编译，IDEA 不会自动编译而需要手动 mvn clean install 或者打开自动编译 File -\u0026amp;gt; Settings -\u0026amp;gt; Build,Execution,Deployment -\u0026amp;gt; Compiler -\u0026amp;gt; Make project automatically。\nACTS IDE 生成对象模型 （1）待构建模型的类定义的任意方法上点击，生成当前类的模型\n图14\n（2）接口定义任意方法上点击，生成当前接口中，所有方法的复杂入参、复杂返回结果的模型\n图15\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-model/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"65aaf62462b3b0ea142ca75a5b61eb0d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-model/","summary":"快速理解 ACTS 的模型 在写测试用例的过程中，需要预先准备一些 DB 表、方法入参的数据，或者需要校验一些 DB 表、返回结果的数据，这些数据可以以模版的形式保","tags":null,"title":"一键模型化","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-model/","wordcount":1096},{"author":null,"categories":null,"content":" 快速理解 ACTS 中的脚本 如果你是一个经常编写测试用例的同学，是不是经常苦于这样的问题： * 不断的 assertEquals 写得快吐了，重复性编码毫无创意； * 少一个 assert 容易假绿，错一个败坏心情； * 场景一旦复杂，测试代码比业务代码还要长，写起来痛不欲生； * 每换一个应用，之前写的工具类就要搬一次；\n左图为 TestNG 用例，右图为 ACTS 用例，重复性代码一去不回，代码体积明显缩小。区别于普通测试脚本，ACTS 脚本继承自 ActsTestBase 类，封装了数据加载、驱动、执行引擎和校验规则，无需用户来组织清理数据、准备数据、执行用例和校验结果，对于简单业务可以做到零编码，极大释放代码编写和后期维护成本。\n测试脚本生成 前提条件：务必 mvn 编译工程和生成对象模型，否则会造成 ACTS IDE 不可预料的错误，如无法编辑、数据不正确等。\n接口定义的方法上点击，选择 ACTS 功能 -\u0026amp;gt; 生成测试用例。\n测试脚本运行 方法：右键 ACTS 脚本中的被测方法，选择 TestNG 来执行测试脚本，如下图：\n指定测试脚本运行 在 src/test/resource/config/acts-config.properties 中配置 test_only＝^T，表示只跑用例名称以 T 开头的用例，^T 也可以换成其他正则表达式；\n 修改要测试的用例名称，在用例名前面加 T，ACTS 运行时时仅执行用例名称以 T 开头的用例。\n 脚本用例拆分功能 默认每个测试脚本的所有用例数据保存在同一个 YAML 中，ACTS 支持用例数据根据开关 spilt_yaml_by_case 来决定同一测试脚本的所有用例数据存储在一个 YAML 中还是每个用例存储为一个 YAML。 开关默认为关闭，即同一测试脚本的所有测试数据存储在一个 YAML 文件中。\n在 acts-config.properities 中设置 spilt_yaml_by_case=true 即可打开开关，之后新生成测试脚本时每个用例对应一个单独的以 caseId 命名的 YAML文件，拆分的方式可以降低多人研发同一接口带来的文件冲突问题。\n此外，为了支持将老的 YAML 文件按用例拆分，ACTS 提供了工具类，如下，支持将指定脚本下，指定路径的 YAML 文件按用例拆分。\n BaseDataUtil.saveYamlDataToCaseByCase\n 注意：拆分后，建议先给原有 YAML 重命名做备份，然后打开用例编辑器检查拆分后的文件内容是否正确，确认无误后可删除原有 YAML 文件，两者不能并存。 编码方式准备数据 ACTS 提供了数据自定义 API 接口，封装于 ActsRuntimeContext 类中，如下： + 快速获取和设置自定义参数\n获取全部自定义参数：`getParamMap getParamMap()` 按 key 获取：`Object getParamByName(String paraName)` 新增自定义参数：`void addOneParam(String paraName, Object paraObj)` 替换自定义参数：`void setParamMap(Map\u0026amp;lt;String, Object\u0026amp;gt; paramMap)` 泛型方式获取自定义参数：`T getParamByNameWithGeneric(String paraName)` 快速获取和设置用例入参\n获取所有入参：List getInputParams() 按位置获取：Object getInputParamByPos(int i) 新增用例参数：void addInputParam(Object obj)\n 快速获取和设置期望结果\n获取期望结果：Object getExpectResult() 设置期望结果：Boolean setExpectResult(Object objToSet)\n Mock 功能使用 Mock 功能目前是采用 Mockito 的方案，具体资料见 Mockito 英文文档和 Mockito 中文文档\n增加依赖 在 test 模块增加如下依赖（如果已经引入 SOFABoot 的测试 starter 则无需重复引入）\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 默认 spring test 依赖的 mockito 版本是 1.x，想要升级的可以排除后再引入相应的版本\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.mockito\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mockito-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.18.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Mockito 用于测试时进行打桩处理，通过它可以指定某个类的某个方法在什么情况下返回什么样的值。Mockito 库能够 Mock 对象、验证结果以及打桩，示例如下：\n@SpringBootTest(classes = SOFABootApplication.class) @TestExecutionListeners(listeners = MockitoTestExecutionListener.class) public class RegisterUserActsTest extends ActsTestBase { @TestBean @Autowired // 这是测试类 public UserService userService; @MockBean // 这是要mock的bean public AccountManageFacadeClient accountManageFacadeClient; @Test(dataProvider = \u0026amp;quot;ActsDataProvider\u0026amp;quot;) public void registerUser (String caseId, String desc, PrepareData prepareData) { runTest(caseId, prepareData); } @Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { super.beforeActsTest(actsRuntimeContext); AccountManageResult accountManageResult = new AccountManageResult(); …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-script/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0d20739dedad1f11277bd02ed65329c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-script/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-script/","summary":"快速理解 ACTS 中的脚本 如果你是一个经常编写测试用例的同学，是不是经常苦于这样的问题： * 不断的 assertEquals 写得快吐了，重复性编码毫无创意； * 少一个 assert 容易假绿","tags":null,"title":"一键脚本化","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-script/","wordcount":1276},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 集成 Zipkin 进行数据上报展示。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n 下面的示例中将分别演示在 SOFABoot/SpringBoot 工程中 以及 非 SOFABoot/SpringBoot 工程中如何使用。\n 依赖引入 添加 SOFATracer 依赖 工程中添加 SOFATracer 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置 Zipkin 依赖 考虑到 Zipkin 的数据上报能力不是 SOFATracer 默认开启的能力，所以期望使用 SOFATracer 做数据上报时，需要添加如下的 Zipkin 数据汇报的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.zipkin2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.11.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.reporter2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin-reporter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.7.13\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置文件 在工程的 application.properties 文件下添加一个 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFATracerReportZipkin # logging path logging.path=./logs com.alipay.sofa.tracer.zipkin.enabled=true com.alipay.sofa.tracer.zipkin.baseUrl=http://localhost:9411 启动 Zipkin 服务端 启动 Zipkin 服务端用于接收 SOFATracer 汇报的链路数据，并做展示。Zipkin Server 的搭建可以参考此文档进行配置和服务端的搭建。\n运行 可以将工程导入到 IDE 中运行生成的工程里面中的 main 方法启动应用，也可以直接在该工程的根目录下运行 mvn spring-boot:run，将会在控制台中看到启动日志：\n2018-05-12 13:12:05.868 INFO 76572 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcSofaTracerFilter\u0026#39; to urls: [/*] 2018-05-12 13:12:06.543 INFO 76572 --- [ main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped \u0026amp;quot;{[/helloZipkin]}\u0026amp;quot; onto public java.util.Map\u0026amp;lt;java.lang.String, java.lang.Object\u0026amp;gt; com.alipay.sofa.tracer.examples.zipkin.controller.SampleRestController.helloZipkin(java.lang.String) 2018-05-12 13:12:07.164 INFO 76572 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 可以通过在浏览器中输入 http://localhost:8080/helloZipkin 来访问 REST 服务，结果类似如下：\n{ content: \u0026amp;quot;Hello, SOFATracer Zipkin Remote Report!\u0026amp;quot;, id: 1, success: true } 查看 Zipkin 服务端展示 打开 Zipkin 服务端界面，假设我们部署的 Zipkin 服务端的地址是 http://localhost:9411，打开 URL 并搜索 helloZipkin(由于我们本地访问的地址是 localhost:8080/helloZipkin)，可以看到展示的链路图。\nSpring 工程运行 对于一般的 Spring 工程，我们通常使用 tomcat/jetty 作为 servlet 容器来启动应用。具体工程参考 在 Spring 工程中使用 SOFATracer\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/report-to-zipkin/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d28d192386829452262116de9c32b570","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","summary":"在本文档将演示如何使用 SOFATracer 集成 Zipkin 进行数据上报展示。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 下面的示例中将分别演","tags":null,"title":"上报数据至 Zipkin","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","wordcount":661},{"author":null,"categories":null,"content":" 优雅关闭，包括两部分，一个是 RPC 框架作为客户端，一个是 RPC 框架作为服务端。\n作为服务端 作为服务端的时候，RPC 框架在关闭时，不应该直接暴力关闭。在 RPC 框架中\ncom.alipay.sofa.rpc.context.RpcRuntimeContext 在静态初始化块中，添加了一个 ShutdownHook\n// 增加jvm关闭事件 if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } 这个 ShutdownHook 的作用是当发布平台/用户执行 kill pid 的时候，会先执行 ShutdownHook 中的逻辑。在销毁操作中，RPC 框架会先执行向注册中心取消服务注册、关闭服务端口等动作。\nprivate static void destroy(boolean active) { RpcRunningState.setShuttingDown(true); for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.preDestroy(); } List\u0026amp;lt;ProviderConfig\u0026amp;gt; providerConfigs = new ArrayList\u0026amp;lt;ProviderConfig\u0026amp;gt;(); for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { providerConfigs.add(bootstrap.getProviderConfig()); } // 先反注册服务端 List\u0026amp;lt;Registry\u0026amp;gt; registries = RegistryFactory.getRegistries(); if (CommonUtils.isNotEmpty(registries) \u0026amp;amp;\u0026amp;amp; CommonUtils.isNotEmpty(providerConfigs)) { for (Registry registry : registries) { registry.batchUnRegister(providerConfigs); } } // 关闭启动的端口 ServerFactory.destroyAll(); // 关闭发布的服务 for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { bootstrap.unExport(); } // 关闭调用的服务 for (ConsumerBootstrap bootstrap : REFERRED_CONSUMER_CONFIGS) { ConsumerConfig config = bootstrap.getConsumerConfig(); if (!CommonUtils.isFalse(config.getParameter(RpcConstants.HIDDEN_KEY_DESTROY))) { // 除非不让主动unrefer bootstrap.unRefer(); } } // 关闭注册中心 RegistryFactory.destroyAll(); // 关闭客户端的一些公共资源 ClientTransportFactory.closeAll(); // 卸载模块 if (!RpcRunningState.isUnitTestMode()) { ModuleFactory.uninstallModules(); } // 卸载钩子 for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.postDestroy(); } // 清理缓存 RpcCacheManager.clearAll(); RpcRunningState.setShuttingDown(false); if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework has been release all resources {}...\u0026amp;quot;, active ? \u0026amp;quot;actively \u0026amp;quot; : \u0026amp;quot;\u0026amp;quot;); } } 其中以 bolt 为例，关闭端口并不是一个立刻执行的动作\n@Override public void destroy() { if (!started) { return; } int stopTimeout = serverConfig.getStopTimeout(); if (stopTimeout \u0026amp;gt; 0) { // 需要等待结束时间 AtomicInteger count = boltServerProcessor.processingCount; // 有正在执行的请求 或者 队列里有请求 if (count.get() \u0026amp;gt; 0 || bizThreadPool.getQueue().size() \u0026amp;gt; 0) { long start = RpcRuntimeContext.now(); if (LOGGER.isInfoEnabled()) { LOGGER.info(\u0026amp;quot;There are {} call in processing and {} call in queue, wait {} ms to end\u0026amp;quot;, count, bizThreadPool.getQueue().size(), stopTimeout); } while ((count.get() \u0026amp;gt; 0 || bizThreadPool.getQueue().size() \u0026amp;gt; 0) \u0026amp;amp;\u0026amp;amp; RpcRuntimeContext.now() - start \u0026amp;lt; stopTimeout) { // 等待返回结果 try { Thread.sleep(10); } catch (InterruptedException ignore) { } } } // 关闭前检查已有请求？ } // 关闭线程池 bizThreadPool.shutdown(); stop(); } 而是 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/graceful-shutdown/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"53af179e23ba184b01eb8234c055b15d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","summary":"优雅关闭，包括两部分，一个是 RPC 框架作为客户端，一个是 RPC 框架作为服务端。 作为服务端 作为服务端的时候，RPC 框架在关闭时，不应该直接暴力关闭。在","tags":null,"title":"优雅关闭","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","wordcount":866},{"author":null,"categories":null,"content":" 使用 CloudMesh 轻松实践 Service Mesh Demo 内容介绍 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。\nDemo内容介绍 Service Mesh 将服务间通信能力下沉到基础设施，让应用解耦并轻量化。\n但 Service Mesh 本身的复杂度依然存在，CloudMesh 通过将 Service Mesh 托管在云上，使得您可以轻松的实践 Service Mesh 技术。\n通过我们的 workshop，您可以将以多种编程语言开发的应用，简单部署到 CloudMesh 上，即可获得服务网格提供的强大能力。包括对服务进行访问，通过监控查看流量，体验服务治理、Sidecar 管理和对服务的新版本进行灰度发布等实用功能。\n本次 demo 中，我们将重点体验 CloudMesh 强大的流量控制能力。在灰度发布过程中，可以对灰度流量占比进行精准控制，并通过实时流量监控了解服务网格中流量的实际走向：\n常规的灰度发布，在灰度过程中需要占用两倍容量：\nCloud Mesh 提供的灰度发布功能，可以实现在灰度发布过程中不必占有额外的容量，而且容许在发布期间多次暂停以便修改灰度占比：\nDemo 操作指南 为了方便参加本次 demo 的同学，我们准备了整个 demo 流程的详尽的操作指南。\n更多 请 点击此处访问 在线版本。 下载本地 Demo 幻灯片。 ","date":-62135596800,"description":"使用该指南您可以快速部署应用到 CloudMesh ，对服务进行访问，通过监控查看流量，体验服务治理、Sidecar管理和对服务的新版本进行灰度发布等实用功能。","dir":"guides/kc-cloud-mesh-demo/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e389a65e6736e909718275cd76505525","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-cloud-mesh-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/guides/kc-cloud-mesh-demo/","summary":"使用 CloudMesh 轻松实践 Service Mesh Demo 内容介绍 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。 Demo内容介绍 Service Mesh 将服务间通信能力下沉到基础","tags":null,"title":"使用 CloudMesh 轻松实践 Service Mesh","type":"guides","url":"/sofastack.tech/guides/kc-cloud-mesh-demo/","wordcount":453},{"author":null,"categories":null,"content":"使用 Consul 作为服务注册中心需要添加如下依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.ecwid.consul\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;consul-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 中如下配置：\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 其中后面的值为 consul 的连接地址，如果需要设置一些其他参数，也可以通过\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;amp;b=2 进行设置\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-consul/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e6b0aa843ea0ad401c3184f6ce87649b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-consul/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-consul/","summary":"使用 Consul 作为服务注册中心需要添加如下依赖 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.ecwid.consul\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;consul-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.4.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 然后在 application.properties 中如下配置： com.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 其中后面的值为 consul 的连接地址，如果需要设置一些其他参数，也可以通过 com.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;b=2 进行","tags":null,"title":"使用 Consul 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-consul/","wordcount":72},{"author":null,"categories":null,"content":" 本文将介绍如何使用 MOSN 在 SOFAMesh 框架下搭建 Service Mesh 的开发环境，并验证 MOSN 的一些基础路由能力、负载均衡能力等。本文介绍的内容将包括 :\n MOSN 与 SOFAMesh 的关系 准备工作 源码方式部署 SOFAMesh Bookinfo 实验 MOSN 与 SOFAMesh 的关系 我们曾在 MOSN 介绍中介绍过，MOSN 是一款采用 Go 语言开发的 Service Mesh 数据平面代理。而 SOFAMesh 则是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案，MOSN 作为 SOFAMesh 的关键组件用来完成数据面的转发。\n下图是 SOFAMesh 整体框架下，MOSN 的工作示意图。\n注意：当前 MOSN 不支持在原生的 Istio 中直接使用。\n 准备工作 本文以 macOS 为例 ，其他环境可以安装对应版本的软件。\n1. 安装 hyperkit 先安装 docker-for-mac，之后安装驱动\n1.1 安装 docker 下载软件包安装，或者使用如下的命令安装。\n$ brew cask install docker 1.2 安装驱动 $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. 安装 Minikube(也可以购买商业 k8s 集群) 推荐使用 Minikube v0.28 以上来体验，请参考 https://github.com/kubernetes/minikube\n$ brew cask install minikube 3. 启动 Minikube 注意，pilot 至少需要 2G 内存，所以在启动的时候，可以通过加参数的方法给 minikube 添加分配的资源，如果你机器的资源不够，推荐使用商业版本的 k8s 集群。\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit 创建istio 命名空间\n$ kubectl create namespace istio-system 4. 安装 kubectl 命令行工具 kubectl 是用于针对 k8s 集群运行命令的命令行接口，安装参考 https://kubernetes.io/docs/tasks/tools/install-kubectl。\n$ brew install kubernetes-cli 5. 安装 Helm Helm 是一个 k8s 的包管理工具，安装参考 https://docs.helm.sh/using_helm/#installing-helm\n$ brew install kubernetes-helm 源码方式部署 SOFAMesh 1. 下载 SOFAMesh 源码 $ git clone https://github.com/sofastack/sofa-mesh.git 2. 通过 Helm 安装 SOFAMesh 使用 helm template 安装\n首先需要切换到SOFAMesh源码所在目录，然后使用Helm安装istio CRD以及各个组件\n$ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - 3. 验证安装 istio-system 命名空间下的 pod 状态都是 Running 时，说明已经部署成功。 如果仅仅是为了运行bookinfo，只需要pilot,injector,citadel这三个pods运行成功就可以满足最低要求\n$ kubectl get pods -n istio-system NAME READY STATUS RESTARTS AGE istio-citadel-6579c78cd9-w57lr 1/1 Running 0 5m istio-egressgateway-7649f76df4-zs8kw 1/1 Running 0 5m istio-galley-c77876cb6-nhczq 1/1 Running 0 5m istio-ingressgateway-5c9c8565d9-d972t 1/1 Running 0 5m istio-pilot-7485f9fb4b-xsvtm 1/1 Running 0 5m istio-policy-5766bc84b9-p2wfj 1/1 Running 0 5m istio-sidecar-injector-7f5f586bc7-2sdx6 1/1 Running 0 5m istio-statsd-prom-bridge-7f44bb5ddb-stcf6 1/1 Running 0 5m istio-telemetry-55ff8c77f4-q8d8q 1/1 Running 0 5m prometheus-84bd4b9796-nq8lg 1/1 Running 0 5m 4. 卸载安装 卸载SOFAMesh\n$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - $ kubectl delete namespace istio-system BookInfo 实验 BookInfo 是一个类似豆瓣的图书应用，它包含四个基础服务：\n Product Page：主页，由 python 开发，展示所有图书信息，它会调用 Reviews 和 Details 服务 Reviews：评论，由 java 开发，展示图书评论，会调用 Ratings 服务 Ratings：评分服务，由 nodejs …","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-with-sofamesh/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9c6461e92180417d3a8ec4f3f2c723fe","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","summary":"本文将介绍如何使用 MOSN 在 SOFAMesh 框架下搭建 Service Mesh 的开发环境，并验证 MOSN 的一些基础路由能力、负载均衡能力等。本文介绍的内容将包括 : MOSN 与 SOFAMesh 的关系 准备工作 源码","tags":null,"title":"使用 MOSN 搭建 Service Mesh 平台","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","wordcount":1654},{"author":null,"categories":null,"content":"SOFARPC 已支持使用 Nacos 作为服务注册中心。假设你已经根据 Nacos 的快速开始在本地部署好 Nacos Server，服务发现的端口默认设置在 8848。\n在 SOFARPC 中使用 Nacos 作为服务注册中心只需要在 application.properties 中加入如下配置即可：\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 如果你直接使用了 SOFARPC，而不是 SOFABoot，需要手动添加 nacos 的依赖，其中 version 为用户想使用的 version。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba.nacos\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;nacos-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 当前支持 Nacos 的版本： - SOFARPC：5.5.0 支持 Nacos 服务端版本 0.6.0，SOFABoot: 2.5.3。 - SOFARPC：5.6.0 支持 Nacos 服务端版本 1.0.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-nacos/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cc161f22cd2145fe309e63087581adc1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-nacos/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-nacos/","summary":"SOFARPC 已支持使用 Nacos 作为服务注册中心。假设你已经根据 Nacos 的快速开始在本地部署好 Nacos Server，服务发现的端口默认设置在 8848。 在 SOFARPC 中使用 Nacos 作为服务","tags":null,"title":"使用 Nacos 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-nacos/","wordcount":232},{"author":null,"categories":null,"content":"SOFARPC 已支持使用 SOFARegistry 作为服务注册中心。假设你已经根据 SOFARegistry 的快速开始在本地部署好 SOFARegistry Server，服务发现的端口默认设置在 9603。\n在 SOFARPC 中使用 SOFARegistry 作为服务注册中心首先要添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.2.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 中加入如下配置即可：\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 当前支持 SOFARegistry 的版本：\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\n由于本次发布的时间问题，暂时需要用户指定SOFARPC Starter的版本\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFARPC 集成验证 SOFARegistry 服务端版本：5.2.0\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-sofa/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"65085018ce2b2b2ef452993bb79a69de","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-sofa/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-sofa/","summary":"SOFARPC 已支持使用 SOFARegistry 作为服务注册中心。假设你已经根据 SOFARegistry 的快速开始在本地部署好 SOFARegistry Server，服务发现的端口默认设置在 9603。 在 SOFARPC 中使用 SOFARegistry 作为服务","tags":null,"title":"使用 SOFARegistry 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-sofa/","wordcount":182},{"author":null,"categories":null,"content":" 使用 SOFAStack 快速构建微服务 前置条件 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n [必选]部署注册中心：https://www.sofastack.tech/projects/sofa-registry/server-quick-start/ [必须]部署数据库：本地自行搭建数据库，然后导入 DDL.sql [可选]部署 LookoutServer：https://www.sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/ [可选]部署 Zipkin：https://zipkin.io/pages/quickstart.html 实验内容 本实验基于 SOFAStack 快速构建一个微服务，主要包括以下几个部分：\n 使用 SOFABoot + SOFARPC 发布服务 使用 SOFABoot + SOFARPC 调用服务 通过 ZipKin 查看 SOFATracer 上报的 Tracer 信息 通过 SOFALookout 查看上报的 Metrics 信息 架构图 任务 1、任务准备 从 github 上将 demo 工程克隆到本地\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git 然后将工程导入到 IDEA 或者 eclipse。导入之后界面如下：\n balance-mng：余额管理系统，提供扣减余额服务 stock-mng：库存管理系统，提供扣减库存服务 2、引入依赖 将下面的依赖引入到 balance-mng 和 stock-mng 工程模块的 pom.xml 文件中。\n\u0026amp;lt;!--SOFARPC 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFATracer 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFARegistry 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--runtime 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFALookout 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; balance-mng 工程需要将依赖引入 balance-mng/balance-mng-impl/pom.xml 文件：\nstock-mng 工程直接将依赖引入 stock-mng/pom.xml 文件：\n3、添加配置 将如下配置复制到 balance-mng 和 stock-mng 工程模块的 application.properties 中。\n# 1、添加服务注册中心地址 com.alipay.sofa.rpc.registry.address=sofa://localhost:9603 # 2、添加 tracer 数据上报的服务端 zipkin 地址 # 如果上面前置条件未搭建 tracer，可以不配置 com.alipay.sofa.tracer.zipkin.base-url=http://localhost:9411 # 3、添加 metrics 数据上报的服务端地址 # 如果上面前置条件未搭建 lookout-server，可以不配置 com.alipay.sofa.lookout.agent-host-address=localhost balance-mng 工程需要将配置添加至 balance-mng/balance-mng-bootstrap/src/main/resources/application.properties 文件：\n另外数据库配置修改为自己的数据库信息：\n# database config spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://localhost:3306/stock_db spring.datasource.username=root spring.datasource.password=root stock-mng 工程需要将配置添加至 stock-mng/src/main/resources/application.properties 文件：\n另外数据库配置修改为自己的数据库信息：\n# database config spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://localhost:3306/stock_db spring.datasource.username=root spring.datasource.password=root 4、修改 unique id 由于所有人共用一套服务发现，为区分不同用户发布的服务，需要为服务增加 unique id。\nKubeCon workshop 会给每个用户准备一个 SOFAStack 账号，格式为 user0@sofastack.io 到 user99@sofastack.io，去掉 @sofastack.io 部分，账户前半部分的 user0 至 user99 即可作为 unique id。\n 注意：balance-mng 和 stock-mng 里的 unique id 需要一致。 …","date":-62135596800,"description":"本指南将基于 SOFAStack 快速构建一个微服务。","dir":"guides/sofastack-quick-start/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"78bfd4806a86dc15ac86eee16fb85c82","permalink":"https://sofastack.github.io/sofastack.tech/guides/sofastack-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/sofastack-quick-start/","summary":"使用 SOFAStack 快速构建微服务 前置条件 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 [必选]部署注册中心：https://ww","tags":null,"title":"使用 SOFAStack 快速构建微服务","type":"guides","url":"/sofastack.tech/guides/sofastack-quick-start/","wordcount":1486},{"author":null,"categories":null,"content":" 使用 Seata 保障支付一致性 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n在开始该 demo 之前先完成《使用 SOFAStack 快速构建微服务》，如果没有完成，可以基于仓库里的 kc-sofastack-demo 工程为基线完成下面的 demo，该 demo 是在它基础上加上 Seata 分布式事务。但该 demo 不是只能应用于 SOFA，可以适用于任何 java 技术栈应用。\nAT 模式 1、引入 maven 依赖 将下面的依赖引入到父工程的 pom 文件中（kc-sofastack-demo/pom.xml）:\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;seata.version\u0026amp;gt;0.6.1\u0026amp;lt;/seata.version\u0026amp;gt; \u0026amp;lt;netty4.version\u0026amp;gt;4.1.24.Final\u0026amp;lt;/netty4.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; \u0026amp;lt;dependencyManagement\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;javax.servlet\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;servlet-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${netty4.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; \u0026amp;lt;/dependencyManagement\u0026amp;gt; 将下面的依赖引入到 stock-mng 工程的 pom 文件中（kc-sofastack-demo/stock-mng/pom.xml）:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 将下面的依赖引入到 balance-mng-impl 工程的 pom 文件中（kc-sofastack-demo/balance-mng/balance-mng-impl/pom.xml）:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 2、使用 Seata 的 DataSourceProxy 代理实际的数据源，并配置 GlobalTransactionScanner 扫描@GlobalTransaction 注解 将下面的 java 代码段加到 BalanceMngApplication 和 StockMngApplication 类的 main 方法下面:\nimport io.seata.rm.datasource.DataSourceProxy; import io.seata.spring.annotation.GlobalTransactionScanner; public static void main(String[] args) { SpringApplication.run(BalanceMngApplication.class, args); } @Configuration public static class DataSourceConfig { @Bean @Primary @ConfigurationProperties(prefix = \u0026amp;quot;spring.datasource.hikari\u0026amp;quot;) public DataSource dataSource(DataSourceProperties properties) { HikariDataSource dataSource = createDataSource(properties, HikariDataSource.class); if (properties.getName()!=null \u0026amp;amp;\u0026amp;amp; properties.getName().length() \u0026amp;gt; 0) { dataSource.setPoolName(properties.getName()); } return new DataSourceProxy(dataSource); } @SuppressWarnings(\u0026amp;quot;unchecked\u0026amp;quot;) protected …","date":-62135596800,"description":"该指南将向您展示如何使用开源分布式事务框架 Seata 的 AT 模式、TCC 模式解决业务数据的最终一致性问题。 ","dir":"guides/kc-seata-demo/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"60071a0eb44bf0901fb187eefd63ccdb","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-seata-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/guides/kc-seata-demo/","summary":"使用 Seata 保障支付一致性 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 在开始该 demo 之前先完成《使用 SOFAStack 快速构建微服务》，如果","tags":null,"title":"使用 Seata 保障支付一致性","type":"guides","url":"/sofastack.tech/guides/kc-seata-demo/","wordcount":2320},{"author":null,"categories":null,"content":" 使用 Zookeeper 作为服务注册中心只需要在 application.properties 中如下配置即可：\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 注意：考虑掉服务的实时性，以下特性暂不支持\nSOFABoot RPC 也提供一个缓存文件(目前暂不支持)，当 Zookeeper 不可用时，使用该缓存文件进行服务发现。配置该缓存文件的方式如下：\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth 支持 当用户需要对发布和消费服务，进行权限认证的时候，可以通过在操作 zookeeper 时，指定对应的目录和账号密码来进行读写。这样只有使用了相同密码的 服务方或者消费方才能进行读写。\nSOFARPC API 支持 在构造注册中心的时候，将Auth添加上\nparameters.put(\u0026amp;quot;scheme\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;); //如果存在多个认证信息，则在参数形式为为user1:passwd1,user2:passwd2 parameters.put(\u0026amp;quot;addAuth\u0026amp;quot;, \u0026amp;quot;sofazk:rpc1\u0026amp;quot;); registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181/authtest\u0026amp;quot;) .setParameters(parameters); 之后其他没有使用正确auth的，将无法访问authtest目录\nXML 方式支持 如下使用即可\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry\u0026amp;amp;scheme=digest\u0026amp;amp;addAuth=sofazk:rpc1 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-zookeeper/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"71d6486c5577cc85d84c56688cdf2af1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","summary":"使用 Zookeeper 作为服务注册中心只需要在 application.properties 中如下配置即可： com.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 注意：考虑掉服务的实时性，以下特性暂不支持 SOFABoot RPC 也提供一个缓存文件(目前暂不支持)，当 Zookeeper 不可","tags":null,"title":"使用 Zookeeper 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","wordcount":309},{"author":null,"categories":null,"content":"使用本地文件作为服务注册中心在 application.properties 中如下配置即可：\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg 其中 /home/admin/registry/localRegistry.reg 就是使用的本地文件的目录。\n对于 windows 用户，则以上地址类似：\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-local/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"33bc89393392e21b3917f090313c0df5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-local/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-local/","summary":"使用本地文件作为服务注册中心在 application.properties 中如下配置即可： com.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg 其中 /home/admin/registry/localRegistry.reg 就是使用的本地文件的目录。 对于 windows 用户，则以上地址类似： com.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg","tags":null,"title":"使用本地文件作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-local/","wordcount":56},{"author":null,"categories":null,"content":" SOFABoot 是在 Spring Boot 的基础上提供的功能扩展。基于 Spring Boot 的机制，SOFABoot 管理了 SOFA 中间件的依赖，并且提供了 Spring Boot 的 Starter，方便用户在 Spring Boot 中使用 SOFA 中间件。\nSOFABoot 依赖管理 \u0026amp;ndash; Maven 在使用 SOFA 中间件之前，需要引入 SOFABoot 依赖管理。类似 Spring Boot 引入方式，在工程中增加如下 \u0026amp;lt;parent/\u0026amp;gt; 标签配置的方式:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 其中 ${sofa.boot.version} 为具体的 SOFABoot 版本，参考发布历史。\nSOFABoot 依赖管理 \u0026amp;ndash; Gradle 从 SOFABoot 3.1.1 版本开始，SOFABoot 开始支持使用 Gradle 来进行依赖管理，如果要使用 Gradle 来进行依赖管理，需要按照如下的形式来配置 build.gradle：\nbuildscript { ext { sofaBootVersion = \u0026#39;3.1.1\u0026#39; } repositories { mavenLocal() mavenCentral() } dependencies { classpath(\u0026amp;quot;com.alipay.sofa:sofa-boot-gradle-plugin:${sofaBootVersion}\u0026amp;quot;) } } apply plugin: \u0026#39;java\u0026#39; apply plugin: \u0026#39;eclipse\u0026#39; apply plugin: \u0026#39;com.alipay.sofa.boot\u0026#39; apply plugin: \u0026#39;io.spring.dependency-management\u0026#39; group = \u0026#39;com.example\u0026#39; version = \u0026#39;0.0.1-SNAPSHOT\u0026#39; sourceCompatibility = 1.8 repositories { mavenLocal() mavenCentral() } dependencies { implementation(\u0026#39;com.alipay.sofa:rpc-sofa-boot-starter\u0026#39;) implementation(\u0026#39;org.springframework.boot:spring-boot-starter\u0026#39;) testImplementation(\u0026#39;org.springframework.boot:spring-boot-starter-test\u0026#39;) } 主要有几个步骤：\n 添加 buildScript，增加 sofa-boot-gradle-plugin 的依赖，其中版本号为你使用的 SOFABoot 的版本。 添加两个 plugin，分别是 com.alipay.sofa.boot 和 io.spring.dependency-management。 这样，在 dependencies 里面，就可以直接添加 SOFABoot 管理的各种中间件和依赖了，而不用声明版本号。\n引入 SOFA 中间件 SOFABoot 使用一系列后缀为 -sofa-boot-starter 来标示一个中间件组件，如果想要使用某个中间件，直接添加对应的依赖即可。例如，如果期望使用 SOFARPC，只需增加下面的 Maven 依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 注意上面的 Maven 依赖中并没有声明版本，这个是因为版本已经在 sofaboot-dependencies 里面声明好。这样做的好处是对于 SOFA 中间件，用户统一进行升级即可，不需要单独升级一个中间件的版本，防止出现依赖冲突以及兼容性的问题。目前管控的 SOFABoot 中间件列表如下:\n 中间件 starter SOFARPC rpc-sofa-boot-starter SOFATracer tracer-sofa-boot-starter SOFALookout lookout-sofa-boot-starter 引入 SOFABoot 扩展组件 SOFABoot 基于 Spring Boot 提供了健康检查，模块隔离，类隔离等扩展能力。遵循 Spring Boot 依赖即服务的理念，添加相关组件依赖之后，扩展能力即可生效。目前提供的扩展组件如下：\n 扩展组件 starter 健康检查 actuator-sofa-boot-starter 模块化隔离 isle-sofa-boot-starter 类隔离 sofa-ark-springboot-starter 测试扩展 test-sofa-boot-starter 引入 SOFA 中间件 ark 插件 SOFABoot 提供了类隔离组件 SOFAArk，借助 SOFAArk 容器，用户可以将依赖冲突的三方包打包成 ark 插件。运行时，ark 插件使用单独的类加载器加载，可以和其他 ark 插件以及业务依赖隔离，解决类冲突问题。SOFABoot 官方提供了 SOFARPC 和 SOFATracer 的 ark 插件，例如在应用中引入 SOFARPC ark 插件依赖替代 SOFARPC starter，从而隔离应用和 SOFARPC 及其间接依赖。目前管控的 ark 插件列表如下:\n Ark插件 plugin SOFARPC rpc-sofa-boot-plugin SOFATracer tracer-sofa-boot-plugin 引入 SOFABoot 命名空间 使用 SOFA 中间件时，需要在 XML 中根据中间件的具体使用方式添加相应的配置，这个时候需要引入 SOFABoot 的命名空间 xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; 以能够正确解析相应的配置标签，示例：\n\u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/dependency-management/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dabdbd425f20dee4d7ab580d43574456","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/dependency-management/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/dependency-management/","summary":"SOFABoot 是在 Spring Boot 的基础上提供的功能扩展。基于 Spring Boot 的机制，SOFABoot 管理了 SOFA 中间件的依赖，并且提供了 Spring Boot 的 Starter，方便用户在 Spring Boot 中使用","tags":null,"title":"依赖管理","type":"projects","url":"/sofastack.tech/projects/sofa-boot/dependency-management/","wordcount":981},{"author":null,"categories":null,"content":"SOFARPC 使用了一些三方开源组件，他们分别是：\n一些主要依赖：\n Netty under Apache License 2.0 SLF4j under the MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 一些扩展依赖：\n protobuf under New BSD License Snappy under Apache License 2.0 dubbo under Apache License 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b6c87388d5c1462f13d92012639a08b2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/notice/","summary":"SOFARPC 使用了一些三方开源组件，他们分别是： 一些主要依赖： Netty under Apache License 2.0 SLF4j under the MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 一些扩展依赖： protobuf under New BSD License","tags":null,"title":"依赖组件版权说明","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/notice/","wordcount":87},{"author":null,"categories":null,"content":" SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 的能力。如果你需要使用 SOFA 中间件，那么建议使用 SOFABoot 的健康检查能力的扩展，来更优雅的上线应用实例\n引入健康检查扩展 要引入 SOFABoot 的健康检查能力的扩展，只需要引入以下的 Starter 即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 如果不引入 SOFABoot 的健康检查扩展，用户依然可以直接依赖 HealthIndicator 接口进行原生的 Spring Boot Actuator 的 Liveness Check。\n安全提醒 从 SOFABoot 2.3.0 开始，由于健康检查能力依赖于 SpringBoot 1.4.x 里的 Actuator 组件，而 Actuator 会默认开启很多 EndPoint，例如 /dump，/trace 等等，可能存在安全风险，可以参照官方文档里的安全建议进行设置。\n SpringBoot 1.5.x 和 SpringBoot 2.x 已修复了部分安全行为，SOFABoot 将通过升级 SpringBoot 内核进行支持。\n 查看健康检查结果 加入健康检查扩展之后，我们可以直接在浏览器中输入 http://localhost:8080/health/readiness 来查看 Readiness Check 的结果。如果要查看 Liveness Check 的结果，可以直接查看 Spring Boot 的健康检查的 URL http://localhost:8080/health。\n除了通过 URL 来查看健康检查的结果之外，在 SOFABoot 中，还可以通过查看具体的日志来确定健康检查的结果，日志的目录位于 health-check 目录下，日志的内容大概如下：\n2018-04-06 23:29:50,240 INFO main - Readiness check result: success 目前 SOFA 中间件已经通过 SOFABoot 的 Readiness Check 的能力来控制了上游流量的进入，但是一个应用的流量可能并不是全部都是从中间件进入的，比较常见的还有从负载均衡器进入的，为了控制从负载均衡器进入的流量，建议使用者通过 PAAS 来访问 Readiness Check 的结果，根据结果来控制是否要在负载均衡器中上线对应的节点。\n注: 自 SOFABoot 2.x 之后，不再间接引入 spring-boot-starter-web 依赖，如果需要在浏览器中查看健康检查结果，需要额外在工程中引入 web 容器依赖。\n注: 在 SOFABoot 3.x 中调整了 endpoint 路径，health/readiness 更改为 actuator/readiness\n扩展 Readiness Check 能力 在 Readiness Check 的各个阶段，SOFABoot 都提供了扩展的能力，应用可以根据自己的需要进行扩展，在 2.x 版本中，可供扩展的点如下：\n 回调接口 说明 org.springframework.context.ApplicationListener 如果想要在 Readiness Check 之前做一些事情，那么监听这个 Listener 的 SofaBootBeforeHealthCheckEvent 事件。 org.springframework.boot.actuate.health.HealthIndicator 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 com.alipay.sofa.healthcheck.startup.SofaBootAfterReadinessCheckCallback 如果想要在 Readiness Check 之后做一些事情，那么可以扩展 SOFABoot 的这个接口。 在 3.x 版本中，可供扩展点如下：\n 回调接口 说明 com.alipay.sofa.healthcheck.core.HealthChecker 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，可以直接扩展该接口。相较于 Spring Boot 本身的 HealthIndicator 接口，该接口提供了一些额外的参数配置，比如检查失败重试次数等。 org.springframework.boot.actuate.health.HealthIndicator 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 org.springframework.boot.actuate.health.ReactiveHealthIndicator 在 WebFlux 中，如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 com.alipay.sofa.healthcheck.startup.ReadinessCheckCallback 如果想要在 Readiness Check 之后做一些事情，那么可以扩展 SOFABoot 的这个接口。 需要指出的是，上述四个扩展接口均可以通过 Spring Boot 标准的 Ordered, PriorityOrdered 和注解 @Order 实现执行顺序的设置。\nReadiness Check 配置项 应用在引入 SOFABoot 的健康检查扩展之后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 Readiness Check 的相关行为。\n Readiness Check 配置项 说明 默认值 开始支持版本 com.alipay.sofa.healthcheck.skip.all 是否跳过整个 Readiness Check 阶段 false 2.4.0 com.alipay.sofa.healthcheck.skip.component 是否跳过 SOFA 中间件的 Readiness Check false 2.4.0 com.alipay.sofa.healthcheck.skip.indicator 是否跳过 HealthIndicator 的 Readiness Check false 2.4.0 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/health-check/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a366b25125fa4aedb08a9cef572db1c8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/health-check/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/health-check/","summary":"SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 的能力。如果你需要使用 SOFA 中间件，那么建议使用 SOFABoot 的健康检查能力的扩展，来更优雅的上线应用实例 引入健康检查扩展 要","tags":null,"title":"健康检查","type":"projects","url":"/sofastack.tech/projects/sofa-boot/health-check/","wordcount":1269},{"author":null,"categories":null,"content":" 目前默认生效的的扩展模块是：lookout-ext-jvm，lookout-ext-os(from v1.5.0)。\n JVM 线程 metric name metric tags specification jvm.threads.totalStarted \u0026amp;mdash; jvm.threads.active \u0026amp;mdash; jvm.threads.peak \u0026amp;mdash; jvm.threads.daemon \u0026amp;mdash; JVM 类加载 metric name metric tags specification jvm.classes.unloaded \u0026amp;mdash; jvm.classes.loaded \u0026amp;mdash; jvm.classes.total \u0026amp;mdash; JVM 内存 metric name metric tags specification jvm.memory.heap.init \u0026amp;mdash; jvm.memory.heap.used \u0026amp;mdash; jvm.memory.heap.max \u0026amp;mdash; jvm.memory.heap.committed \u0026amp;mdash; JVM 垃圾回收 metric name metric tags specification jvm.gc.young.time \u0026amp;mdash; jvm.gc.young.count \u0026amp;mdash; jvm.gc.old.time \u0026amp;mdash; jvm.gc.old.count \u0026amp;mdash; 机器文件系统信息 metric name metric tags specification instance.file.system.free.space root（文件系统根目录名） \u0026amp;mdash; instance.file.system.total.space root \u0026amp;mdash; instance.file.system.usabe.space root \u0026amp;mdash; 机器信息 metric name metric tags specification instance.mem.free \u0026amp;mdash; instance.mem.total \u0026amp;mdash; instance.processors \u0026amp;mdash; instance.uptime \u0026amp;mdash; instance.systemload.average \u0026amp;mdash; Linux 操作系统信息 （1.5.0版本之后默认启用） metric name metric tags specification os.systemload.average.1min \u0026amp;mdash; os.systemload.average.5min \u0026amp;mdash; os.systemload.average.15min \u0026amp;mdash; os.cpu.idle \u0026amp;mdash; os.cpu.iowait \u0026amp;mdash; os.cpu.irq \u0026amp;mdash; os.cpu.nice \u0026amp;mdash; os.cpu.softirq \u0026amp;mdash; os.cpu.system \u0026amp;mdash; os.cpu.user \u0026amp;mdash; os.disk.usage.percent.used device,root,type \u0026amp;mdash; os.disk.usage.total.bytes device,root,type \u0026amp;mdash; os.disk.usage.used.bytes device,root,type \u0026amp;mdash; os.net.stats.in.bytes intfc \u0026amp;mdash; os.net.stats.in.compressed intfc \u0026amp;mdash; os.net.stats.in.dropped intfc \u0026amp;mdash; os.net.stats.in.errs intfc \u0026amp;mdash; os.net.stats.in.fifo.errs intfc \u0026amp;mdash; os.net.stats.in.frame.errs intfc \u0026amp;mdash; os.net.stats.in.multicast intfc \u0026amp;mdash; os.net.stats.in.packets intfc \u0026amp;mdash; os.net.stats.out.bytes intfc \u0026amp;mdash; os.net.stats.out.carrier.errs intfc \u0026amp;mdash; os.net.stats.out.collisions intfc \u0026amp;mdash; os.net.stats.out.compressed intfc \u0026amp;mdash; os.net.stats.out.dropped intfc \u0026amp;mdash; os.net.stats.out.errs intfc \u0026amp;mdash; os.net.stats.out.fifo.errs intfc \u0026amp;mdash; os.net.stats.out.packets intfc \u0026amp;mdash; os.memory.stats.buffers.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.cached.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.free.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.total.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-ext-metrics/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c8a4fb3d904e359e99db9d4e81e60812","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","summary":"目前默认生效的的扩展模块是：lookout-ext-jvm，lookout-ext-os(from v1.5.0)。 JVM 线程 metric name metric tags specification jvm.threads.totalStarted \u0026mdash; jvm.threads.active \u0026mdash; jvm.threads.peak","tags":null,"title":"内置扩展 Metrics 指标","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","wordcount":296},{"author":null,"categories":null,"content":" 分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等） Zab：被应用在 zookeeper 中，业界使用广泛，但没有抽象成通用的 library Raft：以容易理解著称，业界也涌现出很多 raft 实现，比如大名鼎鼎的 etcd, braft, tikv 等 什么是 Raft？ Raft 是一种更易于理解的分布式共识算法，核心协议本质上还是师承 paxos 的精髓，不同的是依靠 raft 模块化的拆分以及更加简化的设计，raft 协议相对更容易实现。\n模块化的拆分主要体现在：Raft 把一致性协议划分为 Leader 选举、MemberShip 变更、日志复制、Snapshot 等几个几乎完全解耦的模块\n更加简化的设计则体现在：Raft 不允许类似 paxos 中的乱序提交、简化系统中的角色状态（只有 Leader、Follower、Candidate三种角色）、限制仅 Leader 可写入、使用随机化的超时时间来设计 Leader Election 等等\n特点：Strong Leader 系统中必须存在且同一时刻只能有一个 leader，只有 leader 可以接受 clients 发过来的请求 Leader 负责主动与所有 followers 通信，负责将\u0026amp;rsquo;提案\u0026amp;rsquo;发送给所有 followers，同时收集多数派的 followers 应答 Leader 还需向所有 followers 主动发送心跳维持领导地位(保持存在感) 一句话总结 Strong Leader: \u0026amp;ldquo;你们不要 BB! 按我说的做，做完了向我汇报!\u0026amp;rdquo; 另外，身为 leader 必须保持一直 BB(heartbeat) 的状态，否则就会有别人跳出来想要 BB\n复制状态机 对于一个无限增长的序列 a[1, 2, 3…]，如果对于任意整数 i，a[i] 的值满足分布式一致性，这个系统就满足一致性状态机的要求 基本上所有的真实系统都会有源源不断的操作，这时候单独对某个特定的值达成一致显然是不够的。为了让真实系统保证所有的副本的一致性，通常会把操作转化为 write-ahead-log(WAL)。然后让系统中所有副本对 WAL 保持一致，这样每个副本按照顺序执行 WAL 里的操作，就能保证最终的状态是一致的\n Client 向 leader 发送写请求 Leader 把\u0026amp;rsquo;操作\u0026amp;rsquo;转化为 WAL 写本地 log 的同时也将 log 复制到所有 followers Leader 收到多数派应答, 将 log 对应的\u0026amp;rsquo;操作\u0026amp;rsquo; 应用到状态机 回复 client 处理结果 Raft 中的基本概念 Raft-node 的 3 种角色/状态 Follower：完全被动，不能发送任何请求，只接受并响应来自 leader 和 candidate 的 message，每个节点启动后的初始状态一定是 follower Leader：处理所有来自客户端的请求，以及复制 log 到所有 followers Candidate：用来竞选一个新 leader （candidate 由 follower 触发超时而来） Message 的 3 种类型 RequestVote RPC：由 candidate 发出，用于发送投票请求 AppendEntries (Heartbeat) RPC：由 leader 发出，用于 leader 向 followers 复制日志条目，也会用作 Heartbeat （日志条目为空即为 Heartbeat） InstallSnapshot RPC：由 leader 发出，用于快照传输，虽然多数情况都是每个服务器独立创建快照，但是leader 有时候必须发送快照给一些落后太多的 follower，这通常发生在 leader 已经丢弃了下一条要发给该follower 的日志条目(Log Compaction 时清除掉了) 的情况下 任期逻辑时钟 时间被划分为一个个任期 (term)，term id 按时间轴单调递增 每一个任期的开始都是 leader 选举，选举成功之后，leader 在任期内管理整个集群，也就是 \u0026amp;lsquo;选举 + 常规操作\u0026amp;rsquo; 每个任期最多一个 leader，可能没有 leader (spilt-vote 导致) Raft 功能分解 Leader 选举 超时驱动：Heartbeat/Election timeout 随机的超时时间：降低选举碰撞导致选票被瓜分的概率 选举流程： Follower \u0026amp;ndash;\u0026amp;gt; Candidate (选举超时触发) 赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Leader 另一个节点赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Follower 一段时间内没有任何节点器赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Candidate 选举动作： Current term++ 发送 RequestVote RPC New Leader 选取原则 (最大提交原则) Candidates include log info in RequestVote RPCs(index \u0026amp;amp; term of last log entry) During elections, choose candidate with log most likely to contain all committed entries Voting server V denies vote if its log is “more complete”: (lastTermV \u0026amp;gt; lastTermC) || ((lastTermV == lastTermC) \u0026amp;amp;\u0026amp;amp; (lastIndexV \u0026amp;gt; lastIndexC)) Leader will have “most complete” log among electing majority 安全性：一个 term，最多选出一个 leader，可以没 leader，下一个 term 再选 影响 raft 选举成功率的几个时间参数： RTT(Round Trip Time)：网络延时 Heartbeat timeout：心跳间隔，通常应该比 election timeout 小一个数量级，目的是让 leader 能够持续发送心跳来阻止 followers 触发选举 Election timeout：Leader 与 followers …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/consistency-raft-jraft/","fuzzywordcount":8000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a0e98df1bec305cca7db6fc34fc97771","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":16,"relpermalink":"/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","summary":"分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? P","tags":null,"title":"分布式一致性 Raft 与 JRaft","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","wordcount":7950},{"author":"林楠","categories":"SOFAStack","content":" 前言 在实践中，我们通常会使用业务功能模块化的开发模式，部署时将不同模块合并部署，由于团队间技术栈不统一，此时就有可能出现依赖冲突等问题。SOFAArk 定义了一种开发规范，将不同的应用模块打包成 Ark Biz，由一个基座 Biz 和多个 Biz 模块组成部署包，支持两种合并部署的方式，一种是静态合并部署，Ark Biz 以 Maven 依赖的方式引入项目；另一种是在运行时使用 API 或者 配置中心（Zookeeper）动态地安装或卸载 Biz，本文将重点讨论此方式。\nArk Biz 的生命周期 Ark Biz 的生命周期主要包含三条指令：\n install: 安装 Biz uninstall: 卸载 Biz switch: 激活 Biz 在动态的安装和卸载时，Ark Biz 会流转于生命周期的五个阶段，Biz 在不同阶段时的状态如下：\n unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时 Biz 包还没有安装或者安装中 activated: Biz 包启动完成，且处于激活状态，可以对外提供服务 broken: Biz 包启动失败后状态 deactivated: Biz 包启动完成，但处于未激活状态(注意这个状态只对 JVM 服务生效，对 RPC 等其他中间件无效) 这里我们可以看一下 Ark Biz 的数据模型 BizModel 类：\npublic class BizModel implements Biz { ... private String bizName; private String bizVersion; private BizState bizState; ... } 在 Ark Biz 的数据模型中 bizState 表示的就是当前状态，可以看到数据模型中定义了 Biz 包的名称和版本号，在运行时 SOFAArk 允许部署相同名称不同版本的 Biz，但只能有一个版本处于 activated 激活状态，其他版本的 Biz 状态将自动处于 deactivated 未激活状态。\ninstall 在入口方法 ArkClient#installOperation 中，下载 Biz 包到本地临时文件，临时文件命名规则：${bizName}-${bizVersion}-${时间戳}。准备好 Biz 包后，调用 installBiz 方法，进入安装主流程。\npublic static ClientResponse installOperation(BizOperation bizOperation) throws Throwable { return installOperation(bizOperation, arguments); } public static ClientResponse installOperation(BizOperation bizOperation, String[] args) throws Throwable { ... if (bizOperation.getParameters().get(Constants.CONFIG_BIZ_URL) != null) { URL url = new URL(bizOperation.getParameters().get(Constants.CONFIG_BIZ_URL)); bizFile = ArkClient.createBizSaveFile(bizOperation.getBizName(), bizOperation.getBizVersion()); FileUtils.copyInputStreamToFile(url.openStream(), bizFile); } return installBiz(bizFile, args); } 安装 Ark Biz 的主流程：\n 解析 Biz 包，创建 BizModel 将 Ark Biz 注册到 Biz Manager 中（如果已经注册过，安装流程将直接结束，并返回提示信息） 启动 Ark Biz 如果启动失败，则关停并卸载 Ark Biz public static ClientResponse installBiz(File bizFile, String[] args) throws Throwable { ... Biz biz = bizFactoryService.createBiz(bizFile); // 1 ClientResponse response = new ClientResponse(); if (bizManagerService.getBizByIdentity(biz.getIdentity()) != null || !bizManagerService.registerBiz(biz)) { // 2 return response.setCode(ResponseCode.REPEAT_BIZ).setMessage( String.format(\u0026amp;quot;Biz: %s has been installed or registered.\u0026amp;quot;, biz.getIdentity())); } try { biz.start(args); // 3 ... response .setCode(ResponseCode.SUCCESS) .setMessage( String.format(\u0026amp;quot;Install Biz: %s success, cost: %s ms, started at: %s\u0026amp;quot;, biz.getIdentity(), end - start, startDate)) .setBizInfos(Collections.\u0026amp;lt;BizInfo\u0026amp;gt; singleton(biz)); return response; } catch (Throwable throwable) { ... response.setCode(ResponseCode.FAILED).setMessage( String.format(\u0026amp;quot;Install Biz: %s fail,cost: %s ms, started at: %s\u0026amp;quot;, biz.getIdentity(), end - start, startDate)); ... try { biz.stop(); // 4 } catch (Throwable e) { ... throw e; } finally { bizManagerService.unRegisterBizStrictly(biz.getBizName(), biz.getBizVersion()); } return response; } } 解析 Ark Biz 当开启内嵌模式时，将 Biz 包解压到 ${Biz}-unpack 目录下，生成展开型的 Biz 包；当未开启内嵌模式时，直接使用原始的 Biz Jar 包，生成压缩型的 Biz …","date":-62135596800,"description":"源码解析 | 动态部署","dir":"projects/sofa-boot/sofa-ark-dynamic-deploy/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"49b198c473b8ee5d8de18d8260661df6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","summary":"前言 在实践中，我们通常会使用业务功能模块化的开发模式，部署时将不同模块合并部署，由于团队间技术栈不统一，此时就有可能出现依赖冲突等问题。SO","tags":["源码解析"],"title":"动态部署","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","wordcount":3759},{"author":null,"categories":null,"content":" 单元测试 单元测试例子放到自己开发的模块下。\n如果依赖了第三方服务端（例如Zookeeper），请手动加入 profile。参考 registry-zookeeper 模块代码。\n如果依赖了其它模块要集成测试，请放到 test/test-intergrated 模块中。\n如果还依赖了第三方服务端（例如Zookeeper），请放到 test-intergrated-3rd 模块中。\n性能测试 关闭了以下默认开启项目：\n-Dcontext.attachment.enable=false -Dserialize.blacklist.enable=false -Ddefault.tracer= -Dlogger.impl=com.alipay.sofa.rpc.log.SLF4JLoggerImpl -Dmultiple.classloader.enable=false -Devent.bus.enable=false\n我们对 BOLT+hessian 进行了压测。\n服务端：4C8G 虚拟机，千M网络，jdk1.8.0_111；\n客户端：50个客户端并发请求。\n 协议 请求 响应 服务端 TPS 平均RT(ms) bolt+hessian 1K String 1K String 直接返回 10000 1.93 bolt+hessian 1K String 1K String 直接返回 20000 4.13 bolt+hessian 1K String 1K String 直接返回 30000 7.32 bolt+hessian 1K String 1K String 直接返回 40000 15.78 bolt+hessian 1K String 1K String 直接返回 50000(接近极限,错误率0.3%） 26.51 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/test/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ccda7c2372a7f55d61f682b72d3b1dc2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/test/","summary":"单元测试 单元测试例子放到自己开发的模块下。 如果依赖了第三方服务端（例如Zookeeper），请手动加入 profile。参考 registry-zookeeper 模块代码。 如果依","tags":null,"title":"单元测试与性能测试","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/test/","wordcount":292},{"author":null,"categories":null,"content":" 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git 官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git 协作流程 GitHub 贡献代码流程 提交 issue 不论您是修复 ACTS 的 bug 还是新增 ACTS 的功能，在您提交代码之前，在 ACTS 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. ACTS 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 ACTS 主干代码到您的代码仓库。\n拉分支 ACTS 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式.\ngit clone https://github.com/您的账号名/acts.git 拉分支准备修改代码\ngit branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n 修改完代码后，执行如下命令提交所有修改到本地\ngit commit -am \u0026#39;添加xx功能\u0026#39; 修改代码注意事项 代码风格保持一致 ACTS 通过 Maven 插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码\n 新有修改应该通过已有的单元测试.\n 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\nmvn clean test 也可以通过 IDE 来辅助运行。\n 其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。 * 执行如下命令提交本地修改到 github 上\n``` git push origin \u0026amp;quot;branchname\u0026amp;quot; ``` 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 ACTS 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 ACTS 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 ACTS 的人员， ACTS 人员会 Review 您的代码，符合要求后就会合入主干，成为 ACTS 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 ACTS 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/contributing/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cd68baede6258921f83665ef0a446f1f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/contributing/","summary":"准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git 官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章G","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-acts/contributing/","wordcount":1224},{"author":null,"categories":null,"content":" 可以先去 发展路线 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看 git官方书籍，需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程。 GitHub 贡献代码流程 提交issue 不论您是修复 SOFAArk 的 bug 还是新增 SOFAArk 的功能，在您提交代码之前，在 SOFAArk 的 GitHub 地址上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFAArk 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的fork按钮，复制一份 SOFAArk 主干代码到您的代码仓库。\n拉分支 SOFAArk 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择git/https方式.\ngit clone https://github.com/您的账号名/sofa-ark.git 拉分支准备修改代码\ngit branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\n git branch -a 如果您想切换回主干，执行下面命令:\n git checkout -b master 如果您想切换回分支，执行下面命令：\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFAArk 通过 Maven 插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\n mvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\n git commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFAArk 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFAArk 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFAArk 的人员， SOFAArk 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFAArk 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFAArk 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-contribution/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dbf77f98884a71c5c7a3fbb4dd189cfe","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","summary":"可以先去 发展路线 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看 git官方书籍，需要阅","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","wordcount":1278},{"author":null,"categories":null,"content":" 可以先去 RoadMap 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看 git官方书籍，需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFADashboard 的 bug 还是新增 SOFADashboard 的功能，在您提交代码之前，在 SOFADashboard 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。\n这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFADashboard 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFADashboard 主干代码到您的代码仓库。\n拉分支 SOFADashboard 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式.\ngit clone https://github.com/您的账号名/sofa-dashboard.git 拉分支准备修改代码 bash git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令: bash git checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFADashboard 通过 Maven插件来保持代码格式一致。在提交代码前，务必本地执行\nmvn clean compile 补充单元测试代码\n 新有修改应该通过已有的单元测试.\n 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug\n您可以用如下命令运行所有测试\nmvn clean test 也可以通过 IDE 来辅助运行。 其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地：\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFADashboard 的代码仓库。\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFADashboard 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFADashboard 的人员， SOFADashboard 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFADashboard 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。 对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFADashboard 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/contribution/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"584584be9c13f2d36c85890dd192368a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/contribution/","summary":"可以先去 RoadMap 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看 git官方书籍，需要阅读前几","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/contribution/","wordcount":1262},{"author":null,"categories":null,"content":" 可以先去 发展路线 \u0026amp;amp; 任务认领 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFARegistry 的 bug 还是新增 SOFARegistry 的功能，在您提交代码之前，在 SOFARegistry 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFARegistry 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFARegistry 主干代码到您的代码仓库。\n拉分支 SOFARegistry 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式. git clone https://github.com/您的账号名/sofa-registry.git 拉分支准备修改代码 git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFARegistry 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug您可以用如下命令运行所有测试 mvn clean test 也可以通过 IDE 来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFARegistry 的代码仓库.\n提交合并代码到主干的请求 在您的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFARegistry 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request 按钮。选择目标分支,一般就是 master，系统会通知 SOFARegistry 的人员， SOFARegistry 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFARegistry 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFARegistry 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/contributing/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c08b5945719137833634c111c43a8d9e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/contributing/","summary":"可以先去 发展路线 \u0026amp; 任务认领 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git官方书","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-registry/contributing/","wordcount":1264},{"author":null,"categories":null,"content":" 可以先去 发展路线 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFARPC 的 bug 还是新增 SOFARPC 的功能，在您提交代码之前，在 SOFARPC 的GitHub上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFARPC 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的fork按钮，复制一份 SOFARPC 主干代码到您的代码仓库。\n拉分支 SOFARPC 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择git/https方式. git clone https://github.com/您的账号名/sofa-rpc.git 在提交pull request请求前, 请将您克隆的代码和远程代码库同步，这样您的pull request会简单清晰 git remote add upstream git@github.com:sofastack/sofa-rpc.git git fetch upstream git rebase upstream/master 拉分支准备修改代码 git checkout -b add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFARPC 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\nmvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFARPC 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFARPC 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFARPC 的人员， SOFARPC 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFARPC 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFARPC 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/contributing/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"448a7b9a949bd2d9e2e71ac6c237f9df","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/contributing/","summary":"可以先去 发展路线 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git官方书籍,需要阅","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/contributing/","wordcount":1351},{"author":null,"categories":null,"content":" 客户端发展规划 v2.0 ，在基于 Java 8 进行重构，v1.0 为支持 Java 6 做了些设计与性能妥协； 集成更多的开源产品； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/plan/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6153fc1f5e000f195d96dfdb03c5b381","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/plan/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/plan/","summary":"客户端发展规划 v2.0 ，在基于 Java 8 进行重构，v1.0 为支持 Java 6 做了些设计与性能妥协； 集成更多的开源产品；","tags":null,"title":"发展规划","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/plan/","wordcount":49},{"author":null,"categories":null,"content":" 任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 代码 支持多个 Web 应用合并部署，采用多 Host/单 Host 两种模式 难 代码 支持 telnet 指令查看 ark plugin 简单 代码 支持 telnet 指令查看 jvm/rpc 服务 中 版本迭代计划 v0.5.0 支持多个 Web 应用合并部署，采用多 Host/单 Host 两种模式 v0.6.0 支持 telnet 指令查看 ark plugin； 支持 telnet 指令查看 jvm/rpc 服务； ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-roadmap/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c4532d11cef15d8fe3ff5e04c7b08f90","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","summary":"任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 代码 支持多个 Web 应用合","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","wordcount":175},{"author":null,"categories":null,"content":" 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。\n如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关Issue 文档 文档翻译 低 代码 弹性长连接管理方式 低 #56 代码 etcd注册中心实现 中 @wynn5a\n2018-6 #153 代码 eureka注册中心实现 中 @liufeiit\n2018-4 #52 代码 gRPC 支持 高 #57 代码 CXF 协议 高 #58 代码 TLS 支持 高 版本迭代计划 v5.5.0 JSON 序列化支持 H2的TLS安全支持 弹性连接池 hystrix集成 Consul注册中心支持 v5.6.0 grpc 通讯层支持 etcd注册中心支持 SofaMesh支持 BOLT 版本协商与 CRC 校验 v5.7.0 Telnet 内置指令支持 SpringBoot 2.0 支持 Mock功能支持 加密功能支持 v5.8.0 授权支持 SofaRegistry 支持 Reactive 支持 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/roadmap/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6064fc180911f520f6d1590b88595693","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/roadmap/","summary":"任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。 如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。 类型","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/roadmap/","wordcount":292},{"author":null,"categories":null,"content":" 任务列表 欢迎大家领取任务参与贡献。\n 类型 任务 困难度 认领人及时间 计划发布时间 计划完成时间 进度 相关 issue 代码 SOFATracer 性能优化专题 高 issue 18和 issue 11 代码 SOFATracer 支持 HttpClient 中 已经完成，见 HttpClient 接入文档 代码 SOFATracer 数据汇报能力提供在非 SOFABoot 框架下的运行和配置能力 中 已经完成，见 Spring 工程中使用 SOFATracer issue 32 代码 SOFATracer 提供采样能力 中 已经完成，见使用 SOFATracer 的采样能力 issue 10 代码 SOFATracer 支持 Zipkin 2.X.X 版本 中 已经完成，见使用 SOFATracer 远程汇报数据到 Zipkin issue 23 代码 SOFATracer 支持 Druid 中 已经完成，见 DataSource 接入文档 代码 SOFATracer 支持 c3p0 中 已经完成 代码 SOFATracer 支持 Tomcat-JDBC 中 已经完成 代码 SOFATracer 支持 HikariCP 中 已经完成 代码 SOFATracer 支持 dbcp 中 已经完成，见 DataSource 接入文档 代码 SOFATracer 支持 dbcp2 中 已经完成 代码 SOFATracer 支持 Sharding-JDBC 中 代码 SOFATracer 支持 Mysql JDBC Driver 中 代码 SOFATracer 支持 Oracle JDBC Driver 中 代码 SOFATracer 支持 Dubbo 中 代码 SOFATracer 支持 RestTemplate 和 AsyncRestTemplate 中 已经完成 代码 SOFATracer 支持标准Servlet 中 已经完成，见对于标准 servlet 容器的支持（ tomcat/jetty 等） 代码 SOFATracer 支持单机版链路分析并给用户通过注解使用的埋点方式，数据汇报到 Zipkin 中 代码 SOFATracer 支持 Kafka 中 代码 SOFATracer 支持 Redis 中 代码 SOFATracer 支持 hystrix 中 文档 文档翻译 中 版本迭代计划 2.2.0 SOFATracer 支持 JDBC 数据源 SOFATracer 支持 Mysql Driver SOFATracer 支持 Sharding-JDBC SOFATracer 支持 Mysql-JDBC SOFATracer 支持 Druid SOFATracer 支持 c3p0 SOFATracer 支持 Tomcat-JDBC SOFATracer 支持 HikariCP SOFATracer 支持 HttpClient SOFATracer 支持 Zipkin 2.X.X 版本，开发验证并测试 2.3.0 SOFATracer 支持RestTemplate 和 AsyncRestTemplate SOFATracer 支持提供采样能力 SOFATracer 支持标准 servlet 容器 SOFATracer 支持 Zipkin UI 中文界面 SOFATracer 支持数据汇报能力提供在非 SOFABoot 框架下的运行和配置能力 2.4.0 SOFATracer 支持 Dubbo SOFATracer 支持 Kafka SOFATracer 性能优化专题 2.5.0 SOFATracer 支持单机版链路分析并给用户通过注解使用的埋点方式，数据汇报到 Zipkin 展示 SOFATracer 支持 manual report SOFATracer 支持 基于 Opentracing API 埋点方式 SOFATracer 支持 Opentracing 0.30.0+ 版本 ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/roadmap/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8b0a6fbe5f6ea5ae789f5186271073c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/roadmap/","summary":"任务列表 欢迎大家领取任务参与贡献。 类型 任务 困难度 认领人及时间 计划发布时间 计划完成时间 进度 相关 issue 代码 SOFATracer 性能优化专题 高 issue 18和 issue 11 代码 SOFATracer 支持 HttpClient 中","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/roadmap/","wordcount":605},{"author":null,"categories":null,"content":" 发展路线 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。\n如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关issue 文档 文档翻译 低 代码 支持Spring Cloud 中 代码 数据自检 高 代码 黑名单过滤 中 代码 SOFARegistry Dashboard 高 代码 支持其他微服务框架 中 代码 支持 Docker \u0026amp;amp; Kubernetes 高 代码 多语言客户端支持 高 版本迭代计划 v5.3.0 支持 Spring Cloud 数据自检 黑名单过滤 v5.4.0 SOFARegistry Dashboard 支持其他微服务框架 v5.5.0 支持 Docker \u0026amp;amp; Kubernetes 多语言客户端支持 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/roadmap/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b0ab45d52ba3eb7db590a4f5e4197c9e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/roadmap/","summary":"发展路线 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。 如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡","tags":null,"title":"发展路线 \u0026 任务认领","type":"projects","url":"/sofastack.tech/projects/sofa-registry/roadmap/","wordcount":216},{"author":null,"categories":null,"content":"更多参见：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md\n","date":-62135596800,"description":"","dir":"projects/mosn/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"62efb8e40401ab4612bcccaa6e942c97","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/release-notes/","summary":"更多参见：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md","tags":null,"title":"发布历史","type":"projects","url":"/sofastack.tech/projects/mosn/release-notes/","wordcount":61},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-rpc/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ab7d46caa6906863103b77b742ec7e84","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/release-notes/","summary":"更多参见：https://github.com/sofastack/sofa-rpc/releases","tags":null,"title":"发布历史","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/release-notes/","wordcount":51},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-ark/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-release/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"994c3569ea416ee5b0dea253f08af6be","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-release/","summary":"更多参见：https://github.com/sofastack/sofa-ark/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-release/","wordcount":51},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-dashboard/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/release-node/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3c8e6985123810c9692f47cc56b50081","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/release-node/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/release-node/","summary":"更多参见：https://github.com/sofastack/sofa-dashboard/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/release-node/","wordcount":57},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-registry/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d92dddf77bbbd6078f3f96ba2224a53d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/release-notes/","summary":"更多参见：https://github.com/sofastack/sofa-registry/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-registry/release-notes/","wordcount":56},{"author":null,"categories":null,"content":" SOFABoot 提供了模块并行加载以及 Spring Bean 异步初始化能力，用于加快应用启动速度。模块并行加载参考相应文档，下面介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力来提高应用启动速度。\n引入依赖 SOFABoot 在 v2.6.0 开始提供异步初始化 Spring Bean 能力，引入如下 Starter 即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 使用场景 在实际使用 Spring/Spring Boot 开发中，会有一些 Bean 在初始化过程中执行准备操作，如拉取远程配置、初始化数据源等等；在应用启动期间，这类 Bean 会增加 Spring 上下文刷新时间，导致应用启动耗时变长。为了加速应用启动，SOFABoot 通过配置可选项，将 Bean 的初始化方法(init-method) 使用单独线程异步执行，加快 Spring 上下文加载过程，提高应用启动速度。\n使用方法 异步初始化 Bean 的原理是开启单独线程负责执行 Bean 的初始化方法(init-method)，因此在使用过程中，除了引入上述依赖管理，还需要在 Bean 的 xml 定义中配置 sofa:async-init=\u0026amp;quot;true\u0026amp;quot; 属性，用于指定是否异步执行该 Bean 的初始化方法，例如：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- async init test --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBean\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.beans.TimeWasteBean\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot; sofa:async-init=\u0026amp;quot;true\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 配置 SOFABoot 异步初始化能力提供两个属性配置，用于指定负责异步执行 Bean 初始化方法(init-method)的线程池大小： + com.alipay.sofa.boot.asyncInitBeanCoreSize \u0026amp;gt; 线程池基本大小，默认值为 CPU 核数加一 + com.alipay.sofa.boot.asyncInitBeanMaxSize \u0026amp;gt; 线程池中允许的最大线程数大小，默认值为 CPU 核数加一\n配置可以通过 VM -D 参数或者 Spring Boot 配置文件 application.yml 设置。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/speed-up-startup/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ebd933894c7828948b87610d1d0ca020","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/speed-up-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/speed-up-startup/","summary":"SOFABoot 提供了模块并行加载以及 Spring Bean 异步初始化能力，用于加快应用启动速度。模块并行加载参考相应文档，下面介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力来提高应用启","tags":null,"title":"启动加速","type":"projects","url":"/sofastack.tech/projects/sofa-boot/speed-up-startup/","wordcount":519},{"author":null,"categories":null,"content":" 启动过程 Ark 1.0 非内嵌模式 打包方式 在 SOFAArk 1.0 中使用 sofa-ark-maven-plugin 打包\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 启动流程图 Ark 1.0 应用的整体启动流程如下图所述： 启动方式 方式一、IDEA 启动 使用 idea 启动 SpringBoot Application 即可\n方式二、命令行启动 Ark 包是可执行 Jar，可直接使用 java -jar 的方式启动，先使用 mvn clean package 进行打包，打包得到 ${bizName}-${bizVersion}-executable-ark.jar，命令行启动\njava -jar ${bizName}-${bizVersion}-executable-ark.jar 启动原理分析 Springboot 应用，ArkApplicationStartListener 实现了 ApplicationListener 接口，监听 Spring 的启动事件，调用SofaArkBootstrap.launch(args)启动 Ark。\npublic class ArkApplicationStartListener implements ApplicationListener\u0026amp;lt;SpringApplicationEvent\u0026amp;gt; { @Override public void onApplicationEvent(SpringApplicationEvent event) { try { if (isSpringBoot2() \u0026amp;amp;\u0026amp;amp; APPLICATION_STARTING_EVENT.equals(event.getClass().getCanonicalName())) { startUpArk(event); } if (isSpringBoot1() \u0026amp;amp;\u0026amp;amp; APPLICATION_STARTED_EVENT.equals(event.getClass().getCanonicalName())) { startUpArk(event); } } catch (Throwable e) { throw new RuntimeException(\u0026amp;quot;Meet exception when determine whether to start SOFAArk!\u0026amp;quot;, e); } } public void startUpArk(SpringApplicationEvent event) { if (LAUNCH_CLASSLOADER_NAME.equals(this.getClass().getClassLoader().getClass().getName())) { // Ark 启动入口，非 Springboot 应用需要手动调用该方法 SofaArkBootstrap.launch(event.getArgs()); } } public boolean isSpringBoot1() { return SpringBootVersion.getVersion().startsWith(\u0026amp;quot;1\u0026amp;quot;); } public boolean isSpringBoot2() { return SpringBootVersion.getVersion().startsWith(\u0026amp;quot;2\u0026amp;quot;); } } SofaArkBootstrap launch 方法里面启了一个线程执行SofaArkBootstrap.remain方法，remain 里面调ClasspathLauncher.launch方法。\npublic class SofaArkBootstrap { private static final String BIZ_CLASSLOADER = \u0026amp;quot;com.alipay.sofa.ark.container.service.classloader.BizClassLoader\u0026amp;quot;; private static final String MAIN_ENTRY_NAME = \u0026amp;quot;remain\u0026amp;quot;; private static EntryMethod entryMethod; public static void launch(String[] args) { try { if (!isSofaArkStarted()) { entryMethod = new EntryMethod(Thread.currentThread()); IsolatedThreadGroup threadGroup = new IsolatedThreadGroup( entryMethod.getDeclaringClassName()); // 参数中指定当前类的remain方法，LaunchRunner.run 里面会用反射调用remain方法 LaunchRunner launchRunner = new LaunchRunner(SofaArkBootstrap.class.getName(), MAIN_ENTRY_NAME, args); Thread launchThread = new Thread(threadGroup, launchRunner, entryMethod.getMethodName()); launchThread.start(); // 等待前面的线程 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup-process/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c89b63bd70a937cf29bbf165fda00444","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","publishdate":"0001-01-01T00:00:00Z","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","summary":"启动过程 Ark 1.0 非内嵌模式 打包方式 在 SOFAArk 1.0 中使用 sofa-ark-maven-plugin 打包 \u0026lt;build\u0026gt; \u0026lt;plugins\u0026gt; \u0026lt;plugin\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofa-ark-maven-plugin\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${sofa.ark.version}\u0026lt;/version\u0026gt; \u0026lt;executions\u0026gt; \u0026lt;execution\u0026gt; \u0026lt;id\u0026gt;default-cli\u0026lt;/id\u0026gt; \u0026lt;!--goal executed to generate executable-ark-jar --\u0026gt; \u0026lt;goals\u0026gt; \u0026lt;goal\u0026gt;repackage\u0026lt;/goal\u0026gt; \u0026lt;/goals\u0026gt; \u0026lt;configuration\u0026gt; \u0026lt;outputDirectory\u0026gt;./target\u0026lt;/outputDirectory\u0026gt; \u0026lt;!--default none--\u0026gt; \u0026lt;arkClassifier\u0026gt;executable-ark\u0026lt;/arkClassifier\u0026gt; \u0026lt;/configuration\u0026gt; \u0026lt;/execution\u0026gt; \u0026lt;/executions\u0026gt; \u0026lt;/plugin\u0026gt; \u0026lt;/plugins\u0026gt; \u0026lt;/build\u0026gt; 启动流程图 Ark 1.0 应用的整体启动流程如","tags":null,"title":"启动过程","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","wordcount":4023},{"author":null,"categories":null,"content":" 本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sidecar的部署模式，满足用户的各种需求。\n前置要求 Docker Docker Compose 安装步骤 下载最新的 release 包 解压安装文件，并且进入解压后的路径，安装路径包含： 示例应用路径 samples/ /bin 路径下应该能找到 istioctl 客户端可执行文件，istioctl 可用于创建路由规则和策略 配置文件 istion.VERSION 把 Istio 的 bin 路径添加到系统的 PATH。比如，在 MacOS 或者 Linux 系统下执行如下命令：\nexport PATH=$PWD/bin;$PATH 安装helm 创建命名空间 SHELL kubectl create namespace istio-system 使用helm安装istio CRD\nhelm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - 使用helm安装各个组件 SHELL helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - 确认所有 pod 都在运行中：\nkubectl get pod -n istio-system 如果 Istio pilot 容器意外终止，确保运行 istioctl context-create 命令，并且重新执行上一个命令。\n部署应用程序 现在开始部署 Bookinfo 示例程序 为 default 命名空间打上标签 istio-injection=enabled，实现 Sidecar 自动注入\nkubectl label namespace default istio-injection=enabled 使用 kubectl 部署Bookinfo的服务\nkubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml 确认所有的服务和 Pod 都已经正确的定义和启动\nkubectl get services kubectl get pods 卸载 Istio helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - kubectl delete namespace istio-system ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1de4868fa0e9c73d932343847864d7fb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","summary":"本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sid","tags":null,"title":"在 Kubernetes 中快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","wordcount":465},{"author":null,"categories":null,"content":" 本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。\nSOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sidecar的部署模式，满足用户的各种需求。\n前置要求 Kubernetes 安装 Helm 安装步骤 Step 1. 下载最新的 release 包 Step 2. 把 Istio 的 bin 路径添加到系统的 PATH。比如，在 Linux 系统下执行如下命令：\nexport PATH=$PWD/bin;$PATH Step 3. 创建命名空间\nkubectl create namespace istio-system Step 4. 使用helm安装istio CRD\nhelm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - Step 5. 使用helm安装各个组件\nhelm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - Step 6. 确认所有 pod 都在运行中\nkubectl get pod -n istio-system 部署应用程序 现在开始部署 Bookinfo 示例程序。\n为 default 命名空间打上标签 istio-injection=enabled，实现 Sidecar 自动注入：\nkubectl label namespace default istio-injection=enabled 使用 kubectl 部署Bookinfo的服务：\nkubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml 确认所有的服务和 Pod 都已经正确的定义和启动：\nkubectl get services kubectl get pods 卸载 Istio helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - kubectl delete namespace istio-system ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/sofa-mesh-setup/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"940d012b4883e5c91bf777916cd3c6b3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","summary":"本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sid","tags":null,"title":"在 Kubernetes 中快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","wordcount":362},{"author":null,"categories":null,"content":" 基于 Serverless 轻松构建云上应用 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。\n作为云原生技术前进方向之一，Serverless 架构让您进一步提高资源利用率，更专注于业务研发。通过我们的 workshop，您 可以体验到快速创建 Serverless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错等产品新功能。\nWorkshop 操作内容 流程图 应用架构图 效果预览 \nStep 0: 前期准备 应用 clone：https://github.com/sofastack-guides/kc-serverless-demo \n讲师演示 \n快速发布后端 Java 应用 选择快速创建 选择 Java Runtime 上传代码包 balance-mng.jar 入口方法可自动识别 端口：8080 创建完成后，复制保存后端服务的地址 查看后端服务计算实例数量：0 快速发布前端 Node JS 应用 选择创建应用服务 创建应用，选择技术栈为 Node JS 上传代码包 prod-stockmng-v1.zip 运行时选择 nodejs-0.0.1.1-pre 入口方法可自动识别 端口： 3000 环境变量设置 BALANCEMNG_URL 为后端服务的地址 \nStep 1: 查看 Serverless 应用服务 访问 Serverless 应用服务地址 https://sas.shared.cloud.alipay.com/ 使用账号，密码登陆 选择 workspace： workspace0【user00-09】 workspace1【user10-19】 \u0026amp;hellip; workspace9【user90-99】 查看前端应用服务：kubectl frontend demo xx【00-99】 查看后端应用服务：kubectl backend demo xx【00-99】 查看目前后端应用的计算实例数量：0 \nStep 2: 查看 0-1 冷启能力 使用 Chrome 浏览器访问前端服务，域名为：*.kevinwang.cc 查看后端服务的计算实例数量的变化 \n讲师演示2 \n创建版本和流量控制 克隆前端应用，并创建新版本 上传代码包 prod-stockmng-v2.zip 配置权重，路由 1:1 访问 V1 和 V2 版本 通过浏览器查看效果 \nStep 3: 查看版本和流量控制 打开前端应用服务 查看当前应用服务的 V1 和 V2 版本，和路由 通过浏览器访问应用查看流控效果 \nStep 4: 时间触发器 创建时间触发器，定时 2 分钟后触发一次 为前端应用配置触发器 在指定时间，通过执行记录查看触发效果 [](https://github.com/sofastack-guides/kc-serverless-demo#step-2-%E6%9F%A5%E7%9C%8B-0-1-%E5%86%B7%E5%90%AF%E8%83%BD%E5%8A%9B) \nStep 5: Log Shell 和计量 打开 Log Shell 选择相应的应用服务，并输入日志地址/关键词 搜索查看应用服务日志，可全屏 打开计量信息 通过计量监控查看实例运行情况 \n讲师演示3 \nM-N 快速伸缩 打开应用服务 查看当前版本的计算实例限额 1-5 / 计算实例数量：目前为 1 开始压测模拟高并发，并同步查看计算示例数变化 快速从 1 变化为 4，演示结束 Step 6:【可选步骤】快速开始+测试执行 按照前文步骤，尝试自己创建一个新的前端应用 测试执行应用服务 快速发布前端 Node JS应用 选择创建应用服务 创建应用，选择技术栈为 Node JS 上传代码包 prod-stockmng-v1.zip 运行时选择 nodejs-0.0.1.1-pre 入口方法可自动识别 端口： 3000 环境变量设置 BALANCEMNG_URL 为后端服务的地址 测试执行应用服务 选择测试执行 触发查看效果 更多 下载本次 Demo 幻灯片 ","date":-62135596800,"description":"使用该指南您可以体验到快速创建 Serveless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错、按时间触发应用等产品新功能。","dir":"guides/kc-serverless-demo/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f355d1b598fed47b730bd74ad25f3683","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-serverless-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/kc-serverless-demo/","summary":"基于 Serverless 轻松构建云上应用 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。 作为云原生技术前进方向之一，Serverless 架构","tags":null,"title":"基于 Serverless 轻松构建云上应用","type":"guides","url":"/sofastack.tech/guides/kc-serverless-demo/","wordcount":1070},{"author":null,"categories":null,"content":" Ark 包 SOFAArk 定义特殊格式的可执行 Jar 包，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark 包；使用命令 java -jar 即可在 SOFAArk 容器之上启动应用；Ark 包 通常包含 Ark Container 、Ark Plugin 依赖（如果有）、合并部署的 Ark Biz （如果有）以及应用自身的 Ark Biz；详情可参考 Ark 包；\nArk Container Ark 容器，Ark Plugin 和 Ark Biz 运行在 SOFAArk 容器之上；容器具备管理多插件、多应用的功能；容器启动成功后，会解析 Ark Plugin 和 Ark Biz 配置，完成隔离加载并按优先级依次启动之；Ark Container 一般不会被用户直接感知，由打包插件 sofa-ark-maven-plugin 自动打入。详情可参考 SOFAArk 容器启动；\nArk Plugin Ark 插件，SOFAArk 定义特殊格式的 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-plugin-maven-plugin 可以将一个或多个普通的 Java Jar 包打包成一个标准格式的 Ark Plugin； Ark Plugin 会包含一份配置文件，通常包括插件类和资源的导入导出配置、插件启动优先级等；运行时，Ark 容器会使用独立的 PluginClassLoader 加载插件，并根据插件配置构建类加载索引表，从而使插件与插件、插件与应用之间相互隔离；详情可参考 Ark Plugin；\nArk Biz Ark 模块，SOFAArk 定义特殊格式的 Fat Jar ，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark Biz 包；作用有二点，一、在 Ark 包 中，作为工程应用模块及其依赖包的组织单元；二、可以被其他应用当成普通 Jar 包依赖，用于在同一个 SOFAArk 容器启动多个 Ark Biz；多个 Ark Biz 共享 Ark Container 和 Ark Plugin ；详情可参考 Ark Biz；\n合并部署 SOFAArk 允许将多个应用（Biz 包）合并打入到 Ark 包中，当启动 Ark 包时，会启动所有应用；也支持在运行时通过 API 或者配置中心（例如 Zookeeper）动态的部署和卸载应用，这些应用同时运行在同一个 JVM 中，由独立的 BizClassLoader 加载，各应用之间通过 SofaService/SofaReference 实现交互，称之为多应用的合并部署。\n宿主应用 宿主应用是相对合并部署而言，在打包 Ark 包时，至少有一个 Biz 包被打入，如果应用引入了其他 Biz 包，则 Ark 包中会存在多个 Biz 包。当只有一个 Biz 包时，默认将其设置为宿主应用；如果存在多个 Biz 包，则需要配置指定宿主应用。宿主应用相对其他 Biz 包最大的不同，即不允许被卸载。\n简单总结下，在 SOFAArk 框架中，应用(配置、源码、依赖)被打包成 Biz 包组织在一起，但是特殊的依赖（Ark Plugin 和其他应用 Biz 包）不会被打入 Biz 包中，Biz 包是不可执行的 Fat Jar; Ark Plugin 是特殊的二方包，可以将多个二方依赖打包成 Plugin，运行时由独立的 PluginClassLoader 加载，根据打包时配置的导出导入资源、类，构建运行时类加载模型；Ark 包是可执行 Fat Jar，一般由 Ark Container、Ark Plugin(0个或多个)、Ark Biz(至少一个)。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-terminology/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b6d0ed10afe9d04bc00307017ffba7c5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","summary":"Ark 包 SOFAArk 定义特殊格式的可执行 Jar 包，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark 包；使用命令 java -jar 即可在 SOFAArk 容器之上启动应用；Ark 包","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","wordcount":1015},{"author":null,"categories":null,"content":" 业界通用术语 术语 说明 服务（Service） 通过网络提供的、具有特定业务逻辑处理能力的软件功能。 服务提供者（Service Provider） 通过网络提供服务的计算机节点。 服务消费者（Service Consumer） 通过网络调用服务的计算机节点。一个计算机节点可以既作为一些服务的提供者，又作为一些服务的消费者。 服务发现（Service Discovery） 服务消费者获取服务提供者的网络地址的过程。 服务注册中心（Service Registry） 一种提供服务发现功能的软件系统，帮助服务消费者获取服务提供者的网络地址。 数据中心（Data Center） 物理位置、供电、网络具备一定独立性的物理区域，通常作为高可用设计的重要考量粒度。一般可认为：同一数据中心内，网络质量较高、网络传输延时较低、同时遇到灾难的概率较大；不同数据中心间，网络质量较低、网络延时较高、同时遇到灾难的概率较小。 SOFARegistry 约定术语 术语 说明 SOFARegistry 蚂蚁金服开源的一款服务注册中心产品，基于“发布-订阅”模式实现服务发现功能。同时它并不假定总是用于服务发现，也可用于其他更一般的“发布-订阅”场景。 数据（Data） 在服务发现场景下，特指服务提供者的网络地址及其它附加信息。其他场景下，也可以表示任意发布到 SOFARegistry 的信息。 单元（Zone） 单元化架构关键概念，在服务发现场景下，单元是一组发布与订阅的集合，发布及订阅服务时需指定单元名，更多内容可参考异地多活单元化架构解决方案。 发布者（Publisher） 发布数据到 SOFARegistry 的节点。在服务发现场景下，服务提供者就是“服务提供者的网络地址及其它附加信息”的发布者。 订阅者（Subscriber） 从 SOFARegistry 订阅数据的节点。在服务发现场景下，服务消费者就是“服务提供者的网络地址及其它附加信息”的订阅者。 数据标识（DataId） 用来标识数据的字符串。在服务发现场景下，通常由服务接口名、协议、版本号等信息组成，作为服务的标识。 分组标识（GroupId） 用于为数据归类的字符串，可以作为数据标识的命名空间，即只有 DataId、GroupId、InstanceId 都相同的服务，才属于同一服务。 实例 ID（InstanceId） 实例 ID，可以作为数据标识的命名空间，即只有DataId、GroupId、InstanceId都相同的服务，才属于同一服务。 会话服务器（SessionServer） SOFARegistry 内部负责跟客户端建立 TCP 长连接、进行数据交互的一种服务器角色。 数据服务器（DataServer） SOFARegistry 内部负责数据存储的一种服务器角色。 元信息服务器（MetaServer） SOFARegistry 内部基于 Raft 协议，负责集群内一致性协调的一种服务器角色。 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/terminology/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b678a49547c55f2a70e2d94dbce5b4a2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/terminology/","summary":"业界通用术语 术语 说明 服务（Service） 通过网络提供的、具有特定业务逻辑处理能力的软件功能。 服务提供者（Service Provider） 通","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-registry/terminology/","wordcount":1089},{"author":null,"categories":null,"content":" 名词 说明 TraceId TraceId 指的是 SOFATracer 中代表唯一一次请求的 ID，此 ID 一般由集群中第一个处理请求的系统产生，并在分布式调用下通过网络传递到下一个被请求系统。 SpanId SpanId 代表了本次请求在整个调用链路中的位置或者说层次，比如 A 系统在处理一个请求的过程中依次调用了 B，C，D 三个系统，那么这三次调用的的 SpanId 分别是：0.1，0.2，0.3。如果 B 系统继续调用了 E，F 两个系统，那么这两次调用的 SpanId 分别是：0.1.1，0.1.2。 其他相关的名词解释可以参考 OpenTracing 规范。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/explanation/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8ba307b0679e918f7ac68c7efb7e53f7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/explanation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/explanation/","summary":"名词 说明 TraceId TraceId 指的是 SOFATracer 中代表唯一一次请求的 ID，此 ID 一般由集群中第一个处理请求的系统产生，并在分布式调用下通过网络传递到下一个被请求系统。 SpanId SpanId","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/explanation/","wordcount":211},{"author":null,"categories":null,"content":" 消息 内部全部使用 SofaRequest 和 SofaResponse 进行传递。\n如果需要转换为其它协议，那么在真正调用和收到请求的时候，转换为实际要传输的对象。\n可以对 SofaRequest 和 SofaResponse 进行写操作的模块： - Invoker - Filter - ServerHandler - Serialization\n对消息体是只读的模块： - Cluster - Router - LoadBalance\n日志 日志的初始化也是基于扩展机制。虽然是扩展，但是由于日志的加载应该是最早的，所以在 rpc-config.json 里有一个单独的 Key。\n{ // 日志实现，日志早于配置加载，所以不能适应Extension机制 \u0026amp;quot;logger.impl\u0026amp;quot;: \u0026amp;quot;com.alipay.sofa.rpc.log.MiddlewareLoggerImpl\u0026amp;quot; } 配置项 使用者的 RPC 配置 用户的配置，例如端口配置（虽然已经开放对象中设置端口的字段，但是sofa默认是从配置文件里取的），线程池大小配置等。 - 通过 SofaConfigs 加载配置，调用 ExternalConfigLoader 读取外部属性。 - 通过 SofaConfigs 提供的 API 进行获取。 - 所有内部配置的Key都在 SofaOptions 类 - 优先级： System.property \u0026amp;gt; sofa-config.properties(每个应用一个) \u0026amp;gt; rpc-config.properties\nRPC 框架配置 框架自身的配置，例如默认序列化，默认超时等。 未来要一个ClassLoader一个。 - 通过 RpcConfigs 加载配置文件。 - 通过 RpcConfigs 其提供的API进行获取和监听数据变化 - 所有内部配置的Key都在 RpcOptions 类 - 优先级： System.property \u0026amp;gt; custom rpc-config.json（可能存在多个自定义，会排序） \u0026amp;gt; rpc-config-default.json\n常量 全局的基本常量在 RpcConstants 中。例如： 调用方式 sync oneway 协议 bolt/grpc、 序列化 hessian/java/protobuf\n 上下文的key 等等。 如果扩展实现自身的常量，请自行维护。 例如 BOLT 协议的常量。 SERIALIZE_CODE_HESSIAN = 1 PROTOCOL_TR = 13 例如 DSR 配置中心相关的常量。 _WEIGHT、_CONNECTTIMEOUT 这种 配置中心特有的key 地址 地址信息放到 ProviderInfo 类中 ProviderInfo 的值主要分为三部分 字段，一般是一些必须项目。 例如IP，端口，状态等； 静态字段：例如应用名； 动态字段：例如预热权重等； 字段枚举维护在 ProviderInfoAttrs 类中。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/common-model/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b2cc3f7ed134408d6adc25e418e1978b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/common-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/common-model/","summary":"消息 内部全部使用 SofaRequest 和 SofaResponse 进行传递。 如果需要转换为其它协议，那么在真正调用和收到请求的时候，转换为实际要传输的对象。 可以对 SofaRequest 和 SofaResponse 进行写操作的模块","tags":null,"title":"基础模型","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/common-model/","wordcount":684},{"author":null,"categories":null,"content":" 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 - git 工具用法可以查看 git 官方书籍,需要阅读前几章来熟悉。 - git 协作流程可以查看这篇文章 git 协作流程。\nGitHub 贡献代码流程 提交issue 不论您是修复 SOFAJRaft 的 bug 还是新增 SOFAJRaft 的功能，在您提交代码之前，在 SOFAJRaft 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处: - 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作。 - SOFAJRaft 的维护人员会对您提的 bug 或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 - 在达成一致后再开发，并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。\n获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFAJRaft 主干代码到您的代码仓库。\n拉分支 在这之前，可以先看看 SOFAJRaft 的 分支管理策略\nSOFAJRaft 所有修改都在分支上进行，修改完后提交 pull request，在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要： - 下载代码到本地，这一步您可以选择git/https方式。\ngit clone https://github.com/您的账号名/sofa-jraft 拉分支准备修改代码: git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支： git branch -a 如果您想切换回主干，执行下面命令： git checkout -b master 如果您想切换回分支，执行下面命令： git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFAJRaft 通过 Maven 插件来保持代码格式一致。在提交代码前，务必本地执行 mvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试： mvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等。 对于无用的注释，请直接删除。 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档。 修改完代码后，请按照如下格式执行命令提交所有的修改到本地:\ngit commit -am \u0026#39;(feat) 添加xx功能\u0026#39; git commit -am \u0026#39;(fix) 修复xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，接下来就可以与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的，那么这里的 origin 是 push 到您的代码仓库，而不是 SOFAJRaft 的代码仓库。\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFAJRaft 主干代码了。此时您需要进入您在 GitHub 上的对应仓库，按右上角的 pull request 按钮。选择目标分支，一般就是 master，系统会通知 SOFAJRaft 的人员， SOFAJRaft 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFAJRaft 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFAJRaft 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"99034715298f73cd835672b872141609","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","summary":"准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 - git 工具用法可以查看 git 官方书籍,需要阅读前几章来熟悉。 - git 协作流程可以查看这篇文章 git","tags":null,"title":"如何参与 SOFAJRaft 代码贡献","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","wordcount":1276},{"author":null,"categories":null,"content":" 简介 该样例工程演示了如何借助 maven 插件将一个普通的 Java 工程打包成标准格式规范的 Ark Plugin\n背景 现实开发中，常常会遇到依赖包冲突的情况；假设我们开发了一个类库 sample-lib , 业务应用在引入使用时，可能存在跟已有的依赖发生冲突的情况；通常这个时候，我们会希望自己的类库能够和业务其他依赖进行隔离，互不协商双方依赖包版本。 Ark Plugin 正是基于这种需求背景下的实践产物； Ark Plugin 运行在 Ark Container 之上，由容器负责加载启动，任何一个 Ark Plugin 由独立的 ClassLoader 加载，从而做到相互隔离。Ark Plugin 存在四个概念：\n 导入类：插件启动时，优先委托给导出该类的插件负责加载，如果加载不到，才会尝试从本插件内部加载；\n 导出类：其他插件如果导入了该类，优先从本插件加载；\n 导入资源：插件在查找资源时，优先委托给导出该资源的插件负责加载，如果加载不到，才会尝试从本插件内部加载；\n 导出资源：其他插件如果导入了该资源，优先从本插件加载；\n 详细请参考插件规范\n 工具 官方提供了 Maven 插件 - sofa-ark-plugin-maven-plugin ，只需要简单的配置项，即可将普通的 Java 工程打包成标准格式规范的 Ark Plugin ，插件坐标为:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 详细请参考插件配置文档\n 入门 基于该用例工程，我们一步步描述如何构建一个 Ark Plugin\n创建标准 Maven 工程 该用例工程是一个标准的 Maven 工程，一共包含两个模块： * common 模块：包含了插件导出类\n plugin 模块：包含了 com.alipay.sofa.ark.spi.service.PluginActivator 接口实现类和一个插件服务类，插件打包工具 sofa-ark-plugin-maven-plugin 即配置在该模块的 pom.xml 中； 配置打包插件 在 plugin 模块的 pom.xml 中按如下配置打包插件：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${project.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--can only configure no more than one activator--\u0026amp;gt; \u0026amp;lt;activator\u0026amp;gt;com.alipay.sofa.ark.sample.activator.SamplePluginActivator\u0026amp;lt;/activator\u0026amp;gt; \u0026amp;lt;!-- configure exported class --\u0026amp;gt; \u0026amp;lt;exported\u0026amp;gt; \u0026amp;lt;!-- configure package-level exported class--\u0026amp;gt; \u0026amp;lt;packages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa.ark.sample.common\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/packages\u0026amp;gt; \u0026amp;lt;!-- configure class-level exported class --\u0026amp;gt; \u0026amp;lt;classes\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.ark.sample.facade.SamplePluginService\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/classes\u0026amp;gt; \u0026amp;lt;/exported\u0026amp;gt; \u0026amp;lt;!--specify destination where ark-plugin will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;../target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 在用例工程中，我们只配置了一部分配置项，这已经足够生成一个可用的 Ark Plugin，各配置项含义如下： * activator: Ark 容器启动插件的入口类，最多只能配置一个；通常来说，在插件的 activator 会执行一些初始化操作，比如发布插件服务；在本样例工程中，即发布了插件服务。\n 导出包：包级别的导出类配置，插件中所有以导出包名为前缀的类，包括插件的三方依赖包，都会被导出；\n 导出类：精确类名的导出类配置，导出具体的类；\n outputDirectory： mvn package 打包后，输出的 ark plugin 文件存放目录；\n 需要指出的是，在用例工程中，我们只导出了工程创建的类；实际在使用时，也可以把工程依赖的三方包也导出去。\n打包、安装、发布、引入 和普通的工程操作类似，使用 mvn package , mvn install , mvn deploy 即可完成插件包的安装和发布；需要注意的是，默认发布的 Ark Plugin 其 Maven 坐标会增加 classifier=ark-plugin ；例如在该样例工程中，如果需要使用该 ark plugin，必须如下配置依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin-demo/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d8125843ced13352dd228299f222c74d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","summary":"简介 该样例工程演示了如何借助 maven 插件将一个普通的 Java 工程打包成标准格式规范的 Ark Plugin 背景 现实开发中，常常会遇到依赖包冲突的情况；假设我们开发了一个类","tags":null,"title":"如何打包 Ark Plugin","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","wordcount":1171},{"author":null,"categories":null,"content":" 简介 该样例工程演示了如何借助 Maven 插件将一个 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包；\n准备 因该样例工程依赖 sample-ark-plugin，因此需要提前在本地安装该 Ark Plugin\n工具 官方提供了 Maven 插件 - sofa-ark-maven-plugin ，只需要简单的配置项，即可将 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包，插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 详细请参考插件使用文档\n 入门 基于该样例工程，我们一步步描述如何将一个 Spring Boot Web 工程打包成可运行 Ark 包\n创建 SpringBoot Web 工程 在官网 https://start.spring.io/ 下载一个标准的 Spring Boot Web 工程\n引入 sample-ark-plugin 在工程主 pom.xml 中如下配置，添加另一个样例工程打包生成的 Ark Plugin 依赖，参考文档\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置打包插件 在工程主 pom.xml 中如下配置 Maven 插件 sofa-ark-maven-plugin :\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- 让模块只能使用基座里模块声明过的依赖，详细查看 https://www.sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/ --\u0026amp;gt; \u0026amp;lt;declaredMode\u0026amp;gt;true\u0026amp;lt;/declaredMode\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 在该样例工程中，我们只配置了一部分配置项，这已经足够生成一个可用的可执行 Ark 包，各配置项含义如下： * outputDirectory: mvn package 打包后，输出的 Ark 包文件存放目录；\n arkClassifier: 指定发布的 Ark 包其 Maven 坐标包含的 classifier 值，默认为空； 关于 arkClassifier 配置项需要特别注意下，默认值为空；如果不指定 classifier ，上传到仓库的 Jar 包其实是一个可运行的 Ark 包；如果需要和普通的打包加以区分，需要配置该项值。\n打包、安装、发布 和普通的工程操作类似，使用 mvn package , mvn install , mvn deploy 即可完成插件包的安装和发布；\n运行 我们提供了两种方式在 Ark 容器上启动工程应用，通过命令行启动或者在 IDE 启动；在 IDE 启动时，需要额外添加依赖；使用命令行启动非常简便，直接使用 java -jar 即可启动应用；下面我们说下如何在 IDE 启动 Ark 应用；\n Spring Boot 工程：Spring Boot 工程需要添加如下依赖即可： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 普通 Java 工程： 相较于 SpringBoot 工程，普通的 Java 工程需要添加另一个依赖： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-support-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 除此之外，还需要在工程 main 方法最开始处，执行容器启动，如下：\npublic class Application{ public static void main(String[] args) { SofaArkBootstrap.launch(args); ... } } 运行测试用例 SOFAArk 提供了 org.junit.runner.Runner 的两个实现 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-demo/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2c97c409788f41051c79836d277997be","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","summary":"简介 该样例工程演示了如何借助 Maven 插件将一个 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包； 准备 因该样例工程依赖 sample-ark-plugin，因","tags":null,"title":"如何打包 Ark 包","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","wordcount":1293},{"author":null,"categories":null,"content":" 如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。\n 直接下载代码，然后执行如下命令：\ncd sofa-rpc mvn clean install 注意：不能在子目录（即子模块）下进行编译。因为 SOFARPC 模块太多，如果每个子模块都会install 和 deploy，仓库内会有较多无用记录。 所以在设计 SOFARPC 工程结构的时候，我们决定各个子模块组件是不需要 install 和 deploy 到仓库里的，我们只会install 和 deploy 一个sofa-rpc-all(all) 模块。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/how-to-build/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"52ad3debb35be8743c97bb4b6b77f22b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/how-to-build/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/how-to-build/","summary":"如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后执行如下命令： cd sofa-rpc mvn clean install 注意：不能在子目录（即子模块）下进行编译。因为 SOFARPC 模块太多","tags":null,"title":"如何编译 SOFARPC 工程","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/how-to-build/","wordcount":180},{"author":null,"categories":null,"content":" 在非 Kubernetes 环境下使用 Istio 需要达成以下的关键任务：\n 为 Istio 控制平面配置 Istio API server，也可以通过 memostore 的方式启动 Pilot 用作演示用途。 给所有微服务实例手工添加 SOFA MOSN，并以 Sidecar 模式启动。 确保请求都通过 SOFA MOSN 进行路由。 设定控制平面 Istio 控制平面由四个主要的服务组成：Pilot、Mixter、Citadel 以及 API server。\nAPI server Istio\u0026amp;rsquo;s API server (基于 kubernetes API server) 提供了配置管理和基于角色的访问控制。API server 需要 etcd 集群作为底层的持久化存储。\n本地安装 使用如下的 docker compose file 安装一个用于 POC 目的的 API server：\nversion: \u0026#39;2\u0026#39; services: etcd: image: quay.io/coreos/etcd:latest networks: default: aliases: - etcd ports: - \u0026amp;quot;4001:4001\u0026amp;quot; - \u0026amp;quot;2380:2380\u0026amp;quot; - \u0026amp;quot;2379:2379\u0026amp;quot; environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;/usr/local/bin/etcd\u0026amp;quot;, \u0026amp;quot;-advertise-client-urls=http://0.0.0.0:2379\u0026amp;quot;, \u0026amp;quot;-listen-client-urls=http://0.0.0.0:2379\u0026amp;quot; ] istio-apiserver: image: gcr.io/google_containers/kube-apiserver-amd64:v1.7.3 networks: default: aliases: - apiserver ports: - \u0026amp;quot;8080:8080\u0026amp;quot; privileged: true environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;kube-apiserver\u0026amp;quot;, \u0026amp;quot;--etcd-servers\u0026amp;quot;, \u0026amp;quot;http://etcd:2379\u0026amp;quot;, \u0026amp;quot;--service-cluster-ip-range\u0026amp;quot;, \u0026amp;quot;10.99.0.0/16\u0026amp;quot;, \u0026amp;quot;--insecure-port\u0026amp;quot;, \u0026amp;quot;8080\u0026amp;quot;, \u0026amp;quot;-v\u0026amp;quot;, \u0026amp;quot;2\u0026amp;quot;, \u0026amp;quot;--insecure-bind-address\u0026amp;quot;, \u0026amp;quot;0.0.0.0\u0026amp;quot; ] 其他控制平面组件 目前 SOFA MOSN 还没有集成 Pilot 之外的其他组件，因此我们暂时无需安装 Mixer、Citadel 等组件。\n为微服务实例添加 SOFA MOSN Sidecar 微服务应用的每个实例都必须有个伴生的 SOFA MOSN 实例。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-installation/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4c0bd56673dc8aebef9011a22496392d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","summary":"在非 Kubernetes 环境下使用 Istio 需要达成以下的关键任务： 为 Istio 控制平面配置 Istio API server，也可以通过 memostore 的方式启动 Pilot 用作演示用途。 给所有微服务实例手工添加 SOFA","tags":null,"title":"安装指南","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","wordcount":372},{"author":null,"categories":null,"content":"提供可以允许配置的所有参数。 * 发布订阅配置 * 预热转发配置 * 自动故障剔除配置\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b1a8a8c426beab292165716f1dff1ae4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration/","summary":"提供可以允许配置的所有参数。 * 发布订阅配置 * 预热转发配置 * 自动故障剔除配置","tags":null,"title":"完整配置参数","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration/","wordcount":37},{"author":null,"categories":null,"content":" 客户端 API 使用说明 SOFALookout 客户端设计上保持了 API 与实现解耦。如果我们只需要基于 SOFALookout API 进行埋点，那么只需要依赖 API 包即可。在没有依赖具体实现模块依赖时（比如 client 依赖 或 SOFABoot（Spring Boot）Start 依赖），API 包会自动使用 NoopRegistry，使得所有埋点的地方都已空实现替代。\n1.API 依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.关于 ID Lookout metrics 相比传统的 metrics 库单一维度的信息描述，提供了支持多维度描述的 tags 能力。 Lookout metrics 的唯一标识 Id 类，由 name 和 tags 构成。\nId basicId = registry.createId(\u0026amp;quot;rpc.provider.service.stats\u0026amp;quot;); id = basicId.withTag(\u0026amp;quot;service\u0026amp;quot;, \u0026amp;quot;com.alipay.demo.demoService\u0026amp;quot;) .withTag(\u0026amp;quot;method\u0026amp;quot;, \u0026amp;quot;sayHi\u0026amp;quot;) .withTag(\u0026amp;quot;protocol\u0026amp;quot;, \u0026amp;quot;tr\u0026amp;quot;) .withTag(\u0026amp;quot;alias\u0026amp;quot;, \u0026amp;quot;group1\u0026amp;quot;); 上面是 Id 的简单示例了，如何创建 Id，如何打 tag，（每打一次 tag，都会生成并返回一个新的 Id 对象引用）切记！使用返回新的 Id 对象了哦。\n 不要主动缓存 Id 或具体的 Metric 对象,Lookout 的 Registry 已经登记记录了。相等的 Id （ name 和 tags 一样）会复用已有的Id 对应 Metric 对象。 2.1 Priority tag (不是必须) PRIORITY 枚举级别: HIGH, NORMAL, LOW;\nid.withTag(LookoutConstants.LOW_PRIORITY_TAG); 如果不打该 Tag (建议)，默认是 NORMAL 级别。级别代表了采集间隔周期（HIGH：2s, NORMAL: 30s, LOW: 1min）\n2.2 关于 tags 通用的 tags，比如：本机 ip，机房等详细会统一附上，不需要单独指定。 普通 Java 项目直接 lookout-client 时，tags 需要自己指定，特别记住：appName 别忘啦！tag:app=xx key 必须小写，尽量是字母，数字，下划线； （尤其是运行期的 Counter, Timer, DistributeSummary 这些 metrics）某个类型的 tag 的 values 尽量是稳定不变有限集合，而且 tags 尽量少，防止 metrics 数量超过最大限制！ 比如：rpc 场合 service, method 两个 tag 对应的值是有限较小的； 反例是每次 rpc 调用都有是个独立的 tag-value。 因此，总体原则自定义打 tags 时要尽量少，对应 values 的集合数量尽量小； 专门用途的 TAG 名称: \u0026amp;ldquo;priority\u0026amp;rdquo;: 表示优先级。 系统保留的 tag key 统配格式_*_,以下划线开始，以下划线结束（比如: \u0026amp;ldquo;type\u0026amp;rdquo; ）。 请不要使用这种格式的 key，可能会被系统覆盖或丢弃 3.可接入的统计( Metric )类型API Counter 「计数器」 场景：方法调用次数； 主动汇报的数据包括： count, rate (也就是 qps)； 使用方式 Counter counter=registry.counter(id); counter.inc(); Timer 「耗时统计器」 场景:统计任务，方法耗时，支持分桶统计 主动汇报的数据包括：elapPerExec (单次执行耗时), total 耗时，Max 耗时,（上报单位：秒）； 使用方式 Timer timer=registry.timer(id); timer.record(2, TimeUnit.SECONDS); DistributionSummary 「值分布情况统计器」 场景：比如 io 流量，支持分桶统计 主动汇报的数据包括: count, total(size), max(size)； 使用方式: DistributionSummary distributionSummary=registry.distributionSummary(id); distributionSummary.record(1024); Gauge 「即时数据观察」 场景：比如线程池，内存值等即时值； 主动汇报的数据包括: value； 往注册表中登记新 gauge 时，ID 值相等，注册表继续使用已有的(忽略新的)； 注意，推荐 gauge 观察的对象尽量是单例的（复用），并且建议在运行时一直活着（而不是作为一个临时的统计）！，如果不是单例或者只存活一段时间，那么一定要从 Registry 中 remove 掉，否则影响 GC（主要是它持有的外部对象引用无法释放，浪费空间）!!\n 使用方式: registry.gauge(id,new Gauge\u0026amp;lt;Double\u0026amp;gt;() { @Override public Double value() { return 0.1; } }); MixinMetric 「上述基本统计 metrics 的混合管理体」 MixinMetric 是 Lookout 特有的，表示多个基本 metrics 的混合体。引入该 Mixin 目的是优化对「同一度量目标」（即测量目标一致，tags 一致）的多测量指标传输和存储效率，比如：同一线程池的各种指标(线程总数，活跃总数，等待队列大小\u0026amp;hellip;)。\n 使用方式（比如，对一次服务调用，加入多个测量指标：调用耗时，输入字节，调用次数，输出字节等等） //1. getOrAdd MixinMetric MixinMetric rpcServiceMetric=registry.minxinMetric(id); //2. getOrAdd basic component metric to use Timer rpcTimer = rpcServiceMetric.timer(\u0026amp;quot;perf\u0026amp;quot;); DistributionSummary …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-api/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"76574f2435a3565fe1fc50831ff9ab0c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-api/","summary":"客户端 API 使用说明 SOFALookout 客户端设计上保持了 API 与实现解耦。如果我们只需要基于 SOFALookout API 进行埋点，那么只需要依赖 API 包即可。在没有依赖具体实现模块依赖时（比如","tags":null,"title":"客户端 API 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-api/","wordcount":1562},{"author":null,"categories":null,"content":" Registry 的使用 不同的 Registry 的集成提供了不同的访问 Metrics 的方式。\n1. LookoutRegistry 提供按照一定时间窗口统计 metrics 的能力。它又分为“主动推”和“被动拉”两种模式，暂时被动拉取模式处于关闭状态。\n（1）主动推模式\n可以通过【客户端配置】指定远程 Agent 的IP地址，即开始上报检查，和定时上报数据。 （2）被动拉模式\n可以通过【客户端配置】启动该模式，则在 19399 端口提供 HTTP 服务。更多交互细节请参考（待补充） 2. 对接到 Prometheus SOFALookout 的数据可以对接到 Prometheus 上面。为了将数据对接到 Prometheus 上面，首先需要在工程中加入依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-reg-prometheus\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 添加好依赖之后，启动应用，既可以访问 http://localhost:9494 来看到数据，其中 9494 为默认的端口，可以通过在 application.properties 里面配置 com.alipay.sofa.lookout.prometheus-exporter-server-port 来改变端口。\n有了访问数据的 URL 之后，可以编辑一个 prometheus.yml 来抓取该项目信息，假设本机 IP 地址为 10.15.232.20，那么可以配置如下的 prometheus.yml：\nscrape_configs: - job_name: \u0026#39;lookout-client\u0026#39; scrape_interval: 5s static_configs: - targets: [\u0026#39;10.15.232.20:9494\u0026#39;] 有了上面的配置文件之后，可以再到本地通过 Docker 来启动 Prometheus：\ndocker run -d -p 9090:9090 -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml --name prom prom/prometheus:master 然后通过浏览器访问: http://localhost:9090，再通过 PromQL 查询即可查询到对应的 Metrics。\nSOFALookout 中也提供了一个对接 Prometheus 的样例，大家可以前往自行查看。\n3. 对接 SpringBoot actuator 除了 Prometheus 之外，SOFALookout 可以与 SpringBoot 1.x 的 Actuator 的相集成，只需依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后启动后访问 http://localhost:8080/metrics 既可以看到通过 SOFALookout API 埋点的数据。\nSOFALookout 也提供了集成的样例工程，大家可以前往自行查看。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-registry/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3c51ba6519cee542b459a170dabcf32b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-registry/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-registry/","summary":"Registry 的使用 不同的 Registry 的集成提供了不同的访问 Metrics 的方式。 1. LookoutRegistry 提供按照一定时间窗口统计 metrics 的能力。它又分为“主动推”和“被动拉”两种模式，暂时被动拉取模","tags":null,"title":"客户端 Registry 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-registry/","wordcount":575},{"author":null,"categories":null,"content":" 1. 创建 Maven 工程 服务端部署完毕后，我们可以新建一个 Maven 工程使用 SOFARegistry 提供的服务。首先新建一个 Maven 工程，然后引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. 发布数据 // 构建客户端实例 RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // 构造发布者注册表 String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // 将注册表注册进客户端并发布数据 registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); 使用 SOFARegistry 发布数据一共包含三个步骤：\n 构建客户端实例; 构造发布者注册表; 将注册表注册进客户端并发布数据。 2.1 构建客户端实例 构建客户端实例的关键是创建 RegistryClientConfig 对象，创建 RegistryClientConfig 对象时需要指定 RegistryEndpoint 和 RegistryEndpointPort:\n RegistryEndpoint：注册中心任一 Session 节点地址； RegistryEndpointPort: Session 节点配置的 session.server.httpServerPort 端口值。 2.2 构造发布者注册表 构造发布注册表只需要创建 PublisherRegistration 并指定 dataId，dataId 是发布服务的唯一标识。\n2.3 发布数据 调用 RegistryClient 的 register 方法可以进行数据发布，该方法需要两个参数，第一个参数是发布注册表，指定了服务的 dataId，第二个参数是数据值，一般是一个字符串类型。\n3. 订阅数据 // 构建客户端实例 RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, global String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setScopeEnum(ScopeEnum.global); // 将注册表注册进客户端并订阅数据，订阅到的数据会以回调的方式通知 SubscriberDataObserver registryClient.register(registration); 使用 SOFARegistry 订阅数据一共包含四个步骤：\n 构建客户端实例; 创建 SubscriberDataObserver； 构造订阅者注册表； 将注册表注册进客户端并订阅数据。 其中创建客户端实例方式与上文发布数据时创建客户端实例的方法一致。\n3.1 创建 SubscriberDataObserver SubscriberDataObserver 是一个回调接口，该接口定义了 handleData 方法，该方法包含两个参数，分别是 dataId 及最终数据，当客户端收到服务端订阅的数据时会调用该方法。在 SOFARegistry 中，服务端返回数据用 UserData 表示，该类包含以下两个方法：\npublic interface UserData { Map\u0026amp;lt;String, List\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; getZoneData(); String getLocalZone(); } getLocalZone: 返回当前zone； getZoneData: 返回以 zone 为 key，每个 zone 的数据为 value 的数据。 3.2 构造订阅者注册表 构造订阅者注册表需要创建 SubscriberRegistration 对象，创建该对象需要指定 dataId 及 SubscriberDataObserver。\n3.3 订阅数据 调用 RegistryClient 的 register 方法可以进行数据订阅，该方法包含一个参数，只需传入 SubscriberRegistration 对象即可。\n如果先运行发布数据的程序，然后再运行订阅数据的程序，那么我们将在控制端看到如下输出：\nreceive data success, dataId: …","date":-62135596800,"description":"","dir":"projects/sofa-registry/client-quick-start/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"66e300d44b2f2a903d976bf83eb7c16e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/client-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/client-quick-start/","summary":"1. 创建 Maven 工程 服务端部署完毕后，我们可以新建一个 Maven 工程使用 SOFARegistry 提供的服务。首先新建一个 Maven 工程，然后引入如下依赖： \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. 发布数据 // 构建客户端","tags":null,"title":"客户端使用","type":"projects","url":"/sofastack.tech/projects/sofa-registry/client-quick-start/","wordcount":897},{"author":null,"categories":null,"content":" 该项目演示了如何在 SOFABoot 中使用 SOFALookout 并且对接到 Spring Boot 的 Actuator 中。如果想要对接到 Prometheus 上或者其他的 Registry 中，请参考 Registry 一节。\n新建 SpringBoot（或 SofaBoot ）项目 新建一个 Spring Boot 的应用（如果是 SOFABoot 工程按照 SOFABoot 文档 - 依赖管理中的方式引入 SOFABoot 即可）。\n引入 Lookout 的 Starter 依赖 在 pom.xml 中引入以下依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 如果 Spring Boot 项目需指定版本。\n新建一个 Metrics 指标 在完成依赖的引入之后，然后可以在 Spring Boot 中的启动类中，加入如下的方法：\n@Autowired private Registry registry; @PostConstruct public void init() { Counter counter = registry.counter(registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;).withTag(\u0026amp;quot;instant\u0026amp;quot;, NetworkUtil.getLocalAddress().getHostName())); counter.inc(); } 上面的代码中直接通过 @Autowired 注入了一个 Registry 的字段，通过这个 Registry 的字段，我们就可以创建对应的 Counter，然后通过修改这个 Counter 的数据来生成 SOFALookout 的 Metrics 的指标。\n添加配置项 在 SOFABoot 项目中，需要增加一个应用名的配置项：spring.application.name=xxx。\n与 Spring Boot Actuator 对接 新增了一个指标之后，我们可以选择对接到 Spring Boot Actuator 上，要对接到 Spring Boot Actuator 上面，需要添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 添加如上的依赖之后，我们在本地启动应用，访问 http://localhost:8080/metrics，就可以看到前面添加的指标，如下：\n\u0026amp;quot;http_requests_total.instant-MacBook-Pro-4.local\u0026amp;quot;: 1, 以上的 QuickStart 的代码在: lookout-client-samples-boot，大家可以下载作为参考。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-boot/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"27e057f8a8a4ac97f42ea66ca6a17fdd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","summary":"该项目演示了如何在 SOFABoot 中使用 SOFALookout 并且对接到 Spring Boot 的 Actuator 中。如果想要对接到 Prometheus 上或者其他的 Registry 中，请参考 Registry 一节。 新建 SpringBoot（或 SofaBoot ）项目 新建一","tags":null,"title":"客户端快速开始 - SOFABoot 项目","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","wordcount":490},{"author":null,"categories":null,"content":" 普通 Java 项目 在应用中加入 client 的 Maven 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; lookout-client 默认依赖了 lookout-reg-server 模块（支持向 lookout server 上报 metrics 数据），如果希望使用其他类型注册表(比如 lookout-reg-prometheus)，那么再加上对应依赖即可。\n开始使用 SOFALookout 的 Client 之前，首先需要构建一个全局的客户端实例（ com.alipay.lookout.client.DefaultLookoutClient ）\nLookoutConfig lookoutConfig = new LookoutConfig(); DefaultLookoutClient client = new DefaultLookoutClient(\u0026amp;quot;appName\u0026amp;quot;); //选择构建需要使用的 Registry(如果多个注册表类型，建议使用同一 lookoutConfig 实例，便于集中管理) LookoutRegistry lookoutRegistry = new LookoutRegistry(lookoutConfig); //客户端可以后置添加 registry 实例(至少要加一个) client.addRegistry(lookoutRegistry); //(可选)对已加入或后续加入的客户端的 registry 实例，统一注册扩展模块的 metrics client.registerExtendedMetrics(); 然后通过客户端拿取 Registry 实例，进行使用：\n//该注册表是个“组合”型的注册表 Registry registry = client.getRegistry(); //demo Id id = registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;); Counter counter = registry.counter(id); counter.inc(); 客户端的使用，可以详细参考样例工程。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-java/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5dc476aa21ece4789859f1af598d4445","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","summary":"普通 Java 项目 在应用中加入 client 的 Maven 依赖 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa.lookout\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;lookout-client\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${lookout.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; lookout-client 默认依赖了 lookout-reg-server 模块（支持向 lookout server 上报 metrics 数据），如果希望使用其他类型注册表(比如 lookout-reg","tags":null,"title":"客户端快速开始 - 普通 Java 项目","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","wordcount":311},{"author":null,"categories":null,"content":"客户端模块是一个较复杂的模块，这里包含了集群管理、路由、地址管理器、连接管理器、负载均衡器，还与代理、注册中心等模块交互。\n参见：\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/client-invoke-flow/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"310d99d64b808a3b526563e92c699952","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","summary":"客户端模块是一个较复杂的模块，这里包含了集群管理、路由、地址管理器、连接管理器、负载均衡器，还与代理、注册中心等模块交互。 参见：","tags":null,"title":"客户端调用流程","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","wordcount":64},{"author":null,"categories":null,"content":" 客户端配置项设置示例 lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026amp;quot;127.0.0.1\u0026amp;quot;); 客户端配置项说明 配置项 对应 SpringBoot 配置项 默认配置值 说明 lookout.enable com.alipay.sofa.lookout.enable true 功能开关，默认是 true。如果改为 false，那么所有 metrics 就几乎没有内存与计算消耗(空对象与空方法) lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 metrics 最大数目限制，超过会自动忽略 lookout.prometheus.exporter.server.port com.alipay.sofa.lookout.prometheus-exporter-server-port 9494 prometheus 抓取的端口 lookout.exporter.enable com.alipay.sofa.lookout.exporter-enable false 是否开启支持被动采集的服务 lookout.agent.host.address com.alipay.sofa.lookout.agent-host-address - 主动上报 Agent 服务器的注解地址，支持多个地址以逗号分隔 客户端日志配置说明 系统属性配置项 对应 SpringBoot 配置项 默认配置值 说明 -Dlogging.level.com.alipay.lookout=? logging.level.com.alipay.lookout warn lookout 客户端的日志级别，debug 可以看见汇报数据的详情 -Dlogging.path=? logging.path 当前用户目录 SpringBoot V1的日志目录调整，包括 \u0026amp;ldquo;lookout/\u0026amp;rdquo; 日志子目录 客户端配置自定义(适用于 SpringBoot 技术栈模式) 使用配置定制扩展: MetricConfigCustomizerConfig\n@Configuration public class MetricConfigCustomizerConfig { @Bean public MetricConfigCustomizer metricConfigCustomizer() { return new MetricConfigCustomizer() { @Override public void customize(MetricConfig metricConfig) { metricConfig.addProperty(\u0026amp;quot;testaa\u0026amp;quot;, \u0026amp;quot;testbb\u0026amp;quot;); } }; } } ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-configuration/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5fd84950d4d565d3fb20781337792bf1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/client-configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/client-configuration/","summary":"客户端配置项设置示例 lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026quot;127.0.0.1\u0026quot;); 客户端配置项说明 配置项 对应 SpringBoot 配置项 默认配置值 说明 lookout.enable com.alipay.sofa.lookout.enable true 功能开关，默认是 true。如果改为 false，那么所有 metrics 就几乎没","tags":null,"title":"客户端配置","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/client-configuration/","wordcount":298},{"author":null,"categories":null,"content":"包含单机故障剔除和 Hystrix 熔断。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e567dc5e291867e92c8dd1c4f953b768","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault/","summary":"包含单机故障剔除和 Hystrix 熔断。","tags":null,"title":"容灾恢复","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault/","wordcount":13},{"author":null,"categories":null,"content":" 本文档中提供了 MOSN 的示例工程。\n使用 MOSN 作为 HTTP 代理 请参考 MOSN 转发 HTTP 的示例工程 http-sample。\n使用 MOSN 作为 SOFARPC 代理 请参考 MOSN 转发 SOFARPC 的示例工程 sofarpc-sample。\n使用 MOSN 作为TCP 代理 请参考 MOSN 作为 TCP Proxy 的示例工程 tcpproxy-sample 。\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-samples/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"600c182fdee786a59e14899ba0fce8a1","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-run-samples/","summary":"本文档中提供了 MOSN 的示例工程。 使用 MOSN 作为 HTTP 代理 请参考 MOSN 转发 HTTP 的示例工程 http-sample。 使用 MOSN 作为 SOFARPC 代理 请参考 MOSN 转发 SOFARPC 的示例工程 sofa","tags":null,"title":"工程示例","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-run-samples/","wordcount":106},{"author":null,"categories":null,"content":" 源码工程中提供了一些样例工程，辅助说明项目的使用。样例工程的 readme 有使用补充说明，另外需要将这些 sample 工程单独的导入 IDE。\n客户端样例工程 lookout-client-samples-java 该样例工程展示了，在普通 Java 项目中,如何以代码形式使用和配置客户端。\n lookout-client-samples-boot 该样例工程展示了，在 SpringBoot(或SofaBoot) 项目中,如何使用和配置客户端。\n lookout-client-samples-prometheus 该样例工程展示了，在 SpringBoot(或SofaBoot) 项目中,如何使用和配置客户端使用 prometheus。\n lookout-samples-prom-push 该样例工程展示了，在 Java 项目中,使用 prometheus 客户端并以push方式（PushGateway）上报数据。\n服务器端样例工程 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-samples/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a8a0fcd3f99ce2fb46e4d543e30797c9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-samples/","summary":"源码工程中提供了一些样例工程，辅助说明项目的使用。样例工程的 readme 有使用补充说明，另外需要将这些 sample 工程单独的导入 IDE。 客户端样例工程 lookout-client-samples-java 该样例工","tags":null,"title":"工程示例","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-samples/","wordcount":261},{"author":null,"categories":null,"content":" Q：报错误 NoSuchMethodError 一般情况下该类错误由依赖冲突导致。已知的依赖冲突列举如下，遇到时选择性排除它们。\n日志冲突 commons-logging 冲突 \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-logging\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; logback-classic 冲突 在冲突位置将 logback-classic 排除，如 spring-boot-starter-logging 和 spring-test 为存在冲突的应用依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.3.4.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; snakeyaml 冲突 java.lang.NoSuchMethodError: org.yaml.snakeyaml.Yaml.\u0026amp;lt;init\u0026amp;gt;(Lorg/yaml/snakeyaml/constructor/BaseConstructor;)V spring-boot-starter-test 与 org.testng 中引用的 org.yaml 存在冲突。这里以排除 spring-boot-starter-test 中的 org.yaml 为例（也可在 org.testng 等冲突位置排除）\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.yaml\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;snakeyaml\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Q：报错 NoClassDefFoundError 一般情况下依赖缺失或者依赖冲突会导致该类问题。\nMockito 报错找不到类 SOFABoot 使用 Mockito 时，如果已经存在 spring-boot-starter-test 则无需重复引入 Mockito。\nQ：报错 No bean dataAccessConfigManager available ACTS 测试脚本指定的 Application 启动类中缺少 acts-core.xml，如图添加即可。\nQ：No runnable methods 一般是由于选择 Junit 运行 ACTS 测试脚本导致的，ACTS 测试脚本可使用 TestNG 方式运行。\nQ：生成模版异常 有较多情况会导致这一现象，常见的是新编写的类或者对类进行变更后，没有进行 mvn 编译。先执行 mvn clean install -Dmaven.test.skip=true，再进行模版生成。\nQ：编辑器设置入参错误 使用 ACTS IDE 操作入参时，出现无法选中或者设置数值出错等情况，一般是生成测试脚本操作有误，没有生成入参模版而直接生成测试脚本，导致初始生成的 YAML 中入参不正确。\n 解法一：删除测试脚本对应的 YAML 文件，然后打开 ACTS IDE 并右键入参设置 -\u0026amp;gt; 模版选择，编辑后保存则 YAML 文件会自动重建。 解法二：删除生成的测试脚本和 YAML 文件，首先生成入参的模版，再重新生成测试脚本即可，YAML 中会默认带入参设置； Q：报错 argument type mismatch 该问题一般是被测接口有多个同名重载方法导致的，从而引发反射时参数不匹配错误。\n解决方法 可以在脚本中重写 ACTS 测试基类的 findMethod 方法，返回真正被测的方法对象。下面的方法也适用于获取被测方法失败的情况。\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { Method method =null; try { method = VirtualAssetQueryService.class.getDeclaredMethod (\u0026amp;quot;query\u0026amp;quot;, QueryVirtualAssetListParam.class); } catch (NoSuchMethodException e) { e.printStackTrace(); } catch (SecurityException e) { e.printStackTrace(); } actsRuntimeContext.setTestedMethod(method); } 使用 ACTS IDE 编辑类的属性后保存取值失效 ACTS IDE 默认类是标准的 JavaBean 形式，会调用属性的 set 方法为其赋值，如果不存在 set 方法则无法保存取值。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/faq/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5f89d1f5695cbe6b669a8738741529bd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/faq/","summary":"Q：报错误 NoSuchMethodError 一般情况下该类错误由依赖冲突导致。已知的依赖冲突列举如下，遇到时选择性排除它们。 日志冲突 commons-logging 冲突 \u0026lt;exclusion\u0026gt; \u0026lt;artifactId\u0026gt;commons-logging\u0026lt;/artifactId\u0026gt; \u0026lt;groupId\u0026gt;commons-logging\u0026lt;/groupId\u0026gt; \u0026lt;/exclusion\u0026gt; logback-classic 冲突 在冲突位置将 logback-classic 排除，","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-acts/faq/","wordcount":776},{"author":null,"categories":null,"content":" Q: Readiness Check 有啥应用场景？ Liveness Check 和 Readiness Check 概念来自于 Kuberentes，分别代表运行时检查和启动时检查。Spring Boot 提供了 Liveness Check，但是没有提供 Readiness Check。利用 Readiness Check 的能力，SOFA 中间件中的各个组件只有在 Readiness Check 通过之后，才将流量引入到应用的实例中，比如 RPC，只有在 Readiness Check 通过之后，才会向服务注册中心注册，后面来自上游应用的流量才会进入。除了中间件可以利用 Readiness Check 的事件来控制流量，PAAS 系统也可以通过访问 http://localhost:8080/health/readiness 来获取应用的 Readiness Check 的状况，从而控制例如负载均衡设备等等的流量。\nQ: 是否可以在 SOFABoot 模块中定义 Controller 组件？ SOFABoot 模块一般用于封装对外发布服务接口的具体实现，属于业务层，Controller 属于展现层内容，我们不建议也不支持在 SOFABoot 模块中定义 Controller 组件，Controller 组件相关定义建议直接放在 Root Application Context。\nQ: 类隔离在蚂蚁内部使用是否广泛？ 类隔离在蚂蚁内部使用非常广泛，绝大部分业务应用都是运行在蚂蚁中间件自研的类隔离框架之上。主要是为了解决依赖冲突的问题，像蚂蚁金服这种体量的公司，业务线繁杂、基础服务组件众多，很难做到对所有 JAR 包做统一管控。特别涉及到跨团队模块组件相互依赖时，因为各自技术栈历史包袱的存在，难以有效统一冲突包版本。使用类隔离技术解决了实际开发中的很多痛点，业务开发者不需要担心自身依赖冲突的问题，在多团队协作开发中，也有很大的优势。\nQ: SOFABoot类隔离框架（SOFAArk）和 OSGI 容器有哪些差异？ 作为开源界早负盛名的动态模块系统，基于 OSGi 规范的 Equinox、Felix 等同样具备类隔离能力，然而他们更多强调的是一种编程模型，面向模块化开发，有一整套模块生命周期的管理，定义模块通信机制以及复杂的类加载模型。作为专注于解决依赖冲突的隔离框架，SOFAArk 专注于类隔离，简化了类加载模型，因此显得更加轻量。其次在 OSGi 规范中，所有的模块定义成 Bundle 形式，作为应用开发者，他需要了解 OSGi 背后的工作原理，对开发者要求比较高。在 SOFAArk 中，定义了两层模块类型，Ark Plugin 和 Ark Biz，应用开发者只需要添加隔离的 Ark Plugin 依赖，底层的类加载模型对应用开发者俩说是透明的，基本不会带来额外的学习成本。\nQ: SOFAArk 和 Java9 模块化有哪些差异？ Jigsaw 作为 Java9 模块化方案，抛开内部实现细节，在使用规范上和 OSGi 特别相似：模块的依赖、包导入导出、动态导出、可读性传递、模块服务注册与消费、开放模块、可选模块等等若干概念，相对于 SOFAArk 简单的包导入导出显然过于复杂。在实现细节上，考虑到 JDK 代码的兼容性，Jigsaw 没有采用类加载器隔离的方式，不同模块之间仍然可能是同一个类加载器加载。严格上来讲，Jigsaw 并没有解决同一个类多版本的问题，但是因为模块显示的依赖声明，使用纯 Jigsaw 模块化编程，不同版本类冲突的问题在编译期就能被检查或者启动失败，因为不允许不同模块含有相同类名的包。对于在实际开发中遇到的一类情况，例如两个组件依赖不同版本 hessian 包，即使这两个组件定义成了两个模块，运行时也只有一个hessian版本被加载，依然解决不了不同版本类共存的问题。另外，Jigsaw 相对 Ark 或者 OSGi 有一个明显的缺点，Jigsaw 不允许运行时动态发布模块服务，模块间的通信依赖在 module-info.java 中使用 provides 和 uses 静态注册和引用模块服务。当然，Jigsaw 有很多自己的优点，通过引入module-path，在 module 中显示声明模块依赖关系，避免了传统 maven/gradle 中因为间接依赖导致运行时加载类不确定的缺点；其次通过设置模块包的导入导出配置，可以完全做到接口和实现的分离，提升安全性；另外 Java9 本身借助模块化改造，使用jlink工具，开发者可以将自身应用必须的模块聚合，打包一个自定义的jre镜像。\nQ: 为什么使用 SNAPSHOT 版本拉取不到依赖？ 如果需要使用处于研发状态的 SNAPSHOT 版本，有两种方式：\n 拉取 sofa-ark 仓库代码，本地执行 mvn install。 在本地 maven setting.xml 文件增加如下 profile 配置: \u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; Q: 为什么使用 java -jar 启动 Spring Boot/SOFABoot 应用 Ark 包时，应用自动退出？ 因为 SOFAArk 容器不会开启任何非 Daemon 线程，如果是非 Web 应用或者应用启动时不会创建非 Daemon 线程，则应用在执行完 main 方法时，会正常退出。判断 Ark 包是否正常启动，可以观察是否有如下日志出现：\nArk container started in …","date":-62135596800,"description":"","dir":"projects/sofa-boot/faq/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"56f06d32d37d8a5947d7c7ee43d6d955","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/faq/","summary":"Q: Readiness Check 有啥应用场景？ Liveness Check 和 Readiness Check 概念来自于 Kuberentes，分别代表运行时检查和启动时检查。Spring Boot 提供了 Liveness Check，但是没有提供","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-boot/faq/","wordcount":2071},{"author":null,"categories":null,"content":" 与 Prometheus的差异 答：主要包括:（1）Lookout metrics server 支持适配更多的协议接入；（2）聚焦在围绕 ES 生态提供易使用和运维的最佳实践；（3）支持计算能力下推；（4）除了 Metrics 后期会有 tracing，eventing等方案； （5）对聚合函数和 REST API 都做了兼容性的扩展和增强；（6）支持分布式集群部署具备高可用能力。\nLookout客户端会提供多语言(c,go,python\u0026amp;hellip;)支持吗 答：暂时不会。因为 Lookout Gateway已经支持很多主流协议的数据上报，同时也支持自定义扩展。 如果非Java技术栈，我们推荐大家使用其他开源主流的sdk库，比如: Prometheus sdk，Metricbeat等\n\u0026amp;ldquo;In order to improve query performance, you need to add tag filtering! realQuery:jvm.classes.loaded\u0026amp;rdquo; 答：只输入metric name查询会影响查询性能，所以我们强制每个查询至少有一个 tag（label）的筛选能力，比如:\u0026amp;ldquo;jvm.classes.loaded{app=\u0026amp;ldquo;lookout-gateway\u0026amp;rdquo;}\u0026amp;ldquo;。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/faq/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f05d40c9d503ad466634f0473a5fac40","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/faq/","summary":"与 Prometheus的差异 答：主要包括:（1）Lookout metrics server 支持适配更多的协议接入；（2）聚焦在围绕 ES 生态提供易使用和运维的最佳实践；","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/faq/","wordcount":430},{"author":null,"categories":null,"content":" 咨询 Q: SOFARPC 是蚂蚁金服内部使用的版本吗？ 是的，SOFARPC 有良好的扩展接口，内部使用的版本就是在开源的版本多一些扩展实现。例如我们云上的商业版本集成了蚂蚁金融云的共享版注册中心、链路跟踪等产品；蚂蚁内部的版本集成了蚂蚁内部的注册中心、LDC路由等特性扩展。\nQ: SOFARPC 内部是用 Zookeeper 作为注册中心的吗？可以集成其它 etcd 等注册中心吗？ 在蚂蚁内部使用的是蚂蚁自研的注册中心产品。SOFARPC 的注册中心模块是可扩展的，对内对外使用的都是一套核心接口。目前开源的版本中集成了 Zookeeper，其它的注册中心实现社区已经在集成中。\nQ: 与Dubbo对比？ Dubbo 是阿里集团开源的一款非常优秀的RPC框架，高性能，具有良好的扩展性。Dubbo在国内开源界起步较早，使用者较多，开源生态更加丰富，目前已进入Apache基金会进行孵化。Dubbo最早在阿里巴巴B2B部门广泛使用。更多信息这里就不多介绍了。\nSOFARPC 最早起源于阿里集团内部的 HSF，但是经过了蚂蚁金服集团内部多年的独立发展，目前脱离为一个独立的产品。SOFARPC 在协议，网络，路由，可扩展性等层面都进行了大量的改造和优化的工作，以满足蚂蚁金服大规模金融级的业务场景。在蚂蚁金服内部，SOFARPC 在蚂蚁中间件（SOFAStack）的生态下，有完善的微服务技术栈支持，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量等等。截止 2019 年双十一，SOFARPC 已经被蚂蚁几千个系统所使用，生产环境发布的接口数量超过了十几万。\n但是在开源领域，SOFARPC 目前还是一个起步阶段，开源生态还在建设当中，随着开源计划的推进，我们会在后续的版本里增加各个周边组件，完善微服务技术栈。同时也欢迎大家来贡献，共同打造 SOFAStack。\n对于性能的对比，类似协议下使用的技术点都是差不多的，所以基本上可比性不高。 对于扩展性的对比，两者都具有良好的扩展性。 对于其它功能差异点的话，这里列一些已经开源或者即将开源的功能点供参考：SOFARPC 协议上将支持 HTTP/2、GRPC，能力上如服务预热权重、自动故障降级、协商机制、CRC数据校验等，结合 SOFABoot 可以实现 RPC 框架与业务的类隔离防止类冲突等等，另外 SOFARPC 在跨单元机房的路由，包括配合服务注册体系实现的对异地多活的支撑也是非常有特色的，期望后面能逐步跟大家分享讨论，甚至形成行业标准。而 SOFARPC 结合内部微服务下做一致性的框架实现的「微交易」架构也是蚂蚁在金融领域非常有价值的沉淀，也是跟 dubbo 体系不一样的地方。\nQ: 对比其他 RPC 框架有何优势？ 作为RPC框架，最基本的能力就是 RPC 调用，其它都是些性能、扩展性、功能性的差异，可能各家的侧重点不一样。\nSOFARPC 在蚂蚁金服内部大规模应用足以证明 SOFARPC 是一款可靠的生产级的 RPC 框架。而蚂蚁金服的金融的属性决定了 SOFARPC 在金融场景下的功能侧重点。\nQ: 和Spring Cloud 的对比？ SOFARPC 定位在 RPC 框架，和 Spring Cloud 的比较不在一个对比维度上面。 Spring Cloud 可对比的是 SOFAStack，SOFAStack 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，以及分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案。SOFAStack 的各个组件会在未来逐渐开源。\n另外，SOFARPC 的 Starter 是基于 Spring Boot 开发的，Spring Cloud 的各个组件也是基于 Spring Boot 开发的，所以两者并不冲突。\n研发类 Q: 为什么不使用 JDK8 SOFARPC 在蚂蚁金服内部还有JDK6的使用场景，所以编译选择JDK7，而编译级别选择JDK6。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/faq/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a6ec77ce5a423c5345394f42c64a416b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/faq/","summary":"咨询 Q: SOFARPC 是蚂蚁金服内部使用的版本吗？ 是的，SOFARPC 有良好的扩展接口，内部使用的版本就是在开源的版本多一些扩展实现。例如我们云上的商业版","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/faq/","wordcount":1533},{"author":null,"categories":null,"content":"SOFARPC 可以在使用 Bolt 通信协议的情况下，可以选择不同的序列化协议，目前支持 hessian2 和 protobuf。\n默认的情况下，SOFARPC 使用 hessian2 作为序列化协议，如果需要将序列化协议设置成 protobuf，在发布服务的时候，需要做如下的设置：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 即在 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签内增加 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签，并且设置 serialize-type 属性为 protobuf。\n对应的，在引用服务的时候，也需要将序列化协议改成 protobuf，设置方式和发布服务的时候类似：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot; jvm-first=\u0026amp;quot;false\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 目前，使用注解的方式尚不能支持设置序列化协议，这个将在后续的版本中支持，详见 ISSUE：https://github.com/sofastack/sofa-boot/issues/278\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/serialization/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"87e2faa84c2c7a7605243dc096bc4e17","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/serialization/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/serialization/","summary":"SOFARPC 可以在使用 Bolt 通信协议的情况下，可以选择不同的序列化协议，目前支持 hessian2 和 protobuf。 默认的情况下，SOFARPC 使用 hessian2 作为序列化协议，如","tags":null,"title":"序列化协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/serialization/","wordcount":296},{"author":null,"categories":null,"content":" SLF4J 提供了 MDC （Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。本文将介绍 SOFATracer 集成的 SLF4J MDC功能，方便用户在只简单修改日志配置文件的前提下输出当前 SOFATracer 上下文 TraceId 以及 SpanId 。\n使用前提 为了在应用中的日志正确打印 TraceId 和 SpanId 参数，我们的日志编程接口需要面向 SLF4J 进行编程，即打印日志的编程接口不要依赖具体的日志实现。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入依赖 如果是 SOFABoot 或者 Spring Boot 的应用具体的日志实现需要大家去引入，我们推荐的日志打印实现是 Logback 和 Log4j2，不推荐 Log4j，同时日志实现建议只使用一个而不要使用多个实现。\n Logback 实现引入： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Log4j2 实现引入： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-log4j2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!--SOFABoot 没有管控 log4j2 版本 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置方法 我们基于 SLF4J MDC 的原理打印对应的 TraceId 和 SpanId，首先我们的应用中的日志编程接口应该面向 SLF4J，如通过如下的方式：\n//引入接口 import org.slf4j.Logger; import org.slf4j.LoggerFactory; //构造日志打印实例 private static final Logger logger = LoggerFactory.getLogger(XXX.class); 其次，我们为了正确打印 TraceId 和 SpanId 参数，我们还需要在日志的配置文件中配置 PatternLayout 的额外参数，这两个参数是 %X{SOFA-TraceId} 和 %X{SOFA-SpanId}，参数值我们均是从 MDC 中获取的值。\n以 Logback 为例配置的 pattern 参数：\n\u0026amp;lt;pattern\u0026amp;gt;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId}, %X{SOFA-SpanId}] ---- %m%n\u0026amp;lt;/pattern\u0026amp;gt; 关键配置项目：[%X{SOFA-TraceId},%X{SOFA-SpanId}] 作为 Logback pattern 的一部分，在对应的 appender 被调用的时候，会根据 pattern 中的占位符替换为当前线程上下文中 TraceId 和 SpanId 的具体值，当前线程中没有对应的 TraceId 和 SpanId 值时，会用“空字符串”替代。 Log4j2 配置 PatternLayout 样例：\n\u0026amp;lt;PatternLayout pattern=\u0026amp;quot;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId},%X{SOFA-SpanId}] ---- %m%n \u0026amp;quot; /\u0026amp;gt; Log4j 配置 PatternLayout 样例：\n\u0026amp;lt;layout class=\u0026amp;quot;org.apache.log4j.PatternLayout\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;param name=\u0026amp;quot;ConversionPattern\u0026amp;quot; value=\u0026amp;quot;%d %-5p %-32t [%X{SOFA-TraceId},%X{SOFA-SpanId}] - %m%n\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/layout\u0026amp;gt; 需要注意的是：[%X{SOFA-TraceId},%X{SOFA-SpanId}] 使我们推荐的打印格式，用户可以根据自己的实际需求场景进行定制\n 附:基于 Log4j2 示例工程的源代码地址。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/print-traceid-spanid/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0d8cc680f811d1db2cffddbba269571c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","summary":"SLF4J 提供了 MDC （Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。本文将介绍 SOFATracer 集成的 SLF4J MDC功能，方便用户在只","tags":null,"title":"应用日志打印 traceId 和 spanId","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","wordcount":701},{"author":null,"categories":null,"content":" SOFADashboard 支持查看应用的IP、端口、健康检查状态等基本信息。此功能依赖 SOFADashboard client ，如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可：\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dashboard-client-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; 除此之外，SOFADashboard 解耦了类似于 SpringBoot Admin 客户端和服务端直连的模式，引入了第三方的储存，目前默认是 redis，因此如果希望能够监控 更多 actuator 信息，可以添加如下依赖：\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dashboard-ext-redis-store\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; 功能展示 相关数据的展示采用了 react-json-view 组件，是的可以直观的看到原始数据集。\n应用维度展示 应用实例 基础信息 健康检查详细数据 环境变量 loggins mappings 配置 client , prefix : com.alipay.sofa.dashboard.client\n 属性 名称 默认值 备注 enable 是否可用 true 当开启时，dashboard client 的相应功能才会作用 instanceIp 指定当前实例的IP 地址 \u0026amp;rdquo;\u0026amp;rdquo; 一般用于测试或者需要指定 IP 的场景 storeInitDelayExp 初始上报延迟 30s Dashboard度量数据存储上报延迟期望(s) storeUploadPeriodExp 上报周期 60s Dashboard度量数据存储上报周期(s) virtualHost 虚拟地址 \u0026amp;rdquo;\u0026amp;rdquo; 服务发布虚拟host（同SofaRpc中相同定义），可使用-Dcom.alipay.sofa.rpc.virtual.host引入 virutalPort 虚拟端口 \u0026amp;rdquo;\u0026amp;rdquo; 服务发布虚拟port（同SofaRpc中相同定义），可使用-Dcom.alipay.sofa.rpc.virtual.port引入 internalHost 内部地址 \u0026amp;rdquo;\u0026amp;rdquo; 容器内部地址（例如podIp等)，可使用-Dcom.alipay.sofa.rpc.virtual.internal.host引入 arkEnable 是否启用ark管理 true 当开启时，dashboard client的相应功能才会作用 注：virtualHost，virutalPort 如果通过com.alipay.sofa.rpc指定了相应参数，则不需要通过dashborad再次指定\nzookeeper , prefix : com.alipay.sofa.dashboard.zookeeper\n 属性 名称 默认值 备注 address 地址 true baseSleepTimeMs 客户端错误重试间隔(ms). 1000 maxRetries 客户端最大重试次数 3 sessionTimeoutMs 客户端会话超时时间(ms) 6000 connectionTimeoutMs 客户端超时时间(ms) 6000 redis , prefix : com.alipay.sofa.dashboard.redis\n 属性 名称 默认值 备注 enble 是否可用 true 当开启时，dashboard会使用redis作为存储 recordTtl 上报周期(ms). 3600 url redis对应url 例如：redis://user:password@example.com:6379 host redis对应host（单实例模式） port redis对应port（单实例模式） password redis密码 Sentinel.master Sentinel模式master master节点名，需参阅集群搭建设置 Sentinel.nodes Sentinel模式节点地址 例如host1:port1;host2:port2;host3:port3 Cluster.nodes Cluster模式节点地址 例如host1:port1;host2:port2;host3:port3 Cluster.maxRedirects Cluster模式重定向次数 0 建议给值，例如10 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/dashboard-client/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"60586c6dfee1f2afcdac88cbe7a36b83","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/dashboard-client/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/dashboard-client/","summary":"SOFADashboard 支持查看应用的IP、端口、健康检查状态等基本信息。此功能依赖 SOFADashboard client ，如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可： \u0026lt;denpendency\u0026gt;","tags":null,"title":"应用面板","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/dashboard-client/","wordcount":1078},{"author":null,"categories":null,"content":" 首先参考基本代码贡献需知 注意测试用例覆盖率； 代码格式； 验证 Samples 单独导入 Samples 的 Maven 项目； 修改对应 Pom 文件中依赖版本； 验证 Samples 也能正确工作； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/development-use-guide/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"423a54ec3f5fbfc9c0e150eb853738ae","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/development-use-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/development-use-guide/","summary":"首先参考基本代码贡献需知 注意测试用例覆盖率； 代码格式； 验证 Samples 单独导入 Samples 的 Maven 项目； 修改对应 Pom 文件中依赖版本； 验证 Samples 也能正确工作；","tags":null,"title":"开发指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/development-use-guide/","wordcount":63},{"author":null,"categories":null,"content":" 1.如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后在代码目录下执行如下命令：\n mvn clean install 2.版本发布 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号，例如 1.0.1。\n参见: http://semver.org/lang/zh-CN/。\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表 BugFix 版本。只做 bug 修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 1.3.0，那么将会维护 1.2.x 的 bugfix 分支，而 1.1.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 1.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 1.3.0。 发布后拉起下一个版本，例如 1.3.1-SNAPSHOT。 3.测试 单元测试 单元测试例子放到自己开发的模块下，测试类的包名与被测试类所在包相同。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/developer-guide/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fcacc7e89b979f3aec8dc3333a7a3c37","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-acts/developer-guide/","summary":"1.如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后在代码目录下执行如下命令： mvn clean install 2.版本发布 版本号 采用三位版本号，分别是主版","tags":null,"title":"开发者手册","type":"projects","url":"/sofastack.tech/projects/sofa-acts/developer-guide/","wordcount":404},{"author":null,"categories":null,"content":"介绍实现架构和相关的细节介绍： * 如何编译 * 架构介绍 * 调用流程 * 基础模型 * 扩展点设计 * 版本发布 * 测试\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/developer-guide/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"903b9f3a5372a75d654f8eeaaf750eeb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/developer-guide/","summary":"介绍实现架构和相关的细节介绍： * 如何编译 * 架构介绍 * 调用流程 * 基础模型 * 扩展点设计 * 版本发布 * 测试","tags":null,"title":"开发者手册","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/developer-guide/","wordcount":49},{"author":null,"categories":null,"content":" 线程中使用 java.lang.Runnable 如果用户在代码中通过 java.lang.Runnable 新启动了线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFATracer 提供的 com.alipay.common.tracer.core.async.SofaTracerRunnable 默认完成了此操作，大家可以按照如下的方式使用：\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.start(); 线程中使用 java.util.concurrent.Callable 如果用户在代码中通过 java.util.concurrent.Callable 新启动线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFATracer 提供的 com.alipay.common.tracer.core.async.SofaTracerCallable 默认完成了此操作，大家可以按照如下的方式使用：\nExecutorService executor = Executors.newCachedThreadPool(); SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt; sofaTracerSpanSofaTracerCallable = new SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt;(new Callable\u0026amp;lt;Object\u0026amp;gt;() { @Override public Object call() throws Exception { return new Object(); } }); Future\u0026amp;lt;Object\u0026amp;gt; futureResult = executor.submit(sofaTracerSpanSofaTracerCallable); //do something in current thread Thread.sleep(1000); //another thread execute success and get result Object objectReturn = futureResult.get(); 这个实例中，假设 java.util.concurrent.Callable 返回结果的对象类型是 java.lang.Object，实际使用时可以根据情况替换为期望的类型。\nSOFATracer 对线程池、异步调用场景下的支持 异步场景 异步调用，以 rpc 调用为例，每次 rpc 调用请求出去之后不会等待到结果返回之后才去发起下一次处理，这里有个时间差，在前一个 rpc 调用的 callback 回来之前，又一个新的 rpc 请求发起，此时当前线程中的 TracerContext 没有被清理，则 spanId 会自增，tracerId 相同。\n 对于上面这种情况，SOFATracer 在对于异步情况处理时，不会等到 callback 回来之后，调用 cr 阶段才会清理，而是提前就会清理当前线程的 tracerContext 上下文，从而来保证链路的正确性。\n线程池 目前来说，不管是 SOFARPC 还是 Dubbo 的埋点实现，在使用单线程或者线程池时，情况是一样的：\n 同步调用，线程池中分配一个线程用于处理 rpc 请求，在请求结束之前会一直占用线程；此种情况下不会造成下一个 rpc 请求错拿上一个请求的 tracerContext 数据问题 异步调用，由于异步回调并非是在 callback 中来清理上下文，而是提前清理的，所以也不会存在数据串用问题。 callback 异步回调，这个本质上就是异步调用，所以处理情况和异步调用相同。 附：案例工程\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/async/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e755346c441115663c101638667fe4c0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/async/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/async/","summary":"线程中使用 java.lang.Runnable 如果用户在代码中通过 java.lang.Runnable 新启动了线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFA","tags":null,"title":"异步线程处理","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/async/","wordcount":726},{"author":null,"categories":null,"content":" 本文用于帮助初次接触 MOSN 项目的开发人员，快速搭建开发环境，完成构建，测试，打包和示例代码的运行。\n注：MOSN 基于 Go 1.12.7 开发，使用 dep 进行依赖管理。\n准备运行环境 如果您使用容器运行 MOSN，请先 安装 docker 如果您使用本地机器，请使用类 Unix 环境 安装 Go 的编译环境 安装 dep : 参考官方安装文档 获取代码 MOSN 项目的代码托管在 Github，获取方式如下：\ngo get -u mosn.io/mosn 如果您的 go get 下载存在问题，请手动创建项目工程\n# 进入 GOPATH 下的 src 目录 cd $GOPATH/src # 创建 mosn.io 目录 mkdir -p mosn.io cd mosn.io # 克隆 MOSN 代码 git clone git@github.com:mosn/mosn.git cd mosn 最终 MOSN 的源代码代码路径为 $GOPATH/src/mosn.io/mosn\n导入IDE 使用您喜爱的 Go IDE 导入 $GOPATH/src/mosn.io/mosn 项目，推荐 Goland。\n编译代码 在项目根目录下，根据自己机器的类型以及欲执行二进制的环境，选择以下命令编译 MOSN 的二进制文件。\n使用 docker 镜像编译 make build // 编译出 linux 64bit 可运行二进制文件 本地编译 使用下面的命令编译本地可运行二进制文件。\nmake build-local 在非 Linux 机器交叉编译 Linux 64bit 可运行二进制文件。\nmake build-linux64 在非 Linux 机器交叉编译 Linux 32bit 可运行二进制文件。\nmake build-linux32 完成后可以在 build/bundles/${version}/binary 目录下找到编译好的二进制文件。\n打包 在项目根目录下执行如下命令进行打包。\nmake rpm 完成后可以在 build/bundles/${version}/rpm 目录下找到打包好的文件。\n创建镜像 执行如下命令进行镜像创建。\nmake image 运行测试 在项目根目录下执行如下命令运行单元测试：\nmake unit-test 在项目根目录下执行如下命令运行集成测试（较慢）。\nmake integrate 从配置文件启动 MOSN 运行下面的命令使用配置文件启动 MOSN。\n./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; 开启 MOSN 转发示例程序 参考 examples 目录下的示例工程运行 Samples。\n使用 MOSN 搭建 Service Mesh 平台 请参考与 Istio 集成。\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-setup/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d41615315adb522aa4b84762f113a574","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-setup/","summary":"本文用于帮助初次接触 MOSN 项目的开发人员，快速搭建开发环境，完成构建，测试，打包和示例代码的运行。 注：MOSN 基于 Go 1.12.7 开发，使用 dep 进行依赖管理。","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-setup/","wordcount":614},{"author":null,"categories":null,"content":" 本文档共分为四部分：\n 第一部分：在 Intellij IDEA 上安装 ACTS IDE 可视化编辑器； 第二部分：向您介绍如何在多模块工程中引入 ACTS 依赖； 第三部分：测试模块下一键搭建 ACTS 框架以管理后续 ACTS 用例； 第四部分：一键生成 ACTS 测试脚本； 1.安装 ACTS IDE 推荐使用 Intellij IDEA 2017，为了您的安全，请仅从该下载源获取 ACTS IDE 安装包： 点击下载 ACTS IDE，\n本地磁盘安装：Preference -\u0026amp;gt; Plugins -\u0026amp;gt; Install plugin from disk -\u0026amp;gt; Restart IDEA 即可。 2.引入 ACTS 依赖 在引入依赖之前，需要您的应用是一个多模块工程（包含 test 模块），后续 ACTS 会将全部的测试代码放置在 test 模块下以便管理 ACTS 用例。\n您可以依据应用的具体情况，选择性阅读以下内容：\n应用已经是完整的多模块工程，可参考文档 2.1 部分，帮助您引入 ACTS 依赖； 应用是多模块工程但无 test 模块，可参考文档 2.2 部分，帮助您快速添加 test 模块； 应用不是一个多模块工程，可参考文档 2.3 部分，帮助您快速构建多模块工程。 如果还没有创建工程，可参考 SOFABoot 快速开始搭建应用。\n2.1多模块应用-包含 test 模块 只需在 test 模块的 pom.xml 中引入 acts-bom 即可。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2多模块应用-无 test 模块 这里是使用 Intellij IDEA 来创建子模块。\n对着父工程右键 -\u0026amp;gt; New -\u0026amp;gt; Module -\u0026amp;gt; 输入 test 模块名字（一般是 appname-test），分步示例图如下：\n第一步：新建 test 模块 第二步：管理 test 模块 在父工程的 pom.xml 中管理刚刚新建的 test 模块。\n第三步：依赖 ACTS 引入 最后，找到刚刚新建的 test 模块，并在其 pom.xml 中引入 acts-bom 即可。\n\u0026amp;lt;!-- 引入包含 SOFABootApplication 的 pom --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.example\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;example-service\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- 引入 ACTS 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.3非多模块应用 如果你已经有了一个不错的 SOFABoot 应用，但它不是一个多模块应用，下面的内容将帮助你快速地将现有工程构建为多模块工程。\n第一步：新建父工程 创建好一个 SOFABoot 工程，然后删除无关的文件，只需保留 pom.xml 文件。\n第二步：新建子模块 新建子工程模块，将原有应用作为子工程并入父工程下，相关依赖管理提到父工程中。以新建 service 模块和 test 模块为例。\n第三步：管理子模块 第四步：依赖引入 最后，在 test 模块的 pom.xml 文件中引入 acts-bom 即可。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 3.一键初始化 ACTS 测试框架 下面只需要你轻轻动动手指即可完成初始化工作。在图3.2中，您需要正确填写应用名称并选择适合应用的编码格式。\n有关一键初始化生成的文件有何作用，可以参考 ACTS 使用手册的框架准备部分。\n4.一键生成测试脚本 4.1启动类 将 service 模块中的启动类，如 SOFABootApplication 拷贝到 test 模块，并增加需要加载的配置文件：classpath*:META-INF/spring/acts-core.xml\n4.2测试脚本 前提条件：务必 mvn 编译工程和生成对象模型，否则会造成 ACTS IDE 不可预料的错误，如无法编辑、数据不正确等。\n接口定义的方法上点击，选择 ACTS 功能 -\u0026amp;gt; 生成测试用例，并在刚生成的测试脚本中矫正 SOFABoot 启动类的 import 位置。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/getting-started/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dfc5fb9b394ea14c280568dcb881a8b0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/getting-started/","summary":"本文档共分为四部分： 第一部分：在 Intellij IDEA 上安装 ACTS IDE 可视化编辑器； 第二部分：向您介绍如何在多模块工程中引入 ACTS 依赖； 第三部分：测试模块下一键搭建 ACTS 框","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-acts/getting-started/","wordcount":1074},{"author":null,"categories":null,"content":" 在本文档中，将创建一个 Spring Boot 的工程，引入 SOFABoot 基础依赖，并且引入 SOFABoot 的健康检查扩展能力，演示如何快速上手 SOFABoot。\n环境准备 要使用 SOFABoot，需要先准备好基础环境，SOFABoot 依赖以下环境： - JDK7 或 JDK8 - 需要采用 Apache Maven 3.2.5 或者以上的版本来编译\n创建工程 SOFABoot 是直接构建在 Spring Boot 之上，因此可以使用 Spring Boot 的工程生成工具 来生成，在本文档中，我们需要添加一个 Web 的依赖，以便最后在浏览器中查看效果。\n引入 SOFABoot 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。 然后，添加 SOFABoot 健康检查扩展能力的依赖及 Web 依赖(方便查看健康检查结果)：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 最后，在工程的 application.properties 文件下添加 SOFABoot 工程常用的参数配置，其中 spring.application.name 是必需的参数，用于标示当前应用的名称；logging path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFABoot Demo # logging path logging.path=./logs 运行 可以将工程导入到 IDE 中运行生成的工程里面中的 main 方法（一般上在 XXXApplication 这个类中）启动应用，也可以直接在该工程的根目录下运行 mvn spring-boot:run，将会在控制台中看到启动打印的日志：\n2018-04-05 21:36:26.572 INFO ---- Initializing ProtocolHandler [\u0026amp;quot;http-nio-8080\u0026amp;quot;] 2018-04-05 21:36:26.587 INFO ---- Starting ProtocolHandler [http-nio-8080] 2018-04-05 21:36:26.608 INFO ---- Using a shared selector for servlet write/read 2018-04-05 21:36:26.659 INFO ---- Tomcat started on port(s): 8080 (http) 可以通过在浏览器中输入 http://localhost:8080/sofaboot/versions 来查看当前 SOFABoot 中使用 Maven 插件生成的版本信息汇总，结果类似如下：\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Built-Time: \u0026amp;quot;2018-04-05T20:55:26+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.4\u0026amp;quot; } ] 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，sofaboot/versions 更改为 actuator/versions\n可以通过在浏览器中输入 http://localhost:8080/health/readiness 查看应用 Readiness Check 的状况，类似如下：\n{ status: \u0026amp;quot;UP\u0026amp;quot;, sofaBootComponentHealthCheckInfo: { status: \u0026amp;quot;UP\u0026amp;quot; }, springContextHealthCheckInfo: { status: \u0026amp;quot;UP\u0026amp;quot; }, DiskSpace: { status: \u0026amp;quot;UP\u0026amp;quot;, total: 250140434432, free: 22845308928, threshold: 10485760 } } 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，health/readiness 更改为 actuator/readiness\nstatus: \u0026amp;quot;UP\u0026amp;quot; 表示应用 Readiness Check 健康的。可以通过在浏览器中输入 http://localhost:8080/health 来查看应用的运行时健康状态（可能会随着时间发生变化）。\n注: 在 SOFABOOT 3.X 中调整了 endpoint 路径，/health 更改 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/quick-start/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7f582b905fde4a56791c03d4dd6b5a57","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/quick-start/","summary":"在本文档中，将创建一个 Spring Boot 的工程，引入 SOFABoot 基础依赖，并且引入 SOFABoot 的健康检查扩展能力，演示如何快速上手 SOFABoot。 环境准备 要使用 SOFABo","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-boot/quick-start/","wordcount":2154},{"author":null,"categories":null,"content":" 这个快速开始可以帮您快速在您的电脑上，下载、安装并使用 SOFADashboard。\n环境准备 sofa-dashboard-backend 依赖 Java 环境来运行。请确保是在以下运行环境可以正常使用:\n JDK 1.8+；下载 \u0026amp;amp; 配置。 Maven 3.2.5+；下载 \u0026amp;amp; 配置。 sofa-dashboard-frontend 使用了 Ant Design Pro 脚手架，前端环境请参考 Ant Design\n数据库初始化 Mysql 版本：5.6+\n SOFAArk 管控需要依赖 MySQL 进行资源数据存储，工程目录下有一个 SofaDashboardDB.sql 脚本文件，可以通过执行这个脚本文件进行数据库表的初始化。\nZookeeper  ZooKeeper 3.4.x and ZooKeeper 3.5.x\n SOFADashboard 中的服务治理、SOFAArk 管控依赖于 Zookeeper，需要本地启动 Zookeeper 服务： ZooKeeper Document。\n后端运行 \u0026amp;gt; git clone https://github.com/sofastack/sofa-dashboard.git \u0026amp;gt; cd sofa-dashboard \u0026amp;gt; mvn clean package -DskipTests \u0026amp;gt; cd sofa-dashboard-backend/sofa-dashboard-web/target/ \u0026amp;gt; java -jar sofa-dashboard-web-1.0.0-SNAPSHOT.jar 前端运行 sofa-dashboard-front 是 SOFADashboard 的前端代码工程，基于蚂蚁金服开源的前端框架 antd 开发。\n\u0026amp;gt; cd sofa-dashboard-front \u0026amp;gt; npm i \u0026amp;gt; npm run dev 案例工程 sofastack-dashboard-guides ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/quick-start/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa4c5f48810727f71d675255f19617a3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/quick-start/","summary":"这个快速开始可以帮您快速在您的电脑上，下载、安装并使用 SOFADashboard。 环境准备 sofa-dashboard-backend 依赖 Java 环境来运行。请确保是在以下运行环境可以正常","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/quick-start/","wordcount":313},{"author":null,"categories":null,"content":"SOFARPC 有多种编程界面，下面会对各种界面进行举例： - SOFARPC 方式 - SOFABoot 方式\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"990bb2211b02b04c3ab6e03f3ba1f74b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started/","summary":"SOFARPC 有多种编程界面，下面会对各种界面进行举例： - SOFARPC 方式 - SOFABoot 方式","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started/","wordcount":30},{"author":null,"categories":null,"content":" SOFATracer 接入的组件列表参考：SOFATracer 介绍，在使用时请注意不同组件对应的SOFATracer 版本和 JDK 版本。\n环境准备 要使用 SOFABoot，需要先准备好基础环境，SOFABoot 依赖以下环境： - JDK7 或 JDK8 - 需要采用 Apache Maven 3.2.5 或者以上的版本来编译\n示例列表 下面所有 Samples 工程均为 SOFABoot 工程(同时支持 SpringBoot 工程中使用)，关于如何创建 SOFABoot 工程请参考 SOFABoot 快速开始。\n 组件接入 Spring MVC 埋点接入 HttpClient 埋点接入 DataSource 埋点接入 RestTemplate 埋点接入 OkHttp 埋点接入 Dubbo 埋点接入 采样 上报数据到 Zipkin ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/component-access/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"143f2b9022161ae5a7b10d261752ae5f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/component-access/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/component-access/","summary":"SOFATracer 接入的组件列表参考：SOFATracer 介绍，在使用时请注意不同组件对应的SOFATracer 版本和 JDK 版本。 环境准备 要使用 SOFABoot","tags":null,"title":"快速开始指南","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/component-access/","wordcount":209},{"author":"向旭","categories":null,"content":"TODO\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/code-analyze/summary/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d6fe0ca21825accb191a9eedccf17358","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/summary/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/summary/","summary":"TODO","tags":null,"title":"总览","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/summary/","wordcount":1},{"author":null,"categories":null,"content":" SOFATracer 此前的埋点均是基于组件维度的埋点，用户很难在自己业务代码中进行埋点操作，或者增加自定义 tag 值来监控一些链路信息。基于此，SOFATracer 从 2.4.1\u0026amp;frasl;3.0.6 版本开始支持手动埋点和基于注解的埋点方式，帮助用户解决自定义埋点问题。\n使用方式 自定义埋点提供了两种方式，一种是手动埋点，一种是基于注解方式埋点。\n手动埋点 手动埋点的方式遵循 opentracing 规范，SOFATracer 中通过 beforeInvoke 和 afterInvoke 两个函数封装了 span 的周期，如下：\n// 注入 tracer @Autowired Tracer tracer; private void testManual(){ try { // beforeInvoke 开始 SofaTracerSpan sofaTracerSpan = ((FlexibleTracer) tracer).beforeInvoke(\u0026amp;quot;testManual\u0026amp;quot;); sofaTracerSpan.setTag(\u0026amp;quot;manualKey\u0026amp;quot;,\u0026amp;quot;glmapper\u0026amp;quot;); // do your biz } catch (Throwable t){ // 异常结束 ((FlexibleTracer) tracer).afterInvoke(t.getMessage()); } finally { // 正常结束 ((FlexibleTracer) tracer).afterInvoke(); } } 这种方式在使用上没有直接使用注解方便，但是可以直观的了解到 span 的生命周期，另外手动埋点也是对基于注解方式埋点的一种补充，下面介绍。\n基于注解方式 SOFATracer 中提供了 @Tracer 注解，其作用域是 method 级别。\n// 在 hello 方法上使用 @Tracer 注解进行埋点 @Tracer public String hello(String word){ // 自定义 tag 数据 SpanTags.putTags(\u0026amp;quot;author\u0026amp;quot;,\u0026amp;quot;glmapper\u0026amp;quot;); // 失效 helloInner(word); return \u0026amp;quot;glmapper : hello \u0026amp;quot; + word; } // 在 hello 方法上使用 @Tracer 注解进行埋点 @Tracer private String helloInner(String word){ return \u0026amp;quot;glmapper : hello \u0026amp;quot; + word; } @Tracer 是基于 Spring Aop 实现，因此一定程度上依赖 Spring 中的代理机制。如代码片段中所示，helloInner 方法由于执行过程中不会使用代理对象，而是 this，所以会导致 helloInner 的注解埋点失效。那么对于此种情况，就可以使用手动埋点的方式来弥补。\nSpanTags 是 SOFATracer 中提供的工具类，在使用注解或者手动埋点的情况下，可以通过此类提供的静态方法来设置 tag 。\n日志格式 json 格式 {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-05 10:23:53.549\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;flexible-sample\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9291567650233504100130712\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.2\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;4ms\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;hello\u0026amp;quot;,\u0026amp;quot;param.types\u0026amp;quot;:\u0026amp;quot;java.lang.String\u0026amp;quot;,\u0026amp;quot;author\u0026amp;quot;:\u0026amp;quot;glmapper\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} 非 json 格式 2019-09-05 10:25:50.992,flexible-sample,0a0fe9291567650350953100130778,0.2,client,,http-nio-8080-exec-1,4ms,hello,param.types=java.lang.String\u0026amp;amp;author=glmapper\u0026amp;amp;,,\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/flexible/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5aaadb77e734e58428a0852d14888e92","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/flexible/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/flexible/","summary":"SOFATracer 此前的埋点均是基于组件维度的埋点，用户很难在自己业务代码中进行埋点操作，或者增加自定义 tag 值来监控一些链路信息。基于此，SOFATracer","tags":null,"title":"手动埋点","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/flexible/","wordcount":566},{"author":null,"categories":null,"content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAArk 实现原理》第二篇，本篇作者盲僧，来自 OYO。《剖析 | SOFAArk 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附系列共建列表，目前已完成领取。\n前言 SOFAArk 是 SOFA 团队开源的又一款扛鼎力作，它是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署的能力。\n从 2016 年底开始，蚂蚁金服内部开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2021 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构，也是为系列文章做好铺垫。\nSOFAArk Biz 的打包插件是 sofa-ark-maven-plugin ，它可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式的 Ark 包或者 Ark Biz 包，关于 Ark 包和 Ark Biz 包可以参考这里：\n Ark 包：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/ Ark Biz：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/ 本文将从如下三个方面进行介绍：先对插件的使用和打包出来的产物做一个简单介绍，然后告诉大家调试插件的方法，最后对整个插件的原理做一个流程图和阐述。\nSOFAArk ：https://github.com/sofastack/sofa-ark\nSOFAArk 插件使用 文中的示例代码可以参考 我的 github。\n 插件使用 先将 Spring Boot 的打包插件 spring-boot-maven-plugin 删除或者注释，然后再引入如下插件即可：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \n执行 mvn package 命令后，将会打出如下结构的 3 个 jar 包，大家可以自行解压这三个 jar 包，看一看里面的具体内容，下面我们简单分析一下：\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT.jar ：它是 maven 插件打出来的原生 jar 包，只包含我们写的代码和 manifest 文件，无特殊意义。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-biz.jar ：这个 jar 包称之为 Ark Biz 包，因为 SOFAArk 容器是支持运行多个 Ark Biz 的，所以打成这种包是为了和别的项目一起合并部署使用，另外 Ark 包里也包含了这个。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-executable.jar ：这个 jar 包称之为 Ark 包，从字面上来看它是一个可执行的 jar 包，即意味着它是一个可以用 java -jar 命令来单独运行的 Fat Jar，类似于我们用 Spring Boot 插件打出来的包。\n后面的分析主要是围绕 Ark 包来做讲解，因为它包含了 Ark Biz 包，所以只要搞明白它是如何生成的，那么对整个插件的原理也就基本了解了。\n与 Spring Boot 插件对比 要想分析出 sofa-ark-maven-plugin 插件的作用，我们需要先和 Spring Boot 的插件进行对比，从打包产物上直观的感受一下两者的区别。\nspring-boot-maven-plugin 插件 spring-boot-maven-plugin 是 SpringBoot 默认提供的打包插件，其功能就是将工程打包成一个可执行的 FATJAR。spring-boot-maven-plugin 打包产物的目录结构如下：\n. ├── BOOT-INF │ ├── classes # 应用的字节码目录 │ └── lib # 应用所依赖的 jar 包 ├── META-INF │ ├── MANIFEST.MF # manifest 文件信息 │ └── maven # 应用的坐标信息 └── org └── springframework └── boot └── loader # 存放的是 Spring Boot Loader 的 class 文件 ├── JarLauncher.class # Spring Boot 启动类 ├── archive ├── data ├── jar └── util MANIFEST.MF 文件内容：\nManifest-Version: 1.0 Archiver-Version: Plexus Archiver Built-By: rrz Start-Class: pers.masteryourself.tutorial.sofa.ark.maven.plugin.MavenP luginApplication Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Spring-Boot-Version: 2.1.4.RELEASE Created-By: Apache Maven 3.5.3 Build-Jdk: 1.8.0_101 Main-Class: org.springframework.boot.loader.JarLauncher MANIFEST.MF 文件中可以看到，描述了当前 jar 的一些核心元素，包括启动类、class 文件路径、lib 依赖路径、jdk 版本等等，这里需要关注的是 Main-Class，SpringBoot 就是通过该类来引导启动的。SOFAArk 应用也提供了类似的引导类及其自身特殊的结构， …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-build-package-plugin/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5ebfd73573e2f2d529f0303da2fe026c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":null,"title":"打包插件","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","wordcount":2994},{"author":null,"categories":null,"content":" 1. 集成部署模式 1.1 扩容 registry-integration 假设目前已经部署了 3 台 registry-integration，分别是 node1/node2/node3，扩容的新节点是 node4。\n操作步骤：\n第一步. 部署新的 registry-integration 节点\n首先参考部署文档，将 registry-integration.tgz 在新节点 node4 上部署起来，值得注意的是，node4 需要将 nodes.metaNode 配置项指定为4台机器的地址列表：\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt; 在这一步中，node4启动完成后，访问 curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check 状态显示是不健康，因为 node4 尚未加入集群，要加入集群，需要做第二步。\n第二步. 调用 changePeer 使新节点加入集群\n对已经存在的 node1/node2/node3 的任意一台，执行“修改节点列表”的运维命令，将原有由 node1/node2/node3 构成的集群，改为 node1/node2/node3/node4 集群：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check 状态显示应当是健康。\n1.2 缩容 registry-integration 假设集群目前有3台机器 node1/node2/node3，需要缩容 node3。\n1.2.1 平滑缩容 操作步骤：\n第一步. 调用 changePeer 移除节点\n对 node1/node2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“node1/node2/node3”改为“node1/node2”，即把node3移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;node3\u0026amp;gt;:9615/health/check 状态显示应当是不健康的，因为 node3 已经被踢出了集群。\n**第二步.关闭 node3 **\n这一步可选，因为 node3 已经被移除集群了，所以即便 node3 还在运行，也对原集群不影响。\n1.2.2 宕机处理 假设 node3 已经宕机，也需要将 node3 移除出集群\n操作步骤：\n第一步. 调用 changePeer 移除节点\n对 node1/node2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“node1/node2/node3”改为“node1/node2”，即把 node3 移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 2. 独立部署模式 2.1 扩容 registry-meta 假设目前已经部署了3台 registry-meta ，分别是 metaNode1/metaNode2/metaNode3，扩容的新节点是 metaNode4.\n操作步骤：\n第一步. 部署新的 registry-meta 节点\n首先参考部署文档，将 registry-meta.tgz 在新节点 metaNode4 上部署起来，值得注意的是，metaNode4 需要将 nodes.metaNode 配置项指定为4台机器的地址列表：\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;,\u0026amp;lt;metaNode3\u0026amp;gt;,\u0026amp;lt;metaNode4\u0026amp;gt; 在这一步中，metaNode4 启动完成后，访问 curl http://localhost:9615/health/check 状态显示是不健康，因为 metaNode4 尚未加入集群，要加入集群，需要做第二步。\n第二步. 调用 changePeer 使新节点加入集群\n对已经存在的 metaNode1/metaNode2/metaNode3 的任意一台，执行“修改节点列表”的运维命令，将原有由 metaNode1/metaNode2/metaNode3 构成的集群，改为 metaNode1/metaNode2/metaNode3/metaNode4 集群：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;metaNode1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;,\u0026amp;lt;metaNode3\u0026amp;gt;,\u0026amp;lt;metaNode4\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://localhost:9615/health/check 状态显示应当是健康。\n2.2 缩容 registry-meta 假设集群目前有3台机器 metaNode1/metaNode2/metaNode3，需要缩容 metaNode3。\n2.2.1 平滑缩容 操作步骤：\n第一步. 调用 changePeer 移除节点\n对 metaNode1/metaNode2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“metaNode1/metaNode2/metaNode3”改为“metaNode1/metaNode2”，即把 metaNode3 移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;metaNode1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;metaNode3\u0026amp;gt;:9615/health/check 状态显示应当是不健康的，因为metaNode3已经被踢出了集群。\n第二步. 关闭 metaNode3\n这一步可选，因为 metaNode3 已经被移除集群了，所以即便 metaNode3 还在运行，也对 …","date":-62135596800,"description":"","dir":"projects/sofa-registry/scale/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"57de6dc4da1292063ff25ecea9ffbd08","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/scale/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/scale/","summary":"1. 集成部署模式 1.1 扩容 registry-integration 假设目前已经部署了 3 台 registry-integration，分别是 node1/node2/node3，扩容的新节点","tags":null,"title":"扩容与缩容","type":"projects","url":"/sofastack.tech/projects/sofa-registry/scale/","wordcount":1695},{"author":null,"categories":null,"content":" 自定义引擎各个阶段 可以在测试脚本中或者基类中重写 ActsTestBase 提供的 API。\n 重写 prepare，execute，check，clear 等。可以通过在 super.prepare() 之前或者之后进行某些操作。 重写 process 方法，在 super.process() 之前或之后进行操作。可将整个脚本重新编排，例如在现有的清理 -\u0026amp;gt; 准备 -\u0026amp;gt; 执行 -\u0026amp;gt; 校验流程中增加一些个性化的步骤。 重写 beforeActsTest、afterActsTest，可以在每一个用例运行前后做一些个性化的操作，如准备上下文、缓存刷新等。 参数化 在结果期望和数据库期望中可以使用 $变量名 来标识某个值是变量，测试脚本中可以把值设置进去； 支持范围：入参、返回结果、数据库表字段，支持类型：目前仅支持 String 的参数化。\n使用方法：\n（1）界面以 $ 开头定义变量\n（2）代码中给变量赋值\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { actsRuntimeContext.paramMap.put(\u0026amp;quot;roleId\u0026amp;quot;, \u0026amp;quot;123\u0026amp;quot;); actsRuntimeContext.refreshDataParam(); } 在写 DB 数据期望的时候，也可以通过 = 符号来进行赋值，表示这个值来自于查询结果，后面的表就可以使用这个变量作为值。\n假设接口会向 2 张表插入数据。\n id_A value_A 123 abc id_B value_B abc efg 查询的时候要先通过接口返回的 A 表的 id_A 查到 value_A, 然后把 value_A 作为 B 表的查询条件，在插件上面可以这样写：\n 字段 flag 值 id_A C $param1 value_A Y =param2 字段 flag 值 id_B C $param2 value_B Y efg 上面操作说明：\n =param2 和 $param2 的操作，表示框架会先从 A 表查出 value_A 然后 select from B where id_B = value_A，进而得到全部 B 表的属性值； $param1 表示可以在代码中对 id_A 赋值，代码形如： actsRuntimeContext.paramMap.put(\u0026amp;quot;param1\u0026amp;quot;,\u0026amp;quot;123\u0026amp;quot;); 表示对变量 param1 赋值 123，上述代码可以写到脚本的 beforeActsTest 里面，这样在查询 A 表之前，框架就会将 123 赋值给 id_A。\n参数组件化 目前仅支持 String 的组件化\n如果属性是需要动态生成的字符串，例如某些 ID，可以通过 @ 符号来调用一个组件生成这个属性，组件要放在跟 test 同级的 component 包下，即：com.corpname.appname.acts.component (这里appname是系统名，corpname是公司名，如alipay)。\npublic class MyComponent { @TestComponent(id = \u0026amp;quot;test\u0026amp;quot;) public String test(String param) { return param+\u0026amp;quot;123\u0026amp;quot;; } } 并通过 acts-config.properties 配置指明参数化组件使其生效，多个组件使用英文逗号 , 分隔，末尾注意不必要的空格。\nparam_components=IdGenerateComponent,NoGenerateComponent 如上图 alis_value 值为 @test?param=123 则在用例运行时会自动替换 alis_value 的取值。\n组件的 ID 要保证唯一，否则默认调用第一个，如果声明了一个无参组件方法，调用方式为 @test 即可，同时支持组件化参数通过变量传入：@test?param=$id，实际执行时会替换 $id 的值为实际值。\n脚本中也可以通过代码调用：\nActsComponentUtil.run(\u0026amp;quot;@test?param=123\u0026amp;quot;); 自定义组件多个参数的场景使用 \u0026amp;amp; 分割参数，如 @test?param1=xxx\u0026amp;amp;param2=yyy\nDB 工具类 1. 指定数据源进行 DB 表访问 框架 ActsDBUtils 中提供了 DB 的指定数据源访问，用于个性化 DB 操作。例如某张表的某条纪录不是准备数据也不是校验数据，但是需要在运行后删掉或更新，此时就需要用到该工具操作 DB 数据。\n使用前配置\n使用指定数据源方式需要在 acts-config.properties 文件中首先将要指定的数据源进行配置，配置例子如下：\ndatasource_bean_name_exampleDataSource=com.alipay.example.dal;exampleDataSource #整体配置的格式为：datasource_bean_name_xxx(数据源名字)=yyy(数据源所在 Module);xxx(数据源名字) 指定数据源方法\nActsDBUtils 工具类中指定数据源方法说明：\npublic static int getUpdateResultMap(String sql,String tableName,String dbConfigKey); 该方法用于指定数据源进行表的增、删和改的操作。sql 为标准 sql 语句，tableName 为逻辑表名，dbConfigKey 为该 表所在的逻辑数据源配置，与 acts-config.properties 配置的 xxx（数据源名字）相同。\npublic static List\u0026amp;lt;Map\u0026amp;lt;String, Object\u0026amp;gt;\u0026amp;gt; getQueryResultMap(String sql, String tableName,String dbConfigKey); 该方法用于指定数据源进行表的查询操作，以上两个方法都是原子化的 DB 表的操作，如果有其他的 DB 需求可以在上面进行 封装。\n2. 不指定数据源进行 DB 表访问 该方式下 ACTS 框架默认根据表名搜索数据源，工具方法的使用步骤如下：\n使用前配置\ndatasource_bundle_name=com.alipay.example.common.dal ds_exampleDataSource=table1,tabal2 #整体配置的格式为 #datasource_bundle_name=数据源所在模块名 #ds_数据源名字=该数据源下的逻辑表名 不指定数据源方法\npublic static int getUpdateResultMap(String …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-api/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ce7e264713a6f7a3f0672e2432489f59","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-api/","summary":"自定义引擎各个阶段 可以在测试脚本中或者基类中重写 ActsTestBase 提供的 API。 重写 prepare，execute，check，clear 等。可以通过在 super.prepare() 之","tags":null,"title":"扩展功能","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-api/","wordcount":1955},{"author":null,"categories":null,"content":" ExtensionLoader 为了对 SOFARPC 各个环节的都有充足的可扩展性，SOFA-RPC定义了一套十分灵活的扩展机制，所有扩展实现都是平等的。\n这套机制不管是对SOFA-RPC本身的开发者其使用者而言都是非常有用的。SOFA-RPC将其自身抽象为了多个模块，各个模块之间无显示依赖，通过SPI的方式进行交互。\n这套扩展机制抽象了这一SPI的交互方式。如果你读了上面文档讲到的 Filter 和 Router，应该已经有所体会。\n这里讲一下如何使方式进行扩展的。\nSOFARPC 提供了 ExtensionLoader 的能力。\n扩展点设计 SOFARPC 定义了一个注解 @Extensible，该注解标识在接口或者抽象类上，标识该类是一个扩展点。即告诉 SOFARPC 该类是可扩展的，需要寻找该扩展点的实现，同时也定义了寻找实现类的文件名称，是否单例。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * 指定自定义扩展文件名称，默认就是全类名 * * @return 自定义扩展文件名称 */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * 扩展类是否使用单例，默认使用 * * @return 是否使用单例 */ boolean singleton() default true; /** * 扩展类是否需要编码，默认不需要 * * @return 是否需要编码 */ boolean coded() default false; } SOFARPC 同时定义了 @Extension 注解，标识该类是一个扩展实现类。也定义了扩展点在文件中寻找扩展实现时使用的名字。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * 扩展点名字 * * @return 扩展点名字 */ String value(); /** * 扩展点编码，默认不需要，当接口需要编码的时候需要 * * @return 扩展点编码 * @see Extensible#coded() */ byte code() default -1; /** * 优先级排序，默认不需要，大的优先级高 * * @return 排序 */ int order() default 0; /** * 是否覆盖其它低{@link #order()}的同名扩展 * * @return 是否覆盖其它低排序的同名扩展 * @since 5.2.0 */ boolean override() default false; /** * 排斥其它扩展，可以排斥掉其它低{@link #order()}的扩展 * * @return 排斥其它扩展 * @since 5.2.0 */ String[] rejection() default {}; } 新增扩展点 1.定义扩展点。\n@Extensible public interface Person { void getName(); } 2.定义扩展实现\n@Extension(\u0026amp;quot;A\u0026amp;quot;) public class PersonA implements Person{ @Override public void getName() { System.out.println(\u0026amp;quot;li wei\u0026amp;quot;); } } 3.编写扩展描述文件：META-INF/services/sofa-rpc/com.alipay.sofa.rpc.extension.Person。文件内容如下：\nA=com.alipay.sofa.rpc.extension.PersonA 4.加载扩展点，获取到扩展实现类使用。\nPerson person = ExtensionLoaderFactory.getExtensionLoader(Person.class).getExtension(\u0026amp;quot;A\u0026amp;quot;); 已有扩展点 如果想对 SOFARPC 的各个内置扩展点进行功能扩展，可直接实现已有扩展，配置扩展模式文件即可。\n目前已有的扩展点如下：\n 接口名 中文名 备注 内置实现 com.alipay.sofa.rpc.client.Client 客户端 Failover、Failfast com.alipay.sofa.rpc.client.ConnectionHolder 连接管理器 AllConnect（全部连接） com.alipay.sofa.rpc.client.AddressHolder 地址管理器 单组、多组 com.alipay.sofa.rpc.client.LoadBalancer 负载均衡 随机、轮询、最少并发、一致性hash、本机优先 com.alipay.sofa.rpc.client.Router 路由器 com.alipay.sofa.rpc.codec.Compressor 压缩 snappy、quicklz com.alipay.sofa.rpc.codec.Serializer 序列化器 java、hessian、pb com.alipay.sofa.rpc.filter.Filter 拦截器 com.alipay.sofa.rpc.protocol.Protocol 协议 bolt、dubbo、rest com.alipay.sofa.rpc.protocol.ProtocolDecoder 协议解码 bolt com.alipay.sofa.rpc.protocol.ProtocolEncoder 协议编码 bolt com.alipay.sofa.rpc.protocol.TelnetHandler telnet的响应 version、help、ls com.alipay.sofa.rpc.proxy.Proxy 代理类 java、javassist com.alipay.sofa.rpc.registry.Registry 注册中心 zookeeper com.alipay.sofa.rpc.server.Server 服务端实现 bolt、rest com.alipay.sofa.rpc.transport.ClientTransport 客户端长连接实现 netty com.alipay.sofa.rpc.transport.ServerTransport 服务端长连接实现 netty ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/extension-loader/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"acc5628da3a7ea2df5eb68bd8ec17159","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/extension-loader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/extension-loader/","summary":"ExtensionLoader 为了对 SOFARPC 各个环节的都有充足的可扩展性，SOFA-RPC定义了一套十分灵活的扩展机制，所有扩展实现都是平等的。 这套机制不管是对SOFA-RP","tags":null,"title":"扩展点设计","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/extension-loader/","wordcount":1131},{"author":null,"categories":null,"content":" SOFARPC 的服务发布和引用的基本配置已经在「编程界面」章节中说明，这里主要介绍服务发布和引用的一些特性。\n同一服务发布多种协议 在 SOFARPC 中，可以将同一个服务发布成多个协议，让调用端可以使用不同的协议调用服务提供方。\n如果使用 Java API，可以按照如下的代码构建多个 ServerConfig，不同的 ServerConfig 设置不同的协议，然后将这些 ServerConfig 设置给 ProviderConfig：\nServerConfig serverConfigA = new ServerConfig(); ServerConfig serverConfigB = new ServerConfig(); List\u0026amp;lt;ServerConfig\u0026amp;gt; serverConfigs = new ArrayList\u0026amp;lt;ServerConfig\u0026amp;gt;(); serverConfigs.add(serverConfigA); serverConfigs.add(serverConfigB); providerConfig.setServer(serverConfigs); 如果使用 XML 的方式，直接在 \u0026amp;lt;sofa:service\u0026amp;gt; 标签中增加多个 binding 即可：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 如果使用 Annotation 的方式，在 @SofaService 中增加多个 binding 即可：\n@SofaService( interfaceType = SampleService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;), @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) } ) public class SampleServiceImpl implements SampleService { // ... } 同一服务注册多个注册中心 如果使用 API 的方式，构建多个 RegistryConfig 设置给 ProviderConfig 即可：\nRegistryConfig registryA = new RegistryConfig(); RegistryConfig registryB = new RegistryConfig(); List\u0026amp;lt;RegistryConfig\u0026amp;gt; registryConfigs = new ArrayList\u0026amp;lt;RegistryConfig\u0026amp;gt;(); registryConfigs.add(registryA); registryConfigs.add(registryB); providerConfig.setRegistry(registryConfigs); 如果是使用 XML 的方式\n需要在properties里配置注册中心\ncom.alipay.sofa.rpc.registries.zookeeper=zookeeper://127.0.0.1:2181 com.alipay.sofa.rpc.registries.nacos=nacos://127.0.0.1:8848 \u0026amp;lt;bean id=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacadeImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;nacos,zookeeper\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 如果使用 Annotation 的方式\n需要在properties里配置注册中心\ncom.alipay.sofa.rpc.registries.zookeeper=zookeeper://127.0.0.1:2181 com.alipay.sofa.rpc.registries.nacos=nacos://127.0.0.1:8848 @SofaService(bindings = {@SofaServiceBinding(registry = \u0026amp;quot;nacos\u0026amp;quot;), @SofaServiceBinding(registry = \u0026amp;quot;zookeeper\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { // ... } 方法级参数设置 在 Java API 方式中，调用 MethodConfig 对象相应的 set 方法即可设置对应的参数，如下所示：\nMethodConfig methodConfigA = new MethodConfig(); MethodConfig methodConfigB = new MethodConfig(); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfigA); methodConfigs.add(methodConfigB); providerConfig.setMethods(methodConfigs); //服务端设置 consumerConfig.setMethods(methodConfigs); //客户端设置 使用 XML 的方式，在对应的 binding 里面使用 \u0026amp;lt;sofa:method\u0026amp;gt; 标签即可设置对应的参数：\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/publish-and-reference/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6a78b8b84b226eaf1e6d2b1ff1d15fee","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/publish-and-reference/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/publish-and-reference/","summary":"SOFARPC 的服务发布和引用的基本配置已经在「编程界面」章节中说明，这里主要介绍服务发布和引用的一些特性。 同一服务发布多种协议 在 SOFARPC 中，可以将同一个服务","tags":null,"title":"服务发布与引用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/publish-and-reference/","wordcount":699},{"author":null,"categories":null,"content":" 自动化 推荐版本: ES 5\n自动初始化库 Lookout 服务器端启动时，会自动检查（默认开启，可关闭）所连接的ES机器(或集群)，检查 Metrics 数据存储的 Index和 Mapping 是否已经建立， 如果未初始化则进行初始化工作。默认初始化并产生索引alias: \u0026amp;ldquo;lookout-active-metrics，lookout-search-metrics\u0026amp;rdquo;。\n 看下 Alias 和 Indices\nhttp://localhost:9200/_cat/aliases lookout-active-metrics metrics-2019.05.30-1 - - - lookout-search-metrics metrics-2019.05.30-1 - - - 看下存储 Mapping：\nhttp://localhost:9200/lookout-active-metrics/_mapping { \u0026amp;quot;metrics-2019.05.30-1\u0026amp;quot;: { \u0026amp;quot;mappings\u0026amp;quot;: { \u0026amp;quot;metrics\u0026amp;quot;: { \u0026amp;quot;properties\u0026amp;quot;: { \u0026amp;quot;id\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;keyword\u0026amp;quot; }, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;keyword\u0026amp;quot; }, \u0026amp;quot;time\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;date\u0026amp;quot; }, \u0026amp;quot;value\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;float\u0026amp;quot; } } } } } } 自动运维 自动 Indices Rollover\n 如果超过1天，则切换新索引 如果单个索引的 docs 数目超过: 100000000，则切换新索引； 自动删除过期 Indices\n 默认最多只保留 7 天的数据，过期的 Index 会自动检查并被删除；\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-es/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"016a397aa24e885b5aaa32cf1cac3f35","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-es/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-es/","summary":"自动化 推荐版本: ES 5 自动初始化库 Lookout 服务器端启动时，会自动检查（默认开启，可关闭）所连接的ES机器(或集群)，检查 Metrics 数据存储的 Index和 Mapping 是","tags":null,"title":"服务器端 ES 存储使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-es/","wordcount":315},{"author":null,"categories":null,"content":"由于 SOFALookout Metrics Server 兼容 Prometheus API,所以 Grafana 集成 Lookout 很简单，只需要选择 Prometheus 作为数据源协议即可 （注意 Lookout Server 的默认查询端口也是: 9090）。\n下图展示 Grafana 新增数据源配置:\n使用 PromQL 查询展示数据:\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-grafana/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"45b8a5084ac2a151af28ff11413b13cb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","summary":"由于 SOFALookout Metrics Server 兼容 Prometheus API,所以 Grafana 集成 Lookout 很简单，只需要选择 Prometheus 作为数据源协议即可 （注意 Lookout Server 的默认查询端口也是: 9090）。 下图展示 Grafana 新增数据源配置","tags":null,"title":"服务器端 Grafana 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","wordcount":81},{"author":null,"categories":null,"content":" 如果需要扩展支持适配一个新的数据存储，可能需要下面的步骤:\n1.写入适配 需要在 gateway/metrics/exporter/ 下面添加新的 exporter; 参考已有的 \u0026amp;ldquo;gateway/metrics/exporter/elasticsearch\u0026amp;rdquo; 模块；\n 提供个新存储的 MetricExporter 功能是写入数据到存储中，参考\u0026amp;rdquo;com.alipay.sofa.lookout.gateway.metrics.exporter.es.ESMetricExporter\u0026amp;rdquo;，提供个新存储的 MetricExporter；\n 提供个该模块的spring配置类 参考 \u0026amp;ldquo;com.alipay.sofa.lookout.gateway.metrics.exporter.es.spring.bean.config.EsExporterConfiguration\u0026amp;rdquo;，它包括 ESProperties 的配置描述映射。尤其重要的是带有注解 @ConditionalOnExporterComponent方便该功能开关；\n 在 \u0026amp;ldquo;com.alipay.sofa.lookout.gateway.metrics.starter.MetricPipelineConfiguration\u0026amp;rdquo; 中 @import 上述存储spring配置类； 2.查询数据适配 需要在 server/metrics 目录下，添加新 storage 扩展； 参考 “server/metrics/storage-ext-es” 模块，比如新增“storage-ext-**”\n 提供个新的存储 Storage 实现； 参考已有 “com.alipay.sofa.lookout.server.storage.ext.es.ElasticSearchStorage”，实现Storage接口。这里也需要ES实现对应的 “QueryStmt”，”LabelValuesStmt“，”LabelNamesStmt“.\n 提供个该模块的spring配置类 参考\u0026amp;rdquo;com.alipay.sofa.lookout.server.storage.ext.es.spring.bean.config.ElasticSearchServerConfig\u0026amp;rdquo;,提供 Storage的实例。 另外参考支持”@ConditionalOnProperty“的功能开关配置；\n 在 \u0026amp;ldquo;com.alipay.sofa.lookout.server.starter.ServerAutoConfiguration\u0026amp;rdquo; 中 @import 上述存储spring配置类； 3.最后贡献建议 提issue说明需求，并可以介绍下方案； 保证测试覆盖； fork 代码，编译通过后，提交 PR； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-storage-ext/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b990dad82668bc22c24d4ad0468f0535","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","summary":"如果需要扩展支持适配一个新的数据存储，可能需要下面的步骤: 1.写入适配 需要在 gateway/metrics/exporter/ 下面添加新的 exporter; 参考已有的 \u0026ldquo;gateway/metrics/exporter/elasticsearch\u0026rdquo; 模块； 提供个新存储的 MetricExporter 功能是写入数据","tags":null,"title":"服务器端 Metrics 存储扩展机制","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","wordcount":864},{"author":null,"categories":null,"content":" 1. Tag选择器的“in”筛选 =~| 将tag符合表达式的提供的值选择出来，类似于SQL中的in语义\n示例\n将app为 foo 或 foo2的应用时序数据查询出来\njvm.memory.heap.used{app=~|\u0026amp;quot;foo|foo2\u0026amp;quot;,instance_id=\u0026amp;quot;xxx\u0026amp;quot;} 2. Tag选择器的\u0026amp;rdquo;not in\u0026amp;rdquo;筛选 !~| 将tag不符合表达式提供的值选择出来,类似SQL中的not in语义\n示例\njvm.memory.heap.used{app!~|\u0026amp;quot;foo|foo2\u0026amp;quot;,instance_id=\u0026amp;quot;xxx\u0026amp;quot;} 3. Increase2函数 （类似Increase），适用于Promethues的Counter型指标 increase 会根据根据查询步长，做个时间点上的函数估值（根据既有增长斜率）。所以可能是非整型。 如果你就想返回真实时间点的整数差值，不愿估算目标时刻的近视值。那么推荐使用 Increase2。\n需要组合聚合函数时，记住“Rate then sum, never sum then rate”（这里说的rate 与 increase 函数类似）\nsum by (job)(Increase2(http_requests_total{job=\u0026amp;quot;node\u0026amp;quot;}[5m])) # This is okay 4. \u0026amp;ldquo;histogram_quantile\u0026amp;rdquo; 与(Lookout)自定义 \u0026amp;ldquo;zhistogram_quantile\u0026amp;rdquo; histogram_quantile ，是对使用prometheus client得到的 metrics buckets进行分析；\nzhistogram_quantile，是对使用 lookout sdk的得到的 metrics buckets 进行分析;\n5. Promethues 一些最佳实践总结 rate，increase 函数用于计算指标的速率，在使用时要根据指标数据的采集或上报时间间隔来进行over_time时间的控制。比如metrics数据是1分钟上报一次,如果想获取某个metric指标的1分钟的速率，应该按如下方式写promql语句\nrate(http_requestl{token=\u0026amp;quot;mobile\u0026amp;quot;}[2m] step 表示最终显示的采样（步长），如果和range （比如2m）保持一致，表示原样输出，不采样。 如果想进行采样，step \u0026amp;gt; range 就行了！ 所以总的来说，step \u0026amp;gt;= range.\nrange, 从实际使角度，推荐 range 值要尽量明显大于数据实际的上报时间间隔才有意义，比如上报单位是30秒，那range尽量\u0026amp;gt;= 1分钟。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-promql-feature-enhancement/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3bd5cd1f9d3ce3f9ba5b503ef0ba9da1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","summary":"1. Tag选择器的“in”筛选 =~| 将tag符合表达式的提供的值选择出来，类似于SQL中的in语义 示例 将app为 foo 或 foo2的应用时序数据查询出来","tags":null,"title":"服务器端 PromQL 语法特性增强","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","wordcount":691},{"author":null,"categories":null,"content":" 使用 Lookout sdk是推荐方式，当然 Lookout gateway 还支持其他协议上报。（但由于属于非标接入，细节可联系我们）\n注意如果使用 非lookout sdk ，自己一定注意控制客户端metrics数量！ [Don\u0026amp;rsquo;t over use labels(tags)]\n1.Promethues Push协议写入支持 Lookout-gateway这里扮演的是一个 prometheus-pushgateway 角色：\necho \u0026amp;quot;some_metric{k1=\u0026amp;quot;v1\u0026amp;quot;} 3.14\u0026amp;quot; | curl --data-binary \\ @- http://localhost:7200/prom/metrics/job/{job}/app/{app}/step/{step} 区别在于：\u0026amp;rdquo;http://localhost:7200/prom/\u0026amp;ldquo;，端口为7200，加了级主路径为/prom.\n 【必选】URL路径变量 {app} {job} 和{step}，必须要指定哦。step 单位秒，表示您定时上报的时间间隔（假如10s 上报一次数据，那么 step=10）\n 【可选】如果和lookout gateway间有网络代理，建议URL 里也附带上客户端真实 ip （如 \u0026amp;ldquo;/ip/{ip}\u0026amp;ldquo;）。\n 上报格式样式: 【 http_requests_total{method=\u0026amp;ldquo;post\u0026amp;rdquo;,code=\u0026amp;ldquo;200\u0026amp;rdquo;} 1027 】，多个以换行符【\u0026amp;rsquo;\\n\u0026amp;rsquo;】分割；\n 更多细节可以参考：prometheus-pushgateway ，你可以选择官方对应编程语言的SDKs\n 2. Lookout 自有协议写入支持 默认的收集服务和数据协议标准(即Lookout自有的协议支持标准)\n localhost:7200/lookout/metrics/app/{app}/step/{step}\ncurl -H \u0026amp;quot;Content-type:text/plain\u0026amp;quot; -X POST -d \u0026#39;xx\u0026#39; \\ localhost:7200/lookout/metrics/app/{app}/step/{step} 请求体是一种批量复合形式。内容是多条 metrics 数据以 \u0026amp;ldquo;\\t\u0026amp;rdquo; 进行连接；\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;count\u0026amp;quot;:0,\u0026amp;quot;rate\u0026amp;quot;:0.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;value\u0026amp;quot;:99.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;elapPerExec\u0026amp;quot;:0.0,\u0026amp;quot;totalTime\u0026amp;quot;:0.0,\u0026amp;quot;max\u0026amp;quot;:0.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;totalAmount\u0026amp;quot;:0.0,\u0026amp;quot;rate\u0026amp;quot;:0.0,\u0026amp;quot;max\u0026amp;quot;:0}} 上面内容中组成部分分别是：counter型,gauge型,Timer型\n 其中单条数据结构\n{ \u0026amp;quot;time\u0026amp;quot;: \u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;k1\u0026amp;quot;: \u0026amp;quot;v1\u0026amp;quot; }, \u0026amp;quot;m_name\u0026amp;quot;: { \u0026amp;quot;count\u0026amp;quot;: 0, \u0026amp;quot;rate\u0026amp;quot;: 0 } } tag 的 value 需要转义;\n 如果内容由进行了 snappy 压缩，需添加请求头 \u0026amp;ldquo;Content-Encoding:snappy\u0026amp;rdquo;,且\u0026amp;rdquo;Content-type: application/octet-stream\u0026amp;rdquo;;\n 3.OPEN TSDB 协议写入支持 请求demo\ncurl -X POST \\ http://localhost:7200/opentsdb/api/put \\ -H \u0026#39;Content-Type: application/json\u0026#39; \\ -H \u0026#39;step: 10000\u0026#39; \\ -H \u0026#39;app: xx\u0026#39; \\ -H \u0026#39;X-Lookout-Token: xx\u0026#39; \\ -d \u0026#39;[{ \u0026amp;quot;metric\u0026amp;quot;: \u0026amp;quot;xzc.cpu\u0026amp;quot;, \u0026amp;quot;timestamp\u0026amp;quot;: 1530624430, \u0026amp;quot;value\u0026amp;quot;: 30, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;host\u0026amp;quot;: \u0026amp;quot;web02\u0026amp;quot;, \u0026amp;quot;dc\u0026amp;quot;: \u0026amp;quot;lga\u0026amp;quot; } }]\u0026#39; 注意timestamp的单位是秒(而且尽量是当前时间附近哦，否则不太好查询)\n post的内容可以是一个json对象或json数组(批量模式)\n 更多细节可以参考 OpenTSDB的 /api/put 接口 http://opentsdb.net/docs/build/html/api_http/put.html\n 4.Metricbeat 写入协议支持 （1）.metricbeat的配置 配置文件 metricbeat.yml\noutput.elasticsearch: hosts: [\u0026#39;10.15.232.67:7200\u0026#39;] path: /beat host 是 lookout-gateway 的地址,端口是7200. 另外加了级主路径/beat;\n(2).为了符合metrics2.0标准，gateway会对数据进行转换 这块后续去时序库查询，你需要关注：\n FROM:\n{ \u0026amp;quot;@timestamp\u0026amp;quot;: \u0026amp;quot;2018-03-29T08:27:21.200Z\u0026amp;quot;, …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-other-metrics-protocol-support/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"df745d82f3f681cfd94b8187934a8477","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","summary":"使用 Lookout sdk是推荐方式，当然 Lookout gateway 还支持其他协议上报。（但由于属于非标接入，细节可联系我们） 注意如果使用 非lookout sdk ，自己一定注意控制客","tags":null,"title":"服务器端常见数据采集协议支持","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","wordcount":1013},{"author":null,"categories":null,"content":" SOFADashboard 服务治理主要是对 SOFARpc 的服务进行管理。 目前已经支持基于 ZK 和 SofaRegistry 两个注册中心。\n功能展示 1、基于服务维度 服务列表 服务提供者详情： 2、基于应用维度 应用列表 应用服务详情 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/governance/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e547baf489fd5d125be9e67a366854b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/governance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/governance/","summary":"SOFADashboard 服务治理主要是对 SOFARpc 的服务进行管理。 目前已经支持基于 ZK 和 SofaRegistry 两个注册中心。 功能展示 1、基于服务维度 服务列表 服务提供者详情： 2、基于应用维度 应用","tags":null,"title":"服务治理","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/governance/","wordcount":78},{"author":null,"categories":null,"content":" 本地开发 在本地启动 SOFARegistry 是使用的H2 database 作为注册中心使用的配置数据库, 可以直接启动\ncom.alipay.sofa.registry.server.integration.RegistryApplication#main\n默认会使用 application-dev.properties 作为配置文件\n部署模式 SOFARegistry 部署依赖 mysql, 使用 mysql 作为注册中心自身的元数据存储。\n支持两种部署模式，分别是集成部署模式及独立部署模式，本文将介绍最简单的单节点集成部署模式，更多更详细的部署模式介绍可以查看 部署文档。\n部署步骤 1.下载源码或者安装包 下载源码方式 git clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Pserver-release -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all 下载安装包方式 您可以从 release 页面 下载最新的 registry-all.tgz 包 。\n建议下载 v6 以上版本\ntar -zxvf registry-all.tgz cd registry-all 2.启动 registry-integration 2.1 如果是本地启动开发注册中心, 可以使用 h2 作为数据库\nIDEA 源码启动: 运行 com.alipay.sofa.registry.server.integration.RegistryApplication#main\nfat jar 脚本启动命令: sh bin/integration/start_dev.sh\n2.2 正式环境建议使用 mysql\n创建 database 和 table\necho \u0026amp;quot;create database registrymetadb \u0026amp;quot; | mysql -u username -p mysql -u username -p registrymetadb \u0026amp;lt; create_table.sql 修改 conf/application.properties 中的配置，数据库密码也可以通过 JDBC_PASSWORD 环境变量传入\n启动命令: sh bin/integration/start.sh\n3.确认运行状态 可访问三个角色提供的健康监测 API，或查看日志 logs/registry-startup.log：\n# 查看meta角色的健康检测接口： $ curl http://localhost:9615/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} # 查看data角色的健康检测接口： $ curl http://localhost:9622/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... status:WORKING\u0026amp;quot;} # 查看session角色的健康检测接口： $ curl http://localhost:9603/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-registry/server-quick-start/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b620900b56ba04f4668838846a97698a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/server-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/server-quick-start/","summary":"本地开发 在本地启动 SOFARegistry 是使用的H2 database 作为注册中心使用的配置数据库, 可以直接启动 com.alipay.sofa.registry.server.integration.RegistryApplication#main 默认会使用 application-dev.properties 作为配置文件 部署模式 SOFARegistry 部署依赖 mysql, 使用 mysql 作为注册中心","tags":null,"title":"服务端部署","type":"projects","url":"/sofastack.tech/projects/sofa-registry/server-quick-start/","wordcount":460},{"author":null,"categories":null,"content":" 如图: Node Raft 分组中的一个节点，连接封装底层的所有服务，用户看到的主要服务接口，特别是 apply(task) 用于向 raft group 组成的复制状态机集群提交新任务应用到业务状态机。\n存储 Log 存储，记录 raft 配置变更和用户提交任务的日志，将从 Leader 复制到其他节点上。LogStorage 是存储实现， LogManager 负责对底层存储的调用，对调用做缓存、批量提交、必要的检查和优化。 Meta 存储，元信息存储,记录 raft 实现的内部状态，比如当前 term,、投票给哪个节点等信息。 Snapshot 存储,，用于存放用户的状态机 snapshot 及元信息，可选。 SnapshotStorage 用于 snapshot 存储实现， SnapshotExecutor 用于 snapshot 实际存储、远程安装、复制的管理。 状态机 StateMachine： 用户核心逻辑的实现,核心是 onApply(Iterator) 方法，应用通过 Node#apply(task) 提交的日志到业务状态机。 FSMCaller： 封装对业务 StateMachine 的状态转换的调用以及日志的写入等，一个有限状态机的实现，做必要的检查、请求合并提交和并发处理等。 复制 Replicator： 用于 leader 向 follower 复制日志，也就是 raft 中的 appendEntries 调用，包括心跳存活检查等。 ReplicatorGroup: 用于单个 RAFT Group 管理所有的 replicator，必要的权限检查和派发。 RPC RPC 模块用于节点之间的网络通讯: 1. RPC Server: 内置于 Node 内的 RPC 服务器，接收其他节点或者客户端发过来的请求，转交给对应服务处理。 2. RPC Client: 用于向其他节点发起请求，例如投票、复制日志、心跳等。\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/engine-architecture/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d2cc9de133aed20695229d0cde5b6ff9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/engine-architecture/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-jraft/engine-architecture/","summary":"如图: Node Raft 分组中的一个节点，连接封装底层的所有服务，用户看到的主要服务接口，特别是 apply(task) 用于向 raft group 组成的复制状态机集群提交新任务应用到业务状态机","tags":null,"title":"核心引擎设计","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/engine-architecture/","wordcount":529},{"author":null,"categories":null,"content":" MOSN 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 xDS 等云原生能力。\nxDS（UDPA）支持 MOSN 支持云原生统一数据面 API（UDPA），支持全动态配置更新。\nxDS 是 Envoy 创建的一个关键概念，它是一类发现服务的统称，其包括如下几类：\n CDS：Cluster Discovery Service EDS：Endpoint Discovery Service SDS：Secret Discovery Service RDS：Route Discovery Service LDS：Listener Discovery Service 正是通过对 xDS 的请求来动态更新 Envoy 配置，另外还有个 ADS（Aggregated Discovery Service）通过聚合的方式解决以上 xDS 的更新顺序问题。\n业务支持 MOSN 作为底层的高性能安全网络代理，支撑了 RPC、消息（Messaging）、网关（Gateway）等业务场景。\nIO 模型 MOSN 支持以下两种 IO 模型：\n Golang 经典 netpoll 模型：goroutine-per-connection，适用于在连接数不是瓶颈的情况。\n RawEpoll 模型：也就是 Reactor 模式，I/O 多路复用（I/O multiplexing）+ 非阻塞 I/O（non-blocking I/O）的模式。对于接入层和网关有大量长链接的场景，更加适合于 RawEpoll 模型。\n netpoll 模型 MOSN 的 netpoll 模型如上图所示，协程数量与链接数量成正比，大量链接场景下，协程数量过多，存在以下开销：\n Stack 内存开销 Read buffer 开销 Runtime 调度开销 RawEpoll 模型 RawEpoll 模型如上图所示，使用 epoll 感知到可读事件之后，再从协程池中为其分配协程进行处理，步骤如下：\n 链接建立后，向 Epoll 注册 oneshot 可读事件监听；并且此时不允许有协程调用 conn.read，避免与 runtime netpoll 冲突。 可读事件到达，从 goroutine pool 挑选一个协程进行读事件处理；由于使用的是 oneshot 模式，该 fd 后续可读事件不会再触发。 请求处理过程中，协程调度与经典 netpoll 模式一致。 请求处理完成，将协程归还给协程池；同时将 fd 重现添加到 RawEpoll 中。 协程模型 MOSN 的协程模型如下图所示。\n 一条 TCP 连接对应一个 Read 协程，执行收包、协议解析； 一个请求对应一个 worker 协程，执行业务处理，proxy 和 Write 逻辑； 常规模型一个 TCP 连接将有 Read/Write 两个协程，我们取消了单独的 Write 协程，让 workerpool 工作协程代替，减少了调度延迟和内存占用。\n能力扩展 协议扩展 MOSN 通过使用统一的编解码引擎以及编/解码器核心接口，提供协议的 plugin 机制，包括支持：\n SOFARPC HTTP1.x/HTTP2.0 Dubbo NetworkFilter 扩展 MOSN 通过提供 network filter 注册机制以及统一的 packet read/write filter 接口，实现了 Network filter 扩展机制，当前支持：\n TCP proxy Fault injection StreamFilter 扩展 MOSN 通过提供 stream filter 注册机制以及统一的 stream send/receive filter 接口，实现了 Stream filter 扩展机制，包括支持：\n 流量镜像 RBAC 鉴权 TLS 安全链路 通过测试，原生的 Go 的 TLS 经过了大量的汇编优化，在性能上是 Nginx（OpenSSL）的80%，Boring 版本的 Go（使用 cgo 调用 BoringSSL）因为 cgo 的性能问题， 并不占优势，所以我们最后选择使用原生 Go 的 TLS，相信 Go Runtime 团队后续会有更多的优化，我们也会有一些优化计划。\nGo vs Nginx 测试结果如下图所示：\n Go 在 RSA 上没有太多优化，go-boring（CGO）的能力是 Go 的两倍。 p256 在 Go 上有汇编优化，ECDSA 优于go-boring。 在 AES-GCM 对称加密上，Go 的能力是 go-boring 的 20 倍。 在 SHA、MD 等 HASH 算法也有对应的汇编优化。 为了满足金融场景的安全合规，我们同时也对国产密码进行了开发支持，这个是 Go Runtime 所没有的。虽然目前的性能相比国际标准 AES-GCM 还是有一些差距，大概是 50%，但是我们已经有了后续的一些优化计划，敬请期待。\n支持国密的性能测试结果如下图所示：\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/core-concept/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5fd84bf5ceb2a4ab800cd0e2db774731","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/core-concept/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/concept/core-concept/","summary":"MOSN 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 xDS 等云原生能力。 xDS（UDPA）支持 MOSN 支持云原生统一数据面 API（UDPA），","tags":null,"title":"核心概念","type":"projects","url":"/sofastack.tech/projects/mosn/concept/core-concept/","wordcount":1332},{"author":null,"categories":null,"content":" 框架准备 在阅读前，您可以参考快速开始下载并安装 ACTS IDE 和引入 ACTS 框架.\n本部分主要包含编码说明、数据源配置和一键配置说明，以帮助您使用 ACTS 框架。\n编码说明 请确保 ACTS 的编码与系统代码的编码一致，即确定以下的编码保持一致：生成脚本选择的编码、workspace 的编码应该都与应用代码编码保持一致，不一致时会出现乱码问题。\n生成脚本选择的编码，如下图设置：\nIDEA workspace 的编码：\n数据源配置 ACTS 配置数据源的目的，是为了在数据准备、数据清理、数据校验阶段，能够使用系统的数据源正确的进行 DB 增删改查。\n数据源配置 在 src/test/resource/config/acts-config.properties 中配置 dal 层的 ModuleName、数据源以及表的对应关系，以 ds_ 开头，如下：\ndatasource_bundle_name =com.alipay.testapp.common.dal ds_bean1=table1,table2 ds_bean2=table3,table4 #配置格式 #ds_数据源bean=逻辑表名1,逻辑表名2 其中数据源 bean1、数据源 bean2 是应用代码中 dal 层的数据源 bean 的名称，支持多个数据源。表名支持正则表达式，无需带分库分表后缀，若有多个数据源时请注意，某张表只能属于一个数据源，如下图：\n数据库直连 数据库直连，用于 DB 数据模型的生成。在 src/test/resource/config/dbConf/ 下的 devdb.conf 或 testdb.conf 中配置如下：\nxxx_url = jdbc:oracle:thin:@localhost:1521:cifdb xxx_username = myname xxx_password = mypswd 一键配置的说明 一键配置测试框架主要生成包含两部分，一部分是基础 Java 类，另一类是必须的配置文件，具体生成内容如下：\nJava 类 AppNameActsBaseUtils.java\n测试脚本编写过程中常用的从框架中获取各种数据的工具类，初始化搭建只提供了常用的方法，可自行添加。\n AppNameActsTestBase.java\n封装后的应用测试基类，业务系统如有特殊需求可在其上自行封装，如果没有则可以忽略此文件。\n 配置文件 ","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ready/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c3a89cbf42d55c98206a08e94d05ffde","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-ready/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-ready/","summary":"框架准备 在阅读前，您可以参考快速开始下载并安装 ACTS IDE 和引入 ACTS 框架. 本部分主要包含编码说明、数据源配置和一键配置说明，以帮助您使用 ACTS 框架。 编码说","tags":null,"title":"框架准备","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-ready/","wordcount":593},{"author":null,"categories":null,"content":" SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力。为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式：\n 基于代码组织上的模块化：这是最常见的形式，在开发期，将不同功能的代码放在不同 Java 工程下，在编译期被打进不同 jar 包，在运行期，所有 Java 类都在一个 classpath 下，没做任何隔离； 基于 Spring 上下文隔离的模块化：借用 Spring 上下文来做不同功能模块的隔离，在开发期和编译期，代码和配置也会分在不同 Java 工程中，但在运行期，不同模块间的 Spring Bean 相互不可见，DI 只在同一个上下文内部发生，但是所有的 Java 类还是在同一个 ClassLoader 下； 基于 ClassLoader 隔离的模块化：借用 ClassLoader 来做隔离，每个模块都有独立的 ClassLoader，模块与模块之间的 classpath 不同，SOFAArk 就是这种模块化的实践方式。 SOFABoot 模块化开发属于第二种模块化形式 —— 基于 Spring 上下文隔离的模块化。每个 SOFABoot 模块使用独立的 Spring 上下文，避免不同 SOFABoot 模块间的 BeanId 冲突，有效降低企业级多模块开发时团队间的沟通成本。\n关于 SOFABoot 模块化产生的背景，可参考文章《蚂蚁金服的业务系统模块化 \u0026amp;mdash;- 模块化隔离方案》\n功能简介 依赖引入 使用 SOFABoot 模块化开发方案，需要引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;isle-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFABoot 模块 SOFABoot 框架定义了 SOFABoot 模块的概念，一个 SOFABoot 模块是一个包括 Java 代码、Spring 配置文件、SOFABoot 模块标识等信息的普通 Jar 包，一个 SOFABoot 应用可以包含多个 SOFABoot 模块，每个 SOFABoot 模块都含有独立的 Spring 上下文。\n以 SOFABoot 模块为单元的模块化方式为开发者提供了以下功能：\n 运行时，每个 SOFABoot 模块的 Spring 上下文是隔离的，模块间定义的 Bean 不会相互影响； 每个 SOFABoot 模块是功能完备且自包含的，可以很容易在不同的 SOFABoot 应用中进行模块迁移和复用，只需将 SOFABoot 模块整个拷贝过去，调整 Maven 依赖，即可运行。 SOFABoot 模块的格式定义见: 模块配置。\nSOFABoot 模块间通信 上下文隔离后，模块与模块间的 Bean 无法直接注入，模块间需要通过 SOFA 服务进行通信，目前SOFABoot 提供了两种形式的服务发布和引用，用于解决不同级别的模块间调用的问题：\n JVM 服务发布和引用：解决一个 SOFABoot 应用内部各个 SOFABoot 模块之间的调用问题， JVM 服务发布与引用 RPC 服务发布和引用：解决多个 SOFABoot 应用之间的远程调用问题，RPC 服务发布与引用。 模块并行化启动 每个 SOFABoot 模块都是独立的 Spring 上下文，多个 SOFABoot 模块支持并行化启动，与 Spring Boot 的单 Spring 上下文模式相比，模块并行化启动能够加快应用的启动速度。\nRoot Application Context SOFABoot 应用运行时，本身会产生一个 Spring Context，我们把它叫做 Root Application Context，它是每个 SOFABoot 模块创建的 Spring Context 的 Parent。这样设计的目的是为了保证每个 SOFABoot 模块的 Spring Context 都能发现 Root Application Context 中创建的 Bean，这样当应用新增 Starter 时，不仅 Root Application Context 能够使用 Starter 中新增的 Bean，每个 SOFABoot 模块的 Spring Context 也能使用这些 Bean。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/modular-development/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"95bc080787c3614bfa485d2f3cd0de4c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/modular-development/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/modular-development/","summary":"SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力。为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式： 基于代码组织上的模块化","tags":null,"title":"模块化开发概述","type":"projects","url":"/sofastack.tech/projects/sofa-boot/modular-development/","wordcount":1073},{"author":null,"categories":null,"content":"SOFABoot 会根据 Require-Module 计算模块依赖树，例如以下依赖树表示模块B 和模块C 依赖模块A，模块E 依赖模块D，模块F 依赖模块E：\n该依赖树会保证模块A 必定在模块B 和模块C 之前启动，模块D 在模块E 之前启动，模块E 在模块F 之前启动，但是依赖树没有定义模块B 与模块C，模块B、C与模块D、E、F之间的启动顺序，这几个模块之间可以串行启动，也可以并行启动。\nSOFABoot 默认会并行启动模块，在使用过程中，如果希望关闭并行启动，可以在 application.properties 中增加以下参数:\ncom.alipay.sofa.boot.module-start-up-parallel=false ","date":-62135596800,"description":"","dir":"projects/sofa-boot/parallel-start/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a6ef51b78d2a4f9af0debbc25ea45e8a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/parallel-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/parallel-start/","summary":"SOFABoot 会根据 Require-Module 计算模块依赖树，例如以下依赖树表示模块B 和模块C 依赖模块A，模块E 依赖模块D，模块F 依赖模块E： 该依赖树会保证模块A 必定在模块B 和","tags":null,"title":"模块并行化启动","type":"projects","url":"/sofastack.tech/projects/sofa-boot/parallel-start/","wordcount":204},{"author":null,"categories":null,"content":" SOFABoot 模块是一个普通的 Jar 包加上一些 SOFABoot 特有的配置，这些 SOFABoot 特有的配置，让一个 Jar 包能够被 SOFABoot 识别，使之具备模块化的能力。\n一个完整的 SOFABoot 模块和一个普通的 Jar 包有两点区别:\n SOFABoot 模块包含一份 sofa-module.properties 文件，这份文件里面定义了 SOFABoot 模块的名称以及模块之间的依赖关系。 SOFABoot 模块的 META-INF/spring 目录下，可以放置任意多的 Spring 配置文件，SOFABoot 会自动把它们作为本模块的 Spring 配置加载起来。 sofa-module.properties 文件详解 先来看一份完整的 sofa-module.properties 文件（src/main/resources 目录下）：\nModule-Name=com.alipay.test.biz.service.impl Spring-Parent=com.alipay.test.common.dal Require-Module=com.alipay.test.biz.shared Module-Profile=dev Module-Name Module-Name 是 SOFABoot 模块的名称，也是 SOFABoot 模块的唯一标示符。在一个 SOFABoot 应用中，一个 SOFABoot 模块的 Module-Name 必须和其他的 SOFABoot 模块的 Module-Name 不一样。需要注意的一点是，一个 SOFABoot 应用运行时的 SOFABoot 模块，不仅仅只包含本应用的模块，还包括依赖了其他应用的 SOFABoot 模块，确定是否唯一的时候需要把这些 SOFABoot 模块也考虑进去。\nRequire-Module Require-Module 用于定义模块之间的依赖顺序，值是以逗号分隔的 SOFABoot 模块名列表，比如上面的配置中，就表示本模块依赖于 com.alipay.test.biz.shared 模块。对于这种依赖关系的处理，SOFABoot 会将 com.alipay.test.biz.shared 模块在本模块之前启动，即com.alipay.test.biz.shared 模块将先启动 Spring 上下文。\n一般情况下，是不需要为模块定义 Require-Module 的，只有当模块的 Spring 上下文的启动依赖于另一个模块的 Spring 上下文的启动时，才需要定义 Require-Module。举一个例子，如果你在 A 模块中发布了一个 SOFA JVM Service。在 B 模块的某一个 Bean 的 init 方法里面，需要使用 SOFA Reference 调用这个 JVM Service。假设 B 模块在 A 模块之前启动了，那么 B 模块的 Bean 就会因为 A 模块的 JVM Service 没有发布而 init 失败，导致 Spring 上下文启动失败。这个时候，我们就可以使用 Require-Module 来强制 A 模块在 B 模块之前启动。\nSpring-Parent 在 SOFABoot 应用中，每一个 SOFABoot 模块都是一个独立的 Spring 上下文，并且这些 Spring 上下文之间是相互隔离的。虽然这样的模块化方式可以带来诸多好处，但是，在某些场景下还是会有一些不便，这个时候，你可以通过 Spring-Parent 来打通两个 SOFABoot 模块的 Spring 上下文。Spring-Parent 属性可以配置一个模块的名称，比如上面的配置中，就将 com.alipay.test.common.dal 的 Spring 上下文设置为当前模块的 Spring 上下文的父 Spring 上下文。\n由于 Spring 的限制，一个模块的 Spring-Parent 只能有一个模块\n关于 Spring 的父上下文的作用可以看 Spring 的 BeanFactory 的说明：http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/beans/factory/BeanFactory.html\nModule-Profile 支持 SOFABoot Profile 能力： SOFABoot Profile\nSpring 配置文件 SOFABoot 模块可以包含 Spring 配置文件，配置文件需要放置在 META-INF/spring 目录下，SOFABoot 启动时会自动扫描该目录，并把目录下所有 XML 文件作为本模块的 Spring 配置加载起来。在 Spring 配置文件中，我们可以定义 Bean、发布服务等等。\nSOFABoot 模块一般用于封装对外发布服务接口的具体实现，属于业务层，Controller 属于展现层内容，我们不建议也不支持在 SOFABoot 模块中定义 Controller 组件，Controller 组件相关定义请直接放在 Root Application Context。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-module/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2dbb8a536237f21afbee1e3f320b8193","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-module/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-module/","summary":"SOFABoot 模块是一个普通的 Jar 包加上一些 SOFABoot 特有的配置，这些 SOFABoot 特有的配置，让一个 Jar 包能够被 SOFABoot 识别，使之具备模块化的能力。 一个完整的 SOFABoot 模块和一个普通的 Jar 包","tags":null,"title":"模块配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-module/","wordcount":1194},{"author":null,"categories":null,"content":"如果你要扩展一个注册中心，我们先看下注册中心的抽象类。\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026amp;lt;ProviderConfig\u0026amp;gt; configs); public abstract List\u0026amp;lt;ProviderGroup\u0026amp;gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026amp;lt;ConsumerConfig\u0026amp;gt; configs); } 可以看到我们需要的主要接口。\n 启动注册中心客户端、维持连接 销毁注册中心客户端、释放资源 发布服务、缓存发布信息 取消发布服务、删除缓存 订阅服务列表、同步或者异步返回数据，有变化接收通知 取消订阅服务列表、删除缓存 其它\n 注册中心节点断连后，不影响本地调用 和一个注册中心节点断连后，可自己切换到其它注册中心节点 注册中心节点切换后，自动恢复注册和订阅信息 注册中心数据缓存到本地文件，就算连不上任何注册中心，服务提供者和服务调用者也能重启并正常调用 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-extension-guide/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c952ecbea16f7ae68ad095ab8baf0583","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","summary":"如果你要扩展一个注册中心，我们先看下注册中心的抽象类。 package com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026lt;ProviderConfig\u0026gt; configs); public abstract List\u0026lt;ProviderGroup\u0026gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public","tags":null,"title":"注册中心扩展指南","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","wordcount":290},{"author":null,"categories":null,"content":"SOFABoot RPC Starter 为用户提供多种注册中心选择和方便的配置。 目前 bolt ， rest ， dubbo 都支持 Zookeeper 作为注册中心。另外 bolt ， rest 支持本地文件系统作为注册中心，该种模式一般用于测试。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-usage/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5a1a4619c8ac4a9fc27b8576472aed9f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-usage/","summary":"SOFABoot RPC Starter 为用户提供多种注册中心选择和方便的配置。 目前 bolt ， rest ， dubbo 都支持 Zookeeper 作为注册中心。另外 bolt ， rest 支持本地文件系统作为注册中心，该种模式一般用于测","tags":null,"title":"注册中心选择","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-usage/","wordcount":72},{"author":null,"categories":null,"content":" 本文描述的是 MOSN 作为 Sidecar 使用时的流量劫持方案。\nMOSN 作为 Sidecar 和业务容器部署在同一个 Pod 中时，需要使得业务应用的 Inbound 和 Outbound 服务请求都能够经过 Sidecar 处理。区别于 Istio 社区使用 iptables 做流量透明劫持，MOSN 目前使用的是流量接管方案，并在积极探索适用于大规模流量下的透明劫持方案。\n流量接管 区别于 Istio 社区的 iptables 流量劫持方案，MOSN 使用的流量接管的方案如下：\n 假设服务端运行在 1.2.3.4 这台机器上，监听 20880 端口，首先服务端会向自己的 Sidecar 发起服务注册请求，告知 Sidecar 需要注册的服务以及 IP + 端口（1.2.3.4:20880） 服务端的 Sidecar 会向服务注册中心（如 SOFA Registry）发起服务注册请求，告知需要注册的服务以及 IP + 端口，不过这里需要注意的是注册上去的并不是业务应用的端口（20880），而是 Sidecar 自己监听的一个端口（例如：20881） 调用端向自己的 Sidecar 发起服务订阅请求，告知需要订阅的服务信息 调用端的 Sidecar 向调用端推送服务地址，这里需要注意的是推送的 IP 是本机，端口是调用端的 Sidecar 监听的端口（例如 20882） 调用端的 Sidecar 会向服务注册中心（如 SOFA Registry）发起服务订阅请求，告知需要订阅的服务信息； 服务注册中心（如 SOFA Registry）向调用端的 Sidecar 推送服务地址（1.2.3.4:20881） 服务调用过程 经过上述的服务发现过程，流量转发过程就显得非常自然了：\n 调用端拿到的服务端地址是 127.0.0.1:20882，所以就会向这个地址发起服务调用 调用端的 Sidecar 接收到请求后，通过解析请求头，可以得知具体要调用的服务信息，然后获取之前从服务注册中心返回的地址后就可以发起真实的调用（1.2.3.4:20881） 服务端的 Sidecar 接收到请求后，经过一系列处理，最终会把请求发送给服务端（127.0.0.1:20880） 透明劫持 上文通过在服务注册过程中把服务端地址替换成本机监听端口实现了轻量级的“流量劫持”，在存在注册中心，且调用端和服务端同时使用特定SDK的场景中可以很好的工作，如果不满足这两个条件，则无法流量劫持。为了降低对于应用程序的要求，需要引入透明劫持。\n使用 iptables 做流量劫持 iptables 通过 NAT 表的 redirect 动作执行流量重定向，通过 syn 包触发新建 nefilter 层的连接，后续报文到来时查找连接转换目的地址与端口。新建连接时同时会记录下原始目的地址，应用程序可以通过(SOL_IP、SO_ORIGINAL_DST)获取到真实的目的地址。\niptables 劫持原理如下图所示：\n使用 iptables 做流量劫持时存在的问题 目前 Istio 使用 iptables 实现透明劫持，主要存在以下三个问题： 1. 需要借助于 conntrack 模块实现连接跟踪，在连接数较多的情况下，会造成较大的消耗，同时可能会造成 track 表满的情况，为了避免这个问题，业内有关闭 conntrack 的做法，比如阿里巴巴就关闭了这个模块。 1. iptables 属于常用模块，全局生效，不能显式的禁止相关联的修改，可管控性比较差。 1. iptables 重定向流量本质上是通过 loopback 交换数据，outbond 流量将两次穿越协议栈，在大并发场景下会损失转发性能。\n上述几个问题并非在所有场景中都存在，比方说某些场景下，连接数并不多，且 NAT 表未被使用到的情况下，iptables 是一个满足要求的简单方案。为了适配更加广泛的场景，透明劫持需要解决上述三个问题。\n透明劫持方案优化 使用 tproxy 处理 inbound 流量\ntproxy 可以用于 inbound 流量的重定向，且无需改变报文中的目的 IP/端口，不需要执行连接跟踪，不会出现 conntrack 模块创建大量连接的问题。受限于内核版本，tproxy 应用于 outbound 存在一定缺陷。目前 Istio 支持通过 tproxy 处理 inbound 流量。\n使用 hook connect 处理 outbound 流量\n为了适配更多应用场景，outbound 方向通过 hook connect 来实现，实现原理如下：\n无论采用哪种透明劫持方案，均需要解决获取真实目的 IP/端口的问题，使用 iptables 方案通过 getsockopt 方式获取，tproxy 可以直接读取目的地址，通过修改调用接口，hook connect 方案读取方式类似于tproxy。\n实现透明劫持后，在内核版本满足要求（4.16以上）的前提下，通过 sockmap 可以缩短报文穿越路径，进而改善 outbound 方向的转发性能。\n总结 总结来看，如果应用程序通过注册中心发布/订阅服务时，可以结合注册中心劫持流量；在需要用到透明劫持的场景，如果性能压力不大，使用 iptables redirect 即可，大并发压力下使用 tproxy 与hook connect 结合的方案。\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/traffic-hijack/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5845d8478a48fcddc74f0b9d28ede2c2","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/traffic-hijack/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/concept/traffic-hijack/","summary":"本文描述的是 MOSN 作为 Sidecar 使用时的流量劫持方案。 MOSN 作为 Sidecar 和业务容器部署在同一个 Pod 中时，需要使得业务应用的 Inbound 和 Outbound 服务请求都能够经过 Sidecar 处理。区别于 Istio 社","tags":null,"title":"流量劫持","type":"projects","url":"/sofastack.tech/projects/mosn/concept/traffic-hijack/","wordcount":1671},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.1.2。\n参见: http://semver.org/lang/zh-CN/。\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 5.3.0，那么将会维护 5.2.x 的 bugfix 分支，而 5.1.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 5.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 5.3.0。 发布后拉起下一个版本，例如 5.3.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/version-release/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"604f113607e6815757f4d1907190c13c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/version-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/version-release/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.1.2。 参见: http://semver.org/lang/zh-CN/","tags":null,"title":"版本发布","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/version-release/","wordcount":315},{"author":null,"categories":null,"content":" 1.3.2 2020-06-19\n Bug Fixes 移除对 bolt address parser 的扩展，避免 check connection 返回结果不符合预期 SPI 组件 JRaftServiceLoader 改为延迟加载策略规避多余对象的创建 几个 corner case 修复，比如 replicate logs 如果比 appliedIndex（follower）更小，那么可以认为是成功的 关闭 Recyclers 时的 IndexOutOfBoundsException 问题修复 Features 抽象出网络通信层，增加 GRPC 实现并支持 Replication Pipeline，用户亦可自行对通信层进行其他实现的扩展 RheaKV 增加 reverseScan API 提供 Replicator 与 RPC 的线程池隔离，避免相互影响 read-index 线性一致读请求提供请求超时（timeout）配置 Breaking Changes 无 致谢（排名不分先后） @shibd @SteNicholas @killme2008 @zongtanghu 1.3.1 2020-04-17\n Bug Fixes 修复 bolt rpc callback 默认的任务饱和丢弃策略，改为抛出异常 修复 learner 启动晚于 leader 选举成功时无法复制日志的 bug Features multi raft group 之间共享 timer 和 scheduler 等较重的线程资源，优化 multi group 场景中的多余资源占用 提供 RPC adapter，用户可基于 SPI 扩展不同的 RPC 实现 正式提供稳定的 RocksDBSegmentLogStorage，适合 value 较大的数据存储 sofa-bolt 升级到 1.6.1，支持 SSL 以及具有更好的小数据包传输能力 引入一个新的数据结构 segment list 来解决 LogManager 中过多的 log memory copy 采纳 nacos 的建议，对 raft Task 增加 join API Breaking Changes 无 致谢（排名不分先后） @jovany-wang @SteNicholas @zongtanghu @OpenOpened 1.3.0 2019-11-29\n Bug Fixes 删除数据并重启且期间没有新的 task 提交的情况下 prev log index 紊乱的修复 修复一些选举和线性一致读相关的 corner case Recyclers 多个线程 recycle 资源时的 NPE 修复 Features 新增 Read-only member(learner) 角色，支持 learner 节点上的线性一致读 实现优先级选举 在 multi raft group 的场景中，随机打散每个 group 的第一次 snapshot timeout 时间，避免一个进程内多个 group 同时 snapshot RheaKV 新增 containsKey API RheaKV 实现 snapshot checksum 以及异步 snapshot 新增 replicator 的 state 监听器： ReplicatorStateListener RepeatedTimer 的默认实现替换为 HashedWheelTimer 修复 windows 上定时器 CPU 消耗偏高的问题 kill -s SIGUSR2 pid 中增加打印 rocksdb stats 和所有 ThreadPool 指标统计信息 升级 rocksdb 版本到 5.18.3 新增实验性质的 RocksDBSegmentLogStorage，适合 value 较大的数据存储 Counter 例子改进，演示 ReadIndex 线性一致读 当优化 checksum 中多余的 mem copy Breaking Changes 无 致谢（排名不分先后） @zongtanghu @devYun @masaimu @SteNicholas @yetingsky 1.2.6 2019-08-15\n Bug Fixes 修复 ReadIndex 并发情况下可能出现的读超时 保存 raft meta 失败后终止状态机 修复 windows 环境中无法原子 move 文件的问题 当 RheaKV apply 失败时终止状态机避免出现数据不一致情况 Features 增加 LogEntry checksum validation 优化 log replication 线程模型减少锁竞争 优化 RheaKV multi group snapshot 对于 multi-raft-group 场景，提供 manual rebalance API 在无 PD 模式手动平衡各节点 leader 数量 CliService 提供获取存活 follower 节点的 API 引入 SPI 扩展机制，LogStorage、SnapshotStorage、RaftMetaStorage、LogEntryCodec 均可基于 SPI 扩展 Linux 平台 SIGUSR2 信号输出节点状态以及 metric 信息 RheaKV 增加 CompareAndPut 原子更新 API 新增 pooled buf allocator 解决 log replication 时大量分配 byte[] 频繁触发 fullgc 默认关闭 RheaKV rocksdb 的 fsync 和 WAL，依靠 raft log 和 snapshot 确保数据一致性 当 raft node 过载时拒绝新的请求 Breaking Changes 无 致谢（排名不分先后） @SteNicholas @zongtanghu 1.2.5 2019-04-01\n Bug Fixes 修复 jmh 与 unit test 代码冲突问题 修复 snapshot 过大引起的安装失败 bug，会影响新增节点的加入 Features LogManagerImpl 中耗费 cpu 部分的代码优化 修正一些单词拼写错误 Breaking Changes 无 此版本强烈推荐升级\n1.2.4 2019-03-20\n Bug Fixes 修复一种情况下 lease read 的 stale read 部分 timestamp 修改为 monotonic time 修复一种情况下 replicator 被 block 住的问题 解决 windows 平台下某些单测无法创建目录 解决 windows 平台下某些 rocksdb options 设置不当导致进程 crash Features 开放 RocksDB options 的设置给用户层 Pre-vote 优化，启用 lease 机制来规避网络分区+集群长时间无写入的情况下，游离节点回归后打断当前 term，提升系统可用性 升级 bolt …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/release-log/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9e24fb74a3cda6a600252b01f8a85db9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/release-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-jraft/release-log/","summary":"1.3.2 2020-06-19 Bug Fixes 移除对 bolt address parser 的扩展，避免 check connection 返回结果不符合预期 SPI 组件 JRaftServiceLoader 改为延迟加载策略规避多余对象的创建 几个 corner case 修复，比如 replicate logs 如果比 appliedI","tags":null,"title":"版本发行日志","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/release-log/","wordcount":2298},{"author":null,"categories":null,"content":" 通过 SOFABoot，我们可以直接在浏览器中就可以查看 SOFA 中间件的版本等详细信息。\n引入 SOFABoot Infra 依赖 要在 SOFABoot 中直接通过浏览器查看 SOFA 中间件的版本信息，只需要在 Maven 依赖中增加如下的内容即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;infra-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 版本信息查看 在应用启动成功后，可以在浏览器中输入 http://localhost:8080/sofaboot/versions 查看 SOFA 中间件的版本信息，如：\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Built-Time: \u0026amp;quot;2018-04-05T20:55:22+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.0\u0026amp;quot; } ] 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，sofaboot/versions 更改为 actuator/versions\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/view-versions/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c6b6d22e9038aa1f5e4ce74449ba1cda","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/view-versions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/view-versions/","summary":"通过 SOFABoot，我们可以直接在浏览器中就可以查看 SOFA 中间件的版本等详细信息。 引入 SOFABoot Infra 依赖 要在 SOFABoot 中直接通过浏览器查看 SOFA 中间件的版本信息，只","tags":null,"title":"版本查看","type":"projects","url":"/sofastack.tech/projects/sofa-boot/view-versions/","wordcount":182},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 1.0.0。\n参见: http://semver.org/lang/zh-CN/\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 1.2.0，那么将会维护 1.1.x 的 bugfix 分支，而 1.0.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 1.0.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 1.0.0。 发布后拉起下一个版本，例如 1.0.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/version-rule/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a2093bdf478bdff0e15a2de70e522d03","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/version-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/version-rule/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 1.0.0。 参见: http://semver.org/lang/zh-CN/ 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本","tags":null,"title":"版本规范","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/version-rule/","wordcount":286},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.2.0。\n参见: http://semver.org/lang/zh-CN/\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 5.4.0，那么将会维护 5.3.x 的 bugfix 分支，而 5.2.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 5.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 5.3.0。 发布后拉起下一个版本，例如 5.3.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-standard/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"71aad9cbc42aba3d9f875ae9169cf005","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/release-standard/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/release-standard/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.2.0。 参见: http://semver.org/lang/zh-CN/ 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本","tags":null,"title":"版本规范","type":"projects","url":"/sofastack.tech/projects/sofa-registry/release-standard/","wordcount":286},{"author":null,"categories":null,"content":"SOFABoot 使用了一些三方开源组件，他们分别是：\n一些主要依赖：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License sofa-common-tools under Apache 2.0 license 一些扩展依赖：\n nuxeo under Apache License, Version 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"11f073a7a9965ab5690ed166fe319bbd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/notice/","summary":"SOFABoot 使用了一些三方开源组件，他们分别是： 一些主要依赖： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License sofa-common-tools under Apache 2.0 license 一些扩展依赖： nuxeo under Apache License, Version 2.0 \u0026hellip; 其它整理中。","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-boot/notice/","wordcount":67},{"author":null,"categories":null,"content":" 依赖组件版权说明 SOFADashboard 使用了一些三方开源组件，他们分别是：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFA Bolt under Apache License 2.0 SOFA Bolt under Apache License 2.0 Curator under Apache License 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a9ebe38d245302f94ab7bfa793329926","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/notice/","summary":"依赖组件版权说明 SOFADashboard 使用了一些三方开源组件，他们分别是： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFA Bolt under Apache License 2.0 SOFA Bolt under Apache License 2.0 Curator under Apache License 2.0 \u0026hellip; 其它整理中。","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/notice/","wordcount":67},{"author":null,"categories":null,"content":" 依赖组件版权说明 SOFARegistry 使用了一些三方开源组件，他们分别是：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1  SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 \u0026amp;hellip; 其它整理中，如若发现遗漏，还请主动告知。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c40263ffd56a2f1292756c9fafea55e2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/notice/","summary":"依赖组件版权说明 SOFARegistry 使用了一些三方开源组件，他们分别是： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1 SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 \u0026hellip; 其","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-registry/notice/","wordcount":89},{"author":null,"categories":null,"content":" RheaKV：基于 JRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库。 AntQ Streams QCoordinator： 使用 JRaft 在 coordinator 集群内做选举、元信息存储等功能。 SOFA 服务注册中心元信息管理模块：IP 数据信息注册，要求写数据达到各个节点一致，并且在不小于一半节点挂掉，保证不影响数据正常存储。 AntQ NameServer 选主 ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/user-stories/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b233be7d9eed33645945293e637e28ea","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/user-stories/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/user-stories/","summary":"RheaKV：基于 JRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库。 AntQ Streams QCoordinator： 使用 JRaft 在 coordinator 集群内做选举、元信息存储等","tags":null,"title":"用户案例","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/user-stories/","wordcount":140},{"author":null,"categories":null,"content":"SOFARPC 支持指定地址进行调用的场景。用 Java API 的使用方式如下，设置直连地址即可：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); 用 XML 的使用方式如下：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sample.HelloService\u0026amp;quot; id=\u0026amp;quot;helloService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 用 Annotation 的使用方式如下：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, directUrl = \u0026amp;quot;127.0.0.1:12220\u0026amp;quot;)) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/peer-to-peer/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b1815c322f5dc9528f6429d1d5e38369","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/peer-to-peer/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/peer-to-peer/","summary":"SOFARPC 支持指定地址进行调用的场景。用 Java API 的使用方式如下，设置直连地址即可： ConsumerConfig\u0026lt;HelloService\u0026gt; consumer = new ConsumerConfig\u0026lt;HelloService\u0026gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026quot;bolt://127.0.0.1:12201\u0026quot;); 用 XML 的使用方式如下： \u0026lt;sofa:reference interface=\u0026quot;com.alipay.sample.HelloService\u0026quot; id=\u0026quot;helloService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:route target-url=\u0026quot;127.0.0.1:12200\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:reference\u0026gt; 用 Annotation 的使用方式如下","tags":null,"title":"直连调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/peer-to-peer/","wordcount":82},{"author":null,"categories":null,"content":" 类委托加载 注：这里委托加载不止包含类委托，还包含资源委托加载。\nSOFAArk 通过多 ClassLoader 的方式提供类隔离的能力，并在此基础上具备多版本隔离和热部署的能力。当然类如果纯粹隔离还不够，还需要考虑ClassLoader之间的类共享。SOFAArk 通过类委托机制，提供了一套丰富的委托加载能力。定义了PluginClassLoader 和 BizClassLoader，不同类型具备不同的类查找逻辑，同时提供ClassLoaderHook能力，允许自定义模块间的类委托加载。SOFAArk 框架本身的类委托加载是非常灵活的，但是在实际落地时，需要有一套类委托加载的最佳实践。\nSOFAArk 支持的场景主要分为两类： 1. 多Plugin的类隔离：考虑如何相同类不同版本不会相互冲突 2. 合并部署/热部署：原应用如何拆分，或多个应用如何合并\n这里我们主要考虑第2种，多 ClassLoader 如何布局，在内部探索出的最佳实践多 ClassLoader 布局为 模块里的类和资源查找优先从模块里查找列，查找不到从再基座里查找。\n最佳实践 类委托加载的准则是中间件相关的依赖需要放在同一个的 ClassLoader 里进行加载执行，达到这种方式的最佳实践有两种：\n强制委托加载 由于中间件相关的依赖一般需要在同一个ClassLoader里加载运行，所以可以制定一个中间件依赖的白名单，强制这些依赖委托给基座加载。SOFAArk 已经提供白名单能力，详细查看与 sofa.ark.plugin.export.class.enable 有关源码。\n强制加载优缺点 优点 模块开发者不需要感知哪些依赖属于需要强制加载由同一个 ClassLoader 加载的依赖\n 缺点 白名单里要强制加载的依赖列表需要维护，列表的缺失需要更新基座，较为重要的升级需要推所有的基座升级。\n自定义委托加载 模块里pom通过设置依赖的 scope 为 provided主动指定哪些要委托给基座加载。通过模块瘦身工具自动把与基座重复的依赖委托给基座加载，基座通过预置中间件的依赖（可选，虽然模块暂时不会用到，但可以提前引入，以备后续模块需要引入的时候不需再发布基座即可引入）\n1. 基座预置依赖 基座可以提前预置一些依赖\n2. 通过两种方式委托给基座加载 模块pom里依赖 scope 设置为 provided biz 打包插件sofa-ark-maven-plugin里设置 excludeGroupIds 或 excludeArtifactIds 3. 只有模块声明过的依赖才可以委托给基座加载 模块启动的时候，框架会有一些扫描逻辑，这些扫描如果不做限制会查找到模块和基座的所有类、资源，导致一些模块明明不需要的功能尝试去初始化，从而报错。SOFAArk 2.0.3之后新增了模块的 declaredMode, 来限制只有模块里声明过的依赖才可以委托给基座加载。只需在模块的 sofa-ark-maven-plugin 打包插件的 Configurations 里增加 true即可。\n自定义委托加载优缺点 优点 不需要维护强制加载列表，当部分需要由同一 ClassLoader 加载的依赖没有设置为统一加载时，可以修改模块就可以修复，不需要发布基座（除非基座确实依赖）。\n 缺点 对模块自动瘦身的依赖较强\n对比与总结 委托加载类型 依赖缺失排查成本 修复成本 模块改造成本 维护成本 强制加载 类转换失败或类查找失败，成本中 更新 plugin，发布基座，高 低 高 自定义委托加载 类转换失败或类查找失败，成本中 更新模块依赖，如果基座依赖不足，需要更新基座并发布，中 高 低 自定义委托加载 + 基座预置依赖 + 模块自动瘦身 类转换失败或类查找失败，成本中 更新模块依赖，设置为provided，低 低 低 推荐自定义委托加载方式 模块自定义委托加载 + 模块自动瘦身 模块开启 declaredMode 基座预置依赖 开启后的副作用 由于基座提前启动，模块再次启动的时候，如果依赖了基座的依赖里有发布服务，那么模块在启动的时候还会再次发布，如果该问题有一定影响可以模块pom里exclude掉对应的依赖。 ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-class-loader-delegation/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d3ea2dc9104433356ad82b6a772a971a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","summary":"类委托加载 注：这里委托加载不止包含类委托，还包含资源委托加载。 SOFAArk 通过多 ClassLoader 的方式提供类隔离的能力，并在此基础上具备多版本隔离和热部署的能力。当","tags":null,"title":"类委托加载","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","wordcount":1428},{"author":null,"categories":null,"content":"介绍几种 SOFARPC 在不同环境下的使用方式 * 非 Spring 环境 API 使用 * SOFABoot 环境 XML 配置使用 * SOFABoot 环境注解使用 * SOFABoot 环境动态 API 使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programming/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9a947dae761c84aa4d95121c076ac552","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programming/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programming/","summary":"介绍几种 SOFARPC 在不同环境下的使用方式 * 非 Spring 环境 API 使用 * SOFABoot 环境 XML 配置使用 * SOFABoot 环境注解使用 * SOFABoot 环境动态 API 使用","tags":null,"title":"编程界面","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programming/","wordcount":50},{"author":null,"categories":null,"content":"自动故障剔除会自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复。目前支持 bolt 协议。\n在 SOFABoot 中，只需要配置自动故障剔除的参数到 application.properties 即可。可以不完全配置，只配置自己关心的参数，其余参数会取默认值。需要注意的是 com.alipay.sofa.rpc.aft.regulation.effective 是该功能的全局开关，如果关闭则该功能不会运行，其他参数也都不生效。\n 属性 描述 默认值 timeWindow 时间窗口大小：对统计信息计算的周期。 10s leastWindowCount 时间窗口内最少调用数：只有在时间窗口内达到了该最低值的数据才会被加入到计算和调控中。 10次 leastWindowExceptionRateMultiple 时间窗口内异常率与服务平均异常率的降级比值：在对统计信息进行计算的时候，会计算出该服务所有有效调用ip的平均异常率，如果某个ip的异常率大于等于了这个最低比值，则会被降级。 6倍 weightDegradeRate 降级比率：地址在进行权重降级时的降级比率。 1\u0026amp;frasl;20 weightRecoverRate 恢复比率：地址在进行权重恢复时的恢复比率。 2倍 degradeEffective 降级开关：如果应用打开了这个开关，则会对符合降级的地址进行降级，否则只会进行日志打印。 false(关闭) degradeLeastWeight 降级最小权重：地址权重被降级后的值如果小于这个最小权重，则会以该最小权重作为降级后的值。 1 degradeMaxIpCount 降级的最大ip数：同一个服务被降级的ip数不能超过该值。 2 regulationEffective 全局开关：如果应用打开了这个开关，则会开启整个单点故障自动剔除摘除功能，否则完全不进入该功能的逻辑。 false(关闭) 示例\ncom.alipay.sofa.rpc.aft.time.window=20 com.alipay.sofa.rpc.aft.least.window.count=30 com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple=1.4 com.alipay.sofa.rpc.aft.weight.degrade.rate=0.5 com.alipay.sofa.rpc.aft.weight.recover.rate=1.2 com.alipay.sofa.rpc.aft.degrade.effective=true com.alipay.sofa.rpc.aft.degrade.least.weight=1 com.alipay.sofa.rpc.aft.degrade.max.ip.count=2 com.alipay.sofa.rpc.aft.regulation.effective=true 如上配置，打开了自动故障剔除功能和降级开关，当节点出现故障时会被进行权重降级，在恢复时会被进行权重恢复。每隔 20s 进行一次节点健康状态的度量，20s 内调用次数超过 30 次的节点才被作为计算数据，如果单个节点的异常率超过了所有节点的平均异常率的 1.4 倍则对该节点进行权重降级，降级的比率为 0.5 。权重最小降级到 1 。如果单个节点的异常率低于了平均异常率的 1.4 倍则对该节点进行权重恢复，恢复的比率为1.2 。单个服务最多降级 2 个ip。\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-fault-tolerance/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a132b54b2398534d1773489e2b0db166","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","summary":"自动故障剔除会自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复。目前支持 bolt 协议。 在 SOFABoot 中，只需要配置自动故障剔除的","tags":null,"title":"自动故障剔除","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","wordcount":759},{"author":null,"categories":null,"content":"集群中通常一个服务有多个服务提供者。其中部分服务提供者可能由于网络，配置，长时间 fullgc ，线程池满，硬件故障等导致长连接还存活但是程序已经无法正常响应。单机故障剔除功能会将这部分异常的服务提供者进行降级，使得客户端的请求更多地指向健康节点。当异常节点的表现正常后，单机故障剔除功能会对该节点进行恢复，使得客户端请求逐渐将流量分发到该节点。单机故障剔除功能解决了服务故障持续影响业务的问题，避免了雪崩效应。可以减少人工干预需要的较长的响应时间，提高系统可用率。\n运行机制：\n 单机故障剔除会统计一个时间窗口内的调用次数和异常次数，并计算每个服务对应ip的异常率和该服务的平均异常率。 当达到ip异常率大于服务平均异常率到一定比例时，会对该服务+ip的维度进行权重降级。 如果该服务+ip维度的权重并没有降为0，那么当该服务+ip维度的调用情况正常时，则会对其进行权重恢复。 整个计算和调控过程异步进行，不会阻塞调用。 单机故障剔除的使用方式如下：\nFaultToleranceConfig faultToleranceConfig = new FaultToleranceConfig(); faultToleranceConfig.setRegulationEffective(true); faultToleranceConfig.setDegradeEffective(true); faultToleranceConfig.setTimeWindow(20); faultToleranceConfig.setWeightDegradeRate(0.5); FaultToleranceConfigManager.putAppConfig(\u0026amp;quot;appName\u0026amp;quot;, faultToleranceConfig); 如上，该应用会在打开了单机故障剔除开关，每20s的时间窗口进行一次异常情况的计算，如果某个服务+ip的调用维度被判定为故障节点，则会进行将该服务+ip的权重降级为0.5倍。\n更加详细的参数请参考单机故障剔除参数。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-tolerance/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7501b0fac1d1d89c61de0d591e29e1d0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault-tolerance/","summary":"集群中通常一个服务有多个服务提供者。其中部分服务提供者可能由于网络，配置，长时间 fullgc ，线程池满，硬件故障等导致长连接还存活但是程序已经无法正常","tags":null,"title":"自动故障剔除","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault-tolerance/","wordcount":528},{"author":null,"categories":null,"content":" 在使用自定义埋点组件的情况下，用户可以选择自定义 Reporter。\n自定义 Reporter 实现 public class MyReporter implements Reporter { @Override public String getReporterType() { return \u0026amp;quot;myReporter\u0026amp;quot;; } @Override public void report(SofaTracerSpan sofaTracerSpan) { // System.out 输出 System.out.println(\u0026amp;quot;this is my custom reporter\u0026amp;quot;); } @Override public void close() { // ignore } } 配置 com.alipay.sofa.tracer.reporter-name=com.glmapper.bridge.boot.flexible.MyReporter 自定义实现 Reporter 可以将业务埋点的日志输出到任何期望的地方。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/reporter-custom/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"521206c7f4051c1cc8ec8232c20bab6d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/reporter-custom/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/reporter-custom/","summary":"在使用自定义埋点组件的情况下，用户可以选择自定义 Reporter。 自定义 Reporter 实现 public class MyReporter implements Reporter { @Override public String getReporterType() { return \u0026quot;myReporter\u0026quot;; } @Override public void report(SofaTracerSpan sofaTracerSpan) { // System.out 输出 System.out.println(\u0026quot;this is my custom reporter\u0026quot;); } @Override","tags":null,"title":"自定义 Reporter","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/reporter-custom/","wordcount":108},{"author":null,"categories":null,"content":" SOFARPC 支持自定义业务线程池。可以为指定服务设置一个独立的业务线程池，和 SOFARPC 自身的业务线程池是隔离的。多个服务可以共用一个独立的线程池。\nSOFARPC 要求自定义线程池的类型必须是 com.alipay.sofa.rpc.server.UserThreadPool。\nXML 方式 如果采用 XML 的方式发布服务，可以先设定一个 class 为 com.alipay.sofa.rpc.server.UserThreadPool 的线程池的 Bean，然后设置到 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 thread-pool-ref 属性中：\n\u0026amp;lt;bean id=\u0026amp;quot;helloService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- 自定义一个线程池 --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;customExecutor\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.server.UserThreadPool\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;corePoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;maximumPoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;queueSize\u0026amp;quot; value=\u0026amp;quot;0\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloService\u0026amp;quot; interface=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;!-- 将线程池设置给一个 Service --\u0026amp;gt; \u0026amp;lt;sofa:global-attrs thread-pool-ref=\u0026amp;quot;customExecutor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation 方式 如果是采用 Annotation 的方式发布服务，可以通过设置 @SofaServiceBinding 的 userThreadPool 属性来设置自定义线程池的 Bean：\n@SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, userThreadPool = \u0026amp;quot;customThreadPool\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 在 Spring 环境使用 API 方式 如果是在 Spring 环境下使用 API 的方式发布服务，可以通过调用 BoltBindingParam 的 setUserThreadPool 方法来设置自定义线程池：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setUserThreadPool(new UserThreadPool()); 在非 Spring 环境下使用 API 方式 如果是在非 Spring 环境下使用 API 的方式，可以通过如下的方式来设置自定义线程池：\nUserThreadPool threadPool = new UserThreadPool(); threadPool.setCorePoolSize(10); threadPool.setMaximumPoolSize(100); threadPool.setKeepAliveTime(200); threadPool.setPrestartAllCoreThreads(false); threadPool.setAllowCoreThreadTimeOut(false); threadPool.setQueueSize(200); UserThreadPoolManager.registerUserThread(ConfigUniqueNameGenerator.getUniqueName(providerConfig), threadPool); 如上为 HelloService 服务设置了一个自定义线程池。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-threadpool/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3f05f154bcb2b653ebeebb35b84d5ae1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-threadpool/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-threadpool/","summary":"SOFARPC 支持自定义业务线程池。可以为指定服务设置一个独立的业务线程池，和 SOFARPC 自身的业务线程池是隔离的。多个服务可以共用一个独立的线程池。 SOFARPC 要求自定义","tags":null,"title":"自定义线程池","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-threadpool/","wordcount":412},{"author":null,"categories":null,"content":"SOFARPC 中对服务地址的选择也抽象为了一条处理链，由每一个 Router 进行处理。同 Filter 一样， SOFARPC 对 Router 提供了同样的扩展能力。\n@Extension(value = \u0026amp;quot;customerRouter\u0026amp;quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026amp;lt;ProviderInfo\u0026amp;gt; route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) { return providerInfos; } 新建扩展文件 META-INF/services/sofa-rpc/com.alipay.sofa.rpc.client.Router 。内容如下：\ncustomerRouter=com.alipay.sofa.rpc.custom.CustomRouter 如上自定义了一个 CustomerRouter ，生效于所有消费者。其中 init 参数 ConsumerBootstrap 是引用服务的包装类，能够拿到 ConsumerConfig ，代理类，服务地址池等对象。 needToLoad 表示是否生效该 Router ， route 方法即筛选地址的方法。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-router/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"236e8d4bda3e856267a3575853aa900c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-router/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-router/","summary":"SOFARPC 中对服务地址的选择也抽象为了一条处理链，由每一个 Router 进行处理。同 Filter 一样， SOFARPC 对 Router 提供了同样的扩展能力。 @Extension(value = \u0026quot;customerRouter\u0026quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override","tags":null,"title":"自定义路由寻址","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-router/","wordcount":179},{"author":null,"categories":null,"content":" SOFARPC 提供了一套良好的可扩展性机制，为各个模块提供 SPI 的能力。 SOFARPC 对请求与响应的过滤链处理方式是通过多个过滤器 Filter 来进行具体的拦截处理，该部分可由用户自定义 Filter 扩展，自定义 Filter 的执行顺序在内置 Filter 之后。具体方式如下：\nBolt Filter 新建自定义 Filter 。\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 生效该自定义 Filter 到拦截器链中。这一步具体方式有三种。 方式1：API方式。该种方式能够生效到指定的 provider 或 consumer 。\n// 服务提供者 providerConfig.setFilterRef(Arrays.asList(new CustomFilter())); // 服务调用者 consumerConfig.setFilterRef(Arrays.asList(new CustomFilter())); 方式2：在类上加上 @Extension 注解+配置扩展文件方式。\n@Extension(\u0026amp;quot;customer\u0026amp;quot;) public class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 新建扩展文件 META-INF/services/sofa-rpc/com.alipay.sofa.rpc.filter.Filter 。内容如下：\ncustomer=com.alipay.sofa.rpc.custom.CustomFilter 编码注入。\n// 服务提供者 providerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); // 服务调用者 consumerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); 方式三：在类上加上 @Extension 注解+ @AutoActive 注解方式+配扩展文件方式。该种方式利用 @AutoActive 注解代替了上述第二中方式的编码注入步骤，能够生效于所有 provider 或 consumer 。其中 providerSide 参数表示是否生效于服务端， consumerSide 参数表示是否生效于客户端。\n@Extension(\u0026amp;quot;customer\u0026amp;quot;) @AutoActive(providerSide = true, consumerSide = true) public class customerFilter extends Filter { // ... } ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-filter/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"30ff5937b52a7c2dd8028e878979a33d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-filter/","summary":"SOFARPC 提供了一套良好的可扩展性机制，为各个模块提供 SPI 的能力。 SOFARPC 对请求与响应的过滤链处理方式是通过多个过滤器 Filter 来进行具体的拦截处理，该部分可由用户","tags":null,"title":"自定义过滤器","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-filter/","wordcount":409},{"author":null,"categories":null,"content":" 本文是对 MOSN 自定义配置的说明。\nDuration String 字符串，由一个十进制数字和一个时间单位后缀组成，有效的时间单位为 ns、us（或µs）、ms、s、m、h，例如 1h、3s、500ms。 metadata metadata 用于 MOSN 路由和 Cluster Host 之间的匹配。\n{ \u0026amp;quot;filter_metadata\u0026amp;quot;:{ \u0026amp;quot;mosn.lb\u0026amp;quot;:{} } } mosn.lb 可对应任意的 string-string 的内容。\ntls_context { \u0026amp;quot;status\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;server_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;ca_cert\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;cert_chain\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;private_key\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;verify_client\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;require_client_cert\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;insecure_skip\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;cipher_suites\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;ecdh_curves\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;min_version\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;max_version\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;alpn\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;fall_back\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;extend_verify\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;sds_source\u0026amp;quot;:{} } status，bool类型，表示是否开启 TLS，默认是 false。 type，字符串类型，描述 tls_context 的类型。tls_context 支持扩展实现，不同的 type 对应不同的实现方式，默认实现方式对应的 type 是空字符串。 server_name，当没有配置 insecure_skip 时，用于校验服务端返回证书的 hostname。作为Cluster配置时有效。 ca_cert，证书签发的根 CA 证书。 cert_chain，TLS 证书链配置。 private_key，证书私钥配置。 verify_client，bool 类型，作为 Listener 配置时有效，表示是否要校验 Client 端证书 require_client_cert，bool 类型，表示是否强制 Client 端必须携带证书。 insecure_skip，bool 类型，作为 Cluster 配置时有效，表示是否要忽略 Server 端的证书校验。 cipher_suites，如果配置了该配置，那么 TLS 连接将只支持配置了的密码套件，并且会按照配置的顺序作为优先级使用，支持的套件类型如下：\nECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-AES256-CBC-SHA ECDHE-RSA-AES128-CBC-SHA ECDHE-ECDSA-AES256-CBC-SHA ECDHE-ECDSA-AES128-CBC-SHA RSA-AES256-CBC-SHA RSA-AES128-CBC-SHA ECDHE-RSA-3DES-EDE-CBC-SHA RSA-3DES-EDE-CBC-SHA ECDHE-RSA-SM4-SM3 ECDHE-ECDSA-SM4-SM3 ecdh_curves，如果配置了该配置，那么 TLS 连接将只支持配置了的曲线。\n 支持 x25519、p256、p384、p521。 min_version，最低的 TLS 协议版本，默认是 TLS1.0。\n 支持 TLS1.0、TLS1.1、TLS1.2。 默认会自动识别可用的 TLS 协议版本。 max_version，最高的 TLS 协议版本，默认是 TLS1.2。\n 支持 TLS1.0、TLS1.1、TLS1.2。 默认会自动识别可用的 TLS 协议版本。 alpn，TLS 的 ALPN 配置。\n 支持 h2、http/1.1、 sofa。 fall_back，bool类型，当配置为 true 时，如果证书解析失败，不会报错而是相当于没有开启 TLS。\n extend_verify，任意 json 类型，当 type 为非空时，作为扩展的配置参数。\n sds_source，访问 SDS API 的配置，如果配置了这个配置，ca_cert、cert_chain 和 private_key 都会被忽略，但是其余的配置依然有效。\n sds_source { \u0026amp;quot;CertificateConfig\u0026amp;quot;:{}, \u0026amp;quot;ValidationConfig\u0026amp;quot;:{} } CertificateConfig 描述了如何获取 cert_chain 和 private_key 的配置。 ValidationConfig 描述了如何获取 ca_cert 的配置。 详细的 Config 内容参考 envoy: sdssecretconfig。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/custom/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cdad467fd3551e47a7585511278767cd","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/custom/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/configuration/custom/","summary":"本文是对 MOSN 自定义配置的说明。 Duration String 字符串，由一个十进制数字和一个时间单位后缀组成，有效的时间单位为 ns、us（或µs）、ms、s、m、h，例如","tags":null,"title":"自定义配置说明","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/custom/","wordcount":1005},{"author":null,"categories":null,"content":" SOFARPC 支持进行框架层面的重试策略，前提是集群模式为 FailOver（SOFARPC 默认即为 FailOver 模式）。重试只有在发生服务端的框架层面异常或者是超时异常才会发起。如果是业务抛出异常，是不会重试的。默认情况下 SOFARPC 不进行任何重试。\n 请注意：超时异常虽然可以重试，但是需要服务端保证业务的幂等性，否则可能会有风险\n XML 方式 如果使用 XML 方式订阅服务，可以设置 sofa:global-attrs 的 retries 参数来设置重试次数：\n\u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;retriesServiceReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.retries.RetriesService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs retries=\u0026amp;quot;2\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 如果是使用 Annotation 的方式，可以通过设置 @SofaReferenceBinding 注解的 retries 属性来设置：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, retries = 2)) private SampleService sampleService; Spring 环境下 API 方式 如果是在 Spring 环境下用 API 的方式，可以调用 BoltBindingParam 的 setRetries 方法来设置：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setRetries(2); 非 Spring 环境下 API 方式 如果是在非 Spring 环境下直接使用 SOFARPC 的裸 API 的方式，可以通过调用 ConsumerConfig 的 setRetries 方法来设置：\nConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt;(); consumerConfig.setRetries(2); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/retry-invoke/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d60b44aa8f1b49ab6c1bbc55593a91da","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/retry-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/retry-invoke/","summary":"SOFARPC 支持进行框架层面的重试策略，前提是集群模式为 FailOver（SOFARPC 默认即为 FailOver 模式）。重试只有在发生服务端的框架层面异常或者是超时","tags":null,"title":"调用重试","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/retry-invoke/","wordcount":319},{"author":null,"categories":null,"content":" SOFARPC 提供多种负载均衡算法，目前支持以下五种：\n 类型 名称 描述 random 随机算法 默认负载均衡算法。 localPref 本地优先算法 优先发现是否本机发布了该服务，如果没有再采用随机算法。 roundRobin 轮询算法 方法级别的轮询，各个方法间各自轮询，互不影响。 consistentHash 一致性hash算法 同样的方法级别的请求会路由到同样的节点。 weightRoundRobin 按权重负载均衡轮询算法 按照权重对节点进行轮询。性能较差，不推荐使用。 要使用某种特定的负载均衡算法，可以按照以下的方式进行设置：\nXML 方式 如果使用 XML 的方式引用服务，可以通过设置 sofa:global-attrs 标签的 loadBalancer 属性来设置：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs loadBalancer=\u0026amp;quot;roundRobin\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 Annotation 方式目前暂未提供设置某一个 Reference 的负载均衡算法的方式。将在后续的版本中提供。\n在 Spring 环境下 API 方式 如果在 Spring 或者 Spring Boot 的环境下使用 API，可以通过调用 BoltBindingParam 的 setLoadBalancer 方法来设置：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setLoadBalancer(\u0026amp;quot;roundRobin\u0026amp;quot;); 非 Spring 环境下 API 方式 如果在非 Spring 环境下直接使用 SOFARPC 提供的裸 API，可以通过调用 ConsumerConfig 的 setLoadBalancer 方法来设置：\nConsumerConfig consumerConfig = new ConsumerConfig(); consumerConfig.setLoadbalancer(\u0026amp;quot;random\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/load-balance/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"739984ca9a414429304f85010fd73ad0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/load-balance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/load-balance/","summary":"SOFARPC 提供多种负载均衡算法，目前支持以下五种： 类型 名称 描述 random 随机算法 默认负载均衡算法。 localPref 本地优先算法 优先发现是否本机发布了该服务，如果没有再采用","tags":null,"title":"负载均衡","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/load-balance/","wordcount":375},{"author":null,"categories":null,"content":" 任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 文档 SOFADashboard 配置参数文档 简单 代码 支持 SOFARegistry 中 代码 支持 Docker 中 代码 支持 Kubernetes 中 代码 支持 Apollo 中 代码 优化前端 中 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/roadmap/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a740c874742b504de9011b07f3a4ddb5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/roadmap/","summary":"任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 文档 SOFADashboard 配置参数文档 简","tags":null,"title":"路线图及任务认领","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/roadmap/","wordcount":102},{"author":null,"categories":null,"content":" 1. registry-meta 1.1 推送开关 在注册中心新版本发布的过程中为了把对业务的影响减少到最小，避免服务端重启动引发大规模服务地址信息变更产生大量推送，我们提供运维层面暂时关闭推送的能力。在服务端完成发布后，可以打开推送恢复正常工作状态，在关闭期间的数据订阅和服务发布信息会再次进行全局推送进行补偿。\n打开推送：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/close\u0026amp;quot; 关闭推送：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/open\u0026amp;quot; 1.2 查询地址列表 查看 meta 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/META/node/query\u0026amp;quot; 查看 data 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/DATA/node/query\u0026amp;quot; 查看 session 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/SESSION/node/query\u0026amp;quot; 2. registry-data 2.1 查询数据 查看 pub 数量：\ncurl \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/datum/count\u0026amp;quot; 根据客户端的 ip\u0026amp;amp;port 查询其发布的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;\u0026amp;quot;:\u0026amp;quot;\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;}\u0026#39; 3. registry-session 3.1 查询数据 根据客户端的 ip\u0026amp;amp;port 查询其发布的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/pub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]\u0026#39; 根据客户端的 ip\u0026amp;amp;port 查询其订阅的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/sub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]\u0026#39; 3.2 断开客户端链接：clientOff 根据客户端的 ip\u0026amp;amp;port 强制删除其所有 sub\u0026amp;amp;pub 数据（但不会断开连接）：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/api/clients/off\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;connectIds\u0026amp;quot;: [\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]}\u0026#39; ","date":-62135596800,"description":"","dir":"projects/sofa-registry/management-api/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2cf59ac422c84c279d73c1f7f1cd0902","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/management-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/management-api/","summary":"1. registry-meta 1.1 推送开关 在注册中心新版本发布的过程中为了把对业务的影响减少到最小，避免服务端重启动引发大规模服务地址信息变更产生大量推送，我们提供运维","tags":null,"title":"运维命令","type":"projects","url":"/sofastack.tech/projects/sofa-registry/management-api/","wordcount":554},{"author":null,"categories":null,"content":"SOFARPC 支持不同的通信协议，目前支持 Bolt, RESTful 和 Dubbo，详细的事情请参考各个协议对应的文档： * Bolt 协议 * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化协议 * 自定义线程池 * RESTful * 基本使用 * 自定义 Filter * 集成 Swagger * Dubbo * 基本使用 * H2C * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/protocol/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"18f51cb12f7a0384a71ab22349292a08","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/protocol/","summary":"SOFARPC 支持不同的通信协议，目前支持 Bolt, RESTful 和 Dubbo，详细的事情请参考各个协议对应的文档： * Bolt 协议 * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化","tags":null,"title":"通信协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/protocol/","wordcount":109},{"author":null,"categories":null,"content":" 1. 环境准备 要使用 SOFARegistry，需要先准备好基础环境，SOFARegistry 依赖以下环境：\n Linux/Unix/Mac JDK8 需要采用 Apache Maven 3.2.5 或者以上的版本来编译 2. 资源配额 cpu: 4c memory: 8G disk: 50G 3. 两种部署模式 集成部署模式 将 meta/data/session 三个角色打包集成在一个 jvm 里运行，可单机或集群部署，部署简单。 独立部署模式 将 meta/data/session 三个角色分开部署，每个角色都可以单机或集群部署，可根据实际情况为每个角色部署不同的数量。 生产环境建议使用这种部署模式。 4. 配置参数 SOFARegistry 的部署，依赖于一些公共参数\n properties environment 默认值 作用 nodes.localDataCenter x DefaultDataCenter 集群名，多个注册中心公用同一个数据库用到 nodes.localRegion x DEFAULT_ZONE 逻辑 region, 创建多组 session jdbc.url JDBC_URL 必填 数据库地址 jdbc.username JDBC_USERNAME 必填 数据库用户名 jdbc.password JDBC_PASSWORD 必填 数据库密码 properties 可以写在 registry-all/conf/application.properties 中， kubernetes 下部署也可以使用 configmap 进行文件挂载\n5. 打包 jar release 页面 下载最新的 registry-all.tgz 包\ntar -zxvf registry-all.tgz cd registry-all 或者从源码打包\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Pserver-release -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all image image 托管于 https://hub.docker.com/r/sofaregistry/sofaregistry\n或者从源码 build: 修改 Makefile 中 image 的 repository\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true make image_build make image_push 6. 集成部署模式 集成部署模式，是将 meta/data/session 三个角色打包集成在一个 JVM 里运行，可单机或集群部署, 不建议大规模使用\n6.1 jar 单机部署 集成部署的单机部署模式可以直接参考快速开始-服务端部署部分。\n6.2 jar 集群部署 解压 registry-all.tgz，并修改配置文件 集群部署，即搭建 2 台以上的集群，建议至少使用 3 台（注意：目前不支持在同一台机器部署多个 SOFARegistry，因此您必须有 3 台不同的机器）。在每一台机器上的部署方法同上：\ncp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all 区别是每台机器在部署时需要修改 registry-all/conf/application.properties 配置, 组成同一个注册中心的多台机器需要配置相同的数据库和nodes.localDataCenter\nnodes.localDataCenter=DefaultDataCenter nodes.localRegion=DEFAULT_ZONE jdbc.url = jdbc:mysql://127.0.0.1:3306/registrymetadb?useUnicode=true\u0026amp;amp;characterEncoding=utf8 jdbc.username = root jdbc.password = root 启动 registry-integration 每台机器都修改以上配置文件后，按照“单机部署”的步骤去启动 registry-integration 即可。 sh bin/integration/start.sh\n6.3 docker 集群部署 客户端和 SOFARegistry 需要同一个三层网络内，因此利用 docker 部署需要使用 host network 可以通过配置文件挂载的方式进行部署，也可以通过环境变量传递的方式 同时需要添加 REGISTRY_APP_NAME=integration 进入集成模式，在一个 jvm 里启动 3 个角色\nimage 中， registry-all.tgz 的解压地址在 registry-distribution/registry-all, 配置需要挂载到正确的目录\ndocker run -e REGISTRY_APP_NAME=integration \\ --name=sofa-registry --rm --net=host \\ -v $PWD/conf/:/registry-distribution/registry-all/conf/ \\ -e JDBC_URL=jdbc:mysql://172.17.0.1:3306/registrymetadb -e JDBC_USERNAME=root -e JDBC_PASSWORD=root sofaregistry/sofaregistry:6.1.4 7. 独立部署模式 独立部署模式，是将 meta/data/session 三个角色分开部署，每个角色都可以单机或集群部署，可根据实际情况为每个角色部署不同的数量，生产环境推荐使用这种部署模式。\n以下介绍 332 模式（即 3 台 meta + 3 台 data + 2 台 session）的部署步骤。\n7.1 jar 集群部署 解压 registry-all.tgz，并修改配置文件 集群部署，即搭建 2 台以上的集群，建议至少使用 3 台（注意：目前不支持在同一台机器部署多个 SOFARegistry，因此您必须有 3 台不同的机器）。在每一台机器上的部署方法同上： cp …","date":-62135596800,"description":"","dir":"projects/sofa-registry/deployment/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7e28583bc38be66af8d704d7fbcd9dd4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/deployment/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/deployment/","summary":"1. 环境准备 要使用 SOFARegistry，需要先准备好基础环境，SOFARegistry 依赖以下环境： Linux/Unix/Mac JDK8 需要采用 Apache Maven 3.2.5 或者以上的版本来编译","tags":null,"title":"部署","type":"projects","url":"/sofastack.tech/projects/sofa-registry/deployment/","wordcount":1558},{"author":null,"categories":null,"content":" MOSN 的配置文件可以分为以下四大部分：\n Servers 配置，目前仅支持最多 1 个 Server 的配置，Server 中包含一些基础配置以及对应的 Listener 配置 ClusterManager 配置，包含 MOSN 的 Upstream 详细信息 对接控制平面（Pilot）的 xDS 相关配置 其他配置 Trace、Metrics、Debug、Admin API 相关配置 扩展配置，提供自定义配置扩展需求 配置文件概览\nMOSN 的基本配置部分如下所示：\n{ \u0026amp;quot;servers\u0026amp;quot;: [], \u0026amp;quot;cluster_manager\u0026amp;quot;: {}, \u0026amp;quot;dynamic_resources\u0026amp;quot;: {}, \u0026amp;quot;static_resources\u0026amp;quot;: {}, \u0026amp;quot;admin\u0026amp;quot;:{}, \u0026amp;quot;pprof\u0026amp;quot;:{}, \u0026amp;quot;tracing\u0026amp;quot;:{}, \u0026amp;quot;metrics\u0026amp;quot;:{} } 配置类型 MOSN 的配置包括以下几种类型：\n 静态配置 动态配置 混合模式 静态配置 静态配置是指 MOSN 启动时，不对接控制平面 Pilot 的配置，用于一些相对固定的简单场景（如 MOSN 的示例）。 使用静态配置启动的 MOSN，也可以通过扩展代码，调用动态更新配置的接口实现动态修改。 静态配置启动时必须包含一个 Server 以及至少一个 Cluster。 动态配置 动态配置是指 MOSN 启动时，只有访问控制平面相关的配置，没有 MOSN 运行时所需要的配置。\n 使用动态配置启动的 MOSN，会向管控面请求获取运行时所需要的配置，管控面也可能在运行时推送更新 MOSN 运行配置。\n 动态配置启动时必须包含 DynamicResources 和 StaticResources 配置。\n 混合模式 MOSN 启动时的配置可以同时包含静态模式与动态模式，以混合模式启动的 MOSN 会先以静态配置完成初始化，随后可能由控制平面获取配置更新。\n配置示例 静态配置示例 动态配置的示例如下所示。\n{ \u0026amp;quot;servers\u0026amp;quot;: [ { \u0026amp;quot;default_log_path\u0026amp;quot;: \u0026amp;quot;/home/admin/logs/mosn/default.log\u0026amp;quot;, \u0026amp;quot;default_log_level\u0026amp;quot;: \u0026amp;quot;DEBUG\u0026amp;quot;, \u0026amp;quot;processor\u0026amp;quot;: 4, \u0026amp;quot;listeners\u0026amp;quot;: [ { \u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;0.0.0.0:12220\u0026amp;quot;, \u0026amp;quot;bind_port\u0026amp;quot;: true, \u0026amp;quot;filter_chains\u0026amp;quot;: [ { \u0026amp;quot;filters\u0026amp;quot;: [ { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;proxy\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;downstream_protocol\u0026amp;quot;: \u0026amp;quot;SofaRpc\u0026amp;quot;, \u0026amp;quot;upstream_protocol\u0026amp;quot;: \u0026amp;quot;SofaRpc\u0026amp;quot;, \u0026amp;quot;router_config_name\u0026amp;quot;: \u0026amp;quot;test_router\u0026amp;quot; } }, { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;connection_manager\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;router_config_name\u0026amp;quot;: \u0026amp;quot;test_router\u0026amp;quot;, \u0026amp;quot;virtual_hosts\u0026amp;quot;: [] } } ] } ] } ] } ], \u0026amp;quot;cluster_manager\u0026amp;quot;: { \u0026amp;quot;clusters\u0026amp;quot;: [ { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;example\u0026amp;quot;, \u0026amp;quot;lb_type\u0026amp;quot;: \u0026amp;quot;LB_ROUNDROBIN\u0026amp;quot;, \u0026amp;quot;hosts\u0026amp;quot;: [ {\u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;127.0.0.1:12200\u0026amp;quot;} ] } ] } } 动态配置示例 静态配置的示例如下所示。\n{ \u0026amp;quot;dynamic_resources\u0026amp;quot;: { \u0026amp;quot;ads_config\u0026amp;quot;: { \u0026amp;quot;api_type\u0026amp;quot;: \u0026amp;quot;GRPC\u0026amp;quot;, \u0026amp;quot;grpc_services\u0026amp;quot;: [ { \u0026amp;quot;envoy_grpc\u0026amp;quot;: {\u0026amp;quot;cluster_name\u0026amp;quot;: \u0026amp;quot;xds-grpc\u0026amp;quot;} } ] } } }, \u0026amp;quot;static_resources\u0026amp;quot;: { \u0026amp;quot;clusters\u0026amp;quot;: [ { \u0026amp;quot;name\u0026amp;quot;: \u0026amp;quot;xds-grpc\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;STRICT_DNS\u0026amp;quot;, \u0026amp;quot;connect_timeout\u0026amp;quot;: \u0026amp;quot;10s\u0026amp;quot;, \u0026amp;quot;lb_policy\u0026amp;quot;: \u0026amp;quot;ROUND_ROBIN\u0026amp;quot;, \u0026amp;quot;hosts\u0026amp;quot;: [ { \u0026amp;quot;socket_address\u0026amp;quot;: {\u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;pilot\u0026amp;quot;, \u0026amp;quot;port_value\u0026amp;quot;: 15010} } ], \u0026amp;quot;upstream_connection_options\u0026amp;quot;: { \u0026amp;quot;tcp_keepalive\u0026amp;quot;: { \u0026amp;quot;keepalive_time\u0026amp;quot;: 300 } }, \u0026amp;quot;http2_protocol_options\u0026amp;quot;: { } } ] } } ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/overview/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0aa65950d2c24e8ce86d265bea275e2a","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/configuration/overview/","summary":"MOSN 的配置文件可以分为以下四大部分： Servers 配置，目前仅支持最多 1 个 Server 的配置，Server 中包含一些基础配置以及对应的 Listener 配置 ClusterManager 配置，包含 MOSN 的 Upstream 详细信","tags":null,"title":"配置概览","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/overview/","wordcount":663},{"author":null,"categories":null,"content":" 目前 SOFATracer 提供了两种采样模式，一种是基于 BitSet 实现的基于固定采样率的采样模式；另外一种是提供给用户自定义实现采样的采样模式。下面通过案例来演示如何使用。\n本示例基于 tracer-sample-with-springmvc 工程；除 application.properties 之外，其他均相同。\n基于固定采样率的采样模式 在 application.properties 中增加采样相关配置项 #采样率 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #采样模式类型名称 com.alipay.sofa.tracer.samplerName=PercentageBasedSampler 验证方式 当采样率设置为100时，每次都会打印摘要日志。 当采样率设置为0时，不打印 当采样率设置为0~100之间时，按概率打印 以请求 10 次来验证下结果。\n1、当采样率设置为100时，每次都会打印摘要日志\n启动工程，浏览器中输入：http://localhost:8080/springmvc ；并且刷新地址10次，查看日志如下：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:47.643\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173568757510019269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:68,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:50.980\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569097710029269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:51.542\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569153910049269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-4\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:52.061\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569205910069269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:2,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-6\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/sampler/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"48856a040da01abc84213934c1c5fce4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/sampler/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/sampler/","summary":"目前 SOFATracer 提供了两种采样模式，一种是基于 BitSet 实现的基于固定采样率的采样模式；另外一种是提供给用户自定义实现采样的采样模式。下面通过案例来演示如何使","tags":null,"title":"采样模式","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/sampler/","wordcount":719},{"author":null,"categories":null,"content":" 链路数据透传 链路数据透传功能支持应用向调用上下文中存放数据，达到整个链路上的应用都可以操作该数据。 使用方式如下，可分别向链路的 request 和 response 中放入数据进行透传，并可获取到链路中相应的数据。\nRpcInvokeContext.getContext().putRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;,\u0026amp;quot;value_request\u0026amp;quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;,\u0026amp;quot;value_response\u0026amp;quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;); 使用示例 例如 A -\u0026amp;gt; B -\u0026amp;gt; C 的场景中，将 A 设置的请求隐式传参数据传递给 B 和 C。在返回的时候，将 C 和 B 的响应隐式传参数据传递给 A。\nA 请求方设置的时候：\n// 调用前设置请求透传的值 RpcInvokeContext context = RpcInvokeContext.getContext(); context.putRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;, \u0026amp;quot;a2bbb\u0026amp;quot;); // 调用 String result = service.hello(); // 拿到结果透传的值 context.getResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;); B 业务代码中：\npublic String hello() { // 拿到请求透传的值 RpcInvokeContext context = RpcInvokeContext.getContext(); String reqBaggage = context.getRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;); // doSomthing(); // 结果透传一个值 context.putResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;, \u0026amp;quot;b2aaa\u0026amp;quot;); return result; } 如果中途自己启动了子线程，则需要设置子线程的上下文：\nCountDownLatch latch = new CountDownLatch(1); final RpcInvokeContext parentContext = RpcInvokeContext.peekContext(); Thread thread = new Thread(new Runnable(){ public void run(){ try { RpcInvokeContext.setContext(parentContext); // 调一个远程服务 xxxService.sayHello(); latch.countDown(); } finally { RpcInvokeContext.removeContext(); } } }, \u0026amp;quot;new-thread\u0026amp;quot;); thread.start(); // 此时拿不到返回值透传的数据的 latch.await(); //等待 // 此时返回结束，能拿到返回透传的值 和 SOFATracer 的比较 SOFATracer 是蚂蚁开源的一个分布式链路追踪系统,RPC 目前已经和 Tracer 做了集成,默认开启. 和 Tracer 进行数据传递不同的是\n RPC的数据透传更偏向业务使用,而且可以在全链路中进行双向传递,调用方可以传给服务方,服务方也可以传递信息给调用方,SOFATracer 更加偏向于中间件和业务无感知的数据的传递,只能进行单向传递. RPC的透传可以选择性地不在全链路中透传,而Tracer 中如果传递大量信息,会在整个链路中传递.可能对下游业务会有影响. 所以整体来看,两个信息各有利弊,在有一些和业务相关的透传数据的情况下,可以选择 RPC 的透传.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-chain-pass-data/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"96cfb41f07a6a2ad979b53093ff5eee9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","summary":"链路数据透传 链路数据透传功能支持应用向调用上下文中存放数据，达到整个链路上的应用都可以操作该数据。 使用方式如下，可分别向链路的 request 和 response 中放入数","tags":null,"title":"链路数据透传","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","wordcount":606},{"author":null,"categories":null,"content":"默认 SOFARPC 已经集成了 SOFATracer，用户也可以使用其他的 APM 产品，如 Skywalking来实现相应的功能。详见文档：\n SOFATracer Skywalking 如果想要关闭 SOFARPC 的链路追踪能力的话，在使用了 rpc-sofa-boot-starter 的情况下，可以在 application.properties 配置文件中配置 com.alipay.sofa.rpc.defaultTracer=。\n在直接使用 sofa-rpc-all 的情况下，可以在 main 函数里面加上如下的代码来关闭 SOFARPC 的链路追踪的能力（在发布任何 SOFARPC 的服务或者引用任何 SOFARPC 的服务之前）：\nRpcConfigs.putValue(RpcOptions.DEFAULT_TRACER, \u0026amp;quot;\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/tracing-usage/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5f944f87d827ae060fb0528f6715af97","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/tracing-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/tracing-usage/","summary":"默认 SOFARPC 已经集成了 SOFATracer，用户也可以使用其他的 APM 产品，如 Skywalking来实现相应的功能。详见文档： SOFATracer Skywalking 如果想要关闭 SOFARPC 的链路","tags":null,"title":"链路追踪","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/tracing-usage/","wordcount":197},{"author":null,"categories":null,"content":" 从 rpc-sofa-boot-starter 6.0.1 版本开始，SOFARPC 提供了 RESTful 服务和 Swagger 的一键集成的能力。\n在使用了 rpc-sofa-boot-starter 的情况下，如果想要开启 swagger 的能力，首先需要在 pom.xml 中增加 Swagger 的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 里面增加 com.alipay.sofa.rpc.restSwagger=true。\n最后，访问 http://localhost:8341/swagger/openapi 就可以拿到 SOFARPC 的 RESTful 的 Swagger OpenAPI 内容。\n如果没有使用 rpc-sofa-boot-starter 或者在 rpc-sofa-boot-starter 的版本低于 6.0.1，可以采用如下的方式集成 Swagger。\n首先，需要在应用中引入 Swagger 相关的依赖，由于 SOFARPC 的 RESTful 协议走的是 JAXRS 标准，因此我们引入 Swagger 的 JAXRS 依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 上面引入 Guava 的 20.0 的版本是为了解决 Guava 的版本冲突。\n增加一个 Swagger 的 RESTful 服务 为了能够让 Swagger 将 SOFARPC 的 RESTful 的服务通过 Swagger OpenAPI 暴露出去，我们可以反过来用 SOFARPC 的 RESTful 的服务提供 Swagger 的 OpenAPI 服务。首先，需要新建一个接口：\n@Path(\u0026amp;quot;swagger\u0026amp;quot;) public interface OpenApiService { @GET @Path(\u0026amp;quot;openapi\u0026amp;quot;) @Produces(\u0026amp;quot;application/json\u0026amp;quot;) String openApi(); } 然后提供一个实现类，并且发布成 SOFARPC 的 RESTful 的服务：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}, interfaceType = OpenApiService.class) public class OpenApiServiceImpl implements OpenApiService, InitializingBean { private OpenAPI openAPI; @Override public String openApi() { return Json.pretty(openAPI); } @Override public void afterPropertiesSet() { List\u0026amp;lt;Package\u0026amp;gt; resources = new ArrayList\u0026amp;lt;\u0026amp;gt;(); resources.add(this.getClass().getPackage()); // 扫描当前类所在的 Package，也可以扫描其他的 SOFARPC RESTful 服务接口所在的 Package if (!resources.isEmpty()) { // init context try { SwaggerConfiguration oasConfig = new SwaggerConfiguration() .resourcePackages(resources.stream().map(Package::getName).collect(Collectors.toSet())); OpenApiContext oac = new JaxrsOpenApiContextBuilder() .openApiConfiguration(oasConfig) .buildContext(true); openAPI = oac.read(); } catch (OpenApiConfigurationException e) { throw new RuntimeException(e.getMessage(), e); } } } } 这样，应用启动后，访问 http://localhost:8341/swagger/openapi 即可得到当前的应用发布的所有的 RESTful 的服务的信息。\n解决跨域问题 如果用户在另外一个端口中启动了一个 Swagger UI，并且希望通过 Swagger UI 来访问 http://localhost:8341/swagger/openapi 查看 API 定义，发起调用，那么可能需要解决访问跨域的问题，要解决 SOFARPC RESTful 服务访问跨域的问题，可以在应用启动前增加如下的代码：\nimport org.jboss.resteasy.plugins.interceptors.CorsFilter; public static void main(String[] args) { CorsFilter corsFilter = new CorsFilter(); corsFilter.getAllowedOrigins().add(\u0026amp;quot;*\u0026amp;quot;); …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-swagger/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d068767fe0dd2922eecef69736684be8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-swagger/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-swagger/","summary":"从 rpc-sofa-boot-starter 6.0.1 版本开始，SOFARPC 提供了 RESTful 服务和 Swagger 的一键集成的能力。 在使用了 rpc-sofa-boot-starter 的情况下，如果想要开启 swagger 的能力，首先需要在 pom.xml 中增加 Swagger 的依赖： \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.swagger.core.v3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;swagger-jaxrs2\u0026lt;/artifactId\u0026gt;","tags":null,"title":"集成 SOFARPC RESTful 服务和 Swagger","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-swagger/","wordcount":646},{"author":null,"categories":null,"content":" 服务发布 服务发布过程涉及到三个类 RegistryConfig ，ServerConfig ，ProviderConfig 。\n1. RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;) RegistryConfig 表示注册中心。如上声明了服务注册中心的地址和端口是127.0.0.1:2181，协议是 Zookeeper。\n2. ServerConfig\nServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ServerConfig 表示服务运行容器。如上声明了一个使用8803端口和 bolt 协议的 server 。\n3. ProviderConfig\nProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt;() .setInterfaceId(HelloWorldService.class.getName()) .setRef(new HelloWorldServiceImpl()) .setServer(serverConfig) .setRegistry(registryConfig); providerConfig.export(); ProviderConfig 表示服务发布。如上声明了服务的接口，实现和该服务运行的 server 。 最终通过 export 方法将这个服务发布出去了。\n服务引用 服务引用涉及到两个类， RegistryConfig 和 ConsumerConfig 。\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig); HelloService helloService = consumerConfig.refer(); ConsumerConfig 表示服务引用，如上声明了所引用服务的接口和服务注册中心。 最终通过 refer 方法将这个服务引用，获取到该服务的远程调用的代理。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-rpc/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ee6f74a4974c7abf72322cef108d5ef0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-rpc/","summary":"服务发布 服务发布过程涉及到三个类 RegistryConfig ，ServerConfig ，ProviderConfig 。 1. RegistryConfig RegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026quot;zookeeper\u0026quot;) .setAddress(\u0026quot;127.0.0.1:2181\u0026quot;) RegistryConfig 表示注册中心。如上声明了服务","tags":null,"title":"非 Spring 环境 API 使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-rpc/","wordcount":300},{"author":null,"categories":null,"content":"预热权重功能让客户端机器能够根据服务端的相应权重进行流量的分发。该功能也常被用于集群内少数机器的启动场景。利用流量权重功能在短时间内对服务端机器进行预热，然后再接收正常的流量比重。 运行机制如下： 1.服务端服务在启动时会将自身的预热时间，预热期内权重，预热完成后的正常权重推送给服务注册中心。如上图 ServiceB 指向 Service Registry 。\n2.客户端在引用服务的时候会获得每个服务实例的预热权重信息。如上图 Service Registry 指向 client 。\n3.客户端在进行调用的时候会根据服务所在地址的预热时期所对应的权重进行流量分发。如上图 client 指向 ServiceA 和 ServiceB 。 ServiceA 预热完毕，权重默认 100 ， ServiceB 处于预热期，权重为 10，因此所承受流量分别为 100%110 和 10%110 。\n该功能使用方式如下。\nProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt;() .setWeight(100) .setParameter(ProviderInfoAttrs.ATTR_WARMUP_WEIGHT,\u0026amp;quot;10\u0026amp;quot;) .setParameter(ProviderInfoAttrs.ATTR_WARM_UP_END_TIME,\u0026amp;quot;12000\u0026amp;quot;); 如上，该服务的预热期为12s，在预热期内权重为10，预热期结束后的正常权重为100。如果该服务一共发布在两个机器A,B上，A机器正处于预热期内，并使用上述配置，B已经完成预热，正常权重为200。那么客户端在调用的时候，此时流量分发的比重为10：200，A机器预热结束后，流量分发比重为100：200。 在SOFABoot中，如下配置预热时间，预热期间权重和预热完后的权重即可。\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleRestFacadeReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.endpoint.facade.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs weight=\u0026amp;quot;100\u0026amp;quot; warm-up-time=\u0026amp;quot;10000\u0026amp;quot; warm-up-weight=\u0026amp;quot;1000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/provider-warmup-weight/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b9e320dfaa4f9700ecdca67d76e07d54","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","summary":"预热权重功能让客户端机器能够根据服务端的相应权重进行流量的分发。该功能也常被用于集群内少数机器的启动场景。利用流量权重功能在短时间内对服务端","tags":null,"title":"预热权重","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","wordcount":497}] \ No newline at end of file diff --git a/blog/2021-cloud-native-technology-development-status-and-future-trends/index.html b/blog/2021-cloud-native-technology-development-status-and-future-trends/index.html index 4db3fa22..41f72d8b 100644 --- a/blog/2021-cloud-native-technology-development-status-and-future-trends/index.html +++ b/blog/2021-cloud-native-technology-development-status-and-future-trends/index.html @@ -483,7 +483,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -519,7 +519,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -605,7 +605,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -643,7 +643,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/index.html b/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/index.html index 9b38ea8f..8adfd464 100644 --- a/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/index.html +++ b/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/index.html @@ -483,7 +483,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -519,7 +519,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -605,7 +605,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -643,7 +643,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/20220920/index.html b/blog/20220920/index.html index 2ffff843..e9a79ec3 100644 --- a/blog/20220920/index.html +++ b/blog/20220920/index.html @@ -611,7 +611,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -647,7 +647,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -733,7 +733,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -771,7 +771,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/20220929/index.html b/blog/20220929/index.html index 19bdd596..9fc2506c 100644 --- a/blog/20220929/index.html +++ b/blog/20220929/index.html @@ -353,7 +353,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -389,7 +389,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -475,7 +475,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -513,7 +513,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/a-new-generation-of-log-based-systems-in-sofajraft/index.html b/blog/a-new-generation-of-log-based-systems-in-sofajraft/index.html index ba8582d3..055f67f8 100644 --- a/blog/a-new-generation-of-log-based-systems-in-sofajraft/index.html +++ b/blog/a-new-generation-of-log-based-systems-in-sofajraft/index.html @@ -760,7 +760,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -796,7 +796,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -882,7 +882,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -920,7 +920,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/alipay-deep-learning-tensorflow-elasticdl/index.html b/blog/alipay-deep-learning-tensorflow-elasticdl/index.html index e0474cfc..224b9fb9 100644 --- a/blog/alipay-deep-learning-tensorflow-elasticdl/index.html +++ b/blog/alipay-deep-learning-tensorflow-elasticdl/index.html @@ -387,7 +387,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -423,7 +423,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -509,7 +509,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -547,7 +547,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/announcing-sofastack-open-source/index.html b/blog/announcing-sofastack-open-source/index.html index 843de5af..a08d5917 100644 --- a/blog/announcing-sofastack-open-source/index.html +++ b/blog/announcing-sofastack-open-source/index.html @@ -319,7 +319,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -355,7 +355,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -441,7 +441,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -479,7 +479,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-financial-db-mesh-explore-practice/index.html b/blog/ant-financial-db-mesh-explore-practice/index.html index d482301a..3980e4d9 100644 --- a/blog/ant-financial-db-mesh-explore-practice/index.html +++ b/blog/ant-financial-db-mesh-explore-practice/index.html @@ -357,7 +357,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -393,7 +393,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -479,7 +479,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -517,7 +517,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-financial-happy-1024/index.html b/blog/ant-financial-happy-1024/index.html index 3c6be279..864c7cc9 100644 --- a/blog/ant-financial-happy-1024/index.html +++ b/blog/ant-financial-happy-1024/index.html @@ -368,7 +368,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -404,7 +404,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -490,7 +490,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -528,7 +528,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-financial-managing-large-scale-kubernetes-clusters/index.html b/blog/ant-financial-managing-large-scale-kubernetes-clusters/index.html index d59448df..947fca26 100644 --- a/blog/ant-financial-managing-large-scale-kubernetes-clusters/index.html +++ b/blog/ant-financial-managing-large-scale-kubernetes-clusters/index.html @@ -440,7 +440,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -476,7 +476,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -562,7 +562,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -600,7 +600,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-financial-native-cloud-financial-architecture/index.html b/blog/ant-financial-native-cloud-financial-architecture/index.html index afd3c3f9..c8bb78eb 100644 --- a/blog/ant-financial-native-cloud-financial-architecture/index.html +++ b/blog/ant-financial-native-cloud-financial-architecture/index.html @@ -389,7 +389,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -425,7 +425,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -511,7 +511,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -549,7 +549,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-financial-native-cloud-security-architecture/index.html b/blog/ant-financial-native-cloud-security-architecture/index.html index 84792779..ca5d64e5 100644 --- a/blog/ant-financial-native-cloud-security-architecture/index.html +++ b/blog/ant-financial-native-cloud-security-architecture/index.html @@ -373,7 +373,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -409,7 +409,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -495,7 +495,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -533,7 +533,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/index.html b/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/index.html index 8c4da465..df0c5927 100644 --- a/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/index.html +++ b/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/index.html @@ -412,7 +412,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -448,7 +448,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -534,7 +534,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -572,7 +572,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-group-sofatracer-principles-and-practices/index.html b/blog/ant-group-sofatracer-principles-and-practices/index.html index 2b9c0352..02e836d3 100644 --- a/blog/ant-group-sofatracer-principles-and-practices/index.html +++ b/blog/ant-group-sofatracer-principles-and-practices/index.html @@ -546,7 +546,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -582,7 +582,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -668,7 +668,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -706,7 +706,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-group-technical-risk-coding-platform-in-practice-maas/index.html b/blog/ant-group-technical-risk-coding-platform-in-practice-maas/index.html index 8d76d9fd..0a02af0d 100644 --- a/blog/ant-group-technical-risk-coding-platform-in-practice-maas/index.html +++ b/blog/ant-group-technical-risk-coding-platform-in-practice-maas/index.html @@ -567,7 +567,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -603,7 +603,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -689,7 +689,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -727,7 +727,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/index.html b/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/index.html index 57c8da51..56213e10 100644 --- a/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/index.html +++ b/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/index.html @@ -650,7 +650,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -686,7 +686,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -772,7 +772,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -810,7 +810,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-intelligent-monitoring/index.html b/blog/ant-intelligent-monitoring/index.html index b891be5b..7cc3df61 100644 --- a/blog/ant-intelligent-monitoring/index.html +++ b/blog/ant-intelligent-monitoring/index.html @@ -599,7 +599,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -635,7 +635,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -721,7 +721,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -759,7 +759,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/index.html b/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/index.html index 65172d70..26693e08 100644 --- a/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/index.html +++ b/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/index.html @@ -741,10 +741,10 @@

  • SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验
    • -
  • SOFAArk Committer 专访｜看它不爽，就直接动手改！
    • -
  • 深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进
    • +
  • SOFAArk Committer 专访｜看它不爽，就直接动手改！
    • + @@ -760,7 +760,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -796,7 +796,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -882,7 +882,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -920,7 +920,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ant-security-technology-nydus-mirror-acceleration-practice/index.html b/blog/ant-security-technology-nydus-mirror-acceleration-practice/index.html index 8b68dde6..2df6632a 100644 --- a/blog/ant-security-technology-nydus-mirror-acceleration-practice/index.html +++ b/blog/ant-security-technology-nydus-mirror-acceleration-practice/index.html @@ -617,7 +617,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -653,7 +653,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -739,7 +739,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -777,7 +777,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/antfin-middleware-open-source-key-figure-luzhi/index.html b/blog/antfin-middleware-open-source-key-figure-luzhi/index.html index 24e8c179..349d77ca 100644 --- a/blog/antfin-middleware-open-source-key-figure-luzhi/index.html +++ b/blog/antfin-middleware-open-source-key-figure-luzhi/index.html @@ -404,7 +404,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -440,7 +440,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -526,7 +526,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -564,7 +564,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/antfin-monitoring-cloud-native-observable-market-design-overview/index.html b/blog/antfin-monitoring-cloud-native-observable-market-design-overview/index.html index e58817ec..12a5f70b 100644 --- a/blog/antfin-monitoring-cloud-native-observable-market-design-overview/index.html +++ b/blog/antfin-monitoring-cloud-native-observable-market-design-overview/index.html @@ -442,7 +442,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -478,7 +478,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -564,7 +564,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -602,7 +602,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/antfin-service-mesh-monitor-landing-experience/index.html b/blog/antfin-service-mesh-monitor-landing-experience/index.html index 7ded8b0c..7c3c1c8e 100644 --- a/blog/antfin-service-mesh-monitor-landing-experience/index.html +++ b/blog/antfin-service-mesh-monitor-landing-experience/index.html @@ -433,7 +433,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -469,7 +469,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -555,7 +555,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -593,7 +593,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/antfin-service-mesh-network-agents/index.html b/blog/antfin-service-mesh-network-agents/index.html index edb5d597..36172bbd 100644 --- a/blog/antfin-service-mesh-network-agents/index.html +++ b/blog/antfin-service-mesh-network-agents/index.html @@ -629,7 +629,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -665,7 +665,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -751,7 +751,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -789,7 +789,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/antfin-zsearch-vector-search/index.html b/blog/antfin-zsearch-vector-search/index.html index f773be88..96069c2d 100644 --- a/blog/antfin-zsearch-vector-search/index.html +++ b/blog/antfin-zsearch-vector-search/index.html @@ -626,7 +626,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -662,7 +662,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -748,7 +748,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -786,7 +786,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/index.html b/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/index.html index c5d1eda1..51ca81e5 100644 --- a/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/index.html +++ b/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/index.html @@ -346,7 +346,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -382,7 +382,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -468,7 +468,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -506,7 +506,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/antgroup-kubernetes-high-slo/index.html b/blog/antgroup-kubernetes-high-slo/index.html index 920ceddc..75d7eba9 100644 --- a/blog/antgroup-kubernetes-high-slo/index.html +++ b/blog/antgroup-kubernetes-high-slo/index.html @@ -338,7 +338,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -374,7 +374,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -460,7 +460,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -498,7 +498,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/antgroup-serverless-task/index.html b/blog/antgroup-serverless-task/index.html index e5ec2810..27bfbaa3 100644 --- a/blog/antgroup-serverless-task/index.html +++ b/blog/antgroup-serverless-task/index.html @@ -347,7 +347,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -383,7 +383,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -469,7 +469,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -507,7 +507,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/index.html b/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/index.html index a62fd76a..f8ab0076 100644 --- a/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/index.html +++ b/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/index.html @@ -591,7 +591,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -627,7 +627,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -713,7 +713,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -751,7 +751,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/index.html b/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/index.html index b76ed885..5a94d4e2 100644 --- a/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/index.html +++ b/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/index.html @@ -358,7 +358,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -394,7 +394,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -480,7 +480,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -518,7 +518,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/index.html b/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/index.html index c7a89a75..33adb2ab 100644 --- a/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/index.html +++ b/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/index.html @@ -352,7 +352,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -388,7 +388,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -474,7 +474,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -512,7 +512,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/index.html b/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/index.html index bc413fa5..7b91c36b 100644 --- a/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/index.html +++ b/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/index.html @@ -395,7 +395,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -431,7 +431,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -517,7 +517,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -555,7 +555,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/index.html b/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/index.html index b370b9e0..df6d75fb 100644 --- a/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/index.html +++ b/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/index.html @@ -571,7 +571,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -607,7 +607,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -693,7 +693,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -731,7 +731,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/index.html b/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/index.html index e94eda77..1e543510 100644 --- a/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/index.html +++ b/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/index.html @@ -538,7 +538,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -574,7 +574,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -660,7 +660,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -698,7 +698,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/build-subset-optimization/index.html b/blog/build-subset-optimization/index.html index bb18a3f7..843d9dfe 100644 --- a/blog/build-subset-optimization/index.html +++ b/blog/build-subset-optimization/index.html @@ -487,7 +487,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -523,7 +523,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -609,7 +609,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -647,7 +647,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/c-go-mechanism-calling-go-from-c/20221008/index.html b/blog/c-go-mechanism-calling-go-from-c/20221008/index.html index 2d8df8a7..3921b0b0 100644 --- a/blog/c-go-mechanism-calling-go-from-c/20221008/index.html +++ b/blog/c-go-mechanism-calling-go-from-c/20221008/index.html @@ -515,7 +515,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -551,7 +551,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -637,7 +637,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -675,7 +675,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/index.html b/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/index.html index 965017aa..81096f47 100644 --- a/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/index.html +++ b/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/index.html @@ -605,7 +605,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -641,7 +641,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -727,7 +727,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -765,7 +765,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/cloud-native-network-proxy-mosn-evolutionary-path/index.html b/blog/cloud-native-network-proxy-mosn-evolutionary-path/index.html index ff11b91f..89855795 100644 --- a/blog/cloud-native-network-proxy-mosn-evolutionary-path/index.html +++ b/blog/cloud-native-network-proxy-mosn-evolutionary-path/index.html @@ -547,7 +547,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -583,7 +583,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -669,7 +669,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -707,7 +707,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/index.html b/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/index.html index 2643c82c..03ceac16 100644 --- a/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/index.html +++ b/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/index.html @@ -453,7 +453,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -489,7 +489,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -575,7 +575,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -613,7 +613,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/index.html b/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/index.html index bc6a387a..37a4ea32 100644 --- a/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/index.html +++ b/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/index.html @@ -481,7 +481,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -517,7 +517,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -603,7 +603,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -641,7 +641,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/community-article-mosn-routing-framework-explained/index.html b/blog/community-article-mosn-routing-framework-explained/index.html index 66ff7cda..da78520d 100644 --- a/blog/community-article-mosn-routing-framework-explained/index.html +++ b/blog/community-article-mosn-routing-framework-explained/index.html @@ -497,7 +497,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -533,7 +533,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -619,7 +619,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -657,7 +657,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/index.html b/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/index.html index 6d878ad0..8fbcc244 100644 --- a/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/index.html +++ b/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/index.html @@ -358,7 +358,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -394,7 +394,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -480,7 +480,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -518,7 +518,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/container-image-basics/index.html b/blog/container-image-basics/index.html index c48626f1..668fdb8f 100644 --- a/blog/container-image-basics/index.html +++ b/blog/container-image-basics/index.html @@ -885,7 +885,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -921,7 +921,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -1007,7 +1007,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -1045,7 +1045,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/index.html b/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/index.html index 6bee3575..9d0d62c7 100644 --- a/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/index.html +++ b/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/index.html @@ -476,7 +476,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -512,7 +512,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -598,7 +598,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -636,7 +636,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/index.html b/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/index.html index cdcfc581..994e7ed5 100644 --- a/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/index.html +++ b/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/index.html @@ -609,7 +609,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -645,7 +645,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -731,7 +731,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -769,7 +769,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/deeperinto-http-3-2-the-not-so-boring-ssl/index.html b/blog/deeperinto-http-3-2-the-not-so-boring-ssl/index.html index edfffc74..2958f922 100644 --- a/blog/deeperinto-http-3-2-the-not-so-boring-ssl/index.html +++ b/blog/deeperinto-http-3-2-the-not-so-boring-ssl/index.html @@ -554,7 +554,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -590,7 +590,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -676,7 +676,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -714,7 +714,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/distributed-arch-in-the-enterprise/index.html b/blog/distributed-arch-in-the-enterprise/index.html index eec45f06..fe225578 100644 --- a/blog/distributed-arch-in-the-enterprise/index.html +++ b/blog/distributed-arch-in-the-enterprise/index.html @@ -398,7 +398,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -434,7 +434,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -520,7 +520,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -558,7 +558,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/distributed-architecture-and-cloud-native/index.html b/blog/distributed-architecture-and-cloud-native/index.html index 97b82d7f..4d926f0d 100644 --- a/blog/distributed-architecture-and-cloud-native/index.html +++ b/blog/distributed-architecture-and-cloud-native/index.html @@ -405,7 +405,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -441,7 +441,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -527,7 +527,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -565,7 +565,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/index.html b/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/index.html index 1431b482..8cc658d7 100644 --- a/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/index.html +++ b/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/index.html @@ -409,7 +409,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -445,7 +445,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -531,7 +531,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -569,7 +569,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/index.html b/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/index.html index 5b38b93a..f0403ff6 100644 --- a/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/index.html +++ b/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/index.html @@ -613,7 +613,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -649,7 +649,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -735,7 +735,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -773,7 +773,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/dragonfly-and-nydus-mirror-mode-integration-practice/index.html b/blog/dragonfly-and-nydus-mirror-mode-integration-practice/index.html index c6adde55..2762cf59 100644 --- a/blog/dragonfly-and-nydus-mirror-mode-integration-practice/index.html +++ b/blog/dragonfly-and-nydus-mirror-mode-integration-practice/index.html @@ -682,7 +682,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -718,7 +718,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -804,7 +804,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -842,7 +842,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/index.html b/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/index.html index 36f099bb..2b61c5c8 100644 --- a/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/index.html +++ b/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/index.html @@ -751,7 +751,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -787,7 +787,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -873,7 +873,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -911,7 +911,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/dragonfly-v-2-1-0-release/index.html b/blog/dragonfly-v-2-1-0-release/index.html index 7d766f28..b0bdfa93 100644 --- a/blog/dragonfly-v-2-1-0-release/index.html +++ b/blog/dragonfly-v-2-1-0-release/index.html @@ -409,7 +409,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -445,7 +445,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -531,7 +531,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -569,7 +569,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/index.html b/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/index.html index cefece56..38169fdc 100644 --- a/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/index.html +++ b/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/index.html @@ -376,7 +376,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -412,7 +412,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -498,7 +498,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -536,7 +536,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/index.html b/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/index.html index 7cf99063..5210c447 100644 --- a/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/index.html +++ b/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/index.html @@ -499,7 +499,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -535,7 +535,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -621,7 +621,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -659,7 +659,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/index.html b/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/index.html index d5a344fb..e6bdaaef 100644 --- a/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/index.html +++ b/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/index.html @@ -704,7 +704,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -740,7 +740,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -826,7 +826,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -864,7 +864,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/end-to-end-ai-system-sqlflow/index.html b/blog/end-to-end-ai-system-sqlflow/index.html index b72f8d6c..13b23ac6 100644 --- a/blog/end-to-end-ai-system-sqlflow/index.html +++ b/blog/end-to-end-ai-system-sqlflow/index.html @@ -491,7 +491,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -527,7 +527,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -613,7 +613,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -651,7 +651,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/index.html b/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/index.html index 07e3a802..5c7178f5 100644 --- a/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/index.html +++ b/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/index.html @@ -502,7 +502,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -538,7 +538,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -624,7 +624,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -662,7 +662,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/exploration-and-practice-of-service-mesh-in-icbc/index.html b/blog/exploration-and-practice-of-service-mesh-in-icbc/index.html index 47f7a0e8..b7e37b5e 100644 --- a/blog/exploration-and-practice-of-service-mesh-in-icbc/index.html +++ b/blog/exploration-and-practice-of-service-mesh-in-icbc/index.html @@ -421,7 +421,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -457,7 +457,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -543,7 +543,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -581,7 +581,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/index.html b/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/index.html index 06c7a715..2c2a3c32 100644 --- a/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/index.html +++ b/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/index.html @@ -551,7 +551,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -587,7 +587,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -673,7 +673,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -711,7 +711,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/index.html b/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/index.html index f9799763..4c1eda28 100644 --- a/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/index.html +++ b/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/index.html @@ -401,7 +401,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -437,7 +437,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -523,7 +523,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -561,7 +561,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/explore-sofaregistry-1-infrastructure/index.html b/blog/explore-sofaregistry-1-infrastructure/index.html index 3fa99fdb..b1c6d952 100644 --- a/blog/explore-sofaregistry-1-infrastructure/index.html +++ b/blog/explore-sofaregistry-1-infrastructure/index.html @@ -555,7 +555,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -591,7 +591,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -677,7 +677,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -715,7 +715,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/explore-the-workflow-of-mosn-from-an-rpc-request/index.html b/blog/explore-the-workflow-of-mosn-from-an-rpc-request/index.html index e4448bf1..813c9f94 100644 --- a/blog/explore-the-workflow-of-mosn-from-an-rpc-request/index.html +++ b/blog/explore-the-workflow-of-mosn-from-an-rpc-request/index.html @@ -606,7 +606,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -642,7 +642,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -728,7 +728,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -766,7 +766,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/financial-technology-meet-open-source/index.html b/blog/financial-technology-meet-open-source/index.html index 44deb28a..dccc1ee5 100644 --- a/blog/financial-technology-meet-open-source/index.html +++ b/blog/financial-technology-meet-open-source/index.html @@ -413,7 +413,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -449,7 +449,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -535,7 +535,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -573,7 +573,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/five-years-to-ali-p8/index.html b/blog/five-years-to-ali-p8/index.html index 034a612a..2ff943fb 100644 --- a/blog/five-years-to-ali-p8/index.html +++ b/blog/five-years-to-ali-p8/index.html @@ -341,7 +341,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -377,7 +377,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -463,7 +463,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -501,7 +501,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/forrester-daipeng-white-paper-cloud-native/index.html b/blog/forrester-daipeng-white-paper-cloud-native/index.html index 71ef9e90..8a7f9e77 100644 --- a/blog/forrester-daipeng-white-paper-cloud-native/index.html +++ b/blog/forrester-daipeng-white-paper-cloud-native/index.html @@ -329,7 +329,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -365,7 +365,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -451,7 +451,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -489,7 +489,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/go-code-city-cloud-kusionstack-practice/index.html b/blog/go-code-city-cloud-kusionstack-practice/index.html index 48985916..71d062f0 100644 --- a/blog/go-code-city-cloud-kusionstack-practice/index.html +++ b/blog/go-code-city-cloud-kusionstack-practice/index.html @@ -444,7 +444,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -480,7 +480,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -566,7 +566,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -604,7 +604,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/go-language-how-to-do-inverse-type-derivation/index.html b/blog/go-language-how-to-do-inverse-type-derivation/index.html index 92032304..5a741baa 100644 --- a/blog/go-language-how-to-do-inverse-type-derivation/index.html +++ b/blog/go-language-how-to-do-inverse-type-derivation/index.html @@ -444,7 +444,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -480,7 +480,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -566,7 +566,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -604,7 +604,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/go-native-plug-in-use-problem-full-analysis/index.html b/blog/go-native-plug-in-use-problem-full-analysis/index.html index dfdb4eeb..ff7c7f0f 100644 --- a/blog/go-native-plug-in-use-problem-full-analysis/index.html +++ b/blog/go-native-plug-in-use-problem-full-analysis/index.html @@ -576,7 +576,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -612,7 +612,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -698,7 +698,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -736,7 +736,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/go-sql-driver-amazing-bug/index.html b/blog/go-sql-driver-amazing-bug/index.html index a1c43461..a47ffca5 100644 --- a/blog/go-sql-driver-amazing-bug/index.html +++ b/blog/go-sql-driver-amazing-bug/index.html @@ -500,7 +500,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -536,7 +536,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -622,7 +622,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -660,7 +660,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/index.html b/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/index.html index bddbc7cb..2dadab44 100644 --- a/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/index.html +++ b/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/index.html @@ -324,7 +324,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -360,7 +360,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -446,7 +446,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -484,7 +484,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/index.html b/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/index.html index e84c1f5b..74be2b06 100644 --- a/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/index.html +++ b/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/index.html @@ -381,7 +381,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -417,7 +417,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -503,7 +503,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -541,7 +541,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/index.html b/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/index.html index 28ca34ce..495671b3 100644 --- a/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/index.html +++ b/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/index.html @@ -729,7 +729,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -765,7 +765,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -851,7 +851,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -889,7 +889,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/index.html b/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/index.html index d5621704..1244734e 100644 --- a/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/index.html +++ b/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/index.html @@ -550,7 +550,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -586,7 +586,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -672,7 +672,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -710,7 +710,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/index.html b/blog/index.html index a764c977..b97abf82 100644 --- a/blog/index.html +++ b/blog/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/is-pprof-enough-for-go-memory-leak/index.html b/blog/is-pprof-enough-for-go-memory-leak/index.html index 58d2bdbe..08e36a69 100644 --- a/blog/is-pprof-enough-for-go-memory-leak/index.html +++ b/blog/is-pprof-enough-for-go-memory-leak/index.html @@ -413,7 +413,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -449,7 +449,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -535,7 +535,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -573,7 +573,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/is-sidecarless-the-next-stop-for-servicemesh/index.html b/blog/is-sidecarless-the-next-stop-for-servicemesh/index.html index dd388441..5ba8dbfe 100644 --- a/blog/is-sidecarless-the-next-stop-for-servicemesh/index.html +++ b/blog/is-sidecarless-the-next-stop-for-servicemesh/index.html @@ -442,7 +442,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -478,7 +478,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -564,7 +564,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -602,7 +602,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/java-kubernetes-operator-kubecon-na2019/index.html b/blog/java-kubernetes-operator-kubecon-na2019/index.html index 579c7f1a..901eaecf 100644 --- a/blog/java-kubernetes-operator-kubecon-na2019/index.html +++ b/blog/java-kubernetes-operator-kubecon-na2019/index.html @@ -362,7 +362,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -398,7 +398,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -484,7 +484,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -522,7 +522,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/k8s-1.14-release-note/index.html b/blog/k8s-1.14-release-note/index.html index e30c925a..4885e7f0 100644 --- a/blog/k8s-1.14-release-note/index.html +++ b/blog/k8s-1.14-release-note/index.html @@ -373,7 +373,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -409,7 +409,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -495,7 +495,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -533,7 +533,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/kata-container-2.0-road-to-attack/index.html b/blog/kata-container-2.0-road-to-attack/index.html index c670a5fa..3b5d4a3f 100644 --- a/blog/kata-container-2.0-road-to-attack/index.html +++ b/blog/kata-container-2.0-road-to-attack/index.html @@ -343,7 +343,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -379,7 +379,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -465,7 +465,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -503,7 +503,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/kata-container-introduction-to-safe-containers/index.html b/blog/kata-container-introduction-to-safe-containers/index.html index b0103b20..9aada147 100644 --- a/blog/kata-container-introduction-to-safe-containers/index.html +++ b/blog/kata-container-introduction-to-safe-containers/index.html @@ -384,7 +384,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -420,7 +420,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -506,7 +506,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -544,7 +544,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/kcl-a-declarative-cloud-native-configuration-policy-language/index.html b/blog/kcl-a-declarative-cloud-native-configuration-policy-language/index.html index 252052a7..4d2eb2be 100644 --- a/blog/kcl-a-declarative-cloud-native-configuration-policy-language/index.html +++ b/blog/kcl-a-declarative-cloud-native-configuration-policy-language/index.html @@ -728,7 +728,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -764,7 +764,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -850,7 +850,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -888,7 +888,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/knative-serverless-kubecon-na2019/index.html b/blog/knative-serverless-kubecon-na2019/index.html index ea2ff383..398e92f4 100644 --- a/blog/knative-serverless-kubecon-na2019/index.html +++ b/blog/knative-serverless-kubecon-na2019/index.html @@ -373,7 +373,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -409,7 +409,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -495,7 +495,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -533,7 +533,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/index.html b/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/index.html index 7b7373cb..8678ac6e 100644 --- a/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/index.html +++ b/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/index.html @@ -533,7 +533,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -569,7 +569,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -655,7 +655,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -693,7 +693,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/kubernetes-practice-antfinal-shopping-festival/index.html b/blog/kubernetes-practice-antfinal-shopping-festival/index.html index 5ac691a8..f46122f8 100644 --- a/blog/kubernetes-practice-antfinal-shopping-festival/index.html +++ b/blog/kubernetes-practice-antfinal-shopping-festival/index.html @@ -426,7 +426,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -462,7 +462,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -548,7 +548,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -586,7 +586,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/kubernetes-the-next-gen-os/index.html b/blog/kubernetes-the-next-gen-os/index.html index d3562d86..d80df621 100644 --- a/blog/kubernetes-the-next-gen-os/index.html +++ b/blog/kubernetes-the-next-gen-os/index.html @@ -675,7 +675,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -711,7 +711,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -797,7 +797,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -835,7 +835,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/kusionstack-in-practice-at-ant-group-first/index.html b/blog/kusionstack-in-practice-at-ant-group-first/index.html index 7a18d53f..cfa114d7 100644 --- a/blog/kusionstack-in-practice-at-ant-group-first/index.html +++ b/blog/kusionstack-in-practice-at-ant-group-first/index.html @@ -407,7 +407,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -443,7 +443,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -529,7 +529,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -567,7 +567,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/lunettes-makes-kubernetes-service-operations-easier/index.html b/blog/lunettes-makes-kubernetes-service-operations-easier/index.html index 1589856d..9246dc89 100644 --- a/blog/lunettes-makes-kubernetes-service-operations-easier/index.html +++ b/blog/lunettes-makes-kubernetes-service-operations-easier/index.html @@ -443,7 +443,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -479,7 +479,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -565,7 +565,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -603,7 +603,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/mecha-carry-mesh-to-the-end/index.html b/blog/mecha-carry-mesh-to-the-end/index.html index 2ef8f1b2..16f3d6a7 100644 --- a/blog/mecha-carry-mesh-to-the-end/index.html +++ b/blog/mecha-carry-mesh-to-the-end/index.html @@ -625,7 +625,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -661,7 +661,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -747,7 +747,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -785,7 +785,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/microkernel-distributed-operating-system-kubernetes/index.html b/blog/microkernel-distributed-operating-system-kubernetes/index.html index e0c51e53..43f798bd 100644 --- a/blog/microkernel-distributed-operating-system-kubernetes/index.html +++ b/blog/microkernel-distributed-operating-system-kubernetes/index.html @@ -391,7 +391,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -427,7 +427,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -513,7 +513,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -551,7 +551,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/index.html b/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/index.html index 52f26262..5a1eec50 100644 --- a/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/index.html +++ b/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/index.html @@ -719,7 +719,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -755,7 +755,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -841,7 +841,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -879,7 +879,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/microservices-service-mesh/index.html b/blog/microservices-service-mesh/index.html index fbe73bc9..81b7ded9 100644 --- a/blog/microservices-service-mesh/index.html +++ b/blog/microservices-service-mesh/index.html @@ -403,7 +403,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -439,7 +439,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -525,7 +525,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -563,7 +563,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/moe-series-1how-to-extend-envoy-with-golang/index.html b/blog/moe-series-1how-to-extend-envoy-with-golang/index.html index 1c633ea8..ffc79024 100644 --- a/blog/moe-series-1how-to-extend-envoy-with-golang/index.html +++ b/blog/moe-series-1how-to-extend-envoy-with-golang/index.html @@ -421,7 +421,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -457,7 +457,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -543,7 +543,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -581,7 +581,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/index.html b/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/index.html index 5f4ec838..a185816f 100644 --- a/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/index.html +++ b/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/index.html @@ -406,10 +406,10 @@

  • SOFA 五周年，Live Long and Prosper！
    • -
  • 缘起｜蚂蚁应用级服务发现的实践之路
    • -
  • 缘起｜蚂蚁应用级服务发现的实践之路
    • +
  • 缘起｜蚂蚁应用级服务发现的实践之路
    • +
  • MoE 系列（一）｜如何使用 Golang 扩展 Envoy
  • 火山引擎基于 Dragonfly 加速实践
    • @@ -429,7 +429,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -465,7 +465,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -551,7 +551,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -589,7 +589,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/index.html b/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/index.html index 26cff9a3..0c380f53 100644 --- a/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/index.html +++ b/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/index.html @@ -363,7 +363,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -399,7 +399,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -485,7 +485,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -523,7 +523,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/moe-series-4-go-extended-asynchronous-mode/index.html b/blog/moe-series-4-go-extended-asynchronous-mode/index.html index c3fe8055..507d8249 100644 --- a/blog/moe-series-4-go-extended-asynchronous-mode/index.html +++ b/blog/moe-series-4-go-extended-asynchronous-mode/index.html @@ -387,7 +387,7 @@

  • SOFA 五周年，Live Long and Prosper！
    • -
  • 缘起｜蚂蚁应用级服务发现的实践之路
    • +
  • 缘起｜蚂蚁应用级服务发现的实践之路
    • @@ -404,7 +404,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -440,7 +440,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -526,7 +526,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -564,7 +564,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/moe-series-5envoy-go-extensions-memory-security/index.html b/blog/moe-series-5envoy-go-extensions-memory-security/index.html index fb770556..539cac84 100644 --- a/blog/moe-series-5envoy-go-extensions-memory-security/index.html +++ b/blog/moe-series-5envoy-go-extensions-memory-security/index.html @@ -358,7 +358,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -394,7 +394,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -480,7 +480,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -518,7 +518,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/moe-series-7-envoy-go-extension-sandbox-security/index.html b/blog/moe-series-7-envoy-go-extension-sandbox-security/index.html index 1c8678cb..24d9f36b 100644 --- a/blog/moe-series-7-envoy-go-extension-sandbox-security/index.html +++ b/blog/moe-series-7-envoy-go-extension-sandbox-security/index.html @@ -358,7 +358,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -394,7 +394,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -480,7 +480,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -518,7 +518,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/moe-series6envoy-go-extensions-concurrency-security/index.html b/blog/moe-series6envoy-go-extensions-concurrency-security/index.html index 43e1c8ef..87c5459b 100644 --- a/blog/moe-series6envoy-go-extensions-concurrency-security/index.html +++ b/blog/moe-series6envoy-go-extensions-concurrency-security/index.html @@ -401,7 +401,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -437,7 +437,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -523,7 +523,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -561,7 +561,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/momo-service-mesh-exploration-and-practice/index.html b/blog/momo-service-mesh-exploration-and-practice/index.html index 074025e8..769098ca 100644 --- a/blog/momo-service-mesh-exploration-and-practice/index.html +++ b/blog/momo-service-mesh-exploration-and-practice/index.html @@ -485,7 +485,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -521,7 +521,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -607,7 +607,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -645,7 +645,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/mosn-1-0-released-starting-a-new-architectural-evolution/index.html b/blog/mosn-1-0-released-starting-a-new-architectural-evolution/index.html index 9155d7f9..87f96a80 100644 --- a/blog/mosn-1-0-released-starting-a-new-architectural-evolution/index.html +++ b/blog/mosn-1-0-released-starting-a-new-architectural-evolution/index.html @@ -504,7 +504,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -540,7 +540,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -626,7 +626,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -664,7 +664,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/index.html b/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/index.html index e51cc8c6..fcd3155a 100644 --- a/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/index.html +++ b/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/index.html @@ -409,7 +409,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -445,7 +445,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -531,7 +531,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -569,7 +569,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/index.html b/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/index.html index 76b50f53..76d5131e 100644 --- a/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/index.html +++ b/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/index.html @@ -752,7 +752,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -788,7 +788,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -874,7 +874,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -912,7 +912,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/mosn-istio-service-mesh/index.html b/blog/mosn-istio-service-mesh/index.html index 180538ea..9006278e 100644 --- a/blog/mosn-istio-service-mesh/index.html +++ b/blog/mosn-istio-service-mesh/index.html @@ -435,7 +435,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -471,7 +471,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -557,7 +557,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -595,7 +595,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/mosn-meetup-4-deploy-automation-at-large-scale/index.html b/blog/mosn-meetup-4-deploy-automation-at-large-scale/index.html index fdbe62b2..aa137afc 100644 --- a/blog/mosn-meetup-4-deploy-automation-at-large-scale/index.html +++ b/blog/mosn-meetup-4-deploy-automation-at-large-scale/index.html @@ -369,7 +369,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -405,7 +405,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -491,7 +491,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -529,7 +529,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/mosn-multi-protocol-extension-development-practice/index.html b/blog/mosn-multi-protocol-extension-development-practice/index.html index 60e99e69..b0e938f1 100644 --- a/blog/mosn-multi-protocol-extension-development-practice/index.html +++ b/blog/mosn-multi-protocol-extension-development-practice/index.html @@ -355,11 +355,11 @@

  • Gopher China 2021 专访之宋顺：Go 在蚂蚁集团的应用、实践
    • -
  • 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了
    • -
  • 【活动报名】SOFAMeetup#6 北京站，从数据库到架构，聊透分布式，玩转 Layotto
    • -
  • 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案
    • +
  • 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了
    • + +
  • 用安全计算保护关键业务
    • @@ -376,7 +376,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -412,7 +412,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -498,7 +498,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -536,7 +536,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/mosn-reverse-channel-explained/index.html b/blog/mosn-reverse-channel-explained/index.html index 9620517e..bde5d759 100644 --- a/blog/mosn-reverse-channel-explained/index.html +++ b/blog/mosn-reverse-channel-explained/index.html @@ -533,10 +533,10 @@

  • Seata 在蚂蚁国际银行业务的落地实践
    • -
  • KusionStack 开源｜Kusion 模型库和工具链的探索实践
    • -
  • Seata 多语言体系建设
    • +
  • KusionStack 开源｜Kusion 模型库和工具链的探索实践
    • +
  • Go 原生插件使用问题全解析
    • @@ -554,7 +554,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -590,7 +590,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -676,7 +676,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -714,7 +714,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/index.html b/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/index.html index 4550942f..7fdafecc 100644 --- a/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/index.html +++ b/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/index.html @@ -622,10 +622,10 @@

  • 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了
    • -
  • 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案
    • -
  • 用安全计算保护关键业务
    • +
  • 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案
    • + @@ -641,7 +641,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -677,7 +677,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -763,7 +763,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -801,7 +801,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/mosn-transparent-hijacking/index.html b/blog/mosn-transparent-hijacking/index.html index c1218f9b..95123a18 100644 --- a/blog/mosn-transparent-hijacking/index.html +++ b/blog/mosn-transparent-hijacking/index.html @@ -374,7 +374,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -410,7 +410,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -496,7 +496,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -534,7 +534,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/my-new-name-is-tongsuo/index.html b/blog/my-new-name-is-tongsuo/index.html index d11c92e5..986f120b 100644 --- a/blog/my-new-name-is-tongsuo/index.html +++ b/blog/my-new-name-is-tongsuo/index.html @@ -392,7 +392,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -428,7 +428,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -514,7 +514,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -552,7 +552,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/index.html b/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/index.html index ecb62841..2edece00 100644 --- a/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/index.html +++ b/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/index.html @@ -615,7 +615,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -651,7 +651,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -737,7 +737,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -775,7 +775,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/next-kubernetes-frontier-multi-cluster-management/index.html b/blog/next-kubernetes-frontier-multi-cluster-management/index.html index 10970b81..647f6fb6 100644 --- a/blog/next-kubernetes-frontier-multi-cluster-management/index.html +++ b/blog/next-kubernetes-frontier-multi-cluster-management/index.html @@ -370,7 +370,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -406,7 +406,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -492,7 +492,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -530,7 +530,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/nudus-20230131/index.html b/blog/nudus-20230131/index.html index 552c586c..eba50dfa 100644 --- a/blog/nudus-20230131/index.html +++ b/blog/nudus-20230131/index.html @@ -376,10 +376,10 @@

  • Nerdctl 原生支持 Nydus 加速镜像
    • -
  • SOFARegistry | 聊一聊服务发现的数据一致性
    • -
  • SOFARegistry | 聊一聊服务发现的数据一致性
    • +
  • SOFARegistry | 聊一聊服务发现的数据一致性
    • +
  • Nydus 镜像扫描加速
    • @@ -397,7 +397,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -433,7 +433,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -519,7 +519,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -557,7 +557,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/index.html b/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/index.html index 52ddb51f..d46398c5 100644 --- a/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/index.html +++ b/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/index.html @@ -704,7 +704,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -740,7 +740,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -826,7 +826,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -864,7 +864,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/nydus-exploratory-practice-of-next-generation-container-images/index.html b/blog/nydus-exploratory-practice-of-next-generation-container-images/index.html index 7b456d75..f571ed28 100644 --- a/blog/nydus-exploratory-practice-of-next-generation-container-images/index.html +++ b/blog/nydus-exploratory-practice-of-next-generation-container-images/index.html @@ -594,7 +594,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -630,7 +630,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -716,7 +716,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -754,7 +754,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/index.html b/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/index.html index 52842b9a..5044b1ad 100644 --- a/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/index.html +++ b/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/index.html @@ -377,7 +377,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -413,7 +413,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -499,7 +499,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -537,7 +537,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/nydus-mirror-scan-acceleration/index.html b/blog/nydus-mirror-scan-acceleration/index.html index 107201a0..1834f7ab 100644 --- a/blog/nydus-mirror-scan-acceleration/index.html +++ b/blog/nydus-mirror-scan-acceleration/index.html @@ -643,7 +643,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -679,7 +679,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -765,7 +765,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -803,7 +803,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/index.html b/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/index.html index 0c78988f..0ce4a909 100644 --- a/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/index.html +++ b/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/index.html @@ -325,7 +325,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -361,7 +361,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -447,7 +447,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -485,7 +485,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/index.html b/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/index.html index 1c62ea68..4a45ec62 100644 --- a/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/index.html +++ b/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/index.html @@ -448,10 +448,10 @@

  • SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验
    • -
  • SOFAArk Committer 专访｜看它不爽，就直接动手改！
    • -
  • 深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进
    • +
  • SOFAArk Committer 专访｜看它不爽，就直接动手改！
    • +
  • 网商双十一-基于 ServiceMesh 技术的业务链路隔离技术及实践
  • Service Mesh 在中国工商银行的探索与实践
    • @@ -471,7 +471,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -507,7 +507,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -593,7 +593,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -631,7 +631,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/index.html b/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/index.html index b613a6d1..fa60e6e9 100644 --- a/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/index.html +++ b/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/index.html @@ -491,7 +491,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -527,7 +527,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -613,7 +613,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -651,7 +651,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/index.html b/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/index.html index 5dc94bfb..14519faf 100644 --- a/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/index.html +++ b/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/index.html @@ -419,7 +419,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -455,7 +455,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -541,7 +541,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -579,7 +579,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/open-source-together-seata-enters-apache-incubator/index.html b/blog/open-source-together-seata-enters-apache-incubator/index.html index 8122669a..8f3b917c 100644 --- a/blog/open-source-together-seata-enters-apache-incubator/index.html +++ b/blog/open-source-together-seata-enters-apache-incubator/index.html @@ -439,7 +439,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -475,7 +475,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -561,7 +561,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -599,7 +599,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/index.html b/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/index.html index ac35d82a..d94c708c 100644 --- a/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/index.html +++ b/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/index.html @@ -528,10 +528,10 @@

  • Gopher China 2021 专访之宋顺：Go 在蚂蚁集团的应用、实践
    • -
  • 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了
    • -
  • 【活动报名】SOFAMeetup#6 北京站，从数据库到架构，聊透分布式，玩转 Layotto
    • +
  • 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了
    • + @@ -547,7 +547,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -583,7 +583,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -669,7 +669,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -707,7 +707,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/originsants-practical-path-to-application-level-service-discovery/index.html b/blog/originsants-practical-path-to-application-level-service-discovery/index.html index 8bc3da42..d94ea626 100644 --- a/blog/originsants-practical-path-to-application-level-service-discovery/index.html +++ b/blog/originsants-practical-path-to-application-level-service-discovery/index.html @@ -577,7 +577,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -613,7 +613,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -699,7 +699,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -737,7 +737,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/index.html b/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/index.html index a53a1fa4..85af6215 100644 --- a/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/index.html +++ b/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/index.html @@ -373,7 +373,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -409,7 +409,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -495,7 +495,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -533,7 +533,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/index.html b/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/index.html index 70b8b18c..1bb0df35 100644 --- a/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/index.html +++ b/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/index.html @@ -375,7 +375,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -411,7 +411,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -497,7 +497,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -535,7 +535,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/p2p-transfer-protocol-optimization-in-dragonfly/index.html b/blog/p2p-transfer-protocol-optimization-in-dragonfly/index.html index 3f40d5ce..51c7e199 100644 --- a/blog/p2p-transfer-protocol-optimization-in-dragonfly/index.html +++ b/blog/p2p-transfer-protocol-optimization-in-dragonfly/index.html @@ -391,7 +391,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -427,7 +427,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -513,7 +513,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -551,7 +551,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/10/index.html b/blog/page/10/index.html index 75409e41..09ef05e0 100644 --- a/blog/page/10/index.html +++ b/blog/page/10/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/11/index.html b/blog/page/11/index.html index a1949d4e..6d8cd7ea 100644 --- a/blog/page/11/index.html +++ b/blog/page/11/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/12/index.html b/blog/page/12/index.html index 09d2e206..08101bee 100644 --- a/blog/page/12/index.html +++ b/blog/page/12/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/13/index.html b/blog/page/13/index.html index 01da8e3d..ce6184f7 100644 --- a/blog/page/13/index.html +++ b/blog/page/13/index.html @@ -528,7 +528,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -564,7 +564,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -650,7 +650,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -688,7 +688,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/14/index.html b/blog/page/14/index.html index cb9e8440..40b6c98c 100644 --- a/blog/page/14/index.html +++ b/blog/page/14/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/15/index.html b/blog/page/15/index.html index b54c13f8..14d9b923 100644 --- a/blog/page/15/index.html +++ b/blog/page/15/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/16/index.html b/blog/page/16/index.html index 44c476f9..89ec2af6 100644 --- a/blog/page/16/index.html +++ b/blog/page/16/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/17/index.html b/blog/page/17/index.html index f91a8884..20e4b030 100644 --- a/blog/page/17/index.html +++ b/blog/page/17/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/18/index.html b/blog/page/18/index.html index f9ba1019..b365a945 100644 --- a/blog/page/18/index.html +++ b/blog/page/18/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/19/index.html b/blog/page/19/index.html index 34b58411..bbeaff9d 100644 --- a/blog/page/19/index.html +++ b/blog/page/19/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/2/index.html b/blog/page/2/index.html index b2a7a1d6..d9c2005e 100644 --- a/blog/page/2/index.html +++ b/blog/page/2/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/20/index.html b/blog/page/20/index.html index fa347510..619354d9 100644 --- a/blog/page/20/index.html +++ b/blog/page/20/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/21/index.html b/blog/page/21/index.html index 2efa813a..32bd3f79 100644 --- a/blog/page/21/index.html +++ b/blog/page/21/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/22/index.html b/blog/page/22/index.html index 1457a928..dab459cb 100644 --- a/blog/page/22/index.html +++ b/blog/page/22/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/23/index.html b/blog/page/23/index.html index d95c97ac..57bbd2d7 100644 --- a/blog/page/23/index.html +++ b/blog/page/23/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/24/index.html b/blog/page/24/index.html index 0c67a89a..8ce1ab59 100644 --- a/blog/page/24/index.html +++ b/blog/page/24/index.html @@ -538,7 +538,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -574,7 +574,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -660,7 +660,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -698,7 +698,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/25/index.html b/blog/page/25/index.html index 5e88f39e..cb9b8867 100644 --- a/blog/page/25/index.html +++ b/blog/page/25/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/26/index.html b/blog/page/26/index.html index 8c98a5cc..18254852 100644 --- a/blog/page/26/index.html +++ b/blog/page/26/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/27/index.html b/blog/page/27/index.html index 7b6aa9e6..3f4f01bf 100644 --- a/blog/page/27/index.html +++ b/blog/page/27/index.html @@ -530,7 +530,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -566,7 +566,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -652,7 +652,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -690,7 +690,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/28/index.html b/blog/page/28/index.html index 81a3de2f..dd0d7ffd 100644 --- a/blog/page/28/index.html +++ b/blog/page/28/index.html @@ -528,7 +528,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -564,7 +564,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -650,7 +650,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -688,7 +688,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/29/index.html b/blog/page/29/index.html index ac39808c..a5838167 100644 --- a/blog/page/29/index.html +++ b/blog/page/29/index.html @@ -530,7 +530,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -566,7 +566,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -652,7 +652,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -690,7 +690,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/3/index.html b/blog/page/3/index.html index 0261d47a..2e6e016c 100644 --- a/blog/page/3/index.html +++ b/blog/page/3/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/30/index.html b/blog/page/30/index.html index a5e9ffe3..cc8f19d4 100644 --- a/blog/page/30/index.html +++ b/blog/page/30/index.html @@ -538,7 +538,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -574,7 +574,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -660,7 +660,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -698,7 +698,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/31/index.html b/blog/page/31/index.html index 3b51742d..ba11338b 100644 --- a/blog/page/31/index.html +++ b/blog/page/31/index.html @@ -534,7 +534,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -570,7 +570,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -656,7 +656,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -694,7 +694,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/32/index.html b/blog/page/32/index.html index 15c12b82..e03552c3 100644 --- a/blog/page/32/index.html +++ b/blog/page/32/index.html @@ -542,7 +542,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -578,7 +578,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -664,7 +664,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -702,7 +702,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/33/index.html b/blog/page/33/index.html index 0a3644ee..f395a219 100644 --- a/blog/page/33/index.html +++ b/blog/page/33/index.html @@ -534,7 +534,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -570,7 +570,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -656,7 +656,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -694,7 +694,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/34/index.html b/blog/page/34/index.html index 109c4bb3..8daa4189 100644 --- a/blog/page/34/index.html +++ b/blog/page/34/index.html @@ -540,7 +540,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -576,7 +576,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -662,7 +662,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -700,7 +700,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/35/index.html b/blog/page/35/index.html index 988e4668..3d9f4bc0 100644 --- a/blog/page/35/index.html +++ b/blog/page/35/index.html @@ -544,7 +544,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -580,7 +580,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -666,7 +666,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -704,7 +704,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/36/index.html b/blog/page/36/index.html index 061e3d47..4a6a0f06 100644 --- a/blog/page/36/index.html +++ b/blog/page/36/index.html @@ -532,7 +532,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -568,7 +568,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -654,7 +654,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -692,7 +692,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/37/index.html b/blog/page/37/index.html index 3146ff73..7c27d382 100644 --- a/blog/page/37/index.html +++ b/blog/page/37/index.html @@ -538,7 +538,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -574,7 +574,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -660,7 +660,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -698,7 +698,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/38/index.html b/blog/page/38/index.html index 936dc129..305a49eb 100644 --- a/blog/page/38/index.html +++ b/blog/page/38/index.html @@ -530,7 +530,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -566,7 +566,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -652,7 +652,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -690,7 +690,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/39/index.html b/blog/page/39/index.html index 8a9b4dda..59383fb0 100644 --- a/blog/page/39/index.html +++ b/blog/page/39/index.html @@ -538,7 +538,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -574,7 +574,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -660,7 +660,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -698,7 +698,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/4/index.html b/blog/page/4/index.html index a5ca1d52..86c7ccfd 100644 --- a/blog/page/4/index.html +++ b/blog/page/4/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/40/index.html b/blog/page/40/index.html index 8c87e78a..697894f1 100644 --- a/blog/page/40/index.html +++ b/blog/page/40/index.html @@ -532,7 +532,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -568,7 +568,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -654,7 +654,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -692,7 +692,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/41/index.html b/blog/page/41/index.html index 8662e4cf..e713a679 100644 --- a/blog/page/41/index.html +++ b/blog/page/41/index.html @@ -542,7 +542,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -578,7 +578,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -664,7 +664,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -702,7 +702,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/42/index.html b/blog/page/42/index.html index c0f6b499..033a4660 100644 --- a/blog/page/42/index.html +++ b/blog/page/42/index.html @@ -558,7 +558,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -594,7 +594,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -680,7 +680,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -718,7 +718,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/43/index.html b/blog/page/43/index.html index 1489a9cd..bfa191b5 100644 --- a/blog/page/43/index.html +++ b/blog/page/43/index.html @@ -536,7 +536,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -572,7 +572,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -658,7 +658,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -696,7 +696,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/44/index.html b/blog/page/44/index.html index 67397892..4268ab49 100644 --- a/blog/page/44/index.html +++ b/blog/page/44/index.html @@ -548,7 +548,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -584,7 +584,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -670,7 +670,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -708,7 +708,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/45/index.html b/blog/page/45/index.html index 7fb194de..92dde974 100644 --- a/blog/page/45/index.html +++ b/blog/page/45/index.html @@ -546,7 +546,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -582,7 +582,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -668,7 +668,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -706,7 +706,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/46/index.html b/blog/page/46/index.html index e9b610ce..adbda689 100644 --- a/blog/page/46/index.html +++ b/blog/page/46/index.html @@ -562,7 +562,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -598,7 +598,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -684,7 +684,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -722,7 +722,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/47/index.html b/blog/page/47/index.html index a6e579e6..c23239fe 100644 --- a/blog/page/47/index.html +++ b/blog/page/47/index.html @@ -574,7 +574,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -610,7 +610,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -696,7 +696,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -734,7 +734,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/48/index.html b/blog/page/48/index.html index 23e3fccf..aa19557b 100644 --- a/blog/page/48/index.html +++ b/blog/page/48/index.html @@ -546,7 +546,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -582,7 +582,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -668,7 +668,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -706,7 +706,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/49/index.html b/blog/page/49/index.html index 26528f19..92a4de0d 100644 --- a/blog/page/49/index.html +++ b/blog/page/49/index.html @@ -562,7 +562,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -598,7 +598,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -684,7 +684,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -722,7 +722,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/5/index.html b/blog/page/5/index.html index babcfc68..08924632 100644 --- a/blog/page/5/index.html +++ b/blog/page/5/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/50/index.html b/blog/page/50/index.html index f65df2b8..e8681cb4 100644 --- a/blog/page/50/index.html +++ b/blog/page/50/index.html @@ -565,7 +565,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -601,7 +601,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -687,7 +687,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -725,7 +725,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/6/index.html b/blog/page/6/index.html index c0457b5a..705fcfa2 100644 --- a/blog/page/6/index.html +++ b/blog/page/6/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/7/index.html b/blog/page/7/index.html index a72e38aa..69853e5a 100644 --- a/blog/page/7/index.html +++ b/blog/page/7/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/8/index.html b/blog/page/8/index.html index 848ec1f9..d62f70ef 100644 --- a/blog/page/8/index.html +++ b/blog/page/8/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/page/9/index.html b/blog/page/9/index.html index e11ccaf2..36ae8274 100644 --- a/blog/page/9/index.html +++ b/blog/page/9/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/prometheus-on-ceresdb-evolutionary-path/index.html b/blog/prometheus-on-ceresdb-evolutionary-path/index.html index d3b703cc..34599e1f 100644 --- a/blog/prometheus-on-ceresdb-evolutionary-path/index.html +++ b/blog/prometheus-on-ceresdb-evolutionary-path/index.html @@ -562,7 +562,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -598,7 +598,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -684,7 +684,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -722,7 +722,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/protecting-critical-operations-with-secure-computing/index.html b/blog/protecting-critical-operations-with-secure-computing/index.html index db7841f8..daaf078f 100644 --- a/blog/protecting-critical-operations-with-secure-computing/index.html +++ b/blog/protecting-critical-operations-with-secure-computing/index.html @@ -400,7 +400,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -436,7 +436,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -522,7 +522,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -560,7 +560,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/index.html b/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/index.html index 7e766142..0668323c 100644 --- a/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/index.html +++ b/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/index.html @@ -718,7 +718,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -754,7 +754,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -840,7 +840,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -878,7 +878,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/restricted-flow-on-the-technology-windfall/index.html b/blog/restricted-flow-on-the-technology-windfall/index.html index 880e7f94..f23f8688 100644 --- a/blog/restricted-flow-on-the-technology-windfall/index.html +++ b/blog/restricted-flow-on-the-technology-windfall/index.html @@ -583,7 +583,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -619,7 +619,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -705,7 +705,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -743,7 +743,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/index.html b/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/index.html index 9b7185b3..516dfb6c 100644 --- a/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/index.html +++ b/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/index.html @@ -466,7 +466,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -502,7 +502,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -588,7 +588,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -626,7 +626,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/index.html b/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/index.html index 839a1e14..6c09d6a3 100644 --- a/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/index.html +++ b/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/index.html @@ -387,7 +387,7 @@

  • Gopher China 2021 专访之宋顺：Go 在蚂蚁集团的应用、实践
    • -
  • 【活动报名】SOFAMeetup#6 北京站，从数据库到架构，聊透分布式，玩转 Layotto
    • +
  • 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了
    • @@ -404,7 +404,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -440,7 +440,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -526,7 +526,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -564,7 +564,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/index.html b/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/index.html index a40c6f0e..739339f5 100644 --- a/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/index.html +++ b/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/index.html @@ -367,7 +367,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -403,7 +403,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -489,7 +489,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -527,7 +527,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/seata-distributed-transaction-deep-dive/index.html b/blog/seata-distributed-transaction-deep-dive/index.html index 4c13fc67..5d0057c0 100644 --- a/blog/seata-distributed-transaction-deep-dive/index.html +++ b/blog/seata-distributed-transaction-deep-dive/index.html @@ -541,7 +541,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -577,7 +577,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -663,7 +663,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -701,7 +701,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/seata-distributed-transaction-open-source/index.html b/blog/seata-distributed-transaction-open-source/index.html index cef9719c..bbc98571 100644 --- a/blog/seata-distributed-transaction-open-source/index.html +++ b/blog/seata-distributed-transaction-open-source/index.html @@ -492,7 +492,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -528,7 +528,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -614,7 +614,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -652,7 +652,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/index.html b/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/index.html index 95114899..874f5d3d 100644 --- a/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/index.html +++ b/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/index.html @@ -381,7 +381,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -417,7 +417,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -503,7 +503,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -541,7 +541,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/seata-go-1-1-0-released-completes-at-mode-support/index.html b/blog/seata-go-1-1-0-released-completes-at-mode-support/index.html index 1d258e85..a3908eb9 100644 --- a/blog/seata-go-1-1-0-released-completes-at-mode-support/index.html +++ b/blog/seata-go-1-1-0-released-completes-at-mode-support/index.html @@ -460,7 +460,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -496,7 +496,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -582,7 +582,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -620,7 +620,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/seata-go-1.2.0-available-for-production-environments-is-here/index.html b/blog/seata-go-1.2.0-available-for-production-environments-is-here/index.html index 6372f4bb..728ab0bc 100644 --- a/blog/seata-go-1.2.0-available-for-production-environments-is-here/index.html +++ b/blog/seata-go-1.2.0-available-for-production-environments-is-here/index.html @@ -479,7 +479,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -515,7 +515,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -601,7 +601,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -639,7 +639,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/seata-in-practice-in-ant-international-banking/index.html b/blog/seata-in-practice-in-ant-international-banking/index.html index ce09c902..082bbda5 100644 --- a/blog/seata-in-practice-in-ant-international-banking/index.html +++ b/blog/seata-in-practice-in-ant-international-banking/index.html @@ -741,10 +741,10 @@

    @@ -572,7 +572,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -608,7 +608,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -694,7 +694,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -732,7 +732,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/seata-saga-flexible-financial-applications/index.html b/blog/seata-saga-flexible-financial-applications/index.html index 20581738..c32e60c6 100644 --- a/blog/seata-saga-flexible-financial-applications/index.html +++ b/blog/seata-saga-flexible-financial-applications/index.html @@ -799,7 +799,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -835,7 +835,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -921,7 +921,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -959,7 +959,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/seata-saga-model-quick-start-and-best-practices/index.html b/blog/seata-saga-model-quick-start-and-best-practices/index.html index 9ee7ec12..dcbf5fdd 100644 --- a/blog/seata-saga-model-quick-start-and-best-practices/index.html +++ b/blog/seata-saga-model-quick-start-and-best-practices/index.html @@ -461,7 +461,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -497,7 +497,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -583,7 +583,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -621,7 +621,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/seata-server-deep-analysis/index.html b/blog/seata-server-deep-analysis/index.html index f435e010..5ee8af14 100644 --- a/blog/seata-server-deep-analysis/index.html +++ b/blog/seata-server-deep-analysis/index.html @@ -642,7 +642,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -678,7 +678,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -764,7 +764,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -802,7 +802,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/seata-tcc-applicable-models-scenarios/index.html b/blog/seata-tcc-applicable-models-scenarios/index.html index c3890ce2..00acb974 100644 --- a/blog/seata-tcc-applicable-models-scenarios/index.html +++ b/blog/seata-tcc-applicable-models-scenarios/index.html @@ -415,7 +415,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -451,7 +451,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -537,7 +537,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -575,7 +575,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/seata-tcc-theory-design-realization/index.html b/blog/seata-tcc-theory-design-realization/index.html index b5020fa2..5410cb57 100644 --- a/blog/seata-tcc-theory-design-realization/index.html +++ b/blog/seata-tcc-theory-design-realization/index.html @@ -359,7 +359,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -395,7 +395,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -481,7 +481,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -519,7 +519,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/serverless-knative-giac/index.html b/blog/serverless-knative-giac/index.html index be6bc5bb..f6c96c65 100644 --- a/blog/serverless-knative-giac/index.html +++ b/blog/serverless-knative-giac/index.html @@ -511,7 +511,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -547,7 +547,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -633,7 +633,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -671,7 +671,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/serverless-market-challenge/index.html b/blog/serverless-market-challenge/index.html index 7c2647d2..5f883aa2 100644 --- a/blog/serverless-market-challenge/index.html +++ b/blog/serverless-market-challenge/index.html @@ -374,7 +374,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -410,7 +410,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -496,7 +496,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -534,7 +534,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/index.html b/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/index.html index 2a5e7817..eb496f25 100644 --- a/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/index.html +++ b/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/index.html @@ -403,7 +403,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -439,7 +439,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -525,7 +525,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -563,7 +563,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-antfin-deep-practice-qcon/index.html b/blog/service-mesh-antfin-deep-practice-qcon/index.html index f738ed0a..321cc73c 100644 --- a/blog/service-mesh-antfin-deep-practice-qcon/index.html +++ b/blog/service-mesh-antfin-deep-practice-qcon/index.html @@ -749,7 +749,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -785,7 +785,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -871,7 +871,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -909,7 +909,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/index.html b/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/index.html index dd153c57..6b0e0eba 100644 --- a/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/index.html +++ b/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/index.html @@ -503,7 +503,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -539,7 +539,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -625,7 +625,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -663,7 +663,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-api-udpa-follow-up/index.html b/blog/service-mesh-api-udpa-follow-up/index.html index 90ffe75d..aa661239 100644 --- a/blog/service-mesh-api-udpa-follow-up/index.html +++ b/blog/service-mesh-api-udpa-follow-up/index.html @@ -740,7 +740,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -776,7 +776,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -862,7 +862,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -900,7 +900,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-development-trend-1/index.html b/blog/service-mesh-development-trend-1/index.html index 72a1a063..c4381308 100644 --- a/blog/service-mesh-development-trend-1/index.html +++ b/blog/service-mesh-development-trend-1/index.html @@ -636,7 +636,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -672,7 +672,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -758,7 +758,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -796,7 +796,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-development-trend-2/index.html b/blog/service-mesh-development-trend-2/index.html index 55804ed5..b9cd4226 100644 --- a/blog/service-mesh-development-trend-2/index.html +++ b/blog/service-mesh-development-trend-2/index.html @@ -757,7 +757,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -793,7 +793,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -879,7 +879,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -917,7 +917,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-end-user-survey-report/index.html b/blog/service-mesh-end-user-survey-report/index.html index dcece0b5..03e9683f 100644 --- a/blog/service-mesh-end-user-survey-report/index.html +++ b/blog/service-mesh-end-user-survey-report/index.html @@ -359,7 +359,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -395,7 +395,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -481,7 +481,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -519,7 +519,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-exploration-thinking-after-1111-1/index.html b/blog/service-mesh-exploration-thinking-after-1111-1/index.html index a542f248..661e60db 100644 --- a/blog/service-mesh-exploration-thinking-after-1111-1/index.html +++ b/blog/service-mesh-exploration-thinking-after-1111-1/index.html @@ -461,7 +461,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -497,7 +497,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -583,7 +583,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -621,7 +621,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-giac-2018/index.html b/blog/service-mesh-giac-2018/index.html index e1f2f046..93c17b43 100644 --- a/blog/service-mesh-giac-2018/index.html +++ b/blog/service-mesh-giac-2018/index.html @@ -490,7 +490,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -526,7 +526,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -612,7 +612,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -650,7 +650,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-giac-2019/index.html b/blog/service-mesh-giac-2019/index.html index bc51a78a..e9b09b00 100644 --- a/blog/service-mesh-giac-2019/index.html +++ b/blog/service-mesh-giac-2019/index.html @@ -474,7 +474,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -510,7 +510,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -596,7 +596,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -634,7 +634,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-meetup-5-istio-retrospect/index.html b/blog/service-mesh-meetup-5-istio-retrospect/index.html index 837d1e69..ceebfef9 100644 --- a/blog/service-mesh-meetup-5-istio-retrospect/index.html +++ b/blog/service-mesh-meetup-5-istio-retrospect/index.html @@ -450,7 +450,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -486,7 +486,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -572,7 +572,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -610,7 +610,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-meetup-5-retrospect/index.html b/blog/service-mesh-meetup-5-retrospect/index.html index f17d6695..fbfe43e1 100644 --- a/blog/service-mesh-meetup-5-retrospect/index.html +++ b/blog/service-mesh-meetup-5-retrospect/index.html @@ -650,7 +650,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -686,7 +686,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -772,7 +772,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -810,7 +810,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/index.html b/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/index.html index f606c4f4..57edb133 100644 --- a/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/index.html +++ b/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/index.html @@ -480,7 +480,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -516,7 +516,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -602,7 +602,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -640,7 +640,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/index.html b/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/index.html index 058451df..22a6157f 100644 --- a/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/index.html +++ b/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/index.html @@ -622,7 +622,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -658,7 +658,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -744,7 +744,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -782,7 +782,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/index.html b/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/index.html index 27b4333f..919993fc 100644 --- a/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/index.html +++ b/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/index.html @@ -563,7 +563,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -599,7 +599,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -685,7 +685,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -723,7 +723,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/index.html b/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/index.html index a6daae29..e8564ccb 100644 --- a/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/index.html +++ b/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/index.html @@ -536,7 +536,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -572,7 +572,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -658,7 +658,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -696,7 +696,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/index.html b/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/index.html index a62f77ed..edd28d74 100644 --- a/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/index.html +++ b/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/index.html @@ -410,7 +410,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -446,7 +446,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -532,7 +532,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -570,7 +570,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/index.html b/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/index.html index 887f8015..11078859 100644 --- a/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/index.html +++ b/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/index.html @@ -592,7 +592,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -628,7 +628,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -714,7 +714,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -752,7 +752,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/index.html b/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/index.html index 38b8bae4..4c4f9dc2 100644 --- a/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/index.html +++ b/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/index.html @@ -485,7 +485,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -521,7 +521,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -607,7 +607,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -645,7 +645,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/index.html b/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/index.html index cd1c165d..cbd80914 100644 --- a/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/index.html +++ b/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/index.html @@ -546,7 +546,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -582,7 +582,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -668,7 +668,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -706,7 +706,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/index.html b/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/index.html index 8c824145..e9948d84 100644 --- a/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/index.html +++ b/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/index.html @@ -433,7 +433,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -469,7 +469,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -555,7 +555,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -593,7 +593,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/index.html b/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/index.html index 2e092b0c..05a7b33f 100644 --- a/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/index.html +++ b/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/index.html @@ -496,7 +496,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -532,7 +532,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -618,7 +618,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -656,7 +656,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/index.html b/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/index.html index 8c7b1fe4..d919795c 100644 --- a/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/index.html +++ b/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/index.html @@ -456,7 +456,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -492,7 +492,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -578,7 +578,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -616,7 +616,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-practice-in-production-at-ant-financial-wushi/index.html b/blog/service-mesh-practice-in-production-at-ant-financial-wushi/index.html index 308982bc..4965ec38 100644 --- a/blog/service-mesh-practice-in-production-at-ant-financial-wushi/index.html +++ b/blog/service-mesh-practice-in-production-at-ant-financial-wushi/index.html @@ -594,7 +594,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -630,7 +630,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -716,7 +716,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -754,7 +754,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-the-road-ahead-long/index.html b/blog/service-mesh-the-road-ahead-long/index.html index 9e5b6ea8..5b476900 100644 --- a/blog/service-mesh-the-road-ahead-long/index.html +++ b/blog/service-mesh-the-road-ahead-long/index.html @@ -585,7 +585,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -621,7 +621,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -707,7 +707,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -745,7 +745,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/index.html b/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/index.html index 3bb88e57..b70ab01d 100644 --- a/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/index.html +++ b/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/index.html @@ -651,7 +651,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -687,7 +687,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -773,7 +773,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -811,7 +811,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/index.html b/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/index.html index 264b59ab..57b33208 100644 --- a/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/index.html +++ b/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/index.html @@ -494,7 +494,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -530,7 +530,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -616,7 +616,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -654,7 +654,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/index.html b/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/index.html index 7fcfd482..ed56dd86 100644 --- a/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/index.html +++ b/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/index.html @@ -452,7 +452,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -488,7 +488,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -574,7 +574,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -612,7 +612,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/index.html b/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/index.html index 12e4ea28..94aced78 100644 --- a/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/index.html +++ b/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/index.html @@ -775,7 +775,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -811,7 +811,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -897,7 +897,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -935,7 +935,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sidacar-kubecon-na2019/index.html b/blog/sidacar-kubecon-na2019/index.html index 326cec93..704b94c0 100644 --- a/blog/sidacar-kubecon-na2019/index.html +++ b/blog/sidacar-kubecon-na2019/index.html @@ -456,7 +456,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -492,7 +492,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -578,7 +578,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -616,7 +616,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-activity-retrospect-collection/index.html b/blog/sofa-activity-retrospect-collection/index.html index 5a824c89..36d852ca 100644 --- a/blog/sofa-activity-retrospect-collection/index.html +++ b/blog/sofa-activity-retrospect-collection/index.html @@ -412,7 +412,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -448,7 +448,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -534,7 +534,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -572,7 +572,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-acts-automated-testing-framework/index.html b/blog/sofa-acts-automated-testing-framework/index.html index 33893748..33b9ed82 100644 --- a/blog/sofa-acts-automated-testing-framework/index.html +++ b/blog/sofa-acts-automated-testing-framework/index.html @@ -416,7 +416,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -452,7 +452,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -538,7 +538,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -576,7 +576,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-ark-0.6.0/index.html b/blog/sofa-ark-0.6.0/index.html index 78269027..4048bac9 100644 --- a/blog/sofa-ark-0.6.0/index.html +++ b/blog/sofa-ark-0.6.0/index.html @@ -373,7 +373,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -409,7 +409,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -495,7 +495,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -533,7 +533,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-ark-maven-packaging-plugins/index.html b/blog/sofa-ark-maven-packaging-plugins/index.html index e34f6265..18867480 100644 --- a/blog/sofa-ark-maven-packaging-plugins/index.html +++ b/blog/sofa-ark-maven-packaging-plugins/index.html @@ -507,7 +507,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -543,7 +543,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -629,7 +629,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -667,7 +667,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-ark-overview/index.html b/blog/sofa-ark-overview/index.html index 8cf1f571..b765a6e4 100644 --- a/blog/sofa-ark-overview/index.html +++ b/blog/sofa-ark-overview/index.html @@ -407,7 +407,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -443,7 +443,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -529,7 +529,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -567,7 +567,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-blot-connection-management-deep-dive/index.html b/blog/sofa-blot-connection-management-deep-dive/index.html index 9cb1bcfd..5ab255a8 100644 --- a/blog/sofa-blot-connection-management-deep-dive/index.html +++ b/blog/sofa-blot-connection-management-deep-dive/index.html @@ -433,7 +433,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -469,7 +469,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -555,7 +555,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -593,7 +593,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-bolt-codec-deep-dive/index.html b/blog/sofa-bolt-codec-deep-dive/index.html index f5d68e7d..1ea114e5 100644 --- a/blog/sofa-bolt-codec-deep-dive/index.html +++ b/blog/sofa-bolt-codec-deep-dive/index.html @@ -463,7 +463,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -499,7 +499,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -585,7 +585,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -623,7 +623,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-bolt-framework-deep-dive/index.html b/blog/sofa-bolt-framework-deep-dive/index.html index 71aa9bf5..ebb6d9d0 100644 --- a/blog/sofa-bolt-framework-deep-dive/index.html +++ b/blog/sofa-bolt-framework-deep-dive/index.html @@ -395,7 +395,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -431,7 +431,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -517,7 +517,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -555,7 +555,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-bolt-serialization-deep-dive/index.html b/blog/sofa-bolt-serialization-deep-dive/index.html index 25e0583f..e9c1b7c4 100644 --- a/blog/sofa-bolt-serialization-deep-dive/index.html +++ b/blog/sofa-bolt-serialization-deep-dive/index.html @@ -531,7 +531,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -567,7 +567,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -653,7 +653,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -691,7 +691,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/index.html b/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/index.html index f5a90b7f..4d50d175 100644 --- a/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/index.html +++ b/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/index.html @@ -401,7 +401,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -437,7 +437,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -523,7 +523,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -561,7 +561,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-boot-class-isolation-deep-dive/index.html b/blog/sofa-boot-class-isolation-deep-dive/index.html index 655117e2..981a6de4 100644 --- a/blog/sofa-boot-class-isolation-deep-dive/index.html +++ b/blog/sofa-boot-class-isolation-deep-dive/index.html @@ -430,7 +430,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -466,7 +466,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -552,7 +552,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -590,7 +590,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-boot-extension-practice/index.html b/blog/sofa-boot-extension-practice/index.html index fb9ee652..70165f8e 100644 --- a/blog/sofa-boot-extension-practice/index.html +++ b/blog/sofa-boot-extension-practice/index.html @@ -528,7 +528,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -564,7 +564,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -650,7 +650,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -688,7 +688,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-boot-log-isolation/index.html b/blog/sofa-boot-log-isolation/index.html index 09aed91a..0f7da6c2 100644 --- a/blog/sofa-boot-log-isolation/index.html +++ b/blog/sofa-boot-log-isolation/index.html @@ -593,7 +593,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -629,7 +629,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -715,7 +715,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -753,7 +753,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-boot-modular-development/index.html b/blog/sofa-boot-modular-development/index.html index 03fee9f8..65e69b99 100644 --- a/blog/sofa-boot-modular-development/index.html +++ b/blog/sofa-boot-modular-development/index.html @@ -457,7 +457,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -493,7 +493,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -579,7 +579,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -617,7 +617,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-boot-overview/index.html b/blog/sofa-boot-overview/index.html index c0fd78ac..62a74bf7 100644 --- a/blog/sofa-boot-overview/index.html +++ b/blog/sofa-boot-overview/index.html @@ -440,7 +440,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -476,7 +476,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -562,7 +562,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -600,7 +600,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-boot-readiness-check-in-kubernetes/index.html b/blog/sofa-boot-readiness-check-in-kubernetes/index.html index fae142de..3e0f3834 100644 --- a/blog/sofa-boot-readiness-check-in-kubernetes/index.html +++ b/blog/sofa-boot-readiness-check-in-kubernetes/index.html @@ -601,7 +601,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -637,7 +637,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -723,7 +723,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -761,7 +761,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-1-retrospect/index.html b/blog/sofa-channel-1-retrospect/index.html index eea14dc9..cd0cfa44 100644 --- a/blog/sofa-channel-1-retrospect/index.html +++ b/blog/sofa-channel-1-retrospect/index.html @@ -498,7 +498,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -534,7 +534,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -620,7 +620,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -658,7 +658,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-10-retrospect/index.html b/blog/sofa-channel-10-retrospect/index.html index e5868c73..77870fd5 100644 --- a/blog/sofa-channel-10-retrospect/index.html +++ b/blog/sofa-channel-10-retrospect/index.html @@ -608,7 +608,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -644,7 +644,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -730,7 +730,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -768,7 +768,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-11-retrospect/index.html b/blog/sofa-channel-11-retrospect/index.html index 9719e086..505af11f 100644 --- a/blog/sofa-channel-11-retrospect/index.html +++ b/blog/sofa-channel-11-retrospect/index.html @@ -509,7 +509,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -545,7 +545,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -631,7 +631,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -669,7 +669,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-12-retrospect/index.html b/blog/sofa-channel-12-retrospect/index.html index e5b71e3e..b7e04351 100644 --- a/blog/sofa-channel-12-retrospect/index.html +++ b/blog/sofa-channel-12-retrospect/index.html @@ -542,7 +542,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -578,7 +578,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -664,7 +664,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -702,7 +702,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-13-retrospect/index.html b/blog/sofa-channel-13-retrospect/index.html index 786ac644..565b1bb5 100644 --- a/blog/sofa-channel-13-retrospect/index.html +++ b/blog/sofa-channel-13-retrospect/index.html @@ -586,7 +586,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -622,7 +622,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -708,7 +708,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -746,7 +746,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-14-retrospect/index.html b/blog/sofa-channel-14-retrospect/index.html index 00221e12..cee3cd07 100644 --- a/blog/sofa-channel-14-retrospect/index.html +++ b/blog/sofa-channel-14-retrospect/index.html @@ -534,7 +534,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -570,7 +570,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -656,7 +656,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -694,7 +694,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-15-retrospect/index.html b/blog/sofa-channel-15-retrospect/index.html index e14ae3d8..45f15c9a 100644 --- a/blog/sofa-channel-15-retrospect/index.html +++ b/blog/sofa-channel-15-retrospect/index.html @@ -574,7 +574,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -610,7 +610,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -696,7 +696,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -734,7 +734,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-16-retrospect/index.html b/blog/sofa-channel-16-retrospect/index.html index 2ad618f5..cd66c413 100644 --- a/blog/sofa-channel-16-retrospect/index.html +++ b/blog/sofa-channel-16-retrospect/index.html @@ -405,7 +405,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -441,7 +441,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -527,7 +527,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -565,7 +565,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-17-retrospect/index.html b/blog/sofa-channel-17-retrospect/index.html index 1fb85dd5..bcb3593c 100644 --- a/blog/sofa-channel-17-retrospect/index.html +++ b/blog/sofa-channel-17-retrospect/index.html @@ -504,7 +504,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -540,7 +540,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -626,7 +626,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -664,7 +664,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-18-retrospect/index.html b/blog/sofa-channel-18-retrospect/index.html index cd10d416..9d366235 100644 --- a/blog/sofa-channel-18-retrospect/index.html +++ b/blog/sofa-channel-18-retrospect/index.html @@ -374,7 +374,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -410,7 +410,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -496,7 +496,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -534,7 +534,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-2-retrospect/index.html b/blog/sofa-channel-2-retrospect/index.html index 0b9630fb..8b664027 100644 --- a/blog/sofa-channel-2-retrospect/index.html +++ b/blog/sofa-channel-2-retrospect/index.html @@ -598,7 +598,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -634,7 +634,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -720,7 +720,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -758,7 +758,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-3-retrospect/index.html b/blog/sofa-channel-3-retrospect/index.html index f88cbfb7..cb087513 100644 --- a/blog/sofa-channel-3-retrospect/index.html +++ b/blog/sofa-channel-3-retrospect/index.html @@ -563,7 +563,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -599,7 +599,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -685,7 +685,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -723,7 +723,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-4-retrospect/index.html b/blog/sofa-channel-4-retrospect/index.html index e71349b4..c62fa3fd 100644 --- a/blog/sofa-channel-4-retrospect/index.html +++ b/blog/sofa-channel-4-retrospect/index.html @@ -534,7 +534,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -570,7 +570,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -656,7 +656,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -694,7 +694,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-5-retrospect/index.html b/blog/sofa-channel-5-retrospect/index.html index 488f2736..23e7ffcf 100644 --- a/blog/sofa-channel-5-retrospect/index.html +++ b/blog/sofa-channel-5-retrospect/index.html @@ -466,7 +466,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -502,7 +502,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -588,7 +588,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -626,7 +626,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-6-retrospect/index.html b/blog/sofa-channel-6-retrospect/index.html index deb2b59d..9f875b10 100644 --- a/blog/sofa-channel-6-retrospect/index.html +++ b/blog/sofa-channel-6-retrospect/index.html @@ -506,10 +506,10 @@

  • SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs
    • -
  • 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理
    • -
  • 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理
    • +
  • 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理
    • + @@ -525,7 +525,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -561,7 +561,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -647,7 +647,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -685,7 +685,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-7-retrospect/index.html b/blog/sofa-channel-7-retrospect/index.html index 15ddfdb7..9e26bca9 100644 --- a/blog/sofa-channel-7-retrospect/index.html +++ b/blog/sofa-channel-7-retrospect/index.html @@ -496,7 +496,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -532,7 +532,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -618,7 +618,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -656,7 +656,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-channel-8-retrospect/index.html b/blog/sofa-channel-8-retrospect/index.html index 97f659ee..a7f32df6 100644 --- a/blog/sofa-channel-8-retrospect/index.html +++ b/blog/sofa-channel-8-retrospect/index.html @@ -482,7 +482,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -518,7 +518,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -604,7 +604,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -642,7 +642,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-dashboard-open-source/index.html b/blog/sofa-dashboard-open-source/index.html index 50f3ecaa..f22ef4ef 100644 --- a/blog/sofa-dashboard-open-source/index.html +++ b/blog/sofa-dashboard-open-source/index.html @@ -492,7 +492,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -528,7 +528,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -614,7 +614,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -652,7 +652,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-enclave-confidential-computing/index.html b/blog/sofa-enclave-confidential-computing/index.html index eede4709..76fe4051 100644 --- a/blog/sofa-enclave-confidential-computing/index.html +++ b/blog/sofa-enclave-confidential-computing/index.html @@ -452,7 +452,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -488,7 +488,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -574,7 +574,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -612,7 +612,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-financial-cloud-native-exploration/index.html b/blog/sofa-financial-cloud-native-exploration/index.html index 75092b85..f959c751 100644 --- a/blog/sofa-financial-cloud-native-exploration/index.html +++ b/blog/sofa-financial-cloud-native-exploration/index.html @@ -400,7 +400,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -436,7 +436,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -522,7 +522,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -560,7 +560,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-algorithm-storage-module-deep-dive/index.html b/blog/sofa-jraft-algorithm-storage-module-deep-dive/index.html index a74beebd..b87e92af 100644 --- a/blog/sofa-jraft-algorithm-storage-module-deep-dive/index.html +++ b/blog/sofa-jraft-algorithm-storage-module-deep-dive/index.html @@ -509,7 +509,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -545,7 +545,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -631,7 +631,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -669,7 +669,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-deep-dive/index.html b/blog/sofa-jraft-deep-dive/index.html index d8fa02f9..3af549f9 100644 --- a/blog/sofa-jraft-deep-dive/index.html +++ b/blog/sofa-jraft-deep-dive/index.html @@ -473,7 +473,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -509,7 +509,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -595,7 +595,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -633,7 +633,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-election-mechanism/index.html b/blog/sofa-jraft-election-mechanism/index.html index 441433da..98146c07 100644 --- a/blog/sofa-jraft-election-mechanism/index.html +++ b/blog/sofa-jraft-election-mechanism/index.html @@ -465,7 +465,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -501,7 +501,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -587,7 +587,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -625,7 +625,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-linear-consistent-read-implementation/index.html b/blog/sofa-jraft-linear-consistent-read-implementation/index.html index 68baf35f..c3140418 100644 --- a/blog/sofa-jraft-linear-consistent-read-implementation/index.html +++ b/blog/sofa-jraft-linear-consistent-read-implementation/index.html @@ -430,7 +430,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -466,7 +466,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -552,7 +552,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -590,7 +590,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-pipeline-principle/index.html b/blog/sofa-jraft-pipeline-principle/index.html index e8e6e23d..a1cc9239 100644 --- a/blog/sofa-jraft-pipeline-principle/index.html +++ b/blog/sofa-jraft-pipeline-principle/index.html @@ -492,7 +492,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -528,7 +528,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -614,7 +614,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -652,7 +652,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-priority-election/index.html b/blog/sofa-jraft-priority-election/index.html index 1ab0b4f0..d13e706b 100644 --- a/blog/sofa-jraft-priority-election/index.html +++ b/blog/sofa-jraft-priority-election/index.html @@ -447,7 +447,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -483,7 +483,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -569,7 +569,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -607,7 +607,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-production-level-algorithm-library/index.html b/blog/sofa-jraft-production-level-algorithm-library/index.html index c4c50b00..56c84aad 100644 --- a/blog/sofa-jraft-production-level-algorithm-library/index.html +++ b/blog/sofa-jraft-production-level-algorithm-library/index.html @@ -694,7 +694,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -730,7 +730,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -816,7 +816,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -854,7 +854,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-rheakv-distributedlock/index.html b/blog/sofa-jraft-rheakv-distributedlock/index.html index 91b5d066..49eca9e1 100644 --- a/blog/sofa-jraft-rheakv-distributedlock/index.html +++ b/blog/sofa-jraft-rheakv-distributedlock/index.html @@ -491,7 +491,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -527,7 +527,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -613,7 +613,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -651,7 +651,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-rheakv-multi-raft-group/index.html b/blog/sofa-jraft-rheakv-multi-raft-group/index.html index af27c0b6..b6eca977 100644 --- a/blog/sofa-jraft-rheakv-multi-raft-group/index.html +++ b/blog/sofa-jraft-rheakv-multi-raft-group/index.html @@ -483,7 +483,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -519,7 +519,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -605,7 +605,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -643,7 +643,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-rheakv/index.html b/blog/sofa-jraft-rheakv/index.html index bf8de523..7125fbee 100644 --- a/blog/sofa-jraft-rheakv/index.html +++ b/blog/sofa-jraft-rheakv/index.html @@ -479,7 +479,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -515,7 +515,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -601,7 +601,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -639,7 +639,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-snapshot-principle-analysis/index.html b/blog/sofa-jraft-snapshot-principle-analysis/index.html index be2aeab3..910cbea5 100644 --- a/blog/sofa-jraft-snapshot-principle-analysis/index.html +++ b/blog/sofa-jraft-snapshot-principle-analysis/index.html @@ -435,7 +435,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -471,7 +471,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -557,7 +557,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -595,7 +595,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-jraft-user-china-mobile/index.html b/blog/sofa-jraft-user-china-mobile/index.html index 3cf983a4..ccfb9c87 100644 --- a/blog/sofa-jraft-user-china-mobile/index.html +++ b/blog/sofa-jraft-user-china-mobile/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-lookout-server-open-source/index.html b/blog/sofa-lookout-server-open-source/index.html index 189a9d3c..65459d38 100644 --- a/blog/sofa-lookout-server-open-source/index.html +++ b/blog/sofa-lookout-server-open-source/index.html @@ -343,7 +343,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -379,7 +379,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -465,7 +465,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -503,7 +503,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-meetup-1-jraft/index.html b/blog/sofa-meetup-1-jraft/index.html index 9ca1f256..f106745f 100644 --- a/blog/sofa-meetup-1-jraft/index.html +++ b/blog/sofa-meetup-1-jraft/index.html @@ -460,7 +460,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -496,7 +496,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -582,7 +582,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -620,7 +620,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-meetup-1-registry/index.html b/blog/sofa-meetup-1-registry/index.html index 3346170e..2b2c824a 100644 --- a/blog/sofa-meetup-1-registry/index.html +++ b/blog/sofa-meetup-1-registry/index.html @@ -512,7 +512,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -548,7 +548,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -634,7 +634,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -672,7 +672,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-meetup-1-seata/index.html b/blog/sofa-meetup-1-seata/index.html index a59492ba..f6609af3 100644 --- a/blog/sofa-meetup-1-seata/index.html +++ b/blog/sofa-meetup-1-seata/index.html @@ -525,7 +525,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -561,7 +561,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -647,7 +647,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -685,7 +685,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-meetup-2-1-retrospect/index.html b/blog/sofa-meetup-2-1-retrospect/index.html index df6cce25..835f3547 100644 --- a/blog/sofa-meetup-2-1-retrospect/index.html +++ b/blog/sofa-meetup-2-1-retrospect/index.html @@ -440,7 +440,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -476,7 +476,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -562,7 +562,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -600,7 +600,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-meetup-2-2-retrospect/index.html b/blog/sofa-meetup-2-2-retrospect/index.html index 6cf764e5..2655582b 100644 --- a/blog/sofa-meetup-2-2-retrospect/index.html +++ b/blog/sofa-meetup-2-2-retrospect/index.html @@ -704,7 +704,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -740,7 +740,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -826,7 +826,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -864,7 +864,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-meetup-3-cloud-original-retrospect/index.html b/blog/sofa-meetup-3-cloud-original-retrospect/index.html index f2c4258d..741e461a 100644 --- a/blog/sofa-meetup-3-cloud-original-retrospect/index.html +++ b/blog/sofa-meetup-3-cloud-original-retrospect/index.html @@ -462,7 +462,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -498,7 +498,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -584,7 +584,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -622,7 +622,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-meetup-3-seata-retrospect/index.html b/blog/sofa-meetup-3-seata-retrospect/index.html index f2839c54..a35dca87 100644 --- a/blog/sofa-meetup-3-seata-retrospect/index.html +++ b/blog/sofa-meetup-3-seata-retrospect/index.html @@ -543,7 +543,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -579,7 +579,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -665,7 +665,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -703,7 +703,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-mesh-cnutcon-2018/index.html b/blog/sofa-mesh-cnutcon-2018/index.html index 3fa3360b..c10b076d 100644 --- a/blog/sofa-mesh-cnutcon-2018/index.html +++ b/blog/sofa-mesh-cnutcon-2018/index.html @@ -388,7 +388,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -424,7 +424,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -510,7 +510,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -548,7 +548,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-mesh-x-protocol-common-address-solution/index.html b/blog/sofa-mesh-x-protocol-common-address-solution/index.html index 4b539eb8..d282a4a1 100644 --- a/blog/sofa-mesh-x-protocol-common-address-solution/index.html +++ b/blog/sofa-mesh-x-protocol-common-address-solution/index.html @@ -507,7 +507,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -543,7 +543,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -629,7 +629,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -667,7 +667,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-mesh-x-protocol-rapid-decode-forward/index.html b/blog/sofa-mesh-x-protocol-rapid-decode-forward/index.html index c1b71b4e..0bc609bd 100644 --- a/blog/sofa-mesh-x-protocol-rapid-decode-forward/index.html +++ b/blog/sofa-mesh-x-protocol-rapid-decode-forward/index.html @@ -510,7 +510,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -546,7 +546,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -632,7 +632,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -670,7 +670,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-mesh-x-protocol-tcp-protocol-extension/index.html b/blog/sofa-mesh-x-protocol-tcp-protocol-extension/index.html index 6b9a738d..836ebc60 100644 --- a/blog/sofa-mesh-x-protocol-tcp-protocol-extension/index.html +++ b/blog/sofa-mesh-x-protocol-tcp-protocol-extension/index.html @@ -402,7 +402,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -438,7 +438,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -524,7 +524,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -562,7 +562,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-registry-data-consistency/index.html b/blog/sofa-registry-data-consistency/index.html index de897c4b..c819321e 100644 --- a/blog/sofa-registry-data-consistency/index.html +++ b/blog/sofa-registry-data-consistency/index.html @@ -495,7 +495,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -531,7 +531,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -617,7 +617,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -655,7 +655,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-registry-data-fragmentation-synchronization-scheme/index.html b/blog/sofa-registry-data-fragmentation-synchronization-scheme/index.html index 58372ce4..6b8ea011 100644 --- a/blog/sofa-registry-data-fragmentation-synchronization-scheme/index.html +++ b/blog/sofa-registry-data-fragmentation-synchronization-scheme/index.html @@ -559,7 +559,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -595,7 +595,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -681,7 +681,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -719,7 +719,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-registry-dataserver-smooth-expansion-contraction/index.html b/blog/sofa-registry-dataserver-smooth-expansion-contraction/index.html index 59baf2ef..92cd56c0 100644 --- a/blog/sofa-registry-dataserver-smooth-expansion-contraction/index.html +++ b/blog/sofa-registry-dataserver-smooth-expansion-contraction/index.html @@ -608,7 +608,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -644,7 +644,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -730,7 +730,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -768,7 +768,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-registry-deep-dive/index.html b/blog/sofa-registry-deep-dive/index.html index f40edb4c..a92b1c29 100644 --- a/blog/sofa-registry-deep-dive/index.html +++ b/blog/sofa-registry-deep-dive/index.html @@ -507,7 +507,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -543,7 +543,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -629,7 +629,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -667,7 +667,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-registry-introduction/index.html b/blog/sofa-registry-introduction/index.html index bbb37ba2..b24ed6e1 100644 --- a/blog/sofa-registry-introduction/index.html +++ b/blog/sofa-registry-introduction/index.html @@ -619,7 +619,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -655,7 +655,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -741,7 +741,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -779,7 +779,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-registry-metaserver-function-introduction/index.html b/blog/sofa-registry-metaserver-function-introduction/index.html index 97639b45..06cb17fa 100644 --- a/blog/sofa-registry-metaserver-function-introduction/index.html +++ b/blog/sofa-registry-metaserver-function-introduction/index.html @@ -475,7 +475,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -511,7 +511,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -597,7 +597,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -635,7 +635,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-registry-service-discovery-optimization/index.html b/blog/sofa-registry-service-discovery-optimization/index.html index 9ca0c87d..b5897487 100644 --- a/blog/sofa-registry-service-discovery-optimization/index.html +++ b/blog/sofa-registry-service-discovery-optimization/index.html @@ -442,7 +442,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -478,7 +478,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -564,7 +564,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -602,7 +602,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-registry-service-offline-notification/index.html b/blog/sofa-registry-service-offline-notification/index.html index e976981c..50fbb64c 100644 --- a/blog/sofa-registry-service-offline-notification/index.html +++ b/blog/sofa-registry-service-offline-notification/index.html @@ -421,7 +421,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -457,7 +457,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -543,7 +543,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -581,7 +581,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-registry-session-storage/index.html b/blog/sofa-registry-session-storage/index.html index c0793b5a..154ec418 100644 --- a/blog/sofa-registry-session-storage/index.html +++ b/blog/sofa-registry-session-storage/index.html @@ -455,7 +455,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -491,7 +491,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -577,7 +577,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -615,7 +615,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-annotation-support/index.html b/blog/sofa-rpc-annotation-support/index.html index 05a36b11..514c5996 100644 --- a/blog/sofa-rpc-annotation-support/index.html +++ b/blog/sofa-rpc-annotation-support/index.html @@ -486,7 +486,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -522,7 +522,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -608,7 +608,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -646,7 +646,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-connection-management-heartbeat-analysis/index.html b/blog/sofa-rpc-connection-management-heartbeat-analysis/index.html index d4e72a2c..5b1e2e34 100644 --- a/blog/sofa-rpc-connection-management-heartbeat-analysis/index.html +++ b/blog/sofa-rpc-connection-management-heartbeat-analysis/index.html @@ -627,7 +627,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -663,7 +663,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -749,7 +749,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -787,7 +787,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-cross-language-support/index.html b/blog/sofa-rpc-cross-language-support/index.html index 4999f4eb..dfef7862 100644 --- a/blog/sofa-rpc-cross-language-support/index.html +++ b/blog/sofa-rpc-cross-language-support/index.html @@ -514,7 +514,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -550,7 +550,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -636,7 +636,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -674,7 +674,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-data-transmission/index.html b/blog/sofa-rpc-data-transmission/index.html index 26aad4dc..c28deb2a 100644 --- a/blog/sofa-rpc-data-transmission/index.html +++ b/blog/sofa-rpc-data-transmission/index.html @@ -445,7 +445,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -481,7 +481,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -567,7 +567,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -605,7 +605,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-framework-overall-extension/index.html b/blog/sofa-rpc-framework-overall-extension/index.html index 018b0caf..d80489c4 100644 --- a/blog/sofa-rpc-framework-overall-extension/index.html +++ b/blog/sofa-rpc-framework-overall-extension/index.html @@ -586,7 +586,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -622,7 +622,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -708,7 +708,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -746,7 +746,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-generalized-call-implementation/index.html b/blog/sofa-rpc-generalized-call-implementation/index.html index 1f2a3f84..3fca4a76 100644 --- a/blog/sofa-rpc-generalized-call-implementation/index.html +++ b/blog/sofa-rpc-generalized-call-implementation/index.html @@ -443,7 +443,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -479,7 +479,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -565,7 +565,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -603,7 +603,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-graceful-exit/index.html b/blog/sofa-rpc-graceful-exit/index.html index d67b515b..6a451617 100644 --- a/blog/sofa-rpc-graceful-exit/index.html +++ b/blog/sofa-rpc-graceful-exit/index.html @@ -522,7 +522,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -558,7 +558,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -644,7 +644,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -682,7 +682,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-link-tracking/index.html b/blog/sofa-rpc-link-tracking/index.html index faea4d8c..760e3ab3 100644 --- a/blog/sofa-rpc-link-tracking/index.html +++ b/blog/sofa-rpc-link-tracking/index.html @@ -558,7 +558,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -594,7 +594,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -680,7 +680,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -718,7 +718,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-routing-implementation/index.html b/blog/sofa-rpc-routing-implementation/index.html index 2c68d123..929b0b35 100644 --- a/blog/sofa-rpc-routing-implementation/index.html +++ b/blog/sofa-rpc-routing-implementation/index.html @@ -500,7 +500,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -536,7 +536,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -622,7 +622,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -660,7 +660,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-serialization-comparison/index.html b/blog/sofa-rpc-serialization-comparison/index.html index 934cafd9..7586f62d 100644 --- a/blog/sofa-rpc-serialization-comparison/index.html +++ b/blog/sofa-rpc-serialization-comparison/index.html @@ -542,10 +542,10 @@

  • 【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析
    • -
  • 【剖析 | SOFARPC 框架】之 SOFARPC 路由实现剖析
    • -
  • 【剖析 | SOFARPC 框架】之 SOFARPC 优雅关闭剖析
    • +
  • 【剖析 | SOFARPC 框架】之 SOFARPC 路由实现剖析
    • +
  • 【剖析 | SOFARPC 框架】之 SOFARPC 数据透传剖析
    • @@ -563,7 +563,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -599,7 +599,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -685,7 +685,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -723,7 +723,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-single-machine-fault-culling/index.html b/blog/sofa-rpc-single-machine-fault-culling/index.html index f87c1fe8..39cbba8a 100644 --- a/blog/sofa-rpc-single-machine-fault-culling/index.html +++ b/blog/sofa-rpc-single-machine-fault-culling/index.html @@ -533,7 +533,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -569,7 +569,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -655,7 +655,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -693,7 +693,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-synchronous-asynchronous-implementation/index.html b/blog/sofa-rpc-synchronous-asynchronous-implementation/index.html index 36cdc0e4..a69db5e2 100644 --- a/blog/sofa-rpc-synchronous-asynchronous-implementation/index.html +++ b/blog/sofa-rpc-synchronous-asynchronous-implementation/index.html @@ -551,7 +551,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -587,7 +587,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -673,7 +673,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -711,7 +711,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-threading-model/index.html b/blog/sofa-rpc-threading-model/index.html index 55124897..fb712d0a 100644 --- a/blog/sofa-rpc-threading-model/index.html +++ b/blog/sofa-rpc-threading-model/index.html @@ -534,7 +534,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -570,7 +570,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -656,7 +656,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -694,7 +694,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-rpc-zookeeper-integriation/index.html b/blog/sofa-rpc-zookeeper-integriation/index.html index 2501643c..c9a006a5 100644 --- a/blog/sofa-rpc-zookeeper-integriation/index.html +++ b/blog/sofa-rpc-zookeeper-integriation/index.html @@ -693,7 +693,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -729,7 +729,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -815,7 +815,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -853,7 +853,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-special-weekly/index.html b/blog/sofa-special-weekly/index.html index 2d606db3..f5a33b8e 100644 --- a/blog/sofa-special-weekly/index.html +++ b/blog/sofa-special-weekly/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-star-is-recruiting/index.html b/blog/sofa-star-is-recruiting/index.html index 97b00c69..1d7b7b7a 100644 --- a/blog/sofa-star-is-recruiting/index.html +++ b/blog/sofa-star-is-recruiting/index.html @@ -369,7 +369,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -405,7 +405,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -491,7 +491,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -529,7 +529,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-tracer-event-tracing-deep-dive/index.html b/blog/sofa-tracer-event-tracing-deep-dive/index.html index e6bc84bf..67dece10 100644 --- a/blog/sofa-tracer-event-tracing-deep-dive/index.html +++ b/blog/sofa-tracer-event-tracing-deep-dive/index.html @@ -618,7 +618,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -654,7 +654,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -740,7 +740,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -778,7 +778,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-tracer-overview/index.html b/blog/sofa-tracer-overview/index.html index 40955171..7eddf01e 100644 --- a/blog/sofa-tracer-overview/index.html +++ b/blog/sofa-tracer-overview/index.html @@ -637,7 +637,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -673,7 +673,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -759,7 +759,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -797,7 +797,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-tracer-response-mechanism/index.html b/blog/sofa-tracer-response-mechanism/index.html index bb30811e..e1d7076f 100644 --- a/blog/sofa-tracer-response-mechanism/index.html +++ b/blog/sofa-tracer-response-mechanism/index.html @@ -556,7 +556,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -592,7 +592,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -678,7 +678,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -716,7 +716,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-tracer-sampling-tracking-deep-dive/index.html b/blog/sofa-tracer-sampling-tracking-deep-dive/index.html index 0c556917..fe67ba27 100644 --- a/blog/sofa-tracer-sampling-tracking-deep-dive/index.html +++ b/blog/sofa-tracer-sampling-tracking-deep-dive/index.html @@ -479,7 +479,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -515,7 +515,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -601,7 +601,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -639,7 +639,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/index.html b/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/index.html index ce395a95..3e8c0cde 100644 --- a/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/index.html +++ b/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/index.html @@ -704,7 +704,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -740,7 +740,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -826,7 +826,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -864,7 +864,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-trcaer-disruptor-practice/index.html b/blog/sofa-trcaer-disruptor-practice/index.html index 094c9c5c..aed72ad7 100644 --- a/blog/sofa-trcaer-disruptor-practice/index.html +++ b/blog/sofa-trcaer-disruptor-practice/index.html @@ -957,7 +957,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -993,7 +993,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -1079,7 +1079,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -1117,7 +1117,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-0327/index.html b/blog/sofa-weekly-0327/index.html index 85a9f23d..3d152f01 100644 --- a/blog/sofa-weekly-0327/index.html +++ b/blog/sofa-weekly-0327/index.html @@ -412,7 +412,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -448,7 +448,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -534,7 +534,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -572,7 +572,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-0421/index.html b/blog/sofa-weekly-0421/index.html index 3957dd0a..bf594986 100644 --- a/blog/sofa-weekly-0421/index.html +++ b/blog/sofa-weekly-0421/index.html @@ -383,7 +383,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -419,7 +419,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -505,7 +505,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -543,7 +543,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-0430/index.html b/blog/sofa-weekly-0430/index.html index a8b66fd4..3c0db22c 100644 --- a/blog/sofa-weekly-0430/index.html +++ b/blog/sofa-weekly-0430/index.html @@ -351,7 +351,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -387,7 +387,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -473,7 +473,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -511,7 +511,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-0505/index.html b/blog/sofa-weekly-0505/index.html index 97b8f7a5..25a7c199 100644 --- a/blog/sofa-weekly-0505/index.html +++ b/blog/sofa-weekly-0505/index.html @@ -405,7 +405,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -441,7 +441,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -527,7 +527,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -565,7 +565,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-0611/index.html b/blog/sofa-weekly-0611/index.html index 4feb9a73..a466dcd5 100644 --- a/blog/sofa-weekly-0611/index.html +++ b/blog/sofa-weekly-0611/index.html @@ -342,7 +342,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -378,7 +378,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -464,7 +464,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -502,7 +502,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-1006/index.html b/blog/sofa-weekly-1006/index.html index 923bca47..f5905103 100644 --- a/blog/sofa-weekly-1006/index.html +++ b/blog/sofa-weekly-1006/index.html @@ -351,7 +351,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -387,7 +387,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -473,7 +473,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -511,7 +511,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20190719/index.html b/blog/sofa-weekly-20190719/index.html index c06b4440..8ae06488 100644 --- a/blog/sofa-weekly-20190719/index.html +++ b/blog/sofa-weekly-20190719/index.html @@ -330,7 +330,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -366,7 +366,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -452,7 +452,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -490,7 +490,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20190726/index.html b/blog/sofa-weekly-20190726/index.html index 8c6f97e2..e42e78a0 100644 --- a/blog/sofa-weekly-20190726/index.html +++ b/blog/sofa-weekly-20190726/index.html @@ -309,7 +309,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -345,7 +345,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -431,7 +431,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -469,7 +469,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20190802/index.html b/blog/sofa-weekly-20190802/index.html index bf6370b2..340de7fb 100644 --- a/blog/sofa-weekly-20190802/index.html +++ b/blog/sofa-weekly-20190802/index.html @@ -369,7 +369,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -405,7 +405,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -491,7 +491,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -529,7 +529,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20190809/index.html b/blog/sofa-weekly-20190809/index.html index 865cbcca..bceb43f0 100644 --- a/blog/sofa-weekly-20190809/index.html +++ b/blog/sofa-weekly-20190809/index.html @@ -336,7 +336,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -372,7 +372,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -458,7 +458,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -496,7 +496,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20190816/index.html b/blog/sofa-weekly-20190816/index.html index 2c91e092..9b78808f 100644 --- a/blog/sofa-weekly-20190816/index.html +++ b/blog/sofa-weekly-20190816/index.html @@ -329,7 +329,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -365,7 +365,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -451,7 +451,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -489,7 +489,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20190823/index.html b/blog/sofa-weekly-20190823/index.html index e5e2c9ae..484ea2ba 100644 --- a/blog/sofa-weekly-20190823/index.html +++ b/blog/sofa-weekly-20190823/index.html @@ -399,7 +399,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -435,7 +435,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -521,7 +521,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -559,7 +559,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20190830/index.html b/blog/sofa-weekly-20190830/index.html index 0e4e31d9..0b9d156f 100644 --- a/blog/sofa-weekly-20190830/index.html +++ b/blog/sofa-weekly-20190830/index.html @@ -374,7 +374,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -410,7 +410,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -496,7 +496,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -534,7 +534,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20190906/index.html b/blog/sofa-weekly-20190906/index.html index 8142718c..9dea1f60 100644 --- a/blog/sofa-weekly-20190906/index.html +++ b/blog/sofa-weekly-20190906/index.html @@ -381,7 +381,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -417,7 +417,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -503,7 +503,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -541,7 +541,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20190913/index.html b/blog/sofa-weekly-20190913/index.html index 1e49448c..68a722dd 100644 --- a/blog/sofa-weekly-20190913/index.html +++ b/blog/sofa-weekly-20190913/index.html @@ -321,7 +321,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -357,7 +357,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -443,7 +443,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -481,7 +481,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20190920/index.html b/blog/sofa-weekly-20190920/index.html index 2c2e7df9..7f2e20c5 100644 --- a/blog/sofa-weekly-20190920/index.html +++ b/blog/sofa-weekly-20190920/index.html @@ -346,7 +346,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -382,7 +382,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -468,7 +468,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -506,7 +506,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20190927/index.html b/blog/sofa-weekly-20190927/index.html index ab0843c6..c6605957 100644 --- a/blog/sofa-weekly-20190927/index.html +++ b/blog/sofa-weekly-20190927/index.html @@ -402,7 +402,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -438,7 +438,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -524,7 +524,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -562,7 +562,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191004/index.html b/blog/sofa-weekly-20191004/index.html index f5031b28..f6bbd33b 100644 --- a/blog/sofa-weekly-20191004/index.html +++ b/blog/sofa-weekly-20191004/index.html @@ -359,7 +359,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -395,7 +395,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -481,7 +481,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -519,7 +519,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191011/index.html b/blog/sofa-weekly-20191011/index.html index cd695028..347f5542 100644 --- a/blog/sofa-weekly-20191011/index.html +++ b/blog/sofa-weekly-20191011/index.html @@ -329,7 +329,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -365,7 +365,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -451,7 +451,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -489,7 +489,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191018/index.html b/blog/sofa-weekly-20191018/index.html index f1c4b906..f001fe72 100644 --- a/blog/sofa-weekly-20191018/index.html +++ b/blog/sofa-weekly-20191018/index.html @@ -349,7 +349,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -385,7 +385,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -471,7 +471,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -509,7 +509,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191025/index.html b/blog/sofa-weekly-20191025/index.html index ae4f2e56..ef0704dc 100644 --- a/blog/sofa-weekly-20191025/index.html +++ b/blog/sofa-weekly-20191025/index.html @@ -411,7 +411,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -447,7 +447,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -533,7 +533,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -571,7 +571,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191101/index.html b/blog/sofa-weekly-20191101/index.html index 87dc5362..61709aa6 100644 --- a/blog/sofa-weekly-20191101/index.html +++ b/blog/sofa-weekly-20191101/index.html @@ -375,7 +375,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -411,7 +411,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -497,7 +497,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -535,7 +535,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191108/index.html b/blog/sofa-weekly-20191108/index.html index 332ccf42..5ec93df2 100644 --- a/blog/sofa-weekly-20191108/index.html +++ b/blog/sofa-weekly-20191108/index.html @@ -359,7 +359,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -395,7 +395,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -481,7 +481,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -519,7 +519,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191115/index.html b/blog/sofa-weekly-20191115/index.html index ec7dd46f..041b35bb 100644 --- a/blog/sofa-weekly-20191115/index.html +++ b/blog/sofa-weekly-20191115/index.html @@ -445,7 +445,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -481,7 +481,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -567,7 +567,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -605,7 +605,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191122/index.html b/blog/sofa-weekly-20191122/index.html index ff8e9fe3..030f3109 100644 --- a/blog/sofa-weekly-20191122/index.html +++ b/blog/sofa-weekly-20191122/index.html @@ -415,7 +415,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -451,7 +451,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -537,7 +537,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -575,7 +575,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191129/index.html b/blog/sofa-weekly-20191129/index.html index 1ec98457..b4b7fbd1 100644 --- a/blog/sofa-weekly-20191129/index.html +++ b/blog/sofa-weekly-20191129/index.html @@ -421,7 +421,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -457,7 +457,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -543,7 +543,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -581,7 +581,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191206/index.html b/blog/sofa-weekly-20191206/index.html index d474b9e4..b5a26767 100644 --- a/blog/sofa-weekly-20191206/index.html +++ b/blog/sofa-weekly-20191206/index.html @@ -440,7 +440,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -476,7 +476,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -562,7 +562,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -600,7 +600,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191213/index.html b/blog/sofa-weekly-20191213/index.html index 37e59519..bc00cebe 100644 --- a/blog/sofa-weekly-20191213/index.html +++ b/blog/sofa-weekly-20191213/index.html @@ -436,7 +436,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -472,7 +472,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -558,7 +558,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -596,7 +596,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191220/index.html b/blog/sofa-weekly-20191220/index.html index 6a60e1b5..cf50e647 100644 --- a/blog/sofa-weekly-20191220/index.html +++ b/blog/sofa-weekly-20191220/index.html @@ -430,7 +430,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -466,7 +466,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -552,7 +552,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -590,7 +590,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20191227/index.html b/blog/sofa-weekly-20191227/index.html index a282663a..ca1caa9c 100644 --- a/blog/sofa-weekly-20191227/index.html +++ b/blog/sofa-weekly-20191227/index.html @@ -408,7 +408,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -444,7 +444,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -530,7 +530,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -568,7 +568,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200103/index.html b/blog/sofa-weekly-20200103/index.html index 962a6475..f6ca4dc7 100644 --- a/blog/sofa-weekly-20200103/index.html +++ b/blog/sofa-weekly-20200103/index.html @@ -393,7 +393,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -429,7 +429,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -515,7 +515,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -553,7 +553,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200110/index.html b/blog/sofa-weekly-20200110/index.html index 0e69469c..c4d711a8 100644 --- a/blog/sofa-weekly-20200110/index.html +++ b/blog/sofa-weekly-20200110/index.html @@ -388,7 +388,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -424,7 +424,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -510,7 +510,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -548,7 +548,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200117/index.html b/blog/sofa-weekly-20200117/index.html index 682dc081..8be541e1 100644 --- a/blog/sofa-weekly-20200117/index.html +++ b/blog/sofa-weekly-20200117/index.html @@ -363,7 +363,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -399,7 +399,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -485,7 +485,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -523,7 +523,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200207/index.html b/blog/sofa-weekly-20200207/index.html index 4eb61d24..ce746bd2 100644 --- a/blog/sofa-weekly-20200207/index.html +++ b/blog/sofa-weekly-20200207/index.html @@ -388,7 +388,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -424,7 +424,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -510,7 +510,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -548,7 +548,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200214/index.html b/blog/sofa-weekly-20200214/index.html index 4951dda1..afe8beb4 100644 --- a/blog/sofa-weekly-20200214/index.html +++ b/blog/sofa-weekly-20200214/index.html @@ -399,7 +399,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -435,7 +435,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -521,7 +521,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -559,7 +559,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200221/index.html b/blog/sofa-weekly-20200221/index.html index 1baea180..2dd60d15 100644 --- a/blog/sofa-weekly-20200221/index.html +++ b/blog/sofa-weekly-20200221/index.html @@ -435,7 +435,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -471,7 +471,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -557,7 +557,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -595,7 +595,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200228/index.html b/blog/sofa-weekly-20200228/index.html index 80c7fbbf..e37373cf 100644 --- a/blog/sofa-weekly-20200228/index.html +++ b/blog/sofa-weekly-20200228/index.html @@ -401,7 +401,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -437,7 +437,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -523,7 +523,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -561,7 +561,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200306/index.html b/blog/sofa-weekly-20200306/index.html index 0a512a2a..1ee1ce92 100644 --- a/blog/sofa-weekly-20200306/index.html +++ b/blog/sofa-weekly-20200306/index.html @@ -393,7 +393,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -429,7 +429,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -515,7 +515,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -553,7 +553,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200313/index.html b/blog/sofa-weekly-20200313/index.html index 8ee7c56a..b9e164c2 100644 --- a/blog/sofa-weekly-20200313/index.html +++ b/blog/sofa-weekly-20200313/index.html @@ -430,7 +430,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -466,7 +466,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -552,7 +552,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -590,7 +590,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200320/index.html b/blog/sofa-weekly-20200320/index.html index 3c49c37a..fb079e15 100644 --- a/blog/sofa-weekly-20200320/index.html +++ b/blog/sofa-weekly-20200320/index.html @@ -378,7 +378,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -414,7 +414,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -500,7 +500,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -538,7 +538,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200403/index.html b/blog/sofa-weekly-20200403/index.html index a7cad64b..25a33259 100644 --- a/blog/sofa-weekly-20200403/index.html +++ b/blog/sofa-weekly-20200403/index.html @@ -398,7 +398,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -434,7 +434,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -520,7 +520,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -558,7 +558,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200410/index.html b/blog/sofa-weekly-20200410/index.html index bfdb4775..e4c77129 100644 --- a/blog/sofa-weekly-20200410/index.html +++ b/blog/sofa-weekly-20200410/index.html @@ -388,7 +388,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -424,7 +424,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -510,7 +510,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -548,7 +548,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200417/index.html b/blog/sofa-weekly-20200417/index.html index 95f478cd..cf5963d4 100644 --- a/blog/sofa-weekly-20200417/index.html +++ b/blog/sofa-weekly-20200417/index.html @@ -376,7 +376,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -412,7 +412,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -498,7 +498,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -536,7 +536,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200424/index.html b/blog/sofa-weekly-20200424/index.html index 9a10082d..0efb5edd 100644 --- a/blog/sofa-weekly-20200424/index.html +++ b/blog/sofa-weekly-20200424/index.html @@ -353,7 +353,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -389,7 +389,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -475,7 +475,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -513,7 +513,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200508/index.html b/blog/sofa-weekly-20200508/index.html index 4fbdd285..8cfe377e 100644 --- a/blog/sofa-weekly-20200508/index.html +++ b/blog/sofa-weekly-20200508/index.html @@ -456,7 +456,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -492,7 +492,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -578,7 +578,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -616,7 +616,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200515/index.html b/blog/sofa-weekly-20200515/index.html index f8bbcaed..27dc2025 100644 --- a/blog/sofa-weekly-20200515/index.html +++ b/blog/sofa-weekly-20200515/index.html @@ -400,7 +400,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -436,7 +436,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -522,7 +522,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -560,7 +560,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200522/index.html b/blog/sofa-weekly-20200522/index.html index a2c0900d..d8ee3b82 100644 --- a/blog/sofa-weekly-20200522/index.html +++ b/blog/sofa-weekly-20200522/index.html @@ -385,7 +385,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -421,7 +421,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -507,7 +507,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -545,7 +545,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200528/index.html b/blog/sofa-weekly-20200528/index.html index cdb9106f..71dac712 100644 --- a/blog/sofa-weekly-20200528/index.html +++ b/blog/sofa-weekly-20200528/index.html @@ -375,7 +375,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -411,7 +411,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -497,7 +497,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -535,7 +535,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200529/index.html b/blog/sofa-weekly-20200529/index.html index 2421b79a..6fc95512 100644 --- a/blog/sofa-weekly-20200529/index.html +++ b/blog/sofa-weekly-20200529/index.html @@ -387,7 +387,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -423,7 +423,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -509,7 +509,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -547,7 +547,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200605/index.html b/blog/sofa-weekly-20200605/index.html index 5751d29d..3e098b6c 100644 --- a/blog/sofa-weekly-20200605/index.html +++ b/blog/sofa-weekly-20200605/index.html @@ -394,7 +394,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -430,7 +430,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -516,7 +516,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -554,7 +554,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200612/index.html b/blog/sofa-weekly-20200612/index.html index e37c118e..cb6a1af0 100644 --- a/blog/sofa-weekly-20200612/index.html +++ b/blog/sofa-weekly-20200612/index.html @@ -382,7 +382,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -418,7 +418,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -504,7 +504,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -542,7 +542,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200619/index.html b/blog/sofa-weekly-20200619/index.html index e8362014..713db061 100644 --- a/blog/sofa-weekly-20200619/index.html +++ b/blog/sofa-weekly-20200619/index.html @@ -391,7 +391,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -427,7 +427,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -513,7 +513,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -551,7 +551,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200703/index.html b/blog/sofa-weekly-20200703/index.html index 249da3d0..acbb5b70 100644 --- a/blog/sofa-weekly-20200703/index.html +++ b/blog/sofa-weekly-20200703/index.html @@ -382,7 +382,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -418,7 +418,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -504,7 +504,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -542,7 +542,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200710/index.html b/blog/sofa-weekly-20200710/index.html index 971cf979..05e7f3ac 100644 --- a/blog/sofa-weekly-20200710/index.html +++ b/blog/sofa-weekly-20200710/index.html @@ -352,7 +352,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -388,7 +388,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -474,7 +474,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -512,7 +512,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200717/index.html b/blog/sofa-weekly-20200717/index.html index b281f5ec..158b731b 100644 --- a/blog/sofa-weekly-20200717/index.html +++ b/blog/sofa-weekly-20200717/index.html @@ -384,7 +384,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -420,7 +420,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -506,7 +506,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -544,7 +544,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200724/index.html b/blog/sofa-weekly-20200724/index.html index 60e09102..0743e786 100644 --- a/blog/sofa-weekly-20200724/index.html +++ b/blog/sofa-weekly-20200724/index.html @@ -379,7 +379,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -415,7 +415,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -501,7 +501,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -539,7 +539,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200731/index.html b/blog/sofa-weekly-20200731/index.html index 52ae969a..852fd462 100644 --- a/blog/sofa-weekly-20200731/index.html +++ b/blog/sofa-weekly-20200731/index.html @@ -413,7 +413,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -449,7 +449,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -535,7 +535,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -573,7 +573,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200807/index.html b/blog/sofa-weekly-20200807/index.html index 926d6b40..dceed1a0 100644 --- a/blog/sofa-weekly-20200807/index.html +++ b/blog/sofa-weekly-20200807/index.html @@ -394,7 +394,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -430,7 +430,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -516,7 +516,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -554,7 +554,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200814/index.html b/blog/sofa-weekly-20200814/index.html index 5232152c..d876645a 100644 --- a/blog/sofa-weekly-20200814/index.html +++ b/blog/sofa-weekly-20200814/index.html @@ -409,7 +409,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -445,7 +445,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -531,7 +531,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -569,7 +569,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200821/index.html b/blog/sofa-weekly-20200821/index.html index 4d637a7b..11a57c96 100644 --- a/blog/sofa-weekly-20200821/index.html +++ b/blog/sofa-weekly-20200821/index.html @@ -359,7 +359,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -395,7 +395,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -481,7 +481,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -519,7 +519,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200828/index.html b/blog/sofa-weekly-20200828/index.html index a83a17e0..1b33e6e9 100644 --- a/blog/sofa-weekly-20200828/index.html +++ b/blog/sofa-weekly-20200828/index.html @@ -357,7 +357,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -393,7 +393,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -479,7 +479,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -517,7 +517,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200911/index.html b/blog/sofa-weekly-20200911/index.html index 862f0180..1c48ef2f 100644 --- a/blog/sofa-weekly-20200911/index.html +++ b/blog/sofa-weekly-20200911/index.html @@ -395,7 +395,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -431,7 +431,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -517,7 +517,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -555,7 +555,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200918/index.html b/blog/sofa-weekly-20200918/index.html index 6edf977e..46640e35 100644 --- a/blog/sofa-weekly-20200918/index.html +++ b/blog/sofa-weekly-20200918/index.html @@ -370,7 +370,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -406,7 +406,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -492,7 +492,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -530,7 +530,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20200925/index.html b/blog/sofa-weekly-20200925/index.html index 50f20e91..7bce932e 100644 --- a/blog/sofa-weekly-20200925/index.html +++ b/blog/sofa-weekly-20200925/index.html @@ -371,7 +371,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -407,7 +407,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -493,7 +493,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -531,7 +531,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201002/index.html b/blog/sofa-weekly-20201002/index.html index 13c6ea42..80f9d253 100644 --- a/blog/sofa-weekly-20201002/index.html +++ b/blog/sofa-weekly-20201002/index.html @@ -357,7 +357,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -393,7 +393,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -479,7 +479,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -517,7 +517,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201009/index.html b/blog/sofa-weekly-20201009/index.html index cfb2d7c9..195677f9 100644 --- a/blog/sofa-weekly-20201009/index.html +++ b/blog/sofa-weekly-20201009/index.html @@ -340,7 +340,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -376,7 +376,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -462,7 +462,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -500,7 +500,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201016/index.html b/blog/sofa-weekly-20201016/index.html index c14075a7..7dbbb627 100644 --- a/blog/sofa-weekly-20201016/index.html +++ b/blog/sofa-weekly-20201016/index.html @@ -403,7 +403,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -439,7 +439,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -525,7 +525,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -563,7 +563,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201023/index.html b/blog/sofa-weekly-20201023/index.html index 9fe32489..602c8a8e 100644 --- a/blog/sofa-weekly-20201023/index.html +++ b/blog/sofa-weekly-20201023/index.html @@ -395,7 +395,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -431,7 +431,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -517,7 +517,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -555,7 +555,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201030/index.html b/blog/sofa-weekly-20201030/index.html index 8dd8c60e..ce5a3cc9 100644 --- a/blog/sofa-weekly-20201030/index.html +++ b/blog/sofa-weekly-20201030/index.html @@ -364,7 +364,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -400,7 +400,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -486,7 +486,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -524,7 +524,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201106/index.html b/blog/sofa-weekly-20201106/index.html index 474c8bf2..42071860 100644 --- a/blog/sofa-weekly-20201106/index.html +++ b/blog/sofa-weekly-20201106/index.html @@ -421,7 +421,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -457,7 +457,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -543,7 +543,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -581,7 +581,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201113/index.html b/blog/sofa-weekly-20201113/index.html index e6580c6c..a485fd30 100644 --- a/blog/sofa-weekly-20201113/index.html +++ b/blog/sofa-weekly-20201113/index.html @@ -346,7 +346,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -382,7 +382,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -468,7 +468,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -506,7 +506,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201120/index.html b/blog/sofa-weekly-20201120/index.html index 2c2b6609..bbf40eca 100644 --- a/blog/sofa-weekly-20201120/index.html +++ b/blog/sofa-weekly-20201120/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201127/index.html b/blog/sofa-weekly-20201127/index.html index f4bee192..a7476082 100644 --- a/blog/sofa-weekly-20201127/index.html +++ b/blog/sofa-weekly-20201127/index.html @@ -343,7 +343,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -379,7 +379,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -465,7 +465,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -503,7 +503,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201204/index.html b/blog/sofa-weekly-20201204/index.html index 645fd1c8..270847db 100644 --- a/blog/sofa-weekly-20201204/index.html +++ b/blog/sofa-weekly-20201204/index.html @@ -333,7 +333,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -369,7 +369,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -455,7 +455,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -493,7 +493,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201211/index.html b/blog/sofa-weekly-20201211/index.html index e83dd153..a6509980 100644 --- a/blog/sofa-weekly-20201211/index.html +++ b/blog/sofa-weekly-20201211/index.html @@ -354,7 +354,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -390,7 +390,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -476,7 +476,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -514,7 +514,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201218/index.html b/blog/sofa-weekly-20201218/index.html index 0d883cb0..019c8e2a 100644 --- a/blog/sofa-weekly-20201218/index.html +++ b/blog/sofa-weekly-20201218/index.html @@ -343,7 +343,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -379,7 +379,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -465,7 +465,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -503,7 +503,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201225/index.html b/blog/sofa-weekly-20201225/index.html index 39295596..2122a605 100644 --- a/blog/sofa-weekly-20201225/index.html +++ b/blog/sofa-weekly-20201225/index.html @@ -345,7 +345,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -381,7 +381,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -467,7 +467,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -505,7 +505,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20201231/index.html b/blog/sofa-weekly-20201231/index.html index 3ca0d709..395c0c7d 100644 --- a/blog/sofa-weekly-20201231/index.html +++ b/blog/sofa-weekly-20201231/index.html @@ -360,7 +360,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -396,7 +396,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -482,7 +482,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -520,7 +520,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210108/index.html b/blog/sofa-weekly-20210108/index.html index 9c6dedd1..ff935924 100644 --- a/blog/sofa-weekly-20210108/index.html +++ b/blog/sofa-weekly-20210108/index.html @@ -357,7 +357,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -393,7 +393,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -479,7 +479,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -517,7 +517,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210115/index.html b/blog/sofa-weekly-20210115/index.html index af233c9f..d8b00c2d 100644 --- a/blog/sofa-weekly-20210115/index.html +++ b/blog/sofa-weekly-20210115/index.html @@ -336,7 +336,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -372,7 +372,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -458,7 +458,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -496,7 +496,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210122/index.html b/blog/sofa-weekly-20210122/index.html index 72857f3b..826cd030 100644 --- a/blog/sofa-weekly-20210122/index.html +++ b/blog/sofa-weekly-20210122/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210129/index.html b/blog/sofa-weekly-20210129/index.html index c3ade018..c3fad884 100644 --- a/blog/sofa-weekly-20210129/index.html +++ b/blog/sofa-weekly-20210129/index.html @@ -351,7 +351,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -387,7 +387,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -473,7 +473,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -511,7 +511,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210205/index.html b/blog/sofa-weekly-20210205/index.html index b6e906ee..25ad6c27 100644 --- a/blog/sofa-weekly-20210205/index.html +++ b/blog/sofa-weekly-20210205/index.html @@ -400,7 +400,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -436,7 +436,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -522,7 +522,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -560,7 +560,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210212/index.html b/blog/sofa-weekly-20210212/index.html index 9541df09..b44b4512 100644 --- a/blog/sofa-weekly-20210212/index.html +++ b/blog/sofa-weekly-20210212/index.html @@ -309,7 +309,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -345,7 +345,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -431,7 +431,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -469,7 +469,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210219/index.html b/blog/sofa-weekly-20210219/index.html index 26784d22..b830e574 100644 --- a/blog/sofa-weekly-20210219/index.html +++ b/blog/sofa-weekly-20210219/index.html @@ -354,7 +354,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -390,7 +390,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -476,7 +476,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -514,7 +514,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210305/index.html b/blog/sofa-weekly-20210305/index.html index bf155b03..ab354871 100644 --- a/blog/sofa-weekly-20210305/index.html +++ b/blog/sofa-weekly-20210305/index.html @@ -373,7 +373,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -409,7 +409,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -495,7 +495,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -533,7 +533,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210312/index.html b/blog/sofa-weekly-20210312/index.html index 85aa6e93..42c46f64 100644 --- a/blog/sofa-weekly-20210312/index.html +++ b/blog/sofa-weekly-20210312/index.html @@ -380,7 +380,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -416,7 +416,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -502,7 +502,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -540,7 +540,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210319/index.html b/blog/sofa-weekly-20210319/index.html index e6f3892b..079a8d3b 100644 --- a/blog/sofa-weekly-20210319/index.html +++ b/blog/sofa-weekly-20210319/index.html @@ -380,7 +380,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -416,7 +416,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -502,7 +502,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -540,7 +540,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210326/index.html b/blog/sofa-weekly-20210326/index.html index d8c3052f..5fac7658 100644 --- a/blog/sofa-weekly-20210326/index.html +++ b/blog/sofa-weekly-20210326/index.html @@ -333,7 +333,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -369,7 +369,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -455,7 +455,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -493,7 +493,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210402/index.html b/blog/sofa-weekly-20210402/index.html index c6dab937..ea70bfa9 100644 --- a/blog/sofa-weekly-20210402/index.html +++ b/blog/sofa-weekly-20210402/index.html @@ -350,7 +350,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -386,7 +386,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -472,7 +472,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -510,7 +510,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210409/index.html b/blog/sofa-weekly-20210409/index.html index 93f11ecf..9836ecb2 100644 --- a/blog/sofa-weekly-20210409/index.html +++ b/blog/sofa-weekly-20210409/index.html @@ -368,7 +368,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -404,7 +404,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -490,7 +490,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -528,7 +528,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210416/index.html b/blog/sofa-weekly-20210416/index.html index b44b8b63..3510e722 100644 --- a/blog/sofa-weekly-20210416/index.html +++ b/blog/sofa-weekly-20210416/index.html @@ -352,7 +352,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -388,7 +388,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -474,7 +474,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -512,7 +512,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210422/index.html b/blog/sofa-weekly-20210422/index.html index c085baee..ac1db31e 100644 --- a/blog/sofa-weekly-20210422/index.html +++ b/blog/sofa-weekly-20210422/index.html @@ -411,7 +411,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -447,7 +447,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -533,7 +533,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -571,7 +571,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210423/index.html b/blog/sofa-weekly-20210423/index.html index 62dfb62f..56fc66fd 100644 --- a/blog/sofa-weekly-20210423/index.html +++ b/blog/sofa-weekly-20210423/index.html @@ -383,7 +383,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -419,7 +419,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -505,7 +505,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -543,7 +543,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210507/index.html b/blog/sofa-weekly-20210507/index.html index 7b3273b3..3f546437 100644 --- a/blog/sofa-weekly-20210507/index.html +++ b/blog/sofa-weekly-20210507/index.html @@ -341,7 +341,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -377,7 +377,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -463,7 +463,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -501,7 +501,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210514/index.html b/blog/sofa-weekly-20210514/index.html index ca1f531f..adca8ab9 100644 --- a/blog/sofa-weekly-20210514/index.html +++ b/blog/sofa-weekly-20210514/index.html @@ -372,7 +372,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -408,7 +408,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -494,7 +494,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -532,7 +532,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210521/index.html b/blog/sofa-weekly-20210521/index.html index d277a516..204b2620 100644 --- a/blog/sofa-weekly-20210521/index.html +++ b/blog/sofa-weekly-20210521/index.html @@ -374,7 +374,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -410,7 +410,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -496,7 +496,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -534,7 +534,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210604/index.html b/blog/sofa-weekly-20210604/index.html index b2defa8a..e4ff6705 100644 --- a/blog/sofa-weekly-20210604/index.html +++ b/blog/sofa-weekly-20210604/index.html @@ -360,7 +360,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -396,7 +396,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -482,7 +482,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -520,7 +520,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210618/index.html b/blog/sofa-weekly-20210618/index.html index 07e785fb..200ac654 100644 --- a/blog/sofa-weekly-20210618/index.html +++ b/blog/sofa-weekly-20210618/index.html @@ -351,7 +351,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -387,7 +387,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -473,7 +473,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -511,7 +511,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210625/index.html b/blog/sofa-weekly-20210625/index.html index 81b9dd74..93081128 100644 --- a/blog/sofa-weekly-20210625/index.html +++ b/blog/sofa-weekly-20210625/index.html @@ -342,7 +342,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -378,7 +378,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -464,7 +464,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -502,7 +502,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210702/index.html b/blog/sofa-weekly-20210702/index.html index e44e6c17..ee6a67f6 100644 --- a/blog/sofa-weekly-20210702/index.html +++ b/blog/sofa-weekly-20210702/index.html @@ -351,7 +351,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -387,7 +387,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -473,7 +473,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -511,7 +511,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210716/index.html b/blog/sofa-weekly-20210716/index.html index 6cffa20c..48f83ad7 100644 --- a/blog/sofa-weekly-20210716/index.html +++ b/blog/sofa-weekly-20210716/index.html @@ -358,7 +358,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -394,7 +394,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -480,7 +480,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -518,7 +518,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210723/index.html b/blog/sofa-weekly-20210723/index.html index 4f92ee0c..cb15ce35 100644 --- a/blog/sofa-weekly-20210723/index.html +++ b/blog/sofa-weekly-20210723/index.html @@ -352,7 +352,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -388,7 +388,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -474,7 +474,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -512,7 +512,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210730/index.html b/blog/sofa-weekly-20210730/index.html index 808bc049..da91f1b8 100644 --- a/blog/sofa-weekly-20210730/index.html +++ b/blog/sofa-weekly-20210730/index.html @@ -407,7 +407,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -443,7 +443,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -529,7 +529,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -567,7 +567,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210806/index.html b/blog/sofa-weekly-20210806/index.html index bfb88fbc..da801ab5 100644 --- a/blog/sofa-weekly-20210806/index.html +++ b/blog/sofa-weekly-20210806/index.html @@ -378,7 +378,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -414,7 +414,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -500,7 +500,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -538,7 +538,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210813/index.html b/blog/sofa-weekly-20210813/index.html index bbefcc32..fd5f14e7 100644 --- a/blog/sofa-weekly-20210813/index.html +++ b/blog/sofa-weekly-20210813/index.html @@ -387,7 +387,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -423,7 +423,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -509,7 +509,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -547,7 +547,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210820/index.html b/blog/sofa-weekly-20210820/index.html index 81c089ed..8ac8beb4 100644 --- a/blog/sofa-weekly-20210820/index.html +++ b/blog/sofa-weekly-20210820/index.html @@ -403,7 +403,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -439,7 +439,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -525,7 +525,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -563,7 +563,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210903/index.html b/blog/sofa-weekly-20210903/index.html index 109f8281..0416cecd 100644 --- a/blog/sofa-weekly-20210903/index.html +++ b/blog/sofa-weekly-20210903/index.html @@ -405,7 +405,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -441,7 +441,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -527,7 +527,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -565,7 +565,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210910/index.html b/blog/sofa-weekly-20210910/index.html index b0f13714..6a3c2ad5 100644 --- a/blog/sofa-weekly-20210910/index.html +++ b/blog/sofa-weekly-20210910/index.html @@ -379,7 +379,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -415,7 +415,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -501,7 +501,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -539,7 +539,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210917/index.html b/blog/sofa-weekly-20210917/index.html index 4616ebf2..af2d0b34 100644 --- a/blog/sofa-weekly-20210917/index.html +++ b/blog/sofa-weekly-20210917/index.html @@ -435,7 +435,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -471,7 +471,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -557,7 +557,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -595,7 +595,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20210924/index.html b/blog/sofa-weekly-20210924/index.html index 077e02d9..61caaf44 100644 --- a/blog/sofa-weekly-20210924/index.html +++ b/blog/sofa-weekly-20210924/index.html @@ -360,7 +360,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -396,7 +396,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -482,7 +482,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -520,7 +520,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211001/index.html b/blog/sofa-weekly-20211001/index.html index 84c09982..7fa537b5 100644 --- a/blog/sofa-weekly-20211001/index.html +++ b/blog/sofa-weekly-20211001/index.html @@ -403,7 +403,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -439,7 +439,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -525,7 +525,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -563,7 +563,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211008/index.html b/blog/sofa-weekly-20211008/index.html index cf8c5e1c..b5a72a0f 100644 --- a/blog/sofa-weekly-20211008/index.html +++ b/blog/sofa-weekly-20211008/index.html @@ -402,7 +402,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -438,7 +438,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -524,7 +524,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -562,7 +562,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211015/index.html b/blog/sofa-weekly-20211015/index.html index cb6651d4..b88ec020 100644 --- a/blog/sofa-weekly-20211015/index.html +++ b/blog/sofa-weekly-20211015/index.html @@ -390,7 +390,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -426,7 +426,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -512,7 +512,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -550,7 +550,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211029/index.html b/blog/sofa-weekly-20211029/index.html index 1df1470f..87a4978b 100644 --- a/blog/sofa-weekly-20211029/index.html +++ b/blog/sofa-weekly-20211029/index.html @@ -456,7 +456,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -492,7 +492,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -578,7 +578,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -616,7 +616,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211105/index.html b/blog/sofa-weekly-20211105/index.html index 6a2dc4d9..e1302d08 100644 --- a/blog/sofa-weekly-20211105/index.html +++ b/blog/sofa-weekly-20211105/index.html @@ -407,7 +407,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -443,7 +443,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -529,7 +529,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -567,7 +567,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211112/index.html b/blog/sofa-weekly-20211112/index.html index 19d3f1e5..c03ac442 100644 --- a/blog/sofa-weekly-20211112/index.html +++ b/blog/sofa-weekly-20211112/index.html @@ -419,7 +419,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -455,7 +455,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -541,7 +541,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -579,7 +579,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211119/index.html b/blog/sofa-weekly-20211119/index.html index e16f0b5e..3cc66314 100644 --- a/blog/sofa-weekly-20211119/index.html +++ b/blog/sofa-weekly-20211119/index.html @@ -429,7 +429,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -465,7 +465,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -551,7 +551,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -589,7 +589,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211126/index.html b/blog/sofa-weekly-20211126/index.html index d8a524fd..8ac8bb70 100644 --- a/blog/sofa-weekly-20211126/index.html +++ b/blog/sofa-weekly-20211126/index.html @@ -443,7 +443,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -479,7 +479,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -565,7 +565,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -603,7 +603,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211203/index.html b/blog/sofa-weekly-20211203/index.html index 24629b68..56b9db64 100644 --- a/blog/sofa-weekly-20211203/index.html +++ b/blog/sofa-weekly-20211203/index.html @@ -437,7 +437,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -473,7 +473,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -559,7 +559,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -597,7 +597,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211210/index.html b/blog/sofa-weekly-20211210/index.html index 1c8a9e97..b55f90f7 100644 --- a/blog/sofa-weekly-20211210/index.html +++ b/blog/sofa-weekly-20211210/index.html @@ -435,7 +435,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -471,7 +471,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -557,7 +557,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -595,7 +595,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211217/index.html b/blog/sofa-weekly-20211217/index.html index 38cb18d0..c7303c91 100644 --- a/blog/sofa-weekly-20211217/index.html +++ b/blog/sofa-weekly-20211217/index.html @@ -411,7 +411,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -447,7 +447,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -533,7 +533,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -571,7 +571,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211224/index.html b/blog/sofa-weekly-20211224/index.html index 7a93a8a7..ba48580d 100644 --- a/blog/sofa-weekly-20211224/index.html +++ b/blog/sofa-weekly-20211224/index.html @@ -418,7 +418,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -454,7 +454,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -540,7 +540,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -578,7 +578,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20211231/index.html b/blog/sofa-weekly-20211231/index.html index fd41b329..cf302979 100644 --- a/blog/sofa-weekly-20211231/index.html +++ b/blog/sofa-weekly-20211231/index.html @@ -417,7 +417,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -453,7 +453,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -539,7 +539,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -577,7 +577,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220107/index.html b/blog/sofa-weekly-20220107/index.html index 30228cf2..d3971f63 100644 --- a/blog/sofa-weekly-20220107/index.html +++ b/blog/sofa-weekly-20220107/index.html @@ -425,7 +425,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -461,7 +461,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -547,7 +547,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -585,7 +585,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220113/index.html b/blog/sofa-weekly-20220113/index.html index 40c216e3..d914b6fd 100644 --- a/blog/sofa-weekly-20220113/index.html +++ b/blog/sofa-weekly-20220113/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220114/index.html b/blog/sofa-weekly-20220114/index.html index 035f5e9e..3f05cc0a 100644 --- a/blog/sofa-weekly-20220114/index.html +++ b/blog/sofa-weekly-20220114/index.html @@ -419,7 +419,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -455,7 +455,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -541,7 +541,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -579,7 +579,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220121/index.html b/blog/sofa-weekly-20220121/index.html index 0226ab38..fa5597ec 100644 --- a/blog/sofa-weekly-20220121/index.html +++ b/blog/sofa-weekly-20220121/index.html @@ -389,7 +389,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -425,7 +425,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -511,7 +511,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -549,7 +549,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220129/index.html b/blog/sofa-weekly-20220129/index.html index 467c304e..4754d05e 100644 --- a/blog/sofa-weekly-20220129/index.html +++ b/blog/sofa-weekly-20220129/index.html @@ -407,7 +407,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -443,7 +443,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -529,7 +529,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -567,7 +567,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220204/index.html b/blog/sofa-weekly-20220204/index.html index 37ea31e8..7e07d115 100644 --- a/blog/sofa-weekly-20220204/index.html +++ b/blog/sofa-weekly-20220204/index.html @@ -380,7 +380,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -416,7 +416,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -502,7 +502,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -540,7 +540,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220211/index.html b/blog/sofa-weekly-20220211/index.html index 60568f67..ee27e03c 100644 --- a/blog/sofa-weekly-20220211/index.html +++ b/blog/sofa-weekly-20220211/index.html @@ -407,7 +407,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -443,7 +443,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -529,7 +529,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -567,7 +567,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220218/index.html b/blog/sofa-weekly-20220218/index.html index 94452d34..9671acaf 100644 --- a/blog/sofa-weekly-20220218/index.html +++ b/blog/sofa-weekly-20220218/index.html @@ -397,7 +397,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -433,7 +433,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -519,7 +519,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -557,7 +557,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220228/index.html b/blog/sofa-weekly-20220228/index.html index 83073a94..0369d6fe 100644 --- a/blog/sofa-weekly-20220228/index.html +++ b/blog/sofa-weekly-20220228/index.html @@ -394,7 +394,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -430,7 +430,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -516,7 +516,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -554,7 +554,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220304/index.html b/blog/sofa-weekly-20220304/index.html index 8d2a725c..8f9eef67 100644 --- a/blog/sofa-weekly-20220304/index.html +++ b/blog/sofa-weekly-20220304/index.html @@ -441,7 +441,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -477,7 +477,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -563,7 +563,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -601,7 +601,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220311/index.html b/blog/sofa-weekly-20220311/index.html index cd7211ac..78f5caa5 100644 --- a/blog/sofa-weekly-20220311/index.html +++ b/blog/sofa-weekly-20220311/index.html @@ -371,7 +371,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -407,7 +407,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -493,7 +493,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -531,7 +531,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220318/index.html b/blog/sofa-weekly-20220318/index.html index 2d221ada..623bff65 100644 --- a/blog/sofa-weekly-20220318/index.html +++ b/blog/sofa-weekly-20220318/index.html @@ -411,7 +411,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -447,7 +447,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -533,7 +533,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -571,7 +571,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220329/index.html b/blog/sofa-weekly-20220329/index.html index 66d0127d..a38ffd1d 100644 --- a/blog/sofa-weekly-20220329/index.html +++ b/blog/sofa-weekly-20220329/index.html @@ -393,7 +393,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -429,7 +429,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -515,7 +515,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -553,7 +553,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220401/index.html b/blog/sofa-weekly-20220401/index.html index 6900ae40..86802dfa 100644 --- a/blog/sofa-weekly-20220401/index.html +++ b/blog/sofa-weekly-20220401/index.html @@ -416,7 +416,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -452,7 +452,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -538,7 +538,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -576,7 +576,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220408/index.html b/blog/sofa-weekly-20220408/index.html index 853717f2..394a4d66 100644 --- a/blog/sofa-weekly-20220408/index.html +++ b/blog/sofa-weekly-20220408/index.html @@ -403,7 +403,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -439,7 +439,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -525,7 +525,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -563,7 +563,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220506/index.html b/blog/sofa-weekly-20220506/index.html index 41275ace..278fa855 100644 --- a/blog/sofa-weekly-20220506/index.html +++ b/blog/sofa-weekly-20220506/index.html @@ -385,7 +385,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -421,7 +421,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -507,7 +507,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -545,7 +545,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220513/index.html b/blog/sofa-weekly-20220513/index.html index ae25eefa..000088f7 100644 --- a/blog/sofa-weekly-20220513/index.html +++ b/blog/sofa-weekly-20220513/index.html @@ -409,7 +409,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -445,7 +445,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -531,7 +531,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -569,7 +569,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220520/index.html b/blog/sofa-weekly-20220520/index.html index 9a7a4326..4aea0af3 100644 --- a/blog/sofa-weekly-20220520/index.html +++ b/blog/sofa-weekly-20220520/index.html @@ -387,7 +387,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -423,7 +423,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -509,7 +509,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -547,7 +547,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220527/index.html b/blog/sofa-weekly-20220527/index.html index 5076771f..14fdd135 100644 --- a/blog/sofa-weekly-20220527/index.html +++ b/blog/sofa-weekly-20220527/index.html @@ -381,7 +381,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -417,7 +417,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -503,7 +503,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -541,7 +541,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220610/index.html b/blog/sofa-weekly-20220610/index.html index b4d8d0d6..1a1556d1 100644 --- a/blog/sofa-weekly-20220610/index.html +++ b/blog/sofa-weekly-20220610/index.html @@ -398,7 +398,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -434,7 +434,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -520,7 +520,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -558,7 +558,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220617/index.html b/blog/sofa-weekly-20220617/index.html index ef8624dc..fbdae05b 100644 --- a/blog/sofa-weekly-20220617/index.html +++ b/blog/sofa-weekly-20220617/index.html @@ -351,7 +351,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -387,7 +387,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -473,7 +473,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -511,7 +511,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220624/index.html b/blog/sofa-weekly-20220624/index.html index cedbb88d..73eb566c 100644 --- a/blog/sofa-weekly-20220624/index.html +++ b/blog/sofa-weekly-20220624/index.html @@ -349,7 +349,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -385,7 +385,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -471,7 +471,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -509,7 +509,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220708/index.html b/blog/sofa-weekly-20220708/index.html index f3ac6852..dbe60fec 100644 --- a/blog/sofa-weekly-20220708/index.html +++ b/blog/sofa-weekly-20220708/index.html @@ -367,7 +367,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -403,7 +403,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -489,7 +489,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -527,7 +527,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220715/index.html b/blog/sofa-weekly-20220715/index.html index f9e084b0..9e885cba 100644 --- a/blog/sofa-weekly-20220715/index.html +++ b/blog/sofa-weekly-20220715/index.html @@ -379,7 +379,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -415,7 +415,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -501,7 +501,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -539,7 +539,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220722/index.html b/blog/sofa-weekly-20220722/index.html index 01814627..3dc5a765 100644 --- a/blog/sofa-weekly-20220722/index.html +++ b/blog/sofa-weekly-20220722/index.html @@ -357,7 +357,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -393,7 +393,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -479,7 +479,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -517,7 +517,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220729/index.html b/blog/sofa-weekly-20220729/index.html index 4cbd3b95..0aa9fc77 100644 --- a/blog/sofa-weekly-20220729/index.html +++ b/blog/sofa-weekly-20220729/index.html @@ -353,7 +353,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -389,7 +389,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -475,7 +475,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -513,7 +513,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220805/index.html b/blog/sofa-weekly-20220805/index.html index 9400dc3a..c4ec5437 100644 --- a/blog/sofa-weekly-20220805/index.html +++ b/blog/sofa-weekly-20220805/index.html @@ -355,7 +355,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -391,7 +391,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -477,7 +477,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -515,7 +515,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220812/index.html b/blog/sofa-weekly-20220812/index.html index ff79b157..bdc47c61 100644 --- a/blog/sofa-weekly-20220812/index.html +++ b/blog/sofa-weekly-20220812/index.html @@ -373,7 +373,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -409,7 +409,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -495,7 +495,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -533,7 +533,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220819/index.html b/blog/sofa-weekly-20220819/index.html index 18feed67..c6f7cd39 100644 --- a/blog/sofa-weekly-20220819/index.html +++ b/blog/sofa-weekly-20220819/index.html @@ -345,7 +345,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -381,7 +381,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -467,7 +467,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -505,7 +505,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220826/index.html b/blog/sofa-weekly-20220826/index.html index a3ba63b0..2cfd0f4d 100644 --- a/blog/sofa-weekly-20220826/index.html +++ b/blog/sofa-weekly-20220826/index.html @@ -353,7 +353,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -389,7 +389,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -475,7 +475,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -513,7 +513,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220909/index.html b/blog/sofa-weekly-20220909/index.html index ec4782bc..ca902ae0 100644 --- a/blog/sofa-weekly-20220909/index.html +++ b/blog/sofa-weekly-20220909/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20220916/index.html b/blog/sofa-weekly-20220916/index.html index aa18322e..a6e05211 100644 --- a/blog/sofa-weekly-20220916/index.html +++ b/blog/sofa-weekly-20220916/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20221007/index.html b/blog/sofa-weekly-20221007/index.html index dd67ef14..0cbd2ef4 100644 --- a/blog/sofa-weekly-20221007/index.html +++ b/blog/sofa-weekly-20221007/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20221104/index.html b/blog/sofa-weekly-20221104/index.html index 4aa15334..74cacebb 100644 --- a/blog/sofa-weekly-20221104/index.html +++ b/blog/sofa-weekly-20221104/index.html @@ -329,7 +329,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -365,7 +365,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -451,7 +451,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -489,7 +489,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20221111/index.html b/blog/sofa-weekly-20221111/index.html index 7a5acaf4..cf58d727 100644 --- a/blog/sofa-weekly-20221111/index.html +++ b/blog/sofa-weekly-20221111/index.html @@ -332,7 +332,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -368,7 +368,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -454,7 +454,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -492,7 +492,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20221122/index.html b/blog/sofa-weekly-20221122/index.html index 1e253f13..68fbba59 100644 --- a/blog/sofa-weekly-20221122/index.html +++ b/blog/sofa-weekly-20221122/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-202211223/index.html b/blog/sofa-weekly-202211223/index.html index 59430596..b99f098f 100644 --- a/blog/sofa-weekly-202211223/index.html +++ b/blog/sofa-weekly-202211223/index.html @@ -335,7 +335,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -371,7 +371,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -457,7 +457,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -495,7 +495,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20221209/index.html b/blog/sofa-weekly-20221209/index.html index 54664ac5..78ddffca 100644 --- a/blog/sofa-weekly-20221209/index.html +++ b/blog/sofa-weekly-20221209/index.html @@ -331,7 +331,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -367,7 +367,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -453,7 +453,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -491,7 +491,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20221216/index.html b/blog/sofa-weekly-20221216/index.html index 4abd00bf..9f4e7d20 100644 --- a/blog/sofa-weekly-20221216/index.html +++ b/blog/sofa-weekly-20221216/index.html @@ -355,7 +355,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -391,7 +391,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -477,7 +477,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -515,7 +515,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20221230/index.html b/blog/sofa-weekly-20221230/index.html index 933bd00f..6eb7fd94 100644 --- a/blog/sofa-weekly-20221230/index.html +++ b/blog/sofa-weekly-20221230/index.html @@ -335,7 +335,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -371,7 +371,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -457,7 +457,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -495,7 +495,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230127/index.html b/blog/sofa-weekly-20230127/index.html index 7f151655..739fd21d 100644 --- a/blog/sofa-weekly-20230127/index.html +++ b/blog/sofa-weekly-20230127/index.html @@ -333,7 +333,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -369,7 +369,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -455,7 +455,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -493,7 +493,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230203/index.html b/blog/sofa-weekly-20230203/index.html index c065b3cb..477b0392 100644 --- a/blog/sofa-weekly-20230203/index.html +++ b/blog/sofa-weekly-20230203/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230210/index.html b/blog/sofa-weekly-20230210/index.html index a8e573ff..74e9c055 100644 --- a/blog/sofa-weekly-20230210/index.html +++ b/blog/sofa-weekly-20230210/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230217/index.html b/blog/sofa-weekly-20230217/index.html index c74b38cd..a84fdebd 100644 --- a/blog/sofa-weekly-20230217/index.html +++ b/blog/sofa-weekly-20230217/index.html @@ -337,7 +337,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -373,7 +373,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -459,7 +459,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -497,7 +497,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230303/index.html b/blog/sofa-weekly-20230303/index.html index f64c13b4..3e1cca63 100644 --- a/blog/sofa-weekly-20230303/index.html +++ b/blog/sofa-weekly-20230303/index.html @@ -334,10 +334,10 @@

  • Nerdctl 原生支持 Nydus 加速镜像
    • -
  • SOFARegistry | 聊一聊服务发现的数据一致性
    • -
  • SOFARegistry | 聊一聊服务发现的数据一致性
    • +
  • SOFARegistry | 聊一聊服务发现的数据一致性
    • + @@ -353,7 +353,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -389,7 +389,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -475,7 +475,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -513,7 +513,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230310/index.html b/blog/sofa-weekly-20230310/index.html index 080c8bd2..c6590ad7 100644 --- a/blog/sofa-weekly-20230310/index.html +++ b/blog/sofa-weekly-20230310/index.html @@ -357,7 +357,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -393,7 +393,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -479,7 +479,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -517,7 +517,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230324/index.html b/blog/sofa-weekly-20230324/index.html index 4fa82a51..b836fa3e 100644 --- a/blog/sofa-weekly-20230324/index.html +++ b/blog/sofa-weekly-20230324/index.html @@ -365,7 +365,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -401,7 +401,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -487,7 +487,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -525,7 +525,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230331/index.html b/blog/sofa-weekly-20230331/index.html index d665a920..face03b7 100644 --- a/blog/sofa-weekly-20230331/index.html +++ b/blog/sofa-weekly-20230331/index.html @@ -361,7 +361,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -397,7 +397,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -483,7 +483,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -521,7 +521,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230407/index.html b/blog/sofa-weekly-20230407/index.html index 81d5f1b6..81cb27a2 100644 --- a/blog/sofa-weekly-20230407/index.html +++ b/blog/sofa-weekly-20230407/index.html @@ -393,7 +393,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -429,7 +429,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -515,7 +515,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -553,7 +553,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230414/index.html b/blog/sofa-weekly-20230414/index.html index 2e7dad02..54f5549f 100644 --- a/blog/sofa-weekly-20230414/index.html +++ b/blog/sofa-weekly-20230414/index.html @@ -347,7 +347,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -383,7 +383,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -469,7 +469,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -507,7 +507,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230428/index.html b/blog/sofa-weekly-20230428/index.html index bd422602..2cf99a05 100644 --- a/blog/sofa-weekly-20230428/index.html +++ b/blog/sofa-weekly-20230428/index.html @@ -380,7 +380,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -416,7 +416,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -502,7 +502,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -540,7 +540,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230623/index.html b/blog/sofa-weekly-20230623/index.html index 40cf20fd..4569cb61 100644 --- a/blog/sofa-weekly-20230623/index.html +++ b/blog/sofa-weekly-20230623/index.html @@ -352,7 +352,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -388,7 +388,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -474,7 +474,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -512,7 +512,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230818/index.html b/blog/sofa-weekly-20230818/index.html index d2b0a3c8..de817951 100644 --- a/blog/sofa-weekly-20230818/index.html +++ b/blog/sofa-weekly-20230818/index.html @@ -357,7 +357,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -393,7 +393,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -479,7 +479,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -517,7 +517,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230825/index.html b/blog/sofa-weekly-20230825/index.html index 876a59a7..9169d441 100644 --- a/blog/sofa-weekly-20230825/index.html +++ b/blog/sofa-weekly-20230825/index.html @@ -413,7 +413,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -449,7 +449,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -535,7 +535,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -573,7 +573,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230901/index.html b/blog/sofa-weekly-20230901/index.html index 5a2fbc40..0ad471dd 100644 --- a/blog/sofa-weekly-20230901/index.html +++ b/blog/sofa-weekly-20230901/index.html @@ -480,7 +480,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -516,7 +516,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -602,7 +602,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -640,7 +640,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230915/index.html b/blog/sofa-weekly-20230915/index.html index 55da76df..c95880fb 100644 --- a/blog/sofa-weekly-20230915/index.html +++ b/blog/sofa-weekly-20230915/index.html @@ -456,7 +456,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -492,7 +492,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -578,7 +578,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -616,7 +616,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-20230929/index.html b/blog/sofa-weekly-20230929/index.html index bf238b37..544afa9d 100644 --- a/blog/sofa-weekly-20230929/index.html +++ b/blog/sofa-weekly-20230929/index.html @@ -338,7 +338,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -374,7 +374,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -460,7 +460,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -498,7 +498,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-230317/index.html b/blog/sofa-weekly-230317/index.html index 2437435a..748e0f64 100644 --- a/blog/sofa-weekly-230317/index.html +++ b/blog/sofa-weekly-230317/index.html @@ -392,7 +392,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -428,7 +428,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -514,7 +514,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -552,7 +552,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-230512/index.html b/blog/sofa-weekly-230512/index.html index ff6e26dd..937b4247 100644 --- a/blog/sofa-weekly-230512/index.html +++ b/blog/sofa-weekly-230512/index.html @@ -344,7 +344,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -380,7 +380,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -466,7 +466,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -504,7 +504,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-230519/index.html b/blog/sofa-weekly-230519/index.html index af6c5fb5..8cf2da08 100644 --- a/blog/sofa-weekly-230519/index.html +++ b/blog/sofa-weekly-230519/index.html @@ -355,7 +355,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -391,7 +391,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -477,7 +477,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -515,7 +515,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-230526/index.html b/blog/sofa-weekly-230526/index.html index 77a98761..9075c7fa 100644 --- a/blog/sofa-weekly-230526/index.html +++ b/blog/sofa-weekly-230526/index.html @@ -356,7 +356,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -392,7 +392,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -478,7 +478,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -516,7 +516,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-230609/index.html b/blog/sofa-weekly-230609/index.html index 69be2c07..84791418 100644 --- a/blog/sofa-weekly-230609/index.html +++ b/blog/sofa-weekly-230609/index.html @@ -338,7 +338,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -374,7 +374,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -460,7 +460,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -498,7 +498,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly-230616/index.html b/blog/sofa-weekly-230616/index.html index 9703675e..6da98f6d 100644 --- a/blog/sofa-weekly-230616/index.html +++ b/blog/sofa-weekly-230616/index.html @@ -355,7 +355,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -391,7 +391,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -477,7 +477,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -515,7 +515,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly/20220923/index.html b/blog/sofa-weekly/20220923/index.html index 0914fb52..0f71d6f7 100644 --- a/blog/sofa-weekly/20220923/index.html +++ b/blog/sofa-weekly/20220923/index.html @@ -343,7 +343,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -379,7 +379,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -465,7 +465,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -503,7 +503,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly/20221028/index.html b/blog/sofa-weekly/20221028/index.html index 590b7535..4117a985 100644 --- a/blog/sofa-weekly/20221028/index.html +++ b/blog/sofa-weekly/20221028/index.html @@ -331,7 +331,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -367,7 +367,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -453,7 +453,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -491,7 +491,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofa-weekly20210226/index.html b/blog/sofa-weekly20210226/index.html index f6f43ee6..0b51079d 100644 --- a/blog/sofa-weekly20210226/index.html +++ b/blog/sofa-weekly20210226/index.html @@ -374,7 +374,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -410,7 +410,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -496,7 +496,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -534,7 +534,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/index.html b/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/index.html index a9f64117..dacc5e0f 100644 --- a/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/index.html +++ b/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/index.html @@ -377,7 +377,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -413,7 +413,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -499,7 +499,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -537,7 +537,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/index.html b/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/index.html index 50c9591a..c76f7dc8 100644 --- a/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/index.html +++ b/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/index.html @@ -1545,7 +1545,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -1581,7 +1581,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -1667,7 +1667,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -1705,7 +1705,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofagw-cross-domain-communication-solution/index.html b/blog/sofagw-cross-domain-communication-solution/index.html index fb904868..1c91355d 100644 --- a/blog/sofagw-cross-domain-communication-solution/index.html +++ b/blog/sofagw-cross-domain-communication-solution/index.html @@ -473,7 +473,7 @@

  • Service Mesh 在『路口』的产品思考与实践：务实是根本
    • -
  • 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇
    • +
  • 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇
    • @@ -490,7 +490,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -526,7 +526,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -612,7 +612,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -650,7 +650,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofajraft-in-practice-in-the-same-tour/index.html b/blog/sofajraft-in-practice-in-the-same-tour/index.html index c84086f0..fa2c877b 100644 --- a/blog/sofajraft-in-practice-in-the-same-tour/index.html +++ b/blog/sofajraft-in-practice-in-the-same-tour/index.html @@ -919,7 +919,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -955,7 +955,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -1041,7 +1041,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -1079,7 +1079,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/index.html b/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/index.html index 6f39e725..5b83a01c 100644 --- a/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/index.html +++ b/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/index.html @@ -800,7 +800,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -836,7 +836,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -922,7 +922,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -960,7 +960,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/index.html b/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/index.html index d7dd8371..021ae963 100644 --- a/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/index.html +++ b/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/index.html @@ -906,7 +906,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -942,7 +942,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -1028,7 +1028,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -1066,7 +1066,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofarpc-5.5.x-nacos-hystrix/index.html b/blog/sofarpc-5.5.x-nacos-hystrix/index.html index cd66c1dc..cc2d356c 100644 --- a/blog/sofarpc-5.5.x-nacos-hystrix/index.html +++ b/blog/sofarpc-5.5.x-nacos-hystrix/index.html @@ -505,7 +505,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -541,7 +541,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -627,7 +627,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -665,7 +665,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofaserverless-system-for-speedy-business-development/index.html b/blog/sofaserverless-system-for-speedy-business-development/index.html index 383c8d13..55406c81 100644 --- a/blog/sofaserverless-system-for-speedy-business-development/index.html +++ b/blog/sofaserverless-system-for-speedy-business-development/index.html @@ -519,7 +519,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -555,7 +555,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -641,7 +641,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -679,7 +679,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack-2019-oscar/index.html b/blog/sofastack-2019-oscar/index.html index e0b72e2d..0b29ee60 100644 --- a/blog/sofastack-2019-oscar/index.html +++ b/blog/sofastack-2019-oscar/index.html @@ -307,7 +307,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -343,7 +343,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -429,7 +429,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -467,7 +467,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack-anniversary-1/index.html b/blog/sofastack-anniversary-1/index.html index 38d7931a..f398cbd4 100644 --- a/blog/sofastack-anniversary-1/index.html +++ b/blog/sofastack-anniversary-1/index.html @@ -303,7 +303,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -339,7 +339,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -425,7 +425,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -463,7 +463,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack-cloud-native-workshop-show/index.html b/blog/sofastack-cloud-native-workshop-show/index.html index 2b0f94c9..931b5511 100644 --- a/blog/sofastack-cloud-native-workshop-show/index.html +++ b/blog/sofastack-cloud-native-workshop-show/index.html @@ -391,7 +391,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -427,7 +427,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -513,7 +513,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -551,7 +551,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack-cncf-cloud-native-landscape/index.html b/blog/sofastack-cncf-cloud-native-landscape/index.html index 30214b56..db1cca87 100644 --- a/blog/sofastack-cncf-cloud-native-landscape/index.html +++ b/blog/sofastack-cncf-cloud-native-landscape/index.html @@ -340,7 +340,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -376,7 +376,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -462,7 +462,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -500,7 +500,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack-independent-droup/index.html b/blog/sofastack-independent-droup/index.html index 804f979a..16a4fa0c 100644 --- a/blog/sofastack-independent-droup/index.html +++ b/blog/sofastack-independent-droup/index.html @@ -315,7 +315,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -351,7 +351,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -437,7 +437,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -475,7 +475,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack-linux-china/index.html b/blog/sofastack-linux-china/index.html index 4b84c380..5780594e 100644 --- a/blog/sofastack-linux-china/index.html +++ b/blog/sofastack-linux-china/index.html @@ -374,7 +374,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -410,7 +410,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -496,7 +496,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -534,7 +534,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack-modular-isolation/index.html b/blog/sofastack-modular-isolation/index.html index 4f3b997b..d5b135d0 100644 --- a/blog/sofastack-modular-isolation/index.html +++ b/blog/sofastack-modular-isolation/index.html @@ -418,7 +418,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -454,7 +454,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -540,7 +540,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -578,7 +578,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack-open-source-doubles/index.html b/blog/sofastack-open-source-doubles/index.html index 52150a02..39cff762 100644 --- a/blog/sofastack-open-source-doubles/index.html +++ b/blog/sofastack-open-source-doubles/index.html @@ -347,7 +347,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -383,7 +383,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -469,7 +469,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -507,7 +507,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack-oschina-2018/index.html b/blog/sofastack-oschina-2018/index.html index 1238d38f..d498dd20 100644 --- a/blog/sofastack-oschina-2018/index.html +++ b/blog/sofastack-oschina-2018/index.html @@ -500,7 +500,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -536,7 +536,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -622,7 +622,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -660,7 +660,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack-projects-joined-cncf-landscape/index.html b/blog/sofastack-projects-joined-cncf-landscape/index.html index f7c424ca..72fd72fe 100644 --- a/blog/sofastack-projects-joined-cncf-landscape/index.html +++ b/blog/sofastack-projects-joined-cncf-landscape/index.html @@ -329,7 +329,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -365,7 +365,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -451,7 +451,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -489,7 +489,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack-user-yimi/index.html b/blog/sofastack-user-yimi/index.html index 34f3da2e..a616b225 100644 --- a/blog/sofastack-user-yimi/index.html +++ b/blog/sofastack-user-yimi/index.html @@ -446,7 +446,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -482,7 +482,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -568,7 +568,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -606,7 +606,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofastack20220927/index.html b/blog/sofastack20220927/index.html index c87bbea4..a9247ab5 100644 --- a/blog/sofastack20220927/index.html +++ b/blog/sofastack20220927/index.html @@ -445,7 +445,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -481,7 +481,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -567,7 +567,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -605,7 +605,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofatracer-completes-its-link-visualisation-journey/index.html b/blog/sofatracer-completes-its-link-visualisation-journey/index.html index b0897902..ddad3d9b 100644 --- a/blog/sofatracer-completes-its-link-visualisation-journey/index.html +++ b/blog/sofatracer-completes-its-link-visualisation-journey/index.html @@ -574,7 +574,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -610,7 +610,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -696,7 +696,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -734,7 +734,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sofaweekly-20230106/index.html b/blog/sofaweekly-20230106/index.html index f16d268c..3c0faae6 100644 --- a/blog/sofaweekly-20230106/index.html +++ b/blog/sofaweekly-20230106/index.html @@ -370,7 +370,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -406,7 +406,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -492,7 +492,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -530,7 +530,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/spring-boot-sofa-boot-class-isolation-integration/index.html b/blog/spring-boot-sofa-boot-class-isolation-integration/index.html index f613044e..66e25cef 100644 --- a/blog/spring-boot-sofa-boot-class-isolation-integration/index.html +++ b/blog/spring-boot-sofa-boot-class-isolation-integration/index.html @@ -600,7 +600,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -636,7 +636,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -722,7 +722,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -760,7 +760,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sqlflow-ai-didi-antfin-open-source-construction/index.html b/blog/sqlflow-ai-didi-antfin-open-source-construction/index.html index 488ae31e..3c43f0ec 100644 --- a/blog/sqlflow-ai-didi-antfin-open-source-construction/index.html +++ b/blog/sqlflow-ai-didi-antfin-open-source-construction/index.html @@ -332,7 +332,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -368,7 +368,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -454,7 +454,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -492,7 +492,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/sqlflow-open-source/index.html b/blog/sqlflow-open-source/index.html index 9d47be14..cbe714a2 100644 --- a/blog/sqlflow-open-source/index.html +++ b/blog/sqlflow-open-source/index.html @@ -372,7 +372,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -408,7 +408,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -494,7 +494,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -532,7 +532,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/still-worried-about-multi-cluster-management/index.html b/blog/still-worried-about-multi-cluster-management/index.html index 24a68b09..4ecc9def 100644 --- a/blog/still-worried-about-multi-cluster-management/index.html +++ b/blog/still-worried-about-multi-cluster-management/index.html @@ -458,7 +458,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -494,7 +494,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -580,7 +580,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -618,7 +618,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/index.html b/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/index.html index 6e8ab925..16d8b8ac 100644 --- a/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/index.html +++ b/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/index.html @@ -505,7 +505,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -541,7 +541,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -627,7 +627,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -665,7 +665,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/technical-financial-distributed-trading/index.html b/blog/technical-financial-distributed-trading/index.html index aa8b5046..9e1ff812 100644 --- a/blog/technical-financial-distributed-trading/index.html +++ b/blog/technical-financial-distributed-trading/index.html @@ -358,7 +358,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -394,7 +394,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -480,7 +480,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -518,7 +518,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/tengine-babassl-making-state-secrets-easier-to-use/index.html b/blog/tengine-babassl-making-state-secrets-easier-to-use/index.html index d9acde2b..f0a3aff0 100644 --- a/blog/tengine-babassl-making-state-secrets-easier-to-use/index.html +++ b/blog/tengine-babassl-making-state-secrets-easier-to-use/index.html @@ -404,10 +404,10 @@

  • SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验
    • -
  • SOFAArk Committer 专访｜看它不爽，就直接动手改！
    • -
  • 深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进
    • +
  • SOFAArk Committer 专访｜看它不爽，就直接动手改！
    • +
  • 网商双十一-基于 ServiceMesh 技术的业务链路隔离技术及实践
    • @@ -425,7 +425,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -461,7 +461,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -547,7 +547,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -585,7 +585,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/the-next-five-years-of-cloud-native-runtime/index.html b/blog/the-next-five-years-of-cloud-native-runtime/index.html index ac13d55b..9cb4ed17 100644 --- a/blog/the-next-five-years-of-cloud-native-runtime/index.html +++ b/blog/the-next-five-years-of-cloud-native-runtime/index.html @@ -639,7 +639,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -675,7 +675,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -761,7 +761,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -799,7 +799,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/the-next-five-years-of-sofastack/index.html b/blog/the-next-five-years-of-sofastack/index.html index 29d686c6..59fdef16 100644 --- a/blog/the-next-five-years-of-sofastack/index.html +++ b/blog/the-next-five-years-of-sofastack/index.html @@ -487,7 +487,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -523,7 +523,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -609,7 +609,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -647,7 +647,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/the-practice-and-thinking-behind-sofastack/index.html b/blog/the-practice-and-thinking-behind-sofastack/index.html index e2e0ff73..20fdba62 100644 --- a/blog/the-practice-and-thinking-behind-sofastack/index.html +++ b/blog/the-practice-and-thinking-behind-sofastack/index.html @@ -336,10 +336,10 @@

    @@ -403,7 +403,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -439,7 +439,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -525,7 +525,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -563,7 +563,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/index.html b/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/index.html index a3d0c956..4e8fdda1 100644 --- a/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/index.html +++ b/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/index.html @@ -407,7 +407,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -443,7 +443,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -529,7 +529,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -567,7 +567,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/1024/index.html b/categories/1024/index.html index 5abf577c..94acc62d 100644 --- a/categories/1024/index.html +++ b/categories/1024/index.html @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/cafedeployment/index.html b/categories/cafedeployment/index.html index 9f58d3a0..5c70c680 100644 --- a/categories/cafedeployment/index.html +++ b/categories/cafedeployment/index.html @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/elasticdl/index.html b/categories/elasticdl/index.html index ebe60b80..e53326e5 100644 --- a/categories/elasticdl/index.html +++ b/categories/elasticdl/index.html @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/kata-container/index.html b/categories/kata-container/index.html index b95348d2..350c54b6 100644 --- a/categories/kata-container/index.html +++ b/categories/kata-container/index.html @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/kata-containers/index.html b/categories/kata-containers/index.html index a472447d..a6457361 100644 --- a/categories/kata-containers/index.html +++ b/categories/kata-containers/index.html @@ -276,7 +276,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -312,7 +312,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -398,7 +398,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -436,7 +436,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/kubernetes/index.html b/categories/kubernetes/index.html index 2197ef86..c8c8fa8e 100644 --- a/categories/kubernetes/index.html +++ b/categories/kubernetes/index.html @@ -419,7 +419,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -455,7 +455,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -541,7 +541,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -579,7 +579,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/mosn/index.html b/categories/mosn/index.html index 11f3df49..b38436e4 100644 --- a/categories/mosn/index.html +++ b/categories/mosn/index.html @@ -377,7 +377,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -413,7 +413,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -499,7 +499,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -537,7 +537,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/occlum/index.html b/categories/occlum/index.html index caa6847a..4bdf585f 100644 --- a/categories/occlum/index.html +++ b/categories/occlum/index.html @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/seata/index.html b/categories/seata/index.html index 0608f296..3597c668 100644 --- a/categories/seata/index.html +++ b/categories/seata/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/serverless/index.html b/categories/serverless/index.html index db821efe..24719079 100644 --- a/categories/serverless/index.html +++ b/categories/serverless/index.html @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/service-mesh/index.html b/categories/service-mesh/index.html index 473ce883..e9872006 100644 --- a/categories/service-mesh/index.html +++ b/categories/service-mesh/index.html @@ -529,7 +529,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -565,7 +565,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -651,7 +651,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -689,7 +689,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/service-mesh/page/2/index.html b/categories/service-mesh/page/2/index.html index 5a61bb1d..b5ad77b0 100644 --- a/categories/service-mesh/page/2/index.html +++ b/categories/service-mesh/page/2/index.html @@ -529,7 +529,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -565,7 +565,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -651,7 +651,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -689,7 +689,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/service-mesh/page/3/index.html b/categories/service-mesh/page/3/index.html index 6af9844c..18cce52b 100644 --- a/categories/service-mesh/page/3/index.html +++ b/categories/service-mesh/page/3/index.html @@ -533,7 +533,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -569,7 +569,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -655,7 +655,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -693,7 +693,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/service-mesh/page/4/index.html b/categories/service-mesh/page/4/index.html index b253f523..3efe0302 100644 --- a/categories/service-mesh/page/4/index.html +++ b/categories/service-mesh/page/4/index.html @@ -397,7 +397,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -433,7 +433,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -519,7 +519,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -557,7 +557,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/index.html b/categories/sofa-weekly/index.html index 8bcddfec..180934ab 100644 --- a/categories/sofa-weekly/index.html +++ b/categories/sofa-weekly/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/10/index.html b/categories/sofa-weekly/page/10/index.html index a8a50345..35198031 100644 --- a/categories/sofa-weekly/page/10/index.html +++ b/categories/sofa-weekly/page/10/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/11/index.html b/categories/sofa-weekly/page/11/index.html index 4c91acd8..2039ba6e 100644 --- a/categories/sofa-weekly/page/11/index.html +++ b/categories/sofa-weekly/page/11/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/12/index.html b/categories/sofa-weekly/page/12/index.html index afbb68ef..fd97daa8 100644 --- a/categories/sofa-weekly/page/12/index.html +++ b/categories/sofa-weekly/page/12/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/13/index.html b/categories/sofa-weekly/page/13/index.html index ba2e6988..86dad494 100644 --- a/categories/sofa-weekly/page/13/index.html +++ b/categories/sofa-weekly/page/13/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/14/index.html b/categories/sofa-weekly/page/14/index.html index 8ccf41bd..2e0e771f 100644 --- a/categories/sofa-weekly/page/14/index.html +++ b/categories/sofa-weekly/page/14/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/15/index.html b/categories/sofa-weekly/page/15/index.html index 85cde952..e5d6b1a2 100644 --- a/categories/sofa-weekly/page/15/index.html +++ b/categories/sofa-weekly/page/15/index.html @@ -515,7 +515,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -551,7 +551,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -637,7 +637,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -675,7 +675,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/16/index.html b/categories/sofa-weekly/page/16/index.html index 3c0d1e85..750474d5 100644 --- a/categories/sofa-weekly/page/16/index.html +++ b/categories/sofa-weekly/page/16/index.html @@ -515,7 +515,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -551,7 +551,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -637,7 +637,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -675,7 +675,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/17/index.html b/categories/sofa-weekly/page/17/index.html index af451d9f..556aa341 100644 --- a/categories/sofa-weekly/page/17/index.html +++ b/categories/sofa-weekly/page/17/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/18/index.html b/categories/sofa-weekly/page/18/index.html index 1fd9631f..8364934c 100644 --- a/categories/sofa-weekly/page/18/index.html +++ b/categories/sofa-weekly/page/18/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/19/index.html b/categories/sofa-weekly/page/19/index.html index 1880d850..10c229bb 100644 --- a/categories/sofa-weekly/page/19/index.html +++ b/categories/sofa-weekly/page/19/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/2/index.html b/categories/sofa-weekly/page/2/index.html index d7aadb51..489ba3ff 100644 --- a/categories/sofa-weekly/page/2/index.html +++ b/categories/sofa-weekly/page/2/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/20/index.html b/categories/sofa-weekly/page/20/index.html index eb5bf650..b654ce5a 100644 --- a/categories/sofa-weekly/page/20/index.html +++ b/categories/sofa-weekly/page/20/index.html @@ -252,7 +252,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -288,7 +288,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -374,7 +374,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -412,7 +412,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/3/index.html b/categories/sofa-weekly/page/3/index.html index f2dfcf85..7562e93f 100644 --- a/categories/sofa-weekly/page/3/index.html +++ b/categories/sofa-weekly/page/3/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/4/index.html b/categories/sofa-weekly/page/4/index.html index 5f7b40af..54bb0a36 100644 --- a/categories/sofa-weekly/page/4/index.html +++ b/categories/sofa-weekly/page/4/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/5/index.html b/categories/sofa-weekly/page/5/index.html index 57bb68a3..ef116e5d 100644 --- a/categories/sofa-weekly/page/5/index.html +++ b/categories/sofa-weekly/page/5/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/6/index.html b/categories/sofa-weekly/page/6/index.html index 1bd9f34c..eba4e8cf 100644 --- a/categories/sofa-weekly/page/6/index.html +++ b/categories/sofa-weekly/page/6/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/7/index.html b/categories/sofa-weekly/page/7/index.html index 0679c76f..d97a01cd 100644 --- a/categories/sofa-weekly/page/7/index.html +++ b/categories/sofa-weekly/page/7/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/8/index.html b/categories/sofa-weekly/page/8/index.html index e37dda57..529f5b4e 100644 --- a/categories/sofa-weekly/page/8/index.html +++ b/categories/sofa-weekly/page/8/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa-weekly/page/9/index.html b/categories/sofa-weekly/page/9/index.html index fc208d92..3cb1a1da 100644 --- a/categories/sofa-weekly/page/9/index.html +++ b/categories/sofa-weekly/page/9/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofa/index.html b/categories/sofa/index.html index 563115ce..ac23a9e1 100644 --- a/categories/sofa/index.html +++ b/categories/sofa/index.html @@ -303,7 +303,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -339,7 +339,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -425,7 +425,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -463,7 +463,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofaacts/index.html b/categories/sofaacts/index.html index 72bfa475..8c9d0ec1 100644 --- a/categories/sofaacts/index.html +++ b/categories/sofaacts/index.html @@ -276,7 +276,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -312,7 +312,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -398,7 +398,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -436,7 +436,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofaark/index.html b/categories/sofaark/index.html index 292b40a9..26522965 100644 --- a/categories/sofaark/index.html +++ b/categories/sofaark/index.html @@ -369,7 +369,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -405,7 +405,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -491,7 +491,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -529,7 +529,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofabolt/index.html b/categories/sofabolt/index.html index 9d3d99f9..ea5b4538 100644 --- a/categories/sofabolt/index.html +++ b/categories/sofabolt/index.html @@ -401,7 +401,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -437,7 +437,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -523,7 +523,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -561,7 +561,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofaboot/index.html b/categories/sofaboot/index.html index 67358df0..449c638c 100644 --- a/categories/sofaboot/index.html +++ b/categories/sofaboot/index.html @@ -451,7 +451,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -487,7 +487,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -573,7 +573,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -611,7 +611,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofachannel/index.html b/categories/sofachannel/index.html index 221c8e2d..1127b722 100644 --- a/categories/sofachannel/index.html +++ b/categories/sofachannel/index.html @@ -543,7 +543,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -579,7 +579,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -665,7 +665,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -703,7 +703,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofachannel/page/2/index.html b/categories/sofachannel/page/2/index.html index d3e38080..85d1891f 100644 --- a/categories/sofachannel/page/2/index.html +++ b/categories/sofachannel/page/2/index.html @@ -533,7 +533,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -569,7 +569,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -655,7 +655,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -693,7 +693,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofachannel/page/3/index.html b/categories/sofachannel/page/3/index.html index b00a05ab..0240a124 100644 --- a/categories/sofachannel/page/3/index.html +++ b/categories/sofachannel/page/3/index.html @@ -535,7 +535,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -571,7 +571,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -657,7 +657,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -695,7 +695,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofachannel/page/4/index.html b/categories/sofachannel/page/4/index.html index 47da7e4b..60af051f 100644 --- a/categories/sofachannel/page/4/index.html +++ b/categories/sofachannel/page/4/index.html @@ -425,7 +425,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -461,7 +461,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -547,7 +547,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -585,7 +585,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofadashboard/index.html b/categories/sofadashboard/index.html index 807b797e..c3485d0b 100644 --- a/categories/sofadashboard/index.html +++ b/categories/sofadashboard/index.html @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofaenclave/index.html b/categories/sofaenclave/index.html index 09edd0e4..6a56fd65 100644 --- a/categories/sofaenclave/index.html +++ b/categories/sofaenclave/index.html @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofagw/index.html b/categories/sofagw/index.html index 0efe8a7e..0443efff 100644 --- a/categories/sofagw/index.html +++ b/categories/sofagw/index.html @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofajraft/index.html b/categories/sofajraft/index.html index f9b77896..918bda6e 100644 --- a/categories/sofajraft/index.html +++ b/categories/sofajraft/index.html @@ -545,7 +545,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -581,7 +581,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -667,7 +667,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -705,7 +705,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofajraft/page/2/index.html b/categories/sofajraft/page/2/index.html index eae04412..d6833b54 100644 --- a/categories/sofajraft/page/2/index.html +++ b/categories/sofajraft/page/2/index.html @@ -355,7 +355,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -391,7 +391,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -477,7 +477,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -515,7 +515,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofalab/index.html b/categories/sofalab/index.html index 7f04a63b..86c84369 100644 --- a/categories/sofalab/index.html +++ b/categories/sofalab/index.html @@ -342,7 +342,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -378,7 +378,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -464,7 +464,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -502,7 +502,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofalookout/index.html b/categories/sofalookout/index.html index b70beb48..43c9f249 100644 --- a/categories/sofalookout/index.html +++ b/categories/sofalookout/index.html @@ -276,7 +276,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -312,7 +312,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -398,7 +398,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -436,7 +436,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofameetup/index.html b/categories/sofameetup/index.html index df6e8159..ec79c48d 100644 --- a/categories/sofameetup/index.html +++ b/categories/sofameetup/index.html @@ -515,7 +515,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -551,7 +551,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -637,7 +637,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -675,7 +675,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofameetup/page/2/index.html b/categories/sofameetup/page/2/index.html index 2390b63a..45396b5a 100644 --- a/categories/sofameetup/page/2/index.html +++ b/categories/sofameetup/page/2/index.html @@ -322,7 +322,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -358,7 +358,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -444,7 +444,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -482,7 +482,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofamesh/index.html b/categories/sofamesh/index.html index 5db9cb5b..66190d24 100644 --- a/categories/sofamesh/index.html +++ b/categories/sofamesh/index.html @@ -332,7 +332,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -368,7 +368,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -454,7 +454,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -492,7 +492,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofaregistry/index.html b/categories/sofaregistry/index.html index 2cb46691..4a901210 100644 --- a/categories/sofaregistry/index.html +++ b/categories/sofaregistry/index.html @@ -543,7 +543,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -579,7 +579,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -665,7 +665,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -703,7 +703,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofaregistry/page/2/index.html b/categories/sofaregistry/page/2/index.html index 59a981dc..88074aa1 100644 --- a/categories/sofaregistry/page/2/index.html +++ b/categories/sofaregistry/page/2/index.html @@ -289,7 +289,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -325,7 +325,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -411,7 +411,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -449,7 +449,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofarpc/index.html b/categories/sofarpc/index.html index 69a3a354..d8b7f68c 100644 --- a/categories/sofarpc/index.html +++ b/categories/sofarpc/index.html @@ -545,7 +545,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -581,7 +581,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -667,7 +667,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -705,7 +705,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofarpc/page/2/index.html b/categories/sofarpc/page/2/index.html index c7bb0542..9b7c120f 100644 --- a/categories/sofarpc/page/2/index.html +++ b/categories/sofarpc/page/2/index.html @@ -454,7 +454,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -490,7 +490,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -576,7 +576,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -614,7 +614,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/index.html b/categories/sofastack/index.html index be69d5e2..60e4206f 100644 --- a/categories/sofastack/index.html +++ b/categories/sofastack/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/10/index.html b/categories/sofastack/page/10/index.html index 07b38269..65806d2b 100644 --- a/categories/sofastack/page/10/index.html +++ b/categories/sofastack/page/10/index.html @@ -512,7 +512,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -548,7 +548,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -634,7 +634,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -672,7 +672,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/11/index.html b/categories/sofastack/page/11/index.html index 6382ca10..f3145180 100644 --- a/categories/sofastack/page/11/index.html +++ b/categories/sofastack/page/11/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/12/index.html b/categories/sofastack/page/12/index.html index c21563a3..51749732 100644 --- a/categories/sofastack/page/12/index.html +++ b/categories/sofastack/page/12/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/13/index.html b/categories/sofastack/page/13/index.html index a7dba580..d3f78976 100644 --- a/categories/sofastack/page/13/index.html +++ b/categories/sofastack/page/13/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/14/index.html b/categories/sofastack/page/14/index.html index f1a31a0c..80c74826 100644 --- a/categories/sofastack/page/14/index.html +++ b/categories/sofastack/page/14/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/15/index.html b/categories/sofastack/page/15/index.html index 4db0441a..16290421 100644 --- a/categories/sofastack/page/15/index.html +++ b/categories/sofastack/page/15/index.html @@ -538,7 +538,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -574,7 +574,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -660,7 +660,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -698,7 +698,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/16/index.html b/categories/sofastack/page/16/index.html index ba057ff0..153ad8f5 100644 --- a/categories/sofastack/page/16/index.html +++ b/categories/sofastack/page/16/index.html @@ -528,7 +528,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -564,7 +564,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -650,7 +650,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -688,7 +688,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/17/index.html b/categories/sofastack/page/17/index.html index 6105119f..c62286ed 100644 --- a/categories/sofastack/page/17/index.html +++ b/categories/sofastack/page/17/index.html @@ -447,7 +447,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -483,7 +483,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -569,7 +569,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -607,7 +607,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/2/index.html b/categories/sofastack/page/2/index.html index 5e6c5768..33f3b020 100644 --- a/categories/sofastack/page/2/index.html +++ b/categories/sofastack/page/2/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/3/index.html b/categories/sofastack/page/3/index.html index 53ffa5cd..e95654be 100644 --- a/categories/sofastack/page/3/index.html +++ b/categories/sofastack/page/3/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/4/index.html b/categories/sofastack/page/4/index.html index 43b99b47..b758b49c 100644 --- a/categories/sofastack/page/4/index.html +++ b/categories/sofastack/page/4/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/5/index.html b/categories/sofastack/page/5/index.html index c4fa9df5..737e3d13 100644 --- a/categories/sofastack/page/5/index.html +++ b/categories/sofastack/page/5/index.html @@ -522,7 +522,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -558,7 +558,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -644,7 +644,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -682,7 +682,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/6/index.html b/categories/sofastack/page/6/index.html index e3156085..52b0f217 100644 --- a/categories/sofastack/page/6/index.html +++ b/categories/sofastack/page/6/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/7/index.html b/categories/sofastack/page/7/index.html index ea861a9d..7d429ea9 100644 --- a/categories/sofastack/page/7/index.html +++ b/categories/sofastack/page/7/index.html @@ -516,7 +516,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -552,7 +552,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -638,7 +638,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -676,7 +676,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/8/index.html b/categories/sofastack/page/8/index.html index c78fdb3b..c92566b0 100644 --- a/categories/sofastack/page/8/index.html +++ b/categories/sofastack/page/8/index.html @@ -514,7 +514,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -550,7 +550,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -636,7 +636,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -674,7 +674,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofastack/page/9/index.html b/categories/sofastack/page/9/index.html index ac05f27e..1749b70b 100644 --- a/categories/sofastack/page/9/index.html +++ b/categories/sofastack/page/9/index.html @@ -500,7 +500,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -536,7 +536,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -622,7 +622,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -660,7 +660,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofatalk/index.html b/categories/sofatalk/index.html index 49478898..a8569d82 100644 --- a/categories/sofatalk/index.html +++ b/categories/sofatalk/index.html @@ -249,7 +249,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -285,7 +285,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -371,7 +371,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -409,7 +409,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sofatracer/index.html b/categories/sofatracer/index.html index 31770969..9c062178 100644 --- a/categories/sofatracer/index.html +++ b/categories/sofatracer/index.html @@ -461,7 +461,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -497,7 +497,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -583,7 +583,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -621,7 +621,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/sqlflow/index.html b/categories/sqlflow/index.html index aa635297..361edfdd 100644 --- a/categories/sqlflow/index.html +++ b/categories/sqlflow/index.html @@ -303,7 +303,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -339,7 +339,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -425,7 +425,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -463,7 +463,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/categories/summer-2021/index.html b/categories/summer-2021/index.html index bfd52d55..f04831b1 100644 --- a/categories/summer-2021/index.html +++ b/categories/summer-2021/index.html @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/categories/\344\272\221\345\216\237\347\224\237/index.html" "b/categories/\344\272\221\345\216\237\347\224\237/index.html" index 39966af3..8c43405b 100644 --- "a/categories/\344\272\221\345\216\237\347\224\237/index.html" +++ "b/categories/\344\272\221\345\216\237\347\224\237/index.html" @@ -332,7 +332,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -368,7 +368,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -454,7 +454,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -492,7 +492,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/categories/\345\210\206\345\270\203\345\274\217\346\236\266\346\236\204/index.html" "b/categories/\345\210\206\345\270\203\345\274\217\346\236\266\346\236\204/index.html" index ec0b298a..4aeb8740 100644 --- "a/categories/\345\210\206\345\270\203\345\274\217\346\236\266\346\236\204/index.html" +++ "b/categories/\345\210\206\345\270\203\345\274\217\346\236\266\346\236\204/index.html" @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/categories/\345\221\250\345\271\264\345\272\206/index.html" "b/categories/\345\221\250\345\271\264\345\272\206/index.html" index afe51a0a..523ff006 100644 --- "a/categories/\345\221\250\345\271\264\345\272\206/index.html" +++ "b/categories/\345\221\250\345\271\264\345\272\206/index.html" @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/categories/\345\274\200\346\272\220\344\271\213\345\244\217/index.html" "b/categories/\345\274\200\346\272\220\344\271\213\345\244\217/index.html" index 78696115..2c272f22 100644 --- "a/categories/\345\274\200\346\272\220\344\271\213\345\244\217/index.html" +++ "b/categories/\345\274\200\346\272\220\344\271\213\345\244\217/index.html" @@ -303,7 +303,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -339,7 +339,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -425,7 +425,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -463,7 +463,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/categories/\345\276\256\346\234\215\345\212\241/index.html" "b/categories/\345\276\256\346\234\215\345\212\241/index.html" index 437cc3cb..ecb9ea0a 100644 --- "a/categories/\345\276\256\346\234\215\345\212\241/index.html" +++ "b/categories/\345\276\256\346\234\215\345\212\241/index.html" @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/categories/\346\231\272\350\203\275\347\233\221\346\216\247/index.html" "b/categories/\346\231\272\350\203\275\347\233\221\346\216\247/index.html" index 55c72a41..0fb24c3b 100644 --- "a/categories/\346\231\272\350\203\275\347\233\221\346\216\247/index.html" +++ "b/categories/\346\231\272\350\203\275\347\233\221\346\216\247/index.html" @@ -274,7 +274,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -310,7 +310,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -396,7 +396,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -434,7 +434,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/categories/\351\225\234\345\203\217/index.html" "b/categories/\351\225\234\345\203\217/index.html" index ad21e2f9..7af9226b 100644 --- "a/categories/\351\225\234\345\203\217/index.html" +++ "b/categories/\351\225\234\345\203\217/index.html" @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/en/algolia.json b/en/algolia.json index 2665059a..7220c783 100644 --- a/en/algolia.json +++ b/en/algolia.json @@ -1 +1 @@ -[{"author":null,"categories":["SOFAStack"],"content":" \nSOFAStack™ (Scalable Open Financial Architecture Stack) is a collection of cloud native middleware components, which are designed to build distributed systems with high performance and reliability, and have been fully validated by mission-critical financial business scenarios.\nLinks Home Page: https://www.sofastack.tech\nSource Code: https://github.com/sofastack\nProjects SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, log space isolation and asynchronous initialization of bean. SOFARPC is a high-performance, high-extensibility, production-level Java RPC framework. SOFAMesh SOFAMesh is a large-scale implementation solution for Service Mesh which is improved and extended based on Istio. SOFAMosn SOFAMosn(Modular Observable Smart Network) is a powerful proxy acting as Service Mesh\u0026amp;rsquo;s data plane written in Go. SOFATracer SOFATracer is a distributed link tracing system based onOpenTracing specification. SOFALookout SOFALookout is a lightweight and open source middleware service that solves the metrics and monitoring issues of the system. SOFABolt SOFABolt is a network communication framework implemented based on Netty. SOFAArk SOFAArk is a light-weight, java based classloader isolation framework. SOFAJarslink Is a dynamic modules and merged deployments solution based on SOFAArk. SOFAActs ACTS (AntCoreTest) is a white-box testing framework that is based on the accumulation of testing practices for financial-grade distributed architectures. SOFAJraft SOFAJRaft is a production-grade, high-performance Java implementation based on the RAFT consensus algorithm. SOFARegistry SOFARegistry is a production ready, high efficient, highly available service registry. SOFADashboard Is a one-stop console of SOFAStack. More projects in: github/sofastack\nCommunity Github\n WeChat\n Official Account：Antfin_SOFA is a technology exchange platform dedicated to building first-class distributed technologies in financial scenario applications, focusing on the most cutting-edge, reference-oriented technical solutions and implementation routes in the financial technology industry. WeChat Groups：We have ten groups and more than four thousand developers, Add ant-techfin02 as your friend, and reply SOFA will invite to joining into the group. DingTalk\n DingTalk Group:\n 「SOFAStack 1」 No: 23127468 Group is Full\n 「SOFAStack 2」 No: 23195297 Group is Full\n 「SOFAStack 3」 No: 23390449 Group is Full\n 「SOFAStack 4」 No: 23372465 Group is Full\n 「SOFAStack 5」 No: 30315793\n DingTalk Group:「SOFAStack Online service」, If you have used any SOFAStack related components in a production environment, please let us know, and we will invite you to join this group for faster communication and more efficient use of problem support online. Weibo\n SegmentFault\n juejin.im\n ","date":1524135415,"description":"Say hello to SOFAStack!","dir":"blog/hello-sofastack/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"26e249e6b2d0e482eb4404b76dabaec4","permalink":"https://sofastack.github.io/sofastack.tech/en/blog/hello-sofastack/","publishdate":"2018-04-19T11:56:55+01:00","readingtime":2,"relpermalink":"/sofastack.tech/en/blog/hello-sofastack/","summary":"SOFAStack™ (Scalable Open Financial Architecture Stack) is a collection of cloud native middleware components, which are designed to build distributed systems with high performance and reliability, and have been fully validated by mission-critical financial business scenarios.\nLinks Home Page: https://www.sofastack.tech\nSource Code: https://github.com/sofastack\nProjects SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, log space isolation and asynchronous initialization of bean.","tags":["SOFAStack"],"title":"Hello SOFAStack!","type":"blog","url":"/sofastack.tech/en/blog/hello-sofastack/","wordcount":383},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFA 六周年，Hello SOFA World！\n 活动时间：04 月 20 日 13:30\u0026amp;ndash;18:00\n 活动形式：线下 Meetup + 线上直播\n 资料下载：\n Apache Seata(incubating) 新征程\n探索微服务下一站，Koupleless 模块化研发框架与运维调度系统\n开源：除了代码之外还需要做哪些事？\n厚积薄发 - MOSN 社区开启新征程\nSOFABoot - 新一代研发框架\nEnvoy 网关基于 MOE 架构的落地与实践\n介绍 2024 年 4 月 20 日，\nSOFAStack 社区在上海 S 空间与社区小伙伴一起庆祝的第 6 个生日。\n大家一起进入到「SOFA 世界」\n非正式会议+室内露营的活动形式\n让 SOFAer 的技术交流更为轻松自在，现场的开源技术探索氛围十分浓厚。\n现场回顾 点击👉 云相册 进行查看\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 王特（花名：亦夏），Apache Seata(incubating) 社区 PPMC\n 赵真灵（花名：有济），Koupleless 社区负责人\n 马振军（花名：古今），Layotto 社区负责人\n 朱德江（花名：人德），MOSN 开源负责人\n 胡子杰（花名：致节），SOFABoot 社区 PMC\n 杜鑫，中国电子云技术专家、MOSN 社区开发者\n 议程 了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1713596400,"description":"2024 年 4 月 20 日，我们在上海一起庆祝了 SOFA 社区的六岁生日。","dir":"activities/sofa-6th-anniversary/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5711a60fad8f2916fe1fd7bbd9f07242","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-6th-anniversary/","publishdate":"2024-04-20T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-6th-anniversary/","summary":"概要 活动主题：SOFA 六周年，Hello SOFA World！ 活动时间：04 月 20 日 13:30\u0026ndash;18:00 活动形式：线下 Meetup + 线上直播 资料下载： Apache Seata(incubating) 新征程 探索微服务下一站，","tags":["SOFAStack","开源六周年"],"title":"SOFA 六周年，Hello SOFA World","type":"activities","url":"/sofastack.tech/activities/sofa-6th-anniversary/","wordcount":497},{"author":"呈铭","categories":"SOFAStack","content":" 王程铭（呈铭）\n蚂蚁集团技术工程师，Apache Committer\n专注 RPC、Service Mesh 和云原生等领域。\n本文 7368 字，预计阅读 15 分钟\n前言 MOSN（Modular Open Smart Network）是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并经过了双十一大促几十万容器的生产级验证。\nMOSN 为服务提供多协议、模块化、智能化、安全的代理能力，融合了大量云原生通用组件，同时也可以集成 Envoy 作为网络库，具备高性能、易扩展的特点。MOSN 可以和 Istio 集成构建 Service Mesh，也可以作为独立的四、七层负载均衡，API Gateway、云原生 Ingress 等使用。\nMOSN 作为数据面，整体由 NET/IO、Protocol、Stream、Proxy 四个层次组成，其中：\n NET/IO 用于底层的字节流传输\n Protocol 用于协议的 decode/encode\n Stream 用于封装请求和响应，在一个 conn 上做连接复用\n Proxy 做 downstream 和 upstream 之间 stream 的转发\n 那么 MOSN 是如何工作的呢？下图展示的是使用 Sidecar 方式部署运行 MOSN 的示意图，服务和 MOSN 分别部署在同机部署的 Pod 上， 您可以在配置文件中设置 MOSN 的上游和下游协议，协议可以在 HTTP、HTTP2.0 以及 SOFARPC 等中选择。\n以上内容来自官网 https://mosn.io\nRPC 场景下 MOSN 的工作机制 RPC 场景下，MOSN 的工作机制示意图如下：\n我们简单理解一下上面这张图的意义：\n Server 端 MOSN 会将自身 ingress 的协议端口写入到注册中心；\n Client 端 MOSN 会从注册中心订阅地址列表，第一次订阅也会返回全量地址列表，端口号是 Server 端 ingress 绑定的端口号；\n 注册中心会实时推送地址列表变更到 Client 端（全量）；\n Client 端发起 rpc 调用时，请求会被 SDK 打到本地 Client 端 MOSN 的 egress 端口上；\n Client 端 MOSN 将 RPC 请求通过网络转发，将流量通过负载均衡转发到某一台 Server 端 MOSN 的 ingress 端口处理；\n 最终到了 Server 端 ingress listener，会转发给本地 Server 应用；\n 最终会根据原来的 TCP 链路返回。\n 全局视野下的 MOSN 工作流程 现在我们已经了解了 MOSN 的工作机制，那么 MOSN 作为 MESH 的数据面，是怎么进行流量拦截并且将响应原路返回的呢？\n为了方便大家理解，我将以上时序图内容进行拆分，我们一一攻破。\n3.1 建立连接 MOSN 在启动期间，会暴露本地 egress 端口接收 Client 的请求。MOSN 会开启 2 个协程，分别死循环去对 TCP 进行读取和写处理。MOSN 会通过读协程获取到请求字节流，进入 MOSN 的协议层处理。\n// 代码路径 mosn.io/mosn/pkg/network/connection.go func (c *connection) Start(lctx context.Context) { // udp downstream connection do not use read/write loop if c.network == \u0026amp;quot;udp\u0026amp;quot; \u0026amp;amp;\u0026amp;amp; c.rawConnection.RemoteAddr() == nil { return } c.startOnce.Do(func() { // UseNetpollMode = false if UseNetpollMode { c.attachEventLoop(lctx) } else { // 启动读/写循环 c.startRWLoop(lctx) } }) } func (c *connection) startRWLoop(lctx context.Context) { // 标记读循环已经启动 c.internalLoopStarted = true utils.GoWithRecover(func() { // 开始读操作 c.startReadLoop() }, func(r interface{}) { c.Close(api.NoFlush, api.LocalClose) }) // 省略。。。 } 3.2 Protocol 处理 Protocol 作为多协议引擎层，对数据包进行检测，并使用对应协议做 decode/encode 处理。MOSN 会循环解码，一旦收到完整的报文就会创建与其关联的 xstream，用于保持 tcp 连接用于后续响应。\n// 代码路径 mosn.io/mosn/pkg/stream/xprotocol/conn.go func (sc *streamConn) Dispatch(buf types.IoBuffer) { // decode frames for { // 协议 decode，比如 dubbo、bolt 协议等 frame, err := sc.protocol.Decode(streamCtx, buf) if frame != nil { // 创建和请求 frame 关联的 xstream，用于保持 tcp 连接用于后续响应 sc.handleFrame(streamCtx, xframe) } } } func (sc *streamConn) handleFrame(ctx context.Context, frame api.XFrame) { switch frame.GetStreamType() { case api.Request: // 创建和请求 frame 关联的 xstream，用于保持 tcp 连接用于后续响应，之后进入 proxy 层 sc.handleRequest(ctx, frame, false) } } func (sc *streamConn) handleRequest(ctx context.Context, frame api.XFrame, oneway bool) { // 创建和请求 frame 关联的 xstream serverStream := sc.newServerStream(ctx, frame) // 进入 proxy 层并创建 downstream serverStream.receiver = sc.serverCallbacks.NewStreamDetect(serverStream.ctx, sender, span) serverStream.receiver.OnReceive(serverStream.ctx, frame.GetHeader(), frame.GetData(), nil) } 3.3 Proxy …","date":1711436400,"description":"从一次 RPC 请求，探索 MOSN 的工作流程","dir":"blog/explore-the-workflow-of-mosn-from-an-rpc-request/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9993f1cea8de40427d6ef6d8345f9d0c","permalink":"https://sofastack.github.io/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","publishdate":"2024-03-26T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","summary":"王程铭（呈铭） 蚂蚁集团技术工程师，Apache Committer 专注 RPC、Service Mesh 和云原生等领域。 本文 7368 字，预计阅读 15 分钟 前言 MOSN（Modul","tags":["SOFAStack"],"title":"从一次 RPC 请求，探索 MOSN 的工作流程","type":"blog","url":"/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","wordcount":2760},{"author":null,"categories":"SOFAStack","content":" 梁栎鹏（立蓬）\n蚂蚁集团技术工程师,云原生领域工程师\n就职于蚂蚁集团中间件团队，参与维护与建设蚂蚁 SOFAArk 和 Koupleless 开源项目，参与内部 SOFAServerless 产品的研发和实践。\n本文 4603 字，预计阅读 10 分钟\nbackground-你的企业应用协作效率低吗？ 明明只改一行，但代码编译加部署要十分钟？\n多人开发一套代码库，调试却频频遇到资源抢占和相互覆盖，需求上线也因此相互等待？\n当项目代码逐渐膨胀，业务逐渐发展，代码耦合、发布耦合以及资源耦合的问题日益加重，开发效率一降再降。\n如何解决？来试试把单个 Spring Boot 应用拆分为多个 Spring Boot 应用吧！拆出后，多个 Spring Boot 应用并行开发，互不干扰。在 Koupleless 模式下，业务可以将 Spring Boot 应用拆分成一个基座和多个 Koupleless 模块（Koupleless 模块也是 Spring Boot 应用）。\n🙌拉到「Koupleless 拆分插件解决方案」部分，可直接查看单体应用拆分的插件演示视频！\n关键挑战 从单个 Spring Boot 应用拆出多个 Spring Boot 应用有三大关键挑战：\n一是拆子应用前，复杂单体应用中代码耦合高、依赖关系复杂、项目结构复杂，难以分析各文件间的耦合性，更难从中拆出子应用，因此需要解决拆分前复杂单体应用中的文件依赖分析问题。\n二是拆子应用时，拆出操作繁琐、耗时长、用户需要一边分析依赖关系、一边拆出，对用户要求极高，因此需要降低拆分时用户交互成本。\n三是拆子应用后，单体应用演进为多应用共存，其编码模式会发生改变。Bean 调用方式由单应用调用演进为跨应用调用，特殊的多应用编码模式也需根据框架文档调整，比如在 Koupleless 中，为了减少模块的数据源连接，模块会按照某种方式使用基座的数据源，其学习成本与调整成本极高，因此需要解决拆分后多应用编码模式演进问题。\nKoupleless 拆分插件解决方案 针对以上三大关键挑战，Koupleless IntelliJ IDEA 插件将解决方案分为 3 个部分：分析、交互和自动化拆出，提供依赖分析、友好交互和自动化拆出能力，如下图：\n在分析中，分析项目中的依赖关系，包括类依赖和 Bean 依赖分析，解决拆分前复杂单体应用中的文件依赖分析问题；\n在交互中，可视化类文件之间的依赖关系，帮助用户梳理关系。同时，可视化模块目录结构，让用户以拖拽的方式决定要拆分的模块文件，降低拆分时的用户交互成本；\n在自动化拆出中，插件将构建模块，并根据特殊的多应用编码修改代码，解决拆分后多应用编码模式演进问题。\n🙌 Koupleless 半自动拆分演示视频，带你更直观了解插件如何在分析、交互、自动化拆出中提供帮助。\n一个示例，秒懂 Koupleless 解决方案优势 假设某业务需要将与 system 相关的代码都拆出到模块，让通用能力保留在基座。这里我们以 system 的入口服务 QuartzJobController 为例。\n步骤一：分析项目文件依赖关系 首先，我们会分析 QuartzJobController 依赖了哪些类和 Bean。\n 方式一：使用 Idea 专业版，对 Controller 做 Bean 分析和类分析，得到以下 Bean 依赖图和类依赖关系图 优势：借助 IDEA 专业版，分析全面\n劣势：需要对每个类文件都做一次分析，Bean 依赖图可读性不强。\n 方式二：凭借脑力分析 当 A 类依赖了B、C、D、\u0026amp;hellip;、N类，在拆出时需要分析每一个类有没有被其它类依赖，能不能够拆出到模块应用。\n优势：直观\n劣势：当 A 的依赖类众多，需要层层脑力递归。\n 方式三：使用 Koupleless 辅助工具，轻松分析！ 选择你想要分析的任意类文件，点击“分析依赖”，插件帮你分析～ 不仅帮你分析类文件依赖的类和 Bean，还提示你哪些类可以拆出，哪些类不能拆出。\n以 QuartzJobController 为例，当选定的模块中有 QuartzJobController, QuartzJobService 和 QuartzJobServiceImpl 时，QuartzJobController 依赖的类和 Bean 关系如下图所示：\nQuartzJobController 的依赖类/Bean 分为四类：已在模块、可移入模块、建议分析被依赖关系和不建议移入模块：\n 如果在模块中，则被标记为绿色“已在模块”，如：QuartzJobService 和 QuartzJobServiceImpl；\n 如果只被模块类依赖，那么被标记为蓝色“可移入模块”，如 JobQueryCriteria；\n 如果只被一个非模块类依赖，那么被标记为黄色“建议分析被依赖关系”，如 QuartLog；\n 如果被大量非模块类依赖，那么被标记为红色“不建议移入模块”，如 BadRequestException。\n 当使用插件对 QuartzJobController 和 JobQueryCriteria 进行分析时，依赖树和被依赖树如下，与上述分析对应：\n优势：直观、操作便捷、提示友好\n劣势：插件只支持分析常见的 Bean 定义和类引用\n步骤二：拆出到模块\u0026amp;amp;修改单应用编码为多应用编码模式\n选择相关的类文件拆出到模块。\n 方式一：复制粘贴每个文件、脑力分析所有模块基座之间的 Bean 调用、根据多应用编码模式修改代码。 在拆出时不可避免会面临这些问题：刚拆到哪儿了？这文件在没在模块里？我要不要重构这些包名？Bean 调用跨应用吗？多应用编码的文档在哪？\n优势：可以处理插件无法处理的多应用编码模式\n劣势：用户不仅需要分析跨应用 Bean 依赖关系，还需要学习多应用编码方式，人工成本较高。\n 方式二：使用 Koupleless 辅助工具，轻松拆出！ 根据你想要的模块目录结构，拖拽需要拆出的文件至面板。点击“拆出”，插件帮你分析，帮你根据 Koupleless 多应用编码模式修改～\n优势：直观、交互方便、插件自动修改跨应用 Bean 调用方式和部分特殊的多应用编码模式\n劣势：插件只能根据部分多应用编码模式修改代码，因此用户需要了解插件能力的范围\n技术方案 在上文中我们已经知道，插件将整体流程分为 3 个阶段：分析阶段、交互阶段和自动化拆出阶段，整体流程如下图所示：\n 在分析阶段中，分析项目中的依赖关系，包括类依赖、Bean 依赖和特殊的多应用编码分析，如：MyBatis 配置依赖；\n 在交互阶段，可视化类文件之间的依赖关系和模块目录结构；\n 在自动化拆出阶段，插件首先将构建模块并整合配置，然后根据用户需要重构包名，接着修改模块基座 Bean 调用方式，并根据特殊的多应用编码修改代码，如：自动复用基座数据源。\n 接下来，我们将分别简单介绍分析阶段、交互阶段和自动化拆出阶段中用到的主要技术。\n分析阶段 插件分别使用 JavaParser 和 commons-configuration2 扫描项目中的 Java 文件和配置文件。\n类依赖分析 为了准确地分析出项目的类依赖关系，插件需要完整分 …","date":1710831600,"description":"单体应用协作开发太难？Koupleless 带来拆分插件，帮你抽丝剥茧提高协作开发效率！","dir":"blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"31cd46eb078e59933c6f2c5cf7b32bc8","permalink":"https://sofastack.github.io/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","publishdate":"2024-03-19T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","summary":"梁栎鹏（立蓬） 蚂蚁集团技术工程师,云原生领域工程师 就职于蚂蚁集团中间件团队，参与维护与建设蚂蚁 SOFAArk 和 Koupleless 开源项目，参与内部 SOFAServerless 产品的研发和实践。 本","tags":["SOFAStack"],"title":"单体应用协作开发太难？Koupleless 带来拆分插件，帮你抽丝剥茧提高协作开发效率！","type":"blog","url":"/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","wordcount":3944},{"author":null,"categories":"SOFAStack","content":" 文｜祁晓波\n南京爱福路汽车科技基础设施负责人\n主要研究微服务、可观测、稳定性、研发效能、Java 中间件等领域。\n本文 4812 字 阅读 12 分钟\nKoupleless *（原 SOFAServerless）* 自 2023 年开源以来已经落地了若干企业，这些企业也见证了从 SOFAServerless 到 Koupleless 的品牌\u0026amp;amp;技术能力迭代升级。随着 Koupleless 1.0 的重磅发布，一些企业已经在内部取得了不错的效果，例如南京爱福路汽车科技有限公司。\n南京爱福路汽车科技有限公司和大多数科技企业一样，在企业生产开发过程遇到了微服务的一些问题，例如资源成本过高、启动慢等问题。在看到 Koupleless 项目正不断开源出实实在在的能力和案例，在解决很实际的微服务痛点问题，决定采用 Koupleless 进行尝试，并随着 Koupleless 一路走来，已经将 6 个应用合并成 1 个应用大幅降低资源成本，取得了不错的效果。\n1｜背景 南京爱福路汽车科技有限公司 *（以下简称爱福路）* 作为行业 top 的汽车后市场解决方案提供商，为维修门店提供智慧管理系统、为行业提供维修应用大数据，致力于成为汽车后市场数智化构建者。\n随着其服务的企业增多，爱福路也越来越多地接触到了各类体量的企业。\n这就对爱福路的服务提供形式提出了较多不同的诉求： 除了单纯的公有云 SAAS 之外，还包括私有化部署等解决方案的诉求。\n2｜问题提出 我们知道，随着微服务和云原生技术的普及，应用数量急剧膨胀。\n如此多的应用也带来了比较大的成本问题。\n爱福路在为海量公域客户提供服务的时候，更关注稳定、弹性。\n但是在为某个客户提供独立部署方案时，爱福路发现如此多的服务在部署到 K8s 时所带来的服务器成本非常高 *（通常来说，独立部署服务面向的客户群体比之公域客户少了 1-2 个数量级）*，而单个客户也很难有足够的预算负担整个部署方案。这就大大阻塞了爱福路后续持续拓展私有化部署客户的进度。\n举个例子：一个应用在进行 K8s 交付时，最少会提供两个副本；而大量这样的 Java 应用存在对于整体的集群利用率不高，继而造成较高的成本。\n因此爱福路面临着如下的课题： 当进行私有化交付时，如何能够更便捷地、低成本地交付我们现有的产物？\n其中，低成本至少应该包含如下几个角度：\n 既存代码的低成本改造； 新的交付方式低成本的维护； 运行产物低成本的 IT 成本。 3｜问题探索和推导 爱福路基于当前的微服务架构和云原生方式进行了思考和探索： 是否到了爱福路微服务架构进一步升级的时候了？\n在当前整体降本增效的大环境趋势中，在保持服务稳定的前提下对于服务器有更加极致的使用。\n从业务视角来看，服务单店的整体服务器成本越低，爱福路的竞争力就越强。\n那么，有没有可能在保持 Java 的生态环境下，低成本的同时能够保证爱福路继续享受云原生的红利？爱福路做了如下推导：\n通过上述的推导，爱福路判断也许「模块化+Serverless」将是一种解法。\n因此一款来自蚂蚁的开源框架成为他们重点的关注，那就是 Koupleless。（阅读原文可跳转官网地址：https://koupleless.io/user-cases/ant-group/）\n当然一个重要原因是蚂蚁开源一直做得不错，社区也比较活跃。除了社区群和 GitHub 之外，PMC 有济也积极地建立了独享的 VIP 群进行专门对接。\n4｜Koupleless（原 SOFAServerless） Koupleless 技术体系是在业务发展、研发运维的复杂性和成本不断增加的情况下，蚂蚁集团为帮助应用又快又稳地迭代而决定研发，从细化研发运维粒度和屏蔽基础设施的角度出发，演进出的一套低成本接入的「模块化+Serverless」解决方案。\n核心方式是通过类隔离和热部署技术，将应用从代码结构和开发者阵型拆分为两个层次：业务模块和基座，基座为业务模块提供计算环境并屏蔽基础设施，模块开发者不感知机器、容量、中间件等基础设施，专注于业务研发帮助业务快速向前发展。\n合并部署降成本 在企业中， “80%” 的长尾应用仅服务 “20%” 的流量，蚂蚁集团也不例外。\n在蚂蚁集团存在大量长尾应用，每个长尾应用至少需要 预发布、灰度、生产 3 个环境，每个环境最少需要部署 3 个机房，每个机房又必须保持 2 台机器高可用，因此大量长尾应用 CPU 使用率不足 10%。\n通过使用 Koupleless，蚂蚁集团对长尾应用进行了服务器裁撤，借助类委托隔离、资源监控、日志监控等技术，在保证稳定性的前提下，实现了多应用的合并部署，极大降低了业务的运维成本和资源成本。\n此外，采用这种模式，小应用可以不走应用申请上线流程，也不需要申请机器，可以直接部署到业务通用基座之上，从而帮助小流量业务实现了快速创新。\n2023 年底 SOFAServerless 品牌全新升级为 Koupleless（GitHub页面：https://github.com/koupleless/koupleless）。\n企业里不同业务有不同的发展阶段，因此应用也拥有自己的生命周期。\n  * 初创期：一个初创的应用一般会先采用单体架构。 * 增长期：随着业务增长，应用开发者也随之增加。此时您可能不确定业务的未来前景，也不希望过早把业务拆分成多个应用以避免不必要的维护、治理和资源成本，那么您可以用 Koupleless 低成本地将应用拆分为一个基座和多个功能模块，不同功能模块之间可以并行研发运维独立迭代，从而提高应用在此阶段的研发协作和需求交付效率。 * 成熟期：随着业务进一步增长，您可以使用 Koupleless 低成本地将部分或全部功能模块拆分成独立应用去研发运维。 * 长尾期：部分业务在经历增长期或者成熟期后，也可能慢慢步入到低活状态或者长尾状态，此时您可以用 Koupleless 低成本地将这些应用一键改回模块，合并部署到一起实现降本增效。\n 应用生命周期演进\n可以看到 Koupleless 主要通过将应用模块化来降低整个服务的运行成本，更值得称道的是支持模块和应用的来回切换，可以更低成本地接入，支持平滑演进。\n5｜架构适配尝试 Spring Boot 1「可行性确认」 爱福路的存量应用中，九成使用的是 Spring Boot 1，RPC 主要依赖 Dubbo 2.6。这点和社区是有一定出入的，社区仅仅支持 SpringBoot 2。\n为此爱福路需要尝试对于 Spring Boot 1 的支持，也因此提出了相应的 issue👇\nhttps://github.com/sofastack/sofa-ark/issues/268\n通过和社区沟通协调确认，爱福路发现只是社区没能够完全覆盖到这块，企业自身可以通过部分扩展进行支持。\n当时社区同学认为这个是比较重要的变更，可以进一步覆盖更多的社区用户，为此还特地调整了中央仓库的发版频次：加速 review、加速发 snapshot。\n正是这些细节让爱福路更加信任 Koupleless 团队👍，也坚定了此次方案能够实际落地的信心。\n应用合并 当 Spring Boot 1 得到支持之后，爱福路可以快速地将原来的 …","date":1709017200,"description":"高效降本｜深度案例解读 Koupleless 在南京爱福路的落地实践","dir":"blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0c6483ccd63328d158a35bc8b5b81940","permalink":"https://sofastack.github.io/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","publishdate":"2024-02-27T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","summary":"文｜祁晓波 南京爱福路汽车科技基础设施负责人 主要研究微服务、可观测、稳定性、研发效能、Java 中间件等领域。 本文 4812 字 阅读 12 分钟 Koupleless *（原 SOFA","tags":["SOFAStack"],"title":"高效降本｜深度案例解读 Koupleless 在南京爱福路的落地实践","type":"blog","url":"/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","wordcount":3555},{"author":null,"categories":"SOFAStack","content":" 如果你是企业经营者，在为企业降本增效而发愁； 如果你是企业的开发、运维或架构同学，在日常工作中被开发效率、交付问题等困扰…… 欢迎来了解 Koupleless *（原 SOFAServerless）*！\n现在，Koupleless 重磅发布了1.0 版本！（👈点击查看 release note）\n那么，Koupleless 是什么？又将如何为你解决以上问题？除了以上这几种情境，Koupleless 还有哪些能力呢？欢迎你来社区探索发现。\nKoupleless 是什么？ Koupleless 由 SOFAServerless 品牌升级而来，是一款模块化研发框架与运维调度平台。它从应用架构角度出发，帮助应用解决从需求、到研发、到交付再到运维的全生命周期痛点问题。其最核心的架构图如下👇。如果想了解更详细的原理介绍也可以查看官网页面：https://koupleless.gitee.io/docs/introduction/architecture/arch-principle/。\n它能帮助解决的问题包括：\n 应用拆分过度，机器成本和长期维护成本高； 应用拆分不够，多人协作互相阻塞； 应用构建、启动与部署耗时久，应用迭代效率不高； SDK 版本碎片化严重，升级成本高周期长； 平台、中台搭建成本高，业务资产沉淀与架构约束困难； 微服务链路过长，调用性能不高； 微服务拆分、演进成本高； 如果你也被以上问题所困扰，那么欢迎来了解 Koupleless 给出的解决方案。 本模式在蚂蚁集团内部历经 4-5 年时间孵化而成，当前已经帮助 70W 核业务量完成 10 倍级降本增效，可以帮助应用做到秒级启动，只占 20M 内存。\n性能对比示例如下图👇。\n根据我们的模块化应用架构模型，可以看到我们是将传统应用从纵向和横向切分演变而来的。\n所以我们将 SOFAServerless 进行品牌升级成为 Koupleless，取自 Couple + less，寓意通过对应用进行拆分解耦，实现更好的职责分工，帮助业务降本增效。\n我们为什么开源？ 关注应用架构领域的同学，应该知道微服务很好地解决了组织分布式协作难题，但同时也带来了一些问题，并且这些问题正日益获得更多关注。 有人说，2023 年是微服务的转折年[1]，其中一些科技巨头*（如 Amazon 和 Google ）*已经开始尝试去解决和完善微服务带来的问题，例如 service weaver[2]，amazon prime video[3]的架构改造，甚至直接回归单体。\n而蚂蚁内部在 4-5 年前就开始着手解决微服务问题，并为此打造了 Koupleless 应用研发模式。 根据蚂蚁这些年的实践经验，我们相信模块化架构是一种有潜力的架构，真正能够较好地解决微服务问题；我们也希望通过模块化架构给行业内部提供一种新的解决方案，帮助更多企业降本增效。\n开源提供了哪些能力？ 自 2023 年下半年开源以来，经过这半年时间和社区的共同努力，我们已经开放了内部完整的能力，包括研发工具、框架、运维调度平台等；也沉淀了一些常用组件最佳实践和 samples 用例（具体查看 release note：https://github.com/koupleless/koupleless/releases/tag/v1.0.0）。 具备了线上接入使用的能力，一些企业也已经可以按照官网和文档自主接入使用了。\n 研发工具 Arkctl一键构建、部署和发布模块，方便用于本地开发测试验证。 Arklet、SOFAArk 和 Runtime 组件为多种研发框架如 Spring Boot、SOFABoot、Dubbo 提供多模块运行容器环境，适配 30+ 组件，沉淀 25+ samples 用例。 控制面组件 ModuleControllerModuleDeployment，提供模块发布与运维能力； ModuleScheduler，提供模块基础调度能力； ModuleScaler，提供模块扩缩容能力。 有了这些组件之后，从开发验证 -\u0026amp;gt; 交付上线 -\u0026amp;gt; 日常运维全流程的基本能力已经具备，1.0 版本实现生产可用级别。\n挑战与亮点 这套模式最大的挑战来自于将多个应用或代码片段合并在一起，在隔离与共享上如何找到最佳的平衡点，使得在存量应用低成本接入的同时，能享受到隔离的带来稳定可靠的好处，也能享受到共享的高性能、低资源消耗的收益。\n隔离可以确保运行时的稳定可靠，但带来了性能的下降、资源利用率的损失；共享提升了性能和资源利用率，但也带来了运行时的一些问题，例如 static 变量可能带来互相影响的问题。我们采用了模块化技术来解决这类问题。在 Java 领域模块化技术并不是我们首创的，20 年前就有了 OSGl 技术，那为什么我们的模块化技术能在蚂蚁内部规模化落地呢？我们是做了哪些工作来解决存量应用低成本接入和共享后的一些问题的呢？\n要解决这类问题，我们并没有太多可参考的行业案例，相当于是在无人区里摸索，除了解决隔离与共享的核心问题外，还要解决配套设施的建设、用户心智的培养等，这些都需要一个笃定的心力和持续的过程，这些问题就是这套模式的挑战所在。 好在最终，我们拨云见日探索了出来。我们在隔离和共享之间找到了一个最佳的平衡点，并且能让存量业务低成本的接入，这也是我们最自豪的地方。我们在蚂蚁集团用事实证明了模块化技术并不是停留在设计稿里的技术，或者小部分人才能使用的技术，它的问题和挑战并不可怕，是有固定模式的，可以通过工具和流程逐步治理、收敛的，现在将此模式进行开源分享，是希望可以帮助其他企业少走弯路，和社区一起把这套模式心智在行业里树立起来。\nKoupleless 已接入 15+ 企业 当前在统计内的，有 15+ 企业在使用 Koupleless 接入线上或者用于交付，还有 17+ 企业正在试用或者接入中，还有一些因为信息缺失未统计到的。详细企业接入列表可以查看官网信息[4]。 很高兴 Koupleless 能帮助到他们，也十分欢迎这些企业探索的更多使用场景，也欢迎更多企业开发者一起参与社区建设，推广这套技术。\nKoupleless 未来的规划 我们希望能让模块化架构成为应用架构领域里的新模式，并能在行业里推广开来。这不仅是我们作为技术人的技术追求，也是我们做开源的持续动力来源。 当前我们虽然发布了 1.0 版本，但开源工作才只是刚刚开始，还有更多规划。比如，我们希望未来能把模块化技术做得更加完善，将我们想要做到的效果完整地提供出来：\nSpeed as you need, Pay as you need， Deploy as you need， Evolve as you need 。 需要的能力包括支持各种框架、运行时组件、中间件服务，还有非常多相关的配套设施；也希望这套模式能在更多语言里发挥出效果，例如 Go 语言，以此和更多的小伙伴们一起探索出微服务领域的下一站。\n这里感谢所有参与贡献 Koupleless 1.0 的 51 位开发者： @QilingZhang @lvjing2 @glmapper @yuanyuancin @lylingzhen @yuanyuan2021 …","date":1707202800,"description":"成倍降本增效，提升企业竞争力！SOFAServerless 品牌升级为 Koupleless，重磅发布 1.0 版本","dir":"blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bf0d878bbdb545204ab25a89a7c592ac","permalink":"https://sofastack.github.io/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","publishdate":"2024-02-06T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","summary":"如果你是企业经营者，在为企业降本增效而发愁； 如果你是企业的开发、运维或架构同学，在日常工作中被开发效率、交付问题等困扰…… 欢迎来了解 Koupleless *（原","tags":["SOFAStack"],"title":"成倍降本增效，提升企业竞争力！SOFAServerless 品牌升级为 Koupleless，重磅发布 1.0 版本","type":"blog","url":"/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","wordcount":2620},{"author":null,"categories":"SOFAStack","content":" 今天 SOFAStack 邀请到了开源之夏 2023 Layotto 社区的中选学生陈亦昺同学！在本项目中，他负责可插拔式组件的开发。希望他分享的这段经历，能让更多人了解到 Layotto 开源社区，感受开源的魅力～\n项目链接：https://summer-ospp.ac.cn/org/prodetail/23f080194?list=org\u0026amp;amp;navpage=org\n项目名称 Layotto support pluggable components\n项目导师 王文学\n项目背景描述 Layotto 是一款基于云原生的应用运行时，旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，比如状态管理、配置管理、事件发布订阅等能力，以简化应用的开发。同时，它以 MOSN 项目为底座，在提供分布式能力以外，还提供了 Service Mesh 的流量管控能力。\nLayotto 对用户程序暴露 API，用户程序可以通过 API 调度对应的运行时服务。例如 Layotto 支持 config 服务，其内部会使用含有各种 component (如 Nacos，Apollo，Etcd 等) 的 SDK 来提供 config API 能力。\n当前 Layotto 的 component 都是实现在 Layotto 的工程里面的。这也就使得用户在想要使用新的 component 时，必须使用 Golang 语言开发，同时必须在 Layotto 工程中实现，再进行统一编译。这种体验对于多语言用户来说非常不友好。\n因此 Layotto 需要提供 pluggable components 的能力，允许用户通过任何语言实现自己的 component，而 Layotto 则通过 gRPC 协议和外部的 component 进行通信。\n项目实现思路 方案 基于 UDS（Unix Domain Socket）实现本地跨语言组件服务发现，降低通信开销。\n 基于 proto 实现组件跨语言实现能力。\n 数据流架构 组件发现 如上图所示，用户自定义组件启动 socket 服务，并将 socket 文件放到指定目录中。Layotto 启动时，会读取该目录中的所有 socket 文件（跳过文件夹），并建立 socket 连接。\n目前，Layotto 向 Dapr 对齐，不负责用户组件的生命周期。这就意味着在服务期间，用户组件下线后不会进行重连，则该组件服务无法使用。后面会根据社区使用情况，来决定 Layotto 是否需要支持进程管理模块，或是使用一个单独的服务来管理。\n由于 Windows 对于 UDS 的支持还不是很完善，且 Layotto 本身取消了对 Windows 的兼容，所以新特性采用的 UDS 发现模式未对 Windows 系统做兼容。\n组件注册 如上面的数据流架构图所示，用户注册的组件需要实现 pluggable proto 定义的 gRPC 服务。Layotto 会根据 gRPC 接口，实现 Go interface 接口，这里对应于数据流图中的 wrapper component。wrapper component 与 built-in component 对 Layotto Runtime 来说没有任何区别，用户也不会有特殊的感知。\nLayotto 通过 gRPC reflect 库，获取到用户提供服务实现了哪些组件，然后注册到全局的组件注册中心，以供用户使用。\n开源之夏个人随访 自我介绍 大家好，我是陈亦昺，目前就读于杭州电子科技大学，大三学生。自从大二开始，我对开源产生了浓厚的兴趣，特别是在云原生和微服务领域。\n起初，我主要为我个人感兴趣的项目提供使用案例和文档支持，随后逐渐开始贡献一些简单的功能。例如，我为 Kratos 贡献了一个简单的 toml 配置文件解析器，并向 go-zero 提供了一些建议，改进了它的优雅关闭（Graceful Shutdown）功能。\n之后，我接触到了服务网格领域，认识了 MOSN 社区，并开始为其中的子项目 Layotto 做开源贡献：我修复了一些 makefile 脚本使用中的 bug、编写了 Go SDK 的使用文档、并尝试对 Nacos 组件进行封装。\n申请本社区项目的原因 SOFAStack 是一个金融级的云原生架构，内部孵化了许多吸引我的微服务项目。接触 SOFAStack 社区以来，我发现他们对开源贡献十分重视，仓库中有丰富的文档来帮助用户了解项目的背景、功能、代码模块等。\n👉SOFAStack 仓库地址：https://github.com/sofastack\nMOSN 项目也组织过源码阅读活动，将 MOSN 核心组件的代码设计整理成文档；仓库所有者也会为新人提供适合入手的 issue 作为开始。所以在 OSPP 活动开始之前，我其实就先认识了 SOFAStack 社区，并对其新兴项目 Layotto 做了一定的贡献。OSPP 开始后，我很快与导师取得联系，并得知可以参考 Layotto 对标项目 Dapr 的设计实现。于是，我翻阅了 Dapr 的相关文档、该功能实现时的 issues，阅读了该块功能的源码，最终得出适合移植到 Layotto 的方案。\n如何克服项目过程中的困难与挑战？ 在项目开发的初期阶段，导师会引导我了解项目的愿景、业务背景和代码结构；当我在开发过程中遇到困难时，导师为我提供了很多实质性的建议和改进方向；此外，社区每周三定期举行社区会议，让我们可以同步项目开发进度、讨论遇到的问题，共同寻求解决方案。\n在开发过程中我其实遇到了不少问题，其中一个让我印象深刻的是 Go 依赖冲突问题。早期，Layotto 参考了 Dapr 的一些组件接口设计，并直接引入了 Dapr 仓库的代码，这样直接复用了 Dapr 组件的功能，也避免了重复劳动。但是早期的 Dapr 并没有实现可插拔组件的功能，为了让新功能与 Dapr 组件保持兼容，我必须将 Dapr 升级到能够实现该功能的版本。\n然而，这两个版本之间存在许多不兼容的变化（尽管对外提供的服务接口并没有改变），所以一旦我升级了依赖，Layotto 就会出现大量错误。最终在与导师的沟通中，我们一致认为这部分兼容性工作的收益不大，只需实现新的接口供用户使用即可。\n你眼中的社区印象 SOFAStack 是一个充满开源精神的、热情的社区，欢迎并鼓励学生和开源爱好者积极参与其中。同时，SOFAStack 社区也是专业的，它专注于云原生和金融领域的技术创新和解决方案，旨在帮助开发者快速构建和管理云原生应用，提高应用的可伸缩性、弹性以及可靠性。\n一些收获 参加这次开源之夏项目使我获益匪浅。我对云原生有了进一步的深刻理解，并在实际业务操作中积累了宝贵的经验。同时，参加这个活动还扩展了我的知识技能，激发了我对开源项目做出贡献的热情。\n通过与导师和社区的合作，我学会了如何与其他开发者协作、如何提出和解决问题，并且还掌握了使用开源工具和资源的技巧。通过阅读 Layotto 和 Dapr 的源代码，我掌握了许多关于程序设计的经验，例如编写可测试的代码、命名规范、如何构建单元测试用例等等。这 …","date":1700550000,"description":"开源之夏经验分享｜Layotto 社区 陈亦昺：保持热情、全力以赴！","dir":"blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e50c0aaf2bd1fc9a639cb47390aa1839","permalink":"https://sofastack.github.io/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","publishdate":"2023-11-21T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","summary":"今天 SOFAStack 邀请到了开源之夏 2023 Layotto 社区的中选学生陈亦昺同学！在本项目中，他负责可插拔式组件的开发。希望他分享的这段经历，能让更多人了解到 Layotto 开源社区，","tags":["SOFAStack"],"title":"开源之夏经验分享｜Layotto 社区 陈亦昺：保持热情、全力以赴！","type":"blog","url":"/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","wordcount":2488},{"author":null,"categories":"SOFAStack","content":" 北京时间 2023 年 10 月 29 日，分布式事务开源项目 Seata 通过 Apache 基金会的投票决议，以全票通过的优秀表现正式成为 Apache 孵化器项目！\n根据 Apache基金会邮件列表显示，包含 13 个约束性投票（binding votes）和 6 个无约束性投票（non-binding votes）的投票全部持赞同意见，无弃权票和反对票，投票顺利通过。\n“Welcome Seata to the ASF incubator.”\n项目历史 早在 2007 年\n蚂蚁集团和阿里巴巴就在内部开发了分布式事务中间件，用于解决电商、支付、物流等业务场景中应用数据的一致性问题。内部项目分别被称为 XTS（eXtended Transaction Service）/TXC（Taobao Transaction Constructor），该项目几乎在每笔订单的交易支付链路几乎都有使用。\n自 2013 年以来\n蚂蚁集团在金融云上向企业客户发布了分布式事务云服务产品 DTX（Distributed Transaction-eXtended），阿里巴巴在阿里云上发布 GTS（global transaction service），两者均在各个行业领域积累了大量用户。\n2019 年 1 月\n阿里巴巴集团正式开源了该项目，项目命名为 Fescar（Fast \u0026amp;amp; Easy Commit and Rollback）。项目开源以来，它受到了众多开发人员的热烈欢迎和赞扬，开源一周收获了超 3k star，曾一度蝉联 GitHub Trending 排行榜第一。\n2019 年 4 月\n蚂蚁集团数据中间件团队加入了 Fescar 社区。为了创建一个更加开放和中立的社区，Fescar 改名为 Seata（Simple Extensible Autonomous Transaction Architecture），代码仓库从 Alibaba organization 迁移到其独立的 Seata organization。\n2019 年 12 月\nSeata 开源项目正式发布 1.0.0 GA 版本，标志着项目已基本可生产使用。\n2023 年 10 月\n为了更好地通过社区驱动技术的演进，蚂蚁集团和阿里巴巴携手，正式将 Seata 捐赠给 Apache 基金会，提案通过了 Apache 基金会的投票决议。\n项目现状 Seata 开源 4 年来，主项目在 GitHub 累计收获 star 超 24k，累计发布版本超 40 次，参与代码贡献人数超 300 人。\n Seata 被各领域企业/组织广泛应用于解决分布式事务问题，在 GitHub「Used by」拥有超过 3.1k 的仓库依赖，金融领域企业纷纷试点使用。\n Seata 对于市面上主流的关系数据库、RPC 框架做了广泛的支持，同时被许多第三方社区做了主动和被动集成。\n 项目特性 提供 AT、TCC、Saga 和 XA 事务模式，支持事务模式的混用，以满足不同业务场景的数据一致性需求。\n 提供 Java、Golang 等多语言 SDK 支持。\n 支持了 Apache Dubbo、Spring Cloud Alibaba、gRPC、Motan、SOFARPC、HttpClient 等服务调用框架。\n 提供了 MySQL、MariaDB、Oracle、PostgreSQL、OceanBase、TiDB、SQLServer、PolarDB、Dameng 等关系数据库无侵入 AT 事务模式的支持。\n 支持基于多种关系数据库、Redis 存储的存算分离的集群模式，支持基于 Raft 的存算不分离集群模式，满足不同运维场景下的集群高可用需求。\n 支持了市面上主流的注册中心和配置中心。\n 提供了丰富的插件化扩展机制，支持用户自定义 SDK 侧 30 多个扩展点。\n 致谢 感谢所有曾经参与到社区建设中来的贡献者。\n特别感谢愿意为 Seata 提供指导的 Champion 和 Mentors:\nChampion：\nSheng Wu（wusheng @apache.org）\nMentors：\nSheng Wu(wusheng @apache.org）\nJustin Mclean(justin @classsoftware.com）\nHuxing Zhang(huxing @apache.org）\nHeng Du(duhengforever @apache.org）\n我们坚信，将 Seata 引入 ASF 可以推动开源社区向着更强大、更多元化发展。我们将努力践行 Apache Way，同时欢迎更多的公司和个人加入到开发队伍中来，让 Seata 社区更加健康、茁壮地成长，让更多人享受开源带来的技术红利！\n项目寄语 四年前，我们秉持开源开放的理念，在社区写下了第一行代码。回顾过去四年，Seata 开源社区的技术演进和社区运营就像一次创业旅程。这四年我们取得了不菲的成绩，Seata 的出现快速占领了开发者的心智，成为了分布式事务领域的事实标准，在理论实践中我们牵头推动了行业标准的建立。Seata 捐赠给 ASF 是我们迈向更多元化社区治理和全球化发展的重要里程碑。\n\u0026amp;ndash; 季敏（Seata 开源社区创始人）\n恭喜 Seata 全票通过进入 Apache 孵化器！2019 年，蚂蚁集团和阿里集团携手一起开源了分布式事务框架 Seata，各自贡献了内部分布式事务的最佳实践。经过了四年的发展，Seata 早已成为一个被社区广泛认可的分布式事务项目，大量的贡献者在 Seata 里面贡献代码，丰富了 Seata 的各种功能，很多用户在自己的环境中使用 Seata，给 Seata 带来了大量的实践落地案例。Seata 进入 Apache 孵化器不是终点，而是新的起点，期待 Seata 后面能够持续按照 The Apache Way 的方式运作，以更加中立的姿态，吸引更多的贡献者和用户，走向更加宽阔的未来。\n\u0026amp;ndash; 黄挺（蚂蚁集团中间件负责人）\n非常高兴 Seata 这个阿里和蚂蚁合作多年的开源项目进入 Apache 基金会进行孵化，相信 Apache Way 会帮助项目更加社区化、服务更多人，也期待 Apache 的 Seata 能为社区带来更多微小而美好的改变。对于蚂蚁开源来说，Seata 进入 Apache 孵化也是一个重要的里程碑，希望未来有更多蚂蚁团队发起的项目能走上 Apache 之路。\n\u0026amp;ndash; 王旭（蚂蚁开源技术委员会副主席）\n分布式事务是微服务架构最复杂，技术水位最深的部分。阿里\u0026amp;amp;蚂蚁在开源捐献之前申请了数十个专利，开源之后在社区推动下高速发展，吸收 70%+外部开发者，大幅降低分布式的复杂度，扩展了分布式事务的生态；未来随着微服务高速发展，随着数据一致性要求越来越高，相信分布式事务会发挥越来越大的作用！\n\u0026amp;ndash;李艳林（阿里云微服务团队负责人）\nSeata 是一款由阿里巴巴和蚂蚁集团共同参与开发的分布式事务解决方案，广泛应用于两家公司的内部系统。它的突出特点在于高性能和简单易用，为微服务架构下的分布式事务处理提供了高效且可靠的解 …","date":1700118000,"description":"携手开源，共同见证｜Seata 进入 Apache 孵化器","dir":"blog/open-source-together-seata-enters-apache-incubator/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bc69512b849467987dfe2349cb824154","permalink":"https://sofastack.github.io/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","publishdate":"2023-11-16T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","summary":"北京时间 2023 年 10 月 29 日，分布式事务开源项目 Seata 通过 Apache 基金会的投票决议，以全票通过的优秀表现正式成为 Apache 孵化器项目！ 根据 Apache基金会邮件列表显","tags":["SOFAStack"],"title":"携手开源，共同见证｜Seata 进入 Apache 孵化器","type":"blog","url":"/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","wordcount":4740},{"author":null,"categories":"SOFAStack","content":" 文｜王连平（花名：烨川)\n蚂蚁集团容器团队专家\n本文 3441 字 阅读 9 分钟\n技术背景 Kubernetes 是容器编排的标杆平台，其标准化、插件化特性促使其拥有巨大的生态体系。众所周知，Kubernetes 是由其众多管控组件共同驱动容器交付的，但这种特性可会给开发人员和 SRE 在开发和运维过程中带来更高复杂性。\n当容器在交付过程出现错误，通常会使用 Kubectl 命令行工具查看 Pod 相关的事件，进而查看相关组件的日志定位具体的错误。这种方式存在效率低、信息少的缺点，导致问题排查耗时耗力。另外，容器在交付过程中会经历诸多阶段，比如调度、IP 分配、挂卷、容器创建和启动等，当此过程变得很慢时，需要精准定位到哪里是瓶颈点，最直接的方法是在所有管控组件做埋点，然后逐阶段分析问题。这种埋点方式带来了巨大的工作量，不易推进实施。\n针对这些问题，蚂蚁集团围绕 Kubernetes 平台构建了一套综合的容器观测服务——Lunettes。它利用 Kubernetes 多维度的交付信息（例如 API Server 请求、Audit 审计）构建了一套容器交付全生命周期观测服务，可以跟踪和诊断容器交付过程，并且基于诊断能力提供容器交付 SLI/SLO 服务，实现了数字化方式监控和管理 Kubernetes 容器服务。\n整体方案 在 Kubernetes 系统中，大量的管控组件在容器交付的过程中分工协作，为交付出来一个正常运行的容器不断的重试调和，过程中会产出大量的中间请求动作、日志等信息，Kubernetes 系统这种异步终态特性是容器交付可观测服务的一个关键挑战。那么在此类系统中观测容器交付过程，应该具备哪些特性呢？\n我们希望 Lunettes 应该具备：\n 提供多维度的容器交付信息，并且能优雅处理面向终态的机制\n 提供便捷的组件接入方式，尽可能小的侵入组件代码\n 提供较灵活的定制化或者配置方式\n 给用户提供简单易用的交互接口\n Lunettes 基于上述特性的考虑，整体采用旁路数据采集、数据分析和数据服务思路，围绕 Kubernetes 的审计日志做容器交付相关业务的分析，包括 Pod 基本信息、Pod 交付关键生命周期、Pod 交付诊断、Pod 交付跟踪和 Pod 交付 SLO 共 5 部分的交付数据。在数据分析链路上抽象出多个通用的模型，让用户灵活定制容器交付 Trace 及 SLO 诊断能力。同时，向上提供了 OpenAPI 和 Grafana UI 两种用户交互接口，便于用户信息消费。\n系统架构 上图示意了 Lunettes 系统的系统架构和数据链路，除了 Kubernetes API Server 审计数据源、数据采集和数据存储组件外，Lunettes 整体包括用户接口层和数据处理层两部分，其中数据处理层是 Lunettes 的核心业务逻辑所在。其处理流程如下：\n 从数据流向看，Filebeat 从 Kubernetes API Server 采集审计日志后，存储到 Elastic Search 中，在审计采集过程中使用 Filebeat Processor 进行冗余信息过滤，在数据存储 Elastic Search 时使用 Pipeline 增加必要时间序列，如此使得存储到 ES 中的数据量小而丰富。\n Lunettes 会近实时从 ES 拉取审计数据，审计进入 Lunettes 后首先会被 Share Processor 处理，这里处理主要分为 Pod 元数据信息提取、超事件（HyperEvent）抽象、以及并发反序列化审计请求中的 Raw Data，前置反序列化是为了减少后续 SLO、Trace 等业务处理时重复处理，提升性能。\n 数据经过 Share Processor之后，进入核心的交付分析模块，核心包括交付生命周期 Trace、交付 SLO 分析、交付原因分析及容器基础信息搜集，数据在模块之前按照需求做依赖 DAG，最终将产出 OTel、ES Table、Metrics 三种数据写入相关的数据服务。\n 存储到 ES、jaeger 和 prometheus 的数据，会被 Lunettes Rest API 和 Grafana di 处理，转换为 OpenAPI 数据接口和 Grafana Portal 上的数据进行展示。Grafana Portal 中一站式集成了 Lunettes 所有的功能，用户使用更便捷。\n Lunettes 核心能力 交付 SLO 交付 SLO 目的是基于 Kubernetes 交付链路能力对用户承诺交付保障。那么“交付 SLO”是什么呢？可以概括为：在一定时间内保障用户的容器可以成功交付。这个时间就是给用户的承诺，自然地 SLO 时间如何来定是非常关键的。Lunettes 主要从 Pod Spec 中获取资源规格、资源亲和配置等属性，计算出 Pod 的 SLO 时间。另外，Lunettes 也会根据 Pod 选择的不同交付链路（可以简单的理解为高速交付链路和普通低速链路）来给出保障时间。\n有了 SLO 超时计算标准，另一个挑战是如何计算 SLO 时间。如前文所述，容器交付链路中包含了多个阶段，Lunettes 将其区分为 Kubernetes 平台自身耗时和用户耗时两大类，通过 overlay 时间轴，去除用户时间后作为整体 SLO 时间保障。如此，对外承诺的 SLO 时间不会因为用户错误行为（配置、代码 bug 等）导致承诺失败。\n交付诊断 交付过程中出错是必然的，从庞大的 Kubernetes 系统快速定位容器交付过程中的问题是用户非常关心的。Lunettes 另一个重要的能力是从大量的容器交付行为信息中分析出容器交付的错误原因，用户通过 Portal 或者 OpenAPI 可以轻松获取容器交付的结果，如下图所示，Lunettes 在诊断结果中积累沉淀了 30 余种错误类型，帮用户快速定位问题。\n诊断过程中，Lunettes 采用回放审计日志技术，通过模拟容器交付过程抽象定义出原因分析 DAG 框架。审计日志回放输入 DAG 诊断框架后，各模块将分析自己阶段的交付是否完成，如果出错则抛出异常。最终，经过回放分析给出 Pod 出错位置，当然各分析模块是面向终态的分析过程。DAG 的框架既保证了分析过程行为的正确性，也提升了诊断流程的可扩展性。\n交付 Trace 交付 Trace 核心目的是跟踪每个 Pod 的交付过程，记录 Pod 交付过程中各阶段的耗时，以及对出错的阶段进行日志记录。一般地，在微服务系统中面向请求的 Trace 都是打桩，正如前文所述 Kubernetes 这种终态异步系统中，打桩每个管控组件是非常大的一个工程量，而且在组件之间异步分布式传递 Trace Context 很有挑战性。Lunettes 另辟蹊径，基于审计日志，抽象出 HyperEvent 概念，其包含了 Pod 交付过程中发生在 Pod 身上所有的 Verb 和 Event 两类信息，比如 Patch 一个 Condition 表示某个交付阶段完成，透出一个 Event 表示某个阶段结束。这两种信息被进一步用于定义交付 Trace 过程中每个阶段的开始和 …","date":1699945200,"description":"告别复杂性！用正确的工具轻松应对 K8s 管理挑战","dir":"blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"55bbf8c8afe1ee0fec5d19b4e8176065","permalink":"https://sofastack.github.io/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","publishdate":"2023-11-14T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","summary":"文｜王连平（花名：烨川) 蚂蚁集团容器团队专家 本文 3441 字 阅读 9 分钟 技术背景 Kubernetes 是容器编排的标杆平台，其标准化、插件化特性促使其拥有巨大的生态体系。","tags":["SOFAStack"],"title":"告别复杂性！用正确的工具轻松应对 K8s 管理挑战","type":"blog","url":"/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","wordcount":2785},{"author":null,"categories":"SOFAStack","content":" 今天，我们邀请到了开源之夏 2023 活动 Dragonfly 社区的中选学生李从旺同学，他此次承担的项目是——「PyTorch Serve 基于 Dragonfly P2P 技术分发模型」。希望通过他的开源故事，能让更多人了解到开源的魅力，也可以从不同的视角去认识 Dragonfly 项目。\n关于 Dragonfly Dragonfly 提供高效、稳定、安全的基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为孵化级别的托管项目。Dragonfly 在解决大规模文件分发场景下有着无可比拟的优势。P2P 技术在 AI 推理服务分发大模型场景现阶段应用较少，并且 P2P 技术经过证实也可以真正解决大文件分发过程中的性能瓶颈。在 AI 推理服务分发大模型场景，通过集成 Dragonfly P2P 技术减少源站压力，并且提高模型分发效率。结合 AI 推理领域生态拓展 Dragonfly 应用场景，服务 AI 领域并且成为重要基础设施。\n项目信息 项目名称：PyTorch Serve 基于 Dragonfly P2P 技术分发模型\n项目导师：戚文博\n项目描述：本项目是在 PyTorch Serve 分发过程中解决推理模型拉取时，可能会存在性能带宽瓶颈的问题，所以本项目需要 Dragonfly 通过 P2P 能力提高 PyTorch Serve 模型拉取速度，主要供过 Plugin 方式将 Dragonfly P2P 能力集成到 PyTorch Serve 中。\n项目链接：https://github.com/dragonflyoss/dragonfly-endpoint\n项目实现思路 无论你是需要安装或是升级，对 Dragonfly 各个组件的理解很重要，这是后期顺利进行性能测试的一个前提。\n Manager: 维护各 P2P 集群之间的关系，动态配置管理和 RBAC。它还包括一个前端控制台，方便用户直观地操作集群。 Scheduler: 为下载对等体选择最优的下载父对等体。异常控制 Dfdaemon 的返回源。 Seed Peer：Dfdaemon 开启的种子节点模式，可以作为 P2P 集群中的背向源下载节点，它是整个集群中下载的根节点。 Peer: 与 Dfdaemon 一起部署，基于 C/S 架构，提供 dfget 命令下载工具，dfget 守护进程运行守护进程提供任务下载功能。 架构 TorchServe 通过集成 Dragonfly Endpoint 插件，发送模型下载请求到 Dragonfly ，Dragonfly 作为代理去对应的 Object Storage 下载模型并返回。\n模型下载步骤：\n1、TorchServe 发起模型下载请求到 Dragonfly Peer。 2、Dragonfly Peer 会到 Dragonfly Scheduler 注册任务。 3、返回拥有资源的候选的父节点。 - Scheduler 服务发现本地 Cache 对这个任务是缓存未命中状态，就触发从 Seed Peer 进行文件下载。 - Seed Peer 如果对于任务也是缓存未命中状态，就会触发回源下载，即到对应的对象存储下载模型文件。 4、到对应的候选的父节点进行分片下载文件。 5、模型下载返回后，TorchServe 会进行模型注册。\n在性能测试的步骤中，会对模型下载的几种情况分别进行测试，而结果显示下载性能在命中缓存的情况下确实有极大的提升。\n开源之夏个人随访 自我介绍 大家好，我叫李从旺，是佐治亚理工学院电子与计算机工程专业研二的学生。去年就曾参加过开源之夏的活动，当时的任务是为 Apache APISIX 网关做插件。\n参加活动的原因 我之前参与过开源之夏，发现这个活动非常适合学生去了解以及深入参与到开源社区。众多的开源项目与技术发现可以让我们了解到行业中的最新动态，比如去年的云原生和今年的 AI 基础设施、大模型等。\n同时这种实践搭配的任务难度，在导师与社区的热心帮助之下，无论是为了磨练技术、建立社区连接，还是作为新手开源入门的起点都非常合适。对我来说，第二次参与活动的主要目的是了解并学习新技术。\n申请本社区项目的原因 主要是我对 Dragonfly 的 P2P 技术很感兴趣，并且它也符合我的技术栈。我提前了解过 Dragonfly 在业界的使用情况与热度，得知它作为实用的基础设施广泛被各个公司使用，且仍然在迭代新功能，于是便有了申请的想法。其次就是我对于插件的编写比较有经验，上手本次的项目会更加顺利。\n如何克服项目过程中的困难与挑战？ 主要的困难在于，之前我没想到 TorchServe 官方对于前端的插件支持较少，因此在调研初期，花费了较多时间去了解 TorchServe 的架构细节与插件的实现机制等。在插件的设计方案上也踩了不少坑：比如起初只考虑增加模型加速下载的部分，而官方 API 模型的下载与注册却是同时进行的；同时官方的代码设计中许多内部方法是不对外开放的，这样一来插件编写的方案也会有限制。这一问题的克服方法主要是反复查看官方代码、文档以及和导师沟通，不合理的方案不断地被导师淘汰，最终我找到了代码侵入最小的实现方式。\n还有开源项目从零开始搭建的困难，包括目录设计、工作流的设计、测试用例、文档编写（需要不断打磨）等工作。这些非 coding 的部分往往会占据更多的时间。我的建议是——积极参考社区优秀活跃的开源项目和直接询问导师，这样效率会比用搜索引擎快得多。因为很多规范是会随时间变化的，新项目当然要符合最新的规范。\n困难还出现在测试环节！整个插件的使用涉及到不同的对象存储、Dragonfly 以及 TorchServe 等多个组件；多种环境的部署以及不同的配置细节也需要付出额外的关注。当然，最大的挑战是由我硬件资源不足的电脑带来的，解决的办法主要是详细地记录步骤以及利用一些云计算资源，这对后期使用文档的撰写也非常有帮助。\n导师与社区带来的帮助 在整个开发的过程中，包括前期调研环节，导师给予我的帮助是巨大的。耐心、细心、负责是 Dragonfly 社区以及我的导师给我的最大感受了。他们不仅在技术上给出指导，在文档编写乃至后期的技术交流方面也都非常用心。开发周期内的每周例会和平时的信息反馈也都非常及时，我作为学生，体验也非常好。\n你眼中的 Dragonfly 社区印象 Dragonfly 致力于提供高效、稳定、安全的基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。目前社区还在不断壮大发展中，欢迎大家一起来参与开源共建。\n超出预期的收获 在调研中，我学习到了 Dragonfly P2P 的实现原理以及 TorchServe 各个模块的实现方案。在每周例会中，也有许多来自其他社区的同学或嘉宾， …","date":1699340400,"description":"开源之夏经验分享｜Dragonfly 社区 李从旺：社区贡献也是一种影响力","dir":"blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f093077c7b660418d01cdd971f144de1","permalink":"https://sofastack.github.io/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","publishdate":"2023-11-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","summary":"今天，我们邀请到了开源之夏 2023 活动 Dragonfly 社区的中选学生李从旺同学，他此次承担的项目是——「PyTorch Serve 基于 Dragonfly P2P 技术分发模型」。希望通过他的开源","tags":["SOFAStack"],"title":"开源之夏经验分享｜Dragonfly 社区 李从旺：社区贡献也是一种影响力","type":"blog","url":"/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","wordcount":2622},{"author":null,"categories":"SOFAStack","content":" 文｜谭崇康（*花名：见云*）\n蚂蚁集团高级技术专家\n本文 3781 字 阅读 10 分钟\n问题：K8s 服务运营需要更好的可观测能力 云原生系统以 Kubernetes*（K8s）*为基石，业界很多公司的基础设施也构建在 K8s 平台之上。作为公司的关键基础设施，K8s 平台的运营效率直接影响业务的稳定与效率。\n然而，将 K8s 作为服务运营与单纯的使用 K8s 存在很大的区别。在使用 K8s 时，我们关注是形形色色的功能，而在 K8s 服务运营过程中我们将更加聚焦 K8s 服务的质量以及效率。运营一个 K8s 服务需要关注的典型问题例如：\n 问题诊断及其效率：K8s 链路长、组件多、概念丰富、状态复杂等，如何快速诊断日常失败问题原因是一个很关键的能力； 服务质量衡量问题：如何衡量 K8s 平台服务整体资源交付效率以及调度、镜像拉取、IP 分配等各个环节的服务质量，进而引导服务能力的提升； 链路性能问题：如何发现、定位集群中的性能瓶颈，提升集群的资源交付吞吐； 运营体系化问题：当前社区的可观测服务更多关注的还是某些孤立的功能点，服务运营需要的是数字化、性能、效率、体系化等。 Lunettes：K8s 平台运营可观测工作空间 K8s 集群构成的容器服务平台，并努力提升平台服务的质量。在这个过程中，我们沉淀了很多运营工具以及相关的运营经验。基于这些工具及经验，我们构建了容器可观测服务 Lunettes，希望帮助大家更简单地运营 Kuberntes 服务。Lunettes 项目代码已经在 GitHub 平台开放，欢迎大家参与！\n项目链接：https://github.com/alipay/container-observability-service\nLunettes 服务提供的一些特性，包括：\n 定义了 K8s 资源交付效率的 SLO，并基于 SLO 产出了成功率相关的可观测数据，用户基于 SLO 衡量 K8s 整体及子服务的质量，同时发现服务能力受损等问题； 提供了容器一键诊断能力，Lunettes 分析 K8s 资源交付过程的各个阶段，产出当前运维过程中的问题，帮助用户快速定位及解决问题； 建设了一套无侵入的资源交付 Trace 能力，基于 Lunettes 分析的 HyperEvent 事件，用户可以看到资源交付链路中各个子阶段的耗时及错误，及时发现性能瓶颈点。 其他的一些易用特性包括：\n 统一的操作界面，支持多集群管理，一站式服务体验； 多维信息的聚合能力，提供日志、监控、Trace 等多维数据融合的能力。 Lunettes 是一个一站式的 K8s 容器可观测服务，能够为原生的 K8s 集群构建一个为服务运营打造的可观测工作空间，大幅降低了 K8s 服务运营的难度：\n 基于可扩展的多维可观测数据构建：Lunettes 将不同维度的可观测数据抽象为 HyperEvent，并在 HyperEvent 之上构建其他服务能力。我们可以方便地通过配置化封装能力将新的可观测数据维度封装成 HyperEvent 从而扩展 Lunettes 的数据聚合能力。 面向原生 K8s 集群，一键拉起：Lunettes 各个核心功能都具备灵活的配置能力，并且默认配置为原生 K8s 版本设计。Lunettes 可以采用普通 YAML 或 helm charts 部署，用户可以方便地在 K8s 集群一键拉起 Lunettes 服务。 构建 K8s 运营的完整的可观测工作空间*（workspace）*：Lunettes 提供了包含资源交付 SLO、容器生命周期诊断、容器生命周期 Trace、多维数据融合等常用的功能，为 K8s 集群提供一站式运营工作空间。 软件架构 Lunettes 服务的软件架构分为四层，分别为：\n 用户接口层 *（User-Portal）*：图形化交互基于 Grafana 构建，此外我们也提供 OpenAPI 接口； 可观测服务层 *（Observability-Services）*：包含阶段耗时分析、资源交付 SLO、资源交付诊断、资源交付 Trace 等多个可观测特性； 数据处理层 *（Data- Processing）*：Lunettes 具有可观测数据源扩展能力，支持 Operations、Events 等多种可观测数据，并将可观测数据统一封装为 HyperEvent，经由上层的 SharedProcessor 统一处理。在 Lunettes 中，可观测数据的处理是高度可配置化的，ConfigCenter 负责配置的管理。 存储层 *（Storage）*：Lunettes 的存储层支持多种存储服务，包含 Prometheus、ElasticSearch、SLS 等。 基础功能介绍 资源交付 SLO K8s 的核心功能是将资源以容器的形式交付出去。如何定义容器平台的资源交付质量是一个核心的话题。Lunettes 首先根据可观测数据定义容器生命周期中的各个阶段，区分基础设施阶段以及用户应用阶段，从而统计容器平台容器交付所花费的时间。进一步，Lunettes 根据容器交付的时间定义资源交付 SLO。下图中展示了集群的 1 分钟级以及 1 小时级 Pod 创建成功率的 SLO 数据。\n容器生命周期诊断 Lunettes 将诊断 Pod 创建流程中各个阶段的错误，形成典型容器创建错误码，例如 FailedScheduling 对应调度失败、FailedPullImage 对应镜像拉取失败等。典型的错误码将具备以下功能：\n 错误信息形成一个标准的错误集合，每个错误类型以可理解的方式代表特定的一类错误，给用户提供当前交付失败的诊断结果； 形成标准的 ErrorCode，作为上下游问题传递的依据，构建端到端的诊断链路； 当集群故障时，诊断结果作为聚合信息，当大量错误聚合时，方便我们快速定位到集群中的错误组件及错误原因。 在诊断过程中，Lunettes 将从底层的可观测数据中抽取生命周期中的关键事件，涵盖了 Operation、Events 等，帮助用户根据关键事件快速定位容器生命周期中的各种问题。\n资源交付 Trace Lunettes 设计了一套无侵入的资源交付*（创建、删除等）*过程 Trace 体系，基于 Lunettes 分析的 HyperEvent 事件，以用户可理解的方式分析资源交付过程中的各个阶段，例如 IP 分配、镜像拉取、Volume 绑定等，并基于这些分析构建了资源交付 Trace。通过资源交付 Trace，用户可以方便地找到资源交付过程中各个阶段的耗时及错误，从而掌握整个资源交付过程中的热点问题。Trace 与 Log、Event 等关联，帮助用户快速找到问题的根因。\n多维信息聚合能力 基于我们在过去多年积累的 K8s 运营经验，Lunettes 为日常运营活动中的多个典型场景设计，聚合了 YAML 信息、Event 信息、审计信息、Trace 信息、SLO 信息等多维度的可观测信息，为用户提供一个完整的 K8s 运营可观测工作空间。\n实践：几个典型的使用场景 Case1：诊断 Pod 创建失败 以镜像拉取失败为例，我们来看一下在 Lunettes 中， …","date":1698735600,"description":"Lunettes - 让 Kubernetes 服务运营更简单","dir":"blog/lunettes-makes-kubernetes-service-operations-easier/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"edc4c98af54696e29b070cc6ce02dea6","permalink":"https://sofastack.github.io/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","publishdate":"2023-10-31T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","summary":"文｜谭崇康（*花名：见云*） 蚂蚁集团高级技术专家 本文 3781 字 阅读 10 分钟 问题：K8s 服务运营需要更好的可观测能力 云原生系统以 Kubernetes*","tags":["SOFAStack"],"title":"Lunettes - 让 Kubernetes 服务运营更简单","type":"blog","url":"/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","wordcount":3487},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack GitHub issue 精选 本周各项目回复 issue 精选 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n1.@MOSN #2347\n@huayangchan\n 我们目前在调研阶段，想用 envoy 做来做流量代理，但是考虑到研发效能，所以想用 MOE 的方案看看。因为涉及到 L4 的流量处理，顺便再确认下，那对于企业内部自定义的 RPC 协议，涉及到四层的流量 filter 操作，基于目前开源版 MOSN 是做不‍到哈？只能基于原生 envoy 的 L4 extension 来做么？\n A：这个我们内部的做法就是 MOSN 的 xprotocol 框架支持多协议，然后再用 L4 MOE 嫁接到 envoy 上。收益还是很可观，没有链接的常驻协程。如果直接用 envoy 的 L4 的话，你其实还是需要用 Go 搞一套 proxy 框架出来的。你可以先用纯 MOSN 支持你们的 RPC 协议，然后再用 MOE 移植到 envoy 上。\n「MOSN」：https://github.com/mosn/mosn/issues/2347\n2.@SOFABolt #332\n@tongtaodragonfly\n 在我们的环境中，连接事件日志文件中出现警告消息，如下所示：\n未知协议代码：[ProtocolVersion{version=[3]}] 在 ProtocolDecoder 中解码时。] 为什么会报告此警告消息？什么样的情况可能会触发此警告消息？\n A：协议版本是应用层网络帧的第一个字节。通常为 1*（对于 BoltV1）*和 2*（对于 BoltV2 协议）*。如果第一个字节是 3，bolt 找不到对应的协议，所以你会看到这个错误。\n此问题可能有两个常见原因：\n 一些未知的客户端向您的端口发送错误的数据包； 解码器没有消耗掉一个数据包中的所有数据，因此存中留下了一些错误的数据。Decoder 下次消费数据时，读取到了错误的数据。 「SOFARPC」：https://github.com/sofastack/sofa-registry/issues/332\n3.@SOFAArk #741\n@jgslvwy\n 请问下 SOFAArk 子应用支持用 spring-boot-maven-plugin 吗？为什么示例里面子应用还用的 sofa-ark-maven-plugin？\n A：子应用使用 sofa-ark-maven-plugin 构建产物是可以热部署到基座的 Jar 包，你要用 spring-boot-maven-plugin 也是可以，子应用本身也是独立的 Spring Boot，只是不能热部署到基座 JVM 上而已。\n「MOSN」：https://github.com/sofastack/sofa-ark/issues/741\n本周推荐阅读 MoE 系列（六）｜Envoy Go 扩展之并发安全\nSeata Saga 模式快速入门和最佳实践\nGo 语言，如何做逆向类型推导?\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\n","date":1696575600,"description":"SOFA 聊天室、issue 精选","dir":"blog/sofa-weekly-1006/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0dd36b93af4616c470c2dacf6b00830c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-1006/","publishdate":"2023-10-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-1006/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 聊天室、issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-1006/","wordcount":1117},{"author":null,"categories":"SOFAStack","content":" 文｜梁仕威（花名：栖川）\n蚂蚁集团算法专家\n方略平台技术负责人，专注于分布式计算领域，主要负责蚂蚁基础算法的分布式设计与开发。\n本文 3419 字，阅读 9 分钟\n在类似安全风控这种对抗性的场景中，由于欺诈者作案手法的频繁变化，使得训练数据并不总会包含足够的信息给算法自动挖掘出优质的拦截规则，这种场景下高质量拦截规则的挖掘需要结合专家领域知识。如何将算法和专家领域知识相结合成为了业界一个值得探索的课题。蚂蚁集团 AI Infra 团队针对上述问题，构建了一个交互式的规则研发系统——方略，提供了一种在规则研发过程中高效融入专家领域知识的解决方案。\n描述该系统的 Demonstration Paper 《Fanglue: An Interactive System for Decision Rule Crafting》 近期已经被数据库领域的重要会议 International Conference on Very Large Data Bases （VLDB2023） 所接收。VLDB 是中国计算机学会 （CCF） 推荐的 A 类会议，每年都会吸引国内外各大高校和科技公司的投稿。\n1｜背景 决策规则由于其直观可解释的 If-Then 结构，被广泛应用于欺诈预防等金融科技领域至关重要的任务中。标准的决策规则由两部分构成：一系列条件和预测值。 条件是由特征、操作符、值构成的三元组结构，例如 age\u0026amp;lt;50。当规则中的所有条件都被满足时，规则会输出预测值。\n目前大多数现有的规则挖掘系统都是以端到端形式运行的，即给定训练集后，专家设定规则挖掘算法的优化指标和超参数，然后等待算法运行结束就可以获得一组规则。在这种方式下，设置超参数和优化指标是融入专家领域知识的唯一途径，一旦规则挖掘过程开始，专家就没有其他方法能够干预规则的生成。但是在如风控这种对抗性的场景中，由于作案手法的频繁变化，训练数据里并不总会包含足够的信息给算法自动挖掘出优质的规则。在这种情况下，专家必须将领域知识更深入地融合到规则生成过程中才能获得有意义的结果。\n举个例子，假设支付宝的一位风控专家，想要编辑规则来拦截一种新型欺诈行为。由于该欺诈行为是最近才出现的，他准备的数据集中只有少数关于这种欺诈行为的黑样本。假设这种欺诈行为的一个关键步骤是要求受害者向欺诈者发送多个付款码，因此短时间内付款码刷新的次数是识别这种欺诈活动的重要特征。然而风控专家发现挖掘算法返回的规则中没有使用该特征，大多数规则都使用了交易金额来区分欺诈行为和正常行为，因为数据集中的交易金额巧合地将这两种行为区分开了。但是随着新型欺诈行为的普及，交易金额就不能继续作为识别这种欺诈行为的有力依据了。这种现象在反欺诈场景中并不罕见，当黑样本太少时，无关的特征也能够区分出输入数据中的黑白样本。虽然付款码刷新频次确实是规则挖掘过程中一个非常有竞争力的特征 （例如评估指标排名靠前） ，但由于数据中噪声的影响，使得其不能排到最前面，从而不能被算法挖掘出来。这种情况下，将专家领域知识融入进来，让付款码刷新频次这个特征应用到拦截规则中，对阻止新型欺诈行为扩散尤为重要。\n为了能在规则研发过程中高效融入专家领域知识，蚂蚁集团 AI Infra 团队构建了一个交互式的规则研发系统——方略。方略为用户提供了一个 Web 界面来可视化地制定决策规则。用户将数据上传到方略后就可以开始规则研发流程，方略会实时地推荐出规则的候选条件与对应评估指标，并生成数据分析结果，为用户提供有用的定量分析信息。同时方略使用 Ray 作为计算引擎并将数据分布式存储在内存中，以满足在交互式处理大规模数据时的实时响应需求。\n2｜系统架构 （图 1）\n图 1 展示了方略的系统架构。用户通过 Web 界面与方略进行交互。方略的界面上有三个核心模块：条件推荐模块、条件编辑模块和规则评估模块。服务端的 Task Manager 负责接收来自三个核心模块的请求①，并且会启动相应的 Ray 作业②。\n用于计算的数据水平切分后预先加载进 Ray 的一组 Actor 内存里。对于一个特定的计算任务，每个 Actor 都会基于分配到的数据计算出局部统计信息，这些局部统计信息会汇集到 Driver 里进一步处理得到全局统计信息③。然后全局统计信息返回给 Task Manager④，并被传递给 Data Processor。Data Processor 在全局统计信息的基础上进一步处理，例如计算出各个候选条件的评估指标，得到的处理结果会在 Web 界面上展示给用户⑤。然后整个系统会等待用户的下一步操作。\n一旦用户作出某些操作 （例如从候选条件中选择一个加入到当前规则中） 触发相应的核心模块，系统就会重复上述过程。用户编辑好的规则会保存到数据库里⑥。\n3｜技术细节 不同于标准规则，方略采用合取范式 （Conjunctive Normal Form） 的规则表示形式，即同时支持“AND”和“OR”条件。合取范式规则是由一个或多个子句和一个预测值组成的合取式 （AND 连接） ，其中子句是条件的析取式 （OR 连接） ，条件的形式为特征、运算符、值。方略专注于二分类问题，使用训练集和验证集上的精确度、召回率、F1 得分或黑样本覆盖率等指标来评估决策规则。\n方略提供三种实时的条件推荐帮助用户构建规则： “AND”条件推荐、 “OR”条件推荐、近似条件推荐。\n假设我们已经有了一些子句构成的决策规则，需要往这个规则中增加一个“AND”或者“OR”条件，方略会搜索所有可能的三元组 （特征、运算符、值） ，并通过将这些候选条件附加到当前规则里计算评估指标。标准的规则学习算法会选择具有最佳指标的候选条件，而方略会在 Web 界面上展示在验证集上取得 top 评估指标的候选条件列表供用户选择。\n为了快速计算所有候选条件的评估指标，方略使用 Ray 作为计算引擎，每个 Actor 计算出局部统计信息，然后聚合到 Driver 里得到全局统计信息。为了验证系统的效率，我们在一个包含 140 万个样本和 50 个特征的数据集上进行了实验。图 2 对比了在生成“AND”候选条件下，方略的实现与基于 Mars on Ray （基于 DataFrame 运算） 实现的耗时。可以看到方略的实现非常高效，使用 16 个 Actor 就可以在 1 秒内返回结果，满足交互式环境下高响应的需要。\n（图 2）\n在安全风控场景下，当规则中存在一些容易被攻击的条件时 （例如拦截规则里有条件：转账金额\u0026amp;gt;=500，欺诈方只需要使得转账金额小于 500 就可以绕过拦截规则） ，风控专家会希望通过寻找“语义上相似”的条件来增加另一层保护。为了加强规则的鲁棒性，方略提出并引入了近似条件。假设当前的规则是 C1 and C2 and C3，覆盖的样本集为 A，我们希望在 C2 上增加近似条件，那么方略会在 C1 and C3 的基础上遍历所有的候选条件 （特征、运算符、值） ，每个候选条件都会覆盖数据的一个子集，记为 B。一个理想的近似条件应该在 A 和 B 之间具有高重叠度，同时又不引入太多额外的白样本。方略基于图 3 所示的公式衡量条件的相似度，其中表示中带有正标签的子集，表示中带有负标 …","date":1696316400,"description":"VLDB2023｜方略：一个交互式的规则研发系统","dir":"blog/vldb2023-fanglue-an-interactive-rule-development-system/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"310a7da278d5e5a913dc0e0d09ac6c02","permalink":"https://sofastack.github.io/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","publishdate":"2023-10-03T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","summary":"文｜梁仕威（花名：栖川） 蚂蚁集团算法专家 方略平台技术负责人，专注于分布式计算领域，主要负责蚂蚁基础算法的分布式设计与开发。 本文 3419 字，阅读 9 分","tags":["SOFAStack"],"title":"VLDB2023｜方略：一个交互式的规则研发系统","type":"blog","url":"/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","wordcount":3237},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议回顾 SOFAServerless：\n主题：SOFAServerless 社区会议 时间：09 月 27 日 19:30 - 20:30\n会议内容：\n 待跟进事项：\n ModuleController corner case 和多场景验证以及功能打磨\n 0.5 版本补充 ModuleController 和 Arklet 新 feature 使用文档\n 开源中间件排摸继续跟进\n 补充 0.5 版本原理文档\n 0.5 版本待合并收尾，开源之夏结项\n 发布内容：\n SOFAServerless 0.5.0 可试用版本已发布，详细可查看👇\n 试用手册 https://sofaserverless.netlify.app/docs/tutorials/base-create/springboot-and-sofaboot\n 试用样例 https://github.com/sofastack-guides/sofa-ark-spring-guides/tree/master/samples/web/tomcat\n 「SOFAServerless」：https://github.com/sofastack/sofa-serverless/issues/117\nSOFAStack 社区本周贡献 本周推荐阅读 蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata Saga 模式快速入门和最佳实践\n大象转身：支付宝资金技术 Serverless 提效总结\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\n","date":1695970800,"description":"SOFAServerless 社区会议回顾、社区本周贡献、SOFA 亚运特辑","dir":"blog/sofa-weekly-20230929/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5b9c3463eb10dee170d71426e96abb86","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230929/","publishdate":"2023-09-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230929/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议回顾、社区本周贡献、SOFA 亚运特辑","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230929/","wordcount":529},{"author":null,"categories":"SOFAStack","content":" 2023 年 9 月 20 日，KCL 项目通过了全球顶级开源基金会云原生计算基金会 （CNCF） 技术监督委员会评定，正式成为 CNCF 沙盒项目。\n这意味着 KCL 得到了云原生开源社区的认可，保障了项目的中立性，有利于开发者、合作伙伴等共同参与项目建设，协作共赢，并为云原生应用交付带来动态配置管理和自动化能力迈出了重要一步！\n 项目地址：https://github.com/kcl-lang/kcl 项目官网：https://kcl-lang.io 通过进入 CNCF 沙盒，KCL 社区将更多吸引更多开发者和用户参与共建，进一步推动项目在云原生业务场景的成熟应用，此外加入 CNCF 将为 KCL 提供一个增强的协作和创新平台。它提供了与处于云原生技术前沿的多元化开发者、组织和行业专家社区进行交流的机会。我们期待与其他 CNCF 项目进行更多合作，贡献我们的技术专业知识，并探索更多 CNCF 项目集成的可能性。\n什么是 CNCF CNCF，全称 Cloud Native Computing Foundation （云原生计算基金会） ，是 Linux 基金会旗下的子基金会。CNCF 致力于为云原生软件构建可持续生态系统，涉及领域包括存储、计算、编排、调度、CI/CD、DevOps、服务治理、服务网关等。\n比如 Kubernetes 便是 CNCF 最具代表性的项目之一。\n什么是 CNCF 沙盒项目 CNCF 社区将项目分为沙盒项目 （Sandbox） 、孵化项目 （Incubating） 、毕业项目 （Graduated） 。著名的毕业项目有：Kubernetes、Prometheus、Istio、ETCD、Containerd、ArgoCD 和 Helm 等。完整的毕业和孵化项目列表查看地址：https://www.cncf.io/projects/\nSandbox 是 CNCF 创建的，旨在为开源项目提供一个有益的、中立的家园，以促进开源项目的合作与开发。入选沙盒的项目，是被 CNCF TOC 认可的，并值得进行实验和开发的潜力项目。\nSandbox 对应的是 CNCF 社区早期项目，列表为：https://www.cncf.io/sandbox-projects/ 。进入 Sandbox 需要 66% 以上的 TOC （技术委员会） 成员赞成，即全部 11 人 https://github.com/cncf/toc#members 中的 8 人投赞成票。\n什么是 KCL KCL 是一个开源的基于约束的记录及函数语言，期望通过成熟的编程语言技术和实践来改进对大量繁杂配置比如云原生 Kubernetes 配置场景的编写，致力于围绕配置的模块化、扩展性和稳定性，打造更简单的逻辑编写体验，构建更简单的自动化和生态集成路径。\n项目主要里程碑如下：\n 2022 年 5 月，KCL 正式开源； 2023 年 6 月，KCL 正式成为 CNCF Landscape 项目； 2023 年 9 月，KCL 由 CNCF 应用交付 TAG 进行审核并通过 TOC 投票，顺利成为 CNCF Sandbox 项目 - https://github.com/cncf/sandbox/issues/48 为什么需要 KCL 正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在云原生配置和自动化的特定问题域内，我们使用专用配置和策略语言用于编写和管理规模化复杂配置及策略。不同于混合编写范式、混合工程能力的高级通用语言，专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将复杂配置和策略编写思路和方式沉淀到语言特性中。\n此外，KCL 期望通过更现代化的声明式配置语言和工具，在轻量级客户端云原生动态配置领域填补配置语言及工具的空白并解决如下问题：\n 维度爆炸: 大多数静态配置如云原生领域的 Kubernetes YAML 配置需要为每个环境单独进行配置；在最糟糕的情况下，它可能引入涉及环境交叉链接的难以调试的错误，稳定性和扩展性都较差。 配置漂移: 对于不同环境的静态管理应用程序和基础设施配置的方式，往往没有标准的方式去管理这些动态的不同环境的配置，采用非标准化的方法比如脚本和胶水代码的拼盘，会导致复杂度呈指数增长，并导致配置漂移。 认知负担: Kubernetes 等作为构建平台的平台技术手段在底层统一基础架构细节方面出色，但是缺乏更上层的应用软件交付抽象，对于普通开发者认知负担较高，影响了更上层应用开发者的软件交付体验。 针对如上问题，KCL 期望提供如下能力:\n 通过代码抽象等手段屏蔽基础设施和平台的细节和复杂性，降低研发者认知负担； 编辑和校验已有的存量配置或模版，直接解决云原生小配置场景问题如 Helm Chart 配置硬编码问题，但远不止如此； 通过配置语言无副作用地管理跨团队的大规模配置数据，提升团队协作效率。 具体来说，KCL 可以：\n 在代码层面提升配置语义验证的能力，比如 Schema 定义、字段可选/必选、类型、范围等配置检查校验能力； 提供配置分块编写、组合和抽象的能力，比如结构定义、结构继承、约束定义和配置策略合并等能力； 用现代编程语言的方式以编写代码的方式提升配置的灵活度，比如条件语句、循环、函数、包管理等特性提升配置重用的能力； 提供完备的工具链支持，丰富的 IDE 插件、语言和生态工具链支持用以降低上手门槛，提升使用体验； 通过包管理工具和 OCI Registry 使得配置以更简单的方式在不同团队/角色之间分享，传播和交付； 提供高性能的编译器满足规模化配置场景诉求，比如满足由一份基线配置根据部署上下文生成不同环境不同拓扑的配置的渲染性能以及配置自动化修改性能诉求； 通过多语言 SDK，KCL 语言插件等手段提升其自动化集成能力，在发挥配置及策略编写价值的同时显著降低 KCL 的学习成本。 除了语言自身，KCL 还提供了许多额外的工具如格式化，测试、文档等工具帮助您使用、理解和检查编写的配置或策略；通过 VS Code 等 IDE 插件，包管理工具和 Playground 降低配置编写和分享的成本；通过 Rust、Go 和 Python 多语言 SDK 自动化地管理和执行配置。\nKCL 能做什么 动态配置管理 作为一种配置语言，KCL 为应用程序和平台开发人员/SRE 提供的最重要的功能是动态配置管理。通过代码抽象，我们可以构建以应用为中心的模型屏蔽复杂的基础设施和平台概念，为开发人员提供一个以应用程序为中心且易于理解的界面。此外，KCL 还允许平台人员快速扩展和定义自己的模型，并且这些模型可以通过 OCI 注册表进行分享和复用。\n此外，KCL 还支持与 Kubernetes Resource Model (KRM) 规范直接集成，KRM KCL 是一个通用的配置模型规范，用于描述和管理各种云原生资源，如容器、Pod、服务的配置操作和抽象等。KRM KCL 规范提供了一种统一的方式来定义和管理这些资源，使得它们可以在不同的环境中进行移植和复用。它建立在一个完全开放的 Kubernetes 世界当中，几乎不与任何编排/引擎工具 …","date":1695711600,"description":"喜报！CNCF 基金会宣布 KCL 成为沙盒项目！","dir":"blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1b28ec99e654374176191b2a95853377","permalink":"https://sofastack.github.io/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","publishdate":"2023-09-26T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","summary":"2023 年 9 月 20 日，KCL 项目通过了全球顶级开源基金会云原生计算基金会 （CNCF） 技术监督委员会评定，正式成为 CNCF 沙盒项目。 这意味着 KCL 得到了云原生开","tags":["SOFAStack"],"title":"喜报！CNCF 基金会宣布 KCL 成为沙盒项目！","type":"blog","url":"/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","wordcount":4030},{"author":null,"categories":"SOFAStack","content":" 文｜唐荦彦\n深信服高级开发工程师，主要负责 SASE 云化架构以及基础设施建设\n本文 3056 字，阅读 6 分钟\n1｜你将在本文学到什么 多 K8s 集群镜像分发方案 Dragonfly 的理解 Harbor 的预热机制 Dragonfly 的使用以及排障 2｜K8S 多集群镜像分发问题 在边缘云架构的生产环境下，演进过程中，一开始的镜像分发方案如下：\n每个边缘集群都存在节点的 Harbor 仓库，进行缓存操作，当边缘集群集体崩溃重启过程中，不会引发所有 worker 上中心仓拉取镜像。\n带来的问题是：\n 每套环境一个 Harbor，导致部署、维护的困难。 Harbor 的复制策略比较简单，无法单例执行。并且重试非常占用中心仓带宽。 那么面对这种场景存在以下两种方案：\n Harbor 仓库分级复制策略 P2P 镜像分发策略 Harbor 仓库分级复制策略，存在以下问题：\n 如何进行分级划分 升级过程，如果节点所处的是第三级，如何触发复制策略加速缓存 每个节点增加了安全暴露面 节点的不断增加，后续是否需要 3 级、4 级、5 级，维护管理成本指数增加。 所以在项目中，我的选择是 Dragonfly 的 P2P 镜像分发策略。\n3｜Dragonfly 是什么 在理解过程中，首先需要搞懂以下几个问题：\n P2P 是什么？\n 镜像的分层拉取策略。\n 什么是 P2P 此 P2P 不是金融圈里面经常爆雷的，而是 Peer to Peer 网络技术。有几个比较突出的使用：\n 迅雷； 某夭折的播放器（*快 B*）； 国内一些视频网站白嫖用户网络的 P2P CDN。 为什么需要 P2P 网络 P2P 网络对应的就是传统网络传输 C/S 模式。传统模式下，所有的客户端请求数据下载都需要访问服务器，那么服务器的压力会非常大，当客户端多的情况下，网络带宽也存在问题。\n以下来自 WIKI 百科：\n对等式网络（*英语：peer-to-peer，简称 P2P*），又称点对点技术，是去中心化、依靠用户群（*peers*）交换信息的互联网体系。它的作用在于，减低以往网路传输中的节点，以降低资料遗失的风险。与有中心服务器的中央网络系统不同，对等网络的每个用户端既是一个节点，也有服务器的功能，任何一个节点无法直接找到其他节点，必须依靠其户群进行信息交流。\n镜像分层拉取 Docker 镜像通过分层进行资源共享，通过 copy-on-write 完成文件隔离。在执行 Pull 的时候，可以看到：\nc1c792ed5250: Already exists fcac137f6aa5: Already exists c31aa26549dd: Already exists 04699d7e44fb: Pull complete 可以分析得出，在 Docker pull 时，先会判断本地是否存在当前层，如果没有则从远端服务器拉取层。\nDragonfly 架构** 组件包括：\nManager: 多 Dragonfly 调度节点进行管理，提供了 UI 管理界面、镜像预热机制。\nScheduler:\n 基于机器学习的多场景自适应智能 P2P 节点调度，为当前下载节点选择最优父节点； 构建 P2P 下载网络的有向无环图； 根据不同特征值评估节点下载能力, 剔除异常节点； 当下载失败情况，主动通知 Dfdaemon 进行回源下载。 Dfdaemon： （*分为 Peer、Seed Peer*）\n 基于 gRPC 提供下载功能, 并提供多源适配能力； 开启 Seed Peer 模式可以作为 P2P 集群中回源下载节点, 也就是整个集群中下载的根节点； 为镜像仓库或者其他 HTTP 下载任务提供代理服务； 下载任务基于 HTTP 或 HTTPS 或其他自定义协议。 使用场景流程说明如下：（*当需要下载某一层镜像时*）\n Docker 在请求下载镜像时，通过配置 Docker http proxy 代理，将请求转发到 Peer 节点。\n Peer 节点进行本地缓存判断，查看是否存在该层镜像；\n 是，则直接响应。如图： 如果当前 Peer 不存在，将当前请求转发到 Scheduler；\n Scheduler 将判断 Seed Peer 中是否存在：\n 是，则将对应的地址返回，通知 Peer 去指定的 Seed Peer 拉取资源,如图： 否，则通知 Seed Peer 回源拉取，拉取成功后，Peer 再进行拉取。 最长路径：Docker -\u0026amp;gt; Peer -\u0026amp;gt; Seed Peer -\u0026amp;gt; 源站 -\u0026amp;gt; Seed Peer -\u0026amp;gt; Peer -\u0026amp;gt; Docker。\nDragonfly 操作实践（*Docker 版*） 由于 K8s 版本过于简单，封装了 Docker 手动操作部分，这里讲源码版本如何使用。\n源码安装\n从上面已经了解到：Docker pull 通过 http proxy 配置即可通过 Peer 拉取镜像，那么操作就简单了。\n步骤如下：\n 配置 Docker；\n 安装依赖组件：MySQL、Redis、Jaeger（*为了研究操作路径以及代码*）;\n 配置 Manager、Scheduler、Seed Peer、Peer；\n 详细步骤如下：\na.配置 Docker 配置 http proxy  vi /etc/systemd/system/docker.service.d/http-proxy.conf [Service] Environment=\u0026amp;quot;HTTP_PROXY=http://127.0.0.1:65001\u0026amp;quot; Environment=\u0026amp;quot;HTTPS_PROXY=http://127.0.0.1:65001\u0026amp;quot; 私有仓库的话，配置忽略证书 insecure-registries； vi /etc/docker/daemon.json { \u0026amp;quot;insecure-registries\u0026amp;quot;: [\u0026amp;quot;your.private.registry\u0026amp;quot;] } 重启 Docker：systemctl restart docker。\nb.安装依赖 MySQL: docker run -d --name dragonfly-mysql --restart=always -p 3306:3306 \\ --env MARIADB_USER=\u0026amp;quot;dragonfly\u0026amp;quot; \\ --env MARIADB_PASSWORD=\u0026amp;quot;dragonfly\u0026amp;quot; \\ --env MARIADB_DATABASE=\u0026amp;quot;manager\u0026amp;quot; \\ --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=\u0026amp;quot;yes\u0026amp;quot; \\ mariadb:10.6 Redis：\ndocker run -d --name dragonfly-redis --restart=always -p 6379:6379 \\ redis:6-alpine \\ --requirepass …","date":1695106800,"description":"Docker 环境基于 Dragonfly 的 Kubernetes 多集群镜像分发实践","dir":"blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a9c41894dec9bab10278add3e654f859","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","publishdate":"2023-09-19T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","summary":"文｜唐荦彦 深信服高级开发工程师，主要负责 SASE 云化架构以及基础设施建设 本文 3056 字，阅读 6 分钟 1｜你将在本文学到什么 多 K8s 集群镜像分发方案 Dragonfly 的理解 Harbor 的","tags":["SOFAStack"],"title":"Docker 环境基于 Dragonfly 的 Kubernetes 多集群镜像分发实践","type":"blog","url":"/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","wordcount":2798},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题： Layotto 社区会议\n时间： 09 月 20 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入： +02162681677（中国大陆）+057128095818（中国大陆）\n入会链接： https://meeting.dingtalk.com/j/r3Nq5pEd730\n议题：\n Layotto 项目规划和展望 #976 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910 2023 CSDI SUMMIT #987\n add uds support for Java SDK\n 「Layotto」：https://github.com/mosn/layotto/issues/989\nSOAFServerless：\n主题： SOFAServerless 社区会议\n时间： 09 月 19 日 19:30 - 20:30\n入会口令（钉钉）： 909 575 00367\n电话呼入： +02162681677（中国大陆）+057128095818（中国大陆）\n入会链接： https://meeting.dingtalk.com/j/eU7EoXJYiHK\n议题：\n 已完成部分\n 健康状态检查方案 review\n 基座引用的 starter，支持 Spring Boot、SOFABoot，Arklet 版本推到 Maven 中央仓库\n 增加锁控制\n 修复 ModuleController 使用 Arklet 遇到的问题\n 基座 Starter，Arklet 0.4 版本打包发版\n 待迭代事项\n SOFAArk\n 基座模块 1:1 复用\n 支持 SOFABoot 4\n SOFAServerless\n 支持中间件列表与优先级，排摸支持情况，设计评测标准\n 官网搭建\n ModuleController\n 先扩后缩\n 模块回滚\n 模块流量 Service\n 强推基线\n 单测达到 80/60、8+ 集成测试、CI 自动化、开发者指南 #72 #73\n ModuleController 各项参数校验\n replicas = -1 表示对等架构\n Arklet\n 服务的跨 Spring Context 发现与调用\n 健康状态检查方案 review\n 增加影响基座健康状态的能力，查询健康状态指令模块安装支持远程协议\n 【spring-boot-ark-plugin】#74\n 【Arklet】指令耗时统计和资源消耗统计设计 #77\n Arkctl\n Arkctl 增加模块对应实例与状态查询\n Arkctl 增加模块代码初始化能力 #83\n Arkctl 增加模块部署能力 #82\n Arkctl、Arklet、ModuleController 0.5 发版本\n 「SOFAServerless」：https://github.com/sofastack/sofa-serverless/issue/100\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：09 月 13 日 14:00 - 15:00\n会议内容：\n 项目规划方向补充\n Wasm 组件的规划 资源隔离 开源之夏\n Dapr component 升级的讨论 集成 K8s 注入的进度分享和思路讨论 CSDI Summit 社区成员分享同步\n add uds support for Java SDK 的同步\n 「Layotto」：https://github.com/mosn/layotto/issues/989\n「会议回放」：https://www.bilibili.com/video/BV1UF411D77o\nSOFAStack 社区本周贡献 本周推荐阅读 SOFABoot 4.0 正式发布，多项新特性等你来体验！\n蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata-DTX｜分布式事务金融场景案例介绍\nSOFARegistry | 大规模集群优化实践\n","date":1694761200,"description":"SOFA Weekly｜SOFAServerless 社区会议预告、Layotto 社区会议回顾与预告、C 位大咖说","dir":"blog/sofa-weekly-20230915/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa9ec5c3db35fbfd01dcafbf949b707b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230915/","publishdate":"2023-09-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230915/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议预告、Layotto 社区会议回顾与预告、C 位大咖说","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230915/","wordcount":1262},{"author":null,"categories":"SOFAStack","content":" 文｜王勤龙（*花名：长凡*）\n蚂蚁集团 AI 系统工程师\n文｜张吉（*花名：理之*）\n蚂蚁集团 AI 系统工程师\n文｜兰霆峰\n四川大学 20 级计算机系\n本文 5104 字 阅读 13 分钟\n01 背景 如今大语言模型（*LLM*）的分布式训练节点规模越来越大，训练耗时长。比如 OpenAI 在 1024 个 NVIDIA A100 GPU 上训练 GPT-3 大约需要 34 天。训练节点越多，耗时越长，训练期间节点故障概率就越大，况且 A100 GPU 的故障率也相对较高。所以大规模训练作业难免会遇到节点故障。据我们在蚂蚁 GPU 训练集群上观察，一个月内，单卡的故障率约 8%，那么一天单卡的故障率约为 0.27%。常见的故障原因有 Xid、ECC、NVLINK error 和 NCCL error 故障等。对于一个千卡训练作业来说，卡故障导致一天内训练失败的概率高达到 93%。所以训练作业几乎每天都会失败。作业失败后，用户需要手动重启作业，运维成本很高。如果用户重启不及时，中间间隔的时间就会导致 GPU 卡空闲，浪费昂贵的算力资源。\n有些故障会导致机器不可用，从而导致可用节点数量不能达到用户指定的数量。这时，训练就不能启动，用户需要手动减少节点数量后重新提交作业。待故障机修复后，用户又需要手动增加作业的节点数来重启作业。这样增大了用户的运维成本，也导致了新节点无法及时加入训练。\n为此，DLRover 在 Kubernetes 上基于 Torch Elastic 开发了弹性训练功能，实现 PyTorch 分布式训练的自动容错和弹性。具体功能如下：\n 出现故障后，快速执行节点健康检测，定位故障机并将其隔离，然后重启 Pod 来替换故障节点。\n 健康检测通过后，重启训练子进程来自动恢复模型训练，无需重启作业或者所有 Pod。\n 节点故障导致可用机器少于作业配置，自动缩容来继续训练。集群新增机器后，自动扩容来恢复节点数量。\n 优化 FSDP 并行训练的模型 save/load，支持根据实际卡数 reshard 模型参数，缩短 checkpoint 保存和加载时间。\n 在 DLRover 弹性容错应用在蚂蚁大模型训练前，一周内千卡训练运行时间占 60.8%，有效训练时间约 32.9%（*有效训练时间=模型迭代的步数*每步的时间*）。除此之外，训练运行时间还包括 checkpoint 保存时间和训练回退时间等。DLRover 上线后，一周内千卡训练运行时间占比提升至 83.6%，有效训练时间提升至 58.9%。\n02 PyTorch 弹性训练框架 弹性训练是指在训练过程中可以伸缩节点数量。当前支持 PyTroch 弹性训练的框架有 Torch Elastic 和 Elastic Horovod。二者显著的区别在于节点数量变化后是否需要重启训练子进程来恢复训练。Torch Elastic 感知到新节点加入后会立刻重启所有节点的子进程，集合通信组网，然后从 checkpoint 文件里恢复训练状态来继续训练。而 Elastic Horovod 则是每个训练子进程在每个 step 后检查新节点加入，子进程不退出的情况下重新集合通信组网，然后有 rank-0 将模型广播给所有 rank。二者的优劣对比如下：\n通过上述对比可以看出，Torch Elastic 重启训练子进程的方案对用户更加友好，支持更多的分布式训练策略和模型。而 FSDP 和 NCCL 是当前大模型分布式训练使用最为广泛的技术。所以 DLRover 选择使用 Torch Elastic 重启子进程的方案来实现 Kubernetes 集群上分布式训练的弹性容错。\n03 集合通信动态组网 动态组网是指训练进程可以自动根据动态变化的节点数量来组网集合通信，无需固定给各个节点指定集合通信的 rank 和 world size。动态组网是弹性容错训练必须的，因为弹性容错作业中，节点的失败、扩容或者缩容都会导致节点的 rank 和 world size 变化。所以我们无法在作业启动前给节点指定 rank 和 world size。\nTorch Elastic 动态组网 Torch Elastic 启动子进程后，所有子进程需要进行集合通信组网。Torch Elastic 使用 Dynamic Rendezvous 机制来协助子进程组网。每个节点上运行一个 ElasticAgent，ElasticAgent 会从一个共享存储中获取作业节点的 host group，然后将自己的 host 加入 group 并同步到共享存储里。这个共享存储当前默认使用 TCPStore。接着，ElasticAgent 不断从共享存储里获取查询 host group，直到 host group 里的节点数量达到最小节点数量 min_nodes 且一段时间内没有变化，即认为所有节点都准备好了。然后，ElasticAgent 就可以从 host group 里获取自己的节点 rank（*PyTorch 中称为 group rank*）和 world size。这样，ElasticAgent 就可以给拉起的子进程配置 local rank、global rank 和 world size 了。有了这些信息，子进程就可以进程集合通信组网。\n但是使用 Torch Elastic 原生方案中，我们发现一些问题：\n 节点不能容错。TCPStore 在一个训练节点上，如果该节点挂了，重组网就没法继续了。\n 节点 rank 是随机的。ElasticAgent 同步 host 到共享存储的顺序是随机的，导致节点 rank 的随机。在训练代码中，用户一般会将模型迭代信息输出在 rank-0 的日志里，比如 step、loss 和耗时等。用户只能通过进程日志寻找 rank-0 ，对于多节点的作业，这是比较麻烦的。\n Torch Elastic 的动态组网不能控制组网的节点数量。比如 LLM 模型训练中，用户可能会将 4 个节点作为一个数据预处理的组，那么弹性伸缩需要保证节点数量是 4 的整数倍。而 Torch Elastic 只要发现有一个新节点加入就会立刻重启训练。  DLRover 动态组网 针对上面问题，DLRover 重新实现了 PyTorch ElasticAgent 的动态组网模块 RendezvousHandler，利用 ElasticJob 点 Master 来协助 PyTorch 组网。Master 是一个纯 CPU 节点，不参与训练，稳定性比 GPU 节点高很多。\n（DLRover ElasticJob 动态组网）\nDLRover 的 ElasticJob 在启动 Pod 时，会给每个 Pod 一个唯一的编号 Pod ID 并配置到 Pod 的环境变量里。训练节点的 ElasticAgent 的 RendezvousHandler 会将自己的编号 Pod ID 和 GPU 卡数上报给 Master 的 Rendezvous Manager。然后不断从 Master 中请求通信 world，即所有节点的信息。Master 的 Rendezvous Manager …","date":1694502000,"description":"DLRover 在 K8s 上千卡级大模型训练稳定性保障的技术实践","dir":"blog/dlrover's-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9873bd3dccef5853a61dc3c706403d5d","permalink":"https://sofastack.github.io/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","publishdate":"2023-09-12T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","summary":"文｜王勤龙（*花名：长凡*） 蚂蚁集团 AI 系统工程师 文｜张吉（*花名：理之*） 蚂蚁集团 AI 系统工程师 文｜兰霆峰 四川大学 20 级计算机系 本文 5104 字 阅读 13 分","tags":["SOFAStack"],"title":"DLRover 在 K8s 上千卡级大模型训练稳定性保障的技术实践","type":"blog","url":"/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","wordcount":5172},{"author":null,"categories":"SOFAStack","content":" 1. 前言 本文是支付宝资金技术团队在《大象转身-支付宝资金技术交付提效之路》系列总结之一。如果你正在负责一个所支撑的业务面临从平台到场景化创新的发展阶段，希望通过提升交付效率来提升技术团队的竞争力和团队研发幸福感， 那么这篇文章也许会让你有收获：\n Serverless 的技术理念是什么？对业务研发有什么借鉴意义？\n 如何基于 Serverless 驱动研发模式的升级，设计一个能让场景化创新快起来的技术架构，提升全局研发效率？\n 本篇作者：呆莫（代巍）、歆明（何鑫铭）\n文章较长，建议收藏和保存\n为什么写这篇文章 我们做了近两年的 Serverless 研发模式的探索和落地，目前该模式已经承接了大部分资金业务的场景，平台也已经进入推广期，有 20+ 团队经过 SOFAServerless 技术团队的介绍找到我们。未接入 SOFAServerless 的想从业务视角寻求架构选型依据和应用架构设计，已接入 SOFAServerless 的同学来寻找基座治理经验。因此决定写一篇文章，将我们的架构选型、设计和落地经验做一次完整的总结。\n2. 我们遇到的问题 我们的问题：随着场景创新增多，SOFA 应用变臃肿、团队研发人数变多导致研发和运维难度升高，阻碍了业务创新的交付效率，系统需要做重构。\n简单说说背景 资金在这两年时间，肩负了很多业务创新、寻找业务增量的目标。增量时代的创新是残酷的，成功的明星产品背后，是无数次的失败（这三年间，技术支撑了 15+ 个创新产品的建设，包括小程序、行业解决方案）。而支付团队转型做创新也面临着巨大的挑战：动辄 1-2 个月起的研发交付周期，在当时使得技术团队被按在地上摩擦，各种问题接踵而来。\n蚂蚁集团 CTO 苗人凤曾经说过，创新是九死一生，技术就是要帮助业务降低机会成本。\n我们逐渐意识到业务创新的快速发展，一定离不开业务快速交付的新型技术研发模式。如果我们还是沿用平台化的架构思路，在一个庞大的资金平台上写一堆创新场景的代码，在完成业务需求的同时还要思考如何抽象、如何保障增量的代码不影响平台稳定性，那一定快不了。\n2021 年，我们成立“资金场景创新提效项目”，试图通过平台架构升级、研发模式升级解决场景创新效率问题。\n问题定义：资金场景应用变成巨石应用带来一系列问题 试着代入一下案例：\n如果有那么 5 个创新业务迭代在同一个应用发布窗口进行推进，会存在各种各样导致延期的原因:\n1、A 业务验证延后 2 天，那么 5 个迭代都要延后 2 天；\n2、B 业务升级了中间件版本，那整个应用的业务都面临回归成本一样要延后整个发布期；\n3、C 业务想要在预发搭个车微调一些代码，但是由于动作慢没能成功验证，导致污染了主干，进而耽误了整体；\n……\n 在应用架构层面，资金部门早期孵化出了一个“大资金场景层应用”——Fundapplication。Fundapplication 在研发协作方面，从一开始的几个同学，到后来几个业务团队、几十个研发同学，都在一个应用系统上研发，通过多个 bundle 区分不同业务，公共的 bundle 沉淀通用能力和研发工具（*类似于之前的 mng 系统*），如下图：\n这种架构设计在遇到大量的彼此没有复用的业务创新需求时，就逐步沦为了巨石应用，如下图：\n1、研发运维效率低：作为入口系统，mgw 接口无法在本地开发自测，改动任何代码必须发布到联调环境。发布一次需要 10 分钟以上，还要忍受环境不稳定因素带来的额外时间花费。\n2、业务迭代抢占，协同成本高：系统作为创新应用系统，有 10+ 个创新产品，30+ 个正式员工和外包员工也在这个系统上做研发迭代，火车式发布迭代痛点明显——一人晚点，全体延期。\n3、研发时隔离效率低：30+ 研发同学（含外包）在一个系统内研发，经过不到一年的时间，我们的系统就变成 10+ 个 bundle、2w+ 个 Java 文件（*全站均值 4000*）的体量了，因为各种业务的各种依赖的增加，系统启动一次需要 15 分钟。随着创新场景增多会变得更加糟糕，而且很多代码没有办法随着业务的下线而删除。\n4、运行时不隔离：目前我们没有对不同的业务区分不同的机房，业务吃大锅饭，难以做到按产品的资源和稳定性保障。\n如果你的应用也存在上述问题，对业务创新的交付效率产生了一定的影响，那可以继续参考第 3、4 章我们的架构选型和关键设计。\n3. 应用架构的选型 当前蚂蚁基于 SOFABoot 的应用架构，在规模化创新场景研发的交付效率、分工协作模式上存在局限性。从行业的发展趋势分析，云原生等新技术引领的“集装箱”架构模式，有利于促进规模化的生产效率和分工协作方式。借助蚂蚁 SOFAServerless 的孵化，我们决定作为种子用户，使用 Serverless 中 BaaS+FaaS 的理念，重塑创新场景研发的研发模式。\n微服务应用架构的局限性 大应用创新的模式，是在一个应用系统中按照不同 bundle 来隔离创新应用，可复用的代码可能是放到一个公共的 bundle 中。优点当然是复用效率高，运维统一，缺点主要是协作效率、隔离成本和研发效率。大应用变成巨石应用如何解决？这个我们很容易就想到使用分治的思路，将一个大应用拆成多个应用，通过 RPC 来互相调用。\n在蚂蚁当前体系下，微服务系统的 0-1 成本、后续运维成本、硬件机器成本仍然会是一个不小的开销，创新试错还是快不起来。且后端业务创新具有巨大的不确定性，如果因为业务没量了变成长尾系统下线的成本也很高；在性能方面，多个系统间通用能力的调用，会使全链路的调用耗时增加，在业务上不可接受。所以有没有一种技术，可以让业务既能够隔离，又能够降低隔离带来的负向影响：运维成本、能力复用效率、性能？\n行业技术架构的发展趋势 一部分做架构的同学喜欢用“架构隐喻”来介绍架构的理念。近几年容器化、云原生、Serverless 等新技术层出不穷，作为架构师需要在对新技术保持敏感的同时，能够有一双洞察架构本质的眼睛。\n这些底层新技术的出现，本质上是通过抽象定义“集装箱”的方式，规范了构建、部署、运行、运维标准，提升了软件的生产效率。大家可以感受一下这些技术底层理念的相通之处：\n Docker 通过定义容器“集装箱”提升传统虚拟机、基础设施软件构建、运维效率；\n K8s 进一步抽象万物皆可定义为 CRD（*自定义资源*）提升“集装箱”的部署、运维效率；\n 中间件 Mesh 化将“集装箱”理念应用到中间件近端，将中间件近端与业务代码剥离解耦；\n BaaS、FaaS 等 Serverless 技术，将“集装箱”理念范围进一步扩大到可复用的“业务领域插件”。\n 可以这么说，集装箱改变世界航运效率，计算机软件行业的 Docker、K8s 们通过“集装箱”的架构理念改变了基础软件生产效率。而随着 Serverless 的兴起，“集装箱”的架构理念将会自底向上地，重塑对软件交付效率重度依赖的互联网、金融等行业。\n我们来看下，集装箱的理念对我们业务研发的启示：\n过去，业务研发需要关注独立的业务应用，既需要关注业务代码、中间件代码等代码信息，又需要关注 Java 进程、CPU、内存等运维信息，随着这两年蚂蚁 MOSN 等 Service …","date":1693897200,"description":"大象转身：支付宝资金技术 Serverless 提效总结","dir":"blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","fuzzywordcount":12500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d09a365280bac8113c2d8e53309c4911","permalink":"https://sofastack.github.io/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","publishdate":"2023-09-05T15:00:00+08:00","readingtime":25,"relpermalink":"/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","summary":"1. 前言 本文是支付宝资金技术团队在《大象转身-支付宝资金技术交付提效之路》系列总结之一。如果你正在负责一个所支撑的业务面临从平台到场景化创新的","tags":["SOFAStack"],"title":"大象转身：支付宝资金技术 Serverless 提效总结","type":"blog","url":"/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","wordcount":12433},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAChannel#35 预告 SOFABoot 是蚂蚁集团开源的基于 Spring Boot 的研发框架。近期，SOFABoot 更新了 4.0 版本，带来了更多新特性。不仅正式支持了 Spring Boot 3 版本，也同时做出了包括历史功能演进在内的一系列调整优化，使得框架自身更加易用。\n本期 SOFAChannel#35 邀请到了蚂蚁集团技术专家、SOFABoot 项目 Maintainer 胡子杰跟大家分享 《SOFABoot 4.0 — 迈向 JDK 17 新时代》。\nSOFA 社区会议预告 SOFAServerless：\n主题：SOFAServerless 社区会议\n时间：09 月 04 日 19:30 - 20:30\n入会口令（钉钉）：909 575 00367\n电话呼入：+057128095818（中国大陆） +02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/EQzqQVtJoro\n议题：\n 8月回顾\n Arklet 待完成的动作\n 增加影响基座健康状态的能力，查询健康状态指令\n ModuleController 的功能\n 各项参数校验、单测达到 80/60、8+ 集成测试、CI 自动化、开发者指南\n 各组件的发版 release\n ModuleController 0.3\n Arklet 0.3\n SOFAArk 2.2.2\n 9 月迭代规划讨论\n SOFAArk\n 基座模块 1:1 复用 ClassLoader\n 支持 SOFABoot 4\n SOFAServerless\n 支持中间件列表与优先级，排摸支持情况，设计评测标准\n 基座 Starter，Arklet 的打包发布\n ModuleController\n 新扩后缩\n 模块回滚\n 模块流量 Service\n Arklet\n 服务的跨 Spring Context 发现与调用\n Arkctl、Arklet、ModuleController 0.5 发版本\n 「*SOFAServerless*」：https://github.com/sofastack/sofa-serverless/issues/44\nLayotto：\n主题：Layotto 社区会议\n时间：09 月 06 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+02162681677（中国大陆）+057128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/MkM4YQVrEE3\n议题：\n Layotto 项目规划和展望 #976\n 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959\n Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\n Develop a new component for sms API；为“短信 API”开发新的组件 #830\n 「*Layotto*」：https://github.com/mosn/layotto/issues/984\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：08 月 30 日 14:00 - 15:00\n会议内容：\n 下半年规划与展望\n SDK 模式、公有云部署的两个方向明确 开源之夏\n Layotto K8s 集成：关于动态配置注入思路的讨论\n 短信邮件 API：API 适配不同云厂商的组件具体开发\n 「*Layotto*」：https://github.com/mosn/layotto/issues/984\n「*会议回放*」：https://www.bilibili.com/video/BV1bz4y1K7RG\nSOFARPC 5.11.0 版本发布 发布 SOFARPC 5.11.0 版本，主要变更如下:\n 支持 SOFARPC 在 Mac M1 芯片环境编译\n 修复直连调用时，url 拼接错误的问题\n 升级 Hessian 到 3.5.0\n 升级 Bolt 到 1.6.6\n 升级 gRPC 到 1.53.0\n 升级 SOFARegistry 到 6.3.0\n 升级 Dubbo 到 3.1.8\n 升级 Javassist 到 3.29，引入新版 API，支持在 JDK 17 环境下使用\n 解决部分 SOFABoot 4.0 下的兼容性问题，现在 SOFARPC 支持基于 SOFABoot 4.0 运行\n 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.11.0\nSOFAHessian 3.5.0 版本发布 发布 SOFAHessian 3.5.0 版本，主要变更如下:\n 新增了 Currency、 Atomic、Throwable、StackTraceElement 类的定制序列化器，支持在 JDK 17 环境下运行\n 针对内部的反射逻辑做了一定的调整，支持在 JDK 17 环境下运行\n 详细发布报告：https://github.com/sofastack/sofa-hessian/releases/tag/v3.5.0\nSOFAStack 社区本周贡献 本周推荐阅读 SOFABoot 4.0 正式发布，多项新特性等你来体验！\n蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata-DTX｜分布式事务金融场景案例介绍\nSOFARegistry | 大规模集群优化实践\n","date":1693551600,"description":"SOFAChannel#35 直播预告、SOFARPC/SOFAHessian 新版本发布、社区会议","dir":"blog/sofa-weekly-20230901/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4506495f5728921c30461c2adf82271f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230901/","publishdate":"2023-09-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230901/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAChannel#35 直播预告、SOFARPC/SOFAHessian 新版本发布、社区会议","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230901/","wordcount":1753},{"author":null,"categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区 活动时间：09 月 07 日，周四晚 19 点 活动形式：线上直播 资料下载： 点击获取 B 站直播间地址：http://live.bilibili.com/21954520 B 站直播回放：SOFAChannel#35 介绍 | SOFAChannel SOFA:Channel 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\nSOFA:Channel 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\nSOFABoot 项目简介 SOFABoot 是蚂蚁集团开源的基于 Spring Boot 的研发框架，提供了诸如 Readiness Check、模块化和日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\n近期，SOFABoot 更新了 4.0 版本，带来了更多新特性。不仅正式支持了 Spring Boot 3 版本，也同时做出了包括历史功能演进在内的一系列调整优化，使得框架自身更加易用。\n本期 SOFAChannel#35 邀请到了蚂蚁集团技术专家、SOFABoot 项目 Maintainer 胡子杰跟大家分享 《SOFABoot 4.0 — 迈向 JDK 17 新时代》。\n直播介绍 《SOFABoot 4.0—迈向 JDK 17 新时代》\n2023 年 9 月 7 日（周四）\n19：00 - 20：00\n「嘉宾简介」\n胡子杰（*花名：致节*）\n蚂蚁集团技术专家\nSOFABoot Maintainer\n「议题简介」\n本次分享将主要介绍 SOFABoot 4.0 新版本引入的新特性与变化，包括其设计理念与实现方式。再者就是介绍 SOFABoot 3 应用如何升级至 SOFABoot 4.0 版本，并展望 SOFABoot 未来的发展趋势。\n「听众收获」\n SOFABoot 4.0 的新特性与变化； 已有应用如何升级至 SOFABoot 4.0 版本； 一起探讨 SOFABoot 未来发展的趋势。 直播回放 点击查看\n了解更多技术干货 使用钉钉搜索群号：44858463 ，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1693465200,"description":"SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》","dir":"activities/sofa-channel-35/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"94eeffb4d40ce60a8be76d1892342c40","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-35/","publishdate":"2023-08-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-35/","summary":"概要 活动主题：SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区 活动时间：09 月 07 日，周四晚 19 点 活动","tags":["SOFAChannel"],"title":"SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-35/","wordcount":704},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题：Layotto 社区会议\n时间：08 月 30 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+057128095818（中国大陆）+02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/Wv0wyrJyDhA\n议题：\n Layotto 项目规划和展望 #976\n 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959\n Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\n Develop a new component for sms API；为“短信 API” 开发新的组件 #830\n 「*Layotto*」：https://github.com/mosn/layotto/issues/983\nSOFA 社区会议回顾 SOFAServerless：\n主题：SOFAServerless 社区会议\n时间：08 月 21 日 19:30 - 20:30\n会议内容：\n 8月回顾\n Arklet 待完成的动作\n 增加影响基座健康状态的能力，查询健康状态指令\n 健康状态检查方案 review\n 模块安装支持远程协议\n 修复 ModuleController 使用 Arklet 遇到的问题 #17\n 增加锁控制 #39\n 基座引用的 starter，支持 Spring Boot、SOFABoot，推到 Maven 中央仓库\n 9 月迭代规划讨论\n 支持中间件列表与优先级\n 支持 SOFABoot 4.0\n 回滚，先扩后缩，模块流量 Service\n Arkctl Arklet ModuleController 0.5 发版本\n 「*SOFAServerless*」：https://github.com/sofastack/sofa-serverless/issues/38\n「*会议回放*」：https://www.bilibili.com/video/BV19r4y1R761\nLayotto：\n主题：Layotto 社区会议\n时间：08 月 23 日 14:00 - 15:00\n会议内容：\n Layotto 社区下半年规划\n 开源之夏\n 自定义插件：等待同步动作\n 集成 K8s\n 此前遗留问题的讨论、动态配置的思路\n 在 K8s 上已跑通的 demo 分享\n 短信 API\n API 已完成，关闭 issue，将跟进开发各自组件\n 「*Layotto*」：https://github.com/mosn/layotto/issues/983\n「*会议回放*」：https://www.bilibili.com/video/BV15j411q7As\nSOFAStack 社区本周贡献 本周推荐阅读 蚂蚁 SOFAServerless 微服务新架构的探索与实践\n超越边界：FaaS 的应用实践和未来展望\nMoE 系列（七）｜ Envoy Go 扩展之沙箱安全\nSeata-DTX｜分布式事务金融场景案例介绍\n","date":1692946800,"description":"SOFAServerless 社区会议回顾、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-20230825/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"25a1f7a1856d6b2d7c1f7c87dd47da64","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230825/","publishdate":"2023-08-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230825/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议回顾、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230825/","wordcount":1130},{"author":null,"categories":"SOFAStack","content":" 作者简介 赵真灵（有济）\n蚂蚁集团技术专家，Serverless 和微服务领域专家\n曾负责基于 K8s Deployment 的应用发布运维平台建设、K8s 集群的 Node/pod 多级弹性伸缩与产品建设。当前主要负责应用架构演进和 Serverless 相关工作。同时也是 SOFAArk 社区的开发和维护者以及 KNative 社区的贡献者。\n本文 3612 字，预计阅读 12 分钟\n传统微服务架构面临的问题和挑战？ 应用架构从单体应用发展到微服务，结合软件工程从瀑布模式到当前的 DevOps 模式的发展，解决了可扩展、分布式、分工协作等问题，为企业提供较好的敏捷性与执行效率，给企业带来了明显的价值。但该模式发展至今，虽然解决了一些问题，也有微服务自身的问题慢慢暴露出来，在当前已经得到持续关注：\n1、业务开发者需要感知复杂的基础设施，启动慢（*分钟级*），研发效率低，运维负担重：\n对于基础设施的问题，在服务网格和应用运行时的工作已经取得了一定的成果，但是基础设施到业务开发之间还存在业务通用的部分，这里当前没有一个模式来给予支持。\n当前已经有一些开源项目在尝试解决基础设施的问题，例如服务网格、应用运行时，如 Dapr/Layotto，也都在实际应用中得到了不错的效果。但当前服务网格和应用运行时更多的是将中间件以下下沉到 sidecar，而一个应用一般还包括通用的业务逻辑部分，要让更广泛的业务也能享受到无基础设施的体感，也需要让业务以下（*可以把业务层以下的看作基础设施*）都能屏蔽。另外当前对于中小企业来说，使用服务网格和应用运行时的成本还是比较高的。\n2、拆分微服务的资源与维护成本高：\n拆分后每个子应用都包含公共部分（*框架、中间件等*），除了同样存在上述第一个问题之外，还需要独占机器资源成本高，如果部分业务萎缩，会面临长尾应用问题，需要承担长期维护的成本。\n3、拆分微服务的敏捷度与业务、组织发展的敏捷度不一致，导致如何合理地拆分微服务始终是个老大难的问题：\n 拆得多增加了资源和管理成本； 拆得不够造成协作效率问题。有些是应该拆但没拆，有些是因为业务领域已经较为细分不便再拆，特别在一些中小企业里，可能都没有微服务的配套设施。 蚂蚁的解决思路和方案 为了解决这些问题，我们对应用同时做了横向和纵向的拆分。纵向拆分：把应用拆分成基座和模块两层，这两层分别对应两层的组织分工。基座小组与传统应用一样，负责机器维护、通用逻辑沉淀、模块架构治理，并为模块提供运行资源和环境。模块在业务层以下所有的基础设施、应用框架、中间件可以不再关注，聚焦在业务逻辑研发本身；并且采用 jar 包的研发模式，具备秒级的验证能力，让模块开发得到极致的提效。\n这可以理解为这套架构的核心模型，核心的能力有两个：平台化 + 模块化。模块化是 20 年前 OSGI 就已经提出的概念，从 OSGI 到 JPMS 一直未被抛弃，到最近 Spring Modulith、Service Weaver 等行业里又兴起一些开源框架，它一直在发展；平台化从 2017 年出现在技术雷达到 2023 年被 Gartner 列为十大战略趋势之一，到现在国内的平台工程，不断得到重视和发展。而我们实际上在行业还没有对这两个技术方向充分关注的情况下，就在尝试把他们结合起来，并在蚂蚁内部得到规模化验证和落地，给业务带来极致的降本增效效果。\n该模式的另一个特点是可演进、可回滚。这里的模块随着业务发展壮大，可以独立部署成微服务；如果微服务拆分过多，可以低成本改造成模块，合并部署在一起，解决资源成本和长期维护成本。实际上可以理解为我们是在单体应用架构和传统微服务架构中间，增加了一个可以演进过渡的架构。\n总结下来这套新微服务架构可以解决这四个问题：\n1、横向拆分出基座屏蔽业务以下的基础设施、框架、中间件和业务通用逻辑等部分，从而极大降低了业务开发者的认知负荷、提高了开发效率。\n2、一个应用可以低成本改造或拆分出多个模块，模块间可以并行独立迭代，从而解决了多人协作阻塞问题，每个模块不单独占用机器资源，没有拆分的机器成本问题。\n3、存量微服务如果拆分过多，可以低成本改造成模块应用，合并部署在一起，解决拆分过多带来的资源成本和维护成本痛点。\n4、模块可以灵活部署，解决微服务拆分与组织发展灵敏度不一致导致的协作低效与分工不合理问题。应用拆分出多个模块，可以部署在一起，也可以进一步演进成独立微服务，同样如果微服务拆分过多，也可以低成本改回模块合并部署到一起。\n这里卖个关子——为什么这些技术在蚂蚁能规模化落地？存量的业务 owner 在业务迭代进度和升级新架构之间做权衡时，我们做了哪些工作？ 欢迎来到 9 月 3 号 QCon 大会现场获得更详细的信息。\n在采用新的微服务架构模式后的成果 举个当前蚂蚁实际业务采用新模式前后的对比数据：\n可以看到这些数据是十倍级以上的提升，当前蚂蚁所有 BU 都已经接入，将近 40W core 的在线业务，并为两种业务模式：中台模式和轻应用模式的业务都提供秒级研发运维的能力。一个基座上面最多有上百个模块，一个开发同学在研发验证阶段，一下午可以验证上百次，需求的交付效率最快可以到小时级别。\n在当下行情下，新技术落地的挑战与蚂蚁的思路 当前行情下，企业对新技术会更加谨慎，技术人也对新技术采取保守态度。新技术虽然很酷，但投入大落地场景有限。这其实是发展过程的转换，在高速发展的行情下，一方面是历史包袱少，另一方面是乐观态度占据主导，更加相信新技术能较快得到规模化落地，整个社会都对新技术充满热情。而在当下阶段，很多企业已经有一定的历史包袱，时间证明新技术规模化落地需要很长的周期，需要整个体系一起演进才可能达到最初的预想，可能也会带来越来越繁复的基础设施，所以当前行业对新技术更加偏保守也是非常合理的。\n所以蚂蚁在建设这套微服务新架构时，有一个非常关键的设计思路，那就是要接地气或者是可演进，也即是要让存量业务能低成本接入。这也是最初蚂蚁在落地该模式时踩过的最大的坑：一个普通应用转换成基座需要花费上月时间（*包括流量迁移*），模块研发与现有基础设施不匹配导致模块研发成本也很高，这个问题在当时也影响了该模式的生死存亡。后来蚂蚁在这块上投入了很大精力，最终让普通应用在小时内可以成为基座或模块，研发模式也与普通应用基本一致。\n经过这个过程，最终低成本、可演进也成为了该模式的一个核心优势。未来对外开源，我们会把接地气做得更加彻底，不对企业的基础设施程度有预设条件：\n 无需容器化也可以接入； 无需使用 K8s 平台也可接入； 无需具备微服务配套设施可也接入； 无需服务网格化也可接入。 微服务新架构落地实战中遇到的更具体的困难和挑战 我们做的这套模式在行业内没有先例，相当于是在无人区里摸索，因此面临多方面的挑战：\n1、关于模块化技术的质疑：为什么现在模块化技术又开始被关注？为什么我们基于 SOFAArk 的模块化技术能推广？挑战主要集中在如何制定合理的隔离和共享通信策略，我们需要避免 OSGI 之类的复杂度问题，做到可以低成本使用。\n2、模块化技术采用了多 ClassLoader，对于 ClassLoader 的隔离、卸载不干净等问题，我们一步一个脚印，深入并体系化 …","date":1692687600,"description":"蚂蚁 SOFAServerless 微服务新架构的探索与实践","dir":"blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b76d3b366c9f1902b9a16c8792999967","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","publishdate":"2023-08-22T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","summary":"作者简介 赵真灵（有济） 蚂蚁集团技术专家，Serverless 和微服务领域专家 曾负责基于 K8s Deployment 的应用发布运维平台建设、K8s 集群的 Node/pod 多级弹性伸缩","tags":["SOFAStack"],"title":"蚂蚁 SOFAServerless 微服务新架构的探索与实践","type":"blog","url":"/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","wordcount":4058},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题： Layotto 社区会议\n时间： 08 月 23 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入：+057128095818（中国大陆）+02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/KPX3eRflTbk\n议题：\nLayotto 项目规划和展望 #976\n2023 开源之夏-课题汇总 #894\nOSPP | Layotto 支持 Pluggable Component 组件 #959\nSupport Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\nDevelop a new component for sms API；为“短信 API”开发新的组件 #830\nDiscuss: whether the sms API definition needs to be modified；讨论一下是否需要修改 sms API 定义 #966\n「Layotto」：https://github.com/mosn/layotto/issues/981\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：8 月 16 日 14:00 - 15:00\n会议内容：\nLayotto 公有云部署想法、下半年产品演进路线讨论分析；\n开源之夏进展同步：\n可插拔插件初步方案的讨论；\nK8s 集成注入位置确认、Dapr 注入的实现方案讨论；\n短信 API 适应不同场景的设计方案\n「Layotto」：https://github.com/mosn/layotto/issues/981\n「会议回放」：https://www.bilibili.com/video/BV1wX4y1E7KQ/\nSOFAStack 社区本周贡献 本周推荐阅读 超越边界：FaaS 的应用实践和未来展望\nMoE 系列（七）｜ Envoy Go 扩展之沙箱安全\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\nSeata-DTX｜分布式事务金融场景案例介绍\n","date":1692342000,"description":"SOFA Weekly｜Layotto 社区会议回顾与预告、SOFA 茶水间、社区本周贡献","dir":"blog/sofa-weekly-20230818/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f1f84d7ed240f62b5ec5da285c349dd4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230818/","publishdate":"2023-08-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230818/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜Layotto 社区会议回顾与预告、SOFA 茶水间、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230818/","wordcount":828},{"author":null,"categories":"SOFAStack","content":" 作者简介 邢奇（薯片）\n蚂蚁集团技术专家，云原生和 Service Mesh 领域专家\n长期从事服务治理和服务发现等相关领域的研究和实践，在 RPC 框架（*Dubbo、Spring Cloud 和 SOFARPC 等*）方面有源码级的研究和贡献；在 Service Mesh、云原生、容器和 K8s 等方面有深入的研究和实践经验。\n参与了多个开源项目的贡献，包括 MOSN、SOFA、Dubbo 和 Nacos 等。目前担任蚂蚁云开发技术负责人，负责支付宝云开发产品的研发和实践。\n本文 5689 字，预计阅读 16 分钟\n概述 什么是 FaaS ？\n在 ChatGPT 里面输入 FaaS 关键字，得到的结果是：*FaaS 是一种云计算服务模型*。它允许开发者编写和部署函数，而不需要管理底层基础设施的运行，即 Function as a Service。\n同时通过 ChatGPT 可以生成对应的函数代码——\nFaaS 的崛起 FaaS 的理念和函数研发模式，为传统的应用模式解决了许多问题，有着超前的优势。\n传统应用模式的困境 在研发态，不管是单体应用还是微服务应用，亦或是 Mesh 架构或者应用运行时，在研发态，开发者除了要关注业务逻辑本身之外，经常会被中间件所打扰，需要配合去做 SDK 升级改造，性能或者功能优化等。同时在使用云产品或者云服务的时候，需要被迫去感知多云的差异。\n在运维态，开发者面临着更重的运维压力。当一个应用上线，开发者需要对这个业务的未来发展进行一个复杂且不确定的容量评估，再去为这个容量去申请对应的资源，最后经过一个复杂的上线流程进行发布。在发布结束之后，开发者还得时刻关注线上流量的变化，去进行不断的扩容和缩容的调整。\n总而言之，整个中间件和基础设施对开发者的打扰是非常严重的：\n 应用研发模式的代码耦合严重，复杂度高； 运维流程繁琐，效率低； 容量评估一般很难符合真实情况，线上的资源利用率一般都较低，存在着浪费。 于是 FaaS 函数的研发模式应运而生。\n可以很直观地看到，在传统应用和微服务应用的改造和优化的基础之上，FaaS 希望做得更进一步，更面向未来。以函数为编程对象，用户无需关注应用、机器等数据和基础设施信息。\n通过这样的改变，大大提升研发效能，做到快速开发；并且提高运维效率，提供一站式免运维的 Serverless 平台；最后，函数会随着流量进行创建和销毁，最终降低成本和资源的消耗。\nFaaS 使用场景 尽管 FaaS 具有许多优势，但并非所有场景都适合采用函数编程模式。下面介绍一些 FaaS 适用的普遍场景：\n1、BFF 的场景。 即一些胶水代码（*对接多个接口、进行数据的组装和适配等*）。胶水代码的逻辑相对简单，但同时需求变化快、生命周期短。对应的应用场景如运营/营销活动等。活动结束之后，就不再有流量进入，也没有必要再进行代码和机器的维护。\n2、事件驱动的场景。 例如音视频转码，用户上传文件触发任务，或者通过消息触发调度，或者业务上有明显的波峰和波峰的流量特征。\n3、中台型业务。 例如算法平台的算子。算子计算是非常独立的业务逻辑，但是参与的研发人数非常多，逻辑相对来说不可控，需要有更高的隔离能力。\nFaaS 落地面临的技术问题 FaaS 技术产品的落地，可能会面临以下问题和挑战：\n性能问题：\n1、在传统的微服务架构下，开发者会为 RPC 调用性能进行了大量的优化；在 FaaS 的场景，也需要保证函数调用的性能。\n2、弹性扩缩容的反应时效性。很多 FaaS 产品会采用弹性的模型去采集 CPU、QPS 并发等指标，再通过平台去计算指标，进而进行一些扩容和缩容的操作，时效性很低。\n3、函数启动的速度。函数启动的速度在 FaaS 场景中至关重要，函数容器的创建和启动不仅仅是发布态的事情，而是一个数据面流量的依赖。\n安全问题：\n1、想要充分地利用计算资源以降低成本，其必要的前提就是有效地利用和隔离资源。\n2、代码容器。用户的函数代码跑在容器里面，防止容器逃逸就是重中之重。\n3、相较传统的编程模型而言，FaaS 的编程模型到底是如何屏蔽中间件以及云服务的干扰的呢？\n蚂蚁 FaaS 技术架构 蚂蚁在 FaaS 实践之初设定了 3 个 FaaS 技术架构实践的基本原则。\n原则 1：流量模型。 蚂蚁的函数容器是随着流量进行创建和销毁的，而不是通过指标数据进行分析的弹性模型。\n原则 2：函数冷启动。 尽管有 Warm Pool 或者 cache 技术可作选择，但为了最大程度降低成本和利用资源，蚂蚁将目标定为 100ms 以内的极致的冷启动。\n原则 3：安全隔离。 用户的函数都跑在我们的容器里面，因此必须保证高水位的安全隔离特性。\n其实，蚂蚁在实践 FaaS 技术架构时，有一个总的原则就是 one request per instance—极致的情况下，是创建一个函数容器去处理一个请求，类似编程模型创建一个线程去处理一个请求。在这里，创建函数容器就相当于创建一个线程，具有相似的快速、消耗低的优点，同时还有线程所不具备的安全隔离特性。\n架构说明 组件介绍和功能说明 函数网关：负责对函数请求进行转发和控制，并为每一个请求发起一次容器调度任务。\n容器调度引擎：负责对容器进行调度，维护容器的整个生命周期，并且可以对函数容器进行并发度和复用等状态控制，同时也负责管理整个集群的函数 Pod 资源池。（函数 Pod 资源池是函数容器运行的一个环境，一个集群内会有 N 多个 Pod 资源池。 ）\n函数运行时：函数运行时是 OCI 标准的实现，它负责快速地启动函数容器，并对容器的 runtime 进行有效的控制。\n函数容器：函数容器可以理解为是函数运行时+runtime+用户代码的一个运行态，用户的函数代码就跑在函数容器中。\n数据面流量和调度流程说明 从上图可以看到，所有请求都会通过函数网关进入到函数集群，函数网关会发起一次调度任务：通过容器调度引擎 Scheduler 为这一请求快速分配一个 Pod 资源。然后网关就会把这个流量转发给这个 Pod 资源里面的节点网关，节点网关随即缓存对应的请求，并且等待函数容器启动。同时函数节点调度器会并发地创建函数容器并且为容器挂载函数代码。函数容器在启动完成之后，就会立刻作为一个客户端去节点网关上拉取请求，然后进行业务逻辑处理。\n从上述流程中可以看到，蚂蚁 FaaS 场景中的 Serverless 有了第二层含义——no server（*没有 server*）。函数容器永远是作为一个 client 去处理请求。这样的方式从设计上就避免了对基础设施环境的依赖，同时减少了需要去打开一些网络端口、处理网络连接的损耗，也不需要像微服务应用那样去做一些 checkhealth 和 readliness 探针等之后才能进行注册，然后再进行服务发现和调用。\n性能优化实践 函数网关 FaaS 函数网关采用 Go 语言进行编写，网络编程模型是通过一个 go routine 处理一个请求的同步编程，比较符合开发者的习惯。同时由于 Go 语言良好的垃圾回收机制和 GPM 调度模型，网关也有了不错的性能。但是随着业务的不断增长，整个网关在高并发下会出现毛刺现象，P99 长尾也比 …","date":1692082800,"description":"超越边界：FaaS 的应用实践和未来展望","dir":"blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d4e9bc499a9bd2a868c56d990b3f4dc8","permalink":"https://sofastack.github.io/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","publishdate":"2023-08-15T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","summary":"作者简介 邢奇（薯片） 蚂蚁集团技术专家，云原生和 Service Mesh 领域专家 长期从事服务治理和服务发现等相关领域的研究和实践，在 RPC 框架（*Dubbo、Spri","tags":["SOFAStack"],"title":"超越边界：FaaS 的应用实践和未来展望","type":"blog","url":"/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","wordcount":6592},{"author":null,"categories":"SOFAStack","content":" Dragonfly 最新正式版本 v2.1.0 已经发布！ 感谢赵鑫鑫[1]同学帮助重构 Console 代码，并且提供全新的 Console[2]控制台方便用户可视化操作 P2P 集群。欢迎访问 d7y.io[3]网站来了解详情，下面具体介绍 v2.1.0 版本带来了哪些更新。\n功能 Console v1.0.0[4]已经发布，它是一个全新的可视化控制台，方便用户操作 P2P 集群。 新增虚拟网络拓扑探索功能，能够在 P2P 运行时探测节点之间的网络延迟，从而构建一个虚拟网络拓扑结构提供调度使用。 Manager 提供控制 Scheduler 可以提供的服务，例如在 Manager 中设置 Scheduler 不提供预热功能，那么 Scheduler 实例就会拒绝预热请求。 Dfstore 提供 GetObjectMetadatas 和 CopyObject 接口，支持 Dragonfly 作为 JuiceFS 的后端存储。 新增 Personal Access Tokens 功能，用户可以创建自己的 Personal Access Tokens 在调用 Open API 的时候鉴权使用。 Manager REST 服务提供 TLS 配置。 修复当 Dfdaemon 没有可用的 Scheduler 地址时启动失败的现象。 新增 Cluster 资源单位，Cluster 代表一个 P2P 集群，其只包含一个 Scheduler Cluster 和一个 Seed Peer Cluster，并且二者关联。 修复 Dfstore 在 Dfdaemon 并发下载时，可能导致的对象存储下载失败。 Scheduler 新增 Database 配置，并且把之前 Redis 的配置信息移入到 Database 配置中，并且兼容老版本。 在 Dfdaemon 中使用 gRPC 健康检查代替 net.Dial。 修复调度器过滤以及评估过程中 candidateParentLimit 可能影响到调度结果的问题。 修复 Scheduler 中的 Storage 在 bufferSize 为 0 的时候，导致的无法写入下载记录的问题。 日志中隐藏敏感信息，例如 Header 中的一些 Token 信息等。 Manager 中 Scheduler、Seed Peer 等资源删除过程中，不再使用软删除。 Scheduler 数据库表中新增 uk_scheduler 索引，Seed Peer 数据库表中新增 uk_seed_peer 索引。 由于初期功能设计定位不清晰的原因，删除 Security Domain 和 Security 的功能。 Manager 和 Scheduler 新增 Advertise Port 配置，方便用户配置不同的 Advertise Port。 修复 Task 注册阶段状态机状态变更错误的问题。 破坏性变更 不再提供 Scheduler Cluster 和 Seed Peer Cluster 之间 M:N 的关系。提供了 Cluster 的概念，一个 Cluster 即表示一个 P2P 集群，并且一个 Cluster 只包含一个 Scheduler Cluster 和 Seed Peer Cluster，且二者是 1:1 的关联关系。 控制台 更多的关于控制台的内容可以参考官网文档 Manager Console[5]。\nAI 基础设施 Triton Inference Server[6]使用 Dragonfly 下载模型文件，可以参考 #2185[7]。如果有对集成 Triton Inference Server 项目 Drgaonfly Repository Agent[8]感兴趣的同学，可以联系 gaius.qi@gmail.com。 TorchServer[9]使用 Dragonfly 下载模型文件，现正在开发，预计 v2.1.1 版本可以使用，项目仓库在 Dragonfly Endpoint[10]。 Fluid[11]基于 JuiceFS[12]运行时通过 Dragonfly 下载数据，正在开发，预计 v2.1.1 版本可以使用。 Dragonfly 助力火山引擎 AIGC [13]推理业务 P2P 镜像加速。 社区中已经有很多案例，基于 P2P 技术使用 Dragonfly 分发 AI 场景中的文件。在 AI 推理阶段，推理服务并发下载模型可以有效通过 Dragonfly P2P 缓解模型仓库的带宽压力，从而提高整体下载速度。在 KubeCon + CloudNativeCon + Open Source Summit China 2023[14]社区联合快手做一次分享，主题是《Dragonfly: Intro, Updates and AI Model Distribution in the Practice of Kuaishou - Wenbo Qi, Ant Group \u0026amp;amp; Zekun Liu, Kuaishou Technology》[15]，感兴趣的同学可以关注。 维护者 社区新增四位 Maintainer，希望能够帮助更多的 Contributor 参与到社区的工作中。\n 黄逸炀[16]：就职于火山引擎，主要专注于社区代码工程方面。 温满祥[17]：就职于百度，主要专注于社区代码工程方面。 Mohammed Farooq[18]：就职于 Intel，主要专注于社区代码工程方面。 许洲[19]：大连理工大学在读博士，主要专注于智能调度算法方面。 其他 版本更新包含的更多细节可以参考👇 CHANGELOG：https://github.com/dragonflyoss/Dragonfly2/blob/main/CHANGELOG.md\n相关链接 [1].Xinxin Zhao Github：\nhttps://github.com/1zhaoxinxin\n[2].Dragonfly Console Github：\nhttps://github.com/dragonflyoss/console\n[3].Dragonfly 官网： https://d7y.io\n[4].Dragonfly Console Release v1.0.0： https://github.com/dragonflyoss/console/tree/release-1.0.0\n[5].Manager Console 文档： https://d7y.io/docs/reference/manage-console\n[6].Triton Inference Server： https://github.com/triton-inference-server/server\n[7].issue #2185： https://github.com/dragonflyoss/Dragonfly2/issues/2185\n[8].Dragonfly Repository Agent Github： …","date":1691478000,"description":"Dragonfly 发布 v2.1.0 版本！","dir":"blog/dragonfly-v-2-1-0-release/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d4047f2f246c79313ab932a67dc6b444","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-v-2-1-0-release/","publishdate":"2023-08-08T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/dragonfly-v-2-1-0-release/","summary":"Dragonfly 最新正式版本 v2.1.0 已经发布！ 感谢赵鑫鑫[1]同学帮助重构 Console 代码，并且提供全新的 Console[2]控制台方便用户可视化操作 P2P 集群。欢迎访问 d7","tags":["SOFAStack"],"title":"Dragonfly 发布 v2.1.0 版本！","type":"blog","url":"/sofastack.tech/blog/dragonfly-v-2-1-0-release/","wordcount":1667},{"author":null,"categories":"SOFAStack","content":" Dragonfly 项目简介 Dragonfly 是一款基于 P2P 的镜像加速和文件分发系统。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在 AI 数据分发、文件分发、日志分发和镜像分发等领域被大规模使用。在解决大规模文件分发场景下有着无可比拟的优势。\n自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF Sandbox 级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为 Incubating 级别的托管项目。\nSOFAChannel#34 就邀请到了蚂蚁集团技术专家、Dragonfly 项目 Maintainer 戚文博跟大家分享 Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的实践。\n直播介绍 《Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的加速实践》\n2023 年 8 月 9 日（周三）\n19：00 - 20：00\n「嘉宾简介」\n戚文博（花名：百蓦）\n蚂蚁集团技术专家\nDragonfly Maintainer\n「议题简介」\n在 AI 场景下，训练和推理两个过程中，数据的传输往往是关键瓶颈之一。Dragonfly \u0026amp;amp; Nydus 作为 CNCF Incubating 项目，其利用 P2P 技术和按需加载能力，能够大幅度提升数据传输的速度和效率，从而提高 AI 计算的整体效率和性能。这使得 AI 算法的训练和推理过程中数据传输更加高效和可靠，为 AI 技术的应用提供了强有力的支撑。\n「听众收获」\n1、了解并走进 Dragonfly 项目；\n2、镜像加速领域相关技术的分享；\n3、Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的实践。\n直播预约 钉钉搜索：22880028764\n钉钉群同步直播，讲师在线答疑\nB 站直播预约 有机会获得 Dragonfly 精美贴纸～\nhttps://www.bilibili.com/opus/825142485488500792?spm_id_from=444.41.0.0\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1690959600,"description":"Dragonfly \u0026 Nydus 作为 CNCF Incubating 项目，其利用 P2P 技术和按需加载能力，能够大幅度提升数据传输的速度和效率，从而提高 AI 计算的整体效率和性能。","dir":"activities/sofa-channel-34/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0b819934f2ea5ec73a3cbc2f8470a87f","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-34/","publishdate":"2023-08-02T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-34/","summary":"Dragonfly 项目简介 Dragonfly 是一款基于 P2P 的镜像加速和文件分发系统。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在 AI 数据分发、文件分发、日志","tags":["SOFAStack"],"title":"SOFAChannel#34《Dragonfly \u0026 Nydus 在 AI 场景下的加速实践》——Dragonfly 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-34/","wordcount":663},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n*本文* 807 字 阅读 3分钟\n在本系列的第 5 篇《MoE 系列（五）｜Envoy Go 扩展之内存安全》中我们介绍了内存安全如何实现。第 6 篇《MoE 系列（六）｜ Envoy Go 扩展之并发安全》又谈到了并发场景下的内存安全。\n今天，我们来到了安全性的最后一篇：沙箱安全，也是相对来说，最简单的一篇。\n沙箱安全 所谓的沙箱安全，是为了保护 Envoy 这个宿主程序的安全，也就是说，扩展的 Go 代码运行在一个沙箱环境中，即使 Go 代码跑飞了，也不会把 Envoy 搞挂。\n具体到一个场景，也就是当我们使用 Golang 来扩展 Envoy 的时候，不用担心自己的 Go 代码写得不好，而把整个 Envoy 进程搞挂了。\n那么目前 Envoy Go 扩展的沙箱安全做到了什么程度呢？\n简单来说，目前只做到了比较浅层次的沙箱安全。不过，也是实用性比较高的一层。\n严格来说，Envoy Go 扩展加载的是可执行的机器指令，是直接交给 CPU 来运行的，并不像 Wasm 或者 Lua 一样由虚拟机来解释执行。所以，理论上来说，也没办法做到绝对的沙箱安全。\n实现机制 目前实现的沙箱安全机制，依赖的是 Go Runtime 的 recover 机制。\n具体来说，Go 扩展底层框架会自动地，或者（*代码里显示启动的协程*）依赖人工显示地，通过 defer 注入我们的恢复机制。所以，当 Go 代码发生了崩溃的时候，则会执行我们注入的恢复策略，此时的处理策略是，使用 500 错误码结束当前请求，而不会影响其他请求的执行。\n但是这里有一个不太完美的点，有一些异常是 recover 也不能恢复的，比如这几个：\nConcurrent map writes Out of memory Stack memory exhaustion Attempting to launch a nil function as a goroutine All goroutines are asleep - deadlock 好在这几个异常，都是不太容易出现的。唯一一个值得担心的是 Concurrent map writes，不熟悉 Go 的话，还是比较容易踩这个坑的。\n所以，在写 Go 扩展的时候，我们建议还是小心一些，写得不好的话，还是有可能会把 Envoy 搞挂的。\n当然，这个也不是一个很高的要求，毕竟这是 Gopher 写 Go 代码的很常见的基本要求。\n好在大多常见的异常，都是可以 recover 恢复的，这也就是为什么现在的机制，还是比较有实用性。\n未来 那么，对于 recover 恢复不了的，也是有解决的思路：\n比如 recover 恢复不了 Concurrent map writes，是因为 Runtime 认为 map 已经被写坏了，不可逆了。\n那如果我们放弃整个 runtime，重新加载 so 来重建 runtime 呢？那影响面也会小很多，至少 Envoy 还是安全的，不过实现起来还是比较地麻烦。\n眼下比较浅的安全机制，也足够解决大多数的问题了。\n了解更多…\nMOSN Star 一下🌟：\nhttps://github.com/mosn/mosn\n推荐阅读： MoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（四）｜Go 扩展的异步模式\n","date":1690873200,"description":"MoE 系列（七） - Envoy Go 扩展之沙箱安全","dir":"blog/moe-series (7) |envoy-go-extension-sandbox-security/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5f4a7e3872dbe224f8ed9d420af546dc","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","publishdate":"2023-08-01T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 *本文* 807 字 阅读 3分钟 在本","tags":["SOFAStack"],"title":"MoE 系列（七） - Envoy Go 扩展之沙箱安全","type":"blog","url":"/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","wordcount":1055},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 1313 字 阅读 4 分钟\n前一篇介绍了 Envoy Go 扩展的内存安全，相对来说，还是比较好理解的，主要是 Envoy C++ 和 Go GC 都有自己一套的内存对象的生命周期管理。这篇聊的并发安全，则是专注在并发场景下的内存安全，相对来说会复杂一些。\n并发的原因 首先，为什么会有并发呢🤔️\n本质上因为 Go 有自己的抢占式的协程调度，这是 Go 比较重的部分，也是与 Lua 这类嵌入式语言区别很大的点。\n细节的话，这里就不展开了，感兴趣的可以看这篇👉cgo 实现机制 - 从 C 调用 Go\n这里简单交代一下，因为 C 调用 Go，入口的 Go 函数的运行环境是，Goroutine 运行在 Envoy worker 线程上，但是这个时候，如果发生了网络调用这种可能导致 Goroutine 挂起的，则会导致 Envoy worker 线程被挂起。\n所以，解决思路🪄就是像 Go 扩展的异步模式[1]中的示例一样，新起一个 Goroutine，它会运行在普通的 Go 线程上。\n那么此时，对于同一个请求，则会同时有 Envoy worker 线程和 Go 线程，两个线程并发在处理这个请求，这个就是并发的来源。\n但是，我们并不希望用户操心这些细节，而是在底层提供并发安全的 API，把复杂度留在 Envoy Go 扩展的底层实现里。\n并发安全的实现 接下来，我们就针对 Goroutine 运行在普通的 Go 线程上这个并发场景，来聊一聊如何实现并发安全。\n对于 Goroutine 运行在 Envoy 线程上，因为并不存在并发冲突，这里不做介绍。\n写 header 操作 我们先聊一个简单的，比如在 Go 里面通过 header.Set 写一个请求头。\n核心思路是，是通过 dispatcher.post，将写操作当做一个事件派发给 Envoy worker 线程来执行，这样就避免了并发冲突。\n读 header 操作 读 header 则要复杂不少，因为写不需要返回值，可以异步执行，读就不行了，必须得到返回值。\n为此，我们根据 Envoy 流式的处理套路，设计了一个类似于所有权的机制。\nEnvoy 的流式处理，可以看这篇👉 搞懂 http filter 状态码[2]。\n简单来说，我们可以这么理解，当进入 decodeHeaders 的时候，header 所有权就交给 Envoy Go 的 C++ 侧了，然后，当通过 cgo 进入 Go 之后，我们会通过一个简单的状态机，标记所有权在 Go 了。\n通过这套设计/约定，就可以安全地读取 header 了，本质上，还是属于规避并发冲突。\n为什么不通过锁来解决呢？因为 Envoy 并没有对于 header 的锁机制，C++ 侧完全不会有并发冲突。\n读写 data 操作 有了这套所有权机制，data 操作就要简单很多了。\n因为 header 只有一份，并发冲突域很大，需要考虑 Go 代码与 C++ 侧的其他 filter 的竞争。\ndata 则是流式处理，我们在 C++ 侧设计了两个 buffer 对象，一个用于接受 filter manager 的流式数据，一个用于缓存交给 Go 侧的数据。\n这样的话，交给 Go 来处理的数据，Go 代码拥有完整的所有权，不需要考虑 Go 代码与 C++ 侧其他 filter 的竞争，可以安全地读写，也没有并发冲突。\n请求生命周期 另外一个很大的并发冲突，则关乎请求的生命周期，比如 Envoy 随时都有可能提前销毁请求，此时 Goroutine 还在 Go thread 上继续执行，并且随时可能读写请求数据。\n处理的思路是：\n并没有有效的办法，能够立即 kill Goroutine，所以，我们允许 Goroutine 可能在请求被销毁之后继续执行。\n但是，Goroutine 如果读写请求数据，Goroutine 会被终止，panic + recover（*recover 细节我们下一篇会介绍*）。\n那么，我们要做的就是，所有的 API 都检查当前操作的请求是否合法，这里有两个关键：\n每请求有一个内存对象，这个对象只会由 Go 来销毁，并不会在请求结束时，被 Envoy 销毁，但是这个内存对象中保存了一个 weakPtr，可以获取 C++ filter 的状态。\n通过这个机制，Go 可以安全地获取 C++ 侧的 filter，判断请求是否还在。\n同时，我们还会在 onDestroy，也就是 C++ filter 被销毁的 Hook 点；以及 Go thread 读写请求数据，这两个位置都加锁处理，以解决这两个之间的并发冲突。\n最后 对于并发冲突，其实最简单的就是，通过加锁来竞争所有权，但是 Envoy 在这块的底层设计并没有锁，因为它根本不需要锁。\n所以，基于 Envoy 的处理模型，我们设计了一套类似所有权的机制，来避免并发冲突。\n所有权的概念也受到了 Rust 的启发，只是两者工作的层次不一样，Rust 是更底层的语言层面，可以作用于语言层面，我们这里则是更上层的概念，特定于 Envoy 的处理模型，也只能作用于这一个小场景。\n但是某种程度上，解决的问题，以及其中部分思想是一样的。\n了解更多…\nMOSN Star 一下🌟：\nhttps://github.com/mosn/mosn\n参考链接 [1]Go 扩展的异步模式:\nhttps://uncledou.site/2023/moe-extend-envoy-using-golang-4/\n[2]搞懂 http filter 状态码:\nhttps://uncledou.site/2022/envoy-filter-status/\n推荐阅读 MoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（四）｜Go 扩展的异步模式\nMoE 系列（五）｜Envoy Go 扩展之内存安全\n","date":1689663600,"description":"MoE 系列（六）｜Envoy Go 扩展之并发安全","dir":"blog/moe-series（6）｜envoy-go-extensions- concurrency- security/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1689663600,"objectID":"a7747e9132ae0170156edbe2e8b8b0f2","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","publishdate":"2023-07-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 1313 字 阅读 4 分钟 前一篇介","tags":["SOFAStack"],"title":"MoE 系列（六）｜ Envoy Go 扩展之并发安全","type":"blog","url":"/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","wordcount":1822},{"author":null,"categories":"SOFAStack","content":" Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开发。\n二方库升级 SOFABoot 4.0 基于 Spring Boot 3.0 与 Spring Framework 6 构建。在 Spring Boot 3.0 与 Spring Framework 6 引入的二方库升级列表可参考文档👉 Spring Boot 3.0 Release Notes\n在 SOFABoot 4.0 引入的二方库升级列表如下：\n Spring Boot 3.0.5 Spring Cloud 4.0.0 Spring Cloud Stream 3.2.6 SOFA Common tools 2.0.0 SOFATracer 4.0.0 SOFARPC 5.10.0 FastJson 1.2.83 Guava 31.1-jre Grpc 1.51.1 Grpc common protos 2.11.0 Druid 1.2.16 ASM 9.4 Javassist 3.29.2-GA Curator 4.3.0 Dubbo 3.1.8 Nacos 2.0.3 Swagger 1.6.7 Swagger2 2.2.8 基于 Jakarta EE Spring Boot 3.0 中依赖 Jakarta EE 规范的部分已经升级到了 Jakarta EE 10 版本。例如，使用 Servlet 6.0 和 JPA 3.1 规范。因此，部分包的命名空间也进行了替换，例如你应该使用：\n✅jakarta.servlet.Filter\n而不是 javax.servlet.Filter。\n同时，如果你使用了自己的依赖提供 Jakarta EE 规范的 API，需注意进行对应的依赖升级，例如你应该使用：\n✅jakarta.servlet:jakarta.servlet-api\n而不是 javax.servlet:javax.servlet-api。\n可参考文档：Migrate to Jakarta EE 9 来修改 Jakarta 相关的包名以及依赖。\n支持 SOFAArk 2.0 SOFAArk 2.0 模式是 SOFAArk 框架的整体优化版本，相较于 SOFAArk 1.0 模式，它的整体优化思路和原则是 Ark Master Biz 保持和原生 SOFABoot 保持一致，弱化复杂的 Ark Plugin 类管控机制，将 Ark Plugin 与 Master Biz 合并。使得 Ark Master Biz 和原生 SOFABoot 应用的启动方式、类加载方式保持一致，大大降低了 Master Biz 应用的编程难度。\nSOFABoot 4.0 版本不再支持 SOFAArk 1.0 模式，如果你想要在 SOFABoot 应用中使用 SOFAArk 2.0 模式，可以按照以下步骤进行操作：\n1、在项目中引入 SOFAArk 组件依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;ark-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2、添加 Spring Boot 的 Package 插件\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 3、启动应用\n 方式一： IDEA 启动，注意需要添加启动参数：-Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二： 命令行启动，先运行 mvn clean package 命令进行打包，生成 ${bizName}-${bizVersion}-ark-biz.jar 的可执行文件，然后在终端运行以下启动参数：\njava -jar -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName} ${bizName}-${bizVersion}-ark-biz.jar\n支持场景化的按配置加载能力 通常情况下，应用在不同的场景下可能需要开启或者关闭不同的功能，Spring Boot 提供了丰富的 Configuration 动态配置能力[4] 能力以支持应用在不同的场景下加载不同的 Bean。\nSOFABoot 在此基础上，对 org.springframework.context.ApplicationContextInitializer 等扩展点进行了增强，支持通过统一风格的配置定制各类 Bean 以及扩展点的开启与关闭，并提供了定制模版配置的开启方式以降低应用配置项的复杂度。\n 通过： com.alipay.sofa.boot.autoconfigure.condition.ConditionalOnSwitch 注解为 Bean 添加按配置开启能力：\n@Configuration(proxyBeanMethods = false) @ConditionalOnSwitch(id=\u0026amp;quot;sample\u0026amp;quot;) public class SampleConfiguration { @Bean public SampleBean sampleBean() { return new SampleBean(); } } 添加：\nsofa.boot.switch.bean.sample.enabled=false 配置后，SampleConfiguration 配置类将不再加载。\n 通过继承： …","date":1689058800,"description":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","dir":"blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2a9d6f15f257293795df8dec9fbc5130","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","publishdate":"2023-07-11T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","summary":"Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开","tags":["SOFAStak"],"title":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","type":"blog","url":"/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","wordcount":3757},{"author":null,"categories":"SOFAStack","content":" 文｜魏陈豪（花名：无陈 Sam)\n蚂蚁集团 SOFAStack 产品专家\n本文 2966 字 阅读 8 分钟\n序言 今天给大家带来一篇 Seata-DTX[1] 商业版分布式事务在金融行业如何保证事务一致性的实践介绍。从一个全局视角出发看看一致性的保证、分别有哪些节点，事务组件在其中处在一个什么位置、担任什么工作。\n分布式系统下的事务问题阐述 云原生应用以分布式系统为主，应用会被切分到多个分布式的微服务系统下。拆分一般分为水平拆分和垂直拆分，这并不仅仅单指对数据库或者缓存的拆分，主要是表达一种分而治之的思想和逻辑。\n分布式系统的底层无法逃离“CAP 的不可能三角”*（C: Consistency，一致性；A: Availability，可用性；P: Partition Tolerance，分区容忍性）*。CAP 原理证明，任何分布式系统只可同时满足以上两点，无法三者兼顾。而分布式的服务化系统都需要满足分区容忍性，那么必须在一致性和可用性之间进行权衡。\n如果网络发生异常情况，导致分布式系统中部分节点之间的网络延迟不断增大，可能会导致分布式系统出现网络分区。复制操作可能会被延后，如果这时我们的使用方等待复制完成再返回，则可能导致在有限时间内无法返回，就失去了可用性；如果使用方不等待复制完成，而在主分片写完后直接返回，则具有了可用性，但是失去了一致性。\n图 1 CAP 理论\n图片出处：https://lushunjian.github.io/blog/2018/06/20/CAP%E7%90%86%E8%AE%BA/\n金融机构对一致性的诉求 对金融机构而言，架构层面的高可用和业务层面的强一致性，几乎同样重要。这就需要金融级云原生能够很好地平衡“CAP 的不可能三角”，需要尽可能兼顾业务强一致与系统高可用。\n但是“一致性挑战”在分布式系统中绝不仅仅是一个数据库问题，而是一个大的话题。其涵盖分布式系统的各个层面：事务一致性、节点一致性、系统间业务一致性、消息幂等一致性、缓存一致性、跨 IDC 一致性等等。所以也需要云原生架构有一系列技术能够应对金融级对一致性的严苛挑战。\n一致性控制的几个重要维度 这里挑选几个常见的金融场景下需要解决的一致性维度进行阐述。\n事务级：事务级别的一致性控制需要根据不同的金融场景选择合适的分布式事务模式。在我们针对 Seata-DTX 的客户进行调研后，发现大多数客户在平衡成本和性能后，基于 SAGA 和 TCC 是目前金融机构比较常用的两种分布式事务模式。SAGA 模式对应用实现侵入性更小，但基于补偿事务来保障一致性的设计、前后步骤执行过程中不保证事务隔离性；而 TCC 模式能做到比较好的事务隔离性，但需要应用层感知更多的复杂度。\n对于事务流程中部分不需要同步返回结果的节点，为提高执行效率可采用异步消息队列实现，对于一些事务流程较长的场景可明显降低事务实现复杂度、削峰填谷。典型场景如客户购买理财场景简化分为存款账户扣款和理财账户入账两个步骤，若选用 SAGA 模式，存款账户成功扣款后、理财账户入账失败，客户会看到“钱已付、货没到”的中间异常状态，需要系统进行冲正存款账户扣款来保障事务一致性。如选用 TCC 模式，先后完成存款账户扣款、理财账户入账的逻辑处理，各自需要存款系统和理财系统记录逻辑处理的状态，二者均成功后再发起统一提交。\n数据库级：接下来是数据库层面，金融场景下对于数据不丢有着极致的要求：一方面需要在同城、异地多个机房保存多个副本，另一方面需要在多个副本之间实现数据同步，Seata-DTX 的高可用也是依赖数据库之间的数据同步进行保障的。整体作用是以防一个 Seata-DTX 事务集群宕机后，切换到另外一套 Seata-DTX 事务集群后，可以恢复到正在进行中的事务记录，保障同城分布式事务的 RPO 为零、异地 RPO 接近零。数据库同步中，如果使用的是分布式事务库，分布式数据库一般通过对 Paxos 的支持来实现跨多服务器，甚至跨多中心的数据一致性保证。\n机房级：跨机房的路由能力、异常事务的跨机房恢复能力。发生机房故障时，数据库需要能够切到同城/异地的副本、并保障 RPO 为零，配合应用层的交易路由切换，完成机房级容灾切换、恢复业务。期间因机房故障导致的部分交易事务流程中断，分布式事务组件需要具备自动恢复能力，重新启动中断的事务流程按事先设定的业务规则向前完成或向后冲正。\n真实金融客户案例 以某资产规模超过 2 万亿元的省级农信为例，来看一下在核心整体下移的过程中，如何使用事务、配合数据库，机房容灾进行一致性控制。\n首先介绍一下整体的业务架构，在新核心平台中，大致可以分为产品服务层、交易中心层、交易中台层，如图 1 所示。交易中心收口所有的交易流程，对产品服务提供交易能力。最下面是交易原子能力层，主要包含 8 个中台，中台不直接对上提供服务，由交易中心统一处理。整个交易中心的能力，都基于服务编排构建，在编排流程中使用 SAGA 事务进行流程一致性控制。\n图 2 分布式新核心下移平台分层架构\n以贷款产品为例：整体的贷款支取、还款等长流程在信贷产品系统中，由 SAGA 事务进行串联，核心的资金交换部分由 TCC 事务把控一致性，做到对整体长流程里多个应用实现较小的侵入性。但基于补偿事务来保障一致性的设计、前后步骤执行过程中不保证事务隔离性，因此用 TCC 模式来处理对隔离性有较强诉求的核心资金交换服务，如图 3 所示。\n图 3 核心下移智能贷款系统流程\n如下图 4 是上述图 3 信贷产品中的还贷流程 TCC 流程示例。启动 TCC 事务后，使用 try 先尝试锁定客户账户余额，锁定成功后，等待二阶段提交。尝试 try 换贷款利息，锁定成功。整体提交事务，进行二阶段的扣账 confirm，以及还利息 confirm。\n图 4 核心下移智能贷款 TCC 流程\n事务层面的一致性进行了保证后，针对客户的 2 地机房进行事务的高可用部署，如图 5 所示。\n图 5 金融级云原生分布式事务部署架构\nConsole 是分布式事务的配置控制台，用户访问时通过 VIP 路由到不同机房的 console，数据写入到主 DB，主备 DB 数据实时同步。\nSeata-DTX Server 为分布式事务异库模式下的事务控制器和事务恢复器。其主要是记录事务日志，发起二阶段调用以及异常事务的恢复任务。\n业务应用用过 VIP 获取 Seata-DTX Server 对应的 IP。事务发起方发起事务时，事务日志都写入到主 DB 中，数据同步到备 DB。\n当福州 IDC 宕机或者断电时，流量会全部路由到上海 IDC。备数据库中因为有主 DB 的所有事务记录，当控制台查看事务数据和发起恢复事务任务时，仍然能正常执行。（当然可能会有人问这个情况下会不会频繁出现跨机房的分布式事务影响性能，此处负载均衡会基于入口流量的单元信息，自动调拨流量到对应的机房。此处不过多进行阐述。）\n综上可以看出，当前 Seata-DTX 的架构设计中，不单单是在事务层面去控制一致性。当有多个地域，多个副本时，可能需要结合数据库保证事务数据的一致。在多机房的情况下，需要依赖容灾能力，保证交易事务的流程可恢复。 …","date":1687849200,"description":"Seata-DTX｜分布式事务金融场景案例介绍","dir":"blog/seata-dtx｜distributed-transaction-financial-scenario-case-introduction/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1687849200,"objectID":"352eb80ff974af35f8069ba6c958fede","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","publishdate":"2023-06-27T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","summary":"文｜魏陈豪（花名：无陈 Sam) 蚂蚁集团 SOFAStack 产品专家 本文 2966 字 阅读 8 分钟 序言 今天给大家带来一篇 Seata-DTX[1] 商业版分布式事务在金融行业如何保证事务一致性的实践介绍。","tags":["SOFAStack"],"title":"Seata-DTX｜分布式事务金融场景案例介绍","type":"blog","url":"/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","wordcount":2760},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nLayotto：\n主题： Layotto 社区会议\n时间： 06 月 28 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入： +862162681677（中国大陆）+8657128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/NhOf1RUNqwL\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components #888 Support Pod injection to deploy Layotto as a sidecar in Kubernetes #910 Develop a new component for Encryption API #952 「Layotto」：https://github.com/mosn/layotto/issues/953\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 21 日 14:00 - 15:00\n会议内容：\n 本次社区会议预告开源之夏课题审核通过，等待 6 月 26 日 公示； 为 Configure API 开发 Nacos 组件问题，目前已经进入解决的最后阶段； 支持 Pluggable Components 及关于支持 Pod 注入，目前皆已审核通过，等待公示； 新增 Develop a new component for Encryption API 组件，相关任务已发布至社区群，感兴趣同学可留言加入其中。 「Layotto」：https://github.com/mosn/layotto/issues/953\n「会议回放」：https://www.bilibili.com/video/BV1kX4y1i75R/?spm_id_from=333.337.search-card.all.click\u0026amp;amp;vd_source=5dab7f4bd190defb59dcf6e727539b24\nSOFAStack 社区本周贡献\n本周推荐阅读\nSOFAStack 的下一个五年\nMOSN 反向通道详解\nSeata Saga 模式快速入门和最佳实践\n生产环境可用的 Seata-go 1.2.0 来啦！！！\n","date":1687503600,"description":"SOFA Weekly｜Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-20230623/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c0b300d2a38604aa46274b6323f27af1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230623/","publishdate":"2023-06-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230623/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230623/","wordcount":869},{"author":null,"categories":"SOFAStack","content":" 文｜宋顺（GitHub ID：nobodyiam)\nSOFAStack 社区开源负责人\n蚂蚁集团高级技术专家\n本文 3861 字 阅读 11 分钟 01 回顾开源这五年 回想起 2018 年 4 月 19 日 SOFAStack 首次开源，当时的官宣文章中就提到了我们开源的初心：\n期望通过逐步向社区开源 SOFA 中各个组件，从而一方面帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，另一方面也是期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固。\n所以这几年我们也是围绕着这个初心把 SOFAStack 体系的各个产品逐渐开源，包括首批开源的 SOFABoot、SOFARPC、SOFAArk，以及后来的 SOFARegistry、SOFAJRaft、Seata 等。同时我们也孵化了 MOSN 社区，开源了云原生网络代理 MOSN 以及应用运行时 Layotto。这些产品也是代表着 SOFAStack 在金融级云原生领域的沉淀和积累，目前已经在上百家企业中生根发芽。\n图 1 - 产品开源时间线\n我们再来看几个数字，在这 5 年中，我们举办了 18 场 Meetup，开展了 32 场直播分享，目前在 GitHub 组织层面有 438 名贡献者以及 3W 的 Star。\n图 2 - 开源 5 年的几个数字\n除了在项目上收获了不少贡献者和 Star 外，我们也逐渐地对开源有了更为深刻的认识。\n以开源指标为例，我们的初心是为了帮助更多机构和合作伙伴完成金融分布式转型，我们一开始最为关注的指标是用户数；但因开源的特殊性，我们无法直接获取实际的用户数，所以采用了 GitHub 的 Star 作为衡量指标。\n我相信这也是很多开源项目常见的第一反应，后期大家其实也发现了一些问题。举例来说，有些开源项目为了完成指标，采取了点 Star 送礼物等行为。这些虽然没有在我们的项目上发生，我们仍觉得有违开源初心，就放弃了 Star 数作为核心的指标。\n图 3 - Star 数作为衡量指标\n另一个开源项目常用的衡量指标是贡献者数量，很多开源项目是没有商业公司支撑的。为了项目的长期发展，需要持续的吸引新的贡献者加入，从而为社区带来活力。\n我们在放弃 Star 数指标后，把重心放在了贡献者数量上，会为新贡献者提供一些简单的任务，使他们能更快的融入社区，成为潜在的长期贡献者。\n不过和 Star 指标类似，在过程中我们也发现其它社区中出现了一些不好的现象。比如故意留一些明显的 bug，或者提供一些修改错别字的任务来刷贡献者数量，我们认为这些也是有违开源初心的。\n图 4 - Contributor 数作为衡量指标\n那么，我们该如何对待开源呢？\n我脑海中想起了 Envoy 作者 Matt Klein 在 Envoy 开源五周年时说的一句话：成功的开源软件就像创办一个企业。\n图 5 - 成功的开源软件就像创办一个企业\n其实开源项目和创业很类似，首先你需要有一个好的点子，然后去吸引人才一起加入来提升产品能力，再通过一些营销手段对项目做推广来获取客户，而后持续迭代改进。\n对企业而言，员工和客户固然很重要，不过我认为最核心的还是产品，只有一个定位准确、解决实际问题的产品才能受到市场欢迎，从而获取资金维持公司的运营。\n在开源项目上，用户对应着企业的客户，是提供场景的驱动力来源；贡献者对应着企业的员工，属于资源投入，是推动力来源；而产品才是真正能解决用户问题的，是整个开源飞轮中最为核心的部分。所以 Star 数和贡献者数量都只是过程指标，核心还是要提升产品力，不能本末倒置。\n图 6 - 开源飞轮\n02 展望下一个五年 聊完了过去五年的过程和收获，对 SOFAStack 而言，下一个五年的主要方向就比较明确：我们还是会着重放在产品力的提升上，希望能持续解决分布式场景中的核心问题。\n那核心问题究竟是哪些呢？我想起了泛在计算的提出者 Mark Weiser 曾经说过的一句话：最卓越的技术是那些“消失不见的”技术。\n图 7 - 消失不见的技术\n对这个判断，我也是深以为然。在日常生活中，这类案例也是比比皆是：比如电，我们现在都是即插即用，以至于已经不感知电力背后的复杂基础设施，类似的还有水、煤气等。它们背后都有着复杂的基础设施在支撑，经过了数十年的技术发展之后，已经非常稳定可靠，交互也非常简单，所以这些技术就像是“消失不见”一样。\n图 8 - 水电煤随开随用\n然而在我们实际的研发场景中，业务研发对基础设施的感知还远没有达到无感的地步。\n比如在研发态，我们除了要关注业务逻辑之外，还会经常被中间件 SDK 升级所打扰，在使用云产品时还得感知多云的差异。\n在运维态，除了要关注发布时的业务表现，还要时刻去关注资源状况。在其容量不足的时候要申请资源做扩容，在业务低峰的时候要缩容服务来节约成本。\n可以说，技术基础设施的存在感越强，研发运维的效率就越低，无法把精力集中在业务的创新上。\n图 9 - 实际研发场景\n那么，我们该如何才能让技术基础设施也消失不见呢？\n我们知道对微服务而言，可以通过服务网格来解耦业务逻辑和 RPC 通用能力，从而实现独立演进、透明升级。\n图 10 - Service Mesh 演进架构\n项目地址：https://github.com/mosn/mosn\n在实际场景中，除了微服务之外，业务往往还会使用其它的中间件能力。例如动态配置、消息、缓存、数据库等，如何降低这些中间件和业务应用的耦合是一个新的问题。另外，在多语言场景，我们仍然要为每种语言开发一套轻量 SDK 来实现通信协议和编解码逻辑，这部分也有很高的成本。所以我们如何进一步去降低多语言的支持成本是另一个亟待解决的问题。\n为此，我们也是借鉴了 Dapr 的应用运行时思路，基于 MOSN 设计开发了 Layotto，在下层对接了各种基础服务；在上层为应用提供了统一的、具备各种分布式能力的 API。\n开发者不需要再关心底层各种组件的实现差异，只需要关注应用本身需要哪些能力。比如调用 RPC、发送消息，然后通过 gRPC 调用对应的 API 即可。这样就可以彻底和底层基础服务解绑，同时也是极大地降低了多语言的支持成本。\n图 11 - Layotto 架构\n项目地址：https://github.com/mosn/layotto\n通过服务网格和应用运行时，我们解决了研发态对中间件 SDK 升级、多云差异感知等负担，我们再来看下如何通过 Serverless 技术来降低运维态的负担。\n我们知道业务研发一般是从需求到设计、开发、测试，最后发布生产的一个循环过程，其中不少业务还会出现多个迭代并行开发的场景。然而发布生产要求是串行的，就会导致迭代堵车的现象，后一个迭代必须得等前一个迭代发完才能开始发布，整体效率比较低。\n除此之外，随着业务重要性的提升，发布流程也会变重，发布周期短则几个小时，长则几天甚至几周也屡见不鲜。同时，业务逻辑的增加也会导致应用启动变慢，启动一个系统往往需要几十分钟，导致应用扩容等操作响应迟缓。\n图 12 - 研发迭代形式\n我们经过分析，发现不少应用代码本质上是可以分成两层的。一层是公共逻辑和核心模 …","date":1687244400,"description":"SOFAStack 的下一个五年","dir":"blog/the-next-five-years-of-sofastack/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"434c6a58fe31dc8becf81b773891362a","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-next-five-years-of-sofastack/","publishdate":"2023-06-20T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/the-next-five-years-of-sofastack/","summary":"文｜宋顺（GitHub ID：nobodyiam) SOFAStack 社区开源负责人 蚂蚁集团高级技术专家 本文 3861 字 阅读 11 分钟 01 回顾开源这五年 回想起 2018 年 4 月 19 日 SOFAStack 首","tags":["SOFAStack"],"title":"SOFAStack 的下一个五年","type":"blog","url":"/sofastack.tech/blog/the-next-five-years-of-sofastack/","wordcount":3990},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 21 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862162681677（中国大陆）+8657128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/f4KJsKNnxfN\n议题：\n 2023 开源之夏-课题汇总 #894 为 Configure API 开发 Nacos 组件 #921 Support Pluggable Components #888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910 「Layotto」：https://github.com/mosn/layotto/issues/949\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 14 日 14:00 - 15:00\n会议内容：\n本次社区会议预告开源之夏目前已进入社区审核阶段；关于为 Configure API 开发 Nacos 组件问题，根据社区同学在 issue 中的沟通互动，已取得新的进展；支持 Pluggable Components 目前预计已完成审核，月底会有所公示；关于支持 Pod 注入，目前已审核部分，需等待官网公示；网站钉钉群二维码已修复与更新，可正常使用。\n「Layotto」：https://github.com/mosn/layotto/issues/949\n「会议回放」：https://www.bilibili.com/video/BV1wm4y1i7hv/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFARPC 5.10.1 版本发布\n发布 SOFARPC 5.10.1 版本，主要变更如下:\n 支持修改 gRPC Message Size #1333 升级 Hessian 到 3.4.0 以支持部分 java.time 类的序列化 #1338 详细发布报告：https://github.com/sofastack/sofa-rpc/compare/v5.10.0...5.10.1\nSOFAStack 社区本周贡献\n本周推荐阅读\nSeata Saga 模式快速入门和最佳实践\n生产环境可用的 Seata-go 1.2.0 来啦\nMOSN 基于延迟负载均衡算法-走得更快，期待走得更稳\nMoE 系列（五）｜Envoy Go 扩展之内存安全\n","date":1686898800,"description":"SOFA Weekly｜SOFARPC 5.10.1 版本发布、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230616/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cda466451816463410fd13477709f561","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230616/","publishdate":"2023-06-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230616/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFARPC 5.10.1 版本发布、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230616/","wordcount":996},{"author":null,"categories":"SOFAStack","content":" 文｜王特 （花名：亦夏）\nEmail：yixia.wt@antgroup.com\n蚂蚁集团数据中间件核心开发\n本文4927 字 阅读 13 分钟\nSeata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。Seata 为用户提供了 AT、TCC、SAGA、XA 等多种事务模式，帮助解决不同业务场景下的事务一致性问题。\n本文主要介绍 Seata Saga 模式的使用以及最佳实践，围绕三个部分展开，第一部分是 Seata Saga 的简介、第二部分旨在快速介绍 Seata Saga 模式的使用方法并帮助大家入门，最后一部分将会给大家分享一些 Seata Saga 实践中的经验，帮助用户更快、更好得使用 Seata Saga 模式。\n1 Seata Saga 简介 1.1 Saga 模式 Saga 模式是分布式事务的解决方案之一，理念起源于 1987 年 Hector \u0026amp;amp; Kenneth 发表的 Sagas 论文。它将整个分布式事务流程拆分成多个阶段，每个阶段对应我们的子事务，子事务是本地事务执行的，执行完成就会真实提交。\n它是一种基于失败的设计，如上图可以看到，每个活动或者子事务流程，一般都会有对应的补偿服务。如果分布式事务发生异常的话，在 Saga 模式中，就要进行所谓的“恢复”，恢复有两种方式，逆向补偿和正向重试。比如上面的分布式事务执行到 T3 失败，逆向补偿将会依次执行对应的 C3、C2、C1 操作，取消事务活动的“影响”。那正向补偿，它是一往无前的，T3 失败了，会进行不断的重试，然后继续按照流程执行 T4、T5 等。\n根据 Saga 模式的设计，我们可以得到 Saga 事务模式的优缺点。\n优点：\n 子事务 （或流程） ，提交是本地事务级别的，没有所谓的全局锁，在长事务流程下，避免了长时间的资源锁定；另外这种流水线的处理模型天然符合阶段式信号处理模型，能发掘出更高的性能和吞吐。 正向服务和补偿服务都是交给业务开发实现的，所以 Saga 模式和底层数据库协议是无关的。XA/AT 模式可能依赖特定的数据库类型和版本，比如 MySQL 是 5.0 之后才支持的 XA，那么低版本的 MySQL 就不能适用到 XA 模式。 缺点：\n 也是因为正向服务和补偿服务都由业务开发者实现，所以业务上是有开发成本的，侵入性相对 XA/AT 打一个注解的方式会高很多。 因为一阶段子事务活动提交是本地事务级别的，所以 Saga 模式不保证隔离性。提交之后就可能“影响”其他分布式事务、或者被其他分布式事务所“影响”。例如：其他分布式事务读取到了当前未完成分布式事务中子事务的更新，导致脏读；其他分布式事务更新了当前未完成分布式事务子事务更新过的字段，导致当前事物更新丢失；还有不可重复读的场景等。 所以 Saga 模式的使用也需要考虑这些问题带来的“影响”。一般 Saga 模式的使用场景有如下几个：\n 长事务流程，业务上难以接受长时间的资源锁定，Saga 的特性使得它在长事务流程上处理非常容易； 业务性质上，业务可以接受或者解决缺乏隔离性导致的“影响”。例如部分业务只要求最终一致性，对于隔离性要求没有那么严格，其实是可以落地 Saga 模式的； 分布式事务参与者包含其他机构或者三方的服务，数据资源服务不是我们自身维护，无法提供 TCC 模式要求的几个接口。 1.2 Seata Saga 接下来我们来看看 Seata Saga 的实现。Saga 主流的实现分为两种：编排式和协调式。Seata Saga 的实现方式是编排式，是基于状态机引擎实现的。 状态机执行的最小单位是节点：节点可以表示一个服务调用，对应 Saga 事务就是子事务活动或流程，也可以配置其补偿节点，通过链路的串联，编排出一个状态机调用流程。在 Seata 里，调用流程目前使用 JSON 描述，由状态机引擎驱动执行，当异常的时候，我们也可以选择补偿策略，由 Seata 协调者端触发事务补偿。\n有没有感觉像是服务编排，区别于服务编排，Seata Saga 状态机是 Saga+服务编排，支持补偿服务，保证最终一致性。\n我们来看看一个简单的状态机流程定义：\n上方是一个 Name 为 reduceIncentoryAndBalance 的状态机描述，里面定了 ServiceTask 类型的服务调用节点以及对应的补偿节点 CompensateReduceInventory。\n看看几个基本的属性：\n Type：节点类型，Seata Saga 支持多种类型的节点。例如 ServiceTask 是服务调用节点 ServiceName/ServiceMethod：标识 ServiceTask 服务及对应方法 Input/Output：定义输入输出参数，输入输出参数取值目前使用的是 SPEL 表达式 Retry：控制重试流程 Catch/Next：用于流程控制、衔接，串联整个状态机流程 更多类型和语法可以参考 Seata 官方文档[1]，可以看到状态机 JSON 声明还是有些难度的，为了简化状态机 JSON 的编写，我们也提供了可视化的编排界面[2]，如下所示，编排了一个较为复杂的流程。\n话不多说，我们进入下面的实践环节。\n2 Seata Saga 使用入门 2.1 从 Seata 官网新人文档开始 Seata 分 TC、TM 和 RM 三个角色，TC （Server 端） 为单独服务端部署，TM 和 RM （Client 端） 由业务系统集成。\nServer 端存储模式 （store.mode） 现有 file、db、redis 三种 （后续将引入 Raft、MongoDB） ，file 模式无需改动，直接启动即可。\n 部署 Seata Server\n从新人文档，可以看出 Seata 还是传统的 CS 模型。首先我们需要部署 Seata Server 端。Server 端默认的存储模式时 file 模式，无需改动，直接执行 SpringBoot 启动类 main 方法即可启动 Seata Server。为了方便，本次演示就使用 file 模式启动，其他模式的启动方式可以参考新人文档的详细介绍。\n创建 Client 端测试应用\n同时我们需要创建一个客户端的测试应用，这里命名 seata-saga-test，测试应用使用 SpringBoot 框架，配置好 spring 的 aplication.pname 和 port，并且引入 seata-spring-boot-starter 依赖，完成 Client 端应用的搭建。\n2.2 从 Seata Saga 单元测试看起 一般了解一个框架的功能，建议是从入口的单元测试类开始看起。在 Seata 仓库中找到 Seata Saga 的 test 模块，从最外围的测试类 io.seata.saga.engine.StateMachineTests 看起 （一般开源项目最外围的测试类即是入口类） ：\n从上面的截图可以看出，入口测试方法主要分为三个部分：\n【1】处的 spring 配置文件声明了 StateMachineEngine Bean 以及对应的属性，【2】处也引用 …","date":1686726000,"description":"Seata Saga 模式快速入门和最佳实践","dir":"blog/seata-saga-model-quick-start-and-best-practices/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7287981b4eabf6ef5f22582a62cd69ff","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","publishdate":"2023-06-14T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","summary":"文｜王特 （花名：亦夏） Email：yixia.wt@antgroup.com 蚂蚁集团数据中间件核心开发 本文4927 字 阅读 13 分钟 Seata 是一款开源的","tags":["SOFAStack"],"title":"Seata Saga 模式快速入门和最佳实践","type":"blog","url":"/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","wordcount":3753},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n可信基础设施技术分论坛\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：6 月 14 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/f4KJsKNnxfN\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components#888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes#910 How to run layotto with congfig_mongo.json#932 「Layotto」：https://github.com/mosn/layotto/issues/949\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议 时间：06 月 07 日 14:00 - 15:00\n会议内容：\n本次社区会议讨论了开源之夏现阶段导师审核课题的情况，并同步最新进展情况；关于 support pluggable components 与 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes 两个课题，现阶段正常进行中，无风险存在；How to run layotto with congfig_mongo.json 的问题已经解决，具体的解决方案详情可看 issue 或 视频回放。\n「Layotto」：https://github.com/mosn/layotto/issues/937\n「会议回放」：https://www.bilibili.com/video/BV1Pu4y1f7oa/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFAStack 社区本周贡献\n","date":1686294000,"description":"SOFA Weekly｜可信基础设施技术分论坛、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230609/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c2b1e54167604c2f46d7caa6b28da98f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230609/","publishdate":"2023-06-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230609/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜可信基础设施技术分论坛、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230609/","wordcount":781},{"author":null,"categories":"SOFAStack","content":"文｜刘月财（GitHub ID：luky116)\n360 服务端开发专家\nSeata-go 项目负责人\n本文 2752 字 阅读 7 分钟\n发布概览\nSeata-go 1.2.0 版本支持 XA 模式。XA 协议是由 X/Open 组织提出的分布式事务处理规范，其优点是对业务代码无侵入。当前 Seata-go 的 XA 模式支持 MySQL 数据库。至此，Seata-go 已经集齐 AT、TCC、Saga 和 XA 四种事务模式，完成了与 Seata Java 的功能对齐。\nXA 模式的主要功能:\n 支持了 XA 数据源代理\n 支持了 XA 事务模式\n XA 相关的 Samples 可以参考示例：\nhttps://github.com/seata/seata-go-samples/tree/main/xa\n在本版本中还修复了近期大量用户在使用过程中提交的 issue。\n版本的主要更新如下\nFeature：\n[#467] 实现 XA 模式支持 MySQL\nhttps://github.com/seata/seata-go/pull/467\n[#534] 支持 Session 的负载均衡\nhttps://github.com/seata/seata-go/pull/534\nBugfix：\n[#540] 修复初始化 XA 模式的 bug\nhttps://github.com/seata/seata-go/pull/540\n[#545] 修复 XA 模式获取 db 版本号的 bug\nhttps://github.com/seata/seata-go/pull/545\n[#548] 修复启动 XA 时候会失败的 bug\nhttps://github.com/seata/seata-go/pull/548\n[#556] 修复 XA 数据源的 bug\nhttps://github.com/seata/seata-go/pull/556\n[#562] 修复提交 XA 全局事务的 bug\nhttps://github.com/seata/seata-go/pull/562\n[#564] 修复提交 XA 分支事务的 bug\nhttps://github.com/seata/seata-go/pull/564\n[#566] 修复使用 XA 数据源执行本地事务的 bug\nhttps://github.com/seata/seata-go/pull/566\nOptimize：\n[#523] 优化 CI 流程\nhttps://github.com/seata/seata-go/pull/523\n[#525] 将 Jackson 序列化重命名为 JSON\nhttps://github.com/seata/seata-go/pull/525\n[#532] 移除重复的代码\nhttps://github.com/seata/seata-go/pull/532\n[#536] 优化 go import 代码格式\nhttps://github.com/seata/seata-go/pull/536\n[#554] 优化 XA 模式的性能\nhttps://github.com/seata/seata-go/pull/554\n[#561] 优化 XA 模式的日志输出\nhttps://github.com/seata/seata-go/pull/561\nTest:\n[#535] 添加集成测试\nhttps://github.com/seata/seata-go/pull/535\nDoc:\n[#550] 添加 1.2.0 版本的改动日志\nhttps://github.com/seata/seata-go/pull/550\n英文版：https://github.com/seata/seata-go/releases/tag/v1.2.0\n致谢\n非常感谢以下 Contributors 的代码贡献。若有无意遗漏，请报告。\n@georgehao\nhttps://github.com/georgehao\n@luky116\nhttps://github.com/luky116\n@jasondeng1997\nhttps://github.com/jasondeng1997\n@106umao\nhttps://github.com/106umao\n@wang1309\nhttps://github.com/wang1309\n@iSuperCoder\nhttps://github.com/iSuperCoder\n@Charlie17Li\nhttps://github.com/Charlie17Li\n@Code-Fight\nhttps://github.com/Code-Fight\n@Kirhaku\nhttps://github.com/Kirhaku\n@Vaderkai\nhttps://github.com/VaderKai\n同时，我们收到了社区反馈的很多有价值的 issue 和建议，非常感谢大家。\n社区讨论\n加入钉钉群：\nSeata-go 社区群：33069364\nSeata-go 开发群：44816898\n未来展望\nSeata 社区近期与不少国内 Go 语言微服务框架以及 ORM 框架背后的开发社区达成合作，比如 GORM 框架，已经集成到了 Sample 中，后续会将更多的 ORM 框架集成在 Seata-go-samples 项目中。\nSeata-go-samples 集成到 Seata-go GitHub Actions 的集成测试环境，目前已经在进行中，用于测试每个 PR，保证系统的兼容性与稳定性。\nSeata-go 后续的 Saga 模式，计划采用 Temporal 框架来做服务编排，目前正在规划中，期待能给用户带来更实用便利的 Saga 使用体验。\n欢迎对开源感兴趣的朋友加入 Seata 开源建设中来。\n常用链接\nSeata：\nhttp://github.com/seata/seata\nhttps://github.com/seata/seata-php\nhttps://github.com/seata/seata-js\nhttps://github.com/seata/seata-go\nSamples：\nhttps://github.com/seata/seata-samples\nhttps://github.com/seata/seata-go-samples\n官网：\nhttps://seata.io/\n投稿\n欢迎大家将 Seata/Seata-go/Seata-php/Seata-js 相关的实践文章投稿至：https://www.yuque.com/fred-x/ngfgiz/le1h4u5kn0xyhhoh\nSeata Star 一下✨：\nhttps://github.com/seata/seata-go\n","date":1686034800,"description":"生产环境可用的 Seata-go 1.2.0 来啦！！！","dir":"blog/seata-go-1.2.0-available-for-production-environments-is-here/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7df64ba112ba3f76cfa911d05813d383","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","publishdate":"2023-06-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","summary":"文｜刘月财（GitHub ID：luky116) 360 服务端开发专家 Seata-go 项目负责人 本文 2752 字 阅读 7 分钟 发布概览 Seata-go 1.2.0 版本支持 XA 模式。XA 协议是由 X/Open 组织提","tags":["SOFAStack"],"title":"生产环境可用的 Seata-go 1.2.0 来啦！！！","type":"blog","url":"/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","wordcount":920},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区 活动时间：05 月 31 日，周三晚 19 点 活动形式：线上直播 资料下载：点击获取 B 站直播间地址：http://live.bilibili.com/21954520 B 站直播ID：21954520 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》 Occlum 是蚂蚁集团于 2019 年开源的机密计算操作系统，也是 Linux 基金会机密计算联盟官方项目，荣列 2021“科创中国”开源创新榜。2022 年 12 月 10 日，Occlum 正式发布 v1.0 版本。学术成果发表在 ASPLOS\u0026amp;rsquo;20。Occlum 可让复杂应用轻松获得机密计算能力，是目前业界最受欢迎的开源机密计算操作系统。\nSOFAChannel 第 33 期邀请到了 LibOS 项目的 Contributor 惠春阳来做分享，带大家了解机密计算，讲述 Occlum 如何借助 EDMM，获得更高的安全性、易用性和更极致的性能，成为更好的机密计算 Library OS。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 惠春阳（花名：三仟） 蚂蚁集团技术专家 Occlum 机密计算 LibOS 项目 Contributor 议程 直播回放 点击查看\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1685516400,"description":"SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区","dir":"activities/sofa-channel-33/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"eb7a144641c7fa0312314ecca5edb8cb","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-33/","publishdate":"2023-05-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-33/","summary":"概要 活动主题：SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区 活动时间：05 月 31 日","tags":["SOFAStack"],"title":"SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-33/","wordcount":642},{"author":null,"categories":"SOFAStack","content":" 前面几篇介绍了 Envoy Go 扩展的基本用法，接下来几篇将介绍实现机制和原理。\nEnvoy 是 C++ 实现的，那 Envoy Go 扩展，本质上就相当于把 Go 语言嵌入 C++ 里了。\n在 Go 圈里，将 Go 当做嵌入式语言来用的，貌似并不太多见，这里面细节还是比较多的。比如：\n Envoy 有一套自己的内存管理机制，而 Go 又是一门自带 GC 的语言。 Envoy 是基于 libevent 封装的事件驱动，而 Go 又是包含了抢占式的协程调度。 为了降低用户开发时的心智负担，我们提供了三种安全保障。有了这三层保障，用户写 Go 来扩展 Envoy 的时候，就可以像平常写 Go 代码一样简单，而不必关心这些底层细节。\n三种安全 1. 内存安全 用户通过 API 获取到的内存对象，可以当做普通的 Go 对象来使用。\n比如，通过 Headers.Get 得到的字符串，在请求结束之后还可以使用，而不用担心请求已经在 Envoy 侧结束了，导致这个字符串被提前释放了。\n2. 并发安全 当启用协程的时候，我们的 Go 代码将会运行在另外的 Go 线程上，而不是在当前的 Envoy worker 线程上，此时对于同一个请求，则存在 Envoy worker 线程和 Go 线程的并发。\n但是，用户并不需要关心这个细节，我们提供的 API 都是并发安全的，用户可以不感知并发的存在。\n3. 沙箱安全 这一条是针对宿主 Envoy 的保障，因为我们并不希望某一个 Go 扩展的异常，把整个 Envoy 进程搞崩溃。\n目前我们提供的是，Go Runtime 可以 recover 的有限沙箱安全，这通常也足够了。\n更深度的，Runtime 不能 recover 的，比如 Map 并发访问，则只能将 Go So 重载，重建整个 Go Runtime 了，这个后续也可以加上。\n内存安全实现机制 要提供安全的内存机制，最简单的办法，也是*（几乎）*唯一的办法，就是复制。但是，什么时候复制、怎么复制，还是有一些讲究的。这里权衡的目标是降低复制的开销，提升性能。\n这里讲的内存安全，还不涉及并发时的内存安全，只是 Envoy*（C++）*和 Go 这两个语言运行时之间的差异。\nPS：以前用 OpenResty 的时候，也是复制的玩法，只是有一点区别是，Lua String 的 Internal 归一化在大内存场景下，会有相对较大的开销；Go String 则没有这一层开销，只有 Memory Copy + GC 的开销。\n复制时机 首先是复制时机，我们选择了按需复制，比如 Header，Body Data 并不是一开始就复制到 Go 里面，只有在对应的 API 调用时，才会真的去 Envoy 侧获取\u0026amp;amp;复制。\n如果没有被真实需要，则并不会产生复制，这个优化对于 Header 这种常用的，效果倒是不太明显，对于 Body 这种经常不需要获取内容的，效果则会比较的明显。\n复制方式 另一个则是复制方式，比如 Header 获取上，我们采用的是在 Go 侧预先申请内存，在 C++ 侧完成赋值的方式，这样我们只需要一次内存赋值即可完成。\n这里值得一提的是，因为我们在进入 Go 的时候，已经把 Header 的大小传给了 Go，所以我们可以在 Go 侧预先分配好需要的内存。\n不过呢，这个玩法确实有点 tricky，并不是 Go 文档上注明推荐的用法，但是也确实是我们发现的最优的解法了。\n如果按照 Go 常规的玩法，我们可能需要一次半或两次内存拷贝，才能保证安全，这里有个半次的差异，就是我们下回要说的并发造成的。\n另外，在 API 实现上，我们并不是每次获取一个 Header，而是直接一次性把所有的 Header 全复制过来，在 Go 侧缓存了。这是因为大多数场景下，我们需要获取的 Header 数量会有多个，在权衡了 CGO 的调用开销和内存拷贝的开销之后，我们认为一次性全拷贝是更优的选择。\n最后 相对来说，不考虑并发的内存安全，还是比较简单的，只有复制最安全，需要权衡考虑的则更多是优化的事情了。\n比较复杂的还是并发时的安全处理，这个我们下回再聊。\nMOSN Star 一下✨： https://github.com/mosn/mosn\n推荐阅读 MoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\n[MoE 系列（四）｜Go 扩展的异步模式](\n","date":1685430000,"description":"MoE 系列（五）｜Envoy Go 扩展之内存安全","dir":"blog/moe-series (5)｜envoy-go-extensions-memory-security/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1685430000,"objectID":"f5d59dc8bad34c82fb7116161068a117","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","publishdate":"2023-05-30T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","summary":"前面几篇介绍了 Envoy Go 扩展的基本用法，接下来几篇将介绍实现机制和原理。 Envoy 是 C++ 实现的，那 Envoy Go 扩展，本质上就相当于把 Go 语言嵌入 C++ 里了。 在 Go 圈里，将 Go","tags":["SOFAStack"],"title":"MoE 系列（五）｜Envoy Go 扩展之内存安全","type":"blog","url":"/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","wordcount":1443},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAChannel#33 预告\n**Occlum 是蚂蚁集团于 2019 年开源的机密计算操作系统，也是 Linux 基金会机密计算联盟官方项目，荣列 2021“科创中国”开源创新榜。2022 年 12 月 10 日，Occlum 正式发布 v1.0 版本。学术成果发表在 ASPLOS\u0026amp;rsquo;20。Occlum 可让复杂应用轻松获得机密计算能力，是目前业界最受欢迎的开源机密计算操作系统。\nSOFAChannel 第 33 期邀请到了 LibOS 项目的 Contributor 惠春阳来做分享，带大家了解机密计算，讲述 Occlum 如何借助 EDMM，获得更高的安全性、易用性和更极致的性能，成为更好的机密计算 Library OS。\n本期为 SOFAStack 与博文视点联合举办的机密计算专题，直播中也将抽奖送出《机密计算：AI 数据安全和隐私保护》。欢迎所有对 Occlum、机密计算、TEE 感兴趣的小伙伴们一起来听直播！🧸\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 24 日 14:00 - 15:00\n会议内容：\n随着本周社区会议的召开，社区同学讨论了如何为 Configure API 开发 Nacos 组件问题。会议同步了开源之夏的学生招募进展，以及在课题沟通时推进了 Layotto 目前能够解决的问题，并进一步讨论了版本优化的方法。\n「Layotto」：https://github.com/mosn/layotto/issues/931\n「会议回放」：https://www.bilibili.com/video/BV1XM4y1v7A9/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 31 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components#888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes#910 「Layotto」：https://github.com/mosn/layotto/issues/931\nSOFAStack 社区本周贡献\n本周推荐阅读\n直播预告 | SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》\nMOSN 基于延迟负载均衡算法——走得更快，期待走得更稳\nMoE 系列（四）｜Go 扩展的异步模式\nSOFAServerless 体系助力业务极速研发\n","date":1685084400,"description":"SOFA Weekly｜SOFAChannel#33 直播预告、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230526/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6ce1b77204d6ef8dfa8d2dcae4a65d59","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230526/","publishdate":"2023-05-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230526/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAChannel#33 直播预告、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230526/","wordcount":1186},{"author":null,"categories":"SOFAStack","content":" 文｜纪卓志（GitHub ID：jizhuozhi)\n京东高级开发工程师\nMOSN 项目 Committer\n专注于云原生网关研发的相关工作，长期投入在负载均衡和流量控制领域\n前言 这篇文章主要是介绍 MOSN 在 v1.5.0 中新引入的基于延迟的负载均衡算法#2253。首先会对分布式系统中延迟出现的原因进行剖析，之后介绍 MOSN 都通过哪些方法来降低延迟，最后构建与生产环境性能分布相近的测试用例来对算法进行验证。\n在开始聊基于延迟的负载均衡算法之前，我们先介绍下什么是负载均衡。\n什么是负载均衡 Wikipedia中 Load Balancing (Computing) 词条是这样介绍负载均衡的：\n 负载均衡是将一组任务分配到一组资源（计算单元）上的过程，目的是使它们的整体处理更有效率。负载均衡可以优化响应时间，避免负载不均匀导致一些计算节点过载而其他计算节点处于空闲状态\n 负载均衡在大型分布式系统中是关键的组成部分。负载均衡解决了分布式系统中最重要的两个问题：可伸缩性*（Scalability）*和韧性*（Resilience）*。\n 可伸缩性：应用程序部署在多个相同的副本中。当计算资源不足时可以通过部署额外的副本来增加计算资源，而当计算资源大量冗余时可以通过减少副本来节省成本。通过负载均衡可以将请求负载分布到不同的副本中。\n 韧性：分布式系统的故障是部分的。应用程序通过冗余副本的方式，保证在部分组件故障时仍能正常地提供服务。负载均衡通过感知节点的故障，调整流量的分配，将流量更多的分配到那些能够正常提供服务的节点上。\n 走得更快 负载均衡使得现代软件系统具备了可扩展性和韧性。但在分布式系统中还存在不容忽视的问题：延迟。\n延迟来自哪里 现代软件系统通常是多层级结构大型分布式系统，即使是只服务单个终端用户的请求，它背后也有可能经过了上百次的数据访问，这种情况在微服务架构中更是尤为普遍。\n微服务架构（引用自 Microservices Pattern）\n单台性能稳定的服务器中延迟通常由以下几个方面造成：\n 计算任务本身的复杂度 内容的传输过程中的延迟 请求排队等待的延迟 后台任务活动所导的资源竞争 这些服务器之间的延迟将会叠加，任何显著的延迟增加都会影响终端用户的体验。此外，任何来自单个节点的延迟峰值也会直接影响到终端用户体验。同时越来越多地使用公有云部署应用程序也进一步加剧了响应时间的不可预测性。因为在这些环境中存在共享资源*（CPU、内存和 IO）*的争用，应用程序机几乎不可避免地遇到性能影响，而这种影响是随时发生的。\n如何减少延迟 有研究表明，在大型互联网应用中，延迟往往具有长尾特点，P99 比中位数高出几个数量级。如果在应用架构的每层都能够减少这些尾部延迟，那么对终端用户整体的尾部延迟将会显著降低。\n在服务网格中，所有接收和发送的流量都会经过边车代理，通过边车代理可以轻松地控制网格的流量，而无需对服务进行任何修改。如果边车代理在对应用层流量进行转发时，总是通过负载均衡时选择响应时间较短的服务器，那么将会显著降低对终端用户的尾部延迟。\n基于此，我们准备开始为 MOSN 引入基于延迟的负载均衡算法，并进行适当调整来保证能够在大多数使用场景下显著减少延迟。\n性能问题是局部的 前面提到了，每个节点的性能受到多种因素的影响，这些影响因素是动态的，难以准确预测每个节点的性能，因此我们无法精确地选择最好的节点，但是可以避免较差的节点。\n在云环境中，服务器的性能常常是难以预测的，但是我们可以通过对大量的数据进行分析，发现服务器性能的分布大多数情况下是符合正态分布的。因此，尽管有一部分的服务器在性能方面表现比较差，它们的数量通常都是少数的*（3Sigma）*，而绝大部分服务器节点的表现是正常的。\n除了服务器之间的差异，还存在由基础设施导致的动态延迟，这种延迟可能是由于网络拥塞、故障或不断增长的流量所导致。这种延迟通常具有持续性和局部性：持续性则表示延迟会长时间存在，不会在短时间内消失；而局部性指的是延迟往往只出现在某些特定服务器上，而不会在全局发生。\nPeakEWMA 面对这些问题，我们使用 Peak EWMA*（Peak Exponentially Weighted Moving Average）*计算响应时间指标，并根据这个指标来对节点进行负载均衡。\nEWMA 是一种动态权重调整算法，各数值的加权影响力随时间而指数式衰退，越近期的数据加权影响力越重，但较旧的数据也给予一定的加权值。\n它以相对较高的权重考虑了最近响应时间的影响，因此更具有针对性和时效性。加权的程度以常数 𝛼 决定，𝛼 数值介于 0 至 1，它用来控制数据加权影响力衰退的速率。\n作为一种统计学指标，EWMA 的计算过程不需要大量的采样点以及时间窗口的设定，有效地避免了计算资源的浪费，更适合在 MOSN 这样的边车代理中使用。\n由于响应时间是历史指标，当服务器出现性能问题导致长时间未返回时，负载均衡算法会错误地认为这台服务器仍是最优的，而不断地向其发送请求而导致长尾延迟增高。我们使用活跃连接数作为实时变化的指标对响应时间进行加权，表示等待所有活跃的连接都返回所需要的最大时间。\nP2C（Power of Two Choice） 在大规模集群中，如果使用遍历所有服务器选择最好的服务器的方法，虽然可以找到最轻负载的服务器来处理请求，但这种方法通常需要大量的计算资源和时间，因此无法处理大规模的请求。因此，我们使用 P2C 来选择最优节点。相比之下，P2C 算法可以在常数时间内选择两个服务器进行比较，并选择其中负载更轻的服务器来处理请求。P2C 基于概率分配，即不直接基于权重分配，而是根据每个服务器优于其他服务器的概率值来决定请求的分配。\n此外，在多个负载均衡器的情况下，不同负载均衡器可能会有不同的节点视图，这可能导致某些负载均衡器选择的最优节点总是最差的节点。这是因为负载均衡器选择最优节点时基于自己的视图信息，而节点视图随着时间的变化可能会发生变化，因此不同的负载均衡器选择的最优节点也可能不同。P2C 算法通过对随机选择的两个节点进行比较，可以使节点间的负载均衡更加均匀，即使节点视图发生变化，也能提供稳定的负载均衡效果。\n 在 MOSN 的 v1.5.0 版本中，只有节点权重相同时会使用 P2C，当权重不同时会使用 EDF 进行加权选择。后续会提供可配置的选项。\n 模拟流量验证 我们构建了与生产环境性能分布相近的测试用例来对算法进行验证。\n首先我们使用正态分布生成了 10 台服务器的基准性能，其中数学期望为 50ms，标准差为 10ms。接下来，我们将这些基准性能作为数学期望，并以标准差为 5ms 的正态分布随机生成了请求延迟，以模拟真实世界的情况。此外，我们还在其中一台服务器注入了概率为 0.1 的故障，故障发生时会产生 1000ms 的延迟，以测试系统的容错性。\n为了模拟请求倾斜时请求排队等待的延迟，我们限制了每台服务器的最大并发数为 8，当同时处理的最大请求数超过了最大并发数时，将会排队等待。这样能够更加真实地模拟出系统的运行情况。\n最后，我们使用了 Round Robin、Least Request 和 Peak EWMA 三 …","date":1684825200,"description":"MOSN 基于延迟负载均衡算法——走得更快，期待走得更稳","dir":"blog/mosn-delay-based-load-balancing-algorithm-go-faster, expect-to-go-steadier/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4ed40af7694979d98879f50bcaf9093c","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","publishdate":"2023-05-23T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","summary":"文｜纪卓志（GitHub ID：jizhuozhi) 京东高级开发工程师 MOSN 项目 Committer 专注于云原生网关研发的相关工作，长期投入在负载均衡和流量控制领域","tags":["SOFAStack"],"title":"MOSN 基于延迟负载均衡算法——走得更快，期待走得更稳","type":"blog","url":"/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","wordcount":3277},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 大事记\nQCon 是由极客邦科技旗下 InfoQ 中国主办的综合性技术盛会，每年在伦敦、北京、纽约、圣保罗、上海、旧金山召开。自 2007 年 3 月份首次举办以来，已有超万名高级技术人员参加过 QCon 大会。QCon 内容源于实践并面向社区，演讲嘉宾依据热点话题，面向 5 年以上工作经验的技术团队负责人、架构师、工程总监、高级开发人员分享技术创新和典型实践。\n2023 年 5 月 26 日-27 日，QCon 广州站邀请了 MOSN 项目核心开发者、蚂蚁集团技术专家朱德江，将现场分享 《解密 MoE：将 Golang 嵌入 Envoy（C++）》。扫描上图二维码可参与报名。\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 17 日 14:00 - 15:00\n会议内容：\n随着本周社区会议的召开，社区同学进一步探讨了 Layotto 兼容 Dapr 的组件问题，解决思路逐渐清晰；对于如何使 Layotto 提供高性能的通信交互能力，社区同学将此问题与开源之夏的课题进行结合，并确定了版本优化的方向。\n「Layotto」：https://github.com/mosn/layotto/issues/929\n「会议回放」：https://www.bilibili.com/video/BV1Go4y1F7wo/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 24 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题汇总 #894\n Discussion：自建各种 Component #902\n 希望 Layotto 提供高性能的通信交互能力 #867\n 「Layotto」：https://github.com/mosn/layotto/issues/929\nSOFAStack 社区本周贡献\n本周推荐阅读\nMoE 系列（四）｜Go 扩展的异步模式\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\n【开源之夏 2023】欢迎报名 MOSN 社区项目！\n【开源之夏 2023】欢迎报名 SOFAStack 社区项目！\n","date":1684479600,"description":"SOFA Weekly｜SOFA 大事记、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230519/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bd81b1b8854e7bc553af2531bbdbe44a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230519/","publishdate":"2023-05-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230519/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 大事记、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230519/","wordcount":1102},{"author":null,"categories":"SOFAStack","content":"在《MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置》中我们体验了用 Istio 做控制面，给 Go 扩展推送配置，这次我们来体验一下，在 Go 扩展的异步模式下，对 Goroutine 等全部 Go 特性的支持。\n异步模式\n之前，我们实现了一个简单的 Basic Auth[1]，但是，那个实现是同步的，也就是说，Go 扩展会阻塞，直到 Basic Auth 验证完成，才会返回给 Envoy。\n因为 Basic Auth 是一个非常简单的场景，用户名密码已经解析在 Go 内存中了，整个过程只是纯 CPU 计算，所以，这种同步的实现方式是没问题的。\n但是，如果我们要实现一个更复杂的需求，比如，我们要将用户名密码调用远程接口查询，涉及网络操作，这个时候，同步的实现方式就不太合适了。因为同步模式下，如果我们要等待远程接口返回，Go 扩展就会阻塞，Envoy 也就无法处理其他请求了。\n所以，我们需要一种异步模式：\n 我们在 Go 扩展中，启动一个 Goroutine，然后立即返回给 Envoy，当前正在处理的请求会被挂起，Envoy 则可以继续处理其他请求。 Goroutine 在后台异步执行，当 Goroutine 中的任务完成之后，再回调通知 Envoy，挂起的请求可以继续处理了。 注意：虽然 Goroutine 是异步执行，但是 Goroutine 中的代码，与同步模式下的代码，几乎是一样的，并不需要特别的处理。\n为什么需要\n为什么需要支持 Goroutine 等全部 Go 的特性呢？\n有两方面的原因：\n 有了 Full-feature supported Go，我们可以实现非常强大、复杂的扩展。 可以非常方便的集成现有 Go 世界的代码，享受 Go 生态的红利。 如果不支持全部的 Go 特性，那么在集成现有 Go 代码的时候，会有诸多限制，导致需要重写大量的代码，这样，就享受不到 Go 生态的红利了。\n实现\n接下来，我们还是通过一个示例来体验，这次我们实现 Basic Auth 的远程校验版本，关键代码如下：\nfunc (f *filter) DecodeHeaders(header api.RequestHeaderMap, endStream bool) api.StatusType { go func() { // verify 中的代码，可以不需要感知是否异步 // 同时，verify 中是可以使用全部的 Go 特性，比如，http.Post if ok, msg := f.verify(header); !ok { f.callbacks.SendLocalReply(401, msg, map[string]string{}, 0, \u0026amp;quot;bad-request\u0026amp;quot;) return } // 这里是唯一的 API 区别，异步回调，通知 Envoy，可以继续处理当前请求了 f.callbacks.Continue(api.Continue) }() // Running 表示 Go 还在处理中，Envoy 会挂起当前请求，继续处理其他请求 return api.Running } 再来看 verify 的代码，重点是，我们可以在这里使用全部的 Go 特性：\n// 这里使用了 http.Post func checkRemote(config *config, username, password string) bool { body := fmt.Sprintf(`{\u0026amp;quot;username\u0026amp;quot;: \u0026amp;quot;%s\u0026amp;quot;, \u0026amp;quot;password\u0026amp;quot;: \u0026amp;quot;%s\u0026amp;quot;}`, username, password) remoteAddr := \u0026amp;quot;http://\u0026amp;quot; + config.host + \u0026amp;quot;:\u0026amp;quot; + strconv.Itoa(int(config.port)) + \u0026amp;quot;/check\u0026amp;quot; resp, err := http.Post(remoteAddr, \u0026amp;quot;application/json\u0026amp;quot;, strings.NewReader(body)) if err != nil { fmt.Printf(\u0026amp;quot;check error: %v\\n\u0026amp;quot;, err) return false } if resp.StatusCode != 200 { return false } return true } // 这里操作 header 这个 interface，与同步模式完全一样 func (f *filter) verify(header api.RequestHeaderMap) (bool, string) { auth, ok := header.Get(\u0026amp;quot;authorization\u0026amp;quot;) if !ok { return false, \u0026amp;quot;no Authorization\u0026amp;quot; } username, password, ok := parseBasicAuth(auth) if !ok { return false, \u0026amp;quot;invalid Authorization format\u0026amp;quot; } fmt.Printf(\u0026amp;quot;got username: %v, password: %v\\n\u0026amp;quot;, username, password) if ok := checkRemote(f.config, username, password); !ok { return false, \u0026amp;quot;invalid username or password\u0026amp;quot; } return true, \u0026amp;quot;\u0026amp;quot; } 另外，我们还需要实现一个简单的 HTTP 服务，用来校验用户名密码，这里就不展开了，用户名密码还是 foo:bar。\n完整的代码，请移步 Github[2]。\n测试\n老规矩，启动之后，我们使用 curl 来测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; HTTP/1.1 401 Unauthorized # valid foo:bar $ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39; HTTP/1.1 200 OK 依旧符合预期。\n总结\n在同步模式下，Go 代码中常规的异步非阻塞也会变成阻塞执行，这是因为 Go 和 Envoy 是两套事件循环体系。\n而通过异步模式，Go 可以在后台异步执行，不会阻塞 Envoy 的事件循环，这样，就可以用上全部的 Go 特性了。\n由 …","date":1684220400,"description":"MoE 系列（四）｜Go 扩展的异步模式","dir":"blog/moe-series (4)-go-extended-asynchronous-mode/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"34088a54a5896da249c7fab7e02b446e","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","publishdate":"2023-05-16T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","summary":"在《MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置》中我们体验了用 Istio 做控制面，给 Go 扩展推送配置，这次我们来体验一下，在 Go 扩展的异步模式下，对 Goroutine 等","tags":["SOFAStack"],"title":"MoE 系列（四）｜Go 扩展的异步模式","type":"blog","url":"/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","wordcount":1459},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议回顾\nSOFAArk：\n主题：SOFAArk 社区会议（月会）\n时间：5 月 8 日 20:00 - 21:30\n会议内容：\n本次社区会议根据议题介绍了近期 SOFAArk 2.2.0 版本发布计划，更新内容预计包含支持 JDK 17 模式下运行、依据 JarLocation 解析 BUG 修复、Benchmark 的一期建设；会议同步了非迭代 issue 进展，包括搭建 SOFAArk Windows 环境 CI、修复因文件路径不支持跨平台导致的资源加载失败问题；介绍了今年开源之夏 SOFAArk 提交的两个项目，邀请社区同学关注与参与；最后，大家一起讨论了 GPT 在 SOFA 工程领域的探索，目前开发同学正在建设基于 ChatGPT + LangChain 的基础工具链，会议中也邀请了社区同学一起共建。\n「会议纪要」：https://github.com/sofastack/sofa-ark/issues/636\n「会议回放」：https://www.bilibili.com/video/BV1Qs4y1D7Lv/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 2023-05-17 社区会议\n时间：5 月 17 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题:\n 2023 开源之夏-课题汇总#894 Discussion：自建各种 Component#902 希望 Layotto 提供高性能的通信交互能力#867 CLA 机器人问题同步 「Layotto」：https://github.com/mosn/layotto/issues/920\nSOFAStack 社区本周贡献\n本周推荐阅读\n【开源之夏 2023】欢迎报名 SOFAStack 社区项目！\n【开源之夏 2023】欢迎报名 MOSN 社区项目！\nKCL v0.4.6 重磅发布！全新的 IDE 插件，Helm/Kustomize/KPT 工具集成\n恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n","date":1683874800,"description":"SOFA Weekly｜SOFAArk 社区会议回顾、Layotto 社区会议预告、社区本周贡献","dir":"blog/sofa-weekly-230512/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3897039aee7e06226e62c5d248b6a953","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230512/","publishdate":"2023-05-12T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230512/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAArk 社区会议回顾、Layotto 社区会议预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230512/","wordcount":1029},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\nDragonfly 项目介绍\nDragonfly 是一个基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱项目 （Sandbox） 。2020 年 4 月，CNCF 技术监督委员会 （TOC） 投票决定接受 Dragonfly 作为孵化项目 （Incubating） 。经过多年生产实践经验打磨的下一代产品，汲取了 Dragonfly 1.x 的优点并针对已知问题做了大量的优化，在解决大规模文件分发场景下有着无可比拟的优势。基于 P2P 技术的优势，在 AI Inference 分发模型场景可以解决大文件分发过程中的性能瓶颈。并且可以通过集成 Dragonfly P2P 技术减少源站压力，提高模型分发效率。在未来，Dragonfly 会结合 AI 领域生态进行拓展，服务 AI 领域并且成为其重要基础设施。\nKata Containers 项目介绍\n自 2013 年 Docker 问世以来，容器技术立刻让全球的开发者为之着迷，并逐渐成为现代应用程序、构建、发布和运维的主流方式。容器以标准格式对应用程序进行封装，应用程序可从一个计算环境快速、安全地切换到另一个计算环境，这对于想要快速构建、测试和部署软件的开发者而言至关重要。然而传统的以 runC 为代表的容器方案基于共享内核技术，通过 Linux 提供的 Cgroups 和 Namespace 等方案进行隔离和控制，如果某一容器中的恶意程序利用了系统缺陷从容器中逃逸，则会对宿主机系统构成严重威胁。尤其是在公有云环境，这一潜在威胁成为了容器技术普及和落地的一大障碍。如果将不同容器再嵌套放入到不同的虚拟机，通过增加一层相对安全、成熟的隔离技术，就能大大提高系统的安全性，减少系统被攻破的可能。基于这种思想的开源技术也随之出现，代表性的两个项目为 Intel 开源技术中心的 Clear Containers 和 Hyper.sh 的 runV。2017 年，这两个开源项目合并，共同创建了开源项目 Kata Containers，其目标是将虚拟机的安全优势与容器的高速及可管理性相结合，为用户提供标准化、安全、高性能的容器解决方案。Kata Containers 创建的不同 Pod （容器） 运行在不同的虚拟机 （Kernel） 之中，比传统容器提供了更好的隔离性和安全性，同时继承了容器快速启动和标准化等优点。\nNydus 项目介绍\n镜像是容器基础设施中的一个重要部分，目前 OCI 标准镜像的缺陷之一是容器需要等待整个镜像数据下载完成后才能启动，这导致了容器启动时消耗了过多的端到端时间。在大规模集群场景下，这对网络与存储负载的影响尤为明显。Nydus 镜像加速框架提供了容器镜像按需加载的能力，它在生产环境里支撑了每日百万级别的加速镜像容器创建，将容器端到端冷启动时间从分钟级降低到了秒级。Nydus 目前由蚂蚁集团，阿里云，字节跳动联合研发，与内核态 EROFS 做了深度集成，也是 Kata Containers 与 Linux 内核态原生支持的镜像加速方案。目前 Nydus 已经被容器生态主流项目支持，例如 Containerd，Docker，Podman，BuildKit, Nerdctl，Kata Containers。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nDragonfly 社区项目\n项目链接： https://summer-ospp.ac.cn/org/orgdetail/72e6f975-d2b8-4fa3-a377-441c1038db10?lang=zh\nPyTorch Serve 基于 Dragonfly P2P 技术分发模型\n导师： yxxhero\n邮箱： aiopsclub@163.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0132?list=org\u0026amp;amp;navpage=org\nTensorFlow Serving 基于 Dragonfly P2P 技术分发模型\n导师： 崔大钧\n邮箱： bigerous@qq.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0022?list=org\u0026amp;amp;navpage=org\nTriton Inference Server 基于 Dragonfly P2P 技术分发模型\n导师： 戚文博\n邮箱： gaius.qi@gmail.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0001?list=org\u0026amp;amp;navpage=org\nKata Containers 社区项目\n项目链接： https://summer-ospp.ac.cn/org/orgdetail/301597a0-ca46-418a-89d1-13ea3c050ee9?lang=zh\n基于 VSOCK FD Passthrough 对 Container IO Stream 进行重构\n导师： 李福攀\n邮箱： fupan.lfp@antgroup.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010451?list=org\u0026amp;amp;navpage=org\nNydus RAFS v6 guest 内核支持优化\n导师： 李亚南\n邮箱： alex.lyn@antgroup.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010419?list=org\u0026amp;amp;navpage=org\n跨容器 shared-mount 支持\n导师： 彭涛\n邮箱： bergwolf@hyper.sh\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010417?list=org\u0026amp;amp;navpage=org\nNydus 社区项目\n项目链接： …","date":1683788400,"description":"【开源之夏 2023】欢迎报名 Dragonfly、Kata Containers、Nydus 社区项目！","dir":"activities/[Summer-2023-of-open-source-promotion-plan]welcome-to-register-for-dragonfly,kata-containers,and-nydus-community-projects!/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d417195ca31984354ab9fba0f7f2cefe","permalink":"https://sofastack.github.io/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","publishdate":"2023-05-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["开源之夏"],"title":"【开源之夏 2023】欢迎报名 Dragonfly、Kata Containers、Nydus 社区项目！","type":"activities","url":"/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","wordcount":2002},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2023 年，MOSN 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2023”，为大家准备了三个任务，涉及 Go、HTTP、Security、Software-Defined Networking、Container 等多个领域。\nMOSN 项目介绍\nMOSN*（Modular Open Smart Network）*是一款基于 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并在双 11 大促期间经过几十万容器的生产级验证。MOSN 为服务提供多协议、模块化、智能化、安全的代理能力，融合了大量云原生通用组件，同时也可以集成 Envoy 作为网络库，具备高性能、易扩展的特点。另外，MOSN 可以集成 Istio 构建 Service Mesh，也可以作为独立的四、七层负载均衡，API Gateway、云原生 Ingress 等使用。\nLayotto 项目介绍\nLayotto（/leɪˈɒtəʊ/） 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，例如状态管理、配置管理、事件发布订阅等，以简化应用的开发。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nMOSN 社区项目\n项目链接：https://summer-ospp.ac.cn/org/orgdetail/f0813e66-fa19-4302-a3e3-e6f2d210c83d?lang=zh\nMOSN\nGo、HTTP、Security\n项目社区导师：罗泽轩\nspacewanderlzx@gmail.com\n基于 Coraza 和 MOSN on Envoy 开发 Envoy 的 WAF 插件\n项目编号：23f080212\n项目难度：进阶/Advanced\nCoraza 是一个用 Go 实现的 WAF 引擎，我们希望能够借助 MOSN on Envoy 的能力，让 Coraza 运行在 Envoy 当中，并与官方的基于 Wasm 的实现*（https://github.com/corazawaf/coraza-proxy-wasm）*进行比较。\n 实现一个基本可用的 WAF 插件*（需要有详尽的文档+测试）*，并与 Wasm 版本做对比，输出一份比较报告。 了解 MOSN、Envoy 和 WAF，能够用 Go 写代码。 MOSN\nGo、Software-Defined Networking\n项目社区导师：纪卓志\njizhuozhi.george@gmail.com\n为 Envoy Go 扩展建设插件市场\n项目编号：23f080259\n项目难度：进阶/Advanced\nEnvoy 是当前最流行的网络代理之一，Go 扩展是 MOSN 社区为 Envoy 增加的 Go 生态基础，也是 MOSN 社区 MoE 框架的基础。\n受益于 Golang 生态系统，研发可以轻松在 Envoy 实现插件用于更多的长尾场景，其中很多场景都是通用的。\n本项目是为 Envoy Go 扩展构建插件市场。在插件市场中，人们可以在插件市场中分享插件，选用已经存在的插件。通过插件市场，可以让 Envoy、MoE 生态变得更加开放、共享、丰富。\n 提供一个 Envoy Go 插件的内容平台，在这里可以发布经过社区 Review 的优秀插件，需要拥有服务端与前端页面。\n 不自建账号体系，通过 GitHub OAuth2.0 完成用户认证与授权。\n 进阶——对接 GitHub OpenAPI，支持动态获取插件所在仓库信息，包括 README、分支版本以及 Star 数。\n 能够使用 Go 语言*（框架不限）*开发出带前端页面的小型站点。\n 对认证与授权及 OAuth2.0 有基本的了解。\n 熟悉 Git 和 GitHub 工作流程*（分支、版本、合并请求等）*。\n Layotto\nGo、gRPC\n项目社区导师：wenxuwan\nwangwenxue.wwx@antgroup.com\nLayotto Support Pluggable Components\n项目编号：23f080194\n项目难度：进阶/Advanced\n当前 Layotto 的 Components 都是实现在 Layotto 的工程里面的。用户若要想使用新的 Component，就必须使用 Golang 语言开发，同时必须在 Layotto 工程中实现，然后统一编译。对于多语言用户来说非常不友好，因此 Layotto 需要提供 Pluggable Components 的能力，允许用户可以通过任何语言实现自己的 Components，Layotto 通过 gRPC 协议和外部的 Components 进行通信。\n 完成 Pluggable Components 框架设计。\n 提供 Pluggable Components 接入文档和示例。\n 熟悉 Golang 和 gRPC，熟悉 Dapr 和 Layotto 运行时架构。\n 申请资格\n 本活动面向年满 18 周岁在校学生。\n 暑期即将毕业的学生，只要在申请时学生证处在有效期内，就可以提交申请。\n 中国籍学生参与活动需提供身份证、学生证、教育部学籍在线验证报告（学信网）或在读证明。\n 外籍学生参与活动需提供护照，同时提供录取通知书、学生卡、在读证明等文件用于证明学生身份。\n 活动流程\n添加 SOFAGirl 微信\n备注“开源之夏”进群交流\n","date":1683615600,"description":"【开源之夏 2023】欢迎报名 MOSN 社区项目！","dir":"activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project!/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1bdbf9f33dd6670508117cc1e5e907df","permalink":"https://sofastack.github.io/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","publishdate":"2023-05-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["开源之夏"],"title":"【开源之夏 2023】欢迎报名 MOSN 社区项目！","type":"activities","url":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","wordcount":1852},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nSOFAArk：\n主题：SOFAArk 2023-05-08 社区会议\n时间：5 月 8 日（下周一）20:00-21:30\n入会口令（钉钉）：683 550 26227\n电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题：\n 近期版本发布计划和内容 非迭代 issue 处理同步 开源之夏活动介绍 GPT 在 SOFA 工程领域的探索 「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/636\nLayotto：\n主题：Layotto 2023-05-10 社区会议\n时间：5 月 10 日（下周三）14:00-15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题/导师招募 Discussion：自建各种 Component 希望 Layotto 提供高性能的通信交互能力 CLA 机器人问题同步 「Layotto」：https://github.com/mosn/layotto/issues/915\nMOSN 社区：\n 基于 coraza 和 MOSN on Envoy 开发 Envoy 的 WAF 插件 导师：罗泽轩\n联系邮箱：spacewanderlzx@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080212?lang=zh\u0026amp;amp;list=pro\n 为 Envoy Go 扩展建设插件市场 导师：纪卓志\n联系邮箱：jizhuozhi.george@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080259?list=org\u0026amp;amp;navpage=org\nLayotto 社区：\n Layotto 支持自动/手动注入 Pod 部署 导师：刘训灼\n联系邮箱：mixdeers@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/2395a0359?list=org\u0026amp;amp;navpage=org\n Layotto Support Pluggable Components 导师：王文学\n联系邮箱：wangwenxue.wwx@antgroup.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080194?list=org\u0026amp;amp;navpage=org\n社区本周贡献\n本周推荐阅读\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\n如何看待 Dapr、Layotto 这种多运行时架构？\n应用运行时 Layotto 进入 CNCF 云原生全景图\n","date":1683270000,"description":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","dir":"blog/sofa-weekly-0505/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d9d0126ce61dc5e57710e2db403ca34e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0505/","publishdate":"2023-05-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0505/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜开源之夏 MOSN 与 Layotto 项目简介、社区会议预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0505/","wordcount":1039},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2023 年，SOFAStack 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2023”，一共为大家准备了五个任务，涵盖 SOFARPC、SOFAArk、SOFAJRaft 和 Layotto 等核心项目，涉及 Golang、Java、Kubernetes、Cloud Native、Distributed System 等多个领域。\nSOFARPC 项目介绍\nSOFARPC 是由蚂蚁集团开源的一款 Java RPC 框架，具有高可扩展性、高性能和生产级特性。该框架旨在简化应用之间的 RPC 调用，并为应用提供便捷透明、稳定高效的点对点远程服务调用方案。为方便用户和开发者进行功能扩展，SOFARPC 提供了丰富的模型抽象和可扩展接口，包括过滤器、路由、负载均衡等。\nSOFAArk 项目介绍\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，由蚂蚁集团开源贡献。该容器主要提供类隔离和应用（模块）合并部署能力。SOFAArk 提供多种方式来支持多应用（模块）合并部署，包括基于命令行的管控、基于 API 的管控等。\nSOFAJRaft 项目介绍\nSOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，适用于高负载低延迟的场景，支持 MULTI-RAFT-GROUP。使用 SOFAJRaft 可专注于业务领域，由 SOFAJRaft 解决与 RAFT 相关的技术难题。并且 SOFAJRaft 易于使用，可以通过几个示例快速掌握它。\nLayotto 项目介绍\nLayotto(/leɪˈɒtəʊ/) 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，例如状态管理、配置管理、事件发布订阅等，以简化应用的开发。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nSOFAStack 社区项目\n项目链接：https://summer-ospp.ac.cn/org/orgdetail/95a9e459-a200-4a26-bc0a-81074c2d89be?lang=zh\nSOFARPC\nJava、网络通信、RPC\n项目社区导师：EvenLiu\nevenljj@163.com\nSOFARPC 支持 Stream 流式处理方式\n项目编号：2395a0260\n项目难度：进阶/Advanced\nStream 方式是一种异步的流式处理方式，可以在数据传输过程中逐个处理数据，避免一次性传输大量数据造成的性能问题。服务端 Stream 是指服务端在处理请求时，将数据分成多个部分逐个返回给客户端的过程；客户端 Stream 是指客户端在请求服务器时，将请求参数分成多个部分逐个发送给服务器的过程。Stream 方式可以让我们在处理大量数据时更高效地使用资源，提高系统的性能和响应速度。SOFARPC 中需要 Triple、Bolt 协议支持 Stream 方式流式处理。\n SOFARPC 中 Triple 协议支持 Stream 流式处理。\n SOFARPC 中 Bolt 协议支持 Stream 流式处理。\n SOFAArk\nJava、SOFAArk 源代码\n项目社区导师：卫恒\nglmapper_2018@163.com\n开发一个客户端，支持 Biz 模块的热部署和热卸载，初步实现 Serverless 体验\n项目编号：2395a0267\n项目难度：基础/Basic\nSOFAArk 从最初的一个类隔离框架，逐步演进为支持合并部署与热部署的 “Serverless” 运行时框架，尤其在去年我们完成了 SOFAArk1.0 到 2.0 架构的演进。但是为了让开发者真正享受 Serverless 的研发体验，我们还需要建设一个客户端框架，对接 SOFAArk 实现 Biz 模块的热部署和热卸载，并暴露 HTTP API 接口可以让上游系统或者开发者直接使用。\n 设计并开发一个新的 SDK（SOFALet），新的 SDK 也就是 SOFALet 暴露一组 HTTP 接口，底层调用 SOFAArk 原子能力实现模块的热部署和热卸载。SOFALet 未来还会有 Node.js 版，这一期先支持 Java 版也就是对接 SOFAArk。\n 理解 SOFAArk 源代码，尤其是关于 telnet 指令安装和卸载模块的部分。\n SOFAArk\nGo、K8s\n项目社区导师：流铄\nxujinle300@126.com\n开发一个 K8s Operator，编排客户端 API 实现 Biz 模块的热部署，初步达成 Serverless 研发体验\n项目编号：2395a0392\n项目难度：基础/Basic\n为了让开发者真正享受 Serverless 的研发体验，我们需要先建设一个简易的 K8s Operator 和 SOFA Module Deployment、SOFA Module ReplicaSet CRD，对接编排模块热装载和热卸载的客户端，实现模块秒级发布的初步能力，让开发者能初步体验到 Serverless 的发布运维能力。\n 理解 SOFAArk 模块安装和卸载部分的源代码，并且熟悉 K8s CRD 和 Operator 体系的设计与开发。 SOFAJRaft\nJava、网络通信、RPC\n项目社区导师：刘源远\ngege87417376@qq.com\n结合 NWR 实现 Flexible RAFT，用于自定义 Quorum 的大小\n项目编号：2395a0390\n项目难度：进阶/Advanced\nJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，它运行过程分为两个阶段，即 Leader 选举和日志复制。在原始的 RAFT 算法中，Leader 选举和日志复制都需要获得多数派成员的支持。而 NWR 模型则可以在动态调整一致性强度的场景中使用，它需要满足 W+R\u0026amp;gt;N，以保证强一致性。JRaft 将 RAFT 和 NWR 结合起来，使得用户可以根据不同的业务需求来动态调整 Quorum 的数量。例如，在一个写多读少的场景中，用户可以将多数派的数量从 3 调整为 2，以降低达成共识的条件，从而提高写请求的效率。同时，为了保证 RAFT 的正确性，写 Quorum 的调整需要付出代价，即读 Quorum 的数量也需要相应调整。JRaft 支持成员变更，因此用户可以配置 (0,1] 范围内的小数来计算 W 和 R 的具体值。通过使用 JRaft，用户可以根据自己的业务需求来灵活地调整 …","date":1683270000,"description":"【开源之夏 2023】欢迎报名 SOFAStack 社区项目！","dir":"activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"def1ba20e3e6b79b6b9e2c6bae16ba91","permalink":"https://sofastack.github.io/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","publishdate":"2023-05-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["SOFAStack 开源之夏"],"title":"【开源之夏 2023】欢迎报名 SOFAStack 社区项目！","type":"activities","url":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","wordcount":2742},{"author":null,"categories":"SOFAStack","content":"上一篇我们用 Go 扩展实现了 Basic Auth，体验了 Go 扩展从 Envoy 接受配置。\n之所以这么设计，是想复用 Envoy 原有的 xDS 配置推送通道，今天我们就来体验一番，云原生的配置变更。\n前提准备\n这次我们需要一套 K8s 环境，如果你手头没有，推荐使用 Kind 安装一套。具体安装方式，这里就不展开了。\n安装 Istio\n我们直接安装最新版的 Istio：\n# 下载最新版的 istioctl$ export ISTIO_VERSION=1.18.0-alpha.0$ curl -L https://istio.io/downloadIstio | sh - # 将 istioctl 加入 PATH$ cd istio-$ISTIO_VERSION/$ export PATH=$PATH:$(pwd)/bin # 安装，包括 istiod 和 ingressgateway$ istioctl install 是的，由于 Go 扩展已经贡献给了上游官方，Istiod（Pilot）和 Ingress Gateway 都已经默认开启了 Go 扩展，并不需要重新编译。\nIstio 配置 Ingress\n我们先用 Istio 完成标准的 Ingress 场景配置，具体可以看 Istio 的官方文档[1]。\n配置好了之后，简单测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot;HTTP/1.1 200 OKserver: istio-envoydate: Fri, 10 Mar 2023 15:49:37 GMT 基本的 Ingress 已经跑起来了。\n挂载 Golang so\n之前我们介绍过，Go 扩展是单独编译为 so 文件的，所以，我们需要把 so 文件，挂载到 Ingress Gateway 中。\n这里我们把上次 Basic Auth 编译出来的 libgolang.so，通过本地文件挂载进来。简单点搞，直接 edit deployment 加了这些配置：\n# 申明一个 hostPath 的 volumevolumes:- name: golang-so-basic-auth hostPath: path: /data/golang-so/example-basic-auth/libgolang.so type: File # 挂载进来volumeMounts:- mountPath: /etc/golang/basic-auth.so name: golang-so-basic-auth readOnly: true 开启 Basic Auth 认证\nIstio 提供了 EnvoyFilter CRD，所以，用 Istio 来配置 Go 扩展也比较方便，apply 这段配置，Basic Auth 就开启了。\napiVersion: networking.istio.io/v1alpha3kind: EnvoyFiltermetadata: name: golang-filter namespace: istio-systemspec: configPatches: # The first patch adds the lua filter to the listener/http connection manager - applyTo: HTTP_FILTER match: context: GATEWAY listener: filterChain: filter: name: \u0026amp;quot;envoy.filters.network.http_connection_manager\u0026amp;quot; subFilter: name: \u0026amp;quot;envoy.filters.http.router\u0026amp;quot; patch: operation: INSERT_BEFORE value: # golang filter specification name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: \u0026amp;quot;type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config\u0026amp;quot; library_id: example library_path: /etc/golang/basic-auth.so plugin_name: basic-auth plugin_config: \u0026amp;quot;@type\u0026amp;quot;: \u0026amp;quot;type.googleapis.com/xds.type.v3.TypedStruct\u0026amp;quot; type_url: typexx value: username: foo password: bar 虽然有点长，但是，也很明显，配置的用户名密码还是：foo:bar。\n测试\n我们测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot;HTTP/1.1 401 Unauthorized # valid foo:bar$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39;HTTP/1.1 200 OK 符合预期。\n接下来，我们改一下 EnvoyFilter 中的密码，重新 apply，再测试一下：\n# foo:bar not match the new password$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39;HTTP/1.1 401 Unauthorized 此时的 Envoy 并不需要重启，新的配置就立即生效了，云原生的体验就是这么溜~\n总结\n因为 Go 扩展可以利用 Envoy 原有的 xDS 来接受配置，所以，从 Istio 推送配置也变得很顺利。\n不过，Istio 提供的 EnvoyFilter CRD 在使用上，其实并不是那么方便和自然，后面我们找机会试试 Envoy Gateway，看看 K8s Gateway API 的体验如何。\n至此，我们已经体验了整个 Envoy Go 的开发\u0026amp;amp;使用流程，在云原生时代，人均 Golang 的背景下，相信可以很好的完成网关场景的各种定制需求。\n下一篇，我们将介绍，如何在 Go 扩展中使用异步 …","date":1683010800,"description":"MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置","dir":"blog/moe-series (3)｜dynamic-update-of-go-extension-configuration-with-istio/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1683010800,"objectID":"5ff7cec6ed4b29c51c1f65f47b32672c","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","publishdate":"2023-05-02T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","summary":"上一篇我们用 Go 扩展实现了 Basic Auth，体验了 Go 扩展从 Envoy 接受配置。 之所以这么设计，是想复用 Envoy 原有的 xDS 配置推送通道，今天我们就来体验一番，云原生的","tags":["SOFAStack"],"title":"MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置","type":"blog","url":"/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","wordcount":974},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nSOFAArk：\n主题：SOFAArk 社区会议\n时间：5 月 8 日 20:00 - 21:30\n入会口令（钉钉）：683 550 26227\n电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题：\n 近期版本发布计划和内容。 非迭代 issue 处理同步。 开源之夏活动介绍。 GPT 在 SOFA 工程领域的探索。 「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/636\n每月一次的 SOFAArk 社区会议要开啦！有对议题感兴趣的同学不要错过哦～\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：4 月 26 日 14:00 - 15:00\n会议内容：\n本次社区会议根据议题同步了 2023 开源之夏申报的课题，并号召社区同学踊跃参与；对于自建各种组件，会议详细讲解了问题痛点与解决方案；Layotto 在升级 gRPC 版本时出现的前置依赖问题，会议中的同学提出了方案；在会议的最后，同步了 CLA 机器人解决的进展与办法。\n「Layotto」：https://github.com/mosn/layotto/issues/915\n「会议回放」：https://www.bilibili.com/video/BV1Qg4y177dG/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@huayangchan #914\n 下载 Layotto-0.5.0 源码，在本地 Windows 系统编译启动时，报一些函数和变量未定义错误，如 undefined: syscall.GetsockoptIPv 6Mreq，这应该是 Unix 系统才调用的函数，为什么在 Windows 系统运行会调 Unix 系统相关的函数，还说源码只能在 Unix 系统上便已启动?\n A：Layotto 是基于 MOSN 为底座的，用到了 Linux 的系统函数，所以不支持 Windows 上的编译。可以参考：https://github.com/mosn/layotto/issues/801\n「Layotto」：https://github.com/mosn/layotto/issues/914\n2.@shuangchengsun #263\n 图片展示了实例（Client）的上下线过程， 假设这么一个场景，Client1 处于下线过程中，此时它已经和 Session Server 断链，但是 Session Server 在发出同步通知前因为某种原因挂了，此时 Client1 在路由表中的状态是如何维护的？\n A: Data 上有一个定时器去维护每个 Session 相关数据的。如果 Session 挂了，Data 大约 30s 后把挂掉的 Session 的数据清理掉，同时链接挂掉的 Client（除了要下线的那个）会自动重连到其他 Session 上。然后会把数据增长一个 Version 重新注册到 Session，Session 会再次发到那台 Data 上。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/issues/263\n本周推荐阅读\n缘起｜蚂蚁应用级服务发现的实践之路\nSOFARegistry 源码｜数据同步模块解析\nMoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\n","date":1682665200,"description":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","dir":"blog/sofa-weekly-20230428/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f7cd5d7b9340442e111c4dfeaf5a6813","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230428/","publishdate":"2023-04-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230428/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230428/","wordcount":1451},{"author":null,"categories":"SOFAStack","content":"文｜蚂蚁集团 ZOLOZ 团队\n使用全球领先安全科技，为用户和机构提供安全、便捷的安全风控解决方案。\n本文 6386 字 阅读 12 分钟\n背景简介\nZOLOZ[1]是蚂蚁集团旗下的全球安全风控平台，通过业内领先的生物识别、大数据分析和人工智能技术，为用户和机构提供安全又便捷的安全风控解决方案。ZOLOZ 已为中国、印尼、马来西亚、菲律宾等 14 个国家和地区的 70 余家合作伙伴提供数字化转型过程中的安全风控技术支持。目前，已经覆盖金融、保险、证券、信贷、电信、公众服务等领域，累计服务用户超 12 亿。\n随着 Kubernetes 和云原生的大爆发，ZOLOZ 应用开始在公有云上进行大规模容器化部署。ZOLOZ 业务的镜像经过长期维护和更新，无论是镜像层数还是整体大小都达到了一个较大的量级 （数百 MB 或者几个 GB） 。特别是 ZOLOZ AI 算法推理应用的基础镜像大小要远大于一般应用镜像 （Docker Hub 上 PyTorch/PyTorch：1.13.1-CUDA 11.6-cuDNN 8-Runtime 有 4.92GB，同比 CentOS：latest 只有约 234MB） ，对于容器冷启动，即在本地无镜像的情况下，需要先从 Registry 下载镜像才能创建容器，在生产环境中，容器的冷启动往往耗时数分钟，并且随规模扩大会导致 Registry 因集群内网络拥堵而无法快速地下载镜像，如此庞大的镜像给应用的更新和扩容等操作都带来了不少挑战。在公有云上容器化持续推进的当下，ZOLOZ 应用主要遇到了三大挑战：\n 算法镜像大，推送到云上镜像仓库耗时长，开发过程中，在使用测试环境进行测试时，往往希望快速迭代，快速验证，但是每次改完一个分支发布验证都要经过几十分钟，开发效率十分低下。\n 拉取算法镜像耗时长，在集群扩容大量机器拉取镜像文件会容易导致集群网卡被打满，影响业务正常运行。\n 集群机器拉起时间长，难以满足流量突增时，弹性自动扩缩容。\n 虽然也尝试过各种折中的解决方案，但这些方案都有缺陷，现在结合蚂蚁、阿里云、字节跳动等多个技术团队打造了一套更通用的公有云上解决方案，该方案改造成本低，性能好，目前看来是比较理想的方案。\n术语及定义\nOCI：Open Container Initiative，开放容器计划是一个 Linux 基金会项目，由 Docker 在 2015 年 6 月启动，旨在为操作系统级虚拟化 （最重要的是 Linux 容器） 设计开放标准。\nOCI Manifest：遵循 OCI Image Spec 的制品。\nBuildKit：是 Docker 公司出品的一款更高效、Dockerfile 无关、更契合云原生应用的新一代 Docker 构建工具。\n镜像：本文中的镜像指 OCI Manifest，也包括 Helm Chart 等其他 OCI Manifest。\n镜像仓库：遵循 OCI Distribution Spec 实现的制品仓库。\nECS：是一种由 CPU、内存、云盘组成的资源集合，每一种资源都会逻辑对应到数据中心的计算硬件实体。\nACR：阿里云镜像仓库服务。\nACK：阿里云容器服务 Kubernetes 版提供高性能可伸缩的容器应用管理能力，支持企业级容器化应用的全生命周期管理。\nACI：ACI 全称 Ant Continuous Integration （AntCI） ，是蚂蚁集团研发效能旗下一款以流水线 （Pipeline） 为核心的 CI/CD 效能产品。使用智能自动化构建、测试和部署，提供了以代码流为输入的轻量级持续交付解决方案，提高团队研发的工作效率。\nPrivate Zone：基于专有网络 VPC （Virtual Private Cloud） 环境的私有 DNS 服务。该服务允许在自定义的一个或多个 VPC 中将私有域名映射到 IP 地址。\nP2P：点对点技术，当 P2P 网络中某一个 Peer 从 Server 下载数据的时候，下载完数据后也能当作服务端供其他 Peer 下载。当大量节点同时下载的时候，能保证后续下载的数据，可以不用从 Server 端下载。从而减轻 Server 端的压力。\nDragonfly：Dragonfly 是⼀款基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。现在为云原生计算机基金会 （CNCF） 托管作为孵化级项目。\nNydus：Nydus 镜像加速框架是 Dragonfly 的子项目，它提供了容器镜像按需加载的能力，在生产环境支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，端到端数据一致性，内核态支持等方面相比 OCIv1 有巨大优势。\nLifseaOS：面向容器场景，阿里云推出轻量、快速、安全、镜像原子管理的容器优化操作系统，相比传统操作系统软件包数量减少 60%，镜像大小减少 70%，OS 首次启动从传统 OS 的 1min 以上下降到了 2s 左右。支持镜像只读和 OSTree 技术，将 OS 镜像版本化管理，更新操作系统上的软件包、或者固化的配置时，以整个镜像为粒度进行更新。\n方案设计\n解决镜像大的问题\n1. 精简基础 镜像 大小\n基础 OS 从 CentOS 7 改为 AnolisOS 8，精简运维工具的安装，只默认安装一些必须的工具列表 （基础运维工具、运行时通用依赖、日志清理、安全基线等组件） ，并简化安全加固的配置，基础镜像从 1.63GB 减少到 300MB。\nAnolisOS 仓库：https://hub.docker.com/r/openanolis/anolisos/tags\n2. Dockerfile 优化\n通过 Dockerfile 编写约束、镜像检测等手段减少不必要的构建资源和时间。\nDockerfile 最佳实践原则: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/\n3. 并行构建和构建缓存\n蚂蚁构建中心采用 Nydus 社区优化版的 BuildKit[2]，BuildKit 支持 layer 级别缓存，准确引用先前的产出物并进行缓存匹配，使用方法与普通镜像并无区别，对于 Multistage 类型 Dockerfile，BuildKit 可以实现不同 stage 之间的并行执行。\n推送到云上镜像仓库耗时长\n1. 使用 Nydus 镜像进行块级别数据去重\n传统 OCI 镜像，不同镜像之间可以共享的最小单位是镜像中的层，在 deduplication 上的效率是非常低的，层内部存在重复的数据，层与层之间可能存在大量重复的数据，即使有微小的差别，也会被作为不同的层，根据 OCI Image Spec 对删除文件和 Hard Link 的设计，一个镜像内部可能存在已经被上层删除的文件仍然存在于下层中，并包含在镜像中。另外 OCI Image 使用了 tar+gzip 格式来表达镜像中的层，而 tar 格式并不区分 tar archive entries ordering， …","date":1682492400,"description":"蚂蚁安全科技 Nydus 镜像加速实践","dir":"blog/ant-security-technology-nydus-mirror-acceleration-practice/","fuzzywordcount":8700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c89b17510ce48eb33633af0051249102","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","publishdate":"2023-04-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","summary":"文｜蚂蚁集团 ZOLOZ 团队 使用全球领先安全科技，为用户和机构提供安全、便捷的安全风控解决方案。 本文 6386 字 阅读 12 分钟 背景简介 ZOLOZ[1]是蚂蚁集团旗","tags":["SOFAStack"],"title":"蚂蚁安全科技 Nydus 镜像加速实践","type":"blog","url":"/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","wordcount":8656},{"author":null,"categories":"SOFA WEEKLY","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：4 月 19 日 14:00 - 15:00\n会议内容：\n本次社区会议根据议题探讨了 2023 开源之夏申报课题的具体方式和内容，并号召同学踊跃参与报名；对于自建组件问题，方案已经敲定，感兴趣的同学可以尝试；Layotto 在升级 gRPC 版本时出现前置依赖问题，并在会议中同步进展；关于 CLA 机器人出现的问题，社区同学共同讨论了提供解决的思路。\n「Layotto」：https://github.com/mosn/layotto/issues/907\n「会议回放」：https://www.bilibili.com/video/BV1aT411p7cr/?share_source=copy_web\u0026amp;amp;vd_source=802e089175dbc2ea677914f78683b18a\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 2023-04-26 社区会议\n时间：4 月 26 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2344343024\n议题：\n 2023 开源之夏-课题/导师招募#894\n Discussion：自建各种 Component#902\n 希望 Layotto 提供高性能的通信交互能力#867\n 「Layotto」：https://github.com/mosn/layotto/issues/907\nSOFA 五周年资料已上传 SOFAStack 官网\n回复公众号：“SOFA 五周年”\n即可获取链接啦～\n还可戳“阅读原文”跳转哦！\nSOFAStack 社区本周贡献\nSOFARPC 5.10.0 版本发布\n发布 SOFARPC 5.10.0 版本，主要变更如下:\n 重构了自定义序列化器的注册模式，使得主站版可以覆盖开源版的注册#1296\n 修改了反序列化时 Request Header 的处理逻辑#1325\n 更新了 Javassist Proxy 构造 class 时的 API 使之能在 JDK17 环境下运行#1316\n 详细发布报告：https://github.com/sofastack/sofa-rpc/compare/v5.9.2\u0026amp;hellip;v5.10.0\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n @LY1806620741 #1061 com.alipay.sofa.rpc.enable-swagger 是否已经废弃？在 3.16.3\ncom.alipay.sofa.rpc.enable-swagger=true 配置使用了 Objectway 的 ASM，与 Spring Boot 的 ASM 冲突。\n A：可以手动增加一个依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.ow2.asm\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;asm\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;9.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 看起来是 https://github.com/sofastack/sofa-rpc/blob/5.8.3.1/all/pom.xml 少添加了一个 ASM 的依赖，导致出现上面的问题。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n @Estom#642 多 Host 模式下，动态部署，无法启动第二个 Tomcat。需要添加特殊的配置吗？\n A：多 Host 模式配置建议看一下这份文档 https://www.sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/中的“6.多 Host 与单 Host 模式”。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/642\n","date":1682060400,"description":"SOFA Weekly｜SOFARPC 5.10.0 版本发布、SOFA 五周年回顾、Layotto 社区会议回顾与预告","dir":"blog/sofa-weekly-0421/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4477f615201d81a1e6578f20f910a5d2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0421/","publishdate":"2023-04-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0421/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA WEEKLY"],"title":"SOFA Weekly｜SOFARPC 5.10.0 版本发布、SOFA 五周年回顾、Layotto 社区会议回顾与预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0421/","wordcount":1547},{"author":null,"categories":"SOFAStack","content":"文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 1445 字 阅读 5 分钟\n上一篇我们用一个简单的示例，体验了用 Golang 扩展 Envoy 的极速上手。\n这次我们再通过一个示例，来体验 Golang 扩展的一个强大的特性：\n从 Envoy 接收配置。\nBasic Auth\n我们还是从一个小示例来体验，这次我们实现标准的 Basic Auth 的认证，与上一次示例不同的是，这次认证的用户密码信息，需要从 Envoy 传给 Go，不能在 Go 代码中写死了。\n完整的代码可以看 example-basic-auth[1]，下面我们展开介绍一番。\n获取配置\n为了更加灵活，在设计上，Envoy 传给 Go 的配置是 Protobuf 的 Any 类型，也就是说，配置内容对于 Envoy 是透明的，我们在 Go 侧注册一个解析器，来完成这个 Any 配置的解析。\n如下示例：\nfunc init() { // 注册 parser http.RegisterHttpFilterConfigParser(\u0026amp;amp;parser{}) } func (p *parser) Parse(any *anypb.Any) interface{} { configStruct := \u0026amp;amp;xds.TypedStruct{} if err := any.UnmarshalTo(configStruct); err != nil { panic(err) } v := configStruct.Value conf := \u0026amp;amp;config{} if username, ok := v.AsMap()[\u0026amp;quot;username\u0026amp;quot;].(string); ok { conf.username = username } if password, ok := v.AsMap()[\u0026amp;quot;password\u0026amp;quot;].(string); ok { conf.password = password } return conf } 这里为了方便，Any 中的类型是 Envoy 定义的 TypedStruct 类型，这样我们可以直接使用现成的 Go pb 库。\n值得一提的是，这个配置解析，只有在首次加载的时候需要执行，后续在 Go 使用的是解析后的配置，所以，我们解析到一个 Go map 可以拥有更好的运行时性能。\n同时，由于 Envoy 的配置，也是有层级关系的，比如 http-filter, virtual host, router, virtual clusters 这四级，我们也支持这四个层级同时有配置，在 Go 侧来组织 merge。\n当然，这个只有在 Go 侧有复杂的 filter 组织逻辑的时候用得上，后面我们在 MOSN 的上层封装的时候，可以看到这种用法，这里暂时不做展开介绍。\n认证\n具体的 Basic Auth 认证逻辑，我们可以参考 Go 标准 net/http 库中的 Basic Auth 实现。\nfunc (f *filter) verify(header api.RequestHeaderMap) (bool, string) { auth, ok := header.Get(\u0026amp;quot;authorization\u0026amp;quot;) if !ok { return false, \u0026amp;quot;no Authorization\u0026amp;quot; } username, password, ok := parseBasicAuth(auth) if !ok { return false, \u0026amp;quot;invalid Authorization format\u0026amp;quot; } if f.config.username == username \u0026amp;amp;\u0026amp;amp; f.config.password == password { return true, \u0026amp;quot;\u0026amp;quot; } return false, \u0026amp;quot;invalid username or password\u0026amp;quot; } 这里面的 parseBasicAuth 就是从 net/http 库中的实现，是不是很方便呢。\n配置\n简单起见，这次我们使用本地文件的配置方式。如下是关键的配置：\nhttp_filters: - name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config library_id: example library_path: /etc/envoy/libgolang.so plugin_name: basic-auth plugin_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/xds.type.v3.TypedStruct value: username: \u0026amp;quot;foo\u0026amp;quot; password: \u0026amp;quot;bar\u0026amp;quot; 这里我们配置了用户名密码：foo:bar。\n预告一下，下一篇我们会体验通过 Istio 来推送配置，体会一番动态更新配置的全流程。\n测试\n编译，运行，跟上篇一样，我们还是使用 Envoy 官方提供的镜像即可。\n跑起来之后，我们测试一下：\n$ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; HTTP/1.1 401 Unauthorized # invalid username:password $ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;Authorization: basic invalid\u0026#39; HTTP/1.1 401 Unauthorized # valid foo:bar $ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39; HTTP/1.1 200 OK 是不是很简单呢，一个标准的 Basic Auth 扩展就完成了。\n总结\nEnvoy 是面向云原生的架构设计，提供了配置动态变更的机制，Go 扩展可以从 Envoy 接受配置，也就意味着 Go 扩展也可以很好的利用这套机制。\nGo 扩展的开发者，不需要关心配置的动态更新，只需要解析配置即可，非常的方便~\n下一篇我们会介绍，配合 Istio 来动态更新用户名密码，体验一番云原生的配置变更体验。\n后续还有更多 Golang 扩展的特性介绍，原理解析，以及，更上层的 MOSN 集成体验，欢迎持续关注。\n[1]example-basic-auth： …","date":1681801200,"description":"MoE 系列（二）｜Golang 扩展从 Envoy 接收配置","dir":"blog/moe-series (2)｜golang-extensions-receive-configuration-from-envoy/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1681801200,"objectID":"f19954b7d5ae3122eec6e6599e9d1be2","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","publishdate":"2023-04-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 1445 字 阅读 5 分钟 上一篇我","tags":["SOFAStack"],"title":"MoE 系列（二）｜Golang 扩展从 Envoy 接收配置","type":"blog","url":"/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","wordcount":1147},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFA 五周年，Live Long and Prosper！\n 活动时间：04 月 15 日 12:00\u0026amp;ndash;17:00\n 活动形式：线下 Meetup + 线上直播\n 资料下载：\n 《SOFAStack 的下一个五年》\n《京东搜索基于Service Mesh的微服务治理探索与实践》\n《顺丰应用运行时落地实践》\n《Seata发展之路——昨天、今天、明天》\n《蚂蚁注册中心建设的思考与实践》\n B 站直播间地址：http://live.bilibili.com/21954520 介绍 2018 年 4 月 19 日，我们在北京启程，伴随种下希望的种子，举办了 SOFAStack 社区的第一个开放日。\n转眼来到 2023 年，瑞兔送福又逢春暖花开，怀揣着新的愿景，我们于 4 月 15 日回到北京庆祝 SOFA 的五岁生日。🎂\n今年的主题「Live Long and Prosper」相信对于不少“星际迷航”粉丝来说都已经耳熟能详了。这是瓦肯人在举瓦肯手礼的时候会说的祝词，却也非常符合 SOFAStack 开源社区的愿景。\n我们希望无论是 SOFAStack 社区项目，还是 SOFA 的生态伙伴，都能够“Live Long and Prosper”！👽\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 宋顺（花名：齐天），SOFAStack 社区开源负责人\n 王志龙，京东集团架构师、MOSN Contributor\n 杨定朝，顺丰集团高级研发工程师、Layotto 用户\n 李宗杰（花名：白鹰），Seata 蚂蚁开源负责人\n 肖健（花名：昱恒），SOFARegistry Maintainer\n 议程 直播回放 https://www.bilibili.com/video/BV1vL411e78B/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1681542000,"description":"2023 年 4 月 15 日，我们在北京一起庆祝了 SOFA 社区的五岁生日。","dir":"activities/sofa-anniversary-5/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3e1d3b14932e3e3e091b5cbce4868d80","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-anniversary-5/","publishdate":"2023-04-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-anniversary-5/","summary":"概要 活动主题：SOFA 五周年，Live Long and Prosper！ 活动时间：04 月 15 日 12:00\u0026ndash;17:00 活动形式：线下 Meetup + 线上直播 资料下载： 《SOFAStack 的下","tags":["SOFAStack","开源五周年"],"title":"SOFA 五周年，Live Long and Prosper！","type":"activities","url":"/sofastack.tech/activities/sofa-anniversary-5/","wordcount":633},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n**1.@SOFAJRaft **#965 提问：\n@a364176773\n RheaKV 中的 RocksDB 为何不支持选择其他压缩方式和压缩风格？\n貌似可以靠StorageOptionsFactory.registerRocksDBOptions注册进去，这样就不会走 default 了？\n A：是的，可以设置自己的选项。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/965\n2.@SOFARPC#1320\n@Misakami\n Spring Boot 3.1 + JDK 17 SOFARPC 显示发布成功但是客户端获取不到服务。\n A：看上去获取不到服务和 JDK17 并没有直接的联系。可以先确认:\n 服务端是否将自身地址发布到注册中心；\n 客户端是否接收到注册中心的推送。\n 「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1320\n本周推荐阅读\n缘起｜蚂蚁应用级服务发现的实践之路\nSOFARegistry | 聊一聊服务发现的数据一致性\nGo 语言，如何做逆向类型推导\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n","date":1681455600,"description":"SOFA Weekly｜SOFA 开源五周年来自社区家人的祝福、社区本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230414/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4e553c30969c289fec68bf7f78424e0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230414/","publishdate":"2023-04-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230414/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 开源五周年来自社区家人的祝福、社区本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230414/","wordcount":657},{"author":null,"categories":"SOFAStack","content":"文｜肖健（花名：昱恒）\n蚂蚁集团技术专家、SOFARegistry Maintainer\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。\n本文 8339 字 阅读 15 分钟\nPART. 1\n前言\n什么是服务发现？\n我们今天主要聊的话题是“应用级服务发现”的实践，聊这个话题之前，我们先简单介绍一下什么是“服务发现”，然后再聊聊，为什么需要“应用级服务发现”。\n在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信，而这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\n图 1（点击图片查看大图）\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑了蚂蚁庞大的服务集群，具有分布式可支撑海量数据、可云原生部署、推送延迟低、高可用等特点。\nPART. 2\n应用级服务发现的设想\n介绍完什么是服务发现之后，我们来看看什么是“接口级服务发现”，以及与之相对应的“应用级服务发现”。\n从 RPC 框架说起\n根据上述描述，我们先看看业界常用的 RPC 框架，是如何进行服务的发布和订阅的。以 SOFARPC 编程界面为例：\n｜服务发布\npackage com.alipay.rpc.sample; @SofaService(interfaceType = FooService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class FooServiceImpl implements FooService { @Override public String foo(String string) { return string; } } @SofaService(interfaceType = BarService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class BarServiceImpl implements BarService { @Override public String bar(String string) { return string; } } ｜服务使用\n@Service public class SampleClientImpl { @SofaReference(interfaceType = FooService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private FooService fooService; @SofaReference(interfaceType = BarService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private BarService barService; public String foo(String str) { return fooService.foo(str); } public String bar(String str) { return barService.bar(str); } } 上述两个编程界面，完成了两个服务 FooService 和 BarService 的发布、订阅、调用。\n微服务面临的挑战\n上述的服务发布、订阅、调用功能，离不开注册中心的服务发现提供准确的服务地址。将图 1 的服务发现场景进一步展开，此时的工作原理如下图：\n图 2（点击图片查看大图）\n服务发布者\n- 集群内部署了 100 个 pod，IP 分别为：1.1.1.1 ~ 1.1.1.100；\n- 服务发布者的 URL：1.1.1.1:12200?app=applicationB\u0026amp;amp;_SERIALIZETYPE=hessian2\u0026amp;amp;_TIMEOUT=3000\u0026amp;amp;zone=zone1\u0026amp;amp;version=1\u0026amp;amp;_WARMUPTIME=0，12200 端口为 sofarpc-bolt 协议默认的端口。\n服务订阅者：集群内部署了 100 个 pod，IP 分别为：2.1.1.1 ~ 2.1.1.100。\n基于上述的集群部署情况，我们来看看微服务的场景面临的挑战。\n｜挑战 1：注册中心 publisher 存储的挑战\n在上面的集群部署中，可以看到注册中心的数据存储模型，集群内部署了 100 个 provider pod，每个 provider 发布了 2 个服务，即每个 pod 有 2 个 publisher，以 provider1 为例：\n如果在每个 provider 提供更多服务的情况下呢？比如每个 provider 提供了 50 个服务，这样的量级在微服务场景中并不少见，那么此时注册中心对于 provider1，就需要存储 50 个 publisher，分别是：\n可以看到，随着 provider 的扩容，注册中心存储的 publisher 数据量是以 50 倍于 provider 的速度在增长。\n如果您对 SOFARegistry 有过了解，就会知道 SOFARegistry 是支持数据存储分片，可以存储海量数据的。\n但是数据量上涨带来的是 SOFARegistry 本身的服务器数量增涨，如果我们有办法可以降低 SOFARegistry 的数据存储量，那么就能节约 SOFARegistry 本身的服务器成本，同时 SOFARegistry 整个集群的稳定性也会得到提升。\n｜挑战 2：注册中心 subscriber 存储的挑战\n在上述的集群部署中，集群内部署了 100 个 consumer pod，每个 consumer 订阅了 2 个服务，即每个 pod 有 2 个 subscriber，同理于 publisher 的存储挑战，随着 consumer 订阅的接口持续增加，例如 consumer 订阅了 provider 的 10 个 service，此时注册中心存储 consumer1 的 10 个 subscriber 如下：\n随着 consumer 的扩容，注册中心内的 subscriber 存储同样面临着挑战。\n｜挑战 3：服务变更通知的挑战\n随着 publisher 和 subscriber 数量增长，除了对存储的挑战以外，对于数据变更通知同样面临着极大的挑战，让我们来看看如下的场景：provider 下线了 1 台，从 100 台减少到了 99 台，次数集群内发生了哪些变化呢？\n1、首先是在注册中心存储方面，需要将 provide 50 个 service …","date":1681196400,"description":"缘起｜蚂蚁应用级服务发现的实践之路","dir":"blog/origins｜ant's-practical-path-to-application-level-service-discovery/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1681196400,"objectID":"961f22ae0d2c39d1338da028adc43cbb","permalink":"https://sofastack.github.io/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","publishdate":"2023-04-11T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家、SOFARegistry Maintainer 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。 本文 8339 字 阅","tags":["SOFAStack"],"title":"缘起｜蚂蚁应用级服务发现的实践之路","type":"blog","url":"/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","wordcount":3973},{"author":"肖健","categories":["SOFARegistry"],"content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家、SOFARegistry Maintainer\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。\n本文 8339 字阅读 15分钟\nPART. 1\n前言 什么是服务发现？ 我们今天主要聊的话题是“应用级服务发现”的实践，聊这个话题之前，我们先简单介绍一下什么是“服务发现”，然后再聊聊，为什么需要“应用级服务发现”。\n在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信，而这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\n图 1\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑了蚂蚁庞大的服务集群，具有分布式可支撑海量数据、可云原生部署、推送延迟低、高可用等特点。\nPART. 2\n应用级服务发现的设想 介绍完什么是服务发现之后，我们来看看什么是“接口级服务发现”，以及与之相对应的“应用级服务发现”。\n从 RPC 框架说起 根据上述描述，我们先看看业界常用的 RPC 框架，是如何进行服务的发布和订阅的。以 SOFARPC 编程界面[1]为例：\n服务发布 package com.alipay.rpc.sample; @SofaService(interfaceType = FooService.class, bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class FooServiceImpl implements FooService { @Override public String foo(String string) { return string; } } @SofaService(interfaceType = BarService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class BarServiceImpl implements BarService { @Override public String bar(String string) { return string; } } 服务使用 @Service public class SampleClientImpl { @SofaReference(interfaceType = FooService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private FooService fooService; @SofaReference(interfaceType = BarService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private BarService barService; public String foo(String str) { return fooService.foo(str); } public String bar(String str) { return barService.bar(str); } } 上述两个编程界面，完成了两个服务 FooService 和 BarService 的发布、订阅、调用。\n微服务面临的挑战 上述的服务发布、订阅、调用功能，离不开注册中心的服务发现提供准确的服务地址。将图 1 的服务发现场景进一步展开，此时的工作原理如下图：\n图 2（点击图片查看大图）\n服务发布者：\n- 集群内部署了 100 个 pod，IP 分别为：1.1.1.1 ~ 1.1.1.100；\n- 服务发布者的 URL：1.1.1.1:12200?app=applicationB\u0026amp;amp;_SERIALIZETYPE=hessian2\u0026amp;amp;_TIMEOUT=3000\u0026amp;amp;zone=zone1\u0026amp;amp;version=1\u0026amp;amp;_WARMUPTIME=0，12200 端口为 sofarpc-bolt 协议默认的端口。\n服务订阅者：集群内部署了 100 个 pod，IP 分别为：2.1.1.1 ~ 2.1.1.100。\n基于上述的集群部署情况，我们来看看微服务的场景面临的挑战。\n挑战 1：注册中心 publisher 存储的挑战 在上面的集群部署中，可以看到注册中心的数据存储模型，集群内部署了 100 个 provider pod，每个 provider 发布了 2 个服务，即每个 pod 有 2 个 publisher，以 provider1 为例：\n如果在每个 provider 提供更多服务的情况下呢？比如每个 provider 提供了 50 个服务，这样的量级在微服务场景中并不少见，那么此时注册中心对于 provider1，就需要存储 50 个 publisher，分别是：\n可以看到，随着 provider 的扩容，注册中心存储的 publisher 数据量是以 50 倍于 provider 的速度在增长。\n如果您对 SOFARegistry 有过了解，就会知道 SOFARegistry 是支持数据存储分片，可以存储海量数据的。\n但是数据量上涨带来的是 SOFARegistry 本身的服务器数量增涨，如果我们有办法可以降低 SOFARegistry 的数据存储量，那么就能节约 SOFARegistry 本身的服务器成本，同时 SOFARegistry 整个集群的稳定性也会得到提升。\n挑战 2：注册中心 subscriber 存储的挑战 在上述的集群部署中，集群内部署了 100 个 consumer pod，每个 consumer 订阅了 2 个服务，即每个 pod 有 2 个 subscriber，同理于 publisher 的存储挑战，随着 consumer 订阅的接口持续增加，例如 consumer 订阅了 provider 的 10 个 service，此时注册中心存储 consumer1 的 10 个 subscriber 如下：\n随着 consumer 的扩容，注册中心内的 subscriber 存储同样面临着挑战。\n挑战 3：服务变更通知的挑战 随着 publisher 和 subscriber 数量增长，除了对存储的挑战以外，对于数据变更通知同样面临着极大的挑战，让我们来看看如下的场景：provider 下线了 1 台，从 100 台减少到了 99 台，次数集群内发生了哪些变化呢？\n1、首先是在注册中心存储方面，需要将 provide 50 个 service 中的 publishers 列表都减 …","date":1681196400,"description":"缘起｜蚂蚁应用级服务发现的实践之路","dir":"projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c9a51341a37418edfd01dc26b64f56e4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","publishdate":"2023-04-11T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家、SOFARegistry Maintainer 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。 本文 8339 字阅","tags":["SOFAStack","SOFARegistry"],"title":"缘起｜蚂蚁应用级服务发现的实践之路","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","wordcount":4116},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 会议预告\nLayotto：\n主题：Layotto 2023-04-12 社区会议\n时间：4 月 12 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2344343024\n议题：\n- 2023开源之夏-课题/导师招募 #894；\n- Discussion: 自建各种 Component #902；\n- 希望 layotto 提供高性能的通信交互能力 #867。\n「Layotto」：\nhttps://github.com/mosn/layotto/issues/907\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@LSQGUANLIVV #1322\n 从 sofa2.3.5 升级到 3.6.3 的时候，启动应用报错，如下图所示。\n 按照报错的点去找发现是 applicationContext 为 null，这里是需要新增加什么配置吗？还是原来的什么地方需要改呢？\n A：有可能是 sofa-boot / sofa-rpc-starter / sofa-rpc 这三个包的兼容性问题。升级了 sofa-rpc，需要同时升级这三个包。可以通过 pom 依赖看下是否有版本冲突。\n 是用的 sofaboot-enterprise-dependencies 的父依赖的默认的，这个也会冲突吗？\n A：使用默认的一般不会有问题，担心有些配置把默认配置覆盖了。另外商业版需要咨询商业版客服，开源社区这边能提供的帮助有限。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1322\n2.@hanzhihua #956\n readCommittedUserLog 可能获得不到刚写入的数据。我在做 NodeTest 测试过程中，在测试 readCommittedUserLog 方法中，出现了错误。\n 我发现主要是日志写入后，但 lastAppliedIndex 没有原子级别更新，造成了读取不到错误。\n A：因为onApply中是可以回滚的，所以没法去实时更新 lastAppliedIndex，只有确认这一批次没有回滚或者回滚的正确 log index，才能去更新。如果你需要在onApply过程中去 commit，可以调用日志迭代器的Iterator#commit方法，将当前 apply 的 log index 确认提交。然后就可以调用readCommittedUserLog确保可以读取到，代价就是无法回滚到 commit 之前的位置了。\n 问一下，onApply 回滚是什么意思，是指状态机 apply 发生异常，还是获取日志为 null，另外怎么回滚呢？\n A：这个方法：\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/956\n本周推荐阅读\n《MoE 系列（一）｜如何使用 Golang 扩展 Envoy》\n《SOFAJRaft 在同程旅游中的实践》\n《Tongsuo/铜锁｜「开放原子开源基金会」拜访篇》\n《如何看待 Dapr、Layotto 这种多运行时架构？》\n","date":1680850800,"description":"SOFA Weekly｜SOFA 开源五周年活动报名、Layotto 会议预告、社区本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230407/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5deb7a12ba899d85e14ea36b8d21dec4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230407/","publishdate":"2023-04-07T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230407/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 开源五周年活动报名、Layotto 会议预告、社区本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230407/","wordcount":1357},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区会议 SOFAArk 背景：SOFAArk 在社区开源将近 5 年，从最初的一个类隔离框架，逐步演进为支持合并部署与热部署的 “Serverless” 运行时框架。尤其在去年我们完成了 SOFAArk 1.0 到 2.0 架构的演进，在蚂蚁也基于 SOFAArk 2.0 完成了 Serverless 研发模式初步的规模化落地。\n主题：SOFAArk 社区化运作方式 KO（暨第一次月会） 时间：4 月 3 日（下周一）20:00 入会口令（钉钉）：683 550 26227 电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆） 入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题： - SOFAArk 社区化运作计划同步与讨论； - 版本维护策略公告； - 项目 CY23 开源规划（含新人培养计划）； - 本次月会 issue 讨论。\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。\n「SOFAArk」：\nhttps://github.com/sofastack/sofa-ark/issues/635\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@Misakami #1321\n 请问 sofa-rpc 有支持 jdk 17 的计划么？现在虽然能正常使用，但是需要在启动参数加上 \u0026amp;ndash;add-opens java.base/java.lang=ALL-UNNAMED。\n A：有的，近期也正在做兼容 jdk 17 的开发。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1321\n2.@googlefan #939\n jraft-spring-boot-starter || NodeManager 设计目的的作用? 看到 jraft-core 有提供 NodeManage.nodeMap 这个针对 Node 节点进行管理的实例，我以为可以通过 NodeManage.nodeMap 来获取所有集群节点的 RPC 服务，如果是这样的话，这个类的设计的目的是?\n A：NodeManager 是 jraft 内部为了实现单个进程内多个 raft group 共享同一个网络端口设计的，不是给集成着或者用户使用的。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/939\n本周推荐阅读 应用运行时 Layotto 进入 CNCF 云原生全景图\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1680246000,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230331/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a01ecd144b06b6b3399f4474a92ab677","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230331/","publishdate":"2023-03-31T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230331/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230331/","wordcount":1071},{"author":null,"categories":"SOFAStack","content":"本文作为 MoE 系列第一篇，主要介绍用 Golang 扩展 Envoy 的极速开发体验。\n一、背景\nMoE*（MOSN on Envoy）*是 MOSN 团队提出的技术架构，经过近两年的发展，在蚂蚁内部已经得到了很好的验证；并且去年我们也将底层的 Envoy Go 七层扩展贡献了 Envoy 官方，MOSN 也初步支持了使用 Envoy 作为网络底座的能力。\n借此准备写一系列的文章，逐一介绍这里面的技术。本文作为开篇，将重点介绍 MoE 中的基础技术，Envoy Go 扩展。\n二、FAQ\n开始前，先给大家解答下几个基本的问题：\n 1、MoE 与 Envoy Go 扩展有什么区别？\n A：MoE 是技术架构，Envoy Go 扩展是连接 MOSN 和 Envoy 的基础技术。\n 2、Envoy Go 扩展，与用 Go 来编译 Wasm 有什么区别？\n A：Envoy Go 支持 Go 语言的所有特性，包括 Goroutine；Go Wasm 则只能使用少量的 Go 语言特性，尤其是没有 Goroutine 的支持。\n 3、Go 是静态链接到 Envoy 么？\n A：不是的，Go 扩展编译成为 so，Envoy 动态加载 so，不需要重新编译 Envoy\n 4、Envoy Go 支持流式处理么？\n A：支持的。\n由于 Go 扩展提供的是底层的 API，非常的灵活，使用上相对会稍微复杂一些；如果只想简单的使用，可以使用 MOSN 的 filter，后面我们也会介绍。\n三、需求\n我们先实现一个小需求，来实际体会一下：\n对请求需要进行验签，大致是从 URI 上的某些参数，以及私钥计算一个 token，然后和 header 中的 token 进行对比，对不上就返回 403。\n很简单的需求，仅仅作为示例，主要是体验一下过程。\n四、代码实现\n完整的代码可以看 envoy-go-filter-example[1] 这个仓库，这里摘录最核心的两个函数：\nconst secretKey = \u0026amp;quot;secret\u0026amp;quot; func verify(header api.RequestHeaderMap) (bool, string) { token, ok := header.Get(\u0026amp;quot;token\u0026amp;quot;) if ok { return false, \u0026amp;quot;missing token\u0026amp;quot; } path, _ := header.Get(\u0026amp;quot;:path\u0026amp;quot;) hash := md5.Sum([]byte(path + secretKey)) if hex.EncodeToString(hash[:]) != token { return false, \u0026amp;quot;invalid token\u0026amp;quot; } return true, \u0026amp;quot;\u0026amp;quot; } func (f *filter) DecodeHeaders(header api.RequestHeaderMap, endStream bool) api.StatusType { if ok, msg := verify(header); !ok { f.callbacks.SendLocalReply(403, msg, map[string]string{}, 0, \u0026amp;quot;bad-request\u0026amp;quot;) return api.LocalReply } return api.Continue } DecodeHeaders 是扩展 filter 必须实现的方法，我们就是在这个阶段对请求 header 进行校验。\nverify 是校验函数，这里的 RequestHeaderMap 是 Go 扩展提供的 interface，我们可以通过它来读写 header，其他都是常见的 Go 代码写法。\n五、编译\n编译很简单，与常见的 Go 编译一样，这里我们使用 Golang 官方的 docker 镜像来编译：\ndocker run --rm -v `pwd`:/go/src/go-filter -w /go/src/go-filter \\ -e GOPROXY=https://goproxy.cn \\ golang:1.19 \\ go build -v -o libgolang.so -buildmode=c-shared . Go 编译还是很快的，只需要几秒钟，当前目录下，就会产生一个 libgolang.so 的文件。反观 Envoy 的编译速度，一次全量编译动辄几十分钟，或者上小时的，这幸福感提升了不止一个档次。🥰\n六、运行\n我们可以使用 Envoy 官方提供的镜像来运行，如下示例：\ndocker run --rm -v `pwd`/envoy.yaml:/etc/envoy/envoy.yaml \\ -v `pwd`/libgolang.so:/etc/envoy/libgolang.so \\ -p 10000:10000 \\ envoyproxy/envoy:contrib-dev \\ envoy -c /etc/envoy/envoy.yaml 只需要把上一步编译的 libgolang.so 和 envoy.yaml 挂载进去就可以了。\n值得一提的是，我们需要在 envoy.yaml 配置中启用 Go 扩展，具体是这段配置：\nhttp_filters: - name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config library_id: example library_path: /etc/envoy/libgolang.so plugin_name: example-1 跑起来之后，我们测试一下：\n$ curl \u0026#39;http://localhost:10000/\u0026#39; missing token $ curl -s \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;token: c64319d06364528120a9f96af62ea83d\u0026#39; -I HTTP/1.1 200 OK 符合期望，是不是很简单呢？\n七、后续\n什么？这个示例太简单？\n是的，这里主要是体验下开发流程，下篇我们将再介绍更高级的玩法：\nGo 接受来自 Envoy 侧的配置、异步 Goroutine，以及与 Istio 配合的用法。\n｜相关链接｜\n[1]envoy-go-filter-example 仓库：\nhttps://github.com/doujiang24/envoy-go-filter-example/tree/master/example-1\n了解更多…\nMOSN Star 一下✨： https://github.com/mosn/mosn\n","date":1679986800,"description":"MoE 系列（一）｜如何使用 Golang 扩展 Envoy","dir":"blog/moe-series (1)|how-to-extend-envoy-with-golang/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e45d3681cf3bc1ea80ee4b37621b372a","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","publishdate":"2023-03-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","summary":"本文作为 MoE 系列第一篇，主要介绍用 Golang 扩展 Envoy 的极速开发体验。 一、背景 MoE*（MOSN on Envoy）*是 MOSN 团队提出的技术架构，经过近两年的发展，","tags":["SOFAStack"],"title":"MoE 系列（一）｜如何使用 Golang 扩展 Envoy","type":"blog","url":"/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","wordcount":1163},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区会议 Layotto 主题：Layotto 社区会议 时间：3 月 29 号（下周三）下午 14 点 钉钉会议令：688 824 34655 电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆） 钉钉入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2316789049\n议题： - 2023 开源之夏-课题/导师招募 #894 - Discussion: 自建各种 Component #902 - 希望 Layotto 提供高性能的通信交互能力 #867\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。 想要参加社区建设的同学可以关注社区的新手任务列表，总有一个适合你。\n「Layotto」：\nhttps://github.com/mosn/layotto/issues/907\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@kunple-w #916\n SpringBoot 2.2 废弃了 logging.path，2.3 已删除该属性，应使用 logging.file.pat。 Steps to reproduce the behavior： - 使用 SOFA 3.10.0，按照 SOFA guides 配置 logging.path，启动后并没有出现文档中的一些日志文件。 - 降级为 sample 中的 3.2.0 版本，日志文件出现。 截图如下（2个属性同时配置）: A：SOFA 中间件中使用 sofa-common-tools 打印的日志，日志空间和 SOFABoot 应用程序是隔离的。因此可以同时使用 logging.path 以及 logging.file.path 属性分别定义 SOFA 中间件和 SOFABoot 应用程序的日志路径。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n2.@shuangchengsun #263\n 客户端的上下线，Client1 处于下线过程，此时 Client1 在路由表中的状态是如何维护的？ A：data 上有一个定时器去维护每个 Session 相关数据的，如果 Session 挂了，data 大约 30s 后把挂掉的 Session 的数据清理掉，同时链接挂掉的 Session 上的的 Client（除掉了下的 Client） 会自动重新连接到其他 Session 上，然后会把数据增加一个版本重新注册到 Session 上，Session 会再发到那台数据上。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/issues/263\n本周推荐阅读 应用运行时 Layotto 进入 CNCF 云原生全景图\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1679641200,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230324/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"84510ab87fdbaaab0b53efb84b3e8d41","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230324/","publishdate":"2023-03-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230324/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230324/","wordcount":1242},{"author":null,"categories":"SOFAStack","content":"文｜黄逸炀\nDragonfly Maintainer\n字节跳动火山引擎软件工程师\n专注于镜像存储及镜像 P2P 分发\nPART. 0\n背景\n火山引擎镜像仓库 CR 使用 TOS 来存储容器镜像。目前在一定程度上能满足并发大规模的镜像拉取。然而最终拉取的并发量受限于 TOS 的带宽和 QPS。\n这里简单介绍一下目前针对于大规模拉镜像遇到的两个场景的问题：\n1、客户端数量越来越多，镜像越来越大，TOS 带宽最终无法满足需求。 2、如果客户端使用了 Nydus 对镜像格式做转换之后，对 TOS 的请求量会有数量级的增加，TOS API 的 QPS 限制导致无法满足需求。\n不论是镜像仓库服务本身还是背后的存储，最终肯定是有带宽和 QPS 限制的。如果单纯依赖服务端提供的带宽和 QPS，很容易就无法满足需求。因此需要引入 P2P ，减轻服务端压力，进而满足大规模并发拉取镜像的需求。\nPART. 1\n基于 P2P 技术镜像分发系统调研\n目前开源社区有几个 P2P 项目，这里对这些项目进行简单介绍。\nDragonfly\n架构图\n术语\nManager\n1、存储动态配置供 Seed Peer 集群、Scheduler 集群以及 Dfdaemon 消费。\n2、维护 Seed Peer 集群和 Scheduler 集群之间关联关系。\n3、提供统一异步任务管理，用作预热等功能。\n4、监听各模块是否健康运行。\n5、为 Dfdaemon 筛选最优 Scheduler 集群调度使用。\n6、提供可视化控制台，方便用户操作管理 P2P 集群。\nScheduler\n1、基于机器学习的多场景自适应智能 P2P 节点调度, 为当前下载节点选择最优父节点。\n2、构建 P2P 下载网络的有向无环图。\n3、根据不同特征值评估节点下载能力, 剔除异常节点。\n4、当下载失败情况，主动通知 Dfdaemon 进行回源下载。\nDfdaemon\n1、基于 gRPC 提供下载功能, 并提供多源适配能力。\n2、开启 Seed Peer 模式可以作为 P2P 集群中回源下载节点, 也就是整个集群中下载的根节点。\n3、为镜像仓库或者其他 HTTP 下载任务提供代理服务。\n4、下载任务基于 HTTP 或 HTTPS 或其他自定义协议。\nKraken\n架构图\n术语\nAgent\n1、是 P2P 网络中的对等节点，需要在每个节点上部署。\n2、实现了 Docker Registry interface。\n3、通知 tracker 自己拥有的数据。\n4、下载其他 agent 的数据（tracker 会告诉该 agent 需要下载这块数据需要到哪个 agent 上下载）\nOrigin\n1、负责从存储中读取数据做种。\n2、支持不同的存储。\n3、通过 Hash 环的形式保证高可用。\nTracker\n1、P2P 网络中的协调者，追踪谁是 Peer，谁是 Seeder。\n2、追踪 Peer 拥有的数据。\n3、提供有序的 Peer 节点供 Peer 下载数据。\n4、通过 Hash 环的形式保证高可用。\nProxy\n1、实现了 Docker Registry Interface。\n2、将镜像层传给 Origin 组件。\n3、将 Tag 传给 BUILD INDEX 组件。\nBuild-Index\n1、Tag 和 digest 映射，agent 下载对应 Tag 数据时向 Build-Index 获取对应的 Digest 值。\n2、集群之间镜像复制。\n3、保存 Tag 数据在存储中。\n4、通过 Hash 环的形式保证高可用。\nDragonfly vs Kraken\nPART. 2\n方案\n在火山引擎上，主要考虑 VKE 和 VCI 通过 CR 拉取镜像。\n1、VKE 的产品特点是基于 ECS 部署的 K8S，因此十分适合每个节点部署 Dfdaemon，充分利用每个节点的带宽，进而充分利用 P2P 的能力。\n2、VCI 的产品特点是底层有一些资源很充足虚拟节点。上层的服务是以 POD 为载体，因此无法像 VKE 那样每个节点部署 Dfdaemon，所以部署的形式部署几个 Dfdaemon 作为缓存，利用缓存的能力。\n3、VKE 或 VCI 客户端拉取经过 Nydus 格式转化过的镜像。在该场景下，需要使用 Dfdaemon 作为缓存，不宜使用过多的节点，避免对 Scheduler 造成过大的调度压力。\n基于火山引擎对于以上产品的需求，以及结合 Dragonfly 的特点，需要设计一套兼容诸多因素的部署方案。部署 Dagonfly 的方案设计如下。\nPART. 3\n整体架构图\n1、火山引擎上的资源都是归属于主账号下。P2P 控制组件以主账号级别隔离，每个主账号下一套 P2P 控制组件。服务端实现 P2P Manager Controller，通过该 Controller 来管控控制面所有 P2P 控制组件。\n2、P2P 控制组件部署在镜像仓库数据面 VPC，通过 LB 与用户集群打通。\n3、在 VKE 集群上，Dfdaemon 以 DaemonSet 方式部署，每个节点上部署一个 Dfdaemon。\n4、在 VCI 上，Dfdaemon 以 Deployment 方式部署。\n5、ECS 上 Containerd 通过 127.0.0.1:65001 访问本节点上的 Dfdaemon。\n6、通过在用户集群部署一个 controller 组件，基于 PrivateZone 功能，在用户集群生成.p2p.volces.com 域名， controller 会根据一定的规则挑选特定节点*（包括 VKE、VCI）*的 Dfdaemon pod，以 A 记录的形式解析到上述域名。\n ECS 上 Nydusd 通过.p2p.volces.com 域名访问 Dfdaemon。 VCI 上镜像服务客户端和 Nydusd 通过.p2p.volces.com 域名访问 Dfdaemon。 PART. 4\n压测数据\n环境\n镜像仓库：带宽 10Gbit/s。\nECS: 4C8G，挂载本地盘，带宽 6Gbit/s。\n镜像\nNginx (500M)\nTensorFlow (3G)\n组件版本\nDragonfly v2.0.8。\nQuota\nDfdaemon: Limit 2C6G。\nScheduler: 2 Replicas，Request 1C2G，Limit 4C8G。\nManager: 2 Replicas，Request 1C2G，Limit 4C8G。\nPOD 启动时间对比\nNginx Pod 分别并发 50、100、200、500 的所有 Pod 从创建到启动消耗时间。\nTensorFlow Pod 分别并发 50、100、200、500 的所有 Pod 从创建到启动消耗时间。\n在大规模拉镜像的场景下，在使用 Dragonfly 和 Dragonfly \u0026amp;amp; Nydus 场景对比 OCIv1 场景能够节省 90% 以上的容器启动时间。使用 Nydus 之后启动时间更短是因为镜像 lazyload 的特性，只需要拉取很小的一部分元数据 Pod 就能启动。\n存储源端带宽峰值对比\nNginx Pod …","date":1679382000,"description":"火山引擎基于 Dragonfly 加速实践","dir":"blog/volcano-engine-based-on-dragonfly-acceleration-practices/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"21e4e09162503066e2909a462942331d","permalink":"https://sofastack.github.io/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","publishdate":"2023-03-21T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","summary":"文｜黄逸炀 Dragonfly Maintainer 字节跳动火山引擎软件工程师 专注于镜像存储及镜像 P2P 分发 PART. 0 背景 火山引擎镜像仓库 CR 使用 TOS 来存储容器镜像。目前在一定程度上能满足并发","tags":["SOFAStack"],"title":"火山引擎基于 Dragonfly 加速实践","type":"blog","url":"/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","wordcount":3113},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议\nMOSN\n主题：MOSN 2023 社区会议 时间：3 月 23 号（下周四）晚上 19 点 钉钉会议号：689 448 86753 电话呼入：+862759771614（中国大陆） 钉钉入会链接：https://meeting.dingtalk.com/j/vvE0uCA0vQT\n议题： 回顾 MOSN 去年进展及今年的规划。 邀请部分 MOSN 用户来分享落地经验、发展规划。 共商 MOSN 2023 发展大计。\n另外，还邀请了 Higress 社区来互动交流，探讨合作空间。 Service Mesh、Gateway、Envoy、Istio、ztunnel 等等大家关注的话题，也可以在这里交流。欢迎大家参会讨论~\n「 MOSN 」：https://github.com/mosn/mosn\nLayotto\n主题：Layotto 社区会议 时间：3 月 22 号（下周三）下午 14 点 钉钉会议令：688 824 34655 电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆） 钉钉入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2299840541\n议题： Discussion: 自建各种 Component #902 希望 Layotto 提供高性能的通信交互能力 #867\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。 想要参加社区建设的同学可以关注社区的新手任务列表，总有一个适合你。\n「Layotto」： https://github.com/mosn/layotto/issues/902 https://github.com/mosn/layotto/issues/867\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@LY1806620741 #1061\ncom.alipay.sofa.rpc.enable-swagger 在 3.16.3 是否已经废弃\n配置使用了 Objectway 的 asm，与 Springboot 的 asm 冲突。 另外，没有在 SOFABoot 文档上找到所有的属性说明。\n重现该行为的步骤：\n运动单 SOFABoot\n配置 com.alipay.sofa.rpc.enable-swagger=true\n启动并访问*http://localhost:8341/swagger/bolt/api *\ndebug 可以看到找不到 class objectway.classvisitor\n引入 asm.jar 后会与 sping 框架的 asm org.springframework.asm.ClassVisitor 冲突\nA：看起来是 https:/github.com/sofastack/sofa-rpc/blob/5.8.3.1/all/pom.xml 少添加了一个 asm 的依赖，导致出现上面的问题。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n2.@springcoco #589\n关于多部网站代码解析的一些疑问，在多网站这一章节，发现这样说： 我的疑惑是 Spring 是如何判定 ArkTomcatEmbeddedWebappClassLoader 类存在呢？ 在加载 ArkTomcatServletWebServerFactory 的时候，我发现也会加载 Tomcat 默认的 Server Factory，如何最终判定周 WebServer 使用 ArkWebServerFacticServletTomcat 使用 Ark。 A：ArkTomcatEmbeddedWebappClassLoader 作为一个判断条件，如果没有使用 web-ark-plugin，意味着没有 ArkTomcatEmbeddedWebappCl\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/589\nMOSN 1.0 发布，开启新架构演进\n社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析\nMOSN 反向通道详解\n蚂蚁集团境外站点 Seata 实践与探索\n","date":1679036400,"description":"SOFA Weekly | MOSN、Layotto 社区会议通知、Seata 版本发布","dir":"blog/sofa-weekly-230317/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1827a7e4749437ae2082098f18a52e18","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230317/","publishdate":"2023-03-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230317/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、Layotto 社区会议通知、Seata 版本发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230317/","wordcount":1402},{"author":null,"categories":"SOFAStack","content":" 发布概览 Seata-go 1.1.0 版本补齐了 AT 模式下对 Multi Delete、Multi Update、Insert on Update 和 Select for Update 的支持。至此 Seata-go 的 AT 模式与 Seata AT 模式全面对齐。\n此版本给出了在 Dubbo-go/Gin/gRPC 中使用 Seata-go TCC/AT 两种模式的示例。\n示例链接：https://github.com/seata/seata-go-samples/tree/main/at\nAT 模式:\n AT 模式支持并集成了 Multi Delete SQL 语法 AT 模式支持并集成了 Multi Update SQL 语法 AT 模式支持并集成了 Insert on Update SQL 语法 AT 模式支持并集成了 Select for Update SQL 语法 配置文件：\n完善了更多地方读取配置文件功能\n版本的主要更新如下 Feature： [#491] 支持查询全局事务锁 https://github.com/seata/seata-go/pull/491\n[#482] 支持 AT 模式 Multi Delete SQL 执行器 https://github.com/seata/seata-go/pull/482\n[#481] 支持 AT 模式 Multi Update SQL 执行器 https://github.com/seata/seata-go/pull/481\n[#478] 支持 AT 模式 Select for Update SQL 执行器 https://github.com/seata/seata-go/pull/478\n[#477] 支持 Undo Log 的 Json 序列化方式 https://github.com/seata/seata-go/pull/477\n[#456] 支持 AT 模式 Insert on Update SQL 执行器 https://github.com/seata/seata-go/pull/456\n[#444] 支持 BZip 压缩算法 https://github.com/seata/seata-go/pull/444\n[#436] 支持读取 RM 相关的配置文件 https://github.com/seata/seata-go/pull/436\n[#433] 支持 XA 连接管理器 https://github.com/seata/seata-go/pull/433\n[#430] 支持读取 Getty 相关的配置文件 https://github.com/seata/seata-go/pull/430\nBugfix：\n[#509] 修复 AT 模式下执行 Insert on Update 时 Undo Log 的 SQLType 字段的问题 https://github.com/seata/seata-go/pull/509\n[#495] 修复 Undo Log 的 SQLType 字段的问题 https://github.com/seata/seata-go/pull/495\n[#487] 修复 AT 执行时出现的问题 https://github.com/seata/seata-go/pull/487\n[#472] 修复全局事务中上下文丢失值问题 https://github.com/seata/seata-go/pull/472\n[#461] 修复 Error_Code_test 中变量未定义导致的 CI 失败问题 https://github.com/seata/seata-go/pull/461\n[#459] 修复 Error 日志重复打印问题 https://github.com/seata/seata-go/pull/459\n[#452] 修复 AT 模式执行 Insert SQL 时 ID 增的报错问题 https://github.com/seata/seata-go/pull/452\nOptimize：\nSeata-go 的示例项目已经全部迁移到新的仓库：https://github.com/seata/seata-go-samples\n[#507] 优化 AT 模式 Multiple Update SQL 执行器 https://github.com/seata/seata-go/pull/507\n[#505] 优化 AT 模式 Multi SQL 执行器 https://github.com/seata/seata-go/pull/505\n[#453] 优化 Message Type 和 Transaction error Code 枚举值 https://github.com/seata/seata-go/pull/453\n[#447] 优化数据源初始化流程 https://github.com/seata/seata-go/pull/447\n[#466] 优化变量的命名 https://github.com/seata/seata-go/pull/466\nTest:\n[#445] 添加 Transaction error Code 的单元测试 https://github.com/seata/seata-go/pull/445\nDoc:\n[#492] 更新 Readme 文件的已完成功能列表 https://github.com/seata/seata-go/pull/492\n[#489] 添加 1.1.0 版本的 Change Log https://github.com/seata/seata-go/pull/489\n英文版：https://github.com/seata/seata-go/releases/tag/v1.1.0\n致谢\n非常感谢以下 Contributors 的代码贡献。若有无意遗漏，请报告。\n@luky116 https://github.com/luky116\n@georgehao https://github.com/georgehao\n@lxfeng1997 https://github.com/lxfeng1997 @106umao https://github.com/106umao @wang1309 https://github.com/wang1309 @iSuperCoder https://github.com/iSuperCoder @Charlie17Li https://github.com/Charlie17Li @Code-Fight https://github.com/Code-Fight @Kirhaku https://github.com/Kirhaku @Vaderkai https://github.com/VaderKai @springrain https://github.com/springrain @Shaozhou Hu https://github.com/raspberry-hu …","date":1678777200,"description":"Seata-go 1.1.0 发布，补齐 AT 模式支持","dir":"blog/seata-go-1-1-0-released-completes-at-mode-support/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e92a21aaa50425c14c2a8462c1d96e2e","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","publishdate":"2023-03-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","summary":"发布概览 Seata-go 1.1.0 版本补齐了 AT 模式下对 Multi Delete、Multi Update、Insert on Update 和 Select for Update 的支持。至此 Seata-go 的 AT 模式与 Seata AT 模式全面对齐。 此","tags":["SOFAStack"],"title":"Seata-go 1.1.0 发布，补齐 AT 模式支持","type":"blog","url":"/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","wordcount":1353},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@linkoog #602\n 首先我使用了 Ark-Guides 和 Ark-biz 的示例进行操作。 可以正常加载模板，但配置文件加载不到。 Start 是启动模块， Config 是配置的存储释放模块。 试了下面两种方式，都读到不到配置文件 1、直接打包 Config 的 Jar 中 2、在 Start 模板下面放 Conf/Ark/ 环境 沙发方舟版本：2.0.8 JVM 版本（例如 Java -Version ）：1.8.333 操作系统版本（例如 Uname -a ）：macOS 行家版本： 集成开发环境版本\n A：配置文件的配置应和 Spring Boot 应用保持一致，建议把配置文件放至 Resources 目录下。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/602\n2.@SpringLin97 #928\n Jraft 支持 IPV6 组建集群吗？\n A：1.3.5 以后版本支持 IPV6。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/928\n本周推荐阅读 DLRover：蚂蚁开源大规模智能分布式训练系统\nNydus 在约苗平台的容器镜像加速实践\nWasm 原生时代已经来到\nGo 语言，如何做逆向类型推导?\n","date":1678431600,"description":"SOFA Weekly | SOFANews、开源人 \u0026 issue 精选","dir":"blog/sofa-weekly-20230310/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c8fb3a67d5797275149ca3410ab9631e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230310/","publishdate":"2023-03-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230310/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、开源人 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230310/","wordcount":684},{"author":null,"categories":"SOFAStack","content":" 文｜沙剑 蚂蚁集团高级技术专家 专注分布式深度学习领域 主要负责蚂蚁大规模分布式训练引擎的设计和开发\n 本文 4491 字 阅读 12 分钟\n本文整体介绍了 DLRover 的项目动机与核心能力，未来我们会发布一系列文章，来从同步/异步弹性训练，优化策略服务，多种集群和训练框架对接，策略定制开发等多个角度来介绍 DLRover 的更多细节，敬请期待。\n技术背景 2022 年 6 月，蚂蚁集团决定全面引入 ESG 框架，启动并确立了“数字普惠”、“绿色低碳”、“科技创新”、“开放生态”四位一体的可持续发展战略。针对“绿色低碳”，设立了 4 个子议题，包括绿色运营、科技助力产业碳中和、生态保护与修复绿色低碳生活。\n在此背景下，绿色 AI 也成为蚂蚁 AI Infra 团队的一个重要工作方向。作为绿色 AI 的重要板块，工程提效项目致力于打造高性能离在线 AI 工程体系，通过提升算力效率和资源利用率，最终达到节省资源降低碳排放的目的。\n当前，用户提交分布式训练作业的工具有 Yarn 或者 KubeFlow/Training-Operator。在提交作业时，用户需要在作业中指定作业资源，包括不同角色的节点数量和资源规格（CPU 核数、内存、GPU 等）。\n在训练作业提交后，作业可能遇到如下问题： - 集群资源不足以启动作业的所有节点，作业只能等待。 - 训练作业的节点可能会出错，比如被高优任务抢占、机器故障、IO 故障等，导致作业失败。\n出现这些问题后，用户只能修改作业资源来重新提交作业。\n针对这两个问题，蚂蚁集团早期基于 Kubernetes 开源了 ElasticDL 项目来支持 K8s 上 TF 2.x 分布式训练的弹性容错。在项目落地过程中我们又发现了如下问题： - 用户配置的资源可能过少引起 OOM 和训练性能差。 - 用户为了保障作业成功率和速度，通常会配置超额资源导致利用率低。 - 越来越多的用户使用 PyTorch 或其他 TF 之外的框架来开发和训练模型。 - 越来越多的分布式集群开始支持 AI 作业，比如 Ray、Spark 集群，能否适配任意计算集群？ - 在线学习越来越被广泛采用的情况下，如何运用一套系统同时解决兼容离在线训练？\n前两个问题使得集群 CPU 利用率通常只有 20% 上下，同时算法开发人员需要投入很多人工运维成本，为了解决训练端资源提效的需求，支持在不同集群上针对在离线多种训练模式，给不同框架的分布式训练作业自动地寻找最优资源配置。\n蚂蚁 AI Infra 团队基于 ElasticDL 弹性容错的思路，升级扩展并开源了 DLRover，其目标在于提升分布式模型训练的智能性，目前很多公司的训练作业都是跑在混部的集群中，运行环境复杂多变，正如其名，DLRover 作为分布式训练领域的 “路虎”，不管多么崎岖的地形，都可以轻松驾驭。\n整体方案 DLRover 提出了 “ML for System” 的理念来提升分布式训练的智能性，那么这样的系统应该具备哪些能力呢？\n我们认为主要体现在如下几个方面： - 解耦：不和底层训练框架耦合在一起，只依赖接口抽象，遵循依赖倒置原则。（*i.e. Elastic Runtime*） - 资源调度：具备上帝视角的资源调度管控能力。和建立在对作业精准画像的决策能力。 - 数据驱动：同时收集掌握集群资源数据，也掌握训练作业数据。以数据驱动智能。 - 作业交互：以对训练作业以及模型白盒化的理解，动态根据实际情况，对训练作业进行优化调整。超越简单机械的弹性容错！ - 智能：通过对集群以及作业信息的收集，结合算法模型+固定策略产出精准的作业优化策略。\n我们希望设计并实现一个系统，让用户完全摆脱资源配置的束缚，专注于模型训练本身。在没有任何资源配置输入的情况下，DLRover 仍然可以为每个训练作业提供最佳资源配置。考虑到用户可能会以不同的方式运行他们的训练作业，DLRover 除了面向训练平台进行作业统一管理的 Cluster Mode，也提供 Single-Job Mode 方便独立的算法开发者也能享受到弹性容错等基本特性。\n系统架构 DLRover 由四个主要组件组成：ElasticJob、Elastic Trainer、Brain 服务和 Cluster Monitor。\n上图显示了 DLRover 如何在 K8s 集群上管理深度学习训练作业。DLRover 以 ElasticJob CRD 的形式将作业提交到集群。收到 CRD 后，ElasticJob Operator 会拉起一个 Master Pod 作为 Elastic Trainer。其从 Brain 服务中获取初始资源计划。Elastic Trainer 用它来创建 Scale CRD，并应用 Scale CRD 通知 ElasticJob Controller 启动所需的 Pod，每个 Pod 将在其上启动一个 Elastic Agent。\n在训练过程中，Elastic Trainer 的 Training Master 将数据分片分发给 Worker。同时，Cluster Monitor 监控每个作业的运行状态（*i.e.每个节点的 Workload*）和集群状态（*i.e. 资源水位*）。这些数据将定期报告给 Brain，Brain 将数据持久化到数据库中。\n然后 DLRover Brain 根据作业的运行状态，选择合适的算法生成新的资源计划，并通知 Elastic Trainer 开始资源调整。\n总的来讲，DLRover 可以帮助分布式训练作业自动化运行在集群中，可以看作分布式作业的自动驾驶，模型开发者只需要关注模型的算法设计，DLRover 目前开源版则可以为用户提供如下能力： - 自动资源推导：帮助用户自动初始化训练资源，提升资源利用率与作业稳定性。 - 动态训练数据分片：针对不同 Worker 性能不通造成的木桶效应，根据实际消费速度分配训练数据，可配合 Failover 记录消费位点，数据不丢失。 - 单点容错：提供单点容错的能力，不需要完整重启作业。 - 资源弹性：支持运行时 Pod 级和 CPU/Memory 级的资源弹性扩缩容，动态全局优化决策。\nDLRover 能带来什么 1.作业零资源参数配置 用户提交分布式作业时无需提供任何资源信息，DLRover 会自动对作业进行画像，推导出最优的资源配置，同时运行时可以根据实际情况（*集群资源、样本流量、当前利用率、\u0026amp;hellip;*）自动对资源进行调整。下面展示了两种提交脚本的配置对比：\n2.单点容错提升作业稳定性与恢复效率 DLRover 支持单点恢复 Parameter Server 和 Worker 角色的失败退出而不需要整体作业重启，对于非用户代码和数据类型的错误可以实现用户无感的重启。例如集群中，很常见的一类错误是由于用户配置了不足的内存，导致训练 OOM。在 DLRover 的帮助下，我们可以自动拉起一个优化配置的节点来恢复失败的 Node。在真实环境下，DLRover 管理的训练作业，相比基线的 Kubeflow TF-Operator 作业，训练成功率从 84% 提升到了 95% 以上。 …","date":1678172400,"description":"DLRover：蚂蚁开源大规模智能分布式训练系统","dir":"blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d19aa2ffa0b2368819bac80add901dfb","permalink":"https://sofastack.github.io/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","publishdate":"2023-03-07T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","summary":"文｜沙剑 蚂蚁集团高级技术专家 专注分布式深度学习领域 主要负责蚂蚁大规模分布式训练引擎的设计和开发 本文 4491 字 阅读 12 分钟 本文整体介绍了 DLRover 的项目动机与","tags":["SOFAStack"],"title":"DLRover：蚂蚁开源大规模智能分布式训练系统","type":"blog","url":"/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","wordcount":3919},{"author":null,"categories":"SOFAStack","content":" SOFA Weekly｜铜锁探「密」、本周贡献 \u0026amp;amp; issue 精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@ZhengweiHou #1313\n 同一台机器启动两个 SOFA 进程，开启端口自适应（AdaptivePort），但是两个进程服务注册端口一致，但实际生效端口不一致。通过验证端口自适应逻辑发现我的机器上（ServerSocket.bind) 预期结果不一致。详细情况如图所示：\n A：AdaptivePort 的逻辑在 可以看下这块代码。\ncom.alipay.sofa.rpc.server.ServerFactory#resolveServerConfig\n和你理解的应该不太一样。\n「SOFARPC」: https://github.com/sofastack/sofa-rpc/issues/1313\n**2.@hanzhihua ** #934\n 咨询一个问题，Closure Threadpool 使用 SynchronousQueue 而不使用其他的有缓存的 Queue，是怎么考虑的呢？\n A：主要是原因是希望在任务量大 Core Thread 饱和的时候尽快新增线程来更快的处理任务，中间加一个 Queue 会影响到，Java Threadpool 的策略你懂的，需要 Queue 满了后 MaximumThreads 参数的值才发挥作用。\n「SOFAJRaft」： https://github.com/sofastack/sofa-jraft/issues/934\n3.@penglinzhang #612\n 静态合并部署时，为什么宿主应用会把子业务应用中的 Bean 也会扫描注册到自己的 ApplicationContext 中，而不是仅仅把子应用作为一个特殊 Jar 包？\n A：由于你的宿主应用 @ComPonentScan 扫描了 “com.alipay.sofa”，并且你的业务 Bean 也是 com/alipay/sofa 路径下的，你可以尝试将业务包 Spring-Boot-Ark-Biz 的路径改成自定义的。\n「SOFAArk」： https://github.com/sofastack/sofa-ark/issues/612\n本周推荐阅读\nSOFARegistry | 聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1677826800,"description":"","dir":"blog/sofa-weekly-20230303/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1b93b164611c557c53757d288b2e2d77","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230303/","publishdate":"2023-03-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230303/","summary":"SOFA Weekly｜铜锁探「密」、本周贡献 \u0026amp; issue 精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Sta","tags":["SOFAStack"],"title":"SOFA Weekly｜铜锁探「密」、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230303/","wordcount":802},{"author":null,"categories":"SOFAStack","content":" 文 | 向申 约苗平台运维工程师 关注云原生领域\n本文字数 9574 阅读时间 24 分钟\n 本文是来自向申同学的分享，介绍了其在 K8s 生产环境集群部署 Nydus 的相关实践。\nNydus 是蚂蚁集团，阿里云和字节等共建的开源容器镜像加速项目，是 CNCF Dragonfly 的子项目，Nydus 在 OCI Image Spec 基础上重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。详情文档请参考如下地址：\n Nydus 官方网站：https://nydus.dev/\n Nydus Github：https://github.com/dragonflyoss/image-service\n PART.1\n容器镜像的概念 1. 容器镜像 容器镜像有一个官方的类比，\u0026amp;rdquo;生活中常见的集装箱\u0026amp;rdquo;，虽然拥有不同的规格，但箱子本身是不可变的（*Immutable*），只是其中装的内容不同。\n对于镜像来说，不变的部分包含了运行一个应用软件（如 MySQL ）所需要的所有元素。开发者可以使用一些工具（*如 Dockerfile*）构建出自己的容器镜像，签名并上传到互联网上，然后需要运行这些软件的人可以通过指定名称（*如 example.com/my-app*）下载、验证和运行这些容器。\n2. OCI 标准镜像规范 在 OCI 标准镜像规范出台之前，其实有两套广泛使用的镜像规范，分别是 Appc 和 Docker v2.2，但“合久必分，分久必合”，有意思的是两者的内容已经在各自的发展中逐步同化了，所以 OCI 组织顺水推舟地在 Docker v2.2 的基础上推出了 OCI Image Format Spec，规定了对于符合规范的镜像，允许开发者只要对容器打包和签名一次，就可以在所有的容器引擎上运行该容器。\n这份规范给出了 OCI Image 的定义：\nThis specification defines an OCI Image, consisting of a manifest, an Image Index (optional), a set of filesystem layers, and a Configuration.\n3. 容器的工作流程 一个典型的容器工作流程是从由 Developers 制作容器镜像开始的（*Build*），然后上传到镜像存储中心（*Ship*），最后部署在集群中（*RUN*）。\nPART.2\nOCI 镜像格式 通常所说的镜像文件其实指的是一个包含了多个文件的“包”，“包”中的这些文件提供了启动一个容器所需要的所有需要信息，其中包括但不限于，容器所使用的文件系统等数据文件，镜像所适用的平台、数据完整性校验信息等配置文件。当我们使用 Docker pull 或者 Nerdctl pull 从镜像中心拉取镜像时，其实就是在依次拉取该镜像所包含的这些文件。\nNerdctl 依次拉取了一个 Index 文件、一个 Manifest 文件、一个 Config 文件和若干个 Layer 数据文件。实际上，一个标准的 OCI 镜像通常就是由这几部分构成的。\n其中，Layer 文件一般是 tar 包或者压缩后的 tar 包，其包含着镜像具体的数据文件。这些 Layer 文件会共同组成一个完整的文件系统（*也就是从该镜像启动容器后，进入容器中看到的文件系统*） 。\nConfig 文件是一个 JSON 文件。其中包含镜像的一些配置信息，比如镜像时间、修改记录、环境变量、镜像的启动命令等等。\nManifest 文件也是一个 JSON 文件。它可以看作是镜像文件的清单，即说明了该镜像包含了哪些 Layer 文件和哪个 Config 文件。\n下面是一个 Manifest 文件的典型例子：\n\u0026amp;quot;schemaVersion\u0026amp;quot;: 2, \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.manifest.v1+json\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.config.v1+json\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:0584b370e957bf9d09e10f424859a02ab0fda255103f75b3f8c7d410a4e96ed5\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 7636 }, \u0026amp;quot;layers\u0026amp;quot;: [ { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:214ca5fb90323fe769c63a12af092f2572bf1c6b300263e09883909fc865d260\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 31379476 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:50836501937ff210a4ee8eedcb17b49b3b7627c5b7104397b2a6198c569d9231\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 25338790 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:d838e0361e8efc1fb3ec2b7aed16ba935ee9b62b6631c304256b0326c048a330\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 600 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:fcc7a415e354b2e1a2fcf80005278d0439a2f87556e683bb98891414339f9bee\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 893 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: …","date":1677567600,"description":"Nydus 在约苗平台的容器镜像加速实践","dir":"blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7e9b91c041e413e6e7587da7c34f0e22","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","publishdate":"2023-02-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","summary":"文 | 向申 约苗平台运维工程师 关注云原生领域 本文字数 9574 阅读时间 24 分钟 本文是来自向申同学的分享，介绍了其在 K8s 生产环境集群部署 Nydus 的相关实践。 Nydus 是蚂蚁","tags":["SOFAStak"],"title":"Nydus 在约苗平台的容器镜像加速实践","type":"blog","url":"/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","wordcount":4215},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 4 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@linkoog #602\n SOFAArk 2.0 合并部署时，ark-biz 无法读取配置文件\n A：配置文件的配置应该和 Spring Boot 应用保持一致，建议把配置文件放置到 resources 目录下。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.@tdxafpdq #925\n 消息中间件业务场景下，如何使用 Snapshot 服务，以解决磁盘占用持续增长以及全量回放变慢。\n A：消息场景下，还是控制消息的总量，通过 TTL 等机制来及时删除过期的消息，如果是同步数据库的场景，可以使用 Snapshot 来做检查点（Checkpoint），Snapshot 本身可能只做一些数据库状态校验的动作，确保 Snapshot log index 之前的日志都已经同步复制完成，然后 JRaft 就可以释放之前的日志。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 SOFARegistry｜聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1676617200,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230217/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f937156cef65231cd51d07b5c8c4f9c7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230217/","publishdate":"2023-02-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230217/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230217/","wordcount":695},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区\n 活动时间：02 月 25 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：待直播后更新\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#32 你的开源入门指南——Kata Containers 社区 如今“参与开源”已然成为很多技术人追赶的浪潮。但有些人苦于找不到参加途径，有些人畏畏缩缩不敢发声，或者是由于开源项目众多，不知道该如何挑选\u0026amp;hellip;\u0026amp;hellip;在本期 SOFAChannel#32 的节目中，我们邀请到了 Kata Containers 社区新星姚胤楠同学，给大家带来开源入门指南！Kata Containers 是一种基于硬件虚拟化技术、兼容 OCI/CRI 等协议的容器运行时技术，可以完美地运行在 Kubernetes 集群之上。Kata Containers 比传统容器提供了更高的安全性和更强的隔离性，同时具备快速启动和部署的优势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 姚胤楠\n Kata Containers Contributor\n 议程 直播回放 待直播后更新\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1676530800,"description":"2023 年 02 月 25 日 19：00 - 20：00 ，线上直播第 32 期。","dir":"activities/sofa-channel-32/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7ece90c394a1f25d260f0d79aa6a80b0","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-32/","publishdate":"2023-02-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-32/","summary":"概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区 活动时间：02 月 25 日，周四晚 19 点 活动形式：线上直播 资料下载：待","tags":["SOFAChannel","Kata Containers","你的开源入门指南"],"title":"SOFAChannel#32 你的开源入门指南——Kata Containers 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-32/","wordcount":569},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区\n 活动时间：02 月 25 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：待直播后更新\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#32 你的开源入门指南——Kata Containers 社区 如今“参与开源”已然成为很多技术人追赶的浪潮。但有些人苦于找不到参加途径，有些人畏畏缩缩不敢发声，或者是由于开源项目众多，不知道该如何挑选\u0026amp;hellip;\u0026amp;hellip;在本期 SOFAChannel#32 的节目中，我们邀请到了 Kata Containers 社区新星姚胤楠同学，给大家带来开源入门指南！Kata Containers 是一种基于硬件虚拟化技术、兼容 OCI/CRI 等协议的容器运行时技术，可以完美地运行在 Kubernetes 集群之上。Kata Containers 比传统容器提供了更高的安全性和更强的隔离性，同时具备快速启动和部署的优势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 姚胤楠\n Kata Containers Contributor\n 议程 直播回放 待直播后更新\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1676444400,"description":"2023 年 02 月 16 日 19：00 - 20：00 ，线上直播第 32 期。","dir":"activities/sofachannel-32/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f529a5fffabf35600dcecdc9b513fe85","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofachannel-32/","publishdate":"2023-02-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofachannel-32/","summary":"概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区 活动时间：02 月 25 日，周四晚 19 点 活动形式：线上直播 资料下载：待","tags":["SOFAChannel","Kata Containers","你的开源入门指南"],"title":"SOFAChannel#32 你的开源入门指南——Kata Containers 社区","type":"activities","url":"/sofastack.tech/activities/sofachannel-32/","wordcount":569},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者蚂蚁集团技术专家\n专注于云原生网关研发的相关工作。\n本文 224 字 阅读 8 分钟\nPART. 1\n引言 在上回的文章《Go 内存泄漏，pprof 够用了么？》中说到，从一个 core 文件生成内存引用关系火焰图时，虽然可以从 core 文件中读到所有的内存对象，但是并不知道它们的类型信息。\n这是因为 Go 作为静态类型语言，在运行时，内存对象的类型是已知的。也就是说，并不需要想动态类型语言那样，为每个内存对象在内存中存储其类型信息 （有点例外的是 interface） 。\n比如这个 Go 语言例子：\ntype Foo struct { a uint64 b int64} func foo(f *Foo) int64 { return f.b} Foo 函数在使用 f 这个指针时，并不需要判断其类型，直接读一个带偏移量地址就能得到 f.b，也就是一条指令：mov rax, qword ptr [rax + 8]，就是这么简单直接。\n再看 Lua 语言这个例子：\nfunction foo(f) return f.bendfoo({ b = 1 }) Foo 函数在执行的时候，首先得判断 f 的类型，如果是 table，则按照 key 取 b 的值；如果不是，则抛运行时 error。\n能够运行时判断 f 的类型，是因为 Lua 中变量是用 TValue 来表示的，这个 TValue 结构中，就有一个信息用来存储变量类型。\nPART. 2\n逆向类型推导 逆向类型推导的逻辑是：根据已知内存的类型信息，推导被引用的内存对象的类型信息。\n比如这个例子：\ntype Foo struct { a uint64 b int64}type Bar struct { f *Foo}var b Bar 如果我们知道了 b 的类型是 Bar，那么 b 中第一个 field 指向的内存对象，就是 Foo 类型了 （前提是合法的内存对象地址） 。\n既然存在推导，那我们怎么知道一些初始值呢？\n一共有两类来源：\n1.全局变量；\n2.协程中每一帧函数的局部变量。\nPART. 3\n全局变量 Go 在编译的时候，默认会生成一些调试信息，按照 DWARF 标准格式，放在 ELF 文件中 .debug_* 这样的段里。\n这些调试信息中，我们关注两类关键信息：\n 类型信息： 包括了源码中定义的类型，比如某个 struct 的名字、大小、以及各个 field 类型信息；\n 全局变量： 包括变量名、地址、类型，调试信息中的、全局变量的地址、以及其类型信息，也就是构成推导的初始值。\n 函数局部变量，要复杂一些，不过基本原理是类似的，这里就不细说了~\nPART. 4\n推导过程 推导过程，跟 GC-Mark 的过程类似，甚至初始值也跟 GC-Root 一样。\n所以，全部推导完毕之后，GC-Mark 认为是 alive 的内存对象，其类型信息都会被推导出来。\ninterface\nGo 语言中 interface 比较类似动态类型，如下是空接口的内存结构，每个对象都存储了其类型信息：\ntype eface struct { _type *_type data unsafe.Pointer} 按照类型推导，我们能知道一个对象是 interface{}，但是其中 Data 指向对象，是什么类型，我们则需要读取 _type 中的信息了。\n_type 中有两个信息，对我们比较有用：\n1.名字\n不过比较坑的是，只存了 pkg.Name 并没有存完整的 Include Path 这个也合理的，毕竟 Go 运行时并不需要那么精确，也就是异常时，输出错误信息中用一下。不过在类型推导的时候，就容易踩坑了。\n2.指针信息\n具体存储形式有点绕，不过也就是表示这个对象中，有哪些偏移量是指针。\n有了这两个信息之后，就可以从全量的类型中，筛选出符合上面两个信息的类型。\n通常情况下，会选出一个正确的答案，不过有时候选出多个，仅仅根据这两个信息还不能区分出来，一旦一步错了，后面可能就全推导不出来了。\n我们给 Go 官方 Debug 贡献了一个补丁，可以进一步的筛选，有兴趣的可以看 CL 419176[1]。\nunsafe.pointer\n其实，在上面的 interface 示例中，最根源的原因，也就是 data unsafe.pointer，这个指针并没有类型信息，只是 interface 的实现中，有另外的字段来存储类型信息。\n不过，在 Go Runtime 中还有其它的 unsafe.pointer，就没有那么幸运了。\n比如 map 和 sync.map 的实现都有 unsafe.pointer，这种就没有办法像 interface 那样统一来处理了，只能 case-by-case，根据 map/sync.map 的结构特征来逆向写死了\u0026amp;hellip;\n我们给 Go 官方 Debug 贡献了 sync.map 的逆向实现，有兴趣的可以看 CL 419177[2]。\nPART. 5\n隐藏类型 除了源码中显示定义的类型，还有一些隐藏的类型，比如：Method Value、Closure 的实现中，也都是用 struct 来表示的，这些属于不太容易被关注到的“隐藏”类型。\nMethod Value 在逆向推导中，还是比较容易踩坑的，我们给 Go 官方 Debug 贡献了这块的实现，有兴趣的可以看 CL 419179[3]。\n相比 Method Value 这种固定结构的，Closure 这种会更难搞一些，不过幸运的是，我们目前的使用过程中，还没有踩坑的经历。\nPART. 6\n逆向推导风险 这种逆向推导要做到 100% 完备还是挺难的，根本原因还是 unsafe.pointer。\n在 reflect.Value 中也有 unsafe.pointer，据我所知，这个是还没有逆向推导实现的，类似的应该也还有其它未知的。\n甚至，如果是标准库中的类型，我们还是可以一个个按需加上，如果是上层应用代码用到的 unsafe.pointer，那就很难搞了。\n还有一种可能，推导不出来的原因，就是内存泄漏的来源，我们就碰到这样一个例子，以后有机会再分享~\n幸运的是：如果是只是少量的对象没有推导出来，对于全局内存泄漏分析这种场景，通常影响其实也不大。\n另外，对于一个对象，只需要有一个路径可以推导出来也就够了。\n也就是说，如果一条推导线索因为 unsafe.pointer 断了，如果另外有一个线索可以推导到这个对象，那也是不影响的。因为从 GC root 到一个 GC obj 的引用关系链，可能会不止一条。\nPART. 7\n小结 Go 虽然是静态类型语言，不过由于提供了 unsafe.pointer，给逆向类型推导带来了很大的麻烦。好在 Go 对于 unsafe.pointer 的使用还是比较克制，把标准库中常用到的 unsafe.pointer 搞定了，基本也够用了。\n理论上来说，逆向推导这一套也适用于 C 语言，只不过 C 语言这种指针漫天飞的，动不动就来个强制类型转换，就很难搞了。\n｜相关链接｜\n[1]CL …","date":1676358000,"description":"Go 语言，如何做逆向类型推导?","dir":"blog/Go-language-how-to-do-inverse-type-derivation/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"38703e8299b15a8a7e65645ff69c5926","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","publishdate":"2023-02-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者蚂蚁集团技术专家 专注于云原生网关研发的相关工作。 本文 224 字 阅读 8 分钟 PART. 1 引","tags":["MOSN"],"title":"Go 语言，如何做逆向类型推导?","type":"blog","url":"/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","wordcount":2248},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 8 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@shuangchengsun #266\n 我想知道对于 SOFARegistry 这样的系统是如何定义 SLA 的，以及有没有一个参考值。\n A：一般 SLA 的定义和系统的关键指标相关，类似 Registry 的核心就是 Pub Sub 模型，Pub 列表变化后及时推送给 Sub；那么 SLA 的定义就可以从类似 Pub 变更后在多长的周期内能推送给所有的 Sub，这个成功率应该高于多少。参考值这个看系统维护者对这个系统的要求吧，这个没什么标准值。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/\n2.@郑长青 #2197\n 我在宿主应用使用 Ark Biz，采用 Maven 依赖方式静态合并部署，但是通过 biz-a 查看，没有启动业务应用，这个问题遇到过吗？\n A：是打包业务 Biz 的 declared-libraries 赋值问题，所以动态部署和静态部署使用 2.1.0 版本的 sofa-ark-maven-plugin 插件无法正常运行。Bug 修复的 PR 已经合并，预计周五（2 月 10 日）发布新 2.1.1 版本。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/\n本周推荐阅读 Special Weekly | 瑞兔送福，Live Long and Prosper\nSOFARegistry | 大规模集群优化实践\nNydus 加速镜像一致性校验增强\n一个 go-sql-driver 的离奇 bug\n欢迎扫码关注：\n","date":1676012400,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230210/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4c87dfeed2681923e2afaa93b04009bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230210/","publishdate":"2023-02-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230210/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230210/","wordcount":728},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@wwg2017 #5222\n 如果二阶段提交 ：1.服务端没有接收到 TM 请求 report ；2. 服务端请求没有下发下来客户端没有接收到；3.客户端接收到了执行失败了。请问上面三种情况的话，对数据订单影响是什么？\n A：第一种情况会等到超时时间，默认是 60 秒后进行回滚。在 AT 模式下，订单数据由于是一个一阶段提交会有短暂的读未提交问题，这个需要按 @globallock 注解 +select for update 达到分布式下读已提交，但是会被阻塞到事务回滚后才可读到（默认 60s）。后面两种情况都会进行无限间隔 1s 的重试直至成功回滚/提交。\n「Seata」：https://github.com/seata/seata\n2.@antjack #2197\n Allow Setting Cluster Idle Timeout to Zero to Indicate Never Timeout.This issue requests the ability to set an idle_timeout = 0, to indicate the indefinite idle timeout for upstream connection timeout.\n 「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 Special Weekly | 瑞兔送福，Live Long and Prosper\nSOFARegistry | 大规模集群优化实践\nNydus 加速镜像一致性校验增强\n一个 go-sql-driver 的离奇 bug\n欢迎扫码关注：\n","date":1675407600,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230203/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"17cef13c896ee0712ff7fad78ebafe52","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230203/","publishdate":"2023-02-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230203/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230203/","wordcount":656},{"author":null,"categories":"SOFAStack","content":" 导言：\n GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。这是去年（2022）的夏令营活动中，王瑞同学参加 Nydus 开源项目的总结，主要介绍了为 Nydus 支持镜像与文件系统一致性校验所做的相关工作。\n Nydus 简介 Nydus 是 CNCF 孵化项目 Dragonfly 的子项目，它提供了容器镜像，代码包，数据分析按需加载的能力，无需等待整个数据下载完成便可开始服务。\nNydus 在生产环境已经支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，网络带宽效率，端到端数据一致性等方面相比 OCIv1 格式有着巨大优势，并可扩展至例如 NPM 包懒加载等数据分发场景。\n目前 Nydus 由蚂蚁集团，阿里云，字节跳动联合开发，Containerd，Podman 社区接受了 Nydus 运行时作为其社区子项目，也是 KataContainers 以及 Linux v5.19 内核态原生支持的镜像加速方案。\nNydus 架构及原理 OCI 容器镜像是当前容器镜像的实现标准。它采用了分层的设计，每个镜像可包含多个镜像层。新层包含的是在旧层的基础上，新增加或者修改的文件或者被删除的文件。这种设计方式比较简单，不过也有着一定的缺陷。如需要镜像层全部堆叠后才能看到整个文件系统的视图，但不是所有数据都会被读取;同时可能已经删除或者被修改旧层中的文件，但是仍需要完整地下载和解压旧层;文件元数据修改导致整个镜像层被重新存储等。 Nydus 兼容目前的 OCI 生态，旨在通过细粒度的数据分割、去重和按需加载机制加速容器 的启动和分发，同时降低资源的消耗。\nNydus 的整体架构如下图所示。它可以通过 FUSE 给 runc 容器提供运行时的按需加载能力，也可以通过 virtiofs 承载 FUSE 协议，给 Kata Containers 等基于 VM 的容器运行时提供按需加载的能力。它可以从容器 Registry，OSS，NAS，Dragonfly supernode 等多个镜像源拉取镜像，同时内部会有本地的缓存加速容器的创建。\n在用户空间文件系统，Nydus 采用了数据和元数据分离的设计思想，元数据的修改不会导致整个镜像层的更新。原先的镜像层只存储文件的数据部分，同时数据被分块存储。拉取镜像是不需要拉取整层，只需要拉取所需文件对应的数据块即可。这也使得层与层之间，镜像与镜像之间共享数据块更加容易。上图展示了 Nydus 数据和元数据的存储格式。其中元数据以 merkle tree 的形式存储在 bootstrap 中，包含了容器启动所需要的信息。数据以 1MB 分块存储，不同镜像可以共享同一数据块。\nNydus 镜像校验意义及流程 Nydus 镜像在构建完成后，由于网络、磁盘等故障或者镜像被恶意修改，无法保证容器启动前镜像是合法的，所以需要对镜像的格式进行校验。当前的校验使用 nydusify 工具。主要分为三个部分:\n 对 Nydus 镜像的 bootstrap 进行校验，会通过 BootstrapRule 调用 nydus-image 二进制文件。nydus-image 首先检查 bootstrap 的 SuperBlock 格式是否正确，然后会从根结点开始按照文件系统层级结构检查文件或者目录的 inode 是否合法或被修改。\n 对镜像的 manifest 进行校验，会通过 ManifestRule 检验 Nydus 的 manifest 是否合法，ImageConfig 是否与原始 OCI 镜像一致等。\n 对镜像进行文件系统校验，会通过 FilesystemRule 分别挂载原始 OCI 镜像和 Nydus 镜像，然后进行校验。对于原始镜像，会使用 docker pull 拉取镜像，然后指定 lowerdir 和 upperdir，通过 OverlayFS 挂载 Rootfs；对于 Nydus 镜像，会使用 Nydusd 挂载。挂载完成后，会分别遍历两个目录，比较元数据和数据是否一致。\n 目前 Nydus 的校验方式仍有一定的限制，如元数据检查不完全，需要 docker 拉取镜像等。该项目旨在增强 nydusify 和 nydus-image 的校验功能，使校验更加易用和全面。\n文件系统校验方案 该项目当前分为以下三部分:\n 当前 nydusify check 在应用 FilesystemRule 进行校验时，对于文件元数据只检查文件路径、大小、模式和权限位以及 xattrs 是否和原始镜像一致，同时对文件数据用 blake3 计算得到哈希值并进行比较。但是由于校验内容不完整，可能会出现元数据不一致校验通过的情况。故对该结构体添加 dev、rdev、symlink、project id、uid、gid、nlink、ctime 等字段，实现对文件元数据更全面的检查。 当前 nydusify check 在应用 FilesystemRule 进行校验时，需要手动指定 source 和 Backend Type, Backend Config 才能成功应用 Nydusd 挂载并进行文件系统校验，在校验数据时，也会再次检查 Backend Type 是否指定。在大多数情况下，Backend Type 为 Registry，Backend Config 可以通过查看 Registry 的 config 文件获取相关信息，如 http.addr 字段获取地址，auth 字段获取认证信息等获取。因而用户在很多情况下并不需要手动输入上述参数。该任务旨在简化该命令，实现 Backend Type，Backend Config 的自动推断，使得用户更方便地进行校验。 (3) 当前 nydusify check 在应用 FilesystemRule 进行校验时，需要用户安装 docker，因为要使用 docker pull 命令拉取镜像。在没有 docker 的环境下，无法完成校验。可以修改该部分代码，手动下载、解压镜像，并使用 OverlayFS 挂载，从而去除对 docker 的依赖。\n文件系统校验实现细节 增加校验字段 该部分的实现较为简单。首先在原 Node 结构体增加 rdev, symlink, uid, gid, mtime 等字段。\n然后在遍历文件系统时，使用 Readlink 获取文件的软链接，通过 Lstat 系统调用获取 文件更详细的元数据信息（rdev, uid, gid, mtime 等），从而在进行比较时增加对上述字段的校验。值得注意的是 dev 不同是正常的，nlink 由于 OverlayFS 的问题无法进行校验。此外，还需要修改异常错误信息，从而遇到不一致时能够打印完整的文件元数据信息。\n简化校验参数 该部分需要实现 Backend Type 和 Backend Config 的自动推断，即如果镜像存储在 registry 中，用户无需指定上述两个参数即可完成校验。\n首先，我们需要添加上述结构体，即镜像源为 Registry 时的 Backend Config。对 …","date":1675148400,"description":"Nydus 加速镜像一致性校验增强","dir":"blog/nudus-20230131/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"483248448e3baf3c9667fae7d625f0e5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nudus-20230131/","publishdate":"2023-01-31T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/nudus-20230131/","summary":"导言： GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。这是去年（2022）的","tags":["SOFAStack"],"title":"Nydus 加速镜像一致性校验增强","type":"blog","url":"/sofastack.tech/blog/nudus-20230131/","wordcount":3175},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack GitHub issue 精选 本周各项目回复 issue 共计 5 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @fengjiachun #951\n 怎么通过GitHub Action 自动发布新版本 jar 到 maven 库？\n A：把 autoReleaseAfterClose 设置为 true，可以非常方便。\n「SOFAJraft」：https://github.com/sofastack/sofa-jraft/\n2. @canaan-wang #859\n Layotto 为什么要开发 SDK ？SDK 中的功能代码为什么不可以迁移到 Server 端？\n A：对于一些熟悉 gRPC 的用户来说，Client 端直接裸用 gRPC 都可以，但这种方式对于应用开发者是有理解成本的，所以 Layotto 的 SDK 提供的更多的是接口定义，让用户编程的时候不需要直接面向裸漏的 gRPC。举个简单的例子：假设用户可以往 gRPC 的 header 里面塞一个字段 “rpc-remote-address” 该字段用来指定 RPC 访问的远端目标地址，那么如果没 SDK，用户就得知道两件事：字段名和如何塞字段到 gRPC 的 header。但如果有 SDK，你可以提供一个函数 SetRpcTargetAddress（Address String）来直接给用户使用。\n「Layotto」：https://github.com/mosn/layotto/\n本周推荐阅读 WASM 将引领下一代计算范式[译]\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1674802800,"description":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230127/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7f4e9f1a38f28d522bf4684610397dfa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230127/","publishdate":"2023-01-27T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230127/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230127/","wordcount":762},{"author":null,"categories":"SOFA Weekly","content":"送虎迎兔\n各位 SOFAStack 社区的朋友好：\n我是 SOFAStack 社区的负责人鲁直，度过了令人难忘的虎年，我们即将迈入充满希望的兔年，在这里给大家拜个早年，祝大家兔年吉祥。\n虎年虽然有诸多的不便与艰难，但是好在开源本就是倡导异步沟通、在线协作；无论你在世界的哪个角落，只要连上互联网，都可以参与到开源社区中来。在过去的一年中，SOFAStack 社区新增了 100 多位的 Committer；他们有来自腾讯、Shoppee、MiHoYo、华信永道、同程旅行等公司的员工；也有来自高校的学生，这些 Committer 和我们已有的 Committer 一起发布了大量的新 Feature，也修复了很多深藏的 Bug。\n不过，通过线上的协作虽然能够正常进行开源项目的开发，但是联络感情最好的方式一定还是线下的 Meetup。\n在虎年出行各种不便的情况下，我们和各个社区联合，在杭州、成都、广州、合肥和上海举行了 Meetup，不过遗憾的是 SOFAStack 社区开源四周年的活动没有能够在线下举办。\n伴随着兔年的即将到来，SOFAStack 社区的开源也即将迈入第五年，没有了出行的各种限制，SOFAStack 社区的五周年活动也将在线下和大家相见。\n兔年展望\n回望 SOFAStack 社区将近五年的开源时间，一开始我们只是按照自己的粗浅理解来做开源，把代码放到 GitHub 上面去，举办一些 Meetup。\n随着和开源社区朋友们的深入沟通，我们对于开源的理解、对于社区的理解也一步步深入和加强，意识到想要让 SOFAStack 社区长期发展，除了项目本身的优秀想法之外，更需要一个开放的、活跃的社区，只有两者结合一起才能够长久地经营下去。基于此我们设计了完善的社区晋升机制，也和项目的上下游保持良好的沟通和合作关系，融入到更大的开源大家庭中。\n今年我们也会在继续在开放和有趣方面做进一步的深入，包括会把部分的项目推进到基金会孵化，使它们能够更加健康地长期发展，也会把更多有趣的活动带给大家。\n兔年准备做的几件事\nSOFABoot 4.0\nSOFABoot 将会发布 4.0 版本，适配最新发布的 Spring Boot 3.0。回想 2019 年，我们在配套设施并不完善的情况下，尝试了使用 GraalVM 做 SOFABoot 的静态化，初步感受到了 Native 能够带来的启动速度的提升。随着 Spring Boot 3.0 的发布与 Spring 对于 GraalVM 支持的完善，我们终于有机会能够把 SOFABoot 的静态化做地更加完善。\nMOSN 2.0\nMOSN 将会发布 2.0 的版本，MoE 架构将会正式和大家见面。随着我们和 Envoy 社区的重要的合作点Envoy\u0026amp;rsquo;s L7 Go extension API，我们 MOSN 2.0 的开发和测试工作也已经接近尾声，新的架构将会给 MOSN 带来更多的可能性。\nLayotto 1.0\nLayotto 将会发布 1.0 的版本，提供更多的组件支持，并且进一步完善多云与多语言的支持。\nSeata\nSeata 将会继续丰富多语言的支持，也会走向更加开放的社区。\n除了上面的项目之外，SOFAStack 社区其他的一些项目在年后也会陆陆续续公布 RoadMap，期待大家一起加入进来玩。\nLive Long and Prosper\n星际迷航里面的瓦肯人在举瓦肯手礼的时候会说著名的瓦肯祝词：“Live Long and Prosper”，这句话也非常符合 SOFAStack 开源社区的愿景，我们希望无论是 SOFAStack 的项目还是 SOFAStack 的社区，都能够“Live Long and Prosper”。\n期待与大家在兔年线下相见，Let\u0026amp;rsquo;s build the community together! Live long and prosper!\n","date":1674284400,"description":"Special Weekly | 瑞兔送福，Live Long and Prosper","dir":"blog/sofa-special-weekly/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9bce67dda0b127c88ba3f0413516f2f7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-special-weekly/","publishdate":"2023-01-21T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-special-weekly/","summary":"送虎迎兔 各位 SOFAStack 社区的朋友好： 我是 SOFAStack 社区的负责人鲁直，度过了令人难忘的虎年，我们即将迈入充满希望的兔年，在这里给大家拜个早年，祝大家兔年吉祥。","tags":["SOFA Weekly"],"title":"Special Weekly | 瑞兔送福，Live Long and Prosper","type":"blog","url":"/sofastack.tech/blog/sofa-special-weekly/","wordcount":1241},{"author":null,"categories":"SOFAStack","content":" 文｜郝洪范\n京东技术专家\nSeata-go 项目共同发起人\n微服务底层技术的探索与研究。\n本文 3482 字 阅读 7 分钟\n 对于 Go CURD Boy 来说，相信 github.com/go-sql-driver/mysql 这个库都不会陌生。基本上 Go 的 CURD 都离不开这个特别重要的库。我们在开发 Seata-go 时也使用了这个库。不过最近在使用 go-sql-driver/mysql 查询 MySQL 的时候，就出现一个很有意思的 bug, 觉得有必要分享出来，以防止后来者再次踩坑。\n PART. 1 问题详述 为了说明问题，这里不详述 Seata-go 的相关代码，用一个单独的 demo 把问题详细描述清楚。\n1.1 环境准备 在一个 MySQL 实例上准备如下环境：\nCREATE TABLE `Test1` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `create_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, -PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=101 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; 从这个 SQL 语句中可以看出来， create_time 是 timestamp 类型，这里要特别留意 timestamp 这个类型。\n现在插入一条数据，然后查看刚插入的数据的值。\ninsert into Test1 values (1, \u0026#39;2022-01-01 00:00:00\u0026#39;) 查看下 MySQL 当前的时区。请记好相关值，草蛇灰线，伏笔于此。\nshow VARIABLES like \u0026#39;%time_zone%\u0026#39;; 查询结果：\n接下来使用 MySQL unix_timestamp 查看 create_time 的时间戳：\nSELECT unix_timestamp(create_time) from Test1 where id = 1; 查询结果：\n1.2 测试程序 有如下 demo 程序，示例使用 go-sql-driver 读取 create_time 的值：\npackage main import ( \u0026amp;quot;database/sql\u0026amp;quot; \u0026amp;quot;fmt\u0026amp;quot; \u0026amp;quot;time\u0026amp;quot; _ \u0026amp;quot;github.com/go-sql-driver/mysql\u0026amp;quot; ) func main() { var user = \u0026amp;quot;user\u0026amp;quot; var pwd = \u0026amp;quot;password\u0026amp;quot; var dbName = \u0026amp;quot;dbname\u0026amp;quot; dsn := fmt.Sprintf(\u0026amp;quot;%s:%s@tcp(localhost:3306)/%stimeout=100s\u0026amp;amp;parseTime=true\u0026amp;amp;interpolateParams=true\u0026amp;quot;, user, pwd, dbName) db, err := sql.Open(\u0026amp;quot;mysql\u0026amp;quot;, dsn) if err != nil { panic(err) } defer db.Close() rows, err := db.Query(\u0026amp;quot;select create_time from Test1 limit 1\u0026amp;quot;) if err != nil { panic(err) } for rows.Next() { t := time.Time{} rows.Scan(\u0026amp;amp;t) fmt.Println(t) fmt.Println(t.Unix()) }} 我们运行个程序会输出下面的结果:\n2022-01-01 00:00:00 +0000 UTC1640995200 1.3 问题详述 发现问题所在了吗？有图如下，把结果放在一块，可以详细说明问题。\n图中红色箭头指向的两个结果，用 go-sql-driver 读取的结果和在 MySQL 中用 unix_timestamp 获取的结果明显是不一样的。\nPART. 2 问题探案 1.3 小节中最后示图可以看出，数据库中 create_time 的值 2022-01-01 00:00:00 是东八区的时间，也就是北京时间，这个时间对应的时间戳就是 1640966400 。但是 go-sql-driver 示例程序读出来的却是 1640995200 ， 这是什么值？这是 0 时区的 2022-01-01 00:00:00。\n对问题的直白描述就是：MySQL 的 create_time 是 2022-01-01 00:00:00 +008 ，而读取到的是 2022-01-01 00:00:00 +000 ，他俩压根就不是一个值。\n基本能看出来 bug 是如何发生的了。那就需要剖析下 go-sql-driver 源码，追查问题的根源。\n2.1 go-sq-driver 源码分析 这里就不粘贴 \u0026amp;quot;github.com/go-sql-driver/mysql\u0026amp;quot; 的详细源码了，只贴关键的路径。\nDebug 的时候详细关注调用路径中红色的两个方块的内存中的值。\n// https://github.com/go-sql-driver/mysql/blob/master/packets.go#L788- L798 func (rows *textRows) readRow(dest []driver.Value) error { // ... // Parse time field switch rows.rs.columns[i].fieldType { case fieldTypeTimestamp, fieldTypeDateTime, fieldTypeDate, fieldTypeNewDate: if dest[i], err = parseDateTime(dest[i].([]byte), mc.cfg.Loc); err != nil { return err } }} func parseDateTime(b []byte, loc *time.Location) (time.Time, error) { const base = \u0026amp;quot;0000-00-00 00:00:00.000000\u0026amp;quot; switch len(b) { case 10, 19, 21, 22, 23, 24, 25, 26: // up to \u0026amp;quot;YYYY-MM-DD HH:MM:SS.MMMMMM\u0026amp;quot; year, err := parseByteYear(b) month := time.Month(m) day, err := parseByte2Digits(b[8], b[9]) hour, err …","date":1673938800,"description":"一个 go-sql-driver 的离奇 bug","dir":"blog/go-sql-driver-amazing-bug/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d7361909c70b2dd88fad050699609660","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-sql-driver-amazing-bug/","publishdate":"2023-01-17T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/go-sql-driver-amazing-bug/","summary":"文｜郝洪范 京东技术专家 Seata-go 项目共同发起人 微服务底层技术的探索与研究。 本文 3482 字 阅读 7 分钟 对于 Go CURD Boy 来说，相信 github.com/go-sql-driver/mysql 这个库都不会陌生。基本上 Go 的 CURD 都离","tags":["SOFAStack"],"title":"一个 go-sql-driver 的离奇 bug","type":"blog","url":"/sofastack.tech/blog/go-sql-driver-amazing-bug/","wordcount":1881},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 6 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @dengqian #2203\n 是否支持应用级服务发现，若支持能够给提供者和消费者的代号示例吗？\n A：SOFARegistry 本身是比较存粹的服务发布和订阅功能，应用级和接口级的区别在于 Client 发送给 Registry 的是应用级的 Publisher 还是接口级的 Publisher。所以相关的应用级 Publisher 聚合以及应用级 Subscriber 订阅的逻辑主要是在 Mesh 端，而这部分 Mesh 代码暂时还没开源。稍后我们会整理完整的应用级服务上线的过程以及设计方案，发布到社区文档中。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/\n2. @yemoli #1290\n 请问 MOSN 支持增加订阅 xDS 吗？gRPC DeltaAggregatedResources。\n A：xDS 这个块还不支持，不过底层的资源是支持增加更新的，感兴趣的话语，欢迎共建~\n「MOSN」：https://github.com//mosn/mosn/\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1673593200,"description":"SOFA Weekly | 铜锁探「密」、本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20220113/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5558f66f4c819ff525bcb4708fab5700","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220113/","publishdate":"2023-01-13T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220113/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 铜锁探「密」、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220113/","wordcount":715},{"author":null,"categories":"SOFAStack","content":" 文｜李楠（GitHub ID : @loheagn）\n北京航空航天大学 21 级研究生\n云原生底层系统的开发和探索工作。\n本文 6369 字 阅读 16 分钟\nOSPP 开源之夏是由中科院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动。旨在鼓励在校学生积极参与开源软件的开发维护、促进优秀开源软件社区的蓬勃发展、培养和发掘更多优秀的开发者。\n这是去年（2022）的开源活动中，李楠同学参加 Nydus 容器开源生态集成课题的相关工作。\n| 作者有话说 |\n 大家好！我是来自北京航空航天大学的 2021 级研究生李楠，对云原生技术很感兴趣，GitHub ID 是 @loheagn。在今年上半年，我参加了 Linux 基金会的春季实习，完成了 CNCF - Kubevela: Management of Terraform state 项目的工作，并因此培养了对开源工作的兴趣。在开源之夏 2022 开放题目后，我了解到了 Nydus 项目，感觉这是一个很酷的项目，由于我之前对容器和镜像的底层技术并不是很熟悉，觉得这是个很不错的学习机会。于是便尝试投递了简历申请，最终很幸运地通过了筛选，并在严松老师的帮助下顺利完成了题目。\n PART. 1 项目背景 Nerdctl Nerdctl 是一个对标 Docker CLI 和 Docker Compose 的、用于与 Containerd （当下最流行的容器运行时，Docker 的后端也是调用的 Containerd，通常作为守护进程出现） 交互的命令行工具。\n用户可以像使用 Docker CLI 一样使用 Nerdctl 与 Containerd 进行交互，比如使用 nerdctl pull \u0026amp;lt;image_name\u0026amp;gt; 来拉取镜像、使用 nerdctl run \u0026amp;lt;image_name\u0026amp;gt; 来运行容器等等。\n相比于 Containerd 本身提供的 CTR 工具，Nerdctl 默认提供了更友好的用户体验，并尽量保持其使用方式与 Docker 一致。对于从 Docker 迁移到 Containerd 的用户，往往只需要 alias docker=nerdctl 就可以与之前获得一致的使用体验。\nOCI 镜像格式 OCI 镜像格式是 OCI （Open Container Initiative，开放容器计划） 的重要组成部分。它给出了一个厂商无关的镜像格式规范，即一个镜像应该包含哪些部分、每个部分的数据结构是如何的、这些各个部分应该以怎样的方式进行组织等等。\nOCI 镜像格式脱胎于 Docker 镜像格式，它与 Docker 镜像格式有着非常类似的结构；但它比 Docker 镜像格式有更好的兼容性，并得到了各个厂商的普遍认同。\n因此，在这里主要介绍一下 OCI 镜像格式的主要内容。\n通常所说的镜像文件其实指的是一个包含了多个文件的“包”，“包”中的这些文件提供了启动一个容器所需要的所有需要信息，其中包括但不限于，容器所使用的文件系统等数据文件，镜像所适用的平台、数据完整性校验信息等配置文件。当我们使用 docker pull 或 nerdctl pull 从镜像中心拉取镜像时，其实就是在依次拉取该镜像所包含的这些文件。\n例如，当我们使用 nerdctl pull 拉取一个 OCI 镜像时：\n从 Log 中可以清晰地看到，Nerdctl 依次拉取了一个 index 文件、一个 manifest 文件、一个 config 文件和若干个 layer 数据文件。实际上，一个标准的 OCI 镜像通常就是由这几部分构成的。\n其中，layer 文件一般是 tar 包或者压缩后的 tar 包，其包含着镜像具体的数据文件。这些 layer 文件会共同组成一个完整的文件系统（也就是从该镜像启动容器后，进入容器中看到的文件系统） 。\nconfig 文件是一个 JSON 文件。其中包含镜像的一些配置信息，比如镜像时间、修改记录、环境变量、镜像的启动命令等等。\nmanifest 文件也是一个 JSON 文件。它可以看作是镜像文件的清单，即说明了该镜像包含了哪些 layer 文件和哪个 config 文件。\n下面是一个 manifest 文件的典型例子：\n{ \u0026amp;quot;schemaVersion\u0026amp;quot;: 2, \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.manifest.v1+json\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.config.v1+json\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:0584b370e957bf9d09e10f424859a02ab0fda255103f75b3f8c7d410a4e96ed5\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 7636 }, \u0026amp;quot;layers\u0026amp;quot;: [ { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:214ca5fb90323fe769c63a12af092f2572bf1c6b300263e09883909fc865d260\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 31379476 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:50836501937ff210a4ee8eedcb17b49b3b7627c5b7104397b2a6198c569d9231\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 25338790 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:d838e0361e8efc1fb3ec2b7aed16ba935ee9b62b6631c304256b0326c048a330\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 600 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:fcc7a415e354b2e1a2fcf80005278d0439a2f87556e683bb98891414339f9bee\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: …","date":1673334000,"description":"Nerdctl 原生支持 Nydus 加速镜像","dir":"blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ef25c9d4c042e6feeca78cb7919f6fa5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","publishdate":"2023-01-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","summary":"文｜李楠（GitHub ID : @loheagn） 北京航空航天大学 21 级研究生 云原生底层系统的开发和探索工作。 本文 6369 字 阅读 16 分钟 OSPP 开源之夏是由中科院","tags":["SOFAStack"],"title":"Nerdctl 原生支持 Nydus 加速镜像","type":"blog","url":"/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","wordcount":5660},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @dengqian #2203\n Why pprof debug server do not support hot upgrade?\n A：Debug server init here：\nfunc DefaultInitStage(c *v2.MOSNConfig) { InitDefaultPath(c) InitDebugServe(c) InitializePidFile(c) InitializeTracing(c) InitializePlugin(c) InitializeWasm(c) InitializeThirdPartCodec(c) } And started here:\nfunc (m *Mosn) inheritConfig(c *v2.MOSNConfig) (err error) { m.Config = c server.EnableInheritOldMosnconfig(c.InheritOldMosnconfig) // default is graceful mode, turn graceful off by set it to false if !c.DisableUpgrade \u0026amp;amp;\u0026amp;amp; server.IsReconfigure() { m.isFromUpgrade = true if err = m.inheritHandler(); err != nil { return } } log.StartLogger.Infof(\u0026amp;quot;[mosn] [NewMosn] new mosn created\u0026amp;quot;) // start init services if err = store.StartService(nil); err != nil { log.StartLogger.Errorf(\u0026amp;quot;[mosn] [NewMosn] start service failed: %v, exit\u0026amp;quot;, err) } return } 「MOSN」：https://github.com//mosn/mosn/\n2. @yemoli #1290\n SOFARPC 发现了安全漏洞在哪提交呢？\n A：可以邮件给：khotyn.huangt@antgroup.com。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/\n本周推荐阅读 SOFARegistry | 聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1672988400,"description":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","dir":"blog/sofaweekly-20230106/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f7cd3e95e772fe4b498452c1594986a2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaweekly-20230106/","publishdate":"2023-01-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofaweekly-20230106/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofaweekly-20230106/","wordcount":596},{"author":null,"categories":"SOFAStack","content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。\n本文 9492字 阅读 24 分钟\nPART. 1 前言 1.1 什么是服务发现 在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信。这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群；具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n1.2 服务发现的考量 设计和考量一个服务发现系统，可以从下面这些指标展开：\n各个指标之间并不是相互独立的。例如对于数据一致性方案的选型也会影响到数据分区、数据复制、集群容灾、多集群同步等方案的决策，也在很大程度上决定这个服务发现系统的整体架构。\n这篇文章重点分析了各个服务发现系统的数据一致性方案，以及基于这个方案延伸出来的特性，帮助大家初步了解服务发现系统。\nPART. 2 开源产品分析 2.1 为什么需要数据一致性 根据上述描述，数据一致性在服务发现系统中如此重要，甚至会影响到整个服务发现系统的各方面架构考量，那我们到底为什么需要数据一致性呢？\n要回答这个问题，让我们从单点故障说起：早期我们使用的服务，以及服务数据存储，它们往往是部署在单节点上的。但是单节点存在单点故障，一旦单节点宕机就整个服务不可用，对业务影响非常大。随后，为了解决单点问题，软件系统引入了数据复制技术，实现多副本。\n通过数据复制方案，一方面我们可以提高服务可用性，避免单点故障；另一方面，多副本可以提升读吞吐量、甚至就近部署在业务所在的地理位置，降低访问延迟。\n随着多副本的引入，就会涉及到多个副本之间的数据怎样保持一致的问题，于是数据一致性随之而来。\n2.2 开源产品分析\n对于多个副本之间进行数据同步，一致性关系从强到弱依次是：\n 线性一致性 （Linearizability consistency）\n 顺序一致性 （Sequential consistency）\n 因果一致性 （Causal consistency）\n 最终一致性 （Eventual consistency）\n 我们对比一下目前开源的比较典型的服务发现产品，在数据一致性上的方案实现：\nPART. 3 Etcd 数据一致性 3.1 Etcd 读数据流程 1. Client：Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： Client 发送 RPC 请求到了 Server 后，KV Server 基于拦截器记录所有请求的执行耗时及错误码、来源 IP 等，也可控制请求是否允许通过；\n3. Raft： Etcd 收到读请求后，向 Etcd Raft 模块发起 Read Index 读数据请求，返回最新的 ReadState 结构体数据；\n4. MVCC：KV Server 获取到 Read State 数据后，从 MVCC 模块的 Tree Index 读取基于 Key-Version 的唯一标识 Revision；再以 Revision 作为 Key 从 Boltdb 中读取数据。\n3.2 Etcd 写数据流程 1. Client： Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： 通过一系列检查之后，然后向 Raft 模块发起 （Propose） 一个提案 （Proposal） ，提案内容为存储的 value；\n3. Raft：\na.向 Raft 模块发起提案后，KV Server 模块会等待此 put 请求；如果一个请求超时未返回结果，会出现的 EtcdServer：request timed out 错误。\nb.Raft 模块收到提案后，如果当前节点是 Follower，它会转发给 Leader，只有 Leader 才能处理写请求。Leader 收到提案后，通过 Raft 模块将 put 提案消息广播给集群各个节点，同时需要把集群 Leader 任期号、投票信息、已提交索引、提案内容持久化到一个 WAL （Write Ahead Log） 日志文件中，用于保证集群的一致性、可恢复性。\n4. Raft 模块提交 Proposal 完成后，向 MVCC 模块提交写数据。\n3.3 Raft 功能分解 共识算法的祖师爷是 Paxos， 但是由于它过于复杂、难于理解，工程实践上也较难落地，导致在工程界落地较慢。\nStandford 大学的 Diego 提出的 Raft 算法正是为了可理解性、易实现而诞生的，它通过问题分解，将复杂的共识问题拆分成三个子问题，分别是：\n Leader 选举： Leader 故障后集群能快速选出新 Leader；\n 日志复制：集群只有 Leader 能写入日志， Leader 负责复制日志到 Follower 节点，并强制 Follower 节点与自己保持相同；\n 安全性： 一个任期内集群只能产生一个 Leader、已提交的日志条目在发生 Leader 选举时，一定会存在更高任期的新 Leader 日志中、各个节点的状态机应用的任意位置的日志条目内容应一样等。\n 下面以实际场景为案例，分别深入讨论这三个子问题，看看 Raft 是如何解决这三个问题，以及在 Etcd 中的应用实现。\n关于 Raft 的 Leader 选举与日志复制，可以从 *http://www.kailing.pub/raft/index.html* 动画中进一步了解。\n3.4 Etcd 读写一致性 3.4.1 线性一致性写 所有的 Read/Write 都会来到 Leader，Write 会有 Oplog Leader 被序列化，依次顺序往后 commit，并 Apply 然后在返回，那么一旦一个 Write 被 committed，那么其前面的 Write 的 Oplog 一定就被 committed 了。所有的 Write 都是有严格的顺序的，一旦被 committed 就可见了，所以 Raft 是线性一致性写。\n3.4.2 线性一致性读 Etcd 默认的读数据流程是 Linearizability Read，那么怎么样才能读取到 Leader 已经完成提交的数据呢？\n读请求走一遍 Raft 协议\n每个 Read 都生成一个对应的 Oplog，和 Write 一样，都会走一遍一致性协议的流程，会在此 Read Oplog 被 Apply 的时候读，那么这个 Read Oplog 之前的 Write Oplog 肯定也被 Applied 了，那么一定能够被读取到，读到的也一定是最新的。\n 有什么问题?\n 不仅有日志写盘开销，还有日志复制的 RPC 开销，在读比重较大的系统中是无法接受的；\n 还多了一堆的 Raft \u0026amp;lsquo;读日志\u0026amp;rsquo;。 …","date":1672729200,"description":"SOFARegistry | 聊一聊服务发现的数据一致性","dir":"blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","fuzzywordcount":7400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"87d55af6b45db61d5fb44c2096813f0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","publishdate":"2023-01-03T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。 本文 9492字 阅读 24 分钟 PART. 1 前言 1.1 什么是","tags":["SOFAStack"],"title":"SOFARegistry | 聊一聊服务发现的数据一致性","type":"blog","url":"/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","wordcount":7378},{"author":"肖健","categories":["SOFAStack"],"content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。\n本文 9492字 阅读 24 分钟\nPART. 1 前言 1.1 什么是服务发现 在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信。这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群；具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n1.2 服务发现的考量 设计和考量一个服务发现系统，可以从下面这些指标展开：\n各个指标之间并不是相互独立的。例如对于数据一致性方案的选型也会影响到数据分区、数据复制、集群容灾、多集群同步等方案的决策，也在很大程度上决定这个服务发现系统的整体架构。\n这篇文章重点分析了各个服务发现系统的数据一致性方案，以及基于这个方案延伸出来的特性，帮助大家初步了解服务发现系统。\nPART. 2 开源产品分析 2.1 为什么需要数据一致性 根据上述描述，数据一致性在服务发现系统中如此重要，甚至会影响到整个服务发现系统的各方面架构考量，那我们到底为什么需要数据一致性呢？\n要回答这个问题，让我们从单点故障说起：早期我们使用的服务，以及服务数据存储，它们往往是部署在单节点上的。但是单节点存在单点故障，一旦单节点宕机就整个服务不可用，对业务影响非常大。随后，为了解决单点问题，软件系统引入了数据复制技术，实现多副本。\n通过数据复制方案，一方面我们可以提高服务可用性，避免单点故障；另一方面，多副本可以提升读吞吐量、甚至就近部署在业务所在的地理位置，降低访问延迟。\n随着多副本的引入，就会涉及到多个副本之间的数据怎样保持一致的问题，于是数据一致性随之而来。\n2.2 开源产品分析\n对于多个副本之间进行数据同步，一致性关系从强到弱依次是：\n 线性一致性 （Linearizability consistency）\n 顺序一致性 （Sequential consistency）\n 因果一致性 （Causal consistency）\n 最终一致性 （Eventual consistency）\n 我们对比一下目前开源的比较典型的服务发现产品，在数据一致性上的方案实现：\nPART. 3 Etcd 数据一致性 3.1 Etcd 读数据流程 1. Client：Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： Client 发送 RPC 请求到了 Server 后，KV Server 基于拦截器记录所有请求的执行耗时及错误码、来源 IP 等，也可控制请求是否允许通过；\n3. Raft： Etcd 收到读请求后，向 Etcd Raft 模块发起 Read Index 读数据请求，返回最新的 ReadState 结构体数据；\n4. MVCC：KV Server 获取到 Read State 数据后，从 MVCC 模块的 Tree Index 读取基于 Key-Version 的唯一标识 Revision；再以 Revision 作为 Key 从 Boltdb 中读取数据。\n3.2 Etcd 写数据流程 1. Client： Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： 通过一系列检查之后，然后向 Raft 模块发起 （Propose） 一个提案 （Proposal） ，提案内容为存储的 value；\n3. Raft：\na.向 Raft 模块发起提案后，KV Server 模块会等待此 put 请求；如果一个请求超时未返回结果，会出现的 EtcdServer：request timed out 错误。\nb.Raft 模块收到提案后，如果当前节点是 Follower，它会转发给 Leader，只有 Leader 才能处理写请求。Leader 收到提案后，通过 Raft 模块将 put 提案消息广播给集群各个节点，同时需要把集群 Leader 任期号、投票信息、已提交索引、提案内容持久化到一个 WAL （Write Ahead Log） 日志文件中，用于保证集群的一致性、可恢复性。\n4. Raft 模块提交 Proposal 完成后，向 MVCC 模块提交写数据。\n3.3 Raft 功能分解 共识算法的祖师爷是 Paxos， 但是由于它过于复杂、难于理解，工程实践上也较难落地，导致在工程界落地较慢。\nStandford 大学的 Diego 提出的 Raft 算法正是为了可理解性、易实现而诞生的，它通过问题分解，将复杂的共识问题拆分成三个子问题，分别是：\n Leader 选举： Leader 故障后集群能快速选出新 Leader；\n 日志复制：集群只有 Leader 能写入日志， Leader 负责复制日志到 Follower 节点，并强制 Follower 节点与自己保持相同；\n 安全性： 一个任期内集群只能产生一个 Leader、已提交的日志条目在发生 Leader 选举时，一定会存在更高任期的新 Leader 日志中、各个节点的状态机应用的任意位置的日志条目内容应一样等。\n 下面以实际场景为案例，分别深入讨论这三个子问题，看看 Raft 是如何解决这三个问题，以及在 Etcd 中的应用实现。\n关于 Raft 的 Leader 选举与日志复制，可以从 *http://www.kailing.pub/raft/index.html* 动画中进一步了解。\n3.4 Etcd 读写一致性 3.4.1 线性一致性写 所有的 Read/Write 都会来到 Leader，Write 会有 Oplog Leader 被序列化，依次顺序往后 commit，并 Apply 然后在返回，那么一旦一个 Write 被 committed，那么其前面的 Write 的 Oplog 一定就被 committed 了。所有的 Write 都是有严格的顺序的，一旦被 committed 就可见了，所以 Raft 是线性一致性写。\n3.4.2 线性一致性读 Etcd 默认的读数据流程是 Linearizability Read，那么怎么样才能读取到 Leader 已经完成提交的数据呢？\n读请求走一遍 Raft 协议\n每个 Read 都生成一个对应的 Oplog，和 Write 一样，都会走一遍一致性协议的流程，会在此 Read Oplog 被 Apply 的时候读，那么这个 Read Oplog 之前的 Write Oplog 肯定也被 Applied 了，那么一定能够被读取到，读到的也一定是最新的。\n 有什么问题?\n 不仅有日志写盘开销，还有日志复制的 RPC 开销，在读比重较大的系统中是无法接受的；\n 还多了一堆的 Raft \u0026amp;lsquo;读日志\u0026amp;rsquo;。 …","date":1672729200,"description":"SOFARegistry | 聊一聊服务发现的数据一致性","dir":"projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","fuzzywordcount":7400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"27d048a94346192098907dd51a25e4ba","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","publishdate":"2023-01-03T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。 本文 9492字 阅读 24 分钟 PART. 1 前言 1.1 什么是","tags":["SOFAStack","SOFARegistry"],"title":"SOFARegistry | 聊一聊服务发现的数据一致性","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","wordcount":7378},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 小白\n 在蚂蚁内部目前中间件升级采用的是业务方修改 POM 依赖的方式吗？\n A：是以这个方式为主的\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2. 肖文璧 提问\n Unrecognized VM option \u0026amp;lsquo;CMSParallelRemarkEnabled\u0026amp;rsquo; Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.导致 Seata-Server 无法启动是怎么回事？\n A：A：这个是因为使用了高版本的 JDK 导致。高版本的 JDK 取消了 CMS 处理器，转而采用了 ZGC 代替它。 解决方案有两个，选其中之一便可：1、降级 JDK 版本；2、在 Seata 的启动脚本中删除 CMS 的 JDK 命令。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1672383600,"description":"SOFA Weekly | 2023 我们一起加油、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221230/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"75c5a4519ec5c68e190926415dd7e767","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221230/","publishdate":"2022-12-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221230/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 2023 我们一起加油、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221230/","wordcount":607},{"author":null,"categories":"SOFAStack","content":" 文｜余硕\n上海交通大学22届毕业生阿里云开发工程师\n从事云原生底层系统的开发和探索工作。\n本文 6369 字 阅读 16 分钟\n GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。 这是今年的夏令营活动中，余硕同学参加 Nydus 开源项目的总结，主要介绍了 Nydus 为支持镜像扫描与修复所做的研究与相关工作。\n PART. 1 课题背景 Nydus 开源镜像加速框架 Nydus 是 CNCF 孵化项目 Dragonfly 的子项目，它提供了容器镜像，代码包按需加载的能力。Nydus 应用时无需等待全部数据下载完成便可开始服务。\nNydus 在生产环境中已经支撑了每日百万级别的加速镜像容器创建。它在容器启动性能、镜像空间占用、网络带宽效率、端到端数据一致性等方面相比 OCI v1 格式有着巨大优势，并可扩展至其它数据分发场景，比如 NPM 包懒加载等。\n目前 Nydus 由蚂蚁集团、阿里云、字节跳动联合开发。Containerd、Podman 社区已经接受了 Nydus 运行时作为其社区子项目，它也是 Kata Containers 以及 Linux v5.19 内核态原生支持的镜像加速方案。\n有关 Nydus 镜像加速开源项目的详细介绍，可以参考：Nydus——下一代容器镜像的探索实践。\n项目描述 为 Nydus 镜像增加一个扫描和修复的命令行工具，包含以下功能：\n 提供一个 Nydus 镜像 url 和需要替换的文件列表；\n 使用工具拉取镜像 Bootstrap；\n 找到镜像中对应的文件并替换；\n 打包成新的镜像并上传回 Registry。\n 概括来说，原有项目目标是为 Nydus 镜像实现一个扫描和修复的命令行工具，其中这些功能是这个工具或者工具组的实现流程。\n但此项目具有一定的实验性，其核心是为 Nydus 格式的镜像提供扫描和修复的功能或者指引。如果存在更好的方式，项目最终不一定要按照原有项目描述去实现。因此在接下来的课题完成过程中，我们首先对已有镜像扫描/修复的工具与服务进行了调研，来确定此课题方案的最终形态。\n镜像扫描工具及服务 扫描和修复 镜像扫描和修复可以被拆解为两个过程。扫描不更改原有的镜像内容，只需要寻找扫描目标是否存在某种缺陷；镜像修复则需要根据缺陷改动镜像，包括但不限于镜像内容，镜像层级组织等。我们调研发现，当前主流开源镜像扫描引擎包括云厂商镜像安全服务都只涉及镜像扫描的功能， 不会主动添加镜像修复的功能。\n我们分析主要的原因有：\n 直接进行镜像修复可能引入新的安全问题；\n 镜像扫描的内容存在不同种类，很可能需要为不同种类的镜像安全问题设计不同的修复方式；\n 镜像修复功能可以通过重新打包镜像替代。\n 所以，镜像安全服务暂时只是提供扫描结果的安全报告，具体的修复操作由用户自行决定。我们也准备沿用这样的思路：在本课题中，为镜像实现安全扫描的功能，并提供报告作为用户镜像修复的参考依据。\n 我们也探索讨论了镜像修复的支持，或者 Nydus 特性在镜像修复场景下的增强，比如镜像内包替换后的去重与重组等，或许这些可以是未来 Nydus 中增加的功能特性。\n 镜像扫描介绍 镜像扫描的原因与内容 容器镜像是当前容器/软件分发的基础，里面包含了容器隔离环境以及软件执行环境的相关内容。因此保障其安全性变得十分重要。镜像扫描即是要扫描镜像中的所有内容，及时发现可能包含的安全漏洞或者隐私泄露。\n综合来看，镜像扫描需要关注镜像的安全性与健壮性，扫描的内容主要分为三类：\n1. 安全漏洞。 包括系统软件包和应用软件库中可能存在的安全漏洞。可以通过比对镜像中这些库/软件包的来源、版本等与 CVE 数据库中报告的漏洞的包的来源、版本来定位可能存在的安全漏洞。\n2. 配置。 包括镜像运行的环境配置和镜像中相关内容组合可能带来的问题。帮助尽早定位配置错误以及配置错误可能带来的安全风险。\n3. 隐私。 需要扫描的是用户指定的一些隐私信息。比如用户不小心将密钥等信息存入镜像。如果在扫描配置中进行指定，扫描过程可能发现这些隐私信息，避免隐私泄露以及可能带来的安全问题。\n扫描引擎 常见的扫描引擎有 Trivy、Synk 等。Docker 官方使用的是 Synk，但它比较商业化；Trivy 是 CNCF 的项目，开放性较好。\n镜像扫描的使用方式 在我们的调研中，镜像扫描主要应用方式有三种：\n1. 基础使用。 镜像扫描的过程可以直接通过集成了镜像扫描引擎的容器运行时或者镜像扫描引擎命令行触发。比如运行 $ docker scan image-url ，可以扫描镜像，并输出相应的报告。\nsource：https://docs.docker.com/engine/scan/\n2. 流程集成。 镜像扫描的过程可以集成到镜像中心或者 CI/CD 流程中。比如将镜像扫描集成到数据中心，在每次镜像上传到数据中心时触发镜像扫描，可以保证从数据中心下载的镜像总是经过安全扫描的；集成在 CI/CD 流程中，设置触发条件，可以保证镜像生成，镜像部署等过程所使用的镜像的安全性。\nsource: https://www.containiq.com/post/container-image-scanning\n3. 扫描服务。 云厂商提供了镜像安全的服务。它们背后可能是基于前两种使用方式实现，但是还可以有很多种功能的增强。用户想使用镜像扫描的功能也可以直接购买类似的安全服务，并进行灵活的配置。\nsource: https://cloud.google.com/container-analysis/docs/on-demand-scanning-howto\nPART. 2 课题解决思路 基本思路 课题首先要解决的基本思路是，如项目描述一般为 Nydus 实现一个专属的镜像扫描工具；还是复用已有的镜像扫描引擎，在 Nydus 侧实现对接支持，从而完成 Nydus 镜像扫描的功能实现。\n我们最终选择了结合已有镜像扫描引擎的实现思路。尽管为 Nydus 实现一个专属的镜像扫描工具可以更好的利用 Nydus 的特性，但是从镜像功能生态上考虑，这并不是一个很好的方式。复用或者集成到现有的镜像扫描工具，一方面可以直接使用已实现的镜像扫描引擎中全面的内容扫描能力；另一方面，与上层镜像安全服务的对接也不用再重写相关接口。这样也可以减少一些功能定制，减少用户使用的负担。因此此课题选择了后一种实现的基本思路。\n扫描思路：FileSystem vs Image Trivy 扫描功能实现的框架 1. 控制路径。\nTrivy 在镜像扫描上由以下路径控制，每触发一次命令，会由一个 Scanner 控制。其中关键的是 artifact 和 driver 。扫描引擎一般可以支持多种格式的扫描，比如 OCI v1 镜像或者镜像 Rootfs，同时一般也支持本地或者远端存储信息等。这些一般可由 ScannerConfig 配置或者自动解析。\natifact 存储着镜像 (包括文件系统) 元信息，如果已经扫描过其中的内容，还可以存储部分解析后的信息。另外，load …","date":1672124400,"description":"Nydus 镜像扫描加速","dir":"blog/nydus-mirror-scan-acceleration/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c1a6786f703b2475c84aad66b06e85b5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-mirror-scan-acceleration/","publishdate":"2022-12-27T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/nydus-mirror-scan-acceleration/","summary":"文｜余硕 上海交通大学22届毕业生阿里云开发工程师 从事云原生底层系统的开发和探索工作。 本文 6369 字 阅读 16 分钟 GitLink 编程夏令营是在 CCF 中国计算机学会指导下","tags":["SOFAStack"],"title":"Nydus 镜像扫描加速","type":"blog","url":"/sofastack.tech/blog/nydus-mirror-scan-acceleration/","wordcount":5496},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 小白\n SOFAArk 可以把 2 个端口不一样的 Spring Boot 微服务合并到一起部署吗？比如一个是 8080 另一个端口是 8081，2 个服务都有各自的接口， 合并部署后还可以通过对应的端口来进行访问嘛？\n A：不使用 Web-Ark-Plugin 插件，每个模块会启动新的 Tomcat 实例，可以让服务用不同的 port。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2. 肖文璧 提问\n Seata 对 Java17 的版本有支持吗？\n A：A：需要 v1.6.0 版本。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1671778800,"description":"SOFA Weekly | 新年礼包已就位、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-202211223/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"af3eb0769d6765dd7994becf03bd4a1c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-202211223/","publishdate":"2022-12-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-202211223/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 新年礼包已就位、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-202211223/","wordcount":578},{"author":null,"categories":"SOFAStack","content":" 文｜戚文博 （花名：百蓦）\nDragonfly Maintainer蚂蚁集团软件工程师\n主要负责「基于 P2P 的文件以及镜像加速系统」。\n本文 2175 字 阅读 15 分钟\nPART. 1 背景 自 17 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 18 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会 （TOC） 投票决定接受 Dragonfly 作为孵化级别的托管项目。Dragonfly 多年生产实践经验打磨的下一代产品，它汲取了上一代 Dragonfly1.x[1] 的优点并针对已知问题做了大量的优化。\nNydus 作为 Dragonfly 的子项目优化了 OCIv1 镜像格式，并以此设计了一个用户态文件系统，使容器可以按需下载镜像，不再需要下载完整镜像即可启动容器。在最新版本中 Dragonfly 完成了和子项目 Nydus 的集成，让容器启动即可以按需下载镜像，减少下载量。也可以在传输过程中利用 Dragonfly P2P 的传输方式，降低回源流量并且提升下载速度。\nPART. 2 实践 注:如果没有可用的 Kubernetes 集群进行测试，推荐使用 Kind[2]。\n安装 Dragonfly\n基于 Kubernetes cluster 详细安装文档可以参考：\nhttps://d7y.io/docs/next/getting-started/quick-start/kubernetes/ 。\n使用 Kind 安装 Kubernetes 集群\n创建 Kind 多节点集群配置文件 kind-config.yaml ，配置如下:\nkind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker extraPortMappings: - containerPort: 30950 hostPort: 65001 - role: worker 使用配置文件创建 Kind 集群:\nkind create cluster --config kind-config.yaml 切换 Kubectl 的 context 到 Kind 集群:\nkubectl config use-context kind-kind Kind 加载 Dragonfly 镜像\n下载 Dragonfly latest 镜像:\ndocker pull dragonflyoss/scheduler:latest docker pull dragonflyoss/manager:latest docker pull dragonflyoss/dfdaemon:latest Kind 集群加载 Dragonfly latest 镜像:\nkind load docker-image dragonflyoss/scheduler:latest kind load docker-image dragonflyoss/manager:latest kind load docker-image dragonflyoss/dfdaemon:latest 基于 Helm Charts\n创建 Dragonfly P2P 集群\n创建 Helm Charts 配置文件 charts-config.yaml 并且开启 Peer 的预取功能, 配置如下:\nscheduler: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 seedPeer: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 download: prefetch: true dfdaemon: hostNetwork: true config: verbose: true pprofPort: 18066 metrics: :8000 download: prefetch: true proxy: defaultFilter: \u0026#39;Expires\u0026amp;amp;Signature\u0026amp;amp;ns\u0026#39; security: insecure: true tcpListen: listen: 0.0.0.0 port: 65001 registryMirror: dynamic: true url: https://index.docker.io proxies: - regx: blobs/sha256.* manager: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 使用配置文件部署 Dragonfly Helm Charts:\n$ helm repo add dragonfly https://dragonflyoss.github.io/helm-charts/$ helm install --wait --create-namespace --namespace dragonfly-system dragonfly dragonfly/dragonfly -f charts-config.yamlNAME: dragonflyLAST DEPLOYED: Wed Oct 19 04:23:22 2022NAMESPACE: dragonfly-system STATUS: deployedREVISION: 1TEST SUITE: None NOTES: 1. Get the scheduler address by running these commands: export SCHEDULER_POD_NAME=$(kubectl get pods --namespace dragonfly-system -l \u0026amp;quot;app=dragonfly,release=dragonfly,component=scheduler\u0026amp;quot; -o jsonpath={.items[0].metadata.name}) export SCHEDULER_CONTAINER_PORT=$(kubectl get pod --namespace dragonfly-system $SCHEDULER_POD_NAME -o jsonpath=\u0026amp;quot;{.spec.containers[0].ports[0].containerPort}\u0026amp;quot;) kubectl --namespace dragonfly-system port-forward $SCHEDULER_POD_NAME 8002:$SCHEDULER_CONTAINER_PORT echo \u0026amp;quot;Visit http://127.0.0.1:8002 to use your …","date":1671519600,"description":"Dragonfly 和 Nydus Mirror 模式集成实践","dir":"blog/dragonfly-and-nydus-mirror-mode-integration-practice/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"75467253523cbbd18d6aef01e3449eb4","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","publishdate":"2022-12-20T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","summary":"文｜戚文博 （花名：百蓦） Dragonfly Maintainer蚂蚁集团软件工程师 主要负责「基于 P2P 的文件以及镜像加速系统」。 本文 2175 字 阅读 15 分钟 PART. 1 背景 自 17 年开","tags":["SOFAStack"],"title":"Dragonfly 和 Nydus Mirror 模式集成实践","type":"blog","url":"/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","wordcount":2729},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.小白 提问：\n 运行之后我发现和文档写的不一样 biz 和宿主的 Spring Boot 没有隔开，文档上写的是 2.6.6 和 2.5.0 但是实际启动都是 2.6.6，这是怎么回事？\n A：不建议用不同 Spring Boot，多 host 模式只要不使用 Web-Ark-Plugin 是可以的；我用 Sofa-Ark-Spring-Guides 试了一下，可以设置不同的 host。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.吴东梁 提问：\n 保存在内存里的事务信息多久会删除一次，来避免 OOM？\n A：结束就删。\n 那如果在事务结束之后只删内存的数据，不删除数据库里面数据会不会产生问题？\n A：没有内存和数据库共用的版本，不会的。\n「Seata」：https://github.com/seata/seata\nTongsuo 8.3.2 版本发布 主要变更如下：\n1.修复 C90 下的编译问题；\n2.修复 SSL_CTX_dup() 函数的 bug；\n3.修复 NTLS ServerKeyExchange 消息的 RSA 签名问题；\n4.修复 apps/x509 的 SM2 证书签名 bug；\n5.支持新特性 - 添加导出符号前缀。\n下载地址：\nhttps://github.com/Tongsuo-Project/Tongsuo/releases/tag/8.3.2\n本周推荐阅读 Tongsuo 支持半同态加密算法 Paillier\n金融级应用开发｜SOFABoot 框架剖析\nSeata AT 模式代码级详解\nSOFA 飞船 Layotto 星球登陆计划最新进展\n欢迎扫码关注：\n","date":1671174000,"description":"SOFA Weekly | Tongsuo 8.3.2 版本发布、C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221216/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a5844a518eb6396a88e6c0ad05c590bc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221216/","publishdate":"2022-12-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221216/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Tongsuo 8.3.2 版本发布、C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221216/","wordcount":728},{"author":null,"categories":"SOFAStack","content":" 文｜李大元 （花名：达远）\nKusion 项目负责人\n来自蚂蚁集团 PaaS 核心团队，PaaS IaC 基础平台负责人。\n本文 4331 字 阅读 11 分钟\nPART. 1 后云原生时代 距离 Kubernetes 第一个 commit 已经过去八年多了，以其为代表的云原生技术早已不再是什么新技术，而是现代化应用的“标配”。现代化应用依赖的基础服务远不止 Kubernetes 一种，稍微复杂点的应用往往会同时使用到 Kubernetes 生态云原生技术、IaaS 云服务、企业内部自建系统等各种异构基础设施，可能还会有多云、混合云的部署需求，我们已经进入到了 ”后云原生时代”，只针对 Kubernetes 的运维工具早已不能满足我们的诉求。\n更复杂的是，在企业内部，这些服务一般是由不同团队维护的，一次规模化运维需要多个团队的成员互相配合才能完成，但是 App Dev、Platform Dev、SRE 各个团队之间缺少高效的协作方式。技术自身的复杂性加上低效的团队协作，使得 “后云原生时代” 的规模化运维难度有了指数级的提高。\nPART. 2 规模化运维的问题一直都在 复杂异构基础设施的规模化运维，这并不是后云原生时代特有的问题，自分布式系统诞生以来，一直都是一个难题，只是在后云原生时代，这个问题变得更加困难。十多年前业界提出了 DevOps 理念，无数企业基于此理念构建了自己的 DevOps 平台，希望解决此问题，但在实际落地的过程中往往不尽人意，Dev 团队和 Ops 团队之间如何合作？职责如何划分？几十人的平台团队，如何支持几万工程师的运维诉求？底层基础设施复杂多样，能力日新月异，如何快速让一线 Dev 享受到技术红利？这些问题一直没有得到很好的解决，最近又有人提出了 DevOps 已死，Platform Engineering 才是未来的说法。抛开概念定义，无论是 DevOps 还是 Platform Engineering，本质上都是企业规模化运维这同一命题下的不同理念，我们更需要的是一个符合技术发展趋势，能解决当前问题的解决方案。\nPART. 3 传统架构不再适用 在传统的运维思路中，解决上述问题的方法一般是构建一个 PaaS 平台，例如我们早期的蚂蚁 PaaS 平台，他是一个 Web 控制台，有 UI 界面，用户（通常是 App Dev 或 SRE）通过 UI 交互可以完成诸如发布、重启、扩缩容等操作。在技术实现上大体可以分为三部分，一个前端系统，提供用户交互的能力，作为系统入口；中间是一个后端系统，对接各个基础设施；底层是各个基础设的 API。这种架构运行了近十年，一直运行的很好，既有用户友好的交互界面，又可以屏蔽基础设施复杂性，而且各个团队之间还职责分明，但是到了如今后云原生时代，这种架构不再适用，暴露出有两个致命缺点， “费人” 、 “费时” 。\n举一个常见的例子，网络团队为其负责的 Loadbalancer（负载均衡器）开发了一种新的负载算法，需要提供给用户使用。\n在上述架构下，整个工作流程是这个样子：\n1.网络团队开发好能力，提供出 API；\n2.PaaS 后端通过编码对接底层 API，进行互联互通，屏蔽复杂性，提供面向用户的更高级别 API；\n3.PaaS 前端根据新功能修改 UI，利用后端 API 把能力透出给最终用户。\n这里存在一个问题，即使一个再小的功能，也需要 PaaS 后端和前端修改代码，整个流程下来最快也要一周才能上线，而且涉及的基础设施团队越多，效率越低。这个问题在十年前并不算是一个问题，但是在今天就是一个很大的问题，一个后云原生时代的现代化应用，使用三个云原生技术（Kubernetes + Istio + Prometheus），两个云服务（Loadbalancer + Database），一个内部自建服务，已经是一个很常见的形态了，复杂应用只会依赖的更多。如果每个基础设施都由 PaaS 团队硬编码对接一遍，PaaS 团队的人再扩大十倍也不够用。\n“费人”讲完了，我们再看看“费时”的问题。上面例子里的一个小功能，需要进行两次跨团队的协作，一次基础设施和 PaaS 后端，另一次是 PaaS 后端与 PaaS 前端。团队协作是一个很难的问题，有时候比技术本身还要难。应用的架构已经很复杂了，如果要做一次规模化运维，一次运维 100 个应用，这要和多少个团队沟通协作？要花费多少时间？没有好的协作机制，这就变成了一个不可能完成的任务。\nPART. 4 探索与实践 我们在蚂蚁集团内部进行了近两年的探索，kustomize、helm、argoCD、Terraform 这些常见的工具我们都实践过，甚至还为一些工具自研了一些辅助系统，但结果并不尽人意。这些工具要么太局限于 Kubernetes 生态，运维不了其他类型的基础设施，要么就是支持了异构基础设施，但对于 Kubernetes 生态支持的不友好，无法发挥出云原生技术的优势，而且只是运维工具的升级对于团队协作效率几乎没有提升，我们需要一套更加体系化的方案。\n回到问题本身，针对“费人”、“费时”的问题，我们提出两个思路：\n1.能否不让 PaaS 做中转，而是由 App Dev 通过一种高效自助的方式，使用到互联互通的各种基础设施能力？\n2.能否构建一个中心化的协作平台，用技术的手段规范大家的行为，标准化的进行沟通？\n从技术的角度来看，PaaS 平台需要提供灵活的工具链和工作流，基础设施所有能力都通过模块化的方式暴露出来，App Dev 利用这些平台的基本能力，自己组合、编排来解决自己的问题，过程中不需要平台层的参与。并且整个过程中涉及的所有团队，都使用统一的语言和接口进行交流，全程无需人工参与。\nPART. 5 我们的实践 经过在蚂蚁内部 PaaS 平台近两年的探索与实践，沉淀出一套端到端的完整方案， 取名为 KusionStack，目前已经开源。试图从统一异构基础设施运维与团队协作两个角度解决传统 PaaS “费人”、“费时”的问题。\n整个体系主要分为三个部分：\n1.Konfig：Git 大库，是多团队协作的中心化平台，存放着各个团队的运维意图；\n2.KCL：蚂蚁自研的配置策略 DSL，所有团队间交流的工具；\n3.Kusion：KusionStack 引擎，负责所有的运维操作。\nPlatform Dev 通过 KCL 定义好基础能力模型，App Dev 通过 import、mixin 等语言特性在应用配置模型（AppConfig）里复用这些预定义好的能力，快速在 Konfig 里描述运维意图。AppConfig 是一个精心设计过的模型，只暴露 App Dev 需要关心的属性，屏蔽基础设施的复杂性。\n永远不要低估基础设施的专业性与复杂性，即使已经成为云原生技术标准的 Kubernetes，对普通用户来说依然有很高的门槛，一个 Deployment 就有几十个字段，再加上自定义的 labels、annotations 就更多了，普通用户根本无法全部理解。或者说普通 AppDev 不应该去了解 Kubernetes，他们需要的只是发布，甚至不需要关心底层是不是 Kubernetes。\nAppConfig 经过编译 …","date":1671174000,"description":"已来到 “后云原生时代” 的我们，如何规模化运维？","dir":"blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"79ce4a433a89df3cd7edcf19c450a1f0","permalink":"https://sofastack.github.io/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","publishdate":"2022-12-16T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","summary":"文｜李大元 （花名：达远） Kusion 项目负责人 来自蚂蚁集团 PaaS 核心团队，PaaS IaC 基础平台负责人。 本文 4331 字 阅读 11 分钟 PART. 1 后云原生时代 距离 Kubernetes 第一个 commit 已经过","tags":["SOFAStack"],"title":"已来到 “后云原生时代” 的我们，如何规模化运维？","type":"blog","url":"/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","wordcount":3707},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#31:RPC 框架设计的考和量\n 活动时间：12 月 15 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#31 RPC 框架设计的考和量 本议题主要介绍 RPC 相关的概念和知识，和设计一个 RPC 框架需要关注的方面，以及从服务治理角度再谈 RPC 框架的设计，同时介绍 SOFARPC 在这些方面是如何实现的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 刘建军（花名：保义）\n SOFARPC Maintainer\n 蚂蚁集团基础组件研发，SOFARPC 开发者和维护者\n 议程 直播回放 https://www.bilibili.com/video/BV1pD4y187Gh/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1671087600,"description":"2022 年 12 月 15 日 19：00 - 20：00 ，线上直播第 31 期。","dir":"activities/sofachannel-31/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e59afb3aad30a8e2d7bc88251a256b03","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofachannel-31/","publishdate":"2022-12-15T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofachannel-31/","summary":"概要 活动主题：SOFAChannel#31:RPC 框架设计的考和量 活动时间：12 月 15 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播","tags":["SOFAChannel","SOFARPC","RPC 框架设计的考和量"],"title":"SOFAChannel#31 RPC 框架设计的考和量","type":"activities","url":"/sofastack.tech/activities/sofachannel-31/","wordcount":433},{"author":null,"categories":"SOFAStack","content":" 文｜王发康 （花名：毅松 ）\n蚂蚁集团技术专家、MOSN 项目核心开发者\n深耕于高性能网络服务器研发，目前专注于云原生 ServiceMesh、Nginx、MOSN、Envoy、Istio 等相关领域。\n本文 5574 字 阅读 14 分钟\n前言 从单体到分布式，解决了日益增长的业务在单体架构下的系统臃肿问题；从分布式到微服务，解决了服务化后的服务治理问题；从微服务到服务网格，解决了应用和基础设施耦合下的研发效能及稳定性问题。\n从微服务架构的演进历史来看，任何架构都不是一成不变，总是随着应用在不同阶段的痛点以及周边技术的发展而持续演进，而服务网格 （ServiceMesh） 概念从提出到生产落地至今已 6 年多了，那它的下一代架构应该是什么样？对此业界也有不同的声音 Service Mesh 的下一站是 Sidecarless 吗[1] ，本文主要介绍蚂蚁在这方面的探索和实践，最终如何帮业务降本增效，提升安全保障水位。\n一、 问题及挑战 谈起 ServiceMesh，大家的脑海中应该会呈现出下面这幅图，即 ServiceMesh 的 Sidecar 形态，它非常好的解决了应用和基础设施耦合下的系列问题，为业务的提效及稳定性等方面然禹功不可没。\n但是随着 ServiceMesh 的规模化增大，Sidecar 架构也随之暴露了一些劣势，譬如应用和 Sidecar 资源耦合导致相互抢占、生命周期绑定，导致应用扩缩容涉及额外 Sidecar 容器的创建及销毁开销、Sidecar 数量随着应用 Pod 数等比增加，导致其资源无法充分复用等。\n引用 redhat.com/architect/why-when-service-mesh\n1.1 资源耦合 Sidecar 形态虽然从代码维度是解耦了基础设施与应用的耦合，但是在资源方面目前仍然是和应用 Pod 绑定在一起，这就导致其资源管理成为一个难题。对此蚂蚁 ServiceMesh 在 Sidecar 资源管理[2] 进行改善，解决了初期的资源分配及管理。但随着业务的发展也暴露一些隐患，一方面 Sidecar 和应用相互抢占 CPU 可能导致引发时延毛刺问题，另一方面固定的 1\u0026amp;frasl;4 内存资源可能无法满足机房规模增大引发的网络连接数膨胀等系列问题。\n1.2 生命周期绑定 Sidecar 和应用属于同一个 Pod，而 K8s 是以 Pod 为最小单位进行管理的。这导致应用在扩缩容操作时会涉及额外 Sidecar 容器的创建及销毁开销，而 Sidecar 中的进程是基础设施软件本不应该随着应用的销毁而销毁。\n1.3 资源复用不充分 Sidecar 数量随着应用 Pod 数等比增加，而 Sidecar 上运行的都是基础设施通用能力，这将导致 Sidecar 中应用无关逻辑的 CPU 和内存等开销都在每个 Pod 中重复消耗。另外对于一些本能通过软件集中优化或硬件集中卸载的计数也无法充分施展。\n1.4 安全及业务侵入性 Sidecar 同应用同属一个 Pod，这无论对于 Sidecar 还是应用自身都是增大了安全攻击切面，另一方面 Sidecar 形态的服务治理也不算是完全业务无感的，至少要做一次 Sidecar 的注入，然后重启应用 Pod 才生效。\n二、思考及分析 对于上述 Sidecar 形态下的四个痛点：资源耦合、生命周期绑定、资源复用不充分、安全及业务侵入性，其实归根结底还是其架构导致。\n如果将 Sidecar 从应用 Pod 中剥离出来，对于资源耦合、生命周期绑定、安全侵入性问题都会迎刃而解，而资源复用粒度取决于剥离后部署的集中化程度。对于剥离后的集中化程度也并不是越集中越好，因为中心化后会增加交互时延以及能力的完整性缺失，所以在中心化和 Sidecar 化之间做一次折中，即通过 Node 化部署形态来解决，这样既可以做到同 Node 上的 Mesh 资源复用，又可以做到网络交互不跨 Node 的相关优化。\n虽然解决了 Sidecar 形态下的痛点，但是 Node 化后也引入了一些新的 “问题”。对于问题我们需要用辩证的眼光去看待，有时问题的背后可能是一个新机会。\n譬如 Sidecar 形态下的服务发现都是 Pod 级别，随着 Pod 规模的增大其服务条目成倍速增加，如果 Node 化后服务发现使用 Node IP 这样是不是可以成本的缩减服务条目，亦达到网络连接数的复用及收敛。\n- 隔离性、多租户： 多个应用共享 Mesh 后，涉及的一些应用维度的配置、内存、CPU 等资源如何相互隔离，另外对于 Sidecar 中各种基础设施组件如果自身来支持多租户，则改造成本是不可预估的。\n- 服务 pub/sub： 之前 Sidecar 形态下，Sidecar 和 APP 的 IP 是同一个 （Container 网络模式） ，Node 化后 IP 变成 Daemonset 容器的 IP，服务发现应如何管理？以及 Pod 和 Node 之间的流量如何管理。\n- 运维及安全合规\n a. Node 化后涉及到 Daemonset 自身以及应用维度的配置升级发布流程如何管控，同时出现故障时如何缩小爆炸半径；\n b. Node 化后涉及到的安全合规问题如何保证，如网络连通性如何隔离、身份等；\n c. Node 化后，Daemonset 所占用的机器成本如何规划 （超卖？独占？） 以及各个应用的资源消耗如何计算。\n三、方案介绍 将应用 Pod 中的 Sidecar 下沉到 Node，以 Daemonset 方式在每个 Node 部署。我们将该 Daemonset 命名为 NodeSentry，其定位是作为 Node 的网络基础设施，承载网络安全、流量治理、Mesh 下沉、连接收敛等 Node 相关网络治理平台。\n本文主要介绍 NodeSentry 承载 Mesh 下沉相关方案，Node 化后需要数据面 Proxy 能够高效、稳定的承载多个 Pod 的流量治理。这就要求数据面 Proxy 具备高处理性能及高研发效能，为此我们在 2021 年就其做了相关技术布局 MOSN2.0，详细介绍见 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态[3] 。\nMesh 下沉至 NodeSentry 其架构如上图所示，在新的架构下不仅能解决 Sidecar 形态的痛点，同时也具备了如下收益：\n- 资源解耦：解耦应用和基础设施的资源配额，多应用的 Mesh 资源池化、削峰填谷；\n- 资源复用：同 Node 同应用 Mesh 共享，ingress 方向连接收敛 、egress 方向连接共享、Node 级粒度 cache 命中率更高等；\n- Node 服务发现体系：解决注册中心等基础设施服务端压力以及调用端的内存消耗；\n- 提升启动速度：新架构下应用无需每次都启动 Mesh 的容器及镜像下载、SDK 初始化共享等额外操作；\n- 集中优化：云原生 L7 网络协议栈，软硬件结合性能优化，支持 IPV6，蚂蚁卡，RDMA or QUIC 等；\n- 解耦应用和网络： 同 Zero Trust Networking[4] 相关技术结合实现全局调度，有限互通等。 …","date":1670914800,"description":"降本增效：蚂蚁在Sidecarless 的探索和实践","dir":"blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7ece9ce602bb943fa14d61d09a0114a1","permalink":"https://sofastack.github.io/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","publishdate":"2022-12-13T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","summary":"文｜王发康 （花名：毅松 ） 蚂蚁集团技术专家、MOSN 项目核心开发者 深耕于高性能网络服务器研发，目前专注于云原生 ServiceMesh、Ngin","tags":["SOFAStack"],"title":"降本增效：蚂蚁在 Sidecarless 的探索和实践","type":"blog","url":"/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","wordcount":4731},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.小白 提问：\n 这个配置是起到什么作用？true\n A：declaredMode 是指：如果 biz 和宿主 biz 依赖相同的包，biz 会使用宿主 biz 内的包。即：biz 该包设置成 provided 时，安装 biz 至宿主 biz 可以正常使用，从而减小了 biz 的体积。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.肖才稳 提问：\n Seata 的回滚模式，如果数据库被其他应用改了，是不是不能回滚了？Seata 必须保证数据库只有自己一个应用用了是吗？\n A：那你可以用 XA，AT 是要保证所有操作数据库的动作都在 Seata 事务的全局事务覆盖下。也就是说，如果你这个库的这个表被其他应用用了，让这个应用也集成 Seata 就行了。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 cgo 机制 - 从 c 调用 go\nGo 内存泄漏，pprof 够用了么?\nSeata AT 模式代码级详解\nSOFA 飞船 Layotto 星球登陆计划最新进展\n欢迎扫码关注：\n","date":1670569200,"description":"SOFA Weekly | MOSN v1.3.0 版本发布、公众号半自助投稿、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221209/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c276f5a6fa8b10d73ba44cb43b79ea22","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221209/","publishdate":"2022-12-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221209/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.3.0 版本发布、公众号半自助投稿、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221209/","wordcount":664},{"author":null,"categories":"SOFAStack","content":" 文｜田阳 （花名：烈元）\nMOSN Maintainer\n专注云原生等技术领域\n本文3042字 阅读 10 分钟\n1. 背景 Service Mesh 被越来越多的公司认可并实践，在实际落地过程中也遇到了形形色色的问题，同时架构也在持续演进去解决这些问题：有的从初始的 DaemonSet mode 转变为 Sidecar mode，如 Linkerd ；有的从做 CNI 延伸到 Service Mesh 场景， 结合 eBPF 使用 DaemonSet mode，如 Cilium ；如今 Istio 也新增了 Ambient Mesh ，支持 DaemonSet mode 作为其主推模式。\n不难看出一个演进趋势就是围绕着是否需要 Sidecar 而展开，那么 Service Mesh 的下一站将会是 Sidecarless 吗？本文将对目前的社区趋势做一个简要分析， 最后也将介绍蚂蚁在这方面的探索和实践。\n2. 社区趋势 2.1 Cilium Cilium[1] 是目前最火的云原生网络技术之一，基于革命性的内核技术 eBPF，提供、保护和观察容器工作负载之间的网络连接。\n在 6 月份，Cilium 发布了 1.12 版本，其中发布了 Service Mesh 能力、Sidecarless 架构，它提供了两种模式：\n通过图表我们可以发现：针对 L3/L4 的能力，Cilium 使用内核的 eBPF 直接支持；对于 L7 的部分能力，将使用 DaemonSet 部署的 Envoy 来支持。Cilium 认为大部分能力都不需要 L7 的参与，通过 eBPF 就能满足，所以 Cilium 也称自己为内核级服务网格。\n针对于此 Cilium 也有一个解释，结合应用程序 TCPD 最终被合入 linux kernel 发展为 iptables 为例，认为 Mesh 也应该作为基础能力下沉到 linux kernel 作为网络的基础组件，就类似于 TCP，作为 Linux 的一部分透明地提供的服务。\n在当需要 L7 代理能力的时候，会构建 DaemonSet Envoy 处理 L7 的能力。Envoy 也已经有了 Namespace 的初步概念，它们被称为监听器。监听器可以携带单独的配置并独立运行，从而可以支持多租户的配置隔离 (但目前还做不到资源和故障的隔离） 。\nCilium 认为 DaemonSet 相比 Sidecar 最明显的好处就是代理数大大减少，减少资源和管理成本。\n可以看出 Cilium Service Mesh 的发展历程是由下而上，从内核层慢慢向业务层扩展自己的服务边界，由 eBPF 来支持服务网络也是有一定的立场因素。但 eBPF 并不是银弹，DaemonSet mode 也是有一些其他的问题，收益和损失都是相对的。\n2.2 Linkerd 当然，Cilium 这个架构也不乏有挑战者，其中来头最大的就是 Linkerd[2] （Service Mesh 概念的提出者） 的创始人 William Morgan ，比较有意思的是 Linkerd 最开始的架构是 DaemonSet mode ，在后面的版本才换成 Sidecar mode ，对于此，作为逆行者的他应该最有发言权。\n在 William Morgan 的最新文章[3] 中也客观提出了 eBPF 的一些局限性，为了保证 eBPF 的安全执行而不影响 kernel ，需要通过验证器验证是否有不正确的行为，这就导致 eBPF 的编写存在一定的潜规则，比如不能有无界循环；不能超过预设的大小等，代码的复杂性也就受到了一定限制。所以较复杂的逻辑用 eBPF 来实现也是有较高的成本的。\n文章中也提到了 DaemonSet 的一些弊端：\n- 资源管理不可评估：这取决于 K8s 调度多少 Pod 到该 Node；\n- 隔离性：所有应用公用一个 Proxy ，相互影响稳定性；\n- 爆炸半径变大：影响整个 Node 的 Pod 实例；\n- 安全问题更复杂：比如 Proxy 保存有整个 Node 的秘钥。\n简而言之，Sidecar 模式继续贯彻了容器级别的隔离保护 —— 内核可以在容器级别执行所有安全保护和公平的多租户调度。容器的隔离仍然可以完美的运行，而 DaemonSet 模式却破坏了这一切，重新引入了争抢式的多租户隔离问题。\n当然他也认为 eBPF 可以更好的促进 Mesh 的发展，eBPF+Sidecar 的结合是 Mesh 的未来。\n 我们也比较认可他对于 eBPF 的看法， eBPF 就像是一把瑞士军刀，小巧精湛，作为胶水把各种网络数据面连接起来，提供基础网络能力，比如提供访问加速，透明劫持，网络可观察性等能力。但要开发复杂的业务能力，在实操之后，感觉还是有点力不从心。目前我们团队也正在使用 eBPF 开发 K8s Service 和透明拦截等基础网络能力。\n William Morgan 的说法看着也不无道理，我们先不急着站队，再来看看 Istio 是怎么做的，看是否会有新的想法~\n2.3 Istio 在 9 月份，Service Mesh 领域的当家花旦 Istio 毫无征兆的发布了 Ambient Mesh ，并作为自己后续的主推架构，简单来讲就是把数据面从 Sidecar 中剥离出来独立部署，Sidecarless 架构，以彻底解决 Mesh 基础设施和应用部署耦合的问题。\n 比较好奇 Istio 在没有经过社区讨论和落地案例的情况下，是怎样决策笃定这个新的架构方向的呢？\n Istio 认为 Sidecar mode 存在如下三个问题：\n- 侵入性\n必须通过修改应用程序的 Kubernetes pod spec 来将 Sidecar 代理 “注入” 到应用程序中，并且需要将 Pod 中应用的流量重定向到 Sidecar 。因此安装或升级 Sidecar 需要重新启动应用 Pod ，这对工作负载来说可能是破坏性的。\n- 资源利用不足\n由于每个 Sidecar 代理只用于其 Pod 中相关的工作负载，因此必须针对每个 Pod 可能的最坏情况保守地配置 Sidecar 的 CPU 和内存资源。这导致了大量的资源预留，可能导致整个集群的资源利用不足。\n- 流量中断\n流量捕获和 HTTP 处理 通常由 Sidecar 完成，这些操作的计算成本很高，并且可能会破坏一些实现和 HTTP 协议不完全兼容的应用程序。\nEnvoy 的创始人也来凑了个热闹，他对 Sidecar 架构也是颇有微词。\n我们在落地过程中也是遇到了类似的痛点，比如随着机房规模和应用规模的变大，应用的连接数继续膨胀导致 CPU 和 MEM 资源占用也在持续增加，但这一切都不是应用本身想去关心的。\n那么让我们来解开 Ambient Mesh 架构真面目，是怎样来解决 Sidecar mode 的问题， 架构主要提出了分层：\n从图中可以看出，跟 Cilium 有一些类似，这儿的两层数据面都是基于 Envoy 来构建的，Secure Overlay Layer 主要处理 L4 场景，DaemonSet 部署，L7 processing Layer 主要处理 L7 场景， …","date":1669705200,"description":"Service Mesh 的下一站是 Sidecarless 吗？","dir":"blog/is-sidecarless-the-next-stop-for-servicemesh/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"620c3d0c618cffbc58020852e1ed722d","permalink":"https://sofastack.github.io/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","publishdate":"2022-11-29T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","summary":"文｜田阳 （花名：烈元） MOSN Maintainer 专注云原生等技术领域 本文3042字 阅读 10 分钟 1. 背景 Service Mesh 被越来越多的公司认可并实践，在实际落地过程中也遇到了形形色色","tags":["SOFAStack"],"title":"Service Mesh 的下一站是 Sidecarless 吗？","type":"blog","url":"/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","wordcount":3215},{"author":null,"categories":"SOFAStack","content":" 文｜王祖熙（花名：金九 )\n蚂蚁集团开发工程师\n负责国产化密码库 Tongsuo 的开发和维护\n专注于密码学、高性能网络、网络安全等领域\n本文 4316 字 阅读10 分钟\n1. 背景 在《Tongsuo 支持半同态加密算法 EC-ElGamal》中，已经阐述了同态和半同态加密算法的背景和原理，可以移步查阅。总之，同态算法在隐私计算领域有着重要的作用，目前应用比较广泛的是 Paillier 和 EC-ElGamal 半同态加密算法，它们接口类似且只支持加法同态。\n但是它们两者的性能和原理有很大的差异：\n原理方面，Paillier 是基于复合剩余类的困难性问题 （大数分解难题） 的公钥加密算法，有点类似 RSA；而 EC-ElGamal 是基于椭圆曲线数学理论的公钥加密算法，其安全性理论上要比 Paillier 要更好。\n性能方面，EC-ElGamal 的加密和密文加法性能要比 Paillier 好；而 Paillier 的解密和密文标量乘法性能要比起 EC-ElGamal 要更好更稳定 （EC-ElGamal 的解密性能与解密的数字大小有关系，数字越大可能需要解密的时间越长，这与 EC-ElGamal 解密用到的解密表有关系，而 Paillier 的解密就没有这个问题。） 。\n所以这两个产品各有优劣，大家可以根据自己的业务特点选择使用 Paillier 还是 EC-ElGamal。\n2. Paillier 原理 2.1 密钥生成 1.随机选择两个大素数 p、q，满足 ，且满足 p 和 q 的长度相等；\n2.计算以及 ，表示最小公倍数；\n3.随机选择整数，一般 g 的计算公式如下： a. 随机选择整数； b. 计算：，为了简化和提高性能，k 一般选 1，g=1+n；\n4.定义 L 函数：，计算：；\n5.公钥：(n, g)，私钥：(λ, μ)。\n2.2 加密 明文 m，满足 −n\u0026amp;lt;m\u0026amp;lt;n；\n 选择随机数 r，满足 0≤r\u0026amp;lt;n 且 ；\n 计算密文：。\n 2.3 解密\n 密文 c，满足；\n 计算明文：。\n 2.4 密文加法\n 密文：c1 和 c2，，c 就是密文加法的结果。 2.5 密文减法\n 密文：c1 和 c2，计算：，c 就是密文减法的结果。 2.6 密文标量乘法\n 密文：c1，明文标量：a，计算：，c 就是密文标量乘法的结果。 3. 正确性 3.1 加解密正确性 公式推导需要用到 Carmichael 函数和确定合数剩余的公式，下面简单说明一下：\n● Carmichael 函数\na. 设 n=pq，其中：p、q 为大素数；\nb. 欧拉函数：ϕ(n) ，Carmichael 函数：λ(n)；\nc. 当 和时，\n其中：。\n对于任意 ，有如下性质：。\n● 判定合数剩余\na. 判定合数剩余类问题是指 n=pq，其中：p、q 为大素数，任意给定，使得，则说 z 是模 的第 n 次剩余；\nb. 第 n 项剩余的集合是 的一个阶乘法子集；\nc. 每个第 n 项剩余 z 都正好拥有 n 个 n 阶的根，其中只有一个是严格小于 n 的 （即 ） ；d. 第n项剩余都可以写成 的形式。\n● 正确性验证\n解密：\n3.2 密文加法正确性 3.3 密文减法正确性 3.4 密文标量乘法正确性 4. 算法实现 4.1 接口定义 ●对象相关接口\n○公/私钥对象：PAILLIER_KEY ，该对象用来保存 Paillier 公钥和私钥的基本信息，比如 p、q、n、g、λ、μ 等信息，私钥保存所有字段，公钥只保存 n、g，其他字段为空或者 0。相关接口如下：\n// 创建 PAILLIER_KEY 对象 \\PAILLIER_KEY *PAILLIER_KEY_new(void); // 释放 PAILLIER_KEY 对象 void PAILLIER_KEY_free(PAILLIER_KEY *key); // 拷贝 PAILLIER_KEY 对象，将 src 拷贝到 dest 中 PAILLIER_KEY *PAILLIER_KEY_copy(PAILLIER_KEY *dest, PAILLIER_KEY *src); // 复制 PAILLIER_KEY 对象 PAILLIER_KEY *PAILLIER_KEY_dup(PAILLIER_KEY *key); // 将 PAILLIER_KEY 对象引用计数加1，释放 PAILLIER_KEY 对象时若引用计数不为0则不能释放其内存 intPAILLIER_KEY_up_ref(PAILLIER_KEY *key); // 生成 PAILLIER_KEY 对象中的参数，bits 为随机大素数 p、q 的二进制位长度 int PAILLIER_KEY_generate_key(PAILLIER_KEY *key, int bits); // 获取 key 的类型：公钥 or 私钥 // PAILLIER_KEY_TYPE_PUBLIC 为私钥，PAILLIER_KEY_TYPE_PRIVATE 为私钥 int PAILLIER_KEY_type(PAILLIER_KEY *key); ○上下文对象：PAILLIER_CTX，该对象用来保存公私钥对象以及一些其他内部用到的信息，是 Paillier 算法其他接口的第一个参数。相关接口如下：\n// 创建 PAILLIER_CTX 对象，key 为 paillier 公钥或者私钥，threshold 为支持最大的数字阈值，加密场景可设置为 0，解密场景可使用默认值： PAILLIER_MAX_THRESHOLDPAILLIER_CTX *PAILLIER_CTX_new(PAILLIER_KEY *key, int64_t threshold); // 释放 PAILLIER_CTX 对象 void PAILLIER_CTX_free(PAILLIER_CTX *ctx); // 拷贝 PAILLIER_CTX 对象，将 src 拷贝到 dest 中 PAILLIER_CTX *PAILLIER_CTX_copy(PAILLIER_CTX *dest, PAILLIER_CTX *src); // 复制 PAILLIER_CTX 对象 PAILLIER_CTX *PAILLIER_CTX_dup(PAILLIER_CTX *src); ○密文对象： PAILLIER_CIPHERTEXT ，该对象是用来保存 Paillier 加密后的结果信息，用到 PAILLIER_CIPHERTEXT 的地方，可调用如下接口：\n// 创建 PAILLIER_CIPHERTEXT 对象 PAILLIER_CIPHERTEXT *PAILLIER_CIPHERTEXT_new(PAILLIER_CTX *ctx); // 释放 PAILLIER_CIPHERTEXT 对象 void PAILLIER_CIPHERTEXT_free(PAILLIER_CIPHERTEXT *ciphertext); ●加密/解密接口\n// 加密，将明文 m 进行加密，结果保存到 PAILLIER_CIPHERTEXT 对象 …","date":1669100400,"description":"Tongsuo 支持半同态加密算法 Paillier","dir":"blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c3860b700dec4c686121bd9ef3565472","permalink":"https://sofastack.github.io/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","publishdate":"2022-11-22T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","summary":"文｜王祖熙（花名：金九 ) 蚂蚁集团开发工程师 负责国产化密码库 Tongsuo 的开发和维护 专注于密码学、高性能网络、网络安全等领域 本文 4316 字 阅读10 分钟 1. 背景 在","tags":["SOFAStack"],"title":"Tongsuo 支持半同态加密算法 Paillier","type":"blog","url":"/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","wordcount":3758},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.卓俊良 提问：\n Q: 22. AT 模式和 Spring @Transactional 注解连用时需要注意什么 ？\n A：@Transactional 可与 DataSourceTransactionManager 和 JTATransactionManager 连用，分别表示本地事务和 XA 分布式事务，大家常用的是与本地事务结合。当与本地事务结合时， @Transactional 和 @GlobalTransaction 连用，@Transactional 只能位于标注在 @GlobalTransaction 的同一方法层次或者位于 @GlobalTransaction 标注方法的内层。这里分布式事务的概念要大于本地事务，若将 @Transactional 标注在外层会导致分布式事务空提交，当 @Transactional 对应的 connection 提交时会报全局事务正在提交或者全局事务的 xid 不存在。\n 如果要支持 istio1.14 是需要重新适配吗？还是说有其他简化的方式？\n A：是需要适配下的，主要看新增了多少改动。\n「Seata」：https://github.com/seata/seata\n2.快叫我去学习 提问：\n Q: 34.Seata 的 JDK 版本要求是什么？\n A：目前 Seata 支持的 JDK 版本为 JDK8、11。其余版本不确保 100% 兼容。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Dragonfly 中 P2P 传输协议优化\nNydus | 容器镜像基础\nSOFARegistry | 大规模集群优化实践\n开源项目文档社区化！Tongsuo/铜锁实践\n欢迎扫码关注：\n","date":1668754800,"description":"SOFA Weekly |开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221122/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a317262c02b5a9ed70ec67cae8b88892","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221122/","publishdate":"2022-11-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221122/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221122/","wordcount":726},{"author":null,"categories":"SOFAStack","content":" 文｜孙珩珂\n上海交通大学\n本文1987字 阅读 10 分钟\n01 优化背景 此前 Dragonfly 的 P2P 下载采用静态限流策略，相关配置项在 dfget.yaml 配置文件中：\n# 下载服务选项。 download: # 总下载限速。 totalRateLimit: 1024Mi # 单个任务下载限速。 perPeerRateLimit: 512Mi 其中 perPeerRateLimit 为单个任务设置流量上限， totalRateLimit 为单个节点的所有任务设置流量上限。\n静态限流策略的理想情况是： perPeerRateLimit 设置为20M ， totalRateLimit 设置为 100M ，且该节点目前运行了 5 个或更多的 P2P 下载任务，这种情况下可以确保所有任务总带宽不会超过 100M ，且带宽会被有效利用。\n这种限流策略的缺点是：若perPeerRateLimit 设置为 20M ， totalRateLimit 设置为 100M ，并且当前该节点只运行了一个下载任务，那么该任务的最大下载速度为 20M ，和最大带宽 100M 相比，浪费了 80% 的带宽。\n因此，为了最大限度地利用带宽，需要使用动态限流来确保任务数量少时能能充分利用总带宽，而任务数量多时也能公平分配带宽。最终，我们设计出一套根据上下文进行动态限流的算法，其中上下文指各任务在过去一秒内使用的带宽，此外，算法还考虑到了任务数量、任务剩余大小、任务保底带宽等因素，性能相比原来的静态限流算法有显著提升。\n02 相关代码分析 perPeerRateLimit 配置项最终赋值给 peerTaskConductor 的pt.limiter ，由 peerTaskConductor 的 DownloadPiece() 函数里进行限速，pt.waitLimit() 进行实际限流工作，底层调用 Go 自带的限流函数 WaitN() 。\nTotalRateLimit 配置项则在创建 Daemon 时被赋值给 pieceManager 的pm.limiter ，在 pieceManager 的 DownloadPiece() 和 processPieceFromSource() 函数中用到的 pm.limiter ，而这两个函数都会由 peerTaskConductor 调用，也就是说 P2P 下载会先进行总限速，之后再进行每个任务单独限速。\n根据以上分析，Dragonfly 进行任务限速的逻辑为，每个peer task（peerTaskConductor）会有单独的限速 perPeerRateLimit ，同时 pieceManager 会有 TotalRateLimit 的总限速，以此达到单任务单独限流，同时限制所有任务总带宽的效果。\n03 优化方案 为了解决此前静态限流算法总带宽利用率不佳的缺点，需要将其改进为动态限流算法，即总带宽限速仍恒定，但每个任务的单独带宽限速需要根据上下文适度、定期调整，已达到最大化利用总带宽、同时相对公平分配带宽的目的。\n在经过数个改版后，最终我们确定了根据上下文进行限流的 sampling traffic shaper 动态限流算法。具体方案为，每个任务的单任务限流交由 TrafficShaper 组建进行统一管理， TrafficShaper 维护当前正在运行的所有任务，并且定期（每秒）更新这些任务的带宽。\n具体来说，上下文指每个任务在上一秒使用的带宽、每个任务的剩余大小、任务数量、任务保底带宽（不能低于 pieceSize ）等因素， TrafficShaper 会根据这些上下文公平地、效率最大化地为每个任务分配其下一秒的带宽（具体分配方案详见下一小节），实现动态限流的效果。\n04 优化实现 定义 TrafficShaper 接口如下：\n// TrafficShaper allocates bandwidth for running tasks dynamically type TrafficShaper interface { // Start starts the TrafficShaper Start() // Stop stops the TrafficShaper Stop() // AddTask starts managing the new task AddTask(taskID string, ptc *peerTaskConductor) // RemoveTask removes completed task RemoveTask(taskID string) // Record records task\u0026#39;s used bandwidth Record(taskID string, n int) // GetBandwidth gets the total download bandwidth in the past second GetBandwidth() int64 } 该接口有两种实现，第一种是 samplingTrafficShaper 即基于上下文的 traffic shaper ，第二种是 plainTrafficShaper 只记录带宽使用情况，除此之外不做任何动态限流工作，用于和 samplingTrafficShaper 对比性能提升。\n同时，将相关配置项修改为如下内容：\n# 下载服务选项。 download: # 总下载限速。 totalRateLimit: 1024Mi # 单个任务下载限速。 perPeerRateLimit: 512Mi # traffic shaper类型，有sampling和plain两种可选 trafficShaperType: sampling Traffic shaper 的具体运行逻辑为，由peerTaskManager维护trafficShaper，在创建peerTaskManager时，根据配置初始化trafficShaper，并且调用Start()函数，启动trafficShaper，具体来说，新建time.NewTicker，跨度为 1 秒，也即每秒trafficShaper都会调用updateLimit()函数以动态更新所有任务的带宽限流。\nupdateLimit() 函数会遍历所有运行中的任务，得出每个任务上一秒消耗的带宽以及所有任务消耗的总带宽，随后根据任务上一秒使用的带宽、任务剩余大小等因素，按比例分配带宽，具体来说首先根据上一秒该任务使用带宽以及该任务剩余大小的最大值确定下一秒该任务带宽，接着所有任务带宽根据总带宽按比例缩放，得到下一秒的真实带宽；同时需要确保每个任务的带宽不低于该任务的 pieceSize ，以免出现持续饥饿状态。\n在 peerTaskManager 的 getOrCreatePeerTaskConductor() 函数中，若新建任务，需要带宽，那么调用 AddTask() 更新所有任务的带宽，即按照已有任务的平均任务分配带宽，然后再根据总带宽上限将所有任务的带宽等比例进行缩放；根据平均带宽分配新任务带宽的优势为，避免了已经有一个任务占满了所有带 …","date":1668495600,"description":"Dragonfly 中 P2P 传输协议优化","dir":"blog/p2p-transfer-protocol-optimization-in-dragonfly/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9af455951fd545b7e7fa74b3eca908ce","permalink":"https://sofastack.github.io/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","publishdate":"2022-11-15T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","summary":"文｜孙珩珂 上海交通大学 本文1987字 阅读 10 分钟 01 优化背景 此前 Dragonfly 的 P2P 下载采用静态限流策略，相关配置项在 dfget.yaml 配置文件中： # 下载服务选项。 download: # 总下载","tags":["SOFAStack"],"title":"Dragonfly 中 P2P 传输协议优化","type":"blog","url":"/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","wordcount":2220},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. 奇奇 提问：\n Seata 可以用于生产环境吗？\n A：0.4.2 版本之后就可以上生产环境。\n「Seata」：https://github.com/seata/seata\n2. 牛康龙 提问：\n 在使用时遇到了如下图这个问题，请问该如何解决啊？ A：换 Hikari Durid 的 bug 。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读\ncgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\nGo 内存泄漏，pprof 够用了么？\nSeata AT 模式代码级详解\n欢迎扫码关注\n","date":1668150000,"description":"SOFA Weekly |本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221111/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a95c87454a97852938da43731c348498","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221111/","publishdate":"2022-11-11T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221111/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221111/","wordcount":497},{"author":null,"categories":"SOFAStack","content":" 文｜唐斌\n字节跳动基础架构研发工程师\nNydus 与 Nydus snapshotter 社区贡献者，专注存储，云原生技术。\n本文 6964 字 阅读 15 分钟\n1 Nydus 1.1 存在的问题 对于容器镜像使用者\n问题一： 启动容器慢：容器启动慢的情况普遍发生在当用户启动一个很大的容器镜像时，由于在容器准备阶段需要三步（以 overlayfs 为例）：\n- 下载镜像；\n- 解压镜像；\n- 使用 overlayfs 将容器可写层和镜像中的只读层聚合起来提供容器运行环境。\n其中，下载镜像阶段需要下载整个镜像文件，不能实现文件数据按需加载。再加上下载镜像本身受限于网络带宽，当容器镜像达到 GB 级别时，下载时间会较长，破坏了容器原本优秀的用户体验。\n问题二： 较高的本地存储成本：不同镜像之间可以共享的最小单位是镜像中的层，缺点之一是重复数据的处理效率较低。\n原因如下：\n- 首先，层内部存在重复的数据；\n- 其次，层与层之间可能存在大量重复的数据，即使有微小的差别，也会被作为不同的层；\n- 再次，根据 OCI imagespec 对删除文件和 hardlink 的设计，镜像内部已经被上层删除的文件可能仍然存在于下层，并包含在镜像中。\n对于镜像提供者\n这里的提供者主要指容器服务的镜像中心。\n问题一： 巨大的存储资源浪费。\n- 存在大量相似镜像，造成这种情况有两个原因：\n 首先，上面提到的层的缺点，导致在容器镜像中心存在许多相似镜像；\n 其次，OCI image 使用了 tar+gzip 格式来表示镜像中的层，而 tar 格式并不区分 tar archive entries ordering，这带来一个问题，如果用户在不同机器上 build 同一个镜像，最终可能会因为使用了不同的文件系统而得到不同的镜像，用户上传之后，镜像中心中会存在若干不同镜像的实质内容是完全相同的情况。\n - 镜像去重效率低\n虽然镜像中心有垃圾回收机制来实现去重功能，但其仍然以层为单位，所以只能在有完全相同 hash value 的层之间去重。\n问题二： 云原生软件供应链带来的新需求。\n随着时间推移，和软件供应链一起发展的还有对软件供应链环节的多样性攻击手段。安全防护是软件供应链中非常重要的组成，不光体现在对软件本身的安全增强，也体现在对供应链的安全增强。因为应用运行环境被前置到了容器镜像中，所以对容器镜像的安全，包括对镜像的漏洞扫描和签名成为了容器服务提供者的必要能力。\nOCI 镜像规范的缺陷\n主要的缺陷有两点：\n- tar 格式标准\n tar 格式并不区分 tar archive entries ordering，这带来一个问题，即如果用户在不同机器上 ；build 同一个镜像，最终可能会因为使用了不同的文件系统而得到不同的镜像，比如在文件系统 A 上的 order 是 foo 在 bar 之前进入 tar ，在文件系统 B 上的 order 是 bar 在 foo 之前进入tar ，那么这两个镜像是不同的；\n 当 tar 被 gzip 压缩过之后不支持 seek ，导致运行之前必须先下载并解压 targz 的 image layers，而不能实现文件数据按需加载。\n - 以层为镜像的基本单位\n 内容冗余：不同层之间相同信息在传输和存储时都是冗余内容，在不读取内容的时候无法判断到这些冗余的存在；\n 无法并行：每一层是一个整体，对同一个层既无法并行传输，也不能并行提取；\n 无法进行小块数据的校验，只有完整的层下载完成之后，才能对整个层的数据做完整性校验；\n 其他一些问题：比如，跨层数据删除难以完美处理。\n 1.2 Nydus 基础 在容器的生产实践中，偏小的容器镜像能够很快部署启动。当应用的镜像达到 GB 级以上的时候，在节点上下载镜像通常会消耗大量的时间。Dragonfly 通过引入 P2P 网络有效地提升了容器镜像大规模分发的效率。然而，用户必须等待镜像数据完整下载到本地，然后才能创建自己的容器。\nNydus 是在最新的 OCI Image-Spec 基础之上设计的容器镜像加速服务，重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。Nydus 由阿里云和蚂蚁集团的工程师合作开发，并大规模部署在内部的 生产环境中。\nNydus 优化了现有的 OCI 镜像标准格式，并以此设计了一个用户态的文件系统。通过这些优化，Nydus 能够提供这些特性：\n 容器镜像按需下载，用户不再需要下载完整镜像就能启动容器\n 块级别的镜像数据去重，最大限度为用户节省存储资源\n 镜像只有最终可用的数据，不需要保存和下载过期数据\n 端到端的数据一致性校验，为用户提供更好的数据保护\n 兼容 OCI 分发标准和 artifacts 标准，开箱即可用\n 支持不同的镜像存储后端，镜像数据不只可以存放在镜像仓库，还可以放到 NAS 或者类似 S3 的对象存储上\n 与 Dragonfly 的良好集成 1.3 Nydus 架构 Nydus 的架构主要包含两部分内容：\n- 新的镜像格式（Rafs）\n- 负责解析容器镜像的 FUSE 用户态文件系统进程\nNydus 兼容多种文件系统，能够解析 FUSE 和 virtiofs 协议来支持传统的 runc 容器、 Kata容器。对于存储后端，支持使用容器仓库（ Registery ）、OSS 对象存储 、NAS、Dragonfly 的超级节点和 Peer 节点作为 Nydus 的镜像数据存储后端。此外，为了加速启动速度，Nydus 还可以配置一个本地缓存，避免每次启动容器时都从远端数据源拉取数据。\n1.4 Nydus 特性 容器启动速度变快\n用户部署了 Nydus 镜像服务后，由于使用了按需加载镜像数据的特性，容器的启动时间明显缩短。在官网的测试数据中，Nydus 能够把常见镜像的启动时间，从数分钟缩短到数秒钟。理论上来说，容器镜像越大，Nydus 体现出来的效果越明显。\n提供运行时数据一致校验\n在传统的镜像中，镜像数据会先被解压到本地文件系统，再由容器应用去访问使用。解压前，镜像数据是完整校验的。但是解压之后，镜像数据不再能够被校验。这带来的一个问题就是，如果解压后的镜像数据被无意或者恶意地修改， 用户是无法感知的。而 Nydus 镜像不会被解压到本地，同时可以对每一次数据访问进行校验，如果数据被篡改，则可以从远端数据源重新拉取。\n从图中可以看出，对容器镜像数据进行运行时一致性校验是通过对每个数据块计算 SHA 256 实现的，这得益于 Nydus 采用分块的方式管理镜像数据。如果在镜像文件非常大的时候，对整个镜像文件计算哈希值非常不现实。\n1.5 Nydus 镜像格式：RAFS RAFS 是对 EROFS 文件系统的增强，拓展在云原生场景下的能力，使其适应容器镜像存储场景。RAFS v6 是内核态的容器镜像格式，除了将镜像格式下沉到内核态，还在镜像格式上进行了一系列优化，例如块对齐、更加精简的元数据等。\nRAFS v6 镜像格式\n1.6 Nydus -snapshotter Nydus snapshotter 是 containerd 的一个外部插件， …","date":1667977200,"description":"Nydus | 容器镜像基础","dir":"blog/container-image-basics/","fuzzywordcount":6100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa785f9400252d3285438e7ad8a39218","permalink":"https://sofastack.github.io/sofastack.tech/blog/container-image-basics/","publishdate":"2022-11-09T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/container-image-basics/","summary":"文｜唐斌 字节跳动基础架构研发工程师 Nydus 与 Nydus snapshotter 社区贡献者，专注存储，云原生技术。 本文 6964 字 阅读 15 分钟 1 Nydus 1.1 存在的问题 对于容器镜像使用者 问题一： 启动","tags":["SOFAStack"],"title":"Nydus | 容器镜像基础","type":"blog","url":"/sofastack.tech/blog/container-image-basics/","wordcount":6057},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.康政恒 提问：\n MOSN 做链路追踪是否需要 APP 配合传递 traceID、spanID 这些吗? A：链路追踪都需要 APP 配合的，这是业务决定，跟是不是 MOSN 没关系。\n 「MOSN」：https://github.com/mosn/mosn/\n2.康政恒 提问：\n MOSN 是否和 APP 也保持长链接呀，这样可以知道 APP 的存活状态。 A：保持长链接。\n 「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 SOFARegistry | 大规模集群优化实践\ncgo 机制 - 从 c 调用 go\nSeata AT 模式代码级详解\nGo 内存泄漏，pprof 够用了么？\n欢迎扫码关注：\n","date":1667545200,"description":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221104/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"32dcc5c5b6f04360aa073fe5820a4d12","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221104/","publishdate":"2022-11-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221104/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221104/","wordcount":519},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#30:Nydus 开源容器镜像加速服务的演进与未来\n 活动时间：11 月 03 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#30 Nydus 开源容器镜像加速服务的演进与未来 Nydus 在生产环境已经支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，网络带宽效率，端到端数据一致性等方面相比 OCIv1 格式有着巨大优势，并可扩展至例如 NPM 包懒加载等数据分发场景。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 严松（花名：井守）\n Nydus 镜像加速开源项目 Maintainer\n 负责蚂蚁集团基础设施研发，专注于云原生镜像与容器运行时生态。\n 议程 直播回放 https://b23.tv/Gnz9y6D\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1667458800,"description":"2022 年 11 月 03 日 19：00 - 20：00 ，线上直播第 30 期。","dir":"activities/sofa-channel-30/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"51b6ca632e0cf11ccff50820a472a320","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-30/","publishdate":"2022-11-03T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-30/","summary":"概要 活动主题：SOFAChannel#30:Nydus 开源容器镜像加速服务的演进与未来 活动时间：11 月 03 日，周四晚 19 点 活动形式：线上直播 资料","tags":["SOFAChannel","Nydus","开源容器镜像加速服务的演进与未来"],"title":"SOFAChannel#30 Nydus 开源容器镜像加速服务的演进与未来","type":"activities","url":"/sofastack.tech/activities/sofa-channel-30/","wordcount":485},{"author":null,"categories":"SOFARegistry","content":" 文｜李旭东\n专注于 SOFARegistry 及其周边基础设施的开发与优化\n本文 7016 字 阅读 15 分钟\n1 前言 SOFARegistry 在蚂蚁内部迭代升级过程中，每年大促都会引来一些新的挑战，通过不断的优化这些在大规模集群遇到的性能瓶颈，我们总结出一些优化方案，来解决大规模集群遇到的性能问题。\n通过阅读这篇文章，读者可以学习到一些 Java 和 Go 语言系统的优化技巧，在系统遇到瓶颈的时候，能够知道有哪些优化手段针对性的进行优化。\n2 大规模集群的挑战 随着业务的发展，业务的实例数在不断增长，注册中心所需要承载的数据量也在快速的增长 ，以其中 1 个集群为例，2019 年的数据为基准数据，在 2020 年 pub 接近千万级。下图是该集群历年双 11 时的数据对比。 相比 2019 年双 11，2021 年双 11 接口级的 pub 增长 200%，sub 增长 80%。实例数和数据量的增长带来推送量的二次方形式的增长，SOFARegistry 每一年大促都会经历新的挑战。\n比如，在某一年的新机房压测过程中，由于新机房规模特别大（普通机房的 4 倍），导致注册中心的推送压力变大了十倍多，出现了 ：\n- DataServer 的网络被打爆，导致大量数据变更没有及时通知到 Session ，推送延迟飙升；\n- 因为数据包过大， SessionServer 与客户端之间出现了大量的 channel overflow 推送失败，推送延迟飙升；\n- 由于实例数量过多，注册中心的推送包以及内部传输的数据包过大，很容易打满单机的网络处理上限，序列化数据也会占用大量的 CPU ；\n- 由于地址列表扩大了几倍，导致对应推送接收端 MOSN 也出现了问题，大量机器出现 OOM ， 出现大量 CPU 毛刺影响请求延迟；\n- 注册中心常见瞬间大量并发的请求，比如业务大规模重启，很容易导致瞬时注册中心自身处理能不足，如何进行限流，以及如何快速达到数据最终一致。\n3 优化方案 针对上述大规模集群遇到的挑战，我们做了以下的优化方案：\n3.1 横向扩展支撑大规模集群 在大规模集群场景下，单纯采用扩大机器规格的纵向扩展方式往往会遇到瓶颈，单机的配置是有上限的，超大的 heap gc 时也可能产生较高的暂停时间，而且恢复与备份会花费很长时间。\n3.1.1 双层数据架构进行数据分片 双层数据架构: Session (会话层：分散链接)、Data （数据层：分散数据）来实现横线扩展的能力，通过对链接和数据进行分片，SOFARegistry 可以通过横向扩容很容易的支撑更大的集群。单机采用小规格的机器，在容灾以及恢复方面也可以取得很好的效果。\nSOFARegistry 的架构可以参见： https://www.sofastack.tech/blog/explore-sofaregistry-1-infrastructure/\n3.2 应对瞬时大量请求 注册中心存在瞬时处理大量请求的场景，比如当在大量应用同时发生运维或者注册中心自身发生运维的时候，会有大量的注册请求发送到 Session 。\n同时有一些依赖注册中心的基础设施会通过变更发布数据到注册中心来通知到每一个订阅端。为了应对这种不可预见的瞬时大量请求变更，注册中心需要有一定的策略进行削峰。\n3.2.1 队列攒批处理 贴合蚂蚁的业务，为大规模集群而生，在大数据量，高并发写入下提供稳定的推送延迟，通过添加队列并进行攒批处理，提高吞吐量，对瞬间高并发请求进行削峰。\n举例：\n- Session 接收到大量 Publisher ，攒批发请求到 Data [1]\na.利用 BlockingQueue 存储需要发送 的请求，同时会配置最大容量防止 OOM\nb.独立的 Worker 线程从 BlockingQueue 中取出多个请求，创建多个 BlockingQueue 和 Worker 提高并发度\nc.按照分片规则进行分组，打包成一个请求发往不同的 DataServer\n- Session 接收到大量 Subscriber ，聚合去重后创建推送任务 *[2]*\na.Subscriber 存储到 Map的数据结构中，可以进行去重的避免短时间一个实例重复注册创建大量推送任务\nb.定时从 Map 中取出 Subscribers ，进行分组创建推送任务\nc.最大数据量是 Session 单机的所有 Subscriber ，容量可控\n- 用 Map 存储 DataServer 上发生变化数据的 DataInfoId ，聚合通知 Session 进行推送[3]\na.短时间 DataServer 的数据可能变化多次，比如大量 Publisher ，数据修复定时任务等等\nb.对这些数据变化记录 DataInfoId ， 短时间只会对 Session 通知一次变更创建推送任务\nc.最大数据量是 Data 单机全部的 DataInfoId\n- 用 Map 存储 PushTask 进行去重，避免数据连续变化触发大量推送任务[4]\na.添加了 Map size 的检查，过多的推送任务会直接丢弃，防止 OOM\nb.同样的推送任务高版本会替换掉低版本\n3.3 减少网络通讯开销 3.3.1 LocalCache Session 和 Data 之间会有大量的数据通讯，通过添加 LocalCache 可以在不增加代码架构复杂度的前提下大幅度提升系统的性能。\n对于注册中心，服务数据可以通过 dataInfoId + version 唯一标识。Session 在创建推送任务时会从 Data 拉取最新的服务数据，利用 Guava 的 LoadingCache ,大量推送任务被创建时，缓存的利用率会比较高，可以减少很多从 Data 拉取数据的开销。\n- Session 利用 LoadingCache 从 Data 拉取数据[5]\na.会传入创建推送任务时的版本（一般由 Data 的变更通知带过来）对比 Cache 内的数据是否足够新；\nb.如果不够新，清理缓存后利用 LoadingCache 从 Data 拉取一次数据；\nc. LoadingCache 会配置 maximumWeight 防止数据过多导致 OOM 。\n3.3.2 压缩推送 在集群规模比较大的时候，比如有一个应用发布了 100 个接口，每个接口的发布数据有 150B ，该应用有 8000 个实例，每个接口有 2w 订阅方。那么每次变更这个应用的机器造成的全量推送，每个推送包 1MB ， 累积需要发出 200w 个推送包，即使 Session 可以横向扩容到 100 台， Session 单机也需要在 7 秒内发出 20GB 的流量，严重阻塞 Session 的网络队列，也会很快打爆 netty buffer ，造成大量的推送失败，这么多推送包的序列化也会耗费 Session 大量的 CPU 。\n对于 Data ，如果 Session 的数量过多，每次变更需要给每台 Session 返回大量的大数据包，也会产生大量的出口流量，影响其他请求的成功率。\n由于每个实例发布的数据的相似度很高，几乎只有 IP 不一致，所以当采用压缩推送时压缩率会非常高，能压 …","date":1667458800,"description":"SOFARegistry | 大规模集群优化实践","dir":"blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"56b7649b36ba3889527d68dc2214c31d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","publishdate":"2022-11-03T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","summary":"文｜李旭东 专注于 SOFARegistry 及其周边基础设施的开发与优化 本文 7016 字 阅读 15 分钟 1 前言 SOFARegistry 在蚂蚁内部迭代升级过程中，每年大促都会引来一些新的挑战，通过不断的优","tags":["SOFARegistry"],"title":"SOFARegistry | 大规模集群优化实践","type":"blog","url":"/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","wordcount":5846},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.康恒政 提问：\n MOSN 之间是维持长链接的吗，然后像 Spring Cloud、Dubbo、Bolt 协议的数据在这个长链接上面传递吗？\n A：支持的，MOSN 原生就支持 Dubbo，Bolt 协议。\n「MOSN」：https://github.com/mosn/mosn/\n2.康恒政 提问：\n 注册中心是不是可以支持其他种类的，比如 ZooKeeper、Eureka 什么的？\n A：可以的，可以自己扩展，默认支持了 ZK 。\n「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 cgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\n从规模化平台工程实践，我们学到了什么？\n直播预告丨SOFAChannel#30《Nydus 开源容器镜像加速服务的演进与未来》\n欢迎扫码关注：\n","date":1666940400,"description":"SOFA Weekly | MOSN v1.2.0 版本发布、开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly/20221028/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8890ddd864d60166dc508e0ec80d9049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly/20221028/","publishdate":"2022-10-28T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly/20221028/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.2.0 版本发布、开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly/20221028/","wordcount":605},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 4656 字 阅读 12 分钟\n一、前言 去年刚学 go 语言的时候，写了这篇 cgo 实现机制[1] ，介绍了 cgo 的基本情况。主要介绍的是 go=\u0026amp;gt;c 这个调用方式，属于比较浅的层次。随着了解的深入，发现 c=\u0026amp;gt;go 的复杂度又高了一级，所以有了这篇文章。\n二、两个方向 首先，cgo 包含了两个方向， c=\u0026amp;gt;go ，go=\u0026amp;gt;c 。\n相对来说，go=\u0026amp;gt;c 是更简单的，是在 go runtime 创建的线程中，调用执行 c 函数。对 go 调度器而言，调用 c 函数，就相当于系统调用。执行环境还是在本线程，只是调用栈有切换，还多了一个函数调用的 ABI 对齐，对于 go runtime 依赖的 GMP 环境，都是现有的，并没有太大的区别。\n而 c=\u0026amp;gt;go 则复杂很多，是在一个 c 宿主创建的线程上，调用执行 go 函数。这意味着，需要在 c 线程中，准备好 go runtime 所需要的 GMP 环境，才能运行 go 函数。以及，go 和 c 对于线程掌控的不同，主要是信号这块。所以，复杂度又高了一级。\n三、GMP 从哪里来 首先简单解释一下，为什么需要 GMP ，因为在 go 函数运行的时候，总是假设是运行在一个 goroutine 环境中，以及绑定有对应的 M 和 P 。比如，要申请内存的时候，则会先从 P 这一层 cache 的 span 中的获取，如果这些没有的话，go runtime 就没法运行了。\n虽然 M 是线程，但是具体实现上，其实就是一个 M 的数据结构来表示，对于 c 创建的协程，获取的是 extra M ，也就是单独的表示线程的 M 数据结构。\n简单来说，c 线程需要获取的 GMP ，就是三个数据对象。在具体的实现过程中，是分为两步来的：\n1. needm 获取一个 extra M\n开启了 cgo 的情况下，go runtime 会预先创建好额外的 M ，同时还会创建一个 goroutine，跟这个 M 绑定。所以，获取到 M，也就同时得到了 G。\n而且，go runtime 对于 M 并没有限制，可以认为是无限的，也就不存在获取不到 M 的情况。\n2.exitsyscall 获取 P\n是的，这个就是 go=\u0026amp;gt;c 的反向过程。只是 P 资源是有限的，可能会出现抢不到 P 的情况，此时就得看调度机制了。\n四、调度机制 简单情况下，M 和 P 资源都顺利拿到了，这个 c 线程，就可以在 M 绑定的 goroutine 中运行指定的 go 函数了。更进一步，如果 go 函数很简单，只是简单的做点纯 CPU 计算就结束了，那么这期间则不依赖 go 的调度了。\n有两种情况，会发生调度：\n1. exitsyscall 获取不到 P 此时没法继续执行了，只能：\n1.将当前 extra M 上绑定的 g ，放入全局 g 等待队列\n2.将当前 c 线程挂起，等待 g 被唤起执行\n在 g 被唤起执行的时候，因为 g 和 M 是绑定关系：\n1.执行 g 的那个线程，会挂起，让出 P ，唤起等待的 c 线程\n2.c 线程被唤起之后，拿到 P 继续执行\n2. go 函数执行过程中发生了协程挂起 比如，go 函数中发起了网络调用，需要等待网络响应，按照之前介绍的文章，Goroutine 调度 - 网络调用[2] 。当前 g 会挂起，唤醒下一个 g ，继续执行。\n但是，因为 M 和 g 是绑定关系，此时会：\n1. g 放入等待队列\n2.当前 c 线程被挂起，等待 g 被唤醒\n3. P 被释放\n在 g 被唤醒的时候，此时肯定不是在原来的 c 线程上了\n1.当前线程挂起，让出 P，唤醒等待的 c 线程\n2.c 线程被唤醒后，拿到 P，继续执行\n直观来说，也就是在 c 线程上执行的 goroutine，并不像普通的 go 线程一样，参与 go runtime 的调度。对于 go runtime 而言，协程中的网络任务，还是以非阻塞的方式在执行，只是对于 c 线程而言，则完全是以阻塞的方式来执行了。\n为什么需要这样，还是因为线程的调用栈，只有一个，没有办法并发，需要把线程挂起，保护好调用栈。\nPS：这里的执行流程，其实跟上面抢不到 P 的流程，很类似，底层也是同一套函数在跑（核心还是 schedule）。\n五、信号处理 另外一大差异是，信号处理。\n c 语言世界里，把信号处理的权利/责任，完全交给用户了。\n go 语言，则在 runtime 做了一层处理。\n 比如，一个具体的问题，当程序运行过程中，发生了 segfault 信号，此时是应该由 go 来处理，还是 c 来响应信号呢？\n答案是，看发生 segfault 时的上下文：\n1.如果正在运行 go 代码，则交给 go runtime 来处理\n2.如果正在运行 c 代码，则还是 c 来响应\n那具体是怎么实现的呢？信号处理还是比较复杂的，有比较多的细节，这里我们只介绍几个核心点。\n1. sighandler 注册 首先，对于操作系统而言，同一个信号，只能有一个 handler 。再看 go 和 c 发生 sighandler 注册的时机：\n go 编译产生的 so 文件，被加载的时候，会注册 sighandler（仅针对 go 需要用的信号），并且会把原始的 sighandler 保存下来。\n c 可以在任意的时间，注册 sighandler，可以是任意的信号。\n 所以，推荐的做法是，在加载 go so 之前，c 先完成信号注册，在 go so 加载之后，不要再注册 sighandler 了，避免覆盖 go 注册 sighandler。\n2.信号处理 对于最简单的情况，如果一个信号，只有 c 注册了 sighandler，那么还是按照常规 c 信号处理的方式来。\n对于 sigfault 这种，go 也注册了 sighandler 的信号，按照这个流程来：\n1.操作系统触发信号时，会调用 go 注册的 sighandler（最佳实践中，go 的信号注册在后面）；\n2.go sighandler 先判断是否在 c 上下文中（简单的理解，也就是没有 g，实际上还是挺复杂的）；\n3.如果，在 c 上下文中，会调用之前保存的原始 sighandler（没有原始的 sighandler，则会临时恢复 signal 配置，重新触发信号）；\n4.如果，在 go 上下文中，则会执行普通的信号处理流程。\n其中，2 和 3 是最复杂的，因为 cgo 包含了两个方向，以及信号还有 sigmask 等等额外的因素，所以这里细节是非常多的，不过思路方向还是比较清晰的。\n六、优化 上篇 cgo 实现机制[1] ，提过优化一些思路，不过主要针对 go =\u0026amp;gt; c 这个方向。因为 c =\u0026amp;gt; go 的场景中，还有其他更重要的优化点。\n1.复用 extra M 通常情况下，最大的性能消耗点在获取/释放 M。\n1.上面提到，从 c 进入 go，需要通过 needm 来获取 M 。这期间有 5 个信 …","date":1665212400,"description":"cgo 机制 - 从 c 调用 go","dir":"blog/c-go-mechanism-calling-go-from-c/20221008/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a233624b1a608f5d80599295f0599d5b","permalink":"https://sofastack.github.io/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","publishdate":"2022-10-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 4656 字 阅读 12 分钟 一、前言","tags":["SOFAStack"],"title":"cgo 机制 - 从 c 调用 go","type":"blog","url":"/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","wordcount":4794},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. greedying 提问：\n 我发现 MOSN 去 cookie 时候，如果取不到，则返回中横线。这里万一 cookie 值就是中横线怎么办呢？\n A：你用啥接口取的？\n 用变量取的,前缀加 cookie 的 key。 \u0026amp;gt;\u0026amp;gt;MOSN 代码就是这么写的，那个 ValueNotFound 是一个短横，这是一个 feature 还是 bug？\n A：哦 确实，这儿应该返回 error 就行了，不然任何值都有可能不对。 要这样处理才合理，通过 error 来判断了。\n「MOSN」：https://github.com/mosn/mosn\n2. 卿同学 提问：\n 我看 Layotto 也在推动和 Envoy 的融合，这一块现在有进展吗？\n A：今年我们首先会开源 Envoy 的 cgo 插件，然后基于这个插件，可以把 Layotto 跑在 Envoy 上。\n「Layotto」：https://github.com/mosn/layotto\n本周推荐阅读\ncgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\nGo 内存泄漏，pprof 够用了么？\nSeata AT 模式代码级详解\n欢迎扫码关注\n","date":1665126000,"description":"SOFA Weekly | C 位大咖说 \u0026 QA","dir":"blog/sofa-weekly-20221007/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2d8af727a21b1ea54ab966afa87a0c03","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221007/","publishdate":"2022-10-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221007/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说 \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221007/","wordcount":623},{"author":null,"categories":"SOFAStack","content":"文｜杨洋（花名：凯申 )\n铜锁开源密码库创始人蚂蚁集团高级技术专家\n本文 1284 字 阅读 5 分钟\n1 前言\n如大家所见，针对铜锁开源密码库（ *https://github.com/Tongsuo-Project*）的文档，我们正在逐步地进行一些改革。\n其中，最大的一个变化是：我们把原来放在 readthedocs.org（简记 rtfd.io）上的教程和说明文档转移到了语雀上。\n为此有必要和大家解释一下，这其中的原因以及背后的一些想法。\n2 说说历史原因\n铜锁开源项目自诞生以来，其文档管理不是那么的严格和统一。\n铜锁派生自 OpenSSL ，而 OpenSSL 的文档则是以 perldoc 体系为核心，且混合了一部分的纯文本和 markdown 。OpenSSL 的这些文档内容均散落在 OpenSSL 源代码仓库的各个目录中。\n对于 perldoc 所支持的 pod 格式的文件，可以被编译成多种不同最终格式的文档，这其中以 man 手册和 html 文件为主。\n综上所述，所以铜锁项目在早期延续了编写 pod 文件并编译成 html 和 man 手册的这种模式，随着项目的发展，我们发现此模式存在若干不足，例如：\n perldoc 这套体系过于古老，文档的编写依旧停留在“非可视化”的状态。且编译过程较为复杂，和 markdown 等相比不具备优势，也不够通用；\n man 手册也比较古老，是单机的本地模式。查询文档的功能较弱，效率较低，不如 readthedocs 这种可视化的查询文档的方式来得便捷；\n OpenSSL 的文档组织形式更多的是以 API 为出发点，而不是以“教程”为出发点，这对于很多新手用户来说无从下手。\n 3 早前的一些改进\n为了解决这些不足之处，铜锁项目将文档的重心从 API 视角切换到了教程视角，即以教会用户如何通过使用铜锁来完成某种功能为核心目标，重新组织了文档的形态，并以 markdown 写了若干教程类的文档。\n这些文档需要一个呈现平台，因此我们选择了成熟的 readthdocs.org 作为铜锁文档的发布地（https://tongsuo.rtfd.io ），并持续运行了一段时间。\n在这之后，我们又发现了一些问题：\n1.访问不便。readthedocs.org 是海外的文档托管网站，国内会出现访问比较慢甚至无法访问的状况；\n2.不容易交互。更多的是单方面的信息展示，用户真有问题还是要到 Github 上提交 issue，效率比较低。\n4 “文档社区化”的诞生\n前段时间，我机缘巧合的参与了一档播客节目的录制\n*（https://www.ximalaya.com/zhubo/343307074）*。\n在录制过程中，大家也讨论到：是否可以将互动引入到开源社区的文档体系中，将开源项目的文档“社区化”，进而形成除了代码托管平台之外的、更加贴近最终用户的社区交流讨论形式。\n受此启发，我们最后决定尝试将铜锁的全部文档迁移到语雀上，利用语雀的社区化能力，增强铜锁和其用户间的互动。具体来说有如下几点：\n1.新的文档网站地址为：*https://yuque.com/tsdoc* 。目前有两个知识库，铜锁的各种文档均分类到这些知识库中，而且都是对全网公开的，后续我们也会根据需要对知识库去做一些调整；\n2.用户可以在这些文档中进行评论；3.上述知识库的文档会每天同步备份到 Github 的指定仓库中；\n4.现有的 *https://tongsuo.rtfd.io* 将不再更新。\n此外，对于 API ，我们也会重新进行梳理，将铜锁特有的 API 整理后供用户检索查询。希望大家能和我们一起参与这场“文档社区化”的试验，欢迎伙伴们充分发表自己的意见、建议以及想法，一起将这次试验更好地落地。\n本周推荐阅读\n你好，我的新名字叫“铜锁/Tongsuo”\nBabaSSL：支持半同态加密算法 EC-ElGamal\nBabaSSL 发布 8.3.0｜实现相应隐私计算的需求\nSeata AT 模式代码级详解\n","date":1664434800,"description":"开源项目文档社区化！Tongsuo/铜锁实践","dir":"blog/20220929/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8f7a5b72bc271ef963ccea749cb0e888","permalink":"https://sofastack.github.io/sofastack.tech/blog/20220929/","publishdate":"2022-09-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/20220929/","summary":"文｜杨洋（花名：凯申 ) 铜锁开源密码库创始人蚂蚁集团高级技术专家 本文 1284 字 阅读 5 分钟 1 前言 如大家所见，针对铜锁开源密码库（ *https://gi","tags":["SOFAStack"],"title":"开源项目文档社区化！Tongsuo/铜锁实践","type":"blog","url":"/sofastack.tech/blog/20220929/","wordcount":1401},{"author":null,"categories":"SOFAStack","content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。\n本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同；\n- 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。\n平台工程旨在帮助企业构建面向应用研发者的自服务运维体系，尝试通过工程化的技术手段和工作流程解决以下关键问题：\n- 设计合理的抽象层次，帮助应用研发者降低对 Infra 、platform 等技术以及运维、稳定性工作的认知负担；\n- 为应用研发者提供统一的工作界面和空间，避免用户陷入割裂的平台产品界面、复杂的工作流中；\n- 帮助研发者通过有效的工作流程和推荐路径基于 内部工程平台[4] 快速开展工作；\n- 帮助研发者通过配套的 CI 、CD 、CDRA 等产品自服务管理应用生命周期；\n- 帮助平台产品研发团队简单、高效、一致的开放其平台基础能力；\n- 通过培训、布道、运营等手段营造协同工作和分享的文化。\n事实上，不是所有人都应该或者能够成为这个领域的专家，这非常困难！\n实际上平台技术团队的专家通常也仅擅长自己的专业领域而已，特别是在云原生理念和技术广泛应用的今天，面向大量高度开放、可配置的平台技术带来的成百上千的应用配置，PaaS 领域的业务复杂性，以及高稳定性和统一治理的要求，而平台工程的目的正是为了让应用研发者尽可能简单无痛的参与到这样规模化的 DevOps 工作中。\n在蚂蚁的实践中，我们更趋向于以下这种合作状态，在团队架构和工作模式上更靠近 Google 的最佳实践。平台研发者及 SRE 成为 “ Enabler ” 支持应用研发者自服务的完成研发及交付运维，同时应用研发者使其应用可交付运维的工作结果也成为运维人员可以接手应用运维工作的基础。最终 SRE 、应用研发及运维人员把工作过程中的问题和痛点反馈给平台研发者形成正向循环。\n三、专用语言：工程化方式的一极 有什么比一种专用语言更适合开放的、自服务的、面向领域业务的问题定义，同时需要满足自动化、低安全风险、低噪音、易治理的企业内部要求吗？正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在平台工程的特定问题域内，一批配置和策略语言用于编写和管理规模化复杂配置及策略。\n不同于混合编写范式、混合工程能力的高级通用语言，这类专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将规模化复杂配置和策略编写思路和方式沉淀到语言特性中。\n在蚂蚁的平台工程实践中，我们强化了客户端的工作方式，将围绕应用运维生命周期的模型、编排、约束和策略稳定、可扩展的通过专用语言 KCL[5] 编写维护在共享仓库 Konfig[6] 中。\nKCL 是一种面向有编程能力的应用研发者的静态强类型语言，提供现代高级语言的编写体验和围绕领域目的有限功能。在平台工程实践中 KCL 不是一种仅用于编写 K-V 对的语言，而是一种面向平台工程领域的专用语言。应用研发者、 SRE 、平台研发者面向 Konfig 协同研发，通过 KCL 原生功能编写应用配置，以及在 PaaS 领域更为高频和复杂的 模型抽象[7] 、 功能函数[8] 和 约束规则[9] ，即编写稳定、可扩展的业务模型、业务逻辑、防错约束和环境规则。\nKonfig 仓库则成为统一的编程界面，工作空间和业务层载体，而基于 KCL 的安全、低噪音、低副作用、一致的编写范式更有利于长期管理和治理。\n四、分治：解构规模化问题 分治思路是解决规模化问题的钥匙，从 MapReduce 到 Kubernetes 无不体现其功效。在规模化交付运维领域，经典运维平台试图在统一的黑盒平台产品中，以内置的统一模型、编排、 provision 技术来应对全量业务场景。这样的实践可以快速启动，在小范围内奏效，但随着不同业务主体采用率提升引入差异化需求，同时随着持续变化的平台技术逐渐进入疲态。\n在蚂蚁的实践中，Konfig monorepo 是内部工程平台向研发者开放的编程界面和工作空间，帮助应用研发者以统一的编程界面编写围绕应用运维生命周期的配置和策略，从而编排和使用存量和新增的平台基础设施，按需创建管理云原生环境以及基于 RBAC 的权限，并通过 GitOps 方式管理交付过程。\nKonfig monorepo 为不同场景、项目、应用提供了独立的白盒的编程空间，其内生的扩展性来源于：\n- 灵活、可扩展、独立的客户端的 工程结构设计[10] ；\n- 独立配置块自动合并技术[11] 支持任意分块、可扩展的配置块组织；\n- 静态类型系统[12] 技术提供现代编程语言可复用、可扩展的类型化建模和约束功能；\n- 项目粒度的 GitOps CI 工作流程定义支持；\n- 基于 Kusion[13] 引擎的 provision 技术选择。\nKonfig monorepo 提供了分治的、可组合的工程结构设计、代码组织、建模方式、工作流程定义和 provision 技术选择支持，同时又以一致的研发模式和工作流承载了可扩展的业务需求。这样客户端的工作方式在保证灵活性、可扩展性、可移植性的同时也降低了对服务 …","date":1664262000,"description":"从规模化平台工程实践，我们学到了什么？","dir":"blog/sofastack20220927/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa7d711a2d4e1a4f7c4242cbfe473fa2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack20220927/","publishdate":"2022-09-27T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofastack20220927/","summary":"文｜朵晓东（花名：奕杉 ) KusionStack 负责人、蚂蚁集团资深技术专家 在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作 一、摘要 本文尝试从平台","tags":["SOFAStack"],"title":"从规模化平台工程实践，我们学到了什么？","type":"blog","url":"/sofastack.tech/blog/sofastack20220927/","wordcount":6378},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.刘家燕 提问：\n MOSN 现在支持 TCP 服务按照端口灰度么？譬如：应用场景：接入了一个 TCP 服务，分别暴露了三个端口是 60403，60269，60129，每一个端口对应不同的业务来源，调用之后会对应不同的业务处理。目的：现在对其中一个端口例如 60403 逻辑处理做了一些调整，发版验证是否顺利调用。因此，将该服务进行灰度，创建 v1，v2 版本。当监听到 60403 端口调用时，路由到v2 ；其他端口，路由到v1 。\n A：最简单的就是你建两个 listener，不同端口的 listener 的路由对应不同的 cluster，比如 cluster_v1，cluster_v2。\n 意思是给创建灰度的版本各自创建一个 listener 吗？\n A：因为本来就要监听不同的端口，所以不同端口的 listener 配置不同的 router 就行了哦。\n「MOSN」：https://github.com/mosn/mosn/\n2.Lewise Liu \u0026amp;amp; 赵宇 提问：\n 请问，MOSN 可以与新版本 Istio 控制面集成吗？\n A：目前是支持的 1.10 ，新版本的话要做一些适配。\n 具体需要哪些适配？比如 1.14 。\n A：我的理解，主要是新版本的 xDS 会新增一些 feature，如果依赖这些新 feature 的话，就需要做一些对应的适配或许也有一些在新版本里，被废弃或者调整了的（这些应该不多的）。\n「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 Seata AT 模式代码级详解\nGo 内存泄漏，pprof 够用了么？\n社区文章｜MOSN 构建 Subset 优化思路分享\nGo 代码城市上云——KusionStack 实践\n欢迎扫码关注：\n","date":1663916400,"description":"SOFA Weekly |开源人、本周 QA、本周 Contributor","dir":"blog/sofa-weekly/20220923/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0aeda2b5aff95f678add334d82d2e2b0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly/20220923/","publishdate":"2022-09-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly/20220923/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly |开源人、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly/20220923/","wordcount":879},{"author":null,"categories":"SOFAStack","content":" 文｜\n刘月财\nseata-go 项目负责人\n北京小桔科技有限公司【滴滴】开发工程师\n赵新（花名：于雨 )\n蚂蚁集团 Seata 项目开源负责人\n本文5343字 阅读 14分钟\n背景 Seata 四种事务模式中，AT 事务模式是阿里体系独创的事务模式，对业务无侵入，也是 Seata 用户最多的一种事务模式，兼具易用性与高性能。\n目前，Seata 社区正大力推进其多语言版本建设，Go、PHP、JS 和 Python 四个语言版本基本完成了 TCC 事务模式的实现。参照 Seata v1.5.2 版本的 AT 模式的实现，并结合 Seata 官方文档，本文尝试从代码角度详解 Seata AT 事务模式的详细流程，目的是梳理 Seata Java 版本 AT 模式的实现细节后，在多语言版本后续开发中，优先实现 AT 事务模式。\n1、什么是 AT 模式？ AT 模式是一种二阶段提交的分布式事务模式，它采用了本地 undo log 的方式来数据在修改前后的状态，并用它来实现回滚。从性能上来说，AT 模式由于有 undo log 的存在，一阶段执行完可以立即释放锁和连接资源，吞吐量比 XA 模式高。用户在使用 AT 模式的时候，只需要配置好对应的数据源即可，事务提交、回滚的流程都由 Seata 自动完成，对用户业务几乎没有入侵，使用便利。\n2、AT 模式与 ACID 和 CAP 谈论数据库的事务模式，一般都会先谈论事务相关的 ACID 特性，但在分布式场景下，还需要考虑其 CAP 性质。\n2.1 AT 与 ACID 数据库事务要满足原子性、一致性、持久性以及隔离性四个性质，即 ACID 。在分布式事务场景下，一般地，首先保证原子性和持久性，其次保证一致性，隔离性则因为其使用的不同数据库的锁、数据 MVCC 机制以及相关事务模式的差异， 具有多种隔离级别，如 MySQL 自身事务就有读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）、序列化（Serializable）等四种隔离级别。\n2.1.1 AT模式的读隔离 在数据库本地事务隔离级别读已提交（Read Committed） 或以上的基础上，Seata（AT 模式）的默认全局隔离级别是读未提交（Read Uncommitted） 。\n如果应用在特定场景下，必须要求全局的读已提交，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。 SELECT FOR UPDATE 语句的执行会查询全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到全局锁拿到，即读取的相关数据是已提交的，才返回。\n出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。\n详细例子参考 Seata 官网：https://seata.io/zh-cn/docs/dev/mode/at-mode.html\n2.1.2 AT 模式的写隔离 AT 会对写操作的 SQL 进行拦截，提交本地事务前，会向 TC 获取全局锁，未获取到全局锁的情况下，不能进行写，以此来保证不会发生写冲突：\n- 一阶段本地事务提交前，需要确保先拿到全局锁；\n- 拿不到全局锁，不能提交本地事务；\n- 拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。\n详细例子参考 Seata 官网：https://seata.io/zh-cn/docs/dev/mode/at-mode.html\n2.2 AT 与 CAP Seata 所有的事务模式在一般情况下，是需要保证 CP，即一致性和分区容错性，因为分布式事务的核心就是要保证数据的一致性（包括弱一致性）。比如，在一些交易场景下，涉及到多个系统的金额的变化，保证一致性可以避免系统产生资损。\n分布式系统不可避免地会出现服务不可用的情况，如 Seata 的 TC 出现不可用时，用户可能希望通过服务降级，优先保证整个服务的可用性，此时 Seata 需要从 CP 系统转换为一个保证 AP 的系统。\n比如，有一个服务是给用户端提供用户修改信息的功能，假如此时 TC 服务出现问题，为了不影响用户的使用体验，我们希望服务仍然可用，只不过所有的 SQL 的执行降级为不走全局事务，而是当做本地事务执行。\nAT 模式默认优先保证 CP，但提供了配置通道让用户在 CP 和 AP 两种模式下进行切换：\n- 配置文件的 tm.degrade-check 参数，其值为 true 则分支事务保证 AP，反之保证 CP；\n- 手动修改配置中心的 service.disableGlobalTransaction 属性为 true，则关闭全局事务实现 AP。\n3、AT 数据源代理 在 AT 模式中，用户只需要配置好 AT 的代理数据源即可， AT 的所有流程都在代理数据源中完成，对用户无感知。 AT 数据源代理的整体类结构如下图：\n AT 事务数据源代理类结构图【from *https://seata.io/zh-cn/docs/dev/mode/xa-mode.html*】\nAT 的数据源代理中，分别对目标数据库的 DataSource 、 Connection 和 Statement 进行了代理，在执行目标 SQL 动作之前，完成了 RM 资源注册、 undo log 生成、分支事务注册、分支事务提交/回滚等操作，而这些操作对用户并无感知。\n下面的时序图中，展示了 AT 模式在执行过程中，这几个代理类的动作细节：\n注：图片建议在 PC 端查看\n4、AT 模式流程 以下是 AT 模式的整体流程，从这里可以看到分布式事务各个关键动作的执行时机，每个动作细节，我们后面来讨论：\n注：图片建议在 PC 端查看\n4.1 一阶段 在 AT 模式的第一阶段， Seata 会通过代理数据源，拦截用户执行的业务 SQL ，假如用户没有开启事务，会自动开启一个新事务。如果业务 SQL 是写操作（增、删、改操作）类型，会解析业务 SQL 的语法，生成 SELECT SQL 语句，把要被修改的记录查出来，保存为 “before image” 。然后执行业务 SQL ，执行完后用同样的原理，将已经被修改的记录查出来，保存为 “after image” ，至此一个 undo log 记录就完整了。随后 RM 会向 TC 注册分支事务， TC 侧会新加锁记录，锁可以保证 AT 模式的读、写隔离。RM 再将 undo log 和业务 SQL 的本地事务提交，保证业务 SQL 和保存 undo log 记录 SQL 的原子性。\n4.2 二阶段提交 AT 模式的二阶段提交，TC 侧会将该事务的锁删除，然后通知 RM 异步删除 undo log 记录即可。\n4.3 二阶段回滚 如果 AT 模式的二阶段是回滚，那么 RM 侧需要根据一阶段保存的 undo log 数据中的 before image 记录，通过逆向 SQL 的方式，对 …","date":1663657200,"description":"Seata AT 模式代码级详解","dir":"blog/20220920/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6769242244447e5e61c3cd74b1d4fbbb","permalink":"https://sofastack.github.io/sofastack.tech/blog/20220920/","publishdate":"2022-09-20T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/20220920/","summary":"文｜ 刘月财 seata-go 项目负责人 北京小桔科技有限公司【滴滴】开发工程师 赵新（花名：于雨 ) 蚂蚁集团 Seata 项目开源负责人 本文5343字 阅读 14分钟 背景 Seata 四种事","tags":["SOFAStack"],"title":"Seata AT 模式代码级详解","type":"blog","url":"/sofastack.tech/blog/20220920/","wordcount":4292},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.杜鑫 提问：\n 想问下 MOSN 的基于 Go plugin 实现的插件机制，有相关文档介绍嘛，源码大概在哪个部分呀？想接入下试试。\n A：有好几种，有 Go plugin 独立进程的，有 Go so 编译的，我发你文档先看看。\n 这个看啦，我看文档里说 so 的方式还在 beta，没有详细介绍，想了解下 so 方式的介绍。\n A：so 的，我们最近有位同学才分享了，干货满满：https://mp.weixin.qq.com/s/VAYrtYBdzvcAOa7G_cMZRg ，这里有个 demo，https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions 以及一些插件的实现，https://github.com/mosn/extensions/tree/master/go-plugin\n「MOSN」：https://github.com/mosn/mosn/\n2.林楠 提问：\n 有一个问题，动态部署时报找不到 CommonLoggingApplicationListener 类，这个类在基座中有这个类 https://github.com/sofastack/sofa-ark/issues/561\n A：说明这个类没有成功委托给基座加载，可以断下 BizClassLoader.loadClassInternal 方法，看下模块类加载的寻找过程。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 MOSN｜Go 原生插件使用问题全解析\nGo 内存泄漏，pprof 够用了么？\n如何看待 Dapr、Layotto 这种多运行时架构？\nSOFAServerless 助力业务极速研发\n欢迎扫码关注：\n","date":1663311600,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220916/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"810dfae8641310109a14ebe511d3d818","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220916/","publishdate":"2022-09-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220916/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220916/","wordcount":864},{"author":"SOFA 团队","categories":"SOFATalk","content":" 概要 活动主题：SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 活动时间：09 月 14 日，周三晚 19 点 活动形式：线上直播 直播回放：点击观看 资料下载：戳这里 查看文章：SOFARegistry 源码解析｜推送延迟 tracre 介绍 | SOFATalk \u0026amp;lt;SOFA:Talk/\u0026amp;gt; SOFATalk 系列活动是 SOFAStack 社区开展的全新直播栏目，与以往的直播不同的是，SOFATalk 为大家搭建了一个更加自由开放的交流环境，参与者不仅可以在直播间发送弹幕讨论，还能够进入钉钉会议与嘉宾直接连麦讨论！茶余饭后，跟着 SOFA Talk 一下～\n| SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 对于分布式注册中心，整个推送过程涉及到很多的流程和节点。如何计算从发布端变更到广播给全集群所有的订阅方的延迟？以及每个阶段的延迟分别是多少？这对排查集群内部的问题及注册中心的负载具有比较大的价值，因此需要对整个推送过程进行延迟链路跟踪。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n分享嘉宾 张晨\n SOFARegistry Contributor，开源爱好者。\n 嘉宾海报 了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1663138800,"description":"2022 年 9 月 14 日 19：00 - 20：00 ，Talk 第 1 期。","dir":"activities/sofa-talk-1/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7a05d225a66088112646cb4424d8f344","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-talk-1/","publishdate":"2022-09-14T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-talk-1/","summary":"概要 活动主题：SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 活动时间：09 月 14 日，周三晚 19 点 活动形式：线上直播 直播回放：点击观看 资料下载：戳这里","tags":["SOFATalk","SOFARegistry","源码解析"],"title":"SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace","type":"activities","url":"/sofastack.tech/activities/sofa-talk-1/","wordcount":473},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者、蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 2651 字 阅读 8 分钟\nMOSN 是主要使用 Go 语言开发的云原生网络代理平台，在蚂蚁集团有着几十万容器的大规模生产应用。在这种大规模的应用中，经常会遇到各种内存问题，通常情况下 pprof heap profile 可以很好帮助分析问题。不过，有时候 pprof 也不够用，也就需要我们有更合适的工具了。\nPart.1\u0026amp;ndash;出生证 vs 暂住证 首先 pprof 确实很好用，设计实现也都很精巧，有兴趣的可以查看这篇《Go 语言 pprof heap profile 实现机制》[1]。\n用 pprof 来分析内存泄漏，通常情况下是够用了，不过有时候，也会不够用。\n这是为什么呢？因为 pprof 只是记录了内存对象被创建时的调用栈，并没有引用关系。也就是说，没有办法知道，内存对象是因为被谁引用了而导致没有被释放。对此，我的同事\u0026amp;ndash;烈元同学有一个很形象的比喻，pprof 只能看到出生证，却查不了暂住证。\nPart.2\u0026amp;ndash;需要引用关系 有些场景下，我们知道了泄漏的内存是从哪里申请的，但是翻了半天代码，也搞不清楚内存为什么没有释放。比如，内存对象经过复杂的调用传递，或者复杂的内存池复用机制，又或者传给了某个不熟悉的第三方库，在第三方库中有非预期的使用……\n在这些情况下，我们会有一个很直觉的想法是，想看看这些内存对象的引用关系。\nPart.3\u0026amp;ndash;内存引用关系火焰图 内存引用关系火焰图，是一种内存对象引用关系的可视化方式，最早应用于 OpenResty XRay 产品。这个工具确实是内存分析神器，给不少的客户定位过内存问题，感兴趣的可以移步 OpenResty 官方博客[2]。\n下图是由一个 MOSN 服务产生的，自下而上表示的是从 GC root 到 GC object 的引用关系链，宽度表示的是对象大小 （也包括其引用的对象的大小之和） 。\n有了这样的可视化结果，我们就可以直观的看到内存对象的引用关系。\n比如下图最宽的部分，表示的是 MOSN 中 cluster_manager 全局变量中引用的 cluster 内存对象：\nhttps://github.com/mosn/mosn/blob/aecc93c4b2b4801e7992387f245fe9eefa45733d/pkg/upstream/cluster/cluster_manager.go#L82\nPart.4\u0026amp;ndash;实现原理 在生成火焰图之前，首先我们需要提取两个关键信息：\n- 每个内存对象之间的引用关系；\n- 每个内存对象的类型。\n引用关系 获取引用关系比较简单，首先，我们可以在 heap 中找到所有的 GC 对象。然后遍历所有的对象，再结合 bitmap 信息，获取这个对象引用的其他对象。基本原理跟 GC mark 是类似的，虽然实现上很不一样，但因为这个是离线工具，可以简单粗暴的实现。\n类型推导 Go 语言作为编译型静态语言，是不需要为每个内存对象存储类型信息的 （有点例外的是 interface） 。如果是动态类型语言，比如 Lua，则会方便很多，每个 GC 对象都存储了对象的类型。\n所以，要获取每个对象的类型，还是比较麻烦的，也是投入时间最多的一块。当然，还是有解决办法的，简单来说就是做逆向类型推导，根据已知内存的类型信息，推导被引用的内存对象的类型信息。\n这块还是比较复杂的，有兴趣的可以看这篇《Go 语言，如何做逆向类型推导》[3]的介绍。\n生成过程 有了这两个关键信息之后，生成过程如下还是比较清晰的：\n1. 获取所有的内存对象，包括类型、大小，以及他们之间的引用关系，形成一个图；\n2. 从 root 对象出发，按照层次遍历，形成一棵树 （也就是剪枝过程，每个对象只能被引用一次） ；\n3. 将这棵树的完整引用关系，当做 backtrace dump 下来，count 是当前节点的总大小 （包括所有子节点） ，也就是火焰图上的宽度；\n4. 从 bt 文件生成 svg，这一步是 brendangregg 的 FlameGraph 标准工具链。\nPart.5\u0026amp;ndash;使用方式 这个工具是基于 Go 官方的 viewcore 改进来的。不过，鉴于 Go 官方不那么热心维护 viewcore 了，MOSN 社区先 fork 了一份，搞了个 mosn 分支，作为 MOSN 社区维护的主分支。\n之前也给 Go 官方 debug 提交了好几个 bugfix，等后面有空，我们再去提交这个 feature。\n所以，使用方式如下：\n# 编译 mosn 维护的 viewcore git clone git@github.com:mosn/debug.git cd debug/cmd/viewcore go build . # 假设已经有了一个 core 文件（CORE-FILE） # 以及对应的可执行程序文件（BIN-FILE） viewcore CORE-FILE --exe BIN-FILE objref ref.bt # 下载 FlameGraph 工具 git clone git@github.com:brendangregg/FlameGraph.git ../FlameGraph/stackcollapse-stap.pl ref.bt | ../FlameGraph/flamegraph.pl\u0026amp;gt; ref.svg # 浏览器打开 ref.svg 即可看到火焰图 如果使用碰到问题，可以随时联系我们或提交 issue（https://github.com/mosn/mosn/issues）。\n当然，倘若你成功定位了某个问题，也欢迎与我们共同分享，Let\u0026amp;rsquo;s have fun together！\nMOSN 用户钉钉群：33547952\n相关链接 [1] 《Go 语言 pprof heap profile 实现机制》：https://uncledou.site/2022/go-pprof-heap/\n[2] OpenResty 官方博客：https://blog.openresty.com.cn/cn/openresty-xray-case-yundun/\n[3] 《Go 语言，如何做逆向类型推导》：https://uncledou.site/2022/go-type-derivation/\n了解更多… MOSN Star 一下✨： https://github.com/mosn/mosn\n插播一条好消息！🤩\n对 Go 语言开发感兴趣的小伙伴们,欢迎大家参与到近期正热的 GoCity 项目体验\n点击此处查看演示视频，快速入门吧🥳\n本周推荐阅读 MOSN 反向通道详解\nGo 原生插件使用问题全解析\nGo 代码城市上云\u0026amp;ndash;KusionStack 实践\nMOSN 文档使用指南\n欢迎扫码关注：\n","date":1663052400,"description":"Go 内存泄漏，pprof 够用了吗？","dir":"blog/is-pprof-enough-for-go-memory-leak/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c96e193420c2f17fd7653b33766f4296","permalink":"https://sofastack.github.io/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","publishdate":"2022-09-13T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者、蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 2651 字 阅读 8 分钟 MOSN 是主","tags":["SOFAStack"],"title":"Go 内存泄漏，pprof 够用了吗？","type":"blog","url":"/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","wordcount":2059},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过\u0026amp;rdquo;SOFA WEEKLY\u0026amp;rdquo;的形式回复\n1.我是一个小胖子 提问：\n MOSN 现在是已经完整支持 xDS 协议了吗？\n A：支持 istio1.10。\n 如果要支持 istio1.14 是需要重新适配吗？还是说有其他简化的方式？\n A：是需要适配下的，主要看新增了多少改动。\n「MOSN」：https://github.com/mosn/mosn/\n2.林楠 提问：\n 关在 uninstall biz 包的时候，没有从内嵌 Tomcat 卸载掉，接口仍能访问。看到 demo 中的提示是由于未注册 BeforeBizStopEvent，所以不具备动态卸载能力。想问下 SOFAArk 是否有计划做 Tomcat 的动态卸载，如果想自行实现的话，是不是调用 ArkTomcatWebServer 实例的 stop 方法就能够实现动态卸载？\n A：Spring Boot 模块没有动态卸载能力：https://github.com/sofastack/sofa-ark/issues/554#issuecomment-1207183454\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 MOSN｜Go 原生插件使用问题全解析\n社区文章｜MOSN反向通道详解\nMOSN 文档使用指南\nSOFAServerless 助力业务极速研发\n欢迎扫码关注：\n","date":1662706800,"description":"SOFA Weekly | Go 代码城市、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220909/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b48f13a6692060ffac5ff1eeb1886fb2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220909/","publishdate":"2022-09-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220909/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Go 代码城市、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220909/","wordcount":749},{"author":null,"categories":"SOFAStack","content":"导语\nKusionStack 是面向 Kubernetes 云原生场景的 IaC 配置代码化实践的开源一站式可编程协议栈。其基本思想是让「应用方+平台方」的同学能够共同基于 IaC 构建的 Konfig 模型库同一平面进行 DevOps 协同工作。今天我们和大家分享一个好玩的 Go 代码城市应用，以及 KusionStack 是如何一键将其部署到 K8s 云原生环境的。\nKusionStack 项目主仓库：\nhttps://github.com/KusionStack/kusion\nPART. 1\n什么是代码城市（CodeCity）\nCodeCity 代码城市是瑞典工程师 Richard Wettel 开发的创意应用，可以通过类似数字城市的视觉形式展示和度量代码的复杂性。其效果如图：\n在 3D 形式展示的代码城市中的中心地标非常直观——最大、最高的建筑总是容易追踪的焦点。因为这个极具特色的创意，CodeCity 获得了 2008 年的\u0026amp;rdquo;Riconoscimento ated-ICT Ticino\u0026amp;rdquo; 一等奖，同时也可以免费用于非商业的科研和学习用途。\n今天要展示的 GoCity 是 Go 语言版本的代码城市，我们可以通过这种方式评估 KusionStack 等 Go 语言项目的代码复杂度。也可以通过在线的 GoCity 查看 KusionStack/kusion 仓库的展示效果。\nPART. 2\n本地执行 GO 代码城市\n之前的 GoCity 还是在 2021 年 10 月更新的，在最新的 Docker 和 Go1.18 环境有一些小问题，还好 KusionStack 相关同学为其提交了补丁进行了修复（_这也是开源项目的魅力所在，也希望开源社区小伙伴能够参与 KusionStack 的共建_），现在可以执行以下命令安装：go install github.com/rodrigo-brito/gocity@latest。然后通过 gocity open 打开 Github 或本地仓库。\n- 比如打开本地的 KusionStack/kusion 仓库\n- 然后浏览器打开对应页面\n本地执行一切正常！\nPART. 3\nGo 代码城市一键上云\n作为一个类似数字城市的应用，在云原生、元宇宙等背景下，部署上云也是一个自然的需求。同时我们也希望通过 GoCity 展示下 KusionStack 的基本用法。在 GoCity 上云之前，我们先尝试如何本地执行该应用。\n相应的容器镜像已经推送到 Docker Hubhttps://hub.docker.com/r/yuanhao1223/gocity，运行命令如下：\n运行成功后，可打开本地地址http://localhost:4000/查看 Go 项目的数字城市 3D 效果。\n容器化成功后，现在准备上云。从本地执行容器的方式可以看出，想要在 Kubernetes 部署，至少需要 Deployment 和 Service 两种资源。其中 Deployment 用来部署 Go 代码城市，Service 暴露端口，访问无状态应用。\n首先参考安装文档https://kusionstack.io/docs/user_docs/getting-started/install/安装好本地 Kusion 命令，然后通过 kusion init 的在线仓库提供了相应的模板。Kusion 命令支持一键初始化配置：\n输出类似以下信息：\n为了方便展示，Kusion 模板已经内置了 CodeCity 的例子。其中 code-city 模板依赖 konfig 大库中抽象化的前/后端模型，code-city 模板无依赖，可以自闭环。我们选择后者：\n初始化过程中，指定了容器镜像，并且容器端口和 Service 端口均为 4000，现在进入配置目录，目录结构如下：\n- 完整的代码可以参考 ：\nhttps://github.com/KusionStack/kusion-templates/tree/main/code-city-demo\n为了方便本地测试，可以通过 minikube start 本地启动 MiniKube 服务。然后命令行模式切换到 code-city-kcl 目录，然后执行 kusion apply 命令生效配置。到此，开始正式上云： kusion apply main.k\n输出类似于：\n检查 Deployment 的状态：\n输出类似于：\n使用 kubectl 端口转发：\n访问本地地址https://localhost:4000/)，点击 Example 处的链接 “KusionStack/kusion”，可以看到和本地执行一样的效果：\n至此，完成了 Go 代码城市的一键上云。有兴趣的读者，可以基于模型库 Konfig，选择其他模板，探索 KusionStack 支持的其它运维场景，下面我们将探索代码城市内部的原理。\nPART. 4\n认识数字城市中的建筑含义\n说实话代码城市第一眼看上去更像一个电路板，要理解其中的含义需要了解几个基本的参数映射关系，如预览页面的右下角图所示：\n以上的对应关系在其官方文档中也说明，如下图所示：\n其中地面的粉红色表示 Go 包对应的目录（_因为包的依赖关系可能再产生叠加_），灰色表示目录内部的文件，而蓝色表示结构体。其中表示文件的灰色建筑物的大小即文件的大小，表示结构体的蓝色建筑物的高度即方法的数量，建筑物的长宽表示结构体中属性的数量，蓝色颜色的深度表示相关代码行数。\n我们可以选择 DiffOptions 结构体对应建筑物查看其相关的属性参数：\n可以看到该结构体中有 15 个属性、3 个方法、共 156 行代码。通过点击其中的 “Github 链接” 按钮可以跳转到对应的位置：\n因此通过这种方式我们可以很容易查看全局有无特别高大的建筑，从而判断是否存在某些文件和结构体的代码需要改进。可以说 GoCity 是一个很有趣的代码分析工具，甚至可以集成到 Github PR 代码评审流程中。\nPART. 5\n分析 GoCity 的代码架构\nGoCity 代码架构主要分为代码数据提取和前端模型展示两块，如图所示：\n首先 Codebase 表示要展示的代码，通过 Git Service 被拉取，然后通过 Parser 和 Position 服务提取得到对应的参数信息，然后通过前端展示。Go 语言代码主要集中在模型数据提取部分，而前端展示主要为 JS 等实现。前端展示资源文件通过 embed.FS 内嵌到程序中，GoCity 命令启动 Web 服务展示页面。代码架构比较清晰，也是一个比较理想可用于 Go 语言学习的开源项目。\nPART. 6\n展望\n我们通过 KusionStack 的方式，配合少量的 KCL 配置代码，完成了 Go 代码城市一键上云的操作。虽然云上的 Go 代码城市和本地的版本看不出什么区别，但是云上程序的整个生命周期管理将大为不同。在后面的例子中我们将展示如何通过 KusionStack 结合 KCL 配置语言进行 IaC 方式的云原生应用的运维操作。感谢关注🙏\n参考链接\n● …","date":1661842800,"description":"Go 代码城市上云——KusionStack 实践","dir":"blog/go-code-city-cloud-kusionstack-practice/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"577810f0ec8cee7a80e6717647a67bbe","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","publishdate":"2022-08-30T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","summary":"导语 KusionStack 是面向 Kubernetes 云原生场景的 IaC 配置代码化实践的开源一站式可编程协议栈。其基本思想是让「应用方+平台方」的同学能够共同基于 IaC 构建的 Konfig 模型库同一平","tags":["SOFAStack"],"title":"Go 代码城市上云——KusionStack 实践","type":"blog","url":"/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","wordcount":2203},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. 孙春明 提问：\n 请问这个 mosnd 是做什么的？我如果想重新做 mosnio/proxyv2:v1.0.0-1.10.6 镜像，需要怎么处理呢？\n A：这个 mosnd 只是 mosn 的拷贝，可以看下这个文档：https://mosn.io/docs/user-guide/start/istio/#mosn-%E4%B8%8E-istio-%E7%9A%84-proxyv2-%E9%95%9C%E5%83%8F-build-%E6%96%B9%E6%B3%95\n「MOSN」：https://github.com/mosn/mosn\n2. 胡 提问：\n 请问这边有现成用 SOFAStack 搭建的框架包吗，内容涉及 SOFABoot、SOFARegistry、SOFARPC 的？\n A：现成的框架包的话，你可以从 SOFABoot 开始，参考这个：https://www.sofastack.tech/projects/sofa-boot/quick-start/\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n「SOFARegistry」： https://github.com/sofastack/sofa-registry\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nMOSN v1.1.0 版本发布\n发布 MOSN v1.1.0 版本，主要变更如下：\n 支持反向建连，云边互联场景，细节可以参考博客： https://mosn.io/blog/posts/mosn-tunnel/\n 支持自定义 xDS 解析扩展\n trace 支持 zipkin 扩展\n 优化创建 subset 负载均衡的算法，降低内存占用\n 详细发布报告：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md\n本周推荐阅读\nMOSN 构建 Subset 优化思路分享\nMOSN 1.0 发布，开启新架构演进\nMOSN 社区性能分析利器——Holmes 原理浅析\nMOSN 反向通道详解\n欢迎扫码关注\n","date":1661497200,"description":"SOFA Weekly | MOSN v1.1.0 版本发布、C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220826/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"60009aeca74279e2fb1f880466fa50dd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220826/","publishdate":"2022-08-26T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220826/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.1.0 版本发布、C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220826/","wordcount":951},{"author":null,"categories":"SOFAStack","content":"文｜史贵明（花名：莫城)\n蚂蚁集团技术专家\n蚂蚁集团多云配置管理系统技术负责人\n云原生基础设施领域，容器服务、配置管理、IaC、PaC、GitOps 等方向\n本文 2369 字 阅读 7 分钟\n背景\n要讲 Kusion 在蚂蚁集团的实践，我们首先来了解下蚂蚁集团在此之前的配置管理状况。\n如上图所示，图中展示的是在结合 Kusion 之前的应用基线配置管理系统。这里提到的 “应用基线配置” 非应用动态开关，而是注入应用依赖的软件版本、中间件配置、网络数据库等基础设施配置。\n从上图可以看到，应用基线管理系统是标准 BS 架构，对用户提供 Console 和 API，历经 6、7 年发展历史，承担起蚂蚁集团历史上绝大多数应用基线配置需求，功能丰富且拥有极其复杂的配置计算能力。目前已经支撑了 15000+ 应用、近 400 项应用配置、50+ 全局配置。\n在这个架构下，最上层用户通过表单或者集成系统 API 来与系统交互，以 RDBMS 为存储介质，将应用的配置以类 Key-Value 形式存储。能力层主要包含通用的角色管理、认证鉴权、版本与配置审计等通用能力，还提供模板化的方式来计算应用配置，如将 Deployment 模板化，最终将用户的基线配置渲染为 Deployment，同时模板与基线配置都存在非常复杂而又灵活的继承能力，举个例子，可以给应用配置 Zone_（逻辑机房）_级别的基线，也可以配置环境级别的基线，或者应用级别的基线，前者可以继承后者，就像子类和父类的集成关系。\n除了应用本身的基线配置，同时也管理了全局配置，如全局的 DNS 配置、Load Balance、网路配置等等。这个架构非常经典，并且有效支持了历史上各种配置需求及各种 618、双 11 等场景，这些都是毋庸置疑的。但是随着蚂蚁集团云原生化进程的推进，上面的经典架构也逐渐出现一些瓶颈。 不知道大家对于这种架构的配置管理，或者架构有没有遇到这样的问题？我来举几个例子：\n● 灵活性： 业务越来越多，应用的基础设施配置也更加的灵活，各种定制化需求越来越多，原有架构主要解决标准应用的场景和通用场景；\n● 开放性： 基线系统的核心能力主要代码在 PaaS 同学这边负责，对于多种多样的需求需要内部排期支持，开放性不足，无法复用和沉淀强大的 SRE 团队的经验；\n● 透明性： 配置计算黑盒，很多配置的计算逻辑都 hardcoding 在代码中，一个配置的变更最终会影响什么、影响有多大无法确定。比如修改了全局 sidecar 版本，导致线上应用批量异常。\n业界对标\n带着上面这些问题，我们在业界做了一些对标和学习:\n1.在 Google的《The Site Reliability Workbook》这本书中，Google 同学从自身的实践中总结出一些常见问题，其中非常重要的一点是：在做配置管理过程中，没有意识到，大规模配置管理问题的本质是编程语言问题。配置需求的声明、校验都可以通过语言来解决。\n2.从 Google 自身的实践来讲，K8s 是基于 Google 多年大规模集群管理经验贡献的开源产品，但是其内部主要使用的是 Borg，Borg 团队是在 Borg master 之上研发的，Borg 接入的三件套分别是：\n● BCL： 用户通过编写 BCL 代码实现对基础设施需要的配置；\n● Borgcfg： 通过 Borgcfg 将配置执行到 Borg 集群；\n● Webconsole： 通过 Webconsole 查看发布情况。\n经过调研，我们了解到 Google 大量的运维能力、产品、质量生态都是基于上述三件套演进多年。\n基于上述的一些总结，我们推演出类 Borg 的思路来解决蚂蚁集团的基础设施配置管理，我们尝试用语言和工具及服务实现蚂蚁集团下一代配置管理架构。\n下一代配置管理架构\n在这个新的架构下，我们可以看到整体架构不仅仅是一个简单的 BS 架构，配置的用户界面也从浏览器 Form 表单演进为中央开放配置大库。而配置大库所使用的就是 Kusion，Kusion 的用户使用前面的同学已经讲过了，对于配置大库本身的技术细节我不做过多的展开，这里强调的是大库在设计上支持多站点交付的架构。\n新配置管理架构主要分为以下几个特点：\n● 基于配置代码化理念抽象建设统一的应用配置模型，沉淀可重用模型组件，实现配置代码一次编写多站点可迁移。抽象领域模型：Stack 是配置的最小集合，Project 是一组 Stack 的抽象，不仅囊括 App 的应用基线配置, 也支持其他如 DataBase 配置、负载均衡配置，甚至 Network Policy 等非应用配置。\n● 通过策略控制器机制，创建与组织独特的安全性，合规性和治理要求相对应的防护规则。\n● 声明式自动化，持续监控运行状态并确保符合 Git 中定义的期望状态。\n应用发布案例\n接下来结合一个具体产品案例做阐述，在这个案例中以应用迭代发布为例：\n1.用户在业务迭代中，修改业务代码、提交代码、CI 测试、构建镜像，并将构建的镜像推送到远程镜像中心。然后通过配置管理服务层——这里是 auto-image-updater 组件——自动将配置更新到配置大库对应的配置文件中。\n2.触发大库的变更扫描、测试、审核等一些列的质保手段，同时触发一次应用发布流程，应用发布流程是具有风险体系的、可视化的发布流程，包括推进流程要从预发、仿真、灰度逐步推进，最后进入生产环境。\n在每个推进阶段，需要从配置大库获取到配置代码并同时使用配置管理服务层获取 KCL 的编译结果，也就是 Spec 模型，然后通过产品化方式将 Spec 与生产环境中真实的 Runtime 进行“Live Diff”以供参与人更好地识别变更内容和变更范围，然后以分组发布等具有风险防控的手段变更到对应环境，如 apply 到 K8s 集群。\n3.我们看下过程中的具体可视化产品，可以看到发布进度、应用配置的 Diff，以及可以看到历史版本的配置。\n问题与展望\n回顾下我们开始提到的几个问题：\n1. 灵活性： 即对各种灵活定制化需求的支持;\n2. 开放性： 通过 KCL 语言及开放配置大库，用户的基础设施配置通过新的用户界面即可自主完成，不需要等待配置管理平台开发人员进行开发；\n3. 透明性： 变更过程可以通过产品化的“Live Diff”来识别变更风险；\n我们通过上述的一些探索，一定程度上解决了蚂蚁集团在推进云原生进程中的问题，过程中也遇到了方方面面的困难，比如如何从老架构切换到新架构？架构代际演进时新老系统并存问题是必须要解决的，可以通过如双写等方式解决。在新架构下更值得探讨的有如下问题，全局配置如何管理以及如何更好的扩展配置的维度。\n站点的全局配置，在老的基线配置的全局配置不仅仅是简单的 Key-Value， 在使用上是非常复杂的，比如 DNSConfig 配置，按照租户、环境、Zone 等做了不同的优先级编排，对于这些的描述比较复杂，使用 KCL 描述如此复杂的配置很困难。\n针对于配置的继承和扩展，以 APP 基线配置为例，目前更多的是支持应用和应用环境级别的配置，针对 Zone 等细粒度的配置需要在 KCL 代码中通过写 if else 来实现，这对 …","date":1661238000,"description":"KusionStack 在蚂蚁集团的探索实践 (上)","dir":"blog/kusionstack-in-practice-at-ant-group-first/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8bfaea9639af72bb640f142108de2d90","permalink":"https://sofastack.github.io/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","publishdate":"2022-08-23T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","summary":"文｜史贵明（花名：莫城) 蚂蚁集团技术专家 蚂蚁集团多云配置管理系统技术负责人 云原生基础设施领域，容器服务、配置管理、IaC、PaC、GitOp","tags":["SOFAStack"],"title":"KusionStack 在蚂蚁集团的探索实践 (上)","type":"blog","url":"/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","wordcount":2774},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 卿同学 提问：\n 想咨询一下，目前蚂蚁内部使用 MOSN 外有使用到 Envoy 吗？\n A：目前蚂蚁的东西向网关是 MOSN on Envoy 的，Layotto on Envoy 也在试点中，所以没有直接使用 Envoy，不过很多场景是跑在 Envoy 上的。\n 那在 RPC、MQ、DB 流量这块都走 MOSN 流量拦截的方式吗？还是基于 Layotto API 的方式呢？\n A：目前主要是 MOSN，多语言和多云场景在走 Layotto 的方式。\n 我看 Layotto 也在推动和 Envoy 的融合，这一块现在有进展吗？\n A：今年我们首先会开源 Envoy 的 cgo 插件，然后基于这个插件，可以把 Layotto 跑在 Envoy 上。\n「MOSN」：https://github.com/mosn/mosn\n「Layotto」：https://github.com/mosn/layotto\n2. 古寒 提问：\n 咨询下， MOSN 部署有指导文档嘛？\n A：有的，看下这个文档，https://mosn.io/docs/user-guide/start/proxy/\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 社区文章｜MOSN 构建 Subset 优化思路分享\n如何看待 Dapr、Layotto 这种多运行时架构\nMOSN 文档使用指南\nMOSN 社区性能分析利器——Holmes 原理浅析\n欢迎扫码关注：\n","date":1660892400,"description":"SOFA Weekly | C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220819/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"187a873747e511ae312c36058eb71f8c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220819/","publishdate":"2022-08-19T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220819/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220819/","wordcount":758},{"author":null,"categories":"SOFAStack","content":" 文｜\n赵新（花名：于雨)：蚂蚁集团 Seata 项目开源负责人、开放原子开源基金会代码贡献之星\n郭成（花名：星北)：Seata-php 项目共同发起人、蚂蚁集团技术专家\n刘岳健：Seata-php 项目共同发起人、Hyperf 开发组成员、广东快客电子商务有限公司高级后端工程师\n本文 5894 字 阅读 12 分钟\n导语 通俗地讲，seata-php 是 Seata 的 PHP 语言实现，它实现了 Java 和 PHP 之间的互通，让 PHPer 也能使用 seata-php 来实现分布式事务。\nSeata 是一个非常成熟的分布式事务框架，在 Java 领域是事实上的分布式事务技术标准平台。Seata 目前正在构建其多语言体系[1]，整个体系包含了目前常用的五大类语言：Java、Go、Python、JS 和 PHP。目前的态势是后四种语言都依据 Seata Java 版本构建起对应语言的实现。\n除了追求 Seata 多语言体系过程中因为开源价值要求构建 Seata 的 PHP 版本这个原因外，作为构建起 Web 1.0 时代技术基础 LAMP 架构中的要角，PHP 语言在电商和金融交易场景下依然被广泛使用。而这些场景对数据一致性要求非常强烈，这是构建 seata-php 最大的诱因，也是其技术价值所在。\nPART. 1\u0026amp;ndash;Seata 架构与多语言体系 图片来自 Seata 官网\n Seata 总体架构由如下角色构成：\n- 事务协调器 Transaction Coordinator\n简称 TC，维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n- 事务管理器 Transaction Manager\n简称 TM，定义全局事务的范围，提交或者回滚全局事务。\n- 资源管理器 Resource Manager\n简称 RM，和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\n从 C/S 通信架构角度来看，TC 是服务端，TM 和 RM 是客户端。TC 与 TM 以及各个 RM 之间使用 Netty 框架进行长链接通信。具体而言，Seata Java 版本的通信协议是在四层 TCP 协议之上又定义了一套私有的二进制双向通信协议，通信框架使用了 Netty。其他四种语言只要依据 Seata 的通信协议标准实现其通信功能，即可在多语言生态体系内任何语言之间进行通信和服务调用。\n三个角色中，TM 和 RM 以 SDK API 形式供上层 APP 调用，而 TC 是独立进程部署，使用任何语言实现都可以。据说懒惰是程序员的第一美德，在 Seata Java 已经实现了 Java 版本的 TC 的情况下，多语言体系内其他语言就没必要再做重复工作，只需要构建其对应语言的 TM 和 RM 的 SDK API 包，与 Seata Java TC 通信即可。\nPART. 2\u0026amp;ndash;Seata 与 PHP 技术 分布式事务技术是微服务技术体系的一环，构建 Seata PHP 首先需要选择其微服务技术平台，seata-php 目前使用的微服务框架是 Hyperf。\nPHP 在业界以入门门槛低著称，目前常用的微服务框架有 Laravel 以及在其上构建的 Lumen。Laravel 框架的最大优点就是其生态丰富，各种组件应有尽有，如果 Laravel 可以和 Spring 框架类比，Lumen 就是 Spring Boot。但其缺点是性能堪忧，例如在普通的 8C 机器上，空跑一个只运行 echo 逻辑的 HTTP 服务，其吞吐量仅有 1K QPS。\nHyperf 框架是近年内出现的由国人基于 Swoole 开发的一个微服务框架，特点如下：\n1. 类似于 Nginx，Hyperf 以多进程形式常驻内存，每个进程内都有一个弹性线程池。正常情况下 Hyperf 收到调用请求后，可以保证 1ms 之内分配服务线程，而 Lumen 的响应时间常在 10ms 左右；\n2. 因为 Hyperf 服务常驻内存的特点，其稳定性好，资源利用率当然比以 CGI 机制运行的 Lumen 低很多；\n3. Hyperf 的对请求的处理过程借鉴了 Go 语言机制，其 runtime 层面以异步方式执行上层的用户同步调用，相比 Lumen 其吞吐率高而延迟低。例如在同样环境下使用 Hyperf 实现同样的 echo HTTP 服务，可以轻松达到 60K QPS；\n除了 Hyperf 自身稳定性与高性能外，依赖于 Hyperf 服务进程常驻内存的特点，TC 可以很方便的对seata-php 的 RM 发起二阶段事务处理，即作为 Server 的 Java TC 对作为 Client 的 PHP 版本的 RM 发起 RPC 回调。如果使用 Lumen 作为 seata-php 的微服务框架，几乎不可能实现这个技术点。\nPART. 3\u0026amp;ndash;快速入门 seata-php 基于 Hyperf 微服务框架，seata-php 已经实现了 AT 事务模式，并给出了测试用例。本章节的目的是基于现有实现，让对 seata-php 这个项目感兴趣的同学能够快速入门 seata-php。\n3.1\u0026amp;ndash;搭建 PHP 开发环境 使用 Hyperf/Box 这个工具能够快速创建开发环境，并且能够与其他自建开发工具链隔离，避免污染日常的开发环境。\n3.1.1 下载 Hyperf/Box # Mac wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_x86_64_macos -O box # Linux x86_64 wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_x86_64_linux -O box # Linux aarch64 wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_aarch64_linux -O box sudo mv ./box /usr/local/bin/box sudo chmod +x /usr/local/bin/box # 在 https://github.com/settings/tokens/new 创建 token 后，配置到 box 中 box config set github.access-token \u0026amp;lt;Your Token\u0026amp;gt; 注意：\n- 如果你是 Mac 用户首次使用的话，需要在“系统偏好设置”\u0026amp;ndash;\u0026amp;gt;“安全性与隐私”中给 Box 工具进行授权；\n- 已经测试过，X86 的 Box，可以在 M1 版本的 Mac 上使用；\n- 使用 Box 时，创建 GitHub access token 权限需要 repo、workflow。\n3.1.2 配置 PHP 环境 当 Box 下载好后，继续下载 PHP 8.0 版本\n# 下载 php8.0 box get …","date":1660633200,"description":"让 PHPer 也能使用 seata-php 来实现分布式事务","dir":"blog/seata-php-semi-annual-planning/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ee9381666d88165cad305e1b3880d181","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-php-semi-annual-planning/","publishdate":"2022-08-16T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/seata-php-semi-annual-planning/","summary":"文｜ 赵新（花名：于雨)：蚂蚁集团 Seata 项目开源负责人、开放原子开源基金会代码贡献之星 郭成（花名：星北)：Seata-php 项目共同发起人、蚂蚁集","tags":["SOFAStack"],"title":"Seata-php 半年规划","type":"blog","url":"/sofastack.tech/blog/seata-php-semi-annual-planning/","wordcount":4330},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup 合肥站-云原生技术沙龙\n 活动时间：2022 年 08 月 13 日（周六）13:30-17:00\n 活动地点：合肥市高新区创新创业园 D8 栋一楼集思空间\n 活动形式：线下活动\n 资料下载：\n《SOFA Serverless 体系助力业务极速研发》\n《KusionStack 在蚂蚁规模化运维的探索和总结》\n 本次分享涉及的项目地址：\n【SOFAArk】https://github.com/sofastack/sofa-ark\n【KusionStack】https://github.com/kusionstack/kusion\n 活动介绍 活动议程 直播回放 SOFA Serverless 体系助力业务极速研发\nKusionStack 在蚂蚁规模化运维的探索和总结\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1660374000,"description":"SOFA Meetup 合肥站-云原生技术沙龙","dir":"activities/sofa-meetup-17/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"717c5211a439598278a7cbb834d09bb0","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-17/","publishdate":"2022-08-13T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-17/","summary":"概要 活动主题：SOFA Meetup 合肥站-云原生技术沙龙 活动时间：2022 年 08 月 13 日（周六）13:30-17:00 活动地点：合肥市高新区创新创业园 D8 栋","tags":["SOFAMeetup"],"title":"SOFA Meetup 合肥站-云原生技术沙龙","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-17/","wordcount":346},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 信广健 提问：\n 经过十分曲折的故事了解到了 Layotto ， 进群后想看看后续发展，有什么好的文档可以学习下吗？\n A：目前还在活跃开发中，可以看下 https://github.com/mosn/layotto 了解下，相关的文档也在 https://mosn.io/layotto/\n「Layotto」：https://github.com/mosn/layotto\n2. 清源 提问：\n 现在 MOSN 除了适配 XDS 做到动态规则下发之外？有没有其他的动态规则下发办法？\n A：你可以自己实现的，XDS 也是调用 MOSN 的更新 API。\n「MOSN」：https://github.com/mosn/mosn\n3. 樊志超 提问：\n 问一下，MOSN 与业务容器间的信息交互是采用 socket 方式吗？\n A：这个看你怎么用了，自己选择。\n 默认的是哪种方式呢？\n A：TCP、UDS 都可以。\n「MOSN」：https://github.com/mosn/mosn\nSOFARPC 5.8.6 版本发布 SOFARPC 5.8.6 是一个功能优化、Bug 修复版本，建议使用 5.7.10 ~ 5.8.5 版本的用户都升级到 5.8.6。\n主要变更如下：\n- 功能优化：\n1.支持用户自定义 tracer 中 callerAppName\n2.添加 DomainRegistry 订阅域名数据, 支持 direct url 功能\n- BUG 修复：\n1.修复了 Triple 协议在多 classLoader 环境下的序列化问题\n详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.8.6\n本周推荐阅读 蚂蚁开源：开放自研核心基础软件技术，携手探索技术高地\n\nGo 原生插件使用问题全解析\n\nMOSN 反向通道详解\n\n如何看待 Dapr、Layotto 这种多运行时架构\n\n欢迎扫码关注：\n","date":1660287600,"description":"SOFA Weekly | SOFARPC 5.8.6 版本发布、Meetup 合肥站、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220812/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"06f5bddaf802462077c913d20d2f9d15","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220812/","publishdate":"2022-08-12T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220812/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 5.8.6 版本发布、Meetup 合肥站、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220812/","wordcount":861},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup 广州站-云原生技术交流\n 活动时间：2022 年 08 月 06 日（周六）14:00-18:00\n 活动地点：广州市海珠区阅江西路 88 号阿里中心北塔 4F 万松书院\n 活动形式：线下活动\n 资料下载：\n《基于 P2P 的文件和镜像加速系统 Dragonfly》\n《Buildpacks \u0026amp;amp; Argo CD GitOps》\n《KusionStack 实践探秘｜技术、角色与应用场景篇》\n《KubeSphere 在青花瓷的落地实践与展望》\n《Holmes｜Go 应用性能异常诊断定位利器》\n《云原生应用灾备最佳实践》\n 本次分享涉及的项目地址：\n【Dragonfly】https://github.com/dragonflyoss\n【KusionStack】https://github.com/kusionstack/kusion\n【MOSN】https://github.com/mosn/mosn\n 活动介绍 活动议程 直播回放 Dragonfly：基于 P2P 的文件和镜像加速系统\nKusionStack 实践探秘｜技术、角色与应用场景篇\nHolmes｜Go 应用性能异常诊断定位利器\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1659769200,"description":"SOFA Meetup 广州站-云原生技术交流","dir":"activities/sofa-meetup-16/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cc936d9167acee9569070c076ab0da31","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-16/","publishdate":"2022-08-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-meetup-16/","summary":"概要 活动主题：SOFA Meetup 广州站-云原生技术交流 活动时间：2022 年 08 月 06 日（周六）14:00-18:00 活动地点：广州市海珠区阅江西路 88 号阿","tags":["SOFAMeetup"],"title":"SOFA Meetup 广州站-云原生技术交流","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-16/","wordcount":504},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 吴宇奇 提问：\n 请问下，Bolt 协议里面的这个 cmdCode，除了心跳、request、response，还有别的用法吗？ A：举个例子，新增 goaway 扩展。https://github.com/sofastack/sofa-bolt/issues/278\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\n2. bobtthp 提问：\n 大佬们问下动态路由这块，有 example 可以看看嘛？ A：这篇文章就是例子哟，https://mosn.io/blog/posts/how-use-dynamic-metadata/#%E5%8A%A8%E6%80%81%E8%B7%AF%E7%94%B1-cluster ，原理就是 route 的配置是变量，然后 streamfilter 根据业务逻辑修改这个变量的值，很方便试试。\n 好的，这个我有一个疑问。这个变量如何注入进去呢？我理解应该每一个节点的变量都不一样嘛？还有一个疑问是，如果需要和配置中心交互这块是怎么做的，可以借鉴一下吗？\n A：变量就是 streamfilter 模块分配的，然后他来设置这个变量的值，值就是 cluster 的名字；后面那个问题指的是 cluster host 的更新吗？\n 指的是如果需要外部的配置中心那可能需要监听配置的动态变化；第一个这块我好像没理解好，我举个例子：如果是多个应用，那是不是我要设置多个变量？\n A：比如你 A 应用的 cluster 名字是 A，B 应用的 cluster 名字是 B， 那么这个变量只需要一个，只是 value 你可以根据逻辑设置为 A 或者 B。\n这个就是一些复杂的路由场景，用配置不能表达，就可以用代码的方式来做这个事。我们内部的一些复杂路由场景也是这样做的。\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 云原生 Meetup 广州站，等你来！\n\nGo 原生插件使用问题全解析\n\nMOSN 反向通道详解\n\nKusionStack｜Kusion 模型库和工具链的探索实践\n\n欢迎扫码关注公众号：\n","date":1659682800,"description":"SOFA Weekly | Meetup 广州站参会指南、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220805/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"51544dab85fa7fe78001737602f2536b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220805/","publishdate":"2022-08-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220805/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Meetup 广州站参会指南、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220805/","wordcount":1038},{"author":null,"categories":"SOFAStack","content":" 文｜郑泽超（GitHub ID：CodingSinger )\n字节跳动高级工程师\n热衷于微服务和 ServiceMesh 开源社区\n本文 6802 字，阅读 15 分钟\nPart.1\u0026amp;ndash;贡献者前言 说起来非常的抓马，当时和 MOSN 的相遇是在给于雨负责的开源项目 Dubbo-go 贡献代码那阵。在自己顺利当上了 Dubbo 开源社区的 Committer 之后，心想着能更深入的学习 Golang 语言，机缘巧合之下碰到了 MOSN 的老大哥烈元 （也是元总领我进了 MOSN 社区的大门） 。\n作为一款目标对齐 Envoy 的高性能可扩展安全网络代理，MOSN 支持的生态能力更贴近国内互联网公司的技术栈，并且对新功能的响应也很迅速。其次 MOSN 有着很多值得借鉴的巧妙设计和进阶的使用技巧，能充分满足自己在工作之外深入学习 Golang 语言的诉求。\n目前，我在社区里陆续参与了 EDF Scheduler、LAR、WRR 负载均衡、DSL 路由能力、UDS Listener、Plugin 模式的 Filter 扩展以及反向通道等一些比较大的 feature 能力建设。再次感谢雨哥、元总、鹏总、毅松等社区内一众大佬们帮我考究方案并且帮我 Review 代码。\n本文主要介绍之前新合入 master 分支的「反向通道」的使用场景和设计原理，欢迎大家留言探讨。\nMOSN 项目概述 MOSN（Modular Open Smart Network）是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并经过双 11 大促几十万容器的生产级验证，具备高性能、易扩展的特点。MOSN 可以和 Istio 集成构建 Service Mesh，也可以作为独立的四、七层负载均衡、API Gateway、云原生 Ingress 等使用。\nPart.2\u0026amp;ndash;MOSN 的反向通道实现 在云边协同的网络场景，通常都是单向网络，云侧节点无法主动发起连接与边缘节点通讯。这种限制虽然在极大程度上保证了边缘节点的安全，但缺点也很明显，即只允许边缘节点主动发起访问云端节点。\n云边隧道旨在解决云端无法主动访问边缘节点的问题，其本质是一个反向通道 （后文统称为反向通道） 。通过在边缘侧主动发起建连的方式与云端节点之间构建一条专用的全双工连接，用来传输云端节点的请求数据和回传最终的响应结果。\n目前例如 SuperEdge、Yurttunnel 等业界知名云边协同开源框架，对于云边通信的实现方案都是基于反向通道。\n本文将着重介绍 MOSN 之上的反向通道运作流程和原理。总体架构如下所示 (图中箭头表示 TCP 建连反向) ：\n整个运作流程可以简单概括为：\n1. 边缘侧的 MOSN 实例 （后文统称为 Tunnel Agent） 在启动时 Tunnel Agent 相关服务协程。\n2. 通过指定的静态配置或者动态服务发现方式拿到需要反向建连的公有云侧的 MOSN Server 地址列表 （后文统称 Tunnel Server ） ，并且建立反向连接。\n3. 云侧的 Frontend 与 Tunnel Server 侧的转发端口进行数据交互，这部分数据会被托管到之前建立的反向连接进行发送。\n4. 边缘节点接受到请求之后，再将请求转发给实际的后端目标节点，回包过程则远路返回。\nPart.3\u0026amp;ndash;反向通道启动过程 MOSN Agent 通过 ExtendConfig 特性，在 MOSN 启动时加载和完成初始化 Tunnel Agent 的工作。\nExtendConfig 中定义 AgentBootstrapConfig 结构如下：\ntype AgentBootstrapConfig struct { Enable bool `json:\u0026amp;quot;enable\u0026amp;quot;` // The number of connections established between the agent and each server ConnectionNum int `json:\u0026amp;quot;connection_num\u0026amp;quot;` // The cluster of remote server Cluster string `json:\u0026amp;quot;cluster\u0026amp;quot;` // After the connection is established, the data transmission is processed by this listener HostingListener string `json:\u0026amp;quot;hosting_listener\u0026amp;quot;` // Static remote server list StaticServerList []string `json:\u0026amp;quot;server_list\u0026amp;quot;` // DynamicServerListConfig is used to specify dynamic server configuration DynamicServerListConfig struct { DynamicServerLister string `json:\u0026amp;quot;dynamic_server_lister\u0026amp;quot;` } // ConnectRetryTimes ConnectRetryTimes int `json:\u0026amp;quot;connect_retry_times\u0026amp;quot;` // ReconnectBaseDuration ReconnectBaseDurationMs int `json:\u0026amp;quot;reconnect_base_duration_ms\u0026amp;quot;` // ConnectTimeoutDurationMs specifies the timeout for establishing a connection and initializing the agent ConnectTimeoutDurationMs int `json:\u0026amp;quot;connect_timeout_duration_ms\u0026amp;quot;` CredentialPolicy string `json:\u0026amp;quot;credential_policy\u0026amp;quot;` // GracefulCloseMaxWaitDurationMs specifies the maximum waiting time to close conn gracefully GracefulCloseMaxWaitDurationMs int `json:\u0026amp;quot;graceful_close_max_wait_duration_ms\u0026amp;quot;` TLSContext *v2.TLSConfig `json:\u0026amp;quot;tls_context\u0026amp;quot;` } - ConnectionNum：Tunnel Agent 和每个 Tunnel Server 建立的物理连接数量。\n- HostingListener：指定 Agent 建立连接之后托管的 MOSN …","date":1659423600,"description":"本文主要介绍之前新合入 master 分支的「反向通道」的使用场景和设计原理，欢迎大家留言探讨。","dir":"blog/mosn-reverse-channel-explained/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7e5e0314310caad88df4a18ccf8bb436","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-reverse-channel-explained/","publishdate":"2022-08-02T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-reverse-channel-explained/","summary":"文｜郑泽超（GitHub ID：CodingSinger ) 字节跳动高级工程师 热衷于微服务和 ServiceMesh 开源社区 本文 6802 字，阅读 15 分钟 Part.1\u0026ndas","tags":["SOFAStack"],"title":"MOSN 反向通道详解","type":"blog","url":"/sofastack.tech/blog/mosn-reverse-channel-explained/","wordcount":3101},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. bobtthp 提问：\n 请教下 MOSN 转发 HTTP/2 协议，listener filter 和 router match 两个部分要怎么写呀？\n A：就用这个 exmple 就行了。\nhttps://github.com/mosn/mosn/blob/master/configs/mosn_config_dev.json\n「MOSN」：https://github.com/mosn/mosn\n2. 黄大宇 提问：\n Biz 版本更新时，如果不卸载旧版本，安装新版本时会报 webContextPath 冲突异常。比如现在运行 1.0.0，而我要升级到 2.0.0，那么能否先安装 2.0.0，然后再切换，再把 1.0.0 卸载。目前是这一过程出现了 webContextPath 冲突的问题。\n A：有两种解法，一种是让流量走宿主，然后分发给 Biz。另一种是 context path 挂钩版本，调用时带上版本，类似 v1，v2 这样。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n3. 黄润良 提问：\n Cluster Manager 这块配置，如果要实现动态配置，有没有什么最佳实践之类的？MOSN 有开放 API 或者接入配置中心的案例吗？\n A：直接使用 XDS 协议就行了，获取你也可以直接调用 MOSN 的 API，这里有个 ZK 的例子：\nhttps://github.com/mosn/mosn/tree/master/pkg/upstream/servicediscovery/dubbod\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 Go 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\nSOFAServerless 助力业务极速研发\n\nSeata 在蚂蚁国际银行业务落地实践\n\n欢迎扫码关注公众号：\n","date":1659078000,"description":"SOFA Weekly | Meetup 广州站、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220729/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"876d0f78f149dc93f464e53e5474a250","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220729/","publishdate":"2022-07-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220729/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Meetup 广州站、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220729/","wordcount":760},{"author":null,"categories":"SOFAStack","content":" 文｜杨洋（花名：凯申 )\n铜锁开源密码库创始人、蚂蚁集团高级技术专家\n本文 2816 字，阅读 8 分钟\n再见 BabaSSL ，你好 Tongsuo!\n BabaSSL 这个名字由于其历史上的若干特殊原因，导致了其看起来是主要 SSL/TLS 协议的密码学产品，这其实并不符合整个产品的功能特性，名字本身也不够中立，这会让用户产生一定程度的误解。\n目前 BabaSSL 在积极推进向开放原子开源基金会的捐赠行动，并结合社区未来发展的方向，现决定对 BabaSSL 项目进行更名。新名字需要更加中立化，而且需要体现项目的功能特性。基于这些考虑，计划取新名字为：铜锁，对应拉丁字母名称为铜锁的汉语拼音“Tongsuo”。铜锁是在中华文明 5000 年历史的进程中得到了广泛应用的安全设施，且小巧、设计精妙，极具中国传统特色，符合密码库的产品特色和发展目标。\n 一、BabaSSL 从何而来，为何而改？ BabaSSL 于 2019 年诞生在蚂蚁和阿里集团内部，是基于 OpenSSL 1.1.1 版本 fork 而来的一个变种版本。创建 BabaSSL 项目的动机是在蚂蚁和阿里内部得到一个统一的 OpenSSL 变种版本，以便使用此统一版本来支撑蚂蚁和阿里内部的各种业务。这样可以减小各个业务方维护 OpenSSL 的成本，实现密码学能力的统一管理和维护，进而降低潜在的安全风险。\n针对蚂蚁和阿里内部的业务特点，BabaSSL 需要采用和 OpenSSL 完全不同的发展路线。简单来说，BabaSSL 需要覆盖的场景非常的多样化，包括移动端、服务器端、资源受限的嵌入式环境等。而且在算法和密码学特性的支持上，蚂蚁和阿里的业务对前沿的技术存在较大需求，因此要求 BabaSSL 需要采用相对激进的演进策略，但还要确保很高的质量标准以应对蚂蚁和阿里的业务规模。所以我们当年使用 Brisk and Better Assured Cryptography and SSL/TLS toolkit 来命名这个密码学基础库，并缩写为 BabaSSL。\n随着 BabaSSL 项目的发展，我们发现除了蚂蚁和阿里内部的业务对其有着重大的依赖之外，业界也对国密合规和前沿密码学技术存在较大需求。因此在 2020 年 10 月份，我们将 BabaSSL 进行了开源，并维持 BabaSSL 名称不变。随着 BabaSSL 开源社区的发展、用户数量的增多，我们逐渐发现 BabaSSL 这个名称已经无法继续肩负整个社区更大的目标和使命，因此取一个新名字就十分必要。\n二、我的新名字——\u0026amp;rdquo;铜锁/Tongsuo\u0026amp;rdquo; 经过与开源社区小伙伴们共同探讨，并与开放原子开源基金会沟通后，我们最终选定了 “铜锁/Tongsuo” 作为 BabaSSL 开源项目的新名字，其含义如下：\n1. 铜锁的设计形象和密码学的锁形象异曲同工，都是保障安全的技术\n2. 铜锁的历史悠久，应用十分广泛\n3. 铜锁诞生于中国汉代，流行至明清，极具中国特色，代表了中国的传统文化\n4. 铜锁设计精妙、体积小巧，安全性高\n铜锁的这些特点，符合 BabaSSL 的项目定位和发展目标：适应场景最广、性能最好、可靠性最高且监管合规的开源密码学基础库。正如铜锁是中国 5000 年历史长河中为人民生命财产提供保证的最基础元素，“铜锁密码库”作为信息安全领域基础组件、中国网络空间安全和数据安全的核心基础元素，也希望能为中国人民的信息和财产安全贡献力量。\n铜锁的拉丁字母名称则直接采用铜锁的汉语拼音：Tongsuo，除此之外不再赋予其他含义解释，目的是集中体现中国的品牌名称和文化价值。\n三、更名后的一系列操作 我们近期会针对 BabaSSL 开源项目进行如下的更名举措，其中部分举措可能会对用户造成影响，需额外注意：\n「代码库名称变更」\n1. 在 Github 上创建新的 Tongsuo 组织，并将 BabaSSL 代码仓库更名为 Tongsuo 后迁移其下；\n2. BabaSSL 代码仓库的转地址会在 Github 上自动跳转到新的 Tongsuo 仓库地址，方便已有用户访问；\n3. 新的 Tongsuo 代码仓库的 master 分支变更为基于 OpenSSL 3.0 代码基础，并整体迁移为 Apache License 2.0 开源许可证。由此进行相关分支变更如下：\na. 现有的 master 分支更名为 master-babassl，并设置为只读模式，即不再接受新的代码合并，只留做参考用；\nb. 将 master-tongsuo 分支更名为 master，作为下个大版本 tongsuo-8.4.0 的开发分支。由于新的 master 分支和旧的 master 分支之间没有代码提交的逻辑关系，因此需要用户手动重新检出新的master 分支并覆盖本地的旧 master 分支内容。在此过程中如果你的本地 master 分支存在代码修改，请注意保存以免代码修改丢失。\n「网站改名」\n1. 启动 tongsuo.net 网站，并更新网站内容/品牌；\n2. 将对 babassl.cn 网站的访问重定向到 tongsuo.net；\n3. 新增 tongsuo.readthedocs.org 网站，作为铜锁项目的文档库。\n「Release 改名和版本策略」\n1. 在 8.3.x 版本中将沿用 BabaSSL 名称，即 BabaSSL 8.3.1 等后续版本；\n2. 从 8.4.0 开始更名为 Tongsuo。Tongsuo 延续 BabaSSL 的版本编号，不再重新定义编号。主要是考虑软件版本的升级和比较的前后兼容性问题。新的 release 包名称为：tongsuo-a.b.c.tar.gz 或 tongsuo-a.b.c.zip。\n「代码 API 命名修改」\n需要考虑兼容问题，因此 BABASSL_ 开头的 API 还需持续保留，直到 9.0 大版本发布。\n四、期待与你共“铜”成长 经过这一年的努力，铜锁/Tongsuo 开源密码库项目通过了开放原子开源基金会的 TOC 答辩。接下来我们的重心是继续推进铜锁 8.4.0 版本的研发工作，该版本会在半同态加密算法等前沿密码学领域进行相关特性的大力支持，为铜锁的用户带来隐私计算领域的底层密码学原语能力。\n希望能有更多朋友参与进来，与我们共同去完善铜锁/Tongsuo，不论你所处哪一个研究领域，我们都非常期待和欢迎你的加入。此外，我们于近期建立了铜锁 （BabaSSL） 的开源项目钉钉群，方便铜锁密码库的用户们进行沟通交流，期待着能有更多的社区朋友在铜锁 （BabaSSL） 共同成长！\n钉钉用户交流群群号：44810299\n 铜锁（BabaSSL）的更名涉及到较多的现有资产名称变更事宜，例如代码库改名、文档内容名称替换等。具体的相关进展和状态，我们会及时在上述钉钉群中向大家通告。\n 了解更多…\n铜锁/Tongsuo Star 一下✨： https://github.com/BabaSSL/BabaSSL\n本周推荐阅读 BabaSSL：支持半同态加密算法 EC-ElGamal\n\nBabaSSL 发布 8.3.0｜ …","date":1659078000,"description":"再见 BabaSSL ，你好 Tongsuo!","dir":"blog/my-new-name-is-tongsuo/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b06ddb637930e9c54104c4e1f05501d7","permalink":"https://sofastack.github.io/sofastack.tech/blog/my-new-name-is-tongsuo/","publishdate":"2022-07-29T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/my-new-name-is-tongsuo/","summary":"文｜杨洋（花名：凯申 ) 铜锁开源密码库创始人、蚂蚁集团高级技术专家 本文 2816 字，阅读 8 分钟 再见 BabaSSL ，你好 Tongsuo! BabaSSL 这个名字由于其历史上的若干特殊原因，导致","tags":["SOFAStack"],"title":"你好，我的新名字叫“铜锁/Tongsuo”","type":"blog","url":"/sofastack.tech/blog/my-new-name-is-tongsuo/","wordcount":2336},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#29:基于 P2P 的文件和镜像加速系统 Dragonfly\n 活动时间：07 月 28 日，周四晚 19 点\n 活动形式：线上直播\n 直播回放：点击观看\n 资料下载：戳这里\n 推荐阅读：Dragonfly\u0026amp;ndash;基于 P2P 的文件和镜像分发系统\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”等多种形式期待你的参与！\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#29 基于 P2P 的文件和镜像加速系统 Dragonfly Dragonfly 是一款基于 P2P 的智能镜像和文件分发工具。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在应用分发、缓存分发、日志分发和镜像分发等领域被大规模使用。自 17 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 18 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为孵化级别的托管项目。分享主要介绍 Dragonfly 项目，并与大家共同分享开发过程中的设计思想以及最佳实践。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 戚文博（花名：百蓦）\n Dragonfly Maintainer\n 基于 P2P 的文件以及镜像加速系统, 负责 Scheduler 以及 Manager 子模块\n 马金晶（花名：楚贤）\n Dragonfly Maintainer\n 基于 P2P 的文件以及镜像加速系统, 负责 Dfdaemon 子模块\n 议程 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1658818800,"description":"2022 年 7 月 26 日 19：00 - 20：00 ，线上直播第 29 期。","dir":"activities/sofa-channel-29/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d3727242c6f0f12aead78985904e20bb","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-29/","publishdate":"2022-07-26T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-29/","summary":"概要 活动主题：SOFAChannel#29:基于 P2P 的文件和镜像加速系统 Dragonfly 活动时间：07 月 28 日，周四晚 19 点 活动形式：线上直播 直播回放：点击观看","tags":["SOFAChannel","Dragonfly","文件和镜像加速系统"],"title":"SOFAChannel#29 基于 P2P 的文件和镜像加速系统 Dragonfly","type":"activities","url":"/sofastack.tech/activities/sofa-channel-29/","wordcount":623},{"author":null,"categories":"SOFAStack","content":" 文｜李乔（花名：南桥)、李宗杰（花名：白鹰)\n李乔：蚂蚁集团高级开发工程师，负责蚂蚁境外银行支付结算系统开发\n李宗杰：蚂蚁集团技术专家，负责蚂蚁分布式事务中间件研发\n本文 11580 字 阅读 25 分钟\nPART. 1\u0026amp;ndash;背景 蚂蚁国际境外银行业务正在部分迁移至阿里云，原内部使用的 SOFA 技术栈无法在阿里云上得到支持。为了满足银行业务快速发展、简化银行系统技术栈的目标，我们采用了 Spring+Dubbo 等一套开源的技术方案重新构建起了新的技术栈。蚂蚁集团作为金融机构，内部应用采用了微服务架构，数据间的一致性极其重要，但蚂蚁内部原有的分布式事务框架，在阿里云上也无法提供技术支持。\nSeata 是分布式事务解决方案，囊括了阿里集团的 TXC （阿里云版本称为 GTS） 和蚂蚁集团的 TCC/SAGA 等多种模式，是一款经过多年双十一大规模流量验证的金融级分布式事务框架。因此在综合比较各个现有的分布式事务框架之后，我们选择了 Seata。\n本文介绍了蚂蚁集团境外银行技术部在国际站点建设过程中，使用开源的 Seata 1.4.2 版本进行分布式事务管理的详细方案。同时本文也介绍如何在客户端实现对事务悬挂、幂等、空提交以及空回滚等情形的处理方法。\nPART. 2\u0026amp;ndash;调研 Seata 经过四年建设后，已经形成了一个非常庞大的技术体系。但不管其如何演进，Seata 整体保持了架构的稳定性与使用接口的向后兼容性。\n2.1\u0026amp;ndash;Seata 架构 Seata 官网给出了其如下架构图：\n总体由如下角色构成：\n●TC: Transaction Coordinator\n事务协调器：维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n●TM: Transaction Manager\n事务管理器：定义全局事务的范围，提交或者回滚全局事务。\n●RM：Resource Manager\n资源管理器：和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\nTC 与 TM 以及各个 RM 之间使用 netty 框架进行长链接通信，通信协议是在四层 TCP 协议之上自定义的一套二进制双向通信协议，所以 Seata 总体的通信效率非常高。\n2.2\u0026amp;ndash;事务模式 在这套架构之上，Seata 提供了 TCC、AT、SAGA 和 XA 四种事务模式：\nTCC 模式\n参与者需要实现 Prepare/Commit/Rollback 接口，在一阶段实现数据资源的预处理，在二阶段实现提交和回滚逻辑完成两阶段的提交。优点是通过业务逻辑实现数据可见性和隔离性，快速释放本地事务，提高对同一个资源的并发度，缺点是引入了中间数据的预处理过程，增加了业务复杂度。因此 TCC 模式具有很好的性能与隔离性，尤其适合在银行金融场景下同一个账户的并发交易处理。\nAT 模式\n在一阶段时通过解析 SQL，生成二阶段回滚日志：二阶段提交时，删除回滚日志；二阶段回滚时，通过回滚日志来恢复记录到一阶段之前的状态。类似于 TCC 的两阶段，不过二阶段的 Commit/Rollback 由框架自动生成，自动实现了二阶段操作，易用性好于 TCC。但 AT 模式通过全局锁来实现数据的隔离性，因此对于同一个资源的事务处理只能串行操作，所以性能逊于 TCC。当然如果不存在并发使用同一个资源的场景，则 AT 模式可以很好的兼顾性能和隔离性，以及更好的开发效率。\nSAGA 模式\n是一种长事务解决方案，其一阶段正向服务和二阶段补偿服务都由业务开发实现，它在微服务编排领域有大量应用。但其数据隔离性不好，业务数据有被脏写的风险。\nXA 模式\n其使用接口与 AT 模式一致，提供了最严格的隔离性，可以保证了用户不会出现脏读。XA 模式的缺点是其事务范围较长，其性能较低。\n2.3\u0026amp;ndash;小结 Seata 四种模式都是二阶段事务的技术实现。结合 Seata 自身的技术架构，其事务模型总体有如下特点：\nPART. 3\u0026amp;ndash;实践 进行总体技术调研后，我们认为 Seata 的总体技术栈可以满足我们所有金融业务场景的需求。在实施过程中，在不同的业务场景下根据不同的技术需求进行了取舍，我们在发起者本地的交易流水部分使用了 AT 模式，在下游账户相关的服务中使用了 TCC 模式。本章接下来我们将以业务中最经典的账务余额模型为例详述本次实践，包括为了适配相应的事务模型所做的工作。\n3.1\u0026amp;ndash;交易流水使用 AT 模式 为了记录每次的交易流水状态，在发起每笔交易前，我们都要将本次交易流水做记录，交易状态流水简化模型如下：\n在接收到请求时，首先记录初始化状态的交易流水，然后发起分布式事务。本次交易的分布式事务执行成功后，预期该笔交易流水需要是执行成功状态。为了对失败的交易发起重试，我们启动了一个定时任务，定时扫描交易流水状态，扫描到一定时间后未完成的记录需要重新发起重试。\n从上面的场景可以看出，在发起者的交易流水记录的状态变更中，也需要参与到整个分布式事务中。分布式事务成功，则流水状态需要更新为成功，如果分布式事务失败，则需要更新为失败。同时交易流水记录之间是独立的，不存在并发操作的可能，只有异步任务的扫描才会和交易中的事务做抢锁处理。\n针对这个场景，就非常适合使用 AT 模式，无需通过业务代码记录事务执行状态，而是直接在发起者中通过 AT 模式提供的代理数据源执行修改流水状态为“执行成功”状态，由框架自动完成 AT 模式下的一二阶段的提交和回滚，保证交易流水状态和整体分布式事务的状态一致，同时可以保持简洁的代码和更高的开发效率。\n3.2\u0026amp;ndash;账户使用 TCC 模式 从业务原理上来分析，账户的余额是不能凭空增加或者减少的，每个余额变动必须有明细对应。所以账户余额模型应该具备以下几个关键要素：账户 （明确到底是谁的账户）、 余额 （承载的客户资产具体数值）、 账务明细 （记载账户余额变动的数值、时间和原因） 。这三个其实构成了最朴素的账户余额模型。\n根据从业务原理的分析，我们就产生了一个最简单的账户余额基础数据模型：\n账户（ip_account）\n账户模型确定了基本的账户信息：\n●账号：该账号与会员的信息映射在一起，作为会员的余额资产；\n●账户类型：对公 （商户账号） ，对私 （个人账号） ，平台户、营销户、商户待结算账户等类型；\n●余额：记录当前客户资产具体数据的余额；\n●交易状态：控制四种交易方式：流入、流出、充值、提现，这是在账务层做的一个资金安全兜底保障。每一种类型用 T/F 来表示是否可以进行此类交易，T 是可以，F 是不可以 ；\n●核算主体：用于表示当前账号在那个核算主体下面进行核算。\n账户明细（ip_account_log,ip_trans_log）\nip_trans_log 是指账户的交易明细，用于解释为什么这个账户是要发生这笔记账请求。可以理解为业务原始凭证，用于和业务系统数据关联校验。以你用支付宝在便利店买了一瓶矿泉水为例，就是记录的这花 2 元买水的原始信息。\nip_account_log 是指账务明细，用于解释这个账户到底扣减了多少钱，记账的对方账户是谁。仍然以你用支付宝在便利店 …","date":1658818800,"description":"蚂蚁国际境外银行业务正在部分迁移至阿里云，原内部使用的 SOFA 技术栈无法在阿里云上得到支持。为了满足银行业务快速发展、简化银行系统技术栈的目标，我们采用了 Spring+Dubbo 等一套开源的技术方案重新构建起了新的技术栈。","dir":"blog/seata-in-practice-in-ant-international-banking/","fuzzywordcount":9000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8c90a02142b9bb70cfc93d7828e502ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","publishdate":"2022-07-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","summary":"文｜李乔（花名：南桥)、李宗杰（花名：白鹰) 李乔：蚂蚁集团高级开发工程师，负责蚂蚁境外银行支付结算系统开发 李宗杰：蚂蚁集团技术专家，负责蚂蚁","tags":["SOFAStack"],"title":"Seata 在蚂蚁国际银行业务的落地实践","type":"blog","url":"/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","wordcount":8943},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 罗坤 提问：\n 您好，请问一下可以用 SOFATracer 的摘要日志是 result.code 判断交易是否成功来告警么？result.code 有哪些状态？\n A：是可以的，如果是监控，可以用 stat 日志。\n「SOFATracer」： https://github.com/sofastack/sofa-tracer\n2. xiaoyu 提问：\n 咨询一个问题，现在使用 MOSN 作为 Istio 数据面，还是只能使用 Istio 1.10.6 版本吗？\n A：是的，目前支持的这个版本。\n「MOSN」： https://github.com/mosn/mosn\n3. 高岩 提问：\n 请教下， MOSN 官网的集成 Istio 的例子，在 Katacoda 上练习 step 4 的测试 curl productpage 时失败，然后在我本地 Minikube 的环境测试结果也一样，请问下这个 demo 问题怎么排查？\n A：我试了一下，这个 Katacode 上执行 grep 会报错，但是不执行就没问题。\n 好的，我再试一下，感谢。\n A：如果遇到问题，可以看一下 MOSN 的日志。kubectl logs $pod -c istio-proxy 就可以了，还有问题可以建个 issue。\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 Kusion 模型库和工具链的探索实践\n\nSeata 多语言体系建设\n\nGo 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\n欢迎扫码关注：\n","date":1658473200,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220722/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"077f31118a42474e52018a9f6b870b4f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220722/","publishdate":"2022-07-22T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220722/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220722/","wordcount":675},{"author":"梁倍宁","categories":"SOFAStack","content":" 前言 SOFABoot的isle模块为Spring Boot应用提供了上下文隔离的能力以更好的支持模块化开发。借助该能力，可以很好的解决不同模块中的Bean冲突问题，有效的提高了团队协作开发的效率，尽可能的避免因冲突带来的额外时间成本\n SOFABoot的模块隔离能力，也叫做Spring上下文隔离能力，相较于类加载器隔离的实现方式，Spring上下文隔离的实现更为简单。SOFA给每一个模块都提供了一个独立的Spring上下文，这样各模块之间的Bean就无法直接引用，直接引用时通常会出现NoSuchBeanDefinitionException表示当前容器没有指定的Bean，以达到各模块在运行时隔离的效果。\n模块化启动相关类 类名 描述 com.alipay.sofa.isle.stage.PipelineStage 该接口是PipelineContext中一个步骤的描述，SOFA将启动行为抽象成了一条流水线中的各个步骤 com.alipay.sofa.isle.stage.ModelCreatingStage 该类是PipelineStage实现之一，其主要作用是创建模块 com.alipay.sofa.isle.stage.SpringContextInstallStage 该类是PipelineStage实现之一，其主要作用是将SOFA定义的“模块”安装到Spring的上下文中，也是SOFA模块化中最关键的一个步骤 com.alipay.sofa.isle.stage.ModuleLogOutputStage 该类是PipelineStage实现之一，其主要作用只是模块化的相关日志 com.alipay.sofa.isle.spring.SofaModuleContextLifecycle 该类是SOFA模块化核心实现的入口类，实现了SmartLifecycle接口，会在Spring发布ContextRefreshed事件之前调用 主体流程 SofaModuleContextLifecycle SOFABoot的模块化能力主要是基于Spring的Lifecycle来实现的，核心的入口类为com.alipay.sofa.isle.spring.SofaModuleContextLifecycle，该类实现了Spring的org.springframework.context.SmartLifecycle接口，会在ContextRefreshedEvent事件发布之前调用。当Spring的上下文刷新时会触发SOFA模块化的装配流程，其源码如下：\npublic void start() { if (isleRefreshed.compareAndSet(false, true)) { try { pipelineContext.process(); } catch (Throwable t) { SofaLogger.error(ErrorCode.convert(\u0026amp;quot;01-10000\u0026amp;quot;), t); throw new RuntimeException(t); } } } 检查当前状态是否是已经调用，如已调用则直接返回。 如果是Root上下文，则直接调用PipelineContext的process，该调用会顺序执行模块化流水线上的各个步骤ModelCreatingStage、SpringContextInstallStage、ModuleLogOutputStage 接下来我们逐个解析PipelineStage的行为。\nModelCreatingStage 顾名思义模型构造阶段，该阶段会对应用程序构造一个应用模型，用以描述应用的基本属性以及所拥有的模块。ModelCreatingStage的process源码码如下：\nprotected void doProcess() throws Exception { ApplicationRuntimeModel application = new ApplicationRuntimeModel(); application.setAppName(appName); SofaRuntimeManager sofaRuntimeManager = applicationContext .getBean(SofaRuntimeManager.class); application.setSofaRuntimeContext(sofaRuntimeManager.getSofaRuntimeContext()); application.setModuleDeploymentValidator(new DefaultModuleDeploymentValidator()); getAllDeployments(application); applicationContext.getBeanFactory().registerSingleton(SofaBootConstants.APPLICATION, application); } 为应用构造运行时模型ApplicationRuntimeModel\n 为ApplicationRuntimeModel设置应用名，即环境变量中的spring.application.name对应的值\n 为应用模型设置SOFA运行时上下文\n 读取所有的Deployment并装载到ApplicationRuntimeModel中\n 将该ApplicationRuntimeModel注册到应用程序的Root Spring上下文中\n 这里详细说明一下第3步中是如何加载Deployment的，以下是getAllDeployments的代码:\nprotected void getAllDeployments(ApplicationRuntimeModel application) throws IOException, DeploymentException { Enumeration\u0026amp;lt;URL\u0026amp;gt; urls = appClassLoader.getResources(SofaBootConstants.SOFA_MODULE_FILE); if (urls == null || !urls.hasMoreElements()) { return; } while (urls.hasMoreElements()) { URL url = urls.nextElement(); UrlResource urlResource = new UrlResource(url); Properties props = new Properties(); props.load(urlResource.getInputStream()); DeploymentDescriptorConfiguration deploymentDescriptorConfiguration = new DeploymentDescriptorConfiguration( …","date":1658473200,"description":"源码解析｜SOFABoot 上下文隔离机制解析","dir":"projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e980cc3e12470d9a9f803973bb5c1a48","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","publishdate":"2022-07-22T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","summary":"前言 SOFABoot的isle模块为Spring Boot应用提供了上下文隔离的能力以更好的支持模块化开发。借助该能力，可以很好的解决不同模块","tags":["“源码解析”"],"title":"源码解析｜SOFABoot 上下文隔离机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","wordcount":5953},{"author":null,"categories":"SOFAStack","content":" 文｜杨英明（花名：向野)\nKusionStack 核心贡献者、蚂蚁集团高级研发工程师\n在基础设施技术领域深耕，专注 IaC/XaC、GitOps 等方向\n本文 4912 字 阅读 12 分钟\n前言 KusionStack 最早是为了解决蚂蚁内部复杂的运维场景而诞生的解决方案。思路是通过自研的 DSL （KCL） 沉淀运维模型 （Kusion Model） ，将基础设施部分能力的使用方式从白屏转为代码化，同时结合 DevOps 工具链 （Kusion CLI） 实现配置快速验证和生效，以此提升基础设施的开放性和运维效率。\n其中，Kusion Model 就是题中所说的 Kusion 模型库，而 Kusion CLI 就是 Kusion 工具链了。具体概念如下：\nKusion 模型库 Kusion 模型库是基于 KCL 抽象的配置模型。它的特点包括了开箱即用、用户友好、以及业务抽象。其实模型库最初朴素的出发点就是改善 YAML 用户的编写效率和体验，因为目前其实有不少配置是基于 YAML 描述的，比如 Kubernetes 在成为容器编排的事实标准之后，基于 K8s 的声明式配置就越来越多了起来。\n但是由于 K8s 本身的复杂性导致 YAML 配置越来越冗长、复杂。我们希望通过将复杂的配置描述通过 KCL 这门配置语言抽象封装到统一的模型中，从而简化用户侧配置代码的编写。\nKusion 工具链 Kusion 工具链是基于 KCL 的 DevOps 工具集合，它是用来辅助用户在 Kusion 生态里更好的生成、驱动他们的 KCL 配置。\n简单来说，Kusion 模型库是用 KCL 语言沉淀下来的可复用组件，工具链是 Kusion 模型的驱动器。\n本文主要介绍 KusionStack 中 Kusion 模型库和工具链在蚂蚁内部的实践探索和总结，重点阐述了如何利用 KusionStack 提升复杂基础设施的开放性和运维效率，希望对同样面临此类困境的伙伴有所启示。\nPART. 1\u0026amp;ndash;为什么要做 Kusion 模型库和工具链？ 我们可以先来看一张“现象\u0026amp;ndash;问题”图：\n在这张图中，我们列出了一些在内部大规模场景下的实践过程中会遇到的问题。\n举个应用部署的例子，应用 A 有 10+ 组件，内部对于这种非标应用没有提供很好的支持，每次部署需要经历繁多的步骤，比如元数据准备、申请证书、VIP、域名、手动部署 CRD、RBAC、Webhook、监控配置等。这个过程没有自动化，交付部署复杂，定制程度高，其中任何一个步骤出现问题，都需要找对应的研发同学沟通，应用部署的人工成本很高。\n总体来说，当时蚂蚁内部在大规模场景下利用现有基础设施进行运维的困境，主要就是来源于以上列出的这些现象，所以去解决这些现象背后的问题，成了亟待我们去做的事情。\nPART. 2\u0026amp;ndash;困境中的应对思路 经过反复的探讨和一致认同，我们最终摸索出一套解决方案，即通过 Kusion 模型库和工具链，从以下几个方面解决上述复杂基础设施运维困境的问题。\n可读性 面向业务 \u0026amp;amp; 屏蔽底层实现\n我们基于 KCL 抽象了 Kusion 模型库，其中包含一些开箱即用的模型，这些模型针对业务进行了抽象和提炼，面向用户的这层模型界面暴露的都是用户关心的属性，一些实现的细节被屏蔽掉了，所以它是面向业务的，也更容易被用户所接受和上手使用。\n符合工程直觉\nKusion 模型库作为用 KCL 编写的模型集合，更加符合工程直觉。因为 KCL 既然作为一门语言，它支持定义变量，编写条件判断，比如你可以通过 if-else 编写一些差异化的配置。\n解决的问题\n本节介绍的可读性的提升主要分为两个方面。一方面是 KCL 这门 KusionStack 自研的配置语言本身足够强的表达力，使得通过 KCL 描述配置和抽象模型更加丝滑；另一方面，使用 KCL 定义的 Kusion Model 封装了复杂的配置转换逻辑，屏蔽业务细节，抽象出清晰易懂的用户界面。这两方面的带来的可读性的优势可以比较好的解决使用传统配置语言维护困难的问题。\n工程性 前后端模型解耦\n我们对 Kusion 模型库根据功能，区分了前端模型和后端模型。为什么要区分前端模型和后端模型？直接目的是将「用户界面」和「模型实现」进行分离：\n前端模型\n前端模型即「用户界面」。包含平台侧暴露给用户的所有可配置属性，其中省略了一些重复的、可推导的配置，抽象出必要属性暴露给用户。\n用户只需要像实例化一个类 （Class） 一样，传入必要参数构成一份应用的「配置清单」，再经过工具链编译即可得到完整的面向基础设施的配置描述，比如说 K8s 的 YAML；\n后端模型\n后端模型是「模型实现」。后端模型和前端模型不同，是对用户不感知，刚才提到前端模型可以构成用户的配置清单，那么怎么让用户的配置清单生效呢？\n我们将属性的渲染逻辑全部下沉到后端模型中，后端模型中可借助 KCL 编写校验、逻辑判断、代码片段复用等逻辑，提高配置代码复用性和健壮性。\nMixin 复用\nMixin 是 KCL 提供的一种复用代码片段的方式。举个具体的例子，比如说有个模型的属性叫做超卖，开启超卖开关可以将 Pod 调度到可以超卖的机器当中，应用一般在发布线下环境的时候会开启超卖，以充分利用集群的资源。这段超卖配置生效的逻辑可能会被不同的应用运维模型使用，那么就可以借助 Mixin 机制实现一个 OverQuotaMixin，OverQuotaMixin 可以被不同后端模型引用，解决复用性的问题，无需重复造轮子。\nAppConfiguration 沉淀\n我们针对不同应用运维场景或者部署场景抽象为不同的应用运维模型，这些应用运维模型我们叫做 AppConfiguration。\n它们暴露的属性是不一样的，比如适应于标准基础设施的标准应用模型，适应于网络应用的网络应用模型。这些不同的应用运维模型暴露给用户可配置的属性是不同的，这些模型沉淀下来可以描述越来越多场景的应用运维配置，沉淀为在推动配置代码化过程中重要的资产。\n解决的问题\n本节介绍的是团队在建设蚂蚁的 Kusion 模型库过程中形成的一套最佳实践，它是推动建设 Kusion 模型库和工具链的一站式和开放性的基础。\n一站式 全生命周期配置描述 \u0026amp;amp; Single Source of Truth\n我们在完善可读性和工程性的过程中实现了全生命周期配置描述。我们将应用的部署配置、网络配置、监控配置等等和应用生命周期相关的配置尽可能的放到了一个模型中。\n这样做的好处是，将散落在各个系统的配置片段收集到了一起，用户可以在一个统一界面中维护他的应用配置，同时对于第三方系统，也不需要对接不同系统，他只需要运维一份统一的配置即可。\n「全生命周期配置描述」其实在做一件事情，就是业界经常提到的 Single Source of Truth，也就是所谓的“唯一真实来源”。这是实现 IaC 的重要前提之一。\n从下图可以看到，Kusion 模型库中的前后端模型将不同维度的运维能力通过 KCL 模块化，并灵活组织在各种 AppConfiguration 模型中。同时基于 AppConfiguration 实例化出的 …","date":1658214000,"description":"KusionStack 最早是为了解决蚂蚁内部复杂的运维场景而诞生的解决方案。思路是通过自研的 DSL（KCL）沉淀运维模型（Kusion Model），将基础设施部分能力的使用方式从白屏转为代码化，同时结合 DevOps 工具链（Kusion CLI）实现配置快速验证和生效，以此提升基础设施的开放性和运维效率。","dir":"blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e4c34198e41bd1986c646cf6f0ab041b","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","summary":"文｜杨英明（花名：向野) KusionStack 核心贡献者、蚂蚁集团高级研发工程师 在基础设施技术领域深耕，专注 IaC/XaC、GitOps 等方向 本文 4912 字 阅读 12 分钟","tags":["SOFAStack"],"title":"KusionStack 开源｜Kusion 模型库和工具链的探索实践","type":"blog","url":"/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","wordcount":5102},{"author":null,"categories":"SOFAStack","content":" 文｜赵新（花名：于雨 )\n蚂蚁集团可信原生部工程师阿里开源先锋人物、阿里开源大使\n负责蚂蚁可信原生技术部 DB Mesh 系统开发，以及容器和分布式事务开源工作\n本文 3846 字，阅读 10 分钟\n｜引语｜ 分布式事务是微服务技术体系中非常关键的的一个技术节点，当下最流行且经过大规模生产验证的高质量分布式事务实现无疑是 Seata。Seata 社区过去四年长期专注于 Java 语言实现，在 Java 领域是事实上的分布式事务技术标准平台。\n在诸如 gRPC 等微服务体系都在进行多语言建设的当下，分布式事务也应该有多种语言支持。所以在规划 2022 年 Seata Roadmap 时，其中一个非常的关键点就是 Seata 的多语言技术体系建设。在经过半年的准备特别是完成了 Seata v1.5.2 发版后，社区在今年 （2022年） 下半年的重点任务就是全力建设 Seata 的多语言实现。\nPART. 1\u0026amp;ndash;关键技术点 Seata Java 版本经过四年建设后，已经形成了一个非常庞大的技术体系。在进行多语言建设时，想要在半年内让多语言版本 Seata 的功能与 Seata Java 完全对齐，是不可能的。社区需要综合考量当下的实际迫切需求以及未来的发展方向，先找出 Seata 多语言版本的关键技术点。\n1. 事务模式 Seata 提供了 TCC、SAGA、AT 和 XA 四种经典事务模式。下图是四种模式的发布时间。\n各种模式有其各样的特点：\nAT 模式\n算是阿里体系独创的事务模式，其本质属于两阶段事务，其二阶段的 commit/rollback 由框架自动生成，对业务没有侵入，用户友好度高于 TCC 模式，可完美接续 Spring 事务，开发效率也较高，也是当前用户最多的一种模式。在 v1.5.2 已经发版的当下时间节点来看，AT 模式下通过全局锁来实现数据的隔离性，对于同一个资源的事务处理只能串行操作，性能一般。\nTCC 模式\n需要业务层参与者实现 prepare/commit/rollback 接口，其性能在四种模式下最好，数据可见性、隔离性也不错，流行程度仅次于 AT。特别适用于对吞吐、性能、隔离性要求都比较高的金融业务。\nSAGA 模式\n是一种长事务解决方案，其一阶段正向服务和二阶段补偿服务都由业务开发实现，可以很方便地与微服务框架进行结合，其性能仅次于 TCC 模式。因为其方便编排的特点，它在微服务编排领域有大量应用，当然使用时需要用户写 JSON 文件对服务进行编排。但其数据隔离性不好，业务数据有被脏写的风险。社区目前正在进行 SAGA 注解化工作（https://github.com/seata/seata/pull/4577），可进一步提升其性能与易用性。\nXA 模式\n不同于其他三种「补偿型」事务，它提供了最严格的隔离性：可以保证全局视角的数据一致性，即保证了用户不会出现脏读。Seata XA 模式的接口与 AT 模式基本一致，算是对用户比较友好的一种事务模式，它是对 XA 协议的严格实现。XA 模式的缺点是其事务范围比较长，其性能最低。\n四种模式的发版顺序如下：\n每种事务模式在阿里体系内都有各自的业务场景，其出现与演进都是迎合了各自业务场景现有的痛点。AT 和 XA 是不需要理解业务语义的，作用于 DB driver + DB 层面，TCC 和 SAGA 则需要业务层面自实现回滚幂等类逻辑，按照数据面和业务面来切分，依据对业务的入侵程度，四种模式归类如下图。\n分布式事务的基石是通信框架、SQL 解析以及数据库连接驱动实现等。得益于 Java 语言丰富的生态，Seata Java 版本可以很方便地站在这些 “巨人” 肩上展开相应的工作，这也是其他语言无法望其项背的。例如，主流数据库都提供了其 Java 版本的 DB driver。但当把工作背景放到多语言场景下时，就需要考量各个语言相关技术点的实现程度了。\n四种事务模式，AT 模式本质是应用层的事务，需要把数据库层面做过的 Redo/Undo 在应用层再做一遍，其中非常关键的一个技术点是：AT 模式需要介入数据源做 SQL 拦截，对 SQL 进行解析。单单考量 SQL 解析这个单技术点，Java 和 Python 语言有 antlr，Go 语言有 TiDB 提供的可自由使用的 pingcap/parser，但目前很多其他语言在这块都是空白的。\n所以社区在考量现实情况后，除了 Go 和 Python 版本，在进行多语言版本建设时，没有 SQL 解析包的语言版本先不提供 AT 模式的实现。\n2. 通信协议 不论哪种事务模式，都构建在 Seata 独有的架构之上。\n图片来自 seata 官网\nSeata 总体架构由如下角色构成：\n事务协调器 Transaction Coordinator\n简称 TC，维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n事务管理器 Transaction Manager\n简称 TM，定义全局事务的范围，提交或者回滚全局事务。\n资源管理器 Resource Manager\n简称 RM，和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\nTC 与 TM 以及各个 RM 之间使用 netty 框架进行长链接通信。具体而言，Seata Java 版本的通信协议是在四层 TCP 协议之上又定义了一套私有的二进制双向通信协议。其关键点在于 Seata Java 版本站在了 netty 这个巨人肩上。\n回到多语言这个背景下，很多语言并没有提供一套成熟的 TCP 通信框架。譬如 Dubbo 在建设其 Go 版本 dubbo-go 时，为了在 TCP 之上实现与 Dubbo 的私有二进制协议通信，本人前期的工作重点是先实现 TCP 通信框架 getty（https://github.com/apache/dubbo-getty），然后再实现其序列化协议 dubbo-go-hessian2（https://github.com/apache/dubbo-go-hessian2）。如果把语言切换成 JS、PHP 或者 Python，相关通信协议建设需要耗费社区大量精力。\nSeata 2019 年就在 API 层适配了 gRPC 的事务上下文传递，为了方便 Seata 多语言版本的建设，Seata Java 框架本身正在进行一项重要工作：Seata Client （包括 TM 和 RM） 基于 gRPC 与 Seata Server （TC） 集群进行通信。希望借助于 gRPC 的多语言优势，节省多语言版本在通信层面的工作量。\n3. 配置和注册中心 类似于其他微服务框架，Seata 自身除了上一节提到的内部组件外，还依赖于注册中心和配置中心。微服务上层的应用通过配置中心找到注册中心，再通过注册中心发现 Seata 的各个服务组件。一个典型的完备的 Seata 服务架构如下图。\nSeata Java 这套架构可以很方便的嵌入注入 Dubbo、SOFARPC 以及 Spring 等 Java 微服务框架中。其中两种非常重要的外部依赖组件是：\nConfig …","date":1658214000,"description":"在诸如 gRPC 等微服务体系都在进行多语言建设的当下，分布式事务也应该有多种语言支持。所以在规划 2022 年 Seata Roadmap 时，其中一个非常的关键点就是 Seata 的多语言技术体系建设。在经过半年的准备特别是完成了 Seata v1.5.2 发版后，社区在今年 （2022 年） 下半年的重点任务就是全力建设 Seata 的多语言实现。","dir":"blog/seata-multi-programming-language-system-construction/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"60da96ebbdbc644758f505352c5e2d13","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-multi-programming-language-system-construction/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/seata-multi-programming-language-system-construction/","summary":"文｜赵新（花名：于雨 ) 蚂蚁集团可信原生部工程师阿里开源先锋人物、阿里开源大使 负责蚂蚁可信原生技术部 DB Mesh 系统开发，以及容器和分布式事务开源工作","tags":["SOFAStack"],"title":"Seata 多语言体系建设","type":"blog","url":"/sofastack.tech/blog/seata-multi-programming-language-system-construction/","wordcount":4266},{"author":"林楠","categories":"SOFAStack","content":" 前言 SOFABoot 提供两种服务通信能力，一种是 JVM 服务，用于同一应用内不同模块间的通信，一种是 RPC 服务，用于不同应用间的通信。SOFABoot 提供三种方式实现服务的发布和引用，分别是XML 配置文件、注解和 API 的方式，本文从源码角度解析从服务的发布和引用到组件协议 binding 机制的实现原理。\n服务发布与引用 在了解组件协议 binding 机制之前，我们先简单了解一下服务的发布与引用的源码。\nXML 通过 XML 方式发布或引用服务时，使用 sofa:service 发布服务，使用 sofa:reference 引用服务，示例代码如下：\n\u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleJvmService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.isle.sample.SampleJvmService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; \u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleJvmService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.isle.sample.SampleJvmService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 我们可以看到在 xml 中使用 xmlns:sofa，将 sofa 前缀的命名空间定义为 http://sofastack.io/schema/sofaboot ，Spring 在解析 sofa:* 标签时会与该命名空间相关联。对于 xml 的解析，SOFABoot 在 sofa-boot 模块中使用 spring.handlers 配置文件中注册了 sofa 命名空间的 XML 处理器。\nhttp\\://sofastack.io/schema/sofaboot=com.alipay.sofa.boot.spring.namespace.handler.SofaBootNamespaceHandler SofaBootNamespaceHandler 在初始化阶段，基于 SPI 机制查找所有标签解析器，调用 registerTagParser 方法注册标签解析器。\npublic void init() { ServiceLoader\u0026amp;lt;SofaBootTagNameSupport\u0026amp;gt; serviceLoaderSofaBoot = ServiceLoader.load(SofaBootTagNameSupport.class); serviceLoaderSofaBoot.forEach(this::registerTagParser); } 注册标签解析器时，调用解析器的 supportTagName 方法获取标签名，将解析器与标签名关联起来。\nprivate void registerTagParser(SofaBootTagNameSupport tagNameSupport) { if (tagNameSupport instanceof BeanDefinitionParser) { registerBeanDefinitionParser(tagNameSupport.supportTagName(), (BeanDefinitionParser) tagNameSupport); } else if (tagNameSupport instanceof BeanDefinitionDecorator) { registerBeanDefinitionDecoratorForAttribute(tagNameSupport.supportTagName(), (BeanDefinitionDecorator) tagNameSupport); } else { ... } } sofa:service 标签的解析器是 ServiceDefinitionParser，使用 doParseInternal 方法读取 xml 标签属性值，并解析为 bean 定义，根据 getBeanClass 定义的类型，将 sofa:service 标签定义的服务转换为 ServiceFactoryBean，并注册到 Spring 上下文中。\npublic class ServiceDefinitionParser extends AbstractContractDefinitionParser { ... @Override protected void doParseInternal(Element element, ParserContext parserContext, BeanDefinitionBuilder builder) { String ref = element.getAttribute(REF); builder.addPropertyReference(REF, ref); if (element.hasAttribute(\u0026amp;quot;id\u0026amp;quot;)) { String id = element.getAttribute(\u0026amp;quot;id\u0026amp;quot;); builder.addPropertyValue(BEAN_ID, id); } else { builder.addPropertyValue(BEAN_ID, ref); } } @Override protected Class getBeanClass(Element element) { return ServiceFactoryBean.class; } @Override public String supportTagName() { return \u0026amp;quot;service\u0026amp;quot;; } } 根据 Spring 的机制，在注册 bean 时，对 bean 的属性赋值后会调用 bean …","date":1658214000,"description":"源码解析 | SOFABoot 组件协议 binding 机制解析","dir":"projects/sofa-boot/sofaboot-component-protocol-binding/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"acfba7d02af62462b2f1c32fb39c9265","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","summary":"前言 SOFABoot 提供两种服务通信能力，一种是 JVM 服务，用于同一应用内不同模块间的通信，一种是 RPC 服务，用于不同应用间的通信。SOFABoot 提供三种方式实","tags":["“源码解析”"],"title":"源码解析：SOFABoot 组件协议 binding 机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","wordcount":5465},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展\n欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 清源 提问：\n 咨询个问题，MOSN 能做协议转换吗？类似于 API 网关那种功能，像 HTTP 调 Dubbo 的服务。\n A：可以的哈，这里是一个 HTTP 到 SOFA 的例子，\nhttps://github.com/mosn/mosn/tree/master/pkg/filter/stream/transcoder/http2bolt\n 我看了下，例子中并没有对 buf 做编解码，是 Bolt 自动识别 HTTP 的报文吗？\n A：这个 filter 就是把 HTTP 的字段转换为 Bolt 的哟，这还有个 Spring Cloud 到 Dubbo 的转换，MOSN 已经对 buf 解码好了，暴露给你的是 HTTP 解码之后的 header 和 body，\nhttps://www.github.com/mosn/extensions/tree/master/go-plugin%2Fplugins%2Ftranscoders%2Fspringcloud2dubbo%2Fmain\n「MOSN」：\nhttps://github.com/mosn/mosn\n2. 国奇 提问：\n 你好，请问有能用的 SOFARegistry 安装步骤吗？\n A：用 start_dev 启动 integrate 模式，registry-run.sh 是给其他脚本调用的：\n也可以参考下面这个文档，fatjar docker 的部署模式都可以：\n*https://www.sofastack.tech/projects/sofa-registry/deployment/***\n「SOFARegistry」：\nhttps://github.com/sofastack/sofa-registry\n3. 国奇 提问：\n 你好，发现一个问题，比如 A 应用 1.0 升级到 2.0 得改 webContextPath 才可以。也就是说要升级版本，要改版本号，还需要改 webContextPath 对吧？\n A：按这里文章介绍的，不引入 web-ark-plugin 的话，就用不同的端口来部署多个 web 服务。你们可以保留这个使用方式，就不需要改 webContextPath，\nhttps://github.com/WuHang1/sofa-ark/blob/code_analyse_multi_web_deploy/doc/CODE_ANALYSE_MULTI_WEB.md\n 发布就会更改不同的端口号，否则端口号被占用。可不可以，我自己不用改端口号，也不用改 webContextPath？\n A：目前不可以，你可以看下之前介绍 SOFAArk Web 插件的文档，里面介绍了必须要改这两个中的其中一个。如果有方案能做到这点那是挺好的，可以提个 proposal。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 Go 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\n社区文章｜MOSN 构建 Subset 优化思路分享\n\nNydus —— 下一代容器镜像的探索实践\n\n欢迎关注：\n","date":1657868400,"description":"SOFA Weekly | 开源人—牛学蔚、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220715/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f60972f54e7daee19a80b6022c644290","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220715/","publishdate":"2022-07-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220715/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展 欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人—牛学蔚、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220715/","wordcount":912},{"author":null,"categories":"SOFAStack","content":" 文｜丁飞（花名：路德 )\n蚂蚁集团高级工程师\n深耕于 SOFAMesh 产品的商业化落地\n主要方向为基于服务网格技术的系统架构升级方案设计与落地\n本文 4394 字 阅读 10 分钟\n｜前言｜ MOSN 作为蚂蚁集团在 ServiceMesh 解决方案中的数据面组件，从设计之初就考虑到了第三方的扩展开发需求。目前，MOSN 支持通过 gRPC、WASM、以及 Go 原生插件三种机制对其进行扩展。\n我在主导设计和落地基于 Go 原生插件机制的扩展能力时遇到了很多问题，鉴于这方面的相关资料很少，因而就有了这个想法来做一个非常粗浅的总结，希望能对大家有所帮助。\n注：本文只说问题和解决方案，不读代码，文章最后会给出核心源码的 checklist。\nPART. 1\u0026amp;ndash;文章技术背景 一、运行时 通常而言，在计算机编程语言领域，“运行时”的概念和一些需要使用到 VM 的语言相关。程序的运行由两个部分组成：目标代码和“虚拟机”。比如最为典型的 JAVA，即 Java Class + JRE。\n对于一些看似不需要“虚拟机”的编程语言，就不太会有“运行时”的概念，程序的运行只需要一个部分，即目标代码。但事实上，即使是 C/C++，也有“运行时”，即它所运行平台的 OS/Lib。\nGo 也是一样，因为运行 Go 程序不需要前置部署类似于 JRE 的“运行时”，所以它看起来似乎跟“虚拟机”或者“运行时”没啥关系。但事实上，Go 语言的“运行时”被编译器编译成了二进制目标代码的一部分。\n图 1-1. Java 程序、runtime 和 OS 关系\n图 1-2. C/C++ 程序、runtime 和 OS 关系\n图 1-3. Go 程序、runtime 和 OS 关系\n二、Go 原生插件机制 作为一个看起来更贴近 C/C++ 技术栈的 Go 语言来说，支持类似动态链接库的扩展一直是社区中较为强烈的诉求。\n如图 1-5，Go 在标准库中专门提供了一个 plugin 包，作为插件的语言级编程界面，src/plugin 包的本质是使用 cgo 机制调用 unix 的标准接口：dlopen() 和 dlsym() 。因此，它给 C/C++ 背景的程序员一种“这题我会”的错觉。\n图 1-4. C/C++ 程序加载动态链接库\n图 1-5. Go 程序加载动态链接库\nPART. 2\u0026amp;ndash;典型问题解决 很遗憾，与 C/C++ 技术栈相比，Go 的插件的产出物虽然也是一个动态链接库文件，但它对于插件的开发、使用有一系列很复杂的内置约束。更令人头大的是，Go 语言不但没有对这些约束进行系统性的介绍，甚至写了一些比较差的设计和实现，导致插件相关问题的排错非常反人类。\n本章节重点跟大家一起看下，在开发、使用 Go 插件，主要是编译、加载插件的时候，最常见、但必须定位到 Go 标准库 （主要包括编译器、链接器、打包器和运行时部分） 源码才能完全弄明白的几个问题，及对应的解决方法。\n简而言之，Go 的主程序在加载 plugin 时，会在“runtime”里对两者进行一堆约束检查，包括但不限于：\n- go version 一致\n- go path 一致\n- go dependency 的交集一致\n 代码一致 path 一致 - go build 某些 flag 一致\n一、不一致的标准库版本 主程序加载插件时报错：\nplugin was built with a different version of package runtime/internal/sys\n从这个报错的文本可以得知，具体有问题的库是 runtime/internal/sys ，很显然这是一个 go 的内置标准库。看到这里，你可能会有很大的疑惑：我明明用的是同一个本地环境编译主程序和插件，为什么报标准库不是一个版本？\n答案是，Go 的 error 日志描述不准确。而这个报错出现的根本原因可以归结为：主程序和插件的某些关键编译 flag 不一致，跟“版本”没啥关系。\n比如，你使用下面的命令编译插件：\nGO111MODULE=on go build \u0026amp;ndash;buildmode=plugin -mod readonly -o ./codec.so ./codec.go\n但是你使用 goland 的 debug 模式调试主程序，此时，goland 会帮你把 go build 命令按下面的例子组装好：\n注意，goland 组装的编译命令里包含关键的 -gcflags all=-N -l 参数，但是插件编译的命令里没有。此时，你在尝试拉起插件时就会得到一个有关 runtime/internal/sys 的报错。\n图 2-1. 编译 flag 不一致导致的加载失败\n解决这一类标准库版本不一致问题的方案比较简单：尽可能对齐主程序和插件编译的 flag。事实上，有一些 flag 是不影响插件加载的，你可以在具体的实践中慢慢摸索。\n二、不一致的第三方库版本 如果使用 vendor 来管理 Go 的依赖库，那么当解决上一节的问题之后，你 100% 会立即遇到以下这个报错：\nplugin was built with a different version of package xxxxxxxx\n其中，xxxxxxxx 指的是某一个具体的三方库，比如 github.com/stretchr/testify。这个报错有几个非常典型的原因，如果没有相关的排查经验，其中几个可能会烧掉开发人员不少时间。\nCase 1. 版本不一致\n如报错所示，似乎原因很明确，即主程序和插件所共同依赖的某个第三方库版本不一致，报错中会明确告诉你哪一个库有问题。此时，你可以对比排查主程序和插件的 go.mod 文件，分别找到问题库的版本，看看他们是否一致。如果这时候你发现主程和插件确实有 commitid 或 tag 的不一致问题，那解决的方法也很简单：对齐它们。\n但是在很多场景下，你只会用到三方库的一部分：如一个 package，或者只是引了某些 interface。这一部分的代码在不同的版本里可能根本就没有变更，但其他没用到的代码的变更，同样会导致整个三方库版本的变更，进而导致你成为那个“版本不一致”的无辜受害者。\n而且，此时你可能立即会遇到另一个问题：以谁为基准对齐？主程序？还是插件？\n从常理上来说，以主程序为基线进行对齐是一个比较好的策略，毕竟插件是新添加的“附属品”，且主程序与插件通常是“一对多”的关系。但是，如果插件的三方库依赖因为任何原因就是不能和主程序对齐怎么办？在尝试了很久以后，我暂时没有找到一个完美解决这个问题的办法。\n如果版本无法对齐，就只能从根本上放弃走插件这条路。\nGo 语言的这种对三方库的、几乎无脑的强一致性约束，从一方面来说，避免了运行时因为版本不一致带来的潜在问题；从另一方面来说，这种刻意不给程序员灵活度的设计，对插件化、定制化、扩展化开发非常的不友好。\n图 2-2. 共同依赖的三方库版本不一致导致的加载失败\nCase 2. 版本号一致，代码不一致\n当你按照 case 1 的思路排查 go.mod 文件，但是惊讶的发现报错的库版本是一致的时候，事情就会变得复杂起来。你可 …","date":1657609200,"description":"作者在主导设计和落地基于 Go 原生插件机制的扩展能力时遇到了很多问题，鉴于这方面的相关资料很少，因而就有了这个想法来做一个非常粗浅的总结，希望能对大家有所帮助。","dir":"blog/go-native-plug-in-use-problem-full-analysis/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"734cc212a753d53c15717c92d859d34c","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","publishdate":"2022-07-12T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","summary":"文｜丁飞（花名：路德 ) 蚂蚁集团高级工程师 深耕于 SOFAMesh 产品的商业化落地 主要方向为基于服务网格技术的系统架构升级方案设计与落地 本文 4394 字 阅读 10 分钟 ｜前","tags":["SOFAStack"],"title":"Go 原生插件使用问题全解析","type":"blog","url":"/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","wordcount":4545},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 何烨 提问：\n 请问一下这个配置现在支持 Nacos 了吗？\n A：SOFABoot 已经支持 Nacos 了。\n「SOFABoot」： https://github.com/sofastack/sofa-boot\n2. 鲍之知 提问：\n 下图中这个 SOFATracer 日志默认是生成在哪里呀？\n A：~/logs。\n「SOFATracer」： https://github.com/sofastack/sofa-tracer\n3. Philip Guan 提问：\n 请问 biz 可以独立引入 master biz 中没有的依赖吗？例如 Hutool、master biz 没有，希望在 biz 里使用。\n A：可以的，打包完后可以 check 一下是否 /biz/ 里有这个包。如果没有的话，可以在 master biz 里引入这个依赖，在 biz 里引入但设置 为 provided 也可以使用。\n 期望是 master biz 不引入 Hutool 的情况下，在 biz 里使用 Hutool。\n A：可以的。\n「SOFAArk」： https://github.com/sofastack/sofa-ark\n本周推荐阅读 KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境 \n GLCC｜Kata Containers、Nydus、Layotto、KusionStack 中选名单公示！ \n SOFARegistry 源码｜数据同步模块解析 \n 社区文章｜MOSN 构建 Subset 优化思路分享 \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1657263600,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220708/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"897429d0434f7577dd9a8efd3b70056f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220708/","publishdate":"2022-07-08T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220708/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220708/","wordcount":661},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@魏顺利 提问：\n runtime-sofa-boot-starter 和 rpc-sofa-boot-starter 区别是什么？\n A：runtime-sofa-boot-starter 是 SOFA 的核心能力 starter，rpc-sofa-boot-starter 是 SOFARPC 能力的 starter。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n2.@寒鸦少年 提问：\n 请问 Plugin 是一个微服务的概念吗，是否提供 HTTP 接口呢？\n A：Plugin 自己管理的依赖，通过 ark 中提到的 导出机制，将其自己管理的类能够暴露给 biz 使用 （多 biz 可以共享某个 plugin 导出的类） ；plugin 和 biz 之间更多说的是类加载的委托关系，biz 之间是通信。\n 那 biz 的 class loader 的加载逻辑应该很复杂吧，因为它要区分什么类自己加载，什么类委托 plugin 加载。\n A：可以看下这个，https://www.sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/\n「SOFAArk」https://github.com/sofastack/sofa-ark\n本周推荐阅读 社区文章｜MOSN 构建 Subset 优化思路分享 \n SOFA 星球”闯关计划 2.0——Layotto 飞船焕新出发 \n Nydus —— 下一代容器镜像的探索实践 \n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1656054000,"description":"SOFA Weekly | 开源人-于雨、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220624/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bc4cc62919a28554b99dc8a812b88dcc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220624/","publishdate":"2022-06-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220624/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人-于雨、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220624/","wordcount":813},{"author":null,"categories":"SOFAStack","content":" 文｜李旭东（花名：向旭 )\n蚂蚁集团技术专家\n蚂蚁中间件研发，专注于 SOFARegistry 及其周边基础设施的开发与优化\n本文 2098 字 阅读 8 分钟\n｜前言｜ MOSN 使用了 Subset 算法作为其标签匹配路由负载均衡的方式。本文主要介绍 Subset 的原理，包括了在超大规模集群下 MOSN 的 Subset 所遇到的一些性能瓶颈与采用的优化算法。\n首先，为什么要优化 Subset 呢？\n总体而言，性能瓶颈往往会由于集群规模的增大逐渐暴露出来。在蚂蚁的超大规模的集群上，注册中心推送地址列表会对应用造成一定的开销。\n在我所参与过的某一次大规模压测中，核心应用的机器数目非常庞大，当进行发布或者运维的时候，它的地址列表会被推送给所有调用它的应用。\n而 MOSN 会接收这份地址列表重新构建自己的路由。当地址列表非常庞大的时候，MOSN 更新 cluster 的性能瓶颈逐渐地暴露出来，出现了较高的 CPU 毛刺，内存在短时间内出现了上涨，gc 频率也大幅度增加。\n通过下方的火焰图，我们可以看到这次压测期间对某应用的 MOSN 的 pprof：\n- Alloc：\n- CPU：\n从 pprof 可以看到，无论是 CPU 还是 alloc 的开销， 构建 SubsetLoadBalancer 都明显占了大头，所以优化这部分的构建是亟待去做的一件事。\n最终通过探索优化，我们可以减少 SubsetLoadBalancer 构建过程中 95% 的 CPU 开销和 75% 的 alloc 开销。\n下面让我们一起回顾下本次优化的过程与思路。\nPART. 1\u0026amp;ndash;Subset 基本原理介绍 在一个集群里，通常机器会有不同的标签，那么如何将一个请求路由到指定标签的一组机器呢？\nMOSN 的做法是把一个服务下的机器按照机标签组合进行预先分组，形成多个子集。在请求的时候，根据请求中的 metadata 信息可以快速查询到这个请求对应应该匹配到的子集。\n如下图所示，可以看到当前有 4 个节点：\n标签匹配规则会根据 zone 、mosn_aig 、mosn_version 这 3 个字段进行匹配路由，根据这 3 个 key 的排序进行组合得到以下匹配路径：\n相对应的匹配树如下：\n假设需要访问 {zone: zone1, mosn_aig: aig1}，那么经过排序后查找顺序为 mosn_aig:aig1 -\u0026amp;gt; zone:zone1，查找到 [h1, h2]。\n以上就是 Subset 的基本原理介绍。\nPART. 2\u0026amp;ndash;MOSN 对 Subset 的构建 首先需要输入的参数有两个：\n- 带标签的机器列表 hosts，比如 [h1, h2, h3, h4]；\n- 用于匹配的 subSetKeys, 如下图：\n接着我们先带上思路，然后阅读源码来看一下 MOSN 的 SubsetLoadBalancer 是如何构建这棵树的。\n核心思路如下：\n- 遍历每一个 host 的 labels 和 subSetKeys 递归去创建一棵树；\n- 对于树的每一个节点，都会遍历一次 hosts 列表，过滤出匹配这个节点的 kvs 的 subHosts，每个节点创建一个子 load balancer。\n我们来看源码图：\n整体的构建复杂度是 O *(M*NK) (M: Subset 树节点个数，N: Hosts 个数, K: 匹配的 Keys）\nPART. 3\u0026amp;ndash;构建性能瓶颈分析 通过对生产的 profile 分析，我们发现 SubsetLoadBalancer 的 createSubsets 在 CPU 和 alloc 的火焰图中的占比都较高。所以下面我们开始编写 benchmark，来优化这一部分的性能。\n我们的输入参数为：\n- subSetKeys：\n- 8000 个 hosts （每个 hosts 都有 4 个 label, 每个 label 对应 3 种 value） ：\n接着，我们来看 CPU 和 alloc_space 的占用情况。\n- CPU：\n- alloc_space：\n从上面两张火焰图中，我们可以看出 HostMatches 和 setFinalHost 占用了较多的 CPU_time 和 alloc_space。我们首先来看下 HostMatches：\n它的作用是判断一个 host 是不是完全匹配给定的键值对，且判断这个 host 是否匹配这个匹配树节点。\n它的开销主要在于执行次数过多：treeNodes * len(hosts) ，所以在集群变大时，这边的运行开销会大幅度上升。\n然后我们再来看一下 setFinalHost：\n他的主要逻辑是按 IP 进行去重，同时会附带 copy。如果我们在 SubsetLoadBalancer 的顶层进行去重，那么它的任意 Subset 都不需要再次去重。因此，这边可以把它改成不去重。\nPART. 4\u0026amp;ndash;倒排索引优化构建 在 HostMatches 的这么多次匹配中，实际上有很多的重复操作，比如对 host label 中某个 kv 判断 equals，在构建过程中重复的次数相当之多。\n所以优化的思路可以基于避免这部分重复的开销，从预先构建倒排索引出发。具体步骤展开如下：\n1. 输入两项参数:\n- subSetKeys：\n- hosts：\n2. 遍历一次 hosts，针对每个 kv 我们用 bitmap 构建倒排索引：\n3. 根据 subSetKeys 和倒排索引中的 kvs，构建出匹配树，因为索引中是去重的与 hosts 数目无关，这个操作开销占比很低；\n4. 对于树的每个节点，利用倒排索引中的 bitmap 做交集快速得到匹配全部 kv 的 hosts 的索引 bitmap；\n5. 使用 bitmap 中存储的 index 从 hosts 中取出对应 subHosts 构建子 load balancer，同时注意此处不需要使用 setFinalHosts 进行去重。\n基于上述思路过程开发新的 Subset preIndex 构建算法，可以在 MOSN 的对应 Pull Request 页面查看详情：\nhttps://github.com/mosn/mosn/pull/2010\n再分享下添加 benchmark 进行测试的地址：\nhttps://github.com/mosn/mosn/blob/b0da8a69137cea3a60cdc6dfc0784d29c4c2e25a/pkg/upstream/cluster/subset_loadbalancer_test.go#L891\n可以看到相对之前的构建方式，构建速度快了 20 倍，alloc_space 减小了 75% 。同时，alloc 次数出现了少量的上升，这是因为需要额外的构建一次倒排索引所致。\n下面观察一下 gc：\n我们可以发现，相较于之前的构建方式，运行期间的内存更小了，而且 CPU 回收的内存也变少了，同时 gc 并行扫描的时长小幅上涨，STW 时间变的更短。\n最后，测试一下在不同 hosts 数目下的优化程度，可以看到在 hosts …","date":1655708400,"description":"MOSN 使用了 Subset 算法作为其标签匹配路由负载均衡的方式。本文主要介绍 Subset 的原理，包括了在超大规模集群下 MOSN 的 Subset 所遇到的一些性能瓶颈与采用的优化算法。","dir":"blog/build-subset-optimization/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d1475506aa7ef2b35d302df89924b72d","permalink":"https://sofastack.github.io/sofastack.tech/blog/build-subset-optimization/","publishdate":"2022-06-20T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/build-subset-optimization/","summary":"文｜李旭东（花名：向旭 ) 蚂蚁集团技术专家 蚂蚁中间件研发，专注于 SOFARegistry 及其周边基础设施的开发与优化 本文 2098 字 阅读 8 分钟 ｜前言｜ MOSN 使用了 Subset 算法作为其标","tags":["SOFAStack"],"title":"社区文章｜MOSN 构建 Subset 优化思路分享","type":"blog","url":"/sofastack.tech/blog/build-subset-optimization/","wordcount":2243},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@魏顺利 提问：\n 生成的 ark-biz.jar 这个怎么打到 maven 仓库？\n A：加上true配置然后 mvn install/deploy，参考：\nhttps://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.@寒鸦少年 提问：\n 请教个问题，SOFAStack 商业版里面，SOFABoot 在集成中间件的时候，中间件的客户端咱这边有自己封装的版本，还是纯走开源的那些客户端比如 Jedis 之类的。\n A：SOFAStack 有些中间件会有自己的封装，也会有独立的客户端。\n 可以给个列表么，具体有哪些独立的客户端和开源版本的升级点对比之类的？\n A：可以看下这个：\n「SOFABoot」https://github.com/sofastack/sofa-boot\n本周推荐阅读 「开源之夏」SOFASTack \u0026amp;amp; MOSN 社区项目中选结果 \n SOFA 星球”闯关计划 2.0——Layotto 飞船焕新出发 \n Nydus —— 下一代容器镜像的探索实践 \n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1655449200,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220617/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3d55fba6e2019654f9dccb079b67ba5d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220617/","publishdate":"2022-06-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220617/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220617/","wordcount":699},{"author":"吴航","categories":"SOFAStack","content":" 背景 原生springboot-web应用部署流程 两种合并部署模式 支持单Host合并部署的关键点 多Biz共用tomcat实例 多Biz接口区分 总结 背景 SOFAArk基于java类加载机制，为我们提供了一种java进程内多模块隔离的方案。每个业务模块——Ark Biz，都是一个完整的springboot项目，可独立运行；也可作为一个maven依赖或远程jar包，引入被称为Master Biz的基座Biz，随着Master Biz的启动合并部署运行，并由专属的BizClassLoader加载来实现隔离。\n当多个合并部署的Biz为web应用时，则面临着更多的挑战，这里我们可以对比独立tomcat部署多个webapp的实现，其除了各webapp之间的隔离外，还要保证tomcat自身资源的共享和统一管控。SOFAArk从0.6.0开始支持基于springboot embedded tomcat的多web应用合并部署，它是如何做到的，是否可以继续扩展支持其它类型web容器应用，下文将会进行具体分析。\n原生springboot-web应用部署流程 我们先从原生的springboot构建的基于内置tomcat的web应用说起。其在运行main函数初始化时，使用TomcatServletWebServerFactory#getWebServer这一工厂方法，创建了一个实现WebServer接口的TomcatWebServer实例，用来控制一个tomcat服务器，其中包括了一个Catalina Server的实现StandardServer，Server中的Engine、Host、Context容器也都是一个，Context中包含了唯一的contextPath。\nspringboot自身还有jetty、netty等WebServer的实现，同样由其对应的工厂方法创建。对应的工厂bean基于springboot的自动装配机制加载。\n两种合并部署模式 首先我们可以参考非Web的多Biz合并部署，SOFAArk使用不同的类加载器加载不同的Biz，其中Master Biz为LaunchedURLClassLoader加载，非Master Biz有其专属的BizClassLoader加载。对于每个Web Biz，也会使用其类加载器完成上述原生springboot web应用的启动流程，创建自己的Server、Host等。\n这种情况下，为了区分不同Biz的接口，需要为每个Biz配置不同的port。\n这种方式由于一个Jvm进程中包含了多个Server及其Host，因此被称为多Host模式。\n多Host模式的问题首先在于重复创建了tomcat相关的资源，造成资源的浪费；其次是每个Biz有自己的端口，不利于整个Ark包应用整体对外提供服务。因此SOFAArk提供了类似独立tomcat部署多webapp的方式。所有Biz共用同一个Server及Host，每个Biz只创建自己的Context，通过Context中的contextPath将自身接口与其它Biz接口做区分。\n这种方式由于一个Jvm进程中共用一个Server及其Host，因此被称为单Host（多Context）模式。下面将就其实现做重点介绍。\n支持单Host合并部署的关键点 相较于单纯的springboot应用，一个Ark包的复杂之处在于，它可以包含多个Ark Biz，其中每个Ark Biz都是一个完整的springboot项目。因此在使用单个内置tomcat实例部署时会面临以下问题：\n 多个Biz(springboot项目)需要共用tomcat实例；\n 需要像独立tomcat下部署多webapp一样，通过添加前缀的方式区分不同Biz的http接口。\n 因此sofa-ark对springboot的相关实现做了替换，具体如下：\n sofa-ark springboot ArkTomcatServletWebServerFactory TomcatServletWebServerFactory ArkTomcatEmbeddedWebappClassLoader TomcatEmbeddedWebappClassLoader ArkTomcatWebServer TomcatWebServer 并使用其插件机制来扩展，ArkTomcatEmbeddedWebappClassLoader位于web-ark-plugin插件中，当maven依赖该插件时，springboot判断ArkTomcatEmbeddedWebappClassLoader类存在，加载ArkTomcatServletWebServerFactory，该Factory再创建ArkTomcatWebServer，由此使用单Host模式合并部署。\n若未依赖该插件，则ArkTomcatEmbeddedWebappClassLoader不存在，springboot自动加载其原生实现，使用多Host模式合并部署。\n多Biz共用tomcat实例 针对第一个问题——多个Biz要共用tomcat实例，sofa-ark定义了EmbeddedServerService接口，插件web-ark-plugin里包含了接口的实现EmbeddedServerServiceImpl，来持有公共tomcat实例。\npackage com.alipay.sofa.ark.web.embed.tomcat; //作为ark plugin导出 public class EmbeddedServerServiceImpl implements EmbeddedServerService\u0026amp;lt;Tomcat\u0026amp;gt; { //共享tomcat private Tomcat tomcat; private Object lock = new Object(); @Override public Tomcat getEmbedServer() { return tomcat; } @Override public void setEmbedServer(Tomcat tomcat) { if (this.tomcat == null) { //通过加锁，避免多Web Biz并发启动加载时重复创建tomcat实例 synchronized (lock) { if (this.tomcat == null) { this.tomcat = tomcat; } } } } } 如果Biz引入了web-ark-plugin，则在ArkTomcatServletWebServerFactory中注入EmbeddedServerServiceImpl，持有最先初始化的Web Biz创建的Tomcat实例(TomcatWebServer的核心)，并在后续初始化的其它Biz调用getWebServer获取tomcat实例时，返回持有的同一个实例，以此来保证多个Biz运行在同一个tomcat中。\npackage com.alipay.sofa.ark.springboot.web; //每个Web Biz启动中都会创建一 …","date":1655362800,"description":"SOFAArk 源码解析-多 Web 应用合并部署","dir":"projects/sofa-boot/sofa-ark-multi-web-component-deploy/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e279d4b44741b8b88e22bf6420d8b5a6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","publishdate":"2022-06-16T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","summary":"背景 原生springboot-web应用部署流程 两种合并部署模式 支持单Host合并部署的关键点 多Biz共用tomcat实例 多Biz接口区分 总","tags":["“源码解析”"],"title":"SOFAArk 源码解析-多 Web 应用合并部署","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","wordcount":3703},{"author":"林楠","categories":"SOFAStack","content":" 前言 spring-boot-starter-actuator模块为 Spring Boot 应用提供了监控能力，内置一系列健康指标，如数据源、磁盘空间等，并且允许开发者自定义健康指标。Spring Boot 提供 health 端点，将所有健康指标聚合，当应用中有一个组件状态异常，那么应用的整体状态视为down，开发者可以访问 health 端点来了解应用当前的运行状况。\n SOFABoot 基于 actuator 模块扩展了健康指标，为应用提供 SOFA 组件的健康检查能力。同时，在 Spring Boot 原生的健康检查能力基础之上，增加了 Readiness Check 的能力。在这里我们做一个区分，Spring Boot 原生的健康检查称为 Liveness Check，SOFABoot 增加的健康检查称为 Readiness Check。Liveness Check 关注应用运行是否正常，如果 Liveness 状态异常，表示这个应用已经无法对外提供服务；Readiness Check 则关注的是应用有没有启动完成，是否进入“准备就绪”状态，能否对外提供服务。\n Readiness Check 只在应用启动阶段执行一次，通过请求 readiness 端点获取就绪状态，准备就绪后流量将进入应用。Readiness Check 完成后，多次请求 readiness 端点，不会重新发起检查。因此，在运行阶段应使用 Liveness Check 检查应用健康情况。\n 总体流程 在介绍总体流程前，先看一下 SOFABoot 健康检查机制中的一些重要接口：\n 接口类 说明 org.springframework.boot.actuate.health.HealthIndicator Spring Boot 原生的健康检查接口，想要新增一个自定义健康指标，可以直接扩展此接口 com.alipay.sofa.healthcheck.core.HealthChecker SOFABoot 提供的健康检查接口，相比 HealthIndicator 接口，增加了一些扩展参数，如失败重试次数，超时时间等 com.alipay.sofa.boot.health.NonReadinessCheck SOFABoot 默认会将所有 HealthIndicator 和 HealthChecker 纳入 Readiness Check 中，可以实现该接口将指标项标记为不参与 Readiness Check com.alipay.sofa.healthcheck.startup.ReadinessCheckCallback SOFABoot在 Readiness Check 之后会回调这个接口，如果想要在健康检查后做一些处理，可以直接扩展此接口 SOFABoot 的健康检查是基于 Spring 事件机制实现的，核心是 com.alipay.sofa.healthcheck.ReadinessCheckListener。ReadinessCheckListener 类实现了 GenericApplicationListener 接口，并监听 ContextRefreshedEvent事件，当 Spring 上下文刷新时触发健康检查流程：\npublic void onContextRefreshedEvent(ContextRefreshedEvent event) { if (applicationContext.equals(event.getApplicationContext())) { healthCheckerProcessor.init(); healthIndicatorProcessor.init(); afterReadinessCheckCallbackProcessor.init(); readinessHealthCheck(); readinessCheckFinish = true; } } 初始化 HealthCheckerProcessor：在 Spring 上下文中查找所有 HealthChecker 类型的 Bean； 初始化 HealthIndicatorProcessor：在 Spring 上下文中查找所有 HealthIndicator 类型的 Bean，并排除掉不参与 Readiness Check 的Bean。默认会排除 NonReadinessCheck 类型的 Bean，还可以通过参数com.alipay.sofa.boot.excludedIndicators 配置要排除的类型； 初始化 AfterReadinessCheckCallbackProcessor：在 Spring 上下文中查找所有 ReadinessCheckCallback 类型的 Bean ； 执行 Readiness Check 从上文中可以看出，readinessHealthCheck 方法是 Readiness Check 的入口：\npublic void readinessHealthCheck() { ...... healthCheckerStatus = healthCheckerProcessor .readinessHealthCheck(healthCheckerDetails); ...... healthIndicatorStatus = healthIndicatorProcessor .readinessHealthCheck(healthIndicatorDetails); ...... if (healthCheckerStatus \u0026amp;amp;\u0026amp;amp; healthIndicatorStatus) { ...... healthCallbackStatus = afterReadinessCheckCallbackProcessor .afterReadinessCheckCallback(healthCallbackDetails); } determineReadinessState(); } Readiness Check 的主要流程是依次执行 HealthChecker 和 HealthIndicator 的检查，如果所有健康指标状态均正常，才会执行ReadinessCheckCallback 回调。最后聚合所有指标状态，判断应用是否准备就绪。 健康检查的核心逻辑就在三个处理器HealthCheckerProcessor、HealthIndicatorProcessor和AfterReadinessCheckCallbackProcessor中，接下来我们依次分析一下。\nHealthCheckerProcessor 首先看一下 HealthChecker 接口为开发者提了哪些方法：\n 方法签名 说明 Health isHealthy() 指标项检查，返回值标识指标项状态是否正常 String getComponentName() 指标项名称 int getRetryCount() 失败重试次 …","date":1655276400,"description":"源码解析 | SOFABoot HealthCheck 机制解析","dir":"projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"33693ca9474cc5e3a509fca7935b1cbb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","publishdate":"2022-06-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","summary":"前言 spring-boot-starter-actuator模块为 Spring Boot 应用提供了监控能力，内置一系列健康指标，如数据源、磁盘空间等，并且允许","tags":["“源码解析”"],"title":"源码解析：SOFABoot HealthCheck 机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","wordcount":5393},{"author":null,"categories":"SOFAStack","content":" 文｜严松（花名：井守）\nNydus 镜像开源项目 Maintainer蚂蚁集团技术专家\n蚂蚁集团基础设施研发，专注云原生镜像与容器运行时生态\n本文 7060 字 阅读 15 分钟\n｜前言｜ 容器镜像是云原生的基础设施之一，作为容器运行时文件系统视图基础，从它诞生到现在，衍生出了镜像构建、存储、分发到运行时的整个镜像生命周期的各种生态。\n然而，虽然镜像生态众多，但自它诞生以来，镜像设计本身并没有多少改进。这篇文章要探讨的就是对容器镜像未来发展的一些思考，以及 Nydus 容器镜像的探索和实践。\n读完这篇文章，你能够了解到：\n- 容器镜像的基本原理，以及它的组成格式；\n- 目前的镜像设计有哪些问题，应该如何改进；\n- Nydus 容器镜像做了哪些探索，以及怎么实践。\nPART. 1 容器镜像 OCI 容器镜像规范 容器提供给了应用一个快速、轻量且有着基本隔离环境的运行时，而镜像提供给了容器 RootFS，也就是容器内能看到的整个 Filesystem 视图，其中至少包括了文件目录树结构、文件元数据以及数据部分。镜像的特点如下：\n- 易于传输，例如通过网络以 HTTP 的方式从 Registry 上传或下载；\n- 易于存储，例如可以打包成 Tar Gzip 格式，存储在 Registry 上；\n- 具备不可变特性，整个镜像有一个唯一 Hash，只要镜像内容发生变化，镜像 Hash 也会被改变。\n早期的镜像格式是由 Docker 设计的，经历了从 Image Manifest V1[1]、V2 Scheme 1[2]到 V2 Scheme 2[3]的演进。后来出现了诸如 CoreOS 推出的其他容器运行时后，为了避免竞争和生态混乱，OCI 标准化社区成立。它定义了容器在运行时、镜像以及分发相关的实现标准，我们目前用的镜像格式基本都是 OCI 兼容的。\n镜像主要是由镜像层和容器配置两大部分组成的。\n什么是镜像层？\n可以回想下平时写的 Dockerfile 文件：每条 ADD、COPY、RUN 指令都可能会产生新的镜像层，新层包含的是在旧层的基础上，新增加或修改的文件 （包含元数据和数据） ，或被删除的文件 （用称之为  Whiteout **[4] 的特殊文件表示删除） 。\n所以简单来说镜像的每一层存储的是 Lower 与 Upper 之间的 Diff，非常类似 Git Commit。这层 Diff 通常会被压缩成 Tar Gzip 格式后上传到 Registry。\n在运行时，所有 Diff 堆叠起来后，就组成了提供给容器的整个文件系统视图，也就是 RootFS。镜像的另外一部分是容器运行时配置，这部分包含了命令、环境变量、端口等信息。\n镜像层和运行时配置各自有一个唯一 Hash （通常是 SHA256） ，这些 Hash 会被写进一个叫 Manifest[5]的 JSON 文件里，在 Pull 镜像时实际就是先拉取 Manifest 文件，然后再根据 Hash 去 Registry 拉取对应的镜像层/容器运行时配置。\n目前的镜像设计问题 第一，我们注意到镜像层需要全部堆叠后，容器才能看到整个文件系统视图，所以容器需要等到镜像的每一层都下载并解压之后才能启动。有一篇 FAST 论文研究分析[6]说镜像拉取占了大约容器 76% 的启动时间，但却只有 6.4% 的数据是会被容器读取的。这个结果很有趣，它激发了我们可以通过按需加载的方式来提高容器启动速度。另外，在层数较多的情况下，运行时也会有 Overlay 堆叠的开销。\n第二，每层镜像是由元数据和数据组成的，那么这就导致某层镜像中只要有一个文件元数据发生变化，例如修改了权限位，就会导致层的 Hash 发生变化，然后导致整个镜像层需要被重新存储，或重新下载。\n第三，假如某个文件在 Upper 层里被删除或者被修改，旧版本文件依然留存在 Lower 层里不会被删除。在拉取新镜像时，旧版本还是会被下载和解压，但实际上这些文件是容器不再需要的了。当然我们可以认为这是因为镜像优化做的不够好，但在复杂场景下却很难避免出现这样的问题。\n第四，镜像 Hash 能够保证镜像在上传和下载时候的不可变，但在镜像被解压落盘后，很难保证运行时数据不被篡改，这也就意味着运行时的数据是不可信的。\n第五，镜像是以层为基本存储单位，数据去重是通过层的 Hash，这也导致了数据去重的粒度较粗。从整个 Registry 存储上看，镜像中的层与层之间，镜像与镜像之间存在大量重复数据，占用了存储和传输成本。\n镜像设计应该如何改进 我们看到了 OCI 镜像设计的诸多问题，在大规模集群场景下，存储与网络负载压力会被放大，这些问题的影响尤为明显，因此镜像设计急需从格式、构建、分发、运行、安全等各方面做优化。\n首先，我们需要实现按需加载。 在容器启动时，容器内业务 IO 请求了哪些文件的数据，我们再从远端 Registry 拉取这些数据，通过这种方式，可以避免镜像大量数据拉取阻塞容器的启动。\n其次，我们需要用一个索引文件记录某个文件的数据块在层的 Offset 偏移位置。 因为现在的问题是，Tar 格式是不可寻址的，也就是说需要某个文件时，只能从头顺序读取整个 Tar 流才能找到这部分数据，那么我们自然就想到了可以用这种方式来实现。\n接着，我们改造层的格式以支持更简单的寻址。 由于 Tar 是会被 Gzip 压缩的，这导致了就算知道 Offset 也比较难 Unzip。\n我们让原来的镜像层只存储文件的数据部分 （也就是图中的 Blob 层） 。Blob 层存储的是文件数据的切块 （Chunk） ，例如将一个 10MB 的文件，切割成 10 个 1MB 的块。这样的好处是我们可以将 Chunk 的 Offset 记录在一个索引中，容器在请求文件的部分数据时，我们可以只从远端 Registry 拉取需要的一部分 Chunks，如此一来节省不必要的网络开销。\n另外，按 Chunk 切割的另外一个优势是细化了去重粒度，Chunk 级别的去重让层与层之间，镜像与镜像之间共享数据更容易。\n最后，我们将元数据和数据分离 。 这样可以避免出现因元数据更新导致的数据层更新的情况，通过这种方式来节省存储和传输成本。\n元数据和 Chunk 的索引加在一起，就组成了上图中的 Meta 层，它是所有镜像层堆叠后容器能看到的整个 Filesystem 结构，包含目录树结构，文件元数据，Chunk 信息等。\n另外，Meta 层包含了 Hash 树以及 Chunk 数据块的 Hash，以此来保证我们可以在运行时对整颗文件树校验，以及针对某个 Chunk 数据块做校验，并且可以对整个 Meta 层签名，以保证运行时数据被篡改后依然能够被检查出来。\n如上所述，我们在 Nydus 镜像格式中引入了这些特性，总结下来如下：\n- 镜像元数据和数据分离，用户态按需加载与解压；\n- 更细粒度的块级别数据切割与去重；\n- 扁平化元数据层 （移除中间层） ，直接呈现 Filesystem 视图；\n- 端到端的文件系统元数据树与数据校验。\nPART. 2 Nydus 解决方案 镜像加速框架 Nydus 镜像加速框架是 Dragonfly[7] …","date":1655190000,"description":"容器镜像是云原生的基础设施之一，虽然镜像生态众多，但自它诞生以来，镜像设计本身并没有多少改进。这篇文章要探讨的就是对容器镜像未来发展的一些思考，以及 Nydus 容器镜像的探索和实践。","dir":"blog/nydus-exploratory-practice-of-next-generation-container-images/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"66c30936f5c0aa0e2bdf61ffdb88288e","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","publishdate":"2022-06-14T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","summary":"文｜严松（花名：井守） Nydus 镜像开源项目 Maintainer蚂蚁集团技术专家 蚂蚁集团基础设施研发，专注云原生镜像与容器运行时生态 本文 7060 字 阅读 15 分","tags":["SOFAStack"],"title":"Nydus —— 下一代容器镜像的探索实践","type":"blog","url":"/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","wordcount":8779},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@有时候 提问：\n SOFARPC 注册服务和订阅服务用到的 interface，Java 类文件内容是一样的，但如果包路径不是完全一样有问题么？\n A：路径不一样就是不同接口，注册中心不感知到 method 这层。dataid 不一样的，https://www.sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/ 。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n2.@啥也不是 提问：\n 大佬们，在现有协议拓展框架下，在 choose host 以后根据节点信息动态选择上游的协议，实现起来感觉不是很方便，有大佬指点一下吗？\n A：你是上下游协议不一样吗？\n 是的，而且同一个集群里面协议也可能不一样。我们自己的 RPC 协议存在多个版本，上下游的版本我们没办法控制，想着每个版本分别作为一种协议，利用框架能力，让协议版本的选择跟序列化解偶，每个 host 的版本是通过我们自己配置中心获取的。cluster 中 host 协议版本不受我们控制。\n A：Upstream 的协议本来就是在 filter 里面转换，你在 choose host 之后进行 filter 设置就行了。这个是一个协议转换框架 filter，根据配置的协议转换，你可以复用这个，区别就是 upstream 的协议是动态指定的，但没有本质区别：https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ftranscoder\n「MOSN」https://github.com/mosn/mosn\n3.@曹飞 提问：\n 大佬，监控指标可以显示到应用维度吗？ A：Metric 可以自定义输出的。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 ID API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 Wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 蚂蚁集团获得 OpenInfra Superuser 2022 年度大奖！\n KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境\n 如何看待 Dapr、Layotto 这种多运行时架构？\n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers！\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1654844400,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220610/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2b864568ab02c9da5090b213d0ff984a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220610/","publishdate":"2022-06-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220610/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220610/","wordcount":1483},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#28:SOFAArk 类隔离框架设计\n 活动时间：06 月 09 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#28 SOFAArk 类隔离框架设计 SOFAArk 是一款基于 Java 实现的轻量级类隔离框架，主要提供类隔离、动态部署、合并部署能力。本次分享将用 30 分钟的时间，带你深入 SOFAArk 框架，一起剖析其技术背景及设计思想，并展望其未来的发展趋势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 张冯君（花名：远远）\n 蚂蚁集团开发工程师\n 负责蚂蚁集团 SOFAArk 框架方向的相关工作\n 议程 直播回放 https://www.bilibili.com/video/BV1gS4y1i7Fg/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1654758000,"description":"2022 年 6 月 09 日 19：00 - 20：00 ，线上直播第 28 期。","dir":"activities/sofa-channel-28/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bfe5796985a7bfb85eb7b19614b05a57","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-28/","publishdate":"2022-06-09T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-28/","summary":"概要 活动主题：SOFAChannel#28:SOFAArk 类隔离框架设计 活动时间：06 月 09 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B","tags":["SOFAChannel","SOFAArk","类隔离框架"],"title":"SOFAChannel#28 SOFAArk 类隔离框架设计","type":"activities","url":"/sofastack.tech/activities/sofa-channel-28/","wordcount":452},{"author":null,"categories":"SOFAStack","content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团高级技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n本文 2580 字 阅读 6 分钟\n｜前言｜ 本文撰写于 KusionStack 开源前夕，作者有感而发，回顾了团队从 Kusion 项目开发之初到现今成功走上开源之路的艰辛历程。当中既描述了作者及其团队做 Kusion 项目的初心和项目发展至今的成果，也表达了作者自身对团队的由衷感激，字里行间都散发着真情实感。\nKusionStack 是什么？\nKusionStack 是开源的可编程云原生协议栈！\nKusion 一词来源于 fusion （意为融合） ，希望通过一站式的技术栈融合运维体系的多个角色，提升运维基础设施的开放性、扩展性，从整体上降本增效。KusionStack 通过定义云原生可编程接入层，提供包括配置语言 KCL、模型界面、自动化工具、最佳实践在内的一整套解决方案，连通云原生基础设施与业务应用，连接定义和使用基础设施的各个团队，串联应用生命周期的研发、测试、集成、发布各个阶段，服务于云原生自动化系统建设，加速云原生落地。\nPART. 1 为了一个理想的运维体系 2019 年秋，MOSN 的工作已持续了近两年，期间我们逐步完成了在支付宝核心链路的形态验证。整个过程中除了 MOSN 本身面对的种种技术挑战和困难，所谓的云原生技术红利，实际上也已经掣肘于运维系统固化所造成的效率制约。\n有一天主管找我吃饭 （下套） ，期间向我描述了他理想中的运维体系：\n他希望 SRE 能通过一种专用语言来编写需求，通过写代码来定义基础设施的状态，而不是花费极大的精力在检查、发现、修复的循环上。基础设施团队则通过提供开放的可编程语言和工具支撑不同诉求的 SRE 团队，达到更高的整体 ROI。\n我立刻意识到这和 Hashicorp 的 Terraform 神之相似 （后来 Hashicorp 在 2021 年底上市，以超过 150 亿美元的市值成为迄今为止市值最高的一次开源 IPO） 。另一方面，不同于 IaaS 交付场景，蚂蚁面对着大量更规模化、复杂度更高的云原生 PaaS 场景，又让我想到了 Google 内部运用专用语言、工具等技术开放 Borg[1]运维能力的实践[2]，当时感觉这是一个既有意思又有挑战的事[3]。\n饭桌上我们聊了一些思路以及一些还不太确定的挑战，他问我想不想搞一个试试，搞不成也没关系。当时没想太多，饭没吃完就答应了。\nPART. 2 漫长的学习、探索与实践 隔行如隔山。\n没有过语言设计研发的经验，也没有过开放自动化系统设计的经验，项目开展之初，我们就陷入了举步维艰的困境。\n经历了一段漫长时间的学习、摸索和实践的反复循环之后，项目依旧没有大的起色，更困难的是我们不但要面对蚂蚁内部复杂又耦合的场景和问题，还要经受「这种高度工程化的方式在蚂蚁是否有生存土壤」的质疑。\n屋漏偏逢连夜雨，期间又令人惋惜且无奈的经历了一些人事变化，同时由于种种原因，项目一度陷入了各种困境。整个 2020 年，我们在未知、纠结、无奈中度过……\n感谢瓴熙、庭坚和我的主管，感谢你们当时没有放弃这个项目，依然与我一同坚守。\nPART. 3 痛并快乐的孵化之旅 通过持续地布道、交流和沟通，我们逐步在基础设施技术团队和 SRE 团队找到了更多有共识的朋友。\n同时在技术上，我们亦脱离了迷茫，真正意义上地启动了 Kusion 项目，也成功地从 PoC 过渡到了 MVP 的阶段。\n最终，我们以“非标”应用为切入点，开始了痛并快乐着的孵化之旅。\n感谢零执、青河、子波、李丰、毋涯、向野、达远……在这里无法一一列举，感谢你们的坚持让这个想法逐步成为现实。\nPART. 4 突破与进展 略过中间的种种探索和实践，回顾这段历程，在这一年多的时间里我们结合了编译技术、运维及平台技术，成功建立了一个基于 Kusion 可编程技术栈的运维体系。\n在业务场景上，项目覆盖了从 IaaS 到 SaaS 的大量运维场景，截至目前共接入了 800+ 应用，覆盖 9 个 BG，21 个 BU，其中典型案例交付运维提效 90% 以上，这也是蚂蚁内部第一次将大量异构应用纳入到一整套运维技术栈。\n在蚂蚁我们基于云原生容器和微服务技术深入探索了 DevOps、CICD 实践，完善了蚂蚁的云原生技术体系，逐步释放了云原生效率红利，同时形成了一个近 300 人的虚拟运维研发团队。\n不同职能不同团队的参与者凝聚在一起解决各自所面对的问题，贡献了 3W+ commit 和 35W+ 行代码，有一些参与者自发成为 Kusion 的研发者 。我认为这些工程师文化理念和领域知识的积累带来了远超运维业务本身的价值。\n此外，Kusion 也成为了可编程基线产品、云原生运维产品、多云交付产品等新一代运维产品的基础技术，成为蚂蚁运维体系架构升级的一部分。\n不忘初心，我们希望通过技术手段促进与运维参与方的合作关系的合理化、基于开放技术栈的自动化，以及运维数据与知识的沉淀积累，以达到整体协作运维效率的不断提升。\n同时，因蚂蚁内部运维场景较多且链路复杂，每个环节都需要最懂运维业务的 SRE 密切参与，与平台、应用研发协同工作，最终各环节联合在一起形成了一套完整的运维体系，在这样的思路下开放技术也会越来越重要。\n平台研发、SRE、应用研发等多种角色协同编写的代码是一种数据的沉淀，亦是一种业务知识的沉淀，基于这些数据和知识，未来会有更多的可能性。\nPART. 5 走上开源之路 在历经了一段内部探索之后，我们希望把 KusionStack 开源到技术社区。因为我们意识到自身面对的问题，其他公司、团队其实也同样正在面对。借助开源这件事，我们希望团队的这些工作成果能对更多人有所帮助。\n当然，也受限于自身能力以及精力和资源的投入，我们希望能有更多朋友参与进来，与我们共同去完善 KusionStack，不论你是工作在云原生、运维自动化、编程语言或者是编译器中的哪一个领域，我们都非常期待和欢迎你的加入。\nPART. 6 期待与你共成长 这段经历对我来说异常宝贵，不仅仅是在于自身再一次在新的技术领域和蚂蚁的技术升级方面尝试了新的探索并实现了突破，更宝贵的是，自己还拥有了一段与一群人均 95 后的小伙伴一起将想法落地实现的奇幻历程。\n在未来， Kusion 的朋友圈不再局限于蚂蚁内部，面向开源，我们期待着能有更多的社区朋友在 KusionStack 与我们共同成长！\n了解更多\u0026amp;hellip;\nKusionStack Star 一下✨：\nhttps://github.com/KusionStack\nKusionStack 的开源，希望能对大家有所帮助，也希望能跟更多朋友共同完善 KusionStack。欢迎对云原生、运维自动化、编程语言、编译器感兴趣的同学一起参与社区共建，在新的技术领域升级方面进行探索和突破，实现更多新的想法。\n点击文末阅读原文直达项目地址。\n【参考链接】\n[1]《Large-scale cluster management at Google with …","date":1654585200,"description":"KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境","dir":"blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"688d35ea65772596c3a0115a62a63b53","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","publishdate":"2022-06-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","summary":"文｜朵晓东（花名：奕杉 ) KusionStack 负责人、蚂蚁集团高级技术专家 在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作 本文 2580 字 阅读 6 分钟 ｜前","tags":["SOFAStack"],"title":"KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境","type":"blog","url":"/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","wordcount":2772},{"author":"周群力","categories":"SOFAStack","content":" 文｜周群力（花名：仪式 )\nLayotto PMC；Layotto 和 SOFAStack 开源社区的建设，Dapr 贡献者，Dapr sig-api 的 Co-chair\n本文 10963 字 阅读 20 分钟\n2019 年，微软开源了 Dapr 项目。2021 年，蚂蚁参照 Dapr 思想开源了 Layotto 项目。如今，蚂蚁已落地 Layotto，服务了很多应用。从理想落地到现实的过程中，我们遇到了不少问题，也对项目做了很多改变。回过头再看，如何看待 Dapr、Layotto 这种多运行时架构？我们能从中学到什么？\n本次我将从以下几个方面，分享蚂蚁在落地多运行时架构之后的思考：\n1. 如何看待“可移植性”\n2. 多运行时架构能带来哪些价值\n3. 与 Service Mesh、Event Mesh 的区别\n4. 如何看待不同的部署形态\nPART. 1 快速回顾\n如果你熟悉 Multi-Runtime、Dapr 和 Layotto 的概念，可以跳过这一章节，直接进入下一章节。\n快速回顾：什么是 Multi-Runtime 架构？\nMulti-Runtime 是一种服务端架构思路，如果用一句话来概括，就是把应用里的所有中间件挪到 Sidecar 里，使得“业务运行时”和“技术运行时”分离开。\n更详细的解释如下：首先来看 Service Mesh，和传统 RPC 框架相比，Service Mesh 的创新之处在于引入了 Sidecar 模式。Service Mesh 只解决了服务间通讯的需求，而现实中的分布式应用存在更多需求，比如“协议转换”、“状态管理”等。Multi-Runtime 架构提出将各种各样的分布式能力外移到独立 Runtime，最后和应用 Runtime 共同组成微服务，形成所谓的“Multi-Runtime” （多运行时） 架构。\n具体细节可以详阅《Multi-Runtime Microservices Architecture》和《Mecha：将 Mesh 进行到底》。\n哪些项目实现了 Multi-Runtime 架构？\nDapr\nDapr 的全称是“Distributed Application Runtime”，即“分布式应用运行时”，是一个由微软发起的开源项目。\nDapr 项目是业界第一个 Multi-Runtime 实践项目，Dapr 的 Sidecar，除了可以和 Service Mesh 一样支持服务间通讯，还可以支持更多的功能，如 state （状态管理） 、pub-sub （消息通讯） ，resource binding （资源绑定，包括输入和输出） 。Dapr 将每种功能抽象出标准化的 API （如 state API） ，每个 API 都有多种实现，比如用户可以面向 state API 编程，但是可以随意切换存储组件，今年用 Redis，明年改成用 MongoDB，业务代码不用改。\n如果之前没有接触过 Dapr，更详细的介绍可以阅读《Dapr v1.0 展望：从 Service Mesh 到云原生》这篇文章。\nLayotto\nLayotto 是由蚂蚁集团 2021 年开源的一个实现 Multi-Runtime 架构的项目，核心思想是在 Service Mesh 的数据面（MOSN里支持 Dapr API 和 WebAssembly 运行时，实现一个 Sidecar 同时作为 Service Mesh 数据面、多运行时 Runtime、FaaS 运行时。项目地址为：https://github.com/mosn/layotto\n以上是本文背景，接下来是本次主题分享。\nPART. 2 你真的需要这种“可移植性”吗？\n社区比较关注 Dapr API 的“可移植性”，但在落地过程中，我们不禁反思：你真的需要这种“可移植性”吗？\n标准化 API 能满足所有需求吗？\n数据库领域曾出现过一个有趣的讨论：同一个数据库能否适用于所有场景，满足所有需求？ 比如，一个数据库能否同时支持 OLAP+OLTP+ACID 等等需求？\n今天，我们在建设 Dapr API 的过程中也遇到了有趣的问题：在某个产品领域 （比如消息队列） ，能否定义一套“标准 API”同时适用于所有的消息队列？\n当然，这两个问题不能混为一谈：即使是两种不同类型的数据库，比如两个数据库，一个只做 OLAP，另一个只做 OLTP，它们都可以支持 SQL 协议。两个差距那么大的数据库都能用同样的协议，我们有理由相信：在特定领域，设计一个适用于所有产品的“标准 API”是可行的。\n可行，但现在还不完全行。\n现在的 Dapr API 还比较简单，简单场景足以胜任，但在复杂的业务场景下，做不到“帮助应用 Write once,run on any cloud”。对这个问题，敖小剑老师的文章《死生之地不可不察：论 API 标准化对 Dapr 的重要性》有过详细描述，大意是说：\n现在的 Dapr API 比较简单，在生产落地的时候满足不了复杂需求，于是开发者只能添加很多自定义的扩展字段，在 Sidecar 的组件里做特殊处理。比如下面是用 State API 时候的一些自定义扩展字段：\n（图片摘自敖小剑老师的文章）\n这些自定义的扩展字段会破坏可移植性：如果你换一个组件，新组件肯定不认识这些字段，所以你得改代码。\n之所以出现这个问题，背后的根本原因是 Dapr API 的设计哲学。\n社区在设计 Dapr API 时，为了可移植性，设计出的 API 倾向于 “功能交集” 。比如在设计 Configuration API 时，会考察各种配置中心 A、B、C，如果 A、B、C 都有同一个功能，那么这个功能才会出现在 Dapr API 中：\n然而，在现实世界中，人们的需求可能是 A 和 B 的交集，B 和 C 的交集 （如下图红色部分） ，而不是 A、B、C 的交集：\n或者更常见，用户的需求是“B 的所有功能”，其中必然包括一些 B 独有的功能，Dapr API 无法覆盖：\nDapr 提供“标准 API”、“语言 SDK”和“Runtime”，需要应用进行适配 （这意味着老应用需要进行改造） ，侵入性比较大。\n因此 Dapr 更适合新应用开发 （所谓 Green Field） ，对于现有的老应用 （所谓 Brown Field） 则需要付出较高的改造代价。但在付出这些代价之后，Dapr 就可以提供跨云跨平台的可移植性，这是 Dapr 的核心价值之一。\n这些听起来是解决不了的问题。那怎么办？\n跨云部署时，你真的需要从 Redis 换成 Memcached 吗？\n在设计 API 时，常常出现类似的讨论：\nA：嘿，这个功能只有 Redis 和 xxx 有，但是 Memcached 和其他存储系统没有。我们该怎么办，要不要把这个功能纳入 API 规范里？\nB：如果我们把这个功能纳入 API 里，会有什么问题？\nA：那样的话，使用我们 API 的用户就没法从 Redis 迁移到 Memcached 了，这破坏了可移植性！\n等一等……你真的需要从 Redis 换成 Memcached 吗？\n你真的需要这种“可移植性”吗？\n不需要吧！如果 …","date":1653980400,"description":"本文讨论了 Layotto 落地之后，关于 Multi-Runtime 架构“可移植性”、落地价值以及部署形态等方面的思考。","dir":"blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","fuzzywordcount":9200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d0732e32f9b202c205fb1e03b195eb8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","publishdate":"2022-05-31T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","summary":"文｜周群力（花名：仪式 ) Layotto PMC；Layotto 和 SOFAStack 开源社区的建设，Dapr 贡献者，Dapr sig-api 的 Co-chair 本文 10963 字 阅读 20 分钟 2019 年，微软开源了 Dapr 项目。","tags":["SOFAStack"],"title":"如何看待 Dapr、Layotto 这种多运行时架构","type":"blog","url":"/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","wordcount":9182},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@周衡 提问：\n 请问一下，我需要调度 RPC 的上下文是哪一个类？有一些参数想直接通过上下文传递。\n A：RpcInvokeContextv6\n「SOFARegistry」：https://github.com/sofastack/sofa-rpc\n@bobtthp 提问：\n MOSN 对接 dubbo 目前注册中心支持 zk 吗？\n A：FaaS 示例么？那个还没上过生产，还在探索阶段。支持的，可以参考这个文档：https://www.github.com/mosn/mosn/tree/master/pkg%2Fupstream%2Fservicediscovery%2Fdubbod%2Fcommon.go\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n 深入 HTTP/3（2）｜不那么 Boring 的 SSL\n 【2022 开源之夏】欢迎报名 MOSN 社区项目！\n 蚂蚁集团 Service Mesh 进展回顾与展望\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1653634800,"description":"SOFA Weekly | Kusion 开源啦、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220527/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1f1971d6ef1280f9bc0fa21d099dfd99","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220527/","publishdate":"2022-05-27T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220527/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | Kusion 开源啦、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220527/","wordcount":1025},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#27:深入 HTTP/3｜从QUIC-TLS 看协议的安全设计\n 活动时间：05 月 26 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#27 深入 HTTP/3｜从 QUIC-TLS 看协议的安全设计 安全通信是网络技术中绕不开的话题，而 QUIC 作为目前炙手可热的协议技术，在这上面也理所应当的有着非常多的优秀实践，本次分享将用 50 分钟的时间，带你深入 QUIC-TLS，一起剖析其技术背景及设计思想，并展望其未来的发展趋势。\n当然，本次直播也分享一些蚂蚁自己的工程实践经验及相关的产品。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 曾柯（花名：毅丝）\n 蚂蚁集团高级工程师\n 负责蚂蚁集团的接入层建设工作，主要方向为高性能安全网络协议的设计及优化\n 议程 直播回放 https://www.bilibili.com/video/BV1xg411o7Jo/\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1653634800,"description":"2022 年 5 月 26 日 19：00 - 20：00 ，线上直播第 27 期。","dir":"activities/sofa-channel-27/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cdb2bb81c619db029bb9a62a1374b721","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-27/","publishdate":"2022-05-27T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-27/","summary":"概要 活动主题：SOFAChannel#27:深入 HTTP/3｜从QUIC-TLS 看协议的安全设计 活动时间：05 月 26 日，周四晚 19 点 活动形式：线","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#27 深入 HTTP/3｜从 QUIC-TLS 看协议的安全设计","type":"activities","url":"/sofastack.tech/activities/sofa-channel-27/","wordcount":543},{"author":"曾柯","categories":"SOFAStack","content":" 文｜曾柯（花名：毅丝 )\n蚂蚁集团高级工程师*负责蚂蚁集团的接入层建设工作* 主要方向为高性能安全网络协议的设计及优化\n本文 10924 字，阅读 20 分钟\nPART. 1 引言 从前一篇文章《深入 HTTP/3（1）｜从 QUIC 链接的建立与关闭看协议的演进》对于 QUIC 的浅述中我们了解到，QUIC 的优化很大程度上是一种基于 TLS 流程的优化，由此也可见 TLS 对于 QUIC 的重要性，那么今天我们就来聊一聊 QUIC-TLS。为了表述尽量没有歧义，我们先来规范下文章中各个术语的意义。\n本文目前既然已经提到了 SSL、TLS 这两个术语，我们不妨先来简短回顾下安全协议的发展史，这既可以帮我们理清两个术语的关系，也能帮助我们对这项技术的进化有一个简短的概念。\nSSL (Secure Sockets Layer) 协议本身是网景公司为了保证互联网上数据传输的安全性，在 1994 年设计的一套协议。这套协议在当时被广泛使用在各大浏览器上，但 SSL 协议最初的几个版本安全性都非常堪忧，初期的更迭非常频繁，从 1994 年到 1995 年连续迭代了 3 个大版本，而现在大家最耳熟能详的应该就是 SSLv3.0 了。可惜 SSLv3.0 也没有逃脱更迭的厄运，由于硬件算力的迭代，大量 SSLv3.0 中广泛使用的加密算法不再安全，并且协议交互流程也存在不安全之处。1999 年，IETF 正式介入安全协议的设计及开发，并推出了 TLS (Transport Layer Security) 协议的第一个版本 TLS1.0，随后 TLS 协议的发展开始变得迟缓，在 2006 年 IETF 组织推出了 TLS1.1，并在 2008 年再次发布了 TLS1.2，两个版本都是针对一些握手交互过程中的细节的安全提升，握手流程其实是没有大的变化的。\n直到 2013 年，Google 在推出 gquic 的同时，也推出了其设计的安全交互流程 quic-crypto，quic-crypto 是一次交互流程的重大创新，也以此成为了 TLS1.3 的前身。TLS1.3 从某种意义上来说，应该被称作 TLS2.0，因为其革新力度非常大，当然这也导致其标准化流程非常长，TLS1.3 的标准化整整历经了 4 年，直到 2018 年才正式成为 RFC。而 TLS1.3 本身也成为了 IETF-QUIC 的安全交互技术的基础，所以这条时间线里也揉杂了 QUIC-TLS 的设计历程，我们来简单理一下：\n图 1. TLS 发展简史\n当然 DTLS 等相关安全技术的进化也融合在这条时间线中，限于篇幅问题，这里暂时不表。说了这么多废话，我们现在来正式标准化一下我们的名词：\n【SSL、TLS】 ：在本文中都指安全传输协议，后续的文章中只会使用 TLS 作为相关技术的代名词\n【QUIC-crypto】 ：Google quic 中使用的握手流程，本文不对其进行具体分析\n【QUIC-TLS】 ：本文指 IETF-QUIC 使用的安全交互流程，即 RFC9001 中标准化的流程，也是本文详细描述的重点\n【PTO】 ：全称为 Probe Timeout，定义于 RFC9002 中，留待下一篇文章来对其进行详细分析，本文将其理解成一个通信端设置的针对报文的超时重传的时间即可\n【DTLS】 ：全称为 Datagram Transport Layer Security，即面向报文的 TLS 协议，限于篇幅的问题，本文并不详细对其分析，而 DTLS 中存在有很多和 QUIC-TLS 类似思路的设计，感兴趣的同学可以参见 RFC9147\n“make infrastructure boring”是 Google 一直以来的口号，BoringSSL 这个开源产品则是他们在安全通信领域的行动，而文章的标题既然叫“不那么 Boring 的 SSL”，除了蹭一蹭 BoringSSL 和 OpenSSL 这些著名的 SSL 开源项目的热度之外，也是想给文章制造一点悬念：Boring 往往意味着相关技术简单好用到了令人发指的地步，而 QUIC 到底遇见了什么问题，才让本身相对成熟的 TLS 协议用起来不再 Boring？\n本文后续也将围绕这个话题展开，来看看 QUIC-TLS 设计中那些值得玩味的地方。\nPART. 2 浅看 TLS 本着由浅入深的思路，在开始介绍 QUIC-TLS 之前，我们也先浅析一下 TLS，这也非常有助于我们后面对于 QUIC-TLS 的理解。\nTLS 协议从某种程度上来说解决了几个哲学问题：你是谁？你怎么证明你是你？\n当然这些问题的答案还不足以保证整个的安全\u0026amp;hellip;\n1. 我们还需要一种技术来保证中间人无法获取到我们的数据，这也就是我们相对比较熟悉的 「对称加密技术」，比如 AES、SM4 等加密技术；\n2. 为了加密的数据也能证明通信一端的身份，我们引入了 「AEAD 加密即认证的模式」；\n3. 为了协商出这种对称加密的密钥，TLS 引入了 「非对称密钥交换技术」，典型如 ECDHE、RSA 等密钥交换算法；\n4. 为了身份管理的统一及身份的有效携带，TLS 引入了 「数字证书技术」，包括整个 pki 公钥体系及 X509 数字证书标准；\n5. 为了数据的不可篡改，TLS 引入了 「数字签名技术」，典型如 ECDSA、RSA 等签名算法；\n6. 为了各个阶段的加密密钥独立及签名流程的简洁，TLS 引入了 「Hash 算法」，典型如 SHA 系列算法。\n上述的各种机制再整个 TLS 协议中被抽象为两部分协议：\n一层是 Handshake 协议，负责核心密钥的交互及身份认证；一层是 Record 协议，负责数据的安全，完整性及握手完成后数据的可信证明，而 Handshake 协议则坐落于 Record 协议之上，这也就形成了这样的协议栈。\n图 2. TLS 协议栈简图\n简而言之，Handshake 过程中的数据也依赖 Record 层来进行数据加密，而 Record 层加密的 key 则依赖 Handshake 层进行交互得到。这看似是个逻辑死锁，实际上是通过一个层层递进的状态机完成的，抛开繁琐的 TLS 状态机本身，这个流程基本可以用下图来表述：\n图 3. TLS 密钥状态更新流程图\n至于 TLS 的初始阶段使用明文传输的数据，也并不违背这个流程，我们可以将其理解为 TLS 初始阶段对应一个值为空的 key。而从上图中我们也可以看到，实现和虚线部分对应的两个阶段切换，必须有严格的先后顺序，如果发生乱序，一端是无法完成数据的解析的，所以 TLS 协议非常依赖底层传输协议来保证数据的有序到达，而这也是 TLS 的设计区别于 DTLS 和 QUIC-TLS 的最大根因之一。有了这部分知识储备，我们再来看 TLS 的握手 (以 TLS1.3 的 0-RTT 交互场景为例) ，就会清晰很多：\n图 4. TLS 握手流程图\n可以看到，明文\u0026amp;rdquo;()\u0026amp;ldquo;,\u0026amp;rdquo;{}\u0026amp;ldquo;,\u0026amp;rdquo;[]\u0026amp;ldquo;对应的加密状态的切换，和上面的图的流程基本是一致的，而典型如 EndOfEarlyData 这种标 …","date":1653375600,"description":"深入 HTTP/3（2）｜不那么 Boring 的 SSL","dir":"blog/deeperinto-http-3-2-the-not-so-boring-ssl/","fuzzywordcount":9500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e7a8be2c91c093af30cba5045b0b6516","permalink":"https://sofastack.github.io/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","publishdate":"2022-05-24T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","summary":"文｜曾柯（花名：毅丝 ) 蚂蚁集团高级工程师*负责蚂蚁集团的接入层建设工作* 主要方向为高性能安全网络协议的设计及优化 本文 10924 字，阅读 20 分钟 PART. 1 引言","tags":["SOFAStack"],"title":"深入 HTTP/3（2）｜不那么 Boring 的 SSL","type":"blog","url":"/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","wordcount":9435},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@林楠 提问：\n SOFARegistry 使用数据库做存储，未来有没有计划做一个简洁版，不依赖数据库？\n A：v6 使用存储主要是存放元数据而不是服务数据，元数据存储接口未来计划使用 jraft 作为存储。这也是 v5—\u0026amp;gt;v6 的过程中去掉的一个功能，因为在内部，引入 jraft 有一定运维成本，需要 operator 这种非标组件。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@jiaxin shan 提问：\n 想知道 Layotto 的成熟案例，有没有一些大公司进行使用呢？体量是多少？1.miscro-service 方向 2.FaaS 方向也有一些落地实例吗？\n A：目前蚂蚁在生产环境使用，另外也有某大厂准备上测试环境了。官网的 WASM 跑 FaaS 示例么？那个还没上过生产，还在探索阶段。\n 我理解目前像 FaaS、WASM 等更多是从社区角度，开源侧进行牵引，慢慢孵化一些场景？\n A：对，结合 WASM 做 FaaS 是开源社区探索方向；其他的 runtime、service mesh 属于生产需求驱动，更严肃一些。属于蚂蚁发起、社区共建，如果担心独裁，可以关注下 contributor 数、月活跃贡献者数这些指标，现在活跃贡献者有腾讯、同程等公司的朋友，3个 committor 都不是蚂蚁的。我们每周五有社区周会，你感兴趣可以来聊聊。钉钉群码：41585216\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 【2022 开源之夏】欢迎报名 SOFAStack 社区项目！\n 恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n 【2022 开源之夏】欢迎报名 MOSN 社区项目！\n 蚂蚁集团 Service Mesh 进展回顾与展望\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1653030000,"description":"SOFA Weekly | 我是开源人、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220520/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"27d18203e02fa487e39f1f9e1032271d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220520/","publishdate":"2022-05-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220520/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | 我是开源人、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220520/","wordcount":1274},{"author":"石建伟","categories":"SOFAStack","content":" 一、引言 继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么，值此 SOFAStack 开源 4 周年之际，欢迎大家一起进入《蚂蚁集团 Service Mesh 进展回顾与展望》章节探讨交流。\n本次交流将以如下次序展开：\n二、蚂蚁集团 Service Mesh 发展史 2018 年 3 月份蚂蚁集团的 Service Mesh 起步，MOSN 数据面诞生，起步就坚持走核心开源，内部能力走扩展的道路。 2019 年 6.18 我们在三大合并部署应用上接入了 MOSN 并且顺利支撑了 6.18 大促。 2019 年双 11 蚂蚁所有大促应用平稳的度过双大促。 2020 年 MOSN 对内沉稳发展把接入应用覆盖率提升至 90%，对外商业化开始展露头角。蚂蚁集团全站 90% 标准应用完成 Mesh 化接入。在商业版本中，SOFAStack“双模微服务”架构也在江西农信、中信银行等众多大型金融机构成功落地实践。 2021 年随着 Mesh 化的逐步成熟，多语言场景的逐步丰富，Mesh 化的对中间件协议的直接支撑带来的扩展性问题也逐步凸显，Dapr 的应用运行时概念也逐步崛起，这一年我们开源了 Layotto，期望通过对应用运行时 API 的统一来解决应用和后端中间件具体实现耦合的问题，进一步解耦应用和基础设施，解决应用在多云运行时的厂商绑定问题。 2022 年随着 Mesh 化落地的基础设施能力逐步完善，我们开始考虑 Mesh 化如果给业务带来更多价值，在 Mesh 1.0 时代，我们把中间件相关的能力尽可能做了下沉，提升了基础设施的迭代效率，在 Mesh 2.0 时代，我们期望能有一种机制可以让业务侧相对通用的能力，也可以做到按需下沉，并且具备一定的隔离性，避免下沉的能力影响 Mesh 数据代理主链路。这部分将在看未来部分做一些介绍。 图示的方式简诉一下 Service Mesh 架构演进的几个阶段：\n SOA 时代，中间件的客户端均直接集成在业务进程内： Mesh 化阶段一：中间件能力下沉，应用和基础设施实现部分解耦： 应用运行时阶段：将应用和具体基础设施的类型解耦，仅依赖标准 API 编程： 三、东西向流量规模化挑战 Mesh 化后的数据面 MOSN 承载了应用间非常核心的东西向通信链路，目前在蚂蚁集团内部覆盖应用数千，覆盖容器数十W+，海量的规模带来了如长连接膨胀、服务发现数据量巨大、服务治理困难等问题。接下来我们来聊一聊我们在演进的过程中遇到并解决掉的一些经典问题。\n3.1 长连接膨胀问题 在海量规模的应用背后存在着复杂的调用关系，部分基础性服务被大部分应用所依赖，由于调用方全连服务提供方的机制存在，一个基础性服务的单 Pod 需要日常承载近 10W 长连接，单机 QPS 一般还是有上限的，我们以 1000 QPS 的 Pod 举例，10w 长连接的场景下，每条长连接上的 QPS 是非常低的，假设所有连接的请求均等，平均每条长连接每 100s 仅有一次请求产生。\n为了保证长连接的可用性，SOFA RPC 的通信协议 Bolt 有定义心跳包，默认心跳包是 15s 一次，那么一条长连接上的请求分布大概如下图所示：\n在上诉场景中，一条长连接上，心跳包的请求数量远大于业务请求的数量，MOSN 在日常运行中，用于维护长连接可用句柄持有内存的开销，还有心跳包发送的 CPU 开销，在海量规模集群下不可忽视。\n基于以上问题，我们找到了两个解法：\n 在保证连接可用的前提下减少心跳频率 在保证负载均衡的前提下降低应用间的连接数 3.1.1 心跳退避 由于心跳的主要作用是尽可能早的发现长连接是否已不可用，通常我们认为经过 3 次心跳超时即可判定一条长连接不可用，在一条长连接的生命周期里，不可用的场景占比是非常低的，如果我们把长连接的检测周期拉长一倍就可以减少50%的心跳 CPU 损耗。为了保障检测的及时性，当出现心跳异常（如心跳超时等）场景时，再通过降低心跳周期来提高长连接不可用时的判定效率，基于以上思路我们设计了 MOSN 里的长连接心跳退避策略：\n 当长连接上无业务请求且心跳正常响应时，逐步将心跳周期拉长 15s -\u0026amp;gt; 90s 当长连接上出现请求失败或心跳超时的场景时，将心跳周期重置回 15s 当长连接上存在正常业务请求时，降级本次心跳周期内的心跳请求 通过以上心跳退避的手段，MOSN 的常态心跳 CPU 消耗降低至原来的 25%。\n3.1.2 服务列表分片 从心跳退避的优化可以看出，在海量长连接的场景下，单长连接上的请求频率是很低的，那么维护这么多长连接除了对负载均衡比较友好之外，其他的收益并不大，那么我们还有另外一个优化方向，就是减少客户端和服务端之间建立的长连接数量。\nMOSN 使用一致性哈希的策略对服务端机器进行分组：在客户端的内存中，首先将全量的服务端机器列表加入到一致性哈希环中，然后基于配置计算预期分片情况下的机器列表数 N，随后根据客户端机器 IP，从一致性哈希环中获取 N 个机器列表作为本机器的分片列表。每个客户端计算的哈希环都是一样的，不同的机器 IP 使得最终选择的机器分片列表是不同的。实现了不同客户端机器持有不同的服务端集群分片的效果。\n通过对服务列表的分片优化，客户端向服务端建立的长连接数量急剧减小，在 6w 长连接且采用 50% 的负载均衡分片的场景下：单机 CPU 降低约 0.4 Core，内存降低约 500M。\n3.2 海量服务发现问题 MOSN 的服务发现能力没有使用 Pilot，而是在内部直接和 SOFARegistry（服务注册中心） 对接，使用这种架构的原因之一就是 RPC 的接口级服务发现，节点的 Pub、Sub 量巨大，海量应用的频繁运维产生的节点变更推送对 Pilot 的性能和及时性挑战都很大，社区有使用 Pilot 在稍大规模下做 CDS 下发的过程中也发现非常多的性能问题并提交 PR 解决，但对于蚂蚁集团一个机房就有 200W Pub，2000W Sub 的规模下，Pilot 是完全无法承载的。SOFARegistry 的架构是存储和连接层分离，存储为内存分片存储，连接层也可以无限水平扩容，在内部海量节点变更下也能实现秒级变更推送。\n虽然 SOFARegistry 的推送能力没什么问题，不过海量节点变更后产生的推送数据，会导致 MOSN 内有大量的 Cluster 重构，列表下发后到 Cluster 构建成功的过程中，会有大量的临时内存产生，以及 CPU 计算消耗。这些尖刺型内存申请和 CPU 占用，是可能直接影响请求代理链路稳定性的。为了解决这个问题，我们也考虑过两个优化方向：\n SOFARegistry 和 MOSN 之间把全量推送改造为增量推送 服务发现模型从接口级切换为应用级 其中第一点能带来的效果是每次列表推送变化为原推送规模的 1/N，N 取决于应用变更时的分组数。第二点能带来的变化是更加明显的，我们假设一个应用会发布 20个接口，100个应用的 Pod 产生的服 …","date":1652770800,"description":"继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么，值此 SOFAStack 开源 4 周年之际，欢迎大家一起进入《蚂蚁集团 Service Mesh 进展回顾与展望》章节探讨交流。","dir":"blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8c0eeb7a88e858fcfef4b4c9824ebb3f","permalink":"https://sofastack.github.io/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","publishdate":"2022-05-17T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","summary":"一、引言 继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么","tags":["SOFAStack","Service mesh"],"title":"蚂蚁集团 Service Mesh 进展回顾与展望","type":"blog","url":"/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","wordcount":5542},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFAMeetup 成都站-云原生技术交流专场\n 活动时间：2022 年 05 月 14 日（周六）14:00-18:00\n 活动形式：线上直播\n 资料下载：\n 《Nydus-面向下一代的容器镜像》\n《云原生应用配置代码化实践》\n活动回顾 直播回放：\nNydus-面向下一代的容器镜像\n云原生应用配置代码化实践\n活动议程 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1652511600,"description":"SOFAMeetup 成都站-云原生技术交流专场","dir":"activities/sofa-meetup-15/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f637fdc7cae0e17bb6c6cf1302cd7f80","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-15/","publishdate":"2022-05-14T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-15/","summary":"概要 活动主题：SOFAMeetup 成都站-云原生技术交流专场 活动时间：2022 年 05 月 14 日（周六）14:00-18:00 活动形式：线上直播 资料","tags":["SOFA"],"title":"【活动回顾】《SOFAMeetup 成都站-云原生技术交流专场》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-15/","wordcount":211},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@曹飞提问：\n MOSN 集成 prometheus 是怎么使用呢？看到读取相应配置，是在自定义配置里面吗？\n A：你可以自定义收集指标，然后通过 promoetheus 格式输出。在配置加这个 metric 的就行了。https://github.com/mosn/mosn/blob/f3248bf2ed6c5d13635e8ce4af921f665ccdf96c/configs/mosn_config_dev.json#L69\n「MOSN」：https://github.com/mosn\n@沈冰 提问：\n SOFAArk 2.0 怎么创建 ark-plugin? 使用的场景是做类隔离。\n A：当前这个还和 1.0 的使用方式一致的，完全按照 1.0 的方式来。https://developer.aliyun.com/article/625338\n「SOFAArk」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto v0.4.0 版本 发布 Layotto v0.4.0 版本，主要变更如下：\n1.文件能力增加了七牛云 oss、hdfs、腾讯云 oss 的实现；\n同时增加了Java SDK 的实现\n2.支持 API 插件和自定义组件能力\n3.支持 SkyWalking\n4.支持基于内存的和 mongo 的分布式锁和分布式自增 ID\n5.支持 secret 接口\n6.支持 Dapr 的 state、InvokeService、InvokeBinding API\n7.优化了当前 CI 流程\n7.修复及优化若干 bug\n详细发布报告:https://github.com/mosn/layotto/releases/tag/v0.4.0\n本周推荐阅读 【2022 开源之夏】欢迎报名 SOFAStack 社区项目！\n 恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n SOFAServerless 体系助力业务极速研发\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1652425200,"description":"SOFA Weekly | Layotto v0.4.0 版本发布、开源之夏项目讲解、本周 Contributor","dir":"blog/sofa-weekly-20220513/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0d42b166bf83ba9a3cc657d29b0b64b2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220513/","publishdate":"2022-05-13T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220513/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto v0.4.0 版本发布、开源之夏项目讲解、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220513/","wordcount":1311},{"author":"Webster-Yang","categories":"SOFAStack","content":" 背景 SOFARgeistry 分为 Session、Data 和 Meta 三个模块。Session 模块用于 client 交互，可以横向扩容，可以承受大量 client 连接请求；Data 是数据存储模块，利用 slot 分片机制来均衡负载，使用备份来解决高可用问题；Meta 是 Session、Data 的注册中心，采用分布式锁来选举 leader，本文详细阐述 Meta 如何选主。\n基于 MySQL 的分布式锁 MySQL 表\ndrop table if exists distribute_lock; CREATE TABLE distribute_lock ( id bigint(20) NOT NULL AUTO_INCREMENT primary key, data_center varchar(128) NOT NULL, lock_name varchar(1024) NOT NULL, owner varchar(512) NOT NULL, duration bigint(20) NOT NULL, term bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT \u0026#39;任期\u0026#39;, term_duration bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT \u0026#39;租期\u0026#39;, gmt_create timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, gmt_modified timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_data_center_lock` (`data_center`, `lock_name`), KEY `idx_lock_owner` (`owner`) ); 表的增改查等操作\npublic interface DistributeLockMapper { /** * query by dataCenter and lockName * * @param dataCenter * @param lockName * @return */ public DistributeLockDomain queryDistLock( @Param(\u0026amp;quot;dataCenter\u0026amp;quot;) String dataCenter, @Param(\u0026amp;quot;lockName\u0026amp;quot;) String lockName); /** * compete lock, it will throw exception if lockName existed * * @param lock */ public void competeLockOnInsert(DistributeLockDomain lock) throws Exception; /** * compete lock with cas * * @param competeLock * @return */ public void competeLockOnUpdate(FollowCompeteLockDomain competeLock); /** renew lock last update time */ public void ownerHeartbeat(DistributeLockDomain lock); /** force reset owner and duration */ public void forceRefresh(DistributeLockDomain lock); } 整体流程 step1：启动时创建锁记录，\n\u0026amp;lt;insert id=\u0026amp;quot;competeLockOnInsert\u0026amp;quot; parameterType=\u0026amp;quot;com.alipay.sofa.registry.jdbc.domain.DistributeLockDomain\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;![CDATA[ INSERT /*+ QUERY_TIMEOUT(2000000) */ INTO distribute_lock ( data_center, lock_name, owner, duration, gmt_create, gmt_modified, `term`, `term_duration` ) VALUES ( #{dataCenter}, #{lockName}, #{owner}, #{duration}, NOW(3), NOW(3), 1, 0 ) ON DUPLICATE KEY UPDATE lock_name = #{lockName} ]]\u0026amp;gt; \u0026amp;lt;/insert\u0026amp;gt; step2：leader 每秒提交心跳，更新表\n\u0026amp;lt;update id=\u0026amp;quot;ownerHeartbeat\u0026amp;quot; parameterType=\u0026amp;quot;com.alipay.sofa.registry.jdbc.domain.DistributeLockDomain\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;![CDATA[ update /*+ QUERY_TIMEOUT(2000000) */ distribute_lock set owner = #{owner}, gmt_modified = NOW(3), `term_duration` = (`term_duration` + 1) where data_center = #{dataCenter} and lock_name = #{lockName} and owner = #{owner} and term = #{term} and `term_duration` = #{termDuration} and timestampdiff(SECOND, gmt_modified, NOW()) \u0026amp;lt; #{duration}/1000 ]]\u0026amp;gt; \u0026amp;lt;/update\u0026amp;gt; step3：follower 每秒判断锁是否过期，如果过期，则 cas 竞选 leader\npublic DistributeLockDomain onFollowWorking(DistributeLockDomain lock, String myself) { /** as follow, do compete if lock expire */ if (lock.expire()) { LOG.info(\u0026amp;quot;lock expire: {}, meta elector start: {}\u0026amp;quot;, lock, myself); distributeLockMapper.competeLockOnUpdate( new FollowCompeteLockDomain( lock.getDataCenter(), lock.getLockName(), lock.getOwner(), …","date":1652252400,"description":"源码解析｜registry meta选主","dir":"projects/sofa-registry/code-analyze/code-analyze-registry-meta/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1ed6ac5b5251011241bc8ec391f4e720","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","publishdate":"2022-05-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","summary":"背景 SOFARgeistry 分为 Session、Data 和 Meta 三个模块。Session 模块用于 client 交互，可以横向扩容，可以承受大量 client 连接请求；Data 是数据存储模块，","tags":["“源码解析”"],"title":"源码解析｜registry meta 选主","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","wordcount":1236},{"author":"赵真灵、刘晶","categories":"SOFAStack","content":" 文｜赵真灵（花名：有济）蚂蚁集团技术专家、刘晶（花名：飞廉） 蚂蚁集团技术专家\n以下内容整理自 SOFAStack 四周年的分享\n本文 5332 字 阅读 10 分钟\nSOFAServerless 研发运维平台是蚂蚁集团随着业务发展、研发运维的复杂性和成本不断增加的情况下，为帮助应用又快又稳地迭代而研发。从细化研发运维粒度和屏蔽基础设施的角度出发，演进出的一套解决方案。\n核心方式是通过类隔离和热部署技术，将应用从代码结构和开发者阵型拆分为两个层次：业务模块和基座，基座为业务模块提供计算环境并屏蔽基础设施，模块开发者不感知机器、容量等基础设施，专注于业务研发帮助业务快速向前发展。\nPART. 1 背 景 当前 Serverless 的发展有两个演进方向，一个是从面向函数计算的架构往在线应用演进，另一种是面向在线应用的架构往类函数计算方向演进。\nSOFAServerless 体系选择了后者，是从面向应用研发运维过程中遇到的一些问题展开的。在应用架构领域，不可避免的问题是应用随着业务的复杂度不断增加，研发运维的过程中的问题会不断暴露出来。\n首先我们先看一下对于普通应用，研发和运维过程中的流程是什么样的？\n如图所示，从需求到设计、开发、线下测试，再到发布线上的研发运维不断反馈、循环迭代的过程。可以简化为开发同学提交代码到代码仓库，在线下做并行的验证测试，测试通过之后在线上发布，发布过程是串行的，只能够有一个发布窗口，这样的过程在应用体量业务还不太复杂的情况下问题，并不是很明显。\n但当业务复杂度不断增加，普通应用迭代过程在会出现一些新的问题，如下图：\n1.管理成本高：需求管理、代码管理、人员管理\n2.时间成本高：线上验证与发布互相阻塞；单次启动慢\n3.变更风险高： 一次变更涉及所有代码；一次变更涉及所有机器\n4.可扩展性不够\n另外，由于这些问题是因为多业务单元与研发任务耦合在某些单点上导致的，这些研发运维的成本随着业务的复杂度，呈现出指数增长的特点。\nPART. 2 SOFAServerless 研发运维体系 解决方案介绍\n对于这些问题，业界已经发展并演进出了多种应用架构，从单体架构 -\u0026amp;gt; 垂直架构 -\u0026amp;gt; SOA 架构 -\u0026amp;gt; 分布式微服务架构 -\u0026amp;gt; 服务网格架构等，我们分析这些演进过程为解决遇到的研发运维问题提出 SOFAServerless 研发运维体系，主要的核心思路是：\n 研发运维力度的细化 通过细化的方式，让多人协作之间不互相 block；\n迭代的范围变小，速度变快。\n 屏蔽基础设施 屏蔽基础设施，让业务开发同学只关注代码服务和流量。\n对于这两点，我们采用了 SOFAArk ClassLoader 类隔离和热部署能力，将应用拆分成基座和模块。\n基座和模块 从这张图里面可以看到我们拆分的形态，把一个普通的 JVM 应用拆出多个模块，进一步对模块进行了一些分工：基座和模块，对应的研发人员也分为基座开发者和模块开发者。\n基座沉淀通用的逻辑，为模块提供计算和环境，并会模块开发者屏蔽基础设施，让模块开发者不需要关心容量、资源、环境。各个模块是独立的代码仓库，可以进行独立的研发运维，这样研发运维粒度得到细化，并且由于基座为模块屏蔽了环境与基础设施，模块开发者可以专注业务开发，提高整体效率。\n如何共享和通信 应用如果只是做拆分，没有共享和通信能力是不完整的方案也难以解决实际问题。对于共享和通信，基座作为共享的一层，能帮模块预热 RPC 数据库缓存通用类、通用方法、通用逻辑，可以供安装一些模块去复用。这样模块实现的比较轻，所以模块的部署密度也可以做得很高。\n对于模块通信，当前模块之间的通信可以支持任意的通信方式，比如说基座调模块、模块调基座模块和模块之间调用。由于模块通信是 JVM 内跨 ClassLoader 调用，与普通 JVM 内方法调用增加了序列化与反序列化的开销，目前这部分开销已经优化到约等于 JVM 内部的方法调用。\n在这一能力建设之后，可以较大降低模块的接入改造成本并扩大可适用的业务范围。\n如何解决业务痛点 管理成本\n相较于原来的研发模式，研发人员拆分成不同小组，代码仓库也拆分出多个模块仓库，并且可以独立并行的发布到线上，整个 pipelien 都可以做到独立进行。\n如此一来，需求管理、代码管理、人员管理的成本就得到下降了，线上发布过程中也不会再有互相阻塞的问题存在。\n当然这些成本下降不代表这些问题完全没有了，只是从原来的指数增长转变成了这种线性增长。随业务的复杂度不断增加，它的收益会更加的明显。\n时间成本 相对于普通应用的镜像构建需要 3 分钟，发布需要镜像下载、启动、挂载流量大概 3 分钟，总共平均需要 6 分钟；模块构建只需要 10 秒，启动大概 1~10 秒 （模块大小可大可小，对于较小的模块，速度可以做到毫秒级别） 。\n把一次发布耗时从原来的 6 分钟下降到 15 秒，一次迭代从原来 2 周下降到了 2 天，最快可以 5 分钟上线的。\n可扩展性 对于线上集群的部署形态，不同的机器上部署的模块不尽相同。例如对于模块 1，只安装在了第一第二台机器上，那么模块升级时只会涉及到这两台机器本身，变更的机器范围就比较小了。另外，模块 1 如果要扩容的话，可以从集群内筛选出较空闲的机器进行模块热部署即可，一般也就是 10s 级别，所以能做大快速的水平扩展能力。\n变更风险 对于一次模块的升级变更，只会涉及模块自身的代码本身不会设计整个应用代码。模块变更需要更新的机器也只是模块安装过的机器本身，不会涉及到整个集群，所以变更范围大大缩小，变更风险也相较普通应用能得到明显减少。\n高可用和配套能力 SOFAServerless 体系在解决业务研发运维痛点基础上，建设了高可用和配套的能力。\n资源隔离 资源隔离体现在单个 JVM 内部的，这里采用了我们公司内部 AliJDK 多租户隔离能力，每一个模块可以指定自己的资源使用的上限。\n比如说，其中一个模块的逻辑有一些问题，消耗的资源比较大，不会影响到其他的模块，相当于得到了故障的隔离。\n流量隔离能力 对于单个集群内部，我们做了一些精细化的流量路由。主要是因为发服务时能够动态增加 tag，流量路由时能够配一些规则，推送到 MOSN、Layotto 里，能让流量根据对应的 tag 进行一些精细化路由，这样就具备了流量的精细化路由和流量隔离能力。\n可观测性能力与变更防御能力 具备模块粒度的健康检查、资源监控、日志监控还有排障能力，在此基础上建设模块粒度的变更防御。\n一个模块可以同时存在多个版本，可以做一些快速的 A/B 测试、灰度、回滚这些能力。\nPART. 3 业务的落地形态** SOFAServerless 发展到现在，已经在蚂蚁内部接入了 700 多个 Java、nodejs 应用，基本涵盖了蚂蚁所有业务线，支撑了 1 万多次的完整的生产研发迭代。线下可以做到秒级发布，支付宝应用内很多业务就是跑在 SOFAServerless 上的，比如投放展位、公益游戏、营销玩法。\n去年 SOFAServerless 成功支撑了 618、双 12、五福等重量级大促和活动，经受住了大流量高并发场景下的考验，托管在 SOFAServerless 的资 …","date":1652166000,"description":"SOFAServerless 体系助力业务极速研发","dir":"blog/sofaserverless-system-for-speedy-business-development/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"760d9079310bd5202d52c369c1603bec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","publishdate":"2022-05-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","summary":"文｜赵真灵（花名：有济）蚂蚁集团技术专家、刘晶（花名：飞廉） 蚂蚁集团技术专家 以下内容整理自 SOFAStack 四周年的分享 本文 5332 字 阅读 10 分钟 SOFAServerless 研发运维平台是蚂","tags":["SOFAStack"],"title":"SOFAServerless 体系助力业务极速研发","type":"blog","url":"/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","wordcount":5533},{"author":"范明柯","categories":"SOFAStack","content":" 前言 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析\n 一、架构流程图 二、订阅流程 以客户端首次订阅，且服务发布方已注册的场景为例，订阅流程主要分为三步，\n 客户端发起订阅 session server 处理订阅任务，从缓存（或 data server）拉取地址列表 向客户端推送地址列表 2.1 客户端发起订阅 客户端发起订阅的方式是异步的，首先将订阅注册的任务添加到客户端的内存队列中。\n2.2 session server 处理订阅请求 session server 接收到订阅注册任务后，主要是通过 SessionRegistry#regsiter 方法处理的，判断当前是服务消费方，添加到订阅者缓存中； case SUBSCRIBER: Subscriber subscriber = (Subscriber) storeData; // if (!sessionInterests.add(subscriber)) { break; } sessionRegistryStrategy.afterSubscriberRegister(subscriber); break; 触发RegProcessor#fireOnReg方法，将订阅者放入buffer中，参考源码如下： boolean fireOnReg(Subscriber subscriber) { final String dataInfoId = subscriber.getDataInfoId(); // 从若干个BufferWorker数组找到其中一个 BufferWorker worker = indexOf(subscriber.getDataInfoId()); // 将dataInfoId和subscriber存到BufferWorker线程中的subMap中 // subMap的key为dataInfoId，value为SubBuffer SubBuffer buffer = worker.subMap.computeIfAbsent(dataInfoId, k -\u0026amp;gt; new SubBuffer()); return buffer.add(subscriber); } 2.3 session server 拉取地址列表 BufferWorker 线程循环处理 map 缓存中的订阅注册任务，处理流程如下：\n 从 worker 的 subMap 取出所有 dataInfoId 和订阅者列表，并对每个 dataInfoId 分别处理 通过 RegProcessor#processBuffer 方法处理每个 dataInfoId 和对应的订阅者 int processBuffer(Ref ref, int hitSize) { List\u0026amp;lt;Subscriber\u0026amp;gt; subscribers = Lists.newArrayListWithCapacity(hitSize); for (Map.Entry\u0026amp;lt;String, Subscriber\u0026amp;gt; e : ref.subscriberMap.entrySet()) { final Subscriber sub = e.getValue(); // 若订阅者已经推送过，直接忽略 if (!sub.hasPushed()) { subscribers.add(sub); } // 这里因为subscriberMap是引用，没有锁保护，所以sub可能已经被新的subscriber替换掉 // try to remove the sub, but subs maybe changes ref.subscriberMap.remove(sub.getRegisterId(), sub); } if (!subscribers.isEmpty()) { // 从缓存中获取dataInfoId的地址列表，并推送给subscribers regHandler.onReg(ref.dataInfoId, subscribers); } // 返回推送地址列表的订阅者数量 return subscribers.size(); } 通过 FirePushService#getDatum 方法从缓存中获取地址列表。该缓存使用 Guava Cache 的LoadingCache，当缓存中没有 dataInfoId 的地址列表时，会自动从 data server 获取地址列表，并放在缓存中。\n 通过 FirePushService#processPush 方法将地址列表推送给所有订阅者\n 首先通过 firePush 方法将 PushTas k放入 buffer 等待 PushTaskBuffer.BufferWorker 线程异步处理任务 2.4 session server 推送地址列表 PushProcessor 初始化时默认创建 4 个 PushTaskBuffer.BufferWorker 线程； BufferWorker 线程循环执行 watchBuffer 方法，将 worker 中缓存的过期任务删除后进行处理，具体逻辑见下边源码； int watchBuffer(BufferWorker worker) { int bufferedSize = worker.bufferMap.size(); if (bufferedSize \u0026amp;gt;= MAX_BUFFERED_SIZE) { LOGGER.warn(\u0026amp;quot;arrived max buffered size: buffered={}\u0026amp;quot;, bufferedSize); } // 获取推送任务 List\u0026amp;lt;PushTask\u0026amp;gt; pending = worker.transferAndMerge(); int count = 0; for (PushTask task : pending) { // 将任务放进线程池执行 if (task.commit()) { count++; } } if (pending.size() \u0026amp;gt; 0 || count \u0026amp;gt; 0) { LOGGER.info(\u0026amp;quot;buffers={},commits={}\u0026amp;quot;, pending.size(), count); } return count; } 推送地址列表给客户端。 三、发布流程 服务发布流程主要分为下面5步：\n 客户端服务注册 session server 处理服务发布请求 data server 保存服务注册数据，并生成数据变更通知 session server 接收数据变更通知，拉取数据 session server 推送地址列表 3.1 服务注册 客户端进行发布注册，与上面客户端订阅的逻辑一样，都是先将请求放在队列里，等待异步处理，此处不再赘述。\n3.2 session server 处理服务发布请求 SessionRegistry#register 方法判断请求来自服务发布方； …","date":1652079600,"description":"源码解析｜发布订阅推送","dir":"projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","fuzzywordcount":3100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"981d3695a0bbf202fbb64b22687b1f25","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","publishdate":"2022-05-09T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","summary":"前言 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析 一、架构流程图 二、订阅流程 以客户端首次订阅，且服务发布方已注册的场景为例，订阅流程主要分为三步， 客户端发起订","tags":["“源码解析”"],"title":"源码解析｜发布订阅推送","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","wordcount":3020},{"author":null,"categories":"SOFA Weekly","content":" 开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2022 年，SOFAStack 和 MOSN 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2022”，为大家准备了六个任务，涉及 Cloud Native、Micro Service、Distributed System、Kubernetes、Container 等多个领域。\n活动规则 进入：https://summer-ospp.ac.cn/#/homepage\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\n项目任务 1.SOFARegistry 客户端负载均衡\nSOFARegistry 的客户端目前采用长连接与其中一台 Session 相连，随后会用这根链接注册和订阅服务，在注册中心进行运维期间，客户端会断链重连到别的机器上，经过一轮滚动升级，就会造成 Session 上链接分布的不均衡，一是数据不均衡，二是推送压力不均衡，严重的时候会造成单机热点，影响推送的效率。\n由于长连接快速检测节点宕机的机制，主动断链会造成节点数据下线，因此客户端链接的稳定性也是一个很重要的考虑。\n对服务发现来说，发布和订阅对链接稳定性的要求不同：\n 对发布，链接断开会造成服务数据下线\n 对订阅，会造成轻微的数据推送延迟，延迟时间通常是重连间隔\n 项目社区导师：dzdxdzidaxie@gmail.com\n2.增强 layotto-java-sdk 和 layotto-spring-boot\n项目编号：2295a0213\n任务难度：基础/Basic\n1.增强 Layotto 的 java-sdk 的功能，使其与 go-sdk 对齐。现在的 java-sdk 有 file、lock、pubsub、sequencer、state 的 API，缺少 secret、config 等 API。\n 完善 layotto-sdk-springboot, 将 Layotto 的更多功能集成进 spring-boot。layotto-sdk-springboot 的设计目标是帮助 spring-boot 的用户低成本接入 Layotto，比如用户在代码中添加一个 Java 注解后，就能方便的进行消息监听、收到新消息后自动调用方法。\n 在 layotto-sdk-springboot 的基础上，开发 layotto-sdk-sofaboot, 方便 SOFABoot 用户使用 Layotto。\n 项目社区导师：张立斌1098294815@qq.com\n3.Layotto 中实现 ceph 文件系统，同时打通 SOFABoot\n项目编号：2295a0214\n任务难度：基础/Basic\n用 ceph 实现 Layotto 的 file API 组件，并通过 SOFABoot 调通。\n 首先熟悉 Layotto 的架构设计，基于现在的 file 接口实现 ceph 文件系统。（此处需要调研 Layotto 的 file 组件的可移植性以及 ceph 文件系统，判断当前的 Layotto 接口能否满足 ceph 文件系统）\n 通过 SOFABoot 和 Layotto 打通，可以通过 SOFABoot 应用调通 Layotto 的 file 接口。\n 项目社区导师：wenxuwanwangwx_junction@163.com\n4.SOFATracer upgrade opentracing api version \u0026amp;amp; adapter opentelemetry api\n项目编号：2295a0196\n任务难度：进阶/Advanced\nCurrently, sofa-tracer relies on the openTracing version 0.22.0. This version has been out of date for a long time and we need to update to the official recommended stable version. In addition, we need to provide an API layer to accommodate OpentElemetry.\nTasks:\n1、upgrade opentracing version torelease-0.33.0\n2、adapter https://opentelemetry.io/docs/migration/opentracing/\n3、provide intergration doc and guides\n项目社区导师：卫恒（宋国磊）glmapper_2018@163.com\n5.为 MOSN 适配社区 Proxy-Wasm v2 开源规范\n项目编号：22f080190\n任务难度：进阶/Advanced\nWebAssembly(Wasm) 是近几年从 Web 领域诞生，并快速出圈的一项虚拟机指令格式，是一种可移植的、语言无关并兼容 Web 的全新格式，支持在浏览器和非 Web 环境运行不同语言编写的应用程序。\nMOSN 是一款主要使用 Go 语言开发的网络代理 (类似 Envoy、Nginx)，融合了大量云原生通用插件，为服务提供了多协议、模块化、智能化、安全的代理能力。\n如何为这些插件提供一个安全隔离的运行环境，甚至支持不同语言编写的插件，成为了一个非常具有挑战性的课题。Wasm 技术和 Proxy-Wasm 规范的诞生为解决上述问题提供了一种全新的思路。\n本题目将基于 MOSN 中已有的 Wasm 框架，适配开源社区专门为网络代理场景提出的 Proxy-Wasm v2 规范，使 MOSN 具备运行符合 v2 规范的 Wasm 插件的能力。\n项目社区导师：叶永杰yongjie.yyj@antgroup.com\n6.Layotto 集成 Istio\n项目编号：22f080198\n任务难度：进阶/Advanced\n1.Istio 是 ServiceMesh 方向上一个非常火热的解决方案，默认使用 envoy 作为数据面。\n MOSN 作为一个对标 envoy 的另一种数据面实现，也可以跟 Istio 集成，作为 envoy 的一种替代方案。\n Layotto 作为 Application Runtime 的一种实现，基于 MOSN 开发，期望可以结合 Service Mesh 跟 Application Runtime 两种思想。\n 既然 Istio 可以集成 MOSN ，且 Layotto 跟 MOSN 是一体的，因此本次的任务是把 Layotto 作为数据面跟 Istio 进行集成，以服务调用为例，在应用通过 Layotto …","date":1651906800,"description":"【2022 开源之夏】欢迎报名 SOFAStack 社区和 MOSN 社区项目！","dir":"blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"38cfc44c56af96fa7b7700c470ce5931","permalink":"https://sofastack.github.io/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","publishdate":"2022-05-07T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["SOFA Weekly"],"title":"【2022 开源之夏】欢迎报名 SOFAStack 社区和 MOSN 社区项目！","type":"blog","url":"/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","wordcount":2100},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@尚之 提问：\n SOFARegistry 和应用绑定有多深，Serverless 场景下有没有更动态的方案和应用解绑？\n A：其实不需要和应用进行绑定，更准确的说法是节点级的服务发现，就算应用下面每个节点之间发布的服务不一样，应用级的这个方案也是可以支持的。而且目前蚂蚁的 Serverless 的场景实际上已经是应用级了，只是对于业务 owner 没有感知。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@沄澈|che 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?\n A：要看 SerializerFactory 对 Localdatetime 的支持了。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 MOSN 1.0 发布，开启新架构演进\n HAVE FUN | SOFABoot 源码解析活动\n SOFARegistry 源码｜数据分片之核心-路由表 SlotTable 剖析\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1651820400,"description":"SOFA Weekly | 神奇技术、本周贡献者、新手任务","dir":"blog/sofa-weekly-20220506/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d89becc4edace0dc4e93d5a8b39f9e61","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220506/","publishdate":"2022-05-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220506/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 神奇技术、本周贡献者、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220506/","wordcount":1010},{"author":"周书伟","categories":"SOFAStack","content":" 源码解析：无损运维 SOFARegistry 是一个基于内存存储的分布式注册中心，数据是分散存储在各个节点，为了做到注册中心自身运维期间依然能够对外正常提供服务，需要进行节点下线快速感知和数据迁移。\n session 存储 client 发送的发布和订阅数据，由于 client 断连重放的特性，session 单机下线后 client 会重放数据到其他节点。\n data 会接收 session 发送的发布数据，data 单机下线后，meta 会通过 SlotTable 的变更把对应 Slot 的所有权移交其他 data，data 启动后会进行数据同步到达数据完整可对外提供服务的状态。\n session、data下线的过程，如何避免下线期间数据丢失和抖动 SessionServer 和 DataServer 下线的相关代码都位于各自 bootstrap 类的 dostop 方法中。\n首先讨论 SessionServer 的下线过程：\nprivate void doStop() { try { LOGGER.info(\u0026amp;quot;{} Shutting down Session Server..\u0026amp;quot;, new Date().toString()); stopHttpServer(); clientNodeConnectionHandler.stop(); // stop process disconnect event stopServer(); // stop http server and client bolt server before add blacklist // make sure client reconnect to other sessions and data gracefulShutdown(); stopDataSyncServer(); stopConsoleServer(); executorManager.stopScheduler(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Shutting down Session Server error!\u0026amp;quot;, e); } LOGGER.info(\u0026amp;quot;{} Session server is now shutdown...\u0026amp;quot;, new Date().toString()); } 从代码中可以看出，SessionServer 服务在下线时，首先会停掉 HttpServer，HttpServer 提供一系列 REST 接口，用于 dashboard 管理、数据查询等；然后停掉 clientNodeConnectionHandler，clientNodeConnectionHandler 是 Exchange 设置的一系列 ChannelHandler 之一，Exchange 作为 Client / Server 连接的抽象，负责节点之间的连接。gracefulShutdown 方法则是通知 Meta（元数据服务器）将本节点加入 Meta 的黑名单中。HttpServer 和客户端的 bolt Server 是在本节点加入黑名单前关停，以保证 client 已经重连到了其他 session 节点上。这样就保证了运维的 session 节点下线期间，client 的数据不会因为 session 节点的不可用，导致数据丢失和抖动。接下来又依次关停了 DataSyncServer，ConsoleServer。\nDataServer 下线过程的代码如下：\nprivate void doStop() { try { LOGGER.info(\u0026amp;quot;{} Shutting down Data Server..\u0026amp;quot;, new Date().toString()); gracefulShutdown(); stopHttpServer(); stopServer(); stopDataSyncServer(); stopNotifyServer(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Shutting down Data Server error!\u0026amp;quot;, e); } LOGGER.info(\u0026amp;quot;{} Data server is now shutdown...\u0026amp;quot;, new Date().toString()); } DataServer 的下线则和 Session 的下线有些区别，由于 DataServer 数据服务器，负责存储具体的服务数据，而且 Slot 均匀地分配给每个节点上，所以下线前需要检测 DataServer 上的插槽状态，所以 doStop 的方法中，首先调用了如下的优雅下线的方法，其中代码中的主要内容如下：\naddBlacklistRetryer.call( () -\u0026amp;gt; { LOGGER.info(\u0026amp;quot;[GracefulShutdown] add self to blacklist\u0026amp;quot;); metaServerService.addSelfToMetaBlacklist(); return true; }); addBlacklistRetryer.call( () -\u0026amp;gt; { if (fetchStopPushService.isStopPushSwitch()) { return true; } SlotTableStatusResponse statusResponse = metaServerService.getSlotTableStatus(); if (statusResponse.isProtectionMode()) { return true; } LOGGER.info(\u0026amp;quot;[GracefulShutdown] wait no slot\u0026amp;quot;); if (slotManager.hasSlot()) { throw new RuntimeException(\u0026amp;quot;current data server still own slot, waiting...\u0026amp;quot;); } return true; }); LOGGER.info(\u0026amp;quot;add data self to blacklist successfully\u0026amp;quot;); 首先节点通知 Meta 加入黑名单，stopmetaServerService.getSlotTableStatus() 获取节点上 SlotTable 的状态，当 Slot 重新分配给其他节点后，该 Data 节点才会成功加入黑名单，并进行接下来 HttpServer、DataSyncServer、NotifyServer 的下线动作。\n整体流程是 Data 上的 Slot 逐步迁移，期间仍然对外提供服务。\n迁移完成后主动从列表中剔除并设置节点黑名单并下线。\n以下图为例，假设要下线的节点是 DataServer-1： …","date":1651820400,"description":"源码解析｜无损运维","dir":"projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ffe7f76f483d5fbc2827a237b6c48093","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","publishdate":"2022-05-06T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","summary":"源码解析：无损运维 SOFARegistry 是一个基于内存存储的分布式注册中心，数据是分散存储在各个节点，为了做到注册中心自身运维期间依然能够对外正常提供服务，需要","tags":["“源码解析”"],"title":"源码解析｜无损运维","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","wordcount":3684},{"author":"朱德江","categories":"SOFAStack","content":" 文｜朱德江（花名：人德）\n蚂蚁集团技术专家 负责 MOSN 核心开发，关注云原生流量网关的演进\n以下内容整理自 SOFAStack 四周年的分享\n本文 5332字 阅读 10 分钟\nMOSN 1.0 发布 MOSN 是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源，经过双 11 大促几十万容器的生产级验证。\n经过 4 年的蓬勃发展，在 11 位 commiter，100 多个 contributor 和整个社区的共同努力下，经历 27 个小版本的迭代，MOSN 1.0 版本正式发布了。\n一个足够成熟稳定，有开源用户共建、有商业化落地、有社区，拥抱云原生生态的 MOSN 1.0 来了。\n除了在蚂蚁集团的全面落地，MOSN 在业界也有较广泛的应用，比如有工商银行的商业化落地，还有阿里云、去哪儿网、时速云等企业的生产实践。\n同时，随着 1.0 的发布，进入少年期的 MOSN 也将开启新一代 MOE 架构演进，奔向星辰大海。\n发展历史 MOSN 起源于 Service Mesh，原本在微服务之间的调用是通过比较重的 SDK 来完成的，当 SDK 升级的时候，需要应用配合一起升级，有比较强的打扰。\nMOSN 为了解决这一痛点，向着把 SDK 剥离出来的方向演进。在应用所在的 Pod 内，单独有一个运行 MOSN 的 sidecar，那么应用本身只需要跟 MOSN 去通讯，就可以完成整个的服务调用的流程。把 SDK 剥离出来，相当于 MOSN 作为一个独立的组件去演进，其演进过程对应用本身没有打扰。这在蚂蚁内部的收益其实是非常明显的。\n在整个演进的过程中，有两个比较深的体会：一个比较明显的是，有一个独立的 sidecar，可以去跟业务逻辑做解耦；另外一个标准化，在云原生的时代里，控制面和数据面被拆分为两个独立的组件，MOSN 作为数据面的组件，演进过程中要跟很多控制面的服务对接，这期间标准化是一个很重要的。在整个标准化的过程中，它并不像业务解耦那么直观，但是用的时间越长，对其越深有体会。\n现在 MOSN 已经在蚂蚁内部全面的铺开，部署有几十万 Pod，峰值 QPS 千万级。\nMOSN 的演进历程 2018 年： 开始创建；\n2019 年： 在双 11 完成了核心链路的覆盖，在 19 年底的时候，MOSN 开始独立运营；\n2020 年： 7 月份获得 Istio 官方的推荐。同时，MOSN 开启了商业化的探索，年底完成了江西农信的落地；\n2021 年： 对接了 Envoy、Dapr、WASM 生态，和主流的社区合作。同年 12 月份， 在工商银行完成了商业化的落地，树立了业界新标杆。\nMOSN 除了在蚂蚁内部全面铺开，以及商业化的落地实践，还有逐渐完善的社区。MOSN 社区目前有 11 个 Committer，其中超过 70% 是非蚂蚁的 Committer，有 100 多位的 Contributor，经过了 28 个小版本的迭代。MOSN 还有很多开源的用户，他们将 MOSN 在自己公司落地，也对 MOSN 有很多的贡献。\n社区除了在 MOSN 项目的贡献之外，还有对其他项目/社区的贡献，包括Holmes、BabaSSL、Proxy-Wasm 等项目，以及跟其他生态项目的对接。\n总体来说，MOSN 现在足够成熟稳定，有商业化的落地，有社区、有周边、有生态，所以我们选择这个时间点发布 MOSN 1.0 版本。\n1.0 的核心能力以及扩展生态 MOSN 1.0 版本标志性的成果是已经集成了 Istio 的 1.10 版本。\nMOSN 作为网络代理的软件，在核心转发方面已经支持了 TCP、UDP、透明劫持的模式。MOSN 所处在东西向网关场景下，有很多内部的、私有的非标协议，MOSN 除了支持 HTTP 标准协议以外，还有很重要的 XProtocol 框架，可以非常简单、方便支持私有的非标协议，内置的 Bolt、 Dubbo 协议，也是通过 XProtocol 框架来实现的。我们还支持了多协议的自动识别，也是在东西向流量网关里面比较核心的、比较特别的能力支持。\n后端管理和负载均衡是在网络代理情况下，比较基本的常规能力。MOSN 也支持了连接池、主动健康检查、各种各样的负载均衡的策略。\n在核心路由上，MOSN 支持基于 Domain 的 VirtualHost，引入了一个非常强大的变量支持，通过变量做复杂的路由规则，也支持了 Metadata 的分组路由。还有路由级别的超时、重试的配置，以及请求头、响应头的处理。\n简单来说，作为一个网络代理的平台，通用的核心能力 MOSN 都已经完全具备了。\n同时在网络代理的场景，通常需要做很多扩展，MOSN 的扩展生态做到了什么样的程度了呢？\nRPC 协议： 有 Dubbo 和 SOFABolt 的支持，同时基于 BabaSSL 做了国密的支持；\n控制面： MOSN 已经做了 Istio 的支持；\n注册中心： SOFARegistry；\n可观测性：Skywalking 以及 Holmes 针对 Go 运行时期间，资源使用异常的自动分析和诊断。\n在网关场景里，有很多的逻辑是需要做定制的。除了常规的用 Go 写一些 filter 扩展之外，还支持 Go Plugin 这种轻量级的模式，也支持 Proxy-Wasm 标准的 Wasm 扩展运行在 MOSN 中，服务治理方面也对接了 Sentinel。\nIstio 1.10 MOSN 会通过标准的 xDS 协议和 Istio 通讯，这是一个非常标准的使用方式，同时我们也在积极的参与标准的建设。\n我们在标准的制定过程中，积极提案参与讨论，比如说限流的和路由的 proto，也正是我们和 Istio 有非常多的合作，才能够获得 Istio 官方的推荐。\nMOSN 起源于 ServiceMesh 东西向流量的场景，我们经过了四年的努力，选择在今天这个时间点发布 MOSN 1.0 版本，作为一个成熟稳定、有商业化落地、有社区、有生态的一个版本呈现出来，我们欢迎更多的人来使用 MOSN，也欢迎大家一起来共建和成长。\n二、MoE 新架构 做这个的愿景初衷是什么？\n这样做的优势是什么？\nMoE 新架构的探索有什么新的进展？\n首先 Enovy 和 MOSN 是作为目前市面上的两个数据面，它们都各有特点， Enovy 是 C++写的，处理性能会比较高。MOSN 的研发性和效能高，有很好的生态。\nMoE 就是 MOSN 加 Enovy。我们希望能够做把两者的优势给融合起来，相互融合，各取所长，把高性能和高研发效能结合到一起，支持我们做大做强，走得更远。\nMoE 架构在 Enovy 的角度来看，MOSN 作为 Enovy 的一个插件扩展，在所有的 Enovy 的扩展方式里面，做一个横向的对比。\n1.首先第一个是 Lua\n嵌入式的脚本语言有比较强的优势，它操作简单。但是作为相对小众的语言，劣势也很明显——生态不好。我们目的是为了提高研发效能， Lua 无法让我们达到目标。\n2.WASM 是比较诱人的方案\nWASM 在发展初期，有很多东西还只是停留在愿景上。很多的语言支持不友好，以及 runtime 性能不够好，这都是很现实的痛点。\n3. …","date":1650956400,"description":"MOSN 1.0 发布，开启新架构演进","dir":"blog/mosn-1-0-released-starting-a-new-architectural-evolution/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6319d8cdb62702760f6c4d04c3f996a7","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","publishdate":"2022-04-26T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","summary":"文｜朱德江（花名：人德） 蚂蚁集团技术专家 负责 MOSN 核心开发，关注云原生流量网关的演进 以下内容整理自 SOFAStack 四周年的分享 本文 5332字 阅读 10 分钟 MOSN 1.0 发布","tags":["SOFAStack"],"title":"MOSN 1.0 发布，开启新架构演进","type":"blog","url":"/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","wordcount":4640},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@黄昊 提问：\n 同一个网格里，不同的 Pod 可以注入不同版本的 Sidecar 吗？\n A：去改 inject 程序可以实现，相关资料可以搜索：K8s准入控制。\n 利用 webhook，动态匹配返回 sidecar-image 是这个意思吗？看代码，貌似 Istio 里面可以通过sidecar.istio.io/proxyImage 这个 annotation 来指定。\n A：是的。\n「MOSN」：https://github.com/mosn\n@service mesh 提问：\n gateway 有开源计划吗？\n A：有考虑，但是目前还没有具体的时间点，可以看下这个初期的 issue，有个demo.\nhttps://github.com/mosn/mosn/issues/1563\n「MOSN」：https://github.com/mosn\n@Tom 提问：\n Wasm 还有啥好玩的待实现的特性吗？\n A：目前关于 Wasm 主要想尝试两个方向：\n 以 Wasm 作为用户开发函数的载体，可以参考下：https://github.com/mosn/layotto/issues/191\n 以 Wasm 作为开发 Layotto 各个组件的载体，可以参考下：https://github.com/mosn/layotto/issues/476\n 第二个应该需要尝试使用 Rust 为 Layotto 的 API 开发一个组件然后编译成 Wasm。\n「Layotto」：https://github.com/layotto\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 金融级应用开发｜SOFABoot 框架剖析\n “SOFA 星球”闯关计划 ——Layotto 飞船\n HAVE FUN | 飞船计划、源码解析活动最新进展\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1650610800,"description":"SOFA Weekly | 年度优秀 Committer 、本周 Contributor、本周 QA","dir":"blog/sofa-weekly-20210422/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a78268fffd513c90682e116743a482e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210422/","publishdate":"2022-04-22T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210422/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 年度优秀 Committer 、本周 Contributor、本周 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210422/","wordcount":1213},{"author":"顾叶宸","categories":"SOFAStack","content":" 前言 某些场景下 SOFARegistry 需要暂时关闭推送功能，这样集群内的业务可以利用 client 的缓存继续工作，比如说 SOFARegistry 需要进行不兼容升级，需要全集群下线，更新版本后再拉起。\n推送开关的状态存储在数据库中，通过 Meta 修改数据后，Session 可以通过读取到推送开关的变更通知，并在对应的推送流程上进行切断。\n本文将聚焦推送开关功能的三个关键问题：\n meta 如何存储开关配置数据。 session 如何获取到开关配置的变更并触发更新（通知、定时）。 session 关闭推送功能的实现。 总体流程 关闭推送的请求，主要由 StopPushDataResource类下的closePush负责处理。我们来看看它的实现：\npublic Result closePush() { boolean ret; Result result = new Result(); // 1.重设灰度推送开关 ret = resetGrayOpenPushSwitch(); if (!ret) { result.setSuccess(false); return result; } PersistenceData persistenceData = PersistenceDataBuilder.createPersistenceData( ValueConstants.STOP_PUSH_DATA_SWITCH_DATA_ID, \u0026amp;quot;true\u0026amp;quot;); try { // 2.重设全局推送开关 ret = provideDataService.saveProvideData(persistenceData); ...... } catch (Throwable e) { ...... } if (ret) { // 3.发送数据变更通知 fireDataChangeNotify( persistenceData.getVersion(), ValueConstants.STOP_PUSH_DATA_SWITCH_DATA_ID); } result.setSuccess(ret); return result; } 可以看到，closePush函数主要做了三件事：\n 重设灰度推送开关 灰度推送开关中，存储着一个 IP 列表。灰度推送允许 SOFARegistry 即使在全局推送关闭的情况下，仍满足特定 IP 的推送请求。因此想要完全关闭推送功能，需要重设该开关，清空其中的 IP 列表。\n 重设全局推送开关 关闭推送功能，需要重设全局推送开关，保存开关配置为关闭的新数据。\n 发送数据变更通知 数据变更通知将告诉 Session，开关配置已经改变，需要进行更新。\nMeta存储开关配置数据 我们以重设全局推送开关中，开关数据的存储为例：\n meta 首先从内存中读取旧的开关配置版本号，并与当前数据版本号进行比较。  只有确定是更新的数据，才会进行后续存储。\n 存储新的开关配置数据，并更新数据库中该数据的版本号。\n 更新内存中的开关配置数据。\n public boolean saveProvideData(PersistenceData persistenceData, long expectVersion) { // 1.比较版本号 if (persistenceData.getVersion() \u0026amp;lt;= expectVersion) { ...... return false; } // 2.更新数据库 boolean success = provideDataRepository.put(persistenceData, expectVersion); if (success) { lock.writeLock().lock(); try { // 3.更新内存 provideDataCache.put( PersistenceDataBuilder.getDataInfoId(persistenceData), persistenceData); } catch (Throwable t) { ...... return false; } finally { lock.writeLock().unlock(); } } return success; } 重设灰度开关中的步骤与之类似，因此这里不再赘述。\nSession 获取开关配置 通知更新 继续上文，closePush会调用fireDataChangeNotify函数，通知外界开关配置发生了更新。\nprivate void fireDataChangeNotify(Long version, String dataInfoId) { ...... if (TASK_LOGGER.isInfoEnabled()) { ...... } provideDataNotifier.notifyProvideDataChange(provideDataChangeEvent); } 这一通知首先会进行判断，是哪一种事件类型。在本例中，开关配置的更新是与 Session 有关的事件。 public void notifyProvideDataChange(ProvideDataChangeEvent event) { Set\u0026amp;lt;Node.NodeType\u0026amp;gt; notifyTypes = event.getNodeTypes(); // 判断事件类型 if (notifyTypes.contains(Node.NodeType.DATA)) { defaultDataServerService.notifyProvideDataChange(event); } if (notifyTypes.contains(Node.NodeType.SESSION)) { defaultSessionServerService.notifyProvideDataChange(event); } } 随后，通知会被交付给 Session 相关的消息交换类，并进行Request请求。 public void notifyProvideDataChange(ProvideDataChangeEvent event) { new NotifyTemplate\u0026amp;lt;ProvideDataChangeEvent\u0026amp;gt;().broadcast(event); } public void broadcast(E event) { ...... getNodeExchanger().request(new NotifyRequest(event, connection, executors)); ...... } 在消息交换类中，系统使用getClientHandlers得到了负责消息响应的handler。 public Response request(Request request) throws RequestException { final URL url = …","date":1650610800,"description":"源码解析｜推送开关","dir":"projects/sofa-registry/code-analyze/code-analyze-push-switch/","fuzzywordcount":2900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"38175885eb9d257b9f176246010b34b3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","publishdate":"2022-04-22T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","summary":"前言 某些场景下 SOFARegistry 需要暂时关闭推送功能，这样集群内的业务可以利用 client 的缓存继续工作，比如说 SOFARegistry 需要进行不兼容升级，需要全集群下线，更新版本后再拉起","tags":["“源码解析”"],"title":"源码解析｜推送开关","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","wordcount":2840},{"author":"SOFA 团队","categories":"周年庆","content":" 概要 活动主题：见证 SOFAStack 社区开源四周年!\n 活动时间： 2022 年 04 月 16 日 （14:00-17:40）\n 活动形式：线上直播\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | 一、宋顺四周年致辞 点击下载资料\n| 二、《蚂蚁服务发现的大规模实践和展望》 讲师：蚂蚁集团技术专家李旭东（花名：向旭）\n点击下载资料\n议题简介\nnaming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。\n蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。\n本次将会分享蚂蚁内部实践经验，以及 naming 在云原生时代下的发展方向及趋势。\n| 三、《蚂蚁集团 Service Mesh 进展回顾与展望》 讲师：蚂蚁集团高级技术专家 石建伟（花名：卓与）\n点击下载资料\n议题简介\n练内功：内部集群规模化扩张带来的技术挑战，长连接膨胀，服务治理智能化演进和人工介入说再见\n定标准：Mesh 化是终点么？应用运行时标准\n建通路：让业务飞速发展的秘诀\n看未来：云原生运行时的下一个五年\n| 四、《MOSN 1.0 发布，开启新一代架构演进》 讲师：MOSN 核心成员 朱德江（花名：人德）\n点击下载资料\n议题简介\n一、MOSN 1.0 发布\n回顾 MOSN 的发展历史、新版本的特性介绍\n二、新架构演进\n发力南北向网关数据面、整合控制面，开源新产品\n| 五、《Ark Serverless 体系助力业务极速研发》 讲师：蚂蚁集团技术专家 赵真灵（花名：有济）\n讲师：蚂蚁集团技术专家刘晶（花名：飞廉）\n点击下载资料\n议题简介\nArk Serverless 技术体系让用户以开发模块（代码块）的方式快速上线新功能，同时让模块开发者不感知机器、环境与容量等基础设施，助力企业实现业务的快速发展。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1650092400,"description":"见证 SOFAStack 社区开源四周年!","dir":"activities/sofastack-four-years-of-open-source/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"08b0bec521b5328d71dcc39370feb260","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofastack-four-years-of-open-source/","publishdate":"2022-04-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofastack-four-years-of-open-source/","summary":"概要 活动主题：见证 SOFAStack 社区开源四周年! 活动时间： 2022 年 04 月 16 日 （14:00-17:40） 活动形式：线上直播 B 站直播间地址：http://live","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFA 四周年，开源正当时！","type":"activities","url":"/sofastack.tech/activities/sofastack-four-years-of-open-source/","wordcount":827},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@ 尚之 提问：\n SOFARegistry 和应用绑定有多深，Serverless 场景下有没有更动态的方案和应用解绑？\n A：其实不需要和应用进行绑定，更准确的说法是节点级的服务发现，就算应用下面每个节点之间发布的服务不一样，应用级的这个方案也是可以支持的。而且目前蚂蚁的 Serverless 的场景实际上已经是应用级了，只是对于业务 owner 没有感知。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@ 黄润良 提问：\n 两个组合为什么不生效呢？按照时间轮转，就不需要管理日志数量了吗？\n A：按照时间轮转还没有支持这个日志数量。\n 按时间轮转的，轮转后的文件名应该是带日期时间字符串的把，配个定制任务清理一下就可以了吗？\n A：我们也是用的这个库，然后根据时间轮转是我们扩展的，我们是统一平台做这个事，就没在 MOSN 里实现。\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto Java-sdk 本周发布 Layotto Java-sdk 发布 v1.1.0 版本，主要变更如下：\n 支持 File API\n 支持 Sequencer API\n 新增 layotto-springboot\n 「发布报告」：https://github.com/layotto/java-sdk/releases/tag/v1.1.0\n本周推荐阅读 HAVE FUN | Layotto 源码解析\n 异构注册中心机制在中国工商银行的探索实践\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1649401200,"description":"SOFA Weekly |开源新知、本周 QA、Layotto Java-sdk 本周发布","dir":"blog/sofa-weekly-20220408/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c70e2662ec9434d8229f900636d39af1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220408/","publishdate":"2022-04-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220408/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |开源新知、本周 QA、Layotto Java-sdk 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220408/","wordcount":1202},{"author":"行动","categories":"SOFAStack","content":" SOFARegistry 对于服务数据是分片进行存储的，因此每一个 data server 只会承担一部分的服务数据，具体哪份数据存储在哪个 data server 是有一个称为 SlotTable 的路由表提供的，session 可以通过 SlotTable 对对应的 data derver 进行读写服务数据， slot 对应的 data follower 可以通过 SlotTable 寻址 leader 进行数据同步。\n维护 SlotTable 是由 Meta 的 leader 负责的，Meta 会维护 data 的列表，会利用这份列表以及 data 上报的监控数据创建 SlotTable，后续 data 的上下线会触发 Meta 修改 SlotTable， SlotTable 会通过心跳分发给集群中各个节点。\n1. DataServer 更新SlotTable 路由表过程。 如上图所示 session 和 data 节点定时会向 Meta 节点上报心跳、Meta节点维护了 data 以及 session 节点列表信息、并且在心跳请求中将返回 SlotTable 路由表信息、data 节点将路由表 SlotTable 保存在本地中。\n2. SlotTable 更新平衡算法 由前文可知、SOFARegistry 采用了数据分片存储在 DataServer 节点之上、那么随之而来的问题就是数据如何分片呢?\nSOFARegistry 采用预分配的方式。\n传统的一致性 Hash 算法有数据分布范围不固定的特性，该特性使得服务注册数据在服务器节点宕机、下线、扩容之后，需要重新存储排布，这为数据的同步带来了困难。大多数的数据同步操作是利用操作日志记录的内容来进行的，传统的一致性 Hash 算法中，数据的操作日志是以节点分片来划分的，节点变化导致数据分布范围的变化。\n在计算机领域，大多数难题都可以通过增加一个中间层来解决，那么对于数据分布范围不固定所导致的数据同步难题，也可以通过同样的思路来解决。\n这里的问题在于，当节点下线后，若再以当前存活节点 ID 一致性 Hash 值去同步数据，就会导致已失效节点的数据操作日志无法获取到，既然数据存储在会变化的地方无法进行数据同步，那么如果把数据存储在不会变化的地方是否就能保证数据同步的可行性呢？答案是肯定的，这个中间层就是预分片层，通过把数据与预分片这个不会变化的层相互对应就能解决这个数据同步的难题。\n目前业界主要代表项目如 Dynamo、Casandra、Tair、Codis、Redis cluster 等，都采用了预分片机制来实现这个不会变化的层。\n事先将数据存储范围等分为 N 个 slot 槽位，数据直接与 slot 相对应，数据的操作日志与相应的 solt 对应，slot 的数目不会因为节点的上下线而产生变化，由此保证了数据同步的可行性。除此之外，还需要引进“路由表”的概念，如图 13，“路由表”负责存放每个节点和 N 个 slot 的映射关系，并保证尽量把所有 slot 均匀地分配给每个节点。这样，当节点上下线时，只需要修改路由表内容即可。保持 slot 不变，即保证了弹性扩缩容，也大大降低了数据同步的难度。\n实际上上述 Slot 和 **节点 **的映射关系在源码中以 **SlotTable 和 Slot **的方式进行表达。源码如下代码块所示。\npublic final class SlotTable implements Serializable { public static final SlotTable INIT = new SlotTable(-1, Collections.emptyList()); // 最后一次更新的时间 epoch private final long epoch; //保存了 所有的 slot 信息； slotId ---\u0026amp;gt; slot 对象的映射 private final Map\u0026amp;lt;Integer, Slot\u0026amp;gt; slots; } public final class Slot implements Serializable, Cloneable { public enum Role { Leader, Follower, } private final int id; //当前slot的leader节点 private final String leader; //最近更新时间 private final long leaderEpoch; //当前slot的follow节点 private final Set\u0026amp;lt;String\u0026amp;gt; followers; } 由于节点在动态变化中、所以 Slot 和 节点的映射也在时刻变化中、那么我们接下来的重点就是 SlotTable 的变更过程。SlotTable 的变更是在 Meta 节点中触发、当有服务上下线的时候会触发SlotTable 的变更、除此之外也会定期执执行 SlotTable的变更。\nSlotTable的整个同步更新步骤如图所示。\n代码参考 com.alipay.sofa.registry.server.Meta.slot.arrange.ScheduledSlotArranger#arrangeSync.\nSlotTable 的定期变更是通过在初始化 ScheduledSlotArranger 时候实例化守护线程不断的 定期执行 内部任务 Arranger 的 arrangeSync 方法来实现 SlotTable 变更的。大致流程如下所示。\n因为负责 SlotTable 的更新是在 MetaServer 中的主节点更新的。\n所以更新 SlotTable的第一步就是判断是否是主节点。主节点才负责真正的 SlotTable 变更步骤。\n第二步是获取最新的 DataServer 节点，因为 重新分配 SlotTable 本质上是 对 DataServer 节点和 slot 槽位之间的映射关系进行重新分配。所以肯定需要获取到当前正在存活的 DataServer 节点信息，从而方便的对之进行 slot 分配。\n(这里获取正在存活的 DataServer 也就是有和 MetaServer 维持心跳的 DataServer, 底层是从 com.alipay.sofa.registry.server.Meta.lease.impl.SimpleLeaseManager中获取，感兴趣可以查看相关源码) 。\n第三部是分配前置校验，实际上一些边界条件的判断、例如 DataServer 是否为空、 DataServer 的大小是否大于配置的 minDataNodeNum，只有满足这些条件才进行变更。\n第四步 执行 trayArrageSlot 方法、进入到该方法内部之中。\n首先获取进程内部锁、实际上是一个 ReentrantLock，这里主要是为了避免定时任务多次同时执行 SlotTable 的分配工作。\nprivate final Lock lock = new ReentrantLock(); 随后便是根据当前的 Data …","date":1649401200,"description":"源码解析｜SlotTable","dir":"projects/sofa-registry/code-analyze/code-analyze-slottable/","fuzzywordcount":8900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8705a6ead8d88f09270c5c19a3f6e6e6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","publishdate":"2022-04-08T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","summary":"SOFARegistry 对于服务数据是分片进行存储的，因此每一个 data server 只会承担一部分的服务数据，具体哪份数据存储在哪个 data server 是有一个称为 SlotTable 的路由表提供的，sessio","tags":["“源码解析”"],"title":"源码解析｜SlotTable","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","wordcount":8810},{"author":"宋国磊","categories":"SOFAStack","content":" 本篇主要对 SOFARegistry 的数据同步模块进行解析，对于注册中心的概念以及 SOFARegistry 的基础架构不做过多阐述，相关介绍可以见海量数据下的注册中心 - SOFARegistry 架构介绍\n本文主要写作思路大致分为下面 2 个部分：第一部分借助 SOFARegistry 中的角色分类来说明哪些角色之间会进行数据同步，第二部分对数据同步的具体实现进行解析。\nSOFARegistry 的角色分类 如上图，SOFARegistry 包含 4 个角色：\n 角色 说明 Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。 SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。 DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。 MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。 在这 4 个角色中，MetaServer 作为元数据服务器本身不处理实际的业务数据，仅负责维护集群 SessionServer 和 DataServer 的一致列表，不涉及数据同步问题；Client 与 SessionServer 之间的核心动作是订阅和发布，从广义上来说，属于用户侧客户端与 SOFARegistry 集群的数据同步，可以见：https://github.com/sofastack/sofa-registry/issues/195，因此不在本文讨论范畴之内。\nSessionServer 作为会话服务，它主要解决海量客户端连接问题，其次是缓存客户端发布的所有 pub 数据；session 本身不持久化服务数据，而是将数据转写到 DataServer。DataServer 存储服务数据是按照 dataInfoId 进行一致性 Hash 分片存储的，支持多副本备份，保证数据高可用。\n从 SessionServer 和 DataServer 的功能分析中可以得出：\n SessionServer 缓存的服务数据需要与 DataServer 存储的服务数据保持一致 DataServer 支持多副本来保证高可用，因此 DataServer 多副本之间需要保持服务数据一致。 SOFARegistry 中对于上述两个对于数据一致性保证就是通过数据同步机制来实现的。\n数据同步的具体实现 下面主要介绍数据同步的实现细节，主要包括 SessionServer 和 DataServer 之间的数据同步 和 DataServer 多副本之间的数据同步两块。\nSessionServer 和 DataServer 之间的数据同步 SessionServer 和 DataServer 之间的数据同步，是基于推拉结合的机制\n 推：DataServer 在数据有变化时，会主动通知 SessionServer，SessionServer 检查确认需要更新（对比 version） 后主动向 DataServer 获取数据。\n 拉：除了上述的 DataServer 主动推以外，SessionServer 每隔一定的时间间隔，会主动向 DataServer 查询所有 dataInfoId 的 version 信息，然后再与 SessionServer 内存的 version 作比较，若发现 version 有变化，则主动向 DataServer 获取数据。这个“拉”的逻辑，主要是对“推”的一个补充，若在“推”的过程有错漏的情况可以在这个时候及时弥补。\n 关于推和拉两种模式检查的 version 有一些差异，可以详见下面 推模式下的数据同步 和 拉模式下的数据同步 中的具体介绍\n 推模式下的数据同步流程 推模式是通过 SyncingWatchDog 这个守护线程不断 loop 执行来实现数据变更检查和通知发起的。\n// 这里遍历所有的 slot for (SlotState slotState : slotTableStates.slotStates.values()) { try { sync(slotState, syncSessionIntervalMs, syncLeaderIntervalMs, slotTableEpoch); } catch (Throwable e) { SYNC_ERROR_LOGGER.error( \u0026amp;quot;[syncCommit]failed to do sync slot {}, migrated={}\u0026amp;quot;, slotState.slot, slotState.migrated, e); } } 按 slot 分组汇总数据版本。data 与每个 session 的连接都对应一个 SyncSessionTask，SyncSessionTask 负责执行同步数据的任务，核心同步逻辑在com.alipay.sofa.registry.server.data.slot.SlotDiffSyncer#sync\n方法中完成，大致流程如下面时序图所示：\n这上图圈红部分的逻辑第四步，根据 dataInfoId diff 更新 data 内存数据，这里仅处理了被移除的 dataInfoId，对于新增和更新的没有做任务处理，而是通过后面的第 5 -7 步来完成；这么做的主要原因在于避免产生空推送导致一些危险情况发生。\n第 5 步中，比较的是所有变更 dataInfoId 的 pub version，具体比较逻辑参考后面 diffPublisher 小节中的介绍。\n数据变更的事件通知处理 数据变更事件会被收集在 DataChangeEventCenter 的 dataCenter2Changes 缓存中，然后由一个守护线程 ChangeMerger 负责从 dataCenter2Changes 缓存中不断的读取，这些被捞到的事件源会被组装成 ChangeNotifier 任务，提交给一个单独的线程池(notifyExecutor)处理，整个过程全部是异步的。\n拉模式下的数据同步流程 拉模式下，由 SessionServer 负责发起， com.alipay.sofa.registry.server.session.registry.SessionRegistry.VersionWatchDog\n默认情况下每 5 秒扫描一次版本数据，如果版本有发生变更，则主动进行拉取一次，流程大致如下：\n需要注意的是，拉模式对推送流程的补充，这里的 version 是每个 sub …","date":1649228400,"description":"源码解析｜数据同步","dir":"projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b78da7b0c10e92e61edba8aeb05d8bac","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","publishdate":"2022-04-06T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","summary":"本篇主要对 SOFARegistry 的数据同步模块进行解析，对于注册中心的概念以及 SOFARegistry 的基础架构不做过多阐述，相关介绍可以见海量数据下的注册中心 - SOFARegistry 架构介绍 本文主要写","tags":["“源码解析”"],"title":"源码解析｜数据同步","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","wordcount":3696},{"author":"Junlong Liu","categories":"SOFAStack","content":" 文｜Junlong Liu\nShopee Digital Purchase \u0026amp;amp; Local Services Engineering\n本文1743字 阅读 6分钟\n贡献者前言 我是在开发工作过程中了解到 Holmes 的，为了保障系统稳定性需要一个性能排查工具，因此也需要一个保留现场的性能监控工具。当我在网上查询该方面的开源库时，发现可用的并不多。后续找到 MOSN 社区的 Holmes ，发现这个开源库功能基本齐全、扩展性也高，特别是 GCHeapDump 这个业界领先的功能，对解决内存升高的问题十分有用。\n2021 年年末了解到的 Holmes 组件，然后开始了解 Holmes 所在的 MOSN 社区。Holmes 作为性能排查工具，核心功能是及时发现性能指标异常，并对系统进行 Profiling。\n由于 Holmes 还处于萌芽期，除了 Readme 之外的文档资料并不多。还有一些 Holmes 当时不支持的功能，比如动态配置调整与上报。Holmes 当时也还没发布第一个版本，但是自己对这方面也有兴趣和理解，于是在 GitHub 上提了几个 Issue 讨论，社区回复的速度十分快。后续在社区前辈们的指导下提了 PR，也因此通过 Holmes 的代码设计学习到了很多关于开源组件的设计理念。\n因此我决定参与开源社区并贡献代码，以解决实际需求。有了一定的了解和经验之后，通过和人德前辈讨论，总结这样一篇分享文章。\n本文将介绍 Holmes 的使用场景、快速开始案例、多个监控类型、设计原理、扩展功能与如何借助 Holmes 搭建起一套简单的性能排查系统，欢迎大家留言指导。\nHolmes 使用场景 对于系统的性能尖刺问题，我们通常使用 Go 官方内置的 pprof 包进行分析，但是难点是对于一闪而过的“尖刺”，开发人员很难及时保存现场：当你收到告警信息，从被窝中爬起来，打开电脑链接 VPN，系统说不定都已经重启三四趟了。\nMOSN 社区的 Holmes 是一个基于 Golang 实现的轻量级性能监控系统，当应用的性能指标发生了异常波动时，Holmes 会在第一时间保留现场，让你第二天上班可以一边从容地喝着枸杞茶，一边追查问题的根因。\nQuick Start 使用 Holmes 的方式十分简单，只需要在您的系统初始化逻辑内添加以下代码：\n// 配置规则 h, _ := holmes.New( holmes.WithCollectInterval(\u0026amp;quot;5s\u0026amp;quot;), // 指标采集时间间隔 holmes.WithDumpPath(\u0026amp;quot;/tmp\u0026amp;quot;), // profile保存路径 holmes.WithCPUDump(10, 25, 80, 2 * time.Minute), // 配置CPU的性能监控规则 holmes.WithMemDump(30, 25, 80, 2 * time.Minute),// 配置Heap Memory 性能监控规则 holmes.WithGCHeapDump(10, 20, 40, 2 * time.Minute), // 配置基于GC周期的Heap Memory 性能监控规则 holmes.WithGoroutineDump(500, 25, 20000, 100*1000, 2 * time.Minute), //配置Goroutine数量的监控规则 ) // enable all h.EnableCPUDump(). EnableGoroutineDump(). EnableMemDump(). EnableGCHeapDump().Start() 类似于 holmes.WithGoroutineDump(min, diff, abs,max,2 * time.Minute) 的 API 含义为:\n当 Goroutine 指标满足以下条件时，将会触发 Dump 操作。\n当 Goroutine 数大于 Max 时，Holmes 会跳过本次 Dump 操作，因为当 Goroutine 数过大时，Goroutine Dump 操作成本很高。\n2 * time.Minute 是两次 Dump 操作之间最小时间间隔，避免频繁 Profiling 对性能产生的影响。\n更多使用案例见文末的 Holmes 使用案例文档。\nProfile Types Holmes 支持以下五种 Profile 类型，用户可以按需配置。\nMem: 内存分配\nCPU: CPU 使用率\nThread: 线程数\nGoroutine: 协程数\nGCHeap: 基于 GC 周期监控的内存分配\n指标采集 Mem、CPU、Thread、Goroutine 这四种类型是根据用户配置的 CollectInterval，每隔一段时间采集一次应用当前的性能指标，而 gcHeap 时基于 GC 周期采集性能指标。\n本小节会分析一下两种指标。\n根据 CollectInterval 周期采集 Holmes 每隔一段时间采集应用各项指标，并使用一个固定大小的循环链表来存储它们。\n根据 GC 周期采集 在一些场景下，我们无法通过定时的 memory dump 保留到现场。比如应用在一个 CollectInterval 周期内分配了大量内存，又快速回收了它们。此时 Holmes 在周期前后的采集到内存使用率没有产生过大波动，与实际情况不符。\n为了解决这种情况，Holmes 开发了基于 GC 周期的 Profile 类型，它会在堆内存使用率飙高的前后两个 GC 周期内各 Dump 一次 Profile，然后开发人员可以使用 pprof \u0026amp;ndash;base 命令去对比两个时刻堆内存之间的差异。\n根据 GC 周期采集到的数据也会放在循环列表中。\n规则判断 本小节介绍 Holmes 是如何根据规则判断系统出现异常的。\n阈值含义 每个 Profile 都可以配置 min、diff、abs、coolDown 四个指标，含义如下:\n当前指标小于 min 时，不视为异常。\n当前指标大于 (100+diff)100% 历史指标，说明系统此时产生了波动，视为异常。\n当前指标大于 abs (绝对值)时，视为异常。\nCPU 和 Goroutine 这两个 Profile 类型提供 Max 参数配置，基于以下考虑：\nCPU 的 Profiling 操作大约会有 5% 的性能损耗，所以当在 CPU 过高时，不应当进行 Profiling 操作，否则会拖垮系统。\n当 Goroutine 数过大时，Goroutine Dump 操作成本很高，会进行 STW 操作，从而拖垮系统。（详情见文末参考文章）\nWarming up 当 Holmes 启动时，会根据 CollectInterval 周期采集十次各项指标，在这期间内采集到的指标只会存入循环链表中，不会进行规则判断。\n扩展功能 除了基本的监控之外，Holmes 还提供了一些扩展功能：\n事件上报 您可以通过实现 Reporter 来实现以下功能：\n发送告警信息，当 Holmes 触发 Dump 操作时。\n将 Profiles 上传到其他地方，以防实例被销毁，从而导 …","date":1649142000,"description":"社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析","dir":"blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"87409f8ec80db088a42f856f0baf16da","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","publishdate":"2022-04-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","summary":"文｜Junlong Liu Shopee Digital Purchase \u0026amp; Local Services Engineering 本文1743字 阅读 6分钟 贡献者前言 我是在开发工作过程中了解到 Holmes 的，为了保障系统稳定性需要一个性能排查工具，","tags":["SOFAStack"],"title":"社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析","type":"blog","url":"/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","wordcount":2934},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@ 毛晨斌 提问：\n 使用 Layotto 是不是客户端代码需要重新实现，全部调用 Layotto 提供的API？多少正式的项目正在使用 Layotto?\n A：目前蚂蚁的落地用户将客户端 SDK，改成调用 Layotto；现在在搞无侵入方案。\n 开源版服务器端支持哪些中间件，客户端无侵入支持哪些中间件？\n A：1. 已经落地的方案是：将各种中间件的 Java SDK，改成调用 Layotto （比如把 xxx-MQ-sdk 内部逻辑改成调layotto pubsub API，但是对业务代码暴露的接口不变)。业务系统需要升级下 SDK，业务代码不用改。这部分没开源，因为是改内部中间件的 SDK，这些中间件本身没开源。 2. 开源版服务器端支持那些中间件：每类 API 有支持的组件列表。 https://mosn.io/layotto/#/zh/component_specs/sequencer/common 其中 state API、pubsub API 因为复用了 Dapr 的组件，所有 Dapr 组件都支持。https://docs.dapr.io/zh-hans/reference/components-reference/supported-state-stores/\n3.客户端支持哪些：目前有 .net java go 的 Layotto SDK，有个 layotto-springboot 刚合并。SDK 在 https://github.com/layotto\n 关于无侵入方案：后面想把协议转换的事情放到 Layotto 做、让用户接入 Layotto 时不用改客户端 SDK，不过方案还在讨论，最近会写个 proposal。 5.现在还没有现成的客户端无侵入 SDK，老系统接入 Layotto 需要改原来的 SDK。\n「SOFABolt」：https://github.com/sofastack/sofa-boot\n黄润良 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?upstream 的 ip access 日志怎么打印来访日志呢，主要是负载均衡后访问到后段的哪个 IP?\n A：你要在 errorlog 打印吗？你可以配置 accesslog，一个请求一条的。你的 tracelog 也可以打印的。https://github.com/mosn/mosn/blob/master/pkg/log/accesslog.go\n [WARN][downStream]reset stream reason ConnectionTermination[proxy][downstream]processError=downstreamReset proxyld:2204350,reason:ConnectionTermination\n A：downstream 的连接断链了。比如你 curl 访问 MOSN，在 reponse 回复之前 Ctrl+C 终止断链接，MOSN 就会打印这个日志，也就是还没有回复请求，client 就断链了。 然后 client 自己有超时，可能就断链了。\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nHolmes 本周发布 Holmes 发布 v1.0 版本\nHolmes 是 MOSN 社区开源的 go 语言 continous profiling 组件，可以自动发现 cpu、 memory、goroutine 等资源的异常，并自动 dump 异常现场 profile，用于事后分析定位。也支持上传 profile 到自动分析平台，实现自动问题诊断、报警。\n「发布报告」：https://github.com/mosn/holmes/releases/tag/v1.0.0\n「Holmes 原理介绍」：https://mosn.io/blog/posts/mosn-holmes-design/\n本周推荐阅读 HAVE FUN | Layotto 源码解析\n 异构注册中心机制在中国工商银行的探索实践\n Nydus 镜像加速插件迁入 Containerd 旗下\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1648796400,"description":"SOFA Weekly | 开源新知、本周 QA、新手任务","dir":"blog/sofa-weekly-20220401/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b94eecd772ed0839dc842cdafb587990","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220401/","publishdate":"2022-04-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220401/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源新知、本周 QA、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220401/","wordcount":1838},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFAMeetup\u0026amp;amp;木兰技术开放日（云原生专场）\n 活动时间：2022 年 04 月 01 日（周五）09:30-12:00\n 活动形式：线上直播\n 资料下载：\n 《如何建立云原生时代的 DevOps 工具链》\n《在大规模集群中落地 Layotto 这种多运行时架构是一种什么样的体验》\n《云原生多集群治理实践》\n《蚂蚁服务发现的大规模实践与展望》\n活动议程 活动回顾 直播主题：木兰技术开放日\u0026amp;amp;SOFAMeetup（云原生专场）\n直播时间：2022 年 4 月 1 日 上午 9:30\n议题分享：\n《中国木兰社区助力云原生扬帆远航》 王庆 英特尔研发总监、木兰开源社区技术委员会成员\n 嘉宾简介：\n王庆，英特尔软件与先进技术事业部云基础设施软件研发总监、开放基础设施基金会个人独立董事、Linux 基金会下属 SODA 基金会外联委员会主席。木兰开源社区技术委员会成员、中国计算机学会CCF开源发展委员会常务委员。\n曾经参与或领导团队开发 Xen、tboot、Yocto、OpenStack 等开源项目。 目前，他和他的团队正在积极致力于云计算、云原生、边缘计算、网络和存储、以及云性能评估与优化等方向，涵盖 Kubernetes、Containerd、Istio、Envoy、Ceph、Akraino 等等。该团队多年来和业界建立了良好的合作关系，是开源云计算软件的一支中坚力量。\n《如何建立云原生时代的 DevOps 工具链》 刘新 都广科技创始人、建木核心开发者。\n 嘉宾简介：\n刘新，都广科技创始人、建木核心开发者。\n从事软件开发与架构设计工作超过 10 年。 曾在通讯、金融、医疗与云计算等行业担任过首席架构师、技术总监、产品总监和CTO等技术职务。\n个人主要兴趣在分布式架构、DevOps、系统优化、工程质量提升等方面。 目前主要精力在开源建木社区运营并负责后端代码的开发贡献。\n议题简介：\n云原生离不开 DevOps，DevOps 作为云原生架构落地的三驾马车的重要性不言而喻。而 DevOps 的成功实施，往往依赖一组集成化的工具链。那么在当前 DevOps 工具百花齐放的情况下，云原生时代的 DevOps 工具链又应该如何建立呢？\n《在大规模集群中落地 dapr 或 Layotto 这种多运行时架构是什么样的体验》 周群力（目前在蚂蚁集团中间件团队负责 Layotto 项目研发）\n 嘉宾简介：\n周群力（花名：仪式）目前在蚂蚁集团中间件团队负责 Layotto 项目研发\n议题简介：\n随着 Service Mesh 在蚂蚁集团内部的大规模落地，我们逐渐遇到了新的挑战，这让我们迫切的寻找新的解决方案。 Service Mesh 通过引入 sidecar 来简化服务治理，而 dapr 这种“多运行时”项目告诉大家：sidecar 能做的事情远不止于此。\n\u0026amp;ldquo;多运行时\u0026amp;rdquo;这种架构真的有这么好么？会不会太过理想化？\n实际落地时会踩什么坑，怎么解决，最终又能带来什么价值？\n在大规模集群中，落地 dapr或layotto 这种多运行时架构是什么样的体验？\n听众收益：\n了解蚂蚁集团在Service Mesh大规模落地以后遇到的新问题以及对于如何解决这些问题的思考。\n了解“多运行时架构”是什么，解决什么问题 了解目前“多运行时架构”相关开源项目在大规模集群落地时会遇到什么问题，有什么不足，如何解决，以及最终带来什么收益 帮助同样在做“多运行时架构”项目的朋友们躲坑、少走弯路。\n《云原生多集群治理实践》 徐迪 腾讯云技术专家，Clusternet 项目发起人。\n 嘉宾简介：\n腾讯云技术专家，Clusternet 项目发起人。在云原生领域有着丰富的经验，也是国内较早参与 Kubernetes 社区的开发者。热爱开源，拥抱开源，并多次在 KubeCon 各大峰会上发表演讲。\n议题简介：\n在过去的数年里，云计算领域经历了多次巨大的变革，当前越来越多的组织将应用部署在本地和云上的多个基础设施平台上，这些平台可能是两个公共云服务提供商，或者两个私有云，或者多地域的边缘云。新的形态导致基础设施的管理和应用治理的方式发生变化，传统的技术架构与管理方式增加了复杂性和风险，难以满足跨多个平台的应用服务部署和治理的挑战，代表业内最新理念的 Clusternet 项目应运而生。在这次演讲中，你将了解到 Clusternet 的最新进展和先进特性。\n《蚂蚁服务发现的大规模实践与展望》 肖健 目前在蚂蚁集团中间件团队负责 SOFARegistry 项目研发\n 嘉宾简介：肖健（花名：昱恒）目前在蚂蚁集团中间件团队负责 SOFARegistry 项目研发\n议题简介：\nnaming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。\n本次分享将会包含以下内容：\n 蚂蚁内部实践\n naming在云原生时代下的发展方向及趋势\n 总结和展望\n 听众收益：\n 了解蚂蚁集团在SOFARegistry新挑战及云原生时代的思考。\n 了解SOFARegistry实践经验。\n 了解蚂蚁集团对未来naming的思考及naming在云原生方向上的探索。\n 了解未来SOFARegistry的发展和相关的社区动向。\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1648796400,"description":"SOFAMeetup\u0026木兰技术开放日-云原生专场","dir":"activities/sofa-meetup-14/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"89cf0108c9b9e15c842c69bdc4a95876","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-14/","publishdate":"2022-04-01T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-14/","summary":"概要 活动主题：SOFAMeetup\u0026amp;木兰技术开放日（云原生专场） 活动时间：2022 年 04 月 01 日（周五）09:30-12:00 活动形式：","tags":["SOFA"],"title":"【活动回顾】《SOFAMeetup\u0026木兰技术开放日-云原生专场》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-14/","wordcount":2074},{"author":"Carver_007","categories":"SOFAStack","content":" 为了支撑超大规模集群以及大内容传输的支持，增加传输效率，减少网络带宽，考虑对消息进行压缩处理，SOFARegistry的data和session以及session和client (目前只有go支持）添加了对压缩数据传输的支持，同时增加缓存来减少压缩带来的较高的cpu的消耗。\n SOFARegistry 通讯默认支持了哪些压缩算法 目前 SOFARegistry 默认支持了 gzip 和 zstd 两种压缩算法。 gzip 是目前使用最广泛，压缩比较高的一种压缩算法。 zstd 是由 Facebook 的 Yann Collet 开发的一个无损数据压缩算法，Zstandard 在设计上与DEFLATE（.zip、gzip）算法有着差不多的压缩比，但是相比 gzip 有更高的压缩和解压缩速度。\n 两种压缩的基本实现代码如下： 整体结构如下如： CompressUtils 工具类采用静态 Map 对象（compressorMap），以编码方式为 key，以具体编码对应的压缩对象为 value 进行装载，然后待其使用的时候通过编码方式进行获取对应的编码对象实现类。 启动的时候装载到一个 Map 对象，key 为上图的两种编码常量，value 为具体实现类。当需要压缩的时候通过一下 find 方法或者重载方法进行获取具体压缩对象。代码如下：\n缓存的使用 由于压缩和解压缩的对资源的消耗极大，SOFARegistry采用了Google的Guava缓存来提升部分性能，当需要获取压缩的时候首选从缓存中获取，缓存中没有, 才进行压缩操作，同时将压缩结果缓存起来，以便下次获取的时候能直接获取。 具体代码细节参考如下：\n 小注：默认采用hession进行序列化\n 3.数据推送以及通讯两端的数据协商机制 发送端压缩对象的选择由订阅者接收端配置信息决定，所以可以保证发送端和接收端的压缩格式的统一。\n小结： SOFARegistry 是一种定位大型金融级分布式注册中心，数据通信定位偏向于大数据包大流量，因此对于数据传输效率和数据安全较为关注，采用高效的压缩方式，能有效的增加传输效率和使用安全性。目前支持的两种压缩方式都是市面上主流的压缩算法，同时配合这缓存的机制，极好的解决了大数据包带来大流量对网络带宽的压力，因此非常适合大型项目，但是相较于小型项目，这种压缩机制就显得很多余，压缩带来较高的 cpu 压力，因此 SOFARegistry 同时支持关闭压缩传输方式，以支持一些小型项目，具体使用根据业务来定。\n","date":1648623600,"description":"源码解析｜通讯数据压缩","dir":"projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1eea84eb058815d251783d98ba763865","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","publishdate":"2022-03-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","summary":"为了支撑超大规模集群以及大内容传输的支持，增加传输效率，减少网络带宽，考虑对消息进行压缩处理，SOFARegistry的data和sessi","tags":["“源码解析”"],"title":"源码解析｜通讯数据压缩","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","wordcount":901},{"author":"SOFAStack","categories":"SOFAStack","content":" 文｜颜高飞\n【工商银行】金融科技研究院云计算实验室\n本文 2651 字 阅读 5 分钟\n前言 中国工商银行于 2014 年率先启动银行核心业务系统的分布式架构转型探索，自主研发了同业领先的分布式服务平台。\n注册中心为服务平台提供了核心的服务发现功能，其健壮性对服务调用的成功率起着至关重要的作用。近年来，随着服务架构落地范围迅速扩大，注册中心性能容量支撑能力面临更高挑战。\n工商银行结合金融业实际运行场景，对注册中心架构进行了深度定制及优化，不断探索性能容量和高可用能力极限。\nPART. 1 问题及挑战 工商银行分布式服务平台选用 zookeeper 作为分布式服务注册中心。\nzookeeper 在业界分布式系统中使用广泛，具有大规模应用场景，为用户提供高效、稳定的分布式协调服务。zookeeper 支持集群化部署、性能可扩展，可用性也较高，主要表现有：\n1、半数存活即可用特性，使其容灾性能较强\n只要选举节点中有过半节点正常工作，集群即可正常对外提供服务。若集群内个别服务器宕机，客户端会自动切换连接至其他可用服务器。\n2、会话机制，使客户端注册信息保持稳定\n客户端与 zookeeper 服务端之间通过心跳保持会话，默认会话超时 40s。若集群正常对外服务，在会话超时后，zookeeper 服务端将剔除客户端注册信息。而若集群整体不可用，会话不会过期，在注册中心集群恢复后，能自动从快照中重新恢复故障前的会话和注册信息，无需外部干预。\n3、集群提供 observer 机制，实现读写分离、流量隔离\nobserver 节点不参与集群选举，只承担客户端连接和请求，提升整体吞吐量；分担选举节点压力，提升集群稳定性。在实施 observer 分组的情况下，还可实现客户端流量隔离。\n在金融业务实际运行场景中，工商银行搭建了以选举节点为核心、扩展部署 observer 节点的 zookeeper 注册中心集群，并在工商银行稳定运行多年。\n理论上，当 zookeeper 注册中心集群出现故障时，服务调用不会受到影响。\n但在实际混沌工程故障演练过程中，我们发现：偶发场景下，分布式服务平台存在因 zookeeper 系统资源故障或其他问题导致影响业务交易的现象。\n具体问题列举如下：\n 问题一：单服务扩容后提供方节点数过多 触及 zookeeper 推送报文 4M 的上限，从而导致 zookeeper 服务器性能压力过大，未能及时处理其他服务注册请求，影响交易。\n 问题二：zookeeper 集群 leader 服务器内存故障 进程僵死后集群重新选举产生新 leader，但集群内部分服务器未及时感知新 leader，导致部分服务提供方掉线，影响交易。\n 问题三：zookeeper 注册数据大幅增大后 集群故障重新选举后 leader 向其他节点同步的数据量过大，服务器网络到达瓶颈，导致部分服务器未及时加入新集群，影响交易。\n基于以上问题，工商银行一方面对 zookeeper 源码进行了深度定制，另一方面开始着手研究提升服务注册和服务发现高可用能力的机制。\nPART. 2 建设多注册多订阅机制，提升服务调用稳定性 为规避单注册中心集群故障而影响服务调用的问题，工商银行构建了多点接入的高可用注册模型（如图 1 所示）。\n说明：上图中 DC1 和 DC2 为 2 个机房，分别部署有 2 个独立的注册中心集群。DC1 和 DC2 中部署的提供方和消费方均注册、订阅自两个注册中心集群。DC1 中的消费方优先使用 DC1 注册中心推送的提供方列表，DC2 中的消费方优先使用 DC2 注册中心推送的提供方列表。\n在同城双机房内独立部署两个 zookeeper 集群，提供方注册服务至双注册中心，消费方也从双注册中心订阅服务。消费方优先使用与其在同一机房内的注册中心推送的数据，当同机房注册中心集群发生故障时，其他机房的注册中心可接管。注册中心集群故障接管过程中，服务正常调用。\n双注册双订阅机制建成后，分布式服务平台多次完美应对了底层系统资源故障、网络隔离等问题，分布式服务注册和服务发现稳定性显著提升。\n基于双 zookeeper 集群部署的双活架构，因双集群注册中心组件技术栈相同，极小概率下仍存在系统性交易风险——若两个 zookeeper 注册中心集群在同一时刻均出现同一类型故障时（比如同时达到性能瓶颈），业务交易仍然可能会受到影响。\n因此，为规避极小概率的系统性风险，工商银行进一步开展异构注册中心建设，追求极致的服务注册和发现高可用能力。\nPART. 3 建设异构注册中心，规避单一技术栈风险 注册中心异构部署，进一步提升高可用能力\n工商银行开展异构注册中心建设，在部署 zookeeper 集群的同时对等部署一套独立的异构注册中心集群。业务系统同时向 zookeeper 和异构注册中心两个集群注册并进行服务订阅（如图 2 所示）。\n异构注册中心与 zookeeper 协同工作，提升注册中心整体对外服务能力。当 zookeeper 集群与异构注册中心任一集群发生系统性故障时，另一注册中心集群可接管（如图 3 所示数据表结构）。\n说明：上图中 zookeeper 集群故障，异构注册中心正常工作，服务仍可正常注册、订阅及调用。\n提出合并订阅机制，使注册中心故障时迁移更加平滑\n工商银行原有多注册中心订阅机制，消费方优先使用某一注册中心推送的提供方列表，仅当该注册中心上无任一可用提供方，消费方才切换使用下一注册中心推送的数据。此时若优先使用的注册中心因故障推送了不完整的提供方列表，消费方集中调用这些提供方，可能导致“提供方负载不均”、“触发并发限流”等问题。\n为保障建设异构注册中心后注册中心故障时迁移更加平滑，工商银行研究并提出了消费方合并订阅机制：在消费方侧合并 zookeeper 和异构注册中心的订阅视图，各注册中心订阅数据合并后再刷新 invoker 缓存。\n即使某注册中心故障推送了空或者不完整的提供方列表，合并后的数据仍是有效的，提高了消费方筛选提供方的效率，提升交易成功率。\n注册中心异构部署和消费方合并订阅机制建成后，混沌模拟注册中心 CPU 满载、内存高负荷、磁盘故障、网络抖动、网络隔离等故障场景，提供方负载均衡，交易无失败，符合预期。同时，合并订阅机制还能额外降低多注册中心模式下消费方缓存提供方列表所占用的内存。\n基于以上技术储备及基础建设，工商银行于 2020 年开展异构注册中心建设，规避行内注册中心单一技术栈风险，进一步提升了注册中心核心组件在整个分布式体系中的高可用能力。\nPART. 4 未来展望 为满足分布式服务平台金融级高可用的需求，工商银行探索并提出异构注册高可用方案，消除了大规模服务注册场景下单一注册中心存在的系统性风险，保障金融系统的稳健运行。\n未来，工商银行将在异构注册的基础上进一步推动单元化部署运维转型，打破注册中心为全局唯一流量枢纽的现状，实现交易流量在单元内部最大限度完成闭环，辅以单元自动切换实现故障隔离，进一步控制区域性故障场景下的故障爆炸半径，全面提升分布式服务平台流量控制、高可用接管能力，为同业微服务架构规模化应用提供最佳实践和范例。\n本周推荐阅读 “SOFA 星球” …","date":1648537200,"description":"异构注册中心机制在中国工商银行的探索实践","dir":"blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"29e6ac47144c6efb8a23731c2f6351d2","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","publishdate":"2022-03-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","summary":"文｜颜高飞 【工商银行】金融科技研究院云计算实验室 本文 2651 字 阅读 5 分钟 前言 中国工商银行于 2014 年率先启动银行核心业务系统的分布式架构转型探索，自主研","tags":["SOFAStack"],"title":"异构注册中心机制在中国工商银行的探索实践","type":"blog","url":"/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","wordcount":2684},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@韩升 提问：\n 问下 SOFABolt 是否可以单独集成到 Spring Cloud 体系中？不依赖与 SOFABoot？还是直接引用 Bolt 的组件，然后使用原生的方式处理？\n A：直接用 Bolt 自己的 API 就行。\n「SOFABolt」：https://github.com/sofastack/sofa-boot\n**沄澈|che ** 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?\n A：要看 SerializerFactory 对 Localdatetime 的支持了。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nHolmes 本周发布 Holmes 发布 v1.0 版本\nHolmes 是 MOSN 社区开源的 go 语言 continous profiling 组件，可以自动发现 cpu、 memory、goroutine 等资源的异常，并自动 dump 异常现场 profile，用于事后分析定位。也支持上传 profile 到自动分析平台，实现自动问题诊断、报警。\n「发布报告」：https://github.com/mosn/holmes/releases/tag/v1.0.0\n「Holmes 原理介绍」：https://mosn.io/blog/posts/mosn-holmes-design/\n本周推荐阅读 SOFAArk Committer 专访｜看它不爽，就直接动手改！\n “SOFA 星球”闯关计划 ——Layotto 飞船\n 探索 SOFARegistry（一）｜基础架构篇\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1648278000,"description":"SOFA Weekly | 开源新知、Holmes 本周发布、新手任务","dir":"blog/sofa-weekly-20220329/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b4b14b0e38ee5d01c12019bbab406c50","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220329/","publishdate":"2022-03-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220329/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源新知、Holmes 本周发布、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220329/","wordcount":1205},{"author":"kuaile-zc","categories":"SOFAStack","content":" 大致代码流程 推送延迟的计算方式 首次订阅和后续推送延迟计算的区分 如何统计各个阶段的耗时 前言： 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析\n 1、大致代码流转流程 起源于此类 com.alipay.sofa.registry.server.session.push.PushProcessor @PostConstruct 注解由 java 源码提供初始化类会运行此方法，那么就从 init() 函数开始我们今天的故事！\n1.初始化 KeyedThreadPoolExecutor 类（com.alipay.sofa.registry.task.KeyedThreadPoolExecutor）\n2.初始化 initTaskBuffer()\n3.创建针对 push 的 cleaner 者创建过程中会将此线程设置为守护者线程 t.setDaemon(true)\n守护者线程：是指在程序运行的时候在后台提供一种通用服务的线程，比如垃圾回收线程就是一个很称职的守护者，并且这种线程并不属于程序中不可或缺的部分。因此，当所有的非守护线程结束时，程序也就终止了，同时会杀死进程中的所有守护线程。反过来说，只要任何非守护线程还在运行，程序就不会终止。\n源码给的默认值\ncoreSize = OsUtils.getCpuCount() * 3 CPU 数量 * 3\ncoreBufferSize = coreSize * 3000\n让我们来看看初始 KeyedThreadPoolExecutor 会发生的故事。\n1.设置基本参数，添加 Prometheus 监控。\n2.通过配置创建 AbstractWorker[] workers 数组类型。\n3.设置每个 worker 线程为\n让我们来看一下 createWorkers（） 这个方法干了什么事。\n1.创建阻塞队列\n2.创建多个 worker 数量根据 coreSize 并且所以的 worker 都共享所有队列\n阻塞队列被包装了一层详解如下：\n前置知识原生阻塞队列具有以下特性 ArrayBlockingQueue：基于数组的阻塞队列实现，在 ArrayBlockingQueue 内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外， ArrayBlockingQueue 内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。\nLinkedBlockingQueue：基于链表的阻塞队列，同 ArrayListBlockingQueue 类似，其内部也维持着一个数据缓冲队列（该队列由一个链表构成），当生产者往队列中放入一个数据时，队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时（LinkedBlockingQueue 可以通过构造函数指定该值），才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而 LinkedBlockingQueue 之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。\ncom.alipay.sofa.registry.task.BlockingQueues 存储队列的变量是 BlockingQueue[] queues 因为入参 array（false）所以最终生成的是数组类型的 LinkedBlockingQueue 阻塞队列 coreSize 个数组 coreBufferSize 个初始队列大小。\n我们可以看到 WorkerImpl 类的结构如下\n我们用图来解析一下 WorkerImpl 的工作原理\n所以当有服务订阅之后会生成订阅任务 WorkerImpl 将会执行任务，然后在任务执行过程中延迟链路跟踪。整个推送结束之后会有回调函数进行统计。\n2.推送延迟的计算方式 创建推送任务的时候 PushTask（）\nPushProcessor 中的都 push（）开启 push 任务\n1.检查是否是停止的推送任务和是否是灰度推送功能。\n2.task.trace.startPush() 开始任务记录当前开始时间值 PushTrace.pushStartTimestamp\n3.检查 push 任务运行情况 如果没有记录则表示正常， 如果已经有记录则：一种情况超时删除任务第二则是重试\n4.task.createPushData() 创建 Push data\n5.放入 push 记录为了未来重试或者异常情况获取记录做判断\n6.创建回调函数，完成 push 任务之后回调函数生效\n回调函数代码如下\nPushClientCallback.onCallback\n回调函数 PushClientCallback(task) onCallback(Channel channel, Object message) 调用了 this.pushTask.trace.finishPush（）结束了整个 push 链路追踪。\n最后算出大量的数据进行追踪 PushTrace.finish()\n3.首次订阅和后续推送延迟计算的区分 见下表/图统计\n4.如何统计各个阶段的耗时 此图为理解链路追踪过程：\n 字段 字段解释 表达式 根据上图分析步骤 首次订阅和后续推送计算方式是否有区别（默认不填为否） 注解 subRegTimestamp 订阅者订阅请求的时候的时间戳 pushStartTimestamp push 推送开始的时间戳 System.currentTimeMillis() 任务开始获取当前时间戳 pushFinishTimestamp push 推送完成的时间戳 System.currentTimeMillis() 结束之后调用结束方法之后获取当前时间戳 pushCause.triggerPushCtx.firstTraceTimes 第一次通知 seesion 数据变更的时间 lastTriggerSession(pushCause.triggerPushCtx.lastTraceTimes) 最后一次触发session(SOFARegistry 的组件之一）进行变更推送 pushCause.datumTimestamp 主动 pub：那时间就是在 data 端触发修改 datum 的时间如果是主动 sub：那时间就是 sub 注册的当前时间 是 lastPushTimestamp 上一次 push 的时间首次订阅：如果是首次订阅，就是订阅注册的时间，用于后续的过滤，防止重复计算已经推送过的数据的延迟。后续推送：上一次 push 的时间 是 lastPushTimestamp 上一次 push 的时间首次订阅：如果是首次订阅，就是订阅注册的时间，用于后续的过滤，防止重复计算已经推送过的数据的延迟。后续推送：上一次 push …","date":1648018800,"description":"源码解析｜推送延迟 trace","dir":"projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"585ac9eb55d6cd8f21a0fd12a313e8d8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","publishdate":"2022-03-23T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","summary":"大致代码流程 推送延迟的计算方式 首次订阅和后续推送延迟计算的区分 如何统计各个阶段的耗时 前言： 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析 1、大致代码流转流程 起","tags":["“源码解析”"],"title":"源码解析｜推送延迟 trace","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","wordcount":2584},{"author":"行动","categories":"SOFAStack","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁集团开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁集团的业务发展驱动下，近十年间已经演进至第六代。\n 本文为《源码解析｜数据倒排索引》，作者行动，来自高德。\n 《源码解析》系列由 SOFA 团队和源码爱好者们出品。\n GitHub 地址：https://github.com/sofastack/sofa-registry\nSOFARegistry 分层设计 我们知道一个典型的服务发布流程是这样的。\n 图1 服务发布流程\n 如上图、服务注册中心在RPC远程调用中的通常是中间协调者的角色，服务发布者Publisher将服务的发布信息（服务名称、ip、端口号等信息)）发布到注册中心 Registry 中、通常保存在 Registry 内部的数据结构中。服务订阅者在第一次调用服务的时候、会通过 Registry 找到所要调用服务的提供者列表。缓存在本地然后通过负载均衡算法找到一个具体的服务提供者。调用这个具体的服务提供者接口。\n了解了一个典型的 RPC 调用的流程、我们来看看 SOFARegistry 作为一个注册中心内部包含哪几种角色。\n Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\n SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\n DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。\n MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n 图2 SOFARegistry 分层设计 如图 2 所示、在 SOFARegistry 中、客户端 client 直接和 session 通讯，而不是传统意义上的Data节点、这种添加中间一层隔离 DataServer 和客户端的做法。主要是为了处理客户端连接风暴。对这种分层设计。\n感兴趣的可以参考 《海量数据下的注册中心 - SOFARegistry 架构介绍》的 “如何支持海量客户端” 章节，这里不再赘述。文章下面也是主要围绕 Session层展开。\nSessionServer 启动过程 SessionServer 模块的各个 bean 在 JavaConfig 中统一配置，JavaConfig 类为 SessionServerConfiguration，启动入口类为 SessionServerInitializer，该类不由 JavaConfig 管理配置，而是继承了 SmartLifecycle 接口，在启动时由 Spring 框架调用其 start 方法。 该方法中调用了 SessionServerBootstrap#start 方法（图 3），用于启动一系列的初始化服务。 从代码中可以看出，SessionServer 服务在启动时，会启动 SessionServer、SessionSyncServer、HttpServer 三个 bolt 服务。在启动这些 Server 之时，DataServer 注册了一系列 bolt Handler 来处理各类消息。\npublic void start() { try { openSessionSyncServer(); startupRetryer.call( () -\u0026amp;gt; { connectMetaServer(); return true; }); startupRetryer.call( () -\u0026amp;gt; systemPropertyProcessorManager.startFetchPersistenceSystemProperty()); startScheduler(); openHttpServer(); startupRetryer.call( () -\u0026amp;gt; { connectDataServer(); return true; }); sessionRegistryStrategy.start(); configProvideDataWatcher.start(); openSessionServer(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Cannot bootstrap session server :\u0026amp;quot;, e); throw new RuntimeException(\u0026amp;quot;Cannot bootstrap session server :\u0026amp;quot;, e); } } SessionServer 保存了哪些数据 在了解了 SessionServer 的启动过程、明白 SessionServer 作为 DataServer 的代理层、有着非常重要的位置。能够分摊一部分对 DataServer 的压力。那么在 SessionServer 在注册的时候会保存了哪些数据呢?\n SessionCacheService 从名称可以看出是缓存数据，当 Subscriber 注册到 SessionServer 中的时候、我们会给 Client 推送 Client 感兴趣的服务提供者信息列表。但是我们不可能在每次 Client 有变化的时候都去 Data层获取数据、这样对 Data 层的压力会很大。在 SessionServer 上缓存数据服务提供者信息可以对 DataServer 层屏蔽 Client 的变化，从而有效减轻 DataServer 的压力。SessionCacheService 内部的 readWriteCacheMap 缓存了服务提供者列表信息。使用 guava cache 缓存数据。数据有 ttl ，除此之外 Data 层有数据变化也会通知 cache 数据失效。\n Subscriber 和 Publisher 会话缓存信息正排索引信息。 SessionServer 的设计之初就是为了和 Client 直接通讯。通过 SessionServer 来负责与 Client 的连接，将每个 Client 的连接数收敛到 1，每个 SessionServer 负责与若干个 Client 连接，这样当 Client 数量增长时，只需要扩容 SessionServer 集群就可以了。 …","date":1648018800,"description":"源码解析｜数据倒排索引","dir":"projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"40d37578e58543cd340847fbdef907c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","publishdate":"2022-03-23T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["“源码解析”"],"title":"源码解析｜数据倒排索引","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","wordcount":4102},{"author":"葛长伟","categories":"SOFAStack","content":" 文｜葛长伟（花名：川朗 )\n蚂蚁集团技术专家\n负责容器镜像加速项目 Nydus 的开发和维护，专注于容器镜像存储、持久存储和文件系统领域。\n本文 1344 字 阅读 4 分钟\n前言 今年 1 月 ，Containerd 社区通过投票接收 Nydus-snapshotter 成为 Containerd 社区的子项目。这是继 ttrpc-rust 之后，蚂蚁容器团队再次向 Containerd 捐赠子项目。\n此举将方便 Nydus 和 Containerd 的开发协同，减少项目迭代过程中可能出现的不兼容问题，也让用户可以更容易地使用 Nydus 镜像加速服务。\n目前 Nydus 已经将 Nydus-snapshotter 的代码迁移到了 Containerd 组织下的新仓库[1]。\nNydus 简介 Nydus 是蚂蚁集团和阿里云共同开源的容器镜像加速项目，属于 CNCF Dragonfly 项目，是其中的镜像服务部分。\nNydus 是在最新的 OCI Image-Spec 基础之上设计的容器镜像加速服务，重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。\nNydus 设计了一个为镜像优化的文件系统—Rafs。\nNydus 镜像可以推送和保存在标准的容器镜像中心，Nydus 镜像格式完全兼容 OCI Image Spec 和 Distribution Spec。成功转换或者创建镜像后，Nydus 镜像会生成一个元数据文件 Bootstrap、若干个数据文件 blob、manifest.json、config.json。\n目前可以通过 Nydusify 、Acceld 或者 Buildkit 创建 Nydus 加速镜像。\n其中，Acceld[2] 是 Nydus 和 eStargz 的开发者正在合作开发的 Harbor 开源企业级镜像中心的一个子项目，它提供了一个通用的加速镜像转换服务和框架。基于 Acceld，Nydus 和 eStargz 可以方便地从 Harbor 触发加速镜像转换。\n与此同时，Nydus 也在开发 Buildkit 相关的支持，在未来也可以直接通过 Buildkit 从 Dockerfile 直接创建加速镜像。\nNydus-snapshotter 是 Containerd 的 Remote Snapshotter 插件，它是一个独立于 Containerd 的进程。\n当集成 Nydus-snapshotter 到 Containerd 后，Nydus-napshotter 在容器镜像准备阶段，只会将 Nydus 镜像的元数据部分 Bootstrap 从镜像中心下载下来，并且创建了一个新的进程 Nydusd。Nydusd 是处理文件系统操作的用户态进程。通过配置，Nydusd 可以作为基于 Linux FUSE 的用户态文件系统 Virtio-fs Vhost-user Backend，甚至可以是 Linux Fscache 的用户态进程。\nNydusd 负责从镜像中心或者对象存储下载文件数据以响应读文件的请求，并可以将文件数据块缓存在 Host 的本地文件系统。\nNydus 特性 Nydus 有如下重要的特性：\n1、镜像层间块级数据去重，可以减少镜像中心的存储成本，降低数据传输的带宽消耗。\n2、Whiteout 文件不会再被打包进 Nydus 镜像。\n3、端到端的数据完整性校验。\n4、作为 CNCF 孵化项目 Dragonfly 的子项目，Nydus 可以接入 P2P 分发系统，以此降低对镜像中心的压力。\n5、支持数据和元数据分离存储。可以将数据保存在 NAS、阿里云 OSS 或者 AWS S3。\n6、支持文件访问行为记录，这样就可以审计和分析容器内应用的访问行为。增强安全能力、优化镜像数据排布。\n除了以上的关键特性，Nydus 可以灵活地配置成 Linux FUSE 用户态文件系统、基于轻量虚拟化技术容器的 Virtio-fs daemon，或者 Linux 内核磁盘文件系统 EROFS 的用户态 on-demand 数据下载服务：\n1、轻量化地集成到 vm-based 容器运行时。现在 KataContainers 正在考虑原生地支持 Nydus 作为容器镜像加速方案。\n2、Nydus 和 EROFS 紧密合作，期望可以直接使用 EROFS 作为容器镜像的文件系统。相关修改的第一部分已经合并入 Linux Kernel v5.16。\nNydus 部署形态 支持 Runc 时，Nydus 作为 FUSE 用户态文件系统进程：\n支持 KataContainers 时，Nydus 作为 Virtio-fs daemon：\n目前 EROFS 正在尝试联合 Fscache 一起，以内核文件系统 EROFS 直接作为容器 Rootfs：\nNydus 将与 Containerd 社区紧密合作，致力于提供更优秀的容器镜像加速方案，提高镜像的存储和分发效率，提供安全可靠的容器镜像服务。\n求贤若渴： 关于蚂蚁集团可信原生技术部安全容器和存储团队\n在蚂蚁集团内部主要负责公司内部容器运行时和云原生存储技术，是公司数据链路的守护者，运行时环境的看门人。我们团队也是 Kata Containers 的创立者，镜像加速服务 Nydus 的发起者，分布式事务服务 Seata 的维护者，也维护着公司内数据访问组件 ZDal/ZCache/XTS 等产品。\n我们是开源精神的信徒，也是实现开源软件和公司业务双赢的践行者。我们是一个关注业务、关注业界前沿、关注基础设施技术，更关心成员成长的团队。目前我们正在招收 2023 届实习生，有兴趣的可以参考蚂蚁集团2023届实习生招聘。\n联系邮箱：liyuming.lym@antgroup.com\n本周推荐阅读 恭喜 李志强 成为 Layotto committer！\n社区文章｜MOSN 路由框架详解\nHAVE FUN | SOFARegistry 源码解析\nBabaSSL：支持半同态加密算法 EC-ElGamal\n","date":1647932400,"description":"Nydus 镜像加速插件迁入 Containerd 旗下","dir":"blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ad4cca5257474169e5ca87f15437235d","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","publishdate":"2022-03-22T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","summary":"文｜葛长伟（花名：川朗 ) 蚂蚁集团技术专家 负责容器镜像加速项目 Nydus 的开发和维护，专注于容器镜像存储、持久存储和文件系统领域。 本文 1344 字 阅读 4 分钟 前","tags":["SOFAStack"],"title":"Nydus 镜像加速插件迁入 Containerd 旗下","type":"blog","url":"/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","wordcount":1715},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@rust-rust 提问：\n 建议开发各种语言的 API。\n A：Java 和 Python 在设计中，争取注册到 jsse 里。\nBabaSSL：https://github.com/BabaSSL\n@会飞的小胖子 提问：\n tengine 现在可使用 BabaSSL 了吗？\n A：tengine master 已经支持，稳定版还得等等。\nBabaSSL：https://github.com/BabaSSL\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nSOFAJRaft 本周发布 发布 1.3.10 版本，主要变更如下：\nFeatures： 优化 read-index 读，增加 maxReadIndexLag 参数设置快速失败阈值\nLogEntry 增加切片读取 API\n在删除 rocksdb 大 range 数据时，优化空间回收速度\n在节点过载时，将原有的快速失败策略修改为反压策略，依赖于这个特性的用户推荐升级\nBug Fixes： 升级 Log4j 以解决安全漏洞\nsnapshot 文件使用 atomic move 避免文件重新命名是被损坏\n修复 Counter demo 不兼容 gRPC 的问题\n修复对 snapshot 并行压缩/解压的配置项错误\n修复在某种竞争条件下 Replicator 可能停止发送心跳的 bug\n「详细参考」：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.10\n本周推荐阅读 SOFAArk Committer 专访｜看它不爽，就直接动手改！\n HAVE FUN | SOFARegistry 源码解析\n 探索 SOFARegistry（一）｜基础架构篇\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1647586800,"description":"SOFA Weekly | Committer 聊天室、SOFAJRaft 本周发布、新手任务","dir":"blog/sofa-weekly-20220318/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"71d080ef0a61bca724b03bf0f44daa07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220318/","publishdate":"2022-03-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220318/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Committer 聊天室、SOFAJRaft 本周发布、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220318/","wordcount":1155},{"author":"连文湧","categories":"SOFAStack","content":" 数据表结构要求 以应用级服务发现元数据表为例\n param type description data_center String local data center revision String revision app_name String appName client_version String clientVersion base_params String base_params service_params String service_params deleted boolean delete or no gmt_create Date create time gmt_modified Date last update time 写入 写入缓存 cachedExecutor.execute 执行缓存写入操作防止无法瞬间处理大量相同数据写入操作。防止大量节点上报相同的应用级服务发现元数据。\npublic V execute(K key, Callable\u0026amp;lt;V\u0026amp;gt; callable) throws Exception { V v = cache.getIfPresent(key); if (v != null) { //发现元素，命中+1 hitCount.increment(); return v; } return cache.get( key, () -\u0026amp;gt; { //未发现元素，未命中+1 missingCount.increment(); onMiss(key); return callable.call(); }); } 二参数的 execute 统计修订号revision的命中和未命中次数统计 metrics，在通讯数据压缩暴露到 prometheus。\n写入数据 protected void refreshEntryToStorage(AppRevisionDomain entry) { try { cachedExecutor.execute( entry.getRevision(), () -\u0026amp;gt; { //判断是否执行replace写入数据 if (appRevisionMapper.heartbeat(entry.getDataCenter(), entry.getRevision()) == 0) { appRevisionMapper.replace(entry); } //省略日志操作 } } cachedExecutor 默认指定 silentMs=10s，当缓存项在指定的时间段内没有更新就会被回收（移除 key），需要等待获取新值才会返回。10s 内没有更新说明数据量不大，也不需要进行写入缓存的操作。\n通过 hearbeat() 底层通过 update 原子判断数据是否存在。刷新 gmt_modified 字段时间防止被误删。\nupdate app_revision set gmt_modified=CURRENT_TIMESTAMP where data_center = #{dataCenter} and revision=#{revision} and deleted = \u0026#39;0\u0026#39; 当 update 没有命中的时候，使用 replace，保证能生成一个新的 id，用于后续的 watch 方法监听表获取元素更新变化，并刷新 gmt_modified 防止字段超时被删除。\nreplace into app_revision( data_center, revision, app_name, client_version, base_params, service_params, deleted, gmt_create, gmt_modified ) values ( #{dataCenter}, #{revision}, #{appName}, #{clientVersion}, #{baseParams}, #{serviceParams}, #{deleted}, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP ) 获取数据增量改变 Watch 数据库没有提供订阅的操作，watch 方法缓存最新 id 值，增量读取数据库中更新的 id 值并更新最新的 id 值保证 lastLoadId 一直保持最新的状态\nprivate void watch() { syncStart(); try { long start = lastLoadId; if (listStableEntries(start, 1).size() == 0) { return; } logger.info(\u0026amp;quot;start watch from {}\u0026amp;quot;, start); long maxId = listToTail( (T entry) -\u0026amp;gt; { container.onEntry(entry); logger.info(\u0026amp;quot;watch received entry: {}\u0026amp;quot;, entry); }, start, 100); logger.info(\u0026amp;quot;end watch to {}\u0026amp;quot;, maxId); lastLoadId = maxId; } finally { syncEnd(); } } listStableEntries 提供从数据库获取最新数据的 id 值的方法，写入数据的方法底层通过 replace 写入，因此一定会有新的 id 生成。\n机制存在问题：如果数据中间出现不连续的间断，无法得到更新后存在间隔的 id 值。\n此方法主要列出所有创建完成 1s 后更新的元素。\nif (entry.getGmtCreate().getTime() \u0026amp;gt;= now.getTime() - DB_INSERT_DELAY_MS) { break; } 其中 DB_INSERT_DELAY_MS=1s\n为什么是 1s？\n内部是分布式数据库，表内数据会被拆分到多个机器上，每台机器批量获取 id 属性，此时如果大量并发插入，可能产生 id 值高的已经入库，而低 id 还没有完全写入，这时 watch 方式会出现问题，漏掉低 id 值的数据，直到 list 调用才能被重新填入。而这种问题产生的间隔很短，因此 1s 的间隔能保证id值较低的数据已经被填入。\nlistToTail 方法返回当前最大可靠 id 值\nprivate long listToTail(EntryCallable\u0026amp;lt;T\u0026amp;gt; callable, final long start, final int page) { long curStart = start; while (true) { List\u0026amp;lt;T\u0026amp;gt; entries = listStableEntries(curStart, page); if (CollectionUtils.isEmpty(entries)) { break; } for (T entry : …","date":1647586800,"description":"源码解析｜数据表监听","dir":"projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1343a0bf78782bc53e05233bbdcde0cf","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","publishdate":"2022-03-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","summary":"数据表结构要求 以应用级服务发现元数据表为例 param type description data_center String local data center revision String revision app_name String appName client_version String clientVersion base_params String base_params service_params String service_params deleted boolean delete or no gmt_create Date create time gmt_modified Date last update time 写入 写入缓存 cachedExecutor.execute 执行缓存写","tags":["“源码解析”"],"title":"源码解析｜数据表监听","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","wordcount":1597},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展\n 活动时间：03 月 17 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#26 解读 BabaSSL ：项目概况和最新进展 从数据存储到网络通信，从密码合规再到隐私计算，这些场景都离不开密码学算法和协议。\nBabaSSL 密码库作为蚂蚁和阿里的统一基础密码库，广泛的应用在各类蚂蚁和阿里的业务当中，提供了 TLS 通信、数据加密、国密合规等关键的密码学相关能力，确保了各项业务平稳、安全、合规的运行。\nBabaSSL 自 2020 年开源以来，在行业内得到了广大用户的使用和验证。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 张成龙（花名：刻一） -蚂蚁集团技术专家\n-负责蚂蚁 BabaSSL 密码库核心研发\n议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:50 BabaSSL 项目的概况和最新进展 张成龙（花名：刻一），蚂蚁集团技术专家，负责蚂蚁 BabaSSL 密码库核心研发\n你将收获 1.了解 BabaSSL 项目的诞生背景\n2.了解 BabaSSL 密码库的主要功能和技术特点\n3.了解 BabaSSL 8.3.0 新功能\n4.了解 BabaSSL 的未来发展趋势\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1647500400,"description":"03 月 17 日周四晚 19 点，线上直播第 26 期。","dir":"activities/sofa-channel-26/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e998e41cd8ea96210efdbecbb3ae0e95","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-26/","publishdate":"2022-03-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-26/","summary":"概要 活动主题：SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展 活动时间：03 月 17 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展","type":"activities","url":"/sofastack.tech/activities/sofa-channel-26/","wordcount":633},{"author":"曹先胜","categories":"SOFAStack","content":" 文｜曹先胜\ne签宝中间件开发\n负责e签宝中间件开发和维护，包括 MQ、网关、微服务、数据同步、全链路压测等\n贡献者前言 「 开源就是在使用中，共同成长的过程 」\n从 2018 年学习 SOFAStack 的一些开源项目，到如今深入使用 MOSN，伴随着 SOFA 走到四周年。\n因为兴趣也接触了不少的开源社区，唯独对 SOFA 社区的组件体验颇多， 例如 SOFAArk、SOFARPC、MOSN。长年混迹在钉钉群里提问题，都能得到及时回复，这对我们研究 MOSN 有很大的帮助。也因此通过 MOSN 的代码设计，学习到了很多关于 Sidecar 的设计理念。\n我们使用 MOSN 的出发点是公司框架使用了很多的中间件，每个中间件有自己的依赖，这些依赖经常性的会发生冲突。虽然我们使用了类似 Spring Boot 的 Pom 管理机制，但升级框架过程中，如果有同学自行引入了 jar 包，就不可避免的会发生 jar 冲突。为了解决这个问题，我们调研了很多方案，最终认为 Service Mesh 是解决这个问题的一个比较合适的方案。\n同时，也调研了一些其他的开源产品，经过内部讨论和各种取舍，我们选择了MOSN。\n在使用 MOSN 时，因为要对接 Eureka，需要进行动态路由，而官网关于路由的文章不是很多。因此，在自己和烈元老师学习后，总结了这样一篇路由分享文章。\nMOSN 作为网络边缘代理组件，路由功能是核心功能，本文将介绍 MOSN 路由如何使用，以及 MOSN 路由的一些高级使用技巧，欢迎大家留言指导。\n路由基本设计 在 MOSN 的路由设计中，Cluster 和 Route 是高度关联的，说白了 Route 的配置，就是为了表达如何准确找到你想找到的 Cluster，另外一个 Cluster 可以有多个 Host 机器。\n例如一个 Cluster 有 100 台机器，其中有 50 台是 v1 版本，50 台是 v2 版本，如何根据一些特定的规则，准确地把请求路由到 v1 版本或者 v2 版本呢？\n再例如，我想根据 Header 里的某个值，再将这个值和“配置中心”里的某个值进行计算，才能找到 Cluster，那么我该如何配置呢？\n 首先，我们看最简单的路由设置。 上图是一个简单的 Json 配置。其中，Cluster Manager 和 Routers 的配置是路由的关键。我们可以根据 Cluster Manager 配置多个 Cluster，每个 Cluster 配置多个 Host。\n然后在 Routers 配置中，根据一些规则，告诉 MOSN 如何将请求路由到 Cluster 中。\n如下图：\n此配置表示，现在有一个 Rouer 配置名为 Server_Router，有一个虚拟主机，可配置多个域名，这里匹配所有域名。\n同时，这个域名有多个路由配置，这里暂且配置了一个路由配置：前缀匹配，只要是 / 开头的，就转发到 ServerCluster 里的 Host 中，也就是下面的 Cluster Manager 配置里的 ServerCluster。\n这样，就实现了一个简单的 MOSN 路由的配置。\n动态路由 Cluster 大部分情况下，如果我们的路由逻辑很简单，例如根据 Header 里的某个名字，找到对应的 Cluster，代码或者配置就是这么写的：\n、、、java router := v2.Router{ // header 匹配 RouterConfig: v2.RouterConfig{ Match: v2.RouterMatch{ Headers: []v2.HeaderMatcher{ // 这个 header 匹配, 就转发到 app.Name cluster. { Name: \u0026amp;ldquo;X-service-id\u0026amp;rdquo;, Value: app.Name, }, }, }, // cluster 名称匹配. Route: v2.RouteAction{ RouterActionConfig: v2.RouterActionConfig{ ClusterName: app.Name, }, }, }, } r.VirtualHosts[0].Routers = append(r.VirtualHosts[0].Routers, router) 、、、\n上面代码的意思是如果 Header 里有 X-service-id 这个 kv，那么就能找到下面 RouteAction 对应的 Cluster 了。\n那如果是更复杂的逻辑呢？\n比如利用请求里的 Header 和“配置中心”的某个值进行计算，如何才能找到 Cluster呢？\n此时，通过配置已经无法解决这个需求，因为这其中涉及到了计算逻辑，MOSN 通过动态配置可以支持该需求。\n如下图配置：\n我们设置了一个（\u0026amp;rdquo;Cluster_Variable\u0026amp;rdquo;: \u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;） 的 KV 配置。\n同时，我们还需要在 StreamFilter 中，利用变量机制设置 key 为 “My-ClusterVariable” 的 Value ，这个 Value 就是计算出来的 Cluster 名称。\n代码如下：\n、、、Java // 先注册这个 key 到变量表中。 func init() { variable.Register(variable.NewStringVariable(\u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;, nil, nil, variable.DefaultStringSetter, 0)) }\nvar clusterMap = make(map[int]string, 0)\nfunc (f *MyFilter) OnReceive(ctx context.Context, headers api.HeaderMap, buf buffer.IoBuffer, trailers api.HeaderMap) api.StreamFilterStatus { l := len(clusterMap) // 找 Cluster cluster := // 执行一些计算 // 设置到上下文变量中。这个 key 必须和配置文件中保持一致。 variable.SetString(ctx, \u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;, cluster) return api.StreamFilterContinue } 、、、\nMOSN Subset 如上面所述，我们经常有在一个集群里有多个版本，如何根据某些标签将请求路由到指定的版本呢？\n通常，我们会使用 Subset 方案，即“子集合”。可在一个 Cluster 里面，为每个应用打标。同时我们的路由也配置相关的配置（MOSN 称为 Metadata），实现较为复杂的路由。\nMOSN 官方文档中，简单介绍了 Metadata 的使用。\n下面让我们更详细的介绍 Subset 的使用：\n上图中左边是 Cluster Host 配置，右边是 Router 配置。\n这个路由配 …","date":1647327600,"description":"社区文章｜MOSN 路由框架详解","dir":"blog/community-article-mosn-routing-framework-explained/","fuzzywordcount":3100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5de6ebad45acd0c8edc9e9b104c8c333","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","publishdate":"2022-03-15T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","summary":"文｜曹先胜 e签宝中间件开发 负责e签宝中间件开发和维护，包括 MQ、网关、微服务、数据同步、全链路压测等 贡献者前言 「 开源就是在使用中，共同成长的","tags":["SOFAStack"],"title":"社区文章｜MOSN 路由框架详解","type":"blog","url":"/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","wordcount":3087},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@麦兜兜 提问：\n 我这边在 MOSN 上新增了一种私有协议，基本路由功能已经跑通了，其他的流量治理相关配置有样例吗？\n A：治理如果是说的限流限速的话，通常 MOSN 里面的 stream filter 基本上都是和协议无关的，都是可以使用的。\n@张宁 提问：\n snapshot 做起来，打快照后会删除日志的，所以调一下打快照的时间间隔。\n SOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 HAVE FUN | SOFARegistry 源码解析\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\nBabaSSL：支持半同态加密算法 EC-ElGamal\n","date":1646982000,"description":"SOFA Weekly | MOSN 社区会议、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220311/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"58a24de0efaa2ed6d21cbdd80894b214","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220311/","publishdate":"2022-03-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220311/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 社区会议、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220311/","wordcount":697},{"author":"王祖熙","categories":"SOFAStack","content":" 文｜王祖熙（花名：金九 )\n蚂蚁集团开发工程师\n负责蚂蚁 Kubernetes 集群容器交付专注于集群交付能力、交付性能及交付 Trace 等相关领域\n—— 数据不出域、可用不可见\n01背 景 随着大数据与人工智能的快速发展，个人隐私数据泄露和滥用时有发生，隐私安全问题也越来越被重视。\n国家于 2020 年施行密码法、2021 年施行个人信息保护法，对个人隐私数据和数据安全加密有更高的要求。\n因此，隐私计算也不断地被提及和关注，源于其有优秀的数据保护作用，使得『数据不出域、可用不可见』，限定了数据的使用场景，防止了数据的泄露，而引起了业界的热捧。\n隐私计算是指在保护数据本身不对外泄露的前提下，实现数据共享和计算的技术集合，共享数据价值，而非源数据本身，实现数据可用不可见。\n 隐私计算对于个人用户来说，有助于保障个人信息安全；\n 对于企业来说，隐私计算是数据协作过程中履行数据保护义务的关键路径；\n 对于政府来说，隐私计算实现数据价值最大化的重要支撑。\n 隐私计算目前在金融、医疗、电信、政务等领域均在开展应用试验，比如：\n银行和金融机构\n在不泄露各方原始数据的前提下，进行分布式模型训练，可以有效降低信贷、欺诈等风险；\n医疗机构\n无需共享原始数据便可进行联合建模和数据分析，数据使用方在不侵犯用户隐私的情况下，可以使用建模运算结果数据，有效推动医疗行业数据高效利用。\n隐私计算的相关技术有多方安全计算 （MPC） 、可信执行环境 （TEE） 、联邦学习 （FL） 、同态加密 （HE） 、差分隐私 （DP） 、零知识证明 （ZKP） 、区块链 （BC） 等等。\n这些技术各有优缺点，隐私计算的产品或者平台也是由这些技术来搭建。\n其中与密码学明显相关的是同态加密，目前同态加密算法的开源项目各有千秋，用户使用比较复杂。BabaSSL 作为基础密码库，应该提供一套简单易用和高效的同态加密算法实现和接口，让上层应用更方便简单地使用同态加密算法。\n此外，随着隐私计算技术的兴起，蚂蚁集团推出了开箱即用、软硬件结合的隐私计算基础设施，一站式解决方案，即可信原生一体机。\nBabaSSL 作为蚂蚁可信原生一体机中的核心基础软件密码库，将同态加密等隐私计算所需的相关密码学能力整合其中，为可信原生一体机的用户带来更加便捷高效的使用体验。\n02 同态加密 同态加密 （Homomorphic Encryption, HE） 是指满足密文同态运算性质的加密算法，按性质分为加法同态和乘法同态：\n加法同态\n乘法同态\n同态加密后得到密文数据，对密文数据进行同态加法或者乘法得到密文结果，将密文结果同态解密后可以得到原始数据直接加法或者乘法的计算结果。\n如下图：\n根据满足加法和乘法的运算次数又分为：全同态加密和半同态加密。\n全同态加密\n（ Fully Homomorphic Encryption, FHE ）\n1.支持任意次的加法和乘法运算\n2.难实现、性能差 （密钥过大，运行效率低，密文过大）\n3.主流算法：Gentry、BFV、BGV、CKKS\n4.需要实现的接口\n半同态加密\n（Partially Homomorphic Encryption, PHE）\n1.只支持加法或乘法中的一种运算，或者可同时支持有限次数的加法和乘法运算\n2.原理简单、易实现、性能好\n3.主流算法：RSA、ElGamal、Paillier\n4.需要实现的接口：\n*（1）KeyGen()： 密钥生成算法，用于产生加密数据的公钥 PK（* Public Key）和私钥 SK（Secret Key），以及一些公共参数 PP（Public Parameter）。\n*（2）Encrypt()： 加密算法，使用 PK 对用户数据 Data 进行加密，得到密文 CT（Ciphertext）。*\n*（3）Decrypt()： 解密算法，使用 SK 对密文 CT 解密得到数据原文 PT（Plaintext）。*\n*（4）Add()： 密文同态加法，输入两个 CT 进行同态加运算。*\n*（5）Sub()： 密文同态减法，输入两个 CT 进行同态减法算。*\n*（6）ScalaMul() 或者 Mul() ：密文同态标量乘法，输入一个 CT 和一个标量 PT，计算 CT 的标量乘结果。*\nEC-ElGamal 原理\nElGamal 加密算法是基于 Diffie-Hellman 密钥交换的非对称加密算法，EC-ElGamal 是 ECC 的一种，是把 ElGamal 移植到椭圆曲线上来的实现，主要计算有：椭圆曲线点加、点减、点乘、模逆和离散对数。\n以下是 EC-ElGamal 的算法原理：\n公共参数\n1.G：椭圆曲线基点\n2.SK：私钥，SK=d\n（d 是 0 到椭圆曲线的阶 q 之间的随机数）\n3.PK：公钥，PK=dG\n加密\n1.明文 m，随机数 r\n2.计算密文 C：\n（3）明文 m 的取值范围为模 order(G) 的模空间，但实际使用时 m 需限制为较小的数 （例如 32 比特长度） ，否则椭圆曲线离散对数问题 （ECDLP） 无法求解。\n解密\n1.计算 rPK：\n2.计算 mG：\n3.计算 mG 的 ECDLP，获得明文 m。\n密文加法、密文减法\n1.两个密文：\n2 .密文加：\n对 2 个密文的 2 个 ECC 点分别做点加，共 2 个点加，公式如下：\n3.密文减：\n对 2 个密文的 2 个 ECC 点分别做点减，共 2 个点减，公式如下：\n密文标量乘法\n1.密文\n2.对密文的 2 个 ECC 点分别用 𝑚_2 做点乘，共 2 个点乘，公式如下：\n3.如上公式与明文m2m1的同态加密结果一致：\n这里 r=m2r1\n03 算法实现 接口定义\n对象相关接口\n1.上下文对象：\nEC_ELGAMAL_CTX，该对象用来保存公私钥以及一些其他内部用到的信息，是 EC-ElGamal 算法其他接口的第一个参数。\n接口如下：\n//创建 EC_ELGAMAL_CTX 对象，key 为 ECC 公钥或者私钥的 EC_KEY 对象 2.解密表对象：\nEC_ELGAMAL_DECRYPT_TABLE，该对象用来保存解密表的内部信息。椭圆曲线离散对数问题（ECDLP）只有爆力破解的方法可求解，而爆力破解的速度比较慢，通常的做法是使用小步大步算法（Baby-Step，Giant-Step，BSGS）。总体思想是提前将所有可能的明文结果提前运算后，保存到 hash 表中，下次只需要进行少量的运算和 hash 表查找就可以得到结果，大大提高 ECDLP 的解密效率，但解密表的初始化可能比较慢，而且解密表的实现事关解密速度，后面考虑可以开放接口的实现给上层应用，所以这里先定义了一个解密表的对象和默认实现。\n接口如下：\n//创建 EC_ELGAMAL_DECRYPT_TABLE 对象 //decrypt_negative 为 1 时表示该解密表可以解密负数，初始化解密表时将可能的负数运算后插入到 hash 中。 EC_ELGAMAL_DECRYPT_TABLE *EC_ELGAMAL_DECRYPT_TABLE_new(EC_ELGAMAL_CTX *ctx, int32_t …","date":1646809200,"description":"BabaSSL：支持半同态加密算法 EC-ElGamal进","dir":"blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"efc7daaf960e5998f9fee0a1457a986e","permalink":"https://sofastack.github.io/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","publishdate":"2022-03-09T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","summary":"文｜王祖熙（花名：金九 ) 蚂蚁集团开发工程师 负责蚂蚁 Kubernetes 集群容器交付专注于集群交付能力、交付性能及交付 Trace 等相关领域 —— 数据不出域、可用不可见 01","tags":["SOFAStack"],"title":"BabaSSL：支持半同态加密算法 EC-ElGamal","type":"blog","url":"/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","wordcount":3244},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@冷建伟 提问：\n 启动 SOFABoot 报错：Can not found binding converter for binding type bolt。跟到源码发现：bindingTypeBindingConverterMap 只有 jvm，没有 bolt。跟到源码发现 SPI load 的 converter 只有 JVM。版本：runtime-sofa-boot-starter-3.1.4.jar。想问下是不是要升级我的 SOFA SDK 版本 ？\n A：这个引入 rpc starter 即可。\n@leon 提问：\n SOFARegistry 是不需要用 K8s 吗？\n A：SOFARegistry 在内部是基于 K8s 部署的，提供更细粒度更高性能的服务发现。\n 为什么不是想办法优化 K8s 服务发现性能，而是搞代码侵入性的方案？\n A：基于 K8s 的实现的无侵入式服务发现是云原生下的一套较为后期和理想的方案，这也是 SOFARegistry 后续演进的规划之一。\n目前依然采用侵入的发布订阅模式，一是性能的考量，现有的 K8s 很难支撑起数千万级别数量的服务以及稳定推送延迟的要求；二是迁移有一个过程，对大量现有应用进行服务发现的改造是一个很长周期，无侵入式服务发现会采用逐渐接入的方式。\n目前重点还在于如何更好更稳定的支撑起超大规模集群的问题上。\n@来永国 提问：\n SOFATracer 加了 sofa-tracer-rocketmq-plugin 扩展包，还需要做什么配置吗？\n A：需要配置一下 SendMessageHook 和 ConsumeMessageHook 这两个 hook，分别是：SofaTracerSendMessageHook、SofaTracerConsumeMessageHook。\n本周发布 BabaSSL 开源发布 8.3.0 版本，主要更新如下：\n修复 CVE-2021-4160\nopenssl enc 命令支持 wrap 模式\nASYNC: 支持 job 的嵌套\n支持 TLS 证书压缩 (RFC 8879)\n发行版上游 patch 集合合并 [hustliyilin]\n支持 NTLS session ticket\n支持祖冲之消息完整性算法 128-EIA3\n支持 NTLS 客户端认证\n移除 ARIA 算法\n支持国密合规的软随机数生成器\n支持半同态加密算法 EC-ElGamal\n在 NTLS 中支持 RSA_SM4 加密套件\nARM 平台上提供 SM3 和 SM4 的性能优化\nSM4 算法逻辑优化以提升性能 [zzl360]\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nMOSN 本周发布 发布 MOSN V0.26.0 版本，主要变更如下：\n主要更新如下：\n XProtocol 进行了重构，XProtocol 不再是一种协议，而是便于协议扩展实现的框架\n 新增 ip_access filter，基于来源 IP 的 ACL 控制器\n 支持 go plugin 加载协议转化插件，并支持动态选择协议转换插件\n 支持动态设置上游协议，使用 transcoder filter 来替换 Proxy 中的协议转换\n 其他优化与BUG Fix\n 「详细参考」：\nhttps://mosn.io/blog/releases/v0.26.0/\n本周推荐阅读 BabaSSL 发布 8.3.0｜实现相应隐私计算的需求\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1646377200,"description":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","dir":"blog/sofa-weekly-20220304/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9e14d6832e36d94e116c499a9ef62278","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220304/","publishdate":"2022-03-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220304/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |BabaSSL 发布新版本、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220304/","wordcount":1478},{"author":"小蚂蚁","categories":"SOFAStack","content":" 在近日中国科协召开的 2022“科创中国”年度会议上，中国工程院院士周济发布了 2021“科创中国”开源创新榜单。\n蚂蚁集团开发的可信执行环境隐私计算操作系统 Occlum 入选“科创中国”开源创新榜年度优秀开源产品。\n其中，可信执行环境隐私计算操作系统 Occlum 也是该榜单中唯一聚焦隐私计算领域的入选产品。\nOcclum 发展里程 2015 年 蚂蚁集团开始布局隐私计算，成功推出了 TEE 开源操作系统 Occlum。目前，Occlum 也是蚂蚁集团所有隐私计算业务的 TEE 底座，支撑了蚂蚁隐私计算的核心场景。\n2019 年 Occlum 正式开源，是国内第一个面向可信执行环境(Trusted Execution Environments，简称 TEE)的隐私计算操作系统，解决了云端 TEE 技术额外的功能限制和兼容性问题，降低了隐私计算应用开发门槛。\n目 前 Occlum 已捐赠到由微软、谷歌、IBM、阿里巴巴、腾讯等领先科技公司成立的隐私计算联盟(Confidential Computing Consortium,The LinuxFoundation)，是联盟中唯一由中国发起的项目。\n开源隐私计算操作系统 Occlum 还支持了阿里巴巴、微软等公司的云端隐私计算业务场景和大批隐私计算创业公司的隐私计算平台。国际著名开源项目也在使用 Occlum 开源产品，如 Hyperledger Avalon、Inclavare Container 等。\nOcclum 获得了产、学、研多方认可，相关技术成果已在操作系统领域顶级会议 ASPLOS 2020 发表。\n从 1869 项开源产品中被推选出来，Occlum 长期以来在基础技术领域的努力和坚持得到了认可。\n开源路漫漫，我们也很开心地看到，中国开发者正在成为全球开源社区的重要力量。\n对 SOFAStack - Occlum 感兴趣的话\n👏 等你加入我们！\n本周推荐阅读 BabaSSL 发布 8.3.0｜实现相应隐私计算的需求\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n从 generator 的角度看 Rust 异步代码\n","date":1646290800,"description":"Occlum 入选 2021“科创中国”开源创新榜","dir":"blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3d995f09ef72a3b41105b1315cb3c29f","permalink":"https://sofastack.github.io/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","publishdate":"2022-03-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","summary":"在近日中国科协召开的 2022“科创中国”年度会议上，中国工程院院士周济发布了 2021“科创中国”开源创新榜单。 蚂蚁集团开发的可信执行环境隐私","tags":["SOFAStack"],"title":"Occlum 入选 2021“科创中国”开源创新榜","type":"blog","url":"/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","wordcount":723},{"author":"SOFAStack","categories":"SOFAStack","content":" BabaSSL 8.3.0 稳定版本发布！ 密码学开源项目 BabaSSL 近日发布了 8.3.0 稳定版本，该版本中提供了若干 bug 修复以及较多的新特性支持。\n从具体特性角度来看，BabaSSL 8.3.0 版本在国际前沿技术标准、国内密码合规能力以及国密算法的性能优化上均进行了能力的提升。其中：\n前沿技术标准： RFC8879 所定义的 TLS 证书压缩功能为 TLS 握手带来了很大的性能提升、进一步降低了 TLS 加密通信时的延迟，对于提升用户体验起到了很好的增强，可直接降低 TLS 握手带宽 80% 以上。\n国内密码合规能力： 支持 NTLS session ticket、客户端认证以及 RSA_SM4 加密套件，为目前国内各行业也在进行的国密改造提供了功能上的大力支持；\n而对国密合规的软随机数生成器的支持，更是满足了国密改造过程中的合规性要求。\n国密算法性能优化： 此次 BabaSSL 连同 ARM、阿里云对国密 SM3 和 SM4 算法在 ARM v8 架构上进行了特殊硬件指令的优化，使得 BabaSSL 在具备相关指令集的 ARM 架构 CPU 上可以取得更好的 SM3 和 SM4 的计算性能。\n例如，在阿里云倚天 710上，SM3 获得最高 74% 以及 SM4 算法最高 36 倍的性能提升；此外，SM4 算法逻辑的 C 语言优化，也实现了在通用 CPU 上性能的提升。\nBabaSSL 8.3.0 主要存在如下方面的更新： 修复 CVE-2021-4160\n openssl enc 命令支持 wrap 模式\n ASYNC: 支持 job 的嵌套\n 支持 TLS 证书压缩 (RFC 8879)\n 发行版上游 patch 集合合并 [hustliyilin]\n 支持 NTLS session ticket\n 支持祖冲之消息完整性算法 128-EIA3\n 支持 NTLS 客户端认证\n 移除 ARIA 算法\n 支持国密合规的软随机数生成器\n 支持半同态加密算法 EC-ElGamal\n 在 NTLS 中支持 RSA_SM4 加密套件\n ARM 平台上提供 SM3 和 SM4 的性能优化\n SM4 算法逻辑优化以提升性能 [zzl360]\n 值得一提的是，针对数据安全和隐私保护市场的兴起，BabaSSL 8.3.0 中实现了对半同态加密算法 EC-ElGamal 的支持，隐私计算领域的用户可以便捷的使用该算法实现相应隐私计算的需求，并同时利用 BabaSSL 提供的国密能力实现技术合规。\n此外，BabaSSL 目前作为蚂蚁隐私计算一体机中默认集成的软件密码库，为蚂蚁隐私计算一体机的用户提供统一的密码学 API 接口，方便隐私计算应用程序的开发和调试。\n欢迎下载 BabaSSL 8.3.0 版本，下载地址：\nhttps://github.com/BabaSSL/BabaSSL/releases/tag/8.3.0\nBabaSSL 是什么 ？ BabaSSL 是一个提供现代密码学算法和安全通信协议的开源基础密码库，为存储、网络、密钥管理、隐私计算等诸多业务场景提供底层的密码学基础能力。实现数据在传输、使用、存储等过程中的私密性、完整性和可认证性的保证，为数据生命周期中的隐私和安全提供保护能力。\n作为国内稀缺的密码学开源项目，BabaSSL 填补了国内信息基础设施领域相关产品的空白，是我国建设国产密码学大生态、解决密码学技术“卡脖子”问题、发展前沿密码学技术的关键一环。\n除了在国家商用密码算法领域之外，BabaSSL 还在前沿密码学领域进行了支持，包括隐私计算场景下所需的各种密码学算法以及为了应对量子计算而产生的后量子密码学算法等。\nBabaSSL 对国际和国内的新型技术标准采用快速跟进的策略，因此支持的功能十分丰富。同时基于蚂蚁和阿里海量的用户场景，其性能和稳定性也达到了互联网生产级别。\n自 2020 年开源以来，BabaSSL 也在行业内得到了广大用户的使用和验证，并应用到了众多业务场景里。\nBabaSSL 的前世今生 BabaSSL 诞生于蚂蚁集团和阿里集团内部，目前作为蚂蚁和阿里的统一基础密码库，广泛应用在各类蚂蚁和阿里的业务当中，提供了 TLS、数据存储、国密合规等关键的密码学相关能力，确保了各项业务平稳、安全、合规的运行。\n2020 年进行开源以来，BabaSSL 将蚂蚁和阿里内部所积累的密码学技术能力提供给业界使用，同时在申请商用密码产品软件密码模块一级资质，也是首个有望获得商用密码产品型号证书的开源密码学产品。\n从具体场景来看，有如下三个方面，分别是存储、网络和端上的设备。其中网络服务的场景，是 BabaSSL 最大的支撑场景，例如淘宝、天猫、阿里云等各种涉及到链路加密的服务器端。此外移动端 App，例如支付宝手机 App 中集成了 BabaSSL 来实现多种密码学的能力。\n1. 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了 有了基础国密算法支持，我们在 AnolisOS 上构建出一个围绕国密算法展开的基础软件生态，同时它也是一个全栈国密解决方案：从底层固件，内核，到基础密码学库，在主要链路上做国密改造，最终形成一个完整的基于国密的安全信任链条。\n2. RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海 TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。随着 TLS 1.3+ 国密正式成为了国家/国际层面均认可的标准（RFC8998），我们也正式在 BabaSSL 中支持了相关能力并将其开源，并建设了 BabaSSL 社区。\n3. TLS 握手带宽直降 80%，BabaSSL 是怎么做到的 为了保障数据的安全性，通常使用 TLS/SSL 进行加密传输。当客户端访问服务器后台时，客户端会先和服务器进行 TLS 握手。RFC 8879 TLS Certificate Compression 就是为了解决这个问题，在 TLS 1.3 握手时提供证书压缩功能，大大降低数据传输，减少 TLS 握手的带宽消耗呢。\n4. Tengine + BabaSSL ，让国密更易用！ 国内著名 Web 服务器和反向代理开源软件 Tengine 完成了对 BabaSSL的适配工作。Tengine 对 BabaSSL 提供的特殊 API 进行了适配，并增加对 NTLS 相关能力的支持。无需额外的 patch 或者代码改动，从用户使用的角度进一步提升了便利性。\n对密码学、隐私计算感兴趣的话\n等你加入我们！\n本周推荐阅读 Tengine + BabaSSL ，让国密更易用！\nTLS 握手带宽直降 80%，BabaSSL 是怎么做到的\nRFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n","date":1646204400,"description":"BabaSSL 发布 8.3.0｜实现相应隐私计算的需求","dir":"blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f9693f85dce6fd979f0323ae3797b3cc","permalink":"https://sofastack.github.io/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","publishdate":"2022-03-02T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","summary":"BabaSSL 8.3.0 稳定版本发布！ 密码学开源项目 BabaSSL 近日发布了 8.3.0 稳定版本，该版本中提供了若干 bug 修复以及较多的新特性支持。 从具体特性角度来看，BabaSSL 8.3.0 版","tags":["SOFAStack"],"title":"BabaSSL 发布 8.3.0｜实现相应隐私计算的需求","type":"blog","url":"/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","wordcount":2108},{"author":"李旭东","categories":"SOFAStack","content":" 简介 SOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群，具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n蚂蚁生产集群 — SOFARegistry 支撑 1000 万服务发布者、4000 万服务订阅者，在业务应用大规模变更触发千万级别推送量的场景下，推送延迟的 p99 依然能够保持在 7s 以下。\n《认识 SOFARegistry》 这一系列文章将会基于 SOFARegistry 新版本（V6）的代码，讲解注册中心在超大规模集群场景下落地的解析与实践，同时介绍 SOFARegistry 的各项功能，方便业务落地。\n部署架构 SOFARegistry 现有的架构设计：采用双层存储架构，外加一个负责内部元数据管理的 meta 组件。\nSOFARegistry 的角色分为 4 个: client、session、data、meta。\n角色分工如下：\nClient\n提供应用接入服务注册中心的基本 API 能力，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\nSessionServer ｜ 会话服务器\n负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\nDataServer ｜ 数据服务器\n负责存储具体的服务数据，数据按 dataInfoId 进行分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模增长而扩容。\nMetaServer ｜ 元数据服务器\n负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n借助双层数据分片的架构，SOFARegistry 具有了支撑海量数据的基石\n● 支持海量数据：每台 DataServer 只存储一部分的分片数据，随数据规模的增长，只要扩容 DataServer 服务器即可。\n● 支持海量客户端：连接层的 SessionServer 只负责跟 Client 打交道，SessionServer 之间没有任何通信或数据复制，所以随着业务规模的增长，SessionServer 可以较轻量地扩容，不会对集群造成额外负担。\n数据结构 作为注册中心的基础功能，SOFARegistry 提供发布订阅的接口：Subscriber、Publisher。\n在服务发现场景下，Subscriber 需要通过服务名称从注册中心订阅到多个服务方的地址，进行负载均衡的访问。\n当存在服务方机器宕机时，注册中心通知所有的订阅方从服务列表中摘除这个 IP 地址，这样就不会再访问宕机的机器。\n下面给出简化后的发布者和订阅者的字段，贴合上述服务发现的需求。\nclass Subscriber{ String dataId; // 服务名称 String group; // 业务类型，比如RPC、MSG等等 String instanceId; // 租户名称 String zone; // 所在分区，结合scope实现逻辑隔离 ScopeEnum scope; // 订阅范围: zone、dataCenter、global } class Publisher{ String dataId; String group; String instanceId; String zone; List\u0026amp;lt;String\u0026amp;gt; dataList; // 发布的数据, sofarpc 用法中常见url } 常见用法（JAVA SDK）\n发布者\n// 构造发布者注册表 PublisherRegistration registration = new PublisherRegistration(\u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); // 将注册表注册进客户端并发布数据 Publisher publisher = registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); // 如需覆盖上次发布的数据可以使用发布者模型重新发布数据 publisher.republish(\u0026amp;quot;10.10.1.1:12200?xx=zz\u0026amp;quot;); 订阅者\n// 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { @Override public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, global String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); registration.setScopeEnum(ScopeEnum.global); // 将注册表注册进客户端并订阅数据，订阅到的数据会以回调的方式通知 SubscriberDataObserver Subscriber subscriber = registryClient.register(registration); 更详细的用法文档参考官方文档: https://www.sofastack.tech/projects/sofa-registry/java-sdk/\n特点与优势 这是一张 SOFARegistry 和其他注册中心产品的特性对比图，可以看出相比其他产品，SOFARegistry 在功能特性方面还是不足（未来 SOFARegistry 在特性方面会进行完善）。 SOFARegistry 的主要优势还是在于支撑超大规模集 …","date":1646118000,"description":"探索 SOFARegistry（一）｜基础架构篇","dir":"blog/explore-sofaregistry-1-infrastructure/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ae1a4db92cf2dea8d057ba7dede8c440","permalink":"https://sofastack.github.io/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","publishdate":"2022-03-01T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","summary":"简介 SOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群，具有分布式可水平扩容、容量大、推送延迟低、高可","tags":["SOFAStack"],"title":"探索 SOFARegistry（一）｜基础架构篇","type":"blog","url":"/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","wordcount":3704},{"author":"SOFA 团队","categories":"SOFAStack","content":" 2 月 24 日，MOSN 举办了 2022 年首次的社区会议。\nMOSN 社区在会议上提出了新一年的 Roadmap，社区成员分享了 MOSN 在不同场景下落地实践的经验，以及大家一起大开脑洞，探讨了更多我们可以创造的可能性。\nMOSN 社区 Roadmap MOSN 在 2022 年主要的目标是发布 MOSN 1.0，以及开源一个新的开箱即用的产品。同时推动 MOE （ MOSN 2.0 架构）演进，对接更多的生态组件。\n随着 MOSN 的落地用户越来越多，稳定性建设也是今年的重点发展方向，让大家用得放心。\n社区会议分享嘉宾 来自探探科技、阿里云、去哪儿网的用户，在本次会议中都积极分享了自己的使用案例，供大家借鉴参考。\n探探科技 谢正尧同学详细地列出了 MOSN 落地过程中遇到的问题和踩到的坑，给 MOSN 的后续优化提供了很好的思路。\n有不少坑我们都已经安排上了日程，MOSN 的开发者都赶在填坑的路上。\n阿里云 沐沂同学列出了新财年的规划，和大家分享了边缘的跨集群服务发现场景的租户拆分，以及新的部署形式。\n去哪儿网 佳龙同学比较关注 Roadmap 中的 GC 方面，希望可以引入一些高性能的网络框架，对性能优化方面有更多的需求。\n以及很期待 MOSN 社区的 holmes，希望可以解决查问题时的难题。\nQA 回顾 1.Q：MOE 的落地场景、最佳实践的博客有哪些？\nA：具体内容我们会在 Service Mesh Summit 2022 首届服务网格峰会进行分享。今年会有更多的落地场景，在尝试替换接入层网关，也会试点上线的，可以期待一下！\n2.Q：我可不可以理解为——假如 MOE 在 Envoy 被接收后，可以通过 Go 代码去写一个 filter，让它跑在 Envoy 上，之后我的数据链直接用 Envoy 就可以？\nA：是的，就这个意思。现在我们的 demo 就可以玩起来了，只是有些接口还没标准化，现在我们内部落地的 sofagw 就是这个架构。\n「demo文档」⬇️： https://github.com/mosn/mosn/blob/master/pkg/networkextention/README-cn.md\n3.关于 GC 优化方式的讨论\nA：（1）降低 GC 频率确实是有效的，可以减少长期存活对象的重复 mark。（2）不过这种预分配的，其实不是很灵活，最好的还是动态调整 GC Percent，保持 GC goal 在预期的水位。\n本质上是一个内存换 CPU 的方案，在内存够用的时候，提高 GC goal 的水位。\n我们搞 holmes 内存异常捕获的时候，也考虑过这种情况。https://uncledou.site/2022/go-pprof-heap/\n大家在本次会议中畅所欲言，大开脑洞。也正是与使用用户的沟通交流，让 MOSN 的发展规划和用户需求相辅相承。\n感谢大家的积极配合，在你们的帮助下，MOSN 社区会持续推动性能优化、技术落地，与用户共同成长。\n我们之后还会举办社区会议，比如在 MOSN 发布新版本或者有大进展时。听取用户反馈，同步业界动态，期待下次会议啦～\n想要预定下次的社区会议,了解更多 MOSN 社区动态,钉钉搜索:21992058\n本周推荐阅读 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\nMOSN 多协议扩展开发实践\nService Mesh 在中国工商银行的探索与实践\n云原生运行时的下一个五年\n","date":1646031600,"description":"社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进","dir":"blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ee484f870924be25bf5ccddd91840b89","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","publishdate":"2022-02-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","summary":"2 月 24 日，MOSN 举办了 2022 年首次的社区会议。 MOSN 社区在会议上提出了新一年的 Roadmap，社区成员分享了 MOSN 在不同场景下落地实践的经验，以及大家","tags":["SOFAStack"],"title":"社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进","type":"blog","url":"/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","wordcount":1114},{"author":"陈岸琦","categories":"SOFAStack","content":" 文｜陈岸琦（花名：敖清 )\n蚂蚁集团高级开发工程师\n负责蚂蚁 Prometheus 监控原生功能，在蚂蚁集团的落地与产品化建设\n本文 6566 字 阅读 15 分钟\n前 言 日志和指标是监控不可或缺的两种数据源，为应用系统提供完整的可观测性。\nAntMonitor 作为蚂蚁的统一监控平台，是一款主要以日志方式采集监控数据的监控产品。在社区，开源的云原生监控，主要以 Metrics （指标）的方式实现监控，其中以 Prometheus 为代表。\n并且 Prometheus 监控因其强大的用户功能、结合 PromQL 的数据后分析能力，在业界有广泛的用户群体。实际上已成为开源标准，广泛用于开源 Kubernetes 的集群监控。\nPrometheus 本身是一款单机监控产品，在蚂蚁庞大的高可用集群场景落地，具有一定的局限性和困难，包括但不限于：\n Prometheus 没有提供稳定的、长期的数据存储功能，无法满足蚂蚁场景下对历史数据的查询；\n Prometheus 是有损监控，不保证数据的完整性，无法满足蚂蚁场景下对交易笔数等数据的精确性要求；\n Prometheus 不支持日志监控。\n 但是为了满足用户对 Metrics 监控的需求，经过近两年的努力，我们成功地将 Prometheus 的主要功能融合进了 AntMonitor 的现有架构，提供了一套具有蚂蚁场景特色的集群化解决方案。\n今年大促，我们成功地将 Sigma 集群监控（蚂蚁原生的集群管理和资源调度平台）完整迁移至 AntMonitor。配合告警和大盘，实现了 Sigma 监控的覆盖。AntMonitor 凭借 Sigma 监控的迁移，成功孵化了完善的的云原生 Prometheus 监控能力。\n本文简要介绍了AntMonitor 对 Prometheus 监控功能的支持，以及 Sigma 监控的落地实践。\nPART. 1 海量数据下的采集架构 以下是一段 Prometheus metrics 数据的样例：\nMetrics（指标）数据和日志数据拥有较大差别，包括但不限于：\n第一、日志数据写在磁盘上，每条日志都有标准时间戳，而 Prometheus metrics 是存在内存里，采集时间以拉取的时间为准，因此数据的准确性对调度的准确性有较高要求。\n第二、日志的每次采集均采集增量即可，每次采集的数据量有限，但是 Metrics 数据每次采集均要采集全量，数据的文本大小动辄上百 MB，因此 Metrics 数据量巨大，很容易超限。\n第三、日志数据均需要按照某些固定 schema（数据表结构）作切分清洗、计算聚合，但是原生 Metrics 通常存储单机原始数据。\nAntMonitor 现有的数据链路大致为由 agent 采集日志数据缓存于内存，由 Spark 计算集群从 agent 内存中拉取数据，进行聚合，存储于 CeresDB。\n然而 Metrics 数据不同于日志数据，单机明细数据通常具备可观测性，具备完整的信息。因此通常 Metrics 数据，可以跳过计算步骤，直接进行存储。因此，Metrics 数据在保留单机明细数据的情况下，由 agent 内存和 Spark 拉取的方式已经不合时宜，不仅浪费了计算资源，agent 内存也无法支撑住庞大的 Metrics 数据量。\n因此，我们根据用户的业务需求，提供了两条数据链路：\n 在需要保留单机明细数据的情况下，走基于网关的明细数据采集链路；\n 在需要数据聚合的情况下，走基于 Spark 的聚合数据采集。\n 1.1 基于网关的明细数据采集 为了使保留明细数据跳过计算集群直接存储，我们研发上线了一套专门服务 Metrics 数据的中心化采集 + push 存储的链路。\n中心化采集相对于传统的 agent 采集，不再需要依赖于部署在每台物理机，而是只通过 HTTP 请求的方式采集 Metrics 数据。中心化采集对 Metrics 的采集配置进行结构化的下发和调度，以此满足了 Metrics 采集对时间戳调度精确性的要求。并且，中心采集对采集到的数据不存内存，而是直接以 push 的方式推送给 PushGateway，由 gateway 直接存储至底层 CeresDB。\n这套采集方案，满足了 Metrics 对时间精度和存储单机数据的要求。并且将 Metrics 数据采集与现有的日志采集接耦，使二者互不干扰，解放了对 agent 内存和计算资源的高消耗。\n该套方案已经成功用于蚂蚁 Sigma 等多个技术栈和基础设施的 Prometheus 采集，目前每分钟处理上亿条指标数据。\n1.2 基于 Spark 的聚合数据采集 以 Sigma 为代表的基础设施监控，对单机明细数据有较大需求。但是保留明细数据也有较大的缺点，例如：数据量庞大，对存储消耗较高；数据查询时，耗时和数据读取量巨大。\n但是对于一些业务应用用户，对单机明细数据并不关注，只关注于一些维度的聚合数据。例如，以机房维度、集群维度等。因此在这种场景下，存储明细数据，会造成较大的存储浪费，并且在数据查询时，会带来很差的用户体验。因此在这种场景下，我们保留了目前 AntMonitor 传统的日志链路，对采集的 Metrics 单机明细数据进行了聚合进行存储。在业务不关注单机明细数据的场景下，这条链路拥有明显的好处，节省了存储空间，提升了用户查询的速度。\n但是不同于日志监控的数据聚合，必须由用户配置聚合规则，由于 Metrics 数据本身就包含 schema 信息，我们通过自动化的配置项，自动对 Gauge、Counter、Histogram 等 metric type 自动为用户生成了聚合配置，免去了用户手动配置聚合的繁琐：\n下图总结对比了数据聚合与不聚合的区别和优劣：\nPART. 2 维表体系下的元数据统一 原生 Prometheus 提供多种服务发现机制，如 K8s 服务发现通过 apiserver 可以自动获取发现采集的 targets。但是，AntMonitor 作为一个蚂蚁统一监控系统，显然是不能通过 apiserver 自动发现监控目标。\nAntMonitor 在日志监控的现有基础上，建设有一套较为完善的元数据维表体系，包含了 SOFA、Spanner、OB 等多个蚂蚁技术栈元数据。元数据告诉我们去哪里采集监控数据，对应原生的服务发现机制。为了拉齐原生功能，我们对部分维表进行了必要改造，此处我们以 Sigma 监控的落地实践为例，简要介绍下我们的元数据同步流程。\n2.1 Sigma 元数据同步 AntMonitor 进行 Sigma 监控的前提是要获取元数据，元数据告诉我们去哪里采集监控数据。\n为此，我们设计了基于 RMC（蚂蚁的统一元数据平台） 的 “全量同步+增量同步” 元数据同步方案。前者保证元数据齐全可靠，后者基于 AntQ 实现，保证了元数据的实时性。\n从图中可以看到，为了对齐原生的 staleness 功能，Sigma pod 元数据统一添加了下线 (offline) 这个中间状态。\n原生 Prometheus 通过 relabeling 功能实现采集目标过滤等，还可以通过 metric relabeling 对拉取到 …","date":1645772400,"description":"2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践","dir":"blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a8d933b0202e682ad456783714a58ed6","permalink":"https://sofastack.github.io/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","publishdate":"2022-02-25T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","summary":"文｜陈岸琦（花名：敖清 ) 蚂蚁集团高级开发工程师 负责蚂蚁 Prometheus 监控原生功能，在蚂蚁集团的落地与产品化建设 本文 6566 字 阅读 15 分钟 前 言 日志和指标是监控不可","tags":["SOFAStack"],"title":"2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践","type":"blog","url":"/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","wordcount":4491},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@徐豪 提问：\n 想了解 Ark 动态模块，如何在 IDEA 里面进行开发调试？\n A：这个和普通工程基于 idea 调试没有什么区别的，你的 issue 里面提到要调试模块，那就在安装模块的时候，将断点打在你关注的代码行。\n 目前我没有看到相关的 guide，然后自行尝试，先启动容器，再手工启动模块，感觉没成功，不清楚问题出在哪？\n A：～/logs/sofa-ark 看看有日志吗？\n@孙英雄 提问：\n 请问伙伴们有在用 SOFA 技术栈在非金融的项目开发吗？\n A：有的哈，可以看下使用者登记 https://github.com/sofastack/sofa-rpc/issues/375https://github.com/sofastack/sofastack.tech/issues/5\n@来永国 提问：\n 升 SpringBoot to 2.4.x 还有计划吗？\n A：GitHub 上有一些 exmaple，你可以先玩玩。这个今年在规划了，下个 SOFABoot 版本 3.11.0 将会升级到 Spring Boot 2.4.13。\nhttps://www.github.com/mosn/mosn/tree/master/examples%2Fcn_readme%2Fdubbo-examples\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 技术人聊开源：这并不只是用爱发电\n应用运行时 Layotto 进入 CNCF 云原生全景图\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\n","date":1645772400,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220228/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a61ff0d87e7608cc95b2de68338812bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220228/","publishdate":"2022-02-25T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220228/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220228/","wordcount":838},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践\n 活动时间：02 月 24 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践 Kubernetes 已经成为行业内，容器编排的标准。越来越多的企业开始在生产中使用 Kubernetes，拥抱云原生。\nKubernetes 为什么要持续迭代升级？大规模集群下升级过程将面临哪些问题？如何在复杂问题中找到一条无损升级路子？本次分享将用40分钟时间带你一起庖丁解牛 Kubernetes 的升级难题。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 王连平（花名：烨川） 蚂蚁集团高级工程师。 负责蚂蚁 Kubernetes 集群容器交付方面工作，专注于集群交付能力、交付性能及交付Trace等相关领域。 议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:50 蚂蚁大规模 Kubernetes 集群无损升级实践 王连平（花名：烨川），蚂蚁集团高级工程师\n你将收获 了解大规模 Kubernetes 集群升级核心问题 了解核心问题背后的 Kubernetes 设计理念 了解蚂蚁在解决这些问题的一些思路 一起探讨 Kubernetes 这个庞然大物的未来升级之道 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1645686000,"description":"02 月 24 日周四晚 19 点，线上直播第 25 期。","dir":"activities/sofa-channel-25/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4e7019a0dffc50381dc10af4c627eaf6","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-25/","publishdate":"2022-02-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-25/","summary":"概要 活动主题：SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践 活动时间：02 月 24 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践","type":"activities","url":"/sofastack.tech/activities/sofa-channel-25/","wordcount":655},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区获奖啦 SOFAStack 团队在 segmentfault 思否颁布的2021 年中国技术先锋年度评选中，荣获“中国技术品牌影响力企业” 。\n SOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@Nothing 提问：\n 请教个问题，一个服务的订阅者实例数很多的情况下，如果所有订阅者都与 provider 建立连接，provider 的连接数压力大，SOFARegistry 是怎么考虑这种情况的?\n A：目前正在做 host subset 的设计，注册中心端会直接进行分片，减少客户端压力。现在开源版本的 SOFARegistry 还不具备这个的能力，我们内部也是采用全链接。可以了解一下 MOSN ，MOSN 有类似分片功能，内部也有大规模落地。\n@老段 提问：\n 如果启动三个节点的话，停掉一个节点，系统就会一直选举，不再提供服务了；如果启动五个节点的话，停掉两个节点，系统就会一直选举，也不再提供服务了。这个正常么？\n A：不正常，我这边 3 个节点，kill 一个 follower 完全没影响，kill leader 也可以很快选举完成。不会一直选举，服务可以提供，只不过日志里会去找那个挂了的节点。\n@张永欣 提问：\n MOSN 怎么配置 dubbo 连接，支持自发现 dubbo 服务吗？\n A：github 上有一些 exmaple，你可以先玩玩：\nhttps://www.github.com/mosn/mosn/tree/master/examples%2Fcn_readme%2Fdubbo-examples\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 技术人聊开源：这并不只是用爱发电\n应用运行时 Layotto 进入 CNCF 云原生全景图\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\n","date":1645167600,"description":"SOFA Weekly |荣获“中国技术品牌影响力企业”、开发者的搬砖日常、QA 整理","dir":"blog/sofa-weekly-20220218/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ba96ccb01c0806da34a4f846db7ccdec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220218/","publishdate":"2022-02-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220218/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |荣获“中国技术品牌影响力企业”、开发者的搬砖日常、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220218/","wordcount":990},{"author":"金融级分布式架构","categories":"SOFAStack","content":" 2022 年 2 月 10 日，CNCF 发布了最新版本的 Landscape。\nLayotto 正式加入 CNCF 云原生全景图!\n分类在 Serverless framework 板块下，详情见 ：https://l.cncf.io/serverless\n意味着 Layotto 正式成为了CNCF 认可的构建云原生最佳实践中的一环。\nCNCF 简介 云原生计算基金会（CNCF, Cloud Native Computing Foundation）致力于云原生技术的普及和可持续发展。\nCNCF Landscape 意图从云原生的层次结构，以及不同的功能组成上，让用户了解云原生体系的全貌。同时，也受到广大开发者和使用者对该项目的关注和重视。\nLayotto 简介 Layotto(/leɪˈɒtəʊ/) 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。\n它为应用提供了各种分布式能力，比如状态管理、配置管理、事件发布订阅等能力，以简化应用的开发。\n更多关于 Layotto 的内容可以查看：\n云原生运行时的下一个五年\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\nLayotto Star 一下✨： https://github.com/mosn/layotto\n新的一年 Layotto 除了继续优化 service mesh 和 multi-runtime 方面的功能外，也会投入精力融入开源 serverless 生态。\n接下来会和大家分享下 2021 年 Layotto 的落地总结，以及新一年的 roadmap，欢迎关注!\n想要初步接触 Layotto 的技术同学，可以从我们的技术任务入手，欢迎大家一起来玩～\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n想要了解更多关于 Layotto 的最新动态\n👐 欢迎添加微信小助手进群，随时提问 👐\n本周推荐\n云原生运行时的下一个五年\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n","date":1644822000,"description":"应用运行时 Layotto 进入 CNCF 云原生全景图","dir":"blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6521f348ceee0dc3067e03c8209f4a01","permalink":"https://sofastack.github.io/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","publishdate":"2022-02-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","summary":"2022 年 2 月 10 日，CNCF 发布了最新版本的 Landscape。 Layotto 正式加入 CNCF 云原生全景图! 分类在 Serverless framework 板块下，详情见 ：https://l.cncf.","tags":["SOFAStack"],"title":"应用运行时 Layotto 进入 CNCF 云原生全景图","type":"blog","url":"/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","wordcount":742},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@小楼 提问：\n 请问 session 是如何支持 Dubbo 的元数据的？\n A：Registery 的元数据现在不是通用的，只针对 SOFARPC。\n session 之间应该是没有数据同步的吧，跨 session 节点怎么办呢？\n A：现在会同步两个信息，一个是元数据，一个是接口级订阅，接口级订阅是用于兼容没升级的应用。同步的路径是通过存储，类似 K8 的 listwatch 机制，内部落地存储的插件实现是 db，这个块数据比较少，就几千行吧，而且变化很小。\n「SOFARegistery」：https://github.com/sofastack/sofa-registry\n@来永国 提问：\n 为什么我起了 RPC 服务端客户端和注册中心，然后连接调用是可以的，然后我把注册中心关了，它还是跑得通？\n A：client 会有缓存的。\n 获取注册中心的服务有 API 接口吗?\n A：有的，有个从单机 session 获取数据的接口 curl localhost:9603/digest/pub/data/query?dataInfoId=com.test.SimpleService#@#DEFAULT_INSTANCE_ID#@#DEFAULT_GROUP dataInfoId 参数需要进行 url encode 应该还没公开的 API 文档，获取数据的 HTTP 接口也不太易用，我最近会补一下文档还有方便使用的接口。\n 那看样子这个相当于是指定搜索了吗？\n A：是的，目前没有模糊查询的接口， curl localhost:9603/digest/getDataInfoIdList 你可以用这个 API grep 一下。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@东仔 提问：\n SOFABolt 的最新分支是哪个？\n A：https://github.com/sofastack/sofa-bolt master 就是最新分支。\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n","date":1644562800,"description":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220211/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b55336c3e1f02336f659e4eedb771ea7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220211/","publishdate":"2022-02-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220211/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220211/","wordcount":1170},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@来永国 提问：\n 想问下，发现在 SOFA 的 spi 加载扩展的时候，是有做到 getExtensionLoader 遍历 META-INF 的，但是没搞懂是怎么做到的。br/ A：在这个方法里: com.alipay.sofa.rpc.ext.ExtensionLoader#loadFromFile，getResource 这边可以获得多个文件。\n@半个馒头 提问：\n 多次提交 raft 日志会自动触发 jraft 的 leader 转移吗？\n A：不会，可能是其他场景触发的。\n steps down when alive nodes don\u0026amp;rsquo;t satisfy quorum.\n A：是 leader 中发现半数节点在心跳周期内没有心跳了。\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 喜迎虎年｜开源正当时！\n2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n","date":1643958000,"description":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20220204/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b8eaeb7040dab97c5de595df79e1bc7c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220204/","publishdate":"2022-02-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220204/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220204/","wordcount":747},{"author":"金融级分布式架构","categories":"SOFAStack","content":" Awesome SOFAer 👋:\n大家好，\n我是 SOFAStack 社区的负责人——齐天\n虎年伊始，我谨代表 SOFAStack 社区\n祝大家新年快乐！\n在新的一年事事如意，虎虎有生气！\nPart 01 开源正当下！ 回想起 6 年前，在 Github 写下第一行 Apollo 的代码时。\n那时国内的开源社区是这样一番景象：\nDubbo 还没被唤醒、很多现在耳熟能详的项目还在襁褓中、开源社区的贡献者寥寥无几、少量的活跃项目凭着核心个人开发者对技术的热爱维持着。虽然使用开源产品的公司很多，但是做开源产品却是一种非常小众的行为。\n然而最近几年开源却一下子火了起来，成为了技术圈的时髦热词，在各种场合被频频提起。\n究其原因，我想一方面是开源商业化的模式诞生了以 Confluent、GitLab、HashiCorp 为代表的百亿美元上市公司群体，证明了开源的商业价值，吸引到了资本的关注；\n另一方面从政策层面，工业和信息化部印发了《“十四五”软件和信息技术服务业发展规划》，其中提到了要提升关键软件供给能力，加快繁荣开源生态，建设 2-3 个有国际影响力的开源社区。\n在这些因素的刺激影响下，国内的开源行业得到了迅猛的发展，诞生了开放原子基金会以及以木兰社区为代表的诸多综合性开源社区，众多基于开源项目的创业公司也纷纷获得融资，不完全统计列表如下：\n● 2021 年 3 月深圳支流科技 API7 完成 Pre-A 轮（基于 Apache APISIX 项目）\n● 2021 年 4 月上海硅智信息技术 Kyligence 完成 D 轮融资（基于 Apache Kylin 项目）\n● 2021 年 5 月北京思斐软件 SphereEx 完成天使轮融资（基于 Apache ShardingSphere 项目）\n● 2021 年 5 月涛思数据 TaosData 完成 B 轮融资（开源物联网大数据平台 TDengine）\n● 2021 年 10 月 StreamNative 获得 A 轮融资（基于 Apache Pulsar 项目）\n● 2021 年 11 月白鲸开源获得数百万美元种子轮融资（基于 Apache DolphinScheduler）\n● 2021 年 11 月开源数据库结构变更和版本管理 ByteBase 获得三百万美元种子轮融资\n● 2022 年 1 月 SphereEx 又完成了 Pre-A 轮融资\n可以说，「开源正当时！」\nPart 02 如何正确对待开源？ 然而，繁华之下也有隐忧。\n很多企业看到了开源的商业价值，所以纷纷投入大量资源，有了投入自然对回报就有着期待。在这种情形下一个不合理的 KPI 很容易就会让开源动作走样，诸如点 star 拿礼物、大量提交修改错别字的 commit 等行为也屡见不鲜。\n而另一方面有些底层开源项目如 Log4j2 虽然很重要，但是由于没有明显的商业价值，企业没有动力投入资源，以至于只有少数开发者无偿、自愿地进行维护，在曝出严重漏洞后大家才意识到原来开源软件供应链的根基竟是如此脆弱。\n那么，回到我们自身\u0026amp;hellip;\n应该如何正确对待开源呢？ 我的思绪再次拉回到 6 年前，当时的我对开源还懵懵懂懂，把代码贡献到 GitHub 的出发点非常纯粹：作为一名软件工程师，写了一份自己认为还过得去的代码，解决了一些通用问题，就希望让这份代码发挥更大的作用，同时也能通过代码会友，大家一起交流技术、分享心得，岂不乐哉？至于能获得多大的影响力、有多大的商业价值，当时是没有任何概念的。\n现在想来，似乎是有一分盲目和冲动在，一种想把好东西分享出去的冲动。\n当然了，要把开源项目做好，光有一时的冲动是不够的。做过开源项目的朋友基本都有一个共识，那就是做开源项目非常枯燥，日复一日地处理 issue、review pr，时不时还会遇到伸手党不合理的需求，稍有怠慢还会招来无端的指责。\n那到底是什么支撑我投入开源这么多年呢？ 想来想去应该还是兴趣吧\u0026amp;hellip;\n对技术的兴趣让这些重复性的事情显得不那么枯燥，而通过开源又结交了很多志趣相投的朋友，大家在一起既可以聊技术，也可以聊生活，虽然身处五湖四海，甚至素未谋面，但相谈甚欢，正是这样开放、有趣的社区让兴趣得以持续保鲜。\n而这也正是 SOFAStack 的开源理念，我们希望在喧嚣中依然保持乐于分享的初心，打造开放、有趣的技术社区。通过开放让更多的人加入进来，通过有趣让大家留下来并持续分享、交流，相互学习、相互成长。\n比如在开放方面，我们通过 Github、Meetup、直播、公众号、视频号等多种渠道和大家进行技术交流。\n 在社区治理上，我们也是完善了社区的晋升机制，鼓励贡献者以不同形式来影响社区走向，不少项目如 MOSN、Layotto 都有较大比例的外部 Committer。\n 在社区合作方面，我们和包括 Envoy、Dapr、Seata 等国内外社区进行了深度的技术共建，在传播方面也是和云原生社区、字节码联盟的 WAMR 社区等一起联合举办了多场 Meetup，为社区带来了精彩的技术分享。\n 而在有趣方面，虽然我们这些工程师平时看上去都挺严谨的，但其实私下里还都有好玩的一面。所以我们的视频号也是不断尝试新的视频形式，就是希望营造一个比较轻松、有趣的环境来和大家进行技术交流，在快乐中学习和成长。\n虎年准备做的几件事 SOFARegistry V6 虽然 SOFARegistry V5 版本早已在 GitHub 上开源，其性能、容量、稳定性上也都达到了比较高的水平，不过在日常运行中还是存在不少痛点。所以我们对 V6 版本做了大幅重构，在性能、稳定性、可运维性等方面都取得了较大的突破并在生产环境完成全量上线（降本提效！注册中心在蚂蚁集团的蜕变之路），相信不管是一家中小规模的公司还是一家大型企业，SOFARegistry 都会是一个比较靠谱的选项。\n而在研发这个版本的过程中我们也沉淀了针对注册中心场景的混沌测试工具，也将于近期和大家见面，希望能帮大家更好地评估各类开源注册中心的能力极限，以便选择最适合自己的产品。\nMOSN 目前 MOSN 作为 Service Mesh 的数据面在蚂蚁生产环境已经覆盖了数十万容器，切实解决了我们在基础设施独立演进上的痛点，在社区也有将近 20 家公司登记使用。不过总体来看，使用门槛还是比较高。\n所以今年我们会开源一个 MOSN 的管控面产品，从而端到端打通 MOSN 的使用场景，降低使用难度，造福更多的用户。\nLayotto Layotto 作为云原生运行时的下一个五年的重要载体，今年我们会继续投入精力和 Dapr 社区一起推动 API 标准化向前演进，重新定义基础设施的边界。同时也会探索 Layotto on Envoy 的运行方式，从而只需运维一个 Sidecar 即可同时具备 Service Mesh 和应用运行时的能力。\n在函数运行时方面，去年我们在 KubeCon 演示了通过 K8s 标准语义把一个 WASM 模块调度到 Layotto 进程中运行，今年在这个方向也会继续向前探索更多可能性。\n去年 4 月，SOFAStack 社区在北京和大家度过了一个愉快的三周岁生日，也标志着社区逐渐走向成 …","date":1643871600,"description":"喜迎虎年｜开源正当时！","dir":"blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d95d0ce2c5f132fcd207d1701c64c415","permalink":"https://sofastack.github.io/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","publishdate":"2022-02-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","summary":"Awesome SOFAer 👋: 大家好， 我是 SOFAStack 社区的负责人——齐天 虎年伊始，我谨代表 SOFAStack 社区 祝大家新年快乐！ 在新的一年事事如意，虎虎有生气！ Part 01 开源正当下！ 回想起 6 年","tags":["SOFAStack"],"title":"喜迎虎年｜开源正当时！","type":"blog","url":"/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","wordcount":2729},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@李雪涛 提问：\n 请问 MOSN 插件的管理接口应该怎么调用，里面的 IP 和 port，IP 应该指的是 Pod 的 IP 吧，那 port 指的是什么呢?br/ A：通过 admin 得配置。 https://www.github.com/mosn/mosn/tree/master/configs%2Fmosn_config.jso\n「MOSN」：https://github.com/mosn/mosn\n@李雪涛 提问：\n 我的插件参考的： https://github.com/mosn/mosn/blob/istio-1.10/examples/codes/plugin/pluginfilter/pluginfilter.go\n 但是我利用 admin 接口 enable 的时候输出的是插件未注册的错误，能帮我看一下我的插件注册部分哪里写的不对吗？\n插件的 client 的注册相关的代码： https://www.codepile.net/pile/EK6Om3A6\nA：镜像的配置有这个 plugin 吗？或者你先别用那个 Istio，现本地打包测试下，直接二进制启动试试： 1. 看配置，有没有 paper 的 filter 配置 2. MOSN 的 main 文件需要 import 你的 paper 文件，因为注册用的 init 3. 看下启动日志： https://github.com/mosn/mosn/blob/master/cmd/mosn/main/mosn.go\n「MOSN」：https://github.com/mosn/mosn\n@来永国 提问：\n 我把透传写在 SOFARPC 拦截器里，服务端接收不到客户端透传的参数。\n A：确实是这样，baggage 处理在 filter 之前。\n 还有什么更优雅的方式吗？那我非要只在 filter 里加透传要怎么做呢？\n A：非要在 filter 里面处理 baggage 的话,可以直接操作 SOFARequest 对象的 RequestProp. RemotingConstants.RPC_REQUEST_BAGGAGE，可以参考 com.alipay.sofa.rpc.context.BaggageResolver#carryWithRequest 类。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n","date":1643439600,"description":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220129/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"930109d877cef64f3e5441f23528dd16","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220129/","publishdate":"2022-01-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220129/","wordcount":1066},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王辉 提问：\n 那 6.x 版本相比 5.x 版本，缺失了哪些功能，有列表么？\n A：providedata 的功能还在，但通过 session 透出的 watcher 还没有支持，其他的功能没有缺失。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@李雪涛 提问：\n 请问自定义一个 streamfilter，可以在这个 filter 中获取当前请求的目的 IP 吗?\n A：可以的哈，通过变量就可以获取 。\n具体内容可以参考下方文档：\nhttps://www.github.com/mosn/mosn/tree/master/pkg%2Fproxy%2Fvar.go\n「MOSN」：https://github.com/mosn/mosn\n@王宇阳 提问：\n 请教一下 MOSN 做网关会对 HTTP 协议中没有带 content-type 的请求头做处理吗，比如加一个默认的这样？\n A：如果响应 header 没有携带 content-type 的话则默认加一个 “text/plain; charset=utf-8” 的 content-type。\n（注：MOSN 中的 HTTP 解析这块使用的 fasthttp 的库，目前这块会有这个默认操作。）\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 叮，你有一份开发者问卷到了\n一图看懂 SOFAStack 社区的 2021 ｜文末有“彩蛋”\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n","date":1642748400,"description":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220121/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e77bc7011b07dcfa07b22d729631a09d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220121/","publishdate":"2022-01-21T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220121/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220121/","wordcount":971},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#24：漫谈 HTTP/3 进化史\n 活动时间：01 月 20 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#24：漫谈 HTTP/3 进化史 HTTP/3 协议栈可以说是当前 4\u0026amp;frasl;7 层协议的集大成者，它浓缩了大量现有协议的最佳实践及优化技巧。\n那么 HTTP/3 是如何一步一步发展成今天这个样子的呢？它解决了什么样的问题？未来又还会走向何方？\n本次分享将用 50 分钟的时间，带你走近 HTTP/3 的世界，一一解读这些问题\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 曾柯（花名：毅丝） 蚂蚁集团高级工程师。 负责蚂蚁集团的接入层建设工作，主要方向为高性能安全网络协议的设计及优化 议程 18:50-19:00 主持人开场 SOFA 社区小助手-泡椒 主持人\n19:00-19:50 漫谈 HTTP/3 进化史 曾柯（花名：毅丝），蚂蚁集团高级工程师\n你将收获 了解4/7层协议的发展历程 了解HTTP/3解决的问题 一起展望HTTP/3的未来 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1642662000,"description":"01 月 20 日周四晚 19 点，线上直播第 24 期。","dir":"activities/sofa-channel-24/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2f719fc9371adf2f0f5a9de7f21c47cd","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-24/","publishdate":"2022-01-20T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-24/","summary":"概要 活动主题：SOFAChannel#24：漫谈 HTTP/3 进化史 活动时间：01 月 20 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播间地址：h","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#24：漫谈 HTTP/3 进化史","type":"activities","url":"/sofastack.tech/activities/sofa-channel-24/","wordcount":584},{"author":"杜克伟","categories":"SOFAStack","content":" 文｜杜克伟（花名：苏麟 )\n蚂蚁集团高级开发工程师\n负责蚂蚁 Kubernetes 集群的稳定性方面的工作，专注于集群组件变更、稳定性风险保障\n本文 15738 字 阅读 20 分钟\n前 言 为了支撑蚂蚁业务的迭代升级，蚂蚁基础设施今年启动了 Gzone 全面云化项目。要求 Gzone 需与已经云化的 Rzone 合并部署在同一个集群，Sigma 单集群实际管理的节点规模将超过万台，单集群承担的业务也将更加复杂。\n因此我们启动了大规模 Sigma 集群的性能优化方案，在请求延迟上期望能够对齐社区标准，不因规模增长的原因下降。\netcd 作为 Sigma 集群的数据存储数据库，是整个集群的基石，能够直接决定性能天花板。社区建议的单 etcd 集群存储限制是 8G, 而蚂蚁 Sigma 集群的单 etcd 集群存储量早已超过了这个限制，Gzone 上云项目势必会加重 etcd 的负担。\n首先，蚂蚁业务混合了流失计算、离线计算和在线业务，混合大量的生命周期在分钟级甚至是秒级的 Pod，单集群每天的 Pod 创建量也提升到了数十万, 都需要 etcd 来支撑；\n其次，复杂的业务需求催生了大量的 List (list all、list by namespace、list by label)、watch、create、update、delete 请求，针对 etcd 的存储特性，这些请求性能均会随着 etcd 存储规模的增大而严重衰减，甚至导致 etcd OOM，请求超时等异常；\n最后，请求量的增长也加剧了 etcd 由于 compact、defrag 操作对请求 RT P99 的暴涨，甚至请求超时，从而导致集群关键组件调度器、CNI 服务等 Operator 类组件间断性丢失，造成集群不可用。\n根据前人的经验，针对 etcd 集群进行数据水平拆分是一个有效的优化手段，典型的拆分是把 Pod 等重要数据单独 etcd 集群来存储，从而降低单 etcd 存储和请求处理的压力，降低请求处理延迟。但是 Pod 资源数据针对 Kubernetes 集群具有特殊性，具有其他资源没有的高要求，尤其是针对已颇具规模正在服务的 K8s 集群进行拆分更是需要万分谨慎小心。\n本文主要记录了蚂蚁集团在进行 Pod 资源数据拆分过程中一些实践经验和心得。\n抛砖引玉，请大家多多指教！\nPART. 1 面临的挑战 从前人的 Pod 数据拆分经验了解到，Pod 数据拆分是一个高危且复杂的流程，原因来自于 Pod 数据自身的特殊性。\nPod 是一组容器的组合，是 Sigma 集群中可调度的最小单位，是业务 workload 的最终承载体。Sigma 集群的最核心最终的交付资源就是 Pod 资源。\nSigma 集群最核心的 SLO 也是 Pod 的创建删除升级等指标。Pod 资源数据可以说是 Sigma 集群最重要的资源数据。同时 Sigma 集群又是由事件驱动的，面向终态体系设计，所以 Pod 资源数据拆分除了考虑基本的前后数据一致性问题外，还要考虑拆分过程中对其他组件的影响。\n前人的拆分经验流程中最核心的操作是数据完整性校验和关键服务组件停机。数据完整性校验顾名思义是为了保证数据前后的一致性，而关键服务组件停机是为了避免拆分过程中如果组件不停机造成的非预期后果，可能会有 Pod 非预期删除，Pod 状态被破坏等。但是如果照搬这套流程到蚂蚁 Sigma 集群，问题就来了。\n蚂蚁 Sigma 作为蚂蚁集团核心的基础设施，经过 2 年多的发展已经成为拥有 80+ 集群、单集群节点数可达到 1.2w+ 规模的云底座。在如此规模的集群上，运行着蚂蚁内部百万级别的 Pod，其中短运行时长 Pod 每天的创建量在 20w+次。为了满足各种业务发展需求，Sigma 团队与蚂蚁存储、网络、PaaS 等多个云原生团队合作，截止目前 Sigma 共建的第三方组件量已经达到上百个。如果 Pod 拆分要重启组件，需要大量的与业务方的沟通工作，需要多人共同操作。如果操作不慎，梳理不完全漏掉几个组件就有可能造成非预期的后果。\n从蚂蚁 Sigma 集群现状总结一下已有的 Pod 数据拆分经验流程的问题：\n1. 人工操作大量组件重启时间长、易出错 潜在需要重启的组件高达数十个，需要与各个组件 owner 进行沟通确认，梳理出需要重启的组件，需要耗费大量的沟通时间。万一遗漏就可能造成非预期的后果，比如资源残留、脏数据等。\n2. 完全停机持续时间长打破 SLO 数据拆分期间组件完全停机，集群功能完全不可用，且拆分操作极为耗时，根据前人经验，持续时间可能长达 1~2 小时，完全打破了 Sigma 集群对外的 SLO 承诺。\n3. 数据完整性校验手段薄弱 拆分过程中使用 etcd 开源工具 make-mirror 工具来迁移数据，该工具实现比较简单，就是读取一个 etcd 的 key 数据然后重新写到另一个 etcd，不支持断点续传，同时因重新写入 etcd 造成原有 key 的重要字段 revision 被破坏，影响 Pod 数据的 resourceVersion, 可能会造成非预期后果。关于 revision 后文会详细说明。最后的校验手段是检验 keys 的数量是否前后一致，如果中间 key 的数据被破坏，也无法发现。\nPART. 2 问题解析 美好的期望 作为一个懒人，不想和那么多的组件 owner 沟通重启问题，大量组件重启也易造成操作遗漏，造成非预期问题。同时是否有更好的数据完整性校验的手段呢？\n如果组件不重启，那么整个过程后演变为下面的流程，预期将简化流程，同时保障安全性。\n为了达成美好的期望，我们来追本溯源重新 review 整个流程。\n数据拆分是在做什么？ 众所周知，etcd 存储了 Kubernetes 集群中的各种资源数据，如 Pod、Services、Configmaps、Deployment 等等。\nKube-apiserver 默认是所有的资源数据都存储在一套 etcd 集群中，随着存储规模的增长，etcd 集群会面临性能瓶颈。以资源维度进行 etcd 的数据拆分来提升 Kube-apiserver 访问 etcd 的性能是业内所共识的经验优化思路，本质是降低单 etcd 集群的数据规模，减少单 etcd 集群的访问 QPS。\n针对蚂蚁 Sigma 集群自身的规模和需求，需拆分为 4 个独立的 etcd 集群，分别存储 Pods、Leases、event 和其他资源数据，下面分别简要说明这前三类(Pods、Lease、event)需要拆分出去的资源数据。\nEvent 资源 K8s event 资源数据并不是 watch 中的 event，一般是表示关联对象发生的事件，比如 Pod 拉取镜像，容器启动等。在业务上一般是 CI/CD 需要流水式展示状态时间轴，需要频繁拉取 event 资源数据。\nevent 资源数据本身就是有效期的（默认是 2 小时），除了通过 event 观测资源对象生命周期变化外，一般没有重要的业务依赖，所以说 event 数据一般认为是可以丢弃，不需要保障数据前后一致性的。\n因为上述的数据特点，event 的拆分是最为简 …","date":1642489200,"description":"蚂蚁大规模 Sigma 集群 Etcd 拆分实践","dir":"blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d2c7a90fb1f46225bb634988b092d058","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","publishdate":"2022-01-18T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","summary":"文｜杜克伟（花名：苏麟 ) 蚂蚁集团高级开发工程师 负责蚂蚁 Kubernetes 集群的稳定性方面的工作，专注于集群组件变更、稳定性风险保障 本文 15738 字 阅读 20 分钟 前 言 为了","tags":["SOFAStack"],"title":"蚂蚁大规模 Sigma 集群 Etcd 拆分实践","type":"blog","url":"/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","wordcount":8750},{"author":"杨洋","categories":"SOFAStack","content":" 文｜杨洋（花名：凯申 )\n蚂蚁集团高级技术专家\n负责密码学工程能力建设、BabaSSL 开源社区建设\n本文 2366 字 阅读 5 分钟\n近日，国内著名 Web 服务器和反向代理开源软件 TengineBabaSSL 完成了对 BabaSSL的适配工作。\nTengine 对 BabaSSL 提供的特殊 API 进行了适配，并增加对 NTLS 相关能力的支持。\n「详细 Pull Request 请见」：https://github.com/alibaba/tengine/pull/1595\n至此，对我国密码行业相关安全通信协议，有使用需求的用户可以直接使用 Tengine + BabaSSL 的组合。而无需额外的 patch 或者代码改动，从用户使用的角度进一步提升了便利性。\nPART. 1 NTLS 目前，我国密码行业中有两个主要的通信协议相关的技术标准。一个是由信安标委于 2020 年发布的 TLCP 协议，即传输层密码协议；另外一个则是由密标委在 2012 年发布的 GM/T 0024《SSL VPN 技术规范》（以下简称 0024）。\nTLCP 和 0024 的具体内容差别不大，均是从 TLS 协议发展而来，他们的主要特点是将商用密码算法 SM2、SM3 和 SM4 应用到了 TLS 协议中，并使用 SM2 密钥交换机制替换掉了 TLS 协议原有的密钥交换流程。\nTLCP 和 0024 另外一个显著的特点将 TLS 协议中使用的数字证书拆分成了加密和签名两种用途的证书，加密证书和签名证书以及对应私钥均需要进行配置使用，所以 TLCP 和 0024 也俗称“国密双证书”协议。\nBabaSSL 对上述国密双证书协议进行了支持，并统称为 NTLS。\nNTLS 的全名为 National TLS，即我国核准的传输层安全协议，所以也可以叫做国密 TLS。\n由此可见，NTLS 并不是指某一种具体的符合商用密码相关技术标准要求的网络协议，而是多个协议的统称。在 BabaSSL 中代指 TLCP 和 0024 国密双证书协议，因为 NTLS 和标准 TLS 协议存在工作方式的不同，因此 BabaSSL 中增加了一些新的 API 来对其进行支持。而应用程序若想使用 NTLS 功能，就需要调用这些新增 API，给现有基于 OpenSSL API 进行适配的应用程序带来了额外的开发工作量。\nPART. 2 Tengine + BabaSSL Tengine 是由淘宝网发起的 Web 服务器项目，它在 Nginx 的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。\nTengine 的性能和稳定性已经在大型的网站(如淘宝网，天猫商城等)得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的 Web 平台。\nTengine 作为国内知名的开源 Web 服务器软件，在各领域均得到了广泛的使用且享有很高的知名度。\nBabaSSL 是一款轻巧、灵活且靠谱的密码学和 TLS 协议工具集。BabaSSL 是蚂蚁集团和阿里集团的各主要业务中所使用的底层密码库，目前开源出来供业界使用。BabaSSL 广泛的应用在包括网络、存储、移动端 App 等场景中。\nTengine 来源于 Nginx，所以默认使用的是 OpenSSL。此次 Tengine 针对 BabaSSL 中的 NTLS 功能进行了适配，用户如果选择使用 BabaSSL 作为 Tengine 的底层密码库来实现通信加密的能力，则可以无需对 Tengine 进行任何代码改动，原生开启 NTLS 能力。\nPART. 3 Tengine 启用 NTLS 具体来说，此次在 Tengine 中增加了几个新的指令，对 NTLS 进行支持。\n1. 下载 BabaSSL 和 Tengine 前往 👇 下载 BabaSSL 的源代码包: https://github.com/BabaSSL/BabaSSL/releases\n 前往 👇 获取 Tengine 的最新代码: 「git clone」\nhttps://github.com/alibaba/tengine.git\n2. 编译 BabaSSL 和 Tengine 使用如下配置：\n./configure --add-module=modules/ngx_openssl_ntls \\ --with-openssl=../path/to/BabaSSL \\ --with-openssl-opt=\u0026amp;quot;--strict-warnings enable-ntls\u0026amp;quot; \\ --with-http_ssl_module --with-stream \\ --with-stream_ssl_module --with-stream_sni 3. 配置 Tengine 开启 NTLS 一个开启了 NTLS 的 Tengine 配置文件的例子：\nworker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; server { listen 443 ssl; server_name localhost; enable_ntls on; ssl_sign_certificate server_sign.crt; ssl_sign_certificate_key server_sign.key; ssl_enc_certificate server_enc.crt; ssl_enc_certificate_key server_enc.key; location / { return 200 \u0026amp;quot;body $ssl_protocol:$ssl_cipher\u0026amp;quot;; } } } stream { server { listen 8443 ssl; enable_ntls on; ssl_sign_certificate server_sign.crt; ssl_sign_certificate_key server_sign.key; ssl_enc_certificate server_enc.crt; ssl_enc_certificate_key server_enc.key; return \u0026amp;quot;body $ssl_protocol:$ssl_cipher\u0026amp;quot;; } } 4. 测试 NTLS 可以使用 BabaSSL 的 s_client 工具对开启了 NTLS 的 Tengine 进行测试。\n「具体可以参考」：\nhttps://babassl.readthedocs.io/zh/latest/Tutorial/SM/ntls/\nPART. 4 总 结 随着互联网业务的发展，在新时期下，数据成为了影响人们正常生活的核心要素。\n因此数据安全和个人信息保护等问题变得更加需要重视，国家近期也针对数据安全领域进行了相关立法。\n密码学技术作为整个信息安全领域的基础技术能力，对数据安全也存在着很大的影响。同时 …","date":1641884400,"description":"Tengine + BabaSSL ，让国密更易用！","dir":"blog/tengine-babassl-making-state-secrets-easier-to-use/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"45a5b2c753bc2a5c371c606d1177571e","permalink":"https://sofastack.github.io/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","publishdate":"2022-01-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","summary":"文｜杨洋（花名：凯申 ) 蚂蚁集团高级技术专家 负责密码学工程能力建设、BabaSSL 开源社区建设 本文 2366 字 阅读 5 分钟 近日，国内著名 Web 服务器和反向代","tags":["SOFAStack"],"title":"Tengine + BabaSSL ，让国密更易用！","type":"blog","url":"/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","wordcount":1930},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王勇旭 提问：\n com.alipay.sofa.rpc.boot.runtime.adapter.processor.ConsumerConfigProcessor 没有提供注解上的支持，自己实现来处理吗？Cluster 指定 failover、failfast 或者自己实现，这种在 SOFA 中是怎么使用的呢？ A：这种的话，单个注解的 API 是不支持的。不过可以通过调整整体的 RPC 的配置，来实现切换到你想使用的 Cluster 上。具体如何配置可以看代码这里，支持自定义的配置文件，也支持 -D 环境变量的方式传入，key 为 consumer.Cluster。\n 为啥不支持单个 API 的配置啊，是出于某种考虑吗?\n A：单个 API 的话，可以单独通过 ConsumerConfig 的 setCluster(String Cluster)去设置。但是不是通用功能，所以没加到 annotation 上。\n 感觉和 loadbalance 是差不多同一级的，注解上 lD 支持，Cluster 不支持\u0026amp;hellip;\n A：这个功能感觉更偏全局一些，当然也是有单个 API 自定义的需求，之前的设计可能也是基于这个考量。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@崔伟协 提问：\n 所有整个流程里的异常返回（那些没转发到 Upstream/或者转发失败的，直接返回给 client)都会经过这里吗？ https://github.com/mosn/mosn/blob/master/pkg/proxy/downstream.go#L1359\n A：也不一定，你的诉求是啥呢？但是所有请求基本都会走 filter，你可以在 append filter 劫持返回的请求。\n 就是捕获一波没转发的或者转发失败的，不包括已经转发的然后返回失败的。\n A：这个可能还不太好区分，超时也算是转发的了，但超时之后也会调用 hijack。返回的包是不是 Upstream 发过来是可以判断的， 你写一个 append filter，然后判断 types.VarProxyIsDirectResponse 这个变量。\n「MOSN」：https://github.com/mosn/mosn\n@我是一个小胖子 提问：\n 这个统一路由框架，已经 ready，还是在计划中？\n A：https://mosn.io/blog/posts/how-use-dynamic-metadata/\n可以参考这篇文章，是更加灵活的方案。还有一部分没在文档里，就是路由的 match 规则也支持变量和 DSL。\n「MOSN」：https://github.com/mosn/mosn\n@Noob Xu 提问：\n 请问一下，MOSN 的国密 TLS 支持，是不是先用 \u0026amp;ndash;prefix=/usr/local/BabaSSL/linux_BabaSSL_lib 构建 BabaSSL，然后用 CGO_ENABLED=1 go build -tags BabaSSL 构建 MOSN，是不是就支持 TLS 1.3 + 国密单证书了 ？\n A：在/usr/local/BabaSSL/linux_BabaSSL_lib 这个路径下放上 BabaSSL 的 lib，比如/usr/local/BabaSSL/linux_BabaSSL_lib，然后 CGO_ENABLED=1 go build -tags=BabaSSL 之后配置里 TLS 的 CipherSuite 按照 MOSN 支持的几种格式配置，比如 ECDHE-RSA-SM4-SM3 就可以了。在 MOSN 和 MOSN 之间的 TLS 通信就可以走 1.3 和国密了。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 叮，你有一份开发者问卷到了\n一图看懂 SOFAStack 社区的 2021 ｜文末有“彩蛋”\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n","date":1641538800,"description":"SOFA Weekly |SOFA 社区插话小剧场、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220107/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e8f7168b6d3204a6c3f130a563ead237","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220107/","publishdate":"2022-01-07T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220107/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |SOFA 社区插话小剧场、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220107/","wordcount":1625},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@东仔 提问：\n SOFARegistry 的 client、meta、data、session 的四个模块间怎么交互的？\n A：client API 参考 :\nhttps://www.sofastack.tech/projects/sofa-registry/java-sdk/\nmeta、data、session 没有提供 API 文档, 相关介绍可以看下:\nhttps://github.com/sofastack/sofa-registry/releases/tag/v6.1.4\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@刚刚 提问：\n 获取有效链接，这个方法不是每次 new 一个 TCP 链接？\n A：会复用的，为 0 的时候才新建，不为 0 的时候我看是去到一个，直接把那个位置重置为 nil 了。\n 复用是体现在？还是我 down 大代码不是最新的。\n A：用完了会放回这个 avliableclients 的数组里，你的代码不是最新，但大致逻辑也就这样。\n「MOSN」：https://github.com/mosn/mosn\n3、之前有同学问到 OpenKruise 怎么热升级 MOSN，欢迎大家阅读这篇文档试用反馈！\nhttps://mosn.io/blog/posts/mosn-sidecarset-hotupgrade/\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nMOSN 本周发布 发布 MOSN V0.26.0 版本，主要变更如下：\n主要更新如下：\n XProtocol 进行了重构，XProtocol 不再是一种协议，而是便于协议扩展实现的框架\n 新增 ip_access filter，基于来源 IP 的 ACL 控制器\n 支持 go plugin 加载协议转化插件，并支持动态选择协议转换插件\n 支持动态设置上游协议，使用 transcoder filter 来替换 Proxy 中的协议转换\n 其他优化与BUG Fix\n 「详细参考」：\nhttps://mosn.io/blog/releases/v0.26.0/\n本周推荐阅读 一行降低 100000kg 碳排放量的代码！\nSOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1640934000,"description":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","dir":"blog/sofa-weekly-20211231/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1e143008505428e2046bc3c99bd99e51","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211231/","publishdate":"2021-12-31T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211231/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211231/","wordcount":1172},{"author":"张稀虹","categories":"SOFAStack","content":" 文｜张稀虹（花名：止语 )\n蚂蚁集团技术专家\n负责蚂蚁集团云原生架构下的高可用能力的建设 主要技术领域包括 ServiceMesh、Serverless 等\n本文 3631 字 阅读 8 分钟\nPART. 1 故事背景 今年双十一大促后，按照惯例我们对大促期间的系统运行数据进行了详细的分析，对比去年同期的性能数据发现，MOSN 的 CPU 使用率有大约 1% 的上涨。\n为什么增加了？\n是合理的吗？\n可以优化吗？\n是不可避免的熵增，还是人为的浪费？\n带着这一些列灵魂拷问我们对系统进行了分析\nPART. 2 问题定位 我们从监控上发现，这部分额外的开销是在系统空闲时已有，并且不会随着压测流量增加而降低，CPU 总消耗增加 1.2%，其中 0.8% 是由 cpu_sys 带来。\n通过 perf 分析发现新版本的 MOSN 相较于老版本， syscall 有明显的增加。\n经过层层分析，发现其中一部分原因是 MOSN 依赖的 sentinel-golang 中的一个StartTimeTicker 的 func 中的 Sleep 产生了大量的系统调用，这是个什么逻辑？\nPART. 3 理论分析 查看源码发现有一个毫秒级别的时间戳缓存逻辑，设计的目的是为了降低高调用频率下的性能开销，但空闲状态下频繁的获取时间戳和 Sleep 会产生大量的系统调用，导致 cpu sys util 上涨。我们先从理论上分析一下为什么这部分优化在工程上通常是无效的，先来看看 Sentinel 的代码：\npackage util import ( \u0026amp;quot;sync/atomic\u0026amp;quot; \u0026amp;quot;time\u0026amp;quot; ) var nowInMs = uint64(0) // StartTimeTicker starts a background task that caches current timestamp per millisecond, // which may provide better performance in high-concurrency scenarios. func StartTimeTicker() { atomic.StoreUint64(\u0026amp;amp;nowInMs, uint64(time.Now().UnixNano())/UnixTimeUnitOffset) go func() { for { now := uint64(time.Now().UnixNano()) / UnixTimeUnitOffset atomic.StoreUint64(\u0026amp;amp;nowInMs, now) time.Sleep(time.Millisecond) } }() } func CurrentTimeMillsWithTicker() uint64 { return atomic.LoadUint64(\u0026amp;amp;nowInMs) } 从上面的代码可以看到，Sentinel 内部用了一个 goroutine 循环的获取时间戳存到 atomic 变量里，然后调用 Sleep 休眠 1ms，通过这种方式缓存了毫秒级别的时间戳。外部有一个开关控制这段逻辑是否要启用，默认情况下是启用的。从这段代码上看，性能开销最大的应该是 Sleep，因为 Sleep 会产生 syscall，众所周知 syscall 的代价是比较高的。\ntime.Sleep 和 time.Now 对比开销到底大多少呢？ 查证资料（1）后我发现一个反直觉的事实，由于 Golang 特殊的调度机制，在 Golang 中一次 time.Sleep 可能会产生 7 次 syscall，而 time.Now 则是 vDSO 实现的，那么问题来了 vDSO 和 7 次系统调用相比提升应该是多少呢？\n我找到了可以佐证的资料，恰好有一个 Golang 的优化（2），其中提到在老版本的 Golang 中（golang 1.9-)，Linux/386 下没有这个 vDSO 的优化，此时会有 2 次 syscall，新版本经过优化后理论性能提高 5～7x+，可以约等于一次 time.Now \u0026amp;lt;= 0.3 次 syscall 的开销。\nCache 设计的目的是为了减少 time.Now 的调用，所以理论上这里调用量足够大的情况下可能会有收益，按照上面的分析，假设 time.Now 和 Sleep 系统调用的开销比是 0.3:7.3（7+0.3），Sleep 每秒会执行 1000 次（不考虑系统精度损失的情况下），这意味着一秒内 CurrentTimeMillsWithTicker 的调用总次数要超过 2.4W 才会有收益。\n所以我们再分析一下 CurrentTimeMillsWithTicker 的调用次数，我在这个地方加了一个 counter 进行验证，然后模拟请求调用 Sentinel 的 Entry，经过测试发现：\n 当首次创建资源点时，Entry 和 CurrentTimeMillsWithTicker 的放大比为 20，这主要是因为创建底层滑动窗口时需要大量的时间戳计算\n 当相同的 resource 调用 Entry 时，调用的放大比⁰为 5:1\n ｜注 0: 内部使用的 MOSN 版本基于原版 Sentinel 做了一些定制化，社区版本放大比理论上低于该比值。\n考虑到创建资源点是低频的，我们可以近似认为此处调用放大比为 5。所以理论上当单机 QPS 至少超过 4800 以上才可能会取得收益\u0026amp;hellip;\u0026amp;hellip;我们动辄听说什么 C10K、C100K、C1000K 问题，这个值看上去似乎并不很高？但在实际业务系统中，这实际上是一个很高的量。\n我随机抽取了多个日常请求量相对大的应用查看 QPS（这里的 QPS 包含所有类型的资源点，入口/出口调用以及子资源点等，总之就是所有会经过 Sentinel Entry 调用的请求量），日常峰值也未超过 4800QPS，可见实际的业务系统中，单机请求量超过这个值的场景是非常罕见的。¹\n｜注 1: 此处监控为分钟级的数据监控，可能与秒级监控存在一定的出入，仅用于指导日常请求量评估。\n考虑到这个优化还有一个好处，是可以降低同步请求时间戳时的耗时，所以我们可以再对比一下直接从 atomic 变量读取缓存值和通过 time.Now() 读取时间戳的速度。\n可以看到单次直接获取时间戳确实比从内存读取开销大很多，但是仍然是 ns 级别的，这种级别的耗时增长对于一笔请求而言是可以忽略不计的。\n大概是 0.06 微秒，即使乘以 5，也就是 0.3 微秒的增加。在 4000QPS 这个流量档位下我们也可以看一下 MOSN 实际 RT。\n两台机器的 MOSN RT 也没有明显的差异，毕竟只有 0.3 微秒\u0026amp;hellip;\nPART. 4 测试结论 同时我们也找了两台机器，分别禁用/启用这个 Cache 进行测试，测试结果佐证了上述分析的结论。\n从上图的数据可以看出来，启用 Cache 的情况下 cpu sys util 始终比不启用 Cache 的版本要大，随着请求量增加，性能差距在逐步缩小， …","date":1640674800,"description":"一行降低 100000kg 碳排放量的代码！","dir":"blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"93ce5b0bb923a249ebd161465f032ce8","permalink":"https://sofastack.github.io/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","publishdate":"2021-12-28T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","summary":"文｜张稀虹（花名：止语 ) 蚂蚁集团技术专家 负责蚂蚁集团云原生架构下的高可用能力的建设 主要技术领域包括 ServiceMesh、Serverles","tags":["SOFAStack"],"title":"一行降低 100000kg 碳排放量的代码！","type":"blog","url":"/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","wordcount":3103},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@微光 提问：\n 有一个嵌入式分布式 KV 存储需求，JRaft RheaKV 能用在生产吗？\n A：我们的时序数据库集群基于 RheaKV 做元数据存储和集群调度。\n有关内容可以参考这个文件：《\u0026amp;rdquo;使用组件及场景：时序数据库集群基于 RheaKV 做元数据存储和集群调度\u0026amp;rdquo;》\nhttps://github.com/sofastack/sofa-jraft/issues/524\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@微光 提问：\n RheaKV 中这样移除一个节点 Node，好像不行。在 DefaultRheaKVCliService 中是否可以提供动态上线 Node 和下线 Node 的 API？\n A：你提的都支持。所谓动态，不是说 JRaft 决定的，是你的运维系统可以使用 JRaft API 动态执行。\nissue 详细回复：https://github.com/sofastack/sofa-jraft/issues/747\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@苏泽东 提问：\n 哪位老师帮我解答下这个 Endstream 方法?\n A：这个主要是请求发出去后，一直等到收到响应后，记录下 RT 时间等监控数据。\n「MOSN」：https://github.com/mosn/mosn\n@火种 提问：\n 咨询一个问题：看 MOSN 的源码，如果非 netpoll，是通过在 startRWLoop 来实现的，如果是使用 netpoll 的情况下，长链接是怎么迁移的？\n A：https://mp.weixin.qq.com/s/ts_qsUee6mUFv0FpykaOXQ 推荐你看下这个文件。\n startRWloop 会调用 startreadloop 和 startwriteloop，在这两个函数中进行了长链接的数据的交换，但是使用 netpoll 后，代码分支就变成 netpoll 相应的分支了，不会进入上述两个函数了。\n A：没有支持 netpoll 模式的迁移。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n网商双十一基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\n","date":1640329200,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211224/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9977b0cb01909a1c2ef21e4a2026b36b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211224/","publishdate":"2021-12-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211224/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211224/","wordcount":1292},{"author":"马振雄","categories":"SOFAStack","content":" 近几年云计算的发展如火箭般迅猛，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施的统一资源调度带来了极大挑战。\n在越来越复杂的异构基础设施上，存量应用和增量应用应该如何上云？面对大量异构基础设施带来的挑战，企业如何最大化上云价值？\n12 月 15 日，在以“引领分布式云变革，助力湾区数字经济”为主题的全球分布式云大会上，蚂蚁集团数字科技事业部产品总监马振雄分享了分布式云异构基础设施之上，蚂蚁集团在构建分布式云 PaaS 平台 SOFAStack 背后的实践和思考。\nPART. 1 服务网格定义新的应用上云路径 随着云原生的发展，企业在技术升级的过程中伴随着大量的历史包袱，这些历史包袱是所有存量的异构功能，这些异构功能有以下几个特征：技术架构异构、通信协议异构、开发框架异构。\n这些存量的应用如何在异构的基础设施上统一纳管，背后就涉及到了应用的全生命周期，从研发时的应用改造成本，到运行时如何对异构应用做统一服务治理，再到运维时如何对基础设施进行统一元数据管理、统一变更、统一容灾、统一应急以及资金安全，这些都是存在于 PaaS 层的挑战。\n如果说 IaaS 层的统一资源调度以资源为视角和出发点，那么在上层 PaaS 则需要以应用为视角思考整个分布式基础设施的复杂度到底会带来哪些挑战，以及企业应该如何应对。\n企业存在大量的历史包袱，历史包袱五花八门，如果要把这些历史包袱全部改造成分布式应用或者云原生应用，背后需要的代价非常昂贵，很难有一家企业在短时间内愿意负担起这样的时间和成本，彻底将所有的历史包袱云原生化。\n相比于其他上云方式，Service Mesh 能够实现跨平台、跨协议，并且业务代码无侵入改造，从而快速地将应用植入 Sidecar 完成 Mesh 化，获得分布式红利、安全可观测，并且整个架构平滑演进。企业在架构升级过程中可以按部就班、循序渐进，并且实现端到端的安全可信以及全链路可观测能力。\n总体来说网格服务首先降低了传统应用改造成分布式、云原生应用的成本问题；其次是解决了所有企业新老系统的互联互通和统一纳管的问题；第三是让企业应用架构在升级过程变得更平滑；第四是让所有企业保留自己存量系统的技术栈，且保留了企业自身自主可控性要求。\nForrester 长期以来对蚂蚁集团的创新技术保持关注，Forrester 首席分析师、Serving Technology Executives 服务技术决策者戴鲲发布《蚂蚁集团服务网格总体经济影响》，并分享了他对于 Mesh 的研究，\n未来要实现开发的智能化，需要通过微服务来进行智能化进程，不再像以前一样零敲碎打。对传统应用进行定制化，要通过网格服务动态地组装，实现云上开发。\n通过对蚂蚁集团客户的访谈，Forrester 发现无论是传统金融机构还是互联网金融机构，都面临在混合架构下存在的共性挑战，包括基础设施升级换代、应用开发升级、云上云下交互等方方面面。Forrester 发现网格服务从单体应用改造成本节省到运维安全管理效率提升等方面都有明显的收益，通过研究三年数据测算，使用蚂蚁服务网格产品后，客户的投资回报率达到 99%。\nPART. 2 SOFAStack 实现异构统一运维与弹性容灾 基于自身的技术积累和场景打磨，蚂蚁数字科技定义了分布式云 PaaS 平台在运维态的六大能力，包括统一元数据管理、统一集群资源管理、统一变更能力、统一应急能力、统一容灾能力，和统一端到端从业务、应用到基础设施的可观测能力。在此基础上，蚂蚁数字科技重新定义 SRE，实现统一应用运维能力。\n行业一般认为 SRE 中的“R”（Reliability）是可靠性，蚂蚁数字科技结合自身十几年来对业务可用性和连续性的极致追求，经历了十多次双十一大规模验证，对 SRE 进行重新定义，将 SRE 里的 R 从 Reliability 转变为 Risk，意味着蚂蚁自身的保障体系是以风险为核心。最终通过十几年来的技术沉淀，打造了自己的技术风险保障平台 TRaaS。也正是因为这十几年沉淀的精华，才能让蚂蚁做到业务、应用、基础设施的运维无人值守，运维“自动驾驶”。\n蚂蚁的技术风险防控体系从上到下分别代表了三个目标：高可用、资金安全、低成本。三个组织保障：团队、文化、制度。再到需求、研发、发布以及监控的四条防线，最终沉淀出一套完整的技术风险保障体系的平台能力，整个平台由四个能力板块组成，包括了从应急、变更到容量、资金安全。\n应急平台建立起了以风险为核心的事前、事中、事后的故障风险保障体系，分别对应故障风险检测能力、故障定位能力、故障应急和自愈能力，以及故障的回溯能力。变更平台建立起了以变更为核心的事前、事中、事后的变更风险自动分析、防御、阻断能力。容量平台建立起了对于全局数据中心和系统整体瓶颈的自动探测、容量规划和容量保鲜能力。最后的资金平台，通过对业务应用无侵入地建立起了资金核对第二道防线，帮助企业彻底规避资金安全风险，减少资损。\n如果说第一个核心的挑战解决的是研发态和运行态的问题，第二个核心挑战解决运维态问题，第三个核心挑战，要解决的是从整体架构上解决容灾态的问题。\n随着分布式云基础设施的蓬勃发展，企业数据中心从集中化走向离散化，这意味着企业任何一个应用随时随地可以跑在全国的任何一家数据中心机房的任何一个节点。这种变化背后，从应用视角来看，迫切需要整体的系统应用架构，支撑业务突破地域和城市级别的无限可扩展能力。基于蚂蚁对于业务连续性的极致追求，蚂蚁在支撑业务发展过程中，建立起了金融行业超大规模的三地五中心，并沉淀了一套异地多活单元化架构，解决企业在容灾、弹性、灰度方面的三大痛点。\n容灾方面，可以支撑企业的数据中心架构彻底从单活走向同城双活、两地三中心、再走向多地多活。一个业务单元发生故障不会影响到另外一个业务单元，从架构本身原生保障了业务的可靠性和连续性。\n弹性方面，由于灵活部署和快速扩容机制，能够结合灵活的流量调拨机制，支撑企业的数据中心突破城市和地域级别的扩展，做到真正意义上的无限可扩展。\n灰度，结合跨单元的路由分发，可以轻易地做到蓝绿单元这样具有创新的业务灰度方式。\n多地多活的架构非常复杂，从上至下包含了四层，从接入层做路由规则和路由分发，到应用层的中间件路由，再到数据层的数据分片和数据路由，最后到运维层的统一容灾、统一监控、单元拓扑。\n以金融行业为例，大型银行在主机下移过程中，需要面临的重要课题就是如何将核心系统下沉到分布式集群，在分布式集群下移过程中如何匹配主机系统性能和稳定性，背后很重要的能力就是多地多活架构。\n最终，蚂蚁在以上三个核心挑战的实践过程中，沉淀出新一代分布式云 PaaS 平台 SOFAStack。平台在金融行业有非常多的头部客户案例，从原生能力就满足了金融行业远高于其他行业在容量、性能、规模、高可用、合规、降本提效等方面的高标准要求。更重要的是 SOFAStack 来源于金融行业，但不止于金融行业，蚂蚁希望通过 SOFAStack 赋能到更多的行业，完成更多企业的数字化转型。\nPART. 3 SOFAStack 未来演进方向 Mesh 的未来会经历三个重要的发展阶段：\n第一个阶段，不止是 Service …","date":1640242800,"description":"SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验","dir":"blog/the-practice-and-thinking-behind-sofastack/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cb8e3ab2323cb918eeb7a4cb68408c61","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","publishdate":"2021-12-23T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","summary":"近几年云计算的发展如火箭般迅猛，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施","tags":["SOFAStack"],"title":"SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验","type":"blog","url":"/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","wordcount":3335},{"author":"吕冰洁","categories":"SOFAStack","content":" 吕冰洁（花名：尚之）蚂蚁集团技术专家\n我们团队是在做蚂蚁集团内部 Serverless 项目，深度依赖 SOFAArk。SOFAArk 作为 Serverless 项目的核心热部署组件，在无感接入、快速启动方面有很大的诉求。\n因此为 SOFAArk 2.0 提供了最核心的内嵌式运行模式，同时对 1.0 版本存在的一些问题做了较多的性能优化。\n2022 年 03 月 07 日，吕冰洁@zjulbj 被投票选为，SOFAArk Committer。\nBefore 我主要是负责让传统的 SOFABoot 的应用平滑迁移到 SOFAArk 上。\n开始走了很多弯路，接入成本上可能需要半个月到一个月。最初选择了新建应用切流这种比较间接的方案，基于这个方案做迁移过程中的平滑迁移、切流工具。\n但是没解决根本问题，只是通过工具减少了部分工作量。\n过程 我们就尝试通过修改架构把这些问题解掉，推动自己深入了解底层，思考它为什么是这么设计的，为什么导致现在的问题？\n通过研究之后，发现最开始 SOFAArk 是面向终态去设计的，是比较理想化的容器。但实际落地过程中，业务是逐步演进而来的。刚接入就要感知特别大的变化，涉及部署脚本、镜像、测试脚本等一系列的改造，导致业务无法快速享受 SOFAArk 带来的红利。\n我们就借鉴之前的经验，比如 Tomcat 最开始是一个容器，后面往内嵌化发展。我们内部的 CloudEngine 最开始也是一个容器，后面往 SOFABoot 演进也是一个往内嵌化的发展。\nAfter 所以从我们整个迁移和落地的角度，设计了这套方案，修改其中的相关代码。\n从原来需要 2~3 周到现在的一天，降低迁移的成本，省去了大量迁移工作。也为我们后面全站规模化、商业化的一键开启 ark 奠定了基础。\n作为业务研发深入中间件开发底层 Q:如何看待自己作为业务研发的身份接触到开源？\nA:作为业务研发，深入到开源组件的底层设计，不仅对我们自己使用组件有很大的帮助，也能让我们和开源社区的组件同步节奏，不至于脱节。\n另外我们解决了实际问题，其他的使用方肯定也会遇到同样的问题。那我们是不是可以把已有的经验，回馈到开源社区帮助到更多的人。我觉得这是一个良性循环的开源环境，而不是向开发者提一些需求 pr 就结束了。\nQ:你觉得解决这个问题的难点在哪里？\nA:主要的难点还是我以业务研发的身份，参与到整个 SOFAArk 中间件的开发中。\n首先我需要对它的整个设计有清晰的把握，尽管之前有半年的使用经验，也依然花费了一周的时间才搞懂了核心架构。还好 ark 的文档写得很详细，大大降低了我的理解成本。\nQ:在沟通的过程中有没有什么困难的？\nA:沟通没有困难，毕竟大家都是技术，其实都是相通的。只要把自己的使用场景说清楚，中间过程遇到的一些具体问题说清楚。然后结合整个社区的生态，思考一下自己的需求处于什么样的定位，毕竟大家都是基于问题出发。\n也是通过这次深入开发底层，让我们更清晰的认识到大家都是绑在一条船上的，也更理解开发者，毕竟大家初心都是为了共同的目标去努力。\n业务研发和开发者的双重身份是否有可持续性？ Q:这个状态还会一直持续下去吗？\nA:目前我已经成为了 SOFAArk 2.0 的核心开发人员，还会推进 SOFAArk 在蚂蚁主站大规模落地，作为开发的角色维护下去的。本身我们的 Serverless 产品它下面依赖的部署组建就是 SOFAArk，我们要去大规模落地的过程中，涉及到对 ark 的一些支持问题，所以我们可能需要深入到底层去剖析，让组件真正的更易用。\nQ:业务研发深入到中间件底层设计，在开源社区是一个普遍的现象吗？\nA:我理解应该是都有这样的现象，比如说我们用到动态热部署的能力，那我们对启动优化的东西，后面也会把它那个反馈到 SOFABoot、 Spring Boot 社区。\n在我们自己落地过程中遇到的问题，想到的创新解决方案，如果是通用的话，会往各个社区去提 pr、做一些反馈的进行同步。\n比如，我们在 SOFAArk 启动加速这一块，针对 Classloader 做了启动类加载的优化，启动速度平均提升了 50% 左右。\n目前这个已经在 Spring Boot 提了 pr，他们那边正在跟进；\nSOFABoot 这边也有相关的同学在保持跟进，之后我们会在我们主站率先去做一个 backport 的支持。\n业务研发专属经验分享 A:SOFAArk 负责人说你是一个追求细节、追求极致的同学。\nQ:我们团队是做 Serverless 产品的，产品的要求是“更快、更高效、性能更好、体验更好”。\n这就要求了我们在做代码优化的过程中去追求细节、追求极致，也是我们整个团队的风格。\nA:有了这种特殊经历后，有哪些经验可以分享给其他业务研发的吗？\nQ:作为业务研发，最开始我对 ark 也不是很了解的，刚接手 ark 的迁移的东西，也没敢想说去对 ark 做这么大的改造。\n一切基于我们团队的问题出发，一步步深入了解它的原理，去尝试实践自己想法，最终做出了开源的贡献，回过头来看才发现自己做了这么多。\n大部分业务研发不太愿意去参与这种开源贡献，可能就是把它想得比较难了。\n大家不用担心深入底层开发是很有门槛的事情，只要你带着问题出发，其他的都不是问题！\n看他不爽，就直接动手改吧！\n本周推荐阅读 社区文章｜MOSN 路由框架详解\nHAVE FUN | SOFARegistry 源码解析\nBabaSSL：支持半同态加密算法 EC-ElGamal\n恭喜 吕冰洁 成为 SOFAStack committer！\n","date":1640070000,"description":"SOFAArk Committer 专访｜看它不爽，就直接动手改！","dir":"blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"af2c0c99370a29c6e191e9a912277670","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","publishdate":"2021-12-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","summary":"吕冰洁（花名：尚之）蚂蚁集团技术专家 我们团队是在做蚂蚁集团内部 Serverless 项目，深度依赖 SOFAArk。SOFAArk 作为 Serverless 项目的核心热部署组件，在无","tags":["SOFAStack"],"title":"SOFAArk Committer 专访｜看它不爽，就直接动手改！","type":"blog","url":"/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","wordcount":1947},{"author":"曾柯","categories":"SOFAStack","content":" 文｜曾柯（花名：毅丝 )\n蚂蚁集团高级工程师\n负责蚂蚁集团的接入层建设工作,主要方向为高性能安全网络协议的设计及优化\n本文 10279 字 阅读 18 分钟\nPART. 1 引言 作为系列文章的第一篇，引言部分就先稍微繁琐一点，让大家对这个系列文章有一些简单的认知。\n先介绍下这个系列文章的诞生背景。QUIC、HTTP/3 等字眼想来对大家而言并不陌生。从个人的视角来看，大部分开发者其实都已经有了一些背景知识，比如 HTTP/3 的核心是依赖 QUIC 来实现传输层及 TLS 层的能力。而谈及其中细节之时，大家却又知之甚少，相关的文章大多只是浅尝辄止的对一些 HTTP/3 中的机制和特性做了介绍，少有深入的分析，而对于这些机制背后诞生原因，设计思路的分析，就更难得一见了。\n从个人并不大量的 RFC 阅读及 draft 写作经历来看，和撰写论文文献一样，为了保证一份 RFC 的精简以及表述准确，当然也是为了编写过程的简单。在涉及到其他相关协议时，作者往往是通过直接引用的方式来进行表述。这也就意味着直接通过阅读 RFC 来学习和了解网络协议是一个曲线相对比较陡峭的过程，往往读者在阅读到一个关键部分的时候，就不得不跳转到其他文档，然后重复这个令人头痛的过程，而当读者再次回到原始文档时，可能都已经忘了之前的上下文是什么。\n而 HTTP/3，涉及到 QUIC、TLS、HTTP/2、QPACK 等标准文档，而这些标准文档各自又有大量的关联文档，所以学习起来并不是一个容易的事。\n当然，系列文章的立题为“深入 HTTP/3”，而不是“深入 QUIC”，其背后的原因就是 HTTP/3 并不仅仅只是 QUIC 这么一个点，其中还包含有大量现有 HTTP 协议和 QUIC 的有机结合。在系列文章的后续，也会对这一部分做大篇幅的深入分析。\n一个协议的性能优秀与否，除了本身的设计之外，也离不开大量的软硬件优化，架构落地，专项设计等工程实践经验，所以本系列除了会针对 HTTP/3 本身特性进行分享之外，也会针对 HTTP/3 在蚂蚁落地的方案进行分享。\n引言的最后，也是本文的正式开始。\n据统计，人类在学习新的知识时，比较习惯从已有的知识去类比和推断，以产生更深刻的感性和理性认识。我想对大部分同学而言，“TCP 为什么要三次握手以及四次挥手？”这个问题，颇有点经典的不能再经典的味道，所以今天这篇文章也将从 QUIC 链接的建立流程及关闭流程入手，开始我们系列的第一篇文章。\nPART. 2 链接建立 2.1 重温 TCP “TCP 为什么要三次握手？”\n在回答问题之前我们需要了解 TCP 的本质，TCP 协议被设计为一种面向连接的、可靠的、基于字节流的全双工传输层通信协议。\n“可靠”意味着使用 TCP 协议传输数据时，如果 TCP 协议返回发送成功，那么数据一定已经成功的传输到了对端，为了保证数据的“可靠”传输，我们首先需要一个应答机制来确认对端已经收到了数据，而这就是我们熟悉的 ACK 机制。\n“流式”则是一种使用上的抽象(即收发端不用关注底层的传输，只需将数据当作持续不断的字节流去发送和读取就好了)。“流式”的使用方式强依赖于数据的有序传输，为了这种使用上的抽象，我们需要一个机制来保证数据的有序，TCP 协议栈的设计则是给每个发送的字节标示其对应的 seq(实际应用中 seq 是一个范围，但其真实效果就是做到了每个字节都被有序标示)，接收端通过检视当前收到数据的 seq，并与自身记录的对端当前 seq 进行比对，以此确认数据的顺序。\n“全双工”则意味着通信的一端的收发过程都是可靠且流式的，并且收和发是两个完全独立，互不干扰的两个行为。\n可以看到，TCP 的这些特性，都是以 seq 和 ACK 字段作为载体来实现的，而所有 TCP 的交互流程，都是在为了上述特性服务，当然三次握手也不例外，我们再来看 TCP 的三次握手的示意图：\n为了保证通信双方都能确认对端数据的发送顺序，收发端都需要各自记录对端的当前 seq，并确认对端已经同步了自己的 seq 才可以实现，为了保证这个过程，起码需要 3 个 RTT。而实际的实现为了效率考虑，将 seq 和 ACK 放在了一个报文里，这也就形成了我们熟知的三次握手。\n当然，三次握手不仅仅是同步了 seq，还可以用来验证客户端是一个正常的客户端，比如 TCP 可能会面临这些问题：\n(1)有一些 TCP 的攻击请求，只发 syn 请求，但不回数据，浪费 socket 资源；\n(2)已失效的连接请求报文段突然又传送到了服务端，这些数据不再会有后续的响应，如何防止这样的请求浪费资源？\n而这些问题只是三次握手顺手解决的问题，不是专门为了它们设计的三次握手。\n细心的你，可能已经发现了一个问题，如果我们约定好 client 和 server 的 seq 都是从 0(或者某个大家都知道的固定值)开始，是不是就可以不用同步 seq 了呢？这样似乎也就不需要三次握手那么麻烦了？可以直接开始发送数据？\n当然，协议的设计者肯定也想过这个方案，至于为什么没这么实现，我们在下一章来看看 TCP 面临什么样的问题。\n2.2 TCP 面临的问题 2.2.1 seq 攻击 在上一节我们提到，TCP 依赖 seq 和 ACK 来实现可靠，流式以及全双工的传输模式，而实际过程中却需要通过三次握手来同步双端的 seq，如果我们提前约定好通信双方初始 seq，其实是可以避免三次握手的，那么为什么没有这么做呢？答案是安全问题。\n我们知道，TCP 的数据是没有经过任何安全保护的，无论是其 header 还是 payload，对于一个攻击者而言，他可以在世界的任何角落，伪造一个合法 TCP 报文。\n一个典型的例子就是攻击者可以伪造一个 reset 报文强制关闭一条 TCP 链接，而攻击成功的关键则是 TCP 字段里的 seq 及 ACK 字段，只要报文中这两项位于接收者的滑动窗口内，该报文就是合法的，而 TCP 握手采用随机 seq 的方式（不完全随机，而是随着时间流逝而线性增长，到了 2^32 尽头再回滚）来提升攻击者猜测 seq 的难度，以增加安全性。\n为此，TCP 也不得不进行三次握手来同步各自的 seq。当然，这样的方式对于 off-path 的攻击者有一定效果，对于 on-path 的攻击者是完全无效的，一个 on-path 的攻击者仍然可以随意 reset 链接，甚至伪造报文，篡改用户的数据。\n所以，虽然 TCP 为了安全做出过一些努力，但由于其本质上只是一个传输协议，安全并不是其原生的考量，在当前的网络环境中，TCP 会遇到大量的安全问题。\n2.2.2 不可避免的数据安全问题 相信 SSL/TLS/HTTPS 这一类的字眼大家都不陌生，整个 TLS(传输安全层)实际上解决的是 TCP 的 payload 安全问题，当然这也是最紧要的问题。\n比如对一个用户而言，他可能能容忍一次转账失败，但他肯定无法容忍钱被转到攻击者手上去了。TLS 的出现，为用户提供了一种机制来保证中间人无法读取，篡改的 TCP 的 payload 数据，TLS 同时还提供了一套安全的身份认证体系，来防止攻击者冒充 Web 服务提供者。然而 TCP …","date":1640070000,"description":"深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进","dir":"blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","fuzzywordcount":9100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"399aa26268182488b3d65e0618367a35","permalink":"https://sofastack.github.io/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","publishdate":"2021-12-21T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","summary":"文｜曾柯（花名：毅丝 ) 蚂蚁集团高级工程师 负责蚂蚁集团的接入层建设工作,主要方向为高性能安全网络协议的设计及优化 本文 10279 字 阅读 18 分钟 PART. 1 引言 作为","tags":["SOFAStack"],"title":"深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进","type":"blog","url":"/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","wordcount":9072},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFA x 字节码联盟 WAMR 社区「WebAssembly Open Day」\n 活动时间：2021 年 12 月 18 日（周六）13:00-17:00\n 活动形式：线上直播\n 资料下载：\n 《蚂蚁集团 WASM 编译器虚拟机基础能力建设》 \n《WebAssembly Micro Runtime 开源技术解析与展望》\n《Waft: 基于 WebAssembly 的 AIoT 应用框架实践》\n《WASM 中的 GC 遐想》\n《WebAssembly 在区块链中的实践》\n《Wasm \u0026amp;amp; WAMR 在 AIOT 领域的应用》\n活动议程 活动回顾 嘉宾简介：\n《字节码联盟与 WAMR 开源社区进展介绍》\n王鑫 intel 技术经理 任职英特尔公司，关注计算机语言与运行引擎，可信计算和物联网等技术领域。开发与创建开源项目 WebAssembly Micro Runtime，参与推动英特尔、微软、Mozilla 等公司成立字节码联盟（Bytecode-Alliance），任字节码联盟技术管理委员会（TSC）成员。\n杨斌（花名：凯撒） 蚂蚁集团技术总监 任职蚂蚁集团技术总监，关注操作系统，计算机语言与运行引擎等技术领域。\nTill Schneidereit 字节码联盟董事会主席\nRalph Squillace 微软高级总监 字节码联盟董事会成员\n汤伟\n蚂蚁集团资深技术专家\n《蚂蚁集团 WASM 编译器虚拟机基础能力建设》\n嘉宾简介：\n汤伟，一直从事编译器和虚拟机相关工作，2020年11月加入蚂蚁金服，主导webassembly相关工具链的设计与开发。\n议题简介： 作为面向蚂蚁的 wasm 编译器、虚拟机基础平台团队，面向蚂蚁 wasm 用户核心诉求，针对开发效率、性能提升以及生态拓展，确定 wasm 编译器、虚拟机上的技术选型，探索未来编译器、虚拟机协同设计空间。\n听众收益： 了解wasm在蚂蚁的业务场景中的需求和我们的编译器、虚拟机技术能力建设上的一些探索。\n何良\nintel 资深软件工程师\n《WebAssembly Micro Runtime 开源技术解析与展望》\n嘉宾简介：何良，INTEL 资深软件工程师， WAMR开源项目核心开发者\n议题简介：主要介绍 WebAssembly Micro Runtime(WAMR) 的技术特性，发展历程以及路线图。面对嵌入式设备独特的资源条件和使用场景，WAMR进行了有针对性的特性开发，比如选用不同的运行模式适应不同的资源水平，利用XIP在文件系统中直接执行，在RUNTIME中支持 Sensor API 等。此外，WAMR努力打造高效的开发环境，提供源码级调试的功能框架和VSCODE插件。目前，支持高级语言（比如JAVA,KOTLIN等）和SOCKET APIs的功能开发正在有序展开。\n唐兹源\n阿里巴巴前端技术专家\n《Waft: 基于 WebAssembly 的 AIoT 应用框架实践》\n嘉宾简介：\n唐兹源，天猫精灵工程技术前端团队负责人，在智能硬件应用研发领域拥有超过 4 年的经验，专注于 AIoT 体验技术创新\n议题简介：\n本次分享将为大家带来天猫精灵技术团队基于 WAMR 和自研渲染引擎打造的应用框架实践经验，介绍 WebAssembly 在天猫精灵智能音箱以及生态硬件（如电视大屏、投影仪等）的应用场景，以及 Waft 应用框架体系的设计和思考\n听众收益：\n了解 WebAssembly 在智能音箱及电视大屏中的应用场景 了解天猫精灵技术团队如何结合 WAMR 和自研渲染引擎设计动态化容器 了解如何运用 AssemblyScript 设计适合 Web 开发者的应用框架及工具链建设\n臧琳\n腾讯云高级工程师\n《WASM中的GC遐想》\n嘉宾简介：腾讯云编程语言团队高级工程师，OpenJDK committer，专注于编程语言 Runtime 技术在云计算领域的优化与应用。\n议题简介：内存管理及垃圾回收技术是现代高级语言的核心技术之一，也是webassembly承载多语言支持的必经之路， wasm社区已经将GC proposal提上日程，本话题和大家一起进行一次头脑风暴，探讨未来wasm的内存管理及垃圾收集技术可能的发展方向。\n张磊\n蚂蚁集团技术专家\n《WebAssembly在区块链中的实践》\n嘉宾简介：毕业于北京大学，曾就职于华为编译器实验室。目前在蚂蚁链智能合约团队，从事编译器和虚拟机相关研发工作。\n议题简介：Wasm 的安全性、高性能和跨平台等优点，使其天然适合用作区块链智能合约的执行环境。另一方面，区块链对于安全性和确定性的极致要求，也对 Wasm 本身提出了一些技术挑战。本次分享将会结合蚂蚁链的实践经验，介绍 Wasm与区块链之间的各种奇妙“化学反应”。\n听众收益：将会了解到wasm在区块链领域的应用现状和面临的技术挑战。\n黄齐\n小米软件工程师/Vela OS 框架业务技术负责人\n《Wasm \u0026amp;amp; WAMR在AIOT领域的应用》\n嘉宾简介：负责小米Vela OS内核、中间件的研发和在不同架构上的落地，带领团队完成了基于Wasm的应用开发框架的开发和落地，支撑了小米内部多项业务发展\n议题简介：Wasm 作为诞生于浏览器的技术，为何能在 IoT 领域大放异彩？在内存只有数十 KB 级别的运行环境里使用 Wasm，我们将面临怎样的挑战和困难？本次向大家分享小米对 Wasm 技术在 IoT 应用中的实践与思考\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1639810800,"description":"【活动回顾】《WebAssembly Open Day》","dir":"activities/sofa-meetup-13/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6055a6cf6a48ee5bfe63e2c249c2e3d4","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-13/","publishdate":"2021-12-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-13/","summary":"概要 活动主题：SOFA x 字节码联盟 WAMR 社区「WebAssembly Open Day」 活动时间：2021 年 12 月 18 日（周六）13:00-17:00 活动形式","tags":["SOFA"],"title":"【活动回顾】《WebAssembly Open Day》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-13/","wordcount":1931},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@孙军超 提问：\n 请教一下 JRaft 里， Bolt 的 logback 日志怎么关掉 ?\n A：可以参考这个文件。https://github.com/sofastack/sofa-jraft/issues/724\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@超 提问：\n 这种方式运行 Wasm 的时候，Layotto 自身加上运行时部分初始化需要加载 Dapr 组件时间可能总共要 1-2s（还没有实测，因为目前只用过 Dapr，后面会实际运行一下）。这方面冷启动延迟一方面可以精简 Wasm 的 runtime 仅包括 Dapr 或者 Layotto 的 SDK 通过网络来通信；另一方面就是优化运行时的启动时间。作者对这方面问题有想法吗？\n A:这个问题属于 Layotto 自身如何快速初始化，目前我们也在这方面做一些尝试，比如优化调度算法，让某些特征的函数调度到特定的 Layotto 上，这样就可以让 Layotto 提前初始化好资源。不过这只是函数急速调度中的一个环节，实际落地过程中还有调度算法执行耗时，Pod 启动耗时，函数自身启动耗时等等因素，这也是我们目前正在努力的方向。\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Python 或 C++ 、SDK\n开发 Spring-Boot-Layotto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 让用户使用@SofaService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nSOFARegistry 本周发布 SOFARegistry V6 正式发布的第一个版本。\n主要更新如下：\n 运维难度大幅度降低 自身元数据存储插件化，如果不希望引入 raft 运维的复杂性，支持基于 db 实现。meta、session 无状态化，data 弱状态化。\n 性能和可扩展能力大幅提升 横向扩展能力大幅度提升，能够横向扩展至 300+ session 节点，能够承载亿级服务数据。\n「详细参考」：https://github.com/sofastack/sofa-registry/releases/tag/v6.1.4\n网商双十一基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\n降本提效！注册中心在蚂蚁集团的蜕变之路\n","date":1639724400,"description":"开发者的搬砖日常、社区本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211217/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"42ba6063d3d0ebea2b80a70c23e77497","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211217/","publishdate":"2021-12-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211217/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 本周 Contributor、QA 整理、SOFARegistry 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211217/","wordcount":1387},{"author":"张化仁","categories":"SOFAStack","content":" 文｜张化仁（花名：花伦 )\n网商银行基础技术架构部架构师\n校对｜阚广稳(花名：空门)\n本文 4832 字 阅读 10 分钟\n｜引言｜ 微服务架构下，服务之间的调用错综复杂，一个应用可能会承载着多种不同的业务流量。由于运行在同一个应用进程内，多种业务流量之间势必会存在相互影响的情况。\n如果某种业务流量陡增，导致应用进程负载激增，进而请求排队，其它业务流量也势必会受影响。多数时候这种相互影响的情况都是在容忍范围以内或者可以规避的，特定场景下我们可能就需要考虑通过隔离某些业务流量的方式，来消除业务之间相互影响的风险：\n 例如，当后台调度型的流量影响了在线用户请求；\n 再如，当低敏的甚至可失败的业务影响了高敏的需要重保的业务。\n 业务链路隔离的诉求是业内普遍存在的。通常的方案是新创建一个应用，然后将需要隔离的业务迁移到这个新应用上。\n新建应用的方式，研发运维等都需要付出成倍的成本，相关应用还需要配合改造和迁移。对于只有单个应用需要创建的情况或许还能勉强接受，网商银行部分应用例如高保极简网关、高保客户视图等当前就是采用的这种方案。这种方式是非常笨重的，而且当我们期望特定业务关联的整条链路上的多个应用都进行业务隔离的话，这种方案的成本将非线性上升进而变得难以接受。\n云原生架构下，对容器和流量可以进行更精细化的管控，对于上述业务流量隔离的场景，我们有了更简洁、更灵活、更通用的替代方案\u0026amp;ndash;我们称之为「业务单元隔离」，可以在不创建新应用的情况下实现上述诉求。此方案当前已在包括核心链路在内的网商多个业务场景得到应用，也顺利通过了今年双十一大促的考验。\n那么「业务单元隔离」具体是什么？我们是如何借助「业务单元隔离」实现业务链路的隔离呢？本文将和大家细述。\nPART. 1 概念及基本原理 概念及运维模型 「业务单元隔离」是一套流量染色和资源隔离的方案，可以帮助业务相对简单地实现业务链路隔离。在调研和验证的过程我们也提出了优化改进方案并推进落地，最终进一步减轻了业务接入的成本。\n「业务单元隔离」需要结合两个新的概念来阐述：「AIG」和「业务单元」。\nAIG 是某个应用为了支撑某些业务而隔离出来的一组资源。由一个或多个应用的 AIG 组成的、服务与某个或某类特定业务的业务链路我们称为一个业务单元。保证有且只有符合特征的流量引流到某个业务单元，我们称之为「业务单元的隔离部署」。\n主要任务及配套设施 从「业务单元隔离」的概念中我们不难看出：要实现某个业务链路的流量隔离，至少需要做有以下几件事情：\n1.业务单元构建：给链路上的应用分别创建 AIG 组成一个业务单元，且须保证不能有流量流入新建的业务单元。\n2.业务流量识别：需要通过某种方式识别出上游应用流入的特定业务的流量。\n3.特定业务引流：对于识别到的特定业务的流量，需要有机制让这些流量流向新创建的业务单元。\n很显然，上述的这些事情，必然需要基础设施侧和应用侧相互配合才可实现。如下图所示，相关的基础设施及作用如下：\n1.业务单元构建：需要为 AIG 提供完整的研发/运维/监控支持；\n2.流量识别（RPC）：链路中业务单元上游的应用（A）需要接入打标染色 SDK，以便通过染色管控平台下发打标染色规则；\n3.流量识别（调度）：复杂调度（消息触发，应用单 LDC 内自主分发批任务）通过转换成基于 SOFARPC 的流式任务，从而实现染色和隔离。\n4.特定业务引流：MOSN 侧的精细化路由需要支持 AIG，让流量可以流入到新特定的业务单元。\n业务单元构建 业务单元实际是一个相对抽象的概念，对应一条业务链路。\n网商的实践中，为了让业务单元更加具象化，我们规定一个业务单元内的多个应用，其 AIG 名称（appname-aigcode）中的 aigcode 部分必须尽可能一致。\n因此，构建一个特定的业务单元，本质上是要给链路上相关的应用，都创建出服务于特定业务隔离的资源组（AIG）。\n对于单个应用，构建 AIG 包含两部分：\n一是初始化 AIG 元数据；\n其次是围绕此 AIG 的各种运维操作（扩缩容、上下线、重启、sidecar 注入升级等）。\n可以看到要支持 AIG，PaaS 侧几乎所有运维操作都需要适配，工作量非常很大。所以 PaaS 侧在支持 AIG 这件事情上也必须权衡取舍，决定只在终态的 workload 运维模式下支持了 AIG，这也导致 AIG 强依赖应用从现有的 image 的模式迁移到 workload 的模式。\nworkload 运维模式下，PaaS 将发布和运维的内容都编排成 CRD 资源，交给底层 sigma（K8s）做运维。切换到 workload 运维模式有利于集团统一发布运维体系，也可以更好的支持弹性扩缩容、自愈等场景。\n但相比 image 模式，workload 模式对用户使用习惯和体验上冲击很大，初期相关的问题也非常多。因此尽管网商 workload 一直在有序推进，在后续核心业务接入 AIG 的项目中，为了避免强制切换到 workload 运维模式影响核心业务运维应急，我们也给 PaaS 提了支持仅对 AIG 机器开启了 workload 的诉求，并且针对这种情况做了完备的混合运维验证。\nRPC 流量隔离 业务单元创建好之后，如何确保新的业务单元在不引流的情况下默认没有 RPC 流量流入呢？\n应用的机器之所以有 RPC 流量流入，是因为注册中心（SOFARegistry）和跨机房负载均衡（AntVip）中挂载了机器 IP：应用进程启动成功 MOSN 感知到后，MOSN 会将服务信息注册到 SOFARegistry，发布运维过程机器健康检查通过后 PaaS 侧会调用接口往 AntVip 上挂载机器的 IP。\n所以，要确保新的 AIG 机器默认没有流量流入，就需要 MOSN 和 PaaS 侧做出调整。\n整体调整方案如下图所示：\n如何识别特定业务的 RPC 流量呢？\n上游应用接入打标染色 SDK 之后，其在作为服务端被其它应用调用、作为客户端调用其它应用的时候，都可以被 SDK 中的 RPC 拦截器拦截，拦截器对比 RPC 请求和下发的打标染色规则，一旦 match 就会在 RPC Header 中增加业务请求标识。\n最后，就是将流量引流到特定业务单元。\n借助 MOSN 强大的精细化路由能力，我们可以让流量路由到指定的业务单元,并在业务单元内部收敛。业务单元隔离主要用到了 MOSN 的客户端路由能力，在客户端应用发起调用、请求流经当前 Pod 的 MOSN 时，可以按我们下发的路由规则控制流量的走向。\n调度流量隔离 调度本质是消息，简单的调度场景通常也不会有隔离的诉求。很多有隔离诉求的场景当前都是“消息任务+三层分发”的模式，利用调度触发批处理逻辑。\n三层分发协议是基于 tb-remoting 协议分发请求的，不是标准的 SOFARPC 协议，不经过 MOSN，因此 MOSN 也无法控制这种请求的走向。\n为了解决这个问题，AntScheduler 推出了全新的流式调度模式，通过将三层分发模式转变成多次标准 SOFARPC 调用，从而和 MOSN 无缝配合，满足流量隔离的诉求。\n对于希望调度流量直接路由到 AIG 的场 …","date":1639465200,"description":"网商双十一-基于 ServiceMesh 技术的业务链路隔离技术及实践","dir":"blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"472fb3f3bcfec5e7e03683b781646824","permalink":"https://sofastack.github.io/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","publishdate":"2021-12-14T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","summary":"文｜张化仁（花名：花伦 ) 网商银行基础技术架构部架构师 校对｜阚广稳(花名：空门) 本文 4832 字 阅读 10 分钟 ｜引言｜ 微服务架构下，服务之间的调用错综复杂","tags":["SOFAStack"],"title":"网商双十一-基于 ServiceMesh 技术的业务链路隔离技术及实践","type":"blog","url":"/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","wordcount":4521},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@证道者 提问：\n MOSN 的网络性有做新的技术尝试吗?\n A：这个是我们今年在网络性能上的尝试，内部也在网关场景落地，后续也会开源出来。iouringv 之前我们做过测试，在我们的场景提升有限。\nhttps://mp.weixin.qq.com/s/ioewVcwiB5QA8w3A3gaikg\n「MOSN」：https://github.com/mosn/mosn\n@赵一凡 提问：\n 问下 SOFALookout 的客户端可以直接把默认已有度量指标推送到 ES 吗？\n A：一般客户端是上报到 lookout 服务端, 再由服务端决定要写到哪。\n「SOFALookout」：https://github.com/sofastack/sofa-lookout\n@开发者 提问：\n 这个 Test 模块是用来开发者做测试的还是做自动化测试的？\n A：用于 jraft 的 jepsen 验证，参考这个项目：\nhttps://github.com/sofastack/sofa-jraft-jepsen\njraft 每次发版前要确保通过 jepsen 验证。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@小楼 提问：\n 请问 session 是如何支持 Dubbo 的元数据的？\n A：Registery 的元数据现在不是通用的，只针对 SOFARPC。\n session 之间应该是没有数据同步的吧，跨 session 节点怎么办呢？\n A：现在会同步两个信息，一个是元数据，一个是接口级订阅，接口级订阅是用于兼容没升级的应用。同步的路径是通过存储，类似 K8 的 listwatch 机制，内部落地存储的插件实现是 db，这个块数据比较少，就几千行吧，而且变化很小。\n「SOFARegistery」：https://github.com/sofastack/sofa-jraft\n@小楼 提问：\n 是用什么 db 存储的?\n A：蚂蚁内部的 db 普遍都是 ob，不过代码是兼容 mysql 的。\n「SOFARegistery」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API、分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 Service Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\nService Mesh 双十一后的探索和思考(下)\n蚂蚁 Service Mesh 大规模落地实践与展望\n","date":1639119600,"description":"开发者的搬砖日常、社区本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211210/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c8ef24b5957863311a11eff48080bc30","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211210/","publishdate":"2021-12-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211210/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开发者的搬砖日常、社区本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211210/","wordcount":1289},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#23：蚂蚁服务发现的大规模实践与展望\n 活动时间：12 月 09 日，周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#23：蚂蚁服务发现的大规模实践与展望 naming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。本次分享将会包含以下内容：\n 蚂蚁内部实践 naming 在云原生时代下的发展方向及趋势 总结和展望 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 林育智 蚂蚁集团高级技术专家。 目前在蚂蚁集团中间件团队负责 naming 等项目的研发工作 议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:30 蚂蚁服务发现的大规模实践与展望 林育智，蚂蚁集团高级技术专家\n你将收获 了解蚂蚁集团在 SOFARegistry 新挑战及云原生时代的思考。\n了解 SOFARegistry 实践经验。\n了解蚂蚁集团对未来 naming 的思考及 naming 在云原生方向上的探索。\n了解未来 SOFARegistry 的发展和相关的社区动向。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1639033200,"description":"12 月 09 日周三晚 19 点，线上直播第 23 期。","dir":"activities/sofa-channel-23/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"781a397af19af21ad03eef254f28fe69","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-23/","publishdate":"2021-12-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-23/","summary":"概要 活动主题：SOFAChannel#23：蚂蚁服务发现的大规模实践与展望 活动时间：12 月 09 日，周三晚 19 点 活动形式：线上直播 资料下载：戳这里","tags":["SOFAChannel","SOFARegistry"],"title":"SOFAChannel#23：蚂蚁服务发现的大规模实践与展望","type":"activities","url":"/sofastack.tech/activities/sofa-channel-23/","wordcount":709},{"author":"顾欣","categories":"SOFAStack","content":" Service Mesh 是下一代的微服务架构基础。蚂蚁集团从 2018 年初就开始了技术探索并进行了落地试点。目前， Service Mesh 覆盖了蚂蚁数千个应用，实现了核心链路全覆盖。\n蚂蚁集团通过 Service Mesh 的大规模落地，向云原生走出了坚实的一步，验证了可行性，真切看到了基础设施下沉后无论是对业务还是对基础设施团队都带来了研发和运维效率的提升，成本的降低。\n与此同时，蚂蚁也在积极将成熟的技术开放给社会，目前已将自研数据面 MOSN 开源，欢迎开源爱好者一起共建。\nhttps://github.com/mosn/mosn\n｜前言｜ 微服务架构是当今互联网和金融机构渐趋主流的系统架构模式，其核心是集成服务通信、服务治理功能的服务框架，微服务框架在持续演进同时，服务网格（Service Mesh）作为一种新型的微服务架构，因架构灵活、普适性强，被认为具有较好发展前景。\n中国工商银行（后简称工行）主动探索服务网格领域，从 2019 年开始服务网格技术预研工作，通过对服务网格技术深入研究和实践后，于 2021 年建设了服务网格平台。服务网格与现有微服务架构融合发展，助力工行应用架构向分布式、服务化转型，承载未来开放平台核心银行系统。\nPART. 1 业界服务网格发展现状 自 2016 年服务网格技术诞生以来，业界涌现了诸多的开源产品，如 Istio（Google + IBM + Lyft）、Linkerd（Twitter）、Consul（Hashicorp）等。其中以 Istio 社区活跃度和认可度最高，被作为服务网格的标杆开源产品。\n服务网格是一个专门处理服务通讯的基础设施层。它通过在业务 Pod 中注入 Sidecar 容器，接管业务容器的通信流量，同时 Sidecar 容器与网格平台的控制平面对接，基于控制平面下发的策略，对代理流量实施治理和管控，将原有服务框架的治理能力下层到 Sidecar 容器中，从而实现了基础框架能力的下沉，与业务系统解耦。\n图 1：服务网格示意图\nSidecar 容器接管后端服务通信的进出流量后，通过标准协议进行服务间通信，可实现跨语言、跨协议的服务互访。此外，Sidecar 容器可对代理的流量进行管控，如统一的服务路由、安全加密、监控采集等。\n图 2：服务网格请求流转过程示意图\nPART. 2 服务网格技术在工行的 探索与实践 工行从 2015 年开启了 IT 架构转型工程，截止目前分布式体系已覆盖 240 余个关键应用，生产已有约超 48 万个提供方分布式服务节点，日均服务调用量超 127 亿，逐步实现了超越主机性能容量的集群处理能力。工行分布式服务平台在稳定支撑已有业务系统的平稳运行同时，也存在一些业界共性的挑战，诸如：\n（1）跨语言技术栈的互联互通需研发多套基础框架，技术研发和维护成本高。\n（2）多产品线下，各应用使用了不同版本的基础框架，推动各应用升级框架周期较长，生产并行运行多版本的基础框架，兼容压力较大。\n为解决当前痛点，工行积极引入服务网格技术，探索解耦业务系统与基础设施，完善服务治理能力。\n与微服务框架融合发展，构建企业级服务网格平台 服务网格（Service Mesh）平台在建设过程中，集成了原有分布式体系的注册中心、服务监控等基础设施，将原服务框架客户端中最基础的通讯协议编解码能力以轻量级客户端的形式保留在业务系统中，其余服务框架客户端的能力均下沉至 Sidecar 中，可与服务框架兼容发展，平滑过渡。\n目前工行已完成服务网格（Service Mesh）平台的建设，在与分布式服务平台融合发展过程中，打通了异构语言系统的服务治理与监控体系，解耦了业务与中间件系统，丰富了流量治理能力，并已在智能投顾、文字识别等应用完成业务试点。\n图 3：服务网格边车（Sidecar）与微服务 SDK 对比图\n服务网格控制平面包含了配置中心、注册中心、安全中心、管控中心、监控中心、日志中心等模块。数据平面 Sidecar 与原服务框架使用相同的通讯协议（Dubbo/Spring Cloud），支持服务网格系统与原服务框架系统互联互通，平滑迁移。\n图 4：工行服务网格架构图\n探索企业级方案，支持规模化部署和平滑迁移 工行服务网格在大数据、高频联机等服务场景下，对流量代理部署模式、平滑迁移、性能优化等方面开展了落地实践。\n（1）大数据场景下的无侵入流量代理部署模式\n工行应用开发语言主要使用 Java，但在大数据领域 Python 语言也被广泛使用。针对异构语言场景，服务网格平台提供了无侵入透明劫持的流量代理方案，简化了异构语言应用接入难度。无侵入流量代理的核心是通过修改网络 Iptables 规则，强制拦截进出业务容器的流量，并将这部分流量重定向至 Sidecar 容器。\n其具体实现为：在启动业务 Pod 时，通过 Init Container（初始化容器）修改业务 Pod 的网络 Iptables 规则，该规则让进出业务容器的流量都强制重定向至 Sidecar 容器，实现 Sidecar 容器对业务容器的流量接管。\n图 5：透明劫持流量代理示意图\n但是 Iptables 对性能和可维护性都存在较大的挑战，故在联机高频服务场景，我们提供了轻量级客户端与 Sidecar 协作的流量代理方案。\n（2）高频联机场景下的低侵入流量代理部署模式\n在联机高频服务场景，我们通过对业务应用引入轻量级的客户端，该客户端在对业务透明的前提下，改变业务应用的服务注册发现行为，将原往注册中心发起的服务注册与订阅的行为转变为往本地 127.0.0.1 的 Sidecar 地址发起服务注册与订阅，并由 Sidecar 代理向注册中心发起服务注册与订阅。业务容器通过 Sidecar 代理订阅后，本地获取的服务目的地址则为 127.0.0.1 的 Sidecar 地址，后续所有请求将会直接发往 Sidecar，再由 Sidecar 转发至真实的服务目的地址，实现流量代理能力。\n图 6：端口流量代理示意图\n（3）传统部署向网格化部署的平滑迁移\n目前工行微服务主要有基于 Dubbo 和 Spring Cloud 两种服务实例组成，且已在生产环境大规模运行，在引入服务网格系统时需具备与原微服务系统的平滑过渡能力。工行通过服务网格系统同时支持 Dubbo 与 Spring cloud 协议，服务网格实例可与原服务框架实例通过相同协议互相访问。使在同一注册中心下，服务网格系统与原分布式服务系统可融合发展，平滑过渡。\n图 7：平滑迁移示意图\n（4）规模化部署后的性能挑战与优化\n目前工行最大的注册中心集群上有超 48 万提供者的超大规模业务场景，而在开源 Isito 架构中，服务发现的目的地址、配置信息等会通过 Pilot 的 Xds API 进行全量下发。在大量服务实例的情况下，全量下发会影响 Pilot 和 Sidecar 的性能和稳定性。服务网格平台通过引入第三方注册中心与配置中心。由 Sidecar 直接对接注册中心与配置中心，支持按需订阅，配置精准下发，大幅降低 Pilot 和 Sidecar 压力。通过压测，控制平面具备支持百万级实例的性能容量能力。\n图 8：工行控制面组件演进 …","date":1639033200,"description":"Service Mesh 在中国工商银行的探索与实践","dir":"blog/exploration-and-practice-of-service-mesh-in-icbc/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a597abc497eb1d695c4aa838d6cb6545","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","publishdate":"2021-12-09T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","summary":"Service Mesh 是下一代的微服务架构基础。蚂蚁集团从 2018 年初就开始了技术探索并进行了落地试点。目前， Service Mesh 覆盖了蚂蚁数千个应用，实现了核心链路全覆盖。 蚂蚁集","tags":["SOFAStack"],"title":"Service Mesh 在中国工商银行的探索与实践","type":"blog","url":"/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","wordcount":3781},{"author":"马振军","categories":"SOFAStack","content":" 文｜马振军（花名：古今 )\n在基础架构领域耕耘多年\n目前在蚂蚁集团中间件团队\n负责 MOSN、Layotto 等项目的开发工作\n校对｜卓与、齐天\n本文 9053 字 阅读 18 分钟\n｜前言｜ 在过去几年里，蚂蚁集团的基础设施进行了广受瞩目的大规模 Mesh 化改造，成为业内服务网格化的一个标杆。在收获了基础架构团队掌握数据平面带来业务敏捷性的同时，也享受到了将基础设施 SDK 从应用中剥离出来后，带来的应用和基础设施双方更高的易维护性。\n然而服务网格并不是银弹，大规模落地后也面临着新的问题。\n适逢其时，微软牵头的 Dapr 横空出世，把分布式应用运行时的概念带入了大众视野，我们也尝试使用这种思路来解决 Mesh 化后遗留的问题。\n本文通过回顾蚂蚁集团一路从微服务架构到 Service Mesh 再到分布式应用运行时的整个演进历程，结合生产落地过程中遇到的各种问题及思考，尝试探讨一下未来五年，云原生运行时可能的发展方向。\nPART. 1 从 Service Mesh 到应用运行时 2018 年，蚂蚁集团在 Service Mesh 刚刚开始流行的时候，就在这个方向上大力投入，如今已三年有余。Sevice Mesh 早已在公司内大规模落地，支持了生产环境数十万容器的日常运行。\n19 年下半年，Dapr 项目正式开源并持续火爆，应用运行时的概念引起了人们的关注，蚂蚁集团也踏上了从 Service Mesh 到应用运行时的演进道路。\nA、蚂蚁 Service Mesh 实践的收获与遗留问题 在传统的微服务架构下，基础架构团队一般会为应用提供一个封装了各种服务治理能力的 SDK，这种做法虽然保障了应用的正常运行。但缺点也非常明显，每次基础架构团队迭代一个新功能都需要业务方参与升级才能使用，而遇到 bugfix 版本，往往需要强推业务方升级，这里面的痛苦程度基础架构团队的每一个成员都深有体会。\n伴随着升级的困难，随之而来的就是应用使用的 SDK 版本差别非常大。生产环境同时跑着各种版本的 SDK ，这种现象又会让新功能的迭代必须考虑各种兼容，时间一长就会让代码维护非常困难，有些祖传逻辑更是不敢改也不敢删。\n同时这种“重” SDK 的开发模式，导致异构语言的治理能力始终很难对标主语言，各种保障高可用的能力都无法作用于异构语言应用。\n后来有人提出了 Service Mesh 的理念，这种理念旨在把服务治理能力跟业务解耦，让两者通过进程级别的通信方式进行交互。在这种架构下，各种服务治理能力从应用中剥离，运行在独立的进程中，让业务团队跟基础架构团队可以各自进行迭代更新，大幅度提升效率。\n同时 SDK 因为功能减少而变“轻”则降低了异构语言的接入门槛，让这些语言开发的应用有机会对标主语言的治理能力。\n在看到 Service Mesh 理念的巨大潜力之后，蚂蚁集团很快就在这个方向上进行了大力投入，如上图所示，首先是使用 Go 语言自研了可以对标 envoy 的数据面。然后把 RPC 中各种治理能力下沉了到 MOSN 中，这样 RPC 的 SDK 变“轻”，而其他基础设施的 SDK 则依旧维持现状。\n在 RPC 能力完成 Mesh 化改造之后，我们进行了快速推广，如今达到了数千个应用，数十万个容器的生产规模。与此同时，全站升级频率最快可以达到 1~2 次/月，这跟传统微服务架构下 1~2 次/年的升级频率相比达到了一个质的提升。\nB、蚂蚁初步泛 Mesh 化的探索 在 RPC 能力完成 Mesh 化改造并且验证了这种架构的可行性以及体验到 Mesh 化带来的迭代效率大幅度提升的收益以后，我们正式走上了整个基础设施泛 Mesh 化改造的道路。\n如上图所示，在泛 Mesh 化改造的大趋势下，除了 RPC 以外，缓存、消息、配置等一些常用的基础设施能力迅速从应用中剥离，下沉到 MOSN 中，这套架构极大的提高了整个基础架构团队的迭代效率。\n正如软件工程没有银弹说的那样，随着泛 Mesh 化落地规模逐渐扩大，我们逐渐意识到它遗留的问题，如上图所示。\n在这种架构下，虽然应用跟基础设施之间加了一层网络代理，但对于基础设施协议部分的处理依然保留在 SDK 中，这就导致应用本质上还是要面向某个基础设施做开发，比如想使用 Redis 作为缓存实现，那么应用需要引入 Redis 的 SDK，未来如果想切换到 Memcache 等其他缓存实现，则必须对应用进行改造。\n除了替换 SDK 之外，甚至还涉及到调用 API 的调整，因此这种架构完全无法满足当前公司面临的同一个应用在多个平台部署的需求。\n与上述问题类似，泛 Mesh 化改造后，“轻” SDK 的低开发成本让各种异构语言都有机会接入到整个基础设施体系中来，享受多年基础设施建设的红利。\n但由于 SDK 里仍然保留了通信、序列化等协议的处理逻辑，因此随着接入的语言越来越多样化，这里依然存在不能忽视的开发成本。换句话说，泛 Mesh 化改造带来的“轻” SDK 跟传统微服务架构相比虽然降低了异构语言接入基础设施的门槛，但是随着接入语言越来越多样，依赖的中间件能力越来越丰富，我们还需要尝试进一步降低这种门槛。\n如果对上述两个问题做一层抽象，本质上都可以归结为应用跟基础设施之间的边界不够清晰，或者说应用中始终嵌入了某种基础设施实现中特有的处理逻辑，导致两者一直耦合在一起。\n因此如何定义应用跟基础设施之间的边界，让两者彻底解绑是我们当下必须要思考解决的问题。\nPART. 2 重新定义基础设施边界 A、如何看待 Dapr Dapr 项目由微软牵头，于 19 年下半年正式开源，作为分布式应用运行时的一种实现方案登上舞台，引起了广泛关注，它向我们展示了如何定义应用跟基础设施之间的边界。\n上图是 Dapr 官方提供的架构图，跟 Service Mesh 架构类似，Dapr 采用 Sidecar 的模型部署在应用跟基础设施之间。但与之不同的是，Dapr 基于 HTTP/gRPC 这类标准协议向应用提供了一套语义明确、面向能力的 API ，让应用可以不再关心基础设施的实现细节，只需专注业务本身依赖哪些能力即可。\n目前 Dapr 已经提供了较为丰富的 API，包括状态管理、发布订阅、服务调用等常见基础设施能力，基本能够覆盖业务日常开发的需求，并且每种能力都对应了多种具体的基础设施实现，开发者可以按需自由切换且这种切换对应用完全透明。\n除了能力之外，Dapr 官方也给出了 Dapr 跟 Service Mesh 之间的异同点，如上图所示。\n两者虽然有一些交集，但本质不同，Service Mesh 强调的是透明的网络代理，它并不关心数据本身，而 Dapr 强调的是提供能力，是真正站在应用的角度来思考如何降低应用的开发成本。\nDapr 本身的优势非常明显，不过 Service Mesh 所提供的丰富的网络治理能力，也是保障应用生产稳定性的关键点。\n与此同时 Dapr 跟基础设施的交互也无法离不开网络，因此有没有一种解决方案可以让应用运行时跟 Service Mesh 双剑合璧，降低应用开发成本的同时保留丰富的网络治理能力？\nB、Layotto：Servcie Mesh \u0026amp;amp; …","date":1638860400,"description":"云原生运行时的下一个五年","dir":"blog/the-next-five-years-of-cloud-native-runtime/","fuzzywordcount":8100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2498666960b384ded6da40a6158f9535","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","publishdate":"2021-12-07T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","summary":"文｜马振军（花名：古今 ) 在基础架构领域耕耘多年 目前在蚂蚁集团中间件团队 负责 MOSN、Layotto 等项目的开发工作 校对｜卓与、齐天 本文 9053 字 阅","tags":["SOFAStack"],"title":"云原生运行时的下一个五年","type":"blog","url":"/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","wordcount":8008},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@xj 提问：\n 请问在 UseNetpollMode 模式下，for 循环读取链接里面的数据，那么如果遇到链接数据源源不断的情况：比如刚 readOnce 读取完毕所有数据后，再下一个循环，又有数据被写入到链接接收缓冲区里面，那么又会继续读取到。此时会损耗很多时间处理这个链接的 io 事件，影响其他链接的处理。\n A：执行久了这个协程会被 runtime 调度走哟,当然也可以多少次 read 就主动 schedule, 这个可能就要看压测数据了，配置多少合适。最开始 nginx 也是存在类似问题。\nhttps://github.com/nginx/nginx/commit/fac4c7bdf53ee7d8fec6568f1e9fecefcde6feba#diff-8f5c3450fb35200b97b96bb249ca15d6\n「MOSN」：https://github.com/mosn/mosn\n@子旦 提问：\n 请教下群里的大佬，SOFARPC 相较于 Dubbo RPC 的优势在哪？有没有相关资料，求分享～\n A：可以看下 FAQ 里面有描述。\nhttps://www.sofastack.tech/projects/sofa-rpc/faq/\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@福自奇 提问：\n 5 个 jraft 节点，一个节点挂了没及时维修，剩下四个节点两两网络分区，2|2，此时集群是不是不可用了。\n A：是，因为已经多数派不可用了（最多只有 2 个节点可用）。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@福自奇 提问：\n bolt 下面输出的日志，jraft 提供了归档或者自动删除的选项吗？现在发现 bolt 下面的日志占用内存 7g 了，是要自己写脚本定时删除吗？\n A：日志没有自动删，可以自己用脚本删。\n 这个如果没有节点异常，好像不会打？只有节点挂了才会打？\n A：bolt 日志正常都会有，如果想关掉可以看下 GitHub 上最新被 close 的 issue。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy 开发 in-memory 组件\nfail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 降本提效！注册中心在蚂蚁集团的蜕变之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1638514800,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211203/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3866acfa6aee9d270af2995d820dcb64","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211203/","publishdate":"2021-12-03T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211203/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211203/","wordcount":1289},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@洪艺辉 提问：\n 无损迁移 TCP Listener 之后，在新 MOSN 上重新 server.Serve(net.Listener)，老 MOSN 那个 Listenr 能马上死掉的 API?\n A：New MOSN 启动成功之后，就关闭老的。\n「MOSN」：https://github.com/mosn/mosn\n@大白 提问：\n MOSN 借助 FastHTTP 解析，是不是就没考虑大的请求了。这边不做处理的考虑是什么呢？\n A：MOSN 有个地方限制太大的请求，好像还可以配置来着。\n 是的，注意到有限制最大 body 大小，但是遇到一些大请求对 Sidecar 压力会很大吧。\n A：RPC 场景一般没有大包，我们有个 issue 是直接 Stream。FastHTTP 也支持流式，要适配下，有兴趣可以一起来搞搞。\nhttps://github.com/mosn/mosn/issues/1676\n「MOSN」：https://github.com/mosn/mosn\n@xj 提问：\n 咨询下 MOSN 在做 gRPC 代理的时候，如何解决代理识别客户端新增的 proto ？难道客户端多一个 proto 代理也要增加？ 还是说直接在 HTTP2.0 层面做？\n A：就是 HTTP2.0 层面，代理一般不需要识别 body。\n「MOSN」：https://github.com/mosn/mosn\n@TyCoding 提问：\n 请问 SOFARPC 不使用 SOFABoot 的话，就只能用这种方式发布服务和消费吗？那如果多个接口呢?\n A：多个接口，就多个 providerconfig 即可。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@王金鹏 提问：\n 有个问题想请教一下 SOFABoot 和 bolt 之间版本兼容的问题，SOFABoot 版本 2.3.4，bolt 原版本 1.4.2 升级到 1.5.8 会不会有兼容性的问题？\n A：最好不要这么升级，bolt 不同版本 API 可能存在差异，最好直接把 SOFABoot 版本升级上去，对应的依赖都是我们测试过的。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy 开发 in-memory 组件\nfail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 降本提效！注册中心在蚂蚁集团的蜕变之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1637910000,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211126/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"134422b15d1bd92c49604b5b45687076","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211126/","publishdate":"2021-11-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211126/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211126/","wordcount":1331},{"author":"林育智","categories":"SOFAStack","content":" 文｜林育智（花名：源三 )\n蚂蚁集团高级专家 专注微服务/服务发现相关领域\n校对｜李旭东\n本文 8624 字 阅读 18 分钟\n｜引 言｜ 服务发现是构建分布式系统的最重要的依赖之一， 在蚂蚁集团承担该职责的是注册中心和 Antvip，其中注册中心提供机房内的服务发现能力，Antvip 提供跨机房的服务发现能力。\n本文讨论的重点是注册中心和多集群部署形态（IDC 维度），集群和集群之间不涉及到数据同步。\nPART. 1 背 景 回顾注册中心在蚂蚁集团的演进，大概起始于 2007\u0026amp;frasl;2008 年，至今演进超过 13 年。时至今日，无论是业务形态还是自身的能力都发生了巨大的变化。\n简单回顾一下注册中心的历代发展：\nV1：引进淘宝的 configserver V2：横向扩展 从这个版本开始，蚂蚁和阿里开始独立的演进，最主要的差异点是在数据存储的方向选择上。蚂蚁选择了横向扩展，数据分片存储。阿里选择了纵向扩展，加大 data 节点的内存规格。\n这个选择影响到若干年后的 SOFARegistry 和 Nacos 的存储架构。\nV3 / V4：LDC 支持和容灾 V3 支持 LDC 单元化。\nV4 增加了决策机制和运行时列表，解决了单机宕机时需要人工介入处理的问题，一定程度上提升高可用和减少运维成本。\nV5：SOFARegistry 前四个版本是 confreg，17 年启动 V5 项目 SOFARegistry，目标是：\n1.代码可维护性：confreg 代码历史包袱较重\n 少量模块使用 guice 做依赖管理，但大部分模块是静态类交互，不容易分离核心模块和扩展模块，不利于产品开源。\n 客户端与服务端的交互模型嵌套复杂，理解成本极高且对多语言不友好。\n 2.运维痛点：引入 Raft 解决 serverlist 的维护问题，整个集群的运维包括 Raft，通过 operator 来简化。\n3.鲁棒性：在一致性 hash 环增加多节点备份机制（默认 3 副本），2 副本宕机业务无感。\n4.跨集群服务发现：站内跨集群服务发现额外需要 antvip 支撑，希望可以统一 2 套设施的能力，同时商业化场景也有跨机房数据同步的需求。\n这些目标部分实现了，部分实现的还不够好，例如运维痛点还残留一部分，跨集群服务发现在面对主站的大规模数据下稳定性挑战很大。\nV6：SOFARegistry 6.0 2020 年 11 月，SOFARegistry 总结和吸收内部/商业化打磨的经验，同时为了应对未来的挑战，启动了 6.0 版本大规模重构计划。\n历时 10 个月，完成新版本的开发和升级工作，同时铺开了应用级服务发现。\nPART. 2 挑 战 当下面临的问题 集群规模的挑战 数据增长：随着业务的发展，业务的实例数在不断增长，pub/sub 的数量也相应增长。以其中一个集群为例，2019 年的数据为基准数据，在 2020 年 pub 接近千万级。 下图是该集群历年双十一时的数据对比和切换应用级的优化效果。相比 2019 年双十一，2021 年双十一接口级的 pub 增长 200%，sub 增长 80%。\n 故障爆炸半径增长：集群接入的实例越多，故障影响的业务和实例数也就越多，保障业务的稳定是最基础也是优先级最高的要求。\n 考验横向扩展能力：集群达到一定的规模后，是否还具备继续横向扩展的能力，需要集群具备良好的横向扩展能力，从 10 扩到 100 和从 100 扩到 500 是不一样的难度。\n HA 能力：集群实例数多了后，面临的节点总体的硬件故障率也相应增高，各种机器故障集群是否能快速恢复？有运维经验的同学都知道，运维一个小集群和运维一个大集群面临的困难简直是指数级增长。\n 推送性能：大多数服务发现的产品都选择了数据的最终一致性，但是这个最终在不同集群的规模下到底是多久？相关的产品其实都没有给出明确的数据。\n 但是实际上，我们认为这个指标是服务发现产品的核心指标。这个时长对调用有影响：新加的地址没有流量；删除的地址没有及时摘除等。蚂蚁集团的 PaaS 对注册中心的推送时延是有 SLO 约束的：如果变更推送列表延时超过约定值，业务端的地址列表就是错误的。我们历史上也曾发生过因推送不及时导致的故障。\n业务实例规模增加的同时也带来推送的性能压力：发布端 pub 下面的实例数增加；订阅端业务实例数增加；一个简单的估算，pub/sub 增长 2 倍，推送的数据量是 2*2，增长 4 倍，是一个乘积的关系。同时推送的性能也决定了同一时间可以支持的最大运维业务实例数，例如应急场景下，业务大规模重启。如果这个是瓶颈，就会影响故障的恢复时间。\n集群规模可以认为是最有挑战性的，核心的架构决定了它的上限，确定后改造成本非常高。而且往往等到发现瓶颈的时候已经是兵临城下了，我们要选择能拉高产品技术天花板的架构。\n运维的挑战 SOFARegistryX 立项时的一个主要目标是具备比 confreg 更好的运维能力：引入 meta 角色，通过 Raft 选举和存储元信息，提供集群的控制面能力。但是事实证明，我们还是低估了可运维的重要性，正如鲁迅先生说：【程序员的工作只有两件事情，一件是运维，另一件还是运维】。\n三年前的目标放到今天已经严重滞后了。\n 集群数增长：蚂蚁集团内部的业务是分站点部署的（简单理解为每个站点是一块相对比较独立的业务，需要不同级别的隔离），同时一个站点需要部署多套集群：容灾需要分机房部署；开发需要分多环境。部署站点的数目增长超出我们的想像。现在已经达到数百个集群了，还在迅速增长中，增长速度参考最近几年美联储的货币供应量增长速度。以前认为有些运维工作可以苟且，人肉顶一下，集群数增长后，苟且次数太多了，挤占了开发/运维同学的精力，完全没资源去规划诗和远方。 业务打扰：业务的运维是全天候 7*24 的，容量自适应/自愈/MOSN 每月一版本把全站应用犁一遍等等。下图是每分钟运维的机器批数，可以看到，就算是周末和深夜，运维任务也是不断的。 蚂蚁集团的同学对注册中心的运维公告应该是比较熟悉和痛恨的。因为业务的敏感性，注册中心之前一直是停机发布和运维，这个时候需要锁定全站的发布/重启动作。为了尽量少影响业务，注册中心相关的同学只能献祭一头黑发，在深夜低峰期做相关的操作。即使这样，仍然没办法做到对业务零打扰。\n云原生时代 naming 的挑战 云原生的技术时代下，可以观察到一些趋势：\n 微服务/FaaS 的推广导致轻型应用增多：实例数增多，需要能支撑更大的业务规模\n 应用实例的生命周期更短：FaaS 按需使用，autoscale 容量自适应等手段导致实例的涨潮退潮更频繁，注册中心的性能主要体现在实例变更的响应速度上\n 多语言支持：在过去，蚂蚁集团主要的开发体系是 Java，非 Java 语言对接基础设施都是二等公民，随着 AI 和创新性业务的需求，非 Java 体系的场景越来越多。如果按照每种语言一个 SDK，维护成本会是个噩梦，当然 sidecar（MOSN）是个解法，但是自身是否能支持低侵入性的接入方式，甚至 sdk-free 的能力？\n 服务路由：在过去绝大部分的场景都可以认为 endpoint 是平等的，注册中心只提 …","date":1637650800,"description":"降本提效！注册中心在蚂蚁集团的蜕变之路","dir":"blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","fuzzywordcount":7800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f75ce63f7162ca26342a52f74ce577ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","publishdate":"2021-11-23T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","summary":"文｜林育智（花名：源三 ) 蚂蚁集团高级专家 专注微服务/服务发现相关领域 校对｜李旭东 本文 8624 字 阅读 18 分钟 ｜引 言｜ 服务发现是构建分布式系统的最重要的","tags":["SOFAStack"],"title":"降本提效！注册中心在蚂蚁集团的蜕变之路","type":"blog","url":"/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","wordcount":7736},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@黄润良 提问：\n 有什么办法可以获取日志的这两个值吗？\n A：可以参考下图\n MOSN：https://github.com/mosn/mosn\n@爱德华 提问：\n 请教一下，SOFAJRaft 在 leader 晋升后，给每个 follower 发送的探测请求是什么？是 Raft 论文中，为了“提交上一个 term 日志项”，才发送的空请求吗？\n A：是为了探测该 follower 与 leader 的日志差异。找对 nextIndex 对吧？提交上一个 term 要通过 noop 日志。Raft 论文里有个 nextIndex，你可以看看相关内容， 日志复制那个小节。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@Bazingga 提问：\n 源码里面是怎么支持的呀，RheaKV 是使用了这个功能是吧。\n A：可以参考下这个 https://blog.csdn.net/SOFAStack/article/details/91458041\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@爱德华 提问：\n 我请教一下关于 follower 截断日志的问题。leader 拥有日志：101,102,103，它们的 term 为 2；follower 拥有日志：101,102,103,104，它们的 term 为 2；按照正常逻辑，follower 应该截断 104 的日志。根据上面的代码，在探测消息中，这种情况，follower 会返回了 success=true，并携带 lastLogIndex=104。那么 follower 是在什么时候截断 104 的呢？\n A：checkAndResolveConflict 方法。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 在服务注册时，使用枚举值替代字符串硬编码\n优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n开发 spring-boot-laytto\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 rometheus on CeresDB 演进之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1637305200,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211119/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"05f1b91614900f1434b7748905df364b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211119/","publishdate":"2021-11-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211119/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211119/","wordcount":1249},{"author":"刘家财","categories":"SOFAStack","content":" 文｜刘家财（花名：尘香 )\n蚂蚁集团高级开发工程师 专注时序存储领域\n校对｜冯家纯\n本文 7035 字 阅读 10 分钟\nCeresDB 在早期设计时的目标之一就是对接开源协议，目前系统已经支持 OpenTSDB 与 Prometheus 两种协议。Prometheus 协议相比 OpenTSDB 来说，非常灵活性，类似于时序领域的 SQL。\n随着内部使用场景的增加，查询性能、服务稳定性逐渐暴露出一些问题，这篇文章就来回顾一下 CeresDB 在改善 PromQL 查询引擎方面做的一些工作，希望能起到抛砖引玉的作用，不足之处请指出。\nPART. 1 内存控制 对于一个查询引擎来说，大部分情况下性能的瓶颈在 IO 上。为了解决 IO 问题，一般会把数据缓存在内存中，对于 CeresDB 来说，主要包括以下几部分：\n MTSDB：按数据时间维度缓存数据，相应的也是按时间范围进行淘汰\n Column Cache：按时间线维度缓存数据，当内存使用达到指定阈值时，按时间线访问的 LRU 进行淘汰\n Index Cache：按照访问频率做 LRU 淘汰\n 上面这几个部分，内存使用相对来说比较固定，影响内存波动最大的是查询的中间结果。如果控制不好，服务很容易触发 OOM 。\n中间结果的大小可以用两个维度来衡量：横向的时间线和纵向的时间线。\n控制中间结果最简单的方式是限制这两个维度的大小，在构建查询计划时直接拒绝掉，但会影响用户体验。比如在 SLO 场景中，会对指标求月的统计数据，对应的 PromQL 一般类似 sum_over_time(success_reqs[30d]) ，如果不能支持月范围查询，就需要业务层去适配。\n要解决这个问题需要先了解 CeresDB 中数据组织与查询方式，对于一条时间线中的数据，按照三十分钟一个压缩块存放。查询引擎采用了向量化的火山模型，在不同任务间 next 调用时，数据按三十分钟一个批次进行传递。\n在进行上述的 sum_over_time 函数执行时，会先把三十天的数据依次查出来，之后进行解压，再做一个求和操作，这种方式会导致内存使用量随查询区间线性增长。如果能去掉这个线性关系，那么查询数量即使翻倍，内存使用也不会受到太大影响。\n为了达到这个目的，可以针对具备累加性的函数操作，比如 sum/max/min/count 等函数实现流式计算，即每一个压缩块解压后，立即进行函数求值，中间结果用一个临时变量保存起来，在所有数据块计算完成后返回结果。采用这种方式后，之前 GB 级别的中间结果，最终可能只有几 KB。\nPART. 2 函数下推 不同于单机版本的 Prometheus ，CeresDB 是采用 share-nothing 的分布式架构，集群中有主要有三个角色：\n datanode：存储具体 metric 数据，一般会被分配若干分片(sharding)，有状态\n proxy：写入/查询路由，无状态\n meta：存储分片、租户等信息，有状态。\n 一个 PromQL 查询的大概执行流程：\n1.proxy 首先把一个 PromQL 查询语句解析成语法树，同时根据 meta 中的分片信息查出涉及到的 datanode\n2.通过 RPC 把语法树中可以下推执行的节点发送给 datanode\n3.proxy 接受所有 datanode 的返回值，执行语法树中不可下推的计算节点，最终结果返回给客户端\nsum(rate(write_duration_sum[5m])) / sum(rate(write_duration_count[5m])) 的执行示意图如下：\n为了尽可能减少 proxy 与 datanode 之间的 IO 传输，CeresDB 会尽量把语法树中的节点推到 datanode 层中，比如对于查询 sum(rate(http_requests[3m])) ，理想的效果是把 sum、rate 这两个函数都推到 datanode 中执行，这样返回给 proxy 的数据会极大减少，这与传统关系型数据库中的“下推选择”思路是一致的，即减少运算涉及的数据量。\n按照 PromQL 中涉及到的分片数，可以将下推优化分为两类：单分片下推与多分片下推。\n单分片下推 对于单分片来说，数据存在于一台机器中，所以只需把 Prometheus 中的函数在 datanode 层实现后，即可进行下推。这里重点介绍一下 subquery【1】 的下推支持，因为它的下推有别于一般函数，其他不了解其用法的读者可以参考 Subquery Support【2】。\nsubquery 和 query_range【3】 接口（也称为区间查询）类似，主要有 start/end/step 三个参数，表示查询的区间以及数据的步长。对于 instant 查询来说，其 time 参数就是 subquery 中的 end ，没有什么争议，但是对于区间查询来说，它本身也有 start/end/step 这三个参数，怎么和 subquery 中的参数对应呢？\n假设有一个步长为 10s 、查询区间为 1h 的区间查询，查询语句是\n那么对于每一步，都需要计算 3600\u0026amp;frasl;10=360 个数据点，按照一个小时的区间来算，总共会涉及到 360*360=129600 的点，但是由于 subquery 和区间查询的步长一致，所以有一部分点是可以复用的，真正涉及到的点仅为 720 个，即 2h 对应 subquery 的数据量。\n可以看到，对于步长不一致的情况，涉及到的数据会非常大，Prometheus 在 2.3.0 版本后做了个改进，当 subquery 的步长不能整除区间查询的步长时，忽略区间查询的步长，直接复用 subquery 的结果。这里举例分析一下：\n假设区间查询 start 为 t=100，step 为 3s，subquery 的区间是 20s，步长是 5s，对于区间查询，正常来说：\n1.第一步\n需要 t=80, 85, 90, 95, 100 这五个时刻的点\n2.第二步\n需要 t=83, 88, 83, 98, 103 这五个时刻的点\n可以看到每一步都需要错开的点，但是如果忽略区间查询的步长，先计算 subquery ，之后再把 subquery 的结果作为 range vector 传给上一层，区间查询的每一步看到的点都是 t=80, 85, 90, 95, 100, 105…，这样就又和步长一致的逻辑相同了。此外，这么处理后，subquery 和其他的返回 range vector 的函数没有什么区别，在下推时，只需要把它封装为一个 call （即函数）节点来处理，只不过这个 call 节点没有具体的计算，只是重新根据步长来组织数据而已。\ncall: avg_over_time step:3 └─ call: subquery step:5 └─ binary: == ├─ selector: a_gauge └─ literal: 2 在上线该优化前，带有 subquery 的查询无法下推，这样不仅耗时长，而且还会生产大量中间结果，内存波动较大；上线该功能后，不仅有利于内存控制， …","date":1637046000,"description":"Prometheus on CeresDB 演进之路","dir":"blog/prometheus-on-ceresdb-evolutionary-path/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c56a0b61329eb6462295f7bfb16ee6b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","publishdate":"2021-11-16T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","summary":"文｜刘家财（花名：尘香 ) 蚂蚁集团高级开发工程师 专注时序存储领域 校对｜冯家纯 本文 7035 字 阅读 10 分钟 CeresDB 在早期设计时的目标之一就是对接开源协议，目前系","tags":["SOFAStack"],"title":"Prometheus on CeresDB 演进之路","type":"blog","url":"/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","wordcount":4807},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@zjw 提问：\n 请教个 SOFARegistry 的问题，sessionServer 启动后，地址是上报给 Meta 的吗？如果 sessionServer 意外关闭，地址是什么时候怎么摘除的？\n A：session 会定时向 Meta 发送请求对自己的地址进行心跳续约，session 宕机后，Meta 端一段时间接收不到心跳就会摘除宕机的 session，然后广播给所有其他的 session。目前是靠心跳，超时之后 Meta 会把 session 或者 data 剔除。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@滕川 提问：\n 如果 leader 节点挂了，新选举的 leader 节点如何知道各个 follower 节点的 match index。\n A：leader 不需要知道，leader 节点就直接发 appendEtries 即可。如果哪个 follower 还缺更之前的 log，那么它拒绝掉这次 appendEntries 就可以了， leader 会有相应的回退处理逻辑。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@橙橙不是澄澄 提问：\n Raft 里面为什么不要 observer 呢？恰好之前看到 ZooKeeper 里面有这个角色。\n A：Raft 里面可以有类似的角色，叫 learner。learner 不参与选举，只接收 leader 日志，JRaft 也支持 learner。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@邓君武 提问：\n SOFAJRaft 文档中说支持 MULTI-RAFT-GROUP，目前 SOFAJRaft-RheaKV 这个存储组件中用到了。那么如果我想根据 SOFAJRaft 实现一个分布式的业务系统，MULTI-RAFT-GROUP 该怎么用呢？\n A：MULTI-RAFT-GROUP 主要用于解决 SIGLE-RAFT-GROUP 单点瓶颈问题（存储或是吞吐），多个 group 中每个 group 都有一个 leader，可以把 leader 打散到不同的机器上，提高并发度。JRaft 天然支持 MULTI-RAFT-GROUP ，使用的话可以参考 RheaKV。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 在服务引用和发布时，使用枚举值替代字符串硬编码\n优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n升级由 Rust 开发的 Wasm demo\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n 蚂蚁集团技术风险代码化平台实践（MaaS）\n ","date":1636700400,"description":"SOFA WEEKLY | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211112/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"801d338b492a06363ed6a129c2da9774","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211112/","publishdate":"2021-11-12T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211112/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211112/","wordcount":1544},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft\n 活动时间：11月10日,周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft SOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 冯家纯 蚂蚁集团高级技术专家。 蚂蚁集团-智能监控-技术中台（存储）团队技术负责人，团队负责时序数据库相关。 分布式服务框架 Jupiter 作者。 基于 Raft 的分布式共识算法库 SOFAJRaft 开源负责人、核心开发者。 议程 18:50-19:00 主持人开场 小助手-泡椒 主持人\n19:00-19:30 分布式共识：Raft 与 SOFAJRaft 冯家纯，蚂蚁集团高级技术专家\n你将收获 对 Raft 共识算法有所了解，还可以了解到 SOFAJRaft 基于 Raft 算法做了哪些优化，以及实现 Raft 算法的一些好的实践经验。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1636527600,"description":"11 月 10 日周三晚 19 点，线上直播第 22 期。","dir":"activities/sofa-channel-22/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"896e421f2df319f46ec573a77343446c","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-22/","publishdate":"2021-11-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-22/","summary":"概要 活动主题：SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft 活动时间：11月10日,周三晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站","tags":["SOFAChannel","HTTP/3"],"title":"SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft","type":"activities","url":"/sofastack.tech/activities/sofa-channel-22/","wordcount":643},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@玄灭 提问：\n 大佬，关于 downStream 和 upStream，你看看我这个理解对不对哈？一个 MOSN 进程，既会代理当前 pod 的业务进程流量请求，此时 downStream 是当前 pod 进程；同时，这个 MOSN 进程也会代理其他 pod 请求当前 pod 的流量，此时当前 pod 就不能成为 downStream；也就是说，角色会互换。从另一个角度，从 server 端口进来的，都是 downStream，使用 client 向外其他进程发送数据，都是 upStream。 A：一般来说，downStream 就是 server listen 请求，upStream 是 client，发送请求。你说的第一种，一般用 Ingress、Egress 来区分。\n 在 MOSN 里，downStream 永远是 side 进程吗？\n A：MOSN 里面，downStream 就是 server 端，接收请求的。\n MOSN 两个端口的话，server 端可能是 side 进程，也可能是其他 MOSN 进程。所以 downStream 可以是 side 进程的请求，也可以是其他 MOSN 进程的请求。\n A：站在 MOSN 角度，给我发请求的就是 downStream。\n「MOSN」：https://github.com/mosn/mosn\n@zzzZ 提问：\n 怎么将实现的 Eventhandler 注册进容器中，监听容器启动和停止事件？\n A：这里有具体讲解，https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/\n 事件能传播吗？比如 master 传播给子模块内。 A：容器级别的会传播。\n 「SOFABoot」：https://github.com/sofastack/sofa-boot\n@苏千 提问：\n 如何让 Layotto 打印日志，将 metadata 打印出来，我传递了没有生效，想看看是否传递错误。\n A：Layotto 现在默认 log 就是打印的，但没打印 metadata 里面的值，现在 oss 的实现就没传 prefix，所以不生效吧。\n可以试一下这个方法，如果这样的话，你 SDK 测需要适配一下。https://github.com/mosn/layotto/issues/98#issuecomment-957479097\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n升级由 Rust 开发的 Wasm demo\n Hard 集成 Skywalking、Jaeger 等系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 如何在生产环境排查 Rust 内存占用过高问题\n 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1636095600,"description":"SOFA Weekly |Layotto 本周 Contributor、QA 整理、新手任务","dir":"blog/sofa-weekly-20211105/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f2607e9479571a83a8453798866de8f9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211105/","publishdate":"2021-11-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211105/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly |Layotto 本周 Contributor、QA 整理、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211105/","wordcount":1382},{"author":"魏熙凯","categories":"SOFAStack","content":" 📄\n文｜魏熙凯（蚂蚁集团技术专家）\n本文 6320 字 阅读 10 分钟\n▼\n内存安全的 Rust，虽然基本不会出现内存泄漏，但如何合理分配内存，是每个复杂应用都要面临的问题。往往随着业务的不同，相同的代码可能会产生不同的内存占用。因此，有不小的概率会出现内存使用过多、内存逐渐增长不释放的问题。\n本文我想分享一下，我们在实践过程中遇到的关于内存占用过高的问题。对于这些内存问题，在本文中会做出简单的分类，以及提供我们在生产环境下进行排查定位的方法给大家参考。\n 本文最先发表于 RustMagazine 中文月刊\n(https://rustmagazine.github.io/rust_magazine_2021/chapter_5/rust-memory-troubleshootting.html）\n 内存分配器 首先在生产环境中，我们往往不会选择默认的内存分配器（malloc），而是会选择 jemalloc，可以提供更好的多核性能以及更好的避免内存碎片（详细原因可以参考[1]）。Rust 的生态中，对于 jemalloc 的封装有很多优秀的库，这里我们就不纠结于哪一个库更好，我们更关心如何使用 jemalloc 提供的分析能力，帮助我们诊断内存问题。\n阅读 jemalloc 的使用文档，可以知道其提供了基于采样方式的内存 profile 能力，而且可以通过 mallctl 可以设置 prof.active 和 prof.dump 这两个选项，来达到动态控制内存 profile 的开关和输出内存 profile 信息的效果。\n内存快速增长直至 oom 这样的情况一般是相同的代码在面对不同的业务场景时会出现，因为某种特定的输入（往往是大量的数据）引起程序的内存快速增长。\n不过有了上面提到的 memory profiling 功能，快速的内存增长其实一个非常容易解决的情况，为我们可以在快速增长的过程中打开 profile 开关，一段时间后，输出 profile 结果，通过相应的工具进行可视化，就可以清楚地了解到哪些函数被调用，进行了哪些结构的内存分配。\n不过这里分为两种情况：可以复现以及难以复现，对于两种情况的处理手段是不一样的，下面对于这两种情况分别给出可操作的方案。\n**可以复现\n可以复现的场景其实是最容易的解决的问题，因为我们可以在复现期间采用动态打开 profile，在短时间内的获得大量的内存分配信息即可。\n下面给出一个完整的 demo，展示一下在 Rust 应用中如何进行动态的内存 profile。\n本文章，我会采用jemalloc-sys jemallocator jemalloc-ctl 这三个 Rust 库来进行内存的 profile，这三个库的功能主要是：\n```jemallocator```: 实现了 Rust 的 ```GlobalAlloc```，用来替换默认的内存分配器。 ```jemalloc-ctl```: 提供了对于 mallctl 的封装，可以用来进行 tuning、动态配置分配器的配置、以及获取分配器的统计信息等。 下面是 demo 工程的依赖： ``` java [dependencies] jemallocator = \u0026amp;quot;0.3.2\u0026amp;quot; jemalloc-ctl = \u0026amp;quot;0.3.2\u0026amp;quot; [dependencies.jemalloc-sys] version = \u0026amp;quot;0.3.2\u0026amp;quot; features = [\u0026amp;quot;stats\u0026amp;quot;, \u0026amp;quot;profiling\u0026amp;quot;, \u0026amp;quot;unprefixed_malloc_on_supported_platforms\u0026amp;quot;] [profile.release] debug = true 其中比较关键的是jemalloc-sys 的几个 features 需要打开，否则后续的 profile 会遇到失败的情况，另外需要强调的是 demo 的运行环境是在 Linux 环境下运行的。\n然后 demo 的 src/main.rs 的代码如下：\nuse jemallocator; use jemalloc_ctl::{AsName, Access}; use std::collections::HashMap; #[global_allocator] static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc; const PROF_ACTIVE: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;prof.active\\0\u0026amp;quot;; const PROF_DUMP: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;prof.dump\\0\u0026amp;quot;; const PROFILE_OUTPUT: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;profile.out\\0\u0026amp;quot;; fn set_prof_active(active: bool) { let name = PROF_ACTIVE.name(); name.write(active).expect(\u0026amp;quot;Should succeed to set prof\u0026amp;quot;); } fn dump_profile() { let name = PROF_DUMP.name(); name.write(PROFILE_OUTPUT).expect(\u0026amp;quot;Should succeed to dump profile\u0026amp;quot;) } fn main() { set_prof_active(true); let mut buffers: Vec\u0026amp;lt;HashMap\u0026amp;lt;i32, i32\u0026amp;gt;\u0026amp;gt; = Vec::new(); for _ in 0..100 { buffers.push(HashMap::with_capacity(1024)); } set_prof_active(false); dump_profile(); } demo 已经是非常简化的测试用例了，主要做如下的说明：\n编译完成之后，直接运行程序是不行的，需要设置好环境变量（开启内存 profile 功能）： export MALLOC_CONF=prof:true 然后再运行程序，就会输出一份 memory profile 文件，demo 中文件名字已经写死 —— ```profile.out```，这个是一份文本文件，不利于直接观察（没有直观的 symbol）。 通过 jeprof 等工具，可以直接将其转化成可视化的图形： ```jeprof --show_bytes --pdf \u0026amp;lt;path_to_binary\u0026amp;gt; ./profile.out \u0026amp;gt; ./profile.pdf``` 这样就可以将其可视化，从下图中，我们可以清晰地看到所有的内存来源： …","date":1635836400,"description":"如何在生产环境排查 Rust 内存占用过高问题","dir":"blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a2811b69df2016f531d4d42a431a7683","permalink":"https://sofastack.github.io/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","publishdate":"2021-11-02T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","summary":"📄 文｜魏熙凯（蚂蚁集团技术专家） 本文 6320 字 阅读 10 分钟 ▼ 内存安全的 Rust，虽然基本不会出现内存泄漏，但如何合理分配内存，是每个复杂应用都要面临","tags":["SOFAStack"],"title":"如何在生产环境排查 Rust 内存占用过高问题","type":"blog","url":"/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","wordcount":3930},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@崔伟协 提问：\n PingPong 是类似 HTTP 的 req/resp 吗? Multiplex 是类似 HTTP2.0 的没有队头阻塞吗？ A：是的。\n 自己实现的 xprotocol 自定义子协议，要怎么配置 downstream 是 PingPong 还是 Multiplex 呢，PoolMode() api.PoolMode 这个方法似乎只影响 upstream 的 conn pool?\n A：downstream 不用感知，这个访问你的 client 就决定他的行为。\n「MOSN」：https://github.com/mosn/mosn\n2.@玄灭 提问：\n 请教下 MOSN 可以同时支持多个协议吗？比如同时支持 HTTP1.1、rocketmq 协议。\n A：可以的，一个端口都可以。协议可以做自动识别，协议配置就可以配置 Auto。\n「MOSN」：https://github.com/mosn/mosn\n3.@玄灭 提问：\n 业务层的 SDK 用的什么协议呢？比如 mq 用的是私有协议，还是和 RPC 统一是一个协议啊？\n A：我们两种模式，一种是私有协议，一种是统一协议都有再用，统一协议是用 Layotto 支持的。\n 你们的大方向是统一协议，还是私有协议啊？我理解的私有协议对于上游改造成本，会比较小吧；统一协议的话，成本比较大。\n A：私有协议你认为是 Mesh 了，现有业务的支持；统一协议就是类似 Dapr 这种，新业务使用不同场景。\n「MOSN」：https://github.com/mosn/mosn\n4.@晓辰 提问：\n 请问一下 MOSN 有支持 windows 的计划吗？\n A：Go 语言跨平台应该支持的，你提个 pr 看看，是不是有些 Linux 需要跳过？\n「MOSN」：https://github.com/mosn/mosn\n5.@王磊 提问：\n MOSN 目前支持的 Istio 版本是 1.5.2 吗？更高的 Istio 版本支持有计划吗？\n A：这个分支，近期会合到 Master。\nhttps://github.com/mosn/mosn/tree/istio-1.10\n「MOSN」：https://github.com/mosn/mosn\n6.@孙力 提问：\n MOSN 有剔除上游故障节点的功能吗? 比如上游服务有 5 台服务器，访问其中一台总报错，下次就不选这台了。\n https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ffaulttolerance\n 这个 stream_filter 应该是只要上游 host 返回的状态码代表异常就会统计，达到一定比例就会 healthFlag 置为 false。但我们其实想做接口 + host 的，比如访问上游的某个 HTTP 接口总失败，只是针对下次访问这个接口时，才剔除节点，这样是不是需要自己定制一下 InvocationKey ？\n A：还是有区别的，这个是把 host 置为失败了，是全局的，其他接口也会失败。删除了之后，其他访问这个接口请求也不会访问这个 host 了。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n用某种存储实现 File API 组件（例如本地文件系统、hdfs、ftp 等）\n升级由 rust 开发的 wasm demo\nSOFARPC 本周发布 本周 SOFARPC 发布 v5.8.0 版本代码。\n主要更新如下：\n RpcInvokeContext 中增加调用时精细化耗时埋点信息\n Java 集合的使用优化\n 修复 RouterChain 加入不存在的 Router 时 NPE 问题\n 增加泛型修复配置类中类型传递问题\n bolt 版本从 1.5.6 升级到 1.5.9\n hessian 版本从 3.3.7 升级到 3.3.13\n nacos 版本从 1.0.0 升级到 2.0.3\n httpclient 版本从 4.5.11 升级到 4.5.13\n commons-io 版本从 2.4 升级到 2.7\n 「详细参考」：https://github.com/sofastack/sofa-rpc/releases/tag/v5.8.0\n本周推荐阅读 蚂蚁集团技术风险代码化平台实践（MaaS）\n 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1635490800,"description":"SOFA WEEKLY |Layotto 本周 Contributor、QA 整理、 SOFARPC 本周发布","dir":"blog/sofa-weekly-20211029/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dc10182aab6b4170339c958ac73dd2bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211029/","publishdate":"2021-10-29T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211029/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、 SOFARPC 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211029/","wordcount":1667},{"author":"黄章衡","categories":"SOFAStack","content":" 📄\n文｜黄章衡（SOFAJRaft 项目组）\n福州大学 19 级计算机系\n研究方向｜分布式中间件、分布式数据库\nGithub 主页｜https://github.com/hzh0425\n校对｜冯家纯（SOFAJRaft 开源社区负责人）\n本文 9402 字 阅读 18 分钟\n▼\nPART. 1 项目介绍 1.1 SOFAJRaft 介绍 SOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\nGithub 地址：\nhttps://github.com/sofastack/sofa-jraft\n1.2 任务要求 目标：当前 LogStorage 的实现，采用 index 与 data 分离的设计，我们将 key 和 value 的 offset 作为索引写入 rocksdb，同时日志条目（data）写入 Segment Log。因为使用 SOFAJRaft 的用户经常也使用了不同版本的 rocksdb，这就要求用户不得不更换自己的 rocksdb 版本来适应 SOFAJRaft， 所以我们希望做一个改进：移除对 rocksdb 的依赖，构建出一个纯 Java 实现的索引模块。\nPART. 2 前置知识 Log Structured File Systems\n如果学习过类似 Kafka 等消息队列的同学，对日志型系统应该并不陌生。\n如图所示，我们可以在单机磁盘上存储一些日志型文件，这些文件中一般包含了旧文件和新文件的集合。区别在于 Active Data File 一般是映射到内存中的并且正在写入的新文件(基于 mmap 内存映射技术)，而 Older Data File 是已经写完了，并且都 Flush 到磁盘上的旧文件，当一块 Active File 写完之后，就会将其关闭，并打开一个新的 Active File 继续写。\n并且每一次的写入，每个 Log Entry 都会被 Append 到 Active File 的尾部，而 Active File 往往会用 mmap 内存映射技术，将文件映射到 os Page Cache 里，因此每一次的写入都是内存顺序写，性能非常高。\n终上所述，一块 File 无非就是一些 Log Entry 的集合，如图所示:\n同时，仅仅将日志写入到 File 中还不够，因为当需要搜索日志的时候，我们不可能顺序遍历每一块文件去搜索，这样性能就太差了。所以我们还需要构建这些文件的 “目录”，也即索引文件。这里的索引本质上也是一些文件的集合，其存储的索引项一般是固定大小的，并提供了 LogEntry 的元信息，如:\n- File_Id : 其对应的 LogEntry 存储在哪一块 File 中\n- Value_sz : LogEntry 的数据大小\n(注: LogEntry 是被序列化后, 以二进制的方式存储的)\n- Value_pos: 存储在对应 File 中的哪个位置开始\n- 其他的可能还有 crc，时间戳等\u0026amp;hellip;\u0026amp;hellip;\n那么依据索引文件的特性，就能够非常方便的查找 IndexEntry。\n- 日志项 IndexEntry 是固定大小的\n- IndexEntry 存储了 LogEntry 的元信息\n- IndexEntry 具有单调递增的特性\n举例，如果要查找 LogIndex = 4 的日志:\n- 第一步，根据 LogIndex = 4，可以知道索引存储的位置：IndexPos = IndexEntrySize * 4\n- 第二步，根据 IndexPos，去索引文件中，取出对应的索引项 IndexEntry\n- 第三步，根据 IndexEntry 中的元信息，如 File_Id、Pos 等，到对应的 Data File 中搜索\n- 第四步，找到对应的 LogEntry\n内存映射技术 mmap\n上文一直提到了一个技术：将文件映射到内存中，在内存中写 Active 文件，这也是日志型系统的一个关键技术，在 Unix/Linux 系统下读写文件，一般有两种方式。\n传统文件 IO 模型\n一种标准的 IO 流程, 是 Open 一个文件，然后使用 Read 系统调用读取文件的一部分或全部。这个 Read 过程是这样的：内核将文件中的数据从磁盘区域读取到内核页高速缓冲区，再从内核的高速缓冲区读取到用户进程的地址空间。这里就涉及到了数据的两次拷贝：磁盘-\u0026amp;gt;内核，内核-\u0026amp;gt;用户态。\n而且当存在多个进程同时读取同一个文件时，每一个进程中的地址空间都会保存一份副本，这样肯定不是最优方式的，造成了物理内存的浪费，看下图：\n内存映射技术\n第二种方式就是使用内存映射的方式\n具体操作方式是：Open 一个文件，然后调用 mmap 系统调用，将文件内容的全部或一部分直接映射到进程的地址空间(直接将用户进程私有地址空间中的一块区域与文件对象建立映射关系)，映射完成后，进程可以像访问普通内存一样做其他的操作，比如 memcpy 等等。mmap 并不会预先分配物理地址空间，它只是占有进程的虚拟地址空间。\n当第一个进程访问内核中的缓冲区时，因为并没有实际拷贝数据，这时 MMU 在地址映射表中是无法找到与地址空间相对应的物理地址的，也就是 MMU 失败，就会触发缺页中断。内核将文件的这一页数据读入到内核高速缓冲区中，并更新进程的页表，使页表指向内核缓冲中 Page Cache 的这一页。之后有其他的进程再次访问这一页的时候，该页已经在内存中了，内核只需要将进程的页表登记并且指向内核的页高速缓冲区即可，如下图所示：\n对于容量较大的文件来说（文件大小一般需要限制在 1.5~2G 以下），采用 mmap 的方式其读/写的效率和性能都非常高。\n当然，需要如果采用了 mmap 内存映射，此时调用 Write 并不是写入磁盘，而是写入 Page Cache 里。因此，如果想让写入的数据保存到硬盘上，我们还需要考虑在什么时间点 Flush 最合适(后文会讲述)。\nPART. 3 架构设计 3.1 SOFAJRaft 原有日志系统架构 下图是 SOFAJRaft 原有日志系统整体上的设计：\n其中 LogManager 提供了和日志相关的接口，如:\n/** * Append log entry vector and wait until it\u0026#39;s stable (NOT COMMITTED!) * * @param entries log entries * @param done callback */ void appendEntries(final Listentries, StableClosure done); /** * Get the log entry at index. * * @param index the index of log entry * @return the …","date":1635231600,"description":"新一代日志型系统在 SOFAJRaft 中的应用","dir":"blog/a-new-generation-of-log-based-systems-in-sofajraft/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0d3a13e7ed41a72bee7fe7973424e4e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","publishdate":"2021-10-26T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","summary":"📄 文｜黄章衡（SOFAJRaft 项目组） 福州大学 19 级计算机系 研究方向｜分布式中间件、分布式数据库 Github 主页｜https://github.com","tags":["SOFAStack"],"title":"新一代日志型系统在 SOFAJRaft 中的应用","type":"blog","url":"/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","wordcount":5282},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）\n 活动时间：2021 年 10 月 23 日（周六）13:30-17:30\n 活动地点：上海市浦东新区南泉北路 447 号蚂蚁 S 空间 1210 明月台\n 活动形式：线下活动\n 资料下载： 《攀登规模化的高峰蚂蚁集团大规模 Sigma 集 ApiServer 优化实践》\n 活动回顾 《攀登规模化的高峰蚂蚁集团大规模 Sigma 集 ApiServer 优化实践》\n嘉宾介绍\n唐博：蚂蚁集团技术专家，目前主要致力于 Kubernetes 性能和规模化方向，在资源编排调度，以及机器学习平台等领域有所涉猎，是 Kubernetes/istio/volcano 等云原生相关项目的代码贡献者。\n谭崇康：蚂蚁集团高级技术专家，负责大规模 K8s 集群设计、集群性能及 Pod 交付成功率及吞吐保障。长期从事云平台领域的新架构研发工作，研究兴趣包括 Kubernetes 领域的最新技术、操作系统、大数据、AIOps 等。\n议题简介\n 蚂蚁集团运行着全球最大的 Kubernetes（内部称为 Sigma） 集群之一，本次分享将介绍蚂蚁集团构建万级节点的大规模 Kubernetes 集群以及优化 Kubernetes apiserver 的过程当中的挑战和解决方案. 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1634972400,"description":"【活动回顾】SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）","dir":"activities/sofa-meetup-12/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"590a0e1f5b8a6a4035844058f4361490","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-12/","publishdate":"2021-10-23T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-12/","summary":"概要 活动主题：SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day） 活动时间：2021 年 10 月 23 日（周六）13:30-17:30 活","tags":["SOFAMeetup"],"title":"【活动回顾】SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-12/","wordcount":479},{"author":"赵陈","categories":"SOFAStack","content":" 📄\n文｜赵陈（SOFA 开源之夏链路项目组)\n武汉理工大学计算机工程硕士在读\n研究方向：唐卡线稿的自动上色\n校对｜宋国磊（SOFATracer commiter)\n本文 6971 字 阅读 18 分钟\n▼\n背 景 有幸参与开源软件供应链点亮计划——暑期 2021 支持的开源项目，目前 SOFATracer 已经能够将埋点数据上报到 Zipkin 中，本项目的主要目标是将产生的埋点数据上报给 Jaeger 和 SkyWalking 中进行可视化展示。\nPART. 1 SOFATracer SOFATracer 是蚂蚁集团基于 OpenTracing 规范开发的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer 提供了异步落地磁盘的日志打印能力和将链路跟踪数据上报到开源产品 Zipkin 做分布式链路跟踪展示的能力。这次参加开源之夏活动的任务是要把链路跟踪数据上报到 Jaeger 和 SkyWalking 中进行展示。\nSOFATracer 数据上报 上图是 SOFATracer 中的链路上报流程，Span#finish 是 span 生命周期的最后一个执行方法，这是整个数据上报的入口，SOFATracer 的 report span 方法中含有上报链路展示端和日志落盘两个部分。SOFATracer 中没有把上报数据采集器和日志落盘分开只是在日志落盘之前调用 SOFATracer#invokeReporListeners 方法，找到系统中所有实现了 SpanReportListener 接口并加入了 SpanReportListenersHolder 的实例，调用其 onSpanReport 方法完成链路数据上报至数据采集器。下面的代码片段是 invokeReportListeners 方法的具体实现。\nprotected void invokeReportListeners(SofaTracerSpan sofaTracerSpan) { List\u0026amp;lt;SpanReportListener\u0026amp;gt; listeners = SpanReportListenerHolder .getSpanReportListenersHolder(); if (listeners != null \u0026amp;amp;\u0026amp;amp; listeners.size() \u0026amp;gt; 0) { for (SpanReportListener listener : listeners) { listener.onSpanReport(sofaTracerSpan); } } } SpanReportListenerHolder 中的实例在项目启动的时候加入，且分为 Spring Boot 应用和 Spring 应用两种情况：\n 在 Spring Boot 应用中自动配置类 SOFATracerSpanRemoteReporter 会将当前所有 SpanReportListener 类型的 bean 实例保存到 SpanReportListenerHolder 的 List 对象中。SpanReportListener 的实例对象会在各自的 AutoConfiguration 自动配置类中注入到 IOC 容器中。\n 在 Spring 应用中通过实现 Spring 提供的 bean 生命周期接口 InitializingBean，在 afterPropertiesSet 方法中实例化 SpanReportListener 的实例对象并且加入到 SpanReportListenerHolder 中。\n 要实现把 SOFATracer 中的 trace 数据上传到 Jaeger 和 SkyWalking 需要实现 SpanReportListener 接口并在应用启动的时候把对应实例加入到 SpanReportListenersHolder 中。\nPART. 2 Jaeger 数据上报 下图是 Jaeger 中数据上报的部分图示，图中 CommandQueue 中存放的是刷新或添加指令，生产者是采样器和 flush 定时器，消费者是队列处理器。采样器判断一个 span 需要上报后向 CommandQueue 中添加一个 AppendCommand，flush 定时器根据设置的 flushInterval 不断向队列中添加 FlushCommand，队列处理器不断从 CommandQueue 中读取指令判断是 AppendCommand 还是 FlushCommand，如果刷新指令把当前 byteBuffer 中的数据发送到接受端，如果是添加指令把这个 span 添加到 byteBuffer 中暂存。\n在实现上报到 Jaeger 过程中主要工作是 Jaeger Span 和 SOFATracer Span 模型的转换，转换过后利用上面的逻辑发送 span 到后端。\n上图是 Jaeger 中 Sender 的 UML 图，从图中可以看到有两种类型的 Sender 分别是 HTTPSender 和 UDPSender 。分别对应用 HTTP 发送数据和 UDP 发送数据，在实现 SOFATracer 上报 Jaeger 中使用 UDPSender 发送 span 数据到 Jaeger Agent 中，使用 HTTPSender 直接发送数据到 Jaeger-Collector 中。\nJaeger Span 与 SOFATracer Span 模型的转换 模型转换对照 TraceId 和 SpanId 的处理 TraceId 的转换：\n 问题在 SOFATracer 中的 TracerId 的产生规则是：服务器 IP + ID 产生的时间 + 自增序列 + 当前进程号 例如 ：0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，您也可以根据这个规律来查找到请求经过的第一个服务器。后面的 13 位 1403169275002 是产生 TraceId 的时间。之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。——TraceId 和 SpanId 生成规则\n 在 SOFATracer 中 TraceId 是 String 类型，但是在 Jaeger 中 TraceId 是使用的两个 Long 型的整数来构成最终的 TraceId。\n解决方案 在 Jaeger …","date":1634626800,"description":"终于！SOFATracer 完成了它的链路可视化之旅","dir":"blog/sofatracer-completes-its-link-visualisation-journey/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"260c9a0bc64d5f84afc37ee442e347c6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","publishdate":"2021-10-19T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","summary":"📄 文｜赵陈（SOFA 开源之夏链路项目组) 武汉理工大学计算机工程硕士在读 研究方向：唐卡线稿的自动上色 校对｜宋国磊（SOFATracer commiter) 本文 6971","tags":["SOFAStack"],"title":"终于！SOFATracer 完成了它的链路可视化之旅","type":"blog","url":"/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","wordcount":4273},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@崔伟协 提问：\n 我们的项目基于 MOSN，请问这里 panic了，要怎么解决？\n https://github.com/mosn/mosn/blob/master/pkg/proxy/downstream.go#L393-L399\nA：有异常的时候可以直接返回一个异常的数据包，m.receiveHandler.SendHijackReply(api.SuccessCode, m.headers) 在 filter 里面可以直接返回一个包。\n「MOSN」：https://github.com/mosn/mosn\n@玄灭 提问：\n 请问 MOSN 有计划支持 eureka 注册中心吗？\n A：目前没有，欢迎 pr，有个 zk 的例子，实现起来也简单。\nhttps://www.github.com/mosn/mosn/tree/master/pkg%2Fupstream%2Fservicediscovery%2Fdubbod\n「MOSN」：https://github.com/mosn/mosn\n@张昊 提问：\n 仓库中 /jarslink-samples/spring-boot-transform-sample 对照文档启动后，telnet 中 install -b *ark-biz.jar，控制台报错，大家有遇到类似问题嘛？\n A：这个项目不维护了，相关功能已经 merge 到 SOFAArk 里面去了，以后建议直接用 SOFAArk。\nSOFAArk 有相关的适应样例：https://github.com/sofastack-guides\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n@春少 提问：\n 这一段逻辑，是为了避免在执行 add peer 的时候，出现 raft 选举的情况吗？ A：是的，所以这个时候就交给新的 leader 负责继续推进新的成员节点变更。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN : 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n-Easy\n为 Layotto 中的关键模块添加注释（例如限流/分布式锁等模块）\n添加 nodejs sdk\n-Medium\n用某种存储实现 File API 组件（例如本地文件系统、hdfs、ftp 等）\n升级由 rust 开发的 wasm demo\n升级由 AssemblyScript 开发的 wasm demo\n详见： https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n另外最近更新了社区晋升规则，大家贡献 pr 后只要满足条件即可晋升，成为社区的维护者之一。\n详见： https://mosn.io/layotto/#/zh/community/promote\n本周推荐阅读 蚂蚁集团技术风险代码化平台实践（MaaS）\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1634281200,"description":"SOFA Weekly | QA 整理、SOFAStack\u0026MOSN 新手任务","dir":"blog/sofa-weekly-20211015/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"498a7a535dc938be0783eab5c808d792","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211015/","publishdate":"2021-10-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211015/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly | QA 整理、SOFAStack\u0026MOSN 新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211015/","wordcount":1130},{"author":"吴成辉","categories":"SOFAStack","content":" 📄\n文｜吴成辉（花名：清霄 蚂蚁集团高级技术专家)\n校对｜陈真、庄晓丹、冯家纯\n本文 6250 字 阅读 11 分钟\n▼\n我们一起回顾下监控上层业务曾经面临的问题：\n 烟囱式的监控分析重复建设 在技术风险领域，一度有超过 5 个系统在做监控分析的能力建设，大致逻辑基本都是拉监控的 Raw Data，做基础的聚合、分析处理后（类似同环比、阈值类的方式），根据一些当前的场景输入，结合一些算法能力，得出一个结论并触发一系列的 Action。类似这种烟囱式的监控分析场景，都是比较初级的重复建设，缺乏智能化、体系化。\n SRE 经验标准化沉淀的问题 在分析场景里也面临 SRE 经验无法标准化沉淀复用的问题，什么是 SRE 经验？拿交易付款下跌来举例，如果当前交易付款下跌 10%，SRE 通常有这么几个分析路径，首先看下淘宝交易是否下跌（来源），再看交易创建，收银台渲染是不是下跌等，这一类我们称为业务依赖。从全局看是否有大规模的压测、变更等动作，这一类称为变更关联，以及如何根据当前故障情况决策进行切流、限流等恢复措施，我们称为分析后置操作。\n 长尾需求 比如比较常见的，算多数据之间的成功率，流量损耗等等需求，通过产品化解决的成本非常高，而且用户不能快速修改、定制相关能力。\n同时我们看到当前监控系统自身面临的问题：\n 监控的数据使用复杂 包含了几万张数据表、十几万张自定义数据表，数据类型超过 20+，以及跨站点、数据源异构等等问题。\n 监控服务不够开放 如何动态日志清洗计算、如何做分析后的时序存储、监控的时序检测能力如何复用等等。我们需要把监控的数据、能力完全服务化出来。\n 高效的可编程代码化平台缺失 没有一个高效平台帮助 SRE 先沉淀经验、再促进经验的标准化、复用，最后产品化。\n基于上面问题，我们提出了 MaaS 的设想（Monitoring as a Service), 监控能力服务化，开放、融合监控能力到技术风险各个领域，快速完成 SRE 场景建设，沉淀可复用能力，主要包含以下 4 个阶段目标：\n1.开放服务把监控的计算、存储、算法、视图等等能力开放出来。\n2.核心共建几个重点的技术风险领域场景，比如变更防御、压测引流、无损注入、定位应急等等。\n3.促进服务的标准化沉淀，让更多的场景可以复用、共同建设这部分的能力。\n4.解决“监”与“控”之间的链接问题。\n（我们的这里的 AIOPS 更多指的是\n一系列专家经验的集合、沉淀、持续维护优化）\nPART. 1 平台技术概览 能力服务化\n监控的服务化能力整体包含这么几部分，数据服务化、配置服务化、计算、存储服务化、算法服务化、通知、云原生服务化等等，也包括一些外部能力集成比如消息缓存等等。\n我简单举两个服务化的例子来介绍下什么是服务化：\n比如视图服务，当某个变更发起后，这个变更关联的 100 个应用指标、20 个业务指标中的 10 个指标出现了问题，这个时候，我们需要动态为这个 10 个指标创建一个数据视图，来分析业务影响范围，这个时候就会用到我们的视图服务。\n动态计算服务，比如我需要实时计算下某个应用在 A 机房（或某个 ZONE 如：GZXXX）的其中 5 台机器在 11:00~12:00 的接口方法调用情况，动态的计算服务就会派得上用场。\n数据服务化\n能力服务化中非常重要的一环就是数据服务化，因为数据是所有监控分析的基础，数据服务化主要分成两部分。\n 第一步是监控数据模型化 我们从数据的使用视角把数据抽象出数据虚拟表、虚拟表列定义、列关系。以及虚拟表的实现绑定，包含指标数据，也包含关系元数据，最后把这些物理实现映射到监控具体的数据指标或者底层的元数据服务上。\n 第二步是服务模板化 我们把一个数据服务抽象出三类：\n实体查询，比如查询一个应用或者一个 Tbase 的集群；\n数据查询，比如查询一个应用的 Sofa Service 在 APP 聚合维度上的数据；\n关系查询，查询一个实体的关联实体，比如 cif 关联的 Tbase 集群等。\n 最后，我们实现了 5w+ 数据服务自动生成，分钟级别 SDK 更新的能力，我们可以通过非常语义化的访问方式来访问监控的所有数据，我们可以做到只要是监控体系内的数据，都可以通过我们这套能力访问到对应的数据服务，从而达到整个监控数据的服务化开放。 研发效能\n 大库管理，我们设计了一种可以支持服务沉淀、权限隔离（可以独立按目录管理 CR）、逻辑复用的代码结构，比如缓存 Tbase 的研发 + SRE 可以共同在 cache 目录里面定义缓存问题的发现、分析、恢复。同时可以复用到 core-service 里面的比如容器是否健康，网络是否异常等标准服务。平台能够提供一致的多环境调试能力，方便监控分析逻辑可以直接运行在本地 IDE 环境中，我们通过动态代理的模式把本地访问的数据、函数服务代理到服务端，从而达到了本地跟线上完全一致的研发体验。这项能力极大地提高了研发效率，研发过程中可以直接 debug 线上数据，比传统的日志模式的调试方式有非常大的效率提升，一个基础的分析函数基本可以在小时级别内完成。\n 一站式发布运维，传统的 Serverless 发布模式大致要经历这么几个阶段，从工程打包到 Jar 文件，耗时 1min，大概在 100-300MB，从 Jar 文件打包 Build 出镜像，大致 10min，最后做镜像化发布整体耗时约 20min, 整体流程大概耗费半个小时。我们研发了一套基于函数粒度的发布运维模式，以 MaaSFunction 为入口，做跨文件 Linker，如何做 Linker，看这个示意图，我们从 MaasFunction 入口开始解析本类依赖的文件，比如这边依赖的其他函数，到下面的 service，再到 util 层的相互依赖，从而通过这种方式解析出业务代码片段，通过动态编译完 Jar 大小目前最大在 500KB 左右，根据代码大小一般在 5s 内，再通过热加载到目标机器上，整体可以做到 5s 级发布，1s 回滚，其他还有配套的日志、监控等等能力。\n 多语言 Runtime\n我们在初期建设的时候函数是都运行在一个集群里面，经常会遇到例如：死循环、OOM、线程频繁创建等等性能问题，因为业务代码不可控，CR 不能完全杜绝这类问题，这样我们就需要完全隔离的函数运行环境，从图中可以看到，每个函数至少具备 2 个独立的容器（容灾的需要），函数 1OOM（Out Of Memory），不会影响到函数 2。这样我们就可以基本做到函数级别的执行层隔离，我们通过 SLO 的度量，平台稳定性有了非常大的提升。\n当我们按照函数级别隔离的模式大规模上线的时候遇到了成本问题，底层 sigma 支持的 pod 调度的最小规模是 0.5c（底层物理网卡等等限制），如果 2 台容灾，基本上一个函数至少占用 1c 的物理资源，随着函数业务的大规模使用，这块成本是很难持续的。通过我们的观察，绝大多数函数占用实际的 CPU10% 不到，甚至更低。我们同 Serverless Paas 团队一起共建了函数的高密度部署模式，通过 0.5c 的 pod 中隔离 5 个 0.1c 的容器，然后通过容器 IP + 端口的方式绑定 …","date":1634022000,"description":"蚂蚁集团技术风险代码化平台实践（MaaS）","dir":"blog/ant-group-technical-risk-coding-platform-in-practice-maas/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"87ede64d8d98af4c1bf7bf4d51ee9cdf","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","publishdate":"2021-10-12T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","summary":"📄 文｜吴成辉（花名：清霄 蚂蚁集团高级技术专家) 校对｜陈真、庄晓丹、冯家纯 本文 6250 字 阅读 11 分钟 ▼ 我们一起回顾下监控上层业务曾经面临的问题： 烟囱式","tags":["SOFAStack"],"title":"蚂蚁集团技术风险代码化平台实践（MaaS）","type":"blog","url":"/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","wordcount":5838},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@风 提问：\n 麻烦问下 SOFA 中的 consumerConfig 的 uniqueId 和 application 分别起什么作用，有什么区别呀？\n A：发布 RPC 服务的时候做配置，uniqueId 是服务的唯一标识，比如你想同一个 service 类发两个服务，就起两个 uniqueId。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@郑楚齐 提问：\n 我在 K8s 上测试将使用 spring-cloud-feign 的服务接入 MOSN Proxy，但是目前 consumer 端一直访问不到 provider，我还在排查问题，想问一下，如果要调用的话，FeignClient 这边是不是需要直接将 URL 指向代理？ A：不是透明劫持的话，就要直接指向 Proxy 的端口。\n「MOSN」：https://github.com/mosn/mosn\n@东仔 提问：\n MOSN 在 Linux 上的 idea 如何启动？\n A：参考下图，\n 「MOSN」：https://github.com/mosn/mosn\n@王逸飞 提问：\n A -\u0026amp;gt; B, A 没有问题，执行到 B 的更新操作时候， Could not found global transaction xid = 192.168.0.112:8091:1893025023560908，会是什么原因产生的？\n A：debug 到 b 的时候看下 TC 的 global table 里面数据存不存在。可能是服务重试或者网络超时造成，自己看下 tm 的决议是什么?\n java.time.LocalDateTime 序列化失败，这样的情况一般如何解决呢? A：改数据库类型，mkyro + datatime 改为时间戳类型，或者等 1.5。\n「Seata」：https://github.com/seata/seata\n本周发布 Layotto 发布了0.2.0 版本，包括以下功能：\n 支持 File API\n 支持 Binding API\n Tracing 和 metrics\n 为已有 API 添加更多组件\n 修复安全问题以及减少 panic 风险\n 不同组件之间保证数据隔离、代码复用\n WASM 模块支持热加载\n go sdk 添加更多 feature\n 一个简单的 Java sdk\n 添加更多文档、修复文档错误\n 添加社区治理和晋升规则\n 详细参考：\nhttps://github.com/mosn/layotto/releases/tag/v0.2.0\n本周推荐阅读 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁智能监控\n ","date":1633676400,"description":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、Layotto 发布新版本","dir":"blog/sofa-weekly-20211008/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b71750e53df5357dc922e1a7d952c265","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211008/","publishdate":"2021-10-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211008/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、Layotto 发布新版本","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211008/","wordcount":1050},{"author":"金敏、邱见","categories":"SOFAStack","content":" 文｜金敏（蚂蚁集团技术专家)\\邱见（Red Hat)\n校对｜ 冯泳（蚂蚁集团资深技术专家)\n本文 3311 字 阅读 6 分钟\n从最初 Kubernetes 技术问世，业界一遍一遍的质疑它能否能经得住生产级的考验，到今天许多大型企业已经采用 Kubernetes 技术“云化”之前大规模的基础设施，在企业内部创建了数十个甚至数百个集群。\nKubernetes 原生的管理能力目前仍然停留在单集群级别。每一个集群可以稳定地自治运行，但是却缺乏横贯多个集群的统筹管理能力。基础设施的建立者需要协调分散在各处的管理组件，形成一个统一的管理平台。\n通过它，运维管理人员能够获知多集群水位的变化，节点健康状态的震荡等信息；业务应用负责人能够决策如何调配应用服务在各个集群中的部署分布；应用的运维人员能够获知服务状态，下发腾挪的策略。\n与多集群相关的创新正在不断涌现。例如 ClusterAPI 和 Submariner 就是处理特定多集群管理问题比较成功的项目。\n而本文要讨论的是那些试图解决企业在面对多集群管理时遇到的所有问题的技术探索。\n在过去五年中，中国的技术公司蚂蚁集团在多集群管理的思考、使用和实施等方面学习到了很多宝贵的经验。\n蚂蚁集团管理着遍布全球的数十个 Kubernetes 集群，每个集群平均拥有数千个节点（服务器）。他们将应用程序及其所需组件（包括中间件，数据库，负载均衡等等）在架构层面组织成逻辑数据中心（LDC）的弹性逻辑单元中，并将它们规划部署到物理基础设施上。这种架构设计帮助他们实现基础设施运维的两个关键目标：高可用性和事务性。\n 首先，部署在某个 LDC 上的业务应用的可用性在所属 LDC 内能够得到保障。\n 其次，部署在 LDC 内的应用组件可以被验证，并在故障发生时，可以被回滚。\n 蚂蚁集团 PaaS 团队的资深技术专家冯泳表示：\n “蚂蚁集团拥有数十个 Kubernetes 集群、数十万个节点和数千个关键应用的基础设施。在这样的云原生基础设施中，每天都会有数以万计的 Pod 被创建和删除。构建一个高度可用、可扩展且安全的平台来管理这些集群和应用程序是一项挑战。”\n PART. 1 始于 KubeFed 在 Kubernetes 项目生态中，多集群功能主要由与之同名的 SIG-Multicluster 团队处理。这个团队在 2017 年开发了一个集群联邦技术叫做 KubeFed。\n联邦最初被认为是 Kubernetes 的一个内置特性，但很快就遇到了实现以及用户诉求分裂的问题，Federation v1 可以将服务分发到多个 Kubernetes 集群，但不能处理其他类型的对象，也不能真正的以任何方式“管理”集群。一些有相当专业需求的用户——尤其是几个学术实验室——仍在使用它，但该项目已被 Kubernetes 归档，从未成为核心功能。\n然后，Federation v1 很快被一种名为“ KubeFed v2 ”的重构设计所取代，世界各地的运营人员都在使用该设计。它允许单个 Kubernetes 集群将多种对象部署到多个其他 Kubernetes 集群。KubeFed v2 还允许“控制平面”主集群管理其他集群，包括它们的大量资源和策略。这是蚂蚁集团多集群管理平台的第一代方案。\n蚂蚁集团使用多集群联邦的首要任务之一是资源弹性，不止包括节点级别弹性也包括站点级别弹性。通过在需要时添加节点和整个集群起到提高效率和扩展系统的能力。例如年度性的资源弹性，每年 11 月 11 日是中国一年一度的光棍节，蚂蚁集团通常需要快速部署大量额外容量来支持高峰在线购物工作负载。然而，可惜的是正如他们发现的那样 KubeFed 添加新集群的速度很慢，而且在管理大量集群方面效率低下。\n在 KubeFed v2 集群中，一个中枢 Kubernetes 集群会充当所有其他集群的单一“控制平面”。蚂蚁集团发现，在管理托管集群和托管集群中应用程序的时候，中枢集群的资源使用率都非常高。\n在管理仅占蚂蚁集团总量 3% 的应用程序工作负载的测试中，他们发现由中等规模的云实例构成的中枢集群就已经饱和了，并且响应时间很差。因此，他们从未在 KubeFed 上运行全部工作负载。\n第二个限制与 Kubernetes 的扩展功能有关，称为自定义资源定义或 CRD。类似蚂蚁集团这样的“高级用户”往往会开发众多的自定义资源来扩充管理能力。为了要在多集群间分发 CRD，KubeFed 要求为每个 CRD 都创建一个“联合 CRD”。这不仅使集群中的对象数量增加了一倍，也为在集群间维护 CRD 版本和 API 版本一致性方面带来了严重的问题，并且会造成应用程序因为不能兼容不同的 DRD 或者 API 版本而无法顺利升级。\nCRD 的这种数量激增也导致了严重的故障排除问题，同时 CRD 的使用定义不规范/字段变更随意等坏习惯会使 KubeFed 控制面的鲁棒性雪上加霜。在本地集群有自定义资源的地方，联邦控制平面上也有一个代表该本地集群资源的图形聚合视图。但是如果本地集群出现问题，很难从联邦控制平面开始知道问题出在哪里。本地集群上的操作日志和资源事件在联邦级别也是不可见的。\nPART. 2 转向 Open Cluster Management Open Cluster Management 项目（OCM）是由 IBM 最初研发，并由红帽在去年开源。OCM 在蚂蚁集团和其他合作伙伴的经验基础上，改进了多集群管理的方法。它将管理开销从中枢集群下放到每个被管理集群上的代理（Agent）上，让它在整个基础设施中分布式自治并维护稳定。这使得 OCM 理论上能管理的集群数量至少比 KubeFed 多一个数量级。到目前为止，用户已经测试了同时管理多达 1000 个集群。\nOCM 还能够利用 Kubernetes 本身的发展来提高自身的能力。例如，那些以 CRD 封装的能力扩展可以使用 OCM 的 WorkAPI（一个正在向 SIG-Multicluster 提议的子项目）在集群之间分发 Kubernetes 对象。WorkAPI 将本地 Kubernetes 资源的子集嵌入其中，作为要部署的对象的定义，并将其留给代理进行部署。此模型更加灵活，并且最大限度地减少了对任何中央控制平面的部署需求。WorkAPI 可以一起定义一个资源的多个版本，支持应用程序的升级路径。同时 WorkAPI 兼顾了中枢集群和被管理集群网络链接故障时的状态保持问题，并可以在重连的情况下保障资源状态的最终一致性。\n最重要的是，OCM 在集群部署中实现了更多的自动化。在 KubeFed 中，集群的纳管是一个“双向握手”的过程，以中枢集群和被管理集群之间“零信任”作为基础，在此过程中涉及许多手动步骤来保障安全性。新平台能够简化这一过程。例如，因为它在 “PULL” 的基础上运行，不再需要多阶段手动证书注册，也不需要任何明文的 KubeConfig 证书的流通，就可以做到让被管理集群获取中枢集群的管理命令。\n尽管注册的流程注重双向的“信任性”，但是在 OCM 中添加新集群只需要很少的操作；工作人员可以简单地在目标 Kubernetes 集群上部署 “Klusterlet” 代理实现自动纳 …","date":1633330800,"description":"下一个 Kubernetes 前沿：多集群管理","dir":"blog/next-kubernetes-frontier-multi-cluster-management/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7120f96fca72cfca3c6fbfd9ab9e3172","permalink":"https://sofastack.github.io/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","publishdate":"2021-10-04T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","summary":"文｜金敏（蚂蚁集团技术专家)\\邱见（Red Hat) 校对｜ 冯泳（蚂蚁集团资深技术专家) 本文 3311 字 阅读 6 分钟 从最初 Kubernetes 技术问世，业界一遍一遍的质疑它能否能","tags":["SOFAStack"],"title":"下一个 Kubernetes 前沿：多集群管理","type":"blog","url":"/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","wordcount":2933},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周新晋 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@郑楚齐 提问：\n 我们在 Istio 环境下，因为 MOSN 是自动 sidecar 注入的，我怎么控制他读取我的配置文件内容呢？而且我看官方的 Istio 案例也是可以通过 virsual service 进行流量控制的，我们这个 config.json 也是可以进行流量控制的，是不是我理解的 config.json 是在 virsualService.yaml 的功能上进行拓展的功能(比如这种 tag 路由是 virsualService 不能控制的)。\n A：Istio 场景下对应的 sidecar 的静态配置是一些通用的模板（如 pilot 地址渲染等）。关于 service 相关的路由及治理控制都是通过 Istio 定义的 CRD 控制：\nhttps://istio.io/latest/docs/reference/config/networking/\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n MOSN 执行的这个 config.json 是如何使用呢？因为目前 Istio 的这个配置 DestinationRule VirsualService 是不满足需求的，或者说 MOSN 收到我们订制的DestinationRule VirsualService，会自动转为 config.json 供给 MOSN 使用呢？\n A：cluster subset 配置目前 Istio 的 Destination Rule 还不支持，不过目前是可以通过 Envoy Filter 来给对应的 cluster 打 patch 实现（比较麻烦点）。\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n 如果是在 Envoy Filter 打 patch 的话，有没有什么例子吗?\n A：这个就是上面说的 cluster subset 配置。目前 Istio 的 Destination Rule 里面还不支持这个（详细见上面的那个讨论 issue），目前唯一的方法就是使用 Envoy Filter 的这个 CRD 打 patch 实现。\n可参考文档：https://istio.io/latest/docs/reference/config/networking/envoy-filter/#EnvoyFilter-ClusterMatch\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n 看了官方的 EnvoyFilter，不过感觉跟我们 MOSN 的 config.json 里面的内容想对照匹配起来确实很难。\n A：你可以用 xds 动态更新或者扩展用我们的 API 更新，不需要直接用这个配置文件。直接调用 MOSN 自己的 API，xds 其实也是 adapt 到这些 API 接口的，如果你们不用 Istio 的话，自己封装可能更简单，主要就 route 和 cluster 两个 API 就行了。\n这是一个用 zk 更新 Dubbo 的例子：\nhttps://github.com/mosn/mosn/blob/38b3b922b59500acc082e0ac9d705e41944c94ee/pkg/upstream/servicediscovery/dubbod/common.go#L99\nMOSN：https://github.com/mosn/mosn\n@孤若 提问：\n 当空回滚时，如果是因为远程方法调用 try 响应超时，怎么解决终止 try 执行？比如 rollback 执行远比 try 阶段快，rollback 结束 try 还在执行。\n A：我之前有参考这个，有提到 TCC 异常控制：\nhttps://www.infoq.cn/article/g33hcc-qosjplkt4e64e\nSeata：https://github.com/seata/seata\n@林祥标 提问：\n Seata 1.3.0 jdk 1.8 使用 jackson 对 localDateTime 进行序列化时报错，有大佬知道怎么解决吗？\n A：如果数据库用 datetime，实体又是 localdatetime，目前我发现只能 spi、替换序列化方式、依赖等等都没用。通过 spi 定义三个序列化方式就行了：LocalDate、LocalDateTime、LocalTime\u0026amp;hellip;反正如果数据库不是时间戳，目前给的适配方式是无用的(个人用下来的结果)。\nSeata：https://github.com/seata/seata\nSOFAStack：新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nEasy\n为 Layotto 中的关键模块添加注释（例如限流/分布式锁等模块）、添加 nodejs sdk。\nMedium\n用某种存储实现 File API 组件（例如本地文件系统、minio、hdfs、ftp 等）。\n「详见」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁智能监控\n 2021 年云原生技术发展现状及未来趋势\n ","date":1633071600,"description":"SOFA Weekly | Layotto 本周新晋 Contributor、QA 整理、新手任务）","dir":"blog/sofa-weekly-20211001/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8a010b34f9a0dbd849f07463c4b6c9b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211001/","publishdate":"2021-10-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211001/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto 本周新晋 Contributor、QA 整理、新手任务）","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211001/","wordcount":1710},{"author":"唐博、谭崇康","categories":"SOFAStack","content":" 文｜唐博（花名：博易 蚂蚁集团技术专家)\n谭崇康（花名：见云 蚂蚁集团高级技术家)\n本文 10316 字 阅读 18 分钟\n▼\n蚂蚁集团运行着全球最大的 Kubernetes（内部称为 Sigma) 集群之一。Kubernetes 社区官方以 5K node 作为 Kubernetes 规模化的事实标准，而蚂蚁集团在 2019 年的时候，就已经维护着单集群规模超过 1W node 的 Kubernetes 集群。\n这不仅仅是单集群节点量级上的差异，更是业务规模的差异，业务多样化和复杂度上的差异。\n一个形象化的比喻就是，如果官方以及跟着官方的 Kubernetes 使用者能想象到的 Kubernetes 的集群规模是泰山，那么蚂蚁集团在官方的解决方案之上已经实现了一个珠穆朗玛峰。\n蚂蚁集团的 Kubernetes 的演进，从 2018 年至今已经走过了 3 年多的岁月，虽然在 2019 年的时候就构建了万台集群的规模，但时至今日，无论是业务形态还是集群的服务器都发生了巨大的变化。\n 首先，当时的集群万台节点，主要还是偏小规格的服务器，而如今都是大机型，虽然机器的数量也是万台，实际管理的 CPU 数量已经成倍增长。\n 其次是当时集群里面几乎全量是 Long running 的在线业务，Pod 的创建频率每天只有几千个，如今我们的集群上几乎跑满了流式计算和离线计算业务等按需分配的 Pod，因此在 Pod 数量上成倍增长，实际管理的 Pod 数量超过了百万。\n 最后，是 Serverless 的业务快速发展，Serverless Pod 的生命周期基本在分钟级甚至是秒级，集群每天的 Pod 创建量也超过了几十万，伴随着大量的 Kubernetes list watch 和 CRUD 请求，集群的 apiserver 承受了数倍于以往的压力。\n 因此在业务 Serverless 的大背景下，我们在蚂蚁启动了大规模 Sigma 集群的性能优化方案，根据业务的增长趋势，我们设定的目标是，构建 1.4W 个节点规模的集群，同时通过技术优化，期望达成在请求延迟上不会因为规模的原因有所下降，能够对齐社区标准，即 create/update/delete 请求的天级别 P99 RT 在 1s 之内。\n可想而知，挑战是非常巨大的。\nPART. 1 大规模集群的挑战 毋庸置疑，大规模集群带来了很多挑战：\n 随着集群规模增大，故障的爆炸半径也将扩大。Sigma 集群承载了蚂蚁集团诸多重要应用，保障集群的稳定和业务的稳定是最基础也是优先级最高的要求。\n 用户大量的 list 操作，包括 list all，list by namespace，list by label 等，均会随着集群的规模增大而开销变大。这些合理或者不合理的 list 请求，将让 apiserver 的内存在短时间内快速增长，出现 OOM 异常，无法对外响应请求。此外，业务方的 list 请求也会因为 apiserver 无法处理请求而不断重试，造成 apiserver 重启后因过载不可恢复服务能力，影响整个集群的可用性。\n 大量 List 请求透过 apiserver 直接访问 etcd 服务，也会让 etcd 实例的内存剧增而出现 OOM 异常。\n 随着业务量的增长，特别是离线任务的增多，create/update/delete 等请求的数量也迅速增加，导致客户端请求 apiserver 的 RT 极速上升，进而使得调度器和一些控制器因为选主请求超时而丢主。\n 业务量增长将加剧 etcd 由于 compact 等操作自身存在的性能问题，而使 etcd 的 P99 RT 暴涨，进而导致 apiserver 无法响应请求。\n 集群中的控制器服务，包括 Kubernetes 社区自带的控制器例如 service controller，cronjob controller 以及业务的 operator 等，自身存在的性能问题都将在大规模集群面前被进一步放大。这些问题将进一步传导到线上业务，导致业务受损。\n 如计算机学科的古老格言所说：\n「 All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection\u0026amp;hellip; and the performance problems. 」\n大规模集群既是照妖镜，也是试金石。\nPART. 2 大规模集群的收益 诚然，构建一个大规模的 Kubernetes 集群也提供了诸多收益：\n 为运行大型服务提供更为便利的基础设施 ，便于应对业务扩容时大幅飙升的资源需求。例如在双十一等电商大促活动期间，可以通过扩展现有集群而不是新建其它小集群来应对业务的增长。同时集群管理者可以管理更少的集群，并且以此来简化基础架构管理 。\n 为大数据和机器学习的离线计算任务提供更多的资源，为分时复用/分时调度等调度手段提供更大的施展空间，让离线的计算任务在在线业务的低峰期时可以使用更多的资源进行计算，享受极致弹性和极速交付。\n 还有非常重要的一点，在更大的集群中可以通过更加丰富的编排调度手段来更为有效地提升集群整体的资源利用率。\n PART. 3 SigmaApiServer性能优化 Sigma apiserver 组件是 Kubernetes 集群的所有外部请求访问入口，以及 Kubernetes 集群内部所有组件的协作枢纽。apiserver 具备了以下几方面的功能:\n 屏蔽后端数据持久化组件 etcd 的存储细节，并且引入了数据缓存，在此基础上对于数据提供了更多种类的访问机制。\n 通过提供标准 API，使外部访问客户端可以对集群中的资源进行 CRUD 操作。\n 提供了 list-watch 原语，使客户端可以实时获取到资源中资源的状态。\n 我们对于 apiserver 性能提升来说可以从两个层面进行拆解，分别是 apiserver 的启动阶段和 apiserver 的运行阶段。\napiserver 启动阶段 的性能优化有助于：\n 减少升级变更影响时长/故障恢复时长，减少用户可感知的不可用时间，给 Sigma 终端用户提供优质的服务体验（面向业务的整体目标是 Sigma 月度可用性 SLO 达到 99.9%，单次故障不可用时间 \u0026amp;lt; 10min）。\n 减少因为发布时客户端重新 list 全量资源而导致的 apiserver 压力过大情况出现。\n apiserver 运行阶段 的性能优化的意义在于：\n 稳定支持更大规模的 Kubernetes 集群。\n 提高 apiserver 在正常平稳运行的状态中，单位资源的服务能力；即提高可以承受的请求并发和 qps， 降低请求 RT。\n 减少客户端的超时以及超时导致的各种问题；在现有资源下提供更多的流量接入能力；\n 整体优化思路\n构建一个大规模的 Kubernetes 集群以及性能优化不是一件容易的事，如 Google Kubernetes Engine K8s 规模化文章所 …","date":1632812400,"description":"攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践","dir":"blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b6cc47242239f350d5aca9717037f061","permalink":"https://sofastack.github.io/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","publishdate":"2021-09-28T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","summary":"文｜唐博（花名：博易 蚂蚁集团技术专家) 谭崇康（花名：见云 蚂蚁集团高级技术家) 本文 10316 字 阅读 18 分钟 ▼ 蚂蚁集团运行着全球最大的 Kubernetes","tags":["SOFAStack"],"title":"攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践","type":"blog","url":"/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","wordcount":7129},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@证道者 提问：\n MOSN 怎么将 HTTP 转到 Dubbo 的数据,怎么实现新的协议？\n A：这个你要写个 filter ，因为每个 HTTP 字段怎么对应 Dubbo 的字段，是没有固定标准的。\nA：「HTTP 转 SOFA 的例子」 https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ftranscoder%2Fhttp2bolt\nA：这个需要 client 满足这个字段对应规范，所以一般就自己实现了。\n 公司很多这种 RPC 的接口，每一个接口都要写一下 filter 吗？没有通用的转换吗？\n A：一个协议就一个吧，比如 HTTP 的 header：service 对应 Dubbo 的 service。你也可以用其他的 HTTP header 来对应，比如用 dubbo-service，所以没有一个标准，就需要自己简单做个对应关系。\nMOSN：https://github.com/mosn/mosn\n@王夕 提问：\n 咨询一个问题，TCC 的嵌套子事务，如果发生重试的话，如下图中的 2、6，会产生不同的 branch 记录吗？ A：有可能,要么关了重试,要么做幂等\n 也就是说根据 xid 做幂等，而不要根据 branchid 做幂等对吗？\n A：branchid 进来一次就变一次,肯定不行,该分支同入参同 xid 一般就可以作为幂等的校验条件。\nSeata：https://github.com/seata/seata\n@江培泉 提问：\n 请教下，oracle 用户没获取到行信息，导致 undo_log 无法插入，也无法回滚。 主键字段类型和 JAVA 的类型： A：主键的 Long 改成 BigDecimal，Oracle 的 number 长度超过 19 之后，用 Long 的话，setObject 会查不出数据来。\nSeata：https://github.com/seata/seata\n本周推荐阅读 SOFAJRaft 在同程旅游中的实践\n 技术风口上的限流\n 蚂蚁智能监控\n 2021 年云原生技术发展现状及未来趋势\n ","date":1632466800,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210924/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"88a73b7a463bc79a5bcb81ae4e0a4fee","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210924/","publishdate":"2021-09-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210924/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210924/","wordcount":903},{"author":"赵延","categories":"SOFAStack","content":"文｜赵延（SOFAJRaft Committer)\n校对｜冯家纯（SOFAJRaft Committer)\n本文 15717 字 阅读 23 分钟\n▼\n同程艺龙作为对 Raft 研究较早的公司，早在 14 年算法的 paper 刚发布的时候，便已经对其进行了调研。同时也与 paxos 、zab 等算法进行了详细的对比，并在公司内部的计数器、任务调度元信息存储等场景进行试点。\n不过早期对于 Raft 的尝试较多的是在 C++ 技术栈试水，在 Java 技术栈里却很少有涉及。\n近期刚好有基于 etcd 的老项目由于需要自定义的数据结构需要重构，原有的 etcd 无法在底层数据结构层面满足需求，因此决定采用 Java 技术栈结合开源项目 SOFAJRaft 进行底层数据存储的开发，以期解决多节点数据强一致的问题。\n本文假设读者对 Raft 及强一致的概念已经有了较深的理解，详细介绍了公司内部如何使用 *JRaft* 的进行老系统的改造以及使用过程中遇到的工程问题，希望其他对 Raft 有兴趣的同学可以一起讨论。\nPART. 1\n背 景\n公司内部原本存在一个系统 mdb (metadata database)，go 语言编写，用于管理所有的实例元数据信息，元数据的内容就是一个 map。\n该组件提供对元数据增删改查的接口，并且使用 go 语言编写，在检索数据时引入了 K8s selector 的包，使用 K8s selector 的解析规则筛选特定标签的元数据信息。\n数据持久化则是实用了强一致组件 etcd 进行存储，key 为元数据的 ID，保证唯一，value 为具体的元信息，包含各个标签以及对应的值。\n该系统大体架构如图 -1 所示:\n 图-1：原来的架构\n「该架构的弊端」\n 每隔一段时间需要去拉取 etcd 的全量数据，担心单次请求数据量太大的情况，对数据 ID 进行了 hash 分片，依次获取每个分片下个 key，再通过 key 去获取 value，导致 etcd 的查询频率非常高。\n 非 ID 查询条件的一致性查询，和上面的问题一样，也需要做拉取全量数据的操作。\n 更新删除操作也是一样，需要拉取全量数据再操作。\n 分析以上问题可以发现，使用 etcd 作为强一致存储，但 etcd 是基于 KV 存储的组件，并且解析组件 mdb 和 etcd 是分离的，在需要保证数据最新的情况下，必须得去 etcd 拿最新的数据到本地再进行操作。\n而 etcd 基于 KV，就得拿到 etcd 的全量数据都给拉到本地后再做操作。\n如果有一个组件，提供强一致的存储能力，又能直接去解析 K8s selector 的规则，存储的数据结构和元数据信息更加亲和，那么中间的那一层 mdb 就可以直接去掉了，由这个组件来解析对应的 crud 规则，将解析过后的规则直接在本地查询，那么以上问题就能够直接解决了。\nPART. 2\n改 造\n基于以上问题，我们准备自己开发一个强一致存储的组件，能够自己解析 K8s selector 的规则，并且将数据保存在自己本地。\n因为个人对 Java 语言比较了解，并且之前使用 Nacos 时，对 SOFAJRaft 也有一定了解，最终选择了 SOFAJRaft 来构建强一致存储组件，将它命名为 mdb-store。\n主要改造点：\n 使用 SOFAJRaft 编程模型构建业务状态机，业务状态机中根据 Raft log 中的 data 类型，进行 crud 的操作。\n mdb-store 提供与原来 mdb 相同的 api，让改造对用户透明，改造完成后只需要切换域名对应的实例即可。\n 迁移 K8s selector 的解析逻辑，这里用 Java 写了一套和 go 版本 K8s selector 一样解析逻辑的组件 K8s-selector-Java。\n 改造过后的架构如图-2所示:\n 图-2：重构后的架构\n通过改造过后，将 mdb 移除，让用户直接和 mdb-store 进行通信，中间的通信少了一跳，加快了访问效率。将 mdb 和 etcd 也进行了移除，减少了整个系统的组件，降低运维成本。\nPART. 3\nSOFAJRaft 的具体使用\n将写操作转换成 Raft log\n在 SOFAJRaft 中，编程模型和通常的 Spring MVC 的编程模式不太一样。\n在 Spring MVC 中，一个请求到达了后端，通常会通过 Controller -\u0026amp;gt; Service -\u0026amp;gt; Processor 这么几层。Controller 负责本次 http 请求的资源映射， 再由 Controller 去调用特定的 Service 方法，在 Service 层中，对参数进行一些处理和转换，再交由 Processor 层去对请求做真正的处理。\n大体逻辑如图 -3 所示，\n 图-3：通常的编程模型\n在 SOFAJRaft 中，所有的写操作都要通过状态机去执行（读操作不需要经过状态机）。需要将写操作转换成 task，状态机去应用 task 然后再进行业务处理。\ntask 中包含两个属性是需要关注的，一个是 done，一个是 data。\n- done 就是本次 task 被状态机处理完成后的回调，比如在 done 的回调逻辑中，将 response flush 到客户端。\n- data 就是 Raft log 中的具体数据，比如要执行一条插入元数据的命令。data 就会包含本次操作的类型（插入），以及本次操作的具体数据。\nprivate ByteBuffer data = LogEntry.EMPTY_DATA; private Closure done; /// 省略部分代码 } 大体逻辑如图 -4 所示，\n 图-4：SOFAJRaft 的编程模型\n所有的操作都抽象成一个实体 Operation，在 Service 层，就根据业务把参数转换成不同的 Operation，然后再将 Operation 序列化，设置到 Task 中的 data 属性，再由 Node 将 task 提交。\n这里可以将 task 看成是一个 Raft log，一旦 Raft log 被半数的机器给提交。状态机就会应用 Raft log，应用完成之后就会触发 done 中的回调。\n· 抽象过后的实体类\n//操作类型，比如增删改查 int type; //操作的哪个表，某些类型不需要此字段 String table; //具体的操作数据，根据 type 的不同，数据类型也会不同 T params;} · 构建 task 并通过 node 提交给状态机\n//定义回调的逻辑，当该 Raft log 被状态机应用后，会进行回调 task.setDone(new StoreClosure(operation, status -\u0026amp;gt; { StoreStatus storageStatus = (StoreStatus) status; closure.setThrowable(storageStatus.getThrowable()); …","date":1632207600,"description":"SOFAJRaft 在同程旅游中的实践","dir":"blog/sofajraft-in-practice-in-the-same-tour/","fuzzywordcount":7500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7c319b747ce3bc0df7adbd820d690ed3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","publishdate":"2021-09-21T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","summary":"文｜赵延（SOFAJRaft Committer) 校对｜冯家纯（SOFAJRaft Committer) 本文 15717 字 阅读 23 分钟 ▼ 同程艺龙作为对 Raft 研究较早的公司，早在 14 年算法的 paper 刚发布的","tags":["SOFAStack"],"title":"SOFAJRaft 在同程旅游中的实践","type":"blog","url":"/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","wordcount":7461},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@证道者 提问：\n 今天看了文章，好像蚂蚁 MOSN 结合 envoy，性能更好，不知道有没有开源这个？\n A：有开源，有个镜像可以玩。\nhttps://mp.weixin.qq.com/s/ioewVcwiB5QA8w3A3gaikg，\n今年 GopherChina 的文字版, 可以了解下。我们内部已经落地，线上跑飞起来了，适合不同的场景了。目前我们用在南北和网关，比较大规模的场景。这个目前也在跟 envoy 官方共建合作，还有场景就是本来就是 envoy 的用户，也可以更简单的写扩展。\n2、@朱仕智 提问：\n 请问这个限流在开源版本 MOSN 里面吗？\n A：在开源，内部的做了一些业务相关的扩展。\n3、@Glennxu 提问：\n请问下现在统一限流中心能使用么？\n A：现在开源版本还用不了集群限流，自适应限流的实现也和我们的有一些差异,后面我们会考虑移植到开源版本的。\n4、@朱仕智 提问：\n 今天正好在看 kratos 里面限流的文章，那个限流就是自适应限流，这里提到统一限流中心，这个哪里能看到？\n A：这个短期我们估计不会开源的，主要是这部分功能本身比较简单，而我们内部的规则和开源的模型也有所不同，加上现在我们跟自己的基础设施绑定了，不太方便直接开源。\n5、@魏小亮 提问：\n 是不是简单理解为 MOSN 作为 cpp 的动态库，作为一个插件给 envoy 调用？\n A：可以这么简单认为，对于一般用户的话就是用关心 MOSN 就行了，写 MOSN 的 filter，不需要了解底层机制。就像大家用 openresty，也很少去关心 nginx 和 luajit。\n 我以为要实现一个 envoy 的 filter 需要 c++ 代码来实现。\n A：其实 lua 也可以， 比如用 go 你可以启动一个 zk，然后去调用 envoy 的 xds 做服务发现可以做的事情就很多了。\n6、@茄子 提问：\n请教一下，在使用 rheakv 的过程中出现这个问题要怎么排查?\n A：可以看下 bolt 怎么设置写入的高低水位线，这应该是触发了 netty 的 channel 写入水位线。\ncom.alipay.remoting.config.BoltGenericOption#NETTY_BUFFER_HIGH_WATER_MARK com.alipay.remoting.config.BoltGenericOption#NETTY_BUFFER_LOW_WATER_MARK\n刚才找了下，你看些这个类的 options。\n com.alipay.sofa.jraft.rpc.impl.BoltRaftRpcFactory#CHANNEL_WRITE_BUF_LOW_WATER_MARK com.alipay.sofa.jraft.rpc.impl.BoltRaftRpcFactory#CHANNEL_WRITE_BUF_HIGH_WATER_MARK\njraft 也开放了设置。\n本周发布 SOFABoot 开源发布 3.9.0 版本，\\主要更新如下\\：\n SOFABoot 异常日志添加错误码；\n 去除 AbstractContractDefinitionParser 对 Autowire 注解的使用；\n 为 RPC 服务提供方添加开关，可以不注册到服务注册容器中；\n 添加健康检查进度；\n 去除 SOFARuntimeManager 对 Value 注解的使用；\n 优化 Spring 上下文并行启动的线程池配置。\n 详细参考：\nhttps://github.com/sofastack/sofa-boot/releases/tag/v3.9.0\n**SOFARPC 发布 v5.7.10 版本代码，主要更新如下：\n SOFARPC 支持接口中静态方法的使用；\n 使用 TransmittableThreadLocal 解决 RpcInternalContext 中 ThreadLocal 值传递问题；\n 优化超时时间的获取与校；\n 反序列化过程中正确感知 header 变化；\n 修复 RpcInvokeContext 中线程安全问题；\n 修复 ProviderInfo中getAttr 类型转换问题。\n 详细参考：\nhttps://github.com/sofastack/sofa-rpc/releases/tag/v5.7.10\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1631862000,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210917/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"83215c365789c806399a2ca00fc114e9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210917/","publishdate":"2021-09-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210917/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210917/","wordcount":1344},{"author":"张稀虹","categories":"SOFAStack","content":" 站在风口上 要问近两年最火的技术话题是什么？\nService Mesh 一定不会缺席。\n如果用一句话来解释什么是 Service Mesh。\n可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。*\n对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关心服务之间的那些原本通过服务框架实现的事情，只要交给 Service Mesh 就可以了。\nService Mesh 作为 sidecar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在 Serivce Mesh 中实现，这对于限流熔断而言就是一个天然的流量劫持点。\n如今蚂蚁 80% 以上的应用都已经完成了 Mesh 化，Mesh 统一限流熔断的建设自然是水到渠成了。\n服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。\n在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。\n 相较于传统的限流组件，Mesh 限流具备很多优势，在研发效能和研发成本上都取得了明显的收益：\n- MOSN 架构天然的流量劫持让应用无需逐个接入 SDK\n- 也无需为特定语言开发不同版本的限流组件\n- 限流能力的升级也无需业务同步升级\n「背景业务」\n 在 Mesh 统一限流实现前，蚂蚁集团内部存在多个不同的限流产品，分别提供不同的流量控制策略：\n不同类型的流量（SOFARPC、无线网关 RPC、HTTP、消息等）限流配置分散在不同的平台，由不同的团队维护，产品质量和文档质量参差不齐，学习成本高、使用体验差。\n不同的限流策略需要接入不同的 SDK，引入很多间接依赖，安全漏洞引起的升级频繁，维护成本高。\n不仅在开发建设上存在不必要的人力投入，也给业务方使用造成了困扰和不便。\n另一方面，我们的业务规模越来越大，但大量服务仍在使用最简单的单机限流策略。没有通用的自适应限流、热点限流、精细化限流、集群限流等能力。\n因为限流能力缺失、限流漏配、错误的限流配置等问题引起的故障频发。\nMesh 架构下，sidecar 对流量管理具备天然的优势，业务无需在应用中接入或升级限流组件，中间件也无需针对不同的技术栈开发或维护多个版本的限流组件。\n在目前 Service Mesh 蚂蚁内部大规模接入完成的背景下，将多种不同的限流能力统一收口至 MOSN，将所有限流规则配置统一收口至“统一限流中心”，可以进一步提高 MOSN 的流量管理能力，同时大幅降低业务限流接入及配置成本。\n基于这样的背景下，我们在 MOSN 中进行了统一限流能力建设。\n站在巨人肩膀上 在建设统一限流能力的过程中，我们调研了许多成熟的产品，既包括我们自己的 Guardian、Shiva、都江堰等，也包括开源社区的 concurrency-limits 、Hystrix、Sentinel 等产品。\n我们发现阿里巴巴集团开源的 Sentinel 是其中的集大成者。\n之前我们在打造 Shiva 的过程中也与集团 Sentinel 的同学进行过交流学习，他们也正在积极建设 Golang 版本的 sentinel-golang。\nMOSN 作为一款蚂蚁自研的基于 Golang 技术建设的 Mesh 开源框架，如果搭配上 Sentinel 的强大的流控能力和较为出色的社区影响力，简直是强强联合、如虎添翼、珠联璧合、相得益彰\u0026amp;hellip;啊。\n不过 Sentinel 对于我们而言也并不是开箱即用的，我们并不是完全没有历史包袱的全新业务，必须要考虑到蚂蚁的基础设施和历史限流产品的兼容，经过我们调研发现主要存在几个需要投入建设的点：\n 控制面规则下发需要走蚂蚁的基础设施\n *Sentinel-golang 的单机限流、熔断等逻辑，*和我们之前的产品有较大差异\n 集群限流也要用蚂蚁的基础设施实现\n *Sentinel 自适应限流粒度太粗，*蚂蚁有更加精细化的需求\n 日志采集方案需要调整\n 综合考虑后，我们决定基于 Sentinel 做扩展，站在巨人的肩膀上打造蚂蚁自己的 Mesh 限流能力。\n基于 Sentinel 良好的扩展能力，我们对单机限流、服务熔断、集群限流、自适应限流等都做了蚂蚁自己的实现，也将部分通用的改动反哺到了开源社区，同时配套建设了统一的日志监控报警、统一限流中心。\n 最终我们在 MOSN 里将各种能力都完成了建设，下表展示了 MOSN 限流和其他限流组件的能力对比：\n 奥卡姆剃刀 Pluralitas non est ponenda sine necessitate.\n如无必要，勿增实体\n 一个限流策略就配套一个 SDK 和一个管理后台七零八落，交互体验参差不齐，文档和操作手册质量也良莠不齐，交由不同的团队维护和答疑，如果你全都体验过一遍一定会深恶痛绝。\n而 Mesh 统一限流的核心目的之一就是砍掉这些东西，化繁为简，降低业务同学的学习成本和使用成本，降低我们自己的维护成本。\n- 流量控制的能力全部集成到 MOSN 里，取众家之长，去其糟粕\n- 流量控制的管控台全部收口到统一限流中心\n 这应该是我们造的最后一个限流轮子了吧\n青出于蓝而胜于蓝\n上文提到了我们是站在 Sentinel 的肩膀上实现的 Mesh 统一限流，那我们又做了什么 Sentinel 所不具备的能力呢？\n实际上我们对几乎所有的 Sentinel 提供的限流能力都做了一套自己的实现，其中也有不少的亮点和增强。\n下面分享几个我们的技术亮点。\n自适应限流\n- 对于业务同学而言逐个接口做容量评估和压测回归费时费心，有限的精力只能投入到重点的接口保障上，难免会漏配一些小流量接口的限流。\n- 而负责质量和稳定性保障的同学经常在故障复盘时看到各种漏配限流、错配限流、压测故障、线程阻塞等造成的各种故障。\n我们希望即使在系统漏配错配限流的情况下，在系统资源严重不足时 MOSN 能够精准的找到导致系统资源不足的罪魁祸首，并实时根据系统水位自动调节异常流量。\n在此需求背景下我们实现了一套符合成熟云原生定义的自检测、自调节的限流策略。\n 自适应限流的实现原理并不复杂，朴素的解释就是，触发限流后实时检测系统整体水位，同时秒级按比例调节流量。\n核心逻辑如下：\n- 系统资源检测：秒级检测系统资源占用情况，如果连续超过阈值 N 秒（默认 5 秒）则触发基线计算，同时将压测流量阻断腾挪出资源给线上业务使用；\n- 基线计算：将当前所有的接口统计数据遍历一遍，通过一系列算法找出资源消耗大户，再把这些大户里明显上涨的异常流量找出来，把他们当前的资源占用做个快照存入基线数据中；\n- 基线调节器：将上一步骤存入的基线数据根据实际情况进行调整，根据系统资源检测的结果秒级的调整基线值，仍然超过系统阈值则按比例下调基线值，否则按比例恢复基线值，如此反复；\n- 限流决策：\n系统流量不断经过自适应限流模块，会尝试获取该接口的基线数据，如果没有说明 …","date":1631602800,"description":"技术风口上的限流","dir":"blog/restricted-flow-on-the-technology-windfall/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cb0fcdbcc898f63e21810897fcd0a0d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","publishdate":"2021-09-14T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","summary":"站在风口上 要问近两年最火的技术话题是什么？ Service Mesh 一定不会缺席。 如果用一句话来解释什么是 Service Mesh。 可以将它比作是应用程序或者说微服务间的 TCP","tags":["SOFAStack"],"title":"技术风口上的限流","type":"blog","url":"/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","wordcount":4850},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA x Erda Meetup#8 成都站，云原生基础设施建设的现在及未来\n 活动时间：2021 年 09 月 11 日（周六）13:30-17:00\n 活动地点：四川省成都市武侯区蚂蚁 C 空间 101 猎户座\n 活动形式：线下活动\n 资料下载： 《从云原生视角，解读 Erda 微服务观测系统的实现》 《Service Mesh落地之后：为 sidecar 注入灵魂》 《技术风口上的限流—蚂蚁集团的 Mesh 限流落地与实践 》 《Erda 关于云原生数据开发平台的思考和实践》\n 活动议程 活动回顾 《从云原生视角，解读 Erda 微服务观测系统的实现》\n嘉宾介绍\n刘浩杨，Erda 微服务和监控团队负责人，主要负责云原生 PaaS 的架构设计、微服务观测治理平台的产品技术规划等工作，对分布式、可观察性、云原生等方向有深入的研究和实践经验。同时也是开源爱好者，Apache SkyWalking PMC 成员，在 Apache SkyWalking 的多语言生态和社区建设中起到重要作用。\n议题简介\n 在云原生架构下，基于 DevOps、微服务、容器化等云原生的能力，可以帮助业务团队快速、持续、可靠和规模化地交付系统，同时也使得系统的复杂度成倍提升，由此带来了前所未有的运维挑战。 在此背景下，对分布式系统的“可观测性”应运而生，可观察性提供了一套理念来监控、诊断云原生应用系统。和监控相比，可观察性从单一的度量扩展为 Metrics、Tracing、Logging 三大支柱，Erda MSP (MicroService Platform) 中的 APM 系统也在逐渐演进为以可观察性分析诊断为核心的微服务观测平台，本次主题将会解读 Erda 对微服务观测系统的探索和实践。 听众收获\n可快速了解监控和可观测性技术的发展历程，了解云原生场景下可观测性的痛点和解决方案，及获取 Erda 微服务观测平台的功能特性。\n《Service Mesh落地之后：为 sidecar 注入灵魂》\n嘉宾介绍\n周群力（花名：仪式），开源爱好者, co-founder of Layotto，Dapr contributor。目前在蚂蚁中间件团队工作，对SOFAStack和MOSN的开源影响力负责。虽然工作是做云原生基础设施，但业余时间也喜欢折腾前端和数据。\n议题简介\n 随着Service Mesh在蚂蚁集团内部的大规模落地，我们逐渐遇到了新的挑战，这让我们迫切的寻找新的解决方案。 Service Mesh通过引入sidecar来简化服务治理，但是随着探索实践，我们发现 sidecar 能做的事情远不止于此。一方面，给 sidecar 添加 Multi-Runtime 能力可以帮助基础设施团队更好的和业务团队解耦，简化多语言治理；另一方面，中立的 Runtime API 可以抽象基础设施、简化编程，帮助 K8s 生态成为真正的“分布式操作系统”，也帮助应用彻底和厂商解绑，保证多云环境的可移植性；与此同时，在 WebAssembly 日益火爆的当下，WASM 也能帮助 sidecar 实现 FaaS、业务系统 sdk 下沉等功能。 那么，Service Mesh落地之后，架构演进的思路是什么？我们的思路是：为sidecar注入灵魂。 听众收获\n 了解蚂蚁集团在Service Mesh大规模落地以后遇到的新问题以及对于如何解决这些问题的思考。 了解Multi-Runtime解决的问题及实践经验。 了解中立的Runtime API解决什么问题，以及相关实践经验 了解WASM在FaaS等方向的探索。 《技术风口上的限流—蚂蚁集团的 Mesh 限流落地与实践 》\n嘉宾介绍\n张稀虹，蚂蚁集团技术专家，专注于云原生相关技术在业务生产中的落地与实践，开源项目 MOSN 核心成员，目前关注云原生 ServiceMesh、Serverless 等相关领域。\n议题简介\n ServiceMesh 可谓是站在风口上的技术热点，流量控制正是 Mesh 架构下的核心功能。Mesh 的架构优势使得业务可以更低成本的使用上通用的限流熔断能力，本次分享为大家介绍蚂蚁集团的 Mesh 限流能力的建设以及业务落地推广的实践经验。 听众收获\n 了解 Mesh 架构下的限流熔断技术优势 分享蚂蚁集团 Mesh 限流熔断能力建设经验 拓宽思路了解限流熔断未来的探索方向 《Erda 关于云原生数据开发平台的思考和实践》\n嘉宾介绍\n侯璐瑶，高级技术专家，Erda 数据团队负责人，主要负责基于云原生的数据平台的架构设计、负责数据应用产品架构和产品演进，对于大数据领域数据组件和数据应用等方向有比较深入的研究和实践经验。\n议题简介\n 数据 on 云原生是必然的路径，云原生对于数据平台带来了比传统平台更容易的扩展性和便捷性。本次分享主要介绍 Erda 数据开发平台在云原生上的建设和实战经验。 听众收获\n 了解云原生的整体数据架构； 分享 Erda 的落地实践经验。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1631343600,"description":"【活动回顾】SOFAMeetup#8 成都站 云原生基础设施建设的现在及未来","dir":"activities/sofa-meetup-10/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"270d57821d3a01ac4bc85082d157f6d9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-10/","publishdate":"2021-09-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-10/","summary":"概要 活动主题：SOFA x Erda Meetup#8 成都站，云原生基础设施建设的现在及未来 活动时间：2021 年 09 月 11 日（周六）13:30-17:00 活动地点：四川省","tags":["SOFAMeetup"],"title":"【活动回顾】SOFAMeetup#8 成都站 云原生基础设施建设的现在及未来","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-10/","wordcount":1791},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@胡希国 提问：\n 这个 start 函数在父进程执行完 WaitConnectionsDone()之后在哪调用的，新的子进程在迁移长连接的时候监听 conn.sock 等着老进程调 startRWloop 去连接和发送 connfd，看源码一直到 WaitConnectionsDone() 就断了，实在没找到接下来在哪执行的 ReadLoop 和 WriteLoop。\n https://github.com/mosn/mosn/blob/0ea3e3b4b2abfde2a845edc006a3e866ff0b1201/pkg/network/connection.go#L186\nA：迁移连接之后，创建连接最后就会 start 了。\n 2、@胡希国 提问：\n 父进程的每个长连接 connection fd 里面都有一个 readloop 逻辑是吗？一旦 WaitConnectionsDone() 触发了 stopchan 那个条件，就自动做迁移了是吧。\n A：是的，每个连接都有 readloop 的， WaitConnectionsDone 就是等他们迁移完。\nhttps://mosn.io/docs/concept/smooth-upgrade/\n这篇文章里面有写的。\n 3、@汪晓涛 提问：\n 镜像地址有吗？可以对接 dapr 吗？\n A：目前是七层扩展哈，对接 dapr 是四层，这个月底应该就可以支持了。\nhttps://github.com/mosn/mosn/issues/1563\n4、@徐泽唯 提问：\n 大佬帮我看下这是什么问题？xid in change during RPC from 192.168.2.115:8091:178170994535436288 to null。\n A：不影响，直接升级最新的 spring-cloud-starter-alibaba-seata 和最新的 seata-all 或者 seata-spring-boot-starter 即可，只是一个日志警告。\n5、@北京jht 提问：\n 如果想了解一下这个组件对系统带来的开销和性能，可能会出现在哪个问题上。\n A：没有实际的业务场景，结果出入比较大。RPC 开销应该是最大的消耗。\n 咱们这个 Seata-Server 的回查和提交都是异步的吧，会对 RPC 本身的耗时产生影响吗？\n A：你算 RPC 一次 1ms tm begin 1ms rmregisty 1ms 如果有 3 个 rm，就是 4ms。然后 tm 决议发给 tc，5ms。如果是 tcc，那么就是 5ms + tc 下发到 3 个 rm 执行，rm 执行二阶段业务也要时间。\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1631257200,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210910/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e29e1740eb32b19f715b92a21a2dfd02","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210910/","publishdate":"2021-09-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210910/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210910/","wordcount":907},{"author":"向万鹏","categories":"SOFAStack","content":" AntMonitor简介 AntMonitor 是蚂蚁集团的智能监控系统，通过构建面向监控可观测数据的、实时的、稳定的采集、清洗、计算及存储数据链路，为技术风险大脑及体系提供实时、稳定、可靠、丰富的可观测数据与告警服务。\nAntMonitor 日常服务于蚂蚁全站 100+ 业务域，分钟峰值数据清洗量 20TB、数据聚合量 1TB、数据存储量 1.5 亿条，大促期间这些指标更是成倍增长，如此庞大且复杂的系统是如何对自身的稳定性进行保障的，这篇文章将从思考、策略与实现的角度带领大家一探究竟。\n系统构架 系统架构上，AntMonitor 可以分为产品、告警、计算和存储等四个子系统，各个子系统可以独立提供服务，又相互协调配合，承担起了蚂蚁技术风险的数据底盘角色。\n 产品系统 产品系统直接为用户提供各项可视化服务，包括 monitormeta 和 monitorprod 两个组件。\n monitormeta 负责元数据的管理与同步，例如计算配置、告警规则以及各类运维元数据等；\n monitorprod 为产品中台核心服务，对外提供数据服务；对内支持数据模型定义，数据模型抽象，数据模型转换等能力。\n 计算系统 计算系统提供一体化的数据采集、清洗、聚合与数据生命周期管理服务。计算系统内组件较多，可以分为服务层、计算层和采集层进行介绍。\n一、服务层\n tableapi 对外提供标准的数据服务接口；\n dimservice 为列式的元数据缓存服务中心。\n 二、计算层\n global-scheduler（gs） 为全局任务调度组件，负责对注册过来的 compute-space 计算集群进行生命周期管理，并基于配置生成任务拓扑，随后投递到计算集群。\n compute-space（cspace） 为一个抽象的计算能力资源池，负责对gs投递过来的任务拓扑进行解析执行以产出数据，写入存储系统，并将任务状态反馈给 gs ，cspace 并不与具体的数据计算资源池绑定，底层的实现可以是任意计算引擎。当前，一个 cspace 节点的实现为一个 spark 集群。\n三、采集层\n gaea-registry为整个采集侧的管控中心，它将采集配置下发给 agent 和 vessel ，同时也负责维护所有 agent 和 vessel 的健康状态与路由信息等。\n agent为部署在物理机上的采集服务进程，负责对日志、系统指标、事件等原始数据进行读取。\n vessel为数据清洗集群，负责拉群 agent 采集的原始数据进行结构化清洗，并以 rpc 形式返回给 cspace 。\n 告警系统 告警系统基于用户配置的告警规则对计算产出的指标数据进行巡检，产出告警事件并推送给订阅者。告警系统的组件与计算系统有些类似，包括：\n alarm-global-scheduler（alarm-gs）为告警调度组件；\n alarm-compute-space（alarm-cspace）为告警计算资源池；\n alarm-gateway 为告警推送网关。\n 如果将告警系统和计算系统进行类比的话，可以抽象地认为：告警的输入不是采集，而是计算系统产出的数据；告警的输出也不是存储系统，而是告警通知网关 alarm-gateway 。\n存储系统 存储系统（ceresdb）为 AntMonitor 提供时序数据的读写服务。\n ceresdbconsole 为可视化的运维管控组件；\n ceresmeta 为元数据管理组件，负责存储集群的主备切换、扩缩容等协调工作；\n ceresproxy 与 ceresbase 为部署在同一个容器内的两个伴随进程，其中 ceresproxy 为路由层，负责对查询或写入的数据进行汇总，并将结果返回给客户端，同时提供租户校验、流控、黑名单等能力；ceresbase 为数据存储节点，负责时序数据的存储、索引维护等功能。\n 稳定性建设 监控系统在整个蚂蚁的体系架构内是一个特殊的角色，它在承载所有业务系统的可观测与告警能力的同时，还为容量、自愈、故障应急等技术风险其他子域提供着数据服务。\n因此，监控对自身的稳定性要求更加严苛，在诸如大规模宕机、机房网络中断或更极端情况下，监控也需要保障自身是可以稳定运行的。\n针对蚂蚁智能监控自身的稳定性建设，我们主要从两方面进行推进，包括稳定性架构的设计与运行时的稳定性保障，整体如下图所示。\n 稳定性架构 稳定性架构是建设稳定性中最重要的一环，一个经过缜密设计的稳定性架构，可以使我们后期尽可能优雅从容地处理各类稳定性问题，而不是疲于奔命地打地鼠。\n具体来说，在设计稳定性架构之初，我们首先应该意识到系统的运行时环境和输入都不会是稳定的。\n运行时环境的不稳定 ，主要体现在机器的故障宕机、网络的抖动，或者更极端的机房光纤被挖断、城市自然灾害等客观因素影响。处理这类问题通常从两方面出发：\n第一、尽可能地提升系统的容灾等级。\n例如单点、机房级容灾、城市级容灾等，以最基础的去单点来说，我们需要保证所有的调度或同步类节点（例如 monitormeta、gs）都是基于主备架构的，所有的服务类节点（例如 monitorprod、tableapi）都是无状态的，所有的分片节点（例如 gaea-registry、ceresbase）都是存在冗余副本的，所有的工作类节点（例如 cspace、alarm-cspace），宕机后也都是可以自行恢复的。\n第二、所有的数据处理流程都应该面向失败进行设计。\n因为当故障发生后，可能某几个周期的任务已经失败，这时候需要有能力驱动这些任务进行重试，例如 cspace 需要有能力对某一个计算任务的采集失败进行容忍和重试、alarm-gs 需要对告警任务的执行失败进行重新调度等。\n针对系统输入的不确定性 ，我们也分两种情况进行处理：\n第一种情况是入口数据的错乱。\n例如脏配置、脏元数据、不合法的数据类型等，错误的数据流入系统可能会导致不可预期的行为，针对此类问题，我们通常需要在入口处进行校验，拒绝非预期的数据流入系统。\n第二种情况是入口数据量级管控。\n任何系统，其性能都是和容量挂钩的，其设计也都是在一定的性能容量平衡假设下进行的。监控系统的输入通常是业务日志，而且监控配置的定义是直面用户的，那么很可能一个随意定义的配置将导致海量的服务调用明细日志流入监控系统，导致集群崩溃，所以对流量的限制与管控非常重要。在 AntMonitor 中，各个关键的入口例如采集入口、计算入口、存储入口、数据查询入口等都有严格的流量管控校验规则，确保监控系统在预期容量下能够稳定运行，而不会被突发的流量所压垮。\n综上，我们将重点从容灾架构和架构单元化两方面出发来阐述 AntMonitor 稳定性架构的设计思路。\n容灾架构 前文简要提及了架构去单点问题的解决思路，这足以覆盖日常可能发生的节点宕机、网络抖动等小规模故障场景，但是当真正的毁灭性灾难来临时，还需要更高层面的容灾方案来应对。\n目前基于不同租户保障等级的区分以及资源配额等客观因素的权衡，AntMonitor 实施了两套不同等级的容灾策略，即针对常规业务域租户的机房级容灾和针对高保业务域租户的城市级容灾。\n机房级容灾 对于常规的业务域租 …","date":1630998000,"description":"蚂蚁智能监控","dir":"blog/ant-intelligent-monitoring/","fuzzywordcount":6700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3529d1b46b4e16c43414a1cd3e89fb02","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-intelligent-monitoring/","publishdate":"2021-09-07T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/ant-intelligent-monitoring/","summary":"AntMonitor简介 AntMonitor 是蚂蚁集团的智能监控系统，通过构建面向监控可观测数据的、实时的、稳定的采集、清洗、计算及存储数据链路，为技术风险大","tags":["SOFAStack"],"title":"蚂蚁智能监控","type":"blog","url":"/sofastack.tech/blog/ant-intelligent-monitoring/","wordcount":6622},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;ldquo;SOFA WEEKLY\u0026amp;rdquo; 的形式回复\n1、@黄润良 提问：\n 在写 filter 扩展的时候，如何获取一些请求的信息？比如请求 ip 之类的。\n A：*pkg/server/handler.go*，这里面可以看到设置进去的。\n MOSN：https://github.com/mosn/mosn\n2、@黄润良 提问：\n 一些 filter 只能用于某些协议的，但从配置来看，filter 应该是对所有协议都生效的吧？那我在设计 filter 的是需要考虑协议的兼容性吗？\n A：你配置的 listener 块里面有协议，就可以和 filter 对应上了。\n如果你怕别人误用，可以简单处理绕过。比如 dubbofilter 就是 Dubbo 协议自有的，怕其他协议误配置了，可以在代码跳过。\n MOSN：https://github.com/mosn/mosn\n3、@黄润良 提问：\n 目前有方法可以控制 filter 的执行的先后顺序吗？\n A：按照配置的顺序。\n 4、@楼政浩 提问： 往 raft 集群提交数据，都得通过 RPC 吗？ 如果我的 raft 节点的 fsm 又输出了 log，我想往集群提交这个 log，可以通过什么接口？\n A：jraft 通过 raft log 将数据复制到你各个节点的 fsm，fsm 的输入数据全部来自 raft log，你说的 fsm 又输出了 log 如果我没理解错的话，就是说本质上 fsm log 的输入全部来自 raft log，那么你这个所谓 log 就存在你自己的 fsm 就行，本来就是每个节点都会有的，不要再提交。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n5、@陈华洋 提问：\n SOFABoot 的模块化是怎么解决数据库链接的问题。 就是 SOFABoot 模块化之后，我把 mybatis 配置到了公共模块里面，然后其他模块父上下文指定为公共模块，但是其他模块内的 @Mapper 在项目启动的时候都扫描不到。\n A：建议把所有数据库相关的操作都放同一个模块，封装成 dal 层。可以配一个配置,让一个 spring 上下文里的 bean 暴露出来、能给别的 Spring 上下文用。\nSOFABoot：https://github.com/sofastack/sofa-boot\n6、@Z 提问：\n 请问在大数据量操作的时候，配置上有什么建议吗？\n A：把 6000 多条数据的操作在一个本地事务中完成，合并成一个分支注册。\nSeata：https://github.com/seata/seata\n7、@金箍 提问：\n 请问全局事务提交成功或者失败之后，有回调方法可以用吗？\n A：tm 有个 hook，其他没有。源码搜索「transactionlHook」有相关的文档。\nSeata：https://github.com/seata/seata\n8、@仪式 提问：\n 如果事务进行的过程中事务发起者（TM）宕机了，Seata 会怎么做故障处理呀。\n A：超时回滚，如果 TM 是决议提交给了 TC，那么“是”提交，“否”就只能等待超时回滚。TC 里的定时任务来做超时回滚。\nSeata：https://github.com/seata/seata\nSOFAStack \u0026amp;amp; MOSN：新手任务计划\n作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nSOFA-Boot\n设计实现一个新的配置项，用于判断 SOFA-Boot 是否由 IDE 启动。\nhttps://github.com/sofastack/sofa-boot/issues/861\nLayotto\n减少 panic 风险，给所有创建新协程的代码加上 recover。 设计实现 actuator metrics API，用于统计、展示 metrics 指标 WASM 通过 State API 访问存储：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n","date":1630652400,"description":"SOFA WEEKLY | QA 整理，新手计划","dir":"blog/sofa-weekly-20210903/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b8e03b60dc613f8a724cc3f95441bc2e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210903/","publishdate":"2021-09-03T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210903/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理，新手计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210903/","wordcount":1569},{"author":"SOFA 团队","categories":"SOFAStack","content":" 真的吗？真的吗？\nSOFA 志愿者开始招募啦？\n直视他！直视他！\nSOFA 星球在等你加入呀！\n我们正式启动“SOFA 星途者”计划\n只差一个你 即可成团出道\n不要感觉成团困难\n只要我们一起就能所向披靡\n谁是SOFA“星途者” SOFA 星途者是一群对开源宇宙感兴趣，希望在这片“宇宙”其中探索到更多“星辰”的人。SOFA 星途者们能够为千千万万的开发者们，提供丰富的 Meetup 及线上直播等交流平台。\n现在面向一切有理想、有追求的你们进行招募。\n“星”字代表 SOFA 星球，“途”代表在开源宇宙的征途。所以“星途”的意思即 SOFA 星球在开源宇宙的探索与征途。\n那么“星途者”就是加入 SOFA 星球的你们，让我们一起在开源宇宙中驰骋探索。\n“SOFA 星途者，探索开源宇宙中的星辰大海”\n即将进入，SOFA 社区 SOFAStack™（Scalable Open Financial Architecture Stack）是一套用于快速构建金融级云原生架构的中间件，也是在金融场景里锤炼出来的最佳实践，并且具备以下特点：\n开放：技术栈全面开源共建、 保持社区中立、兼容社区、兼容开源生态，组件可插拔， SOFAStack 组件与其它开源组件可相互集成或替换。\n金融级：包含构建金融级云原生架构所需的各个组件，让用户更加专注于业务开发，满足用户场景的现状和未来需求，经历过大规模场景的锤炼，特别是严苛的金融场景。\n云原生：基于 SOFAStack 可快速搭建云原生微服务体系，快速开发更具可靠性和扩展性、更加易于维护的云原生应用。\n开启 SOFA 征途 SOFA 陆续在全国各地组织了多场 Meetup 活动，活动全程直播，线上线下参与人数累计破万。Meetup 为 SOFA 星途者提供面对面沟通探讨的机会，收到了业界人士的一致好评。\n目前在北京、上海、杭州、合肥举办过 Meetup 活动，后续的还会点亮更多城市（成都、深圳、广州、南京等），欢迎你作为 SOFA 星途者加入我们的征途。\n杭州站\n 上海站\n 北京站\n 合肥站\n 召唤装备！ 在 SOFA 星球，大家不仅能够与每个领域的技术大牛面对面交流技术、认识新朋友，更能够收获 SOFA 星途者的周边衣服、杯子、双肩包等……\n最重要的是可以收获 SOFA 社区颁发的专属证书。\nSOFA 星途者的成员在参加 SOFA 的活动时可享受 VIP 通道，也会获得一些特大活动的 VIP 门票赠送～\n如果你是大学生“星途者”，那么你有可能会获得互联网大厂的实习推荐机会，在你感兴趣的星辰领域继续探索成长，有机会获得更多的学习机会。\n想成为一名“星途者”需要做些什么？\n扫描下方二维码\n 勇敢迈出成为“星途者”的第一步\n剩下的九十九步\n我们一起走\n","date":1630393200,"description":"SOFA 星球招募啦～","dir":"blog/sofa-star-is-recruiting/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d889b6b480fa6731f51805443e5ca5db","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-star-is-recruiting/","publishdate":"2021-08-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-star-is-recruiting/","summary":"真的吗？真的吗？ SOFA 志愿者开始招募啦？ 直视他！直视他！ SOFA 星球在等你加入呀！ 我们正式启动“SOFA 星途者”计划 只差一个你 即可成团出道 不要感觉成团","tags":["SOFAStack"],"title":"SOFA 星球招募啦～","type":"blog","url":"/sofastack.tech/blog/sofa-star-is-recruiting/","wordcount":960},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@胡希国 提问：\n 想和大家请教一下 MOSN 的热升级方案，就是我看到 MOSN 也是通过接收到 hup 信号然后 fork 的方式生成的一个新的子进程，（确切来说是 forkexec），和 Envoy 的解决方案应该是相同的，那为什么说和 Nginx 不一样呢？这种也是存在父子进程关系的吧（我看到 Envoy 是存在的），那为什么说没有继承 listenerfd 而需要通过 uds 来传递呢？\n A：Nginx reload 的过程是 master 不会退出，只是新 fork 了子进程。MOSN 是先启动一个 MOSN 进程，然后通过 socket 把 fd 继承过去之后，老的 MOSN 会退出。\nMOSN：https://github.com/mosn/mosn\n2、@鹏程万里 提问：\n FailureHandler 怎么实现自定义类呢？需要做回滚失败的通知。\n A：自己创建一个 Failurehandler bean return 一个实现类。\nSeata：https://github.com/seata/seata\n3、@随风 提问：\n 请问下，如果 A 方法和 B 方法上都有注解 GlobalTransactional，那么 A 方法可以直接调用 B 方法吗？\n A：可以的，用的还是一个 xid。\nSeata：https://github.com/seata/seata\n4、@zero 提问：\n 有分布式数据库了还需要用 Seata 吗？\n A：分布式数据库解决的是单个 connection 中每个 SQL 请求到了不同的库上的事务。一个分布式数据库背后可能有 N 个数据库被操作，内部用 xa 保证了事务。\nSeata：https://github.com/seata/seata\n本周发布 本周 SOFAJRaft 发布 1.3.8v版本。主要更新如下：\n Snapshot 支持并行压缩/解压缩，充分利用多核，加速在 snapshot 较大的时的 load 和 save 速度；\n CliService 提供 learner 到 follower 的转换 API；\n 修复 install snapshot retry 失败的 bug；\n 修复 RheaKV 在成员发生变更时没有刷新路由表的 bug。\n 详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.8\n新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nSOFA-Boot\n 发布服务时 增加 interfaceType 校验；\n 增加 SOFATracer 插件。\n 详见：\nhttps://github.com/sofastack/sofa-boot/issues/841\nLayotto\n 选择喜欢的组件实现分布式锁和分布式自增 id；\n 让 Layotto 能够简单方便的部署在 Kubernetes 上；\n 提供 Dockerfile，以便用户用 docker 部署 Layotto 。\n 详见：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1629442800,"description":"SOFA WEEKLY | SOFAJRaft 发布新版本,QA 整理","dir":"blog/sofa-weekly-20210820/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"60274ff33263cdb109e3d4342c35a45a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210820/","publishdate":"2021-08-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210820/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本,QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210820/","wordcount":1223},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#21：走进下一代互联网：HTTP/3\n 活动时间：08月18日,周三晚19点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#21：走进下一代互联网：HTTP/3 近年来，具备优秀基因的 QUIC 协议成为互联网领域炙手可热的传输技术。基于 QUIC 承载的 HTTP/2 也被正式命名为下一代传输协议： HTTP/3。这次直播会给大家介绍 QUIC，HTTP/3 的核心设计理念，以及在蚂蚁的应用实践。​\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 孔令涛（花名：伯琴） 蚂蚁集团技术专家，主要从事四七层协议优化，网关开发等工作。 议程 19:00-19:05 主持人开场 小助手-泡椒 主持人\n19:05-20:00 用安全计算保护关键业务 伯琴 蚂蚁集团技术专家，主要从事四七层协议优化，网关开发等工作。\n你将收获 你将了解 QUIC/HTTP/3 协议的前世今生、优良特性、落地实践、普及情况、与未来发展趋势等。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1629270000,"description":"8 月 18 日周三晚 19 点，线上直播第 21 期。","dir":"activities/sofa-channel-21-1/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b77dae9fff7d781959845f53872d0eee","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-21-1/","publishdate":"2021-08-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-21-1/","summary":"概要 活动主题：SOFAChannel#21：走进下一代互联网：HTTP/3 活动时间：08月18日,周三晚19点 活动形式：线上直播 资料下载：戳","tags":["SOFAChannel","HTTP/3"],"title":"SOFAChannel#21：走进下一代互联网：HTTP/3","type":"activities","url":"/sofastack.tech/activities/sofa-channel-21-1/","wordcount":588},{"author":"于雨","categories":"SOFAStack","content":" 个人有幸担任了 2021 年 GIAC 会议云原生专场的出品人兼讲师，组织了前后四个场子的演讲，在这个过程中个人同时作为听众从这些同行的演讲中学到了很多非常有用的知识。本文算是对 2021 GIAC 云原生专场的侧记，管中窥豹，以观 2021 年云原生技术发展现状及未来一段时间内的趋势。\n 云原生这个词含义广泛，涉及到资源的高效利用、交付、部署及运维等方方面面。从系统层次分可以区分出云原生基础设置【如存储、网络、管理平台 K8s】、云原生中间件、云原生应用架构以及云原生交付运维体系，本次专场的四个议题也基本涵盖了这四大方向：\n 亚马逊的资深技术专家黄帅的 《一个云原生服务的爆炸半径治理》 快手基础架构中心服务网格负责人姜涛的 《快手中间件 Mesh 化实践》 Tetrate 可观测性工程师柯振旭的 《使用 SkyWalking 监控 Kubernetes 事件》 本人以 Dubbogo 社区负责人出品的《Dubbogo 3.0：Dubbo 在云原生时代的基石》 下面根据个人现场笔记以及个人回忆分别记述各个议题的要点。因时间以及本人能力有限，一些错误难免，还请行家多多指正。\n云原生服务的爆炸半径 个人理解，黄的这个议题属于云原生应用架构范畴。\n其演讲内容首先从亚马逊 AWS 十年前的一个故障说开：AWS 某服务的配置中心是一个 CP 系统，一次人为的网络变更导致配置中心的冗余备份节点被打垮，当运维人员紧急恢复变更后，由于配置中心不可用【有效副本数少于一半】导致了整个存储系统其他数据节点认为配置数据一致性不正确拒绝服务，最终导致整个系统服务崩溃。\n复盘整个事故的直接原因是：CAP 定理对可用性和一致性的定义限定非常严格，并不适合应用于实际的生产系统。因此作为线上控制面的配置中心的数据应该在保证最终一致性的前提下，首先保证可用性。\n更进一步，现代分布式系统的人为操作错误、网络异常、软件 Bug、网络/存储/计算资源耗尽等都是不可避免的，分布式时代的设计人员一般都是通过各种冗余【如多存储分区、多服务副本】手段保证系统的可靠性，在不可靠的软硬件体系之上构建可靠的服务。\n但是这中间有一个误区：有时候一些冗余手段可能因为雪崩效应反而会导致系统可靠性地降低。如上面的事故，人为的配置错误导致了一连串的软件体系故障，且这些故障之间是高度强相关的，最终导致了雪崩效应，可以称之为 “水平扩展的毒药效应”。此时思考的维度就从 “在不可靠软硬件体系上提供可靠服务” 进一步拓展为 “通过各种隔离手段减小事故的爆炸半径”：当不可避免的故障发生时，尽量把故障损失控制到最小，保障在可接受范围内，保证服务可用。\n针对这个思路，黄给出了如下故障隔离手段：\n 服务粒度适中 微服务的服务粒度并不是拆分的越细越好。如果服务粒度过细，会导致服务数量过多，其第一个后果就是导致一个组织内几乎无人能搞清楚服务整体逻辑的来龙去脉，增加维护人员的负担：大家只敢小修小补无人敢做出大幅度的优化改进。\n服务粒度过细的第二个后果是造成整体微服务单元体指数级增加，造成容器编排部署成本上升。适中的服务粒度要兼顾架构体系的进化与部署成本的降低。\n 充分隔离 进行服务编排时，获取数据中心的电源和网络拓扑信息，保证强相关系统之间部署做到 “不远” 且 “不近”。\n“不近”是指同一个服务的副本不在使用同一个电源的同一个机柜部署，也不在使用了同一个网络平面的 Azone 内部署。“不远” 是指部署距离不能太远，例如多副本可以同城多 IDC 部署。使用这两个原则兼顾性能与系统可靠性。\n 随机分区 、所谓的随机分区这块，其实质就是在混合服务请求，保证某个服务的请求可以走多通道【队列】，保证在某些通道挂掉的情况下不影响某个服务的请求处理，应用随机分区技术，将用户打散在多个 Cell 中，大幅度降低爆炸半径。\n与 K8s APF 公平限流算法中的洗牌分片（Shuffle Sharding）颇为相似。\n 混沌工程 通过持续内化的混沌工程实践，提前踩雷，尽量减少 “故障点”，提升系统可靠性。\n使用 SkyWalking 监控 Kubernetes 事件 这个议题虽然被安排在第三场演讲，属于云原生交付运维体系，但是与上个议题关联性比较强，所以先在此记述。\n如何提升 K8s 系统的可观测性，一直是各大云平台的中心技术难题。K8s 系统可观测性的基础数据是 K8s event，这些事件包含了 Pod 等资源从请求到调度以及资源分配的全链路信息。\n SkyWalking 提供了 logging/metrics/tracing 等多维度可观测性能力，原来只是被用于观测微服务系统，今年提供了 skywalking-kubernetes-event-exporter 接口，专门用于监听 K8s 的 event，对事件进行提纯、收集、发送至 SkyWalking 后端进行分析和存储。\n 柯同学在演讲过程中花费了相当多的精力演讲整个系统的可视化效果如何丰富，个人感兴趣的点如下图所示：以类似于大数据流式编程的手段对 event 进行过滤分析。\n 其可视化效果与流式分析手段都是蚂蚁 Kubernetes 平台可借鉴的。\n快手中间件mesh化实践 快手的姜涛在这个议题中主要讲解了快手 Service Mesh 技术的实践。\n 姜把 Service Mesh 分为三个世代。其实划分标准有很多，如何划分都有道理。很明显，姜把 Dapr 划入了第三个世代。\n 上图是快手的 Service Mesh 架构图，很明显借鉴了 Dapr 的思想：下沉基础组件的能力到数据平面，把请求协议和接口标准化。一些具体的工作有：\n 1 统一运维，提高可观测性与稳定性，进行故障注入和流量录制等 2 对 Enovy 等做了二次开发，只传输变更的数据、按需获取，解决单实例服务数过多的问题 3 对协议栈和序列化协议做了大量的优化 4 实施了面向失败设计，Service Mesh 可以 fallback 为直连模式 个人感兴趣的是姜提到了 Service Mesh 技术在快手落地时面临的三个挑战：\n 成本问题：复杂环境下的统一部署与运维。 复杂度问题：规模大、性能要求高、策略复杂。 落地推广：对业务来说不是强需求。 特别是第三个挑战，Service Mesh 一般的直接收益方不在业务端，而是基础架构团队，所以对业务不是强需求，而且快手这种实时业务平台对性能非常敏感，Service Mesh 技术又不可避免地带来了延迟的增加。\n为了推动 Service Mesh 技术的落地，快手的解决手段是：\n 1 首先务必保证系统稳定性，不急于铺开业务量； 2 搭车公司重大项目，积极参与业务架构升级； 3 基于 WASM 扩展性，与业务共建； 4 选取典型落地场景，树立标杆项目。 姜在最后给出了快手下半年的 Service Mesh 工作：\n 很显然这个路线也是深受 Dapr 影响，理论或者架构上创新性不大，更侧重于对开源产品进行标准化并在快手落地。\n在演讲中姜提到了 Serivce Mesh 技术落地的两个标杆：蚂蚁集团和字节跳动。其实他们成功的很重要原因之一就是高层对先进技术的重视以及业务侧的大力配合。 …","date":1629183600,"description":"2021 年云原生技术发展现状及未来趋势","dir":"blog/2021-cloud-native-technology-development-status-and-future-trends/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ee44d71749f600f689656893c5b607af","permalink":"https://sofastack.github.io/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","publishdate":"2021-08-17T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","summary":"个人有幸担任了 2021 年 GIAC 会议云原生专场的出品人兼讲师，组织了前后四个场子的演讲，在这个过程中个人同时作为听众从这些同行的演讲中学到了很多非常有用","tags":["SOFAStack"],"title":"2021 年云原生技术发展现状及未来趋势","type":"blog","url":"/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","wordcount":3976},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙运盛 提问：\n 我想咨询大家一个问题，假如二阶段提交或者回滚的方法里，再发生异常的话，应该如何处理呢？\n A：这个异常后，重新捞取之前没结束的事务，重试就可以了吧，二阶段反正已经不阻塞其它一阶段的流程了。\nSeata：https://github.com/seata/seata\n2、@胡希国 提问：\n 我想请教一个问题，这里 New MOSN 收到 Old MOSN 传来的监听文件描述符之后，利用 filelistener 函数产生一个 listener 的作用是和 bind 一样么？就在 New MOSN 上开始监听了是吗？那这时候 Old MOSN 不也同时在监听么，这里的内部逻辑是什么样的？\n A：跟 bind 不一样，这儿是同一个 fd，两个进程都监听，常规操作。你可以想象成 Nginx 的多个进程都可以监听一个 listen 一样。\nMOSN：https://github.com/mosn/mosn\n3、@胡希国 提问：\n MOSN 的 forkexec 是个怎么样的方式呢？它也和 Envoy 一样有一个独立的 python（envoy）进程来负责产生新的 MOSN 进程么？\n A：MOSN 启动起来之后检查到有 socket 文件，然后和 Old MOSN 通信继承 fd，继承完了通知 Old MOSN 退出，所以你可以直接启动一个 MOSN 来。\nMOSN：https://github.com/mosn/mosn\n4、@胡希国 提问：\n 想请问下 MOSN 实现的过程为什么没有采用直接 fork 父进程的方式呢？\n A：容器间升级是不能 fork 的。\nMOSN：https://github.com/mosn/mosn\n5、@ch 提问：\n 今天发生了一个 rollback status: TimeoutRollbacking 超时问题。 描述: Seata 提示 rollback status: TimeoutRollbacking。 出现原因：全局事务在执行 order 库和 account 库，因为 account 库被 IO 堵死 导致业务超时执行了 70s。 然后 Seata 就报 timeout 导致 order 库回滚了数据 account 没有回滚数据（account 已经被 IO 流撑死,无法读写数据）。 版本：client 1.3.0 server 1.3.0。\n A：account 没有回滚诗句，tc 会重试。回滚事务，只要注册了的事务就一定能回滚，没注册的本地事务就会回滚，所以其实没有任何问题。\nSeata：https://github.com/seata/seata\nSOFAStack \u0026amp;amp; MOSN：新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发，但是不知道从何下手“的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing！\nLayotto 新手任务：\n 支持运行多个 Wasm 模块，以便让 Layotto 成为 FaaS 容器；\n 提供 Dockerfile，以便用户用 docker 部署 Layotto；\n 看懂 Wasm 模块的实现并为 Wasm 模块编写单元测试。\n 详见 ：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1628838000,"description":"SOFA Weekly | SOFAStack \u0026 MOSN：新手任务计划，QA 整理","dir":"blog/sofa-weekly-20210813/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"84929b0bd678bf23739507e3920d0293","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210813/","publishdate":"2021-08-13T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210813/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAStack \u0026 MOSN：新手任务计划，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210813/","wordcount":1357},{"author":"郑志雄（纶珥）","categories":"SOFAStack","content":" 背景 微服务架构带来很多好处的同时也让系统的复杂度提升了，传统的单体应用按照不同的维度拆分成一个一个分布式微服务，不同的微服务甚至可能采用不同的语言编写；此外，服务的部署往往都是分布式的，可能有几千台服务器，横跨多个不同的城市数据中心。下图是一个典型的微服务架构，图中的节点数还比较少，在支付宝，一个线下支付整体交易付款链路，涉及上百个节点。\n 图片来源：https://www.splunk.com/en_us/data-insider/what-is-distributed-tracing.html#benefits-of-distributed-tracing\n微服务化引入了以下几个典型问题：\n 故障定位难，一次请求往往需要涉及到多个服务，排查问题甚至需要拉上多个团队;\n 完整调用链路梳理难，节点调用关系分析;\n 性能分析难，性能短板节点.\n 以上这几个问题其实都是应用的可观测性问题：\n Log；\n Trace；\n Metrics。\n 本文将会专注于 Trace 方面，完整地说是分布式链路跟踪 (Distributed tracing)。2010 年谷歌发表了 Dapper 的论文，分享了他们的解决方案，算是业界比较早的分布式链路追踪系统。之后各大互联网公司纷纷参照 Dapper 的思想推出各自的链路跟踪系统，包括 Twitter 的 Zipkin、阿里的鹰眼，还有 PinPoint，Apache 的 HTrace 和 Uber 的 Jaeger；当然，也有我们的本文的主角：SOFATracer。分布式链路的实现有多种多样，因此也催生了分布式链路追踪的规范：OpenTracing，2019 年 OpenTracing 和 OpenCensus 合并成为了 OpenTelemetry。\nOpenTracing 在深入 SOFATracer 之前先简单解释一下 OpenTracing，因为 SOFATTracer 是基于 OpenTracing 规范（基于 0.22.0 的 OpenTracing，新版的规范 API 有所不同）构建的。一个 Trace 由服务调用生成的 Span 及其之间的引用构成，一个 Span 是一个时间跨度，一次服务调用创建一个新 Span，分为调用 Span 和被调 Span，每个 Span 包含：\n TraceId and SpanId\n 操作名称\n 耗时\n 服务调用结果\n 一个 Trace 链路中一般会有多个服务调用，那么也就会有多个 Span，Span 之间的关系由引用声明，引用从调用者指向服务提供者，OpenTracing 中指定了两个引用类型：\n ChildOf，同步服务调用，客户端需要服务端的结果返回才能进行后续处理；\n FollowsFrom，异步服务调用，客户端不等待服务端结果。\n 一个 Trace 是一个有向无环图，一次调用的拓扑可以如下展示：\n 图中的 SpanContext 是一次请求中会共享的数据，因此叫做 Span 上下文，一个服务节点在上下文中放入的数据对于后续的所有节点都可见，因此可以用来做信息传递。\nSOFATracer TraceId 生成 TraceId 收集一次请求中的所有服务节点。其生成规则需要避免不同 TraceId 之间的冲突，并且开销不能很高，毕竟 Trace 链路的生成是业务逻辑之外的额外开销。SOFATracer 中的 TraceId 生成规则是：服务器 IP + 产生 ID 时候的时间 + 自增序列 + 当前进程号，比如：\n0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，大家也可以根据这个规律来查找到请求经过的第一个服务器。 后面的 13 位 1403169275002 是产生 TraceId 的时间。 之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。 最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。\n 伪代码如下：\nTraceIdStr.append(ip).append(System.currentTimeMillis()) append(getNextId()).append(getPID()); SpanId 生成 SpanId 记录服务调用拓扑，在 SOFATracer 中：\n 点代表调用深度\n 数字代表调用顺序\n SpanId 由客户端创建\n SOFATracer 中 TraceId 和 SpanId 的生成规则参考了阿里的鹰眼组件\n 合并调用 Span 和被调 Span，结合 TraceId 和 SpanId 就能构建完整的服务调用拓扑：\n Trace 埋点 但是，我们如何生成并获取到 Trace 数据呢？这就得 Trace 采集器（Instrumentation Framework）登场了，其负责：\n Trace 数据的生成、传递和上报\n Trace 上下文的解析和注入\n 并且 Trace 采集器还要做到自动、低侵入和低开销等。典型的 Trace 采集器结构如下，其在业务逻辑之前埋点：\n Server Received (SR), 创建一个新的父 Span 或者从上下文中提取\n 调用业务代码\n 业务代码再次发起远程服务调用\n Client Send (CS) 创建一个子 Span，传递 TraceId、SpanId 和透传数据\n Client Received (CR), 结束当前子 Span，记录/上报 Span\n Server Send (SS) 结束父 Span，记录/上报 Span\n 步骤 3-5 可能没有，也可能重复多次。\n埋点逻辑的实现多种多样，目前主流的有如下几种方式：\n Filter，请求过滤器 (dubbo, SOFARPC, Spring MVC)\n AOP 切面 (DataSource, Redis, MongoDB)\n a.Proxy\nb.ByteCode generating\n Hook 机制 (Spring Message, RocketMQ) Java 语言中，SkyWalking 和 PinPoint 都使用 javaagent 方式做到自动、无侵入埋点。典型的，SOFATracer 实现 Spring MVC 的 Trace 埋点如下：\n SOFATracer 的 Span 100% 创建，只是 log/report 支持采样，相对来说，log/report 的 overhead 更高，更容易在大流量/负载下成为性能瓶颈。而其他 Trace 系统，Span 是采样生成的，但为了在调用出错的情况下能 100% 有 Trace，他们采用了逆向采样的策略。\nSOFATracer 默认把 Trace …","date":1628578800,"description":"蚂蚁集团 SOFATracer 原理与实践","dir":"blog/ant-group-sofatracer-principles-and-practices/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"235d67352aa5a94ae53bf00b4e8c1730","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","publishdate":"2021-08-10T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","summary":"背景 微服务架构带来很多好处的同时也让系统的复杂度提升了，传统的单体应用按照不同的维度拆分成一个一个分布式微服务，不同的微服务甚至可能采用不同","tags":["SOFAStack"],"title":"蚂蚁集团 SOFATracer 原理与实践","type":"blog","url":"/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","wordcount":3268},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定 时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@非余 提问：\n 我有个需求，就是我们有自己的配置中心，我的配置加载不想用默认的文件配置，这里如果我要开发的话应该怎么样加会比较漂亮？\n A：把 config.Load 重写成你自己的配置解析，configmanager.RegisterConfigLoadFunc。\nMOSN：https://github.com/mosn/mosn\n@飒 提问：\n 一个方法先 insert 而后另一个方法 update 事物回滚失败怎么解决？\n A：不会，可能你没有保证写函数被 @GlobalTransactional 注解覆盖或建表语句不是最新的导致了你回滚顺序变了。\nSeata：https://github.com/seata/seata\n@飒 提问：\n A 服务使用了 @GlobalTransactional（rollbackFor = Exception.class），调用了 B 服务，B 服务报错了，结果都提交成功，数据库数据也更新了，一般是什么原因？\n A：应该是你被调用的服务，没有加入到全局事务中去（也就是说，被调用的服务没加上 @GlobalTransactional）。\nSeata：https://github.com/seata/seata\n@冯仁彬 提问：\n 被调用的服务也必须添加 @GlobalTransactional?\n A：被调用的服务如果自身不会有任何地方访问自己身的写库方法，那么仅需集成 Seata，如果自身有，那么自身的写库操作全部要被带有 @GlobalTransactional 注解的地方调用，至于这个入库你自己设计。\nSeata：https://github.com/seata/seata\n本周推荐阅读 KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周发布详情如下：\n本周 MOSN 发布了 v0.24.0 版本。主要更新如下：\n 支持 jaeger tracing；\n grpc 框架支持热升级；\n 变量机制支持 interface 类型的变量；\n 路由模块优化，支持端口匹配、支持变量模式；\n 负载均衡模块多处优化；\n 其他优化与 Bug Fix。\n 详细发布报告：https://github.com/mosn/mosn/releases/tag/v0.24.0\n更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1628233200,"description":"SOFA WEEKLY | MOSN 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210806/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"29e513237a11de947612fdc004f8ddde","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210806/","publishdate":"2021-08-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210806/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210806/","wordcount":1125},{"author":"柴树杉","categories":"SOFAStack","content":" 楔子: 以蚂蚁典型的建站场景为例，在接入 Kusion 后，用户侧配置代码减少到 5.5%，用户面对的 4 个平台通过接入统一代码库而消减，在无其他异常的情况下交付时间从 2 天下降到 2 小时……\n注：本文是柴树杉在 2021 GIAC 大会上分享的内容。相关 PPT 内容请点击下方自行下载\n GIAC 大会 PPT 下载：KCL声明式的云原生配置策略语言 \n0. 你好GIAC 大家好，我是来自蚂蚁的同学，很高兴能在GIAC的编程语言新范式板块和大家分享《KCL配置策略语言》。KCL语言是蚂蚁内部的Kusion解决方案中针对云原生基础设施配置代码化自研的DSL语言，目前已经在建站场景等一些场景开始小范围推广试用。\n我们先看一下简单的KCL代码：\nschema GIACInvitation[name: str]: Name: str = name Topic: str = \u0026amp;quot;分享主题\u0026amp;quot; Company?: str = None Type: str = \u0026amp;quot;分享嘉宾\u0026amp;quot; Address: str = \u0026amp;quot;深圳\u0026amp;quot; invitation = GIACInvitation(\u0026amp;quot;姓名\u0026amp;quot;) { Topic: \u0026amp;quot;KCL配置策略语言\u0026amp;quot; Company: \u0026amp;quot;蚂蚁集团\u0026amp;quot; } 这个例子代码先通过 schema 定义了一个 GIACInvitation 结构体：该结构体有一个 str 类型的 name 参数，同时还有一组标注了类型和默认值的属性。然后通过声明式的语法构造了GIACInvitation 的实例 invitation。\n这个例子虽然简单，但是包含了 KCL 最重要的 schema 语言结构。从例子可以看出 KCL 尝试通过声明式的语法、静态类型检查特性来改进配置代码的编写和维护工作。这也是设计 KCL 语言的初衷，我们希望通过编程领域成熟的技术理论来解决云原生领域的配置代码化的问题。\n1. KCL语言的诞生背景 在经典的 Linux/UNIX 操作系统中，我们通过 Shell 和系统内置的各种工具和内核进行交互，同时通过 Shell 脚本来管理更上层的 App。可以说 Shell 语言极大地简化了内核的编程界面，不仅仅提升了操作系统易用性也简化了上层 App 的管理和运维，也提高了生产效率。而 Kubernetes 作为容器管理领域的事实标准，已经成为云计算时代的Linux/UNIX。类比 UNIX 系统，Kubernetes 目前还缺少一种符合其声明式、开放、共享设计理念的交互语言及工具。\n 1.1 为何要设计KCL语言？ K8s已经成为云计算的操作系统，但是目前尚缺少功能完备的SHELL交互界面。目前虽然有很多而且开源方案，但是还没有像UNIX的Shell那种出现比较成熟的方案，特别是尚无法满足头部互联网企业大规模工程化的要求。云原生技术与企业落地之间存在Gap需要填补，这正是云原生工程化要解决的问题，也是设计KCL语言的出发点。\n1.2 目前是一个好时机 云原生的思路是高度的开放化和民主化，结果就是万物可配置，一切配置都是代码。带配置代码面前人人平等，每个用户都可以通过调整配置代码和基础平台设施进行交互。因此对配置的编写和维护正在成为云计算时代软件工程师的必备的技能和需求。基于对云原生配置代码化需求的日益旺盛，硅谷的诸多头部公司已经对这个方向进行了大规模的实践和验证，这些都给了我们大量可以参考的经验。\n因此蚂蚁的 Kusion 项目尝试通过 KCL 配置策略语言正是为了简化云原生技术设施的接入方式设计，其设计目标不仅仅是为了提升蚂蚁基础设施的开放程度及使用效率，同时希望能够优化共享、协同的开发流程，可以说其定位正是云原生时代的 Shell 语言。虽然目前还处于探索和实践阶段，我们通过此文和大家分享下 KCL 语言的设计与实现的一些理念，为云原生的快速到来贡献一点绵薄之力。\n1.3 KCL诞生历史 KCL 语言从2019年开始初期的调研和设计工作。到2020年3月发布kcl-0.1，基于Python定制语法，采用Go版本的Grumpy和AntLR等工具开发。2020年下半年改用Python语言并加快了开发和迭代速度，发布的kcl-0.2.x引入了大量语言特性、增加了Plugin扩展支持、同时支持IDEA插件。2021年上半年开始统一优化和整合语言特性，发布的kcl-0.3优化类型系统、集成单元测试工具、优化执行性能并提供了Go等多语言的API支持、同时通过LSP为VSCode提供支持。2021年下半年开始在建站等常见落地，同时引入静态类型检查和优化性能，完善语言的文档支持。\n2. KCL语言的设计原则 基于蚂蚁践行多年的经典运维中台沉淀的经验和对各种问题利弊的思考，Kusion 项目对如何充分利用云原生技术带来的红利，打造一个开放、透明、声明式、可协同的运维体系进行了探索和思考，提出并实践了基于基础设施代码化的云原生协同开发的模型。而 KCL 语言正是 Kusion 项目为了解决云原生协同开发而设计的声明式的配置编程语言，简单、稳定、高效和工程化是 KCL 语言设计的设计理念。\n 2.1 简单为王 简单不仅仅可以降低学习和沟通的成本，而且可以减少代码出问题的风险。不论是 UNIX 奉行的 KISS 原则还是 Go语言推崇的 Less is more 设计理念，简化易用的界面始终是各种成功产品追求的一个目标。同样从简单原则出发，KCL 语言在参考现代编程语言之上只保留了必要的元素，同时通过类型自动推导、引入受限的控制流和 schema 提供了基础灵活的配置定义编写能力，删减语言特性始终是 KCL 语言设计工作的一个重要目标。\n2.1.1 声明式语法 声明式编程是和命令式编程并列的一种编程范式，声明式编程只告诉你想要的结果，执行引擎负责执行的过程。声明式编程使用更加简单，可以降低命令式拼装造成的复杂性和副作用，保持配置代码清晰可读，而复杂的执行逻辑已经由 Kubernetes 系统提供支持。KCL 语言通过简化对 schema 结构体实例化的语法结构对声明式语法提供支持，通过仅提供少量的语句来减少命令过程式编程带来的复杂性。 围绕 schema 和配置相关的语法，KCL 希望每种配置需求尽可能通过固定的写法完成，使得配置代码尽可能的统一化。\n比如作为 KCL 声明式语法的核心结构 schema 可以采用声明式方式实例化：\nschema Name: firstName: str lastName: str schema Person: name: Name = { firstName: \u0026amp;quot;John\u0026amp;quot; lastName: \u0026amp;quot;default\u0026amp;quot; } JohnDoe = Person { name.lastName: \u0026amp;quot;Doe\u0026amp;quot; } 首先通过schema定义了一个 Name 结构，结构包含2个字符串类型的必填属性。然后在 Person 中复用 Name 类型声明一个name属性，并且给name属性设置了默认值以简化用户使用。最终 …","date":1627974000,"description":"KCL：声明式的云原生配置策略语言","dir":"blog/kcl-a-declarative-cloud-native-configuration-policy-language/","fuzzywordcount":8200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"30b5034f7ce40b32a13a09cfe141b101","permalink":"https://sofastack.github.io/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","publishdate":"2021-08-03T15:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","summary":"楔子: 以蚂蚁典型的建站场景为例，在接入 Kusion 后，用户侧配置代码减少到 5.5%，用户面对的 4 个平台通过接入统一代码库而消减，在无其他异常的情况下交","tags":["SOFAStack"],"title":"KCL：声明式的云原生配置策略语言","type":"blog","url":"/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","wordcount":8120},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张鹏 提问：\n 比如我在新模块中添加 Service 实现，宿主应用没有调用相关的 Service 啊，我其实想实现代码的热部署通过 SOFAArk 可以？\n A：可以动态部署的（所有的 bean 会刷新，服务会发布），跟宿主应用有没有调用没有关系的。\nSOFAArk：https://github.com/sofastack/sofa-ark\n2、@周永平 提问：\n 我想请教下，SOFABoot 如果使用 Spring 的 event，跨模块会被通知到吗？\n A：默认情况下，Spring 事件只在本模块中，不会传递的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@孙力 提问：\n 蚂蚁内部与 MOSN 对应的应该是有统一的控制面吗？其中熔断限流组件是使用的 sentinel 吗？控制面与 MOSN 中的 sentinel-client 对接更新限流规则，使用的 sentienl 的 dynamic-rule，还是 xds 下发的？\n A：我们内部是有统一的控制面的，我们的限流熔断算法是基于 sentinel 去扩展实现的，底层的限流框架是基于 sentinel 的，更新规则时我们用的是我们内部的一套配置管理中间件。\nMOSN：https://github.com/mosn/mosn\n4、@孟晓冬 提问：\n 目前的问题是，Dubbo 应用在注入 MOSN 时，MOSN 启动时，要么报权限问题，要么报各种 not support，想请教一下是什么原因？\n A：你用的 1.7.x 的 Istio 的话，那要用对应分支的 MOSN 版本镜像。\nMOSN：https://github.com/mosn/mosn\n本周发布 本周 Layotto 发布了 v0.1.0\n这是 Layotto 的第一次发布，包含功能：\n 支持 configuration API\n 支持 pubsub API\n 支持 state API\n 支持 distributed lock API\n 支持 sequencer API\n 支持 rpc API\n 支持通过 4 层或者 7 层进行流量治理（例如 dump 流量,限流等功能)\n 支持 Actuator API，用于健康检查和运行时元数据查询\n 支持集成 Istio\n 支持基于 WASM 进行多语言编程\n Go sdk\n 感谢各位贡献者这段时间的付出！\n详细参考：https://github.com/mosn/layotto/\n文章解读： https://mosn.io/layotto/#/zh/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/index\n本周 SOFABoot 发布了 3.8.0 版本。主要更新如下：\n 支持 JDK11\n 添加 proxyBeanMethods=false 字段在 @Configuration 类上\n 调整 SOFARPC 注解的超时优先级\n 修复 Ark 环境处理注解时抛出 TypeNotPresentExceptionProxy 异常的问题\n 详细参考： https://github.com/sofastack/sofa-boot\n本周推荐阅读 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 还在为多集群管理烦恼吗？OCM来啦！\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1627628400,"description":"SOFA Weekly | Layotto、SOFABoot 发布新版本、QA 整理","dir":"blog/sofa-weekly-20210730/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa875b307e883aea56f46eab071f52d0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210730/","publishdate":"2021-07-30T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210730/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto、SOFABoot 发布新版本、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210730/","wordcount":1199},{"author":"祝辰（忘禅）","categories":"SOFAStack","content":" 开篇 这篇文章是基于SOFA Meetup合肥站的分享总结，主要针对于注册中心的定位以及功能介绍，通过对蚂蚁注册中心发展史的分析，带领大家了解，蚂蚁的注册中心是如何一步一步演变为现在的规模和特性的。\n更多深入的技术细节，欢迎大家加入到SOFA和SOFARegistry的社区中，探寻结果。\n注册中心是什么 服务发现 \u0026amp;amp; 服务注册 注册中心简单来说，是为了解决分布式场景下，服务之间互相发现的问题。\n如下图所示，服务A想要调用服务B的时候，需要知道B的地址在哪里，如何解决这个问题？\n 一般来说，分为两个点：\n 服务发现可以有一个中心化的组件或者说是存储，它承载了所有服务的地址，同时提供出来一个可供查询和订阅的能力，服务的消费方可以通过和这个中心化的存储交互，获取服务提供方的地址列表。 服务注册：同样是上文中中心化的组件，但是，这个时候的服务信息可以有两种措施 服务连接注册中心，同时上报自身的服务以及元数据（也是今天本文讲述的重点） 有一个集中的控制面（control plane）将用户定义的服务和IP的映射写入注册中心，例如AWS的CloudMap 调用流程 如上图所示，就是目前一种主流的注册中心模式，SOFARegistry和Nacos都是这种模式。\n 服务A，服务B通过SDK或者REST将自身的服务信息上报给注册中心 服务A需要调用服务B的时候，就对注册中心发起请求，拉取和服务B相关的服务IP列表以及信息 在获取到服务B的列表之后，就可以通过自身定义的负载均衡算法访问服务B 心跳 心跳是注册中心用于解决服务不可用时，及时拉出服务降低影响的默认方式，如下图所示\n 服务B的一个节点断网或是hang住，引发心跳超时；或是宕机、断链直接引发心跳失败 注册中心把问题节点从自身的存储中拉出（这里拉出根据具体实现：有的是直接删除，有的是标记为不健康） 服务A收到注册中心的通知，获取到服务B最新的列表 DUBBO 注册中心 下面通过DUBBO的例子，我们来看一下注册中心是如何使用的，以及流程\n首先，DUBBO在2.7和3.0中的配置略有不同，但是都是简单易懂的，这里都放上来\nDUBBO-2.7\n DUBBO-3.0\n 在RPC客户端只需要配置一个注册中心的地址即可，地址中包含了基础三元素\n protocol（协议类型）比如，zookeeper host port 基于此，dubbo的注册流程如下图所示\n 服务的生产方通过DUBBO客户端向注册中心（Registry）发起注册行为（register） 服务的消费方通过DUBBO客户端订阅信息（subscribe） 注册中心通过通知的方式，下发服务列表给服务消费方 注册中心的本质 通过前文的讲解，以及DUBBO组件的具体例子，我们大概可以归纳注册中心的本质\n“存储” + “可运维”\n 一方面，注册中心需要存储能力去记录服务的信息，比如应用列表 另一方面，注册中心在实践过程中，需要提供必需的运维手段，比如关闭某一服务流量 蚂蚁注册中心编年史 史前时代 史前时代的蚂蚁是相当久远的架构，当时所有的服务部署在同一台物理机上或者JVM上，服务之间不存在有跨机器调用的场景，这里略过不表\n 硬负载时代 后来，为了解决应用之间的耦合带来的部署难，运维难问题，我们对服务进行了拆分，拆分后的服务，遇到了一个问题，就是如何处理服务之间的调用关系，这个时候，蚂蚁用了两种硬负载 F5 或是 LVS。\n通过简单的4层代理，我们可以把服务部署在代理的后面，服务与服务之间通过代理互相访问，达到了跨机调用的目的\n 第一代注册中心 \u0026amp;ndash; 硬负载到软负载的演变 通过硬负载访问的方式，一方面解决了服务之间互相调用的问题，部署架构也简单易懂；另一方面，在业务快速增长之后，却带来了一定的问题：\n 单点的问题（所有调用都走F5的话，F5一旦挂了，很多服务会不可用） 容量问题（F5承载的流量太高，本身会到一个性能瓶颈） 这个时候，蚂蚁引进了阿里集团的一款产品叫ConfigServer，作为注册中心进行使用，这个注册中心的架构就和开头提到的架构很像了，服务之间可以通过IP直接访问，而降低了对负载均衡产品的强依赖，减少了单点风险。\n 第二代注册中心 \u0026amp;ndash; ScaleUp？ScaleOut？It\u0026amp;rsquo;s a problem 但是，问题还在持续，那就是注册中心，本身是一个单点，那么，他就会继续遇到上文中所说的两个问题\n 单点风险（注册中心本身是单机应用） 容量瓶颈（单台注册中心的连接数和存储数据的容量是有限的） 解决的方式有两种\n scale-up（淘宝）：通过增加机器的配置，来增强容量以及扛链接能力；同时，通过主-备这样的架构，来保障可用性 scale-out（蚂蚁）：通过分片机制，将数据和链接均匀分布在多个节点上，做到水平拓展；通过分片之后的备份，做到高可用 蚂蚁和淘宝走了两条不同的路，也推进了蚂蚁后面演进出一套独立的生态系统\n蚂蚁的演进架构如下，产生了两种不同的应用节点\n session节点，专门用来抗链接使用，本身无状态可以快速扩展，单机对资源的占用很小 data节点，专门用来存储数据，通过分片的方式降低单个节点的存储量，控制资源占用 第五代注册中心 \u0026amp;ndash; Meta节点的诞生 上面的架构已经很符合目前主流的分布式架构了，但是在运维过程中，产生了一系列问题，比如\n 所有data都是分布式的，data之间的服务发现需要通过启动时给定一个配置文件，这样就和标准运维脱钩 data节点的上下线需要去及时修改配置文件，否则集群重启会受到影响 分布式存储一致性问题，每次迭代发布，需要锁定paas平台，防止节点变动带来的不一致 所有这些问题的产生，我们发现可以引入一个元数据管理中心（Meta）节点来，解决对data和session管理的问题，data和session通过4层负载或是7层负载对meta访问即可.\n对比业界的解决方案，都有类似的模型，比如HDFS的Name Node、Kafka依赖于ZK，Oceanbase依赖于RootServer 或者 配置中心Apollo依赖于Euraka。\nMeta节点的出现，缓解了手工运维注册中心的瓶颈，但是，依然没有从根本上解决问题，那么问题在哪里？详见下文分析。\n 第六代注册中心 \u0026amp;ndash; 面向运维的注册中心 上文说道，Meta节点的出现，承接了Data以及Session之间服务发现的问题，但是，丛云未测来讲，还是有很多问题解决不了，比如\n Data节点的发布在数据量大的前提下，依然是个痛点 Session节点的新加节点上，可能很久都没有流量 等等，对于这些问题，在SOFARegistry5.x的基础上，我们快速迭代了6.0版本，主要是面向运维的注册中心。\nData节点发布难的问题，说到底是一个影响范围的问题，如何控制单一data节点发布或者挂掉对数据的影响面，是解决问题的本源，这里我们采用了两个措施\n 改进数据存储算法（consistent-hash -\u0026amp;gt; hash-slot） 应用级服务发现 存储算法的演进 之前我们使用了一致性hash的算法，如下图所示， …","date":1627369200,"description":"我们做出了一个分布式注册中心","dir":"blog/we-made-a-distributed-registry/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"991c52c34e8dc2370ae08263b297cbe0","permalink":"https://sofastack.github.io/sofastack.tech/blog/we-made-a-distributed-registry/","publishdate":"2021-07-27T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/we-made-a-distributed-registry/","summary":"开篇 这篇文章是基于SOFA Meetup合肥站的分享总结，主要针对于注册中心的定位以及功能介绍，通过对蚂蚁注册中心发展史的分析，带领大家了解，","tags":["SOFAStack"],"title":"我们做出了一个分布式注册中心","type":"blog","url":"/sofastack.tech/blog/we-made-a-distributed-registry/","wordcount":4390},{"author":"","categories":"SOFAStack","content":" 蚂蚁集团运维着可能是全球最大的 K8s 集群：K8s 官方以 5k node 作为 K8s 规模化的顶峰，而蚂蚁集团事实上运维着规模达到 10k node 规模的 K8s 集群。一个形象的比喻就是，如果官方以及跟着官方的 K8s 使用者能想象到的 K8s 的集群规模是泰山，那么蚂蚁集团在官方的解决方案之上已经实现了一个珠穆朗玛峰，引领了 K8s 规模化技术的提升。\n这个量级的差异，不仅仅是量的差异，更是 K8s 管理维护的质的提升。能维护有如此巨大挑战巨量规模的 K8s 集群，其背后原因是蚂蚁集团付出了远大于 K8s 官方的优化努力。\n所谓万丈高楼平地起，本文着重讨论下蚂蚁集团的在 K8s 的基石 \u0026amp;mdash; etcd 层面做出的高可用建设工作：只有 etcd 这个基石稳当了，K8s 这栋高楼大厦才保持稳定性，有 tidb 大佬黄东旭朋友圈佐证【图片已获黄总授权】。\n 面临的挑战 etcd 首先是 K8s 集群的 KV 数据库。 从数据库的角度来看，K8s 整体集群架构各个角色如下：\n etcd 集群的数据库\n kube-apiserver etcd 的 API 接口代理、数据缓存层\n kubelet 数据的生产者和消费者\n kube-controller-manager 数据的消费者和生产者\n kube-scheduler 数据的消费者和生产者\n etcd 本质是一个 KV 数据库，存储了 K8s 自身资源 、用户自定义的 CRD 以及 K8s 系统的 event 等数据。每种数据的一致性和数据安全性要求不一致，如 event 数据的安全性小于 K8s 自身的资源数据以及 CRD 数据。\nK8s 的早期拥护者在推广 K8s 时，宣称其比 OpenStack 的优势之一是 K8s 没有使用消息队列，其延迟比 OpenStack 低。这其实是一个误解，无论是 etcd 提供的 watch 接口，还是 K8s client 包中的 informer 机制，无不表明 K8s 是把 etcd 当做了消息队列，K8s 消息的载体很多，譬如 K8s event。\n从消息队列的角度来看，K8s 整体集群架构各个角色如下：\n etcd 消息路由器\n kube-apiserver etcd 生产者消息代理和消息广播【或者成为次级消息路由器、消费者代理】\n kubelet 消息的生产者和消费者\n kube-controller-manager 消息的消费者和生产者\n kube-scheduler 消息的消费者和生产者\n etcd 是推模式的消息队列。etcd 是 K8s 集群的 KV 数据库和消息路由器，充当了 OpenStack 集群中的 MySQL 和 MQ 两个角色，这样的实现貌似简化了集群的结构，但其实不然。在 large scale 规模 K8s 集群中，一般经验，首先都会使用一个单独 etcd 集群存储 event 数据：把 KV 数据和一部分 MQ 数据物理隔离开，实现了 KV 和 MQ 角色的部分分离。 如 参考文档 2 中提到美团 “针对 etcd 的运营，通过拆分出独立的 event 集群降低主库的压力”。\n当 K8s 集群规模扩大时，etcd 承载着 KV 数据剧增、event 消息暴增以及消息写放大的三种压力。 为了证明所言非虚，特引用部分数据为佐证：\n etcd KV 数据量级在 100 万以上；\n etcd event 数据量在 10 万以上；\n etcd 读流量压力峰值在 30 万 pqm 以上，其中读 event 在 10k qpm 以上；\n etcd 写流量压力峰值在 20 万 pqm 以上，其中写 event 在 15k qpm 以上；\n etcd CPU 经常性飙升到 900% 以上；\n etcd 内存 RSS 在 60 GiB 以上；\n etcd 磁盘使用量可达 100 GiB 以上；\n etcd 自身的 goroutine 数量 9k 以上；\n etcd 使用的用户态线程达 1.6k 以上；\n etcd gc 单次耗时常态下可达 15ms。\n 使用 Go 语言实现的 etcd 管理这些数据非常吃力，无论是 CPU、内存、gc、goroutine 数量还是线程使用量，基本上都接近 go runtime 管理能力极限：经常在 CPU profile 中观测到 go runtime 和 gc 占用资源超过 50% 以上。\n蚂蚁的 K8s 集群在经历高可用项目维护之前，当集群规模突破 7 千节点规模时，曾出现如下性能瓶颈问题：\n etcd 出现大量的读写延迟，延迟甚至可达分钟级；\n kube-apiserver 查询 pods / nodes / configmap / crd 延时很高，导致 etcd oom；\n etcd list-all pods 时长可达 30 分钟以上；\n 2020 年 etcd 集群曾因 list-all 压力被打垮导致的事故就达好几起；\n 控制器无法及时感知数据变化，如出现 watch 数据延迟可达 30s 以上。\n 如果说这种状况下的 etcd 集群是在刀锋上跳舞， 此时的整个 K8s 集群就是一个活火山：稍不留神就有可能背个 P 级故障， 彼时的整个 K8s master 运维工作大概是整个蚂蚁集团最危险的工种之一。\n高可用策略 实现一个分布式系统高可用能力的提升，大概有如下手段：\n 提升自身稳定性与性能；\n 精细管理上游流量；\n 保证服务下游服务 SLO。\n etcd 经过社区与各方使用者这么多年的锤炼，其自身的稳定性足够。蚂蚁人能做到的，无非是使出周扒皮的本事，提高集群资源整体利用率，scale out 和 scale up 两种技术手段双管齐下，尽可能的提升其性能。\netcd 自身作为 K8s 的基石，其并无下游服务。如果说有，那也是其自身所使用的物理 node 环境了。下面分别从 etcd 集群性能提升、请求流量管理等角度阐述我们在 etcd 层面所做出的高可用能力提升工作。\n文件系统升级 在山窝里飞出金凤凰，诚非易事。让 etcd 跑的更快这件事，没有什么手段比提供一个高性能的机器更短平快地见效了。\n1.使用 NVMe ssd etcd 自身 = etcd 程序 + 其运行环境。早期 etcd 服务器使用的磁盘是 SATA 盘，经过简单地测试发现 etcd 读磁盘速率非常慢，老板豪横地把机器鸟枪换炮 \u0026amp;mdash; 升级到使用了 NVMe SSD 的 f53 规格的机器：etcd 使用 NVMe ssd 存储 boltdb 数据后，随机写速率可提升到 70 MiB/s 以上。\n参考文档 2 中提到美团 “基于高配的 SSD 物理机器部署可以达到日常 5 倍的高流量访问”，可见提升硬件性能是大厂的首选，能折腾机器千万别浪费人力。\n2.使用 tmpfs NVMe ssd 虽好，理论上其读写极限性能跟内存比还是差一个数量级。我们测试发现使用 tmpfs【未禁止 swap out】替换 NVMe ssd 后，etcd 在读写并发的情况下性能仍然能提升 20% 之多。考察 K8s 各种数据类型的特点后，考虑到 event …","date":1627282800,"description":"蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路","dir":"blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"49c1cbed799517497d7760e5717c5843","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","publishdate":"2021-07-26T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","summary":"蚂蚁集团运维着可能是全球最大的 K8s 集群：K8s 官方以 5k node 作为 K8s 规模化的顶峰，而蚂蚁集团事实上运维着规模达到 10k node 规模的 K8s 集群。一个形象的比喻就是","tags":["SOFAStack"],"title":"蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路","type":"blog","url":"/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","wordcount":7144},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践\n 活动时间：2021 年 07 月 24 日（周六）13:30-17:30\n 活动地点：合肥高新区创新产业园D8栋一楼集思空间\n 活动形式：线下活动\n 资料下载： 《蚂蚁注册中心 SOFARegistry 分享》 《基于API 网关的微服务治理演进与架构实践》 《蚂蚁集团分布式链路组件 SOFATracer 原理与实践》 《准实时的日志聚合平台》 《Service Mesh在蚂蚁集团的实践》\n 本次分享涉及的项目地址\n sofa-registry开箱即用计划 https://github.com/sofastack/sofa-registry/projects/5\nsofa-registry深度解析计划 https://github.com/sofastack/sofa-registry/projects/4\n(这两个计划想帮助对参与开源项目感兴趣的同学由浅入深的上手，成为社区的一员)\nsofa-tracer https://github.com/sofastack/sofa-tracer\nmosn https://github.com/mosn/mosn\n活动介绍 活动议程 本期议题以及嘉宾详解 《蚂蚁注册中心 SOFARegistry 分享》\n嘉宾介绍\n祝辰（花名忘禅），蚂蚁集团技术专家，2020年加入蚂蚁集团致力于服务发现领域的技术建设，开源项目sofa-registry、x-pipe核心开发人员。\n议题简介\n大规模微服务场景下的注册中心：SOFARegistry v6 新特性介绍 SOFARegistry 是蚂蚁集团内部在使用的服务注册中心，它支撑起了蚂蚁集团海量规模的业务服务。 但随着蚂蚁集团业务规模的日渐庞大，SOFARegistry 在资源、容量、运维等方面也遇到了一些挑战，针对这一系列的挑战，我们对 SOFARegistry 进行了大量的改造，开发了 v6 版本的 SOFARegistry。\n项目地址\nsofa-registry开箱即用计划 https://github.com/sofastack/sofa-registry/projects/5\nsofa-registry深度解析计划 https://github.com/sofastack/sofa-registry/projects/4\n(这两个计划想帮助对参与开源项目感兴趣的同学由浅入深的上手，成为社区的一员)\n听众收获\n1、全面了解不同注册中心的设计及架构；\n2、深入了解千万级别微服务场景下服务发现的问题和解法。\n《基于API 网关的微服务治理演进与架构实践》\n嘉宾介绍\n王晔倞，现任API7 VP，Apache APISIX Contributor。公众号「头哥侃码」作者，曾在好买财富、大智慧、中通服软件、东方购物任职，21年IT从业经验，对技术管理和架构设计有一定的经验。TGO 鲲鹏会上海理事会成员，腾讯云TVP，QCon北京2017明星讲师，QCon北京2018优秀出品人。\n议题简介\n内容讲述随着业务的发展，规模扩大，服务颗粒越来越细，数量也越来越多。 我们在过程中有过很多经验和探索，并将系统从一个服务于单个业务方的后台系统逐渐改造成为一个支持海量内容，服务多个业务方，业务规则复杂多变的微服务治理架构。 通过API网关，我们有效协调线上运行的各个服务，保障服务的SLA。基于服务调用的性能KPI数据进行容量管理，并通过对技术中台的升级，对故障进行降级、熔断、限流等一系列升级。\n听众收获\n1、微服务治理当前面临的问题；\n2、API网关在微服务治理中的价值；\n3、从“单体“到”微服务“的转型过程中，该如何使用API网关实现微服务治理。\n《蚂蚁集团分布式链路组件 SOFATracer 原理与实践》\n嘉宾介绍\n郑志雄（花名纶珥），SOFABoot 开源负责人，主要负责蚂蚁集团应用研发框架的开发。\n议题简介\n当下的微服务技术架构，应用的各种服务通常都比较复杂、分布在不同的机器上；同时，这些应用可能又构建在不同的软件模块上，这些软件模块有可能是由不同的团队开发，可能使用不同的编程语言来实现、有可能部署了几千台服务器。为了能够分析应用的线上调用行为以及调用性能，蚂蚁金服基于 OpenTracing 规范，提供了分布式链路跟踪 SOFATracer 的解决方案，帮助理解各个应用的调用行为，并可以分析远程调用性能的组件。\n项目地址\nhttps://github.com/sofastack/sofa-tracer\n听众收获\n1、了解微服务场景下分布式链路组件的作用及价值；\n2、了解蚂蚁集团 SOFATracer 组件的基本原理。\n《准实时的日志聚合平台》\n嘉宾介绍\n吕思泉是思科 Webex 产品线 MATS（媒体分析与问题诊断服务）团队的技术专家，热爱开源，热爱分享，热爱生活，在MATS团队主要工作方向为基础技术的研究与应用，在分布式系统和微服务方面有丰富的经验，由其本人编写并开源的jgossip项目解决了MATS分布式Job Engine的水平扩展难题，由其本人研究并实践的基于Loki+Promtail+Grafana的日志平台大幅度提高了MATS团队在分布式系统日志管理与监控方面的效率。\n议题简介\n简要介绍基于 Loki 的日志可视化套件，以及思科内部如何使用该技术进行监控和告警。\n听众收获\n通过讲师介绍，大家可以了解到一种轻巧灵活的日志聚合系统，帮助开发人员快速定位问题以及实时了解系统状况。\n《Service Mesh 在蚂蚁集团的实践》\n嘉宾介绍\n李唯（良恩），蚂蚁集团技术专家。2017 年加入蚂蚁集团中间件团队。参与了 Service Mesh 在蚂蚁的落地建设，目前主要负责 MOSN 在蚂蚁内部的设计开发。\n议题简介\n随着业务发展，越来越多公司选择了微服务架构，它帮助业务解决了很多问题，但是在实践过程中也不免会遇到一些问题。在这些利与弊的权衡之中，Service Mesh 能够帮助到我们什么呢？本次内容分享 Service Mesh 在微服务的实践中解决的一些问题以及其背后的思考。\n项目地址\nhttps://github.com/mosn/mosn\n听众收获\n1、了解 Service Mesh 在微服务中的实践场景和意义；\n2、了解 Service Mesh 在蚂蚁实践中为业务带来的价值。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1627110000,"description":"SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践","dir":"activities/sofa-meetup-8/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4f05d75ae1c87e74010079dc175e3420","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-8/","publishdate":"2021-07-24T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-8/","summary":"概要 活动主题：SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践 活动时间：2021 年 07 月 24 日（周六）13:30-17:30 活动地点","tags":["SOFAMeetup"],"title":"SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-8/","wordcount":2084},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@王辉 提问：\n SOFARegistry 的 data 节点，连接 meta 节点，为什么设计成随机选择一个节点连接，如果 meta 节点 3 个节点，其中有一个节点挂了，而 data 节点又随机选择到这个挂的节点，就启动失败了。\n A：通过 slb 查询到主节点，然后所有的 session 和 data 都连接 meta 主节点。不是随机连接一个 meta。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n2、@刚刚 提问：\n SOFARPC 是通过 MOSN 转发协议？SOFARPC 对外注册的 IP 在 k8 的容器是什么策略？\n A：MOSN 支持 SOFARPC 协议的转发。服务发布订阅没有做啥特殊的，就和原来是一样的。\nMOSN：https://github.com/mosn/mosn\n3、@证道者 提问：\n Layotto 中 wasm 是怎么设置 cpu 和内存的？\n A：目前官方提供的 Wasm 运行时还不支持对 cpu 内存等资源进行限制，不过我们已经在跟 WasmEdge 社区沟通了，他们是可以支持这种场景的，所以后面同时会支持 WasmEdge 作为 Layotto 的 Wasm 运行时。\nLayotto：https://github.com/mosn/layotto\n3、@Q 提问：\n 两个 tc 节点，就有两套 global，branch，lock 表，当一个事物的调用链中，不同的 rm 连接的是不同的 tc 节点时，是不是会在各自 tc 的 branch 表里生成分支事物啊，这个时候怎么保证一致性呢？\n A：tc 集群无状态的，共用一套 db 数据。\nSeata：https://github.com/seata/seata\n本周推荐阅读 RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n 还在为多集群管理烦恼吗？OCM来啦！\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1627023600,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210723/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2d78986f9ca335444ed265e7bfac0648","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210723/","publishdate":"2021-07-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210723/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210723/","wordcount":972},{"author":"","categories":"SOFAStack","content":" 作者简介：冯泳（花名鹿惊），资深技术专家，拥有西北工业大学计算机科学博士学位，在高性能计算，大数据和云计算领域拥有十多年的设计开发经验，专注于调度，资源和应用管理领域。也深度参与相关开源项目的开发和商业化，例如 OpenStack, Mesos, Swarm, Kubernetes, Spark 等，曾在 IBM 领导过相关的开发团队。\n 前言 在云计算领域如果还有人没听过 Kubernetes，就好像有人不知道重庆火锅必须有辣椒。Kubernetes 已经像手机上的 Android，笔记本上的 Windows 一样成为管理数据中心事实上的标准平台了。围绕着 Kubernetes，开源社区构建了丰富的技术生态，无论是 CI/CD、监控运维，还是应用框架、安全反入侵，用户都能找到适合自己的项目和产品。可是，一旦将场景扩展到多集群、混合云环境时，用户能够依赖的开源技术就屈指可数，而且往往都不够成熟、全面。\n为了让开发者、用户在多集群和混合环境下也能像在单个 Kubernetes 集群平台上一样，使用自己熟悉的开源项目和产品轻松开发功能，RedHat 和蚂蚁、阿里云共同发起并开源了 OCM（Open Cluster Management）旨在解决多集群、混合环境下资源、应用、配置、策略等对象的生命周期管理问题。目前，OCM 已向 CNCF TOC 提交 Sandbox 级别项目的孵化申请。\n项目官网：https://open-cluster-management.io/\n 多集群管理发展历史 让我们把时间拉回到几年前，当业界关注/争论的焦点还在 Kubernetes 是否生产级可用的时候，就出现了最早一批登陆“多集群联邦“技术的玩家。它们大都是体量上远超平均水准的 Kubernetes 实践先驱，从最早 Redhat、谷歌入场做了 KubeFed v1 的尝试，再到后来携手 IBM 吸取经验又推出 KubeFed v2。除了这些大型企业在生产实践 Kuberentes 的场景中探索多集群联邦技术，在商业市场上，各个厂商基于 Kubernetes 包装的服务产品也大多经历了从单集群产品服务到多集群形态、混合云场景进化的过程。其实，无论是企业自身还是商业用户都有共性的需求，聚焦在以下几个方面：\n多地域问题：当集群需要在异构基础设施上或者横跨更广地域进行部署\nKubernetes 集群依赖 etcd 作为数据持久层，而 etcd 作为分布式系统对系统中各个成员之间的网络延迟上有要求，对成员的数量也有一些限制，虽然在延迟能够容忍的情况下可以通过调整心跳等参数适配，但是不能满足跨国跨洲的全球性部署需求，也不能保证规模化场景下可用区的数量，于是为了让 etcd 至少可以稳定运行，一般会按地域将 etcd 规划为多个集群。此外，以业务可用和安全性为前提，混合云架构越来越多地被用户接受。跨越云服务提供商很难部署单一 etcd 集群，随之对应的，Kubernetes 集群也被分裂为多个。当集群的数量逐渐增多，管理员疲于应对时，自然就需要一个聚合的管控系统同时管理协调多个集群。\n规模性问题：当单集群规模性遇到瓶颈\n诚然，Kubernetes 开源版本有着明显的规模性瓶颈，然而更糟糕是，我们很难真正量化 Kubernetes 的规模。社区一开始提供了 kubemark 套件去验证集群的性能，可是现实很骨感，kubemark 所做的事情基于局限于在不同节点数量下反复对 Workload 进行扩缩容调度。可是实践中造成 Kubernetes 性能瓶颈的原因复杂、场景众多，kubemark 很难全面客观描述多集群的规模性，只能作为非常粗粒度下的参考方案。后来社区支持以规模性信封来多维度衡量集群容量，再之后有了更高级的集群压测套件 perf-tests。当用户更清晰地认识到规模性的问题之后，就可以根据实际场景（比如 IDC 规模、网络拓扑等）提前规划好多个 Kubernetes 集群的分布，多集群联邦的需求也随之浮出水面。\n容灾/隔离性问题：当出现更多粒度的隔离和容灾需求\n业务应用的容灾通过集群内的调度策略，将应用部署到不同粒度的基础设施可用区来实现。结合网络路由、存储、访问控制等技术，可以解决可用区失效后业务的连续性问题。但是如何解决集群级别，甚至是集群管理控制平台自身的故障呢？\netcd 作为分布式系统可以天然解决大部分节点失败的问题，可是不幸的是实践中 etcd 服务也还是可能出现宕机的状况，可能是管理的操作失误，也可能是出现了网路分区。为了防止 etcd 出现问题时“毁灭世界”，往往通过缩小“爆炸半径”来提供更粒度的容灾策略。比如实践上更倾向于在单个数据中心内部搭建多集群以规避脑裂问题，同时让每集群成为独立的自治系统，即使在出现网络分区或者更上层管控离线的情况下可以完整运行，至少稳定保持现场。这样自然就形成了同时管控多个 Kubernetes 集群的需求。\n另一方面，隔离性需求也来自于集群在多租户能力上的不足，所以直接采取集群级别的隔离策略。顺带一提的好消息是 Kubernetes 的控制面公平性/多租户隔离性正在一砖一瓦建设起来，通过在 1.20 版本进入 Beta 的 APIPriorityAndFairness 特性，可以根据场景主动定制流量软隔离策略，而不是被动的通过类似 ACL 进行流量的惩罚限流。如果在最开始进行集群规划的时候划分为多个集群，那么隔离性的问题自然就解决了，比如我们可以根据业务给大数据分配独占集群，或者特定业务应用分配独占请集群等等。\nOCM 的主要功能和架构 OCM 旨在简化部署在混合环境下的多 Kubernetes 集群的管理工作。可以用来为 Kubernetes 生态圈不同管理工具拓展多集群管理能力。OCM 总结了多集群管理所需的基础概念，认为在多集群管理中，任何管理工具都需要具备以下几点能力：\n1.理解集群的定义；\n2.通过某种调度方式选择一个或多个集群；\n3.分发配置或者工作负载到一个或多个集群；\n4.治理用户对集群的访问控制；\n5.部署管理探针到多个集群中。\nOCM 采用了 hub-agent 的架构，包含了几项多集群管理的原语和基础组件来达到以上的要求：\n●通过 ManagedCluster API 定义被管理的集群，同时 OCM 会安装名为 Klusterlet 的 agent 在每个集群里来完成集群注册，生命周期管理等功能。\n●通过 Placement API 定义如何将配置或工作负载调度到哪些集群中。调度结果会存放在 PlacementDecision API 中。其他的配置管理和应用部署工具可以通过 PlacementDecisiono 决定哪些集群需要进行配置和应用部署。\n●通过 ManifestWork API 定义分发到某个集群的配置和资源信息。\n●通过 ManagedClusterSet API 对集群进行分组，并提供用户访问集群的界限。\n●通过 ManagedClusterAddon API 定义管理探针如何部署到多个集群中以及其如何与 hub 端的控制面进行安全可靠的通信。\n架构如下图所示，其中 registration 负责集群注册、集群生命周期管 …","date":1626764400,"description":"还在为多集群管理烦恼吗？OCM来啦！","dir":"blog/still-worried-about-multi-cluster-management/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"aef61122b990c692c05ed45907471ef8","permalink":"https://sofastack.github.io/sofastack.tech/blog/still-worried-about-multi-cluster-management/","publishdate":"2021-07-20T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/still-worried-about-multi-cluster-management/","summary":"作者简介：冯泳（花名鹿惊），资深技术专家，拥有西北工业大学计算机科学博士学位，在高性能计算，大数据和云计算领域拥有十多年的设计开发经验，专注","tags":["SOFAStack"],"title":"还在为多集群管理烦恼吗？OCM来啦！","type":"blog","url":"/sofastack.tech/blog/still-worried-about-multi-cluster-management/","wordcount":5878},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈拥军 提问：\n 我想求教一个问题，非 Spring 工程中使用 SOFARPC 的泛化调用是否可行？\n A：使用 SOFARPC 的 API 方式构造 泛化 Reference 就可以。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@孙明 提问：\n 请教大家，SOFARPC 可以相互依赖吗？比如 a 依赖 b，同时 b 也依赖 a。\n A：只要不是应用启动期的循环依赖，都是可以的。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n3、@周杰慧 提问：\n 请教个问题，使用 shardingsphere 与 Seata AT 模式结合，我看 Seata 源代码回滚时用主键更新，但对于数据库分片来讲更新时 where 条件需要带上分片的列，这样的话我应该怎么解决这个问题呢？\n A：看他们的 demo 来集成。\nSeata：https://github.com/seata/seata\n4、@Q 提问：\n eureka 做注册中心，TC 高可用时，如何在 TC 端覆盖 eureka 属性？\n A：在 seata\\conf 目录下新增 eureka-client.properties 文件，添加要覆盖的 eureka 属性即可。例如，要覆盖 eureka.instance.lease-renewal-interval-in-seconds 和 eureka.instance.lease-expiration-duration-in-seconds添加如下内容：\neureka.lease.renewalInterval=1\neureka.lease.duration=2\n属性前缀为 eureka，其后的属性名可以参考类 com.netflix.appinfo.PropertyBasedInstanceConfigConstants，也可研究 Seata 源码中的 discovery 模块的 seata-discovery-eureka 工程。\nSeata：https://github.com/seata/seata\n本周推荐阅读 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\n RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1626418800,"description":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210716/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cd4f09022c5b4338855eea46f50d5a9a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210716/","publishdate":"2021-07-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210716/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210716/","wordcount":993},{"author":"曾柯","categories":"SOFAStack","content":" 01 引言-TLS 1.3 协议及 SM 算法 说起 TLS，大家一定不会陌生，TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。自从 2014 年 Heartbleed 漏洞被发现以来，网络安全受人关注的程度越来越高，出于更安全更快捷的需求，TLS 1.3 协议也随之被提出，其相应的 RFC 于 2018 年正式发布。随着网络安全越来越受到重视，安全战略也逐步上升到国家战略的高度，国家密码局在 2010 年底公布了我国自主研制的“椭圆曲线公钥密码算法”（SM2 算法），并随后陆续发布了国密算法 SM1-SM9（SM 代表商密的拼音大写）。今天我们要分享的东西，就和 TLS 1.3 及国密有关。\n首先先让大家对这两者之间的关系有一个基本的概念，我们以一个典型的 TLS 1.2 中的密钥套件为例：\n 对应到我们的国密的算法上，则各个算法对应的套件如下：\n1、密钥交换算法：ECC-SM2，ECDHE-SM2（这里先不详细展开，只简单介绍一下，国密的密钥交换算法基于当前的椭圆曲线算法设计了两种专门的算法，而对应的曲线则是 SM2 曲线）；\n2、数字签名算法：SM2（SM2 既是签名算法的名称，同时在椭圆曲线算法中对应的曲线名也叫 SM2，有的博客文档里也将密钥交换算法称作 SM2，读者请注意不要混淆）；\n3、对称加密算法：SM4；\n4、hash 算法：SM3。\n也就是说，国密局针对安全握手各个阶段所需要的算法都出台了一份自主可控的算法。\n02 why 国密？why not 国密？ 先说说为什么要用国密，国密算法作为国密局的主力产品，肯定是在很多地方有优势的，先来总结下国密的典型优势：\n1、更安全：SM2 作为一种 ECC 算法（256 位）的安全性是要高于 2048 位的 RSA 的。同时 SM3 的摘要长度为 256 bit，安全强度也是要高于当时主流的 MD5 算法及 SHA1 算法的。\n2、更快速：在通讯过程中，256 位的 SM2 算法相比于 2048 位的 RSA 算法（国密算法在设计时，RSA2048 是主流签名算法，所以这里暂不讨论ECDSA等算法），可以传输更少的数据，也就意味着更少的传输时间，并且在理论上来说，SM2 签名算法的计算速度是要快过 RSA2048 不少的。\n3、自主可控：在目前这个国际形势下，这是最最最关键的一点！\n国密听起来像是中国密码的一次革新，但这些年却一直没有大面积推行开来，说明其本身肯定有一些问题的，这里抛开一些细节的小问题，谈一谈国密算法在大规模落地过程中遇到的一些比较棘手的问题：\n1.速度不够快（麻烦指数★★★）\n国密整个 TLS 会话流程中涉及到的几个算法，相对主流国际算法来说，大部分情况下性能均相对弱势，这里针对一些给出一些简单的性能对比表：\n对称加密算法性能对比：\n 签名算法性能对比：\n hash 算法性能对比：\n 从对比中我们可以看到，国密的这些算法目前和国际算法性能常常不在一个量级，无论是对称加密还是非对称加密的部分。究极根本原因，还是由于各种通用的国际算法普及程度太大，在工程上有着相应的多层次的优化（硬件计算和各种软加速手段），以对称加密为例：国密对称加密算法 SM4 对标的算法是 aes-128，从本身的加密原理上来看，SM4 在理论上不会和 aes-128 产生如此大的差距，然而 AES 由于普遍性实在太强，典型的 AES 实现都基于 Intel 的 SIMD 指令集对其进行了并行化加速，而 SM4 目前只有纯软的实现，性能上自然有不小的差距。不仅如此，目前的主流对称加密模式为 GCM 及 CCM 模式，其背后的思想为加密即认证技术（AEAD），而国密算法尚不支持这种模式，在安全性上也存在着一些弱点。\n2.需要双证书（★★★★）\n要把双证书讲清楚首先需要大家理解下 PKI 密钥协商机制，典型的密钥协商算法分为两种：RSA，ECDHE。国密的 ECC-SM2 密钥协商流程和 RSA 比较类似，算法核心的性质在于用公钥加密的数据可以用私钥解密，整个密钥协商流程简化如下图：\n 而 ECDHE-SM2 比较类似 ECDHE 算法，均是基于 DH 和 ECC 的算法，理解起来更加容易，流程简化如下图：\n 我们再来谈双证书这个事情，双证书分为签名证书和加密证书，这套体系的目的是满足国家对于敏感数据强管控诉求，即只要能抓到所有数据包，则管控机构则可以在理论上恢复出所有明文数据，由此催生出了加密证书这个东西，加密证书的私钥需要在专门的机构留底。我们来看 RSA 的密钥交换流程，只要拥有了私钥，则中间的密钥生成的材料（随机数）也就可以在理论上进行导出。而对于 ECDHE-SM2 来说，对称密钥的导出流程不仅仅只由随机数 a/c 来决定，同时也需要加密证书对应的私钥参与到计算中（具体流程比较繁琐，这里不展开，读者可参考 GM/T 0024 标准阅读详细的细节），也就意味着当私钥被监管，则对称密钥可以理论上被导出。\n这套体系很强悍，但难就难在目前所有主流密码库如 openssl，boringssl 都不支持，那么这也就意味着如果要推进这套体系的普适度，要么基于主流密码库开发，并推进开源社区接受，进而慢慢渗透到国内用户把这套体系用起来，要么在尽可能兼容目前密码体系的情况下开发一套新的密码库并强制国内用户替换，每一种办法都存在不小的难度。\n3.需要客户端也持有证书（★★★★★）\n国密在 GM/T 0024 标准里面定义了基于 ECDHE-SM2 算法的密钥交换流程，但这个算法的要求十分苛刻，必须要求 Client 也持有证书，的确这对于安全性有一定提升，但麻烦也就随之而来，支付宝的客户端目前没有证书，如果加上证书会让 App 更重，握手交互的数据更多，极大降低用户体验。这些问题还不够致命，如何管理海量的端上证书，才是真正令人头疼的麻烦。\n也许你会问：不用 ECDHE 不就好了嘛，但从技术的演进趋势来看，高效/安全是我们孜孜不倦的追求，而类 RSA 的握手流程则从根源上限制了国密 ECC 密钥交换流程无法演进到 1-RTT 握手，0-RTT 信息传输。不仅如此，ECHDE 的安全性及性能，也要好很多。在 TLS 1.3 的 1RTT 标准握手流程中，明确定义了废除 RSA 握手，只支持 ECDHE。目前这个情况就造成了一个死锁，想用 TLS 1.3-\u0026amp;gt;需要 ECDHE-\u0026amp;gt;需要 Client 有证书-\u0026amp;gt;没有证书且不想用证书-\u0026amp;gt;问题无解。\n03 重磅推出，TLS 1.3+ 国密算法套件 针对国密落地过程中的这些痛点问题，2019 年 8 月份，由蚂蚁的同学牵头，撰写了一份 TLS 1.3+ 国密算法 draft，并最终成为了一份 IETF 标准文档：\n 整个标准设计的核心思想是：整合目前国密算法优势，全面贴合国际上的安全技术思路，把不好用的东西先暂时剔除掉，提升国密算法在国内及国际上的影响力，从而让更多组织及个人参与到国密算法的使用和建设中来。基于这个思路，我们联合了 360 等公司，经过和国密局的多次沟通，正式推出了相关标准。在整个流程上，我们在 ECDHE 算法上取消了 Client 证书的要求，并暂时放 …","date":1626159600,"description":"RFC8998+BabaSSL---让国密驶向更远的星辰大海","dir":"blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"54dc71c8ea8dcfb0408a430934cb90c3","permalink":"https://sofastack.github.io/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","publishdate":"2021-07-13T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","summary":"01 引言-TLS 1.3 协议及 SM 算法 说起 TLS，大家一定不会陌生，TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。自从 2014 年 Heartbleed 漏洞被发","tags":["SOFAStack"],"title":"RFC8998+BabaSSL---让国密驶向更远的星辰大海","type":"blog","url":"/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","wordcount":3534},{"author":"王发康","categories":"SOFAStack","content":" 注：本文是王发康（毅松）在 2021 GopherChina 上演讲的文字稿，相关分享 PPT 可自行到 MOSN meetup 下载。MOSN meetup 地址；MOSN 官方 Github 地址；GitHub 地址。\n 前言 MOSN 在 Service Mesh 领域作为东西向服务治理网络在蚂蚁集团双 11 、春节红包等活动及开源社区都得到了一定实践。为了能够让社区用户更好的享受到这一技术红利，MOSN 从 2018 年开源以来在社区开发者、用户的共同努力下，使得 MOSN 在云原生演进方面做了很多探索和实践。比如 Istio 下另一个数据面 — MOSN、WebAssembly 在 MOSN 中的探索与实践、MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章、MOSN 基于 Sentinel 的限流实践、MOSN 中玩转 Dubbo-go 等周边生态展开合作。\n2021 年为了更好的为业务提效，MOSN 开启了将云原生进行到底的决心。本文介绍了 MOSN 在网络扩展层的思考和技术选型，以及最终是如何通过使用 Envoy 作为 MOSN 的网络层扩展，从而实现 MOSN 和 Envoy 生态打通。使得网络层具备 C++ 高性能的同时，上层业务治理能力也能借助 GoLang 进行高效的定制化开发。\n 面临的问题及挑战 一、社区生态，如何最大化求同存异 最近几年 Service Mesh 技术在云原生社区也是百花齐放，虽然 MOSN 在开源社区也是备受开发者的关注，但是 Envoy 经过长久的发展其社区的活跃度和用户量的积累这点是不可忽略的。另外选择 MOSN 的用户都是看重其二次开发的便捷性以及 GoLang 的生态丰富，选择 Envoy 的用户主要是看重其高性能的网络处理能力及社区的活跃度。那我们是否能够通过技术的手段将其二者优势融为一体，发挥各自的特长，不要让用户顾此失彼。\n二、单一的 Proxy，无法支撑其架构的演进 在 Proxy 层面，无论是 MOSN 还是 Envoy 都是在各自领域中发挥优势。随着云原生技术的快速发展和成熟以及业务的增长，既要 Proxy 能够具备高研发效能，还要具备高处理性能，而单一的 Proxy 已经无法满足当前业务架构上的持续演进。\n东西向和南北向数据面 Proxy 逐步统一：两套数据面定位不同但功能上存在一定重叠，导致维护成本高，未来需要逐步收敛。这就要求 Proxy 不仅具备易扩展性方便业务方扩展东西向业务上的流量治理能力，而且还要具备抗高并发的能力满足南北向高流量转发。\nService Mesh 部署形态逐步向 Node 化架构演进：Service Mesh 规模化后，由于多出的 Proxy 势必会导致一定资源上的浪费，那在中心化和 Mesh 化之间做一次折中，即通过 Node 化部署形态来解决。Node 化后就要求 Proxy 能够高效、稳定的承载多个 POD 的流量治理。\nService Mesh 需要同时具备 Application Runtime 能力：虽然 Service Mesh 解决了微服务治理的痛点，但在实际业务开发中，缓存、数据库、消息队列、配置管理等，仍然需要维护一套重量级的 SDK 并且侵入应用代码。目前业界的解决方案是在 Service Mesh 的基础上多引入一个 Proxy 如 Dapr 来解决，这就导致应用的 POD 需要维护多个容器，所以如何让 Service Mesh 的 Proxy 具备快速复用 Dapr 能力成为解决该问题的关键。\n我们的思考 针对上述问题分析过后，其实背后的原因是有共性的。比如将其统一为一个 sidecar，如果单纯的从一个数据面改为另一个，那其中的改造成本是巨大的。那是否可以换个思路，为 MOSN 的网络层增加可扩展性，即可以让 MOSN 的网络处理直接下沉至 Envoy，同时将这个能力剥离出来成为 Envoy 在 GoLang 上的一个标准能力，这样就能够让 Envoy 和 MOSN 互相复用已有的能力。二者相互融合，各取所长，使其同时具备高研发效能和处理性能高，自然而然就解决上述“单一的 Proxy，无法支撑架构的演进”和“社区生态，如何最大化求同存异”所面临的问题。相互融合后，不仅融合了各种的优势，而且也能够把两边的生态打通，借此 MOSN 社区和 Envoy 社区能形成双赢的局面。\n 方案调研与分析 知道当前面临问题的原因后，便有了一个宏观的解决方向。于是就对此展开了相关调研，梳理了业界针对此问题的一些解决方案，综合各种方案的优劣势并结合蚂蚁业务现状以及开源社区用户的痛点进行了分析和评估。\n扩展方案调研\n 扩展方案评估\n 通过上述方案优劣势的对比以及评估，MOE（MOSN on Envoy） 相比 ext-proc 无需跨进程 gRPC 通信，性能高，易管理；相比 Envoy WASM 扩展无需网络 IO 操作转换成本；相比 Lua 扩展生态好、能复用现有的 SDK，对于处理上层业务更合适。\n同时我们将 Envoy 中增加 GoLang 扩展的这个方案也在 Envoy 社区进行了讨论，也得到了 Envoy 社区 Maintainer 的赞同。其中依赖的技术 CGO 是 GoLang 官方出品，该技术基本上在 GoLang 每个 release notes 中都有提到，说明也一直在维护的。另外业界也有很多项目在使用这项技术（比如：NanoVisor、Cilium、NginxUnit、Dragonboat、Badger、Go withOpenCV etc）其稳定性已经过一定的考验了，同时我们自己也测试了 CGO 自身的开销在 0.08 ~ 1.626 微秒，而且调用开销也是属于线性增长而非指数增长趋势。\n 所以综合稳定性、性能、改造成本以及社区生态等因素评估，MOE 解决方案无论在当前阶段还是未来都具备一定优势。\n方案介绍 一、整体架构 如下是 MOE 的整体架构图，最下面是各种高性能数据面，目前我们主要适配的是 Envoy。在数据面之上剥离了一层 GoLang L7 extension filter 的抽象，用于和底层的数据面连通；然后在 MOSN 侧通过 GoLang L7 extension SDK 将 MOSN 连通；最后通过 CGO 这个通道将 Envoy 和 MOSN 打通。\n 整体架构如上图所示，其核心包括如下三部分组成：\n1、GoLang L4/L7 extension filter\n使用 C++ 实现的 Envoy 侧的 GoLang L4/L7 filter ，该模块通过 CGO API 来调用 GoLang 实现的 L4/L7 extension filter。\n2、GoLang L4/L7 extension SDK\nGoLang L4/L7 extension SDK 会导出一些 CGO API，用于 Golang L4/L7 extension filter 和 L4/L7 extension GoLang filter 交互。\n3、L4/L7 extension filter via GoLang\nL4/L7 …","date":1625554800,"description":"开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态","dir":"blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e570e9fb3aba7b066d2e3b332ae18dbc","permalink":"https://sofastack.github.io/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","publishdate":"2021-07-06T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","summary":"注：本文是王发康（毅松）在 2021 GopherChina 上演讲的文字稿，相关分享 PPT 可自行到 MOSN meetup 下载。MOSN meetup 地址；MOSN 官方 Github 地址；GitHub 地址。 前言 MOSN 在 Service Mesh","tags":["SOFAStack"],"title":"开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态","type":"blog","url":"/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","wordcount":5977},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@刘世杰 提问：\n 新接触 SOFABoot，有 2 个问题想请教一下： 1.如何根据不同的贡献方选择对应的扩展实现？贡献方有多个的情况下，覆盖了原始的对象，没看到如何根据身份定位具体实现的逻辑，不知道是遗漏了什么说明文档，我看的这个文档：https://www.sofastack.tech/projects/sofa-boot/extension/\n2.如何确保贡献方提供的 jar 包不对服务提供方产生影响？如果多个贡献方提供的 jar 包里间接依赖了不同版本的二三方的 jar 包。在同一个 classloader 下只能加载一个版本的 class，那对某些贡献方的逻辑处理可能会出现 NoClassDefFoundError 类的异常。SOFAArk 是具备了这种隔离的能力的，是否需要引入这种方式？\n A：1.如果有多个扩展点 x 的扩展地方，那么 A 的 registerExtension 就会被调用多次（与被扩展的次数一样，这个方法需要线程安全）；框架无法获知扩展者的身份，这个就需要扩展点提供方自行甄别。\n2.第二种情况，其实不仅限于 SOFABoot 中的扩展点，仅有一个 class loader 的情况下，会出现这种情况。个人认为在没有动态性要求的情况下，优先解决 maven 依赖冲突。\nSOFABoot：https://github.com/sofastack/sofa-boot\n2、@刘世杰 提问：\n 1.按照官网的 Demo，如果有多个贡献方 A、B、C，按照顺序执行了 registerExtension 方法，那 word 的值会以 C 为准吗？意思是不是说在运行时一个扩展点只有一个贡献方？\n2.如果贡献方比较多的话，这个后期的解决冲突的成本会不会比较高。还有些比较隐蔽的实现，可能不是太好测试出来，到生产才发现问题。另外，如果做动态的话在 SOFABoot 的技术栈里是扩展点 +Ark 的方式？\n A：1.这个顺序是没有保证的，SOFABoot 为了启动速度，并行化了上下文刷新的，因此可能是 A、B、C 顺序，也有可能是 C、B、A；运行时可以有多个实现的，这个取决于你的服务类型，以及如何实现的。\n2.可以这么理解，SOFAArk 就是一种动态扩展的方案。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@证道者 提问：\n MOSN mirror 功能是只能转发 Dubbo 的流量么？\n A：不是只能转发 Dubbo，都可以的。\nMOSN：https://github.com/mosn/mosn/\n本周推荐阅读 【感谢有你，SOFAer】一图看懂 SOFAStack 2021 半年报\n MOSN 多协议扩展开发实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1625209200,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210702/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5808aa4a754ad5a4024b619e1d61cba8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210702/","publishdate":"2021-07-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210702/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210702/","wordcount":1290},{"author":"永鹏","categories":"SOFAStack","content":" Service Mesh 是当今云原生的关键部分，蚂蚁已经在生产环境完成了大规模的落地，但是业界整体 Service Mesh 改造程度还不高。其中平稳的进行 Mesh 化改造是可以对已上线的业务进行 Mesh 化改造的前提，在平稳改造过程中，协议的支持又是最基础的部分。MOSN 提供的多协议扩展开发框架旨在降低使用私有协议的场景进行 Mesh 化改造的成本，帮助业务快速落地。\n MOSN 是蚂蚁自研的一款高性能网络代理，主要用于 Service Mesh 的数据面 Sidecar。Service Mesh，是近几年来云原生方向比较热门的话题，其主旨就是构建一个基础设施层，用来负责服务之间的通信。主要就是有一个和服务应用共同部署的 Sidecar 来实现各种中间件的基础能力，实现基础设施的标准化、和业务逻辑解耦，做到业务无感知的基础能力快速演进。目前国内很多公司都开始拥抱 Service Mesh，和蚂蚁合作的一些企业，如中信银行、江西农信等也基于 MOSN 完成了 Mesh 化的改造。\nService Mesh 架构的目的就是为了降低基础设施改造升级对业务造成的影响，但是如何平滑的从传统微服务架构转向 Service Mesh 架构也是一个非常有挑战的工作，这里涉及的细节很多，但是无论如何有一个最基础的问题就是我们在进行灰度 Mesh 化改造的时候，已经 Mesh 化的节点需要能和没有 Mesh 化的节点维持正常通信。而不同的公司选择的通信协议都有所不同，这就直接导致在技术选型的时候，选择的 Sidecar 需要能够支持所使用的协议。一些受到广泛应用的协议可能还会被陆续的支持，而有的协议可能还是公司自己定制的，因此不可避免的是需要基于 Sidecar 的扩展能力，进行二次开发以支持私有的协议。\n 多协议扩展框架 谈到 Service Mesh 的 Sidecar，就不得不提到 Envoy，这是一款被广泛应用的 Service Mesh Sidecar 代理。Envoy 的扩展框架支持开发者进行二次开发扩展，其中 Envoy 目前支持的不少协议就是基于其扩展框架开发实现的。在 Envoy 的扩展框架下，要扩展一个协议可以参考 Envoy 中 HTTP 协议处理的流程，包括 4 层 Filter 实现编解码部分与 Connection Manager 部分，在 Connection Manager 的基础上再实现 7 层的 Filter 用于支持额外的业务扩展、路由的能力、和 Upstream 的连接池能力。可以看到一个协议处理的流程几乎是贯穿了各种模块，实现一个协议扩展成本还是比较高的。\n 再来看一下 MOSN 的框架。MOSN 在一次协议处理上可以划分为四个层次，除开基本的从网络 IO 中获取数据的网络层以外，还可以划分为 protocol 层、stream 层与 proxy 层。其中 protocol 层负责协议解析相关编解码的工作，负责将数据流解析成 MOSN 可以理解的协议帧，或者将协议帧编码成二进制流；stream 层负责的内容就比较多了，包括处理不同的请求类型，初始化请求的上下文，关联事件，响应与请求之间的关联，还有 upstream 连接池相关的处理等，不同的协议处理的细节也会有所不同；proxy 层是一个协议无关的代理转发层，负责请求的路由与负责均衡等能力，同时也具备七层的扩展能力用于不同业务实现的扩展。根据这个架构，可以看到协议处理的核心就在于 protocol 层和 stream 层，相比于 Envoy 的设计来说，路由、七层扩展等部分是具备多协议复用的能力的。但是同时也可以看到 stream 层涉及的细节比较多，实现起来难度也是比较大的，为此 MOSN 在此基础上又提出了一个多协议扩展的框架，用于简化协议的实现。\n MOSN 的多协议框架主要就是针对 stream 层的复用扩展能力，在 MOSN 的协议处理分层设计中， network 层和 proxy 层在设计上就是协议无关可复用的，如果能做到 stream 层也进行复用，那么协议实现就只需要关注 protocol 层的编解码本身，实现难度就会大大降低了。那么 stream 层是不是具备可复用的能力的呢，我们认为对于大部分协议，尤其是 RPC 协议来说是可以的。首先我们对协议进行一个抽象，定义成 XProtocol 接口，表示任意的协议。每个协议实现都是实现一个 XProtocol 接口，它包括基础的编解码接口、一些特殊请求响应的构造接口（如心跳、异常）、还有协议的模型（如类似 HTTP 的 pingpong 模型，常见的 RPC 多路复用模型等），以及协议匹配的接口。所有的 XProtocol 协议实现通过 XProtocol Engine 关联起来，除了通过配置指定使用哪种协议进行处理以外，对于实现了协议匹配接口的协议来说，可以基于请求特征进行自动识别。然后我们对于 XProtocol 解析出的协议帧也进行统一的抽象，包括多路复用相关的接口、协议类型的判断（是请求，还是响应，或者是类似 Goaway 一类的控制帧，请求又可以细分为心跳请求、无响应的 oneway 请求等）、支持对协议帧的数据进行修改（Header/Body 的修改）、还有统一的状态码管理映射等。\n 在 MOSN 的协议处理分层机制下，以及有了以 XProtocol 和 XFrame 的抽象定义为核心的多协议扩展框架以后，我们在 stream 层就可以完全基于接口进行协议的处理，而不同的协议扩展实现者只需要专注于协议编解码本身，以及对编解码后的结果进行简单的接口适配，就可以完成在 MOSN 中的接入，由此获得 MOSN 中各种通用能力的支持，如限流扩展、路由引流等。对比 Envoy 中扩展协议实现部分可以看到是简化了不少的。当然 MOSN 这个多协议框架不能满足所有的协议情况，但是对于目前我们看到的大部分 RPC 协议，在配合上 proxy 层中七层 stream filter 扩展的基础上，都是可以很好的满足的。\n实践案例 下面以 MOSN 在社区合作伙伴中 Dubbo 协议落地的案例来详细的了解 MOSN 的多协议扩展。这里很多代码也是 MOSN 社区的同学贡献的。 在这个案例中，除了要求协议需要支持 Dubbo 以外，还希望使用像限流等这些基础的扩展能力，同时需要蓝绿分组等路由的能力，选择的控制面是 Istio，用于动态配置的下发。那这些需求在 MOSN 中是如何实现的呢？\n首先是协议解析部分，这里采用了基于开源的 dubbo-go 框架做协议实现，基于 dubbo-go 封装出了 MOSN 的 XProtocol 和 XFrame 模型；限流、xDS 等能力直接复用 MOSN 已有的实现，无需额外实现。但是这里有一个问题点就是 Istio 动态下发的路由配置是 HTTP 相关的，HTTP 的路由配置模型与 Dubbo 还是存在一定差异的，而修改 Istio 的成本会比较高，在这里就做了另外一层扩展。基于 MOSN 七层的 StreamFilters，在进行路由匹配之前对 Dubbo 协议进行定制化的处理，用来满足 HTTP 的 …","date":1624950000,"description":"MOSN 多协议扩展开发实践","dir":"blog/mosn-multi-protocol-extension-development-practice/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d5691b6aa90017e49d9726b702475306","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","publishdate":"2021-06-29T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","summary":"Service Mesh 是当今云原生的关键部分，蚂蚁已经在生产环境完成了大规模的落地，但是业界整体 Service Mesh 改造程度还不高。其中平稳的进行 Mesh 化改造是可以对已上线的业务","tags":["SOFAStack"],"title":"MOSN 多协议扩展开发实践","type":"blog","url":"/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","wordcount":4141},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@证道者 提问：\n 应用调用端多语言可以，Layotto 服务能力是不是目前只能 golang 开发，java 可以开发服务能力集成到 Layotto 里吗？还有就是 Layotto 底座是 MOSN 可以不用这个吗？我目前有一个需要处理，就是数据库单表 crud，跨表的 crud，自己分页检索这个能力可以用 Layotto 吗？\n A：如果想用别的语言给 Layotto 做扩展的话，目前感觉可行的方法就是借助 wasm，但具体的方案我们还得调研一下，目前是只能用 golang 开发。 至于你说的这个需求，可应该以作为 Layotto state API 的一种实现组件。\nLayotto：https://github.com/mosn/layotto\n2、@证道者 提问：\n 目前提供 pub/sub 能力，流 stream 能力，状态能力，以后也会将一些通用的业务能力抽象下移到 Layotto 吗？我觉得有点像组件化，面向能力编程。\n A：是的，主要就是希望业务同学可以面向能力编程，比如只需要考虑自己是否需要 pub/sub 能力就行，而不需要管背后是 kafka 还是 rocketMQ 之类的，我们目前在规划的有分布式锁、可观测性能力的下沉，其他的能力会参考社区的反馈。\nLayotto：https://github.com/mosn/layotto\n3、@证道者 提问：\n 所有的都在 Layotto 里面跑，pubsub PRC 不会相互干扰吗?\n A：你指的是资源使用上的互相争抢是吧，目前我们 Service Mesh 落地，Sidecar 也是集成的有 RPC 和 消息能力的，Sidecar 本身主要还是一个转发通道，本身资源占用还是极少的，目前生产上也没有因为同时 Run RPC 和 消息导致互相干扰的现象产生。在 Layotto 这也是类似的场景，大部分业务在单机维度很难跑到极限性能峰值，基本上不会有互相干扰的情况出现。\nLayotto：https://github.com/mosn/layotto\n本周推荐阅读 MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1624604400,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210625/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"edfd61aa9405dccf65be9b8703fa5a1f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210625/","publishdate":"2021-06-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210625/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210625/","wordcount":1070},{"author":"SOFAStack","categories":"SOFAStack","content":" 作者简介： 马振军，花名古今，在基础架构领域耕耘多年，对 Service Mesh 有深度实践经验，目前在蚂蚁集团中间件团队负责 MOSN、Layotto 等项目的开发工作。\n Layotto 官方 GitHub 地址:https://github.com/mosn/layotto\n点击链接即可观看现场视频：https://www.bilibili.com/video/BV1hq4y1L7FY/\nService Mesh 在微服务领域已经非常流行，越来越多的公司开始在内部落地，蚂蚁从 Service Mesh 刚出现的时候开始，就一直在这个方向上大力投入，到目前为止，内部的 Mesh 方案已经覆盖数千个应用、数十万容器并且经过了多次大促考验，Service Mesh 带来的业务解耦，平滑升级等优势大大提高了中间件的迭代效率。\n在大规模落地以后，我们又遇到了新的问题，本文主要对 Service Mesh 在蚂蚁内部落地情况进行回顾总结，并分享对 Service Mesh 落地后遇到的新问题的解决方案。\n一、Service Mesh 回顾与总结 A、Service Mesh 的初衷 在微服务架构下，基础架构团队一般会为应用提供一个封装了各种服务治理能力的 SDK，这种做法虽然保障了应用的正常运行，但缺点也非常明显，每次基础架构团队迭代一个新功能都需要业务方参与升级才能使用，尤其是 bugfix 版本，往往需要强推业务方升级，这里面的痛苦程度每一个基础架构团队成员都深有体会。\n伴随着升级的困难，随之而来的就是应用使用的 SDK 版本差别非常大，生产环境同时跑着各种版本的 SDK，这种现象又会让新功能的迭代必须考虑各种兼容，就好像带着枷锁前进一般，这样随着不断迭代，会让代码维护非常困难，有些祖传逻辑更是一不小心就会掉坑里。\n同时这种“重”SDK 的开发模式，导致异构语言的治理能力非常薄弱，如果想为各种编程语言都提供一个功能完整且能持续迭代的 SDK 其中的成本可想而知。\n18 年的时候，Service Mesh 在国内持续火爆，这种架构理念旨在把服务治理能力跟业务解耦，让两者通过进程级别的通信方式进行交互。在这种架构模式下，服务治理能力从应用中剥离，运行在独立的进程中，迭代升级跟业务进程无关，这就可以让各种服务治理能力快速迭代，并且由于升级成本低，因此每个版本都可以全部升级，解决了历史包袱问题，同时 SDK 变“轻”直接降低了异构语言的治理门槛，再也不用为需要给各个语言开发相同服务治理能力的 SDK 头疼了。\nB、Service Mesh 落地现状 蚂蚁很快意识到了 Service Mesh 的价值，全力投入到这个方向，用 Go 语言开发了 MOSN 这样可以对标 envoy 的优秀数据面，全权负责服务路由，负载均衡，熔断限流等能力的建设，大大加快了公司内部落地 Service Mesh 的进度。\n现在 MOSN 在蚂蚁内部已经覆盖了数千个应用、数十万容器，新创建的应用默认接入 MOSN，形成闭环。而且在大家最关心的资源占用、性能损耗方面 MOSN 也交出了一份让人满意的答卷： 1. RT 小于 0.2ms\n CPU 占用增加 0%~2%\n 内存消耗增长小于 15M\n 由于 Service Mesh 降低了异构语言的服务治理门槛，NodeJS、C++等异构技术栈也在持续接入到 MOSN 中。\n在看到 RPC 能力 Mesh 化带来的巨大收益之后，蚂蚁内部还把 MQ，Cache，Config 等中间件能力都进行了 Mesh 化改造，下沉到 MOSN，提高了中间件产品整体的迭代效率。\nC、新的挑战 应用跟基础设施强绑定 一个现代分布式应用，往往会同时依赖 RPC、Cache、MQ、Config 等各种分布式能力来完成业务逻辑的处理。\n当初看到 RPC 下沉的红利以后，其他各种能力也都快速下沉。初期，大家都会以自己最熟悉的方式来开发，这就导致没有统一的规划管理，如上图所示，应用依赖了各种基础设施的 SDK，而每种 SDK 又以自己特有的方式跟 MOSN 进行交互，使用的往往都是由原生基础设施提供的私有协议，这直接导致了复杂的中间件能力虽然下沉，但应用本质上还是被绑定到了基础设施，比如想把缓存从 Redis 迁移到 Memcache 的话，仍旧需要业务方升级 SDK，这种问题在应用上云的大趋势下表现的更为突出，试想一下，如果一个应用要部署在云上，由于该应用依赖了各种基础设施，势必要先把整个基础设施搬到云上才能让应用顺利部署，这其中的成本可想而知。 因此如何让应用跟基础设施解绑，使其具备可移植能力，能够无感知跨平台部署是我们面临的第一个问题。\n 异构语言接入成本高 事实证明 Service Mesh 确实降低了异构语言的接入门槛，但在越来越多的基础能力下沉到 MOSN 以后，我们逐渐意识到为了让应用跟 MOSN 交互，各种 SDK 里都需要对通信协议，序列化协议进行开发，如果再加上需要对各种异构语言都提供相同的功能，那维护难度就会成倍上涨，\nService Mesh 让重 SDK 成为了历史，但对于现在各种编程语言百花齐放、各种应用又强依赖基础设施的场景来说，我们发现现有的 SDK 还不够薄，异构语言接入的门槛还不够低，如何进一步降低异构语言的接入门槛是我们面临的第二个问题。\n二、Multi Runtime 理论概述 A、什么是 Runtime? 20 年初的时候，Bilgin lbryam 发表了一篇名为 Multi-Runtime Microservices Architecture 的文章，里面对微服务架构下一阶段的形态进行了讨论。\n如上图所示，作者把分布式服务的需求进行了抽象，总共分为了四大类： 1. 生命周期（Lifecycle） 主要指应用的编译、打包、部署等事情，在云原生的大趋势下基本被 docker、kubernetes 承包。\n 网络（Networking） 可靠的网络是微服务之间进行通信的基本保障，Service Mesh 正是在这方面做了尝试，目前 MOSN、envoy 等流行的数据面的稳定性、实用性都已经得到了充分验证。\n 状态（State） 分布式系统需要的服务编排，工作流，分布式单例，调度，幂等性，有状态的错误恢复，缓存等操作都可以统一归为底层的状态管理。\n 绑定（Binding） 在分布式系统中，不仅需要跟其他系统通信，还需要集成各种外部系统，因此对于协议转换，多种交互模型、错误恢复流程等功能也都有强依赖。\n 明确了需求以后，借鉴了 Service Mesh 的思路，作者对分布式服务的架构演进进行了如下总结：\n 第一阶段就是把各种基础设施能力从应用中剥离解耦，通通变成独立 sidecar 模型伴随着应用一起运行。\n第二阶段是把各种 sidecar 提供的能力统一抽象成若干个 Runtime，这样应用从面向基础组件开发就演变成了面向各种分布式能力开发，彻底屏蔽掉了底层实现细节，而且由于是面向能力，除了调用提供各种能力的 API 之外，应用再也不需要依赖各种各样基础设施提供的 SDK 了。\n作者的思路跟我们希望解决的问题一致， …","date":1624258800,"description":"MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章","dir":"blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","fuzzywordcount":7600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4ea3e26c4f2e5422816a186691849af5","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","publishdate":"2021-06-21T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","summary":"作者简介： 马振军，花名古今，在基础架构领域耕耘多年，对 Service Mesh 有深度实践经验，目前在蚂蚁集团中间件团队负责 MOSN、Layotto 等项目的开发工","tags":["SOFAStack"],"title":"MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章","type":"blog","url":"/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","wordcount":7525},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙力 提问：\n 请问和 MOSN 相关的健康检查有什么可行的方案吗？比如如何检查 MOSN 的健康状态，MOSN 检查业务容器健康，检查失败后有什么降级或动作？\n A：MOSN 有获取运行状态的 API ，\nhttps://github.com/mosn/mosn/blob/master/pkg/admin/server/apis.go#L301\n检查业务容器健康通常来说需要自己扩展。\nhttps://github.com/mosn/mosn/blob/9a53d7239d8d5ca987410c15d791e780b5809558/pkg/upstream/healthcheck/factory.go#L53\n健康检查也有回调可以注册，可以实现自己的降级逻辑。\nMOSN：https://github.com/mosn/mosn\n2、@许玉杰 提问：\n AT 模式是怎么做到的空回滚、防悬挂和幂等的啊？\n A：幂等是用户自己做的，防悬挂和空回滚有 undolog，AT 的幂等等于接口幂等，自己的接口保证即可。\nSeata：https://github.com/seata/seata\n3、@jueming 提问：\n Seata 支持 mybatis 的注解开发吗？目前用的 seata1.0 的版本，需要配置代理数据源，但是配置之后，影响了其他 sql 的执行，代理执行了 sql 的方法，打印了相关 sql 语句（数据库里有数据），但是得到的实体却为空。我把代理关闭以后则不影响 sql 的查询，这种情况应该怎么解决？\n A：这里的问题是添加代理数据源的时候，使之前的 datasource 自动失效，没有读取 mybatis 的配置，解决方法是在设置新的 sqlsessionfactory 的时候，把需要配置的属性通过 ibatis 包下的 Configuration 注入进去。\nSeata：https://github.com/seata/seata\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623999600,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210618/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c8d740f2b60544b872580120fd456cde","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210618/","publishdate":"2021-06-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210618/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210618/","wordcount":902},{"author":"SOFAStack","categories":"SOFAStack","content":" GoCN：贵司从什么时候开始用 Go，基于什么原因，还记得第一个用 Go 的项目是什么吗?\n宋顺：早在 2015 年，蚂蚁的基础设施团队就已经使用 Go 来尝试优化资源调度能力，当时还是基于 Docker Swarm 做的一些调度平台，这个时期没有持续太长就逐步切换到了 Kubernetes，蚂蚁内部的版本叫 Sigma，当前 Sigma 已经承担起了蚂蚁内部所有集群的资源调度，并且也在逐年提升资源利用率，为公司节省了不少的成本。\nGoCN：现在有多少人用 Go，或者 Go 开发比例占到多少？\n宋顺：目前 Go 主要用于蚂蚁的基础设施团队，在资源调度、弹性伸缩、安全容器、日志无盘、Service Mesh、Serverless 等场景中广泛应用，Go 的开发人员在基础设施团队内部占比高达 50% 以上，业务团队大部分还是以 Java 为主。\nGoCN：Go 有哪些特性是非常匹配贵司业务和开发需求的，有哪些是让人很抓马的，希望有哪些改进？\n宋顺：Go 的简单易学、安全编码、研发效率、活跃生态等特性是非常符合我们的需求的。抓马的主要还是性能，如大规模下 gc 抖动，调度延迟等。改进方面希望能够有比 channel 更轻量的 Go block/wake 机制，这块我们也在和社区讨论中：https://github.com/golang/go/issues/46431\nGoCN：目前来看 Go 在项目中普及的难度是什么，在招聘方面有困难吗?\n宋顺：在基础设施层面普及没有太大难度，后续如果在业务团队中也能顺畅的使用 Go 还是需要我们的 Service Mesh 体系对多语言体系的支撑更加完善，让业务能更少的感知底层能力从而专注业务开发。我们即将开源的 Layotto 就是希望在 Runtime 层面通过统一的 API 定义，从而可以让各种语言都非常简单的享受到分布式架构的红利，为业务提效。 在招聘方面由于目前 Go 主要用于基础设施，所以我们需要的是对网络、系统内核、高性能有较多经验的人才，不过眼下这类人才还是比较稀缺的。\nGoCN：希望招到具备哪方面能力的 Go 工程师？\n宋顺：有高性能网络编程和性能优化经验，对分布式系统有较深理解，对 Go Runtime 有一定研究的 Gopher 工程师。\nGoCN：对本次大会的期待是什么？\n宋顺：希望了解 Go 在更多公司的实践经验、学习 Go 语言自身的特性演进以及和更多的 Gopher 现场交流。\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623740400,"description":"Gopher China 2021 专访之宋顺：Go 在蚂蚁集团的应用、实践","dir":"blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e6d1f215ee12ebb60c2cc4fda0b64d82","permalink":"https://sofastack.github.io/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","publishdate":"2021-06-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","summary":"GoCN：贵司从什么时候开始用 Go，基于什么原因，还记得第一个用 Go 的项目是什么吗? 宋顺：早在 2015 年，蚂蚁的基础设施团队就已经使用 Go 来尝试优化资","tags":["SOFAStack"],"title":"Gopher China 2021 专访之宋顺：Go 在蚂蚁集团的应用、实践","type":"blog","url":"/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","wordcount":990},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙军超 提问：\n 实际项目中，怎么动态的配置 # 集群列表中所有节点的地址列表initialServerList: 127.0.0.1:8181,127.0.0.1:8182,127.0.0.1:8183比如加一个节点 这个列表怎么自动刷新 。\n A：通过 CliService 动态增上改节点。\nSOFAJraft：https://github.com/sofastack/sofa-jraft\n2、@王国鑫 提问：\n 请教一下，其中一个 follow 机器，在状态机 onApply 里执行任务，有一些异常，这个异常状态如何上报给 leader？\n A：异常分两种，跟上不上报 leader 没什么关系，也不需要上报 leader。leader 只负责感知对应 follower 能不能跟上 raft log， 不论 raft 还是 paxos，都可以理解为分布式日志状态机，你这个异常是你自己的业务状态机里的事情了，raft 只保证 raft log 一致，你自己需要保证相同的 raft log 你要产生相同的结果。\nSOFAJraft：https://github.com/sofastack/sofa-jraft\n3、@陈泽胜 提问：\n 我想问一下我这个是什么问题？ 这是偶发的，两三天会出现一次，有时候一小时内会出现多次。\n Seata：https://github.com/seata/seata\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623394800,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-0611/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"74bd4ee2b575599848e566b632980c07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0611/","publishdate":"2021-06-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0611/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0611/","wordcount":896},{"author":"","categories":"SOFAStack","content":" 主题：从数据库到架构，我们来聊透分布式\n时间：2021年6 月 19 日（周六）13：00 -17：30\n活动地点：北京海淀中关村创业大街 72 号拓荒族众创空间\n报名方式：点击http://hdxu.cn/Iq6Ef 即可报名。\n扫描海报上面的二维码，即可报名。\n【重要提醒】2021 年 6 月 19 日将有惊喜送出，欲知惊喜为何，请待 619 给您分解。\n6月初， OceanBase 诚意开源，正式揭开 300 万 C++ 数据库内核代码的神秘面纱。\n本次线下 Meetup，由 OceanBase \u0026amp;amp; SOFAStack 联合举办，也是 OceanBase 开源之后的首次线下活动。\n本次分享将邀请来自 OceanBase 和 SOFAStack 两个开源项目的四位专家，分别从云原生分布式架构、分布式 HTAP 数据库，以及新发布的时序数据库 CeresDB 来层层解开分布式的魅力。\n 报名方式：\n1、 扫描海报二维码，立即报名；\n2、 点击http://hdxu.cn/Iq6Ef 即可报名。\n在活动现场不仅仅可以和讲师面对面交流\n还有精美礼品发放，快来现场吧~\n","date":1623135600,"description":"【活动报名】SOFAMeetup#6 北京站，从数据库到架构，聊透分布式，玩转 Layotto","dir":"activities/sofa-meetup-7/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"884ed3d8cfc6d7b0784dbda5a27315b1","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-7/","publishdate":"2021-06-08T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-7/","summary":"主题：从数据库到架构，我们来聊透分布式 时间：2021年6 月 19 日（周六）13：00 -17：30 活动地点：北京海淀中关村创业大街 72 号拓荒族众创空","tags":["SOFAStack"],"title":"【活动报名】SOFAMeetup#6 北京站，从数据库到架构，聊透分布式，玩转 Layotto","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-7/","wordcount":371},{"author":"","categories":"SOFAStack","content":" 此文原系 2021 年阿里云开发者大会，开源操作系统社区和生态分论坛，题为《国密技术开发与实践》的分享会后解读。 AnolisOS 国密是社区在 AnolisOS 上做的国密技术解决方案，非常欢迎业界有兴趣的开发者能够参与到 OpenAnolis 社区，为国内的基础软件生态添砖加瓦。\n演讲嘉宾： 杨洋：蚂蚁集团高级技术专家，主导开发了 BabaSSL，也是国内唯一的一个 OpenSSL maintainer，参与起草并推动 RFC8998 标准国际化。 张天佳：阿里云技术专家，主要负责 AnolisOS 上国密技术的开发和应用，参与实现了 libgcrypt 中的国密算法和 linux 内核中的 SM2 算法。\n 让我们穿越回现场： \u0026amp;gt;\u0026amp;gt;缘起 说到密码算法，大家一定很熟悉 MD5，AES，RSA 这些通用的国际标准算法，这也是目前我们普遍采用的密码学算法，它们在数据安全、通信、区块链等众多领域都有着广泛的应用。\n众所周知，这些算法标准都是国外制定的，在某些情况下这会对国内信息安全有不利影响。当下有实力的国家，甚至有些大公司都制定了自己的算法标准。\n顾名思义，国密就是密码算法的国产化，跟其它领域一样，密码算法的国产化已经势不可挡，这也是我们必须要做的事情。中国的国密算法为我们提供了一个新的选择，在必要的场合中可以选择替代那些国际主流算法，尤其是当下国际贸易冲突，技术封锁不可忽视的大环境下，大规模推广和采用国密算法将为国内重要的网络基础设施提供可靠的数据安全保障。\n国密简介 我是谁，从哪里来\n国密是一个口语化的称呼，官方名称是国家商用密码，简称商密，拼音缩写是 SM，这也是国密标准中具体算法名字的来源。国密是用于商用的、不涉及国家秘密的密码技术。\n国密标准完全由中国密码管理局制定，主要的技术实现也基本是国内开发人员完成的，这对摆脱国外的密码技术和产品依赖是非常有利的。\n到哪里去\n自 2012 年以来，SM2/3/4 的国密标准陆续公布，目前国密技术生态基本处于一个正在逐步走向成熟的阶段，但国内密码基础软件在采用国密算法方面仍处于碎片化的状态，比如我们经常可以看到各种个人或组织名义开源的支持国密算法的库；此外这些开源项目的安全更新和社区活跃也都做的不好。国密的推广仍然需要我们中国基础软件的开发者和用户共同努力。\n2020 年 1 月 1 日，《中华人民共和国密码法》正式实施，从法律层面规范了国家商用密码的应用和管理，这也为推广和应用国密提供了必要的法律保障。\n与国际算法的对比\n这里是国密算法和国际通用算法的一个对比，可以直观地看到国密的一个基本情况：\n 针对各种常用的国际能用算法类型，比如对称算法，公钥算法和消息摘要算法，国密标准都定义了对应的相同功能的国密算法，比如 SM4 提供了与 AES 同样的加密强度，并且支持各种加密模式； SM2 是基于椭圆曲线的公钥算法，同时定义了非对称加解密，数字签名和密钥交换标准，相对于 RSA，SM2 的密钥更短，但支持的加密强度却更高；SM3 是国密定义的消息摘要算法标准，摘要长度是固定的 256 位，强度等同于 SHA256。\n除了基础的算法，国密标准也定义了 TLCP 国密双证书协议，用以支持国内的传输层安全协议。这里还有一个好消息，今年三月份，TLS1.3+国密单证书协议正式被国际标准所承认，并且以 RFC8998 标准发布，这意味着我们可以选择在 TLS1.3 协议中使用完整的国密套件，目前我们也在联系正规浏览器厂商支持这个标准的实施和应用。\n同时国密也定义了使用国密算法的 X509 证书，使用 SM3 哈希算法，SM2 算法作为数字签名，证书类型是 SM2-with-SM3。\n对开发者来说，国密提供了一个选择，可以选择从国际通用算法平滑迁移过来。除此之外，国密还有其它一些算法标准，是不太常用的，比如 SM9，ZUC 算法等。\nBabaSSL 前世今生 BabaSSL 是主打国密的密码算法库，与 OpenSSL 1.1.1 保持兼容，作为国密的密码算法解决方案而诞生。\nBabaSSL 是基于之前蚂蚁集团和阿里集团内部的 OpenSSL 版本合并而来，并首次进行了开源。BabaSSL 的含义是：灵巧、轻快且靠谱的密码学和 SSL/TLS 工具库。\nBabaSSL 的绿色商标，是基于阿里的橙色和蚂蚁的蓝色混合而来，也意味着我们希望将 BabaSSL 打造成一个灵活、小巧并且健壮的基础密码学库。\nBabaSSL 目前在阿里集团和蚂蚁集团内部得到了非常广泛的使用。从具体场景来看，有如下三个方面，分别是存储、网络和端上的设备。其中网络服务的场景，是 BabaSSL 最大的支撑场景，例如淘宝、天猫、阿里云等各种涉及到链路加密的服务器端。此外移动端 App，例如支付宝手机 App 中集成了 BabaSSL 来实现多种密码学的能力。\n开源 BabaSSL 已经在去年的 10 月份进行了开源，目前代码是托管在 OpenAnolis 上，当前开源的版本是 8.2.0，也是我们目前最新的稳定版本。\n目前 BabaSSL 在阿里内部使用的版本和开源版本之间存在一定的差异，我们目前正在逐步把内部版本的功能特性迁移到开源版本上进行开源，最终变成一个统一的开源版本，那么届时阿里内部也完全依赖于这个开源的版本，而不会再保留内部的闭源版本。\n特色功能 以下是 BabaSSL 当前最新稳定版本 8.2.0 的主要特色功能特性：\n 基于 OpenSSL 1.1.1，具备 OpenSSL 1.1.1 的全部能力并且保持兼容 支持国密 SM2, SM3 和 SM4，并对 OpenSSL 1.1.1 中所欠缺的 SM2 能力，比如 X509 证书的签发和验证功能进行了补全 GM/T 0024 和 TLCP 国密双证书 TLS 协议 支持 RFC 8998：TLS 1.3+国密单证书 提供了对 IETF 正在标准化过程中的 Delegated Credentials 支持 IETF QUIC API 底层密码学能力 更加完善的 SM2 算法支持，比如 X.509 证书签发、验签的支持 正在申请软件密码模块一级资质 与 OpenSSL 对比 接下来是大家很关心的 BabaSSL 和 OpenSSL 这种老牌的密码算法库之间的区别：\n 从图上可以看到一些主要区别：\n对于一些新的密码学技术标准，BabaSSL 会采取一种相对激进的策略快速跟进，比如在 IETF 中一些正在标准化流程中的技术方案，例如 delegated credentials, compact TLS 等，会进行原型的实现和快速跟进，而 OpenSSL 则是相对保守，因为 OpenSSL 社区的策略是原则上只实现已经发布了的国际标准和国家标准。 在对于国密算法、国密协议、国密的监管合规、云计算厂商的深度集成、以及国产化硬件等方面， BabaSSL 会进行更加深度和广泛的支持，而 OpenSSL 则支持的比较有限。 对于 API 的易用程度，由于没有历史包袱，所以 BabaSSL 可以提供更加简单易用的 API，而OpenSSL 的 API 则相对复杂。对于资源受限的嵌入式设备，BabaSSL 会进行体积裁剪和内 …","date":1623135600,"description":"揭秘 AnolisOS 国密生态，想要看懂这一篇就够了","dir":"blog/the-secret-of-anolisos/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"447fa6eedb1d5ccdea4c37803a2b0dc3","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-secret-of-anolisos/","publishdate":"2021-06-08T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/the-secret-of-anolisos/","summary":"此文原系 2021 年阿里云开发者大会，开源操作系统社区和生态分论坛，题为《国密技术开发与实践》的分享会后解读。 AnolisOS 国密是社区在 AnolisOS 上做的国密技术解决方案","tags":["SOFAStack"],"title":"揭秘 AnolisOS 国密生态，想要看懂这一篇就够了","type":"blog","url":"/sofastack.tech/blog/the-secret-of-anolisos/","wordcount":3702},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@郭晶晶 提问：\n 蚂蚁内部的 SOFAMesh 对 Istio 的 pilot 进行了哪些扩展？是不是内部的 SOFAMesh 才支持 zk 注册中心。\n A：蚂蚁内部用的注册中心是 https://github.com/sofastack/sofa-registry 在服务发现这块是有跟 SOFARegistry 做对接，内部的模块更多还是适应内部的各种配套设置和架构做的一些定制。\nMOSN：https://github.com/mosn/mosn\n2、@王庆振 提问：\n https://github.com/sofastack/sofa-bolt/issuse/257 Connection 对象不应该是对应一个 poolkey（ip:port）吗？为什么 Connection 中还会持有 poolkey 的集合\n A：这个是因为 Bolt 还要服务消息中间件的，消息这边有一个 Connection 对应多个上层对象的场景，poolKey 不是 ip:port 的形式。\nSOFABolt：https://github.com/sofastack/sofa-bolt\n3、@jueming 提问：\n 这一步如果抛出异常，那么是不是不会释放 connection 连接？导致长期占有数据库连接。 A: 会释放，close 是框架层面出现异常自动就会调，如果你自己写 jdbc，你也肯定捕获一次做 rollback close了，这属于框架和业务上的处理，Seata 只不过把异常抛出去。\nSeata：https://github.com/seata/seata\n本周推荐阅读 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案\n 用安全计算保护关键业务\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 本周发布 本周发布详情如下：\n本周发布 MOSN v0.23.0 版本，主要变更如下： 1.新增基于 networkfilter 的 grpc server 扩展实现能力；\n2.新增 TLS 连接的证书缓存，降低内存占用；\n3.修复 HTTP1 协议的 URL 编码与大小写敏感问题；\n4.新增 so plugin 扩展协议实现的示例；\n5.其他 BUG Fix 与优化。\n详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.23.0\n更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1622790000,"description":"SOFA Weekly | MOSN 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210604/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"47a5a019bacbf28f24ea5e9cbad7fc20","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210604/","publishdate":"2021-06-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210604/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210604/","wordcount":951},{"author":"","categories":"SOFAStack","content":" 机器学习（ML）和深度学习（DL）在众多真实的应用场景中愈发重要。这些模型使用已知数据进行训练，并部署在图像分类、内容推荐等场景中进行新数据的处理。总体而言，数据越多，ML/DL 模型就越完善。但囤积和处理海量数据也带来了隐私、安全和监管等风险。 隐私保护机器学习（PPML）有助于化解这些风险。其采用加密技术差分隐私、硬件技术等，旨在处理机器学习任务的同时保护敏感用户数据和训练模型的隐私。 在英特尔® 软件防护扩展（英特尔® SGX）和蚂蚁集团用于英特尔® SGX 的内存安全多进程用户态操作系统 Occlum 的基础上，蚂蚁集团与英特尔合作搭建了 PPML 平台。在本篇博客中，我们将介绍这项运行在 Analytics Zoo 上的解决方案，并展示该解决方案在第三代英特尔® 至强® 可扩展处理器上得到英特尔® 深度学习加速（英特尔® DL Boost）技术助力时的性能优势。\n 英特尔® SGX 是英特尔的受信任执行环境（TEE），它提供基于硬件的内存加密，隔离内存中的特定应用代码和数据。英特尔® SGX 使得用户层代码可以分配内存中的受保护区域，即 “飞地”，这些区域不受更高权限等级程序运行的任何影响（如图一所示）。\n 图一 通过英特尔® SGX 加强防护\n 与同态加密和差分隐私相比，英特尔® SGX 在操作系统、驱动、BIOS、虚拟机管理器或系统管理模型已瘫痪的情况下仍可帮助防御软件攻击。因此，英特尔® SGX 在攻击者完全控制平台的情况下仍可增强对隐私数据和密钥的保护。第三代英特尔® 至强® 可扩展处理器可使 CPU 受信任内存区域增加到 512GB，使得英特尔® SGX 技术能够为隐私保护机器学习解决方案打下坚实的基础。\n2014 年正式成立的蚂蚁集团服务于超 10 亿用户，是全球领先的金融科技企业之一。蚂蚁集团一直积极探索隐私保护机器学习领域，并发起了开源项目 Occlum。Occlum 是用于英特尔® SGX 的内存安全多进程用户态操作系统（LibOS）。使用 Occlum 后，机器学习工作负载等只需修改极少量（甚至无需修改）源代码即可在英特尔® SGX 上运行，以高度透明的方式保护了用户数据的机密性和完整性。用于英特尔® SGX 的 Occlum 架构如图二所示。\n 图二 用于英特尔® SGX 的 Occlum 架构（图片来源：Occlum · GitHub）\n Analytics Zoo 赋能端到端 PPML 解决方案 Analytics Zoo 是面向基于 Apache Spark、Flink 和 Ray 的分布式 TensorFlow、Keras 和 PyTorch 的统一的大数据分析和人工智能平台。使用 Analytics Zoo 后，分析框架、ML/DL 框架和 Python 库可以在 Occlum LibOS 以受保护的方式作为一个整体运行。此外，Analytics Zoo 还提供安全数据访问、安全梯度与参数管理等安全性功能，赋能联邦学习等隐私保护机器学习用例。端到端 Analytics Zoo PPML 解决方案如图三所示。\n 图三 端到端 PPML 解决方案为金融服务、医疗卫生、云服务等应用领域提供安全分布式计算\n 在 Analytics Zoo PPML 平台上，蚂蚁集团与英特尔共同打造了一个更加安全的分布式端到端推理服务流水线（如图四所示）。 该流水线采用 Analytics Zoo Cluster Serving 打造，后者是轻量级分布式实时服务解决方案，支持多种深度学习模型，包括 TensorFlow、PyTorch、Caffe、BigDL 和 OpenVINOTM。 Analytics Zoo Cluster Serving 包括 web 前端、内存数据结构存储 Redis、推理引擎（如面向英特尔® 架构优化的 TensorFlow 或 OpenVINO™ 工具套件），以及分布式流处理框架（如 Apache Flink）。 推理引擎和流处理框架在 Occlum 和英特尔® SGX “飞地” 上运行。web 前端和 Redis 受到传输层安全（TLS）协议加密，因此推理流水线中的数据（包括用户数据和模型）在存储、传输、使用的过程中都受到更多地保护。\n 图四 推理服务流水线\n 共创美好未来：英特尔® DL Boost 加速端到端 PPML 解决方案 1.该解决方案执行如下端到端推理流水线： RESTful http API 接收用户输入，Analytics Zoo pub/sub API 将用户输入转化成输入队列，并由 Redis 管理。用户数据受加密保护。 2.Analytics Zoo 从输入队列中抓取数据。它在分布式流处理框架（如 Apache Flink）上采用推理引擎进行推理。英特尔® SGX 使用 Occlum 来保护推理引擎和分布式流处理框架。英特尔® oneAPI 深度神经网络库（oneDNN）利用支持 Int8 指令集的英特尔® DL Boost 提高分布式推理流水线的性能。 3.Analytics Zoo 从分布式环境中收集推理输出，并送回到由 Redis 管理的输出队列。随后，解决方案使用 RESTful http API 将推理结果作为预测返回给用户。输出队列中的数据和 http 通信内容都被加密。\n性能分析 Analytics Zoo PPML 解决方案的性能进行了验证。\n 表一 测试配置\n 图五为测试结果。与不受英特尔® SGX 保护的推理流水线相比，当推理解决方案受到英特尔® SGX 保护，ResNet50 推理流水线的吞吐量会有少许损失。而采用支持 INT8 指令集的英特尔® DL Boost 后，受英特尔® SGX 保护的推理流水线吞吐量翻了一番。\n 图五 英特尔® SGX、英特尔® DL Boost 和第三代英特尔® 至强® 可扩展处理器提供高性能安全能力\n 基于英特尔® SGX 打造的 Analytics Zoo PPML 解决方案继承了受信任执行环境（TEE）的优点。和其它数据安全解决方案相比，它的安全性和数据效用性十分突出，性能方面仅略逊于纯文本。英特尔® DL Boost 和英特尔® oneDNN 则进一步提升了 Analytics Zoo PPML 推理解决方案的性能。表二总结了该解决方案（TEE）相对于同态加密（HE）、差分隐私（DP）、安全多方计算（MPC）和纯文本的优势。\n 表二 Analytics Zoo PPML 解决方案（TEE）与其他方案的比较\n 总结 在日益复杂的法律和监管环境中，对于企业和组织来说，保护客户数据隐私比以往任何时候都更加重要。在隐私保护机器学习的助力下，企业和组织就能在继续探索强大的人工智能技术的同时，面对大量敏感数据处理降低安全性风险。 Analytics Zoo 隐私保护机器学习解决方案基于 Occlum、英特尔® SGX、英特尔® DL Boost 和 Analytics Zoo 打造，为助力确保数据的安全性和大数据人工智能工作负载性能提供了平台解决方案。蚂蚁集团和英特尔共同打造并验证了这一 PPML 解决方案，并将继续合作探索人工智能和数据安全性领域的最佳实践。\n测试 …","date":1622530800,"description":"助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案","dir":"blog/Helping data security: Ant and Intel work together to create a verified PPML solution/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ccebaadae29c36d85ccb2d8216b6f9b4","permalink":"https://sofastack.github.io/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","publishdate":"2021-06-01T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","summary":"机器学习（ML）和深度学习（DL）在众多真实的应用场景中愈发重要。这些模型使用已知数据进行训练，并部署在图像分类、内容推荐等场景中进行新数据","tags":["SOFAStack"],"title":"助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案","type":"blog","url":"/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","wordcount":2757},{"author":"顾宗敏","categories":"SOFAStack","content":" 什么是安全计算？ Linux 基金会旗下的安全计算联盟对安全计算下了一个定义：\n Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential Computing Consortium\n 在这个定义中强调了这么几点：\n1.安全计算保护的是运算过程中的数据安全;\n2.安全计算需要借助硬件的能力。\n下面就对这两点做一个阐述： 在云计算场景，我们可以把云计算简化为三个部分：数据的传输，数据的运算和数据的存储。\n 这个三个部分的安全解决方案的完整度是有差别的。在数据的传输环节，业界有很完整的安全标准和实现比如 SSL， TLS。在数据存储环节，密码学也提供了非常好的解决方案，我们可以将数据用恰当的方式加密以后保存，防止在存储环节泄密。在数据的运算环节，还没有和其他两个环节那样完整的解决方案。安全计算正是以解决这个问题为目标的。\n安全计算是如何实现的呢？ 我们以英特尔的 SGX 技术为例来看一下具体的技术方案。\n 英特尔的 SGX 技术是将 CPU 作为运算的信任起点，在应用程序中构建安全的运算环境（飞地）。从计算机发明的那一天起，我们就假设 CPU 会按照软件的指令正确地执行，只是没有强调这一点。在软件大发展的今天，各种软件在一台硬件上协作运行，整个生态越来越复杂，恶意软件也出现了。为了防止恶意软件的破坏，CPU 为需要保护的应用隔离出一个独立的飞地环境。飞地外的应用既不能观察也不能修改飞地中的代码和数据，从而保证了飞地中的数据安全。CPU 对飞地的保护非常强，即使是拥有高特权的操作系统和虚拟化管理软件也无法突破这种保护。事实上，不仅仅可以防软件的攻击，哪怕是外围硬件提供者（比如：主板制造者，内存提供者）都无法突破这个保护。\n英特尔 SGX 是目前最成熟的安全计算产品，但并不是唯一的安全计算产品。其他硬件厂商如 AMD，ARM，Nvidia 都在推出安全计算产品。所有这些产品都是软硬件一体的解决方案，总结起来有以下这些特点：\n 在了解了安全计算的概念后，介绍一些安全计算的典型场景：\n 有了安全计算环境，用户可以放心地将应用放到共有云计算环境中，计算中用到的数据和计算的结果都可以加密传输。这样可以统一基础设施的架构，避免复杂的混合云部署方式。\n 云上的数据交易和数据服务也成为了可能。数据拥有方和算法提供方可以分别提供数据和算法至安全计算平台完成计算而不用担心机密泄露的问题。\n 安全计算也可以促成更多的数据合作。各方数据可以在一个安全的环境中做融合运算，让数据产生更大的价值。\n 在边缘计算场景中，计算节点部署在非常复杂的环境中，机器不受控。安全计算可以有效地保护用户数据和隐私。\n安全计算这么多的应用场景，为什么还没有看到大规模部署呢？这是因为安全计算目前还有一个非常大的短板：易用性不强。具体表现为3点：\n应用分割难：将一个现有的应用改造为一个安全计算应用的改造难度很大。需要做代码分割。\n场景部署难：安全计算是要依托于硬件的。在实际部署中需要对应用调度系统做改造。\n安全分析难：一个应用使用了安全计算是不是就一定安全了呢？答案是不确定。这需要对整个应用做非常细致的安全分析。\n针对这些难题，蚂蚁集团和阿里巴巴集团的工程师提出了独到的解决方案。 首先是解决应用分割难的问题。\n 蚂蚁集团开源的 Occlum 项目在飞地中开发了 LibOS 适配层，让 Linux 下的应用可以无修改地运行在 SGX 环境中，彻底解决了应用分割的问题。Occlum 使用 Rust 语言开发，保证内存了安全性；支持多进程和加密文件系统，应用无需修改。 例如：基于蚂蚁集团金融级云原生框架 SOFABoot 开发的应用可以完全无修改的运行在 Occlum 环境中。\n👇网站链接🔗： https://github.com/occlum/occlum/tree/master/demos/sofaboot\n针对部署难的问题，阿里云推出了 Inclavare 开源项目。\n Inclavare 基于 Occlum，为用户提供了安全计算容器。用户只需将关注的重点放在应用本身即可，Inclavare 会将计算调度至合适的计算节点。 针对安全分析难，蚂蚁集团的 MORSE 多方安全计算引擎和 MYTF 区块链计算平台分别为不同的计算场景提供了解决方案。用户无需再承担高昂的安全分析成本。\n 蚂蚁集团在安全计算领域持续投入，用科技的力量来保护数据安全，保护用户隐私，给用户提供更安全的服务。蚂蚁集团开源了 TEE 安全 LibOS Occlum。 用户可以在 https://github.com/occlum/occlum 找到所有的实现代码。用户既可以审查 Occlum 的源代码，以确保整体方案的安全性；也可以参考已有的 demo 来学习 Occlum 的使用方法，快速上手安全计算。\n本周推荐阅读 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 金融级能力成核心竞争力，服务网格驱动企业创新\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1622530800,"description":"用安全计算保护关键业务","dir":"blog/Protecting Critical Operations with Secure Computing/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"800c9227ecb01253319dc8df2eb14d68","permalink":"https://sofastack.github.io/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","publishdate":"2021-06-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","summary":"什么是安全计算？ Linux 基金会旗下的安全计算联盟对安全计算下了一个定义： Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential Computing Consortium 在这个定义中强调了这么几点： 1.安全计","tags":["SOFAStack"],"title":"用安全计算保护关键业务","type":"blog","url":"/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","wordcount":1810},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@非余 提问：\n 对于 Kata 我有些地方还是不太理解，我现在说说我的理解，麻烦你看对不 对，我的理解是 Kata 有两个缓存： 1. virtiofs 需要一个缓存。virtiofsd 和 guest 交互需要缓存做文件系统 buffer ，这个缓存的对应 qemu 的参数就是 memory-backend-file 。（这个缓存和 vhost-user 使用的 vring 是不是同一个？每一个 vm 有自己的缓存空间 ） 在 Kata 配置文件对应的是 default_memory。缓存策略是 virtio_fs_cache。 2. dax 缓存，对应的参数是 virtio_fs_cache_size，没有缓存策略控制。\n A：1、是的；2、dax的缓存控制是依靠guest的文件系统语义实现的。\nSOFAStack：https://github.com/sofastack\n2、@张鹏科 提问：\n SofaReferenceBinding 这个注解有一个属性：serializeType，默认序列化协议使用的是 Hessian2，我想替换成 protobuf，我看文档说这个目前不支持在注解中替换，只能以 xml 的方式。有点蒙，到底支持不支持？\n A：支持。\nSOFAStack：https://github.com/sofastack\n3、@jueming 提问：\n 请问一下 sofa-rpc和 Dubbo 区别在哪呢，是不是可以无缝接入 mosn sidecar？\n A: 核心差别目前主要是在协议上吧，协议的可扩展性双方都有，SOFARPC 的 Bolt 协议是基于最早 HSF 协议的一些痛点做了改良设计，整个协议的请求头是能包含更多信息，比如在 MOSN 里支持 Bolt 协议，整个请求在 MOSN 内只解析 header 就可以拿到足够信息做路由，header 的解析也是类似简单 kv 的方式，Dubbo 使用的协议在 Mosn 或者 Envoy 里需要做 Hessian 反序列化才能拿到足够的信息，性能损耗会稍微大一点，其他方面的扩展性上机制略有不同，但是都有比较强的扩展能力。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n4、@汪辉 提问\n Caused by:io.seata.core.exception.TmTransactionException: TransactionException[begin global request failed. xid=null, msg=Communications link failure. 请问这个 突然没有 xid 是什么情况？\n A：因为是 begin 时的异常，所以没有 xid，begin 成功了才有 Communications link failure。\nSeata：https://github.com/seata/seata\n5、@贾云森 提问\n 常见的就是并没有对 Select 语句进行 forupdate,如果你不开启 forupdate,Seata 默认是遇到并发性竞争锁并不会去尝试重试,导致拿不到 lock 当前事务进行回滚.不影响一致性,如果你想没 forupdate 也开启竞争锁client.rm.lock.retryPolicyBranchRollbackOnConflict 设置为 false（有死锁风险）。 请问是参数开启会出现死锁风险，还是自己手动添加 forupdate ，也会出现死锁风险呢？\n A：不加for update，也会竞争锁。但是因为可能存在二阶段需要回滚的事务，所以retryPolicyBranchRollbackOnConflict 为 true 的时候，优先会给需要回滚的事务进行回滚，所以需要放弃锁，这是 at 模式的一个缺陷。因为 at 就是 2 个锁，1 先获取数据库本地锁，2 获取全局，此事后如果获取全局锁后会释放本地锁，造成了死锁。所以 at 上出现 get global lock fail 是正常的，自己应该在业务上做好重试，当一个全局事务因为获取锁失败的时候，应该重新完整的发起，所谓的完整应该是从 globaltransational 的 tm 端重新发起。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周 sofa-rpc 发布 v5.7.8 版本代码。主要更新如下：\n 支持 Dubbo service version 设置 修复 tracer 采样标志位无法正确透传的问题 修复重试逻辑中丢失最初异常的问题 详细参考： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.8\n","date":1622185200,"description":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20200528/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c1c3882d7e68e5fce4c25a088adaa109","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200528/","publishdate":"2021-05-28T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200528/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200528/","wordcount":1758},{"author":"章耿","categories":"SOFAStack","content":" Mesh 模式的引入是实现应用云原生的关键路径，蚂蚁集团已在内部实现大规模落地。随着 Message、DB、Cache Mesh 等更多的中间件能力的下沉，从 Mesh 演进而来的应用运行时将是中间件技术的未来形态。应用运行时旨在帮助开发人员快速的构建云原生应用，帮助应用和基础设施进一步解耦，而应用运行时最核心是 API 标准，期望社区一起共建。\n 蚂蚁集团 Mesh 化介绍 蚂蚁是一家技术和创新驱动的公司，从最早淘宝里的一个支付应用，到现在服务 全球十二亿用户的大型公司，蚂蚁的技术架构演进大概会分为如下几个阶段：\n2006 之前，最早的支付宝就是一个集中式的单体应用，不同的业务做了模块化的开发。\n2007 年的时候，随着更多场景支付的推广，开始做了一下应用、数据的拆分，做了 SOA 化的一些改造。\n2010 年之后，推出了快捷支付，移动支付，支撑双十一，还有余额宝等现象级产品，用户数到了亿这个级别，蚂蚁的应用数也数量级的增长，蚂蚁自研了很多全套的微服务中间件去支撑蚂蚁的业务；\n2014 年，像借呗花呗、线下支付、更多场景更多业务形态的出现，对蚂蚁的可用性和稳定性提出更高的要求，蚂蚁对微服务中间件进行了 LDC 单元化的支持，支撑业务的异地多活，以及为了支撑双十一超大流量的混合云上的弹性扩缩容。\n2018 年，蚂蚁的业务不仅仅是数字金融，还有数字生活、国际化等一些新战略的出现，促使我们要有更加高效的技术架构能让业务跑得更快更稳，所以蚂蚁结合业界比较流行的云原生的理念，在内部进行了 Service Mesh、Serverless、可信原生方向的一些落地。\n 可以看到蚂蚁的技术架构也是跟随公司的业务创新不断演进的，前面的从集中式到 SOA 再到微服务的过程，相信搞过微服务的同学都深有体会，而从微服务到云原生的实践是蚂蚁近几年自己探索出来的。\n为什么要引入 Service Mesh 蚂蚁既然有一套完整的微服务治理中间件，那为什么还需要引入 Service Mesh 呢？\n 拿蚂蚁自研的服务框架 SOFARPC 为例，它是一个功能强大的 SDK，包含了服务发现、路由、熔断限流等一系列能力。在一个基本的 SOFA(Java) 应用里，业务代码集成了 SOFARPC 的 SDK，两者在一个进程里运行。在蚂蚁的大规模落地微服务之后，我们就面临了如下的一些问题：\n升级成本高：SDK 是需要业务代码引入的，每次的升级都需要应用修改代码进行发布。由于应用规模较大，在一些大的技术变更或者安全问题修复的时候。每次需要数千个应用一起升级，费时费力。 版本碎片化：由于升级成本高，SDK 版本碎片化严重，这就导致我们写代码的时候需要兼容历史逻辑，整体技术演进困难。 跨语言无法治理：蚂蚁的中后台在线应用大多使用 Java 作为技术栈，但是在前台、AI、大数据等领域有很多的跨语言应用，例如 C++/Python/Golang 等等，由于没有对应语言的 SDK，他们的服务治理能力其实是缺失的。\n我们注意到云原生里有 Service Mesh 一些理念开始出现，所以开始往这个方向探索。在 Service Mesh 的理念里，有两个概念，一个是 Control Plane 控制平面，一个是 Data Plane 数据平面。控制面这里暂时不展开，其中数据平面的核心思想就是解耦，将一些业务无需关系的复杂逻辑（如 RPC 调用里的服务发现、服务路由、熔断限流、安全）抽象到一个独立进程里去。只要保持业务和独立进程的通信协议不变，这些能力的演进可以跟随这个独立的进程自主升级，整个 Mesh 就可以做到统一演进。而我们的跨语言应用，只要流量是经过我们的 Data Plane 的，都可以享受到刚才提到的各种服务治理相关的能力，应用对底层的基础设施能力是透明的，真正的云原生的。\n蚂蚁 Mesh 落地过程 所以从 2017 年底开始，蚂蚁就开始探索 Service Mesh 的技术方向，并提出了 基础设施统一，业务无感升级 的愿景。主要的里程碑就是：\n2017 年底开始技术预研 Service Mesh 技术，并确定为未来发展方向；\n2018 年初开始用 Golang 自研 Sidecar MOSN 并开源，主要支持 RPC 在双十一小范围试点；\n2019 年 618，新增 Message Mesh 和 DB Mesh 的形态，覆盖若干核心链路，支撑 618 大促；\n2019 年双十一，覆盖了所有大促核心链路几百个应用，支撑当时的双十一大促；\n2020 年双十一，全站超过 80% 的在线应用接入了 Mesh 化，整套 Mesh 体系也具备了 2 个月从能力开发到全站升级完成的能力。\n蚂蚁 Mesh 落地架构 目前 Mesh 化在蚂蚁落地规模是应用约数千个，容器数十万的级别，这个规模的落地，在业界是数一数二的，根本就没有前人的路可以学习，所以蚂蚁在落地过程中，也建设一套完整的研发运维体系去支撑蚂蚁的 Mesh 化。\n 蚂蚁 Mesh 架构大概如图所示，底下是我们的控制平面，里面部署了服务治理中心、PaaS、监控中心等平台的服务端，都是现有的一些产品。还有就是我们的运维体系，包括研发平台和 PaaS 平台。那中间是我们的主角数据平面 MOSN，里面管理了 RPC、消息、MVC、任务四种流量，还有健康检查、监控、配置、安全、技术风险都下沉的基础能力，同时 MOSN 也屏蔽了业务和基础平台的一些交互。DBMesh 在蚂蚁是一个独立的产品，图里就没画出来。然后最上层是我们的一些应用，目前支持 Java、Nodejs 等多种语言的接入。 对应用来说，Mesh 虽然能做到基础设施解耦，但是接入还是需要一次额外的升级成本，所以为了推进应用的接入，蚂蚁做了整个研发运维流程的打通，包括在现有框架上做最简化的接入，通过分批推进把控风险和进度，让新应用默认接入 Mesh 化等一些事情。\n同时随着下沉能力的越来越多，各个能力之前也面临了研发协作的一些问题，甚至互相影响性能和稳定性的问题，所以对于 Mesh 自身的研发效能，我们也做了一下模块化隔离、新能力动态插拔、自动回归等改进，目前一个下沉能力从开发到全站推广完成可以在 2 个月内完成。\n云原生应用运行时上的探索 大规模落地后的新问题与思考\n蚂蚁 Mesh 大规模落地之后，目前我们遇到了一些新的问题： 跨语言 SDK 的维护成本高：拿 RPC 举例，大部分逻辑已经下沉到了 MOSN 里，但是还有一部分通信编解码协议的逻辑是在 Java 的一个轻量级 SDK 里的，这个 SDK 还是有一定的维护成本的，有多少个语言就有多少个轻量级 SDK，一个团队不可能有精通所有语言的研发，所以这个轻量级 SDK 的代码质量就是一个问题。\n业务兼容不同环境的新场景：蚂蚁的一部分应用是既部署在蚂蚁内部，也对外输出到金融机构的。当它们部署到蚂蚁时，对接的是蚂蚁的控制面，当对接到银行的时候，对接的是银行已有的控制面。目前大多数应用的做法是自己在代码里封装一层，遇到不支持的组件就临时支持对接一下。\n从 Service Mesh 到 Multi-Mesh：蚂蚁最早的场景是 Service Mesh，MOSN 通过网络连接代理的方式进行了 …","date":1621926000,"description":"蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海 ","dir":"blog/Exploration and Practice of AntCloud Native Application Runtime - ArchSummit Shanghai/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"da69750163f92aa73f15821202ee07e6","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","publishdate":"2021-05-25T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","summary":"Mesh 模式的引入是实现应用云原生的关键路径，蚂蚁集团已在内部实现大规模落地。随着 Message、DB、Cache Mesh 等更多的中间件能力的下沉，从 Mesh","tags":["SOFAStack"],"title":"蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海 ","type":"blog","url":"/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","wordcount":4840},{"author":"SOFAStack社区","categories":"Summer 2021","content":"警告警告⚠️暑期即将到来，\n在暑期到来之前你有没有考虑过这样一个问题？\n那就是这个夏天怎么过？\n我相信你读完问题后脑海里浮现出了 N 多个想法，我相信那都是对你有意义的，但是你有没有考虑过让这个夏天过的更有“意义”一些。\n让你在这个夏天不仅可以让还是学生的你参与到知名开源项目，体验开源文化，与开源社区导师一同交流探讨的同时又可以收获一笔不菲的奖金，最重要的是可以获得一份特别亮眼的项目经历！！！\n动没动心？？？❤️\n 2021年的夏天被称为“开源之夏”\n那么什么是“开源之夏”？\n“开源之夏”全名开源软件供应链计划-暑期2021，是由中国科学院软件研究所与 openEuler 社区共同举办的一项面向高校学生的暑期活动，是一项专门面向高校学生的开源项目开发活动，旨在鼓励在校学生积极参与开源软件的开发维护。主办方联合各大开源社区，针对对重要开源软件的开发与维护提供项目任务，学生根据兴趣申请项目，中选后将在社区导师指导下进行开发，并将成果贡献给社区。根据项目的难易程度和完成情况，学生将获得 6000、9000、12000元不等的项目奖金。完成SOFAStack社区项目的优秀贡献者可以获得蚂蚁内推机会（蚂蚁中间件团队很多优秀的工程师都是被挖过来的开源社区贡献者🤫）\n活动官网：https://summer.iscas.ac.cn/\n暑期 2021 项目任务活动自发布以来，众多开源社区踊跃报名，5 月 20 日社区报名截止，共有 109 家海内外社区报名，并上线了 877 个开源项目任务。其中 SOFAStack 社区上线了 9 个项目任务，包含云计算、云原生、分布式系统、微服务中间件、前端等多个方向结合的项目任务，涉及的开源项目包括：JRaft、SOFA-RPC、SOFA-Registry、SOFADashboard、SOFATracer，有中、高等级不同难度的任务以供选择。\nSOFAStack 社区项目任务列表：https://summer.iscas.ac.cn/#/org/orgdetail/s\nsofastack 学生指南：https://summer.iscas.ac.cn/help/student/\n学生如何申请？\n学生申请通道 5 月 24 号正式开放啦！\n申请时间：5 月 24 日\u0026amp;ndash; 6 月 13 日\nSTEP 1 ：查看项目任务列表，你感兴趣的任务。可同步在官网报名系统注册账号进行报名。\n报名系统：\nhttps://portal.summer-ospp.ac.cn/summer/login\n STEP 2：就感兴趣的任务与对应的导师取得联系，沟通清楚项目需求，也可就项目方案和导师讨论。\nSTEP 3：撰写项目申请书，并在报名系统提交项目申请书和个人简历。\nSTEP 4：6 月 30 号公布中选结果，中选学生在导师指导下，按计划在 7-9 月进行开发。\nSTEP 5：完成开发，获得项目奖金和证书。\n详情可进一步阅读暑期 2021 学生指南：https://summer.iscas.ac.cn/help/student/\n暑期 2021 面向人群 本活动面向年满 18 周岁在校学生，不限国籍暑期即将毕业的学生，只要在申请时学生证处在有效期内，就可以提交申请海外学生可提供录取通知书/学生卡/在读证明证明学生身份\n ","date":1621839600,"description":"“开源之夏” SOFAStack 社区 9 个项目任务上线，学生申请正式开始！","dir":"activities/Summer 2021 of Open Source Promotion Plan/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9917f037c993814f23d2049396c438eb","permalink":"https://sofastack.github.io/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","publishdate":"2021-05-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","summary":"警告警告⚠️暑期即将到来， 在暑期到来之前你有没有考虑过这样一个问题？ 那就是这个夏天怎么过？ 我相信你读完问题后脑海里浮现出了 N 多个想法，我相信","tags":["Summer 2021"],"title":"“开源之夏” SOFAStack 社区 9 个项目任务上线，学生申请正式开始！","type":"activities","url":"/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","wordcount":1198},{"author":"朵晓东","categories":"SOFAStack","content":" 本文是云原生开放协同技术探索与实践一阶段的总结和综述。\n蚂蚁基础技术在过去3年多以来持续、深入推进全面的云原生化技术演进，我们将在线、离线计算资源装进了一台计算机，将服务体系通过 mesh 的思路和技术手段进行了下沉解耦，可以说比较充分的拥抱了云原生技术，并获取了其带来的技术红利。\n当完成了资源、服务的云原生化，我们发现在云原生基础能力之上的运维体系与云原生技术开放、共享的思路有较大的距离，在技术体系上也与云原生技术声明式、白盒化的思路相悖，同时由于缺少匹配的技术支撑，历史包袱等问题也成为了云原生运维难以真正代际演进的障碍。今天我要介绍的就是蚂蚁在这样的背景下在云原生运维方向进行的技术探索和实践。\n规模化云原生运维探索 我们先来回顾一下在蚂蚁真实的实践方式和面对的问题。首先，我们来看看蚂蚁践行多年的经典运维中台，这类运维平台一般包括了控制器、业务模型、编排引擎、原子任务及管道，在蚂蚁这样的平台是一系列服务的集合，他们较好的满足了集中式、标准化、低变更频率的应用发布及运维需求。但这种模式在实践中也存在着明显的不足。\n首先对于非标准应用、应用个性化需求、高成本需求、非紧急需求、技改类需求，往往无法较好的满足。在蚂蚁的实践中，非标运维需求、对核心应用模型及运维模型冲击较大的高成本改造需求、大量基础能力或运维功能的透出需求等长期无法得到较好的满足，需求往往是合理的，是难以获得足够的优先级执行落地。在研发阶段，运维平台长期积累了高复杂度的业务逻辑，修改测试涉及跨系统的长改造链路，同时基础能力的透出、运维能力的产品化依赖前端、服务端研发资源。这些问题使得运维平台研发日渐吃力，特别是在产品 GUI、业务模型、编排引擎等变更热点上，受限于扩展机制能力不足，内部实践中甚至出现过线上不断修改代码、发布服务以满足需求的情况。平台上线后，统一的质保和线上全链路功能验证同样面对较大的压力。对于最终的使用者，命令式按钮背后的黑盒计算透明度低，审计难，结果难预测，同时激情操作、操作界面不熟悉等问题也一直影响着线上的稳定性。这些问题长期存在，我们寄希望于代际的技术演进来解决这些问题。 \u0026amp;gt;当云原生基础服务逐渐稳定后，对于自身场景不在运维平台管理范围内的应用，研发同学自发的借助云原生社区工具链解决问题。基于 Kubernetes 生态高度开放、高度可配置的特点，研发者可以自助、灵活、透明的声明式应用运行、运维需求，以应用粒度完成发布、运维操作。\n用户通过 kustomize 等社区技术缩短了对接基础设施的路径，并通过如 velocity 等文本模板技术部分解决了静态 YAML 文件在较多变量时维度爆炸的问题，解决了默认值设定的问题，同时通过 code review 的方式进行多因子变更及评审。由于 Kubernetes 及其生态提供了面向资源、服务、运维、安全的横向能力，使得这种简单的方式可有很好的普遍性和适用性，通过对不同的 Kubernetes 集群 “播放” 这些数据即可完成对基础设施的变更，本质上是一种声明数据的流转。面向 git 仓库的研发方式和 gitops 流程支持对运维产品研发资源的诉求较低，往往可以比较简单的搭建起来，不强依赖产品研发资源投入。相比经典运维中台，这些好处清晰明确，但从工程视角缺点也非常明显。 \u0026amp;gt;首先 Kubernetes API 的设计较为复杂，仅是 Kubernetes 原生提供的 low level API 就暴露了 500 多种模型，2000 多字段，场景上几乎涵盖了基础设施应用层的方方面面，即使是专业同学也很难理解所有细节。其次这种方式的工程化程度很低，违反 DRY 原则，违反各团队职责能力高内聚低耦合的原则，即使在有一定的工具支持的情况下，在内部的典型案例中一个多应用的 infra 项目仍然维护了多达 5 万多行 YAML，同时由于团队边界造成的多个割裂的平台，用户需在多个平台间切换，每个平台的操作方式各异，加上跳板机黑屏命令，完成一次完整的发布需要 2 天时间。\n由于低工程化程度的问题，各团队间协同依赖人肉拉群同步，最终 YAML 由多个团队定义的部分组合而成，其中一大部分属于 Kubernetes 及运维平台团队的定义，这些内容需要持续跟踪同步避免腐化，长期维护成本高。\nKUSION: 云原生开放协同技术栈 以上两种模式各有利弊，优势和问题都比较清晰。那么能不能既要也要呢，能不能在继承经典运维平台优势的情况下，充分利用云原生技术带来的红利，打造一个开放、透明、可协同的运维体系？\n带着这样的问题，我们进行了探索和实践，并创建了基于基础设施代码化思路的云原生可编程技术栈 Kusion。\n大家都知道 Kubernetes 提供了声明式的 low level API，提倡其上生态能力通过 CRD 扩展的方式定义并提供服务，整个生态遵循统一的 API 规范约束，复用 API 技术和工具。Kubernetes API 规范提倡 low level API 对象松耦合、可复用，以支持 high level API 由 low level API “组合” 而成。Kubernetes 自身提供了利于开源传播的极简方案，并不包括 API 之上的技术和方案。\n回到云原生技术的本源，我们回看了 Kubernetes 前身 Borg 的应用技术生态。如下图示，在 BorgMaster 之上，Borg 团队研发了 Borg 接入三件套，即 BCL（Borg Configuration Language），Command-line tools，以及相应的 web service。用户可以通过 BCL 声明式编写需求，通过 Command-line tools 将 BCL 文件执行到 Borg 集群，并通过 web GUI 视图查看任务细节。经过大量的调研，我们了解到 Google 内部的运维能力及产品生态、质量技术生态都依赖这三件套构建而成，在内部也进行了多年的迭代演进。 \u0026amp;gt;这给了我们启发，今天我们有了容器技术、服务体系，有了大量用户和差异化的需求，有了一定数量的自动化运维平台，我们希望能通过云原生专用的语言和工具来链接 Kubernetes 生态、各个运维平台以及大量的用户，通过唯一事实定义消除运维平台孤岛，完成云原生基础设施在应用、运维层面的代际演进，达到 “Fusion on Kubernetes” 的目标。\n带着这样的目标，我们持续地进行做技术探索和实践，目前已经形成了 Kusion 技术栈，并在蚂蚁的生产实践中进行应用。 \u0026amp;gt;Kusion 技术栈基于这样的基础能力而工作，包括如下组成部分：\n云原生配置策略专用语言 KCL (Kusion Configuration Language)\nKCL 解释器及其 Plugin 扩展机制\nKCL 研发工具集: Lint, Format, Doc-Gen，IDE Plugin(IDEA, VsCode)\nKusion Kubernetes 生态工具: OpenAPI-tool, KusionCtl(Srv)\nKonfig 配置代码库，其中包括平台侧及用户侧代码\nOCMP (Open CloudNative Management …","date":1621321200,"description":"带你走进云原生技术：云原生开放运维体系探索和实践","dir":"blog/Take you into cloud-native technology: cloud-native open operation and maintenance system exploration and practice/","fuzzywordcount":10400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"365cd296d63b8ea2fa2e70b06830c734","permalink":"https://sofastack.github.io/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","publishdate":"2021-05-18T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","summary":"本文是云原生开放协同技术探索与实践一阶段的总结和综述。 蚂蚁基础技术在过去3年多以来持续、深入推进全面的云原生化技术演进，我们将在线、离线计算","tags":["SOFAStack"],"title":"带你走进云原生技术：云原生开放运维体系探索和实践","type":"blog","url":"/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","wordcount":10395},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@姚远 提问：\n 请问下 SOFAArk，master-biz 是个 Spring Boot 应用，A-biz 是个普通的Spring，一起打成一个 Executable-Ark 包。那么 Spring 相关的 Jar 是不是就要加载 2 次。 A：如果没有下沉插件的话，是会加载两次。\n SOFAArk：https://github.com/sofastack/sofa-ark\n@colin 提问：\n 内部服务之间的路由策略，是推荐用 service-mesh 来做吗？还是内部服务之间也用服务网关？ A：内部东西向流量推荐走 mesh ，一般来说网关更适合做南北向网络边界上的出入口。\n MOSN：https://github.com/mosn/mosn/\n@colin 提问：\n 这种场景，推荐用网关还是 service-mesh？目前我们是自己的内部网关来做的，网络不隔离，只是 jvm 进程隔离。 A：如果逻辑上也不隔离，互相能够服务发现，互相信任不需要额外鉴权的话，可以认为是内部流量，走 mesh 比走集中式的网关更合适。如果逻辑隔离，那么走网关比较合理。\n MOSN：https://github.com/mosn/mosn/\n@骆伟康 提问：\n 请问一下 这里我使用 dynamic 多数据源 结合 Seata 但是为啥只回滚了主库的数据 另外的库回滚失败？ A：看官网 FAQ，关闭 Seata 的自动代理，mp 的 dynamic 组件你开启他的 Seata 开关他自己会代理的。\n Seata：https://github.com/seata/seata\n@贾云森 提问：\n Could not commit JDBC transaction; nested exception is io.seata.rm.datasource.exec.LockConflictException: get global lock fail, xid:192.168.3.239:8092:138223831620784128, lockKeys:outpat_medical:135231296034705408,135231296034705409,135231296034705410,135231296034705411,135231296034705412,135231296034705413)\u0026amp;ldquo;,\u0026amp;ldquo;code\u0026amp;rdquo;:85550,\u0026amp;ldquo;data\u0026amp;rdquo;:null,\u0026amp;ldquo;time\u0026amp;rdquo;:\u0026amp;ldquo;2021-05-19 10:12:10\u0026amp;rdquo; 想问一下为什么会发生这种异常啊？ A：正常输出，竞争锁没竞争到。\n Seata：https://github.com/seata/seata\n@winyQ 提问：\n 项目里 Seata 用 AT 模式，可以在项目里再集成 JTA 吗，两个并存有没有什么问题？ A：JTA 是 XA ，无法跟 AT 兼容。\n Seata：https://github.com/seata/seata\n本周推荐阅读 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 金融级能力成核心竞争力，服务网格驱动企业创新\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n 本周发布 本周发布详情如下：\n本周 SOFAJRaft 发布 1.3.7 版本，主要更新如下：\n 1.修复 TCP 建连被 block 导致选主超时 2.升级 commons.io 到 2.8.0 以修复安全漏洞\n详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.7\n ","date":1621234800,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210521/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d7be1cbefe37ff9c846ea84f7ad52755","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210521/","publishdate":"2021-05-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210521/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210521/","wordcount":1146},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张思雨提问：\n 我配置中心里加了 transport.threadFactory.clientSelectorThreadSize\u0026amp;hellip;设置了个 100，这个值是不是一般设置成 cpu 核数*2 就够了啊？ 我之前遇到了 tc 调客户端的 commit 超时。我就把这种值都调大了试试效果 ， transport.threadFactory.clientSelectorThreadSize 100 transport.threadFactory.workerThreadSize 3000\n A：线程数这个东西这不该开放出去，很危险，对 netty 了解一点应该也知道 NioEventLoopGroup 的最多应该就核心数的两倍。 Seata：https://github.com/seata/seata\n2、@林南行提问：\n 大家好，请教一个问题：我现在用的 seata-server 的 1.3.0 的版本，客户端用的是 1.4.1 版本。当同时启动 10+个微服务连接 seata-server 的时候，只有 10 个能注册成功，剩余的必须重启后才能重新注册成功，这个是什么问题呢？\n A：试一下把 logSerialization 改成 kyro。 Seata：https://github.com/seata/seata\n3、@林南行提问：\n seata-server-1.3.0 和 seata-server-1.4.2 在配置上有什么区别吗？ 两边的 registry.conf 配置是一样的，但是 1.3.0 能正常启动，1.4.2 就报错，global_table 找不到。\n A：没区别，说明配置有问题，看看 global_table 写了没，写了的话，写的是什么，配置中心是什么，检查清除。 Seata：https://github.com/seata/seata\n4、@潘顾昌提问：\n 请问什么情况这个状态会是 Finished？现在导致这部分数据没有提交，但是也没有报错，正常的数据提交后看到的都是这个。 现在有些情况会返回 Finished，导致没有正常提交。\n A：事务结束了不就是 Finished，自己服务降级了吧，导致没回滚，部分插入部分没插入了。 Seata：https://github.com/seata/seata\n5、@潘顾昌提问：\n Finished 已经插入的数据会回滚丢失吗？我们后台实时监控到，一开始是插入到数据库的，确实是有的，但是结束以后数据就丢失了\n A：seata 没有执行二阶段回滚，不会消失数据，数据丢失要么是本地事务发生异常，你们捕获异常了，用 spring API 来回滚了本地事务，导致异常没抛出去，事务回滚了，要么发生异常，被你们的全局异常捕获器捕获了，导致决议了提交，实际上数据已经被本地事务回滚，seata 在二阶段不是 rollback 相关状态的时候不会干预业务数据。 Seata：https://github.com/seata/seata\n本周推荐阅读\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n Rust 大展拳脚的新兴领域：机密计算\n 开源项目是如何让这个世界更安全的？\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周发布详情如下：\n本周 sofa-registry 发布 V6-alpha 代码，本版本不建议生产使用，正式版本会在近期 release。主要更新如下：\n 支持应用级服务发现 基于 slot 分配的数据分片存储 详细参考：https://github.com/sofastack/sofa-registry/tree/v6-alpha1 文章解读：https://mp.weixin.qq.com/s/-5oK-EuZWpvIATvTzSMRAw\n","date":1620975600,"description":"SOFA WEEKLY | SOFARegistry 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210514/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7c193377953cba7840c05a3ff7d6d4ec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210514/","publishdate":"2021-05-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210514/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARegistry 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210514/","wordcount":1488},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@Chrosing 提问：\n Seata 被锁的 xid 数据 一直卡住的时候， 为啥丢失了一部分 undo_log 语句？导致直接删除 lock_table 的 xid 时候，没有回滚数据回去，当前版本 1.3.0。\n A：不会丢 undolog，只可能回滚了部分，部分因为脏写了导致没法回滚，这部分的 undolog 留着；所以看起来 undolog 少了，其实是分支回滚调了，留着的都是没有回滚的。\nSeata：https://github.com/seata/seata\n2、@洪波森 提问：\n 这算一个 bug 吗，永远跑不进来？\n A：不是，读不到你事务分组对应的值，就是 null。\nSeata：https://github.com/seata/seata\n3、@陈承邦 提问：\n sharding-transaction-base-seata-at 这个包只对 Seata 做了代理，我看了一早上源码，直接用 Seata 包 好像也不影响 分布式事务\n A：Seata 无法找到具体那个 datasource，Seata 只能代理 sharding-jdbc 最外层的 datasource，这个 datasource 里面有 N 个 datasource 来实现分库分表的功能，这个才是真正对数据库的 Seata：https://github.com/seata/seata\n4、@杨政伟 提问：\n 请教一个问题，如果 A 方法调用 B 方法，B 方法启用了事务，并发生异常时，但 B 方法并没有回滚，怎么能实现 B 方法的回滚？\n A：在同一个类里面被其他方法调用，是不能开启事务的，看一下 aop 的机制。a 是个实例 cglib 代理了 a 成为了一个包装了它的实例，此时你直接调了内部的实例，怎么走到它的切面去呢？\nSeata：https://github.com/seata/seata\n本周推荐阅读 下一代机密计算即将到来：性能比肩普通应用\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n Rust 大展拳脚的新兴领域：机密计算\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n ","date":1620370800,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-20210507/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4606adcc9195341f35c6dd05b0e93da1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210507/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210507/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210507/","wordcount":957},{"author":"英花","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#20：用安全计算保护关键业务\n 活动时间：05 月 19 日周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#20：用安全计算保护关键业务 随着全社会对隐私保护越来越关注安全计算也成了近期的热点。蚂蚁做为一家金融科技公司，特别注重用科技的方法来保护用户隐私。这次直播会介绍蚂蚁在安全计算方面的一些方法和实践。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 相和 蚂蚁集团安全计算团队 Occlum 项目负责人 （从事 Intel SGX 相关开发工作十多年，期间设计和主持开发了 Intel SGX SDK） 议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 用安全计算保护关键业务 相和 蚂蚁集团安全计算团队 Occlum 项目负责人\n你将收获 了解Intel SGX 技术和蚂蚁开源的 Occlum 产品。 了解如何用 Occlum 来保护已有的 SOFABoot 应用。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1620370800,"description":"05 月 19 日周三晚 19 点，线上直播第 20 期。","dir":"activities/sofa-channel-20/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f41faefa3f35c17635d73634cf7a50f5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-20/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-20/","summary":"概要 活动主题：SOFAChannel#20：用安全计算保护关键业务 活动时间：05 月 19 日周三晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播间","tags":["SOFAChannel","Occlum"],"title":"SOFAChannel#20：用安全计算保护关键业务","type":"activities","url":"/sofastack.tech/activities/sofa-channel-20/","wordcount":551},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAStack Meetup#5 上海站 容器沙箱专场\n 活动时间：2021 年 05 月 22 日（周六）14:00-17:00\n 活动地点：上海市浦东新区蚂蚁 S 空间 南泉北路 447 号 201\n 活动形式：线下活动\n 资料下载： 《边缘计算中的 Kata Containers\u0026amp;gt; 《快速闪电：Nydus 镜像加速服务》 《WebAssembly Micro Runtime：云原生时代的超轻量级新型沙箱》 《WebAssembly 在 MOSN 中的探索与实践》\n 活动介绍 活动议程 本期议题以及嘉宾详解 《边缘计算中的 Kata Containers》\n嘉宾介绍\n李枫，先后就职于摩托罗拉, 三星等IT公司, 现为独立开发者。在移动平台上积累了十年以上的研发经验, 近几年主要专注于云计算/边缘计算基础设施领域。是《灰帽黑客 第4版：正义黑客的道德规范、渗透测试、攻击方法和漏洞分析技术》和《恶意网络环境下的Linux防御之道 》中文版的主要译者。对技术创新具有浓厚的兴趣和实践能力，热心参与开源社区的各种活动，多次参加各种IT会议并作技术分享。\n议题简介\n Kata Containers 具有的轻量和高安全等特性使它在资源受限和安全性需求的物联网/边缘计算领域有很好的应用前景, 并且可以与其他轻量级解决方案（如 K3S 等）进一步结合使用。本话题包含下列子话题： 1) LF Edge（由 Akraino 和 EdgeX 合并而成）中的 Kata Containers； 2) 打造轻量级 K8S 集群\u0026amp;ndash;Kata-Containers 与 K3S 的结合； 3) 在 ACRN 中运行 Kata Containers； 4) 将 Kata Containers 应用于边缘云。 听众收获\n 了解 Kata Containers 的基本情况 了解 Kata Containers 在边缘计算场景的应用前景 《快速闪电：Nydus 镜像加速服务》\n嘉宾介绍\n彭涛，蚂蚁集团可信原生技术部高级技术专家，Linux 内核和文件系统开发者，近年来主要关注容器运行时相关技术，是 Kata Containers 维护者和架构委员会成员，Dragonfly 镜像服务 nydus 的作者之一，云原生技术浪潮的坚定支持者。\n徐佶辉，蚂蚁集团可信原生技术部技术专家，Dragonfly 镜像服务 nydus 的作者之一，负责 nydus 在蚂蚁的落地。\n议题简介\n 有研究表明，容器镜像拉取占据了容器启动时间的 70%，而容器启动实际上只需要访问容器镜像不到 6% 的数据量。基于此，我们设计实现了可以按需加载容器镜像的 nydus 镜像加速服务，在内部大规模部署，并开源贡献给 Dragonfly 社区。本话题将向大家介绍 nydus 项目的背景，架构和技术细节，以及我们对容器镜像生态的展望。 听众收获\n 了解当前 OCI 容器镜像格式优缺点 了解 nydus 项目的背景，架构和技术细节 了解容器镜像生态的发展趋势 《WebAssembly Micro Runtime：云原生时代的超轻量级新型沙箱》\n嘉宾介绍\n王鑫，英特尔高级工程经理，WAMR(WebAssembly Micro Runtime)项目的创建者，主要工作集中在管理语言运行时和Web技术，2009年以来领导了Java和WebAssembly虚拟机运行时开发、V8 JavaScript引擎的性能优化等相关工作。加入英特尔之前，在摩托罗拉主要作为技术Leader，负责无线基站系统相关的工作。\n议题简介\n 近年来WebAssembly在服务器侧及云原生场景中越来越流行，WAMR(WebAssembly Micro Runtime)是字节码联盟(Bytecode Alliance)旗下的WebAssembly独立运行时开源项目，支持多种软硬件平台，支持解释器/AOT/JIT等多种执行方式，性能优异，资源占用少，对多线程和SIMD也有良好的支持。这次分享将介绍WAMR的架构、特性、社区合作及在云原生场景中的应用。 听众收获\n 了解WebAssembly这一新兴技术 了解WAMR开源项目的架构、特性及社区合作 了解WAMR在云原生场景中的应用实例 《WebAssembly 在 MOSN 中的探索与实践》\n嘉宾介绍\n叶永杰，蚂蚁集团可信原生技术部软件工程师，开源项目 MOSN 核心成员，目前关注云原生 ServiceMesh、WebAssembly 等相关领域。\n议题简介\n 随着云原生数据面 MOSN 在蚂蚁金服内部的大规模落地，安全隔离逐渐成为急需解决的问题之一。为此，我们利用 WebAssembly 基于给定资源的安全模型，依托于社区 Proxy-Wasm 开源规范，为 MOSN 中的扩展插件提供了一个独立隔离的沙箱环境。这次分享将介绍 MOSN 的背景，WebAssembly 在 MOSN 中的实践、以及我们在 Proxy-Wasm 开源规范上的贡献。 听众收获\n 了解云原生数据平面 MOSN 的基本情况 了解 Proxy-Wasm 开源规范的基本情况 了解 WebAssembly 技术在云原生数据平面的实践案例 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1620370800,"description":"SOFAStack Meetup#5 上海站 容器沙箱专场","dir":"activities/sofa-meetup-6/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"411a4b0f323c4d5ced46847b710a948d","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-6/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-6/","summary":"概要 活动主题：SOFAStack Meetup#5 上海站 容器沙箱专场 活动时间：2021 年 05 月 22 日（周六）14:00-17:00 活动地点：上海市浦东新区蚂蚁 S","tags":["SOFAMeetup"],"title":"SOFAStack Meetup#5 上海站 容器沙箱专场","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-6/","wordcount":1805},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@李明 提问：\n 请教一下： SOFATracer 用 3.1.0 版本对应 SOFABoot，应该使用 3.1. 版本吗？\n A：都可以，不依赖 SOFABoot 版本。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@黄海淇 提问：\n 有没有 SOFABoot 从零开始的文档哇？这家公司用的 SOFA 相关的组件做的银行项目。\n A：https://www.sofastack.tech/projects/sofa-boot/overview/ ，在我们社区各个项目的主页介绍里面都是有文档的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@陈承邦 提问：\n undo_log 日志当时回滚删除，还是过一段时间批量删除？ A：回滚删除，status 为 1 的 7 天删除。\nSeata：https://github.com/seata/seata\n4、@贾云森 提问：\n @GlobalTransactional 这个注解下的，不同 Service 的数据库操作，都要加本地事务吗？\n A：AT 模式下不需要。\nSeata：https://github.com/seata/seata\n5、@天成 提问：\n 问下：生产跟预发感觉也得搭建 2 个 seata-server，不能共用一个对吧？\n A：可以共用一个，因为锁需要共享才能排他；也可以分开，但是要用表共享，具体看官网事务分组。\nSeata：https://github.com/seata/seata\n本周推荐阅读 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 开发 Wasm 协议插件指南\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n ","date":1619766000,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-0430/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8225fa5618621f7b6ea3e7504b74610a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0430/","publishdate":"2021-04-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0430/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0430/","wordcount":903},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谭新宇 提问：\n 请教 SOFAJRaft 的问题：默认的 election timeout 这么小嘛？业务压力比较大的话感觉很可能发生超过 1s 的 STW GC 吧，这时会不会导致频繁换主。\n A：最好调整下默认参数，不过 1s 的 STW 实际上也不太正常，需要优化。\nSOFAJRaft：https://github.com/sofastack/sofa-jrafta\n2、@刚刚 提问：\n SOFARPC 是通过 MOSN 转发协议？SOFA RPC 对外注册的 IP 在 k8 的容器是什么策略？\n A：：MOSN 支持 SOFARPC 协议的转发。\nA：服务发布订阅没有做啥特殊的，就和原来是一样的。\nMOSN:https://github.com/mosn/mosn\n3、@王哲 提问：\n 问下 MOSN 对 Kubernetes 版本有限制么？\n A：MOSN 对 K8s 没有强制版本要求，不过 Istio 是对其有版本要求的，具体可以看文档：https://istio.io/latest/about/supported-releases/#support-status-of-istio-releases。\nMOSN:https://github.com/mosn/mosn\n4、@王哲 提问：\n 我试了下 mosn bookinfo出现了这个问题：那个 demo Istio 注入后 yaml 文件是 OK 的，但是运行时 describe pod 看 binaryPath 又变成了 envoy，下面是运行时的，不知道是不是因为这个问题？\n A：看起来是你修改的路径没有生效，可以先在 configmap 里面修改下这个 binarypath 。\nMOSN:https://github.com/mosn/mosn\n5、@朱闯 提问：\n 请教个问题：saga 模式下是无锁的，一阶段就提交了本地事务，那么也会出现脏写而导致没法正常回滚事务的情况吧。\n A：所以允许向前重试，最终一致。向前是最终一致，没有脏写。\nSeata：https://github.com/seata/seata\n6、@何凯博 提问：\n 请教下各位大佬，xa 模式下 Seata 是怎么实现事务隔离的？\n A：xa 就是本地事务隔离，把本地事务 prepare，到二阶段再提交或者回滚。\nSeata：https://github.com/seata/seata\n7、@谢太阳 提问：\n A 项目独立库，B 项目用 sharding jdbc 分库分表，A 项目发起分布式事务，出现异常，B 项目不回滚，请教这个一般是什么问题呢？上面是 A 调用 B 的日志，没有分支的回滚记录。下面 B 调用 A 是正常的。\n A：xid 传递检查一下，数据源代理没成功，或者 xid 没传递。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Rust 大展拳脚的新兴领域：机密计算\n 开发 Wasm 协议插件指南\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n 本周发布 本周发布详情如下：\n1、Occlum 发布了 0.22.0 版本，主要变更如下：\n 三个新的 demo：redis，Flink 和 Enclave RA_TLS 支持 /dev/shm 文件子系统 支持 golang1.16.3 详细参考：\nhttps://github.com/occlum/occlum/releases/tag/0.22.0\n","date":1619161200,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-20210423/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"30345ac491d8918983986d2f4cf1d058","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210423/","publishdate":"2021-04-23T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210423/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210423/","wordcount":1277},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@藜蒿 提问：\n 请问一下，SOFATracer+SpringBoot 如何在 spring-mvc-digest.log 增加 rest 请求的请求体数据在 json 日志中。需要打印 request 数据，不单单是 url 上的，可能是 post 请求放在 body 里面的。A：可以用这里的命名空间：\n A：这个暂时不行，不过你可以通过手动埋点的方式去拿这些信息，可以提个 issue ，详细描述下场景诉求。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@南桥 提问：\n 请问下 select * for update, 在 Seata 的事务中，除了会加一个全局的锁，还会加数据库锁吗？ 如果一条记录在分布式事务中，已经加了 for update 读。 那么这条记录再在数据库本地事务中，不加 @GlobalLock，加 for update 读，能读到吗？\n A：不会加全局锁，先加本地锁。\nA：如果要根据读的结果来写，为了得到分布式事务下的已提交数据，需要 for update。数据库层面可以快照读，但是无法当前读（for update 会阻塞），上了分布式事务后，结果都是二阶段后才是准确的，因为有了分布式事务的概念，在此之下的所有本地事务，也就是数据库方的数据已经不能算是准确的了，因为在 AT 模式下随时都有会回滚数据。\nSeata：https://github.com/seata/seata\n3、@姜广兴 提问：\n saga 模式 demo 中的服务都有对应的补偿服务，如果对接外部系统，没有提供相应的补偿服务，还可以使用 saga 模式吗？\n A：可以，没有补偿服务就不补偿，可以向前重试。\nSeata：https://github.com/seata/seata\n4、@彭勃 提问：\n 看到这段，我请教一下。目前，我们自己通过再加一个 mysql MGR 集群去回避这个外部持久化单点故障的问题请问有人有过相关实践吗？您觉得可行吗？\n A：可以这么做，MGR 的话性能应该就比单 DB 要下降了，但是比主备要靠谱，主备的话还是有可能丢数据，MGR 有一致性协议存在，理论上没什么大问题。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Rust 大展拳脚的新兴领域：机密计算\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n 本周发布 本周发布详情如下：\n1、SOFATracer **** 发布 v3.1.1 版本，主要变更如下：\n 添加数据脱敏扩展点，默认无对应的开源实现，用户可以自定义；商业版则提供了该实现 。\n详细参考：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.1.1 ","date":1618556400,"description":"SOFA WEEKLY |SOFATracer 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210416/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6e17e1cbdfbb154ddbe2066aa24dabfa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210416/","publishdate":"2021-04-16T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210416/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210416/","wordcount":1212},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA开源三周年，Let\u0026amp;rsquo;s have fun together\n 活动时间：2021 年 04 月 24 日（周六）14:00-17:00\n 活动地点：北京海淀中关村创业大街72号拓荒族众创空间（三层路演厅）\n 活动形式：线下活动\n 资料下载：\n 《SOFAStack 三周年分享》下载链接\n 《Enabling Financial-Grade Secure Infrastructure with Confidential Computing》下载链接\n 《云原生网络代理 MOSN 新的助推器—Envoy》下载链接\n 《注册中心 6.0 新特性》下载链接\n 《服务网格在企业落地的典型场景与实践》下载链接\n 活动介绍 SOFA 开源三周年， Let\u0026amp;rsquo;s have fun together！北京，我们来啦！\n不知不觉，我们已相识三年，\n很开心能邀请你一起来见证 SOFAStack 社区三周年，\n三年的时间，见证了 SOFAStack 在各个行业环境中的成长，是我们 SOFA 星球的骄傲。\n我们将在北京迎来 SOFA 三周岁的生日，期待与你一同分享！\n活动议程 本期议题以及嘉宾详解 《SOFA 三周年 \u0026amp;mdash;- 一起做些有趣的事儿吧！》\n嘉宾介绍\n黄挺，蚂蚁集团资深技术专家，目前主要负责蚂蚁中间件团队，推动了蚂蚁 Service Mesh，Serverless 等云原生技术在蚂蚁落地。\n议题简介\n SOFA 开源已经进行了三年的时间，在本次分享中，将会带大家了解 SOFA 开源三周年以来的一些心路历程，介绍 SOFA 开源未来的发展方向. 听众收获\n 了解 SOFA 开源的现状 了解 SOFA 开源的未来的发展方向\n 《机密计算如何为金融级基础设施保驾护航》\n嘉宾介绍\n田洪亮，蚂蚁集团高级技术专家，在机密计算、可信执行环境（TEE）和系统软件方面拥有丰富的经验，是蚂蚁自主研发的开源 TEE 操作系统 Occlum 的架构师。在加入蚂蚁之前，供职于 Intel 中国研究院。他于清华大学获得博士学位。\n议题简介\n 构建金融级基础设施的重要一环就是金融级安全性，而这正是 SOFAStack 技术栈中的 Occlum 项目所瞄准的目标。本次演讲将介绍蚂蚁集团在机密计算（Confidential Computing）和可信执行环境（TEE）方面所做的努力，尤其是如何通过蚂蚁自研的、开源TEE操作系统 Occlum 来实现零门槛、高性能的机密计算。 听众收获\n 了解机密计算这一激动人心的新兴技术方向；\n 了解机密计算领域的重要进展\n 《云原生网络代理 MOSN 新的助推器 —Envoy》\n嘉宾介绍\n王发康，蚂蚁集团技术专家，专注于高性能网络服务器研发，MOSN、Tengine 开源项目核心成员，目前关注云原生 ServiceMesh、Nginx、Envoy、Istio 等相关领域。\n议题简介\n MOSN 在 Service Mesh 领域作为东西向服务治理网络在蚂蚁集团双 11 、红包等活动及开源社区都得到了实践，为进一步节省研发及运维等相关成本，目前业界也有东西和南北向数据面进行统一的趋势。该演讲主题介绍了如何使用 Envoy 作为 MOSN 的网络层扩展，将 MOSN 和 Envoy 生态打通，同时使得 MOSN 底层网络处理能力具备 C/C++ 同等高性能、满足南北向高并发场景，又能复用 MOSN 的服务治理能力及 GoLang 的高研发效率。 听众收获\n 可快速了解如何使用 MOSN/GoLang 来扩展 Envoy 的服务治理能力\n 收获 MOSN 扩展 Envoy 时遇到的踩坑事项\n 了解 MOSN 开源社区进展\n 《新版 SOFARegistry 的多个 10X 提升》\n嘉宾介绍\n李旭东，蚂蚁集团中间件高级开发工程师，SOFARegistry Committer，专注于分布式中间件开发与优化。毕业后先后参与分布式服务发现体系构建和企业级 ServiceMesh 平台的开发。\n议题简介\n 随着集群的规模越来越大，服务注册中心的压力也越来越大。如何通过应用级服务发现改造减少服务数据一到两个数量级。现有服务如何利用 MOSN 无感知平滑迁移到应用级服务发现。分布式注册中心如何提高稳定性，如何利用混沌测试提前发现问题。SOFARegistry未来的发展方向。 听众收获\n 了解应用级服务发现如何进行实现和改造以及迁移的方案\n 分布式注册中心的质量和稳定性如何保障\n 《服务网格在企业落地的典型场景与实践》\n嘉宾介绍\n王磊，时速云CTO，负责时速云企业级容器 PaaS、中间件、DevOps、微服务治理、API 网关等多个云原生产品及相关解决方案的架构、产品和研发管理工作，对云原生相关领域有较深的理解及丰富的落地经验，致力于为企业构建新一代以应用为中心的云原生基础平台。曾在IBM中国开发实验室从事IBM中间件、Bluemix PaaS平台等产品的研发和设计工作。\n议题简介\n 当前，应用的微服务改造正在许多企业中如火如荼地进行，然而，微服务改造后的治理问题成了其进一步发展的障碍。在这一背景下，Service Mesh 应运而生，通过将治理能力下沉到基础设施层的方式来降低对业务应用的侵入。从实际需求出发，时速云基于 MOSN 等技术研发了自己的服务网格产品，克服了落地中的各种障碍，目前已在金融客户的核心生产系统中运行了1年多的时间，算是较早落地服务网格的典型案例。在这个过程中我们也感悟到，技术的先进性是持续追求的方向，而如何更好的结合实际场景才是推进服务网格落地的关键。本次分享主要介绍一下我们在落地服务网格时碰到的一些典型需求场景及实践经验。 听众收获\n 了解企业对于服务网格的典型诉求\n 了解服务网格落地时面临的主要问题与相关解决方案\n 服务网格的典型使用场景及未来展望\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1618210800,"description":"SSOFA 开源三周年，Let's have fun together！","dir":"activities/sofa-meetup-5/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"aee1e29a3825c8fdcafee69bc8a1613e","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-5/","publishdate":"2021-04-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-5/","summary":"概要 活动主题：SOFA开源三周年，Let\u0026rsquo;s have fun together 活动时间：2021 年 04 月 24 日（周六）14:00-17:00 活动地点：北京海淀中","tags":["SOFAMeetup"],"title":"SOFA 开源三周年，Let's have fun together！","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-5/","wordcount":2041},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@闫文超 提问：\n 问下 SOFARPC 注册到 nacos 上，可以指定 group 的名字吗？想用于不同租户的隔离的功能。\n A：可以用这里的命名空间：\nnamespace :com.alipay.sofa.rpc.registry.nacos.NacosRegistry。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@霂白 提问：\n 注解方式发布的服务，有插件能自动生成给其他语言使用的 protobuf 的文件吗？Java 已经写了接口和 bean 的结构，直接转换为对应 pb 的文件。现在有 pb的定义文件转换注解方式的，Java 的代码的 maven 插件吗？写 pb 转 Java 或者写 Java 转 pb 两个方向总有一个通的吧，不然又写 Java，又写pb？\n A：这个我理解目前应该是没有的，不过确实是一个比较有意思的方向。\nA：pb 转 Java 问题不大，有现成的工具， 自己写一个也不是很复杂，Java 转 pb 不太兼容；pb 不支持两个参数，这里的问题在于传输协议，不在于代码格式，有需要我们开个 issue 详细聊下 ，鉴权这块后续应该会交给 MOSN 来做。 SOFAStack：https://github.com/sofastack/sofastack.tech\n3、@阿怪 提问：\n 请教大佬一个问题：TCC 模式，事务异常，回滚走自定义实现的 cancel 方法，这个方法里面操作了数据库回滚并且报错，有两个问题： 1.重试次数如何配置？ 2.线程的 ThreadLocal 的数据无法获取，BusinessActionContext 这个类获取不到，可不可以配置？\n A：那就用 localtcc，一开始的 TCC 不支持 spring cloud，后续开发了个 localtcc 的注解和功能来满足。 Seata：https://github.com/seata/seata\n4、@冯明明 提问：\n 我用的是最新版的 spring-cloud-ablibaba rpc 使用的 Dubbo 。截图中这种依赖方式，必须在接口上增加@LocalTcc 才能应用 TCC 模式。我看源码 这种依赖生成的是 xxx.proxy0 这种实现类不能被 RemotingParser解析，接口提供者倒是能被解析，但 DubboRemotingParser 生成的 RemoteSpec 的 protocol 属性是 Dubbo，源码中只有 injvm 能走 TCC 的相关逻辑，请问我是哪里没有配置正确吗 ?\n A：1.方便以后出控制台可以实时查看分支事务状态； 2.比如某些分支吞了异常后，有 report 的情况下方便判断。比如：a 调 b 再调 c，b 其实已经出现异常并且本地事务下已经回滚了，此时 c 响应给 a，a 做后续处理的时候异常，此时 TC 发现 b 已经由本地事务回滚了，就无需驱动了，这样就减少了下发的数量。 Seata：https://github.com/seata/seata\n5、@张红亮 提问：\n 能在 service 实现里再次调用的方法上加 @GlobalTransactional 吗？\n A：可以的，跟本地事务注解一样，支持事务传播。 Seata：https://github.com/seata/seata\n本周推荐阅读 Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n 本周发布 本周发布详情如下：\n1、SOFAJRaft 发布 v1.3.6 版本，主要变更如下：\n 增加 Replicator 的状态变化监听器  RheaKV 增加批量原子更新 API  Grpc 模块支持 max_inbound_message_size 配置  优化 RheaKV 内存占用  详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.6\n","date":1617951600,"description":"SOFA WEEKLY | SOFAJRaft 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210409/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"403b28d70a485885d5c8b391175a5f81","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210409/","publishdate":"2021-04-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210409/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210409/","wordcount":1512},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 请教一下：为什么 KVStoreStateMachine#onSnapshotLoad 是 leader 的时候，不去做；leader 节点如果之前进行过 snapshot 之后，raft log 应该会被删除吧；后续集群重启的时候，leader 不用 snapshot 怎么保证数据还原呢？\n A：想一下，如果它还需要 load snapshot 的话，它是怎么变成 leader 的，如果已经是 leader 了，肯定不需要 load snapshot；理论上不会走到这个分支，只是防御性的代码，如果走到这个分支，就直接报错停止状态机了。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@明惑 提问：\n 现在创建 Grpc Server 的时候，只提供了 port 配置，考虑放开一些参数可以用户配置吗？比如 grpc 的 messageSize。\n A：helper.config看一下。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@刘明明 提问：\n 请教一下：我现在想用 Go 去写一个组件当一个简易的 Sidecar 去对其他服务做健康检查。这个 Go 组件要整合 nacos 注册发现和元数据管理，后期也会整合 Istio，这个组件干的事情应该和 MOSN 类似，Go 这边 0 基础，我是写 JAVA 的，就比如这个用 JAVA 实现只需要 springboot 就好了，Go 这边我调研了下准备用 go-Micro，请问各位这个方向是否正确？\n A：可以参考这个实现： https://github.com/mosn/mosn/issues/1087 这个是直接对接 zk 做的。\nMOSN：https://github.com/mosn/mosn\n4、@彭勃 提问：\n 请教一下，关于 TCC 模式下，会有发生空回滚，资源悬挂，幂等性等问题，需要通过事务控制表去管理。我此前看到同学介绍它们会将事务控制表变成 TCC 模式的一部分（2020 年初），让业务开发者不用自己关注这些问题，请问现在 TCC 模式已经做了吗？\n A：目前只能支持单数据源下的防悬挂，直接利用开启 spring 本地事务，然后做一些前置操作来预防。\nSeata：https://github.com/seata/seata\n5、@王译锌 提问：\n 请教一下：既然回滚依赖于异常上报给 TM，那为什么分支事务的状态还要上报给 TC 呢？一直没想通这个问题。\n A：1.方便以后出控制台可以实时查看分支事务状态； 2.比如某些分支吞了异常后，有 report 的情况下方便判断。比如：a 调 b 再调 c，b 其实已经出现异常并且本地事务下已经回滚了，此时 c 响应给 a，a 做后续处理的时候异常，此时 TC 发现 b 已经由本地事务回滚了，就无需驱动了，这样就减少了下发的数量。\nSeata：https://github.com/seata/seata\n本周推荐阅读 WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n ","date":1617346800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210402/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"99c3b3c82b2f3fb86b66e6632aef8a20","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210402/","publishdate":"2021-04-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210402/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210402/","wordcount":1337},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 使用 jraft 跨 IDC 搭建了集群，一旦读 follower 节点，有 13ms 的网络延迟，用了lease read，读 leader 还好，直接返回。读 follower，要和 leader 通信，hreadb 有跨机房部署的场景吗？\n A：ollower 节点提供读能力，属于额外赠送的能力，其实 readIndex 的实现必须要和 leader 现有一个通信，这个没办法；我们不开 follower 读，从 leader 读；etcd 的 read-index 也是一样的原理，都需要请求一次 leader， zk 我了解貌似还不支持 follower 读；当然如果你不要求线性一致读，那么你绕开 raft 状态机，直接从你的存储里面读就好，如果你要的是最终一致性，那么你直接从 follower 节点上绕过 raft 直接读。 A：核心就是：follower 节点必须知道 leader 此时的 applyIndex 到哪里，然后需要再等待自己状态机的 applyIndex 也到达这个位置了才能提供读，否则就有可能一个数据 leader 上有，follower 上没有，这就很明显违背了线性一致读，所以和 leader 的这一次通信必须有，不过数据包很小，通常应该很快。 SOFAJRaft：https://github.com/sofastack/sofa-jraft 2、@吴岳奇 提问：\n 需求场景：AbstractRoutingDataSource 动态切换数据源，同一方法下，对两个不同服务器上数据表新增，涉及分布式事务。 问题: springboot 整合 Seata AT 模式 ，但无法动态代理数据源，一直代理的 yml 配置的默认的数据源。\n A：多数据源关闭自动代理；bstractRoutingDataSource 内部的多个数据源手动代理后放进去。 Seata：https://github.com/seata/seata 3、@彭勃 提问：\n 我在启动 Seata server 的时候，日志里报告了这种找不到 zookeeper 相关节点的异常；KeeperErrorCode = NoNode for /seata/store.mode。\n A：应该是用了zk 当配置中心，但是又没有写配置进去。 Seata：https://github.com/seata/seata \n本周推荐阅读 MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n ","date":1616742000,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210326/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"617144edd18f95b94e5860ed416ed165","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210326/","publishdate":"2021-03-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210326/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210326/","wordcount":1116},{"author":"嘉祁","categories":"Service mesh","content":" 本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。主要分为 3 个部分： -介绍 MOSN 在规模化运维中遇到的挑战 -无人值守上的实践 -MOSN 与技术风险方面的思考\n MOSN 规模化后的运维挑战 MOSN 早期在内部推进的时候，变更方面的支持是比较传统的。早期的变更工具只有基础的 pod 粒度的 MOSN 升级的能力。变更过程中的问题，最初依赖于上层业务系统的监控和反馈，稍后我们又在 MOSN 内建设了错误码。发布控制上，将版本区分为稳定版和灰度版本，升级的灰度过程和大范围的覆盖过程都由人工控制。这些方式在小范围、大量人力投入的情况下，保证了 MOSN 早期的快速演进和范围覆盖，也兼顾了基本的稳定性需求。\n随着 MOSN 的成熟，MOSN 的接入规模快速增长到了覆盖多个技术栈，数千应用的数十万 pod，涉及蚂蚁内部几乎所有的业务，早期的这些做法也遇到了很多问题。我们接入的应用不再只是 SOFA 技术栈的某些版本，业务也不再局限在某几条链路，大范围变更影响范围数倍甚至数十倍增长，风险变得极高，需要投入大量的人力评估每一个版本变更的影响。 举个例子，早期的 MOSN 几乎只需要考虑与较新版本的 SOFA 的对接。而当 node.js 应用开始接入时，MOSN 的变更也需要相应的考虑对 node.js 应用的影响。\n同样是为了减小风险，变更过程中尽可能减少单位时间的可能的影响范围，变更时长不可避免被拉长。\n早期的 MOSN 可能只需发布数十个应用，当范围扩大到过千时，如果单位时间发布的 pod 数据不变，那么变更时长即增加数十倍，变更的总时长变得荒谬。而如果总时长不变，则影响面和风险增加数十倍，风险不可控，业务也无法接受。\n最终结果是平衡单位时间的影响面和变更时长，风险放大无法避免，整体的迭代周期同样变长。更糟糕的是，新的特性不断堆积在下一个大版本，bugfix 也难以及时上线。这些问题最终不仅推高了下一次变更的风险，甚至直接影响当前生产的稳定。\n这么一个负向的循环需要如何打破呢。我们希望跳出传统的运维模式，既要变更的高效率，又要整体的稳定性。我们希望用技术来解决问题。\nMOSN 的无人值守变更 关于无人值守，一个可以借鉴的定义来源于近年火热的自动驾驶领域。同样都是希望把人从乏味的工作中解放出来，同样都需要面临复杂的环境问题。\n自动驾驶领域的等级定义方式也给了无人值守变更一个很好的参考点。最低级别的是 L0，一切都是人工操作，像云时代之前的时代，从装系统到应用部署，都依赖于人工命令行处理。 然后是 L1，平台提供了原子粒度的变更工具支持和基础的观察工具支持，如同早期的 MOSN。\n当这些工具更完善，提供一些基本的流程编排能力之后，开始进入自动化的时代，但可能随时需要人工介入处理。在此基础上，加上自动化的观测规则，把人工观察介入变成系统自动阻断，变更开始具备了无人值守的基本能力。 历经一年多的演进，MOSN 当前就处于这个阶段。我们也还在持续的完善和打磨，向着完全无人干预的方向演进。\n接下来我们来看 MOSN 是如何逐步达到无人值守的。 首先来看下风险的防控。前面我们提到，在传统的变更流程里面，需要人工介入的有变更范围控制；还有变更准入的检查，变更批次完成后，还要抽查确认变更结果以及业务异常情况。 也就是图上标红的这些内容。\n但是人本身是不可靠的。人为控制变更范围意味着灰度过程无法保证，准入的检查会存在比如信息不同步，规则遗漏的情况，完成情况的检查在大量应用或 pod 同步变更时，也只能做到少量抽检，无法避免问题被漏过。 把人工介入的部分交给系统，我们就有了一个初步可以脱离手动操作和人工观察的流程。\n上图展示了变更防御的介入流程。 变更范围改为由算法来自动产生的带有强度灰度的批次范围。前置准入与后置检查通过将变更类型与变更范围传递给变更防御的检查，通过检查才能继续执行。\n举一个简单的场景。MOSN 覆盖很多不同业务的链路，各业务有不同的变更保护时段，怎么来解决呢？\n首先在已经业务有保护时段的情况下，我们当然不能不管业务的风险强行变更。在有变更自动防控之前，我们只能找个共同的可变更时段，很多时候这就是半夜，但对于 MOSN 这么大规模的变更，半夜变更不仅仅是影响研发和运维幸福感的问题，只有半夜能变更的话，效率也无法接受。而有了变更的自动准入阻断规则，这个时间选择的问题立即就不存在了，我们只需要把所有应用的变更都跑起来，系统自动判断各自的可执行时段，甚至不需要参与变更的各方都知道所有业务的可变更时段。\n变更防控上线以后，极大的解决了我们的变更风险问题。但它并没有解决效率问题，一段时间来看，我们的效率甚至下降了。为什么? 我们分析了自身的变更过程，注意到两点：一是我们引用的业务错误的检查标准不一，部分业务的敏感度偏高或是阈值不合理，导致变更被持续阻断，无法继续；二则我们的全面检查放大了上面的问题，多个批次下来被中断的的概率也极大的提高了\n仔细来看业务的错误检查。这些检查不仅说明了 MOSN 自身的检查，还包括了业务的自身的错误和其它中间件、基础设施的问题。这些检查无法直接说明 MOSN 自身的健康情况。怎么解决呢？我们决定不再依赖这个不靠谱的检查，由 MOSN 自己来说明自己的健康情况。\n我们在 MOSN 中建设了两个层面的健康度观测能力。第一层是静态健康度，主要是 MOSN 的启动自检，在流量进入前完成，体现 MOSN 运行环境和基本启动依赖的健康情况；第二层是动态健康度，主要是 error metrics 日志，体现核心功能运行状态。结合这两层健康层，MOSN 就具备了完整了自身状态的观察能力，可以把业务的错误检查从变更检查中移除。\n我们还做了一个进一步提升变更效率的事情，彻底解决业务冷启动消耗的时间。\n无论是传统的原地升级或者是滚动升级的模式，过程都无法避免业务需要冷启动。由于业务依赖比较多，大部分业务的启动速度和成功率是大幅低于 MOSN 的，因此业务的冷启动时间一直是 MOSN 变更时间的大头。\n一个很好的解决方案是热升级。MOSN 自身是具备热升级能力的，下图展示了热升级的过程。 稍微解释一下的 MOSN 热升级过程。sidecar operator 会给待升级的 pod 注入一个新版本的 MOSN sidecar，旧版本的 MOSN 会收到连接迁移的请求，所有的长连接会被新版本的 MOSN 接管，完成之后旧版本 MOSN 会停止，sidecar container 被删除。\n热升级是一个很理想的升级方式，但是完善的热升级需要的条件和环境都比较复杂，需要 k8s 和 operator 的相应支持，而且被迁移的长连接需要同步的迁移状态，对于 MOSN 内的有状态协议也带来比较大的研发压力。\n我们的选择是把复杂做到了运维侧，做一个相对折中的方式。相对于热升级，这个方案没有那么热，我们称为温升级。 上图展示了温升级的过程。概括起来是三步：关闭待运维 pod 的所有入流量，升级 MOSN 的容器，打开流量。\n温升级去掉了业务的冷启动时间，避免了业务重启失败。MOSN 只需要做好配置的向下兼容，升级过程和传统升级过程几乎完全一样，但成倍的提升了升级效率。\n最后，我们说 …","date":1616677200,"description":" 本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。","dir":"blog/mosn-meetup-4-deploy-automation-at-large-scale/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"aec6af134a0e93f3576b7d5f3fd9101d","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","publishdate":"2021-03-25T21:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","summary":"本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。主要分为 3 个部分： -介绍 MOSN 在规模化运维中遇到的挑战 -无人值守上的实践 -MOSN 与技术风险","tags":["Service mesh","Service Mesh 落地实践"],"title":"mosn的无人值守变更实践","type":"blog","url":"/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","wordcount":3465},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 请教一下：JRaft 的 StateMachine 的 onApply 方法是线程安全的吗？如果在 onApply 里面有一些耗时操作的话，整个应用吞吐会下降很明显吧。\n A：是，对于同一个 st，onApply 必须由 JRaft 的单线程去执行，因为 raft 算法本身需要保证 raft log 被顺序 apply，所以这里没有线程安全问题；把结果同步了就好了，计算别放里头。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@孙军超 提问：\n 请教个问题：我现在直接跑 jraft-example 的 rheakv 的测试代码 PutExample，第一次调用 Rocksdb put 函数总会先阻塞整整 5 秒钟，server 端也没有任何报错。 A：猜测是 DefaultChannelId 里的 getProcessId() 太慢了，或者是 NetUtil 里获取 loopback 地址太慢，有一个办法可以证实：在 main 方法最开始提前 Class.forName 去加载这俩个类，应该会先卡住 5 秒，等到 rheakv 的逻辑执行时就不会卡住了；试一下我上面说的方法，猜测就是这两个类其中之一导致的：https://stackoverflow.com/questions/33289695/inetaddress-getlocalhost-slow-to-run-30-seconds； 配 etc/hosts 生效后可以解决。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@明惑 提问：\n 请教一下：状态机中 onApply 和 onSnapshot 的方式是线程安全的吗，我在这两个方法中操作同一个数据，会不会出现并发问题呢？\n A：onSnapshot 会暂停其他线程；不会有影响，onApply 又是单线程执行的。\nSOFAStack：https://github.com/sofastack/sofastack.tech\n4、@胡志奇 提问：\n Snapshot 的 save/load 方法都将阻塞状态机，应该尽力优化，避免阻塞。Snapshot 的保存如果可以做到增强备份更好。 onSnapshotSave 需要在保存后调用传入的参数 closure.run(status) 告知保存成功或者失败，推荐的实现类似：\n @Override public void onSnapshotSave(SnapshotWriter writer, Closure done) { // 同步获取状态机的当前镜像状态 state // 异步保存 state // 保存成功或者失败都通过 done.run(status) 通知到 jraft } 官网上说的，异步保存也会阻塞？\n A：没有问题，安全的；你截取的内容其实已经说得很清楚了，异步是指存储操作，同步是指获取当前状态机的镜像必须是同步操作；就是说：你必须在状态机被后续的 raft log 更改之前，拿到镜像，也就是拿镜像和 apply 是串行操作，一旦拿到镜像，你可以用异步的方式把镜像保存的磁盘上，甚至再压缩一下。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n5、@闫文超 提问：\n 问下大佬，SOFABoot 启动服务端暴露两个接口，但是 nacos 注册中心只注册了一个 RPC 端口，客户端调用接口报错\n A：SOFARPC + NACOS 有实践案例：https://www.sofastack.tech/projects/sofa-rpc/registry-nacos/ 如果还是解决不了可以上传一个可以复现问题的 demo 工程到 GitHub。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n6、@游侠 提问：\n 请教一下：在 SOFAJRaft，Learner 这种复制器，怎么理解？表示这个节点，只读？\n A：learner 不参与选举，可理解为冷备。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n 可信原生负责人入选“2021年度全球青年领袖”名单\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n ","date":1616137200,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210319/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"196034de19b2d4c77fbe5c88e6721a8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210319/","publishdate":"2021-03-19T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210319/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210319/","wordcount":1712},{"author":"SOFA 团队","categories":"sofagw","content":" 简介：本周将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会重点说明如何解决在安全、互通、接入成本、高效等几方面问题，接着介绍了SOFAGW网关的内部实现架构，最后是SOFAGW网关达成的业务成果。\n 1. 业务痛点 随着业务发展越来越多元化，部分业务域相对比较独立，或因其业务属性，会建立成独立的站点（租户），比如：国际业务和蚂蚁保等。这些站点之间网络是隔离的，但实际业务上会存在一些通信的需求，所以我们碰到的核心问题是：网络互相隔离的多个站点之间怎么做高效可信的通信？对此我们有两种针对站点间互通的解决思路：\n思路1：为每个业务创建跨域 VIP 为每个业务创建跨域 VIP，站点的业务通过 VIP 来做通信。这种方式，运维管理员要在两个网络间开很多 VIP，加访问白名单，最终网络拓扑会变成如下；将面临网络口子多、运维成本高、业务接入成本高、安全阈值低等问题。\n这个方案有以下几个问题：\n 很多服务需要开 VIP 口子，服务多了之后，VIP 难以维护； VIP 的 ACL 控制很弱，只能基于 IP 端口或 IP 段控制，不能按业务应用或服务来做控制； 安全管控能力很弱，对请求不可审计； 业务适配改造工作量大，技术栈不统一，存在多种 RPC 框架。 思路2：实现一个高效可信的互通网关，来承接站点之间的通信代理 这就是我们采用的多站点互相通信的解决方案，下面详细介绍我们的互通方案和重点解决的问题。\n2. 解决方案：SOFAGW 互通网关 鉴于上面提到的问题，我们研发了 SOFAGW 互通网关，致力于实现一个简单高效、安全可信的跨域 RPC/消息 互通网关。\n如上面的整体架构图所示，我们的解决方案是各站点部署一套 SOFAGW 网关，把站点间的通信都收敛到 SOFAGW 上，由 SOFAGW 来保证安全通信，而在研发体验上，业务方同学按照本地服务做开发，不用为跨域通信做特殊处理，做到无缝接入。\nRPC互通过程： 在 SOFAGW 网关上，申请接入需要互通的 RPC 服务。接入后，消费方 SOFAGW 网关会把这个 RPC 服务发布到本站点注册中心上，服务方 SOFAGW 网关会从注册中心订阅这个 RPC 服务提供方地址。 消费方应用通过注册中心订阅到目标服务是本站点的 SOFAGW，把请求发送到本站点的 SOFAGW。 本站点的 SOFAGW 根据 API 配置信息，把请求转发到对端站点的 SOFAGW。 对端站点的 SOFAGW 根据注册中心订阅到的地址，把请求发送给真实的服务提供方。 完成跨展达 RPC 通信。 消息互通过程： 消息的互通和 RPC 互通非常类似，差别主要在于需要通过消息中心来收发消息。\n 在 SOFAGW 网关上，申请需要接入互通的消息服务。 客户端把消息投递到本站点的消息中心，消息中心把消息封装成 RPC 请求发送到本站点 SOFAGW。 本站点的 SOFAGW 根据API配置信息，把请求转发到对端站点的 SOFAGW。 对端站点的 SOFAGW 把请求发送到消息中心，消息中心再把消息投递到真实的消费方。 完成跨站点消息投递。 SOFAGW 互通网关重点解决以下几个痛点：\n2.1 安全通信 首先我们要解决网络不可达问题。从图里可以看到：每个站点都部署了 SOFAGW 网关，网关之间可以用专线或 VIP 之类的产品打通，这样站点间把流量就收敛到了 SOFAGW 网关，避免到处开网络通道口子，便于安全管理。\n网络安全 为了保证 SOFAGW 网关之间的通信安全可信，我们开启了 mTLS 双向认证，既能对数据做加密，也能确认对方的身份可信，从而确保通信安全。\n数据安全 一个站点（租户）会给其他多个站点提供服务，这些暴露的服务首先要确保租户级别的水平权限隔离，也就是说，A 站点暴露给 B 站点的服务，不能被 C 站点的应用调用到。如何做到这点？\n SOFAGW 网关会给不同站点提供不同的访问域名（这些域名都会解析到 SOFAGW 的 VIP 上）。 SOFAGW 之间通过 mTLS 双向认证通过后，可以确认请求的域名（ host ）可信，也就是 C 站点的应用无法用 B 站点的域名与 A 站点的 SOFAGW 网关建立 TLS 连接。 SOFAGW 会通过请求头里的 host + path 路由做路由转发，C 站点的请求无法匹配上提供给 B 站点的域名，也就无法访问到提供给 B 站点的服务。 除了要确保租户级别的水平权限控制，SOFAGW 还具备应用级别的 ACL 权限控制，如果一个 API 服务只暴露给某特定应用，那其他的应用是无法访问这个 API 服务的。\n另外，站点间的通信数据不是任意的，目前在业务 API 接入过程中，我们会有严格的数据安全审计流程。\n2.2 统一技术栈，跨域 RPC/消息 互通 不同的业务方会使用不同 RPC 框架，如 SOFARPC、HSF、Dubbo，底层用的通信协议和序列化协议也不一样，很难直接通信，如果做协议转化适配又会有很大的成本。在性能、扩展性和新特性支持等方面，老的各种协议难以满足发展需求，也很难在原有协议的基础上扩展以支持新的功能。为了更好的支持业务发展，对齐各 RPC 框架通用能力，需要设计一种新的通用的协议，从协议层解决以上问题。\n所以，阿里巴巴及蚂蚁集团共同制定了 Triple 协议，让内部使用的编程框架都支持 Triple 协议，这样大家互通时就会很顺畅。\nTriple 协议是什么？\nTriple 协议本身，是基于 gRPC-over-HTTP2 扩展的 RPC 协议，与现有的其他 RPC 协议比较， 有以下优势：\n 多种 RPC 模式 ( P2P/ Reactive Streams/ Bidirectional / Pub-Sub ) 基于 protobuf 提供统一的服务定义以及 API 治理 更好的性能 ( Protobuf / Protostuff / Back Pressure ) 原生跨语言支持 ( C++/ Dart/ Go/ Java/ Python/ Ruby/ C# / OC / JS / PHP )，原生兼容 gRPC 客户端 易于升级和修改协议 兼容现有的 RPC 框架，易于协议升级和互通 ( gRPC / SOFA-RPC / HSF / Dubbo \u0026amp;hellip;) 对网关型应用友好，原生支持 gRPC-over-HTTP2 支持移动设备原生调用 Triple 遵循 gRPC-over-HTTP2 协议规范，使用 CUSTOM-METADATA 扩展元数据。对于已经存在的 grpc- 开头的 Header 保持不变，保证与原生 gRPC 客户端/服务端互通，对于协议中不存在需要新扩展的 Header，将以tri- 开头。另外，去年发布的 Dubbo 3.0 也是以gRPC为基础，Triple 能和 Dubbo 3.0 保持良好兼容。\n举例，当前我们约定的 Triple 协议头：\n2.3 无缝接入 为了让业务方无缝接入，SOFAGW 网关和注册中心专门做了联动，具体原理从上面的整体架构图可以看到：\n 在调用 …","date":1615878000,"description":"将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会重点说明如何解决在安全、互通、接入成本、高效等几方面问题，接着介绍了SOFAGW网关的内部实现架构，最后是SOFAGW网关达成的业务成果。","dir":"blog/sofagw-cross-domain-communication-solution/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"158827766506b1c5f49729b31a6f66e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","publishdate":"2021-03-16T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","summary":"简介：本周将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会","tags":["Service mesh","Service Mesh 落地实践"],"title":"SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案","type":"blog","url":"/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","wordcount":4308},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@孙军超 提问：\n 请教一下 jraft-rheakv rocksdb 的 get put 操作，耗时要 5 秒钟，是服务端配置需要优化吗？ 以下是我的服务端配置截图。 A：kill -s sigusr2 可以看到性能指标度量，官方文档请看一下有相关说明。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@戚金奎 提问：\n 请教一个问题：如图，目前服务都是通过 openfeign 远程调用，如果 setScore 所在的服务抛出了异常，是能直接出发事务回滚吗（我本地的无法出发回滚），还是需要在这个 seata1 里面接受一下返回值然后抛出异常才可以回滚吗（目前我这边是这种可以回滚）？\n A：决议全局提交/回滚的只能是\n@GlobalTransactional 注解的发起者，它 catch 到异常才会触发回滚；远端的异常应该是没抛给调用者，或者被框架拦截了异常。\nSeata：https://github.com/seata/seata\n@谭玖朋 提问：\n 这两个地方调用 rollback 有特殊意义吗？我发现在此之前没有更新操作啊。 A：这个地方应该是一个编码的习惯，在 autocommit=false 的时候，返回前都做一次 commit 或者 rollback 操作，确保当前的事务能够提交或者回滚，同时释放数据库的锁（哪怕前面并没有事务和锁）。\nSeata：https://github.com/seata/seata\n@戚金奎 提问：\n 请教一个问题：如果出现如图的这种情况， 执行的这个全局事务在获取全局锁之后，会获取 m 字段最新的值，再和自己的 before_image 里面记录的值去比较，发现不一致，全局事务失败并回滚。 A：所有写场景要被 globaltransational 覆盖，不允许直接去数据库改数据。否则就会出现在全局事务被决议回滚的时候，别的地方把这个数据改了。\nSeata：https://github.com/seata/seata\n@姜世存 提问：\n 请教一个问题，这个 LoadLevel 注解有什么作用\n A：所以别的业务要继承 Seata，写入口加入 globaltransational 注解，只读无需加注解。\nSeata：https://github.com/seata/seata\n@winyQ 提问：\n 项目里 Seata 用 AT 模式，可以在项目里再集成 JTA 吗，两个并存有没有什么问题？\n A：JTA 是 XA ，无法跟 AT 兼容。\nSeata：https://github.com/seata/seata\n本周推荐阅读 可信原生负责人入选“2021年度全球青年领袖”名单\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 本周发布 本周发布详情如下：\n1、sofa-common-tools 发布 v1.3.3 版本，主要变更如下：\n 修复 log space factory 的懒初始化模型问题  详细参考：\nhttps://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.3\n","date":1615532400,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210312/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f2a08527a8868ee63936378b903d5b07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210312/","publishdate":"2021-03-12T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210312/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | sofa-common-tools 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210312/","wordcount":1269},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望\n 活动时间：2021 年 03 月 21 日（周日）14:00-17:00\n 活动地点：浙江杭州西湖区学院路77号黄龙万科中心-I座\n 活动形式：线下活动\n 资料地址：点击链接\n 活动介绍 SOFAMeetup 牛年首站：3月21日 杭州见！\n久别重逢，朋友们，SOFAMeetup 回来了。 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁集团超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n本期 SOFA Meetup 将带来 Service Mesh专题： Service Mesh 在蚂蚁、美团的落地后，如何开展能力及基础设施的建设？如何更好的支撑业务发展？在Service Mesh 大规模落地后，MOSN 如何解决变更风险和效率问题？ 如何支撑 Service Mesh 的演进与优化？本次分享将会提供我们一些思考和实践！\n活动议程 本期议题以及嘉宾详解 《Service Mesh 在蚂蚁落地后的探索与实践》\n嘉宾介绍\n李唯，蚂蚁集团技术专家，2017 年加入蚂蚁集团中间件团队。参与了 Service Mesh 在蚂蚁的落地建设，目前主要负责 MOSN 在蚂蚁内部的设计开发。\n议题简介\n Service Mesh 在蚂蚁落地之后的能力建设，结合 MOSN 在蚂蚁的实践和探索，分析 Service Mesh 在大规模场景下持续向前演进的挑战及其背后的思考。 听众收获\n 了解 Service Mesh 在蚂蚁实践过程中遇到的困难和思考 收获 Service Mesh 在赋能业务方面的案例经验与启发\n 收获 Service Mesh 在研发效能方面的最佳实践\n 《MOSN 的无人值守变更实践》\n嘉宾介绍\n黄家琦，蚂蚁金服技术专家，SRE，专注于基础设施与中间件稳定性建设。深度参与了 Service Mesh 在蚂蚁内部大规模生产落地过程中的技术风险能力建设。SOFABolt-Python 组件维护者。\n议题简介\n 自 Service Mesh 在蚂蚁大规模落地之后，MOSN 的变更风险和效率问题愈发突出，本次将介绍从 SRE 视角下对于 MOSN 变更问题的思考，以及对于无人值守变更的实践。 听众收获\n 了解大规模 Service Mesh 下的变更问题与思考\n 收获 Service Mesh 在无人值守变更方面的经验与启发\n 《Service Mesh 在美团的落地挑战与实践》\n嘉宾介绍\n薛晨，美团基础架构团队技术专家，一直专注于分布式系统架构、服务治理领域和基础软件产品化。毕业以来先后深度参与了分布式调度系统、分布式配置服务、PaaS 平台构建和 Service Mesh 方向的探索和实践，在相关领域有较多的思考和沉淀。\n议题简介\n 云原生时代的到来，美团的服务治理系统 OCTO 也向 Service Mesh 的方向演进。作为集团的标准化基础设施，覆盖所有业务线和日均万亿调用，在演进的过程中我们面临着诸多挑战。 如何支撑和更好的支撑业务的发展？如何尽可能的保证演进过程的可靠和丝滑？如何更好的兼顾效率与稳定性？ 听众收获\n 了解超大规模服务治理系统 Mesh 化的最新进展\n 了解 Service Mesh 规模化落地的挑战和应对方案\n 对服务治理和 Service Mesh 未来的一些思考\n 《过往可鉴，未来可期 — MOSN 社区周年回顾与展望》\n嘉宾介绍\n田阳，蚂蚁金服高级技术专家，专注于高性能网络服务器研发，MOSN 开源项目维护者，Tengine 项目成员。\n议题简介\n MOSN 开启开源社区，独立运营已一年有余。在这期间，社区持续投入开源生态建设和云原生演进，并成为了 Istio 官方推荐的数据平面。本次我们将对过去一年的成绩进行回顾与总结，对未来社区的发展进行探讨与展望。 听众收获\n 了解 MOSN 的核心能力和支撑的业务场景\n 了解 MOSN 怎样支撑蚂蚁 Mesh 的演进和大规模落地所做的优化\n 了解 MOSN 后续规划，与 Envoy 社区的合作进展等\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1615273200,"description":"SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望","dir":"activities/sofa-meetup-4/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2619f4f8ba15ac0f4fe43a82ef297db1","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-4/","publishdate":"2021-03-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-4/","summary":"概要 活动主题：SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望 活动时间：2021 年 03 月 21 日（周日）14:00-17:00 活动地","tags":["SOFAMeetup"],"title":"SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-4/","wordcount":1552},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@刘嘉伟 提问：\n 请教一下：我在纯 TCC 事务 a、b、c个服务调用中 c 服务异常了，b 服务回滚日志是 rm handle undo log process: UndoLogDeleteRequest{resourceId=\u0026amp;lsquo;insert\u0026amp;rsquo;, saveDays=7, branchType=AT} 明明是纯 TCC 事务，怎么 AT 都出来了，导致了一个问题：TCC 数据源也没有代理的，也没有相应的 undo log表，然后 AT 事务回滚肯定无效的，TCC 的 cancel 也没有执行。\n A：这个理论上来说是没影响的，定时触发的，跟你本身的回滚逻辑应该没关系；这个 pr 会优化这个点：https://github.com/seata/seata/pull/3501。\nSeata：https://github.com/seata/seata\n@刘嘉伟 提问：\n 请问 AT 模式中如何防止事务回滚时，系统中一闪而过的脏数据，有时页面刚好打开，被用户感知到这些脏数据了；人工处理很麻烦，触发异常因为回滚操作有耗时，脏数据通常怎么处理；TCC 就没有这个问题，隔离的资源用户感知不到。\n A：数据在数据库，在数据库写被隔离的；前端本身就会有脏读出现，要靠后端保证。\nSeata：https://github.com/seata/seata\n@赵勇 提问：\n 比如这个图：A、B、C 各自都有自己的代码、自己的数据库，分开部署的；A 调用 B、C 提供的服务，那 undo_log 要在 db-a、db-b、db-c 里都建一份，然后 A、B、C 的代码里都要引入全局事务相关的类、包， 再加上把 GlobalTransaction 标到 A 的代码上，是这样实现吗；我看 GTS 的文档，感觉 undo_log 是 A 的代码引入的类包去写的，不是 B、C 自己写的，B、C 的代码还是该怎么写怎么写，不需要接全局事务相关的东西。 A：Undo_log 是每一个微服务的业务数据库都要建立，各自维护自己的 Undo_log；如果刚入门了解的话，先看看官网和跑一跑 demo。\nSeata：https://github.com/seata/seata\n@吴宗杰 提问：\n 2020 年 4 月份 Seata 从 1.2.0 支持 XA 协议，Mycat 支持 XA 分布式事务，是不是说明 Seata 和 Mycat 可以一起用？不过看到 19 年 slievrly 有和 Mycat 方沟通，后面应该也会支持的吧。\n A：可以试试，因为 Seata 所谓的 XA 模式是对支持了 XA 协议的数据库的 API 进行自动化的，XA 事务开启和统一提交回滚，Mycat 是属于一种 proxy，伪装的数据库层来代理背后的数据库，不知道这种结合会不会有什么问题存在，特别是 XA 这种出现中间层和 Seata 的兼容问题导致 XA 死锁就麻烦大了。\nSeata：https://github.com/seata/seata\n@谭玖鹏 提问：\n 请教一个问题，这个 LoadLevel 注解有什么作用\n A：看一下 EnhancedServiceLoader#getUnloadedExtensionDefinition 这个函数，跟一下 spi 那块加载的代码就知道了，跟 dubbo 那边差不多，dubbo 有个博客解析：https://dubbo.apache.org/zh/docs/v2.7/dev/source/dubbo-spi/。\nSeata：https://github.com/seata/seata\n@winyQ 提问：\n 不用 Seata 事务的数据操作方法里用的 datasource 还是代理数据源对象，这个没办法改吗，一旦设置 datasourceproxy，好像就一直只能用这个了。\n A：虽然拿到的都是 datasourceproxy，但是没有 globaltransational 和线程中没有 xid 的时候都是不会干预的；内部还是原来的 datasource 做操作，如果你确定没有 2 个服务以上参与的函数，可以用 globallock+ 对要修改的数据进行 for update 先再做写操作，会比直接加 globaltransational 注解效率高，但是相对而言入侵也高了。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 蚂蚁 Service Mesh 大规模落地实践与展望\n ","date":1614927600,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210305/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c5c658590a95eee0eb2c13cfb67d7d49","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210305/","publishdate":"2021-03-05T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210305/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210305/","wordcount":1701},{"author":"雪连","categories":"MOSN","content":" Serverless Task 是蚂蚁集团在分布式调度和批处理中间件发展而来的解决方案。通过 ServiceMesh 的精细化引流能力，再利用研发框架的“服务分组”配置能力，将 Serverless Task 流量全部收敛在指定的“服务分组”集群内。结合定时任务本身具备的周期、可预测等特点，根据任务执行情况弹性伸缩“服务分组”内的机器资源从而提升资源利用率和系统稳定性。\n 分布式调度在蚂蚁的场景和遇到的问题 在单体架构中，为了解决一台机器在固定的周期间隔执行相同的任务，避免人工干预过多，有了基于 Cron 的单机调度；随着企业级应用的发展和微服务化以及云原生架构的逐渐演进，原先的单体架构逐渐演变为服务化或者云原生架构。在此背景下，既要解决原先单机要解决的定时调度问题，还需要解决任务管理、负载均衡以及高可用、容灾等问题，同时兼顾用户体验的简单高效，分布式调度产品就应运而生。\n在蚂蚁域内，分布式调度广泛应用于各个 BU 的业务场景中，举例：如在支付宝上购买基金的用户每天需要计算基金收益，那么就需要在分布式调度的基础上结合批处理的能力，充分利用应用集群的处理能力，完成每一个用户基金净值的收益计算，典型处理场景如下：\n为了充分利用集群的能力，业务会采用按照业务各个维度拆分的方式对数据进行分片，然后根据分片原则加载数据，最后尽可能的将数据分散在集群机器上完成每一个用户基金净值的计算。通过类似上述集群执行的方式，结合分布式调度及批处理的能力，可以完成业务的计算诉求，但是由于这部分计算逻辑被原有的应用集群承载，随着业务的发展和数据量的不断增加，就会有如下的问题：\n稳定性问题：在线流量如 RPC/MSG 等与任务调度流量（简称异步任务流量）在 CPU/MEM/线程池 资源共享而引发的相互抢占导致的稳定性问题。\n资源利用率问题：异步任务流量最常用 Cron 表达式来描述，对于一天 24 小时只需要运行 7 个小时的任务来说，剩余的 17 个小时的资源就是浪费掉的。\n效率问题：业务同学在接入任务调度以及对批处理执行的控制，数据量统计、异常归类和动态调整参数等复杂性导致的研发效率较低；发布上线后，对处理速度、资源容量评估以及稳定性投入导致的运维效率较低。\nServerless Task 解决方案 为了解决上文分布式调度在蚂蚁的多年实践中遇到的问题，我们提供了 Serverless Task 的解决方案。\n通过故障隔离的方式来提高稳定性。Serverless Task 在不影响大家研发习惯的前提下，业务同学只需要通过在 PaaS 平台中，在同一个集群下申请“服务分组”集群，这些机器用于达到只承担异步任务的流量，而屏蔽其他在线流量的访问的目的。机器资源承载的流量做区分后，再配合 ServiceMesh 的精细化引流能力能够将流量收敛在指定的“服务分组”内，同时结合框架的“服务分组”配置能力，能够指定 Bean、消息、任务或者服务是否注册或者启动。通过上述的方式，最终能够实现，指定的异步任务收敛在指定的“服务分组”机器资源内，以此实现在线流量和异步任务流量的故障隔离，避免相互影响，而提升系统的整体稳定性。\n通过弹性伸缩的方式来提高资源利用率。基于可控弹性伸缩 HPA 技术，通过分析任务的 Cron 表达式或者基于 CPU/Mem/线程池等各项正常或者异常指标，能够将隔离在指定“服务分组”内运行异步任务的机器动态调整其 Pod 数量，在满足业务处理诉求的前提下，通过弹性伸缩技术最大化的提升资源利用率。\n提供更加产品化的能力。Serverless Task 支持处理器编排、支持迭代隔离、自定义参数和自定义限流等能力以提升业务的研发效率；同时，异步任务在故障隔离的基础上，利用弹性伸缩技术动态调整业务的 Pod 资源数量，可以让业务研发同学尽可能少的关注资源而只需关注任务的运行情况，以此极大的提升运维效率。\nServerless Task 关键能力介绍 弹性伸缩技术 上文介绍了 Serverless Task 的解决方案思路，为了真正实现 Serverless ，让业务同学不关注容量只关注业务逻辑，一个很重要的技术能力就是弹性伸缩。\n弹性伸缩技术，通过分析任务的 Cron 表达式或者基于 CPU/Mem 等各项指标计算出来的画像（每个时刻期望的 Pod 副本数量），来确定每个时刻的应该 Ready 的 Pod 数量，当在流量低峰或者任务没有在运行的时间就可以将机器缩容到相对较小的副本数。同时为了能够在最短的时间内恢复业务 Pod 的运行，启动速度是一个至关重要的指标，采用基于 ServiceMesh、JVM Elastic Heap 和内存 swap 的容器保活技术实现极速启动，来保证业务容器再恢复到期望的副本数时，有足够快的速度。\n 任务链路隔离与伸缩能力 通过上面描述的 Serverless Task 的解决方案，能够将异步任务的流量收敛在一个业务集群指定的“服务分组”集群内，并能够在弹性伸缩的基础上充分利用机器资源。但是，这样就会导致新的问题，当上游系统被隔离后，其处理速度和稳定性都会一定程度的增加，但是对下游的调用量就会激增，导致下游出现热点或者稳定性问题。基于此，我们提供了任务链路的解决方案，期望将 Serverless Task 触发异步任务的门面系统以及对下游系统的调用，都能够通过“服务分组”的方式隔离开，期望组合成一条异步任务流量作为入口流量的任务链路，具体的实现方案如下所示。\n每一个 Serverless Task 在周期触发时都会自动携带染色标识（每一个异步任务的唯一标识），通过在任务调度平台选择当前异步任务要引流到的“服务分组”，就可以完成门面系统的 Serverless Task 到指定“服务分组”的引流。每一次 Serverless Task 调用门面系统均携带染色标识，门面系统紧接着对下游系统再发起调用，门面系统结合控制面的业务引流能力，就可以在控制面对门面系统下发引流规则，并配置流量比例，便可以将门面系统对下游系统的调用也收敛在指定的“服务分组”集群内。以此类推，下游系统如果继续有对后续系统的调用，也可以采用类似的方式推送引流规则来完成指定调用流量的“服务分组”集群收敛，以此来完成一条 Serverless Task 作为入口流量的任务链路的流量隔离，并具有单独的业务语义，比如：批扣链路、计价链路。\n在完成了任务链路的隔离之后，由于入口的流量是由异步任务驱动或者触发的，流量是能够通过 Cron 或者运行状态做比较准确的预测，那么在任务链路执行完毕后，就可以将整个链路的资源全部伸缩掉，同样当异步任务的流量高峰到来之前时再扩容出足够的机器资源，以此在隔离出任务链路的同时，还能提升整体任务链路的稳定性以及整个任务链路的资源利用率。\n总结与展望 通过 ServiceMesh 的精细化引流能力，可以将 Serverless Task 流量收敛在指定的“服务分组”集群内，再利用框架（如 SOFA Boot）的“服务分组”配置能力，控制非期望的 Bean 和服务在“服务分组”集群内关闭，最终就能够做到将 Serverless Task 流量完整的收敛在指定的服务器集群内，达到流量收敛的目的后，再结 …","date":1614668400,"description":"如何实现任务调度和存量应用的 Serverless 化，本文为大家介绍 Serverless Task 是如何实现这一解决方案。","dir":"blog/antgroup-serverless-task/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cb83515191621dc518d49a84ac297f0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-serverless-task/","publishdate":"2021-03-02T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/antgroup-serverless-task/","summary":"Serverless Task 是蚂蚁集团在分布式调度和批处理中间件发展而来的解决方案。通过 ServiceMesh 的精细化引流能力，再利用研发框架的“服务分组”配置能力，将 Serverless Task 流量全部收敛","tags":["Serverless","任务调度","弹性伸缩","ServerlessTask","Service Mesh"],"title":"Serverless 给任务调度带来的变化及蚂蚁集团落地实践","type":"blog","url":"/sofastack.tech/blog/antgroup-serverless-task/","wordcount":2748},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@宓文明 提问：\n 请教：大家有没有遇到过 SOFAArk 工程这样的情况：双机房集群部署（检查模块 jar 大小相同、MD5 相同、部署时间相同），其中一台服务器中报错 NoClassDefFoundError（调用模块工具类的静态方法时，工具类找不到），其余的服务器都 OK。 A：你们登录到机器上去，堆栈是有的；这种问题可能是因为底层有 class 没找到，两个思路： - 版本冲突 ，不一定局限在你的 JsonUtil 这个类，里面的类也有可能引发 。 - 通过 arthas ，分析下不同 bizClassLoader 加载 JsonUtil 的情况。\nSOFAArk:https://github.com/sofastack/sofa-ark\n@郭强 提问：\n MOSN 是如何保证一定是先于业务容器启动，并且保证是后于业务容器销毁呢？\n A：启动就是按 pod 里的容器顺序启动，MOSN 容器在 APP 容器前。APP 容器内的应用进程启动前会检查 MOSN 的端口是否存活，得等到 MOSN 进程启动完成才能继续。销毁 pod 的时候没有特别处理，就是摘了pod 的流量整个销毁。\nMOSN:https://github.com/mosn/mosn\n@郭强 提问：\n APP 容器内的应用进程启动前会检查 MOSN 的端口是否存活。 这个是怎么做到的呢，是自动修改应用容器的 command 配置？还是说需要应用进程的 dockerfile 保证一定规范吗？\n A：蚂蚁内部的 Kubernetes 有针对性的做一些定制改造支持，标准 k8s 目前是控制不了容器启动顺序的； 最好的方式还是 k8s 原生支持 sidecar lifecycle，没有这个的话，相对折中的方式就是在应用启动脚本前 check 下了。\nMOSN:https://github.com/mosn/mosn\n@饶文强 提问：\n 请教一下：我不是很理解这一步锁撤销的步骤：线程 A 进入同步代码块方法，尝试获取偏向锁，此时若 CAS 线程 id 替换失败，为什么涉及一个偏向锁撤销，线程 A 不是没有获取到锁。我的理解是此时锁对象的偏向锁线程 id 不是线程A本身，为什么还需要偏向锁撤销？ A：因为偏向锁可以被降级，其他的不可以，这个时候需要升级锁或降级锁；偏向锁持有者是不会做降级操作的，只有前来竞争锁的线程会去判断。\nSeata:https://github.com/seata/seata\n@莹 提问：\n 有个场景：tcc 模式，try 方法创建订单记录，插入到数据库，然后异常回滚，在 rollback 方法中把这个订单记录根据主键删除，请问数据库主键字段怎么传过去？\n A：可以通过一阶段把 xid 对应业务信息存在 redis 中，二阶段通过 xid 拿出来使用。\nSeata:https://github.com/seata/seata\n@敲跃 提问：\n 问个问题：Seata 的 at 和 saga 模式 一阶段本地事务已提交，为了防止这部分数据被其他事务读到，文档给的解决方案 \u0026amp;gt; 脏读 select 语句加 for update，代理方法增加 @GlobalLock+@Transactional 或 @GlobalTransaction ； \u0026amp;gt; 实际操作的时候：涉及到本地事务的表的所有 sql 和方法都要这么改造，会不会成本太大，有没有其他好点的解决方案？\n A：涉及到所有的写入口加上 @GlobalTransaction 即可；只读场景 @GlobalLock +for update 即可；读了就写场景一定要 @GlobalTransaction，只读了给前端展示之类的。\nSeata:https://github.com/seata/seata\n本周推荐阅读 Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 蚂蚁 Service Mesh 大规模落地实践与展望\n 基于 MOSN 和 Istio Service Mesh 的服务治理实践\n ","date":1614322800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly20210226/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fff3af65c30bb18078a3222b86261205","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly20210226/","publishdate":"2021-02-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly20210226/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly20210226/","wordcount":1351},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@王盛 提问：\n 这个配置在 sidecar 里面怎么改，这个怎么配到 Istio 里面?\n A：在 Istio 中关于 tracing 这块的 driver 目前是通过配置 xxx_bootstrap.json 静态配置的，然后通过 istioctl 命令参数来选择使用哪个 driver。当前由于 skywalking 自身配置还没作为 bootstrap 的静态默认配置，所以需要你自己修改下 xxx_bootstrap.json，这个配置就好了（即把上面的那个配置加进去）。简单说就是修改下 sidecar 的静态默认配置文件，增加 skywalking 为 tracing 的 driver 配置。\nMOSN：https://github.com/mosn/mosn\n@卞平超 提问：\n TCC 多阶段；rollback 可以设置顺序吗？比如被调用的服务，先回滚，再回滚主服务的，A-\u0026amp;gt;B，想先回滚 B 的数据，commit 和 rollback；方法中的业务代码有异常，是会不断的重复执行。\n A：TC 的表字段 datetime 看下精度，二阶段都决议了，没有从 commit 异常，直接到 rollback。如果 10 个参与方，就 1 个 commit 异常，不去重试保证最终一致的话，数据不就乱了；已经决议了，就要保证起码能最终一致，而不应该串改结果，参考消息队列设计，为什么消费异常要重试。\nSeata：https://github.com/seata/seata\n@方舟 提问：\n 请问一下，在 TCC 模式中，如果 TM 和 TC 断开连接，能够保证全局事务的回滚吗，重连超时后，全局事务会回滚吗？\n A：会重连，然后重试；需要你自己保证幂等和悬挂，会等你连上之后再重试。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁集团轻量级类隔离框架概述 | SOFAArk 源码解析\n 蚂蚁集团研发框架总览 | SOFABoot 框架剖析\n SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理\n 蚂蚁集团 API Gateway Mesh 思考与实践\n 本周发布 本周发布详情如下：\n1、SOFARPC发布 v5.7.7版本，主要变更如下：\n 使用 Github Action 替代 Travis 进行持续集成 升级 jackson-datebind 到 2.9.10.7 升级 junit 到 4.13.1 修复了Rest中，当请求经过代理源IP获取不准确的问题 修复了内置 Protobuf Compiler 的 BUG 详细参考：https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.7\n","date":1613718000,"description":"SOFA WEEKLY | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210219/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"29b9f9ae46cecd6979ce334f8e11baf0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210219/","publishdate":"2021-02-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210219/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210219/","wordcount":1096},{"author":"李唯","categories":"云原生","content":" Service Mesh 双十一后的探索和思考(上) 引言 2019 年 Service Mesh 在蚂蚁大规模落地并完美支撑双十一核心链路，对于落地过程在去年已经有系列文章解读。而在此之后的一年多时间，Service Mesh 在蚂蚁又在如何演进呢。本文介绍蚂蚁 Service Mesh 在双十一落地之后所做的探索和思考。\n能力建设 得益于 Service Mesh 将业务和基础设施解耦，在过去一年中我们的基础设施能力得到了飞快的发展。大量能力大规模落地蚂蚁。例如链路加密，可信身份认证，服务鉴权，自适应限流，集群限流，精细化引流，服务自愈等。这里先对四个能力进行解读，其它能力后续再有文章讲述。\n链路加密 为了达到一个更高的安全水位，我们预期在蚂蚁内部所有的通信 100% 加密覆盖，这就是链路加密。\n设计 链路加密落地最大的挑战就是加密对业务不能造成影响，包括几个问题：\n 必须简化大规模场景下的运维复杂度问题，需要具备可灰度、可回滚的能力； 灰度运行期间，明文和加密切换不能对业务请求造成影响，需要进行热切换； 开启加密以后，对性能的影响必须控制在可接受的范围内； 基于这些需求，完成了链路加密的架构设计，主要思路包括：\n 通过统一的管控面控制服务端应用的配置，基于动态服务发布与订阅机制，在服务端支持加密能力以后，客户端自动进行加密的切换，运维人员只需要控制服务端配置节奏完成灰度；在灰度运行期间，服务端同一个端口需要同时支持明文和加密的能力； 相比于明文通信，基于 TLS 加密的通信主要消耗在连接建立的握手期间，服务端和客户端采用长连接的方式，减少连接的建立，以减少开启加密对性能的影响； 客户端在感知到服务端明文和加密状态变化以后，需要在不同的长连接之间进行稳定的切换，后文会详细介绍； 完整的一个加密开启流程如图所示，首先运维人员在管控面选择需要开启加密的应用，通过 XDS 完成配置下发。MOSN 在收到配置以后，会基于 SDS 机制获取到证书和私钥在内存中，证书和私钥由统一的 Secret 进行管理，应用侧不持久化保存。收到证书和私钥以后，会向注册中心发布本机已经支持了加密，注册中心会向所有订阅的客户端进行推送，客户端收到推送以后，与服务端的通信切换到加密状态。\n加密状态热切换：连接淘汰机制 我们的加密通信是基于 TLS 进行的实现，一个连接在建立好并且开始传输数据以后，连接上的数据是 TLS 加密的还是明文的就已经固定了，不存在将一个明文通信的连接变成 TLS 加密连接的情况。基于 TLS 这个机制，通信从明文切换到加密时，一定是需要新建一个连接，并且成功完成 TLS 握手。\n为了做到在连接切换期间业务请求不受影响，MOSN 实现了一个连接淘汰机制，用于连接加密状态的热切换。 每一个请求在 MOSN 中经过了路由和负载均衡以后，会选择到一个后端地址，基于这个地址从连接池中选择对应的长连接转发请求，在引入了加密切换以后，每次选择到连接以后，都需要判断当前预期的加密状态和连接的加密状态是否匹配，如果不匹配，则会创建新的连接进行加密状态的切换，并且使用新连接将连接池中的旧连接代替，这样就可以确保后续的请求都使用状态匹配的连接。对于被替换的旧连接，我们需要进行淘汰，但是这个淘汰不是简单的断开连接，因为旧连接上可能还有正在处理的请求，如果直接将连接断开就会导致请求有损，这是不能接受的。\n那么是如何淘汰旧连接的呢？这里就要讲到 MOSN 的长连接保持机制了。为了避免因为异常断网等导致连接“假死”的情况，在连接空闲时，会主动发起心跳请求，确保连接处于活跃状态，而如果服务端一段时间内都没有收到心跳，则会主动将连接断开。连接淘汰就是利用这个机制，对于准备淘汰的连接，我们将停止该连接的心跳发送，当连接上的请求处理结束后，这个连接上就不再会有任何数据的传输，经过一段时间后，服务端就会主动将这个连接断开，此时连接断开是安全的，不会影响任何请求。 优化 对应用无感知开启加密，除了指开启过程中不需要重启、请求无损等，还包括在开启以后的资源消耗、RT 影响也需要是无感知的。在实际落地应用过程中，由于我们都是使用长连接，TLS 握手带来的建连消耗只占用了很少一部分，在长连接通信过程中的对称加密消耗经过实际测试几乎可以忽略不计，看上去链路加密对性能的指标没有什么问题。\n但是在实际大规模落地以后，我们发现部分应用开启了加密以后，内存占用有显著的上涨，经过排查，定位到属于Golang TLS 标准库实现问题（ MOSN 是使用 Golang 编写的），我们自行优化以后，也向 Golang 官方提了 PR回馈社区，目前该 PR 已经被 Golang 官方所接受，预计在 go1.16 中发布，具体实现可以见 crypto/tls: pool Conn\u0026amp;rsquo;s outBuf to reduce memory cost of idle connections\n自适应限流 流量管理本身就是 Mesh 架构最为核心的功能之一，我们在 MOSN 中实现了多种策略的限流能力，包括单机 QPS限流、集群限流、热点限流、接口熔断、自适应限流等，其中自适应限流是一大亮点。\n限流是每个技术同学都不陌生的名词，同时也是很多不同角色的同学头疼的事情。对于业务同学而言逐个接口做容量评估和压测回归费时费心，有限的精力只能投入到重点的接口保障上，难免会漏配一些小流量接口的限流；而负责质量和稳定性保障的同学经常在故障复盘时看到各种漏配限流、错配限流、压测故障、线程阻塞等造成的各种故障\u0026amp;hellip;\u0026amp;hellip;\n我们希望即使在系统漏配错配限流的情况下，在系统资源严重不足时 MOSN 能够精准的找到导致系统资源不足的罪魁祸首，并实时根据系统水位自动调节异常流量。这就是自适应限流想要实现的效果。\n技术原理 能用一句话说清楚你们的技术原理吗？ 类 PID 控制流量闭环自适应调节 朴素的解释就是，触发限流后一边观察系统整体水位，一边秒级按比例调节流量的策略，用一张图来解释具体的原理： 1.系统资源检测：秒级检测系统资源占用情况，如果连续超过阈值N秒则触发基线计算，同时开始拒绝压测流量进入； 2.基线计算：将当前所有的接口统计数据遍历一遍，通过一系列算法找出资源消耗大户，再把这些大户里明显上涨的流量找出来，把他们当前的资源占用做个快照存入基线数据中； 3.基线调节器：将上一步骤存入的基线数据根据实际情况进行调整，根据系统资源检测的结果秒级的调整基线值，若系统水位超过阈值则按比例下调基线值，否则按比例恢复基线值，如此反复； 4.限流决策：根据上述步骤生产的基线数据决策是否限流；\n自适应限流已在全站线上应用中大规模启用，成功防范了多起业务故障。为新春红包压测和线上业务保驾护航。\n技术优势 相较于传统的限流组件，MOSN 中的自适应限流具备很多优势，MOSN 架构天然的流量劫持让应用无需逐个接入SDK，也无需为特定语言开发不同版本的限流组件，同时给业务同学降低了配置的难度，也为业务实现了兜底保护。在研发效能和研发成本上都取得了明显的收益。\n MOSN 自适应限流 传统 QPS …","date":1613548800,"description":"本文介绍蚂蚁 Service Mesh 在双十一落地之后所做的探索和思考。","dir":"blog/service-mesh-exploration-thinking-after-1111-1/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3a08e94a57454e3ef36f8eee6da6795e","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","publishdate":"2021-02-17T16:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","summary":"Service Mesh 双十一后的探索和思考(上) 引言 2019 年 Service Mesh 在蚂蚁大规模落地并完美支撑双十一核心链路，对于落地过程在去年已经有系列文章解读。而在此之后的一年多","tags":["云原生"],"title":"Service Mesh 双十一后的探索和思考(上)","type":"blog","url":"/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","wordcount":5691},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" 本文作者：蚂蚁集团黄挺（花名鲁直），SOFAStack 社区主理人，同时负责蚂蚁集团云原生方向的推动和落地，包括 Service Mesh、Serverless、消息、微服务等领域，带领 SOFA 团队扎根技术完成很多落地实践。\n 大家好，我是鲁直，有段时间没有和大家见面，今天是农历一年的起点，首先祝大家新年快乐，在新的一年牛气冲天！在这样特别的日子里，我想和大家分享对于 Service Mesh 未来方向的思考，再谈谈 SOFAStack 社区接下来计划做的一些事情，希望大家接下来能够在社区里面玩得开心，let\u0026amp;rsquo;s have fun together! Service Mesh 是否已经解决了所有问题？ 2020 年， SOFA 团队宋顺（花名齐天，当前蚂蚁集团 Service Mesh 负责人）在 QCon 上海站分享了《蚂蚁 Service Mesh 大规模落地实践与展望》，详细讲述了 Service Mesh 在蚂蚁集团的进展和未来规划。 在过去的几年里面，Service Mesh 在整个云原生社区如火如荼地发展，从刚开始的 Linkerd，到后面的 Istio，不断地有大公司加入到 Service Mesh 的领域的开拓之中，随着小剑、净超等同学在国内布道 Service Mesh，Service Mesh 从 2017 开始在国内火热程度也不断升温，SOFA 团队也在这个时候开始关注到 Service Mesh 这个领域，并且开始在内部尝试做落地的事情，也和业界的很多朋友一起举办了一场又一场的 Service Mesh Meetup。\n应该说我们是幸运的，成功在 2019 年实现了 Service Mesh 在蚂蚁大促业务链路上的全面落地，获得了大规模落地 Service Mesh 的经验，并且在这之后持续应对 Service Mesh 大规模落地之后的遇到的各种挑战，截止到 2020 年底，蚂蚁集团已经基本上实现了在线业务的全面 Service Mesh 化，在一部分网关场景上，也采用了 Service Mesh 的架构，实现了南北向和东西向流量架构的统一。\n但是随着 Mesh 化的进程不断地往前推进，一直在我们心中萦绕这一个问题，Service Mesh 在一定程度上解决了基础设施和业务耦合的问题，但是是否已经把所有的问题都解决完毕了？这个问题的答案显然是没有全部解决完毕，这个尚待解决的问题还是基础设施和业务耦合的问题。\n目前包括蚂蚁集团在内的各种各样的 Service Mesh 的解决方案，都是会选择采用尽量透明的方式去适配应用已有的协议，让业务尽量减少接入 Service Mesh 的成本，即使不是全透明的方式，而是采用瘦 SDK 的方式接入（蚂蚁集团目前采用了这种方式），也是为了这个目的。在这种形态下，应用固然可以透明地获得非常多的能力，包括限流，服务发现，安全通信等等，但是一旦涉及到 RPC 协议的变化（从 SOFARPC 到 gRPC），后端缓存的变化（从 Memcached 到 Redis），应用还是需要去修改代码适配新框架的 SDK，这又是一件无论让应用还是让基础设施团队非常痛苦的事情，本质上还是应用去适配基础设施的变化，而不是反过来。\n###\nService Mesh 的未来方向：Cloud Native Application Runtime 那么我们应该如何去解决这个问题？在一次内部的会议上，我们和几个同事在讨论如何对 K8s 里面我们自定义的 Operator 进行规范化的问题，防止一个有问题的 Operator 把整个 K8s 搞挂了，但是一个同事提出了 Operator Framework 的想法，在 Operator 里面运行一个 Sidecar，这个 Sidecar 提供 Operator Framwork 的能力，这里面给了我们一个启发，可以用 Sidecar 这种模式去实现一个开发框架，一个运行时，来更好地帮助业务屏蔽掉对于后端基础设施的访问，我们看到业界也出现了这样的一些产品，比如 Dapr，CloudState 等，在这种模式下 Sidecar 已经不是一个简简单单的 Proxy，而是一个 Runtime，我们把这种形态称之为 Cloud Native Application Runtime。\n这种模式之所以可以称之为 Cloud Native Application Runtime，关键还是 Sidecar 定义了一套面向应用的 API，这套 API 正是解耦应用和基础设施的关键。有了这套 API Spec，就相当于在应用和基础设施之间构建了一层防腐层，只要这一层 API Spec 能够持续往前保持兼容，后面的基础设施不断地演进和变化，都不会动到应用侧，基础设施和应用之间才能够实现更加彻底的分离，未来基础设施无缝升级才会成为可能。未来云原生的应用在不同的云之间迁移，甚至基于多朵云来构建应用，应用这一侧也不用重复进行适配的工作，应该说，这种模式也是符合未来混合云的方向的。所以，我们大胆的预测，未来 Service Mesh 持续往前继续演进，必然会发展到 Cloud Native Application Runtime 这样的方向。\n基于这样的思考，在 2021 年，SOFAStack 社区一方面会继续推进已有的项目的健康发展，另一方面在继续在Service Mesh 的方向上深耕：继续分享在 Service Mesh 领域上的一些新思考之外，比如 Service Mesh 大规模落地之后的研发效率和运维效率的解决思路，我们也会和社区中的其他的组织一起通过 Service Mesh 的 Meetup 等活动继续推动 Service Mesh 的理念在国内的影响力，以及企业落地实践。（PS：最近 MOSN 刚刚公布了 2021 年的 RoadMap，欢迎大家关注：https://github.com/mosn/mosn/issues/1559，其他项目的 RoadMap 也会在春节后陆续和社区讨论然后公布；我们计划在 3 月份举办一次 Service Mesh 的 Meetup，欢迎感兴趣的社区同学报名)。\nSOFAStack 开源社区即将成立三周年，SOFA 团队深刻地体会到一个开源项目的持续健康地发展，关键在于社区和社区中的每一位开发者，是你们每一个 star，每一个 issue 和 PR 推动着项目的成长。特别感谢接近三年时间，大家一同参与社区建设，感谢一起帮助社区成长的小伙伴们。SOFAStack 开源社区还有很长的路要和你们走，我们也会联合其他社区一起推动 Cloud Native Application Runtime 的理念的落地和实践，希望有更多开发者可以和我们一起去探索 Service Mesh 的未来形态，一起推动其成为云原生应用构建的一种标准方式。\nAwesome SOFAer, then awesome SOFAStack， Let\u0026amp;rsquo;s have fun together！\n","date":1613113200,"description":"Special Weekly | SOFAStack 社区牛年展望，Let's have fun together!","dir":"blog/sofa-weekly-20210212/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3ef0208984bc034e62f2db51cf66a8e4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210212/","publishdate":"2021-02-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210212/","summary":"本文作者：蚂蚁集团黄挺（花名鲁直），SOFAStack 社区主理人，同时负责蚂蚁集团云原生方向的推动和落地，包括 Service Mesh、Serverles","tags":["SOFA Weekly"],"title":"Special Weekly | SOFAStack 社区牛年展望，Let's have fun together!","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210212/","wordcount":2162},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@李明阳 提问：\n SOFAArk 的项目里面 controller 层可以是 Biz 包么，这样 mng 里面引入 one，然后启动 mng 访问不到 one 里面的接口呢？ A：SOFAArk 的项目里面 controller 层不限制的，biz 包部署普通的依赖包，它是一个可执行的 jar，ark包 = biz + plugin + container，动态部署你可以通过 telnet 指令的方式去动态安装，不建议直接塞到 pom 里面去。\nSOFAArk：https://github.com/sofastack/sofa-ark\n@王盛 提问：\n 请教个问题：\u0026amp;ndash;set meshConfig.defaultConfig.binaryPath=\u0026amp;ldquo;/usr/local/bin/mosn\u0026amp;rdquo; 这个不起作用，有谁碰见过这个情况？ A：你用的是 istio1.5.2 吧，这个是不行的，istio 代码写死了的。这种手动注入应该可以的。这一块儿有些细节没有说明，你可以重新提交一下 pr。 MOSN：https://github.com/mosn/mosn\n@杨星 提问：\n 如果 Seata 使用注册中心的话，Client 端的 registry.type，与 config.type 需要改成对应的注册中心吧，Client 端的这两项配置的作用是什么？SeataServer 的这两项配置倒好理解，Client 端的config.type 目的是读取client端的配置信息，那 registry.type 是干什么的呢？\n A：我认为，registry.type 指的是注册中心的类型，config.type 指的是配置中心的类型。注册和配置中心是 2 个东西，我认为是从注册中心里拿 seata-server 实例，客户端找协调者。\nSeata：https://github.com/seata/seata\n本周推荐阅读 干货 | 蚂蚁集团是如何实现经典服务化架构往 Service Mesh 方向的演进的？\n 开源 | SOFAMesh 的通用协议扩展\n 【剖析 | SOFAMosn】系列之 SOFAMosn 的诞生和特性总览\n Service Mesh 发展趋势：云原生中流砥柱\n MOSN 项目进展 本月我们还认证了一位新的 Committer，是来自字节跳动的 郑泽超 同学，感谢 郑泽超 同学为 MOSN 社区做出的贡献。\n本周发布详情如下：\n1、MOSN发布 v0.21.0 版本，主要变更如下：\n 限流模块升级与优化，支持自定义过滤条件等能力 为适配路由支持变量机制对部分常量名进行了不兼容的删除和新增，可能会影响部分基于 MOSN 的代码编写 新增了 DSL(Domain-Specific Language)的路由支持 StreamFilter 模块支持加载基于 Go 动态连接库编写的 Filter 基于 XProtocol 实现了 DubboThrift 协议的支持 其他 BUG Fix 与优化 详细参考：https://github.com/mosn/mosn/releases/tag/v0.21.0\nSOFABoot 项目进展 本周发布详情如下：\n1、SOFABoot发布 v3.6.0 版本，主要变更如下：\n 支持本地开发时自动将 SOFABoot 日志输出到控制台 startup endpoint 采用新的数据格式，支持按时间轴分析 修复 baen 加载耗时的图形化展示问题 修复 ReadinessCheckListener 的启动顺序问题 SOFARPC 升级版本至 5.7.7 SOFATracer 升级版本至 3.1.0 SOFA-common-tools 升级版本至 1.3.2 Tomcat 升级版本至 9.0.37 使用 Github Action 进行CI 移除默认的 Maven Profile 配置 详细参考：https://github.com/sofastack/sofa-boot/releases/tag/v3.6.0\nSOFATracer 项目进展 本周发布详情如下：\n1、SOFATracer 发布 v3.1.0 版本，主要变更如下：\n 修复 flexible result.code 返回成功、失败 code 码 修复 DubboSofaTracerFilter Server span tag value error 修复 SofaTracerFeignClient 中 UnsupportedOperationException 问题 优化 spring mvc filter 的 error tag 支持 kafka 支持 RabbitMQ 支持 oracle rac JDBC URL 支持 hikari 详细参考： https://github.com/sofastack/sofa-tracer/releases/tag/v3.1.0\n","date":1612508400,"description":"SOFA WEEKLY | MOSN、SOFABoot、SOFATracer 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210205/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4cde1d3e68e2e13cbca7278164a4ab12","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210205/","publishdate":"2021-02-05T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210205/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、SOFABoot、SOFATracer 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210205/","wordcount":1518},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@潘麒安 提问：\n 请教下 session-server 报这个错，是需要扩更多的 session 么，但是 session进程本身 CPU 和内存占用不高。 A：看错误是把 session 发向 data 的处理队列打满了，可以排查一下，检查一下使用的版本，data 的资源使用和common-error.log 下的错误日志。\n SOFARegistry：https://github.com/sofastack/sofa-registry\n@刘达 提问：\n MOSN 怎么配置监听一个端口，这个端口上会接受有多种协议的数据，根据协议转发到不同的集群地址。ISTIO+MOSN， 用户 http 请求 gateway，通过 gateway 调 dubbo，每个应用自动注入 sidecar，测试没跑起来。 A：配置 Auto，支持协议自动识别，转发不同的集群，那就看路由了；用新版本，然后这样配置。 MOSN：https://github.com/mosn/mosn\n本周推荐阅读 剖析 | 详谈 SOFABoot 模块化原理\n 网商银行是如何建设金融级云原生分布式架构的？\n 实操 | 基于 SOFABoot 进行模块化开发\n 开源 | SOFABoot 类隔离原理剖析\n SOFABolt 项目进展 本周发布详情如下：\n1、SOFABolt 发布 v1.5.7 版本，主要变更如下：\n 优化 log4j2 日志配置，解决在异常场景下的性能问题 详细参考：https://github.com/sofastack/sofa-bolt/releases/tag/v1.5.7\nsofa-common-tools 项目进展 本周发布详情如下：\n1、sofa-common-tools 发布 v1.3.2 版本，主要变更如下：\n 修复 LogCode2Description 性能问题 详细参考：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.2\n","date":1611903600,"description":"SOFA WEEKLY | SOFABolt、 sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210129/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4f4f43ac764d4c99010c408e4d53c92e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210129/","publishdate":"2021-01-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt、 sofa-common-tools 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210129/","wordcount":934},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@叶毅威 提问：\n 请教下 SOFARegistry 数据持久化在哪里啊?\n A：SOFARegistry 的元数据（注册中心自身的 IP 列表之类的数据）存储在 meta 角色内，使用 JRaft 进行存储。 应用的发布数据保存在 data 角色的内存中，采用三副本（可配置）的方式实现高可用。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n@叶毅威 提问：\n 我用 SDK 调用注册了一个 datainfo 但是关掉之后 这个并没有下线，是哪里需要配置么，不是默认链接断开就下线么？\n A：session 上采用 HTTP 方式获取的数据都是当前节点的注册数据，只有 data 上才会做数据聚合。 dataInfo 是不会被删除的，连接断开后对应 dataInfo 下的对应 Publisher 会被自动移除。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n@田冲 提问：\n 现象：canal 监听到某个被分布式事务控制的表的 insert-binlog 日志后再去查询 MySQL 表里数据时发现这条数据不存在，延迟1秒钟左右再查询就能查询到。 疑问：seata-at 模式-两阶段提交的设计会出现 MySQL 先生成了 binlog 日志，后提交事务的情况吗？\n A：这个问题其实很简单，你 canal 读不到，那你自己应用本地事务提交后马上读这个 insert 的数据看能不能读到；如果读到，理论上来说这个过程不可能超过一秒，所以如果你应用能查到，你canal查不到，排查canal的问题，而不是 Seata 的问题；Seata 最后也只不过做了 connection.commit；最后事务的提交落库是数据库方本地事务流程落库，Seata 不会起到任何干扰，Seata 代理的是 jdbc 层的处理；redo 后写 binlog 时马上就会广播的，而不是事务提交才把 binlog 广播出去；所以内 xa 的二阶段没提交你就去查主库，由于隔离级别不一定查得到。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Kubernetes 是下一代操作系统 | 面向 Kubernetes 编程\n 蚂蚁集团生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理\n 蚂蚁集团服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析\n 开箱即用的 Java Kubernetes Operator 运行时\n ","date":1611298800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210122/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"16aa2c7282629fe75b244cdce08845e7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210122/","publishdate":"2021-01-22T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210122/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210122/","wordcount":1098},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@吴小彬 提问：\n 请教下，如果分支事务中使用了分库分表中间件（shardingsphere-proxy、mycat 等），Seata-AT 模式是不是不能用的？是只可以用 TCC 模式吗？现在的 shardingsphereProxy 中间件（不是 shardingsphereJdbc ）用 AT 模式，它对微服务来说就是一个 MySQL 连接，它是怎么知道微服务调用链中的 xid 的？\n A：可以用，shardingsphere 4.1 支持 Seata AT， proxy 我估摸着有点悬，因为他属于一个代理层。Jdbc 是直接在应用的 Jdbc 层提供服务的，所以 AT 可以很好的支持。\n@谭玖朋 提问：\n 在关于 AT 模式，第一阶段执行完后生成行锁然后注册分支事务，其中的行锁具体是指什么锁呢？因为发现第一阶段执行完后，其实再查数据的话是已经改变了。所以关于这个行锁这么解释？\n A：Select for update 的时候，首先 Seata 会代理这个语句，去查询 TC 这个行有没有锁住，如果没锁住，客户端业务用了 for update 那么就拿到了本地锁，此时因为本地锁排他，这个时候没有全局锁的 for update 就是分布式下的读已提交。 不是允许脏读，是读已提交。读未提交是默认的，所以只有在你 update 的时候（update 是当前读），但是如果你的 update 是基于快照度的 select 结果，可能会出现事与愿违的结果，如果你要基于某个数据来 update，要么 for update 来读分布式下的已提交，要么就用 update x=x-1 之类的写法，因为提交时会抢占全局锁，没抢到会 rollback，释放当前锁进行重试，这样就能保证抢到锁的时候，update 的数据当前读是分布式下的读已提交并修改 目前好像没人写关于 AT 行锁及全局锁部分源码有分析讲解的资料，如果感兴趣可以去阅读一下，写出来投稿给我们。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Mecha：将 Mesh 进行到底 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 Service Mesh 和 API Gateway 关系深度探讨 Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍 Occlum 项目进展 Occlum 发布 v0.19.1 版本，主要变更如下：\ni.同时兼容 Glibc 和 musl libc的应用\nii. 支持基于 DCAP (Intel SGX Data Center Attestation Primitives) 的远程验证\niii. 修复了内存泄漏问题\n详细发布报告： https://github.com/occlum/occlum/releases/tag/0.19.1\n","date":1610694000,"description":"SOFA WEEKLY | Occlum 发布新版本，Seata QA 整理","dir":"blog/sofa-weekly-20210115/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"48d18f44f20f4b6d5f8b219e383bfa51","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210115/","publishdate":"2021-01-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210115/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Occlum 发布新版本，Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210115/","wordcount":1106},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王家爵 提问：\n SOFABoot 项目要一两分钟才能启动，目前这边有监控工具可以看到启动过程中各个步骤的耗时吗？\n A：3.6.0 之后可以通过 actuator/startup 查看启动的耗时分布。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n@东仔 提问：\n SOFABolt 的最新分支是哪个？\n A：master 就是最新分支。https://github.com/sofastack/sofa-bolt\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\n我是一个小胖子 提问：\n 请问现在已经支持自适应限流了吗？\n A：开源版本里有基于 sentinel 的自适应限流，这个你可以看看 sentinel-golang 的文档，但是和我们内部用的自适应限流有一些差异。\n 你们内部不用 sentinel 是吗？\n A：也用，我们基于 sentinel 做了一些扩展。\n「MOSN」：https://github.com/mosn/mosn\n来永国 提问：\n 为什么我起了 RPC 服务端客户端和注册中心，然后连接调用是可以的，然后我把注册中心关了，它还是跑得通？\n A：client 会有缓存的。\n 获取注册中心的服务有 API 接口吗?\n A：有的，有个从单机 session 获取数据的接口 curl localhost:9603/digest/pub/data/query?dataInfoId=com.test.SimpleService#@#DEFAULT_INSTANCE_ID#@#DEFAULT_GROUP dataInfoId 参数需要进行 url encode 应该还没公开的 API 文档，获取数据的 HTTP 接口也不太易用，我最近会补一下文档还有方便使用的接口。\n 那看样子这个相当于是指定搜索了吗？\n A：是的，目前没有模糊查询的接口， curl localhost:9603/digest/getDataInfoIdList 你可以用这个 API grep 一下。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1610607600,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20220114/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7e0323f9034710384e38cbb6f2176adf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220114/","publishdate":"2021-01-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220114/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220114/","wordcount":1222},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@梁俊 提问：\n 有一台物理服务器，没有安装 OS，是不是可以把 Occlum LibOS 像通用操作系统一样当做 host OS 用，运行 Occlum LibOS，需不需要在物理服务器上安装 host OS?\n A：Occlum 对硬件也是有要求的。这个机器需要支持 Intel SGX 技术。简单得说，就是必须可以安装 SGX 驱动。 Guest OS 是虚拟机的概念，从 guest OS 的角度看，OS 依然运行在 kernel 态。简单来说，如果想使用 Occlum，那么建议方案： 1 . 找一台 SGX 机器 （比如 W55）； 2. 安装一个OS，并且装上 SGX 驱动； 3. 安装 Occlum；\n Occlum 相对于 Docker 有哪些优势，比 Docker 快吗?\n A：Occlum 的优势是安全。外界无法探测运行在 Occlum 中的程序和这个程序使用的内存以及寄存器。也就是说，可以把机密信息（比如密钥）放在 Occlum 中而不用担心信息泄露。\nOcclum：https://github.com/occlum/occlum\n2、@李天宇 提问：\n 可不可以定义一个这样的准则每个 RPC 后面，必须得有一个 TM，每个 TM 维护一个 TM 块，RPC +1，就应该等于 TM 块？ A：这样一个完整的链路有多少个参与者，发起者可以获得，校验规则就是 spanid 是否与参与者数量 +1，是否相等？认为 RPC 向下的服务资源都是一个完整的事务，不管它是否与 db 交互，即可以无 RM ，我的想法就是让 TM 发起者，可以随着链路信息感知所有的 TM。 Tm 可以在每个微服务上都标注下 注解，默认是加入到之前的事务中。TraceId 可以塞到 Seata 的协议中传递到 RPC 下游。\n3、@李天宇 提问：\n 支持不同 branch 不同的 type 吗？\n A：AT 和 TCC 可以共存，Saga 不行。比如 a 数据在 AT 下被改，又被 Saga 或者 xa 分支改动，因为它们不是 AT 无法通过全局锁保证隔离性，除非所有的模式只要内部含有 AT 分支，都去获取全局锁，这样带来了一个问题，如何提前知晓某个 TM 的调用链路中有 AT 分支，靠用户注解上写，那入侵性就有点大了。\nSeata：https://github.com/seata/seata\n本周推荐阅读 SOFAEnclave：蚂蚁机密计算如何解决现实挑战？ 蚂蚁集团宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 开源项目是如何让这个世界更安全的？ 网商银行是如何建设金融级云原生分布式架构的？ MOSN 项目进展 本周发布详情如下：\n1、MOSN 发布 v0.20.0 版本，主要变更如下：\n 路由模块进行了优化与重构，支持变量机制与可配置的扩展模式 使用的 Go 版本升级到了 1.14.13 支持 XDS 非持久化模式下配置的热升级 完善支持了 Netpoll 模式 其他一些新功能、优化与 Bug Fix 详细参考：https://github.com/mosn/mosn/releases/tag/v0.20.0\n","date":1610089200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20210108/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"86ee4a89adc2c475c6f406d2774743c8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210108/","publishdate":"2021-01-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210108/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210108/","wordcount":1294},{"author":"小蚂蚁","categories":"SOFAStack","content":" Forrester 认为：\n包括容器、微服务与服务网格等领域在内的云原生平台，将成为构建适应未来的现代企业的核心引擎。\n在常态化混合异构环境下，面对云原生应用路径的多样化趋势与全维度挑战，企业必须将服务网格技术与微服务有效结合，才能真正释放云原生技术的红利。\n近几年云计算发展如火如荼，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施的统一资源调度带来了极大挑战。\n在越来越复杂的异构基础设施上，存量应用和增量应用应该如何上云？面对大量异构基础设施带来的挑战，企业如何最大化上云价值？\n服务网格（SOFAStack Mesh）是蚂蚁集团自主研发的基于金融级生产实践的增强版服务网格平台，将传统微服务和 Service Mesh 技术进行了深度融合，其核心技术经过了蚂蚁集团的大规模生产实践验证。\n它深度、无缝对接了 SOFAStack 经典应用服务和容器应用服务，为客户提供了简单易用的 Service Mesh 架构的支撑平台。目前， 服务网格已经广泛应用在大型金融机构。\n近日，蚂蚁集团联合 Forrester 公司发布了《蚂蚁集团服务网格总体经济影响》（以下简称白皮书）。\n白皮书基于蚂蚁集团云原生分布式架构 SOFAStack，结合客户使用的成本节省情况和业务收益，为企业上云提供新的路径方法与参考实践。\n白皮书首先系统地分析了全球企业在资产现代化、数字化等市场趋势下面临的风险与挑战，面对挑战。Forrester 提出适应未来 (Future Fit) 的技术战略模型。\n即以客户为中心，帮助企业快速重构业务结构和能力，调整运营方式，以自适应性、创造力和韧性满足未来客户和员工的需求。而平台、实践与合作伙伴将成为构建这一技术战略的关键因素。\nForrester 认为，包括容器、微服务与服务网格等领域在内的云原生平台将成为构建适应未来的现代企业的核心引擎。\nForrester 在报告中指出，在常态化混合异构环境下，面对云原生采用路径的多样化趋势与全维度挑战，企业必须将服务网格技术与微服务有效结合，才能真正释放云原生技术的红利。\n具体而言，企业技术决策者与实践者应当积极拥抱服务网格技术，并致力于在以下四个方面实现异构分布式环境下的策略化、平台化赋能：可观测性、微服务治理、灰度发布与部署、微服务框架可管理性。\n 可观测性 通过服务网格，Sidecar 代理可以主动观测相关微服务的调用关系，并将链路信息进行统一日志记录。而企业级的服务网格监控工具，应当可以对服务网格产生的遥测数据进行分析与关联。为企业开发与运维团队提供可视化的链路拓扑、实时的监控报告、基于策略的告警，以及分布式追踪与故障定位能力。\n 微服务治理微服务 主要治理能力还包括服务发现、流量治理、安全通信和应用弹性伸缩。服务网格通过基于策略的运行状况检查、动态路由、自动重试、服务熔断、服务降级、服务限流等机制提升微服务运行时的可配置性与健壮性，从而显著简化异构环境下微服务治理的技术复杂性。\n 灰度发布与部署 服务网格提供对调用方与服务方透明的灰度代理开启机制和有效的回滚机制，从而实现一体化、精细化与智能化的灰度发布与部署能力。在保障业务连续性与客户体验稳定性的同时，加速客户价值交付。\n 微服务框架可管理性 借助服务网格，企业能够将服务治理能力从各类异构的微服务框架下沉到服务网格所在的基础设施层面。而微服务框架自身只需要聚焦业务核心实现和语言差异性，从而实现微服务框架在服务治理层面的轻量化。\n面对技术发展和市场需求，蚂蚁集团在近十多年五代架构的演进过程中，经过充分的迭代和验证，逐渐沉淀出了一套金融级分布式架构 SOFAStack。\n其中的服务网格产品 SOFA Mesh 是基于 Istio 开源项目研发的企业级云原生网络通信方案，为分布式应用提供流量管理、安全加密、可观察性、服务治理等能力，实现灰度发布、蓝绿部署、滚动升级，助力企业数字化转型。\n蚂蚁集团数字科技事业部产品总监马振雄认为，相比于其他上云方式，Service Mesh 能够实现跨平台、跨协议，并且业务代码无侵入改造。从而快速地将应用植入 Sidecar 完成 Mesh 化，获得分布式红利、安全可观测，并且整个架构平滑演进。企业在架构升级过程中可以按部就班、循序渐进，并且实现端到端的安全可信以及全链路可观测能力。\n蚂蚁集团客户的访谈提到，Forrester 发现无论是传统金融机构还是互联网金融机构，都面临在混合架构下存在的共性挑战，包括基础设施升级换代、应用开发升级、云上云下交互等方方面面。\nForrester 表示，对于金融机构而言，网格服务在单体应用改造成本、云原生环境开发人员效率提升、运维安全管理效率提升以及替代旧有系统等方面能实现明显的降本增效。通过研究三年数据测算，使用蚂蚁服务网格产品后，其客户的投资回报率达到 99%。\n以某资产总额超一万亿的省级农信为例。\n随着金融科技的迅速发展，该银行积极加速数字化转型。在转型过程中，遇到了异构系统难以统一治理，技术栈绑定等一系列问题。蚂蚁集团 SOFA Mesh 帮助该用户：\n构建全行级通信网络，异构系统服务治理， 低成本云原生落地，实现无侵入平滑上云，无需修改业务代码，无需考虑依赖关系；\n同时支持架构灵活演进，兼容 ESB 等传统异构系统，帮助客户最大化上云价值。\n此外，SOFA Mesh 还能够实现以下重要的非量化重要收益：\n 统一监控能力 SOFA Mesh 能够实现传统技术栈和云原生环境的统一监控，提升问题定位效率。\n 精准故障定位 对于已完成了微服务化改造的服务云原生环境来说，服务网格提供了强大的流量管控能力，通过调用链精准定位故障。\n 故障复盘资源消耗节省 对于监管要求极高的金融企业，在故障出现后要进行全面复盘，以确保系统未来的可用性，避免类似事故发生。但复盘也消耗大量开发运维人员的时间，对工作效率产生影响。\n 组件能力提升 解耦后的微服务的公共组件、业务组件、及安全组件都得以实现性能上的提升。\n未来，蚂蚁集团希望和更多合作伙伴一起，借助 SOFAStack 以及服务网格的成功实践经验，让更多企业用户低成本上云，迈向数字化云原生的新时代。\nSOFAStack 社区为了能提供更好更优质的内容来满足大家的需求、口味\n特别设计了本次的问卷，大概占用您 2 分钟的时间～\n我们会选取 5 份认真回答的问卷送出SOFAStack 社区的 2022 限量新年礼物\n快扫描二维码一起写问卷吧～\nhttps://www.wjx.cn/vj/rXjIC9b.aspx\n本周推荐阅读 「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\nService Mesh 双十一后的探索和思考(下)\n","date":1609743600,"description":"服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书","dir":"blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9fdc287491ed68fe45196c70d88a67c9","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","publishdate":"2021-01-04T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","summary":"Forrester 认为： 包括容器、微服务与服务网格等领域在内的云原生平台，将成为构建适应未来的现代企业的核心引擎。 在常态化混合异构环境下，面对云原生应用路径","tags":["SOFAStack"],"title":"服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书","type":"blog","url":"/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","wordcount":2531},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News  SOFA 社群元旦快乐！新的一年我们也要在一起哦！\n同时，也有一个好消息要和大家共享： MOSN 荣获 「2020 年中国优秀开源项目」，感谢所有开发者们的支持和喜爱，MOSN 团队会继续努力，提供更好的开源产品和服务，也期待大家的持续共建。\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@苏榴结 提问：\n 对于某个全局事务来说，向 tc 注册说你是 tm 也是 rm，但因为这个全局事务已经有了 tm，所以它就会被认定为rm 是吗？\n A :服务起来的时候就跟 TC 说了你可以做 TM ，也可以做 RM (分别建立一个长连接与 TC 通信)，然后在需要进行某个全局事务的时候，如果他是发起全局事务的那个，那么他就发挥了他 TM 那部分职能，如果他是负责操作数据库，那他就发挥了 RM 那部分的职能。\n2、@刘亚飞 提问：\n 为什么图 1 中描述用协程池来处理可读 conn，图 2 中，又说每一个 conn 有一个读协程呢？是因为图 1 描述的是 rawpoll 模型下的代码方式，而图 2 是 goroutine-per-connection 模式下的一个 write goroutine 池化吗？\n 图1\n图2\nA：图 1 图 2 属于两种模型。Rawpoll 模型的话就是自己做 epoll_wait，有可读事件从协程池拿一个协程来读取数据；协程模型的话就是一个连接一个协程，标准的 go 编码模式，runtime 来处理 epoll_wait，可配置选择不同模式。\n本周推荐阅读 云原生网络代理 MOSN 的进化之路 基于 MOSN 和 Istio Service Mesh 的服务治理实践 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 SOFA项目进展 本周发布详情如下：\n1、SOFA-Common-Tools 发布 1.3.1 版本：\n 修复多 classloader 场景下 commons-logging 的兼容性 修复 SOFAThreadPoolExecutor 被删除的方法，提高向下兼容性 详细参考: https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.1\n2、SOFA-Ark 发布 1.1.6 版本：\n 支持插件扩展，通过宿主动态扩展指定 plugin 依赖和导出关系 SOFA-Ark-manve-plugin 支持打包按规则排除依赖（from file） 详细参考： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.6\n","date":1609398000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201231/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ca60ed7c9ac011477c8861c0f5650629","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201231/","publishdate":"2020-12-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201231/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA 社区元旦快乐，MOSN 荣获 2020 中国优秀开源项目","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201231/","wordcount":994},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@薛帅领 提问：\n 多数据源切换后，增加事务但不起作用（切数据源是执行方法后才切换的），本地事务及 Seate 分布式事务也不行，这个有什么好的解决方案吗？\n A：Spring 本地事务注解本身就不支持多数据源事务，且如果你开启了本地事务，之后并不会进入你的切换数据源的切面。 在多数据源下，去掉本地事务注解就好了。用 globaltransactional 注解在多数据源的入口加上，多个数据源都被 Seata 代理的话，就会保证多数据源的事务。\n2、@李天宇 提问\n 如果在分布式事务中，另一个线程做批处理 update 之类的，是否会锁住呢?\n A：不会，另一个线程也要记得加上 globaltransactional 注解就行了。在 a 线程要提交之前要去尝试拿到它修改数据的全局锁的，如果 a 拿到了，但是还没到二阶段提交，b 也是要去尝试拿，拿不到就会不执行 SQL，等待全局锁释放了，也就是 a 发起的事务结束了，b 才能执行 SQL 提交。这样就保证了利用全局锁（粒度行级），来达到隔离性。\nSeata：https://github.com/seata/seata\n相关推荐阅读 Kubernetes: 微内核的分布式操作系统 走出微服务误区：避免从单体到分布式单体\n 网商银行是如何建设金融级云原生分布式架构的？\n 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构\n SOFA 项目进展 本周发布详情如下：\nSOFA-Common-Tools 发布1.3.0 版本，主要变更如下：\n SOFA 线程池支持 ScheduledThreadPoolExecutor 与 ThreadPoolTaskScheduler 新增 SofaConfigs 支持统一的配置获取 新增 LogCode2Description 支持统一的错误码获取 重构线程池实现，支持更丰富的监控数据 所有组件统一 spce 属性获取逻辑 修复配置日志输出到控制台时不生效的问题 详细参考：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.0\n祝大家圣诞节快乐！\n","date":1608879600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201225/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"59bc2ae2a6b06f7ca356aeb61a6c78fd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201225/","publishdate":"2020-12-25T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201225/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA-Common-Tools 发布新版本， QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201225/","wordcount":963},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@缪文 提问:\n SOFA-Boot 框架，模块隔离时，子 module 中引入 mybatis 框架，@MapperScan 注解是在RootContext 中扫描，还是在子 module 中扫描？\n A: 非 auto 的 configuration 都是在对应模块进行解析的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n2、@李扬 提问：\n 分支事务被回滚是同步还是异步的,如果是异步的,能加监听方法吗?\n A：可以实现 transactionhook 这个类，然后在 tm 发起者里加入到 Transaction HookManager#registerHook 。这样在二阶段决议后，可以做一些小动作，比如二阶段提交的时候，再执行 redis ，mongo 的数据插入。\n3、@吴国柱 提问：\n 本地事务与全局事务一起开启会有问题吗？\n A：全局事务要在本地事务的外层,就是包裹本地事务，不能由本地事务包裹全局事务。本地事务出异常都不会进行注册，也就代表本地事务如果出问题本地事务自行会回滚(基础知识)，如果本地事务提交了，其它服务的本地事务出现异常，或者业务代码出现异常，将有 Seata来负责把已提交的事务回滚。\nSeata：https://github.com/seata/seata\nSOFAChannel 部分合辑 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 蚂蚁集团分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁集团分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 相关推荐阅读 剖析 | 详谈 SOFABoot 模块化原理 蚂蚁集团研发框架日志隔离解析 | SOFABoot 框架剖析 蚂蚁集团研发框架总览 | SOFABoot 框架剖析 ","date":1608274800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201218/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"712d560758c60f16cc7d2651bb781e65","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201218/","publishdate":"2020-12-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201218/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 线上直播合辑整理，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201218/","wordcount":949},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 【12/07 - 12/11】每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@bruce 提问：\n SOFAJRaft 可以实现在三个节点中选出一个 leader , 其他逻辑由自己实现吗?\n A：可以，可以不用状态机，也不用加载和持久化快照, 只需要选个 leader。 \u0026amp;gt; 各个节点如何知道自己是主还是从?\nA：示例 2、@李明 提问:\n 全局事务执行过程中，有其他线程操作数据库，这时全局事务执行失败，在回滚的时校验数据发现数据被修改过，导致回滚失败，这种情况怎么避免?\n A：其他线程也加上 global transactional 注解。分布式事务下，没有单个分支是独立的个体存在，需要拿到全局事务中，让其他事务知晓他的存在，从而避免在分布式调用链路中，恰好遇到同一个数据进行修改时，发生的脏写脏读 globallock 是在更新前去 tc 看下这个时候这个数据有没有被其他事务锁定，没有的话就说明这个数据没有被其他事务使用，是提交的数据，所以这叫读分布式事务下的已提交。 但是他并没有去注册分支，也就是他没有去占有这个全局锁，来达到分布式事务下的排他性。他在得到 tc 响应的时候，去执行 update 是有时间的，此时有个分布式事务下的分支 update 后，拿到了全局锁，然后他的链路二阶段是回滚 ，但是数据就被你这个认为没有全局锁的本地线程给改了，这就导致被干扰无法回滚。 所以 globallock 需要配合 sql 语句，在 update 前，先做 for update 这个数据，拿到这个数据的本地锁，拿到本地锁之后，再去 tc 判断有没有全局锁，如果 tc 没有锁，因为本地已经拿到本地锁了，具有本地事务的排他性，其他分支事务拿不到该数据的本地锁，是无法去注册分支去拿到全局锁，也就是禁止了其他分支事务的干扰，所以不会脏写。 目前 tcc 下一般就是 globallock+select for update 来防止被其他 at 事务改动后，进行了脏写。\n3、@ 尚攀 提问:\n Raft 是为了解决目前的什么问题？\n A: 依赖外部存储。AT 有 before 镜像、after 镜像，after 镜像是在 undo_log 表里存储，那么 before 在哪里存着了？未来的 Raft 模式，集群支持动态扩缩容，事务信息存储在内存中（测试下来比 redis 快），现在的全局事务信息，分支事务信息，全局锁都是持久化到 db，或者 redis 去的。如果这个时候持久化用的 db 宕机了，Seata-Server会不可用，而集成了 Raft ，leader 宕机后自动选举新 leader，继续运转。所以，利用 raft 一致性算法，可以让多个Seata集群内存中的数据保持一致。\n相关推荐阅读 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑\n 蚂蚁集团生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理\n 蚂蚁集团 SOFAJRaft 优先级选举剖析 | 特性解析\n 剖析 | 蚂蚁集团生产级 Raft 算法 SOFAJRaft 合辑\n Seata 项目进展 本周发布详情如下： 发布 Seata 1.4.0 版本，主要变更如下：\n 支持 yml 配置文件 支持 Oracle nclob 类型 支持客户端最少的活动负载均衡 支持客户端一致性哈希的负载均衡 支持 Spring Boot 使用自定义配置中心和注册中心 支持配置默认全局事务超时时间 多处 BUG 修复和功能优化 详细参考：https://github.com/seata/seata/releases/tag/v1.4.0\n","date":1607670000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201211/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dc10639aea7c443d918ac8f8355ed64c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201211/","publishdate":"2020-12-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201211/","summary":"SOFA WEEKLY | 【12/07 - 12/11】每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是","tags":["SOFA Weekly"],"title":"SOFA Weekly | Seata 发布新版本， QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201211/","wordcount":1418},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@刘江涛 提问： \u0026amp;gt; 已知在同一个分布式事务中，各个 RM 的模式都应该与对应 TM 模式相同。那同一个微服务可以多种模式并存吗？比如 AT , XA , Saga 并存，然后 A 业务使用 AT 模式，B 业务使用其他模式之类的。\nA：不可以，隔离性无法得到保证。如果要一起用，就要保证一条调用链路中所有数据的隔离性，也就是跟 AT 一样都得去竞争锁，而且 Saga，TCC 之类的对 SQL 没要求，可能在跟 AT 一起使用的时候就有要求了，得不偿失。\n 如果公司要引入多种模式的话，微服务之间的关系是这样的吗？\n A ：是的，当然 AT 集群是可以调 Saga 集群的，但是他们不能属于同一个全局事务,也就是 AT 那个事务提交了，Saga 的如果回滚了，是 Saga 集群的问题，等于有 2 个全局事务的诞生。 Seata：https://github.com/seata/seata\n相关推荐阅读 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化\n 云原生网络代理 MOSN 透明劫持技术解读 | 开源\n 基于 MOSN 和 Istio Service Mesh 的服务治理实践\n 云原生网络代理 MOSN 的进化之路\n MOSN 项目进展 本周发布详情如下： 1、MOSN 发布了 v0.19.0 版本： - 重构了 StreamFilter 框架，提供更强的可复用的能力 - 支持 MaxProcs 可基于 CPU 使用限制自动识别的能力 - 支持指定 Istio cluster 的网络 - 针对高并发场景的内存使用进行了优化 - 多处BUG修复\n详细参考：https://github.com/mosn/mosn/releases/tag/v0.19.0\n","date":1607065200,"description":"SOFA WEEKLY | 【11/30 - 12/04】每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201204/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4123f0805fdf3799cbafcc143f8d6bac","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201204/","publishdate":"2020-12-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201204/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本、 Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201204/","wordcount":843},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech\n SOFAStack：https://github.com/sofastack\n 社区 Big News  SOFAStack 获得 2020 年度 OSC 中国开源项目评选「优秀 Gitee 组织」，感谢所有开发者们的支持和喜爱，SOFA 团队会继续努力，提供更好的开源产品和服务，也期待大家的持续共建。 2020 年度 OSC 中国开源项目评选结果公布\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张松 提问： \u0026amp;gt; SOFARPC 支持提供者注册的时候配置一个标识，然后消费者根据这个标识来获取到对应的服务提供者吗？类似于对服务提供者做一个分组。\nA：你是指 SOFARPC 的 unique-id 吧，支持的。 \u0026amp;gt; 不是，类似于分组的配置，因为我这边现在需要多环境，要来区分同一个注册中心下的同一个接口的不同分组。\nA：SOFARPC 就是用 uniqueId 来区分同一个接口，不同实现的。SOFARPC 没有 group 的概念，只有一个 uniqueId，需要服务方和调用方配置一样，强隔离的。 SOFARPC：https://github.com/sofastack/sofa-rpc\n2、@徐泽唯 提问： \u0026amp;gt; 自动降级以后如果调用的服务抛错了 数据是不是就不对了？\nA：自动降级只是发起者那边发现 SeataServer 不可用后，不去走 begin 。你业务数据就完全没全局事务的允许运行，是会出现数据不一致。比如seata-server宕机了，后续的服务因为 Seata-Server 宕机，不走分布式事务，此时全局事务有部分数据是需要回滚的，但是由于Seata-Server宕机了，导致没法回滚，这个时候不经过全局事务的事务执行就会导致数据不一致。所以说，tc 最好集群搭建，以免宕机后，降级代表了你允许 at 模式下数据不一致。 Seata：https://github.com/seata/seata\n相关推荐阅读 蚂蚁金服微服务实践 | 开源中国年终盛典分享实录 火了 2 年的服务网格究竟给微服务带来了什么？ 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下： 1、SOFAJRaft 发布了 1.3.5 版本： - 增加对IPv6的支持＃526 ＃527 - 升级\u0026amp;rsquo;rocksdb\u0026amp;rsquo;到5.18.4以支持AArch64\n- 优化：心跳响应不经过管道直接发送，避免管道影响心跳响应的及时性 详细参考：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.5 2、SOFABoot 发布 3.4.6 版本: - 支持手动 readiness 回调（健康检查二阶段） - 扩展点失败反馈健康检查，默认为否 - 提供上下文隔离场景下获取所有 Spring 上下文的标准方法 - Bean 加载时间和层级树形分层显示\n详细参考：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.6\n","date":1606460400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201127/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f379c4483cff2807f5cfe8c6bbab5d8c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201127/","publishdate":"2020-11-27T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201127/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/23 - 11/27】SOFA Weekly | SOFAJRaft 、SOFABoot发布新版本，SOFAStack 获优秀 Gitee 组织奖","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201127/","wordcount":1352},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech\n SOFAStack：https://github.com/sofastack\n 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@小刘 提问： \u0026amp;gt; 刚开始用 Seata ，方法上用了 @GlobalTrasactional + mybatis 插入一条数据的时候返回的自增id不正确,取消@GlobalTrasactional用普通的事务@Trasactiona 插入数据的时候返回的自增 id 正常了。\nA: 这个基础是有问题的。全局锁的作用是锁定并发修改时的数据的，不是针对接口。接口并发肯定是多线程走的，不可能阻塞等待排队。 Seata：https://github.com/seata/seata\n2、@初识 提问： \u0026amp;gt; 防悬挂是怎么理解的？能简单说说吗？\nA: 保证一致性，幂等用的。比如a-\u0026amp;gt;b，因为特殊原因，比如全局事务超时，b注册上了分支事务，本地事务的 commit 还没执行的时候，全局事务回滚下发到了，如果这个时候本地事务 commit 了，那么数据就不一致了，所以全局事务回滚下发到了，会插入一个 undolog ，让本地事务 commit 的时候因为 undolog 唯一索引冲突使本地事务提交失败，触发回滚，保证了当全局事务状态是回滚时，分支事务都是回滚的。 当然，如果是 commit 了，再收到下发回滚，因为 commit 了已经有 undolog了，那么会通过 undolog 回滚，这个针对的是没有 undolog 时的情况。\n**3、@StevenCheney **提问： \u0026amp;gt; Nmosn 的版本 和 Istio 有对应关系吗？\nA：目前的 Master 支持 1.5._，但是上次看1.5._的时候有一些注入的问题，你可以看一下 feature-istio_adapter 这个分支，最近应该会合并一些pr进来，到时候可以直接适配1.7._，理论上1.6._也是可以支持的，需要测试一下。 \u0026amp;gt; Docker image 会同步更新吗？\nA：主要是看你的需求，如果你是只要 MOSN ，不要 Envoy，就直接使用https://github.com/istio/istio/issues/23753 这个来打包，如果你都需要的话或者说不介意多一个 Envoy，就直接使用 proxyv2 打一个就好了。 MOSN：https://github.com/mosn/mosn\n本周推荐阅读 蚂蚁智能运维：单指标异常检测算法初探 蚂蚁宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 企业数字化转型指南，《SOFAStack 解决方案白皮书》正式发布 SOFA 项目进展** 本周发布详情如下： 1、SOFA-Common-Tools 发布1.2.1版本：\n 重构了本地控制台输出日志逻辑； 移除了 log-sofa-boot-starter 相关代码； 详细参考： https://github.com/sofastack/sofa-common-tools/releases/tag/v1.2.1\n","date":1605855600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201120/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a81d6649eb11649a90e54eef8a5a57e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201120/","publishdate":"2020-11-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201120/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/16 - 11/20】SOFA-Common-Tools 项目发布新版本、Seata、MOSN 相关 QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201120/","wordcount":1234},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@杨文鹏 提问：\n 感觉 SOFAArk 在静态合并部署情况下,和 SOFABoot 的类隔离起到的作用是一样的？不知道我理解对不对。\n A：SOFABoot 没类隔离，它的类隔离就是继续 SOFAArk。 \u0026amp;gt; 比如新建一个 SOFABoot 应用，需要再手动集成 SOFAArk 吗？\nA：需要的。\n SOFABoot：https://github.com/sofastack/sofa-boot SOFAArk：https://github.com/sofastack/sofa-ark 2、@倪绍东 提问：\n 如果是提交阶段有数据库失败了，其他成功的怎么办呢，没办法了吧？\n A：一阶段提交,二阶段不可能提交的情况下还失败，XA 本地事务一阶段持久化在数据库层面不可能丢失，本地事务undolog跟redolog了解一下。对 Seata-server 来说保存了事务状态，如果二阶段有节点执行失败，就重试，直到成功。也就是你节点二阶段执行失败，自己了解下为什么你数据库出问题了，而不是分布式事务有什么问题。 \u0026amp;gt; 会不会出现重试过程中，其他事务修改了现有数据，而最终又被重试成功的情况?\n A：二阶段提交代表了什么？代表了整个调用链是成功的，一个成功的分布式事务，一阶段已经持久化了，你再去改，这个数据又不是脏的有什么问题？XA 来说，本地事务的本地锁先了解一下，一阶段不提了，锁被本地持有，如何修改？本地排它锁都没释放，何来脏写。\n3、@李艺渊 提问：\n Seata TCC 模式下，订单微服务和库存微服务。订单微服务try阶段添加订单信息，现阶段可以支持在库存微服务try阶段获取订单信息吗？或者说能把创建好的订单信息存储到 Seata-server ，然后在其他微服务可以获取到吗？\n  A：我理解 Server只负责全局事务的流转，try 出错就 cancel ，成功就 commit。Try 里面对两个库操作，正常是可以拿到数据吧。 \u0026amp;gt; 这2个微服务是分开部署的，数据库也是分开的。像订单微服务的 try 阶段，把订单信息存储到 order 数据库了。那库存微服务是不会去访问 order 数据库的。现在就是看库存微服务如何获取到新增的订单信息，看有没有什么 好的方式。\n Seata：https://github.com/seata/seata Service Mesh 相关推荐阅读 Service Mesh 中的可观察性实践 陌陌的 Service Mesh 探索与实践 - 直播回顾 Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 Apache SkyWalking 在 Service Mesh 中的可观察性应用 ","date":1605254400,"description":"【11/9-11/13】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201113/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"59cb50e2977d5e0b3ad675ca234c2b0f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201113/","publishdate":"2020-11-13T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201113/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 相关阅读合集、SOFABoot 以及 Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201113/","wordcount":1270},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、《Service Mesh Webinar#4:阿里云 CDN 微服务架构演进之路》直播回顾以及 QA 整理 视频回顾地址：https://www.bilibili.com/video/BV13D4y1R7do/\n@道酉 提问： \u0026amp;gt; 请问阿里云 MOSN 两个容器的热更新怎么实现的，就是怎么在pod内添加一个容器再去掉一个\nA：我们其实也没用跨容器热升级的方式，两个 Pod 挂载相同目录的方式是支持的。\n@陈鹏 提问：\n 请问一下同一个容器的热升级是怎么做的呢？\n A：我们是通过 RPM 升级的方式，容器内 systemd 管理的进程。\n@梁昌泰 提问：\n 重启不叫热升级吧？\n A：没有重启哈，直接起来一个新的进程。\n2、@谢子华 提问：\n Seata Saga 中，TC 的作用是什么？在 Saga 执行过程中 TM、TC、RM 和状态机的交互过程是怎样的？\n A：1）发起重试。2）根据分支响应状态，判断是否切换重试方向。目前，Sage 的分支默认情况下不会注册到 TC 了的，因为 Saga 本地库里有各 RM 的数据。 只有全局事务注册和全局事务提交或回滚时，与 TC 交互。\n 现在二阶段重试失败不断发起重试在 1.4.0 版本解决了吗？判断是否切换重试方向是只有可能 TC 会决定向后或者向前重试？\n A：是由 RM 端返回的状态为依据，由 TC 端切换重试方向，决定权在 RM 端。\n 我的理解是 RM 告诉 TC 回滚失败，然后有可回滚和不可回滚两个状态，TC 根据这个决定是否继续重试？那如何在 RM 进行配置？\n A：我刚才的截图是 TC 端发起全局提交时，RM 返回“回滚”失败重试回滚，这种情况，默认情况下不存在了，因为 Saga 不会注册分支到 TC。 实际上，应该是在 SagaCore 的全局回滚时，RM 端如果返回“提交”失败，重试提交状态时，会切换到向前重试。\n看了下源码，只有全局事务是因超时而进入全局回滚时，才会切换重试方向。\n 切换重试方向是指本来流程图配置是向后重试，然后超时了，TC 会切换为向前重试？\n A：意思是全局事务正在运行时，因超时60秒，TC 端自动将全局事务标记为超时回滚状态，然后会异步发起全局回滚请求。 这种情况下，碰到回滚失败时，会切换为向前重试。\n 哦哦，原来是这个样子。默认情况下，本地只会把全局的 RM，状态发送给 TC?\n A：默认情况下，RM 的数据只会存在本地。TC 端可以说是不管 Saga 分支的情况的。TC 只管接收 1）TM 的开始全局事务、完成全局事务；2）超时进入全局回滚；3）根据状态判断是否继续重试，还是切换重试方向。\n 1)是 TM 监测到所有 RM 都已完成然后告诉 TC 全局事务结束？3)TC 根据状态判断是否重试，现在 RM 不把状态发送给 TC，那这个状态是从哪里来?\n A：1）是的。 3）这个请求是从 TC 向 RM 端发起的。RM 只是返回一个状态而已。\n 我在实践中的问题就是在二阶段执行出现异常会不断地重试，如之前跟你聊过的补偿触发后补偿服务执行异常会不断重试。上述 TC 发起的全局回滚如果回滚过程中出现异常是不是也会不断地重试？不断地重试感觉比较占用资源？是否有应对策略让他能够只是有限次重试？\n A：重试策略的 PR 已经有了，但是因为 PR 依赖关系较多，暂时还没有合并，后续我会精简 PR 代码，单单引入重试策略的功能及其配置的功能。到时候会能够配置重试策略。目前，基本上是1秒钟就会发起一次重试。\n 现在没有重试策略的情况下，是否有其他的应对方法？\n A：将重试时间间隔配置稍微大一些，默认1秒。\n本周推荐阅读 云原生网络代理 MOSN 的进化之路 基于 MOSN 和 Istio Service Mesh 的服务治理实践 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 云原生网络代理 MOSN 平滑升级原理解析 | 开源 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.18.0 版本，主要变更如下：\n 新增 MOSN 配置文件扩展机制； 新增 MOSN 配置工具，提升用户配置体验； 优化 HTTP 协议处理对内存的占用； TLS 模块优化，增加了客户端降级配置逻辑、降低了 TLS 内存占用； 支持大于 4M 的 XDS 消息； 部分 API 接口进行了重构； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.18.0\n2、发布 Seata v1.4.0 版本，主要变更如下：\n 支持 yml 配置文件； 支持 Oracle nclob 类型； 支持客户端最少的活动负载均衡； 支持客户端一致性哈希的负载均衡； 支持 Spring Boot 使用自定义配置中心和注册中心； 支持 Apollo 密钥 key 配置； 修复禁止执行更新主键值的 SQL； 重构 Redis 存储模式下 session 的存储结构； 详细发布报告： https://github.com/seata/seata/releases/tag/v1.4.0\n","date":1604646000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201106/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dc199415476133ea6f6ee6adf2bf91fa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201106/","publishdate":"2020-11-06T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201106/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、Seata 发布新版本、MOSN 相关阅读整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201106/","wordcount":2032},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@王钢 提问： \u0026amp;gt; https://github.com/sofastack-guides/kc-sofastack-dynamic-demo/issues/11 基于 SOFAArk 和 SOFADashboard 实现动态模块管控时遇到宿主应用能够下载biz安装成功，但是不能在zookeeper下生成对应的/apps/biz节点，导致管理端不能更新状态，不知道应该怎么排查解决。使用的 ZK 版本是 3.4.10。\nA：可以 debug 下写 /apps/biz 的逻辑，这里是不是宿主客户端没有连接上来，具体可以看一下：https://github.com/sofastack/sofa-dashboard-client SOFADashboard 之前只做了一个简单的模型，后面陆续其他同学也在上面做了一些开发，如果有兴趣可以一起参与共建哈。\nSOFADashboard：https://github.com/sofastack/sofa-dashboard\n2、@钟文豪 提问： \u0026amp;gt; SOFAJRaft 是如何计算 commitIndex 的呢？\nA：可以看看这个文档：https://www.sofastack.tech/projects/sofa-jraft/raft-introduction/\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@张潇 提问： \u0026amp;gt; 各位好 问个概念的问题。我三个服务 A,B,C，在 A 服务方法加了 @GlobalTransactional，调用 B ，C。启动三个服务的时候看 Seata 日志 ,A,B,C 服务每一个都是 RM 也是 TM。是这样的吗？不是 A 服务才是 TM 吗？\nA：在你这个事务当中，A 是对应着 TM，B、C 对应着 RM。 但是在注册的时候，他们都同时向 seata-server 注册了 TM 和 RM，意味着他们可以作为 TM，也可以作为 RM。 比如你有一个全局事务从 B 发起的，那这个时候他就是 TM。如果你认为你的业务场景中 B、C 这两个服务不会作为 TM 存在，你也可以把 TM 相关的配置删了，然后他就不会去注册 TM 了。可以从定义上去看 TM 和 RM，会发起全局事务的就是 TM，对应着数据库资源的就是 RM。一个服务可能只是 TM，也可能只是 RM，也可能都是。\nSeata：https://github.com/seata/seata\n本周推荐阅读 网商银行是如何建设金融级云原生分布式架构的？ 开源项目是如何让这个世界更安全的？ SOFA 项目进展 本周发布详情如下：\n开源 MOSN Golang 系统诊断工具 holmes beta 版：\n 支持基于 goroutine 波动的自动 goroutine profile dump； 支持基于 RSS 统计的 heap profile dump； 支持基于 CPU 使用率的自动 cpu profile dump； 详细参考： https://github.com/mosn/holmes/blob/master/readme.md\nSOFA 直播预告 传统 CDN 节点内组件间通信通过 IP 分组渲染的方式实现，当更多参差不齐的异构节点资源出现的时候则不再能很好地满足我们的需求。\n本期主要分享阿里云将传统的 CDN 节点改造成微服务架构的落地过程，主要使用了蚂蚁 SOFAStack–Service Mesh 的数据面 MOSN，主要分为两个阶段，第一个阶段是由传统 CDN 节点到数据面先行的微服务架构，通过数据面 MOSN+coredns 实现服务发现；第二个阶段是由数据面先行到数据面+控制面的标准 Service Mesh 架构。根据我们的落地和改造经验，介绍基于 MOSN+coredns/Istio 的 Service Mesh 架构改造的实际案例。上期分享了《Service Mesh 在 CDN 边缘场景的落地实践》，大家也可以温故一下～ 视频回顾地址：https://tech.antfin.com/community/live/1289\n分享主题：《Service Mesh Webinar#4:阿里云 CDN 节点微服务架构演进之路》\n分享嘉宾：邓茜（花名沐沂），阿里云高级开发工程师\n听众收获：\n 了解边缘场景下，使用 Service Mesh 架构的好处； 了解如何利用 MOSN + coredns 实现简单的服务发现； 了解如何利用 MOSN+ Istio 配置 http/tcp/udp 的转发规则以及如何动态配置持久化； 线上直播时间：2020 年 11 月 4 日（周三）20:00-21:00\n欢迎报名：点击“这里”，即可报名。\n","date":1604041200,"description":"【10/26-10/30】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201030/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a67a4e194b658ba2f0427011c0b56dba","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201030/","publishdate":"2020-10-30T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201030/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 项目更新及直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201030/","wordcount":1772},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@廖虹剑 提问：\n 我们想扩展一下 Dubbo 的 thrift 协议，遇到一个问题，consumer -\u0026amp;gt; mosn-client -\u0026amp;gt; provider，现在请求可以正常 decode -\u0026amp;gt; encode 到达 provider，并且 provider 可以正常调用，在返回的时候，数据包已经发回 MOSN，并且成功 decode，但是会阻塞在 read 处直到超时，没办法 write 回 consumer。 请问有什么排查思路吗？MOSN 里面这个网络模型看得有点晕。\n A：先 read 再 decode 的呀，你说的阻塞在 read 是阻塞在哪？\n read 方法已经正常调用，并且 decode了，但是没有触发写事件，consumer端 会一直在等待。 然后又会到这里卡住直到超时 A：数据 read 了没有新数据，这里就是会超时啊。你要看 decode 之后做了什么。\n 我打断点看到的 remote ip 和端口是 provider 端的。或者我换一个问法，MOSN 在获取到 upstream 的响应数据并且 decode 之后，是如何怎么触发 encodeResponse 并写回 writebuffer 的。我调试发现它 read 完数据之后无法进入到 endStream 方法。 也没看到什么异常日志。 我对 go 还不是特别了解，如果有什么问题还请多指正，辛苦了。\n A：你从 Decode 的逻辑往下跟一下就可以了，Dubbo 目前是 xprotocol 协议的实现 Decode 以后会经过 proxy 的流程最后再 encode，然后 write。read 是异步的，这个有点简单的介绍： https://mosn.io/blog/code/mosn-eventloop/\n 找到问题了，是 encode 的时候 replace requestId 的时候出了点问题，导致找不到对应的 stream，感谢~\n MOSN：https://github.com/mosn/mosn\n2、@Bernie G 提问：\n 我这边项目是 Spring Boot，没有用 Dubbo， 这种情况可以用 Seata 做 Saga 事务吗？\n A：你的服务调用是通过 feign，resttemplate？Saga 跟 RPC 框架不是强绑定的，你的远程服务可用在被调用方作为类似 reference bean 的形式调用就可以。\n 我们这边主要用的是 RestfulApi 还有 gRPC 来作为微服务之间的调用， Seata 能支持吗？ 如果能给个代码 Sample 最好。\n A：Test 中有 gRPC 的实例，看下是否满足需求。 https://github.com/seata/seata/tree/develop/integration/grpc\nSeata：https://github.com/seata/seata\n本周推荐阅读 开源项目是如何让这个世界更安全的？ Hey，邀请你加入我们一起玩耍 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.4.5 版本，主要变更如下：\n 支持 triple 线程监控； 升级 sofa-ark 版本至 1.1.5； 升级 junit 版本至 4.13.1； 修复 jvm filter npe 问题； 修复http server 线程池配置问题； 详细发布报告： https://github.com/sofastack/sofa-boot/releases/tag/v3.4.5\n2、发布 SOFAArk v1.1.5 版本，主要变更如下：\n 修复 web 模块并发安装问题； 修复支持 web 环境测试 webContext 默认为 null 导致的 NPE 问题； 详细发布报告： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.5\nSOFA 直播预告 在边缘计算和 5G 商业化风起云涌的当下，阿里云 CDN 开展了节点全面云原生化的改造，在此背景下，我们尝试利用 CDN 资源池为底座，在大规模复杂边缘场景下建设 Service Mesh 的基础能力，打造边缘 PaaS 平台。落地实践过程中我们使用了蚂蚁 SOFAStack–Service Mesh 体系中的 MOSN 作为数据面，Istio 作为控制面。本次分享将从 Service Mesh 技术以及 CDN 边缘场景介绍入手，重点分析 Istio 和 MOSN 结合的落地实战过程。\n分享主题：《Service Mesh Webinar#3：Service Mesh 在 CDN 边缘场景的落地实践》\n分享嘉宾：肖源（花名萧源），阿里云技术专家\n听众收获：\n 了解 Service Mesh 技术； 了解 Service Mesh 在阿里云 CDN 边缘场景的落地实践； 给到想要落地 Service Mesh 的同学一些案例与建议； 线上直播时间：2020 年 10 月 28 日（周三）20:00-21:00\n欢迎报名：点击“这里”，即可报名。\n","date":1603436400,"description":"【10/19-10/23】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201023/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cf0c4a06a60155202353fe19c3185072","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201023/","publishdate":"2020-10-23T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201023/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAArk、SOFABoot 发版、10月28日线上直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201023/","wordcount":1640},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谢子华 提问：\n SOFARPC 客户端A调用服务端 B，B在方法中想异步调用C（不同步等结果），在callback里面才响应结果返回给A。这种有 Demo 吗？\n A：链路异步吗？ 可直接看测试用例 https://github.com/sofastack/sofa-rpc/blob/master/test/test-integration/src/test/java/com/alipay/sofa/rpc/test/async/AsyncChainTest.java\n 谢谢，看了下用例。我理解是 服务端接口执行时在 RpcInvokeContext 设置了 SendableResponseCallback 类型的 callback。SOFA 就会忽略接口的返回值。然后在 callback 中主动调用 sendAppResponse 返回结果。对吗？\n A：对的。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@明丽 提问：\n 有没有存在经常锁表的童鞋？lock_table 里存在锁表数据和 undo_log 里面有历史几天的数据没有被删除掉？\n A：locktable 如果没删除，说明可能遇到脏数据导致分支事务无法回滚，此时就会有锁无法释放，这时候要根据 locktable 的信息去找对应的分支事务是那个应用，去看下日志提示，如果是脏数据会说镜像校验不通过\n 这里的脏数据具体是指什么样的数据？\n A：全局事务是回滚时，需要回滚的数据被改动。\n 通常报错的就是并发情况下扣减库存，操作同一条 update 库存数量语句。\n A：比如 a=1，update 后时 a=2。此时其他的分支事务异常，导致全局事务决议时回滚，这个时候 a 被改为了3，这个 a 的数据脏了，隔离性没被保证。此时回滚的时候会校验 a 还是不是当前事务修改的值，如果不是，说明这个数据脏了，已经不正确了，不能盲目的直接回滚成1，说明隔离性没保证，有数据被 Seata 全局事务外的地方修改了，如果想保证隔离性，就需要保证任何一个写场景，都被全局事务注解覆盖。\n 我们这边的更新场景都有加全局事务的注解，好像没有起作用，还有别的不起作用的情况吗？\n A：那就检查是否都覆盖了，比如定时任务，或者会不会有认为的去数据库层面直接修改。\n 另外一个问题，我在订单服务下单的时候发起扣库存请求，这个时候只需要在订单服务的方法加上全局注解就可以了，对吗？不需要在库存服务被调用的方法加注解？\n A：只要保证 xid 传递跟数据源代理即可，但是如果有订单服务之外，没有被全局事务注解覆盖的地方操作了库存，一样会脏。这个文章我借鉴了清铭、屹远、煊意的博客，总结了一下 XA 跟 AT 的关系，也谈到了隔离性方面的问题，希望你看过后可以理解 AT 的隔离性是如何保证的。 https://blog.csdn.net/qq_35721287/article/details/108982806\nSeata：https://github.com/seata/seata\n剖析 SOFAJRaft 实现原理合集 SOFAJRaft 实现原理 - 生产级 Raft 算法库存储模块剖析原理 SOFAJRaft 实现原理 - SOFAJRaft-RheaKV 是如何使用 Raft 的 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析 | SOFAJRaft 实现原理 SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.5.Alpha1 版本，主要变更如下：\n 升级 \u0026amp;lsquo;rocksdb\u0026amp;rsquo; 到 5.18.4 以支持 AArch64； 优化：心跳响应不经过 pipeline 直接发送，避免 pipeline 影响心跳响应的及时性； 修复使用 grpc 时，在一定情况下无法自动重连的问题； 修复使用 grpc 时，在 error response 处理的错误； 致谢（排名不分先后）：@cmonkey @odidev 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.5.Alpha1\nSOFA 团队欢迎你加入 蚂蚁集团招聘技术运营专家啦～欢迎加入我们一起为可信技术带来更多的想象。\n岗位名称：可信原生技术运营专家\n岗位描述：\n 挖掘技术内容和业务价值，并形成体系，构建传播矩阵，形成并提高产品和技术的行业美誉度； 完整策划并执行线上、线下的技术活动、大赛，构建围绕可信原生技术的开发者活跃群体，并有更多创造性的技术玩法，使技术可感知； 维护重点 KOL，并吸纳行业专业意见，加大行业贡献，并深化行业影响力。 岗位要求：\n 具备用户细分、市场定位、产品规划、产品包装的能力中的一项或多项； 具备良好的创新思维、有技术前瞻性； 良好的沟通协作能力，及横向驱动能力； 有线上市场推广经验，或线下活动策划经验者优先考虑； 对于云计算领域有较深入的了解，有相关工作背景者优先考虑。 欢迎简历投递至：khotyn.huangt@antgroup.com\n","date":1602831600,"description":"【10/12-10/16】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201016/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a7a2f16f7c62d777b8aff0f90a85ba7b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201016/","publishdate":"2020-10-16T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201016/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布、SOFAJRaft 源码解析文章合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201016/","wordcount":1951},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@叶翔宇 提问： \u0026amp;gt; 想请教一个问题，使用 MOSN 的过程中，我们想通过 request 的 header 中带的 version 信息来实现灰度的机制。比如：目标 service 有 3 个 host，其中一台版本1.0，其他两个版本2.0。\nA：你这个加一个 route 的判断就可以路由到不同的 cluster 了。\n 我们的是同一个 cluster 里面的不同 hosts\u0026amp;hellip;\n A：你就把不同版本的 hosts 归为不同的 cluster 就可以啦。\n2、@李样兵 提问： \u0026amp;gt; 我们现在生产环境中没有使用 K8s, 只使用 MOSN+自定义配置和注册中心，可行吗？\nA：你们是 Dubbo 么？\n 对，dubbo+http， 生产环境是 docker 还没有 K8s。\n A：你可以用这个方案，MOSN 直接连接注册中心。 https://github.com/mosn/mosn/issues/1087 MOSN：https://github.com/mosn/mosn\n线上直播 SOFAChannel 合集 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 蚂蚁金服分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 ","date":1602226800,"description":"【10/05-10/09】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201009/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a83b0d192a605f994a1379ab41578403","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201009/","publishdate":"2020-10-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201009/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN QA 整理、SOFAChannel 线上直播合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201009/","wordcount":938},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@周爽 提问： \u0026amp;gt; 我现在基于springcloud 集成 nacos,sentinel,zipkin,jpa,shardingjdbc，昨天说的做了防止重复代理，如果我是多数据源呢？后续1.3.1是配置也需要开启，代码也需要写代理吗？\nA：多数据源就关掉自动代理，自己手动\n 就在我多数据源里面加上右边的 DataSourceProxy 就可以了吗？ @Primary 这个只需DataSource1Config加上，DataSource2Config是否需要加呢？\n A：代理这个 reresult；\n AT 和 XA 1.3版本可以理解为代码“使用”上就一个 new poxy 不同吗？\n A：一个是 new DataSourceProxy，一个是 new DataSourceXAProxy\n Seata “实现”一个是二阶，一个是基于 XA 事务规范？\n A：都是二阶段，一个模式是自研，一个是基于数据库底层实现。 Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 SOFAEnclave：蚂蚁金服新一代可信编程环境，让机密计算为金融业务保驾护航102年 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.7.6 版本，主要变更如下：\n 支持精细化配置 Jackson 序列化； Triple 协议支持用户自定义元数据； Triple 协议支持 SPI 编程模式； 升级 hibernate-validator 版本到 5.3.6.Final； TripleServer 启动时发送启动事件； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.6\n2、发布 MOSN v0.17.0 版本，主要变更如下：\n 重构 XProtocol 连接池，支持 pingpong 模式、多路复用模式与连接绑定模式； 优化 XProtocol 多路复用模式，支持单机 Host 连接数可配置； Listener 配置新增对 UDS 的支持； 新增在 Dubbo 协议下通过 xDS HTTP 配置进行转换的过滤器； 部分框架实现优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.17.0\n","date":1601622000,"description":"【09/28-10/02】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201002/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bc9b38b8088d82138a46a8318e944840","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201002/","publishdate":"2020-10-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201002/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":" SOFA Weekly | MOSN、SOFARPC 发版、Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201002/","wordcount":1018},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@刘源远 提问：\n 请教一下大家，这个本地事务提交，是指这个本地事务在分布式事务中提交，还是指在自己的事务中提交啊？ 如果是指分布式事务中提交，那不就应该在分支事务提交之前，才存在回滚嘛？如果是指自己的事务中提交，那我断点下来，本地业务事务已经提交了，为什么还产生这条记录呢？ A：只要二阶段回滚的时候，发现你的 undolog 没插入就会做一条防御性的 undolog，你可以认为你没产生资源悬挂，但是二阶段确实没读到你的 undolog。所以才会插入一个防御性，你完全不需要理会 status=1 的记录。\n 奇怪的是，我断点下来，在一阶段会产生 undolog 记录（两条），然后抛异常回滚之后，一阶段的 undolog 记录（两条）被删除了，产生一条 status=1 的记录。会不会是因为某些原因，一阶段会产生 undolog 记录被删除了，所有二阶段没有查询到？\n A： 多数据源？\n 对的，多数据源。\n A：确认下是不是重复代理了？把自动代理关了，一般多数据源都是已经手动代理了，因为二阶段的时候，下发找 datasource，找到的不是你当时操作数据库的 datasource，导致没发现 undolog，就插了一条 status=1。\n 我现在手动配置代理，有两个数据源，一个用了 DataSourceProxy，一个没有。现在处于分布式事务中是使用了 DataSourceProxy 的数据源，但是回滚后还是会产生一条 status=1 的 undolog。\n A： 自动代理关了吗，看下怎么代理的。\n 你指的自动代理是 springboot-start 吗？还是其他的？\n A：Seata 的数据源自动代理，设置 Seata: enable-auto-data-source-proxy: false\n OK，好啦\n Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服通信框架 SOFABolt 解析 | 超时控制机制及心跳机制 蚂蚁金服通信框架 SOFABolt 解析 | 连接管理剖析 蚂蚁金服通信框架 SOFABolt 解析 | 协议框架解析 蚂蚁金服通信框架 SOFABolt 解析 | 序列化机制(Serializer) 蚂蚁金服通信框架 SOFABolt 解析 | 编解码机制 社区活动预告 CSDI summit 中国软件研发管理行业技术峰会（Software development management industry technology summit）由国内专业咨询机构百林哲匠心打造的软件行业技术领域顶级盛会，将于2020年9月24-27日举办。 话题涵盖：组织数字化转型、研发效能、产品创新、用户增长、云原生、架构创新、微服务、AI 大数据、数据安全和云安全、AIOT 实践等方面。蚂蚁集团也应邀参与本次大会分享。\n分享主题：金融级云原生 PaaS 实践之路\n分享嘉宾：成旻 蚂蚁金服高级技术专家\n分享时间：2020-09-26 16:40 - 18:00\n分享亮点：\n 蚂蚁 PaaS 产品的缘起； 经典应用服务的能力和特色； 容器应用服务的进阶能力； 面向未来\u0026amp;ndash;混合云发展发向； 活动形式：线上峰会\n活动详情：点击“这里”，了解日程详情\n","date":1601017200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200925/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c7562a535d9b34b23d0b559dd756ef6a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200925/","publishdate":"2020-09-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200925/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt 源码解析合辑、CSDI summit 活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200925/","wordcount":1385},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 社区大事件 MOSN 支持 Istio 啦～详见链接：\n 英文版：《Using MOSN with Istio: an alternative data plane》 中文版：《在 Istio 中使用 MOSN：另一个数据平面》 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@梓郁 提问：\n 我最近刚刚接触分布式链路监控，看了 SOFATracer 的 slf4j 的 demo。现在有一个问题。就是我想在日志里面打印出 span 的 parentid，但是我不想在我自己的代码里面显性地用 MDC 添加，有什么其他方法吗？（我现在是打算在 MDCSpanExtension 里面用 mdc.put 添加;再重新打包添加依赖这样可行吗？）\n A：自己扩展下这个接口 SpanExtension。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@石评 提问：\n 我有个关于 Seata 的疑问：A -\u0026amp;gt; B-\u0026amp;gt;C 的时候，不管 B 有没有本地事务，如果 C 失败了 B 的都会回滚，那么 B 的本地事务的作用是什么呢？\n A：分布式事务认为由若干个分支事务（本地事务）构成的，如果加了 autocommit=false，那么 B 服务的几条 sql构成一个本地事务，如果不加那么每条 DML 语句都是一个本地事务。本地事务越少那么与 TC 的交互次数越少。\n3、@徐成阳 提问：\n Seata 的 TCC 强一致的嘛？\n A：AT、XA、TCC 应该都属于强一致性。 SAGA 无法保证事务隔离性，在部分情况下可能会存在无法回滚，而选择向前继续重试来保证事务最终一致性。 四种模式都是属于最终一致性。SAGA 性能更高，因为没有二阶段提交，而且分支数据都是保存在本地的。\nSeata：https://github.com/seata/seata\n本周推荐阅读 来了！2020 云栖大会 蚂蚁金融科技产品能力再升级 企业数字化转型指南，《SOFAStack 解决方案白皮书》正式发布 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.4.bugfix_2 版本，主要变更如下：\n 修复使用 grpc 时，在一定情况下无法自动重连的问题； 详细发布报告： https://github.com/sofastack/sofa-jraft/releases/tag/1.3.4.bugfix_2\n社区活动预告 这里有一个您的专属日程提醒，请查收：\n日程主题：OceanBaseDev Meetup#1 上海站「深入分布式数据库：事务·高可用·云原生」\n出品人： - 杨传辉（花名：日照）蚂蚁集团研究员、OceanBase 总架构师 - 韩富晟（花名：颜然）蚂蚁集团资深技术专家、OceanBase 事务研发负责人\n日程时间：2020-09-20 本周日 13:00-17:30\n日程地点：上海市杨浦区政学路77号 InnoSpace+\n日程详情：点击“这里”，了解日程详情\n","date":1600412400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200918/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d3e2feb22ec7504b5fc6648eeba4769f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200918/","publishdate":"2020-09-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200918/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFAWeekly｜MOSN 支持 Istio、SOFAJRaft 发布、本周日您有一条待办日程","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200918/","wordcount":1251},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈健斌 提问：\n Seata 使用注册中心只存储个地址列表，引入 SOFAJRaft 后感觉注册中心没必要了？用户用起来就跟 zk 集群、kafka 集群一样，ip:port,ip:port 这样。\n A：这个 看需求了，都可以啊。我感觉还是可以继续使用注册中心，然后 SOFAJRaft 的地址从注册中心回去，动态构建 SOFAJRaft 集群。\n 可以噢，这样 client 端不需要设置 server 的集群了，通过注册中心来就可以了，自动组装了。 我目前是这么设计的，有空的话还望指点一二。\n A：Sesta server 经常会经常替换吗？\n 这个得看用户了，要不咱假设2个情况吧，如果不经常替换，此方案适用不。经常替换下要做哪些改进？\n A：经常替换的话要考虑 raft 集群的替换，要处理 addpeer removepeer 这是要走 raft 协议的（用 cliservice 这个接口），就是换一台 server 不是换个地址就完事了，需要调用 addpeer把新机器加入 raftgroup 然后 SOFAJRaft 会自动同步数据，移除一个节点需要调用 removepeer。\n 也就是，如果我现在扩容，比如我原来的节点是127.0.0.1:7091，127.0.0.1:7092，127.0.0.1:7093 然后我现在要加一个127.0.0.1:7094，我能不能直接跟 zk 那边扩容一样，我新加入进来的节点设置的地址是127.0.0.1:7091，127.0.0.1:7092，127.0.0.1:7093，127.0.0.1:7094，先让他加入进去，然后手动挨个重启其余3台。目前这样的扩缩容，我的设计方案能满足吗？\n A：不需要重启，需要 addpeer，参考第11小结，最有效的排查 SOFAJRaft 问题工具 https://www.sofastack.tech/projects/sofa-jraft/jraft-user-guide/ SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@koutatu 提问： \u0026amp;gt; 想咨询下，Seata Saga 模式下，TC 的作用是什么呢，回滚操作还是 TC 触发吗？感觉 Saga 状态机模式下，状态机可以控制回滚，TC 是不是只是记录下状态，不做什么实际处理了呢？\nA：你说的应该是对的，Saga 脱离 TC 理论上都是可行的。\n 目前的回滚操作是不是也是状态机自身控制的，也就是链路里面的每一步都需要有一个状态机。TC 只负责接收消息，而不是像 TCC 或者拦截器式的 Saga 一样，回滚由 TC 统一控制。\n A：TC 在 Saga 模式的作用就是记录全局事务分支事务状态。 Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析 SOFABoot 扩展点初体验 | SOFALab 实践系列 剖析 | 详谈 SOFABoot 模块化原理 实操 | 基于 SOFABoot 进行模块化开发 开源 | SOFABoot 类隔离原理剖析 SOFA 项目进展 1、发布 SOFAArk v1.1.4 版本，主要变更如下：\n 支持动态替换 biz name； TestClassLoader 导出 mockito 包以支持 mockito 测试框架； 修复 AfterBizStopEvent 事件处理时机问题导致的 NPE； 修复 web 模块卸载问题； 支持 ark telnet 使用安全模式启动； 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.1.4\n2、发布 SOFABoot v3.4.4 版本，主要变更如下：\n 提供 jvm 调用拦截扩展； 修复若干测试用例； 修复在 ark 环境使用 sofa:reference 引用 jvm 服务出现 NPE bug； 修复健康检查通过但 ExtensionComponent activate 失败 bug； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.4\n社区活动预告 近几年，越来越多的传统企业面临互联网化，IOT、区块链、AI、5G 等技术也在高速发展，任何一个技术的推广到成熟都会带来数据量的指数级增长，都会对存储带来巨大的冲击。相信随着这些技术的突破，未来越来越多的核心场景会走向分布式的领域。国内很多团队也在进行分布式数据库的探索与实践。\nOceanBaseDev Meetup 是以城市站展开的数据库技术交流活动，旨在为关注分布式数据库技术的同学提供技术交流、分享、探讨的空间与平台。\nOceanBaseDev Meetup#1 上海站，将邀请蚂蚁集团 OceanBase 团队的三位核心研发专家以及网易杭研资深研发工程师，针对分布式数据库的分布式事务以及落地实践展开分享。现场更有外滩大会门票等你来拿～\n活动主题：**OceanBaseDev Meetup#1 上海站「深入分布式数据库：事务·高可用·云原生」\n出品人： - 杨传辉（花名：日照）蚂蚁集团研究员、OceanBase 总架构师 - 韩富晟（花名：颜然）蚂蚁集团资深技术专家、OceanBase 事务研发负责人\n活动时间：2020-09-20 13:00-17:30\n活动地点：上海市杨浦区政学路77号 InnoSpace+\n活动报名：点击“[阅读原文**](https://www.huodongxing.com/event/5562442480600)”，了解活动详细议题并锁定席位\n","date":1599807600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200911/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"25ab3501e7db2cd836d05f86bb6c17ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200911/","publishdate":"2020-09-11T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200911/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot、SOFAArk 发布、9/20 上海线下活动推荐","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200911/","wordcount":2145},{"author":"王发康（毅松）","categories":"MOSN","content":" 本文根据 2020 年 8 月 15 号在深圳 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会云原生专场现场实录整理。\n分享嘉宾：王发康（毅松）蚂蚁集团可信原生技术部 技术专家，专注于高性能网络服务器研发，是 MOSN、Tengine 开源项目核心成员，目前关注云原生 Service Mesh、Nginx、Istio 等相关领域，喜欢开源，乐于分享。\nGItHub：https://github.com/wangfakang\n以下是分享全文。\n前言 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，本文就其在演进过程中遇到的问题及思考进行展开。对接 UDPA，实现 Istio 融合，并增强 MOSN 服务治理及流量控制能力对接云原生周边组件，实现 MOSN 开箱即用。\n大家下午好，我叫王发康，来自蚂蚁集团可信云原生应用网络团队，之前几年一直从事南北向网关（接入层）的开发和维护，说来也是和流量有着别样的渊缘，现在主要做东西向的流量网关（Service Mesh）开发和设计。今天演讲的主题是《云原生网络代理 MOSN 的进化之路》，主要从如下几点介绍：\n MOSN 介绍； 云原生演进； 总结与展望； MOSN 介绍 接下来，就 MOSN 的诞生背景、发展历程、MOSN 具备的功能和架构以及内部的落地情况这几个维度介绍下 MOSN。\nMOSN 诞生背景 随着云计算、物联网等技术迅速发展，也促使着微服务的架构一直在进化，其演进过程通常经历了如下四个阶段：\n单体：一般起始阶段业务很简单，流量也不大，所有的处理都可以在一个服务中完成；\n分布式：随着业务操作的多样化以及流量的日益增长，不得不按照服务维度进行拆分，这样相同的服务资源消耗可对等，方便容量评估及管理；\n微服务：随着服务的拆分粒度越来越细，其服务的数量一直在增加，由此出现各种微服务治理的需求（限流、鉴权、路由等），于是便出现各种治理组件并以 SDK 插件的方式集成到不同应用中；\nService Mesh：伴随着服务治理的 SDK 种类、版本、重复等一系列问题，于是把 SDK 的能力剥离到 Sidecar，和业务进行解耦，从而实现业务和中间件能力的并行迭代；\n业务痛点\n 多语言，中间件组件开发适配成本高； SDK 升级困难； 服务治理能力弱； 技术不通用，无法复用； 业界解决方案\n Envoy (C++)； Linkerd (活跃度较低)； NginxMesh (活跃度低)； 综合以上业务痛点以及业界现有方案的评估，于是 MOSN 就诞生了。MOSN（Modular Open Smart Network）是用 GoLang 编写的网络代理服务器。作为 Sidecar、API Gateway、云原生 Ingress、Layer 4 或 Layer 7 负载均衡器等场景构建的。随着时间的推移，我们添加了额外的功能，例如多协议框架，多进程插件机制，DSL 以及对 xDS API 等的支持，支持 xDS 意味着我们现在可以将 MOSN 用作 Istio 的数据平面。\nMOSN 发展历程 从 2017 年底开始 Service Mesh 技术调研，2018 年 3 月份 MOSN 雏形问世并进行了小规模试点，秉着让更多的用户能够享受这一技术红利的思路，于是 2018 年 6 月正式开源 MOSN。2019 年 618 进行了规模化落地，并在同年的双 11 大促达到了核心支付链路的全覆盖。在通过大规模验证后，MOSN 社区开始在其标准化以及生态方面进行发展和演进。\nMOSN 功能视图 MOSN 作为一个通用的数据转发平面，提供多协议卸载、动态服务发现、服务治理（Trace、限流、重试、重写、超时控制等）、丰富的负载均衡算法等功能，可用于 Sidecar、API Gateway、云原生 Ingress、Layer 4 或 Layer 7 负载均衡器等场景。\nMOSN 架构解析 MOSN 采用的是分层的体系结构，其系统分为 NET/IO、Protocol、Stream、Proxy 四层：\n NET/IO 作为网络层，监测连接和数据包的到来，同时作为 listener filter 和 network filter 的挂载点; Protocol 作为多协议引擎层，对数据包进行检测，并使用对应协议做 decode/encode 处理; Stream 对 decode 的数据包做二次封装为 stream，作为 stream filter 的挂载点; Proxy 作为 MOSN 的转发框架，对封装的 stream 做 proxy 处理; 其中，每一层通过工厂设计模式向外暴露其接口，方便用户灵活地注册自身的需求。通过协程池的方式使得用户以同步的编码风格实现异步功能特性。通过区分协程类型，MOSN 实现了 read 和 proxy worker 两大类协程，read 协程主要是处理网络的读取及协议解析，proxy worker 协程用来完成读取后数据的加工、路由、转发等。其架构如下图所示：\nMOSN 为了降低 Runtime GC 带来的卡顿，自身做了内存池的封装方便多种对象高效地复用，另外为了提升服务网格之间的建连性能还设计了多种协议的连接池从而方便地实现连接复用及管理。\n在连接管理方面，MOSN 设计了多协议连接池， 当 Proxy 模块在 Downstream 收到 Request 的时候，在经过路由、负载均衡等模块处理获取到 Upstream Host 以及对应的转发协议时，通过 Cluster Manager 获取对应协议的连接池 ，如果连接池不存在则创建并加入缓存中，之后在长连接上创建 Stream，并发送数据，如下图所示：\n在内存管理方面，MOSN 在 sync.Pool 之上封装了一层资源对的注册管理模块，可以方便的扩展各种类型的对象进行复用和管理。其中 bpool 是用来存储各类对象的构建方法，vpool 用来存放 bpool 中各个实例对象具体的值。运行时通过 bpool 里保存的构建方法来创建对应的对象通过 index 关联记录到 vpool 中，使用完后通过 sync.Pool 进行空闲对象的管理达到复用，如下图所示：\nMOSN 落地情况 服务在做了 Mesh 化后，有人可能会质疑，增加一跳 Sidecar 转发是否会导致性能下降，其实不然，在蚂蚁的部分业务场景中，部分业务上了 Mesh 后，其 CPU 消耗还比之前低了，原因是之前的一些通用 SDK 能力都下沉到 Sidecar 中，并统一做了一定的优化。另一个好处是，由于 MOSN 使用 GoLang 开发，天然具备其高开发效率，所以也大大的提升了中间件相关能力的研发速度。\nMOSN 云原生演进 在 MOSN 大规模落地并通过双 11 大考后，MOSN 也开始在实践的道路上进行标准化演进。并通过和 Istio 社区的合作，MOSN 实现了 xDS 的适配，可方便的实现 Istio 作为 MOSN 的控制面进行服务配置的管理。另一方面， …","date":1599022800,"description":"MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，本文就其在演进过程中遇到的问题及思考进行展开。","dir":"blog/cloud-native-network proxy-mosn-evolutionary-path/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"080e78e9d0103daed414ee3a8b5b7996","permalink":"https://sofastack.github.io/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","publishdate":"2020-09-02T13:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","summary":"本文根据 2020 年 8 月 15 号在深圳 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会云原生专场现场实录整理。 分享嘉宾：王发康（毅松）","tags":["MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 的进化之路","type":"blog","url":"/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","wordcount":5065},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@晏伦 提问：\n 请问 Seata 的全局锁粒度是数据库级别还是表级别？全局锁会带来并发的问题吧？如何权衡的呢？\n A：全局锁是行级别的；如果2个事务在同时更新同一行，会出现锁竞争问题，所以 AT 模式的适用场景是并发请求较低，不会产生行锁竞争的业务场景。\nSeata：https://github.com/seata/seata\n本周推荐阅读 少年五年升阿里 P8，他如何从低谷登上“光明顶”？ 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构 Forrester中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求 组件解析部分合辑 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 SOFA 项目进展 发布 sofa-common-tools v1.2.0 版本，主要变更如下：\n 修复多线程日期打印问题； SOFAThreadPool 支持一个 Runnable 在多个 thread 运行； 停止 JDK6 支持； 详细发布报告：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.2.0\n社区活动预告 CSDI summit 中国软件研发管理行业技术峰会（Software development management industry technology summit）是软件行业技术领域顶级盛会，协同国内外知名软件、互联网等企业研发一线技术专家从 AI 和大数据、产业变革、技术创新、生态发展、业务创新、商业模式等方面重点研讨软件研发趋势。蚂蚁集团也受邀参与本次峰会分享“云原生”相关主题。\n分享主题：金融级云原生 PaaS 实践之路\n分享嘉宾：成旻 蚂蚁集团高级技术专家\n分享时间：2020-09-26 16:40-18:00\n听众收获：\n 蚂蚁 PaaS 产品的缘起； 经典应用服务的能力和特色； 容器应用服务的进阶能力； 面向未来\u0026amp;ndash;混合云发展发向； 活动地点： 线上活动\n活动报名： 点击“这里\n","date":1598598000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200828/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"474484cd88c8a1971016217eb9c1438d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200828/","publishdate":"2020-08-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200828/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | sofa-common-tools 发布、组件解析合辑、云原生活动推荐","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200828/","wordcount":1038},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谢小东 提问：\n 请教一个问题，在使用 AT 模式的时候，新增的一条数据，回滚之前我在 db 改了我刚新增的数据，这个时候如果我抛出异常，但是就不发回滚，该怎么处理？\n A：不要在全局事务包裹之外进行对数据的并发操作，如果你这样做，就跳过了 AT 的全局锁，隔离性无法保证，如果你有这方面需求的，可以用 XA 模式，并且使用数据库自身带有排它锁的操作，数据库的自身支持了 XA 模式，就可以帮你保证隔离性。\n 你的意思就是我在这种情况下 XA 模式适合？XA 模式是行锁么？\n A：XA 是数据库自身实现的隔离机制，AT 是统一到 TC 去竞争行锁，而没用到 AT 的地方修改数据库当然就不会去 TC 竞争行锁，隔离性只能保证再全局事务注解下的操作生效。\n2、@彭兴家 提问：\n 请问 Seata 里说的全局锁和本地锁对应 MySQL 的什么锁呀？\n A：全局锁就是从 TC 竞争的锁，本地锁就是参与方自己本地的 MySQL 连接，比如 update 不就有排他锁的作用吗，因为一阶段提交，连接释放了，这个本地数据库的锁就解开了。而全局锁是从 TC 拿的，这个锁保证了你的入口只要是分布式事务注解下，就会去竞争这个全局锁。保证了再分布式事务注解下的全局事务间的隔离性\n 谢谢，明白了。但这样的话，Seata 通过前置镜像回滚。在全局事物执行的过程中，要是其他项目(没在全局事物下的项目)对该条数据进行了修改，那么按照 Seata 的机制，前置镜像对比不同了就不能回滚，需要手动处理？\n A：是的，需要人工介入，因为只有人为分析才能校准数据了。对 Seata 来说他只知道要把数据回滚到发生前，但是数据被干扰了，就无法回滚了。\n 理论上来说这种情况出现的几率很大呀，多个不同项目操作同一条数据。\n A：全局事务，字面意思要理解一下。你让他不全局了，让它不覆盖到，如何保证隔离性？要么涉及到的库对应的应用全局使用 Seata AT，要么就换 XA，修改的数据，用 select for update，这个本地锁在二阶段下发通知前不会释放，保证了隔离性。\n3、@苏龙飞 提问：\n 请问，现在我们的 cloud 项目中用了 Seata，数据库只有一个，然后发现性能不够，所以想换成多主从数据库，并且能和 Seata 兼容，有没有好的方案呀？\n A：主从方案本就应该是允许暂时的不一致，只要你保证读写都需要的时候，一定是主库，并把主库的 datasource 代理掉就好了，保证需要读后马上写的，一定要是主库操作。 Seata：https://github.com/seata/seata\nSOFAChannel 部分合辑 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 [链接]()蚂蚁金服分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 本周推荐阅读 蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO？ 蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？ ","date":1597993200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200821/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"34ac475f8a4ec2435b62a9bf4d520e2a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200821/","publishdate":"2020-08-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200821/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 线上直播合辑整理、Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200821/","wordcount":1515},{"author":"樱桃","categories":"Occlum","content":" \u0026amp;lt; SOFA:Channel/ \u0026amp;gt;，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 本文根据 SOFAChannel#18 直播分享整理，主题：零门槛的机密计算：Occlum LibOS 使用入门和技术揭秘。\n大家好，我是今天的讲师田洪亮（花名：樱桃），蚂蚁集团技术专家，也是 Occlum 开源负责人。今天我和大家分享一下如何使用 Occlum 的轻松开发机密计算应用以及 Occlum 技术架构和特色。\n前言 云计算、大数据、人工智能，我们正处在一个数据爆炸的时代。如何能够在享受和利用海量数据所产生的价值的同时，保证数据的安全和用户的隐私呢？这无异是一个用户、企业和监管部门共同关注的问题。\n近年来兴起的机密计算（Confidential Computing），正是为了解决这个问题而来。利用可信执行环境（Trusted Execution Environments，简称 TEE）技术，机密计算使得数据始终保持加密和强隔离状态，从而确保了用户数据的安全和隐私。机密计算可以解决诸多应用场景中“信任”难题，比如多个不互信组织之间的数据融合与联合分析、区块链上的智能合约的机密性保护、公有云平台对外部或内部攻击的防御、高敏感信息（比如密码学材料、医疗档案等）的安全保护等等。\n但是，机密计算底层依赖的 TEE 技术——比如目前最成熟的云端 TEE 技术 Intel SGX——也带来了额外的功能限制和兼容问题。这使得机密计算的开发者面领一个巨大的阻碍：应用开发难。\n在本文中，我们会首先分析当前 SGX 应用开发者会遇到的各种挑战和痛点，然后介绍蚂蚁集团自研的开源 TEE OS 系统 Occlum 如何大幅降低 SGX 应用开发的门槛，真正做到人人都可以玩转机密计算。\n为什么 SGX 应用开发难？ SGX 应用程序是一种基于划分的模型：在用户态的（不可信）应用程序（上图红色部分）可以嵌入 SGX TEE 保护的区域（上图绿色部分），被称为 Enclave。支持 SGX 的 Intel CPU 保证 Enclave 中的受保护内容是在内存中加密的，并且与外界强隔离。外界的代码如果想进入 Enclave 中执行其中的可信代码必须通过指定的入口点，后者可以实施访问控制和安全检查以保证 Enclave 无法被外界滥用。\n由于 SGX 应用程序是基于这种划分的架构，应用开发者通常需要使用某种 SGX SDK，比如 Intel SGX SDK、Open Enclave SDK、Google Asylo 或 Apache Rust SGX SDK。但无论使用上述哪种 SDK，开发者会遭遇下面的开发困境：\n 必须将目标应用做二分：开发者需要决定哪些组件应该置于 Enclave 内部，哪些置于 Enclave 外部，以及双方如何通信。对于复杂的应用，确定高效、合理且安全的划分方案本身就是一件颇具挑战的工作，更不要说实施划分所需的工程量。 被限定在某个编程语言：无论使用上述哪种 SDK 开发，一个开发者都将被限定在该 SDK 所支持的语言，这通常意味着 C/C++（当使用 Intel SGX SDK、Open Enclave SDK 或 Google Asylo 时），而无法使用 Java、Python、Go 等更加友好的编程语言。 只能获得很有限的功能：处于硬件限制和安全考虑，Enclave 中是无法直接访问 Enclave 外的（不可信）OS 的。由于 Enclave 中缺乏 OS 的支持，各种 SDK 只能提供普通不可信环境下的一个很小的功能子集，这使得很多现有的软件库或工具都无法在 Enclave 中运行。 上述困境使得为 SGX 开发应用成为一件十分痛苦的事，制约了 SGX 和机密计算的普及度和接受度。\n学会 Occlum 的“三板斧” Occlum 是一款蚂蚁集团开源的 TEE OS，可以大幅降低 SGX 应用的开发门槛。那到底多低呢？只需要学会 Occlum的三条命令：new、build和run。本节我们以利用 Occlum 在 SGX 中运行一个 Hello World 程序为例进行说明。\n这里有一个非常简单的 Hello World 程序。\n$ cat hello_world.c #include \u0026amp;lt;stdio.h\u0026amp;gt; int main() { printf(\u0026amp;quot;Hello World!\\n\u0026amp;quot;); return 0; } 首先，我们用 Occlum 提供的 GCC 工具链（occlum-gcc）编译这个程序，并验证它在 Linux 上能正常工作。\n$ occlum-gcc hello_world.c -o hello_world $ ./hello_world Hello World! 然后，我们为这个程序创建一个 Occlum 的实例目录（使用 occlum new 命令）。\n$ occlum new occlum_hello $ cd occlum_hello 该命令会创建一个名为 occlum_hello 的目录，并在该目录中准备一些必要的文件（如 Occlum.json 配置文件）子目录（如 image/）。\n接下来，我们基于刚刚编译好的 hello_world 制作一个 Occlum 的 Enclave 文件和可信镜像（使用 occlum build 命令）。\n$ cp ../hello_world image/bin $ occlum build 最后，我们在 SGX 中运行 hello_world（使用 occlum run 命令）。\n$ occlum run /bin/hello_world Hello World! 更复杂的程序也可以用类似上面的流程通过 Occlum 移植进 SGX 中。用户无需理解 SGX 的二分编程模型，无需或只需少量修改应用代码，还可以自由选择编程语言（比如 Java、Python、Go 等）。使用 Occlum，应用开发者可以将宝贵的精力集中在编写应用上，而非为 SGX 做应用移植。\n用起来像 Docker 的 TEE OS 在了解了 Occlum 的基本用法和体验之后，很自然地会好奇 Occlum 的技术原理：Occlum 的用户接口为什么这样设计？而简单接口背后的技术架构又是怎样的？本节就试图回答这些问题。\nOcclum 的一个设计理念是 Enclave-as-a-Container。在云原生时代，容器至关重要，容器无处不在。容器最常见的实现方式是基于 Linux 的 cgroup 和 namespace（比如 Docker），但也有基于虚拟化的实现（比如 Kata）。我们观察到，TEE 或者 Enclave 也可以作为一种容器的实现手段。因此，为了传达这种理念，同时给用户提供一种熟悉的体验，我们特意将 Occlum 的用户接口设计成与 Docker 和 OCI 标准接近。除了前面提到的 new、build和run 三个命令，Occlum 还提供 start、exec、stop、kill 等命令，其语意与 Docker 同 …","date":1597906800,"description":"本文分享如何使用 Occlum 的轻松开发机密计算应用以及 Occlum 技术架构和特色。","dir":"blog/sofa-channel-18-retrospect/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a1d55e5deb00aa8cde8d14f250569013","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-18-retrospect/","publishdate":"2020-08-20T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-channel-18-retrospect/","summary":"\u0026lt; SOFA:Channel/ \u0026gt;，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。 本文根据 SOFAChannel#18 直","tags":["Occlum","SOFAchannel"],"title":"人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | SOFAChannel#18 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-18-retrospect/","wordcount":2939},{"author":"田晓旭","categories":"Kubernetes","content":" 随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。\n 根据 CNCF 2019 Kubernetes 使用调查报告的显示：目前 84% 的用户已经在生产环境中使用 Kubernetes，生产环境中容器部署规模超过 1000 的比例是 34%，其中超过 5000 的大规模应用比例是 19%。当集群越来越大、越来越复杂，集群可用性就会面临挑战。\n 整体指标：集群是否健康，所有组件是否正常工作，集群中 Pod 创建的失败数量有多少等等； 追踪能力：集群中发生了什么，是否有异常，用户做了什么事情等等； 原因定位：出现异常之后，找到是哪个组件出了问题； 想要解决这些问题，比较好的一个方法就是 SLO，通过定义 SLO 来描述集群的可用性，追踪集群中 Pod 的生命周期，一旦出现失败 Pod，快速定位异常组件。本文采访了蚂蚁集团技术专家范康和姚菁华来分享蚂蚁集团的 SLO 体系是如何建立的。\n大家常会听到 SLA，其实 SLA 是 SLO 衍生出来的协议，SLA 协议会形成具有法律效力的合同，通常是服务供应商和外部客户之间签订的，而 SLO 是用于内部服务之间，定义服务所提供功能的一种期望状态。\n1 SLO 指标定义 如果我们要通过定义来描述集群的可用性，那么具体的描述指标就成为了需要解决的关键问题。在蚂蚁 集团 内部，集群可用性的关键指标包含五个：集群健康度、Pod 创建成功率、残留 Terminating Pod 的数量、服务在线率和故障机数量。\n 集群健康度：通常使用 Healthy，Warning，Fatal 三个值来描述，其中 Warning 和 Fatal 对应告警体系，例如 P2 告警发生，那集群就是 Warning，而 P0 告警发生，那集群就是 Fatal，必须进行处理； Pod 创建成功率：这是一个非常重要的指标，蚂蚁集团一周的 Pod 创建量在百万级别，如果成功率波动会造成大量 Pod 失败，同时 Pod 成功率下跌也是集群异常的最直观反映； 残留 Terminating Pod 的数量：有人可能会好奇为什么使用残留 Terminating Pod 的数量，而不用删除成功率？这是因为当 Pod 数量达到百万级别后，即使删除成功率达到了 99.9%，Terminating Pod 的数量也有数千，残留这么多 Pod 占用应用容量，在生产环境中是不可接受的； 服务在线率：这个指标是通过探针来衡量的，探针失败则意味着集群不可用； 故障机数量：这是一个节点维度的指标，故障机通常是指无法正确交付 Pod 的物理机，集群故障机需要做到“快速发现，快速隔离，及时修复”，否则会对集群容量造成影响； 以上指标的阈值和 SLO 性能目标都是根据业务方的增长来定义的，随着业务的不断增长，这些指标的定义也可能需要跟着做调整。\n以 Pod 创建成功率为例，蚂蚁集团将 Pod 分为了普通 Pod 和 Job 类 Pob，普通 Pod 的 RestartPolicy 为 Never，Job 类 Pod 的 RestartPlicy 为 Never 或 OnFailure，两者都设定有交付时间，普通 Pod 的交付标准是 1min 内 Pod 已经 Ready；Job 类 Pod 的交付标准是 1min 内 Pod 的状态已达 Running、Succeeded 或 Failed。最开始 Pod 创建成功率的定义是成功创建的 Pod 和总 Pod 的比值，但是很快就发现在排查原因时，系统很难分辨，所以又将 Pod 失败原因调整成用户和系统两部分，创建成功率的定义就变成了创建成功的 Pod 和总的 Pod 减去用户失败 Pod 的比值。\n2 蚂蚁集团的 SLO 体系 确定好 SLO 各项关键指标的定义之后，接下来就是构建 SLO 体系。\n据范康介绍，蚂蚁集团 SLO 系统主要包括两个方面，一个方面用于向终端用户 / 运维人员展示当前集群各项指标状，另一方面是各个组件相互协作，分析当前集群状态，获取影响 SLO 的各项因素，为提升集群 pod 交付成功率提供数据支持。\n蚂蚁集团 SLO 体系架构图\n自顶向下而看，蚂蚁集团 SLO 的分层架构包括 SLO、Trace system、Increase of SLO、Target 和 The unhealthy node。\n其中，顶层组件主要面向各种指标数据，如集群健康状态、pod 创建、删除、升级成功率、残留 pods 数量、不健康节点数量等指标。其中 Display Board 是指监控大盘，可能不会实时查看，为避免错过处理紧急事件的最佳时机，同时构建了 Alert 告警子系统，支持配置多种告警方式；Analysis System 通过分析指标历史数据以及采集到的节点 metrics 和 master 组件指标，给出更详细的集群运营报告；Weekly Report 子系统给出当前集群本周 pod 创建 / 删除 / 升级的数据统计，以及失败案例原因汇总；Terminating Pods Number 给出一段时间内集群内新增的无法通过 Kubernetes 机制删除的 Pods 列表和 Pods 残留原因；Unhealthy Nodes 则给出一个周期内集群所有节点的总可用时间占比，每个节点的可用时间、运维记录、以及不能自动恢复，需要人工介入恢复的节点列表。\n为了支撑上述这些功能，蚂蚁集团还开发了 Trace System，用来分析展示单个 pod 创建 / 删除 / 升级失败的具体原因。其中包含日志和事件采集、数据分析、pod 生命周期展示三个模块。日志和事件采集模块采集各 master 组件以及节点组件的运行日志和 pod、node 事件，分别以 pod/node 为索引存储日志和事件；数据分析模块分析还原出 pod 生命周期中各阶段用时，判断 pod 失败原因，节点不可用原因。最后，由 Report 模块向终端用户暴露接口和 UI，向终端用户展示 pod 生命周期以及出错原因。\n3 经验总结 目前蚂蚁集团的 SLO 实践不仅提高了集群 pod 的交付成功率，同时通过构建 tracing 系统，分析到集群内 pod 交付关键链路的耗时，整理失败原因，实现了数据分析 / 诊断平台。对于如何实现高 SLO，范康也给出了自己的五点经验。\n 在提升成功率的进程中，SLO 治理团队面临最大的问题是镜像下载。Pod 必须在规定时间内交付，而镜像下载通常需要非常多的时间。所以，团队通过计算镜像下载时间，专门设置了一个 ImagePullCostTime 的错误，即镜像下载时间太长，导致 Pod 无法按时交付。另外，阿里镜像分发平台蜻蜓支持了 Image lazyload 技术，在 Kubelet 创建容器时，不用再下载镜像，大大加速了 Pod 的交付速度； 提升单个 Pod 成功率：随着成功率的提升，再提升的难度会越来越大，这是可以引入 workload 进行重试。蚂蚁集团内部的 PaaS 平台会不断重试，直到 Pod 成功交付或者超时。需要注意的是，重试时要先排除之前的失败节点； 检查关键 Daemonset： …","date":1597820400,"description":"随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。本文分享蚂蚁集团的 SLO 体系是如何建立的。","dir":"blog/antgroup-kubernetes-high-slo/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f15367978d8b820ec3fcddf3ab6d7779","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-kubernetes-high-slo/","publishdate":"2020-08-19T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/antgroup-kubernetes-high-slo/","summary":"随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。 根据 CNCF 2019 Kubernetes 使用调查报告的显示：目前 84% 的用户已经在生产环境中使用 Kubernetes，生","tags":["Kubernetes"],"title":"蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO？","type":"blog","url":"/sofastack.tech/blog/antgroup-kubernetes-high-slo/","wordcount":2530},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈亚兵 提问：\n 我想单独使用注册中心 SOFARegistry，可能的服务有 Java 和 Python，SOFARegistry 支持 Python 服务接口的注册吗？\n A：SOFARegistry 注册中心是支持各个语言的服务发现和订阅的，目前开源版中只有 Java client。实现其他语言的服务发现和订阅，需要自己实现相关语言的 Registry client。\n sofa-bolt-python 也有服务发现和发布，它和 sofa-registry 的发现有什么不同吗？\n A：sofa-bolt-python 只做了使用 MOSN 的服务接口的客户端。sofa-registry 是服务端。 SOFARegistry：https://github.com/sofastack/sofa-registry\n2、@刘明 提问：\n Seata 的 XA 模式做了一个压测，tps=1000，开始报错，ORA-24756：事务处理不存在。 看了下数据库global_table，状态是 3。 3 是 CommitRetrying ， 这说明 phase 1 阶段过了，2 阶段提交报事务不存在。 目前 global_table 里有700多条记录，95%是状态3，还有状态1的。\n A：应该是一个原因，很可能就是2阶段提交失败了。begin 的你查看下他的分支事务状态是什么。\n begin 的分支表里没有数据，可能注册就失败了。\n A：是的，有可能，TC 收到了，然后 TM 超时了，我建议你 1000tps 的测试，搞个 TC 集群，就一台可能撑不住。\n 我想在出错的时候，有个日志轨迹，可以知道数据目前是不是脏的？\n A：select for update 或者 update x=x+n 这样写法一般没事。\n 会不会锁住记录呢？\n A：不锁住怎么保证隔离性。这个 for update xa 没提交前会锁住的，这个锁由数据库方自己已经实现了。\n 是的，那1阶段已经过了，记录会一直锁在那里了吗？\n A：二阶段没提交，锁在数据库肯定没释放。不过看起来你应该提交了吧，因为已经提示你事务不存在了。\n 是的，事务提示不存在，但是数据没有提交。 我研究下。\n A：可以的，seata-xa 现在还不是特别完善，可以多研究下，发现问题可以提交 PR 来贡献，一起让 XA 更稳定更好。\n 并发情况下，事务已经提交，TCC 发起 global commit 请求超时导致了 commitRetry，因此事务不再存在，只是 TCC 会一直去重试。 这导致了性能下降很快，不断重复已经不存在事务的 commit 动作，使用 Oralce 测试下来耗时很大，MySQL 可能也不会更好。考虑在 RM 端做 xaCommit 的时候，引入一个 Redis 检查 xid 是否已经提交，已经提交返回提交成功。\n Seata：https://github.com/seata/seata\n本周推荐阅读 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？ SOFA 项目进展 本周发布详情如下：\n发布 SOFABoot v3.4.3 版本，主要变更如下：\n 新增 endpoint，支持展示启动耗时信息； 升级 Tomcat 版本，修复安全隐患 CVE-2020-11996； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.3\n社区活动报名 A2M 峰会旨在发现全球互联网领域在人工智能、大数据、互联网架构等领域的创新工程和杰出团队，整合国际最佳技术实践，构建行业案例研究智库，帮助中国企业在人工智能时代成功转型、升级。蚂蚁集团受邀进行云原生构建之路的专题分享。\n分享主题：Dubbo 基于 MOSN 在 Service Mesh 场景下的落地实践\n分享嘉宾：曹春晖 蚂蚁集团 可信原生技术部技术专家\n蚂蚁集团技术专家，对 Go 语言有深入的研究，《Go 语言高级编程》作者。在后端业务开发、数据平台等领域有多年的实践经验。目前正在领导 MOSN 社区进行 Dubbo 生态在 Service Mesh 场景下的落地工作。\n背景介绍：过去一段时间，云原生和 Service Mesh 大火。很多公司希望借着东风推动公司的微服务架构演进到下一阶段。然而在实践过程中不会事事如意，问题接踵而至。\n在使用 Dubbo 来做微服务框架的公司中，因为每个公司发展阶段不同，上云的进度不同，社区方案却要求必须要在完全上云之后才能沐浴 Service Mesh 的春风，这着实令人失望。\n解决思路：借助前人的落地经验，在 MOSN 与 Dubbo 结合的探索中，我们思考出一些可供处于不同上云阶段的公司参考的落地方案。经过对数据面的简单改造，在控制风险的前提下，能够渐进地将 Service Mesh 落地到公司内。\n成果：基于 MOSN 和 Dubbo-go，实现 Service Mesh 在 Dubbo 场景下的落地。\n听众收益：\n 了解落地 Service Mesh 对于整体架构的收益； 了解 MOSN 社区的发展现状和规划； 了解 Dubbo 在各种业务场景和上云发展阶段中如何优雅落地 Service Mesh； 分享时间：2020-09-05 16:50-17:50\n活动地点：上海\n活动报名：点击“这里”锁定席位\n","date":1597388400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200814/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"68d4b22d401ef51b62f39c8680895b36","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200814/","publishdate":"2020-08-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200814/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot 发布、SOFAJRaft 以及 SOFARPC 内容合辑、MOSN 活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200814/","wordcount":2113},{"author":"万佳","categories":"Kubernetes","content":" 在 Kubernetes 中，Secret 显得尤其重要。因为它是 K8s 中存储所有敏感信息的对象。据悉，这些敏感信息包含密码、集群的证书、OAuth token、ssh key 以及其他用户自定义的敏感文件等。因此，一旦 K8s 中 Secret 出现安全问题，后果将非常严重。此外，虽然社区提供了一定的安全防护方案，但是依然存在诸多问题。\nK8s Secret 面临着哪些安全问题？这些安全问题会带来什么影响？社区提供的解决方案存在哪些不足？\u0026amp;hellip;\u0026amp;hellip;针对这些问题，InfoQ 记者采访了蚂蚁集团高级工程师秦凯伦，他专注于可信计算、系统安全和虚拟化等领域，对 K8s Secret 有着深入的研究和探索。\nK8s Secret 的安全问题 根据 Kubernetes 文档，Secret 是 K8s 中存储所有敏感信息的对象。事实上，如果敏感信息直接存放于 K8s 的 Pod spec 或镜像中，不仅管控困难，而且存在较大的安全隐患。因此，K8s 通过创建、管理、应用 Secret 对象，可以更好地控制敏感信息的用途，并降低其意外暴露的风险。\n秦凯伦称，虽然引入 K8s Secret 对象，这在一定程度上降低了意外泄露的风险（更多地是通过集中式的管理），但是 K8s Secret 对象自身的安全性，“社区默认方案中仍存在许多安全问题”。\n一般来说，K8s 中，Secret 数据以纯文本的方式存储在 etcd 中，默认只有 base64 编码，未经加密。同时，共享该文件或将其检入代码库，密码容易泄露。\n社区解决方案的不足 针对此问题，K8s 社区提供了基于 KMS 的 K8s Secret 加密方案，谷歌云、AWS 和 Azure 均支持该方案。他说，“这虽然解决了 etcd 中 Secret 明文存储问题，但依然有一些问题。”\n Secret、加密 Secret 的密钥在内存中明文存放、易被攻破； 攻击者可以假冒合法用户，调用解密接口，窃取密钥； 密钥一旦泄露，将导致所有数据的泄露，从而引起用户对整个系统的信任崩溃。“为此，社区和一些公司尝试为该方案中的 Plugin 加上基于硬件的安全保护，从而提升攻击难度。但对某些特定用户来说，保护的覆盖面和程度依然不够”。\n实际上，我们可以从 K8s Secret 的整个生命周期来看：\n Secret 的生成及访问 Secret 的身份证书明文存放在用户侧内存中，用户侧环境复杂，容易被攻击者攻破； 加密 Secret 的密钥的生成、cache 等在 K8s API server 中明文存放在内存中，安全根易被窃取或破坏； 与 KMS 交互的 Plugin 的加解密接口无法防止攻击者假冒，存在泄漏风险； Secret 在 Node 中消费，依然明文内存存放，暴露出一定攻击面； 在秦凯伦看来，理想中，对 K8s 中 Secret 的保护程度应该考虑其整个生命周期的安全、可信，做到端到端的安全防护。\n蚂蚁集团的探索 为此，他们基于 TEE 技术，将 K8s Secret 整个生命周期和端到端使用过程中的关键组件、步骤保护起来。整体方案大致如下：\n 将 API Server 端与 KMS 交互的 KMS Plugin 用 TEE 保护，在保障了 Plugin 中根密钥（安全根）、数据加密密钥无泄漏风险的前提下，降低了性能开销； 将 API Server 端的 KMS provider 用 TEE 保护，避免数据密钥及 Secret 在任何时候明文直接暴露在内存中；同时，通过 TEE 的本地证明机制能够认证解密数据密钥接口的调用者，防止攻击者假冒，确保密钥的安全； 将用户端的 kubectl、kubeconfig 等使用 TEE 保护，一方面 kubeconfig 不落盘同时被硬件保护，提升了安全水位；另一方面，用户的 Secret 通过安全信道直通到 TEE 中进行处理，避免了直接暴露在内存中，规避了被恶意窃取的风险，且用户对 API Server 进行 TEE 远程证明，可以帮助用户确信他正在把自己的 Secret 托付给可信的软件实体（没有含有故意泄露用户秘密的恶意逻辑），建立对 API Server 的信任； 将 Node 端的 kubelet 中 Secret 的消费过程用 TEE 保护，进一步避免了 Secret直接暴露在内存中，规避了被恶意窃取的风险； 秦凯伦向 InfoQ 记者指出，“这种方案是基于 TEE 的端到端 K8s Secret 保护，还引入 LibOS 技术，实现 TEE 保护对用户、开发者和运维团队完全透明。”\n据悉，KMS Plugin 和 TEE-based KMS Plugin 没有标准和开源的社区实现，因此他们设计并开发了自己的 KMS Plugin，并在灰度发布、应急处理、监控管理等方面进行了生产增强。“在与 TEE 结合的过程中，我们为了应对 SGX 机型存在的性能问题，提供了 standalone 和服务化 KMS Plugin 两套方案”。\n同样，TEE-based kubectl 也没有标准和开源的社区实现，他说：“我们基于 kubeproxy 开发了自己的安全 kubectl，实现了 kubeconfig 对用户透明、与用户身份绑定、不落盘并采用TEE保护内存安全等设计目标。”\n此外，考虑到 TEE 保护的易用性、可靠性、可扩展性和可维护性等，他们在评估多套方案后，引入了由蚂蚁开源的 Occlum LibOS，屏蔽了 TEE 对用户、开发者和运维团队的影响，大大降低了 TEE 开发的门槛和成本。\n在秦凯伦看来，K8s 作为蚂蚁大规模容器集群的管控根基，应用基于 TEE 的端到端 K8s Secret 保护防护方案，增强了其自身安全和可信，提升了蚂蚁核心管控平面的安全水位，“这对于金融场景下高标准的数据安全和隐私保护来说不可或缺”。\nK8s 相关阅读 备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？ Kubernetes: 微内核的分布式操作系统 开箱即用的 Java Kubernetes Operator 运行时 深入Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统 深度 | 蚂蚁金服自动化运维大规模 Kubernetes 集群的实践之路 ","date":1597215600,"description":"K8s Secret 面临着哪些安全问题？这些安全问题会带来什么影响？社区提供的解决方案存在哪些不足？","dir":"blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"39e435e749635a88bce9e36771e5b2e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","publishdate":"2020-08-12T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","summary":"在 Kubernetes 中，Secret 显得尤其重要。因为它是 K8s 中存储所有敏感信息的对象。据悉，这些敏感信息包含密码、集群的证书、OAuth token、ssh key","tags":["Kubernetes"],"title":"蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？","type":"blog","url":"/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","wordcount":1958},{"author":"SOFA 团队","categories":"SOFAStack","content":" PS：阅读本文大约需要 15 分钟，或者您可以选择直接拉至文末投递简历，加入云上江湖。\n 有人说，历史是由懒汉推动的。\n科技的演进史，其实就是人类不断偷懒的过程。我们懒得浪费体力，于是有了蒸汽机；我们懒得动笔演算，于是有了电子计算机；我们懒得随身携带现钞，于是有了线上交易和无接触支付……程序和信息成为这个时代的基底，服务和应用围绕着我们的指尖打转。\n我们从网络上索取一切，海量的数据和代码在赛博空间里奔流不息。\n突然有一天，构筑代码世界的工人们也犯懒了。为首的“懒汉”开始思考，能不能把一些通用的代码模块打包起来，供给上层随时取用，这样就省下了重复“造轮子”的力气，让敲代码也成为一种模块化的工作？\n这一“偷懒”，就偷出了一个新概念：中间件。\n无人探索的道路 对普通人来说，“中间件”是一个很遥远的词汇。\n从技术层面来讲，中间件是介于基础设施和业务系统之间的特殊软件。程序员们别出心裁地构思了各种比喻：有人说它是建筑工地上的“预制件”，让工人不必从头开始搅拌水泥；有人说它是整合货源的“中间商”，让商家免于一次次询价比价的操劳……\n“基础设施和业务系统之间，有很多通信和集成方面的要求，让每个业务系统都去做一遍是很浪费人力的。”蚂蚁集团高级产品专家马振雄这么说，“大家都有这样的诉求。”\n时势造英雄，SOFAStack 在蚂蚁集团应运而生。\n它诞生得悄无声息，初衷只是为了“解救”支付宝。那还是青涩年代的支付宝，没有琳琅满目的蚂蚁森林、花呗和健康码，用4个“一”就能概括它的全部：一个简单的应用，装在一台应用服务器上，使用一个数据库，服务一个大客户——淘宝。\n简单、轻快、便捷，这个系统支撑了支付宝从2004年到2006年早期的发展。但是随着交易量的攀升、业务的复杂化，支付宝很快遭遇了成长中的阵痛。\n“从刚开始几十个人，后来几百人，到现在几千人的技术团队，在不同规模下的研发方式和组织方式都是不一样的。”蚂蚁集团高级技术专家黄挺说，“人一多，你发现不同的人写的代码会不一样，冲突也越来越多。”\n概而言之，研发效率出现了问题。\n如果说从前的支付宝是一间平房，如今则要发展成一座城市。而每搭建一座建筑，工人都必须从头开始烧制砖块、搅拌水泥——没有挖掘机，没有液压锤，一切从手无寸铁开始，对以“建设城市”为己任的团队来说，这是完全不可接受的。\n举个例子，当时支付宝的一个电子钱包系统 iWallet，每次启动需要五六分钟，足够开发人员下楼抽一支烟。如果发现错误，就得修改后重新启动，开发人员每天深陷在代码编译和重启的“死循环”之中。\n究其原因，就是因为 iWallet 系统包含了几十个工程，有十多个团队并行开发。支付宝原本的系统无法支撑这么复杂的业务逻辑，也难以让那么多工程师在一起并行工作，大家把它称为 monolithic——庞大的单体系统。\n支付宝的诉求显而易见：第一，希望成百上千个项目并行进行，每个工程师可以不受干扰地工作；第二，当业务逻辑增加的时候，系统的复杂度不要成指数级上升。 它需要一套能够力挽狂澜的“中间件”。\n2006年，契机来临。技术团队在这一年开了一连串的会，会议的核心议题只有一个：决定支付宝未来的技术架构。团队内部分成两派：第一派提议向银行老大哥学习，走集中式架构的老路；第二派则认为分布式架构才能支撑未来的交易支付系统，而且不是客户端/服务器时代那种小规模架构，是互联网时代的超大规模分布式架构。\n毫无疑问，这是一条无人探索过的道路。\n当然，你知道阿里人的秉性，退缩和守成从来不是他们的标签。经过长达一年左右的思考和论证，技术团队果断驶入第二条赛道。2007年起，支付宝率先启动了对交易系统、商户系统、会员系统、支付清算系统的改造，一个全新的架构正在孕育之中。\n这套分布式架构就叫“SOFA”。\n为什么叫这个名字？其一是源于当时正火的“SOA”概念，即 Service-Oriented Architecture，“面向服务的架构”，在此基础上加入金融业务，就构成了 SOFA 的全称：Service-Oriented Fabric Architecture。\n其二则是开发者的私心，“希望能够像沙发（Sofa）一样，让工程师可以非常爽地工作。” 从“连接器”到“工具库” 什么是 SOA？用偏技术的语言表述，就是把企业的 IT 系统以“服务”的方式重新组织，再通过“服务总线”连接起来，形成可插拔式的企业 IT 架构，这个架构就是 SOA。\n你或许觉得这个释义很难懂，没关系，因为在那个年代，SOA 纯粹只是一套面向传统企业 IT 架构的思想，换句话说，一套理论框架罢了。\n你问业界具体的成功实践？抱歉，没有。\n初次试水，蚂蚁的“探路者”们走得非常谨慎：第一代 SOFA 只解决两个问题，一是充当一个类似于“胶水”、“连接器”的机制，把分布式系统连接成整体；二是做到每一个服务组件化，让每个工程师专注做好各自的组件，最后把组件拼装在一起成为“服务”，再把“服务”拼装在一起组成整个系统。\n用黄挺的话来说，“SOFA 能够隔离出一些不同的模块，由不同的人去做开发，每个人有了更加细致的分工，不会跟别人出现太多的交叉。”\n第一代 SOFA 清晰地定义了团队之间的边界，何时分工协作，何时紧密联合，安排得明明白白。黄挺举了个例子：简单的一次转账业务，系统需要调用用户的通讯录，调用账务相关的子系统——可能还得去问银行，账户余额到底够不够？整个流程涉及到非常复杂的系统交互，这些由不同团队开发和运维的系统，怎样才能高效交互、稳定完成每一笔业务呢？这就仰赖 SOFA 从中协调和沟通了。\n燃眉之急解决了，但初生的分布式中间件 SOFA 并不能处理所有问题。它还需要打怪升级，积累经验，向下一代、再下一代演化。\n无人探索的道路上没有先驱者，只有野蛮生长的技术难题在横冲直撞。\n在 SOFA 的加持下，支付宝一边拆分金融业务系统（后来的业务中台）一边拆分底层 IT 系统（后来的数据中台和计算中台），在拆分过程中还要应对历年双十一的海量数据冲刷，以及不断涌现、千奇百怪的技术问题。甚至在解决分布式服务一致性问题时，由于业界提出的两个 SOA 事务标准都无法支撑支付宝核心系统的交易量，团队干脆一狠心一咬牙：现有的标准都不可行，要不我们自己提一个吧！\n逢山开路，遇水搭桥。很难说清 SOFA 这些年来的演进中，他们遭遇过多少类似的阻碍，又有多少奇思妙想和技术实践沉淀下来，最后凝练成 SOFA 内部的几行代码。\n他们在无人区设下哨塔，漫漫长夜被灯火点亮。\n第一代 SOFA，做到了模块化。\n第二代 SOFA，完成了服务化。\n第三代 SOFA 的亮点，则是被誉为“蚂蚁黑科技”的单元化，“异地多活”架构让服务器资源水平扩容的难度大大下降，保障了用户的每一笔订单平稳顺滑。团队坦诚，面向超大规模互联网金融交易的分布化改造，单元化这一技术构想完全是被业务倒逼的，业界没有先例可循。\n“我们找到过一些论文、一些概念，但以支付宝这么大的体量，没有人确定这事儿真的能做成。”团队成员感慨。\n就这样，随着支付宝架构的逐次优化，SOFA 也在不断迭代和成长。从最初仅是一个简单的框架，到后来强化通讯性能、提升容灾效率、建设异地容灾架构、单元化改造、添加 LDC 逻辑数据中心项目……SOFA 羽 …","date":1597042800,"description":"从初试锋芒到大展拳脚，从无人区的前哨到数字化转型的领航员，云上自有江湖，欢迎加入云上江湖","dir":"blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","fuzzywordcount":8900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dc1065f8e3a2e016a6fc8750bbfab2c2","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","publishdate":"2020-08-10T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","summary":"PS：阅读本文大约需要 15 分钟，或者您可以选择直接拉至文末投递简历，加入云上江湖。 有人说，历史是由懒汉推动的。 科技的演进史，其实就是人类不断偷","tags":["SOFAStack"],"title":"蚂蚁 SOFAStack：云上自有江湖","type":"blog","url":"/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","wordcount":8849},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@丁浪 提问：\n 这个跟 TCP 长链接的心跳没根本区别啊！也只能保证链路上的通畅，应用僵死或者苟延残喘了可能发现不了，可以补充从注册中心去主动探测 URL，反正现在 SpringBoot 和 SOFABoot 应用都可以开启 healthcheck 的 endpoint，为啥不从注册中心发探测请求，反正都有 healthcheck 的 endpoint。链路上的保活那只是基本生存需求，稍微高级一点就不行了，应用僵死或者苟延残喘那种可能还有心跳的。我看你们把这个问题交给 RPC 框架去做了，让 RPC 框架去做故障剔除和容错。 A：SOFARegistry 目前设计是比较依赖网络连接的，网络连接只要出发了断链事件（这个目前监听是靠 Netty 的事件通知过来的）就会进行数据清理，这个敏感性也决定了服务发现比较快，但是对于抖动和其他大面积不稳定情况处理确实显得不足。我们说的 RPC 框架剔除是对于经常性的链接不通地址采取自动降级不进行调用处理，至于 Spring 那种心跳检测机制，我们开始实现也考虑过，因为这个健康检查机制和网络断连触发的敏感性差别较大，健康检是定期轮训的可能确定服务下线没有这么快速发现，所以没有采用，后续也想过兼容两种模式解决这个断链处理，引入类似 ZK 那种 Session 过期等机制可以在快速发现和稳定性做一个取舍。\n 那种应用进程僵死、较长时间 fullgc 之类的，长链接心跳还在注册中心发现不了流量过来就有问题的，RPC 框架的剔除机制我个人认为只能是种兜底降级。我目前是结合 K8s 探针去请求应用的 healthcheck 路径的，K8s 健康检查不通过就会杀进程重启 Pod，这样注册中心也会感知到 RPC 流量也就剔了。\n SOFARegistry：https://github.com/sofastack/sofa-registry\n2、@倪美俭 提问：\n 这是 AT 模式，store:db，rollback 的交互图，麻烦帮忙瞅瞅有问题吗？ A：是的，一阶段都是提交的，二阶段如果是回滚就会把之前的本地 commit 回滚掉。\n 这种场景是否要优化下，直接发起二阶段回滚，就不再进行这个本地事务一阶段的提交呢？这里为什么会进入到本地事务的 commit 方法里，而不是 rollback 方法里呢？\n A：这种你把本地的事务注解加到全局事务注解下面就好了，这样发起方所在的本地事务是直接走 rollback，其余参与方才是二阶段决议通知下来。\n 强一致性需求的场景，Seata 里只能用 XA，但 XA 是依赖数据库本身对 XA 协议的支持来实现的，那是不是这种模式下性能上会比 LCN 要逊色一些呢？\n A：首先 LCN 的原理是通过 connection 的代理，使之做空提交，二阶段决议后，把 hold 住的 connection 进行真正的 commit 或者 rollback，然而这个方式的隔离性交由本地事务来实现，因为 connection 未提交，所以事务还未提交，强依赖了本地事务。其次除非你的服务不会宕机，否则不建议你使用 LCN 模式，因为如果在二阶段决议后，宕机了一个参与者，那么 LCN 是无法恢复之前的数据，导致数据丢失。\n而 XA 你可以认为他跟 LCN 也很像，但是 LCN 面对的是数据源连接，而 XA 你会发现这个才是由数据库真正意义上去支持的一个协议，即使宕机了，Seata XA 也是做了 XA 的预提交，持久化提交数据在数据库层面，但未真正提交，从而可达到宕机后重启也可以提交事务。\n这是我做在 Seata 中 LCN 原理实现的 PR：https://github.com/seata/seata/pull/2772 ，你可以阅读下，很容易发现他的缺陷，LCN 的性能高是基于啥也基本没干，就多了个几个 RPC 通信的消耗，无需解析 SQL，做镜像校验，全局锁解锁等操作，他仅仅只是把本地事务的提交延迟到其余的参与者都完成了业务并且没发生异常的情况下。看过这个 PR 或者 LCN 的源码后，你就会真正的理解为什么 LCN 说自己不产生事务，而是事务的协调者而已。\n 去年看过 LCN 的源码，它也是代理了数据库连接，在一阶段会 hold 住所有的数据库连接，并不真正提交，二阶段会全部一起提交或回滚，那么有参与者宕机的话不应该会全部回滚吗？\n A：因为是基于本地连接的回滚，连接断开会自动回滚，所以即使二阶段决议形成提交时，若应用或网络出问题，连接断开就自动回滚了，不能保证极端一致性。 Seata：https://github.com/seata/seata\n本周推荐阅读 少年五年升阿里 P8，他如何从低谷登上“光明顶”？ 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.15.0 版本，主要变更如下：\n 新增 UDP Listener 的支持； 新增配置扩展能力，Dubbo 服务发现可通过扩展配置扩展，支持 Yaml 格式的配置解析； 新增流量镜像功能的扩展实现； 支持了更多路由配置； Skywalking 升级到 0.5.0 版本； 针对 Upstream 与 XProtocol 进行了优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.15.0\n同时，恭喜邓茜（@dengqian）成为 MOSN Committer，感谢她为 MOSN 社区所做的贡献。\n2、发布 SOFARPC v5.7.5 版本，主要变更如下：\n 修复日志打印的问题； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.5\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题： …","date":1596783600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200807/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3ae77ff6536d0104b38d51679b7f078b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200807/","publishdate":"2020-08-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200807/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN \u0026 SOFARPC 发布、MOSN 社区活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200807/","wordcount":2576},{"author":"陈伟荣","categories":"智能监控","content":" 电影《太空旅客》里，无人驾驶的阿瓦隆号飞船去往家园2号要经历120年，飞船的顺利抵达必须依赖一套高端智能运维系统。在蚂蚁，技术风险部的智能监控就好比那个智能运维系统，而智能监控团队便是背后那群看不见的守护飞船的人。\n 2019年双十一的凌晨三四点，阿里西溪园区附近的某家网咖里门客冷清，只有几个神色淡定的青年小伙聚在一排座位上愉快地进行 DOTA 游戏， 他们时不时看一眼手机上发来的消息，像是在守着什么不敢掉以轻心，但脸上又流露出胜券在握的信心。\n就在几个小时前，这群看似“不务正业”的网咖少年还坐在阿里双十一最核心的作战室“光明顶”，与阿里众大佬高管一起值班，助力双十一决胜千里。\n他们正是蚂蚁集团技术风险部智能监控团队。\n对于阿里人来说，“光明顶之战”为每年大促中的巅峰一战，能够登上“光明顶”的非泰山北斗即拥有超强武功的高手。作为该团队主力之一的陈伟荣说，光明顶上各路阿里大神、大佬汇聚一堂，每年的双十一就是智能监控团队的“高光时刻”。\n从象牙塔走向“光明顶” 在蚂蚁技术大事记上，智能监控团队于2012年就曾被留名：首次实现秒级交易监控。之后，他们每隔一段时间就会有技术突破。2014年至2016年期间，蚂蚁监控就用一套 xflush 系列产品成功走出蚂蚁实现与阿里集团监控团队的合作，为当时的淘系赋能。之后的 sunfire 监控、新一代阿里集团网络监控与 IDC 监控均是在此基础上迭代而来，并且沿用至今。\n这期间，一位青涩少年正从象牙塔走向阿里。他就是陈伟荣，2015年以应届毕业生身份加入阿里监控团队成为一名工程师。\n和很多刚毕业的同学一样，陈伟荣对互联网公司的技术体系并不熟悉，彼时他眼中的监控团队更像是一个运维工具组，日常工作就是服务器上看看日志，看看 CPU、内存指标，再做下数据展现就完事了。相较于消息中间件、数据中间件、虚拟化、块存储等各种基础技术团队相比，初入职场的陈伟荣偶尔也会觉得智能监控好像并没有那么高端大气上档次。因此才刚工作几个月，他就判定自己在监控团队肯定呆不了多久就会转岗。\n但是随着进一步深入工作领域，他发现大家工作对标的是各类流式计算，加之团队重视底层引擎研发，在对计算框架和时序存储研究一番后，陈伟荣意识到团队在做的事一点都不比其他基础技术团队简单：这是一个非常典型的垂直领域大数据应用，技术和业务上都非常具有相当挑战性。\n在技术层面上，实时、稳定、低成本、高精度都是对监控的要求，这些约束条件做到一点两点不难，但是要同时做到，极难。但陈伟荣所在的团队就是落地了这样一个高度稳定，秒级延迟，PB 级吞吐的监控平台，他透露后面团队还将重点发力算法和智能化能力。\n2016年发生了很多让陈伟荣迄今难忘的事，有一些事情的影响至今存留。\n那年支付宝新春红包登上了央视春晚，春晚直播屏幕前是全国人民一双双充满期待的眼睛。对于春节红包项目组的技术同学来说自然是严阵以待、不允许有丝毫差池。入职仅半年的陈伟荣有幸和团队其他精兵强将一起加入项目组，承担实时数据计算部分的任务，他主动提出要做项目内相对复杂的内存缓存部分研发。\n但代码写出来后陈伟荣被师兄狠狠痛批了。本来对于自己的技术和工作态度都很有信心的陈伟荣看到师兄一边改 bug 一边骂、一副恨铁不成钢的架势，心中的底气彻底被击碎。\n此后，少年卸下傲气，行路时步步夯实。\n2016年的双十一如约而至，这是陈伟荣在监控团队的第二年，面孔依旧很新，但是双十一活动却已经迎来了第八年。恰逢又一年的光明顶之战，团队却正好缺位，陈伟荣主动挺身而出，承担起阿里16年双十一监控系统稳定性负责人的角色。\n那次双十一，陈伟荣首次挑大梁，最终拼尽全力不负众望完成任务。双十一交易巅峰来临的那十几分钟也成为陈伟荣至今回忆起来最难忘的一段时间。据后来公布的数据了解到，2016年的双十一支付宝支付峰值已达到12万笔/秒，全天交易量达十亿，但是没有一笔交易异常。\n“平时研发中只要我认定这个事情从长期，或者更高视角看能帮助到团队和用户，我就愿意去做一些非常危险的，甚至短期都看不到收益的研发工作，”陈伟荣说。\n2017年，陈伟荣从阿里集团转到了蚂蚁集团，随后逐步切入工作，带领着蚂蚁技术风险部监控技术中台，负责数据的采集链路和实时计算的架构，并在此基础上构筑监控的数据服务体系。猛将加持，蚂蚁监控团队持续发力，2018年后，他们便结合自身的定位和业务目标，重新审视监控这个领域，又推出了 Antmonitor 系列的监控产品，现已发展到了2.0版本。 五年升P8，回首依然是少年 十年前，高考在陈伟荣生命里落下帷幕。只不过这场尽力准备了三年的考试，结果并不如意。\n高考成绩出来后陈伟荣大失所望，比正常发挥时几乎掉了一个层次，最后被南开大学德语专业录取，几乎等同于被调剂。高考后的暑假，难以接受打击的陈伟荣一度靠游戏度日。在复读和将就之间纠结了很久后，最终他决定向前看，并开始着手调研和规划大学的学习计划，为转专业作准备。\n高考失意，大学时奋起直追，陈伟荣通过各种努力走出了一条独特的发展道路：从文科的德语专业到软件工程专业，期间还修了金融学学位。\n毕业前的校招季，不少互联网公司开始招实习生，陈伟荣把简历投递给了阿里。但那时他心里更想走的是继续出国深造的路，所以当年投的简历更多是无心插柳之举。\n经过几轮紧张的现场面试后，没想到第二天阿里面试官就电话通知陈伟荣面试通过了。人生就是这样不可预料，同期报名的同学中仅他一个临时起意投递简历的被录取了。来了阿里后，陈伟荣一下子被阿里技术体系的先进性吸引了，实习转正后，他便决定不再继续读书直接工作了。\n他不知道自己本科拼命几年扭转的人生方向是否正确，只携一身热血前往，不回头。\n从2015年加入阿里开始，陈伟荣一直在监控领域做事，但是工作范围逐渐放大，从最初采集 agent 研发到逐步深入理解整个数链路、开始掌握数据技术架构，到现在能带领团队推进技术架构演进，他不断挑战自己的极限。\n五年时间弹指一挥间，说起过去，陈伟荣的回忆里酸甜苦辣翻涌。但要说最开心的时刻，他觉得是今年年初完成 pontus2.0 项目研发并最终上线支撑业务监控场景这个事。这次的技术升级突破了先前的监控技术框架，真正统一了监控数据层模型为未来数据建设铺平了道路，大家一起攻克艰难让项目按时落地，过程中的不易最后都变成了开心的回忆。\n团队里同事们年龄相仿，组队打篮球或者去网吧开黑打 DOTA 成为大家最放松的时刻，或嬉笑怒骂，或相互扶持，抛去工作上的对接合作与依赖关系，他们可以聊天南地北，聊海阔天空……\n最近，有一件事让 92 年的陈伟荣比较开心，那就是他专门定制的电吉他终于到货了。\n原来，这位少年还是一位重金属音乐爱好者。说着，他给我发来一个 Arch Enemy 在 2016 年 wacken 音乐节现场的视频链接，还提醒我要关小声音听。\n“我去过两次这个乐队在上海的 live，还跟主唱的那个妹子击过掌。”\n我眼前浮现这样一幅画面：“光明顶”少年与 Arch Enemy 歌曲中那些真实直白歌词达成了共识——人生也要“不断突破，向死而生”。\n","date":1596438000,"description":"坐在光明顶的少年。","dir":"blog/five-years-to-ali-p8/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"80f2d7c63c3dfb1ee561e79745630a68","permalink":"https://sofastack.github.io/sofastack.tech/blog/five-years-to-ali-p8/","publishdate":"2020-08-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/five-years-to-ali-p8/","summary":"电影《太空旅客》里，无人驾驶的阿瓦隆号飞船去往家园2号要经历120年，飞船的顺利抵达必须依赖一套高端智能运维系统。在蚂蚁，技术风险部的智能监","tags":["智能监控"],"title":"少年五年升阿里 P8，他如何从低谷登上“光明顶”？","type":"blog","url":"/sofastack.tech/blog/five-years-to-ali-p8/","wordcount":2786},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@刘明 提问\n 请问，分支事务在回滚过程中，服务器宕机了，重新启动后，TC 如果发送过来的回滚请求，是否还能继续回滚？\n A：可以。\n 是使用 XA 模式的 Oracle 数据库，分支服务器即使宕机了，回滚日志还在 Oracle 上是么？\n A：是的，xa_prepare 在 DB 实现 XA 层面做了持久化，MySQL 要求 5.7.7+。\n 刚测试了下 Oracle 的，xid 就像一个字符串 key 一样，任何时候只要告诉 Oracled 对 xid 做 rollback 都可以成功。我以为需要在 start/end 同一个连接里才行，是我理解错了。\n A：lcn 才需要这样，xa 不需要一个连接，所以 lcn 那种宕机了数据就没了。\n LCN 没有了解，他难道不是基于数据库自带的 XA 实现的？\n A：lcn 是 lcn 框架的一个原理，就是通过 connection 来统一提交和回滚。\n 我是用 jdbc 直接操作 Oracle 测试的，用 Oracle 的 XAResource。 这个特性是数据库自带的？\n A：XA 协议本来就是由数据库方进行的支持。\n 使用 DatabaseSessionManager 去存储 globalsession，这个 lockAndExecute 方法没有 lock 的逻辑，多个进程在获取 global 会话做超时、重试提交等时，会有资源冲突吗？\n A：多个 TC 会出现资源争抢冲突，倒是不影响一致性。\n 多个 TC 会对同一个 XID 做 retryCommitingg 操作吧，2个 TC 会做2次，3个 TC 会做3次？\n A：是的，没有分布式任务调度。\n 2个事务分支，TC 在发起提交请求后，分支一正常提交，分支二网络波动没有收到提交请求。 这个时候 TC 会尝试重试提交。 如果一直重试失败，会因为全局事务 timeout 发起回滚请求吗？\n A：提交一阶段就是持久化了，不会影响。\n 但是全局事务会有个超时检查，超时的事务处理方式就是回滚，会不会这样？分支二的提交重试一直不能成功，最后global 会话超时的吧？这时候分支一已经 commit，再做 rollback 肯定不行了。\n A：二阶段结果已经出现了，已经决议好了的，二阶段的提交只不过是空提交而已，异步的。\n 二阶段 TC 成功发送 commit，RM 接收到了后，执行 XA 提交动作，这时候数据才真正可以看到，如果 RM 接收不到 commit 请求，他本地数据时没有提交的吧？\n A：XA 模式确实是这样的。\n 那参与者中有人收到 commit 请求了，有人没收到，最后 global 超时，是不是也没法回滚了？\n A：XA 一阶段只是做了预备数据的持久化，保持操作，并没有真正入库，等到 commit 的时候才会入库，每个模式2阶段都不一样。 Seata：https://github.com/seata/seata\n本周推荐阅读 Kata Containers 2.0 的进击之路 Kata Containers 创始人：安全容器导论 Kata创始人王旭：远程工作可以从开源中借鉴哪些经验？ SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.4.2 版本，主要变更如下：\n 修复 ServiceComponent 和 ReferenceComponent 的健康检查结果不包含抛出的内部异常； 修复默认情况下 SOFA runtime 忽略组件抛出的内部异常； 增加引流操作的阻断性，fail fast； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.2\n2、发布 SOFAJRaft v1.3.4 版本，主要变更如下：\n 升级 SOFABolt 到 1.6.2（支持异步非阻塞建连机制）； 移除对 log4j 的直接依赖； RouteTable、RegionEngine、StoreEngine 实现 Describer 以提供更详细的调试信息； 修复 snapshot 文件创建漏洞，禁止跳出 snapshot 目录之外创建文件； 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.4\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题：云原生网络代理 MOSN 的进化之路 分享嘉宾：王发康（毅松）蚂蚁集团 可信原生技术部 技术专家 背景介绍：网络通信代理 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，增强 MOSN 服务治理及流量控制能力，对接云原生周边组件，实现 MOSN 开箱即用，MOSN 成为云原生 Service Mesh 的标准 Sidecar 之一，从而借力开源，反哺开源。 听众收益：可快速基于 MOSN 和 Istio 进行 Service Mesh 实践，了解微服务的发展历程、遇到的痛点以及解决方案，获取 MOSN 的功能特性，解决微服务常见的问题。 分享时间：2020-08-15 13:30-14:30 活动地点：深圳 活动报名：点击“这里” ","date":1596178800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200731/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ba067c1a03b386adff832962bb27dd52","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200731/","publishdate":"2020-07-31T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200731/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 以及 SOFABoot 发布、MOSN 社区活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200731/","wordcount":1941},{"author":"李昊阳","categories":"Kata Containers","content":" Kata Containers 开源项目于2017年底正式启动，其目标是将虚拟机（VM）的安全优势与容器的高速及可管理性相结合，为用户带来出色的容器解决方案。该项目在过去两年取得了哪些进展？下一版本的路线图包含什么特性？首先让我们快速回顾一下 Kata Containers 项目的奋进之路… 缘起：Kata Containers 2013 年，Docker 问世，容器成为热门新事物，全球的开发者为之着迷。也难怪，容器以标准格式封装，将运行于标准操作系统环境上的应用打包，使应用程序可从一个计算环境快速可靠的切换至另一个计算环境，这对于那些想要快速构建、测试和部署软件的开发者而言至关重要。容器具有轻量化、低开销的特性，几乎可以立即被调度和启动，可在任何环境中运行，为微服务提供便利，扩展资源等（以上仅列举了一些流行的优势）。 尽管有许多技术优势，但容器有一个缺点 - 容器与宿主机共享内核，这可能会引发严重的安全漏洞问题。理论上，如果您在单个主机上部署了多个容器，一旦其中某个容器被恶意代码利用，由于共享namespace，该主机上的其他所有容器也容易受到攻击，在这种情况下，可能会对云基础设施整体构成严重的安全威胁。如果您是云供应商，安全威胁可能会扩展到云端客户的数据和业务，这是绝对要避免的。\n图1. 传统容器：主要通过共享内核的 Cgroup 和 Namespace 来达到容器隔离和资源限制的目的\n因此，许多负责大规模容器运行的运维人员将容器“嵌套”在虚拟机中，从逻辑上将其与运行在同一主机上的其他进程隔离开，但在虚拟机中运行容器会丧失容器的速度和敏捷性优势。Intel 和 Hyper.sh（已加入蚂蚁集团）的开发人员意识到了这个问题，同时开始独立研发解决方案，两家公司都希望容器可以摆脱传统虚机的所有包袱，换言之，就是开发“面向云原生的虚拟化”技术：\n 来自 Intel 开源技术中心的工程师在 Intel Clear Containers 项目中运用 Intel Virtualization Technology（Intel VT）技术来强化性能和安全隔离； 与此同时，Hyper.sh 的工程师采用相似的策略启动了开源项目 runV，将容器放在一个安全“沙箱”中，通过支持多种 CPU 架构和管理程序，侧重于开发技术中立的解决方案； 2017年，两家公司将项目合并，互为补充，创建了开源项目 Kata Containers。Intel 和 Hyper.sh 联合开发者社区，希望在各方的共同努力下，兼顾性能和兼容性，在为终端用户提供出色应用体验的同时，加速开发新的功能特性以满足未来新兴用例的需求。Kata Containers 成为 OpenStack 基金会（OSF）除 OpenStack 之外的首个托管项目，该项目于2017年12月在北美 KubeCon 上正式公开亮相，社区座右铭是“快如容器，稳似虚机”。 其实质是，通过 Kata Containers 让每个容器/pod 采用其单独的内核，运行在一个轻量级的虚拟机中。由于每个容器/pod 现在都运行在专属虚拟机中，恶意代码无法再利用共享内核来访问邻近的容器，因此，容器即服务(CaaS)供应商能够更安全的提供在裸金属上运行容器的服务。由于容器之间的硬件隔离，Kata Containers 允许互不信任的租户，甚至生产应用及未经认证的生产应用程序都能在同一集群内安全运行。\n图2. Kata Containers: 每个容器/pod 被隔离在各自的轻量级虚拟机中\n因此，Kata Containers 与容器一样轻便快捷，并且可与容器生态系统无缝集成（包括流行的编排工具，如 Docker 和 Kubernetes），同时还具有虚拟机的安全优势。\n社区进展 Kata Containers 项目成立的第一年，社区主要致力于合并 Intel 及 Hyper.sh 的代码，并在全球的行业活动中介绍该项目独特的硬件隔离方案，这是其他容器运行时所缺乏的功能，同时也邀请了大量的社区开发者共同推进该项目。 Kata Containers 社区如今已经拥有众多的贡献者和支持者，包括来自九州云、阿里巴巴、AMD、AWS、百度、Canonical、中国移动、CityNetwork、戴尔易安信、易捷行云、烽火通信、谷歌、华为、IBM、微软、红帽、SUSE、腾讯、同方有云、中兴、英伟达、Mirantis、NetApp、PackageCloud、Packet、Vexxhost 等许多有影响力公司的开发者。随着社区的不断壮大，该项目正在稳步发展中。 社区成就包括：\n 加入开放容器倡议（OCI）规范，Kata Containers 社区持续与 OCI 和 Kubernetes 社区紧密合作，并在 AWS、Azure、GCP 和 OpenStack 公有云环境以及所有主要 Linux 发行版中对 Kata Containers 进行定期测试； 添加了对主要架构的支持，除 x86_64 外，还包括 AMD64，ARM，IBM p- 系列和 IBM z- 系列等架构； 无缝集成上游 Kubernetes 生态系统，Kata Containers 现在可以立即连接到大多数开箱即用的 Kubernetes 网络； 删除不必要的间接层，社区已经去掉了 kata-proxy 组件，并在 KubernetesSIG-Node 开发者和 containerd 社区的帮助下引入了 shim-v2，从而减少了 Kata Containers 辅助进程的数量； 降低开销，提升速度，社区正努力提升启动速度，减少内存消耗，并朝着创建（几乎）“零开销”沙箱技术的目标迈进。为此引入多个虚拟机管理程序，包括 QEMU，QEMU-lite，NEMU和AWSFirecracker。还与 containerd 项目整合，推动建立了 rust-vmm 项目，2019年，社区用 Rust 重写了一个沙箱内的 agent，显著减少了匿名页。总之，社区正通过一系列的改进工作来最大限度地减少开销，通过引入 FirecrackerVMM 将内存开销减少到 10MB，而通过 rust-agent 的合并将 agent 的匿名页从10MB减少到1.1MB； “面向云原生的虚拟化”，与面向虚拟机领域不同，容器领域是以应用为中心的，为了解决这种差异，社区引入了 virtio-vsock 和 virtio-fs，后续将引入更灵活的内存弹性技术virtio-mem； 如需详细了解项目进展，可查看王旭的系列博客：KataContainers: 两年而立 百度智能云的 Kata Containers 应用实践 百度，中国领先的搜索引擎运营商，全球最大的中文网站托管商，全球领先的 AI 公司-正在其百度智能云中大规模（超过 43k CPU 内核！）应用 Kata Containers，包括百度智能云函数计算（CFC）、百度智能云容器实例（BCI）、百度边缘计算等多种实践场景。 百度智能云是百度面向企业和开发人员的智能云计算平台，致力于为各行各业的企业提供一体化的人工智能、大数据和云计算服务。根据 Synergy Research Group 发布 …","date":1595919600,"description":"Kata Containers 项目的奋进之路","dir":"blog/kata-container-2.0-road-to-attack/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2eaaa668460266fb66b2b44f5611c472","permalink":"https://sofastack.github.io/sofastack.tech/blog/kata-container-2.0-road-to-attack/","publishdate":"2020-07-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/kata-container-2.0-road-to-attack/","summary":"Kata Containers 开源项目于2017年底正式启动，其目标是将虚拟机（VM）的安全优势与容器的高速及可管理性相结合，为用户带来出色的容器解决方案。该项目在过","tags":["Kata Containers"],"title":"Kata Containers 2.0 的进击之路","type":"blog","url":"/sofastack.tech/blog/kata-container-2.0-road-to-attack/","wordcount":4042},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网https://www.sofastack.tech SOFAStack:https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@Zhengguang 提问：\n 想问下，默认的 RMClient.init(applicationId, txServiceGroup); 这个方式启动 RM 的时候有个问题，它传递的 resourceId 为 null 也就是说 RM 初始化的时候虽然在 TC 注册了，但是注册的信并非之前断开始后那个 resourceId，所以 RM 重启后并不会立即收到来自 TC 的 retry。 以下是日志，可以看到默认 RM 初始化的时候 resourceIds 是空的： [timeoutChecker_2] INFO io.seata.core.rpc.netty.NettyPoolableFactory - NettyPool create channel to transactionRole:RMROLE,address:127.0.0.1:8091,msg:\u0026amp;lt; RegisterRMRequest{resourceIds=\u0026amp;lsquo;null\u0026amp;rsquo;, applicationId=\u0026amp;lsquo;api\u0026amp;rsquo;, transactionServiceGroup=\u0026amp;lsquo;my_test_tx_group\u0026amp;rsquo;} \u0026amp;gt;\n使用 API 方式，跑的是 seata-sample-api 这个 demo，AT 模式。\n A：1.其实 RMClient.init 的时候，并不会进行注册，真正进行注册的是初始化 DataSourceProxy的 时候。 2.如果注册的时候 resourceIds=\u0026amp;lsquo;null\u0026amp;rsquo;，很有可能你的 DataSourceProxy 没有初始化，也即是数据源没代理成功。\n 是的我观察到的就是这个现象，我这边项目更希望在 API 模式下使用 Seata，所以并没有通过 spring 启动，可能 DataSourceProxy 没有自动初始化，所以这里是不是应该有什么方式可以手动触发 DataSourceProxy 初始化的过程。\n A：手动配置一样就可以了，像这样子：\n\u0026amp;lt;bean id=\u0026amp;quot;dataSourceProxy\u0026amp;quot; class=\u0026amp;quot;io.seata.rm.datasource.DataSourceProxy\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;constructor-arg ref=\u0026amp;quot;dataSource\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; 哦哦，所以我要在 RMClient.init 启动后，马上手动获取一次 DataSourceProxy。Demo 中的这个 DataSourceUtil 要在第一次 getDataSource 的时候才会初始化 proxy，所以我要在 RMClient.init 启动后马上 get 一次数据源就好了， 测试通过。\n Seata：https://github.com/seata/seata\n本周推荐阅读 基于 MOSN 和 Istio Service Mesh 的服务治理实践 再启程，Service Mesh 前路虽长，尤可期许 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 SOFA 项目进展 本周发布详情如下：\n发布 SOFABolt v1.6.2 版本，主要变更如下：\n 支持检查连接并异步创建连接； 支持用户设置 UserProcessor 的 ClassLoader； 修复 URL 对象默认连接数为0导致不创建连接的问题； 修复无可用连接的 ConnectionPool 无法被回收的问题； 详细发布报告：https://github.com/sofastack/sofa-bolt/releases/tag/v1.6.2\n社区活动报名 机密计算（Confidential Computig）是近年来发展迅速的一种安全技术，它利用可信执行环境（TEE）——如 Intel SGX——来保证内存数据始终处于加密状态，因而将安全性提高到前所未有的程度，并赋能了诸多新型应用场景，比如多方联合数据分析、隐私保护的机器学习、保证机密性的区块链合约等等。虽然技术本身令人兴奋，但机密计算对应用开发者有比较高的门槛，令人望而却步。\n针对上面的问题，蚂蚁集团开源了 Occlum 项目，一款使用 Rust 语言开发的、面向机密计算的 TEE OS，可使得任何语言的任何应用程序轻松地移植进 TEE 环境。本次分享既会从用户角度介绍如何使用 Occlum 的轻松开发机密计算应用，也会从技术角度分享 Occlum 技术架构和特色。\nOcclum 网站：https://occlum.io\nOcclum Github：https://github.com/occlum/occlum\n本期主题：《SOFAChannel#18：零门槛的机密计算：Occlum LibOS 使用入门和技术揭秘》\n分享嘉宾：田洪亮（花名：樱桃） 蚂蚁集团技术专家 Occlum 开源负责人\n你将收获：\n 了解机密计算领域的最新进展； 了解 Occlum 的技术架构； 了解使用 Rust 语言开发安全软件的一手经验； 了解如何将创新工作转化为实用系统； 直播时间：2020-07-30 19:00-20:00\n报名方式：点击“这里”，即可报名\n","date":1595574000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200724/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6efe8af3dfb578bdfd495367e78b60e4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200724/","publishdate":"2020-07-24T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200724/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt 发布新版本、MOSN 相关文章整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200724/","wordcount":1603},{"author":"姚昌宇","categories":"Service Mesh","content":" Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。\n 本文根据7月22日晚 Service Mesh Webinar#2 有米科技高级后端工程师、MOSN Committer 姚昌宇，线上主题分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》整理，文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 大家好, 欢迎大家参加第二期 Service Mesh Webinar。本期的分享主题是《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。我是今天的分享嘉宾姚昌宇，来自有米科技，目前在公司也是负责服务治理相关的工作，我本身也是一名云原生爱好者，在空余时间关注和参与 Service Mesh 社区，最近参与了 MOSN 新版本的开发，也是有了很多收获。这次受社区邀请来给大家做这次分享，希望能给大家带来收获。\n今天的分享将从以下几个方面进行：\n 第一部分会简单介绍一下什么是 Service Mesh、Service Mesh 可以给我们带来什么红利以及我参与社区的过程和一些收获； 第二部分是这次分享的重点，我会从一个开发者的角度，说说如何基于 MOSN 和 Istio 去做服务治理，中间会包括 MOSN 源码的分析和 Istio 功能的实操，也是比较多 Service Mesh 爱好者关注的如何落地的问题，比如流量的控制啊、服务监控等等的功能； 第三部分会总结一下今天的分享以及 MOSN 一些近况和未来愿景的介绍； Service Mesh 简介以及社区共建实践分享 Service Mesh 简介 首先，什么是 Service Mesh 呢？相信这是众多爱好者刚接触 Service Mesh 时的最初疑问。Service Mesh 发展了这么多年，网上介绍和分析的文章也是很多，在这里我也再啰嗦一句。如果用一句话来概括 Service Mesh，我会说，它是一种微服务的通信方案，是不断演进而成的。\n大家都知道，服务端架构经历了一系列的演进，从最开始的单体服务到 SOA，再到微服务，服务间通信也从最开始的无需通信、到集成在代码里、再到胖客户端库，再演进为 Service Mesh 的 network stub 模式，又或者称为 sidecar 模式。\nService Mesh 主要解决了之前的服务间通信方案的几个问题：\n 语言绑定； 升级困难； 重复开发、标准不一； 语言绑定：在将服务治理逻辑抽离到 Sidecar 之前，这些治理逻辑需要集成在代码里面。这就容易导致业务要么要绑死在同一种开发语言上，要么就要相同的逻辑不同语言维护多份。这样既不灵活，维护起来成本也比较大。\n升级困难：企业里的基础设施团队，在升级服务治理逻辑之后，需要推动各个业务去重启他们的服务，这样一个周期通常会拖的非常长，重启过程也会有各种问题，导致线上各个版本的治理功能不一致，落地起来相当费劲。\n重复开发、标准不一：每个公司都会根据他们的实际情况落地微服务，有的会使用各个语言比较成熟的微服务框架，比如 Java 的 Spring Cloud、Dubbo；或者 Golang 的 go-micro 之类的框架。有的团队或者会使用集成组件的方式，在各个语言的基础上，加上一些成熟的服务治理组件，比如 Consul、Zookeeper、Hytrix、Vault 等。通常，通过对接这些组件来抽象出一个类似于微服务控制平面需要一定的开发成本，而且这些框架和组件标准也是不一致的，维护起来也会有不少成本。\n那么，Service Mesh 是如何解决这些问题的呢？\n首先，Service Mesh 架构将服务治理的逻辑抽离到一个单独的 Sidecar 进程中，而 Sidecar 进程是与语言无关的。Sidecar 通过代理的形式劫持业务进程的流量，从而做到与具体的业务开发语言解耦。\n其次，Sidecar 通过边车模式和业务进程部署在一起，但是又与业务进程分离。Sidecar 进程可以随时重启更新，业务进程无需感知这个过程。这样可以加速治理逻辑更新换代的过程，解决了传统服务治理，升级困难的问题。\n最后，Service Mesh 定义了控制面和数据面的概念。控制面提供 UI 给操作者去控制整个集群的流量，数据面，顾名思义就是数据流动的平面，负责接收这些配置信息，表现出对应的代理行为。控制面和数据面通过统一的协议进行通信，也就是 Service Mesh 里的 xDS 协议来交换配置信息。通过这样的方式，理论上实现了 xDS 协议的控制面/数据面可以互相插拔替换，这就统一了标准，解决了第三点重复开发和标准不一的问题。\n社区共建经历分享 那了这么多，那我是如何从关注 Service Mesh 社区，到参与到 MOSN 开源共建的呢？觉得整个过程可以概括成3点：\n 找到组织； 知识积累； 参与贡献； 其实一开始我也是一个初学者，刚接触到 Service Mesh 也会被一大堆不知名的名词砸得晕头转向的，像是 xDS、控制面、metrics tracing 之类的名词。所幸的是，ServiceMesher 的中文社区相当完善和活跃。我相信有了解过 Service mesh 的同学，肯定有加过2个微信 \u0026amp;ndash; 一个就是宋净超宋大的微信，一个就是 ServiceMesher 社区的微信群。也是得益于众多的前辈将 ServiceMesher 中文社区维护的这么好，将各种内部实践分享出去，以及外部一手资讯搬运甚至翻译过来，乃至是这样子的不定期的线上线下分享。这些都是非常好的资源。只要你想去学，就肯定有方法的。而对于新人的疑问，社区里的大神们也是非常乐意解答。\n既然有了目标和资源，那就差去做了。接下来我通过不断的去理解这些新领域的概念，理解它们的含义和背后的设计目的以及应用场景，再加上源码分析和动手实践，慢慢也就搭建起了整个关于 Service Mesh 的知识体系。\n在摸清门道之后，其实参与开发也不是什么难事了。那为什么我会选择 MOSN 呢？其实蚂蚁集团有整个 SOFAStack，也就是金融级云原生架构的开源共建计划，其中有服务注册、流量跟踪、rpc 协议、分布式事务等等的项目。我选择 MOSN 主要是有两点考虑：\n 第一是 MOSN 是使用 Golang 实现的，这一点和个人的技术栈比较吻合； 那第二点，我认为 Sidecar 在 Mesh 的位置是比较关键的。在大型的集群里，上百万的 Sidecar 在集群里互相通信，为业务进程转发处理数据包，其稳定性、性能要求和灵活性都是比较高的； 近期我也参与到了 MOSN 的 Istio Roadmap 开发中，主要目标是将 MOSN无 缝地接入到 Istio 里，成为在里面可以工作的 Sidecar。我主要做的几个功能是pilot-agent 的适配以及一致性哈希负载均衡功能的开发。其实和做业务需求是类似的，首先要知道功能要达到什么目的，然后预演改动的地方，最后实践：fork 一份 MOSN、开发 …","date":1595498400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/mosn-istio-service-mesh/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"03b066886bc7e069eca5654ee35e4782","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-istio-service-mesh/","publishdate":"2020-07-23T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/mosn-istio-service-mesh/","summary":"Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。 本文根据7月22日晚 Service Mesh Webinar#2 有米科技高级后端","tags":["Service Mesh","MOSN"],"title":"基于 MOSN 和 Istio Service Mesh 的服务治理实践","type":"blog","url":"/sofastack.tech/blog/mosn-istio-service-mesh/","wordcount":4565},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@古月 提问：\n 请问 SOFARPC 可以在 Spring MVC 环境 XML 配置使用?老项目 ssm，非 Spring Boot 环境。\n A：可以的。和直接用 SOFARPC 没区别。 SOFARPC 相关 Demo：https://www.sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@伍月 提问：\n 工程使用 OperatingSystemMXBean（osBean）类对系统 CPU 情况进行监控。 osBean.getSystemCpuLoad() = -1 ？？？ osBean.getProcessCpuLoad() = -1 ？？？ 有没有人知道是怎么回事。 注：正常情况下 CPU 返回值在 0 到 1 之间。\n A：抛出异常的时候会返回 -1，之前记得 arthas 也会返回 -1。\n 感谢回答。 工程在 Linux 服务器上运行时获取 CPU 数据正常。只是在本地 Windows 上运行时获取 CPU 数据返回 -1。后来百度得知可能由于本地 Windows 用户没有获取系统 CPU 数据的权限。\n Seata：https://github.com/seata/seata\n本周推荐阅读 我们需要什么样的端到端 AI 系统？蚂蚁 SQLFlow 的思考与答案 火了 2 年的服务网格究竟给微服务带来了什么？ Kubernetes: 微内核的分布式操作系统 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.7.4版本，主要变更如下：\n 允许用户设置 Triple 服务的版本； protobuf 编译器升级到 0.0.2； hibernate-validator 升级到 5.3.5.Final； jackson-databind 升级到 2.9.10.5； 修复了 Hessian over triple 不支持基本类型的问题； 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.4\n2、发布 Seata v1.3.0 版本，主要变更如下：\n AT 模式支持了像多主键，自动升降级，redis 存储等大量 feature； TCC 模式支持了模式支持 Dubbo 和 SOFARPC 注解调用； Saga 模式支持 Groovy 脚本任务、支持 jackson 序列化、代码重构将内部扩展点 SPI 化； 整体性能得到大幅度提升，修复了旧版本的存量 bug； 本次 release 变动文件数：442，代码变动：+17062 −8419，参与代码 commit 人数：31，合并 PR 数：90，其中：feature：20，bugfix：29，代码优化重构：41； 详细发布报告：https://github.com/seata/seata/releases/tag/v1.3.0\n社区活动报名 Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#2，邀请有米科技高级后端工程师姚昌宇，带来分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。本期分享可以收获对 Service Mesh 技术以及如何落地有更多的认识。\n分享主题：基于 MOSN 和 Istio Service Mesh 的服务治理实践\n分享嘉宾：姚昌宇 有米科技高级后端工程师、MOSN committer\n你将收获：\n 了解如何参与到 MOSN 开源社区共建中； 了解如何使用 MOSN 在 Istio 场景下的服务治理实践 ; 了解 MOSN 新版本的功能以及未来远景； 结合 Istio 各个场景的 Demo，分享 MSON 的多协议/私有协议实现； 直播时间：2020-07-22 20:00-21:00\n直播间地址：关注直播间，7月22日不见不散\n","date":1594969200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200717/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"54ea1b69911fe82c9674739a421a0ce5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200717/","publishdate":"2020-07-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200717/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC、Seata 组件发布以及社区 QA 整理、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200717/","wordcount":1475},{"author":"沈凋墨","categories":"Kubernetes","content":" 如今，Kubernetes 已经成为分布式集群管理系统和公有云/私有云的事实标准。实际上，Kubernetes 是一个分布式操作系统，它是 Google 在分布式操作系统领域十余年工程经验和智慧的结晶，而 Google 一直以来都管理着世界上最大的分布式集群，在分布式操作系统领域的研究和认识领先于全世界。因此，2014年发布的 Kubernetes 能在短短几年时间内就超越了诸多前辈，大获成功。\n作为分布式操作系统，Kubernetes（包括其前代产品 Google Borg）的出现远远晚于 UNIX、Linux、Windows 等著名的单机操作系统，Kubernetes 架构设计自然地继承了很多单机操作系统的珍贵遗产，微内核架构就是这些遗产中最重要的一份。在本文接下来的部分，我们将专注于微内核（microkernel）这个概念及其对 Kubernetes 架构的影响。\n什么是微内核？ 在介绍微内核的时候，我们有必要同时回顾一下单机操作系统的历史，以理解其价值所在。本章中以「操作系统」指代「单机操作系统」。\nUNIX 的兴起 电子计算机诞生之后，在上个世纪70年代以前，出现过许许多多的操作系统，DOS、OS/360、Multics 是其中的知名代表，这是操作系统领域的拓荒时代。20年来的拓荒孕育出了伟大的成果：随着 CPU 技术的发展，UNIX 于1969年诞生了，这是一个真正意义上的分时操作系统。\n图片来源：维基百科\n借助新的 CPU 技术的支持，UNIX 将软件系统划分为内核（kernel）和用户态程序（userland programs）两部分。内核是一组中断处理程序的集合，把硬件的能力封装为操作系统功能调用（system calls），用户态程序通过系统调用使用硬件功能，用户态程序运行于各自的进程中，所有用户态进程都共享同一个内核，每当系统调用或中断发生，UNIX 便陷入（trap）内核，内核执行系统调用，与此同时，内核中的分时调度算法将决定把 CPU 交给哪个进程，并管理进程的上下文切换。另外，UNIX 把（几乎）所有硬件都封装为文件。UNIX 还提供了一个特殊的用户态程序 shell，供用户直接使用系统，通过内核提供的进程间通信能力，shell让 用户可以把一系列应用程序组合起来，处理复杂的需求，作者称这个设计思想为「KISS」（Keep It Simple and Stupld）。UNIX 的所有设计思想在当时是都是非常了不起的创举。\nUNIX 不但自身对业界产生了巨大的直接贡献，还成为所有现代操作系统的蓝本，两位作者 Ken Tompson 和 Dennis Ritchie 因此荣获1983年度的图灵奖。\nUNIX 诞生于贝尔实验室，该实验室属于美国国家电信电报公司（AT\u0026amp;amp;T），见识到 UNIX 的强大威力之后，AT\u0026amp;amp;T 做出了一个看似无私的决定：将 UNIX 开源（初期只对大学开源），这使得所有现代操作系统得以诞生。虽然 AT\u0026amp;amp;T 最终被分拆，辉煌不再，但这个决定对人们的贡献绵延至今。在21世纪20年代的今天，无论是 MacOS、Windows、Linux，都直接受到 UNIX 的影响，而 iOS 来自 MacOS，Android 来自 Linux，因此 UNIX 的灵魂仍然活在每个人的手机中、活在每个手机 App 后台的服务中。\n此外，UNIX 诞生之时，还附送了一项比操作系统本身价值更大的副产品：Dennis Ritchie 为开发 UNIX 设计了C语言，C语言成为了所有流行的现代编程语言的主要设计来源，不仅如此，C语言在其诞生近40年后的今天，仍然是最重要的编程语言之一。\n值得一提的是，当时 UNIX 的主要开放对象是伯克利、卡内基梅隆等研究型大学，文理学院规模较小，没有研究生项目，不属于 AT\u0026amp;amp;T 的主要开放目标，因此 Olivet College 毕业的一位小哥未受到 UNIX 思潮的影响。这位名叫 David Cutler 的软件天才于1975年在 DEC 设计了 VMS 操作系统，VMS 和最初的 UNIX 一样，运行在 PDP-11 上，但并不是基于 UNIX，而是独立设计的。VMS 在业界没有掀起大浪，以兼容 UNIX 告终。后来 David Cutler 离开 DEC，加入微软，在那里谱写了属于他自己的传奇。有趣的是，乔布斯也曾在文理学院就读，看来美国文理学院的学生是不走寻常路的。\n微内核的兴起 UNIX「一切皆文件」的设计带来了用户程序设计的很多便利，但它要求所有对硬件的封装都要在内核态，因此内核中模块的 bug 会让整个系统受到影响，比如说，如果某个设备驱动有内存泄漏，所有使用该设备的用户态进程都会有内存泄漏，如果某个内核模块有安全漏洞，整个系统的安全性将不再可控。\n为了解决这类问题，上个世纪70年代，操作系统研究者们开始发展「微内核」的概念，微内核的本质是让操作系统的内核态只保留内存地址管理、线程管理和进程间通讯（IPC）这些基本功能，而把其它功能如文件系统、设备驱动、网络协议栈、GUI 系统等都作为单独的服务，这类服务一般是单独的用户态 daemon 进程。\n用户态应用程序通过 IPC 访问这些服务，从而访问操作系统的全部功能，如此一来，需要陷入内核的系统调用数量将大大减少，系统的模块化更加清晰。同时系统更加健壮，只有内核中的少量系统调用才有权限访问硬件的全部能力，如设备驱动的问题只会影响对应服务，而不是影响整个系统。和 micro kernel 相对，UNIX 的设计被称为 monolithic kernel。\nUNIX 开放后，AT\u0026amp;amp;T 继续着版本迭代，而各大学基于 AT\u0026amp;amp;T 的 UNIX 开发了很多新的操作系统内核，其中较为知名的有：\n BSD，monolithic，由伯克利的传奇人物 Bill Joy 于1974年发布（据说 Bill Joy 花三天便完成了 BSD 内核的第一个版本开发，Bill Joy 的作品还包含第一个 TCP/IP 协议栈、vi、Solaris、SPARK 芯片等等）。该内核对业界影响非常之大，后来发展为 FreeBSD、OpenBSD、NetBSD 等分支。现代操作系统如 Solaris、MacOS X、Windows NT 对其多有借鉴。 Mach，微内核，由卡内基梅隆大学于1984年发布，主要作者是 CMU 的两位研究生 Avie Tevanian 和 Rick Rashid。该内核对业界影响也很大，GNU Hurd、MacOS X 对其多有借鉴，但该项目本身以失败告终。 MINIX，微内核，由阿姆斯特丹自由大学（Vrije Universiteit Amsterdam）的 Andrew Tanenbaum 教授于1987年发布。无数计算机系学生通过 MINIX 及其配套教材掌握了操作系统的设计原理，Linux 的初始版本就是基于 MINIX 复刻的。MINIX 虽然著名，但主要用于教学，从未在工业界获得一席之地。 微内核的沉寂 从上世纪90年代至本世纪10年代，UNIX 和 VMS 的后裔们展开了一场混战，从结果来看，微内核的概念虽然美好，但现实非常 …","date":1594882800,"description":"本文将专注于微内核（microkernel）这个概念及其对 Kubernetes 架构的影响分享。","dir":"blog/microkernel-distributed-operating-system-kubernetes/","fuzzywordcount":7100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9fc5956b0fc0551dfdcf50df35ee8a84","permalink":"https://sofastack.github.io/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","publishdate":"2020-07-16T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","summary":"如今，Kubernetes 已经成为分布式集群管理系统和公有云/私有云的事实标准。实际上，Kubernetes 是一个分布式操作系统，它是 Google 在分","tags":["Kubernetes"],"title":"Kubernetes: 微内核的分布式操作系统","type":"blog","url":"/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","wordcount":7097},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践\n 活动时间：7 月 22 日周四晚 8 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 Service Mesh Webinar Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#2 Service Mesh Webinar#2，邀请有米科技高级后端工程师姚昌宇，带来分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。\n本期嘉宾将为大家分享从关注 ServiceMesher 社区，到参与 MOSN 开源共建的心路历程，包括 Service Mesh 技术的相关介绍、如何参与社区共建以及如何将 MOSN 结合 Istio 根据实际场景落地的示范。本期分享可以使你对 Service Mesh 技术，以及如何落地有更多的认识。\n分享主题：\n《基于 MOSN 和 Istio Service Mesh 的服务治理实践》\n分享嘉宾：\n姚昌宇 有米科技高级后端工程师、MOSN committer。多年后端开发经验、云原生爱好者。目前负责公司内部数据和算法能力接口的服务治理相关的开发工作，2018年起关注并参与 ServiceMesher 社区发起的各种活动，近期参与 MOSN v0.14.0 版本功能的开发。\n直播时间：2020年5月28日（周四）20:00-21:00\n大纲：\n Service Mesh 带来的红利 参与 MOSN 开源共建给我带来的收获 如何参与 MOSN 开源共建 找到组织：进入 MOSN 开发者群 熟悉 MOSN \u0026amp;amp; 搭建本地调试环境：现场演示（http、grpc 服务流量控制演示，指标收集，请求跟踪演示） 发现优化点/参与 Roadmap 感悟总结，以及 MOSN 近况\u0026amp;amp;未来远景介绍 用户收获：\n 了解如何参与到 MOSN 开源社区共建中； 了解如何使用 MOSN 在 Istio 场景下的服务治理实践 ; 了解 MOSN 新版本的功能以及未来远景； 结合 Istio 各个场景的 Demo，分享 MSON 的多协议/私有协议实现； ","date":1594710000,"description":"7 月 22 日周四晚 8 点，Service Mesh Webinar#2 线上直播。","dir":"activities/service-mesh-webinar-2/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"856529bdb9666c8bad4c59a80444662f","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-webinar-2/","publishdate":"2020-07-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-webinar-2/","summary":"概要 活动主题：Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践 活动时间：7 月 22 日周四晚 8 点 活动形式：线上直播 报名方式：戳这里","tags":["MOSN","Service Mesh Webinar"],"title":"Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践","type":"activities","url":"/sofastack.tech/activities/service-mesh-webinar-2/","wordcount":657},{"author":"罗广明","categories":"Service Mesh","content":" 本文节选自 ServiceMesher 社区出品的开源电子书《Istio Handbook——Istio 服务网格进阶实战》，作者罗广明，来自百度。\n 在过去几年中，微服务成为了业界技术热点，大量的互联网公司都在使用微服务架构，也有很多传统企业开始实践互联网技术转型，基本上也是以微服务和容器为核心。本文将主要介绍微服务架构的概述以及云原生环境下的 Service Mesh 和传统微服务应用的区别。\n微服务架构概述 微服务架构可谓是当前软件开发领域的技术热点，在各种博客、社交媒体和会议演讲上的出镜率非常之高，无论是做基础架构还是做业务系统的工程师，对微服务都相当关注，而这个现象与热度到目前为止，已经持续了近 5 年之久。\n尤其是近些年来，微服务架构逐渐发展成熟，从最初的星星之火到现在的大规模落地与实践，几乎已经成为分布式环境下的首选架构。微服务成为时下技术热点，大量互联网公司都在做微服务架构的落地和推广。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。\n而在这个技术转型中，国内有一个趋势，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。然而软件开发没有银弹，基于这些传统微服务框架构建的应用系统在享受其优势的同时，痛点也越加明显。这些痛点包括但不限于以下几点：\n 侵入性强。想要集成 SDK 的能力，除了需要添加相关依赖，往往还需要在业务代码中增加一部分的代码、或注解、或配置；业务代码与治理层代码界限不清晰。 升级成本高。每次升级都需要业务应用修改 SDK 版本，重新进行功能回归测试，并且对每一台机器进行部署上线，而这对于业务方来说，与业务的快速迭代开发是有冲突的，大多不愿意停下来做这些与业务目标不太相关的事情。 版本碎片化严重。由于升级成本高，而中间件却不会停止向前发展的步伐，久而久之，就会导致线上不同服务引用的 SDK 版本不统一、能力参差不齐，造成很难统一治理。 中间件演变困难。由于版本碎片化严重，导致中间件向前演进的过程中就需要在代码中兼容各种各样的老版本逻辑，带着 “枷锁” 前行，无法实现快速迭代。 内容多、门槛高。Spring Cloud 被称为微服务治理的全家桶，包含大大小小几十个组件，内容相当之多，往往需要几年时间去熟悉其中的关键组件。而要想使用 Spring Cloud 作为完整的治理框架，则需要深入了解其中原理与实现，否则遇到问题还是很难定位。 治理功能不全。不同于 RPC 框架，Spring Cloud 作为治理全家桶的典型，也不是万能的，诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。而这些功能往往是企业大规模落地不可获缺的功能，因此公司往往还需要投入其它人力进行相关功能的自研或者调研其它组件作为补充。 以上列出了传统微服务框架的局限性，但这并不意味着它们就一无是处了。在中小企业，采用 Spring Cloud 这样的传统微服务框架已经可以满足绝大部分服务治理的需求，并且借此快速推进微服务化改造。这些痛点往往是技术发展到一定的程度必然要经历的阶段，这些痛点促使技术不断发展、不断前进。\n在众多热门技术趋势中，云原生的关注度居高不下，很多开发者都对由此兴起的一众技术十分追捧，众多企业又开始探索云原生架构的转型与落地。这一年，中国的开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变。而 Service Mesh 技术也因此越来越火热，受到越来越多开发者的关注，并拥有了大批拥趸。那么 Service Mesh 是什么呢？它为什么会受到开发者的关注？它和传统微服务应用有什么区别？\nService Mesh 定义 Service Mesh 一词最早由开发 Linkerd 的 Buoyant 公司提出，并于 2016 年 9 月29 日第一次公开使用了这一术语。William Morgan，Buoyant CEO，对 Service Mesh 这一概念定义如下：\n A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.\n 翻译成中文如下：\nService Mesh 是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。\n以上这段话有四个关键点：\n 本质：基础设施层； 功能：请求分发； 部署形式：网络代理； 特点：透明； 2017 年，随着 Linkerd 的传入，Service Mesh 进入国内社区的视野，并且由国内的技术布道师们翻译成“服务网格”。\n服务网格概述 服务网格从总体架构上来讲比较简单，不过是一堆紧挨着各项服务的用户代理，外加一组任务管理流程组成。代理在服务网格中被称为数据层或数据平面（data plane），管理流程被称为控制层或控制平面（control plane）。数据层截获不同服务之间的调用并对其进行“处理”；控制层协调代理的行为，并为运维人员提供 API，用来操控和测量整个网络。\n更进一步地说，服务网格是一个专用的基础设施层，旨在“在微服务架构中实现可靠、快速和安全的服务间调用”。它不是一个“服务”的网格，而是一个“代理”的网格，服务可以插入这个代理，从而使网络抽象化。在典型的服务网格中，这些代理作为一个 sidecar（边车）被注入到每个服务部署中。服务不直接通过网络调用服务，而是调用它们本地的 sidecar 代理，而 sidecar 代理又代表服务管理请求，从而封装了服务间通信的复杂性。相互连接的 sidecar 代理集实现了所谓的数据平面，这与用于配置代理和收集指标的服务网格组件（控制平面）形成对比。\n总而言之，Service Mesh 的基础设施层主要分为两部分：控制平面与数据平面。当前流行的两款开源服务网格 Istio 和 Linkerd 实际上都是这种构造。\n控制平面的特点：\n 不直接解析数据包。 与控制平面中的代理通信，下发策略和配置。 负责网络行为的可视化。 通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。 数据平面的特点：\n 通常是按照无状态目标设计的，但实际上为了提高流量转发性能， …","date":1594710000,"description":"本文将主要介绍微服务架构的概述以及云原生环境下的 Service Mesh 和传统微服务应用的区别。","dir":"blog/microservices-service-mesh/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f6d713862b049df801c82f5c52ec6ed1","permalink":"https://sofastack.github.io/sofastack.tech/blog/microservices-service-mesh/","publishdate":"2020-07-14T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/microservices-service-mesh/","summary":"本文节选自 ServiceMesher 社区出品的开源电子书《Istio Handbook——Istio 服务网格进阶实战》，作者罗广明，来自百度。 在过去几年中，微服务成为","tags":["Service Mesh"],"title":"火了 2 年的服务网格究竟给微服务带来了什么？","type":"blog","url":"/sofastack.tech/blog/microservices-service-mesh/","wordcount":5219},{"author":"SOFA 团队","categories":"SQLFlow","content":" 端到端机器学习是一种由输入端的数据直接得到输出端结果的AI系统，它可以对业务人员屏蔽复杂技术细节，同时给模型以更多自动调节空间，增加模型整体契合度。近两年来，端到端机器学习成为 AI 领域研发热点，蚂蚁集团于2019年5月发布端到端 AI 系统 SQLFlow 开源项目，受到业界广泛关注。今天，就让我们来看看它对端到端 AI 的思考与解答。\n SQLFlow 是蚂蚁集团开源的使用 SQL 完成 AI 工作流构建的编译系统。SQLFlow 将多种数据库系统（MySQL, Hive, MaxCompute）和多种机器学习引擎（Tensorflow, Keras, XGBoost）连接起来，将 SQL 程序编译成可以分布式执行的工作流，完成从数据的抽取，预处理，模型训练，评估，预测，模型解释，运筹规划等工作流的构建。\n接下来我们会根据以下内容逐步介绍 SQLFlow：\n 为什么要使用 SQL 语言描述端到端 AI 任务； 使用 SQLFlow SQL 语句构建 AI 任务； 使用 SQL 程序构建端到端 AI 工作流； 使用 SQLFlow Model Zoo 沉淀模型； 应用 SQLFlow 的场景案例； 为什么要使用 SQL 语言描述端到端 AI 任务 首先，思考一个问题，人工智能和金融有哪些耳熟能详的结合呢？  在智能征信风控方向，可以运用大数据进行机器学习，刻画用户画像，抽取个性化典型特征，推进反欺诈评估、用户征信评估。 用到的技术：聚类（将有相似特征的群体聚类，确定人群标签）、分类（学习已有分类标签的用户特征，识别新用户所属的类型、标签）、模型解释\n 在智能投资顾问方向，我们以人工智能算法为基础，为客户提供自动化投资管理解决方案，包括提供投资资讯、构建投资组合、直接投资管理等服务。 用到的技术：时序模型、回归、运筹规划\n 智能营销方向，上世纪90年代沃尔玛超市将「啤酒」与「尿布」摆在同一区域的做法，大大增加了商品销售收入，成为借助数据分析实现智能营销的经典案例。而今天，在人工智能等新技术的加持下，数据分析技术正在不断进化，千人千面的智能营销已有广泛的应用。 用到的技术：推荐算法、Ranking、CTR、运筹规划\n然而，构建传统的机器学习工作流程，需要经历非常多的步骤并使用复杂的技术栈： 构建完整的 AI 应用，首先需要获取用于构建模型的数据，这些数据通常可以从日志、订单数据、交易记录等获得。之后通过数据抽取，将其中我们需要用到的部分信息，从多个存储位置抽取出来。抽取数据之后需要进行数据预处理，比如去掉错误的数据，填充缺失的数据，整理，排序等。预处理完成之后，我们需要从这部分数据中得到用于训练模型的特征，比如提取时间序列的周期性特征，获取交叉特征等，最后将构建的特征转换成训练框架可以接收的数据格式，才能开始训练。 另外，在开始训练之前，我们还需要确定使用哪个模型，XGBoost 模型还是深度学习模型，哪个模型更适合当前的场景？模型可以从现有模型库中获取并根据需要修改，或者从头编写新的模型使用。另外在构建机器学习模型时，我们需要不断的评估模型的表现如何，以获得最优的模型，这时就要使用各种评价指标描述训练好的模型。当模型评估结果验证达标之后，就需要将模型代码发布一个新的版本，部署到线上环境。发布之前还要通过线下测试，小流量 ABTest，然后推全部署。如果是离线任务则需要更新定时任务使用新的模型代码。\n当模型的时效性比较强的时候，我们还需要不断的使用新的数据更新模型，就是“增量训练“，这样每次增量训练就不得不再次从头走一次完整的流程。\n要完成这一整套流程，需要用到复杂的技术栈。\n我们需要的数据可能存储在磁盘，或者像 HDFS 这样的分布式文件系统，或者可以从结构化的数据库系统中获得，或者是 NoSQL 引擎（比如 mongodb）存储的数据；在预处理阶段，有可能需要编写 MapReduce Job 来处理 HDFS 上的大量的数据，或者使用 Hive 编写 SQL 语句完成处理，亦或直接编写 Python 代码处理数据；在特征工程阶段，又需要使用类似 statsmodels, tsfresh 或者编写 Python 程序使用诸如 Pandas 之类的库完成预处理；在模型训练阶段，算法工程师首先需要掌握各种建模的能力，算法原理和基础知识，也需要熟练使用各种机器学习引擎如 sklearn, XGBoost, Tensorflow, Pytorch 等；最后在上线部署阶段，还需要了解模型如何接入 Serving 系统，怎么样做 ABTest，怎么编写 CI/CD 任务保证模型上线不影响线上业务。\n构建 AI 应用，不仅需要冗长的链路和复杂的技术，从业务需求到 AI 系统上线也需要特别长的沟通链路。\n比如业务同学和产品同学在构建产品思路的时候，在他的脑海中的 AI 系统需要完成的任务，传达给开发同学之后，有可能传达不到位，需要反复的沟通。有时甚至做了一半还需要重做。\n另外从需求到上线，为了保证线上服务和数据产出的稳定，也需要通过许多的步骤。比如业务同学说：「活动要上线了，时间点很关键，明天必须发布！」开发同学接到需求，加班加点，开发验证完成之后，模型准确率提升10个点，准备发布模型。SRE 同学则会把控上线之前的各项准备，包括预发测试是否通过，压力测试是否通过，CPU 负载是否有提升，硬件资源是否能承载新的模型，模型预测延迟是否提升了等……完成流程也需要很长时间。然而如果没有 SRE 的把关，线上的服务很难保证稳定性。\n使用 SQL 作为描述和构建 AI 任务的语言，可以降低构建 AI 应用的门槛，提升效率。\n首先需要区分编程语言主要的两种描述方法：描述意图和描述过程。简而言之，描述意图是在描述「做什么」，描述过程是描述「怎么做」。比如，夏天大家有空喜欢吃点烧烤喝点啤酒，描述意图的方式，说「我想去撸串」这一句就够了。而描述过程，就需要说「我今天晚上下班后，叫上老王小李，去公司楼下的烧烤店，点100个串和10个啤酒，最后用支付宝扫码付款」。可以看到描述意图可以非常简洁，而具体的执行方案，可以根据意图中构建得出。这点也是 SQL 不同于其他语言的关键点。\n在描述模型训练任务时，使用 SQLFlow SQL 只需要编写 SELECT * FROM iris.train TO TRAIN DNNClassifier LABEL class INTO my_dnn_model; 即可，如果使用 Python 完成相同的任务则需要编写如下图这样的较长的代码。\nSQL 语言除了有非常简洁的优势之外，在数据科学领域，SQL 语言的已有用户量大，并且在不断的增加。这里也有两个统计图，统计了数据科学类任务所使用的工具的流行程度和增长趋势。SQL 语言流行程度排名第三，增量排在第四名。数据科学领域正在更多的使用 SQL 是我们希望使用 SQL 语言描述 AI 任务的原因。除了在表达能力上 SQL 语言有非常简洁的优势之外，在蚂蚁内 MaxCompute 被广泛使用也是我们选择 SQL 的一个原因。\n如何使用 SQLFlow SQL 语句构建 AI 任务 SQLFlow 是一个开源项目， …","date":1594623600,"description":"近两年来，端到端机器学习成为 AI 领域研发热点，蚂蚁集团于2019年5月发布端到端 AI 系统 SQLFlow 开源项目，受到业界广泛关注。今天，就让我们来看看它对端到端 AI 的思考与解答。","dir":"blog/end-to-end-ai-system-sqlflow/","fuzzywordcount":6700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"667a8ff160a9c7f54a5ceba7c20b7437","permalink":"https://sofastack.github.io/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","publishdate":"2020-07-13T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","summary":"端到端机器学习是一种由输入端的数据直接得到输出端结果的AI系统，它可以对业务人员屏蔽复杂技术细节，同时给模型以更多自动调节空间，增加模型整体","tags":["SQLFlow"],"title":"我们需要什么样的端到端 AI 系统？蚂蚁 SQLFlow 的思考与答案","type":"blog","url":"/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","wordcount":6621},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网:https://www.sofastack.tech SOFAStack:https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@郝连帅 提问： \u0026amp;gt; 如果回滚失败有没有告警机制实现？比如钉钉告警。\nA：可以的，实现 FailureHandler 接口。\n本周推荐阅读 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.3，主要变更如下：\n RheaKV 允许不同分片各自配置不同的 learner 节点； 在只有一个成员变更的情况下，仍然使用 raft 联合一致性算法； 替换基于 GPL-2.0 licence 的 Bits.java； 升级 jackson.databind 版本到 2.10.4 已修复安全漏洞； 修复在 node panic 后可能因为未及时刷盘导致快照元数据丢失的 bug； 致谢（排名不分先后）：@zongtanghu\n此版本强烈建议升级 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.3\n社区活动报名 CNCF 的旗舰会议聚集了全球领先开源社区和云原生社区的使用者和技术大咖参加线上峰会。相约 2020 年 7 月 30 日 - 8 月 1 日三天的线上峰会，共同探讨云原生计算的未来和方向。蚂蚁集团也受邀进行两个云原生主题分享。\n分享主题：在大规模 Kubernetes 集群上实现高 SLO 的方法\n 分享嘉宾：霜林 蚂蚁集团技术专家、散樗 蚂蚁集团高级开发工程师 议题介绍：随着 Kubernetes 集群的规模和复杂性的增加，集群越来越难以提供高成功率和低延迟的合格 pod。在本次演讲中，蚂蚁集团的工程师将分享他们在设计 SLO架构和实现高服务水平目标的方法的经验。他们将引入适当的指标，首先衡量 Kubernetes 集群是否健康。然后，他们将解释如何设计和实现跟踪和分析平台，以收集有效的度量和计算这些指标。有了跟踪分析平台，pod 提供过程中出现的问题可以很容易的被诊断出来。最后，他们将展示如何沉淀人工体验到自我修复系统，以自动修复已知的问题。 分享时间：2020-07-30 20:10-20:40 报名方式：点击“这里”，即可报名 分享主题：为 Kubernetes 的秘密披上无形的盾牌\n 分享嘉宾：柯粟 蚂蚁集团高级开发工程师 议题介绍：K8s 的秘密广泛应用于生产中，用于对敏感信息进行存储管理。与 KMS 的集成，甚至与基于硬件的插件，确实增强了保护，但还远远不够，特别是对于财务级的安全需求。由于缺乏端到端的秘密加固解决方案，攻击面在很大程度上在 K8s 集群中其他关键元素/流的威胁中仍然不受保护。通过聚合可信执行环境（TEE）和增强的身份验证，本讲座探索在使用、静止和传输中保护 K8s 秘密的答案。对 kubectl、K8S主节点和节点进行了更改，以保证可用性和机密性。TEE 对开发人员和用户的透明性将通过一个演示进行阐述和演示。最后，将分享在蚂蚁集团的实践经验和 KEP 给社区。 分享时间：2020-07-31 20:10-20:40 报名方式：点击“这里”，即可报名 ","date":1594364400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200710/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"304a9dc50d507f12e1b562491d6b5546","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200710/","publishdate":"2020-07-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200710/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布、CNCF 旗舰会议活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200710/","wordcount":1362},{"author":"尹博学","categories":"分布式架构","content":" 过去几年是云原生理念高速普及的黄金时期。微服务、容器、无服务器架构、服务网格等新技术的出现，在技术社区中激起了一浪又一浪的创新热潮。然而由于金融行业对性能和安全的严苛要求，云原生技术在企业实际场景中的实施落地，特别是在金融场景的实施落地，仍然面临诸多挑战。\n本文整理自2020阿里云线上峰会蚂蚁集团资深技术专家尹博学的主题演讲，为大家分享蚂蚁关于金融级 IT 架构及分布式架构的思考和应用实践。关注本网站，蚂蚁 SOFAStack 白皮书即将发布，不要错过哦～\n 以下为演讲整理全文：\n大家好，我是蚂蚁集团的尹博学，今天和大家分享一下蚂蚁关于金融级 IT 架构及分布式架构的一些思考和应用案例，主要包含三个部分，分别是行业常见的分布式架构介绍、蚂蚁单元化架构的介绍以及单元化架构的应用案例。\n行业常见分布式架构 行业常见的分布式架构主要包含，单活架构、双活架构和冷备架构。从容灾能力角度来看，双活架构和冷备架构均能做到应用级跨机房容灾，但是数据库因为使用了异步复制的技术，无法做到机房级 RPU=0 的容灾。再看灰度发布的能力，冷备架构和双活架构都只能做到机房级灰度发布，无法做到更细粒度的灰度发布。\n蚂蚁集团单元化架构介绍 在介绍完行业常见的分布式架构后，我们来看一下蚂蚁的分布式架构发展历程，和单元化架构的详细介绍。\n这是蚂蚁分布式架构发展历程。蚂蚁也经历了单活、同城双活、两地三中心三个阶段。其中两地三中心是同城双活加一个冷备。随着蚂蚁业务和业务量复杂度的越来越高，业务对于基础架构的要求也越来越高，即扩展能力、容灾能力、灰度能力要求越来越高。最终蚂蚁发展到了单元化架构，将主要业务拆分单元即分片，装入不同的逻辑单元内，每个分片的数据库实现三地五中心部署即三地五中心的单元化架构。\n首先我们来看一下蚂蚁单元化架构的整体架构设计，整体架构包含 RZone、GZone 和 CZone。其中 GZone 部署的是无法拆分的数据和业务，GZone 的数据和业务被 RZone 依赖，GZone 全局只部署一份，而 RZone 部署的是可拆分的业务和对应的数据。每个 RZone 内的数据分片如图所示有五副本，实现三地五中心部署，每个分片内只有一个可写入的主副本，其余副本按照 Paxos 协议做数据强一致。每个 RZone 内实现业务单元封闭，独立完成自己的所有业务。而 CZone 的出现是因为 GZone 全局只有一份，不同城市的 RZone 可能依赖 GZone 服务和数据的时候需要远距离调用，延迟比较大，所以在每个城市部署一个 CZone 作为 GZone 的只读副本，为本城市的 RZone 提供服务。\n介绍完单元化架构的整体设计之后，我们从容灾、灰度发布、弹性三个方面详细看一下该架构的能力。\n首先看容灾能力，容灾能力分为同城容灾和异地容灾，以图中所示为例，RZone1 出现故障先看同城容灾能力，我们目标将 RZone1 切换至同城容灾 RZone2。先做数据库分片切换，RZone1 对应的分片为分片1，把分片1在 RZone2 的副本提升为主副本，数据库副本提升完毕后将 RZone1 的流量切换至 RZone2，实现同城容灾 RPO=0、RTO\u0026amp;lt;1min。\n再看异地容灾，同样以 RZone1 故障为例。目标切换至 RZone3，先做数据库切换，分片1在 RZone3 的副本切换成主副本，完成后将 RZone1 的流量切换至 RZone3，实现异地容灾，该过程 RPO=0、RTO\u0026amp;lt;1min。\n接下来我们看弹性。弹性的背景是业务在大促、节假日等流量出现大幅上涨的过程，我们可以短期租借新的城市和新的 IDC。如图所示，我们租借城市 X 的 IDCX 作为 RZoneX，将 RZone5 的部分流量弹出至 RZoneX，对应流量的数据也弹出至 RZoneX 内。在节假日大促结束之后，将 RZoneX 内的流量和数据弹回至 RZone5，然后回收 RZoneX，这样大幅节约了机房成本。\n介绍完弹性之后，我们来看灰度能力。如图所示，我们将四个 RZone（RZone1、RZone2、RZone3、RZone4）的业务和应用分为 A、B 组，日常 A 组和 B 组各承担50%的应用流量。在应用新版本发布时，我们将 A 组的流量全部切换至 B 组，此时在 A 组上部署新版本，部署完毕后将 B 组的流量按粒度切换至 A 组上，切换粒度等于数据分片的粒度。在切换的过程中可以做 A 组和 B 组的服务对比，如果发现 A 组的服务异常，可以快速将流量切换回 B 组。在 A 组服务一段时间后无异常发生，最终可以将 B 组的流量全部切换至 A 组，把 B 组的版本更新为新的版本，在整个切换的过程中实现了可灰度、可回滚、可监控。\n我们再深入到架构内部，来阐释一下架构内关键模块是如何支撑该架构的。\n首先我们看流量路由模块。流量路由模块的核心是将用户的 uid 信息和对应的 Zone 信息植入到 cookie 中，供流量路由模块做精准路由。我们以用户 uid=68、RZone=RZ03 为例来看流量路由模块是如何工作的，首次用户接入时 cookie 内无 Zone 信息，流量接入模块会随即将该请求发到一个 RZone 内，如发到 RZone1 内，RZone1 通过 zoneClinet 会准确计算该请求应发至 RZone3，即通过 RouteClinet 将该请求发送。发送过程中将计算出的 uid 信息和对应的 Zone 信息植入 cookie 内转发至 RZone3，RZone3 完成本次业务请求后将结果返回给用户，其后用户同意 session 内的其它请求，因为在 cookie 内已经有了准确的路由信息，会被流量路由模块准确的发至 RZone3 完成业务请求。\n接着我们再看一下服务路由，服务路由分为本机房服务路由和跨机房服务路由调用。先看本机房服务路由，服务调用端向本机房服务注册中心订阅服务，发现服务地址后做本机房服务路由调用。再看跨机房服务路由调用，服务调用端向其他 IDC 的注册中心订阅服务地址，发现服务地址后做跨机房服务调用。\n最后我们看数据是如何实现高可靠的。蚂蚁使用自研的分布式关系数据库 OceanBase，每个分片的数据库做5副本部署，部署地域实现三地五中心部署，5副本中有3副本实现强一致，如图所示可以实现同城、IDC 容灾和异地容灾。\n单元化架构实践场景 介绍完蚂蚁单元化架构的主要概念即关键模块信息之后，我们看一下单元化架构在外部客户实施的一些案例。\n第一个案例是一家城商行，它的业务系统、IT系统历史比较长，无法一步跨越到单元化架构，我们为其推荐了大 GZone 的模式，即把城商行的所有服务和数据不做拆分，直接装入一个 GZone 内，在 GZone 的基础上实现同城双活即应用同城双中心部署，数据库同城三中心部署，从而实现同城容灾能力，RPO=0、RTO\u0026amp;lt;1min，但无法实现异地容灾能力，其可灰度能力和弹性能力都无法做到更细力度。\n再看第二个区域银行的案例。我们为这家区域银行实现了同城单元化，即将这家区域银行的主要业务拆分成两个逻辑业务单元两个分片，将其装入一个城市的两个 IDC 内，在另外一个城市建设冷 …","date":1594278000,"description":"本文整理自2020阿里云线上峰会蚂蚁集团资深技术专家尹博学的主题演讲，为大家分享蚂蚁关于金融级 IT 架构及分布式架构的思考和应用实践。","dir":"blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dec27e85a58fcb573b33b9de6125bbc5","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","publishdate":"2020-07-09T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","summary":"过去几年是云原生理念高速普及的黄金时期。微服务、容器、无服务器架构、服务网格等新技术的出现，在技术社区中激起了一浪又一浪的创新热潮。然而由于","tags":["分布式架构"],"title":"支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构","type":"blog","url":"/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","wordcount":3642},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@guotaisu 提问：\n 根据 jraft-example, 使用“fake PD”, 怎样手动 rebalance。使用 PD 自管理体现在哪？\n A：手动 API： https://github.com/sofastack/sofa-jraft/blob/master/jraft-core/src/main/java/com/alipay/sofa/jraft/CliService.java#L190\nPD 目前只实现了 leader 平衡和自动分裂，支持很容易基于 SPI 扩展增加自己的逻辑(增加并实现自己的 com.alipay.sofa.jraft.rhea.util.pipeline.Handler 即可)，文档见：https://www.sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/\n regionEngineOptionsList 配置：实例中的 regionId 的 startKey：01000000-endKey：23000000 根据什么来定义的，假设我一个 store 节点只部署 1-3 个 region，可以自定义上下界是吗，依据什么来定义？\n A：rheakv multi group 按照 range 分片，左闭右开，可以自定义，怎么定义取决于你对自己场景 key 分布的评估。\n yaml 配置中 regionEngineOptionsList.RegionEngineOptions 中的 serverAddress、initialServerList 等配置和外部与 regionEngineOptionsList 平级的 serverAddress 配置以及与 storeEngineOptions 平级的 initialServerList 是什么关系，谁覆盖谁？\n A：store 和 region 为1：n， region 包含在 store 中，store 的参数会 copy 传递到 region。\n jraft-example 展示，Rhea-kv 是客户端+服务端模式，其中 benchmark 使用分片集群部署模式，需要先同时使用 BenchmarkClient、BenchmarkServer 拉启后台服务，而后面的 rheakv 使用分节点配置和启动，如何区分二者的场景和使用姿势。\n A：rheakv 可以作为 client+server 部署，也可以单独作为 client 部署，通常你不想在每个节点提供服务但是还需要调用服务，那么就只 client 部署即可（配置的区别就在于是否配置了 StoreEngineOptions）。\n 本人项目使用 SOFAJRaft 场景是分布式单体服务快速便捷存储业务元数据，实现一致性访问。请问后台需要拉取这么多服务如何还能保证我的应用轻量快捷？另外，这些后台 jraft-kv 选举和存储服务启动后，是独立进程吗，整合到自己到项目中后，可否一个进程并且其服务生命周期随同我的母体应用的生命周期。\n A：SOFAJRaft 是一个 jar 包，是不是独立进程完全取决于你自己的意愿，都可以。\n 参考 jraft-example 实例，基于 rheakv 部署 multi group，加减 learnner 节点等，应该是以分组为单位操作，目前只看到 NodeOptions 中有 groupId 属性，多组时怎么配置和分别操作。\n A：这应该是两个问题。 问题1（groupId 多组如何配置）：在 rheakv 里，groupId 是 clusterName + ‘-’ regionId。 问题2（多组如何配置 learner）：目前没有很灵活，我们内部使用还是单独指定几台机器，上面的节点全部是 learner 节点，只要配置 initialServerList: 127.0.0.1:8181,127.0.0.1:8182,127.0.0.1:8183/learner 即所有 group 的 learner 都在 127.0.0.1:8183/learner 一个节点上，你的需求收到了，下个版本会增加每个 region 单独指定 learner，需要修改 RegionEngineOptions.initialServerList 在不为空的时候不被 StoreEngineOptions 的值覆盖即可。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 网络通信框架 SOFABolt 功能介绍及协议框架解析 | SOFAChannel#17 直播回顾 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.14.0，主要变更如下：\n 支持 Istio 1.5.x 版本； 升级了一些依赖库，如 FastHTTP、Dubbo-go、Tars； 支持 Maglev 负载均衡、支持 HostRewrite Header； 新增了一些 Metrics 输出与查询接口； 部分实现优化与 Bug 修复； 详细发布报告：https://mosn.io/zh/blog/releases/v0.14.0/\n同时，恭喜姚昌宇（@trainyao）成为 MOSN Committer，感谢他为 MOSN 社区所做的贡献。\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题：云原生网络代理 MOSN 的进化之路 分享嘉宾：王发康（毅松）蚂蚁集团 可信原生技术部 技术专家 背景介绍：网络通信代理 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，增强 MOSN 服务治理及流量控制能力，对接云原生周边组件，实现 MOSN 开箱即用，MOSN …","date":1593759600,"description":"【06/29-07/03】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200703/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6f65c94a70fdd3d222fb510cbec05abf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200703/","publishdate":"2020-07-03T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200703/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 版本发布以及社区活动预告、SOFABolt 直播回顾整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200703/","wordcount":1989},{"author":"丞一","categories":"SOFAChannel","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 大家好，我是本期 SOFAChannel 的分享讲师丞一，来自蚂蚁集团，是 SOFABolt 的开源负责人。今天我们来聊一下蚂蚁集团开源的网络通信框架 SOFABolt 的框架解析以及功能介绍。本期分享将从以下四个方面展开：\n SOFABolt 简介； 基础通信能力解析； 协议框架解析； 私有协议实现解析； SOFABolt 是什么 SOFABolt 产生背景 相信大家都知道 SOFAStack，SOFAStack(Scalable Open Financial Architecture Stack)是一套用于快速构建金融级云原生架构的中间件，也是在金融场景里锤炼出来的最佳实践。\nSOFABolt 则是 SOFAStack 中的网络通信框架，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架，他的名字 Bolt 取自迪士尼动画《闪电狗》。他一开始是怎么在蚂蚁集团内部产生的，我们可以类比一下 Netty 的产生原因：\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生； 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生； 这些年，在微服务与消息中间件在网络通信上，蚂蚁集团解决过很多问题、积累了很多经验并持续进行着优化和完善，我们把总结的解决方案沉淀到 SOFABolt 这个基础组件里并反馈到开源社区，希望能够让更多使用网络通信的场景受益。目前该组件已经运用在了蚂蚁集团中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n同时，已有数家企业在生产环境中使用了 SOFABolt，感谢大家的肯定，也希望 SOFABolt 可以给更多的企业带来实践价值。\n以上企业信息根据企业用户 Github 上反馈统计 — 截止 2020.06。\nSOFABolt：https://github.com/sofastack/sofa-bolt\nSOFABolt 框架组成 SOFABolt 整体可以分为三个部分：\n 基础通信能力（基于 Netty 高效的网络 IO 与线程模型、连接管理、超时控制）； 协议框架（命令与命令处理器、编解码处理器）； 私有协议实现（私有 RPC 通信协议的实现）； 下面，我们分别介绍一下 SOFABolt 每个部分的具体能力。\n基础通信能力 基础通信模型 如上图所示，SOFABolt 有多种通信模型，分别为：oneway、sync、future、callback。下面，我们介绍一下每个通信模型以及他们的使用场景。\n oneway：不关注结果，即客户端发起调用后不关注服务端返回的结果，适用于发起调用的一方不需要拿到请求的处理结果，或者说请求或处理结果可以丢失的场景； sync：同步调用，调用线程会被阻塞，直到拿到响应结果或者超时，是最常用的方式，适用于发起调用方需要同步等待响应的场景； future：异步调用，调用线程不会被阻塞，通过 future 获取调用结果时才会被阻塞，适用于需要并发调用的场景，比如调用多个服务端并等待所有结果返回后执行特定逻辑的场景； callback：异步调用，调用线程不会被阻塞，调用结果在 callback 线程中被处理，适用于高并发要求的场景； oneway 调用的场景非常明确，当调用方不需要拿到调用结果的时候就可以使用这种模式，但是当需要处理调用结果的时候，选择使用同步的 sync 还是使用异步的 future 和 callback？都是异步调用，又如何在 future、callback 两种模式中选择？\n显然同步能做的事情异步也能做，但是异步调用会涉及到线程上下文的切换、异步线程池的设置等等，较为复杂。如果你的场景比较简单，比如整个流程就一个调用并处理结果，那么建议使用同步的方式处理；如果整个过程需要分几个步骤执行，可以拆分不同的步骤异步执行，给耗时的操作分配更多的资源来提升系统整体的吞吐。\n在 future 和 callback 的选择中，callback 是更彻底的异步调用，future 适用于需要协调多个异步调用的场景。比如需要调用多个服务，并且根据多个服务端响应结果执行逻辑时，可以采用 future 的模式给多个服务发送请求，在统一对所有的 future 进行处理完成协同操作。\n超时控制机制 在上一部分的通信模型中，除了 oneway 之后，其他三种（sync、future、callback）都需要进行超时控制，因为用户需要在预期的时间内拿到结果。超时控制简单来说就是在用户发起调用后，在预期的时间内如果没有拿到服务端响应的结果，那么这次调用就超时了，需要让用户感知到超时，避免一直阻塞调用线程或者 callback 永远得不到执行。\n在通信框架中，超时控制必须要满足高效、准确的要求，因为通信框架是分布式系统的基础组件，一旦通信框架出现性能问题，那么上层系统的性能显然是无法提升的。超时控制的准确性也非常重要，比如用户预期一次调用最多只能执行3秒，因为超时控制不准确导致用户调用时线程被阻塞了4秒，这显然是不能接受的。\nSOFABolt 的超时控制采用了 Netty 中的 HashedWheelTimer，其原理如上图。假设一次 tick 表示100毫秒，那么上面的时间轮 tick 一轮表示800毫秒，如果需要在300毫秒后触发超时，那么这个超时任务会被放到\u0026amp;rsquo;2\u0026amp;rsquo;的 bucket 中，等到 tick 到\u0026amp;rsquo;2\u0026amp;rsquo;时则被触发。如果一个超时任务需要在900毫秒后触发，那么它会被放到如\u0026amp;rsquo;0\u0026amp;rsquo;的 bucket 中，并标记 task 的 remainingRounds=1，当第一次 tick 到\u0026amp;rsquo;0\u0026amp;rsquo;时发现 remainingRounds 不等于0，会对 remainingRounds 进行减1操作，当第二次 tick 到\u0026amp;rsquo;0\u0026amp;rsquo;，发现这个任务的 remainingRounds 是0，则触发这个任务。\n如果将时间轮的一次 tick 设置为1秒，ticksPerWheel 设置为60，那么就是现实时钟的秒针，走完一圈代表一分钟。如果一个任务需要再1分15秒后执行，就是标记为秒针走一轮之后指向第15格时触发。关于时间轮的原理推荐阅读下面这篇论文： 《Hashed and Hierarchical Timing Wheels: data structures to efficiently implement a timer facility》。\n快速失败机制 超时控制机制可以保证客户端的调用在一个预期时间之后一定会拿到一个响应，无论这个响应是由服务端返回的真实响应，还是触发了超时。如果因为某些原因导致客户端的调用超时了，而服务端在超时之后实际将响 …","date":1593694800,"description":"开源网络通信框架 SOFABolt 首次线上直播文字回顾。","dir":"blog/sofa-channel-17-retrospect/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9f88cb52dccf190278f16c9eab448644","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-17-retrospect/","publishdate":"2020-07-02T21:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-17-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播","tags":["SOFAChannel","SOFABolt"],"title":"网络通信框架 SOFABolt 功能介绍及协议框架解析 | SOFAChannel#17 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-17-retrospect/","wordcount":5457},{"author":"敖小剑","categories":"微服务","content":" 最近社区频繁出现的对微服务的各种质疑和反思的声音，甚至放弃微服务回归单体。本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Event/EDA 来走出微服务实践误区：从单体到微服务，却最后沦为分布式单体。\n 回顾：从单体到微服务到 Function 在过去几年间，微服务架构成为业界主流，很多公司开始采用微服务，并迁移原有的单体应用迁移到微服务架构。从架构上，微服务和单体最大的变化在于微服务架构下应用的粒度被“拆小”：将所有业务逻辑都在一起的单体应用，按照领域模型拆分为多个内聚而自治的“更小”的应用。而 Function 则在拆分上更进一步，拆分粒度变成了“单个操作”，基于 Function 逐渐演进出现 FaaS 形态和 Serverless 架构。\n在微服务和 Serverless 的喧嚣中，也逐渐出现了很多质疑和反对的声音：越来越多的人发现，当他们兴冲冲的迁移单体应用到微服务和 Serverless 架构之后，得到的收益并没有期望中的那么理想。最近，出现了对微服务的各种质疑、反思的声音，甚至放弃微服务回归单体。举例，我在 InfoQ 中国网站 简单搜索关键字“微服务”，前三页中就出现了如下的内容：\n 我们为什么停用微服务？ 这些公司为什么放弃微服务？ 什么？你的团队没有100人，那就不要用微服务了！ 致传统企业朋友：不够痛就别微服务，有坑 微服务带来的心理阴影 微服务到底该多大？如何设计微服务的粒度？ Uber 团队放弃微服务改用宏服务，网友评论炸锅了 为什么 Segment 从微服务回归单体 无论是支持还是反对微服务的声音，大多都是着眼于组织架构（康威定律，对应用和代码的 ownership）、微服务拆分（粒度大小，如何识别领域模型和业务边界）、分布式事务（跨多个微服务调用时维持一致性），工具（自动化构建、部署，可测试性，监控，分布式链路跟踪，CI/CD），数据库分离（避免多个微服务尤其是领域模型外的微服务共享数据库）等方面进行合理性分析和观点阐述，相信大家都对这些问题都有了解。\n而我今天的文章，将从另外一个角度来看待微服务（也包括 Serverless）实践中存在的误区——辛辛苦苦从单体走到微服务，却最后沦为分布式单体。\n分布式单体 “Distributed Monolith”，分布式单体，这真是一个悲伤的技术术语。而这偏偏是企业采用微服务后通常最容易踏进去的一个“陷阱”，事实上我看到的很多微服务落地最终都是以\u0026amp;rdquo;分布式单体\u0026amp;rdquo;收场，无法获得微服务的完整收益。\n问题源于微服务实施的方式 —— 按照业务逻辑拆解单体，划分为多个微服务，定义 API 接口，然后通过 REST 或者 RPC 进行远程调用，最终把这些微服务组合起来提供各种业务功能。简单说，就是在业务拆分的基础上，用进程间的远程调用简单替代原来进程内的方法调用。期间，对于原来使用的各种分布式能力，继续沿用之前的方式，简单说：方式不变，只是粒度变小。\n从方法论说这样做无可厚非，这也是微服务采用过程中非常标准的做法。但问题在于，止步于此是不够的 —— 至少存在两个有待继续努力改进的地方。\n分布式单体起因之一：通过共享库和网络客户端访问分布式能力 分布式能力的共享库和网络客户端是造成分布式单体问题的原因之一，关于这一点，来自 verizon 的 Mohamad Byan 在他的名为 Avoid the Distributed Monolith!! 的演讲中有详细的阐述，我这里援引他的图片和观点：\n上图是微服务体系的逻辑架构，由两部分组成：\n 内层架构（图上浅蓝色部分），是每个微服务的实现架构； 外层架构（图上黄色部分），是构建强大微服务架构所需要的各种能力，这里通常有大家熟悉的各种分布式能力； 特别提示：这里说的“网络客户端”是各种分布式能力的客户端，如服务注册发现/ MQ 中间件/ Redis 等 key-value 存储/数据库/监控日志追踪系统/安全体系等，不是服务间通讯如 RPC 的客户端。\n 而内层的微服务是通过 共享类库 和 网络客户端 来访问外层架构提供的分布式能力：\n分布式能力的 共享类库 和 网络客户端 会迫使内层微服务和外层架构的各种分布式能力之间产生强耦合，增加运维的复杂性（如升级困难造成版本碎片化），多语言受限于类库和网络客户端支持的语言，各种组件（如消息中间件）往往使用自定义数据格式和通讯协议 —— 所有这些迫使内层微服务不得不实质性受限于外层架构的技术选型。\n对于 Function，这个问题就更加明显了：Function 的粒度更小，更专注业务逻辑。某些简短的 Function 可能只有几百行代码，但是，为了让这几百行代码运转起来而需要引入的共享类库和网络客户端可能相比之下就规模惊人了。援引一张网上图片作为示意：\n分布式单体起因之二：简单用远程调用替代进程内方法调用 在微服务架构改造过程中，熟悉单体系统和架构的开发人员，习惯性的会将这些单体时代的知识和经验重用到新的微服务架构之中。其中最典型的做法就是：在遵循领域模型将现有单体应用按照业务边界拆分为多个微服务时，往往选择用 REST 或者 RPC 等远程调用方式简单替代原有的进程内方法调用。\n当两个逻辑上的业务模块存在协作需求时：\n从单体到微服务，直接方法调用被替换为远程调用（REST 或者 RPC），即使采用 Service Mesh 也只是在链路中多增加了 Sidecar 节点，并未改变远程调用的性质：\n这导致了前面所说的 “分布式单体”：\n 在微服务之前：应用程序由多个耦合在一起的模块组成，这些模块通过内存空间进行方法调用….. 在微服务之后：应用程序由多个耦合在一起的微服务组成，这些微服务通过网络进行远程调用….. 抛开调用方式的差异来看采用微服务前后的系统架构，会发现：两者几乎是完全一样的！！\n而微服务版本在某些情况下可能表现的更糟糕：因为调用方式更脆弱，因为网络远比内存不可靠。而我们将网络当成 “胶水” 来使用，试图把分散的业务逻辑模块（已经拆分为微服务）按照单体时代的同样方式简单粘在一起，这当然比单体在同一个进程内直接方法调用更加的不可靠。\n 关于这一点，在 \u0026amp;ldquo;The Eight Fallacies of Distributed Computing/分布式计算的8个谬论\u0026amp;rdquo; 一文中有详细阐述。\n 类似的，在采用 Function 时，如果依然沿用上面的方式，以单体或微服务架构的思维方式和设计模式来创建 FaaS/Serverless 架构：\n其本质不会发生变化 —— 不过是将微服务变成粒度更小的函数，导致系统中的远程调用数量大为增加：\n系统内的耦合并没有发生变化，Serverless 并不能改变微服务中存在的这个内部耦合问题：调用在哪里，则耦合就在哪里！只是把将组件的粒度从 “微服务“换成了 “Function/函数”。\n耦合的存在是源于系统不同组件之间的通讯模式，而不是实现通讯的技术。\n如果让两个组件通过“调用”（后面再展开讲何为调用）进行远程通信，那么不管调用是如何实现的，这两个组件都是紧密耦合。因此，当系统从单体到微服务到 Serverless，如果止步于简单的用远程调 …","date":1593414000,"description":"本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Event/EDA 来走出微服务实践误区：从单体到微服务，却最后沦为分布式单体。","dir":"blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","fuzzywordcount":9800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9ab906cecb82200b18dceb4ab43ba46a","permalink":"https://sofastack.github.io/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","publishdate":"2020-06-29T15:00:00+08:00","readingtime":20,"relpermalink":"/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","summary":"最近社区频繁出现的对微服务的各种质疑和反思的声音，甚至放弃微服务回归单体。本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Eve","tags":["微服务","分布式"],"title":"走出微服务误区：避免从单体到分布式单体","type":"blog","url":"/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","wordcount":9732},{"author":"王旭","categories":"镜像","content":" 众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知道，最初的 Docker = LXC + aufs，前者就是所谓的 Linux 容器了，而后者则是我今天要聊的镜像。\n 千禧年：惊艳的 Live CD 说到 Linux distro，除了做差异化的界面主题之外，核心差异一般都在于：\n 如何更方便地安装； 如何更方便地升级； 而在 distro 界却有一股清流，超脱于这两件事情之外，它们就是 Live CD，它们装在一张光盘里，或者是一个 U盘上，不需要安装、也不会改变。之前创业的时候，我司的运维大佬——彤哥曾经说过：\n 第一次见到 liveCD 时我内心是震惊的。。\n 这我当然是赞同的，那时我也是震惊的同学之一，要知道 Knoppix 在 2000 千禧年就来到了世界，而它所基于的著名的 Debian，直到2005年6月，Sarge (3.1) 发布的时候才正式在 stable release 里带上了图形界面的安装程序 debian-installer （简称 d-i），此前版本的安装还在用文本菜单。就在这个年代，这样一个开光盘即用、启动起来就是图形界面的系统，给我们这些玩家带来的震撼，当然是可想而知的。那时候的 Live CD 就是十三年后的 Docker，绝对配得上“惊艳”两个字。\n要知道，一张 700MB 左右的光盘里塞下个完整的操作系统并不容易（当然有人开头之后也不太难，后来我爱的 DSL 可以做到 50MB）。Knoppix 有个很棒的想法——把装好的操作系统给压缩一下，放在光盘里， 随用随解压，这样，一张 700MB 光盘里可以放下大约 2GB 的根文件系统，这样就跑 KDE 桌面也就没啥问题了，当是时，distrowatch.com 上可以看到，一大片 distro 都是基于 Knoppix 魔改的，足见其影响力。\n进化：可读写层与 UnionFS Knoppix 在诞生之初的一个执念是“绝不碰本地存储一根指头”，而光盘，CD-ROM，所使用的 ISO9600 文件系统也是只读的，这无疑暗合了当今流行的“不可变基础设施”的潮流，但是，即使在今天，没有可写文件系统对于很多 Linux 软件仍然是非常困难的，毕竟随随便便一个程序也要写一点配置文件、状态信息、锁、日志之类的嘛。而诞生之初的 Knoppix 是不可写的，那么，要有什么东西要罗盘，就得手工挖掘出本地硬盘来挂上，或者是挂个 NAS 到 /home 或其他挂载点上来，当你不想只是做个紧急启动盘的时候，这就有点麻烦了。\n如果我们从今天穿越回去，毫不费力就可以指出，用 overlayfs 加上一个 tmpfs 做可写层嘛。但是，overlayfs 要到2010年才首次提交 patchset，2014年才被合并到 3.18内核（这中间，当时的淘宝内核组也有不少贡献和踩坑呢）。当然，比 overlay 早的类似的 unionfs 还是有的，Docker 最早采用的 Aufs 就是其中之一，它是2006年出现的，这里 AUFS 的 A，可以理解成 Advanced，但它最早的意思实际是 Another——是的，“另一个 UFS”，而它的前身就是 UnionFS。\n在2005年5月，也就是十五年前，Knoppix 创造性地引入了 UnionFS，而在一年半以后的 5.1 版本中，Knoppix 引入了当年诞生的更稳定的 aufs，此后，包括大家熟悉的 Ubuntu LiveCD、Gentoo LiveCD 全都使用了 aufs。可以说，正是 Live CD 们，提前了8年，为 Docker 和 Docker Image 的诞生，做好了存储上的准备。\n这里简单说一句给不了解的人听，所谓 union fs，是指多个不同文件系统联合（堆叠）在一起，呈现为一个文件系统，它和一般的 FHS 规定的那种树装组织方式是不同的，如下图，对于左边的标准的目录树结构，任何一个文件系统，挂载在树上的一个挂载点，根据路径，就可以指到一个确定的文件系统，比如，下图中，所有的 /usr/local/ 下面的路径都在一个文件系统上，而其他 /usr 就会在另一个文件系统上；而 UnionFS 是多层堆叠的，你写的文件会停留在最上层，比如图中，你修改过的 /etc/passwd 就会在最上的可写层，其他的文件就要去下面的层中去找，也就是说，它允许同一个目录中的不同文件在不同层中，这样，Live CD 操作系统跑起来就像真正的本地操作系统一样可以读写所有路径了。\n块或文件：Cloop 与 SquashFS 让我们把目光放在只读层上，这一层是 Live CD 的基础，在 Live CD 还没有 union FS 来做分层的时候就已经存在这个只读 rootfs 了。对 Knoppix 来说，这一层是不能直接放完整、无压缩的操作系统的，因为在21世纪初，大家都还在用 24x 到 40x 速光驱的时代，Knoppix Live CD 面临的一个大问题是 700MB 的光盘和庞大的桌面操作系统之间的矛盾。\n开头我们提到了，Knoppix 的想法就是“把装好的操作系统给压缩一下，放在光盘里， 随用随解压”，这样精心选择后的 2GB 的 Distro 就可以压到一张光盘里了，不过“随用随解压“不是说有就有的，文件系统访问块设备，是要找到块的偏移量的，压缩了之后，这个偏移量就并不那么好找了，全解压到内存里再找偏移并不那么容易。\n回到2000年，那时候还是2.2内核，Knoppix 的作者 Klaus Knopper 在创立 Knoppix 之初就引入了一种压缩的(compressed) loop 设备，称为 cloop，这种设备是一种特殊的格式，它包含了一个索引，从而让解压缩的过程对用户来说是透明的，Knoppix 的 cloop 设备看起来就是一个大约 2GB 大的块设备，当应用读写一个偏移的数据的时候，它只需要根据索引解压缩对应的数据块，并返回数据给用户就可以了，无需全盘解压缩。\n尽管 Knoppix 把众多 distro 带上了 Live CD 的船，但是，众多后继者，诸如 arch、Debian、Fedora、Gentoo、Ubuntu 等等 distro 的 LiveCD，以及大家熟悉的路由器上玩的 OpenWrt，都并没有选择 cloop 文件，它们选择了和应用语义更接近的文件系统级的解决方案——Squashfs。Squashfs 压缩了文件、inode 和目录，并支持从 4K 到 1M 的压缩单元尺寸。同样，它也是根据索引按需解压的，和 cloop 的不同之处是，当用户访问一个文件的时候，它来根据索引解压相应的文件所在的块，而非再经过一层本地文件系统到压缩块的寻址，更加简单直接。事实上，Knoppix 里也一直有呼声想要切换到 squashfs，比如，2004年就有开发者在转换 knoppix 到squashfs 上，而且，一些测试数据似乎也表明 Squashfs 的性能似乎要更好一些，尤其在元数据操作方面。\n在 wiki 上是这么评价 cloop 的缺点的： …","date":1592895600,"description":"众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知道，最初的 Docker = LXC + aufs，前者就是所谓的 Linux 容器了，而后者则是今天要聊的镜像。","dir":"blog/twenty-years-of-image-format-from-Knoppix-to-OCI-Image-v2/","fuzzywordcount":6100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f918e4318b9157894559ba289b29553d","permalink":"https://sofastack.github.io/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","publishdate":"2020-06-23T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","summary":"众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知","tags":["镜像"],"title":"镜像格式二十年：从 Knoppix 到 OCI-Image-v2","type":"blog","url":"/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","wordcount":6095},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@雷霆 提问：\n 各位大佬 请问 TCC 拦截器这块为什么 xid 要先解绑，再绑定呢，这样做是有什么考虑吗？ A：执行 TCC 分支时，首先会解绑 xid，这是因为在 TCC 分支内，是不需要执行 AT 的 SQL 解析和自动补偿的（可以在 seata-rm-datasource 的 ExecuteTemplate 里看下实现），同时需要绑定下当前的拦截类型 TCC，这个拦截器类型在跨服务传递时也有特殊处理，建议也看下跨服务传递的源码。最后然后执行完 TCC 分支后的解绑、还原 xid 的操作，就是一个事务上下文的还原了。你目前看到的这个源码，后续我们还会优化下，更方便理解。这一系列操作是为了根据分支类型来区分分支事务的行为：AT 分支的行为是自动补偿，会走 SQL 解析和 undo 回滚，TCC 分支的行为是手动补偿，不会走 undo，而是执行用户自定义的 try 和 confirm。\n2、@taking 提问：\n 为何 TCC 模式的分支事务 commit 需要同步呢？\n A：因为如果异步 commit 会存在，退款的问题，如果没有 commit 那么事务没有完成，这时来了一笔退款交易，则原交易状态没有完成，会失败。当然也可以异步化，但是需要能够容忍一些反向交易的失败，或对反向交易做特殊处理。\n 如果 commit 被阻塞，退款请求也一样还是会失败吧？\n A：commit 被阻塞，说明支付还没有成功，前面不会发起退款的。\n 可以考虑在 LocalTCC 注解上加个属性表示是否允许异步执行。\n A：也可以的，然后在反向交易时需要能判断这个正交易是否已经完成，没有完成，触发一次事务恢复，进行 commit，然后再执行反交易。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服智能监控云原生可观测大盘设计概览 再启程，Service Mesh 前路虽长，尤可期许 蚂蚁金服在 Service Mesh 监控落地经验分享 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFAJRaft v1.3.2 版本，主要变更如下：\n 抽象出网络通信层，增加 GRPC 实现并支持 Replication Pipeline，用户亦可自行对通信层进行其他实现的扩展； RheaKV 增加 reverseScan API ； 提供 Replicator 与 RPC 的线程池隔离，避免相互影响； read-index 线性一致读请求提供请求超时（timeout）配置； 几个 corner case 修复，比如 replicate logs 如果比 appliedIndex（follower）更小，那么可以认为是成功的； 致谢（排名不分先后） @shibd 、@SteNicholas 、@killme2008 、@zongtanghu 详细发布报告： https://github.com/sofastack/sofa-jraft/releases/tag/1.3.2\n2、发布 Occlum v0.13.0 版本，主要变更如下：\n 扩展了Occlum.json的配置格式，更强大，更易读； 增加了3个新的系统调用； 增强了编程语言支持：支持了 Rust、改进了 Python 和 Go 的 demo； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.13.0\n社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1592550000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200619/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4b795b006dbfdc77ff65a693f80f1e6c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200619/","publishdate":"2020-06-19T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200619/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft、Occlum 发布、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200619/","wordcount":1726},{"author":"申尘","categories":"智能监控","content":" 背景 蚂蚁金服业务自定义监控是蚂蚁金服监控产品中的一个重要功能，主要是通过自定义日志数据源并配置大盘的方式来解决蚂蚁金服业务实时监控的需求。在产品功能上，用户可以通过对一系列日志数据源的创建、组织、管理及表单配置化的方式，简单、快速组织出一个多维监控大盘。这项能力在当时是一个具有创新性的能力，从功能到产品体验上很好解决了当时蚂蚁金服复杂业务监控的痛点。\n但是，随着蚂蚁金服监控产品的不断迭代更新，以及云原生可观测性对于监控大盘的高要求，大家对自定义监控的体验诉求也越来越多，包括更便捷的交互方式、更丰富的图表、更丰富的数据源、更多扩展点等，因此对监控大盘的升级也势在必行。\n本文将介绍蚂蚁金服监控产品在监控大盘方面的创新设计与尝试，新版自定义监控大盘 Barad-Dur 目标成为业界体验最优秀的自定义监控大盘，在交互、体验与设计理念上有诸多创新点，同时将以模块的形式发布，支持二次开发，可以同时为蚂蚁金服内外监控系统服务。\n产品体验 WYSIWYG 当前优秀的监控大盘产品都标配一个“所见即所得（WYSIWYG）”编辑器，这方面能力是蚂蚁金服监控产品一直缺失的。在蚂蚁金服监控产品中配置大盘还是通过传统的表单方式，对用户非常不友好、学习曲线陡峭、配置效率不高。导致用户经常将配置大盘作为一项需求提给监控团队，由监控团队的“大盘配置专家”来进行配置，不仅存在较高的沟通成本，也给监控团队增加了很大的负担。\n在新版监控大盘 Barad-Dur 中，对 WYSIWYG 编辑器的交互体验进行了大量工作，力求做到市面上最优秀的编辑体验。\n体验1：缩放 Barad-Dur 的缩放是可以在四周以及四角上进行的，而市面上常见的大盘产品只支持右下角的缩放。由于坐标系统一般采用的是 (left, top, width, height) 来定义一个矩形，最容易实现的就是右下角缩放，只需要变动 width 和 height 两个参数即可。最难实现的是左上角的缩放，四个参数需要同时变动，且关系比较复杂。特别是在引入网格布局后，缩放时要自动“吸附”临近的网格点，难上加难。\n体验2：拖动 Barad-Dur 的图表拖动可以实现图表位置的一步交换，而市面上常见的大盘产品需要进行多次拖动才能实现两个图表的交换。且在拖动过程中，图表的整体布局会被打乱，而 Barad-Dur 不会存在这样的问题。\n体验3：自动重布局 Barad-Dur 的自动重布局功能非常强大，可以支持实时布局预览（当然市面上常见的大盘产品也支持），同时大盘的布局调整会根据具体操作（缩放、拖动）的方向进行。而市面上常见的大盘产品只能在垂直方向上进行布局调整，因为所用的算法非常简单，只是粗暴地把所有图表向页面上“推”。\n体验4：任意位置 Barad-Dur 的布局支持图表在任意位置摆放，而市面上常见的大盘产品由于上述的简陋算法，不支持此功能，所有的图表必须堆叠在页面的顶部。\n体验5：布局复位 Barad-Dur 的自动重布局能够在对单个图表进行调整时将其他图表“推开”，然后更强大的是可以再将被推开的图表复位。这里找到了市面上常见的大盘产品直接拿来用的开源布局框架进行对比。该框架其实提供了上述的任意位置功能，然而由于没有布局复位的功能，导致该功能一旦启用，会令整个大盘在编辑过程中布局被扰乱，对用户起不到任何帮助，所以市面上常见的大盘产品没有启用这个功能。\n体验6：文字编辑 Barad-Dur 支持在大盘中添加静态文字以及对于文字的编辑。静态文字可用于公告、标题、说明等一些常见的大盘场景。\n功能对比 Barad-Dur 市面上常见的大盘产品 任意拖动 ✔︎ ✔︎ 任意缩放 ✔︎ ✘ 多样图表 ✔︎ ✔︎ 图表实时编辑 ✔︎ ✔︎ 图表导入导出 ✔︎ ✔︎ 任意布局 ✔︎ ✘ 添加文字 ✔︎ ✘ 综上对比，可以看出 Barad-Dur 的 WYSIWYG 编辑器在各项功能上已经领先于市面上常见的大盘产品。\n控制器 大盘，即 Dashboard (in an automobile or similar vehicle) a panel beneath the front window having various gauges and accessories for the use of the driver; instrument panel。其本意是指汽车上的仪表板，这里的仪表板包括了两类组成部分：监视器、控制器。在仪表板上不仅能看到汽车的当前状态，也能对汽车进行各种控制。这是大盘的本意，但是就目前看来，市面上所有的监控大盘产品都缺失了控制器这个重要的组成部分，导致监控大盘其实只是监视大盘。如果只是用来监视的，那大盘独立存在就没有意义，就像汽车的仪表板上只有转速表、时速表、里程表，却没有油门、刹车、换挡杆。\n我们再来看几个工业产品的大盘：\n面向普通消费者的量产产品\n面向专业消费者的量产产品\n面向专家的定制产品\n控制器是不可或缺的组成部分，甚至比监视器更加重要。Barad-Dur 提供了在大盘中设置控制按钮的功能，可以实现一些简单的控制，比如关闭/启动报警、打开钉钉聊天窗口、启动控制预案等。日后会不断加入更加强大的控制功能，让蚂蚁金服监控大盘变成一个完整的监控系统。\n技术实现 自定义数据源 上文提到 Barad-Dur 支持二次开发，支持自定义数据源，仅需一点点工作即可接入自己的数据源：\n 继承 AbstractDatasource，并实现 doRequestData 接口； 调用 registerDatasource 将数据源注册至 Barad-Dur（如果使用 Barad-Dur 的数据源编辑器，可在注册时指定自定义的数据源的编辑器）； Barad-Dur 会对所有的数据源进行包装，提供缓存、增量加载、请求合并等功能。\n统一时序数据源 为了实现自定义数据源能够在任意图表中正确展现，Barad-Dur 定义了一种 universal 的时序数据格式，支持多 key 以及多 value。所有的时序数据源（以后可能会支持非时序数据源）都会将查询结果转换为这种格式，所有的图表也都会使用这种数据格式进行展现。\n使用统一数据格式的优势在于，图表和数据源都是按照同样的数据接口（约定）来实现的，所以图表和数据源是可以独立变化的。即图表可以任意切换而不需要改动数据源配置，数据源也可以任意切换而不需要调整图表配置。这是市面上常见的大盘产品做不到的。\n另一大优势在于计算。Barad-Dur 支持数据源的简单前端计算（如计算比率的场景需要将数据 A 与数据 B 相除），在使用了统一的数据格式之后，将计算也视为一个时序数据源，它的输入是一组时序数据源，也就是说一个计算数据源可以引用另一个计算数据源。这也是市面上常见的大盘产品做不到的。\nScene Graph Scene Graph 的概念常用于游戏引擎对于场景的渲染。由于场景中各个节点有父子关系且子节点的空间关系常常用相对于父节点的量来表示，所以需要一种数据结构来将这些 local 空间的量（translation、rotation）转变为 global 空间的量，才能最终转换成屏幕空间的量用于渲染。 …","date":1592463600,"description":"本文将介绍蚂蚁金服监控产品在监控大盘方面的创新设计与尝试。","dir":"blog/antfin-monitoring-cloud-native-observable-market-design-overview/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"30e37e5824f0c80a9aef838c5db03a3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","publishdate":"2020-06-18T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","summary":"背景 蚂蚁金服业务自定义监控是蚂蚁金服监控产品中的一个重要功能，主要是通过自定义日志数据源并配置大盘的方式来解决蚂蚁金服业务实时监控的需求。在","tags":["智能监控"],"title":"蚂蚁金服智能监控云原生可观测大盘设计概览","type":"blog","url":"/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","wordcount":3490},{"author":"涵畅","categories":"Service Mesh","content":" 前言 几乎所有人都在说 Service Mesh；貌似没人知道怎么落地 Service Mesh；但是大家都觉得其他人在大力做 Service Mesh；所以大家都宣称自己在做 Service Mesh。\n上面只是开一个玩笑，但是从某种程度反映了一些实际情况：Service Mesh 是一种设计思想和理念，而不是具体的架构或者实现方式，虽然 Istio+Envoy 的配置似乎已经成了事实标准，当我们环顾四周，却发现理想太丰满，现实太骨感，因为各企业当前切实原因，导致各种形态的 Service Mesh 百花齐放。\n蚂蚁金服的 Service Mesh 就属于上面提到的百花齐放中的一员，我们已经渡过探索期，全面进入生产应用。去年的双十一完成了交易支付核心链路，几十万容器规模的生产级验证。但是业界对于 Service Mesh 仍然有很多种不同的声音，一方面是众星捧月式的支持，另一方面是困惑和质疑，包括对价值、架构以及性能的质疑。那么我们对此是什么态度？双十一深度实践之后蚂蚁金服的 Service Mesh 路又在何方？Service Mesh 架构是终点吗？\n本文将结合蚂蚁金服内部实际场景以及思考，讲述继 2019 双十一之后，蚂蚁金服在 Service Mesh 路上的规划和持续演进。\n蚂蚁金服 Service Mesh 实践回顾 上图是 2019 年蚂蚁金服双十一的实践架构，云原生网络代理 MOSN（https://github.com/mosn）作为蚂蚁金服自研数据面产品，承载了 Mesh 架构的东西向流量。对于控制平面，基于务实的前提我们探索出一套当前阶段切实可行的方案，基于传统服务发现体系落地了 Service Mesh 架构。\n这里是数据化的落地总结，在满足业务的同时，我们真正做到了对业务的低侵入：极低的资源消耗以及快速迭代能力，业务和基础技术都享受到云原生 Mesh 化所带来的红利。\nService Mesh 前路漫漫 我们再来看看 InfoQ 发布的 2020 年 4 月份 Software Architecture and Design 趋势报告，Service Mesh 目前处于 Early Adoption 代，在云原生技术圈仍处于大热阶段，各种技术论坛我们都能见到 Mesh 架构的专场，本篇文章我们不过多讨论 Service Mesh 的选型、使用场景、合理性等等问题，需要的同学可以参考一下文末历史文章，有很多蚂蚁金服对 Service Mesh 的思考。\n对于我们来说，既然在深度思考后选择了这条路，并且在去年双十一进行了深度实践，那么棋到中盘，下一步应该如何落子，除了务实落地之外，我们还要仰望星空，必须知道离诗和远方还有哪些 Gap：\n非全面云原生 前面提到我们落地 Service Mesh 时，仍然采用了传统微服务体系，虽然整体架构基于 K8s，但在控制面上并没有采用社区的方案，当然这些是有考虑的，但是随着整体架构的演进，非全面云原生化势必会成为我们持续享受云原生红利的最大障碍。\n平台能力不足 Service Mesh 的定位是解耦基础设施与业务，但是目前看来，不管是社区 Istio+Envoy 的组合，还是蚂蚁金服传统微服务+MOSN 的实践，均是把东西流量的治理作为了重点，离诗和远方还有很长的路。目前还有大量的基础设施逻辑作为 SDK 镶嵌在业务系统中，我们仍然要面临基础设施升级对业务带来的影响。\n边界流量覆盖不全 随着云原生在数据中心内部愈演愈烈，但是对于数据中心边界以及边缘网络，七层应用网络流量仍然没有形成一个全局体系，由于体系的缺失我们不得不在边界网关与 Mesh 网络两者之间各自分裂发展，均有独立的流量调度体系以及安全可信体系。\n生态融合度低 传统服务体系发展了这么多年，积累了大量宝贵的财富，Service Mesh 作为新贵出现，从两个方面来说：Service Mesh 需要传统服务体系的融入支撑，才能使现有业务迁移到 Mesh 体系；同时传统服务体系的组件也需要有和 Mesh 体系融合的能力才能持续保持竞争力。\n性能 性能是一个老生常谈的问题，Mesh 架构中质疑性能的声音也层出不穷 ，包括 Mixer 控制面，还有引入 Sidecar 造成的额外网络消耗、编解码消耗等等。不过我们可以看到社区一直在解决这些问题，包括对 Mixer 架构的重构，引入 ebpf 来加速流量劫持等等。\n综上所述，我们在 Service Mesh 上任重道远。\n将 Service Mesh 进行到底 今年我们的目标是 Mesh 全面覆盖主要业务，这将面临非常大的挑战：\n 金融级安全可信的要求，需要我们做到全链路加密与服务鉴权； 统一 Sidecar 与 Ingress Web Server； 云原生控制面的落地； 透明劫持能力； 需要承载更多的中间件能力下沉； 上面分析了目前存在的各种问题，同时结合蚂蚁金服自身的业务发展需求，那么我们可以很清晰的对症下药了，我们将上述问题抽象成三类，并进行专项攻坚：\n 以开源生态建设，来应对生态融合问题； 通过云原生标准演进，来解决非全面云原生问题； 最后通过基础核心能力增强，来治理平台能力，覆盖场景以及性能的不足的问题； 开源生态建设 我们再来回顾一下双十一之后我们做的第一个动作：在 2019 年 12 月 28 日由蚂蚁金服主办的第九期 Service Mesh Meetup 上，我们对外宣布了 MOSN 完成在 SOFAStack 的孵化，开始独立运营，以更加开放的姿态寻求合作共建伙伴：\n我们认为，未来会更多地属于那些告别大教堂、拥抱集市的人们。《大教堂与集市》\n在宣布独立运营的同时，我们也做了一系列措施：\n 独立的项目域名：mosn.io 项目地址：github.com/mosn/mosn 社区组织：MOSN Community Organization 项目管理条例：PMC、Committer 选举晋升机制等等 接下来，开源社区我们也持续做了非常多的事情，包括专题 Working Group的创建，例如 Isito WG， Dubbo WG 等等。\n同时也寻求了非常多的外部合作，超过一半的 contributor 均来自外部，接受了第一个来自 BOSS 直聘的 Committer 等等，针对生态融合，我们同Skywalking，Sentinel和Dubbo-go社区进行了深度合作。\nSkywalking 调用依赖以及服务与服务之间的调用状态，是微服务管理中一个重要指标。Skywalking 是该领域非常优秀的一款 APM 软件，MOSN 与 Skywalking 社区展开了合作，进行了两个系统的深度整合工作，目前支持：\n 调用链路拓扑展示； QPS 监控； 细粒度 RT 展示； 在今年五月份，SkyWalking 8.0 版本进行了一次全面升级，采用新的探针协议和分析逻辑，探针将更具互感知能力，更好的在 Service Mesh 下使用探针进行监控。同时，SkyWalking 将开放之前仅存在于内核中的 Metrics 指标分析体系。Prmoetheus、Spring Cloud Sleuth、Zabbix …","date":1592298000,"description":"本文将结合蚂蚁金服内部实际场景以及思考，讲述继 2019 双十一之后，蚂蚁金服在 Service Mesh 路上的规划和持续演进。","dir":"blog/service-mesh-the-road-ahead-long/","fuzzywordcount":7300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"81941474b0c2d163a199a461aaa3f2f3","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-the-road-ahead-long/","publishdate":"2020-06-16T17:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/service-mesh-the-road-ahead-long/","summary":"前言 几乎所有人都在说 Service Mesh；貌似没人知道怎么落地 Service Mesh；但是大家都觉得其他人在大力做 Service Mesh；所以大家都宣称自己在做 Service Mesh。 上","tags":["Service Mesh","源创会"],"title":"再启程，Service Mesh 前路虽长，尤可期许","type":"blog","url":"/sofastack.tech/blog/service-mesh-the-road-ahead-long/","wordcount":7212},{"author":"霄鸿","categories":"Service Mesh","content":" 引言 Service Mesh 是目前社区最为炙手可热的技术方向，去年双11在蚂蚁金服得到全面的应用，并平稳顺滑的支撑了大促服务。作为目前规模最大的 Service Mesh 集群，本文从监控的领域对 Service Mesh 落地进行经验总结，主要从以下几方面进行介绍：\n 云原生监控，介绍蚂蚁金服 Metrics 监控的落地； 用户视角分析，介绍从应用 owner 的角度对这一基础服务设施的体验以及 SRE 从全站服务的稳定性对监控提出的要求； 未来的思考，介绍后续发展方向； 云原生监控 云原生应用的设计理念已经被越来越多的开发者接受与认可，今年蚂蚁金服应用服务全面云原生化，对我们监控服务提出更高的要求。目前 Metrics 指标监控服务也逐渐形成体系，如下图所示基于社区原生 Prometheus 采集方案在蚂蚁金服监控场景下落地。\n怎么采集 蚂蚁金服监控采集 AGENT 是部署在物理机上，支持多个采集插件，如下图，包括执行命令、日志、HTTP 请求、动态 SQL 采集、系统指标采集、JVM 采集以及进程监控等，同时支持多个解析插件自定义解析、单行文本解析、Lua 脚本解析、JSON 解析以及 Prometheus 解析等。\n在Service Mesh 监控落地中，业务方参考业界标准输出 Metrics 指标数据，监控采集该物理机不同 Pod、App 和 Sidecar 的各项指标，包含 Metrics 指标和系统服务指标（CPU、MEM、DISK、JVM、IO 等），然后计算清洗集群节点通过拉取最近周期数据进行数据汇总、groupby 等，数据采集周期又分为：5秒级数据和分钟级数据。 对于 Service Mesh 来说，主要关注的指标有系统指标和 Metrics 指标：\n 系统指标（包括 Pod、App 和 MOSN 等 Sidecar 多个维度的系统指标）： 系统指标, 包含 CPU、LOAD、MEM、BYTES、TCP、UCP 等信息； 磁盘，包含分区可用空间、使用率等信息； IO，包含 IOPS 等信息； Metrics 指标： PROCESSOR，包含 MOSN 进程打开的 fd 数量、申请的虚拟内存大小等进程资源信息； GO，包含 MOSN 进程 goroutine 数量(G)、thread 数量(M)以及 memstats 等 go runtime 信息； Downstream，包含全局下游累计建链数、总读取字节数、累计请求数、请求耗时等； Upstream，包含上游请求失败次数、集群累计建链数、累计断链数、异常断链次数、上游请求平均耗时等； MQ Mesh，包含发送消息总数、耗时、失败数等以及消费消息总数、耗时、失败数等； Gateway Mesh，包含 qps、rt、限流以及多维度的成功数和失败数等； 数据计算 对于 Agent 采集的数据需要从不同维度向上汇聚，满足不同用户对不同视角（LDC、IDC、APP、架构域、站点等视角）的数据需求，以适配蚂蚁金服运维架构体系。\n此时对于这么大规模的数据体系，我们团队建设蚂蚁金服统一的监控数据计算平台。\n 使用统一的监控数据标准、插件化的数据采集接入、通用的数据服务 API 服务来帮助不同的监控产品的快速迭代； 建立一套健全的数据质量体系、高可用计算集群来保障监控数据质量； 通过类 SQL 任务定义、自定义计算任务、插件化来提供丰富、开放的数据分析能力，来满足技术风险业务领域下各种复杂数据分析的需求； 其中计算任务调度（spark）执行的关键组件包括 GS(Global-Scheduler 全局图调度)和 CS (Compute-Space 计算空间)。\nGS 是平台的任务调度中心，如下图所示，它收集了所有业务的数据源配置，根据数据源之间的计算关系，构建出全局计算任务拓扑模型(GlobalGraph)。再根据不同的任务执行策略，将全局任务拓扑图切割成小范围的任务拓扑(Graph)。主要特性有：\n GS 根据任务优先级、资源质量、负载情况等策略，将 Graph 分发到不同的计算空间进行计算(Cspace)； 同一个 Graph 内部的数据依赖是计算过程中直接依赖的； 不同的 Graph 之间的数据依赖会通过存储进行数据解耦； GS 会管理所有 Graph 及计算节点的任务状态，根据 Graph 的依赖关系和依赖 Graph 的执行状态，控制 Graph 的执行时间； CS 是计算平台抽象的计算任务执行空间，如下图所示，主要负责 Graph 的解析和具体计算任务的提交执行，适用于不同的计算引擎，如 Spark/Flink。以 Spark 为例，CS 接收到 GS 发出的 GraphTask，根据 GraphTask 中的 Node(Transform) 解析成 Spark 的 Transfomation 算子和 Action 算子，组成计算 DAG 并提交到 Spark 集群执行。\n在任务执行过程中，CS 会向 GS 同步各任务的执行状态，用于任务跟踪监控。\n多个 CSpace 组成一个 CSpaceGroup，CSpace 之间可以根据负载均衡、资源等级、蓝绿发布等具体场景划分不同的计算分组，多个 CSpace 之间的任务切流可以满足负载均衡、资源隔离、蓝绿发布、灰度等高可用的要求。\n规模化问题 对于蚂蚁金服这么大规模的 Service Mesh 集群数据，产品请求无法都通过 PromQL 方式实时查询结果，以及报警及时通知。此时我们对于监控数据进行分类，其中应用、机房、站点等维度数据进行预计算聚合，例如不同机房的 QPS、RPC 转发成功量、Error 错误等等，前端通过自定义配置出自己关注的大盘视图。\n其中今年大促 MOSN 容器达到几十万，在频繁的发布部署，上线下线过程中，对监控查看的实时性提出更高的要求。其中 Meta 元数据模块对接 K8s 集群，部署监控 operator 监控容器状态变化，达到秒级将最新采集配置通过 Agent registry 更新到 Agent 模块。\n大促保障 我们一方面对监控高可用进行保障，做到采集计算水平扩缩容，另一方面对容量进行评估，通过对不同任务进行分级处理，在大促的时候对高优先级任务进行重点保障，对低优先级任务和业务方进行沟通做降级处理。这样在监控计算资源紧张的情况下，保障核心数据稳定。\n产品视角 Service Mesh 是蚂蚁金服内部应用服务所使用的基础服务设施，对不同的用户看的视角不一样。在监控产品上，用户对产品的使用主要集中在“配、看、用”数据这三个层面。我们早期也做过类似的用户分析。在蚂蚁金服按使用方式将用户分为全局关注者，产品 owner、SRE、领域专家和普通用户等，这里监控产品对于 Service Mesh 也提供不同的视角满足不同的用户需求，举例来说：\n 产品 Owner 视角：特指 MOSN 产品的开发们，他们重点负责 MOSN 的监控指标数据覆盖、数据准确性以及重点调优目标； 普通用户视角：特指应用 Owner，应用 Owner 主要看 MOSN 服务对应用 RPC 调用的影响以及该应用使用 MOSN 服务带来的效率提升； SRE 视角：他们 …","date":1592204400,"description":"作为目前规模最大的 Service Mesh 集群，本文从监控的领域对 Service Mesh 落地进行经验总结","dir":"blog/antfin-service-mesh-monitor-landing-experience/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5728ecea53b7505a29fdd8d498a8f111","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","publishdate":"2020-06-15T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","summary":"引言 Service Mesh 是目前社区最为炙手可热的技术方向，去年双11在蚂蚁金服得到全面的应用，并平稳顺滑的支撑了大促服务。作为目前规模最大的 Service Mesh 集群，本文从","tags":["Service Mesh","智能运维"],"title":"蚂蚁金服在 Service Mesh 监控落地经验总结","type":"blog","url":"/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","wordcount":3749},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 这里有个机会和 SOFAStack 一起玩，你要不要来？ 阿里巴巴编程之夏（Alibaba Summer of Code，以下简称 ASoC）是面向全球18岁及以上本科、硕士、博士高校学生的编程普惠计划，鼓励高校学生深度参与开源开发活动，以第一视角感受开源世界的魅力，成为开源社区新鲜“血液”。\n今年 SOFAStack 开源社区也加入了选题，有兴趣的同学可以尝试下以下 feature：\nSOFAJRaft\n是基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用。\n Feature1:当前 LogStorage 的实现，采用 index 与 data 分离的设计，我们将 key 和 value 的 offset 作为索引写入 rocksdb，同时日志条目（data）写入 Segnemt Log，因为使用 SOFAJRaft 的用户经常也使用了不同版本的 rocksdb，这就要求用户不得不更换自己的 rocksdb 版本来适应 SOFAJRaft， 所以我们希望做一个改进：移除对 rocksdb 的依赖，构建出一个纯 java 实现的索引模块。这个 feature 难度适中，https://github.com/sofastack/sofa-jraft/issues/453\n Feature2:这个 feature 更有挑战些，在 multi raft group 场景中，可能有多个 raft node 在同一个进程中并且很多都是 leader，当他们各自向自己的 followers 发送心跳时会过多的消耗 CPU 和网络 IO。例如我们可以在同一个进程内共享心跳计时器并将这些 leaders 发往同一台机器的心跳请求合并起来发送出去，以此来减少系统消耗，当然你还可以提供更多的优化方案。欢迎尝试 https://github.com/sofastack/sofa-jraft/issues/454\n SOFABolt\n是基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，我们把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。\n Feature：当前的SOFABolt实现中私有协议是直接和整体框架耦合在一起的，在使用SOFABolt的同时需要使用提供的私有协议，当用户希望使用自己的自定义协议时需要进行比较有挑战的代码拓展才能实现。因此我们希望对SOFABolt的协议框架做一些重构以支持快速方便的集成用户的自定义协议。这个 feature 稍有难度，欢迎尝试，https://github.com/sofastack/sofa-bolt/issues/224 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明詹 提问：\n 问下 SOFATracer 现在支持 RabbitMQ 吗？\n A：原生 RabbitMQ API ，Tracer 是没有埋点的；如果和 Spring 集成的，可以基于 Spring Message 方式埋点。使用最新版本即可。 SOFATracer：https://github.com/sofastack/sofa-tracer\n2、@雷霆 提问：\n 请问一下，如果 TCC 在提交全局事务时失败了，比如网络或者 TC 服务异常，导致 TC 压根没有收到全局事务提交的通知，此时 TM 会抛一个异常，导致整个业务处理失败，这个时候已经在一阶段冻结的资源还会回滚吗？看了 Seata 源码，对于这种情况没有看到有触发回滚的操作。\n A：TCC 先注册分支再执行 Try，如果注册分支失败那么 Try 不会执行，如果注册分支成功了 Try 方法失败了，那应该抛出异常触发主动回滚或者触发 Server 超时回滚。\n 那如果分支已经注册成功，且 Try 也执行成功了，就是在 TM 向 TC 发起 global commit 时失败了，TM 多次重试失败后抛了异常，TC 没有收到 commit，这种情况下还会有 rollback 吗？\n A：这种情况触发超时回滚，TC 主动来回滚超时的事务。\n 明白了 谢谢~\n Seata：https://github.com/seata/seata\n本周推荐阅读 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 Forrester 中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求 社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1591945200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200612/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a85bdf92bd596c0809df4b4464b8a85b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200612/","publishdate":"2020-06-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200612/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 绝妙的机会与 SOFAStack 一起玩、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200612/","wordcount":2201},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析\n 活动时间：7 月 2 日周四晚 7 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#16：不得不说的云原生隔离性 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。本期分享将介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1265\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 不得不说的云原生隔离性 丞一 SOFABolt 开源负责人\n你将收获 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 嘉宾 SOFAGirl 主持人 丞一 SOFABolt 开源负责人 ","date":1591945200,"description":"7 月 2 日周四晚 7 点，线上直播第 17 期。","dir":"activities/sofa-channel-17/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6b021a35ee168e2bc4cb3350c6828d68","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-17/","publishdate":"2020-06-12T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-17/","summary":"概要 活动主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 活动时间：7 月 2 日周四晚 7 点 活动形式：线上直播 报名方式：戳","tags":["SOFAChannel","SOFABolt"],"title":"SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-17/","wordcount":574},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" 6月9日，在2020阿里云线上峰会上，蚂蚁联合全球知名市场研究与咨询机构 Forrester 发布《蚂蚁 SOFAStack 总体经济影响报告——金融级云原生市场趋势以及云原生平台带来的成本节省和业务优势》（以下简称“白皮书”）。《白皮书》指出，随着云计算在各行各业的落地不断深化，被技术赋能的企业早已加速构建企业级平台，通过推进数字化转型来塑造可持续的竞争力。其中云平台使能新型基础设施，赋能数字商业模式，成为了社会经济新旧动能转换和信息化应用创新发展的重要数字底座。\n云原生技术已趋向成熟 为金融企业带来全新业务价值与技术优势 Forrester 首席分析师戴鲲表示，越来越多的企业正在借助以云计算为代表的数字技术的巨大潜力，不断提供数字化的客户体验，改进卓越运营能力，加速数字创新进程，构建和扩展数字生态体系，从而加速数字化转型来塑造可持续的竞争力。\n他指出，尤其是一些积极采用新兴技术的泛金融企业，更在加速构建企业级云平台，取得了显著的早期业务成果。而伴随着在应用基础设施、应用软件架构、开发模式与部署架构四个层面协同进化与趋向成熟，云原生技术已为包括金融行业在内的各行各业的企业与机构带来了全新的业务价值与技术优势，具体表现在：\n应用基础设施 从物理机和虚拟机向大规模容器集群进化 容器技术可以实现更高密度的宿主机部署能力和伸缩性，提供更好的性能、更低的空间占用率以及更高的资源利用率，可以实现基础架构的自动化与高效率，帮助金融企业更好地满足大规模互联网业务的动态工作负载支撑要求，从而为客户获得一致的差异化体验提供有效保障。\n应用软件架构 从集中式单体和多层架构向分布式微服务架构进化 微服务框架进一步增强了应用架构伸缩性，通过模块化的复用能力与渐进式的变更能力加速应用价值交付；服务网格为微服务应用带来更为强大的服务间网络连接、可见性和安全性；无服务器计算以全新的编程模型实现应用松耦合和自动伸缩性，有效屏蔽基础架构的复杂性；而边缘计算与物联网技术的发展也使得企业计算架构从中心化向分布式演进，加速洞察的获得与决策反馈的闭环。\n开发模式 从瀑布式和敏捷式向 DevOps 进化 容器技术可以提供良好定义、一致的、高度可迁移的应用软件包，帮助改善开发和运营团队之间的协作过程。而微服务架构的细粒度可重用模块化特性可以帮助技术部门通过技术组件与业务服务的动态组装，通过与持续集成和持续交付流水线的有效集成，实现面向 DevOps 的软件交付，从而加速企业创新进程，有效提升市场响应效率，迅速满足企业内部不同业务部门与区域环境的差异化客户与业务需求。\n运营模式 从单一云环境向混合私有云与公有云的多云环境进化 根据 Forrester 的研究，面向多云、混合云环境的云平台管理能力已经成为了中国乃至全球企业的常态化需求。企业不仅需要在基础架构层面实现跨集群发布部署和跨云平台管控，而且需要具备面向异构资源的一体化管理能力，包括虚机与容器集群的混合管控、经典多层架构与微服务架构的混合支持、传统开发框架与包括大数据和机器学习等在内的新兴技术框架混合使能等。\n如何借助合作伙伴力量 以平台化方式构建金融级云原生能力？ 在迈向云原生的路上，新兴技术带来战略业务价值的同时，也必然引入更多的不确定性。一方面云原生技术依然处在快速演进阶段，距离金融行业所需要的在云端运行关键任务系统的金融级特性仍存在显著差距，另一方面，云原生技术本身在应用架构、开发测试部署过程、应用重构与迁移路径以及系统运维等各个领域都具有技术和管理复杂性。\n戴鲲指出，金融机构在云原生技术的落地实践过程中，必须通过审慎务实的整体战略规划，以平台化的方式有效构建金融级云原生能力，借助合作伙伴的技术深度、生态系统广度以及相关行业实践的专业度，加速可持续的信息化应用创新，真正释放数字基础设施的巨大潜能，需要从以下三大领域进行考虑。\n面向架构敏捷性 构建稳健的集成技术平台，打造业务创新引擎 金融行业的传统企业在长期发展历程中往往积累了大量的技术资产，因此，金融级云原生平台不仅必须具备融合支持能力，还应当以工具化、产品化的方式，帮助开发与运维团队实现云原生应用的快速开发迭代与对存量应用资产的平滑迁移，从而加速金融业务创新进程。\n聚焦业务连续性 基于金融技术风险防控，保障业务稳妥演进 金融级云原生平台必须能够在混合环境下，具备业务同城双活甚至异地多活的高可用容灾能力，而且能够基于单元化架构和数据分片等技术，实现多活容灾的单元化。同时，还应当具备灵活可控的应用发布进程，通过按需暂停回滚、分组灰度发布和原地升级等能力，实现应用的平滑演进；并具备可定制的流程编排能力，实现巡检诊断与容灾应急的自动化。\n追求运维精益性 关注安全可信稳定连续，降低运维保障成本 首先，金融级云原生平台必须具备基于策略的弹性规则配置能力，并通过多维度资源分析、网络流量调拨、实时指标评估以及灵活的回滚方式支持等技术，实现优雅的弹性伸缩。其次，平台必须为全链路可观测性提供支持，不仅提供多维度的监控数据，而且具备场景化的支持能力。最后，平台必须从应用视角出发，结合服务目录、服务网格、日志服务、链路跟踪等技术组件，为大规模分布式业务系统提供可视化的自动化运维能力，有效简化云原生运维过程。\nForrester 为众多希望推动完成数字化转型的金融企业和机构在云计算发展领域提出了以上有关发展方向的战略建议。蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）作为构建金融级云原生架构的应用平台，沉淀了金融场景的最佳实践。在企业面向金融级环境采用云原生技术过程中面临困难时，蚂蚁 SOFAStack 能够提供从服务构建、应用开发、部署发布、服务治理、监控运维、容灾高可用等全生命周期、全栈式解决方案，兼容 Dubbo、Spring Cloud 等微服务运行环境，助力客户各类应用轻松转型分布式架构。\n点击，获取完整 《白皮书》\n","date":1591858800,"description":"云原生技术已趋向成熟 为金融企业带来全新业务价值与技术优势","dir":"blog/forrester-daipeng-white-paper-cloud-native/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"eb590c61c39c7b48afdb5abd95889b99","permalink":"https://sofastack.github.io/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","publishdate":"2020-06-11T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","summary":"6月9日，在2020阿里云线上峰会上，蚂蚁联合全球知名市场研究与咨询机构 Forrester 发布《蚂蚁 SOFAStack 总体经济影响报告——金融级云原生市场趋势以及云原生平台","tags":["SOFAStack","云原生"],"title":"Forrester 中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求","type":"blog","url":"/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","wordcount":2340},{"author":"诣极","categories":"MOSN","content":" 背景 蚂蚁金服内部对 Service Mesh 的稳定性和性能要求是比较高的，内部 MOSN 广泛用于生产环境。在云上和开源社区，RPC 领域 Dubbo 和 Spring Cloud 同样广泛用于生产环境，我们在 MOSN 基础上，支持了 Dubbo 和 Spring Cloud 流量代理。我们发现在支持 Dubbo 协议过程中，经过 Mesh 流量代理后，性能有非常大的性能损耗，在大商户落地 Mesh 中也对性能有较高要求，因此本文会重点描述在基于 Go 语言库 dubbo-go-hessian2 、Dubbo 协议中对 MOSN 所做的性能优化。\n性能优化概述 根据实际业务部署场景，并没有选用高性能机器，使用普通 Linux 机器，配置和压测参数如下：\n Intel\u0026amp;reg; Xeon\u0026amp;reg; Platinum 8163 CPU @ 2.50GHz 4核16G； pod 配置 2c、1g，jvm 参数 -server -Xms1024m -Xmx1024m； 网络延迟 0.23ms, 2台 Linux 机器，分别部署 server+MOSN, 压测程序 rpc-perfomance； 经过3轮性能优化后，使用优化版本 MOSN 将会获得以下性能收益(框架随机512和1k字节压测)：\n 512字节：MOSN+Dubbo 服务调用 tps 整体提升55-82.8%，rt 降低45%左右，内存占用 40M； 1k数据：MOSN+Dubbo 服务调用 tps 整体提升51.1-69.3%，rt 降低41%左右, 内存占用 41M； 性能优化工具 pprof 磨刀不误砍柴工，在性能优化前首先要找到性能卡点，找到性能卡点后，另一个难点就是如何用高效代码优化替代 slow code。因为蚂蚁金服 Service Mesh 是基于 Go 语言实现的，我们首选 Go 自带的 pprof 性能工具，我们简要介绍这个工具如何使用。如果我们 Go 库自带 http.Server 时并且在 main 头部导入import _ \u0026amp;quot;net/http/pprof\u0026amp;quot;，Go 会帮我们挂载对应的 handler, 详细可以参考 godoc 。\n因为 MOSN 默认会在34902端口暴露 http 服务，通过以下命令轻松获取 MOSN 的性能诊断文件：\ngo tool pprof -seconds 60 http://benchmark-server-ip:34902/debug/pprof/profile # 会生成类似以下文件，该命令采样cpu 60秒 # pprof.mosn.samples.cpu.001.pb.gz 然后继续用 pprof 打开诊断文件，方便在浏览器查看，在图1-1给出压测后 profiler 火焰图：\n# http=:8000代表pprof打开8000端口然后用于web浏览器分析 # mosnd代表mosn的二进制可执行文件，用于分析代码符号 # pprof.mosn.samples.cpu.001.pb.gz是cpu诊断文件 go tool pprof -http=:8000 mosnd pprof.mosn.samples.cpu.001.pb.gz 在获得诊断数据后，可以切到浏览器 Flame Graph(火焰图，Go 1.11以上版本自带)，火焰图的 X 轴坐标代表 CPU 消耗情况，Y 轴代码方法调用堆栈。在优化开始之前，我们借助 Go 工具 pprof 可以诊断出大致的性能卡点在以下几个方面(直接压 Server 端 MOSN)：\n MOSN 在接收 Dubbo 请求，CPU 卡点在streamConnection.Dispatch； MOSN 在转发 Dubbo 请求，CPU 卡点在 downStream.Receive； 可以点击火焰图任意横条，进去查看长方块耗时和堆栈明细（请参考图1-2和1-3所示）：\n性能优化思路 本文重点记录优化了哪些 case 才能提升 50%+ 的吞吐量和降低 rt，因此后面直接分析当前优化了哪些 case。在此之前，我们以 Dispatch 为例，看下它为啥那么吃性能 。在 terminal 中通过以下命令可以查看代码行耗费 CPU 数据（代码有删减）：\ngo tool pprof mosnd pprof.mosn.samples.cpu.001.pb.gz (pprof) list Dispatch Total: 1.75mins 370ms 37.15s (flat, cum) 35.46% of Total 10ms 10ms 123:func (conn *streamConnection) Dispatch(buffer types.IoBuffer) { 40ms 630ms 125:\tlog.DefaultLogger.Tracef(\u0026amp;quot;stream connection dispatch data string = %v\u0026amp;quot;, buffer.String()) . . 126: . . 127:\t// get sub protocol codec . 250ms 128:\trequestList := conn.codec.SplitFrame(buffer.Bytes()) 20ms 20ms 129:\tfor _, request := range requestList { 10ms 160ms 134:\theaders := make(map[string]string) . . 135:\t// support dynamic route 50ms 920ms 136:\theaders[strings.ToLower(protocol.MosnHeaderHostKey)] = conn.connection.RemoteAddr().String() . . 149: . . 150:\t// get stream id 10ms 440ms 151:\tstreamID := conn.codec.GetStreamID(request) . . 156:\t// request route . 50ms 157:\trequestRouteCodec, ok := conn.codec.(xprotocol.RequestRouting) . . 158:\tif ok { . 20.11s 159:\trouteHeaders := requestRouteCodec.GetMetas(request) . . 165:\t} . . 166: . . 167:\t// tracing 10ms 80ms 168:\ttracingCodec, ok := conn.codec.(xprotocol.Tracing) . . 169:\tvar span types.Span . . 170:\tif ok { 10ms 1.91s 171:\tserviceName := tracingCodec.GetServiceName(request) . 2.17s 172: …","date":1591686000,"description":"本文将重点描述在基于 Go 语言库 dubbo-go-hessian2、Dubbo 协议中对 MOSN 所做的性能优化。","dir":"blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2584f4b7cd5bf07fb458ef9fbe60433c","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","publishdate":"2020-06-09T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","summary":"背景 蚂蚁金服内部对 Service Mesh 的稳定性和性能要求是比较高的，内部 MOSN 广泛用于生产环境。在云上和开源社区，RPC 领域 Dubbo 和 Spring Cloud 同样广泛用于生产环境，我们在","tags":["MOSN"],"title":"记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化","type":"blog","url":"/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","wordcount":4450},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@林尤庆 提问：\n 请问 SOFARPC 支持 fegin 不？\n A：SOFARPC 发的 rest 服务，feign 的方式是可以调用的，但是跟 ribbon 是没打通的。\n 有具体的例子不？\n A：https://github.com/sofastack/spring-cloud-sofastack-samples\n 我想问下 SOFARegistry 能像 Nacos 那样注册的是整个服务的名称么，现在 SOFARegistry 是细到接口。Spring Cloud是以整个应用注册的，SOFARegistry 是以每一个SofaServicce 注册的。\n A：SOFARegistry 和 Nacos 都是注册中心服务端产品，存的都是 key: list\u0026amp;lt; string \u0026amp;gt; 这样的数据结构，里面存什么数据是由他们的客户端决定的。SOFARPC 就算是注册中心的客户端。\n SOFARegistry 是以每一个 SofaServicce 注册的，fegin 访问的话也是每一个 SofaServicce 去访问的，不是整个应用访问的？\n A：跟 SOFARegistry 没关系，是 SOFARPC 的实现，目前按接口维度注册的。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n2、@姜哲 提问：\n SOFARPC 能发布一个 https 协议的服务吗？\n A：https 不行，h2（http/2+tls）是可以的。\n SOFABoot 环境下怎么发布？有 Demo 吗？\n A：基于 SOFABoot 可能没有适配， 可以先看下 API 方式的： https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/http2/Http2WithSSLServerMain.java\nSOFARPC：https://github.com/sofastack/sofa-rpc\n本周推荐阅读 多点生活在 Service Mesh 上的实践 | 线上直播整理 Service Mesh 中的可观察性实践 | 线上直播整理 Apache SkyWalking 在 Service Mesh 中的可观察性应用 | 线上直播回顾 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 陌陌的 Service Mesh 探索与实践 | 线上直播回顾 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.13.0 版本，主要变更如下：\n 新增 Strict DNS Cluster、GZIP 处理、单机故障隔离； 集成 Sentinel 实现限流能力； 优化 EDF 算法，使用 EDF 算法重新实现 WRR 算法； 支持 Dubbo 服务发现 Beta 版本，优化 Dubbo Decode 性能； 部分实现优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.13.0\n社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1591340400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200605/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9ba8595438771312ed9c187e57789bad","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200605/","publishdate":"2020-06-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200605/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发版、Service Mesh 相关文章整理、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200605/","wordcount":1488},{"author":"陈鹏","categories":"Service Mesh","content":" Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。\n 本文根据5月28日晚 Service Mesh Webinar#1 多点生活平台架构组研发工程师陈鹏，线上主题分享《多点生活在 Service Mesh 上的实践 \u0026amp;ndash; Istio + Mosn 在 Dubbo 场景下的探索之路》整理，文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处。如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点。\n今天主要给大家分享一下 Service Mesh 的一些技术点以及多点生活在 Service Mesh 落地过程中适配 Dubbo 的一些探索。\n首先我们从三个方面入手：\n 为什么需要 Service Mesh 改造； 探索 Istio 技术点； Dubbo 场景下的改造； 为什么需要 Service Mesh 改造 说到为什么需要改造，应该先说一下 Service Mesh 和传统微服务架构的一些特点。\n微服务 微服务一般有这些模块：\n 安全； 配置中心； 调用链监控； 网关； 监控告警； 注册和发现； 容错和限流； 这些模块在传统的微服务架构中有的是和 SDK 结合在一起，有的是一个独立的中间件。\n特点：\n 独立部署； 模块的边界； 技术多样性； 正是由于技术多样性，我的微服务系统可以使用不同的语言进行开发，比如我一个商城系统，订单系统使用 Java 开发，库存系统使用 Go 开发，支付系统使用 Python 开发，微服务之间通过轻量级通信机制协作，比如：HTTP/GRPC 等。比如目前多点使用的 Dubbo(服务治理框架)，随着多点生活的业务发展，目前遇到最棘手的问题就是中间件在升级过程中，推进很慢，需要业务方进行配合，接下来我们看看 Service Mesh。\nService Mesh 优点：\n 统一的服务治理； 服务治理和业务逻辑解藕； 缺点：\n 增加运维复杂度； 引入延时； 需要更多技术栈； 看了 Service Mesh 的优缺点，如果我们 Mesh 化了之后就可以解决我们目前的痛点，升级中间件只需要重新发布一下 Sidecar 就好了，不同语言开发的微服务系统可以采用同样的服务治理逻辑，业务方就可以尝试更多的技术。\n探索 Istio 技术点 在谈 Dubbo 场景下的改造之前我们先介绍一下 Istio 相关的技术点，然后结合 Dubbo 场景应该如何进行适配\nMCP MCP（Mesh Configuration Protocol）提供了一套用于订阅(Watch)、推送(Push)的 API，分为 Source 和 Sink 两个角色。\n Source 是资源提供方(server)，资源变化了之后推送给订阅者(Pilot)，Istio 1.5 之前这个角色就是 Galley 或者自定义 MCP Server； Sink 是资源的订阅者(client)，在 Istio 1.5 之前这个角色就是 Pilot 和 Mixer，都是订阅 Galley 或者自定义 MCP Server 的资源 MCP 的订阅、推送流程图:\n为了和实际情况结合，我们就以 MCPServer 作为 Source，Pilot 作为 Sink 来介绍订阅、推送流程，其中 MCP 通信过程中所传输的「资源」就是 Istio 定义的 CRD 资源，如：VirtualService、DestinationRules 等。\n订阅 Pilot 启动后会读取 Configmap 的内容，里面有一个 configSources 的一个数组配置（Istio 1.5 之后没有这个配置，需要自己添加）、存放的是 MCP Server 的地址； Pilot 连接 MCPServer 之后发送所关注的资源请求； MCPServer 收到资源请求，检查请求的版本信息（可能为空），判断版本信息和当前最新维护的版本信息是否一致，不一致则触发 Push 操作，一致则不处理； Pilot 收到 Push 数据，处理返回的数据（数据列表可能为空，为空也标示处理成功），根据处理结果返回 ACK（成功）/ NACK（失败），返回的应答中包含返回数据的版本信息，如果返回的是 NACK，Pilot 会继续请求当前资源； MCPServer 收到 ACK（和资源请求一致）之后对比版本号，如果一致则不推送，否则继续推送最新数据； 推送 MCPServer 自身数据发生变化，主动推送变化的资源给 Pilot； Pilot 收到之后处理这些数据，并根据处理结果返回 ACK / NACK； MCPServer 收到 ACK（和资源请求一致） 之后对比版本号，如果一致则不推送，否则继续推送最新数据； 这样的订阅、推送流程就保证了 MCPServer 和 Pilot 资源的一致。MCPServer 只能通过 MCP 协议告诉 Pilot 资源发生变化了么？当然不是，MCPServer 可以使用创建 CR 的方式，Pilot 通过 Kubernetes 的 Informer 机制也能感知到资源发生变化了，只是通过 MCP 传输的资源在 Kubernetes 里面看不到，只是存在于 Pilot 的内存里面，当然也可以通过 Pilot 提供的 HTTP debug 接口（istiod_ip:8080/debug/configz）来查。\nhttps://github.com/champly/mcpserver 提供了一个 MCPServer 的一个 demo，如果需要更加细致的了解 MCP 原理可以看一看。\n 更多 debug 接口可以查看: https://github.com/istio/istio/blob/5b926ddd5f0411aa50fa25c0a6f54178b758cec5/pilot/pkg/proxy/envoy/v2/debug.go#L103\n Pilot Pilot 负责网格中的流量管理以及控制面和数据面之前的配置下发，在 Istio 1.5 之后合并了 Galley、Citadel、Sidecar-Inject 和 Pilot 成为 Istiod。我们这里说的是之前 Pilot 的功能，源码里面 pilot-discovery 的内容。\n功能 根据不同平台（Kubernetes、Console）获取一些资源，Kubernetes 中使用 Informer 机制获取 Node、Endpoint、Service、Pod 变化； 根据用户的配置（CR、MCP 推送、文件）触发推送流程； 启动 gRPC server 用于接受 Sidecar 的连接； 推送流程 记录变化的资源类型； 根据变化的资源类型(数组)整理本地数据； 根据变化的资源类型判断需要下发的 xDS 资源； 构建 xDS 资源， …","date":1591264800,"description":"本文主要给分享 Service Mesh 的一些技术点以及多点生活在 Service Mesh 落地过程中适配 Dubbo 的一些探索。","dir":"blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"99f4c0638c5fbd0b762ce8d373142ae0","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","publishdate":"2020-06-04T18:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","summary":"Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。 本文根据5月28日晚 Service Mesh Webinar#1 多点生活平台架构","tags":["Service Mesh","Service Mesh Webinar"],"title":"多点生活在 Service Mesh 上的实践 -- Istio + Mosn 在 Dubbo 场景下的探索之路","type":"blog","url":"/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","wordcount":5590},{"author":"叶志远","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖如何使用 SkyWalking 来观测 Service Mesh，来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务监控的区别。\n本文根据5月14日晚，G7 微服务架构师叶志远的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 谈到 Service Mesh，人们总是想起微服务和服务治理，从 Dubbo 到 Spring Cloud (2016开始进入国内研发的视野，2017年繁荣)再到 Service Mesh (2018年开始被大家所熟悉)，正所谓长江后浪推前浪，作为后浪，Service Mesh 别无选择，而 Spring Cloud 对 Service Mesh 满怀羡慕，微服务架构的出现与繁荣，是互联网时代架构形式的巨大突破。Service Mesh 具有一定的学习成本，实际上在国内的落地案例不多，大多是云商与头部企业，随着性能与生态的完善以及各大社区推动容器化场景的落地，Service Mesh 也开始在大小公司生根发芽，弥补容器层与 Kubernetes 在服务治理方面的短缺之处。本次将以一个选型调研者的视角，来看看 Service Mesh 中的可观察性主流实践方案。\n可观察性的哲学 可观察性（Observability）不是一个新名词，它在很久之前就已经诞生了，但是它在 IT 领域却是一个新兴事物。可观察性在维基百科中原文是这样定义的：“In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. ”。云原生领域第一次出现这个词，是在云原生理念方兴未艾的2017年，在云原生的思潮之下，运用传统的描述方式已经不足以概括这个时代的监控诉求，而 Observability 就显得贴切许多。\n回想一下传统的监控方式，除去运维层面的主机监控、JVM 监控、消息队列监控之外，有多少监控是事先就想好怎么做的？很少！其实很多时候，我们做的事情就是在故障发生之后，对故障复盘的过程中，除了 bug 重现与修复，也会去定制加一些监控，以期望下次发生同样的情况时有一个实时的告警。研发人员收到告警之后得以快速地处理问题，尽可能地减少损失。所以，传统的监控模式大多都是在做亡羊补牢的事情，缺少一个主动性。\n在云原生时代的容器化体系当中就不一样了，容器和服务的生命周期是紧密联系在一起的，加上容器完美的隔离特性，再加上 Kubernetes 的容器管理层，应用服务跑在容器当中就显得更加地黑盒化，相较在传统物理主机或者虚拟机当中，排查问题的时候显得非常不便。所以在云原生时代强调的是可观察性，这样的监控永远都是兵马未动而粮草先行的，需要提前想好我们要如何观察容器内的服务以及服务之间的拓扑信息、各式指标的搜集等，这些监测能力相当重要。\n关于可观察性在云原生领域是何时开始流行起来的，没有一个很明确的时间。业界认为可观察性最早是由 Cindy Sridharan 提出的，其实一位德国柏林的工程师 Peter Bourgon 早在2017年2月就已经有文章在讨论可观察性了，Peter 算是业界最早讨论可观察性的开发者，他写的著名的博文《Metrics, Tracing, and Logging》被翻译成了多种语言。真正可观察性成为一种标准，是来自 Pivotal 公司的 Matt Stine 定义的云原生标准，可观察性位列其中，由此可观察性就成为了云原生时代一个标准主题。\nPeter Bourgon 提出的可观察性三大支柱围绕 Metrics、Tracing 和 Logging 展开，这三个维度几乎涵盖了应用程序的各种表征行为，开发人员通过收集并查看这三个维度的数据就可以做各种各样的事情，时刻掌握应用程序的运行情况，关于三大支柱的理解如下：\n Metrics：Metrics 是一种聚合态的数据形式，日常中经常会接触到的 QPS、TP99、TP95 等等都属于Metrics 的范畴，它和统计学的关系最为密切，往往需要使用统计学的原理来做一些设计； Tracing：Tracing 这个概念几乎是由 SOA 时代带来的复杂性补偿，服务化带来的长调用链，仅仅依靠日志是很难去定位问题的，因此它的表现形式比 Metrics 更复杂，好在业界涌现出来了多个协议以支撑 Tracing 维度的统一实现； Logging：Logging 是由请求或者事件触发，应用程序当中用以记录状态快照信息的一种形式，简单说就是日志，但这个日志不仅仅是打印出来这么简单，它的统一收集、存储以及解析都是一个有挑战的事情，比如结构化(Structured)与非结构化(Unstructed)的日志处理，往往需要一个高性能的解析器与缓冲器； 此外，Peter Bourgon 在博文中还提到了三大支柱结合态的一些理想输出形式，以及对存储的依赖，Metrics、Tracing、Logging 由于聚合程度的不同，对存储依赖由低到高。更多细节，感兴趣的同学可以查看文末的原文链接。\nPeter Bourgon 关于可观察性三大支柱的思考不止于此，他还在2018年的 GopherCon EU 的分享上面再次讨论了 Metrics、Tracing 和 Logging 在工业生产当中的深层次意义，这次他探讨了4个维度。\n CapEx：表示指标初始收集成本，很明显日志的成本最低，埋点即可；其次是 Metrics，最难是 Tracing 数据，在有了协议支撑的情况下，依然要定义许多数据点，以完成链路追踪必须的元数据定义收集； OpEx：表示运维成本，一般指存储成本，这个之前已经讨论过； Reaction：表示异常情况的响应灵敏度，显然聚合之后的数据可以呈现出波动情况，因此 Metrics 是对异常情况最灵敏的；Logging 次之，也可以从 Logging 清洗之中发现异常量；而 Tracing 在响应灵敏度上面似乎沾不上边，最多还是用在排障定位的场景； Investigation：标准故障定位能力，这个维度是 Tracing 的强项，可以直观看出链路当中的故障，精确定位；Logging 次之；Metrics 维度只能反馈波动，对定位故障帮助不大； 在 CNCF Landscape 当中，有一块区域专门用作展示云原生场景下的可观察性解决方案，里面又分为好几个维度，图中是截至2020年5月14日的最新版图，未来还会有更多优秀的解决方案涌现出来。CNCF 目前毕业的10个项目库当中，有3个是和可观察性有关的， …","date":1591092000,"description":"本文根据 G7 微服务架构师叶志远线上分享整理，以一个选型调研者的视角，来看看 Service Mesh 中的可观察性主流实践方案。","dir":"blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a4bde9dc8721fabf285171be403d7f5a","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","publishdate":"2020-06-02T18:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖如何使","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Service Mesh 中的可观察性实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","wordcount":8781},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@钱德鹏 提问：\n 官网的泛化调用 Demo 地址为https://www.sofastack.tech/projects/sofa-rpc/generic-invoke，代码如下： 这段代码里 consumerConfig 没有指定 directUrl，那么是如何获取服务地址的？自己测试时，如果不指定 directUrl，那么会报找不到服务的错误；如果指定 directUrl，可以正常调用。所以想问一下到底需不需要指定？\n ConsumerConfig consumerConfig = new ConsumerConfig() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); A：你这个跟是否跟泛化调用没关系。 RPC 调用肯定是要拿到对方的服务端地址的，这里要么走注册中心去做服务发现，要么走指定直连地址。\n 明白，我的意思是官网的 Demo 里面没指定 URL，那么他是怎么调用成功的？既然官网没有指定，为什么我不指定就调用不到？另外附加一个问题，如果说一定要指定地址，那么我指定成 SLB 地址，由 SLB 去分发，是否可行？\n A：你说官网的 Demo 是哪个？\n https://www.sofastack.tech/projects/sofa-rpc/generic-invoke\n A：这里应该是代码片段，不是完整 Demo。Example 可以参加 https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/invoke/generic/GenericClientMain.java 指定成 SLB 地址是可以的，不过是 slb 跟服务端是长连接，建立了就不断了，服务端负载不一定会均衡。\n 好的，是否可以认为如果像 Demo 里这样调用，就必须指定 directUrl？\n A：对，使用 ZK 为注册中心的例子就是： https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/zookeeper/start/ZookeeperBoltClientMain.java\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@王振 提问：\n 请问，配置 Nacos，如果 Nacos 是集群部署的话，那 Seata 配置 Nacos 地址的时候是不是只需要填写 Nacos 集群地址就行了，不要三个都填的吧？\n A：Nacos 集群不是填3个地址嘛？你自己做了前端负载？\n 用 Nginx 去做了，在 Nacos 之上加入了 Nginx 做了负载均衡，那在 Seata 配置上是不是只需要配置负载均衡的地址就可以了是吗？如果不做负载的话，那填三个地址是逗号隔开吗？\n A：是的，跟直接使用 Nacos 集群写法一致，我们把这个属性透传给 Nacos。\n 是 ip:port,ip:port,ip:port 这种形式对吧？\n A：是的。\n 另外，请问 Seata 对服务器有最低要求吗？\n A：server 推荐 2C4G+ 吧，jvm 内存2G+。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Apache SkyWalking 在 Service Mesh 中的可观察性应用 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 陌陌的 Service Mesh 探索与实践 - 直播回顾 剖析 SOFARPC 框架 【剖析 | SOFARPC 框架】系列之SOFARPC 序列化比较 【剖析 | SOFARPC 框架】系列之SOFARPC跨语言支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 路由实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 优雅关闭剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 数据透传剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 泛化调用实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 单机故障剔除剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 线程模型剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 同步异步实现剖析 【剖析 | SOFARPC 框架】系列之连接管理与心跳剖析 【剖析 | SOFARPC 框架】系列之链路追踪剖析 【剖析 | SOFARPC 框架】系列之总体设计与扩展机制 ","date":1590735600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200529/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2009de6439107016241e7f8efc5a665c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200529/","publishdate":"2020-05-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200529/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 系列直播回顾、SOFARPC 剖析回顾","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200529/","wordcount":1431},{"author":"高洪涛","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖 Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh，来自陌陌和百度的 Service Mesh 生产实践。\n本文根据5月7日晚，美国 Service Mesh 服务商 Tetrate 创始工程师高洪涛的主题分享《Apache SkyWalking 在 Service Mesh 中的可观察性应用》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 本次演讲为大家分享的是 Apache SkyWalking 对 Service Mesh 可观测性方面的应用实践，共分为三个部分：\n 第一部分是 Apache SkyWalking 的相关背景； 第二部分是 Service Mesh 场景下 SkyWalking 所面临的挑战； 最后是针对 Service Mesh 场景方案的演化； SkyWalking 的历史沿革及其特点 SkyWalking 项目的建设目的是为了解决在微服务环境下，如何快速的定位系统稳定性问题。创始团队于2016年启动项目，经过一年的努力完善了最初的版本。2017年，团队启动将项目捐献给 Apache 基金会的流程。在 Apache 基金会孵化器内，经过了多轮系统升级迭代，并获得近乎翻倍的贡献者和关注度，于2019年顺利毕业。经过经年的升级与维护，SkyWalking 从最开始专注于分布式追踪系统的单一平台，发展为包含多个门类并拥有丰富的功能的全领域 APM 系统。\nSkyWalking 整体的系统架构包括有三个部分:\n 第一个是数据采集端，可以使用语言探针对系统的监控指标进行采集，同时也提供了一套完整的数据采集协议。第三方系统可以使用协议将相关的监控数据上报到分析平台。 第二部是分析平台，主要包括对监控指标数据的搜集，流式化处理，最终将数据写到存储引擎之中。存储引擎可使用Elasticsearch，MySQL数据库等多种方案。 第三部分是 UI。UI 组件有丰富的数据展示功能，包含指标展板，调用拓扑图，跟踪数据查询，指标比较和告警等功能。 在此基础上，SkyWalking 本身组件具有丰富的定制功能，方便用户去进行二次开发以支持自己特有的场景。\nSkyWalking 定义了三个维度用来绑定相关的监控指标数据。\n 服务(Service)：表示对请求提供相同行为的一系列或一组工作负载。在使用打点代理或 SDK 的时候, 你可以定义服务的名字。如果不定义的话，SkyWalking 将会使用你在平台上定义的名字, 如 Istio。 实例(Instance)：上述的一组工作负载中的每一个工作负载称为一个实例。就像 Kubernetes 中的 Pod 一样, 服务实例未必就是操作系统上的一个进程。但当你在使用打点代理的时候，一个服务实例实际就是操作系统上的一个真实进程。 端点(Endpoint)：对于特定服务所接收的请求路径，如 HTTP 的 URL 路径和 gRPC 服务的类名 + 方法签名。 预定义的维度可以方便的进行数据预汇集操作，是 SkyWalking 分析引擎重要的组成部分。虽然其相对的会有使用不够灵活的缺点，但在 APM 场景下，指标往往都是预先经过精心设计的，而性能才是关键因素。故 SkyWalking 采用这种预定义维度模式来进行数据汇集操作。\nService Mesh 场景下 SkyWalking 面对的挑战 在描述 Service Mesh 的场景下所面临的挑战之前，需要去解释可观测性所包含的含义。可观测性一般包含有三个部分:\n 第一点，日志系统。由其可以构建出系统运行的实时状态。故日志成为非常方便的观测手段。 第二点，分布式追踪。这部分数据在微服务场景下具有强大的生命力，可以提供给用户分布式系统观测指标。 第三点，指标监控。相比于日志和分布式追踪，其具有消耗小，处理简便等特点，通常作为系统监测告警的重要数据来源。 如上所示是 Istio1.5 的架构图。重点看一下他对可观测性的支持。从图上看，所有的监控指标都汇聚到中间的 Mixer 组件，然后由 Mixer 再发送给他左右的 Adapter，通过 Adapter 再将这些指标发送给外围的监控平台，如 SkyWalking 后端分析平台。在监控数据流经 Mixer 的时候，Istio 的元数据会被附加到这些指标中。另一种新的基于 Telemetry V2 观测体系是通过 Envoy 的 Proxy 直接将监控指标发送给分析平台，这种模式目前还处于快速的演进和开发中，但是它代表着未来的一种趋势。\n从架构图中我们可以看到，这里面的第一个挑战就是 Service Mesh 场景下，对于可观测性的技术体系的支持是非常多变的。\nIstio 本身就包括两种不融合的体系，第一种是基于 Mixer 的场景，第二种是 Mixerless 场景。\nMixer 是基于访问日志进行指标生成的，也就是说服务与服务之间的访问日志经过 Mixer 增加相关的原数据后再发给外围分析系统。其特点是这个模式非常的成熟、稳定，但是性能会非常的低。它的低效源于两个方面，第一点是他的数据发送通道很长，中间节点过多。可以看到数据需要到从 Proxy 发送到 Mixer 节点，再发送给外围的 Adapter 节点。另一个效能低下的原因主要是体现在它发送的是原始访问日志，其数据量是非常大的，会消耗过多的带宽，这对整体的数据搜集与分析提出了非常大的挑战。\n另一种模式是 Mixerless，它完全是基于 Metrics 指标的。通过可观测性包含的技术及其特点分析可知，它是一种消耗比较小的技术，对带宽以及分析后台都是非常友好的。但是它同时也有自己的问题，第一个问题就是他需要的技术门槛是比较高的（使用 WASM 插件来实现），并且对于 Proxy 端的性能消耗也是比较大的。同时由于是新的技术，稳定性较差，相关接口与规范并不完整。\n第二个挑战就是无 Tracing 数据。SkyWalking 最早是为了收集处理跟踪数据（Tracing）而设计的一套系统，但是我们可以从右边的图发现，对于 Service Mesh 上报的数据其实是基于调用的，也就是说它不存在一条完整的跟踪链路。这样就对后台的分析模型有比较大的挑战，如何才能同时支持好这两种模式成为后端分析系统所要处理的棘手问题。\n第三个挑战就是维度匹配的问题。我们从前一章可以看到 SkyWalking 是包括三个维度的，其中对于实例和端点，在 Service Mesh 场景下都是有比较好的支持。这里多说一句，不仅仅是对 Mesh 场景，对于大部分场景都可以很好的去匹配它们。但是对于服务的匹配是有相当大难度的，因为 SkyWalking 只有服务这一层的概念，而在 Istio 中有好几个概念可以称之为“服 …","date":1590649200,"description":"本文根据5月7日晚，美国 Service Mesh 服务商 Tetrate 创始工程师高洪涛的主题分享《Apache SkyWalking 在 Service Mesh 中的可观察性应用》整理。","dir":"blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2414682129ca15d4cfc86bffc6694aaa","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","publishdate":"2020-05-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖 Service Mesh 的","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Apache SkyWalking 在 Service Mesh 中的可观察性应用","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","wordcount":4356},{"author":"罗广明","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。\n本文根据5月13日晚，百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 Service Mesh 在企业落地中有诸多挑战，当与传统微服务应用共同部署治理时可用性挑战更为严峻。本次分享将以 Service Mesh 与 Spring Cloud 应用互联互通共同治理为前提，着重介绍基于 Consul 的注册中心高可用方案，通过各种限流、熔断策略保证后端服务的高可用，以及通过智能路由策略（负载均衡、实例容错等）实现服务间调用的高可用。\nService Mesh 与 Spring Cloud 应用的互通、互联 微服务是时下技术热点，大量互联网公司都在做微服务架构的推广和落地。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。而在这个技术转型中，国内有一个现象，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。近年来，新兴的 Service Mesh 技术也越来越火热，受到越来越多开发者的关注，大有后来居上的趋势。\n在听到社区里很多人谈到微服务技术选型时，注意到他们讨论一个非此即彼的问题：采用 Spring Cloud 还是以 Istio 为代表的 Service Mesh 技术？然而这个答案并非非黑即白、非你即我，一部分应用采用 Spring Cloud，另一部分采用 Service Mesh（Istio）是完全可能的。今天我就和大家一起来讨论这个问题。\n首先，我们来看一下 Spring Cloud 这个传统侵入式微服务框架。它包含以下优点：\n 集大成者，Spring Cloud 包含了微服务架构的方方面面；选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架； 轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者； 开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发； 开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件； 特别感谢 Netflix，这家很早就成功实践微服务的公司，几年前把自家几乎整个微服务框架栈贡献给了社区，早期的 Spring Cloud 主要是对 Netflix 开源组件的进一步封装。不过近两年，Spring Cloud 社区开始自研了很多新的组件，也接入了其他一些互联网公司的优秀实践。\n接下来，我们简单看一下 Service Mesh 框架。它带来了两大变革：微服务治理与业务逻辑的解耦，异构系统的统一治理。此外，服务网格相对于传统微服务框架，还拥有三大技术优势：可观察性、流量控制、安全。服务网格带来了巨大变革并且拥有其强大的技术优势，被称为第二代“微服务架构”。\n然而就像之前说的软件开发没有银弹，传统微服务架构有许多痛点，而服务网格也不例外，也有它的局限性。这些局限性包括：增加了链路与运维的复杂度、需要更专业的运维技能、带来了一定的延迟以及对平台的适配。\n更多关于 Spring Cloud 与 Service Mesh 的优缺点与比较，请阅读 Istio-Handbook [Service Mesh 概述]。\n前面提到过，对于传统微服务框架 Spring Cloud 与新兴微服务框架 Service Mesh，并非是个非黑即白，非你即我，延伸到微服务与单体架构，它们也是可以共存的。\n也可以将其与混合云相类比，混合云中包含了公有云、私有云，可能还有其它的自有基础设施。目前来看，混合云是一种流行的实践方式；实际上，可能很难找到一个完全单一云模式的组织。对多数组织来说，将一个单体应用完全重构为微服务的过程中，对开发资源的调动是一个很严峻的问题；采用混合微服务策略是一个较好的方式，对开发团队来说，这种方式让微服务架构触手可及；否则的话，开发团队可能会因为时间、经验等方面的欠缺，无法接受对单体应用的重构工作。\n构建混合微服务架构的最佳实践：\n 最大化收益的部分优先重构； 非 Java 应用优先采用 Service Mesh 框架； 混合微服务出现的原因是为了更好的支持平滑迁移，最大限度的提升服务治理水平，降低运维通信成本等，并且可能会在一个较长的周期存在着。而实现这一架构的前提，就是各服务的“互联互通”。\n要想实现上述“混合微服务架构”，运行时支撑服务必不可少，它主要包括服务注册中心、服务网关和集中式配置中心三个产品。\n传统微服务和 Service Mesh 双剑合璧（双模微服务），即“基于 SDK 的传统微服务”可以和“基于 Sidecar 的 Service Mesh 微服务”实现下列目标：\n 互联互通：两个体系中的应用可以相互访问； 平滑迁移：应用可以在两个体系中迁移，对于调用该应用的其他应用，做到透明无感知； 灵活演进：在互联互通和平滑迁移实现之后，我们就可以根据实际情况进行灵活的应用改造和架构演进； 这里还包括对应用运行平台的要求，即两个体系下的应用，既可以运行在虚拟机之上，也可以运行在容器/K8s 之上。我们不希望把用户绑定在 K8s 上，因此 Service Mesh 没有采用 K8s 的 Service 机制来做服务注册与发现，这里就突出了注册中心的重要性。\n百度智能云 CNAP 团队实现了上述混合微服务架构，即实现了两个微服务体系的应用互联互通、平滑迁移、灵活演进。上述混合微服务架构图包括以下几个组件：\n API Server：前后端解耦，接口权限控制、请求转发、异常本地化处理等等； 微服务控制中心：微服务治理的主要逻辑，包括服务注册的多租户处理、治理规则（路由、限流、熔断）的创建和转换、微服务配置的管理； 监控数据存储、消息队列：主要是基于 Trace 的监控方案使用的组件； 配置中心：微服务配置中心，最主要的功能是支持配置管理，包括治理规则、用户配置等所有微服务配置的存储和下发，微服务配置中心的特色是借助 SDK 可以实现配置/规则热更新； 接下来主要看一下注册中心的服务注册和发现机制：\n Spring Cloud 应用通过 SDK、Service Mesh 应用实现 Sidecar 分别向注册中心注册，注册的请求先通过微服务控制中心进行认证处理与多租户隔离； Mesh 控制面直接对接注册中心获取服务实例、Spring Cloud 应用通过 SDK 获取服务实例； 双模异构，支持容器与虚机两种模型； 注册中心与高可用方案 前面提到过，要想实现实现混合微服务架构，注册中心很关键。谈到注册中心，目前主流的开源注 …","date":1590476400,"description":"本文根据5月13日晚，百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。","dir":"blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","fuzzywordcount":9100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2cea7fee830cbfcc69ee7732909b231c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","publishdate":"2020-05-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","wordcount":9014},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张晓明 提问：\n 关于 SOFATracer 采样率的配置，只在请求经过的第一个服务配置采样率就可以吗，还是每个服务都需要配置采样率，每个服务都配置的话，要求各服务采样率必须一致吗？\n A：第一个，只在请求经过的第一个服务配置采样率就可以。\n 上报 Zipkin 的话，也只在第一个服务配置就可以吧，其他服务只需要引入 tracer-sofa-boot-starter 就行吧？\n A：上报每个服务节点都要配，不然你下游链路数据拿不到。\n 采样率支持动态更新吗，就是修改后需要重启服务吗？\n A：可以通过自定义采样，配合个配置中心就可以。\n 采样模式用 PercentageBasedSampler，配合配置中心可以吗？\n A：可以，比较麻烦，要反射去改配置类的值，配置类初始化时采样率就确定了，如果要动态改只能通过反射去改。或者通过拿到配置类对象去设置也行，思路差不多。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@李振鸿 提问：\n 请问，分布式事务执行 (只插入两条数据) 执行时间 0.3 会不会比较慢？\n A：嗯，Seata 是消耗了不少性能，尤其是跟 TC 通信、TC 那边的处理。 Seata：https://github.com/seata/seata\n本周推荐阅读 云原生网络代理 MOSN 透明劫持技术解读 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.12.0版，主要更新如下：\n 支持 Go 语言，并增加了 Demo； 新增三个命令行子命令：start, exec 和 stop； 新增 signal 子系统； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.12.0\n社区直播报名 随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处？如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点？服务之间主要通过 Dubbo 交互。本次分享将探索 Istio + MOSN 在 Dubbo 场景下的改造方案，结合现有业务场景和可切入点，明确需要修改的场景，制定符合自己业务场景的 Service Mesh 落地方案，介绍多点生活在 Dubbo 案例的探索及改造方案。\n将从以下几个方面，与大家交流分享：\n 传统微服务架构与 Service Mesh 架构 传统微服务架构在多点遇到的痛点； Service Mesh 架构能带来的福利； Istio 技术点介绍 在 Dubbo 场景下的改造分析 对比 MOSN 和 Envoy 对现有场景的支持； Istio+MOSN 和 Istio+Envoy 在 Dubbo 场景下如何改造； MOSN + Istio 具体实现探索 MOSN 配置文件介绍、从一个流量进来到转发到具体的远端的流程分析； Provider 配置信息如何下发到 Sidecar； 从多点现在的实际场景对现有的 Dubbo 改造方案； Demo 演示 直播主题： Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路\n分享嘉宾：陈鹏，多点生活平台架构组研发工程师，开源项目与云原生爱好者，有多年的网上商城、支付系统相关开发经验，2019年至今从事云原生和 Service Mesh 相关开发工作。\n直播时间：2020/5/28（周四）20:00-21:00\n直播间：点击“这里”，关注直播间即可\n","date":1590138000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200522/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b5778b2bc8e9e6cd92abd8bd7bfc387b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200522/","publishdate":"2020-05-22T17:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200522/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Occlum 发布、技术直播回顾\u0026预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200522/","wordcount":1432},{"author":"巴德","categories":"Kata Containers","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 本文根据 SOFAChannel#16 直播分享整理，主题：不得不说的云原生隔离性。\n大家好，我是今天的讲师巴德，来自蚂蚁金服，主要从事 Kata 容器相关的开发，也是 Kata Containers 项目的维护者之一。今天我和大家分享一下云原生场景下容器隔离性的需求以及我们如何运用 Kata Containers 来提升容器的隔离性。\n从 Kubernetes Pod 说起 在讲云原生隔离性之前，我们先来回顾一下历史。这张图是生产环境应用部署形态的变迁过程。从最左边的物理机上直接部署，到后来的虚拟化兴起，大家把应用部署在虚拟机里，再到 Docker 兴起，大家都把应用部署到容器里面，到现在 Kubernetes 成为主流，大家都把应用部署在 Pod 里面。\n我们看一下 Kubernetes 的一个基本架构，它本身是一个容器的编排系统，主要角色是管理和调度 Pod 以及相关的资源。今天我们主要关注的就是在节点上部署的 Pod，这也是 Kubernetes 资源调度的基本单位。\nKubernetes 官方对 Pod 的定义是一个应用的逻辑主机，其中包含了一个或者多个应用容器，这些容器在资源上是相对紧密的耦合在一起的。Pod 包含了这些容器共享的网络和存储以及如何运行这些容器的声明。Pod 中的内容总是放置在一起并且一同调度，并在共享的上下文中运行。\n这段定义有些抽象，其目的是为了说明 Pod 是可以用不同的隔离技术来实现的。我们先来看一下一个经典的 Pod 实现，基于 Linux namespace 和 cgroups 做抽象的 Pod 实现。\n这个示意图中，我们在一台主机上运行了两个 Pod，这两个 Pod 之间通过主机内核提供的 namespace 和 cgroups 能力来进行隔离。他们之间的所有 namespace 资源都是隔离的。然后在 pod 内部，不同容器之间的 IPC 和网络 namespace 是共享的，但是他们的 mnt/pid/user/uts namespace 又是相互隔离的。这就是一个经典的基于 Linux namespace 和 cgroups 来做隔离的 Pod 的实现。\n对于这种 Pod 的实现，我们可以关注到这两个 Pod 虽然所有的 namespace 都是隔离的，但是他们共享了同一个内核。\n共享内核引入的问题 那么，我们来看一下 Pod 共享同一个内核可能造成什么问题。\n首先我们关注到的是安全问题。也就是说 Pod 中的容器应用会不会通过共享内核的漏洞逃逸出 Pod 的资源隔离？这里我们列了两个近几年的内核 bug，一个是 CVE-2016-5915，另外一个是 CVE-2017-5123，这两个 bug 都曾经造成容器应用通过触发内核 bug 获取宿主机 root 权限并逃逸出 Pod 资源隔离限制。\n另外一个点是故障影响。这个好理解，如果一个 Pod 中的容器应用触发了一个严重的内核 bug，造成内核 panic，这时候同一台宿主机上的所有 Pod 都会被牵连。\n还有一个我们非常关注的点，是共享内核造成的内核资源竞争。同一个宿主机上的不同 Pod，实际上是不同的用户态进程的集合，这些用户态进程虽然在 namespace 上是相互隔离的，但他们还是会共享很多内核资源，比如调度器、某些内核线程或者对象。这种级别的资源共享会引入很多可以观测到的性能抖动，对在线业务的影响也很明显。\n如何避免共享内核造成的这些问题呢？大家最直接的想法就是，把 Kubernetes 装到虚拟机里不就可以更好的隔离起来了吗？如图所示，这本质上是通过增加一个 VM 间接层来解决隔离性问题。\n看起来问题解决了，不是吗？这时候我们就需要抛出计算机届大佬 David Wheeler 的一个名言，“计算机科学中的所有问题都可以通过增加一个间接层来解决，当然，除了间接层过多的问题”。\n那么增加 VM 间接层的方案有什么问题呢？第一，同一个 VM 内的 Pod 之间还是共享内核的。第二，整个集群里出现了虚拟机和 Pod 两层调度系统。\n上帝说，要有光；我们说，要有 Kata 面对这些问题，我们要怎么做呢？我们要部署 Kata 容器 ：)\nKata 容器的一个基本思路是，用虚拟机来作为 Pod 的一种隔离方式。我们把 Pod 中的多个容器资源，放到同一个虚拟机里面，利用虚拟机来实现不同 Pod 独占内核的目的。而 Pod 仍然是 Kubernetes 的基本调度单位，集群里也不会有虚拟机和 Pod 两层调度系统。\n我们简单介绍一下 Kata Containers 这个项目，这是 Openstack 基金会管理下的开放基础设施顶级项目。Kata Containers 的 slogen 是 The speed of containers, the security of VMs。其设计是基于虚拟机完美符合 Pod 抽象这个理念，为用户提供强隔离，易用的容器基础设施。\nKata Containers：https://github.com/kata-containers/kata-containers\n这是 Kata Containers 项目的发展历史概要。在 2015 年的五月，一帮国内的创业者(就是我们) 和 Intel 的同学们分别独立发布了两个叫 runV 和 Clear Containers 的虚拟化容器项目，这就是 Kata Containers 的前身。这两个项目互相有很多交流，在分别独立发展了两年半之后，在 2017 年底，合并成了 Kata Containers 项目，并把这个项目捐给 Openstack 基金会管理，这也是 Openstack 基金会的第一个 Pilot 项目，有一些探索转型的味道。在去年的四月，Kata Containers 被 Openstack 基金会认可为其第二个顶级项目，在这之前的十多年里，Openstack 基金会都只有 Openstack 一个顶级项目。\n目前 Kata Containers 的稳定版本发布到了 1.10.0，而且 2.0 也正在紧锣密鼓地开发中。\n我们再简单介绍下 Kata Containers 的架构。左边蓝色部分是 Kata Containers 对接的上游组件，也就是 Kubernetes 通过 CRI 接口访问 CRI daemon，这里是用 containerd 做展示。 Containerd 通过一个 Shim API 来访问 Kata Containers。右边的就都是 Kata 的组件了。对每一个 Pod，我们有一个名叫 containerd-shim-kata-v2 的服务进程，这个服务进程会负责基于虚拟机的 Pod 的生命周期管理。最后边的 Pod Sandbox 就是我们基于虚拟机来实现的一个 Pod 抽象。在里面我们要运行一个叫 kata-agent 的服务进程，来负责 Pod 内容器的生命周期管理。\nKata 容器特性大放送 介绍了 Kata …","date":1590123600,"description":"本文根据线上直播整理，一起来看看云原生场景下容器隔离性的需求以及我们如何运用 Kata Containers 来提升容器的隔离性。欢迎阅读","dir":"blog/sofa-channel-16-retrospect/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c57953062af87158c42de61e48d1676f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-16-retrospect/","publishdate":"2020-05-22T13:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-channel-16-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播","tags":["Kata Containers","SOFAChannel"],"title":"不得不说的云原生隔离性 | SOFAChannel#16 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-16-retrospect/","wordcount":3573},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路\n 活动时间：5 月 28 日周四晚 8 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 Service Mesh Webinar Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#1 Service Mesh Webinar#1，邀请多点生活平台架构组研发工程师陈鹏，带来分享《多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路》。\n随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处。如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点。服务之间主要通过 Dubbo 交互，本次分享将探索 Istio + MOSN 在 Dubbo 场景下的改造方案。\n分享主题：\n《多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路》\n分享嘉宾：\n陈鹏，多点生活平台架构组研发工程师，开源项目与云原生爱好者，有多年的网上商城、支付系统相关开发经验，2019年至今从事云原生和 Service Mesh 相关开发工作。\n直播时间：2020年5月28日（周四）20:00-21:00\n解决思路:\n从 MCP、Pilot、xDS、MOSN 技术，对 Service Mesh 的可切入点分析。\n成果：\n结合现有业务场景和可切入点，明确需要修改的场景，制定符合自己业务场景的 Service Mesh 落地方案，介绍多点生活在 Dubbo 案例的探索及改造方案。\n大纲：\n 传统微服务架构与 Service Mesh 架构 传统微服务架构在多点遇到的痛点 Service Mesh 架构能带来的福利 Istio 技术点介绍 在 Dubbo 场景下的改造分析 对比 MOSN 和 Envoy 对现有场景的支持 Istio+MOSN 和 Istio+Envoy 在 Dubbo 场景下如何改造 MOSN + Istio 具体实现探索 MOSN 配置文件介绍、从一个流量进来到转发到具体的远端的流程分析 Provider 配置信息如何下发到 Sidecar 从多点现在的实际场景对现有的 Dubbo 改造方案 Demo 演示 ","date":1589958000,"description":"5 月 28 日周四晚 8 点，Service Mesh Webinar#1 线上直播。","dir":"activities/service-mesh-webinar-1/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d146e6a876059c0f8da819f408add6fa","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-webinar-1/","publishdate":"2020-05-20T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-webinar-1/","summary":"概要 活动主题：Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路 活动时间：5 月 28 日周四晚 8 点 活","tags":["MOSN","Service Mesh Webinar"],"title":"Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践","type":"activities","url":"/sofastack.tech/activities/service-mesh-webinar-1/","wordcount":742},{"author":"无在","categories":"MOSN","content":" MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称，可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡、API Gateway、云原生 Ingress 等使用。 MOSN：https://github.com/mosn/mosn\n 在由 Istio 定义的 Service Mesh 体系中，服务治理相关逻辑由独立的 Sidecar 进程处理，如服务发现、故障注入、限流熔断等等。这些处理逻辑是 Service Mesh 着重要解决的问题。通常在谈论到 Service Mesh 时，会优先关注在这些点上，但是在落地过程中，有一个问题同等重要但往往容易被忽视。这个问题概括起来，就是流量是如何被导入到 Sidecar 的监听端口的。\n在数据平面的 Sidecar 中拦截进出应用容器的流量，这一直以来就是 Istio Service Mesh 中一切功能的基础，如何实现透明高效的拦截也是 Service Mesh 设计中的一大难点，本文为大家介绍云原生网络代理 MOSN 是如何做到这一点的。\n流量接管 如果服务注册/发布过程能够允许适当的修改，这个问题会得到极大的简化，比如 Sidecar 将服务发布方的监听地址修改为 127.0.0.1:20882，订阅方 Sidecar 监听本机 20882 端口，当订阅方访问 127.0.0.1:20882 时，流量就自然到达了本端 Sidecar。在这种情况下，无需在网络层面使用重定向技术就可以达到目的。\n服务发布订阅修改逻辑框图\n流量转发流程图\n如上图中，在发布服务时，Sidecar 将服务端原本的地址转换为 Sidecar 自身的端口；服务订阅时，订阅方获取到的端口则是本地 Sidecar 监听的端口。这一方案的优势很明显，逻辑都收敛在了 Sidecar 中，除了需要对 Sidecar 服务注册/发布流程进行改造外，不需要其他组件的参与，但是缺点也很明显，如果业务模型不存在注册中心，或者是服务发布/订阅 SDK 不能进行改造，这个方案就行不通了，而在 Mesh 落地场景中，这个条件恰恰较难满足。\n目前大多数业务的逻辑架构都不符合 Istio 定义的云原生体系，为了享受到 Service Mesh 在服务治理方面的优势，需要选择合适的流量劫持方案。一般而言，流量劫持工作在 L4 层，在进行劫持技术选型时需要考虑三个方面的问题：\n 第一是环境适配，包括容器、虚拟机、物理机、内核、系统发行版等方面的考虑，确保劫持方案在运行环境中能够正常工作； 第二是控制灵活简单，包括如何维护劫持规则，劫持规则如何下发等； 第三是性能，确保在业务运行期间，劫持本身不会带来过大的开销； 下面将从这三个层面分析 MOSN 在落地过程中的一些思考。\n环境适配 在环境适配性上，最容易想到的是 iptables，作为一项古典网络技术，iptables 使用简单，功能灵活，几乎所有现代生产级内核版本与 OS 发行版都默认具备使用条件，Istio 社区也使用 iptables 做流量透明劫持。\niptables 流量劫持原理图\n尽管环境适应性强，但是基于 iptables 实现透明劫持存在以下问题：\n DNAT 模式下，需要借助于 conntrack 模块实现连接跟踪，在连接数较多的情况下，会造成较大的消耗，同时可能会造成 track 表满的情况。为了避免这个问题，可以使用 TProxy 取代 DNAT，但受限于内核版本，TProxy 应用于 outbound 存在一定缺陷。 iptables 属于常用模块，全局生效，不能显式的禁止相关联的修改，可管控性比较差。 iptables 重定向流量本质上是通过 loopback 交换数据，outbond 流量将两次穿越协议栈，在大并发场景下会损失转发性能。 针对 oubound 流量，还可以使用 hook connect 来实现，如图所示：\nhook connect 逻辑框图\n无论采用哪种透明劫持方案，均需要解决获取真实目的 IP/端口的问题，使用 iptables 方案通过 getsockopt 方式获取，TProxy 可以直接读取目的地址，通过修改调用接口，hook connect 方案读取方式类似于 TProxy。\n由于 MOSN 落地的场景十分复杂，有容器与 VM 甚至物理机环境，有基于 K8s 的云原生应用，有基于注册中心的微服务，也存在单体应用，有些场景对性能要求非常高，有些则是够用即可，针对不同的场景，我们选择不同的劫持方案进行适配。如果应用程序通过注册中心发布/订阅服务时，可以结合注册中心劫持流量；在需要用到透明劫持的场景，如果性能压力不大，使用 iptables DNAT 即可，大并发压力下使用 TProxy 与 sockmap 改善性能。\n配置管理 通常基于申明式体系构建的服务在部署时能够得到全局信息，而非申明式体系往往需要在运行期间进行动态的配置修改，由于缺乏全局信息，在运行期间很难获取到准确的服务间调用信息。在生成透明劫持规则时，我们需要明确哪些流量要被重定向到 Sidecar，否则一旦出错，而 Sidecar 又无法处理这部分流量时，将会使得 Sidecar 变成流量黑洞，比如，某一个容器内的 TCP 流量全部被重定向至 Sidecar，而该容器中存在一个使用私有协议承载应用数据的监控 Agent，而 Sidecar 不能识别该协议导致无法争取转发，只能选择丢弃。\n通常情况下，为了确保 Sidecar 能够正确的转发流量，需要满足两个条件，首先是要能够正确识别协议，其次是需要配置转发规则，明确下一跳。对于不满足这两个条件的流量，不应将其重定向至 Sidecar。对于现有的非云原生应用，同时满足这两个条件的代价非常高，比如，某个虚拟机上运行了一个业务，同时还运行了收集 Metrics 的 Agent、日志采集工具、健康检查工具等等。而基于 L4 规则很难精确的将业务流量重定向至 Sidecar，如果多个业务混部，可能导致无法在 L4 层进行业务流量的区分。总结起来，为了精确的把流量引至 Sidecar，需要获得全局的调用关系，这一目标原本应该由 Service Mesh 来完成，而在流量劫持的场景下，却成为了 Service Mesh 的前提。\n为了使用 Service Mesh 而引入大量的部署运维开销是得不偿失的。在落地的过程中，MOSN 引入了多项手段来降低流量劫持的配置难度。我们将需要精确配置重定向规则的工作模式定义为精确匹配，与之相对应的是模糊匹配，即不要求精确区分出需要劫持的流量。降低配置难度的关键在于取消对于精确规则的依赖，在配置模糊规则的前提下，既做到对于关心的业务流量的治理，同时也不影响非业务流量的正常流程。\n我们采用 L4 规则与 L7 规则融合的方式下发模糊的匹配规则，此规则下除了包含关心的业务流量外，还可能包含预期之外的非业务流量。对于业务流量，Sidecar 根据相应的服务治 …","date":1589871600,"description":"如何实现透明高效的拦截也是 Service Mesh 设计中的一大难点，本文为大家介绍云原生网络代理 MOSN 是如何做到这一点的。","dir":"blog/mosn-transparent-hijacking/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c2505ec6bd3034e6cf3222dca8e1b83e","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-transparent-hijacking/","publishdate":"2020-05-19T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-transparent-hijacking/","summary":"MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简","tags":["MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 透明劫持技术解读 | 开源","type":"blog","url":"/sofastack.tech/blog/mosn-transparent-hijacking/","wordcount":3410},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n**1、@黄泽宏 **提问：\n SOFAJRaft 中 rheakv 不实现 region 新增删除，是因为分片迁移比较复杂么？\n A：不知道您说的新增删除是指什么？ 分裂与合并？ 分裂是有的，合并没有，不过分裂还没有经过严格的验证，也暂时不建议使用，分裂和合并确实比较复杂，复杂的不是分片迁移，分片迁移只要 raft 协议实现的没问题就是很自然的事情了。\n 对，sharding 合并分裂迁移，代码大概在哪个位置呢，想先看下实现。\n A：com.alipay.sofa.jraft.rhea.StoreEngine#applySplit 从这里看吧。 SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@廖景楷 提问：\n 请教 Seata 在做超时处理时怎么协调多个节点不会同时对某个事务做多次处理？还是说要求业务容许多次commit，rollback，Seata 就不协调了？ 我在测试 seata-server 多节点 HA 部署，用 MySQL 存储，看代码貌似所有节点都是无差别无状态的，在多个实例的 DefaultCoordiantor 里头有定时器去扫描超时的事务进行重试或者回滚，打开 general log 也发现有多个客户端 IP 在用同样的语句在扫描 global_table 表进行超时等处理。想确认一下多节点间是否有协调机制？ 我在 K8s下面部署3节点的 seata-server statefulset，镜像 docker.io/seataio/seata-server:latest 使用 Nacos 作为 registry。\n A：目前没有，多次不会导致数据问题，不过确实浪费资源，可以考虑引入分布式 job。\n 也就是说比如同一个超时的未 commit Global Session 被多个节点同时扫描到，可能会调用业务做多次 commit，然后由业务自己去重？\n A：是的，不过不是业务处理，框架会处理。\n3、@Cheng cheng 提问：\n 最近正在做 Seata 跟我们产品集成到研究，问一个小白问题，我们需要把 Seata 部署到 K8s 里，那么如果 Seata server 的一个 pod 突然挂了，那在途的调用会突然中断，这样依然可以完美控制事务达成数据一致性吗？\n A：如果 Server 是公用的一个 DB，理论上没问题的。\n 没有理解你说的公用 DB\u0026amp;hellip;. Seata Server 在 K8s 上用独立的几个 pod 部署，那相应的我们会给它单独创建数据库。\n A：Seata 高可用要求就是需要 server 的集群共用同一个 Seata 库，不然无法数据共享，也就是无法知晓当前运作的事务信息。首先你要保证 Server 集群用的同一个注册中心集群，并且共用同一个 Seata 库，这样才能保障数据共享、高可用。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Mecha：将 Mesh 进行到底 陌陌的 Service Mesh 探索与实践 | 线上直播回顾 《Service Mesh Virtual Meetup#1》：视频回顾 *SOFA 项目进展* 本周发布详情如下：\n1、发布 SOFABoot v3.4.0 版本，主要变更如下：\n 支持基于 gRPC 的 triple 协议； 修复 bolt callback 方式的兼容问题； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.0\n2、发布 SOFAHessian v4.0.4 版本，主要变更如下：\n 修复 JDK 判断逻辑有锁问题； 修复 _staticTypeMap 为 ConcurrentMap，和 v3.x 对齐； 详细发布报告： https://github.com/sofastack/sofa-hessian/releases/tag/v4.0.4\n社区直播报名 在云原生时代，容器和 Kubernetes 在日常工作和实际生产中越来越普遍，随之而来的隔离性问题在不断被提起同时也受到了越来越多的关注。\nSOFAChannel#16 线上直播带来《不得不说的云原生隔离性》分享，将邀请 Kata Containers 维护者彭涛（花名：巴德）带我们走近云原生基础设施 \u0026amp;ndash; Kata Containers，详细分享它是如何在云原生框架下解决容器隔离性问题的。\n将从以下几个方面，与大家交流分享：\n 从 Kubernetes Pod 说起，经典容器场景下的 Pod 分享； 共享内核存在的问题以及解决办法； 上帝说，要有光；我们说，要有 Kata； The speed of containers, the security of VMs； Kata Containers 特性大放送； What? 你刚说过增加一个 VM 间接层的问题？ 活动详情：\n 直播主题：SOFAChannel#16：不得不说的云原生隔离性 直播时间：2020/5/21（周四）19:00-20:00 报名方式：点击“这里”，即可报名 ","date":1589533200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200515/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f02bec7b5443778e602b655210ee33fb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200515/","publishdate":"2020-05-15T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200515/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot\u0026SOFAHessian 发布、5/21 社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200515/","wordcount":1781},{"author":"敖小剑","categories":"Service Mesh","content":" 内容摘要：Service Mesh 落地实践三年，效果一直并不理想，到了该反思的时候了。Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化版本，预计也将是云原生化和 Mesh 化的必然趋势，让我们将 Mesh 进行到底。\nMecha 介绍 什么是 Macha？ Mecha 一词，相信爱好动漫的同学应该都不陌生。是的，就是大家熟悉的那个 Mecha（机甲）：\nMecha 这个词之所以出现在这里，主要是因为 Bilgin Ibryam 的这个博客文章 “Multi-Runtime Microservices Architecture”，提出了微服务架构的一个新的设想：Multiple Runtime。\n 备注：这篇博客文章强烈推荐阅读，我甚至建议在阅读本文之前先阅读这篇文章，因为我今天的内容，可以视为对这个文章的深度解读和思考。为了方便，这里提供一份中文翻译版本 多运行时微服务架构。\n 在这篇博客中，Bilgin Ibryam 首先分析并总结了分布式应用的四大需求:\n 生命周期（Lifecycle） 网络（Networking） 状态（State） 捆绑（Binding） 由于每种需求存在的问题和局限性，导致传统解决方案如企业服务总线（ESB）及其变体（例如面向消息的中间件，更轻量级的集成框架等）不再适用。随着微服务架构的发展，以及容器和 Kubernetes 的普及和广泛使用，云原生思想开始影响这些需求的实现方式。未来的架构趋势是通过将所有传统的中间件功能移至其他运行时来全面发展，最后的目标是在服务中只需编写业务逻辑。\n 备注：详情请见原文，为了节约篇幅，这里只做简单概述，不完全引用原文内容。\n 下图是传统中间件平台和云原生平台的对比，传统中间件以各种SDK的方式提供能力，而云原生平台则通过各种外围Runtime（典型如大家熟悉的Servicemesh/Istio）：\n因此作者引入了 Multiple Runtime 的概念：\n作者提出：很可能在将来，我们最终将使用多个运行时来实现分布式系统。多个运行时，不是因为有多个微服务，而是因为每个微服务都将由多个运行时组成，最有可能是两个运行时-自定义业务逻辑运行时和分布式原语运行时。\n对多运行时微服务架构和 Mecha 的说明：\n 您还记得电影《阿凡达》和科学家们制作的用于去野外探索潘多拉的 Amplified Mobility Platform (AMP)“机车服”吗？这个多运行时架构类似于这些 Mecha-套装，为人形驾驶员赋予超能力。在电影中，您要穿上套装才能获得力量并获得破坏性武器。在这个软件架构中，您将拥有构成应用核心的业务逻辑（称为微逻辑/micrologic）和提供强大的开箱即用的分布式原语的 Sidecar Mecha 组件。Micrologic 与 Mecha 功能相结合，形成多运行时微服务，该服务将进程外功能用于其分布式系统需求。最棒的是，Avatar 2 即将面世，以帮助推广这种架构。我们最终可以在所有软件会议上用令人赞叹的机甲图片代替老式的边车摩托车；-)。接下来，让我们看看该软件架构的详细信息。 这是一个类似于客户端-服务器体系结构的双组件模型，其中每个组件都是独立的运行时。它与纯客户端-服务器架构的不同之处在于，这两个组件都位于同一主机上，彼此之间有可靠的网络连接。这两个组件的重要性相当，它们可以在任一方向上发起操作并充当客户端或服务器。其中的一个组件称为 Micrologic，拥有非常少的业务逻辑，把几乎所有分布式系统问题都剥离出去了。另一个伴随的组件是 Mecha，提供了我们在本文中一直讨论的所有分布式系统功能（生命周期除外，它是平台功能）。\n 作者在这里正式提出了 Mecha 的理念：\n思路大体是：Smart Runtime， Dumb Pipes。\n我对 Mecha 的理解是：业务逻辑在编码开始阶段应该是“裸奔”的，专注于业务逻辑的实现，而尽量不涉及到底层实现逻辑；而在运行时，则应该装备“机甲”，全副武装，大杀四方。熟悉的味道是吧？标准而地道的云原生思想。\nMecha 的本质 作者在原文中探讨了 Mecha 运行时的特性：\n Mecha 是通用的，高度可配置的，可重用的组件，提供分布式原语作为现成的能力。 Mecha 可以与单个 Micrologic 组件一起部署(Sidecar 模式)，也可以部署为多个共享(注：我称之为 Node 模式)。 Mecha 不对 Micrologic 运行时做任何假设，它与使用开放协议和格式（例如 HTTP/gRPC、JSON、Protobuf、CloudEvents）的多语言微服务甚至单体一起使用。 Mecha 以简单的文本格式（例如 YAML、JSON）声明式地配置，指示要启用的功能以及如何将其绑定到Micrologic 端点。 与其依靠多个代理来实现不同的目的（例如网络代理、缓存代理、绑定代理），不如使用一个 Mecha 提供所有这些能力。 下面是我对上述特性的个人理解：\n Mecha 提供的是能力，以分布式原语体现的各种能力，而不局限于单纯的网络代理。 Mecha 的部署模型，不局限于 Sidecar 模式，Node 模式在某些场景下（如 Edge/IoT，Serverless FaaS）可能会是更好的方式。至少，Mecha下有机会按需选择，而不是绑死在 Sidecar 模式上。 Mecha 和 Micrologic 之间的交互是开放而有 API 标准的，Mecha 和 Micrologic 之间的“协议”体现在 API 上，而不是 TCP 通讯协议。这提供了一个契机：一个统一 Micrologic 和 Mecha 之间通讯方式的契机。 Mecha 可以以声明式的方式进行配置和控制，这非常符合云原生的理念，同样也使得 API 更关注于能力本身，而不是能力如何配置。 应用需要的能力如此之多（参见上面的图：分布式应用的四大需求），如果每个能力都对应一个代理（不管是 Node 还是 Sidecar），数量会非常夸张，带来的运维压力会很可怕。因此，如 Mecha 这个名字暗示的，运行时应该是整套的形式提供能力，而不是分散。 如果用一句话来总结，那么我认为 Mecha 的本质应该是：\n“面向应用的分布式能力抽象层”\n如 Service Mesh 的本质是服务间通讯的抽象层一样，Mecha 的本质是应用需要的各种分布式能力和原语，包括但不限于服务间通讯。\n从这个角度上说，Mecha 覆盖的范围是 Service Mesh 的超集：毕竟 Service Mesh 只覆盖到应用的部分需求（服务间通讯，还只限于同步/一对一/request-response 模式），还有更多的分布式能力和原语有待覆盖。\n换一句话说，Mecha 的目标应该是：“将 Mesh 进行到底！”\nMecha 的优势和未来 作者指出：Mecha 的好处是业务逻辑和越来越多的分布式系统问题之间的松耦合。\n下图是业务逻辑和分布式系统问题在不同架构中的耦合：\n其实思路和 Service Mesh 是一脉相承的，只是覆盖的分布式能力更广泛一些。\n有一个问题：Mecha 会不会成为微 …","date":1589364000,"description":"Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化版本，预计也将是云原生化和 Mesh 化的必然趋势，让我们将 Mesh 进行到底。","dir":"blog/mecha-carry-mesh-to-the-end/","fuzzywordcount":7500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2ef4b817d0dc0018551a25d24b174ee0","permalink":"https://sofastack.github.io/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","publishdate":"2020-05-13T18:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","summary":"内容摘要：Service Mesh 落地实践三年，效果一直并不理想，到了该反思的时候了。Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化","tags":["Service Mesh"],"title":"Mecha：将 Mesh 进行到底","type":"blog","url":"/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","wordcount":7479},{"author":"高飞航","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。\n本文根据5月6日晚，陌陌中间件架构师高飞航的主题分享《陌陌的 Service Mesh 探索与实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 本次演讲为大家分享的是陌陌目前正在进行的 Service Mesh 实践的相关内容。共分为三个部分：\n 第一部分是原有微服务架构的相关背景； 第二部分是原有架构遇到的问题以及决定采用 Service Mesh 方案的思考过程； 最后的部分对Service Mesh落地实践的方案进行介绍； 陌陌微服务体系演进历程 单体应用到微服务 各个应用的发展过程，都会经历从单体应用、到应用拆分再到微服务架构这样一个过程。陌陌的这个演进过程，有一点比较特别的是，在应用拆分时加入了由 PHP 开发、与客户端 App 进行对接的 API 层，并采用 Java 开发底层具有复杂运算的业务逻辑，这样能够兼得 PHP 的开发效率与 Java 高性能的优势。\n但这个选择的影响也是十分深远的，由于 PHP 在业务中的比重很高，我们在后续进行微服务改造和服务治理时，需要不断地去应对多语言架构带来的挑战。\n微服务体系演进 陌陌的微服务架构改造从 2013 年就开始了，在当时还没有较为完善的服务框架产品的情况下，我们自研了服务框架产品 MOA，支撑了陌陌 IM、附近动态、直播、短视频等核心业务的高速发展历程。\n在多年的迭代发展中，我们逐步完善了服务框架产品功能，同时也扩充了其他基础架构产品，最终形成了一个完善的微服务体系。其他基础架构产品也都是采用了自研的方案，因此整体是一个非常定制化的架构。这一点也成为后续 Service Mesh 落地选型时重点要考量的因素。\n微服务体系整体架构 下面对微服务体系的整体架构进行介绍。我们采用了一个 Redis 作为底层存储的注册中心。服务实例的存活检测主要依赖一个中心化的检测应用 MOA Watcher，能够将无法连通的实例从注册中心的在线列表中移除、摘除实例的业务流量。\n在多语言支持方面，我们除了支持最核心的 Java 与 PHP 应用之外，后续还支持了 Python、C++、Go、NodeJS 等非常多的语言接入微服务体系。由于陌陌的中间件团队是以 Java 工程师为主导的，服务框架组件的核心产品也是一个 Java 的 SDK。在没有足够的资源投入到其他语言 SDK 开发的情况下，我们采用了很多能够简化多语言开发工作的方案。\n例如跨语言调用和 Java 应用内部调用会采用不同的协议，Java 内部是较为传统的自定义二进制传输协议与 Hessian 序列化，跨语言则采用了 Redis 传输协议与 JSON 序列化。Redis 协议分别利用 GET 命令的 key 和 value 的位置传递 Request 和 Response，这样每种语言都可以基于成熟的 Redis 客户端开发 SDK，避免重复编写复杂的网络通信逻辑。此外还增加了一个地址发现服务 Lookup，使其他语言能够像调用普通服务的方式，轮询获取目标服务地址。跨语言场景的这些方案虽然简化了开发工作，但却不是最优方案。这也为整体架构的长期发展埋下了隐患。\n微服务体系的其他产品还包括统一的配置中心、监控平台、日志采集平台、分布式跟踪系统等，这些都是为微服务体系保驾护航的重要基础架构能力。\n流量代理机制 在多语言支持的场景中，我们很早就采用了两个和 Service Mesh 非常相近的方案。一个是为了支持多语言发布服务的入流量代理方案，使用 Java 开发的 Proxy 复用了 Java SDK 注册发现与监控等诸多服务治理能力，使得其他语言仅简单处理本地请求后就能实现发布服务。这些 Java Proxy 与多语言的业务进程是 1:1 部署的，但当时的方案是和业务进程放在一个容器里，升级时需要和业务进程一起重新发布。\n另外一个方案是为了解决 PHP 并行调用下游服务而实现的出流量代理，但这个方案中代理层的进程是运行在独立的服务器上，没有部署在与调用端相同的服务器。\n我们将流量代理机制应用于多语言服务治理的经历，在某种程度上突显了 Service Mesh 的价值，我们可能想到类似的方案去解决问题，但都没有像 Service Mesh 一样系统地给出一种最佳方案。不过这些相近方案的经验是有助于我们后续去推进 Service Mesh 落地的。\n微服务体系规模 随着业务的发展，整个微服务体系也达到了一个很具有挑战的量级。特别是在服务数量大幅增长后，Java 应用的服务治理问题也逐步暴露出来，其中最难以解决的是 SDK 升级的问题，这一点也是进一步推动我们转向 Service Mesh 架构的原因。\n借助 Service Mesh 解决现有架构痛点 架构痛点分析  前面我们提到的各种问题，其实都可以归结为微服务体系中服务治理能力滞后的问题。对于非 Java 的应用，由于没有足够的开发资源，会导致服务框架的 SDK 迭代进度非常缓慢。对于 Java 应用，虽然 SDK 具备最完善的功能，但使全量应用完成升级需要耗费大量人力和时间。根据以往的经验来看，一次推广至少需要一个季度的时间，并且为业务团队带来很多不必要的负担。\n两种场景最终的危害是一致的，都会导致架构能力上无法实现统一，先进的功能无法覆盖到全部应用，使应用稳定性受到损失，甚至引发故障。我们在多语言方案中依赖的中心化的 Lookup 服务，曾经就因为一次服务异常导致整个 API 层不可用，原因就是 PHP 的 SDK 采用了一种有缺陷的机制没有升级。在我们设计新方案时，也会因为架构能力无法统一而无法采用最佳的方案。例如我们在设计多机房架构时，由于流量调度机制无法快速覆盖到全部应用，因此只能采用从应用入口整体调度流量的一种粗粒度的方案。\n引入 Service Mesh Service Mesh 将基础架构逻辑与业务逻辑解耦、并支持独立升级的方式，能够很好地解决前面描述的架构痛点。但引入 Service Mesh 是一项非常重大的架构变更，并且需要多方面的成本投入。因此在实际落地实施前，我们必须思考以下几个问题，并在不同阶段完成对应的工作。\n 第一个是方案是否足够成熟。这里的方案不局限于 Service Mesh 本身，也依赖公司内其他基础设施的演进积累。例如我们在观察阶段实现了应用容化的推广覆盖、日志 Agent 方案的经验积累等。 第二个是遇到的问题是否有其他替代方案。例如我们之前急需在多语言场景覆盖的一个能力是流量调度机制，尝试过一个只提供地址路由机制，不代理流量的 Agent 方案。 …","date":1589266800,"description":"本文根据5月6日晚，陌陌中间件架构师高飞航的主题分享《陌陌的 Service Mesh 探索与实践》整理。","dir":"blog/momo-service-mesh-exploration-and-practice/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9c4d2df383550d5412e3de24312862ed","permalink":"https://sofastack.github.io/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","publishdate":"2020-05-12T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌","tags":["Service Mesh"],"title":"陌陌的 Service Mesh 探索与实践 - 直播回顾","type":"blog","url":"/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","wordcount":6499},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n**SOFAStack 官网: **https://www.sofastack.tech\n**SOFAStack: **https://github.com/sofastack\n社区大事件 MOSN 社区新认证一位 Committer\n孙福泽（@peacocktrain）认证成为 MOSN Committer：\n主要贡献： 贡献 3 个 feature PR\n 使 MOSN 支持 Istio 1.4； 协议支持 HTTP2 双向流式； 添加管道缓冲区； MOSN：https://github.com/mosn/mosn\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n**1、@chromosome **提问：\n 这个视频中提到因为 log server 中存储得到 commitedId 和 applyId 不是任意时刻都同步的，这样的话，如果说状态机的 apply 速度较慢，很可能 client 的 read request 并不能读取到状态机最新 committed 的操作的结果。 https://tech.antfin.com/community/live/821/data/902\n A：commitedIndex 和 applyIndex 的不完全同步，并不影响 read request 的结果，所以上面的后半句理解还是有点问题，可以看一下 SOFAJRaft 线性一致读的原理介绍，参考这个链接线性一致读章节 https://www.sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/\n 所以 counter 例子中的 readindex 写法就是为了读线性一致性吗？例如 this.counterServer.getNode().readindex\n A：是的。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、**@王勇 **提问：\n 在 AT 模式下，事务的回滚如何补偿三方的缓存操作呢？有没有额外的接口，还是只能是变成 TC 模式，或是自己写 aop？\n A：TCC 嵌套 AT，TCC 二阶段行为做补充。\n TCC 内应该说是不存在 AT 吧。\n A：AT 保证数据库的一致性，TCC 做来二阶段时的三方处理，比如发出 MQ 消息、缓存之类的。\n 就是 AT 和 TCC 在同一全局事务中一起使用是吧。这个 TCC 一阶段可以是空的，二阶段回滚时清理缓存嘛？\n A：嗯。\n OK，我明白了。就是让 TCC 嵌套 AT，通常情况下 TCC 为空，需要补偿的时候向 TCC 里写入东西。\n A：可以这么说，如果 TCC 触发二阶段是回滚，你就把缓存删掉，如果是提交就啥也不干，大概是这么个意思。\n TCC 模式下 AT 是默认的吗？对于大事务，Saga 模式，您用过吗？\n A：一、首先需要创建状态机引擎的 bean。 1.2.0里，状态机引擎的 bean 需要自己创建的。 1.3.0里，spring-boot-starter-seata 里会提供自动配置类。（可以先参考我修改过的代码吧。https://github.com/wangliang1986/seata） 二、需要创建 Saga 模式所需的三张表。github 上可以找到建表 SQL。 三、使用 Seata 的在线状态机设计器来定义流程。地址：http://seata.io/saga_designer/index.html 四、将设计器生成的 json 文件放到自己项目的 resources 中，由状态机引擎去加载它。状态机配置类中有一个配置项可以配置 json 文件路径。 五、使用状态机引擎启动 Saga 事务即可。（要注意的是 1.2.0 版本中，Saga 无法与 AT 一起启用。1.3.0 将修复此问题。） Seata：https://github.com/seata/seata\n本周推荐阅读 （含直播报名）Kata Containers 创始人：安全容器导论 蚂蚁金服 SOFAJRaft 优先级选举剖析 | 特性解析 Service Mesh 和 API Gateway 关系深度探讨 SOFA 项目进展 本周发布详情如下：\n1、发布SOFARPC v5.7.0,主要变更如下：\n 支持基于 grpc 的 triple 协议； 重构项目模块结构； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.0\n2、发布 SOFA MOSN v0.12.0，主要变更如下：\n 支持 SkyWalking； 支持流式 HTTP2； 熔断功能、负载均衡逻辑优化，负载均衡新增 ActiveRequest 和 WRR 算法； 优化 HTTP 连接建立性能； 底层实现优化； Bug Fix； 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/v0.12.0\n社区直播报名 本期为第一期 Service Mesh Virtual Meetup 线上系列直播第一期，邀请了四位来自不同公司的嘉宾，从四个角度对 Service Mesh 的应用实践展开分享。\n本次线直播分享涵盖 Service Mesh 的可观察性和生产实践，为大家介绍 Service Mesh 中的可观察性与传统微服务中可观察性的区别，如何使用 SkyWalking 来观测 Service Mesh，还有来自百度和陌陌的 Service Mesh 生产实践。\n本系列采用线上直播的形式，从 5 月 6 日开始到 5 月 14 日，每周三、周四晚上 19:00-20:00 我们相约进行一个主题分享。\n 时间 分享主题 分享嘉宾 嘉宾介绍 5\u0026amp;frasl;6 陌陌的 Service Mesh 实践 高飞航 陌陌中间件架构师 5\u0026amp;frasl;7 Apache SkyWalking 在 Service Mesh 中的可观察性应用 高洪涛 Tetrate 创始工程师 5\u0026amp;frasl;13 Servicre Mesh 高可用在企业级生产中的实践 罗广明 百度高级研发工程师 5\u0026amp;frasl;14 Servicre Mesh 中的可观察性实践 叶志远 G7 微服务架构师 观看直播方式：点击“这里”，关注直播 …","date":1588928400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200508/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c743041c871c1b4fdd685334ab29add6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200508/","publishdate":"2020-05-08T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200508/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN\u0026amp;SOFARPC 发布、社区活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200508/","wordcount":1872},{"author":"王旭","categories":"Kata Container","content":" 从2015年5月初开始创业开发 HyperContainer (runV) 到现在，也快五年了，在这个时候还来写一篇什么是安全容器，显得略有尴尬。不过，也正是经过这五年，越来越多到人开始感到，我需要它却说不清它，这个时候来给大家重新解释 “\u0026amp;gt; 安全容器” 也正是时候。\n缘起：安全容器的命名 Phil Karlton 有一句名言—— _计算机科学界只有两个真正的难题——缓存失效和命名。_ 就容器圈而言，我相信命名绝对配得上这句话，这毫无疑问是一件让老开发者沉默，让新人落泪的事情。\n仅就系统软件而言，我们当今比较通行地称为 Linux 容器（LinuxContainer）的这个概念，曾经用过的名字大概还有——jail, zone, virtualserver, sandbox\u0026amp;hellip; 而同样，在早期的虚拟化技术栈里，也曾经把一个虚拟机环境叫做容器。毕竟这个词本身就指代着那些用来包容、封装和隔离的器物，实在是太过常见。以至于，以严谨著称的 Wikipedia 里，这类技术的词条叫做“系统级虚拟化”，从而回避了“什么是容器”这个问题。\n当2013年 Docker 问世之后，容器这个概念伴随着“不可变基础设施”、“云原生”这一系列概念，在随后的几年间，以摧枯拉朽之势颠覆了基于“软件包+配置”的细粒度组合的应用部署困境，用简单地声明式策略+不可变容器就清爽地描述了软件栈。应用怎么部署似乎离题了，我们这里想要强调的是——\n云原生语境下的容器，实质是“应用容器”——以标准格式封装的，运行于标准操作系统环境（常常是 Linux ABI）上的应用打包——或运行这一应用打包的程序/技术。\n这个定义是我在这里写下的，但是它并不是我的个人意志，这是基于 OCI (Open ContainerInitiative) 规范这一共识的，这个规范规定了容器之中的应用将被放置在什么环境中，如何运行，比如启动容器根文件系统上的哪个可执行文件，用什么用户，需要什么样的 CPU、内存资源，有什么外置存储，有什么样的共享需求等等。\n有了这一共识做基础，我们来说安全容器，这又是一段命名血泪史。当年，我的联合创始人赵鹏是用“虚拟化容器”命名的我们的技术的，为了搏人眼球，用了“Secure as VM, Fast asContainer”的大字标语，自此，被容器安全性问题戳中心坎的人们立刻用“Secure Container”来称呼这类东西，一发而不可收。而我们的内心中，这项技术提供了一层额外的隔离，隔离可能意味着安全性中的一环，也意味着某些运维效率、某些优化可能或者其他的功能。实际上，给安全容器这样的定义更合理——\n一种运行时技术，为容器应用提供一个完整的操作系统执行环境（常常是 LinuxABI），但将应用的执行与宿主机操作系统隔离开，避免应用直接访问主机资源，从而可以在容器主机之间或容器之间提供额外的保护。\n间接层：安全容器的精髓 安全问题的唯一正解在于允许那些（导致安全问题的）Bug 发生，但通过额外的隔离层来阻挡住它们。 —— LinuxCon NA 2015, Linus Torvalds 为了安全，为什么要引入间接层？因为以 Linux 之类的目前主流宿主机操作系统的规模，是无法从理论上验证程序是没有 Bug 的，而一旦合适的 Bug 被合适地利用，安全性风险就变成了安全性问题了，框架和修补并不能确保安全，所以，进行额外的隔离、缩减攻击面，就成了缓解安全问题的法宝——我们不能确保没有漏洞，但我们通过组合来减少漏洞被彻底攻破的风险。\nKata: 云原生化的虚拟化 2017年12月，我们在 KubeCon上对外发布了 Kata Containers 安全容器项目，这个项目的两个前身——我们发起的的 runV 和Intel 发起的 Clear Container 都发布于2015年5月（是的，早于上面 Linus 的引语）。这组项目的思路很简单 ——   操作系统本身的容器机制没办法解决安全性问题，需要一个隔离层；  虚拟机是一个现成的隔离层，AWS 这样的云服务已经让全世界相信，对户来说，\u0026amp;rdquo;secure of VM\u0026amp;rdquo; 是可以满足需求的；  虚机里面只要有个内核，就可以支持 OCI 规范的语义，在内核上跑个 Linux 应用这并不太难实现；  虚机可能不够快，阻碍了它在容器环境的应用，那么可不可以拥有 \u0026amp;ldquo;speed of container\u0026amp;rdquo; 呢？  现在，如果最后一个问题可以解决，那么它就是我们要的“安全的容器”了——这就是 Kata Containers。 目前 Kata Containers 通常是在 Kubernetes 环境中使用的，Kubelet 通过CRI 接口让 containerd 或 CRI-O 执行运行时操作，通常镜像操作由这些 CRI Daemon 来进行，而根据请求，把 Runtime 操作写成一个 OCI Spec 交给 OCI Runtime 执行。这里，对于 1.2 以上的 containerd 和 1.5 版本上后的 Kata Containers（对应 ），通常是利用 containerd 来完成的：\n 每个 Pod 会有一个 shim-v2 进程来为 containerd/CRI-O 执行各种运行时操作，这个进程和整个 Pod 的生命周期一致，通过一个 ttRPC 接口为 containerd/CRI-O 提供服务； Shim-v2 会为 Pod 启动一个虚拟机作为 PodSandbox提供隔离性，其中运行着一个 Linux 内核，通常这个 Linux 内核是一个裁剪过的内核，不会支持没有必要的设备； 这里用的虚拟机可以是 Qemu 或是 Firecracker，如果是 Firecracker，那么根本就没有模拟的设备，而如果是 Qemu，通过配置和补丁，也会让它尽量小一些，支持的其他虚拟机还包括 ACRN 和 cloud-hypervisor，未来后者可能会被越来越多的用到； 这个虚拟机在启动的时候可能根本就是一个 initrd 而没有完整操作系统，或者有个极小的操作系统，总之，它完全不是按照一台模拟机的操作系统来配置的，它只是支撑容器应用运行的基础设施，以及相关的应用环境 Metrics 采集或应用跟踪调试需要的资源； 容器本身的 rootfs 会在 Sandbox 启动之后，在收到 contaienrd/CRI-O 的创建容器的 OCI 请求之后，以热插拔的方式动态插入到虚机中，容器的 rootfs 准备和虚机本身的启动是可以并行的； 依照 CRI 语义和 OCI 规范，Pod 里可以启动多个相关联的容器，它们被放在同一个虚机里，并且可以互相共享 namespace； 外来的存储卷可以以块设备或文件系统共享的方式插入到 PodSandbox 中，但对于 Pod 里的容器来说，它们都是加载好的文件系统，目前开始逐渐普及的文件系统方式是专为 Kata 这样的场景设计的 virtio-fs，它不仅比传统的 9pfs 更快、有更完整的 POSIX 文件系统的支持，而且借由所谓 vhost-user 和 DAX 技术，它还可以在不 …","date":1588921200,"description":"隔离，让云原生基础设施更完美。","dir":"blog/kata-container-introduction-to-safe-containers/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6075ee3441970bada70f11c633f4ba85","permalink":"https://sofastack.github.io/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","publishdate":"2020-05-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","summary":"从2015年5月初开始创业开发 HyperContainer (runV) 到现在，也快五年了，在这个时候还来写一篇什么是安全容器，显得略有尴尬。不过，也正是经过这五年，越来越多到人","tags":["Kata Container"],"title":"（含直播报名）Kata Containers 创始人：安全容器导论","type":"blog","url":"/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","wordcount":4686},{"author":"Committer 胡宗棠","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文作者胡宗棠，SOFAJRaft Committer，来自中国移动。本文主要介绍 SOFAJRaft 在 Leader 选举过程中的重要优化方案—一种半确定性的优先级选举机制，将会先简单地介绍下原 Raft 算法中随机超时选举机制的大致内容，如果读者对这块内容理解得不够深入，建议可以先阅读下《SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理》。阅读完这篇文章后，再来看本篇的内容会对半确定性的优先级选举机制有更为深刻的理解。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n一、Raft 算法中选举机制的概念与特点 Raft 算法是一种“共识性”算法，这里所谓的“共识性”主要体现在让多个参与者针对某一件事达成完全一致：一件事一个结论，同时对已达成一致的结论，是不可推翻的。基于这个根本特征，就决定了 Raft 算法具有以下几个主要特点：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成。这是主要为了保证在任何的时间段内，Raft 集群最多只能存在一个 Leader 角色的节点； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务； 在 Raft 算法中，选举是很重要的一部分。所谓选举就是在由多个节点组成的一个 Raft 集群中选出一个 Leader 节点，由他来对外提供写服务 （以及默认情况下的读服务）。\n这里先介绍一个任期的概念—Term， 其用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。同时，该 Term ID 的值是按照时间轴单调递增的，它构成了 Raft Leader 选举的必要属性。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。为了让 Raft 集群中的所有节点尽可能的客观公平公正，采用了随机超时时间触发选举，来避免若干个节点在同一时刻尝试选举而导致选票被瓜分的情况，保证选举的顺利完成。SOFAJRaft 的做法是，在 Node 触发选举的定时任务— electionTimer 中的设置每次定时执行的时间点：时间区间 [electionTimeoutMs，electionTimeoutMs + maxElectionDelayMs) 中的任何时间点。\n在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求； 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳； 同时，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。当选举 Leader 选举成功后，整个 Raft 集群就可以正常地向外提供读写服务了，如上图所示，集群由一个 Leader 和两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳和将日志 Log 复制给 Follower。\n但 Raft 算法的“随机超时时间选举机制”存在如下问题和限制：\n 下一个任期 Term，Raft 集群中谁会成为 Leader 角色是不确定的，集群中的其他节点成为 Leader 角色的随机性较强，无法预估。试想这样的一个场景：假设部署 Raft 集群的服务器采用不同性能规格，业务用户总是期望 Leader 角色节点总是在性能最强的服务器上，这样能够为客户端提供较好的读写能力，而上面这种“随机超时时间选举机制”将不能满足需求； 如上图所示，由于会存在选票被瓜分的场景，集群中的各个 Candidate 角色节点将在下一个周期内重新发起选举。而在这个极短的时间内，由于集群中不存在 Leader 角色所以是无法正常向客户端提供读写能力，因此业务用户需要通过其他方式来避免短时间的不可用造成的影响； 二、SOFAJRaft 基于优先级的半确定性选举机制 2.1 SOFAJRaft 基于优先级选举机制的原理 为了解决原本 Raft 算法“随机超时时间选举机制”带来的问题，增加选举的确定性，作者贡献了一种“基于优先级的半确定性选举机制”。主要的算法思想是：通过配置参数的方式预先定义 Raft 集群中各个节点的 priority 选举优先级的值，每个 Raft 节点进程在启动运行后是能够知道集群中所有节点的 priority 的值（包括它自身的、本地会维护 priority 变量）。\n对每个 Raft 节点的配置如下（下面以其中一个节点的配置举例），其中 PeerId 的字符串值的具体形式为：{ip}:{port}:{index}:{priority}；\n在 Raft 节点进程初始化阶段，通过对所有节点 priority 值求最大值来设置至节点自身维护的 targetPriority 本地全局变量里。在上面这个例子中，节点的 targetPriority 本地全局变量值就被设置为 160，而自身的 priority 值为 100。\n在每个 Raft 节点通过随机超时机制触发 PreVote 预选举阶段之前，会通过先比较自身的 priority 值和 targetPriority 值来决定是否参加本轮的 Leader 选举投票。所以，一组 Raft 节点组成的集群在刚启动运行的阶段，priority 值最大的节点（上面例子中 160 的那个节点）必然会优先被选择成为这个集群中 Leader 角色的节点向外提供读和写的服务。\n2.2 SOFAJRaft 优先级选 …","date":1588759200,"description":"继源码解析系列后，推出特性解析系列，本文为 SOFAJRaft 特性解析第一篇，主要介绍 SOFAJRaft 在 Leader 选举过程中的重要优化方案—一种半确定性的优先级选举机制。","dir":"blog/sofa-jraft-priority-election/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d867df257326471e46ce05ed548f72e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-priority-election/","publishdate":"2020-05-06T18:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-jraft-priority-election/","summary":"SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFAJRaft 特性解析"],"title":"蚂蚁金服 SOFAJRaft 优先级选举剖析 | 特性解析","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-priority-election/","wordcount":5415},{"author":"敖小剑","categories":"Service Mesh","content":" 前言 关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做一个资料的整理和汇总，结合个人的理解给出一些看法。另外在本文最后，介绍蚂蚁金服在 Service Mesh 和 API Gateway 融合的这个最新领域的一些开创性的实践和探索，希望给大家一个更有体感的认知。\n 备注1：为了节约篇幅，我们将直奔主题，假定读者对 Service Mesh 和 API Gateway 已有基本的了解。 备注2: 这边文章更关注于梳理整个脉络，内容不会展开的特别细，尤其是其他文章已经详细阐述的部分。如果您在浏览本文之后，还想更深入的了解细节，请继续阅读文章最后的参考资料和推荐阅读。\n 原本清晰的界限：定位和职责 首先，Service Mesh 和 API Gateway 在功能定位和承担的职责上有非常清晰的界限：\n Service Mesh：微服务的网络通信基础设施，负责（系统内部的）服务间的通讯； API Gateway： 负责将服务以 API 的形式暴露（给系统外部），以实现业务功能； 如上图所示：\n从功能和职责上说：\n 位于最底层的是拆分好的原子微服务，以服务的形式提供各种能力； 在原子微服务上是（可选的）组合服务，某些场景下需要将若干微服务的能力组合起来形成新的服务； 原子微服务和组合服务部署于 系统内部，在采用 Service Mesh 的情况下，由 Service Mesh 提供服务间通讯的能力； API Gateway 用于将系统内部的这些服务暴露给 系统外部，以 API 的形式接受外部请求； 从部署上说：\n Service Mesh 部署在系统内部：因为原子微服务和组合服务通常不会直接暴露给外部系统； API Gateway 部署在系统的边缘：一方面暴露在系统之外，对外提供 API 供外部系统访问；一方面部署在系统内部，以访问内部的各种服务。 在这里引入两个使用非常广泛的术语：\n 东西向通讯：指服务间的相互访问，其通讯流量在服务间流转，流量都位于系统内部； 南北向通讯：指服务对外部提供访问，通常是通过 API Gateway 提供的 API 对外部保罗，其通讯流量是从系统外部进入系统内部； 解释一下“东西南北”的由来：如上图所示，通常在地图上习惯性的遵循“上北下南，左东右西”的原则。\n 总结：Service Mesh 和 API Gateway 在功能和职责上分工明确，界限清晰。但如果事情就这么结束，也就不会出现 Service Mesh 和 API Gateway 关系的讨论了，自然也不会有本文。\n问题的根源在哪里？\n 强烈推荐阅读：附录中 Christian Posta 的文章 \u0026amp;ldquo;Do I Need an API Gateway if I Use a Service Mesh?\u0026amp;ldquo;对此有深度分析和讲解。\n 哲学问题：网关访问内部服务，算东西向还是南北向？ 如下图所示，图中黄色的线条表示的是 API Gateway 访问内部服务：\n问题来了，从流量走向看：这是外部流量进入系统后，开始访问对外暴露的服务，应该属于“南北向”通讯，典型如上图的画法。但从另外一个角度，如果我们将 API Gateway 逻辑上拆分为两个部分，先忽略对外暴露的部分，单独只看 API Gateway 访问内部服务的部分，这时可以视 API Gateway 为一个普通的客户端服务，它和内部服务的通讯更像是“东西向”通讯：\n所以，API Gateway 作为一个客户端访问内部服务时，到底算南北向还是东西向，就成为一个哲学问题：完全取决于我们如何看待 API Gateway ，是作为一个整体，还是逻辑上分拆为对内对外两个部分。\n这个哲学问题并非无厘头，在 API Gateway 的各种产品中，关于如何实现 “API Gateway 作为一个客户端访问内部服务” ，就通常分成两个流派：\n 泾渭分明：视 API Gateway 和内部服务为两个独立事物，API Gateway 访问内部服务的通讯机制自行实现，独立于服务间通讯的机制； 兼容并济：视 API Gateway 为一个普通的内部服务的客户端，重用其内部服务间通讯的机制； 而最终决策通常也和产品的定位有关：如果希望维持 API Gateway 的独立产品定位，希望可以在不同的服务间通讯方案下都可以使用，则通常选择前者，典型如 Kong；如果和服务间通讯方案有非常深的渊源，则通常选择后者，典型如 Spring Cloud 生态下的 Zuul 和 SpringCloud Gateway。\n但无论选择哪个流派，都改变不了一个事实，当 “API Gateway 作为一个客户端访问内部服务” 时，它的确和一个普通内部服务作为客户端去访问其他服务没有本质差异：服务发现、负载均衡、流量路由、熔断、限流、服务降级、故障注入、日志、监控、链路追踪、访问控制、加密、身份认证\u0026amp;hellip;\u0026amp;hellip; 当我们把网关访问内部服务的功能一一列出来时，发现几乎所有的这些功能都是和服务间调用重复。\n这也就造成了一个普遍现象：如果已有一个成熟的服务间通讯框架，再去考虑实现 API Gateway，重用这些重复的能力就成为自然而然的选择。典型如前面提到的 Spring Cloud 生态下的 Zuul 以及后面开发的 Spring Cloud Gateway，就是以重用类库的方式实现了这些能力的重用。\n这里又是一个类似的哲学问题：当 “API Gateway 作为一个客户端访问内部服务” 时，它以重用类库的方式实现了代码级别的能力重用，相当于自行实现了一个和普通服务间通讯方案完全一样的客户端，那这个“客户端”发出来的流量算东西向还是南北向？\n答案不重要。\nSidecar：真正的重合点 在进入 Service Mesh 时代之后，Service Mesh 和 API Gateway 的关系开始是这样：\n 功能和职责清晰划分； 客户端访问服务的功能高度重叠； 此时两者的关系很清晰，而且由于当时 Service Mesh 和 API Gateway 是不同的产品，两者的重合点只是在功能上。\n而随着时间的推移，当 Service Mesh 产品和 API Gateway 产品开始出现相互渗透时，两者的关系就开始变得暧昧。\n在 Service Mesh 出现之后，如何为基于 Service Mesh 的服务选择合适的 API Gateway 方案，就慢慢开始提上日程，而其中选择重用 Service Mesh 的能力也自然成为一个探索的方向，并逐步出现新式 API Gateway 产品，其想法很直接：\n如何融合东西向和南北向的通讯方案？\n其中的一个做法就是基于 Service Mesh 的 Sidecar 来实现 API Gateway，从而在南北向通讯中引入 Service Mesh 这种东西向通讯的方案。这里我们不展开细节，我这里援引一个图片(鸣谢赵化冰同学)来解释这个方案的思路：\n这个时候 Service …","date":1588143600,"description":"Service Mesh 和 API Gateway 之间的关系，是“泾渭分明”还是“兼容并进”？","dir":"blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"17986a3e65f4db0f66b6ba707cf27a40","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","publishdate":"2020-04-29T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","summary":"前言 关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做","tags":["Service Mesh","API Gateway "],"title":"Service Mesh 和 API Gateway 关系深度探讨","type":"blog","url":"/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","wordcount":5306},{"author":"卫恒","categories":"SOFATracer","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。\n 本文根据 SOFAChannel#15 直播分享整理，主题：分布式链路组件 SOFATracer 埋点机制解析。\n大家好，我是宋国磊，花名卫恒，是 SOFATracer 的开源负责人。今天要和大家分享的是分布式链路组件 SOFATracer 埋点机制解析，将通过具体 Demo 演示快速上手 SOFATracer，同时介绍 SOFATracer 功能点，并详细介绍其核心关键「埋点机制」的原理。\nSOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFATracer：https://github.com/sofastack/sofa-tracer\nSOFATracer 作为 SOFAStack 中的分布式链路组件，也伴随着 SOFAStack 走过了两年的时间，在此首先对两年来对 SOFATracer 保持关注并且参与社区建设的同学表示感谢，也希望大家能够继续关注 SOFAStack 的发展，也欢迎更多的同学加入到 SOFAStack 的社区参与中来。\n今天的分享内容主要将会围绕以下三个部分展开：\n SOFATracer 功能点详细介绍； SOFATracer 埋点机制原理详解； 快速上手 SOFATracer 演示； 关于 SOFATracer 更多的问题也欢迎在 Github 上跟我们交流。\nSOFATracer 简介 首先简单介绍一下 SOFATracer。上图展示的是 SOFATracer 目前所包括的基本能力和所支持的插件。下面虚线框中绿色背景部分，是 SOFATracer 提供的基本功能，具体可以参考官方文档描述。上面虚线框中是 SOFATracer 目前所支持的组件，大概分了以下几种类型：客户端、Web、数据存储、消息、RPC、Spring Cloud。\n之前社区也发起过 剖析 | SOFATracer 框架 的源码解析系列文章，在此系列中对 SOFATracer 所提供的能力及实现原理都做了比较全面的分析，有兴趣的同学可以看下。\n今天主要聊一下埋点机制。不同组件的埋点机制也是有很大的差异，SOFATracer 是如何实现对上述组件进行埋点的，下面就详细分析下不同组件的埋点机制。\n埋点机制 目前 SOFATracer 已经支持了对以下开源组件的埋点支持：Spring MVC、RestTemplate、HttpClient、OkHttp3、JDBC、Dubbo(2.6\u0026amp;frasl;2.7)、SOFARPC、Redis、MongoDB、Spring Message、Spring Cloud Stream (基于 Spring Message 的埋点)、RocketMQ、Spring Cloud FeignClient、Hystrix。\n 大多数能力提供在 3.x 版本，2.x 版本从官方 issue 中可以看到后续将不再继续提供新的功能更新；这也是和 SpringBoot 宣布不再继续维护 1.x 版本有关系。\n 标准 Servlet 规范埋点原理 SOFATracer 支持对标准 Servlet 规范的 Web MVC 埋点，包括普通的 Servlet 和 Spring MVC 等，基本原理就是基于 Servelt 规范所提供的 javax.servlet.Filter 过滤器接口扩展实现。\n 过滤器位于 Client 和 Web 应用程序之间，用于检查和修改两者之间流过的请求和响应信息。在请求到达 Servlet 之前，过滤器截获请求。在响应送给客户端之前，过滤器截获响应。多个过滤器形成一个 FilterChain，FilterChain 中不同过滤器的先后顺序由部署文件 web.xml 中过滤器映射的顺序决定。最先截获客户端请求的过滤器将最后截获 Servlet 的响应信息。\n Web 应用程序一般作为请求的接收方，在 SOFATracer 中应用是作为 Server 存在的，其在解析 SpanContext 时所对应的事件为 sr (server receive)。\nSOFATracer 在 sofa-tracer-springmvc-plugin 插件中解析及产生 Span 的过程大致如下：\n Servlet Filter 拦截到 request 请求； 从请求中解析 SpanContext； 通过 SpanContext 构建当前 MVC 的 Span； 给当前 Span 设置 tag、log； 在 Filter 处理的最后，结束 Span； 当然这里面还会设计到其他很多细节，比如给 Span 设置哪些 tag 属性、如果处理异步线程透传等等。本次分享就不展开细节探讨，有兴趣的同学可以自行阅读代码或者和我们交流。\nDubbo 埋点原理 Dubbo 埋点在 SOFATracer 中实际上提供了两个插件，分别用于支持 Dubbo 2.6.x 和 Dubbo 2.7.x；Dubbo 埋点也是基于 Filter ，此 Filter 是 Dubbo 提供的 SPI 扩展-调用拦截扩展 机制实现。\n像 Dubbo 或者 SOFARPC 等 RPC 框架的埋点，通常需要考虑的点比较多。首先， RPC 框架分客户端和服务端，所以在埋点时 RPC 的客户端和服务端必须要有所区分；再者就是 RPC 的调用方式包括很多种，如常见的同步调用、异步调用、oneway 等等，调用方式不同，所对应的 Span 的结束时机也不同，重要的是基本所有的 RPC 框架都会使用线程池用来发起和处理请求，那么如何保证 SOFATracer 在多线程环境下不串也很重要。\n另外 Dubbo 2.6.x 和 Dubbo 2.7.x 在异步回调处理上差异比较大，Dubbo 2.7.x 中提供了 onResponse 方法（后面又升级为 Listener，包括 onResponse 和 onError 两个方法）；而 Dubbo 2.6.x 中则并未提供相应的机制，只能通过对 Future 的硬编码处理来完成埋点和上报。\n 这个问题 Zipkin Brave 对 Dubbo 2.6.x 的埋点时其实也没有考虑到，在做 SOFATracer 支持 Dubbo 2.6.x 时发现了这个 bug，并做了修复。\n SOFATracer 中提供的 DubboSofaTracerFilter 类：\n@Activate(group = { CommonConstants.PROVIDER, CommonConstants.CONSUMER }, value = \u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;, order = 1) public class …","date":1588068000,"description":"SOFATracer 埋点机制解析直播文字回顾。","dir":"blog/sofa-channel-15-retrospect/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4e4c9d4539119eb12ece83c8228ee4a3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-15-retrospect/","publishdate":"2020-04-28T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-channel-15-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["SOFATracer","SOFAChannel"],"title":"分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-15-retrospect/","wordcount":4579},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#16：不得不说的云原生隔离性\n 活动时间：5 月 21 日周四晚 7 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#16：不得不说的云原生隔离性 在云原生时代，容器和 Kubernetes 在日常工作和实际生产中越来越普遍，随之而来的隔离性问题在不断被提起同时也受到了越来越多的关注。\nKata Containers 是 OpenStack 基金会旗下又独立于 OpenStack 项目之外的开放基础设施顶级项目，旨在把虚拟机的安全隔离优势与容器的速度和可管理性统一起来，为用户提供安全快速易用的容器基础设施。\n本期直播，将邀请 Kata Containers 维护者彭涛（花名：巴德）带我们走近云原生的一项基础设施 \u0026amp;ndash; Kata Containers，看它是如何在云原生框架下解决容器隔离性问题的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1197\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 不得不说的云原生隔离性 卫恒 SOFATracer 开源负责人\n你将收获 从 Kubernetes Pod 说起，经典容器场景下的 Pod 分享； 共享内核存在的问题以及解决办法； 上帝说，要有光；我们说，要有 Kata； The speed of containers, the security of VMs； Kata Containers 特性大放送； What? 你刚说过增加一个 VM 间接层的问题？ 嘉宾 SOFAGirl 主持人 卫恒 SOFATracer 开源负责人 ","date":1588057200,"description":"5 月 21 日周四晚 7 点，线上直播第 16 期。","dir":"activities/sofa-channel-16/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4756bc76f718255ad5fc4fd172a706b4","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-16/","publishdate":"2020-04-28T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-16/","summary":"概要 活动主题：SOFAChannel#16：不得不说的云原生隔离性 活动时间：5 月 21 日周四晚 7 点 活动形式：线上直播 报名方式：戳这里 介绍 | SOFAChannel \u0026lt;SOFA:Channel/\u0026gt; 有","tags":["SOFAChannel","Kata Container"],"title":"SOFAChannel#16：不得不说的云原生隔离性","type":"activities","url":"/sofastack.tech/activities/sofa-channel-16/","wordcount":568},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n**SOFAStack 官网: **https://www.sofastack.tech\n**SOFAStack: **https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@闫圣哲 提问：\n 请问：关于 SOFAJRaft 线性读，为什么读失败了要应用到状态机呢，是为了拉齐 readindex 吗？\n A：线性一直读不走 raft log （应该是你说的状态机的意思），在 rheakv 里面，如果线性一直读失败了，那么会和write操作一样通过 raft log 达成一致再走状态机读，这是个兜底策略，否则 readIndex 失败了能怎么办呢？ 另一只方式就是直接返回用户失败了。可以具体看一下「JRaft 实现细节解析之高效的线性一致读」这一小节的内容～\nhttps://www.sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFA 项目进展 本周发布详情如下：\n发布 Seata v1.2.0 版本，主要变更如下：\n 支持 XA 事务模式； 支持事务传播机制； 支持批量更新和删除 SQL； TCC 模式支持 hsf 服务调用； Saga 模式性能优化默认不注册分支事务等； 本次发布涉及代码改动文件数 324个，代码行 +11,907 −3,437。 此版本在 feature 和稳定性相对 1.1.0 版本都有较大幅度增强，强烈推荐大家验证和升级到此版本。 详细发布报告：https://seata.io/zh-cn/blog/download.html\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 社区直播报名 本期为第一期 Service Mesh Virtual Meetup 线上系列直播第一期，邀请了四位来自不同公司的嘉宾，从四个角度对 Service Mesh 的应用实践展开分享。\n本次线上 meetup 分享涵盖 Service Mesh 的可观察性和生产实践。为大家介绍 Service Mesh 中的可观察性与传统微服务中可观察性的区别，如何使用 SkyWalking 来观测 Service Mesh，还有来自百度和陌陌的 Service Mesh 生产实践。\n本系列采用线上直播的形式，从 5 月 6 日开始到 5 月 14 日，每周三、周四晚上 19:00-20:00 我们相约进行一个主题分享。\n观看直播方式：保存图片扫码 或 点击“这里”，关注直播间，即可观看直播\n","date":1587722400,"description":"【04/20-04/24】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200424/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"455d22426589849b45f59083c641ee7c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200424/","publishdate":"2020-04-24T18:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200424/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 系列直播预告、Seata 发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200424/","wordcount":1092},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析\n 活动时间：4 月 23 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1167\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 分布式链路组件 SOFATracer 埋点机制解析 卫恒 SOFATracer 开源负责人\n你将收获 带你快速上手 SOFATracer； SOFATracer 功能点详细介绍； SOFATracer 埋点机制原理详解； 嘉宾 SOFAGirl 主持人 卫恒 SOFATracer 开源负责人 ","date":1587114000,"description":"4 月 23 日周四晚 7 点，线上直播第 15 期。","dir":"activities/sofa-channel-15/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e1323556a7e34b0937a8d3c1f6815a77","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-15/","publishdate":"2020-04-17T17:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-15/","summary":"概要 活动主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 活动时间：4 月 23 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍 |","tags":["SOFAChannel","SOFATracer"],"title":"SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-15/","wordcount":442},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@杨俊 提问：\n AT 模式下，当 seata-server 挂掉之后，有未完成的全局事务还在 undo_log 表中，这里有两个问题问一下： 1. seata-server 再次重启后，之前未完成的全局事务偶尔会出现回滚失败的问题，就是一直重试，但始终回滚失败，这个问题如何解决？ 1. seata-server 再次重启后，大多数情况下会成功回滚，但是等待时间过长，感觉要至少3-5分钟才会回滚，这期间涉及到的相关业务服务无法处理其他请求，直至之前的未完成全局事务成功回滚了，才能处理其他请求，请问这个问题如何解决，还有回滚时间在哪里配置能够缩短？ ※上述两个问题都是基于 seata-sample 产生的。\n A：1. 要确认下客户端日志中回滚失败的原因，重启后会恢复重启前未完成的事务。一般是出现脏写数据了，需要人工订正。如果单纯跳过可以删除 server 或 undo_log 对应记录。 2. server.recovery.rollbackingRetryPeriod , 是不是重启前未完成事务过多？\n 好的，谢谢。 1. seata-sample 中三个服务，Account、Order 回滚成功，Storage 回滚失败，然后 seata-server 就一直反复重试，seata 和 storage 及其他服务重启也无用，然后手工将日志删除，依然不停重试，最后重启 seata 服务，系统把删掉的日志又给重写到日志表了，但是 log_status 为1，至此不再重试，但是事务未能成功回滚。 1. 重启未完成的事务只有那么三个而已，并不多。\n A：问题1，你还是要看下回滚失败的原因，客户端日志会打印。 问题2，你提个 issue ，我们排查下。\n2、@吕布 提问：\n 请教一下, AT 下分支事务提交后释放资源, 虽然资源释放了, 但别的事务操作它时还是被全局锁了, 这种释放的好处体现在哪些方面？ A：即使你数据库本地事务也是排队执行的，全局锁是 AT 模式的排队机制，所以如果是相同数据主键的这个与连接无关。释放连接是因为数据库连接资源是宝贵的，不会因为连接池连接数不够导致的其他数据无关的事务得不到执行，从更大的层面认为是一定程度提高了吞吐。\n 明白了，一方面就是说提高吞吐, 然后一方面是避免本地事务的间隙锁和表锁, 导致其他不相关数据被锁, 可以说锁粒度变小了。谢谢。\n Seata：https://github.com/seata/seata\nSOFATracerLab 系列阅读 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览 | 剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码分析 | 剖析 蚂蚁金服分布式链路跟踪组件链路透传原理与SLF4J MDC的扩展能力分析 | 剖析 蚂蚁金服分布式链路跟踪组件采样策略和源码 | 剖析 蚂蚁金服分布式链路跟踪组件埋点机制 | 剖析 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.1 版本，主要变更如下：\n multi raft group 之间共享 timer 和 scheduler 等较重的线程资源，优化 multi group 场景中的多余资源占用； 提供 RPC adapter，用户可基于 SPI 扩展不同的 RPC 实现； 正式提供稳定的 RocksDBSegmentLogStorage，适合 value 较大的数据存储； SOFABolt 升级到 1.6.1，支持 SSL 以及具有更好的小数据包传输能力； 引入一个新的数据结构 segment list 来解决 LogManager 中过多的 log memory copy； 采纳 nacos 建议，对 raft Task 增加 join API； 修复 learner 启动晚于 leader 选举成功时无法复制日志的 bug； 致谢（排名不分先后） @jovany-wang 、@SteNicholas 、@zongtanghu 、@OpenOpened\n详细发布报告：https://github.com/sofastack/sofa-jraft/issues/420\n社区直播报名 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n本期直播将通过具体 Demo 带你快速上手 SOFATracer，同时将介绍 SOFATracer 具体功能，并详细介绍其核心关键「埋点机制」的原理。\n 主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 时间：2020年4月23日（周四）19:00-20:00 嘉宾：卫恒 SOFATracer 开源负责人 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1587106800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200417/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1bb16db78404cb9d09dd18ec48374246","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200417/","publishdate":"2020-04-17T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200417/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 直播预告、SOFAJRaft 组件发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200417/","wordcount":1836},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@熊胜 提问：\n 请教个问题，biz 卸载中的关闭 ApplicationContext 这一步是哪里处理的呢？我在 com.alipay.sofa.ark.container.model.BizModel#stop 方法中没看到相应的实现。\n A： biz stop 会发出一个事件，这个时间会被 runtime 拿到处理，可以看下 sofa-boot runtime 里面有处理 biz 卸载事件的 handler。\nSOFAArk：https://github.com/sofastack/sofa-ark\n2、@揭印泉 提问：\n 请问 registry.conf 中的 registry 作用是向 Seata 服务器注册分支事务？\n A：registry 是注册中心，seata server 和 client 都需要的，server 往注册中心注册服务，client 往注册中心找寻 server 服务。\n seata server 和 client 是共用 nacos-config.sh 脚本跑到 Nacos 配置？ 如果他们都配置了 Nacos。\n A：随你，你也可以分开，配置中心没约束，你可以 server 用 nacos，client 用 file，只要读取到即可。\n 服务器端配置了 store.mode=\u0026amp;ldquo;db\u0026amp;rdquo;, 启动参数需要加参数：-m db ?\n A：可以不加，优先级启动参数\u0026amp;gt;配置。\nSeata：https://github.com/seata/seata\nSOFARegistryLab 系列阅读 服务注册中心如何实现 DataServer 平滑扩缩容 | SOFARegistry 解析 服务注册中心数据一致性方案分析 | SOFARegistry 解析 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFAChannel 线上直播合集 SOFAChannel#14：云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 SOFAChannel#13：云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 SOFAChannel#12：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 SOFATracer v3.0.12 版本，主要变更如下：\n 2个 Dubbo 插件融合, 新的用户请直接使用 sofa-tracer-dubbo-common-plugin； 修复 Dubbo 插件传递错误 spanId 的问题； 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.12\n社区直播报名 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n本期直播将通过具体 Demo 带你快速上手 SOFATracer，同时将介绍 SOFATracer 具体功能，并详细介绍其核心关键「埋点机制」的原理。\n 主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 时间：2020年4月23日（周四）19:00-20:00 嘉宾：卫恒 SOFATracer 开源负责人 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1586509200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200410/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9f805804c54d097bea99536c21da6387","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200410/","publishdate":"2020-04-10T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200410/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 直播预告、SOFARegistry 解析系列合集、线上直播回顾合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200410/","wordcount":1705},{"author":"永鹏","categories":"SOFAChannel","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。\n 本文根据 SOFAChannel#14 直播分享整理，主题：云原生网络代理 MOSN 扩展机制解析。\n大家好，我是今天的讲师永鹏，来自蚂蚁金服，目前主要负责 MOSN 的开发，也是 MOSN 的Committer。今天我为大家分享的是云原生网络代理 MOSN 的扩展机制，希望通过这次分享以后，能让大家了解 MOSN 的可编程扩展能力，可以基于 MOSN 的扩展能力，按照自己实际的业务需求进行二次开发。\n前言 今天我们将从以下几个方面，对 MOSN 的扩展机制进行介绍：\n MOSN 扩展能力和扩展机制的详细介绍； 结合示例对 MOSN 的 Filter 扩展机制与插件扩展机制进行详细介绍； MOSN 后续扩展能力规划与展望； 欢迎大家有兴趣一起共建 MOSN。在本次演讲中涉及到的示例就在我们的 Github 的 examples/codes/mosn-extensions 目录下，大家有兴趣的也可以下载下来运行一下，关于这些示例我们还做了一些小活动，也希望大家可以踊跃参与。\nMOSN：https://github.com/mosn/mosn\nMOSN 简介 MOSN 作为云原生的网络代理，旨在为服务提供多协议、模块化、智能化、安全的代理能力。在实际生产使用中，不同的厂商会有不同的使用场景，通用的网络代理能力面对具体的业务场景会显得有些不足，通常都需要进行二次开发以满足业务需求。MOSN 在核心框架中，提供了一系列的扩展机制和扩展点，就是为了满足需要基于业务进行二次开发的场景，同时 MOSN 提供的部分通用逻辑也是基于扩展机制和扩展点的实现。\n比如通过 MOSN “内置实现”的透明劫持的能力，就是通过 MOSN Filter 机制实现。而要实现消息的代理，则可以通过类似的扩展实现。在通用代理的情况下，可以通过 Filter 机制实现业务的认证鉴权，也可以实现定制的负载均衡逻辑；除了转发流程可以扩展实现以外，MOSN 还可以扩展日志的实现，用于对标已有的日志系统，也可以扩展 XDS 实现定制的配置更新；根据不同的业务场景还会有很多具体的扩展情况，就不在此展开了，有兴趣的可以关注MOSN 社区正在建设的源代码分析系列文章与文档。\nMOSN 作为一款网络代理，在转发链路上的网络层、协议层、转发层，在非转发链路上的配置、日志、Admin API 等都提供了扩展能力，对于协议扩展的部分，有兴趣的可以看一下上期直播讲的 MOSN 多协议机制解析，我们今天将重点介绍一下转发层的 Stream Filter 扩展机制与 MOSN 的插件机制。\nStream Filter 机制 在实际业务场景中，在转发请求之前或者回写响应之前，都可能需要对请求/响应做一些处理，如判断是否需要进行转发的认证/鉴权，是否需要限流，又或者需要对请求/响应做一些具有业务语义的记录，需要对协议进行转换等。这些场景都与具体的业务高度耦合，是一个典型的需要进行二次开发的情况。MOSN 的 Stream Filter 机制就是为了满足这样的扩展场景所设计的，它也成为目前 MOSN 扩展中使用频率最高的扩展点。\n在目前的内置 MOSN 实现中，Stream Filter 机制暂时与内置的 network filter: proxy 是绑定的，后面我们也考虑将这部分能力进行抽象，让其他 network filter 也可以复用这部分能力。\n关于 Stream Filter，今天会为大家讲解两个部分的内容： 1. 一个 Stream Filter 包含哪些部分以及在 MOSN 中是如何工作的； 2. 通过一个 Demo 演示来加深对 Stream Filter 的实现与应用；\n一个完整的 Stream Filter 一个完整的 StreamFilter，包含三个部分的内容：\n 一个 StreamFilter 对象，存在于每一个请求/响应当中，在 MOSN 收到请求的时候发挥作用，我们称为 ReceiverFilter，在 MOSN 收到响应时发挥作用，我们称为 SenderFilter。一个 StreamFilter 可以是其中任意一种，也可以是两种都是； 一个 StreamFilterFactory 对象，用于 MOSN 在每次收到请求时，生成 StreamFilter 对象。在 Listener 配置解析时，一个 StreamFilter 的配置会生成一个其对于的 StreamFilterFactory。同一个 StreamFilter 在不同的 Listener 下可能对应不同的 StreamFilterFactory，但是也有的特殊情况下，StreamFilterFactory 可能需要实现为单例； 一个 CreateStreamFilterFactory 方法，配置解析时生成 StreamFilterFactory 就是调用它； Stream Filter 在 MOSN 中是如何工作的 接下来，我们看下 Stream Filter 在 MOSN 中是如何工作的。\n当 MOSN 经过协议解析，收到一个完整的请求时，会创建一个 Stream。此时收到请求的 Listener 中每存在 StreamFilterFactory，就会生成一个 StreamFilter 对象，随后进入到 proxy 流程。\n进入 proxy 流程以后，如果存在 ReceiverFilter，那么就会执行对应的逻辑，ReceiverFilter 包括两个阶段，“路由前”和“路由后”，在每个 Filter 处理完成以后，会返回一个状态，如果是 Stop 则会中止后续尚未执行的 ReceiverFilter，通常情况下，返回 Stop 状态的 Filter 都会回写一个响应。如果是 Continue 则会执行下一个 ReceiverFilter，直到本阶段的 ReceiverFilter 都执行完成或中止；路由前阶段的 ReceiverFIlter 执行完成后，就会执行路由后阶段，其逻辑和路由前一致。如果是正常转发，那么随后 MOSN 会收到一个响应或者发现其他异常直接回写一个响应，此时就会进入到 SenderFilter 的流程中，完成 SenderFilter 的处理。SenderFilter 处理完成以后，MOSN 会写响应给 Client，并且完成最后的收尾工作，收尾工作包括一些数据的回收、日志的记录，以及 StreamFilter 的“销毁”（调用 OnDestroy）。\nStream Filter Demo 对 Stream Filter 有了一个基本的认识以后，我们来看一个实际的 Demo 代码来看下如何实现一个 StreamFilter 并且让它在 MOSN 中发挥作用。\n按照刚才我们的介绍，一个 StreamFIlter 要包含三部分：Filter、Factory、CreateFactory。\n 首先我们实现一个 Filter，其逻辑是模拟一个鉴权的 Filter： …","date":1586437200,"description":"本文根据 SOFAChannel#14 直播分享整理，主题：云原生网络代理 MOSN 扩展机制解析。","dir":"blog/sofa-channel-14-retrospect/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"54f04c153ed4827819de6a6716ad46e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-14-retrospect/","publishdate":"2020-04-09T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-14-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["SOFAChannel","MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-14-retrospect/","wordcount":6144},{"author":"404P","categories":"SOFARegistry ","content":" SOFAStack（Scalable Open Financial Architecture Stack ）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。  SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》最后一篇，本篇作者404P(花名岩途)。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n前言 在微服务架构体系下，服务注册中心致力于解决微服务之间服务发现的问题。在服务数量不多的情况下，服务注册中心集群中每台机器都保存着全量的服务数据，但随着蚂蚁金服海量服务的出现，单机已无法存储所有的服务数据，数据分片成为了必然的选择。数据分片之后，每台机器只保存一部分服务数据，节点上下线就容易造成数据波动，很容易影响应用的正常运行。本文通过介绍 SOFARegistry 的分片算法和相关的核心源码来展示蚂蚁金服是如何解决上述问题的。~~\n服务注册中心简介 在微服务架构下，一个互联网应用的服务端背后往往存在大量服务间的相互调用。例如服务 A 在链路上依赖于服务 B，那么在业务发生时，服务 A 需要知道服务 B 的地址，才能完成服务调用。而分布式架构下，每个服务往往都是集群部署的，集群中的机器也是经常变化的，所以服务 B 的地址不是固定不变的。如果要保证业务的可靠性，服务调用者则需要感知被调用服务的地址变化。\n图1 微服务架构下的服务寻址\n既然成千上万的服务调用者都要感知这样的变化，那这种感知能力便下沉成为微服务中一种固定的架构模式：服务注册中心。\n图2 服务注册中心\n服务注册中心里，有服务提供者和服务消费者两种重要的角色，服务调用方是消费者，服务被调方是提供者。对于同一台机器，往往兼具两者角色，既被其它服务调用，也调用其它服务。服务提供者将自身提供的服务信息发布到服务注册中心，服务消费者通过订阅的方式感知所依赖服务的信息是否发生变化。\nSOFARegistry 总体架构 SOFARegistry 的架构中包括4种角色：Client、Session、Data、Meta，如图3所示：\n图3 SOFARegistry 总体架构\n Client 层 应用服务器集群。Client 层是应用层，每个应用系统通过依赖注册中心相关的客户端 jar 包，通过编程方式来使用服务注册中心的服务发布和服务订阅能力。\n Session 层 Session 服务器集群。顾名思义，Session 层是会话层，通过长连接和 Client 层的应用服务器保持通讯，负责接收 Client 的服务发布和服务订阅请求。该层只在内存中保存各个服务的发布订阅关系，对于具体的服务信息，只在 Client 层和 Data 层之间透传转发。Session 层是无状态的，可以随着 Client 层应用规模的增长而扩容。\n Data 层 数据服务器集群。Data 层通过分片存储的方式保存着所用应用的服务注册数据。数据按照 dataInfoId（每一份服务数据的唯一标识）进行一致性 Hash 分片，多副本备份，保证数据的高可用。下文的重点也在于随着数据规模的增长，Data 层如何在不影响业务的前提下实现平滑的扩缩容。\n Meta 层 元数据服务器集群。这个集群管辖的范围是 Session 服务器集群和 Data 服务器集群的服务器信息，其角色就相当于 SOFARegistry 架构内部的服务注册中心，只不过 SOFARegistry 作为服务注册中心是服务于广大应用服务层，而 Meta 集群是服务于 SOFARegistry 内部的 Session 集群和 Data 集群，Meta 层能够感知到 Session 节点和 Data 节点的变化，并通知集群的其它节点。\nSOFARegistry 如何突破单机存储瓶颈 在蚂蚁金服的业务规模下，单台服务器已经无法存储所有的服务注册数据，SOFARegistry 采用了数据分片的方案，每台机器只保存一部分数据，同时每台机器有多副本备份，这样理论上可以无限扩容。根据不同的数据路由方式，常见的数据分片主要分为两大类：范围分片和 Hash（哈希）分片。\n图4 数据分片\n 范围分片 每一个数据分片负责存储某一键值区间范围的值。例如按照时间段进行分区，每个小时的 Key 放在对应的节点上。区间范围分片的优势在于数据分片具有连续性，可以实现区间范围查询，但是缺点在于没有对数据进行随机打散，容易存在热点数据问题。\n Hash （哈希）分片 Hash 分片则是通过特定的 Hash 函数将数据随机均匀地分散在各个节点中，不支持范围查询，只支持点查询，即根据某个数据的 Key 获取数据的内容。业界大多 KV（Key-Value）存储系统都支持这种方式，包括 cassandra、dynamo、membase 等。业界常见的 Hash 分片算法有哈希取模法、一致性哈希法和虚拟桶法。\n哈希取模 哈希取模的 Hash 函数如下：\nH(Key) = hash(key) mod K; 这是一个 key-machine 的函数。key 是数据主键，K 是物理机数量，通过数据的 key 能够直接路由到物理机器。当 K 发生变化时，会影响全体数据分布。所有节点上的数据会被重新分布，这个过程是难以在系统无感知的情况下平滑完成的。\n图5 哈希取模\n一致性哈希 分布式哈希表（DHT）是 P2P 网络和分布式存储中一项常见的技术，是哈希表的分布式扩展，即在每台机器存储部分数据的前提下，如何通过哈希的方式来对数据进行读写路由。其核心在于每个节点不仅只保存一部分数据，而且也只维护一部分路由，从而实现 P2P 网络节点去中心化的分布式寻址和分布式存储。DHT 是一个技术概念，其中业界最常见的一种实现方式就是一致性哈希的 Chord 算法实现。\n 哈希空间 一致性哈希中的哈希空间是一个数据和节点共用的一个逻辑环形空间，数据和机器通过各自的 Hash 算法得出各自在哈希空间的位置。\n图6 数据项和数据节点共用哈希空间\n图7是一个二进制长度为5的哈希空间，该空间可以表达的数值范围是0～31（2^5），是一个首尾相接的环状序列。环上的大圈表示不同的机器节点（一般是虚拟节点），用 $$Ni$$ 来表示，$$i$$ 代表着节点在哈希空间的位置。例如，某个节点根据 IP 地址和端口号进行哈希计算后得出的值是7，那么 N7 则代表则该节点在哈希空间中的位置。由于每个物理机的配置不一样，通常配置高的物理节点会虚拟成环上的多个节点。\n图7 长度为5的哈希空间\n环上的节点把哈希空间分成多个区间，每个节点负责存储其中一个区间的数据。例如 N14 节点负责存储 Hash 值为8～14范围内 …","date":1586340000,"description":"本文介绍 SOFARegistry 分片算法和相关核心源码来展示蚂蚁金服是如何解决数据分片带来的节点上下线数据波动的问题。","dir":"blog/sofa-registry-dataserver-smooth-expansion-contraction/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"35c77b7278ad2675b56540b1f97ecf8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","publishdate":"2020-04-08T18:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","summary":"SOFAStack（Scalable Open Financial Architecture Stack ）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里","tags":["SOFARegistry ","剖析 | SOFARegistry 框架","SOFALab"],"title":"蚂蚁金服服务注册中心如何实现 DataServer 平滑扩缩容 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","wordcount":6179},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@王磊 提问：\n SOFARPC 注册的 Dubbo 服务和通过 Dubbo 组件注册的服务可以互通的吧？\n A：可以的， Dubbo 是桥接模式。\n 这个怎么配置的。现在注册的 Dubbo 服务 generic=false。 A：现在只支持泛化调用不支持泛化服务，可以关注一下这个 Issue，后期会排期做，也欢迎共建。 https://github.com/sofastack/sofa-rpc/issues/894\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@黄振祥 提问：\n 使用 SOFAStack 快速构建微服务的 Demo 时遇到的一些问题，可以怎么解决呢？ https://github.com/sofastack-guides/kc-sofastack-demo\n A：可以详细看一下这个 issue： https://github.com/sofastack-guides/kc-sofastack-demo/issues/9\n3、@哈哈哈 提问：\n AT 和 Saga 有什么区别吗，AT 我感觉是自动的 Saga。\n A：也可以这么说，Saga 框架上没有加锁，AT 有加锁，事实上 Seata Saga 是一个具备“服务编排”和“Saga 分布式事务”能力的产品。\n4、@全 提问：\n 麻烦问一下，Seata TCC 只支持 Dubbo、SOFARPC 吗？\n A：还有 local，其他的 rpc 框架可以基于 local 包装一下或者扩展下 parser，也欢迎大家贡献。\n 如果通过 spring-cloud 整合的话需要扩展这个 Parser 是吧？\n A：是的，但是像 resttemplate 这种 rest 请求没办法走 parser，需要你 local 包一下。 Seata：https://github.com/seata/seata\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n发布 SOFA MOSN v0.11.0 版本，主要变更如下：\n 重构 XProtocol Engine，优化了协议层的实现； 支持 Listener Filter 的扩展，基于 Listener Filter 重新实现了透明劫持能力； 优化了 LDS 接口，修改了路由配置结构，完善了变量机制； 完善了 TraceLog 的实现； Bug Fix； 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/v0.11.0\n社区直播报名 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n本期直播包含 Demo，可以先下载 Demo，提前体验 MOSN 拓展机制的使用（报名页面有详细 Demo 链接）。\n 主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 时间：2020年4月9日（下周四）19:00-20:00 嘉宾：永鹏 蚂蚁金服高级开发工程师、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1585908000,"description":"【03/30-04/03】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200403/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e109585632269dffffd2819dd121da2b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200403/","publishdate":"2020-04-03T18:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200403/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告 \u0026 发布更新、Service Mesh 落地实践解析合辑","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200403/","wordcount":1376},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@John Deng 提问：\n 现在 MOSN 对 Dubbo 协议支持怎样？\n A：这儿，协议支持了：https://github.com/mosn/mosn/tree/master/pkg/protocol/xprotocol/dubbo 完整的支持，我们已经创建了 Dubbo WG 专门来做这个事情，https://github.com/mosn/community/blob/master/wg-dubbo.md\n 已经生产就绪了吗？\n A：如果是 Dubbo 的话，目前还没有生产可用，主要是相关生态还没对齐，我们正在推进 Dubbo WG kick off，有兴趣可以加入一起完善。 如果指 MOSN 的话，我们去年双11已经线上部署几十万容器，生产可用。 MOSN：https://github.com/mosn/mosn\n2、@Liang 提问：\n SOFAJRaft 的 Leader 节点执行完状态机，把这次的 index 提交之后，什么时候通知的 Follower 节点也提交呢？ 我看现象是 Follower 也立刻跟着提交了，但是这块代码没有找到。想问下具体是怎么实现的，谢谢~\n A：Leader 会往 Follower 发送 lastCommittedIndex， 详情见：\ncom.alipay.sofa.jraft.core.NodeImpl#handleAppendEntriesRequest com.alipay.sofa.jraft.core.BallotBox#setLastCommittedIndex SOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@琦玉 提问：\n 这种情况下，状态机怎么确定是执行回滚，还是执行重试呢？ A：这个是由开发者决定的。 Server 事务恢复的逻辑是：\n 当提交失败时，重试提交； 补偿失败时，重试补偿； 如果超时默认是进行重试补偿，如果配置了这个\u0026amp;rdquo;RecoverStrategy\u0026amp;rdquo;: \u0026amp;ldquo;Forward\u0026amp;rdquo;则进行重试向前执行； 这个\u0026amp;rdquo;RecoverStrategy\u0026amp;rdquo;: \u0026amp;ldquo;Forward\u0026amp;rdquo;配置是告诉状态机默认的事务恢复策略。如果发现这条事务无法向前，也可以通过手动调状态机“补偿”。\n 这种是否最终成功可能有其它业务上的条件，比如取决于另外一个步骤的成功与否。没法在状态语言里面定义。如果 A 充值成功，事务失败，B 就不能回退，必须重试到最终成功。如果 A 充值失败，事务失败，B 就可以回退。这种具体是要怎么去处理呢？分布式事务内先给用户 A 充值, 然后给用户 B 扣减余额, 如果在给 A 用户充值成功, 在事务提交以前, A 用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了\n A：不允许这样设计，业务流水，必须先扣，再充，必须要遵循“宁可长款，不可短款”的原则。\n 意思是分成两个独立的事务，Saga 模式中不定义在同一个状态机流程里？先把B的扣钱流程执行完，再去执行 A 的充值流程 ？\n A：不是，是在同一个事务里，同一个流程，要先进行扣 B 的款，再给 A 充值，那和如果充值失败，可以回滚 B。\n 假如同时给 B 和 C 充值呢？\n A：那就都向前重试，因为充钱业务上不会失败。\n 如果做重试的话，是不是整个流程其它做回退的动作都要在充值动作之前完成?在重试动作之后的动作都只能做重试?\n A：也不是完全只能这样，要根据业务场景来吧。做一个合理的流程设计。 相关阅读：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 Seata：https://github.com/seata/seata\n本周推荐阅读 Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 SOFARegistry v5.4.2 版本，主要变更如下：\n 修复 cloud 模式推送时客户端 cell 设置错误的问题； 详细发布报告： https://github.com/sofastack/sofa-registry/releases/tag/v5.4.2\n社区直播报名 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n本期直播包含 Demo，可以先下载 Demo，提前体验 MOSN 拓展机制的使用（报名页面有详细 Demo 链接）。\n 主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 时间：2020年4月9日（周四）19:00-20:00 嘉宾：永鹏 蚂蚁金服高级开发工程师、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1585299600,"description":"【03/23-03/27】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-0327/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0c6b194e66eeb4c95efa4260e279bab7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0327/","publishdate":"2020-03-27T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0327/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告、本周直播回顾整理、SOFARegistry 发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0327/","wordcount":1980},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析\n 活动时间：4 月 9 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n欢迎先下载 Demo，提前体验 MOSN 拓展机制的使用，成功完成预习作业—— Demo 完整操作的，有机会获得小礼物哟（记得留下完成的证明，获得方式在直播中公布），我们将在直播中公布答案——进行 Demo 的详细演示。PS：在直播中也会发布闯关任务，完成闯关任务也有机会获得小礼物哟～\nDemo：https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions\nDemo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions\n欢迎了解 MOSN：https://github.com/mosn/mosn\n| 针对人群 对云原生、Service Mesh、网络代理有基本了解，想要了解云原生以及对云原生网络代理 MOSN 有二次开发需求的人群\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：21992058（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1131\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 永鹏 蚂蚁金服高级开发工程师， MOSN Committer\n你将收获 快速了解 MOSN 的多种扩展能力 3 个案例，实际体验 MOSN 扩展能力 多案例多形式，使用 MOSN 实现个性化业务需求 嘉宾 SOFAGirl 主持人 永鹏 蚂蚁金服高级开发工程师， MOSN Committer ","date":1585299600,"description":"4 月 9 日周四晚 7 点，线上直播第 14 期。","dir":"activities/sofa-channel-14/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0e1d5c0ea19ec82218fbf675b891ee5a","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-14/","publishdate":"2020-03-27T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-14/","summary":"概要 活动主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 活动时间：4 月 9 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍","tags":["SOFAChannel","MOSN"],"title":"SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-14/","wordcount":901},{"author":"无钩","categories":"MOSN","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。 本文根据 SOFAChannel#13 直播分享整理，主题：云原生网络代理 MOSN 多协议机制解析。\n 大家好，我是今天的讲师无钩，目前主要从事蚂蚁金服网络代理相关的研发工作，也是 MOSN 的 Committer。今天要和大家分享的是《云原生网络代理 MOSN 多协议机制解析》，并介绍对应的私有协议快速接入实践案例以及对 MOSN 实现多协议低成本接入的设计进行解读。\n我们将按以下顺序进行介绍：\n 多协议机制产生的背景与实践痛点； 常见的协议扩展思路初探； SOFABolt 协议接入实践；（重点） MOSN 多协议机制设计解读；（重点） 后续规划及展望； 其中第三点「接入实践」是今天分享的重点，希望能给大家就「如何在 MOSN 中快速扩展私有协议接入」有一个具体的感受。另外「MOSN 如何实现多协议框架」也是很多人关心和问题，我们将摘选几个技术功能，对其背后的设计思考进行解读。\nMOSN 简介 云原生网络代理 MOSN 定位是一个全栈的网络代理，支持包括网络接入层(Ingress)、API Gateway、Service Mesh 等场景，目前在蚂蚁金服内部的核心业务集群已经实现全面落地，并经受了 2019 年双十一大促的考验。今天要向大家介绍的是云原生网络代理 MOSN 核心特性之一的多协议扩展机制，目前已经支持了包括 SOFABolt、Dubbo、TARS 等多个协议的快速接入。\nMOSN：https://github.com/mosn\n多协议机制产生的背景与实践痛点 首先介绍一下多协议机制产生的背景。\n前面提到，蚂蚁金服 2019 年双十一核心链路百分之百 Mesh 化，是业界当时已知的最大规模的 Service Mesh 落地，为什么我们敢这么做？因为我们具备能够让架构平滑迁移的方案。\u0026amp;rdquo;兼容性\u0026amp;rdquo;是任何架构演进升级都必然要面对的一个问题，这在早已实践微服务化架构的蚂蚁金服内部同样如此。为了实现架构的平滑迁移，需要让新老节点的外在行为尽可能的表现一致，从而让依赖方无感知，这其中很重要的一点就是保持协议兼容性。\n因此，我们需要在 Service Mesh 架构下，兼容现有微服务体系中的通信协议——也就是说需要在 MOSN 内实现对目前蚂蚁金服内部通信协议的扩展支持。\n基于 MOSN 本身的扩展机制，我们完成了最初版本的协议扩展接入。但是在实践过程中，我们发现这并不是一件容易的事情：\n 相比编解码，协议自身的处理以及与框架集成才是其中最困难的环节，需要理解并实现包括请求生命周期、多路复用处理、链接池等等机制； 社区主流的 xDS 路由配置是面向 HTTP 协议的，无法直接支持私有协议，存在适配成本； 基于这些实践痛点，我们设计了 MOSN 多协议框架，希望可以降低私有协议的接入成本，加快普及 ServiceMesh 架构的落地推进。\n常见的协议扩展思路初探 前面介绍了背景，那么具体协议扩展框架要怎么设计呢？我们先来看一下业界的思路与做法。\n协议扩展框架 - Envoy 注：图片来自 Envoy 分享资料\n第一个要介绍的是目前发展势头强劲的 Envoy。从图上可以看出，Envoy 支持四层的读写过滤器扩展、基于 HTTP 的七层读写过滤器扩展以及对应的 Router/Upstream 实现。如果想要基于 Envoy 的扩展框架实现 L7 协议接入，目前的普遍做法是基于 L4 filter 封装相应的 L7 codec，在此基础之上再实现对应的协议路由等能力，无法复用 HTTP L7 的扩展框架。 协议扩展框架 - Nginx 第二个则是老牌的反向代理软件 Nginx，其核心模块是基于 Epoll/Kqueue 等 I/O 多路复用技术之上的离散事件框架，基于事件框架之上构建了 Mail、Http 等协议模块。与 Envoy 类似，如果要基于 Nginx 扩展私有协议，那么也需要自行对接事件框架，并完整实现包括编解码、协议处理等能力。\n协议扩展框架 - MOSN 最后回过头来，我们看一下 MOSN 是怎么做的。实际上，MOSN 的底层机制与 Envoy、Nginx 并没有核心差异，同样支持基于 I/O 多路复用的 L4 读写过滤器扩展，并在此基础之上再封装 L7 的处理。但是与前两者不同的是，MOSN 针对典型的微服务通信场景，抽象出了一套适用于基于多路复用 RPC 协议的扩展框架，屏蔽了 MOSN 内部复杂的协议处理及框架流程，开发者只需要关注协议本身，并实现对应的框架接口能力即可实现快速接入扩展。\n三种框架成本对比 最后对比一下，典型微服务通信框架协议接入的成本，由于 MOSN 针对此类场景进行了框架层面的封装支持，因此可以节省开发者大量的研发成本。\nSOFABolt 协议接入实践 初步了解多协议框架的设计思路之后，让我们以 SOFABolt 协议为例来实际体验一下协议接入的过程。\nSOFABolt 简介 这里先对 SOFABolt 进行一个简单介绍，SOFABolt 是一个开源的轻量、易用、高性能、易扩展的 RPC 通信框架，广泛应用于蚂蚁金服内部。\nSOFABolt：https://github.com/sofastack/sofa-bolt\n基于 MOSN 的多协议框架，实际编写了 7 个代码文件，一共 925 行代码(包括 liscence、comment 在内)就完成了接入。如果对于协议本身较为熟悉，且具备一定的 MOSN/Golang 开发经验，甚至可以在一天内就完成整个协议的扩展，可以说接入成本是非常之低。\nGithub: https://github.com/mosn/mosn/tree/master/pkg/protocol/xprotocol/bolt\n下面让我们进入正题，一步一步了解接入过程。\nStep1：确认协议格式 第一步，需要确认要接入的协议格式。为什么首先要做这个，因为协议格式是一个协议最基本的部分，有以下两个层面的考虑：\n 任何协议特性以及协议功能都能在上面得到一些体现，例如有无 requestId/streamId 就直接关联到协议是否支持连接多路复用； 协议格式与报文模型直接相关，两者可以构成逻辑上的映射关系；而这个映射关系也就是所谓的编解码逻辑； 以 SOFABolt 为例，其第一个字节是协议 magic，可以用于校验当前报文是否属于 SOFABolt 协议，并可以用于协议自动识别匹配的场景；第二个字节是 type，用于标识当前报文的传输类型，可以是 Request / RequestOneway / Response 中的一种；第三个字节则是当前报文的业务类型，可以是心跳帧，RPC 请求/响应等类型。后面的字段就不一一介绍了，可以发现，理解了协议格式本身，其实对于协议的特性支持和模型编解码就理解了一大半，因此第一步协议格式的确认了解是重中之重，是后续一切工作开展的前提。\nStep2：确认报文模型 顺应第一步，第二步的主要工作是确认报文编程模型。一般地，在第 …","date":1585227600,"description":"本文根据昨晚直播整理，主要分享云原生网络代理 MOSN 多协议机制解析，并介绍对应私有协议快速接入实践案例以及对其实现多协议低成本接入的设计进行解读。","dir":"blog/sofa-channel-13-retrospect/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"683f36d11af9e48e910e694bf1a119fc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-13-retrospect/","publishdate":"2020-03-26T21:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-channel-13-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["MOSN","Service Mesh","SOFAChannel"],"title":"云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-13-retrospect/","wordcount":6523},{"author":"敖小剑","categories":"Service Mesh","content":" 在2019年5月，CNCF 筹建通用数据平面 API 工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API。\n当时我写了一个博客文章 “CNCF 正在筹建通用数据平面 API 工作组，以制定数据平面的标准 API” 对此进行了介绍。当时 UDPA 还处于非常早期的筹备阶段，信息非常的少。\n现在9个月过去了，我最近收集并整理了一下 UDPA 目前的情况和信息，给大家介绍一下 UDPA 目前最新的进展（截止2020年2月24日）。\n另外蚂蚁金服开源的云原生网络代理 MOSN 目前已经支持 xDS v2 API，后面也会逐步向着 UDPA 的方向去演进，兼容标准 Istio，感兴趣的读者可以去了解下。\nMOSN：https://github.com/mosn/mon\nUDPA 介绍 首先快速介绍一下什么是 UDPA：\n UDPA ：“Universal Data Plane API”的缩写， “通用数据平面 API” UDPA-WG：”Universal Data Plane API Working Group”的缩写，这是 CNCF 下的一个工作组，负责制定 UDPA； UDPA 的目标，援引自 https://github.com/cncf/udpa 的描述：\n 通用数据平面 API 工作组（UDPA-WG）的目标是召集对数据平面代理和负载均衡器的通用控制和配置 API 感兴趣的业界人士。\n UDPA 的愿景，同样援引：\n 通用数据平面 API（UDPA）的愿景在 https://blog.envoyproxy.io/the-universal-data-plane-api-d15cec7a 中阐明。我们将寻求一组 API，它们为 L4/L7 数据平面配置提供事实上的标准，类似于 SDN 中 L2/L3/L4 的 OpenFlow 所扮演的角色。 这些 API 将在 proto3 中规范定义，并通过定义良好的、稳定 API 版本控制策略，从现有的 Envoy xDS API 逐步演进。API 将涵盖服务发现、负载均衡分配、路由发现、监听器配置、安全发现、负载报告、运行状况检查委托等。 我们将对 API 进行改进和成型，以支持客户端 lookaside 负载均衡（例如 gRPC-LB），Envoy 之外的数据平面代理，硬件 LB，移动客户端以及其他范围。我们将努力尽可能与供应商和实现无关，同时坚持支持已投入生产的 UDPA 的项目（到目前为止，Envoy 和 gRPC-LB）。\n 对 UDPA 感兴趣的同学，可以通过以下两个途径进一步深入了解：\n UDPA @ GitHub：UDPA 在 github 上的项目，UDPA API 定义的代码都在这里； Universal Data Plane API Working Group (UDPA-WG)：CNCF 的 UDPA 工作组，可以通过加入工作组的方式了解更多信息； UDPA 和 xDS 的关系 在展开 UDPA 的细节之前，有必要先解释清楚 UDPA 和 xDS 的关系，因为这对理解 UDPA 会有很大帮助。\n在2019年11月的 EnvoyCon 上，Envoy 的开发者，也是目前 UDPA 最主要的负责人之一，来自 Google 的 Harvey Tuch，有一个演讲非常详细而清晰的解答了这个问题，这个演讲的标题是：“The Universal Dataplane API (UDPA): Envoy’s Next Generation APIs”。\n 备注：这里我直接援引这份演讲的部分内容，以下两张图片均出自 这份演讲的PPT 。鸣谢 Harvey。\n 下图展示了近年来 xDS 协议的演进历程和未来规划：\n 2017年，xDS v2 引入 proto3 和 gRPC，同年 Istio 项目启动； 2018和2019年，xDS v2 API 继续发展，陆续引入了新的 API 定义，如 HDS / LRS / SDS 等，尤其是为了改进 Pilot 下发性能，开始引入增量推送机制； xDS v3 API 原计划于2019年年底推出，但目前看技术推迟，目前 v3 还是 alpha1 状态，预计在即将发布的 Istio 1.5 中会有更多的 v3 API 引入。同时 v3 API 也引入了 UDPA 的部分内容，但是由于 UDPA 目前进展缓慢，对 xDS 的影响并不大，主要还是 xDS 自身的发展，比如对 API 和技术债务的清理； 但在2020年，预计 UDPA 会有很大的进展，尤其是下面我们将会展开的 UDPA-TP 和 UDPA-DM 的设计开始正式制定为 API 之后。而 xDS v4 预计将基于 UDPA ，因此 xDS v4 可能会迎来比较大的变动； 简单总结说：xDS 将逐渐向 UDPA 靠拢，未来将基于 UDPA 。\n下图则展示了 Envoy 在 xDS 版本支持上的时间线：\n目前看这个计划在执行时稍微有一点点延误，原计划于2019年年底推出的 v3 的 stable 版本实际上是在1月中定稿的。（备注：具体可参考 Envoy PR api: freeze v3 API ）。然后目前正在广泛使用的 v2 API 将被标记为 depreated。而且在2020年底，v3 API 预计被 v4 API 取代（注意 v4 API 将会是基于 UDPA），而目前我们最熟悉的 v2 API 将计划在2020年底移除，不再支持！\n上图也展示了未来 xDS 协议的大版本演进和更替的方式，总的来说规律是这样：\n 一年一个大版本：2019 v2 -\u0026amp;gt; 2020 v3 -\u0026amp;gt; 2021 v4 -\u0026amp;gt;2022 v5； 每个大版本都要经历 alpha -\u0026amp;gt; stable -\u0026amp;gt; deprecated -\u0026amp;gt; removed 四个阶段，每个阶段历时一年； 稳定后 Envoy 会同时存在三个 API 大版本：正在使用的稳定版本，已经弃用的上一个稳定版本，准备开发的新的下一个大版本（但只会是Alpha）； 发布一个新的 stable 的大版本，就一定会 deprecated 上一个稳定的大版本，同时 remove 更前一个已经 deprecated 的大版本； 所谓 “长江后浪推前浪，前浪死在沙滩上”，又或者说，“江山代有新版出，各领风骚12个月”。\n 备注：Envoy 具体的稳定 API 版本控制策略，可以参见 Envoy 的设计文档 “Stable Envoy API versioning” ，不过这个文档长的有点过分，嫌长的同学可以直接看这个文档的缩减版本 API versioning guidelines。\n UDPA API 进展 言归正传，我们来看一下 UDPA 目前的最新进展。从 https://github.com/cncf/udpa ，可以看到目前 UDPA 中已经定义好的部分 API 内容：\n类型定义 目前只定义了一个类型 TypedStruct。\nTypedStruct 包含任意 JSON …","date":1585130400,"description":"本文收集并整理了一下 UDPA 目前的情况和信息，给大家介绍一下 UDPA 目前最新的进展。","dir":"blog/service-mesh-api-udpa-follow-up/","fuzzywordcount":11000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7293f926580393ddac18da73da056d07","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","publishdate":"2020-03-25T18:00:00+08:00","readingtime":22,"relpermalink":"/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","summary":"在2019年5月，CNCF 筹建通用数据平面 API 工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API。 当时我写了一","tags":["Service Mesh"],"title":"Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍","type":"blog","url":"/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","wordcount":10901},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@木易 提问：\n 请问，这个并发隔离是怎么做到的？二阶段是一阶段的最后去做的对吧，在 TCC 模式下的，RPC 调用二阶段失败了或者 MQ 异步调二阶段失败了，那二阶段失败了可咋整？ A：一阶段如果都成功了，说明所有分支的事务的“资源”已经预留成功了，这时候的失败都是“技术上”的失败比如网络抖动，这时会要重试提交。举个例子，如果二阶段一部份服务 commit 成功了，然后有一个失败了，这时只能重试提交，不能回滚，因为那些二阶段已经成功的服务，不能回滚了。\n 是不是一阶段的发起方还得根据业务编号记录一条 response，然后参与方定时去扫状态未更新的记录，然后根据业务编号去查 response 中的状态再更新自己的状态？\n A：业务流水是肯定要记的。\n 有行锁可用余额肯定没问题，就是这个预扣冻结字段如果放这行数据里，一阶段一释放锁，另一个事务给他改了就不对了，所以我感觉表里加这个字段不行啊，还是得用业务流水加这个预扣字段形成一条记录，这样事务之间的这个才是隔离的 。\n A：是的，是在业务上还要记录一条流水，一来为是业务上的要求，二来可以做幂等和防悬挂控制，三也是在回滚的时候需要这条流水才知道要回滚多少金额。\n相关阅读：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理\nSeata：https://github.com/seata/seata\n2、@邓从宝 提问：\n 您好，合并部署是个什么概念？什么时候会用到合并部署？\n A： 就是将原本独立开发的应用部署在一起，比如资源有限要高密度部署的时候，比如两个微服务应用频繁 rpc 交互想要部署到一个进程里提高性能的时候。\n3、@苏东东 提问：\n SOFAJRaft 能不能不通过 rpcserver 注册 GetValueRequestProcessor，我想用自己的 RPC 框架。\n A：暂时不能，请关注这个 pr 合并以后就可以了 https://github.com/sofastack/sofa-jraft/pull/402 详细 issue： https://github.com/sofastack/sofa-jraft/issues/268 SOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFAArk 解析文章集合 蚂蚁金服轻量级类隔离框架 Maven 打包插件解析 | SOFAArk 源码解析 蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFATracer 解析文章集合 蚂蚁金服分布式链路跟踪组件 SOFATracer 中 Disruptor 实践（含源码） 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 埋点机制剖析 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 采样策略和源码剖析 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 链路透传原理与SLF4J MDC 的扩展能力剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析 社区直播报名 作为云原生网络代理，Service Mesh 是 MOSN 的重要应用场景。随着 Service Mesh 概念的日益推广，大家对这套体系都已经不再陌生，有了较为深入的认知。但是与理论传播相对应的是，生产级别的大规模落地实践案例却并不多见。这其中有多方面的原因，包括社区方案饱受诟病的“大规模场景性能问题”、“配套的运维监控基础设施演进速度跟不上”、“存量服务化体系的兼容方案”等等。\n现实场景中，大部分国内厂商都有一套自研 RPC 的服务化体系，属于「存量服务化体系的兼容方案」中的协议适配问题。为此，MOSN 设计了一套多协议框架，用于降低自研体系的协议适配及接入成本，加速 Service Mesh 的落地普及。SOFAChannel#13，将向大家介绍 MOSN 实现多协议低成本接入的设计思路以及相应的快速接入实践案例。\n 主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 时间：2020年3月26日（周四）19:00-20:00 嘉宾：无钩，蚂蚁金服技术专家、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 欢迎参与投票 MOSN Logo 社区投票，在本期直播结束将公布投票结果，确定最新 Logo。\n 投票方式：回复 issue 你喜欢的方案编号以及原因 ","date":1584691200,"description":"【03/16-03/20】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200320/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e2add88606de2be4ddcf9c9ac2e4bbef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200320/","publishdate":"2020-03-20T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200320/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告、SOFAArk\u0026SOFATracer 解析文章合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200320/","wordcount":1761},{"author":"盲僧","categories":"SOFAArk","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAArk 实现原理》第二篇，本篇作者盲僧，来自 OYO。《剖析 | SOFAArk 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附系列共建列表，目前已完成领取。\n前言 SOFAArk 是 SOFA 团队开源的又一款扛鼎力作，它是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署的能力。\n从 2016 年底开始，蚂蚁金服内部开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构，也是为系列文章做好铺垫。\nSOFAArk biz 的打包插件是 sofa-ark-maven-plugin ，它可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式的 Ark 包或者 Ark Biz 包，关于 Ark 包和 Ark Biz 包可以参考这里：\n Ark 包：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/ Ark Biz：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/ 本文将从如下三个方面进行介绍：先对插件的使用和打包出来的产物做一个简单介绍，然后告诉大家调试插件的方法，最后对整个插件的原理做一个流程图和阐述。\nSOFAArk ：https://github.com/sofastack/sofa-ark\nSOFAArk 插件使用 文中的示例代码可以参考 我的 github\n 插件使用 先将 Spring Boot 的打包插件 spring-boot-maven-plugin 删除或者注释，然后再引入如下插件即可：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 执行 mvn package 命令后，将会打出如下结构的 3 个 jar 包，大家可以自行解压这三个 jar 包，看一看里面的具体内容，下面我们简单分析一下：\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT.jar ：它是 maven 插件打出来的原生 jar 包，只包含我们写的代码和 manifest 文件，无特殊意义。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-biz.jar ：这个 jar 包称之为 Ark Biz 包，因为 SOFAArk 容器是支持运行多个 Ark Biz 的，所以打成这种包是为了和别的项目一起合并部署使用，另外 Ark 包里也包含了这个。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-executable.jar ：这个 jar 包称之为 Ark 包，从字面上来看它是一个可执行的 jar 包，即意味着它是一个可以用 java-jar 命令来单独运行的 Fat Jar，类似于我们用 Spring Boot 插件打出来的包。\n后面的分析主要是围绕 Ark 包来做讲解，因为它包含了 Ark Biz 包，所以只要搞明白它是如何生成的，那么对整个插件的原理也就基本了解了。\n与 Spring Boot 插件对比 要想分析出 sofa-ark-maven-plugin 插件的作用，我们需要先和 Spring Boot 的插件进行对比，从打包产物上直观的感受一下两者的区别。\nspring-boot-maven-plugin 插件 spring-boot-maven-plugin 是 SpringBoot 默认提供的打包插件，其功能就是将工程打包成一个可执行的 FATJAR。spring-boot-maven-plugin 打包产物的目录结构如下：\n. ├── BOOT-INF │ ├── classes # 应用的字节码目录 │ └── lib # 应用所依赖的 jar 包 ├── META-INF │ ├── MANIFEST.MF # manifest 文件信息 │ └── maven # 应用的坐标信息 └── org └── springframework └── boot └── loader # 存放的是 Spring Boot Loader 的 class 文件 ├── JarLauncher.class # Spring Boot 启动类 ├── archive ├── data ├── jar └── util MANIFEST.MF 文件内容：\nManifest-Version: 1.0 Archiver-Version: Plexus Archiver Built-By: rrz Start-Class: pers.masteryourself.tutorial.sofa.ark.maven.plugin.MavenP luginApplication Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Spring-Boot-Version: 2.1.4.RELEASE Created-By: Apache Maven 3.5.3 Build-Jdk: 1.8.0_101 Main-Class: org.springframework.boot.loader.JarLauncher MANIFEST.MF 文件中可以看到，描述了当前 jar 的一些核心元素，包括启动类、class 文件路径、lib 依赖路径、jdk 版本等等，这里需要关注的是 Main-Class，SpringBoot 就是通过该类来引导启动的。SOFAArk 应用也提供了类似的引导类及其自身特殊的结构， …","date":1584612000,"description":"本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构","dir":"blog/sofa-ark-maven- packaging-plugins/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dd530d14f20a460c2f49300c0d784c32","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","publishdate":"2020-03-19T18:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAArk","SOFAArkLab"],"title":"蚂蚁金服轻量级类隔离框架 Maven 打包插件解析 | SOFAArk 源码解析","type":"blog","url":"/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","wordcount":3304},{"author":"卫恒","categories":"SOFATracer","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n Disruptor 简介 Disruptor 旨在在异步事件处理体系结构中提供低延迟，高吞吐量的工作队列。它确保任何数据仅由一个线程拥有以进行写访问，因此与其他结构相比，减少了写争用。目前，包括 Apache Storm、Camel、Log4j 2 在内的很多知名项目都应用了 Disruptor 以获取高性能。\nSOFATracer 也是基于 Disruptor 高性能无锁循环队列来提供异步打印日志到本地磁盘能力的，SOFATracer 提供两种类似的日志打印类型即摘要日志和统计日志，摘要日志：每一次调用均会落地磁盘的日志；统计日志：每隔一定时间间隔进行统计输出的日志；无论是哪种日志的输出，对于 SOFATracer 来说都需要保证较高的性能，以降低对于业务整体流程耗时的影响。\n关于 Disruptor 的 一些原理分析可以参考：Disruptor 。\n A High Performance Inter-Thread Messaging Library 高性能的线程间消息传递库\n 案例 先通过 Disruptor 的一个小例子来有个直观的认识；先看下它的构造函数：\npublic Disruptor( final EventFactory\u0026amp;lt;T\u0026amp;gt; eventFactory, final int ringBufferSize, final ThreadFactory threadFactory, final ProducerType producerType, final WaitStrategy waitStrategy) { this( RingBuffer.create(producerType, eventFactory, ringBufferSize, waitStrategy), new BasicExecutor(threadFactory)); } eventFactory : 在环形缓冲区中创建事件的 factory； ringBufferSize:环形缓冲区的大小，必须是2的幂； threadFactory：用于为处理器创建线程； producerType：生成器类型以支持使用正确的sequencer和publisher创建RingBuffer；枚举类型，SINGLE、MULTI两个项。对应于 SingleProducerSequencer和MultiProducerSequencer两种Sequencer； waitStrategy : 等待策略； 如果我们想构造一个 disruptor，那么我们就需要上面的这些组件。从 eventFactory 来看，还需要一个具体的 Event 来作为消息事件的载体。【下面按照官方给的案例进行简单的修改作为示例】\n消息事件 LongEvent ，能够被消费的数据载体 public class LongEvent { private long value; public void set(long value) { this.value = value; } public long getValue() { return value; } } 创建消息事件的 factory public class LongEventFactory implements EventFactory\u0026amp;lt;LongEvent\u0026amp;gt; { @Override public LongEvent newInstance() { return new LongEvent(); } } ConsumerThreadFactory public class ConsumerThreadFactory implements ThreadFactory { private final AtomicInteger index = new AtomicInteger(1); @Override public Thread newThread(Runnable r) { return new Thread(r, \u0026amp;quot;disruptor-thread-\u0026amp;quot; + index.getAndIncrement()); } } OK ，上面的这些可以满足创建一个 disruptor 了：\nprivate int ringBufferCapacity = 8; //消息事件生产Factory LongEventFactory longEventFactory = new LongEventFactory(); //执行事件处理器线程Factory ConsumerThreadFactory consumerThreadFactory = new ConsumerThreadFactory(); //用于环形缓冲区的等待策略。 WaitStrategy waitStrategy = new BlockingWaitStrategy(); //构建disruptor Disruptor\u0026amp;lt;LongEvent\u0026amp;gt; disruptor = new Disruptor\u0026amp;lt;\u0026amp;gt;( longEventFactory, ringBufferCapacity, longEventThreadFactory, ProducerType.SINGLE, waitStrategy); 现在是已经有了 disruptor 了，然后通过：start 来启动：\n//启动 disruptor disruptor.start(); 到这里，已经构建了一个disruptor；但是目前怎么使用它来发布消息和消费消息呢？\n发布消息 下面在 for 循环中 发布 5 条数据：\nRingBuffer\u0026amp;lt;LongEvent\u0026amp;gt; ringBuffer = disruptor.getRingBuffer(); for (long l = 0; l \u0026amp;lt; 5; l++) { long sequence = ringBuffer.next(); LongEvent event = ringBuffer.get(sequence); event.set(100+l); System.out.println(\u0026amp;quot;publish event :\u0026amp;quot; + l); ringBuffer.publish(sequence); Thread.sleep(1000); } 消息已经发布，下面需要设定当前 disruptor 的消费处理 …","date":1584439200,"description":"本文将对 SOFATracer 中使用 Disruptor 来进行日志输出的代码进行了具体的分析。","dir":"blog/sofa-trcaer-disruptor-practice/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a97d804a20a7af180c889c55210ab2fa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","publishdate":"2020-03-17T18:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFATracer"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 中 Disruptor 实践（含源码）","type":"blog","url":"/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","wordcount":5441},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析\n 活动时间：3 月 26 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 作为云原生网络代理，Service Mesh 是 MOSN 的重要应用场景。随着 Service Mesh 概念的日益推广，大家对这套体系都已经不再陌生，有了较为深入的认知。但是与理论传播相对应的是，生产级别的大规模落地实践案例却并不多见。这其中有多方面的原因，包括社区方案饱受诟病的“大规模场景性能问题”、“配套的运维监控基础设施演进速度跟不上”、“存量服务化体系的兼容方案”等等。\n现实场景中，大部分国内厂商都有一套自研 RPC 的服务化体系，属于「存量服务化体系的兼容方案」中的协议适配问题。为此，MOSN 设计了一套多协议框架，用于降低自研体系的协议适配及接入成本，加速 Service Mesh 的落地普及。本次演讲将向大家介绍 MOSN 实现多协议低成本接入的设计思路，以及相应的快速接入实践案例。\n本期为 SOFAChannel 线上直播第 13 期，将邀请蚂蚁金服技术专家\u0026amp;amp; MOSN Committer 无钩分享《云原生网络代理 MOSN 的多协议机制解析》。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：21992058（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1131\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 无钩 蚂蚁金服技术专家 MOSN Committer\n本期分享大纲 一个请求的 MOSN 之旅 如何在 MOSN 中接入新的协议 SOFABolt 协议接入实践 未来发展：统一路由框架 嘉宾 SOFAGirl 主持人 无钩 蚂蚁金服技术专家 MOSN Committer ","date":1584349200,"description":"3 月 26 日周四晚 7 点，线上直播第 13 期。","dir":"activities/sofa-channel-13/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ba88bba5176867c90fb18dc045408d84","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-13/","publishdate":"2020-03-16T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-13/","summary":"概要 活动主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 活动时间：3 月 26 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介","tags":["SOFAChannel","MOSN"],"title":"SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-13/","wordcount":692},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@胡秋林 提问：\n 请教一个问题，服务拆分然后使用分布式事务，会不会事务链路过长，然后整体性能下降很大呢？\n A：用了分布式事务性能肯定会下降，这是大家对一致性和性能的取舍。在性能对比这块我建议大家去和同类的分布式事务框架对比，而不是只和不用分布式事务去对比。分布式事务很大一部分是处理的系统异常时的一致性，如果针对系统异常这个点，大家如果相信自己的框架 100% 正常的，不会出现超时，网络和宕机等问题，那可以不使用分布式事务，所以保证一致性的很多场景是极端情况下的一致性，在同类框架的对比中，一定是看框架一致性场景的覆盖，如果场景覆盖不全的基础上和我们对比性能我觉得这个没太大意义。这就好比我系统有 1% 几率出现极端情况，我不用 Seata 和使用 Seata 的对比是一样的。\n2、@吴攀 提问：\n 麻烦问下，我现在做的一个销售订单的流程。需要监听审批的状态变化，然后状态机才往下进行流转。Saga 能否满足呢？  A：目前是不支持的，因为 Saga 的状态机定位是服务编排的事务处理，不应该包含人工审批动作，建议做成两个流程，包含人工审批动作，中间状态时间会很长。\n 我来状态想能否把“状态”配置成“IsAsync = true”来实现，然后异步任务来监听审批状态的变化。感觉有些负责。所以来咨询下？有没有更好其他的推荐的方案呢？Netflix Conductor 能满足这个场景么？我现在的场景是：一个销售单出库的流程。销售单建立成功后，要经过审批流程进行审批，然后进入仓库进行库存分配。分配成功后，进行分拣，然后进行打包。最后进行出库。老板想把这些状态流转编制成一个 Saga 支持的状态机。\n A：isAsync 是这个服务异步调用，应该解决不了你这个问题。我的建议是把这个流程差分一下，拆分成两个，或者，销售订单不要纳入状态机，只是插入一条记录，审批通过后，把后面的流程配置成状态机，而且我理解你们这流程是每一步都是人工做完，然后在系统里点一下，然后继续，如果是这样，这不是服务编排的需求，为是工作流的需求。\nSeata：https://github.com/seata/seata\n3、@兴元 提问：\n SOFABoot 版本 v3.3.0，目前官网文档里只有整合 Nacos 0.6.0 版本的，请问怎么使用 Nacos 的命名空间功能？SOFABoot 版本 v3.3.0，maven 引用里 nacos-client 版本是 1.0.0，请问现在支持 nacos 最新版本是多少。\n A：Nacos 配置格式参考：https://www.sofastack.tech/projects/sofa-rpc/registry-nacos/ 对于 namespace 的，可以配置成这样即可：namespace nacos://yyy:8848/namespaceNacos 客户端应该是兼容的，你可以直接升级这个包的版本。\n 命名空间问题解决了，感谢。因为我使用的时候指定了 nacos client 版本为0.6.0，升级到 0.8.0 以上nacos://yyy:8848/namespace 这种形式是可以的，而且只能使用 nacos://yyy:8848/namespace 这种形式，nacos://yyy:8848 是不行的。还望官方文档可以及时更新一下。\n A：这里应该是要配置成：nacos://yyy:8848/ 后面有个/。好的，最近我们升级一下 Nacos 的 client 版本。文档我们同步修改下。\n 刚试了nacos://yyy:8848/，服务依然无法发布到默认命名空间。Nacos server 是1.2.0，客户端是使用SOFABoot v3.3.0。\n A：不会发到默认的，这个会发到的是 SOFARPC 这个 Namespace：private static final String DEFAULT_NAMESPACE = \u0026amp;quot;sofa-rpc\u0026amp;quot;;\nSOFARPC：https://github.com/sofastack/sofa-rpc\n期待见到，每一个精彩的你 蚂蚁金服云原生团队实习生招聘开始啦 【岗位继续增了】蚂蚁金服云原生团队招聘~欢迎加入我们 SOFAChannel 直播回顾 SOFAChannel#12：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.3.1 版本，主要变更如下：\n 升级 Spring Boot 至 2.1.13.RELEASE； 修复 Tomcat AJP 漏洞； …","date":1584086400,"description":"【03/09-03/13】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200313/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cd22bd67fe25923bca65eae188627da8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200313/","publishdate":"2020-03-13T16:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200313/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 3/26 直播预告、多个组件发布、云原生团队校招社招信息汇总","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200313/","wordcount":2967},{"author":"仁空","categories":"SOFA Weekly","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#12 直播分享整理，主题：蚂蚁金服分布式事务实践解析。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 大家好，我是今天分享的讲师仁空，目前是蚂蚁金服分布式事务产品的研发。今天跟大家分享的是蚂蚁金服分布式事务实践解析，也就是分布式事务 Seata 在蚂蚁金服内部的实践。\n今天我们将从以下 4 个主题进行详细介绍：\n 为什么会有分布式事务产品的需求； 理论界针对这个需求提出的一些理论和解决方案； 蚂蚁金服在工程上是如何解决这个问题的； 针对蚂蚁金服业务场景的性能优化； 分布式事务产生背景 首先是分布式事务产生的背景。\n支付宝支付产品在 2003 年上线的时候，那时候的软件形态是单体应用，在一个应用内完成所有的业务逻辑操作。随着软件的工业化，场景越来越复杂，软件也越做越大，所有的业务在一个应用内去完成变的不可能，出现了软件模块化、服务化。\n在从单体应用升级到分布式架构过程中，很自然得需要进行业务服务拆分，将原来糅在一个系统中的业务进行梳理，拆分出能独立成体系的各个子系统，例如交易系统、支付系统、账务系统等，这个过程就是服务化。业务服务拆分之后，原来一个服务就能完成的业务操作现在需要跨多个服务进行了。\n另一个就是数据库拆分，分库分表。原来的单体数据库存不下的这么多信息，按服务维度拆库，比如把用户相关的存一起，形成用户库，订单放一块形成订单库，这个是拆库的过程；另一个是拆表，用户信息按照用户 ID 散列到不同的 DB 中，水平拆分，数据库的容量增大了。这样分库分表之后，写操作就会跨多个数据库了。\n分布式事务理论基础 我们可以看到，在分布式架构中，跨数据库、跨服务的问题是天然存在的。一个业务操作的完成，需要经过多个服务配合完成，这些服务操作的数据可能在一个机房中，也可能跨机房存在，如果中间某一个服务因为网络或机房硬件的问题发生了抖动，怎么保证这笔业务最终的状态是正确的，比如支付场景，怎么防止我转钱给你的过程中，我的钱扣了，而对方的账户并没有收到钱。这个就是业务最终一致性的问题，是分布式事务需要解决的问题。\n2PC 协议 针对这个问题，理论界也提出了解决方案，其中最为人熟知的就是二阶段协议了，简称2PC（Two Phase Commitment Protocol）两阶段提交协议。\n两阶段提交协议，就是把整个过程分成了两个阶段，这其中，它把参与整个过程的实体分成了两类角色，一个叫事务管理器或事务协调者，一个叫资源管理器，事务管理器我们也把它叫做事务发起方，资源管理器称为事务参与者。\n两个阶段，第一个阶段是资源准备阶段，比如我要转账，我要先查询下我的余额够不够，够的话我就把余额资源预留起来，然后告诉发起方“我准备好了”，第二个阶段，事务发起方根据各个参与者的反馈，决定事务的二阶段操作是提交还是取消。\nTCC 协议 另一个协议是 TCC 协议，各个参与者需要实现3个操作：Try、Confirm 和 Cancel，3个操作对应2个阶段，Try 方法是一阶段的资源检测和预留阶段，Confirm 和 Cancel 对应二阶段的提交和回滚。\n图中，事务开启的时候，由发起方去触发一阶段的方法，然后根据各个参与者的返回状态，决定二阶段是调 Confirm 还是 Cancel 方法。\n蚂蚁金服分布式事务介绍 2019年，蚂蚁金服跟阿里巴巴共同开源了分布式事务 Seata ，目前 Seata 已经有 TCC、AT、Saga 模式，Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。今天的分享也是 Seata 在蚂蚁金服内部的实践。\n分布式事务在蚂蚁金服的发展 基于上述的理论，接下来我们详细看下蚂蚁金服的分布式事务实现。\n经过多年的发展，蚂蚁金服内部针对不同的场景发展了几种不同的模式，最早的是 TCC 模式，也就是上面讲的 Try - confirm - Cancel，我们定义接口规范，业务自己实现这3个操作。这个模式提供了更多的灵活性，因为是业务自己实现的，用户可以介入两阶段提交过程，以达到特殊场景下的自定义优化及特殊功能的实现，这个模式能几乎满足任何我们想到的事务场景，比如自定义补偿型事务、自定义资源预留型事务、消息事务等场景。TCC 模式广泛用于蚂蚁金服内部各金融核心系统。\n这里要强调一点的是，TCC 模式与底层数据库事务实现无关，是一个抽象的基于 Service 层的概念，也就是说，在 TCC 的范围内，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，或者列式存储数据库 HBase，只要将对它们的操作包装成 TCC 的参与者，就可以接入到 TCC 事务范围内。\nTCC 模式的好处是灵活性，弊端是牺牲了易用性，接入难度比较大，所有参与者需要进行改造提供 Try - Confirm - Cancel 三个方法。为了解决 TCC 模式的易用性问题，蚂蚁金服分布式事务推出了框架管理事务模式（Framework - Managed Transactions，简称 FMT），也就是 Seata 中的 AT 模式。FMT 模式解决分布式事务的易用性问题，最大的特点是易于使用、快速接入、对业务代码无侵入。\nXA 模式是依赖于底层数据库实现的。\nSaga 模式是基于冲正模型实现的一个事务模式，现在的银行业金融机构普遍用的是冲正模型。\n这期我们重点讲 TCC 和 FMT，关于 Saga 模式，之前 Saga 模式也有专场直播分享过，感兴趣的可以看一下之前的直播回顾：《Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾》。\nTCC 模式在蚂蚁金服内的使用 首先看下 TCC 模式，主要包含一下几个模块：\n 参与者，它要实现全部的三个方法，Try、Confirm 和 Cancel； 发起方，主要是作为协调者的角色，编排各个参与者，比如调用参与者的一阶段方法，决策二阶段是执行提交还是回滚； 举个例子，比如在这个流程图中，存在一个发起方和两个参与者，两个参与者分别实现了 Try、Confirm 和 Cancel 接口，第一阶段被包含在发起方的本地事务模版中（图中黄颜色的两条虚线就是发起方本地事务的范围），也就是说发起方负责调用各个参与者的一阶段方法，发起方的本地事务结束后，开始执行二阶段操作，二阶段结束则整个分布式事务结束。\n二阶段是通过 Spring 提供的事务同步器实现的，发起方在发起一个分布式事务的时候，会注册一个事务同步器，当发起方本地事务结束的时候，会进入事务同步器的回调方法中。如果发起方的本地事务失败，则在回调中自动回滚所有参与者。如果发起方的本地事务成功，则二阶段自动提交所有参与者。二阶段结束后，删除所有事务记录。\n总结一下：\n 事务发起方是分布式事务的协调者； 分布式事务必须在本地事务模板中进行，发起方本地事务的最终状态（提交或回滚）决定整个分布式事务的最终状态； 发起方主职责：开启一个分布式事务 + 调用参 …","date":1584016200,"description":"分布式事务 TCC、FMT 模式在蚂蚁金服内部的实践分享。","dir":"blog/sofa-channel-12-retrospect/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1aaf09602548f4204f00c7b02260e180","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-12-retrospect/","publishdate":"2020-03-12T20:30:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-channel-12-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#12 直播分享整理，主题：蚂蚁金服分布式事务实践解析。 回顾视频以及 PPT 查看地址见文末","tags":["SOFAChannel","分布式事务"],"title":"蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-12-retrospect/","wordcount":6522},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@水木今山 提问：\n 请问下 SOFAJRaft 能否在日志复制到大多数后就响应客户端？我看 rhea 和 counter 的例子好像都是应用到状态机后才通过 closure 响应客户端。\n A：SOFAJRaft 没有限制，可以在自己的 statemachine 里不直接返回客户端再应用， rheakv 不能。举个例子， compareAndSet 操作，需要先读取再设置，最后返回 client，那么怎么能做到不应用状态机就返回呢，对吧？\n 有道理，但直接返回客户端的逻辑只能在 StateMachine 提供的 onApply 方法里实现吗，因为 onApply 的调用应该会滞后许久吧？\n A：onApply 里面实现就可以，onApply 就可以理解为和达成多数派之间没有延迟。\n 我在文档中有看到 TaskClosure 这么一个接口，在它的 onCommitted 方法里响应客户端会不会更高效？据我所知，raft 仅需写入日志就可保证强一致性，可以异步去 apply，所以在复制日志给大多数后就通过 onCommitted方法响应客户端（尽管还没有任何一个节点 apply 了该日志），这样效率好像会高一点，不知道我对这个接口理解有没有误。\n A：com.alipay.sofa.jraft.core.FSMCallerImpl#doCommitted\n可以看看这个方法，里面会在调用状态机之前调用 TaskClosure，想用 TaskClosure 也可以，不过两者没什么延迟区别。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@匿名 提问：\n MOSN 支持 Istio 的什么版本？什么时候可以在 Istio 中可用？\n A：目前 MOSN 可基于 Istio 1.1.4 跑通 bookinfo example，由于最新版本的 Istio 对 XDS 协议进行了升级以及部分能力增强，MOSN 当前正在适配中，预计 2020 年 10 月份会完整支持高版本 Istio 的 HTTP 系能力；同时我们一直在关注 UDPA 的发展，也在尝试参与到标准的制定中。控制平面方面，我们和社区一直保持紧密沟通与合作，大力发展控制平面，MOSN 也将与控制平面共同前进。\nMOSN：https://github.com/mosn/mosn\n3、@孙俊 提问：\n 请问下，全局事务开启后，全局事务锁未释放时，此时又来个操作同一个数据的本地请求，这个请求没有开启全局事务，是可以修改这个数据的呀。\n A：全局事务的分支事务结束后，不在全局事务的本地数据请求可修改数据。\n 那这样，全局事务的其他分支出现异常，分支事务回滚，从undo里读，发现数据已经被修改了，就得人工处理了？\n A：是，从业务设计上来说如果使用 AT 模式要把数据修改都交给 AT 来管理来避免这类问题。 Seata：https://github.com/seata/seata\n剖析 SOFARegistry 系列 服务注册中心数据一致性方案分析 | SOFARegistry 解析 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 1、发布 SOFARegistry v5.4.0 版本，主要变更如下：\n SessionServer 与 DataServer 通讯性能优化； jraft 从 1.2.5 更新到 1.2.7.beta1； 解决 MethodHandle 在某些 jdk 版本存在内存泄露的 bug； Bug Fix； 详细发布报告：https://github.com/sofastack/sofa-registry/releases/tag/v5.4.0\n2、发布 SOFAArk v1.1.1 版本，主要变更如下：\n 优化biz 卸载，清理临时文件； 支持 biz 打包 指定 bizName -D 参数； 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.1.1\n社区直播预告 SOFAChannel#12 线上直播将邀请蚂蚁金服分布式事务核心开发仁空分享介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1583481600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200306/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"762ff425feef89f406716a6c0c4fff9d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200306/","publishdate":"2020-03-06T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200306/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARegistry 发版以及源码系列合辑、SOFAArk 发版、3/12直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200306/","wordcount":1922},{"author":"SOFA 团队","categories":"云原生","content":" 2月19日-2月26日，蚂蚁金服开展了“共战‘疫情’，技术破局”数字课堂线上直播，邀请资深专家从“云原生”、“研发效能”、“数据库”三方面分享蚂蚁金服的实践经验并在线答疑，解析 PaaS 在金融场景的落地建设实践，解析支付宝移动端弹性动态架构，分享 OceanBase 2.2版本的特性和实践。\n 本文根据 蚂蚁金服 SOFAStack 产品专家俞仁杰，在蚂蚁金服数字课堂直播间分享的云原生应用 PaaS 平台的建设实践内容整理，以下为演讲整理全文：\n大家好，欢迎来到蚂蚁金服数字课堂直播间。今年 2 月，SOFAStack 金融分布式架构产品已经在阿里云上完成了商业化发布，为了让更多朋友了解到我们的产品的能力、定位以及背后的设计思路，后续我们会有一系列的直播分享。我们今天想分享给大家的话题叫《云原生应用 PaaS 平台的建设实践》，主要会围绕 PaaS 产品能力在一些需要稳妥创新的金融场景下的落地思路，并且能够更好地与云原生架构做好链接。\n金融场景云原生落地面临挑战 云原生是业务快速变化背景下的必然技术趋势 回顾 IT 的发展史，云计算分类为 IaaS PaaS 和 SaaS 已经有十几年了。而事实上，整个云计算行业的发展，我们能够明显看到企业在落地云计算战略的时候经历的三个阶段，Cloud-Based, Cloud-Ready, Cloud-Native。这三个阶段其实是因为业务的变化越来越敏捷，要求企业关注重心上移，把更多的精力和人才投入到业务逻辑的建设上，而把下层自已并不擅长并且越来越复杂的基础设施、中间件逐渐交给云计算厂商去实现，专业的人做专业的事。\n这本质是社会分工的进一步细化，也符合人类社会发展的规律。在云原生时代，业界所提出的容器技术，Service Mesh 技术，Serverless 技术都是希望让业务研发与基础技术更加的解耦，让业务创新和基础技术创新都更容易的发生。\n容器技术带来的是一种应用交付模式的变革 云原生就是业务快速变化背景下的必然技术趋势。而这个趋势背后的实质载体，就是我们所说的云原生、Kubernetes 以及以 Docker 为代表的容器技术，这些所带来的，本质是一种应用交付模式的变革。而为了真正能够使业界、社区所倡导的新兴应用交付模式落地到实际的企业环境，我们需要一个以应用为中心的平台来进行承载，贯穿应用运维的各项生命周期。\n围绕“云原生”这个关键词，其实在社区和业界已经有了非常多的交流和资料，围绕Docker/K8S 的最佳实践、DevOps CICD、容器网络存储设计、日志监控对接优化等等等等，而我们今天的分享，主要想表达的是我们围绕在 K8S 之上塑造一个 PaaS 平台的产品价值主张。Kubernetes 是一个非常好的编排和调度框架，它核心的贡献是让应用的编排和资源的调度更加的标准化，同时提供了一个高度可扩展的架构，方便上层进行各种控制器和调度器的定制。但是，它并不是一个 PaaS。PaaS 底层可以基于 Kubernetes 去实现，但是在上层要补足非常多的能力才能真正把 Kubernetes 用于生产环境，特别是金融行业的生产环境。\n金融场景需要“稳妥创新” 生产环境落地云原生需要着重考虑哪些挑战？\n我们之前做过一些调研和客户访谈。就现在 2020 年来说，绝大多数金融机构都展现出了对 Kubernetes、容器等技术的极大兴趣，有不少机构也已经在一些非关键的业务、或开发测试环境搭建了开源或商业版的集群。驱动力很简单，金融机构非常希望这一整套新的交付模式帮助到业务飞速迭代。然而对比落差非常明显的是，真正敢于在核心生产环境落地云原生架构的，又少之又少。因为金融业务创新的前提，是要保障稳妥。\n我们团队在服务蚂蚁内部业务、外部金融机构的过程中，总结了以上这几个方面，事实上这六大方面也是我们内部 SRE 不断挑战的几点。我们在今天以及未来的分享中，会逐步总结深化应对这些挑战的产品思路。\nK8S 体系下的应用变更与发布管控 我们今天分享的一个核心内容，就是我们如何在产品层面做应用变更的风险保障的。并围绕此话题向大家介绍变更“三板斧”的背景、K8S 原生部署能力、我们产品围绕变更需求做的扩展并向大家介绍我们在开源方面的规划。\n需求背景：变更“三板斧” 所谓“三板斧”就是可灰度、可监控、可应急。这是蚂蚁内部运维的一条红线准则，所有的变更，都必须要遵从这个规则，即使再细小的变更，再严密的测试，也不能忽略这条规则。为了满足这个需求，我们在 PaaS 产品层设计了各种各样的精细化发布策略，比如分组发布、beta 发布，灰度发布，蓝绿发布等。这些发布策略跟我们在做传统运维时用的手段是非常相似的，但很多使用容器的用户认为在 K8S 里实现会非常的困难。\n有些时候，由于对业务连续性的极高要求，也很难接受原生 K8S 模型标准化模式，比如原生 Deployment 做灰度或者金丝雀发布时，默认情况下在 Pod 变更和流量治理层面的管控还稍显不足，无法完全做到无损发布或按需过程管控。因此，我们在 PaaS 产品层面做了定制，在 Kubernetes 层面做了自定义资源的扩展，目的是能够在云原生的场景下，依然对整个发布过程实现精细化管控，使得大规模集群发布、灰度、回滚时更加优雅，符合技术风险三板斧原则。 Kubernetes 原生发布能力 我们先来回顾一下 K8S 的原生 Deployment 对象，及其背后的 ReplicaSet，其实已经是在最近好几个大版本中已经逐渐的稳定了。 简单的来说，最常见的 K8S 发布场景，我们会通过 Deployment 的对象，声明出我希望的发布模式以及 Pod Spec 定义。在运行时，会有 ReplicaSet 对象来管理 Pod 数量的预期，默认情况下会提供滚动发布或重建发布能力。\nimage.png\n这幅图的下半部分，是围绕 Deployment 作滚动发布时的示意图，这里不再做过多的展开，它的本质根据用户根据我们的运维需求设定好一定的步长，创建新的 Pod，销毁旧的 Pod，因此能做到整个应用版本的变更和发布过程中，都能有对应的容器对外提供服务。 对大部分场景来说，它是够用的，而且整个过程也是非常好的理解，事实上在 K8S 体系，大家除了 Pod/Node，看的最多的就是 Deployment了。\nCAFEDeployment：感知底层拓扑和领域模型 回顾完 Deployment，我们可以再给大家看一下我们根据实际需求作的 CRD 扩展，CAFEDeployment。CAFE 是我们 SOFAStack PaaS 产品线的名称，本文的最后会作一些介绍。\nCAFEDeployment 有一个很重要的能力，就是能够感知到底层拓扑，这个拓扑是什么意思呢？能够知道我想把我的 Pod 发布到哪里，哪边的 Node，不只是基于亲和性的规则作绑定，而是真正能把高可用、容灾、以及部署策略等场景息息相关的信息，带到整个围绕发布的领域模型中。对此，我们提出了一个叫部署单元的领域模型，他是一个逻辑概念，在 yaml 中简单的叫做 Cell。在实际使用中，Cell 的背后，可以是不同的 AZ 不同的物理机房，不同的机架，一切都是围绕着不同级别的高可 …","date":1583395200,"description":"云原生应用 PaaS 平台的建设实践","dir":"blog/distributed-architecture-and-cloud-native/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6c1ff3975ace44ac5189b1f845a43fcb","permalink":"https://sofastack.github.io/sofastack.tech/blog/distributed-architecture-and-cloud-native/","publishdate":"2020-03-05T16:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/distributed-architecture-and-cloud-native/","summary":"2月19日-2月26日，蚂蚁金服开展了“共战‘疫情’，技术破局”数字课堂线上直播，邀请资深专家从“云原生”、“研发效能”、“数据库”三方面分","tags":["云原生"],"title":"技术破局：如何实现分布式架构与云原生？| 含 ppt 下载","type":"blog","url":"/sofastack.tech/blog/distributed-architecture-and-cloud-native/","wordcount":5553},{"author":"明不二","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第七篇，本篇作者明不二。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 在前面的文章已经做过介绍，与其他注册中心相比，SOFARegistry 主要特点在于支持海量数据、支持海量客户端、秒级的服务上下线通知以及高可用特性。本文将从如下几个方面来讲述 SOFARegistry 的一致性方案：\n MetaServer 数据一致性 为支持高可用特性，对于 MetaServer 来说，存储了 SOFARegistry 的元数据，为了保障 MetaServer 集群的一致性，其采用了 Raft 协议来进行选举和复制。\n SessionServer 数据一致性 为支持海量客户端的连接，SOFARegistry 在客户端与 DataServer 之间添加了一个 SessionServer 层，客户端与 SessionServer 连接，避免了客户端与 DataServer 之间存在大量连接所导致的连接数过多不可控的问题。客户端通过 SessionServer 与 DataServer 连接的时候，Publisher 数据同时会缓存在 SessionServer 中，此时就需要解决 DataServer 与 SessionServer 之间数据一致性的问题。\n DataServer 数据一致性 为支持海量数据，SOFARegistry 采用了一致性 Hash 来分片存储 Publisher 数据，避免了单个服务器存储全量数据时产生的容量瓶颈问题。而在这个模型中，每个数据分片拥有多个副本，当存储注册数的 DataServer 进行扩容、缩容时，MetaServer 会把这个变更通知到 DataServer 和 SessionServer，数据分片会在集群内部进行数据迁移与同步，此时就出现了 DataServer 内部数据的一致性问题。\nMetaServer 数据一致性 MetaServer 在 SOFARegistry 中，承担着集群元数据管理的角色，用来维护集群成员列表，可以认为是 SOFARegistry 注册中心的注册中心。当 SessionServer 和 DataServer 需要知道集群列表，并且需要扩缩容时，MetaServer 将会提供相应的数据。\n图1 MetaServer 内部结构 图源自 《蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析》\n因为 SOFARegistry 集群节点列表数据并不是很多，因此不需要使用数据分片的方式在 MetaServer 中存储。如图 1 所示，集群节点列表存储在 Repository 中，上面通过 Raft 强一致性协议对外提供节点注册、续约、列表查询等 Bolt 请求，从而保障集群获得的数据是强一致性的。\nRaft 协议 关于 Raft 协议算法，具体可以参考 The Raft Consensus Algorithm 中的解释。在 SOFA 体系中，对于 Raft 协议有 SOFAJRaft 实现。下面对 Raft 协议算法的原理进行简要介绍。\nRaft 协议由三个部分组成，领导人选举（Leader Election）、日志复制（Log Replication）、安全性（Safety）。\n 领导人选举 通过一定的算法选举出领导人，用于接受客户端请求，并且把指令追加到日志中。\n图2 Raft 状态机状态转换图 图源自Understanding the Raft consensus algorithm: an academic article summary\n 日志复制 领导人接受到客户端请求之后，把操作追加到日志中，同时与其他追随者同步消息，最终 Commit 日志，并且把结果返回给客户端。\n图3 复制状态机 图源自 Raft一致性算法笔记\n 安全性 安全性保证了数据的一致性。\n基于 Raft 协议的数据一致性保障 图4 SOFARegistry 中的 Raft 存储过程 图源自 《蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析》\n如图 4 所示，SOFARegistry 中的 Raft 协议数据存储经历了如上的一些流程。客户端发起 Raft 协议调用，进行数据注册、续约、查询等操作时，会通过动态代理实现 ProxyHandler 类进行代理，通过 RaftClient 把数据发送给 RaftServer ，并且通过内部的状态机 Statemachine ，最终实现数据的操作，从而保证了 MetaServer 内部的数据一致性。\nSessionServer 数据一致性 SessionServer 在 SOFARegistry 中，承担着会话管理及连接的功能。同时，Subscriber 需要通过 SessionServer 来订阅 DataServer 的服务数据，Publisher 需要通过 SessionServer 来把服务数据发布到 DataServer 中。\n在这个场景下，SessionServer 作为中间代理层，缓存从 DataServer 中获取的数据成了必然。DataServer 的数据需要通过 SessionServer 推送到 Subscriber 中，触发 SessionServer 推送的场景有两个：一个是 Publisher 到 DataServer 的数据发生变化；另外一个是 Subscriber 有了新增。\n而在实际的场景中，Subscriber 新增的情况更多，在这种场景下，直接把 SessionServer 缓存的数据推送到 Subscriber 中即可，能够大大减轻 SessionServer 从 DataServer 获取数据对 DataServer 的压力。因此，这也进一步确认了在 SessionServer 缓存数据的必要性。\n图5 两种场景的数据推送对比图\nSessionServer 与 DataServer 数据对比机制 当服务 Publisher 上下线或者断连时，相应的数据会通过 SessionServer 注册到 DataServer 中。此时，DataServer 的数据与 SessionServer 会出现短暂的不一致性。为了保障这个数据的一致性，DataServer 与 SessionServer 之间通过 推 和 拉 两种方式实 …","date":1583224200,"description":" 本文为《剖析 | SOFARegistry 框架》第七篇，作者明不二","dir":"blog/sofa-registry-data-consistency/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"356cd2beadad494a22e2d480948fce8d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-data-consistency/","publishdate":"2020-03-03T16:30:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-data-consistency/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心数据一致性方案分析 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-data-consistency/","wordcount":4336},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:BootLab/\u0026amp;gt;是《剖析 | SOFABoot 框架》系列，会逐步详细介绍 SOFABoot 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFABoot SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\nSOFABoot :https://github.com/sofastack/sofa-boot\n| SOFA:Boot Lab 认领列表：\n 【已认领】《SOFABoot 总览》 【已认领】《SOFABoot runtime 机制解析》 【已认领】《SOFABoot HealthCheck 机制解析》 【已认领】《SOFABoot 日志隔离解析》 【已认领】《SOFABoot 上下文隔离机制解析》 领取方式：关注 「金融级分布式架构」 回复可领取的文章标题，我们将会主动联系你，确认资质后，即可加入 SOFA:BootLab/，It\u0026amp;rsquo;s your show time！\n 如果有同学对以上某个主题特别感兴趣的，可以留言讨论，我们会适当根据大家的反馈调整文章的顺序，谢谢大家关注 SOFAStack ，关注 SOFABoot，我们会一直与大家一起成长的。\n除了源码解析，也欢迎提交 issue 和 PR： SOFABoot：https://github.com/sofastack/sofa-boot\n欢迎领取，参与共建~\n","date":1583208000,"description":"","dir":"activities/sofa-boot-lab/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ee08908ed6148190ca7ebcc0cdc5a3fc","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-boot-lab/","publishdate":"2020-03-03T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-boot-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:BootLab/\u0026gt;是《剖析 | SOFABoot 框架》系列，会逐步详细","tags":["SOFALab","SOFABoot","剖析 | SOFABoot 框架"],"title":"\u003cSOFA:BootLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-boot-lab/","wordcount":542},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@朱楠 提问：\n SpringBoot 集成 Seata Saga 模式后启动报了这个错，有谁知道是什么情况吗？不知道问题出在哪，我就参照Saga 的 demo 来配置的。 A：这个事务异常了，然后 server 端出发了事务恢复，但是这条事务在客户端已经没有了。\n @Reference 这个注解没有 id 或者 name 的属性，试了几次还是不行，实在不行我就用配置文件的方式主入 Dubbo 服务了。 A：其实这也合理，因为 @Reference 是作用在一个类的 field 或 method 上面的，而状态机引擎它不是一个 field 或 method，所以状态机引擎不应该用访问这个类的 reference，而是应该访问一个 spring 上下文作用域的 reference 。我看了一下 Dubbo 的源码 @Reference 这种它并不会注册成为一个 bean，只是生成一个代理然后注入到这个引用它的属性里。所以状态机默认是取 bean 的形式拿不到 bean，你用 xml 的方式引用一个服务。状态机的编排本来就不是用 Java 代码上编排的，而 @Reference 是用于编程方式使用的。 Seata：https://github.com/seata/seata\n2、@魏敏 提问：\n 请问一下，关于 tomcat 的 ajp 漏洞，使用的 SOFABoot 是否受影响呢？https://www.cnvd.org.cn/webinfo/show/5415\n A：针对此次 Tomcat 的 AJP 协议漏洞，SOFABoot 内置的 Tomcat 默认是不会打开 AJP Connector 的，也就是说默认情况下所有版本的 SOFABoot 都是安全的。但是如果你自行打开了 AJP Connector，或者认为风险较大，可以通过覆盖 SOFABoot 管控的 Tomcat 版本进行升级，在主 pom 中的 properties section 指定 Tomcat 版本：\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;!-- other properties goes here --\u0026amp;gt; \u0026amp;lt;tomcat.version\u0026amp;gt;9.0.31\u0026amp;lt;/tomcat.version\u0026amp;gt; \u0026amp;lt;!-- Tomcat 升级规则如下： - 9.x 版本升级至 9.0.31 及以上 - 8.x 版本升级至 8.5.51 及以上 - 7.x 版本升级至 7.0.100 及以上 --\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; SOFABoot：https://github.com/sofastack/sofa-boot\n3、@jinn 提问：\n MOSN 与 Envoy 不同点是什么？优势在哪里？\n A：简单描述一下：\n 语言栈的不同：MOSN 使用 Go 语言技能栈对于使用 Java 语言的公司和个人心智成本更低。 核心能力的差异化： MOSN 支持多协议框架，用户可以比较容易的接入私有协议，具有统一的路由框架； 多进程的插件机制，可以通过插件框架很方便的扩展独立 MOSN 进程的插件，做一些其他管理，旁路等的功能模块扩展； 具备中国密码合规的传输层国密算法支持； MOSN：https://github.com/mosn/mosn\nSOFAChannel 线上直播集锦 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.10.0 版本，主要变更如下：\n 分离部分 MOSN 基础库代码到 mosn.io/pkg； 分离部分 MOSN 接口定义到 mosn.io/api； 支持多进程插件模式； 部分代码实现细节优化； Bug Fix； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.10.0\n社区直播预告 SOFAChannel#12 线上直播将邀请蚂蚁金服分布式事务核心开发仁空分享介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1582873200,"description":"【02/24-02/28】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200228/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"825d23ac19f5c5ae4cfaca517a9a87fd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200228/","publishdate":"2020-02-28T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200228/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布、直播系列整理、0312直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200228/","wordcount":1935},{"author":"SOFA 团队","categories":"SOFAArk","content":" SOFA:Channel/，有趣实用的分布式架构频道。\n本文根据 SOFAChannel#11 直播分享整理，主题：从一个例子开始体验轻量级类隔离容器 SOFAArk。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群：23372465，不错过每场直播。\n 大家好，我是玄北，SOFAArk 开源负责人，今天跟大家分享的主题是《从一个例子开始体验轻量级类隔离容器 SOFAArk》，会跟大家一起解读 SOFAArk ，也会讲解一个 Demo 案例，希望大家可以跟我一起实际操作，体验 SOFAArk 具体操作以及功能实现。\nSOFAArk：https://github.com/sofastack/sofa-ark\n今天的分享将从一下面三个方面展开：\n 初识 SOFAArk； 组件运行时； 动手实践； 今天的重点是最后一个部分的动手实践，前面两部分会跟大家简单介绍一下 SOFAArk 的基础概念，希望在最后一个实践部分，大家可以跟着我一起通过 Demo 实际操作体验 SOFAArk，也可以在实践过程中帮助大家更好得了解前面介绍到的概念。\n一、初识 SOFAArk 现在我们就开始了解 SOFAArk，在实践之前，我们先来了解一下什么是 SOFAArk。SOFAArk 是蚂蚁金服开源的一款基于 Java 实现的轻量级类隔离容器，欢迎大家关注并 Star SOFAArk。\nSOFAArk：https://github.com/sofastack/sofa-ark\n在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案。产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin）； 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz)； 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制； 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz； SOFAArk 可以帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\nSOFAArk 中有三个最主要的概念，分别是 Ark 包、Ark Biz 包、Ark Plugin 包：\nArk 包：类似 Spring Boot 的打包产物，是一个 Fat Jar，即应用交付终态，一个 Ark 包，可以通过 Java-jar 的方式把它运行起来。\nArk Biz 包: 简称 Biz，是组件的交付终态，大家通过名字也可以理解，里面主要封装了一些业务逻辑。\nArk Plugin 包: 简称 Plugin，提供把非业务基础组件下沉的能力，比如 RPC、消息等。\n接下来按照上述三个的顺序，我们来看一下这三个包里主要是什么。\nArk 包目录结构 下图是 Ark 包的目录结构，Ark 包下有 Biz 目录，Container 目录，Plugin 目录，Biz 目录中就是一个一个的 Ark Biz，Plugin 目录保存了所有的 Ark Plugin，Container 是 Ark 容器，Ark 容器会负责启动 Ark Plugin 及 Ark Biz。\nArk Biz 包目录格式 介绍完 Ark 包的目录格式，接下来介绍 Ark Biz 包的格式：\n在 Ark Biz 包的目录格式里同样有几个比较关键的目录格式，分别是：\n application.properties：标准 Spring Boot/SOFABoot 工程配置文件； lib 目录：应用依赖目录； META-INF/MANIFEST：Biz 配置文件。 Ark Plugin 包目录结构 接下来跟大家介绍 Ark Plugin 包，Ark Plugin 包的目录结构与 Ark Biz 包的目录结构类似，但是 Ark Plugin 包的 META-INF/MANIFEST.MF 文件会比 Ark Biz 包复杂一点，Ark Plugin 支持在 META-INF/MANIFEST.MF 文件中定义 Import package、Export package、Import classes 以及 Export classes 等属性，这些属性支持 Plugin ClassLoader 在加载类或者资源文件时可以委托给其他 Plugin 加载。\n上文介绍了 Ark 包、Ark Biz 包、Ark Plugin 包的目录结构，接下来我们介绍下 Ark 包运行时的整个运行时结构。通过下面这张图我们可以看到，在整个运行时，Ark 包分为三层，底层是 Ark Container，中间层是 Ark Plugin，上层是 Ark Biz。Ark Container 负责启动所有 Ark Plugin 及 Ark Biz，Ark Plugin 支持类导入导出能力，所以 Ark Plugin 之间有双向箭头相互委托。为了简化 Ark Biz 的使用，Ark Biz 不支持导入导出类，Ark Biz默认会导入所有 Ark Plugin 的类。\nSOFAArk 的不同 Plugin 相互委托类加载的能力可以帮助我们解决一个文件场景，那就是依赖冲突：\n以上图的场景为例，有一个 Project，依赖了 Dependency A 以及 Dependency B，这两个依赖依赖了不同版本的 Hessian，Dependency A 依赖了 Hessian 3，Dependency B 依赖了 Hessian 4，Hessian 3 与 Hessian 4 是不兼容的，会出现冲突，那么要如何解决这个问题呢？\nSOFAArk 就给出了一个解决方案。如果我们的 Dependency A 跟 Dependency B 的 Hessian 依赖有冲突的话，我们可以把 Dependency A 作为一个整体打包成一个 Ark Plugin， Dependency B 作为一个整体打包成一个 Ark Plugin，每个 Ark plugin 都是一个单独的 Classloader，这样 Dependency A 使用的 Hessian 3 和 Dependency B 使用的 Hessian 4 将不再冲突。\n解决依赖冲突是 SOFAArk 的一个主要使用场景，但是今天我们不详细介绍这个场景，今天主要介绍 SOFAArk 的另一个能力，即组件运行时能力。\n二、组件运行时 组件运行时提供了一种能力，它能够在不重启应用的前提下，通过动态安装、卸载、切换 Biz 模块，实现修改应用运行方式的目的。下图展示了组件运行时的运行时结构，整个运行时结构与上文的 Ark 包运行时结 …","date":1582700400,"description":"本文根据 SOFAChannel#11 直播分享整理。","dir":"blog/sofa-channel-11-retrospect/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a3216377eb47b27325f279f124c2bfd8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-11-retrospect/","publishdate":"2020-02-26T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-channel-11-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#11 直播分享整理，主题：从一个例子开始体验轻量级类隔离容器 SOFAArk。 回顾视","tags":["SOFAArk","SOFAChannel"],"title":"从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-11-retrospect/","wordcount":4342},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@朱楠 提问：\n 请教下，我看文档上有说json可以热部署，有demo吗，没怎么看明白如何热部署 A：就是用这个回答里的这个方法 registerByResource，Java 代码的热部署可以用 SOFAArk，stateMachineEngine 是一个 bean，可以在代码里注入这个 bean，然后你可以实现一个 web 页面，可以上传 json 文件和 jar 包，调用图片中的方法注册状态机，用 SOFAArk 注册 jar 包。\n 我在看 registryByResources 这个方法的源码，注册状态机是不是就不需要修改本地的 json 文件了？\n A：注册了 json，如果数据库里有名称相同的，它会对比字节码，如果不一样，则创建新版本，一样则不注册，新启动的状态机实例用新版本，已启动的状态机实例用老的。\n 懂了，你这里说的上传 jar 包是什么意思？\n A：因为状态机里定义了要调用服务，这个服务可能是目前在系统里没有引用，所以需要上传 jar。\n2、@刘川江 提问：\n Seata Saga 模式服务（ServiceTask）之间如何在运行时传递业务参数？如将服务A运行后的生成的业务对象传递到后续的服务中进行处理。\n A：用 Output 和 Input 属性： Input: 调用服务的输入参数列表, 是一个数组, 对应于服务方法的参数列表, $.表示使用表达式从状态机上下文中取参数，表达使用的 SpringEL, 如果是常量直接写值即可； Ouput: 将服务返回的参数赋值到状态机上下文中, 是一个 map 结构，key 为放入到状态机上文时的 key（状态机上下文也是一个 map），value 中$.是表示 SpringEL 表达式，表示从服务的返回参数中取值，#root 表示服务的整个返回参数。\n 是否支持根据业务参数中的某些值作为条件判断状态机中的服务（ServiceTask）是否执行？\n A: 支持的，可以用 Status 属性来判断 Service 是否执行成功。 Status: 服务执行状态映射，框架定义了三个状态，SU 成功、FA 失败、UN 未知, 我们需要把服务执行的状态映射成这三个状态，帮助框架判断整个事务的一致性，是一个 map 结构，key 是条件表达式，一般是取服务的返回值或抛出的异常进行判断，默认是 SpringEL 表达式判断服务返回参数，带 $Exception{ 开头表示判断异常类型。value 是当这个条件表达式成立时则将服务执行状态映射成这个值。\n 是否支持状态机中的部分服务开启事务。如状态机配置了服务流程A-\u0026amp;gt;B-\u0026amp;gt;C，只在服务B和C上开启分布式事务。\n A：可以，比如 A 是一个查询类的服务，可以将 A 设置成 IsForUpdate=false，如果这个服务不想记录执行日志，可以设置这个服务为 IsPersist=false。\nSeata：https://github.com/seata/seata\n3、@SUNBIAO 提问：\n 请问 SOFA 消费者端可以同时配置多个注册中心嘛？例如一个 web 控制器接入端当作消费者，配置连接多个注册中心，订阅不同注册中心上的生产者服务，但是这个消费者端不同的具体消费者调用不同注册中心的服务，前提是注册中心不能合成一个，现实有多个不同的注册中心。\n A：可以的，可以看这个类 com.alipay.sofa.rpc.config.AbstractInterfaceConfig#registry， 是个 list。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n4、@七美 提问：\n SOFATracer 目前落盘的摘要 log 是固定格式的，能否直接以 zipkin 的 json 数据格式落盘？如果可以如何操作？\n A：使用自定义 reporter ： https://www.sofastack.tech/projects/sofa-tracer/reporter-custom/ + ZipkinV2SpanAdapter 来实现。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n每周读者问答提炼 蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 SOFA 项目进展 本周发布详情如下：\n1、发布 Seata v1.1.0 版本，主要变更如下：\n 支持 postgreSQL； 支持自定义 Saga 恢复策略超时时间； 支持 Saga 模式跳过成功分支事务的 report； 支持httpClient 自动集成； 详情发布报告：https://seata.io/zh-cn/blog/download.html\n2、发布 SOFARPC v5.6.4 版本，主要变更如下：\n 试验性支持 RPC 可能的多版本发布； 升级 Dubbo 依赖版本到2.6.7； 优化 gRPC 支持代码； 升级 Netty 版本4.1.44.final，解决安全问题； 修复 Tracer 采样兼容问题； 修复注册中心虚拟端口的问题； 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.4\n3、发布 SOFABoot v3.3.0 版本，主要变更如下：\n 健康检查页面显示组件的具体绑定类型； RPC XML 超时配置支持字符串变量； 修复无法使用 zk 以外注册中心的 bug； 修复控制台大量输出的 bug； 升级 Spring Boot 依赖版本至 2.1.11.RELEASE； 升级 RPC 版本至 5.6.4； 升级 sofa-common-tools 版本至 1.0.21； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.3.0\n4、发布 sofa-common-tools v1.0.21 版本，主要变更如下：\n 修复类隔离情况下 classloader 加载问题； 详 …","date":1582268400,"description":"【02/17-02/23】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200221/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b82b9b4c82bc3905d736962bd157238c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200221/","publishdate":"2020-02-21T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200221/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 3/12直播预告、SOFARPC、SOFABoot 组件发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200221/","wordcount":2625},{"author":"盲僧","categories":"SOFABoot","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFABoot 框架》第二篇，本篇作者盲僧，来自遨游酒店信息技术。《剖析 | SOFABoot 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:BootLab/]()，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFABoot 是蚂蚁金服开源的基于 SpringBoot 的研发框架，提供了诸如 Readiness Check、类隔离、日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\n本文将从 Java 的日志体系谈起，对 JCL、SLF4J 两个经典的日志框架做一个阐述，引出 SOFABoot 开源的日志隔离框架 sofa-common-tools ，并且有实战 Demo，能够帮助我们快速上手和了解这款框架的使用和作用，最后从源码角度对其进行分析，不仅知其然，还要知其所以然。\nSOFABoot ：https://github.com/sofastack/sofa-boot\nsofa-common-tools ：https://github.com/sofastack/sofa-common-tools\nJava 日志问题 业务开发对日志的选择 众所周知，Java 的日志体系非常复杂，有 Log4j、Log4j2、Logback、JUL 等实现，这么多的日志实现让开发人员在选择上不得不犯晕，因为每个日志实现都对外提供了不同的 API，而且还要担心与项目中现有的第三方框架依赖的日志实现产生冲突问题，甚至还要去维护第三方框架带来的日志依赖。在这些问题的基础上，Java 日志框架应运而生，典型的有 JCL 和 SLF4J。\nJCL JCL 即 Apache Commons Logging，它的原理是提供了一套接口，用户使用了它的接口进行编程，具体实现交由它的 LogFactoryImpl 去动态查找， 但是它并不能绑定所有的日志实现，因为查找绑定的日志实现是放在 classesToDiscover 数组里写死的，导致扩展起来比较麻烦，当前最新版本是 1.2 版本，还不支持绑定 Log4j2 和 Logback。\nSLF4J 于是乎，大名鼎鼎的 SLF4J 出现了，它的存在就是为了替换 JCL，所以肯定提供了比 JCL 更强大的功能。同样是面向接口编程的设计，但是 SLF4J 充分考虑到了后期的扩展问题：一旦市面上有新的日志实现，那么只需要提供新的绑定包即可，相对于 JCL 的动态绑定，SLF4J 实际上是静态绑定，因为应用程序具体要选用哪种日志组件是由开发人员使用哪个绑定包决定的。绑定原理请看下图：\n除此之外，SLF4J 还提供了桥接包，它的意思是指可以把使用某个具体 Log 组件的 API 重定向到 SLF4J 的 API 里（前提需要排除具体实现包，然后引入桥接包），然后 SLF4J 会根据具体的绑定包输出内容，从而达到多种日志实现统一输出的目的。绑定原理请看下图：\n中间件对日志的选择 上面解决了业务开发人员的问题，那么对于从事中间件的开发者来说呢？日志依旧是一个痛点。参考一些中间件项目，如 zookeeper 使用的是 log4j ，hibernate-validator 使用的是 jboss-logging，当业务开发人员去集成这些第三方组件时，就会感到头疼，因为这些组件的日志实现很有可能会和当前业务自身的日志依赖产生冲突。常用的解决方法就是排除某一种日志实现依赖，然后修改 appender 和 logger 达到日志隔离。但这并不是一个一劳永逸的方法，因为每次引入新的 jar 包，你都需要考虑是否有日志冲突。\n那么市面上是否有成熟的框架来解决这个问题呢？当然是有的，蚂蚁金服开源的 SOFABoot 就提供了这样的功能，底层主要是通过 sofa-common-tools 实现的。那么 sofa-common-tools 又是个啥呢？借用官网的描述： sofa-common-tools 是 SOFAStack 中间件依赖的一个通用工具包，通过自动感知应用的日志实现，提供中间件与应用隔离的日志空间打印能力。\n本篇将通过一个案例 demo 先来直观的体验下 sofa-common-tools 所能解决的问题，然后再在此基础上，通过源码解析了解其内部的具体实现原理，以帮助大家更好的认识和了解 sofa-common-tools 这个“小而美”的日志工具包。\n日志隔离实战 完整项目已经上传到 https://github.com/masteryourself/study-sofa.git ，工程是 study-sofa-common-tools\n 有这样一个场景：公司的中间件团队做了一款 middleware-apm 监控系统，并且通过以输出日志的方式向监控系统提供基础数据。由于公司并没有制定统一的日志规范，各个业务方所使用的日志也是千差万别；如：如订单系统使用的是 log4j，账务系统用的 Logback，用户中心用的是 Log4j2； 如果期望 apm 提供的日志输出和业务的不冲突，可以独立的并且完整的兼容业务日志的不同实现，此时便可以使用 SOFABoot 提供的日志隔离框架；其可以帮助我们解决日志实现冲突、日志文件隔离以及动态调试日志级别等功能。下面就先来看下 apm 是如何使用 sofa-commons-tools 来实现的。\nmiddleware-apm 项目 新建 middleware-apm 工程，然后执行 mvn clean install 命令，安装到本地仓库。具体代码可以参考 middleware-apm ，下面对一些核心代码进行简单的说明和分析。代码结构如下：\n日志资源文件配置 这里主要是在 pers.masteryourself.study.sofa.apm.log 目录下创建 log4j、log4j2、logback 的配置文件，详情请参考 github 链接。\n核心日志工厂类-ApmLoggerFactory ApmLoggerFactory 主要是对外提供获取 Logger 实例的 API 方法，其作用类似于 slf4j 中的 LoggerFactory 类；对于想使用 SOFABoot 日志特性的类，只要使用它调用 getLogger 方法获得的 Logger 实例即可。\nLoggerFactory 和 ApmLoggerFactory 的最本质区别在于 ApmLoggerFactory 引入了 LOG_SPACE 的概念。\npublic class ApmLoggerFactory { // 日志空间 private static final String APM_LOG_SPACE = \u0026amp;quot;pers.masteryourself.study.sofa.apm\u0026amp;quot;; static { if …","date":1582016400,"description":"本文将从 Java 的日志体系谈起，对 JCL、SLF4J 两个经典的日志框架做一个阐述，引出 SOFABoot 开源的日志隔离框架 sofa-common-tools，并且有实战 Demo，能够帮助我们快速上手和了解这款框架的使用和作用，最后从源码角度对其进行分析，不仅知其然，还要知其所以然。","dir":"blog/sofa-boot- log-isolation/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a428e36a94180c1e33920579423b4402","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-log-isolation/","publishdate":"2020-02-18T17:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-boot-log-isolation/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFABoot","剖析 | SOFABoot 框架","SOFALab"],"title":"蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-log-isolation/","wordcount":4632},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@乘疯破浪 提问：\n 咨询一个性能问题，一个 2C 的业务场景：本地库操作多次 db，再调用分布式服务，再 TC 端注册多个分支事务耗时较多，用户 C 端等待时间较长，这种问题有处理方案吗？client 已设置 report 分支状态 =false。\n A：确实比较长，个人建议从架构入手去改良，可以通过存入 redis 等一个消息，告诉用户正在插入-\u0026amp;gt;然后一步出力业务，出现异常同样 redis 里的信息改为异常。如果成功就为成功存储 id 或者其它看业务具体情况,然后用户端页面做个倒计时，或者转圈圈，或者直接告诉他正在插入稍等。比如以前用 MQ 削峰就差不多是这个思路吧。长事务尝试用用 Saga、AT 上手快，但是因为锁的存在，效率比较低，后续会逐步优化，性能高入侵也高的 TCC 如果能尝试也可以试试。\n2、@孟昊 提问：\n 请问一下，我今天看了一下文档，好像 cloud 通过 feign 调用方式只能使用 AT 模式, 在并发量比较高的场景下会有问题么(小事务)。\n A：微服务框架跟分布式事务模式没有绑定，还可以用 TCC、Saga。Saga 目前理论上支持所有 RPC 框架，只要是个 bean 即可。\n3、@小孟 提问：\n MOSN 是否支持了 Dubbo 协议？\n A：MOSN 在本周已通过 x-protocol 支持了 Dubbo 和 Tars 协议，具体可见： https://github.com/mosn/mosn/pull/950\n4、关于线上直播 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk 提问回答\n直播视频回顾：https://tech.antfin.com/community/live/1096\n@鸿关 提问：\n 用 SOFAArk 的话，能直接集成到 SOFABoot 工程不？还是说必须要建个 SOFAArk 的工程？SOFAArk 可以运用于非 SOFABoot 的项目么？\n A： 能直接继承到 SOFABoot 工程，不需要新建 SOFAArk 工程，也可以用于非 SOFABoot 工程，只要是 Spring Boot 工程即可，但是不引入 SOFA 相关依赖的话，@SofaService 及 @SofaReference 等注解就没法用了。\n@盲僧 提问：\n 运行期间安装 biz，然后激活模块这一过程做了哪些事情 ，如果这个 biz jar 包放在远程仓库怎么加载里面的代码呢？是拉下来放到本地的一个磁盘用 classloader 去加载使用吗？\n A：安装和激活是的两个操作，安装支持两种协议获取 biz 包：http 和 file，激活只是在内部调整了同 biz 不同版本的状态。\n 运行期间安装 biz 后，那个 execute jar 包里会有这个 biz 包吗？ A：可以尝试用插件打个包出来解压看下哦。\n @曾鹏 提问：\n SOFAArk 有什么实际的应用场景吗？\nA：可以看下这个：蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析\n SOFAArk：https://github.com/sofastack/sofa-ark\n本周推荐阅读 SOFAStack Community | 欢迎加入 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFATracer v2.4.5\u0026amp;frasl;3.0.9 版本，主要变更如下：\ni. 默认禁用上报数据到zipkin, 需要显式设置 com.alipay.sofa.tracer.zipkin.enabled=true 才能开启； 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.5 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.9\n2、发布 SOFATracer v2.4.6v/v3.0.10 版本，主要变更如下：\ni. 支持使用 JVM系统属性 或 环境变量 SOFA_TRACER_LOGGING_PATH 来定制 tracelog 的路径 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.6 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.10\n社区直播预告 本期为 SOFAChannel 线上直播第 12 期，将邀请蚂蚁金服分布式事务核心开发仁空分享《蚂蚁金服分布式事务实践解析》。\n软件开发模式从原来的单应用，到现在的微服务、分布式架构，一个大型分布式系统内，单业务链路往往需要编排多个不同的微服务，如何实现分布式场景下业务一致性，是摆在软件工程师面前的一个技术难题。\n本期分享将介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1581667200,"description":"【02/10-02/14】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200214/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3deaf12dd1b6589f41c57291d9061534","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200214/","publishdate":"2020-02-14T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200214/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 2/13直播回顾、3/12直播预告、SOFATracer 发版","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200214/","wordcount":1781},{"author":"SOFA 团队","categories":"Service Mesh","content":" 2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。\n参与问卷调查的人员情况 共收集到 516 份问卷结果，问卷填写者 94.2% 来自 ServiceMesher 社区，21.7% 的人参与过社区线上活动，27.5% 的人参与过社区 meetup，86.6% 看好 Service Mesh 的未来发展前景。\n下面是参与问卷调查人员的基本情况。\n公司所属行业\n所在公司的 Service Mesh 使用情况\n工作年限\n在公司中担任的职务\n关注 Service Mesh 技术的时长\n周围关注或了解 Service Mesh 技术的人员情况\n学习 Service Mesh 技术的方式\n关注的 Service Mesh 相关开源项目\n除了 Service Mesh 外关注的其他云原生领域\n对 Service Mesh 的了解程度\n关注 Service Mesh 技术中的哪部分\n社区参与 了解社区活动的情况\n对社区的建议\n还有很多对社区的建议，反馈比较多的如下：\n 更多落地实践和指南 发布一些入门级的文章，结合案例，让技术在中小企业中落地 组织一些线上或线下活动 对普通开发者的职业发展的建议 出系列教程 结论 从结果中可以看出，Service Mesh 在互联网公司中关注的比例最高，但是它仍然还在高速发展中，还缺乏完善的教程和案例。\n本次问卷调查旨在了解 ServiceMesher 社区成员对 Service Mesh 的了解及社区参与程度，帮助 ServiceMesher 社区做的更好，还需要社区成员们共同的努力。\n欢迎关注 Service Mesh 技术的小伙伴们加入 ServiceMesher 社区，共同交流学习和成长。\n关于本次调查问卷的最终解释权归 ServiceMesher 社区所有。\n","date":1581667200,"description":"2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。","dir":"blog/service-mesh-end-user-survey-report/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e2f1dc19ca9ab916db565bdd2bd5a50f","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-end-user-survey-report/","publishdate":"2020-02-14T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/service-mesh-end-user-survey-report/","summary":"2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。 参与问卷调查的人员情况 共收集到 516 份问卷结","tags":["Service Mesh"],"title":"Service Mesh 终端用户调查报告","type":"blog","url":"/sofastack.tech/blog/service-mesh-end-user-survey-report/","wordcount":530},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n 活动时间：3 月 12 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#12：蚂蚁金服分布式事务实践解析 软件开发模式从原来的单应用，到现在的微服务、分布式架构，一个大型分布式系统内，单业务链路往往需要编排多个不同的微服务，如何实现分布式场景下业务一致性，是摆在软件工程师面前的一个技术难题。\n蚂蚁金服作为一家金融科技公司，业务涉及金融核心的各个领域，从2007年开始就自主研发了分布式事务框架，解决跨数据库、跨服务的业务一致性问题；随着13来年的不断打磨和沉淀，历经双十一、双十二等大促的洗礼，如今所有核心业务都已经在使用这套框架来保障交易的完整性和最终一致性，做到知托付，让用户放心。\n本期分享将介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n本期为 SOFAChannel 线上直播第 12 期，将邀请蚂蚁金服分布式事务核心开发仁空分享《蚂蚁金服分布式事务实践解析》。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1096\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 仁空，蚂蚁金服分布式事务核心开发\n本期分享大纲 分布式事务产生的背景； 蚂蚁金服分布式事务理论与实践； TCC 模式 FMT 模式 蚂蚁金服分布式事务极致性能提升； 蚂蚁金服分布式事务开源与展望； 嘉宾 SOFAGirl 主持人 仁空，蚂蚁金服分布式事务核心开发 ","date":1581498000,"description":"3 月 12 日周四晚 7 点，线上直播第 12 期。","dir":"activities/sofa-channel-12/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c80a24fd4e76747f0ed57c139a2bfae9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-12/","publishdate":"2020-02-12T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-12/","summary":"概要 活动主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析 活动时间：3 月 12 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍 | SOFAChannel","tags":["SOFAChannel","分布式事务"],"title":"SOFAChannel#12：蚂蚁金服分布式事务实践解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-12/","wordcount":784},{"author":"纶珥","categories":"SOFALab","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFABoot 框架》第一篇，本篇作者纶珥，来自蚂蚁金服。《剖析 | SOFABoot 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:BootLab/]()，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFABoot 是蚂蚁金服开源的基于 SpringBoot 的研发框架，提供了诸如 Readiness Check、类隔离、日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\nSpringBoot 基于 Spring 的按条件配置（Conditional Configuration），结合 starter 依赖机制提供了快捷、方便开发 Spring 项目的体验，获得了极大的成功；SOFABoot 同样在这两个能力上基于 SpringBoot 扩展出适应于金融级应用开发框架。作为脱胎于蚂蚁金服内部对于 SpringBoot 的实践，SOFABoot 补充了 SpringBoot 在大规模金融级生产场景下一些不足的地方，例如 Readiness 检查、类隔离和日志空间隔离等等能力。在增强了 SpringBoot 的同时，SOFABoot 还提供了让用户可以在 SpringBoot 中非常方便地使用 SOFAStack 中间件的能力。\nSOFABoot ：https://github.com/sofastack/sofa-boot\n功能点概览 SOFABoot 完全兼容 SpringBoot，SpringBoot 技术栈可以快速切换到 SOFABoot 技术栈：修改项目 pom 依赖的 \u0026amp;lt;parent/\u0026amp;gt; 节点，例如将：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 当前 SOFABoot 的最新版本为 v3.2.2。\n应用 Readiness 检查 一个应用启动之后，是否是“准备”好能够处理外部请求呢？作为应用流量入口的组件是否可以接收外部连接？这就很有必要引入应用 Readiness 的检查，SOFABoot 提供除 SpringBoot 健康检查之外的应用 Readiness 检查能力，保证应用组件的正常启动、应用安全上线。\nSOFABoot 通过 HealthChecker 检查各组件的 ready 情况。在 Spring 上下文刷新完成之后（所有的 Spring Bean 已经实例化完成），SOFABoot 会获取 IoC 容器中所有的 HealthChecker 实现类，检查其返回的组件健康状况；在应用开启了模块化隔离之后，模块 HealthChecker 还会 kicks in，检查模块的健康状况。Spring 原生的 HealthIndicator 作为 Readiness 的一部分也会纳入 Readiness 的结果中，若 HealthIndicator 出现了失败的情况，那么应用的 Readiness 也是不通过。\nReadiness 检查包含组件的后置检查，流量入口组件（例如：RPC、REST）需要保证后置检查通过之后能接受外部流量的请求，应用才是真正 ready 了。\n应用 Readiness 与 Liveliness 不同的是 Readiness 表示的是应用启动完成之后是否“准备”好的状态，启动完成之后是不变的；两次部署间的 Readiness 的所有请求结果是一致的。\n应用模块化 应用模块化的方案多种多样。传统方案是以应用功能为边界做模块划分；研发期间，不同职责的类放在不同的模块下，但在运行期间都在同一个 classpath 下，没有任何隔离。而与传统的模块划分方案不同，人们发现可以利用 Java 的 ClassLoader 机制，将模块与模块间的类完全隔离；当某个模块需要与另一个模块通信时，可以通过类的导入和导出来实现。OSGi 和 SOFAArk 都是基于 ClassLoader 隔离的模块化实践方案。\n传统的模块化方案没有任何的隔离手段，模块间的边界得不到保障，容易出现模块间的紧耦合；而基于 ClassLoader 的模块化方案则过于彻底，研发人员必须十分清楚类的导入与导出、Java 的类加载体系，模块划分的负担转嫁到了普通研发人员身上。\nSOFABoot 综合以上两种方案的利弊，引入了介于两者之间的模块化方案：每个模块有独立的 Spring 上下文，通过上下文的隔离，让不同模块之间的 Bean 的引用无法直接进行，达到模块在运行时的隔离。这样既保证了不引入过多的复杂性，也避免了没有任何隔离措施的模块边界保障。如下图所示：\n所有的 SOFABoot 模块都会有一个相同的 Spring Context 的 Parent，称之为 Root Application Context。对于所有模块都需要引入的 Bean，可以选择将其放置于 Root Application Context 中，在所有的模块间共享。此外，SOFABoot 框架提供两种 Spring 上下文隔离方案后的模块间通信能力：\n JVM 服务的发布和引用：同一个应用内不同模块间的通信 // Publish a JVM service @Component @SofaService public class MyServiceImpl implements MyService { // implementation goes here } // Reference a JVM service public class AnyClass { @SofaReference private MyService myService; } RPC 服务的发布和引用：不同应用间的通信 // Publish a RPC service @Component @SofaService(interfaceType = MyService.class, bindings = { …","date":1581321600,"description":"本文为《剖析 | SOFABoot 框架》第一篇，主要介绍 SOFABoot 的基础特效。","dir":"blog/sofa-boot-overview/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d1a5fa7654f26a159c65061d4f7712d7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-overview/","publishdate":"2020-02-10T16:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-boot-overview/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFALab","剖析 | SOFABoot 框架","SOFABoot"],"title":"蚂蚁金服研发框架总览 | SOFABoot 框架剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-overview/","wordcount":3219},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@张一心 提问：\n 建议 Seata 全局加锁时候支持快速抢占机制，在不同重要程度事务处理中优先满足重要业务的加锁处理以优先保证紧急重要逻辑的处理，实现方式有多种的，可以根据情况直接回滚干掉非紧急事务也可以在等待加锁队列中做插队处理。\n A：不是通用场景，这个不是通过 API 来实现，后续添加控制台后，在控制台页面对活动事务可以进行控制，可单个事务降级或 redo。\n 之前我是通过改造其值来源于 Nacos 配置的全局事务注解完成的，有了单独事务控制台能起到各司其职更好，既然后续补充了控制台，是不是事务处理的各类统计也能在控制台上面看得到，作为一系列资源分配的参考指标。\n A：控制台主要包括监控统计和事务控制介入，你说的应该是动态降级，这个是全局的，细化不到刚才说的那种抢占机制比如手动在控制台的具体某个事务进行降级释放锁，直接通过 API 这个数据破坏性无法控制，对于这种需要人工去介入并且有 trace。\n 实际生产中涉及金钱交易的优先级往往高于非金钱交易的优先级。破坏性来源主要是加锁中的破坏性回滚，实际业务中往往会存在不能锁刚好被加在队列中等待一阵的现象，这时候完全可以根据全局标记做全局性插队，在处理中加快相关业务处理。监控粒度不应该忽视锁的名称，全局业务的加锁顺序和持有时间，不然当业务量大且相互交叉发生全局性死锁也是会存在的。确切说是业务量大并且分布在不同 TC 上加锁情况下可能会产生哲学家就餐问题带来的死锁。\n A：这里不存在死锁，先拿的是数据库的 X 锁，在拿的是全局锁，你可以举个栗子。一种优先级是处理前优先级类似于 mq 的优先级队列，这种是哪个事务优先被处理，这种是需要兼顾顺序和锁优先级排序，高优先级事务分支优先被处理。 一种是处理中的锁被剥夺，这种是破坏性的，如果在一个不重要的事务中分支1执行完成，另外一个重要事务请求分支1同样的锁，这个锁这时可被剥夺，不重要事务释放锁降级非分布式事务。大多数冲突的情况应该属于处理中而不是处理前。\n 根据测试经验，量小的时候会等，量大的时候会直接碰撞，量进一步加大则除了碰撞而且跑队列里一起挤挤的概率就会飙上去。这时候会遇到几个难点，1队列下是不是插队（这个通过认为设置比较好解决）2抢占是否必要，这时候需要通过对之前加锁的统计（包括业务处理时间与网络通信等综合指标）和潜在破坏性做评估，如果破坏性较小或无且不抢占下对业务预等待时间较长且其他回滚表较为独立则直接回滚抢占，最典型场景就是扣钱的时候充值，或者出货的时候补货。\n A：第2中的破坏性来源于不重要事务锁被剥夺降级为非分布式事务，但是由于后续事务分支出现异常，会导致这个事务分支无法参与回滚，若参与回滚必会导致重要事务全局回滚时数据校验不通过而无法回滚。\n 对，校验不通过关键在于目前采用的是全量型业务，而不是基于对 sql 语句解析之后的增量型业务（即 TCC 的 cancel 步骤里反向对冲）。\n A：对于 AT 模式都是基于数据的不是基于 sql 的，与 binlog 同步方式类型同理。\n 下面问题来了，数据破坏是因为先去 TC 报道还是先去数据库加锁造成的。如果先去 TC 报道，等报道成功再去 DB 加锁就不会发生数据破坏的问题，因为报道失败就直接返回了不会对 DB 造成影响。\n A：那个锁的范围更大些，肯定是 DB 的 X 锁。服务是操作 DB 的，如果连 DB 锁拿不到，拿全局锁有什么意义，假设先拿全局锁，数据库锁拿不到时是不是又需要 RPC 去释放全局锁？\n 不知道有没必要添加对全局读写锁的支持，这个个人未实践过，纯属个人观点，也不知道现在是否已经实现了？\n A：这个说的是类似 JUC 的读写锁嘛？如果单纯这样没什么实际意义，现在是类似数据库 select for update 的 X 锁上升到全局锁。\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.9.0 版本，主要变更如下：\n 引入嵌入模式； 升级 SGX SDK 依赖到最新版； 大幅提升网络 I/O 的性能； 正式支持 Python 语言的应用； 正式支持 Ubuntu 18.04 和 CentOS 7.2； 修复了多个 bug； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.9.0\n社区直播预告 春节后直播预告来啦～本期为 SOFAChannel 线上直播第 11 期，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n时间：2020年2月13日（周四）19:00-20:00\n嘉宾：玄北，蚂蚁金服技术专家 SOFAArk 开源负责人\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1581066000,"description":"【02/03 - 02/07】 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200207/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4e10f9b05976b3f0f8ce4d9128fa8d79","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200207/","publishdate":"2020-02-07T17:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200207/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 落地系列文章、2/13直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200207/","wordcount":2288},{"author":"柑橘、西经、柏翘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，该系列从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n前言 Service Mesh 在蚂蚁金服内部已经大规模落地，经历刚刚双十一的检阅，将现有的体系快速演进至 Service Mesh 架构，无异于给飞机换发动机。本主题主要分享在蚂蚁金服当前的体量下，我们如何做到给飞机换发动机，还确保不出问题。同时在 Mesh 对外客户输出同样有高质量的保障。\n本文结合蚂蚁金服 Mesh 化落地质量保障落地的思考，给大家带来如下三个方面的一些质量保障的分享：\n Mesh 化质量保障体系； Mesh 化测试技术； Mesh 化双十一大规模落地的性能保障； 质量保障体系 首先给大家介绍下我们的质量保障体系。\n测试保障体系\n我们从测试环境、测试用例、基础功能测试原子镜像能力、测试工具平台、测试场景组合调度、测试方案制定、线上巡检监控、灰度发布三板斧、交付验证、性能、自动化测试等多个方面进行系统性测试保障。通过内外部的质量数据度量和双十一大促来检阅我们的质量能力。\nMesh 测试技术 在开始介绍测试技术之前，我们先了解一下什么是 Service Mesh 以及 Service Mesh 是如何工作的，在蚂蚁金服的技术架构中是以什么形式存在，发挥着怎样的作用。\n简单的说 Service Mesh 存在两个面，一个面叫数据面（比如 MOSN），就是处理应用数据请求的一个独立代理模块，脱离于应用，为应用提供请求代理及一些复杂通信逻辑处理，另外一个叫控制面（比如 SOFAMesh），管理应用配置及业务规则等（比如业务开关/服务路由规则），通过下发配置“指挥”数据面去执行，满足不同阶段实现不同的业务支持。\nMesh 框架简图\n我们先简单介绍下经典微服务请求路由。\n经典微服务模式请求路由\n经典微服务模式下 Docker 镜像化服务在一个 Pod 一般只有一个业务应用容器在运行，这种情况下测试框架只要关心业务应用即可。\n经典微服务测试架构\nMesh 测试架构改进 Mesh 测试架构在经典微服务测试架构上也做了新的演进。MOSN 作为 Sidecar 与业务容器共存在一个 Pod，资源与业务应用容器共享，每个业务逻辑都需要通过 MOSN 去处理，因而只关心业务应用肯定不够，需要再扩展支持到 MOSN 这类 Sidecar 的测试验证。在 MOSN 中集成了控制面 xds client，与控制面 pilot 建立通信，用于接收 pilot 下发的配置信息。在蚂蚁金服技术架构存在三地五中心/同城双活等容灾能力，因而产生了 LDC，一个集群多个 zone 情况，控制面 pilot下发是可以配置集群+zone+应用+ip 组合粒度，要验证这个多 zone 下发规则准确性，那就需要创建多个 xds client（或者 MOSN）。另外 Sidecar 是不能直接访问的，通过测试应用暴露出接口，给上层测试。\nMesh 化测试架构\n构建高仿真测试环境 那么，我们测试环境要做到足够仿真，面临哪些挑战呢？首先看下我们自研的 MOSN 具备的能力和技术复杂性。\n MOSN 能力大图\n应对 MOSN 测试场景复杂性，我们搭建了一套高仿真测试环境，这里以 MOSN 中的 RPC 功能为例，阐述这套环境的构成要素及环境部署架构。\n集成测试环境构成要素\n这里可以举一个 RPC 路由的例子来详细讲述。我们知道，业务在做跨 IDC 路由时，主要通过跨域 VIP 实现，这就需要业务在自己的代码中设置 VIP 地址，例如：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.APPNAME.facade.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleRpcService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.tr\u0026amp;gt; \u0026amp;lt;sofa:vip url=\u0026amp;quot;APPNAME-pool.zone.alipay.net:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.tr\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 这时候假如业务配置了不合法的 URL，如：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.APPNAME.facade.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleRpcService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.tr\u0026amp;gt; \u0026amp;lt;sofa:vip url=\u0026amp;quot;http://APPNAME-pool.zone.alipay.net:12200?_TIMEOUT=3000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.tr\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上述 VIP URL 指定了 12200 端口，却又同时指定了 http，这种配置是不合法的，就会出现问题，这时候测试环境就需要跨 zone、跨 LDC 的测试环境。我们在多数复杂产品测试里都会遇到，极度复杂测试场景无法 100% 分析充分。一般对于这种场景，我们可以借助于线上流量回放的能力，将线上的真实流量复制到线下，作为我们测试场景的补充。这也需要非常仿真的测试环境做 MOSN 的流量回放支撑。\n兼容性测试 MOSN 兼容性验证\n我们通过一个例子来详细阐述：老版本的 RPC 中我们支持 TR 协议，后续的新版支持 BOLT 协议，应用升级过程中，存在同时提供 TR 协议和 BOLT 协议服务的情况，如下图：\n应用升级过程中，相同接口提供不同协议的服务\n首先，应用向 MOSN 发布服务订阅的请求，MOSN 向配置中心订阅，配置中心返回给 MOSN 两个地址，分别支持 TR 和 BOLT，MOSN 从两个地址中选出一个返回给应用 APP。\n这里兼容性风险是：MOSN 返回给 APP 的地址是直接取配置中心返回的第一条数据，这里可能是 TR 也可能是 BOLT。\n如果 MOSN 返回给应用的地址是支持 BOLT 协议的服务端，那么后续应用发起服调用时，会直接以 BOLT 协议请求 MOSN，MOSN 选址时，会以轮询的方式两个服务提供方，如果调用到 Server1，就会出现协议不支持的报错。 因此我们针对各种兼容性具体场景都要做好分析和相应的测试。\nMOSN 的鲁棒测试（稳定性、健壮性） 从 MOSN 的视角来看，其外部依赖如下：\nMOSN 外部依赖图\n除了验证 MOSN 自身的功能外，我们还通过故障注入的方式，对 MOSN 的外部依赖做了专项测试。通过这种方式，我们发现了一些上述功能测试未覆盖的场景，这里以应用和 MOSN 之间的 12199 端口举例。\n应用 APP 接入 MOSN 后，原先应用对外提供的 12200 端口改由 MOSN 去监听，应用的端口修改为 12199，MOSN 会向应用的 12199 端口发送心跳，检测应用是否存活。\n如果应 …","date":1579514400,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，结合蚂蚁金服 Mesh 化落地质量保障落地的思考，给大家带来一些质量保障的分享。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8dfd6e1dabd16bc85d9876ce9764e3ab","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","publishdate":"2020-01-20T18:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，该系列从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","wordcount":3163},{"author":"嘉祁","categories":"Service mesh","content":" 本文根据蚂蚁金服中间件 SRE技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。\n背景 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。而在具体部署上，保守的做法是以独立进程的方式与业务进程共同存在于业务容器内。蚂蚁金服的做法是从开始就选择了拥抱云原生。\n大规模落地的过程中，我们在看到 Service Mesh 带来的巨大红利的同时，也面临过很多的挑战。为此，蚂蚁金服配备了“豪华”的技术团队阵容，除了熟悉的 SOFA 中间件团队，还有安全、无线网关以及专门配备了专属的 SRE 团队，使得 MOSN 能力更加全面更加可靠。\n今天我们详细聊聊技术风险这个方面。对于一个新的中间件技术，在落地过程中总会面临稳定性、运维模式变化等等很多的问题与挑战，需要建设相应的技术风险能力，确保整个落地过程以及长期运行的稳定和可靠。\n本次分享主要从以下三个方面展开：\n 落地过程中对于部署模式和资源分配的思考； 变更包括接入、升级的支持、问题与思考； 整个生产生命周期中稳定性面临的挑战与技术风险保障； Sidecar 部署模式 业务容器内独立进程的好处在于与传统的部署模式兼容，易于快速上线；但独立进程强侵入业务容器，对于镜像化的容器更难于管理。而云原生化，则可以将 Service Mesh 本身的运维与业务容器解耦开来，实现中间件运维能力的下沉。在业务镜像内，仅仅保留长期稳定的 Service Mesh 相关 JVM 参数，从而仅通过少量环境变量完成与 Service Mesh 的联结。同时考虑到面向容器的运维模式的演进，接入 Service Mesh 还同时要求业务完成镜像化，为进一步的云原生演进打下基础。\n 优 劣 独立进程 兼容传统的部署模式；改造成本低；快速上线 侵入业务容器； 镜像化难于运维 Sidecar 面向终态；运维解耦 依赖 K8s 基础设施；运维环境改造成本高；应用需要镜像化改造 在接入 Service Mesh 之后，一个典型的 POD 结构可能包含多个 Sidecar：\n MOSN：RPC Mesh, MSG Mesh, \u0026amp;hellip;（扩展中）； 其它 Sidecar； MOSN：https://github.com/mosn/mosn\n这些 Sidecar 容器与业务容器共享相同的网络 Namespace，使得业务进程可以以本地端口访问 Service Mesh 提供的服务，保证了与保守做法一致的体验。\n基础设施云原生支撑 我们也在基础设施层面同步推进了面向云原生的改造，以支撑 Service Mesh 的落地。\n运维平台模型支撑 首先是运维平台需要能够理解 Sidecar，支撑 Sidecar 模型的新增元数据，包括基于 POD 的 Sidecar 的多种标签，以及 Sidecar 基线配置的支持。\n业务全面镜像化 其次我们在蚂蚁金服内部推进了全面的镜像化，我们完成了内部核心应用的全量容器的镜像化改造。改造点包括：\n 基础镜像层面增加对于 Service Mesh 的环境变量支撑； 应用 Dockerfile 对于 Service Mesh 的适配； 推进解决了存量前后端分离管理的静态文件的镜像化改造； 推进了大量使用前端区块分发的应用进行了推改拉的改造； 大批量的 VM 模式的容器升级与替换； 容器 POD 化 除了业务镜像层面的改造，Sidecar 模式还需要业务容器全部跑在 POD 上，来适应多容器共享网络。由于直接升级的开发和试错成本很高，我们最终选择将接入 Service Mesh 的 数百个应用的数万个非 K8s 容器，通过大规模扩缩容的方式，全部更换成了 K8s PODs。\n经过这两轮改造，我们在基础设施层面同步完成了面向云原生的改造。\n资源的演进 Sidecar 模式的带来一个重要的问题，如何分配资源。\n理想比例的假设独占资源模型 最初的资源设计基于内存无法超卖的现实。我们做了一个假设：\n MOSN 的基本资源占用与业务选择的规格同比例这一假设。 CPU 和 Memory 申请与业务容器相应比例的额外资源。这一比例最后设定在了 CPU 1/4，Memory 1/16。\n此时一个典型 Pod 的资源分配如下图示：\n独占资源模型的问题 这一方式带来了两个问题：\n 蚂蚁金服已经实现了业务资源的 Quota 管控，但 Sidecar 并不在业务容器内，Service Mesh 容器成为了一个资源泄漏点； 业务很多样，部分高流量应用的 Service Mesh 容器出现了严重的内存不足和 OOM 情况； 共享资源模型 讨论之后，我们追加了一个假设：\n Service Mesh 容器占用的资源实质是在接入 Service Mesh 之前业务已使用的资源。接入 Service Mesh 的过程，同时也是一次资源置换。 基于这个假设，推进了调度层面支持 POD 内的资源超卖，新的资源分配方案如下图，Service Mesh 容器的 CPU、MEM 都从 POD 中超卖出来，业务容器内仍然可以看到全部的资源。\n考虑到内存超卖也引入了 POD OOM 的风险，因此对于 Sidecar 容器还调整了 OOM Score，保证在内存不足时，Service Mesh 进程能够发挥启动比 Java 业务进程更快的优势，降低影响。\n新的分配方案解决了同时解决了以上两个问题，并且平稳支持了蚂蚁金服的双十一大促。\n变更-Service Mesh 是如何在蚂蚁金服内部做变更的 Service Mesh 的变更包括了接入与升级，所有变更底层都是由 Operator 组件来接受上层写入到 POD annotation 上的标识，对相应 POD Spec 进行修改来完成，这是典型的云原生的方式。\n接入-从无至有 标准的云原生的接入方式，是在创建时通过 sidecar-operator webhook 注入一个 Sidecar 容器。\n这个方式的固有缺陷在于：\n 滚动替换过程需要 Buffer 资源； 过程缓慢； 回滚慢，应急时间长； 原地接入 原地接入是为了支撑大规模的快速接入与回滚，通过在存量的 POD 上操作修改 POD Spec。\n尽管看起来不太云原生，但期望能绕过以上几个痛点，从而可以：\n 不需要重新分配资源； 可原地回滚； 升级 Service Mesh 是深度参与业务流量的，最初的 Sidecar 的升级方式也需要业务伴随重启。\n带流量的平滑升级 为了规避 Java 应用重启带来的重新预热等问题，MOSN 提供了更为灵活的平滑升级机制：由 Operator 控制启动第二个 MOSN Sidecar，完成连接迁移，再退出旧的 Sidecar。整个过程业务可以做到流量不中断，几近无感。\n变更能力的取舍 虽然提供了原地接入与平滑升级，但从实践的效果来看，对存量 POD spec 的修改带来的问题，比收益要多得多。\n 创建时注入/普通升级 原地注入/平滑升级 不改变现存 POD spec 改变现存 POD 资源预分配，不影响调度； 逻辑简单，成功率高；与原有业务升级逻辑一致； …","date":1579514400,"description":" 本文根据蚂蚁金服中间件 SRE 技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。","dir":"blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7e1941c7099e109de92394b49df59a2b","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","publishdate":"2020-01-20T18:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","summary":"本文根据蚂蚁金服中间件 SRE技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。 背景 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。","tags":["Service mesh","Service Mesh Meetup"],"title":"蚂蚁金服 Service Mesh 技术风险思考和实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","wordcount":4057},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n 活动时间：2 月 13 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本期为 SOFAChannel 线上直播第 11 期，将邀请 SOFAArk 开源负责人玄北和大家一起解读 SOFAArk ，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk：https://github.com/sofastack/sofa-ark\n你将收获：\n 快速认识轻量级类隔离容器 SOFAArk； Demo 案例实操，了解如何使用 SOFAArk 实现类隔离； SOFAArk 完整功能详解； | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1096\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 从一个例子开始体验轻量级类隔离容器 SOFAArk 玄北，蚂蚁金服技术专家 、SOFAArk 开源负责人\n本期分享大纲： 快速认识轻量级类隔离容器 SOFAArk； Demo 案例实操，了解如何使用 SOFAArk 实现类隔离； SOFAArk 完整功能详解； 嘉宾 SOFAGirl 主持人 玄北，蚂蚁金服技术专家 、SOFAArk 开源负责人 ","date":1579251600,"description":"2 月 13 日周四晚 7 点，线上直播第 11 期。","dir":"activities/sofa-channel-11/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b110f76087d52e5c6d8ccbe31c76a7f5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-11/","publishdate":"2020-01-17T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-11/","summary":"概要 活动主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk 活动时间：2 月 13 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这","tags":["SOFAChannel","SOFAArk"],"title":"SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk","type":"activities","url":"/sofastack.tech/activities/sofa-channel-11/","wordcount":709},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@J~杰 提问：\n 咨询一下，Seata TCC 中这个 BusinessActivityContext 是用于做什么的？\n A：比如说在 rollback 服务里需要用到 try 服务里的参数时，可以放到 BusinessActivityContext，然后在 rollback 和 comfirm 服务里可以取到这个参数。\n 那是要自己在 try 阶段需要手动实例化 BusinessActivityContext？\n A：不需要，可以在 try 方法上的参数加注解，它会自动把这个参数放入 BusinessActivityContext。\nSeata：https://github.com/seata/seata\n2、王国柱 提问：\n 有一个问题想要请教一下： HBX：如果是 spanner - \u0026amp;gt; gateway -\u0026amp;gt; app1 这种架构，每次上新的应用，应该是需要在 geteway 中配置新应用的 ip 地址路由信息。 如果是 spanner -\u0026amp;gt; gateway.jar,app1 这种架构，如果新增加 app2， spanner 如何知道新的应用地址在哪里。\nHBX：我理解集中式的 gateway，应该会把后端 app 的应用地址信息配置在集中式的 gateway 中。如果做成 jar，那 app 和 jar 的地址信息，该如何被 spanner 知道？\n A：Spanner 其实就是 ingress，不管是 gateway 还是 app x，都可以通过服务发现来发现服务器的 ip 信息。\n 那像这种的话，就是后台服务上线，可以自己注册到 spanner 上，然后外部应用就可以直接访问了。\n A：是的。 MOSN：https://github.com/mosn/mosn\nKubeCon NA2019 回顾 开箱即用的 Java Kubernetes Operator 运行时 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 本周推荐文章 10年后，阿里给千万开源人写了一封信 蚂蚁金服消息队列 SOFAMQ 加入 OpenMessaging 开源标准社区 蚂蚁金服 API Gateway Mesh 思考与实践 社区直播预告 春节后直播预告来啦～本期为 SOFAChannel 线上直播第 11 期，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n时间：2020年2月13日（周四）19:00-20:00\n嘉宾：玄北，蚂蚁金服技术专家 SOFAArk 开源负责人\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1579248000,"description":"【01/13-01/17】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200117/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2fd8dd14cb119400890ef134622ad4d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200117/","publishdate":"2020-01-17T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200117/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":" SOFA Weekly | 2.13直播预告、KubeCon NA2019 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200117/","wordcount":1210},{"author":"何子波、金敏","categories":null,"content":" 本篇分享的内容难度为“初学者/Beginner”级别，以下是阅读本文前推荐您了解的背景知识：\n Java 语言编程基础； 了解过 Kubernetes 平台上的 Operator/Controller 工作机制； 也可以同步参考 Kubernetes 官方博客内容：https://kubernetes.io/blog/2019/11/26/develop-a-kubernetes-controller-in-java\n图为何子波和金敏在 KubeCon NA2019 大会分享后的交流\n何子波 蚂蚁金服技术专家： _(adohe@github) _Kubernetes 维护者，SIG CLI Co-Chair（包括 Kubectl 及其扩展插件，Kustomize 以及客户端运行时），同时关注安全容器，多租户等领域。\n金敏 蚂蚁金服软件工程师： _(yue9944882@github) _Kubernetes SIG API-Machinery 维护者及其子领域 Owner（CRD 服务实现，APIAggregation SDK 套件，控制面流控，OpenAPIv2/3，Java SDK 等），同时也是 OpenAPI 开源生态工具链openapitools.org 的 Techincal Committee。\n本文根据两位在 KubeCon NA2019 的分享内容整理。本次演讲与大家分享蚂蚁金服金融科技扩展云原生 Java 能力到云的实践和改造，并将收获的产出回馈开放给 Kubernetes 社区。\n分享概要 在 Kubernetes 平台上开发部署运行 Operator 已经是在 Kubernetes 上拓展开发能力的默认范式。最早是 CoreOS 的工程师们创新提出了 Operator 的开发理念并且在社区收获了良好的反响，在经过一段时间的波折、打磨和实践之后，我们今天才看到丰富多样的 Operator 层出不穷。实际上 Operator 的效力往往要结合 Kubernetes API 的扩展能力才能更好发挥。所以其广泛传播反过来锤炼演进了 Kubernetes 上 CustomResourceDefinition 承载第三方 API 模型的能力。水涨船高，这也是社区集中投入人力从 v1.14 开始启动 Extensibility GA Sprint 小组冲刺 Kubernetes 扩展性建设的推动原因。\n图为何子波和金敏在 KubeCon NA2019 大会现场演示\n随着 Operator 的受众越来越多，社区也衍生出了面向 Operator 开发提效的工具链项目比如 operator-sdk、kubebuilder、metacontroller 等等优秀的开源项目。可是这些项目大都是面向 Go 语言研发者的，虽然越来越多的研发者向 Go 靠扰已是事实，但是 Go 语言尚不及其他主流编程语言成熟，倒是慢慢铺开的 Kubernetes 等其他开源项目的工业实践在“倒逼”Go 语言底层库的修复和稳固，比如 http2 的底层网络库[1]。与此相似的，我们最早内部孵化的 Java 语言的 Operator 运行时框架也是被实际业务“倒逼”出来的，并在 Kubernetes 社区露头试水之初便收获了许多反馈推动发展直到今天走到全面开放。\n你为什么需要使用 Java 开发 Operator 如果你在犹豫不决是否要使用 Java 开发 Operator 并应用到实际中来，我们从以下几个方面进行对比看看哪一点是足够吸引你尝鲜：\n 适配存量系统：如果在登陆 Kubernetes 之前你的基础设施底层系统都是通过 Java 开发的，那么恭喜你已经有了使用 Java Operator 的天然土壤。反过来把存量系统接口逐个“翻译”为 Go 语言既消耗大量人力又引出持续同步维护 Go 语言库的成本。 堆内存快照：相比于 Java，Go 语言很难将运行中的程序的内存进行完整的快照分析，PProf 相关工具链能做的只是将内存的使用概况汇总输出，虽然也可以帮助分析锁定出泄漏的对象类型，但是粒度有限。反过来 Java 程序的堆内存进行快照分析已经具有成熟的工具链支持，研发者通过一份完整的堆快照可以直接锁定出比如 WorkQueue 中积压的内容，甚至限流器中逐个 Key 的瞬时状态，也可以在 Operator 静默不响应的场景下快速锁定问题。 性能诊断/在线调试：结合比如 JMX Exporter 等工具链的帮助，我们直接将 Java 虚拟机的细节运行状态以 Prometheus Metrics 的形式收集起来，虽然 Go 程序也可以暴露出其运行时的 Metrics，但是对比后我们发现 Java 的 Metrics 在分析 GC 状态和堆分布上更加强大。除此之外，Java Operator 的远程调试更加方便上手。 线程模型：与 Java 显著不同的是，Go 语言中的 Routine 不具有直接从外部“杀死”的功能，你需要结合 Channel/Context 等模型间接实现。而在 Java 虚拟机上的线程模型有和操作系统类似的生命周期管理，开发者可以白盒的操作干涉线程的生命周期。这对于某些业务场景是重要的。 OOP 范型编程接口： Go 语言本身的设计哲学是不认可面向对象编程的，尽管好处很多但是在 API 模型繁多的 Kubernetes 项目中，维护者不得己转向使用代码生成器批量为这些模型生成大量模版代码。Java 的优势之一是范型编程，这可以彻底取代代码生成器的工作，同一套代码可以自由地适配在各种模型，比如 Pod 到 Service 等等。 第三方研发者库生态：经过数十年的演进，Java 积累的第三方工具库远比 Go 语言丰富的多，至少目前而已可以算得上是一个优势。 示例代码速览 下面两张代码片段为你展示了具体开发 Java Operator 所需要的全部工作，相信接触过 Kubernetes Client-Go 的开发者通过名字大致了解如何使用了：\n（如何构造出一个 Informer 实例） https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/InformerExample.java\n（如何构造出一个 Operator 实例） https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/ControllerExample.java\n开发 Java Operator 需要额外注意什么 仅仅是通过代码开发 Operator 显然不是大结局，你还需要注意其他的问题，以下是我们在实际运用的获得的经验总结：\n 严谨管理 CRD Yaml 定义：如最开始提到的，当 Java Operator 操作的是自定义资源比如 CRD 时，我们自然需要操作/维护该 CRD 对应的 Java 模型。 …","date":1579176000,"description":" 本文介绍了如何快速上手使用 Java 开发 Operator，感兴趣的读者可以根据官方实例在本地开发环境体验。","dir":"blog/java-kubernetes-operator-kubecon-na2019/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4af2ef3082aeed080e87501fd71134d9","permalink":"https://sofastack.github.io/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","publishdate":"2020-01-16T20:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","summary":"本篇分享的内容难度为“初学者/Beginner”级别，以下是阅读本文前推荐您了解的背景知识： Java 语言编程基础； 了解过 Kubernetes 平台上的 Operator/Controller 工作机制； 也可","tags":["Kubernetes"],"title":" 开箱即用的 Java Kubernetes Operator 运行时","type":"blog","url":"/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","wordcount":2778},{"author":"贾岛","categories":"Service Mesh","content":" 本文整理自蚂蚁金服高级技术专家贾岛在 12 月 28 日 Service Mesh Meetup 杭州站现场分享。\nMOSN 完成孵化， 启用独立 Group 2020.2019.12.18，MOSN 项目负责人、蚂蚁金服应用网络组负责人涵畅宣布 MOSN 完成从 SOFAStack 的孵化，将启用独立 Group 进行后续运作，欢迎大家共同建设社区。\nMOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称，可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡，API Gateway，云原生 Ingress 等使用。\n项目地址：https://github.com/mosn/mosn\n导语 在 Service Mesh 微服务架构中，我们常常会听到东西流量和南北流量两个术语。蚂蚁金服开源的 Service Mesh Sidecar：MOSN（Modular Observable Smart Network）已经多次与大家见面交流，以往的议题重点在东西流量的服务发现与路由，那么蚂蚁金服在南北流量上的思考是怎样的？\n本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的、解决了什么问题、双十一的实践表现以及我们对未来的思考。\n今天的分享分为三个部分：\n API Gateway Mesh 的定义：我在 Google 上搜了下 API Gateway Mesh 这个词，找到的都是 API Gateway vs Service Mesh，大家估计也会很好奇：这个词具体的定义是怎样的呢？所以我们下面会做将 API Gateway 和 Service Mesh 做个对比，然后讲一下我个人对这个词有理解和思考。 API Gateway Mesh 在蚂蚁金服的实践：今年阿里巴巴核心系统 100% 云原生化，撑住了双11的世界级流量洪峰，这其中，蚂蚁金服的 Service Mesh 大放光彩，核心链路全上 Mesh，数万容器规模，我们 API Gateway 在其中也承担了部分钱包链路和支付链路 100% 的请求。这个章节，我会从蚂蚁金服 API 网关的发展历程来看，我们为什么做 API Gateway Mesh，我们的架构是如何的，以及我们在过程中的一些风险和考验。 云原生下 API Gateway 的思考：大家现在都在讲云原生，但是真正实践云原生的过程中，会越到各种各样的问题，怎么样的 API Gateway 方案和形态是最合适你们的业务的？在云原生的架构中，Service Mesh，API Gateway 都是最核心的组件之一，我们对于云原生下的 API Gateway 在 Service Mesh 架构中的定位是如何思考的？还有，未来我们的一些计划是怎样的？都会在这个章节跟大家分享一下。 API Gateway Mesh 的定义 上面这张图是一个云原生，南北+东西流量的架构图，这里面包含了核心的一些组件，我快速介绍一下：\n LB\\ingress：负责 ssl 卸载、入口流量的负载均衡，通常会做一些简单的路由； API Gateway：负责更偏向业务的 API 验签、限流、协议转换、用户会话、负载均衡等逻辑； Sidecar in POD：业务系统中的 Sidecar，代理机房内东西流量的转发，一般走内部的 RPC（比如SOFARPC \\ Dubbo \\ Thrift \\ SpringCloud），这里面的流量全部通过 Service Mesh 的 Sidecar Proxy 来承载，这个 Sidecar 负责路由（单元化\\灰度\\金丝雀），负载均衡、服务鉴权等等； Control Plane：流量控制「大管家」，云原生里目前最主流的方案是 Istio，负责路由策略、安全、鉴权等等下发和控制； 上面的架构大家都比较了解了，从上面的描述大家也看出来了，API Gateway 和 Service Mesh 的 Sidecar 很多能力都是类似的，比如都是一个网络代理，都具备负载均衡，都具备一些限流和鉴权能力。下面，我们将做一个 API Gateway 和 Service Mesh 的对比。\nAPI Gateway vs Service Mesh  从本质概念上来讲，API Gateway 用一句话概括：「Exposes your services as managed APIs」，将内部的服务以更加可控可管理的方式暴露出去，这里的关键词是「暴露」和「可控」。Service Mesh 用一句话概括：「A infrastructure to decouple the application network from your service code」，一种将服务代码与应用网络解耦的基础设施，这里的关键词是「解耦」。\n在流量上，API Gateway 是管理南北流量的，而 Servcie Mesh 中的 Sidecar 一般情况下是用来负载东西流量的Proxy。两者都具备负责均衡的能力，API Gateway 一般情况下是通过 lvs 、nginx 中心化的一个负载均衡器，我们管这个叫硬负载；而 Service Mesh 一般情况下是通过服务发现，Sidecar 之间是点对点的调用，我们叫软负载。\n通信协议上，API Gateway 一般对外接收开放的通信协议，一般是 HTTP、gRPC 等，而且可能涉及到协议的转换，将 HTTP 转换成内部的 RPC 协议，而 Service Mesh 代理的内部流量一般是内部的私有 RPC 协议（WebService、Dubbo、SOFABolt、Thrift 等等）。在鉴权、流控、安全等控制流量的层面上，对于 API Gateway 来讲都是强依赖的，这样才体现「可控」的特点，而 Service Mesh 代理的内部流量，由于一般处于内网环境，这些控制一般情况下都是弱依赖。\n我们对 Service Mesh 的真正理解 大家可以看到，API Gateway 和 Service Mesh 实际上有很多共同点，也有很多区别。那 API Gateway Mesh 到底是如何定义的呢？那要介绍下，我们对 Service Mesh 的真正理解！\nService Mesh 中的 Sidecar 就是这样一辆边车摩托车，Sidecar 将 Service Code 和内部通信 RPC 逻辑解耦掉。但是 Sidecar 的座位上，不仅仅可以坐「内部通信的 RPC」，也可以将其他中间件放到这辆 Sidecar 中，API Gateway + Sidecar = API Gateway Mesh，我们也可以把 MessageQueue Client 放在 Sidecar 中，就是 Message Mesh。\n所以，大家看，其实 Service Mesh 是一种模式和架构，关键词就是「解耦」你的服务代码和你的「中间件」。\nAPI Gateway Mesh …","date":1579078800,"description":" 本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的、解决了什么问题、双十一的实践表现以及我们对未来的思考。","dir":"blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"370ccd30a2edcf559eb2c82976bcb8a0","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","publishdate":"2020-01-15T17:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","summary":"本文整理自蚂蚁金服高级技术专家贾岛在 12 月 28 日 Service Mesh Meetup 杭州站现场分享。 MOSN 完成孵化， 启用独立 Group 2020.2019.12.18，MOSN 项目负责人、","tags":["Service Mesh","MOSN","Service Mesh Meetup"],"title":"蚂蚁金服 API Gateway Mesh 思考与实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","wordcount":5174},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@李彦迎 提问：\n TCC 模式我可以作为 Saga 模式使用不？譬如 try 为空，永远成功。\n A：可以，不过应该是 confirm 为空，不是 try 为空。\n 请问 Seata 的 Saga 模式能支持 DB2 数据库吗？\n A：可以支持 DB2。\n 请教基础问题：Gateway 调用微服务 A、B，B内部失败了，补偿交易应该回退A的，这个补偿交易应该定义在微服A里面还是微服务B里面？\n A：原服务是谁提供的，补偿服务就应该谁提供。\n 请问能否 Client 用 DB2，Server 用 MySQL? Client 的必须和业务数据库保持一致吧？\n A：也可以的。是的，Client端必须与业务数据库保持一致。\n2、@米晓飞 提问：\n Saga 和现有框架有啥区别呢，优劣比较？\n A：我们在实践中发现，长流程的业务场景，往往有服务编排的需求，同时又要保证服务之间的数据一致性。目前开源社区也有一些 Saga 事务框架，也有一些服务编排的框架，但是它们要么只有 Saga 事务处理能力、要么只有服务编排能力，Seata Saga 是将这两者能力非常优雅的结合在一起，为用户提供一个简化研发、降低异常处理难度、高性能事件驱动的产品。\n3、@张春雨 提问：\n Saga 的模式补偿和 XA 回滚有啥区别呀？\n A：XA 是数据库提交的两阶段提交协议，Saga 的是需要业务层来实现的。\n Seata server 端使用 mysql 去记录事务日志,感觉性能上不是很好、 有没有其他的可替代的持久化方案吗？\n A：Seata 每个模块都设计有 SPI，持久化也一样，未来可以扩展更多持久化方式。 Seata：https://github.com/seata/seata 更多关于 Seata Saga 的内容可以看下文直播回顾。\n4、@FAN 提问：\n MOSN 的平滑升级原理是什么？跟 Nginx 和 Envoy 的区别是什么？\n A：MOSN 的平滑升级方案和 Envoy 类似，都是通过 UDS 来传递 listener fd。但是其比 Envoy 更厉害的地方在于它可以把老的连接从 Old MOSN 上迁移到 New MOSN 上。也就是说把一个连接从进程 A 迁移到进程 B，而保持连接不断！Nginx 的实现是兼容性最强的。 可以详细阅读：https://ms2008.github.io/2019/12/28/hot-upgrade/ MOSN：https://github.com/mosn/mosn\nSOFAArkLab 系列 蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析 本篇开始将正式启动SOFA:ArkLab/源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。文中附共建列表，欢迎领取共建~\nSOFAChannel 集锦 Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v3.2.2 版本，主要变更如下：\n ReadinessCheckListener 的 Order 过高 删除 jaxrs-api 依赖项 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.2.2\n","date":1578643200,"description":"【01/05-01/10】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200110/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1143431da4314982069d5d5465391dc5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200110/","publishdate":"2020-01-10T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200110/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot 发版、直播回顾、SOFAArkLab共建启动","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200110/","wordcount":1463},{"author":"屹远","categories":"Seata","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#10 直播分享整理，主题：分布式事务 Seata 长事务解决方案 Saga 模式详解。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群：23372465，不错过每场直播。\n 大家好，我是陈龙，花名: 屹远（_long187@github_），是蚂蚁金服分布式事务核心研发，也是 Seata Committer。今天分享的主题是《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\nSeata：https://github.com/seata/seata\n金融分布式应用开发的痛点 分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。\u0026amp;mdash;《左耳听风-弹力设计之“补偿事务”》\n而在金融领域微服务架构下的业务流程往往会更复杂，流程很长，比如一个互联网微贷业务流程调十几个服务很正常，再加上异常处理的流程那就更复杂了，做过金融业务开发的同学会很有体感。\n所以在金融分布式应用开发过程中我们面临一些痛点：\n 业务一致性难以保障 我们接触到的大多数业务（比如在渠道层、产品层、集成层的系统），为了保障业务最终一致性，往往会采用“补偿”的方式来做，如果没有一个协调器来支持，开发难度是比较大的，每一步都要在 catch 里去处理前面所有的“回滚”操作，这将会形成“箭头形”的代码，可读性及维护性差。或者重试异常的操作，如果重试不成功可能要转异步重试，甚至最后转人工处理。这些都给开发人员带来极大的负担，开发效率低，且容易出错。\n 业务状态难以管理 业务实体很多、实体的状态也很多，往往做完一个业务活动后就将实体的状态更新到了数据库里，没有一个状态机来管理整个状态的变迁过程，不直观，容易出错，造成业务进入一个不正确的状态。\n 业务监控运维难 业务的执行情况监控一般通过打印日志，再基于日志监控平台查看，大多数情况是没有问题的，但是如果业务出错，这些监控缺乏当时的业务上下文，对排查问题不友好，往往需要再去数据库里查。同时日志的打印也依赖于开发，容易遗漏。\n 缺乏统一的差错守护能力 对于补偿事务往往需要有“差错守护触发补偿”、“人工触发补偿”操作，没有统一的差错守护和处理规范，这些都要开发者逐个开发，负担沉重。\n理论基础 对于事务我们都知道 ACID，也很熟悉 CAP 理论最多只能满足其中两个，所以，为了提高性能，出现了 ACID 的一个变种 BASE。ACID 强调的是一致性（CAP 中的 C），而 BASE 强调的是可用性（CAP 中的 A）。在很多情况下，我们是无法做到强一致性的 ACID 的。特别是我们需要跨多个系统的时候，而且这些系统还不是由一个公司所提供的。BASE 的系统倾向于设计出更加有弹力的系统，在短时间内，就算是有数据不同步的风险，我们也应该允许新的交易可以发生，而后面我们在业务上将可能出现问题的事务通过补偿的方式处理掉，以保证最终的一致性。\n所以我们在实际开发中会进行取舍，对于更多的金融核心以上的业务系统可以采用补偿事务，补偿事务处理方面在30多年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较也公认 Saga 是作为长事务的解决方案。\n https://github.com/aphyr/dist-sagas/blob/master/sagas.pdf http://microservices.io/patterns/data/saga.html\n Saga 模式用一种非常纯朴的方式来处理一致性：补偿。上图左侧是正常的事务流程，当执行到 T3 时发生了错误，则开始执行右边的事务补偿流程，返向执行T3、T2、T1 的补偿服务，其中 C3 是 T3 的补偿服务、C2 是 T2 的补偿服务、C1 是 T1 的补偿服务，将T3、T2、T1 已经修改的数据补偿掉。\n使用场景 一些场景下，我们对数据有强一致性的需求时，会采用在业务层上需要使用“两阶段提交”这样的分布式事务方案。而在另外一些场景下，我们并不需要这么强的一致性，那就只需要保证最终一致性就可以了。\n例如蚂蚁金服目前在金融核心系统使用的就是 TCC 模式，金融核心系统的特点是一致性要求高（业务上的隔离性）、短流程、并发高。\n而在很多金融核心以上的业务（比如在渠道层、产品层、集成层的系统），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务（如金融网络）。这是如果每个服务都开发 Try、Confirm、Cancel 三个方法成本高。如果事务中有其它公司的服务，也无法要求其它公司的服务也遵循 TCC 这种开发模式。同时流程长，事务边界太长，加锁时间长，会影响并发性能。\n所以 Saga 模式的适用场景是：\n 业务流程长、业务流程多； 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口； 典型业务系统：如金融网路（与外部机构对接）、互联网微贷、渠道整合、分布式架构下服务集成等业务系统； 银行业金融机构使用广泛； 其优势：\n 一阶段提交本地事务，无锁，高性能； 参与者可异步执行，高吞吐； 补偿服务易于实现，因为一个更新操作的反向操作是比较容易理解的； 其缺点：\n 不保证隔离性，后面我们会讲到如何应对隔离性的缺失。 基于状态机引擎的 Saga 实现 基于状态机引擎的 Saga 实现的基本原理：\n 通过状态图来定义服务调用的流程并生成 json 定义文件； 状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点（虚线关联的节点）； 状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚； 异常发生时是否进行补偿也可由用户自定义决定； 可以实现服务编排需求，路由、异步、重试、参数转换、参数映射、服务执行状态判断、异常捕获等功能 ； Seata 目前的 Saga 模式采用了状态机+DSL 方案来实现，原因有以下几个：\n 状态机+DSL 方案在实际生产中应用更广泛； 可以使用 Actor 模型或 SEDA 架构等异步处理引擎来执行，提高整体吞吐量； 通常在核心系统以上层的业务系统会伴随有“服务编排”的需求，而服务编排又有事务最终一致性要求，两者很难分割开，状态机+DSL 方案可以同时满足这两个需求； 由于 Saga 模式在理论上是不保证隔离性的，在极端情况下可能由于脏写无法完成回滚操作，比如举一个极端的例子，分布式事务内先给用户 A 充值，然后给用户 B 扣减余额，如果在给A用户充值成功，在事务提交以前，A 用户把线消费掉了，如果事务发生回滚，这时则没有办法进行补偿了，有些业务场景可 …","date":1578574800,"description":"本文根据 SOFAChannel#10 直播分享整理，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用","dir":"blog/sofa-channel-10-retrospect/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2ba15ca1c710e1be2e6758950246d1ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-10-retrospect/","publishdate":"2020-01-09T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-10-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#10 直播分享整理，主题：分布式事务 Seata 长事务解决方案 Saga 模式详解。 回顾视频以及 PPT 查看","tags":["Seata","SOFAChannel"],"title":"Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-10-retrospect/","wordcount":6186},{"author":"卫恒","categories":"SOFAArk","content":" 本篇开始将正式启动 SOFAArk:Lab/ 源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。\n本文为《剖析 | SOFAArk 源码》第一篇，本篇作者卫恒，SOFAArk 开源负责人。《剖析 | SOFAArk 源码》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附共建列表，欢迎领取共建~\n 在大型软件开发过程中，通常会推荐底层功能插件化、业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。对于模块化，从语言层面，原计划在 Java7 就有的模块化特性，终于在 Java9 里面提供了。在 Java语言级对模块化提供支持之前，业界内最知名的 Java 模块化规范当属 OSGi 了，直至到今天，OSGi 在众多企业、厂商中被广泛使用，比如我们常用的 Web 应用服务器、Eclipse 等均采用了 OSGi 规范。\n蚂蚁金服内部，CE 作为使用了 10 年的\u0026amp;rdquo;元老级\u0026amp;rdquo;容器组件，见证了和支撑了每年的大促、新春红包等流量场景。作为中间件的常青树，CE 以足够的稳定性为业务保驾护航。CE 容器也是基于 OSGi 实现了模块化，但是由于 CE 背负了太多包袱，使得其自身变得太重，在云原生及商业化输出上逐渐失去了优势。\n从 2016 年底开始，框架组内部开始在 CE 的基础上进行抽离和整合，开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\nSOFAArk 简介 SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin） 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz) 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz。 SOFAArk：https://github.com/sofastack/sofa-ark\n应用场景 基于模块化及模块的动态能力，SOFAArk 有非常丰富的落地场景，如：通过从 classloader 层面解决 依赖冲突问题、基于 arkcontainer 的多应用合并部署，基于动态 biz 的 SOFAServerless 等等。\n依赖冲突 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError、NoSuchMethodError 等；实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法，统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突；这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题；如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题； OSGi 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGi 框架太过臃肿，功能繁杂；为了解决包冲突问题，引入 OSGi 框架，有牛刀杀鸡之嫌，且反而使工程变得更加复杂，不利于开发。\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 – Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如果工程需要引入两个三方包：A 和 B，但是 A 需要依赖版本号为 0.1 的 C 包，而恰好 B 需要依赖版本号为 0.2 的 C 包，且 C 包的这两个版本无法兼容：\n此时，即可使用 SOFAArk 解决该依赖冲突问题；只需要把 A 和版本为 0.1 的 C 包一起打包成一个 Ark 插件，然后让应用工程引入该插件依赖即可。\n合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 - Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成可执行 Fat Jar 时，可以将其他应用 Biz 包一并打入，启动时，则会根据优先级依次启动各应用。每个 Biz 使用独立的 BizClassLoader 加载，不需要考虑相互依赖冲突问题，Biz 之间则通过 SofaService / SofaReference JVM 服务进行交互。\n 静态合并部署是将多个应用打包在一个 ARK 可执行 JAR 包中，然后通过 java -jar 启动，这种方式可以在 ARK 容器内同时运行多个应用，对于一些资源要求不高、流量较少的应用可以使用这种方式部署以节省资源。\n 动态模块 模块是 ark biz 在动态模型场景下的一种别名，其实质就是一个 ark biz 包。\n 动态模块相对于静态合并部署最大的不同点是，运行时通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态模块的设计理念图如下：\n无论是静态合并部署还是动态模块都会有宿主应用（master biz）的概念, 如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主应用不允许被卸载，一般而言，宿主应用 …","date":1578398400,"description":" 本文为《剖析 | SOFAArk 源码》第一篇，作者卫恒","dir":"blog/sofa-ark-overview/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"56bc84e9737dbad9c77b9700b12bf63d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-overview/","publishdate":"2020-01-07T20:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-ark-overview/","summary":"本篇开始将正式启动 SOFAArk:Lab/ 源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。 本文为《剖析 | SOFAArk 源码》第一篇，本篇作者卫恒，SOFAArk 开源负责人","tags":["SOFAArk","剖析 | SOFAArk 源码 ","SOFALab"],"title":"蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析","type":"blog","url":"/sofastack.tech/blog/sofa-ark-overview/","wordcount":3810},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\nSeata：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，其中长事务解决方案 Saga 模式有着无锁高性能、异步架构高吞吐的优势。\nSeata：https://github.com/seata/seata\nSaga 状态机在线设计器：http://seata.io/saga_designer/index.html\nSaga 状态机设计器视频教程：http://seata.io/saga_designer/vedio.html\n1、@李宇博 提问：\n 您好，我这边看视频直接把 Catch 直接拖到 serviceTask 上，好像没有生效，需要连线还是配置什么属性吗？\n A：没有生效是指什么？Catch 要连一个线到一个其它的 state，意思是捕获到异常后，去执行一个分支，这个 state可以是任何类型的 state，比如 CompensationTrigger、ServiceTask，通常是 CompensationTrigger，立即触发补偿。\n 我是直接连接到 compensateTrigger 上的，然后我手动抛出异常，并没有执行补偿方法，而是在不停的重试调用之前抛出异常的方法。\n A：需要在线上配置异常类型：\n2、@J～杰 提问：\n 咨询一个问题，AT 模式分支事物注册的时候会获取锁，锁名就是和 table+主键有关系的，由于压力测试的时候，有个 check 去数据库查询同一个 rowkey，导致直接获取锁失败，在业务上就是业务失败回滚了，这种有啥办法？\n A：你的意思是热点数据问题吗？\n 可以理解成热点数据，我这边的测试场景就是下单减库存，2个微服务，库存由于基本上是同一行库存数据。\n A：热点数据撞锁是正常的，你可以用自旋锁，让其它事务等待一下再获取锁，而不是立即失败。http://seata.io/zh-cn/docs/user/configurations.html\n 本地调用 Dubbo 微服务是可以的，用 Saga 状态机就报这个问题，报服务没有提供者。\n A：你的 Service 是用的 XML 注册的还是用的注解注册的？\n 注解的方式。\n A：嗯嗯。你尝试用 XML 方法注册一个 Bean 看看行不行，机制上可能有不一样，因为 Saga 状态机是通过 getBean 反射去调方法。而 Dubbo 的注解是通过代理的方式来注入一个对象，这个对象是不是一个有完全成功的 Bean，不确定。之前我遇到过 TCC 用注解不好使，用 XML 好使的问题。\n本周推荐阅读 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 SOFARegistryLab 系列 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 蚂蚁金服服务注册中心 Session 存储策略 | SOFARegistry 解析 蚂蚁金服服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.9.0 版本，主要变更如下： i. 重构了包引用路径，从 sofastack.io/sofa-mosn 变更为 mosn.io/mosn； ii. 支持变量机制，accesslog 修改为使用变量机制获取信息； iii. 修复在 proxy 协程 panic 时导致的内存泄漏； iv. 修复在特定的场景下，读写协程卡死导致的内存泄漏； v. 修复 HTTP2 Stream 计数错误的 bug；\n详细发布报告：https://github.com/mosn/mosn/releases/tag/0.9.0\n社区直播预告 新年快乐~2020年第一期线上直播来啦，SOFAChannel#10 将和大家一起探讨 《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\n主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解\n时间：2020年1月9日（下周四）19:00-20:00\n嘉宾：陈龙（花名：屹远） 蚂蚁金服分布式事务核心研发、Seata Committer\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1578038400,"description":"【12/31-01/03】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200103/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"aa8f76ccca9d7d700e3d9b16c2b0df21","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200103/","publishdate":"2020-01-03T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200103/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 1.9直播预告、MOSN 发版、Saga 状态机设计器视频教程","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200103/","wordcount":1862},{"author":"米麒麟","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第六篇，本篇作者子懿，来自阿里云。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n前言 微服务架构为了保证所有服务可用，当服务发生问题时能及时摘除有问题的服务，需要定期检测服务可用性即健康检测。健康检测包括客户端心跳和服务端主动探测两种方式，定期发送 TCP 或 HTTP 请求根据响应确定服务是否正常。服务注册中心提供服务注册和订阅服务，在服务发布者服务信息发生变化、或者节点上下线时通知变更，动态更新消费方的服务地址列表信息，支持服务注册和下线的快速变更通知。\n本文重点围绕服务的健康检测、SOFARegistry 的健康检测以及基于 SOFARegistry 实现秒级服务注册下线等方面剖析 SOFARegistry 如何实现秒级服务上下线通知原理，阐述如何使用 SOFARegistry 对于服务的注册下线场景通过推送机制快速实现端到端的传达功能：\n 如何实现服务的健康检测？业界服务注册中心的健康机制是怎样的？SOFARegistry 的健康检测实现方式？ SOFARegistry 服务注册下线数据流转过程是怎样的？SOFARegistry 内部角色如何实现秒级服务上下线通知？ 服务的健康检测 服务的健康检测是如何实现？健康检测分为客户端心跳和服务端主动探测两种方式：\n 客户端心跳 客户端采取每隔一定时间间隔主动发送心跳方式向服务端表明自己的服务状态正常，心跳是 TCP 或者 HTTP 的形式； 通过维持客户端和服务端的 Socket 长连接自己实现客户端心跳的方式； ZooKeeper 没有主动的发送心跳，而是依赖组件本身提供的临时节点的特性，通过 ZooKeeper 连接的 Session 维持临时节点； 客户端心跳中长连接的维持和客户端的主动心跳偏重服务链路是否正常，不一定是服务状态正常；服务端主动调用服务健康检查是比较准确的方式，通过返回结果成功判断服务状态健康情况； 服务端主动探测 服务端调用服务发布者 HTTP 接口来完成健康检测； 对于没有提供 HTTP 服务的 RPC 应用，服务端调用服务发布者的接口来实现健康检测； 通过执行脚本形式来进行定时检测； 服务端主动探测依然存在问题。服务注册中心主动调用 RPC 服务的某个接口无法做到通用性；在很多场景下服务注册中心到服务发布者的网络是不通的，服务端无法主动发起健康检查； 注册中心的健康检测 业界服务注册中心的健康检测机制：\n Eureka：定期有 Renew 心跳，数据具有 TTL（Time To Live）；并且支持自定义 HealthCheck 机制，当 HealthCheck 检测出系统不健康时主动更新 Instance 的状态； Zookeeper：定期发送连接心跳以保持会话 （Session），会话本身 （Session） 具有TTL； Etcd：定期通过 HTTP 对数据进行 Refresh，数据具有 TTL。申请 Lease 租约，设置服务生存周期TTL； Consul：Agent 定期对服务进行 healthcheck，支持 HTTP/TCP/Script/Docker；由服务主动定期向 agent 更新 TTL； SOFARegistry 的健康检测 业界服务注册中心的健康检测都有个共同的关键词：“定期”。定期检测的时间周期通常设置为秒级，比如 3 秒、5 秒或 10 秒，甚至更长，也就是说服务的健康状态总是滞后的。蚂蚁金服的注册中心从最初的版本设计开始，就把健康状态的及时感知，当做一个重要的设计目标，特别是需要做到“服务宕机能被及时发现”。因此 SOFARegistry 在健康检测的设计方面决定“服务数据与服务发布者的实体连接绑定在一起，断连马上清数据”，简称此特点叫做连接敏感性。连接敏感性是指在 SOFARegistry 里所有 Client 都与 SessionServer 保持长连接，每条长连接都设置基于 SOFABolt 的连接心跳，如果长连接断连客户端立即发起重新建连，时刻保持 Client 与 SessionServer 之间可靠的连接。\nSOFARegistry 将服务数据 （PublisherRegister） 和服务发布者 （Publisher） 的连接的生命周期绑定在一起：每个 PublisherRegister 定义属性 connId，connId 由注册本次服务的 Publisher 的连接标识 （IP 和 Port）构成，也就是只要该 Publisher 和 SessionServer 断连，服务信息数据即失效。客户端重新建连成功后重新注册服务数据，重新注册的服务数据会被当成新的数据，考虑更换长连接后 Publisher 的 connId 是 Renew 新生成的。\n譬如当服务的进程宕机时，一般情况下 OS 立刻断开进程相关的连接（即发送 FIN），因此 SessionServer 能够实时感知连接断开事件，然后把该 connId 相关的所有 PublisherRegister 都清除，并且及时推送给所有服务订阅者 （Subscriber）。如果只是网络问题导致连接断开，实际的服务进程没有宕机，此时客户端立即发起重新连接 SessionServer 并且重新注册所有服务数据。对服务订阅者本身来说接收到的是服务发布者经历短暂的服务下线后以及再次重新上线。假如此过程耗时足够短暂（例如 500ms 内发生断连和重连），服务订阅者可能感受不到服务下线，因为 DataServer 内部的数据通过 mergeDatum 延迟合并变更的 Publisher 服务信息，version 是合并后最新的版本号。\n服务上下线过程 服务的上下线过程是指服务通过代码调用执行常规注册（Publisher#register） 和下线（Publisher#unregister）操作，不考虑因为服务宕机等意外情况导致的下线场景。\n“一次服务注册过程”的服务数据在 SOFARegistry 内部流转过程：\n 客户端 Client 调用服务发布者 Publisher 的 register 向 SessionServer 注册服务。 SessionServer 接收到服务数据即 PublisherRegister 写入内存 （SessionServer 存储 Client 的服务数据到内存，用于后续跟 DataServer 做定期检查）， …","date":1577955600,"description":" 本文为《剖析 | SOFARegistry 框架》第六篇，作者米麒麟","dir":"blog/sofa-registry-service-offline-notification/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"289ee5ccb8ee61cdd0a42ce60874284b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-service-offline-notification/","publishdate":"2020-01-02T17:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-service-offline-notification/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-service-offline-notification/","wordcount":4114},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解\n 活动时间：1 月 9 日周四晚 7 点\n 活动形式：线上直播\n 活动回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，其中长事务解决方案 Saga 模式有着无锁高性能、异步架构高吞吐的优势。\n本期为 SOFAChannel 线上直播第 10 期，将邀请 蚂蚁金服 分布式事务核心研发 \u0026amp;amp; Seata Committer 屹远 和大家一起探讨 《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1076\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服 Service Mesh 双十一落地详解 屹远 蚂蚁金服分布式事务核心研发、Seata Committer\n本期分享大纲： 金融分布式应用开发的痛点 Seata Saga 理论基础以及使用场景 基于状态机引擎的 Saga 实现 Seata Saga 模式最佳实践以及优势 嘉宾 SOFAGirl 主持人 屹远 蚂蚁金服分布式事务核心研发、Seata Committer ","date":1577765400,"description":"1 月 9 日周四晚 7 点，线上直播第 10 期。","dir":"activities/sofa-channel-10/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a2f7bb983d4cbad1bda1a48a3c99abb7","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-10/","publishdate":"2019-12-31T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-10/","summary":"概要 活动主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解 活动时间：1 月 9 日周四晚 7 点 活动形式：线上直播 活动回顾：戳这","tags":["SOFAChannel","Seata"],"title":"SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解","type":"activities","url":"/sofastack.tech/activities/sofa-channel-10/","wordcount":627},{"author":"董一韬、王轲","categories":null,"content":" 本文推荐知道的背景知识：\n Kubernetes 的基本原理和各大组件的职责； Serverless 计算的基本概念和它的优势； Plus: 对社区 Knative 项目的基本了解； 本文根据董一韬和王轲在 KubeCon NA 2019 大会分享整理。\n董一韬 蚂蚁金服，产品经理，致力于驱动云计算相关产品，包括云原生 PaaS 平台、容器与 Serverless 产品等，与最终顾客紧密合作，帮助客户在规模化的金融场景下采用与落地云原生相关解决方案。\n王轲 蚂蚁金服，软件工程师，建设基于 Kubernetes/Knative 的企业级 Serverless 产品，Knative 的早期使用者，Kubernetes 社区成员、控制面流控早期维护者，长期致力于用创新的方式优化、落地云原生技术。\n一. 分享概要 Knative 是 Google 主导的基于 Kubernetes 的 Serverless 平台，在社区上有较高的知名度。然而，身为社区项目的 Knative 主要关心的是标准、架构。虽有先进的理念，却离可在生产上使用有不少的差距。\n本次 KubeCon 的演讲中，来自蚂蚁金服 SOFAStack-PaaS 平台产品技术团队的隐秀和仲乐与大家分享蚂蚁金服金融科技 Knative 的实践和改造：基于 Knative 构建一个优秀的 Serverless 计算平台，详细分析如何用独特的技术，解决性能、容量、成本三大问题。\n从 Serverless 计算的应用场景开始，提炼客户真正的 Use Case，分公有云、私有云、行业云等，讲述 Serverless 计算的多种用途。之后我们将介绍在 Kubernetes 上运行 Knative 平台的方案，详细介绍要使其生产可用，不得不克服的问题。演讲最后，将刚刚的这些问题一一攻破，做出一个比社区版本优秀的 Knative 平台。\n二. 解决性能问题：使用 Pod 预热池 熟悉 Kubernetes 的同学可能知道，Kubernetes 的首要目标并不是性能。\n在一个大规模的 Kubernetes 集群下，要创建一个新的 Pod 并让它跑起来，是很慢的。这是因为这整个链路很长：先要向 APIServer 发一个 POST 请求，再要等 Scheduler 收到新 Pod 资源被创建的事件，再等 Scheduler 在所有的 Node 上运行一遍筛选、优选算法并把调度结果返回给 API Server，再到被选中 Node 的 Kubelet 收到事件，再到Docker 镜像拉取、容器运行，再到通过安全检查并把新的容器注册到 Service Mesh 上…\n任何一个步骤都有可能出现延时、丢事件，或失败（如调度时资源不足是很常见的）。就算一切都正常工作，在一个大规模的 Kubernetes 集群里，整个链路延时达到20s，也是很常见的。\n这便导致在 Kubernetes 上做 Serverless 的窘境：Serverless 的一大特点是自动扩缩容，尤其是自动从0到1，不使用时不占任何资源。但如果一个用户用 Serverless 跑自己的网站/后端，但用户的首个请求花费20s才成功，这是无法接受的。\n为了解决冷启性能问题，我们团队提出了一个创造性的解决方案：使用 Pod 预热池（Pod Pool）。\n我们的产品会预先创建许多个 Pod 并让它们运行起来，当 Kubernetes 的控制器希望创建一个新的 Pod 的时候，我们不再是从零开始新建一个 Pod，而是找到一个处于待命状态的符合条件的 Pod，并把代码注入这个 Pod，直接使用。\n在演讲中，我们分享了一定技术实现的细节，例如如何创建 CRD 并 fork Kubernetes 的 ControllerManager，来以较小的成本实现新 Workload；如何自动根据历史的使用数据来自动伸缩 Pod 池的水位；如何做代码注入等。我们提了3种方式，分别是给容器发指令让容器中的进程下载并执行代码包、使用 Ephemeral Container、魔改 Kubelet允许替换 Container。\n实际的实现比这个还要复杂，要考虑的问题更多，例如如何响应 Pod 中不同的资源 request、limit。我们实际上也实现了一个调度器。当某个预热好的 Pod 不能满足，会看那个 Pod 所在 Node 上的资源余量，如果余量够则动态改 Kubernetes 控制面数据和 cgroups，实现“垂直扩容”。\n实际操作证明，这个冷启优化的效果非常好，当 Pod 大小固定、代码包缓存存在时，启动一个最简单的 HTTP 服务器类型应用的耗时从近20秒优化到了2秒，而且由于不需要当场调度 Pod，从0到1的稳定性也提升了很多。\n这个优化主要是跳过了若干次 API Server 的交互、Pod Schedule 的过程和 Service Mesh 注册的过程，用户程序从零到一的体验得到极大的提升，又不会招致过多的额外成本。一般来讲多预留10-20个 Pod 就可以应付绝大多数情况，对于少见的短时间大量应用流量激增，最坏情况也只是 fallback 到原先的新创建 Pod 的链路。\nPod 预热池不光可以用来做冷启优化，还有很多其他的应用场景。演讲中我呼吁将这种技术标准化，来解决 Kubernetes 数据面性能的问题。会后有观众提出 cncf/wg-serverless 可能有兴趣做这件事情。\n三. 降低成本：共享控制面组件 在成本方面，我们和大家分享了多租户改造和其他的降低成本的方式。\n如果以单租户的方式运行社区版的 Knative，成本是昂贵的：需要部署 Kubernetes 控制面和 Service Mesh 控制面，因为这些都是 Knative 的依赖，Knative 本身的控制面也很占资源。十几C几十G 的机器就这样被使用了，不产生任何业务价值。因此，共享这些控制面的组件是非常必要的。\n通过共享，用户不必再单独为基础设施买单。控制面的成本也只和每个租户创建的应用的数量之和有关，而不会再和租户多少产生关联。\n我们推荐两种共享的方式，一种是 Namespace 隔离+ RBAC 权限控制，这种控制面共享的方法是最简单、Kubernetes 原生支持，也广为使用的一种方法。另一种方法是蚂蚁金服金融科技自研 Kubernetes 实现的多租户方案，通过在 etcd 中多加一级目录并把每个用户的数据存在他们自己的目录中，实现真正全方位多租户的 Kubernetes。\n演讲中还提到了其他的一些降低成本的方法，如通过 Virtual Kubelet 对接阿里云的 ECI（按需的容器服务）、通过 Cluster AutoScaler 来自动释放使用率低的 Kubernetes 节点或从阿里云购置 ECS 来增加新的节点以水平扩容等。还简单提了一下多个租户的容器共享同一个宿主机可能面临的安全问题，如 Docker 逃逸。一种可能的解决方法是使用 Kata Container（虚拟机）以避免共享 Linux 内核。\n四. 解决容量问题：每个层级都做好对分片的支持 容量方面的挑战在于当 Workload 数量增多后， …","date":1577707200,"description":" 本文基于 Knative 构建一个优秀的 Serverless 计算平台，详细分析如何用独特的技术，解决性能、容量、成本三大问题。","dir":"blog/knative-serverless-kubecon-na2019/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ceeb7bee775048b0c23fe553fc5cd335","permalink":"https://sofastack.github.io/sofastack.tech/blog/knative-serverless-kubecon-na2019/","publishdate":"2019-12-30T20:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/knative-serverless-kubecon-na2019/","summary":"本文推荐知道的背景知识： Kubernetes 的基本原理和各大组件的职责； Serverless 计算的基本概念和它的优势； Plus: 对社区 Knative 项目的基本了解； 本文根据董一韬和王轲在 KubeCon NA 2019 大会","tags":["Knative","Serverless"],"title":" 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019","type":"blog","url":"/sofastack.tech/blog/knative-serverless-kubecon-na2019/","wordcount":3400},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News SOFAStack 社区上线了 SOFA Community 试运行方案，欢迎社区内更多的同学参与我们，加入共建❤\n社区随时都欢迎各种贡献，无论是简单的错别字修正、bug 修复还是增加新功能，欢迎提 issue 或 pull request 至 Github 社区。\nSOFA Community 期待你的加入：https://www.sofastack.tech/community/\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@包和平 提问：\n 请问 Seata Saga 状态机可以跨服务来配置吗？案例中的 springcloud-eureka-feign-mybatis-seata 这个和我们的情况类似。这个默认的不是 AT 模式吗？我想使用 Saga 的状态机来配置整个流程，这个情况就涉及了三个服务 storage order account，我看 demo 中都是在单个服务中配置的状态机，所以想询问一下怎么配置。 A：可以跨服务调用，而且服务用不同的 RPC 框架也是可以的，Saga 的事例在 seata-sample 仓库有，Seata 仓库的 test 模块也有很多事例。文档地址：http://seata.io/zh-cn/docs/user/saga.html\n 有 Saga 模式的 spring feign 方式的配置 demo 吗？\n A：没有，不过 Seata Saga 只需要是一个 bean 就可以调用，理论上和什么 RPC 框架无关。\n A 服务的状态机 a_state.json 设置的子状态机是在 B 服务上配置的 b_state.json，可以这样设置吗？\n A：A 服务如果是通过状态机实现的，例如 a_state.json，这个状态机可以调用 B 服务，B 服务也可以是状态机实现的，例如 b_state.json，这两个状态机都不是子状态机，而 a_state.json 其实只知道调到了一个服务，而它内部是什么实现的它不知道。子状态机是要再同一个应用内，才可以被其它状态机调用，跨了应用，则认为只是一个服务。\n Seata 还支持其他方式实现 Saga？ 我看好像都是状态机呢，是我遗漏了哪里吗?\n A：目前是只有状态机。未来会有通过注解+拦截器实现。我所说的“A 服务如果是通过状态机实现的”，服务的实现是可以任何方式的，不是 Saga 的实现。实现一个服务，自己编码也能实现，和框架无关。\n 这个意思其实只是在 A 中调用了 feignClient 是这个意思吧?\n A：是的。\n2、@李宇博 提问：\n Saga 状态机设计器很多属性和文档不太一样呢。\n A：没有和文档不一致的属性吧。你看到的设计器生成的 json，是因为它带了布局信息，它的 stateProps 是和文档是一致的，其它属性是设计器生成的，不需要关心。\n 我没有找到 startState 属性，然后我以为要自己写 next 属性，好像是连线解决了这个问题，还有一点不太明白，就是一个事务只用设计一个 compensationTrigger么？\n A：是的，是用 Start 后面的连线解决，所以不需要 startState 属性了。 compensationTrigger 可以有任意多个，看怎么画好看就行。\n start、success、fail、choice 节点都省去了配置么？还有 compensationtrigger。\n A： Start 里有配置状态机的名称，描述，版本什么的、fail 里可以配置错误码和错误信息，succed 和 choice 应该只有一个名称，没其他的了。\n 嗯嗯，compensationTrigger 是不是也不用配置了?\n A：不用，也是 id 不重就行。\n3、@赵润泽 提问：\n TCC 模式下的事务发起者和 AT 模式下的事务发起者，被代理后执行的操作是一样的吗？\n A：TccActionInterceptor 拦截的是 TwoPhaseBusinessAction 注解也就是拦截的是分支事务，在之前 TM 已经做了 begin，这个是通过 GlobalTransactional 的 intercept 开启的。\n TCC 事务的开启和 AT 事务的开启流程是一样的吗，毕竟都是一个注解？\n A： 是一样的，都是发起方加 GlobalTransactional 注解，对于 TCC 分支来说都要额外加一个 TwoPhaseBusinessAction 注解。\n本周推荐阅读 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 社区活动预告 就在明天，Service Mesh Meetup 第9期杭州站，本期与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用，现场还有机会获得 Istio 官方 T 恤 以及 相关技术书籍。明天，不见不散~\n主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond\n时间：2019年12月28日（明天）13:00-17:30\n地点：杭州西湖区紫霞路西溪谷G座8楼\n报名方式：点击“这里”，即可报名\n","date":1577430000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191227/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"026916366f7c75abaf698dabaed81047","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191227/","publishdate":"2019-12-27T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191227/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 明日活动信息、社区方案上线、落地系列阅读","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191227/","wordcount":1949},{"author":"封尘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，本次主题主要分享在蚂蚁金服当前的体量下，控制面平稳支撑大规模 Sidecar 的落地实践。聚焦控制面核心组件 Pilot 和 Citadel，分享蚂蚁金服双十一控制面如何管理并服务好全站 Sidecar。\n本次分享主要分为两大部分，分别是：\n Pilot 落地实践； Citadel 安全加固； Pilot 落地实践 在开始分享落地实践之前，我们先来看看 Istio 的架构图：\n理想很丰满，现实很骨感。由于性能等方面的综合考虑，我们在落地过程中，将控制面的组件精简为 Pilot 和 Citadel 两个组件了，不使用因性能问题争议不断的 Mixer，不引入 Galley 来避免多一跳的开销。\n在架构图中，控制面组件 Pilot 是与 Sidecar 交互最重要的组件，负责配置转化和下发，直面 Sidecar 规模化带来的挑战。这也是双十一大促中，控制面最大的挑战。\n规模化的问题在生产实践中，是一个组件走向生产可用级的必经之路。接下来将会分别从稳定性、性能优化、监控这三个方面分别展开。\n稳定性增强 我们先梳理下 Pilot 提供的服务能力，从功能实现上来看，Pilot 是一个 Controller + gRPC Server 的服务，通过 List/Watch 各类 K8s 资源，进行整合计算生成 XDS 协议的下发内容，并提供 gRPC 接口服务。本次分享我们先把关注点放在 gRPC 接口服务这个环节，如何保证接口服务支撑大规模 Sidecar 实例，是规模化的一道难题。\n负载均衡\n要具备规模化能力，横向扩展能力是基础。Pilot 的访问方式我们采用常用的 DNSRR 方案，Sidecar 随机访问 Pilot 实例。由于是长连接访问，所以在扩容时，原有的连接没有重连，会造成负载不均。为解决这个问题，我们给 Pilot 增加了连接限流、熔断、定期重置连接功能，并配合 Sidecar 散列重连逻辑，避免产生连接风暴。\n 连接限流 为了降低大量 MOSN 同时连接同一个 Pilot 实例的风险，在 gRPC 首次连接时，Pilot 增加基于令牌桶方案的流控能力，控制新连接的处理响应，并将等待超时的连接主动断连，等待 Sidecar 下一次重连。\n 熔断 基于使用场景的压测数据，限制单实例 Pilot 同时可服务的 Sidecar 数量上限，超过熔断值的新连接会被Pilot 主动拒绝。\n 定期重置 为了实现负载均衡，对于已经存在的旧连接，应该怎么处理呢？我们选择了 Pilot 主动断开连接，不过断开连接的周期怎么定是个技术活。要考虑错开大促峰值，退避扩缩容窗口之类，这个具体值就不列出来了，大家按各自的业务场景来决定就好了。\n Sidecar 散列重连 最后还有一点是 Client 端的配合，我们会控制 Sidecar 重连 Pilot 时，采用退避式重试逻辑，避免对 DNS 和 Pilot 造成负载压力。\n性能优化 规模化的另一道难题是怎么保证服务的性能。在 Pilot 的场景，我们最关注的当然是配置下发的时效性了。性能优化离不开细节，其中部分优化是通用的，也有部分优化是面向业务场景定制的，接下来会分享下我们优化的一些细节点。\n 首次请求优化 社区方案里 Pilot 是通过 Pod.Status 来获取 Pod 的 IP 信息，在小集群的测试中，这个时间基本秒级内可以完成。然而在大集群生产环境中，我们发现 Status 的更新事件时间较慢，甚至出现超过 10s 以上的情况，而且延迟时间不稳定，会增加 Pilot 首次下发的时延。我们通过与基础设施 K8s 打通，由 PaaS 侧将 Pod 分配到的 IP 直接标记到Pod.Annotation 上，从而实现在第一次获取 Pod 事件时，就可以获取到 IP，将该环节的时延减少到0。\n 按需获取 \u0026amp;amp; Custom Resource 缓存 这是一个面向 DBMesh 业务场景的定制性优化，是基于按需获取的逻辑来实现的。其目的在于解决 DBMesh CR 数量过多，过大导致的性能问题，同时避免 Pilot 由于 List/Watch CR 资源导致 OOM 问题，Pilot 采用按需缓存和过期失效的策略来优化内存占用。  局部推送 社区方案中当 Pilot List/Watch 的资源发生变更时，会触发全部 Sidecar 的配置推送，这种方案在生产环境大规模集群下，性能开销是巨大的。举个具体例子，如果单个集群有 10W 以上的 Pod 数量，任何一个 Pod 的变更事件都会触发全部 Sidecar 的下发，这样的性能开销是不可接受的。\n优化的思路也比较简单，如果能够控制下发范围，那就可以将配置下发限制在需要感知变更的 Sidecar 范围里。为此，我们定义了 ScopeConfig CRD 用于描述各类资源信息与哪些 Pod 相关，这样 Pilot 就可以预先计算出配置变更的影响范围，然后只针对受影响的 Sidecar 推送配置。\n 其他优化 强管控能力是大促基本配备，我们给 Pilot Admin API 补充了一些额外能力，支持动态变更推送频率、推送限流、日志级别等功能。\n监控能力 安全生产的基本要求是要具备快速定位和及时止血能力，那么对于 Pilot 来说，我们需要关注的核心功能是配置下发能力，该能力有两个核心监控指标：\n 下发时效性 针对下发的时效性，我们在社区的基础上补充完善了部分下发性能指标，如下发的配置大小分布，下发时延等。\n 配置准确性 而对于配置准确性验证是相对比较复杂的，因为配置的准确性需要依赖 Sidecar 和 Pilot 的配置双方进行检验，因此我们在控制面里引入了 Inspector 组件，定位于配置巡检，版本扫描等运维相关功能模块。\n配置巡检的流程如下：\n Pilot 下发配置时，将配置的摘要信息与配置内容同步下发； MOSN 接收配置时，缓存新配置的摘要信息，并通过 Admin API 暴露查询接口； Inspector 基于控制面的 CR 和 Pod 等信息，计算出对应 MOSN 的配置摘要信息，然后请求 MOSN 接口，对比配置摘要信息是否一致； 由于 Sidecar 的数量较大，Inspector 在巡检时，支持基于不同的巡检策略执行。大体可以分为以下两类：\n 周期性自动巡检，一般使用抽样巡检； SRE 主动触发检查机制； Citadel 安全方案 证书方案 Sidecar 基于社区 SDS 方案 （Secret Discovery Service），支持证书动态发现和热更新能力。同时蚂蚁金服是一家金融科技公司，对安全有更高的要求，不使用 Citadel 的证书自签发能力，而是通过对接内部 KMS 系统获取证书。同时提供证书缓存和证书推送更新能力。\n我们先来看看架构图，请看图：\n对整 …","date":1577271600,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，聚焦控制面核心组件 Pilot 和 Citadel，分享蚂蚁金服双十一控制面如何管理并服务好全站 Sidecar。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f7e9ad6fafaa6db46864cf0704d2b145","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","publishdate":"2019-12-25T19:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","wordcount":3783},{"author":"徐迪、张晓宇","categories":null,"content":" 图为 KubeCon NA 2019 大会分享现场照\nSpeaker:\n 徐迪 蚂蚁金服技术专家：负责蚂蚁金融云PaaS平台建设，Kubernetes 社区老兵，核心代码库贡献量社区前50； 张晓宇 阿里云技术专家：负责阿里巴巴云原生应用容器平台的生态建设，主要设计和研发节点稳定性和资源利用率相关解决方案，同时也是 Kubernetes 社区热心的成员和贡献者。 本文根据徐迪和张晓宇在 KubeCon NA2019 大会分享整理。分享将会从以下几个方面进行切入：首先会简单介绍一下什么是 Sidecar 容器；其次，我们会分享几个蚂蚁金服和阿里巴巴集团的通用场景，以及我们是如何解决这些挑战的。当然，现在还是有很多的挑战需要后续继续解决，邀请大家与我们一同努力。\nSidecar 简介 Sidecar 容器并不是一个新鲜事物。它是一种设计模式，主要用来做一些辅助的工作，比如网络连通性、下载拷贝文件之类的事情；如果大家熟悉 Docker Swarm 的话，就会发现 Docker Ambassador 其实就是 Sidecar。\n看看如上这个例子，Service Consumer 和 Redis Provider 强耦合，部署在同一个节点上。如果这个时候，Redis Provider 出现问题，需要连接到另外一个 Redis 实例上，需要重新配置，并重启 Service Provider。\n那么在引入了 Ambassador 以后，问题变得相对简单些，只需要重启这里的 Redis Ambassador 即可，并不需要 Service Consumer 进行任何变动。\n当然这种模式，还可以进行跨节点通信，比如下图。这样 Service Consumer 和 Redis Provider 就可以部署在不同的节点上。在某种程度上，很容易地就将两种服务进行了解耦。\nSidecar 案例分享 Sidecar 容器能用来干什么？ 一般来讲，Sidecar 容器可以：\n 日志代理/转发，例如 fluentd； Service Mesh，比如 Istio，Linkerd； 代理，比如 Docker Ambassador； 探活：检查某些组件是不是正常工作； 其他辅助性的工作，比如拷贝文件，下载文件等； \u0026amp;hellip; 仅此而已？ 事实上，Sidecar 越来越被大家接受，并且使用越来越广泛。Sidecar 容器通常和业务容器（非 Sidecar 容器）部署在同一个 Pod 里，共享相同的生命周期，为业务容器提供辅助功能。这是一个非常好的模式，能够极大程度解耦应用，并且支持异构组件，降低技术壁垒。\n但目前 Kubernetes 对 Sidecar 的管理还不完善，越来越不满足我们的使用，尤其是在生产环境中使用 Sidecar。\n几个典型案例 1. 顺序依赖 假设我们在一个 Pod 内注入了多个 Sidecar，但是 Sidecar 之间或者 Sidecar 和业务容器之间有相互依赖关系。\n如下这个例子，我们需要先启动 proxy Sidecar 容器用于建立网络连接，这样 mysql client 才能连接到远端的 mysql 集群，并在本地暴露服务。而后主的业务容器才能正常工作。\n#1 proxy_container (sidecar) #2 mysql_client #3 svc_container 当然，有的人会觉得这个地方，可以通过诸如更改镜像启动脚本延迟启动等方法来解决。但是这些方法侵入性太强，不利于扩展，还很难进行准确的配置。\n2. Sidecar 管理 我们来看看另外一个案例。Sidecar 容器和业务容器耦合在同一个 Pod 内，共享相同的生命周期。因此，单独来管控 Sidecar 容器非常不方，比如更新 Sidecar 的镜像。\n比如，我们已经给很多 Pod 注入了 Istio Proxy 这样的 Sidecar 容器，目前运行状态良好。但是如果这个时候我们想升级这个 Proxy 镜像的话，该怎么办？\n如果按照 Istio 社区官方的文档，我们需要重新注入这些 Sidecar 容器。具体来说，需要删除原有 Pod，重新生成一份新的 Pod（有些 workload 关联的 Pod，会由相应的 workload 控制器自动生成）。\n那如果我们有很多个这样的 Pod 需要处理的话，怎么办？通过命令行的话，太不方便，而且容易出错。通过自己单独写的代码的话，可扩展性是个问题，需要频繁更改这些代码。\n而且这里还有另外一个问题，我们肯定不会一下子升级所有的 Sidecar，肯定要有个灰度的过程，也就是只升级一部分 Sidecar，这个时候又该怎么办呢？\n社区进展 上游社区 这里我们非常感谢 Joseph Irving (@Joseph-Irving) 提出了一个 Sidecar kep，通过定义 LifecycleType 来区分是否是 Sidecar 容器。\ntype Lifecycle struct { // Type // One of Standard, Sidecar. // Defaults to Standard // +optional Type LifecycleType `json:\u0026amp;quot;type,omitempty\u0026amp;quot; protobuf:\u0026amp;quot;bytes,3,opt,name=type,casttype=LifecycleType\u0026amp;quot;` } // LifecycleType describes the lifecycle behaviour of the container type LifecycleType string const ( // LifecycleTypeStandard is the default container lifecycle behaviour LifecycleTypeStandard LifecycleType = \u0026amp;quot;Standard\u0026amp;quot; // LifecycleTypeSidecar means that the container will start up before standard containers and be terminated after LifecycleTypeSidecar LifecycleType = \u0026amp;quot;Sidecar\u0026amp;quot; ) 未来只需要在 Pod Spec 中，按如下方式标记即可：\nname: sidecarContainer image: foo lifecycle: type: Sidecar Pod 内容器的启动顺序按照：初始化容器-\u0026amp;gt;Sidecar 容器-\u0026amp;gt;业务容器 的顺序依次启动。\n其中上述 kep 的 kubelet 端实现 正在进行中。\n为了支持 Sidecar 更多的使用场景，我们以此为基础提出了 PreSidecar 和 PostSidecar，分别用于在业务容器之前和之后启动。具体的使用场景见 我们的 PR。\n为什么我们觉得 Sidecar 应该区分前置和后置呢？\n这是因为在一些场景下， …","date":1577188800,"description":" 本文主要介绍了什么是 Sidecar 容器，蚂蚁金服和阿里巴巴集团的通用场景，以及我们是如何解决这些挑战的。","dir":"blog/sidacar-kubecon-na2019/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"db0769ed83607e39fba6020d4eba87b8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sidacar-kubecon-na2019/","publishdate":"2019-12-24T20:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sidacar-kubecon-na2019/","summary":"图为 KubeCon NA 2019 大会分享现场照 Speaker: 徐迪 蚂蚁金服技术专家：负责蚂蚁金融云PaaS平台建设，Kubernetes 社区老兵，核心代码库贡献量社区前50； 张","tags":["Sidecar 容器"],"title":" 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019","type":"blog","url":"/sofastack.tech/blog/sidacar-kubecon-na2019/","wordcount":2993},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@番番 提问：\n MOSN 的配置信息在哪里呢？\n A：MOSN 配置信息已更新到文档中：https://www.sofastack.tech/projects/sofa-mosn/configuration/overview/\n2、@古月 提问：\n 请问 SOFARPC 服务注册 ip 怎么使用主机 ip，不使用分配给容器的 ip？开发时调用容器内的服务调用不到，容器内的服务注册 ip 为 docker 分配的 ip。\n A：https://www.sofastack.tech/projects/sofa-rpc/application-rpc-config/ com.alipay.sofa.rpc.enabled.ip.range # 多网卡 ip 范围 com.alipay.sofa.rpc.bind.network.interface # 绑定网卡 可以通过网卡/ip段过滤；\nSOFARPC：https://github.com/sofastack/sofa-rpc\n SOFABoot 的服务运行在容器内，注册到注册中心的 ip 为容器的 ip，开发机器的调用不到。\n A：下面的两个参数，容器内端口映射到宿主机，virtual.host 用宿主机的去注册， com.alipay.sofa.rpc.virtual.host com.alipay.sofa.rpc.virtual.port\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@聂风 提问：\n SpringCloud 的项目怎么迁移到 SOFA 有这方面的教程文档吗？\n A：可以先参考下这个工程 https://github.com/sofastack/spring-cloud-sofastack-samples ，SOFAStack 集成 SpringCloud 的案例工程，不知道是不是对你有帮助。\n4、@周小斌 提问：\n Seata 以后会考虑集成分库分表和读写分离功能吗（无业务入侵的方式）？\n A：一般是分库分表组件内部中集成 Seata，负载均衡本质上是在切换数据源，一种是通过 DB URL 这种对外是个黑盒，Seata 不需要关注。另外一种是分库分表组件中使用配置中心做对等库物理库配置，这种需要通过 Resource 的 Group 来定义，比如我在一个节点上执行完一阶段，但是在进行二阶段的时候进行了主备切换，这时候需要在新主节点完成回滚。\n5、@温明磊 提问：\n Saga 项目开启时间长了后，会报 java.sql.SQLException: No operations allowed after statement closed. 这个错误。这个类 DbAndReportTcStateLogStore 方法 recordStateMachineStarted。\n A：是不是因为你的数据源连接池配置有问题呢？可能没有配置 testOnBorrow 或者 testOnReturn。\n 是没有。\n A：你配置一个 testOnBorrow。\n 那能不能在数据库连接的代码里判断，还是必须配置 testOnBorrow？Seata Saga 的数据库连接那代码处理异常。\n A：testOnBorrow 是数据源连接池的配置，和 Seata Saga 无关的，连接池你可以用任何连接池，比如 durid，dbcp。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服 ZSearch 在向量检索上的探索 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.8.0 版本，主要变更如下：\n 重构 futex 实现，增加 FUTEX_REQUEUE 支持 支持 SGX 远程证明 增加 sendmsg 和 recvmsg 系统调用 增加 gRPC demo 增加 Intel OpenVINO demo 增加 SGX 远程证明 demo 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.8.0\n2、发布 SOFABolt v1.6.1 版本，主要变更如下：\n 支持 SSL 支持 UserProcessor 生命周期的方法 支持用户自定义 SO_SND_BUF 和 SO_RCV_BUF 支持 RejectedException 的处理策略 优化了生命周期的检查，避免组件在关闭或启动前后仍然能够提供服务 优化了 DefaultConnectionManager 的构造方法以及其它的部分代码 修复 DefaultConnectionManager#check(Connection) 异常信息不完整的问题 修复 AbstractLifeCycle 启动/关闭的并发问题 详细发布报告： https://github.com/sofastack/sofa-bolt/releases/tag/v1.6.1\n社区活动预告 下周六 Service Mesh Meetup 第9期杭州站来啦，本期与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。欢迎参加~\n主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond\n时间：2019年12月28日（下周六）13:00-17:30\n地点：杭州西湖区紫霞路西溪谷G座8楼\n报名方式：点击“这里”，即可报名\n","date":1576825200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191220/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c9e61e735545e48bd341dd6da7310440","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191220/","publishdate":"2019-12-20T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191220/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 配置文档、SOFABolt 等组件发布、社区活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191220/","wordcount":1781},{"author":"十倍","categories":null,"content":" 图为 ZSearch 基础架构负责人十倍 2019 Elastic Dev Day 现场分享\n引言 ElasticSearch（简称 ES）是一个非常受欢迎的分布式全文检索系统，常用于数据分析，搜索，多维过滤等场景。蚂蚁金服从2017年开始向内部业务方提供 ElasticSearch 服务，我们在蚂蚁金服的金融级场景下，总结了不少经验，此次主要给大家分享我们在向量检索上的探索。\nElasticSearch 的痛点 ElasticSearch 广泛应用于蚂蚁金服内部的日志分析、多维分析、搜索等场景。当我们的 ElasticSearch 集群越来越多，用户场景越来越丰富，我们会面临越来越多的痛点：\n 如何管理集群； 如何方便用户接入和管理用户； 如何支持用户不同的个性化需求； \u0026amp;hellip; 为了解决这些痛点，我们开发了 ZSearch 通用搜索平台：\n 基于 K8s 底座，快速创建 ZSearch 组件，快捷运维，故障机自动替换； 跨机房复制，重要业务方高保； 插件平台，用户自定义插件热加载； SmartSearch 简化用户搜索，开箱即用； Router 配合 ES 内部多租户插件，提高资源利用率； 向量检索需求 基于 ElasticSearch 的通用搜索平台 ZSearch 日趋完善，用户越来越多，场景更加丰富。\n随着业务的飞速发展，对于搜索的需求也会增加，比如：搜索图片、语音、相似向量。\n为了解决这个需求，我们是加入一个向量检索引擎还是扩展 ElasticSearch 的能力使其支持向量检索呢？\n我们选择了后者，因为这样我们可以更方便的利用 ElasticSearch 良好的插件规范、丰富的查询函数、分布式可扩展的能力。\n接下来，我来给大家介绍向量检索的基本概念和我们在这上面的实践。\n向量检索基本概念 向量从表现形式上就是一个一维数组。我们需要解决的问题是使用下面的公式度量距离寻找最相似的 K 个向量。\n 欧式距离： 两点间的真实距离，值越小，说明距离越近； 余弦距离： 就是两个向量围成夹角的 cosine 值，cosine 值越大，越相似； 汉明距离： 一般作用于二值化向量，二值化的意思是向量的每一列只有0或者1两种取值。 汉明距离的值就两个向量每列数值的异或和，值越小说明越相似，一般用于图片识别； 杰卡德相似系数： 把向量作为一个集合，所以它可以不仅仅是数字代表，也可以是其他编码，比如词，该值越大说明越相似，一般用于相似语句识别； 因为向量检索场景的向量都是维度很高的，比如256，512位等，计算量很大，所以接下来介绍相应的算法去实现 topN 的相似度召回。\n向量检索算法 KNN 算法 KNN 算法表示的是准确的召回 topK 的向量，这里主要有两种算法，一种是 KDTtree，一种是 Brute Force。我们首先分析了 KDTree 的算法，发现 KDTree 并不适合高维向量召回，于是我们实现的 ES 的 Brute Force 插件，并使用了一些 Java 技巧进行加速运算。\nKDTree 算法 简单来讲，就是把数据按照平面分割，并构造二叉树代表这种分割，在检索的时候，可以通过剪枝减少搜索次数。\n构建树\n以二维平面点(x,y)的集合(2,3)，(5,4)，(9,6)，(4,7)，(8,1)，(7,2)为例：\n图片来源\n 按照 x 排序，确定中间值7，其他坐标分两边； 第二层按照 y 排序，第三层按照 x 排序； 并且在构建时维护每个节点中的 x 最大最小，y 最大最小四个值； 查找最近点\n图片来源\n搜索(3,5)的最近邻：\n 到根节点距离为5； 遍历到右节点(9,6)，发现整棵右子树的x轴，最小值是8，所以所有右子树的节点到查询节点的距离一定都大于8-3=5，于是所有右子树的节点都不需要遍历； 同理，在左子树，跟(5，4)节点比较，(7,2)被排除； 遍历完(2,3),(4,7)，最近点(5,4) 返回； 结论 Lucene 中实现了 BKDTree，可以理解为分块的 KDTree，并且从源码中可以看到 MAX_DIMS = 8，因为 KDTree 的查询复杂度为 O(kn^((k-1)/k))，k 表示维度，n 表示数据量。说明 k 越大，复杂度越接近于线性，所以它并不适合高维向量召回。\nBrute Force 顾名思义，就是暴力比对每一条向量的距离，我们使用 BinaryDocValues 实现了 ES 上的 BF 插件。更进一步，我们要加速计算，所以使用了 JAVA Vector API 。JAVA Vector API 是在 openJDK project Panama 项目中的，它使用了 SIMD 指令优化。\n结论 使用 avx2 指令优化，100w 的 256 维向量，单分片比对，RT 在 260ms，是常规 BF 的 1/6。 ElasticSearch 官方在7.3版本也发布了向量检索功能，底层也是基于 Lucene 的 BinaryDocValues，并且它还集成入了 painless 语法中，使用起来更加灵活。\nANN 算法 可以看到 KNN 的算法会随着数据的增长，时间复杂度也是线性增长。例如在推荐场景中，需要更快的响应时间，允许损失一些召回率。\nANN 的意思就是近似 K 邻近，不一定会召回全部的最近点。ANN 的算法较多，有开源的 ES ANN 插件实现的包括以下这些：\n 基于 Hash 的 LSH； 基于编码的 IVFPQ； 基于图的 HNSW； ZSearch 依据自己的业务场景也开发了 ANN 插件（适配达摩院 Proxima 向量检索引擎的 HNSW 算法）。\nLSH 算法 Local Sensitive Hashing 局部敏感 hash，我们可以把向量通过平面分割做 hash。例如下面图例，0表示点在平面的左侧，1表示点在平面的右侧，然后对向量进行多次 hash，可以看到 hash 值相同的点都比较靠近，所以在 hash 以后，我们只需要计算 hash 值类似的向量，就能较准确的召回 topK。\nIVF-PQ 算法 PQ 是一种编码，例如图中的128维向量，先把向量分成4份，对每一份数据做 kmeans 聚类，每份聚类出256个聚类中心，这样，原始向量就可以使用聚类中心的编号重新编码，可以看出，现在表示一个向量，只需要用4个字节就行。然后当然要记录下聚类中心的向量，它被称之为码本。\n图片来源\nPQ 编码压缩后，要取得好的效果，查询量还是很大，所以前面可以加一层粗过滤，如图，把向量先用 kmeans 聚类成1024个类中心，构成倒排索引，并且计算出每个原始向量与其中心的残差后，对这个残差数据集进行 PQ 量化。用 PQ 处理残差，而不是原始数据的原因是残差的方差能量比原始数据的方差能量要小。\n这样在查询的时候，我们先找出查询出靠近查询向量的几个中心点，然后再在这些中心点中去计算 PQ 量化后的 top 向量，最后把过滤出来的向量再做一次精确计算，返回 topN 结果。\n图片来源\nHNSW 算法 讲 HNSW 算法之前，我们先来讲 NSW 算法，如下图，它是一个顺序构建图流程：\n 例如第5次构造 D …","date":1576670400,"description":" 本文整理自 2019 Elastic Dev Day 现场分享，主要给大家分享蚂蚁金服在向量检索上的探索。","dir":"blog/antfin-zsearch-vector-search/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"194a0b7104c5147b2fd54e8c74b17e22","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-zsearch-vector-search/","publishdate":"2019-12-18T20:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/antfin-zsearch-vector-search/","summary":"图为 ZSearch 基础架构负责人十倍 2019 Elastic Dev Day 现场分享 引言 ElasticSearch（简称 ES）是一个非常受欢迎的分布式全文检索系统，常用于数据分析，搜索","tags":["ZSearch"],"title":" 蚂蚁金服 ZSearch 在向量检索上的探索","type":"blog","url":"/sofastack.tech/blog/antfin-zsearch-vector-search/","wordcount":4634},{"author":"应明","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第六篇 - Operator 篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 是蚂蚁金服下一代技术架构的核心，也是蚂蚁金服内部双十一应用云化的重要一环，本文主要分享在蚂蚁金服当前的体量下，如何支撑应用从现有微服务体系大规模演进到 Service Mesh 架构并平稳落地。\n本文作者：杜宏伟（花名：应明），蚂蚁金服技术专家，关注 API 网关，Service Mesh 和容器网络，蚂蚁金服 Service Mesh 核心成员。\n为什么需要 Service Mesh 在此之前，SOFAStack 作为蚂蚁金服微服务体系下服务治理的核心技术栈，通过提供 Cloud Engine 应用容器、SOFABoot 编程框架（已开源）、SOFARPC（已开源） 等中间件，来实现服务发现和流量管控等能力。经过若干年的严苛金融场景的锤炼，SOFAStack 已经具备极高的可靠性和可扩展性，通过开源共建，也已形成了良好的社区生态，能够与其他开源组件相互替换和集成。在研发迭代上，中间件类库已经与业务解耦，不过避免不了的是，运行时两者在同一个进程内，意味着基础库的升级需要推动业务方升级对应的中间件版本。\n我们一直在探索更好的技术实现方式。我们发现，Service Mesh 通过将原先通过类库形式提供的服务治理能力进行提炼和优化后，下沉到与业务进程协同，但独立运行的 Sidecar Proxy 进程中，大量的 Sidecar Proxy 构成了一张规模庞大的服务网络，为业务提供一致的，高质量的用户体验的同时，也实现了服务治理能力在业务无感的条件下独立进行版本迭代的目标。\n应用 Service Mesh 的挑战 Service Mesh 带给我们的能力很美好，但现实为我们带来的挑战同样很多。比方说数据面技术选型和私有协议支持，控制面与蚂蚁金服内部现有系统对接，配套监控运维体系建设，以及在调用链路增加两跳的情况下如何优化请求延迟和资源使用率等等。\n本文着重从 MOSN（Sidecar Proxy）的运维和风险管控方面，分享我们的实践经验，其他方面的挑战及应对方案，请参考系列分享中的其他文章。\nMOSN：https://github.com/sofastack/sofa-mosn\nSidecar 注入 创建注入 已经完成容器化改造，运行在 Kubernetes 中的应用，如何接入到 Service Mesh 体系中？最简单的方式，也是以 Istio 为代表的 Service Mesh 社区方案所采用的方式，即是在应用发布阶段，通过 mutating webhook 拦截 Pod 创建请求，在原始 Pod Spec 的基础上，为 Pod 注入一个新的 MOSN 容器。\n值得注意的是，在资源分配上，起初我们依据经验值，在应用 8G 内存的场景下，为 Sidecar 分配 512M 内存，即：\nApp: req=8G, limit=8G Sidecar: req=512M, limit=512M\n很快我们就发现了这种分配方案带来的问题，一方面部分流量比较高的应用的 MOSN 容器，出现了严重的内存不足甚至 OOM；另一方面注入进去的 Sidecar 容器额外向调度器申请了一部分内存资源，这部分资源脱离了业务的 quota 管控。\n因此，为了消除内存 OOM 风险和避免业务资源容量规划上的偏差，我们制定了新的“共享内存”策略。在这个策略下，Sidecar 的内存 request 被置为0，不再向调度器额外申请资源；同时 limit 被设置为应用的 1/4，保障 Sidecar 在正常运行的情况下，有充足的内存可用。为了确实达到“共享”的效果，蚂蚁金服 sigma 团队针对 kubelet 做了调整，使之在设置 Sidecar 容器 cgroups limit 为应用 1\u0026amp;frasl;4 的同时，保证整个 Pod 的 limit 没有额外增加（细节这里不展开）。\n当然，Sidecar 与应用“共享”分配到的内存资源，也导致了在异常情况（比如内存泄露）下，sidecar 跟应用抢内存资源的风险。如何应对这个风险？我们的做法是，通过扩展 Pod Spec（及相应的 apiserver, kubelet 链路），我们为 Sidecar 容器额外设置了 Linux oom_score_adj 这个属性，以保障在内存耗尽的情况下，Sidecar 容器会被 OOM Killer 更优先选中，以发挥 sidecar 比应用能够更快速重启，从而更快恢复到正常服务的优势。\n此外，在 CPU 资源的分配上，我们也遇到过在一些场景下，MOSN 抢占不到 CPU 资源从而导致请求延迟大幅抖动，解决方案是确保在注入 Sidecar 时，根据 Pod 内的容器数量，为每个 Sidecar 容器计算出相应的 cpushare 权重，并通过工具扫描并修复全站所有未正确设置的 Pod。\n原地注入 在创建 Pod 的时候注入 Sidecar，是一件相对比较“舒服“的接入方式，因为这种做法，操作起来相对比较简单，应用只需先扩容，再缩容，就可以逐步用带有 Sidecar 的 Pod，替换掉旧的没有 Sidecar 的 Pod。可问题是，在大量应用，大规模接入的时候，需要集群有较大的资源 buffer 来供应用实例进行滚动替换，否则替换过程将变得十分艰难且漫长。而蚂蚁金服走向云原生的目标之一则是，双十一大促不加机器，提高机器使用率。如果说我们要花更多的钱购买更多的机器来支持云原生，就多少有点事与愿违了。\n为了解决这个问题，我们提出了“原地注入”的概念，也就是说在 Pod 不销毁，不重建的情况下，原地把 Sidecar 注入进去。\n如图所示，原地注入由以下步骤构成：\n 在 PaaS 提交工单，选择一批需要原地注入的 Pod； PaaS 调用中间件接口，关闭业务流量并停止应用容器； PaaS 以 annotation 的形式打开 Pod 上的原地注入开关； Operator 观察到 Pod 原地注入开关打开，渲染 sidecar 模版，注入到 Pod 中并调整 cpu/memory 等参数； Operator 将 Pod 内容器期望状态置为运行； kubelet 将 Pod 内容器重新拉起； PaaS 调用中间件接口，打开业务流量； Sidecar 升级 我们将 RPC 等能力从基础库下沉到 Sidecar 之后，基础库升级与业务绑定的问题虽然消除了，但是这部分能力的迭代需求依然存在，只是从升级基础库变成了如何升级 Sidecar。\n最简单的升级就是替换，即销毁 Pod 重新创建出一个新的，这样新建出来的 Pod 所注入的 Sidecar 自然就是新版本了。但通过替换的升级方式，与创建注入存在相似的问题，就是需要大量的资源 buffer，并且，这种升级方式对业务的影响最大，也最慢。\n非平滑升级 为了避免销毁重建 Pod，我们通过 Operator 实现了“非平滑升级” …","date":1576501200,"description":" 本文着重从 MOSN（Sidecar Proxy）的运维和风险管控方面，分享我们的实践经验。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3528d4d6bd82bd170eccd20d98f5f7e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","publishdate":"2019-12-16T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第六篇 - Operator 篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模","tags":["Service mesh","Service Mesh 落地实践"],"title":" 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","wordcount":3725},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@温明磊 提问：\n 我用的 ShardingSqhere 分库分表，按照各个业务方分库。\u0026amp;gt; 所以我们项目里所有分库的表都带了业务方字段biz_code，这个字段的值也就是虚库的名字，都是写在配置里的。 A：从你的需求看，比较简单只是需要按业务方进行分库，而 biz_code 不在状态机日志表的字段里，你可以考虑先算好分库位，然后用 ShadingJDBC 的 hint 功能来设置分库位即可。\n A：我看了一下 ShardingJDBC 也是用的 ThreadLocal 来设置 hint：https://shardingsphere.apache.org/document/current/cn/manual/sharding-jdbc/usage/hint/\n ShadingJDBC 的 hint 功能是基于 ThreadLocal 的，Saga 异步的方式不能用 sharding jdbc 的吗?\n A：有一个优雅的办法：你实现 StateLogStore 接口，然后代理 Seata Saga 的DbAndReportTcStateLogStore，在每个方法前后加上：hintManager.addDatabaseShardingValue();、hintManager.close()，这样就和同步异步没有关系了，因为设置 hint 和 sql 执行都在同一个线程。\n另外，DbAndReportTcStateLogStore 如何传到你自己实现的 StateLogStore 里，你需要继承 DbStateMachineConfig，然后在 afterProperties 方法，先调 super.afterProperties 方法，然后 getStateLogStore()，传入你自己实现的 StateLogStore 里，然后把自己实现的 StateLogStore 调 setStateLogStore 覆盖。\n2、@Purge yao 提问：\n Saga 状态机在线设计器： http://seata.io/saga_designer/index.html 这个状态机可以让流程引擎用吗？\n A：不可以当工作流用，没有人工节点。\n Seata 用这个流程是干嘛用的？\n A：事实上 Seata Saga 模式 是一个具备“服务编排”和“Saga 分布式事务”能力的产品，总结下来它的适用场景是：\n 适用于微服务架构下的“长事务”处理； 适用于微服务架构下的“服务编排”需求； 适用于金融核心系统以上的有大量组合服务的业务系统（比如在渠道层、产品层、集成层的系统）； 适用于业务流程中需要集成遗留系统或外部机构提供的服务的场景（这些服务不可变不能对其提出改造要求）。 Seata：https://github.com/seata/seata\n3、@anorqiu9 提问：\n 关于 MOSN 我们目前遇到一个架构方面的问题，就是原基于 Dubbo 的服务和现在基于 Spring Cloud 的服务互调如何做？一种方案设计服务同时开启两个服务框架的服务接口为两个框架的服务同时提供服务;另一种方案是异构系统基于网关交互.这两种方案有什么优缺点？大家有没有碰到过类似的场景，是如何处理的？谢谢！\n A：Dubbo 和 Spring Cloud 互相调用，需要使用的是 http 接口来调用，个人推荐用网关来做交互，这样 API 的管理上更方便，当然也可以通过 Sidecar 来解决。\n 是的，我也倾向于网关交互，由网关完成协议的转换，进行包括流量控制、安全访问控制等在内的 API 管理工作。如果一个服务同时处于两种服务框架治理之下，就意味着对这个服务的治理（如限流、熔断及安全访问等）必须在两个地方进行，这将会是一个挑战。 当然，如果使用 Service Mesh 架构，通过 Sidecar 如 MOSN 来实现多 RPC 协议的支持，同时又能通过 Service Mesh 的控制平面实现服务治理的统一，这样就不存在上述说的挑战。 MOSN：https://github.com/sofastack/sofa-mosn\n 本周推荐阅读 蚂蚁金服 DB Mesh 的探索与实践 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布SOFARPC v5.6.3，主要变更如下：\n 试验性支持 grpc； 试验性支持 H2 的 tls； 序列化方式支持 msgpack； 修复直接通过线程上下文指定的地址调用； 扩展加载过程日志改为 debug，防止错误信息过多； 升级 jackson 和 netty 的小版本； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.3\n2、发布 SOFAArk v1.1.0，主要变更如下：\n 支持在 Biz 中使用 Ark 扩展点机制； 修复遗漏处理加载 ark spi 类资源 bug； 提供全新的biz/plugin 生命周期事件； 优化SOFAArk 自身日志输出； 优化 SOFAArk 与 SOFABoot 日志依赖管控； telnet 服务支持退出指令； 升级 netty 版本到 4.1.42.Final； 迁移 sofa-ark-samples 到 https://github.com/sofastack-guides/sofa-ark-samples 详细发布报告： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.0\n3、发布 SOFABoot v3.2.1，主要变更如下：\n 版本升级： …","date":1576220400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191213/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"37b96cc1a849775521b4d2b78d6602ce","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191213/","publishdate":"2019-12-13T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191213/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"活动报名、本周 QA、组件发布 | SOFA Weekly","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191213/","wordcount":2258},{"author":"潘潘","categories":"Service Mesh","content":" 概要 活动主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond 活动时间：时间：2019 年 12 月 28 日（周六）13:00-17:30 活动地点：杭州西湖区紫霞路西溪谷G座8楼 活动形式：线下活动 活动回顾：请戳这里 活动介绍 关于 Service Mesh\n服务网格（Service Mesh）是致力于解决服务间通讯的基础设施层。它负责在现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，Service Mesh 通常是通过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一起来实现，而无需感知应用程序本身。\n关于 ServiceMesher 社区\nServiceMesher 社区，专注于 Service Mesh 和云原生技术，立足开源，分享技术资讯和实践，致力于新技术的推广和普及。\nService Mesh Meetup #9 杭州站\nService Mesh Meetup 是由蚂蚁金服联合 CNCF 官方共同出品，ServiceMesher 社区主办，主题围绕服务网格、Kubernetes 及云原生，在全国各地循环举办的技术沙龙。\n本期 Meetup 与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。\n活动议程 时间 环节（分享主题） 分享嘉宾 13:00-13:30 签到 13:30-14:15 《蚂蚁金服 API Gateway Mesh 的思考与实践》 贾岛 蚂蚁金服 高级技术专家 14:15-15:00 《酷家乐的 Istio 与 Knative 踩坑实录》 付铖 酷家乐 容器化负责人 15:00-15:10 MOSN 社区化发布 涵畅 15:10-15:20 茶歇 15:20-16:00 圆桌环节-《Service Mesh 落地的务实与创新》 鲁直 16:00-16:45 《蚂蚁金服 Service Mesh 技术风险思考和实践》 嘉祁 蚂蚁金服 技术专家 16:45-17:30 《网易严选的 Service Mesh 实践》 王国云 网易严选 架构师 本期议题以及嘉宾详解 13:30-14:15《蚂蚁金服 API Gateway Mesh 的思考与实践》\n 讲师：贾岛 蚂蚁金服 高级技术专家 讲师介绍：靳文祥（花名贾岛），2011年毕业后加入支付宝无线团队，一直从事移动网络接入、API 网关、微服务等相关的研发工作，目前负责蚂蚁金服移动网络接入架构设计与优化。 Topic 介绍：在 Service Mesh 微服务架构中，我们常常会听到东西流量和南北流量两个术语。蚂蚁金服开源的Service Mesh Sidecar MOSN 已经多次与大家见面交流了，以往的议题重点在东西流量的服务发现与路由，那么蚂蚁金服在南北流量上的思考是怎样的？本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的，解决了什么问题，双十一的实践表现，以及我们对未来的思考。 14:15-15:00《酷家乐的 Istio 与 Knative 踩坑实录》\n 讲师：付铖 酷家乐 技术专家 讲师介绍：先后负责酷家乐户型图, 渲染引擎等模块，目前负责酷家乐国际站的研发。在业务开发过程中推动和布道云原生技术，并在部分业务落地了 Istio 服务治理和基于 Knative 的 Serverless 基础设施。 Topic 介绍：酷家乐在部分业务模块，自2018年使用了 Istio 进行服务治理，自2019年使用了 Knative 作为 FaaS 基础设施，在实践过程中解决了大量问题，也积累了不少第一手经验。本次分享，将重点讨论服务网格的性能损耗，存量业务迁移难题，函数计算的冷启动时间问题以及解决方案等。 15:20-16:00 圆桌环节《Service Mesh 落地的务实与创新》\n 主持人：鲁直 蚂蚁金服云原生落地负责人 嘉宾： 涵畅 蚂蚁金服高级技术专家 张超盟 华为云微服务平台架构师 付铖 酷家乐技术专家 王国云 网易严选架构师 16:00-16:45《蚂蚁金服 Service Mesh 技术风险思考和实践》\n 讲师：嘉祁 蚂蚁金服 技术专家 讲师介绍：黄家琦（花名：嘉祁）2012年毕业后加入阿里巴巴技术保障，2015年转入蚂蚁金服SRE，长期从事稳定性相关工作，当前重点关注于中间件，Service Mesh 与云原生基础设施的稳定性。 Topic 介绍：Servish Mesh 是微服务架构与云原生碰撞出的火花，对于传统的中间件体系与运维支撑能力是极大的挑战。本次分享的主题主要关注于在蚂蚁金服内部如何应对这些挑战，并建设相应的技术风险能力来保障其稳定。 16:45-17:30《网易严选的 Service Mesh 实践》\n 讲师：王国云 网易高级技术专家、网易严选架构师 讲师介绍：2008年加入网易，长期从事一线的研发与管理工作，曾参与或负责过网易博客、网易邮箱、网易有钱等多个核心产品的研发工作，擅长服务端架构及技术体系建设，现任严选支持业务研发部技术负责人，负责严选的容器化及 Service Mesh 演进。 Topic 介绍：网易严选在2016年选择了 Service Mesh 作为未来微服务改造的基础架构，并在过去几年支持了业务的持续快速增长。本次分享主要介绍 Service Mesh 在严选的落地和演进情况，讨论 Service Mesh 在混合云架构下落地遇到的挑战和我们的解决方案，同时也希望和大家交流一下在架构方面的一些思考。 加入 SOFA 钉钉互动群 群号：23390449，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n主办方与合作伙伴 主办方：CNCF、ServiceMesher 协办方：蚂蚁金服、SOFAStack、滴滴 合作伙伴：掘金社区、开源中国、养码场、SegmentFault、麦思博、开源社 ","date":1576051200,"description":"本次 Meetup 与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。","dir":"activities/service-mesh-meetup-9/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a7103ed15ed823b9156082c37b7d464a","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-meetup-9/","publishdate":"2019-12-11T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/service-mesh-meetup-9/","summary":"概要 活动主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond 活动时间：时间：2019 年 12 月 28 日（周六）13:00-17:30 活动地点：杭州西湖区紫霞路","tags":["Meetup","Service Mesh"],"title":"Service Mesh Meetup#9 杭州站：To Infinity and Beyond","type":"activities","url":"/sofastack.tech/activities/service-mesh-meetup-9/","wordcount":1855},{"author":"改之","categories":"Service mesh","content":" 蚂蚁金服数据访问层有三个核心组件：数据访问框架 ZDAL、数据访问代理 DBP 和 OceanBase 代理服务器 OBProxy。本篇主要涉及 ZDAL 和 OBProxy 两个组件。ZDAL 作为全站数据访问的标准组件，不仅提供了分库分表、读写分离、分布式 Sequence等标准的应用能力，还提供了链路跟踪、影子压测、单元化、容灾切换等技术风险能力 。OBProxy 作为 OceanBase 的访问入口，提供了 OceanBase 路由寻址、读写分离等数据库能力，同时从执行效率和资源成本角度考虑，从 OBProxy 诞生那天我们就采用了近应用的独立进程部署模式，目前生产环境上保持在几十万级别的进程数。\n本篇文章通过介绍当前蚂蚁金服数据访问层遇到的问题，解决的思路，演进的方向三个方面，期望能够用阐述下 DB Mesh 发展的一些思考并让更多同学认识到 DB Mesh。期望能够 DB Mesh 的方式将数据访问层下沉到统一的基础设施之上，让新业务快速使用上全站多年的技术风险能力，并能够持续享受到更多的性能、资源等技术红利。\n背景 随着业务的快速发展，ZDAL 作为客户端模式的组件，一直存在业务耦合、版本迭代推进、多语言支持等问题。OBProxy 是为 OceanBase 数据库专门量身定制的代理服务器，天然就是业务无耦合、支持多语言。用户的数据在 OceanBase 上以多副本的形式存放在各个 OBServer 上，OBProxy 则负责接收用户发过来的 SQL 请求，解析 SQL 请求并计算分区信息后，将用户请求转发到最佳目标 OBServer 上，并将执行结果给用户。在蚂蚁金服内部也存在分库分表组件 ZDAL，用在多 OceanBase 集群以及单元化的场景。两者配合使用，分库分表组件 ZDAL 做业务层的流量调拨，OceanBase 分区功能支持数据库的水平扩容能力。\n我们进一步看 ZDAL 和 OBProxy 这两个组件的核心逻辑。\nZDAL 的核心逻辑：\n SQL 解析器：获得表名及分库分表字段； 规则引擎：计算分库分表结果； 执行层：将 SQL 改写发给数据库，并做结果集合并用户； OBProxy 的核心逻辑：\n 协议解析器：解析协议中的 SQL，Parse 后获得表名及分区字段； 路由器：计算分区表所在的 OBServer； IO 层：将请求转发给 OBServer，将结果集返回给客户端； 可以看出，OBProxy 和 ZDAL 这两个组件的执行路径有一定的重复度，比如两个组件都做了 SQL 解析，并分析表名和字段。这对性能带来一定的损耗，而且这种重复给研发迭代带来更多的工作量。\n基于前面的考虑将 ZDAL 和 OBProxy 两者合并成一个组件的是一个自然的方案，通过将 ZDAL 逻辑下沉到 OBProxy 中，让 OBProxy 提供了分库分表、读写分离、分布式序列等中间件能力，这个组件我们命名为 ODP（Open Database Proxy）。\nODP 作为近业务端部署的进程，虽然逻辑独立出来，升级时但是依然需要去改动业务的容器，所以迭代过程中的升级推进工作也是比较费时费力，而且 ODP 只是整个产品的冰山一角，需要大量的精力来构建冰山之下的基础设施，比如说如何解决 ODP 的运维问题、用户透明切换的方案、复杂配置的推送问题、金融级数据库密钥管理问题等。我们发现这部分与蚂蚁金服内部大规模实践的 ServiceMesh 遇到的问题有比较大的重合度，所以与 ServiceMesh 一起共建底层基础设施，为这块的完整产品方案命名为 DBMesh。下文会简单介绍一下我们的演进路线和发展方向。\n解决思路 Sidecar 模式以解耦部署 从执行效率和资源成本角度考虑，OBProxy 在蚂蚁金服一直都在采用近业务端部署的方式，日常保有的服务数在数十万的级别。近业务端部署虽然提供了高效率，但是也带来了运维上的复杂度，同时需要升级版本时，也需要和通知业务一起来做发布和升级。要让单个应用升级，基本都是按月计，如果涉及到全站层面的升级，时间基本不太好估算。\n但是随着云原生以及 Kubernetes 的发展，让 Sidecar 模式更为成熟，即在业务的容器旁边再运行一个容器，这个非常贴合我们近业务端部署的 OBProxy 进程，只需要将 OBProxy 进程改造成 OBProxy Sidecar，即可进行独立升级、发布、运维等。同时蚂蚁金服在云原生领域有非常深的实践，有着世界上最大规模的 Kubernetes 集群和 ServiceMesh 集群，将 OBProxy 变成 Sidecar 也是比较合理和方便实施的了。\n今年双十一切了约 10% 的数万个的 PODs 到 ODP Sidecar 模式，通过 Sidecar 的方式能够让业务快速享受到基础软件迭代的好处，本次双十一 ODP 修复了一个非预期日志打印导致某个机房出现慢 SQL 问题，在传统的本地进程方式，需要推动所有的业务进行拉迭代、发布、打包时间周期基本不太可控。而今年让所有涉及应用独立的灰度、升级仅花费两天时间。\n合并重复逻辑拿技术红利 解决了部署模式的问题，通过快速迭代并且独立升级的方式，才能让功能下沉的落地成为可能。我们将分库分表组件的大多数功能都下沉到了 ODP 上，比如：分库分表功能、读写分离功能、分布式 Sequence 功能、全链路跟踪等。如下图：\n整个分库分表组件功能下沉之后，在今年双十一我们在核心系统上线，拿到了一些非常可观的技术红利：\n 性能提升：通过功能的合并可以省去额外的 SQL 解析和路由计算过程，双十一上线的系统 SQL 平均响应时间可以下降上百微秒； 启动速度：应用只需要和 ODP 建立连接即可，无需初始化多个分库的数据源，初始化时间从数十秒降到数十毫秒； 内存下降：和启动速度一样，由于应用和 ODP 的连接数减少了，同样也可以节省应用端的内存使用，生产上能够下降上百 MB； 共建 Mesh 基础设施完善技术风险 研发同学会将更多的关注点放在 ODP 数据链路上，如何提高数据平面的性能，如何增加更多的 SQL 特性，而会忽略非 SQL 执行链路上的诉求。DBMesh 作为应用侧的基础设施，更多的要考虑如何更好的管理 Sidecar、数据访问高安全防控、满足配置变更的三板斧要求、最大程度的节省资源成本等。\n我们在与蚂蚁金服 ServiceMesh 团队共建整个云原生下 Mesh 的技术风险能力，优先完善 Sidecar 的运维能力和变更三板斧能力，后续会将 ODP Sidecar 部署到宿主机上以最大程度优化 ODP 的资源占用，也会逐步下沉更多如影子压测、灰度机房、流量镜像等的技术风险能力。\n总结 DBMesh 让数据访问从客户端模式切换到代理模式，给应用带来了启动速度的极大优化。Sidecar 的部署模式则是 SQL 平均响应时间、资源利用的最优模式。将更多的技术风险能力沉淀进来，让新应用快速享受到金融级的技术风险能力，存量应用的技术风险指标更完善。我们期望通过统一的数据访问基础设施，让业务都使用标准的技术组件，降低学习以及维护成本，仅专注在业务开发和创新上。\n作者介绍 易鸿伟（花名：改 …","date":1575982800,"description":" 本篇文章通过介绍当前蚂蚁金服数据访问层遇到的问题，解决的思路，演进的方向三个方面，期望能够用阐述下 DB Mesh 发展的一些思考并让更多同学认识到 DB Mesh。","dir":"blog/ant-financial-db-mesh-explore-practice/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9732786e2e2be0688d1e6a594838f87e","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","publishdate":"2019-12-10T21:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","summary":"蚂蚁金服数据访问层有三个核心组件：数据访问框架 ZDAL、数据访问代理 DBP 和 OceanBase 代理服务器 OBProxy。本篇主要涉及 ZDAL 和 OBProxy 两个组件。ZDAL 作为","tags":["Service mesh","DB Mesh"],"title":"蚂蚁金服 DB Mesh 的演进之路","type":"blog","url":"/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","wordcount":2561},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@温明磊 提问：\n 我们还是想用 redis 存状态机上下文一个大的实体，输入输出只放 id，我想问下，redis 宕机或者其它情况下，状态机 redis 宕机节点之前的节点都是幂等可重复的，那我怎样让它重新跑一边状态机？只能人工干预吗？\n A：你的意思是因为参数没有了，所以你想重跑状态机回放参数？\n 是的。从最开始跑，因为之前的节点幂等， 也没有变更数据，或者数据已经被 catch 住然后补偿了。\n A：我理解是你可以新启动一个状态机事例，把之前的生成的 id 传进上下文，这样和从新开始没有区别吧？不然你人工处理的话，需要把 state_inst 表里的数据删除。\n 嗯 ，我明白 ，通过定时就可以，因为在状态机开始之前 数据已经落库了。redis 宕机捕获异常后，可以给最开始的数据设置状态，然后定时开启状态机。但是 Saga 确实不能帮我完成定时重启状态机这个事情对吧，或者我就设置个补偿节点，专门用来重启新状态机实例的？这样可以？\n A：我建议是不要搞个补偿节点来处理非补偿的事，我觉得可以自己做个定时任务，然后处理这种情况。\nSeata：https://github.com/seata/seata\n2、@李林 提问：\n 数据面默认是能感知到所有服务的变更么？\n A：是的，因为对接了 SOFARegistry。\n 那当集群规模比较大的时候，是不是会出现感知较慢的情况呢？\n A：SOFARegistry 里有全量的服务订阅信息，MOSN 和 SOFARegistry 对接只会感知当前 MOSN 必须的服务信息，所以 MOSN 内的数据总量不会很大。\n Istio 控制面占用的资源比较多，MOSN 是做了优化么？\n A：你指的 Istio 控制面占用资源比较多指的是哪一部分？Mixer 么？\n 可以理解为只告知当前服务需要依赖的信息吧，这样的话数据量就小多了。\n A：是的。\n Pilot 在我们自己的集群里部署了，占用资源也挺多的，不过比 Mixer 小。 另外我查看数据面 Envoy 从 Pilot 拿到的数据信息挺多的，config_dump 的信息有 30 万行左右。\n A：我们暂时没有从 Pilot 拿服务注册数据，只有一些服务流量管控的配置从 Pilot 下发，Mixer 的能力是集成在 MOSN 内部的所以控制面的消耗还好，不是很重。\n 那应该是做了挺多优化调整的吧。\n A：是的，集成后省去了 Mixer 的两跳，Metrics 数据可以直接被采集。\n 那服务的依赖关系需要通过配置提供才能做到只感知需要依赖的服务吧？Metrics 的直接采集是通过 prometheus 直接抓取每个数据面节点的数据么？\n A：是的，通过 prometheus 协议定时有专门的 agent 抓取的数据。\nMOSN：https://github.com/sofastack/sofa-mosn\n3、@NameHaibinZhang 提问：\n 将 MOSN 按照容器化的方式部署，通过读取默认配置，暴露 15001 端口，MOSN 能够同时在一个端口接收不同协议的请求么，如 Http、SOFARPC 请求。\n A：MOSN 的默认配置都是一些 example，没有 15001 端口，你需要按照你的需求写你的配置。一个 listener 目前不能同时处理两种协议，listener 中 proxy 的配置指定了可以处理的协议。\n 15001 端口是按 Sidecar 方式部署的时候开启的端口，比如通过 Istio 来部署，iptables 中 Envoy 开启 15001 端口。\n A：目前同一个端口支持 tls/明文自定识别， http1/http2 的自动识别，协议哪儿配置 Auto。Http 和 SOFA 的识别目前不支持，有需求的话支持也很方便。\n 嗯，因为作为 Sidecar 部署的时候，http 的接口和 SOFA 接口都希望能通过 Sidecar 来做流量劫持，Auto 可以做 rpc 协议的支持和识别不？\n A：如果是做流量劫持的话，其实是不需要支持识别的，这个 15001 不会实际处理请求，会转发给正确的端口来处理。\n Sidecar 内部做一个转发是吧，开另外2个端口，那15001这个端口配置 TCP 协议了，然后接收到之前做判断是什么协议，转给对应的端口。\n A：可以看一下这篇文章：《SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案》。\nSOFA 项目进展 本周发布详情如下：\n发布 Occlum v0.7.0 版本，主要变更如下：\n 重构了 ioctl 的实现； 增加了 socketpair； 实现了与Alpine Linux的二进制兼容性； 增加了 nanosleep； 增加了外部可调用命令的路径检查（即 occlum run 的）； 增加了 XGBoost 的 demo； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.7.0\n社区活动 回顾： 11月24日 Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动回顾（含现场PPT以及视频回顾）：\n Service Mesh 在『路口』的产品思考与实践：务实是根本 深入Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统 12月5日 SOFAChannel#9 直播回顾：\n https://tech.antfin.com/community/live/1021/data/957 预告-专享福利： “剑指源码，尖峰对话”2019 OSC源创会是由 OSCHINA 主办的线下技术沙龙，理念为“自由、开放、分享”，SOFAStack 也受邀参加本次年终盛会，并带来主题分享。\n主题：《蚂蚁金服 Service Mesh 超大规模实践以及开源》\n嘉宾：卓与，蚂蚁金服 Mesh 化落地负责人\n时间：2019年12月15日下午14:05-14:40（架构分会场）\n专享福利：点击“这里”，验证码填写“SOFAStack”即可获得大会免费票。\nTopic 简 …","date":1575615600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191206/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"aa9ec52b9b85a6c8830ff752423d1248","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191206/","publishdate":"2019-12-06T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191206/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【12/2 - 12/6】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191206/","wordcount":2358},{"author":"曹寅","categories":"Kubernetes","content":" 一、前言 经过超过半年的研发，蚂蚁金服在今年完成了 Kubernetes 的全面落地，并使得核心链路100% 运行在 Kubernetes。到今年双十一，蚂蚁金服内部通过 Kubernetes 管理了数以万计的机器以及数十万的业务实例，超过90%的业务已经平稳运行在 Kubernetes 上。整个技术切换过程平稳透明，为云原生的资源基础设施演进迈好了关键的一步。\n本文主要介绍 Kubernetes 在蚂蚁金服的使用情况，双十一大促对 Kubernetes 带来史无前例的挑战以及我们的最佳实践。希望通过分享这些我们在实践过程中的思考，让大家在应用 Kubernetes 时能够更加轻松自如。\n二、蚂蚁金服的 Kubernetes 现状 2.1 发展历程与落地规模 Kubernetes 在蚂蚁金服落地主要经历了四个阶段：\n 平台研发阶段：2018年下半年蚂蚁金服和阿里集团共同投入 Kubernetes 技术生态的研发，力求通过 Kubernetes 替换内部自研平台； 灰度验证：2019年初 Kubernetes 在蚂蚁金服灰度落地，通过对部分资源集群进行架构升级以及灰度替换生产实例两种方式，让 Kubernetes 得以小规模的验证； 云化落地（蚂蚁金服内部基础设施云原生化）：2019年4月蚂蚁金服内部完成 Kubernetes 适配云化环境的目标，并于618之前完成云化机房100% 使用 Kubernetes 的目标，这是 Kubernetes 第一次在蚂蚁金服内部得到规模化的验证； 规模化落地：2019年618之后，蚂蚁金服内部开始全面推动 Kubernetes 落地，在大促之前完成核心链路100% 运行在 Kubernetes的目标，并完美支撑了双十一大考。 2.2 统一资源调度平台 Kubernetes 承载了蚂蚁金服在云原生时代对资源调度的技术目标：统一资源调度。通过统一资源调度，可以有效提升资源利用率，极大的节省资源成本。要做到统一调度，关键在于从资源层面将各个二层平台的调度能力下沉，让资源在 Kubernetes 统一分配。\n蚂蚁金服在落地 Kubernetes 实现统一调度目标时遵循了标准化的扩展方式：\n 一切业务扩展均围绕 Kubernetes APIServer，通过CRD + Operator方式完成业务功能的适配和扩展； 基础服务通过 Node 层定义的资源接口完成个性化适配，有益于形成资源接入的最佳实践。 得益于持续的标准化工作，我们在落地 Kubernetes 的大半年内应用了多项技术，包含安全容器，统一日志，GPU 精细调度，网络安全隔离及安全可信计算等，并通过 Kubernetes 统一使用和管理这些资源服务了大量在线业务以及计算任务型业务。\n三、双十一 Kubernetes 实践 下面我们通过以下几种场景介绍蚂蚁金服内部是如何使用 Kubernetes，以及在此过程中我们面对的挑战和实践之路。\n3.1 资源分时复用 在大促过程中，不同业务域的洪峰流量通常都是在不同时间段来临，而应对这些不同时间到来的业务流量往往都需要大量的额外计算资源做保障。在以往的几次活动中，我们尝试了通过应用快速腾挪的方式来做到资源上的分时复用，但是服务实例上下线需要预热，腾挪耗时不可控，大规模调度的稳定性等因素都影响了最终腾挪方案的实践效果。\n今年双十一我们采用了资源共享调度加精细化切流的技术以达到资源分时利用的目标，为了达到资源充分利用和极速切换的目标，我们在以下方面做了增强：\n 在内部的调度系统引入了联合资源管理（Union-Resource Management），他可以将波峰波谷不重叠的业务实例摆放在相同的资源集合内，达到最大化的资源利用。 研发了一套融合资源更新，流量切换及风险控制的应用分时复用平台，通过该平台SRE可以快速稳定的完成资源切换以应对不同的业务洪峰。 整套平台和技术最终实现了令人激动的成果：蚂蚁金服内部不同业务链路数以万计的实例实现了最大程度的资源共享，这些共享资源的实例可分钟级完成平滑切换。这种技术能力也突破了当下资源水平伸缩能力的效率限制，为资源的分时复用打开了想象空间。\n3.2 计算型任务混部 Kubernetes 社区的落地案例中，我们往往看到的都是各种各样的在线业务，计算型业务往往通过“圈地”式的资源申请和独立的二层调度跑在 Kuberentes 集群中。但是在蚂蚁内部我们从决定使用 Kubernetes 的第一天起，就将 Kubernetes 融合计算型业务实现资源的统一调度作为我们的目标。\n在蚂蚁金服内部我们持续的使用 Kubernetes 支持各类计算业务，例如各类AI 训练任务框架，批处理任务和流式计算等。他们都有一个共同的特点：资源按需申请，即用即走。\n我们通过 Operator 模型适配计算型任务，让任务在真正执行时才会调用 Kubernetes API 申请 Pod 等资源，并在任务退出时删除 Pod 释放资源。同时我们在调度引擎中引入了动态资源调度能力和任务画像系统，这为在线和计算的不同等级业务提供了分级资源保障能力，使在线业务不受影响的情况下资源被最大化的利用。\n今年双十一除了洪峰时间段（00：00~02：00），蚂蚁金服 Kubernetes 上运行的任务均未做降级，每分钟仍有数以百计的计算任务在 Kubernetes 上申请和释放。未来蚂蚁金服内部将会持续推动业务调度融合，将 Kubernetes 打造成为资源调度的航空母舰。\n3.3 规模化核心 蚂蚁金服是目前少数运行了全球最大规模的 Kubernetes 集群的公司之一，单集群机器规模过万，Pods 数量数十万。随着类似计算型任务混部和资源分时复用这类业务的落地，资源的动态使用以及业务自动化运维都对 Kubernetes 的稳定性和性能带来的巨大的挑战。\n首先需要面对的挑战是调度性能，社区的调度器在5k规模测试中调度性能只有1~2 pods/s，这显然无法满足蚂蚁金服的调度性能需求。\n针对同类业务的资源需求往往相同的特点，我们自研了批量调度功能，再加上例如局部的filters性能优化等工作，最终达到了百倍的调度性能提升！\n在解决了调度性能问题后，我们发现规模化场景下 APIServer 逐渐成为了影响 Kubernetes 可用性的关键组件，CRD+Operator 的灵活扩展能力更是对集群造成巨大的压力。业务方有100种方法可以玩垮生产集群，让人防不胜防。 造成这种现象一方面是由于社区今年以前在规模化上的投入较少 APIServer 能力较弱，另一方面也是由 Operator 模式的灵活性决定。开发者在收益于 Operator 高灵活度的同时，往往为集群管理者带来业务不受控制的风险。即使对 Kubernetes 有一定熟悉程度的开发者，也很难保障自己写出的 Operator 在生产中不会引爆大规模的集群。\n面对这种“核按钮”不在集群管理员手上的情况，蚂蚁内部通过两方面入手解决规模化带来的问题：\n 我们通过持续总结迭代过程中的经验，形成了内部的最佳实践原则，以帮助业务更好的设计Operator CRD 在定义时需要明确未来的最大数量，大量CR …","date":1575464400,"description":"本文主要介绍 Kubernetes 在蚂蚁金服的使用情况，双十一大促对 Kubernetes 带来史无前例的挑战以及我们的最佳实践。","dir":"blog/kubernetes-practice-antfinal-shopping-festival/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5e1572fd3da2309cb49050bc05e24450","permalink":"https://sofastack.github.io/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","publishdate":"2019-12-04T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","summary":"一、前言 经过超过半年的研发，蚂蚁金服在今年完成了 Kubernetes 的全面落地，并使得核心链路100% 运行在 Kubernetes。到今年双十一，蚂蚁金服内部通","tags":["Kubernetes"],"title":"深入 Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统","type":"blog","url":"/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","wordcount":3956},{"author":"齐天","categories":"Service mesh","content":" 一、引言 Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』，我们在产品设计上的思考和实践，希望能给大家带来一些启发。\n二、为什么需要 Service Mesh? 2.1 微服务治理与业务逻辑解耦 在 Service Mesh 之前，微服务体系的玩法都是由中间件团队提供一个 SDK 给业务应用使用，在 SDK 中会集成各种服务治理的能力，如：服务发现、负载均衡、熔断限流、服务路由等。\n在运行时，SDK 和业务应用的代码其实是混合在一个进程中运行的，耦合度非常高，这就带来了一系列的问题：\n 升级成本高 每次升级都需要业务应用修改 SDK 版本号，重新发布； 在业务飞速往前跑的时候，是不太愿意停下来做这些和自身业务目标不太相关的事情的； 版本碎片化严重 由于升级成本高，但中间件还是会向前发展，久而久之，就会导致线上 SDK 版本各不统一、能力参差不齐，造成很难统一治理； 中间件演进困难 由于版本碎片化严重，导致中间件向前演进过程中就需要在代码中兼容各种各样的老版本逻辑，戴着『枷锁』前行，无法实现快速迭代； 有了 Service Mesh 之后，我们就可以把 SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以 Sidecar 的模式部署。通过将服务治理能力下沉到基础设施，可以让业务更加专注于业务逻辑，中间件团队则更加专注于各种通用能力，真正实现独立演进，透明升级，提升整体效率。\n2.2 异构系统统一治理 随着新技术的发展和人员更替，在同一家公司中往往会出现使用各种不同语言、不同框架的应用和服务，为了能够统一管控这些服务，以往的做法是为每种语言、每种框架都重新开发一套完整的 SDK，维护成本非常高，而且对中间件团队的人员结构也带来了很大的挑战。\n有了 Service Mesh 之后，通过将主体的服务治理能力下沉到基础设施，多语言的支持就轻松很多了，只需要提供一个非常轻量的 SDK、甚至很多情况都不需要一个单独的 SDK，就可以方便地实现多语言、多协议的统一流量管控、监控等治理需求。\n图片来源\n2.3 金融级网络安全 当前很多公司的微服务体系建设都建立在『内网可信』的假设之上，然而这个原则在当前大规模上云的背景下可能显得有点不合时宜，尤其是涉及到一些金融场景的时候。\n通过 Service Mesh，我们可以更方便地实现应用的身份标识和访问控制，辅之以数据加密，就能实现全链路可信，从而使得服务可以运行于零信任网络中，提升整体安全水位。\n三、在当下『路口』的思考 3.1 云原生方案？ 正因为 Service Mesh 带来了上述种种的好处，所以这两年社区中对 Service Mesh 的关注度越来越高，也涌现出了很多优秀的 Service Mesh 产品，Istio 就是其中一款非常典型的标杆产品。\nIstio 以其前瞻的设计结合云原生的概念，一出现就让人眼前一亮，心之向往。不过深入进去看了之后发现，在目前阶段要落地的话，还是存在一些 gap 的。\n图片来源\n3.2 Greenfield vs Brownfield 在正式展开讨论之前，我们先来看一副漫画。\n图片来源\n上面这幅漫画描绘了这样一个场景：\n 有两个工人在工作，其中一个在绿色的草地（Greenfield）上，另一个在棕色的土地（Brownfield）上； 在绿色草地上的工人对在棕色土地上的工人说：“如果你没有给自己挖这么深的坑，那么你也可以像我一样做一些很棒的新东西”； 然后在棕色土地上的工人回答道：“你倒是下来试试！”； 这是一幅很有意思的漫画，从表面上看我们可以认为在绿色草地上的工人是站着说话不腰疼，不过其实本质的原因还是两者所处的环境不同。\n在一片未开发过的土地上施工确实是很舒服的，因为空间很大，也没有周遭各种限制，可以使用各种新技术、新理念，我们国家近几十年来的一些新区新城的建设就属于这类。而在一片已经开发过的土地上施工就大不一样了，周围环境会有各种限制，比如地下可能有各种管线，一不小心就挖断了，附近还有各种大楼，稍有不慎就可能把楼给挖塌了，所以做起事来就要非常小心，设计方案时也会受到各种约束，无法自由发挥。\n对于软件工程，其实也是一样的，Greenfield 对应着全新的项目或新的系统，Brownfield 对应着成熟的项目或遗留系统。\n我相信大部分程序员都是喜欢做全新的项目的，包括我自己也是一样。因为可以使用新的技术、新的框架，可以按照事物本来的样子去做系统设计，自由度很高。而在开发/维护一个成熟的项目时就不太一样了，一方面项目已经稳定运行，逻辑也非常复杂，所以无法很方便地换成新的技术、新的框架，在设计新功能时也会碍于已有的架构和代码实现做很多妥协，另一方面前人可能不知不觉挖了很多坑，稍有不慎就会掉进坑里，所以行事必须要非常小心，尤其是在做大的架构改变的时候。\n3.3 现实场景 3.3.1 Brownfield 应用当道 在现实中，我们发现目前大部分的公司还没有走向云原生，或者还刚刚在开始探索，所以大量的应用其实还跑在非 k8s 的体系中，比如跑在虚拟机上或者是基于独立的服务注册中心构建微服务体系。\n虽然确实有少量 Greenfield 应用已经在基于云原生来构建了，但现实是那些大量的 Brownfield 应用是公司业务的顶梁柱，承载着更大的业务价值，所以如何把它们纳入 Service Mesh 统一管控，从而带来更大的价值，也就成了更需要优先考虑的话题。\n图片来源 独立的服务注册中心\n3.3.2 云原生方案离生产级尚有一定距离 另一方面，目前 Istio 在整体性能上还存在一些有待解决的点（引述小剑老师在蚂蚁金服 Service Mesh 深度实践中的观点）：\n Mixer Mixer 的性能问题，一直都是 Istio 中最被人诟病的地方； 尤其在 Istio 1.1\u0026amp;frasl;1.2 版本之后引入了 Out-Of-Process Adapter，更是雪上加霜； 从落地的角度看，Mixer V1 糟糕至极的性能，已经是“生命无法承受之重”。对于一般规模的生产级落地而言，Mixer 性能已经是难于接受，更不要提大规模落地…… Mixer V2 方案则给了社区希望：将 Mixer 合并进 Sidecar，引入 web assembly 进行 Adapter 扩展，这是我们期待的 Mixer 落地的正确姿势，是 Mixer 的未来，是 Mixer 的『诗和远方』。然而社区望穿秋水，但Mixer V2 迟迟未能启动，长期处于 In Review 状态，远水解不了近渴； Pilot Pilot 是一个被 Mixer 掩盖的重灾区：长期以来大家的性能关注点都在 Mixer，表现糟糕而且问题明显的Mixer 一直在吸引火力。但是当选择放弃 Mixer（典型如官方在 Istio 新版本中提供的关闭 Mixer 的配置开关）之后，Pilot 的性能问题也就很快浮出水面； 我们实践下来发现 Pilot 目前主要有两大问题：1）无法支撑海量数据 2）每次变化都会触发全量推送，性能较差； 图片来源\n3.4 当 …","date":1575291600,"description":"Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』，我们在产品设计上的思考和实践。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-wushi/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"30414154356f38408eac8044657b5d63","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","publishdate":"2019-12-02T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","summary":"一、引言 Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』","tags":["Service mesh","Service Mesh 落地实践"],"title":"Service Mesh 在『路口』的产品思考与实践：务实是根本","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","wordcount":6226},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News NO.1 社区新认证一位 Committer\nGithub ID @zongtanghu 成为 SOFAJRaft Committer：\n主要贡献：\n 贡献了两个重要 Feature： 基于优先级配置的自动选举； 为 Replicator 日志复制实现 ReplicatorStateListener 监听器； 添加一些优化功能和 Bugfix： 优化 SOFAJRaft 的工具类，减少冗余代码，增加单元测试用例代码； 优化常量类，实现 Copiable 接口； 原创文章贡献 《SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理》; 《中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说》; 目前，社区已经认证超过四十位 Committer。\n感谢对 SOFAStack 的支持和帮助，也欢迎你加入 SOFAStack community~ SOFAStack 社区：https://www.sofastack.tech/awesome/\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@kaka19ace 提问：\n 为什么 MOSN 热重启机制需要新老进程，两个 unix domain socket server 通信交互? 目前分为 旧进程 reconfigerServer 新进程 transferServer, 1. reconfigerServer 只是新进程主动判断 isReconfigure() 就结束了连接； 1. 迁移 listener fd 以及 connection fd 让旧进程作为 client 角色；\n如果仅使用 reconfigerServer 作为交互通信会存在哪些问题？\n A：你的意思就是旧进程 reconfigerServer在收到 isReconfigure() 后，直接传输旧进程的fd给新进程。原理上也是可以的。这儿其实有个历史原因，最开始支持信号 fork 子进程的方式，是不需要 isReconfigure() 来判断是否存在旧进程的，通过环境变量就可以了，后来为了支持容器升级的方式，单独启一个新的进程，才需要一个机制来判断是否存在旧进程，为了改动更小，之前的逻辑不受影响，才加了这个新的 us 来通讯。\n 翻了老版本代码阅读： reconfigure 这块是基于环境变量设置 fd. fork exec 参数使用 sys.ProcAttr 继承 fd 信息。 这块有一个问题确认，老版本场景里如果升级新版的二进制文件，也是基于同目录下替换了相同的 bin 文件，然后再给老进程 hup 信号触发重启吧？\n A：是的，老版本是发送 hup 信号，然后 fork 一个子进程来做二进制升级，这个适用于虚拟机升级。而基于容器的话，是重新拉起一个容器，一个新的进程，就需要跟老的进程来交互。\n 早期版本和 Envoy uds 迁移方式不同，当时设计是有什么考虑吗？后续基于 SCM_RIGHTS 传输 fd 方式与 Envoy 类似，这块重构原因有哪些?想了解代码演进的过程。\n A：你看到代码是 listen fd 的迁移，和 Envoy 最大的不同是我们会把存量的长链接也做迁移。 代码演进是： 第一阶段， 只支持 listen fd 的迁移。 第二阶段， 支持存量长链接的迁移，hup 信号，然后 fork 的方式。 第三阶段， 支持容器间存量长链接的迁移，通过 uds 查找子进程。\n 非常感谢丰富的演进说明。重新拉起容器这块不太明白，对 Envoy 的场景理解： - 热重启是同一个容器内，Sidecar 新老进程的交接，业务进程继续运行； - Sidecar 进程管理是由 pilot-agent 进行管理，当前容器内 agent 发送热重启信号，非重新拉起容器；\nMOSN 这里指的是拉起新容器, 容器间迁移数据？uds 的路径是挂载盘?\n A：Envoy 的方式不能用镜像来管理二进制了。MOSN 除了支持 Envoy 这种容器内热升级，也支持容器间。MOSN 会拉起新容器，然后做容器间的连接迁移，uds 的路径是共享卷，2个 container 共享。\n 容器间迁移是否和业务场景有关，为何不是让旧容器自己销毁（摘掉服务发现, 并延迟一段时间自己销毁）？\n A：是的，就是为了 Sidecar 的发布对用户无感知，连接不断，升级 Sidecar 的时候服务也一直在运行。 MOSN：https://github.com/sofastack/sofa-mosn\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFAJRaft v1.3.0 版本，主要变更如下：\n 新增 Read-only member(learner) 角色，支持 learner 节点上的线性一致读 实现优先级选举 在 multi-raft-group 的场景中，随机打散每个 group 的第一次 snapshot timeout 时间，避免一个进程内多个 group 同时 snapshot RheaKV 实现 snapshot checksum 以及异步 snapshot 致谢（排名不分先后）：@zongtanghu @devYun @masaimu @SteNicholas @yetingsky 详细发布报告： https://github.com/sofastack/sofa-jraft/issues/362\n社区活动 回顾 11月24日 Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动回顾：\n 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇（文末含分享视频回顾以及 PPT 查看地址） 预告 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔 …","date":1575010800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191129/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"af340bf3bee03aa71221229aee4c986b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191129/","publishdate":"2019-11-29T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/25 - 11/29】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191129/","wordcount":2060},{"author":"鲁直、碧远","categories":"Service mesh","content":" 蚂蚁金服云原生负责人鲁直 双十一后首次线下分享\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA（service-oriented architecture，面向服务的架构）体系快速演进至 Service Mesh 架构。聚焦 RPC 层面的设计和改造方案，本次将分享蚂蚁金服双十一核心应用是如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本。\n蚂蚁金服每年双十一大促会面临非常大的流量挑战，在已有 LDC（Logical Data Center，逻辑数据中心，是蚂蚁金服原创的一种“异地多活单元化架构”实现方案）微服务架构下已支撑起弹性扩容能力。本次分享主要分为 5 部分：\n Service Mesh 简介； 为什么要 Service Mesh； 方案落地； 分时调度案例； 思考与未来； 作者简介 黄挺（花名：鲁直）：蚂蚁金服云原生负责人 主要 Focus 领域：\n SOFAStack 微服务领域； Service Mesh，Serverless 等云原生领域； 雷志远（花名：碧远）：蚂蚁金服 RPC 框架负责人 主要 Focus 领域：\n 服务框架：SOFARPC（已开源）； Service Mesh：MOSN（已开源）； SOFARPC：https://github.com/sofastack/sofa-rpc\nMOSN：https://github.com/sofastack/sofa-mosn\nService Mesh 简介 在讲具体的蚂蚁金服落地之前，想先和大家对齐一下 Service Mesh 的概念，和蚂蚁金服对应的产品。这张图大家可能不陌生，这是业界普遍认可的 Service Mesh 架构，对应到蚂蚁金服的 Service Mesh 也分为控制面和数据面，分别叫做 SOFAMesh 和 MOSN，其中 SOFAMesh 后面会以更加开放的姿态参与到 Istio 里面去。\n今天我们讲的实践主要集中在 MOSN 上，以下我的分享中提到的主要就是集中在数据面上的落地，这里面大家可以看到，我们有支持 HTTP/SOFARPC/Dubbo/WebService。\n为什么我们要 Service Mesh 有了一个初步的了解之后，可能大家都会有这样一个疑问，你们为什么要 Service Mesh，我先给出结论：\n因为我们要解决在 SOA 下面，没有解决但亟待解决的：基础架构和业务研发的耦合，以及未来无限的对业务透明的稳定性与高可用相关诉求。\n那么接下来，我们一起先看看在没有 Service Mesh 之前的状况。\n在没有 Service Mesh 之前，整个 SOFAStack 技术演进的过程中，框架和业务的结合相当紧密，对于一些 RPC 层面的需求，比如流量调度，流量镜像，灰度引流等，是需要在 RPC 层面进行升级开发支持，同时，需要业务方来升级对应的中间件版本，这给我们带来了一些困扰和挑战。如图所示：\n 线上客户端框架版本不统一； 业务和框架耦合，升级成本高，很多需求由于在客户端无法推动，需要在服务端做相应的功能，方案不够优雅； 机器逐年增加，如果不增加机器，如何度过双十一； 在基础框架准备完成后，对于新功能，不再升级给用户的 API 层是否可行；  流量调拨，灰度引流，蓝绿发布，AB Test 等新的诉求； 这些都困扰着我们。我们知道在 SOA 的架构下，负责每个服务的团队都可以独立地去负责一个或者多个服务，这些服务的升级维护也不需要其他的团队的接入，SOA 其实做到了团队之间可以按照接口的契约来接耦。但是长期以来，基础设施团队需要推动很多事情，都需要业务团队进行紧密的配合，帮忙升级 JAR 包，基础设施团队和业务团队在工作上的耦合非常严重，上面提到的各种问题，包括线上客户端版本的不一致，升级成本高等等，都是这个问题带来的后果。\n而 Service Mesh 提供了一种可能性，能够将基础设施下沉，让基础设施团队和业务团队能够解耦，让基础设施和业务都可以更加快步地往前跑。\n我们的方案 说了这么多，那我们怎么解决呢？我们经历了这样的选型思考。\n总体目标架构 我们的 MOSN 支持了 Pilot、自有服务发现 SOFARegistry 和自有的消息组件，还有一些 DB 的组件。在产品层，提供给开发者不同的能力，包括运维、监控、安全等能力，这个是目前我们的一个线上的状态。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n 看上去很美好，要走到这个状态，我们要回答业务的三个灵魂拷问。\n这三个问题后面，分别对应着业务的几大诉求，大家做过基础框架的应该比较有感触。\n框架升级方案 准备开始升级之后，我们要分析目前我们的线上情况，而我们现在线上的情况，应用代码和框架有一定程度的解耦，用户面向的是一个 API，最终代码会被打包，在 SOFABoot 中运行起来。\n SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n 那么，我们就可以在风险评估可控的情况下，直接升级底层的 SOFABoot。在这里，我们的 RPC 会检测一些信息，来确定当前 Pod 是否需要开启 MOSN 的能力。然后我们完成如下的步骤。\n我们通过检测 PaaS 传递的容器标识，知道自己是否开启了 MOSN，则将发布和订阅给 MOSN，然后调用不再寻址，直接完成调用。\n可以看到，通过批量的运维操作，我们直接修改了线上的 SOFABoot 版本，以此，来直接使得现有的应用具备了 MOSN 的能力。有些同学可能会问，那你一直这么做不行吗？不行，因为这个操作是要配合流量关闭等操作来运行的，也不具备平滑升级的能力，而且直接和业务代码强相关，不适合长期操作。\n这里我们来详细回答一下，为什么不采用社区的流量劫持方案？\n主要的原因是一方面 iptables 在规则配置较多时，性能下滑严重。另一个更为重要的方面是它的管控性和可观测性不好，出了问题比较难排查。蚂蚁金服在引入 Service Mesh 的时候，就是以全站落地为目标的，而不是简单的“玩具”，所以我们对性能和运维方面的要求非常高，特别是造成业务有损或者资源利用率下降的情况，都是不能接受的。\n容器替换方案 解决了刚刚提到的第一个难题，也只是解决了可以做，而并不能做得好，更没有做得快，面对线上数十万带着流量的业务容器， 我们如何立刻开始实现这些容器的快速稳定接入？\n这么大的量，按照传统的替换接入显然是很耗接入成本的事情，于是我们选择了原地接入，我们可以来看下两者的区别：\n在之前，我们做一些升级操作之类的，都是需要有一定的资源 Buffer，然后批量的进行操作， …","date":1574946000,"description":" 聚焦 RPC 层面的设计和改造方案，本次将分享蚂蚁金服双十一核心应用是如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3d67d3c4d38ced6f9de8a92364c0827c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","publishdate":"2019-11-28T21:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","summary":"蚂蚁金服云原生负责人鲁直 双十一后首次线下分享 引言 Service Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","wordcount":4496},{"author":"悟尘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第五篇 - 网关篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 本文结合无线网关的发展历程，解读进行 Service Mesh 改造的缘由和价值，同时介绍在双十一落地过程中如何保障业务流量平滑迁移至新架构下的 Mesh 网关。分享将从如下三个方面展开：\n 网关的前世今生，解释网关为什么要 Mesh 化； 网关 Mesh 化，阐述如何进行 Mesh 化改造； 双十一落地，介绍在此过程中实现三板斧能力； 前世今生 蚂蚁金服无线网关当前接入数百个业务系统，提供数万个 API 服务，是蚂蚁金服客户端绝对的流量入口，支持的业务横跨支付宝、网商、财富、微贷、芝麻和国际 A+ 等多种场景。面对多种业务形态、复杂网络结构，无线网关的架构也在不断演进。\n中心化网关 在 All In 无线的年代，随着通用能力的沉淀，形成了中心化网关 Gateway。\n 客户端连接到网关接入层集群 Spanner ； Spanner 会把客户端请求转发到无线网关集群 Gateway； Gateway 提供通用能力如鉴权、限流等处理请求，并根据服务标识将请求路由到正确的后端服务；服务处理完请求，响应原路返回； 2016 年新春红包爆发，蚂蚁森林等新兴业务发展壮大，网关集群机器数不断增长。这加剧了运维层面的复杂性，IT成本也不能承受之重。同时，一些核心链路的业务如无线收银台、扫一扫等，迫切需要与其他业务隔离，避免不可预知的突发流量影响到这些高保业务的可用性。因此，2016 年下半年开始建设和推广去中心化网关。\n去中心化网关 去中心化网关将原先集中式网关的能力进行了拆分：\n 转发逻辑：将 Gateway 中根据服务标识转发的能力迁移到 Spanner 上； 网关逻辑：将网关通用能力如鉴权、限流、LDC 等功能，抽成一个 mgw jar 集成到业务系统中，与后端服务同JVM 进程运行； 此时，客户端请求的处理流程如下：\n 客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务的 mgw 中； mgw 进行通用网关能力处理，90% 的请求随即进行 JVM 内部调用； 去中心化网关与集中式网关相比，具有如下优点：\n 提升性能： 少一层网关链路，网关 jar 调用业务是 JVM 内部调用； 大促期间，无需关心网关的容量，有多少业务就有多少网关； 提高稳定性： 集中式网关形态下，网关出现问题，所有业务都会收到影响； 去中心化后，网关的问题，不会影响去中心化的应用； 但凡事具有两面性，随着在 TOP30 的网关应用中落地铺开，去中心化网关的缺点也逐步显现：\n 研发效能低： 接入难：需要引入 15+ pom 依赖、20+ 的配置，深度侵入业务配置； 版本收敛难：当前 mgw.jar 已迭代了 40+ 版本，当前还有业务使用的是初版，难以收敛； 新功能推广难：新能力上线要推动业务升级和发布，往往需要一个月甚至更久时间； 干扰业务稳定性： 依赖冲突，干扰业务稳定性，这种情况发生了不止一次； 网关功能无法灰度、独立监测，资源占用无法评估和隔离； 不支持异构接入：财富域大部分系统是 Node 技术栈，无法使用去中心化网关；  Mesh 网关 去中心化网关存在的诸多问题，多数是由于网关功能与业务进程捆绑在一起造成的。这引发了我们的思考：如果网关功能从业务进程中抽离出来，这些问题是否就可以迎刃而解了？这种想法，与 Service Mesh 的 Sidecar 模式不谋而合。因此在去中心化网关发展了三年后，我们再出发对蚂蚁金服无线网关进行了 Mesh 化改造，以期籍此解决相关痛点。\nMesh 网关与后端服务同 Pod 部署，即 Mesh 网关与业务系统同服务器、不同进程，具备网关的全量能力。客户端请求的处理流程如下：\n 客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务同 Pod 中的 Mesh 网关； Mesh 网关执行通用逻辑后调用同机不同进程的业务服务，完成业务处理； 对比去中心化网关的问题，我们来分析下 Mesh 网关所带来的优势：\n 研发效能： 接入方便：业务无需引入繁杂的依赖和配置，即可接入 Mesh 网关； 版本容易收敛、新功能推广快：新版本在灰度验证通过后，即可全网推广升级，无需维护和排查多版本带来的各种问题； 业务稳定性： 无损升级：业务系统无需感知网关的升级变更，且网关的迭代升级将可利用 MOSN 现有的特性进行细粒度的灰度和验证，做到无损升级； 独立监测：由于和业务系统在不同进程，可以实时遥测 Mesh 网关进程的表现，并据此评估和优化，增强后端服务稳定性； 异构系统接入：Mesh 网关相当于一个代理，对前端屏蔽后端的差异，将支持 SOFARPC、Dubbo 和 gRPC 等主流 RPC 协议，并支持非 SOFA 体系的异构系统接入； 至此，我们卖瓜自夸式地讲完了无线网关的前世今生，解释了为何要撸起袖子进行网关 Mesh 化。但细心的你想必怀疑：\n Mesh 化之后的请求处理流程不是同进程调用，比起去中心化网关多了一跳，是否有性能损耗？ 毕竟进行了大刀阔斧的变革，在上线过程中如何保障稳定性？ 接下来的章节将对上述问题进行解释。\nMesh 化 架构 首先，从架构层面详细介绍网关 Mesh 化所做的相关工作。依照 Service Mesh 的分层模型，Mesh 网关分为数据面和控制面。\n解读：\n 蓝色箭头线是客户端请求的处理流程，Mesh 网关数据面在蚂蚁金服内部 MOSN 的 Sidecar 中； 绿色箭头线是网关配置下发过程，Mesh 网关控制面当前还是由网关管控平台来承载； 红色箭头线条是 MOSN Sidecar 的运维体系； MOSN：https://github.com/sofastack/sofa-mosn\n数据面 采用 Go 语言实现了原先网关的全量能力，融合进 MOSN 的模型中，复用了其他组件已有的能力。 同时网络接入层 Spanner 也实现了请求分发决策能力。\n数据转换 将客户端的请求数据转换成后端请求数据，将后端响应数据转换成客户端响应。利用 MOSN 协议层扩展能力，实现了对网关自有协议 Mmtp 的解析能力。\n通用功能 授权、安全、限流、LDC 和重试等网关通用能力。利用 MOSN Stream Filter 注册机制以及统一的 Stream Send/Receive Filter 接口扩展而来。\n请求路由 客户端请求按照特定规则路由到正确的后端系统。在网关层面实现 LDC 逻辑后，复用 MOSN RPC 组件的路由匹配能力。其中大部分请求都会路由到当前 Zone，从而直接请求到当前 Pod 的业务进程端口。\n后端调用 支持调用多种类型的后端服务，支持对 SOFARPC、Chair 等后端，后期计划支持更多的 RPC 框架和异构系统。\n控制面 为网关用户提供新增、配置 API 等服务的管控系统，可将网关配置数据下发至 Mesh …","date":1574946000,"description":" 本文结合无线网关的发展历程，解读进行 Service Mesh 改造的缘由和价值，同时介绍在双十一落地过程中如何保障业务流量平滑迁移至新架构下的 Mesh 网关。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a51651ca16ad1df8e867f4e25296c50b","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","publishdate":"2019-11-28T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第五篇 - 网关篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","wordcount":3545},{"author":"嘉祁","categories":"Service mesh","content":" 《蚂蚁金服 Service Mesh 大规模落地系列》将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析，文末包含往期系列文章。本文为该系列文章的第三篇 - 运维篇。\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，也是蚂蚁金服内部向云原生演进的重要一环。本文为 Service Mesh 系列文章的运维篇，作者：黄家琦 （花名：嘉祁），蚂蚁金服运维专家，Service Mesh SRE，主要关注云原生基础设施、中间件及 Service Mesh 的稳定性，同时也是 Pythoner，sofa-bolt-python 作者。\n本文将主要分享大规模服务网格在蚂蚁金服当前体量下落地到支撑蚂蚁金服双十一大促过程中，运维角度所面临的挑战与演进。内容包括云原生化的选择与问题，对资源模型的挑战，大规模下运维设施的演进，以及周边技术风险能力的建设。\nService Mesh 在2019年得到了大规模的应用与落地，截止目前，蚂蚁金服的 Service Mesh 数据平面 MOSN 已接入应用数百个，接入容器数量达数十万，是目前已知的全世界最大的 Service Mesh 集群。同时，在刚刚结束的双十一大促中，Service Mesh 的表现也十分亮眼，RPC 峰值 QPS 达到了几千万，消息峰值 TPS 达到了几百万，且引入 Service Mesh 后的平均 RT 增长幅度控制在 0.2 ms 以内。\n拥抱云原生 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。而在具体部署上，保守的做法是以独立进程的方式与业务进程共同存在于业务容器内。我们在蚂蚁金服内部的做法，则从开始，就选择了拥抱云原生。\nSidecar 模式 业务容器内独立进程的好处在于与传统的部署模式兼容，易于快速上线；但独立进程强侵入业务容器，对于镜像化的容器更难于管理。而云原生化，则可以将 Service Mesh 本身的运维与业务容器解耦开来，实现中间件运维能力的下沉。在业务镜像内，仅仅保留长期稳定的 Service Mesh 相关 JVM 参数，从而仅通过少量环境变量完成与 Service Mesh 的联结。同时考虑到面向容器的运维模式的演进，接入 Service Mesh 还同时要求业务完成镜像化，为进一步的云原生演进打下基础。\n 优 劣 独立进程 兼容传统的部署模式；改造成本低；快速上线 侵入业务容器；镜像化难于运维 Sidecar 面向终态；运维解耦 依赖 K8s 基础设施；运维环境改造成本高；应用需要镜像化改造 在接入 Service Mesh 之后，一个典型的 POD 结构可能包含多个 Sidecar：\n MOSN：RPC Mesh, MSG Mesh, \u0026amp;hellip;（扩展中）； 其它 Sidecar； MOSN：https://github.com/sofastack/sofa-mosn\n这些 Sidecar 容器，与业务容器共享相同的网络 Namespace，使得业务进程可以以本地端口访问 Service Mesh 提供的服务，保证了与保守做法一致的体验。\n基础设施云原生支撑 我们也在基础设施层面同步推进了面向云原生的改造，以支撑 Service Mesh 的落地。\n业务全面镜像化 首先是在蚂蚁金服内部推进了全面的镜像化，我们完成了内部核心应用的全量容器的镜像化改造。改造点包括：\n 基础镜像层面增加对于 Service Mesh 的环境变量支撑； 应用 Dockerfile 对于 Service Mesh 的适配； 推进解决了存量前后端分离管理的静态文件的镜像化改造； 推进了大量使用前端区块分发的应用进行了推改拉的改造； 大批量的 VM 模式的容器升级与替换； 容器 POD 化 除了业务镜像层面的改造，Sidecar 模式还需要业务容器全部跑在 POD 上，来适应多容器共享网络。由于直接升级的开发和试错成本很高，我们最终选择将接入 Service Mesh 的 数百个应用的数万个非 K8s 容器，通过大规模扩缩容的方式，全部更换成了 K8s PODs。\n经过这两轮改造，我们在基础设施层面同步完成了面向云原生的改造。\n资源的演进 Sidecar 模式的带来一个重要的问题，如何分配资源。\n理想比例的假设 最初的资源设计基于内存无法超卖的现实。我们做了一个假设：\n MOSN 的基本资源占用与业务选择的规格同比例这一假设。 CPU 和 Memory 申请与业务容器相应比例的额外资源。这一比例最后设定在了 CPU 1/4，Memory 1/16。\n此时一个典型 Pod 的资源分配如下图示：\n这一方式带来了两个问题：\n 蚂蚁金服已经实现了业务资源的 Quota 管控，但 Sidecar 并不在业务容器内，Service Mesh 容器成为了一个资源泄漏点； 业务很多样，部分高流量应用的 Service Mesh 容器出现了严重的内存不足和 OOM 情况； 完美分割的不完美 不止于此，为了快速支撑 Service Mesh 在非云环境的铺开，上线了原地接入 Service Mesh。而原地接入 Service Mesh 的资源无法额外分配，在内存不能超卖的情况下，采取了二次分割的分配方式。此时的 POD 内存资源被切分为1/16内存给 Sidecar，与15/16给业务容器。除了以上两个问题，还带来一些新的问题：\n 业务可见内存不一致，业务监控偏差，业务进程 OOM 风险。 讨论之后，我们追加了一个假设：\n Service Mesh 容器占用的资源实质是在接入 Service Mesh 之前业务已使用的资源。接入 Service Mesh 的过程，同时也是一次资源置换。 共享 基于这个假设，推进了调度层面支持 POD 内的资源超卖，新的资源分配方案如下图，Service Mesh 容器的 CPU、MEM 都从 POD 中超卖出来，业务容器内仍然可以看到全部的资源。\n考虑到内存超卖也引入了 POD OOM 的风险，因此对于 Sidecar 容器还调整了 OOM Score，保证在内存不足时，Service Mesh 进程能够发挥启动比 Java 业务进程更快的优势，降低影响。\n新的分配方案解决了同时解决了以上两个问题，并且平稳支持了大促前的多轮压测。\n重建 但新的分配方案上线时，Service Mesh 已经在弹性建站时同步上线。同时我们还发现在一些场景下，Service Mesh 容器无法抢占到 CPU 资源，导致业务 RT 出现了大幅抖动，原因是在 CPU Share 模式下，POD 内默认并没有等额的分配 CPU Quota 给 Sidecar。\n于是还有两个问题待解决：\n 存量的已分配 Sidecar 仍有 OOM 风险； Sidecar 无法抢占到 CPU； 我们已经无法承受更换全部 POD 的代价。最终在调度的支持下，通过对 Pod Annotation 的手动重新计算+修改，在 POD 内进行了全部资源的重分配，来修复这两个风险。最终的修复容器总数约 25w 个。 …","date":1574859600,"description":" 本文将主要分享大规模服务网格在蚂蚁金服当前体量下落地到支撑蚂蚁金服双十一大促过程中，运维角度所面临的挑战与演进。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b4428f1c979dfa574a7ec8b4d96bc191","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","publishdate":"2019-11-27T21:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","summary":"《蚂蚁金服 Service Mesh 大规模落地系列》将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析，文末","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","wordcount":4049},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解\n 活动时间：12 月 5 日周四晚 7 点\n 活动形式：线上直播\n 直播回看：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。\n12 月 5 日周四晚 7 点，将邀请蚂蚁金服技术专家卓与 ，聚焦 RPC 层面的设计和改造方案，分享蚂蚁金服双十一核心应用如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本，并从核心、RPC、消息等模块展开本次双十一落地实践的实现细节分享。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1021\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服 Service Mesh 双十一落地详解 卓与 蚂蚁金服 Service Mesh 落地负责人\n本期分享大纲： 蚂蚁金服 Service Mesh 架构双十一大规模落地实践案例分析； 从核心、RPC、消息等模块分享蚂蚁金服 Service Mesh 落地实践细节； 欢迎先阅读Service Mesh 落地系列文章，收看直播收获更好的效果； 嘉宾 SOFAGirl 主持人 卓与 蚂蚁金服 Service Mesh 落地负责人 ","date":1574741400,"description":"12 月 5 日周四晚 7 点，线上直播第 9 期。","dir":"activities/sofa-channel-9/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"33ec75a1b0e23d96934a7ec43dfa5df5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-9/","publishdate":"2019-11-26T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-9/","summary":"概要 活动主题：SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解 活动时间：12 月 5 日周四晚 7 点 活动形式：线上直播 直播回看：戳这里 介绍 | SOFAChannel","tags":["SOFAChannel","Service Mesh"],"title":"SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解","type":"activities","url":"/sofastack.tech/activities/sofa-channel-9/","wordcount":554},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@J～杰 提问：\n 帮我看个问题，标红的这个状态没执行是啥原因？ A：没有 Next 属性，可以下载 seata-sample，里面有例子，https://github.com/seata/seata-samples。\n 好的，CompensateState 这个属性是正向失败后，重试这个状态？\n A：正向失败后，触发这个补偿状态。 https://github.com/seata/seata/tree/develop/test/src/test/java/io/seata/saga/engine 为里有很多单元测试案例，代码对应的json在：https://github.com/seata/seata/tree/develop/test/src/test/resources/saga/statelang。 正向失败后，触发这个 CompensateState 状态，但失败后并不会默认就触发补偿流程，需要在 Catch 属性里，Next 到一个 CompensateTrigger。\n 那 Saga 模式下，如果 TC 端发出回滚命令，Saga 怎么处理，没发现有回滚状态？\n A：Saga 模式的 TCC 模式有点不一样的是，Saga 的回滚不是由 TC 来协调，而是只 TC 触发，回滚流程是由状态机执行的。 https://github.com/seata/seata/blob/develop/test/src/test/resources/saga/statelang/simple_statelang_with_compensation.json\n这里是 Catch 到异常后，可以自定义捕获某些异常，然后 Next 到一个处理 state，这个 state 可以是任何 state，如果是 CompensateTrigger 则立即进行回滚。\n Saga 是通过检测异常来识别回滚命令？\n A：Catch 属性是用来检测异常的，但异常的处理可能不仅仅是进行回滚，可能有别的处理逻辑，因业务不同而不同，catch 到这些异常处理，你可以 Next 到任何一个 state 来处理异常；如果希望回滚，框架提供了 CompensateTrigger 这种一个特定的 state，Next 到 CompensateTrigger，则立即进行回滚。\n 如果一个 Saga 状态失败后，RM 一直会重试，这个重试有没有次数限制的？\n A：https://github.com/seata/seata/blob/develop/server/src/main/resources/file.conf.example 重试间隔和重试超时时间, -1是无限重试，比如可以配置成 1d ，只重度一天。\n 还有个问题，发现 catch 没有捕捉到 RuntimeExcepeion 异常： A：它走到 Fail 那个状态去了吗？另外就是 Status 是会执行的，catch 异常和状态判断是两个互不干扰的事情。\n 就是没有走到 Fail 那个状态才奇怪，刚开始我是把 Status 给去掉的，也没走，后来就加上的。这个重试是状态为 un 的时候，TC 就会一直发起重试的吧？\n A：如果没有发起过回滚（补偿流程），失败后 TC 会重试继续完成状态机正向执行，如果发了回滚，回滚失败后 TC 会重试回滚。\n 那如果发生回滚，是从哪个状态节点开始回滚的？\n A：从失败的节点开始。\n 是通过读这张表的数据 seata_state_inst？\n A：对。\nSeata：https://github.com/seata/seata\n2、@胡文伟 提问：\n 双模微服务是指什么？\n A：所谓双模，是指 SOFA 微服务和 Service Mesh 技术的双剑合璧，即“基于 SDK 的 SOFA 微服务”可以和“基于 Sidecar 的 Service Mesh 微服务”实现下列目标： 互联互通：两个体系中的应用可以相互访问； 平滑迁移：应用可以在两个体系中迁移，对于调用该应用的其他应用，做到透明无感知； 异构演进：在互联互通和平滑迁移实现之后，我们就可以根据实际情况进行灵活的应用改造和架构演进。\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.8.1，主要变更如下：\n 新增 MOSN 处理失败请求数的统计； 提升写共享内存时的性能； 优化内存占用与日志输出； 修复日志文件轮转的 Bug； 详细发布报告：https://github.com/sofastack/sofa-mosn/releases/tag/0.8.1\nSOFAChannel 直播推荐 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。聚焦 RPC 层面的设计和改造方案，分享蚂蚁金服双十一核心应用如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本，并从核心、RPC、消息等模块展开分享本次双十一落地实践的实现细节。\n你将收获：\n 蚂蚁金服 Service Mesh 架构双十一大规模落地实践案例分析； 从核心、RPC、消息等模块分享蚂蚁金服 Service Mesh 落地实践细节； 时间：2019年12月5日（周四）19:00-20:00 形式：线上直播 报名方式：点击“这里”即可报名\n","date":1574406000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191122/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d1021e16b4acefdf05a527584900ba69","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191122/","publishdate":"2019-11-22T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191122/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/18 - 11/22】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191122/","wordcount":2007},{"author":"无勤","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 作为蚂蚁金服向下一代云原生架构演进的核心基础设施，在2019年得到了大规模的应用与落地，截止目前，蚂蚁金服的 Service Mesh 数据平面 MOSN 已接入应用数百个，接入容器数量达数十万，一举成为全世界最大的 Service Mesh 集群。同时，在刚刚结束的双十一大促中，Service Mesh 的表现也十分亮眼，RPC 峰值 QPS 达到了几千万，消息峰值 TPS 达到了几百万，且引入 Service Mesh 后的平均 RT 增长幅度控制在 0.2 ms 以内。\n本文作为整个 Service Mesh 系列文章的消息篇，作者：刘翔（花名：无勤），蚂蚁金服消息 Mesh 负责人， 消息中间件核心研发成员，专注于高吞吐、低延迟的消息中间件研发，以及云原生时代下一代消息系统的架构设计与研发。本文将从以下几个方面对消息 Mesh 进行解读：\n 对消息 Mesh 进行介绍，解答消息 Mesh 在整个 Service Mesh 中的地位是什么，它又能为业务带来哪些价值； 结合蚂蚁金服消息中间件团队 Mesh 化的实践与思考，阐述如何在消息领域进行 Mesh 化改造； 消息 Mesh 在蚂蚁金服内部大规模落地过程中遇到的问题与挑战，以及对应的解决方案； 消息流量精细化调度上的思考与在 Mesh 上的实现与落地； 消息 Mesh 简介 Service Mesh 作为云原生场景下微服务架构的基础设施（轻量级的网络代理），正受到越来越多的关注。Service Mesh 不仅负责在微服务架构的复杂拓扑中可靠地传递请求，也将限流、熔断、监控、链路追踪、服务发现、负载均衡、异常处理等与业务逻辑无关的流量控制或服务治理行为下沉，让应用程序能更好地关注自身业务逻辑。\n微服务架构中的通信模式实际上是多种多样的，既包含同步的请求调用，也包含异步的消息/事件驱动，然而流行的 Service Mesh 实现（Istio，Linkerd，Consul Connect等），都仍局限在对微服务中同步请求调用的关注，却无法管理和追踪异步消息流量。而消息 Mesh 则是对这一块的重要补充，通过将消息 Mesh 有机地融合到 Service Mesh 中，可以帮助 Service Mesh 实现对所有微服务流量的管控和追踪，从而进一步完善其架构目标。\n消息 Mesh 的价值 在传统的消息中间件领域，我们更关注的是消息服务端的性能、服务可用性、数据可靠性等核心指标，而与业务应用密切相关的一些能力，包括消息的流量控制（限流、熔断、灰度、着色、分组等），消息的服务治理（消息量级与消息应用拓扑等），消息链路的追踪（消息轨迹）却往往不尽如人意。\n这不仅是因为传统模式下上述能力的提供和优化都涉及客户端的改造与大规模升级，整个过程常常比较漫长，难以快速根据有效反馈不断优化，更重要的是缺乏一个统一的架构指导思想，混乱无序地向客户端叠加相关功能只会让消息客户端变得越来越臃肿和难以维护，也变向增加了业务系统的接入、调试和排查问题的成本。而消息 Mesh 作为 Service Mesh 的补充，能显著带来如下价值和收益：\n 快速升级 - 通过将与业务逻辑无关的一些核心关键能力下沉到 Sidecar 中，使这些能力的单独快速迭代与升级成为可能； 流量控制 - 可以向 Sidecar 中集成各种流量控制策略，例如可根据消息类型、消息数量、消息大小等多种参数来控制消息的发送和消费速率； 流量调度 - 通过打通 Sidecar 节点之间的通信链路，可以利用 Sidecar 的流量转发来实现任意精度的消息流量调度，帮助基于事件驱动的微服务应用进行多版本流量管理、流量着色、分组路由、细粒度的流量灰度与A/B策略等； 消息验证 - 消息验证在基于事件驱动的微服务架构中正变得越来越重要，通过将这部分能力下沉到 Sidecar，不仅可以让业务系统无缝集成消息验证能力，也可以让 Sidecar 通过 Schema 理解消息内容，并进一步具备恶意内容识别等安全管控能力； 可观测性 - 由于所有的消息流量都必须通过 Sidecar，因此可以为 Sidecar 上的消息流量按需增加 Trace 日志，Metrics 采集，消息轨迹数据采集等能力，并借此进一步丰富消息服务的治理能力； 消息 Mesh 化改造 在蚂蚁金服内部，Msgbroker 基于推模型提供高可靠、高实时、事务消息、header 订阅等特性，帮助核心链路进行异步解耦，提升业务的可扩展能力，并先后伴随蚂蚁金服众多核心系统一起经历了分布式改造、单元化改造与弹性改造，目前主要承载蚂蚁内部交易、账务、会员、消费记录等核心在线业务的异步消息流量。\n由于 Service Mesh 的推进目标也是优先覆盖交易支付等核心链路，为在线业务赋能，因此我们优先选择对 Msgbroker 系统进行 Mesh 化改造。下面将以 Msgbroker 为例，重点剖析 Mesh 化后在整体架构和核心交互流程上的变化，为消息领域的 Mesh 化改造提供参考。\n整体架构 消息 Mesh 化后的整体架构如上图所示，与原有的消息架构相比，主要的变化有：\n 客户端不再与服务端直连，而是通过 Sidecar 进行请求的中转，对客户端而言，Sidecar 实际上是它唯一能感知到的消息服务端，对服务端而言，Sidecar 则扮演着客户端的角色； 所有 Sidecar 都会与控制平面交互，接收服务端地址列表、流量管控和调度配置、运行时动态配置等的下发，从而使数据平面具备限流、熔断、异常重试、服务发现、负载均衡、精细化流量调度等能力； 核心交互流程 当 Sidecar 代理了消息客户端的所有请求后，一旦 Sidecar 完成消息服务的发现与服务端/客户端路由数据的缓存，无论是客户端的发消息请求还是服务端的推消息请求，都能由 Sidecar 进行正确的代理转发，而这一切的关键，则是 Sidecar 与消息客户端协同完成一系列的初始化操作。\n消息 Mesh 化后具体的初始化流程如下所示，与原有的初始化流程相对比，主要有如下不同：\n 在经过 Mesh 化改造后，消息客户端不再直接向 SOFARegistry 订阅消息服务端的地址，而是将所有消息元数据（包含业务应用声明的消息 Topic、发送/订阅组 GroupId 等关键信息）通过 HTTP 请求上报给 MOSN，由 MOSN 进行元数据的持久化（用于 MOSN 异常 Crash 后的恢复）以及消息服务端地址的订阅和处理； 当客户端收到 MOSN 对于注册请求的响应时，会主动与 MOSN 建立连接，并将与该连接相关的 Group 集合信息通过控制指令发送给 MOSN，由于客户端与 MOSN 可能存在多个连接，且不同连接上的 Group 集合可以不同，而 MOSN 与同一个消息服务端只维持一个连接，因此控制指令无法向消息数据一样直接进行转发，而是需要 …","date":1574326800,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇-消息篇","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1778dffdda6a839ad3e72183df3393d6","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","publishdate":"2019-11-21T17:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","wordcount":4722},{"author":"卓与","categories":"Service mesh","content":" 2019 年的双十一是蚂蚁金服的重要时刻，大规模落地了 Service Mesh 并顺利保障双十一平稳渡过。我们第一时间与这次的落地负责人进行了交流。\n采访的开头： 花肉：“这次大规模上了 Service Mesh ，双十一值班感觉是什么？” 卓与：“Service Mesh 真的稳。”\n 图为卓与 TOP100 北京峰会分享现场图\n落地负责人介绍 Service Mesh 是蚂蚁金服下一代架构的核心，今年蚂蚁金服大规模的 Service Mesh 落地，我有幸带领并面对了这个挑战，并非常平稳的通过了双十一的大考。\n我个人主要专注在微服务领域，在服务注册与服务框架方向深耕多年，主导过第五代服务注册中心（SOFARegistry）设计与实施，在微服务的架构演进中持续探索新方向，并在蚂蚁金服第五代架构演进中负责内部 Service Mesh 方向的架构设计与落地。\nSOFAStack：https://github.com/sofastack SOFAMosn：https://github.com/sofastack/sofa-mosn\nService Mesh 在蚂蚁金服 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已经渡过探索期，今年已经全面进入深水区探索。\n2019 年的双十一是我们的重要时刻，我们进行了大规模的落地，可能是目前业界最大规模的实践。作为技术人能面对世界级的流量挑战，是非常紧张和兴奋的。当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？我们借助四个“双十一考题”一一为大家揭晓。\nService Mesh 背景知识 Service Mesh 这个概念社区已经火了很久，相关的背景知识从我们的公众号内可以找到非常多的文章，我在这里不做过于冗余的介绍，仅把几个核心概念统一，便于后续理解。\n图1. Service Mesh 开源架构来自 https://istio.io/\nIstio 的架构图上清晰的描述了 Service Mesh 最核心的两个概念：数据面与控制面。数据面负责做网络代理，在服务请求的链路上做一层拦截与转发，可以在链路中做服务路由、链路加密、服务鉴权等，控制面负责做服务发现、服务路由管理、请求度量（放在控制面颇受争议）等。\nService Mesh 带来的好处不再赘述，我们来看下蚂蚁金服的数据面和控制面产品，如下图：\n图2. 蚂蚁金服 Service Mesh 示意架构\n数据面：SOFAMosn。蚂蚁金服使用 Golang 研发的高性能网络代理，作为 Service Mesh 的数据面，承载了蚂蚁金服双十一海量的核心应用流量。\n控制面：SOFAMesh。Istio 改造版，落地过程中精简为 Pilot 和 Citadel，Mixer 直接集成在数据面中避免多一跳的开销。\n2019 Service Mesh 双十一大考揭秘 双十一 SOFAMosn 与 SOFAMesh 经历海量规模大考，顺利保障双十一平稳渡过。今年双十一蚂蚁金服的百十多个核心应用全面接入 SOFAMosn，生产 Mesh 化容器几十万台，双十一峰值 SOFAMosn 承载数据规模数千万 QPS，SOFAMosn 转发平均处理耗时 0.2ms。\n图3. 双十一落地数据\n在如此大规模的接入场景下，我们面对的是极端复杂的场景，同时需要多方全力合作，更要保障数据面的性能稳定性满足大促诉求，整个过程极具挑战。下面我们将从几个方面来分享下我们在这个历程中遇到的问题及解决方案。\n双十一考题 如何让 Service Mesh 发挥最大的业务价值？ 如何达成几十万容器接入 SOFAMosn 的目标？ 如何处理几十万容器 SOFAMosn 的版本升级问题？ 如何保障 Service Mesh 的性能与稳定性达标？ 落地架构 为了更加方便的理解以上问题的解决与后续介绍中可能涉及的术语等，我们先来看下 Service Mesh 落地的主要架构：\n图4. Service Mesh 落地架构\n以上架构图中主要分几部分：\n 数据面：借助 Kubernetes 中的 Pod 模型，SOFAMosn 以独立镜像和 App 镜像共同编排在同一个 Pod 内，共享相同的 Network Namespace、CPU、Memory，接入 SOFAMosn 后所有的 App RPC 流量、消息流量均不在直接对外，而是直接和 SOFAMosn 交互，由 SOFAMosn 直接对接服务注册中心做服务发现，对接 Pilot 做配置下发，对接 MQ Server 做消息收发等； 控制面：由 Pilot、Citadel 和服务注册中心等组件组成，负责服务地址下发、服务路由下发、证书下发等； 底层支撑：Sidecar 的接入与升级等均依赖 Kubernetes 能力，通过 webhook 做 Sidecar 的注入，通过 Operator 做 Sidecar 的版本升级等，相关运维动作均离不开底层的支撑； 产品层：结合底层提供的原子能力做运维能力封装，监控对接，采集 Sidecar 暴露的 Metrics 数据做监控与预警，流量调控，安全等产品化能力； 蚂蚁金服的答卷 1. 如何让 Service Mesh 发挥最大的业务价值？ 作为一个技术人，我们非常坚持不要为了技术革新本身去做技术革新，一定要让技术帮助业务，用技术驱动业务。这几年随着大家消费习惯以及网络行为的改变，双十一面对的业务场景远比想象中复杂。举个例子大家感受下，大家有没有发现你的女友或者老婆每天对着李佳琦的淘宝直播购物，主播们不断的、实时的红包、上新等等，带来了远比秒杀更复杂的业务场景和体量。大促的模式也更加丰富，不同场景下的大促涉及的应用是不同的，每一类应用在应对独特的洪峰时都需要有足够的资源。\n假如运营同学在不同时间点设计了两种活动，两种活动分别会对应两类不同的应用，如果这两类应用都在大促前准备充足的资源自然是轻松渡过大促峰值，但大促洪峰时间短暂，大量的资源投入有很长一段时间都处于空闲状态，这自然不符合技术人的追求。\n那么如何在不增加资源的场景下渡过各种大促呢？\n核心问题就是如何在足够短的时间内做到大规模资源腾挪，让一批机器资源可以在不同时间点承载起不同的大促洪峰。\n面对这样的挑战，我们会有怎样的解法呢？\nService Mesh 618 大促落地试点时，我们有介绍到为什么要做这个事情，核心价值是业务与基础设施解耦，双方可以并行发展，快速往前走。那么并行发展究竟能为业务带来哪些实际的价值？除了降低基础组件的升级难度之外，我们还在资源调度方向做了以下探索：\n1.1 腾挪调度 说到资源调度，最简单的自然是直接做资源腾挪，比如大促A峰值过后，大促A对应的应用通过缩容把资源释放出来，大促B对应的应用再去申请资源做扩容，这种方式非常简单，难点在于当资源规模非常庞大时，缩容扩容的效率极低，应用需要把资源申请出来并启动应用，耗时很长，假如多个大促 …","date":1574154000,"description":" 当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？我们借助四个“双十一考题”一一为大家揭晓。","dir":"blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"269c9444948a5f83a5a17f907b72ce4a","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","publishdate":"2019-11-19T17:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","summary":"2019 年的双十一是蚂蚁金服的重要时刻，大规模落地了 Service Mesh 并顺利保障双十一平稳渡过。我们第一时间与这次的落地负责人进行了交流。 采访的开头： 花肉：“这","tags":["Service mesh","Service Mesh 落地实践"],"title":"Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","wordcount":6239},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@瀚墨 提问：\n 请问 SOFARPC 本地多人开发有没有最佳实践分享一下了？\n A：你说的多人开发具体是指啥协作场景？\n 开发人员开发本地的服务时，需要依赖的服务可以来自一个开发环境！这样的开发人员就不需要启动自己本地所有的服务了。我们已经有一个开发环境，会部署所有的服务，但是当开发人员开发某一个功能时，可能只希望其中几个接口走本地，其他的接口走开发环境！\n A：你的这个开发环境是一组不确定的机器，还是一台指定 IP 的机器？\nSOFARPC：https://github.com/sofastack/sofa-rpc\n 指定的 IP 地址。\n A：一种方法本地调用方直接配开发环境的机器直连调用， 另外一个方法就是开发环境统一使用一个 uniqueId，和本地用不同的uniqueId。\n2、@温明磊 提问：\n Seata Saga 向前重试状态机 json 该怎么配置，节点代码内部和节点 json 的 catch 都不捕获异常吗，这样就会一直调用该节点。\n A：运行过程中向前重试：通过 Catch 到异常然后 Next 到当前节点（这种实现了 Retry 配置之后就不需要了），事后向前重试：直接调 forward 方法即可（一般不需要自己调，server 端会自动触发）。\n Retry 配置什么时候实现，事后向前重试是一定会发生的吗？\n A：Retry 配置正在做了。事后向前重试目前 server 端的逻辑是这样的：失败时，如果没有触发回滚，那么 server 端会不断发起重试，如果触发过回滚（也就是回滚失败了）server 端会不断触发 compensate。\n 这个没用触发回滚，是不是像我上面说的这个出错节点，代码内部没用捕获异常，json 也没有 catch 异常，然后就不断重试了。\n A：是的。\n3、@金雷-上海 提问：\n 看代码，Saga 二阶段提交成功不删分支事务？回滚也是不删，有特殊原因？\n A：你是 server 端的分支事务吗？客户端的状态机日志不会删，server 端没有显示删除分支事务，只是提交或回滚全局事务。\n 嗯，我看了代码是这样，不清楚为什么这么操作。 全局事务表删了，分支事务不删。\n A：是这样的，Saga 模式的回滚是在客户端状态机协调的，不是用 TC 协调的，TC 只是触发，客户端回滚或成功后会调 server 端上报回滚成功。所以我理解是 server 端这时会删除全局事务记录，而没有删除分支事务记录。因为是客户端协调，所以 TC 也没有循环去调每一个分支事务的 rollback，所以分支事务实际上是留下了，没有被删除。\n 既然全局事务都删除了，如果留着没有什么意义，我觉得可以删除分支事务。\n A：是的。提个 issue，修改一下。\n你提的那个 issue 修复了 ，https://github.com/seata/seata/pull/1893 同时做了一个优化，重试和补偿服务不向 Seata server 注册分支事务，仅原始服务注册分支事务，重试和补偿服务执行完成时向原始服务注册的分支事务上报成功与否的状态。\nRetry 功能，\u0026amp;rdquo;BackoffRate\u0026amp;rdquo;: 1.5，表示重试间隔增量，1.5表示本次重试间隔是上次的1.5倍：https://github.com/seata/seata/issues/1899\n还有一个点，当重试过程中生了别的异常，框架会重新匹配这个异常对应的重试规则，并按新规则来重试，但同一种规则的总次数的不会超过它配置的 MaxAttempts，避免不同异常来回切换而一直重试。\n 新规则就是下面这个配置吗？\n A： 就是你可以配置多个重试规则，根据 Exceptions 属性来匹配，下面那个没有带 Exceptions 表示框架自动匹配网络超时异常。\n 配置了 Exceptions，不只是可以匹配节点的异常，还可以匹配重试的异常，执行新的重试规则。\n A：对的。\n4、@J～杰 提问：\n 我看整个 Saga 流程引擎都是自己开发的，那个 json 的参数属性含义哪里可以参考？\n A：这是官网文档，每个属性的含义，可以看 State language referance 节。 http://seata.io/zh-cn/docs/user/saga.html\n 如果用了 @GlobalTransactional，在并发场景中，是不是还要用 @GlobalLock 保证数据的隔离性？\n A：@GlobalLock 是用于非分布式事务场景下的读分布式事务中数据。在分布式事务的场景本身有全局锁来隔离。\nSeata：https://github.com/seata/seata\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 万字长文丨1分36秒，100亿，支付宝技术双11答卷：没有不可能 SOFA 项目进展 本周发布详情如下：\n发布 SOFATracer v2.4.2\u0026amp;frasl;3.0.8，主要变更如下：\n 迁移 samples 到 sofastack-guides空间下 修复 Server Receive 阶段出现 spanId 增长问题 优化 Zipkin 远程上报问题 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.2 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.8\n云原生活动推荐  本期为 Service Mesh Meetup#8 特别场，联合 CNCF、阿里巴巴及蚂蚁金服共同举办。\n不是任何一朵云都撑得住双 11。\n成交 2684 亿，阿里巴巴核心系统 100% 上云。\n蚂蚁金服的核心交易链路大规模上线 Service Mesh。\n这次，让双 11 狂欢继续，让云原生经得起双 11 大考，也让云原生走到开发者身边。\n你将收获 3 大经验加持：\n 双 11 洗礼下的阿里巴巴 K8s 超大规模实践经验 蚂蚁金服首次 Service Mesh 大规模落地经验 阿里巴巴超大规模神龙裸金属 K8s …","date":1573801200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191115/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c08a41ec62ae153bbc0ce35958093192","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191115/","publishdate":"2019-11-15T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191115/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/11 - 11/15】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191115/","wordcount":2326},{"author":"烈元","categories":"Service mesh","content":" 揭秘 2019 Service Mesh 双十一大考 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已经渡过探索期，今年已经全面进入深水区探索。\n2019 年的双十一是我们的重要时刻，我们进行了大规模的落地。作为技术人能面对世界级的流量挑战，是非常紧张和兴奋的。当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？让我们一起来揭秘蚂蚁金服 Service Mesh 双十一实战。\nService Mesh 基础概念 Istio 清晰的描述了 Service Mesh 最核心的两个概念：数据面与控制面。数据面负责做网络代理，在服务请求的链路上做一层拦截与转发，可以在链路中做服务路由、链路加密、服务鉴权等，控制面负责做服务发现、服务路由管理、请求度量（放在控制面颇受争议）等。\nService Mesh 带来的好处不再赘述，我们来看下蚂蚁金服的数据面和控制面产品：\n 数据面：SOFAMosn。蚂蚁金服使用 Golang 研发的高性能网络代理，作为 Service Mesh 的数据面，承载了蚂蚁金服双十一海量的核心应用流量。\n 控制面：SOFAMesh。Istio 改造版，落地过程中精简为 Pilot 和 Citadel，Mixer 直接集成在数据面中避免多一跳的开销。\n 双十一落地情况概览 今年，蚂蚁金服的核心应用全面接入 SOFAMosn，生产 Mesh 化容器几十万台，双十一峰值 SOFAMosn 承载数据规模数千万 QPS，SOFAMosn 转发平均处理耗时 0.2ms。\n在如此大规模的接入场景下，我们面对的是极端复杂的场景，同时需要多方全力合作，更要保障数据面的性能稳定性满足大促诉求，整个过程极具挑战。\n同时，Service Mesh 的落地也是一个跨团队合作的典范案例，集合了核心、RPC、消息、无线网关、控制面、安全、运维、测试等团队的精诚合作，接下来我们会按照以上几个模块来解析 Service Mesh 的双十一落地情况，更多解析关注本网站。\n本文为《蚂蚁金服 Service Mesh 落地实践系列》第一篇 - 核心篇，作者：田阳（花名：烈元），蚂蚁金服技术专家，专注于高性能网络服务器研发，Tengine 开源项目核心成员，蚂蚁金服开源 SOFAMosn 项目核心成员。\n基础能力建设 SOFAMosn 的能力大图 SOFAMosn 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 XDS 等云原生能力。\n业务支持 SOFAMosn 作为底层的高性能安全网络代理，支撑了 RPC，MSG，GATEWAY 等业务场景。\nIO 模型 SOFAMosn 支持两种 IO 模型，一个是 Golang 经典模型，goroutine-per-connection；一个是 RawEpoll 模型，也就是 Reactor 模式，I/O 多路复用(I/O multiplexing) + 非阻塞 I/O(non-blocking I/O)的模式。\n在蚂蚁金服内部的落地场景，连接数不是瓶颈，都在几千或者上万的量级，我们选择了 Golang 经典模型。而对于接入层和网关有大量长链接的场景，更加适合于 RawEpoll 模型。\n协程模型 一条 TCP 连接对应一个 Read 协程，执行收包，协议解析； 一个请求对应一个 worker 协程，执行业务处理，proxy 和 Write 逻辑； 常规模型一个 TCP 连接将有 Read/Write 两个协程，我们取消了单独的 Write 协程，让 workerpool 工作协程代替，减少了调度延迟和内存占用。\n能力扩展 协议扩展\nSOFAMosn 通过使用同一的编解码引擎以及编/解码器核心接口，提供协议的 plugin 机制，包括支持：\n SOFARPC； HTTP1.x/HTTP2.0； Dubbo； NetworkFilter 扩展\nSOFAMosn 通过提供 network filter 注册机制以及统一的 packet read/write filter 接口，实现了 Network filter 扩展机制，当前支持：\n TCP proxy； Fault injection； StreamFilter 扩展\nSOFAMosn 通过提供 stream filter 注册机制以及统一的 stream send/receive filter 接口，实现了 Stream filter 扩展机制，包括支持：\n 流量镜像； RBAC鉴权； TLS 安全链路 作为金融科技公司，资金安全是最重要的一环，链路加密又是其中最基础的能力，在 TLS 安全链路上我们进行了大量的调研测试。\n通过测试，原生的 Go 的 TLS 经过了大量的汇编优化，在性能上是 Nginx(OpenSSL）的80%，Boring 版本的 Go(使用 cgo 调用 BoringSSL) 因为 cgo 的性能问题， 并不占优势，所以我们最后选型原生 Go 的 TLS，相信 Go Runtime 团队后续会有更多的优化，我们也会有一些优化计划。\n go 在 RSA 上没有太多优化，go-boring（CGO）的能力是 go 的1倍； p256 在 go 上有汇编优化，ECDSA 优于go-boring； 在 AES-GCM 对称加密上，go 的能力是 go-boring 的20倍； 在 SHA、MD 等 HASH 算法也有对应的汇编优化； 为了满足金融场景的安全合规，我们同时也对国产密码进行了开发支持，这个是 Go Runtime 所没有的。虽然目前的性能相比国际标准 AES-GCM 还是有一些差距，大概是 50%，但是我们已经有了后续的一些优化计划，敬请期待。\n平滑升级能力 为了让 SOFAMosn 的发布对应用无感知，我们调研开发了平滑升级方案，类似 Nginx 的二进制热升级能力，但是有个最大的区别就是 SOFAMosn 老进程的连接不会断，而是迁移给新的进程，包括底层的 socket FD 和上层的应用数据，保证整个二进制发布过程中业务不受损，对业务无感知。除了支持 SOFARPC、Dubbo、消息等协议，我们还支持 TLS 加密链路的迁移。\n容器升级\n基于容器平滑升级 SOFAMosn 给了我们很多挑战，我们会先注入一个新的 SOFAMosn，然后他会通过共享卷的 UnixSocket 去检查是否存在老的 SOFAMosn，如果存在就和老的 SOFAMosn 进行连接迁移，然后老的 SOFAMosn 退出。这一块的细节较多，涉及 SOFAMosn 自身和 Operator 的交互。\nSOFAMosn 的连接迁移\n连接迁移的核心主要是内核 Socket 的迁移和应用数据的迁移，连接不断，对用户无感知。\nSOFAMosn 的 metric 迁移\n我们使用了共享内存来共享新老进程的 metric 数据，保证在迁移的过程中 metric 数据也是 …","date":1573779600,"description":" 当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？让我们一起来揭秘蚂蚁金服 Service Mesh 双十一实战。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f758a3d4476cd3e8516947fa6fff5747","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","publishdate":"2019-11-15T09:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","summary":"揭秘 2019 Service Mesh 双十一大考 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","wordcount":3391},{"author":"潘潘","categories":"Service Mesh","content":" 概要 活动主题：Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动时间：2019 年 11 月 24 日（星期日）9:30-16:30 活动地点：北京朝阳大望京科技商务园区宏泰东街浦项中心B座2层多功能厅 活动形式：线下活动 活动报名：请戳这里 活动介绍 Service Mesh Meetup#8 特别场 本期为 Service Mesh Meetup#8 特别场，联合 CNCF、阿里巴巴及蚂蚁金服 共同举办。\n不是任何一朵云都撑得住双 11。\n成交 2684 亿，阿里巴巴核心系统 100% 上云。\n蚂蚁金服的核心交易链路大规模上线 Service Mesh。\n这次，让双 11 狂欢继续，让云原生经得起双 11 大考，也让云原生走到开发者身边。\n你将收获 3 大经验加持：\n 双 11 洗礼下的阿里巴巴 K8s 超大规模实践经验； 蚂蚁金服首次 Service Mesh 大规模落地经验； 阿里巴巴超大规模神龙裸金属 K8s 集群运维实践经验； 错过一次，再等一年哦。\n议程 时间 环节（分享主题） 分享嘉宾 9:00-9:30 签到 9:30-10:10 《释放云原生价值，双 11 洗礼下的阿里巴巴 K8s 超大规模实践》 曾凡松（逐灵），阿里巴巴高级技术专家；汪萌海（木苏），阿里巴巴技术专家 10:10-10:50 《蚂蚁金服双十一Service Mesh超大规模落地揭秘》 黄挺（鲁直），蚂蚁金服云原生负责人；雷志远（碧远），蚂蚁金服技术专家 10:50-11:30 《阿里巴巴超大规模神龙裸金属 K8s 集群运维实践》 周涛 （广侯），阿里巴巴高级技术专家 11:30-12:10  《深入Kubernetes的“无人区” — 蚂蚁金服双十一的调度系统》 曹寅，蚂蚁金服 Kubernetes 落地负责人 12:10-13:30 午休 13:30-14:10  《服务网格在“路口”的产品思考与实践》 宋顺（齐天），蚂蚁金服高级技术专家，开源配置中心Apollo作者 14:10-14:50 《阿里集团核心应用落地 Service Mesh 的挑战与机遇》 李云（至简），阿里巴巴高级技术专家 14:50-13:10 茶歇 15:10-15:50 《蚂蚁金服云原生 PaaS 实践之路》 王成昌（晙曦），蚂蚁金服技术专家 15:50-16:30 《函数计算在双十一小程序场景的应用》 吴天龙（木吴），阿里云函数计算技术专家 加入 SOFA 钉钉互动群 群号：23390449，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n","date":1573639200,"description":"11月24日，Service Mesh Meetup#8 双十一特别场邀您参加，本期联合 CNCF、阿里巴巴及蚂蚁金服共同举办。","dir":"activities/service-mesh-meetup-8/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f127ede30ff37760f648b79ecf887ffa","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-meetup-8/","publishdate":"2019-11-13T18:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-meetup-8/","summary":"概要 活动主题：Kubernetes \u0026amp; Cloud Native X Service Mesh Meetup 活动时间：2019 年 11 月 24 日（星期日）9:30-16:30 活动地点：北京朝阳大望京科技商务园","tags":["Meetup","Service Mesh","Kubernetes"],"title":"Kubernetes \u0026 Cloud Native X Service Mesh Meetup","type":"activities","url":"/sofastack.tech/activities/service-mesh-meetup-8/","wordcount":758},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@温明磊 提问： \u0026amp;gt; 出参入参都放在 Saga 的上下文中，如果参数内容较多较大，业务量又大的话，对内存有限制吗?\nA: 没有做限制，建议无关的参数不要放到上下文。下一个服务需要用的参数、或用于分支判断的参数可以放入上下文。\n 确认个事情：每个节点，要么自己方法内部 Catch 异常处理，使最终有返回信息。要么自己内部可以不处理，交由状态机引擎捕获异常，在 json 中定义 Catch 属性。 而不是补偿节点能够自动触发补偿，需要补偿必须手动在 json，由 Catch 或者 Choices 属性路由到 CompensationTrigger。\n A：对的，这个是为了提高灵活性。用户可以自己控制是否进行回滚，因为并不是所有异常都要回滚，可能有一些自定义处理手段。\n 所以 Catch 和 Choices 可以随便路由到想要的 state 对吧？\n A：是的。这种自定义出发补偿的设计是参考了 bpmn2.0 的。\n 还有关于 json 文件，我打算一条流程，就定义一个 json，虽然有的流程很像，用 Choices，可以解决。但是感觉 json 还是要尽量简单。这样考虑对吗？\n A：你可以考虑用子状态机来复用，子状态机会多生成一行 stateMachineInstance 记录，但对性能影响应该不大。\nService Mesh 相关阅读 从网络接入层到 Service Mesh，蚂蚁金服网络代理的演进之路\n 诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录\n Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录\n 蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录\n Service Mesh 发展趋势：云原生中流砥柱\n 企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录\n 蚂蚁金服Service Mesh新型网络代理的思考与实践 | GIAC 分享实录\n 蚂蚁金服 Service Mesh 渐进式迁移方案|Service Mesh Meetup 实录\n 蚂蚁金服 Service Mesh 实践探索 | Qcon 实录\n 干货 | 蚂蚁金服是如何实现经典服务化架构往 Service Mesh 方向的演进的？\n 活动推荐 2019年度TOP100全球软件案例研究峰会即将举行，蚂蚁金服也受邀参与本次案例分享。\nService Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。RPC、消息、DB、安全、运维等每一个环节均充满挑战。本次实战分享蚂蚁金服双十一核心应用如何大规模落地 Service Mesh 架构并降低大促成本。\n主题：《蚂蚁金服 Service Mesh 双十一实战》\n嘉宾：石建伟，花名：卓与，蚂蚁金服中间件技术专家，主要负责蚂蚁金服服务注册中心、配置中心与 Service Mesh 的研发与架构。当前专注在蚂蚁金服 Service Mesh 内部落地。\n时间：2019年11月15日（周五）16:50-17:50\n地点：北京国际会议中心\n报名方式：点击“这里”即可锁定席位\n","date":1573196400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191108/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4615f39bbae97f3f8b4b1705fcbc5d2f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191108/","publishdate":"2019-11-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191108/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/04 - 11/08】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191108/","wordcount":1255},{"author":"涵畅","categories":"Service mesh","content":" 本文作者：肖涵（涵畅）\n上篇文章《诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录》中，介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，帮助大家了解 Service Mesh 未来发展方向和前景。蚂蚁金服持续在进行 Service Mesh 布道和交流。本文内容整理自 10 月 26 日 Service Mesh Meetup#7 成都站主题演讲，现场视频以及分享 PPT 获取方式见文章底部。\n从网络硬件设备到自研平台，从传统服务治理到 Service Mesh，本文将介绍蚂蚁金服网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑起秒级百万支付，千万春晚咻一咻的。\n前言 在云计算和 SDN 下，我们经常听到流量的东西南北向概念，简单来说从外部 Internet 等到数据中心内部的流量走向被称为南北流量，数据中心内部的 VM 之间的流量被称为东西流量。\n当我们追踪南北向的网络流，请求通常会经过四层负载均衡，七层负载均衡等，这通常被我们称为网络接入层代理。当数据中心内部主动访问公网时候，流量通常也会经过 NAT 网关等做网络地址的转换，这也被我们称为网络代理。当我们把视角转向数据中心内部，网络代理的存在感似乎不是那么强，随着 SOA 的发展我们形成了各种成熟的服务通信框架，例如蚂蚁金服的 SOFAStack，阿里集团的 HSF，Google 的 gRPC 等等，网络代理功能被集成进了各种通信框架中，似乎已经 Proxyless 化了，但是随着微服务以及 Service Mesh 的架构提出，东西向的网络代理以独立的姿态又出现了。\n本文将围绕蚂蚁金服近十年网络代理的变迁，揭示整个蚂蚁金服接入层网络以及 Service Mesh 的演进过程，同时带来我们的思考。\n旧瓶新装 我们先来看看业界情况，传统四层负载均衡的代表产品当然是 IPVS，百度阿里等公司早年均对 IPVS 做了非常深度的定制功能，支撑了早期业务的飞速发展。接着也有 DPDK(阿里云 SLB)，类 DPDK 技术的代表 Google 的 Maglev 以及 eBPF 技术的代表 Facebook 的 Katran 出现。\n七层网络代理各个大厂均有产品代表，Google 的 GFE、百度 的 BFE、腾讯 的 TGW，阿里经济体内部也因为场景等原因有众多，例如手淘的 Aserver，集团 web 统一接入 Tengine，当然还有蚂蚁金服的 Spanner（后面会详细介绍）。同时随着 Service Mesh 概念的提出和技术的逐渐成熟，Mesh 中 Sidecar 角色的网络代理也像雨后春笋一样多了起来，包括蚂蚁金服的 SOFAMosn，Istio 社区方案的 Envoy 以及 Rust 编写的 Linkerd，当然 Service Mesh 场景的网络代理和网络接入层的代理我认为没有本质的差别，随着云原生的深入化，大家终将会形成合力并保持一致的形态。\n上图是2019年 Gartner Networking 方向的曲线，可以看到在上升和爆发区有着非常多的网络代理的影子（Secure Access Service Edge，Service Mesh，Edge Networking，Firewall as a Service etc.），虽然网络代理是一项古老的技术以及产品形态，但是仍然随着基础设施以及业务的变化以新的能力和角色展现在世人眼前。\n网络代理的十年 网络代理技术一直围绕“高效接入，访问加速，稳定高可用，安全合规”四个关键词，不断升级核心能力，架构以及运维能力，底层基础网络物理带宽从1G到10G、25G、100G；阿里骨干广域网络走出杭州扩展到全国、全球规模，不断地通过前瞻技术架构研发，技术自主能力的提升和转变，助力业务发展。\n蚂蚁金服应用网络架构概览 产品理念 我们应该以什么样的业务设计来满足上层业务以及市场的需要？产品理念决定了产品的走向，我们设定了网络产品的核心理念模型：\n网络产品设计理念\n接入层代理十年变迁 接入层网络代理的十年变迁之路，我们可以总结为三个时代，四个阶段：PC 时代、移动时代和万物互联云原生时代，伴随着这三个时代，我们经历了四个关键路径。\n前世 2010年前蚂蚁金服网络代理是商用设备的时代，包括 F5 的 bigip，Netscaler 等产品，对于商业设备白盒化，大家比较熟知的是去 IOE，其实网络设备走在了更前面。使用商用设备主要有几个问题，厂商的 Lockin，成本以及灵活扩展等问题，所以从2010年蚂蚁金服开始向自主研发演进。\n自主研发 我们同时开启了四七层网络接入的自研之路，四七层网络由于场景的不同，在整个演进路线上也有较大的差异。\n四层负载均衡 四层网络由于不理解业务语义，主要进化路线是伴随着系统技术，硬件技术的变化，围绕提高吞吐，降低延迟的目标而演进。2014年全面使用 DPDK 进行技术重构，将传统基于内核技术的 IPVS 新建，转发指标分别从万级，十万级提高到百万和千万级的每秒包转发。\n同时随着 Ebpf，Xdp 技术的出现，基于内核的高速转发平面产品又横空出世（包括 Facebook 开源的 Katran）打破了 DPDK 技术的垄断，同时可编程交换芯片以及 P4 语言也加入了这一站场，这里不具体讨论每种技术的优劣。\nSpanner Spanner 是蚂蚁金服的统一接入网关，其意为扳手，主要是为蚂蚁金服 SSL 卸载和网络接入提供了白盒化解决方案，承载了蚂蚁金服所有的业务流量，包括支付宝 App，Web，商户等的终端访问。\n金融级三地五中心架构的流量调度\n上图展示了 Spanner 的编年史，在2013年蚂蚁金服上架了自己的逻辑数据中心架构 LDC，同时随着演进支持了目前的蚂蚁金服金融级的三地五中心容灾架构：\n为了支持这套架构，蚂蚁金服的所有基础设施都进行了改造和技术升级，流量调拨能力作为最基础的能力，是一个基本盘，Spanner 通过对请求头的识别以及全站转发规则映射来实现流量调度，支撑并不限于以下场景：\n 机房内随机路由； 蓝绿发布； 容灾： 逻辑机房内容灾； 机房级别； 城市级别； 弹性调度； 压测流量调度； 灰度流量调度； SSL/TLS 实践\n蚂蚁金服作为全集团最早实践 https 全站的 BU，一直围绕着安全，合规，性能的主题进行全站加密体系的建设。\n成本之战\n前面提到2012年 Spanner 全面上线后，我们接入层具备了定制业务逻辑的能力，在2013年很好支撑了 LDC 的上线，同时我们在性能成本方面也有机会去进行持续的提升，同年我们引入 SSL 加速卡软硬件一体解决方案，从现在来看该套方案已经非常成熟了，集团 Tengine，Openssl 都提供了非常方便的接入框架，但是当年这一块还一直处于探索阶段。我们在 Spanner 里做了 Nginx 的 SSL 握手异步化改造，改造了 Openssl 同 Cavium 的 SSL 加速卡进行适配，整套方案在当时的机型上较 CPU 提升了基于 RSA2048 算法的 SSL 握手3倍的性能，同时也对后续各大厂商在这方面的实践产生了指导性意 …","date":1573030800,"description":" 从网络硬件设备到自研平台，从传统服务治理到 Service Mesh，本文将介绍蚂蚁金服网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑起秒级百万支付，千万春晚咻一咻的。","dir":"blog/antfin-service-mesh-network-agents/","fuzzywordcount":7600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b539a4c29754f9e761c2027426566250","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-service-mesh-network-agents/","publishdate":"2019-11-06T17:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/antfin-service-mesh-network-agents/","summary":"本文作者：肖涵（涵畅） 上篇文章《诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录》中，介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，帮助大家了","tags":["Service mesh"],"title":"从网络接入层到 Service Mesh，蚂蚁金服网络代理的演进之路","type":"blog","url":"/sofastack.tech/blog/antfin-service-mesh-network-agents/","wordcount":7507},{"author":"敖小剑","categories":"Service mesh","content":" 2019 年，蚂蚁金服在 Service Mesh 领域继续高歌猛进，进入大规模落地的深水区。本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的演讲，他介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，以及大规模落地时遇到的困难和解决方案，助你了解 Service Mesh 的未来发展方向和前景。\n 前言 大家好，我是敖小剑，来自蚂蚁金服中间件团队，今天带来的主题是“诗和远方：蚂蚁金服 Service Mesh 深度实践”。\n在过去两年，我先后在 QCon 做过两次 Service Mesh 的演讲：\n 2017年，当时 Service Mesh 在国内还属于蛮荒时代，我当时做了一个名为“Service Mesh: 下一代微服务”的演讲，开始在国内布道 Service Mesh 技术； 2018年，做了名为“长路漫漫踏歌而行：蚂蚁金服 Service Mesh 实践探索”的演讲，介绍蚂蚁金服在 Service Mesh 领域的探索性的实践，当时蚂蚁金服刚开始在 Service Mesh 探索。 今天，有幸第三次来到 QCon，给大家带来的依然是蚂蚁金服在 Service Mesh 领域的实践分享。和去年不同的是，今年蚂蚁金服进入了 Service Mesh 落地的深水区，规模巨大，而且即将迎来双十一大促考验。\n 备注：现场做了一个调研，了解听众对 Servicve Mesh 的了解程度，结果不太理想：在此之前对 Service Mesh 有了解的同学目测只有10%多点（肯定不到20%）。Service Mesh 的技术布道，依然任重道远。\n 今天给大家带来的内容主要有三块：\n 蚂蚁金服落地情况介绍：包括大家最关心的双十一落地情况； 大规模落地的困难和挑战：分享一下我们过去一年中在大规模落地上遇到的问题； 是否采用 Service Mesh 的建议：这个问题经常被人问起，所以借这个机会给出一些中肯的建议供大家参考； 蚂蚁金服落地情况介绍 发展历程和落地规模 Service Mesh 技术在蚂蚁金服的落地，先后经历过如下几个阶段：\n 技术预研 阶段：2017年底开始调研并探索 Service Mesh 技术，并确定为未来发展方向； 技术探索 阶段：2018年初开始用 Golang 开发 Sidecar SOFAMosn，年中开源基于 Istio 的 SOFAMesh； 小规模落地 阶段：2018年开始内部落地，第一批场景是替代 Java 语言之外的其他语言的客户端 SDK，之后开始内部小范围试点； 规模落地 阶段：2019年上半年，作为蚂蚁金融级云原生架构升级的主要内容之一，逐渐铺开到蚂蚁金服内部的业务应用，并平稳支撑了618大促； 全面大规模落地 阶段：2019年下半年，在蚂蚁金服内部的业务中全面铺开，落地规模非常庞大，而且准备迎接双十一大促； 目前 ServiceMesh 正在蚂蚁金服内部大面积铺开，我这里给出的数据是前段时间（大概9月中）在云栖大会上公布的数据：应用数百个，容器数量（pod 数）超过10万。当然目前落地的pod数量已经远超过10万，这已经是目前全球最大的 Service Mesh 集群，但这仅仅是一个开始，这个集群的规模后续会继续扩大，明年蚂蚁金服会有更多的应用迁移到 Service Mesh。\n主要落地场景 目前 Service Mesh 在蚂蚁金服内部大量落地，包括支付宝的部分核心链路，落地的主要场景有：\n 多语言支持：目前除了支持 Java 之外，还支持 Golang，Python，C++，NodeJS 等语言的相互通信和服务治理； 应用无感知的升级：关于这一点我们后面会有特别的说明； 流量控制：经典的 Istio 精准细粒度流量控制； RPC 协议支持：和 Istio 不同，我们内部使用的主要是 RPC 协议； 可观测性； Service Mesh 的实际性能数据 之前和一些朋友、客户交流过，目前在 Service Mesh 方面大家最关心的是 Service Mesh 的性能表现，包括对于这次蚂蚁金服 Service Mesh 上双十一，大家最想看到的也是性能指标。\n为什么大家对性能这么关注？\n因为在 Service Mesh 工作原理的各种介绍中，都会提到 Service Mesh 是将原来的一次远程调用，改为走 Sidecar（而且像 Istio 是客户端和服务器端两次 Sidecar，如上图所示），这样一次远程调用就会变成三次远程调用，对性能的担忧也就自然而然的产生了：一次远程调用变三次远程调用，性能会下降多少？延迟会增加多少？\n下图是我们内部的大促压测数据，对比带 SOFAMosn 和不带 SOFAMosn 的情况（实现相同的功能）。其中 SOFAMosn 是我们蚂蚁金服自行开发的基于 Golang 的 Sidecar/数据平面，我们用它替代了 Envoy，在去年的演讲中我有做过详细的介绍。\nSOFAMosn：https://github.com/sofastack/sofa-mosn\n CPU：CPU 使用在峰值情况下增加8%，均值约增加2%。在最新的一次压测中，CPU 已经优化到基本持平（低于1%）； 内存：带 SOFAMosn 的节点比不带 SOFAMosn 的节点内存占用平均多 15M； 延迟：延迟增加平均约0.2ms。部分场景带 SOFAMosn 比不带 SOFAMosn RT 增加约5%，但是有部分特殊场景带 SOFAMosn 比不带 SOFAMosn RT 反而降低7.5%； 这个性能表现，和前面\u0026amp;rdquo;一次远程调用变三次远程调用\u0026amp;rdquo;的背景和担忧相比有很大的反差。尤其是上面延迟的这个特殊场景，居然出现带 SOFAMosn（三次远程调用）比不带 SOFAMosn（一次远程调用） 延迟反而降低的情况。\n是不是感觉不科学？\nService Mesh 的基本思路 我们来快速回顾一下 Service Mesh 实现的基本思路：\n在基于 SDK 的方案中，应用既有业务逻辑，也有各种非业务功能。虽然通过 SDK 实现了代码重用，但是在部署时，这些功能还是混合在一个进程内的。\n在 Service Mesh 中，我们将 SDK 客户端的功能从应用中剥离出来，拆解为独立进程，以 Sidecar 的模式部署，让业务进程专注于业务逻辑：\n 业务进程：专注业务实现，无需感知 Mesh； Sidecar 进程：专注服务间通讯和相关能力，与业务逻辑无关； 我们称之为\u0026amp;rdquo;关注点分离\u0026amp;ldquo;：业务开发团队可以专注于业务逻辑，而底层的中间件团队（或者基础设施团队）可以专注于业务逻辑之外的各种通用功能。\n通过 Sidecar 拆分为两个独立进程之后，业务应用和 Sidecar 就可以实现“独立维护”：我们可以单独更新/升级业务应用或者 Sidecar。\n性能数据背后的情景分析 我们回到前面的蚂蚁金服 Service Mesh 落地后的性能对比数据：从原理上说，Sidecar 拆分之后，原来 SDK 中的各种功能只是拆分到 Sidecar 中。整体上并没有增减，因 …","date":1572922800,"description":" 本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的演讲。","dir":"blog/service-mesh-antfin-deep-practice-qcon/","fuzzywordcount":12500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"561edcf88763b36e72894da214d2b123","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","publishdate":"2019-11-05T11:00:00+08:00","readingtime":25,"relpermalink":"/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","summary":"2019 年，蚂蚁金服在 Service Mesh 领域继续高歌猛进，进入大规模落地的深水区。本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的","tags":["Service mesh"],"title":"诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","wordcount":12438},{"author":"屹远","categories":"Seata","content":" Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的 Saga 模式。 项目地址：https://github.com/seata/seata\n本文作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。\n金融分布式应用开发的痛点 分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。\u0026amp;mdash;《左耳听风-弹力设计之“补偿事务”》\n而在金融领域微服务架构下的业务流程往往会更复杂，流程很长，比如一个互联网微贷业务流程调十几个服务很正常，再加上异常处理的流程那就更复杂了，做过金融业务开发的同学会很有体感。\n所以在金融分布式应用开发过程中我们面临一些痛点：\n 业务一致性难以保障 我们接触到的大多数业务（比如在渠道层、产品层、集成层的系统），为了保障业务最终一致性，往往会采用“补偿”的方式来做，如果没有一个协调器来支持，开发难度是比较大的，每一步都要在 catch 里去处理前面所有的“回滚”操作，这将会形成“箭头形”的代码，可读性及维护性差。或者重试异常的操作，如果重试不成功可能要转异步重试，甚至最后转人工处理。这些都给开发人员带来极大的负担，开发效率低，且容易出错。\n 业务状态难以管理 业务实体很多、实体的状态也很多，往往做完一个业务活动后就将实体的状态更新到了数据库里，没有一个状态机来管理整个状态的变迁过程，不直观，容易出错，造成业务进入一个不正确的状态。\n 幂等性难以保障 服务的幂等性是分布式环境下的基本要求，为了保证服务的幂等性往往需要服务开发者逐个去设计，有用数据库唯一键实现的，有用分布式缓存实现的，没有一个统一的方案，开发人员负担大，也容易遗漏，从而造成资损。\n 业务监控运维难，缺乏统一的差错守护能力 业务的执行情况监控一般通过打印日志，再基于日志监控平台查看，大多数情况是没有问题的，但是如果业务出错，这些监控缺乏当时的业务上下文，对排查问题不友好，往往需要再去数据库里查。同时日志的打印也依赖于开发，容易遗漏。对于补偿事务往往需要有“差错守护触发补偿”、“工人触发补偿”操作，没有统一的差错守护和处理规范，这些都要开发者逐个开发，负担沉重。\n理论基础 一些场景下，我们对数据有强一致性的需求时，会采用在业务层上需要使用“两阶段提交”这样的分布式事务方案。而在另外一些场景下，我们并不需要这么强的一致性，那就只需要保证最终一致性就可以了。\n例如蚂蚁金服目前在金融核心系统使用的就是 TCC 模式，金融核心系统的特点是一致性要求高（业务上的隔离性）、短流程、并发高。\n而在很多金融核心以上的业务（比如在渠道层、产品层、集成层的系统），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务（如金融网络）。这是如果每个服务都开发 Try、Confirm、Cancel 三个方法成本高。如果事务中有其它公司的服务，也无法要求其它公司的服务也遵循 TCC 这种开发模式。同时流程长，事务边界太长会影响性能。\n对于事务我们都知道 ACID，也很熟悉 CAP 理论最多只能满足其中两个，所以，为了提高性能，出现了 ACID 的一个变种 BASE。ACID 强调的是一致性（CAP 中的 C），而 BASE 强调的是可用性（CAP 中的 A）。我们知道，在很多情况下，我们是无法做到强一致性的 ACID 的。特别是我们需要跨多个系统的时候，而且这些系统还不是由一个公司所提供的。BASE 的系统倾向于设计出更加有弹力的系统，在短时间内，就算是有数据不同步的风险，我们也应该允许新的交易可以发生，而后面我们在业务上将可能出现问题的事务通过补偿的方式处理掉，以保证最终的一致性。\n所以我们在实际开发中会进行取舍，对于更多的金融核心以上的业务系统可以采用补偿事务，补偿事务处理方面在30年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较也公认 Saga 是作为长事务的解决方案。 \u0026amp;gt; https://github.com/aphyr/dist-sagas/blob/master/sagas.pdf \u0026amp;gt; http://microservices.io/patterns/data/saga.html\n社区和业界的方案 Apache Camel Saga Camel 是实现 EIP（Enterprise Integration Patterns）企业集成模式的一款开源产品，它基于事件驱动的架构，有着良好的性能和吞吐量，它在2.21版本新增加了 Saga EIP。\nSaga EIP 提供了一种方式可以通过 camel route 定义一系列有关联关系的 Action，这些 Action 要么都执行成功，要么都回滚，Saga 可以协调任何通讯协议的分布式服务或本地服务，并达到全局的最终一致性。Saga 不要求整个处理在短时间内完成，因为它不占用任何数据库锁，它可以支持需要长时间处理的请求，从几秒到几天，Camel 的 Saga EIP 是基于 Microprofile 的 LRA（Long Running Action），同样也是支持协调任何通讯协议任何语言实现的分布式服务。\nSaga 的实现不会对数据进行加锁，而是在给操作定义它的“补偿操作”，当正常流程执行出错的时候触发那些已经执行过的操作的“补偿操作”，将流程回滚掉。“补偿操作”可以在 Camel route 上用 Java 或 XML DSL（Definition Specific Language）来定义。\n下面是一个 Java DSL 示例：\n// action from(\u0026amp;quot;direct:reserveCredit\u0026amp;quot;) .bean(idService, \u0026amp;quot;generateCustomId\u0026amp;quot;) // generate a custom Id and set it in the body .to(\u0026amp;quot;direct:creditReservation\u0026amp;quot;) // delegate action from(\u0026amp;quot;direct:creditReservation\u0026amp;quot;) .saga() .propagation(SagaPropagation.SUPPORTS) .option(\u0026amp;quot;CreditId\u0026amp;quot;, body()) // mark the current body as needed in the compensating action .compensation(\u0026amp;quot;direct:creditRefund\u0026amp;quot;) .bean(creditService, \u0026amp;quot;reserveCredit\u0026amp;quot;) .log(\u0026amp;quot;Credit ${header.amount} …","date":1572861600,"description":" 一起来解读 Seata Saga 模式到底解决了什么问题。","dir":"blog/seata-saga-flexible-financial-applications/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9c17449b81e0f1fe51d46bbaeaaa5516","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-saga-flexible-financial-applications/","publishdate":"2019-11-04T18:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/seata-saga-flexible-financial-applications/","summary":"Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的","tags":["Seata"],"title":"基于 Seata Saga 设计更有弹性的金融应用","type":"blog","url":"/sofastack.tech/blog/seata-saga-flexible-financial-applications/","wordcount":6384},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@罗健 提问： \u0026amp;gt; SOFAJRaft 跨机房支持吗？\nA： 跨机房不需要特殊支持，只是网络延时大一点而已。\n 延时大了，读写性能就会降低了吧？ 像 ZooKeeper 一样。\n A：1. SOFAJRaft 支持 transfer leader，把 leader transfer 到和业务就近的机房（目前需要手动调用 cli 服务）； 2. SOFAJRaft 1.3.0 会增加一个选举优先级特性，可以将指定机房节点优先级调高，尽量保证 leader 在指定机房。 SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@阮仁照 提问： \u0026amp;gt; SOFAArk 在打多个 ark-biz 包时，如果有多个 biz 包之间互相调用，默认是会走 injvm 协议的，这是如何做到的。我看了 SOFABoot 那块对 injvm 的支持，是通过 sofaRuntimeContext 来查找实现类，sofaRuntimeContext 是被 spring 容器管理的 bean，这就要求多个 biz 包之间是共用一套 spring 环境（或者说有个统一的父容器），是这样的吗？还是有什么其他实现的思路？\nA：可以看下 com.alipay.sofa.runtime.invoke.DynamicJvmServiceProxyFinder 这个类。\n 懂了，原来在这之上还有个 SofaFramework维护一个静态变量，真巧妙，用这个来解决多个 spring 容器里的 rpc 调用问题吗？\n A：多个 spring 容器之间的调用，不是 rpc 调用，是进程内调用。\n 对的， 这里不是 rpc 调用了， 所以这里也是 filter 会失效的原因。这样的话，那 SofaFramework 这个类就要被所有子容器都共享才对，但是我看打出来的 executable-ark 包，并没有在 classpath 下加载这个类啊，子容器咋共享的？\n A：这个会打包成一个插件，放在 ark plugin 层。 既然说插件之间是隔离的，那你把 SofaFramework 打在插件里，别的 biz 包启动时从会从 plugin里拿一个 SofaFramework ，互相不可见，这不是有问题吗？\n A：不同 biz 会共享同一个。 SOFAArk：https://github.com/sofastack/sofa-ark\n3、@温明磊 提问： \u0026amp;gt; Seata 的 Saga 模式的 json 文件，支持热部署吗？\nA：支持，stateMachineEngine.getStateMachineConfig().getStateMachineRepository().registryByResources()。不过 Java 代码和服务需要自己实现支持热部署。\n Seata 服务部署集群是需要怎么配置? 还是现在不支持\n A：异步执行一个服务，已实现。https://github.com/seata/seata/issues/1843\n Saga 的参数是不是只能在状态机启动时定义。如果第二个服务，依赖第一个服务返回的信息，或者里面组装好的信息怎么办？\n A：有个 Output 参数定义，可以把服务返回的参数映射到状态机上下文，然后在下一个服务的 Input 里定义参数引用。\n 异步执行服务的话，需要在 file 加上这个配置吗? A：这个是状态机定义的 Json 文件，不是 Seata 的客户端配置文件。 Seata：https://github.com/seata/seata\n本周推荐阅读 备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？\n K8s 1.14 发布了，Release Note 该怎么读？\n SOFA 项目进展 本周发布详情如下：\n发布 SOFAMosn v0.8.0，主要变更如下： i. 内存占用优化，优化在连接数、并发数较多的场景下的内存占用 ii. Metrics 统计优化，RPC 心跳场景不计入 QPS 等 Metrics 统计 iii. XDS 处理优化，修改为完全无阻塞启动，并且降低了重试的频率 详细发布报告，请见： https://github.com/sofastack/sofa-mosn/releases/tag/0.8.0\n","date":1572591600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191101/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cd5f758d6d5d28784524b55169ae0a98","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191101/","publishdate":"2019-11-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191101/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/28 - 11/01】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191101/","wordcount":1512},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:ArkLab/\u0026amp;gt;是《剖析 | SOFAArk 源码》系列，会逐步详细介绍 SOFAArk 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFAArk SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力。在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\nSOFAArk :https://github.com/sofastack/sofa-ark\n|\u0026amp;lt; SOFA:ArkLab/\u0026amp;gt; 认领列表：\n 【已完成】轻量级类隔离框架 SOFAArk 简介 【已认领】 SOFAArk 容器模型解析 【已认领】 SOFAArk 类加载模型机制解析 【已认领】 SOFAArk 合并部署能力解析 【已认领】 SOFAArk SPI 机制和 ClassLoaderHook 机制解析 【已认领】 SOFAArk 动态配置机制解析 【已认领】 SOFAArk maven 打包插件解析 【已认领】 （实践）SOFAArk 插件化机制解析与实践 领取方式：关注「金融级分布式架构」 回复可领取的文章标题，我们将会主动联系你，确认资质后，即可加入 SOFA:ArkLab/，It\u0026amp;rsquo;s your show time！\n 如果有同学对以上某个主题特别感兴趣的，可以留言讨论，我们会适当根据大家的反馈调整文章的顺序，谢谢大家关注 SOFAStack ，关注 SOFAArk，我们会一直与大家一起成长的。\n除了源码解析，也欢迎提交 issue 和 PR： SOFAArk :https://github.com/sofastack/sofa-ark\n欢迎领取，参与共建~\n","date":1572408000,"description":"欢迎参与 SOFAArk 源码解析系列文章共建。","dir":"activities/sofa-ark-lab/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"02869baa65a4730cea247cf1763d920c","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-ark-lab/","publishdate":"2019-10-30T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-ark-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:ArkLab/\u0026gt;是《剖析 | SOFAArk 源码》系列，会逐步详细介","tags":["SOFALab","SOFAArk","剖析 | SOFAArk 源码"],"title":"\u003cSOFA:ArkLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-ark-lab/","wordcount":572},{"author":"沧漠","categories":"Kubernetes","content":" 本文 PPT 下载\n导读：Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统，它大幅降低了容器化应用部署的门槛，但运维和管理一个生产级的高可用 Kubernetes 集群仍十分困难。本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。\nKubernetes 以其超前的设计理念和优秀的技术架构，在容器编排领域拔得头筹。越来越多的公司开始在生产环境部署实践 Kubernetes，在阿里巴巴和蚂蚁金服 Kubernetes 已被大规模用于生产环境。\n系统概览 Kubernetes 集群管理系统需要具备便捷的集群生命周期管理能力，完成集群的创建、升级和工作节点的管理。在大规模场景下，集群变更的可控性直接关系到集群的稳定性，因此管理系统可监控、可灰度、可回滚的能力是系统设计的重点之一。除此之外，超大规模集群中，节点数量已经达到 10K 量级，节点硬件故障、组件异常等问题会常态出现。面向大规模集群的管理系统在设计之初就需要充分考虑这些异常场景，并能够从这些异常场景中自恢复。\n设计模式 基于这些背景，我们设计了一个面向终态的集群管理系统。系统定时检测集群当前状态，判断是否与目标状态一致，出现不一致时，Operators 会发起一系列操作，驱动集群达到目标状态。这一设计参考控制理论中常见的负反馈闭环控制系统，系统实现闭环，可以有效抵御系统外部的干扰，在我们的场景下，干扰对应于节点软硬件故障。\n架构设计 如上图，元集群是一个高可用的 Kubernetes 集群，用于管理 N 个业务集群的 Master 节点。业务集群是一个服务生产业务的 Kubernetes 集群。SigmaBoss 是集群管理入口，为用户提供便捷的交互界面和可控的变更流程。元集群中部署的 Cluster-Operator 提供了业务集群集群创建、删除和升级能力，Cluster-Operator 面向终态设计，当业务集群 Master 节点或组件异常时，会自动隔离并进行修复，以保证业务集群 Master 节点达到稳定的终态。这种采用 Kubernetes 管理 Kubernetes 的方案，我们称作 Kube on Kube 方案，简称 KOK 方案。业务集群中部署有 Machine-Operator 和节点故障自愈组件用于管理业务集群的工作节点，提供节点新增、删除、升级和故障处理能力。在 Machine-Operator 提供的单节点终态保持的能力上，SigmaBoss 上构建了集群维度灰度变更和回滚能力。\n核心组件 集群终态保持器 基于 K8s CRD，在元集群中定义了 Cluster CRD 来描述业务集群终态，每个业务集群对应一个 Cluster 资源，创建、删除、更新 Cluster 资源对应于实现业务集群创建、删除和升级。Cluster-Operator watch Cluster 资源，驱动业务集群 Master 组件达到 Cluster 资源描述的终态。业务集群 Master 组件版本集中维护在 ClusterPackageVersion CRD 中，ClusterPackageVersion 资源记录了 Master 组件（如：api-server、controller-manager、scheduler、operators 等）的镜像、默认启动参数等信息。Cluster 资源唯一关联一个 ClusterPackageVersion，修改 Cluster CRD 中记录的 ClusterPackageVersion 版本即可完成业务集群 Master 组件发布和回滚。\n节点终态保持器 Kubernetes 集群工作节点的管理任务主要有：\n 节点系统配置、内核补丁管理； docker / kubelet 等组件安装、升级、卸载； 节点终态和可调度状态管理（如关键 DaemonSet 部署完成后才允许开启调度）； 节点故障自愈。 为实现上述管理任务，在业务集群中定义了 Machine CRD 来描述工作节点终态，每一个工作节点对应一个 Machine 资源，通过修改 Machine 资源来管理工作节点。\nMachine CRD 定义如下图所示，spec 中描述了节点需要安装的组件名和版本，status 中记录有当前这个工作节点各组件安装运行状态。除此之外，Machine CRD 还提供了插件式终态管理能力，用于与其它节点管理 Operators 协作，这部分会在后文详细介绍。\n工作节点上的组件版本管理由 MachinePackageVersion CRD 完成。MachinePackageVersion 维护了每个组件的 rpm 版本、配置和安装方法等信息。一个 Machine 资源会关联 N 个不同的 MachinePackageVersion，用来实现安装多个组件。\n在 Machine、MachinePackageVersion CRD 基础上，设计实现了节点终态控制器 Machine-Operator。Machine-Operator watch Machine 资源，解析 MachinePackageVersion，在节点上执行运维操作来驱动节点达到终态，并持续守护终态。\n节点终态管理 随着业务诉求的变化，节点管理已不再局限于安装 docker / kubelet 等组件，我们需要实现如等待日志采集 DaemonSet 部署完成才可以开启调度的需求，而且这类需求变得越来越多。如果将终态统一交由 Machine-Operator 管理，势必会增加 Machine-Operator 与其它组件的耦合性，而且系统的扩展性会受到影响。因此，我们设计了一套节点终态管理的机制，来协调 Machine-Operator 和其它节点运维 Operators。设计如下图所示：\n 全量 ReadinessGates: 记录节点可调度需要检查的 Condition 列表； Condition ConfigMap: 各节点运维 Operators 终态状态上报 ConfigMap； 协作关系：\n 外部节点运维 Operators 检测并上报与自己相关的子终态数据至对应的 Condition ConfigMap； Machine-Operator 根据标签获取节点相关的所有子终态 Condition ConfigMap，并同步至 Machine status 的 conditions 中； Machine-Operator 根据全量 ReadinessGates 中记录的 Condition 列表，检查节点是否达到终态，未达到终态的节点不开启调度。 节点故障自愈 我们都知道物理机硬件存在一定的故障概率，随着集群节点规模的增加，集群中会常态出现故障节点，如果不及时修复上线，这部分物理机的资源将会被闲置。\n为解决这一问题，我们设计了一套故障发现、隔离、修复的闭环自愈系统。\n如下图所示，故障发现方面，采取 Agent 上报和监控系统主动探测相结合的方式，保证了故障发现的实时性和可靠性（Agent 上报实时性比较好，监控系统主动探测可以覆盖 Agent 异常未上 …","date":1572246000,"description":"本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。","dir":"blog/ant-financial-managing-large-scale-kubernetes-clusters/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0fbce82d736863f9039c6a8f15c6f5d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","publishdate":"2019-10-28T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","summary":"本文 PPT 下载 导读：Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统，它大幅降低了容器化应用部署的门槛，但运维和管理一个生产级","tags":["Kubernetes"],"title":"备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？","type":"blog","url":"/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","wordcount":4899},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@罗健 提问：\n 请问，SOFAJRaft 跨机房支持吗？\n A：跨机房不需要特殊支持，只是网络延时大一点而已。\n 延时大了，读写性能就会降低了吧？ 像 ZooKeeper 一样。\n A：1. SOFAJRaft 支持 transfer leader，把 leader transfer 到和业务就近的机房（目前需要手动调用 cli 服务） 2. SOFAJRaft 1.3.0 会增加一个选举优先级特性，可以将指定机房节点优先级调高，尽量保证 leader 在指定机房。\n2、@梁开心 提问：\n 使用 Seata 的时候，现在是 AT 模式 如果改成 Saga 模式的话，改造会大吗？\n A：AT 模式完全是透明的，Saga 是有侵入性的，要配置状态机 json，如果服务多改造会比较大。\n Saga 模式是不是基于 AT 来加强的长事务处理呢？\n A：没有基于 AT，客户端完全是两套，Server 端是复用的。你也可以看 Saga 的单元测试，那里有很多示例：https://github.com/seata/seata/tree/develop/test/src/test/java/io/seata/saga/engine\n Saga 服务流程可以不配置吗，使用全局事务 id 串起来，这样省去配置的工作量，再加上人工配置难免会配置错误。\n A：Saga 一般有两种实现，一种是基于状态机定义，比如 apache camel saga、eventuate，一种是基于注解+拦截器实现，比如 service comb saga，后者是不需要配置状态图的。由于 Saga 事务不保证隔离性, 在极端情况下可能由于脏写无法完成回滚操作, 比如举一个极端的例子, 分布式事务内先给用户 A 充值, 然后给用户B扣减余额, 如果在给 A 用户充值成功, 在事务提交以前, A 用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了，有些业务场景可以允许让业务最终成功, 在回滚不了的情况下可以继续重试完成后面的流程, 基于状态机引擎除可以提供“回滚”能力外, 还可以提供“向前”恢复上下文继续执行的能力, 让业务最终执行成功, 达到最终一致性的目的，所以在实际生产中基于状态机的实现应用更多。后续也会提供基于注解+拦截器实现。\n3、@温明磊 提问：\n 关于 Saga 的使用，有两个问题咨询下 1、比如有服务 A 在系统1里面，服务 B 在系统2里面。全局事务由 A 开启，流程调用 B 开启子事务，那系统2也需要维护 Saga 状态机的三个表吗，也需要在 Spring Bean 配置文件中配置一个 StateMachineEngine 吗？\n2、如果 系统1和系统2里面的服务，可以相互调用。系统12都可以开启全局事务，可以这样使用吗。那1和2 都需要维护Saga状态机的三个表，也需要在Spring Bean配置文件中配置一个StateMachineEngine。\n A：1、不需要，只在发起方记录日志。由于只在发起方记录日志同时对参与者服务没有接口参数的要求，使得Saga可以方便集成其它机构或遗留系统的服务。 2、可以这样使用，如果两个系统都开启 Saga 事务，那就要记录那三个表配置 StateMachineEngine。\n 这个 EventQueue 只是开启分布式事务的系统 来进行事件驱动，调用其它系统服务像调用本地一样。系统之间还是 RPC 调用是吧，而不是系统之前也是纯事件驱动的？ A：是的。你指的\u0026amp;rdquo;系统之间也是纯事件驱动的\u0026amp;rdquo; 是不是说 RPC 也是非阻塞的？\n 是的，也可以是异步的。\n A：那 RPC 的非阻塞需要 rpc client 支持，理论上也是可以的。rpc client 如果也是非阻塞 IO，那么所有环节都是异步了。\n 就是考虑一个业务流程， 它后续的子流程， 不管谁先运行都不会相互影响，可以异步调用。子流程是其它系统服务。Seata Saga 是不是实现了这点，其实我没看明白 ，Seata Saga 异步调用具体是不是各个节点异步了。是不是两个 ServiceTask 类型，可以同时 process ？\n A：你说的是并发节点类型，还未实现，接下来会实现。目前的事件驱动是指的节点的执行是事件驱动的，流程的顺序是同步的。上一个节点执行完成后，产生事件，触发下一个节点执行。如果要满足你刚说的需求要扩展并发节点。\n 那目前区分同步 BUS 和异步 BUS 是什么作用？\n A：同步 BUS 是线程阻塞的，等整个状态机执行完毕才返回，异步 BUS 是非线程阻塞的，调用后立即返回，状态机执行完毕后回调你的 Callback。\n IsPersist: 执行日志是否进行存储，默认是 true，有一些查询类的服务可以配置在 false，执行日志不进行存储提高性能，因为当异常恢复时可以重复执行？\n A：是的，可以配置成 false, 不过建议先保持默认，这样在查询执行日志比较全，真的要做性能调优再配，一般不会有性能问题。\n每周推荐阅读 蚂蚁金服开源背后的“有意思”工程师 | 1024快乐 蚂蚁金服云原生专家招聘 | 1024有你更快乐 SOFA 项目进展 本周发布详情如下：\n1、Occlum 是一个多任务、内存安全的库操作系统，专门针对可信执行环境（如 Intel SGX）。\n发布 Occlum v0.6.0，主要变更如下： i. 支持 release 模式运行 enclave，轻松发布基于 Occlum 的 SGX 应用； ii. 给 SEFS 增加额外的 MAC 和权限检查，保证 Occlum 的 FS 镜像的完整性； iii. 重构底层错误处理机制，使得报错对用户友好，且附带详细的调试信息； iv. 增加3个新 demo，包括 Bazel、HTTPS file server 和 Tensorflow Lite； v. 在 Docker 镜像中默认安装 Occlum，使得用户开箱即用； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.6.0\n2、发布SOFARPC v5.5.9，主要变更如下： …","date":1571986800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191025/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7927ee3392339de5283b8c4e75f9b4e9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191025/","publishdate":"2019-10-25T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191025/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/21 - 10/25】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191025/","wordcount":2571},{"author":"SOFAStack","categories":"1024","content":" !important 希望我们是最早给你祝福的朋友\n去年的1024，我们回顾了第一代到第五代架构 去年的今天，我们和大家分享了 SOFAStack 背后的这群工程师。比如程立，花名鲁肃，蚂蚁金服 CTO。胡喜，蚂蚁金服副总裁、副CTO。杨冰，蚂蚁金服智能科技产品技术部总监。\n也与大家分享了从第一代到第五代架构的进化历程，详解了 SOFAStack 走的这一条跟传统金融行业不同的分布式架构之路。要基于不可靠的硬件系统实现金融级的性能和可靠性，要应对支付宝这样的超大规模互联网金融应用，有很多难题要解决。蚂蚁金服构建了一整套处理金融级交易的分布式架构与平台，在金融级的一致性要求和海量并发处理能力上达到了很好的平衡，并在快速容灾恢复、弹性伸缩能力、多地多活高可用保证能力和按需供给的精细化资源调度能力方面沉淀了丰富的实践经验。\n前往去年此刻的时光机：蚂蚁金服自研架构SOFA背后的工程师|1024快乐\n今年，SOFAStack 团队在忙什么呢？ 近几年来，“云原生架构”的相关话题讨论比较热烈，我们也相信这也将是金融 IT 架构的关键发展趋势之一。IT 架构转型绝不是一蹴而就的，积极探索和应用以“云原生”为代表的新兴技术的同时，还需考虑与传统模式和技术融合并存，沿着一条稳妥的可落地路径进行创新变革，确保架构转型的价值交付能够稳妥支撑甚至积极引领业务创新。\nService Mesh 是蚂蚁金服下一代架构的核心，这一年，我们在奔跑的火车上换轮子，将现有的微服务架构快速演进到云原生架构。RPC、消息、DB、安全、运维等每一个环节均充满挑战。\n蚂蚁金服每年双十一大促会面临非常大的流量挑战，在已有 LDC 微服务架构下已支撑起弹性扩容能力。当有多个大促分阶段进行时，如何在架构上保障资源最大程度复用降低大促成本极具挑战。期望在最小规模的资源集群下可通过灵活的架构来支撑起快速的资源腾挪来达成多个大促链路最大化利用资源的目的。通过 Service Mesh 架构的支持，基础设施层在应用外具备更强的管控能力，通过流量的调拨，JVM 内存的动态 Swap 等手段可以使用技术手段达成节省资源的目的。 今年即将到来的双十一，蚂蚁金服这套 Service Mesh 将迎来第一次大考 — 双十一实战，也或许是业界第一个如此大规模的实战，请持续关注本公众号，我们会逐步进行技术揭秘。\n今天，我们想介绍蚂蚁金服开源背后的这位“有意思”工程师： 对于蚂蚁金服研究员王益而言，2019年是个颇有纪念意义的年份。今年他整40岁。从10岁开始，写代码整30年。这30年来，他当过“不务正业”的学生，创纪录地在大一就考下系统分析员，“单枪匹马”闯荡过从国内到硅谷的多家知名互联网科技公司，和AI领域许多传奇人物都有所交集。不惑之年对于许多工程师来说，或许已是需要焦虑的年龄，但40岁的王益在蚂蚁金服每天都过得很充实：起床，自由泳一千米，然后去做他最喜欢的事——写代码和组织大家一起写代码。\n 2019年9月11日，在上海举办的Google开发者大会上，蚂蚁金服研究员王益分享了新开发的分布式深度学习系统ElasticDL。这是他来到蚂蚁金服的一年之中所做的第二个开源项目，主要用于大幅提升集群总体利用率以及深度学习团队的工作效能。之前开源的 SQLFlow系统在短短的几个月之间，已经在GitHub上获得了三千多颗星星。\n2019对于王益而言是个颇有纪念意义的年份，今年他整40岁，写代码整30年。 这听上去是一件不可思议的事——30年前，上世纪的80年代末，他在⻓沙上小学，全城都很难找出一位能教编程的老师，个人电脑更是一个陌生名词，一台以苹果2为原型、可以用BASIC语言编程的 “中华学习机”售价7000人民币，在当时几乎可以买下一套房子。\n幸运的是，王益在10岁那年得到了这样一件贵重的礼物，从这台学习机和一本BASIC语言教材开始，他开启了与代码结缘的人生。\n“我那时不是个好学生，经常受‘别人家的孩子’打击，老师和同学都觉得写代码是不务正业。”回想起30年来的经历，这位清华博士、足迹从国内到硅谷历经多家知名互联网科技公司的学霸笑谈自己“活得比较任性”，“但我就是想做与众不同的事。别人越说这样不行，我就越想用这种方式证明自己。”\n初中毕业那年的暑假，他用“中华学习机”和自己焊接的电路板，把自家的老式“威力牌”双筒洗衣机改造成了自动洗衣机。同时，他用Apple BASIC语言和6502汇编混合编程，写了人生中第一个游戏。高中三年，其他同学努力备考，他却加班加点自学了大学计算机系所有课程，随后参加计算机水平考试，先后获得了程序员、高级程序员、以及最高级别系统分析员资格。2018年，他获得Google APAC Innovation Award。从不断摸索代码世界的少年时代，到专注于AI基础架构和系统开发的求学工作生涯，这份“任性”一直伴随他走到今天。\n“我经常从零开始。选择去做什么的一大标准是‘有意思’。”\n相比于规划一条稳妥的职业发展道路，王益更愿意顺应自己强烈的好奇心，去选择最困难但最有意思的探索方向。他在中国和美国互联网公司都工作过，也分别在美国公司的中国分部和中国公司的美国分部工作过。他的足迹遍及国内BAT三家。任性的是，每次跳槽， 他都从一个人coding一个创新项目开始，吸引同事们加入，从而组建团队。虽然2011年就在腾讯作为广告系统技术总监，但是他从不在跳槽时要求带何等规模的团队。\n2014年，王益带着妻子和两个月大的女儿离开腾讯移居硅谷。“一切都归零了。工资减半。”他笑笑说。不过凭着多位学界和业界领袖的推荐，他很快就安顿下来，不到一年就开始在硅谷创业，作为Head of Research Scienets 参与创建了AI创业公司 ScaledInference。这是一家人才济济的创业公司。人工智能行业的领袖人物、加州大学伯克利分校的Michael Jordan教授是这家公司顾问。陆奇曾代表微软到访，讨论技术合作。“可惜我们不够关注业务落地，做的不够好。技术研发一定要有落地的能力。”事后，王益不无遗憾的说。\n在加入蚂蚁金服之前，王益在百度硅谷研究院工作，负责开源深度学习系统PaddlePaddle。在历经两年的艰苦开发，新一代技术Fluid开始系统地落地百度各个业务之后，他发起了他在 PaddlePaddle的最后一个子项目——一条太阳能驱动的无人驾驶船。这是一条双体船，由他和五岁女儿的两条划艇构成。船上的笔记本电脑运行基于immitation learning的人工智能系统，自动学习驾驶者的技巧。为了船体稳定，他在自家车库里焊接了连接两条划艇的金属框架。便于拆装的结构，可以装上他的皮卡，方便下水测试。\n做出加入蚂蚁金服的决定，也是出于同样的理由——“有意思”。“这里的业务很新颖，对AI 有着更加多样化的需求。”如何用AI解决金融行业的问题，是和他以往所面对的完全不同的全新挑战。 SQLFlow：分析师与AI模型间的翻译  加入蚂蚁金服不久，王益就意识到自己之前的朦胧猜想越来越清晰地被验证：和主要依靠流量与广告赚钱的传统互联网公司不同，蚂蚁金服不是纯互联网公司，它有独特的商业模式和对于工具的独到需求。\n此前的十多年中，他的大部分经历是在传统互联网 …","date":1571883840,"description":"不管世界如何，永远永远希望开发者能感觉技术“有意思”，永远希望开发者快乐不复杂。","dir":"blog/ant-financial-happy-1024/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c89decd5fb9b75c59f487dc58bac0365","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-happy-1024/","publishdate":"2019-10-24T10:24:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/ant-financial-happy-1024/","summary":"!important 希望我们是最早给你祝福的朋友 去年的1024，我们回顾了第一代到第五代架构 去年的今天，我们和大家分享了 SOFAStack 背后的这群工程师。比如程立，花名鲁肃","tags":["1024"],"title":"蚂蚁金服开源背后的“有意思”工程师 | 1024快乐","type":"blog","url":"/sofastack.tech/blog/ant-financial-happy-1024/","wordcount":5806},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@温明磊 提问： \u0026amp;gt; 最近在选型 Zeebe 还是 Seata Saga 来实现微服务编排。Zeebe 使用了基于行业标准 BPMN 2.0 的可视工作流。 但是考虑到 Seata 的开源和生态，如果 Seata 能实现流程可视就好了。\nA：未来我们会做可视化的也可以社区贡献。另外给一个调研服务编排选型的建议，遵循 bpmn 2.0 行业标准没有问题的，不过 bmpn2.0 xml 格式太复杂了，我们微服务的编排不需要那么多标签，另外微服务的编排里有很重要一块就是要保证编排的服务的事务一致性，所以需有能支持分布式事务的处理能力，这里面就会涉及服务的状态判断定义，异常处理定义，复杂服务参数的映射，这些在 bpmn 2.0 标准里是没有定义的（当然框架可以在扩展节点里自己扩展）。用 json 定义之后，你会发现其实有没有可视化开发工具没有那么重要了，只是如果有个可视化监控更好。\n 是的，json 我们都可以自己组装。只要把业务接口做成可视可配，完全可以用配置信息组装 json。这样说不知道对不对。但是像您说的，有个可视化的工具 肯定要更好点。\n A：是的，json 还有一个好处是，服务调用的参数可以直接在 json 里组织好。\nSOFARegistryLab 系列阅读 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 云原生推荐阅读 云原生时代，什么是蚂蚁金服推荐的金融架构？ 当金融科技遇上云原生，蚂蚁金服是怎么做安全架构的？ SOFA 项目进展 发布 Seata v0.9.0，主要变更如下：\ni. 长事务解决方案: Saga 模式（基于状态机实现） ii. 支持自定义配置和注册中心类型 iii. 支持 spring cloud config 配置中心 iv. 修复对象锁和全局锁可能造成的死锁和优化锁的粒度 v. 修复 oracle 的批量获取问题 vi. 优化了一些基于 java5 的语法结构 vii. 抽象 undologManager 的通用方法\n详细发布报告： https://github.com/seata/seata/releases/tag/v0.9.0\n云原生活动推荐 Service Mesh Meetup 是由蚂蚁金服联合 CNCF 官方共同出品，ServiceMesher 社区主办，主题围绕服务网格、Kubernetes 及云原生，在全国各地循环举办的技术沙龙。\n本期 Meetup 邀请社区大咖，从服务网格下微服务架构设计、在 5G 时代的应用、如何使用开源的 Traefik 构建云原生边缘路由及蚂蚁金服的服务网格代理演进角度给大家带来精彩分享。\n时间：2019年10月26日（周六）13:00-17:0 0地点：成都武侯区蚂蚁C空间 报名方式：点击这里，即可锁定席位\n","date":1571382000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191018/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"91ccf1c351bfb03d7e18f70fad5f5224","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191018/","publishdate":"2019-10-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191018/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/14 - 10/18】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191018/","wordcount":1198},{"author":"力鲲","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第五篇，本篇作者力鲲，来自蚂蚁金服。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n回顾：服务注册 SOFARegistry 作为服务注册中心，面临的一个很重要的挑战就是如何解决海量的客户端连接问题，这也是本文要剖析的内容。不过作为一篇完整的文章，我们还是会先花一点时间介绍 SOFARegistry 的相关信息，以便读者了解其背景。\n服务注册中心在服务调用的场景中，扮演一个“中介”的角色，服务发布者 (Publisher) 将服务发布到服务注册中心，服务调用方 (Subscriber) 通过访问服务注册中心就能够获取到服务信息，进而实现调用。\n图1 - 服务的“中介”\n流程：订阅 / 发布 在《海量数据下的注册中心 - SOFARegistry 架构介绍》一文中，我们提到了一个典型的 “RPC 调用的服务寻址” 应用场景，服务的提供方通过如下两个步骤完成服务发布：\n 注册，将自己以 Publisher 的角色注册到 SOFARegistry； 发布，将需要发布的数据 (通常是IP 地址、端口、调用方式等) 发布到 SOFARegistry； 与此相对应的，服务的调用方通过如下步骤实现服务调用：\n 注册，将自己以 Subscriber 的角色注册到 SOFARegistry； 订阅，收到 SOFARegistry 推送的服务数据； 从上面我们可以看到，整个流程中很重要的一个步骤就是注册，不管是 Publisher 还是 Subscriber 都只能在注册成功后才能实现发布订阅的需求。因此 SOFARegistry 要解决的一个问题就是如何维护与 Client 连接而产生的 Session，尤其是当 Client 数量众多的时候。\n图2 - 海量啊海量\n设计：分层隔离 在 SOFARegistry 的应用场景中，体量庞大的数据主要有两类：Session 数据、服务信息数据。两类数据的相同之处在于其数据量都会不断扩展，而不同的是其扩展的原因并不相同：Session 是对应于 Client 的连接，其数据量是随着业务机器规模的扩展而增长，而服务信息数据量的增长是由 Publisher 的发布所决定。所以 SOFARegistry 通过分层设计，将两种数据隔离，从而使二者的扩容互不影响。\n图3 - 分层，扩容互不影响\n当然，对于分层设计的概念介绍，在《海量数据下的注册中心 - SOFARegistry 架构介绍》的 “如何支持海量客户端” 章节已经有了很完整的介绍，这里不再赘述。本文是想从代码层面来看看其设计实现的方式。\n通信 Exchange Exchange 作为 Client / Server 连接的抽象，负责节点之间的连接。在建立连接中，可以设置一系列应对不同任务的 handler (称之为 ChannelHandler)，这些 ChannelHandler 有的作为 Listener 用来处理连接事件，有的作为 Processor 用来处理各种指定的事件，比如服务信息数据变化、Subscriber 注册等事件。\n图4 - 每一层各司其职，协同实现节点通信\nSession 节点在启动的时候，利用 Exchange 设置了一系列 ChannelHandler：\n PublisherHandler SubscriberHandler\n WatcherHandler\n ClientNodeConnectionHandler\n CancelAddressRequestHandler\n SyncConfigHandler\n 其中 SubscriberHandler 和 PublisherHandler 主要是与服务发布方 (Publisher) 以及服务调用方 (Subscriber) 的行为相关，我们在下面说明。\n任务处理 由于 SubscriberHandler 在 Session 节点启动时就已经初始化并设置，所以当有 Subscriber 注册时，就由 SubscriberHandler 负责后续一系列的处理逻辑。\n图5 - Subscriber 的注册过程\n上面的流程图展示了 Subscriber 注册的处理过程，SessionSever 在处理注册请求时，除了保存 Subscriber 的会话信息，还要为新注册的 Subscriber 提供其所订阅的服务信息数据，最后通过推送的方式将数据发送 Subscriber。\n下面是上述流程在代码模块上的实现，我们依然用图的方式展示出来，大家按图索骥也便于查阅相关源码中的细节。\n图6 - 代码流转：Subscriber 注册\n可以看到，SOFARegistry 采用了 Handler - Task \u0026amp;amp; Strategy - Listener 的方式来应对服务注册中的各种场景和任务，这样的处理模型能够尽可能的让代码和架构清晰整洁。\nPublisher 的注册过程和 Subscriber 基本一致，略有不同的是 Publisher 在注册完毕之后将要发布的数据写到 DataServer 上。\n图7 - Publisher 的注册过程\n这个过程也是采用了 Handler - Task \u0026amp;amp; Strategy - Listener 的方式来处理，任务在代码内部的处理流程和订阅过程基本一致。\n图8 - 代码流转：Publisher 注册\n会话缓存 在二层架构中 (即 Client 直接连接 DataServer)，连接数是一个很难收敛的指标，因为当一个 Subscriber 订阅的服务位于不同 DataServer 上时，他就会与多个 DataServer 同时保持连接，这样“每台 DataServer 承载的连接数会随 Client 数量的增长而增长，每台 Client 极端的情况下需要与每台 DataServer 都建连，因此通过 DataServer 的扩容并不能线性的分摊 Client 连接数”。\n图9 - 两层结构中，扩容无法减少连接数\n这也是 SOFARegistry 设计三层模型的原因，通过 SessionServer 来负责与 Client 的连接，将每个 Client 的连接数收敛到 1，这样当 Client 数量增长时，只需要扩容 SessionServer 集群就可以了。 所以从设计初衷上我们就能够看出来 SessionServer 必须要满足的两个主要能力： …","date":1571223600,"description":" 本文为《剖析 | SOFARegistry 框架》第五篇，作者力鲲","dir":"blog/sofa-registry-session-storage/","fuzzywordcount":2900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5ae2be3be1d395dd7ccb2bddc97b346f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-session-storage/","publishdate":"2019-10-16T19:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-registry-session-storage/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心 Session 存储策略 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-session-storage/","wordcount":2821},{"author":"杨延昭","categories":"云原生","content":" 蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀，以及面向未来的金融技术创新和参会者分享。我们将其中的优秀演讲整理成文并将陆续发布在本网站，本文为其中一篇。\n 本文作者：杨延昭（杨冰），蚂蚁金服智能科技产品技术部总监\n互联网技术发展日新月异，我们正在进入云原生时代，这个过程中金融行业要如何拥抱云原生？在近两年蚂蚁金服将云原生在金融领域落地，沉淀下一些实践经验，接下来我想分享在蚂蚁的演进过程当中，我们心中的云原生是什么样的，在金融领域落地的时候遇到什么问题，以及我们是怎么解决的。\n经过多年云计算的蓬勃发展，上云已经不是太大问题，接下来的问题是怎么把云用好，用得更高效。RightScale 2019年最新数据显示，现在公有云规模占22%，只使用私有云的客户占3%，更多客户通过混合的模式去使用云，通过混合云取得数据隐私、安全与效率、弹性的平衡。\n再看全球整个 IT 行业，公有云的比例只占整个基础 IT 市场的10%，市场空间仍然很大，IT 市场中剩下很多都是传统企业客户。为什么传统行业无法很好地利用公有云，一个重要的原因是因为他们的 IT 系统经过很长时间建设，很多都有自己的机房。另外有些则业务比较稳定，对上公有云没有很强的需求。它们通常会发展混合云策略，把一些核心业务留在私有云，而把一些边缘业务或创新业务放在公有云上。\n这些特点在金融行业也非常明显，除此之外金融行业还有两个特征：\n 业务形态走向开放和互联网化：随着互联网和数字化经济的发展，金融机构需要进行数字化转型，以及业务敏捷化、服务场景化，以应对新的商业模式带来的冲击； 监管合规的诉求：金融行业的业务特点决定了必须是强隔离，强监管的，所以公有云上的资源共享模式在监管方面会有比较大的挑战。 因此，混合云战略对金融机构更为适用。这一结论也得到研究支持，根据调研机构 Nutanix 的报告，全球金融业在混合云应用方面的发展速度超过其它行业，目前部署普及率达到21%，而全球平均水平为18.5%。\n那么，什么样的混合云是适合金融机构的呢？以蚂蚁的演进历程为例。\n蚂蚁在第四代架构的时候演变成为云平台架构，而且为了应对互联网业务形态下突发性业务对资源的弹性需求，蚂蚁也在同一阶段将架构直接进化成弹性混合云架构。现在蚂蚁已经演进到第五代云原生架构。蚂蚁又是如何在云原生的架构下，把混合云变成金融级的混合云，我想会对各位有些启发。在这个发展过程中，有一条主线，是不同阶段蚂蚁对研发的标准和要求，包括：自主、成本、安全、稳定、海量、敏捷，这也是在在线金融的时代，我们对云原生架构的要求。\n从分布式到云原生 建立金融级交易支付系统  建立金融级的在线交易系统，第一步是要实现金融级分布式的架构，蚂蚁在这方面的代表技术是 SOFAStack 和 OceanBase，目前都已对外商业化，并有丰富的案例。SOFAStack 代表的是，在整个应用层或者无状态服务这个层面上，如何去做可伸缩、可扩展的一套架构。OceanBase 代表的是以数据库为代表的存储或者是有状态服务层面，如何在架构上面去进行分布式。它们拥有四个特性：\n 高可用，99.99%+的可用性保证，确保系统始终连续运行不中断； 一致性，在任何异常情况下数据最终一致，确保资金安全； 可扩展，支持应用级、数据库级、机房级、地域级的快速扩展； 高性能，存储采用读写分离架构，计算引擎全链路性能优化，准内存数据库性能。 而这四个关键的特性都是金融业务最为看重的，而且需要在应用和存储上端到端实现。 以一致性为例，在单个数据库内是可以确保数据一致性的，但在大规模应用的情况下，单个数据库总是会出现瓶颈，数据往往会像服务或者应用一样，按照类似交易、支付、账目等粒度垂直拆开，当这些数据分别存储在不同的数据库集群后，就需要在应用层来解决一致性问题了，同时为了支持海量数据，数据库集群内部也会做分别和多副本，OceanBase 就是这样一套分布式数据库，在其内部也要实现分布式事务。只有这样上下配合才能解掉所有分布式架构下的一致性问题，缺一不可。\n再比如可扩展性方面，有些系统号称做了分布式架构，实际可能只是用了微服务框架，做了应用层的服务化改造，但数据库层既没有用水平扩展的技术，也没用分布式数据库，整个系统的可扩展性就卡在数据层的短板上。\n所以，真正的分布式系统，需要实现端到端的分布式，才能实现无限可扩展和高性能，而真正的金融级分布式系统则要实现端到端的高可用和一致性。\n蚂蚁金服三地五中心异地多活架构我们认为，高可用架构最关键的目标是数据不丢，业务不停。在这个目标的基础上，我们设计并实施了三地五中心的异地多活架构。它的核心优势包括城市级容灾，低成本交易，无限可扩展，以及 RPO=0，PTO\u0026amp;lt;30s. 大家知道我们在去年云栖大会上做了一次剪网线的demo，它演示了整个架构层面上怎么样做到跨城市多活和灾难情况下的恢复快速恢复能力。同时在高可用达标的情况下，我们也做了很多风险相关的事情，总结起来就是在高可用的基础上还要做到资金的安全、变更的免疫和故障的快速恢复。\n解决了高可用的问题，其实金融级最被高频提到的话题就是安全，在云原生时代，我们要解决的是全链路、端到端的安全风险。具体分为三个层面：\n 云原生网络安全，包括策略化高效流量控制，全链路加密，流量劫持与分析； 云原生基础设施安全，包括安全容器，不共享内核，以及安全沙箱； 云原生业务安全，包括 SOFAEnclave 机密计算中间件，以及内存安全的、多任务 Enclave LibOS Occlum。  这个部分我的同事在《金融服务的云原生安全架构》演讲中会详细介绍。小结一下，所谓金融级的能力，最主要是要实现端到端的金融级的高可用，同时实现端到端的安全。接下来我想分享的是，在云原生这个阶段往前走遇到了哪些问题。\n从单元化到弹性架构 应对互联网爆炸式的流量脉冲  从单元化到云原生下的弹性架构\n首先解释下什么是单元化，大家可能比较容易理解数据库层的分库分表或者说 Sharding，能够通过分片的方式解决集中存储计算性能问题，单元化的核心思想是把数据的分片提前到了入口请求的分片，在机房的网络接入层将用户请求根据某个纬度（比如用户 ID）进行 Sharding，这就好比把每个机房就当做了一个巨大无比的有状态的数据库分片，当你是一个 ID 尾号为007或者008用户的时候，当请求通过手机端或者网页域名发送到机房，接入层就已经识别出应该将你路由到华东地区还是在华南地区。当你进入到某个地区的机房时，大部分请求处理工作可以在机房内部完成。偶尔会有一些业务可能会发生跨机房的服务调用，比如说数据在 A 机房的用户给数据在 B 机房的用户转账。这个时候就需要在这个机房上去做有状态的设计。\n我们走向云原生时代的时候，在大的架构上面用 Kubernetes 为基础来设计，在单元化架构下，我们选择在每个单元里部署一个 Kubernetes 集群，将支持多 K8s 集群管理和管控指令下发的 Federated APIServer 做逻辑上的全局部署，其中管控元数据是存储在一个 ETCD 集群的，以保持全局数据一 …","date":1571209200,"description":"本文将分享在蚂蚁金服的演进过程当中，我们心中的云原生是什么样的，在金融领域落地的时候遇到什么问题，以及我们是怎么解决的。","dir":"blog/ant-financial-native-cloud-financial-architecture/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b0fce431d72c523e27e31f1fe831fdee","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","publishdate":"2019-10-16T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","summary":"蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀","tags":["云原生"],"title":"云原生时代，什么是蚂蚁金服推荐的金融架构？","type":"blog","url":"/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","wordcount":5366},{"author":"何征宇","categories":"云原生","content":" 蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀，以及面向未来的金融技术创新和参会者分享。我们将其中的优秀演讲整理成文并将陆续发布在“ 金融级分布式架构”公众号上，本文为其中一篇。\n 本文作者：何征宇，gVisor 创始人，蚂蚁金服研究员\n在云原生发展趋势之下，金融行业想要应用云原生技术，安全问题是一个非常大的拦路虎，而云原生社区对安全问题的重视程度远远不够。蚂蚁金服在落地云原生的时候，解决安全问题是重中之重，经过探索与实践，我们沉淀出了一套从底层硬件到软件、从系统到应用层的全链路金融级云原生安全架构。\n金融行业最重要的就是信任，我们认为，安全所带来的信任，是一种无形的产品，支撑着所有金融业务。\n顺应互联网时代发展，金融行业与机构也发生了很多的变化，包括 App、小程序等更多的访问渠道，更快的业务变化，更多的第三方供应商。但是，不管怎么变化，金融行业有一点始终不变，那就是 Zero Fault，对错误的零容忍，也就是对稳定性和安全性的极高要求。\n这里，我还想澄清大家对金融行业的一个错误看法，就是，大家都说金融机构有很多遗留系统，很多技术是十几年前的，就认为金融机构的技术是落后的。但其实，金融行业一直是科技含量非常高的。前段时间有一部电影上映，叫《蜂鸟计划》，根据真实事件改编，讲一帮做高频交易的人，为了降低从堪萨斯到纽约交易所的时间，建造了一条上千英里直通两地的光纤，想尽办法去争取那最后一毫秒。所以，金融行业并不只有平庸保守的科技，它同样也在追逐最前沿最先进的技术，我们的使命就是要用科技来进一步武装金融行业，为金融科技注入更多的活力。\n云原生架构其实代表一种新的生产力，金融行业肯定是需要云原生的，它为我们带来了节约成本和敏捷开发的能力，但是在它前面还需要加一个定语，就是安全的云原生架构，它里面不仅仅包含之前的相对简单的安全方案，而是一个从端到端的全链路可信的安全解决方案。包括明晰代码所有权，做到可信启动，对镜像的制作和发布收口，配合账号体系，明晰应用的所有权和访问权限；以及安全可独立部署的精细化隔离方案，将安全策略和实施集成在基础架构中，对软件开发和测试透明。\n这里我们着重分享蚂蚁金服正在实践的几项云原生安全技术，包括云原生网络安全 Service Mesh，安全容器，以及机密计算。\n云原生网络安全：SOFAMesh  当前，云原生里除了容器之外第二大技术其实就是 Service Mesh，从蚂蚁的实践来看，其实它对金融安全有非常高的帮助。它至少可以做到三点：\n 策略化高效流量控制，可以帮助运维迅速适应业务快速变化； 全链路加密，保护端到端数据安全； 流量劫持与分析，当发现异常流量与容器时，进行流量阻断。 并且，这些工作对业务是透明的，不需要给业务开发增加负担，同时我们还可以对流量进行实时的语义分析等等，做比传统的防火墙更多的事情。\n蚂蚁金服在对 Service Mesh 的探索中，推出了自己用 Golang 打造的 SOFAMesh，并且已经对外开源，希望和社区一起努力，让 Service Mesh 的理念和技术更加普及。\nSOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强大功能和丰富特性的基础上，为满足大规模部署下的性能要求以及应对落地实践中的实际情况，所做的改进包括采用 Golang 编写的 SOFAMosn 取代 Envoy，极大降低了 Mesh 本身的开发难度，并做了一些创新性工作，例如合并Mixer到数据平面以解决性能瓶颈，增强 Pilot 以实现更灵活的服务发现机制，增加对 SOFARPC、Dubbo 的支持，等等。\n更多详情可查看 SOFAMesh 的 GitHub 主页：https://github.com/sofastack/sofa-mesh\n蚂蚁金服率先在生产环境中大规模落地 SOFAMesh，超过 10W+ 容器做到了 Mesh 化，平稳支撑了 618 大促，给我们带来了多协议支持、UDPA、平滑升级、安全等多方面的好处，并且对性能仅有轻微的影响，单跳 CPU 增加 5% 损耗，RT增加不到 0.2ms，甚至部分业务经过 Mesh 化改造将业务链路下沉，RT 反而下降 7%。\n安全容器：Kata Containers  传统容器架构\n提云原生大家肯定都会提容器，传统容器从虚拟机到容器，其实是牺牲了隔离性的，从上图可以很清楚的看到，当我们的应用在容器里，其实共享着同一个 CPU、内存、网络和存储，只是从外面看起来是不同的。这会导致安全上的问题，就是不同的容器之间不存在真正的隔离，一旦一个容器发生安全问题，很可能影响到其它容器，甚至入侵整个系统。蚂蚁金服在这方面做的工作就是安全容器，具体就是 Kata Containers。\n安全容器架构\nKata Containers 安全容器是 OpenStack 基金会的顶级开放基础设施项目，由蚂蚁金服和 Intel 共同主导开发。在安全容器里，每个 Pod 运行在独立的沙箱中，彼此不共享内核，提供强安全保障。这里给大家分享一下 Kata Containers 的近期进展，针对大家最关注的性能问题有了非常大的提升：\n 引入 shimv2 每 Pod 辅助进程数量从 2N+2 减少到 1 个； 引入 virtiofs，提升文件系统性能约 70% 到 90%； 引入 Firecracker， VMM 内存开销从 60MB 降到约 15MB； 改用 rust 实现 agent，占用内存从 11MB 下降到约 1MB。 我们也会和社区一起继续共建 Kata Containers，让安全容器成为云原生的标配。\n安全容器可以有效的保护主机，但是，金融业务本身仍然需要更强的隔离保护，蚂蚁金服引入了机密计算，并根据实际场景研发了大规模落地解决方案 SOFAEnclave。\n机密计算中间件：SOFAEnclave 所谓机密计算，也就是基于例如 Inte SGX，ARM Trustzone 等可信执行环境（Trusted Execution Environment, TEE），也称为 Enclave ，访问计算机内存时隔离用户数据，以避免将数据暴露给其他应用程序、操作系统或其他云服务器租户的解决方案。\nEnclave架构\nEnclave 是运行时的双向保护，比如说你的金融业务跑在 Enclave 上的时候，操作系统都看不到 Enclave 里的内存，同时会进行完整性检查，保证访问 Enclave 的代码不被替换。\n但是 Enclave 目前存在一些问题，阻碍了它在实际生产环境中的应用。总结这些问题包括：\n第一，需要改写应用，因为可信执行环境里面没有内核和基础库，所以没法把应用直接在 Enclave 中执行；第二，需要分割应用，需要把业务程序划分为 Enclave 内和 Enclave 外的部分；第三，未集群化，与客户端场景不同，Enclave 中的应用如何 failover，容灾也是阻止其在数据中心中大规模使用的一个原因。 …","date":1571036400,"description":"本文着重分享蚂蚁金服正在实践的几项云原生安全技术，包括云原生网络安全 Service Mesh，安全容器，以及机密计算。","dir":"blog/ant-financial-native-cloud-security-architecture/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d65835b57ec0e3e24af2c65db5f41824","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","publishdate":"2019-10-14T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","summary":"蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀","tags":["云原生"],"title":"当金融科技遇上云原生，蚂蚁金服是怎么做安全架构的？","type":"blog","url":"/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","wordcount":3402},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@陈文龙 提问：\n 请问一下，使用 Seata 时，undo_log 表的 rollback_info 字典的内容为｛｝（相当于空），事务回滚后记录又没被清除，而服务的日志打出的是成功回滚，log_status 是 1，这是什么原因呢？\n A：1 是防御性的，是收到 globalrollback 回滚请求，但是不确定某个事务分支的本地事务是否已经执行完成了，这时事先插入一条 branchid 相同的数据，插入的假数据成功了，本地事务继续执行就会报主键冲突自动回滚。假如插入不成功说明表里有数据这个本地事务已经执行完成了，那么取出这条 undolog 数据做反向回滚操作。\n相关阅读：分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾\nSOFARegistryLab 系列阅读 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 活动推荐 2019中国开源年会 (COSCon\u0026amp;rsquo;19) 正式启动啦~\n时间： 2019-11-02 09:00 ~ 11-03 17:00\n地址： 上海普陀区中山北路3663号华东师范大学（中北校区）\n本次大会的主题是“开源无疆、携手出航”（Let’s Cross the Boundaries Together!），这也代表主办方对于中国开源，走向世界，走向辉煌的殷切期望。\nSOFAStack 开源社区也受到主办方的邀请参加此次开源年会。\n更多重磅议题与开源嘉宾，点击“这里”，即可了解。\n","date":1570777200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191011/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"98ed37338b0cd1036114b205bcb980c2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191011/","publishdate":"2019-10-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191011/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/7 - 10/11】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191011/","wordcount":776},{"author":"明不二","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第四篇，本篇作者明不二。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 在前面的章节中我们已经提到，SOFARegistry 与其他服务发现领域的产品相比，最大的不同点在于支持海量数据。本章即将讲述 SOFARegistry 在支撑海量数据上的一些特性。\n本文将从如下几个方面进行讲解：\n DataServer 总体架构：对 SOFARegistry 中支持海量数据的总体架构做一个简述，讲解数据分片和同步方案中所涉及到的关键技术点； DataServer 启动：讲解 DataServer 启动的服务，从而为接下来更直观地理解数据分片、数据同步的触发时机以及触发方式等做一个铺垫； 数据分片：讲解 SOFARegistry 中采用的一致性 Hash 算法进行数据分片的缘由以及具体实现方法； 数据同步方案：讲解 SOFARegistry 采用的数据同步方案； DataServer 总体架构 在大部分的服务注册中心系统中，每台服务器都存储着全量的服务注册数据，服务器之间通过一致性协议（paxos、Raft 等）实现数据的复制，或者采用只保障最终一致性的算法，来实现异步数据复制。这样的设计对于一般业务规模的系统来说没有问题，而当应用于有着海量服务的庞大的业务系统来说，就会遇到性能瓶颈。\n为解决这一问题，SOFARegistry 采用了数据分片的方法。全量服务注册数据不再保存在单机里，而是分布于每个节点中，每台服务器保存一定量的服务注册数据，同时进行多副本备份，从理论上实现了服务无限扩容，且实现了高可用，最终达到支撑海量数据的目的。\n在各种数据分片算法中，SOFARegistry 采用了业界主流的一致性 Hash 算法做数据分片，当节点动态扩缩容时，数据仍能均匀分布，维持数据的平衡。\n在数据同步时，没有采用与 Dynamo、Casandra、Tair、Codis、Redis cluster 等项目中类似的预分片机制，而是在 DataServer 内存里以 dataInfoId 为粒度进行操作日志记录，这种实现方式在某种程度上也实现了“预分片”，从而保障了数据同步的有效性。\n图 1 SOFARegistry 总体架构图\nDataServer 启动 启动入口 DataServer 模块的各个 bean 在 JavaConfig 中统一配置，JavaConfig 类为 DataServerBeanConfiguration， 启动入口类为 DataServerInitializer，该类不由 JavaConfig 管理配置，而是继承了 SmartLifecycle 接口，在启动时由 Spring 框架调用其 start 方法。\n该方法中调用了 DataServerBootstrap#start 方法（图 2），用于启动一系列的初始化服务。\n从代码中可以看出，DataServer 服务在启动时，会启动 DataServer、DataSyncServer、HttpServer 三个 bolt 服务。在启动这些 Server 之时，DataServer 注册了一系列 Handler 来处理各类消息。\n图2 DataServerBootstrap 中的 start 方法\n这几个 Server 的作用如下：\n DataServer：数据服务，获取数据的推送，服务上下线通知等； DataSyncServer：数据同步服务； HttpServer：提供一系列 REST 接口，用于 dashboard 管理、数据查询等； 各 Handler 具体作用如图 3 所示：\n图 3 各 Handler 作用\n同时启动了 RaftClient 用于保障 DataServer 节点之间的分布式一致性，启动了各项启动任务，具体内容如图 4 所示：\n图 4 DataServer 各项启动任务\n各个服务的启动监听端口如图 5 所示：\n图5 监听端口\n其他初始化 Bean 除上述的启动服务之外，还有一些 bean 在模块启动时被初始化, 系统初始化时的 bean 都在 DataServerBeanConfiguration 里面通过 JavaConfig 来注册，主要以如下几个配置类体现（配置类会有变更，具体内容可以参照源码实现）：\n DataServerBootstrapConfigConfiguration：该配置类主要作用是提供一些 DataServer 服务启动时基本的 Bean，比如 DataServerConfig 基础配置 Bean、DataNodeStatus 节点状态 Bean、DatumCache 缓存 Bean 等；\n LogTaskConfigConfiguration：该配置类主要用于提供一些日志处理相关的 Bean；\n SessionRemotingConfiguration：该配置类主要作用是提供一些与 SessionServer 相互通信的 Bean，以及连接过程中的一些请求处理 Bean。比如 BoltExchange、JerseyExchange 等用于启动服务的 Bean，还有节点上下线、数据发布等的 Bean，为关键配置类；\n DataServerNotifyBeanConfiguration：该配置类中配置的 Bean 主要用于进行事件通知，如用于处理数据变更的 DataChangeHandler 等；\n DataServerSyncBeanConfiguration：该配置类中配置的 Bean 主要用于数据同步操作；\n DataServerEventBeanConfiguration：该配置类中配置的 Bean 主要用于处理与数据节点相关的事件，如事件中心 EventCenter、数据变化事件中心 DataChangeEventCenter 等；\n DataServerRemotingBeanConfiguration：该配置类中配置的 Bean 主要用于 DataServer 的连接管理；\n ResourceConfiguration：该配置类中配置的 Bean 主要用于提供一些 Rest 接口资源；\n AfterWorkingProcessConfiguration：该配置类中配置一些后处理 Handler Bean，用于处理一些业务逻辑结束后的后处理动作；\n ExecutorConfiguration： …","date":1570690800,"description":" 本文为《剖析 | SOFARegistry 框架》第四篇，作者明不二","dir":"blog/sofa-registry-data-fragmentation-synchronization-scheme/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e4e0cf21756799897553099d37f73100","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","publishdate":"2019-10-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心数据分片和同步方案详解 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","wordcount":5784},{"author":"闫守孟等","categories":"SOFAEnclave","content":" 近日，Linux 基金会宣布全球多家巨头企业成立机密计算联盟（Confidential Computing Consortium），在对于数据安全和隐私担忧的不断增长下，基于可信执行环境技术的机密计算作为一种可行的解决方案，成为互联网巨头关注的焦点。 蚂蚁金服很早就关注此类技术，并基于机密计算打造了蚂蚁金服新一代可信编程中间件 SOFAEnclave，为金融业务保驾护航。 机密计算是蚂蚁安全计算的一环，也是金融级云原生的一块重要版图，蚂蚁金服表示：相信未来机密计算将和 HTTPS 一样，成为云计算的标配。\n 作者 | 闫守孟、肖俊贤、田洪亮 引言 互联网金融本质上是对大量敏感数据的处理以及由此沉淀的关键业务智能。近年来涌现出来的新业态更是将数据处理的范畴从单方数据扩展到了涉及合作方的多方数据。\n另一方面，从 GDPR 到 HIPAA，数据隐私监管保护的范围愈加扩大，力度日益增强。可见，对金融数据和关键业务智能的安全保护，不仅是互联网金融业务的基础，也是其创新发展的依托，更是攸关合规的关键因素。\n近年来迅速发展的机密计算技术是一种创新的数据隔离和加密处理技术，其重要特点是，TCB(trusted computing base 可信计算基) 中仅包含应用自身和基础硬件，即使 OS kernel、Hypervisor、甚至 BIOS 等特权软件都已经遭到破坏甚至本来就是恶意的，敏感数据和代码依然能安全无虞。\n蚂蚁金服在自身的实践过程中，基于机密计算底层技术发展出金融级的机密计算中间件，确保金融应用数据和代码的机密性和完整性，为关键业务提供易用、安全、集群化的计算环境。\n本文从机密计算的技术背景、关键问题、蚂蚁的技术突破、以及典型应用场景等方面展开。\n机密计算的技术背景 随着云计算的快速发展，越来越多的关键性服务和高价值数据被迁移到了云端。云安全也因此成为学术界和工业界关注的一个焦点。\n近年来，云安全领域最重要的一项技术进展名为机密计算（Confidential Computing）。机密计算填补了当前云安全的一项空白——使用中数据（Data-in-use）的加密。过去通行的做法是对数据在存储中（比如硬盘）和传输中（比如网络）加密，而在使用中（比如内存）解密，以便处理。而机密计算可以保护使用中数据的机密性和完整性。\n目前，多家云计算巨头都在不约而同地推广这项技术：微软已于 2017 年 7 月宣布开始接受 Azure 机密计算的早期试用申请；IBM 于 2017 年 12 月宣布 IBM 云数据保护（Cloud Data Guard）的预览版；谷歌也于 2018 年 5 月开源了名为 Asylo 的机密计算框架。\n那么，机密计算究竟是如何实现的呢？\n实际上，上述所有云计算巨头在实现机密计算时都离不开一种称为“可信执行环境（TEE）”的技术。\n顾名思义，TEE 提供一种与不可信环境隔离的安全计算环境，正是这种隔离和可信验证机制使得机密计算成为可能。\nTEE 一般是直接基于硬件实现的，比如 Intel SGX，AMD SEV，ARM TrustZone，以及 RISC-V Keystone 等；基于虚拟化技术也可以构造 TEE，比如微软的 VSM，Intel 的 Trusty for iKGT \u0026amp;amp; ACRN，但尚不能匹敌硬件 TEE 的安全性。\n其中，Intel 软件防护拓展（Software Guard Extensions，简称 SGX）是目前商用 CPU 中最为先进的 TEE 实现，它提供了一套新的指令集使得用户可以定义称为 Enclave 的安全内存区域。CPU 保证 Enclave 与外界隔离，从而保护其中的代码和数据的机密性、完整性和可验证性。不同于之前的 TEE 实现，比如 ARM TrustZone，SGX 每个 APP 都可以有自己独立的 TEE，甚至可以创建多个 TEE，而 TrustZone 是整个系统有一个 TEE；这里也省去了向设备厂商申请将 TA 装入 TEE 的过程。由于 SGX 的先进性，目前云端机密计算领域甚至已公认用 Enclave 这个词来指代 TEE。\n典型 TEE 安全特性和使用流程 [1]\n典型的 Enclave 达到的安全目标可以用 CIA 概括，即机密性（Confidentiality）、完整性（Integrity）和真实性（Authenticity）。在实现上具有以下基本要求：\n1) Enclave 内存保护\nEnclave 内存只有 Enclave 本身的代码可以访问。CPU 通过内存隔离和加密来防止对安全内存的软件攻击和硬件嗅探。SGX 更通过内存控制器的 integrity tree 防止了对 Enclave 内存的物理篡改。\n2) Enclave 的可信验证\nCPU 支持对 Enclave 中数据和代码的测量，以及对 Enclave 合法性的本地或远程验证。有了测量和验证，本地的 Enclave 之间、客户端与远程 Enclave 之间，就可以认证身份，进而建立安全的通信信道。\n如何开发受 Enclave 保护的应用程序呢？\n以 SGX 为例，其中一种方法是利用 Intel SGX SDK。如下图所示，基于 SGX SDK 的应用程序分为两部分：Enclave 外的不可信组件（左边黄色部分）和 Enclave 内的可信组件（右边绿色部分）。两边可以通过跨 Enclave 的函数调用通信：不可信组件可以通过 ECall 调用可信组件中定义的函数；反之，可信组件也可以通过 OCall 调用不可信组件中定义的函数。\nEnclave 编程模型 [2]\n机密计算面临的关键问题 Enclave 给我们带来了前文所谓 CIA 的安全保障，但是目前面临较大的易用性问题。主要体现在几个方面。\n第一，需要将原有应用分割成两部分，一部分是 enclave 外的 untrusted 部分，一部分在 enclave 里面作为 trusted 部分；\n第二，需要精心设计两部分之间的接口，规划好什么时候进入 Enclave，什么时候退出 Enclave——这存在一定技术门槛，而且比较繁琐容易出错；\n第三，即使我们做了完美的分割， Enclave 里面的环境相对于我们熟悉的通常的 Linux 运行环境来说是非常受限的。例如，enclave 里面不能进行系统调用，libc、pthread 不完整，没有 openmp，多进程支持欠缺等等。\n可见，把应用移植到 Enclave 里面是极具挑战的，在某些时候甚至是不可能做到的。而且，由于开发过程中必须考虑业务无关的繁杂琐细的方面，即使最终能完成应用开发移植目标，也会导致低下的开发效率，极高的开发成本，这对于快节奏的互联网业务来说是难以接受的。\n机密计算走向工程实用面临的另一较大问题是，如何将机密计算从单节点向集群扩展。由于缺乏标准的做法，或者没有一个 best practice 作为参考，很多时候各个业务不得不各自从头造轮子，搭建跟业务逻辑过度耦合的 Enclave 集群基础设施。从而导致低下的开发效率和重复的资源投入。\n另一方面，互联网业务日趋云原生化， …","date":1570258800,"description":"基于机密计算打造的新一代可信编程中间件。","dir":"blog/sofa-enclave-confidential-computing/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f994d83c7c4b263b08e4d2fd22a461b4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-enclave-confidential-computing/","publishdate":"2019-10-05T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-enclave-confidential-computing/","summary":"近日，Linux 基金会宣布全球多家巨头企业成立机密计算联盟（Confidential Computing Consortium），在对于数据安全和隐私担忧的不断","tags":["SOFAEnclave"],"title":"SOFAEnclave：蚂蚁金服新一代可信编程环境，让机密计算为金融业务保驾护航102年","type":"blog","url":"/sofastack.tech/blog/sofa-enclave-confidential-computing/","wordcount":6249},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFALab 系列文章 十一特刊带来 SOFALab 系列源码解析文章集合~\nSOFA:RPCLab/ 系列文章 【剖析 | SOFARPC 框架】系列之总体设计与扩展机制 【剖析 | SOFARPC 框架】系列之链路追踪剖析 【剖析 | SOFARPC 框架】系列之连接管理与心跳剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 同步异步实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 线程模型剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 单机故障剔除剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 泛化调用实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 数据透传剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 优雅关闭剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 路由实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 跨语言支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 序列化比较 SOFA:BoltLab/ 系列文章 蚂蚁金服通信框架SOFABolt解析 | 编解码机制 蚂蚁金服通信框架SOFABolt解析 | 序列化机制(Serializer) 蚂蚁金服通信框架SOFABolt解析 | 协议框架解析 蚂蚁金服通信框架SOFABolt解析 | 连接管理剖析 蚂蚁金服通信框架SOFABolt解析 | 超时控制机制及心跳机制 SOFA:TracerLab/ 系列文章 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览 | 剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码分析 | 剖析 蚂蚁金服分布式链路跟踪组件链路透传原理与SLF4J MDC的扩展能力分析 | 剖析 蚂蚁金服分布式链路跟踪组件采样策略和源码 | 剖析 蚂蚁金服分布式链路跟踪组件埋点机制 | 剖析 SOFA:JRaftLab/ 系列文章 SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.5.8，主要变更如下：\n 优化 log4j2 日志异步化 修复故障剔除模块的事件接收问题 修复 tracelog 日志 local 地址打印不正确的问题 优化泛化调用的方法名显示 修复特殊场景下的泛化调用超时设置 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.5.8\n","date":1570172400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191004/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"81a2a8115038fb193b50618c4d845bf4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191004/","publishdate":"2019-10-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191004/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/30 - 10/4】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191004/","wordcount":1056},{"author":"SQLFlow","categories":"SQLFlow","content":" 2018 年 1 月，Oracle 的官方博客上发表了一篇文章，标题是“It\u0026amp;rsquo;s Pervasive：AI Is Everywhere”。作为全球最著名的商业数据库系统提供商，Oracle 在这篇文章里历数了 AI 在企业信息系统中的发展空间。在面向最终用户的互联网行业，巨头们招募 AI 专家，用 Python 和 C++ 打造服务大众的特定 AI 能力——搜索、推荐、以及精准定向的互联网广告系统。在企业业务中，使用 SQL 的分析师是大多数。\n滴滴首席数据科学家谢梁（左）与蚂蚁金服研究员王益开启共建SQLFlow之旅\n2019 年 7 月，滴滴的数据科学（Data Science）团队的几名数据科学家在北京新澄海大厦见到了来自蚂蚁金服的几位工程师。在那之前两个月，蚂蚁金服从事 AI 基础架构研发的王益团队开源了一款机器学习工具 SQLFLow，将 SQL 程序翻译成 Python 程序，调用数据库和 AI 引擎，实现端到端的 AI。滴滴首席数据科学家谢梁敏锐地关注到这个项目。这次拜访双方一拍即合，开启了共建 SQLFlow 之旅。\n用 SQLFlow 构建 AI 的训练和预测任务\n数据分析师的普适 AI  数据驱动决策是很多公司的追求，在国内很多业务人员都了解 SQL，但是对于 AI、深度学习模型的训练，需要长时间系统性的学习，有一定的门槛。SQLFLow 的出现让包括数据分析师在内的业务人员通过写简单的 SQL 去调用 AI 模型成为了可能。滴滴数据科学团队长期地直面一线业务，了解业务需求，也沉淀了很多常用模型。本次合作双方希望优势互补共同助力 AI 的落地，据悉合作分为三步，第一步滴滴为蚂蚁金服贡献更多针对于业务产品的理解和洞见；第二步滴滴将公司自身业务场景最有价值用的最好的模型贡献到 SQLFLow；第三步滴滴加入到建设到整个 SQLFLow 开源社区的建设，双方要在模型、社区、文化等全方位共建。\nSQLFlow的技术架构\n一个多月的时间，滴滴已经为 SQLFLow 贡献了基于 DNN 分类预测模型、可解释模型和无监督聚类模型三个高价值模型。这三个模型覆盖的场景非常广泛，对于滴滴内部来说，包括网约车、单车、金融等在内的诸多业务场景都可应用起来，于外部而言，“因为整个模型它是一种基础能力，其实它不会局限于某一个公司或某一个行业，它具有普适性。”滴滴高级数据科学家高梓尧强调。\nSQLFlow 和滴滴数据的整合逻辑\n比如分类预测模型，适用于做产品增长的场景，对特定人群进行定向推荐。而无监督聚类模型，也就是模式识别，在滴滴的产品的应用非常广，比如会根据司机出车时长分布，去整合归纳司机出车的偏好，更好地为司机提供调度建议，进而帮助缓解出行供需。\n滴滴首席数据科学家谢梁认为在共建 SQLFlow 过程中，充分体现了算法和数据科学在对数据的理解和应用上的两个不同，以及双方优势互补形成 1+1 大于 2 的合力效果。因为对于传统的算法来讲主要强调对于预测一个给定事件的预测精准性。但是数据科学在预测精准性之上，还强调预测的可解释性。实际上在更广泛的商业层面上，比如运营、营销等更需要了解为什么会这这样发生，这对于业务战略制定、营销方案的确定，以及整个产品序列的设计都有非常大的帮助。\n滴滴数据科学团队在过去不到两个月的共建工作中显著扩大了 SQLFlow 的应用场景。根据蚂蚁金服 SQLFlow 项目的产品负责人刘勇峰介绍，滴滴的同事们建议并且参与研发了 SQLFlow 对接 XGBoost 的功能，从而在深度学习模型之外支持树模型；以及对接 unsupervised learning 的能力，支持聚类分析。此外，SQLFlow 基于 SHAP 支持了深度学习模型和树模型的图示化解释。SQLFlow 也支持了滴滴常用的 Hive 数据库系统。\n基于 XGBoost 的汽车价格预测模型（数据来自 Kaggle）的 SHAP 解释图（注：SHAP 值表征了每个特征对模型输出的影响，如图中，较小的 engine_hp“引擎马力”值会降低汽车的预测价格）\n“我们是希望通过 SQLFlow 真正能够把数据驱动业务、科学决策的思想，能够在中国传播得更好更远，也希望就是能够通过我们自己的努力，真正让 AI 模型能力大众化和普及化，然后使得我们整个国内的数据分析的科学性、合理性和洞察性，能够逐步提升，甚至达到国际领先。”高梓尧说。\n而所有参与项目的同事们对 SQLFlow 的未来都有更大的期待，这是对于开源社区作为一种高效率的工作模式的信任。\n打造一个 SQL 花园生态 在强调数据驱动的滴滴其实一直积极参与到开源建设中，截至目前，滴滴和蚂蚁金服分别开源了数十个项目。SQLFlow 是双方开源共建的首秀。\n对于双方仅一个多月的时间就能够共建三个高价值的模型，谢梁认为很重要的原因是 SQLFlow 已经给滴滴搭建好了底层能力，滴滴相当于做了一个交通领域的几个核心插件，并且通过滴滴插件能力，对整个 SQLFlow 覆盖面和深度方面的底层能力进行了验证和提升，“那么再把这个基础打好之后，我们就相当于造了一个大的花园，我们把土都铺好了，需要什么营养的土，要种什么类型的花，都给他做好了，之后就需要有更多的农民伯伯一起来种田，他们要去种向日葵，我们毕竟精力有限可能就是以种小麦和种主粮为主，更多的经济作物就需要其他开源社区的同学一起来贡献。”\n在整个 SQLFlow 开源社区建设方面双方都有更大的愿景，滴滴的分析团队总结的很多模型在 BI 领域具备普适性，而 SQLFlow 在蚂蚁的场景使用模型在金融领域颇有普适性，未来要让更多的人去用上普适的 AI 能力，在 SQLFlow 社区之上会形成一个开源货架式的交易市场，更多懂业务的人把更多商业场景抽象成模型打造成模型库，模型库是 SQLFlow 生态中的重要一环，双方正在讨论如何共建。“你就像走进一个超市，里面有 10万个 SQL，每一个 SQL 就是一个实现了你商业逻辑的模型，你就拿来用就行了，这是终极的一个目标”，谢梁兴奋地谈到。\n当然现在的 SQLFlow 还是一个非常年轻的开源项目，需要更多的呵护。虽然目前在开源合作方面中国相比美国还有不少差距，但正是因为越来越多的公司和个人去投身其中为之贡献，差距正在缩小。实际上，几乎所有的 SQLFlow 项目成员都是利用业余时间参与到开源项目中。比如滴滴资深算法工程师陈祥，他平时负责数据治理和应用方向上数据、应用与算法的结合和落地, 在 8 月初听到 SQLFlow 项目就决定参与进来，未来他也会号召很多的人参与到开源建设中。\n“开源社区所说的构建大生态，其实大生态还包含着另外一层，就是大家互相学习，然后行业内的所有从业人员进行知识交流。所以当各行各业的同学都在里面贡献自己的经验、技能时，我们其实也能从其他的同学那学习到很多处理数据，或者解决实际问题的方法。”高梓尧所言恰如其分地诠释了开源社区众人拾柴火焰高的魅力。\nGartner 预测“到 2020 年，AI 技术将普遍出现在几乎每一个新的软件产品和服务中。”这其中有蚂蚁金服与滴滴 DS 团队的一份力。\n项目地址 欢迎感兴趣的同学加入社区讨论： 项目官 …","date":1569740400,"description":"让AI 像 SQL 查询一样简单。","dir":"blog/sqlflow-ai-didi-antfin-open-source-construction/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d8e2fdbfc1d48f984a2adf17474cb983","permalink":"https://sofastack.github.io/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","publishdate":"2019-09-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","summary":"2018 年 1 月，Oracle 的官方博客上发表了一篇文章，标题是“It\u0026rsquo;s Pervasive：AI Is Everywhere”。作为全球最著","tags":["SQLFlow"],"title":"让 AI 无处不在：滴滴与蚂蚁金服开源共建 SQLFlow","type":"blog","url":"/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","wordcount":2732},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、关于 SOFAJRaft 的提问：\n@LoFi 提问：\n 关于 SOFAJRaft，请教几个问题：不管 raft log 是并行，batch 还是 pipeline 复制，都是为了提高 throughput，但对 latency 没有好处，因为最终日志必须要顺序 commit 和顺序 Apply ，这是 Raft 论文的要求。但是在某些简单的 KV 场景，上层业务可以根据需求去乱序 commit 和 Apply 么？这样可以降低 latency 。\n A：pipeline 对 latency 会有一些好处，总体上讲 batch 对吞吐有好处，SOFAJRaft 里的 batch 设计也不会对 latency 有坏处，所以它还是好的，乱序 apply 理论上影响一致性。\n 如果 raft log commit 成功，但是 apply 失败，系统目前的处理方式是什么？直接 crash?\n A：apply 异常失败会阻塞住状态机，只有重启才可能恢复，为了保证一致性。\n 如果 leader 本地磁盘 error 或者本地 log flush 失败, 但收到了多数派的响应，日志会 commit 么？怎么处理这种情况？\n A：你说的这种异常状态机就挂掉了，原因同上一条。\n关于扩容：\n 扩容时，新节点的角色不能为 follow 吧？会影响 ballot，不应该先增加一个 Follow 角色，等 snapshot 加载成功后再变为 follow 么？\n A：新加节点首先要求日志追上才行，你说的这个不存在。\n 扩容时，如果是 follow 的话，根据论文就会影响 leader 的投票吧\n A：那首先得你说的这个 follower 在这个组里呀。首先要追上数据，才能变更配置，这个节点才会进入 group，另外再退一步，没有最新日志的 follower 也无法影响投票。SOFAJRaft 比 Raft 论文里面多了一个 preVote。\n 明白，就是先追上数据，然后才能再走一遍 addpeer raftlog ?\n A：不是额，是 addPeer 的流程里第一步就是要先追数据。\n 你的意思是：当新的节点加入集群时，会先追日志 , 然后再把这个节点加入到 raft goup 中，成为投票中的一员 是么？ 也就是说在追日志的过程中，这个新的节点是不会参与 raft log 的投票么？那如果说我只是为一个 raft goup 增加副本数，比如从 3 副本变成 4 副本时，这个时候是怎么处理的呢？反正就是不管哪种情况，都是先追数据，然后再加入到 Goup 里？\n A：新加的 follower 一启动，就会 electiontimeout 发起选举，但是不会成功，然后 leader 会为这个节点新起一个 replicator 开始复制数据日志（通常包含 snapshot），等到数据追上后，leader 会再提交一条配置变更日志，此时这个节点就正式加入到 group 了。\n2、关于 Seata 的提问：\n@姜伟锋 提问：\n 最近在看 Seata 的源码，发现 rpc 相关的 Request、Response 网络传输对象太多了，在保证扩展性的基础上是不是可以优化下，因为主要参数也就是事务组 id、事务组 status、分支事务 id、分支事务 status，再加上附加信息字段，感觉这块设计还有相关序列化设计有点复杂了，这样设计的目的是什么呢，求大佬解。\n A：是指字段冗余还是指外层的包装协议复杂了？\n rpc 传输对象感觉有点冗余，一些 request response 对象是不是可以合并，主要字段应该是固定的，这样设计的目的扩展性是很好，复用性是不是还有优化空间呢？\n A： 这里是按照非事务消息（注册鉴权之类）和事务消息，事务消息又按照 RM，TM 角色以及传输的方向做了分类，你说的冗余能举个栗子嘛？\n 看到是按角色定义的 rpc req，res 传输对象，这些词传输对象中主要的字段是全库事务 id，全库事务状态，分支事务 id，分支事务状态，资源 id，还有一些附加字段，TM、TC、RM 交互时为什么不设计成一个 req res 对象公用或者是否可以在现有框架上提高下复用性，个人是觉得这块设计了好多传输对象，每个对象有对应的序列化和反序列化，有点复杂，这样设计扩展性这个点我明白，复用性不是太好，还有其他考虑吗？\n A：每个消息都有一个名称（code），消息名对于整个事务的链路流程上理解比较清晰，结合着我们的事务流程图来看，每个阶段的 rpc 都有一个确切的含义，即使从字段上来说是相同的比如GlobalRollbackRequest，GlobalCommitRequest 从名称上来看不一样，但从传输层面来看除了code 不一样其他的是一样的。但是大部分消息的字段还是不一样的，对于这种通用字段比如 xid begin 消息就是空的，设计成通用这里只能是 null，非通用比如 lockkey 那这里如果使用通用消息就可能直接塞到一个 applicationData 的扩展字段里，这种写法我觉得不确切，同时有增加了我私有协议序列化时不必要的长度标识字段，每条消息都是由确切的所需的字段，宁愿复杂一些，也要从设计上更清晰些。\nSeata：https://github.com/seata/seata\nSOFAJRaft 解析文章全系列 《剖析 | SOFAJRaft 实现原理》系列文章完结啦，感谢 SOFAStack 社区的核心贡献者们的编写，也欢迎更多感兴趣的技术同学加入。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft …","date":1569567600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190927/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d1709ae51d5099a6263d7269a435e264","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190927/","publishdate":"2019-09-27T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190927/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/23 - 9/27】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190927/","wordcount":2458},{"author":"胡宗棠","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》最后一篇，本篇作者胡宗棠，来自中国移动。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文末包含往期系列文章。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n导读 本文主要介绍 SOFAJRaft 在日志复制和管理中所采用的快照机制。考虑到单独介绍 SOFAJRaft 中的快照机制原理和实现或许有一些唐突，我会先通过一个读者都能够看得明白的例子作为切入点，让大家对快照这个概念、它可以解决的主要问题，先有一个比较深刻的理解。\n一、快照的概念与特点 SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法，就不可避免的要对需要达成共识的内容，在多个服务器节点之间进行传输，一般将这些共识的内容称之为日志块（LogEntry）。如果读过《剖析 | SOFAJRaft 实现原理》系列前面几篇文章的同学，应该了解到在 SOFAJRaft 中，可以通过“节点之间并发复制日志”、“批量化复制日志”和“复制日志pipeline机制”等优化手段来保证服务器节点之间日志复制效率达到最大化。\n但如果遇到下面的两个场景，仅依靠上面的优化方法并不能有效地根本解决问题：\n 当对某个 SOFAJRaft Group 集群以新增节点方式来扩容，新节点需要从当前的 Leader 中获取所有的日志并重放到本身的状态机中，这对 Leader 和网络带宽都会带来不小的开销，还有其他方法可以优化或解决这个问题么？ 因为服务器节点需要存储的日志不断增加，但是磁盘空间有限，除了对磁盘卷大小扩容外，还有其他方式来解决么？ 带着上面两个疑问，我们可以先来看一个大家日常生活中都会遇到的场景—重新安装操作系统，然后再通俗易懂地为大家介绍快照的概念与特点。\n有一天，你的笔记本电脑的 Windows 操作系统因为某一些原因出现启动后多次崩溃问题，不管通过任何方式都没办法解决。这时候，我们想到解决问题的第一个方案就是为这台电脑重新安装操作系统。如果，我们平时偶尔为自己电脑的操作系统做过镜像，直接用之前的镜像文件即可快速还原系统至之前的某一时间点的状态，而无需从零开始安装 Windows 操作系统后，再花大量时间来重新安装一些自己所需要的系统软件（比如 Chrome 浏览器、印象笔记和 FoxMail 邮件客户端等）。\n在上面的例子中，电脑操作系统的镜像就是系统某一时刻的“快照”，因为它包含了这一时刻，系统当前状态机的值（对于用户来说，就是安装了哪些的应用软件）。在需要重新安装操作系统时候，通过镜像这一“快照”，可以很高效地完成还原电脑操作系统这个任务，而无需从零开始安装系统和相应的应用软件。所以，我们这里可以为“快照”下一个简单的定义：一种通过某种数据格式文件来保存系统当前的状态值的一个副本。\n“快照”的特点，就如同它字面意思一样，可以分为“快”和“照”：\n “快”：高效快捷，通过快照可以很方便的将系统还原至某一时刻的状态； “照”：通过快照机制是保存系统某一时刻的状态值； 二、SOFAJRaft 的 Snapshot 机制 2.1 SOFAJRaft Snapshot 机制的原理 读到这里，再去回顾第一节内容开头提出的两个问题，大家应该可以想到解决问题的方法就是通过引入快照机制。\n1. 解决日志复制与节点扩容的瓶颈问题 在 SOFAJRaft 中，Snapshot 为当前 Raft 节点状态机的最新状态打了一个“镜像”单独保存，保存成功后在这个时刻之前的日志即可删除，减少了日志文件在磁盘中的占用空间。而在 Raft 节点启动时，可以直接加载最新的 Snapshot 镜像，直接重放在此之后的日志文件即可。如果设置保存 Snapshot 的时间间隔比较合理，那么节点加载镜像后重放的日志文件较少，启动速度也会比较快。对于新 Raft 节点加入某个 SOFAJRaft Group 集群的场景，新节点可先从 Leader 节点上拷贝最新的 Snapshot 安装到本地状态机，然后拷贝后续的日志数据即可，这样可以在快速跟上整个 SOFAJRaft Group 集群进度的同时，又不会占用 Leader 节点较大的网络带宽资源。\n2. 解决 Raft 节点故障恢复中的时效问题 在一个正常运行的 SOFAJRaft Group 集群中，当其中某一个 Raft 节点出现故障了（假设该故障的原因不是由磁盘损坏等不可逆因素导致的），该 Raft 节点修复故障重新启动时，如果节点禁用 Snapshot 快照机制，那么会重放所有本地的日志到状态机以跟上最新的日志，这样节点启动和达到日志备份完整的耗时均会比较长。但是，如果此时节点开启了 Snapshot 快照机制，那么一切就会变得非常高效，节点只需要加载最新的 Snapshot 至状态机，然后以 Snapshot 数据的日志为起点开始继续回放日志至状态机，直到使得状态机达到最新状态。\n图1 在 Snapshot 禁用情况下集群节点扩容\n图2 在 Snapshot 启用情况下集群节点扩容\n从上面两张 SOFAJRaft 集群的结构图上，可以很明显地看出在开启和禁用 Snapshot 时，扩容的新 Raft 节点需要从 Leader 节点传输过来不同的日志数量。在禁用 Snapshot 情况下，新 Raft 节点需要把 Leade 节点内从起始的 T1 时刻至当前 T3 时刻这一时间范围内的所有日志都重新传至本地后提交给状态机。而在开启 Snapshot 情况下，新 Raft 节点则无需像 图1 中那么逐条复制 T1~T3 时刻内的所有日志，而只需先从 Leader 节点加载最新的镜像文件 Snapshot_Index_File 至本地，然后仅复制 T3 时刻以后的日志至本地并提交状态机即可。\n在这里可能有同学会有疑问：“在 图 1 中，从 Leader 节点传给新扩容的 Raft 节点的数据是 T1~T3 的日志，而 图2 中取而代之的是 Snapshot_Index_File 快照镜像文件，似乎还是不可避免额外的数据传输么？”仔细看下图 2，会发现其中 Snapshot_Index_File 快照镜像文件是对 T1~T3 时刻内日志数据指令的合并（包括数集合[Add 1,Add 6,Add 4,Sub 3,Sub 4,Add 3]），也即为最终的数据状态值。\n2.2 SOFAJRaft Snapshot 机制的实践应用 如果用户需开启 SOFAJRaft 的 Snapshot 机制，则需要在其客户端中设置配置参数类 NodeOptions …","date":1569232800,"description":"本文为《剖析 | SOFAJRaft 实现原理》最后一篇，本篇作者胡宗棠。","dir":"blog/sofa-jraft-snapshot-principle-analysis/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"39ff132d4c11bccb0059665f6e9c4b31","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","publishdate":"2019-09-23T18:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","wordcount":4407},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@wy223170 提问：\n 你好，请问下 SOFAJRaft 如何在虚拟化环境下使用，比如部署三个实例，三个实例都是 docker 的。因为虚拟化实例可能漂移，怎么保证 snapshot 的迁移呢？另外怎么控制多个实例的同时漂移，导致集群不可用的问题？\n A：SOFAJRaft 本身是有状态的，你说的实例漂移就可以理解为这个节点挂掉并新拉起了一个节点，我们内部的做法是通过一个 manager 节点监听容器上下线并执行 CliService removePeer 和 addPeer，利用 raft 协议本身的能力达到数据迁移的目的，但是对于半数以上节点同时漂移是无解的，可能出现丢数据的情况。这是 etcd 的一个解决类似问题的方式，供参考：https://github.com/coreos/etcd-operator\n 感谢回答，是不是只要 manager 节点监听到容器变化就会立刻进行 removePeer 或 addPeer，需不需等待容器已经达到某种状态，比如迁移完 snapshot 等才进行 addPeer 之类的，这可能就需要实例迁移后完成一个打标记的功能标志迁移完成了。\n A：流程是先 addPeer 成功以后再 removePeer。其中 addPeer 在追数据成功后才会返回成功。看到你多次强调 snapshot，其实这里你不用关注 snapshot，这是 SOFAJRaft 内部会考虑的 raft 层的东西，不需要额外做特殊处理。\n开源项目 ElasticDL：蚂蚁金服开源基于 TensorFlow 的弹性分布式深度学习系统 蚂蚁金服开源机器学习工具 SQLFlow，技术架构独家解读 SOFA 项目进展 本周发布详情如下：\n发布 Seata v0.8.1，主要变更如下：\n 支持配置文件使用绝对路径 支持 DataSource 的自动代理 支持通信协议的 kryo 编解码 修复 file 存储模式的 selectForUpdate lockQuery exception 修复数据库连接使用后的 autocommit 问题 优化 etcd3 中 watcher 订阅的效率 优化当数据表无索引时抛出显式异常 详细发布报告： https://github.com/seata/seata/releases/tag/v0.8.1\nSOFAJRaftLab 系列阅读 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 ","date":1568962800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190920/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4519012918ba68bf9e39b0daed78cfc4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190920/","publishdate":"2019-09-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190920/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/16 - 9/20】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190920/","wordcount":1043},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第七篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文末包含往期系列文章。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 在分布式部署、高并发、多线程场景下，我们经常会遇到资源的互斥访问的问题，最有效、最普遍的方法是给共享资源或者对共享资源的操作加一把锁。在 JDK 中我们可以使用 ReentrantLock 重入锁或者 synchronized 关键字达成资源互斥访问目的，但是由于分布式系统的分布性（即多线程和多进程并且分布在不同机器中），使得两种锁失去原有锁的效果，需要用户自定义来实现分布式锁。\n本文重点围绕分布式锁概览、实现方式以及基于 SOFAJRaft 实现等方面剖析 SOFAJRaft-RheaKV 基于 SOFAJRaft 实现分布式锁原理，阐述如何使用 SOFAJRaft 组件提供分布式锁服务功能：\n 什么是分布式锁？分布式锁具备哪些条件？分布式锁有哪些实现方式？ RheaKV 基于 SOFAJRaft 如何实现分布式锁？解决分布式锁哪些问题？ 分布式锁 分布式锁是控制分布式系统之间同步访问共享资源的一种方式，用于在分布式系统中协调他们之间的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下便需要使用到分布式锁。分布式锁通过共享标识确定其唯一性，对共享标识进行修改时能够保证原子性和对锁服务调用方的可见性。\n分布式锁概览 Martin Kleppmann 是英国剑桥大学的分布式系统研究员，之前和 Redis 之父 Antirez 关于 RedLock 红锁是否安全的问题激烈讨论过。Martin 认为一般我们使用分布式锁有两个场景：\n 效率：使用分布式锁能够避免不同节点重复相同的工作导致浪费资源，譬如用户付款之后有可能不同节点发出多条短信； 正确性：添加分布式锁同样避免破坏正确性事件的发生，如果两个节点在同一条数据上面操作，譬如多个节点机器对同一个订单操作不同的流程有可能导致该笔订单最后状态出现错误造成资金损失； 分布式锁需要具备的条件包括：\n 获取锁和释放锁的性能要好； 判断获得锁是否是原子性的，否则可能导致多个请求都能获取到锁； 网络中断或者宕机无法释放锁时，锁必须被清除； 可重入一个线程中多次获取同一把锁，譬如一个线程在执行带锁的方法，该方法调用另一个需要相同锁的方法，则该线程直接执行调用的方法，而无需重新获得锁； 阻塞锁和非阻塞锁，阻塞锁即没有获取到锁，则继续等待获取锁；非阻塞锁即没有获取到锁，不继续等待直接返回获取锁失败； 分布式锁实现 分布式 CAP 理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance），最多只能同时满足两项。”，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。在很多场景中为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候需要保证一个方法在同一时间内只能被同一个线程执行。 分布式锁一般有三种实现方式：\n 基于数据库实现分布式锁； 基于缓存（Redis，Memcached，Tair）实现分布式锁； 基于 ZooKeeper 实现分布式锁； 基于数据库实现分布式锁 基于数据库实现分布式锁的核心思想：在数据库中创建一张表，表里包含方法名等字段，并且在方法名字段上面创建唯一索引，执行某个方法需要使用此方法名向表中插入数据，成功插入则获取锁，执行结束则删除对应的行数据释放锁。\n基于缓存实现分布式锁 基于缓存通常选用 Redis 实现分布式锁，考虑到 Redis 有非常高的性能，Redis 命令对分布式锁支持友好，并且实现方便。基于单 Redis 节点的分布式锁在 Failover 的时候产生解决不了的安全性问题，Redlock 是 Redis 的作者 Antirez 提出的集群模式 Redis 分布式锁，基于 N 个完全独立的 Redis 节点（通常情况下 N 可以设置成5），运行 Redlock 算法依次执行下面各个步骤完成获取锁的操作\n 获取当前时间（毫秒数）； 按顺序依次向 N 个 Redis 节点执行获取锁的操作。此获取操作包含随机字符串 my_random_value，也包含过期时间(比如 PX 30000，即锁的有效时间)。为了保证在某个 Redis 节点不可用的时候算法能够继续运行，获取锁的操作还有超时时间(time out)，它要远小于锁的有效时间（几十毫秒量级）。客户端在向某个 Redis 节点获取锁失败以后应该立即尝试下一个Redis 节点。这里的失败包含任何类型的失败，比如该 Redis 节点不可用，或者该 Redis 节点上的锁已经被其它客户端持有（注：Redlock 原文中这里只提及 Redis 节点不可用的情况，但也应该包含其它的失败情况）； 计算整个获取锁的过程总共消耗了多长时间，计算方法是用当前时间减去第1步记录的时间。如果客户端从大多数 Redis 节点（\u0026amp;gt;= N/2+1）成功获取到了锁，并且获取锁总共消耗的时间没有超过锁的有效时间（lock validity time），那么这时客户端才认为最终获取锁成功；否则认为最终获取锁失败； 如果最终获取锁成功了，那么此锁的有效时间应该重新计算，它等于最初锁的有效时间减去第3步计算出来的获取锁消耗的时间； 如果最终获取锁失败（可能由于获取到锁的 Redis 节点个数少于 N/2+1，或者整个获取锁的过程消耗的时间超过了锁的最初有效时间），那么客户端立即向所有 Redis 节点发起释放锁的操作； 基于 ZooKeeper 实现分布式锁 ZooKeeper 是以 Paxos 算法为基础的分布式应用程序协调服务，为分布式应用提供一致性服务的开源组件，其内部是分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于 ZooKeeper 实现分布式锁步骤包括：\n 创建一个锁目录 lock； 希望获得锁的线程 A 在 lock 目录下创建临时顺序节点； 当前线程获取锁目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在表示当前线程顺序号最小，获得锁； 线程 B 获取所有节点，判断自己不是最 …","date":1568721600,"description":"本文为《剖析 | SOFAJRaft 实现原理》第七篇，本篇作者米麒麟。","dir":"blog/sofa-jraft--rheakv-distributedLock/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"be578aa3941f24a603a7053e7c7e1107","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","publishdate":"2019-09-17T20:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","剖析 | SOFAJRaft 实现原理","SOFALab"],"title":"SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","wordcount":6176},{"author":"Oschina","categories":"ElasticDL","content":" 9 月 11 日，蚂蚁金服在2019谷歌开发者大会上海站上开源了 ElasticDL 项目，这是业界首个基于 TensorFlow 实现弹性深度学习的开源系统。\n开源地址为：https://github.com/sql-machine-learning/elasticdl/\n开源中国采访了 ElasticDL 项目负责人王益，对该深度学习系统的技术细节进行了全面介绍。\n基于 TensorFlow 2.0 和 Kubernetes实现弹性深度学习 这个基于 Eager Execution 模式的开源项目名为“ElasticDL”，它是一个Kubernetes 原生深度学习框架，根据介绍，ElasticDL 主要有四大特点：\n 容错性 弹性调度 易用性 高效 其中又以容错与弹性调度特性最具特色。\nElasticDL 实现了容错和弹性调度的分布式深度学习，可以极大提升集群的总体利用率，同时显著减少用户提交作业之后等待作业启动的时间（pending time）。\n王益介绍：“ElasticDL 是我们知道的第一个基于 TensorFlow 实现弹性深度学习的开源系统。具体地说，ElasticDL 是基于 TensorFlow 2.0 和 Kubernetes 实现弹性深度学习的。”\n集群效用从 1/N 到 N/N 在深度学习技术研发的早期，公用一个计算集群的人相对少， 计算作业之间的协调可以通过口头交流实现。开发者更关心缩短运行时间，也就是从作业启动到结束的这段时间。高性能计算技术（HPC）是解决这个问题的有效途径，比如 NVIDIA 的 cuBLAS 和 cuDNN 优化高性能数学计算、NCCL 优化 GPU 之间的通信效率。\n随着深度学习技术的大规模应用，在许多工程师和研究员公用一个集群的情况下，通过商量来协调调度显然不可行，于是大家开始使用集群管理系统调度分布式作业。\nKubernetes 近年来已经逐渐成为集群管理的重要工具，目前已经在各大公有云中广泛采用。因此，让 TensorFlow 能更好地运行在 Kubernetes 集群上，同时提升利用集群进行深度学习的效率和资源利用率（效用），显得非常具有实际意义。\n关于提升集群资源利用率，王益举了一个比较极端的例子：假设一个集群有 N 个 GPU，而一个任务只使用其中一个，现在有一个任务占用了一个 GPU。当没有弹性调度机制时，一个要求所有 N 个 GPU 的任务需要等待前一个任务结束才能开始，这个等待时间可能高达数天甚至数周，在等待期间，集群的效用是 1/N；而拥有弹性调度能力之后，新的任务可以在 N-1 个 GPU 上立即运行，并且 Kubernetes 可以在第一个任务完成后将占用的 GPU 赋予这个任务，这种情况下，集群整体效用是 100%。\nElasticDL 在容错与弹性调度上都有不错的表现，它的现实意义便是高效解决集群效用问题。\nElasticDL 如何实现？ 前边讲到集群资源利用率提高的前提其实就是ElasticDL 的“弹性调度”特性带来的，而弹性调度依赖于容错能力。\n容错是指作业不受其中进程数量变化的影响，在弹性调度过程中，作业里的进程数量会随集群 workload 情况相应增减，所以作业必须是容错的，才能配合调度系统，实现弹性调度。\n在这个过程中，容错通常由分布式框架实现，比如 Spark 和 ElasticDL 都可以做到当有进程挂掉，或者新的进程加入时，作业不会暂停或者重启，而是平滑地继续。而弹性调度是由分布式框架和分布式操作系统（集群管理系统）一起实现的。比如，当有进程挂掉的时候，分布式框架应该通知集群管理系统新启进程来补位 —— 至于集群管理系统能不能启动起来，取决于用户剩余 quota 和集群的忙碌情况。\n1. 基于 Kubernetes-native 通常使用 Keras 的 model-fit API 和 Estimator，开发者只需要调用 API 即可进行分布式训练或预测，然而 ElasticDL 不依赖于 TensorFlow runtime 实现分布式计算，它的实现在 runtime 之外。\nElasticDL 通过 Kubernetes-native 机制来完成分布式计算，而这也为其带来了容错性与弹性调度的能力。\n所谓 Kubernetes-native指的是一个程序调用 Kubernetes API 来起止进程，它与 Google MapReduce 的机制类似。MapReduce 是一个 Borg-native 的分布式计算框架，用户通过运行一个 Borg 客户端程序启动一个 MapReduce 作业；Borg 客户端调用 Borg API 提交作业，并且启动一个 master 进程；这个 master 调用 Borg API 启动其它 workers 进程。\n在 ElasticDL 中，用户调用 ElasticDL 的命令行客户端程序启动作业；这个客户端程序调用Kubernetes API 启动 master 进程，master进程继续调用 Kubernetes API 启动其它进程。\n“ElasticDL 的整个容错和弹性调度机制都依赖于 Kubernetes-native 架构”，王益介绍：“如果 worker 挂了，按照分布式深度学习训练算法的数学特性，可以不用处理，即可确保训练过程继续。如果一个 parameter server 进程挂了，master会选择一个 worker 进程，让它转换角色替补上挂掉的parameter server 进程。”\n在这两种情况下，master 都会调用 Kubernetes API，请它再启动一个额外的 worker 进程。如果启动成功，master 会带其加入到与其它进程的协作中。master 进程的状态（主要是三个 task queues：todo、doing与 done）可以保留在 Kubernetes 集群的 etcd 存储系统中。\n“这样，万一 master 挂了，重启的 master 进程可以从 etcd 继承前世的状态。任何进程挂了，master 都会请 Kubernetes 去启动一个新的进程代替挂掉的进程。而 Kubernetes 是否能完成使命取决于用户剩余 quota 和集群剩余资源情况。”\n2. 基于 TensorFlow 2.0 EagerExecution 为什么 ElasticDL 又基于 TensorFlow 2.0 呢？王益介绍，这是因为 TensorFlow 2.0 带来了 Eager Execution 特性，正是针对这一特性的尝试，让开发团队实现了Kubernetes-native 的调度方式，从而让 ElasticDL 支持容错和弹性调度。\n分布式学习需要了解每个进程根据局部训练数据计算得到的 gradients，才能汇总这些 gradients 来更新模型。\nTensorFlow 1.x 的执行方式被称为 Graph Mode —— 深度学习计算步骤被表示成一个 graph 数据结构，TensorFlow runtime 会解释执行这个 graph。其中，gradients 的计算过程是 graph …","date":1568635200,"description":"业界首个基于 TensorFlow 实现弹性深度学习的开源系统 ElasticDL 项目的技术细节全面介绍。","dir":"blog/alipay-deep-learning-tensorflow-elasticdl/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"74eedc82d0b4a438d332dd5443605318","permalink":"https://sofastack.github.io/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","publishdate":"2019-09-16T20:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","summary":"9 月 11 日，蚂蚁金服在2019谷歌开发者大会上海站上开源了 ElasticDL 项目，这是业界首个基于 TensorFlow 实现弹性深度学习的开源系统。 开源地址为：https://g","tags":["ElasticDL"],"title":"ElasticDL：蚂蚁金服开源基于 TensorFlow 的弹性分布式深度学习系统","type":"blog","url":"/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","wordcount":4705},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n中秋特辑推荐阅读 【中秋特辑】（含视频回顾）SOFAStack 活动回顾整理集合 SOFARegistry 系列解析文章 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 本周发布详情如下：\n发布 SOFARPC v5.6.1，主要变更如下：\n 升级 sofa-bolt 的版本到 1.5.6 修复 com.alipay.sofa.rpc.log.LoggerFactory 提供的 Logger 实现方案在多 classloader 场景下存在会出现类型不匹配的问题 修复 providerInfo 中可能出现的 staticAttrs 空指针问题 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.1\nHey，中秋快乐呀 ","date":1568271600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190913/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"85b998cb10df30ee42c04a8571b73598","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190913/","publishdate":"2019-09-12T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190913/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/9 - 9/13】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190913/","wordcount":423},{"author":"Yavin","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第三篇，本篇作者 Yavin，来自考拉海购。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n导读 集群成员管理是分布式系统中绕不开的话题。MetaServer 在 SOFARegistry 中，承担着集群元数据管理的角色，用来维护集群成员列表。本文希望从 MetaServer 的功能和部分源码切入剖析，为学习研究、或者项目中使用SOFARegistry 的开发者带来一些启发，分为三个部分：\n 功能介绍 内部架构 源码分析 功能介绍 MetaServer 作为 SOFARegistry 的元数据中心，其核心功能可以概括为集群成员管理。分布式系统中，如何知道集群中有哪些节点列表，如何处理集群扩所容，如何处理集群节点异常，都是不得不考虑的问题。MetaServer 的存在就是解决这些问题，其在 SOFARegistry 中位置如图所示： MetaServer 通过 SOFAJRaft 保证高可用和一致性，类似于注册中心，管理着集群内部的成员列表：\n 节点列表的注册与存储 节点列表的变更通知 节点健康监测 内部架构 内部架构如下图所示：\nMetaServer 基于 Bolt, 通过 TCP 私有协议的形式对外提供服务，包括 DataServer, SessionServer 等，处理节点的注册，续约和列表查询等请求。\n同时也基于 Http 协议提供控制接口，比如可以控制 session 节点是否开启变更通知, 健康检查接口等。\n成员列表数据存储在 Repository 中，Repository 被一致性协议层进行包装，作为 SOFAJRaft 的状态机实现，所有对 Repository 的操作都会同步到其他节点, 通过Rgistry来操作存储层。\nMetaServer 使用 Raft 协议保证数据一致性， 同时也会保持与注册的节点的心跳，对于心跳超时没有续约的节点进行驱逐，来保证数据的有效性。\n在可用性方面，只要未超过半数节点挂掉，集群都可以正常对外提供服务， 半数以上挂掉，Raft 协议无法选主和日志复制，因此无法保证注册的成员数据的一致性和有效性。整个集群不可用 不会影响 Data 和 Session 节点的正常功能，只是无法感知节点列表变化。\n源码分析 服务启动 MetaServer 在启动时，会启动三个 Bolt Server，并且注册 Processor Handler，处理对应的请求, 如下图所示：\n DataServer：处理 DataNode 相关的请求； SessionServer：处理 SessionNode 相关的请求； MetaServer：处理MetaNode相关的请求； 然后启动 HttpServer, 用于处理 Admin 请求，提供推送开关，集群数据查询等 Http 接口。\n最后启动 Raft 服务， 每个节点同时作为 RaftClient 和 RaftServer, 用于集群间的变更和数据同步。\n各个 Server 的默认端口分别为：\nmeta.server.sessionServerPort=9610 meta.server.dataServerPort=9611 meta.server.metaServerPort=9612 meta.server.raftServerPort=9614 meta.server.httpServerPort=9615 节点注册 由上节可知，DataServer 和 SessionServer 都有处理节点注册请求的 Handler。注册行为由 Registry 完成。注册接口实现为：\n@Override public NodeChangeResult register(Node node) { StoreService storeService = ServiceFactory.getStoreService(node.getNodeType()); return storeService.addNode(node); } Regitsry 根据不同的节点类型，获取对应的StoreService，比如DataNode，其实现为 DataStoreService 然后由 StoreService 存储到 Repository 中，具体实现为：\n// 存储节点信息 dataRepositoryService.put(ipAddress, new RenewDecorate(dataNode, RenewDecorate.DEFAULT_DURATION_SECS)); //... // 存储变更事件 dataConfirmStatusService.putConfirmNode(dataNode, DataOperator.ADD); 调用 RepositoryService#put 接口存储后，同时会存储一个变更事件到队列中，主要用于数据推送，消费处理。\n节点数据的存储，其本质上是存储在内存的哈希表中，其存储结构为：\n// RepositoryService 底层存储 Map\u0026amp;lt;String/*dataCenter*/, NodeRepository\u0026amp;gt; registry; // NodeRepository 底层存储 Map\u0026amp;lt;String/*ipAddress*/, RenewDecorate\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; nodeMap; 将RenewDecorate存储到该 Map 中，整个节点注册的流程就完成了，至于如何和 Raft 协议进行结合和数据同步，下文介绍。\n节点移除的逻辑类似，将节点信息从该 Map 中删除，也会存储一个变更事件到队列。\n注册信息续约和驱逐 不知道有没有注意到，节点注册的时候，节点信息被 RenewDecorate 包装起来了，这个就是实现注册信息续约和驱逐的关键：\nprivate T renewal; // 节点对象封装 private long beginTimestamp; // 注册事件 private volatile long lastUpdateTimestamp; // 续约时间 private long duration; // 超时时间 该对象为注册节点信息，附加了注册时间、上次续约时间、过期时间。那么续约操作就是修改lastUpdateTimestamp，是否过期就是判 …","date":1568271600,"description":" 本文为《剖析 | SOFARegistry 框架》第三篇，作者 Yavin ，来自考拉海购。","dir":"blog/sofa-registry-metaserver-function-introduction/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6e08281a1d2851d95121fc739cf80669","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","publishdate":"2019-09-12T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","wordcount":3311},{"author":"潘潘","categories":"SOFAStack","content":" SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时任务、限流/熔断框架、动态配置推送、分布式链路追踪、Metrics 监控度量、分布式高可用消息队列、分布式事务框架和分布式数据库代理层等。\nSOFAStack：https://github.com/sofastack\n本文为 SOFAStack 相关线上线下活动的回顾集合，并且会不定时更新。\n/ SOFAChannel 线上直播系列 / SOFAChannel#8 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 视频回顾资料 SOFAChannel#7 自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 视频回顾资料 SOFAChannel#6 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 视频回顾资料 SOFAChannel#5 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 视频回顾资料 SOFAChannel#4 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 视频回顾资料 SOFAChannel#3 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 视频回顾资料 SOFAChannel#2 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 视频回顾资料 SOFAChannel#1 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 视频回顾资料 / SOFAMeetup 系列 / SOFAMeetup#3\u0026amp;lt;广州站\u0026amp;gt; 分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾 视频回顾资料\n 蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾 视频回顾资料\n SOFAMeetup#2\u0026amp;lt;上海站\u0026amp;gt; 当 Spring Cloud 遇上 SOFAStack | Meetup#2 回顾 视频回顾资料\n 基于 SOFAArk 和 SOFADashboard 实现动态模块管控 | Meetup#2 回顾 视频回顾资料\n SOFAMeetup#1\u0026amp;lt;北京站\u0026amp;gt; 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼 视频回顾资料\n 蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼 视频回顾资料\n 详解蚂蚁金服 SOFAJRaft | 生产级高性能 Java 实现 视频回顾资料\n / 技术大会系列 / 2019 年技术大会实录集合 五小时构建云原生电商平台 | KubeCon SOFAStack Workshop 详解\n 蚂蚁金服大规模分布式事务实践和开源历程 | GIAC 实录\n 蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录\n 2018 年技术大会实录集合 企业实施分布式架构的挑战以及应对建议 | 上海 ATEC 大会实录\n 企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录\n Knative：重新定义 Serverless | GIAC 实录\n 蚂蚁金服微服务实践 | 开源中国年终盛典分享实录\n 蚂蚁金服Service Mesh新型网络代理的思考与实践 | GIAC 分享实录\n 蚂蚁金服 Service Mesh 渐进式迁移方案|Service Mesh Meetup 实录\n 蚂蚁金服SOFAMesh在多语言上的实践 | CNUTCon 实录\n 从平台到中台 | Elaticsearch 在蚂蚁金服的实践经验\n 从“挖光缆”到“剪网线”|蚂蚁金服异地多活单元化架构下的微服务体系\n 蚂蚁金服 Service Mesh 实践探索 | Qcon 实录\n ","date":1568260800,"description":"本文为 SOFAStack 相关线上线下活动的回顾集合，并且会不定时更新。","dir":"blog/sofa-activity-retrospect-collection/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b1f0034b1e2c249a33c57be88f5a184c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-activity-retrospect-collection/","publishdate":"2019-09-12T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-activity-retrospect-collection/","summary":"SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时","tags":["SOFAStack"],"title":"（含视频回顾）SOFAStack 活动回顾整理集合","type":"blog","url":"/sofastack.tech/blog/sofa-activity-retrospect-collection/","wordcount":986},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@王冰 提问：\n 请问个问题，SOFATracer 在采样计算时 rootSpan 为什么会计算两次，第一次是生成 span 时，第二次是在上报前又计算了一次？\n A：这种是考虑到产生 span 的逻辑是业务自己来构建，非正常逻辑情况下的一种兼容处理。对于 Tracer 来说，所有的上报是必须 SOFATracer 的行为，因此在 report 之前也会基于当前采样策略计算一次计算。默认情况下产生跟 span 时的计算更多是 span 或者说 span context 的，这个会作为向下透传的。另外产生不一致的情况不会出现，上报那段逻辑会先检查当前 span 的父 span，如果父 span 是 null 也就意味着当前 span 是 root span，所以也必须要计算。\n2、@迟广文 提问：\n 在使用 Seata 的时候，使用了 restful 框架，我的 TCC 调通了，是在接口上加了 @LocalTCC，实现类加 @Component，本以为会冲突，结果没有。\n A：TCC 的代理会代理二种类型的分支：在本地标注为 localTcc，第二种是 RPC 框架（dubbo、sofa-rpc）当 consumer 端使用作为 reference bean 且在 provider 端标注了二阶段注解时，这二种类型时互斥的，一个 TCC 分支只属于其一类型。\nSOFAChannel 回顾集合 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、SOFATracer v2.4.1/v3.0.6 版本发布，主要变更如下：\n 支持自定义埋点 (FlexibleTracer) 支持 Dubbo 2.6.x 日志输出支持非 json 格式(xstringbuilder)\n 支持自定义扩展 Repoter 上报\n Dubbo 2.7.x 系列支持 2.7.3 版本\n 修复 BasePreparedStatement 初始化问题\n 修复 SQLException 被覆盖问题\n 优化常量命名及代码注释等\n 更新案例及官方文档\n 详细发布报告：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v2.4.1\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.0.6\n官方文档：\nhttps://www.sofastack.tech/projects/sofa-tracer/overview/\n2、SOFABoot v3.2.0 版本发布，主要变更如下：\n 升级 sofa-bolt 版本至 1.5.6 根据 Spring Boot 官方文档建议重构工程代码和组织结构 详细发布报告：\nhttps://github.com/sofastack/sofa-boot/releases/tag/v3.2.0\n官方文档：\nhttps://www.sofastack.tech/projects/sofa-boot/overview/\nSOFA 用户召集 如果您已经在生产环境使用了 SOFAStack 相关组件，请在下方链接登记告诉我们，方便我们更好地为您服务，我们将会把您加入到 “SOFAStack金牌用户服务群【邀约制】”里面，以便更加快捷的沟通和更加高效的线上使用问题支持。 https://github.com/sofastack/sofastack.tech/issues/5 已有用户查看： https://www.sofastack.tech/awesome\n","date":1567753200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190906/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"94743dfe34353e1f6910291d127a73d6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190906/","publishdate":"2019-09-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190906/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/2 - 9/6】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190906/","wordcount":1296},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:RegistryLab/\u0026amp;gt;是《剖析 | SOFARegistry 实现原理》系列，会逐步详细介绍 SOFARegistry 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFARegistry SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nSOFARegistry:https://github.com/sofastack/sofa-registry\n| SOFA:RegistryLab 认领列表：\n 【已完成】海量数据下的注册中心 - SOFARegistry 架构介绍 【已完成】SOFARegistry 服务发现优化之路 【已完成】SOFARegistry 数据分片和同步方案详解 【已完成】SOFARegistry MetaServer 功能介绍和实现剖析 【已完成】SOFARegistry Session 存储策略 【已领取】SOFARegistry 如何实现秒级服务上下线通知 【已领取】SOFARegistry 如何实现 DataServer 平滑扩缩容 参与方式：关注「金融级分布式架构」回复可领取的文章标题，会有相关同学联系进行确认。\n 欢迎领取，参与共建~\n","date":1567483200,"description":"","dir":"activities/sofa-registry-lab/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ebbc0e9574d88e21f39926e750c848e9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-registry-lab/","publishdate":"2019-09-03T12:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-registry-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:RegistryLab/\u0026gt;是《剖析 | SOFARegistry 实现原理》系列","tags":["SOFALab","SOFARegistry"],"title":"\u003cSOFA:RegistryLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-registry-lab/","wordcount":435},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFA:Channel/，有趣实用的分布式架构频道。\n本文根据 SOFAChannel#8 直播分享整理，主题：从一个例子开始体验 SOFAJRaft。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23390449，不错过每场直播。\n 大家好，我是力鲲，来自蚂蚁金服， 现在是 SOFAJRaft 的开源负责人。今天分享主题是《从一个例子开始体验 SOFAJRaft》，其实从这个题目大家也能看出来，今天是要从一个用户而非 owner 的视角来了解 SOFAJRaft。这么设计题目的原因是 SOFAJRaft 作为一种共识算法的实现，涉及到了一些概念和术语，而这些内容更适合通过一系列文章进行阐述，而在直播中我们希望能够分享对用户更有用、更容易理解的信息——SOFAJRaft 是什么，以及我们怎么去用它。\n首先介绍一下 SOFAJRaft 的背景知识，接下来说说这个例子源于什么需求，第三部分是架构的选型，第四部分来看看我们如何使用 SOFAJRaft，最后运行代码，看看 SOFAJRaft 是如何支撑业务运行的。\n欢迎加入社区成为 Contributor，SOFAJRaft。\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务； 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\n图1 - 复制状态机\nSOFAJRaft SOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统。\n图2 - SOFAJRaft 结构\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依然用之前的银行账户系统举例来说明 SOFAJRaft 的各模块是如何工作的。\n当 Client 向 SOFAJRaft 发来一个“存 100 元”的命令之后，Node 的 Log 存储模块首先将这个命令以 Log 的形式存储到本地，同时 Replicator 会把这个 Log 复制给其他的 Node，Replicator 是有多个的，集群中有多少个 Follower 就会有多少个 Replicator，这样就能实现并发的日志复制。当 Node 收到集群中半数以上的 Follower 返回的“复制成功” 的响应之后，就可以把这条 Log 以及之前的 Log 有序的送到状态机里去执行了。状态机是由用户来实现的，比如我们现在举的例子是银行账户系统，所以状态机执行的就是账户金额的借贷操作。如果 SOFAJRaft 在别的场景中使用，状态机就会有其他的执行方式。\nSnapshot 是快照，所谓快照就是对数据当前值的一个记录，Leader 生成快照有这么几个作用：\n 当有新的 Node 加入集群的时候，不用只靠日志复制、回放去和 Leader 保持数据一致，而是通过安装 Leader 的快照来跳过早期大量日志的回放； Leader 用快照替代 Log 复制可以减少网络上的数据量； 用快照替代早期的 Log 可以节省存储空间； 图3 - 需要用户实现：StateMachine、Client\nSOFAJRaft 需要用户去实现两部分：StateMachine 和 Client。\n因为 SOFAJRaft 只是一个工具，他的目的是帮助我们在集群内达成共识，而具体要对什么业务逻辑达成共识是需要用户自己去定义的，我们将用户需要去实现的部分定义为 StateMachine 接口。比如账务系统和分布式存储这两种业务就需要用户去实现不同的 StateMachine 逻辑。而 Client 也很好理解，根据业务的不同，用户需要去定义不同的消息类型和客户端的处理逻辑。\n图4 - 需要用户实现一些接口\n前面介绍了这么多，我们引出今天的主题：如何用 SOFAJRaft 实现一个分布式计数器？\n需求 我们的需求其实很简单，用一句话来说就是：提供一个 Counter，Client 每次计数时可以指定步幅，也可以随时发起查询。\n我们对这个需求稍作分析后，将它翻译成具体的功能点，主要有三部分：\n 实现：Counter server，具备计数功能，具体运算公式为：Cn = Cn-1 + delta； 提供写服务，写入 delta 触发计数器运算； 提供读服务，读取当前 Cn 值； 除此之外，我们还有一个可用性的可选需求，需要有备份机器，读写服务不能不可用。\n系统架构 根据刚才分析出来的功能需求，我们设计出 1.0 的架构，这个架构很简单，一个节点 Counter Server 提供计数功能，接收客户端发起的计数请求和查询请求。\n图5 - 架构 1.0\n但是这样的架构设计存在这样两个问题：一是 Server 是一个单点，一旦 Server 节点故障服务就不可用了；二是运算结果都存储在内存当中，节点故障会导致数据丢失。\n图6 - 架构 1.0 的不足：单点\n针对第二个问题，我们优化一下，加一个本地文件存储。这样每次计数器完成运算之后都将数据落盘，当节点故障之时，我们要新起一台备用机器，将文件数据拷贝过来，然后接替故障机器对外提供服务。这样就解决了数据丢失的风险，但是同时也引来另外的问题：磁盘 IO 很频繁，同时这种冷备的模式也依然会导致一段时间的服务不可用。\n图7 - 架构 1.0 的不足：冷备\n所以我们提出架构 2.0，采用集群的模式提供服务。我们用三个节点组成集群，由一个节点对外提供服务，当 Server 接收到 Client 发来的写请求之后，Server 运算出结果，然后将结果复制给另外两台机器，当收到其他所有节点的成功响应之后，Server 向 Client 返回运算结果。\n图8 - 架构 2.0\n但是这样的架构 …","date":1567400400,"description":"本文根据 SOFAChannel#8 直播分享整理，以 Counter 为例，介绍 SOFAJRaft 的概念，并从需求提出开始，一步步完善架构，明确业务要实现哪些接口，最后启动日志观察 SOFAJRaft 如何支撑业务执行。","dir":"blog/sofa-channel-8-retrospect/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7eab29bc73ad095706ad2daef197b1bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-8-retrospect/","publishdate":"2019-09-02T13:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-channel-8-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#8 直播分享整理，主题：从一个例子开始体验 SOFAJRaft。 回顾视频以及 PPT 查看","tags":["SOFAJRaft","SOFAChannel"],"title":"从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-8-retrospect/","wordcount":5541},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@柴炜晨 提问：\n 求问下 SOFAJRaft rhea split 后，原片1 [0,100) 分裂为 1 [0, 50) , 新片 2[50, 100)，新片 2 上的初始数据是从怎么来的呢？\n A：一个 store 里的所有 region 实际上是共享一个存储，split 只是新增一个逻辑 region 并修改被分裂的和新 region 的 range，后续的 snoapshot ，副本迁移等就均以新的 region 为最小单位了。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、关于 SOFARegistry 的几个问题：\n@虞家成 提问：\n 服务 Sub 数据的一致性问题，其中主要的机制是通过 client, session 对缓存的逐级回放和比对，再加上版本号机制来实现最终一致性，问题是：这个版本号的生成，与递增是由谁来管理与维护？client? session? 还是 data ?\n A：这个版本号主要是在 data 上产生，版本号和最终写入内存时间戳关联产生，所有数据是指服务发布数据保证一致性。\n 对于每条服务的 Pub 数据，是否需要维护一个 ttl 值，否则在某些情况下，这条数据不能释放？\n A：如果你说的 ttl 值是指 pub 数据的生存时间，是有的，我们 pub 数据会有租约机制进行定时更新保证一致性，如果过期会进行清理释放。\n Data 节点是通过广播的方式来通知每个 session 节点？那每个 session 节点是否会存在所有服务的全量 Pub 数据？ 这对内存及网络资源消耗会不会过大？\n A：Data 是通过广播方式通知每个 session 节点，session上有订阅关系按照自己订阅关系判断是否需要推送给客户端。每个 session 没有全量的 pub 数据，但会存在和其连接部分客户端发布数据作为一致性备份回放使用。这个堆内存目前看压力还是可以的。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n3、@黄剑 提问：\n 关于 Seata 有一个问题，全局锁用进去之后，意思就是要等 2 阶段完成后，进行当前资源释放，全局锁那边的接口才进行调用到，如果业务有很多地方都操作到相同表的某一条数据，那岂不是每个业务上面加全局锁？可是我并不知道哪些业务可能会有冲突的哇！\n A：目前只查锁不加锁。\n 我需要查到最终 2 阶段的那张表数据，意思自己的业务上面全部都要使用 @GlobalLock 注解？是这个意思么？\n A：如果你查询的业务接口没有 GlobalTransactional 包裹，也就是这个方法上压根没有分布式事务的需求，这时你可以在方法上标注 @GlobalLock 注解，并且在查询语句上加 for update。如果你查询的接口在事务链路上外层有 GlobalTransactional 注解，那么你查询的语句只要加 for update 就行。设计这个注解的原因是在没有这个注解之前，需要查询分布式事务读已提交的数据，但业务本身不需要分布式事务。若使用 GlobalTransactional 注解就会增加一些没用的额外的 rpc 开销比如 begin 返回 xid，提交事务等。GlobalLock 简化了 rpc 过程，使其做到更高的性能。\n 好的，感谢回复，因为现在出现了一个业务，但是不同接口，上游有全局事务来调用，然后又有其他业务操作了相同的表，所以现在导致我现在根本不知道哪些业务要考虑使用 GlobalLock。\n Seata：https://github.com/seata/seata\n本周推荐阅读 Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录 Service Mesh 发展趋势：云原生中流砥柱 SOFA 项目进展 本周发布详情如下：\n发布 SOFA Mosn v0.7.0，主要变更如下：\n 新增 FeatureGates 的支持 新增一项 Metrics 统计:mosn_process_time 支持 Listener 重启 升级 Go 版本到 1.12.7 修改 XDS Client 启动时机，优先于 MOSN Server 的启动 BUG 修复 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/0.7.0\n","date":1567148400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190830/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"afd535d1a14ed1fc010e93bcff36553d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190830/","publishdate":"2019-08-30T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190830/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/26 - 8/30】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190830/","wordcount":1599},{"author":"敖小剑","categories":"Service Mesh","content":" 敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。\n本文内容整理自 8 月 11 日 Service Mesher Meetup 广州站主题演讲，完整的分享 PPT 获取方式见文章底部。\n 前言 标题“Service Mesh发展趋势(续)”中的“续”是指在今年5月底，我在 CloudNative Meetup上做了一个“Service Mesh发展趋势：云原生中流砥柱”的演讲，当时主要讲了三块内容：Service Mesh 产品动态、发展趋势、与云原生的关系。后来有同学反应希望部分感兴趣的内容能讲的更深一些，所以今天将继续“Service Mesh 发展趋势”这个话题。\n今天给大家分享的内容有部分是上次演讲内容的深度展开，如社区关心的 Mixer v2 以及最近看到的一些业界新的技术方向，如 web assembly 技术，还有产品形态上的创新，如 google traffic director 对 Service Mesh 的虚拟机形态的创新支持。\n在 Service Mesh 出道四年之际，也希望和大家一起带着问题来对 Service Mesh 未来的发展进行一些深度思考。\n在正式开始分享之前，让我们先轻松一下，下面是最近流行的梗，各种灵魂拷问：\n我们今天的分享内容，将效仿上面的方式，对 Servic Mesh 进行四个深入灵魂的拷问。\nService Mesh 灵魂拷问一：要架构还是要性能？ 第一个灵魂拷问针对 Istio 的：要架构还是要性能？\nIstio 的回答：要架构 Istio 的回答很明确：架构优先，性能靠边。\n左边是 Istio 的架构图，从 2017 年的 0.1 版本开始，一直到 Istio1.0，控制平面和数据平面完全物理分离，包括我们今天要关注的 Mixer 模块。Sidecar 通过和 Mixer 的交互实现策略检查和遥测报告。\n右边是 Mixer 的架构图，在 Mixer 内部提供了很多 Adapter 实现，用来提供各种功能。这些 Adapter 运行在 Mixer 进程中，因此被称为进程内适配器（In-Process Adapter）。\n为什么 Istio 选择 Mixer 和 Proxy 分离的架构？\n我们先来看这个架构的优点，概括地说优点主要体现为：\n 架构优雅 职责分明 边界清晰 特别指出，上图右侧的红色竖线，是 Istio0.1 到 Istio1.0 版本中 Istio 和后台基础设施的边界。这意味着，从 k8s API Server 中读取 Adapter 相关的配置信息 （以 Istio CRD 的形式存在），是作为 Istio 功能的一部分。\n具体的优点是：\n Mixer 的变动不影响 Sidecar：包括 Mixer 的部署调整和版本升级； Sidecar 无需和 Adapter 耦合，具体有： Sidecar 不需要读取配置，因此也无需直接连接到 k8s AP Server/Istio Galley； Adapter 的运行时资源开销和 Sidecar 无关； Sidecar 不受 Adapter 增减/更新/升级影响； 保持 Sidecar 代码简单：数以几十计的 Adapter 的代码无需直接进入 Sidecar 代码； 数据平面可替换原则：如果有替换数据平面的需求，则 Mixer 分离的架构会让事情简单很多； 至于缺点，只有一个：性能不好。\n而 1.1 版本之后，Istio 给出了新的回答：架构继续优先，性能继续靠边。\n上图是 Istio1.1 版本之后新的架构图，和之前的差异在于 Mixer 发生了变化，增加了进程外适配器（Out-of-Process Adapter），而 Mixer 和新的 Out-of-Process Adapter 之前依然是远程调用。\n为什么 Istio 改而选择 Out-of-Process Adapter?\n下图是采用 Out-of-Process Adapter 之后的请求处理流程图，Mixer 通过 Bypass Adapter 选择需要的属性列表，然后通过远程调用发送给 Out-of-Process Adapter。Out-of-Process Adapter 实现和之前的 In-Process Adapter 类似的功能，但是改为独立于 Mixer 的单独进程。\n采用 Out-of-Process Adapter 之后，Istio 的优点更加明显了，简单说就是：架构更优雅，职责更分明，边界更清晰。\n而且，请注意：按照 Istio 的设想，此时 Out-of-Process Adapter 已经不再作为 Istio 的组成部分，它的代码实现、安装部署、配置、维护等职责也不再由 Istio 承担，请留意上图中的红色竖线位置。Out-of-Process Adapter 的引入，对于 Istio 来说职责和边界的改变会让 Istio 简单，但是对于使用者（主要指运维）来说则增加了额外的负担，因此造成了很大的争议。\n至于缺点，除了上述的职责转移造成争议外，依然只有一个：性能不好，原来 Sidecar 和 Mixer 之间的远程调用已经让性能变得非常糟糕，现在 Mixer 和 Out-of-Process Adapter 之间再增多加一次远程调用，可谓雪上加霜。\nMixer v1 架构的优缺点分析 Mixer v1 架构的优点主要体现为：\n 集中式服务：提高基础设施后端的可用性，为前置条件检查结果提供集群级别的全局 2 级缓存； 灵活的适配器模型，使其以下操作变得简单： 运维添加、使用和删除适配器； 开发人员创建新的适配器（超过20个适配器）； 而 Mixer v1 架构的缺点，则主要体现为：\n 管理开销： 管理 Mixer 是许多客户不想负担的； 而进程外适配器强制运维管理适配器，让这个负担更加重； 性能： 即使使用缓存，在数据路径中同步调用 Mixer 也会增加端到端延迟； 进程外适配器进一步增加了延迟； 授权和认证功能是天然适合 mixer pipeline 的，但是由于 mixer 设计的延迟和 SPOF（单点故障）特性，导致直接在 Envoy 中实现(Envoy SDS)； 复杂性： Mixer 使用一组称为模板的核心抽象，来描述传递给适配器的数据。这些包括“metrics”，“logentry”，“tracepan”等。这些抽象与后端想要消费的数据不匹配，导致运维需要编写一些手动配置，以便在规范的 Istio 样式和后端特定的样式之间进行映射。原本期望这种映射可以在适配器中实现很大程度上的自动化，但是最终还是太复杂并需要手动配置。 备注：上述优点和缺点的描述摘录自 mixer v2 proposal 。\n 其中，Mixer 性能问题一直以来都是 Istio 最被人诟病的地方。\n那问题来了：如果要性能，该怎么做？\n下图是 Mixer v1 的调用流程，Proxy/Sidecar 是请求数据的起点，Infrastructure Backend 是终点。Mixer v1 …","date":1566972000,"description":"继续探讨 Service Mesh 发展趋势：深度分析 Istio 的重大革新 Mixer v2，Envoy 支持 Web Assembly 的意义所在；深入介绍 Google Traffic Director 对虚拟机模式的创新支持方式，以及最近围绕 SMI 发生的故事。","dir":"blog/service-mesh-development-trend-2/","fuzzywordcount":8100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"51e4af6a0771823fe055c5aebd2e76bd","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-development-trend-2/","publishdate":"2019-08-28T14:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/service-mesh-development-trend-2/","summary":"敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。 本文内容整理","tags":["Service mesh"],"title":"Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-development-trend-2/","wordcount":8088},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@廖春涛 提问：\n 在 SOFAJRaft 中，snapshot load 后应该会有个日志重放的实现，但是我目前看代码没看到说 snapshot 和 LogEntry 有关联的地方，请问是什么关系呢？\n A：snapshot 就是为了压缩日志，以及加快新节点加入。snapshot 后，会将上上次的 snapshot 当时对应的日志级之前的删掉，为什么是上上次？ 因为本次 snapshot 的日志，可能还没有复制到所有 follower，这是一个小优化。 具体到日志重放，如果启动是 leader，会写入一条当前配置的日志，触发 fsm caller 的 onCommitted，然后去重放从 snapshot 的日志到最新的 committed 的日志到状态机。如果是 follower，安装 snapshot 后， leader 会发送该 snapshot 对应的日志之后的日志，走正常的复制流程，因此也会重放到最新的状态机。\n SOFAJRaft 当 Leader 的 Node 执行 apply 后，将 LogEntry 提交给 follower 是通过通知来进行的吗？是不是在 LogManagerImpl 里面的这串代码 A：这段是 wakeup replicators，复制日志到 follower 都是在 Replicator 中实现的。\n2、关于 Seata 的 grouplist 问题：\n 什么时候会用到 file.conf 中的 default.grouplist？\n A：当 registry.type=file 时会用到，其他时候不读。\n default.grouplist 的值列表是否可以配置多个？\n A：可以配置多个，配置多个意味着集群，但当 store.mode=file 时，会报错。原因是在 file 存储模式下未提供本地文件的同步，所以需要使用 store.mode=db，通过 db 来共享 TC 集群间数据\n 是否推荐使用 default.grouplist？\n A：不推荐，如问题1，当 registry.type=file 时会用到，也就是说这里用的不是真正的注册中心，不具体服务的健康检查机制当tc不可用时无法自动剔除列表，推荐使用 nacos 、eureka、redis、zk、consul、etcd3、sofa。registry.type=file 或 config.type=file 设计的初衷是让用户再不依赖第三方注册中心或配置中心的前提下，通过直连的方式，快速验证 Seata 服务。\n3、关于 Seata 事务分组：\n 什么是事务分组？\n A：事务分组是 Seata 的资源逻辑，类似于服务实例。在 file.conf 中的 my_test_tx_group 就是一个事务分组。\n 通过事务分组如何找到后端集群？\n A：首先程序中配置了事务分组（GlobalTransactionScanner 构造方法的 txServiceGroup 参数），程序会通过用户配置的配置中心去寻找 service.vgroup_mapping. 事务分组配置项，取得配置项的值就是 TC 集群的名称。拿到集群名称程序通过一定的前后缀+集群名称去构造服务名，各配置中心的服务名实现不同。拿到服务名去相应的注册中心去拉取相应服务名的服务列表，获得后端真实的 TC 服务列表。\n 为什么这么设计，不直接取服务名？\n A：这里多了一层获取事务分组到映射集群的配置。这样设计后，事务分组可以作为资源的逻辑隔离单位，当发生故障时可以快速 failover。\nSOFA 项目进展 本周发布详情如下：\n1、发布 Seata v0.8.0 版本，主要变更如下：\n 支持 oracle 数据库的 AT 模式 支持 oracle 数据库的批量操作 支持 undo_log 表名可配置 修复 xid 在 db 模式可重复的问题 优化数据镜像比对日志 详细参考发布报告：https://github.com/seata/seata/releases/tag/v0.8.0\n2、发布 SOFAARK v1.0.0 版本，主要变更如下：\n 支持插件批量导出资源和 ark-biz 禁止批量导入资源 支持指定版本调用，解决对于非激活状态的ark-biz服务访问问题（主要用于灰度验证，测试等） 支持打包时跳过打ark-executable 包的过程（优化） 支持从目录运行启动 ArkClient api 支持指定 biz 的 arguments 参数 使用 netty 代替 java NIO 实现 telnet server 支持 SpringBoot testNG 优化示例工程 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.0.0 SOFA 活动推荐 SOFA:Channel/线上直播第 8 期报名中~ 8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。\n 本期主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft 直播时间：8 月 29 日下周四晚 7点 你将收获： 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 报名方式：点击“这里” 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可） ","date":1566543600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190823/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"067db1c93be21087cc809be0294c1b32","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190823/","publishdate":"2019-08-23T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190823/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/19 - 8/23】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190823/","wordcount":1855},{"author":"苟利","categories":"SOFAMeetup","content":" 作者：苟利（陈自欣），蚂蚁金服中间件产品专家， 负责蚂蚁金服分布式链路跟踪系统的产品化工作，在日志分析、监控领域有多年工作经验。\n本文根据 8 月 11 日 SOFA Meetup#3 广州站 《蚂蚁金服在云原生架构下的可观察性的探索和实践》主题分享整理。现场回顾视频以及 PPT 查看地址见文末链接。\n前言 随着应用架构往云原生的方向发展，传统监控技术已经不能满足云原生时代运维的需求，因此，可观察性的理念被引入了 IT 领域。\n下面我将会就可观察性在云原生的起源，可观察性发展动力， 可观察性与监控的关系，可观察性的三大支柱，社区发展方向及产品现状，以及蚂蚁金服对相关问题的理解及实践进行探讨。\n才疏学浅，欢迎拍砖。\n为什么云原生时代需要可观察性 可观察性的由来 在云原生语境下的可观察性这个词，最早出现于2017年7月， Cindy Sridharan 在 Medium 写的一篇博客， \u0026amp;ldquo;Monitoring and Observability\u0026amp;ldquo;，谈到了可观察性与云原生监控的关系。\n而在2017年10月， 来自 Pivotal 公司的 Matt Stine，在接受 InfoQ 采访的时候，对云原生的定义进行了调整， 将Cloud Native Architectures 定义为具有以下六个特质：\n 模块化 （Modularity） (通过微服务) 可观察性 （Observability） 可部署性 （Deployability） 可测试性 （Testability） 可处理性 （Disposability） 可替换性 （Replaceability） 可见，在2017年下半年， 可观察性成为了一个 buzzword（时髦词） ，正式出现在了云计算领域。\n可观察性的定义 虽然“可观察性”这个词在 IT 行业是一个新的术语，但它其实是在上世纪60年代，由匈牙利裔工程师鲁道夫·卡尔曼提出的概念。\n术语“可观察性”，源于控制论，是指系统可以由其外部输出推断其内部状态的程度。\n这个外部输出， 在云原生的语境下，即 Telemetry ，遥测，通常由服务（services）产生，划分为三个维度或者说支柱， Tracing（跟踪），Metrics（指标） , Logging（日志）。\n为什么云原生需要可观察性 近年可以看到，云计算对基础架构改变甚为巨大，无论是互联网行业，还是传统行业，云化在提升资源利用率，提高业务敏捷性的价值已经成为了公式。而在应用层面，由于业务特性的原因，互联网公司大部分已经完成云化，应用架构也不同程度上，完成了从单体应用向微服务应用演进。 在转型后，整体系统复杂性大大增加，倒逼相应的工具及方法论进行升级改造， 去 hold 住这么复杂的局面。\n上图为 Uber 展示的总体调用链图。考虑到业务多样性及复杂度，在蚂蚁金服内部，相关调用关系只会更为复杂，用人类的智力，已经没有办法去理解如此复杂的调用关系。而上图只是展示了可观察性的链路调用， 如果再加上指标及日志， 不对工具及方法论进行革新， 是难以实现对复杂微服务架构的管控的。\n微服务只是云原生的模块化特性的体现， 再考虑到近年被广泛应用容器，Kubernetes , 以及大家关注度极高的 Service Mesh , Istio， 每一个新的技术的出现，在带来了更优雅的架构、更灵活的调度、更完善的治理的同时，也带来更多新的复杂性。\n因此，可观察性对于云原生的应用架构，是必不可少的特性。\n可观察性和传统监控的区别 说半天，不少同学就会说，这个可观察性与我们谈的最多的监控有什么区别。 虽然有不少的人认为， 这词就是个buzzword，就是赶时髦的，没有太大的意义， 但是我结合网上的讨论， 个人认为可观察性与监控， 含义上虽然接近，但是也有一些理念上的差别，使得讨论可观察性这个词，是有具有现实意义，并能真正产生相应的价值。\n 监控更多关注的是基础设施，更多与运维工程师相关，更强调是从外部通过各种技术手段去看内部，打开黑盒系统。 可观察性更多的是描述应用，在我们谈论具体某应用，或者是某些应用是否具备客观性的时候，通常与开发人员相关，因为在常见的可观察性的实践之中，开发人员需要在应用的开发过程中嵌入例如 statd 或者是 opentracing，或者是 opencensus 等所提供的库，对相关的 telemetry 进行输出，或者是俗话说的埋点。通过埋点，将服务内部的状态白盒化，使得其在运维阶段具备可观察性。某种程度上可以说，可观察性遵循了 DevOps 及 SRE 的理念，即研发运维一体化，从开发侧就考虑系统的可运维性。  这里值得补充说明的是，目前市面上，有商用或者开源APM 方案，通过入侵 JVM 或者其他技术手段，对应用进行自动埋点的，输出 trace 及 metrics 信息。 这同样也是一种可观察性的实现方式，这样做的最大的好处是，不需要对现有的应用进行改造，但是相应的 agent 对应用进行实时的监控， 必然会或多或少的增加资源的占用，例如每实例额外 30+MB 内存，5~10% 的 CPU 占用，在大规模的运行环境之中， 会有不少的成本增加。\n可观察性的三大支柱及社区进展 可观察性的三大支柱 可观察性的三大支柱及其之间的关系， Peter Bourgon 在2017年2月撰写了一篇简明扼要的文章， 叫 \u0026amp;ldquo;Metrics, tracing, and logging\u0026amp;rdquo; ， 有兴趣的可以去看一下， 以下仅为简单的提及。\n指标数据（Metrics Data） 描述具体某个对象某个时间点的值。在 Prometheus 中， 指标有四种类型，分别 Counter（计数器）、Gauge（瞬时值）、Histogram（直方图）和 Summary （概要）， 通过这四种类型，可以实现指标的高效传输和存储。\n日志数据 ( Logging Data） 描述某个对象的是离散的事情，例如有个应用出错，抛出了 NullPointerExcepction，或者是完成了一笔转账，个人认为 Logging Data 大约等同于 Event Data，所以告警信息在我认为，也是一种 Logging Data。 但是也有技术团队认为，告警应该算是可观察性的其中一个支柱。 跟踪数据（Tracing Data） Tracing Data 这词貌似现在还没有一个权威的翻译范式，有人翻译成跟踪数据，有人翻译成调用数据，我尽量用Tracing 这个词。 Tracing 的特点就是在单次请求的范围内处理信息，任何的数据、元数据信息都被绑定到系统中的单个事务上。 一个Trace 有一个唯一的Trace ID ，并由多个Span 组成。\n社区方案进展 由于可观察性在云原生中，是一个非常重要的特性， 因此，在开源世界中，先后出现了两个定位都比较类似的项目，分别是源自 Google 的 OpenCensus （定位上报 Tracing + metris） 和由 CNCF 孵化的 OpenTracing（定位上报 Tracing）。 两者都定位于提供厂商中立的技术规范，及实现该规范各种编程语言遥测库，使得用户在使用了相关的库以后，可 …","date":1566381600,"description":"本文根据 8 月 11 日 SOFA Meetup#3 广州站 《蚂蚁金服在云原生架构下的可观察性的探索和实践》主题分享整理，文中包含本次分享视频回顾以及 PPT 查看地址。","dir":"blog/sofa-meetup-3-cloud-original-retrospect/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"85eba21fd9adf73841d7b7ee103723ae","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","publishdate":"2019-08-21T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","summary":"作者：苟利（陈自欣），蚂蚁金服中间件产品专家， 负责蚂蚁金服分布式链路跟踪系统的产品化工作，在日志分析、监控领域有多年工作经验。 本文根据 8 月 11","tags":["SOFAMeetup"],"title":"蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","wordcount":4758},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n本周推荐阅读 分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾 中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说 溢米教育推荐平台的效率与稳定性建设 | SOFAStack 用户说 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.2.6, 主要变更如下： - i. 修复 ReadIndex 并发情况下可能出现的读超时 - ii. 保存 raft meta 失败后终止状态机 - iii. 增加 LogEntry checksum validation - iv. 优化 log replication 线程模型减少锁竞争 - v. 优化 RheaKV multi group snapshot - vi. 致谢（排名不分先后）@SteNicholas @zongtanghu\n详细参考发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.2.6\nSOFA 活动推荐  SOFA:Channel/线上直播第 8 期《从一个例子开始体验 SOFAJRaft》报名中~\n8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。 在本次直播中，我们将重点放在如何去使用这个工具上，用示例来说明如何使用 SOFAJRaft 实现自己的分布式应用。在此过程中，我们会对涉及到的一些 SOFAJRaft 经典概念进行讲解。\n| 点击“这里”即可报名\n| 本期将带来：\n 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可）\n","date":1565942400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190816/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"277754f72430d4473dc3920edbaf2ddb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190816/","publishdate":"2019-08-16T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190816/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/12 - 8/16】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190816/","wordcount":724},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft\n 活动时间：8 月 29 日周四晚 7 点\n 活动形式：线上直播\n 视频回顾：https://tech.antfin.com/community/live/821\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#8：从一个例子开始体验 SOFAJRaft SOFAJRaft 是 Raft 算法的 Java 实现，其本质是一个工具项目。在本次直播中，我们将重点放在如何去使用这个工具上，用示例来说明如何使用 SOFAJRaft 实现自己的分布式应用。在此过程中，我们会对涉及到的一些 SOFAJRaft 经典概念进行讲解。\n为了更好地直播体验，可以在直播前，预习 SOFAJRaft 相关源码解析文章，文章集合：https://www.sofastack.tech/tags/sofajraft/\n8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/737\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 SOFAChannel#8：从一个例子开始体验 SOFAJRaft 力鲲 SOFAJRaft 开源负责人\n本期分享大纲： 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 嘉宾 SOFAGirl 主持人 力鲲 SOFAJRaft 开源负责人 ","date":1565842200,"description":"8 月 29 日周四晚 7 点，线上直播第 8 期。","dir":"activities/sofa-channel-8/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"92590333a35992bc201c798645cbf7ea","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-8/","publishdate":"2019-08-15T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-8/","summary":"概要 活动主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft 活动时间：8 月 29 日周四晚 7 点 活动形式：线上直播 视频回顾：https://tec","tags":["SOFAChannel","SOFAJRaft"],"title":"SOFAChannel#8：从一个例子开始体验 SOFAJRaft","type":"activities","url":"/sofastack.tech/activities/sofa-channel-8/","wordcount":561},{"author":"屹远","categories":"Seata","content":" 作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。 本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，着重分享分布式事务产生的背景、理论基础，以及 Seata 分布式事务的原理以及三种模式（AT、TCC、Saga）的分布式事务实现。\n本次分享的视频回顾以及 PPT 查看地址：https://tech.antfin.com/community/activities/779/review\n一、分布式事务产生的背景 1.1 分布式架构演进之 - 数据库的水平拆分 蚂蚁金服的业务数据库起初是单库单表，但随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。所以我们对数据库进行了水平拆分，将原单库单表拆分成数据库分片。\n如下图所示，分库分表之后，原来在一个数据库上就能完成的写操作，可能就会跨多个数据库，这就产生了跨数据库事务问题。\n1.2 分布式架构演进之 - 业务服务化拆分 在业务发展初期，“一块大饼”的单业务系统架构，能满足基本的业务需求。但是随着业务的快速发展，系统的访问量和业务复杂程度都在快速增长，单系统架构逐渐成为业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。\n如下图所示，蚂蚁金服按照面向服务架构（SOA）的设计原则，将单业务系统拆分成多个业务系统，降低了各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。\n业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，如何保证多个服务间的数据一致性成为一个难题。\n二、分布式事务理论基础 2.1 两阶段提交协议 两阶段提交协议：事务管理器分两个阶段来协调资源管理器，第一阶段准备资源，也就是预留事务所需的资源，如果每个资源管理器都资源预留成功，则进行第二阶段资源提交，否则协调资源管理器回滚资源。\n2.2 TCC TCC（Try-Confirm-Cancel） 实际上是服务化的两阶段提交协议，业务开发者需要实现这三个服务接口，第一阶段服务由业务代码编排来调用 Try 接口进行资源预留，所有参与者的 Try 接口都成功了，事务管理器会提交事务，并调用每个参与者的 Confirm 接口真正提交业务操作，否则调用每个参与者的 Cancel 接口回滚事务。\n2.3 Saga Saga 是一种补偿协议，在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。\n分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。\nSaga 理论出自 Hector \u0026amp;amp; Kenneth 1987发表的论文 Sagas。\nSaga 正向服务与补偿服务也需要业务开发者实现。\n三、Seata 及其三种模式详解 3.1 分布式事务 Seata 介绍 Seata（Simple Extensible Autonomous Transaction Architecture，一站式分布式事务解决方案）是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。Seata 开源半年左右，目前已经有超过 1.1 万 star，社区非常活跃。我们热忱欢迎大家参与到 Seata 社区建设中，一同将 Seata 打造成开源分布式事务标杆产品。\nSeata：https://github.com/seata/seata\n3.2 分布式事务 Seata 产品模块 如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。\n在 Seata 中，分布式事务的执行流程：\n TM 开启分布式事务（TM 向 TC 注册全局事务记录）； 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）； TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）； TC 汇总事务信息，决定分布式事务是提交还是回滚； TC 通知所有 RM 提交/回滚 资源，事务二阶段结束； 3.3 分布式事务 Seata 解决方案 Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。\n3.3.1 AT 模式 今年 1 月份，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。\nAT 模式如何做到对业务的无侵入 ： 一阶段： 在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。\n 二阶段提交： 二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。\n 二阶段回滚： 二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。\nAT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。\n3.3.2 TCC 模式 2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。\nTCC 三个方法描述：\n Try：资源的检测和预留； Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功； Cancel：预留资源释放； 蚂蚁金服在 TCC 的实践经验\n1 TCC 设计 - 业务模型分 2 阶段设计：\n用户接入 TCC ，最重要的是考虑如何将自己的业务模型拆成两阶段来实现。\n以“扣钱”场景为例，在接入 TCC 前，对 A 账户的扣钱，只需一条更新账户余额的 SQL 便能完成；但是在接入 TCC 之后，用户就需要考虑如何将原来一步就能完 …","date":1565776800,"description":"本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，文中包含本次分享视频回顾以及 PPT 查看地址。","dir":"blog/sofa-meetup-3-seata-retrospect/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"841ac02b2ce20e10748bf97db9d644ec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","publishdate":"2019-08-14T18:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","summary":"作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。 本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，着重分享分布式事务","tags":["Seata","SOFAMeetup"],"title":"分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","wordcount":5793},{"author":"胡宗棠","categories":"SOFAJRaft","content":" 文章摘要：BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云服务中的最佳应用实践。\n前言： 高可用的定义，指的是“一个系统经过特有的设计与改造，减少因不确定故障停服的时间，从而对业务使用方来说可以保证其服务的高度可用性”。在生产环境中，往往会存在很多不可预知的故障因素，比如虚拟机宕机、磁盘损坏和网络故障等，因此系统自身的高可用是任何工业级产品所需重点考虑的因素。\n对于消息队列服务来说，考虑到故障切换和业务感知等问题，传统的高可用方式（冷备或者热备）一般都不太适用。在经过多种技术方案对比后，我们发现采用基于 Raft 共识算法的多副本设计方案可以满足我们产品的要求，因此在鉴权认证组件和API计量服务组件中，我们集成了蚂蚁金服开源的 SOFAJRaft 库，实现这两个组件应对单点故障的高可用。\nGitHub 地址：https://github.com/sofastack/sofa-jraft\n一、背景知识：Raft 共识性算法是什么？ Raft 是一种分布式系统中易于理解的共识算法，该协议本质上是 Paxos 算法的精简版，而不同的是依靠 Raft 模块化的拆分以及更加简化的设计，其实现起来更加容易和方便。[1]\n模块化的拆分主要体现在 Raft 把一致性协议划分为如下几部分：\n Leader 选举； Membership 变更； 日志复制； Snapshot。 而更加简化的设计则体现在：Raft 不允许类似 Paxos 中的乱序提交、简化系统中的角色状态（算法定义 Leader、Follower 和 Candidate 三种角色）、限制仅 Leader 可写入、采用随机超时触发 Leader Election 机制来避免“瓜分选票”等等。[2]\n1.1 Raft 算法的整体结构概览 从上面的 Raft 算法整体结构图中可以看出，整个分布式系统中同一时刻有且仅有一个 Leader 角色的节点（如图最右边的服务器），只有 Leader 节点可以接受 Client 发送过来的请求。Leader 节点负责主动与所有 Follower 节点进行网络通信（如图左边两个服务器），负责将本地的日志发送给所有 Follower 节点，并收集分布式系统中多数派的 Follower 节点的响应。此外，Leader 节点，还需向所有 Follower 节点主动发送心跳维持领导地位（即：保持存在感）。\n所以，只要各个节点上的日志保持内容和顺序是一致的，那么节点上的状态机就能以相同的顺序执行相同的命令，这样它们执行的结果也都是一样的。\n1.2 Raft 算法的三种角色及转换 Follower：完全被动，不能发送任何请求，只接受并响应来自 Leader 和 Candidate 的 Message，每个节点启动后的初始状态一般都是 Follower； Leader：处理所有来自客户端的请求、复制 Log 到所有 Follower，并且与 Follower 保持心跳请求； Candidate：节点竞选 Leader 时的状态。Follower 节点在参与选举之前，会将自己的状态转换为 Candidate。 1.3 任期与逻辑时钟概念 时间被划分为多个任期 term（如同总统选举一样），term id 按时间轴单调递增； 每一个任期开始后要做的第一件事都是选举 Leader 节点，选举成功之后，Leader 负责在该任期内管理整个分布式集群，“日志复制”、“通过心跳维护自己的角色”； 每个任期至多只有一个 Leader 节点，也可能没有 Leader (由于“分票”导致)。 1.4 Raft 算法的实际应用实现 目前，Raft 算法已经成熟地应用于诸多知名的开源项目中。业界非常著名的 Etcd(Kubernetes 高可用强一致性的服务发现组件)和 TiKV (高性能开源 KV 存储)均是 Raft 算法的实现。\n二、BC-MQ 基于 Raft 的高可用设计 为满足企业上云和构建万物相连的物联网业务需求，中国移动苏州研发中心结合自身在云计算产品和技术的较多积累，研发了大云消息队列中间件产品 BC-MQ。该产品基于 Apache 开源社区的 RocketMQ 内核，同时结合云端 PAAS 产品架构和消息中间件的应用业务需求进行深度优化和定制化的研发，提供了一款可以满足于云端场景的高性能、高可靠、低延迟和高可用的工业级产品。\n本节从解决原有高可用技术方案的问题视角出发，同时结合选型 SOFAJRaft 库的缘由，将详细阐述 BC-MQ 产品中的安全认证和 API 计量采集服务的高可用设计方案（注：这里不会涉及到安全认证和 API 计量采集组件本身的技术方案细节）。\n2.1 GlusterFS+Keepalived 高可用方案与问题 1. GlusterFS+Keepalived 高可用设计方案 在BC-MQ原有的方案中，多组安全认证服务各自独立部署组建集群，各个安全认证服务相互独立，没有主从关联，服务本身无状态，可水平任意扩展。安全认证服务的高可用依赖于RPC通信的客户端保证，其主要通过负载均衡算法从安全认证服务集群选择一个节点发送RPC请求来实现租户级鉴权认证元数据的获取。在生产环境中，如果出现其中一个安全认证节点宕机不可用时，客户端的RPC通信层能够及时感知并从本地的Node列表中剔除不可用节点。\n集群中有状态的租户级安全认证元数据的强一致性由GlusterFS分布式文件存储的同步机制来保证。安全认证服务组建高可用集群的具体设计方案图如下所示：\n而 BC-MQ 中 API 计量采集服务组件的高可用性则是依靠 Keepalived 组件的冷备模式结合 GlusterFS 分布式文件存储的同步机制共同保证，从而在一定程度上解决了 API 计量采集服务的单点不可用问题。API 计量采集服务的具体高可用设计方案图如下所示：\n2. GlusterFS+Keepalived 高可用方案遇到的问题 初步看上面的这种高可用技术方案挺完美的。但是经过验证和仔细推敲后就发现在生产环境中可能会存在如下几个问题：\n 上面所述的高可用设计方案中引入了 GlusterFS 分布式文件存储系统和 Keepalived 组件，这增加了系统整体的运维复杂度，给运维人员带来很多人工介入排查和部署的工作负担；另一方面，GlusterFS 和 Keepalived 本身的可靠性、稳定性和性能指标等问题也需要软件研发人员重点关注，这增加了系统整体设计的复杂度； 在实际的生产环境中，Keepalived 组件采用冷备方式作为高可用方案需要考虑主机故障宕机后切换到备机的时间成本消耗。在这段时间内，API 计量服务是短暂不可用的。因此，Keepalived 组件的主备切换会造成业务感知影响，导致一些业务的风险发生。 2.2 基于 SOFAJRaft 库的高可用设计方案 由于“GlusterFS+Keepalived”的高可用方案存在上一节阐述的两个问题，所以我们考虑是否可以采用其他的高可用方案来解决这两个问题？目标：即使生产环境出现部分节点故障后， …","date":1565694000,"description":"BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云服务中的最佳应用实践。","dir":"blog/sofa-jraft-user-china-mobile/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a7eb984bdb11d8c0b47133af4c16f48f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-user-china-mobile/","publishdate":"2019-08-13T19:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-user-china-mobile/","summary":"文章摘要：BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云","tags":["SOFAJRaft"],"title":"中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-user-china-mobile/","wordcount":6179},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n关于 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 的讨论： @龚小涛 提问： \u0026amp;gt; 对于快照部分讲解是对某一刻时间点的数据做的快照吗，然后此快照最新的记录下 logindex term 等信息？\nA：快照里记录的数据不是日志复制的数据，而是状态机执行的结果，这个快照数据保存的动作是由用户通过实现这个接口来实现的： com.alipay.sofa.jraft.StateMachine#onSnapshotSave 。当然，里面的快照里面还包括了一些 index、term 等元信息。所以如果你理解的数据是由状态机执行的结果，那理解是对的。\n 关于快照的解决方案中是对数据集合的快照，这里可以细说下吗？\n A：快照中保存的是用户自定义的状态机的当前的状态，具体内容需要用户自己去实现，你可以看下这个接口： com.alipay.sofa.jraft.StateMachine#onSnapshotSave，比如 Counter 这个 example 中，保存的就是计数器当前的 value。\nSOFAJRaftLab 系列阅读 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n发布 SOFARegistry 5.2.1, 主要变更如下： i. 安全修改，升级 Jettyserver 版本到 9.4.17.v20190418. ii. jraft bug 修正版本到1.2.5 iii. 修复 dataServer 启动没有 working 时刻一些操作延迟处理问题 iv. data 重连 meta 逻辑 bug 导致所有 data 无法连接 meta 修改 v. data 从 working 状态变回 init 状态 bug 修改 详细发布报告： https://github.com/sofastack/sofa-registry/releases/tag/v5.2.1\nSOFA 活动推荐 SOFA Meetup #3《从开源技术到产品能力》，本周日我们在广州等你~\n本期活动将为大家带来蚂蚁金服在这些方面的探索和实践，解析 SOFARPC、分布式事务 Seata、无线自动化测试框架 SoloPi 等开源项目的内部大规模落地和社区发展，并且通过可观察性的理念，实现对微服务，Service Mesh 以至未来的 Serverless 架构的应用进行监控，帮助大家应对从应用架构过渡到云原生架构的挑战。\n报名方式：点击“这里”了解活动详情。\n","date":1565337600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190809/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"31aa100cb2b1edaacaa1874644af50ff","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190809/","publishdate":"2019-08-09T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190809/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/5 - 8/9】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190809/","wordcount":1018},{"author":"力鲲、徐家锋","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第六篇，本篇作者徐家锋，来自专伟信息，力鲲，来自蚂蚁金服。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：\u0026amp;lt;SOFA:JRaftLab/\u0026amp;gt;，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n本文的目的是要介绍 SOFAJRaft 在日志复制中所采用的 pipeline 机制，但是作者落笔时突然觉得这个题目有些唐突，我们不应该假设读者理所应当的对日志复制这个概念已经了然于胸，所以作为一篇解析，我觉得还是应该先介绍一下 SOFAJRaft 中的日志复制是要解决什么问题。\n概念介绍 SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法，就不可避免的要对需要达成共识的内容在多个服务器节点之间进行传输，在 SOFAJRaft 中我们将这些内容封装成一个个日志块 (LogEntry)，这种服务器节点间的日志传输行为在 SOFAJRaft 中也就有了专门的术语：日志复制。\n为了便于阅读理解，我们用一个象棋的故事来类比日志复制的流程和可能遇到的问题。\n假设我们穿越到古代，要为一场即将举办的象棋比赛设计直播方案。当然所有电子通讯技术此时都已经不可用了，幸好象棋比赛是一种能用精简的文字描述赛况的项目，比如：“炮二平五”, “马８进７”, “车２退３”等，我们将这些描述性文字称为棋谱。这样只要我们在场外同样摆上棋盘 (可能很大，方便围观)，通过棋谱就可以把棋手的对弈过程直播出来。\n图1 - 通过棋谱直播\n所以我们的直播方案就是：赛场内两位棋手正常对弈，设一个专门的记录员来记录棋手走出的每一步，安排一个旗童飞奔于赛场内外，棋手每走一步，旗童就将其以棋谱的方式传递给场外，这样观众就能在场外准实时的观看对弈的过程，获得同观看直播相同的体验。\n图2 - 一个简单的直播方案\n这便是 SOFAJRaft 日志复制的人肉版，接下来我们完善一下这个“直播系统”，让它逐步对齐真实的日志复制。\n改进1. 增加记录员的数量 假设我们的比赛获得了很高的关注度，我们需要在赛场外摆出更多的直播场地以供更多的观众观看。\n这样我们就要安排更多的旗童来传递棋谱，场外的每一台直播都需要一个旗童来负责，这些旗童不停的在赛场内外奔跑传递棋谱信息。有的直播平台离赛场远一些，旗童要跑很久才行，相应的直播延迟就会大一些，而有些直播平台离得很近，对应的旗童就能很快的将对弈情况同步到直播。\n随着直播场地的增加，负责记录棋局的记录员的压力就会增加，因为他要针对不同的旗童每次提供不同的棋谱内容，有的慢有的快。如果记录员一旦记混了或者眼花了，就会出现严重的直播事故(观众看到的不再是棋手真正的棋局)。\n图4 - 压力很大的记录员\n为此我们要作出一些优化，为每个场外的直播平台安排一个专门的记录员，这样 “赛局-记录员-旗童-直播局” 就构成了单线模式，专人专职高效可靠。\n图5 - “赛局-记录员-旗童-直播棋局”\n改进2. 增加旗童每次传递的信息量 起初我们要求棋手每走一步，旗童就向外传递一次棋谱。可是随着比赛进行，其弊端也逐渐显现，一方面记录员记录了很多棋局信息没有传递出去，以至于不得不请求棋手停下来等待 (不可思议)；另一方面，场外的观众对于这种“卡帧”的直播模式也很不满意。\n所以我们做出改进，要求旗童每次多记几步棋，这样记录员不会积攒太多的待直播信息，观众也能一次看到好几步，而这对于聪明的旗童来说并不是什么难事，如此改进达到了共赢的局面。\n图6 - 旗童批量携带信息\n改进3. 增加快照模式 棋局愈发精彩，应棋迷的强烈要求，我们临时增加了几个直播场地，这时棋手已经走了很多步了，按照我们的常规手段，负责新直播的记录员和旗童需要把过去的每一步都在直播棋盘上还原一遍(回放的过程)，与此同时棋手还在不断下出新的内容。\n从直觉上来说这也是一种很不聪明的方式，所以这时我们采用快照模式，不再要求旗童传递过去的每一步棋谱，而是把当前的棋局图直接描下来，旗童将图带出去后，按照图谱直接摆子。这样新直播平台就能快速追上棋局进度，让观众欣赏到赛场同步的棋局对弈了。\n图7 - 采用快照模式\n改进4. 每一个直播平台用多个旗童传递信息 虽然我们之前已经在改进 2 中增加了旗童每次携带的信息量，但是在一些情况下(棋手下快棋、直播平台很远等)，记录员依然无法将信息及时同步给场外。这时我们需要增加多个旗童，各旗童有次序的将信息携带到场外，这样记录员就可以更快速的把信息同步给场外直播平台。\n图8 - 利用多个旗童传递信息，实现 pipeline 效果\n现在这个人肉的直播平台在我们的逐步改进下已经具备了 SOFAJRaft 日志复制的下面几个主要特点：\n特点1: 被复制的日志是有序且连续的 如果棋谱传递的顺序不一样，最后下出的棋局可能也是完全不同的。而 SOFAJRaft 在日志复制时，其日志传输的顺序也要保证严格的顺序，所有日志既不能乱序也不能有空洞 (也就是说不能被漏掉)。\n图9 - 日志保持严格有序且连续\n特点2: 复制日志是并发的 SOFAJRaft 中 Leader 节点会同时向多个 Follower 节点复制日志，在 Leader 中为每一个 Follower 分配一个 Replicator，专用来处理复制日志任务。在棋局中我们也针对每个直播平台安排一个记录员，用来将对弈棋谱同步给对应的直播平台。\n图10 - 并发复制日志\n特点3: 复制日志是批量的 SOFAJRaft 中 Leader 节点会将日志成批的复制给 Follower，就像旗童会每次携带多步棋信息到场外。\n图11 - 日志被批量复制\n特点4: 日志复制中的快照 在改进 3 中，我们让新加入的直播平台直接复制当前的棋局，而不再回放过去的每一步棋谱，这就是 SOFAJRaft 中的快照 (Snapshot) 机制。用 Snapshot 能够让 Follower 快速跟上 Leader 的日志进度，不再回放很早以前的日志信息，即缓解了网络的吞吐量，又提升了日志同步的效率。\n特点5: 复制日志的 pipeline 机制 在改进 4 中，我们让多个旗童参与信息传递，这样记录员和直播平台间就可以以“流式”的方式传递信息，这样既能保证信息传递有序也能保证信息传递持续。\n在 SOFAJRaft 中我们也有类似的机制来保证日志复制流式的进行，这种机制就是 pipeline。Pipeline 使得 Leader 和 Follower 双方不再需要严格遵从 “Request - Response - Request” 的交互模式，Leader …","date":1565080200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第六篇，本篇作者徐家锋、力鲲。","dir":"blog/sofa-jraft-pipeline-principle/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c88030d7b6620240943e8326565b0ec2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-pipeline-principle/","publishdate":"2019-08-06T16:30:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-jraft-pipeline-principle/","summary":"SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-pipeline-principle/","wordcount":3903},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@屈冉 提问：\n SOFAJRaft 目前支持 Multi-Raft 嘛?\n A：支持的，可以参考 rheakv 实现，就是用的 multi raft group。\n 好的，另外想问一下，SOFAJRaft 有没有和 Braft 的性能比较数据，或者同类实现的？\n A：这里有一份 Benchmark 数据可以参考一下，我们暂时没有计划和同类实现对比性能：\nhttps://github.com/sofastack/sofa-jraft/wiki/Benchmark-%E6%95%B0%E6%8D%AE\nSOFA 开源系列 SoloPi：支付宝 Android 专项测试工具 | 开源 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源 蚂蚁金服分布式事务开源以及实践 | SOFA 开源 蚂蚁金服开源自动化测试框架 SOFAACTS 蚂蚁金服开源 SOFAJRaft：生产级 Java Raft 算法库 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFATracer 2.4.1\u0026amp;frasl;3.0.6, 主要变更如下：\ni. 升级 Dubbo 版本至 2.7.3.\nii. 修复 Dubbo 插件中相关埋点参数获取问题\niii. 修复 Datasource 埋点中的若干问题\niv. Cheery pick 代码优化至 3.x 分支\n详细发布报告：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v2.4.1\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.0.6\n2、发布 SOFA MOSN v0.6.0，主要变更如下：\ni. Listener 支持配置空闲连接超时关闭\nii. 日志新增 Alertf 接口\niii. 支持 SDS 方式获取证书\niv. Metrics统计与输出优化\nv. IO 协程优化\nvi. 后端模块实现重构，提升了动态更新性能，降低了内存的使用\nvii. racer 模块实现重构，支持更完善的扩展机制\n详细发布报告：\nhttps://github.com/sofastack/sofa-mosn/releases/tag/0.6.0\nSOFA 活动推荐 SOFA Meetup #3 广州站《从开源技术到产品能力》报名进行中~\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 SoloPi 的首秀分享~\n8 月 11 日，我们广州见~\n报名方式：点击“这里”即可报名。\n","date":1564732800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190802/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4edd066a5855f1a118fd562cfc299571","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190802/","publishdate":"2019-08-02T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190802/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【7/29- 8/2】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190802/","wordcount":818},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n本周推荐阅读 大公司开源怎么做？SOFAStack 给出了一个很好的例子 对话鲁直：蚂蚁金服中间件的开源头羊 | 穿山甲专访 SOFAJRaftLab 系列阅读 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 活动推荐  SOFA Meetup #3 广州站《从开源技术到产品能力》报名开始啦~\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 Soloπ 的首秀分享~\n8 月 11 日，我们广州见~\n报名方式：点击“这里”了解活动详情。\n","date":1564124400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190726/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"70e3dace7979772fdf90f9f5a47d2e13","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190726/","publishdate":"2019-07-26T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190726/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"（含活动报名）SOFA Weekly | 每周精选【7/22 - 7/26】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190726/","wordcount":485},{"author":"潘潘","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#3 广州站-从开源技术到产品能力 活动时间：8 月 11 日周日下午 13 点 活动地点：广州市广电平云 B 塔 15F 活动形式：线下活动 报名方式：https://tech.antfin.com/community/activities/779 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n欢迎 Star 我：https://github.com/sofastack\nSOFA Meetup#3 广州站-从开源技术到产品能力 适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 Soloπ 的首秀分享~\n随着应用架构往云原生的方向发展，传统监控手段已经不能满足云原生时代运维的需求，因此，可观察性的理念被引入了 IT 领域。如何通过可观察性的理念，对微服务，Service Mesh 以至未来的 Serverless 架构的应用进行监控， 将是应用架构往云原生迁移过程中的一个重要命题。\n加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n点击即可报名 https://tech.antfin.com/community/activities/779\n议程 时间 环节 分享大纲 分享嘉宾 13:00-13:30 签到 13:30-14:15 《RPC 服务框架 SOFARPC 在蚂蚁金服的发展与进化》 - SOFARPC 在蚂蚁金服的应用现状\n- 协议和通信层的变化与设计\n- 跨机房与弹性的挑战\n- RPC 框架发展中的经验与教训\n- 拥抱开源，SOFARPC 的未来\n 碧远@SOFARPC 开源负责人 14:15-15:00 《蚂蚁金服在云原生架构下的可观察性的探索和实践》 \n- 为什么云原生时代需要可观察性\n- 可观察性的三大支柱\n- 现在社区方案的缺陷\n- 蚂蚁金服对云原生的可观察性的理解及实践\n 苟利@蚂蚁金服中间件团队产品专家 15:00-15:10 茶歇 15:10-15:55 《分布式事务 Seata 三种模式详解》 \n- 分布式事务产生的背景\n- 分布式事务理论基础\n- 蚂蚁金服分布式事务实践\n- 开源分布式事务 Seata 简介(AT，TCC，SAGA)\n 屹远@Seata 核心贡献者 15:55-16:40 《无线自动化测试框架 Soloπ 的跨平台实践》 \n- 移动端自动化测试转向轻量化\n- “Android+iOS”双端核心功能介绍\n- “Android+iOS”双端功能打通介绍\n- 结合云测平台、用例管理、IDE 的自动化测试解决方案\n 茅舍@Soloπ 核心作者\n不溯@Soloπ 核心作者 ","date":1564038000,"description":"SOFA Meetup#3 广州站-从开源技术到产品能力，8 月 11 日周日下午 13 点，广州市广电平云 B 塔 15F 等你。","dir":"activities/sofa-meetup-3/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0e50b11d1a8e52f8cefbac0bb4826ffe","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-3/","publishdate":"2019-07-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofa-meetup-3/","summary":"概要 活动主题：SOFA Meetup#3 广州站-从开源技术到产品能力 活动时间：8 月 11 日周日下午 13 点 活动地点：广州市广电平云 B 塔 15F 活动形式：线下活动 报名方式：","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#3 广州站-从开源技术到产品能力","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-3/","wordcount":1067},{"author":"袖扣","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第五篇，本篇作者袖扣，来自蚂蚁金服。\n《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：\u0026amp;lt;SOFA:JRaftLab/\u0026amp;gt;，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/alipay/sofa-jraft\n前言 RheaKV 是首个以 JRaft 为基础实现的一个原生支持分布式的嵌入式键值（key、value）数据库，现在本文将从 RheaKV 是如何利用 MULTI-RAFT-GROUP 的方式实现 RheaKV 的高性能及容量的可扩展性的，从而进行全面的源码、实例剖析。\nMULTI-RAFT-GROUP 通过对 Raft 协议的描述我们知道：用户在对一组 Raft 系统进行更新操作时必须先经过 Leader，再由 Leader 同步给大多数 Follower。而在实际运用中，一组 Raft 的 Leader 往往存在单点的流量瓶颈，流量高便无法承载，同时每个节点都是全量数据，所以会受到节点的存储限制而导致容量瓶颈，无法扩展。\nMULTI-RAFT-GROUP 正是通过把整个数据从横向做切分，分为多个 Region 来解决磁盘瓶颈，然后每个 Region 都对应有独立的 Leader 和一个或多个 Follower 的 Raft 组进行横向扩展，此时系统便有多个写入的节点，从而分担写入压力，图如下：\n此时磁盘及 I/O 瓶颈解决了，那多个 Raft Group 是如何协作的呢，我们接着往下看。\n选举及复制 RheaKV 主要由 3 个角色组成：PlacementDriver（以下成为 PD） 、Store、Region。由于 RheaKV 支持多组 Raft，所以比单组场景多出一个 PD 角色，用来调度以及收集每个 Store 及 Region 的基础信息。\nPlacementDriver PD 负责整个集群的管理调度、Region ID 生成等。此组件非必须的，如果不使用 PD，设置 PlacementDriverOptions 的 fake 属性为 true 即可。PD 一般通过 Region 的心跳返回信息进行对 Region 调度，Region 处理完后，PD 则会在下一个心跳返回中收到 Region 的变更信息来更新路由及状态表。\nStore 通常一个 Node 负责一个 Store，Store 可以被看作是 Region 的容器，里面存储着多个分片数据。Store 会向 PD 主动上报 StoreHeartbeatRequest 心跳，心跳交由 PD 的 handleStoreHeartbeat 处理，里面包含该 Store 的基本信息，比如，包含多少 Region，有哪些 Region 的 Leader 在该 Store 等。\nRegion Region 是数据存储、搬迁的最小单元，对应的是 Store 里某个实际的数据区间。每个 Region 会有多个副本，每个副本存储在不同的 Store，一起组成一个Raft Group。Region 中的 Leader 会向 PD 主动上报 RegionHeartbeatRequest 心跳，交由 PD 的 handleRegionHeartbeat 处理，而 PD 是通过 Region的Epoch 感知 Region 是否有变化。\nRegionRouteTable 路由表组件 MULTI-RAFT-GROUP 的多 Region 是通过 RegionRouteTable 路由表组件进行管理的，可通过 addOrUpdateRegion、removeRegion 进行添加、更新、移除 Region，也包括 Region 的拆分。目前暂时还未实现 Region 的聚合，后面会考虑实现。\n分区逻辑与算法 Shard “让每组 Raft 负责一部分数据。”\n数据分区或者分片算法通常就是 Range 和 Hash，RheaKV 是通过 Range 进行数据分片的，分成一个个 Raft Group，也称为 Region。这里为何要设计成 Range 呢？原因是 Range 切分是按照对 Key 进行字节排序后再做每段每段切分，像类似 scan 等操作对相近 key 的查询会尽可能集中在某个 Region，这个是 Hash 无法支持的，就算遇到单个 Region 的拆分也会更好处理一些，只用修改部分元数据，不会涉及到大范围的数据挪动。\n当然 Range 也会有一个问题那就是，可能会存在某个 Region 被频繁操作成为热点 Region。不过也有一些优化方案，比如 PD 调度热点 Region 到更空闲的机器上，或者提供 Follower 分担读的压力等。\nRegion 和 RegionEpoch 结构如下：\nclass Region { long id; // region id // Region key range [startKey, endKey) byte[] startKey; // inclusive byte[] endKey; // exclusive RegionEpoch regionEpoch; // region term List\u0026amp;lt;Peer\u0026amp;gt; peers; // all peers in the region } class RegionEpoch { // Conf change version, auto increment when add or remove peer long confVer; // Region version, auto increment when split or merge long version; } class Peer { long id; long storeId; Endpoint endpoint; } Region.id：为 Region 的唯一标识，通过 PD 全局唯一分配。\nRegion.startKey、Region.endKey：这个表示的是 Region 的 key 的区间范围 [startKey, endKey)，特别值得注意的是针对最开始 Region 的 startKey，和最后 Region 的 endKey 都为空。\nRegion.regionEpoch：当 Region 添加和删除 Peer，或者 split 等，此时 regionEpoch 就会发生变化，其中 confVer 会在配置修改后递增，version 则是每次有 split 、merge（还未实现）等操作时递增。 …","date":1563955200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第五篇，本篇作者袖扣，来自蚂蚁金服。","dir":"blog/sofa-jraft-rheaKV-multi-raft-group/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fbebe45fe1ffaa4e8f134c2531cde55c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","publishdate":"2019-07-24T16:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","wordcount":4503},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n社区 Big News NO.1 社区新认证一位 Committer\n@SteNicholas 成为 SOFAJRaft Committer。\n主要贡献\n一、贡献了 SOFAJRaft 源码剖析系列一共三篇文章\n 蚂蚁金服生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 二、贡献了 4 个 feature PR\n Multi-raft-group 的手动集群 Leader 平衡实现 实现了 RheaKV 的 CompareAndPut API 实现了 RheaKV 的 putIfAbsent batch 优化 实现了 RheaKV 的 batch delete API 目前，社区已经认证超过四十位 Committer。 感谢对 SOFAStack 的支持和帮助~\n也欢迎你加入 SOFAStack community，指南：\nhttps://github.com/sofastack/community\nSOFARegistryLab 系列阅读 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼 SOFAChannel 回顾集合 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下\nSOFAActs 1.0.1 版本发布，主要变更如下：\n 插件兼容性问题修复 详细参考 发布报告\n","date":1563519600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190719/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"03bd5ad0ca023620792ed7ee60d4c448","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190719/","publishdate":"2019-07-19T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190719/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【7/15 - 7/19】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190719/","wordcount":776},{"author":"枫晟","categories":"CafeDeployment","content":" 本文简单介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。\n相关直播视频以及 PPT 查看地址\n背景介绍 Kubernetes 原生社区 Deployment 和 StatefulSet 解决了“服务节点版本一致性”的问题，并且通过 Rolling Update 实现了滚动升级，提供了基本的回滚策略。对于高可用建设要求不高的“年轻”业务，是一个不错的选择。\n但是，在金融场景下，要解决的场景复杂得多。因此我们在金融分布式架构-云应用引擎（SOFAStack-CAFE，参见《金融级云原生探索实践系列——开篇》）中提出了 CafeDeployment 的云原生模型，致力于解决以下问题：\n1. IP 不可变\n对于很多运维体系建设较为早期的用户，使用的服务框架、监控、安全策略，大量依赖 IP 作为唯一标识而被广泛使用。迁移到 Kubernetes 最大的改变就是 IP 会飘，而这对于他们来说，无异于运维、服务框架的推倒重来。\n2. 金融体系下的高可用\nDeployment/StatefulSet 无法根据特定属性进行差异化部署。而在以同城双活为建设基础的金融领域，为了强管控 Pod 的部署结构（即保证每个机房/部署单元都有副本运行），若通过原生组件进行部署，我们不得不维护多个几乎一模一样的 Deployment/StatefulSet，来保证 Pod 一定会飘到指定机房/部署单元的 node 上。在规模上到一定程度后，这无疑加大了运维管控的复杂度和成本。\n3. 灵活的部署策略\nDeployment 无法控制发布步长，StatefulSet 虽然可以控制步长，但是每次都需要人工计算最新版本需要的副本数并修改 Partition，在多机房/部署单元的情况下，光想想发布要做的操作都脑袋炸裂。\n在面对以上这些问题的时候，我们思考：能不能有一个类似 Deployment 的东西，不仅可以实现副本保持，并且能协助用户管控应用节点部署结构、做 Beta 验证、分批发布，减少用户干预流程，实现最大限度减少发布风险的目标，做到快速止损，并进行修正干预。这就是我们为什么选择定义了自己的资源——CafeDeployment。\n模型定义 CafeDeployment 主要提供跨部署单元的管理功能，其下管理多个 InPlaceSet。每个 InPlaceSet 对应一个部署单元。部署单元是逻辑概念，他通过 Node 上的 label 来划分集群中的节点，而 InPlaceSet 则通过 NodeAffinity 能力，将其下的 Pod 部署到同一个部署单元的机器上。由此实现 CafeDeployment 跨部署单元的管理。\nCafeDeployment 作为多个部署单元的上层，除了提供副本保持，历史版本维护等基本功能，还提供了跨部署单元的分组扩容，分组发布，Pod 调度等功能。模型定义如下：\napiVersion: apps.cafe.cloud.alipay.com/v1alpha1 kind: CafeDeployment metadata: ...... spec: historyLimit: 20 podSetType: InPlaceSet\t# 目前支持底层PodSet：InPlaceSet，ReplicaSet，StatefulSet replicas: 10 selector: matchLabels: instance: productpage name: bookinfo strategy: batchSize: 4\t# 分组发布时，每组更新的Pod数目 minReadySeconds: 30 needWaitingForConfirm: true\t# 分组发布中，每组结束时是否需要等待确认 upgradeType: Beta\t# 目前支持发布策略：Beta发布，分组发布 pause: false template: ...... volumeClaimTemplates:\t# 用于支持statefulSet serviceName:\t# 用于支持statefulSet topology: autoReschedule: enable: true\t# 是否启动Pod自动重调度 initialDelaySeconds: 10 unitType: Cell\t# 部署单元类型：Cell，Zone，None unitReplicas: CellA: 4\t# 固定某部署单元的Pod数目 values:\t# 部署单元 - CellA - CellB 因为我们将大部分的控制逻辑都抽取到上层 CafeDeployment 中，因此我们重新设计了 InPlaceSet，将它做得足够简单，只关注于“InPlace”相关的功能，即副本保持和原地升级，保持 IP 不变的能力，模型定义如下：\nspec: minReadySeconds: 30 replicas: 6 selector: matchLabels: instance: productpage name: bookinfo deployUnit: CellB strategy: partition: 6\t# 控制发布时更新Pod的进度 template: ...... 功能特性 灵活的分组定义 CafeDeployment 支持跨部署单元的分组扩容，Pod 调度，分组发布。分组策略主要分为两种，Beta 分组和 Batch 分组：\n Batch 分组 即根据 BatchSize 将 Pod 分为多个批次，每批中的 Pod 会同时发布。待用户确认（needWaitingForConfirm=true时）无误时，或当前批次所有 Pod 都 ready 后（needWaitingForConfirm=false 时），则会开始进行下一组的发布。\n在分组暂停时，CafeDeployment 会被打上 Annotation: cafe.sofastack.io/upgrade-confirmed=false，用户可通过将 Annotation 的值改为 true，确认当前分组。\n Beta 分组 相比 Batch 发布，会在第一组发布之前多一步 Beta 分组。此组会在每个部署单元内选择一个 Pod 进行发布，以减小错误配置带来的影响。若用户确认无误，可以确认继续，以进入正常的 Batch 发布流程。\n安全的分组扩容和发布能力 分组扩容 为预防不正确的配置造成大量错误 Pod 同时创建，占用大量资源等意外情况出现，CafeDeployment 支持分组扩容，以降低风险。\n在如下配置时，CafeDeployment 会创建两个 InPlaceSet 实例，并开始分组创建（扩容）Pod。\nspec: ...... replicas: 10\t# 副本数为10 strategy: upgradeType: Beta\t# Beta发布 batchSize: 4\t# 每组Pod数为4 needWaitingForConfirm: true\t# 分组暂停 topology: ...... values:\t# …","date":1563454800,"description":"本文根据 SOFAChannel#7 直播分享整理，介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。","dir":"blog/sofa-channel-7-retrospect/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a1185b6bb7c21fd49c4118950c16a2a9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-7-retrospect/","publishdate":"2019-07-18T21:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-channel-7-retrospect/","summary":"本文简单介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。 相关直播视频以及 PPT 查看地址 背景介绍 Kubernetes 原生社区 Deployment 和 StatefulSet 解决了“服务节点版本一致性”","tags":["CafeDeployment","SOFAChannel"],"title":"自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-7-retrospect/","wordcount":3476},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第二篇，本篇作者尚彧，是 SOFARegistry 开源负责人。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末附共建列表，欢迎领取共建~\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 无论传统的 SOA 还是目前的微服务架构，都离不开分布式的特性，既然服务是分布的就必须解决服务寻址的问题。服务注册中心是这个过程最主要的组件，通过服务注册和服务发现特性收集服务供求关系，解耦服务消费方对服务提供方的服务定位问题。\n服务注册中心的最主要能力是服务注册和服务发现两个过程。服务注册的过程最重要是对服务发布的信息进行存储，服务发现的过程是把服务发布端的所有变化（包括节点变化和服务信息变化）及时准确的通知到订阅方的过程。\n本文详细描述服务注册中心 SOFARegistry 对于服务发现的实现和技术演进过程，主要涉及 SOFARegistry 的服务发现实现模式以及服务数据变化后及时推送到海量客户端感知的优化过程。\n服务发现分类 分布式理论最重要的一个理论是 CAP 原理。关于注册中心的解决方案，根据存储数据一致性维度划分业界有很多实现，比如最有代表性的强一致性 CP 系统 ZooKeeper 和最终一致性 AP 系统 Eureka。SOFARegistry 在数据存储层面采用了类似 Eureka 的最终一致性的过程，但是存储内容上和 Eureka 在每个节点存储相同内容特性不同，采用每个节点上的内容按照一致性 Hash 数据分片来达到数据容量无限水平扩展能力。\n服务端发现和客户端发现 抛开数据存储的一致性，我们从服务发现的实现维度考虑服务注册中心的分类，业界也按照服务地址选择发生主体和负载均衡策略实现主体分为客户端服务发现和服务端服务发现。\n 客户端服务发现：即由客户端负责决定可用的服务实例的\u0026amp;rdquo;位置\u0026amp;rdquo;以及与其相关的负载均衡策略，就是服务发现的地址列表在客户端缓存后由客户端自己根据负载均衡策略进行选址完成最终调用，地址列表定期进行刷新或服务端主动通知变更。最主要的缺点是需要有客户端实现，对于各种异构系统不同语言不同结构的实现必须要进行对应的客户端开发，不够灵活，成本较高。 服务端服务发现：在服务端引入了专门的负载均衡层，将客户端与服务发现相关的逻辑搬离到了负载均衡层来做。客户端所有的请求只会通过负载均衡模块，其并不需要知会微服务实例在哪里，地址是多少。负载均衡模块会查询服务注册中心，并将客户端的请求路由到相关可用的微服务实例上。这样可以解决大量不同实现应用对客户端的依赖，只要对服务端的负载均衡模块发请求就可以了，由负载均衡层获取服务发现的地址列表并最终确定目标地址进行调用。 SOFARegistry 服务发现模式：以客户端服务发现模式为主。这样的模式实现比较直接，因为在同一个公司内部实践面对的绝大多数应用基本上都是同一个语言实现的，客户端实现也只需要确定一套，每个客户端通过业务内嵌依赖方式部署，并且可以根据业务需求进行定制负载均衡策略进行选址调用。当然也会遇到特殊的异构系统，这个随着微服务架构 RPC 调用等通信能力下沉到 Mesh 执行也得到解决，可以在 Mesh 层进行特定的服务注册中心客户端嵌入，选择路由都在这里统一进行，对不同语言实现的系统进行无感知。 服务发现的推、拉模型 服务发现最重要的过程是获取服务发布方地址列表的过程，这个过程可以分为两种实现模式：客户端主动获取的拉模式和服务端主动变更通知的推送模式：\n 拉模式主要是在客户端按照订阅关系发起主动拉取过程。客户端在首次订阅可以进行一次相关服务 ID 的服务列表查询，并拉取到本地缓存，后续通过长轮询定期进行服务端服务 ID 的版本变更检测，如果有新版本变更则及时拉取更新本地缓存达到和服务端一致。这种模式在服务端可以不进行订阅关系的存储，只需要存储和更新服务发布数据。由客户端主动发起的数据获取过程，对于客户端实现较重，需要主动获取和定时轮训，服务端只需要关注服务注册信息的变更和健康情况及时更新内存。这个过程由于存在轮训周期，对于时效性要求不高的情况比较适用。 推模式主要是从服务端发起的主动变更推送。这个模式主要数据压力集中在服务端，对于服务注册数据的变更和提供方，节点每一次变更情况都需要及时准确的推送到客户端，更新客户端缓存。这个数据推送量较大，在数据发布频繁变更的过程，对于大量订阅方的大量数据推送频繁执行，数据压力巨大，但是数据变更信息及时，对于每次变更都准确反映到客户端。 SOFARegistry 服务发现模式采用的是推拉结合方式。客户端订阅信息发布到服务端时可以进行一次地址列表查询，获取到全量数据，并且把对应的服务 ID 版本信息存储在 Session 回话层，后续如果服务端发布数据变更，通过服务 ID 版本变更通知回话层 Session，Session 因为存储客户端订阅关系，了解哪些客户端需要这个服务信息，再根据版本号大小决定是否需要推送给这个版本较旧的订阅者，客户端也通过版本比较确定是否更新本次推送的结果覆盖内存。此外，为了避免某次变更通知获取失败，定期还会进行版本号差异比较，定期去拉取版本低的订阅者所需的数据进行推送保证数据最终一致。 SOFARegistry 服务发现模式 数据分层 前面的文章介绍过 SOFARegistry 内部进行了数据分层，在服务注册中心的服务端因为每个存储节点对应的客户端的链接数据量有限，必须进行特殊的一层划分用于专门收敛无限扩充的客户端连接，然后在透传相应的请求到存储层，这一层是一个无数据状态的代理层，我们称之为 Session 层。\n此外，Session 还承载了服务数据的订阅关系，因为 SOFARegistry 的服务发现需要较高的时效性，对外表现为主动推送变更到客户端，所以推送的主体实现也集中在 Session 层，内部的推拉结合主要是通过 Data 存储层的数据版本变更推送到所有 Session 节点，各个 Session 节点根据存储的订阅关系和首次订阅获取的数据版本信息进行比对，最终确定推送给那些服务消费方客户端。\n触发服务推送的场景 直观上服务推送既然是主动的，必然发生在主动获取服务时刻和服务提供方变更时刻：\n 主动获取：服务订阅信息注册到服务端时，需要查询所有的服务提供方地址，并且需要将查询结果推送到客户端。这个主动查询并且拉取的过程，推送端是一个固定的客户端订阅方，不涉及服务 ID 版本信息判定，直接获取列表进 …","date":1563433200,"description":"本文为《剖析 | SOFARegistry 框架》第二篇，本篇作者尚彧，来自蚂蚁金服。","dir":"blog/sofa-registry-service-discovery-optimization/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f99d259a0c323df2ddaaea719da2f93c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","publishdate":"2019-07-18T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路","type":"blog","url":"/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","wordcount":5056},{"author":"隐秀","categories":"SOFAStack","content":" \u0026amp;gt; KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。\n市场观察 当我们回顾云计算的发展历程，会看到基础架构经历了从物理机到虚拟机，从虚拟机再到容器的演进过程。在这大势之下，应用架构也在同步演进，从单体过渡到多层，再到当下的微服务。在变化的背后，有一股持续的动力，它来自于三个不变的追求：提高资源利用率，优化开发运维体验，以及更好地支持业务发展。\n目前， Serverless 已成为云原生社区关注的重点之一，它的发展也不例外。相比容器技术，Serverless 可以将资源管理的粒度更加细化，使开发者更快上手云原生，并且倡导事件驱动模型支持业务发展。从而帮助用户解决了资源管理复杂、低频业务资源占用等问题；实现面向资源使用，以取代面向资源分配的模式。根据 CNCF 在2018年底基于 2400 人的一份统计报告，已有 38% 的组织正在使用 Serverless 技术，相比 2017 同期增长了 22%。(数据来源：CNCF Survey)\n\u0026amp;gt; 图片来源：Gartner Report: China Summary Translation Evolution of Server Computing - VMs to Containers to Serverless - Which to Use When\n目前市场上，云厂商提供了多种 Serverless 产品和解决方案，大致可划分为：\n 函数计算服务：如 AWS Lambda，特点是以代码片段为单位运行，并对代码风格有一定要求。 面向应用的 Serverless 服务：如 Knative，特点是基于容器服务，并提供了从代码包到镜像的构建能力。 容器托管服务：如 AWS Fargate，特点是以容器镜像为单元运行，但用户仍需感知容器。 从社区来看，CNCF 云原生基金会正通过 Serverless 工作组协调社区讨论并促进规范和标准的形成，工作组产出了 Serverless 白皮书和全景图等重要内容。其中，全景图将目前的生态划分为了平台层，框架层，工具链层和安全层这四个模块。\n\u0026amp;gt; 图片来源：https://landscape.cncf.io/\n落地挑战 在交流过程中，我们发现 Serverless 很好地解决了客户的一些诉求：包括通过 0-1-0 的伸缩能力来提高资源时用率，降低成本；支持代码包出发，从而让客户无感化实现云原生，历史应用无需经过容器化改造；支持灵活的触发器配置，引导用户对应用进行事件驱动的改造，从而适应业务的高速发展等。这些优势，使得 Serverless 在小程序开发的场景下大放异彩。\n同时，对于在企业级应用的生产环境落地 Serverless，各方也有了很多探索和突破。在本周刚结束的 KubeCon China 2019 大会上，Serverless 工作组会议也以此为话题展开了讨论。目前的核心挑战可归纳为：\n平台可迁移\n目前众多平台都推出了自己的 Serverless 标准，包括代码格式、框架和运维工具等，用户既面临较高的学习成本和选择压力，也担心无法在平台之间灵活迁移 Serverless 应用。\n0-M-N 性能\n线上应用对控制请求延迟有严格的要求，因此，用户需要谨慎地验证 Serverless 0-1 冷启动速度、M-N 扩容速度以及稳定性都达到了生产要求。\n调试和监控\n用户对底层资源无感知，只能借助平台能力对应用进行调试和监控，用户需要平台提供强大的日志功能进行排错，和多维度的监控功能时刻了解应用状态。\n事件源集成\n采用 Serverless 架构后，应用往往进行更细粒度的拆分，并通过事件串联。因此用户希望平台能集成大多数通用的事件源，并支持自定义事件，使得触发机制更加灵活。\n工作流支持\n完成某个业务，往往涉及多个 Serverless 应用之间的配合，当数目较多时，用户希望可以用工作流工具来进行统一编排和状态查看，提高效率。\n蚂蚁金服实践 SOFAStack 致力于通过产品技术解决云上客户实际痛点，沉淀蚂蚁金服技术实践，帮助用户以高效、低成本的方式迁移到云原生架构。Serverless 应用服务（Serverless Application Service，简称 SOFA SAS）是一款源自蚂蚁金服实践的一站式 Serverless 平台。SAS 基于 SOFAStack CAFE 云应用引擎 （Cloud Application Fabric Engine 简称 CAFE），CAFE 的容器服务已经通过了 CNCF 的一致性认证，是一个标准的 Kubernetes。\nServerless 应用服务产品在兼容标准 Knative 同时，融入了源自蚂蚁金服实践的应用全生命周期管理能力，提供了 Serverless 引擎管理、应用与服务管理、版本管理与流控、根据业务请求或事件触发较快的 0-M-N-0 自动伸缩、计量、日志及监控等配套能力。同时结合金融云上客户实际痛点，产品独居匠心的提供独占版与共享版两种形态，以及传统代码包、容器镜像与纯函数三种研发模式，以解决用户的不同需求，降低客户准入门槛。\n 一键部署：用户可以通过代码包或容器镜像的方式一键部署应用并在任意时刻测试执行。 引擎管理：SAS 提供了丰富的引擎全生命周期管理、诊断、监测等能力，为独占版客户赋能 Serverless 引擎数据面的全方位管理与运维运营能力。 服务及版本：SAS 提供应用管理、应用服务管理以及版本管理。版本可以采用容器镜像方式部署也可以采用传统VM发布模式下的代码包部署，很多情况下用户代码无需修改也无需编写维护 Dockerfile 即可迁移。 0-M-N：SAS 提供 0-M-N-M-0 的 Serverelss 快速伸缩能力，支持事件触发或流量触发的 0-M，多种指标的 M-N（如 QPS、CPU、MEM 等等） 日志监控计量：产品内置了日志、监控、计量等配套设施能力，帮助用户进行调试和应用状态监控。 流量控制：基于 SOFAMesh，SAS提供基本流控能力，后续会与服务网格进一步深度集成提供大规模多维跨地域及混合云的流控能力。 触发器管理：产品支持基于常见周期以及秒级精度的cron表达式触发器，可关联并触发无服务器应用，后续将支持更多 IaaS、PaaS 管控型与数据型事件。 性能简析：横轴为完全在同一时刻触发冷启的Java应用个数，纵轴为冷启应用的平均与最小耗时。随着压力增大，50个Java应用同一时刻调度加冷启平均耗时2.5秒左右，100个Java应用同一时刻调度冷启平均耗时3-4秒，最短耗时1.5到2秒。\n 性能简析：Pooling 快弹慢缩时序算法，池容量和实际单位时间申请量关系可做到如图所示（蓝色为实际申请量，绿色为池容量）\n 目前产品已顺利支撑生产环境小程序 Serverless 模式。同时通过 0-M-N-M-0 的能力在很大程度上降低了小程序的运营成本。在行业客户领域，某保险公司决定近期迁移部分日结前置和长尾应用到 Serverless 产品平台，这也是我们产品又一个重要突破。未来， …","date":1562828400,"description":"KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。","dir":"blog/serverless-market-challenge/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e2a95cbe3e0343e3908f17bea5a55d70","permalink":"https://sofastack.github.io/sofastack.tech/blog/serverless-market-challenge/","publishdate":"2019-07-11T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/serverless-market-challenge/","summary":"\u0026gt; KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。 市场观察 当我们回顾云计算的发展历程，会看到基础架构经历了从物理机到","tags":["SOFAStack","Serverless"],"title":"Serverless 市场观察和落地挑战","type":"blog","url":"/sofastack.tech/blog/serverless-market-challenge/","wordcount":2537},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，ServiceMesh，Serverless，安全容器等方向，并发挥自己的力量。SOFAStack 作为蚂蚁金服重要的开源项目，最近也与 CNCF 有故事发生。\n 近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nCNCF \u0026amp;amp; CNCF Cloud Native Landscape CNCF(Cloud Native Computing Foundation)，是由 Google 牵头创立的云原生计算开源软件基金会。它致力于云原生(Cloud Native)技术的普及和可持续发展。2016 年 11 月，CNCF 开始维护 Cloud Native Landscape，汇总流行热门的云原生技术与工具，并加以分类，为企业构建云原生体系提供参考，在云生态研发、运维领域具有广泛影响力。\nSOFAStack \u0026amp;amp; CNCF Cloud Native Landscape 蚂蚁金服金融级分布式架构 SOFAStack 中的 3 个项目加入这次最新版本的 Cloud Native Landscape ，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 **SOFATracer ** 和 RPC 服务框架 SOFARPC。\nSOFAMosn Star 一下✨： https://github.com/sofastack/sofa-mosn\nSOFAMosn(Modular Observable Smart Network)，是一款采用 GoLang 开发的 Service Mesh 数据平面代理， 功能和定位类似 Envoy ，旨在提供分布式，模块化，可观察，智能化的代理能力。 SOFAMosn 支持 Envoy 和 Istio 的 API，可以和 Istio 集成，在 SOFAMesh 中，我们使用 SOFAMosn 替代 Envoy。 SOFAMosn 初始版本由蚂蚁金服和阿里大文娱 UC 事业部携手贡献，期待社区一起来参与后续开发，共建一个开源精品项目。\nSOFARPC Star 一下✨： https://github.com/sofastack/sofa-rpc\nSOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有业务相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括Bolt， RESTful ， Dubbo ， H2C 协议进行通信。其中 Bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\nSOFATracer Star 一下✨： https://github.com/sofastack/sofa-tracer\nSOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFAStack 开源家族 SOFAStack™（Scalable Open Financial Architecture Stack）是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n图为 SOFAStack 开源全景图，其中橙色部分为 SOFAStack 包含的开源组件，白色部分为兼容或集成开源社区其它优秀的开源产品\n特别感谢 SOFAStack 开源社区的每一个你 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。 到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期认证了两位社区 Committer，再次感谢开发者和企业的信任和认可，因为你们，SOFAStack 社区才能会更好。\n","date":1562749200,"description":"Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC 加入 CNCF 云原生全景图","dir":"blog/sofastack-projects-joined-cncf-landscape/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"219e8daac9b49b95c7d5afd94d9ee791","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","publishdate":"2019-07-10T17:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","summary":"2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kuberne","tags":["SOFAStack","CNCF","开源"],"title":"蚂蚁金服 3 个项目进入 CNCF 云原生全景图 | 开源","type":"blog","url":"/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","wordcount":1278},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第四篇，本篇作者力鲲，来自蚂蚁金服。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 在 Raft 算法中，选举是很重要的一部分，所谓选举也就是在多个节点中选出一个 Leader 节点，由他来对外提供写服务 （以及默认情况下的读服务）。\n在剖析源码时，对选举机制的理解经常会遇到两极分化的情况，对于了解 Raft 算法基本原理的同学，阅读源码就是品味实现之巧妙的过程，而对初体验的同学，却会陷入丈二和尚的窘境，仿佛坠入云里雾里。\n为了提升文章的可读性，我还是希望花一部分篇幅讲清楚选举机制的基本原理，以便后面集中注意力于代码实现。下面是一段图文比喻，帮助理解的同时也让整篇文章不至于过早陷入细节的讨论。\n问题1：选举要解决什么 一个分布式集群可以看成是由多条战船组成的一支舰队，各船之间通过旗语来保持信息交流。这样的一支舰队中，各船既不会互相完全隔离，但也没法像陆地上那样保持非常密切的联系，天气、海况、船距、船只战损情况导致船舰之间的联系存在但不可靠。\n舰队作为一个统一的作战集群，需要有统一的共识、步调一致的命令，这些都要依赖于旗舰指挥。各舰船要服从于旗舰发出的指令，当旗舰不能继续工作后，需要有别的战舰接替旗舰的角色。\n图1 - 所有船有责任随时准备接替旗舰\n如何在舰队中，选出一艘得到大家认可的旗舰，这就是 SOFAJRaft 中选举要解决的问题。\n问题2：何时可以发起选举 何时可以发起选举？换句话说，触发选举的标准是什么？这个标准必须对所有战舰一致，这样就能够在标准得到满足时，所有舰船公平的参与竞选。在 SOFAJRaft 中，触发标准就是通信超时，当旗舰在规定的一段时间内没有与 Follower 舰船进行通信时，Follower 就可以认为旗舰已经不能正常担任旗舰的职责，则 Follower 可以去尝试接替旗舰的角色。这段通信超时被称为 Election Timeout （简称 ET）， Follower 接替旗舰的尝试也就是发起选举请求。\n图2 - ET 触发其他船竞选旗舰\n问题3：何时真正发起选举 在选举中，只有当舰队中超过一半的船都同意，发起选举的船才能够成为旗舰，否则就只能开始一轮新的选举。所以如果 Follower 采取尽快发起选举的策略，试图尽早为舰队选出可用的旗舰，就可能引发一个潜在的风险：可能多艘船几乎同时发起选举，结果其中任何一支船都没能获得超过半数选票，导致这一轮选举无果，然后失败的 Follower 们再一次几乎同时发起选举，又一次失败，再选举 again，再失败 again ···\n图3 - 同时发起选举，选票被瓜分\n为避免这种情况，我们采用随机的选举触发时间，当 Follower 发现旗舰失联之后，会选择等待一段随机的时间 Random(0, ET) ，如果等待期间没有选出旗舰，则 Follower 再发起选举。\n图4 - 随机等待时间\n问题4：哪些候选者值得选票 SOFAJRaft 的选举中包含了对两个属性的判断：LogIndex 和 Term，这是整个选举算法的核心部分，也是容易让人产生困惑的地方，因此我们做一下解释：\n Term：我们会对舰队中旗舰的历史进行编号，比如舰队的第1任旗舰、第2任旗舰，这个数字我们就用 Term 来表示。由于舰队中同时最多只能有一艘舰船担任旗舰，所以每一个 Term 只归属于一艘舰船，显然 Term 是单调递增的。 LogIndex：每任旗舰在职期间都会发布一些指令（称其为“旗舰令”，类比“总统令”），这些旗舰令当然也是要编号归档的，这个编号我们用 Term 和 LogIndex 两个维度来标识，表示“第 Term 任旗舰发布的第 LogIndex 号旗舰令”。不同于现实中的总统令，我们的旗舰令中的 LogIndex 是一直递增的，不会因为旗舰的更迭而从头开始计算。 图5 - 总统令 Vs 旗舰令，LogIndex 稍有区别\n所有的舰船都尽可能保存了过去从旗舰接收到的旗舰令，所以我们选举的标准就是哪艘船保存了最完整的旗舰令，那他就最有资格接任旗舰。具体来说，参与投票的船 V 不会对下面两种候选者 C 投票：一种是 lastTermC \u0026amp;lt; lastTermV；另一种是 (lastTermV == lastTermC) \u0026amp;amp;\u0026amp;amp; (lastLogIndexV \u0026amp;gt; lastLogIndexC)。\n稍作解释，第一种情况说明候选者 C 最后一次通信过的旗舰已经不是最新的旗舰了，至少比 V 更滞后，所以它所知道的旗舰令也不可能比 V 更完整。第二种情况说明，虽然 C 和 V 都与同一个旗舰有过通信，但是候选者 C 从旗舰处获得的旗舰令不如 V 完整 (lastLogIndexV \u0026amp;gt; lastLogIndexC)，所以 V 不会投票给它。\n图6 - Follower 船 b 拒绝了船 c 而投票给船 a，船 a 旗舰令有一个空白框表示“第 Term 任旗舰”没有发布过任何旗舰令\n问题5：如何避免不够格的候选者“捣乱” 如上一小节所说，SOFAJRaft 将 LogIndex 和 Term 作为选举的评选标准，所以当一艘船发起选举之前，会自增 Term 然后填到选举请求里发给其他船只 （可能是一段很复杂的旗语），表示自己竞选“第 Term + 1 任”旗舰。\n这里要先说明一个机制，它被用来保证各船只的 Term 同步递增：当参与投票的 Follower 船收到这个投票请求后，如果发现自己的 Term 比投票请求里的小，就会自觉更新自己的 Term 向候选者看齐，这样能够很方便的将 Term 递增的信息同步到整个舰队中。\n图7 - Follower 船根据投票请求更新自己的 Term\n但是这种机制也带来一个麻烦，如果一艘船因为自己的原因没有看到旗舰发出的旗语，他就会自以为是的试图竞选成为新的旗舰，虽然不断发起选举且一直未能当选（因为旗舰和其他船都正常通信），但是它却通过自己的投票请求实际抬升了全局的 Term，这在 SOFAJRaft 算法中会迫使旗舰 stepdown （从旗舰的位置上退下来）。\n图8 - 自以为是的捣乱者，迫使旗舰 stepdown\n所以我们需要一种机制阻止这种“捣乱”，这就是预投票 (pre-vote) 环节。候选者在发起投票之前，先发起预投票，如果没有得到半数以上节点的反馈，则候选者就会识趣的放弃参选，也就不会抬升全局的 Term。\n图9 - Pre-vote 预 …","date":1562742000,"description":"本文为《剖析 | SOFAJRaft 实现原理》第四篇，本篇作者力鲲，来自蚂蚁金服","dir":"blog/sofa-jraft-election-mechanism/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e40fefafd980ac2308a3ba6f3fda9cdd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-election-mechanism/","publishdate":"2019-07-10T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-jraft-election-mechanism/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-election-mechanism/","wordcount":3152},{"author":"SOFAStack","categories":"SOFAStack","content":" 本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。\n 2019 年 6 月 25 日，在 KubeCon China 2019，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，Service Mesh，Serverless，安全容器等方向，并发挥自己的力量。\n在本次大会，蚂蚁金服也与数百名云原生爱好者用五个小时搭建了一个云原生的电商平台，具体怎么做？希望本文能提供一些思路。\n近二十年技术发展：从集中式架构到云原生架构 过去的十几年里，技术发生了翻天覆地的变化，先来简单回顾下：在二十一世纪初，大部分企业的应用还处于集中式架构。这个阶段企业开始做一些信息化的建设工作，典型的一些技术例如集群部署（Tomcat 集群、Weblogic 集群）来保证系统的高可用，以及采购 IOE（IBM，Oracle，EMC）等这些商业化的软硬件产品，通过更高的配置、更好的性能等方式来抗住业务的增长。\n慢慢的，随着公司规模的扩大，集中式架构已经不足以再支撑复杂的业务系统，很多企业开始做一些系统拆分的改造，典型的技术例如 SOA 化。当系统拆分后，就不再需要使用之前昂贵的小型机去部署服务，慢慢的虚拟机的部署方式变成了主流。同样的，服务化后数据库和存储也不再必须采用商业化软硬件的解决方案，企业转为一些开源的解决方案，例如把 Oracle 换成了 MySQL。\n系统的拆分虽然可以带来很多好处，例如使业务内聚，系统之间松耦合，方便快速迭代等。但是随之带来的问题也很明显，例如拆分后系统越来越多，系统间的交互也会变得更加复杂，调用链路变长可能引起性能问题，分布式后数据存储等数据一致性也有不少挑战，还有服务化后带来资源分配、隔离等问题。这时候一些虚拟化和容器化的技术开始涌现，典型技术就是 OpenStack 和 Docker，OpenStack 帮助我们解决了 IaaS 层的建设与管理问题，而 Docker 给了我们资源隔离的最佳实践，但这些并没有解决掉运维复杂的一些问题。\n而近几年，新的云原生的一些技术产品和理念开始出现，例如 Kubernetes、Service Mesh、Serverless 等，这些可以解决应用部署、运维复杂的一些实际问题。\n技术发展下的蚂蚁金服 蚂蚁金服从 2007 年开始从集中式架构走向分布式架构。我们把过去十多年的技术演进过程中自主研发的一套金融级分布式架构沉淀成为 SOFAStack™（Scalable Open Financial Architecture Stack）。\n从 2007 年到 2012 年，蚂蚁金服完成所有业务系统的模块化、服务化改造。通过 TCC 模式解决了服务化、数据拆分等带来的数据一致性的问题，通过注册中心解决了服务单点的问题。\n在完成服务化改造后，随着服务集群的增大，系统的伸缩性遇到了瓶颈，另外为了满足金融级的属性，蚂蚁金服对系统可用性、数据一致性提出了更高的要求。蚂蚁金服从 2013 年开始摸索出了一套单元化的思想，并基于此，推出了同城双活、异地多活、弹性调度等能力，保证业务不停机，数据不丢失。\n再之后随着国内互联网金融的崛起、蚂蚁金服的国际化，蚂蚁金服也将自己的能力和技术开放出来，在金融云上以云产品的形式存在，开发者可以基于此快速搭建金融级能力的分布式系统，同时我们也将内部的一些实践开源出来。\n从 2017 年开始，我们注意到云原生的理念正在快速发展，面对云原生带来的机会和改变，蚂蚁金服的策略是积极拥抱云原生。 因为云原生带来的思想和理念刚好可以用来解决蚂蚁金服内部遇到的一些场景和问题。\n例如 Service Mesh 可以解决中间件等基础能力下层的问题，Serverless 可以解决研发效能的问题，可以让业务开发更专注于业务。这些新的技术和理念蚂蚁金服都会在内部探索并在生产落地，最近我们在深圳 GIAC 首次分享了大规模落地的实践总结，蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录。同时，我们也会将这些云原生落地实践开源出来，并和社区一起共同推进和建设金融级的云原生标准。\nSOFAStack 开源版本： 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期也认证了两位社区 Committer，这里想再次感谢开发者和企业的信任和认可，我们将持续优化和扩大开源版图。\n我们看下这张图，这里可以看到 SOFAStack 体系下开源了很多微服务相关的技术组件，例如 SOFABoot、SOFARPC 等，我们也和社区其它优秀的开源产品进行了兼容或者集成，利用这些组件可以快速的搭建出金融级分布式架构系统。开源的源码可以在这张图下面的 Github 地址上找到。本次的 Workshop 我们就会利用到开源的一些技术组件。\nSOFAStack 云产品： 上图是云上 SOFAStack 的架构图，我们可以看到 SOFAStack 商业化对外输出的是完整的解决方案。支撑解决方案的就是本次要体验的分布式中间件和云应用引擎等等能力。除此之外还有完善的研发效能平台服务以及技术风险防控平台。关于这部分内容，在本次下午场会有更详细的介绍和体验。\nLet\u0026amp;rsquo;s get started! 刚聊了这么多，大家是不是想动手试试了呢？本次 Demo 将带领大家综合利用开源版本的 SOFAStack 和云上产品，五小时实现一个在线电商平台。\n下面简单介绍下本次 Workshop 的内容，如下图：\n上午\n 构建基础电商平台（书店） ，并改造为微服务架构； 基于 SOFABoot 动态模块能力实时的电商平台（书店）增加智能推荐的能力； 用分布式事务 Seata 来解决微服务拆分后的分布式事务的问题，保证购买和余额的数据一致性； 下午\n 通过 Serverless 快速上云，利用 SOFA SAS 发布书店到云环境上，根据流量自动扩缩容； 通过 Service Mesh 的方式来实现精度灰度和流控的能力； 这是提到的是在线书店的系统架构图，最上面是部署好的一些基础设施，包括注册中心 SOFARegistry，服务管控台 SOFADashboard，监控度量 SOFALookout 等，我们已经提前准备好了这部分内容。\n下面就是业务的内容。为了方便，我们不再做前后端分类部署，本次大家只需要操作 2 个应用：\n左边是网页系统和库存系统，提供库存操作服务，右边是账务系统，提供余额相关服务，当用户的请求进来时，库存系统需要通过 RPC 调到账务系统。\n另外库存服务和余额服务分别对应的是独立的数据库，这个后面会用分布式事务 Seata 去解决分布式事务的问题。\nSOFAStack Cloud …","date":1562742000,"description":"本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。","dir":"blog/sofastack-cloud-native-workshop-show/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bed45f24a92c60ca5b141952abdc2049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","publishdate":"2019-07-10T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","summary":"本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。 2019 年 6 月 25 日，在 KubeCon China 2019，全球知名开源组织云原生计","tags":["分布式事务","SOFABoot","Service Mesh","开源","Seata"],"title":"五小时构建云原生电商平台 | KubeCon SOFAStack Workshop 详解","type":"blog","url":"/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","wordcount":2648},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 活动时间：7 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 在 6 月 KubeCon 大会期间，蚂蚁金服正式宣布加入了 CNCF 成为黄金会员，同时 SOFAStack-CAFE 云应用引擎产品也通过了 K8S 一致性认证，旨在向广大金融机构提供云原生的可落地路径。\n为满足金融级云原生发布部署、变更管控场景对于可灰度、可监控、可应急的需求，SOFAStack 产品研发团队在 Kubernetes 基础上实现了自定义资源 CAFEDeployment ，它能够通过可靠而灵活的分发、风险控制的部署策略以及高性能的原地升级更新扩展部署能力。它尤其消除了金融服务行业所面临的技术障碍，使用户能够专心发展核心业务。\n与 Kubernetes 原生工作负载对象 Deployment 所提供的简洁轻量的滚动发布相比，CAFEDeployment 旨在满足金融场景对分批发布、多活容灾、原地升级等方面的诉求。\n7 月 18 日周四晚 7 点，将邀请 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人 枫晟 为大家分享《扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进》。\n在此次分享中，将介绍对此 Kubernetes 扩展能力的相关观点主张、产品探索和实际演示。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/737\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 枫晟 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人\n本期分享大纲： Kubernetes Deployment 发展历史与现状 Kubernetes Deployment 在互联网金融云场景下的问题与挑战 CafeDeployment 适配互联网金融发布的工作负载 CafeDeployment 的运行机制 CafeDeployment 功能演示 嘉宾 SOFAGirl 主持人 枫晟 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人 ","date":1562573400,"description":"7 月 18 日周四晚 7 点，线上直播第 7 期。","dir":"activities/sofa-channel-7/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"51c929733c988190de480a3a0dc5e735","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-7/","publishdate":"2019-07-08T16:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-7/","summary":"概要 活动主题：SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 活动时间：7 月 18 日周四晚 7 点 活动形式","tags":["SOFAChannel","CAFEDeployment"],"title":"SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进","type":"activities","url":"/sofastack.tech/activities/sofa-channel-7/","wordcount":813},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，ServiceMesh，Serverless，安全容器等方向，并发挥自己的力量。SOFAStack 作为蚂蚁金服重要的开源项目，最近也与 CNCF 有故事发生。\n 近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nCNCF \u0026amp;amp; CNCF Cloud Native Landscape CNCF(Cloud Native Computing Foundation)，是由 Google 牵头创立的云原生计算开源软件基金会。它致力于云原生(Cloud Native)技术的普及和可持续发展。2016 年 11 月，CNCF 开始维护 Cloud Native Landscape，汇总流行热门的云原生技术与工具，并加以分类，为企业构建云原生体系提供参考，在云生态研发、运维领域具有广泛影响力。\nSOFAStack \u0026amp;amp; CNCF Cloud Native Landscape 蚂蚁金服金融级分布式架构 SOFAStack 中的 3 个项目加入这次最新版本的 Cloud Native Landscape，分别是 Service Mesh 数据平面代理 SOFAMosn 、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nSOFAMosn Star 一下✨：https://github.com/sofastack/sofa-mosn\nSOFAMosn(Modular Observable Smart Network)，是一款采用 GoLang 开发的 Service Mesh 数据平面代理， 功能和定位类似 Envoy ，旨在提供分布式，模块化，可观察，智能化的代理能力。 SOFAMosn 支持 Envoy 和 Istio 的 API，可以和 Istio 集成，在 SOFAMesh 中，我们使用 SOFAMosn 替代 Envoy。 SOFAMosn 初始版本由蚂蚁金服和阿里大文娱 UC 事业部携手贡献，期待社区一起来参与后续开发，共建一个开源精品项目。\nSOFARPC Star 一下✨：https://github.com/sofastack/sofa-rpc\nSOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有业务相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括Bolt， RESTful ， Dubbo ， H2C 协议进行通信。其中 Bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\nSOFATracer Star 一下✨：https://github.com/sofastack/sofa-tracer\nSOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFAStack 开源家族 SOFAStack™（Scalable Open Financial Architecture Stack）是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n图为 SOFAStack 开源全景图，其中橙色部分为 SOFAStack 包含的开源组件，白色部分为兼容或集成开源社区其它优秀的开源产品\n特别感谢 SOFAStack 开源社区的每一个你 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期认证了两位社区 Committer，再次感谢开发者和企业的信任和认可，因为你们，SOFAStack 社区才能会更好。\n文中涉及的相关链接：\n SOFAMosn：https://github.com/sofastack/sofa-mosn SOFARPC：https://github.com/sofastack/sofa-rpc SOFATracer：https://github.com/sofastack/sofa-tracer SOFAMesh：https://github.com/sofastack/sofa-mesh ","date":1562569200,"description":"近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入。","dir":"blog/sofastack-cncf-cloud-native-landscape/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7146cdd7e74b9901a8ac20cb3e80cf6e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","publishdate":"2019-07-08T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","summary":"2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kuberne","tags":["SOFAStack"],"title":"蚂蚁金服 3 个项目进入 CNCF 云原生全景图 | 开源","type":"blog","url":"/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","wordcount":1590},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 7 月 3 日，在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开源技术创新奖（自主研发）。云计算开源产业大会由中国信息通信研究院主办，是中国云计算开源领域最权威和专业的行业盛会。\n本次大会上，中国信息通信研究院还发布了《混合云白皮书（2019年）》，该白皮书梳理了混合云的最新发展现状、关键能力、应用案例和技术发展趋势。基于完全自主研发的 SOFAStack 金融级分布式架构的网商银行三地五中心异地多活部署方案被作为典型应用案例入选其中。\n完全自主研发的金融级分布式架构 SOFAStack SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时任务、限流/熔断框架、动态配置推送、分布式链路追踪、Metrics 监控度量、分布式高可用消息队列、分布式事务框架和分布式数据库代理层等。\n据了解，经过数代架构演进和“双十一”考验的 SOFAStack，已于 2018 年 4 月正式对外开源，仅一年时间，SOFAStack 所有相关的开源代码，累计获得 16,000+ 个 Star，并有 110+ 个代码贡献者参与其中。\nSOFAStack 助力客户数字化转型 作为一套分布式架构的完整的解决方案，SOFAStack 在真实的金融场景里锤炼出不少最佳实践。\n2017 年 10 月，SOFAStack 与南京银行共同打造出“鑫云+”互金开放平台。该平台具备高性能承载、敏捷开发、强数据一致性和容灾能力等特性，从而使得南京银行互金核心系统在贷款交易处理能力、成本控制和对接效率都得到了极大的提升。南京银行与互联网平台合作开展线上业务仅一年时间，业务量就已经达到了过去十年传统线下消费金融业务的总和。南京银行“鑫云+”平台上线后，业务快速增长，贷款交易处理量增长了数倍。\n据介绍，SOFAStack 还帮助中国人保健康打造行业领先的互联网保险云核心业务系统，助力网商银行成为中国第一家将核心系统架构在金融云上的银行。\nSOFAStack 引领开源技术创新 2019 年 6 月 25 日，蚂蚁金服正式成为 CNCF 云原生计算基金会黄金会员，SOFAStack 云应用引擎产品 CAFE 已通过 CNCF 一致性认证，积极拥抱云原生的同时，满足严苛金融业务场景需求、保障金融技术风险。\n蚂蚁金服是金融级云原生的首倡者，主张金融级的云原生容器产品必须拥有稳定性与高可用保障、无限弹性扩展、运行时安全的能力，这些理念也集中体现在蚂蚁金服的金融级分布式开源项目 SOFAStack 里。\n蚂蚁金服一直积极参与开源社区共建。截至目前，蚂蚁金服已经有 400 多个开源项目。除了 SOFAStack 系列，Ant Design、SQLFlow、EggJS、Seata（与阿里巴巴共建）等也成为社区热门。\n蚂蚁金服金融科技产品技术总监杨冰表示：“开源是一种可以使客户和上下游产业共同参与和发展的可行模式，是个共赢的模式。在贡献蚂蚁金服的技术沉淀给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。只有开放才能求同存异，共同发展。”\n","date":1562223600,"description":"在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开源技术创新奖（自主研发）。","dir":"blog/sofastack-2019-oscar/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"21da7fc5e118681336c84d2dc46fe6bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-2019-oscar/","publishdate":"2019-07-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofastack-2019-oscar/","summary":"2019 年 7 月 3 日，在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开","tags":["SOFAStack"],"title":"蚂蚁金服 SOFAStack 荣获云计算开源产业大会尖峰开源技术创新奖","type":"blog","url":"/sofastack.tech/blog/sofastack-2019-oscar/","wordcount":1223},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第三篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 线性一致读是在分布式系统中实现 Java volatile 语义，当客户端向集群发起写操作的请求并且获得成功响应之后，该写操作的结果要对所有后来的读请求可见。实现线性一致读常规手段是走 Raft 协议，将读请求同样按照 Log 处理，通过日志复制和状态机执行获取读结果返回给客户端，SOFAJRaft 采用 ReadIndex 替代走 Raft 状态机的方案。本文将围绕 Raft Log Read，ReadIndex Read 以及 Lease Read 等方面剖析线性一致读原理，阐述 SOFAJRaft 如何使用 ReadIndex 和 Lease Read 实现线性一致读：\n 什么是线性一致读？共识算法只能保证多个节点对某个对象的状态是一致的，以 Raft 为例只能保证不同节点对 Raft Log 达成一致，那么 Log 后面的状态机的一致性呢？ 基于 ReadIndex 和 Lease Read 方式 SOFAJRaft 如何实现高效的线性一致读？ 线性一致读 什么是线性一致读? 所谓线性一致读，一个简单的例子是在 t1 的时刻我们写入了一个值，那么在 t1 之后，我们一定能读到这个值，不可能读到 t1 之前的旧值(想想 Java 中的 volatile 关键字，即线性一致读就是在分布式系统中实现 Java volatile 语义)。简而言之是需要在分布式环境中实现 Java volatile 语义效果，即当 Client 向集群发起写操作的请求并且获得成功响应之后，该写操作的结果要对所有后来的读请求可见。和 volatile 的区别在于 volatile 是实现线程之间的可见，而 SOFAJRaft 需要实现 Server 之间的可见。\n如上图 Client A、B、C、D 均符合线性一致读，其中 D 看起来是 Stale Read，其实并不是，D 请求横跨 3 个阶段，而 Read 可能发生在任意时刻，所以读到 1 或 2 都行。\nRaft Log read 实现线性一致读最常规的办法是走 Raft 协议，将读请求同样按照 Log 处理，通过 Log 复制和状态机执行来获取读结果，然后再把读取的结果返回给 Client。因为 Raft 本来就是一个为了实现分布式环境下线性一致性的算法，所以通过 Raft 非常方便的实现线性 Read，也就是将任何的读请求走一次 Raft Log，等此 Log 提交之后在 apply 的时候从状态机里面读取值，一定能够保证这个读取到的值是满足线性要求的。\n当然，因为每次 Read 都需要走 Raft 流程，Raft Log 存储、复制带来刷盘开销、存储开销、网络开销，走 Raft Log不仅仅有日志落盘的开销，还有日志复制的网络开销，另外还有一堆的 Raft “读日志” 造成的磁盘占用开销，导致 Read 操作性能是非常低效的，所以在读操作很多的场景下对性能影响很大，在读比重很大的系统中是无法被接受的，通常都不会使用。\n在 Raft 里面，节点有三个状态：Leader，Candidate 和 Follower，任何 Raft 的写入操作都必须经过 Leader，只有 Leader 将对应的 Raft Log 复制到 Majority 的节点上面认为此次写入是成功的。所以如果当前 Leader 能确定一定是 Leader，那么能够直接在此 Leader 上面读取数据，因为对于 Leader 来说，如果确认一个 Log 已经提交到大多数节点，在 t1 的时候 apply 写入到状态机，那么在 t1 后的 Read 就一定能读取到这个新写入的数据。\n那么如何确认 Leader 在处理这次 Read 的时候一定是 Leader 呢？在 Raft 论文里面，提到两种方法：\n ReadIndex Read Lease Read ReadIndex Read 第一种是 ReadIndex Read，当 Leader 需要处理 Read 请求时，Leader 与过半机器交换心跳信息确定自己仍然是 Leader 后可提供线性一致读：\n Leader 将自己当前 Log 的 commitIndex 记录到一个 Local 变量 ReadIndex 里面； 接着向 Followers 节点发起一轮 Heartbeat，如果半数以上节点返回对应的 Heartbeat Response，那么 Leader就能够确定现在自己仍然是 Leader； Leader 等待自己的 StateMachine 状态机执行，至少应用到 ReadIndex 记录的 Log，直到 applyIndex 超过 ReadIndex，这样就能够安全提供 Linearizable Read，也不必管读的时刻是否 Leader 已飘走； Leader 执行 Read 请求，将结果返回给 Client。 使用 ReadIndex Read 提供 Follower Read 的功能，很容易在 Followers 节点上面提供线性一致读，Follower 收到 Read 请求之后：\n Follower 节点向 Leader 请求最新的 ReadIndex； Leader 仍然走一遍之前的流程，执行上面前 3 步的过程(确定自己真的是 Leader)，并且返回 ReadIndex 给 Follower； Follower 等待当前的状态机的 applyIndex 超过 ReadIndex； Follower 执行 Read 请求，将结果返回给 Client。 不同于通过 Raft Log 的 Read，ReadIndex Read 使用 Heartbeat 方式来让 Leader 确认自己是 Leader，省去 Raft Log 流程。相比较于走 Raft Log 方式，ReadIndex Read 省去磁盘的开销，能够大幅度提升吞吐量。虽然仍然会有网络开销，但是 Heartbeat 本来就很小，所以性能还是非常好的。\nLease Read 虽然 ReadIndex Read 比原来的 Raft Log Read 快很多，但毕竟还是存在 Heartbeat 网络开销，所以考虑做更进一步的优化。Raft 论文里面提及一种通过 Clock + Heartbeat 的 Lease Read  …","date":1562050800,"description":"本文为《剖析 | SOFAJRaft 实现原理》第三篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-jraft-linear-consistent-read-implementation/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cfa43268e0ca8424ff44bd4397f720b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","publishdate":"2019-07-02T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","wordcount":4732},{"author":"绍辉","categories":"Seata","content":" 获取本次分享完整 PPT：下载地址\n本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。详细讲解了在分布式架构演进中，蚂蚁金服面对的跨服务、跨数据库的业务数据一致性问题以及应对措施，并分享了分布式事务 Seata 的 AT、TCC、Saga 和 XA 四种模式。\nSeata：https://github.com/seata/seata\n一、自研分布式事务解决数据一致性问题 1.1 分布式事务问题产生原因 1.1.1 数据库的水平拆分 蚂蚁金服的业务数据库起初是单库单表，但随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。所以我们对数据库进行了水平拆分，将原单库单表拆分成数据库分片。\n如下图所示，分库分表之后，原来在一个数据库上就能完成的写操作，可能就会跨多个数据库，这就产生了跨数据库事务问题。\n1.1.2 业务服务化拆分 在业务发展初期，“一块大饼”的单业务系统架构，能满足基本的业务需求。但是随着业务的快速发展，系统的访问量和业务复杂程度都在快速增长，单系统架构逐渐成为业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。\n如下图所示，蚂蚁金服按照面向服务（SOA）的架构的设计原则，将单业务系统拆分成多个业务系统，降低了各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。\n业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，如何保证多个服务间的数据一致性成为一个难题。\n1.2 蚂蚁金服遇到的数据一致性问题 在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。在分布式网络环境下，我们无法保障所有服务、数据库都百分百可用，一定会出现部分服务、数据库执行成功，另一部分执行失败的问题。\n当出现部分业务操作成功、部分业务操作失败时，业务数据就会出现不一致。以金融业务中比较常见的“转账”场景为例：\n如下图所示，在支付宝的“转账”操作中，要分别完成 4 个动作：\n 创建交易订单； 创建支付订单； A 账户扣钱； B 账户加钱； 而完成以上操作要分别访问 3 个服务和 4 个数据库。\n在分布式环境下，肯定会出现部分操作成功、部分操作失败的问题，比如：A 账户的钱扣了，但是 B 账户的钱没加上，这就造成了资金损失，影响资金安全。\n在金融业务场景下，我们必须保证“转账”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象。\n为了解决跨数据库、跨服务的业务数据一致性问题，蚂蚁金服自主研发了分布式事务中间件。\n从 2007 年开始做分布式事务并支持双十一，至今已经有 12 年。\n2013 年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014 年，蚂蚁金服分布式事务中间件 DTX(Distributed Transaction-eXtended)开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户。在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。所以在 2015 年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务（Distributed Transaction-eXtended，简称 DTX）链接：\nhttps://tech.antfin.com/products/DTX\n二、投入开源社区，共建开源分布式事务 Seata  2.1 分布式事务 Seata 介绍 Seata（Simple Extensible Autonomous Transaction Architecture，简单可扩展自治事务框架）是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。Seata 开源半年左右，目前已经有接近一万 star，社区非常活跃。我们热忱欢迎大家参与到 Seata 社区建设中，一同将 Seata 打造成开源分布式事务标杆产品。\nSeata：https://github.com/seata/seata\n2.2 分布式事务 Seata 产品模块 如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。\n在 Seata 中，分布式事务的执行流程：\n TM 开启分布式事务（TM 向 TC 注册全局事务记录）； 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）； TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）； TC 汇总事务信息，决定分布式事务是提交还是回滚； TC 通知所有 RM 提交/回滚 资源，事务二阶段结束。 2.3 分布式事务 Seata 解决方案 Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。\n2.3.1 AT 模式 今年 1 月份，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。\nAT 模式如何做到对业务的无侵入 ： 一阶段： 在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。\n 二阶段提交： 二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。\n 二阶段回滚： 二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。\nAT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。\n2.3.2 TCC 模式 2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段 执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。\nTCC 三个方法描述：\n Try： …","date":1562050800,"description":"本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。","dir":"blog/seata-distributed-transaction-deep-dive/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d87c4d85b8c16bfc24a0b9bea52b604d","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","publishdate":"2019-07-02T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","summary":"获取本次分享完整 PPT：下载地址 本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。详细讲解了","tags":["分布式事务","实践","开源","Seata"],"title":"Seata 分布式事务实践和开源详解 | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","wordcount":5775},{"author":"响风","categories":"SOFALookout","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23195297，不错过每场直播。\n 大家好，我是响风，来自蚂蚁金服， 现在是 SOFALookout 的开源负责人。本期 SOFAChannel 我给大家带来主题是《轻量级监控分析系统 SOFALookout 原理讲解和功能演示》的分享。本期的讲解内容如下将从以下四个部分展开：\n 监控预警基本概念介绍 SOFALookout 的客户端使用（包括系统设计简介与实现） SOFALookout 的服务端使用（包括系统设计简介与实现） SOFALookout 发展规划 欢迎大家 Star 我，SOFALookout：https://github.com/sofastack/sofa-lookout\n1 监控预警基本概念介绍 1.1 什么是 SOFALookout 现在我们开始第一部分，先介绍一些基本概念。6 月初，SOFALookout 服务端开源，具体内容可以查看相关文章：蚂蚁金服轻量级监控分析系统 SOFALookout 服务端开源，SOFALookout 客户端在之前也已经开源。目前整个系统是真正地可以玩转起来的，这里先介绍一下 SOFALookout。\nSOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。开源版本只提供对 Metrics 的处理部分：涵盖 Metrics 数据的产生，也就是 Metrics 的埋点、收集、加工、存储与查询等一系列服务。\n1.2 Metrics 的前置知识 介绍一些 Metrics 的前置知识：\n第一是时序数据，比较正式的解释是“基于稳定频率持续产生的一系列指标监测数据”。简单说横轴是时间，纵轴是数值的情况下，第一印象可以做成走势图的数据通常就是时序数据。比如 2009 年到 2018 年每年双十一天猫的成交额，就构成了时序数据。\n第二是标签（Tag），它用于表明指标项监测针对的具体对象。还是以刚才的成交额为例子，其实我们要监测的指标是“成交额”，但是“成交额”并没有标明要监测的对象，即谁的成交额，哪个省的成交额，也就是缺少“定语”。标签的作用就相当于是“定语”。比如“天猫的 浙江省的 成交额”，在代码中通常会有键值对来描述，比如 type=\u0026amp;ldquo;天猫\u0026amp;rdquo;，province=\u0026amp;ldquo;浙江\u0026amp;rdquo;。\n第三是时序数据库，即专门为存查时序数据而设计的数据管理系统。主要有以下几个特点：\n 写多读少 数据多维度，无 schema，需要多维度查询或聚合 通常无删除和更新操作， 或受限 以下是一些常见的开源时序数据库，由于篇幅关系，就不一一介绍了。\n Graphite InfluxDB OpenTSDB Prometheus 1.3 传统 Metrics 和 Metrics 2.0 的对比 下面再来看一下传统 Metrics 和 Metrics 2.0 的对比。\n1.3.1 传统 Metrics 传统 Metrics 是我对它的称呼，简单来说它只有 Name 和 Value，没有显式的 Tags 概念。比如 \u0026amp;ldquo;temperature = 29\u0026amp;rdquo;，温度=29，当然这里都省略了时间戳。这个表达式并没有指出监测对象，传统 Metrics 的做法是，将监测对象的信息编码到 Name 里，因此可能就变成了 \u0026amp;ldquo;temperature.hangzhou=29\u0026amp;rdquo;。这里是有一些隐式的 Tags 信息的，只是被编码到 Name 里了。\n这种做法很快会导致一个问题，我们来看下一个例子： shanghai.host1.foo.exporter.bar 。 只看这个名字的话几乎很难知道这个 Metrics 统计的是什么。这是因为它并没有把字段对应的 Key 编码到名字里，所以在缺少一些上下文的情况下，我们很难读懂它的含义。\n另外，字段的顺序也是很重要的，不能写错，这是因为编码到 Name 里的只有 Tag 的 Value，Key 不在里面，于是又有了另外一种编码方式：zone.shanghai.host.host1.app.foo.counters.exporter.bar 。这种方式将 Tag 的 Key 也编码在Name 里。但带来的问题也很明显：Name 越来越长。\n我们再看下一个例子： login.success.h5，它想表达来自 H5 平台登录成功的次数。假设我们还有其他平台，比如安卓、IOS，我们想求所有平台的总登录成功次数，那么就需要做一个聚合操作。通常时序数据库会提供型号来匹配所有值。\n其实上面这些都是旧版本 Graphite 的例子, 不过它在 2017 年底的版本支持了 Tags 概念，所以已经不能拿新版来当反面教材了。\n这是 Dropwizard 客户端的一个简单 Demo，它是一个很流行的 Metrics 埋点客户端，但是只能支持传统 Metrics 的概念。\nMetricRegistry registry = new MetricRegistry(); Counter h5Counter = registry.counter(\u0026amp;quot;login.success.h5\u0026amp;quot;); h5Counter.inc(); 1.3.2 Metrics 2.0 我们再来看 Metrics 2.0，其实 Metrics 2.0 也就只是多了 Tags 的概念，这里同样省略了 Timestamp。\n这是 OpenTSDB 风格的数据描述。\n{ \u0026amp;quot;metric\u0026amp;quot;: \u0026amp;quot;login.counter\u0026amp;quot;, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;result\u0026amp;quot;: \u0026amp;quot;success\u0026amp;quot;, \u0026amp;quot;platform\u0026amp;quot;: \u0026amp;quot;h5\u0026amp;quot; }, \u0026amp;quot;timestamp\u0026amp;quot;: 1560597254000, \u0026amp;quot;value\u0026amp;quot;: 100 } 这是 Prometheus 的描述方式。\ntemperature{city=\u0026amp;quot;hangzhou\u0026amp;quot;}=29 这是对应的 lookout-client 的埋点代码。\nRegistry registry = …; Id loginCounter = registry.createId(\u0026amp;quot;login.counter\u0026amp;quot;); Id id = loginCounter.withTags( \u0026amp;quot;result\u0026amp;quot;, \u0026amp;quot;success\u0026amp;quot;, \u0026amp;quot;platform\u0026amp;quot;, \u0026amp;quot;ios\u0026amp;quot; ); registry.counter(reqId).increment(); 可以看到它们都显式支持了 Metrics 2.0 的概念。\n这里我们花了点时间强调传统 Metrics …","date":1561705200,"description":"本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。","dir":"blog/sofa-channel-6-retrospect/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"27fcb53174efd0b72fcee578993cae38","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-6-retrospect/","publishdate":"2019-06-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-channel-6-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。 回顾视频以及 PPT 查","tags":["SOFALookout","SOFAChannel"],"title":"蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-6-retrospect/","wordcount":4165},{"author":"卓与","categories":"SOFAStack","content":" 本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。分享基于 Service Mesh 的理念，结合蚂蚁金服内部实际场景，将中间件、数据层、安全层等能力从应用中剥离出来后下沉至独立的 Sidecar SOFAMosn 中，结合 Kubernetes 运维体系，提供应用无感知的情况下升级基础设施层能力的案例。\n本次分享将从以如下次序展开进行：\n蚂蚁金服当前的服务化现状 在看蚂蚁金服的服务化架构之前我们先从一个简单的服务化调用示例说起，下图是 SOFARPC 基本原理：\n我们从上图可以看出，构建一个服务化框架需要有服务注册中心，有服务定义，调用方和服务提供方使用相同的服务定义来互相通讯。通过服务注册中心，调用方可以直接订阅到服务提供方的地址，采用点对点的方式直接发起请求。客户端内可实现服务发现、路由寻址、负载均衡、限流熔断等能力来增强服务通讯能力。通过我们开源的 SOFARPC、SOFARegistry、SOFABoot，用户已经可以直接构建起微服务体系，助力业务发展。\n蚂蚁金服发展至今，双 11 系统需要应对的交易洪峰逐年递增：\n每秒 26.5 万笔交易是 2017 年双 11 的峰值数据，这个数据背后有非常复杂的架构支持，LDC 单元化架构是蚂蚁金服沉淀多年的核心架构，依靠这个架构实现每年峰值交易量飞速增长下系统依然能平滑渡过。我们来简要看下 LDC 架构：\n上图摘自 金融级分布式架构 中的 素描单元化 一文，这里不详细展开。LDC 的单元化架构给应用的服务化带来更多的规范与抽象，服务路由中需要考虑单元间的调用，跨机房调用等更多场景。这里主要希望表达的是 LDC 架构给 RPC 调用带来更高的复杂度。\n服务化痛点 中间件版本升级 在上面介绍背景时，有介绍到目前 LDC 架构下服务调用的复杂度，这些复杂度目前是直接体现在应用的代码中。对于业务同学来讲，一个应用的关注重点是如何实现业务逻辑，至于高可用、容灾等能力更多是整体架构层面会考虑的点。应用内通过引入 RPC 的 jar 包即可获得 LDC 架构下服务调用各种能力的支撑，带来便利的同时也可以看到这种模式的缺点：\n应用内除业务逻辑之外，由中间件的 SDK 引入大量外部依赖，来完成服务发现、路由寻址、负载均衡、限流熔断、序列化、通讯等能力，每个组件的引入都可能带来稳定性风险，以及更高的升级成本。\n根据目前 SOFARPC 在内部的版本举例，服务发现依赖 SOFARegistry 的客户端做 IDC 内的服务发现，依赖 Antvip 做跨 IDC 的服务发现，ZoneClient 集成 LDC 架构的单元化信息，路由寻址需要根据请求的入参计算目前 Zone 然后确定调用目标，限流熔断依赖 Guardian 组件，通讯协议与序列化协议相对稳定，变更较少。仅为了完成服务调用，应用需要额外引入 7+ 客户端包。\n每年双 11 需要涉及到架构调整时：比如支持弹性架构，需要做很多中间件客户端的版本升级来支撑更优的架构，对于业务同学来讲，这些升级是很耗费精力的，拿 200 个核心应用举例，每个应用升级中间件版本经过研发、测试、再到部署预发、灰度、生产等环境需要 5个人日的话，200 个核心应用中间件升级需要耗费 1000 人日，如果这部分时间可以节省出来，每年架构升级可以节约大量人力资源。\n跨语言通讯 蚂蚁金服发展至今，内部业务百花齐放，搜索推荐、人工智能、安全等各种业务使用到的技术栈非常多样化，跨语言的服务通讯能力也十分重要。早在几年前，Java 之外规模最大的就是 NodeJS 应用，为了让 Java 和 NodeJS 应用之间可以复用蚂蚁金服内部的各种中间件和基础设施，前端团队使用 NodeJS 逐步重写了各种中间件客户端，让整个 NodeJS 和 Java 体系可以完美互通。\n中间件 SDK 跨语言重写与维护成本极高，随着语言种类的增多，跨语言通讯的诉求也越来越多。\nJava, NodeJS, Go, Python, C++ 等，5+ 语言，中间件 SDK 全部重写成本极高。这些问题不得不激励我们寻找更优的解法。\n解决痛点 SDK 能力下沉 依然以上述 RPC SDK 举例，SDK 中的能力我们可以根据稳定性与不可剥离等特性来看，哪些是可以从应用中抽出来的，尽量把 SDK 做薄，做的足够稳定无需变更，那么升级成本将不复存在。\nRPC SDK 中的服务发现、路由寻址、限流熔断等特性，是更易于变更的，我们将这部分能力下沉至独立的 Sidecar 中，可以复用这部分能力，让多语言的 SDK 只实现最基本的序列化与通讯协议，而这些能力是很轻量且易于实现的。这里的 Sidecar 我们是希望它作为独立进程存在，和业务应用的进程剥离，并和业务应用的升级解耦开来，实现业务和基础设施并行发展，互不干扰的愿景。\n除了 RPC 通讯，我们还可以下沉消息、数据源等能力至 Sidecar 中，业务应用可以越来越薄，SDK 实现成本也降低到可接受的程度，基础设施层与业务剥离，双方均可独立演进。\n落地架构 整体架构 不同于开源的 Istio 体系，蚂蚁金服内部版 Service Mesh 落地优先考虑数据面的实现与落地，控制面在逐步建设中，整体的架构上看，我们使用数据面直接和内部的各种中间件服务端对接，来完成 RPC、消息等能力的下沉，给业务应用减负。由上图可以看出，我们将不同的 Sidecar 与业务应用编排在同一个 Pod 中，App 与 Mosn 直接通讯，Mosn 来负责目标接口的服务发现、路由寻址，并且由 Mosn 内置的安全模块来做应用间调用的加密鉴权。通过 DBMesh 的 Sidecar 来实现数据层的下沉，App 不在需要与多个数据源建立连接，只需要连接本 Pod 内的 DBMesh 即可完成数据层调用，数据库的用户名、密码、分库分表规则等均不再需要关心。\n图中名词解析：\nConfigServer：配置中心，负责各种元数据配置、动态开关等。\nRegistry：服务注册中心，负责 IDC 内服务发现。\nAntVip：类 DNS 解析的产品，可通过域名解析一组目标地址，用于跨 IDC 服务发现。\nMQ：消息中心服务端，用于收发消息。\n落地数据 目前这套架构已经在支付核心链路中做试点，618 大促 Mesh 化应用对比无 Mesh 化应用 CPU 损耗增长 1.7%，单笔交易整体耗时增长 5ms。CPU 增长是由于多出一个进程，请求增加一条之后，RT 会有稳定的小幅增长，但这些成本相比于整体架构带来的红利，微乎其微，并且针对整个数据面的持续优化是有望逐步减少资源占用，提升资源利用率。\n降低打扰度 中间件能力下沉在架构上看是可行的，实际落地如何做到无打扰的在奔跑的火车上换轮子，低打扰是一个非常重要的考量点。借助于 Kubernetes 的优秀实践，将业务容器与 Sidecar 容器编排在同一个 Pod 中是比较合理的架构，Sidecar 与业务容器互不干扰，互相升级均可做到双方无感。\n我们为了让业务应用升级尽可能如丝般顺滑，主要做了 …","date":1561359600,"description":"本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。","dir":"blog/service-mesh-giac-2019/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7cfc7c8a7b735c31418186aae0ca99a2","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-giac-2019/","publishdate":"2019-06-24T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/service-mesh-giac-2019/","summary":"本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。","tags":["SOFAStack","Service mesh"],"title":"蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-giac-2019/","wordcount":4572},{"author":"雾渊","categories":"SOFAArk","content":"  本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。感谢溢米教育对 SOFAStack 的支持，同时也欢迎更多用户投稿 Join us。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服开源贡献。\n写在前面 个性化推荐，相信大家都不陌生，简单来说就是根据每个人的偏好经过模型计算推荐出适合的东西，这些东西可以是视频、商品、文章、电影等。经过互联网这几年的发展，个性化推荐已经无处不在，不管是电商、教育、游戏、金融行业，推荐系统对业务的提升都有着非常重要的帮助。溢米教育作为一家互联网教育平台，近几年推荐业务发展非常迅速，技术团队也在持续的进行能力提升。业务快速增长的同时，亟需一个高效率、高稳定的推荐系统来支持推荐场景。\n本文是根据我们内部推荐平台效率与稳定性建设的实际经验整理，介绍了溢米教育推荐系统的改造优化。在整个过程中我们基于公司架构做了分析，确认了技术选型和改造方案，最终选择基于 SOFAStack 社区开源的 SOFAArk 组件开发框架，极大的提升了我们推荐系统的开发效率和稳定性。希望能给有同样困扰的技术团队参考。\n背景 一次完整的个性化推荐，通常包括召回、过滤、排序等步骤。虽然步骤不多，但是涉及到的逻辑是非常多的，包括 abtest、用户画像、物品画像、离线数据、在线数据、模型系统、字段补全等等。个性化推荐极为依赖场景定制化，不同的场景对应不同的处理逻辑。\n我们可以想象，把这一堆处理逻辑都放在一个系统里面，应用会变得十分臃肿和复杂，随着业务系统不断的迭代更新，逐渐会变得难以维护，开发效率和系统稳定性都会面临不小的挑战。不幸的是，随着溢米业务快速发展，内部的推荐平台已经变得 “过劳肥”。不管是迭代效率、性能、稳定性都遇到了瓶颈，比如：\n 发布耗时：算法团队一个人跟进一条业务线，导致业务迭代频繁、应用发布非常频繁，由于系统本身复杂性，这么一个庞然大物发布一次非常慢，降低了工程师效率；\n 系统臃肿：所有模块统一维护，包含了存储、算法、业务等，几乎每次迭代都是只增不减，降低了系统可维护性；\n 覆盖风险：多个团队共同维护一份代码，分支上容易存在冲突，合并代码存在覆盖风险，降低了团队合作效率；\n 版本不一致：不同业务团队使用的 jar 包版本不一致，每次升级一个 jar 包都会引起很多问题，导致各个团队在开发期间都要花费不少精力解决依赖冲突；\n 基于上述背景，溢米推荐平台不得不进行应用瘦身和系统改造，从而提升平台的开发效率和稳定性。然而在实际的改造过程中，我们不难发现这两者其实是互相冲突的。为了提高稳定性，我们肯定要做到流程上的把控，比如测试、灰度、发布等流程的规范，这势必会影响业务迭代效率；反过来如果要提升效率，那么在流程上肯定会有一定的舍弃，随之而来的是稳定性的潜在风险。 但是人总是需要梦想驱动的，每个工程师都希望能用一种架构或者方案，同时解决很多通用的问题，节约成本，提升效率， 让设计人员能够不至于疲于奔命， 解放生产力来完成更多有创新有挑战的工作。\n调研 效率和稳定性并非一定是二选一，在进行推荐平台升级改造之前，我们梳理了溢米内部影响业务效率和系统稳定性的主要因素。\n 开发效率 系统稳定 影响因素 业务复杂度+开发复杂度 业务变更：代码变更+数据变更 业务迭代流程+开发流程 非业务变更：配置变更+代码变更 业务变更+服务变更上线 流量变化 稳定性流程 硬件故障 关于开发效率，从上面可以看出来除了开发部分是依赖平台所能提供的便利和开发者个人技术能力之外，其余大部分都是流程上的把控。这些流程上的把控一是为了保障业务迭代的正确性，二是为了提升业务迭代带来的线上服务稳定性，但是简单的流程不足以把控住这些点，而过度复杂的流程会很大程度上影响业务迭代效率，所以我们需要思考并且寻求一种平衡，比如如何降低业务开发复杂度？如何提升平台提供的便利？如何在不影响稳定性的情况下简化业务迭代和维护流程？\n关于稳定性，我列举几个在溢米内部遇到的几个类似案例：\n 推荐服务性能优化上线，功能性测试没有问题，但是没有经过压测导致高峰期服务能力下降，最终导致整个服务不可用，而上游由于没有做好服务治理也受影响变成了服务不可用； 推荐服务所依赖的某个数据源或者 RPC 响应从 10ms 突然增长到 100ms，从而导致推荐服务主要线程池耗尽，最终导致服务不可用； 上游压测或者流量推广或者爬虫导致流量激增，但是推荐服务没有做好限流导致服务被打垮而不可用； 推荐系统依赖业务系统提供的RPC服务进行过滤，由于此RPC服务变更导致响应变慢，而推荐服务没有区分强弱依赖导致整体服务超时； 某个业务由于排期时间紧张，测试周期太短，上线后导致其它业务异常； 结合这些案例和上文总结的系统稳定性影响因素，可以发现除了硬件故障是不可控之外，其余几点基本都是因为变更而引起的。那么如何不受变更影响而提升稳定性呢？上面我们介绍过最主要也是最有效的是变更流程控制，通过测试、灰度、发布流程规范，其余也可以通过技术手段来控制，比如性能优化、服务治理、业务隔离、强弱依赖区分、多机房容灾、扩容等等。\n针对以上开发效率和稳定性分析，最开始确定如下了改造目标：\n 场景模块化 系统瘦身，拆分模块，提高系统可维护性 模块复用，提升开发效率 模块开发时隔离 各模块单独迭代开发，解决之前统一迭代开发的代码冲突问题 各模块单独测试，提升测试效率 模块运行时隔离 模块运行时类隔离，解决模块间包冲突问题 模块间有明确的服务边界，一定程度的故障隔离 模块动态可插拔 动态升级，秒级发布回滚 改造 为了满足改造目标，我们初步确认了三个选择：\n 采用自定义 SPI 的 ServiceLoader 动态加载实现； 采用自定义 Classloader 实现； 寻求开源软件支持。 基于资源成本、时间成本的考虑，我们选择了寻求开源支持，蚂蚁金服开源其分布式架构吸引了我们的关注，经过技术判断，我们最终决定使用 SOFAStack 社区开源的 SOFAArk 组件开发框架。\nSOFAArk 定义了一套相对简单的类加载模型、特殊的打包格式、统一的编程界面、事件机制、易扩展的插件机制等，从而提供了一套较为规范化的插件化、组件化的开发方案。更多内容可以参考官方文档：\nSOFA JVM 服务： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-ark-jvm\nSOFAArk 官方文档： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-readme\nSOFAArk 源码： https://github.com/sofastack/sofa-ark\n通过 SOFAArk+SOFABoot 的组合，我们将应用进行拆分，分为宿主应用+数据模块+业务模块：\n 主应用：负责整个容器的状态保持； 数据模块：负责数据通信，包括 Redis，DB，RPC 等基础服务； 业务模块：只需要负责调用数据模块进行业务实现， …","date":1560409200,"description":"本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。","dir":"blog/sofastack-user-yimi/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"967e9a815b24a3b000d5ecd90c59b8fb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-user-yimi/","publishdate":"2019-06-13T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofastack-user-yimi/","summary":"本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。感谢溢米教育对 SOFAStack 的支持，同时也欢迎更多用户","tags":["SOFAArk"],"title":"溢米教育推荐平台的效率与稳定性建设 | SOFAStack 用户说","type":"blog","url":"/sofastack.tech/blog/sofastack-user-yimi/","wordcount":3303},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 活动时间：6 月 12 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 6 月 27 日周四晚 7 点，将邀请 蚂蚁金服 SOFALookout 开源负责人 响风 为大家分享，通过对多个模块的剖析，详解 SOFALookout 服务端以及客户端，带你了解 SOFALookout 具体是如何支持主流 Metrics协议的数据收集、存储、查询计算和可视化的。欢迎报名参加~\nSOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务，提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\n本期分享大纲：\n 监控预警基本概念介绍 SOFALookout 客户端使用 Gateway - 多协议数据收集与处理的设计与实现 Server - PromQL 与多种存储层的设计与实现 SOFALookout 发展路线 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/687\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 轻量级监控分析系统 SOFALookout 原理讲解和功能演示 响风 蚂蚁金服轻量级监控分析系统 SOFALookout 开源负责人\n本期分享大纲： 监控预警基本概念介绍 SOFALookout 客户端使用 Gateway - 多协议数据收集与处理的设计与实现 Server - PromQL 与多种存储层的设计与实现 SOFALookout 发展路线 嘉宾 SOFAGirl 主持人 响风 蚂蚁金服轻量级监控分析系统 SOFALookout 开源负责人 ","date":1560312000,"description":"6 月 12 日周四晚 7 点，线上直播第 6 期。","dir":"activities/sofa-channel-6/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"29a5673d4608770bbe7598954fcecc78","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-6/","publishdate":"2019-06-12T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-6/","summary":"概要 活动主题：SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 活动时间：6 月 12 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直","tags":["SOFAChannel","SOFALookout"],"title":"SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示","type":"activities","url":"/sofastack.tech/activities/sofa-channel-6/","wordcount":637},{"author":"卿祤、 首仁","categories":"SOFAStack","content":" 由蚂蚁金服主办的 SOFAStack Cloud Native Workshop 将在 6月24日于 KubeCon + CloudNativeCon + Open Source Summit China 大会的同场活动中进行，欢迎报名参与，更多信息可见此链接。 欢迎加入 SOFA 钉钉互动群（钉钉搜索群号）：23195297\n 楔子 为支撑业务高速发展并积极拥抱主流技术，我们从 2017 年开始探索并构建以Kubernetes为核心的云原生应用 PaaS 平台。在 2018 年，我们已在网商银行顺利落地了 K8S 容器引擎，并顺利支撑了 2018 年双十一。2019 年伊始，国泰产险作为互金行业的典型代表，正基于 SOFAStack 容器应用服务和监控分析产品探索云原生架构转型。时至今日，已完成了关键业务 SOFABoot 应用的容器化改造，在开发、测试乃至灰度生产环境践行云原生的运维实践。\n这将是一系列技术分享文章的开端，基于在实际金融机构和场景中落地的云原生产品项目经验，我们希望和大家一起分享从中获得的洞察和总结，探讨我们的产品观点、技术实现，并非常期待大家的建议和指点，欢迎一起交流共创。\n云原生容器产品的金融机构落地挑战 从去年开始，云原生、Kubernetes、容器这些关键字逐渐从社区走向金融科技圈，越来越多的金融机构客户开始向我们咨询，云原生技术是什么，能够给企业带来什么价值，对现有业务有什么影响？落地的路径可能会是哪些？\n我们的观点是，金融场景下的云原生，绝对不止是 12Factors，亦不止是 CNCF TOC 所定义的 5 大件，我们不仅要提供标准、通过一致性认证的 Kubernetes 产品，还需要满足更多金融场景需求，创造实际业务价值。\n经过很长一段时间的产品研发实践、深挖内外容器平台落地诉求，金融客户的关注点可能包括但不限于以下几点：\n 业务采用了云原生能否节省资源，提升工程效率？ 发现问题后如何做到快速止损，甚至线上零故障？ 如何在云原生下做到业务同城双活甚至异地多活的高可用容灾能力？ 能否和现有业务能无缝集成，如何做平滑升级？ 采用了云原生平台能否保证和现有云上一致的安全性？ 云原生能否支撑大规模分布式系统的架构？ \u0026amp;hellip; 而基于以上实际场景下的落地挑战，我们对自身容器平台产品的设计和实施，提出了以下六大关键价值主张：\n云原生容器产品的价值主张 一 使用 Immutable Infrastructure 的思想进行设计 在 PaaS 平台中，核心是应用。在之前的经典运维体系中，要对应用打一个全量快照不是件容易的事情，但在云原生世界中，会方便许多。从描述流量接入层的 Service 到描述应用配置和代码包的 Pod template，这些已是 kubernetes 的标准 Resources。\n为了解决应用管理需求，我们定义了一个 CafeAppService 对象，用于整体描述上述内容，并通过 Revision 对象属性作版本控制（和 Knative 中的 Revision 类似）。用户每次的修改都是一个 Revision，发布一个应用本质上是发布该应用的一个 Revision，故可做到快速的弹性扩缩容，并且可以方便回滚到之前发布成功过的 Revision。相比之前基于包的经典发布运维体系，效率有极大提升。\n二 可审计和无损应用发布的能力 发布变更是 PaaS 平台提供的重要能力。对于金融客户来说，每次发布必须要有据可查，而且要保证安全无损。这里，我们将蚂蚁的安全生产理念融入其中，在产品层面上提供“可灰度，可回滚（应急），可监控”的能力。\n为了做到上述能力，我们提供了发布单的概念，并定义了一个原生的 CRD：CafeDeployment。接下来逐一介绍。\n发布单 主要两个用途：做应用发布的审查记录，用于统计分析，故障复盘回顾等；协调多个应用的发布顺序，这是由于金融业务对系统的可靠性要求高，尤其在涉及资金的主链路，另外，不少系统由于业务原因，存在依赖关系，必须做有序发布。\nCafeDeployment 在这里只做简单介绍，后续会有专题介绍。该 CRD 拥有三种能力：\n 原地升级（InplaceSet）:升级过程中 Pod 的 IP 保持不变，可和经典的运维监控体系做无缝集成。 替换升级（ReplicaSet）:和社区版本的 ReplicaSet 能力保持一致。 有状态应用（StatefulSet）:和社区版本的 StatefulSet 能力保持一致。 除此之外，相比社区的 deployment，还具备 beta 验证，自定义分组策略，分组暂停，引流验证（配合 ServiceMesh）的能力。\n三 具有高可用容灾能力的工作负载 金融业由于监管的要求对系统可用性和容灾能力具有很高的要求。从应用的生命周期来看，最主要有两个状态：发布态 和 运行态。\n对于发布态，由于存在 Pod 上下线的过程，线上有抖动不可避免，要做的是尽可能的降低抖动幅度以及降低系统报错率。kubernetes 的 deployment 在发布一个 pod 时，pod 里容器的 kill 和对应 endpoint 的销毁是异步的，这就意味着可能出现 pod 里应用容器已经 kill 了，但仍然会有流量打到该 Pod，导致出现报错，甚至故障。为了防止这种情况，我们采用 finalizer 的机制，保证在南北流量和东西流量（7 层协议）都切断的情况下才对 Pod 进行更新。\n同时，还通过 CafeDeployment 里的灰度发布策略，保证发布态时线上系统的水位不会过低，防止出现流量过载，造成系统异常。\n对于运行态，要考虑以下几个方面：Pod 异常退出后的重新上线，Node 故障后的 Pod 的迁移，机房级故障后系统仍然可用。对于第一点，Kubernetes 本身已经有了较好的机制；第二点，我们做了增强，使用自定义的 NodeLifecycle Controller 结合更加详细的监控信息来判断Node是否出现故障，然后做 Pod 迁移；第三点，从 Scheduler 方面进行保障，CafeDeployment 可以定义相应的高可用拓扑结构，以同城双活为例，在创建 Pod 时，调度器会根据定义好的拓扑信息尽量将 Pod 均分到不同的可用区，达到同城双活的状态。\n四 一致的验证授权体验 蚂蚁金服 PaaS 平台在近 4 年的时间里，已经有了一套完整的 IAM 体系，并且许多客户已经基于此定义了许多的角色，用做安全防护。我们从两方面来提供一致性的体验：\n首先，在产品上的操作上提供和原先一样的验证授权机制。只要客户将 K8S 内预先定义好的角色或者权限分配相应的用户或用户组，那该用户或者属于该用户组的用户就能在产品上做相应的操作。\n其次，IAM 的权限和角色与 Kubernetes 的 RBAC 做映射。根据用户在 IAM 所具备的角色，在 Kubernetes 集群中创建相应的 ClusterRole，并生成访问 Kubernetes 集群的 token，创建 ClusterRoleBinding 与 token 绑定。这样用户使用 kubectl 操作集群时也可以具备相同的权限，保证权限 …","date":1559890800,"description":"这将是一系列技术分享文章的开端，基于在实际金融机构和场景中落地的云原生产品项目经验，我们希望和大家一起分享从中获得的洞察和总结，探讨我们的产品观点、技术实现，并非常期待大家的建议和指点，欢迎一起交流共创。","dir":"blog/sofa-financial-cloud-native-exploration/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9c93781d7d4b980b1990e4655445d4bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","publishdate":"2019-06-07T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","summary":"由蚂蚁金服主办的 SOFAStack Cloud Native Workshop 将在 6月24日于 KubeCon + CloudNativeCon + Open Source Summit China 大会的同场活动中进行，欢迎报名参与，更多信息可见此链接。 欢迎加入 SOFA 钉钉互动群（钉钉搜","tags":["SOFAStack"],"title":"金融级云原生探索实践系列 - 开篇","type":"blog","url":"/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","wordcount":3874},{"author":"墨睿","categories":"SOFALookout","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFALookout 是在 SOFAStack 体系内研发开源的一款解决系统的度量和监控问题的轻量级中间件服务。本文给大家介绍下 SOFALookout 服务器端主要提供的特性以及使用方式。 SOFALookout：https://github.com/sofastack/sofa-lookout\n 前言 容器，K8S，微服务，Mesh 以及 Serverless 这些新技术方向正在根本的变革我们运行软件的方式。我们构建的系统更加分布式化，另外由于容器，系统的生命周期更加短，变得易逝。针对这些变化，SOFALookout 希望提供一套轻量级解决方案。之前 SOFALookout 已经开源客户端的能力。今天，SOFALookout 服务器端 Metrics 部分的代码终于正式开源啦！本文给大家介绍下 SOFALookout 服务器端的主要特性以及使用方法。\n什么是 SOFALookout SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\nSOFALookout 目标是打造一套轻量级 Observability 实时工具平台，帮助用户解决基础设施、应用和服务等的监控和分析的问题。SOFALookout（目前已开源部分） 是一个利用多维度的 metrics 对目标系统进行度量和监控的项目。SOFALookout 的多维度 metrics 参考 Metrics2.0 标准。\nSOFALookout ：https://github.com/sofastack/sofa-lookout\nSOFALookout 安装文档：https://www.sofastack.tech/sofa-lookout/docs/quickstart-metrics-server\n SOFALookout 服务器端的主要特性:\n 适配社区主要 Metrics 数据源协议写入（比如: Prometheus，Metricbeat 等）； 数据的存储支持扩展，暂时开源版默认支持 Elasticsearch， 并且透明和自动化了相关运维操作； 遵循 Prometheus 查询 API 的标准以及支持 PromQL，并进行了适当改进； 自带数据查询的控制台，并支持 Grafana 进行数据可视化； 使用简单，支持单一进程运行整个服务器端模块。 随着 SOFALookout （metrics）服务器端代码开源，metrics 数据的处理已经形成闭环。后续我们将会进一步开源 Trace 和 Event 相关的服务能力，敬请期待。\nSOFALookout 项目结构 服务器端代码分别包括两部分：Gateway 模块和 Server 模块。如下图所示（展示了 SOFALookout 源码项目的模块概要结构）\n├── boot ├── client ├── gateway └── server 项目中的 boot 模块作用是方便集成和运行服务端的模块，既可以单独运行 Gateway 和 Server 的服务，也可以借助 SOFAArk 完成（Gateway 和 Server）的 All in One 的合并为单一进程运行。\nSOFALookout 工作机制 下图完整展示了 SOFALookout 如何从 metrics 数据采集、上报、存储到最终展示的完整流程路径。\n目前 SOFALookout 支持灵活的 metrics 数据存储选型。但开源版本我们暂时只支持了 Elasticsearch 作为存储的方案（后续可能继续支持 Cassandra,InfluxDB\u0026amp;hellip;），其他存储地适配我们希望更多同学能参与共建和支持。优先支持 Elasticsearch 是因为我们考虑到了 ELK 解决方案在业界已经广泛使用，尤其是日志数据。\n为了开箱即用，同时考虑到不熟悉 Elasticsearch 的同学的使用，SOFALookout已经内置了关于 metrics 数据存储的自动化运维工具，可以免除大家自己建 Index，和日常维护 ES Index 的麻烦，更多细节后续单独讲解。\n本次新增开源模块 一、SOFALookout Gateway 模块 SOFALookout Gateway 轻量的数据管道，它提供丰富的协议接入支持，包括自有SDK（SOFALookout Client）上报协议，还支持 Prometheus 的数据协议（推模式和拉模式），Metricbeat 协议（版本是6），OpenTSDB 写入协议。每种数据来源对应于一个 Importer 的概念。\nSOFALookout Gateway 对于远程（推模式）上报提供本地硬盘缓冲的支持。Gateway 总体设计是围绕数据加工的Pipeline 形式，包括前置后置的数据过滤器方便进行开发者数据加工。 另外 Gateway 可以支持自定义 Exporter，默认提供了 Elasticsearch Exporter，Standard Exporter(用于 Gateway 间数据中继)，开发者也可以自定义其他存储的 或 Kafka 等各式各样 Exporter。\n二、SOFALookout Server 模块 SOFALookout Server 兼容和增强了 Prometheus 的数据及元数据查询的 RESTful API。同样对应 PromQL 我们也基本实现了兼容和增强（不包括 Alert 相关语法），SOFALookout 的 promQL 相关解析逻辑是从 Prometheus 移植而来，做了一些优化和改进， 感谢 Prometheus 开源了如此易用和强大的 golang 版本的 QL 实现。\n为了方便方便开发者做数据探索和试验，我们也提供了自有 Web-UI 的支持，能够满足基本功能使用。\n我们还是推荐大家使用 Grafana 进行数据展示。Grafana 集成 SOFALookout 很简单，只需要选择 Prometheus 作为数据源协议即可（SOFALookout默认查询端口也是: 9090）。下图展示 Grafana 新增数据源配置：\n近期计划 下图是近期的 Roadmap：\n非常欢迎更多同学参与 SOFALookout 共建，尤其是支持更多的 Metrics 存储库。\n","date":1559804400,"description":"本文给大家介绍下 SOFALookout 服务器端主要提供的特性以及使用方式。","dir":"blog/sofa-lookout-server-open-source/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d80fe27f8652b6e8a8da8d712a90a027","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-lookout-server-open-source/","publishdate":"2019-06-06T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-lookout-server-open-source/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFALookout 是在 SOFAStack 体系内","tags":["SOFALookout"],"title":"轻量级监控分析系统 SOFALookout 服务端开源","type":"blog","url":"/sofastack.tech/blog/sofa-lookout-server-open-source/","wordcount":1970},{"author":"Jimmy Song","categories":null,"content":" SOFAStack Cloud Native Workshop hosted by Ant Financial (KubeCon China 2019 Co-Located Event) Date: Monday, 24 June, 2019 Time: 9:00 – 16:00 Location: Shanghai Expo Centre Room 616 Registration Fees: Complimentary Register here: https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop Note: This event is hands-on, please bring your personal computer. The language of communication in this workshop is Chinese. SOFAStack (Scalable Open Financial Architecture Stack) is a financial-grade distributed architecture independently developed and open sourced by Ant Financial. It contains the components required to build a financial-grade cloud native architecture. It is a best practice tempered in financial scenarios. SOFAStack official website: https://www.sofastack.tech/\nAttendees can get:\n Rapidly build microservices based on SOFAStack Best Practices for Distributed Transactions in Financial Scenarios Cloud native deployment experience based on Kubernetes Service Mesh basic usage scenario experience on the cloud Get started on Serverless apps Easily build applications on the cloud based on Serverless How to Register: Pre-registration is required. To register for SOFAStack Cloud Native Workshop, add it on during your KubeCon + CloudNativeCon + Open Source Summit registration. You can get KubeCon half price tickets with KCCN19COMATF coupon code!\nFor questions regarding this event, please reach out to jingchao.sjc@antfin.com.\nEvent details 9:00 - 9:20 Opening speech SOFAStack Cloud Native\n9:20 - 10:10 Quickly build microservices with SOFAStack by Jie Cao\nBuilding a microservices application based on the SOFAStack. Through this workshop, you can learn how to report application monitoring data, service link data, and publish and subscribe services in the SOFAStack.\n10:15 - 11:05 SOFABoot dynamic module practice by Guolei Song\nIn this workshop, you can implement the combined deployment and dynamic module push capabilities provided by SOFAArk based on the ARK control capabilities of SOFADashboard.\n11:10 - 12:00 Using Seata to guarantee the consistency of payment by Long Chen\nUnder the microservice architecture, the distributed transaction problem is an industry problem. Through this workshop, you can understand the background of distributed transaction problems under distributed architecture, as well as common distributed transaction solutions and experience on how to use the open source distributed transaction framework - Seata\u0026amp;rsquo;s AT mode, TCC mode to solve the ultimate consistency of the business data.\n12:00 - 13:00 Lunch time\n13:00 - 13:30 Cloud Native exlporation and practice in Ant Fnancial by Renjie Yu\n13:30 - 14:40 Migrating to cloud based on Serverless by Yitao Dong\nAs one of the pioneering technologies of cloud technology, Serverless architecture allows you to further improve resource utilization and focus on business development. Through our workshop, you can experience new product …","date":1559643600,"description":"","dir":"activities/sofastack-cloud-native-workshop/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"57c6b0262af34c2010179000834d8363","permalink":"https://sofastack.github.io/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","publishdate":"2019-06-04T10:20:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","summary":"SOFAStack Cloud Native Workshop hosted by Ant Financial (KubeCon China 2019 Co-Located Event) Date: Monday, 24 June, 2019 Time: 9:00 – 16:00 Location: Shanghai Expo Centre Room 616 Registration Fees: Complimentary Register here: https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop Note: This event is hands-on, please bring your personal computer. The language of communication in this workshop is Chinese. SOFAStack (Scalable Open Financial Architecture Stack) is a financial-grade distributed architecture independently developed and open sourced by Ant Financial.","tags":["KubeCon","Workshop","Cloud Native"],"title":"KubeCon China 2019 Co-Located Event SOFAStack Cloud Native Workshop","type":"activities","url":"/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","wordcount":515},{"author":"宋净超","categories":null,"content":" 蚂蚁金服 SOFAStack 云原生工作坊（KubeCon China 2019 同场活动） 日期：2019年6月24日，星期一 时间：9:00 – 16:00 地点：上海世博中心 616 房间 注册费：免费 注册地址：https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop 备注：本次活动为动手实践，请携带个人电脑。本沙龙沟通语言为中文。 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发并开源的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。SOFAStack 官方网站：https://www.sofastack.tech/\n参加此次 Meetup 您将获得：\n 基于 SOFAStack 快速构建微服务 金融场景下的分布式事务最佳实践 基于 Kubernetes 的云原生部署体验 云上的 Service Mesh 基本使用场景体验 基于 Serverless 轻松构建云上应用 如何注册：此活动须提前注册。请将 SOFAStack Cloud Native Workshop 添加到您 KubeCon + CloudNativeCon + Open Source Summit 的注册表里。您可以使用 KCCN19COMATF 折扣码获取 KubeCon 半价门票！\n如果对此活动有任何疑问，请发送邮件至 jingchao.sjc@antfin.com。\n活动详情 9:00 - 9:20 开场演讲 SOFAStack 云原生开源体系介绍 by 余淮\n9:20 - 10:10 使用 SOFAStack 快速构建微服务 by 玄北\n基于 SOFA 技术栈构建微服务应用。通过本 workshop ，您可以了解在 SOFA 体系中如何上报应用监控数据、服务链路数据以及发布及订阅服务。\n10:15 - 11:05 SOFABoot 动态模块实践 by 卫恒\n在本 workshop 中，您可以基于 SOFADashboard 的 ARK 管控能力来实现 SOFAArk 提供的合并部署和动态模块推送的功能。\n11:10 - 12:00 使用 Seata 保障支付一致性 by 屹远\n微服务架构下，分布式事务问题是一个业界难题。通过本workshop，您可以了解到分布式架构下，分布式事务问题产生的背景，以及常见的分布式事务解决方案；并亲身体验到如何使用开源分布式事务框架Seata的AT模式、TCC模式解决业务数据的最终一致性问题。\n12:00 - 13:00 午餐时间\n13:00 - 13:30 蚂蚁金服的云原生探索与实践 by 首仁\n13:30 - 14:40 通过 Serverless 快速上云 by 隐秀\n作为云原生技术前进方向之一，Serverless 架构让您进一步提高资源利用率，更专注于业务研发。通过我们的 workshop，您可以体验到快速创建 Serveless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错、按时间触发应用等产品新功能。\n14:50 - 16:00 使用 CloudMesh 轻松实践 Service Mesh by 敖小剑\nService Mesh 将服务间通信能力下沉到基础设施，让应用解耦并轻量化。但 Service Mesh 本身的复杂度依然存在，CloudMesh 通过将 Service Mesh 托管在云上，使得您可以轻松的实践 Service Mesh 技术。通过我们的 workshop，您可以快速部署应用到 CloudMesh ，对服务进行访问，通过监控查看流量，体验服务治理、Sidecar管理和对服务的新版本进行灰度发布等实用功能。\n","date":1559643600,"description":"","dir":"activities/sofastack-cloud-native-workshop/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"57c6b0262af34c2010179000834d8363","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofastack-cloud-native-workshop/","publishdate":"2019-06-04T10:20:00Z","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofastack-cloud-native-workshop/","summary":"蚂蚁金服 SOFAStack 云原生工作坊（KubeCon China 2019 同场活动） 日期：2019年6月24日，星期一 时间：9:00 – 16:00 地点：上海世博中心 616 房间 注册费：免费","tags":["KubeCon","Workshop","Cloud Native"],"title":"KubeCon 上海同场活动 SOFAStack Cloud Native Workshop","type":"activities","url":"/sofastack.tech/activities/sofastack-cloud-native-workshop/","wordcount":1134},{"author":"卫恒","categories":"SOFAMeetup","content":" 作者：卫恒（宋国磊），SOFATracer 以及 SOFADashboard 开源负责人。\n本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，着重分享如何使用 SOFADashboard 来管控 SOFAArk ，对于 SOFAArk 中的一些基础概念和知识不过多涉及；建议大家在阅读之前，先了解下 SOFAArk 的相关基本知识。\n现场回顾视频以及 PPT 见文末链接。\n前言 SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署能力，由蚂蚁金服开源贡献。SOFAArk 在 0.6.0 版本 提供了非常丰富的功能特性，其中最核心的当属多应用（模块）合并部署这个能力。SOFAArk 本身提供了多种方式来支持多应用（模块）合并部署 ，包括基于命令行的管控，基于 API 的管控等。本篇将结合 SOFA 开源的管控端组件 SOFADashboard，来实现 SOFAArk 提供的合并部署和动态模块推送的功能。\n案例工程地址\n背景 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n案例模型 本篇所演示案例是上图的一个简化版，从整体上可以体现 SOFAArk多应用合并部署的能力。主要包括已经几个工程：\n sofa-dashboard-ark-hostapp : 宿主应用 sofa-dashboard-ark-facade : 提供接口 API sofa-dashboard-ark-provider ：提供接口 API 的具体实现，将发布一个 JVM 服务 sofa-dashboard-ark-hostapp 和 sofa-dashboard-ark-provider 均作为 SOFAArk 中的 ark-biz 存在；sofa-dashboard-ark-hostapp 作为宿主应用对外提供服务。\n上图的模型中，在宿主应用不重启的情况下，实现 provider 模块的动态替换，从而实现版本升级。\n 在宿主应用启动时，provider 1.0.0 以静态合并部署方式“寄宿”到宿主应用中，这部分实际上与 SOFADashboard 管控是没有什么关系的，为了案例效果，在下面的案例中，关于静态合并部署的操作也会涉及到。\n 最终的工程结构图如下：\n环境准备 本文需要启动 SOFADashboard 服务端，具体请参考 : Quick Start ；其他基础设施环境如 Zookeeper 、Mysql 等需提前准备。\n工程构建 本篇将通过 step by step 的方式来构建整个工程，为大家在实际的应用过程中提供一种简单的思路，同时也帮助大家更好的理解 SOFAArk 中的一些点。\nsofa-dashboard-ark-facade 基础 API 提供模块，不需要依赖任何其他二方或者三方 JAR，这里仅提供一个接口。\npublic interface SofaJvmService { String test(); } sofa-dashboard-ark-provider 这个模块是 JVM 服务的提供方，也是后面需要在宿主应用中进行替换演示的模块包，这个模块本身也是一个 Web 应用。这里就来一步步分解下，如何将一个普通的 SpringBoot 工程改造成一个 ark-biz 工程。\n1、新建一个 SpringBoot 工程 新建 SpringBoot 工程推荐的方式有两种，一种是在 https://start.spring.io/ 进行下载，另外一种是基于 IDEA 的 Spring 插件来生成；此处不在过多描述过程。\n2、工程基本能力实现 引入 sofa-dashboard-ark-facade 依赖，先将需要提供的 JVM 服务实现： @SofaService @Service public class SofaJvmServiceImpl implements SofaJvmService { @Override public String test() { return \u0026amp;quot;first version biz\u0026amp;quot;; } } NOTE: SofaService 的作用是将一个 Bean 发布成一个 JVM 服务， 所以这里需要加上 Spring 提供的 @Service 注解将 SofaJvmServiceImpl 标注为一个 Bean。\n 配置文件： spring.application.name=biz-ark-test server.port=8800 logging.path=./logs 3、配置打包插件，将应用打包成 ark-biz  根据官方文档，可以使用 sofa-ark-maven-plugin 插件将一个普通的工程打包成一个 ark biz 包。这里直接给出本篇中工程的配置：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!--ark-biz 包的打包配置 --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- ark-biz 包的启动优先级，值越小，优先级越高--\u0026amp;gt; …","date":1559286000,"description":"本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，着重分享如何使用 SOFADashboard 来管控 SOFAArk ，对于 SOFAArk 中的一些基础概念和知识不过多涉及。","dir":"blog/sofa-meetup-2-2-retrospect/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"61a156b1a9f1a80f555200bfea5a20b6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","publishdate":"2019-05-31T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","summary":"作者：卫恒（宋国磊），SOFATracer 以及 SOFADashboard 开源负责人。 本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，","tags":["SOFAMeetup","SOFAArk","SOFADashboard"],"title":"基于 SOFAArk 和 SOFADashboard 实现动态模块管控 | Meetup#2 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","wordcount":3608},{"author":"玄北","categories":"SOFAStack","content":" 本文作者：玄北（曹杰），蚂蚁金服 SOFAStack 开源组核心成员。\n本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理，主要来聊聊 spring-cloud-antfin 包含的主要特性及如何使用 SOFAStack 和 SpringCloud 快读构建微服务系统。\n现场回顾视频以及 PPT 见文末链接。\n概念 Spring Cloud 是 Spring 社区开源的一套微服务开发框架，帮助开发人员快速构建分布式应用，Spring Cloud 的官网介绍如下：\n Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state).\n 蚂蚁金服从 2007 年开始在公司内部使用 SOFAStack 框架，2014 年基于 Spring Boot 研发了 SOFABoot，2016 年将 SOFAStack 在公有云输出，2018 年 4 月，蚂蚁金服宣布开源 SOFAStack。SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服开源的，用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。SOFAStack ：https://github.com/sofastack\nSOFAStack 包含以下主要特性：\n 全面：覆盖多种场景，让用户更加专注于业务开发； 可靠：经历过大规模场景的锤炼，特别是严苛的金融场景； 丰富：包含构建金融级云原生架构所需的各个组件，满足用户场景的现状和未来需求； 开放：兼容开源生态，组件可插拔， SOFAStack 组件与其它开源组件可相互集成或替换。 SOFAStack 开源全景图涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的 Nacos、Sentinel 等，为用户提供更加广泛地选择。\nSOFAStack 开源已经超过一年，Spring Cloud 作为当下流行的微服务框架，社区用户以及公司内部用户迫切希望能够将这两个优秀的框架进行整合，将 SOFAStack 中间件适配 Spring Cloud 规范也就产生了我们今天的主角——spring-cloud-antfin。\nspring-cloud-antfin 全景图 Spring 官网提供了一份 Spring Cloud 的架构图：\n从 Spring Cloud 的架构图可以看到，Spring Cloud 框架涵盖了分布式应用开发的方方面面，包括：\n API 网关  熔断与限流 服务发现 分布式配置 分布式链路 spring-cloud-antfin 是 Spring Cloud 微服务规范的 antfin 实现，同样的，我们也有一份 spring-cloud-antfin 全景图，涵盖了蚂蚁金服所有中间件：\n与 Spring Cloud 全景图不同，在 spring-cloud-antfin 中每种分布式组件都有具体的蚂蚁中间件实现：\n API 网关：SOFAGateway 熔断与限流：Guardian 服务发现：SOFARegistry 分布式配置：DRM 分布式链路：SOFATracer 在 spring-cloud-antfin 适配 Spring Cloud 的过程中，我们发现 Spring Cloud 制定的规范并不完整，对于一些 Spring Cloud 规范并未涵盖的方面，spring-cloud-antfin 进行了扩展。\n扩展 Spring Cloud 虽然 Spring Cloud 定义了很多微服务规范，但是在具体业务开发过程中，我们发现 Spring Cloud 还有很多不足，例如 Spring Cloud 对以下能力没有进行规范化：\n 属性级别动态配置 事务消息 Big Table 分布式事务 属性级别动态配置 Spring Cloud 的动态配置基于 RefreshScope 接口，默认 RefreshScope 会对整个 Bean 进行刷新，而且实现自动刷新需要配合 spring-cloud-bus，我们认为与 Apollo、Nacos 等属性级别刷新相比，这个是明显的退步，所以 spring-cloud-antfin 定义一个 DynamicConfig 注解，对于打有这个注解的 Bean，spring-cloud-antfin 支持属性级别动态配置：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) public @interface DynamicConfig { } 事务消息 spring-cloud-stream 默认不支持事务消息，但是在金融级场景中事务消息是必不可少的，所以 spring-cloud-antfin 扩展了 spring-cloud-stream 的定义，对事务消息进行了支持：\n MQ 支持事务：对于使用 MQ 本身就支持事务消息的，spring-cloud-antfin 会在 MessageHeaders 中增加 Transcation 相关属性，以此支持事务消息； MQ 不支持事务：对于使用 MQ 本身不支持事务的，spring-cloud-antfin 支持用本地事件表的模式支持事务消息。 消息发送端在同一个本地事务中记录业务数据和消息事件； 事件恢复服务定时从事件表中恢复未发布成功的事件，重新发布成功后删除记录的事件。 通过事件恢复服务的不停执行，我们保证了本地事件和消息发送到 Message Broker 必定同时成功或者同时失败。\nBig Table 一些 SOFAStack 的使用者，一套代码会在多种技术栈使用，当使用开源技术栈时，Big Table 的实现会使用 HBase，在使用商业技术栈时，Big Table 会使用阿里云的 TableStore，为了让用户实现不修改代码在不同技术栈使用，spring-cloud-antfin 会定义一套统一接口，然后让用户针对 spring-cloud-antfin 的接口进行编程，这样在替换底层实现时用户代码不需要修改：\npublic interface BigTableService { Result get(Get get) throws StoreException; Result[] get(List\u0026amp;lt;Get\u0026amp;gt; get) …","date":1559113200,"description":"本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理。","dir":"blog/sofa-meetup-2-1-retrospect/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ffc229811fe6c3065b010a9730e6d895","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","publishdate":"2019-05-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","summary":"本文作者：玄北（曹杰），蚂蚁金服 SOFAStack 开源组核心成员。 本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理，主要来聊聊 spring-cloud-antfin 包含","tags":["SOFAStack","SOFAMeetup"],"title":"当 Spring Cloud 遇上 SOFAStack | Meetup#2 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","wordcount":2918},{"author":"敖小剑","categories":"Service Mesh","content":" 前言 本文内容整理自5月25日在 Kubernetes \u0026amp;amp; Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 ServiceMesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁金服的上云实践，阐述在云原生背景下 Service Mesh 的核心价值，以及对云原生落地的关键作用。\n内容主要有三个部分：\n Service Mesh 产品动态：介绍最近半年 Service Mesh 的产品动态，包括开源项目和云厂商推出的云上服务 Service Mesh 发展趋势：根据最近的产品动态，总结 Service Mesh 的发展趋势，推断未来的走向 Service Mesh 与云原生：结合云原生，更好的理解 Service Mesh 的价值和作用 Service Mesh 产品动态 Istio1.1 发布 Istio 是目前 Service Mesh 社区最引人注目的开源项目，在今年的3月份发布了期待已久的 Istio 1.1 版本，我们来看看 Istio 最近几个版本的发布情况：\n 2018年6月1日，Istio 发布了 0.8 版本，这是 Istio 历史上第一个 LTS 版本，也是 Istio 历史上变动最大的一个版本； 2018年7月31日，Istio 发布了 1.0 版本，号称 \u0026amp;ldquo;Product Ready\u0026amp;rdquo;； 然后就是漫长的等待，Istio 1.0 系列以每个月一个小版本的方式一路发布了 1.0.1 到 1.0.6，然后才开始 1.1.0 snapshot 1 到 6，再 1.1.0-rc 1 到 6，终于在 2019年3月20日 发布了 1.1 版本，号称 \u0026amp;ldquo;Enterprise Ready\u0026amp;rdquo;。 从 Istio 1.0 到 Istio 1.1，中间的时间跨度高达9个月！我们来看看经过这漫长的开发时间才发布的 Istio 1.1 版本带来了哪些新的东西：\n图中标红的部分，涉及到 Istio 的架构调整，下面将详细介绍 Istio 1.1 版本中带来的架构变化。\nIstio 1.1 架构变化 下图是 Istio 1.0 和 Istio 1.1 的架构图对比：\nIstio 1.1 的第一个架构变化来自 Galley：在 Istio 1.1 的架构图中增加了 Galley 组件。但是实际上在 Istio 1.0 版本中 Gallay 组件就已经存在，只是当时 Galley 的功能非常简单，只是做配置更新之后的验证（Validation），在 Istio 1.0 的架构图中都没有出现。而在 Istio 1.1 版本之后，Galley 的定位发生了巨大的变化：Galley开始分担 Pilot/Mixer 的职责。\n在 Istio 1.1 版本之前的设计中，Istio 的三大组件 Pilot/Mixer/Citadel 都需要访问 Kubernetes 的 API Server，以获取服务注册信息和配置信息，包括 Kubernetes 原生资源如 service/deployment/pod 等，还有 Istio 的自定义资源（数量多达50多个的 CRD） 。这个设计导致 Istio 的各个组件都不得不和 Kubernetes 的 API Server产生强绑定，不仅仅代码大量冗余，而且在测试中也因为需要和 Kubernetes 的 API Server 交互导致 Pilot/Mixer 模块测试困难。\n为了解决这个问题，在 Istio 1.1 之后，访问 Kubernetes 的 API Server 的工作将逐渐交给 Galley 组件，而其他组件如 Pilot/Mixer 就会和 Kubernetes 解耦。\n这个工作还在进行中，目前 Istio 的 CRD 已经修改为由 Galley 读取，而 K8s 的原生资源（Service / Deployment / Pod等），暂时还是由 Pilot 读取。\n为了方便在各个组件中同步数据，Istio 引入了MCP（Mesh Configuration Protocol）协议。在 Istio 1.1 版本中，Pilot 通过 MCP 协议从 Galley 同步数据。MCP 是受 xDS v2 协议（准确说是 aDS）的启发而制定的新协议，用于在Istio 各模块之间同步数据。\nIstio 1.1 的第二个架构变化来自于 Mixer，在 Istio 1.1 版本中，推荐使用 Out-of-Process Adapter，即进程外适配器。Istio 预计下一个版本将弃用 In-Proxy Adapter，目前所有的 Adapter 都将改为 Out-of-Process adapter。\n什么是 In-Proxy Adapter？下图是 Mixer 的架构图，在 Istio 的设计中，Mixer 是一个独立进程，Proxy 通过远程调用来和 Mixer 交互。而 Mixer 的实现了 Adapter 模式，定义了 Adapter API，然后内建了数量非常多的各种Adapter。这些 Adatper 的代码存放在 Mixer 代码中，运行时也在 Mixer 的进程内，因此称为 In-Process Adapter。\nIn-Process Adapter 的问题在于所有的 Adapter 的实现都和 Mixer 直接绑定，包括代码和运行时。因此当 Adapter 需要更新时就需要更新整个 Mixer，任意一个 Adapter 的实现出现问题也会影响整个 Mixer，而且数量众多的 Adapter 也带来了数量众多的CRD。为此，Istio 1.1 版本中通过引入 Out-of-Process Adapter 来解决这个问题。\nOut-of-Process Adapter 以独立进程的方式运行在 Mixer 进程之外，因此 Out-of-Process Adapter 的开发/部署和配置都可以独立于 Mixer，从而将 Mixer 从 Adaper 的实现细节中解脱出来。\n但是，Out-of-Process Adapter 的引入，会导致新的性能问题：原来 Mixer 和 In-Process Adapter 之间是方法调用，现在改成 Out-of-Process Adapter 之后就变成远程调用了。而 Mixer 一直以来都是 Istio 架构设计中最大的争议，之前 Proxy 和 Mixer 之间的远程调用，已经造成非常大的性能瓶颈，而引入 Out-of-Process Adapter 之后远程调用会从一次会变成多次（每个配置生效的 Out-of-Process Adapter 就意味着一次远程调用），这会让性能雪上加霜。\n总结 Out-of-Process Adapter 的引入：架构更加的优雅，性能更加的糟糕。\n在 Istio 1.1 为了架构而不顾性能的同时，Istio 内部也有其他的声音传出，如正在规划中的 Mixer v2。这个规划最重要的决策就是放弃 Mixer 独立进程的想法，改为将 Mixer 的功能合并到 Envoy 中，从而避免 Envoy …","date":1559026800,"description":"本文内容整理自5月25日在 Kubernetes \u0026 Cloud Native Meetup 上海站发表的主题演讲。","dir":"blog/service-mesh-development-trend-1/","fuzzywordcount":8400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8756e6985e0df28a5150ebd3af0e48c5","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-development-trend-1/","publishdate":"2019-05-28T15:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/service-mesh-development-trend-1/","summary":"前言 本文内容整理自5月25日在 Kubernetes \u0026amp; Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 ServiceMesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁金服的上云实践，","tags":["Service Mesh"],"title":"Service Mesh 发展趋势：云原生中流砥柱","type":"blog","url":"/sofastack.tech/blog/service-mesh-development-trend-1/","wordcount":8383},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第二篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 SOFAJRaft-RheaKV 是基于 SOFAJRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库，SOFAJRaft 是基于 Raft 一致性算法的生产级高性能 Java 实现，支持 Multi-Raft-Group。SOFAJRaft-RheaKV 集群主要包括三个核心组件：PD，Store 和 Region。本文将围绕 SOFAJRaft-RheaKV 架构设计，存储概览，核心模块，使用场景以及基于 Raft 实现等方面剖析 SOFAJRaft-RheaKV 基于 SOFAJRaft 实现原理，阐述如何使用 Raft 协议支持 KV 存储类库功能特性：\n SOFAJRaft-RheaKV 基础架构如何设计？核心组件负责哪些功能？模块内部处理流程是怎样？ 基于 SOFAJRaft 如何使用 Raft 实现 SOFAJRaft-RheaKV 强一致性和自驱动等特性？  SOFAJRaft-RheaKV 概览 SOFAJRaft-RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 Library， RheaKV 包含在 SOFAJRaft 项目里，是 SOFAJRaft 的子模块。SOFAJRaft-RheaKV 定位是嵌入式 jar 包方式嵌入到应用中，涵盖以下功能特性：\n 强一致性，基于 Multi-Raft 分布式一致性协议保证数据可靠性和一致性； 自驱动，自诊断，自优化，自决策，自恢复； 可监控基于节点自动上报到 PD 的元信息和状态信息； 基本 API get/put/delete 和跨分区 scan/batch put，distributed lock 等。 架构设计 SOFAJRaft-RheaKV 存储类库主要包括 PD，Store 和 Region 三个核心组件，支持轻量级的状态/元信息存储以及集群同步，分布式锁服务使用场景：\n PD 是全局的中心总控节点，负责整个集群的调度管理，维护 RegionRouteTable 路由表。一个 PDServer 管理多个集群，集群之间基于 clusterId 隔离；PD Server 需要单独部署，很多场景其实并不需要自管理，RheaKV 也支持不启用 PD，不需要自管理的集群可不启用 PD，设置 PlacementDriverOptions 的 fake选项为 true 即可。 Store 是集群中的一个物理存储节点，一个 Store 包含一个或多个 Region。 Region 是最小的 KV 数据单元，可理解为一个数据分区或者分片，每个 Region 都有一个左闭右开的区间 [startKey, endKey)，能够根据请求流量/负载/数据量大小等指标自动分裂以及自动副本搬迁。Region 有多个副本 Replication 构建 Raft Groups 存储在不同的 Store 节点，通过 Raft 协议日志复制功能数据同步到同 Group 的全部节点。 存储设计 SOFAJRaft-RheaKV 存储层为可插拔设计，实现 RawKVStore 存储接口，目前 StoreEngine 存储引擎支持 MemoryDB 和 RocksDB 两种实现：\n MemoryRawKVStore：MemoryDB 基于 ConcurrentSkipListMap 实现，有更好的性能，但是单机存储容量受内存限制； RocksRawKVStore：RocksDB 在存储容量上只受磁盘限制，适合更大数据量的场景。 SOFAJRaft-RheaKV 存储引擎基于 MemoryDB 和 RocksDB 实现 KV 存储入口：\ncom.alipay.sofa.jraft.rhea.storage.RawKVStore com.alipay.sofa.jraft.rhea.storage.MemoryRawKVStore com.alipay.sofa.jraft.rhea.storage.RocksRawKVStore SOFAJRaft-RheaKV 数据强一致性依靠 SOFAJRaft 同步数据到其他副本 Replication, 每个数据变更都会落地为一条 Raft 日志, 通过 Raft 协议日志复制功能将数据安全可靠地同步到同 Raft Group 的全部节点里。\n核心设计 SOFAJRaft-RheaKV 核心模块包括 KV 模块[RheaKVStore 基于 RegionRouteTable 路由表使用 RaftRawKVStore 存储 KeyValue]，PD 模块[PlacementDriverServer 基于 StoreHeartbeat/RegionHeartbeat 心跳平衡节点分区 Leader 以及分裂]。\nKV 模块内部处理 RheaKVStore：最上层 User API，默认实现为 DefaultRheaKVStore， RheaKVStore 为纯异步实现，所以通常阻塞调用导致的客户端出现瓶颈，理论上不会在 RheaKV 上遭遇，DefaultRheaKVStore 实现包括请求路由、Request 分裂、Response 聚合以及失败重试等功能。 PlacementDriverClient：非必须，作为与 PlacementDriver Server 集群沟通的客户端，通过它获取集群完整信息包括但不仅限于\u0026amp;rdquo;请求路由表\u0026amp;rdquo;，对于无 PD 场景， RheaKV 提供 Fake PD Client。 RegionRouteTable：分片逻辑基于 RegionRouteTable 路由表结构，最适合的数据结构便是跳表或者二叉树(最接近匹配项查询)。作为本地路由表缓存组件，RegionRouteTable 根据 KV 请求的具体失败原因来决策是否从 PD Server 集群刷新数据，并且提供对单个 Key、多个 Key 列表以及 Key Range 进行计算返回对应的分区 ID。选择 Region 的 StartKey 作为 RegionRouteTable 的 Key ，主要取决于 Region Split 的方式，父 Region 分裂成两个子 Region 导致其中一个子 Region 的 StartKey …","date":1558681200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第二篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-jraft-rheakv/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4d79102c8300ca628483bdba44c13049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv/","publishdate":"2019-05-24T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 实现原理 - SOFAJRaft-RheaKV 是如何使用 Raft 的","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv/","wordcount":5817},{"author":"Linux 中国老王","categories":"SOFAStack","content":" — 本文转载自 Linux 中国老王\n蚂蚁金服的 SOFAStack 作为一个成功地将企业私有项目转化为开源核心模式的知名案例，我们之前对背后的思考和推动力做过专题分析，但是具体这件事是如何在蚂蚁金服内部发生的、是如何实操的，有很多读者向我们表示非常感兴趣，而我觉得这也是其它技术公司所正在探索和思考的方向。\n因此，上个月底，老王在参加上海举办的 KubeCon 2019 时，遇到了蚂蚁金服 SOFA 团队的余淮，他目前在蚂蚁金服中间件团队服务与框架组具体负责开发框架与 SOFAStack 的开源工作。于是，参会之余，我和余淮就 SOFA 开源的实操方面进行了深入的沟通，现将谈话所得整理给大家。\nSOFA 与开源 继去年开始开源 SOFAStack 以来，今年上半年他们又开源了分布式事务框架 Seata 和服务注册中心 SOFARegistry，之前我曾经向蚂蚁金服中间件负责人杨冰了解过为什么要将 SOFA 开源的背后思考，以及 SOFA 发展迭代的历程，详情可以看之前的文章《蚂蚁金服技术总监杨冰：金融科技公司为什么要拥抱开源？ 》进行了解。\n目前，SOFA 的架构已经发展到 SOFA 5 阶段，在今年 2 月，前任 SOFA 开源负责人鲁直还向我分享了 SOFA 5 中重点推进的方向，主要包括 Service Mesh 和 Serverless，以及分布式事务 Seata 的落地，具体内容见文章《蚂蚁金服开源负责人鲁直：不只是中间件，未来会开源更多》。\n作为一个成功的开源核心模式的项目，我非常关注 SOFA 开源的实操是如何进行的，是如何进行开源治理的，作为 SOFA 团队的老朋友，我们话题就直接从 SOFA 的开源治理聊起。\n以 SOFA 为例：公司内部软件的开源流程 余淮说，从 2015 年开始，蚂蚁金服开启了金融科技对外输出的战略，SOFAStack 也走出了蚂蚁金服，甚至跨越了国界，被更多金融机构与合作伙伴所使用，如天弘基金、信美互信、南京银行、PayTM、DANA 钱包等。\n在与合作伙伴以及客户的沟通、合作过程中，他们发现了 SOFAStack 的理念和能力也正是很多金融行业的企业所需要的。在蚂蚁金融科技对外输出的过程中，内部已经对 SOFAStack 进行了一定程度的代码重构，例如历史兼容逻辑的剥离等，但是并未能达到直接开源的标准。\n关于开源，内部一直有开源的讨论，到 2017 年双十一结束后正式决定开源。经过了一系列的准备，2018 年 4 月，完成了对 SOFA 项目的满足了开源改造的标准后，SOFAStack 马上宣布正式开源框架中部分重要组件。\nSOFA 团队采用的开源策略叫「Open Core」，顾名思义就是要将接口层以及核心实现都开源，以可扩展化的方式来层层构建 SOFAStack 的能力，保证 SOFAStack 的内部版本和开源的版本采用的是同一个内核。为此 SOFAStack 做了大量的改造和重构工作。\n在开源的具体考量上，余淮表示，SOFAStack 的开源改造基本上有三条原则，分别是高可扩展性、对内兼容历史版本、对外兼容业界标准。\n以 SOFARPC 重构为例，大概经历了这样的过程：\n 首先需要将 SOFARPC 进行了一次核心接口和模型抽象，然后增加了扩展点机制和事件总线机制，所有的对内对外实现都基于这些核心接口和模型去扩展，并且保证这些扩展能力都是平等的、可选的； 接着将核心的处理逻辑实现迁移到这套接口和模型上来，保证 SOFARPC 能力完整可用； 然后需要将 SOFARPC 里一些对接内部系统的、兼容历史逻辑的代码做成内部扩展，并进行全量测试验证，确保和已有线上的历史方案的兼容，发布上线； 最后会调研业界的一些开源标准方案和实现，并对其进行兼容，例如 SOFARPC 不仅对接自己的 SOFARegistry 的实现，还兼容了 Zookeeper、Etcd、Nacos 等业界优秀的注册中心方案。 虽然上面重构过程听上去没那么复杂，但是在实际过程中还是非常考验团队的技术能力的，特别是在抽象核心接口和模型的时候，为了做到既兼容内部又兼容外部，这需要进行大量的调研工作，才能做好这层较为通用抽象。其次在对内逻辑兼容的时候，由于内部的历史负担还是比较重的，为了能让重构的代码安全上线，团队也做了很多事情。\n还是举 SOFARPC 的例子，蚂蚁金服内部的服务路由过程比开源是要复杂很多的，特别是配合蚂蚁金服特有的单元化部署以及异地多活的能力，有时候需要多层路由才能找到目标地址。为了验证重构后逻辑的正确性，除了在开源代码里有单元测试用例外，SOFA 团队在内部也构建了一套非常完善的集成框架，专门用来测试已有逻辑的兼容性及正确性。\n基于 Open Core 这套思想建设 SOFAStack 以后，其实对开发同学的工作量来不会变少，反而可能是增多的。这是因为在写代码的同时，需要更多的考虑内部外部的使用情况，对代码质量也提出了更高的要求，开发流程会变得更加复杂。\n例如，内部新增一个特性，在以前可能直接修改代码经过测试就发布上线了，但现在的话会去思考这其中哪些能力是通用的，把这些能力抽象一下放到开源版本里去，然后开源版测试后发布，这个时候内部版本在基于这个开源版进行扩展，再经过测试后发布上线。\n虽然开发同学工作变多了，但是这样的话可以让 SOFAStack 的核心代码被更多的开发者 Review，在更多的系统中运行，在更多的场景下进行验证，对 SOFAStack 的品质保证有非常大的帮助。\n此外在开源进度上，余淮表示， SOFAStack 并不追求开源全部内部的组件，而是会根据产品的特性和开源准备的情况有选择的开源。\n例如 SOFAStack 下的分库分表组件，因为产品特性和 OB 等内部结合紧密就暂时不会开源。金融级分布式架构下未开源部分能力，SOFAStack 会和与业界其它优秀的开源项目做集成，保证整个金融级分布式架构功能的完整性和多样性。\n所以对于 SOFAStack 来说，并不只有自己开源的产品，而更多关注的是，和整个社区里所有开源优秀的产品一起，打造一套快速构建金融级分布式架构的套件。\n开源项目管理 开源一个项目，作为背后推动的公司事实上要付出相当多的人力和资金成本，同时，也不可避免的会涉及到审批流程。随着蚂蚁金服越来越多领域的项目开源，包括 SOFAStack，AI，区块链等，蚂蚁金服内部出台了相应的严格的审核机制，包括技术、合规、法务、安全等部门进行审核，同时还会考察项目开源对公司的意义，以及是否对社区有价值，在审核通过之后项目就会正式开源与大家见面了。\n蚂蚁金服对于开源文化是十分友好的，其内部的代码也大多都是公开在内网的 GitLab 仓库，经常会有业务团队对 SOFAStack 提交一些合并请求（拉取请求）来帮助项目的发展。\n同时，蚂蚁金服的工程师也普遍地拥抱开源，开源能够帮助项目产生更多、更好的想法，同时也可以吸收来自社区的贡献，让项目本身能够做的更好，这是大家所喜闻乐见的。 SOFA 的社区治理 开源项目并不是开放源代码就是终点，事实上，这只是开始，之后持续不断的开源治理才是开源之路。而如何将一个开源项目从最开始的由开源项目背后的公司主导转变为社 …","date":1558681200,"description":"SOFAStack 开源如何在蚂蚁金服内部发生、是如何实操的、如何运营，Lunix中国老王进行了采访和分析，欢迎阅读","dir":"blog/sofastack-linux-china/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c1896b9b50b60432bb345d583a9be24a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-linux-china/","publishdate":"2019-05-24T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofastack-linux-china/","summary":"— 本文转载自 Linux 中国老王 蚂蚁金服的 SOFAStack 作为一个成功地将企业私有项目转化为开源核心模式的知名案例，我们之前对背后的思考和推动力做过专题分析，但是具","tags":["SOFAStack"],"title":"大公司开源怎么做？SOFAStack给出了一个很好的例子","type":"blog","url":"/sofastack.tech/blog/sofastack-linux-china/","wordcount":3968},{"author":"花肉","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 活动时间：5 月 26 日周日下午 13 点 活动地点：上海市徐汇区田林路200号A7栋一楼 活动形式：线下活动 报名方式：https://tech.antfin.com/community/activities/576 活动介绍 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n欢迎 Star 我：https://github.com/sofastack\nSOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n5 月 26 日，SOFAMeetup#2 上海站，SOFAStack 开源核心成员集体出动。本期我们将侧重于各个落地的实际场景进行架构解析。\n分布式事务 Seata 详解、与 Spring Cloud 生态的融合案例、使用 SOFAStack 快速构建微服务 Demo 实操、更有最新开源的《让 AI 像 SQL 一样简单 — SQLFlow Demo 》首秀，期待与你不见不散~\n建议：参会者可带上电脑，现场有 Demo 实操环节~\n加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n点击即可报名 https://tech.antfin.com/community/activities/576\n议程 时间 环节 讲师 13:00 - 13:30 签到 13:30 - 14:15 《研发框架 SOFABoot 的特性及落地场景介绍》 蚂蚁金服 SOFABoot 负责人 善逝 14 :15 - 15:00 《谈注册中心 SOFARegistry 架构设计 》 蚂蚁金服 SOFARegistry 负责人 琪祥 15:00 - 15:05 茶歇休息 15:05 - 15:15 《SOFALab 社区共建分享》 SOFALab 杰出贡献者 米麒麟 15:15 - 16:00 《当 SpringCloud 遇上 SOFAStack》 蚂蚁金服 SOFAStack 开源组核心负责人 玄北 16:00 - 16:45 《分布式事务 Seata 实现原理及实践详解》 Seata Committer 绍辉 16:45 - 17:30 《使用 SOFAStack 快速构建微服务》SOFADashboard 演示 + SOFARegistry + SOFARPC + SOFAArk 蚂蚁金服 SOFADashboard 负责人 卫恒 17:30 - 17:45 《让 AI 像 SQL 一样简单 — SQLFlow Demo 演示》 蚂蚁金服深度学习引擎开源产品负责人 三平 ","date":1558437600,"description":"SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务，5 月 26 日周日下午 13 点，上海市徐汇区田林路200号A7栋一楼。","dir":"activities/sofa-meetup-2/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5765309cb693fc8cc45958ecab5a9c3b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-2/","publishdate":"2019-05-21T11:20:00Z","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-meetup-2/","summary":"概要 活动主题：SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 活动时间：5 月 26 日周日下午 13 点 活动地点：上海市徐汇区田林路200号A7栋一楼 活动形式：线","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#2 上海站——使用 SOFAStack 快速构建微服务","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-2/","wordcount":849},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFAStack 启用独立 Group ，社区更加开放 今日，SOFAStack 将启用独立 Group： https://github.com/sofastack\n感谢大家的一路支持，未来，我们继续相伴~\n背景：分布式架构 SOFAStack 开源历史 金融级分布式架构 SOFAStack 产生于蚂蚁金服内部需求，起初是为了解决高速发展下的业务问题。到 2019 年，已经历12年的业务锤炼，变成了一套成熟的金融级最佳实践。\nSOFAStack 的发展受益于开源社区的优秀产品，我们也决定结合我们的实践积累，把这些技术反馈给开源社区。\n2018 年 4 月，SOFAStack 宣布开源。这一年，SOFAStack 逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFABolt、SOFAMosn、SOFAMesh、SOFAJRaft、SOFAActs、SOFARegistry、SOFADashboard 等组件。2019 年 3 月，蚂蚁金服加入分布式事务Seata的社区共建中，并贡献其 TCC 模式。\nSOFAStack 未来也将持续开源，丰富生态。\nSOFA 开源全景图，涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的 Nacos、Sentinel 等，为用户提供更加广泛地选择。\nSOFAStack 启用独立 Group 和邮件订阅列表 为了开源管理更加清晰，更社区化的运作，更中立的技术态度，开放给更多的开发者和企业参与，SOFAStack 将启用独立 Group：\n SOFAStack 项目地址： https://github.com/sofastack 原项目地址： https://github.com/alipay 继续可访问，会跳转到新的地址上。\n 邮件订阅列表 加入 SOFAStack 邮件组 https://groups.google.com/forum/#!forum/sofastack 获取邮件订阅。\n感谢大家的一路支持，未来，我们继续相伴~\n","date":1557990000,"description":"SOFAStack 将启用独立 Group，社区更加开放今日。感谢大家的一路支持，未来，我们继续相伴","dir":"blog/sofastack-independent-droup/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f25b8521e498ebce982a98b882f941b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-independent-droup/","publishdate":"2019-05-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofastack-independent-droup/","summary":"SOFAStack 启用独立 Group ，社区更加开放 今日，SOFAStack 将启用独立 Group： https://github.com/sofastack 感谢大家的一路支持，未来，我们继续相伴~ 背景：分布式架构 SOFAStack 开源历史","tags":["SOFAStack"],"title":"持续技术开放 | SOFAStack 启用独立 Group","type":"blog","url":"/sofastack.tech/blog/sofastack-independent-droup/","wordcount":617},{"author":"SQLFlow","categories":"SQLFlow","content":" 5 月 6 日，在 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow，他在演讲中表示：“未来三年，AI 能力会成为每一位技术人员的基本能力。我们希望通过开源 SQLFlow，降低人工智能应用的技术门槛，让技术人员调用 AI 像 SQL 一样简单。”\nSQLFlow 的目标是将 SQL 引擎和 AI 引擎连接起来，让用户仅需几行 SQL 代码就能描述整个应用或者产品背后的数据流和 AI 构造。其中所涉及的 SQL 引擎包括 MySQL、Oracle、Hive、SparkSQL、Flink 等支持用 SQL 或其某个变种语言描述数据，以及描述对数据的操作的系统。而这里所指的 AI 引擎包括 TensorFlow、PyTorch 等深度学习系统，也包括 XGBoost、LibLinear、LibSVM 等传统机器学习系统。\nSQLFlow 开源项目链接：https://sqlflow.org/sqlflow\n5 月 26 日，将在上海迎来 SQLFlow 线下首秀 —《让 AI 像 SQL 一样简单— SQLFlow Demo》，还有 SOFAStack 开源生态交流分享，点击链接，即可报名~期待你的到来~\nhttps://tech.antfin.com/community/activities/576\nSQLFlow 的研发团队认为，在 SQLFlow 和 AI 引擎之间存在一个很大的空隙——如何把数据变成 AI 模型需要的输入。谷歌开源的 TensorFlow 项目开了一个好头，TFX Data Transform 和 feature column API 都是意图填补这个空缺的项目。但是这个空缺很大，是各种 SQL 引擎和各种 AI 引擎的笛卡尔积，远不是 TensorFlow 的这两个子项目就足以填补的，需要一个开源社区才行。要填补好这个空缺，需要先让用户意识到其重要性，这也是蚂蚁金服开源 SQLFlow 的意图之一。\nSQLFlow 位于 AI 软件系统生态的最顶端，最接近用户，它也位于数据和数据流软件生态之上。\n其实，将 SQL 和 AI 连接起来这个想法并非 SQLFlow 原创。谷歌于 2018 年年中发布的 BigQueryML 同样旨在“让数据科学家和分析师只用 SQL 语言就可以实现流行的机器学习功能并执行预测分析”。除了 Google 的 BigQueryML，微软基于 SQL Server 的 AI 扩展，以及 Teradata 的 SQL for DL 同样旨在连接 SQL 和 AI，让人工智能的应用变得像 SQL 一样简单。而 SQLFlow 与上述各个系统最根本的差异在于：SQLFlow 是开源的，以上系统都不是。\n开发 SQLFlow 的初衷 蚂蚁金服和很多互联网公司一样，不同产品背后有很多功能都依赖于 AI，比如用户信用的评估就是一套预测模型。到目前为止，每一个这样的功能的实现，都依赖一个工程师团队开发多个子系统——读取数据库或者在线日志流、这两类数据的 join、各种数据筛选、数据到模型输入（常说的 features）的映射、训练模型、用训练好的模型来做预测。整个过程下来耗时往往以月计，如果加班加点放弃写 unit test 代码，可能缩短到以周记。\n以上问题正是 SQLFlow 系统希望替工程师们解决的问题。蚂蚁金服拥有数千数据分析师，他们日常工作用的就是 SQL 语言。虽然数据分析师在互联网行业往往不像用 Python、Java、C++ 的工程师那样醒目，但是在很多有面向商业伙伴的业务的公司里，比如 LinkedIn，他们的贡献和人数都能与工程师相匹敌。SQLFlow 最早的初衷，就是希望解决分析师既要操作数据又要使用 AI、往往需要在两个甚至更多的系统之间切换、工作效率低的窘境。\nSQLFlow 旨在大幅提升效率，让上述功能实现所花费的时间进一步缩短到能以日计，甚至以小时计的程度。\n要达到这样的效率，必须有一种效率极高的描述工作意图的方式。SQL 是一种典型的描述意图，而不描述过程的编程语言。用户可以说我要 join 两个表，但是不需要写循环和构造 hash map 来描述如何 join 两个表。这个特性使得 SQL 能极大地提升开发效率，这正是 SQLFlow 选择扩展 SQL 语法支持 AI 这条思路的原因。\n不过，高效率的背后是更大的工程技术挑战。SQLFlow 需要做到能根据用户的意图，自动生成达到意图的 Python、C++、Go 语言的程序。\nSQLFlow 的架构设计 设计目标 在连接 SQL 和 AI 应用这一方向上，业内已有相关工作。开发者可以使用像 DOT_PRODUCT 这样的运算符在 SQL 中编写简单的机器学习预测（或评分）算法。但是，从训练程序到 SQL 语句需要进行大量的模型参数复制粘贴的工作。目前在一些商业软件中，已经有部分专有 SQL 引擎提供了支持机器学习功能的扩展。\n Microsoft SQL Server：Microsoft SQL Server 支持机器学习服务，可以将 R 或 Python 编写的机器学习程序作为外部脚本运行。 Teradata SQL for DL：Teradata 也提供了 RESTful 服务，可以通过扩展的 SQL SELECT 语法调用。 Google BigQuery：Google BigQuery 通过引入 CREATE MODEL 语句让用 SQL 实现机器学习成为可能。 但上述已有的解决方案都无法解决蚂蚁金服团队的痛点，他们的目标是打造一个完全可扩展的解决方案。\n 这一解决方案应与许多 SQL 引擎都兼容，而不是只能兼容特定版本或类型的 SQL 引擎。 它应该支持复杂的机器学习模型，包括用于深度学习的 TensorFlow 和用于树模型的 XGBoost。 能够灵活地配置和运行前沿机器学习算法，包括指定特征交叉，无需在 SQL 语句中嵌入 Python 或 R 代码，以及完全集成超参数估计等。 应对上述挑战的关键在于打造一套 SQL 扩展语法。研发团队首先从仅支持 MySQL 和 TensorFlow 的原型开发开始，后续计划支持更多 SQL 引擎和机器学习工具包。\n从 SQL 到机器学习 SQLFlow 可以看作一个翻译器，它把扩展语法的 SQL 程序翻译成一个被称为 submitter 的程序，然后执行。 SQLFlow 提供一个抽象层，把各种 SQL 引擎抽象成一样的。SQLFlow 还提供一个可扩展的机制，使得大家可以插入各种翻译机制，得到基于不同 AI 引擎的 submitter 程序。\nSQLFlow 对 SQL 语法的扩展意图很简单：在 SELECT 语句后面，加上一个扩展语法的 TRAIN 从句，即可实现 AI 模型的训练。或者加上一个 PREDICT 从句即可实现用现有模型做预测。这样的设计大大简化了数据分析师的学习路径。\n此外，SQLFlow 也提供一些基本功能，可以供各种 submitter 翻译插件使用，用来根据数据的特点，推导如何自动地把数据转换成 features。这样用户 …","date":1557903600,"description":"本文整理于 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow 的现场演讲。","dir":"blog/sqlflow-open-source/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fcd6535619144aec695ee9afbf2fc36b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sqlflow-open-source/","publishdate":"2019-05-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sqlflow-open-source/","summary":"5 月 6 日，在 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow，他在演讲中表示：“未来三年，AI","tags":["SQLFlow"],"title":"蚂蚁金服开源机器学习工具 SQLFlow，技术架构独家解读","type":"blog","url":"/sofastack.tech/blog/sqlflow-open-source/","wordcount":5106},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs\n活动时间：5 月 16 日周四晚 7 点\n活动形式：线上直播\n报名方式：https://tech.antfin.com/activities/552\n介绍 | SOFAChannel\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs\n如何自动生成测试用例？\n如何减少测试用例设计过程中的阻力？\n如何进行精细化校验以及用例的高效管理，从而保障代码质量，有效提高测试效率？\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 线上直播第 5 期《给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs》报名开启！\n5 月 16 日周四晚 7 点，围绕蚂蚁金服的多年测试实践的积累与沉淀，自动化测试框架 SOFAActs 核心成员青勤将为大家带来精彩分享，不要错过哦。\nSOFAActs 是基于数据模型驱动测试引擎的的新一代测试框架，它的数据以 YAML 为载体，在此上构建基于数据模型的驱动引擎，适配 TestNg+SOFABoot 的测试上下文环境；支持高效、标准化构建用例，可视化编辑测试数据，精细化校验结果数据和自动清理 DB 数据，可以有效降低人工录入用例数据的成本，同时支持 API 重写提高测试代码的可扩展可复用性，提供特有注解提高测试代码编排的灵活性。\n| 加入 SOFA 钉钉互动群\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n| 点击即可报名\nhttps://tech.antfin.com/activities/552\n议程 19:00-19:05 主持人开场\nSOFAGirl 主持人\n19:05-20:00 给研发工程师的代码质量利器 — 自动化测试框架 SOFAActs\n青勤 蚂蚁金服自动化测试框架 SOFAActs 核心成员\n本期分享大纲：\n 蚂蚁金服接口自动化测试理念 如何接入 SOFAActs 自动化测试框架 SOFAActs 自动化测试框架的基本使用 嘉宾 SOFAGirl 主持人 青勤 蚂蚁金服自动化测试框架 SOFAActs 核心成员 ","date":1557310800,"description":"5 月 16 日周四晚 7 点，线上直播。","dir":"activities/sofa-channel-5/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e000553c2c76f43ed8df5b8e56491a7b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-5/","publishdate":"2019-05-08T10:20:00Z","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-5/","summary":"概要 活动主题：SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs 活动时间：5 月 16 日周四晚 7 点 活动形式：线上直播 报名方","tags":["SOFAChannel","SOFAActs"],"title":"SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs","type":"activities","url":"/sofastack.tech/activities/sofa-channel-5/","wordcount":733},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第一篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft 存储模块分为：\n Log 存储记录 Raft 配置变更和用户提交任务日志； Meta 存储即元信息存储记录 Raft 实现的内部状态； Snapshot 存储用于存放用户的状态机 Snapshot 及元信息。 本文将围绕日志存储，元信息存储以及快照存储等方面剖析 SOFAJRaft 存储模块原理，阐述如何解决 Raft 协议存储问题以及存储模块实现：\n Raft 配置变更和用户提交任务日志如何存储？如何调用管理日志存储？ SOFAJRaft Server 节点 Node 是如何存储 Raft 内部配置？ Raft 状态机快照 Snapshot 机制如何实现？如何存储安装镜像？ 日志存储 Log 存储，记录 Raft 配置变更和用户提交任务的日志，把日志从 Leader 复制到其他节点上面。\n LogStorage 是日志存储实现，默认实现基于 RocksDB 存储，通过 LogStorage 接口扩展自定义日志存储实现； LogManager 负责调用底层日志存储 LogStorage，针对日志存储调用进行缓存、批量提交、必要的检查和优化。 LogStorage 存储实现 LogStorage 日志存储实现，定义 Raft 分组节点 Node 的 Log 存储模块核心 API 接口包括：\n 返回日志里的首/末个日志索引； 按照日志索引获取 Log Entry 及其任期； 把单个/批量 Log Entry 添加到日志存储； 从 Log 存储头部/末尾删除日志； 删除所有现有日志，重置下任日志索引。 Log Index 提交到 Raft Group 中的任务序列化为日志存储，每条日志一个编号，在整个 Raft Group 内单调递增并复制到每个 Raft 节点。LogStorage 日志存储实现接口定义入口：\ncom.alipay.sofa.jraft.storage.LogStorage RocksDBLogStorage 基于 RocksDB 实现 Log Structured Merge Tree 简称 LSM ，把一颗大树拆分成 N 棵小树，数据首先写入内存，内存里构建一颗有序小树，随着小树越来越大，内存的小树 Flush 到磁盘，磁盘中的树定期做合并操作合并成一棵大树以优化读性能，通过把磁盘的随机写转化为顺序写提高写性能，RocksDB 就是基于 LSM-Tree 数据结构使用 C++ 编写的嵌入式 KV 存储引擎，其键值均允许使用二进制流。RocksDB 按顺序组织所有数据，通用操作包括 get(key), put(key), delete(Key) 以及 newIterator()。RocksDB 有三种基本的数据结构：memtable，sstfile 以及 logfile。memtable 是一种内存数据结构\u0026amp;ndash;所有写入请求都会进入 memtable，然后选择性进入 logfile。logfile 是一种有序写存储结构，当 memtable 被填满的时候被刷到 sstfile 文件并存储起来，然后相关的 logfile 在之后被安全地删除。sstfile 内的数据都是排序好的，以便于根据 key 快速搜索。\nLogStorage 默认实现 RocksDBLogStorage 是基于 RocksDB 存储日志，初始化日志存储 StorageFactory 根据 Raft节点日志存储路径和 Raft 内部实现是否调用 fsync 配置默认创建 RocksDBLogStorage 日志存储。基于 RocksDB 存储实现 RocksDBLogStorage 核心操作包括：\n init()：创建 RocksDB 配置选项调用 RocksDB#open() 方法构建 RocksDB 实例，添加 default 默认列族及其配置选项获取列族处理器，通过 newIterator() 生成 RocksDB 迭代器遍历 KeyValue 数据检查 Value 类型加载 Raft 配置变更到配置管理器 ConfigurationManager。RocksDB 引入列族 ColumnFamily 概念，所谓列族是指一系列 KeyValue 组成的数据集，RocksDB 读写操作需要指定列族，创建 RocksDB 默认构建命名为default 的列族。 shutdown()：首先关闭列族处理器以及 RocksDB 实例，其次遍历列族配置选项执行关闭操作，接着关闭RocksDB 配置选项，最后清除强引用以达到 Help GC 垃圾回收 RocksDB 实例及其配置选项对象。 getFirstLogIndex()：基于处理器 defaultHandle 和读选项 totalOrderReadOptions 方法构建 RocksDB 迭代器 RocksIterator，检查是否加载过日志里第一个日志索引，未加载需调用 seekToFirst() 方法获取缓存 RocksDB 存储日志数据的第一个日志索引。 getLastLogIndex()：基于处理器 defaultHandle 和读选项 totalOrderReadOptions 构建 RocksDB 迭代器 RocksIterator，调用 seekToLast() 方法返回 RocksDB 存储日志记录的最后一个日志索引。 getEntry(index)：基于处理器 defaultHandle 和指定日志索引调用 RocksDB#get() 操作返回 RocksDB 索引位置日志 LogEntry。 getTerm(index)：基于处理器 defaultHandle 和指定日志索引调用 RocksDB#get() 操作获取 RocksDB 索引位置日志并且返回其 LogEntry 的任期。 appendEntry(entry)：检查日志 LogEntry 类型是否为配置变更，配置变更类型调用 RocksDB#write() 方法执行批量写入，用户提交任务的日志基于处理器 defaultHandle 和 LogEntry 对象调 …","date":1557066600,"description":"本文为《剖析 | SOFAJRaft 实现原理》第一篇，本篇作者米麒麟，来自陆金所。。","dir":"blog/sofa-jraft-algorithm-storage-module-deep-dive/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b48c76bf76b0c77d11af1a6265c9b78b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","publishdate":"2019-05-05T14:30:00Z","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 实现原理 - 生产级 Raft 算法库存储模块剖析","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","wordcount":6384},{"author":"卫恒","categories":"SOFADashboard","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 为了建设更完整的 SOFAStack 微服务体系，我们计划发起 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。欢迎共建~ SOFADashboard：https://github.com/sofastack/sofa-dashboard  背景 从 2018 年 4 月 19 日宣布开源至今，SOFAStack 目前已经开源了包括 SOFABoot、 SOFARPC、SOFALookout、SOFATracer、SOFARegistry 等在内的一系列微服务相关的项目，并投入分布式事务 Seata 进行重要贡献。随着 SOFAStack 架构体系的不断丰富和完善，外部对于 SOFAStack 的管控平台的需求也愈加强烈。\n由于 SOFAStack 内部的管控平台依赖众多的内部基础设施，为了建设更完整的 SOFAStack 微服务体系，我们计划发起全新的 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。\n能力大图 SOFADashboard 作为一站式 SOFAStack 管控台，希望对 SOFAStack 各个组件的使用等进行统一管理。为此我们为 SOFADashboard 规划一版能力图，包含了微服务里的一些能力点，例如应用信息管理、服务治理、配置管控、动态模块等等。见下图所示：\n每个能力点对应的实现我们都做了一层抽象。例如服务查看需要从注册中心获取数据，我们封装了一层服务列表获取接口，底层可以是从 Zookeeper 或者 SOFARegistry 等不同的注册中心实现读取服务列表。\n技术栈选择 为了最大限度的降低开发成本、部署成本及运维成本，SOFADashboard 会基于开源社区优秀的产品来进行开发构建。经过讨论，最终选择社区主流的前后端分离思路，具体的组件包括：\n Ant Design：基于 React封装的一套 Ant Design 的组件库，主要用于研发企业级中后台产品。从产品成熟度、社区活跃度、框架上手难易程度等各个方面均有很好的表现。 SOFABoot：蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。 MyBatis：Mybatis 相对于 JPA 来说，上手难度略低，JPA 更加倾向于结合 DDD 使用(业务越复杂，对于DDD 的需求越高)；对于简单的增删改查业务操作，Mybatis 相对来说更灵活和可控。 v1.0 发布 4 月 30 日，我们上传了第一个 SOFADashboard 版本，主要能力包括：应用信息、服务查看、动态模块管控等。\n目前演示地址：http://dashboard.dev.sofastack.tech:8000/ 详细设计图 基础依赖 从架构图中可以看到，目前 SOFADashboard 中的服务治理、SOFAArk 管控等需要依赖于 Zookeeper 和 MySQL；它们承担的解决如下：\n 外部依赖 作用 备注 Zookeeper 注册中心 SOFARPC 服务治理 配置推送 SOFAArk 管控 MySql 资源存储 注册的 ark-biz 信息，插件与应用的关联信息，插件版本信息等 应用面板 SOFADashboard 支持查看应用的 IP、端口、健康检查状态等基本信息，此功能依赖 SOFADashboard client。SOFADashboard client 用于向 SOFADashboard 服务端注册 IP、端口、健康检查状态等应用基本信息；SOFADashboard client 并非是直接通过 API 调用的方式将自身应用信息直接注册到 SOFADashboard 服务端 ，而是借助于 Zookeeper 来完成。\n客户端向 Zookeeper 中如上图所示的节点中写入数据，每一个 ip:port 节点代表一个应用实例，应用本身信息将写入当前节点的 data 中。\n如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可，具体使用参考 SOFADashboard client 快速开始 。\n服务治理 SOFADashboard 服务治理是对 SOFARPC 的服务进行管理，服务治理管控台部分，主要包括基于服务名查询和服务信息列表展示两个基础能力。在服务治理管控台界面，可以直观的看到当前服务的一些基本元数据信息：\n当点击 服务 ID 对应的超链接时，会进入到当前服务的详情页；服务提供者详情页中，可以看到当前服务所有的提供方信息列表，每个 item 行对应一个服务提供方实例，通过此界面可以快速查看服务的 providers 信息。\n服务消费者详情页中，可以看到当前服务所有的消费方信息列表。\nSOFAArk 管控 SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAArk 管控是 SOFADashboard 针对 API 管控的一种实现。通过面向 Zookeeper 进行命令的推送和命令的解析执行。SOFAArk 管控主要包括以下功能：\n 插件注册 将 ark-biz 插件注册到 SOFADashboard，作为基础数据，统一管控。\n插件基本信息录入：\n插件列表：\n 关联应用 将 ark-biz 插件与宿主应用进行绑定，此关联信息在 SOFAArk 多应用（模块）合并部署中作为重要的基础信息存在。在后续的操作中，可以通过此关联关系查看到某个插件下挂载的应用信息。\n 插件详情 通过插件详情页，可以看下当前 ark-biz 插件下所有关联的宿主应用信息，以及宿主应用中的 ark-biz 状态信息，插件详情页中，可以查看所有关联此插件的应用中，插件的状态信息。\n 命令推送 命令推送是 SOFADashboard 中提供 SOFAArk 管控的核心能力，通过面向 Zookeeper 编程的方式，将指令信息传递给各个宿主应用中的 ark-biz 模块，ark-biz 在接收到相关指令之后再进行相应的行为，如安装、切换、卸载等。\n可以针对应用维度、IP 维度推送一些指令，比如 install、uninstall 等等，当这些命令被写入到 Zookeeper 的某个节点上时，所有监听此节点的宿主应用均会解析此指令，并进行相关的操作。\n基于 IP 维度推送如图例所示，每个应用实例表单默认会有对应的操作，可以通过展示的命令按钮操作当前实例行为：\n点击 安装按钮，延迟 1~1.5s 之后 界面将会刷 …","date":1557039600,"description":"为了建设更完整的 SOFAStack 微服务体系，我们计划发起 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。欢迎共建~","dir":"blog/sofa-dashboard-open-source/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f9a78639fd427da4c3ea19d32e8420e7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-dashboard-open-source/","publishdate":"2019-05-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-dashboard-open-source/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 为了建设更完整","tags":["SOFADashboard"],"title":"SOFADashboard 启动开源共建 | SOFAStack 一站式管控平台","type":"blog","url":"/sofastack.tech/blog/sofa-dashboard-open-source/","wordcount":2602},{"author":"老王","categories":"SOFAStack","content":" 本文转自 Linux 中国\n谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。\u0026amp;ndash; 老王\n二月初春，在西子湖畔的细雨中，我拜访了蚂蚁金服中间件团队，和 SOFA 技术负责人鲁直做了一次深入交谈，更妙的是，鲁直也是负责 SOFA 开源事务推进的人，而这样一个切实践行开放核心模式的开源项目，也正是我非常感兴趣的。\n两个技术人的谈话，自然是朴实而直白的，话题主要围绕着 SOFA 和开源主题展开，希望也能一样引起同是技术人的你的共鸣。\n 人物介绍 受访者：鲁直，蚂蚁金服 SOFA 开源负责人。 采访者：老王，开源布道人，有 20 年互联网从业经历的技术老兵。\n 虽然我和鲁直在微信上已经联系很久了，但这还是第一次见面。交谈中，我了解到鲁直是 2009 年加入阿里巴巴工作，已经有十年了。刚开始是在 1688.COM 做业务系统，对中间件技术非常感兴趣，也会经常研究各种中间件的实现和功能。后来在 2013年时，为了更深入地学习研究中间件框架，转到了蚂蚁金服中间件团队，从那个时候开始就一直在做 SOFA。\n目前鲁直在 SOFA 的团队主要负责的工作包括几个部分。其中一个主要部分就是 SOFA 开源相关的工作。SOFA 的产品体系非常广，包括已经对外开源的部分、内部整个微服务体系，以及 SOFA 框架等等——而这些开源相关的工作主要是由鲁直负责推动的。\n当然，作为技术负责人，鲁直既要带技术团队也要做技术工作。谈及这一点，鲁直说：\n“我觉得做技术管理，跟普通的管理不太一样，因为技术管理最重要的一个点是除了管理之外，还要保持一定的技术判断力和敏锐度。对一些新技术，包括团队中遇到一些重大的技术问题，你都要有一些方向性的判断。虽然最后不一定是你具体解决的，但是在整个团队的技术攻坚和技术选型上，要一起确立方向。”\n我以前也做过十余年的技术管理，我很能够感受这种情况，重大问题技术负责人更要迎难而上。\nSOFA 5 落子 Service Mesh 就我了解的情况，现在 SOFA 已经发展到了 SOFA5 了。在 SOFA4 阶段，主要的任务是将开源体系捋清楚了，然后开始按步骤地开源；到现在发展到了 SOFA5。我想知道从 SOFA4 发展到 SOFA5，是什么让蚂蚁金服中间件团队判断 SOFA4 的阶段性目标已经达成，可以迈进到新的 SOFA5 阶段了呢？\n “从整个业界趋势上来讲，SOFA4 的架构相对来说还是偏传统一些，更多是对我们之前的技术框架的整理和梳理。在这个阶段，SOFA 的代码经过了非常多的优化和重构，才达到了对外开源的要求，从而 SOFA 走上了开源核心的模式，逐步分阶段的将各个部分进行了开源。”鲁直讲到，“但是，从我们对业界的整体判断上来说，未来无疑是云的时代，所以说要考虑怎么让所有的业务系统能够提供云的能力，比如说 Serverless。”\n接着这个话题，鲁直讲了他对云计算的理解：“一方面云计算肯定要为整个业务的发展提供更加方便的基础资源，可以不用去关心底层的基础设施。Serverless 字面的意思就是说‘无服务器’——我不用关心服务器怎么来的，不用关心基础设施，只要关心业务代码就可以了。那反过来对于云服务商来说，经过了这一层抽象，其资源利用率会更高，可以有更多的利润空间，这是一个双赢的局面。对于用户来讲，这种好处是实实在在的，可以更少关注基础设施，只关心代码就可以了。”\n  “我们希望在 SOFA5 的方向上，在这个新的迭代中，去让业务——包括让未来我们开源出来各种功能、各样服务模式——都更多地去关心自己的业务代码，而不用再过多地关心基础设施。”鲁直说。\n 在 SOFA5 中，一个重要的方向就是 Service Mesh 这个方向，这将是 SOFA5 中非常重要的特性。鲁直强调了其对 Service Mesh 技术的看好：“我认为 Service Mesh 是迈向未来往前走的非常关键的一步，让业务不用再关心基础设施。通过 Service Mesh，我们可以将很多技术能力直接放到基础设施里面，而业务可以不用感知到这一层。原来可能需要花几个小时或者更多的时间解决的基础设施问题，现在可以通过 Service Mesh 解决掉。”\n“目前我们我们已经在生产环境中应用了 Service Mesh。我们在这方面有非常大的决心，我们希望能够在今年，在更大的范围中去落地 Service Mesh。当前这个阶段更聚焦在这种技术的内部落地上，希望用好了，再给社区做更多的贡献。”\n Service Mesh 这个词最早是由开发 Linkerd 的 Buoyant 公司于 2016 年提出的，随着 Linkerd 的传入，Service Mesh 也进入国内技术社区的视野。Service Mesh 也被翻译为“服务网格”。Linkerd 则是业界第一个 Service Mesh。 Service Mesh 是一个基础设施层，用于处理服务间通信，负责实现请求的可靠传递。在实践中，服务网格通常实现为轻量级网络代理，通常与应用程序部署在一起，但是对应用程序透明。\nService Mesh 的部署模型，有两种情况： ◈ 对于一个简单请求，作为请求发起者的客户端应用实例，会首先用简单方式将请求发送到本地的 Service Mesh 实例。这是两个独立进程，它们之间是远程调用。Service Mesh 会完成完整的服务间调用流程，如服务发现负载均衡，最后将请求发送给目标服务。这就是 Sidecar，它在原有的客户端和服务端之间加多了一个代理。 ◈ 多个服务调用的情况，Service Mesh 出现在所有的服务的下面，这一层被称之为服务间通讯专用基础设施层。Service Mesh 会接管整个网络，把所有的请求在服务之间做转发。在这种情况下，上面的服务不再负责传递请求的具体逻辑，只负责完成业务处理。服务间通讯的环节就从应用里面剥离出来，呈现出一个抽象层。\n如果有大量的服务，Sidecar 之间的连接就会形成一个网络，这个就是服务网格名字的由来。\n “我们将以 Service Mesh 为跳板再往前走。”鲁直表示，“Serverless 更多的还是应该聚焦在其字面本身，其含义就是‘无服务器’，后面的技术都是为了让无服务器承载具体的业务。”\nServerless 这个概念虽然提出来已经有几年了，目前 AWS 在 Serverless 和 FaaS 方面处于比较前沿的位置，但是在国内，Serverless、FaaS 这些技术的发展还是相对比较滞后。\n鲁直指出，“我觉得 Serverless 想要成功，还是要从覆盖业务的整个广度上打开，否则可能还是停留在 FaaS 上，那场景就比较受限。”\n Service Mesh 将是微服务的下一个时代，关于它还在持续进行理论研究和实践探索。\n 鲁直说：“坦白来讲，我觉得 istio 的理念非常好，但是在整个工程设计上，如果放到蚂蚁金服这样体量较大的环境里面，可能跑起来还需要做一些工作。我们希望今年 Service Mesh 在蚂蚁金服有了更大规模落地之后，可以把我们在 Service Mesh 方面的一些实践经验用到产品环境的工程中去实践，然后贡献出去。目前更多的一些工作，是将整个 …","date":1556607600,"description":"谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。-- 老王","dir":"blog/antfin-middleware-open-source-key-figure-luzhi/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6779f59b05648131b0d635a71cd95d0d","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","publishdate":"2019-04-30T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","summary":"本文转自 Linux 中国 谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。\u0026ndash; 老王 二月初春，在西子湖畔的细雨中，我拜访了蚂蚁金服中间","tags":["SOFAStack"],"title":"对话鲁直：蚂蚁金服中间件的开源头羊 | 穿山甲专访","type":"blog","url":"/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","wordcount":5979},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nGitHub 地址：https://github.com/sofastack/sofa-jraft\n之前，我们有一篇介绍 SOFAJRaft 的文章，可在文末获得链接，延续这个内容，今天的演讲分为三部分，先简要介绍 Raft 算法，然后介绍 SOFAJRaft 的设计，最后说说它的优化。\n分享嘉宾：力鲲 蚂蚁金服 SOFAJRaft 核心成员\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务。 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\nLeader 选举 复制状态机集群在利用 Raft 算法保证一致性时，要做的第一件事情就是 Leader 选举。在讲 Leader 选举之前我们先要说一个重要的概念：Term。Term 用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求；\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳；\n 当然了，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。\n当选举 Leader 成功之后，整个集群就可以向外提供正常读写服务了，如图所示，集群由一个 Leader 两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳或者把 Log 复制给 Follower。\nLog 复制 下面我们就详细说一下 Log 复制。我们之前已经说了 Log 就是 Client 发送给复制状态机的一系列命令。这里我们再举例解释一下 Log，比如我们的复制状态机要实现的是一个银行账户系统，那么这个 Log 就可以是 Client 发给账户系统的一条存钱的命令，比如“存 100 元钱”。\nLeader 与 Follower 之间的日志复制是共识算法运用于复制状态机的重要目的，在 Raft 算法中 Log 由 TermId、LogIndex、LogValue 这三要素构成，在这张图上每一个小格代表一个 Log。当 Leader 在向 Follower 复制 Log 的时候，Follower 还需要对收到的 Log 做检查，以确保这些 Log 能和本地已有的 Log 保持连续。我们之前说了，Raft 算法是要严格保证 Log 的连续性的，所以 Follower 会拒绝无法和本地已有 Log 保持连续的复制请求，那么这种情况下就需要走 Log 恢复的流程。总之，Log 复制的目的就是要让所有的 Server 上的 Log 无论在内容上还是在顺序上都要保持完全一致，这样才能保证所有状态机执行结果一致。\n目前已经有一些很优秀的对 Raft 的实现，比如 C++ 写的 braft，Go 写的 etcd，Rust 写的 TiKV。当然了，SOFAJRaft 并不是 Raft 算法的第一个 Java 实现，在我们之前已经有了很多项目。但是经过我们的评估，觉得目前还是没有一个 Raft 的 Java 实现库类能够满足蚂蚁生产环境的要求，这也是我们去写 SOFAJRaft 的主要原因。\nSOFAJRaft 介绍 接下来我们介绍 SOFAJRaft。 SOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。从去年 3 月开发到今年 2 月完成，并在今年 3 月开源。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统，目前使用案例有 RheaKV，这是 SOFAJRaft 中自带的一个分布式 KV 存储，还有今天开源的 SOFA 服务注册中心中的元信息管理模块也是用到了 SOFAJRaft，除此之外还有一些内部的项目也有使用，但是因为没有开源，所以就不再详述了。\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依 …","date":1556202600,"description":"本文根据 SOFAChannel#4 直播分享整理，主题：SOFAJRaft 详解。","dir":"blog/sofa-jraft-deep-dive/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f2d4559ece4184ef09b96899a1aeb900","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-deep-dive/","publishdate":"2019-04-25T14:30:00Z","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-jraft-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFAJRaft","剖析 | SOFAJRaft 实现原理","SOFALab"],"title":"蚂蚁金服开源 SOFAJRaft 详解| 生产级高性能 Java 实现","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-deep-dive/","wordcount":5688},{"author":"琪祥","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。 GitHub 地址：https://github.com/sofastack/sofa-registry \n 3 月 31 日，蚂蚁金服正式开源了内部演进了近 10 年的注册中心产品-SOFARegistry。先前的文章介绍了 SOFARegistry 的演进之路，而本文主要对 SOFARegistry 整体架构设计进行剖析，并着重介绍一些关键的设计特点，期望能帮助读者对 SOFARegistry 有更直接的认识。\n如有兴趣，也欢迎加入《剖析 | SOFARegistry 实现原理》系列的共建，认领列表见文末。\n服务注册中心是什么 不可免俗地，先介绍一下服务注册中心的概念。对此概念已经了解的读者，可选择跳过本节。\n如上图，服务注册中心最常见的应用场景是用于 RPC 调用的服务寻址，在 RPC 远程过程调用中，存在 2 个角色，一个服务发布者（Publisher）、另一个是服务订阅者（Subscriber）。Publisher 需要把服务注册到服务注册中心（Registry），发布的内容通常是该 Publisher 的 IP 地址、端口、调用方式 （协议、序列化方式）等。而 Subscriber 在第一次调用服务时，会通过 Registry 找到相应的服务的 IP 地址列表，通过负载均衡算法从 IP 列表中取一个服务提供者的服务器调用服务。同时 Subscriber 会将 Publisher 的服务列表数据缓存到本地，供后续使用。当 Subscriber 后续再调用 Publisher 时，优先使用缓存的地址列表，不需要再去请求Registry。\n如上图，Subscriber 还需要能感知到 Publisher 的动态变化。比如当有 Publisher 服务下线时， Registry 会将其摘除，随后 Subscriber 感知到新的服务地址列表后，不会再调用该已下线的 Publisher。同理，当有新的 Publisher 上线时，Subscriber 也会感知到这个新的 Publisher。\n初步认识 在理解了常见的服务注册中心的概念之后，我们来看看蚂蚁金服的 SOFARegistry 长什么样子。如上图，SOFARegistry 包含 4 个角色：\n Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\n SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\n DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。\n MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n产品特点 （图片改编自 https://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products ）\n首先放一张常见的服务注册中心的特性对比，可以看出，在这些 Feature 方面，SOFARegistry 并不占任何优势。那么，我们为什么还开源这样的一个系统？SOFARegistry 开源的优势是什么？下面将着重介绍 SOFARegistry 的特点。\n支持海量数据 大部分的服务注册中心系统，每台服务器都是存储着全量的服务注册数据，服务器之间依靠一致性协议（如 Paxos/Raft/2PC 等）实现数据的复制，或者只保证最终一致性的异步数据复制。“每台服务器都存储着全量的服务注册数据”，在一般规模下是没问题的。但是在蚂蚁金服庞大的业务规模下，服务注册的数据总量早就超过了单台服务器的容量瓶颈。\nSOFARegistry 基于一致性 Hash 做了数据分片，每台 DataServer 只存储一部分的分片数据，随数据规模的增长，只要扩容 DataServer 服务器即可。这是相对服务发现领域的其他竞品来说最大的特点，详细介绍见后面《如何支持海量数据》一节。\n支持海量客户端 SOFARegistry 集群内部使用分层的架构，分别为连接会话层（SessionServer）和数据存储层（DataServer）。SessionServer 功能很纯粹，只负责跟 Client 打交道，SessionServer 之间没有任何通信或数据复制，所以随着业务规模（即 Client 数量）的增长，SessionServer 可以很轻量地扩容，不会对集群造成额外负担。\n相比之下，其他大多数的服务发现组件，如 eureka，每台服务器都存储着全量的数据，依靠 eurekaServer 之间的数据复制来传播到整个集群，所以每扩容 1 台 eurekaServer，集群内部相互复制的数据量就会增多一份。再如 Zookeeper 和 Etcd 等强一致性的系统，它们的复制协议（Zab/Raft）要求所有写操作被复制到大多数服务器后才能返回成功，那么增加服务器还会影响写操作的效率。\n秒级的服务上下线通知 对于服务的上下线变化，SOFARegistry 使用推送机制，快速地实现端到端的传达。详细介绍见后面《秒级服务上下线通知》一节。\n接下来，我将围绕这些特点，讲解 SOFARegistry 的关键架构设计原理。\n高可用 各个角色都有 failover 机制：\n MetaServer 集群部署，内部基于 Raft 协议选举和复制，只要不超过 1\u0026amp;frasl;2 节点宕机，就可以对外服务。 DataServer 集群部署，基于一致性 Hash 承担不同的数据分片，数据分片拥有多个副本，一个主副本和多个备副本。如果 DataServer 宕机，MetaServer 能感知，并通知所有 DataServer 和 SessionServer，数据分片可 failover 到其他副本，同时 DataServer 集群内部会进行分片数据的迁移。 SessionServer 集群部署，任何一台 SessionServer 宕机时 Client 会自动 failover 到其他 SessionServer，并且 Client …","date":1556175600,"description":"本文为《剖析 | SOFARegistry 框架》第一篇，本篇作者琪祥。","dir":"blog/sofa-registry-introduction/","fuzzywordcount":11100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"04394de7d7b0ecba5303baa6949a40d4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-introduction/","publishdate":"2019-04-25T15:00:00+08:00","readingtime":23,"relpermalink":"/sofastack.tech/blog/sofa-registry-introduction/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"海量数据下的注册中心 - SOFARegistry 架构介绍","type":"blog","url":"/sofastack.tech/blog/sofa-registry-introduction/","wordcount":11079},{"author":"觉生","categories":"Seata","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。 Seata：https://github.com/seata/seata 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23127468，不错过每场直播。\n 2019 年 3 月，蚂蚁金服加入分布式事务 Seata 的社区共建中，并贡献其 TCC 模式。本期是 SOFAChannel 第四期，主题：分布式事务 Seata TCC 模式深度解析，本文根据觉生的直播整理。\n大家晚上好，我是 Seata Committer 觉生，来自蚂蚁金服数据中间件团队。今天的内容主要分为以下四个部分：\n Seata TCC 模式的原理解析； 从 TCC 的业务模型与并发控制分享如何设计一个 TCC 接口，并且适配 TCC 模型； 如何控制异常； 性能优化，使得 TCC 模式能够满足更高的业务需求。 1、 Seata 的 TCC 模式 1.1 服务化拆分 下面我们就进入第一个主题，Seata 的 TCC 模式。蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个系统中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，而网络、机器等不可靠，数据一致性的问题很容易出现，与可扩展性、高可用容灾等要求并肩成为金融 IT 架构支撑业务转型升级的最大挑战之一。\n从图中可以看到，从单系统到微服务转变，其实是一个资源横向扩展的过程，资源的横向扩展是指当单台机器达到资源性能瓶颈，无法满足业务增长需求时，就需要横向扩展资源，形成集群。通过横向扩展资源，提升非热点数据的并发性能，这对于大体量的互联网产品来说，是至关重要的。服务的拆分，也可以认为是资源的横向扩展，只不过方向不同而已。\n资源横向扩展可能沿着两个方向发展，包括业务拆分和数据分片：\n 业务拆分。根据功能对数据进行分组，并将不同的微服务分布在多个不同的数据库上，这实际上就是 SOA 架构下的服务化。业务拆分就是把业务逻辑从一个单系统拆分到多个微服务中。\n 数据分片。在微服务内部将数据拆分到多个数据库上，为横向扩展增加一个新的维度。数据分片就是把一个微服务下的单个 DB 拆分成多个 DB，具备一个 Sharding 的功能。通过这样的拆解，相当于一种资源的横向扩展，从而使得整个架构可以承载更高的吞吐。\n 横向扩展的两种方法可以同时进行运用：交易、支付与账务三个不同微服务可以存储在不同的数据库中。另外，每个微服务内根据其业务量可以再拆分到多个数据库中，各微服务可以相互独立地进行扩展。\nSeata 关注的就是微服务架构下的数据一致性问题，是一整套的分布式事务解决方案。Seata 框架包含两种模式，一种是 AT 模式。AT 模式主要从数据分片的角度，关注多 DB 访问的数据一致性，当然也包括多服务下的多 DB 数据访问一致性问题。\n另外一个就是 TCC 模式，TCC 模式主要关注业务拆分，在按照业务横向扩展资源时，解决微服务间调用的一致性问题，保证读资源访问的事务属性。\n今天我们主要讲的就是TCC模式。在讲 TCC 之前，我们先回顾一下 AT 模式，这样有助于我们理解后面的 TCC 模式。\n1.2. AT 模式 对于 AT 模式，之前其他同学已经分享过很多次，大家也应该比较熟悉了。AT 模式下，把每个数据库被当做是一个 Resource，Seata 里称为 DataSource Resource。业务通过 JDBC 标准接口访问数据库资源时，Seata 框架会对所有请求进行拦截，做一些操作。每个本地事务提交时，Seata RM（Resource Manager，资源管理器） 都会向 TC（Transaction Coordinator，事务协调器） 注册一个分支事务。当请求链路调用完成后，发起方通知 TC 提交或回滚分布式事务，进入二阶段调用流程。此时，TC 会根据之前注册的分支事务回调到对应参与者去执行对应资源的第二阶段。TC 是怎么找到分支事务与资源的对应关系呢？每个资源都有一个全局唯一的资源 ID，并且在初始化时用该 ID 向 TC 注册资源。在运行时，每个分支事务的注册都会带上其资源 ID。这样 TC 就能在二阶段调用时正确找到对应的资源。\n这就是我们的 AT 模式。简单总结一下，就是把每个数据库当做一个 Resource，在本地事务提交时会去注册一个分支事务。\n1.3 TCC 模式 那么对应到 TCC 模式里，也是一样的，Seata 框架把每组 TCC 接口当做一个 Resource，称为 TCC Resource。这套 TCC 接口可以是 RPC，也以是服务内 JVM 调用。在业务启动时，Seata 框架会自动扫描识别到 TCC 接口的调用方和发布方。如果是 RPC 的话，就是 sofa:reference、sofa:service、dubbo:reference、dubbo:service 等。\n扫描到 TCC 接口的调用方和发布方之后。如果是发布方，会在业务启动时向 TC 注册 TCC Resource，与DataSource Resource 一样，每个资源也会带有一个资源 ID。\n如果是调用方，Seata 框架会给调用方加上切面，与 AT 模式一样，在运行时，该切面会拦截所有对 TCC 接口的调用。每调用一次 Try 接口，切面会先向 TC 注册一个分支事务，然后才去执行原来的 RPC 调用。当请求链路调用完成后，TC 通过分支事务的资源ID回调到正确的参与者去执行对应 TCC 资源的 Confirm 或 Cancel 方法。\n在讲完了整个框架模型以后，大家可能会问 TCC 三个接口怎么实现。因为框架本身很简单，主要是扫描 TCC 接口，注册资源，拦截接口调用，注册分支事务，最后回调二阶段接口。最核心的实际上是 TCC 接口的实现逻辑。下面我将根据蚂蚁金服内部多年的实践来为大家分析怎么实现一个完备的 TCC 接口。\n2、 TCC 业务模型与并发控制 2.1 TCC 设计原则 从 TCC 模型的框架可以发现，TCC 模型的核心在于 TCC 接口的设计。用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。下面我会分享蚂蚁金服内多年的 TCC 应用实践以及在 TCC 设计和实现过程中的注意事项。\n设计一套 TCC 接口最重要的是什么？主要有两点，第一点，需要将操作分成两阶段完成。TCC（Try-Confirm-Cancel）分布式事务模型相对于 XA 等传统模型，其特征在于它不依赖 RM 对分布式事务的支持，而是通过对业务逻辑的分解来实现分布式事务。\nTCC 模型认为对于业务系统中一个特定的业务逻辑 ，其对外提供服务时，必须接受一些不确定性，即对业务逻辑初步操作的调用仅是一个临时性操作，调用它的主业务服务保留了后续的取消权。如果主业务服务认为全局事务应该回滚，它会要求取消之前的临时性操作，这就对应从业 …","date":1556089200,"description":"本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。","dir":"blog/sofa-channel-4-retrospect/","fuzzywordcount":10500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"75094c50f180bcd31d84bc687e4c93e0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-4-retrospect/","publishdate":"2019-04-24T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/sofa-channel-4-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。 Seata：https://","tags":["Seata","SOFAChannel"],"title":"分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-4-retrospect/","wordcount":10459},{"author":"青勤","categories":"SOFAActs","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23195297，不错过每场直播。\n 大家晚上好，我是蚂蚁金服自动化测试框架 SOFAActs 开源核心成员青勤，目前从事测试技术相关的研发工作，今晚将由我来给大家分享交流自动化测试框架 SOFAActs 的基本原理和使用，今天的内容主要分为以下四个章节：\n 项目介绍 SOFAActs 接入 功能介绍与使用 升阶功能使用 欢迎大家 Star 我，SOFAActs：https://github.com/sofastack/sofa-acts\n1 项目介绍 在分享使用操作前，我将引导大家来熟悉下 SOFAActs 的项目背景、基本原理等。\n对于研发质量保障而言，金融系统和金融业务的多样性、复杂性同样也会在测试场景、测试验证和测试流程的复杂程度上得到充分体现。\n譬如，对于包含出参、RPC 调用、DB 变更和异常等多个测试验证点的用例而言，在研发和测试人员维护和验证用例场景的过程中，时常发生业务结果校验遗漏，对我们及早发现和纠错问题造成干扰，进而无法严格保障产品质量。这些问题对研发质量保障提出了很高的挑战，相应的自动化、精细化的白盒测试工具需求日益增长，这其中就包括 SOFAActs。\n为了解决上述痛点、满足精细化测试需要，在多年测试实践积累与沉淀下，我们研发了基于模型驱动的 SOFAActs 测试框架，它可以灵活、可扩展的提供一站式用例管理，标准化测试执行和精细化校验。目前 SOFAActs 测试框架逐渐成熟并在蚂蚁金服内部得到广泛应用。\n1.1 项目架构 介绍完背景，我们来看下 SOFAActs 的大体框架，SOFAActs 底层封装并集成适配 SOFABoot 等运行环境。\n在重要的引擎层，SOFAActs 封装了工具类和数据模型，并将测试模式的过程进行了标准化，提供通用测试能力和扩展点。对于有自动化测试经验的同学来讲，测试模式其实并不复杂，这其中有很多工作是可以抽象和固定的，SOFAActs 将这部分内容内聚到引擎层，封装成标准测试流程等，尤其是模型驱动和精细化校验等，从而释放精力，将更多关注点聚焦在待测目标上。\n引擎层之上，是 SOFAActs 提供的可视化用例管理功能，可以一站式的维护测试脚本、测试数据和数据模型，借助可视化编辑器可成倍提高用例管理等等操作效率，整体而言 SOFAActs 围绕模型驱动引擎和可视化编辑器，将测试代码的编写工作量极尽降低，目标聚焦在测试对象上。\n这里我们示例看下，SOFAActs 对测试代码和效率的优化。这里以 Credit 接口为例，业务处理开始之前会检查传参，构造上下文、随后发起业务处理，涉及对三张表的读取或变更，并在数据库事物结束之后，返回业务处理结果。\n 针对这一业务逻辑，这里我们构造一个 Credit 接口的完整测试用例，在代码驱动测试时，它需要一下 9 个步骤，手动准备依赖数据、构造请求参数、执行业务逻辑、校验业务结果以及数据清理等等，人工介入成本居高，尤其当存在多个用例时，测试代码可复用性低，测试效率是难以得到有效提升。而与之对比，在模型驱动测试下，Credit 接口的 SOFAActs 测试脚本会对固有的测试模式进行封装，用例复杂度得到极大精简，众多用例数据可以得到高效的可视化管理。\n1.2 执行原理 在开始使用 SOFAActs 之前，我们来了解一下有关 SOFAActs 执行引擎的运作原理。SOFAActs 框架也提供了非常多的扩展点，如果需要个性化的定义，可以对每一个环节进行扩展。\n上文中已提到过 SOFAActs 执行引擎是对测试模式过程的封装，Setup 方法是引擎入口，用于加载初始化 SOFAActs 运行时的必需资源，如获取数据源。\n以下是主体测试过程：clear、prepare、execute、check 这 4 个方法依次负责环境清理、依赖准备、执行、结果校验等。这些内容是代码驱动测试时需要手写的测试代码和内容，每个测试脚本的完成意味着上面的过程会被我们重复一遍，于是 SOFAActs 将这部分内容进行了封装，实现了最通用基础的功能。\n右侧，我们对高频数据如方法入参、出参、异常和依赖DB数据进行了抽象，给出 SOFAActs 的模型，这是代码驱动转向模型驱动、精细化校验的基础。左侧的数据总线会贯穿每个用例的执行生命周期，即贯穿中间的主体测试过程，如果大家对框架封装的基础功能有自定义需要，可以通过数据总线对 SOFAActs 的对象、方法进行获取、重写，以便更灵活的控制框架行为。当然 SOFAActs 对这些内容作了较好的封装，覆盖了大部分的测试需求，无需大家过度关注。\n以上就是 SOFAActs 的执行原理，接下来我会给大家详细介绍 SOFAActs 的接入和使用。\n2 SOFAActs 接入 SOFAActs 分为两部分，其一是可视化编辑器，在 [SOFAStack 官网上 1 我们可以获取该编辑器的安装包，并通过 IDEA 的插件管理进行安装。其二是 SOFAActs 的基础 jar，它提供了 SOFAActs 用例运行的环境支持，在 test 模块 pom 中添加下列依赖即可，有关 test 模块或者多模块详细内容大家可以参考 [SOFAActs 的快速开始文档 1 。\n3 功能介绍和使用 下面，我们进入 SOFAActs 的功能介绍和使用章节，这部分我将分为三小节展开：一站式构建、SOFAActs 核心的模型驱动以及 SOFAActs 提供的精准校验。\n3.1 一站式构建 一站式构建中，SOFAActs 通过可视化编辑器为我们提供了便捷操作，以帮助一键配置初始化、构建测试脚本与模型，可视化管理用例数据等等。借助可视化编辑器，在整个过程中我们可以替换大部分手工编写代码的工作，进行一站式操作。\n一键初始化\n这里我们示例看下，如何操作一键初始化以及一键初始化做哪些内容。首先一键初始化框架只需要 3 个鼠标点击步骤。在 Package 视图下选中测试模块并右键选择 SOFAActs 功能，一键初始化，输入该应用的应用名称和工程编码格式。在一键初始化完成后，SOFAActs 将会在 test 模块写入 SOFAActs 配置文件，DB 连接配置文件，测试套件配置文件以及创建模型存储目录等。\n acts-config 配置文件是 SOFAActs 的核心配置，提供了测试环境切换、数据库连接切换、冒烟测试以及预跑反填等配置，来开关 SOFAActs 的相关功能；model 目录用于存放对象模型、数据模型，以便对模型进行统一管理；DB 配置文件指明了数据库连接信息，用于生成数据模型时自动填充表结构和模版数据。\n一键生成测试脚本\n在完成配置初始化操作后，我们可以开始第一个用例的编写，SOFAActs 提供了一键测试脚本生成功能。以待测的 getMessage 接口为例，在其方法定义上右键选择 SOFAActs 功能，生成测试用例，在弹出框中检查用例信息，修正无误后点击确定可以生成该 …","date":1556089200,"description":"本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。","dir":"blog/sofa-channel-5-retrospect/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1f088b226caf9430dc6aafb3f248316d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-5-retrospect/","publishdate":"2019-04-24T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-5-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAAc","tags":["SOFAActs","SOFAChannel"],"title":"给研发工程师的代码质量利器 | SOFAChannel#5 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-5-retrospect/","wordcount":5492},{"author":"SOFAStack","categories":"SOFAStack","content":"Hey, SOFAer！有些话想对你说：\n“开源”二字代表的不仅仅是一个项目，更是代表了整个技术社区，代表了隐藏在背后的工程师们。\n很幸运，这一年遇到你们。\n生于蚂蚁金服，经历 12 年的业务锤炼，这是金融级分布式架构 SOFAStack。SOFAStack 的发展受益于开源社区的优秀产品，我们也决定结合我们的实践积累，把这些技术反馈给开源社区。\n于是，2018 年 4 月，SOFAStack 宣布开源，项目地址：https://github.com/alipay 。\n这一年，SOFAStack 逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFABolt、SOFAMosn、SOFAMesh、SOFAJRaft、SOFAActs、SOFARegistry 等组件。2019 年 3 月，蚂蚁金服加入分布式事务 Seata 的社区共建中，并贡献其 TCC 模式。\n这一年，我们获得了 14,000+ Star，超过 100 位贡献者参与，并有超过 30 家企业用户将 SOFAStack 应用在了生产环境上。\n这一年，SOFAStack 团队从电脑屏幕前，走到了开源社区里，与大家讨论并吸纳社区的建议。\n这一年，尝试了很多的“第一次”：第一次与大家编写 SOFALab 源码解析系列文章，第一次做 SOFAChannel 技术直播，第一次组织 SOFAMeetup，第一次在开源技术大会演讲。\n嘿，或许你见过我们紧张的样子。\n这一年，我们得到了太多来自社区的帮助，因为你们，SOFAStack 团队能一直享受“Make something people want”的乐趣。\n这一年，感谢有你。Hey, SOFAer~有些话想对你说：\n戳这里\n","date":1555333200,"description":"这一年，感谢有你。","dir":"blog/sofastack-anniversary-1/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"82d2afd98352ab185691773fcd616233","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-anniversary-1/","publishdate":"2019-04-15T21:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofastack-anniversary-1/","summary":"Hey, SOFAer！有些话想对你说： “开源”二字代表的不仅仅是一个项目，更是代表了整个技术社区，代表了隐藏在背后的工程师们。 很幸运，这一年遇到你","tags":["SOFAStack"],"title":"Hey, SOFAer！有些话想对你说：","type":"blog","url":"/sofastack.tech/blog/sofastack-anniversary-1/","wordcount":639},{"author":"李钊","categories":"Seata","content":" 本文作者李钊，公众号「咖啡拿铁」作者，分布式事务 Seata 社区 Contributor。\n1.关于 Seata 在前不久，我写了一篇关于分布式事务中间件 Fescar 的解析，没过几天 Fescar 团队对其进行了品牌升级，取名为 Seata(Simpe Extensible Autonomous Transcaction Architecture)，而以前的 Fescar 的英文全称为 Fast \u0026amp;amp; EaSy Commit And Rollback。可以看见 Fescar 从名字上来看更加局限于 Commit 和 Rollback，而新的品牌名字 Seata 旨在打造一套一站式分布式事务解决方案。更换名字之后，我对其未来的发展更有信心。\n这里先大概回忆一下 Seata 的整个过程模型：\n TM：事务的发起者。用来告诉 TC，全局事务的开始，提交，回滚。 RM：具体的事务资源，每一个 RM 都会作为一个分支事务注册在 TC。 TC 事务的协调者。也可以看做是 Fescar-server，用于接收我们的事务的注册，提交和回滚。 在之前的文章中对整个角色有个大体的介绍，在这篇文章中我将重点介绍其中的核心角色 TC，也就是事务协调器。\n2.Transaction Coordinator 为什么之前一直强调 TC 是核心呢？那因为 TC 这个角色就好像上帝一样，管控着芸芸众生的 RM 和 TM。如果 TC 一旦不好使，那么 RM 和 TM 一旦出现小问题，那必定会乱的一塌糊涂。所以要想了解 Seata，那么必须要了解他的 TC。\n那么一个优秀的事务协调者应该具备哪些能力呢？我觉得应该有以下几个：\n 正确的协调：能正确的协调 RM 和 TM 接下来应该做什么，做错了应该怎么办，做对了应该怎么办。 高可用：事务协调器在分布式事务中很重要，如果不能保证高可用，那么他也没有存在的必要了。 高性能：事务协调器的性能一定要高，如果事务协调器性能有瓶颈，那么他所管理的 RM 和 TM 会经常遇到超时，从而引起回滚频繁。 高扩展性：这个特点是属于代码层面的，如果是一个优秀的框架，那么需要给使用方很多自定义扩展，比如服务注册/发现，读取配置等等。 下面我也将逐步阐述 Seata 是如何做到上面四点。\n2.1 Seata-Server 的设计 Seata-Server 整体的模块图如上所示：\n Coordinator Core：最下面的模块是事务协调器核心代码，主要用来处理事务协调的逻辑，如是否 Commit、Rollback 等协调活动。 Store：存储模块，用来将我们的数据持久化，防止重启或者宕机数据丢失。 Discover：服务注册/发现模块，用于将 Server 地址暴露给 Client。 Config：用来存储和查找服务端的配置。 Lock：锁模块，用于给 Seata 提供全局锁的功能。 Rpc：用于和其他端通信。 HA-Cluster：高可用集群，目前还没开源。为 Seata 提供可靠的高可用功能。 2.2 Discover 首先来讲讲比较基础的 Discover 模块，又称服务注册/发现模块。我们将 Seata-Server 启动之后，需要将自己的地址暴露给其他使用者，那么就需要这个模块帮忙。\n这个模块有个核心接口 RegistryService，如上图所示：\n register：服务端使用，进行服务注册。 unregister：服务端使用，一般在 JVM 关闭钩子，ShutdownHook 中调用。 subscribe：客户端使用，注册监听事件，用来监听地址的变化。 unsubscribe：客户端使用，取消注册监听事件。 lookup：客户端使用，根据 Key 查找服务地址列表。 close：都可以使用，用于关闭 Register 资源。 如果需要添加自己定义的服务注册/发现，那么实现这个接口即可。截止目前在社区的不断开发推动下，已经有四种服务注册/发现，分别是 redis、zk、nacos、eruka。下面简单介绍下 Nacos 的实现：\n2.2.1 register 接口 step1：校验地址是否合法；\nstep2：获取 Nacos 的 Name 实例，然后将地址注册到当前 Cluster 名称上面。\nunregister 接口类似，这里不做详解。\n2.2.2 lookup 接口 step1：获取当前 clusterName 名字；\nstep2：判断当前 Cluster 是否已经获取过了，如果获取过就从 Map 中取；\nstep3：从 Nacos 拿到地址数据，将其转换成我们所需要的；\nstep4：将我们事件变动的 Listener 注册到 Nacos。\n2.2.3 subscribe 接口 这个接口比较简单，具体分两步：\nstep1：将 Clstuer 和 Listener 添加进 Map 中；\nstep2：向 Nacos 注册。\n2.3 Config 配置模块也是一个比较基础，比较简单的模块。我们需要配置一些常用的参数比如：Netty 的 Select 线程数量，Work 线程数量，Session 允许最大为多少等等，当然这些参数在 Seata 中都有自己的默认设置。\n同样的在 Seata 中也提供了一个接口 Configuration，用来自定义我们需要的获取配置的地方：\n getInt/Long/Boolean/Config()：通过 DataId 来获取对应的值。 putConfig：用于添加配置。 removeConfig：删除一个配置。 add/remove/get ConfigListener：添加/删除/获取 配置监听器，一般用来监听配置的变更。 目前为止有四种方式获取 Config：File（文件获取）、Nacos、Apollo、ZK。在 Seata 中首先需要配置 registry.conf，来配置 conf 的类型。实现 conf 比较简单这里就不深入分析。\n2.4 Store 存储层的实现对于 Seata 是否高性能，是否可靠非常关键。\n如果存储层没有实现好，那么如果发生宕机，在 TC 中正在进行分布式事务处理的数据将会被丢失。既然使用了分布式事务，那么其肯定不能容忍丢失。如果存储层实现好了，但是其性能有很大问题，RM 可能会发生频繁回滚那么其完全无法应对高并发的场景。\n在 Seata 中默认提供了文件方式的存储，下面定义存储的数据为 Session，而 TM 创造的全局事务数据叫 GloabSession，RM 创造的分支事务叫 BranchSession，一个 GloabSession 可以拥有多个 BranchSession。我们的目的就是要将这么多 Session 存储下来。\n在 FileTransactionStoreManager#writeSession 代码中：\n上面的代码主要分为下面几步：\nstep1：生成一个 TransactionWriteFuture。\nstep2：将这个 futureRequest 丢进一个 LinkedBlockingQueue 中。为什么需要将所有数据都丢进队列中呢？当然这里其实也可以用锁来实现，在 …","date":1554793200,"description":"在这篇文章，将重点介绍 Seata 其中的核心角色 TC，也就是事务协调器。","dir":"blog/seata-server-deep-analysis/","fuzzywordcount":6900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3354370f3ca29297c819c279994e0a0d","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-server-deep-analysis/","publishdate":"2019-04-09T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/seata-server-deep-analysis/","summary":"本文作者李钊，公众号「咖啡拿铁」作者，分布式事务 Seata 社区 Contributor。 1.关于 Seata 在前不久，我写了一篇关于分布式事务中间件 Fescar 的解析，没","tags":["Seata"],"title":"深度剖析一站式分布式事务方案 Seata-Server","type":"blog","url":"/sofastack.tech/blog/seata-server-deep-analysis/","wordcount":6831},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 活动时间：4 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 4月初，分布式事务 Fescar 宣布进行品牌升级为 Seata，Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n本期为 SOFAChannel 线上直播第 4 期，将邀请 蚂蚁金服 技术专家 \u0026amp;amp; Seata Committer 觉生 和大家一起探讨 《分布式事务 Seata TCC 模式深度解析》。\n本期分享大纲：\n TCC 模式基本原理解析 分布式事务并发控制解析 分布式事务空回滚与幂等解析 分布式事务防悬挂解析 分布式事务异步化解析 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/462\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 分布式事务 Seata TCC 模式深度解析 觉生 蚂蚁金服 技术专家 / Seata Committer\n本期分享大纲： TCC 模式基本原理解析 分布式事务并发控制解析 分布式事务空回滚与幂等解析 分布式事务防悬挂解析 分布式事务异步化解析 嘉宾 SOFAGirl 主持人 觉生 蚂蚁金服 技术专家 / Seata Committer ","date":1554783000,"description":"4 月 18 日周四晚 7 点，线上直播第 4 期。","dir":"activities/sofa-channel-4/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0e0d4d4a75723cc408567a65aab0c3df","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-4/","publishdate":"2019-04-09T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-4/","summary":"概要 活动主题：SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 活动时间：4 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介","tags":["SOFAChannel","Seata"],"title":"SOFAChannel#4：分布式事务 Seata TCC 模式深度解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-4/","wordcount":551},{"author":"绍辉","categories":"Seata","content":" 上周，分布式事务 Fescar 宣布进行品牌升级：\nThanks, Fescar ❤️，\nHello, Seata 🚀。\nSeata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。\n项目地址：https://github.com/seata/seata\n蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n为了帮助大家理解，分布式事务开源负责人绍辉进行了一次线下分享，详细讲述了分布式事务在蚂蚁金服的发展，希望可以帮助大家理解分布式事务，以下为分享的文字整理版本。\n前言 今天的分享将从以下三个部分展开：分布式事务问题产生的背景、蚂蚁金服分布式事务以及分布式事务 Seata 的 Roadmap。\n分享嘉宾：绍辉 蚂蚁金服 分布式事务开源负责人\n1、分布式事务问题产生的背景 1.1、数据库的水平拆分 蚂蚁金服早期，业务量比较小，单库单表便能满足业务需求；但是随着业务的发展，单库单表数据库逐渐成为瓶颈。为了解决数据库的瓶颈问题，我们对数据库进行了水平拆分。拆分所带来的一个问题就是以前一个数据库上便能完成的写操作现在要跨多个数据库，由此带来了跨库事务问题。\n1.2、业务的服务化拆分 蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个 APP 中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，由此产生了跨服务事务问题。\n1.3、转账案例说明数据一致性问题 数据库的水分拆分以及服务的垂直拆分，所带来的问题是一个业务活动通常要调用多个服务、访问多个数据库才能完成。\n以金融业务场景下的转账场景为例，转账服务要完成以下操作：\n 调用交易系统服务创建交易订单； 调用支付系统记录支付明细； 调用账务系统执行 A 扣钱； 调用账务系统执行 B 加钱。 以上 4 个操作要跨 3 个系统，访问 4 个数据库。而网络、数据库、机器等都具有不可靠性，我们很难保证以上 4 个操作能 100% 全部成功。\n在金融属性的业务中，不允许 A 账户的钱扣了，而 B 账户的钱没有加上的现象出现，所以我们必须想办法保证 1 ~ 4 这四个操作要么全部成功，要么全部失败；所以蚂蚁金服自主研发了分布式事务中间件，解决跨服务、跨数据库的数据一致性问题。\n2、蚂蚁金服分布式事务 2.1、分布式事务理论基础 在介绍蚂蚁金服的分布式事务中间件之前，先介绍一些分布式事务的理论背景。\n 2PC 两阶段提交协议（Two Phase Commitment Protocol）是分布式事务最基本的协议。在两阶段提交协议中，有一个事务管理器和多个资源管理器，事务管理器分两阶段协调资源管理器。在第一阶段，事务管理器询问所有资源管理器准备是否成功。如果所有资源均准备成功，那么在第二阶段事务管理器会要求所有资源管理器执行提交操作；如果任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求所有资源管理器在第二阶段执行回滚操作。通过事务管理器的两阶段协调，最终所有资源管理器要么全部提交，要么全部回滚，最终状态都是一致的。\n TCC 资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现。TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题。TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中。事务管理器分两个阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法，最终所有 TCC 服务要么全部都是提交的、要么全部都是回滚的。\n2.2、蚂蚁金服分布式产品介绍 蚂蚁金服从 2007 年开始做分布式事务，至今已经有 12 年历史。蚂蚁金服的分布式事务最初是采用 TCC 实现的，TCC 模式帮蚂蚁业务解决了各类金融核心场景下的数据一致性问题。\n2007 年我们开始支持双十一，为了满足双十一的高性能需求，我们对分布式事务做了一系列的性能优化。\n2013年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014年，蚂蚁金服分布式事务中间件开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户；在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。\n所以在 2015年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务中间件经过长期演进，目前积累了 TCC、FMT 和 XA 三种模式，具有丰富的应用场景。下面分别介绍这三种模式。\n2.3、TCC 模式 蚂蚁金服的 TCC 模式和前面介绍 TCC 理论中提的 TCC 原理是一致的。不同的是，我们在整个分布式事务执行过程中，会去记录事务日志，一个分布式事务会产生一条主事务记录（对应发起方）和若干分支事务记录（对应 TCC 参与者）。记录事务日志的目的是，当分布式事务执行过程中出现异常中断时，事务恢复服务通过轮询事务日志，找出这个异常中断的事务，补偿执行该异常事务剩余未完成的动作，整个分布式事务的最终状态要么全部提交，要么全部回滚。\nTCC 设计规范和注意事项：\n用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。经过蚂蚁金服多年的 TCC 应用实践，总结如下在 TCC 设计和实现过程中的注意事项：\n1、业务操作分两阶段完成： 接入 TCC 前，业务操作只需要一步就能完成。但是在接入 TCC 之后，需要考虑如何将其分成两个阶段完成：把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户 A 的余额中有 100 元，需要扣除其中 30 元”。\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成两步完成：\n Try 操作：资源的检查和预留。 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交。 在扣款场景下，Confirm 阶段 …","date":1554706800,"description":"本文根据 SOFAMeetup#1 分享整理，详细讲述了分布式事务在蚂蚁金服的发展。","dir":"blog/sofa-meetup-1-seata/","fuzzywordcount":5000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fd2c8c1c6ee4231c6987a1d556ce4089","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-seata/","publishdate":"2019-04-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-seata/","summary":"上周，分布式事务 Fescar 宣布进行品牌升级： Thanks, Fescar ❤️， Hello, Seata 🚀。 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。 项","tags":["Seata","SOFAMeetup"],"title":"蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-seata/","wordcount":4909},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享视频回顾获取方式见文章底部。\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nGitHub 地址：https://github.com/alipay/sofa-jraft\n之前，我们有一篇介绍 SOFAJRaft 的文章，可在文末获得链接，延续这个内容，今天的演讲分为三部分，先简要介绍 Raft 算法，然后介绍 SOFAJRaft 的设计，最后说说它的优化。\n分享嘉宾：力鲲 蚂蚁金服 SOFAJRaft 核心成员\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务。 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\nLeader 选举 复制状态机集群在利用 Raft 算法保证一致性时，要做的第一件事情就是 Leader 选举。在讲 Leader 选举之前我们先要说一个重要的概念：Term。Term 用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求； 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳； 当然了，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。\n当选举 Leader 成功之后，整个集群就可以向外提供正常读写服务了，如图所示，集群由一个 Leader 两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳或者把 Log 复制给 Follower。\nLog 复制 下面我们就详细说一下 Log 复制。我们之前已经说了 Log 就是 Client 发送给复制状态机的一系列命令。这里我们再举例解释一下 Log，比如我们的复制状态机要实现的是一个银行账户系统，那么这个 Log 就可以是 Client 发给账户系统的一条存钱的命令，比如“存 100 元钱”。\nLeader 与 Follower 之间的日志复制是共识算法运用于复制状态机的重要目的，在 Raft 算法中 Log 由 TermId、LogIndex、LogValue 这三要素构成，在这张图上每一个小格代表一个 Log。当 Leader 在向 Follower 复制 Log 的时候，Follower 还需要对收到的 Log 做检查，以确保这些 Log 能和本地已有的 Log 保持连续。我们之前说了，Raft 算法是要严格保证 Log 的连续性的，所以 Follower 会拒绝无法和本地已有 Log 保持连续的复制请求，那么这种情况下就需要走 Log 恢复的流程。总之，Log 复制的目的就是要让所有的 Server 上的 Log 无论在内容上还是在顺序上都要保持完全一致，这样才能保证所有状态机执行结果一致。\n目前已经有一些很优秀的对 Raft 的实现，比如 C++ 写的 braft，Go 写的 etcd，Rust 写的 TiKV。当然了，SOFAJRaft 并不是 Raft 算法的第一个 Java 实现，在我们之前已经有了很多项目。但是经过我们的评估，觉得目前还是没有一个 Raft 的 Java 实现库类能够满足蚂蚁生产环境的要求，这也是我们去写 SOFAJRaft 的主要原因。\nSOFAJRaft 介绍 接下来我们介绍 SOFAJRaft。\nSOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。从去年 3 月开发到今年 2 月完成，并在今年 3 月开源。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统，目前使用案例有 RheaKV，这是 SOFAJRaft 中自带的一个分布式 KV 存储，还有今天开源的 SOFA 服务注册中心中的元信息管理模块也是用到了 SOFAJRaft，除此之外还有一些内部的项目也有使用，但是因为没有开源，所以就不再详述了。\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依然用之前的银 …","date":1554188400,"description":"本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享视频回顾获取方式见文章底部。","dir":"blog/sofa-meetup-1-jraft/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"614c6031770d98ed7d0c23c3276d72ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-jraft/","publishdate":"2019-04-02T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-jraft/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFAJRaft","SOFAMeetup"],"title":"详解蚂蚁金服 SOFAJRaft | 生产级高性能 Java 实现","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-jraft/","wordcount":5507},{"author":"张磊、心贵、临石、徙远、衷源、浔鸣","categories":"Kubernetes","content":" 本文由张磊、心贵、临石、徙远、衷源、浔鸣等同学联合撰写。\nKubernetes 1.14.0 Release 已经于 3 月 25 日正式发布。相信你也已经注意到，相比于1.13 和 1.12 版本，这次发布包含的重要变非常多，其对应的 Release Note 的篇幅长度也创下了“新高”。\n面对这样一份“海量信息”的 Release Note，我们该如何从这份文档里进行高效的信息过滤和挖掘，帮助团队更精准、快速的梳理出这次发布最主要的技术脉络呢？\n在本篇文章中，我们将 1.14 的 Release Note 按照主题进行了重新归纳和梳理，按照类别对重要变更进行了技术剖析和讨论。希望这种“分类解读”的方式，能够帮助大家更好的理解 1.14 这个发布的核心内容。\nWindows Node 正式生产可用 随着1.14的发布，Kubernetes 对windows节点的生产级支持无疑是一个重要的里程碑。具体来说，1.14 版本针对 Windows 做了大量增强；\n Pod：Pod内支持 readiness 和 liveness 探针；支持进程隔离和 volume 共享的多容器 Pod；Pod 支持原生configmap 和 sercret；Pod 支持emptyDir；支持对 Pod 进行资源配额等；但是像优雅删除、Termination message、Privileged Containers、HugePages、Pod 驱逐策略等部分特性还未在 1.14 版本提供； Service：支持服务环境变量提供 DNS 解析；支持 NodePort、ClusterIP、LoadBalancer、Headless service；暂不支持 Pod 的 hostnetwork 模式； 常规 Workload controller：RS、deployment、statefulset、daemonset、job、cronjob 均支持 windows 容器； 除此之外，支持 Pod 和 container 维度的metrics、HPA、“kubectl exec”、调度抢占、resource quotas、CNI 网络支持等多种特性让 windows workload 更加云原生；由于 windows 的特殊兼容性，目前 host OS 的版本必须和容器镜像 OS 版本一致，1.14 版本支持 win server 2019；未来版本中会考虑使用 Hyper-V 隔离机制来解决版本兼容性问题。 而伴随着 Windows 容器的生态正在慢慢壮大，能够在生产级别支持 Windows 节点的容器服务开始见诸各大云厂商。阿里云容器服务（ACK）近期已经推出了 Windows Container 的支持，提供了 linux/windows 应用混合部署的统一管理能力。\n参见：Support for Windows Nodes is Graduating to Stable (#116 )\n本地持久化数据卷（Local PV） 正式可用 长期以来，能够让 Kubernetes 直接用宿主机的本地存储设备（比如：本地 SSD 硬盘）来提供持久化数据卷（即：Local PV 功能），一直是社区里非常强烈的一个诉求。这个原因很容易理解：相对于远程存储（网络存储），Local PV 在时延性、易用性、稳定性和费用上具有独特的优势，尤其是对于相关特性比较敏感的应用，如数据库应用和搜索引擎应用来说，有着重要的意义。\n而在 1.14 中，Local PV 终于正式宣布 GA，为云上的持久化存储选择增加了一种重要的的可能。\n不过，必须要明确的是， 选择使用 Local PV，也意味着用户必须自己承担一些潜在的风险，这包括：\n 目前社区的开源方案无法动态创建卷 调度器需要由额外的调度逻辑工作，以确保调度的节点可以分配出足够的磁盘容量 容错性差，如果 Pod 正在运行的宿主机宕机或者磁盘发生异常，那么它的持久化卷里的信息可能丢失 第一个问题，可以通过比如阿里云的 local-volume-provisioner 实现本地 SSD Nvme 实例自动创建数据卷来解决，但对于容错性和健壮性的问题，就是比较棘手的了。\n参见：Durable Local Storage Management is Now GA (#121)\nPod 优先级与抢占机制稳定可用 Kubernetes 里的任务优先级（priority）和抢占机制（preemption）的目的十分明确：保证高优先级的任务可以在需要的时候通过抢占低优先级任务的方式得到运行。\n这其中，优先级定义了一个 Pod 在集群中的重要程度，这个重要程度体现且仅体现在两个地方： 1. 高优先级的Pod 在调度阶段更容易被优先调度（K8s 采用队列调度模型），注意这里并不保证高优先级 Pod 永远被优先调度，实际影响调度顺序的因素有很多； 2. 在集群整体负载较高时，如果出现高优先级 Pod 无法被调度的情况（集群中没有满足条件的 Node 供 Pod 运行），K8s 会启动抢占机制，通过抢占已经运行的低优先级的 Pod 的方式，让高优先级的 Pod 可以运行起来。抢占机制便是在这里引入的。\n抢占机制指当调度器发现某个Pod（如 Pod-A）无法在集群中找到合适的节点部署时（所有节点 Predicates 全部失败），会试图通过删除一些优先级低于 Pod-A 的 Pod 来“腾出空间”部署 Pod-A，这样 Pod-A 就可以被调度了。这样一个“看似简单”的需求在分布式环境中实施起来有很多细节，例如：如何决定删除哪个节点的哪些 Pod、如何保证为 Pod-A 腾出的空间不被其它 Pod 占用、如何保证 Pod-A 不被饿死（Starvation）、如何处理有亲和性需求的 Pod 调度约束、是否需要支持跨节点 Preemption 以支持某些特定的约束（例如某 Failure Domain 的反亲和约束）等等。\n参见：Pod Priority and Preemption in Kubernetes (#564) 你一定要知道什么是 Pod Ready++ 在 1.14 版本之前，Kubernetes 判断一个 Pod 是否 Ready，就是检查这个 Pod 的容器是否全部正常运行。但是这里有个问题，那就是容器或者说里面的主进程 Ready，并不一定意味着这个应用副本就一定是就绪的。为了确认 Pod 确实可以正常可用，我们希望给它增加一些外部指标（比如，该 Pod 需要的 Service，DNS，存储等服务全部就绪），来反应这个Pod是否“真正”Ready。\n这个特性，就是1.14 里一个叫做“Pod Readiness Gates”、也叫做 Pod Ready ++ 的特性。它为pod的“Ready 状态” 提供了一个非常强大的扩展点。需要注意的是，用户需要编写一个外部控制器（Controller）来为这个Pod Readiness Gates 字段对应的指标设置值。\n参见：Pod Ready++ (#580) Kubernetes 原生应用管理能力 1.14之后，Kubernetes 项目本身 …","date":1553756400,"description":"在本篇文章中，我们将 1.14 的 Release Note 按照主题进行了重新归纳和梳理，按照类别对重要变更进行了技术剖析和讨论。希望这种“分类解读”的方式，能够帮助大家更好的理解 1.14 这个发布的核心内容。","dir":"blog/k8s-1.14-release-note/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8dddcb73179e656ccebedbba2d4e9131","permalink":"https://sofastack.github.io/sofastack.tech/blog/k8s-1.14-release-note/","publishdate":"2019-03-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/k8s-1.14-release-note/","summary":"本文由张磊、心贵、临石、徙远、衷源、浔鸣等同学联合撰写。 Kubernetes 1.14.0 Release 已经于 3 月 25 日正式发布。相信你也已经注意到，相比于1.13 和 1.12 版本，这次发布包","tags":["Kubernetes"],"title":"Kubernetes 1.14 发布了，Release Note 该怎么读？","type":"blog","url":"/sofastack.tech/blog/k8s-1.14-release-note/","wordcount":4012},{"author":"Yu Shuqiang","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》最后一篇，本篇作者yushuqiang，来自小象生鲜。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:TracerLab/]，目前领取已经完成，感谢大家的参与。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n 前言 自 Google《Dapper，大规模分布式系统的跟踪系统》论文发表以来，开源 Tracer 系统如雨后春笋般相继面市，各显神通，但都是用于分布式系统调用跟踪的组件，通过统一的 traceId 将调用链路中的各种网络调用情况记录下来，以达到透视化网络调用的目的。本文介绍的 SOFATracer 是以日志的形式来记录的，这些日志可用于故障的快速定位，服务治理等。目前来看 SOFATracer 团队已经为我们搭建了一个完整的 Tracer 框架内核，包括数据模型、编码器、跨进程透传 traceId、采样、日志落盘与上报等核心机制，并提供了扩展 API 及基于开源组件实现的部分插件，为我们基于该框架打造自己的 Tracer 平台提供了极大便利。\n作为一个开源实现，SOFATracer 也尽可能提供大而全的插件实现，但由于多数公司都有自己配套的技术体系，完全依赖官方提供的插件可能无法满足自身的需要，因此如何基于 SOFATracer 自身 API 的组件埋点机制进行扩展，实现自己的插件是必须掌握的一项本领。\n本文将根据 SOFATracer 自身 AP I的扩展点及已提供的插件源码来分析下 SOFATracer 插件的埋点机制。\nSOFATracer 的插件埋点机制 对一个应用的跟踪要关注的无非就是 客户端-\u0026amp;gt;web 层-\u0026amp;gt;rpc 服务-\u0026amp;gt;dao 后端存储、cache 缓存、消息队列 mq 等这些基础组件。SOFATracer 插件的作用实际上也就是对不同组件进行埋点，以便基于这些组件采集应用的链路数据。\n不同组件有不同的应用场景和扩展点，因此对插件的实现也要因地制宜，SOFATracer 埋点方式一般是通过 Filter、Interceptor 机制实现的。\n组件扩展入口之 Filter or Interceptor SOFATracer 目前已实现的插件中，像 SpringMVC 插件是基于 Filter 进行埋点的，httpclient、resttemplate 等是基于 Interceptor 机制进行埋点的。在实现插件时，要根据不同插件的特性和扩展点来选择具体的埋点方式。正所谓条条大路通罗马，不管怎么实现埋点，都是依赖 SOFATracer 自身 API 的扩展机制来实现。\nAPI 扩展点之 AbstractTracer API SOFATracer 中所有的插件均需要实现自己的 Tracer 实例，如 SpringMVC 的 SpringMvcTracer 、HttpClient 的 HttpClientTracer 等。\n 基于 SOFATracer API 埋点方式插件扩展如下： AbstractTracer 是 SOFATracer 用于插件扩展使用的一个抽象类，根据插件类型不同，又可以分为 clientTracer 和 serverTracer，分别对应于 AbstractClientTracer 和 AbstractServerTracer；再通过 AbstractClientTracer 和 AbstractServerTracer 衍生出具体的组件 Tracer 实现，比如上图中提到的 HttpClientTracer 、RestTemplateTracer 、SpringMvcTracer 等插件 Tracer 实现。\nAbstractTracer 这里先来看下 AbstractTracer 这个抽象类中具体提供了哪些抽象方法，也就是对于 AbstractClientTracer 和 AbstractServerTracer 需要分别扩展哪些能力。\n从上图 AbstractTracer 类提供的抽象方法来看，不管是 client 还是 server，在具体的 Tracer 插件实现中，都必须提供以下实现：\n DigestReporterLogName ：当前组件摘要日志的日志名称 DigestReporterRollingKey : 当前组件摘要日志的滚动策略 SpanEncoder：对摘要日志进行编码的编码器实现 AbstractSofaTracerStatisticReporter : 统计日志 reporter 类的实现类 基于 SOFATracer 自身 API 埋点最大的优势在于可以通过上面的这些参数来实现不同组件日志之间的隔离，上述需要实现的这些点是实现一个组件埋点常规的扩展点，是不可缺少的。\n上面分析了 SOFATracer API 的埋点机制，并且对于一些需要扩展的核心点进行了说明。SOFATracer 自身提供的内核非常简单，其基于自身 API 的埋点扩展机制为外部用户定制组件埋点提供了极大的便利。下面以 Thrift 扩展，具体分析如何实现一个组件埋点。\n PS : Thrift 是外部用户基于 SOFATracer API 扩展实现的，目前仅用于其公司内部使用，SOFATracer 官方组件中暂不支持，请知悉；后续会沟通作者提供 PR ，在此先表示感谢。\n Thrift 插件埋点分析 这里我们以 Thrift RPC 插件实现为例，分析如何实现一个埋点插件。\n1、实例工程的分包结构\n从上图插件的工程的包结构可以看出，整个插件实现比较简单，代码量不多，但从类的定义来看，直观的体现了SOFATracer 插件埋点机制所介绍的套路。下面将进行详细的分析与介绍。\n2、实现 Tracer 实例\nRpcThriftTracer 继承了 AbstractTracer 类，是对 clientTracer、serverTracer 的扩展。\n AbstractTracer RpcThriftTracer PS：如何确定一个组件是 client 端还是 server 端呢？就是看当前组件是请求的发起方还是请求的接受方，如果是请求发起方则一般是 client 端，如果是请求接收方则是 server 端。那么对于 RPC 来说，即是请求的发起方也是请求的接受方，因此这里实现了 AbstractTracer 类。\n 3、扩展点类实现\n DigestReporterLogName RpcTracerLogEnum …","date":1553697000,"description":"本文为《剖析 | SOFATracer 框架》最后一篇，本篇作者 Yu Shuqiang，来自小象生鲜。","dir":"blog/sofa-tracer-event-tracing-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"35dc2221b95ec62fd2aa03fca6367554","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","publishdate":"2019-03-27T14:30:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 埋点机制剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","wordcount":4338},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack\nScalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n SOFAStack 开源一周年，继续补充开源大图 2018 年 4 月， 蚂蚁金服宣布开源 SOFAStack 金融级分布式架构。这一年的时间，感谢社区的信任和支持，目前已经累积超过一万的 Star 数目，超过 30 家企业用户。 2019 年 3 月 24 日，SOFA 在北京举办了首场 Meetup，我们有幸见到了关心SOFA 的朋友们。 此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。 SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概念 注册中心在微服务架构中位置 服务发现，并非新鲜名词，在早期的 SOA 框架和现在主流的微服务框架中，每个服务实例都需要对外提供服务，同时也需要依赖外部服务。如何找到依赖的服务（即服务定位），最初我们思考了很多方式，比如直接在 Consumer 上配置所依赖的具体的服务地址列表，或者使用 LVS、F5 以及 DNS（域名指向所有后端服务的 IP）等负载均衡。\n但是以上方式都有明显的缺点，比如无法动态感知服务提供方节点变更的情况，另外基于负载均衡的话还需要考虑它的瓶颈问题。所以需要借助第三方的组件，即服务注册中心来提供服务注册和订阅服务，在服务提供方服务信息发生变化、或者节点上下线时，可以动态更新消费方的服务地址列表信息，最终解耦服务调用方和服务提供方。\n能力 服务注册中心的主要能力：\n 服务注册 服务订阅 演进 蚂蚁金服的服务注册中心，经历了 5 代技术架构演进，才最终形成了如今足以支撑蚂蚁海量服务注册订阅的，具有高可用、高扩展性和高时效性的架构。\n数据结构 SOFARegistry 的存储模型比较简单，主要基于 KV 存储两类数据，一类是订阅关系，体现为多个订阅方关心的 Topic（或服务键值）和他们的监听器列表，另一类是同一个 Topic（或服务键值）的发布者列表。基于观察者模式，在服务提供方发生变化时（比如服务提供方的节点上下线），会从订阅关系中寻找相应的订阅者，最终推送最新的服务列表给订阅者。\n存储扩展 主备模式 既然服务注册中心最主要能力之一是存储，那么就要思考：怎么存？存哪儿？存了会不会丢？ 怎么存，主要是由存什么数据来决定的，由于 SOFARegistry 所存储的数据结构比较简单( KV），因为并没有基于关系数据库；另外由于服务发现对变更推送的时效性要求高，但并没有很高的持久化要求(数据可以从服务提供方恢复)，所以最终我们决定自己实现存储能力。 SOFARegistry 的存储节点，最初是主备模式。 强一致集群 随着蚂蚁的服务数据量不断增长，我们将存储改为集群方式，每个存储节点的数据是一样的，每一次写入都保证所有节点写入成功后才算成功。这种模式的特点是每台服务器都存储了全量的服务数据，在当时数据规模比较小的情况下，尚可接受。\n这样的部署结构有两个问题：\n 首先，根据 CAP 原理，在分区容忍性（P）的前提下，为了保持强一致（C），必然牺牲高可用（A）为代价，比如 Zookeeper 是 CP 系统，它在内部选举期间是无法对外提供服务的，另外由于需要保证 C（顺序一致性），写的效率会有所牺牲。 其次，每个节点都存储全量的服务数据，随着业务的发展就有很大的瓶颈问题。 数据分片 如果要实现容量可无限扩展，需要把所有数据按照一定维度进行拆分，并存储到不同节点，当然还需要尽可能地保证数据存储的均匀分布。我们很自然地想到可以进行 Hash 取余，但简单的取余算法在节点数增减时会影响全局数据的分布，所以最终采用了一致性 Hash 算法（这个算法在业界很多场景已经被大量使用，具体不再进行介绍）。\n每个服务数据，经过一致性 Hash 算法计算后会存储到某个具体的 Data 上，整体形成环形的结构。理论上基于一致性 Hash 对数据进行分片，集群可以根据数据量进行无限地扩展。\n内部分层 连接承载 我们知道单机的 TCP 连接数是有限制的，业务应用不断的增多，为了避免单机连接数过多，我们需要将存储节点与业务应用数量成正比地扩容，而我们实际上希望存储节点的数量只跟数据量成正比。所以我们选择从存储节点上把承载连接职责的能力独立抽离出来成为新的一个角色，称之为 Session 节点，Session 节点负责承载来自业务应用的连接。这么一来，SOFARegistry 就由单个存储角色被分为了 Session 和 Data 两个角色，Session 承载连接，Data 承载数据，并且理论上 Session 和 Data 都支持无限扩展。\n如图，客户端直接和 Session 层建立连接，每个客户端只选择连接其中一个 Session 节点，所有原本直接到达 Data层的连接被收敛到 Session 层。Session 层只进行数据透传，不存储数据。客户端随机连接一台 Session 节点，当遇到 Session 不可用时重新选择新的 Session 节点进行重连即可。\n读写分离 分离出 Session 这一层负责承载连接，引起一个新的问题：数据到最终存储节点 Data 的路径变长了，整个集群结构也变的复杂了，怎么办呢？\n我们知道，服务注册中心的一个主要职责是将服务数据推送到客户端，推送需要依赖订阅关系，而这个订阅关系目前是存储到 Data 节点上。在 Data 上存储订阅关系，但是 Client 并没有直接和 Data 连接，那必须要在 Session 上保存映射后才确定推送目标，这样的映射关系占据了大量存储，并且还会随 Session 节点变化进行大量变更，会引起很多不一致问题。\n因此，我们后来决定，把订阅关系信息（Sub）直接存储在 Session 上，并且通过这个关系 Session 直接承担把数据变化推送给客户端的职责。而对于服务的发布信息（Pub）还是通过 Session 直接透传最终在 Data 存储节点上进行汇聚，即同一个服务 ID 的数据来自于不同的客户端和不同的 Session 最终在 Data 的一个节点存储。\n这样划分了 Sub 和 Pub 数据之后，通过订阅关系（Sub）进行推送的过程就有点类似于对服务数据读取的过程，服务发布进行存储的过程有点类似数据写的过程。数据读取的过程，如果有订阅关系就可以确定推送目标，迁移订阅关系数据到 Session，不会影响整个集群服务数据的状态，并且 Client 节点连接新的 Session 时，也会回放所有订阅关系，Session 就可以无状态的 …","date":1553697000,"description":"此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。","dir":"blog/sofa-registry-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"86b3010d0f85f6711d60de29a244ed7e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-deep-dive/","publishdate":"2019-03-27T14:30:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFARegistry","SOFAMeetup"],"title":"蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-registry-deep-dive/","wordcount":4313},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n SOFAStack 开源一周年，继续补充开源大图 2018 年 4 月， 蚂蚁金服宣布开源 SOFAStack 金融级分布式架构。这一年的时间，感谢社区的信任和支持，目前已经累积超过一万的 Star 数目，超过 30 家企业用户。\n2019 年 3 月 24 日，SOFA 在北京举办了首场 Meetup，我们有幸见到了关心 SOFA 的朋友们。\n此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。\nSOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nGitHub 地址：https://github.com/alipay/sofa-registry 概念 注册中心在微服务架构中位置 服务发现，并非新鲜名词，在早期的 SOA 框架和现在主流的微服务框架中，每个服务实例都需要对外提供服务，同时也需要依赖外部服务。如何找到依赖的服务（即服务定位），最初我们思考了很多方式，比如直接在 Consumer 上配置所依赖的具体的服务地址列表，或者使用 LVS、F5 以及 DNS（域名指向所有后端服务的 IP）等负载均衡。\n但是以上方式都有明显的缺点，比如无法动态感知服务提供方节点变更的情况，另外基于负载均衡的话还需要考虑它的瓶颈问题。所以需要借助第三方的组件，即服务注册中心来提供服务注册和订阅服务，在服务提供方服务信息发生变化、或者节点上下线时，可以动态更新消费方的服务地址列表信息，最终解耦服务调用方和服务提供方。\n能力 服务注册中心的主要能力：\n 服务注册 服务订阅 演进 蚂蚁金服的服务注册中心，经历了 5 代技术架构演进，才最终形成了如今足以支撑蚂蚁海量服务注册订阅的，具有高可用、高扩展性和高时效性的架构。\n数据结构 SOFARegistry 的存储模型比较简单，主要基于 KV 存储两类数据，一类是订阅关系，体现为多个订阅方关心的 Topic（或服务键值）和他们的监听器列表，另一类是同一个 Topic（或服务键值）的发布者列表。基于观察者模式，在服务提供方发生变化时（比如服务提供方的节点上下线），会从订阅关系中寻找相应的订阅者，最终推送最新的服务列表给订阅者。\n存储扩展 主备模式 既然服务注册中心最主要能力之一是存储，那么就要思考：怎么存？存哪儿？存了会不会丢？ 怎么存，主要是由存什么数据来决定的，由于 SOFARegistry 所存储的数据结构比较简单( KV），因为并没有基于关系数据库；另外由于服务发现对变更推送的时效性要求高，但并没有很高的持久化要求(数据可以从服务提供方恢复)，所以最终我们决定自己实现存储能力。 SOFARegistry 的存储节点，最初是主备模式。 强一致集群 随着蚂蚁金服的服务数据量不断增长，我们将存储改为集群方式，每个存储节点的数据是一样的，每一次写入都保证所有节点写入成功后才算成功。这种模式的特点是每台服务器都存储了全量的服务数据，在当时数据规模比较小的情况下，尚可接受。\n这样的部署结构有两个问题：\n 首先，根据 CAP 原理，在分区容忍性（P）的前提下，为了保持强一致（C），必然牺牲高可用（A）为代价，比如 Zookeeper 是 CP 系统，它在内部选举期间是无法对外提供服务的，另外由于需要保证 C（顺序一致性），写的效率会有所牺牲。 其次，每个节点都存储全量的服务数据，随着业务的发展就有很大的瓶颈问题。 数据分片 如果要实现容量可无限扩展，需要把所有数据按照一定维度进行拆分，并存储到不同节点，当然还需要尽可能地保证数据存储的均匀分布。我们很自然地想到可以进行 Hash 取余，但简单的取余算法在节点数增减时会影响全局数据的分布，所以最终采用了一致性 Hash 算法（这个算法在业界很多场景已经被大量使用，具体不再进行介绍）。\n每个服务数据，经过一致性 Hash 算法计算后会存储到某个具体的 Data 上，整体形成环形的结构。理论上基于一致性 Hash 对数据进行分片，集群可以根据数据量进行无限地扩展。\n内部分层 连接承载 我们知道单机的 TCP 连接数是有限制的，业务应用不断的增多，为了避免单机连接数过多，我们需要将存储节点与业务应用数量成正比地扩容，而我们实际上希望存储节点的数量只跟数据量成正比。所以我们选择从存储节点上把承载连接职责的能力独立抽离出来成为新的一个角色，称之为 Session 节点，Session 节点负责承载来自业务应用的连接。这么一来，SOFARegistry 就由单个存储角色被分为了 Session 和 Data 两个角色，Session 承载连接，Data 承载数据，并且理论上 Session 和 Data 都支持无限扩展。\n如图，客户端直接和 Session 层建立连接，每个客户端只选择连接其中一个 Session 节点，所有原本直接到达 Data层的连接被收敛到 Session 层。Session 层只进行数据透传，不存储数据。客户端随机连接一台 Session 节点，当遇到 Session 不可用时重新选择新的 Session 节点进行重连即可。\n读写分离 分离出 Session 这一层负责承载连接，引起一个新的问题：数据到最终存储节点 Data 的路径变长了，整个集群结构也变的复杂了，怎么办呢？\n我们知道，服务注册中心的一个主要职责是将服务数据推送到客户端，推送需要依赖订阅关系，而这个订阅关系目前是存储到 Data 节点上。在 Data 上存储订阅关系，但是 Client 并没有直接和 Data 连接，那必须要在 Session 上保存映射后才确定推送目标，这样的映射关系占据了大量存储，并且还会随 Session 节点变化进行大量变更，会引起很多不一致问题。\n因此，我们后来决定，把订阅关系信息（Sub）直接存储在 Session 上，并且通过这个关系 Session 直接承担把数据变化推送给客户端的职责。而对于服务的发布信息（Pub）还是通过 Session 直接透传最终在 Data 存储节点上进行汇聚，即同一个服务 ID 的数据来自于不同的客户端和不同的 Session 最终在 Data 的一个节点存储。\n这样划分了 Sub 和 Pub 数据之后，通过订阅关系（Sub）进行推送的过程就有点类似于对服务数据读取的过程，服务发布进行存储的过程有点类似数据写的过程。数据读取的过程，如果有订阅关系就可以确定推送目标，迁移订阅关系数据到 Session，不会影响整个集群服务数据的状态，并且 Client 节点连接新的 Session 时，也会回放所有订阅关系，Session 就可以无状态的 …","date":1553670000,"description":"本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/sofa-meetup-1-registry/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0e3d1f0cf167e7afea39c2435ceefcfd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-registry/","publishdate":"2019-03-27T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-registry/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFARegistry","SOFAMeetup"],"title":"蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-registry/","wordcount":4318},{"author":"蚂蚁金服团队","categories":"seata","content":" Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。\nSample 地址：https://github.com/fescar-group/fescar-samples/tree/master/tcc\n文末也提供了项目后续的 Roadmap，欢迎关注。\n一、TCC 简介 在两阶段提交协议（2PC，Two Phase Commitment Protocol）中，资源管理器（RM, resource manager）需要提供“准备”、“提交”和“回滚” 3 个操作；而事务管理器（TM, transaction manager）分 2 阶段协调所有资源管理器，在第一阶段询问所有资源管理器“准备”是否成功，如果所有资源均“准备”成功则在第二阶段执行所有资源的“提交”操作，否则在第二阶段执行所有资源的“回滚”操作，保证所有资源的最终状态是一致的，要么全部提交要么全部回滚。\n资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现；TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题；TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中；事务管理器分 2 阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法；最终所有 TCC 服务要么全部都是提交的，要么全部都是回滚的。\n二、TCC 设计 用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上，进过蚂蚁金服多年的 TCC 应用，总结如下主要的TCC 设计和实现主要事项：\n1、业务操作分两阶段完成 接入 TCC 前，业务操作只需要一步就能完成，但是在接入 TCC 之后，需要考虑如何将其分成 2 阶段完成，把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户A的余额中有 100 元，需要扣除其中 30 元”；\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成 2 步完成：\n Try 操作：资源的检查和预留； 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交； 在扣款场景下，Confirm 阶段走的事情就是发生真正的扣款，把A账户中已经冻结的 30 元钱扣掉。\n Cancel 操作：预留资源的是否； 在扣款场景下，扣款取消，Cancel 操作执行的任务是释放 Try 操作冻结的 30 元钱，是 A 账户回到初始状态。\n2、并发控制 用户在实现 TCC 时，应当考虑并发性问题，将锁的粒度降到最低，以最大限度的提高分布式事务的并发性。\n以下还是以A账户扣款为例，“账户 A 上有 100 元，事务 T1 要扣除其中的 30 元，事务 T2 也要扣除 30 元，出现并发”。\n在一阶段 Try 操作中，分布式事务 T1 和分布式事务 T2 分别冻结资金的那一部分资金，相互之间无干扰；这样在分布式事务的二阶段，无论 T1 是提交还是回滚，都不会对 T2 产生影响，这样 T1 和 T2 在同一笔业务数据上并行执行。\n3、允许空回滚 如下图所示，事务协调器在调用 TCC 服务的一阶段 Try 操作时，可能会出现因为丢包而导致的网络超时，此时事务管理器会触发二阶段回滚，调用 TCC 服务的 Cancel 操作，而 Cancel 操作调用未出现超时。\nTCC 服务在未收到 Try 请求的情况下收到 Cancel 请求，这种场景被称为空回滚；空回滚在生产环境经常出现，用户在实现TCC服务时，应允许允许空回滚的执行，即收到空回滚时返回成功。\n4、防悬挂控制 如下图所示，事务协调器在调用 TCC 服务的一阶段 Try 操作时，可能会出现因网络拥堵而导致的超时，此时事务管理器会触发二阶段回滚，调用 TCC 服务的 Cancel 操作，Cancel 调用未超时；在此之后，拥堵在网络上的一阶段 Try 数据包被 TCC 服务收到，出现了二阶段 Cancel 请求比一阶段 Try 请求先执行的情况，此 TCC 服务在执行晚到的 Try 之后，将永远不会再收到二阶段的 Confirm 或者 Cancel ，造成 TCC 服务悬挂。\n用户在实现 TCC 服务时，要允许空回滚，但是要拒绝执行空回滚之后 Try 请求，要避免出现悬挂。\n5、幂等控制 无论是网络数据包重传，还是异常事务的补偿执行，都会导致 TCC 服务的 Try、Confirm 或者 Cancel 操作被重复执行；用户在实现 TCC 服务时，需要考虑幂等控制，即 Try、Confirm、Cancel 执行一次和执行多次的业务结果是一样的。\nRoadmap 当前已经发布到 0.4.0 版本，后续我们会发布 0.5 ~ 1.0 版本，继续对 AT、TCC 模式进行功能完善和和丰富，并解决服务端高可用问题，在 1.0 版本之后，本开源产品将达到生产环境使用的标准。\n","date":1553583600,"description":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。","dir":"blog/seata-tcc-theory-design-realization/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"45ef8a72beefcd26f4f62e7bdb34671c","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-tcc-theory-design-realization/","publishdate":"2019-03-26T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/seata-tcc-theory-design-realization/","summary":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。 Sample 地址：https://github.com/fescar-group/fescar","tags":["seata"],"title":"TCC 理论及设计实现指南介绍","type":"blog","url":"/sofastack.tech/blog/seata-tcc-theory-design-realization/","wordcount":1971},{"author":"蚂蚁金服团队","categories":"seata","content":" Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用，文末也提供了项目后续的 Roadmap，欢迎关注。\n前言：基于 TCC 模型的应用场景 TCC 分布式事务模型直接作用于服务层。不与具体的服务框架耦合，与底层 RPC 协议无关，与底层存储介质无关，可以灵活选择业务资源的锁定粒度，减少资源锁持有时间，可扩展性好，可以说是为独立部署的 SOA 服务而设计的。\n一、TCC 模型优势 对于 TCC 分布式事务模型，笔者认为其在业务场景应用上，有两方面的意义。\n1.1 跨服务的分布式事务 服务的拆分，也可以认为是资源的横向扩展，只不过方向不同而已。\n横向扩展可能沿着两个方向发展：\n 功能扩展，根据功能对数据进行分组，并将不同的功能组分布在多个不同的数据库上，这实际上就是 SOA 架构下的服务化。 数据分片，在功能组内部将数据拆分到多个数据库上，为横向扩展增加一个新的维度。 下图简要阐释了横向数据扩展策略：\n横向扩展的两种方法可以同时进行运用：用户信息（Users）、产品信息（Products）与交易信息（Trans）三个不同功能组可以存储在不同的数据库中。另外，每个功能组内根据其业务量可以再拆分到多个数据库中，各功能组可以相互独立地进行扩展。\n因此，TCC 的其中一个作用就是在按照功能横向扩展资源时，保证多资源访问的事务属性。\n1.2 两阶段拆分 TCC 另一个作用就是把两阶段拆分成了两个独立的阶段，通过资源业务锁定的方式进行关联。资源业务锁定方式的好处在于，既不会阻塞其他事务在第一阶段对于相同资源的继续使用，也不会影响本事务第二阶段的正确执行。\n传统模型的并发事务：\nTCC 模型的并发事务：\n可以发现 TCC 模型进一步减少了资源锁的持有时间。同时，从理论上来说，只要业务允许，事务的第二阶段什么时候执行都可以，反正资源已经业务锁定，不会有其他事务动用该事务锁定的资源。\n这对业务有什么好处呢？拿支付宝的担保交易场景来说，简化情况下，只需要涉及两个服务，交易服务和账务服务。交易作为主业务服务，账务作为从业务服务，提供 Try、Commit、Cancel 接口：\n Try 接口扣除用户可用资金，转移到预冻结资金。预冻结资金就是业务锁定方案，每个事务第二阶段只能使用本事务的预冻结资金，在第一阶段执行结束后，其他并发事务也可以继续处理用户的可用资金。 Commit 接口扣除预冻结资金，增加中间账户可用资金（担保交易不能立即把钱打给商户，需要有一个中间账户来暂存）。 假设只有一个中间账户的情况下，每次调用支付服务的 Commit 接口，都会锁定中间账户，中间账户存在热点性能问题。 但是，在担保交易场景中，七天以后才需要将资金从中间账户划拨给商户，中间账户并不需要对外展示。因此，在执行完支付服务的第一阶段后，就可以认为本次交易的支付环节已经完成，并向用户和商户返回支付成功的结果，并不需要马上执行支付服务二阶段的 Commit 接口，等到低锋期时，再慢慢消化，异步地执行。\n可能部分读者认为担保交易比较特殊，其实直付交易（直接把钱打到商户账户的交易模式，Commit 接口扣除预冻结资金以后，不是转移到中间账务，而是直接转移到商户账户）也可以这样使用，只要提前告知商户，高峰期交易资金不是实时到账，但保证在一定时间之内结算完成，商户应该也是可以理解的。\n这就是 TCC 分布式事务模型的二阶段异步化功能，从业务服务的第一阶段执行成功，主业务服务就可以提交完成，然后再由框架异步的执行各从业务服务的第二阶段。\n二、通用型 TCC 解决方案 通用型 TCC 解决方案就是最典型的 TCC 分布式事务模型实现，所有从业务服务都需要参与到主业务服务的决策当中。\n适用场景 由于从业务服务是同步调用，其结果会影响到主业务服务的决策，因此通用型 TCC 分布式事务解决方案适用于执行时间确定且较短的业务，比如互联网金融企业最核心的三个服务：交易、支付、账务：\n当用户发起一笔交易时，首先访问交易服务，创建交易订单；然后交易服务调用支付服务为该交易创建支付订单，执行收款动作，最后支付服务调用账务服务记录账户流水和记账。\n为了保证三个服务一起完成一笔交易，要么同时成功，要么同时失败，可以使用通用型 TCC 解决方案，将这三个服务放在一个分布式事务中，交易作为主业务服务，支付作为从业务服务，账务作为支付服务的嵌套从业务服务，由 TCC 模型保证事务的原子性。\n支付服务的 Try 接口创建支付订单，开启嵌套分布式事务，并调用账务服务的 Try 接口；账务服务在 Try 接口中冻结买家资金。一阶段调用完成后，交易完成，提交本地事务，由 TCC 框架完成分布式事务各从业务服务二阶段的调用。\n支付服务二阶段先调用账务服务的 Confirm 接口，扣除买家冻结资金；增加卖家可用资金。调用成功后，支付服务修改支付订单为完成状态，完成支付。\n当支付和账务服务二阶段都调用完成后，整个分布式事务结束。\n三、异步确保型 TCC 解决方案 异步确保型 TCC 解决方案的直接从业务服务是可靠消息服务，而真正的从业务服务则通过消息服务解耦，作为消息服务的消费端，异步地执行。\n可靠消息服务需要提供 Try，Confirm，Cancel 三个接口。Try 接口预发送，只负责持久化存储消息数据；Confirm 接口确认发送，这时才开始真正的投递消息；Cancel 接口取消发送，删除消息数据。\n消息服务的消息数据独立存储，独立伸缩，降低从业务服务与消息系统间的耦合，在消息服务可靠的前提下，实现分布式事务的最终一致性。\n此解决方案虽然增加了消息服务的维护成本，但由于消息服务代替从业务服务实现了 TCC 接口，从业务服务不需要任何改造，接入成本非常低。\n适用场景 由于从业务服务消费消息是一个异步的过程，执行时间不确定，可能会导致不一致时间窗口增加。因此，异步确保性 TCC 分布式事务解决方案只适用于对最终一致性时间敏感度较低的一些被动型业务（从业务服务的处理结果不影响主业务服务的决策，只被动的接收主业务服务的决策结果）。比如会员注册服务和邮件发送服务：\n当用户注册会员成功，需要给用户发送一封邮件，告诉用户注册成功，并提示用户激活该会员。但要注意两点：\n 如果用户注册成功，一定要给用户发送一封邮件； 如果用户注册失败，一定不能给用户发送邮件。 因此，这同样需要会员服务和邮件服务保证原子性，要么都执行，要么都不执行。不一样的是，邮件服务只是一种被动型的业务，并不影响用户是否能够注册成功，它只需要在用户注册成功以后发送邮件给用户即可，邮件服务不需要参与到会员服务的活动决策中。\n对于此种业务场景，可以使用异步确保型TCC分布式事务解决方案，如下：\n由可靠消息服务来解耦会员和邮件服务，会员服务与消息服务组成 TCC 事务模型，保证事务原子性。然后通过消息服务的可靠特性，确保消息一定能够被邮件服务消费，从而使得会员与邮件服务在同一个分布式事务中。同时，邮件服务也不会影响会员服务的执行过程，只在会员服务执行成功后被动接收发送邮件的请求。\n四、补偿型 TCC 解决方案 补偿型 TCC 解决方案与通用型 TCC 解决方案的结构相似，其从业务服务也需要参与到主 …","date":1553410800,"description":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。","dir":"blog/seata-tcc-applicable-models-scenarios/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa8436ce2760fafb880427799a763f32","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","publishdate":"2019-03-24T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","summary":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用，文末也提供了项目后续的 Roadmap，欢迎关注。 前言：基于 TCC 模型的应用场景 TCC 分布式事","tags":["seata"],"title":"TCC 适用模型与适用场景分析","type":"blog","url":"/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","wordcount":3912},{"author":"善逝","categories":"SOFAArk","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服在 SOFAStack 体系内研发了一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力\u0026amp;ndash;SOFAArk。本篇文章为 SOFAArk 0.6.0 的新特性介绍。 GitHub 地址：https://github.com/alipay/sofa-ark\n 简介 在大型软件开发过程中，通常会推荐底层功能插件化、业务功能模块化的开发模式，以其达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化开发方案，产品能力主要包括：\n 定义插件开发规范，提供 Maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin）， 适用于将底层组件插件化输出，例如 RPC、富客户端等； 定义模块开发规范，提供 Maven 打包工具，简单快速将应用（Spring Boot/SOFABoot/普通 Java 应用）打包成模块 (Ark Biz，以下简称 Biz)，适用于将业务组件模块化输出，提升业务能力复用； 定义类加载模型，运行时 Plugin、Biz 之间均相互隔离，运行时由不同的 ClassLoader 加载，有效避免相互之间的包冲突，降低 Plugin 和 Biz 对运行环境的要求； 定义标准的编程界面，包括服务、事件、扩展点等机制，方便 Plugin、Biz 交互和扩展； 定义业务模块 (Biz) 生命周期，支持多 Biz 合并部署。开发阶段将多个 Biz 打包成 Executable Ark Jar 包(以下简称 Ark 包)，或者运行时使用 API 或配置中心(Zookeeper)动态地管理 Biz 安装和卸载，满足多应用合并部署及动态升级的需求。 基于以上能力，SOFAArk 可以帮助解决多应用(模块)合并部署、动态升级、依赖包冲突等场景问题。\n场景 场景一：合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件。协调跨团队合作开发会遇到不少问题：比如各自技术栈不统一导致的依赖冲突、往同一个 Git 仓库提交代码常常导致 merge 冲突、组件功能相互依赖影响测试进度。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发和测试，运行时合并部署，那么将有助于提升开发效率及应用可扩展性。\nSOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互，如下：\nBiz 对应用类型没有限制，可以是 Spring Boot/SOFABoot/Java 普通应用类型，Biz 之间采用统一的编程界面-SOFA JVM服务进行交互。发布和引用服务也非常简单，使用 API 或者 Spring 注解/XML 方式：\n合并部署的形式，分为两种 \u0026amp;ndash; 静态合并部署和动态合并部署。\n静态合并部署 在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成 Ark 包时，会将引入的其他 Biz 包一并打入。通过 java -jar 启动 Ark 包时，则会根据优先级依次启动各 Biz，单个 Biz 使用独立的 BizClassLoader 加载，不需要考虑依赖包冲突问题，Biz 之间则通过 SOFA JVM 服务交互。\n动态合并部署 动态合并部署区别于静态合并部署最大的一点是，在运行时可以通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态合并部署的设计理念图如下：\n无论是静态抑或动态合并部署都有存在宿主应用 (master biz) 的概念，如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主 Biz 和其他 Biz 唯一不同在于，宿主 Biz 不允许被卸载。\n一般而言，宿主应用会作为流量入口的中台系统，具体的服务实现会放在不同的动态 Biz 中，供宿主应用调用。宿主应用可以使用 SOFAArk 提供的客户端 API 实现动态应用的部署和卸载。除了 API， SOFAArk 提供了 Config Plugin，用于对接配置中心（目前支持 Zookeeper），运行时接受动态配置；Config Plugin 会解析下发的配置，控制动态应用的部署和卸载。\n场景二：动态升级 SOFAArk 在蚂蚁内部也被用来解决动态升级的场景问题。有时候，因为业务迭代较快，应用依赖的某二方包需要频繁的变更，这将导致应用每次都因为升级二方包版本做变更发布，影响开发效率；而作为二方包的开发者，常常因为推动依赖方应用升级阻力较大，导致新特性无法按时上线，影响业务发展。\n为了加快创新业务的迭代速度，会将需要频繁变更的二方包打包成 Biz 包，供其他应用依赖。作为依赖方，不会直接在 Pom 文件（假设是使用 Maven 构建）定义 Biz 包版本，而是通过配置中心（例如 Zookeeper）下发配置。如此，当应用启动时，会拉取 Biz 版本配置信息，进而拉取正确版本的 Biz 包并启动。如此，当需要依赖方升级 Biz 版本时，只需要在配置中心重新推送配置即可。\n场景三：依赖隔离 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError, NoSuchMethodError 等。实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法：统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突。这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题。如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题。 OSGi 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGi 框架门槛较高，功能繁杂。为了解决包冲突问题，引入 OSGi 框架，有牛刀杀鸡之嫌，反而使工程变得更加复杂，不利于开发。\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如 …","date":1553065200,"description":"本篇文章为 SOFAArk 0.6.0 的新特性介绍。","dir":"blog/sofa-ark-0.6.0/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7a25cfa30d66586c83abafd947447de3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-0.6.0/","publishdate":"2019-03-20T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-ark-0.6.0/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 蚂蚁金服在 SOFAStack 体","tags":["SOFAArk"],"title":"蚂蚁金服 SOFAArk 0.6.0 新特性介绍 | 模块化开发容器","type":"blog","url":"/sofastack.tech/blog/sofa-ark-0.6.0/","wordcount":3490},{"author":"炎竹","categories":"SOFAActs","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服在 SOFAStack 体系内研发了基于模型驱动的自动化接口测试框架 SOFAACTS。 GitHub 地址：https://github.com/alipay/sofa-acts\n 背景 伴随着业务需求的爆发，蚂蚁金服金融级分布式架构质量测试活动变得复杂起来，表现在测试的业务场景复杂，诸如分布式事务处理流程场景、并发性、账户状态多样性、幂等性和兼容性等等。在原有的自动化测试框架下，测试流程编排极易出现测试数据冗余分散、可维护性差、人工编码成本高和测试验证点易遗漏的问题。\n如何解决上面的问题呢？\n蚂蚁金服在 SOFAStack 体系内研发了基于模型驱动的自动化接口测试框架 SOFAACTS。\nSOFAACTS 介绍 SOFAACTS 由 IDE 和测试引擎组成，下图为产品架构图：\n框架适配 TestNg+Spring 的测试上下文环境，以 YAML 为数据载体并在此上构建数据模型驱动，具有契合快速互联网发展和复杂分布式金融系统特点的优良特性：\n 模型驱动和标准执行引擎； 精细化校验和数据的自动回写； 具有灵活的可扩展性； 用例可视化维护。 1.模型驱动和标准化 在测试用例数据与测试代码分离的探索上，很多测试框架采用数据驱动的方式，但这也无法从容应对金融级的复杂业务场景。框架对用例数据进行了深度抽象，提出模型驱动理念，研发出基于模型的数据驱动和标准化执行引擎，实现了数据和代码的分离管理，同时对测试过程中的数据清理、数据准备、用例执行、结果校验阶段进行标准化，做到测试数据维护和测试代码的简洁优雅。用例执行时用户无需关注数据如何加载，结果和期望数据如何比对，只需要关注测试数据和执行结果。\n接下来，我们介绍如何使用 SOFAACTS 来高效率地完成一键生成数据模型生成和一键生成测试脚本。\n数据模型生成 首先进行数据模型的准备，以方便之后模版化地快速创建对象和表，按照如下方式来准备 DB 数据、接口请求参数和返回结果对象模型。\nDB 数据模型生成 任意测试代码中右击-\u0026amp;gt; SOFAACTS 功能-\u0026amp;gt;生成 DB 表结构模板； 选择生成的目标测试工程； 点击确认后选择并添加需要生成模型的表即可生成。 类对象模型生成 待构建模型的类定义的任意方法上右击-\u0026amp;gt; SOFAACTS 功能-\u0026amp;gt;模板生成，生成当前对象的模型； 生成完成后，我们可以在下图位置找到生成的数据对象模型； 按照上述步骤，这样我们就生成了接口对象模板。 现在，我们开始进行脚本一键生成：\n测试脚本生成 SOFAACTS IDE 提供测试脚本自动生成功能，无需手动编码。操作方式如下：\n 被测接口方法上点击，选择 SOFAACTS 功能\u0026amp;ndash;\u0026amp;gt;生成测试用例； 这时会弹出一个文本框，填写脚本生成的位置和编码格式，如下： 填写完成后，点击 OK 即可自动生成如下测试脚本，可以看出模型驱动生成的脚本精简而优雅。 原来数据驱动下的脚本是如下面图这样的，测试数据冗余分散，人工编码成本高维护性差。\n实践证明 SOFAACTS 用例的测试代码构建效率提高 80% ，测试数据精简到 1/case 数。\n2.精细化校验 在解决复杂业务场景下测试验证难、易遗漏等问题时，SOFAACTS 基于代码行为跟踪和分析理念，通过反射机制和日志解析实现结果数据的自动采集，以此做为场景用例校验的数据基线，并在持续集成时进行基线全量因子匹配来达到精细化验证。如下图：\n同时，为了提高自动采集后数据回填的效率，框架支持预校验数据的自动写入能力，进一步实现了数据的自动化精细校验。如下图：一键点击即可采集到校验数据基线，在蚂蚁内部实践中 ACTS 做到了结果校验效率提升至少 80%，场景验证 0 遗漏。\n3.灵活可扩展 框架为了应对各种特殊业务测试情况而不需要过多改动，设计上应用高内聚与低耦合原则，支持既可以复用框架底层代码又可以针对业务个性化情况做扩展的能力。整个框架提供了丰富的 API，测试执行过程每个方法、每个类以便测试执行过程的每个阶段（如下图）都能够在测试脚本里面被重新为其他方法或者被其他多态的子类替换，这样让框架变得更通用，既赋予了框架轻量性又增加了灵活性。\n自定义的 API 如下：\nAPI 的具体使用请详细学习产品使用手册。\n4.用例可视化维护 框架支持研发集成环境的一站式编辑，高效的用例脚本和数据维护，有效减少重复性的数据准备代码。如下图：\n总结 以上便是对 SOFAACTS 测试框架的基本介绍，还有诸多能力各位可以查阅我们详细的使用手册。\n目前，SOFAACTS 已经在蚂蚁金服大范围使用，分钟级用例编写 10 倍效能提升，累计用例个数 10w 以上，高频功能使用可达近 2000 次/日，并持续保持着旺盛的生命力。\n当前，代码已开源托管在 GitHub 上，欢迎关注，同时也欢迎业界爱好者共同创造更好的 SOFAACTS。\nGitHub 项目地址：https://github.com/alipay/sofa-acts\n相关链接 SOFAACTS ：https://github.com/alipay/sofa-acts API 产品使用手册：https://www.sofastack.tech/sofa-acts/docs/Usage-API SOFAACTS 详细使用手册：https://www.sofastack.tech/sofa-acts/docs/Home 招聘 蚂蚁金服金融核心测试技术团队持续寻找对测试自动化、智能风险管控等方向充满热情的小伙伴加入，有意者请联系 zhiqiang.li@antfin.com\n","date":1552546800,"description":"SOFAStack 体系，基于模型驱动的自动化接口测试框架 SOFAACTS。","dir":"blog/sofa-acts-automated-testing-framework/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b76c650b1a69560fe38c8e4f237f6207","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-acts-automated-testing-framework/","publishdate":"2019-03-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-acts-automated-testing-framework/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 蚂蚁金服在 SOFAStack 体","tags":["SOFAActs"],"title":"SOFAStack 开源自动化测试框架 SOFAACTS","type":"blog","url":"/sofastack.tech/blog/sofa-acts-automated-testing-framework/","wordcount":2096},{"author":"家纯","categories":"SOFAJRaft","content":" 什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 Raft 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。 SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\n 基础知识：分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 Paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 Paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等）。 Zab：被应用在 Zookeeper 中，业界使用广泛，但没有抽象成通用的 library。 Raft：以容易理解著称，业界也涌现出很多 Raft 实现，比如大名鼎鼎的 etcd, braft, tikv 等。 什么是 Raft？ Raft 是一种更易于理解的分布式共识算法，核心协议本质上还是师承 Paxos 的精髓，不同的是依靠 Raft 模块化的拆分以及更加简化的设计，Raft 协议相对更容易实现。\n模块化的拆分主要体现在：Raft 把一致性协议划分为 Leader 选举、MemberShip 变更、日志复制、Snapshot 等几个几乎完全解耦的模块。\n更加简化的设计则体现在：Raft 不允许类似 Paxos 中的乱序提交、简化系统中的角色状态（只有 Leader、Follower、Candidate 三种角色）、限制仅 Leader 可写入、使用随机化的超时时间来设计 Leader Election 等等。\n特点：Strong Leader 系统中必须存在且同一时刻只能有一个 Leader，只有 Leader 可以接受 Clients 发过来的请求； Leader 负责主动与所有 Followers 通信，负责将“提案”发送给所有 Followers，同时收集多数派的 Followers 应答； Leader 还需向所有 Followers 主动发送心跳维持领导地位(保持存在感)。 一句话总结 Strong Leader: \u0026amp;ldquo;你们不要 BB! 按我说的做，做完了向我汇报!\u0026amp;rdquo;。另外，身为 Leader 必须保持一直 BB(heartbeat) 的状态，否则就会有别人跳出来想要 BB 。\nRaft 中的基本概念 篇幅有限，这里只对 Raft 中的几个概念做一个简单介绍，详细请参考 Raft paper。\nRaft-node 的 3 种角色/状态 Follower：完全被动，不能发送任何请求，只接受并响应来自 Leader 和 Candidate 的 Message，每个节点启动后的初始状态一定是 Follower； Leader：处理所有来自客户端的请求，以及复制 Log 到所有 Followers； Candidate：用来竞选一个新 Leader （Candidate 由 Follower 触发超时而来）。 Message 的 3 种类型 RequestVote RPC：由 Candidate 发出，用于发送投票请求； AppendEntries (Heartbeat) RPC：由 Leader 发出，用于 Leader 向 Followers 复制日志条目，也会用作 Heartbeat （日志条目为空即为 Heartbeat）； InstallSnapshot RPC：由 Leader 发出，用于快照传输，虽然多数情况都是每个服务器独立创建快照，但是Leader 有时候必须发送快照给一些落后太多的 Follower，这通常发生在 Leader 已经丢弃了下一条要发给该Follower 的日志条目(Log Compaction 时清除掉了) 的情况下。 任期逻辑时钟 时间被划分为一个个任期 (term)，term id 按时间轴单调递增； 每一个任期的开始都是 Leader 选举，选举成功之后，Leader 在任期内管理整个集群，也就是 “选举 + 常规操作”； 每个任期最多一个 Leader，可能没有 Leader (spilt-vote 导致)。 本图出自《Raft: A Consensus Algorithm for Replicated Logs》\n什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 Raft 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\nSOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nSOFAJRaft 整体功能\u0026amp;amp;性能优化 功能支持 Leader election：Leader 选举，这个不多说，上面已介绍过 Raft 中的 Leader 机制。\n Log replication and recovery：日志复制和日志恢复。\n Log replication 就是要保证已经被 commit 的数据一定不会丢失，即一定要成功复制到多数派。 Log recovery 包含两个方面： Current term 日志恢复：主要针对一些 Follower 节点重启加入集群或者是新增 Follower 节点后如何追日志； Prev term 日志恢复：主要针对 Leader 切换前后的日志一致性。 Snapshot and log compaction：定时生成 snapshot，实现 log compaction 加速启动和恢复，以及 InstallSnapshot 给 Followers 拷贝数据，如下图：\n 本图出自《In Search of an Understandable Consensus Algorithm》\n Membership change：用于集群线上配置变更，比如增加节点、删除节点、替换节点等。\n Transfer leader：主动变更 leader，用于重启维护，leader 负载平衡等。\n Symmetric network partition tolerance：对称网络分区容忍性。\n 如上图 S1 为当前 leader，网络分区造成 S2 不断增加本地 term，为了避免网络恢复后 S2 …","date":1552374000,"description":"本文为 SOFAJRaft 的基础解析，欢迎阅读~","dir":"blog/sofa-jraft-production-level-algorithm-library/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a2e98969240f05af10554781f4ab81ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","publishdate":"2019-03-12T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","summary":"什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用","tags":["SOFAJRaft","SOFALab"],"title":"SOFAStack 开源 SOFAJRaft：生产级 Java Raft 算法库","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","wordcount":6481},{"author":"Linux 中国 老王","categories":"SOFAStack","content":" 我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\u0026amp;ndash; 蚂蚁金服总监杨冰\n引言 最近，我听到了一个消息，蚂蚁金服将会开源 SOFA最核心的两个组件——分布式事务框架和服务注册中心。\n熟悉中间件的朋友们都知道，这两个组件都是针对当前最火的微服务架构。其中，分布式事物框架是解决数据一致性问题的关键。服务注册中心则是服务治理的基础。在这两块开源后，SOFA 将成为一套真正完备的分布式解决方案。\n作为开源人士，我对此消息深感兴趣，因此联系到了蚂蚁金服中间件团队的杨冰总监，就此消息向他求证。机缘凑巧之下，杨冰花费了宝贵的时间，和我深入讲述了 SOFA 开源的思考，以及近期的规划。\n通过这次交谈，也让我看到了一个成功的商业公司是如何拥抱开源、并将开源作为其根本战略来撬动技术红利，支持其急速发展的业务需求的。\n以下是正文，我将它分享出来以飨读者。\n如今，开源已经成为主流，可以说，整个信息产业已经从过去的闭源模式转换为现今的开源模式。各种开源公司纷纷创新不同的开源模式，其中以 RedHat、Google、Facebook 等公司所取得的成绩最为耀眼。\n2018 年的时候，我曾经参与“开源社”主持的《2018 中国开源年度报告》的撰写工作，并建立了一个数学分析模型，以此来对中国的互联网公司的开源项目分析其活跃度和健康度。让我既感意外，也不意外的是，阿里系的开源项目占据了活跃度排行榜前五的第一、第二和第四；甚至在前五十个项目中，阿里系的开源项目占据了超过一半的份额！我不意外的是，业界一直对阿里在开源方面的动作和力度颇有感受；意外的是，这种力度还是超乎了我的想象。这其中包括阿里巴巴集团和蚂蚁金服等都贡献了相当可观的开源项目。\n因此，这次遇到杨冰时，我就开源方面和他深入聊了几句，想了解一下蚂蚁金服是如何思考开源和践行开源的，是如何将开源与公司的商业价值有机地结合起来的。\n缘何开源 作为一家商业公司，宣称自己开源，甚至也形式上开源一些代码，其实已经是很常见的事情了。但是，真正能将开源与公司的技术演进相融合，并能有效地助推公司业务发展的，却并不太多。这件事其实并没有那么简单——远非只是上传到 GitHub 那么简单。\n根据业界的经验，在公司的技术产品开源方面，要将现有场景的代码开源，至少需要在已经运行稳定、结构清晰的现有代码基础上多付出 30% 的技术投入，对代码进行梳理、完善和通用化，才能做到初步的代码开源；而进一步要将这些开源代码维护下去，乃至于和公司业务线上的产品代码保持同步发展，多付出的技术成本还远远不止这些。作为一个互联网技术老兵，我对此深以为然。\n那么，蚂蚁金服是如何说服公司决策层在尚未看到开源回报的前景下，同意付出这么多的额外代价来支持开源的呢？推动开源的力量是因何而来的？\n“首先，开源是个共赢的模式，对于蚂蚁金服来说，开源可以扩大技术服务场景，为支付、金融等更多的客户提供服务，提升合作伙伴的效率。”杨冰说，“虽然，蚂蚁金服已经有很多的业务场景，也在很多场景下取得了超大规模的实践经验，但是，依然存在没有覆盖到的金融服务场景。而将技术开源出来，可以供更多的客户应用到其自身的场景下——这些场景有效的补充了蚂蚁金服的技术应用面，也为更完善的技术框架奠定了基础。因此，我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。”\n“其次，对金融服务来说，监管和自主可控的要求更多，”杨冰接着谈到，“客户也希望可以对其所采用的技术有更多的掌控。”开源是一种可以使客户和上下游产业共同参与和发展的可行模式。\n“所以，其实并不是技术部门去说服公司决策层去开源，而是业务发展的自然选择，这也是一种合理的发展方向。”他总结道。这样的结果，其实是和当前流行的开源商业模式所暗合的。\n“另外，如你所说，确实在开源时，我们做了很大的改造。以可扩展化的方式来层层构建 SOFA 框架的能力，保证 SOFA 的内部版本和开源的版本采用的是同一个内核。在开源时，剥离了特定业务的逻辑，而保持了公司内部的业务线上的代码和开源代码的核心是一致的。这样，只要公司的业务在持续发展，开源的代码就会一直维护和演进下去。所以 SOFA 的内部版本就是在开源版本之上扩展了内部逻辑和历史版本的兼容逻辑。开源版本的核心逻辑，内外是一致的，并在蚂蚁金服的生产环境中被广泛使用，同时会随着蚂蚁金服自身业务诉求的驱动不断的演进。”杨冰补充道，“但这是值得的，在为开源代码做改进时，也是为公司自己的业务做改进，这是双赢且可持续发展的。”\n很多公司在初涉开源时，常常有疑虑，将核心技术开放出去，会不会导致竞争对手的技术提升，会不会造成更大的技术竞争压力？\n“事实上，我们在最初准备开源时，也有讨论过这个方面。技术要被更多人用、更多场景用，才会有发展。而开放的技术才能带来团队的发展，因为技术是动态发展的，作为开源的一方，事实上在技术上是相对领先的。开源和掌握是两码事，掌握和用好又是两码事，所以，因开源而带来的竞争，其实是助推整个开源体系的发展的，是良性的、有益的。”杨冰说，“而从社区和行业现状看，大家都在开放，封闭的技术体系会逐渐落后。只有开放才能求同存异，共同发展。”\n 花絮\n我问蚂蚁金服的朋友，在你们开源中有什么有趣的“段子”吗？可以讲来听听。\n我朋友过了几天后，给我发来了这样一段文字：\n“参与双十一的中间件团队的常态是什么呢？\n当晚，团队的常态大概就是喝着茶等零点高峰，高峰期过了之后，当然就是参与买买买啦。 我们很多的一些事情的初始想法都是来自于双十一当天的夜聊，似乎在经历了紧张的零点高峰之后，脑细胞特别活跃。\n对于基础设施团队来说，双十一算是一次大考的结束，考完成绩出来了，我们就想琢磨一些有挑战的事情，于是我们会天马行空地聊一聊对于下一年在技术上需要去做的事情。而在 2017 年的双十一当天，SOFA 的几个同学就围在一起聊了 SOFA 能不能开源？为什么要开源？开源和商业化之间的关系？开源后要做哪些事情等等，这个算是 SOFA 开源的第一次内部讨论。\n从这次内部讨论之后，经过了大约半年的准备时间，我们在 2018 年 4 月份正式宣布开源并一直在逐步开源的进程中。”\n他说，这就是他们憋了半天想出来的“段子”，哈哈哈，这群可爱的技术人啊。\n SOFA 的演进和开源之路 SOFA 中间件框架是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\nSOFA 开源全景图，涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的Nacos、Sentinel等，为用户提供更加广泛地选择。\nSOFA 作为一个演进了几年的框架，也一定程度上代表了蚂蚁金服的技术体系的演变，并且现在形成了开源核心、开放式（组件式）开源的模式。SOFA 从 2018 年开始开源，但是我比较好奇 SOFA 开源之前的发展旅程是怎样的。\n杨冰说，“最早的时候，在蚂蚁金服还没有从淘宝分拆出来时，公司内使用过一个 …","date":1552287600,"description":"我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。","dir":"blog/financial-technology-meet-open-source/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"620bf66a94dd1d8b872cb4cb90ca3028","permalink":"https://sofastack.github.io/sofastack.tech/blog/financial-technology-meet-open-source/","publishdate":"2019-03-11T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/financial-technology-meet-open-source/","summary":"我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\u0026ndas","tags":["SOFAStack"],"title":"蚂蚁金服总监杨冰：金融科技公司为什么要拥抱开源？ | 穿山甲专访","type":"blog","url":"/sofastack.tech/blog/financial-technology-meet-open-source/","wordcount":6192},{"author":"潘潘","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布 活动时间：3 月 24 日周日下午 13 点 活动地点：北京中关村创业大街 氪空间 活动形式：线下活动 活动视频回顾：https://tech.antfin.com/community/activities/382 活动介绍 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。 欢迎 Star 我：https://github.com/alipay\nSOFA Meetup#1 北京站-服务注册中心、分布式事务重磅发布 这次的 Meetup 是 SOFAStack 第一场线下活动，也是 SOFA 开源一周年的线下庆祝会。\n我们将带来重磅发布，继续补充 SOFAStack 的开源大图，届时除了 SOFA 团队的见面交流之外，也安排了周年的庆祝环节，期待与朋友们的见面。\n重磅发布：开源蚂蚁金服分布式事务 蚂蚁金服内部的分布式事务框架已经发展十多年，广泛用于解决各类复杂业务场景的数据一致性问题，同时经受大规模业务挑战，在高性能、高可用等方面也积累了丰富的实践经验。\n这次，将带来蚂蚁金服分布式事务十多年的技术总结分享，同时也会宣布开源版本。\n重磅发布：开源蚂蚁金服注册中心 SOFARegistry SOFARegistry 是蚂蚁金服开源的服务注册中心。\nSOFARegistry： https://github.com/alipay/sofa-registry\nSOFARegistry 最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。目前 SOFARegistry 不仅全面应用于蚂蚁金服的自有业务，还随着蚂蚁金融科技输出，助力广大合作伙伴，同时也兼容开源生态。SOFARegistry 最新一代内部版与商业版，均以开源版为基础内核，在其上开发内部特性插件。\n更多内容，到现场来看\n加入 SOFA 钉钉互动群 群号：23127468，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n议程 时间 环节 嘉宾介绍 13:00 - 13:30  签到 13:40 - 14:20  《SOFAStack 开源这一年》 蚂蚁金服技术总监 杨冰 14:20 - 15:00 《SOFARegistry \u0026amp;ndash; 蚂蚁金服高性能服务注册中心开源》 蚂蚁金服服务注册中心开源负责人 尚彧 15:00 - 15:20 庆祝一周年环节 15:20 - 16:00  《SOFAFescar \u0026amp;ndash; 蚂蚁金服分布式事务开源以及实践》 蚂蚁金服分布式事务开源负责人 绍辉 16:00 - 16:40 《SOFAJRaft \u0026amp;ndash; 蚂蚁金服基于 RAFT 一致性算法的生产级高性能 Java 实现》 蚂蚁金服 SOFAJRaft 核心成员 力鲲 16:40 - 17:00  互动交流 ","date":1552277400,"description":"SOFA Meetup#1 北京站，3 月 24 日周日下午 13 点，北京中关村创业大街氪空间。","dir":"activities/sofa-meetup-1/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dd713adb17a610bef8a0f6ed06cace55","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-1/","publishdate":"2019-03-11T12:10:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofa-meetup-1/","summary":"概要 活动主题：SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布 活动时间：3 月 24 日周日下午 13 点 活动地点：北京中关村创业大街 氪空间 活动形式：","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-1/","wordcount":1037},{"author":"SOFA 团队","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFA 文档: http://www.sofastack.tech/ SOFA: https://github.com/alipay\n 最新的 SOFARPC 5.5.1 已经发布啦，本文给大家介绍下 SOFARPC v5.5.x 系列主要提供的特性以及使用方式。\nSOFARPC 作为成熟的 RPC 框架，一直致力于给用户提供稳定可靠的 RPC 框架 以及最自主的选择权。SOFARPC 的插件扩展机制可以支持各类实现的可插拔实现。\nSOFARPC 5.5 主要给开发者们带来了服务发现的新选择：Nacos 的集成 与 服务容错对 Hystrix 的集成。\n服务注册 Nacos 新选择 Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。根据 Nacos 的 Roadmap，0.8.0 已具备生产使用的能力，截止笔者撰稿时间，Nacos 已发布 0.9.0，距离 1.0.0 越来越近了。\nSOFARPC 5.5.0 开始提供对 Nacos 的集成，以下介绍两种使用方式：\n1、SOFABoot 集成 Nacos SOFABoot 从 2.5.3 开始已集成 SOFARPC 对 Nacos 的配置支持，假如开发者本机已经根据 Nacos 快速开始安装并启动 Nacos Server。\n根据 RPC 的示例工程创建一个 SOFABoot 工程，SOFABoot 工程使用 2.5.3。\n$ git clone git@github.com:alipay/sofa-rpc-boot-projects.git $ git checkout 5.x 在 application.properties 中配置服务注册中心地址信息，就能够使用 Nacos 作为注册中心。\n$ vi sofa-boot-samples/src/main/resources/application.properties com.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 启动 RPC 服务端实例工程：\nrun com.alipay.sofa.rpc.samples.invoke.InvokeServerApplication 启动成功后即可在 Nacos 服务端看到服务注册信息：Nacos 服务列表 （注：如果用户自己部署了nacos 的服务端，可以通过这个地址访问）\n启动 RPC 客户端调用工程：\nrun com.alipay.sofa.rpc.samples.invoke.InvokeClientApplication 可以看到调用成功结果，分别代表同步、异步、回调调用成功：\nsync future callback client process:callback 2、SOFARPC 独立集成 Nacos SOFARPC 独立使用集成 Nacos 也很简单，只需要将注册中心地址设置为 Nacos 服务地址即可。\n引入 SOFARPC：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; API 方式发布服务：\n# 构造服务注册中心配置 RegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;nacos\u0026amp;quot;) .setSubscribe(true) .setAddress(\u0026amp;quot;127.0.0.1:8848\u0026amp;quot;) .setRegister(true); # 构造服务端口配置 ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setHost(\u0026amp;quot;0.0.0.0\u0026amp;quot;) .setPort(12200); # 构造服务发布者 ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRef(new HelloServiceImpl()) .setServer(serverConfig) .setRegister(true) .setRegistry(Lists.newArrayList(registryConfig)); providerConfig.export(); 即可发布服务至 Nacos Server。\n服务容错支持 Hystrix 在大规模的分布式系统中，一个完整的请求链路会跨越多个服务，其中每一个节点出现故障都将放大到全局，轻则造成执行逻辑崩溃，重则消耗掉所有资源拖垮整个系统。\nHystrix 是 Netflix 开源的容错组件，提供以下功能以解决该问题：\n 通过线程池或是信号量对资源进行隔离，避免依赖服务在故障时使用大量资源拖垮整个应用 使用熔断器模式（Circuit Breaker pattern）实现请求故障服务的快速失败（fail-fast），避免故障服务所造成的延时影响整体请求的延时 提供故障降级（Fallback）使用户可以编写优雅降级的策略，防止故障传递到上层 提供准实时的监控指标，使每一个依赖服务的请求结果和延时可观测 在 SOFARPC 中使用 Hystrix Hystrix 本身使用命令模式（Command pattern）实现了 API，我们在 SOFARPC 中对其进行了封装，只需要简单配置即可开启相关功能。\nHystrix 作为 SOFARPC 的可选模块默认不会进行加载，所以首先需要显式在项目中添加 Hystrix 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后通过开关选择开启全局的 Hystrix 支持，或是只对一部分 Consumer 开启：\n// 全局开启 RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // …","date":1551769200,"description":"最新的 SOFARPC 5.5.1 已经发布啦，本文给大家介绍下 SOFARPC v5.5.x 系列主要提供的特性以及使用方式。","dir":"blog/sofarpc-5.5.x-nacos-hystrix/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c712254801354ae1b1bd22cd39b80ec2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","publishdate":"2019-03-05T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFA 文档: http://www.sofastack.tech/ SOFA: https://github.com/alipay","tags":["SOFARPC"],"title":"SOFARPC 5.5.X 新版发布 | 集成 Nacos 与 Hystrix","type":"blog","url":"/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","wordcount":2473},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo） 活动时间：2 月 28 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 SOFA:Channel/，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\nSOFA:Channel/ 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n本期 SOFAChannel 为 SOFARPC 专场，分为上下两篇，将采用内容分享与 Demo 实际操作结合的形式进行。\n本期为上篇，下篇将在 2 月 28 日开展，记得关注哟~\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 时间：2019-02-21 19:00-20:00 《SOFARPC 性能优化（上）—— 详解优化设计点》 蚂蚁金服 SOFA 团队 碧远 在业务规模大并发极高的情况下，RPC 对性能的追求就变得极为重要，任何一点小的优化都会累积提高业务整体性能。 本期手把手带你解读： 自定义通信协议使用有哪些注意细节？ SOFARPC 如何进行连接保持？ 在 IO 线程池中批量解包带来的性能提升有哪些？\n嘉宾 蚂蚁金服 SOFA 团队 碧远\n","date":1551349200,"description":"本次为下半场，2 月 28 日晚 7 点，线上直播。","dir":"activities/sofa-channel-3/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"202f32cfe0c8a1c3aacbf435389a956f","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-3/","publishdate":"2019-02-28T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-3/","summary":"概要 活动主题：SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo） 活动时间：2 月 28 日周四晚 7 点 活动形","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo）","type":"activities","url":"/sofastack.tech/activities/sofa-channel-3/","wordcount":477},{"author":"碧远","categories":"SOFARPC","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第三期，SOFARPC 性能优化（下），进一步分享 SOFARPC 在性能上做的一些优化。 本期你将收获：\n 如何控制序列化和反序列化的时机； 如何通过线程池隔离，避免部分接口对整体性能的影响； 如何进行客户端权重调节，优化启动期和故障时的性能； 服务端 Server Fail Fast 支持，减少无效操作； 在 Netty 内存操作中，如何优化内存使用。 欢迎加入直播互动钉钉群：23127468，不错过每场直播。\n 大家好，今天是 SOFAChannel 第三期，欢迎大家观看。\n我是来自蚂蚁金服中间件的雷志远，花名碧远，目前负责 SOFARPC 框架的相关工作。在上一期直播中，给大家介绍了 SOFARPC 性能优化方面的关于自定义协议、Netty 参数优化、动态代理等的优化。\n 往期的直播回顾，可以在文末获取。\n本期互动中奖名单： @司马懿 @邓从宝 @雾渊，请文章下方回复进行礼品领取\n 今天我们会从序列化控制、内存操作优化、线程池隔离等方面来介绍剩余的部分。\n序列化优化 上次介绍了序列化方式的选择，这次主要介绍序列化和反序列化的时机、处理的位置以及这样的好处，如避免占用 IO 线程，影响 IO 性能等。\n上一节，我们介绍的 BOLT 协议的设计，回顾一下：\n可以看到有这三个地方不是通过原生类型直接写的：ClassName，Header，Content 。其余的，例如 RequestId 是直接写的，或者说跟具体请求对象无关的。所以在选择序列化和反序列化时机的时候，我们根据自己的需求，也精确的控制了协议以上三个部分的时机。\n对于序列化 serializeClazz 是最简单的：\nbyte[] clz = this.requestClass.getBytes(Configs.DEFAULT_CHARSET); 直接将字符串转换成 Byte 数组即可，跟具体的任何序列化方式，比如跟采用 Hessian 还是 Pb 都是无关的。\nserializeHeader 则是序列化 HeaderMap。这时候因为有了前面的 requestClass，就可以根据这个名字拿到SOFARPC 层或者用户自己注册的序列化器。然后进行序列化 Header，这个对应 SOFARPC 框架中的 SofaRpcSerialization 类。在这个类里，我们可以自由使用本次传输的对象，将一些必要信息提取到Header 中，并进行对应的编码。这里也不跟具体的序列化方式有关，是一个简单 Map 的序列化，写 key、写 value、写分隔符。有兴趣的同学可以直接看源码。\n源码链接：https://github.com/alipay/sofa-bolt/blob/531d1c0d872553d92fc55775565b3f7be8661afa/src/main/java/com/alipay/remoting/rpc/protocol/RpcRequestCommand.java#L66\nserializeContent 序列化业务对象的信息，这里 RPC 框架会根据本次用户配置的信息决定如何操作序列化对象，是调用 Hessian 还是调用 Pb 来序列化。\n至此，完成了序列化过程。可以看到，这些操作实际上都是在业务发起的线程里面的，在请求发送阶段，也就是在调用 Netty 的写接口之前，跟 IO 线程池还没什么关系，所以都会在业务线程里先做好序列化。\n对于反序列化 介绍完序列化，反序列化的时机就有一些差异，需要重点考虑。在服务端的请求接收阶段，我们有 IO 线程、业务线程两种线程池。为了最大程度的配合业务特性、保证整体吞吐，SOFABolt 设计了精细的开关来控制反序列化时机。\n具体选择逻辑如下：\n体现在代码的这个类中。\ncom.alipay.remoting.rpc.protocol.RpcRequestProcessor#process 从上图可以看到 反序列化 大致分成以下三种情况，适用于不同的场景。\n IO 线程池动作 业务线程池 使用场景 反序列化 ClassName 反序列化 Header 和 Content 处理业务 一般 RPC 默认场景。IO 线程池识别出来当前是哪个类，调用用户注册的对应处理器 反序列化 ClassName 和 Header 仅反序列化 Content 和业务处理 希望根据 Header 中的信息，选择线程池，而不是直接注册的线程池 一次性反序列化 ClassName、Header 和 Content，并直接处理 没有逻辑 IO 密集型的业务 线程池隔离 经过前面的介绍，可以了解到，由于业务逻辑通常情况下在 SOFARPC 设置的一个默认线程池里面处理，这个线程池是公用的。也就是说， 对于一个应用，当他作为服务端时，所有的调用请求都会在这个线程池中处理。\n举个例子：如果应用 A 对外提供两个接口，S1 和 S2，由于 S2 接口的性能不足，可能是下游系统的拖累，会导致这个默认线程池一直被占用，无法空闲出来被其他请求使用。这会导致 S1 的处理能力受到影响，对外报错，线程池已满，导致整个业务链路不稳定，有时候 S1 的重要性可能比 S2 更高。\n因此，基于上面的设计，SOFARPC 框架允许在序列化的时候，根据用户对当前接口的线程池配置将接口和服务信息放到 Header 中，反序列化的时候，根据这个 Header 信息选择到用户自定义的线程池。这样，用户可以针对不同的服务接口配置不同的业务线程池，可以避免部分接口对整个性能的影响。在系统接口较多的时候，可以有效的提高整体的性能。\n内存操作优化 介绍完线程池隔离之后，我们介绍一下 Netty 内存操作的一些注意事项。在 Netty 内存操作中，如何尽量少的使用内存和避免垃圾回收，来优化性能。先看一些基础概念。\n内存基础 在 JVM 中内存可分为两大块，一个是堆内存，一个是直接内存。\n堆内存是 JVM 所管理的内存。所有的对象实例都要在堆上分配，垃圾收集器可以在堆上回收垃圾，有不同的运行条件和回收区域。\nJVM 使用 Native 函数在堆外分配内存。为什么要在堆外分配内存？主要因为在堆上的话， IO 操作会涉及到频繁的内存分配和销毁，这会导致 GC 频繁，对性能会有比较大的影响。\n注意：直接分配本身也并不见得性能有多好，所以还要有池的概念，减少频繁的分配。\n因此 JVM 中的直接内存，存在堆内存中的其实就是 DirectByteBuffer 类，它本身其实很小，真的内存是在堆外，通过 JVM 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。直接内存不会受到 Java 堆的限制，只受本机内存影响。当然可以设置最大大小。也并不是 Direct 就完全跟 Heap 没什么关系了，因为堆中的这个对象持有了堆外的地址，只有这个对象被回收了，直接内存才能释放。\n其中 DirectByteBuffer 经过几次 young gc 之后，会进入老年代。当老年代满了之后，会触发 Full GC。\n因为本身很小， …","date":1551337200,"description":"本文根据 SOFAChannel#3 直播分享整理，进一步分享 SOFARPC 在性能上做的一些优化。","dir":"blog/sofa-channel-3-retrospect/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7a816fa5f942ce857c10ebb1c416482d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-3-retrospect/","publishdate":"2019-02-28T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-channel-3-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第三期，SOFARPC 性能优化（下），进一步分享 SOFARPC 在性能上做的一些优化。 本期你","tags":["SOFARPC","SOFAChannel"],"title":"SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-3-retrospect/","wordcount":5775},{"author":"心贵","categories":"Kubernetes","content":" 此文章适合没有任何 Kubernetes/容器/Docker 经验的同学 — 在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。此文章阅读耗时大概 15 分钟。\n 蚂蚁金服资源调度组致力于将 Kubernetes 落地到世界上最有价值的金融科技独角兽公司，欢迎联系作者微信： answer1991chen 咨询招聘事宜。\n文章 Markdown 源码位于 https://github.com/answer1991/articles/blob/master/Kubernetes-is-the-next-generation-os.md ，遵从 Apache License 2.0 开源协议。\n导言 此文章着重介绍如何在入门阶段使用 Kubernetes，以及要面向 Kubernetes 编程带来的优势，不会介绍复杂的 Kubernetes 架构、实现。因此此文章适合没有任何 Kubernetes/容器/Docker 经验的同学，对 Kubernetes 有了解的同学也可以从此文章里面获取一些灵感，可以更加酷炫的玩转 Kubernetes。\n希望在阅读完此文章之后，你可以从 “我需要一个 Linux VM 做开发、测试和部署”，变成 “我需要一个 Kubernetes 做开发、测试和部署”。\nKubernetes 是下一代操作系统 Kubernetes 是这几年非常热门的一个词汇，大概所有的软件工程师都已经听说过这个词。\n那么 Kubernetes 到底是什么呢？可能 Google 会告诉你很多，但是我想告诉你的是：Kubernetes 是下一代操作系统；一个 Kubernetes 集群是一个资源无限大(可扩容)的虚拟机。而且，Kubernetes 的接口是是声明式的，是天然面向分布式系统而设计的（下面会详细介绍）。\n说到这里，大家估计立刻就有疑问了。我想大概是这些：\nQ: 那么，Linux、Windows 要被淘汰了？\nA: 不会被淘汰，只是 Linux、Windows 是一个底层的单机操作系统。而我们这些普通的应用软件工程师将来都不会跟Linux 打交道了，都会使用 Kubernetes 这个更上层、同时功能也更强大的操作系统。\nQ: 那么，我不学 Kubernetes 可以吗？\nA: 不行！在未来不久的某一天，也许云厂商只卖 Kubernetes “虚拟机”了：阿里云不单独卖 ecs 了，亚马逊AWS，微软云，Google 云等各种云厂商都不卖 Linux 虚拟机了。如果你想买单机版的 Linux 虚拟机，他们都会一脸惊讶的问你，你买那么底层的、功能那么薄弱的计算机干什么？就像你现在从云厂商那里买不到一个还没有安装 Linux 的虚拟机一样。以后，云厂商交付的 “虚拟机” 必定是 “集群级别的虚拟机” ，而 “集群级别的虚拟机” 的操作系统就是 Kubernetes。\n在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。\nQ: 那这样的话，我买不到 Linux 虚拟机，我连学习 Linux 的机会都没有了？\nA: 当然不是，有了 Kubernetes，你可以在 1秒内自己搞一个任何 Linux 发行版本的 “单机虚拟机” 出来。\nQ: Kubernetes 真的是一个操作系统？ Show me\u0026amp;hellip;.\nA:\n 功能/名词 单机 Linux Kubernetes 说明 Shell, CMD sh, bash kubectl kubectl 是 Kubernetes 的 shell 工具，有了 kubectl 你就可以连接并管理 Kubernetes 这个超级虚拟机了。 用户，登录 Linux User, Group, ssh 登录 kubeconfig 文件类似 Linux ssh 的 .key 文件，用户使用 kubeconfig 访问 Kubernetes 就自带了用户信息。Kubernetes 能根据用户限制权限，也能限制用户能使用的资源。kubectl 使用 kubeconfig 访问 Kubernetes 就好比使用 .ssh key 访问 Linux Kubernetes 集群管理员(或者自动化的申请系统)为用户颁发 kubeconfig 文件。 进程 进程 Pod Pod 就是 Kubernetes 这个 “超级虚拟机” 的进程。 管理进程 ps, kill kubectl get po, kubectl delete pod 发布、升级、管理 “进程”(或者说应用) 配置管理 登录各个 Linux VM，替换机器上的文件。 kubectl apply -f ./cm.yaml 使用 ConfigMap 管理应用的配置文件，一次提交，进程的每个实例自动生效新的配置。由于篇幅管理，使用 ConfigMap 配置应用（“进程”）启动参数不在此文章里面举例。 发布、管理、升级应用 在 Linux 上面发布一个应用，需要一顿疯狂的操作：先阅读如何发布、参数有什么、下载二进制包、搞定一些配置文件，然后运行应用。 kubectl apply -f ./my-app.yaml my-app.yaml 可能是应用提供商提供的、面向 Kubernetes 发布应用的“菜单”文件(为什么叫“菜单”我后面会介绍)。只要提交这个“菜单”，应用就部署好了。Kubernetes 让一切简单，而且，它是分布式，是天然容灾的。只要向 Kubernetes 提交 Deployment 这样的“资源”即可，下文有介绍。 限制应用资源 一顿疯狂的操作，把应用进程的 Cgroup 限制好。 发布应用时已经做了 Kubernetes 让一切简单。 分布式应用发布 在各个 Linux 虚拟机上面发布好应用，然后把他们组网。 发布应用时已经做了 还是那句话，Kubernetes 让一切简单。 分布式应用容灾 搞个监控，监控我们各个 Linux 虚拟机上面的应用是不是不健康了。不健康了的话，我们起床，来一次“一顿操作猛如虎”的故障恢复操作。 / 天然容灾，安心睡你的觉。 数据持久化，故障时数据迁移 “一顿操作猛如虎” 用 PV（持久化存储卷），容灾把应用的一个应用实例从 “节点一” 切换到了 “节点二”，都不用做任何数据迁移。新的应用实例起来就能使用老数据。 还是那句话，Kubernetes 让一切简单。我都不用关心这个事情。（由于篇幅管理，下文的例子中也不会涉及 PV 的例子） “一顿操作猛如虎” 听起来很酷，但是你在做一些没必要的事情，同时你做了这些事情并不讨好你的老板，可能在因为你的失误操作引起更大的故障和问题。\n面向 Kubernetes 做最简单的操作，达到最佳的效果，才是更酷的事情。\nA: 行了行了，别说那么多了，我还是需要一个 Linux VM。\nQ: 好的，我给您一个 Kubernetes，然后给你一个 基础 OS Pod “菜单”文件，然后您自己就可以创建任何一个 Linux 发行版、任何一个 Linux 版本的的 Linux VM …","date":1551078000,"description":"希望在阅读完此文章之后，你可以从 “我需要一个 Linux VM 做开发、测试和部署”，变成 “我需要一个 Kubernetes 做开发、测试和部署”。","dir":"blog/kubernetes-the-next-gen-os/","fuzzywordcount":8600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"09e6dbd10bffdeea13865fc45e3b3ee5","permalink":"https://sofastack.github.io/sofastack.tech/blog/kubernetes-the-next-gen-os/","publishdate":"2019-02-25T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/kubernetes-the-next-gen-os/","summary":"此文章适合没有任何 Kubernetes/容器/Docker 经验的同学 — 在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。","tags":["Kubernetes"],"title":"Kubernetes 是下一代操作系统 | 面向 Kubernetes 编程","type":"blog","url":"/sofastack.tech/blog/kubernetes-the-next-gen-os/","wordcount":8595},{"author":"碧远","categories":"SOFARPC","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第二期，主要分享 SOFARPC 在性能上做的一些优化，这个系列会分成上下两部分进行分享，今天是 SOFARPC 性能优化（上），也会对本次分享中的一些结论，提供部分代码 Demo，供大家了解验证。 欢迎加入直播互动钉钉群：23127468，不错过我们每场直播。\n 大家好，今天是我们 SOFAChannel 第二期。欢迎大家观看。\n我是来自蚂蚁金服中间件的雷志远，花名碧远，目前在负责 SOFARPC 框架相关工作。\n去年的时候，我们和外部的爱好者们一起，做了一个基于 SOFARPC 的源码解析系列，我同事已经发到群里了，大家可以保存，直播之后查看。\nSOFARPC 源码解析系列：（点击【剖析 | SOFARPC 框架】即可查看）\nhttps://www.sofastack.tech/blog/ 今年，基于源码解析的基础，我们来多讲讲实践，如何应用到大家的业务，来帮助大家解决实际问题。在直播过程中有相关的问题想提问，可以在钉钉群互动。\n前言 在上一期中，余淮分享了《从蚂蚁金服微服务实践谈起》。介绍了蚂蚁微服务的起源，以及之后服务化，单元化的情况。同时介绍了 SOFAStack 目前开源的情况。最后也分享了一下整个微服务中 SOFARPC 的设计与实现。\n本期，我们主要分享 SOFARPC 在性能上做的一些优化。这个系列会分成上下两部分进行分享，今天是 SOFARPC 性能优化（上），也会对本次分享中的一些结论，提供部分代码 Demo，供大家了解验证。\n我们先简要介绍一下 SOFARPC 的框架分层。这个在上次的分享中已经进行了介绍。\n下层是网络传输层，依次是协议，序列化，服务发现和 Filter 等。\nTransport 主要负责数据传输，可以是 Http2Transport，也可以是 BoltTransport，还有可能是其他。\nProtocol 层是协议，是 Rest 还是 Bolt ，或者是 Dubbo 。\nSerialization 是序列化，对于每种协议，可以是用不同的序列化方式，比如 hessian，pb，json 等。\nFilter 是通用的过滤器层，主要是为了留出一些扩展，完成一些其他扩展功能，比如 Tracer 的埋点等。\nRouter 是路由层，主要是做寻址，这里可能是 Zk，也可能是 LVS，也可能是直连。Cluster 是客户端集群方式的表示。\n自定义通讯协议使用 首先我想介绍一下自定义通讯协议。\n在说明自定义通讯协议之前，我先简单介绍一下通讯协议。在TCP之上，RPC框架通常还需要将请求和响应数据进行一定的封装，组装成 Packet，然后发送出去。这样，服务端收到之后，才能正确识别整个 TCP 发过来的字节流中，哪一部分是我们可以进行处理的一个完整单位。反之，客户端收到服务端的TCP 数据流也是如此。\n有了上面的共识之后，我们要回答下面两个问题：\n 为什么要自定义，不使用 Http2/Dubbo/Rest/Grpc？ 自定义之后，带来了什么好处呢？ Http2 虽然更为通用，但是一方面，出现较晚，迁移转换成本高，并且通用则意味着传输的辅助数据会变多，会有一些额外的信息需要传递或者判断。对于序列化反序列化的控制上，也不是很好扩展操作。\n而 Dubbo，协议简单强大。但是一些元信息需要解析，Header 中传输的数据太少，很多都需要依赖 body 中的数据反序列化完成后才能使用，头部的信息太少。\n而使用了自研的协议之后，Header 中可自定义传输更多的元信息，序列化方式，Server Fail Fast，服务端线程隔离等也都成为可能。甚至蚂蚁在 ServiceMesh 的场景下，Mesh 本身也能利用 Bolt 的协议，进行部分数据的读取，而不依赖具体的序列化实现。\n经过我们的实践，大致来看，目前给我们带来的好处主要有以下的能力：\n Server Fast 的支持 Header 和 Body 的分开序列化 Crc 校验的支持 版本的支持，预防未来可能出现的更好的设计方案 多种序列化方式的支持 安全认证，Mesh 路由 如果你要自己设计一个通讯协议。可以考虑使用 BOLT 协议，或者参考进行更好的设计和优化。\n关于 SOFABolt 相关的源码解析，也可以通过这个系列来了解。\nSOFABolt 源码解析系列：点击【剖析 | SOFABOLT 框架】即可查看） https://www.sofastack.tech/blog Netty 性能参数优化 在介绍了自定义通讯协议之后，也就是确定好了怎么封包解包之后，还需要确定传输层的开发。一个 RPC 框架从现在的情况来看，一般不太可能完全基于 JAVA 的 NIO 或者其他 IO 进行直接的开发，主要是一些 NIO 原生的问题和使用难度，而成熟的，目前可选的不多。基本上，大家都会基于 Netty 进行开发，HSF/Dubbo/Motan 等都是这样。\n直接使用是比较简单的。在 Netty 的 Bootstrap 的设置中，有一些可选的优化项，有必要跟大家分享一下。\n1. SO_REUSEPORT/SO_REUSEADDR - 端口复用(允许多个 socket 监听同一个IP+端口)\nSO_REUSEPORT 支持多个进程或者线程绑定到同一端口，提高服务器的接收链接的并发能力，由内核层面实现对端口数据的分发的负载均衡，在服务器 socket 上没有了锁的竞争。\n同时 SO_REUSEADDR也要打开，这样针对 time-wait 链接 ，可以确保 server 重启成功。在一些服务端启动很快的情况下，可以防止启动失败。\n2. TCP_FASTOPEN - 3次握手时也用来交换数据\n三次握手的过程中，当用户首次访问服务端时，发送 syn 包，server 根据客户端 IP 生成 cookie ，并与 syn+ack 一同发回客户端；客户端再次访问服务端时，在 syn 包携带 TCP cookie；如果服务端校验合法，则在用户回复 ack 前就可以直接发送数据；否则按照正常三次握手进行。也就是说，如果客户端中途断开，再建联的时候，会同时发送数据，会有一定的性能提升。\nTFO 提高性能的关键是省去了热请求的三次握手，这在小对象传输较多的移动应用场景中，能够极大提升性能。\nNetty 中仅在 Epoll 的时候可用 Linux特性，不能在 Mac/Windows 上使用，SOFARPC 未开启。\n3. TCP_NODELAY-关闭 (纳格) Nagle 算法，再小的包也发送，而不是等待\nTCP/IP 协议中针对 TCP 默认开启了 Nagle 算法。Nagle 算法通过减少需要传输的数据包个数，来优化网络。但是现在的环境下，网络带宽足够，需要进行关闭。这样，对于传输数据量小的场景，能很好的提高性能，不至于出现数据包等待。\n4. SO_KEEPALIVE –开启 TCP 层面的 Keep Alive 能力\n这个不多说，开启一下 TCP 层面的 Keep Alive 的能力。\n5. WRITE_BUFFER_WATER_MARK …","date":1551078000,"description":"本文根据 SOFAChannel#2 直播分享整理，主要分享 SOFARPC 在性能上做的一些优化。","dir":"blog/sofa-channel-2-retrospect/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6751c882f7879a7dd9c9f49823410ffc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-2-retrospect/","publishdate":"2019-02-25T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-2-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第二期，主要分享 SOFARPC 在性能上做的一些优化，这个系列会分成上下两部分进行分享，今天","tags":["SOFARPC","SOFAChannel"],"title":"SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-2-retrospect/","wordcount":5077},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 活动时间：2 月 21 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 SOFA:Channel/，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\nSOFA:Channel/ 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n本期 SOFAChannel 为 SOFARPC 专场，分为上下两篇，将采用内容分享与 Demo 实际操作结合的形式进行。\n本期为上篇，下篇将在 2 月 28 日开展，记得关注哟~\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 时间：2019-02-21 19:00-20:00 《SOFARPC 性能优化（上）—— 详解优化设计点》 蚂蚁金服 SOFA 团队 碧远 在业务规模大并发极高的情况下，RPC 对性能的追求就变得极为重要，任何一点小的优化都会累积提高业务整体性能。 本期手把手带你解读： 自定义通信协议使用有哪些注意细节？ SOFARPC 如何进行连接保持？ 在 IO 线程池中批量解包带来的性能提升有哪些？\n嘉宾 蚂蚁金服 SOFA 团队 碧远\n","date":1550744400,"description":"本次为上半场，2 月 21 日晚 7 点，线上直播。","dir":"activities/sofa-channel-2/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3140990819c0601c041bf5091405220b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-2/","publishdate":"2019-02-21T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-2/","summary":"概要 活动主题：SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 活动时间：2 月 21 日周四晚 7 点 活动形式：线上直播 直播视","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点","type":"activities","url":"/sofastack.tech/activities/sofa-channel-2/","wordcount":468},{"author":"卫恒","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n本文为《剖析 | SOFATracer 框架》第一篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\n 0、前言 在单体应用时代，我们不需要花费时间去关心调用链路这个东西。但是链路跟踪不仅仅是在分布式场景下才会有，即使是单体应用，同样也会存在调用链路。例如，我们把应用中的每个服务接口作为一个链路节点，那么从请求进来到返回响应，把这个过程中多历经的所有的方法接口串联起来，就能组成一条完整的链路，如下图所示：\n对于单体应用而言，如果访问一个资源没有成功，那么我们可以很快的锁定是哪一台机器，然后通过查询这台机器上的日志就能定位问题。\n但是在微服务体系架构下，这种方式会显得非常无力。对于一个稍具规模的应用来说，一次请求可能会跨越相当多的服务节点，在这种情况下，如果一个请求没有得到成功的响应，就不能确定到底是哪个节点出了问题。\n因此在面对这种复杂的大规模分布式集群来实现的服务体系来说，就需要一些可以帮助理解各个应用的线上调用行为、并可以分析远程调用的组件。\n基于上述背景，蚂蚁金服开源了基于 OpenTracing 规范实现的 SOFATracer 分布式链路跟踪组件，为实施大规模服务化体系架构场景下提供了链路跟踪的解决方案。\n在介绍 SOFATracer 之前，先来了解一下 Opentracing 规范。\n1、Opentracing 简介 首先来解释下 OpenTracing 是什么OpenTracing 致力于为分布式跟踪创建更标准化的API和工具，它由完整的API规范、实现该规范的框架、库以及项目文档组成。\nOpenTracing 提供了一套平台无关、厂商无关的 API，这样不同的组织或者开发人员就能够更加方便的添加或更换追踪系统的实现。 OpenTracing API 中的一些概念和术语，在不同的语言环境下都是共享的。\n1.1、数据模型 Opentracing 规范中，一条 trace 链路是由多个与之关联的 span 组成，一条链路整体可以看做是一张有向无环图，各个span之间的边缘关系被称之为“References”。下面是官方提供的示例：\n如果已时间轴维度来看的话，也可以表现为下面的形式(官方示例)：\n root span : 当前链路中的第一个 span ChildOf 和 FollowFrom 是目前被定义的两种 References 类型 ChildOf : 父级 span某种程度上取决于子span （子span的结果可能会对父span产生影响） FollowFrom : 父 Span不以任何方式依赖子 Span 但是为了简化 span 之间的这种依赖关系，在具体实现时通常会将具有嵌套关系的作为 ChildOf，平行执行的作为FollowFrom，比如：\na、ChildOf 示例\n在 methodA 中调用了 method B :\nmethodA(){ // spanA start methodB(); } // spanA finish methodB(){ // spanB start } // spanB finish 产生的 span在时间维度上展现的视角如下：\n这种关系一般会 表示为 SpanB ChildOf SpanA 。\nb、FollowFrom 示例\nmethod 方法中，methodA执行之后 methodB 执行 :\nmethod(){ methodA(); methodB(); } 产生的 span在时间维度上展现的视角如下：\n这种关系一般会 表示为 SpanB FollowFrom SpanA 。\n1.2、API Opentracing API 是对分布式链路中涉及到的一些列操作的高度抽象集合。Opentracing 中将所有核心的组件都声明为接口，例如 Tracer、Span、SpanContext、Format（高版本中还包括 Scope 和 ScopeManager）等。SOFATracer 使用的版本是 0.22.0 ，主要是对 Tracer、Span、SpanContext 三个概念模型的实现。下面就针对这三个组件结合 SOFATracer 来分析。\n1.3、SOFATracer 标准实现 下图为 SOFATracer 中对于这三个核心接口实现的类图结构：\n 由于篇幅原因，下面的介绍过程中一些点不会展开说明，有兴趣的同学可以自行官网查看完整的 OpenTracing-api 规范 （https://opentracing.io/specification/）。\n a、Tracer \u0026amp;amp; SofaTracer\nTracer 是一个简单、广义的接口，它的作用就是构建 span 和传输 span 。核心接口列表如下：\n 接口 描述 SpanBuilder buildSpan(String operationName) 根据指定的operationName构建一个新的span void inject(SpanContext spanContext, Format format, C carrier); 将 spanContext 以 format 的格式注入到 carrier 中 SpanContext extract(Format format, C carrier); 以 format 的格式从carrier中解析出 SpanContext SofaTracer 实现了 Tracer 接口，并扩展了采样、数据上报等能力。\nb、Span \u0026amp;amp; SofaTracerSpan\nSpan 是一个跨度单元，在实际的应用过程中，Span 就是一个完整的数据包，其包含的就是当前节点所需要上报的数据。核心接口列表如下：\n 接口 描述 SpanContext context() 从 span 中获取 SpanContext void finish()/void finish(long finishMicros) 结束一个 span void close() 关闭 span Span setTag(String key, value) 设置 tags Span log(long timestampMicroseconds, String event) 设置 log 事件 Span setOperationName(String operationName) 设 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第一篇。","dir":"blog/sofa-tracer-overview/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ff58d686746c53b81af210eaf17bb154","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-overview/","publishdate":"2019-02-21T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-overview/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-overview/","wordcount":4138},{"author":"卫恒","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第二篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n 0、前言 在《蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析》一文中已经对 SOFATracer 进行了概要性的介绍。从对 SOFATracer 的定义可以了解到，SOFATracer 作为一个分布式系统调用跟踪的组件，是通过统一的 TraceId 将调用链路中的各种网络调用情况以数据上报的方式记录下来，以达到透视化网络调用的目的。\n本篇将针对SOFATracer的数据上报方式进行详细分析，以帮助大家更好的理解 SOFATracer 在数据上报方面的扩展。\n1、Reporter 整体模型 本节将对 SOFATracer 的 Report 模型进行整体介绍，主要包括两个部分：\n Reporter 的接口设计及实现； 数据上报流程。 1.1、Reporter 的接口设计及实现 数据上报是 SofaTracer 基于 OpenTracing Tracer 接口扩展实现出来的功能；Reporter 实例作为 SofaTracer 的属性存在，在构造 SofaTracer 实例时，会初始化 Reporter 实例。\n1.1.1、Reporter 接口设计 Reporter 接口是 SOFATracer 中对于数据上报的顶层抽象，核心接口方法定义如下：\n//获取 Reporter 实例类型 String getReporterType(); //输出 span void report(SofaTracerSpan span); //关闭输出 span 的能力 void close(); Reporter 接口的设计中除了核心的上报功能外，还提供了获取 Reporter 类型的能力，这个是因为 SOFATracer 目前提供的埋点机制方案需要依赖这个实现。\n1.1.2、Reporter 接口实现 Reporter 的类体系结构如下：\nReporter 的实现类有两个，SofaTracerCompositeDigestReporterImpl 和 DiskReporterImpl ：\n SofaTracerCompositeDigestReporterImpl：组合摘要日志上报实现，上报时会遍历当前 SofaTracerCompositeDigestReporterImpl 中所有的 Reporter ，逐一执行 report 操作；可供外部用户扩展使用。 DiskReporterImpl：数据落磁盘的核心实现类，也是目前 SOFATracer 中默认使用的上报器。 1.2、数据上报流程分析 数据上报实际都是由不同的链路组件发起，关于插件扩展机制及埋点方式不是本篇范畴，就不展开了。这里直接来看数据上报的入口。\n在 Opentracing 规范中提到，Span#finish 方法是 span 生命周期的最后一个执行方法，也就意味着一个 span 跨度即将结束。那么当一个 span 即将结束时，也是当前 span 具有最完整状态的时候。所以在 SOFATracer 中，数据上报的入口就是 Span#finish 方法，这里贴一小段代码：\n//SofaTracerSpan#finish @Override public void finish(long endTime) { this.setEndTime(endTime); //关键记录:report span this.sofaTracer.reportSpan(this); SpanExtensionFactory.logStoppedSpan(this); } 在 finish 方法中，通过 SofaTracer#reportSpan 将当前 span 进行了上报处理。以这个为入口，整个数据上报的调用链路如下图所示：\n整个上报调用流程其实并不是很难，这里留两个问题：\n 如何构造 clientRportor 和 serverReporter 的，依据是什么？ 摘要日志和统计日志是怎么落盘的？ 第一个问题会在插件埋点解析篇中给出答案；第二个问题下面来看。\n2、日志落盘 前面已经提到，SOFATracer 本身提供了两种上报模式，一种是落到磁盘，另外一种是上报到zipkin。在实现细节上，SOFATracer 没有将这两种策略分开以提供独立的功能支持，而是将两种上报方式组合在了一起，然后再通过配置参数来控制是否进行具体的上报逻辑，具体参考下图：\n本节将来剖析下日志落盘的实现细节。日志落盘又分为摘要日志落盘 和 统计日志落盘；摘要日志是每一次调用均会落地磁盘的日志；统计日志是每隔一定时间间隔进行统计输出的日志。\n2.1、摘要日志落盘 摘要日志落盘是基于 Disruptor 高性能无锁循环队列实现的。SOFATracer 中，AsyncCommonDigestAppenderManager 类对 disruptor 进行了封装，用于处理外部组件的 Tracer 摘要日志打印。\n 关于 Disruptor 的原理及其自身的事件模型此处不展开分析，有兴趣的同学可以自行查阅相关资料。这里直接看下 SOFATracer 中是如何使用 Disruptor 的。\n 2.1.1、消息事件模型 SOFATracer 使用了两种不同的事件模型，一种是 SOFATracer 内部使用的 StringEvent，一种是外部扩展使用的SofaTacerSpanEvent。详见：SofaTracerSpanEvent \u0026amp;amp; StringEvent 。\n2.1.2、Consumer 消费者 Consumer 是 AsyncCommonDigestAppenderManager 的内部类；实现了 EventHandler 接口，这个 Consumer 作为消费者存在，监听事件，然后通过 TraceAppender 将 span 数据 flush 到磁盘。详见：AsyncCommonDigestAppenderManager\n2.1.3、Disruptor 的初始化 Disruptor 的构建：在 AsyncCommonDigestAppenderManager 的构造函数中完成的。 //构建disruptor，使用的是 ProducerType.MULTI //等待策略是 BlockingWaitStrategy，考虑到的是CPU的 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第二篇。","dir":"blog/sofa-tracer-response-mechanism/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"350b5d9eacee1bc4b3b604236b247a3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-response-mechanism/","publishdate":"2019-02-21T10:20:00Z","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-tracer-response-mechanism/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-response-mechanism/","wordcount":5014},{"author":"米麒麟","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第四篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\nSOFATracer： https://github.com/sofastack/sofa-tracer\n 前言 由于分布式链路追踪涉及到调用的每个环节，而每个环节都会产生大量的数据，为了存储这种数据，可能需要大量的成本，另外在实际的生产过程中并非所有数据都是值得关注的，基于这些原因，SOFATracer 提供链路数据采样功能特性，一方面可以节约 I/O 磁盘空间，另一方面需要把无关数据直接过滤筛选。目前 SOFATracer 内置两种采样策略，一种是基于固定比率的采样，另一种是基于用户扩展实现的自定义采样。自定义采样模式将 SofaTracerSpan 实例作为采样计算的条件，用户可以基于此实现自行扩展自定义的采样规则。\n本篇文章主要介绍 SOFATracer 数据采样策略原理，通过剖析源码实现详细讲述采样规则算法。\nDapper 论文中的采样模型与策略 跟踪采样模型 每个请求都会利用到大量服务器高吞吐量的线上服务，这是对有效跟踪最主要的需求之一。这种情况需要生成大量的跟踪数据，并且他们对性能的影响是最敏感的。延迟和吞吐量带来的损失在把采样率调整到小于1/16之后就能全部在实验误差范围内。\n在实践中，我们发现即便采样率调整到 1\u0026amp;frasl;1024 仍然是有足够量的跟踪数据用来跟踪大量的服务。保持链路跟踪系统的性能损耗基线在一个非常低的水平是很重要的，因为它为那些应用提供了一个宽松的环境使用完整的 Annotation API 而无惧性能损失。使用较低的采样率还有额外好处，可以让持久化到硬盘中的跟踪数据在垃圾回收机制处理之前保留更长时间，这样为链路跟踪系统的收集组件提供更多灵活性。\n分布式链路跟踪系统中任何给定进程的消耗和每个进程单位时间的跟踪采样率成正比。然而，在较低的采样率和较低的传输负载下可能会导致错过重要事件，而想用较高的采样率就需要能接受的相应的性能损耗。我们在部署可变采样的过程中，参数化配置采样率时，不是使用一个统一的采样方案，而是使用一个采样期望率来标识单位时间内采样的追踪。这样一来，低流量低负载会自动提高采样率，而在高流量高负载的情况下会降低采样率，使损耗一直保持在控制之内。实际使用的采样率会随着跟踪本身记录下来，这有利于从跟踪数据里准确分析排查。\n跟踪采样策略 要真正做到应用级别的透明，我们需要把核心跟踪代码做的很轻巧，然后把它植入到那些无所不在的公共组件中，比如线程调用、控制流以及 RPC 库。使用自适应的采样率可以使链路跟踪系统变得可伸缩，并且降低性能损耗。链路跟踪系统的实现要求性能低损耗，尤其在生产环境中不能影响到核心业务的性能，也不可能每次请求都跟踪，所以要进行采样，每个应用和服务可以自己设置采样率。采样率应该是在每个应用自己的配置里设置的，这样每个应用可以动态调整，特别是应用刚上线时可以适当调高采样率。一般在系统峰值流量很大的情况下，只需要采样其中很小一部分请求，例如 1\u0026amp;frasl;1000 的采样率，即分布式跟踪系统只会在 1000 次请求中采样其中的某一次。\n在 Dapper 论文中强调了数据采样的重要性，如果将每条埋点数据都刷新到磁盘上会增大链路追踪框架对原有业务性能的影响。如果采样率太低，可能会导致一些重要数据的丢失。 论文中提到如果在高并发情况下 1\u0026amp;frasl;1024 的采样率是足够的，也不必担心重要事件数据的丢失。因为在高并发环境下，一个异常数据出现一次，那么就会出现1000次。 然而在并发量不是很多的系统，并且对数据极为敏感时需要让业务开发人员手动设置采样率。\n对于高吞吐量服务，积极采样并不妨碍最重要的分析。如果一个显著的操作在系统中出现一次，他就会出现上千次。低吞吐量服务可以负担得起跟踪每一个请求。这是促使我们下决心使用自适应采样率的原因。为了维持物质资源的需求和渐增的吞吐要求之间的灵活性，我们在收集系统自身上增加了额外的采样率支持。\n如果整个跟踪过程和收集系统只使用一个采样率参数确实会简单一些，但是这就不能应对快速调整在所有部署节点上的运行期采样率配置的这个要求。我们选择了运行期采样率，这样就可以优雅的去掉我们无法写入到仓库中的多余数据。我们还可以通过调节收集系统中的二级采样率系数来调整这个运行期采样率。Dapper 的管道维护变得更容易，因为我们可以通过修改二级采样率的配置，直接增加或减少全局覆盖率和写入速度。\nSOFATracer 的采样源码剖析 SOFATracer 提供链路数据采样功能特性，支持两种采样策略：基于固定采样率的采样模式和基于用户扩展实现的自定义采样模式。\n采样接口模型 SOFATracer 提供定义链路追踪数据采样模式接口 com.alipay.common.tracer.core.samplers.Sampler，此接口 sample 方法通过 SofaTracerSpan 实例参数作为采样计算基础条件决定链路是否采样，实现丰富的数据采样规则。SOFATracer 基于 com.alipay.common.tracer.core.samplers.SamplerFactory 生成的采样器执行链路数据采样基本流程：\n 构建链路追踪器，通过采样器工厂 SamplerFactory 根据自定义采样规则实现类全限定名配置生成指定策略采样器 Sampler，其中基于用户扩展实现的采样模式优先级高，默认采样策略为基于固定采样率的采样计算规则； Reporter 数据上报 reportSpan 或者链路跨度 SofaTracerSpan 启动调用采样器 sample 方法检查链路是否需要采样，获取采样状态 SamplingStatus 是否采样标识 isSampled。 采样器的初始化 上面分析到，采样策略实例是通过 SamplerFactory 来创建的，SamplerFactory 中提供了一个 getSampler 方法用于获取采样器： 从代码片段来看，用户自定义的采样策略将会优先被加载，如果在配置文件中没有找到自定义的 ruleClassName ，则构建默认的基于固定采样率的采样器。SamplerProperties 是采样相关的配置属性，默认提供的基于固定比率的采样率是 100%，即默认情况下，所有的 Span 数据都会被记录到日志文件中。关于具体配置，在下文案例中会有详细介绍。\n采样计算 采样是对于整条链路来说的，也就是说从 RootSpan 被创建开始， …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第四篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-tracer-sampling-tracking-deep-dive/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"552e5d7feb431d3ff658a0194ead7b8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","publishdate":"2019-02-21T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 采样策略和源码剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","wordcount":4224},{"author":"J. Queue","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第三篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。 SOFATracer：https://github.com/sofastack/sofa-tracer\n SOFATracer 是一个用于分布式系统调用跟踪的组件，其核心作用就是能够在分布式场景下将请求经过的各个的链路环节的相关数据记录下来，通过这些数据将各个调用链路相关的组件串联起来。\n在日常的开发中，我们除了跟踪链路外，可能还会遇到一些场景：\n例如在线压测，我们在已有的系统中，模拟一些请求（压测流量）对我们的系统进行压力测试，那么在整个链路中我们是如何让所有的系统都识别出当前的请求是压测流量而不是正式流量的呢？压测流量的标记又是如何在整个链路传递的呢？\n又例如我们已经有了链路数据分析能力，能够快速定位到某个请求是在 A 系统里出的问题，那么我们怎么从 A 系统的业务日志里找到当前请求对应的业务日志呢？\n带着这些问题，让我们先来看看 SOFATracer 的链路透传以及支持 SLF4J MDC 扩展能力。\nSOFATracer 链路透传原理 SOFATracer 的链路透传具体包括两个点：\n 跨进程的透传，即如何将链路数据从一个进程传递到下游进程中 线程中的透传 当前请求跨进程调用结束之后，当前如何恢复 tracer 上下文信息 如何实现跨线程的透传，如在当前线程中起一个异步线程的场景 跨进程链路透传原理 跨进程透传就是将上游系统的链路数据透传到下游系统中，以便于提取出全局的链路标记，如 TracerId 、采样标记等，来实现将服务串联起来并且保持传输过程中某些属性的一致性。SOFATracer 基于 Opentracing 规范实现，因此在链路透传部分，也是基于此规范；下面就先从 Opentracing 规范中的透传开始说起。\nOpentracing 中的定义 在 OT 原文有这么一段描述 传送门\n Programmers adding tracing support across process boundaries must understand the Tracer.Inject(...)and Tracer.Extract(...) capabilities of the OpenTracing specification. They are conceptually powerful, allowing the programmer to write correct_general cross-process propagation code without being bound to a particular OpenTracing implementation; that said, with great power comes great opportunity for confusion.\n 大概意思就是：如果开发者要给应用添加跨进程的追踪能力, 首先要理解 OpenTracing 规范中的 Tracer.Inject(...)和 Tracer.Extract(…)的功能。它们在概念抽象上非常强大，而且允许开发者编写正确的、通用的跨进程传输的代码，而不需要绑定到特定的 OpenTracing 实现上去。\n总的来说就是 Opentracing 的 Tracer 接口定义了跨进程的能力，但是就是没具体实现，不同的基于此规范实现的组件，需要遵循此规范来实现具体的透传逻辑，下面是 Tracer 接口定义的用于透传的两个方法：\n 接口 描述 void inject(SpanContext spanContext, Formatformat, C carrier); 把 spanContext 以指定的 format 的格式注入到 carrier 中 SpanContext extract(Format format, C carrier); 以指定的 format 的格式从 carrier 中解析出 SpanContext 进程透传实现分析 SOFATracer 的 Tracer 的实现类是 SofaTracer， UML 图如下：\n从图中可以看出 SofaTracer 除了有跨进程传输的能力，还扩展了数据上报的能力( Reporter )和采样能力( Sampler )。数据上报能力可以参考《SOFATracer 数据上报机制和源码分析|剖析》这篇文章；采样将在下一篇文章中进行剖析。\n跨进程透传的就是 SpanContext 的内容， carrier 为传输的载体， SpanContext 的实现类为 SofaTracerSpanContext， UML 图：\n跨进程透传处理流程 SOFATracer 中跨进程传输的总体流程如下图所示：\n透传原理的实质就是：调用方编码将指定内容传输到被调方， 被调方解码获取内容的过程。\n跨进程透传的方式有很多， 在这里以客户端向服务端发起 HTTP 请求的方式来演示跨进程传输， fork 代码， 打开 sample/tracer-sample-with-httpclient 示例工程运行 HttpClientDemoApplication ，打开 logs/tracelog/spring-mvc-stat.log 即可看到链路日志， 运行结果 ：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-01-07 19:42:50.134\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:1563,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-01-07 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第三篇。","dir":"blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"82a08996dd671b01595748aa2d2fa748","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","publishdate":"2019-02-21T10:20:00Z","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 链路透传原理与SLF4J MDC 的扩展能力剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","wordcount":6294},{"author":"卫恒","categories":"SOFABoot","content":" SOFABoot 是基于 Spring Boot 的一套研发框架。 在完全兼容 Spring Boot 的基础上，SOFABoot 还提供了启动期监控检查，上下文隔离，模块化开发，类隔离，日志空间隔离等等能力 SOFABoot 地址：https://github.com/alipay/sofa-boot 本文工程案例：https://github.com/glmapper/glmapper-sofa-extension\n 春节小长假还没感觉就过去了，对于“热爱工作”的我，也早早的回到了工作岗位；感受下假期中的我和上班时的我。\n 后面拿枪的就是\u0026amp;rdquo;逼着\u0026amp;rdquo;我写文章的五花肉，上次 SOFATracer 采样用的是刀，这次用了枪！\n 模块化与扩展点 言归正传，节前 SOFABoot 发布了 2.6.x 系列版本，新特性也是相当给力，这里简单罗列下新特性：\n 支持扩展和扩展点 在刷新上下文期间支持 spring bean 的并行初始化 支持使用注解方式发布 JVM 服务 之前的文章中有 @玄北 写过的模块化的文章( 传送门 : 剖析 | 详谈 SOFABoot 模块化原理 \u0026amp;amp; 基于 SOFABoot 进行模块化开发 )，这两篇文章中介绍了模块化的几种实现方案（PS：当然主要还是为了宣传一下 SOFABoot 提供的基于 Spring 上下文隔离的模块化能力）。SOFABoot 的模块隔离方案是为了解决传统的模块化方案模块化不彻底的问题，从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化能力，每个 SOFABoot 模块使用独立的 Spring 上下文，每个模块自包含，模块与模块之间通过 JVM Service 进行通信，从而避免模块间的紧耦合。\n在 Spring 上下文隔离的情况下，各个上下文之间的 bean 是互不可见；SOFABoot 中通过发布 JVM 服务的方式使得不同模块 bean 之间的访问得以实现。但是同时又带来了另外一个问题，如果一个模块以独立 jar 的方式对外提供 api ，那么对于其他依赖此模块的模块来说，就无法去改变这个模块中的 bean 实例行为。\n在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项目，并在上面扩展，与 Spring 融合，提供了扩展点的能力。\n本篇将针对 SOFABoot 2.6.x 版本中提供的扩展点进行简单尝试，结合官方文档提供的示例，一步一步实现我们自定义的一个扩展点功能（本文过于简单，可能会引起极度舒适，请备好被子和热水袋）。\n案例背景 这里先抛出一个例子，现在有一个三方 jar ，它定义了获取数据源接口的顶层抽象；不同的业务方如果依赖这个 jar，则需要自己提供一个数据源的实现，当然其本身提供了默认实现（假设是 mysql）。基于此我们大概能够想到的方式就是基于 SPI 来提供这种扩展能力，但是对于在 Spring 上下文隔离的情况下，业务方的 Spring 上下文是无法与引入 jar 的上下文共享 bean 的，这样自然也就无法实现对原有数据源实现的扩展。\n那么这里我们就可以选择使用 SOFABoot 扩展点来实现，这里有两个比较重要的概念，也是扩展点区别于 SPI 的主要特性：\n 可以在基于 Spring 上下文隔离的情况下实现扩展 扩展的是 Spring Bean  下面基于这两个点，来完成自定义扩展点的一个案例。在实现上述案例之前我们需要先构建一个基于 Spring 上下文隔离的模块化工程，然后再简单介绍下扩展点的基本使用方式。\n构建模块化工程 SOFABoot 开源版本中并没有给出扩展点相关的案例工程，只是在测试用例中进行了详细的测试，有兴趣的同学可以看下相关测试用例代码。实际上测试用例中也没有涉及到在模块化的场景下使用扩展点，测试用例都是基于同一个Spring 上下文来完成的。本篇文章将先搭建一个简单的模块化工程，然后基于此工程来实现扩展点的能力。\n本工程主要包括 4 个模块：\n glmapper-sofa-facade // JVM 服务发布与引用的 API 包 glmapper-sofa-provider // Annotation 方式发布 JVM 服务 glmapper-sofa-consumer // Annotation 方式引用 JVM 服务 glmapper-sofa-web // 启动包含 SOFABoot 模块的 SOFA Boot 应用 官方文档及案例 中给的比较复杂，包含了多种使用服务发布和引用的方式，这里我使用了最新提供的基于注解的方式来实现；获取本文工程案例。\n扩展点基本使用 在 SOFABoot 中使用扩展点能力，需要以下三个步骤：\n 定义提供扩展能力的 bean 定义扩展点 定义扩展并使用 这三步中前两步都是由服务提供方来完成，最后一步由具体的业务使用方式来定义。\n定义提供扩展能力的 bean 本案例工程中，是将 glmapper-sofa-provider 作为服务提供方，因此也在此模块下定义一个具有扩展能力的 bean 。\n定义这个接口的实现：\n在模块的 Spring 配置文件 resources/META-INF/service-provider.xml 中，我们把这个 bean 给配置起来：\n定义扩展点 在上面的 bean 中有一个字段 word ，在实际中，我们希望这个字段能够被其他的模块自定义进行覆盖，这里我们将其以扩展点的形式暴露出来。这里先定义一个类去描述这个扩展点：\n然后在模块的 Spring 配置文件 resources/META-INF/service-provider.xml 中定义扩展点：\n name：为扩展点的名字 ref：为扩展点所作用在的 bean object：为扩展点的贡献点具体的描述，这个描述是通过 XMap 的方式来进行的（XMap 的作用是将 Java 对象和 XML 文件进行映射，这里建议通过在网上搜索下 XMap 的文档来了解 XMap） 至此服务提供端已经暴露出了扩展点，那么在服务使用端，也就是需要扩展这个 bean 的使用方就可以扩展这个bean 了。\n定义扩展 上述已经将扩展点定义好了，此时我们就可以对这个 bean 进行扩展了。扩展是具体业务使用方来做的事，在本案例中，glmapper-sofa-web 模块作为使用服务使用方，因此在 resources/META-INF/spring/web-home.xml 下进行扩展定义：\n bean：为扩展所作用在的 bean point：为扩展点的名字 content 里面的内容为扩展的定义，会通过 XMap 将内容解析为：扩展点的贡献点具体的描述对象，在这里即为 com.glmapper.bridge.extension.ExtensionDescriptor 对象 需要注意一点，glmapper-sofa-web 模块不是一个 SOFABoot 模块，这里留坑。\n 编写一个 TestController 类，这里最先 …","date":1550127600,"description":"本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。","dir":"blog/sofa-boot-extension-practice/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4f05313f7adf5401f3b5f499b43bb928","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-extension-practice/","publishdate":"2019-02-14T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-boot-extension-practice/","summary":"SOFABoot 是基于 Spring Boot 的一套研发框架。 在完全兼容 Spring Boot 的基础上，SOFABoot 还提供了启动期监控检查，上下文隔离，模块化开发，类隔离，日志空间隔离等等","tags":["SOFABoot"],"title":"SOFABoot 扩展点初体验 | SOFALab 实践系列","type":"blog","url":"/sofastack.tech/blog/sofa-boot-extension-practice/","wordcount":3773},{"author":"余淮","categories":"SOFAStack","content":" SOFA:Channel/，有趣实用的分布式架构频道。 SOFA:Channel/ 作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）。\n 大家晚上好，今天是 SOFAChannel 第一次线上直播，感谢大家的收看。\n先自我介绍下，我是来自蚂蚁金服中间件的章耿，花名余淮，目前在负责应用框架与 SOFAStack 开源相关的工作。\n今天给大家的分享主要分为三部分，第一部分是蚂蚁金服服务化演进的简介，第二部分是SOFAStack开源的情况。这两部分之前的分享也提到过，我们讲快一点，第三部分会详细介绍下 SOFARPC 的一些设计和实现细节。\n分享过程中如果大家对技术点比较感兴趣，或者其他组件感兴趣，也欢迎留言，后面的直播会安排更多的相关分享。\n蚂蚁服务化架构演进简介 大家现在对蚂蚁金服技术的概念，听得比较多的应该是“余额宝”、“相互宝”、“蚂蚁森林”、“刷脸支付”，“扫描工具地铁”、“双十一”等等这些耳耳熟能详的产品和场景。\n这些产品的背后，是蚂蚁金融科技的一套核心技术，包括 “三地五中心异地多活架构”，“金融级分布式架构”、“国产金融级分布式数据库 OceanBase”，“智能风控”，“区块链” 等诸多黑科技。\n当然，蚂蚁金服的微服务架构体系像其它传统的企业一样，也不是一开始就这么高大上，也是随着业务的发展慢慢演进而来的。下面给大家简单介绍下演进的过程。\n这个支付宝最早的架构示意图，可以看到当时支付宝只是电商后台的一个支付系统，是一个单体应用，里面简单的分了几个业务模块，连的也是一个数据库。但随着业务规模的不断扩展，单系统架构已经无法满足业务需求。\n所以支付宝就对大系统进行了拆分，将原来的一个单体应用内部的多个模块变成了多个独立的子系统，这算是典型的 SOA 化的架构。\n最开始系统之间是使用 F5 的硬件负载设备来做系统间的负载均衡，但由于 F5 设备存在单点的问题，所以后面就在中间引入一个注册中心的组件。服务提供者去注册中心注册服务，服务消费者去注册中心订阅服务列表，服务消费者通过软负载方式通过 RPC 框架直接调用服务提供者。这在现在看来是一种非常显而易见的服务化架构，但当时 07 年就采用这样的架构还是算比较超前的。\n支付宝在做系统拆分的同时，对数据库也按子系统进行了垂直拆分。数据库的拆分就会引入分布式事务的问题，蚂蚁金服中间件就提供了基于 TCC 思想的分布式事务组件 DTX。\n业务还是不断扩展，系统也越来越多，当系统节点到一定数量的时候，单个物理机房已经无法承受。另外考虑到同城容灾的问题，支付宝就在同城再扩建另外一个机房，通过专线部署为一个内部网络，然后将应用部署上去。\n同城多机房会引入一个跨机房远程访问的问题，相比同机房调用，这个延迟损耗一定是更高的。远程访问主要包括两种：RPC 调用和数据库访问。为了解决 RPC 跨机房调用的问题，支付宝的工程师选择的方案是在每个机房都部署注册中心，同机房优先调用本机房服务的方式，也就变成图中的部署模式。但是数据库跨机房访问的问题，在这个阶段并没有解决。\n另外还存在的一个问题就是调用链路混乱以及数据库连接瓶颈的调用。例如这个图里，我们对数据进行了分片，然后图中的 user0 的请求进来后，随机转到 S2，再随机转到B0，在随机到C1，最终跟进数据分配落到了数据库 D0。可以看到这里的调用链路是随机的，而每一个核心层也需要跟所有的分库都建立长连接。\n为了解决上面的跨机房数据访问、数据库连接数瓶颈以及未来数据水平扩展的问题，蚂蚁的工程师们设计了一套单元化的架构，这是单元化的一个示意图。\n在没有单元化的时候，用户请求进入内部后，所有请求链路都是随机走的，例如图里的 S0 到 B1 到 C2 到 D0。首先蚂蚁的请求都是跟用户相关的，所以我们将数据按用户的维度进行水平分片，例如这张示意图我们将所有用户分为三组。然后我们将我们的应用也部署成三组独立的逻辑单元，每个逻辑单元的应用和数据都是独立的，相当于每个逻辑单元都处理1/3总量用户的数据。\n这个时候我们的三个不同终端的用户，不管是在PC端或者手机端或者扫二维码，当请求进入统一接入层的时候，接入层会按上面逻辑单元的分组规则，将用户请求转发到对应的逻辑单元，例如 user0 的请求转到 S0，后面的应用之间的调用、数据都只在逻辑单元 0 内。统一的 user1 只在逻辑单元 1，user2 也只到逻辑单元 2。\n我们把这种逻辑单元称之为 RegionZone。在实际的部署过程中，物理数据中心 IDC 和 逻辑单元的数量没有完全的对等关系。例如图中我们物理机房可以是两地三中心，而 RegionZone 则是分为五个。\n两地三中心是国家对金融机构的一个容灾指导方案，要求在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同时在异地（＞ 200KM ) 建立异地容灾中心。\n有了这套单元化的架构做指导思想，蚂蚁进行大规模的改造，包括应用改造、基础框架改造、数据中心的建设。\n机房建设完成后，同时蚂蚁金服将自己的用户分成了若干份，划了几个逻辑单元，分别部署进了不同的物理机房，同时完成大规模的数据迁移。\n从两地三中心到容灾能力更强大的三地五中心，我们只需要先进行第三个城市的机房建设，然后将部分 RegionZone 部署到第三个城市，最后再完成数据迁移和引流即可。\n每一个 RegionZone 在异地都有备份，当发生城市级的故障时，我们通过统一的管控中心将新的逻辑规则推送到统一接入层以及异地的备 RegionZone 时，就可以做到城市级的整体容灾切换。\n再后面基于单元化思想，蚂蚁工程师还建设了弹性 LDC 的能力，例如大型活动开始的时候，我们将动态的将大促相关应用调度到其它的临时机房（例如是云上的机房）去，然后将流量引入。例如图中实例将 10% 的流量引入了 ZoneX 中。等到活动结束，我们再将流量引回。\nSOFAStack 开源情况 从前面的服务化演进可以看到，蚂蚁的微服务架构面临的场景已经慢慢从简单的远程调用发展到要面临复杂的三地五中心异地多活场景，为了支持这些场景，蚂蚁中间件自研了一套中间件 SOFAStack。\nSOFAStack 中的 SOFA 其实是 Scalable Open Financial Architecture 的首字母缩写，它是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n这是我们内部的技术栈，可以看到微服务领域各个功能点我们都有对应的内部系统或者组件。包括有RPC框架、服务发现、动态配置、熔断限流，还有分布式事务，分库分表等一整套中间件。\n目前 SOFAStack 也在蚂蚁金融科技上进行了技术输出。我们对中间件产品进行了产品化，并在蚂蚁金融云上变成了云上的产品，并提供了诸多例如同城双活之类的解决方案。这个是商业的产品，大家有空可以看下。\n在去年的 4.19 号，SOFAStack 正式宣布开源，我们第一批主要开了SOFABoot …","date":1548680400,"description":"本文根据 SOFAChannel#1 直播分享整理，主题：从蚂蚁金服微服务实践谈起。","dir":"blog/sofa-channel-1-retrospect/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c7997723a3859feb5f4f8fa454b6e00e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-1-retrospect/","publishdate":"2019-01-28T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-1-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 SOFA:Channel/ 作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。欢迎加入直播","tags":["SOFAStack","SOFAChannel"],"title":"从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-1-retrospect/","wordcount":6269},{"author":"花肉","categories":"SOFAChannel","content":" 活动主题：SOFAChannel#1——从蚂蚁金服微服务实践谈起 活动时间：1 月 17 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 \u0026amp;lt;SOFA:Channel/\u0026amp;gt;，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#1 《从蚂蚁金服微服务实践谈起》\n时间：2019-01-17 地点：浙江省杭州市西湖区线上直播 19:00-20:00 《从蚂蚁金服微服务实践谈起》 章耿 花名余淮（蚂蚁金服高级技术专家。目前在蚂蚁金服中间件服务与框架组负责应用框架及 SOFAStack 相关的工作） 嘉宾 蚂蚁金服 SOFA 团队 余淮\n视频回顾地址 https://tech.antfin.com/community/live/148\n","date":1547720400,"description":"首次 SOFAChannel 线上直播，1 月 17 日晚 7 点等你。","dir":"activities/sofa-channel-1/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5c79d2fac126784ef412f107470b2924","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-1/","publishdate":"2019-01-17T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-1/","summary":"活动主题：SOFAChannel#1——从蚂蚁金服微服务实践谈起 活动时间：1 月 17 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 \u0026","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#1——从蚂蚁金服微服务实践谈起","type":"activities","url":"/sofastack.tech/activities/sofa-channel-1/","wordcount":323},{"author":"许文奇","categories":"SOFAStack","content":" 许文奇 蚂蚁金服高级技术专家，SOFAStack 商业化产品技术 Leader，多年分布式架构及中间件研发经验，负责过蚂蚁金服分布式架构在多家金融机构的咨询和落地 本文根据他在 2019 蚂蚁金服 ATEC（Ant Technology Exploration Conference）科技大会上海站的分享整理。\n 本次分享主要会从单体架构和微服务架构的对比开始，后面重点谈一下实施金融级分布式架构的常见三个问题。\n常用架构：单体式架构 目前很多金融机构的架构是典型的单体式架构，一般由反向代理服务器，数据库和应用组成，所有业务模块都打包在一个应用里面运行，一般为了高可用考虑，应用至少会部署两个节点。单体式架构在业务简单的时候有很多它自身的优点：\n 开发，测试简单 部署简单 扩容简单，只要给应用加机器就行 但同样，单体式架构也有很多缺点，尤其是业务规模变得复杂以后，缺点会非常突出：\n 编译慢，启动慢，代码冲突等各种问题，严重影响开发效率 性能扩展有局限性，一定规模后，单纯堆机器已经很难扩展性能了。 蚂蚁金服的架构：分布式架构 微服务架构是目前大家最关注的一种分布式架构。微服务架构除了在性能可扩展性上对比单体式架构有巨大优势，还有一个重要优势体现在复杂业务下的生产效率优势。\n只有在业务复杂度较低的时候，单体式架构的生产效率才能超过微服务架构，但随着业务复杂度上升，尤其过了临界点，单体架构下的生产效率是非常恐怖的急速下坠，而微服务架构生产效率有所下降，但下降趋势非常缓慢，且不会偏离原有生产效率太多，能很好的应对业务复杂性的增长。\n所以实施微服务架构最重要的一个意义是在业务复杂度较高的情况下提升生产效率，更快速的进行业务创新。\n实施金融级分布式架构最常见的三个挑战 基于微服务架构的巨大优势，很多金融机构、企业开始逐渐转型微服务架构，转型总是伴随着挑战，这里选了三个最常见的，最多用户关心的问题，聊聊蚂蚁金服的一些实践心得：\n 如何进行微服务架构拆分及治理？ 新的分布式架构如何兼容老系统？ 如何一步一步构建金融级容灾架构？ 1、微服务架构拆分及治理 微服务拆分模式可以从微服务架构的扩展立方开始讲起，分为X轴，Y轴，Z轴三类拆分。\nX轴代表横向扩展模式。主要通过部署多份应用，负载均衡的方式来扩展性能，这个单体架构也可以做。当然，在微服务架构下，横向扩展模式的实现方式有别于单体架构。\n微服务架构做服务负载均衡不需要通过F5或者LVS集群这样的硬件设备，只需要通过注册中心就可以实现，这样带来的好处是降低了成本，不需要购买大量的硬件设备了；提高了性能，业务干路上少了一个单点风险；降低了维护成本。\n当然支持横向扩展模式还需要应用是无状态的，这个是微服务架构的基本要求，任何涉及状态的数据都应该保存在数据库，缓存或者其他一些存储介质中。更高的要求的话，应用应该要满足著名的12要素的要求。\nY轴代表功能分解模式。我们提倡业务系统在开发的时候就应该按照模块化进行开发，满足高内聚，低耦合的架构要求。为了更好支持模块化开发，以SOFAStack中间件的SOFABoot框架为例，框架支持模块隔离能力，不同的模块使用不同的Spring上下文，这样不同的模块之间就不能直接引用了，如果需要调用别的模块的接口，那么需要走SOFABoot框架规定的特别声明才可以办到。这样极大的规范了模块化开发，使得这些系统将来在进行拆分的时候，成本非常的低。\n关于功能分解，服务拆分，虽然没有一个标准答案告诉我们就该怎么做，但其实也有一些基本指导原则和实践：\n 按照业务领域进行拆解，而不是组织。所有拆分必须按照业务领域模型进行合理划分，因为实体组织不一定能和业务领域完全对应，且组织一般粒度较大，不能作为拆分细粒度微服务的参考。 从数据核心模型拆分开始先拆，而后再往上进行服务拆分。这个主要是进行拆分的一个重要次序问题。一般梳理数据核心模型比较容易，比如很容易梳理出哪些表，哪些数据属于交易，哪些表，哪些数据属于账务，然后按照业务垂直进行拆分。有些业务归属不那么明确的可以按照数据亲和性进行拆分。然后数据核心模型拆分好以后，再往上按照功能模块，所对应的场景，进行服务拆分。 单一职责。这个是微服务架构的一条金科玉律，要求微服务架构必须遵守。一个很主要的原因是为了避免微服务架构重新掉进单体架构的老问题里面。原来单体架构最大的问题就是任何的改动，都要导致整个应用重新的编译打包部署，还包括全量回归测试。试想一个微服务里面有太多的功能、职责，如果任意一个业务模块有需求，需要改动，必然导致该微服务的应用重新编译，打包部署和全量回归测试，频繁变动成本很高，研发效率也会降低。 注意拆分粒度，避免一开始拆得过细，循序渐进。关于拆分粒度，这个也是一个没有标准答案的问题。总的一个原则就是适用最好。任何一家公司的业务都是独一无二的，不存在一模一样业务的两家公司，所以别人的拆分，可以借鉴，但往往很难照抄。所以推荐拆分的时候，一开始不要拆得过细，按照业务发展的规律，循序渐进。举个例子，比如说红包业务，原来可能只是营销系统的一个模块，但如果公司的业务在红包这块发展得足够复杂，是可以考虑拆为单独的微服务，这一切取决于业务发展。 注意服务分级和分层，避免循环依赖。这个要求服务拆分的时候，充分注意到哪些是核心服务，哪些是非核心服务，不能出现核心服务强依赖非核心服务的情况，更不能出现循环依赖的情况。 考虑团队结构。最后微服务拆出来，肯定是要有对应团队去维护的，所以整个拆分的粒度，拆分的逻辑也要考虑团队结构的情况。 Z 轴代表数据分区模式。一般在数据库遇到性能瓶颈的时候，需要进行数据拆分，一般分为垂直拆分和水平拆分。垂直拆分一般就是按照业务划分来进行，比如以前账务和交易放在一个数据库，现在数据库有瓶颈了，那么就可以拆成账务和交易两个数据库，缓解数据库的性能瓶颈。当然，如果按照垂直拆分完毕以后，还是不能满足性能要求，这个时候就需要进行水平拆分了。\n关于水平拆分，也有一些重要的实践原则。在做数据库水平拆分的时候，最好一次性考虑未来十年，甚至二十年的业务的要求，要避免今天做了一个拆5张表的决定，过了两年，发现不行，还要继续拆成10张表，甚至20张表的情况。\n重新分片是个非常复杂的工作，尤其是线上还不允许停机的情况。另外关于确定如何拆多少库，多少表，也有一些实践。一般拆的数据库数量等于未来业务的峰值（TPS）除以单数据库的容量（TPS）。这里并不代表要一步到位，拆那么多实际物理库，一开始可借助SOFAStack分库分表中间件虚拟成逻辑库，只需要少量物理库，等到访问量上来后，再扩容物理库。拆的表的数量等于单表时间业务量乘以存储时长除以单标容量上限。记住表的数量一定要一步拆到位，避免过一两年还要折腾。\n做了数据拆分后，就会遇到分布式事务的问题，需要解决分布式事务的问题，这个也是金融行业区分与别的行业的最大不同。SOFAStack分布式事务中间件目前支持TCC和FMT两种模式（这里主要讨论实践，对于TCC和FMT两种模式的原理，这里不再赘述，有兴趣的可以参考之前的文章）。TCC模式虽然编码复杂，业务有侵入，难度较高，但胜在性能好，所以像核心系统里面的分布式事务都是用该方案。当然，因为复杂，所以实现中有些地 …","date":1547535600,"description":"本次分享主要会从单体架构和微服务架构的对比开始，后面重点谈一下实施金融级分布式架构的常见三个问题。","dir":"blog/distributed-arch-in-the-enterprise/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e2f9f404c5e859e21c65fb3c2f2f0324","permalink":"https://sofastack.github.io/sofastack.tech/blog/distributed-arch-in-the-enterprise/","publishdate":"2019-01-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/distributed-arch-in-the-enterprise/","summary":"许文奇 蚂蚁金服高级技术专家，SOFAStack 商业化产品技术 Leader，多年分布式架构及中间件研发经验，负责过蚂蚁金服分布式架构在多家金融","tags":["SOFAStack"],"title":"企业实施分布式架构的挑战以及应对建议 | 上海 ATEC 科技大会实录","type":"blog","url":"/sofastack.tech/blog/distributed-arch-in-the-enterprise/","wordcount":5455},{"author":"崔秀龙","categories":"Service Mesh","content":" 崔秀龙，HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员。\n本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整理，完整的分享 PPT 获取方式见文章底部。\n本文内容收录在崔秀龙的新书：《深入浅出 Istio - Service Mesh 快速入门与实践》的第十章，该书将于近期由博文视点出版发行，敬请关注。\n Service Mesh 概念在 Linkerd 落地之后，让一直漂浮在空中的微服务治理方案有了一个明确的落地点，给微服务架构的具体实现指出了一个清晰的方向，围绕这一概念逐步开始形成新的技术生态，在业界造成不少震动。这种震动对于企业 IT 转型工作带来的影响，甚至比容器化的影响更加深远。对于承担企业 IT 转型工作的企业服务行业来说，也自然首当其冲感觉到新概念带来的压力。\n企业服务行业和互联网行业相比，业务形态、技术积累和人员结构等方面都大相径庭，举几个常见的差异：\n 开发、运维、基础设施所属 人员结构、水平和年龄 资源使用率差别 架构和平台一致性 负载能力 \u0026amp;hellip; 目前进行 Service Mesh 布道的主力还是互联网行业的旗手们，一味追求跟进互联网同行们的进度和做法，颇有邯郸学步的风险。\n本文中将会针对目前 Service Mesh 方面的一些普遍问题和关注热点发表一些个人意见。并尝试提供一种 Istio 的试用思路，给乙方同行们提供参考。\nIstio 的功能 无需赘述，多数用户都很清楚，Istio 使用和应用共享网络栈的方式，利用 Iptables 劫持应用的网络流量，从而在不修改业务源码的情况下，完成一系列的功能：\n 监控服务质量 控制服务间的访问路由 应对服务故障 在服务间通信之间进行加密 访问控制和频率限制 分布式跟踪和业务紧密相关，无法做到无侵入。\n 这其中最大的优势就是无侵入，这意味着给试用流程留下了全身而退的机会，如果没有回滚的能力，上述种种能力都是空中楼阁。\nIstio 的问题 API 稳定性可能是最严重的一个问题。目前最成熟的功能组别应该是流量控制，其版本号也仅是 v1alpha3，一般来说，alpha 阶段的产品，代表着不提供向后兼容的承诺，流量控制 API 在从 v1alpha2 升级为 v1alpha3 的过程中，API 几乎全部改写，使得很多早期用户的精力投入付诸东流。核心功能尚且如此，遑论相对比较边缘的 Mixer、Citadel 以及 Galley 组件的相关内容。 发布节奏和发布质量的问题也相当严重。Istio并不算长的历史中，出现了多次版本撤回、大版本严重延期、发布质量低下无法使用以及 Bug 反复等状况，这无疑会让每次升级尝试都充满了不确定性，会很大的影响生产过程的连续性。 Mixer 是一个问题焦点，其数据模型较为复杂，并且集中了所有应用的流量于一点，虽然其中加入了各种缓存等技术来降低延迟，但是其独特地位决定了 Mixer 始终处于一个高风险的位置。同时其 API 结构稍显混乱，重构风险较大。 Pilot的性能方面也经常为人诟病，虽然经过几次升级，但是即使是 1.0 之后，还是出现了两次 Pilot 在集群中服务/Pod 过多的情况下会超量消耗资源的问题。 安全、物理机和虚拟机的支持以及网格边缘通信这三组功能，目前用户较少，质量尚不明确。 最后就是 Istio 的 Sidecar 注入模式，这种模式一定会增加服务间调用的网络延迟，在目前阶段这是一个痼疾，Sidecar 的固定延迟和 Mixer 的不确定行为相结合，有可能会产生严重后果。 这里提出的只是被反复提及，或者经常出现在 Issue 列表中的问题，由发布问题来看，面临的风险可能远不止这些。\nIstio 试用工作的理由和规划 试用 Istio，首先应该确定，该技术的采用，是否能够在可控的风险和投入下，得到有效的产出。\n 微服务模式的推进，必须要有相应的管理能力，Service Mesh 目前看来，是一个确定有效的方案，如果不是 Istio，也会有其它替代产品出现。 目前看来，Istio 是 Service Mesh 的标志性产品，有一定可能性成为事实标准。 提供了众多开箱即用的丰富特性，能够迅速进入 Service mesh。 最后是无侵入的优势：如果试用失败，可以退回，控制损失范围。 Istio 的多数功能，在无需对程序进行修改（分布式跟踪除外）的情况下，能对应用提供如此之多的功能支持，无疑是非常有吸引力的。Istio 的功能集，完全可以说是服务网格技术的典范。一旦确认现有环境有可能支持 Istio 的运行，并且在合理的投入下能够获得有效益的产出，那么这个试用就是有价值的。\n结合 Istio 的现状，以及多数企业的运行状态，个人浅见，Istio 的应用在现阶段只能小范围试探性地进行，在进行过程中要严格定义试用范围，严控各个流程。 按照个人经验，笔者将试用过程分为如下 4 个阶段。\n 范围定义：选择进入试用的服务，确定受影响的范围，并根据 Istio 项目现 状决定预备使用的 Istio 相关功能。围绕这些需要，制定试用需求。 方案部署：根据范围定义的决策，制定和执行相关的部署工作。其中包含 Istio 自身的部署和业务服务、后备服务的部署工作。 测试验证：根据既有业务目标对部署结果进行测试。 切换演练：防御措施，用于在业务失败时切回到原有的稳定环境。 Istio 的试用步骤 确定功能范围 在 Istio 中包含了非常多的功能点，从原则上来说，各种功能都是有其实际作用的。然而，Istio 作为一个新产品，本身也有很多不足，我们在 10.1 节中也提到了这些不足。\nIstio 提供的众多功能对每个公司或者项目，都会有不同价值。我们在采用一个新系统时，首先要考虑的就是性价比问题，这里的“价”代表着 Istio 带来的风险、对业务应用的影响，还包括可能出现的服务停机等问题。\n可以根据性价比，做出一个优先级别列表。在制定了优先级列表之后，就可以根据这一列表，结合项目的实际需求，按照效果明显、功能稳定、部署成本低、少改造或者不改造的标准来进行选择，最终确定待测试的功能点。\n在选定功能点之后，应该遵循目前已有的 Istio 文档，对各个功能点进行单项测试和验证，以确保其有效性。并通过官方 GitHub 的 Issue 列表及讨论组内容，了解现有功能是否存在待解决的问题，以及相关的注意事项等。\n选择试用业务 在试用功能点确定之后，就要选择用于试用的业务应用了。Istio 作为一个相对底层的系统，其部署和调试过程必然会对业务产生一定的影响，在运行阶段又有 Sidecar 和各个组件造成的损耗，如下所述：\n 所有网格之间的通信都要经过 Sidecar 的中转，会造成大约 10 毫秒的延迟。 Pilot 对集群规模敏感，集群中的服务数量、Pod 数量都可能对 Pilot 造成较大影响，也会影响到 Istio 各种规则向 Pod 的传输过程。 所有流量都会经由 Mixer 处理，也有造成瓶颈的可能。 安全功能设置不当同样会造成服务中断。 如上所述还只是个概要，对业务来说，对这些风险都是必须正 …","date":1547103600,"description":"本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-meetup-5-istio-retrospect/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"88553acdb286a68c44cc9bf390855f26","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","publishdate":"2019-01-10T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","summary":"崔秀龙，HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员。 本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整","tags":["Service Mesh"],"title":"企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","wordcount":4050},{"author":"敖小剑","categories":"Serverless","content":" Knative 是Google 发起的 Serverless 项目，希望通过提供一套简单易用的 Serverless 开源方案，将 Serverless 标准化。 本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，PPT 获取地址：下载地址\n 前言 大家好，今天给大家来的演讲专题是“Knative：重新定义Serverless”, 我是来自蚂蚁金服中间件的敖小剑。\n这是我的个人资料，有兴趣的同学可以关注的我的个人技术博客网站 https://skyao.io\n这次演讲的内容将会有这些，首先给大家介绍一下 Knative 是什么，然后是 Knative 的主要组件，让大家对 Knative 有一个基本的了解。之后我会简单的对 Knative 做一些分析和探讨，以及介绍一下 Knative 后续的发展。希望本次的内容让大家能够对Knative有一个基本的认知。\n什么是 Knative？ Knative 是 Google 牵头发起的 Serverless 项目。\n这是Knative的项目定义，注意这句话里面几个关键字：Kubernetes，Serverless，Workload。\n这是最近几年 Google 做大型项目的常态：产品刚出来，阵营就已经很强大了，所谓先声夺人。\n是目前Knative项目的进展，可以看到这是一个非常新的项目，刚刚起步。\n 备注：这是截至2018-11-24演讲当天的情况，到2018年12月底，Knative已经发布了v0.2.2和v0.2.3两个bugfix版本。但也还只是 0.2 ……\n 我们来看一下，在Knative出来前， Serverless 领域已有的实现，包括云端提供的产品和各种开源项目。\n这幅图片摘自 The New Stack 的一个 Serverless 调查，我们忽略调查内容，仅仅看看这里列出来的 Serverless 产品的数量——感受是什么？好多Serverless项目，好多选择！\n那问题来了：到底该怎么选？\n这就是目前 Serverless 的问题：由于缺乏标准，市场呈现碎片化。不同厂商，不同项目，各不相同，因此无论怎么选择，都面临一个风险：供应商绑定！\n这段话来自 Knative 的官方介绍，Google 推出 Knative 的理由和动机。其中第一条和第二条针对的是当前 Serverless 市场碎片的现状。而第四条多云战略，则是针对供应商绑定的风险。\nGoogle 描述 Knative 的动机之一，是将云原生中三个领域的最佳实践结合起来。\n小结：\n当前 Serverless 市场产品众多导致碎片化严重，存在厂商绑定风险，而 Google 推出 Knative，希望能提供一套简单易用的 Serverless 方案，实现 Serverless 的标准化和规范化。\nKnative 的主要组件 第二部分，来介绍一下Knative的主要组件。\n前面提到，Google 推出 Knative ，试图将云原生中三个领域的最佳实践结合起来。反应到 Knative 产品中，就是这三大主要组件：Build，Serving，Eventing。\nKnative Build 组件，实现从代码到容器的目标。为什么不直接使用 dockfile 来完成这个事情？\nKnative Build 在实现时，是表现为 Kubernetes 的 CRD，通过 yaml 文件来定义构建过程。这里引入了很多概念如：Build，Builder，Step，Template，Source等。另外支持用 Service Account 做身份验证。\nKnative Serving 组件的职责是运行应用以对外提供服务，即提供服务、函数的运行时支撑。\n注意定义中的三个关键：\n Kubernetes-based：基于 k8s，也仅支持 k8s，好处是可以充分利用k8s平台的能力 scale-to-zero：serverless 最重要的卖点之一，当然要强调 request-driven compute：请求驱动的计算 值得注意的是，除了k8s之外，还有另外一个重要基础：istio！后面会详细聊这个。\nKnative Serving项目同样也提供了自己的中间件原语，以支持如图所示的几个重要特性。\nKnative中有大量的概念抽象，而在这之后的背景，说起来有些意思：Knative 觉得 kubernetes 和 istio 本身的概念非常多，多到难于理解和管理，因此 Knative 决定要自己提供更高一层的抽象。至于这个做法，会是釜底抽薪解决问题，还是雪上加霜让问题更麻烦……\nKnative的这些抽象都是基于 kubernetes 的 CRD 来实现，具体抽象概念有：Service、Route、Configuration 和 Revision。特别提醒的是，右边图中的 Service 是 Knative 中的 Service 概念，service.serving.knative.dev，而不是大家通常最熟悉的 k8s 的 service。\n对于 Knative Serving 组件，最重要的特性就是自动伸缩的能力。目前伸缩边界支持从0到无限，容许通过配置设置。\nKnative 目前是自己实现的 Autoscaler ，原来比较简单：Revision 对应的pod由 k8s deployment 管理，pod上的工作负载上报 metrics，汇总到 Autoscaler 分析判断做决策，在需要时修改 replicas 数量来实现自动伸缩（后面会再讲这块存在的问题）。\n当收缩到0，或者从0扩展到1时，情况会特别一些。Knative在这里提供了名为 Activator 的设计，如图所示：\n Istio Route 控制流量走向，正常情况下规则设置为将流量切到工作负载所在的pod 当没有流量，需要收缩到0时，规则修改为将流量切到 Activator ，如果一直没有流量，则什么都不发生。此时Autoscaler 通过 deployment 将 replicas 设置为0。 当新的流量到来时，流量被 Activator 接收，Activator 随即拉起 pod，在 pod 和工作负载准备好之后，再将流量转发过去 Knative Eventing 组件负责事件绑定和发送，同样提供多个抽象概念：Flow，Source，Bus，以帮助开发人员摆脱概念太多的负担（关于这一点，我保留意见）。\nBus 是对消息总线的抽象。\nSource 是事件数据源的抽象。\nKnative 在事件定义方面遵循了 Cloudevents 规范。\n小结：\n简单介绍了一下 Knative 中的三大组件，让大家对 Knative 的大体架构和功能有个基本的认知。这次就不再继续深入 Knative 的实现细节，以后有机会再展开。\nKnative分析和探讨 在第三部分，我们来分析探讨一下 Knative 的产品定位，顺便也聊一下为什么我们会看好 Knative。\n首先，最重要的一点是：Knative 不是一个 Serverless 实现，而是一个 Serviceless 平台。\n也就是说，Knative 不是在现有市场上的20 …","date":1546498800,"description":"本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，文中有 PPT 获取地址。","dir":"blog/serverless-knative-giac/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"21d3b124a0863acf6481463647b92095","permalink":"https://sofastack.github.io/sofastack.tech/blog/serverless-knative-giac/","publishdate":"2019-01-03T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/serverless-knative-giac/","summary":"Knative 是Google 发起的 Serverless 项目，希望通过提供一套简单易用的 Serverless 开源方案，将 Serverless 标准化。 本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，PPT 获取地址：下载","tags":["Serverless","Knative"],"title":"Knative：重新定义 Serverless | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/serverless-knative-giac/","wordcount":3746},{"author":"余淮","categories":"SOFAStack","content":" 章耿，花名余淮，蚂蚁金服高级技术专家。 2007 年毕业后一直从事服务化相关的工作，最早在国家电网做电子商务平台 SOA 化的工作，之后在京东负责京东的服务化框架 JSF，目前在蚂蚁金服中间件服务与框架组负责应用框架及 SOFAStack 相关的工作。\n本文根据余淮在 2018 开源中国年终盛典的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 本次分享主要分为三部分： 蚂蚁金服服务化架构演进 蚂蚁金服微服务体系 蚂蚁金服 SOFAStack 的开源情况 1、蚂蚁金服服务化架构演进 在开始讲架构演进之前，我们先来看一组数据。 这是历年来的双十一数据图，柱状是双十一的交易额，从最初到20亿到去年的1682亿，今年是2135亿。而这个橙色的折线则是支付宝双十一 0 点的交易峰值，去年是 26.5w笔每秒，今年更高。从这两组数据可以看出蚂蚁的业务每年都是在高速增长，那技术面临的压力更是在不断的增长。但是最近几年，峰值虽然越来越大，但是大家有个体感，就是大促的购物体验更好了，再也不像以前系统会被大促搞挂，系统反而越来越稳了。\n而支撑这些数字的背后，是蚂蚁金融科技的一些核心技术，我们可以看到有三地五中心多活架构，分布式数据库 OceanBase，金融级分布式架构 SOFAStack，还有更多的一些黑科技，例如 Zoloz 生物识别，蚂蚁区块链，第五代智能风控引擎。\n相信大家都听过一句话 “罗马不是一天建成的”。蚂蚁金服科技的技术也不是最早就设计成这样，和所有的大公司发展一样，目前这些技术架构也是随着业务发展、系统的壮大，一步一步演进而来的。\n下面给大家介绍下蚂蚁金服的演进。\n这个是支付宝最早的架构示意图，可以看到当时支付宝只是电商后台的一个支付系统，是一个单体应用，里面简单的分了几个业务模块，连的也是一个数据库。但随着业务规模的不断扩展，单系统架构已经无法满足业务需求。\n所以支付宝就对大系统进行了拆分，将原来的一个单体应用内部的多个模块变成了多个独立的子系统，这算是典型的 SOA 化的架构。最开始系统之间是使用 F5 的硬件负载设备来做系统间的负载均衡，但由于 F5 设备存在单点的问题，所以后面就在中间引入一个注册中心的组件。服务提供者去注册中心注册服务，服务消费者去注册中心订阅服务列表，服务消费者通过软负载方式通过 RPC 框架直接调用服务提供者。这在现在看来是一种非常显而易见的服务化架构，但当时 07 年就采用这样的架构还是算比较超前的。 支付宝在做系统拆分的同时，对数据库也按子系统进行了垂直拆分。数据库的拆分就会引入分布式事务的问题，蚂蚁金服中间件就提供了基于 TCC 思想的 分布式事务组件 DTX。\n业务还是不断扩展，系统也越来越多，当系统节点到一定数量的时候，单个物理机房已经无法承受。另外考虑到同城容灾的问题，支付宝就在同城再扩建另外一个机房，通过专线部署为一个内部网络，然后将应用部署上去。同城多机房会引入一个跨机房远程访问的问题，相比同机房调用，这个延迟损耗一定是更高的。远程访问主要包括两种：RPC 调用和数据库访问。为了解决 RPC 跨机房调用的问题，支付宝的工程师选择的方案是在每个机房都部署注册中心，同机房优先调用本机房服务的方式，也就变成图中的部署模式。但是数据库跨机房访问的问题，在这个阶段并没有解决。\n为了解决上面的跨机房数据访问、数据库连接数瓶颈以及未来数据水平扩展的问题，蚂蚁的工程师们设计了一套单元化的架构，这是单元化的一个示意图。在没有单元化的时候，用户请求进入内部后，所有请求链路都是随机走的，例如图里的 S0 到 B1 到 C2 到 D0。首先蚂蚁的请求都是跟用户相关的，所以我们将数据按用户的维度进行水平分片，例如这张示意图我们将所有用户分为三组。然后我们将我们的应用也部署成三组独立的逻辑单元，每个逻辑单元的应用和数据都是独立的，相当于每个逻辑单元都处理1/3总量用户的数据。\n这个时候我们的三个不同终端的用户，不管是在PC端或者手机端或者扫二维码，当请求进入统一接入层的时候，接入层会按上面逻辑单元的分组规则，将用户请求转发到对应的逻辑单元，例如 user0 的请求转到 S0，后面的应用之间的调用、数据都只在逻辑单元 0 内。统一的 user1 只在逻辑单元 1，user2 也只到逻辑单元 2。\n我们把这种逻辑单元称之为 RegionZone。在实际的部署过程中，物理数据中心 IDC 和 逻辑单元的数量没有完全的对等关系。例如图中我们物理机房可以是两地三中心，而 RegionZone 则是分为五个。\n两地三中心是国家对金融机构的一个容灾指导方案，要求在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同时在异地（＞ 200KM ) 建立异地容灾中心。\n有了这套单元化的架构做指导思想，蚂蚁进行大规模的改造，包括应用改造、基础框架改造、数据中心的建设。\n机房建设完成后，同时蚂蚁金服将自己的用户分成了若干份，划了几个逻辑单元，分别部署进了不同的物理机房，同时完成大规模的数据迁移。\n从两地三中心到容灾能力更强大的三地五中心，我们只需要先进行第三个城市的机房建设，然后将部分 RegionZone 部署到第三个城市，最后再完成数据迁移和引流即可。\n每一个 RegionZone 在异地都有备份，当发生城市级的故障时，我们通过统一的管控中心将新的逻辑规则推送到统一接入层以及异地的备 RegionZone 时，就可以做到城市级的整体容灾切换。\n再后面我们基于单元化的思想做了更多弹性调度等能力，这里就不展开了。\n2015 年 9 月蚂蚁金融云对外正式发布，在今年 9 月的云栖大会，蚂蚁金融云正式升级为蚂蚁金融科技，并宣布技术全面对外开放，其中就包括金融级分布式架构 SOFAStack，左上角就是网址，感兴趣的朋友可以看下：https://tech.antfin.com/sofa\n云上的 SOFAStack 继承了蚂蚁金服内部的能力，有三大特点，分别是开放（全栈开放、开源共建）、云原生（异地多活、无限扩展）、金融级（资金安全、无损容灾），下面是一些核心能力大家可以看下。这一切就使得蚂蚁金服的微服务体系不仅仅在蚂蚁内部玩得转，也需要适应云上例如云原生、多租户等更复杂的场景。\n2、蚂蚁微服务体系 讲到微服务，大家就会看到或者脑子就跳出各种各样的词，例如 RPC 框架、服务安全、路由寻址等等。 除了这些以外，其实还有更多的服务归属、服务测试、服务编排等更多概念。\n那蚂蚁内部围绕微服务体系，也建设了很多的组件和框架对应这些微服务的概念点。\n这是一张蚂蚁内部微服务体系的一张简图，只列了部分主要组件，这些组件都是自研的，部分已经开源。可以看到有配置中心 DRM、注册中心 SOFARegistry，应用开发框架 SOFABoot，应用里的 RPC 框架、分布式链路跟踪组件 Tracer、监控度量组件 Lookout 等微服务组件，应用旁边是我们的 SOFAMosn，也就是 ServiceMesh 里的数据平面 SideCar，会将 RPC 里的路由、限流、鉴权等一些能力集成到这个组件里， …","date":1545030000,"description":"本文根据余淮在 2018 开源中国年终盛典的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/sofastack-oschina-2018/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e636d50f3f49170801c38118bf711adc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-oschina-2018/","publishdate":"2018-12-17T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofastack-oschina-2018/","summary":"章耿，花名余淮，蚂蚁金服高级技术专家。 2007 年毕业后一直从事服务化相关的工作，最早在国家电网做电子商务平台 SOA 化的工作，之后在京东负责京东的服务化","tags":["微服务","开源","实践"],"title":"蚂蚁金服微服务实践- 2018 开源中国年终盛典分享实录","type":"blog","url":"/sofastack.tech/blog/sofastack-oschina-2018/","wordcount":6551},{"author":"颜洄、丞一","categories":"SOFABolt","content":" 1. 前言 为了让中间件开发者们将更多的精力投入到产品的功能特性上，而不是重复的写通信层框架，蚂蚁中间件团队设计并实现了SOFABolt。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。蚂蚁中间件的同学这些年在微服务和消息中间件上解决了很多网络通信的问题，积累了很多经验，并将这些经验、解决方案沉淀到了SOFABolt这个项目中，希望能让更多需要使用网络通信的团队、开发者受益。目前SOFABolt已经运行在蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n2. 主要特性 SOFABolt核心功能包括三大块：\n 网络通信能力 协议框架 私有协议实现 网络通信能力 网络通信能力（remoting-core）可以理解为Netty的最佳实践，并额外进行了一些优化工作，包含：\n 基于Netty的高效的网络IO于线程模型的应用 链接管理（无锁建连、定时断连、自动重连） 通信模型（oneway、sync、callback、future） 超时控制 批量解包和批量提交处理 心跳于IDLE机制 协议框架 协议框架（protocol-skeleton）包含命令处理器、编解码器等，是底层通信能力之上，具体私有协议之下，连接通信能力和私有协议的中间层。网络通信层是SOFABolt对Netty的封装和功能增强，协议框架则是SOFABolt对网络请求处理流程的抽象，是用户可以不关心底层细节快速实现自己的处理器来完成网络请求的处理逻辑，是用户可以进行拓展来实现自定义的私有协议的基础，也是本篇文章分析的内容。\n私有协议实现 由于性能、安全性等等的原因，很多中间件都会采用私有协议进行通信。SOFABolt除了提供基础的通信能力、协议框架之外，还提供了默认的RPC协议的实现，这样它就是一个完整的通信框架，用户可以不关心协议而直接上手使用。本篇文章主要分析SOFABolt的协议框架的设计和实现，不展开对SOFABolt中的RPC协议实现做介绍。\n3. 协议框架 协议框架整体如下：\n Command：协议命令，通讯数据的顶层抽象。从交互的角度可以分为Request（请求）于Response（响应），从功能的角度，分为负载命令（交换业务数据）和控制命令（进行系统的管理、协调等）。 CommandEncoder/CommandDecoder：协议命令的编解码器，自定义协议实现的基础，编解码器完成对象和字节数组之间的相互转换。 CommandHandler：协议命令的处理器，命令处理入口，负责分发、处理命令。 CommandFactory：协议命令工厂类，负责创建协议命令对象。 HeartbeatTrigger：心跳的处理器，用户用户拓展特定的心跳机制的处理。 下面以SOFABolt中默认实现的RPC协议为例来介绍SOFABolt协议框架的实现。 3.1 请求的处理流程 一个请求处理流程大致如下：\n 通过CommandFactory构建请求对象 通过CommandEncoder对请求对象进行编码，写入到网络连接 服务端从连接中读取数据，通过CommandDecoder解析成请求对象 CommandHandler接收请求对象，进行分发和处理 CommandFactory是一个工厂类，比较简单，不展开介绍。编解码相关内容见《SOFABolt编解码机制》。下面介绍一下CommandHandler对请求的分发和处理。\n上面是SOFABolt中RpcHandler的代码片段，这段代码是命令处理的入口：\n 首先从连接的上下文中获取使用的协议的版本ProtocolCode 再根据ProtocolCode从ProtocolManager中获取具体的协议 之后从协议中获取CommandHandler，并构造请求的上下文信息和请求的对象（代码片段中的msg）提交处理 上面的处理逻辑中透露出一个信息：SOFABolt支持同时运行多个版本的协议，通过ProtocolCode来区分协议。这一点可以使得系统在做升级或重构时，需要同时支持新老系统不同协议时变得简单。\n上面是CommandHandler的代码片段，透露出的信息是SOFABolt支持批量提交请求，这在《SOFABolt编解码机制》一文中也有部分介绍。而具体的process流程如下：\n通过Command对象获取CommandCode，根据CommandCode获取对应的RemotingProcessor进行处理。 CommandCode是一个接口，只有一个返回short的value()方法，表示Command的具体类型，每个请求都需要有自己的CommandCode来标识自己的类型。框架通过一个Map来维护CommandCode和RemotingProcessor的关系，每个CommandCode需要有对应的RemotingProcessor进行处理，一个RemotingProcessor可以处理多个CommandCode的请求。\n再往下看一层，请求会被提交到RemotingProcessor中处理。上面是RpcRequestProcessor处理请求的代码片段，处理流程中会通过cmd.getRequestClass()来获取请求的对象的Class名称，再获取对应的UserProcess进行处理（具体处理不再上面的代码片段中）。 对用户来说，只需要实现自己的Command对象、实现自己的UserProcessor并注册到ProcessorManager中，就可以完成自己的网络通信。 以上是一个请求在SOFABolt的协议框架下的处理流程和核心代码的分析。\n3.2 协议框架的拓展机制 通过对请求处理流程的分析可以感受到SOFABolt的协议框架是支持多协议版本运行，能直接使用，也支持进行拓展来实现更丰富和定制化的功能。下面具体介绍SOFABolt的拓展机制。\n上图是RemotingCommand在处理过程中的路由示意图。第一层路由根据ProtocolCode进行，第二层路由根据CmdCode进行，第三层路由则根据RequestClass进行。用户可以在每一层进行扩展来实现自己的处理。 这种设计具有很好的拓展性和灵活性，ProtocolCode用于区分“大版本”的协议，适用于协议发生较大的变化的场景。CmdCode则标识请求类型，比如在RPC场景中CmdCode可能就两个：RPC_REQUEST、RPC_RESPONSE，而在消息场景中CmdCode可能会更丰富一些，比如有发送消息、批量发送消息、投递消息等等。RequestClass是Command上承载的数据的类型，用户根据不同的类名进行不同的业务逻辑的实行。\n实际应用中，以RPC的场景为例，用户更多的是去实现UserProcessor来完成不同的业务逻辑的处理。而在消息的场景中，因为消息承载的是二进制的数据，所以请求的数据类型是固定的，系统更多的是拓展CmdCode来执行不同类型的请求的处理，比如心跳请求的处理、写入消息的处理、批量写入消息的处理等等。SOFABolt协议框架的设计和实现，具备较好的可拓展性，使其能应用于蚂蚁 …","date":1544091600,"description":"本文是对蚂蚁金服开源通信框架 SOFABolt 的协议框架解析。","dir":"blog/sofa-bolt-framework-deep-dive/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"67335ca275995497a5f28340cb13f45b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","summary":"1. 前言 为了让中间件开发者们将更多的精力投入到产品的功能特性上，而不是重复的写通信层框架，蚂蚁中间件团队设计并实现了SOFABolt。 Bolt 名字取","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架 SOFABolt 协议框架解析","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","wordcount":3889},{"author":"鲁道","categories":"SOFABolt","content":" 前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将重点分析 SOFABolt 的序列化机制。\n我们知道，但凡在网络中传输数据，都涉及到序列化以及反序列化。即将数据编码成字节，再把字节解码成数据的过程。\n例如在 RPC 框架中，一个重要的性能优化点是序列化机制的设计。即如何为服务消费者和和服务提供者提供灵活的，高性能的序列化器。\n这里说的序列化器，不仅仅是指“对象”的序列化器，例如 Hessian，Protostuff，JDK 原生这种“对象”级别的序列化器，而是指“协议”级别的序列化器，“对象”的序列化只是其中一部分。通常“协议”级别的序列化器包含更多的信息。\n下面我们将先从 SOFABolt 的设计及实现入手，进而分析 SOFABolt 详细的序列化与分序列化流程，最后介绍 SOFABolt 序列化扩展。\n设计及实现 一个优秀的网络通信框架，必然要有一个灵活的，高性能的序列化机制。那么，SOFABolt 序列化机制的设计目标是什么呢？具体又是如何设计的呢？\n首先说灵活，灵活指的是，框架的使用方（这里指的是网络通信框架的使用方，例如 RPC，消息中心等中间件）能够自定义自己的实现，即用户决定使用什么类型的序列化以及怎么序列化。\n再说高效，序列化和反序列化事实上是一个重量级的操作，阿里 HSF 作者毕玄在著名的 NFS-RPC框架优化过程（从37k到168k） 文章中提到，其优化 RPC 传输性能的第一步就是调整反序列化操作，从而将 TPS 从 37k 提升到 56k。之后又通过更换对象序列化器，又将 TPS 提升了将近 10k。由此可见，合理地设计序列化机制对性能的影响十分巨大。\n而 SOFABolt 和 HSF 有着亲密的血缘关系，不但有着 HSF 的高性能，甚至在某些地方，优化的更为彻底。\n我们现在可以看看 SOFABolt 序列化设计。\n接口设计 SOFABolt 设计了两个接口：\n Serializer 该接口定义 serialize 方法和 deserialize 方法，用于对象的序列化和反序列化。 CustomSerializer 该接口定义了很多方法，主要针对自定义协议中的 header 和 content 进行序列化和反序列化。同时提供上下文，以精细的控制时机。 同时，从框架设计的角度说，他们可以称之为 “核心域”， 他们也被对应的 “服务域” 进行管理。\n这里解释一下服务域和核心域，在框架设计里，通常会有“核心域”，“服务域”， “会话域” 这三部分组成。\n例如在 Spring 中，Bean 就是核心域，是核心领域模型，所有其他模型都向其靠拢；而 BeanFactory 是服务域，即服务“核心域”的模型，通常长期存在于系统中，且是单例；“会话域” 指的是一次会话产生的对象，会话结束则对象销毁，例如 Request，Response。\n在 SOFABolt 序列化机制中，Serializer 和 CustomSerializer 可以认为是核心域，同时，也有服务于他们的 “服务域”，即 SerializerManager 和 CustomSerializerManager。“会话域” RpcCommand 依赖 “服务域” 获取 “核心域” 实例。\nUML 设计图如下：\n其中红色部分就是 SOFABolt 序列化机制的核心接口，同时也是用户的扩展接口，他们被各自的 Manager 服务域进行管理，最后，会话域 RpcCommand 依赖着 Manager 以获取序列化组件。\n这两个接口的使用场景通常在数据被 协议编解码器 编码之前或解码之后，进行处理。\n例如在发送数据之前，协议编码器 根据通信协议（如 bolt 协议）进行编码，编码之前，用户需要将数据的具体内容进行序列化，协议编解码器 再进行更详细的编码。\n同样，协议解码器 在接收到 Socket 发送来的字节后，根据协议将字节解码成对象，但是，对象的内容还是字节，需要用户进行反序列化。\n一个比较简单的流程图就是这样的:\n上图中，假设场景是 Client 发送数据给 Server，那么，编解码器负责将字节流解码成 Command 对象，序列化器负责将 Command 对象里的内容反序列化成业务对象，从设计模式的角度看，这里是 GOF 中 “命令模式”和“职责链模式”的组合设计。\n看完了设计，再看看实现。\n接口实现 我们可以看看这两个接口的实现。\n Serializer Serializer 接口在 SOFABolt 中已有默认实现，即 HessianSerializer，目前使用的是 hessian-3.3.0 版本。通过一个 SerializerManager 管理器进行管理。注意，这个管理器内部使用的是数组，而不是 Map，这在上文毕玄的文章也曾提到：通过使用数组替换成 Map，NFS-RPC 框架的 TPS 从 153k 提升到 160k。事实上，任何对性能非常敏感的框架，能用数组就绝不用 Map，例如 Netty 的 FastThreadLocal，也是如此。\n当然，Serializer 接口用户也是可以扩展的，例如使用 protostuff，FastJson，kryo 等，扩展后，通过 SerializerManager 可以将自己的序列化器添加到 SOFABolt 中。注意：这里的序列化 type 实际就是上面提到的数组的下标，所以不能和其他序列化器的下标有冲突。\n CustomSerializer 再说 CustomSerializer，这个接口也是有默认实现的，用户也可以选择自己实现，我们这里以 SOFARPC 为例。\nSOFARPC 在其扩展模块 sofa-rpc-remoting-bolt 中，通过实现 CustomSerializer 接口，自己实现了序列化 header，content。\n这里稍微扩展讲一下 header 和 content。实际上，header 和 content 类似 http 协议的消息头和消息体，header 和 content 中到底存放什么内容，取决于协议设计者。\n例如在 SOFARPC 的协议中，header 里存放的是一些扩展属性和元信息上下文。而 content 中存放的则是主要的一些信息，比如 request 对象，request 对象里就存放了 RPC 调用中常用信息了，例如参数，类型，方法名称。\n同时，CustomSerializer 接口定义的方法中，提供了 InvokeContext 上下文，例如是否泛化调用等信息，当进行序列化时，将是否泛型的信息放入上下文，反序列化时，再从上下文中取出该属性，即可正确处理泛化调用。\n注意，如果用户已经自己实现了 CustomSerializer 接口，那么 SOFABolt 的 SerializerManager 中设置的序列化器将不起作用！因为 SOFABolt 优先使用用户的序列化器。\n具体代码如下：\n行文至此，讨论的都是“灵活”这个设计，即用户既可以使用 SOFABolt …","date":1544091600,"description":"SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架，本文将重点分析 SOFABolt 的序列化机制。","dir":"blog/sofa-bolt-serialization-deep-dive/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2145bb681760cdf3d1953bf4ed75fa60","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","summary":"前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之序列化机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","wordcount":4630},{"author":"水寒","categories":"SOFABolt","content":" 基础介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生。 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，积累了很多经验，并持续的进行着优化和完善，我们希望能把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。 目前该产品已经运用在了蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n前言 SOFABolt 提供了设计良好、使用便捷的编解码功能。本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。欢迎大家与我们讨论交流。\n编解码介绍 每个网络应用程序都必须定义如何解析在两个节点之间来回传输的原始字节，以及如何将其和目标应用程序的数据格式做相互转换。在一个成熟的通信框架中，我们通常都会通过私有通信协议来描述这种定义，通过编解码技术将理论上的私有通信协议转化为实践。\n通过编解码技术，我们可以方便的做一些逻辑，例如双方可以方便的统一序列化与反序列化方式、解决 TCP 拆包粘包问题等。\n下面，我们先来看一下 TCP 粘包拆包问题的产生，然后分析 Netty 是如何解决粘包拆包问题的，最后分析 SOFABolt 是如何解决粘包拆包问题的。\nTCP 粘包拆包问题 如上图所示，三种拆包原因见黄色标签说明；两种粘包原因见蓝色标签说明。TCP 本身是面向流的，它无法从源源不断涌来的数据流中拆分出或者合并出有意义的信息，通常可以通过以下几种方式来解决：\n 基于分隔符协议：使用定义的字符来标记一个消息的结尾，在编码的时候我们在消息尾部添加指定的分隔符，在解码的时候根据分隔符来拆分或者合并消息。Netty 提供了两种基于分隔符协议的解码器 LineBasedFrameDecoder 和 DelimiterBasedFrameDecoder。LineBasedFrameDecoder 指定以 \\n 或者 \\r\\n 作为消息的分隔符；DelimiterBasedFrameDecoder 使用用户自定义的分隔符来标记消息的结尾。 基于定长消息协议：每一个消息在编码的时候都使用固定的长度，在解码的时候根据这个长度进行消息的拆分和合并。Netty 提供了 FixedLengthFrameDecoder 解码器来实现定长消息解码。 基于变长消息协议：每一个消息分为消息头和消息体两部分，在编码时，将消息体的长度设置到消息头部，在解码的时候，首先解析出消息头部的长度信息，之后拆分或合并出该长度的消息体。Netty 提供了 LengthFieldBasedFrameDecoder 来实现变长消息协议解码。 基于私有通信协议：Netty 提供了 MessageToByteEncoder 和 ByteToMessageDecoder 两个抽象类，这两个抽象类提供了基本的编解码模板。用户可以通过继承这两个类来实现自定义的编解码器。SOFABolt 通过继承 MessageToByteEncoder 实现了自定义的编码器，通过继承修改版的 ByteToMessageDecoder 来实现了解码器。对于处理 TCP 粘包拆包问题，SOFABolt 实际上也是使用变长消息协议，SOFABolt 的私有通信协议将消息体分为三部分 className、header、body，在消息头对应的提供了 classLen、headerLen、bodyContent 分别标识三部分的长度，之后就可以基于这三个长度信息进行消息的拆分和合并。 对于一个成熟的 rpc 框架或者通信框架来讲，编解码器不仅仅是要处理粘包拆包问题，还要实现一些特有的需求，所以必须制定一些私有通信协议，下面来看一下 SOFABolt 的私有通信协议的设计。\nSOFABolt 私有通信协议的设计 以下分析以 SOFABolt 1.5.1 版本为例。SOFABolt 定义了两种协议 RpcProtocol 和 RpcProtocolV2。针对这两种协议，提供了两组不同的编解码器。\n RpcProtocol 协议定义 请求命令（协议头长度：22 byte） ProtocolCode ：这个字段是必须的。因为需要根据 ProtocolCode 来进入不同的核心编解码器。该字段可以在想换协议的时候，方便的进行更换。 RequestType ：请求类型，request / response / oneway 三者之一。oneway 之所以需要单独设置，是因为在处理响应时，需要做特殊判断，来控制响应是否回传。 CommandCode ：请求命令类型，request / response / heartbeat 三者之一。 CommandVersion ：请求命令版本号。该字段用来区分请求命令的不同版本。如果修改 Command 版本，不修改协议，那么就是纯粹代码重构的需求；除此情况，Command 的版本升级，往往会同步做协议的升级。 RequestId ：请求 ID，该字段主要用于异步请求时，保留请求存根使用，便于响应回来时触发回调。另外，在日志打印与问题调试时，也需要该字段。 Codec ：序列化器。该字段用于保存在做业务的序列化时，使用的是哪种序列化器。通信框架不限定序列化方式，可以方便的扩展。 Timeout ：超时字段，客户端发起请求时，所设置的超时时间。 ClassLen ：业务请求类名长度 HeaderLen ：业务请求头长度 ContentLen ：业务请求体长度 ClassName ：业务请求类名。需要注意类名传输的时候，务必指定字符集，不要依赖系统的默认字符集。曾经线上的机器，因为运维误操作，默认的字符集被修改，导致字符的传输出现编解码问题。而我们的通信框架指定了默认字符集，因此躲过一劫。 HeaderContent ：业务请求头 BodyContent ：业务请求体 响应命令（协议头长度：20 byte） ResponseStatus ：响应码。从字段精简的角度，我们不可能每次响应都带上完整的异常栈给客户端排查问题，因此，我们会定义一些响应码，通过编号进行网络传输，方便客户端定位问题。 RpcProtocolV2 协议定义 请求命令（协议头长度：24 byte） ProtocolVersion ：确定了某一种通信协议后，我们还需要考虑协议的微小调整需求，因此需要增加一个 version 的字段，方便在协议上追加新的字段 Switch ：协议开关，用于一些协议级别的开关控制，比如 CRC 校验， …","date":1544091600,"description":"本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。","dir":"blog/sofa-bolt-codec-deep-dive/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9383bfa0b8c9975e3d4b2ed4bc01a593","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","summary":"基础介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之编解码机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","wordcount":3909},{"author":"胡萝卜、丞一","categories":"SOFABolt","content":" 前言 SOFABolt 是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将分析SOFABolt的超时控制和心跳机制。\n超时 在程序中，超时一般指的是程序在特定的等待时间内没有得到响应，网络通信问题、程序BUG等等都会引起超时。系统引入超时机制往往是为了解决资源的问题，比如一个同步RPC请求，在网络不稳定的情况下可能一直无法得到响应，那么请求线程将一直等待结果而无法执行其它任务，最终导致所有线程资源耗尽。超时机制正是为了解决这样的问题，在特定的等待时间之后触发一个“超时事件”来释放资源。\n在一个网络通信框架中，超时问题无处不在，连接的建立、数据的读写都可能遇到超时问题。并且网络通信框架作为分布式系统的底层组件，需要管理大量的连接，如何建立一个高效的超时处理机制就成为了一个问题。\n时间轮（TimeWheel） 在网络通信框架中动辄管理上万的连接，每个连接上都有很多的超时任务，如果每个超时任务都启动一个java.util.Timer，不仅低效而且会占用大量的资源。George Varghese 和 Tony Lauck在1996年发表了一篇论文：《Hashed and Hierarchical Timing Wheels: EfficientData Structures for Implementing a Timer Facility》来高效的管理和维护大量的定时任务。\n时间轮其实就是一种环形的数据结构，可以理解为时钟，每个格子代表一段时间，每次指针跳动一格就表示一段时间的流逝（就像时钟分为60格，秒针没跳动一格代表一秒钟）。时间轮每一格上都是一个链表，表示对应时间对应的超时任务，每次指针跳动到对应的格子上则执行链表中的超时任务。时间轮只需要一个线程执行指针的“跳动”来触发超时任务，且超时任务的插入和取消都是O(1)的操作，显然比java.util.Timer的方式要高效的多。\nSOFABolt的超时控制机制 如上图所示，SOFABolt中支持四中调用方式：\n oneway：不关心调用结果，所以不需要等待响应，那么就没有超时 sync：同步调用，在调用线程中等待响应 future：异步调用，返回future，由用户从future中获取结果 callback：异步调用，异步执行用户的callback 在oneway调用中，因为并不关心响应结果，所以没有超时的概念。下面具体介绍SOFABolt中同步调用（sync）和异步调用（future\\callback）的超时机制实现。 同步调用的超时控制实现 同步调用中，每一次调用都会阻塞调用线程等待服务端的响应，这种场景下同一时刻产生最大的超时任务取决于调用线程的数量。线程资源是非常昂贵的，用户的线程数是相对可控的，所以这种场景下，SOFABolt使用简单的java.util.concurrent.CountDownLatch来实现超时任务的触发。\nSOFABolt同步调用的代码如上，核心逻辑是：\n 创建InvokeFuture 在Netty的ChannelFuture中添加Listener，在写入操作失败的情况下通过future.putResponse方法修改Future状态（正常服务端响应也是通过future.putResponse来改变InvokeFuture的状态的，这个流程不展开说明） 写入出现异常的情况下也是通过future.putResponse方法修改Future状态 通过future.waitResponse来执行等待响应 其中和超时相关的是future.waitResponse的调用，InvokeFuture内部通过java.util.concurrent.CountDownLatch来实现超时触发。 java.util.concurrent.CountDownLatch#await(timeout, timeoutUnit) 方法实现了等待一段时间的逻辑，并且通过countDown方法来提前中断等待，SOFABolt中InvokeFuture通过构建new CountDownLatch(1)的实例，并将await和countDown方法包装为awaitResponse和putResponse来实现同步调用的超时控制。\n异步调用的超时控制实现 相对于同步调用，异步调用并不会阻塞调用线程，那么超时任务的数量并不受限于线程对的数量，用户可能通过一个线程来触发量大的请求，从而产生大量的定时任务。那么我们需要一个机制来管理大量的定时任务，并且作为系统底层的通信框架，需要保证这个机制尽量少的占用资源。上文已经提到TimeWheel是一个非常适合于这种场景的数据结构。\nNetty中实现了TimeWheel数据结构：io.netty.util.HashedWheelTimer，SOFABolt异步调用的超时控制直接依赖于Netty的io.netty.util.HashedWheelTimer实现。\nFuture模式和Callback模式在超时控制机制上一致的，下面以Callback为例分析异步调用的超时控制机制。\nSOFABolt异步调用的代码如上，核心逻辑是：\n 创建InvokeFuture 创建Timeout实例，Timeout实例的run方法中通过future.putResponse来修改InvokeFuture的状态 在Netty的ChannelFuture中添加Listener，在写入操作失败的情况下通过future.cancelTimeout来取消超时任务，通过future.putResponse来修改InvokeFuture的状态 在写入异常的情况下同样通过future.cancelTimeout来取消超时任务，通过future.putResponse来修改InvokeFuture的状态 在异步调用的实现中，通过Timeout来触发超时任务，相当于同步调用中的java.util.concurrent.CountDownLatch#await(timeout, timeoutUnit)。Future#cancelTimeout()方法则是调用了Timeout的cancel来取消超时任务，相当于同步调用中通过 java.util.concurrent.CountDownLatch#countDown() 来提前结束超时任务。具体超时任务的管理则全部委托给了Netty的Timer实现。 另外值得注意的一点是SOFABolt在使用Netty的Timer时采用了单例的模式，因为一般情况下使用一个Timer管理所有的超时任务即可，这样可以节省系统的开销。 Fail-Fast机制 以上关于SOFABolt的超时机制介绍都是关于SOFABolt客户端如何完成高效的超时任务管理的，其实在SOFABolt的服务端同样针对超时的场景做了优化。\n客户端为了应对没有响应的情况，增加了超时机制，那么就可能存在服务端返回一个响应但是客户端在收到这个响应之前已经认为请求超时了，移除了相关的请求上下文，那么这个响应对客户端来说就没有意义 …","date":1544091600,"description":"本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。","dir":"blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8f3ab1ecc952a0fc5ea40576e8b57471","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","summary":"前言 SOFABolt 是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之超时控制机制及心跳机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","wordcount":4303},{"author":"任展","categories":"SOFABolt","content":" 前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将重点分析 SOFABolt 的连接管理功能。\n我们知道，一次 tcp 请求大致分为三个步骤：建立连接、通信、关闭连接。每次建立新连接都会经历三次握手，中间包含三次网络传输，对于高并发的系统，这是一笔不小的负担；关闭连接同样如此。为了减少每次网络调用请求的开销，对连接进行管理、复用，可以极大的提高系统的性能。\n下面我们将介绍 SOFABolt 在连接管理的实现，包括连接生命周期管理、定时断连及自动重连等。\n设计抽象 首先我们将会介绍 SOFABolt 对连接的封装抽象。\n连接封装 SOFABolt 中定义了一个基础的连接类 \u0026amp;ndash; Connection:\n省去 AtributeKey 类型定义以及 Log 配置，以上是Connection中所有的成员变量。包括几个方面:\n 连接：Channel、Url 版本：protocolCode、version 调用：invokeFutureMap 附着：attributes 引用：referenceCount、id2PoolKey、poolKeys 这里提一下 protocolCode 和 version，版本信息会被携带至对端，用于连接的协商。总的来说，通过对于 Channel 的包装，Connection 提供了丰富的上下文及引用信息，是 SOFABolt 连接管理的直接对象。\n连接事件 SOFABolt 定义了连接事件和事件监听器用于处理连接对象。ConnectionEventType 定义了三种事件类型：CONNECT, CLOSE 和 EXCEPTION. 针对不同的连接事件类型，我们可以通过事件监听器 \u0026amp;ndash; ConnectionEventListener 来进行处理，下面来看一下 ConnectionEventListener 类：\n监听器定义了两个方法 onEvent 和 addConnectionEventProcessor, 分别是触发事件和添加事件处理器。整个监听器采用一个 HashMap 来存储事件类型及其对应的处理器集合。在触发相关连接事件后，会遍历处理器集合并调用处理器执行。\nSOFABolt 的连接管理集中在 ConnectionEventHandler 中处理，他继承了 ChannelDuplexHandler，是标准的用来处理Connection连接对象并进行日志打印的一个处理器。先来看一下成员组成：\n其中连接事件监听器上文已经提及，剩下的几个成员从名称上也通俗易懂，先简单介绍一下，后续会详细地展开：\n 连接管理器：管理连接对象，包括创建、添加、删除、检查是否可用等等 连接事件监听器：监听连接事件的触发，然后执行对应的逻辑 连接事件执行器：包装后的线程池，用于异步触发连接事件监听器来处理对应的连接事件，值得一提的是，这个线程池只有一个线程。 重连管理器：顾名思义，管理重连的Url对象以及执行重连任务 全局开关：全局的设置，比如是否需要管理连接对象、是否需要执行重连任务等等 代码中方法都比较简单，大部分的处理逻辑围绕 Connection 对象展开，主要是维护有关本 Channel 对象的 Connection 对象的生命周期(包括connect、close等事件)。下面着重分析两个方法：\nhannelInactive 方法是在连接断开前触发的方法，在 SOFABolt 里的处理逻辑中，会根据globalSwitch 中 CONN_RECONNECT_SWITCH 的开关状态来判定是否开启重连的任务。除此之外，会在最后触发该 Connection 对象的 CLOSE 事件。这个触发事件是在异步线程中执行的，也就是上文提到的连接事件执行器。\n另一个是 userEventTriggered 方法， 用来触发自定义的用户事件，通过查看本方法的调用位置，可以得知，该方法是在连接建立的最初被触发的，一个简单的例子可以在RpcServer类中找到：\n在连接建立触发 fireUserEventTriggered 方法后，我们就开始执行对应此方法中的逻辑，也可以看到，在判定是 CONNECT 事件后，通过attr得到绑定在Channel的Connection对象，然后就同 channelInactive 方法一样，触发 CONNECT 事件异步执行对应的处理器逻辑。\n连接管理 下面来介绍 ConnectionManager，SOFABolt 提供了默认的实现类 DefaultConnectionManager类。顾名思义，主要负责连接对象的管理：\n 通过工厂创建 Connection 连接对象 通过注入的选择策略进行 Connection 连接的选择 管理创建和添加的 Connection 对象和 ConnectionPool 连接池对象（包括检查 Connection 对象、维护 ConnectionPool 的健壮性） 控制 Connection 对象的心跳打开与关闭 创建连接 ConnectionFactory 用于创建连接对象，SOFABolt 提供了两个实现类： DefaultConnectionFactory 和 RpcConnectionFactory。这个工厂类执行了客户端所有 Connection 对象的创建工作，代码也比较简单：\n注意到了吗，在创建完毕 Connection 对象后，执行了 fireUserEventTriggered 方法，这样就保证了每一个 Connection 对象在创建之后都会去触发 CONNECT 事件。\n选择连接 ConnectionSelectStrategy 选择策略的默认实现是随机策略 RandomSelectStrategy, 在执行选择连接时大致分为两步：\n 在开启CONN_MONITOR_SWITCH监控时，会从该连接池所有的连接中做一个简单的filter操作，把CONN_SERVICE_STATUS为ON的连接挑选出来，作为选择池。如果没有开启监控，那么选择池就是连接池。 执行挑选策略，获取选择池中的一个连接。 管理连接和连接池 管理连接和连接池是 ConnectionManager 最主要的作用，用来进行连接和连接池的生命周期管理，包括添加、删除、检查健康、恢复连接数等功能。下面先看一个在添加中常见的方法，用来获取一个连接池对象或者创建一个，限于篇幅，这里不贴代码，有兴趣的同学可以在 GitHub 上查看源码。在执行创建连接池对象时，会有两种逻辑:\n 返回空的连接池 返回一个初始化过的连接池(有一定的连接数) 这两种逻辑其实对应的是两种需求，第一个对应连接已经创建好然后放入连接池的流程，第二个则是对应通过 Url 来创建一个连接池并且在连接池中做新建连接的流程。那么对于第二种情况，由于建立连接需要耗时且有可能抛出异常，所以 ConnectionManager 允许重试两次。\n下面来说说对于连接和连接池的维护方面的功能， …","date":1544091600,"description":"本文将重点分析 SOFABolt 的连接管理功能。","dir":"blog/sofa-blot-connection-management-deep-dive/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"99733a6333604b8aeb8ada37d5705d36","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","summary":"前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之连接管理剖析","type":"blog","url":"/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","wordcount":3490},{"author":"奕杉","categories":"Service Mesh","content":" 朵晓东，花名奕杉，蚂蚁金服高级技术专家。专注企业云计算技术及产品，蚂蚁金融云 PaaS 创始团队核心成员，Antstack 网络产品负责人。开源爱好者，Apache Kylin 创始团队核心成员；SOFAMesh 创始团队核心成员，SOFAMosn 项目负责人。 本文根据晓东在 GIAC 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，我是蚂蚁金服系统部的高级技术专家奕杉，今天分享的内容是: 《蚂蚁金服在 ServiceMesh 推进落地过程中对新型网络代理的思考和实践》\n内容结构： 主要的分享顺序：\n 背景概述 架构设计及功能特性 技术案例 总结展望 1、背景、概览 ServiceMesh 作为云原生之上的服务网格技术在今年引起了业界的广泛关注，首先我们来看一下目前 ServiceMesh 数据平面的一些方案。\n最为大家熟知的是老牌七层代理 Nginx 和 ISTIO 原生的数据平面 Envoy。Nginx 早已在国内外广泛使用，近两年积极探索 K8S、ServiceMesh 微服务场景，并推出了与 ISTIO 集成的微服务解决方案，试图扩展其场景边界，拿下新的领域，从单纯的7层流量代理到云原生时代的智能数据平面转型。但目前看 “NgMesh”研发不够活跃，已知的使用方也不多。Envoy 作为 Google 和 Lyft联合开发的 ISTIO 原生数据平面产品，近两年借助 ServiceMesh 微服务场景快速打开了市场，并在一些互联网公司推广使用，同时引入了一批开发者进行 API 网关等功能网关的开发，发展势头非常好。\n其次 LINKERD 是基于 Rust 的一种高性能数据平面，但其发展空间受到了 Envoy 挤压，业界使用的公司也比较有限。\n蚂蚁金服基于自身诉求自研了基于 Golang 的数据平面 SOFAMosn（后简称MOSN），并在蚂蚁、UC 等公司落地使用。 同时对业界开源，提供了一种新的数据平面产品选择。\n此外国内的华为、新浪等公司都基于自身场景提出了数据平面方案并先后进行了开源，数据平面竞争已经从独霸业界的基于 Nginx 二开方案逐步转变为目前的多样化产品同场竞技的局面。\n为什么众多大厂纷纷投入研发数据平面呢？\n我个人认为新生技术栈、云原生、微服务快速发展等契机对数据平面提出了场景多样化、功能服务化、云原生亲和等多重挑战。\n以往从未像现在这样对数据平面提出过如此多的要求：\n 数据平面需要执行部署运维中的流量切换； 需要提供云亲和的细粒度流量调度功能； 需要提供微服务亲和的服务发现、路由组网特性； 需要以云原生的方式感知资源； 需要支撑服务粒度、高度自定义的压测、故障测试、线上灰度流量管理； 需要提供链路级、服务级的安全隔离保护，需要支持多种语言、多种协议的转换分发能力； 需要能享受系统层面、硬件层面的红利； 需要为复杂的运维架构（如蚂蚁的 LDC 等）提供可扩展的流量调拨能力等等； 当然根据每个公司的业务场景可能还有其他的因素。 最后，如何要将这些能力都汇聚在统一的数据平面产品上，弥合南北向、东西向数据平面由于技术栈、团队等差异带来的鸿沟，变成了另一个更为复杂的问题。这里所提到的问题中任何一点扩展开来都可以是一个丰富独立的 Topic，受限于篇幅本次分享只能介绍我们在解决这些问题中的一小部分思考和实践。\n2、SOFAMesh 架构 \u0026amp;amp; 重点特性 首先，蚂蚁已经将基于 ISTIO 的 ServiceMesh 方案 \u0026amp;ldquo;SOFAMesh\u0026amp;rdquo; 开源，在控制面我们选择克隆 ISTIO 官方版本并研发符合蚂蚁需求的控制面，在数据面我们选择使用 Golang 研发数据平面 MOSN，目前已经支持了微服务场景所需的大量常用功能。\n这里我根据 ISTIO 的 Task 文档总结了目前 SOFAMesh 支持的一些能力，如：透明拦截适配，细粒度的流控，故障注入，双向链路加密等。对于一些暂时存疑的功能，如 Mixer Check 等，暂时没有支持。目前 SOFAMesh 已在 UC 生产环境落地使用，满足了 Sidecar、Ingress、Egress 多种场景的使用需求。在这里附上 SOFAMesh，SOFAMosn 的 Github 地址，也欢迎大家使用交流。\nSOFAMesh: https://github.com/alipay/sofa-mesh SOFAMosn: https://github.com/alipay/sofa-mosn\n再来看看蚂蚁内部，由于目前蚂蚁生产环境尚未大量铺开K8S，并且已经存在一套完善的管控技术体系，加上目前ISTIO 的性能和稳定性还不满足大规模微服务场景等原因，我们暂时没有选择直接升级到 ISTIO，而是通过优先落地Sidecar 的方式来赢得 ServiceMesh 解决方案带来的红利。在蚂蚁内部，MOSN 接管了SOFABoot 应用，代理了服务发现、路由/负载均衡、通信等工作，构成了微服务网格，通过自有的中间件及管控平面进行微服务的管理、治理。同时，我们积极的推进 MOSN 与 SOFA中间件，网络接入层，安全防护及监控体系的整合，以提供更统一更强大的数据平面。\n接下来我将介绍 MOSN 支持多协议的方案。\n为了在内部快速落地试错，我们首先支持了内部使用最广泛的 SOFARPC 协议，并对其进行了深度优化。随后我们根据 UC Mesh 化推进遇到的普遍问题提出了 XProtocol 方案，以在不解包的场景下提供路由能力。最后我们深度改造了三方 HTTP/1.1 实现及官方 HTTP/2.0 实现。到目前为止，MOSN 已提供了多种协议的支持。同时 MOSN 提供了两种自定义协议的能力支持使用者通过扩展的方式自定义协议实现，满足需要解包、不需要解包的协议扩展需求。\n除协议之外，性能是大家比较关心的另一个问题。为了提供满足生产要求的7层转发性能，我们在 IO、协议、内存、协程、网络处理等方面进行了优化，从目前通过 SOFARPC 通信应用的上线情况来看可以满足生产使用要求，在案例分析中我将展示一些性能数据，后续我们也将继续推进性能优化，以达到更好的性能。\n在安全能力上，SOFAMesh 支持 mTLS，并在蚂蚁内部集成蚂蚁内部的 KMS 完成了 mTLS 落地，同时 RBAC 功能在研发中，此外WAF、流量镜像能功能也在规划中。\n在蚂蚁内部基于 MOSN 的网关产品正在研发中，将会在稳定验证后开源。网关场景相对于 Sidecar 场景有一些特性需求，比如说一般会 Hold 住大量长链接，比如说会根据请求内容动态选择后端应用，由于网关可能代理了不同的后端应用，就会需要动态选择后端协议。此外还有一些网关类的通用能力需求，如签名，授权，限流等。\n为了能基于开源版建设蚂蚁内部的 Sidecar 及网关产品，我们充分考虑了开源版 MOSN 的扩展性，在路由、后端管理、TLS、网络、流处理等各方面提供了扩展性支持。对于其他使用 MOSN 的场景，也可以通过类似的方式来满足自身业务定制需求。\n为了更清晰的展示 MOSN 功能特性，这里将 MOSN 0.4.0 的功能特性通过表格的方式展示出来。可 …","date":1543906800,"description":"本文根据晓东在 GIAC 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-giac-2018/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"71d6ede37fa4f1d1e6c99fbd37ff2f52","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-giac-2018/","publishdate":"2018-12-04T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/service-mesh-giac-2018/","summary":"朵晓东，花名奕杉，蚂蚁金服高级技术专家。专注企业云计算技术及产品，蚂蚁金融云 PaaS 创始团队核心成员，Antstack 网络产品负责人。开源爱好者，","tags":["Service Mesh"],"title":"蚂蚁金服 Service Mesh 新型网络代理的思考与实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-giac-2018/","wordcount":7130},{"author":"敖小剑","categories":"Service Mesh","content":" 敖小剑，蚂蚁金服高级技术专家，十六年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher 社区联合创始人。 龙轼，阿里巴巴技术专家、前京东 Hadoop 负责人、Hadoop 代码贡献者、现负责UC 基于 Kubernetes 自研的 PaaS 平台整体的稳定性。 本文根据他们在 Service Mesher Meetup 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，今天给大家带来的演讲主题是《蚂蚁金服 Service Mesh 渐进式迁移方案》，给大家介绍一下我们蚂蚁金服主站的 Service Mesh 迁移方案，在稍后的内容中我会给大家解释什么是“渐进式”。今天的演讲方式有些特殊，将会是两位讲师合作。我是敖小剑，来自蚂蚁金服中间件团队，另外一位讲师 龙轼 ，来自 UC 基础研发部。\nService Mesh 演进路线 今天的内容将会有四块主要内容：\n Service Mesh演进路线：介绍蚂蚁金服计划在主站落地Service Mesh的方案，由于涉及到大量的存量应用和超大规模，又要保证迁移过程的平滑，因此我们的落地方案相比社区方案要复杂的多。 实现平滑迁移的关键：介绍在整个迁移方案中，为了实现平滑迁移的几个关键做法，然后今天我们将详细展开其他的一个关键点：DNS寻址方案。 DNS寻址方案的演进：详细介绍Kubernetes/Istio/SOFAMesh一路演进过来的DNS寻址方式 DNS寻址方案的后续规划：介绍我们在DNS寻址方案上的后续规划。 前两块内容将由我来为大家介绍，后两块内容将由我的同事 龙轼 为大家介绍。\n在展开内容之前，先看一下背景，Service Mesh在蚂蚁金服主站落地的背景：\n 目标：需要满足我们对长期目标的认可，具体指服务间通讯走Service Mesh，而且是Istio这种带完整的控制平面的Service Mesh形态，基础设施要构建在k8s之上，而应用的形态要向微服务靠拢。 现状：而现实是存在很多挑战，首先还有很多应用没有实现微服务化，而且我们的k8s普及程度也不够，还有非常多的应用没有运行在kubernets之上。Istio的成熟程度也稍显不足，不够稳定，更大的挑战的是Istio目前无法原生支持我们蚂蚁金服的规模，我们还在试图对Istio进行改进和扩展。最后，在落地时必须考虑的非常现实的一点：现有系统中为数众多的应用不可能一夜之间全部迁移。 关键需求：因此在落地实施时，非常重要的需求是：要实现平滑迁移。简单说，微服务 + Service Mesh + kubernetes 是我们的目标，但是如何从现有体系出发，向目标平稳和坚实的迈进，必须给出可行的实践指导。 今天演讲的内容，要给大家介绍的就是，在这样的背景下，我们蚂蚁金服选择的Service Mesh主站落地演进方案。这个方案预期会在2019年初全面铺开。\n主站落地方案的实施原则，这是我们在过去半年的实践中，总结归纳出来的行为指导：\n 符合远期规划：一定要有清晰的长期目标，明确的知道未来的大方向。避免走弯路，避免浪费投资，理想状态是计划中的每一步都可以为下一步奠定坚实的基础。即使因为某些原因不得已妥协或绕行，也应该清晰的知道后面应该如何回归，谢绝中途推倒重来——代价太高，无法承受。 循序渐进：认清现实，如此之大的变革，一定是需要分步进行，不要心存一步登天的幻想，现实可行的方式是小步快跑。将整个过程拆解为若干个大步骤，每一步的工作量和复杂度都控制在一个可以接受的范围内，以保证每一步都简单方便，切实可行。 有可操作性：在操作层面上，要有足够的弹性，即每个步骤中的工作内容，都应该是可以分批进行。以步步为营的方式，逐步扩大战果，杜绝一刀切。 在接下来的演进路线中，大家将会体会到这三个原则在实际落地时的指导作用。\n这个图的信息量有点大，描述的是 Service Mesh 和 k8s 落地可能的多种演进路线。\n我们先从最下面开始看，这是当前蚂蚁金服主站大多数应用的现状：即应用\u0026amp;rdquo;部署在非k8s上\u0026amp;rdquo;，应用也\u0026amp;rdquo;不是Service Mesh形态\u0026amp;rdquo;。 然后看最上面，这是我们期望的蚂蚁金服主站未来的应用终极形态：应用\u0026amp;rdquo;部署在k8s上\u0026amp;rdquo;，应用也迁移到了\u0026amp;rdquo;Service Mesh形态\u0026amp;rdquo;。\n这里有个特别的地方，我们将Service Mesh形态细分为两种模式：\n Sidecar模式：只有Sidecar，没有控制平面，和外部系统的各种集成都是在Sidecar中直接进行。这是第一代的Service Mesh，Linkerd/Envoy都是如此，华为基于ServiceComb演进而来的mesher，新浪微博的Mesh，包括我们蚂蚁金服基于MOSN开发的用于取代多语言客户端的Mesh方案。 Istio模式：有完善的控制平面，可以提供强大的控制能力，而且从数据平面分离，这是第二代的Service Mesh，典型如Istio和Conkduit/Linkerd 2.0。 之所以将Service Mesh形态细分，是因为我们有着这样一个特殊背景：目前的原生Istio无法支撑我们蚂蚁金服的规模，因此在改进完善Istio之前，我们不得不暂时在Sidecar模式下短暂停留。另外一个原因就是考虑到存量应用的迁移，多一个Sidecar模式作为中间缓冲，会让整个迁移过程平滑很多。\n现在我们来介绍图中展示的四条演进路线：\n 左边的路线1，思路是先将应用迁移k8s部署，再迁移到Service Mesh形态。这条路线的最大好处，是过程中每个阶段的绝大多数投资都将最终得以保留，因为符合k8s+service mesh的远期目标。 右边的路线2，思路是跳过k8s，先迁移到Service Mesh形态，一路演进到Istio模式，然后最后迁移到k8s。 中间的路线3，直接一步到位，这个路线是Istio默认的方式，或者说Istio根本没有考虑过迁移的问题，默认客户已经有完善的k8s，然后将改造好的应用直接部署在Istio上。这个路线对于蚂蚁金服主站的复杂场景，当然是不现实的。（补充：只是对蚂蚁金服主站不合适，对于大多数公司，规模不是那么巨大，也没有历史负担，也有k8s基础，完全可行。） 还有一条特别的路线4，走位飘忽，先和路线2一样迁移到Sidecar模式，然后走回路线1，上k8s，再在有k8s支持的情况下继续演进到Istio模式。 下面我们来详细分析各条演进路线的优劣和实施条件。\n演进路线2，和路线1的核心差别，在于：是先上k8s，还是先上Service Mesh。而且路线2是在非k8s条件下一路演进Service Mesh到我们期望的终极形态Istio模式，这意味着过程中和最终目标有非常大的偏移。\n演进路线2的好处，在于第一步非常的自然：\n 没有k8s的限制，因此不依赖基础设施，实施方便。毕竟，k8s普及度是个大问题； 在原有的侵入式框架的客户端SDK基础上，通过包裹一个proxy，重用原有SDK的能力，可以非常快速的得到一个基本可用的Sidecar； 除了多一个proxy外，没有引入太多的新概念和新 …","date":1543474800,"description":"本文根据敖小剑、龙轼在 Service Mesher Meetup 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-meetup-5-retrospect/","fuzzywordcount":10300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5031be4287bf1a7d7921bf5133ea414c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","publishdate":"2018-11-29T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","summary":"敖小剑，蚂蚁金服高级技术专家，十六年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher 社区联合创始人。 龙轼，阿里巴","tags":["Service Mesh"],"title":"Service Mesh 渐进式迁移方案 | Service Mesh Meetup 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","wordcount":10259},{"author":"鲁直","categories":"SOFAMesh","content":" 本文作者：黄挺，蚂蚁金服高级技术专家，蚂蚁金服分布式架构 SOFA 的开源负责人。目前在蚂蚁金服中间件团队负责应用框架与服务化相关的工作。 本文根据黄挺在 CNUTCon 全球运维大会的主题分享整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，我是来自于蚂蚁金服的黄挺，花名鲁直，目前在蚂蚁金服负责微服务团队，也是 SOFA 开源的负责人。来到这个场子的朋友们肯定都知道，Service Mesh 在过去一两年之中迅速成长为社区中非常热门的话题，几乎所有的大会中，都多多少少有一些关于 Service Mesh 的话题。在一个月之前，我的同事敖小剑老师在上海的 QCon 中也分享了蚂蚁金服在 Service Mesh 上的探索，包括在前面的场次中，来自华为的巨震老师也分享了华为在 Service Mesh 上的一些思考。在今天的分享中，我不会去花太多时间介绍什么是 Service Mesh，更多地聚焦在蚂蚁金服将 Service Mesh 用在解决多语言的问题上的一些实践，希望在场的各位可以从这些实践中有所收获。\n这个是我今天介绍的主要的内容，首先，我会大家简单介绍一下多语言在蚂蚁金服发展的一些情况，铺垫一下背景，交代各个语言在蚂蚁金服的使用情况，并且之前在多语言通信上面遇到了哪些问题。\n然后，我会给大家简单介绍下 SOFAMesh，SOFAMesh 是蚂蚁金服产出的 Service Mesh 的解决方案。\n接着我会介绍我们在 SOFAMesh 之上架构的多语言通信的方案以及在这个方案的实施过程中遇到的一些技术要点。\n蚂蚁金服多语言发展 不知道在场的同学有没有听说过 SOFA，SOFA 是蚂蚁金服大约 10 年前开始研发的一套分布式中间件，包括了微服务体系，分布式事务，消息中间件，数据访问代理等等组件，这套组件一直以来都是完全用 Java 来构建的，因此基于 SOFA 构建的 SOFA 应用也都是用 Java 写的，在蚂蚁金服，目前大概有接近 2000 个 SOFA 应用，顺带提一下，这套 SOFA 中间件目前已经部分开源在 Github 上面。从这个数据我们也可以显而易见地得出以下的结论，Java 在蚂蚁金服，至少在在线的应用上，占据了绝对主导的地位。\n随着无线技术的发展以及 NodeJS 技术的兴起，在 2013 年，蚂蚁金服开始引入了 NodeJS，研发了 EggJS，目前也已经在 Github 上开源，在蚂蚁金服，我们主要将 EggJS 作为服务于无线以及 PC 的 BFF 层来使用，后端的所有的微服务还都是用基于 Java 的 SOFA 来研发，EggJS 要调用后端的 SOFA 服务，并且对 PC 和无线端提供接口，必然就要遵守 Java 世界的 SOFA 之前定下的种种“规矩”，事实上，蚂蚁金服的 NodeJS 团队完全用 EggJS 适配了所有的 SOFA 中间件的客户端，保证在 EggJS 上，也可以使用所有的 SOFA 中间件，可以和之前基于 Java 研发的 SOFA 应用进行通信。但是，由于 Java 在蚂蚁中间件上的主导地位，导致 SOFA 中间件的某些特性的实现，完全依赖于 Java 特有的语言特性，因此，NodeJS 团队在追赶 SOFA 中间件的过程中，也非常的痛苦，在后面的例子中，我会有一些具体的例子，大家看了之后肯定会感同身受。\n再到最近几年，随着 AI 的兴起，在蚂蚁金服也越来越多地出现 CPP，Python 等系统，而由于 CPP 和 Python 等等语言，在蚂蚁金服并没有一个独立的基础设施团队去研发对应的中间件，因此，他们和基于 Java 的 SOFA 应用的互通就降级成了直接采用 HTTP 来通信，这种方式虽然也可以 Work，但是在通信基础之上的服务调用的能力却完全没有，和原本的 SOFA 的基础设施也完全没法连接在一起。\n基于以上的一些现状，可以看到我们在发展过程中的主要的两个问题，一个是基础设施上的重复投入的消耗，很多 SOFA 中间件的特性，除了用 Java 写了一遍之外，还得用 NodeJS 再写一遍。另一个是以 Java 为中心，以 Java 为中心其实在只有 Java 作为开发语言的时候并没有什么问题，但是当其他的语言需要和你进行通信的时候，就会出现巨大的问题，事实上，很多框架上的特性的研发同学在不经意之间，就直接就用了 Java 的语言特有的特性去进行研发，这种惯性和隐性的思维会对其他语言造成巨大的壁垒。\n基于以上的问题，我们希望能够产出一个方案，一方面，可以尽量做到一次实现，到处可用。另一方面，需要能够保证语言的中立性，最好是能够天然地就可以让框架或者中间件的研发的同学去在做架构设计以及编码的时候，考虑到需要支持多语言。\nSOFAMesh 其实在这之前，我们已经尝试在数据访问层去解决类似的多语言适配的问题，蚂蚁金服有一个 OceanBase 的数据库，当各个语言需要访问 OceanBase 数据库的时候，采用的就是一个本地的 Proxy，这个 Proxy 会负责 Fail Over，容灾等等场景，而对各个语言只要保证 SQL 上的兼容就可以了，这让我们意识到，Proxy 的模式可能是解决多语言的一个方式，然后，在业界就出现了 Service Mesh，如果只是从技术上讲，Service Mesh 的 Sidecar 本质上也就是一个 Proxy，只是每一个服务实例都加上一个 Sidecar，这些 Sidecar 组成了一个网络，在加上一个控制平面，大家把他叫做 Service Mesh。通过 Service Mesh，我们可以将大量原来需要在语言库中实现的特性下沉到 Sidecar 中，从而达到一次实现，到处可用的效果；另外，因为 Sidecar 本身不以 Library 的形式集成到特定语言实现的服务中，因此也就不会说某些关键特性采用特定语言的特性来实现，可以保证良好的中立性。\n看起来 Service Mesh 似乎是一个非常完美的解决方案，但是如果我们探寻一下 Service Mesh 的本质的话，就会发现 Service Mesh 并非完美解决方案，这种不完美主要是体现在 Service Mesh 本质上是一种抽象，它抽象了什么东西，它把原来的服务调用中的一些高可用的能力全部抽象到了基础设施层。在这张 PPT 中，我放了三张图片，都是一棵树，从左到右，越来越抽象，从图中也可以非常直观地看出来，从右到左，细节越来越丰富。不管是什么东西，抽象就意味着细节的丢失，丢失了细节，就意味着在能力上会有所欠缺，所以，在 Service Mesh 的方案下，虽然看起来我们可以通过将能力下层到基础设施层，但是一旦下层下去，某些方面的能力就会受损。\n因此，我们希望能够演化出这样一套多语言通信的方案，它能够以 Service Mesh 为基础，但是我们也会做适当地妥协去弥补因为上了 Service Mesh 之后的一些能力的缺失。首先我们希望有一个语言中立的高效的通信协议，每个语言都能够非常简单地理解这个协议，这个是在一个跨语言的 RPC 通信中避免不了的，无论是否采用 Service Mesh。然后， …","date":1542870000,"description":"本文根据黄挺在 CNUTCon 全球运维大会的主题分享整理，完整的分享 PPT 获取方式见文章底部。。","dir":"blog/sofa-mesh-cnutcon-2018/","fuzzywordcount":7000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5a750edaa8c6a9759fd5e3533dd3fa4d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","publishdate":"2018-11-22T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","summary":"本文作者：黄挺，蚂蚁金服高级技术专家，蚂蚁金服分布式架构 SOFA 的开源负责人。目前在蚂蚁金服中间件团队负责应用框架与服务化相关的工作。 本文根据黄挺","tags":["SOFAMesh"],"title":"蚂蚁金服 SOFAMesh 在多语言上的探索实践","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","wordcount":6910},{"author":"明不二","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》最后一篇，作者明不二，就职于华为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部完成，感谢所有参与的源码爱好者！\n 前言 在应用服务化架构中，RPC 框架是非常重要的基础组件。而在 RPC 框架当中，序列化（以及反序列化）又是必不可少的一环。因为序列化的性能对整体框架性能有比较大的影响，之前的文章中，我们已经详细剖析了 SOFARPC 各个核心功能模块的实现原理，想必大家已经很清楚 RPC 的调用流程。\n在整个 RPC 调用流程当中，序列化及反序列化起到了承上启下的作用。序列化时，RPC客户端把待调用的方法和参数对象转换为网络上可传输的字节序列，为进一步的编解码提供原料。反序列化时，把从网络上接收到且已经解码了的字节序列转换成对象，便于 RPC 服务端调用。\n本文将从序列化概述、序列化协议特性、序列化使用方法分类、SOFARPC 序列化的设计及实现、几种序列化协议对比等方面介绍及对比序列化及其在 SOFARPC 中的应用。\n序列化概述 RPC 调用通过网络传输相关的调用方法及参数，在这个网络传输过程中，内存中的对象是无法直接传输的，只有二进制字节才能在网络上传输。而为了实现调用对象在网络上的传输，必须通过序列化实现对象 -\u0026amp;gt; 字节的过程，以及反序列化实现字节 -\u0026amp;gt; 对象的过程。在网络协议模型中，序列化属于应用层协议的一部分。\n如下列定义：\n序列化：将数据结构或者对象转换成二进制串的过程。\n反序列化：将序列化过程中生成的二进制串转换成数据结构或者对象的过程。\n在上述定义中，二进制字节数组专指 Java 语言中的 byte[]。\n序列化协议特性 每种序列化协议都有其优点和缺点，在对一个序列化协议进行衡量评判时，通常由如下一些指标可以参考：\n 指标 说明 重要性 通用性 是否跨平台，社区如何 中高 可读 序列化格式是否可读 中低 易用性 是否简单易用 中高 性能 序列化后的大小和压缩 CPU消耗 中高 可扩展性 是在允许字段修改 高 安全性 是否存在一些无法修复的漏洞 高 以下逐个来详细说明：\n通用性 在通用性上，主要考察该序列化协议是否支持跨平台、跨语言的使用，同时兼顾考察业界的流行度及社区的活跃性。\n可读/易用性 在可读、易用性上面，主要考察该序列化协议序列化之后是否人眼可读，如 XML 和 JSON 就是人眼可读的序列化框架，这会大大提高调试的效率。同时，需要考察序列化框架所提供的 API 是否容易学习、调用。当然，在远程调用 的场景下，可读性不是一个重要因素。或者说，我们更多希望不可读。来保证一定的安全性。\n性能 性能指标，主要考虑序列化框架的时间复杂度和空间复杂度。\n序列化之后的数据一般都是用于存储或者网络传输，空间占用大小决定了传输的效率。序列化通常情况下要在原有的数据上加上描述字段，如果这个过程中引入的额外开销过大，则在大规模分布式系统中，很可能会造成巨大的额外空间开销。\n同时，为了提高系统的性能，是否耗费 CPU，解析和反解析二进制串的时间也是一个非常重要的指标。\n可扩展性 主要考虑当系统准备升级，需要对实体的属性进行变更，此时序列化协议能否快速支持，并且不会对原有的系统造成影响。如作为服务提供方的 API 接口入参中，增加了一个字段，是否一定要强制所有的客户端进行升级。这个会涉及到线上兼容性的问题。一般我们要求新增字段，在客户端尚未使用的情况下，不应该有序列化问题。\n安全性 需要考察序列化协议是否支持跨局域网之间的安全访问。是否存在一些安全漏洞。可以通过构造一些字节数组，使得服务端反序列化的时候，触发某些安全漏洞，执行一些系统调用，或者越权操作。\n序列化使用方式分类 按照序列化的使用方式，可以分为自描述型序列化以及基于中间格式型序列化。\n自描述型 所谓的自描述型，即在序列化的字节流里有着完整的对象类型信息和属性信息，可以在不依赖任何外界描述信息的前提下，只要拿到这个二进制流，就可以直接还原出原始对象。\n类似的系列化产品有：hessian、JSON、XML 等。\n例如，有如下一个对象 Person，Java 语言定义如下：\npackage com.sofa.test.Person; public class Person { private int age = 15; private String name = “sofa”; } 则使用 hessian 序列化后的字节流如下：\nM**com.sofa.test.PersonS**nameS**sofaS**ageI**b3 b2 b1 b0 z\n上面的*和b3 b2 b1 b0都表示不可打印的二进制。从上面内容可以看出，按照相应规定就能从二进制串中反序列化出对象来。因为这里面已经描述了类型，类型的字段名，以及对应的值，这样就可以直接反序列化了。\n基于中间描述型 一般这种类型的序列化主要用于跨语言当中，比如 Protobuf以及 thrift等等。在使用时都需要事先定义一个中间格式的文件（IDL 文件），然后根据不同语言的生成工具生成一个相应语言的可序列化类。以下是一个简单的 Proto的描述文件\nmessage SofaApp{ string appName = 1; repeated string authList = 2; repeated string serviceList = 3; } 然后当需要反序列化时，根据 IDL 文件及逆行相应的反序列化即可。格式是这样\n其中，图中的用户定义编号就是前面 proto中对每个字段定义的编号。\nSOFARPC 序列化的设计与实现 SOFARPC 支持及将要支持的序列化协议有：hessian、Protobuf、Json。\n序列化接口定义 在目前的 SOFARPC 5.4 分支中，已经支持的序列化协议有 hessian 和 Protobuf。两个序列化实现类继承了 AbstractSerializer抽象类，该抽象类又实现了如下的 Serializer接口：\n/** * 序列化器接口 * * @author \u0026amp;lt;a href=mailto:zhanggeng.zg@antfin.com\u0026amp;gt;GengZhang\u0026amp;lt;/a\u0026amp;gt; */ @Extensible(coded = true) @Unstable public interface Serializer { /** * 序列化 * * @param object 对象 * @param context 上下文 * @return 序列化后的对象 * @throws SofaRpcException 序列化异常 */ public AbstractByteBuf encode(Object object, Map\u0026amp;lt;String, …","date":1541055600,"description":"本文为《剖析 | SOFARPC 框架》最后一篇，作者明不二，就职于华为。","dir":"blog/sofa-rpc-serialization-comparison/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f0a5fd044fa69071a7251518ea7d69f6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-serialization-comparison/","publishdate":"2018-11-01T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-serialization-comparison/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 序列化比较","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-serialization-comparison/","wordcount":3267},{"author":"鸥波","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十二篇，作者鸥波。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 随着 TIOBE 10月份的编程语言排行 的发布，C++重回第三的位置，新兴的 Swift 和 Go 表现出强劲的上升趋势。与此同时，虽然目前 Java 的领头位置尚未出现有力挑战，我们希望能够在基础设施的建设上预留跨语言的可扩展设计。同时，跨语言的挑战也是工程实际面临的现状，蚂蚁内部如 AI、IoT，算法等缺少 JVM 原生支持的领域，往往不可避免地需要涉及到跨语言调用的问题。\n本文将为大家介绍 基于 SOFARPC 的微服务应用在面临跨语言调用时的方案和实现。\n总体设计 经过前面几篇对 SOFARPC 的 BOLT 协议和序列化这些的介绍，相信大家已经对 RPC 有了一些自己的理解，提到跨语言，我们会首先想到其他语言调用 Java，Java 调用其他语言，那么这里的跨，体现在代码上，到底跨在哪里？\n从跨语言的实现上来说，主要解决两个方面的问题：\n 跨语言的通讯协议和序列化协议\n 跨语言服务发现\n 另外从跨语言的落地来说，还得解决一个平滑兼容的问题。\n业界常见的做法是一般是通过 DNS 和 HTTP 来解决跨语言的问题，但是在内部已经有完善技术栈体系的情况下，直接切换一个新的方案显然是不合适的，所以蚂蚁内部是在已有的技术体系基础上进行改进。\n蚂蚁内部使用的通讯协议是Bolt，序列化协议是Hessian。我们知道，服务端和客户端在请求和返回之间携带的结构化的业务数据，需要在传输到达对端后，被本地的语言能够易于解析消费。由于语言本身特性的差异，同一对象的在序列化和反序列化的转换后，结构可能有差异，但是需要保证其转换操作是可逆的。以上这点Hessian做的不是很好，其跨语言的兼容性不能满足跨语言的需求，所以另外一个可行的方案就是就是选择其它基于 IDL 的序列化协议，例如Protobuf。\n现成的服务注册中心一般都有一些多语言解决方案，像Zookeeper、SOFARegistry、Consul、etcd等都有多语言客户端，所以服务发现这块问题不算太大。\n例如下面就是一个基于注册中心 + Bolt 协议 + Protobuf 序列化的设计图。\n通讯协议和序列化协议 通讯协议只要跨语言各方约定清楚，大家安装约定实现即可，而序列化协议则需要较多的考量。\n序列化的协议选择列出一些考虑要点：\n 是否采用具备自我描述能力的序列化方案，如不需要借助一些 schema 或者接口描述文件。\n 是否为语言无关的，包括脚本语言在内。\n 是否压缩比例足够小，满足网络传输场景的要求。\n 是否序列化和反序列化的性能均足够优秀。\n 是否向前/向后兼容，能够处理传输对象的新增属性在服务端和客户端版本不一致的情况。\n 是否支持加密、签名、压缩以及扩展的上下文。\n JSON Over HTTP 首先，说到跨语言，序列化支持，肯定有同学会问，为什么不直接通过 Http的Json来搞定呢？\n虽然得益于JSON和HTTP在各个语言的广泛支持，在多语言场景下改造支持非常便捷，能够低成本的解决网络通讯和序列化的问题。服务发现的过程则可以使用最简单的固定URL（协议+域名+端口+路径）的形式，负载均衡依赖于F5或者LVS等实现。\n但是这个方案的有明显的局限性：\n HTTP 作为无状态的应用层协议，在性能上相比基于传输层协议（TCP）的方案处于劣势。HTTP/1.1后可以通过设置keep-alive使用长连接，可以一定程度上规避建立连接的时间损耗；然而最大的问题是，客户端线程采用了 request-response 的模式，在发送了 request 之后被阻塞，直到拿到 response 之后才能继续发送。这一问题直到 HTTP/2.0 才被解决。\n JSON 是基于明文的序列化，较二进制的序列化方案，其序列化的结果可读性强，但是压缩率和性能仍有差距，这种对于互联网高并发业务场景下，意味着硬件成本的提升。\n 对于网络变化的响应。订阅端处理不够强大。\n Hessian Over BOLT 在否决了上一个方案后，我们继续看，蚂蚁内部，最开始的时候，SOFARPC 还没有支持 Protobuf 作为序列化方式，当时为了跨语言，NodeJs的同学已经在此基础上，用 js 重写了一个 hessian 的版本，完成了序列化。也已经在线上平稳运行。但是当我们要扩展给其他语言的时候，重写 hessian 的成本太高。而且 Java语言提供的接口和参数信息，其他语言也需要自己理解一遍，对应地转换成自己的语言对象。因此该方案在特定场景下是可行的。但不具备推广至其他语言的优势。\nNode的实现版本可以参考：https://github.com/alipay/sofa-rpc-node\nProtobuf Over BOLT Protobuf 基于IDL，本身具备平台无关、跨语言的特性，是一个理想的序列化方案。但是需要先编写proto文件，结构化地描述传输的业务对象，并生成中间代码。\n由于要重点介绍一下这种方案，因此再次回顾一下SOFABolt的协议规范部分，便于后面的解释。\nRequest command protocol for v1 0 1 2 4 6 8 10 12 14 16 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ |proto| type| cmdcode |ver2 | requestId |codec| timeout | classLen | +-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+ |headerLen | contentLen | ... ... | +-----------+-----------+-----------+ + | className + header + content bytes | + + | ... ... | +-----------------------------------------------------------------------------------------------+ codec: code for codec 序列化,hessian 是1,pb 是11,java 是2 Response command protocol for v1 0 1 2 3 4 6 8 10 12 14 16 …","date":1540969200,"description":"本文为《剖析 | SOFARPC 框架》第十二篇，作者鸥波。","dir":"blog/sofa-rpc-cross-language-support/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"28621f1b90e6ce8edf1b3e446fa5be23","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-cross-language-support/","publishdate":"2018-10-31T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-cross-language-support/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之SOFARPC 跨语言支持剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-cross-language-support/","wordcount":3741},{"author":"敏古","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十一篇，作者敏古。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。 SOFARPC：https://github.com/sofastack/sofa-rpc\n 1、前言 在 SOFABoot 环境下，SOFARPC 提供三种方式给开发人员发布和引用 RPC 服务：\n XML 方式（配置）\n Annotation 方式（注解）\n 编程 API 方式（动态）\n 编程 API 方式与Spring 的 ApplicationContextAware 类似。XML的方式依赖于在xml中引入 SOFA 命名空间，利用 Bean 的生命周期管理，进行 Bean 的注入。相比这两种方式，通过 Annotation 方式发布 JVM 服务更加灵活方便，只需要在实现类上加 @SofaService、@SofaRefernce 注解即可进行服务的发布和引用。本文针对 SOFARPC 在注解的支持和使用分原理、源码两部分进行一一介绍。\n2、原理介绍 2.1、注解是什么 注解又称为元数据，可以对代码中添加信息，这是一种形式化的方法，可以在稍后的某个时刻非常方便地使用这些数据。这个时刻可能是编译时，也可能是运行时。\n注解是JDK1.5版本开始引入的一个特性，用于对代码进行说明，可以对包、类、接口、字段、方法参数、局部变量等进行注解。注解的本质就是一个继承了 Annotation 接口的接口。一个注解准确意义上来说，只不过是一种特殊的注释而已，如果没有解析它的代码，它可能连注释都不如。\n一般常用的注解可以分为三类：\n Java自带的标准注解，包括@Override（标明重写某个方法）、@Deprecated（标明某个类或方法过时）和@SuppressWarnings（标明要忽略的警告）。\n 元注解，元注解是用于定义注解的注解。\n 自定义注解，可以根据自己的需求定义注解。\n 2.2、元注解 元注解是用于修饰注解的注解，通常用在注解的定义上。JAVA 中有以下几个元注解：\n @Target：注解的作用目标，也就是指明，你的注解到底是用来修饰方法的？修饰类的？还是用来修饰字段属性的，有以下几种类型： ElementType.TYPE：允许被修饰的注解作用在类、接口和枚举上 ElementType.FIELD：允许作用在属性字段上 ElementType.METHOD：允许作用在方法上 ElementType.PARAMETER：允许作用在方法参数上 ElementType.CONSTRUCTOR：允许作用在构造器上 ElementType.LOCAL_VARIABLE：允许作用在本地局部变量上 ElementType.ANNOTATION_TYPE：允许作用在注解上 ElementType.PACKAGE：允许作用在包上 @Retention：指定了被修饰的注解的生命周期，分以下三种类型： RetentionPolicy.SOURCE：该注解只保留在一个源文件当中，当编译器将源文件编译成class文件时，它不会将源文件中定义的注解保留在class文件中。 RetentionPolicy.CLASS：该注解只保留在一个class文件当中，当加载class文件到内存时，虚拟机会将注解去掉，从而在程序中不能访问。 RetentionPolicy.RUNTIME：该注解在程序运行期间都会存在内存当中。此时，我们可以通过反射来获得定义在某个类上的所有注解。 @Documented：当我们执行 JavaDoc 文档打包时会被保存进 doc 文档，反之将在打包时丢弃。\n @Inherited：解修饰的注解是具有可继承性的，也就说我们的注解修饰了一个类，而该类的子类将自动继承父类的该注解。\n 以 @Override 为例子：\n当编译器检测到某个方法被修饰了 @Override 注解，编译器就会检查当前方法的方法签名是否真正重写了父类的某个方法，也就是比较父类中是否具有一个同样的方法签名。\n@Override 仅被编译器可知，编译器在对 java 文件进行编译成字节码的过程中，一旦检测到某个方法上被修饰了该注解，就会去匹对父类中是否具有一个同样方法签名的函数，否则不能通过编译。\n2.3、注解解析方式 解析一个类或者方法的注解通常有两种形式，一种是编译期直接的扫描，一种是运行期反射。\n2.3.1、编译器的扫描 指的是编译器在对 java 代码编译字节码的过程中会检测到某个类或者方法被一些注解修饰，这时它就会对于这些注解进行某些处理。典型的就是注解 @Override，一旦编译器检测到某个方法被修饰了 @Override 注解，编译器就会检查当前方法的方法签名是否真正重写了父类的某个方法，也就是比较父类中是否具有一个同样的方法签名。\n这一种情况只适用于那些编译器已经熟知的注解类，比如 JDK 内置的几个注解，而你自定义的注解，编译器是不知道你这个注解的作用的，\n2.3.1、运行期反射 首先对虚拟机的几个注解相关的属性表进行介绍，先大体了解注解在字节码文件中是如何存储的。虚拟机规范定义了一系列和注解相关的属性表，也就是说，无论是字段、方法或是类本身，如果被注解修饰了，就可以被写进字节码文件。属性表有以下几种：\n RuntimeVisibleAnnotations：运行时可见的注解 RuntimeInVisibleAnnotations：运行时不可见的注解 RuntimeVisibleParameterAnnotations：运行时可见的方法参数注解 RuntimeInVisibleParameterAnnotations：运行时不可见的方法参数注解 AnnotationDefault：注解类元素的默认值 java.lang.reflect.AnnotatedElement 接口是所有程序元素（Class、Method和Constructor）的父接口，程序通过反射获取了某个类的 AnnotatedElemen t对象之后，利用 Java 的反射机获取程序代码中的注解，然后根据预先设定的处理规则解析处理相关注解以达到主机本身设定的功能目标。\n本质上来说，反射机制就是注解使用的核心，程序可以调用该对象的以下方法来访问 Annotation信息：\n getAnnotation：返回指定的注解 isAnnotationPresent：判定当前元素是否被指定注解修饰 getAnnotations：返回所有的注解 getDeclaredAnnotation：返回本元素的指定注解 getDeclaredAnnotations：返回本元素的所有注解，不包含父类继承而来的 3、源码解析 3.1、 …","date":1540450800,"description":"本文为《剖析 | SOFARPC 框架》第十一篇，作者敏古。","dir":"blog/sofa-rpc-annotation-support/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e68884b2feaf90e26f191de0ef49e945","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-annotation-support/","publishdate":"2018-10-25T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-rpc-annotation-support/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-annotation-support/","wordcount":4359},{"author":"敖小剑","categories":"SOFAMesh","content":" 背景 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，这两个是Istio/Envoy中的一等公民。而基于HTTP/1.1的REST和基于HTTP/2的gRPC，一个是目前社区最主流的通讯协议，一个是未来的主流，google的宠儿，CNCF御用的RPC方案，这两个组成了目前Istio和Envoy（乃至CNCF所有项目）的黄金组合。\n而我们SOFAMesh，在第一时间就遇到和Istio/Envoy不同的情况，我们需要支持REST和gRPC之外的众多协议：\n SOFARPC：这是蚂蚁金服大量使用的RPC协议(已开源) HSF RPC：这是阿里集团内部大量使用的RPC协议(未开源) Dubbo RPC: 这是社区广泛使用的RPC协议(已开源) 其他私有协议：在过去几个月间，我们收到需求，期望在SOFAMesh上运行其他TCP协议，部分是私有协议 为此，我们需要考虑在SOFAMesh和SOFAMosn中增加这些通讯协议的支持，尤其是要可以让我们的客户非常方便的扩展支持各种私有TCP协议：\n实现分析 我们来大体看一下，在SOFAMesh/Istio中要新增一个通讯协议需要有哪些工作：\n protocol decoder：负责解析协议，读取协议字段 protocol encoder：负责生成请求报文，注意通常会有改动，比如修改某些header 在pilot中需要为新协议生成 Virtual Host 等配置，有 inbound 和 outbound 两份，分别下发到Sidecar 在Sidecar中，根据下发的 Virtual Host 等配置，进行请求匹配，以决定请求该转发到何处 备注：实际下发的配置不止 Virtual Host 配置，为了简单起见，我们仅以 Virtual Host 为例做讲解。\n 其中，protocol encoder和protocol decoder是容易理解的，对于新的通讯协议肯定需要有协议编解码层面的工作必须要完成，这块有工作量是很自然的。\n我们来看看第三块的工作量是什么，inbound 和 outbound 的Virtual Host配置示例如下：\noutbound 配置中，注意 domains 字段是各种域名和ClusterIP，而 routes 中，match是通过prefix来匹配。我们结合HTTP/1.1，domains字段是用来和请求的Host header进行域名匹配的，比如 Host: istio-telemetry，这决定了哪些请求是要转发到 istio-telemetry 这个服务的。routes的match用来进行路由匹配的，通过HTTP请求的path进行匹配。\ninbound 配置类似，只是inbound更简单，domains匹配*就可以。\n从上面的例子中可以看到，Istio和Envoy的设计有非常浓重的HTTP协议的味道，各种语义都是和HTTP直接相关。而当我们进行TCP协议的转发时，就需要将请求的协议字段进行映射，映射到HTTP的相应语义。\n比如，最基本的Destination，原始语义是请求的目的地，在前面的文章中我们指出过这是请求转发最关键的字段。在HTTP协议中，通常是通过Host header和Path表示，对于REST而言还有重要的Method字段。\n下面的格式是其他各种协议对这个Destination原始语义的实际实现方式：\n 协议 实现 原始语义 请求的目的地(Destination) HTTP/1.1 Host header，Method，Path HTTP/2 Header帧中的伪header :authority，:path和:method Bolt协议 header map中key为”service”的字段 HSF协议 协议头中的服务接口名和服务方法名 Dubbo协议 data字段（payload）中的path/method 这些通讯协议在下发规则和进行请求匹配时，就需要进行协调：\n 定义好 Virtual Host 配置中的 domains 字段和 route 中的 match 用到的字段在当前通讯协议中的实际语义 在 protocol encoder 中读取请求的协议字段，和上面的字段对应 然后进行请求路由规则匹配（参照HTTP/1.1中的domain和route match的匹配） 而这些都是需要以代码的方式进行实现，以满足新通讯协议的要求。正规的做法，是每次新增一个通讯协议就将上述的工作内容重复一遍。这会直接导致大量的高度类似的重复代码。\nx-protocol的实现 在上述需要在协议扩展时修改的四个内容中，有一块是特别的：生成 Virtual Host 配置的工作是在Pilot中实现的，而其他三个是在Sidecar （Envoy或MOSN）中。考虑到 protocol encoder 和 protocol decoder 的工作是必不可少的，必然会修改Sidecar来增加实现代码，因此简化开发的第一个想法就是：能不能做到不修改Pilot？\n基本思路就是固定好原始语义，避免每个通讯协议都映射一遍。从前面我们列出来的各个协议的映射情况看，对于RPC协议而言，一般目的地信息都是服务名(有些是接口名)+方法名居多，因此可以考虑直接将服务名和方法名固定下来：\n RPC协议在 Virtual Host 配置中就固定为服务名对应 domains 字段，方法名对应 route 中的 match 用到的字段，这样只要修改一次然后各个RPC协议公用此配置，以后就不用再重复修改Pilot。 protocol encoder 在解析通讯协议完成之后，就直接将协议中对应服务名和方法名的字段提取出来，后面的匹配处理过程就可以公用一套通用实现，这样路由匹配这块也可以不用在重复开发。 因此，在x-protocol中，如果需要引入一个新的通讯协议，需要的工作内容只有必不可少的protocol encoder 和 protocol decoder，和实现以下几个接口：\n总结 X-protocol 在支持新通讯协议上的做法并无新奇之处，只是由于需求特殊有众多通讯协议需要支持，在开发时发现大量重复工作，因此我们选择了一条可以让后面更舒服一点的道路。\n目前这个方案在SOFAMesh中采用，我们将进一步检验实际效果，也会和合作的小伙伴时验证，看他们在自行扩展新协议时是否足够理想。这个方案理论上应该可以同样适用于Istio、Envoy体系，随着社区对Istio的接受程度的提高，在Istio上支持各种TCP通讯协议的需求会越来越多，有理由相信Istio后续可能也会出现类似的方案。毕竟，每次都改一大堆类似的东西，不是一个好做法。\n系列文章 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发 ","date":1539500400,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，本文介绍的是TCP协议扩展。","dir":"blog/sofa-mesh-x-protocol-tcp-protocol-extension/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2c2876e9ae6a7a2b374b0d04cc42e6a4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","publishdate":"2018-10-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","summary":"背景 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，这两个是Istio/Envoy中的一等公民。而","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（3）——TCP协议扩展","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","wordcount":2488},{"author":"敖小剑","categories":"SOFAMesh","content":" 前言 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，而我们SOFAMesh，则需要支持以下几个RPC协议：\n SOFARPC：这是蚂蚁金服大量使用的RPC协议（已开源） HSF RPC：这是阿里集团内部大量使用的RPC协议（未开源） Dubbo RPC: 这是社区广泛使用的RPC协议（已开源） 更适合的平衡点：性能和功能 对于服务间通讯解决方案，性能永远是一个值得关注的点。而SOFAMesh在项目启动时就明确要求在性能上要有更高的追求，为此，我们不得不在Istio标准实现之外寻求可以获取更高性能的方式，比如支持各种RPC协议。\n期间有两个发现：\n Istio在处理所有的请求转发如REST/gRPC时，会解码整个请求的header信息，拿到各种数据，提取为Attribute，然后以此为基础，提供各种丰富的功能，典型如Content Based Routing。 而在测试中，我们发现：解码请求协议的header部分，对CPU消耗较大，直接影响性能。 因此，我们有了一个很简单的想法：是不是可以在转发时，不开启部分功能，以此换取转发过程中的更少更快的解码消耗？毕竟，不是每个服务都需要用到Content Based Routing这样的高级特性，大部分服务只使用 Version Based Routing，尤其是使用RPC通讯协议的服务，没有HTTP那么表现力丰富的header，对Content Based Routing的需求要低很多。\n此外，对于部分对性能有极高追求的服务，不开启高级特性而换取更高的性能，也是一种满足性能要求的折中方案。考虑到系统中总存在个别服务对性能非常敏感，我们觉得Service Mesh提供一种性能可以接近直连的方案会是一个有益的补充。为了满足这些特例而不至于因此整体否决Service Mesh方案，我们需要在Service Mesh的大框架下提供一个折中方案。\n请求转发 在我们进一步深入前，我们先来探讨一下实现请求转发的技术细节。\n有一个关键问题：当Envoy/SOFA MOSN这样的代理程序，接收到来自客户端的TCP请求时，需要获得哪些信息，才可以正确的转发请求到上游的服务器端？\n最关键的信息：destination 首先，毫无疑问的，必须拿到destination/目的地，也就是客户端请求必须通过某种方式明确的告之代理该请求的destination，这样代理程序才能根据这个destionation去找到正确的目标服务器，然后才有后续的连接目标服务器和转发请求等操作。\nDestination信息的表述形式可能有：\n1. IP地址\n可能是服务器端实例实际工作的IP地址和端口，也可能是某种转发机制，如Nginx/HAProxy等反向代理的地址或者Kubernetes中的ClusterIP。\n举例：“192.168.1.1:8080”是实际IP地址和端口，“10.2.0.100:80”是ngxin反向代理地址，“172.168.1.105:80”是Kubernetes的ClusterIP。\n2. 目标服务的标识符\n可用于名字查找，如服务名，可能带有各种前缀后缀。然后通过名字查找/服务发现等方式，得到地址列表（通常是IP地址+端口形式）。\n举例：“userservice”是标准服务名， “com.alipay/userservice”是加了域名前缀的服务名， “service.default.svc.cluster.local”是k8s下完整的全限定名。\nDestination信息在请求报文中的携带方式有：\n1. 通过通讯协议传递\n这是最常见的形式，标准做法是通过header头，典型如HTTP/1.1下一般使用 host header，举例如“Host: userservice”。HTTP/2下，类似的使用“:authority” header。\n对于非HTTP协议，通常也会有类似的设计，通过协议中某些字段来承载目标地址信息，只是不同协议中这个字段的名字各有不同。如SOFARPC，HSF等。\n有些通讯协议，可能会将这个信息存放在payload中，比如后面我们会介绍到的dubbo协议，导致需要反序列化payload之后才能拿到这个重要信息。\n2. 通过TCP协议传递\n这是一种非常特殊的方式，通过在TCP option传递，上一节中我们介绍Istio DNS寻址时已经详细介绍过了。\nTCP拆包 如何从请求的通讯协议中获取destination？这涉及到具体通讯协议的解码，其中第一个要解决的问题就是如何在连续的TCP报文中将每个请求内容拆分开，这里就涉及到经典的TCP沾包、拆包问题。\n转发请求时，由于涉及到负载均衡，我们需要将请求发送给多个服务器端实例。因此，有一个非常明确的要求：就是必须以单个请求为单位进行转发。即单个请求必须完整的转发给某台服务器端实例，负载均衡需要以请求为单位，不能将一个请求的多个报文包分别转发到不同的服务器端实例。所以，拆包是请求转发的必备基础。\n由于篇幅和主题限制，我们不在这里展开TCP沾包、拆包的原理。后面针对每个具体的通讯协议进行分析时再具体看各个协议的解决方案。\n多路复用的关键参数：RequestId RequestId用来关联request和对应的response，请求报文中携带一个唯一的id值，应答报文中原值返回，以便在处理response时可以找到对应的request。当然在不同协议中，这个参数的名字可能不同（如streamid等）。\n严格说，RequestId对于请求转发是可选的，也有很多通讯协议不提供支持，比如经典的HTTP1.1就没有支持。但是如果有这个参数，则可以实现多路复用，从而可以大幅度提高TCP连接的使用效率，避免出现大量连接。稍微新一点的通讯协议，基本都会原生支持这个特性，比如SOFARPC、Dubbo、HSF，还有HTTP/2就直接內建了多路复用的支持。\nHTTP/1.1不支持多路复用（http1.1有提过支持幂等方法的pipeline机制但是未能普及），用的是经典的ping-pong模式：在请求发送之后，必须独占当前连接，等待服务器端给出这个请求的应答，然后才能释放连接。因此HTTP/1.1下，并发多个请求就必须采用多连接，为了提升性能通常会使用长连接+连接池的设计。而如果有了requestid和多路复用的支持，客户端和Mesh之间理论上就可以只用一条连接（实践中可能会选择建立多条）来支持并发请求：\n而Mesh与服务器（也可能是对端的Mesh）之间，也同样可以受益于多路复用技术，来自不同客户端而去往同一个目的地的请求可以混杂在同一条连接上发送。通过RequestId的关联，Mesh可以正确将reponse发送到请求来自的客户端。\n由于篇幅和主题限制，我们不在这里展开多路复用的原理。后面针对每个具体的通讯协议进行分析时再具体看各个协议的支持情况。\n请求转发参数总结 上面的分析中，我们可以总结到，对于Sidecar，要正确转发请求：\n 必须获取到destination信息，得到转发的目的地，才能进行服务发现类的寻址 必须要能够正确的拆包，然后以请求为单位进行转发，这是负载均衡的基 …","date":1539154800,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，本文介绍的是快速解码转发方案。","dir":"blog/sofa-mesh-x-protocol-rapid-decode-forward/","fuzzywordcount":6900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"37ad5c3f997c173a4ceb60cc9dfd0532","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","summary":"前言 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，而我们SOFAMesh，则需要支持以下几个RP","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","wordcount":6856},{"author":"米麒麟","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第九篇，作者米麒麟，目前就职于陆金所。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕，文末提供了已完成的文章目录。\n 前言 众所周知，在微服务架构下面，当应用需要进行新功能升级发布，或者异常关闭重启的时候，我们会对应用的进程进行关闭，而在关闭之前，我们希望做一些诸如关闭数据库连接，等待处理任务完成等操作，这个就涉及到我们本文中的优雅关闭功能。假如应用没有支持优雅停机，则会带来譬如数据丢失，交易中断、文件损坏以及服务未下线等情况。\n微服务的优雅停机需要遵循\u0026amp;rdquo;注销发布服务 → 通知注销服务 → 更新服务清单 → 开启请求屏蔽 → 调用销毁业务服务 → 检查所有请求是否完成 → 超时强制停机\u0026amp;rdquo;应用服务停机流程。\nSOFARPC 提供服务端/客户端优雅关闭功能特性，用来解决 kill PID，应用意外自动退出譬如 System.exit() 退出 JVM，使用脚本或命令方式停止应用等使用场景，避免服务版本迭代上线人工干预的工作量，提高微服务架构的服务高可靠性。\n本文将从进程的优雅关闭，SOFARPC 应用服务优雅关闭流程，Netty 的优雅停机等方面出发详细剖析 。\n进程优雅关闭 Kill 结束进程 在 Linux上，kill 命令发送指定的信号到相应进程，不指定信号则默认发送 SIGTERM(15) 终止指定进程。如果无法终止，可以发送 SIGKILL(9) 来强制结束进程。kill 命令信号共有64个信号值，其中常用的是：\n2(SIGINT：中断，Ctrl+C)。\n15(SIGTERM：终止，默认值)。\n9(SIGKILL：强制终止)。\n这里我们重点说一下15和9的情况。\nkill PID/kill -15 PID 命令系统发送 SIGTERM 进程信号给响应的应用程序，当应用程序接收到 SIGTERM 信号，可以进行释放相应资源后再停止，此时程序可能仍然继续运行。\n而kill -9 PID 命令没有给进程遗留善后处理的条件。应用程序将会被直接终止。\n对微服务应用而言其效果等同于突然断电，强行终止可能会导致如下几方面问题：\n 缓存数据尚未持久化到磁盘，导致数据丢失；\n 文件写操作正在进行未更新完成，突然退出进程导致文件损坏；\n 线程消息队列尚有接收到的请求消息，未能及时处理，导致请求消息丢失；\n 数据库事务提交，服务端提供给客户端请求响应，消息尚在通信线程发送队列，进程强制退出导致客户端无法接收到响应，此时发起超时重试带来重复更新。\n 所以支持优雅关闭的前提是关闭的时候，不能被直接 通过发送信号为9的 Kill 来强制结束。当然，其实我们也可以对外统一暴露应用程序管理的 API 来进行控制。本文暂时不做讨论。\nJava 优雅关闭 当应用程序收到信号为15的关闭命令时，可以进行相应的响应，Java 程序的优雅停机通常通过注册 JDK 的 ShutdownHook 来实现，当应用系统接收到退出指令，首先 JVM 标记系统当前处于退出状态，不再接收新的消息，然后逐步处理推积的消息，接着调用资源回收接口进行资源销毁，例如内存清理、对象销毁等，最后各线程退出业务逻辑执行。\n优雅停机需要超时控制机制，即到达超时时间仍然尚未完成退出前资源回收等操作，则通过停机脚本调用kill-9 PID命令强制退出进程。\n其中 JVM 优雅关闭的流程主要的阶段如下图所示：\n如图所示，Java进程优雅退出流程包括如下五个步骤：\n 应用进程启动，初始化 Signal 实例；\n 根据操作系统类型，获取指定进程信号；\n 实现 SignalHandler 接口，实例化并注册到 Signal，当 Java 进程接收到譬如 kill -12 或者 Ctrl+C 命令信号回调其 handle() 方法；\n SignalHandler 的 handle 回调接口初始化 ShutdownHook 线程，并将其注册到 Runtime 的 ShutdownHook。\n Java 进程接收到终止进程信号，调用 Runtime 的exit() 方法退出 JVM 虚拟机，自动检测用户是否注册ShutdownHook 任务，如果有则触发 ShutdownHook 线程执行自定义资源释放等操作。\n SOFARPC 优雅关闭 在进程可以进行优雅关闭后，SOFARPC 如何实现优雅关闭呢？首先 SOFARPC 对于所有可以被优雅关闭的资源设计com.alipay.sofa.rpc.base.Destroyable接口，通过向 JVM 的 ShutdownHook 注册来对这些可被销毁的资源进行优雅关闭，支持销毁前和销毁后操作。\n这里包括两部分：\n 作为服务端注册 JDK 的 ShutdownHook 执行取消服务注册、关闭服务端口等动作实现；\n 作为客户端通过实现 DestroyHook 接口逐步处理正在调用的请求关闭服务调用。\n 总体设计 运行时上下文注册 JDK 的 ShutdownHook 执行销毁 SOFARPC 运行相关环境实现类似发布平台/用户执行kill PID 优雅停机。运行时上下文 RpcRuntimeContext 静态初始化块注册 ShutdownHook 函数：\nstatic { ... // 增加jvm关闭事件 if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } } 注册本身很简单，重要的是 destroy 方法实际上做的事情非常多。按照先后顺序，大致包含如下几个部分。\nRpcRuntimeContext 销毁服务优雅关闭完整流程：\n 设置 RPC 框架运行状态修改为正在关闭，表示当前线程不再处理 RPC 服务请求；\n 遍历运行时上下文关闭资源的销毁钩子，进行注册销毁器清理资源前期准备工作；\n 获取发布的服务配置反注册服务提供者，向指定注册中心批量执行取消服务注册；\n 检查当前服务端连接和队列任务，先把队列任务处理完毕，再缓慢关闭启动端口；\n 关闭发布的服务，到注册中心取消服务发布，取消将处理器注册到服务端，清除服务发布配 …","date":1539154800,"description":"本文为《剖析 | SOFARPC 框架》第九篇，作者米麒麟，目前就职于陆金所。","dir":"blog/sofa-rpc-graceful-exit/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6a1f6847a5ecf97e90a3a06c36f39246","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-graceful-exit/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-graceful-exit/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 优雅关闭剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-graceful-exit/","wordcount":3972},{"author":"明不二","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十篇，作者明不二，就职于华为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 RPC 框架需要创造一种调用远程服务如同调用本地般的体验，因此在实现一个基于 RPC 框架的微服务架构的系统时，服务消费者（客户端）往往只需要知道服务端提供了哪些接口和方法，并不需要知道服务具体由哪些 IP 在提供。RPC 框架本身的服务发现和路由寻址功能解决了如何知道目标地址的问题，该过程对于 RPC 客户端调用方来说应该是完全透明的。\n在这个过程中，RPC 框架需要接入注册中心来完成服务发现和路由寻址的功能。同时，在应用大规模请求时，微服务系统还需要对请求服务集群化，同时通过负载均衡来达到降低访问压力的效果。\n本文我们会先介绍一下注册中心，然后介绍一下 SOFRPC 中的几种路由，最后会介绍一下负载均衡的几种比较。\n注册中心支持 首先我们简要介绍一下注册中心的原理。\n服务端推送地址给注册中心，注册中心将地址进行合并后，推送给客户端。\n其中，注册中心的场景依赖于各类注册中心的实现。在这里，SOFARPC 提供了注册中心的抽象类 Registry，该抽象类提供了注册中心的配置、启动、注册、反注册、订阅等方法。客户端在接入过程中，可以通过配置来激活 Zookeeper、Consul、local 等注册中心注册进启动类中，当请求到来时，可以通过注册中心进行相应的路由。\n注册中心的抽象类如下：\n在这个接口的基础上，目前内置实现了几种注册中心，包括即将合并的。\nLocal注册中心(Local) Local 注册中心是 SOFARPC 自己实现的一个本地注册中心，该注册中心的实现主要由类 LocalRegistry提供，可以调用其 register(ProviderConfig config) 方法实现服务的注册，主要是文件的读写。\n实现原理很简单，通过在本地注册文件来保存服务的发布和订阅信息。\nZookeeper注册中心(Zookeeper) Zookeeper 接入 SOFARPC 的实现类为 ZookeeperRegistry。目前是 SOFARPC 中默认的注册中心实现。也是大多数情况下，可以方便使用的。\nZookeeper 是一个分布式协调服务，用于维护配置信息、命名、提供分布式同步功能以及提供组服务等。Zookeeper 提供了服务注册与发现的解决方案，提供了简单的 API，可以让集成者简洁调用。\n当要发布一个 SOFARPC 服务时，首先需要在 zookeeper 中注册服务提供者的相关信息，包括：该服务接口隶属于哪个系统、服务的 IP 以及端口号、服务的请求 URL 和服务的权重等等。zookeeper 在这个过程中，注意负责对 SOFARPC 中的服务信息进行中心存储，同时负责把服务注册信息的更新及时通知到服务消费者。\n作为服务调用者，SOFARPC 调用端在调用时，若走的路由链路中有注册中心，则会从注册中心中获取到服务注册的相关信息，然后在调用时会根据负载均衡策略来发送请求。\nConsul注册中心(Consul) Consul 注册中心与 SOFARPC 之间的对接主要依赖于 ConsulRegistry类。\n该注册中心在功能表现上与 zookeeper 看起来一致。对比起 Zookeeper 来，Consul 支持多数据中心，同时支持 http 和 dns 等接口，有着多语言的能力。\n其他注册中心 目前已经在开发中的有 Nacos，SOFAMesh 等。也可以根据自己的场景，进行方便的扩展。\n路由设计 路由原理和设计 在阅读本部分之前，请大家注意：路由是为了选中一组地址。\nSOFARPC 通过对各类注册中心的支持，实现了服务发现、路由寻址的功能。访问客户端时，请求的路由可以由以下一些实现类实现：DirectUrlRouter、RegistryRouter、CustomRouter，上述三个路由实现类分别对应了直接地址路由（不需要经过注册中心直接路由直连到某个地址）、注册中心路由、以及客户自定义路由等。路由从 AddressHolder 获取到地址，同时通过各种负载均衡算法进行负载均衡，请求到相应的系统接口。\n首先我们看一下整个路由寻址过程的阶段。\n这 SOFARPC 中，路由可以分为地址直连路由、注册中心路由以及客户定制化路由。这以上三个路由均扩展了 Router 抽象类。服务路由的抽象类代码如下：\n这里的核心代码是 route 这个方法，将本次请求的信息，和服务列表进行计算。当客户端请求到达 Router 时，会根据请求的参数信息从 Router 和连接管理器中获取请求地址，通过调用 route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) 方法达到路由寻址的目的。\n其中，路由并不是一个非此即彼的过程，这些可选的路由是由用户和系统的配置，被构造成一个路由链来执行的。这样。就可以有一些兜底的逻辑，如指定了 IP 地址，那我们就直接路由到这个地址，如果没有，就进行注册中心的路由等等。\n直连(DirectUrlRouter) 直接路由是比较简单的，因为有专门的配置，所以地址列表这些都是可以很方便地进行识别，在客户端配置时，可通过如下方式配置：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); 直接地址路由扩展了 Router 抽象类的实现，在重写的 route 方法中，直接获取配置好的直接路由地址。当请求到来时，直接从地址管理列表中，拿到对应的地址，就实现了直接地址路由的功能。\n注册中心(RegistryRouter) 注册中心路由同样扩展了 Router 抽象方法，这个 Router是大多数情况下使用最多的路由，主要是从本应用使用的注册中心中获取对应的地址，并进行路由寻址等。后面我们会介绍目前注册中心的几个内置实现。\n自定义(CustomRouter) 客户定制化路由可以配置客户自己所定制的路由实现，可以参考直接地址路由或者注册中心路由的实现，扩展 Router 类即可。\n这里的使用场景：\n一种是对于某些用户来说，在注册中心的场景下，用户认为所有的地址并不是等价的。会对地址进行人为拆分，使用方保存了自己的的所有服务提供方地址（或者是通过某种方法查询），然后重写路由定制逻辑，通过方法级别进行地址的选择。\n另一 …","date":1539154800,"description":"本文为《剖析 | SOFARPC 框架》第十篇，作者明不二，就职于华为。","dir":"blog/sofa-rpc-routing-implementation/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dc2f04fd097731619e17f7da6a24ae6a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-routing-implementation/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-routing-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 路由实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-routing-implementation/","wordcount":3769},{"author":"敖小剑","categories":"SOFAMesh","content":" 本文是SOFAMesh中的多协议通用解决方案x-protocol介绍系列文章之一。\n 前言 在2018年上半年，蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决方案，在6月底对外公布了 SOFAMesh，详情请见之前的文章: 大规模微服务架构下的Service Mesh探索之路 。\n在 SOFAMesh 的开发过程中，针对遇到的实际问题，我们给出了一套名为 x-protocol 的解决方案，定位是云原生、高性能、低侵入性的通用 Service Mesh 落地方案，依托 Kubernetes 基座，利用其原生的服务注册和服务发现机制，支持各种私有 RPC 协议低成本、易扩展的接入，快速享受 Service Mesh 所带来的红利。\n具体解决的问题包括：\n 多通讯协议支持问题，减少开发工作量，简单快捷的接入新协议 尽量提升性能，提供更灵活的性能与功能的平衡点选择，满足特定高性能场景 兼容现有SOA体系，提供通过接口进行访问的方式，实现不修改业务代码也能顺利接入 Service Mesh 支持单进程多服务的传统SOA程序，可以在微服务改造之前，先受益于 Service Mesh 带来的强大功能 在本系列文章中，我们将对此进行详细的讲解，首先是“DNS通用寻址方案”。\n背景和需求 SOA的服务模型 在SOFAMesh计划支持的RPC框架中，SOFARPC、HSF、Dubbo都是一脉相承的SOA体系，也都支持经典的SOA服务模型，通常称为”单进程多服务”，或者叫做”单进程多接口”。（备注：由于服务一词使用过于频繁，下文都统一称为接口以便区分）\nSOA标准的服务注册，服务发现和调用流程如下：\n 在单个SOA应用进程内，存在多个接口 服务注册时，以接口为单位进行多次独立的服务注册 当客户端进行调用时，按照接口进行服务发现，然后发起调用 当我们试图将这些SOA架构的应用搬迁到ServiceMesh时，就会遇到服务模型的问题：微服务是单服务模型，也就是一个进程里面只承载一个服务。以Kubernetes的服务注册为例，在单进程单服务的模型下，服务名和应用名可以视为一体，Kubernetes的自动服务注册会将应用名作为服务注册的标示。\n这就直接导致了SOA模型和微服务模型的不匹配问题：\n SOA以接口为单位做服务注册和服务发现，而微服务下是服务名 SOA是”单进程多接口”，而微服务是”单进程单服务” 一步接一步的需求 先上车后补票 最理想的做法当然是先进行微服务改造，实现微服务拆分。但是考虑到现有应用数量众多，我们可能更愿意在大规模微服务改造之前，先想办法让这些应用可以运行在ServiceMesh下，提前受益于Service Mesh带来的强大功能。因此，我们需要找到一个合适的方案，让ServiceMesh支持没有做微服务改造依然是”单进程多接口”形式的传统SOA应用，所谓”先上车后补票”。\n 不修改代码 考虑到原有的SOA应用，相互之间错综复杂的调用关系，最好不要修改代码，即保持客户端依然通过接口名来访问的方式。当然，SOA架构的客户端SDK可能要进行改动，将原有的通过接口名进行服务发现再自行负载均衡进行远程调用的方式，精简为标准的Servicemesh调用（即走Sidecar），因此修改SDK依赖包和重新打包应用是不可避免。\n 支持带特殊字符的接口名 Kubernetes的服务注册，Service名是不能携带”.“号的。而SOA架构下，接口名有时出于管理方便，有可能是加了域名前缀，如”com.alipay.demo.interface-2”。为了实现不修改原有代码，就只能想办法支持这种带特殊字符的接口名。\n参考Kubernetes和Istio 在进一步讨论解决方案之前，我们先来看一下kubernetes和Istio中的标准请求寻址方式。\n 备注：过程稍显复杂，涉及到Kubernetes/Istio的一些底层细节。但是了解这个过程对后续的理解非常重要，也可以帮助大家了解Kubernetes和Kubernetes的工作原理，强烈推荐阅读。\n Kubernetes下的DNS寻址方式 在Kubernetes下，如图所示，假定我们部署了一个名为userservice的应用，有三个实例，分别在三个pod中。则应用部署之后，Kubernetes会为这个应用分配ClusterIP和域名，并在DNS中生成一条DNS记录，将域名映射到ClusterIP：\n当部署在Kubernetes下的某个充当客户端的应用发起请求时，如图中的HTTP GET请求，目标URL地址为 http://userservice/id/1000221。请求的寻址方式和过程如下：\n 首先进行域名解析，分别尝试解析”userservice”/“userservie.default.svc.cluster.local”等域名，得到ClusterIP 然后客户端发出请求的报文，目标地址为ClusterIP，源地址为当前客户端所在的pod IP（简单起见，端口先忽略） 请求报文随即被kube-proxy拦截，kube-proxy根据ClusterIP，拿到ClusterIP对应的多个实际服务实例所在的pod ip，取其中一个，修改目标地址为这个pod IP 请求报文最终就被发送到服务实例所在的pod IP 应答回来的方式类似，userservice发出的应答报文会被kube-proxy拦截并修改为发送到客户端所在的pod IP。\n我们详细看一下请求和应答全称的四个请求包的具体内容（简单起见继续忽略端口）：\n重点关注请求和应答报文的源地址和目标地址：\n 客户端发出的请求，为”客户端到ClusterIP” kube-proxy拦截到请求后，将请求修改为”客户端到服务器端” 服务器端收到请求时，表现为”客户端到服务器端”，ClusterIP被kube-proxy屏蔽 服务器端发送应答，因为收到的请求看似来自客户端，因此应答报文为”服务器端到客户端” 应答报文被kube-proxy拦截，将应答修改为”ClusterIP到服务器端” 客户端收到应答，表现为”ClusterIP到服务器端”，服务器端IP被kube-proxy屏蔽 kube-proxy在客户端和服务器端之间拦截并修改请求和应答的报文，联通两者，但各自屏蔽了一些信息：\n 在客户端看来它是在和ClusterIP交互，userservice的具体服务器端实例对客户端是无感知的 在服务器端看来，客户端是直接在和它交互，ClusterIP的存在对服务器端是无感知的 更深入一步，看kube-proxy在两个拦截和修改报文中的逻辑处理关系，即kube-proxy是如何在收到应答时正确的找回原有的ClusterIP：\n 在拦截并修改请求报文之后，kube-proxy会保存报文修改的5元组对应关系（5元组指源IP地址，源端口，协议，目的地IP地址，目的地端口） 在收到应答报文后，根据应答报文中的5元组，在保存的5元组对应关系中，找到对应信息，得到原有的ClusterIP和端口，然后修改应答报文 总结，通过上述Kubernetes下的寻址方式，客户端只需发送带简单寻址信息的请求（ …","date":1538982000,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，首先介绍的是DNS通用寻址方案。","dir":"blog/sofa-mesh-x-protocol-common-address-solution/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6429061afc56c5832c17b541943498e6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","publishdate":"2018-10-08T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","summary":"本文是SOFAMesh中的多协议通用解决方案x-protocol介绍系列文章之一。 前言 在2018年上半年，蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","wordcount":5813},{"author":"水寒","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第八篇，作者水寒，目前就职于网易。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕，文末提供了已完成的文章目录。\n 前言 在本系列之前的文章中，我们已经介绍了同步，异步，泛化调用等，也介绍了链路追踪的能力，本篇，我们将介绍一下 SOFARPC 中另一种内置的数据透传的能力。会依次介绍，数据透传的概念， SOFARPC 的设计原理，以及各种不同调用方式下的透传使用和详细说明，最后， 还会比较一下和 SOFATracer 的区别。欢迎大家与我们讨论交流。\n数据透传介绍 首先，我们介绍一下数据透传的概念，我们知道，在 RPC调用中，数据的传递，是通过接口方法参数来传递的，需要接口方定义好一些参数允许传递才可以，在一些场景下，我们希望，能够更通用的传递一些参数，比如一些标识性的信息。业务方可能希望，在每一次调用请求中都能够传递一些自定义的信息到下游。甚至也希望下游能够将一些数据传递回来。\n而数据透传功能，就是指数据不需要以作为方法参数的形式在调用链路中进行传递，而是直接存储到调用上下文中，之后通过 RPC 的内置对象，进行传递，调用双端可从上下文中获取数据而不需要去关注数据的传输过程。\nSOFARPC 提供的数据透传支持请求数据透传（客户端向服务端）和响应数据透传（服务端向客户端）。\nSOFARPC 设计原理 这里主要是介绍一下，实现的核心原理，更加具体的每种调用方式的透传，在后文中都会详细介绍。\n 用户通过 SOFARPC 提供的 API 进行数据传递设置\n SOFARPC 在调用传输前，将透传的数据进行打包获取\n 进行正常的序列化和反序列化\n SOFARPC 在反序列化时将用户设置的透传数据写回 Context\n 服务端用户即可进行获取使用\n 不同调用方式的透传 我们知道，SOFARPC 目前支持四种调用模式，如果没有阅读过之前文章的同学，可以阅读一下 SOFARPC 同步异步实现剖析，请求透传数据的原理都是一样的，服务端设置响应透传数据的原理也是一样的，只是客户端获取响应透传数据的方式有所不同（后三种模式只介绍客户端获取响应透传数据的原理）。因此我们会介绍下不同调用方式的透传细节，并介绍其使用方式，方便大家理解。以下为了方便说明，我们会使用如下的接口示例：\n接口服务 public interface HelloService { String sayHello(String string); } 服务实现 public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string) { // 获取请求透传数据并打印 System.out.println(\u0026amp;quot;service receive reqBag -\u0026amp;gt; \u0026amp;quot; + RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;req_bag\u0026amp;quot;)); // 设置响应透传数据到当前线程的上下文中 RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;resp_bag\u0026amp;quot;, \u0026amp;quot;s2c\u0026amp;quot;); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; ！\u0026amp;quot;; } } 后续的所有调用模式都使用HelloServiceImpl这个服务实现。(示例代码在 SOFARPC 的 测试 case 中都要对应的示例，大家可以对应阅读。)\n对用户可见的操作 API 只有一个就是 RpcInvokeContext，在 SOFABoot 和 SOFARPC 下都适用，当然如果你了解 SOFARPC 的 Filter 机制，也可以通过扩展这个来实现。\nsync 调用下的透传 使用示例 原理剖析 请求透传数据 客户端首先在 main 线程（图中的user thread）中设置请求透传数据到其调用上下文RpcInvokeContext.requestBaggage属性中，之后在调用过程中从requestBaggage中取出请求透传数据并设置到SofaRequest.requestProps属性中； 服务端接收到请求SofaRequest对象后，在其调用链中的 ProviderBaggageFilter#invoke 方法中会先从SofaRequest.requestProps中取出请求透传数据并设置到当前服务端线程的调用上下文RpcInvokeContext.requestBaggage属性中，最后业务代码就可以从调用上下文中获取请求透传数据了。 响应透传数据 服务端设置响应透传数据到其调用上下文RpcInvokeContext.responseBaggage属性中，之后在ProviderBaggageFilter#invoke 方法中先从responseBaggage中取出响应透传数据并设置到SofaResponse.responseProps属性中； 客户端main线程被唤醒后，先从SofaResponse.responseProps中获取响应透传数据，之后将响应透传数据设置到其调用上下文RpcInvokeContext.responseBaggage中，最后业务代码就可以从调用上下文中获取响应透传数据了。 oneway 调用下的透传 使用示例 原理剖析 在 oneway 模式下，客户端不接受服务端响应，也不会获取响应透传数据。\nfuture 调用下的透传 使用示例 原理剖析 客户端获取响应透传数据 future 模式在 SOFARPC 内部会被转化为 callback 的方式进行调用，在 callback 对象中会存储main线程的调用上下文；当客户端接收到响应时，会执行该 callback 对象的回调函数，在其回调函数中，对于响应透传数据，会做如下操作：\n 从SofaResponse.responseProps中获取响应透传数据\n 从 callback 对象中获取 main 线程的调用上下文\n 设置响应透传数据到 main 线程的调用上下文\n 将 main 线程上下文拷贝到当前的回调线程中\n 实际上，第三步与第四步在 SOFARPC 源码中顺序相反，本文这样解读是为了更容易理解。这样无论是 future 模式（从 main 线程的调用上下文获取响应透传数据）还是 callback 模式（从回调线程的调用上下文获取响应透传数据），都可以顺利的获取到响应透传数据。\ncallback 调用下的透传 使用示例 原理剖析 与 future 模式原理一样，只是最终业务代码中是从回调线程而不是main …","date":1538550000,"description":"本文为《剖析 | SOFARPC 框架》第八篇，作者水寒，目前就职于网易。","dir":"blog/sofa-rpc-data-transmission/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a26f5f1db99edadf48c406492ccdcaf8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-data-transmission/","publishdate":"2018-10-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-rpc-data-transmission/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 数据透传剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-data-transmission/","wordcount":2528},{"author":"莫那·鲁道","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第七篇，作者莫那·鲁道 ，来自 E签宝。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 我们知道，在 RPC 调用中，客户端需要加载服务端提供的接口定义类，但是，很多情况下，这个并不总是可行的，于是，衍生了泛化调用的需求，一个成熟的，功能完善的 RPC 框架一般都会支持泛化调用，那么什么是泛化调用呢？SOFA RPC 又是如何支持泛化调用的？同时又是如何实现的？ 和其他的 RPC 泛化调用又有何不同？有何优势？我们将在本文一一解答这些问题。\n泛化调用介绍 当客户端因为某种原因无法得到服务提供方的接口 jar 包时，或者是客户端是一个比较通用的系统，并不想依赖每个服务提供方提供的 facade接口，但是又需要进行调用，那么此时就需要进行泛化调用。\n例如： 1. 当分布式系统由多个语言开发，假设是 Node Js ，同时 Node Js 需要调用 Java 语言的 RPC 服务，那么，我们就需要在两者之间架设适配层，让适配层处理 Node Js 的请求后再转发给 Java 的 RPC 服务。 2. 一些中间系统的功能，比如某些内部网关，需要以一个统一的方式实现对其他下游系统的调用（非 SPI的情况），逐个依赖下游的包显然是不可能的。 3. 一些流量回放类的线上系统，可以将数据采集拦截，之后，通过泛化调用回放，而不需要依赖全站的应用。\n那么这种情况下，肯定不能包含所有接口的 jar 文件，否则就太臃肿了。实际上也是不现实的，总不能每增加一个服务端，就增加一个 jar 包依赖，然后应用进行发布重启。\n这个时候就可以使用泛化调用，将相应的请求包装成泛化调用，就能够实现不依赖接口 jar 包，多语言调用 RPC 服务，避免重复开发。\nSOFA RPC 的泛化调用使用 SOFA RPC 的官方文档十分详细，在官方 wiki 泛化调用 中，已有详细介绍。同时，在源码中的 example 模块中，也有现成的 demo 可以跑起来，读者可以自己 clone 源码阅读，这里我们简要说明一下使用方式，以便大家有一个直观的了解。\n接口定义 总的来说，泛化调用有 2 个 API，包含 5 个方法，其中， 2 个方法已经废弃，也就是说，有 3 个主要方法。分别是：\n/** * 泛化调用 * @return 正常类型（不能是GenericObject类型） */ Object $invoke(String methodName, String[] argTypes, Object[] args); /** * 支持参数类型无法在类加载器加载情况的泛化调用 * @return 除了JDK等内置类型，其它对象是GenericObject类型 */ Object $genericInvoke(String methodName, String[] argTypes, Object[] args); /** * 支持参数类型无法在类加载器加载情况的泛化调用 * @return 返回指定的T类型返回对象 */ \u0026amp;lt;T\u0026amp;gt; T $genericInvoke(String methodName, String[] argTypes, Object[] args, Class\u0026amp;lt;T\u0026amp;gt; clazz); \\$invoke 该方法使用场景：用户知道参数类型和返回值类型，那么就可以使用该方法。 \\$genericInvoke 该方法是个重载方法，重载一的使用场景是：如果你的应用不知道接口的参数类型和返回值类型，这个时候，你就需要使用 GenericObject 类，来包装返回值和参数。 \\$genericInvoke 重载二的使用场景是：如果应用不知道接口参数类型，但是知道接口返回值的类型，那么就不需要使用 GenericObject 作为返回值了。 基本上，已经覆盖了常用的集中场景，可以说功能相当全面。\n泛化使用 由于篇幅有限，这里就不贴使用 demo 了，感兴趣的可以通过链接查看官方的 demo 或者源码，包含 SOFARPC 的 API 使用方式和 SOFABoot 的使用方式：\n demo wiki 地址：用户手册-\u0026amp;gt;基本特性-\u0026amp;gt;泛化调用 源码地址：示例源码 SOFARPC 泛化调用的设计与实现 接下来我们重点来介绍 SOFARPC 是如何实现泛化调用的。\n框架调用设计 简单来说，泛化调用的关键就是对象表示和序列化，SOFARPC 提供了 GenericObject 等对象来表示参数对象或者返回值对象，而将 GenericObject 对象序列化成目标对象，或者将返回值反序列化成 GenericObject 对象，是 SOFARPC 实现泛化的关键。\n这里我们先来看一下 SOFARPC 泛化调用的流程图，有助于后面理解泛化实现。\n我们来说一下这个图： 1. 泛化 API 调用时，会加载泛化过滤器，作用是做一些参数转换，同时设置序列化工厂类型。 2. SOFARPC 在使用 SOFABolt 进行网络调用前，会创建 context 上下文并传递给 SOFABolt，上下文中包含着序列化工厂类型信息，这个信息将决定使用何种序列化器，同时这个上下文将流转于整个调用期间。 3. 在 SOFABolt 正式发送数据之前，会将 GenericObject 对象序列化成普通对象的字节流，这样，服务提供方就不必关心是否为泛化调用，从图中可见，提供方不用对泛化调用做任何改变 —— 这是 SOFARPC 泛化区别于其他 RPC 泛化的关键。 4. 当提供方成功接收请求后，使用普通序列化器即可反序列化数据，只需要正常调用并返回即可。 5. 当消费者的 SOFABolt 接收到响应数据后，便根据 context 的序列化类型，对返回值做反序列化，即将普通的字节流反序列化成 GenericObject 对象 —— 因为客户端有可能不知道返回值的 Class 类型。 6. 最终，泛化 API 即可得到 GenericObject 类型的返回值。\n从上面的流程可以看出，序列化器在泛化调用中，占了极大的篇幅和作用。而 SOFARPC 针对泛化调用，对 hessian3 进行了改造，使其支持泛化调用所需要的序列化功能。SOFA-Hessian的改动可以参考这里。\nHessian 泛化实现 SOFA-Hessian 在 hessian 的包中加入了 com.alipay.hessian.generic 包，此包的作用就是处理泛化调用，重写的关键是实现或继承 SerializerFactory 类和 Serializer、Deserializer 等接口。在这里，设计了一下几个类，来描述对应的类型信息，同时实现这几个类的序列化和反序列化。对应关系如下： …","date":1537945200,"description":" 本文为《剖析 | SOFARPC 框架》第七篇，作者莫那·鲁道 ，来自 E签宝。","dir":"blog/sofa-rpc-generalized-call-implementation/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"de327dfe502c28ef0f926f17b29a6c80","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","publishdate":"2018-09-26T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 泛化调用实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","wordcount":3226},{"author":"畅为","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第六篇，作者畅为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 一. 前言 对于金融业务而言每个环节都涉及到大量的资金操作，若因为网络、硬件等原因导致系统不稳定性，不仅影响用户体验，更重要的是可能会引起资损问题，因此系统可用性至关重要。在微服务分布式架构中提高系统可用性的常见方案是 集群（冗余）。 集群方式将一个服务部署在多个机器上，通过硬负载或软负载实现服务的均衡负载，虽然可以有效避免单点问题，但是仍然避免不了某些场景单机故障引起服务调用失败的问题。\nSOFARPC 提供了自动单机故障剔除能力，能够自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复，提高系统可用性。本文将从以下几个方面进行剖析：\n 单机故障和服务降级介绍\n SOFARPC 单机故障剔除原理\n 二. 单机故障和服务降级 在分布式架构中常见可用性方案的是 集群（冗余），即将一个服务部署在多个机器上，通过硬负载或软负载实现服务的均衡负载。硬件负载因每次请求都需要经过硬件负载，承担所有的访问压力，当集群规模增加、流量增多，硬件负载可能因无法支撑所有流量而导致系统不可用。\n软负载则提供注册中心，并将负载能力转移到服务调用方( Consumer )，注册中心只有在 Consumer 首次订阅或服务发生变化时才会发生交互，避免了并发访问下的单点问题。下图是基于软负载的服务调用：\n虽然软负载可以避免单点问题，但可能存在以下场景导致服务不可用：\n Provider 出现单点故障或宕机，与 Consumer 的长连接已断开，但注册中心尚未摘除或未及时通知Consumer。\n Consumer 和 Provider的长连接还在，注册中心未下发摘除，但服务器端由于某些原因，例如长时间的 Full GC, 硬件故障（后文中为避免重复，统一描述为机器假死）等场景，处于假死状态。\n 这两种场景都是服务端出现故障，但由于长连接还保留等原因注册中心未摘除服务，导致服务调用失败。针对第一种情况 Consumer 不应调用出现故障的 Provider，否则会引起部分服务不可用；针对第二种情况，这个 Consumer 应该不调用或少调用该 Provider，可以通过权重的方式来进行控制。目前 SOFARPC 5.3.0 以上的版本支持 RPC 单机故障剔除能力。SOFARPC 通过服务权重控制方式来减少异常服务的调用，将更多流量打到正常服务机器上，提高服务可用性。\n2.1 SOFARPC故障剔除 vs 注册中心故障剔除 SOFARPC 的故障剔除与注册中心故障服务剔除不同，它们从不同的维度来完成故障剔除提高服务可用性。主要两方面的区别：\n 故障剔除的时机\n 故障剔除的细粒度\n 故障剔除的时机 SOFARPC 的故障剔除与注册中心故障服务剔除不同，它们从不同的维度来完成故障剔除提高服务可用性。注册中心服务管理关注 Provider 与注册中心的心跳或长连接。如果 Provider 出现心跳异常或长连接不存在，则及时将服务从注册中心剔除，并告知 Consumer 移除本地缓存的故障 Provider 信息。Comsumer 在负载均衡选择时则不考虑被剔除的 Provider，如图所示：\n而 SOFARPC 单机故障剔除针对的场景不同，针对的是注册中心还未剔除的服务，这些服务与 Consumer 仍然保持长连接，但由于机器假死，不能提供正常服务。 如下图所示：\n故障剔除的细粒度 注册中心剔除的是粒度是针对单机上的某个服务进程，属于进程级别。一旦这个进程和注册中心断开连接或心跳无感应，则将其从注册中心剔除。\nSOFARPC 故障剔除并控制精度会更精细一些，会细致到进程对外暴露的服务，如部署在某个机器上的交易系统对外提供的交易查询服务 TransQueryService. 管理的维度是 IP + 服务， 这里的服务特指进程中的服务接口。\n2.2 服务权重降级 vs 服务降级 服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。这里的降级级别是整个系统服务，而不是针对接口级别。\nSOFARPC 的服务降级，是指当某些个别机器因为存在机器假死，导致处于假死状态，导致一些服务接口响应异常，通过 SOFARPC 的故障剔除和服务权重降级来减少对这些异常机器接口的访问，而将更多的流量打到正常的机器上。 这里针对的维度主要还是 IP + 服务维度，如部署在 xxx 机器上交易系统对外提供的 TransQueryService 服务。\n三. 原理解析 通常一个服务有多个服务提供者，其中部分提供者可能由于机器假死等导致长连接还存活但是程序已经无法正常响应 。 故障剔除功能会将这部分异常的服务提供者进行降级，使得客户端的请求更多地指向健康节点。当异常节点的表现正常后，故障剔除功能会对该节点进行恢复，使得客户端请求逐渐将流量分发到该节点。\nSOFARPC 5.3.0 以上支持故障剔除的功能，故障剔除功能采用自动化监控和降级，因此可以减少人工干预，提供系统可用率。SOFARPC 剔除的维度是服务 + Ip 级别。为了支持单机故障剔除能力，SOFARPC 提供了以下几个方面的设计：\n 入口设计: 进行RPC调用的时候，增加一个信息统计的传递入口。SOFARPC 采用无缝插入设计，在不破坏开放封闭原则前提下引入单机故障剔除能力。\n 信息收集器 : 维护和管理从入口传进来的统计信息。\n 计算策略 : 主要是根据度量结果，判断是否需要执行降级或者恢复服务。如果命中降级规则，则触发降级行为。如果命中恢复规则，则触发恢复行为。\n 度量策略 : 负责按一定维度对调用信息做度量，判断服务正常或异常。\n 降级策略 : 如果服务异常，需要进行降级处理，降级策略指定了处理逻辑，比如按打印日志或降低服务权重。\n 恢复策略 ：当一个异常服务恢复正常时，如何恢复该服务，例如提高服务权重等。\n 3.1 整体结构和入口 《SOFARPC 链路追踪剖析》中已介绍 SOFARPC 的 内核设计和总线设计，和链路追踪功能一样，SOFARPC 单机故障剔除能力也是基于内核设计和总线设计，做到可插拔、零侵入。\nSOFARPC 单机故障剔除模块是 FaultToleranceModule， 通过 SOFARPC 的 SPI 机制完成模块的自动化加载，以完成该功能的插入。 FaultToleranceModule 模块包含了两个重要部分：\n subscriber 事件订阅器 。 通过订阅事件总线 EventBus 的事件，以零侵入方式完成 RPC 调用的统计和信息收集。\n regulator 调节器 。 根据收集的 RPC 调用信息，完成服务调用或服务权重的调节，达到服务 …","date":1537167600,"description":"本文为《剖析 | SOFARPC 框架》第六篇，作者畅为。","dir":"blog/sofa-rpc-single-machine-fault-culling/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3171526788b6f17e3ffa37512918729f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","publishdate":"2018-09-17T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 单机故障剔除剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","wordcount":5281},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第五篇。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 上一篇，我们介绍了 SOFARPC 同步异步的实现，本文我们将会介绍 SOFARPC 中的线程模型。\n本文会从同步异步，阻塞非阻塞开始讲起，进而探讨常见的线程模型设计，之后，我们会介绍下 SOFABolt 中对 Netty 的模型使用，最后 SOFARPC 在一次调用过程中各个步骤执行的线程。\n几种常见的 IO 模型 首先介绍一下 Linux 的几种 IO 模型，以进程从 Socket 中读取数据为例。实际上，进程最终是通过 recvfrom 系统调用来读取数据。这个时候，系统内核在收到之后，根据 IO 模型的不同，处理是不同的。\n注意，图下的红色部分表示阻塞时间。\n阻塞 I/O 阻塞 I/O(blocking I/O) 模型是最流行，最简单易用的 I/O 模型，默认情况下，所有套接字和文件描述符就是阻塞的。阻塞 I/O 将使请求进程阻塞，直到请求完成或出错。\n非阻塞 I/O 非阻塞 I/O(nonblocking I/O)的含义：如果 I/O 操作会导致请求进程休眠，则不要把它挂起，也就是不会让出 CPU，而是返回一个错误告诉它（可能是 EWOULDBLOCK 或者 EAGAIN）。\nI/O 复用 I/O 多路复用(I/O multiplexing)会用到 select 或者 poll 或者 epoll 函数，这几个函数也会使进程阻塞，但是和阻塞 I/O 所不同的的，函数可以同时阻塞多个 I/O 操作。而且可以同时对多个读操作，多个写操作的 I/O 函数进行检测，直到有数据可读或可写时，才真正调用 I/O 操作函数。\n信号驱动式 I/O 信号驱动 I/O(signal-driver I/O)使用信号，让内核在描述符就绪时发送 SIGIO 信号通知我们进行处理，这时候我们就可以开始真正的读了。\n异步 I/O 异步 I/O(asynchronous I/O)由 POSIX 规范定义，包含一系列以 aio 开头的接口。一般地说，这些函数的工作机制是：告知内核启动某个操作，并让内核在整个操作（包括将数据从内核空间拷贝到用户空间）完成后通知我们。\n这种模型与信号驱动模型的主要区别是：信号驱动 I/O 是由内核通知我们何时可以启动一个 I/O 操作，而异步 I/O 模型是由内核通知我们 I/O 操作何时完成。\n汇总 综上，我们给出一个大家比较熟知的比较图。方便理解。\nJAVA BIO \u0026amp;amp; NIO 在了解了内核层面上这几个线程模型之后，我们要给大家介绍下 JAVA BIO 和 JAVA NIO。\nJAVA BIO 首先我们给大家看一个直接使用 JAVA BIO 写得一个服务端。\n传统的BIO里面socket.read()，如果TCP RecvBuffer里没有数据，调用会一直阻塞，直到收到数据，返回读到的数据。\nJAVA NIO 对于 NIO，如果 TCP 的 buffer 中有数据，就把数据从网卡读到内存，并且返回给用户；反之则直接返回0，永远不会阻塞。下面是一段比较典型的 NIO 的处理代码。\n在我们可以将 JAVA NIO 和多路复用结合起来。这里也是最简单的 Reactor 模式：注册所有感兴趣的事件处理器，单线程轮询选择就绪事件，执行事件处理器。\n这里简单比较了一下以前的 BIO 和现在的 NIO，新的 NIO 给我们带来了如下的好处。\n 事件驱动模型\n 单线程处理多任务\n 非阻塞 I/O，I/O 读写不再阻塞，而是返回 0\n 基于快的传输，比基于流的传输更高效\n 更高级的 IO 函数，零拷贝\n 允许 IO 多路复用\n Reactor 线程模型 前面说了，我们有了 JAVA NIO ，可以用多路复用。有些同学可能会问，不能直接使用吗？答案是可以直接使用，\n但是技术层面上的问题虽然解决了，在工程层面，实现一个高效没有问题的架构依然很难，而且这种多路复用，对编程思维有比较大的挑战，所以，工程层面还不够。因此，有了 Reactor 编程模型\n一般情况下，I/O 复用机制需要事件分发器，以上这个分发事件的模型太简单了。实际使用起来会有一些性能问题。目前比较流行的是 Reactor 和 Proactor，本文不介绍 Proactor 模型，有兴趣的同学可以自己学习。\n标准/典型的 Reactor 中定义了三个角色：\n而一个标准的操作流程则是：\n 步骤1：等待事件到来（Reactor 负责）。\n 步骤2：将读就绪事件分发给用户定义的处理器（Reactor 负责）。\n 步骤3：读数据（用户处理器负责）。\n 步骤4：处理数据（用户处理器负责）。\n 在这个标准之下，Reactor 有几种演进模式可以选择。注意 Reactor 重点描述的是 IO 部分的操作，包括两部分，连接建立和 IO 读写。\n单线程模型 Reactor 单线程模型指的是所有的 IO 操作都在同一个NIO 线程上面完成，NIO 线程的职责如下：\n 作为 NIO 服务端，接收客户端的 TCP 连接；\n 作为 NIO 客户端，向服务端发起 TCP 连接；\n 读取通信对端的请求或者应答消息；\n 向通信对端发送消息请求或者应答消息。\n 这是最基本的单 Reactor 单线程模型。其中 Reactor 线程，负责多路分离套接字，有新连接到来触发 connect 事件之后，交由 Acceptor 进行处理，有 IO 读写事件之后交给 hanlder 处理。\nAcceptor 主要任务就是构建 handler，在获取到和 client 相关的 SocketChannel 之后 ，绑定到相应的 handler上，对应的 SocketChannel 有读写事件之后，基于 reactor 分发，hanlder 就可以处理了（所有的 IO 事件都绑定到 selector 上，由 Reactor 分发）。\n该模型 适用于处理器链中业务处理组件能快速完成的场景。不过，这种单线程模型不能充分利用多核资源，所以实际使用的不多。\n多线程模型 Reactor 多线程模型与单线程模型最大的区别就是将 IO 操作和非 IO 操作做了分离。效率提高。\nReactor 多线程模型的特点：\n 有专门一个 NIO 线程-Acceptor 线程用于监听服务端，主要接收客户端的 TCP 连接请求；\n 网络 IO 操作-读、写等由一个单独的 NIO 线程池负责，线程池可以采用标准的 JDK 线程池实现，它包含一个任务队列和 N 个可用的线程，由这些 NIO 线程负责消息的解码、处理和编码；\n 主从多线程模型 这个也是目前大部分 RPC 框架，或者服务端处理的主要选择。\nReactor 主从多线程模型的特点：\n服务端用于接收客户端连接的不再是个1个单独的 NIO 线程，而是一个独立的 NIO 线程池。\n主要的工作流程： …","date":1536735600,"description":"本文为《剖析 | SOFARPC 框架》第五篇。","dir":"blog/sofa-rpc-threading-model/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fbde29dd299a8163dafa9d571d1714e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-threading-model/","publishdate":"2018-09-12T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-threading-model/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 线程模型剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-threading-model/","wordcount":3410},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第四篇。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 这一篇，我们为大家带来了开发过程中，最常接触到的同步异步调用解析。本文会介绍下同步异步的使用场景，以及 SOFARPC 中的代码实现机制，为了方便大家理解和阅读代码。不会过多的设计代码实现细节，更多的还是希望大家从中有所收获，并能够独立阅读核心代码。\n原理剖析 SOFARPC 以基于 Netty 实现的网络通信框架 SOFABolt 用作远程通信框架，使用者不用关心如何实现私有协议的细节，直接使用内置 RPC 通信协议，启动客户端与服务端，同时注册用户请求处理器即可完成远程调用：\nSOFARPC 服务调用提供同步 Sync、异步 Future、回调 Callback 以及单向 Oneway 四种调用类型。\n这里我们先提供一张整体的图，后面每个方式原理介绍的时候，我会进行更加详细的解释。读者可以重点阅读以下部分的图示，根据阻塞时间的长短，会有不同的标识。\nSync 同步调用 同步调用是指的客户端发起调用后，当前线程会被阻塞，直到等待服务端返回结果或者出现了超时异常，再进行后续的操作，是绝大多数 RPC 的默认调用方式，无需进行任何设置即可。\n这种调用方式，当前线程发起调用后阻塞请求线程,需要在指定的超时时间内等到响应结果才能完成本次调用。如果超时时间内没有得到响应结果，那么抛出超时异常。Sync 同步调用模式最常用，注意要根据对端的处理能力合理设置超时时间。\n如上图所示，这里主要是描述了客户端的处理逻辑，其中客户端线程和 RPC 内部部分处理并不在一个线程里。所以这里客户端线程包含其中一部分操作，后文的图中也是类似。其中红色的树状框表示客户端的线程阻塞。\n可以看到，客户端在代码片段2中，发起 RPC 调用，那么除非本次 RPC 彻底完成，或者 RPC 在指定时间内抛出超时异常，否则红框一直阻塞，代码片段3没有机会执行。\nFuture 异步调用 客户端发起调用后不会同步等待服务端的结果，而是获取到 RPC框架给到的一个 Future 对象，调用过程不会阻塞线程，然后继续执行后面的业务逻辑。服务端返回响应结果被 RPC 缓存，当客户端需要响应结果的时候需要主动获取结果，获取结果的过程阻塞线程。\n如上图所示，代码片段2发起 RPC 调用后，RPC 框架会立刻返回一个 Future 对象。给到代码片段2，代码片段2可以选择等待结果，或者也可以继续执行代码片段3，等代码片段3执行完成后，再获取 Future 中的值。\nCallback 回调调用 客户端提前设置回调实现类，在发起调用后不会等待结果，但是注意此时是通过上下文或者其他方式向 RPC 框架注册了一个 Callback 对象，结果处理是在新的线程里执行。RPC在获取到服务端的结果后会自动执行该回调实现。\n如图所示，客户端代码段2发起 RPC 调用后，并不关心结果，此时也不会有结果。只是将自己的一个 Callback 对象传递给 RPC 框架，RPC 框架发起调用后，立即返回。之后自己等待调用结果，在有了调用结果，或者超过业务配置的超时时间后，将响应结果或者超时的异常，进行 callback 的回调。一般的，一个 callback 的结果需要包含两个部分\npublic interface InvokeCallback { /** * Response received. * * @param result */ public void onResponse(final Object result); /** * Exception caught. * * @param e */ public void onException(final Throwable e); } 如果是正常返回，则 RPC 框架回调用户传入 callback 对象的 onResponse 方法，如果是框架层的异常，比如超时，那么会调用 onException 方法。\nOneway 单向调用 客户端发送请求后不会等待服务端返回的结果，并且会忽略服务端的处理结果，\n当前线程发起调用后，用户并不关心调用结果，只要请求已经发出就完成本次调用。单向调用不关心响应结果，请求线程不会被阻塞，使用 Oneway 调用需要注意控制调用节奏防止压垮接收方。注意 Oneway 调用不保证成功，而且发起方无法知道调用结果。因此通常用于可以重试，或者定时通知类的场景，调用过程是有可能因为网络问题、机器故障等原因导致请求失败，业务场景需要能接受这样的异常场景才能够使用。\n调用方式比较 调用方式 优点 不足 使用场景 Sync 简单 同步阻塞 大部分场景 Oneway 简单，不阻塞 无结果 不需要结果，业务不需要保证调用成功的场景 Future 异步，可获取结果 需要再次调用 get 方法获取结果 同线程内多次 RPC 调用。且没有先后关系 Callback 异步，不需要手动获取结果 使用稍微复杂。且不能在当前代码段直接操作结果 当前不关心结果。但是最终依赖结果做一些其他事情的场景 源码剖析 下面我们以 SOFARPC 中的 BOLT 协议为基础，介绍一些 RPC 框架下面的代码层面的设计。主要介绍代码结构和相互的调用关系。\n对 BOLT 的包装主要在\ncom.alipay.sofa.rpc.transport.bolt.BoltClientTransport 业务方并不直接使用 BOLT 定义的一些类型，而是使用 RPC 定义的一些类型。这些类型被适配到 BOLT 的类型上，使得 RPC 框架对用户提供了统一的 API，和底层是否采用 BOLT 不强相关。\nSync 同步调用 SOFARPC 中的的同步调用是由 Bolt 通信框架来实现的。核心代码实现在\ncom.alipay.remoting.BaseRemoting#invokeSync com.alipay.remoting.rpc.protocol.RpcResponseProcessor#doProcess 使用时无需特殊配置。\nFuture 异步调用 使用 Future 异步调用 SOFABoot 配置服务引用需要设置\n\u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; 元素的 type 属性声明调用方式为 future：\n如上设置为 Future 调用的方式。客户端获取响应结果有两种方式：\n1.通过 SofaResponseFuture 直接获取结果。第一个参数是获取结果的超时时间，第二个参数表示是否清除线程上下文中的结果。\nString result =(String)SofaResponseFuture.getResponse(timeout,true); 2.获取原生 Futrue，该种方式获取JDK原生 …","date":1536130800,"description":"本文为《剖析 | SOFARPC 框架》第四篇。","dir":"blog/sofa-rpc-synchronous-asynchronous-implementation/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d7ab7dabc882ef32b491dc6ce551fc39","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","publishdate":"2018-09-05T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 同步异步实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","wordcount":3596},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第三篇，本篇由米麒麟/碧远共同出品。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 在 RPC 调用过程中，我们经常会和多个服务端进行远程调用，如果在每次调用的时候，都进行 TCP 连接，会对 RPC 的性能有比较大的影响，因此，实际的场景中，我们经常要对连接进行管理和保持。\nSOFARPC 应用心跳包以及断线重连实现,结合系统 tcp-keepalive 机制，来实现对 RPC 连接的管理和保持。\n连接管理 首先我们将会介绍连接管理相关的一些背景知识。\n长连接和短连接 短连接，一般是指客户端向服务端发起连接请求。连接建立后，发送数据，接收服务端数据返回，然后触发连接断开，下次再重新重复以上过程。\n长连接，则是在建立连接后，发送数据，接收数据，但是不主动断开，并且主动通过心跳等机制来维持这个连接可用，当再次有数据发送请求时，不需要进行建立连接的过程。\n一般的，长连接多用于数据发送频繁，点对点的通讯，因为每个 TCP 连接都需要进行握手，这是需要时间的，在一些跨城，或者长距离的情况下，如果每个操作都是先连接，再发送数据的话，那么业务处理速度会降低很多，所以每个操作完后都不断开，再次处理时直接发送数据包即可，节省再次建立连接的过程。\n但是，客户端不主动断开，并不是说连接就不会断。因为系统设置原因，网络原因，网络设备防火墙，都可能导致连接断开。因此我们需要实现对长连接的管理。\nTCP 层 keep-alive tcp 的 keep-alive 是什么 tcp-keepalive，顾名思义，它可以尽量让 TCP 连接“活着”，或者让一些对方无响应的 TCP 连接断开，\n使用场景主要是：\n 一些特定环境，比如两个机器之间有防火墙，防火墙能维持的连接有限，可能会自动断开长期无活动的 TCP 连接。\n 还有就是客户端，断电重启，卡死等等，都会导致 TCP 连接无法释放。\n 这会导致：\n一旦有热数据需要传递，若此时连接已经被中介设备断开，应用程序没有及时感知的话，那么就会导致在一个无效的数据链路层面发送业务数据，结果就是发送失败。\n无论是因为客户端意外断电、死机、崩溃、重启，还是中间路由网络无故断开、NAT 超时等，服务器端要做到快速感知失败，减少无效链接操作。\n而 tcp-keepalive 机制可以在连接无活动一段时间后，发送一个空 ack，使 TCP 连接不会被防火墙关闭。\n默认值 tcp-keepalive，操作系统内核支持，但是不默认开启,应用需要自行开启，开启之后有三个参数会生效，来决定一个 keepalive 的行为。\nnet.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 75 可以通过如下命令查看系统 tcp-keepalive 参数配置。\nsysctl -a | grep keepalive cat /proc/sys/net/ipv4/tcp_keepalive_time sysctl net.ipv4.tcp_keepalive_time 系统默认值可以通过这个查看。\ntcp_keepalive_time，在 TCP 保活打开的情况下，最后一次数据交换到 TCP 发送第一个保活探测包的间隔，即允许的持续空闲时长，或者说每次正常发送心跳的周期，默认值为 7200s（2h）。 tcp_keepalive_probes 在 tcp_keepalive_time 之后，没有接收到对方确认，继续发送保活探测包次数，默认值为 9（次）。 tcp_keepalive_intvl，在 tcp_keepalive_time 之后，没有接收到对方确认，继续发送保活探测包的发送频率，默认值为 75s。\n这个不够直观，直接看下面这个图的说明：\n如何使用 应用层，以 Java 的 Netty 为例，服务端和客户端设置即可。\nServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 100) .childOption(ChannelOption.SO_KEEPALIVE, true) .handler(new LoggingHandler(LogLevel.INFO)) .childHandler(new ChannelInitializer\u0026amp;lt;SocketChannel\u0026amp;gt;() { @Override public void initChannel(SocketChannel ch) throws Exception { ch.pipeline().addLast( new EchoServerHandler()); } }); // Start the server. ChannelFuture f = b.bind(port).sync(); // Wait until the server socket is closed. f.channel().closeFuture().sync(); 就是这里面的ChannelOption.SO_KEEPALIVE, true 对应即可打开.\n目前 bolt 中也是默认打开的.\n.childOption(ChannelOption.SO_KEEPALIVE, Boolean.parseBoolean(System.getProperty(Configs.TCP_SO_KEEPALIVE, \u0026amp;quot;true\u0026amp;quot;))); Java 程序只能做到设置 SO_KEEPALIVE 选项，至于 TCP_KEEPCNT，TCP_KEEPIDLE，TCP_KEEPINTVL 等参数配置，只能依赖于 sysctl 配置，系统进行读取。\n检查 查看 tcp 连接 tcp_keepalive 状态\n我们可以用 netstat -no|grep keepalive 命令来查看当前哪些 tcp 连接开启了 tcp keepalive. 应用层 keep-alive 应用层 keep-alive 方案，一般叫做心跳包，跟 tcp-keepalive 类似，心跳包就是用来及时监测是否断线的一种机制，通过每间隔一定时间发送心跳数据，来检测对方是否连接，是属于应用程序协议的一部分。\n心跳是什么 心跳想要实现的和 tcp keep-alive 是一样的。\n由于连接丢失时，TCP 不会立即通知应用程序。比如说，客户端程序断线了，服务端的 TCP 连接不会检测到断线，而是一直处于连接状态。这就带来了很大的麻烦， …","date":1535526000,"description":"本文为《剖析 | SOFARPC 框架》第三篇，本篇由米麒麟/碧远共同出品。","dir":"blog/sofa-rpc-connection-management-heartbeat-analysis/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2f911034e6bec76b8b0496b7f06e10b7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","publishdate":"2018-08-29T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之SOFARPC 连接管理与心跳剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","wordcount":4225},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第二篇，本篇由畅为/碧远/卓与共同出品。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 一. 前言 微服务已经被广泛应用在工业界，微服务带来易于团队并行开发、独立部署、模块化管理等诸多优点。然而微服务将原单体拆分多个模块独立部署，各模块之间链接变得错综复杂，在大规模分布式系统中这种复杂链路给维护带来了诸多困难。 如果对整个微服务架构不能了然于胸，便很难理清各模块之间的调用关系。 例如修改一个服务接口，对哪些服务造成影响不能快速定位。\nSOFARPC 在5.4.0 以后提供了链路追踪技术，可以有效协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。\n如思维导图所示，本文将从以下几个方面介绍目前已经开源的 SOFARPC 的链路追踪技术：\n二. 什么是链路追踪技术 链路追踪技术主要是收集、存储、分析分布式系统中的调用事件数据，协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。 链路追踪技术包含了数据埋点、收集、存储、分析等相关技术，是一套技术体系。 大部分的链路追踪框架都是参考 google链路追踪系统Dapper 的一篇设计论文（《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 ），SOFARPC 的SOFATracer 的设计灵感也是来自这篇著名论文。\n以大规模分布式电商系统为例，用户下单购买某款产品时后端需要调用各系统或子模块进行协作，共同完成一个用户请求。 如下图所示，用户的下单行为涉及到了A、B、C、D、E、F 6个系统的协同工作，这些系统都是以集群形式部署。整个链路中最长的链路调用是3层，如 A-\u0026amp;gt; C -\u0026amp;gt; E 或 A -\u0026amp;gt; C -\u0026amp;gt; F。\n模块的增多加大了系统出错的概率，一旦因某系统/模块出错导致整个请求调用出错，在缺乏链路追踪的条件下很难定位具体出错的模块，只能通过日志搜索定位。 在实际生产环境下比较关注一个请求中的各个模块的耗时情况、连续调用情况、出错的节点等信息。 为了解决上述问题，Dapper提供了一套解决方案。整个方案分为数据收集、存储和分析几个部分。分布式追踪技术会记录一个请求中各模块的调用信息；并通过一个处理集群把所有机器上的日志增量地收集到集群当中进行处理，将同一个请求的日志串联；最后可视化显示调用情况。\n常用的数据收集方式为埋点，通过在公共组件如RPC等注入代码，收集服务调用的相关信息。目前大部分链路调用系统如Dapper、鹰眼、Spring Cloud Sleuth 都在用这种模式。同样SOFARPC 作为一个公共的通讯框架，在金融业务领域被广泛应用，因此适合作为埋点，这样无需业务端自行埋点，可做到对业务代码的无侵入性。\nDapper 将一个调用过程构建成一棵调用树(称为Tracer)，Tracer树中的每个节点表示链路调用中的一个模块或系统。 通过一个全局唯一的 traceId 来标识一个请求调用链。 并定义了span，span表示一个系统的调用，一个span 包含以下阶段：\n Start: 发起调用\n cleint send(cs): 客户端发送请求\n Server Recv(sr)：服务端收到请求\n Server Send(ss): 服务端发送响应\n Client Recv(cr) : 客户端收到服务端响应\n End： 整个链路完成\n 每个span 包含两个重要的信息 span id(当前模块的span id) 和 span parent ID(上一个调用模块的span id)，通过这两个信息可以定位一个span 在调用链的位置。 通过以上信息我们可以定义用户下单过程的调用链：\nSOFARPC中的链路追踪技术主要是作为埋点部分，因此对于链路追踪系统的收集和分析部分本文不做详述，想要深入了解的可参看参考资料内容。链路追踪可以提供我们以下功能:\n 服务耗时、瓶颈分析 ：分析每个服务的耗时情况，可以针对耗时长的服务进行优化，提高服务性能。\n 可视化错误：快速定位服务链路中出错的环境，便于排查和定位问题。一般链路追踪中间件都提供了ZipKin 页面支持。\n 链路优化: 对于调用比较频繁的服务，可以针对这些服务实施一些优化措施。\n 调用链路梳理：通过可视化界面，对整个调用链路有个清晰的认识。\n 在设计分布式链路框架时需要考虑一下几个问题：\n 低损耗、高性能: 追踪系统对在线服务的影响应该做到足够小，不影响线上服务性能。\n 应用透明: 对于业务开发人员来说，应不需要知道有跟踪系统这回事的。\n 可扩展性：虽则业务规则增大、集群增多，监控系统都应该能完全把控住这种快速变化。\n 数据采样设计：如果每条日志都记录，在高并发情况下对系统有一定的损耗。但收集数据太少可能对统计结果有所影响，所以应合理设计采样比例。\n 三. SOFARPC 链路追踪设计原理 SOFARPC 作为一个基础的通讯中间件，对服务调用有很强的感知能力，容易获取链路追踪所需的服务调用信息。因此很多链路追踪系统都会选择RPC 作为埋点对象，通过对RPC中间件的埋点可以轻松做到对用户的无感知、透明化。 SOFARPC在5.4.0 以后开始支持分布式链路追踪，其技术实现主要依赖于所集成的SOFATracer。\nSOFARPC 不仅提供了埋点信息采集的能力, 还支持数据上报zipkin。 通过SOFARPC + SOFATracer + zipKin 可以快速搭建一套完整的链路追踪系统，包括埋点、收集、分析展示等。 收集和分析主要是借用zipKin的能力，本文重点讲SOFARPC中的数据埋点设计。SOFARPC自身具备的微内核设计和可拓展性，使得在SOFARPC在不破坏开放封闭原则的前提下，比较轻松地集合SOFATracer。该部分主要从以下几个方面讨论SOFARPC的链路追踪设计思路：\n 可插拔设计。 SOFARPC采用了微内核设计，使得很容易扩展，增加新功能。\n 总线设计。为数据埋点做提供一种无侵入的扩展方式。\n 调用trace和span\n 数据采样设计\n 异步刷新机制\n 耗时计算：链路调用的耗时统计等信息获取。\n 埋点数据透传，各模块之间的链路调用数据的透传机制。\n 异步线程的链路调用。在异步多线程环境下如何保证traceId和spanId的有序性。\n 链路调用日志数据的文件存储结构\n 3.1 可插拔设计 SOFARPC自身具备的微内核设计和可拓展性，使得在SOFARPC在不破坏开放封闭原则的前提下，比较轻松地集合SOFATracer。SOFARPC 采用了自己实现的一套SPI机制， 通过该SPI机制动态去加载其他模块、过滤器、协议等，实现灵活拓展。SOFARPC 为了集成SOFATracer也采用了这套机制，做到可插拔。\nSofaTracerModule 类实现了Module …","date":1534921200,"description":"本文为《剖析 | SOFARPC 框架》第二篇，本篇由畅为/碧远/卓与共同出品。","dir":"blog/sofa-rpc-link-tracking/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"09e24cfad0d59d40a509e893f26c59ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-link-tracking/","publishdate":"2018-08-22T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-rpc-link-tracking/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 链路追踪剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-link-tracking/","wordcount":6480},{"author":"碧远","categories":"SOFARPC","content":" 前言 RPC 框架作为分布式技术的基石，在分布式和微服务环境下，扮演着非常重要的角色。\n在蚂蚁金服的分布式技术体系下，我们大量的技术产品（非网关类产品），都需要在内网，进行节点间通信。底层通信框架，已经在蚂蚁自研的 BOLT中的进行了实践，BOLT 提供了优秀的通信协议与通信框架，在 BOLT 的基础上，我们研发了自己的 RPC 框架，提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等基础能力，本文将从以下几个方面介绍目前已经开源的 SOFARPC 框架。\n RPC 是什么 通用 RPC 框架原理 SOFARPC 框架设计 RPC是什么 RPC 这个概念术语在上世纪 80 年代由 Bruce Jay Nelson 提出，在 Nelson 的论文 \u0026amp;ldquo;Implementing Remote Procedure Calls\u0026amp;rdquo; 中他提到了几点：\n 简单：RPC 概念的语义清晰,简单，方便建立分布式计算。 高效：在使用方看来,十分简单而且高效。 通用：通用,适用于各种不同的远程通信调用。 这里面Nelson提出了一个 RPC框架应该包含的几个部分。\n User User-stub RPC-Runtime Server-stub Server 如下图示，为了和现在我们通用的术语一致，我将 User 改成 Client 了。\n当 Client 想发起一个远程调用时，实际是通过本地调用 Client-stub，而 Client-stub 负责将调用的接口、方法和参数通过约定的协议规范进行编码并通过本地的 RPC-Runtime 实例传输到远端的实例。远端 RPC-Runtime 实例收到请求后交给 Server-stub 进行解码后发起本地端调用，在 Java中可以认为就是反射调用,调用结果再返回给 Client 端。\n从上文可以看到，一个典型的 RPC 调用过程还是相对简单的。但是实际上，一个真正的 RPC 框架要做的远不止这些。\n通用 RPC 框架原理 相信对 RPC 框架有过一定了解，或者使用过 RPC 产品的同学，在看到了图上之后，会产生几个疑问：\n1.Stub 怎么出现？\n2.怎么打包参数？\n3.怎么传输?\n4.怎么知道目标地址?\n5.怎么发布一个 RPC 服务?\n在解释这些问题之前，这里我画了一张目前通用的 RPC 框架的一个流程图：\n其中：\n1.创建代理解决了 Stub 的问题。\n2.序列化和网络协议编码解决了打包的问题。\n3.服务发现与路由寻址解决了如何知道目标地址的问题。\n4.如何发布一个服务，Registry 来解决。\n Bolt，Netty 等解决了网络传输的问题。 当然 SOFARPC 的功能不止这些,在解决了这些问题之后，根据业务的需求和实际的线上情况，我们也开发了熔断,限流,故障剔除,数据透传等能力，下面我会来介绍 SOFARPC 的框架设计。\nSOFARPC框架设计 SOFARPC RoadMap 首先介绍下目前 SOFARPC 的现状和一些正在做的事情。\n欢迎对相关功能和 feature 有兴趣的同学，一起参与开发~\nSOFARPC 结构设计 原理大家清楚之后，为了方便大家尽快上手开发使用，我先从目前的 RPC 框架结构来简单介绍。\n其中 core和 core-impl 是核心的功能，包含 API 和一些扩展机制，extension-impl 中，则包含了不同的实现和扩展，比如对 http，rest，对 metrics，以及其他注册中心的集成和扩展。\n如 bootstrap 中对协议的支持，remoting 中对网络传输的支持，registry 中对注册中心的支持等。\n在此基础上，由于 RPC 框架涉及服务端和客户端，我会结合 SOFARPC 的处理流程，详细介绍下客户端和服务端的处理。\n客户端调用流程 当使用方对服务进行了引用配置之后：\n1.RPC 生成 Proxy，作为用户可以操作的入口。\n2.向服务中心订阅这个 RPC 的地址信息。\n3.使用方发起调用，经过路由，负载均衡，各类 Filter 发起调用。\n服务端处理流程 在服务端看来,通过 TCP 监听端口后：\n1.接到 RPC 请求后，进行解码和反序列化。\n2.选择线程池，进行分发。\n3.经过 Filter，进行反射调用。\n4.将结果序列化，编码,进行写回。\n可扩展的机制 从上面的流程中，可以看到，每个部分基本都有多种实现可选，这得益于RPC的扩展机制。\n为了对 RPC 各个环节的都有充足的可扩展性，提供 SPI 的能力，所以内部的实现和第三方实现都是绝对平等的。\n相比原生 SPI，我们实现了更强大的功能\n 按需加载\n 可以有别名\n 可以有优先级进行排序和覆盖\n 可以控制是否单例\n 可以在某些场景下使用编码\n 可以指定扩展配置位置\n 可以排斥其他扩展点\n 我们实现了一套自己的 SPI 机制。整个流程如下：\n在启动加载阶段，RPC 会根据对应的配置，加载需要调用方法ExtensionLoader(Class\u0026amp;lt;T\u0026amp;gt; interfaceClass, ExtensionLoaderListener\u0026amp;lt;T\u0026amp;gt; listener) 逻辑如下：\n 首先读取rpc-config-default.json和rpc-config.json，找到扩展描述文件存放的文件夹：extension.load.path属性。\n 找到接口类对应的扩展描述文件的文件名（默认就是接口名，也可以自己指定）。\n 循环加载这个文件下的扩展描述文件，按行读取。（同一个接口的同一个别名对应唯一的一个实现类，可以重复，允许覆盖。）\n 保存扩展实现类的alias和实现类的对应关系。\n 如果 ExtensionLoaderListener 不为空，则通知 Listener。\n 最终，将会构造出各个不同的 Filter，Invoker 等等。\n其中我们首先设计了一个扩展，代表这个类或者接口是可扩展的，默认单例、不需要编码。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * 指定自定义扩展文件名称，默认就是全类名 * * @return 自定义扩展文件名称 */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * 扩展类是否使用单例，默认使用 * * @return 是否使用单例 */ boolean singleton() default true; /** * 扩展类是否需要编码，默认不需要 * * @return 是否需要编码 */ boolean coded() default false; } 同时，针对具体的扩展实现，定义一个扩展注解\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * 扩展点名字 * * …","date":1533193200,"description":"本文为 剖析 SOFARPC 框架第一篇。","dir":"blog/sofa-rpc-framework-overall-extension/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d83b816009377f7f93fcd1edf63c534d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","publishdate":"2018-08-02T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","summary":"前言 RPC 框架作为分布式技术的基石，在分布式和微服务环境下，扮演着非常重要的角色。 在蚂蚁金服的分布式技术体系下，我们大量的技术产品（非网关类产品","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之总体设计与扩展机制","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","wordcount":2629},{"author":"鲁直","categories":"SOFABoot","content":" 无论是什么样的业务系统，多多少少都会去做一些模块化的划分，或横或纵，各种姿势，但是这些姿势真地能帮你划分出良好的模块吗？帮你在模块之间做到高内聚，低耦合吗？模块化对于服务化又有什么样的影响？本来将分析常见的几种模块化方案的利弊，并且介绍蚂蚁金服开源的框架 SOFA 在模块化中发挥的作用。\n传统模块化的陷阱 在一个简单的 Spring/SpringBoot 的系统中，我们常常见到一个系统中的模块会按照如下的方式进行分层，如下图中的左边部分所示，一个系统就简单地分为 Web 层、Service 层、DAL 层。\n当这个系统承载的业务变多了之后，系统可能演化成上图中右边的这种方式。在上图的右边的部分中，一个系统承载了两个业务，一个是 Cashier（收银台），另一个是 Pay（支付），这两个业务可能会有一些依赖的关系，Cashier 需要调用 Pay 提供的能力去做支付。\n但是在这种模块化的方案里面，Spring 的上下文依然是同一个，类也没有任何做隔离，这就意味着，Pay Service 这个模块里面的任何的一个 Bean，都可以被 Cashier Service 这个模块所依赖。极端的情况下，可能会出现下面这种情况：\nCashier Service 错误地调用了 Pay Service 中的一个内部的 Bean，造成了两个模块之间的紧耦合。\n这种传统的模块化的问题在于模块化地不彻底。虽然在研发的时候，通过划分模块，把特定职责的类放到特定的模块里面去，达到了类的「物理位置」的内聚。但是在运行时，由于没有做任何隔离的手段，作为一个模块的开发者，并没有办法清楚地知道对方模块提供的对外的接口到底是什么，哪些 Bean 我是可以直接注入来用的，哪些 Bean 是你的内部的 Bean，我是不能用的。长此以往，模块和模块之间的耦合就会越来越严重，原来的模块的划分形同虚设。当系统越来越大，最后需要做服务化拆分的时候，就需要花费非常大的精力去梳理模块和模块之间的关系。\nOSGi 模块化 提到模块化，不得不提 OSGi，虽然 OSGi 没有成为 Java 官方的模块化的标准，但是由于 Java 在 Java 9 之前，一直没有官方的模块化的标准，所以 OSGi 已经是事实上的标准。\nOSGi 为模块化主要做了两个事情：\n OSGi 的类隔离 OSGi 的声明式服务 下面就给读者们简单地解释一下 OSGi 的这两个方面。\nOSGi 的类隔离 OSGi 通过扩展 Java 的 ClassLoader 机制，将模块和模块之间的类完全隔离开来，当一个模块需要引用另一个模块的类的时候，通过在模块中的 MANIFEST.MF 文件中声明类的导出和导入来解决，如下图所示：\n通过这种方式，可以控制一个模块特定的类才可以被另一个模块所访问，达到了一定程度地模块的隔离。\n但是，光光通过类的导出导入来解决类的引用问题还不够，还需要去解决实例的引用的问题，我们往往希望能够直接使用对方模块提供的某一个类的实例，而不是自己去 new 一个实例出来，所以 OSGi 还提供了声明式服务的方式，让一个模块可以引用到另一个模块提供的服务。\nOSGi 的声明式服务 OSGi 的声明式服务正是为了解决这个实例引用的问题，我们可以在一个 OSGi 的模块（Bundle）中去添加一个 XML 配置文件去声明一个服务，如下面的代码所示：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;scr:component xmlns:scr=\u0026amp;quot;http://www.osgi.org/xmlns/scr/v1.1.0\u0026amp;quot; name=\u0026amp;quot;ITodoService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;implementation class=\u0026amp;quot;com.example.e4.rcp.todo.service.internal.MyTodoServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;service\u0026amp;gt; \u0026amp;lt;provide interface=\u0026amp;quot;com.example.e4.rcp.todo.model.ITodoService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/service\u0026amp;gt; \u0026amp;lt;/scr:component\u0026amp;gt; 也可以同样的通过 XML 配置文件去引用一个其他的模块声明的服务：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;scr:component xmlns:scr=\u0026amp;quot;http://www.osgi.org/xmlns/scr/v1.1.0\u0026amp;quot; name=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;reference name=\u0026amp;quot;ITodoService\u0026amp;quot; interface=\u0026amp;quot;com.example.e4.rcp.todo.model.ITodoService\u0026amp;quot; bind=\u0026amp;quot;setITodoService\u0026amp;quot; cardinality=\u0026amp;quot;0..1\u0026amp;quot; unbind=\u0026amp;quot;unsetITodoService\u0026amp;quot; policy=\u0026amp;quot;dynamic\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;implementation class=\u0026amp;quot;com.example.e4.rcp.todo.service.internal.XXXServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/scr:component\u0026amp;gt; 通过声明式服务的方式，我们就可以直接在一个 OSGi 的 Bundle 中使用另一个 Bundle 中提供的服务实例了。\nOSGi 的模块化的问题 OSGi 通过类隔离的机制解决了模块之间的类隔离的问题，然后通过声明式服务的方式解决了模块之间的服务调用的问题，看起来已经完美的解决了我们在传统的模块化中遇到的问题，通过这两个机制，模块和模块之间的边界变得清晰了起来。\n但是在实践的过程中，OSGi 的模块化却面临着一个非常严峻的问题，这个就是就是 OSGi 的类隔离带来的复杂性，OSGi 把每一个模块都通过独立的 ClassLoader 去加载，这样在开发模块的时候，研发的同学就必须非常清楚地去定义哪些类应该导出，哪些类应该导入，一旦少导出，或者导出错误，就会出现各种各样的错误，比如 LinkageError，NoSuchMethodError 等等，而要解决这些错误，要求研发同学清楚地理解 OSGi 的整个类加载体系，以及 Java 的整个类加载体系，这对普通的研发同学来说实在是一个太高的要求。所以这种方式在实施成本非常高，OSGi 并不是非常适合于业务研发。\nSOFA 模块化 为了解决传统的模块化方案模块化不彻底的问题，以及 OSGi 的彻底的模块化带来的复杂性的问题，SOFA 在早期就开始引入了一种折衷的模块化的方案。\nSOFA 模块化的整体的示意图如下：\nSOFA 模块化的方 …","date":1532520754,"description":"本来将分析常见的几种模块化方案的利弊，并且介绍蚂蚁金服开源的框架 SOFA 在模块化中发挥的作用。","dir":"blog/sofastack-modular-isolation/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"796c3ab365dd1191a7777c4dbf9d0a1b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-modular-isolation/","publishdate":"2018-07-25T12:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-modular-isolation/","summary":"无论是什么样的业务系统，多多少少都会去做一些模块化的划分，或横或纵，各种姿势，但是这些姿势真地能帮你划分出良好的模块吗？帮你在模块之间做到高","tags":["SOFABoot"],"title":"蚂蚁金服的业务系统模块化之模块化隔离方案","type":"blog","url":"/sofastack.tech/blog/sofastack-modular-isolation/","wordcount":2688},{"author":"玄北","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力，SOFABoot 模块除了包括 Java 代码外，还会包含 Spring 配置文件，每个 SOFABoot 模块都是独立的 Spring 上下文。\n1. 背景 为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式：\n 基于代码组织上的模块化：这是最常见的形式，在开发期，将不同功能的代码放在不同 Java 工程下，在编译期被打进不同 jar 包，在运行期，所有 Java 类都在一个 classpath 下且使用同一个 Spring 上下文，没做任何隔离； 基于 Spring 上下文隔离的模块化：使用 Spring 上下文来做不同功能模块的隔离，在开发期和编译期，代码和配置也会分在不同 Java 工程中，但在运行期，不同的 Spring Bean 相互不可见，IoC 只在同一个上下文内部发生，但是所有的 Java 类还是在一个 ClassLoader 下； 基于 ClassLoader 隔离的模块化：借用 ClassLoader 来做隔离，每个模块都有独立的 ClassLoader，模块与模块之间的 classpath 不同，SOFAArk 就是这种模块化的实践方式。 以上三种模块化形式的隔离化程度逐次递进，但模块化就像一把双刃剑，在降低模块间耦合的同时也给模块间交互增加了成本，本文介绍第二种模块化形式 —— 基于 Spring 上下文隔离的模块化。\n与基于代码组织上的模块化相比，每个 SOFABoot 模块不仅仅包括 Java 代码，还会包含 Spring 配置文件，这种全新的包组织方式大大降低了用户接入成本，用户只需要简单的引入 Jar 包即可，由 SOFABoot 框架负责刷新模块上下文，无需在原来 Spring 配置文件中新增任何 Bean 定义，简化了接入流程，降低了出错几率。\n每个 SOFABoot 模块的 Spring 上下文都是隔离的。在 Spring 开发中，保证 Spring BeanId 不冲突是 Spring 运行的基础，这个限制在应用规模较小时很容易解决，只需用户在定义 BeanId 时稍加注意即可。但是随着系统规模越来越大，一个系统的开发往往涉及多个团队，保证每个业务定义 BeanId 不重复的成本也越来越高。在 SOFABoot 中，每个 SOFABoot 模块使用独立的 Spring 上下文，避免了不同 SOFABoot 模块间 BeanId 冲突，有效降低企业级多模块开发时团队间的沟通成本。\n2. 基本原理 在介绍 SOFABoot 模块化开发使用之前，我们简单了解下其背后的实现原理。下图是应用运行时的逻辑视图：\nSOFABoot 模块是模块化开发的最小单元，每个 SOFABoot 模块是一个独立的 Spring 上下文，在 SOFABoot 模块中我们可以定义Bean、发布 RPC 服务、连接数据库等等。\n由于上下文隔离，模块与模块之间的 Bean 无法通过 @Autowired 依赖注入，我们提供了 JVM Service/Reference 的方式进行模块间通信。SOFABoot 提供了两种形式的服务发布和引用，用于解决不同级别的模块间调用问题：\n JVM 服务发布和引用：解决一个 SOFABoot 应用内部各个 SOFABoot 模块之间的调用问题 RPC 服务发布和引用：解决多个 SOFABoot 应用之间的远程调用问题 Spring Boot 应用在调用 SpringApplication.run 时会创建一个 Spring Context，我们把它叫做 Root Application Context，它是每个 SOFABoot 模块创建的 Spring Context 的 Parent。这样设计的目的是为了保证每个 SOFABoot 模块的 Spring Context 都能发现 Root Application Context 中创建的 Bean，这样当应用新增 Starter 时，不仅 Root Application Context 能够使用 Starter 中新增的 Bean，每个 SOFABoot 模块的 Spring Context 也能使用这些 Bean。\n下面我们来演示如何开发一个简单的 SOFABoot 模块。\n3. 编写 SOFABoot 模块 3.1 新建工程 DEMO 工程地址\n运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，并创建两个普通的 Maven 模块：\n service-facade: 定义服务接口 service-provide: 演示新建 SOFABoot 模块并发布 JVM 服务 3.2 定义服务接口 service-facade 模块包含用于演示 SOFABoot 模块发布与引用服务接口:\npublic interface SampleService { String message(); } 3.3 定义 SOFABoot 模块 service-provider 是一个 SOFABoot 模块，它会发布一个 JVM 服务供其他模块使用。首先需要为 service-provider 模块增加 sofa-module.properties 文件，将其定义为 SOFABoot 模块，sofa-module.properties 文件放置在 resources 目录:\nModule-Name=com.alipay.sofa.service-provider 3.4 发布服务 SOFABoot 支持三种形式的服务发布，分别是： XML 方式、Annotation 方式以及 API 编码方式，这里演示的是 XML 方式发布服务。\n首先增加 SampleServiceImpl 类，实现 SampleService 接口：\npublic class SampleServiceImpl implements SampleService { private String message; public String message() { return message; } public String getMessage() { return message; } public void setMessage(String message) { this.message = message; } } 增加 META-INF/spring/service-provide.xml 文件，将 SampleServiceImpl 发布为 JVM 服务:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; …","date":1532175154,"description":"本文是对蚂蚁金服开源的 SOFABoot 模块化开发的介绍。","dir":"blog/sofa-boot-modular-development/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"12a378e9b4d93d3dd89e79964b63d186","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-modular-development/","publishdate":"2018-07-21T12:12:34Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-boot-modular-development/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力，SOFABoot 模块除","tags":["SOFABoot"],"title":"基于 SOFABoot 进行模块化开发","type":"blog","url":"/sofastack.tech/blog/sofa-boot-modular-development/","wordcount":2209},{"author":"善逝","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力，以更好地解决随着工程应用变得臃肿庞大后带来的包冲突问题。类隔离能力天生带来模块化能力，同样给协作开发带来便利。\nSOFABoot 的类隔离能力借助单独的组件 SOFAArk 实现，遵循 Spring Boot 依赖即服务的思想，只要工程中引入了 SOFAArk 组件依赖，类隔离能力即生效。\n在上一篇文章 《在 Spring Boot 中集成 SOFABoot 类隔离能力》中，我们详细介绍了 SOFABoot 类隔离能力的使用背景及其使用方式。本文将介绍 SOFABoot 类隔离组件 SOFAArk 的实现原理。\n理解 SOFAArk 三要素 SOFAArk 类隔离框架定义了三个概念，Ark Container，Ark Plugin，Ark Biz。\n在介绍这三个主角之前，我们先来介绍另一个管家：Ark 包。我们都知道一个标准的 Spring Boot 应用可以借助 Spring 官方提供的打包插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 将应用打包成一个可执行 FatJar。相对应的，Ark 包则是 SOFABoot 官方提供的打包插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 将应用打包成一个具有类隔离能力的可执行 FatJar，称之为 Ark 包。下图是粗略地对比两者的目录结构差别：\n可以看到 Ark 包作为应用部署包的分发格式，它包含有 Ark Container，Ark Plugin 和 Ark Biz 三种格式模块。这里我们不对 Ark 包或者其他格式模块的目录结构作分析，感兴趣的同学可以点开文末附上的相关链接。我们重点介绍这三个角色的功能。\n Ark Container: Ark 容器，是组件 SOFAArk 的核心，运行 Ark 包时，Ark 容器会最先启动，负责应用运行时的管理，主要包括构建 Ark Plugin 和 Ark Biz 的类导入导出关系表、启动并初始化 Ark Plugin 和 Ark Biz、管理 Ark Plugin 服务的发布和引用等等。 Ark Plugin: SOFAArk 定义的一种模块格式，由若干个 Jar 包组成的一个 FatJar，开发人员可以借助官方提供的 maven 打包插件将若干 Jar 包打包成一个 Ark Plugin 供应用依赖。运行时，由独立的类加载器加载，因此有隔离需求的 Jar 包建议打包成 Ark Plugin 供应用依赖。 Ark Biz: SOFAArk 定义的一种模块格式，是应用及其依赖的所有三方包组成的一个 FatJar，需要注意的是，Ark Biz 不会包含应用依赖的 Ark Plugin。运行时，Ark Biz由独立的类加载器加载，借助类导入导出关系表，Ark Biz 可以使用 Ark Plugin 的导出类和资源。 SOFAArk 运行时隔离 根据上一节的描述可以知道 SOFABoot 类隔离关键是理解 SOFAArk 定义的三个概念，Ark Container，Ark Plugin 和 Ark Biz。下图表示的是应用启动后，运行时 Ark Container，Ark Plugin，Ark Biz 的逻辑分层图：\n我们将先以 Ark Plugin 入手来介绍 SOFABoot 类隔离的实现原理。\nArk Plugin 隔离 开发者借助 SOFABoot 官方提供的插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 可以将 Java 模块打包成一个 Ark Plugin，这里我们不讨论该打包插件的配置参数和使用方式，感兴趣的同学可以点开文末附上的相关链接以及学习 SOFABoot 类隔离能力使用篇。只需要知道，Ark Plugin 主要包含元信息有：插件启动器、导出类、导入类、导出资源、导入资源、优先级等，这些元信息保存在 Ark Plugin 中的 META-INF/MANIFEST.MF 中，一份典型的 MANIFEST.MF 文件样式如下：\nManifest-Version: 1.0 groupId: com.alipay.sofa artifactId: sample-ark-plugin version: 0.3.0-SNAPSHOT priority: 1000 pluginName: sample-ark-plugin activator: com.alipay.sofa.ark.sample.activator.SamplePluginActivator import-packages: import-classes: import-resources: export-packages: com.alipay.sofa.ark.sample.common.*,com.alipay.sofa.ark.sample export-classes: com.alipay.sofa.ark.sample.facade.SamplePluginService export-resources: Sample_Resource_Exported 在上面我们提到，运行 Ark 包时，类隔离容器 Ark Container 会最先启动，然后 Ark Container 会接管整个应用的启动过程。针对 Ark Plugin 处理逻辑如下：\n 首先解析 Ark 包中引入的所有 Ark Plugin，读取插件元信息，构建类/资源导入导出关系索引表。 提前生成所有插件类加载器，每个 Ark Plugin 都使用独立的类加载器，管理插件类加载逻辑，借助第一步生成的类导入导出关系表，突破 Java 原生的双亲委派模型，可以委托其他插件加载所需类，构建一个类 OSGi 的网状类加载模型。 根据插件优先级，依次调用插件启动器。在插件启动器中，插件开发者可以向容器注册服务以方便其他插件引用，也可以引用其他插件发布的服务，及插件启动所需的初始化操作。 需要明确一点，为了让类加载模型足够简单，Ark 容器在启动任何插件前，会把所有的插件类加载器提前构建完毕。Ark Plugin 可以相互委托加载，插件优先级只是影响插件的启动顺序，而且也不强制 …","date":1528107154,"description":"本文将介绍 SOFABoot 类隔离组件 SOFAArk 的实现原理。","dir":"blog/sofa-boot-class-isolation-deep-dive/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"84c324f1230d57a0c4009566de91bb3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","publishdate":"2018-06-04T10:12:34Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力，以更好地解决随着工程应用变得臃肿庞大后带来的包冲","tags":["SOFAArk","SOFABoot"],"title":"SOFABoot 类隔离原理剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","wordcount":3540},{"author":"余淮","categories":"SOFAStack","content":" 蚂蚁金服自主研发的分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件），包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\n一个多月前，蚂蚁金服开源了 SOFABoot 和 SOFARPC 两个组件，受到了社区的热烈欢迎，也收到了很多社区的反馈，其中就有提到目前开源的组件太少。\n本次 SOFA 中间件将继续开源微服务体系下的几个组件：包括分布式链路追踪（SOFATracer）客户端、Metrics监控度量（SOFALookout）客户端、SOFARPC 的 Nodejs 版实现。同时还开源了 SOFABoot 下的模块化开发框架，以及 SOFARPC 的 HTTP/2 能力等。\n下面将逐一进行简单介绍。\nSOFATracer SOFATracer 是一个用于分布式系统调用跟踪的中间件，通过统一的 traceId 将调用链路中的各种网络调用信息以日志或者上报的方式记录下来，以达到透视化网络调用的目的。这些日志可用于故障的快速发现，数据统计，服务治理等。为了解决在实施大规模微服务架构时的链路跟踪问题，SOFATracer 基于 OpenTracing（http://opentracing.io） 规范并扩展其能力，包括基于 Disruptor 高性能无锁循环队列的异步落地磁盘的日志打印能力，自定义日志格式，日志自清除和滚动能力，基于 SLF4J MDC 的扩展能力，统一的配置能力等。同时 SOFATracer 也对接了开源生态，可以选择将 Tracer 数据对接到 Zipkin 等开源产品。\nSOFATracer 的 Github 的地址是：https://github.com/sofastack/sofa-tracer ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFALookout SOFALookout 是一个利用多维度的 Metrics 对目标系统进行度量和监控的中间件。Lookout 的多维度 Metrics 参考 Metrics 2.0（http://metrics20.org/spec） 标准，提供一整套 Metrics 的处理，包括数据埋点、收集、加工、存储与查询等。SOFALookout 包括客户端与服务器端服务两部分，本次先开源客户端部分，服务端部分代码在整理中。 SOFALookout 客户端提供了一套 Metrics API 标准，通过它可以方便地对 Java 应用的 Metrics 进行埋点统计。为了方便使用，SOFALookout 客户端默认提供一些扩展模块，它们提供 JVM，OS 等基本 Metrics 信息的统计，遵循该扩展机制，我们可以自定义或集成更多的 Metrics 数据。另外，SOFALookout 客户端除了支持向 SOFALookout 服务端上报数据外，还支持与社区主流的相关产品，包括 Dropwizard,（SpringBoot）Actuator 以及 Prometheus 等进行集成和数据适配。\nSOFALookout 的 Github 的地址是：https://github.com/sofastack/sofa-lookout ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nEggjs 集成 每种语言都有自己最擅长的领域，跨语言友好性对于分布式架构也是非常重要的。在蚂蚁内部还有一套 Nodejs 版本的 SOFA 中间件的实现，包含了绝大部分 Java 版本的功能，并将它们集成到已经开源的企业级 Nodejs 框架 Eggjs（https://eggjs.org） 中，形成了一套完整的 Web MVC 和 BFF (Backend For Frontend) 解决方案。这套架构目前广泛应用于蚂蚁的 Web 开发和多端适配等场景，让各岗位有了更清晰的职责划分，服务端（一般是 Java）提供基于领域模型的 RPC 接口，前端调用接口拿到数据后进行剪裁和格式化，并实现人机交互。领域模型与页面数据是两种思维模式，通过分层可以很好地解耦，让彼此更专业高效。后面我们也会陆续开源 SOFA 中间件的 Nodejs 版本实现，本期会先放出 SOFARPC 相关的两个模块：\nSOFARPC Node 的 Github 的地址是：https://github.com/sofastack/sofa-rpc-node ， SOFABolt Node 的 Github 的地址是：https://github.com/sofastack/sofa-bolt-node ， 欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFABoot 在最新的 SOFABoot 2.4.0 版本中，SOFABoot 新增加了基于 Spring 上下文隔离的模块化开发能力。在企业级应用场景，随着应用系统模块的增多，每个业务模块之间的耦合也会越来越严重，业务模块的自测更加复杂，团队之间的沟通成本增加。模块化开发是该问题的有效解决方案，但是 Spring Boot 默认不支持模块化开发，所有 Bean 共用一个 Spring 上下文。为此，SOFABoot 提出 SOFABoot 模块的概念，每个业务团队专注于开发自己的 SOFABoot 应用模块，模块自包含模块的代码和配置，拥有独立的 Spring 上下文，便于开发及自测，减少团队间的沟通成本。SOFABoot 模块间通信使用 JVM 服务进行通信，避免模块之间的耦合；如果远程服务在本地其它本地模块中存在，可优先调本地提高性能。同时 SOFABoot 提供了模块并行启动及 Bean 异步初始化能力，大幅提高应用启动速度。\nSOFABoot 的 Github 的地址是：https://github.com/sofastack/sofa-boot ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFARPC 在最新的 SOFARPC 5.4.0 版本中，SOFARPC 基于事件扩展机制，集成了 SOFATracer 和 SOFALookout 两个微服务体系产品，完善了自身的服务监控度量以及分布式跟踪功能。用户可以通过 SOFATracer 对接到 Zipkin 查看服务调用跟踪信息，也可以通过 SOFALookout 对接到 Prometheus 查看服务度量信息。新版本的 SOFARPC 中还增加了 HTTP/1.1 和 HTTP/2 协议的支持，在跨语言等场景下可以快速通过标准的 HTTP 协议进行通信。SOFARPC 也与 Eggjs 进行了打通了 Bolt 协议，方面用户在 Java 和 Nodejs 之间高效通信。\nSOFARPC 的 Github 的地址 …","date":1527761554,"description":"本次 SOFA 中间件将继续开源微服务体系下的几个组件：包括分布式链路追踪（SOFATracer）客户端、Metrics监控度量（SOFALookout）客户端、SOFARPC 的 Nodejs 版实现。同时还开源了 SOFABoot 下的模块化开发框架，以及 SOFARPC 的 HTTP/2 能力等。","dir":"blog/sofastack-open-source-doubles/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"00f2a1c85bfe83bf9f25ef1af9c44366","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-open-source-doubles/","publishdate":"2018-05-31T10:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-open-source-doubles/","summary":"蚂蚁金服自主研发的分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件），包含了构建金融级云原生架构所需的各个组件，","tags":["SOFAStack"],"title":"蚂蚁金服分布式中间件开源第二弹：丰富微服务架构体系","type":"blog","url":"/sofastack.tech/blog/sofastack-open-source-doubles/","wordcount":2957},{"author":"善逝","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力。蚂蚁金服内部丰富的实践场景表明，类隔离能力对解决类冲突、版本管控有其特殊的优势。\nSOFABoot 的类隔离能力由单独的组件 SOFAArk 实现，相比业界遵循 OSGi（https://www.osgi.org/） 规范的 Equinox 或者 Felix，SOFAArk 专注于类隔离，简化了类加载模型，是一款更加轻量的类隔离框架。\n本文将介绍 SOFABoot 类隔离能力的背景及其使用方式。\n1. 背景 在 Java 世界中，依赖的 JAR 包之间相互冲突永远是一个痛，Spring Boot 采用统一的依赖管理机制规避了大部分依赖冲突问题。理想很美好，现实却很骨感，作为蚂蚁金服这类大体量的公司，各业务线纷繁复杂、基础服务组件繁多，很难做到对所有 JAR 包做统一管控，尤其涉及到多个跨团队模块组件相互依赖时，因为各自技术栈历史包袱的存在，难以有效统一冲突包版本。\n假设如下场景，工程需要引入两个三方组件：A 和 B，组件 A 需要依赖 Hessian 3，组件 B 需要依赖 Hessian 4，因为 Hessian 3 和 Hessian 4 是不兼容的。作为开发者，遇到这种包冲突问题，如果不借助类隔离框架，只能耗费精力升级到统一版本。\n为了彻底解决类似的包冲突问题，我们需要借助类隔离机制，使用不同的类加载器加载冲突的三方依赖包，进而做到在同一个应用运行时共存。\n基于此背景，SOFABoot 提供了一个轻量级的类隔离框架，也是本文的主角，SOFAArk。\n2. 基本原理 在介绍 SOFAArk 类隔离框架使用之前，我们简单了解下其背后的实现原理。正如前文中描述，SOFAArk 是通过独立的类加载器加载相互冲突的三方依赖包，从而做到隔离包冲突。那么我们不禁要问，SOFAArk 是如何区分应用中哪些依赖包是需要单独的类加载器加载呢？原因是 Ark Plugin，它是 SOFAArk 框架定义的一种特殊的 JAR 包文件格式，SOFAArk 框架会自动识别 Ark Plugin 这种特殊依赖。\n何为 Ark Plugin ? Ark Plugin 本质上是一个 FatJar，借助 SOFABoot 官方提供的 maven 打包插件，开发者可以把若干普通的 JAR 包打包成 Ark Plugin 供应用依赖或者把普通的 Java 模块改造成 Ark Plugin。通常来说，如果把一个普通 JAR 打包成 Ark Plugin，那么该 JAR 包依赖的其他三方包也会被打入同一个 Ark Plugin，默认情况下 SOFABoot 官方打包插件会自动把间接依赖也打入到 Ark Plugin。\n应用使用添加 maven 依赖的方式引入 Ark Plugin，运行时，SOFAArk 框架会自动识别应用的三方依赖包中是否含有 Ark Plugin，进而使用单独的类加载器加载。为了更加直观，下图是应用运行时逻辑分层图：\n可以看到，在应用运行时，SOFAArk 容器处于最底层，负责启动应用。应用依赖的所有 Ark Plugin 处于中间层，每个 Ark Plugin 都由 SOFAArk 容器使用独立的类加载器加载，相互隔离。应用业务代码及其他非 Ark Plugin 的普通三方依赖包，为了描述简单，统称为 Ark Biz，它运行在最上层，需要依赖中间层的 Ark Plugin。\n一个标准 Ark Plugin 会包含一些配置文件，主要包含导出类和导入类配置。导出类即把 Ark Plugin 中的类导出给 Ark Biz 和其他 Ark Plugin 可见。默认情况下，所有 Ark Plugin 的导出类对于 Ark Biz 来说都是可见的，即 Ark Biz 可以使用 Ark Plugin 的导出类。对于 Ark Plugin 来说，如果需要使用其他 Ark Plugin 的导出类，必须声明为自身的导入类。关于 Ark Plugin 详细说明可以参考文末相关链接。\n下面我们来演示如何开发一个简单的 Ark Plugin。\n3. Java 模块改造成 Ark Plugin 3.1 新建工程 Demo 工程参见：https://github.com/QilongZhang/ark-plugin-demo\n运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，并创建三个普通的 Java 模块。以前文描述的 Hessian 冲突为例，在演示工程中定义了三个模快：\n pojo-module: 定义了一个简单的 PoJo 类 SamplePoJo，并设置为导出类，打包成 pojo-ark-plugin 。 hessian3-module：定义了一个服务类 Hessian3Service，实现了简单的序列化和反序列逻辑，使用的版本是 Hessian 3，并导入了 SamplePoJo，打包成 hessian3-ark-plugin 。 hessian4-module：定义了一个服务类 Hessian4Service，和 Hessian3Service 功能类似，使用的版本是 Hessian 4，并导入了 SamplePoJo，打包成 hessian4-ark-plugin 。 该用例是为了演示如何将普通的 Java 模块及其三方依赖包打包成 Ark Plugin，以 hessian3-module 模块为例来讲解打包流程。\n3.2 编写服务类 在 hessian3-module 中，提供了一个简单的序列化和反序列化功能类 Hessian3Service：\npackage com.alipay.sofa.demo.hessian3; import com.caucho.hessian.io.HessianInput; import com.caucho.hessian.io.HessianOutput; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; /** * @author qilong.zql */ public class Hessian3Service { public byte[] serialize(Object obj) throws IOException { if(obj==null) throw new NullPointerException(); ByteArrayOutputStream os = new ByteArrayOutputStream(); HessianOutput ho = new HessianOutput(os); ho.writeObject(obj); return os.toByteArray(); } public Object deserialize(byte[] by) throws …","date":1526465554,"description":"本文将介绍 SOFABoot 类隔离能力的背景及其使用方式。","dir":"blog/spring-boot-sofa-boot-class-isolation-integration/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c22dd2791732b32177419ff678b34546","permalink":"https://sofastack.github.io/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","publishdate":"2018-05-16T10:12:34Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力。蚂蚁金服内部丰富的实践场景表明，类隔离能力对解决","tags":["SOFABoot","SpringBoot","SOFAArk"],"title":"在 Spring Boot 中集成 SOFABoot 类隔离能力","type":"blog","url":"/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","wordcount":3524},{"author":"绍辉","categories":"Seata","content":" 上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。\nSeata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。项目地址：https://github.com/seata/seata\n蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n为了帮助大家理解，分布式事务开源负责人绍辉进行了一次线下分享，详细讲述了分布式事务在蚂蚁金服的发展，希望可以帮助大家理解分布式事务，以下为分享的文字整理版本。\n前言 今天的分享将从以下三个部分展开：分布式事务问题产生的背景、蚂蚁金服分布式事务以及分布式事务 Seata 的 Roadmap。\n分享嘉宾：绍辉 蚂蚁金服 分布式事务开源负责人\n1、分布式事务问题产生的背景 1.1、数据库的水平拆分 蚂蚁金服早期，业务量比较小，单库单表便能满足业务需求；但是随着业务的发展，单库单表数据库逐渐成为瓶颈。为了解决数据库的瓶颈问题，我们对数据库进行了水平拆分。拆分所带来的一个问题就是以前一个数据库上便能完成的写操作现在要跨多个数据库，由此带来了跨库事务问题。\n1.2、业务的服务化拆分 蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个 APP 中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，由此产生了跨服务事务问题。\n1.3、转账案例说明数据一致性问题 数据库的水分拆分以及服务的垂直拆分，所带来的问题是一个业务活动通常要调用多个服务、访问多个数据库才能完成。\n以金融业务场景下的转账场景为例，转账服务要完成以下操作：\n 调用交易系统服务创建交易订单； 调用支付系统记录支付明细； 调用账务系统执行 A 扣钱； 调用账务系统执行 B 加钱。 以上 4 个操作要跨 3 个系统，访问 4 个数据库。而网络、数据库、机器等都具有不可靠性，我们很难保证以上 4 个操作能 100% 全部成功。\n在金融属性的业务中，不允许 A 账户的钱扣了，而 B 账户的钱没有加上的现象出现，所以我们必须想办法保证 1 ~ 4 这四个操作要么全部成功，要么全部失败；所以蚂蚁金服自主研发了分布式事务中间件，解决跨服务、跨数据库的数据一致性问题。\n2、蚂蚁金服分布式事务 2.1、分布式事务理论基础 在介绍蚂蚁金服的分布式事务中间件之前，先介绍一些分布式事务的理论背景。\n 2PC 两阶段提交协议（Two Phase Commitment Protocol）是分布式事务最基本的协议。在两阶段提交协议中，有一个事务管理器和多个资源管理器，事务管理器分两阶段协调资源管理器。在第一阶段，事务管理器询问所有资源管理器准备是否成功。如果所有资源均准备成功，那么在第二阶段事务管理器会要求所有资源管理器执行提交操作；如果任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求所有资源管理器在第二阶段执行回滚操作。通过事务管理器的两阶段协调，最终所有资源管理器要么全部提交，要么全部回滚，最终状态都是一致的。\n TCC 资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现。TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题。TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中。事务管理器分两个阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法，最终所有 TCC 服务要么全部都是提交的、要么全部都是回滚的。\n2.2、蚂蚁金服分布式产品介绍 蚂蚁金服从 2007 年开始做分布式事务，至今已经有 12 年历史。蚂蚁金服的分布式事务最初是采用 TCC 实现的，TCC 模式帮蚂蚁业务解决了各类金融核心场景下的数据一致性问题。\n2007 年我们开始支持双十一，为了满足双十一的高性能需求，我们对分布式事务做了一系列的性能优化。\n2013年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014年，蚂蚁金服分布式事务中间件开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户；在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。\n所以在 2015年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务中间件经过长期演进，目前积累了 TCC、FMT 和 XA 三种模式，具有丰富的应用场景。下面分别介绍这三种模式。\n2.3、TCC 模式 蚂蚁金服的 TCC 模式和前面介绍 TCC 理论中提的 TCC 原理是一致的。不同的是，我们在整个分布式事务执行过程中，会去记录事务日志，一个分布式事务会产生一条主事务记录（对应发起方）和若干分支事务记录（对应 TCC 参与者）。记录事务日志的目的是，当分布式事务执行过程中出现异常中断时，事务恢复服务通过轮询事务日志，找出这个异常中断的事务，补偿执行该异常事务剩余未完成的动作，整个分布式事务的最终状态要么全部提交，要么全部回滚。\nTCC 设计规范和注意事项：\n用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。经过蚂蚁金服多年的 TCC 应用实践，总结如下在 TCC 设计和实现过程中的注意事项：\n1、业务操作分两阶段完成： 接入 TCC 前，业务操作只需要一步就能完成。但是在接入 TCC 之后，需要考虑如何将其分成两个阶段完成：把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户 A 的余额中有 100 元，需要扣除其中 30 元”。\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成两步完成：\n Try 操作：资源的检查和预留。 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交。 在扣款场景下，Confirm 阶段做的事 …","date":1526465554,"description":"上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。","dir":"blog/seata-distributed-transaction-open-source/","fuzzywordcount":5000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"acb90bbbf0e7ec7dfb8c797bbd94efee","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-distributed-transaction-open-source/","publishdate":"2018-05-16T10:12:34Z","readingtime":10,"relpermalink":"/sofastack.tech/blog/seata-distributed-transaction-open-source/","summary":"上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式","tags":["Seata"],"title":"蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/seata-distributed-transaction-open-source/","wordcount":4977},{"author":"鲁直","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 的健康检查的基础上，加上了 Readiness Check 的能力，以更好地适应大规模金融级的服务化场景，防止在应用启动有问题的情况下让外部流量进入应用。在本文中，我们将通过 Kubernetes 来演示 SOFABoot 的 Readiness Check 的能力，主要涉及到两个部分的能力的演示：\n SOFABoot 的 Readiness Check 失败之后，SOFABoot 不会将发布的 RPC 服务的地址注册到 ZooKeeper 上面，防止 RPC 的流量进入。 Kubernetes 通过 http://localhost:8080/health/readiness 访问到 SOFABoot 的 Readiness 检查的结果之后，不会将 Pod 挂到对应的 Service 之上，防止 Kubernetes 上的流量进入。 准备一个 Kubernetes 的环境 为了演示在 Kubernetes 中使用 SOFABoot 的 Readiness Check 的能力，首先需要准备好一个 Kubernetes 的环境，在这个例子中，我们直接选择在本机安装一个 minikube，minikube 是 Kubernetes 为了方便研发人员在自己的研发机器上尝试 Kubernetes 而准备的一个工具，对于学习 Kubernetes 的使用非常方便。关于如何在本机安装 minikube，大家参考这个官方的安装教程即可。\n安装完成以后，大家可以直接终端中使用 minikube start来启动 minikube。\n需要注意的是，由于国内网络环境的问题，直接用 minikube start 可能会无法启动 minikube，如果遇到无法启动 minikube 的问题，可以尝试加上代理的设置，大家可以参考以下的命令来设置代理服务器的地址：\nminikube start --docker-env HTTP_PROXY=http://xxx.xxx.xxx.xxx:6152 --docker-env HTTPS_PROXY=http://xxx.xxx.xxx.xxx:6152 在 Kubernetes 上安装一个 ZooKeeper 在准备好了 Kubernetes 的环境之后，我们接下来需要在 Kubernetes 上安装一个 ZooKeeper 作为 SOFARPC 的服务自动发现的组件。首先我们需要有一个 ZooKeeper 的 Deployment：\napiVersion: apps/v1beta1 kind: Deployment metadata: name: zookeeper-deployment labels: app: zookeeper spec: replicas: 1 selector: matchLabels: app: zookeeper template: metadata: labels: app: zookeeper spec: containers: - name: zookeeper image: zookeeper imagePullPolicy: IfNotPresent ports: - containerPort: 2181 这个 Deployment 会部署一个 ZooKeeper 的实例，并且将 2181 端口暴露出来。\n有了这个 YAML 文件之后，我们再部署一个 Service 来作为 ZooKeeper 的负载均衡，这样我们在应用中就可以直接通过域名来访问，而不用 IP 来访问 ZooKeeper 了。这个 Service 的 Yaml 文件如下：\napiVersion: v1 kind: Service metadata: name: zookeeper-service spec: selector: app: zookeeper ports: - protocol: TCP port: 2181 targetPort: 2181 这个 Service 直接将 2181 端口映射到 ZooKeeper 的 2181 端口上，这样，我们就可以在应用中直接通过 zookeeper-service:2181 来访问了。\n准备一个 SOFABoot 的应用 在前面的两步都 OK 之后，我们需要准备好一个 SOFABoot 的应用，并且在这个应用中发布一个 SOFARPC 的服务。首先，我们需要从 start.spring.io 上生成一个工程，例如 GroupId 设置为 com.alipay.sofa，ArtifactId 设置为 rpcserver。\n生成好了之后，接下来，我们需要把 SOFABoot 的依赖加上，将 pom.xml 中的 parent 修改成：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 然后，增加一个 SOFARPC 的 Starter 的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 接着，在 application.properties 里面加上我们的配置，包括应用名和 ZooKeeper 的地址：\n# Application Name spring.application.name=SOFABoot Demo # ZooKeeper 的地址 com.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 上面的事情准备好之后，我们可以在应用中发布一个服务，首先，我们需要分别声明好一个接口和一个实现：\npackage com.alipay.sofa.rpcserver; public interface SampleService { String hello(); } package com.alipay.sofa.rpcserver; public class SampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } 接下来，将这个接口和实现发布成一个 SOFARPC 的服务，我们可以新建一个 src/main/resources/spring/rpc-server.xml 的文件：\n\u0026amp;lt;?xml …","date":1525428754,"description":"在本文中，我们将通过 Kubernetes 来演示 SOFABoot 的 Readiness Check 的能力。","dir":"blog/sofa-boot-readiness-check-in-kubernetes/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4018d6494df0e7ecde1c4911610fc89c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","publishdate":"2018-05-04T10:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 的健康检查的基础上，加上了 Readiness Check 的能力，以更好地适应大规模金融级的服务化场景，防止","tags":["SOFABoot","Kubernetes"],"title":"在 Kubernetes 中使用 SOFABoot 的 Readiness Check 能力","type":"blog","url":"/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","wordcount":2732},{"author":"余淮","categories":"SOFARPC","content":" SOFARPC 是近期蚂蚁金服开源的一个高可扩展性、高性能、生产级的 Java RPC 框架。在蚂蚁金服 SOFARPC 已经经历了十多年及五代版本的发展。SOFARPC 致力于简化应用之间的 RPC 调用，为应用提供方便透明、稳定高效的点对点远程服务调用方案。为了用户和开发者方便的进行功能扩展，SOFARPC 提供了丰富的模型抽象和可扩展接口，包括过滤器、路由、负载均衡等等。\nSOFARPC 可以集成多种注册中心实现，其中一种就是常用的 ZooKeeper。\nZooKeeper 作为一个开源的分布式应用协调系统，已经用到了许多分布式项目中，用来完成统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等工作。\n本文将介绍 SOFARPC 是使用 ZooKeeper 作为注册中心的用法。\n1. ZooKeeper 注册中心安装 这里介绍下 Zookeeper 单机模式两种安装方式，集群模式请参考下其他文档。\n1.1 基于压缩包安装 第一步：去官网下载 http://zookeeper.apache.org/releases.html#download 例如目前最新版是 v3.4.11，我们下载压缩包zookeeper-3.4.11.tar.gz，然后解压到文件夹下，例如 /home/admin/zookeeper-3.4.11。\n第二步：设置配置文件，可以直接从样例复制一份。\n$ cd /home/admin/zookeeper-3.4.11 $ cp conf/zoo_sample.cfg conf/zoo.cfg 第三步：到 Zookeeper 安装目录下直接启动Zookeeper。\n$ cd /home/admin/zookeeper-3.4.11 $ sh bin/zkServer.sh start ZooKeeper JMX enabled by default Using config: /Users/zhanggeng/dev/zookeeper/bin/../conf/zoo.cfg -n Starting zookeeper ... STARTED 第四步：我们使用四字命令检查下。\n$ echo stat | nc 127.0.0.1 2181 Zookeeper version: 3.4.11-37e277162d567b55a07d1755f0b31c32e93c01a0, built on 11/01/2017 18:06 GMT ... 第五步：如果需要查看数据，直接运行 zkCli.sh，连接后执行 ls /即可。\n$ sh bin/zkCli.sh Connecting to localhost:2181 ...... WatchedEvent state:SyncConnected type:None path:null [zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] 1.2 基于 Docker 安装 如果您已安装了 Docker，那么可以选择使用镜像启动 Zookeeper。\n$ docker image pull zookeeper:3.4.11 $ docker run -i -t --name my_zookeeper -p2181:2181 -d zookeeper:3.4.11 我们查看下启动日志：\n$ docker logs -f my_zookeeper ZooKeeper JMX enabled by default Using config: /conf/zoo.cfg 2018-04-16 07:38:59,373 [myid:] - INFO [main:QuorumPeerConfig@136] - Reading configuration from: /conf/zoo.cfg ...... 2018-04-16 07:23:41,187 [myid:] - INFO [main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:2181 可以看到端口已经启动并发布，我们使用四字命令检查下。\n$ echo stat | nc 127.0.0.1 2181 Zookeeper version: 3.4.11-37e277162d567b55a07d1755f0b31c32e93c01a0, built on 11/01/2017 18:06 GMT ... 我们可以查看启动的容器运行状态、关闭、重启，参考命令如下：\n$ docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 30b13a744254 zookeeper:3.4.11 \u0026amp;quot;/docker-entrypoin...\u0026amp;quot; 23 hours ago Up 42 seconds 2888/tcp, 0.0.0.0:2181-\u0026amp;gt;2181/tcp, 3888/tcp my_zookeeper ## 关闭重启的话 $ docker container stop 30b13a744254 $ docker container start 30b13a744254 如果需要使用 ZooKeeper 客户端查看查看数据，参考命令如下：\n$ docker exec -it 30b13a744254 zkCli.sh Connecting to localhost:2181 ...... WatchedEvent state:SyncConnected type:None path:null [zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] 2. SOFARPC 集成 Zookeeper 注册中心 Demo 工程参见: sofa-rpc-zookeeper-demo\n2.1 新建工程 运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，然后在 pom.xml 中引入如下 RPC 和 Zookeeper 相关依赖：\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.3.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.curator\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;curator-recipes\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.9.1\u0026amp;lt;/version\u0026amp;gt; …","date":1524737554,"description":"本文是 SOFARPC 集成 Zookeeper 的介绍。","dir":"blog/sofa-rpc-zookeeper-integriation/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"34d9ac266c4b2a95cc924705212d2eb0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","publishdate":"2018-04-26T10:12:34Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","summary":"SOFARPC 是近期蚂蚁金服开源的一个高可扩展性、高性能、生产级的 Java RPC 框架。在蚂蚁金服 SOFARPC 已经经历了十多年及五代版本的发展。SOFARPC 致力于简化应用之","tags":["SOFARPC"],"title":"SOFARPC 集成 Zookeeper 注册中心","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","wordcount":2367},{"author":"蚂蚁中间件","categories":"SOFAStack","content":" 我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！\nSOFA 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服期望通过逐步向社区开源 SOFA 中各个组件，来帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，也期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固，并具备更多金融级的属性。所以我们也非常欢迎社区的伙伴和各行业的伙伴能够参与共同探讨、交流和共建。\nWhy（为什么要做） SOFA 中间件在蚂蚁内部经历了十年的发展和四代架构的演进，被广泛应用在包括支付，借贷，信用，基金，保险等全金融场景，支撑着蚂蚁平稳度过历次双十一，双十二，新春红包等大考，创造了25.6 w/s 的交易记录，并还在不断刷新这个记录。\n从 2015 年开始，蚂蚁金服开启了金融科技对外输出的战略，SOFA 也走出了蚂蚁，甚至跨越了国界，被更多金融机构与合作伙伴所使用，如天弘基金，信美互信，南京银行，PayTM、DANA钱包等。\n在与合作伙伴以及客户的沟通、合作过程中，我们发现了 SOFA 的理念和能力也正是很多金融行业的企业所需要的，大家或多或少正在规划或者已经在做类似的东西，但缺乏像蚂蚁金服这么大的流量来提供考验，也缺乏专业团队的长期投入，更缺乏丰富的金融场景和严苛的业务压力来驱动技术持续发展。\n随着近几年蚂蚁金服在生态构建上不断完善，以及不断地有更多的公司加入到蚂蚁金服的金融生态中，我们也发现了整个金融生态地复杂性和多样性，SOFA 中间件也需要在更多地场景下被打磨、被完善、被增强。因此，我们选择将 SOFA 逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\nHow（怎么做） 为了让 SOFA 能够开源出来，我们投入了大量的重构工作，以可扩展化的方式来层层构建 SOFA 的能力，保证 SOFA 的内部版本和开源的版本采用的是同一个内核。所以 SOFA 的内部版本就是在开源版本之上扩展了内部逻辑和历史版本的兼容逻辑。开源版本的核心逻辑，内外是一致的，并在蚂蚁金服的生产环境中被广泛使用的，同时会随着蚂蚁自身业务诉求的驱动，不断的演进。\n开源社区有非常多优秀的技术和丰富的生态，为了更好的能融入和对接现有技术体系，尊重并遵守一些社区标准，SOFA 在设计过程中就充分考虑了兼容性和架构分层，充分兼容适配社区标准，实现组件化、可扩展、可替换。\n所有的 SOFA 中间件中的组件组合起来可以发挥更大的能力，但是每一个组件都是可以被替换的，比如用户可以选择用 Dubbo 来替换 SOFARPC，或者跟 SOFARPC 对接互通；可以选择 Zookeeper 来作为服务注册发现，也可以选择 SOFA 的服务注册中心来做服务发现；分布式链路追踪组件遵守 OpenTracing 的规范，可以直接和 Zipkin 进行对接等等；Metrics组件会遵循 Metrics2.0 标准，适配 Prometheus 体系等等。\nWhat（要做什么） 本次 SOFA 中间件开源的内容包含了 SOFABoot 和 SOFARPC 两个组件。\nSOFABoot 是蚂蚁金服基于 Spring Boot 构建一个研发框架，整体架构上类似于蚂蚁金服之前开源的Egg框架，遵守微内核，可插拔的理念，我们以标准 Spring Boot Starter的方式，扩展了很多企业级特性，以解决大规模团队开发云原生微服务系统中会遇到的问题，如类隔离，ReadinessCheck，日志隔离等等能力，后续会开放更多内部实践过的特性，如 Spring 上下文隔离，合并部署，动态模块，Tracing、Metrics、Streaming、测试框架等。\n同时，蚂蚁的很多技术团队和阿里的技术团队也开放了很多类库和组件，我们都会提供原生的集成能力和 Demo，方便大家更好的整合使用。SOFABoot 100% 兼容 Spring Boot，和 Spring Boot 并非是替代的关系，所有 Spring Boot 中的能力也都可以在 SOFABoot 中使用。\nSOFABoot 的 Github 的地址是：https://github.com/sofastack/sofa-boot ，欢迎大家使用反馈、贡献代码。\nSOFARPC 是一个高效，可靠，可扩展的 RPC 的框架，是蚂蚁金服服务化架构的基石。SOFARPC 最早源于阿里内部的 HSF，经过了蚂蚁金服内部多年的发展，在协议，网络，路由，可扩展性等层面都进行了大量的改造和优化的工作，适配了更多金融级的场景。\nSOFARPC 在蚂蚁金服内部是被所有在线应用的使用的服务调用框架，截止 2017 年双十一，SOFARPC 已经被蚂蚁 2000 多个系统所使用，生产环境发布的服务数量超过了 23000 个。\nSOFARPC 提供了多协议的支持，包括在蚂蚁金服内部被广泛采用，并且高度优化的 Bolt 协议，以及 REST，Dubbo，gRPC 等等主流的协议；也针对内部网关，测试等等场景提供了泛化调用能力；为了解决超大规模流量的预热的问题，提供了服务预热的能力；用户也可以根据 SOFARPC 的扩展机制扩展自己需要的能力。\n在后续的版本中，SOFARPC 将会加上分布式链路追踪，Metrics，更多的服务注册中心的支持，CRC 校验等等能力。\nSOFARPC 的 Github 的地址是：https://github.com/sofastack/sofa-rpc ，欢迎大家使用反馈、贡献代码。\n除了以上的两个 SOFA 中间件中的组件，在接下来，我们将会陆续开源 SOFA 中间件中的其他的组件，目前这些组件正在进行一定程度地重构中，为开源做准备，敬请大家期待~\n附本文中提到的链接：\n Egg：http://eggjs.org SOFABoot：https://github.com/sofastack/sofa-boot SOFARPC：https://github.com/sofastack/sofa-rpc SOFABolt：https://github.com/sofastack/sofa-bolt 彩蛋 最后，我们也为对 SOFA 中间件感兴趣的小伙伴们准备了一个微信交流群，欢迎感兴趣的同学扫描下方二维码联系加群小助手加入我们 SOFA 交流群哦。👇\n","date":1524147739,"description":"我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！","dir":"blog/announcing-sofastack-open-source/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6019b0e0f6e4c9569640bcdb51b5a157","permalink":"https://sofastack.github.io/sofastack.tech/blog/announcing-sofastack-open-source/","publishdate":"2018-04-19T14:22:19Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/announcing-sofastack-open-source/","summary":"我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！ SOFA 是蚂蚁金服自主","tags":["开源"],"title":"蚂蚁金服启动分布式中间件开源计划，用于快速构建金融级云原生架构","type":"blog","url":"/sofastack.tech/blog/announcing-sofastack-open-source/","wordcount":2479},{"author":"程立","categories":"SOFAStack","content":" 声明：本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创，经谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。\n移动互联网、大数据与云计算作为新的基础设施，催生了新的互联网经济，也正在推动各行各业的升级。在过去十多年中，金融服务飞速发展，移动支付支撑了零售业线上线下的变革，基于大数据的信贷服务支持了无数小微企业的创业创新，老百姓可以随时随地享受曾经高门槛的理财、保险等金融服务。以普惠服务为目标、数据与技术驱动、新型信用体系为基础的新金融已经成为新经济的基石。\n伴随着蚂蚁金服在新金融领域的探索，蚂蚁金服技术团队也在金融技术与架构领域不断开拓。从 2005 年每秒处理 1 笔交易到 2015 年双十一每秒处理 8.59 万笔交易，从单一的支付到覆盖微贷、理财、保险、信用、银行等，通过十多年的探索与实践，我们形成了一套包含金融级分布式交易、分布式大数据分析与决策等在内的完整架构与技术体系。\n在本文中，我们将与大家交流金融级分布式交易相关的实践与体会。\n金融级系统的关键目标 如果将建造系统比作盖楼的话，建一个常规的系统要先立稳四根柱子：高可用、安全、性能、成本。但要建一个移动互联网时代的金融级大厦，除了上述四根柱子需要更加牢固，还需要加上两根柱子：资金安全与数据质量。这六根柱子，是我们在架构蚂蚁金服的每一个系统时的首要目标。\n具体来说，我们对一个金融级系统有以下关键目标：\n高可用：具备 99.99% 以上的高可用性。系统能够容忍各种软硬件设施的故障，可以在服务不中断的情况下进行升级，在严苛的应用场景下保证承诺的服务质量，容忍各种人为失误。对于关键系统，还需要具备异地容灾能力。\n安全：具备多层次检测、感知与防御各类安全攻击的能力。系统有能力实时、精细地分析系统行为与数据流发现异常，必要时可以快速调集资源阻断大规模、有组织的攻击。\n性能：对于实时交易业务，要求极快的响应时间与极高并发能力。对于批量业务，要求极大的吞吐量。尤其重要的是，系统必须具备很强的可伸缩性与弹性，在需要时可以快速调集资源应对突发的业务量。\n成本：在满足高可用、安全与性能的前提下，成本是一个重要约束。我们将单笔交易的平均处理成本（月交易总笔数/月成本）、以及峰值交易的处理成本（每提升 1000 交易 TPS 需要追加的成本）作为两个关键指标去持续优化。除了必须在基础软硬件与系统关键链路上做极致的优化外，灵活的资源调度与按需伸缩能力是优化成本的关键。\n资金安全：这是金融级系统与常规系统的一个关键差异。要做到资金处理绝对不出差错，需要交易与数据具备强一致性，需要在任何故障场景数据不丢不错，需要具备准实时的交易资金核对能力，需要在异常场景下有精细化熔断与快速恢复能力。\n数据质量：数据质量是金融服务质量的基础。数据从采集、生成、流转、存储、计算、使用需要经历很多环节，要确保经过这么多环节后，数据依然是准确、完整和及时的，需要系统具备全链路的数据质量管控与治理能力。\n金融交易系统是否可以走分布式路线？如何基于分布式的思想与技术达到以上 6 个关键目标？接下来，我们就以蚂蚁金服的实践为基础，分享对这个问题的观点。\n分布式金融交易架构与技术 1 强一致的微服务：微交易架构 微服务是一种广泛应用的分布式架构。通过将系统分解为单一职责、高内聚、松耦合、独立部署、自主运行的“微“服务，可以极大提升系统的灵活性与扩展能力。但由于每一个微服务是自包含的数据与计算单元，当一个有严格一致性要求的交易，被分布在很多节点上执行时，如何保证数据与服务处理达到金融级的强一致性，成为一个难题。尽管可以用支持分布式事务的数据库或数据中间件来保证数据分布时的一致性，但解决不了当服务分布时的一致性问题。由于分布式事务对资源加锁的时间长、粒度大，也制约了系统的可伸缩性与高可用性。\n为了解决这个难题，我们提出一种使微服务具备强一致性的微交易架构。在这种架构中，涉及到交易操作的微服务具备事务属性。一个微交易提供三种操作TCC（Try-Confirm-Cancel），其中 Try 操作负责业务检查与资源预留，Confirm 操作负责实际操作，Cancel 操作负责释放预留的资源。一次完整的交易由一系列微交易的 Try 操作组成，如果所有的 Try 操作都成功，最终由微交易框架来统一Confirm，否则统一 Cancel，从而实现了类似经典两阶段提交协议（2PC）的强一致性。但不同于 2PC，微交易架构力求高效与可伸缩。TCC 三个操作都是基于本地事务的短事务，Try 操作只预留必须的业务资源，比如一笔交易涉及10元钱，仅预留账户中的 10 元钱，而不是锁定整个账户，TCC 协议在提交时，也没有单独的 Prepare 阶段，将提交协议的成本降到最低。\n从 2008 年初上线至今，微交易架构已经应用到蚂蚁金服的各种金融业务场景，经历过历次大促高峰考验，证明这套架构与技术的可行性。\n2 金融级分布式数据库: OceanBase 目前，主要商业数据库本质上是单机系统，其容量、性能和可靠性均依赖于单个或少量高性能服务器与高可靠存储的组合，成本高昂且扩展困难。尽管通过运用微交易架构，可以将对数据操作的压力分拆多个数据库，解决了水平可扩展的问题，但数据库本身的性能、成本与可靠性依然是一个难点。因此，阿里巴巴与蚂蚁金服从 2010 年起，开始研发专门的金融级分布式数据库 OceanBase。\nOceanBase 在以下几个方面，对传统数据库架构进行了突破：\n高性能：数据库的一个显著特征是总数量比较大，但每天变化(增删改)的数据只是总数据量的很小一部分。因此 OceanBase 将数据划分为基线数据和修改增量。基线数据即数据库在某个时间点的一个快照，存放在每台 OceanBase 服务器的硬盘中，修改增量即快照点之后的增删改数据，相对比较小，通常存放在每台 OceanBase 服务器的内存中。通过这种方式，使得增删改操作基本都在内存中进行，从而获得接近内存数据库的事务处理性能；\n强一致：经典的主库+备库方式的数据库，很难兼具高可用与强一致能力。为了解决这个问题，OceanBase 使用多数据副本（\u0026amp;gt;=3）投票协议，对于每个写事务，OceanBase 只有在事务日志（redo log）到达超过半数服务器后，才应答客户。这样当少数服务器（例如 3 台中的 1 台，或者 5 台中的 2 台）异常时，剩下的服务器至少有一台有事务日志，保证了数据库不因为少数服务器故障而导致数据丢失；\n高可用：关键业务的数据库必须达到 99.999% 的可用性，服务器故障、机房或网络故障都不能导致数据库不可用。OceanBase 通常由分布于多个机房（3 个或以上）的机群组成，每个机群有完整数据，其中一个机群作为主库对外提供读写服务，其余机群作为备库，接收主库的事务日志和回放日志。当主库故障时，剩下的机群会立刻自动发起投票选举，选出新的主库，新主库从其他机群获得可能存在的最新事务日志并回放，完成后对外提供服务。\n目前 OceanBase 已经稳定支撑了支付宝的核心交易、支付与账务，支撑了网商银行的核心系统，经历了多次“双十一”的考验，形成了跨机房、跨区域部署的高可用架构，并在日常运行、应急 …","date":1520578800,"description":"本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创。","dir":"blog/technical-financial-distributed-trading/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e6da780e4d5f611c48ac55795531fb2c","permalink":"https://sofastack.github.io/sofastack.tech/blog/technical-financial-distributed-trading/","publishdate":"2018-03-09T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/technical-financial-distributed-trading/","summary":"声明：本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创，经谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。","tags":["SOFAStack"],"title":"金融级分布式交易的技术路径","type":"blog","url":"/sofastack.tech/blog/technical-financial-distributed-trading/","wordcount":4822},{"author":null,"categories":null,"content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。 本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同； - 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。\n平台工程旨在帮助企业构建面向应用研发者的自服务运维体系，尝试通过工程化的技术手段和工作流程解决以下关键问题：\n- 设计合理的抽象层次，帮助应用研发者降低对 Infra 、platform 等技术以及运维、稳定性工作的认知负担；\n- 为应用研发者提供统一的工作界面和空间，避免用户陷入割裂的平台产品界面、复杂的工作流中；\n- 帮助研发者通过有效的工作流程和推荐路径基于 内部工程平台[4] 快速开展工作；\n- 帮助研发者通过配套的 CI 、CD 、CDRA 等产品自服务管理应用生命周期；\n- 帮助平台产品研发团队简单、高效、一致的开放其平台基础能力；\n- 通过培训、布道、运营等手段营造协同工作和分享的文化。\n事实上，不是所有人都应该或者能够成为这个领域的专家，这非常困难！\n实际上平台技术团队的专家通常也仅擅长自己的专业领域而已，特别是在云原生理念和技术广泛应用的今天，面向大量高度开放、可配置的平台技术带来的成百上千的应用配置，PaaS 领域的业务复杂性，以及高稳定性和统一治理的要求，而平台工程的目的正是为了让应用研发者尽可能简单无痛的参与到这样规模化的 DevOps 工作中。\n在蚂蚁的实践中，我们更趋向于以下这种合作状态，在团队架构和工作模式上更靠近 Google 的最佳实践。平台研发者及 SRE 成为 “ Enabler ” 支持应用研发者自服务的完成研发及交付运维，同时应用研发者使其应用可交付运维的工作结果也成为运维人员可以接手应用运维工作的基础。最终 SRE 、应用研发及运维人员把工作过程中的问题和痛点反馈给平台研发者形成正向循环。\n三、专用语言：工程化方式的一极 有什么比一种专用语言更适合开放的、自服务的、面向领域业务的问题定义，同时需要满足自动化、低安全风险、低噪音、易治理的企业内部要求吗？正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在平台工程的特定问题域内，一批配置和策略语言用于编写和管理规模化复杂配置及策略。\n不同于混合编写范式、混合工程能力的高级通用语言，这类专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将规模化复杂配置和策略编写思路和方式沉淀到语言特性中。\n在蚂蚁的平台工程实践中，我们强化了客户端的工作方式，将围绕应用运维生命周期的模型、编排、约束和策略稳定、可扩展的通过专用语言 KCL[5] 编写维护在共享仓库 Konfig[6] 中。\nKCL 是一种面向有编程能力的应用研发者的静态强类型语言，提供现代高级语言的编写体验和围绕领域目的有限功能。在平台工程实践中 KCL 不是一种仅用于编写 K-V 对的语言，而是一种面向平台工程领域的专用语言。应用研发者、 SRE 、平台研发者面向 Konfig 协同研发，通过 KCL 原生功能编写应用配置，以及在 PaaS 领域更为高频和复杂的 模型抽象[7] 、 功能函数[8] 和 约束规则[9] ，即编写稳定、可扩展的业务模型、业务逻辑、防错约束和环境规则。\nKonfig 仓库则成为统一的编程界面，工作空间和业务层载体，而基于 KCL 的安全、低噪音、低副作用、一致的编写范式更有利于长期管理和治理。\n四、分治：解构规模化问题 分治思路是解决规模化问题的钥匙，从 MapReduce 到 Kubernetes 无不体现其功效。在规模化交付运维领域，经典运维平台试图在统一的黑盒平台产品中，以内置的统一模型、编排、 provision 技术来应对全量业务场景。这样的实践可以快速启动，在小范围内奏效，但随着不同业务主体采用率提升引入差异化需求，同时随着持续变化的平台技术逐渐进入疲态。\n在蚂蚁的实践中，Konfig monorepo 是内部工程平台向研发者开放的编程界面和工作空间，帮助应用研发者以统一的编程界面编写围绕应用运维生命周期的配置和策略，从而编排和使用存量和新增的平台基础设施，按需创建管理云原生环境以及基于 RBAC 的权限，并通过 GitOps 方式管理交付过程。\nKonfig monorepo 为不同场景、项目、应用提供了独立的白盒的编程空间，其内生的扩展性来源于：\n- 灵活、可扩展、独立的客户端的 工程结构设计[10] ；\n- 独立配置块自动合并技术[11] 支持任意分块、可扩展的配置块组织；\n- 静态类型系统[12] 技术提供现代编程语言可复用、可扩展的类型化建模和约束功能；\n- 项目粒度的 GitOps CI 工作流程定义支持；\n- 基于 Kusion[13] 引擎的 provision 技术选择。\nKonfig monorepo 提供了分治的、可组合的工程结构设计、代码组织、建模方式、工作流程定义和 provision 技术选择支持，同时又以一致的研发模式和工作流承载了可扩展的业务需求。这样客户端的工作方式在保证灵活性、可扩展性、可移植性的同时也降低了对服务 …","date":-62135596800,"description":"","dir":"blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":-62135596800,"objectID":"025e2d84d60225a85a714bfd63e2c369","permalink":"https://sofastack.github.io/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","summary":"文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。 本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同； - 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。","tags":null,"title":"","type":"blog","url":"/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","wordcount":422},{"author":null,"categories":null,"content":" Novel features: Strong leader Raft uses a stronger form of leadership than other consensus algorithms. For example, log entries only flow from the leader to other servers. This simplifies the management of replicated logs and makes Raft easier to understand. Leader election Raft uses randomized timers to elect leaders. This reduces election conflicts simply and rapidly. Membership change Raft uses a new joint consensus approach. Replicated state machines 1. Replicated state machines are implemented based on logs. Each server stores a log. Each log entry contains a command. The state machine executes commands in order. 2. Consensus algorithms for practical systems typically have the following properties: They ensure safety. They are highly available. They do not depend on the time sequence to ensure log consistency. A command can be completed as soon as a majority of the cluster has responded to a single round of remote procedure calls (RPCs). Drawbacks of Paxos Paxos is exceptionally difficult to understand. Paxos does not provide a good foundation for building practical implementations. Raft design principles Concept decomposition Leader election Log replication Membership changes Raft reduces the number of states to simplify the state space. Raft does not allow log holes and restricts the possibilities of log inconsistency. Raft uses randomized timers to simplify the leader election. Raft consistency algorithm State Persistent state on all servers (updated on stable storage before responding to RPCs):\n currentTerm The latest term that the server gets (initialized to 0 on initial boot, increasing monotonically) votedFor The candidateId that has received votes in the current term (or null if none). Log[] Log entries. Each entry contains a command for the state machine, and the term when the entry was received by the leader. Volatile state on all servers:\n commitIndex The index of the highest log entry known to be committed. lastApplied The index of the highest log entry applied to the state machine. Volatile state on leaders:\n nextIndex[] The index of the next log entry to be sent to each follower. matchIndex[] The index of the highest log entry known to have been replicated on each follower. AppendEntries RPC (log replication) Called by the leader to replicate log entries or used as heartbeats.\nArguments:\n term leader\u0026amp;rsquo;s term leaderId The leader\u0026amp;rsquo;s ID that can be used to redirect clients to the leader. prevLogIndex The index of the preceding log entry. prevLogTerm The term of the prevLogIndex entry. entries[] The log entries to be stored (empty for heartbeat, and the leader may send more than one for efficiency). leaderCommit The leader\u0026amp;rsquo;s commitIndex (for committed log entries). Results:\n term The currentTerm for the leader to update. success True if the follower contains log entries matching prevLogIndex and prevLogTerm. Receiver …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/raft-introduction/","fuzzywordcount":2600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b811e803d23b40da67657798801f8b51","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","publishdate":"0001-01-01T00:00:00Z","readingtime":13,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","summary":"Novel features: Strong leader Raft uses a stronger form of leadership than other consensus algorithms. For example, log entries only flow from the leader to other servers. This simplifies the management of replicated logs and makes Raft easier to understand. Leader election Raft uses randomized timers to elect leaders. This reduces election conflicts simply and rapidly. Membership change Raft uses a new joint consensus approach.","tags":null,"title":"'Introduction to the Raft algorithm'","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","wordcount":2562},{"author":null,"categories":null,"content":" Open ACTS IDE In the Packages view, right click the function name annotated by @Test, and choose ACTS Function \u0026amp;gt; Edit Test Case as shown in the following figure.\nWrite test data Prepare request parameters Prepare correct request parameter data for the request parameters (type, order, and quantity) of the tested method. The parameters are divided into simple and complex types. Simple parameters include parameter types String, Date, Integer, Float, Double, Long, Short, and Byte (including their corresponding basic types, such as int and float). Complex parameters include parameter types List, Map, Set, custom class, Java defined class, and their nested expressions.\nSimple request parameters Right click Request Parameters, choose Select Model, and click Simple Type in the pop-up to select simple parameters.\nAfter importing simple request parameters, enter their values directly in the field as shown in the preceding figure. Parameters listed top down are the first, second, and third parameters of the tested method. You can right click a parameter to adjust its order.\nComplex parameters As shown in Figure 27, you need to generate request parameter models for the AccountTransRequest class and the BusinessActionContext class. Generally, class models of the tested method\u0026amp;rsquo;s request parameters and responses are automatically generated along with the test script. You can open ACTS IDE to edit class models of request parameters as shown in Figure 28.\nFigure 28\nIf the models of the method\u0026#39;s request parameters and responses are not identified when you generate the test script, first generate models of complex request parameters and responses (for detailed operation steps, see [Generate object model](../usage-model/#generate-object-model)). Then open ACTS IDE, right click Request Parameters, choose Select Model, and click Complex Type in the pop-up to add complex objects. After this, you can view and edit complex objects under Request Parameters. ![Complex type](complex-type.png) ### List ![List example](list-example.png) ![Edit value](edit-value.png) ### Map See example 2 (the Set type is similar). In Figure 32, request parameters of the method shown in sample 2 is the `Map` type. Objects do not belong to a specific type. If you want to set an object as a complex one, edit the YAML file. For example, if you want to set an object as the AccountTransResult class, edit the YAML file as follows: ![Map examples](map-example.png) Figure 32\n![ Change type](change-type.png) ![Set property values](set-value.png) ### enum Example code: ![Example code](sample.png) 1. You can edit the values in ACTS IDE as follows: ![Edit value](change-value.png) 2. If an enum type class is nested in another class, set the value of the enum type to DEBIT in the CSV model of the class. 3. Figure 37 shows the test case data in the YAML file. ```yaml interestRecoverTypeEnum: !!com.alipay.fc.loancore.common.util.enums.InterestRecoverTypeEnum \u0026#39;ALL\u0026#39; ``` ![YAML data](yaml-data.png) …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ide/","fuzzywordcount":2000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"697e7e6d35a2e058f3ca8b0a72032690","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-ide/","publishdate":"0001-01-01T00:00:00Z","readingtime":10,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-ide/","summary":"Open ACTS IDE In the Packages view, right click the function name annotated by @Test, and choose ACTS Function \u0026gt; Edit Test Case as shown in the following figure.\nWrite test data Prepare request parameters Prepare correct request parameter data for the request parameters (type, order, and quantity) of the tested method. The parameters are divided into simple and complex types. Simple parameters include parameter types String, Date, Integer, Float, Double, Long, Short, and Byte (including their corresponding basic types, such as int and float).","tags":null,"title":"All-in-one editor","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-ide/","wordcount":1929},{"author":null,"categories":null,"content":" Introduction To understand the usage mode of Jarslink2.0, you need to have a certain understanding of the SOFAArk framework and the packaging of Ark packages and Ark Biz packages.\nTo ensure the consistency of reading, here is a rough description of the packaging logic of the application\u0026amp;rsquo;s use of Jarslink2.0. The official recommendation is to jump to the above-mentioned link to obtain the necessary background knowledge.\nJarslink2.0 requires an application type of Spring Boot or SOFABoot. Before introducing new modes of application packaging, let\u0026amp;rsquo;s see why it is necessary for Spring Boot/SOFABoot applications to introduce new packaging modes after using Jarslink2.0.\nBackground At runtime, Jarslink2.0 works as an Ark Plugin of the SOFAArk framework, which must be introduced for the use of Jarslink2.0. The Jarslink2.0 plugin will not be loaded and started until the SOFAArk container is started. As we know, when official Spring Boot projects use plugins:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; An executable FatJar will be packaged, which contains all the dependencies, configurations, and other resources required by the running application. The FatJar entry method is the main method of the Spring Boot application. The packaging logic of a SOFABoot project is the same as that of a Spring Boot project.\nAfter the application introduces Jarslink2.0, which needs to depend on the SOFAArk framework, the FatJar that is packaged by a new packaging mode needs to contain a SOFAArk container. The FatJar entry method also needs to be replaced by the SOFAArk container startup method, because the startup of SOFAArk takes precedence over the execution of the FatJar. The SOFAArk container starts all the Ark Plugins in turn before finally starting the application. Therefore, a new packaging mode is needed, and SOFAArk provides a packaging plugin.\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; responsible for packaging Spring Boot/SOFABoot applications into an executable FatJar called Ark package.\nPackaging Type In the previous section, we have described why the use of Jarslink 2.0 needs to introduce a packaging mode that is different from the official Spring Boot packaging mode, and brought out the first packaging type—Ark package. Now let\u0026amp;rsquo;s summarize the features of Ark package:\n Ark package is an executable FatJar package format customized by the SOFAArk framework, the details of which are available in Reference Documents. The Ark package contains all the configurations, dependencies, and other resources required by the running application. Its packaging logic is similar to that of Spring Boot, and it also contains the Ark Plugin and the SOFAArk framework on which the application depends. The SOFAArk framework does not need to be introduced into the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-repackage/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a9cb3c5d3fa32c5f6c476d9ed80c80cb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","summary":"Introduction To understand the usage mode of Jarslink2.0, you need to have a certain understanding of the SOFAArk framework and the packaging of Ark packages and Ark Biz packages.\nTo ensure the consistency of reading, here is a rough description of the packaging logic of the application\u0026rsquo;s use of Jarslink2.0. The official recommendation is to jump to the above-mentioned link to obtain the necessary background knowledge.\nJarslink2.0 requires an application type of Spring Boot or SOFABoot.","tags":null,"title":"Application packaging","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","wordcount":749},{"author":null,"categories":null,"content":" RheaKV: an embedded, distributed, highly available, and strongly consistent KV storage class library that is implemented based on JRaft and RocksDB. AntQ Streams QCoordinator: uses JRaft to implement elections and meta information storage in the Coordinator cluster. Metadata management module of SOFARegistry: an IP address registration. The data held by all nodes must be consistent, and the normal data storage must not be affected when a minority of nodes fail. AntQ NameServer leader election ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/user-stories/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b233be7d9eed33645945293e637e28ea","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/user-stories/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/user-stories/","summary":"RheaKV: an embedded, distributed, highly available, and strongly consistent KV storage class library that is implemented based on JRaft and RocksDB. AntQ Streams QCoordinator: uses JRaft to implement elections and meta information storage in the Coordinator cluster. Metadata management module of SOFARegistry: an IP address registration. The data held by all nodes must be consistent, and the normal data storage must not be affected when a minority of nodes fail.","tags":null,"title":"Application scenarios","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/user-stories/","wordcount":74},{"author":null,"categories":null,"content":" ## Architecture diagram Jarslink 2.0 is an Ark plugin and needs to depend on the SOFAArk container at runtime. Jarslink 2.0 is in the middle layer between the applications and the containers at runtime. Boundary interaction mode: + 1. Application boundaries: Jarslink 2.0 configures export classes that can be directly used by the applications. Such classes are loaded by Jarslink at runtime. + 2. Container boundaries: The Ark plugin can interact with the SOFAArk container by using the exposed extension points and services. Jarslink expanded the BizDeployer implementation and referenced BizManagerService and BizFactoryService container services.\nModule division The implementation classes of each module appear only in their own modules and are generally not cross-dependent. Required cross-dependencies will be moved into the core module. Detailed module descriptions can be found in the following table:\n Module name Sub-module name Description Dependency relationship bom Dependent on version control None core common Common module with log classes None core spi SPI module, defining basic interfaces and commands None core-impl runtime Jarslink runtime management, processing commands Core integration Ark plugin packaging module, implementing SOFAArk container service extension point and referencing container services All ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-structure/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fa09c01de689002edbd0bea7f68fe66e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","summary":"## Architecture diagram Jarslink 2.0 is an Ark plugin and needs to depend on the SOFAArk container at runtime. Jarslink 2.0 is in the middle layer between the applications and the containers at runtime. Boundary interaction mode: + 1. Application boundaries: Jarslink 2.0 configures export classes that can be directly used by the applications. Such classes are loaded by Jarslink at runtime. + 2. Container boundaries: The Ark plugin can interact with the SOFAArk container by using the exposed extension points and services.","tags":null,"title":"Architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","wordcount":188},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-biz/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d7f80ce6a00d914546e642c887d23a01","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","summary":"","tags":null,"title":"Ark Biz","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","wordcount":0},{"author":null,"categories":null,"content":" 简介 本小节将介绍 Ark Biz 目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark Biz。\nArk Biz 包和 Ark 包 都是使用 Maven 插件 sofa-ark-maven-plugin 打包生成；工程应用在配置该插件时，默认情况下只会打包发布 Ark 包， 只有在配置参数 attach 为 true 时，才会打包发布 Ark Biz：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;false\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 那 Ark Biz 和 Ark 包 有什么区别呢？ 简单来说，Ark Biz 是工程应用所有资源的组织单元，它包含了应用启动所需的所有资源，详细可参考下文描述的 Ark Biz 目录格式；而工程应用打出来的 Ark 包，是一个通过 java -jar 启动，运行在 SOFAArk 容器的 Fat Jar，不仅包含应用工程对应的 Ark Biz，也包含 Ark Container，以及应用依赖的 Ark Plugin；\n通常情况，只需要发布 Ark 包 即可，但是 SOFAArk 是支持运行多个 Ark Biz的，因此如果开发者希望自己应用的 Ark Biz 包能够被其他应用直接当成 Jar 包依赖，进而运行在同一个 SOFAArk 容器之上，那么就需要打包发布 Ark Biz 包；\nArk-Biz 典型目录结构 . ├── META-INF │ ├── MANIFEST.MF │ ├── maven │ │ └── me.qlong.tech │ │ └── sofa-boot-demo3-web │ │ ├── pom.properties │ │ └── pom.xml │ └── sofa-boot-demo3 │ └── sofa-boot-demo3-web.xml ├── com │ └── alipay │ └── sofa │ └── ark │ └── biz │ └── mark ├── config │ ├── application-dev.properties │ ├── application-test.properties │ └── application.properties ├── lib │ ├── spring-beans-4.3.4.RELEASE.jar │ ├── spring-boot-1.4.2.RELEASE.jar │ ├── spring-boot-autoconfigure-1.4.2.RELEASE.jar │ ├── spring-boot-devtools-1.4.2.RELEASE.jar │ ├── spring-boot-starter-1.4.2.RELEASE.jar │ ├── spring-boot-starter-logging-1.4.2.RELEASE.jar │ ├── spring-boot-starter-tomcat-1.4.2.RELEASE.jar │ ├── spring-boot-starter-web-1.4.2.RELEASE.jar │ ├── spring-context-4.3.4.RELEASE.jar │ ├── spring-core-4.3.4.RELEASE.jar │ ├── spring-expression-4.3.4.RELEASE.jar │ ├── spring-web-4.3.4.RELEASE.jar │ ├── ... │ ├── ... │ ├── ... │ └── velocity-1.7.jar ├── logback-spring.xml ├── me │ └── qlong │ └── tech │ └── SOFABootWebSpringApplication.class └── static └── index.html 上述目录结构相关文件和目录说明如下：\n普通的 Java 工程或者 Spring Boot Core/Web 工程都可以打包成 Ark Biz；Ark Biz 没有固定的目录格式，它只是在原来 Jar 包结构基础上新增两个目录文件：\n com/alipay/sofa/ark/biz/mark : 标记文件，标记该 Jar 包是 sofa-ark-maven-plugin 打包生成的 Ark Biz 文件；\n lib/ : lib 目录存放工程应用的三方依赖，\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-biz/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d7f80ce6a00d914546e642c887d23a01","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","summary":"简介 本小节将介绍 Ark Biz 目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark Biz。 Ark Biz 包和 Ark 包 都是使用 Maven 插件 sofa-ark-maven-plugin 打包生成；工程应用在配置该插件时，默认情","tags":null,"title":"Ark Biz","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","wordcount":700},{"author":null,"categories":null,"content":" SOFAArk 合并部署时，除了宿主应用，其他 Biz 允许运行时动态部署和卸载。Biz 的状态如下:\n unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时 Biz 包还没有安装或者安装中 activated: Biz 包启动完成，且处于激活状态，可以对外提供服务 deactivated: Biz 包启动完成，但处于未激活状态，模块多个版本时，只有一个版本处于激活状态(注意这个状态只对 JVM 服务生效，对 RPC 等其他中间件无效) broken: Biz 包启动失败后状态 目前 SOFAArk 提供了三种方式操作 Biz:\n 编程 API Zookeeper 动态配置 Telnet 指令 本质上，后两种都是通过编程 API 操作 Biz，所以在这里详细描述通过编程 API 控制 Biz 的生命周期。SOFAArk 提供客户端 ArkClient 操作 Biz, 主要包含三条指令：\n install: 安装 Biz，虽然有多个重载方法，本质是接受 bizFile 文件作为入参 uninstall: 卸载 Biz，运行时 Biz 是由 bizName 和 bizVersion 唯一确定的，因此需要这两个入参 switch: 激活 Biz，SOFAArk 运行部署多个相同名称不同版本的 Biz，但是运行时只有一个 Biz 被激活（JVM 服务对外可用）；当使用 switch 指令激活其他版本时，当前处于激活状态的 Biz 将切换到钝化，同样也需要 bizName 和 bizVersion 作为入参 注意：部署相同名称不同版本 Biz 时，如果已有激活的版本，后续部署的其他版本 Biz 将自动处于钝化状态\n安装 Biz 以 Spring Boot/SOFABoot 为例，应用(模块)安装包含以下流程：\n 解析模块 \u0026amp;gt; SOFAArk 容器会解析文件流，读取 Biz 配置，创建 BizClassLoader 等，生成 Biz 运行时模型\n 注册模块 \u0026amp;gt; 注册解析后的 Biz 模型，设置状态为 resolved\n 启动模块 \u0026amp;gt; 执行 Biz 的入口方法，完成上下文的刷新，如果报错则对外抛出异常\n 健康检查 \u0026amp;gt; 启动完成，此时 Biz 还没有切换至下一个状态，将会执行应用健康检查，健康检查参考 SOFABoot 文档，健康检查失败则抛出异常，如果应用没有引入 SOFABoot 健康检查依赖，则跳过\n 切换状态 \u0026amp;gt; 健康检查成功，会切换 Biz 状态；如果不存在其他版本 Biz 处于激活状态，则切换状态至 Activated，否则切换状态至 DeActivated\n 注意：启动模块时抛出异常，均导致 Biz 启动失败，可以查看 sofa-ark/common-error.log 日志\n卸载 Biz 应用（模块）卸载包含以下流程：\n 切换 Biz 状态至少 deactivated \u0026amp;gt; 钝化 Biz, 防止流量进入正在卸载的 Biz\n 关闭 ApplicationContext \u0026amp;gt; 关闭 Biz 的 Spring 上下文，如果用户需要自定义卸载操作，可以监听 ContextClosedEvent 事件\n 注销 JVM 服务 \u0026amp;gt; SOFAArk 运行时注销 Biz 发布的 JVM 服务\n 发送卸载事件 \u0026amp;gt; 通知所有 Ark Plugin 和 Ark Biz，正在卸载某个 Biz\n 清楚缓存 \u0026amp;gt; SOFAArk 运行时注销所有和该 Biz 相关的缓存\n 切换 Biz 状态为 unresolved \u0026amp;gt; Biz 执行完所有卸载操作时，将状态置为 unresolved\n 卸载面临的挑战 卸载 Biz 最大的挑战在于 ClassLoader 的卸载，如果 ClassLoader 没有卸载干净，极有可能会导致 metaspace OOM. JDK 对 Class 的回收条件非常苛刻，包含：\n 该类所有实例都已经回收 加载该类的 ClassLoader 已经回收 该类对应的 java.lang.Class 对象已经没有在任何地方被引用，无法在任何地方通过反射访问该类的方法 每个 Biz 都由独立的 BizClassLoader 加载，只要该 Biz 的加载的类或对象或 ClassLoader 被其他 Biz 或 Plugin 引用，则会导致 Biz 无法卸载成功\n激活 Biz 激活指令用于设置 Biz 状态为 Activated，如果此时已有其他版本 Biz 处于激活状态，则先设置其为 Deactivated，再激活指定的 Biz 为 Activated. 激活状态是相对 JVM 服务而言，只有被激活的 Biz，其发布的 JVM 服务才能被其他 Biz 引用\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-biz-lifecycle/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"090ee6596c6808339fa3233139903040","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","summary":"SOFAArk 合并部署时，除了宿主应用，其他 Biz 允许运行时动态部署和卸载。Biz 的状态如下: unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时","tags":null,"title":"Ark Biz 生命周期","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","wordcount":1195},{"author":null,"categories":null,"content":" This section will introduce the directory structure of standard Ark package and how to use the maven plugin of sofa-Ark-maven-plugin to package and release an Ark package.\nMaven plugin The officially provided Maven plugin sofa-Ark-maven-plugin can package common Java projects or Spring Boot projects into standard-format Ark packages. Based on Fat Jar technology, we can directly start an Ark package with the java -jar command. The Maven plugin coordinates are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals The sofa-Ark-maven-plugin plugin provides goal: repackage, which can package the project into an executable Ark package, it can be configured as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Configuration information --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Complete configuration template Complete sofa-Ark-maven-plugin configuration template is as follows:\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.1.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--The default packaging storage directory for Ark package and Ark biz is the project build directory--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;../target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--The name of the generated Ark package file is ${artifactId} by default--\u0026amp;gt; \u0026amp;lt;finalName\u0026amp;gt;demo-ark\u0026amp;lt;/finalName\u0026amp;gt; \u0026amp;lt;!--Whether to skip execution of goal:repackage (false by default)--\u0026amp;gt; \u0026amp;lt;skip\u0026amp;gt;false\u0026amp;lt;/skip\u0026amp;gt; \u0026amp;lt;!--Whether to package, install, and release Ark biz (false by default). Refer to the Ark Biz file for details --\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--Set the classifier of Ark package, which is null by default--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;ark-classifier\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- Set the classifier of Ark biz, which is Ark-biz by default --\u0026amp;gt; \u0026amp;lt;bizClassifier\u0026amp;gt;ark-biz-classifier\u0026amp;lt;/bizClassifier\u0026amp;gt; \u0026amp;lt;!--Exclude the specified package dependency when packaging the Ark biz. The format is: ${groupId:artifactId} or ${groupId:artifactId:classifier}--\u0026amp;gt; \u0026amp;lt;excludes\u0026amp;gt; \u0026amp;lt;exclude\u0026amp;gt;org.apache.commons:commons-lang3\u0026amp;lt;/exclude\u0026amp;gt; \u0026amp;lt;/excludes\u0026amp;gt; \u0026amp;lt;!--Exclude the package dependency that is the same as the specified groupId when packaging the Ark biz--\u0026amp;gt; \u0026amp;lt;excludeGroupIds\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jar/","fuzzywordcount":1400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c2a9b8ad142f15b9ee82d7d9d8237850","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","summary":"This section will introduce the directory structure of standard Ark package and how to use the maven plugin of sofa-Ark-maven-plugin to package and release an Ark package.\nMaven plugin The officially provided Maven plugin sofa-Ark-maven-plugin can package common Java projects or Spring Boot projects into standard-format Ark packages. Based on Fat Jar technology, we can directly start an Ark package with the java -jar command. The Maven plugin coordinates are:","tags":null,"title":"Ark JAR package","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","wordcount":1317},{"author":null,"categories":null,"content":" This section will introduce the standard specifications and directory structure of Ark Plugin and how to use the maven plugin of sofa-ark-plugin-maven-plugin to package and release it.\nPlugin Specifications A standard Ark Plugin should meet the following specifications:\n The plugin should have a name (default is ${artifactId}). At runtime, duplicate names are not allowed. In other words, the name will be used as the unique ID of Ark Plugin;\n A plugin must be configured with a priority (default is 1,000): the lower the number, the higher the priority;\n A plugin should be configured with no more than one entry class activator, a portal for the container startup plugin used to implement the com.alipay.sofa.ark.spi.service.PluginActivator interface class in a uniform way. The plugin with higher priority will start up first;\n Import classes support both package and class levels. They are loaded first from other plugins;\n Export classes support package and class levels. Plugins with higher priority will be exported first;\n Support importing resources from the classpath (wildcard is not supported). Specified resources will be searched for from other plugins first;\n Support exporting resources from the classpath (wildcard is not supported); resources with higher priority will be exported first;\n Maven plugins The officially provided Maven plugin sofa-ark-plugin-maven-plugin can package projects into a standard-format Ark Plugin. The coordinates of Maven plugin are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals The sofa-ark-plugin-maven-plugin plugin provides goal: ark-plugin, which can be used to package the project into a standard-format Ark Plugin. Configurations are as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Configuration information --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Complete configuration template The complete configuration template of the sofa-ark-plugin-maven-plugin plugin is shown as follows:\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Specify the directory to package ${pluginName}.ark.plugin (${project. build. directory} is the default location) --\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin/","fuzzywordcount":1300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"684dc1caa0f834eec498905f95913f83","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","summary":"This section will introduce the standard specifications and directory structure of Ark Plugin and how to use the maven plugin of sofa-ark-plugin-maven-plugin to package and release it.\nPlugin Specifications A standard Ark Plugin should meet the following specifications:\n The plugin should have a name (default is ${artifactId}). At runtime, duplicate names are not allowed. In other words, the name will be used as the unique ID of Ark Plugin;","tags":null,"title":"Ark Plugin","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","wordcount":1242},{"author":null,"categories":null,"content":" 本小节将介绍 Ark Plugin 的标准规范和目录结构，以及如何使用官方插件 sofa-ark-plugin-maven-plugin 打包发布 Ark Plugin。\n插件规范 标准的 Ark Plugin 需要满足以下规范：\n 插件必须配置插件名，默认为 ${artifactId} ；运行时，不允许存在同名的插件，可以认为它是 Ark Plugin 的唯一 ID;\n 插件必须配置优先级，默认为1000，数字越低表示优先级越高；\n 插件最多配置一个入口类 activator ，它是容器启动插件的入口，统一实现 com.alipay.sofa.ark.spi.service.PluginActivator 接口类；优先级高的插件优先启动；\n 导入类支持 package 和 class 两个级别；导入类优先从其他的插件加载；\n 导出类支持 package 和 class 两个级别；优先级高的插件优先导出；\n 支持导入 classpath 中资源，不支持通配符；优先从其他插件中查找指定资源；\n 支持导出 classpath 中资源，不支持通配符；优先级高的插件优先导出；\n Maven 插件 官方提供 Maven 插件 sofa-ark-plugin-maven-plugin 可以将工程打包成标准格式的 Ark Plugin ； Maven 插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${demo.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals sofa-ark-plugin-maven-plugin 插件提供 goal: ark-plugin，可以将工程打包成标准格式的 Ark Plugin, 如下配置：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 配置信息 --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 完整配置模板 完整的 sofa-ark-plugin-maven-plugin 插件配置模板如下：\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 指定打包的 ${pluginName}.ark.plugin 存放目录; 默认放在 ${project.build.directory} --\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!-- 是否把 ark plugin 安装、发布到仓库，默认为true --\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!-- ark plugin 最多仅能指定一个 com.alipay.sofa.ark.spi.service.PluginActivator 接口实现类 --\u0026amp;gt; \u0026amp;lt;activator\u0026amp;gt;com.alipay.sofa.ark.service.impl.SampleActivator\u0026amp;lt;/activator\u0026amp;gt; \u0026amp;lt;!-- 配置优先级，数字越小，优先级越高，优先启动，优先导出类，默认1000 --\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;2000\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!-- 配置插件的名字，务必配置对，运行时，是插件的唯一标识 ID。比如 sofa-rpc 插件，可以配置为 sofa-rpc; 默认为 ${artifactId} --\u0026amp;gt; \u0026amp;lt;pluginName\u0026amp;gt;${ark.plugin.name}\u0026amp;lt;/pluginName\u0026amp;gt; \u0026amp;lt;!--设置 ark plugin 的 classifier, 默认为空, 如非必要，建议不用设置--\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;!-- 配置导入类、资源 --\u0026amp;gt; \u0026amp;lt;imported\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的 package --\u0026amp;gt; \u0026amp;lt;packages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;javax.servlet\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework.*\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/packages\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的 class --\u0026amp;gt; \u0026amp;lt;classes\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.rpc.config.ProviderConfig\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/classes\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的资源 --\u0026amp;gt; \u0026amp;lt;resources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/bean.xml\u0026amp;lt;/resource\u0026amp;gt;\u0026amp;gt; \u0026amp;lt;/resources\u0026amp;gt; \u0026amp;lt;/imported\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"684dc1caa0f834eec498905f95913f83","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","summary":"本小节将介绍 Ark Plugin 的标准规范和目录结构，以及如何使用官方插件 sofa-ark-plugin-maven-plugin 打包发布 Ark Plugin。 插件规范 标准的 Ark Plugin 需要满足以下规范： 插件必须配置插件名，","tags":null,"title":"Ark Plugin","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","wordcount":1937},{"author":null,"categories":null,"content":" Ark container class loading mechanism The plugins and business modules are managed in the Ark container. The following figure describes the class loading mechanism:\nClass loading mechanism of Ark container Each Ark plugin has a separate classloader which loads a class in the following order:\n If byte codes generated by reflection are loaded, the system will throw a ClassNotFoundException to terminate the loading process. This primarily comes from our engineering practice: to avoid long time searches for the classes that can never be found. Search for the already loaded classes Search for classes in the JDK, which mainly consists of two parts: 1) the classes to be loaded by ExtClassloader; 2) the classes that are provided by the JDK but fail to be loaded from the ExtClassloader. When running locally, however, these classes will be added to the SystemClassloader\u0026amp;rsquo;s classpath or they might be put into some third-party toolkits such as sun.tools.attach.BsdVirtualMachine in tool.jar at the same time. This part also comes from our engineering practice, avoiding errors caused by loading a class more than once. See if the class is an interface from Sofa Ark, such as com.alipay.sofa.Ark.spi.service.PluginActivator. If so, the class will be delegated to the classloader of the Ark container responsible for loading. See if it is located in the plugin import (including import-classes and import-package). If so, the loading will be delegated to the plugin classloader that will export it. Load in the plugin\u0026amp;rsquo;s own classpath If the above steps have failed, it will try to load the class in SymtemClassloader to deal with the situation that the agent is used. If the class fails to be loaded with all the above steps, the ClassNotFoundException will be thrown.\nArk business class loading mechanism Each Ark business has a separate classloader. Its class loading mechanism is basically consistent with that of Ark plugin, except for the step 5:\nFor Ark business, no import configuration is provided. Instead, it defaults to importing all classes exported by plug-ins. To deal with some particular business scenarios, however, we do provide the Deny-import configuration so that we can exclude the classes exported by some plugins.\nClass loading mechanism of Ark plugin resources The Ark plugin supports importing and exporting resources. To achieve this, we need to configure the corresponding import and export settings in sofa-Ark-plugin-maven-plugin. There are two ways to search for resources when using ClassLoader: ClassLoader.getResource(String) or ClassLoader.getResources(String);\n ClassLoader.getResource(String): When an Ark Plugin is searching for a single resource, it will delegate the Ark Plugin that will export the resource to load the class first. If multiple plugins export the resource at the same time, then the plugin with higher priority will export the resource first. If the loading fails or no other Ark Plugin has exported the resource, it will have a …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-classloader/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5803b870aae47885c37e4bbb02cb0a06","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","summary":"Ark container class loading mechanism The plugins and business modules are managed in the Ark container. The following figure describes the class loading mechanism:\nClass loading mechanism of Ark container Each Ark plugin has a separate classloader which loads a class in the following order:\n If byte codes generated by reflection are loaded, the system will throw a ClassNotFoundException to terminate the loading process. This primarily comes from our engineering practice: to avoid long time searches for the classes that can never be found.","tags":null,"title":"Ark container class loading mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","wordcount":549},{"author":null,"categories":null,"content":" Starting an Ark plug-in Ark provides the interface for starting a plug-in com.alipay.sofa.ark.spi.service.PluginActivator. The definition of the interface is as follows:\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } Once a plug-in implements this interface, and the activator attribute is configured in MANIFEST.MF, the plug-in will use the start method when it starts and the stop method when it stops.\nArk plug-in communication Ark plug-ins communicate using services. The interfaces used by the publishing and reference services are provided in the input parameter type com.alipay.sofa.ark.spi.model.PluginContext of the preceding method of starting an interface.\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param pluginName the name of the plugin which publish the service * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String pluginName); /** * Get Service List publish by plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;ServiceReference\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; referenceServices(Class\u0026amp;lt;T\u0026amp;gt; ifClass); A plug-in service is interface-specific. For one interface, the following descriptions are true: * Only one service can be published for each plug-in. When more than one service is published, the reference of the previously published service will be returned. * If you use referenceService to reference a single service when multiple plug-ins have published services, which service is returned depends on whether pluginName is specified: * When not specified, the service with the highest priority is returned. * When specified, the service published by the plugin with the specified name is returned.\nThe returned service reference ServiceReference is defined as follows:\npublic interface ServiceReference\u0026amp;lt;T\u0026amp;gt; { /** * get Service Object * @return service */ T getService(); /** * get Service Metadata * @return */ ServiceMetadata getServiceMetadata(); } public interface ServiceMetadata { /** * get Service Unique Name * @return service name */ String getServiceName(); /** * get Service Interface Class * @return interface class */ Class\u0026amp;lt;?\u0026amp;gt; getInterfaceClass(); /** * get …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-plugin/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b552fc51eb84cc0fa4c26860bd316490","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","summary":"Starting an Ark plug-in Ark provides the interface for starting a plug-in com.alipay.sofa.ark.spi.service.PluginActivator. The definition of the interface is as follows:\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } Once a plug-in implements this interface, and the activator attribute is configured in MANIFEST.","tags":null,"title":"Ark container plugin mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","wordcount":477},{"author":null,"categories":null,"content":" Ark container start process The startup process of the Ark container is illustrated as follows:\nArkService Ark Service is a service in the Ark container. The underlying layer uses Guice to manage the service. The service is provided with the lifecycle interface com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } After the service implements the preceding lifecycle interface, the Ark Service container invokes the interface when it starts and stops.\nPipeline service Pipeline is also a service registered in the Ark Service container. The service itself has no order or priority. The service is assembled in the Pipeline while the entire Ark container starts.\nArchive parsing At the very beginning of Pipeline, the running fatjar will be resolved into the models required for runtime, including the Ark plug-in model and the Ark business model, which are registered to the PluginManagerService and the BizManagerService in the Ark Service.\nDeploy the Ark plug-in Get all the Ark plug-ins from the PluginManagerService in the order of their priorities: * ClassloaderService prepares for the map mapping of plug-in export class * PluginDeployService starts com.alipay.sofa.Ark.spi.service.PluginActivator\nStart the Ark business Get all the Ark business from the BizManagerService, and execute the entry main function provided by the business configuration in the Main-Class attribute of MANIFEST.MF.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ad60e803febd20607686a1b4ea98efc3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","summary":"Ark container start process The startup process of the Ark container is illustrated as follows:\nArkService Ark Service is a service in the Ark container. The underlying layer uses Guice to manage the service. The service is provided with the lifecycle interface com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } After the service implements the preceding lifecycle interface, the Ark Service container invokes the interface when it starts and stops.","tags":null,"title":"Ark container startup process","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","wordcount":233},{"author":null,"categories":null,"content":" 使用 Ark 事件处理机制 SOFAArk 从 1.1.0 版本开始提供了全新的事件模型，囊括了 SOFAArk 中 biz 和 plugin 的各个生命周期；该版本提供的事件模型参考了 Spring 中的生命周期事件模型。本篇文档将描述如何使用 SOFAArk 的事件机制。\n事件概览 biz 生命周期事件 事件名 描述 AfterBizStartupEvent biz 启动之后发送的事件 AfterBizStopEvent biz 停止之后发送的事件 AfterBizSwitchEvent biz 切换之后发送的事件 BeforeBizStartupEvent biz 启动之前发送的事件 BeforeBizStopEvent biz 停止之前发送的事件 BeforeBizSwitchEvent biz 切换之前发送的事件 plugin 生命周期事件 事件名 描述 AfterPluginStartupEvent plugin 启动之后发送的事件 AfterPluginStopEvent plugin 停止之后发送的事件 BeforePluginStartupEvent plugin 启动之前发送的事件 BeforePluginStopEvent plugin 停止之前发送的事件 容器级别生命周期事件 事件名 描述 AfterFinishDeployEvent 执行完 DeployStage 阶段之后发送的事件 AfterFinishStartupEvent 执行完 Ark 容器启动之后发送的事件 事件监听 监听指定类型的事件 上述提到的各个阶段的事件，我们可以通过编写 EventHandler 来处理，例如，希望监听类型为 BeforeBizStartupEvent 的事件，则可以通过以下方式实现监听：\n@Component public class EventHandlerSample implements EventHandler\u0026amp;lt;BeforeBizStartupEvent\u0026amp;gt; { private static final Logger LOGGER = LoggerFactory.getLogger(\u0026amp;quot;EVENT-HANDLER-LOGGER\u0026amp;quot;); @Override public int getPriority() { return 0; } @Override public void handleEvent(BeforeBizStartupEvent event) { Biz source = event.getSource(); LOGGER.info(\u0026amp;quot;begin to startup biz, current biz is: {}\u0026amp;quot;,source.getIdentity()); } } 日志目录：target/test/logs/host-app/event-handler.log 日志输出： 2019-11-28 15:18:33,248 INFO EVENT-HANDLER-LOGGER - begin to startup biz, current biz is: provider1:2.0.0, bizState: resolved\n 在此基础上，在提供其他几个 event 的处理器：\n AfterBizStartupEvent @Component public class AfterBizStartupEventHandler implements EventHandler\u0026amp;lt;AfterBizStartupEvent\u0026amp;gt; { private static final Logger LOGGER = LoggerFactory.getLogger(\u0026amp;quot;EVENT-HANDLER-LOGGER\u0026amp;quot;); @Override public void handleEvent(AfterBizStartupEvent event) { Biz source = event.getSource(); LOGGER.info(\u0026amp;quot;after startup biz, current biz is: {}, bizState: {}\u0026amp;quot;,source.getIdentity(),source.getBizState() ); } @Override public int getPriority() { return 0; } } 分别启动 基座 -\u0026amp;gt; 安装 ark-provider 模块 -\u0026amp;gt; 卸载 ark-provider 模块 ，然后看到日志输出如下：\n2019-11-28 15:31:42,325 INFO EVENT-HANDLER-LOGGER - after startup biz, current biz is: host-app:2.0.0, bizState: resolved 2019-11-28 15:36:23,956 INFO EVENT-HANDLER-LOGGER - begin to startup biz, current biz is: provider1:2.0.0, bizState: resolved 2019-11-28 15:36:27,216 INFO EVENT-HANDLER-LOGGER - after startup biz, current biz is: provider1:2.0.0, bizState: resolved 2019-11-28 15:53:38,225 INFO EVENT-HANDLER-LOGGER - before stop biz, current biz is: provider1:2.0.0, bizState: deactivated 2019-11-28 15:53:38,233 INFO EVENT-HANDLER-LOGGER - after biz stop, current biz is: provider1:2.0.0, bizState: unresolved 监听不指定类型的事件 某些情况下，如果期望监听所有 biz 或者 plugin 生命周期事件，可以使用以下方式：\n@Component public class AbstractArkEventHandler implements EventHandler\u0026amp;lt;AbstractArkEvent\u0026amp;gt; { @Override public int getPriority() { return 0; } @Override public void handleEvent(AbstractArkEvent event) { System.out.println(\u0026amp;quot;------------ current event topic: \u0026amp;quot; + event.getTopic()); } } 为了 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-event/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b0f233742572536edc8a517cf7547269","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","summary":"使用 Ark 事件处理机制 SOFAArk 从 1.1.0 版本开始提供了全新的事件模型，囊括了 SOFAArk 中 biz 和 plugin 的各个生命周期；该版本提供的事件模型参考了 Spring 中的生命周期事件模型。本篇","tags":null,"title":"Ark 事件机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","wordcount":1254},{"author":null,"categories":null,"content":" 本小节将介绍标准 Ark 包 的目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark 包。\nMaven 插件 官方提供 Maven 插件 sofa-ark-maven-plugin 可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式 Ark 包 ；基于 Fat Jar 技术，使用 java -jar 命令可以直接启动 Ark 包 。 Maven 插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals sofa-ark-maven-plugin 插件提供 goal: repackage， 可以将工程打包成可执行的 Ark 包，如下配置：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 配置信息 --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 完整配置模板 完整的 sofa-ark-maven-plguin 插件配置模板如下：\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--设置应用的根目录，用于读取 ${base.dir}/conf/ark/bootstrap.application 配置文件，默认为 ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;./\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;!--生成 ark 包文件名称，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;finalName\u0026amp;gt;demo-ark\u0026amp;lt;/finalName\u0026amp;gt; \u0026amp;lt;!--是否跳过执行 goal:repackage，默认为false--\u0026amp;gt; \u0026amp;lt;skip\u0026amp;gt;false\u0026amp;lt;/skip\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--设置 ark 包的 classifier，默认为空--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 classifier，默认为 ark-biz--\u0026amp;gt; \u0026amp;lt;bizClassifier\u0026amp;gt;ark-biz\u0026amp;lt;/bizClassifier\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 biz name，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;bizName\u0026amp;gt;demo-ark\u0026amp;lt;/bizName\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 biz version，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;bizVersion\u0026amp;gt;0.0.1\u0026amp;lt;/bizVersion\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 启动优先级，值越小优先级越高，${artifactId}--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;100\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的启动入口，默认会搜索被打 org.springframework.boot.autoconfigure.SpringBootApplication 注解且含有 main 方法的入口类--\u0026amp;gt; \u0026amp;lt;mainClass\u0026amp;gt;com.alipay.sofa.xx.xx.MainEntry\u0026amp;lt;/mainClass\u0026amp;gt; \u0026amp;lt;!--设置是否将 scope=provided 的依赖打包，默认为 false--\u0026amp;gt; \u0026amp;lt;packageProvided\u0026amp;gt;false\u0026amp;lt;/packageProvided\u0026amp;gt; \u0026amp;lt;!--设置是否生成 Biz 包，默认为true--\u0026amp;gt; \u0026amp;lt;keepArkBizJar\u0026amp;gt;true\u0026amp;lt;/keepArkBizJar\u0026amp;gt; \u0026amp;lt;!--针对 Web 应用，设置 context path，默认为 /--\u0026amp;gt; \u0026amp;lt;webContextPath\u0026amp;gt;/\u0026amp;lt;/webContextPath\u0026amp;gt; \u0026amp;lt;!--打包 ark biz 时，排除指定的包依赖；格式为: ${groupId:artifactId} 或者 ${groupId:artifactId:classifier}--\u0026amp;gt; \u0026amp;lt;excludes\u0026amp;gt; \u0026amp;lt;exclude\u0026amp;gt;org.apache.commons:commons-lang3\u0026amp;lt;/exclude\u0026amp;gt; \u0026amp;lt;/excludes\u0026amp;gt; \u0026amp;lt;!--打包 ark biz 时，排除和指定 groupId 相同的包依赖--\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jar/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c2a9b8ad142f15b9ee82d7d9d8237850","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","summary":"本小节将介绍标准 Ark 包 的目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark 包。 Maven 插件 官方提供 Maven 插件 sofa-ark-maven-plugin 可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式 Ark 包 ；","tags":null,"title":"Ark 包","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","wordcount":1626},{"author":null,"categories":null,"content":" Ark 应用的整体启动流程如下图所述：\n当用 java -jar 启动 Ark 包 或者 在 IDE 中通过 SofaArkBootstrap.launch 启动 Ark 应用时，相应 Launcher 入口会负责启动应用，其中会反射调用 ArkContainer 的入口，初始化 ArkService ，然后依次执行 pipeline，来完成整个 Ark 应用的启动。\nArkService Ark Serivce 是 Ark 容器中的服务，底层使用 Guice 对服务进行管理。同时针对服务，提供了生命周期接口 com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } 当服务实现了上述接口时，在 Ark Serivce 容器启动时和停止时会调用相应的生命周期接口\nPipeline 服务 Pipeline 也是注册在 Ark Service 容器中的一个服务，服务本身是没有顺序和优先级的，在 Pipeline 中会对服务进行一些组装，同时完成整个 Ark 容器的启动\nArchive 解析 在 Pipeline 的最开始，会将运行的 fatjar 进行解析，解析成运行时需要的模型，主要包括 Ark 插件模型和 Ark 业务模型，并将这些模型注册到 Ark Service 中的 PluginManagerService 以及 BizManagerService 中\n初始化环境 设置一些运行时需要的默认参数，比如设置 log4j.ignoreTCL 为 true 让 log4j/log4j2 初始化是日志不要从 ThreadContextClassloader 中寻找配置文件(背景)\n注册容器服务 在 Ark 容器中会发布一些服务供其它的插件来使用，比如 BizDeployer 来让 SOFAArk 官方插件 sofa-jarslink 来完成 biz 的动态加载/卸载等\n部署 Ark 插件 从 PluginManagerService 中获取到所有的 Ark 插件，并按照插件优先级顺序： * ClassloaderService 准备插件 export 类的 map 映射 * PluginDeployService 启动插件的 com.alipay.sofa.ark.spi.service.PluginActivator\n启动 Ark 业务 从 BizManagerService 中获取到所有的 Ark 业务，并执行业务配置在 MANIFEST.MF 属性 Main-Class 中提供的入口 main 函数\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ad60e803febd20607686a1b4ea98efc3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","summary":"Ark 应用的整体启动流程如下图所述： 当用 java -jar 启动 Ark 包 或者 在 IDE 中通过 SofaArkBootstrap.launch 启动 Ark 应用时，相应 Launcher 入口会负责启动应用，其中会反射调用 ArkContainer 的入口，初始化 ArkService ，然","tags":null,"title":"Ark 容器启动流程","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","wordcount":523},{"author":null,"categories":null,"content":" Ark 插件启动 Ark 中提供了插件启动的接口 com.alipay.sofa.ark.spi.service.PluginActivator ，其定义如下：\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } 插件只需要实现此接口，并在 MANIFEST.MF 中配置 activator 属性，就会在启动时执行 start 方法，停止时执行 stop 方法\nArk 插件通信 Ark 之间的通信是通过服务来完成的， 在上述启动接口方法的入参类型 com.alipay.sofa.ark.spi.model.PluginContext 中提供了发布服务和引用服务的接口\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param pluginName the name of the plugin which publish the service * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String pluginName); /** * Get Service List publish by plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;ServiceReference\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; referenceServices(Class\u0026amp;lt;T\u0026amp;gt; ifClass); 插件服务是以接口为粒度的，针对同一个接口： * 每一个插件只允许发布一个服务，重复发布则会直接返回已经发布服务的引用 * 当多有个插件发布服务时，若通过 referenceService 引用单个服务 * 当不指定 pluginName 时，则返回优先级最高的服务 * 当指定 pluginName 时，则返回该插件发布的服务\n返回的服务引用 ServiceReference 定义如下:\npublic interface ServiceReference\u0026amp;lt;T\u0026amp;gt; { /** * get Service Object * @return service */ T getService(); /** * get Service Metadata * @return */ ServiceMetadata getServiceMetadata(); } public interface ServiceMetadata { /** * get Service Unique Name * @return service name */ String getServiceName(); /** * get Service Interface Class * @return interface class */ Class\u0026amp;lt;?\u0026amp;gt; getInterfaceClass(); /** * get ServiceProvider * @return */ ServiceProvider getServiceProvider(); } 其中通过 * getService() 可以获取到服务的实体 (也即发布服务时的 implObject) * getServiceMetadata() 可以获取到服务的元数据信息，包括 * 服务名：即服务的接口名 * 服务接口 * 服务的提供方：包括提供方名字(插件名等)、提供方优先级(插件优先级)\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-plugin/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b552fc51eb84cc0fa4c26860bd316490","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","summary":"Ark 插件启动 Ark 中提供了插件启动的接口 com.alipay.sofa.ark.spi.service.PluginActivator ，其定义如下： public interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } 插件只需要实","tags":null,"title":"Ark 容器插件机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","wordcount":574},{"author":null,"categories":null,"content":" Ark 容器类加载机制 Ark 容器中会管理插件和业务，整体的类加载机制可见如下图描述：\nArk 插件类加载机制 每个 Ark 插件都拥有一个独立的类加载器，其类加载的顺序如下：\n 如果是加载反射生成的字节码，那么会直接抛出 ClassNotFoundException，终止类加载。这一部分主要是来源于我们的工程实践，避免一定找不到的类查找路径过长 查找已经被加载过的类 查找 JDK 中的类，这一块主要包含两部分：第一部分是 ExtClassloader 负责加载的类；第二部分是 JDK 提供的类但从 ExtClassloader 中加载不到，但在本地运行时会被加入到 SystemClassloader 的 classpath 中，同时这些类可能会被放到一些三方工具包中，典型的如 tool.jar 中 sun.tools.attach.BsdVirtualMachine,这一部分也主要来源于我们的工程实践，避免类被加载超过一次，从而引发报错 看类是否是由 Sofa Ark 提供的接口类，典型的如: com.alipay.sofa.ark.spi.service.PluginActivator, 如果是，则类会委托给 Ark 容器的类加载器加载 看是否在插件的 import 中(包括 import-classes 和 import-package)， 如果在，则会委托给导出该类的插件类加载器加载 在插件自身的 classpath 中加载 如果上述都失败了，则会尝试在 SymtemClassloader 中加载，这一步主要是为了解决使用 agent 时的情形 如果上述的步骤都加载失败了，则抛出 ClassNotFoundException\nArk 业务类加载机制 每个 Ark 业务都拥有一个独立的类加载器， Ark 业务类加载机制基本上与 Ark 插件保持一致，在上述的7步中，主要是第5步不一样：\n对于 Ark 业务而言，并没有提供 import 的配置，而是认为默认 import 所有插件 export 出来的类；但为了一些特殊的业务场景，我们提供了 Deny-import 的配置让业务可以排除掉某些插件导出的类\nArk 插件资源加载机制 Ark 插件支持导入导出资源，需要在 sofa-ark-plugin-maven-plugin 配置相关的导入导出配置；在使用 ClassLoader 加载资源时，存在两种方式查找资源，ClassLoader.getResource(String) 和 ClassLoader.getResources(String)；\n ClassLoader.getResource(String): Ark Plugin 在查找单个资源时，会优先委托导出该资源的 Ark Plugin 加载，如果有多个插件同时导出，则优先级高的插件优先导出；如果加载失败或者没有其他 Ark Plugin 导出，则尝试在本 Ark Plugin 查找加载；\n ClassLoader.getResources(String): Ark Plugin 在查找多个资源时，会从所有导出该资源的 Ark Plugin 加载，同时也会从本 Ark Plugin 加载资源；\n Ark 业务资源加载机制 默认情况下，Ark Biz 会优先加载 Ark Plugin 导出的资源；如果开发者希望只在工程应用内部查找，则可以通过 sofa-ark-maven-plugin 配置 denyImportResources；如此，Ark Biz 不会从 Ark Plugin 查找该资源，只会在 Ark Biz 内部查找。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-classloader/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5803b870aae47885c37e4bbb02cb0a06","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","summary":"Ark 容器类加载机制 Ark 容器中会管理插件和业务，整体的类加载机制可见如下图描述： Ark 插件类加载机制 每个 Ark 插件都拥有一个独立的类加载器，其类加载的顺序","tags":null,"title":"Ark 容器类加载机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","wordcount":974},{"author":null,"categories":null,"content":" Ark 容器和 Ark Plugin 在运行时由不同的类加载器加载，不能使用常规的 ServiceLoader 提供 SPI 扩展，SOFAArk 自定义扩展点 SPI 机制， Ark Plugin 实现 SPI 机制，考虑到 Biz 卸载问题，Ark Biz 暂时不支持该 SPI 机制，只适用于 Ark Plugin 之间。\n声明扩展接口 使用注解 @Extensible 声明扩展接口，注解定义如下：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Extensible { /** * return specify extensible file name, default value is the * full name of interface. */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * return whether this a singleton, with a single, shared instance * returned on all calls, default value is true. */ boolean singleton() default true; } file 用于声明 SPI 扩展文件名，默认为接口全类名 singleton 用于声明加载扩展类是否为单例模式 声明扩展实现 使用注解 @Extension 声明扩展实现，注解定义如下：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Extension { /** * extension name */ String value(); /** * extension order, Higher values are interpreted as lower priority. * As a consequence, the object with the lowest value has the highest * priority. */ int order() default 100; } value 用于定义扩展实现名称，例如不同的插件扩展同一个接口，可能会取不同的名字。 order 用于决定具体扩展实现的生效顺序 运行时，对于同一个接口的扩展实现生效规则如下： + 规则一：名称相同的扩展实现，只会返回优先级高的扩展实现类，order 数字越小，优先级越高 + 规则二：名称不相同的扩展实现，则返回一个对应的 List 列表，每个名称返回优先级最高的扩展实现\n加载 SPI 实现类 正常情况下，我们使用 ServiceLoader 加载 SPI 接口实现；SOFAArk 提供了工具类 ArkServiceLoader 用于加载扩展实现，工具类定义了两个简单的方法：\npublic class ArkServiceLoader { private static ExtensionLoaderService extensionLoaderService; // 方法一 public static \u0026amp;lt;T\u0026amp;gt; T loadExtension(Class\u0026amp;lt;T\u0026amp;gt; interfaceType, String extensionName) { return extensionLoaderService.getExtensionContributor(interfaceType, extensionName); } // 方法二 public static \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;T\u0026amp;gt; loadExtension(Class\u0026amp;lt;T\u0026amp;gt; interfaceType) { return extensionLoaderService.getExtensionContributor(interfaceType); } } 方法一：用于加载指定接口和名称的扩展实现，返回单个结果。参考上述规则一 方法二：用于加载指定接口的扩展实现，返回列表结果。参考上述规则二 需要注意下，定义 SPI 接口的插件需要导出该接口，负责实现 SPI 接口的插件需要导入该接口。另外 SOFAArk 容器本身也会定义部分用于插件扩展实现的 SPI 接口，例如 ClassLoaderHook\n为什么不支持 Biz 的 SPI 扩展实现加载 考虑到 Biz 会动态的安装和卸载，如果支持 Biz 的扩展实现加载，生命周期容易引起混乱，暂时不考虑支持。如果确实存在 Ark Plugin 需要主动触发 Ark Biz 的逻辑调用，可以通过 SOFAArk 内部事件机制。\nSOFAArk 默认扩展点 SOFAArk 容器目前提供了唯一一个扩展点 ClassLoaderHook，用于其他插件提供扩展实现，自定义类/资源加载逻辑。ClassLoaderHooker 接口定义如下，用于扩展 BizClassLoader 和 PluginClassLoader 类(资源）加载逻辑：\n@Extensible public interface ClassLoaderHook\u0026amp;lt;T\u0026amp;gt; { Class\u0026amp;lt;?\u0026amp;gt; preFindClass(String name, ClassLoaderService classLoaderService, T t) throws ClassNotFoundException; Class\u0026amp;lt;?\u0026amp;gt; postFindClass(String name, ClassLoaderService classLoaderService, T t) throws ClassNotFoundException; URL preFindResource(String name, ClassLoaderService classLoaderService, T t); URL postFindResource(String name, ClassLoaderService classLoaderService, T t); Enumeration\u0026amp;lt;URL\u0026amp;gt; preFindResources(String name, ClassLoaderService classLoaderService, T t) throws IOException; Enumeration\u0026amp;lt;URL\u0026amp;gt; postFindResources(String name, ClassLoaderService classLoaderService, T t) throws IOException; } 通过在插件中扩展该 SPI 接口实现，可以自定义 PluginClassLoader 和 BizClassLoader 的类/资源的加载逻辑。 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-extension/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"685e049f442cde4f3f51fefad5453dae","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","summary":"Ark 容器和 Ark Plugin 在运行时由不同的类加载器加载，不能使用常规的 ServiceLoader 提供 SPI 扩展，SOFAArk 自定义扩展点 SPI 机制， Ark Plugin 实现 SPI 机制，考虑到 Biz 卸载问题，A","tags":null,"title":"Ark 扩展机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","wordcount":1961},{"author":null,"categories":null,"content":"SOFAArk 容器使用了 logback 日志实现，并集成了 sofa-common-tools，日志相关配置可以参考 配置文档, 这里介绍 SOFAArk 三个日志文件：\n sofa-ark/common-default.log \u0026amp;gt; sofa-ark 默认日志，打印 SOFAArk 启动日志等，大概内容如下： 2019-03-12 15:08:55,758 INFO main - Begin to start ArkServiceContainer 2019-03-12 15:08:56,290 INFO main - Init Service: com.alipay.sofa.ark.container.session.StandardTelnetServerImpl 2019-03-12 15:08:56,311 INFO main - Listening on port: 1234 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.plugin.PluginDeployServiceImpl 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.biz.BizDeployServiceImpl 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.classloader.ClassLoaderServiceImpl 2019-03-12 15:08:56,317 INFO main - Finish to start ArkServiceContainer 2019-03-12 15:08:56,338 INFO main - Start to process pipeline stage: com.alipay.sofa.ark.container.pipeline.HandleArchiveStage 2019-03-12 15:08:56,349 INFO main - Finish to process pipeline stage: com.alipay.sofa.ark.container.pipeline.HandleArchiveStage 2019-03-12 15:08:56,349 INFO main - Start to process pipeline stage: com.alipay.sofa.ark.container.pipeline.RegisterServiceStage 2019-03-12 15:08:56,354 INFO main - Service: com.alipay.sofa.ark.spi.service.biz.BizManagerService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,354 INFO main - Service: com.alipay.sofa.ark.spi.service.biz.BizFactoryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,355 INFO main - Service: com.alipay.sofa.ark.spi.service.plugin.PluginManagerService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,356 INFO main - Service: com.alipay.sofa.ark.spi.service.plugin.PluginFactoryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,356 INFO main - Service: com.alipay.sofa.ark.spi.service.event.EventAdminService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,357 INFO main - Service: com.alipay.sofa.ark.spi.service.registry.RegistryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,360 INFO main - Inject {field= bizManagerService} of {service= ServiceMetadata{service=\u0026#39;com.alipay.sofa.ark.spi.service.biz.BizDeployer\u0026#39;, provider=\u0026#39;ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=100}\u0026#39;}} success! sofa-ark/common-error.log \u0026amp;gt; sofa-ark 错误日志，打印 SOFAArk 容器运行时错误日志，例如 biz 启动失败日志等： 2019-03-12 16:38:41,873 ERROR main - Start biz: Startup In IDE meet error java.lang.reflect.InvocationTargetException: null at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-log/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a514225510e53e9bf7173734c1f878e1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","summary":"SOFAArk 容器使用了 logback 日志实现，并集成了 sofa-common-tools，日志相关配置可以参考 配置文档, 这里介绍 SOFAArk 三个日志文件： sofa-ark/common-default.log \u0026gt; sofa-ark 默认日志，打","tags":null,"title":"Ark 日志","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","wordcount":667},{"author":null,"categories":null,"content":" SOFAArk 定义了两种服务类型，用于解决应用和插件，应用和应用之间的通信问题，下面分别介绍这两种服务类型：\n插件服务 SOFAArk 允许在 Plugin 通过 PluginContext 发布和引用服务，也可以使用注解 @ArkInject 引用服务。为了方便开发高级特性，SOFAArk 容器默认将内部功能组件发布成了服务，包括 Biz 管理，Plugin 管理，事件管理，服务注册管理。目前不允许 Biz 发布服务，只能引用插件服务。下面介绍如何发布和引用插件服务，以及 SOFAArk 容器默认发布的服务。\n发布服务 每个 Plugin 都可以定义唯一的插件入口，需要实现 PluginActivator 接口并在打包插件配置中声明，先看下接口定义：\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkRuntimeException */ void start(PluginContext context); /** * Stop Plugin * @param context * @throws ArkRuntimeException */ void stop(PluginContext context); } SOFAArk 容器在启动插件时，会调用插件启动入口(如果有)，因此如果插件实现方需要发布插件服务供其他插件或者 Biz 调用，可以使用入参 PluginContext 发布服务，PluginContext 提供了两个方法发布服务：\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param uniqueId service implementation id * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject, String uniqueId); 这两个方法的区别在于是否指定 uniqueId，因为同一个接口，可能会有多个服务实现，因此需要使用 uniqueId 区别，同样在引用端也需要指定 uniqueId. 默认 uniqueId 为空\n引用服务 SOFAArk 提供了两种方式引用插件服务，在插件内部，可以直接使用 PluginContext 引用服务，PluginContext 提供了两个简单的方法引用服务：\n/** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param uniqueId service implementation * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String uniqueId); 在 Biz 内部，如果是 Spring Boot/SOFABoot 应用，可以直接使用注解 @ArkInject 引用服务，注解声明如下：\n@java.lang.annotation.Target(ElementType.FIELD) @java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME) @java.lang.annotation.Documented public @interface ArkInject { /** * ark service interface * @return */ Class\u0026amp;lt;?\u0026amp;gt; interfaceType() default void.class; /** * ark service uniqueId * * @return return reference unique-id */ String uniqueId() default \u0026amp;quot;\u0026amp;quot;; } SOFAArk 提供集成 Spring Boot/SOFABoot 功能，在 Field 上打上 @ArkInject，指定接口类型和 uniqueId 即可完成自动注入。为了更加方便的使用，如果没有指定 interfacetType 类型，默认使用被打注解的 Field 类型。\n在插件内部，有时候也可以使用 @ArkInject 引用服务，即插件在发布某个服务时，服务内部可以直接使用 @ArkInject 引用服务；需要注意的是，被引用的服务如果是其他插件发布的，则必须满足其他插件优先当前插件启动。\n默认服务 前面提到，为了方便 Plugin 和 Biz 开发高级特性，SOFAArk 将内部功能组件发布成服务，包括：\n BizManageService \u0026amp;gt; Biz 管理器，管理、查询 Biz 信息\n BizFactoryService \u0026amp;gt; Biz 解析器，解析 Biz 文件\n PluginManagerService \u0026amp;gt; Plugin 管理器，管理、查询 Plugin 信息\n PluginFactoryService \u0026amp;gt; Plugin 解析器，解析 Plugin 文件\n EventAdminService \u0026amp;gt; SOFAArk 事件管理器， …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-service/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"81b7e697b890139c03831cdb648e094b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","summary":"SOFAArk 定义了两种服务类型，用于解决应用和插件，应用和应用之间的通信问题，下面分别介绍这两种服务类型： 插件服务 SOFAArk 允许在 Plugin 通过 PluginContext 发布和引用服务，也可","tags":null,"title":"Ark 服务机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","wordcount":1188},{"author":null,"categories":null,"content":" 在 Ark 服务机制 中，我们详细介绍了如何引用和发布插件服务，主要是解决 Plugin 和 Biz 的通信问题；为了解决 Biz 之间的通信问题，SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference 编程界面；下面介绍其使用方法。\n引入依赖 引入 runtime-sofa-boot-plugin 依赖，如果应用基于 Spring Boot 1.x 开发，推荐使用 v2.6.1 版本；如果应用基于 Spring Boot 2.x 开发，推荐使用 v3.1.3 版本；\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 发布和引用 JVM 服务 SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference JVM 服务概念(参考文档)，为了方便文档统一，重复其介绍。\nSOFABoot 提供三种方式给开发人员发布和引用 JVM 服务\n XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上面的 Bean 发布成一个 SOFA JVM 服务。\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 上面的配置中的 interface 指的是需要发布成服务的接口，ref 指向的是需要发布成 JVM 服务的 Bean，至此，我们就已经完成了一个 JVM 服务的发布。\n服务引用 使用 SOFA 提供的 Spring 扩展标签引用服务:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上面的配置中的 interface 是服务的接口，需要和发布服务时配置的 interface 一致。id 属性的含义同 Spring BeanId。上面的配置会生成一个 id 为 sampleServiceRef 的 Spring Bean，你可以将 sampleServiceRef 这个 Bean 注入到当前 SOFABoot 模块 Spring 上下文的任意地方。\n service/reference 标签还支持 RPC 服务发布，相关文档: RPC 服务发布与引用\n Annotation 方式 警告\n如果一个服务已经被加上了 @SofaService 的注解，它就不能再用 XML 的方式去发布服务了，选择一种方式发布服务，而不是两种混用。\n 除了通过 XML 方式发布 JVM 服务和引用之外，SOFABoot 还提供了 Annotation 的方式来发布和引用 JVM 服务。通过 Annotation 方式发布 JVM 服务，只需要在实现类上加一个 @SofaService 注解即可，如下：\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } 提示\n@SofaService 的作用是将一个 Bean 发布成一个 JVM 服务，这意味着虽然你可以不用再写 \u0026amp;lt;sofa:service/\u0026amp;gt; 的配置，但是还是需要事先将 @SofaService 所注解的类配置成一个 Spring Bean。\n 在使用 XML 配置 \u0026amp;lt;sofa:service/\u0026amp;gt; 的时候，我们配置了一个 interface 属性，但是在使用 @SofaService 注解的时候，却没有看到有配置服务接口的地方。这是因为当被 @SofaService 注解的类只有一个接口的时候，框架会直接采用这个接口作为服务的接口。当被 @SofaService 注解的类实现了多个接口时，可以设置 @SofaService 的 interfaceType 字段来指定服务接口，比如下面这样：\n@SofaService(interfaceType = SampleInterface.class) public class SampleImpl implements SampleInterface, Serializable { public void test() { } } 和 @SofaService 对应，Sofa 提供了 @SofaReference 来引用一个 JVM 服务。假设我们需要在一个 Spring Bean 中使用 SampleJvmService 这个 JVM 服务，那么只需要在字段上加上一个 @SofaReference 的注解即可：\npublic class SampleServiceRef { @SofaReference private SampleService sampleService; } 和 @SofaService 类似，我们也没有在 @SofaReference 上指定服务接口，这是因为 @SofaReference 在不指定服务接口的时候，会采用被注解字段的类型作为服务接口，你也可以通过设定 @SofaReference 的 interfaceType 属性来指定：\npublic class SampleServiceRef { @SofaReference(interfaceType = SampleService.class) private SampleService sampleService; } 使用 @SofaService 注解发布服务时，需要在实现类上打上 @SofaService 注解；在 Spring Boot 使用 Bean Method 创建 Bean 时，会导致 @Bean 和 @SofaService 分散在两处，而且无法对同一个实现类使用不同的 unique id。 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jvm/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1bf80b24428da0f91edc6af7b63f6047","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","summary":"在 Ark 服务机制 中，我们详细介绍了如何引用和发布插件服务，主要是解决 Plugin 和 Biz 的通信问题；为了解决 Biz 之间的通信问题，SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference 编","tags":null,"title":"Ark 服务通信","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","wordcount":2430},{"author":null,"categories":null,"content":" Use java.lang.Runnable in thread If you start a thread via java.lang.Runnable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerRunnable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.start(); Use java.util.concurrent.Callable in thread If you start a thread via java.util.concurrent.Callable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerCallable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nExecutorService executor = Executors.newCachedThreadPool(); SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt; sofaTracerSpanSofaTracerCallable = new SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt;(new Callable\u0026amp;lt;Object\u0026amp;gt;() { @Override public Object call() throws Exception { return new Object(); } }); Future\u0026amp;lt;Object\u0026amp;gt; futureResult = executor.submit(sofaTracerSpanSofaTracerCallable); //do something in current thread Thread.sleep(1000); //another thread execute success and get result Object objectReturn = futureResult.get(); This example assumes that the object type returned by java.util.concurrent.Callable is java.lang.Object. You can replace it with the expected type based on actual situation.\nSOFATracer support for thread pool and asynchronous call scenarios Asynchronous Asynchronous invocation, in RPC calls, for example,each time the rpc call request goes out, it will not wait until the result is returned before initiating the next call. There is a time difference here, before the callback of the previous rpc call comes back, another new one begin. At this time, the TracerContext in the current thread is not cleaned up, the spanId will be incremented, and the tracerId is the same.\n For the above situation, when the SOFATracer is processed for the asynchronous situation, it will not wait for the callback to execute, and then the cr phase will be cleaned up. Instead, the current thread\u0026amp;rsquo;s tracerContext context will be cleaned up in advance to ensure the correctness of the link.\nThread Pool For now, whether it\u0026amp;rsquo;s SOFARPC or Dubbo\u0026amp;rsquo;s trace implementation, the situation is the same when using single-thread or thread pools:\n Synchronous call. A thread in the thread pool is allocated to handle the RPC request. This does not cause the next RPC request to take the tracerContext data of the previous request by mistake Asynchronous calls, since the asynchronous callback is not in the callback to clean up the context, but in advance, there is no dirty data problem. callback, which is essentially an …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/async/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e755346c441115663c101638667fe4c0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/async/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/async/","summary":"Use java.lang.Runnable in thread If you start a thread via java.lang.Runnable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerRunnable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.","tags":null,"title":"Asynchronous thread processing","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/async/","wordcount":436},{"author":null,"categories":null,"content":" ## Model\nApplications Jarslink manages the life cycle of multiple applications. During runtime dynamic deployment, it usually converts a Jar file entity into an abstract model Biz. + Biz: abstract model of the application at runtime\nInstruction Currently, Jarslink supports the telnet protocol and accepts the entered instructions. In the future, it will also support instruction execution through APIs. Acceptable instruction types: + InstallCommand: install the application + UninstallCommand: uninstall the application + CheckCommand: check the application state + SwitchCommand: switch the application state\nService The Jarslink plugin has expanded the SOFAArk container\u0026amp;rsquo;s services of BizDeployer and CommandProvider and referenced the SOFAArk container\u0026amp;rsquo;s exposed services of BizManagerService and BizFactoryService. + BizDeployer is the application deployment extension point provided by the SOFAArk container, and it is used to control the Biz startup in the Ark package. Jarslink has registered its own implementation with the SOFAArk container. + CommandProvider is the command processing extension point provided by the SOFAArk container, and it is used to process the commands received by the SOFAArk container through a telnet link. + BizManagerService is the Biz manager exposed by the SOFAArk container, and it is used for registration, deregistration, and other operations. + BizFactoryService is the Biz generator exposed by the SOFAArk container, and it is used to abstract static Biz package files into runtime Biz models.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-model/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"991cb277d50874fa27095b920ac9b736","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","summary":"## Model\nApplications Jarslink manages the life cycle of multiple applications. During runtime dynamic deployment, it usually converts a Jar file entity into an abstract model Biz. + Biz: abstract model of the application at runtime\nInstruction Currently, Jarslink supports the telnet protocol and accepts the entered instructions. In the future, it will also support instruction execution through APIs. Acceptable instruction types: + InstallCommand: install the application + UninstallCommand: uninstall the application + CheckCommand: check the application state + SwitchCommand: switch the application state","tags":null,"title":"Basic model","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","wordcount":221},{"author":null,"categories":null,"content":" Messages All messages are internally passed through SofaRequest and SofaResponse.\nTo convert to other protocols, you need to transform the messages to the objects that are to be actually transferred when calling and receiving requests.\nThe modules that can write SofaRequest and SofaResponse are as follows:\n Invoker Filter ServerHandler Serialization The modules that can only read message bodies are as follows:\n Cluster Router LoadBalance Logs The log initialization is based on the extension mechanism. Since the log loading should be done earliest, there is a separate key in rpc-config.json.\n{ / / Log implementation is done earlier than configuration loading, so it cannot adapt to the extension mechanism \u0026amp;quot;logger.impl\u0026amp;quot;: \u0026amp;quot;com.alipay.sofa.rpc.log.MiddlewareLoggerImpl\u0026amp;quot; } Configuration items RPC configuration for users The user configuration includes port configuration (although the fields for setting port in the objects have been opened, SOFA gets those fields from the configuration file by default), thread pool size configuration, and other configurations.\n Load the configuration via SofaConfigs and call ExternalConfigLoader to read external properties. Get the configuration through the API provided by SofaConfigs. All the internally configured keys are in the SofaOptions class. Priority: System.property \u0026amp;gt; sofa-config.properties (one for each application) \u0026amp;gt; rpc-config.properties. RPC framework configuration The configuration of the framework itself, such as default serialization and default timeout. In the future, SOFARPC may support the configuration for multiple ClassLoaders.\n Load the configuration file via RpcConfigs. Get and listen to data changes via the API provided by RpcConfigs All internally configured keys are in the RpcOptions class Priority: System.property \u0026amp;gt; custom rpc-config.json (There may be multiple custom configuration files which are sorted in certain order) \u0026amp;gt; rpc-config-default.json. Constants The global basic constants are in RpcConstants. For example: Calling method (sync/oneway) Protocol (bolt/grpc/rest); serialization (hessian/java/protobuf) Context key If the extension implements its own constants, you need to maintain the constants yourself. For example:\n The constants of BOLT protocol SERIALIZE_CODE_HESSIAN = 1 PROTOCOL_TR = 13 The constants related with DSR Configuration Center The keys specific for DSR Configuration Center, such as _WEIGHT and _CONNECTTIMEOUT Address The address information of provider is placed in the ProviderInfo class. The value of ProviderInfo is mainly divided into three parts: Fields, which are generally required items, such as IP, port and status. Static fields, such as application name. Dynamic fields, such as warm-up weight. Field enumerations are maintained in the ProviderInfoAttrs class. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/common-model/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b2cc3f7ed134408d6adc25e418e1978b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/common-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/common-model/","summary":"Messages All messages are internally passed through SofaRequest and SofaResponse.\nTo convert to other protocols, you need to transform the messages to the objects that are to be actually transferred when calling and receiving requests.\nThe modules that can write SofaRequest and SofaResponse are as follows:\n Invoker Filter ServerHandler Serialization The modules that can only read message bodies are as follows:\n Cluster Router LoadBalance Logs The log initialization is based on the extension mechanism.","tags":null,"title":"Basic model","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/common-model/","wordcount":386},{"author":null,"categories":null,"content":" Publish Service To use SOFARPC to publish a Bolt-protocol service, you only need to add a Binding named bolt. The ways to add Bolt Binding are as follows:\nXML To publish a Bolt service using XML, simply add the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag to the \u0026amp;lt;sofa:service\u0026amp;gt; tag:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation To publish a Bolt service using Annotation, you only need to set the bindingType of @SofaServiceBinding to bolt:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)}) Public class SampleServiceImpl implements SampleService { } API in Spring environment To publish a Bolt-protocol service in Spring or Spring Boot environment, just add BoltBindingParam to ServiceParam:\nServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(SampleService.class); // Set the service interface serviceParam.setInstance(new SampleServiceImpl()); // Set the implementation of the service interface List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); Params.add(serviceBindingParam); serviceParam.setBindingParams(params); API in non-Spring environment To provide the Bolt-protocol service using the bare API of SOFARPC in a non-Spring environment, just set the ServerConfig whose protocol is Bolt to the corresponding ProviderConfig:\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;); // Create a new ServerConfig with Bolt protocol ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRef(new SampleServiceImpl()) .setServer(serverConfig) // Set ServerConfig to ProviderConfig to indicate that the protocol published by this service is Bolt. .setRegistry(registryConfig); providerConfig.export(); Reference Service To reference a Bolt-protocol service using SOFARPC, just add a Binding named bolt. The ways to use Bolt Binding are as follows:\nXML To reference a Bolt-protocol service using XML, simply add the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag to the \u0026amp;lt;sofa:reference\u0026amp;gt; tag:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation To reference a Bolt-protocol service using Annotation, just set the bindingType of @SofaReferenceBinding to bolt:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) Private SampleService sampleService; API in Spring environment To reference a Bolt-protocol service in a Spring or Spring Boot environment, simply add a BoltBindingParam to ReferenceParam:\nReferenceClient …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-usage/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dd929c0a3cd2f4620ddf0d30d98ba85d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","summary":"Publish Service To use SOFARPC to publish a Bolt-protocol service, you only need to add a Binding named bolt. The ways to add Bolt Binding are as follows:\nXML To publish a Bolt service using XML, simply add the \u0026lt;sofa:binding.bolt\u0026gt; tag to the \u0026lt;sofa:service\u0026gt; tag:\n\u0026lt;sofa:service ref=\u0026quot;sampleService\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.sample.SampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt/\u0026gt; \u0026lt;/sofa:service\u0026gt; Annotation To publish a Bolt service using Annotation, you only need to set the bindingType of @SofaServiceBinding to bolt:","tags":null,"title":"Basic usage of Bolt protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","wordcount":364},{"author":null,"categories":null,"content":" In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the Dubbo protocol, just set Binding to Dubbo. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish a Dubbo service, just set the bindingType of @SofaServiceBinding to dubbo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a Dubbo service, just set the bindingType of @SofaReferenceBinding to dubbo:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; Set the Group of Dubbo Service In the SOFARPC program model, there is no field called Group, but there is a model of uniqueId, which can be directly mapped to the Group in Dubbo model. For example, the following code is to publish a service whose Group is groupDemo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}, uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;) public class SampleServiceImpl implements SampleService { } The following code is to reference a service whose Group is groupDemo:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;, jvmFirst = false) private SampleService sampleService; Note that Dubbo protocol currently only supports Zookeeper as service registry center.\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo-usage/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1bf72c194a20a5dccea70423690191f4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","summary":"In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the Dubbo protocol, just set Binding to Dubbo. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish a Dubbo service, just set the bindingType of @SofaServiceBinding to dubbo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026quot;dubbo\u0026quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a Dubbo service, just set the bindingType of @SofaReferenceBinding to dubbo:","tags":null,"title":"Basic usage of Dubbo protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","wordcount":203},{"author":null,"categories":null,"content":" In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the H2C protocol, just set Binding to H2C. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish an H2C service, just set the bindingType of @SofaServiceBinding to h2c:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a H2C service, just set the bindingType of @SofaReferenceBinding to h2c:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c-usage/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fa75eff1e99b3acad5087160a1b44a09","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","summary":"In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the H2C protocol, just set Binding to H2C. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish an H2C service, just set the bindingType of @SofaServiceBinding to h2c:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026quot;h2c\u0026quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a H2C service, just set the bindingType of @SofaReferenceBinding to h2c:","tags":null,"title":"Basic usage of H2C protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","wordcount":100},{"author":null,"categories":null,"content":" In SOFARPC (Not In SOFABoot/SpringBoot)，when use Http as a protocol of server，we can use Json as the way of serialization，for some basic test scenes.\nSOFARPC API Usage Service Publish ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026amp;quot;serverApp\u0026amp;quot;)) .setServer(serverConfig) .setUniqueId(\u0026amp;quot;uuu\u0026amp;quot;) .setRegister(false); providerConfig.export(); Service Consume Because of the Http+Json，So users can use HttpClient to start a normal call, this is a piece of code in test.\nprivate ObjectMapper mapper = new ObjectMapper(); HttpClient httpclient = HttpClientBuilder.create().build(); // POST normal request String url = \u0026amp;quot;http://127.0.0.1:12300/com.alipay.sofa.rpc.server.http.HttpService:uuu/object\u0026amp;quot;; HttpPost httpPost = new HttpPost(url); httpPost.setHeader(RemotingConstants.HEAD_SERIALIZE_TYPE, \u0026amp;quot;json\u0026amp;quot;); ExampleObj obj = new ExampleObj(); obj.setId(1); obj.setName(\u0026amp;quot;xxx\u0026amp;quot;); byte[] bytes = mapper.writeValueAsBytes(obj); ByteArrayEntity entity = new ByteArrayEntity(bytes, ContentType.create(\u0026amp;quot;application/json\u0026amp;quot;)); httpPost.setEntity(entity); HttpResponse httpResponse = httpclient.execute(httpPost); Assert.assertEquals(200, httpResponse.getStatusLine().getStatusCode()); byte[] data = EntityUtils.toByteArray(httpResponse.getEntity()); ExampleObj result = mapper.readValue(data, ExampleObj.class); Assert.assertEquals(\u0026amp;quot;xxxxx\u0026amp;quot;, result.getName()); You will get some result.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http-json/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"28abdf6369247346bad670c639a422b8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/http-json/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/http-json/","summary":"In SOFARPC (Not In SOFABoot/SpringBoot)，when use Http as a protocol of server，we can use Json as the way of serialization，for some basic test scenes.\nSOFARPC API Usage Service Publish ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); ProviderConfig\u0026lt;HttpService\u0026gt; providerConfig = new ProviderConfig\u0026lt;HttpService\u0026gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026quot;serverApp\u0026quot;)) .setServer(serverConfig) .setUniqueId(\u0026quot;uuu\u0026quot;) .setRegister(false); providerConfig.export(); Service Consume Because of the Http+Json，So users can use HttpClient to start a normal call, this is a piece of code in test.","tags":null,"title":"Basic usage of HTTP protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/http-json/","wordcount":140},{"author":null,"categories":null,"content":" In SOFARPC, using different communication protocols is equal to using different Bindings. If you need to use the RESTful protocol, just set Binding to REST.\nPublish Service When defining a RESTful service interface, you need to add meta information to the interface using the annotations in JAXRS standard, such as the following interface:\n@Path(\u0026amp;quot;sample\u0026amp;quot;) public interface SampleService { @GET @Path(\u0026amp;quot;hello\u0026amp;quot;) String hello(); } The annotations in JAXRS standard can be found in RESTEasy documentation.\n After the interface is defined, you can publish the implementation of the interface as a service, for example, by means of Annotation:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}) public class RestfulSampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } If you want to publish the service by other methods, please refer to Basic usage of Bolt protocol.\nAccess services through browser After the service is published, you can directly access the service through the browser. For the above service, the access address is as follows:\nhttp://localhost:8341/sample/hello The default port for SOFARPC RESTful service is 8341.\nReference Service In addition to accessing RESTful services published by SOFARPC through a browser, you can also reference services through the standard SOFARPC service reference methods, such as Annotation:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)) private SampleService sampleService; If you want to reference the service by other methods, please refer to Basic usage of Bolt protocol.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-basic/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d41f976864ba8f8221f5b5d26f354d1c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-basic/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-basic/","summary":"In SOFARPC, using different communication protocols is equal to using different Bindings. If you need to use the RESTful protocol, just set Binding to REST.\nPublish Service When defining a RESTful service interface, you need to add meta information to the interface using the annotations in JAXRS standard, such as the following interface:\n@Path(\u0026quot;sample\u0026quot;) public interface SampleService { @GET @Path(\u0026quot;hello\u0026quot;) String hello(); } The annotations in JAXRS standard can be found in RESTEasy documentation.","tags":null,"title":"Basic usage of RESTful protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-basic/","wordcount":228},{"author":null,"categories":null,"content":" Benchmark 源码解析任务还在进行中，敬请期待！\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-benchmark/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fdcbd9e5c563ad087756f0703f94db61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","summary":"Benchmark 源码解析任务还在进行中，敬请期待！","tags":null,"title":"Benchmark","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","wordcount":18},{"author":null,"categories":null,"content":" Test code\nTest environment and conditions Three 16-core 20 GB memory Docker containers as the server nodes (3 replicas) Two to eight 8-core Docker containers as clients 24 Raft groups. Each server node has eight leaders responsible for processing read/right requests. Followers do not have the permission to read. The target of stress testing is the RheaKV module of JRaft. Only the put and get APIs are subject to stress testing. Linearizable reads are guaranteed for the get API. The key size and value size are both 16 bytes. The read percentage is 10% and the write percentage is 90%. Currently, the test scenarios are relatively simple. We will add more test scenarios in the future.\nTest scenario 1 Scenario 1: Test conditions Number of clients Client batching Storage type Read/write ratio Replicator pipeline Key size Value size 8 Enabled MemoryDB 1:9 Enabled 16 bytes 16 bytes Scenario 1: Result summary Eight clients achieved 400,000+ ops, and the p95 RT is within 8 ms. Three server nodes didn\u0026amp;rsquo;t reach their maximum load. The load is about 15, and the CPU usage is about 40%. Scenario 1: Load of three servers Scenario 1: Server 1 top - 20:11:14 up 10 days, 23:09, 1 user, load average: 12.29, 6.92, 4.00 Tasks: 36 total, 1 running, 35 sleeping, 0 stopped, 0 zombie %Cpu0 : 24.3 us, 17.7 sy, 0.0 ni, 50.0 id, 2.0 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu1 : 21.9 us, 18.5 sy, 0.0 ni, 49.5 id, 2.0 wa, 0.0 hi, 0.0 si, 8.1 st %Cpu2 : 20.6 us, 18.6 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 5.6 st %Cpu3 : 23.3 us, 20.0 sy, 0.0 ni, 50.3 id, 1.3 wa, 0.0 hi, 0.0 si, 5.0 st %Cpu4 : 24.1 us, 19.1 sy, 0.0 ni, 49.8 id, 2.3 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu5 : 21.3 us, 18.9 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu6 : 24.7 us, 18.4 sy, 0.0 ni, 50.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu7 : 24.8 us, 17.8 sy, 0.0 ni, 50.0 id, 1.7 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu8 : 26.0 us, 18.3 sy, 0.0 ni, 51.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu9 : 26.6 us, 16.9 sy, 0.0 ni, 52.2 id, 2.0 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu10 : 31.7 us, 17.7 sy, 0.0 ni, 46.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu11 : 23.2 us, 18.9 sy, 0.0 ni, 53.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu12 : 25.6 us, 18.3 sy, 0.0 ni, 51.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu13 : 22.6 us, 18.3 sy, 0.0 ni, 54.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu14 : 24.7 us, 17.3 sy, 0.0 ni, 54.0 id, 1.7 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu15 : 61.8 us, 8.3 sy, 0.0 ni, 28.2 id, 0.3 wa, 0.0 hi, 0.0 si, 1.3 st KiB Mem : 62914560 total, 6854596 free, 39128016 used, 16931948 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 6854596 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15682 root 20 0 12.853g 8.859g 24064 S 708.7 14.8 26:49.38 java Scenario 1: Server 2 top - 20:11:47 up 10 days, 23:03, 1 user, load average: 17.68, 8.50, 4.56 Tasks: 33 total, 1 running, 31 sleeping, 0 stopped, 1 zombie %Cpu0 : 22.7 us, 17.3 sy, 0.0 ni, 35.0 id, 8.3 wa, 0.0 hi, 0.0 si, 16.7 st %Cpu1 : 20.1 us, 19.4 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/benchmark-performance/","fuzzywordcount":8900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4530827525ca87732eaf76ae34f03603","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","publishdate":"0001-01-01T00:00:00Z","readingtime":42,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","summary":"Test code\nTest environment and conditions Three 16-core 20 GB memory Docker containers as the server nodes (3 replicas) Two to eight 8-core Docker containers as clients 24 Raft groups. Each server node has eight leaders responsible for processing read/right requests. Followers do not have the permission to read. The target of stress testing is the RheaKV module of JRaft. Only the put and get APIs are subject to stress testing.","tags":null,"title":"Benchmark data","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","wordcount":8817},{"author":null,"categories":null,"content":" 测试代码\n测试环境\u0026amp;amp;条件 3 台 16C 20G 内存的 docker 容器作为 server node (3 副本) 2 ~ 8 台 8C docker 容器 作为 client 24 个 raft 复制组，平均每台 server node 上各自有 8 个 leader 负责读写请求，不开启 follower 读 压测目标为 JRaft 中的 RheaKV 模块，只压测 put、get 两个接口，其中 get 是保证线性一致读的，key 和 value 大小均为 16 字节 读比例 10%，写比例 90% 目前的测试场景比较简单，以后会增加更多测试场景\n测试场景1 场景1: 测试条件 Client 数量 Client-Batching Storage-Type 读写比例 Replicator-Pipeline key 大小 value 大小 8 开启 MemoryDB 1:9 开启 16 字节 16字节 场景1: 结果汇总： 8 个 client 一共达到 40w+ ops，p95 RT 在 8ms 以内 3 个 server 节点负载没达到极限 load 15 左右，cpu 40% 左右 场景1: 3 个 server 机器负载： 场景1: server1 top - 20:11:14 up 10 days, 23:09, 1 user, load average: 12.29, 6.92, 4.00 Tasks: 36 total, 1 running, 35 sleeping, 0 stopped, 0 zombie %Cpu0 : 24.3 us, 17.7 sy, 0.0 ni, 50.0 id, 2.0 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu1 : 21.9 us, 18.5 sy, 0.0 ni, 49.5 id, 2.0 wa, 0.0 hi, 0.0 si, 8.1 st %Cpu2 : 20.6 us, 18.6 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 5.6 st %Cpu3 : 23.3 us, 20.0 sy, 0.0 ni, 50.3 id, 1.3 wa, 0.0 hi, 0.0 si, 5.0 st %Cpu4 : 24.1 us, 19.1 sy, 0.0 ni, 49.8 id, 2.3 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu5 : 21.3 us, 18.9 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu6 : 24.7 us, 18.4 sy, 0.0 ni, 50.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu7 : 24.8 us, 17.8 sy, 0.0 ni, 50.0 id, 1.7 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu8 : 26.0 us, 18.3 sy, 0.0 ni, 51.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu9 : 26.6 us, 16.9 sy, 0.0 ni, 52.2 id, 2.0 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu10 : 31.7 us, 17.7 sy, 0.0 ni, 46.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu11 : 23.2 us, 18.9 sy, 0.0 ni, 53.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu12 : 25.6 us, 18.3 sy, 0.0 ni, 51.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu13 : 22.6 us, 18.3 sy, 0.0 ni, 54.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu14 : 24.7 us, 17.3 sy, 0.0 ni, 54.0 id, 1.7 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu15 : 61.8 us, 8.3 sy, 0.0 ni, 28.2 id, 0.3 wa, 0.0 hi, 0.0 si, 1.3 st KiB Mem : 62914560 total, 6854596 free, 39128016 used, 16931948 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 6854596 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15682 root 20 0 12.853g 8.859g 24064 S 708.7 14.8 26:49.38 java 场景1: server2 top - 20:11:47 up 10 days, 23:03, 1 user, load average: 17.68, 8.50, 4.56 Tasks: 33 total, 1 running, 31 sleeping, 0 stopped, 1 zombie %Cpu0 : 22.7 us, 17.3 sy, 0.0 ni, 35.0 id, 8.3 wa, 0.0 hi, 0.0 si, 16.7 st %Cpu1 : 20.1 us, 19.4 sy, 0.0 ni, 43.8 id, 9.4 wa, 0.0 hi, 0.0 si, 7.4 st %Cpu2 : 23.3 us, 20.0 sy, 0.0 ni, 39.7 id, 10.3 wa, 0.0 hi, 0.0 si, 6.7 st %Cpu3 : 24.1 us, 20.1 sy, 0.0 ni, 40.8 id, 9.4 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu4 : 21.4 us, 17.7 sy, 0.0 ni, 37.1 id, 9.0 wa, 0.0 hi, 0.0 si, 14.7 st %Cpu5 : 22.6 us, 19.6 sy, 0.0 ni, 40.5 id, 10.6 wa, 0.0 hi, 0.0 si, 6.6 st %Cpu6 : 23.6 us, 19.9 sy, 0.0 ni, 40.2 id, 10.3 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu7 : 20.5 us, 19.9 sy, 0.0 ni, 44.4 id, 9.9 wa, 0.0 hi, 0.0 si, 5.3 st %Cpu8 : 40.7 us, 13.3 sy, 0.0 ni, 34.3 id, 9.0 wa, 0.0 hi, 0.0 si, 2.7 st %Cpu9 : 39.9 us, 14.0 sy, 0.0 ni, 35.2 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/benchmark-performance/","fuzzywordcount":9300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4530827525ca87732eaf76ae34f03603","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/benchmark-performance/","publishdate":"0001-01-01T00:00:00Z","readingtime":19,"relpermalink":"/sofastack.tech/projects/sofa-jraft/benchmark-performance/","summary":"测试代码 测试环境\u0026amp;条件 3 台 16C 20G 内存的 docker 容器作为 server node (3 副本) 2 ~ 8 台 8C docker 容器 作为 client 24 个 raft 复制组，平均每台 server node 上各自有 8 个 leader 负责读写请求","tags":null,"title":"Benchmark 数据","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/benchmark-performance/","wordcount":9269},{"author":null,"categories":null,"content":"Bolt protocol is a TCP-based custom protocol that performs better than HTTP. Within Ant Financial, a large number of RPCs use the Bolt protocol to communicate: * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b812f6aadadf38b79140a711ff6aa6cd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt/","summary":"Bolt protocol is a TCP-based custom protocol that performs better than HTTP. Within Ant Financial, a large number of RPCs use the Bolt protocol to communicate: * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool","tags":null,"title":"Bolt protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt/","wordcount":45},{"author":null,"categories":null,"content":"Bolt 协议一个基于 TCP 的自定义的协议，相比 HTTP 来说，性能更好，在蚂蚁金服内部，大量的 RPC 都是采用 Bolt 协议来进行通信： * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化协议 * 自定义线程池\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b812f6aadadf38b79140a711ff6aa6cd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt/","summary":"Bolt 协议一个基于 TCP 的自定义的协议，相比 HTTP 来说，性能更好，在蚂蚁金服内部，大量的 RPC 都是采用 Bolt 协议来进行通信： * 基本使用 * 调用方式 * 超时控制 * 泛化","tags":null,"title":"Bolt 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt/","wordcount":85},{"author":null,"categories":null,"content":" Bolt 协议基本使用 发布服务 使用 SOFARPC 发布一个 Bolt 协议的服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下：\nXML 使用 XML 发布一个 Bolt 协议只需要在 \u0026amp;lt;sofa:service\u0026amp;gt; 标签下增加 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签即可：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation 使用 Annotation 发布一个 Bolt 协议的服务只需要设置 @SofaServiceBinding 的 bindingType 为 bolt 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Spring 环境下 API 方式 在 Spring 或者 Spring Boot 环境下发布一个 Bolt 协议的服务只需要往 ServiceParam 里面增加一个 BoltBindingParam 即可：\nServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(SampleService.class); // 设置服务接口 serviceParam.setInstance(new SampleServiceImpl()); // 设置服务接口的实现 List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); 非 Spring 环境下的 API 方式 在非 Spring 环境下使用 SOFARPC 的裸 API 提供 Bolt 协议的服务，只需要将 Protocol 为 Bolt 的 ServerConfig 设置给对应的 ProviderConfig：\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;); // 新建一个协议为 Bolt 的 ServerConfig ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRef(new SampleServiceImpl()) .setServer(serverConfig) // 将 ServerConfig 设置给 ProviderConfig，表示这个服务发布的协议为 Bolt。 .setRegistry(registryConfig); providerConfig.export(); 引用服务 使用 SOFARPC 引用一个 Bolt 服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下：\nXML 使用 XML 引用一个 Bolt 协议的服务只需要在 \u0026amp;lt;sofa:reference\u0026amp;gt; 标签下增加 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签即可：\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 使用 Annotation 引用一个 Bolt 协议的服务只需要设置 @SofaReferenceBinding 的 bindingType 为 bolt 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private SampleService sampleService; Spring 环境下 API 方式 在 Spring 或者 Spring Boot 环境下引用一个 Bolt 协议的服务只需要往 ReferenceParam 里面增加一个 BoltBindingParam 即可：\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;SampleService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;SampleService\u0026amp;gt;(); referenceParam.setInterfaceType(SampleService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); 非 Spring 环境下的 API 方式 在非 Spring 环境下使用 SOFARPC 的裸 API 引用一个 Bolt 协议的服务，只需要设置 ConsumerConfig 的 Protocol 为 bolt 即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-usage/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dd929c0a3cd2f4620ddf0d30d98ba85d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt-usage/","summary":"Bolt 协议基本使用 发布服务 使用 SOFARPC 发布一个 Bolt 协议的服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下： XML 使用 XML 发布一个 Bolt 协议只需要","tags":null,"title":"Bolt 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt-usage/","wordcount":570},{"author":null,"categories":null,"content":" 泛化调用提供了让客户端在不需要依赖服务端的接口情况下就能够发起调用的能力。目前 SOFARPC 的泛化调用仅支持在 Bolt 通信协议下使用 Hessian2 作为序列化协议，其他的方式并不支持。\nSOFABoot 环境 发布服务 发布服务没有什么特殊的,正常发布服务即可.比如\n\u0026amp;lt;!-- generic --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 引用服务 \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.api.GenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs generic-interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 其中,jvm-first根据实际情况,默认可以不写,接口写泛化调用的通用接口,generic-interface中写上自己要调用的接口名称即可.\n发起调用 GenericService sampleGenericServiceReference = (GenericService) applicationContext .getBean(\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot;); GenericObject genericResult = (GenericObject) sampleGenericServiceReference.$genericInvoke(\u0026amp;quot;sayGeneric\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericParamModel\u0026amp;quot; }, new Object[] { genericObject }); RPC API ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt;() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); 如上通过 setGeneric 设置该服务为泛化服务，设置服务方的接口名。以 GenericService 作为泛化服务，通过 GenericService 就能够发起泛化调用了。发起调用时，需要传入方法名，方法类型，方法参数。\n如果参数或者返回结果在客户端也需要泛化表示。可以通过 GenericObject 来实现。\nGenericObject genericObject = new GenericObject(\u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot;); genericObject.putField(\u0026amp;quot;str\u0026amp;quot;, \u0026amp;quot;xxxx\u0026amp;quot;); genericObject.putField(\u0026amp;quot;num\u0026amp;quot;, 222); GenericObject result = (GenericObject) testService.$genericInvoke(\u0026amp;quot;echoObj\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot; }, new Object[] { genericObject }); String str = result.getField(\u0026amp;quot;str\u0026amp;quot;); String num = result.getField(\u0026amp;quot;num\u0026amp;quot;); 如上就能获得序列化结果。完整的泛化调用方式使用说明如下：\n/** * Java Bean */ public class People { private String name; private int age; // getters and setters } /** * 服务方提供的接口 */ interface SampleService { String hello(String arg); People hello(People people); String[] hello(String[] args); } /** * 客户端 */ public class ConsumerClass { GenericService genericService; public void do() { // 1. $invoke仅支持方法参数类型在当前应用的 ClassLoader 中存在的情况 genericService.$invoke(\u0026amp;quot;hello\u0026amp;quot;, new String[]{ String.class.getName() }, new Object[]{\u0026amp;quot;I\u0026#39;m an arg\u0026amp;quot;}); // 2. $genericInvoke支持方法参数类型在当前应用的 ClassLoader 中不存在的情况。 // 2.1 构造参数 GenericObject genericObject = new …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/generic-invoke/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"84ac624dc99a42a8f89489aa10304ef7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/generic-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/generic-invoke/","summary":"泛化调用提供了让客户端在不需要依赖服务端的接口情况下就能够发起调用的能力。目前 SOFARPC 的泛化调用仅支持在 Bolt 通信协议下使用 Hessian2 作为序列化协议，其他的方","tags":null,"title":"Bolt 协议泛化调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/generic-invoke/","wordcount":710},{"author":null,"categories":null,"content":" 调用方式 SOFARPC 在 Bolt 协议下提供了多种调用方式满足不同的场景。\n同步 在同步的调用方式下，客户端发起调用后会等待服务端返回结果再进行后续的操作。这是 SOFARPC 的默认调用方式，无需进行任何设置即可。\n异步 异步调用的方式下，客户端发起调用后不会等到服务端的结果，继续执行后面的业务逻辑。服务端返回的结果会被 SOFARPC 缓存，当客户端需要结果的时候，再主动调用 API 获取。如果需要将一个服务设置为异步的调用方式，在对应的使用方式下设置 type 属性即可：\nXML 方式 在 XML 方式下，设置 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 type 属性为 future 即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 在 Annotation 方式下，设置 @SofaReferenceBinding 的 invokeType 属性为 future 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, invokeType = \u0026amp;quot;future\u0026amp;quot;)) private SampleService sampleService; Spring 环境下 API 方式 在 Spring 环境下使用 API，设置 BoltBindingParam 的 type 属性即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setType(\u0026amp;quot;future\u0026amp;quot;); 在非 Spring 环境下 API 方式 在非 Spring 环境下使用 SOFARPC 裸 API，设置 ConsumerConfig 的 invokeType 属性即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setInvokeType(\u0026amp;quot;future\u0026amp;quot;); 获取调用结果 使用异步调用的方式，目前提供了两种方式来获取异步调用的结果：\n直接获取结果 用户可以通过以下的方式来直接获取异步调用的结果：\nString result = (String)SofaResponseFuture.getResponse(0, true); 其中第一个参数是获取结果的超时时间，第二个参数表示是否清除线程上下文中的结果。\n获取 JDK 原生 Future 用户可以通过以下的方式来获取 JDK 的原生的 Future 对象，再可以从任意地方去调用这个 Future 对象来获取结果：\nFuture future = SofaResponseFuture.getFuture(true); 其中的第一个参数表示是否清除线程上下文中的结果。\n回调 SOFARPC Bolt 协议的回调方式可以让 SOFARPC 在发起调用后不等待结果，在客户端收到服务端返回的结果后，自动回调用户实现的一个回调接口。\n使用 SOFARPC Bolt 协议的回调方式，首先需要实现一个回调接口，并且在对应的配置中设置回调接口，再将调用方式设置为 callback。\n实现回调接口 SOFARPC 提供了一个回调的接口 com.alipay.sofa.rpc.core.invoke.SofaResponseCallback，用户使用 SOFARPC Bolt 协议的回调方式，首先需要实现这个接口，该接口提供了三个方法：\n onAppResponse：当客户端接收到服务端的正常返回的时候，SOFARPC 会回调这个方法。 onAppException：当客户端接收到服务端的异常响应的时候，SOFARPC 会回调这个方法。 onSofaException：当 SOFARPC 本身出现一些错误，比如路由错误的时候，SOFARPC 会回调这个方法。 设置回调接口 实现回调接口之后，用户需要将实现类设置到对应的服务引用配置中，并且将调用方式设置为 callback。\nSOFARPC 为设置回调接口提供了两种方式，分别为 Callback Class 和 Callback Ref。Callback Class 的方式直接设置回调的类名，SOFARPC 会通过调用回调类的默认构造函数的方式生成回调类的实例。Callback Ref 的方式则为用户直接提供回调类的实例。\nXML 方式 如果通过 XML 的方式引用服务，将 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 type 属性设置为 callback，并且设置 callback-ref 或者 callback-class 属性即可：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleCallback\u0026amp;quot; class=\u0026amp;quot;com.example.demo.SampleCallback\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;callback\u0026amp;quot; callback-ref=\u0026amp;quot;sampleCallback\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 在 XML 的方式下，callback-ref 的值需要是回调类的 Bean 名称。\nAnnotation 方式 如果通过 Annotation 的方式引用服务，设置 @SofaReferenceBinding 注解的 invokeType 属性为 callback，并且设置 callbackClass 或者 callbackRef 属性即可：\n@SofaReference(binding = …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-type/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e296d9344b6aa9f550e6213b97da084b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/invoke-type/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/invoke-type/","summary":"调用方式 SOFARPC 在 Bolt 协议下提供了多种调用方式满足不同的场景。 同步 在同步的调用方式下，客户端发起调用后会等待服务端返回结果再进行后续的操作。这是 SOFARPC 的","tags":null,"title":"Bolt 协议调用方式","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/invoke-type/","wordcount":1619},{"author":null,"categories":null,"content":" 超时控制 使用 Bolt 协议进行通信的时候，SOFARPC 的超时时间默认为 3 秒，用户可以在引用服务的时候去设置超时时间，又分别可以在服务以及方法的维度设置超时时间，SOFARPC 的超时时间的设置的单位都为毫秒。\n服务维度 如果需要在发布服务的时候在服务维度设置超时时间，设置对应的 timeout 参数到对应的值即可。\nXML 方式 如果使用 XML 的方式引用服务，设置 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签下的 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 timeout 属性的值即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 如果使用 Annotation 引用服务，设置 @SofaReferenceBinding 的 timeout 属性的值即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, timeout = 2000)) private SampleService sampleService; Spring 环境 API 方式 如果在 Spring 或者 Spring Boot 的环境下引用服务，设置 BoltBindingParam 的 timeout 属性的值即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setTimeout(2000) 非 Spring 环境下 API 方式 如果在非 Spring 环境下直接使用 SOFARPC 的裸 API 引用服务，设置 ConsumerConfig 的 timeout 属性即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setTimeout(2000); 方法维度 如果想要单独调整一个服务中某一个方法的超时时间，可以通过在方法维度上设置超时时间来实现。\n对于某一个方法来说，优先方法维度的超时时间，如果没有设置，则使用服务维度的超时时间。\nXML 方式 如果使用 XML 的方式引用一个服务，设置对应的 \u0026amp;lt;sofa:method\u0026amp;gt; 标签的 timeout 属性即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 目前暂未提供通过 Annotation 的方式来设置方法级别的超时时间。\nSpring 环境 API 方式 如果在 Spring 或者 Spring Boot 的环境下引用服务，设置 RpcBindingMethodInfo 的 timeout 属性的值即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); RpcBindingMethodInfo rpcBindingMethodInfo = new RpcBindingMethodInfo(); rpcBindingMethodInfo.setName(\u0026amp;quot;hello\u0026amp;quot;); rpcBindingMethodInfo.setTimeout(2000); List\u0026amp;lt;RpcBindingMethodInfo\u0026amp;gt; rpcBindingMethodInfos = new ArrayList\u0026amp;lt;\u0026amp;gt;(); rpcBindingMethodInfos.add(rpcBindingMethodInfo); boltBindingParam.setMethodInfos(rpcBindingMethodInfos); 非 Spring 环境 API 方式 如果在非 Spring 环境下使用 SOFARPC 的裸 API 引用服务，设置 MethodConfig 的 timeout 属性即可：\nMethodConfig methodConfig = new MethodConfig(); methodConfig.setName(\u0026amp;quot;hello\u0026amp;quot;); methodConfig.setTimeout(2000); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfig); ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setMethods(methodConfigs); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-timeout/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cf14f73dc0c4672a9255ef55b56de419","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt-timeout/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt-timeout/","summary":"超时控制 使用 Bolt 协议进行通信的时候，SOFARPC 的超时时间默认为 3 秒，用户可以在引用服务的时候去设置超时时间，又分别可以在服务以及方法的维度","tags":null,"title":"Bolt 协议超时控制","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt-timeout/","wordcount":584},{"author":null,"categories":null,"content":" As one of the developing directions of cloud native technology, Serverless architecture enables you to further improve resource utilization and focus on service development. With our workshop, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, and quick troubleshooting via log viewer.\nWorkshop procedure Flow diagram Preview Preparation Access to Serverless application service address Login with account and password Git clone this project to local Step 1-1: Publish backend Java application Select Create quickly Select Java Runtime Upload the code package balance-mng.jar The entry method can be automatically recognized Port: 8080 Copy and save the backend service address after creation View the number of computing instances of backend service: 0 Step 1-2: Publish frontend NodeJS application Select create an application Select the buildpack NodeJS Upload the code package stock-mng.zip The entry method can be automatically recognized Select nodejs-0.0.1.1-pre at runtime Port: 3000 Set the environment variable BALANCEMNG_URL as the backend service address Step 2: 0-1 cold boot capability Access frontend service View the changes in the number of the computing instances of backend service Step 3: Log and monitoring View application service logs via Log Shell View usage amount via monitoring Step 4: Configure time trigger Configure timing trigger to call application at fixed time View the triggering results via operation records Step 5: Create versions and control traffic Clone the frontend application and create a new version Upload the code package stock-mng-v2.zip Configure router to visit V1 and V2 at 1:1 ratio View the effect in the browser Step 6: Quick M-n capability for high-concurrency Simulate high concurrency situtation via scripts and access the frontend application service Check how the Serverless application perform quick M-N computing instance changes ","date":-62135596800,"description":"With this guide, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, quick troubleshooting via log viewer, and application startup at fixed time.","dir":"guides/kc-serverless-demo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f355d1b598fed47b730bd74ad25f3683","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-serverless-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/guides/kc-serverless-demo/","summary":"As one of the developing directions of cloud native technology, Serverless architecture enables you to further improve resource utilization and focus on service development. With our workshop, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, and quick troubleshooting via log viewer.\nWorkshop procedure Flow diagram Preview Preparation Access to Serverless application service address Login with account and password Git clone this project to local Step 1-1: Publish backend Java application Select Create quickly Select Java Runtime Upload the code package balance-mng.","tags":null,"title":"Build applications on the cloud based on Serverless","type":"guides","url":"/sofastack.tech/en/guides/kc-serverless-demo/","wordcount":290},{"author":null,"categories":null,"content":" Procedure This guide introduces how to quickly build a microservice based on SOFAStack. It mainly includes the following steps.\n Publish service using SOFABoot and SOFARPC Call service using SOFABoot and SOFARPC View Tracer information reported by SOFATracer via ZipKin View Metrics information via SOFALookout Architecture Tasks 1. Preparation Clone the project demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git Import the project into IDEA or Eclipse. After import, the interface is as follows:\n balance-mng: account management system, providing deduction balance service stock-mng: account system, providing deduction inventory service 2. Introduce dependencies Add the following dependencies into the pom.xml files of balance-mng and stock-mng project modules.\n\u0026amp;lt;!--SOFARPC dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFATracer dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFARegistry dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--runtime dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFALookout dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; For balance-mng project, you need to introduce the dependencies into the pom file of balance-mng-imp module.\nFor stock-mng project, you need to introduce the dependencies into the pom file of stock-mng module.\n3. Add configurations Copy the following configurations into the application.properties file of balance-mng and stock-mng project module.\n# 1、Add Service Registry address com.alipay.sofa.rpc.registry.address=sofa://118.31.43.62:9603 # 2、Add the zipkin address where tracer data is reported com.alipay.sofa.tracer.zipkin.base-url=http://139.224.123.199:9411 # 3、Add the server-side address where the metrics data is reported com.alipay.sofa.lookout.agent-host-address=139.224.123.35 For balance-mng project, you need to add configurations to the application.properties file in balance-mng-bootstrap module.\nFor stock-mng project, you need to add configurations to the application.properties file in stock-mng module.\n4. Modify unique id Since everyone shares a set of service discoveries, to differentiate the services published by different users, it is required to add a unique id to the service.\nKubeCon workshop will prepare a SOFAStack account for each user in the format ofuser0@sofastack.io to user99@sofastack.io. The first half of the account, namely …","date":-62135596800,"description":"This guide introduces how to quickly build a microservice based on SOFAStack. ","dir":"guides/sofastack-quick-start/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"78bfd4806a86dc15ac86eee16fb85c82","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/sofastack-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/guides/sofastack-quick-start/","summary":"Procedure This guide introduces how to quickly build a microservice based on SOFAStack. It mainly includes the following steps.\n Publish service using SOFABoot and SOFARPC Call service using SOFABoot and SOFARPC View Tracer information reported by SOFATracer via ZipKin View Metrics information via SOFALookout Architecture Tasks 1. Preparation Clone the project demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git Import the project into IDEA or Eclipse. After import, the interface is as follows:","tags":null,"title":"Build microservices with SOFAStack","type":"guides","url":"/sofastack.tech/en/guides/sofastack-quick-start/","wordcount":586},{"author":null,"categories":null,"content":" SOFARPC provides a variety of calling types under the Bolt protocol to meet different scenarios.\nSynchronous In the synchronous calling type, after the client initiates a call, it will wait for the server to return the result and then perform subsequent operations. This is the default calling type of SOFARPC.\nAsynchronous In the asynchronous calling type, after the client initiates a call, it will not wait for the result from the server but continue to execute the subsequent business logic. The result returned by the server will be cached by SOFARPC. When the client needs the result, it can call the API to get the result. To set a service to be asynchronous, you can configure the type attribute in the corresponding usage mode:\nXML In the XML mode, set the type attribute of the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag to future:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation In Annotation mode, set the invokeType attribute of @SofaReferenceBinding to future:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, invokeType = \u0026amp;quot;future\u0026amp;quot;)) private SampleService sampleService; API in Spring environment When using the API in Spring environment, you just need to set the type attribute of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setType(\u0026amp;quot;future\u0026amp;quot;); API in non-Spring environment When using the bare API of SOFARPC in a non-Spring environment, you just need to set the invokeType attribute of ConsumerConfig:\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setInvokeType(\u0026amp;quot;future\u0026amp;quot;); Get the calling result Currently, there are two ways to get the result of an asynchronous call:\nGet result directly You can directly get the result of an asynchronous call in the following way:\nString result = (String)SofaResponseFuture.getResponse(0, true); The first parameter is the timeout period for getting the result, and the second parameter indicates whether to clear the result in the thread context.\nGet JDK native Future You can get the JDK native Future object in the following way, and then call the Future object from anywhere to get the result:\nFuture future = SofaResponseFuture.getFuture(true); The first parameter indicates whether to clear the result in the thread context.\nCallback By using the callback type of the SOFARPC Bolt protocol, SOFARPC doesn\u0026amp;rsquo;t need to wait for the result after initiating a call. After the client receives the result returned from the server, it can automatically call back a callback interface implemented by the user.\nTo use the callback type of the SOFARPC Bolt protocol, you first need to …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-type/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e296d9344b6aa9f550e6213b97da084b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/invoke-type/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/invoke-type/","summary":"SOFARPC provides a variety of calling types under the Bolt protocol to meet different scenarios.\nSynchronous In the synchronous calling type, after the client initiates a call, it will wait for the server to return the result and then perform subsequent operations. This is the default calling type of SOFARPC.\nAsynchronous In the asynchronous calling type, after the client initiates a call, it will not wait for the result from the server but continue to execute the subsequent business logic.","tags":null,"title":"Calling type","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/invoke-type/","wordcount":908},{"author":null,"categories":null,"content":" Client built-in extension metrics The extension modules currently in effect by default are lookout-ext-jvm and lookout-ext-os (from v1.5.0).\nJVM thread metric name metric tags specification jvm.threads.totalStarted \u0026amp;mdash; jvm.threads.active \u0026amp;mdash; jvm.threads.peak \u0026amp;mdash; jvm.threads.daemon \u0026amp;mdash; JVM class loading metric name metric tags specification jvm.classes.unloaded \u0026amp;mdash; jvm.classes.loaded \u0026amp;mdash; jvm.classes.total \u0026amp;mdash; JVM memory metric name metric tags specification jvm.memory.heap.init \u0026amp;mdash; jvm.memory.heap.used \u0026amp;mdash; jvm.memory.heap.max \u0026amp;mdash; jvm.memory.heap.committed \u0026amp;mdash; JVM garbage recycling metric name metric tags specification jvm.gc.young.time \u0026amp;mdash; jvm.gc.young.count \u0026amp;mdash; jvm.gc.old.time \u0026amp;mdash; jvm.gc.old.count \u0026amp;mdash; Machine file system information metric name metric tags specification instance.file.system.free.space root（the available filesystem roots） \u0026amp;mdash; instance.file.system.total.space root \u0026amp;mdash; instance.file.system.usabe.space root \u0026amp;mdash; Machine information metric name metric tags specification instance.mem.free \u0026amp;mdash; instance.mem.total \u0026amp;mdash; instance.processors \u0026amp;mdash; instance.uptime \u0026amp;mdash; instance.systemload.average \u0026amp;mdash; Linux operating system information (enabled by default after version 1.5.0) metric name metric tags specification os.systemload.average.1min \u0026amp;mdash; os.systemload.average.5min \u0026amp;mdash; os.systemload.average.15min \u0026amp;mdash; os.cpu.idle \u0026amp;mdash; os.cpu.iowait \u0026amp;mdash; os.cpu.irq \u0026amp;mdash; os.cpu.nice \u0026amp;mdash; os.cpu.softirq \u0026amp;mdash; os.cpu.system \u0026amp;mdash; os.cpu.user \u0026amp;mdash; os.disk.usage.percent.used device,root,type \u0026amp;mdash; os.disk.usage.total.bytes device,root,type \u0026amp;mdash; os.disk.usage.used.bytes device,root,type \u0026amp;mdash; os.net.stats.in.bytes intfc \u0026amp;mdash; os.net.stats.in.compressed intfc \u0026amp;mdash; os.net.stats.in.dropped intfc \u0026amp;mdash; os.net.stats.in.errs intfc \u0026amp;mdash; os.net.stats.in.fifo.errs intfc \u0026amp;mdash; os.net.stats.in.frame.errs intfc \u0026amp;mdash; os.net.stats.in.multicast intfc \u0026amp;mdash; os.net.stats.in.packets intfc \u0026amp;mdash; os.net.stats.out.bytes intfc \u0026amp;mdash; os.net.stats.out.carrier.errs intfc \u0026amp;mdash; os.net.stats.out.collisions intfc \u0026amp;mdash; os.net.stats.out.compressed intfc \u0026amp;mdash; os.net.stats.out.dropped intfc \u0026amp;mdash; os.net.stats.out.errs intfc \u0026amp;mdash; os.net.stats.out.fifo.errs intfc \u0026amp;mdash; os.net.stats.out.packets intfc \u0026amp;mdash; os.memory.stats.buffers.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.cached.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.free.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.total.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-ext-metrics/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c8a4fb3d904e359e99db9d4e81e60812","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","summary":"Client built-in extension metrics The extension modules currently in effect by default are lookout-ext-jvm and lookout-ext-os (from v1.5.0).\nJVM thread metric name metric tags specification jvm.threads.totalStarted \u0026mdash; jvm.threads.active \u0026mdash; jvm.threads.peak \u0026mdash; jvm.threads.daemon \u0026mdash; JVM class loading metric name metric tags specification jvm.classes.unloaded \u0026mdash; jvm.","tags":null,"title":"Client built-in extension metrics","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","wordcount":224},{"author":null,"categories":null,"content":"The client module is a complex module which contains cluster, router, address holder，connection holder, and load balancer, and interacts with proxy, registry center and other modules.\nSee the following flow chart:\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/client-invoke-flow/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"310d99d64b808a3b526563e92c699952","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","summary":"The client module is a complex module which contains cluster, router, address holder，connection holder, and load balancer, and interacts with proxy, registry center and other modules.\nSee the following flow chart:","tags":null,"title":"Client call flow","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","wordcount":31},{"author":null,"categories":null,"content":" Client configuration example lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026amp;quot;127.0.0.1\u0026amp;quot;); Description of server configuration item Configuration item Corresponding SpringBoot configuration item Default value Description lookout.enable com.alipay.sofa.lookout.enable true Function switch, it defaults to true. If you change it to false (empty objects and empty methods), then all metrics comsume almost no memory and computing resource lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 Maximum number limit of metrics, over which will be automatically ignored lookout.prometheus.exporter.server.port com.alipay.sofa.lookout.prometheus-exporter-server-port 9494 The port got by Prometheus Lookout.exporter.enable com.alipay.sofa.lookout.exporter-enable false Whether or not to enable services that support passive collection Lookout.agent.host.address com.alipay.sofa.lookout.agent-host-address - Proactively report the annotation address of the Agent server. Multiple addresses are separated by commas Description of client log configuration Configuration item of system property Corresponding SpringBoot configuration item Default Value Description -Dlogging.level.com.alipay.lookout=? logging.level.com.alipay.lookout warn The log level of Lookout client. Debug to see the details of the report data -Dlogging.path=? logging.path Directory of the current user Modify SpringBoot V1 log directory, including \u0026amp;ldquo;lookout/\u0026amp;rdquo; log subdirectory Custom client configuration (suitable for SpringBoot technology stack mode) Use configuration custom extensions: MetricConfigCustomizerConfig\n@Configuration public class MetricConfigCustomizerConfig { @Bean public MetricConfigCustomizer metricConfigCustomizer() { return new MetricConfigCustomizer() { @Override public void customize(MetricConfig metricConfig) { metricConfig.addProperty(\u0026amp;quot;testaa\u0026amp;quot;, \u0026amp;quot;testbb\u0026amp;quot;); } }; } } ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-configuration/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5fd84950d4d565d3fb20781337792bf1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/client-configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/client-configuration/","summary":"Client configuration example lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026quot;127.0.0.1\u0026quot;); Description of server configuration item Configuration item Corresponding SpringBoot configuration item Default value Description lookout.enable com.alipay.sofa.lookout.enable true Function switch, it defaults to true. If you change it to false (empty objects and empty methods), then all metrics comsume almost no memory and computing resource lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 Maximum number limit of metrics, over which will be automatically ignored lookout.","tags":null,"title":"Client configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/client-configuration/","wordcount":192},{"author":null,"categories":null,"content":" 1. Create a Maven project After deploying the servers, we can create a new Maven project to use services provided by SOFARegistry. Create a new Maven project, and then import the following dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. Publish data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create a publisher registry. String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // Register the registry with the client and publish data. registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); Perform the following steps to publish data by using SOFARegistry:\n Create a client instance. Create a publisher registry. Register the registry with the client and publish data. 2.1 Create a client instance The key to creating a client instance is to create a RegistryClientConfig object. When creating a RegistryClientConfig object, you need to specify the RegistryEndpoint and RegistryEndpointPort.\n RegistryEndpoint: the endpoint of any session node of SOFARegistry RegistryEndpointPort: the session.server.httpServerPort port number configured for a session node 2.2 Create a publisher registry To create a publisher registry, you only need to create a PublisherRegistration object and specify the dataId, which is the unique identifier of the publisher service.\n2.3 Publish data You can call the register method of the RegistryClient to publish data. This method requires two parameters: the first is a publisher registry with the specified dataId of a service, and the second is a string type data value.\n3. Subscribe to the data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create SubscriberDataObserver. SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // Create a subscriber registry and specify the subscription level. ScopeEnum covers three subscription levels: zone, dataCenter, and global. String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setScopeEnum(ScopeEnum.global); // Register the registry with …","date":-62135596800,"description":"","dir":"projects/sofa-registry/client-quick-start/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"66e300d44b2f2a903d976bf83eb7c16e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/client-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/client-quick-start/","summary":"1. Create a Maven project After deploying the servers, we can create a new Maven project to use services provided by SOFARegistry. Create a new Maven project, and then import the following dependency:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. Publish data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create a publisher registry. String dataId = \u0026quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // Register the registry with the client and publish data.","tags":null,"title":"Client usage","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/client-quick-start/","wordcount":558},{"author":null,"categories":null,"content":" Project address\n Introduction During merged deployment, Biz packages can communicate with each other by releasing and referencing JVM services apart from using the RPC framework. This sample project is intended to demonstrate how two Biz packages communicate by JVM services.\nWithin the biz-jvm-invocation-sample project, there are three sub-projects whose functions are as follows: + facade: A common Java module that defines the SampleJvmService interface.\npackage me.qlong.tech.service; public interface SampleJvmService { String service(); } app-one: A SOFABoot Web application that defines a simple rest request and use the @SofaReference annotation to reference the SampleJvmService. When a page request is triggered, an attempt is made to call the JVM service. The key code is: package me.qlong.controller; import com.alipay.sofa.runtime.api.annotation.SofaReference; import me.qlong.tech.service.SampleJvmService; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class HelloController { @SofaReference private SampleJvmService sampleJvmService; @RequestMapping(\u0026amp;quot;/hello\u0026amp;quot;) public String hello() { return sampleJvmService.service(); } } app-two: A non-web application in SOFABoot that uses the @SofaService annotation to publish the SampleJvmService. ```java package me.qlong.tech.service.impl; import com.alipay.sofa.runtime.api.annotation.SofaService; import me.qlong.tech.service.SampleJvmService; import org.springframework.stereotype.Component;\n@SofaService @Component public class AppTwoSampleService implements SampleJvmService{ public String service() { return \u0026amp;ldquo;App Two\u0026amp;rdquo;; } }\n ## Dependency To communicate between Biz packages through JVM services, you must add dependencies on the SOFARuntime package and the corresponding Ark Plugin as follows: ```xml \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; For detailed information about publishing and referencing JVM services, see the SOFABoot Documentation. You are advised to use annotations in Jarslink2.0.\nDemo cd biz-jvm-invocation-sample/facade \u0026amp;amp;\u0026amp;amp; mvn clean install Execute the mvn clean install command in the facade root directory, and install the facade package in the local Maven repository so that you can add a facade dependency in app-one and app-two: \u0026amp;lt;!--service facade--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;me.qlong.tech\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;facade\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; cd biz-jvm-invocation-sample/app-one \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-one root directory and …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"59778c5223dc6267bd537be6c79b658a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","summary":"Project address\n Introduction During merged deployment, Biz packages can communicate with each other by releasing and referencing JVM services apart from using the RPC framework. This sample project is intended to demonstrate how two Biz packages communicate by JVM services.\nWithin the biz-jvm-invocation-sample project, there are three sub-projects whose functions are as follows: + facade: A common Java module that defines the SampleJvmService interface.\npackage me.qlong.tech.service; public interface SampleJvmService { String service(); } app-one: A SOFABoot Web application that defines a simple rest request and use the @SofaReference annotation to reference the SampleJvmService.","tags":null,"title":"Communicate across applications","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","wordcount":527},{"author":null,"categories":null,"content":"SOFARPC supports different communication protocols and currently supports Bolt, RESTful and Dubbo. For details, please refer to the corresponding document of each protocol: * Bolt Protocol * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool * RESTful * Basic usage * Custom filter * Integrate Swagger * Dubbo * Basic usage * H2C * Basic usage\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/protocol/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"18f51cb12f7a0384a71ab22349292a08","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/protocol/","summary":"SOFARPC supports different communication protocols and currently supports Bolt, RESTful and Dubbo. For details, please refer to the corresponding document of each protocol: * Bolt Protocol * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool * RESTful * Basic usage * Custom filter * Integrate Swagger * Dubbo * Basic usage * H2C * Basic usage","tags":null,"title":"Communication protocols","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/protocol/","wordcount":66},{"author":null,"categories":null,"content":" How to compile Install JDK7 and above, and Maven 3.2.5 and above.\n Directly download the code and then execute the following command:\ncd sofa-jarslink mvn clean install Note: you cannot compile the code under a sub-directory (i.e., sub-module). Since there are many modules, the configuration is restricted to the root directory only to avoid repetitive configuration of some packaging plugins such as the formatting plugin and License plugin. There will be an error message if you execute the packaging command in a sub-module.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-compile/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"23c8cae6050d7a772f45d3ff2b4ce889","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","summary":"How to compile Install JDK7 and above, and Maven 3.2.5 and above.\n Directly download the code and then execute the following command:\ncd sofa-jarslink mvn clean install Note: you cannot compile the code under a sub-directory (i.e., sub-module). Since there are many modules, the configuration is restricted to the root directory only to avoid repetitive configuration of some packaging plugins such as the formatting plugin and License plugin.","tags":null,"title":"Compile Jarslink project","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","wordcount":83},{"author":null,"categories":null,"content":" Install JDK7 or later and Maven 3.2.5 or later.\n Download the codes directly and execute the following commands:\ncd sofa-rpc mvn clean install Note: You can not build under a subdirectory (namely the submodule). Because there are too many SOFARPC modules, if every submodule needs to be installed and deployed, there will be much useless records in the repository. This issue is considered in the process of designing the SOFARPC project structure. The current structure saves you the trouble of installing and deploying all submodules, and you just have to install and deploy one module, namely the sofa-rpc-all (all) module.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/how-to-build/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"52ad3debb35be8743c97bb4b6b77f22b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/how-to-build/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/how-to-build/","summary":"Install JDK7 or later and Maven 3.2.5 or later.\n Download the codes directly and execute the following commands:\ncd sofa-rpc mvn clean install Note: You can not build under a subdirectory (namely the submodule). Because there are too many SOFARPC modules, if every submodule needs to be installed and deployed, there will be much useless records in the repository. This issue is considered in the process of designing the SOFARPC project structure.","tags":null,"title":"Compile SOFARPC project","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/how-to-build/","wordcount":100},{"author":null,"categories":null,"content":"Provide all the parameters that can be configured. * Service publishing and reference configuration * Warm-up forwarding configuration * Fault tolerance configuration\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b1a8a8c426beab292165716f1dff1ae4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration/","summary":"Provide all the parameters that can be configured. * Service publishing and reference configuration * Warm-up forwarding configuration * Fault tolerance configuration","tags":null,"title":"Configuration parameters","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration/","wordcount":22},{"author":null,"categories":null,"content":"To use Consul as service registry center, you need to add this dependency\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.ecwid.consul\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;consul-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; and need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 The value after consul: is the connection address of the consul. If you need to set some other parameters, you can also configure as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;amp;b=2 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-consul/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e6b0aa843ea0ad401c3184f6ce87649b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-consul/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-consul/","summary":"To use Consul as service registry center, you need to add this dependency\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.ecwid.consul\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;consul-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.4.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; and need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 The value after consul: is the connection address of the consul. If you need to set some other parameters, you can also configure as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;b=2 ","tags":null,"title":"Consul","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-consul/","wordcount":54},{"author":null,"categories":null,"content":" You can visit Development Route first to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n Refer to the Git official books for the Git tool usage. The first few chapters will help you get a quick start. Read Git collaboration process through GitHub Code Contribution Process Submitting an issue Whether you want to fix a bug of SOFAArk or add a new feature of SOFAArk, you have to submit an issue to describe your demand before you submit the code on GitHub address in SOFAArk. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The maintenance personnel of SOFAArk will discuss about the bug or new function you submitted, to determine if the modification is necessary, or if there is any room for improvement or any better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Getting the source code To modify or add a function, click the fork button in the upper left corner to copy a SOFAArk trunk code to your code repository, after submitting an issue.\nPulling a branch Perform all the SOFAArk modifications on the branch, and submit a pull request after the modifications, which will be merged to the trunk by the project maintenance personnel after Code Review.\nTherefore, after getting the introduction to source code steps, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/{your account}/sofa-ark.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\ngit branch -a If you want to switch back to the trunk, execute the following command:\ngit checkout -b master If you want to switch back to the branch, execute the following command:\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally. After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFAArk uses the Maven plug-in to keep the code style consistent. Before submitting the code, execute the following commands locally: mvn clean compile Supplement unit test code. New modifications should have passed existing unit tests. You should provide the new unit test to prove that the previous code has bugs and the new code has fixed such bugs. Execute the following command to run all tests:\nmvn clean test Other do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original style of the code you are editing, especially the spaces and line feeds in the code. Delete useless annotations. Annotate the places where the logic and functionality …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-contribution/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dbf77f98884a71c5c7a3fbb4dd189cfe","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","summary":"You can visit Development Route first to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n Refer to the Git official books for the Git tool usage. The first few chapters will help you get a quick start. Read Git collaboration process through GitHub Code Contribution Process Submitting an issue Whether you want to fix a bug of SOFAArk or add a new feature of SOFAArk, you have to submit an issue to describe your demand before you submit the code on GitHub address in SOFAArk.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","wordcount":795},{"author":null,"categories":null,"content":" You can go into the development route to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n For the use of git tools, refer to official books on git and get familiarized by reading the first few chapters. For the git collaboration process, refer to the article named Git Collaboration Process. GitHub Code Contribution Process Submitting an issue No Matter whether you are fixing a Jarslink bug or adding a Jarslink feature, submit an issue on the Jarslink GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The Jarslink maintenance personnel will discuss the bug or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Getting the source code To modify or add a feature, click the fork button in the upper left corner to copy Jarslink trunk code to your code repository, after submitting an issue.\nPulling a branch Perform all the Jarslink modifications on the branch, and submit a pull request after the modifications, which will be merged into the trunk by the project maintenance personnel after the code review.\nTherefore, after getting the introduction to source code steps, you need to:\n Download the code locally. You may select the git/https mode in this step.\ngit clone https://github.com/your account name/sofa-jarslink.git Pull a branch to prepare for code modification.\ngit branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\n git branch -a If you want to switch back to the trunk, execute the following command:\n git checkout -b master If you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally. After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. Jarslink uses the Maven plugin to keep the code style consistent. Before submitting the code, be sure to execute the following commands locally\nmvn clean compile Supplement unit test code. New modifications should have passed existing unit tests. You should provide the new unit test to prove that the previous code has bugs and the new code has fixed such bugs. Execute the following command to run all tests:\n mvn clean test You can also use the IDE to help execute a command.\nOther do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-contribution/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d4c1185c6a691679f6dc9dba033550ce","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","summary":"You can go into the development route to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n For the use of git tools, refer to official books on git and get familiarized by reading the first few chapters. For the git collaboration process, refer to the article named Git Collaboration Process.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","wordcount":827},{"author":null,"categories":null,"content":" Before you read this document, you are suggested to read the SOFARPC development roadmap to learn about development tasks and future plans.\n Preparations Before you contribute code, you need to learn the basic use of Git tool and GitHub website.\n For how to use the Git tool, see Git official documenation and pay attention to the first few chapters. For Git collaboration process, see Git collaboration process. GitHub code contribution process Submit an issue No matter to fix SOFARPC bugs or add SOFARPC features, before submitting the codes, you must submit an issue on SOFARPC\u0026amp;rsquo;s GitHub to describe the bugs to be fixed and the functions you want to add.\nThere are several benefits of doing this:\n Avoid the conflict with other developers or their plans for this project, thus eliminating repetitive work. SOFARPC operations staff discuss your bugs or new features to determine if the changes are necessary and whether there is space for improvement or a better approach. Reduce communication cost between you and the SOFARPC operations staff, thus reducing the cases that pull request is rejected. Get source codes To modify or add features, after you submit the issue, you can click Fork in the upper left corner to copy the SOFARPC trunk code to your code repository.\nPull branches All SOFARPC modifications are made on the branch. After modification, submit the pull request. After the code review, the project operations staff merge the branches to the trunk.\nTherefore, you must complete the following steps after getting the source codes:\n Download the codes locally through Git or HTTPs.\n git clone https://github.com/your account name/sofa-rpc.git Pull branches for code modifications.\n \t git branch add_xxx_feature \nAfter executing the above command, your code repository switches to the corresponding branch. Execute the following command to see your current branch:\n\t git branch -a \nIf you want to switch back to the trunk, execute the following command:\n git checkout -b master \nIf you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; \nModify and submit codes locally Once the branch is pulled, you can modify the code.\nAttentions for modifying codes Keep a consistent code style.\nSOFARPC keeps the code format consistent through the Maven plugin. You must execute the following command locally before committing the code: mvn clean compile Supplemental unit test code. New modifications should have passed the existing unit tests. Provide new unit tests to prove that the previous code has bugs, and the new code has fixed these bugs.\nYou can run all tests with the following command:\nmvn clean test You can also use IDE to assist the test running.\n Other attentions Keep the original code style, especially the spacing and alignment. Delete the useless comments directly. Add comments for the logics and functions that cannot be easily understood. Update documentation timely. After modification, …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/contributing/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"448a7b9a949bd2d9e2e71ac6c237f9df","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/contributing/","summary":"Before you read this document, you are suggested to read the SOFARPC development roadmap to learn about development tasks and future plans.\n Preparations Before you contribute code, you need to learn the basic use of Git tool and GitHub website.\n For how to use the Git tool, see Git official documenation and pay attention to the first few chapters. For Git collaboration process, see Git collaboration process.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/contributing/","wordcount":751},{"author":null,"categories":null,"content":"SOFARPC uses some third-party open-source components which include but not limited to:\n Major dependencies\n Netty under Apache License 2.0 SLF4j under MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 Extended dependencies\n protobuf under New BSD License Snappy under New BSD License dubbo under Apache License 2.0 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b6c87388d5c1462f13d92012639a08b2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/notice/","summary":"SOFARPC uses some third-party open-source components which include but not limited to:\n Major dependencies\n Netty under Apache License 2.0 SLF4j under MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 Extended dependencies\n protobuf under New BSD License Snappy under New BSD License dubbo under Apache License 2.0 ","tags":null,"title":"Copyright","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/notice/","wordcount":62},{"author":null,"categories":null,"content":" Copyright statement of dependent components SOFADashboard uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFABolt under Apache License 2.0 SOFABolt under Apache License 2.0 Curator under Apache License 2.0 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a9ebe38d245302f94ab7bfa793329926","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/notice/","summary":" Copyright statement of dependent components SOFADashboard uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFABolt under Apache License 2.0 SOFABolt under Apache License 2.0 Curator under Apache License 2.0 ","tags":null,"title":"Copyright statement","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/notice/","wordcount":47},{"author":null,"categories":null,"content":" Copyright statement of dependent components SOFARegistry uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1\n SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 If you find anything we have missed, please let us know.\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c40263ffd56a2f1292756c9fafea55e2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/notice/","summary":"Copyright statement of dependent components SOFARegistry uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1\n SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 If you find anything we have missed, please let us know.","tags":null,"title":"Copyright statement","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/notice/","wordcount":68},{"author":null,"categories":null,"content":" 本文档主要介绍一个基于 jraft 的分布式计数器的例子。\n场景 在多个节点（机器）组成的一个 raft group 中保存一个分布式计数器，该计数器可以递增和获取，并且在所有节点之间保持一致，任何少数节点的挂掉都不会影响对外提供的两个服务：\n incrmentAndGet(delta) 递增 delta 数值并返回递增后的值。 get() 获取最新的值 RPC 请求 jraft 底层使用 bolt 作为通讯框架，定义两个请求\n IncrementAndGetRequest，用于递增 public class IncrementAndGetRequest implements Serializable { private static final long serialVersionUID = -5623664785560971849L; private long delta; public long getDelta() { return this.delta; } public void setDelta(long delta) { this.delta = delta; } } GetValueRequest，用于获取最新值： public class GetValueRequest implements Serializable { private static final long serialVersionUID = 9218253805003988802L; public GetValueRequest() { super(); } } 应答结果 ValueResponse，包括：\n success　是否成功 value 成功情况下返回的最新值 errorMsg 失败情况下的错误信息 redirect　发生了重新选举，需要跳转的新的leader节点。 public class ValueResponse implements Serializable { private static final long serialVersionUID = -4220017686727146773L; private long value; private boolean success; /** * redirect peer id */ private String redirect; private String errorMsg; public String getErrorMsg() { return this.errorMsg; } public void setErrorMsg(String errorMsg) { this.errorMsg = errorMsg; } ...... } IncrementAndGetRequest 用于 Leader 服务端接收 IncrementAndAddClosure 请求后的回调处理： public class IncrementAndAddClosure implements Closure { private CounterServer counterServer; private IncrementAndGetRequest request; private ValueResponse response; private Closure done; // 网络应答callback public IncrementAndAddClosure(CounterServer counterServer, IncrementAndGetRequest request, ValueResponse response, Closure done) { super(); this.counterServer = counterServer; this.request = request; this.response = response; this.done = done; } @Override public void run(Status status) { // 返回应答给客户端 if (this.done != null) { done.run(status); } } public IncrementAndGetRequest getRequest() { return this.request; } public void setRequest(IncrementAndGetRequest request) { this.request = request; } public ValueResponse getResponse() { return this.response; } } 服务端 状态机 CounterStateMachine 首先持有一个初始值：\npublic class CounterStateMachine extends StateMachineAdapter { /** * counter value */ private AtomicLong value = new AtomicLong(0); 实现核心的 onApply(iterator) 方法，应用用户提交的请求到状态机：\n@Override public void onApply(Iterator iter) { // 遍历日志 while (iter.hasNext()) { long delta = 0; IncrementAndAddClosure closure = null; // done 回调不为null，必须在应用日志后调用，如果不为 null，说明当前是leader。 if (iter.done() != null) { // 当前是leader，可以直接从 IncrementAndAddClosure 中获取 delta，避免反序列化 closure = (IncrementAndAddClosure) iter.done(); delta = closure.getRequest().getDelta(); } else { // 其他节点应用此日志，需要反序列化 IncrementAndGetRequest，获取 delta ByteBuffer data = iter.getData(); try { IncrementAndGetRequest request = Codecs.getSerializer(Codecs.Hessian2).decode(data.array(), IncrementAndGetRequest.class.getName()); delta = request.getDelta(); } catch (CodecException e) { LOG.error(\u0026amp;quot;Fail to decode IncrementAndGetRequest\u0026amp;quot;, e); } } long prev = this.value.get(); // 更新状态机 long …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/counter-example/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f9c54b9f7883ccb1d7c259b7101f4674","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/counter-example/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-jraft/counter-example/","summary":"本文档主要介绍一个基于 jraft 的分布式计数器的例子。 场景 在多个节点（机器）组成的一个 raft group 中保存一个分布式计数器，该计数器可以递增和获取，并且在所有","tags":null,"title":"Counter 例子详解","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/counter-example/","wordcount":2404},{"author":null,"categories":null,"content":" Project address\n Introduction Jarslink 2.0 is available for both Spring Boot and SOFABoot; we just need to add the specified dependencies. To be convenient, it is recommended to use Jarslink 2.0 in the form of SOFABoot projects. This sample project is intended to demonstrate how to quickly reform a Spring Boot project into a SOFABoot project.\nReform After creating a Spring Boot project in the official Spring Boot website, we only need to introduce the SOFABoot dependencies. First, modify the configuration file pom.xml of the Maven project.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace as\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.5.0-SNAPSHOT\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Note: Currently Jarslink 2.0.0 is still at its snapshot version, and the SOFABoot 2.5.0 that it depends on will be released in the near future, so for the moment, the SOFABoot 2.5.0-SNAPSHOT version has to be introduced as the dependency. The pull of the SNAPSHOT package requires special configuration, for which you can refer to FAQ: How do I configure for pulling a SNAPSHOT dependency package?\nThen, add a Spring Boot or SOFABoot official Starter, such as:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;!-- Jarslink2.0 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-jarslink-ark-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0-SNAPSHOT\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- Web --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; To package the application into an Ark package or Biz package, we need to configure the sofa-Ark-maven-plugin packaging plugin in the main pom.xml file, and delete the native packaging plugin the Spring Boot configuration.\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Finally, add a parameter that SOFABoot must use under the application.properties file for the project, including spring.application.name (used to mark the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"46cb9153d039f01a375a569c2a9a5535","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","summary":"Project address\n Introduction Jarslink 2.0 is available for both Spring Boot and SOFABoot; we just need to add the specified dependencies. To be convenient, it is recommended to use Jarslink 2.0 in the form of SOFABoot projects. This sample project is intended to demonstrate how to quickly reform a Spring Boot project into a SOFABoot project.\nReform After creating a Spring Boot project in the official Spring Boot website, we only need to introduce the SOFABoot dependencies.","tags":null,"title":"Create a SOFABoot application","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","wordcount":419},{"author":null,"categories":null,"content":" SOFARPC provides a good extensibility mechanism, which provide SPI capabilities for each module. SOFARPC uses multiple filters to intercept requests and responses. These filters can be customized and extended by users. The execution order of custom filters is after the built-in filters. The procedure is as follows:\nBolt filter 1 Create a new custom filter.\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 2 The custom filter will be added into the interceptor chain. There are three specific ways to do this step.\n Method 1: In API. In this way, the custom filter can take effect in the specified provider or consumer. // Service provider providerConfig.setFilterRef(Arrays.asList(new CustomFilter())); // Service caller consumerConfig.setFilterRef(Arrays.asList(new CustomFilter())); Method 2: Add @Extension annotation + configuration extension file to the class. @Extension(\u0026amp;quot;customer\u0026amp;quot;) public class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } Create a new extension file META-INF/services/sofa-rpc/com.alipay.sofa.rpc.filter.Filter with the following content:\ncustomer=com.alipay.sofa.rpc.custom.CustomFilter Code injection.\n// Service provider providerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); // Service caller consumerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); Method 3: Add @Extension annotation + @AutoActive annotation + configuration extension file to the class. In this way, the code injection step in method 2 is replaced with the @AutoActive annotation. The custom filter can take effect in all providers or consumers. The providerSide parameter indicates whether it takes effect on the server, and the consumerSide parameter indicates whether it takes effect on the client. @Extension(\u0026amp;quot;customer\u0026amp;quot;) @AutoActive(providerSide = true, consumerSide = true) public class customerFilter extends Filter { // ... } ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-filter/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"30ff5937b52a7c2dd8028e878979a33d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-filter/","summary":"SOFARPC provides a good extensibility mechanism, which provide SPI capabilities for each module. SOFARPC uses multiple filters to intercept requests and responses. These filters can be customized and extended by users. The execution order of custom filters is after the built-in filters. The procedure is as follows:\nBolt filter 1 Create a new custom filter.\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.","tags":null,"title":"Custom filter","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-filter/","wordcount":285},{"author":null,"categories":null,"content":"The route service address in SOFARPC is abstracted into a processing chain, and is processed by each router. Like filter, SOFARPC provides the same extensibility for router.\n@Extension(value = \u0026amp;quot;customerRouter\u0026amp;quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026amp;lt;ProviderInfo\u0026amp;gt; route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) { return providerInfos; } Create a extension file META-INF/services/sofa-rpc/com.alipay.sofa.rpc.client.Router with the following content:\ncustomerRouter=com.alipay.sofa.rpc.custom.CustomRouter This file customized a CustomerRouter, which takes effect in all consumers. The parameter ConsumerBootstrap in init method is a wrapper class of the referenced service, and can get objects such as ConsumerConfig, proxy class, and service address pool. needToLoad indicates whether the Router is valid, and the route method is the method for filtering addresses.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-router/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"236e8d4bda3e856267a3575853aa900c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-router/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-router/","summary":"The route service address in SOFARPC is abstracted into a processing chain, and is processed by each router. Like filter, SOFARPC provides the same extensibility for router.\n@Extension(value = \u0026quot;customerRouter\u0026quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026lt;ProviderInfo\u0026gt; route(SofaRequest request, List\u0026lt;ProviderInfo\u0026gt; providerInfos) { return providerInfos; } Create a extension file META-INF/services/sofa-rpc/com.","tags":null,"title":"Custom router","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-router/","wordcount":131},{"author":null,"categories":null,"content":" SOFARPC supports custom business thread pools. A separate business thread pool can be set up for the specified service, isolated from SOFARPC\u0026amp;rsquo;s global business thread pool. Multiple services can share a single thread pool.\nSOFARPC requires that the type of custom thread pool must be com.alipay.sofa.rpc.server.UserThreadPool.\nUse XML If you publish the service using XML, you can first set the bean of the thread pool whose class is com.alipay.sofa.rpc.server.UserThreadPool, and then set the bean in the thread-pool-ref attribute of \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag.\n\u0026amp;lt;bean id=\u0026amp;quot;helloService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Customize a thread pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;customExecutor\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.server.UserThreadPool\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;corePoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;maximumPoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;queueSize\u0026amp;quot; value=\u0026amp;quot;0\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloService\u0026amp;quot; interface=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;!-- Set the thread pool to a Service --\u0026amp;gt; \u0026amp;lt;sofa:global-attrs thread-pool-ref=\u0026amp;quot;customExecutor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Use Annotation If you publish the service using Annotation, you can set the bean of the custom thread pool by setting the userThreadPool attribute of @SofaServiceBinding:\n@SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, userThreadPool = \u0026amp;quot;customThreadPool\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Use API in Spring environment If you publish a service using the API in Spring environment, you can configure a custom thread pool by calling the setUserThreadPool method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setUserThreadPool(new UserThreadPool()); Use API in non-Spring environment If you publish service using the API in non-Spring environment, you can set a custom thread pool as follows:\nUserThreadPool threadPool = new UserThreadPool(); threadPool.setCorePoolSize(10); threadPool.setMaximumPoolSize(100); threadPool.setKeepAliveTime(200); threadPool.setPrestartAllCoreThreads(false); threadPool.setAllowCoreThreadTimeOut(false); threadPool.setQueueSize(200); UserThreadPoolManager.registerUserThread(ConfigUniqueNameGenerator.getUniqueName(providerConfig), threadPool); As above, a custom thread pool is set up for the HelloService service.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-thread-pool/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4d582a7894b2381248522f3a1fc400c9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","summary":"SOFARPC supports custom business thread pools. A separate business thread pool can be set up for the specified service, isolated from SOFARPC\u0026rsquo;s global business thread pool. Multiple services can share a single thread pool.\nSOFARPC requires that the type of custom thread pool must be com.alipay.sofa.rpc.server.UserThreadPool.\nUse XML If you publish the service using XML, you can first set the bean of the thread pool whose class is com.alipay.sofa.rpc.server.UserThreadPool, and then set the bean in the thread-pool-ref attribute of \u0026lt;sofa:global-attrs\u0026gt; tag.","tags":null,"title":"Custom thread pool","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","wordcount":252},{"author":null,"categories":null,"content":" You can view basic information of your application on SOFADashboard, including the IP address, ports, and health check status. This feature is dependent on the SOFADashboard client. If you want to display the information about an application on the SOFADashboard control page, import the sofa-dashboard-client dependency.\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-dashboard-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; Function display ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/dashboard-client/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"60586c6dfee1f2afcdac88cbe7a36b83","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","summary":" You can view basic information of your application on SOFADashboard, including the IP address, ports, and health check status. This feature is dependent on the SOFADashboard client. If you want to display the information about an application on the SOFADashboard control page, import the sofa-dashboard-client dependency.\n\u0026lt;denpendency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofa-dashboard-client\u0026lt;/artifactId\u0026gt; \u0026lt;/denpendency\u0026gt; Function display ","tags":null,"title":"Dashboard client","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","wordcount":52},{"author":null,"categories":null,"content":" In this document will demonstrate how to use SOFATracer to track of Datasource.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce SOFATracer Introduce SOFATracer dependency in the new Spring Boot project:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.2.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce h2database dependencies For convenience, we use the h2database memory database for test. So, we need to introduce the following dependencies:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.h2database\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;h2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;runtime\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;mysql\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mysql-connector-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce the required connection pool dependencies Introduce the required connection pool dependency packages, such as druid, c3p0, tomcat, dbcp, Hikari, and so on.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;druid\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;c3p0\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;c3p0\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.9.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.tomcat\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tomcat-jdbc\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;8.5.31\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-dbcp\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-dbcp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.zaxxer\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;HikariCP-java6\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.8\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configure data source Taking HikariCP as the example, we create a new Spring configuration file named datasource.xml, which defines the followings:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- dataSource pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;simpleDataSource\u0026amp;quot; class=\u0026amp;quot;com.zaxxer.hikari.HikariDataSource\u0026amp;quot; destroy-method=\u0026amp;quot;close\u0026amp;quot; primary=\u0026amp;quot;true\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;driverClassName\u0026amp;quot; value=\u0026amp;quot;org.h2.Driver\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;jdbcUrl\u0026amp;quot; value=\u0026amp;quot;jdbc:h2:~/test\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;username\u0026amp;quot; value=\u0026amp;quot;sofa\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;password\u0026amp;quot; value=\u0026amp;quot;123456\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; Application configuration Required configuration It should be noted that it is …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-datasource/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d9d8f6756a294104647067eaa7827f61","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","summary":"In this document will demonstrate how to use SOFATracer to track of Datasource.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce SOFATracer Introduce SOFATracer dependency in the new Spring Boot project:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.2.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Introduce h2database dependencies For convenience, we use the h2database memory database for test. So, we need to introduce the following dependencies:","tags":null,"title":"DataSource Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","wordcount":642},{"author":null,"categories":null,"content":" Datasource Log Format SOFATracer tracks the standard JDBC data source and outputs the chain data of SQL statement execution, in the default JSON format.\nDataSource digest log (datasource-client-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Database.name Database name Sql SQL execution statement Result.code SQL execution status code Total.time SQL statement execution total time Connection.establish.span SQL execution connection establishment time Db.execute.cost SQL execution time Database.type Database type Database.endpoint Database url Current.thread.name Current thread name Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-28 01:11:56.715\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e1bcab91538068316462100111113\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1.2\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;success\u0026amp;quot;,\u0026amp;quot;total.time\u0026amp;quot;:\u0026amp;quot;228ms\u0026amp;quot;,\u0026amp;quot;connection.establish.span\u0026amp;quot;:\u0026amp;quot;220ms\u0026amp;quot;,\u0026amp;quot;db.execute.cost\u0026amp;quot;:\u0026amp;quot;3ms\u0026amp;quot;,\u0026amp;quot;database.type\u0026amp;quot;:\u0026amp;quot;h2\u0026amp;quot;,\u0026amp;quot;database.endpoint\u0026amp;quot;:\u0026amp;quot;jdbc:h2:~/test:-1\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} DataSource statistical Log (datasource-client-stat.log) stat.key is the set of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, database.name, and SQL field.\n Key Meaning time Log printing time stat.key local.app Current application name database.name Database name sql SQL execution statement count SQL execution count in this period total.cost.milliseconds Total duration (ms) for SQL execution in this period success Request result: Y for success; N for failure load.test Pressure mark: T for pressure test; F for non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-28 01:12:43.647\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;, \u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:228,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-datasource/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"647de768aff8ececc8276d247c5afee1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","summary":"Datasource Log Format SOFATracer tracks the standard JDBC data source and outputs the chain data of SQL statement execution, in the default JSON format.\nDataSource digest log (datasource-client-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Database.","tags":null,"title":"DataSource log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","wordcount":202},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 DataSource 进行埋点。\n SOFATracer 2.2.0 基于标准的 JDBC 接口实现，支持对标准的数据库连接池（如 DBCP、Druid、c3p0、tomcat、HikariCP、BoneCP）埋点。下面演示如何接入 SOFATracer 埋点能力。\n 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 引入 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入 h2database 依赖 为了方便，我们使用 h2database 内存数据库测试，引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.h2database\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;h2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;runtime\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;mysql\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mysql-connector-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入所需的连接池依赖 用户引入所需的连接池依赖包，如 druid, c3p0, tomcat, dbcp, Hikari 等。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;druid\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;c3p0\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;c3p0\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.9.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.tomcat\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tomcat-jdbc\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;8.5.31\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-dbcp\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-dbcp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.zaxxer\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;HikariCP-java6\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.8\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置数据源 我们以 HikariCP 为例，新建一个名为datasource.xml Spring 配置文件，定义如下内容:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- dataSource pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;simpleDataSource\u0026amp;quot; class=\u0026amp;quot;com.zaxxer.hikari.HikariDataSource\u0026amp;quot; destroy-method=\u0026amp;quot;close\u0026amp;quot; primary=\u0026amp;quot;true\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;driverClassName\u0026amp;quot; value=\u0026amp;quot;org.h2.Driver\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;jdbcUrl\u0026amp;quot; value=\u0026amp;quot;jdbc:h2:~/test\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;username\u0026amp;quot; value=\u0026amp;quot;sofa\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;password\u0026amp;quot; value=\u0026amp;quot;123456\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 应用配置 必要配置 需要注意一点，引入 SOFATracer 需要强制配置应用名，否则应用启动失败。这一属性和 SOFABoot 框架要求一致，配置如下：\nspring.application.name=SOFATracerDataSource 非必要配置 为了该演示工程正常运行，需要配置 h2database 属性；另为了方便查看日志，配置日志路径。如下：\n# logging path logging.path=./logs # h2 web consloe 路径 spring.h2.console.path=/h2-console # 开启 h2 web consloe，默认为 false spring.h2.console.enabled=true #允许远程访问 h2 web consloe spring.h2.console.settings.web-allow-others=true spring.datasource.username=sofa …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-datasource/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d9d8f6756a294104647067eaa7827f61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","summary":"在本文档将演示如何使用 SOFATracer 对 DataSource 进行埋点。 SOFATracer 2.2.0 基于标准的 JDBC 接口实现，支持对标准的数据库连接池（如 DBCP、Druid、c3p0、tomcat、H","tags":null,"title":"DataSource 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","wordcount":1014},{"author":null,"categories":null,"content":" SOFATracer 对标准的 JDBC 数据源进行埋点，输出 SQL 语句执行链路数据，默认日志输出为 JSON 数据格式。\nDataSource 摘要日志（datasource-client-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 database.name 数据库名称 sql sql执行语句 connection.establish.span sql执行建连时间 db.execute.cost sql执行时间 database.type 数据库类型 database.endpoint 数据库url sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 21:31:31.566\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe91d156743109138810017302\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;15ms\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;DROP TABLE IF EXISTS TEST; CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;,\u0026amp;quot;connection.establish.span\u0026amp;quot;:\u0026amp;quot;128ms\u0026amp;quot;,\u0026amp;quot;db.execute.cost\u0026amp;quot;:\u0026amp;quot;15ms\u0026amp;quot;,\u0026amp;quot;database.type\u0026amp;quot;:\u0026amp;quot;h2\u0026amp;quot;,\u0026amp;quot;database.endpoint\u0026amp;quot;:\u0026amp;quot;jdbc:h2:~/test:-1\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} DataSource 统计日志（datasource-client-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、database.name、和 sql 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 database.name 数据库名称 sql sql执行语句 count 本段时间内sql执行次数 total.cost.milliseconds 本段时间内sql执行总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 21:31:50.435\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;DROP TABLE IF EXISTS TEST; CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:15,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-datasource/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"647de768aff8ececc8276d247c5afee1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-datasource/","summary":"SOFATracer 对标准的 JDBC 数据源进行埋点，输出 SQL 语句执行链路数据，默认日志输出为 JSON 数据格式。 DataSource 摘要日志（datasource-client-digest.","tags":null,"title":"DataSource 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-datasource/","wordcount":427},{"author":null,"categories":null,"content":" SOFABoot is based on Spring Boot. It means SOFABoot manages SOFA middleware dependencies and provides the Starter for Spring Boot, facilitating the use of SOFA middleware in Spring Boot.\nSOFABoot dependency management You must load SOFABoot\u0026amp;rsquo;s management dependencies before using SOFA middleware. In a way similar to use Spring Boot, add the configuration tag \u0026amp;lt;parent/\u0026amp;gt; in the project settings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Where ${sofa.boot.version} represents the SOFABoot version (refer to release history).\nUse Middleware of SOFAStack For SOFABoot, use -sofa-boot-starter suffixes to name middleware components. If you want to use middleware, simply add its dependencies; To use SOFARPC, for example, simply add the following Maven dependencies:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note that there is no version declaration in the above Maven dependencies as the version has already been declared in sofabook-dependencies. This allows for unified upgrade of all SOFA middleware versions, allaying concerns over dependency conflicts or incompatibility brought by upgrade of a single middleware version. The SOFABoot middleware under control is listed as follows:\n Middleware starter SOFARPC rpc-sofa-boot-starter SOFATracer tracer-sofa-boot-starter SOFALookout lookout-sofa-boot-starter Introducing SOFABoot Extension Based on Spring Boot, SOFABoot provides extended capabilities such as health check, module isolation, and class isolation. In accordance with Spring Boot\u0026amp;rsquo;s the dependency-as-a-service principle, the extension capability will be ready immediately after relevant dependencies are added. Currently, there are several extension modules available:\n Extension components starter Health check healthcheck-sofa-boot-starter Module isolation Isle-Sofa-boot-starter Class isolation sofa-Ark-springboot-starter Test extension test-Sofa-boot-starter Introducing the SOFA middleware: the Ark plug-in SOFABoot provides a class isolation component—SOFAArk, which enables users to package third-party packages with dependency conflicts into an Ark plug-in. At run time, the Ark plug-in is loaded with a separate classloader; it is isolated from other Ark plug-ins and business dependencies to address class conflicts. SOFABoot provides SOFARPC and SOFATracer\u0026amp;rsquo;s Ark plug-ins; the Ark plug-in SOFARPC, for example, is loaded into the application to replace SOFARPC starter, to isolate the application from SOFARPC and its indirect dependencies. The controlled Ark plug-ins are listed as follows:\n Ark plug-in plugin SOFARPC rpc-sofa-boot-plugin SOFATracer tracer-sofa-boot-plugin Introducing SOFABoot namespace Before using SOFA middleware, we need to add …","date":-62135596800,"description":"","dir":"projects/sofa-boot/dependency-management/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dabdbd425f20dee4d7ab580d43574456","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/dependency-management/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/dependency-management/","summary":"SOFABoot is based on Spring Boot. It means SOFABoot manages SOFA middleware dependencies and provides the Starter for Spring Boot, facilitating the use of SOFA middleware in Spring Boot.\nSOFABoot dependency management You must load SOFABoot\u0026rsquo;s management dependencies before using SOFA middleware. In a way similar to use Spring Boot, add the configuration tag \u0026lt;parent/\u0026gt; in the project settings:\n\u0026lt;parent\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofaboot-dependencies\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${sofa.boot.version}\u0026lt;/version\u0026gt; \u0026lt;/parent\u0026gt; Where ${sofa.boot.version} represents the SOFABoot version (refer to release history).","tags":null,"title":"Dependency management","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/dependency-management/","wordcount":391},{"author":null,"categories":null,"content":" 1. Environment preparation To use SOFARegistry, you need to prepare the basic environment first. SOFARegistry depends on the following environment:\n Linux, UNIX, Mac are supported. JDK8 Compile it with Apache Maven 3.2.5 or later versions. 2. Resource Quota -cpu: 4c -memory: 8G -disk: 50G\n3. Two deployment modes Integrated deployment Package and integrate the three roles of meta, data, and session into one jvm, which can be deployed on a standalone machine or a cluster. The deployment is simple. Independent deployment Deploy the meta, data, and session roles separately. You can deploy each of them on a standalone machine or a cluster. You can deploy different numbers of servers for each role as needed. We recommend that you use this deployment mode in the production environment. 4. Configuration parameters The deployment of SOFARegistry depends on some public parameters\n properties environment Default value Function nodes.localDataCenter x DefaultDataCenter Cluster name, multiple registry centers use the same database nodes.localRegion x DEFAULT_ZONE Logical region, create multiple groups of sessions jdbc.url JDBC_URL Required Database address jdbc.username JDBC_USERNAME required database user name jdbc.password JDBC_PASSWORD Required Database password Properties can be written in registry-all/conf/application.properties, deployment under kubernetes can also use configmap for file mounting\n5. Packaging jar release page Download the latest registry-all.tgz package\ntar -zxvf registry-all.tgz cd registry-all Or package from source\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all image image hosted at https://hub.docker.com/r/sofaregistry/sofaregistry\nOr build from source code: Modify the image repository in Makefile\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true make image_build make image_push 6. Integrated deployment mode The integrated deployment mode is to package and integrate the three roles of meta/data/session into a JVM to run. It can be deployed on a single machine or in a cluster. It is not recommended for large-scale use\n6.1 jar stand-alone deployment For the stand-alone deployment mode of integrated deployment, you can directly refer to the Quick Start-Server Deployment section.\n6.2 jar cluster deployment Unzip registry-all.tgz and modify the configuration file Cluster deployment, that is, to build a cluster of 2 or more, it is recommended to use at least 3 (note: currently does not support the deployment of multiple SOFARegistry on the same machine, so you must have 3 different machines). The deployment method on each machine is the same as above:\ncp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar …","date":-62135596800,"description":"","dir":"projects/sofa-registry/deployment/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7e28583bc38be66af8d704d7fbcd9dd4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/deployment/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/deployment/","summary":"1. Environment preparation To use SOFARegistry, you need to prepare the basic environment first. SOFARegistry depends on the following environment:\n Linux, UNIX, Mac are supported. JDK8 Compile it with Apache Maven 3.2.5 or later versions. 2. Resource Quota -cpu: 4c -memory: 8G -disk: 50G\n3. Two deployment modes Integrated deployment Package and integrate the three roles of meta, data, and session into one jvm, which can be deployed on a standalone machine or a cluster.","tags":null,"title":"Deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/deployment/","wordcount":1040},{"author":null,"categories":null,"content":" 1. How to compile Install JDK7 or later versions, and Maven 3.2.5 or later versions. Directly download the code, and execute the following command in the code directory:\n mvn clean install 2. Version release Version number ACTS uses a three-digit version number in the form of major, minor, and patch, for example, 1.0.1.\nFor more information, see https://semver.org/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Patch number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application is. Version maintenance At most two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 1.3.0, the BugFix branch of version 1.2.x will be maintained, but bugs in branch 1.1.x will no longer be fixed. Therefore, a version upgrade for 1.1.x is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 1.3.0-SNAPSHOT. Upon formal release, SNAPSHOT is replaced with a formal version number, for example 1.3.0. After the formal release, the next version is pulled, for example, 1.3.1-SNAPSHOT. 3. Testing Unit test Add the unit test case to the model that you have developed. The package name of the test class is identical to that of the tested class.\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/developer-guide/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fcacc7e89b979f3aec8dc3333a7a3c37","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/developer-guide/","summary":"1. How to compile Install JDK7 or later versions, and Maven 3.2.5 or later versions. Directly download the code, and execute the following command in the code directory:\n mvn clean install 2. Version release Version number ACTS uses a three-digit version number in the form of major, minor, and patch, for example, 1.0.1.\nFor more information, see https://semver.org/.\n Major version number: All versions within a major version number must be compatible with each other.","tags":null,"title":"Developer guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/developer-guide/","wordcount":249},{"author":null,"categories":null,"content":" Develope guide of code contribution First refer to the basic Notes for code contribution Note the test case coverage; Note the code format; Verify samples Import the sample Maven project separately; Modify the dependency version in the corresponding Pom file; Verify that samples can work correctly as well. ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/development-use-guide/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"423a54ec3f5fbfc9c0e150eb853738ae","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","summary":" Develope guide of code contribution First refer to the basic Notes for code contribution Note the test case coverage; Note the code format; Verify samples Import the sample Maven project separately; Modify the dependency version in the corresponding Pom file; Verify that samples can work correctly as well. ","tags":null,"title":"Development guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","wordcount":48},{"author":null,"categories":null,"content":"SOFARPC supports scenarios where a specified address is called.\nThe use of direct call in Java API is as follows, only set the direct connection address:\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); The use of direct call in XML is as follows:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sample.HelloService\u0026amp;quot; id=\u0026amp;quot;helloService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; The use of direct call in Annotation is as follows:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, directUrl = \u0026amp;quot;127.0.0.1:12220\u0026amp;quot;)) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/peer-to-peer/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b1815c322f5dc9528f6429d1d5e38369","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","summary":"SOFARPC supports scenarios where a specified address is called.\nThe use of direct call in Java API is as follows, only set the direct connection address:\nConsumerConfig\u0026lt;HelloService\u0026gt; consumer = new ConsumerConfig\u0026lt;HelloService\u0026gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026quot;bolt://127.0.0.1:12201\u0026quot;); The use of direct call in XML is as follows:\n\u0026lt;sofa:reference interface=\u0026quot;com.alipay.sample.HelloService\u0026quot; id=\u0026quot;helloService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:route target-url=\u0026quot;127.0.0.1:12200\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:reference\u0026gt; The use of direct call in Annotation is as follows:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026quot;bolt\u0026quot;, directUrl = \u0026quot;127.","tags":null,"title":"Direct call","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","wordcount":73},{"author":null,"categories":null,"content":" Fault Recover Including Fault-Hystrix and Fault-Tolerance features.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e567dc5e291867e92c8dd1c4f953b768","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault/","summary":"Fault Recover Including Fault-Hystrix and Fault-Tolerance features.","tags":null,"title":"Disaster recovery","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault/","wordcount":7},{"author":null,"categories":null,"content":" Distributed consensus algorithm Understand distributed consensus Multiple participants reach a complete consensus on one thing: one conclusion for one thing. The conclusion cannot be overthrown. Typical distributed consensus algorithms Paxos: It is considered as the foundation of distributed consensus algorithms. Other algorithms are its variants. However, the Paxos paper only provides the process of a single proposal, without describing the details of multi-paxos that is required for state machine replication. Paxos implementation involves high engineering complexity, for example, multiple-point writes and log hole tolerance. Zab: It is applied in ZooKeeper and widely used in the industry. However, it is not available as a universal library. Raft: It is known for being easy to understand. There are many renowned Raft implementations in the industry, such as etcd, Braft, and TiKV. Introduction to Raft Raft is in nature a Paxos-based distributed consensus algorithm that is much easier to understand than Paxos. Unlike Paxos, Raft divides the protocols into independent modules, and uses a streamlined design, making the Raft protocol easier to implement.\nSpecifically, Raft divides consensus protocols into almost completely decoupled modules, such as leader election, membership change, log replication, and snapshot.\nRaft adopts a more streamlined design by preventing reordering commits, simplifying roles (it has only three roles: leader, follower, and candidate), allowing only the leader to write, and using randomized timeout values to design leader election.\nFeature: strong leader The system can have only one leader at the same time, and only the leader can accept requests sent by clients. The leader is responsible for communication with all followers, sending proposals to all followers, and receiving responses from the majority of followers. The leader also needs to send heartbeats to all followers to maintain its leadership. To summarize, a strong leader tells its followers: \u0026amp;ldquo;Do not say anything. Do what I said and let me know when you finish!\u0026amp;rdquo; In addition, a leader must always remain active by sending heartbeats to followers. Otherwise, a follower will take its place.\nReplicated state machine Assume we have an infinitely incrementing sequence (system) a[1, 2, 3…]. If for any integer i, the value of a[i] meets the distributed consensus requirement, the system meets the requirement of a consensus state machine. Basically, all real life systems are subject to continuous operations, and reaching consensus on a single value is definitely not enough. To make sure all replicas of a real life system are consistent, we usually convert the operations into entries of a write-ahead-log(WAL). Then, we make sure all replicas of the system reach a consensus on the WAL entries, so that each replica performs operations of the WAL entries in order. As a result, the replicas are in consistent states.\n A client sent a write (operation) request to …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/consistency-raft-jraft/","fuzzywordcount":4900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a0e98df1bec305cca7db6fc34fc97771","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":23,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","summary":"Distributed consensus algorithm Understand distributed consensus Multiple participants reach a complete consensus on one thing: one conclusion for one thing. The conclusion cannot be overthrown. Typical distributed consensus algorithms Paxos: It is considered as the foundation of distributed consensus algorithms. Other algorithms are its variants. However, the Paxos paper only provides the process of a single proposal, without describing the details of multi-paxos that is required for state machine replication.","tags":null,"title":"Distributed consensus - Raft and JRaft","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","wordcount":4871},{"author":null,"categories":null,"content":"SOFARPC provides support for the Dubbo protocol, making it convenient for you to interface with existing Dubbo service. * Basic usage\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"87d78ed0c2d06fe7e1dbf9cb9d6c1c9d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/dubbo/","summary":"SOFARPC provides support for the Dubbo protocol, making it convenient for you to interface with existing Dubbo service. * Basic usage","tags":null,"title":"Dubbo","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/dubbo/","wordcount":21},{"author":null,"categories":null,"content":" Dubbo Integration In this document will demonstrate how to use SOFATracer to track of Dubbo, this example address.\nPrepare Environment The versions of the framework components used in this case are as follows:\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 This case includes three submodules:\n tracer-sample-with-dubbo-consumer service provider tracer-sample-with-dubbo-provider service consumer tracer-sample-with-dubbo-facade service interface define New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026amp;rsquo;s dependency. First, you need to unzip the generated zip package of Spring Boot project and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more information about SOFABoot versions, refer to Release notes.\nNew tracer-sample-with-dubbo-facade Module provider a service interface\npublic interface HelloService { String SayHello(String name); } New tracer-sample-with-dubbo-provider Module provider SOFATracer dependency\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer versions are controlled by SOFABoot versions. If the SOFABoot versions used do not match, you need to manually specify a tracer version that is higher than 2.4.0.\n application.properties Configuration # Spring boot application spring.application.name=dubbo-provider # Base packages to scan Dubbo Component: @org.apache.dubbo.config.annotation.Service dubbo.scan.base-packages=com.alipay.sofa.tracer.examples.dubbo.impl ## Filter dubbo.provider.filter=dubboSofaTracerFilter # Dubbo Protocol dubbo.protocol.name=dubbo ## Dubbo Registry dubbo.registry.address=zookeeper://localhost:2181 logging.path=./logs Publish the Dubbo service using annotations\n@Service public class HelloServiceImpl implements HelloService { @Override public String SayHello(String name) { return \u0026amp;quot;Hello , \u0026amp;quot;+name; } } New tracer-sample-with-dubbo-consumer Module provider SOFATracer dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; application.properties Configuration\nspring.application.name=dubbo-consumer dubbo.registry.address=zookeeper://localhost:2181 dubbo.consumer.filter=dubboSofaTracerFilter logging.path=./logs Service reference @Reference(async = false) public HelloService …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-dubbo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"03f845606b454a7224333238aeecd9ab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","summary":"Dubbo Integration In this document will demonstrate how to use SOFATracer to track of Dubbo, this example address.\nPrepare Environment The versions of the framework components used in this case are as follows:\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 This case includes three submodules:\n tracer-sample-with-dubbo-consumer service provider tracer-sample-with-dubbo-provider service consumer tracer-sample-with-dubbo-facade service interface define New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026rsquo;s dependency.","tags":null,"title":"Dubbo Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","wordcount":297},{"author":null,"categories":null,"content":" Dubbo Log Format SOFATracer integrates Dubbo and outputs the requested link log data format. The default is JSON data format.\nDubbo service consumer digest log（dubbo-client-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app Current application name protocol protocol service service interface method service method invoke.type invoke type remote.host remote host remote.port remote port local.host local host client.serialize.time request serialize time client.deserialize.time response deserialize time req.size.bytes Request Body Size resp.size.bytes Response Body Size result.code result code current.thread.name Current thread name time.cost.milliseconds Request time (ms) baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-03 11:36:01.909\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8451554262561656100126684\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;dubbo-consumer\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;dubbo\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.dubbo.facade.HelloService\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;SayHello\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.232.69\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;20880\u0026amp;quot;,\u0026amp;quot;local.host\u0026amp;quot;:\u0026amp;quot;10.15.232.69\u0026amp;quot;,\u0026amp;quot;client.serialize.time\u0026amp;quot;:35,\u0026amp;quot;client.deserialize.time\u0026amp;quot;:0,\u0026amp;quot;req.size.bytes\u0026amp;quot;:323,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:323,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:252,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Dubbo service provider digest log（dubbo-server-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app current application name service service inteface method service method local.host local host local.host local port protocol protocol server.serialize.time response serialize time server.deserialize.time request deserialize time result.code result code current.thread.name current thread name time.cost.milliseconds Request time (ms) baggage Transparently transmitted baggage data Example\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-03 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-dubbo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"9bac8256ee1a74546b74799f9f1c0de9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","summary":"Dubbo Log Format SOFATracer integrates Dubbo and outputs the requested link log data format. The default is JSON data format.\nDubbo service consumer digest log（dubbo-client-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app Current application name protocol protocol service service interface method service method invoke.","tags":null,"title":"Dubbo log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","wordcount":275},{"author":null,"categories":null,"content":"SOFARPC 提供了 Dubbo 协议的支持，可以让用户非常方便地和现有的 Dubbo 的系统做对接。 * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"87d78ed0c2d06fe7e1dbf9cb9d6c1c9d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/dubbo/","summary":"SOFARPC 提供了 Dubbo 协议的支持，可以让用户非常方便地和现有的 Dubbo 的系统做对接。 * 基本使用","tags":null,"title":"Dubbo 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/dubbo/","wordcount":38},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 Dubbo 协议，只要将 Binding 设置为 Dubbo 即可。下面使用以注解的方式来例举，其他的使用方式可以参考 Bolt 协议基本使用，这里不再重复说明。：\n发布服务 发布一个 Dubbo 的服务，只需要将 @SofaServiceBinding 的 bindingType 设置为 dubbo 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 引用服务 引用一个 Dubbo 的服务，只需要将 @SofaReferenceBinding 的 bindingType 设置为 dubbo 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; 设置 Dubbo 服务的 Group 在 SOFARPC 的模型中，没有直接的一个字段叫做 Group，但是 SOFARPC 有一个 uniqueId 的模型，可以直接映射到 Dubbo 的模型中的 Group，比如下面的代码，就是发布了一个 Group 为 groupDemo 的服务：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}, uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;) public class SampleServiceImpl implements SampleService { } 如下的代码，就是引用了一个 Group 为 groupDemo 的服务：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;, jvmFirst = false) private SampleService sampleService; 注意，目前 Dubbo 协议只支持 Zookeeper 作为服务注册中心。\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo-usage/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1bf72c194a20a5dccea70423690191f4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/dubbo-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/dubbo-usage/","summary":"在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 Dubbo 协议，只要将 Binding 设置为 Dubbo 即可。下面使用以注解的方式来例举，其他的使用方式可以","tags":null,"title":"Dubbo 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/dubbo-usage/","wordcount":322},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 Dubbo 进行埋点，本示例工程地址。\n基础环境 本案例使用的各框架组件的版本如下：\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 本案例包括三个子模块：\n tracer-sample-with-dubbo-consumer 服务调用方 tracer-sample-with-dubbo-provider 服务提供方 tracer-sample-with-dubbo-facade 接口 原理 SOFATracer 对象 Dubbo 的埋点实现依赖于 Dubbo 的 SPI 机制来实现，Tracer 中基于 调用拦截扩展 自定义了 DubboSofaTracerFilter 用于实现对 Dubbo 的调用埋点。由于 DubboSofaTracerFilter 并没有成为 Dubbo 的官方扩展，因此在使用 SOFATracer 时需要安装 调用拦截扩展 中 所提供的方式进行引用，即：\n\u0026amp;lt;!-- 消费方调用过程拦截 --\u0026amp;gt; \u0026amp;lt;dubbo:reference filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;!-- 消费方调用过程缺省拦截器，将拦截所有reference --\u0026amp;gt; \u0026amp;lt;dubbo:consumer filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- 提供方调用过程拦截 --\u0026amp;gt; \u0026amp;lt;dubbo:service filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;!-- 提供方调用过程缺省拦截器，将拦截所有service --\u0026amp;gt; \u0026amp;lt;dubbo:provider filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;/\u0026amp;gt; 新建 SOFABoot 工程作为父工程 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 Maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n新建 tracer-sample-with-dubbo-facade 提供一个接口\npublic interface HelloService { String SayHello(String name); } 新建 tracer-sample-with-dubbo-provider 在工程模块的 pom 文件中添加 SOFATracer 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer 版本受 SOFABoot 版本管控，如果使用的 SOFABoot 版本不匹配，则需要手动指定 tracer 版本，且版本需高于 2.4.0.\n 在工程的 application.properties 文件下添加相关参数， # Spring boot application spring.application.name=dubbo-provider # Base packages to scan Dubbo Component: @org.apache.dubbo.config.annotation.Service dubbo.scan.base-packages=com.alipay.sofa.tracer.examples.dubbo.impl ## Filter 必须配置 dubbo.provider.filter=dubboSofaTracerFilter # Dubbo Protocol dubbo.protocol.name=dubbo ## Dubbo Registry dubbo.registry.address=zookeeper://localhost:2181 logging.path=./logs 使用注解方式发布 Dubbo 服务\n@Service public class HelloServiceImpl implements HelloService { @Override public String SayHello(String name) { return \u0026amp;quot;Hello , \u0026amp;quot;+name; } } 新建 tracer-sample-with-dubbo-consumer 在工程模块的 pom 文件中添加 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 在工程的 application.properties 文件下添加相关参数\nspring.application.name=dubbo-consumer dubbo.registry.address=zookeeper://localhost:2181 # Filter 必须配置 dubbo.consumer.filter=dubboSofaTracerFilter logging.path=./logs 服务引用 @Reference(async = false) public HelloService helloService; @Bean …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-dubbo/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"03f845606b454a7224333238aeecd9ab","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","summary":"在本文档将演示如何使用 SOFATracer 对 Dubbo 进行埋点，本示例工程地址。 基础环境 本案例使用的各框架组件的版本如下： SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 本案例包括三个子模块： tracer-sample-with-dubbo-consumer 服务调","tags":null,"title":"Dubbo 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","wordcount":760},{"author":null,"categories":null,"content":" SOFATracer 集成 Dubbo 后输出请求的链路数据格式，默认为 JSON 数据格式。\nDubbo 服务消费方摘要日志（dubbo-client-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 protocol 协议 service 服务接口 method 调用方法 invoke.type 调用类型 remote.host 目标主机 remote.port 目标端口 local.host 本地主机 client.serialize.time 请求序列化时间 client.deserialize.time 响应反序列化时间 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 error 错误信息 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:36:08.250\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;dubbo-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e27a79c156743856804410019644\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;205ms\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;dubbo\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.glmapper.bridge.boot.service.HelloService\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;SayHello\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;192.168.2.103\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;20880\u0026amp;quot;,\u0026amp;quot;local.host\u0026amp;quot;:\u0026amp;quot;192.168.2.103\u0026amp;quot;,\u0026amp;quot;client.serialize.time\u0026amp;quot;:35,\u0026amp;quot;client.deserialize.time\u0026amp;quot;:5,\u0026amp;quot;req.size.bytes\u0026amp;quot;:336,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:48,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Dubbo 服务提供方摘要日志（dubbo-server-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 protocol 协议 service 服务接口 method 调用方法 invoke.type 调用类型 local.host 本地主机 local.port 本地端口 server.serialize.time 响应序列化时间 server.deserialize.time 请求反序列化时间 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 error 错误信息 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-dubbo/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9bac8256ee1a74546b74799f9f1c0de9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","summary":"SOFATracer 集成 Dubbo 后输出请求的链路数据格式，默认为 JSON 数据格式。 Dubbo 服务消费方摘要日志（dubbo-client-digest.log） 以 JSON 格式输出的数据","tags":null,"title":"Dubbo 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","wordcount":550},{"author":null,"categories":null,"content":" The engine architecture is shown in the following diagram. Node A node in a Raft cluster connects and encapsulates all underlayer service modules, and main service interfaces that are visible to users. Specifically, the leader node of a raft group calls apply(task) to commit new tasks to the state machine replication cluster made up by the Raft group, which will then apply the task to the business state machine.\nStorage It stores Raft configuration changes and log entries converted from requests submitted by users, and replicates log entries from the leader\u0026amp;rsquo;s log to followers\u0026amp;rsquo; logs. LogStorage stores logs, while LogManager is responsible for calling the underlayer storage, caching and batch submitting storage calls, and conducting necessary checks and optimization. MetaStorage stores the metadata and records the internal states of the Raft implementation, for example, the current term of the node and the node to vote for. Optional. Snapshot storage is used to store users\u0026amp;rsquo; state-machine snapshots and meta information. SnapshotStorage stores snapshots, while SnapshotExecutor manages the actual storage, remote installation, and replication of snapshots. State machine StateMachine is an implementation of users\u0026amp;rsquo; core logic. It calls the onApply(Iterator) method to apply log entries that are submitted with Node#apply(task) to the business state machine. FSMCaller encapsulates state transition calls that are sent to the User StateMachine, writes log entries, implements a finite-state machine (FSM), conducts necessary checks, and merges requests for batch submission and concurrent processing. Replication Replicator is used by the leader to replicate log entries to followers. It does the same thing as an AppendEntries RPC of Raft. Without log entries, it is sent by the leader as heartbeats. ReplicatorGroup is used by a Raft group to manage all replicators, and to perform necessary permission checks and dispatches. RPC The RPC module is used for network communication between nodes.\n The RPC server is built in a node to receive requests from other nodes or clients, and to redirect such requests to the corresponding service modules. The RPC client is used to issue requests to other nodes, such as requests for votes, log replication requests, and heartbeats. ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/engine-architecture/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d2cc9de133aed20695229d0cde5b6ff9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","summary":"The engine architecture is shown in the following diagram. Node A node in a Raft cluster connects and encapsulates all underlayer service modules, and main service interfaces that are visible to users. Specifically, the leader node of a raft group calls apply(task) to commit new tasks to the state machine replication cluster made up by the Raft group, which will then apply the task to the business state machine.","tags":null,"title":"Engine architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","wordcount":347},{"author":null,"categories":null,"content":" ExtensionLoader To ensure that all steps of SOFARPC have sufficient scalability, SOFARPC defines a very flexible extension mechanism in which all extension implementations are equal.\nThis mechanism is very useful for both SOFARPC developers and users. SOFARPC abstracts itself into multiple modules which have no explicit dependencies on each other and interact via SPI.\nThis extension mechanism abstracts the interaction method of SPI. If you have read the documents about Filter and Router, you may have such experience.\nThe following sections introduce how to extend through the SPI interaction method.\nSOFARPC provides the capabilities of ExtensionLoader.\nDesign extension points SOFARPC defines an annotation @Extensible, which is on the interface or abstract class to identify that the class is an extension point. Namely, it informs SOFARPC that the class is extensible and SOFARPC needs to find the implementation of the extension point. In addition, the annotation defines the file name of the implementation class and whether the class is a singleton.\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * Specify the name of the custom extension file, which is the full class name by default * * @return Custom extension file name */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * Whether the extension class uses a singleton, yes by default * * @return Whether to use a singleton */ boolean singleton() default true; /** * Whether the extension class needs to be encoded, not by default * * @return Whether to encode */ boolean coded() default false; } SOFARPC also defines the @Extension annotation, which indicates an extension implementation class. It also defines the name that the extension point uses when looking for an extension implementation in the file.\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * Extension point name * * @return Extension point name */ String value(); /** * Extension point coding, not required by default; it is required when the interface needs to be encoded * * @return Extension point encoding * @see Extensible#coded() */ byte code() default -1; /** * Priority sorting, not required by default, the larger number, the higher priority * * @return Sort */ int order() default 0; /** * Whether to override other extensions with low {@link #order()} * * @return Whether to override other low-order extensions * @since 5.2.0 */ boolean override() default false; /** * Exclude other extensions, namely exclude other extensions with low {@link #order()} * * @return Excludes other extensions * @since 5.2.0 */ String[] rejection() default {}; } Add extension point Define extension points. @Extensible public interface Person { void getName(); } Define the extension implementation. @Extension(\u0026amp;quot;A\u0026amp;quot;) public class PersonA implements Person{ @Override public void getName() { System.out.println(\u0026amp;quot;li wei\u0026amp;quot;); } } …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/extension-loader/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"acc5628da3a7ea2df5eb68bd8ec17159","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/extension-loader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/extension-loader/","summary":"ExtensionLoader To ensure that all steps of SOFARPC have sufficient scalability, SOFARPC defines a very flexible extension mechanism in which all extension implementations are equal.\nThis mechanism is very useful for both SOFARPC developers and users. SOFARPC abstracts itself into multiple modules which have no explicit dependencies on each other and interact via SPI.\nThis extension mechanism abstracts the interaction method of SPI. If you have read the documents about Filter and Router, you may have such experience.","tags":null,"title":"Extension mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/extension-loader/","wordcount":603},{"author":null,"categories":null,"content":" Customize different engine stages You can rewrite APIs provided by ActsTestBase in the test script or in the base class.\n Rewrite the prepare, execute, check, and clear actions. For example, you can add some actions before or after super.prepare(). Rewrite the process method. You can add some actions before or after super.process() to reorchestrate the entire script. For example, you can add some personalized steps in the existing clear \u0026amp;gt; prepare \u0026amp;gt; execute \u0026amp;gt; check process. Rewrite beforeActsTest and afterActsTest to add some personalized actions before or after the running of each test case, such as preparing the context and refreshing the cache. Parameterization In response expectation and database expectation data, you can use $Variable name to define a value as a variable. You can set values of the variable in the test script. Supported scope: request parameters, responses, and database table fields. Supported types: Currently, only string parameterization is supported.\nUsage:\n(1) Add $ before a value to define it as a variable in the interface.\n(2) Assign values to the variables in the test script.\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { actsRuntimeContext.paramMap.put(\u0026amp;quot;roleId\u0026amp;quot;, \u0026amp;quot;123\u0026amp;quot;); actsRuntimeContext.refreshDataParam(); } When you write the database expectation, you can use the equal sign = to assign a value to the variable. This indicates that the value is a query result, and subsequent tables can use this variable as the value.\nAssume that the interface will insert data into two tables.\n id_A value_A 123 abc id_B value_B abc efg When you query these two tables, first query for value_A based on id_A in Table A that is returned by the interface. Then use value_A as a condition for the query in Table B. You can set the values as follows in the plug-in.\n Field Flag Value id_A C $param1 value_A Y =param2 Field Flag Value id_B C $param2 value_B Y efg Operation description:\n =param2 and $param2 indicate that the ACTS framework will first query for value_A in Table A, and then select from B where id_B = value_A to obtain the property value of id_B in Table B. $param1 indicates that you can assign a value to id_A in the code, for example: actsRuntimeContext.paramMap.put(\u0026amp;quot;param1\u0026amp;quot;,\u0026amp;quot;123\u0026amp;quot;); This snippet assigns the value 123 to the variable param1. You can write this snippet to beforeActsTest in the test script to make the ACTS framework query table A before assigning the value 123 to id_A.\nComponentization Currently, only string componentization is supported.\nIf a property is a dynamically generated string, for example, some IDs. You can use the at sign @ to call a component to generate this property. The component must be placed in the component package at the same level as the test module, namely: com.corpname.appname.acts.component (appname is the name of the system, and corpname is the name of the company, for …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-api/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ce7e264713a6f7a3f0672e2432489f59","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-api/","summary":"Customize different engine stages You can rewrite APIs provided by ActsTestBase in the test script or in the base class.\n Rewrite the prepare, execute, check, and clear actions. For example, you can add some actions before or after super.prepare(). Rewrite the process method. You can add some actions before or after super.process() to reorchestrate the entire script. For example, you can add some personalized steps in the existing clear \u0026gt; prepare \u0026gt; execute \u0026gt; check process.","tags":null,"title":"Extensions","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-api/","wordcount":1102},{"author":null,"categories":null,"content":" Q: What should I do if NoSuchMethodError is returned? Generally, this error is returned in the case of dependency conflicts. Commonly known dependency conflicts are listed as follows. Exclude the corresponding dependencies when you encounter relevant conflicts.\nLog conflict commons-logging conflict \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-logging\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; logback-classic conflict Rule out logback-classic by the location of the conflict. For example, application dependencies spring-boot-starter-logging and spring-test conflict with each other.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.3.4.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; snakeyaml conflict java.lang.NoSuchMethodError: org.yaml.snakeyaml.Yaml.\u0026amp;lt;init\u0026amp;gt;(Lorg/yaml/snakeyaml/constructor/BaseConstructor;)V org.yaml referenced in spring-boot-starter-test conflicts with org.yaml referenced in org.testing. In the following sample code, a conflict of org.yaml in spring-boot-starter-test is ruled out (it can also be ruled out at other conflict locations such as org.testing):\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.yaml\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;snakeyaml\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Q: What should I do if NoClassDefFoundError is returned? Generally, this error is returned in the case of missing dependencies or dependency conflicts.\nMockito returns a no class found error While using Mockito with SOFABoot, you do not have to import Mockito if the spring-boot-starter-test dependency already exists.\nQ: What should I do if \u0026amp;ldquo;No bean dataAccessConfigManager available\u0026amp;rdquo; is returned? This error is returned because the application starter class specified by the test script does not have the acts-core.xml file. You can add the acts-core.xml file according to the following figure.\nQ: What should I do if \u0026amp;ldquo;No runnable methods\u0026amp;rdquo; is returned? Generally, this error is caused when you run your Junit test with the ACTS test script. You can use the TestNG framework to run the ACTS test script.\nQ: What should I do in the case of a model …","date":-62135596800,"description":"","dir":"projects/sofa-acts/faq/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5f89d1f5695cbe6b669a8738741529bd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/faq/","summary":"Q: What should I do if NoSuchMethodError is returned? Generally, this error is returned in the case of dependency conflicts. Commonly known dependency conflicts are listed as follows. Exclude the corresponding dependencies when you encounter relevant conflicts.\nLog conflict commons-logging conflict \u0026lt;exclusion\u0026gt; \u0026lt;artifactId\u0026gt;commons-logging\u0026lt;/artifactId\u0026gt; \u0026lt;groupId\u0026gt;commons-logging\u0026lt;/groupId\u0026gt; \u0026lt;/exclusion\u0026gt; logback-classic conflict Rule out logback-classic by the location of the conflict. For example, application dependencies spring-boot-starter-logging and spring-test conflict with each other.\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.","tags":null,"title":"FAQ","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/faq/","wordcount":633},{"author":null,"categories":null,"content":" Common issues Q: Is SOFARPC the version used inside Ant Financial? Yes, SOFARPC has excellent extension interfaces, and the version for internal use just has some additional extension implementations based on the open source version. For example, the cloud-based commercial version integrates the Ant Financial Technology\u0026amp;rsquo;s shared registry center, Distributed System Tracing (DST) and other products. The version for internal use integrates Ant Financial\u0026amp;rsquo;s internal registry center, LDC router and other individual extensions.\nQ: Does SOFARPC use ZooKeeper as the registry center internally? Can it integrate other registry centers such as etcd? Ant Financial uses its self-developed registry products internally. SOFARPC\u0026amp;rsquo;s registry modules are extensible. All the registry modules use the same set of core interfaces for both internal and external use. Currently, the open-source version has integrated with ZooKeeper, and other registry implementation communities are being integrated.\nQ: What is the difference between SOFARPC and Dubbo? Dubbo, developed by Alibaba Group, is an excellent open-source RPC framework featuring high performance and good scalability. Dubbo is a comparatively mature open source framework, with a large number of users and rich open source ecology. Now, it has joined the Apache Foundation for incubation. Dubbo was first widely used in the Alibaba B2B department.\nOriginated from HSF in Alibaba Group, SOFARPC now has grown to an independent product. SOFARPC has carried out a lot of reconstruction and optimization on the aspects of protocol, network, routing, and scalability to meet the large-scale financial business scenarios of Ant Financial. In the Ant Financial\u0026amp;rsquo;s middleware (SOFAStack) ecosystem, SOFARPC is supported by a comprehensive microservices technology stack, including Microservices R\u0026amp;amp;D framework, RPC framework, service registry center, distributed scheduling task, throttling framework, Dynamic Configuration, DST, Metrics and others. By Dec. 11, 2017, SOFARPC has been used by thousands of systems in Ant Financial, and the production environment has released more than tens of thousands of interfaces.\nHowever, in the open source field, SOFARPC is still at the initial stage, and its open source ecosystem is still under construction. With the advancement of the open source plan, various related components will be available in the subsequent versions to improve the microservices stack. You are welcome to build SOFAStack together with us.\nIn terms of performance, the technical points of both products involved in protocols are similar. As for scalability, both products have good scalability. As for other functional differences, here are some features that have been opened source or will be open sourced in the near future for reference:\n SOFARPC supports HTTP/2 and GRPC protocols and provides such capabilities as service warm-up weight, automatic degradation upon fault, negotiation mechanism, and CRC data …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/faq/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a6ec77ce5a423c5345394f42c64a416b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/faq/","summary":"Common issues Q: Is SOFARPC the version used inside Ant Financial? Yes, SOFARPC has excellent extension interfaces, and the version for internal use just has some additional extension implementations based on the open source version. For example, the cloud-based commercial version integrates the Ant Financial Technology\u0026rsquo;s shared registry center, Distributed System Tracing (DST) and other products. The version for internal use integrates Ant Financial\u0026rsquo;s internal registry center, LDC router and other individual extensions.","tags":null,"title":"FAQ","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/faq/","wordcount":742},{"author":null,"categories":null,"content":"Usually, a service have multiple service providers in a cluster. Some of the service providers may have persistent connections still survived due to network, configuration, long-term fullgc, full thread pool, hardware failure and others, but the program cannot respond properly. The stand-alone fault tolerance function can degrade the exceptional service providers so that the client requests can be pointed to the healthy node. When the exceptional nodes become normal, the standalone fault tolerance function will restore the nodes, so that the client requests can gradually distribute traffic to the nodes. The standalone fault tolerance function solves the problem that service failures continue to affect the business, avoids the avalanche effect, reduces the long response time required for manual intervention and increases system availability.\nRunning mechanism:\n Standalone fault tolerance counts the number of calls and the number of exceptions in a time range, and calculates the abnormal rate of IP for each service and the average abnormal rate of the service. When the IP abnormal rate is greater than the service average abnormal rate to a certain ratio, the dimension of the service + ip is degraded. If the weight of the service + ip dimension is not degraded to 0, then when the call of the service + ip dimension is normal, the weight will be restored. The entire calculation and control process proceeds asynchronously, thus not blocking the call. The standalone fault tolerance is used as follows:\nFaultToleranceConfig faultToleranceConfig = new FaultToleranceConfig(); faultToleranceConfig.setRegulationEffective(true); faultToleranceConfig.setDegradeEffective(true); faultToleranceConfig.setTimeWindow(20); faultToleranceConfig.setWeightDegradeRate(0.5); FaultToleranceConfigManager.putAppConfig(\u0026amp;quot;appName\u0026amp;quot;, faultToleranceConfig); As above, after the standalone fault tolerance switch is turned on, the application will calculate the exceptions every 20s time window. If a service + IP calling dimension is determined to be a faulty node, the weight of the service + IP will be degraded to 0.5 times.\nFor more detailed parameters, please refer to Standalone troubleshooting\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-tolerance/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7501b0fac1d1d89c61de0d591e29e1d0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","summary":"Usually, a service have multiple service providers in a cluster. Some of the service providers may have persistent connections still survived due to network, configuration, long-term fullgc, full thread pool, hardware failure and others, but the program cannot respond properly. The stand-alone fault tolerance function can degrade the exceptional service providers so that the client requests can be pointed to the healthy node. When the exceptional nodes become normal, the standalone fault tolerance function will restore the nodes, so that the client requests can gradually distribute traffic to the nodes.","tags":null,"title":"Fault tolerance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","wordcount":306},{"author":null,"categories":null,"content":"Fault tolerance automatically monitors the RPC calls, degrades the weight of the failed node, and recovers the weight when the node restored to normal. The bolt protocol is currently supported.\nIn SOFABoot, you only need to configure fault tolerance parameters to application.properties. You can select not to configure all parameters but only configure the parameters that you care about. Then, the remaining parameters will take the default values. Note that rpc.aft.regulation.effective is a global switch for this function. If it is off, the function will not work and other parameters will not take effect.\n Attribute Description Default value timeWindow Time window size: the period in which statistics are calculated. 10s leastWindowCount Minimum number of calls in the time window: Only data that has reached this minimum value in the time window will be added in calculation and control. 10 times leastWindowExceptionRateMultiple Degradation ratio of the exception rate in the time window to the average exception rate of the service: When calculating the statistical information, the average exception rate of all valid call IPs of the service is calculated. If the exception rate of an IP is greater than or equal to the lowest ratio, the IP will be degraded. 6 times weightDegradeRate Degradation ratio: The rate of degradation of an address when it is degraded. 1\u0026amp;frasl;20 weightRecoverRate Recovery ratio: The recovery ratio of the address when it is weighted. 2 times degradeEffective Degradation switch: If the application turns on this switch, it will degrade the address that matches the degradation criteria; otherwise, only the log will be printed. false (off) degradeLeastWeight Degradation minimum weight: If the address weight is degraded to the weight less than this minimum weight, the minimum weight will be used. 1 degradeMaxIpCount Maximum number of IPs for degradation: The number of IPs in the same service that have been degraded cannot exceed this value. 2 regulationEffective Global switch: If the switch is turned on by the application, the entire standalone fault tolerance function will be turned on; otherwise, this function will not be used at all. false (off) Example\nCom.alipay.sofa.rpc.aft.time.window=20 Com.alipay.sofa.rpc.aft.least.window.count=30 Com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple=6 Com.alipay.sofa.rpc.aft.weight.degrade.rate=0.5 Com.alipay.sofa.rpc.aft.weight.recover.rate=1.2 Com.alipay.sofa.rpc.aft.degrade.effective=ture Com.alipay.sofa.rpc.aft.degrade.least.weight=1 Com.alipay.sofa.rpc.aft.degrade.max.ip.count=2 Com.alipay.sofa.rpc.aft.regulation.effective=true As configured above, the fault tolerance function and degradation switch are enabled. When a node fails too many times, its weight is degraded, and during recovery, the weight will be restored. The node healthy is measured every 20s, and the nodes called for more than 30 times in 20s are recognized as calculation data. If the …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-fault-tolerance/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a132b54b2398534d1773489e2b0db166","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","summary":"Fault tolerance automatically monitors the RPC calls, degrades the weight of the failed node, and recovers the weight when the node restored to normal. The bolt protocol is currently supported.\nIn SOFABoot, you only need to configure fault tolerance parameters to application.properties. You can select not to configure all parameters but only configure the parameters that you care about. Then, the remaining parameters will take the default values. Note that rpc.","tags":null,"title":"Fault tolerance configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","wordcount":487},{"author":null,"categories":null,"content":" Feature architecture SOFABolt provides the following basic features: Basic communication functions (remoting-core) Netty-based, highly-effective network I/O and thread model practice Connection management (lock-free connection establishment, timed disconnection, automatic reconnection) Basic communication models (oneway, sync, future, callback) Timeout control Batch unpacking and batch submission processor Heartbeat and IDLE event processing Protocol framework (protocol-skeleton) Commands and command processor Coding and decoding processor Heartbeat trigger Custom private protocol implementation - RPC communication protocol (protocol-implementation) RPC communication protocol design Flexible deserialization timing control Request processing timeout FailFast mechanism User request processor (UserProcessor) Duplex communication Usage 1 Use SOFABolt as a remote communication framework. You do not need to consider the details of how to implement a private protocol, just use our built-in RPC communication protocol. You can simply enable the client side and the server side, and simultaneously register a user request processor, thereby completing the remote calling. In addition, basic features such as connection management and heartbeat are available by default. Currently supported call types are shown in the figure below:\n For a sample demonstration, refer to our user guide. Usage 2 Use SOFABolt as a protocol framework. You can reuse the basic functions of the basic communication model, the interface definitions included in the protocols, etc. Then, according to the private protocol you designed, you can customize the command types, command processors, decoding processors, etc. The RPC and message command definition structure is as shown in the figure below:\n","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-functions/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fde29139cbd8b786326a6479e52814dd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","summary":"Feature architecture SOFABolt provides the following basic features: Basic communication functions (remoting-core) Netty-based, highly-effective network I/O and thread model practice Connection management (lock-free connection establishment, timed disconnection, automatic reconnection) Basic communication models (oneway, sync, future, callback) Timeout control Batch unpacking and batch submission processor Heartbeat and IDLE event processing Protocol framework (protocol-skeleton) Commands and command processor Coding and decoding processor Heartbeat trigger Custom private protocol implementation - RPC communication protocol (protocol-implementation) RPC communication protocol design Flexible deserialization timing control Request processing timeout FailFast mechanism User request processor (UserProcessor) Duplex communication Usage 1 Use SOFABolt as a remote communication framework.","tags":null,"title":"Features","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","wordcount":237},{"author":null,"categories":null,"content":" Features Service publishing and reference Communication Protocol Bolt protocol Basic usage Calling type Timeout control Generic call Serialization protocol Custom thread pool RESTful protocol Basic usage Custom filter Integrated Swagger Dubbo Basic usage H2C Basic usage Registry center Direct call Load balancing Custom filter Custom router addressing Call retry Tracing SOFATracer Skywalking Custom thread pool Link data transparent transmission Warm-up weight Fault tolerance Node cross-language call Graceful shutdown ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/features/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0059809aed46360e8787e945ff098610","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/features/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/features/","summary":" Features Service publishing and reference Communication Protocol Bolt protocol Basic usage Calling type Timeout control Generic call Serialization protocol Custom thread pool RESTful protocol Basic usage Custom filter Integrated Swagger Dubbo Basic usage H2C Basic usage Registry center Direct call Load balancing Custom filter Custom router addressing Call retry Tracing SOFATracer Skywalking Custom thread pool Link data transparent transmission Warm-up weight Fault tolerance Node cross-language call Graceful shutdown ","tags":null,"title":"Features","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/features/","wordcount":68},{"author":null,"categories":null,"content":" 本文描述的是 MOSN 的 FilterChain 配置。\nFilterChain 是 MOSN Listener 配置中核心逻辑配置，不同的 FilterChain 配置描述了 Listener 会如何处理请求。\n目前 MOSN 一个 Listener 只支持一个 FilterChain。\nFilterChain 的配置结构如下所示。\n{ \u0026amp;quot;tls_context\u0026amp;quot;: {}, \u0026amp;quot;tls_context_set\u0026amp;quot;: [], \u0026amp;quot;filters\u0026amp;quot;: [] } tls_context_set 一组 tls_context 配置，MOSN 默认使用 tls_context_set 来描述 listener 的 TLS 的证书信息。 一个 listener 可同时支持配置多张 TLS 证书。 tls_context 单独配置 tls_context 而不是使用 tls_context_set 是兼容 MOSN 历史配置（只支持一张证书配置时）的场景，这种配置方式后面会逐步废弃。 tls_context 的详细配置说明，参考 tls_context。 filters 一组 network filter 配置。\nnetwork filter network filter 描述了 MOSN 在连接建立以后如何在 4 层处理连接数据。\n{ \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: {} } type 是一个字符串，描述了 filter 的类型。 config 可以是任意 json 配置，描述不同 filter 的配置。 network filter 可自定义扩展实现，默认支持的 type 包括 proxy、tcp proxy、connection_manager。 connection_manager 是一个特殊的 network filter，它需要和 proxy 一起使用，用于描述 proxy 中路由相关的配置，是一个兼容性质的配置，后续可能有修改。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/filter-chain/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d79979b85edad41aa6f0b3d8fe3295ee","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","summary":"本文描述的是 MOSN 的 FilterChain 配置。 FilterChain 是 MOSN Listener 配置中核心逻辑配置，不同的 FilterChain 配置描述了 Listener 会如何处理请求。 目前 MOSN 一个 Listener 只支持一个 FilterChain。 FilterChain 的配","tags":null,"title":"FilterChain 配置","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","wordcount":389},{"author":null,"categories":null,"content":" Framework preparation Before reading, you can download and install ACTS IDE and import the ACTS framework by refering to Quick start.\nThis topic mainly describes the encoding, datasource configuration, and quick configuration to help you use the ACTS framework.\nEncoding Ensure that the encoding of ACTS and that of the system code are consistent, specifically, ensure that the encoding for script generation and the encoding of the IDEA workspace are consistent with the encoding of your application code. Otherwise, the code may get corrupted.\nThe encoding selected for test script generation is shown as follows.\nEncoding of the IDEA workspace:\nDatasource configuration The purpose of configuring data sources in ACTS is to ensure that you can use the system\u0026amp;rsquo;s data sources to properly perform database addition, deletion, and query operations during the preparation, clearance, and check stages.\nDatasource configuration Configure the mapping relationship between the ModuleName, datasource, and tables at the DAL layer in src/test/resource/config/acts-config.properties. The name of datasources starts with ds_ as follows:\ndatasource_bundle_name =com.alipay.testapp.common.dal ds_bean1=table1,table2 ds_bean2=table3,table4 #Configuration format #ds_datasource bean=logical table 1,logical table 2 Bean 1 and bean 2 are the names of the datasource beans at the DAL layer of the application code. Multiple datasources are supported. The table name supports regular expressions and sharding suffixes are not required. In the case of multiple datasources, a table must belong to only one datasource. See the following figure.\nDirect JDBC connection to the database The direct JDBC connection to the database is used to generate the DB data model. The configuration in devdb.conf or testdb.conf under src/test/resource/config/dbConf/ is as follows:\nxxx_url = jdbc:oracle:thin:@localhost:1521:cifdb xxx_username = myname xxx_password = mypswd Quick configuration description The quick test framework configuration mainly generates the basic Java classes and the necessary configuration files:\nJava classes AppNameActsBaseUtils.java The utility class that is commonly used in the test script writing process to get various data from the ACTS framework. The initial version provides only common methods. You can add desired methods by yourself.\n AppNameActsTestBase.java The encapsulated application test base class. If you have special business system requirements, you can encapsulate additional methods based on this class. If not, ignore this file.\nConfiguration files ","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ready/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c3a89cbf42d55c98206a08e94d05ffde","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-ready/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-ready/","summary":"Framework preparation Before reading, you can download and install ACTS IDE and import the ACTS framework by refering to Quick start.\nThis topic mainly describes the encoding, datasource configuration, and quick configuration to help you use the ACTS framework.\nEncoding Ensure that the encoding of ACTS and that of the system code are consistent, specifically, ensure that the encoding for script generation and the encoding of the IDEA workspace are consistent with the encoding of your application code.","tags":null,"title":"Framework preparation","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-ready/","wordcount":358},{"author":null,"categories":null,"content":"Since Java 8, Java has introduced various @FunctionalInterface interfaces to support functional programming. Generally, Java functions will be executed in a ForkJoinPool. If some thread variables of Tracer are not passed in, it will cause the loss of Trace information.\nTherefore, in SOFATracer XXX version, a series of wrapper classes for these @FunctionalInterface interfaces has been added to ensure that trace-related information can be transferred correctly and transparently. The following is an example of the Consumer interface, just need to change the construction of Consumer to SofaTracerConsumer, and pass the original Consumer as the parameter of the constructor of SofaTracerConsumer:\nConsumer\u0026amp;lt;String\u0026amp;gt; consumer = new SofaTracerConsumer\u0026amp;lt;\u0026amp;gt;(System.out::println); All wrapped classes are in the https://github.com/sofastack/sofa-tracer/tree/master/tracer-core/src/main/java/com/alipay/common/tracer/core/async directory.\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/functional-interface-support/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"45e4d21f290976f4206beac2f4712aec","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","summary":"Since Java 8, Java has introduced various @FunctionalInterface interfaces to support functional programming. Generally, Java functions will be executed in a ForkJoinPool. If some thread variables of Tracer are not passed in, it will cause the loss of Trace information.\nTherefore, in SOFATracer XXX version, a series of wrapper classes for these @FunctionalInterface interfaces has been added to ensure that trace-related information can be transferred correctly and transparently. The following is an example of the Consumer interface, just need to change the construction of Consumer to SofaTracerConsumer, and pass the original Consumer as the parameter of the constructor of SofaTracerConsumer:","tags":null,"title":"Functional interface support","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","wordcount":113},{"author":null,"categories":null,"content":"从 Java 8 中，Java 开始引入了各种 @FunctionalInterface 接口，以更好地支持函数式编程，通常，Java 的函数会在一个 ForkJoinPool 中执行，如果这个时候没有把 Tracer 的一些线程变量传递进去的话，就会造成 Trace 信息的丢失。\n因此，在 SOFATracer XXX 版本中增加了对这些 @FunctionalInterface 接口的包装类，以确保 Trace 相关的信息能够正确地传递下面，下面以 Consumer 接口为例进行说明，只需要将原来构造 Consumer 的地方修改成构造 SofaTracerConsumer，并且将原来的 Consumer 传入作为 SofaTracerConsumer 的构造函数的参数即可：\nConsumer\u0026amp;lt;String\u0026amp;gt; consumer = new SofaTracerConsumer\u0026amp;lt;\u0026amp;gt;(System.out::println); 所有做了包装的类都在 https://github.com/sofastack/sofa-tracer/tree/master/tracer-core/src/main/java/com/alipay/common/tracer/core/async 目录下，文档中不一一列举。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/functional-interface-support/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"45e4d21f290976f4206beac2f4712aec","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/functional-interface-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/functional-interface-support/","summary":"从 Java 8 中，Java 开始引入了各种 @FunctionalInterface 接口，以更好地支持函数式编程，通常，Java 的函数会在一个 ForkJoinPool 中执行，如果这个时候没有把 Tracer 的一些线程变量传递","tags":null,"title":"Functional 接口支持","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/functional-interface-support/","wordcount":229},{"author":null,"categories":null,"content":" Generic calls provide the ability for clients to initiate calls without having to rely on the server`s interface. Currently, the generic call of SOFARPC only supports using Hessian2 as the serialization protocol under the Bolt communication protocol.\nSOFABoot environment Publish Service There is nothing special about publishing a service. Just publish the service normally, for example:\n\u0026amp;lt;!-- generic --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Reference Service \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.api.GenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs generic-interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; The jvm-first can be left empty according to the actual situation. The interface should be the general interface of generic call. As for the generic-interface, you can just write in the name of the interface to be called.\nInitiate a call GenericService sampleGenericServiceReference = (GenericService) applicationContext .getBean(\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot;); GenericObject genericResult = (GenericObject) sampleGenericServiceReference.$genericInvoke(\u0026amp;quot;sayGeneric\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericParamModel\u0026amp;quot; }, new Object[] { genericObject }); RPC API ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt;() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); You can set the service as a generic service and set the interface name of the server by setGeneric as above. GenericService is used as a generic service, and GenericService can initiate generic calls. You need to pass in the method name, method type, and method parameters when invoking a call.\nIf the parameter or return result is also required to be generalized on the client side, you can achieve this with GenericObject.\nGenericObject genericObject = new GenericObject(\u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot;); genericObject.putField(\u0026amp;quot;str\u0026amp;quot;, \u0026amp;quot;xxxx\u0026amp;quot;); genericObject.putField(\u0026amp;quot;num\u0026amp;quot;, 222); GenericObject result = (GenericObject) testService.$genericInvoke(\u0026amp;quot;echoObj\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot; }, new Object[] { genericObject }); String str = result.getField(\u0026amp;quot;str\u0026amp;quot;); String …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/generic-invoke/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"84ac624dc99a42a8f89489aa10304ef7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","summary":"Generic calls provide the ability for clients to initiate calls without having to rely on the server`s interface. Currently, the generic call of SOFARPC only supports using Hessian2 as the serialization protocol under the Bolt communication protocol.\nSOFABoot environment Publish Service There is nothing special about publishing a service. Just publish the service normally, for example:\n\u0026lt;!-- generic --\u0026gt; \u0026lt;bean id=\u0026quot;sampleGenericServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;sampleGenericServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt/\u0026gt; \u0026lt;/sofa:service\u0026gt; Reference Service \u0026lt;sofa:reference jvm-first=\u0026quot;false\u0026quot; id=\u0026quot;sampleGenericServiceReference\u0026quot; interface=\u0026quot;com.","tags":null,"title":"Generic call","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","wordcount":501},{"author":null,"categories":null,"content":" This document introduces how to use SOFARPC for service publishing and reference in SOFABoot.\nYou can get the code sample of this document by clicking here. Note that the code sample requires a local installation of the zookeeper environment. If not, you need to remove the com.alipay.sofa.rpc.registry.address configuration in application.properties to use the local file as a registry center.\nCreate a project Prepare environment: SOFABoot requires JDK7 or JDK8 and needs to be compiled with Apache Maven 2.2.5 or above. Build SOFABoot project: SOFABoot is based on Spring Boot. So you can use Spring Boot\u0026amp;rsquo;s project generation tool to generate a standard Spring Boot project. Add SOFABoot dependency: The generated standard Spring Boot project directly uses Spring parent dependency, which should be changed to the parent dependency provided by SOFABoot. The parent dependency provides and manages a variety of starters provided by SOFABoot. \u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa-boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Here, \u0026amp;lsquo;${sofa-boot.version}\u0026amp;rsquo; specifies the specific SOFABoot version. Refer to Release History.\n Configure application.properties: application.properties is the configuration file in SOFABoot project. Here you need to configure the application name. spring.application.name=AppName Introduce RPC starter: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Define service interface and implementation public interface AnnotationService { String sayAnnotation(String string); } Publish service on server Publish the service through \u0026amp;lsquo;@SofaService\u0026amp;rsquo; annotation, as shown in the following code: SOFABoot registers the service implementation on the server, communicates with the client by bolt protocol, and publishes metadata such as address to registry center (local file is used as registry center by default).\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } Reference service by client The reference service is annotated with \u0026amp;lsquo;@SofaReference\u0026amp;rsquo;, as shown in the following code: SOFABoot will generate a RPC proxy bean for \u0026amp;lsquo;AnnotationService\u0026amp;rsquo;, it also …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-sofa-boot/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0dd5e0e5116473aee630cba38679d493","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","summary":"This document introduces how to use SOFARPC for service publishing and reference in SOFABoot.\nYou can get the code sample of this document by clicking here. Note that the code sample requires a local installation of the zookeeper environment. If not, you need to remove the com.alipay.sofa.rpc.registry.address configuration in application.properties to use the local file as a registry center.\nCreate a project Prepare environment: SOFABoot requires JDK7 or JDK8 and needs to be compiled with Apache Maven 2.","tags":null,"title":"Get started with SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","wordcount":501},{"author":null,"categories":null,"content":" This document introduces how to apply SOFARPC for service publishing and reference. This example will simulate a server locally to listen to a port and publish a service, and the client will reference the service for direct call.\nYou can get the code sample of this document by clicking here.\nCreate a project You need to install JDK 6 or above and Maven 3 or above.\nCreate a new Maven project and introduce SOFARPC dependency.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;latest version\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note: The latest version can be found at https://github.com/sofastack/sofa-rpc/releases.\nWrite a server implementation Step 1: Create interface\n/** * Quick Start demo interface */ public interface HelloService { String sayHello(String string); } Step 2: Create interface implementation\n/** * Quick Start demo implement */ public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string { System.out.println(\u0026amp;quot;Server receive: \u0026amp;quot; + string); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; !\u0026amp;quot;; } } Step 3: Write the server code\n/** * Quick Start Server */ public class QuickStartServer { public static void main(String[] args) { ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // Set a protocol, which is bolt by default .setPort(12200) // set a port, which is 12200 by default .setDaemon(false); // non-daemon thread ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // Specify the interface .setRef(new HelloServiceImpl()) // Specify the implementation .setServer(serverConfig); // Specify the server providerConfig.export (); // Publish service } } Write a client implementation Step 1: Get the server interface\nIn general, the server provides the interface class to the client in the form of jar. In this example, this step is skipped since the server and client are in the same project.\nStep 2: Write the client code\n/** * Quick Start client */ public class QuickStartClient { public static void main(String[] args) { ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // Specify the interface .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // Specify the protocol.setDirectUrl .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12200\u0026amp;quot;); // Specify the direct connection address // Generate the proxy class HelloService helloService = consumerConfig.refer(); while (true) { System.out.println(helloService.sayHello(\u0026amp;quot;world\u0026amp;quot;)); try { Thread.sleep(2000); } catch (Exception e) { } } } } Run Start the server and client separately.\nThe server outputs:\n Server receive: The world\n The client outputs:\n hello world !\n More For more examples, please refer to: example\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-rpc/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"192d252b0b36266622284b68d10e9fe4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","summary":"This document introduces how to apply SOFARPC for service publishing and reference. This example will simulate a server locally to listen to a port and publish a service, and the client will reference the service for direct call.\nYou can get the code sample of this document by clicking here.\nCreate a project You need to install JDK 6 or above and Maven 3 or above.\nCreate a new Maven project and introduce SOFARPC dependency.","tags":null,"title":"Get started with SOFARPC","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","wordcount":371},{"author":null,"categories":null,"content":" Graceful shutdown includes two parts. One is the RPC framework as client, and the other is the RPC framework as server.\nAs server As the server, the RPC framework should not be violently shutdown.\ncom.alipay.sofa.rpc.context.RpcRuntimeContext Added a ShutdownHook to the static initialization snippet:\n// Add jvm shutdown event if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } The logic in ShutdownHook is executed first when the publishing platform or users run the following method kill pid. In the destroy operation, the RPC framework first performs actions such as canceling service registration to the registry center and closing the service port.\nprivate static void destroy(boolean active) { RpcRunningState.setShuttingDown (true); for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.preDestroy(); } List\u0026amp;lt;ProviderConfig\u0026amp;gt; providerConfigs = new ArrayList\u0026amp;lt;ProviderConfig\u0026amp;gt;(); for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { providerConfigs.add(bootstrap.getProviderConfig()); } // First, unregister the server List\u0026amp;lt;Registry\u0026amp;gt; registries = RegistryFactory.getRegistries(); if (CommonUtils.isNotEmpty(registries) \u0026amp;amp;\u0026amp;amp; CommonUtils.isNotEmpty(providerConfigs)) { for (Registry registry : registries) { registry.batchUnRegister(providerConfigs); } } / / Shut down the port that has been started ServerFactory.destroyAll(); // Close the published service for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { bootstrap.unExport(); } // Close the called service for (ConsumerBootstrap bootstrap : REFERRED_CONSUMER_CONFIGS) { ConsumerConfig config = bootstrap.getConsumerConfig(); If (!CommonUtils.isFalse(config.getParameter(RpcConstants.HIDDEN_KEY_DESTROY))) { // Unless you do not let the active unrefer bootstrap.unRefer(); } } // Shut down the registry center RegistryFactory.destroyAll(); / / Close some public resources of the client ClientTransportFactory.closeAll(); // Uninstall the module if (!RpcRunningState.isUnitTestMode()) { ModuleFactory.uninstallModules(); } // Uninstall the hook for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.postDestroy(); } // Clean up the cache RpcCacheManager.clearAll(); RpcRunningState.setShuttingDown (false); if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework has been release all resources {}...\u0026amp;quot;, active ? \u0026amp;quot;actively \u0026amp;quot; : \u0026amp;quot;\u0026amp;quot;); } } Taking bolt as an example, closing the port is not an immediate action.\n@Override public void destroy() { if (!started) { return; } int stopTimeout = serverConfig.getStopTimeout(); If (stopTimeout \u0026amp;gt; 0) { // need to wait for the end time AtomicInteger count = …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/graceful-shutdown/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"53af179e23ba184b01eb8234c055b15d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","summary":"Graceful shutdown includes two parts. One is the RPC framework as client, and the other is the RPC framework as server.\nAs server As the server, the RPC framework should not be violently shutdown.\ncom.alipay.sofa.rpc.context.RpcRuntimeContext Added a ShutdownHook to the static initialization snippet:\n// Add jvm shutdown event if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.","tags":null,"title":"Graceful shutdown","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","wordcount":669},{"author":null,"categories":null,"content":" H2C protocol SOFARPC provides support for the H2C protocol, which can be used to publish and reference services.\n Basic usage ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"45b6d6ba0ca1ae7f6d415d79c184f766","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/h2c/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/h2c/","summary":" H2C protocol SOFARPC provides support for the H2C protocol, which can be used to publish and reference services.\n Basic usage ","tags":null,"title":"H2C","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/h2c/","wordcount":20},{"author":null,"categories":null,"content":"SOFARPC 提供了 H2C 协议的支持，可以可以采用 H2C 协议来进行服务的发布和引用 * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"45b6d6ba0ca1ae7f6d415d79c184f766","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/h2c/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/h2c/","summary":"SOFARPC 提供了 H2C 协议的支持，可以可以采用 H2C 协议来进行服务的发布和引用 * 基本使用","tags":null,"title":"H2C","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/h2c/","wordcount":36},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 H2C 协议，只要将 Binding 设置为 H2C 即可。下面使用以注解的方式来例举，其他的使用方式可以参考 Bolt 协议基本使用，这里不再重复说明。：\n发布服务 发布一个 H2C 的服务，只需要将 @SofaServiceBinding 的 bindingType 设置为 h2c 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 引用服务 引用一个 H2C 的服务，只需要将 @SofaReferenceBinding 的 bindingType 设置为 h2c 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c-usage/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa75eff1e99b3acad5087160a1b44a09","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/h2c-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/h2c-usage/","summary":"在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 H2C 协议，只要将 Binding 设置为 H2C 即可。下面使用以注解的方式来例举，其他的使用方式可以","tags":null,"title":"H2C 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/h2c-usage/","wordcount":168},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0e92b5faec8584280cc296255f3a4541","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/http/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/http/","summary":"","tags":null,"title":"HTTP","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/http/","wordcount":0},{"author":null,"categories":null,"content":" SOFABoot provides Readiness Check to enhance Spring Boot\u0026amp;rsquo;s Health Check. If you need to use the SOFA middleware, you are advised to use the Health Check extension of SOFABoot to launch application examples in a more elegant way.\nEnable Health Check To enable the Health Check feature in SOFABoot, you only need to import the following starter:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Without the Health Check extension, users still can perform Liveness Check with native Spring Boot Actuator directly relying on the HealthIndicator interface.\nSecurity alert From SOFABoot 2.3.0 on, the Health Check depends on the Actuator component in SpringBoot 1.4.x, and the component opens a lot of EndPoint such as \u0026amp;lsquo;/dump \u0026amp;rsquo; and \u0026amp;lsquo;/trace\u0026amp;rsquo;. So there may be a security risk. Refer to the Security Recommendations in the official document for settings.\nSpringBoot 1.5.x and SpringBoot 2.x. have fixed some security issues. SOFABoot will be supported by upgrading the SpringBoot kernel.\nView Health Check results After adding the Health Check extension, you can directly browser http://localhost:8080/health/readiness to view the Readiness Check results. To view the Liveness Check results, access the URL of the Spring Boot Health Check results. http://localhost:8080/health。\nIn SOFABoot, you can also view Health Check results by checking the specific logs in the health-check directory. Generally, such logs contain the following content:\n2018-04-06 23:29:50,240 INFO main - Readiness check result: success At present, the SOFA middleware has controlled upstream traffic access through the Readiness Check offered by SOFABoot. But, apart from the middleware, traffic of an application may come from other sources such as the load balancer. To control such traffic, users are advised to view the Readiness Check results by PAAS and determine whether to launch corresponding nodes in the load balancer based on the results.\n** Note: Versions after SOFABoot 2.x no longer indirectly introduce spring-boot-starter-web dependencies. To view Health Check results in the browser, you need to introduce Web container dependencies in the project. **\n** Note: In SOFABoot 3.x, the endpoint path has been changed from health/readiness to actuator/readiness**\nReadiness Check extension SOFABoot allows extension in every phase of the Readiness Check. Applications can be extended according to their needs. In version 2.x, the extendable points are as follows:\n Callback interface Description org.springframework.context.ApplicationListener If you want to do something before the Readiness Check, you can monitor the SofaBootBeforeHealthCheckEvent event of this listener. org.springframework.boot.actuate.health.HealthIndicator If you want to add a check item to the Readiness Check in SOFABoot, you can directly extend this interface of Spring Boot. …","date":-62135596800,"description":"","dir":"projects/sofa-boot/health-check/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a366b25125fa4aedb08a9cef572db1c8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/health-check/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/health-check/","summary":"SOFABoot provides Readiness Check to enhance Spring Boot\u0026rsquo;s Health Check. If you need to use the SOFA middleware, you are advised to use the Health Check extension of SOFABoot to launch application examples in a more elegant way.\nEnable Health Check To enable the Health Check feature in SOFABoot, you only need to import the following starter:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;healthcheck-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Without the Health Check extension, users still can perform Liveness Check with native Spring Boot Actuator directly relying on the HealthIndicator interface.","tags":null,"title":"Health check","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/health-check/","wordcount":707},{"author":null,"categories":null,"content":" Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to the article Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing an ACTS bug or adding an ACTS feature, submit an issue on ACTS GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The ACTS maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All ACTS modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step.\nGit clone https://github.com/your account name/acts.git Pull a branch to prepare for code modification.\ngit branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\n git branch -a If you want to switch back to the master branch, execute the following command:\n git checkout -b master If you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\n After modifying the code, execute the following command to submit all modifications to your local repository:\ngit commit -am \u0026#39;Add xx feature\u0026#39; When modifying the code, note the following: Keep the code style consistent. ACTS uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Supplement unit test code.\n New modifications should have passed existing unit tests.\n Provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. Execute the following command to run all tests:\nmvn clean test You can also use the IDE to help run a test.\nOther do\u0026amp;rsquo;s and …","date":-62135596800,"description":"","dir":"projects/sofa-acts/contributing/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"cd68baede6258921f83665ef0a446f1f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/contributing/","summary":"Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to the article Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing an ACTS bug or adding an ACTS feature, submit an issue on ACTS GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/contributing/","wordcount":808},{"author":null,"categories":null,"content":" We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submitting an issue Regardless of whether you are fixing a SOFADashboard bug or adding a SOFADashboard feature, submit an issue on SOFADashboard GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.\nThere are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFADashboard maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All SOFADashboard modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-dashboard.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to the branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFADashboard uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Add the unit test code.\n Modifications should have passed existing unit tests.\n You should provide a new unit test to prove that the previous code has bugs and the bugs\nhave been fixed in the new code. You can execute the following code to run all tests:\n mvn clean test You can also use the IDE to help run a test. …","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/contribution/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"584584be9c13f2d36c85890dd192368a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/contribution/","summary":"We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/contribution/","wordcount":837},{"author":null,"categories":null,"content":" We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of git tools, refer to official books on gitand get familiarized by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFARegistry bug or adding a SOFARegistry feature, submit an issue on the SOFARegistry GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFARegistry maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All SOFARegistry modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review.\nTherefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-registry.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command:\ngit branch -a If you want to switch back to the master branch, execute the following command:\ngit checkout -b master If you want to switch back to the branch, execute the following command:\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFARegistry uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Add the unit test code. Modifications should have passed existing unit tests. You should provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. You can execute the following code to run all tests: mvn clean test You can also use the IDE to help run a test.\nOther do\u0026amp;rsquo;s …","date":-62135596800,"description":"","dir":"projects/sofa-registry/contributing/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c08b5945719137833634c111c43a8d9e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/contributing/","summary":"We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of git tools, refer to official books on gitand get familiarized by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFARegistry bug or adding a SOFARegistry feature, submit an issue on the SOFARegistry GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/contributing/","wordcount":839},{"author":null,"categories":null,"content":" How to contribute SOFABolt\u0026amp;rsquo;s code is open source. You can submit your contributions to the code after signing the required agreement.\nContributor License Agreement Alterations and modifications made to SOFABolt\u0026amp;rsquo;s code must comply with the Contributor License Agreement.\nPrerequisites Before contributing any code, you need to know how to use the Git tool and the GitHub website.\nFor the use of Git tools, refer to the official Pro Git book and get familiar with the tools by reading the first few chapters.\nFor the Git collaboration process, refer to Git Workflows.\nGitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a Bolt bug or adding a Bolt feature, submit an issue on the Bolt GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The Bolt maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the Bolt\u0026amp;rsquo;s master branch code to your code repository.\nPull a branch All Bolt modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with the getting source code step, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/sofastack/sofa-bolt.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to your branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; If you want to directly pull a branch from GitHub, execute the following command: git clone -b branchname https://xxx.git Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. Bolt uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally. mvn clean package Add the unit test code. Modifications should have passed existing unit …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-contribution/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c044ad534cf99e4d6d400113b490f816","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","summary":"How to contribute SOFABolt\u0026rsquo;s code is open source. You can submit your contributions to the code after signing the required agreement.\nContributor License Agreement Alterations and modifications made to SOFABolt\u0026rsquo;s code must comply with the Contributor License Agreement.\nPrerequisites Before contributing any code, you need to know how to use the Git tool and the GitHub website.\nFor the use of Git tools, refer to the official Pro Git book and get familiar with the tools by reading the first few chapters.","tags":null,"title":"How to contribute to SOFABolt","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","wordcount":1140},{"author":null,"categories":null,"content":" Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFAJRaft bug or adding a SOFAJRaft feature, submit an issue on the SOFAJRaft GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFAJRaft maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch We recommend that you first read the SOFAJRaft Branch management policy.\nAll SOFAJRaft modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-jraft Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to the branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFAJRaft uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally. mvn clean compile Add the unit test code.\n New modifications should have passed existing unit tests.\n Provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. Execute the following command to run all tests:\n mvn clean test You can also use the IDE to help execute a command.\nOther do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original style of the …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"99034715298f73cd835672b872141609","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","summary":"Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFAJRaft bug or adding a SOFAJRaft feature, submit an issue on the SOFAJRaft GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute to SOFAJRaft","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","wordcount":841},{"author":null,"categories":null,"content":" Http 协议基本使用 在 SOFARPC (非SOFABoot 环境)中，当使用Http作为服务端协议的时候，支持Json作为序列化方式，作为一些基础的测试方式使用。\nSOFARPC API 使用 发布服务 // 只有1个线程 执行 ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); // 发布一个服务，每个请求要执行1秒 ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026amp;quot;serverApp\u0026amp;quot;)) .setServer(serverConfig) .setUniqueId(\u0026amp;quot;uuu\u0026amp;quot;) .setRegister(false); providerConfig.export(); 服务引用 因为是Http+Json，所以引用方可以直接通过HttpClient进行调用,以下为一段测试代码。\nprivate ObjectMapper mapper = new ObjectMapper(); HttpClient httpclient = HttpClientBuilder.create().build(); // POST 正常请求 String url = \u0026amp;quot;http://127.0.0.1:12300/com.alipay.sofa.rpc.server.http.HttpService:uuu/object\u0026amp;quot;; HttpPost httpPost = new HttpPost(url); httpPost.setHeader(RemotingConstants.HEAD_SERIALIZE_TYPE, \u0026amp;quot;json\u0026amp;quot;); ExampleObj obj = new ExampleObj(); obj.setId(1); obj.setName(\u0026amp;quot;xxx\u0026amp;quot;); byte[] bytes = mapper.writeValueAsBytes(obj); ByteArrayEntity entity = new ByteArrayEntity(bytes, ContentType.create(\u0026amp;quot;application/json\u0026amp;quot;)); httpPost.setEntity(entity); HttpResponse httpResponse = httpclient.execute(httpPost); Assert.assertEquals(200, httpResponse.getStatusLine().getStatusCode()); byte[] data = EntityUtils.toByteArray(httpResponse.getEntity()); ExampleObj result = mapper.readValue(data, ExampleObj.class); Assert.assertEquals(\u0026amp;quot;xxxxx\u0026amp;quot;, result.getName()); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http-json/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"28abdf6369247346bad670c639a422b8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/http-json/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/http-json/","summary":"Http 协议基本使用 在 SOFARPC (非SOFABoot 环境)中，当使用Http作为服务端协议的时候，支持Json作为序列化方式，作为一些基础的测试方式使用。","tags":null,"title":"Http 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/http-json/","wordcount":242},{"author":null,"categories":null,"content":" HttpClient Integration In this document will demonstrate how to use SOFATracer to track of HttpClient, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;!-- SOFATracer dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- HttpClient dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 4.5.X --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpasyncclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 4.X --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.1.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer under the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the current application name and logging.path that specifies the log output directory.\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs Add a Controller that provides RESTful service @RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8080/httpclient?name= * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/httpclient\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;httpclient\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } Construct HttpClient to initiate a call to the RESTful service above The code example is as follows:\n Construct an HttpClient synchronous call instance: HttpClientBuilder httpClientBuilder = HttpClientBuilder.create(); // SOFATracer SofaTracerHttpClientBuilder.clientBuilder(httpClientBuilder); CloseableHttpClient httpClient = httpClientBuilder.setConnectionManager(connManager).disableAutomaticRetries() .build(); Construct an HttpClient asynchronous call instance: RequestConfig requestConfig = RequestConfig.custom().setSocketTimeout(6000).setConnectTimeout(6000).setConnectionRequestTimeout(6000).build(); HttpAsyncClientBuilder httpAsyncClientBuilder = HttpAsyncClientBuilder.create(); //tracer SofaTracerHttpClientBuilder.asyncClientBuilder(httpAsyncClientBuilder); CloseableHttpAsyncClient asyncHttpclient = httpAsyncClientBuilder.setDefaultRequestConfig(requestConfig).build(); When you construct the HttpClient via the SofaTracerHttpClientBuilder (clientBuilder method for synchronous call instance, and asyncClientBuilder method for asynchronous call instance) to initiate a call to the RESTful service above, the link data of …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-httpclient/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3efb3d0d5bd884665537aa974ec21359","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","summary":"HttpClient Integration In this document will demonstrate how to use SOFATracer to track of HttpClient, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;!-- SOFATracer dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- HttpClient dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.apache.httpcomponents\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;httpclient\u0026lt;/artifactId\u0026gt; \u0026lt;!-- 4.5.X --\u0026gt; \u0026lt;version\u0026gt;4.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.apache.httpcomponents\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;httpasyncclient\u0026lt;/artifactId\u0026gt; \u0026lt;!-- 4.X --\u0026gt; \u0026lt;version\u0026gt;4.1.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer under the project\u0026rsquo;s application.","tags":null,"title":"HttpClient Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","wordcount":498},{"author":null,"categories":null,"content":" HttpClient Log Format After integrating tracer-httpclient-plugin, SOFATracer outputs the link data requested by HttpClient in JSON data by default.\nHttpClient digest log (httpclient-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.code HTTP call returns status code req.size.bytes Request body size resp.size.bytes Response body size Time.cost.milliseconds Request time (ms) Current.thread.name Thread name Remote.app Name of the called application Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-27 21:58:43.067\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8801538056723034100235072\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:33,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;I/O dispatcher 1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Note: The application name can be passed in as a parameter when constructing an HttpClient instance via SofaTracerHttpClientBuilder.\nHttpClient statistical Log (httpclient-stat.log) stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success (the result code starting with 1 and 2 indicates success, and 302 indicates that the redirection is successful, and others indicate failure); N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-27 21:59:42.233\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:562,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-httpclient/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7df3d68ba21f1b2a43c0265fdc4eae3e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","summary":"HttpClient Log Format After integrating tracer-httpclient-plugin, SOFATracer outputs the link data requested by HttpClient in JSON data by default.\nHttpClient digest log (httpclient-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.","tags":null,"title":"HttpClient log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","wordcount":220},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 HttpClient 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;!-- SOFATracer 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- HttpClient 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 版本 4.5.X 系列 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpasyncclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 版本 4.X 系列 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.1.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8080/httpclient?name= * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/httpclient\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;httpclient\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } 构造 HttpClient 发起一次对上文的 RESTful 服务的调用 代码示例如下：\n 构造 HttpClient 同步调用实例： HttpClientBuilder httpClientBuilder = HttpClientBuilder.create(); //SOFATracer SofaTracerHttpClientBuilder.clientBuilder(httpClientBuilder); CloseableHttpClient httpClient = httpClientBuilder.setConnectionManager(connManager).disableAutomaticRetries() .build(); 构造 HttpClient 异步调用实例： RequestConfig requestConfig = RequestConfig.custom().setSocketTimeout(6000).setConnectTimeout(6000).setConnectionRequestTimeout(6000).build(); HttpAsyncClientBuilder httpAsyncClientBuilder = HttpAsyncClientBuilder.create(); //tracer SofaTracerHttpClientBuilder.asyncClientBuilder(httpAsyncClientBuilder); CloseableHttpAsyncClient asyncHttpclient = httpAsyncClientBuilder.setDefaultRequestConfig(requestConfig).build(); 通过 SofaTracerHttpClientBuilder(clientBuilder 方法构造同步，asyncClientBuilder 方法构造异步) 构造的 HttpClient 在发起对上文的 RESTful 服务调用的时候，就会埋点 SOFATracer 的链路的数据。\n运行 启动 SOFABoot 应用，在控制台中看到启动打印的日志如下：\n2018-09-27 20:31:21.465 INFO 33277 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-09-27 20:31:21.599 INFO 33277 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-09-27 20:31:21.608 INFO 33277 --- [ main] c.a.s.t.e.h.HttpClientDemoApplication : Started HttpClientDemoApplication in 5.949 seconds (JVM running for 6.573) 当有类似如下的日志时，说明 HttpClient 的调用成功：\n2018-09-27 20:31:22.336 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-httpclient/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3efb3d0d5bd884665537aa974ec21359","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","summary":"在本文档将演示如何使用 SOFATracer 对 HttpClient 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;!-- SOFATracer 依","tags":null,"title":"HttpClient 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","wordcount":748},{"author":null,"categories":null,"content":" SOFATracer 集成 sofa-tracer-httpclient-plugin 插件后输出 HttpClient 请求的链路数据，默认为 JSON 数据格式。\nHttpClient 摘要日志（httpclient-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:43:13.191\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e27a79c1567438993170100210107\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;I/O dispatcher 1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;21ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} 备注：应用名称可以通过 SofaTracerHttpClientBuilder 构造 HttpClient 实例时以入参的形式传入。\nHttpClient 统计日志（httpclient-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功(1 开头和 2 开头的结果码算是成功的，302表示的重定向算成功，其他算是失败的)；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:44:11.785\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:229,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-httpclient/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7df3d68ba21f1b2a43c0265fdc4eae3e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","summary":"SOFATracer 集成 sofa-tracer-httpclient-plugin 插件后输出 HttpClient 请求的链路数据，默认为 JSON 数据格式。 HttpClient 摘要日志（httpclient-digest.log） 以 JSON 格式输出的数据，相应 key 的含","tags":null,"title":"HttpClient 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","wordcount":407},{"author":null,"categories":null,"content":" SOFARPC is integrated Hystrix provides fuse capability and is currently available in the first preview version. More information about Hystrix can be found in Hystrix Official Documentation, Hystrix integration capabilities are provided primarily by ScienJus, thanks for contribution.\nNext, let\u0026amp;rsquo;s talk about how to experience the fuse capability of Hystrix. The following example uses the SOFARPC 5.5.0 version. More Hystrix configuration and SOFABoot integration usage will be provided in subsequent releases, so stay tuned.\nWork preparation The Hystrix module is not loaded directly as an optional module by default. If you need to use it, you need to actively add the Hystrix maven dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; By explicitly opening Hystrix by configuration, HystrixFilter will be loaded automatically:\n// Open globally RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // Open for a specific Consumer ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); FallbackFactory The FallbackFactory interface mainly provides the injection capability of the Fallback implementation, which is used to automatically perform the degraded logic when Hystrix executes an exception (throws an exception, timeout, thread pool rejection, and blown).\nDefine the interface Fallback implementation:\npublic class HelloServiceFallback implements HelloService { @Override public String sayHello(String name, int age) { return \u0026amp;quot;fallback \u0026amp;quot; + name + \u0026amp;quot; from server! age: \u0026amp;quot; + age; } } Inject Fallback implementation:\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); // You can directly inject Fallback implementation directly using the default FallbackFactory SofaHystrixConfig.registerFallback(consumerConfig, new HelloServiceFallback()); // You can also customize FallbackFactory to directly inject FallbackFactory SofaHystrixConfig.registerFallbackFactory(consumerConfig, new HelloServiceFallbackFactory()); When the server responds with a failure, the client automatically triggers the Fallback logic execution.\nSetterFactory SetterFactory provides Hystrix fine-grained configuration capabilities. SOFARPC has provided the default DefaultSetterFactory to generate the Setter for each caller. If there is a more customized description, it can also be provided for each ConsumerConfig. Customize SetterFactory.\nSofaHystrixConfig.registerSetterFactory(consumerConfig, new CustomSetterFactory()); In the implementation provided by default, GroupKey is InterfaceId, and CommandKey is the …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-hystrix/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7482dc341bf16dd5671634ffa689604a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","summary":"SOFARPC is integrated Hystrix provides fuse capability and is currently available in the first preview version. More information about Hystrix can be found in Hystrix Official Documentation, Hystrix integration capabilities are provided primarily by ScienJus, thanks for contribution.\nNext, let\u0026rsquo;s talk about how to experience the fuse capability of Hystrix. The following example uses the SOFARPC 5.5.0 version. More Hystrix configuration and SOFABoot integration usage will be provided in subsequent releases, so stay tuned.","tags":null,"title":"Hystrix fault tolerance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","wordcount":335},{"author":null,"categories":null,"content":" SOFARPC 已集成 Hystrix 提供熔断能力，当前提供第一个预览版。关于 Hystrix 的更多介绍可以参考 Hystrix 官方文档，Hystrix 集成能力主要由 ScienJus 提供，感谢贡献。\n接下来介绍一下如何体验 Hystrix 带来的熔断能力，以下示例使用 SOFARPC 5.5.0 版本，更多 Hystrix 的配置及 SOFABoot 集成使用方式将在后续版本提供，敬请关注。\n准备工作 Hystrix 模块作为可选模块默认不会直接加载，如需要使用，需要先主动加入 Hystrix maven 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 通过配置显式开启 Hystrix，将会自动加载 HystrixFilter：\n// 全局开启 RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // 对特定 Consumer 开启 ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); FallbackFactory FallbackFactory 接口主要提供 Fallback 实现的注入能力，用于在 Hystrix 执行出现异常（抛出异常、超时、线程池拒绝和熔断等）时自动执行降级逻辑。\n定义接口 Fallback 实现：\npublic class HelloServiceFallback implements HelloService { @Override public String sayHello(String name, int age) { return \u0026amp;quot;fallback \u0026amp;quot; + name + \u0026amp;quot; from server! age: \u0026amp;quot; + age; } } 注入 Fallback 实现：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); // 可以直接使用默认的 FallbackFactory 直接注入 Fallback 实现 SofaHystrixConfig.registerFallback(consumerConfig, new HelloServiceFallback()); // 也可以自定义 FallbackFactory 直接注入 FallbackFactory SofaHystrixConfig.registerFallbackFactory(consumerConfig, new HelloServiceFallbackFactory()); 当服务端响应失败时，客户端会自动触发 Fallback 逻辑执行。\nSetterFactory SetterFactory 提供 Hystrix 细粒度配置能力，SOFARPC 已提供默认的 DefaultSetterFactory 来生成每个调用方对应的 Setter，如有更定制化的述求，也可以针对每个 ConsumerConfig 提供自定义 SetterFactory。\nSofaHystrixConfig.registerSetterFactory(consumerConfig, new CustomSetterFactory()); 默认提供的实现中 GroupKey 为 InterfaceId，CommandKey 为方法的名称。\n支持 Hystrix 的版本信息 SOFARPC: 5.5.0, SOFABoot: 2.5.3。\nSOAF RPC 集成验证 Hystrix 版本：1.5.12。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-hystrix/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7482dc341bf16dd5671634ffa689604a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault-hystrix/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault-hystrix/","summary":"SOFARPC 已集成 Hystrix 提供熔断能力，当前提供第一个预览版。关于 Hystrix 的更多介绍可以参考 Hystrix 官方文档，Hystrix 集成能力主要由 ScienJus 提供，感谢贡献。 接下来介绍一","tags":null,"title":"Hystrix 客户端熔断","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault-hystrix/","wordcount":552},{"author":null,"categories":null,"content":" Installation guide To use Istio in a non-Kubernetes environment, you must complete the following critical tasks first:\n Configure the Istio API server for the Istio control plane. You can also use MemStore to launch Pilot for demonstration purpose. Manually add SOFAMosn to all microservice instances and start in SideCar mode. Make sure that all requests are routed through SOFAMosn. Set control plane The Istio control plane consists of four main services: Pilot, Mixter, Citadel, and API server.\nAPI server Istio\u0026amp;rsquo;s API server, which is based on Kubernetes API server, provides configuration management and role-based access control. The API server requires an etcd cluster as the underlying persistent storage.\nInstall locally Use the following Docker compose file to install an API server for POC:\nversion: \u0026#39;2\u0026#39; services: etcd: image: quay.io/coreos/etcd:latest networks: default: aliases: - etcd ports: - \u0026amp;quot;4001:4001\u0026amp;quot; - \u0026amp;quot;2380:2380\u0026amp;quot; - \u0026amp;quot;2379:2379\u0026amp;quot; environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;/usr/local/bin/etcd\u0026amp;quot;, \u0026amp;quot;-advertise-client-urls=http://0.0.0.0:2379\u0026amp;quot;, \u0026amp;quot;-listen-client-urls=http://0.0.0.0:2379\u0026amp;quot; ] istio-apiserver: image: gcr.io/google_containers/kube-apiserver-amd64:v1.7.3 networks: default: aliases: - apiserver ports: - \u0026amp;quot;8080:8080\u0026amp;quot; privileged: true environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;kube-apiserver\u0026amp;quot;, \u0026amp;quot;--etcd-servers\u0026amp;quot;, \u0026amp;quot;http://etcd:2379\u0026amp;quot;, \u0026amp;quot;--service-cluster-ip-range\u0026amp;quot;, \u0026amp;quot;10.99.0.0/16\u0026amp;quot;, \u0026amp;quot;--insecure-port\u0026amp;quot;, \u0026amp;quot;8080\u0026amp;quot;, \u0026amp;quot;-v\u0026amp;quot;, \u0026amp;quot;2\u0026amp;quot;, \u0026amp;quot;--insecure-bind-address\u0026amp;quot;, \u0026amp;quot;0.0.0.0\u0026amp;quot; ] Other control plane components Currently, SOFAMosn hasn\u0026amp;rsquo;t integrated with the components other than Pilot, so you don\u0026amp;rsquo;t need to install Mixer, Citadel and other components.\nAdd SOFAMosn Sidecar to microservice instances Every microservice application instance must have an associated SOFAMosn instance.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-installation/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4c0bd56673dc8aebef9011a22496392d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","summary":"Installation guide To use Istio in a non-Kubernetes environment, you must complete the following critical tasks first:\n Configure the Istio API server for the Istio control plane. You can also use MemStore to launch Pilot for demonstration purpose. Manually add SOFAMosn to all microservice instances and start in SideCar mode. Make sure that all requests are routed through SOFAMosn. Set control plane The Istio control plane consists of four main services: Pilot, Mixter, Citadel, and API server.","tags":null,"title":"Installation guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","wordcount":221},{"author":null,"categories":null,"content":" Project address\n Introduction SOFABoot extends the Health Check of Spring Boot. For detailed information, see SOFABoot Documentation. This sample project is intended to demonstrate how to integrate the Health Check component of SOFABoot during merged deployment. Differences between the Health Check in merged deployment and that of a single SOFABoot application are as follows: + During static merged deployment, all Biz packages must pass the Health Check before the Ark package can be started normally. + When deploying the Biz packages dynamically in Jarslink2.0, all packages must pass the Health Check before successful deployment. + In merged deployment, a new check item named multiApplicationHealthChecker will be added when you access Spring Boot\u0026amp;rsquo;s default /health. The item is used to check the health of all Biz packages. Only after all Biz packages pass the Health Check can the merged package pass the Health Check.\nDependency To integrate the Health Check capability of SOFABoot in merged deployment, you need to add the following dependencies:\n\u0026amp;lt;!--health check--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note that spring-boot-starter-web is excluded to avoid starting multiple web applications when you introduce the healthcheck-sofa-boot-starter dependency.\nDemo cd biz-health-check-sample/app-one \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-one root directory and package the application into an Ark or Biz package. The file will be exported to the biz-health-check-sample/app-one/target directory.\n cd biz-health-check-sample/app-two \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-two root directory and package the application into an Ark or Biz package. The file will be exported to the biz-health-check-sample/app-two/target directory.\n Use java -jar to start the Ark package for app-one.\n After the Ark package has started, visit http://localhost:8080/health in the browser. This is Spring Boot\u0026amp;rsquo;s default Health Check endpoint. A new check item named multiApplicationHealthChecker is added in the results and there is now only one Biz package. The page is displayed as follows: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"99832d969ec54b925c3dca1205b95165","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","summary":"Project address\n Introduction SOFABoot extends the Health Check of Spring Boot. For detailed information, see SOFABoot Documentation. This sample project is intended to demonstrate how to integrate the Health Check component of SOFABoot during merged deployment. Differences between the Health Check in merged deployment and that of a single SOFABoot application are as follows: + During static merged deployment, all Biz packages must pass the Health Check before the Ark package can be started normally.","tags":null,"title":"Integrate SOFABoot health check","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","wordcount":389},{"author":null,"categories":null,"content":" Since rpc-sofa-boot-starter version 6.0.1, SOFARPC provide the ability to integrate RESTful service with Swagger easily.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment and you want to enable Swagger support, first, you need add Swagger dependencies in your pom.xml:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Then you need add a configuration com.alipay.sofa.rpc.restSwagger=true in application.properties.\nFinally, visit http://localhost:8341/swagger/openapi and you can get all the Swagger OpenAPI information about SOFARPC\u0026amp;rsquo;s RESTful services.\nIf you are not using rpc-sofa-boot-starter or the version of rpc-sofa-boot-starter you depends is smaller then 6.0.1, you can integration SOFARPC RESTful service with Swagger by using the following tutorial.\nCurrently, SOFARPC does not provide the ability to integrate RESTful service with Swagger via one click. The ability will be provided in future versions, but you can refer to this document to integrate RESTful service with Swagger in the existing versions of SOFARPC.\nFirst, you need to add Swagger related dependencies into your application. Since SOFARPC\u0026amp;rsquo;s RESTful protocol is based on the JAXRS, so you just need to add Swagger\u0026amp;rsquo;s JAXRS dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; The 20.0 version of Guava was added to resolve Guava version conflict.\nAdd a Swagger RESTful service To enable Swagger to expose SOFARPC\u0026amp;rsquo;s RESTful services through Swagger OpenAPI, we can provide Swagger\u0026amp;rsquo;s OpenAPI services through SOFARPC\u0026amp;rsquo;s RESTful services. First, you need to create a new interface:\n@Path(\u0026amp;quot;swagger\u0026amp;quot;) public interface OpenApiService { @GET @Path(\u0026amp;quot;openapi\u0026amp;quot;) @Produces(\u0026amp;quot;application/json\u0026amp;quot;) String openApi(); } Then provide an implementation class and publish it as a RESTful service of SOFARPC:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}, interfaceType = OpenApiService.class) public class OpenApiServiceImpl implements OpenApiService, InitializingBean { private OpenAPI openAPI; @Override public String openApi() { return Json.pretty(openAPI); } @Override public void afterPropertiesSet() { List\u0026amp;lt;Package\u0026amp;gt; resources = new ArrayList\u0026amp;lt;\u0026amp;gt;(); Resources.add(this.getClass().getPackage()); // Scan the package of the current class, or scan the packages of other SOFARPC RESTful service …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-swagger/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d068767fe0dd2922eecef69736684be8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","summary":"Since rpc-sofa-boot-starter version 6.0.1, SOFARPC provide the ability to integrate RESTful service with Swagger easily.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment and you want to enable Swagger support, first, you need add Swagger dependencies in your pom.xml:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.swagger.core.v3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;swagger-jaxrs2\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.0.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.guava\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;guava\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;20.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Then you need add a configuration com.alipay.sofa.rpc.restSwagger=true in application.properties.\nFinally, visit http://localhost:8341/swagger/openapi and you can get all the Swagger OpenAPI information about SOFARPC\u0026rsquo;s RESTful services.","tags":null,"title":"Integrate with Swagger","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","wordcount":462},{"author":null,"categories":null,"content":"Jarslink2.0 supports receiving dynamic commands at runtime to manage the Biz package lifecycle. Before starting an Ark package that has introduced the Jarslink2.0 plugin, you can send commands through the telnet connection protocol with port 1234. For example, execute telnet ip 1234 to enter the Jarslink2.0 command interface and type \u0026amp;ldquo;help\u0026amp;rdquo; in the interface to obtain all relevant command manuals. Next we will introduce the syntax of each Jarslink2.0 command.\n Install the Biz package: The installation command is used to dynamically deploy of applications. Its syntax is install -b $bizFile. You can replace -b with -biz. All Jarslink2.0 commands must contain either a –b or –biz. The \u0026amp;ldquo;install\u0026amp;rdquo; command has only one parameter, the Biz package URI, which can either be the path of a local file or the link to a remote file, for example, install -b file:///Users/qilong.zql/sample-ark-biz.jar.\n Uninstall the Biz package: The uninstall command is used to close the application. The services released by the application and the resources that it occupied will be destroyed. Command syntax: uninstall -b -n $bizName -v $bizVersion. The command must specify the name and version number of the Biz package by -n and -v, which can be replaced with -name and -version. The name and version number of a Biz package are determined at the time of packaging. For detailed information, see Application Packaging.\n Switch the Biz package: The switch command is used for the Biz package hot update to ensure service continuity. Jarslink2.0 allows loading different versions of Biz packages with the same name at runtime. However, only one Biz package can deliver services at one time. To upgrade the loaded Biz package that is delivering services at runtime, execute the installation command to install a later version of the Biz package. After installation, the newer version is inactive because the older version is providing services. Execute the switch command to switch to the newer version without suspending the services that the application is delivering. This is called a hot update. The command syntax is switch -b -n $bizName -v $bizVersion. Parameters are the same as the above.\n Query the Biz package: The query command is used to query the Biz packages installed in JVM and their status. The command syntax is check -b -n $bizName -v $bizVersion, where the Biz package\u0026amp;rsquo;s name and version number are optional parameters. If you do not specify the name and the version number, information for all Biz packages will be returned. If you only specify the name, information for all versions with the specified name will be returned.\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-instruction/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c7e69fe8035b59c0e191538c8ef3da18","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","summary":"Jarslink2.0 supports receiving dynamic commands at runtime to manage the Biz package lifecycle. Before starting an Ark package that has introduced the Jarslink2.0 plugin, you can send commands through the telnet connection protocol with port 1234. For example, execute telnet ip 1234 to enter the Jarslink2.0 command interface and type \u0026ldquo;help\u0026rdquo; in the interface to obtain all relevant command manuals. Next we will introduce the syntax of each Jarslink2.0 command.","tags":null,"title":"Interactive instruction","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","wordcount":424},{"author":null,"categories":null,"content":" Introduction Jarslink2.0 is a functional SOFABoot plugin developed based on SOFAArk. It manages the merged deployment of multiple applications on top of the SOFAArk container, with the following features: + It supports runtime dynamic installation and uninstallation of applications. + It supports runtime application hot replacement capability to ensure service continuity. + For cross-application communication, it supports the JVM services publish and reference. Cross-application communication can base on RPC framework or internal JVM services. + It supports application Health Check.\nBackground At Ant Financial, it is common to deploy multiple applications on top of the same JVM. Main advantages of this approach are as follows:\n Merged deployment of unrelated applications: Some applications have no service dependencies on each other when they are deployed independently and their volume of business is small, so it would be a waste of resources to start the Java Virtual Machine just for them. Merged deployment of these applications can save resources.\n Merged deployment of related applications: Some applications have service dependencies between them. When deployed independently, RPC calls are used between applications. Despite the high stability of the distributed architecture, there are still delays caused by network jitter. By merged deployment of these applications, JVM internal calls will replace RPC calls, which reduces the call overhead.\n Not only is there merged deployment between applications, but the near-client package has the same appeal.\nThe near-client package is a three-party component that provides a series of public services, normally introduced by the application as a dependency. This development mode is likely to cause two problems:\n The three-party dependency that is introduced by the near-client package conflicts with the dependency of the application itself, so an isolated deployment is expected.\n Since the near-client package is introduced by the application as a dependency, any upgrade of the near-client package will require upgrade of the application as well. However, as a common functional component, many business applications rely on the near-client package as a dependency, which entails a huge amount of transformation. Consequently, a dynamic upgrade of the near-client package is expected.\n In addition to merged deployment, many Ant Financial business scenarios require hot deployment of modules, that is, when the application is running, a specific module needs to be dynamically replaced without affecting the normal running of other modules.\nJarslink2.0 is designed to solve such problems. It is an Ark Plugin developed based on SOFAArk and used to manage the merged deployment of multiple applications. Before getting to know Jarslink2.0, you need to understand the SOFAArk framework. For detailed information of SOFAArk, visit the link.\nPrinciple Jarslink2.0 is an Ark Plugin developed based on SOFAArk. Assuming that you …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-readme/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"48a4bc23f10f1ecca3960aecfd0a77d5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","summary":"Introduction Jarslink2.0 is a functional SOFABoot plugin developed based on SOFAArk. It manages the merged deployment of multiple applications on top of the SOFAArk container, with the following features: + It supports runtime dynamic installation and uninstallation of applications. + It supports runtime application hot replacement capability to ensure service continuity. + For cross-application communication, it supports the JVM services publish and reference. Cross-application communication can base on RPC framework or internal JVM services.","tags":null,"title":"Introduction to Jarslink","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","wordcount":651},{"author":null,"categories":null,"content":" Pilot introduction The SOFAMesh project forked the Istio project to enhance Pilot\u0026amp;rsquo;s capabilities. Currently, the ongoing enhancements are focused on the following three areas:\n Support ZooKeeper as a registry center, and support SOFA, DUBBO and other microservice frameworks using ZooKeeper as a registry center. Support the common protocol framework. Use a common protocol, and support multiple protocols simultaneously based on Kubernetes DNS. Add register agent to support the container models of SOFA, Dubbo and HSF. Namely, a single application can register multiple service instances. ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-readme/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7b098e394986596d8fb01e1fe2120829","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","summary":"Pilot introduction The SOFAMesh project forked the Istio project to enhance Pilot\u0026rsquo;s capabilities. Currently, the ongoing enhancements are focused on the following three areas:\n Support ZooKeeper as a registry center, and support SOFA, DUBBO and other microservice frameworks using ZooKeeper as a registry center. Support the common protocol framework. Use a common protocol, and support multiple protocols simultaneously based on Kubernetes DNS. Add register agent to support the container models of SOFA, Dubbo and HSF.","tags":null,"title":"Introduction to Pilot","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","wordcount":84},{"author":null,"categories":null,"content":" ## Product description SOFAArk is a light-weight，java based classloader isolation framework open sourced by Ant Financial. Based on Fat Jar technology, the container can pack simple single-module Java applications or Spring Boot applications into a self-contained executable Fat Jar, known as an Ark package. When the java -jar command is used to start an Ark package embedded with the SOFAArk class isolation container, the SOFAArk container will start, and it then starts each Ark plugin and application.\nBackground In Java world, dependency is always a problem, and can cause various errors, such as LinkageError, NoSuchMethodError etc. There are many ways to solve the dependency problems, the Spring Boot\u0026amp;rsquo;s way is using a dependency management to manage all the dependencies, make sure that all the dependencies in the dependency management will not conflict and can work pretty well. This is quite a simple and efficient way, it can cover most scenario, but there is some exceptions.\nFor example, there is a project that need protobuf version 2 and protobuf version 3, and because protobuf version 3 is not compatible with version 2, so the project can not simply upgrade the protobuf to version 3 to solve the problem. There is same problem for hessian version 3 and version 4.\nTo cover those exceptions, we need to introduce a classloader isolation way, make different version of a framework loaded by different classloader. There are many framework that can do classloader isolation, perhaps the most famous one is OSGi, but OSGi classloader schema is too complex, beside classloader isolation, it also has ability to do hot deploy and a lot of other functionalities that we actually don\u0026amp;rsquo;t want.\nSo this is the origin of SOFAArk, it\u0026amp;rsquo;s goal is to use a light-weight classloader isolation mechanism to solve the problem that Spring Boot did not solve. And just a remind that SOFAArk is not bind to Spring Boot, actually it is a more general classloader isolation framework that can be used with any other frameworks too.\nHow SOFAArk Works There are three concepts in SOFAArk: Ark Container, Ark-Plugin and Ark-Biz; they are organized as what the following graph shows:\nFirst of all, we explain what roles these concepts play;\n Ark Container: It\u0026amp;rsquo;s the runtime manager of total framework; it will startup in the first place, then it resolves Ark Plugin and Ark Biz in classpath and deploys them.\n Ark Plugin: A fat jar packaged by sofa-ark-plugin-maven-plugin, generally it would bring with a class-index configuration which describes what class would be exported and imported. Ark Plugin can resolve classes from each other.\n Ark Biz: A fat jar packaged by sofa-ark-maven-plugin, it mainly contains all staff what a project need in runtime. Ark Biz can resolve classes form Ark Plugin, but not inverse.\n In runtime, Ark Container would automatically recognize Ark-Plugin and Ark-Biz in classpath, and load them with the independent classloader. According to …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-readme/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"cdb6729fc7a63954b7559c8ea319f550","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","summary":"## Product description SOFAArk is a light-weight，java based classloader isolation framework open sourced by Ant Financial. Based on Fat Jar technology, the container can pack simple single-module Java applications or Spring Boot applications into a self-contained executable Fat Jar, known as an Ark package. When the java -jar command is used to start an Ark package embedded with the SOFAArk class isolation container, the SOFAArk container will start, and it then starts each Ark plugin and application.","tags":null,"title":"Introduction to SOFAArk","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","wordcount":642},{"author":null,"categories":null,"content":" MOSN, the short name of Modular Observable Smart Network, is a powerful proxy acting as Service Mesh\u0026amp;rsquo;s data plane like Envoy but written in Go. MOSN supports Envoy and Istio\u0026amp;rsquo;s APIs and can be integrated with Istio, so we use MOSN instead of Envoy in SOFAMesh. The initial version of MOSN was jointly contributed by Ant Financial and UC Business Unit of Alibaba, and we look forward to the community to participate in the follow-up development and build an open source excellent project together.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/sofa-mosn-readme/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"11219bb3b9689ec5f328b8281bd62a95","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","summary":"MOSN, the short name of Modular Observable Smart Network, is a powerful proxy acting as Service Mesh\u0026rsquo;s data plane like Envoy but written in Go. MOSN supports Envoy and Istio\u0026rsquo;s APIs and can be integrated with Istio, so we use MOSN instead of Envoy in SOFAMesh. The initial version of MOSN was jointly contributed by Ant Financial and UC Business Unit of Alibaba, and we look forward to the community to participate in the follow-up development and build an open source excellent project together.","tags":null,"title":"Introduction to SOFAMosn","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","wordcount":223},{"author":null,"categories":null,"content":" Introduction to RheaKV RheaKV is a lightweight, distributed, and embedded KV storage library, which is included in the JRaft project as a submodule.\nFeatures\n Embedded: RheaKV is embedded in applications in the form of Jar files. Strong consistency: RheaKV ensures data reliability and consistency based on the multi-raft distributed consensus protocol. Self-driven (not fully implemented at present): RheaKV supports automatic diagnosis, optimization, decision making, and recovery. Monitorable: RheaKV automatically reports meta information and state information by node to the PD. Basic APIs: get, put, and delete; cross-region APIs: scan, batch put, and distributed lock. Architecture design Terms and definitions PD: The global central master node that is responsible for scheduling the entire cluster. A PD server can manage multiple clusters, with each of them isolated by clusterId. The PD server requires separate deployment. Actually, many scenarios do not need automatic cluster management, and RheaKV does not support PD. Store: A physical storage node within a cluster. A store may contain one or more regions. Region: The minimal KV data unit. Each region can be understood as a database partition or database shard, and has a left closed and right open interval [startKey, endKey). Storage design The storage layer adopts a pluggable design and supports both MemoryDB and RocksDB currently: MemoryDB is implemented based on ConcurrentSkipListMap and provides better performance. However, its independent storage capacity is restricted by the memory. RocksDB is suitable for scenarios with large data volumes, because its storage capacity is only restricted by the disk. Strong data consistency is ensured. RheaKV synchronizes data to other replicas with the help of JRaft, and each data change is recorded as a Raft log entry. The log replication feature of Raft ensures all data is securely and reliably synchronized to all nodes within the same Raft group. Scenarios Lightweight state/meta information storage and cluster synchronization Distributed lock service API description Generally, RheaKV APIs are divided into two types: synchronous APIs and asynchronous APIs. Methods whose names start with letter b (block) are synchronous blocking APIs, and the rest are asynchronous APIs. All asynchronous APIs return the same CompletableFuture parameter. The read method may contain another important parameter, that is readOnlySafe. When this parameter is set to true, linearizable read is supported. Read methods that do not contain this parameter provide linearizable read by default.\nget CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key, final boolean readOnlySafe); byte[] bGet(final byte[] key); byte[] bGet(final String key); byte[] bGet(final byte[] key, final boolean …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-rheakv-user-guide/","fuzzywordcount":4100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e6fa7125455982961214dfe82245be4d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":20,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","summary":"Introduction to RheaKV RheaKV is a lightweight, distributed, and embedded KV storage library, which is included in the JRaft project as a submodule.\nFeatures\n Embedded: RheaKV is embedded in applications in the form of Jar files. Strong consistency: RheaKV ensures data reliability and consistency based on the multi-raft distributed consensus protocol. Self-driven (not fully implemented at present): RheaKV supports automatic diagnosis, optimization, decision making, and recovery. Monitorable: RheaKV automatically reports meta information and state information by node to the PD.","tags":null,"title":"JRaft RheaKV user guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","wordcount":4086},{"author":null,"categories":null,"content":" RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 lib， rheaKV 包含在 jraft 项目中，是 jraft 的一个子模块。\n定位与特性\n 嵌入式: jar 包方式嵌入到应用中 强一致性: 基于 multi-raft 分布式一致性协议保证数据可靠性和一致性 自驱动 （目前未完全实现）: 自诊断, 自优化, 自决策, 自恢复 可监控: 基于节点自动上报到PD的元信息和状态信息 基本API: get/put/delete 和跨分区 scan/batch put, distributed lock 等等 架构设计 功能名词 PD: 全局的中心总控节点，负责整个集群的调度，一个 PD server 可以管理多个集群，集群之间基于 clusterId 隔离；PD server 需要单独部署，当然，很多场景其实并不需要自管理，rheaKV 也支持不启用 PD Store: 集群中的一个物理存储节点，一个 store 包含一个或多个 region Region: 最小的 KV 数据单元，可理解为一个数据分区或者分片，每个 region 都有一个左闭右开的区间 [startKey, endKey) 存储设计 存储层为可插拔设计， 目前支持 MemoryDB 和 RocksDB 两种实现： MemoryDB 基于 ConcurrentSkipListMap 实现，有更好的性能，但是单机存储容量受内存限制 RocksDB 在存储容量上只受磁盘限制，适合更大数据量的场景 数据强一致性， 依靠 jraft 来同步数据到其他副本, 每个数据变更都会落地为一条 raft 日志, 通过 raft 的日志复制功能, 将数据安全可靠地同步到同 group 的全部节点中 使用场景 轻量级的状态/元信息存储以及集群同步 分布式锁服务 API 说明 整体上 rheaKV apis 分为异步和同步两类， 其中以 b （block）开头的方法均为同步阻塞方法， 其他为异步方法，异步方法均返回一个 CompletableFuture，对于 read method， 还有一个重要参数 readOnlySafe，为 true 时表示提供线性一致读， 不包含该参数的 read method 均为默认提供线性一致读\nget CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key, final boolean readOnlySafe); byte[] bGet(final byte[] key); byte[] bGet(final String key); byte[] bGet(final byte[] key, final boolean readOnlySafe); byte[] bGet(final String key, final boolean readOnlySafe); String 类型入参，rheaKV 内部提供了更高效的 Utf8String encoder/decoder， 业务 key 为 String 时， 推荐的做法是直接使用 String 参数的接口 不需要线性一致读语义的场景可以将 readOnlySafe 设置为 false， 负载均衡器会优先选择本地调用，本地不能提供服务则轮询选择一台远程机器发起读请求 multiGet CompletableFuture\u0026amp;lt;Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt;\u0026amp;gt; multiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys); CompletableFuture\u0026amp;lt;Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt;\u0026amp;gt; multiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys, final boolean readOnlySafe); Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt; bMultiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys); Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt; bMultiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys, final boolean readOnlySafe); multiGet 支持跨分区查询，rheaKV 内部会自动计算每个 key 的所属分区（region）并行发起调用， 最后合并查询结果 为了可以将 byte[] 放进 HashMap，这里曲线救国，返回值中 Map 的 key 为 ByteArray 对象，是对 byte[] 的一层包装，实现了 byte[] 的 hashCode scan \u0026amp;amp; iterator CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final byte[] startKey, final byte[] endKey); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final String startKey, final String endKey); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final byte[] startKey, final byte[] endKey, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final String startKey, final String endKey, final boolean readOnlySafe); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final byte[] startKey, final byte[] endKey); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final String startKey, final String endKey); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final byte[] startKey, final byte[] endKey, final boolean readOnlySafe); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final String startKey, final String endKey, final boolean readOnlySafe); RheaIterator\u0026amp;lt;KVEntry\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-rheakv-user-guide/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e6fa7125455982961214dfe82245be4d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":13,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","summary":"RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 lib， rheaKV 包含在 jraft 项目中，是 jraft 的一个子模块。 定位与特性 嵌入式: jar 包方式嵌入到应用中 强一致性: 基于 multi-raft 分布","tags":null,"title":"JRaft RheaKV 用户指南","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","wordcount":6408},{"author":null,"categories":null,"content":" 0. Basic concepts Every request submitted by log index to a Raft group is serialized into a log entry. Each log entry has an ID, which monotonically increases within the Raft group, and the log entries are replicated to every Raft node in the group. Term is a long-type number that monotonically increases within the Raft group. You can simply take it as the number of votes. The term of an elected leader is called the leader term. Before this leader steps down, log entries submitted during this period have the same term. 1. Configuration and supporting classes This topic mainly describes the configuration and utility methods and classes. The core objects are:\n Endpoint, which refers to a service address PeerId, which refers to ID of a Raft node Configuration, which refers to the configuration of a Raft group, or a node list in other words. 1.1 Endpoint Endpoint refers to a service address, including the IP address and the port number. Raft nodes must not be started on the IPv4 address 0.0.0.0. The startup IP address must be clearly specified Create a address, and bind it to port 8080 of the local host, as shown in the following example:\nEndpoint addr = new Endpoint(\u0026amp;quot;localhost\u0026amp;quot;, 8080); String s = addr.toString(); // The result is localhost:8080 PeerId peer = new PeerId(); boolean success = peer.parse(s); // Specifies whether parsing the endpoint from a string is supported. The result is true. 1.2 PeerId A PeerId indicates a participant (leader, follower, or candidate) of the Raft protocol. It comprises three elements in the format of ip:port:index, where ip is the IP address of the node, port is the port number, and index is the serial number of the same port. Currently, the index is not used, and is always set to 0. This field is reserved to allow starting different Raft nodes from the same port and to differentiate them by index.\nCreate a PeerId and set the index to 0, the IP to localhost, and the port to 8080:\nPeerId peer = new PeerId(\u0026amp;quot;localhost\u0026amp;quot;, 8080); EndPoint addr = peer.getEndpoint(); // Gets the endpoint of a node int index = peer.getIdx(); // Gets the index of a node, which is always set to 0 currently String s = peer.toString(); // The result is localhost:8080 boolean success = peer.parse(s); // Specifies whether PeerId parsing from a string is supported. The result is true. 1.3 Configuration It refers to the configuration of a Raft group, or a participant list in other words.\nPeerId peer1 = ... PeerId peer2 = ... PeerId peer3 = ... // A Raft group that consists of three nodes Configuration conf = new Configuration(); conf.addPeer(peer1); conf.addPeer(peer2); conf.addPeer(peer3); 1.4 JRaftUtils utility class To enable users conveniently create objects such as Endpoint, PeerId, and Configuration, Jraft provides the JRaftUtils class to help users quickly create the required objects from strings.\nEndpoint addr = JRaftUtils.getEndpoint(\u0026amp;quot;localhost:8080\u0026amp;quot;); PeerId peer = …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-user-guide/","fuzzywordcount":8400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"105dfa34c3b20df1f2c23c112730507d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":39,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","summary":"0. Basic concepts Every request submitted by log index to a Raft group is serialized into a log entry. Each log entry has an ID, which monotonically increases within the Raft group, and the log entries are replicated to every Raft node in the group. Term is a long-type number that monotonically increases within the Raft group. You can simply take it as the number of votes. The term of an elected leader is called the leader term.","tags":null,"title":"JRaft user guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","wordcount":8306},{"author":null,"categories":null,"content":" 1. 基本概念说明 log index 提交到 raft group 中的任务都将序列化为一条日志存储下来，每条日志一个编号，在整个 raft group 内单调递增并复制到每个 raft 节点。 term 在整个 raft group 中单调递增的一个 long 数字，可以简单地认为表示一轮投票的编号，成功选举出来的 leader 对应的 term 称为 leader term，在这个 leader 没有发生变更的阶段内提交的日志都将拥有相同的 term 编号。 2. 配置和辅助类 本节主要介绍 jraft 的配置和辅助工具相关接口和类。核心包括：\n Endpoint 表示一个服务地址。 PeerId 表示一个 raft 参与节点。 Configuration 表示一个 raft group 配置，也就是节点列表。 2.1 地址 Endpoint Endpoint 表示一个服务地址，包括 IP 和端口， raft 节点不允许启动在 0.0.0.0 所有的 IPv4 上，需要明确指定启动的 IP 创建一个地址，绑定在 localhost 的 8080 端口上，如下例：\nEndpoint addr = new Endpoint(\u0026amp;quot;localhost\u0026amp;quot;, 8080); String s = addr.toString(); // 结果为 localhost:8080 PeerId peer = new PeerId(); boolean success = peer.parse(s); // 可以从字符串解析出地址，结果为 true 2.2 节点 PeerId PeerId 表示一个 raft 协议的参与者（leader/follower/candidate etc.)， 它由三元素组成： ip:port:index， IP 就是节点的 IP， port 就是端口， index 表示同一个端口的序列号，目前没有用到，总被认为是 0。预留此字段是为了支持同一个端口启动不同的 raft 节点，通过 index 区分。\n创建一个 PeerId, index 指定为 0， ip 和端口分别是 localhost 和 8080:\nPeerId peer = new PeerId(\u0026amp;quot;localhost\u0026amp;quot;, 8080); Endpoint addr = peer.getEndpoint(); // 获取节点地址 int index = peer.getIdx(); // 获取节点序号，目前一直为 0 String s = peer.toString(); // 结果为 localhost:8080 boolean success = peer.parse(s); // 可以从字符串解析出 PeerId，结果为 true 2.3 配置 Configuration Configuration 表示一个 raft group 的配置，也就是参与者列表：\nPeerId peer1 = ... PeerId peer2 = ... PeerId peer3 = ... // 由 3 个节点组成的 raft group Configuration conf = new Configuration(); conf.addPeer(peer1); conf.addPeer(peer2); conf.addPeer(peer3); 2.4 工具类 JRaftUtils 为了方便创建 Endpoint/PeerId/Configuration 等对象， jraft 提供了 JRaftUtils 来快捷地从字符串创建出所需要的对象：\nEndpoint addr = JRaftUtils.getEndpoint(\u0026amp;quot;localhost:8080\u0026amp;quot;); PeerId peer = JRaftUtils.getPeerId(\u0026amp;quot;localhost:8080\u0026amp;quot;); // 三个节点组成的 raft group 配置，注意节点之间用逗号隔开 Configuration conf = JRaftUtils.getConfiguration(\u0026amp;quot;localhost:8081,localhost:8082,localhost:8083\u0026amp;quot;); 2.5 回调 Closure 和状态 Status Closure 就是一个简单的 callback 接口， jraft 提供的大部分方法都是异步的回调模式，结果通过此接口通知：\npublic interface Closure { /** * Called when task is done. * * @param status the task status. */ void run(Status status); } 结果通过 Status 告知，Status#isOk() 告诉你成功还是失败，错误码和错误信息可以通过另外两个方法获取：\nboolean success= status.isOk(); RaftError error = status.getRaftError(); // 错误码，RaftError 是一个枚举类 String errMsg = status.getErrorMsg(); // 获取错误详情 Status 提供了一些方法来方便地创建：\n// 创建一个成功的状态 Status ok = Status.OK(); // 创建一个失败的错误，错误信息支持字符串模板 String filePath = \u0026amp;quot;/tmp/test\u0026amp;quot;; Status status = new Status(RaftError.EIO, \u0026amp;quot;Fail to read file from %s\u0026amp;quot;, filePath); 2.6 任务 Task Task 是用户使用 jraft 最核心的类之一，用于向一个 raft 复制分组提交一个任务，这个任务提交到 leader，并复制到其他 follower 节点， Task 包括：\n ByteBuffer data 任务的数据，用户应当将要复制的业务数据通过一定序列化方式（比如 java/hessian2) 序列化成一个 ByteBuffer，放到 task 里。 long expectedTerm = -1 任务提交时预期的 leader term，如果不提供(也就是默认值 -1 )，在任务应用到状态机之前不会检查 leader 是否发生了变更，如果提供了（从状态机回调中获取，参见下文），那么在将任务应用到状态机之前，会检查 term 是否匹配，如果不匹配将拒绝该任务。 Closure done 任务的回调，在任务完成的时候通知此对象，无论成功还是失败。这个 closure 将在 StateMachine#onApply(iterator) 方法应用到状态机的时候，可以拿到并调用，一般用于客户端应答的返回。 创建一个简单 Task 实例：\nClosure done = ...; Task task = new …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-user-guide/","fuzzywordcount":13200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"105dfa34c3b20df1f2c23c112730507d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":27,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","summary":"1. 基本概念说明 log index 提交到 raft group 中的任务都将序列化为一条日志存储下来，每条日志一个编号，在整个 raft group 内单调递增并复制到每个 raft 节点。 term 在整个 raft group 中单","tags":null,"title":"JRaft 用户指南","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","wordcount":13134},{"author":null,"categories":null,"content":" SOFABoot 提供三种方式给开发人员发布和引用 JVM 服务\n XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上面的 Bean 发布成一个 SOFA JVM 服务。\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 上面的配置中的 interface 指的是需要发布成服务的接口，ref 指向的是需要发布成 JVM 服务的 Bean，至此，我们就已经完成了一个 JVM 服务的发布。\n服务引用 使用 SOFA 提供的 Spring 扩展标签引用服务:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上面的配置中的 interface 是服务的接口，需要和发布服务时配置的 interface 一致。id 属性的含义同 Spring BeanId。上面的配置会生成一个 id 为 sampleServiceRef 的 Spring Bean，你可以将 sampleServiceRef 这个 Bean 注入到当前 SOFABoot 模块 Spring 上下文的任意地方。\n service/reference 标签还支持 RPC 服务发布，相关文档: RPC 服务发布与引用\n Annotation 方式 警告\n如果一个服务已经被加上了 @SofaService 的注解，它就不能再用 XML 的方式去发布服务了，选择一种方式发布服务，而不是两种混用。\n 除了通过 XML 方式发布 JVM 服务和引用之外，SOFABoot 还提供了 Annotation 的方式来发布和引用 JVM 服务。通过 Annotation 方式发布 JVM 服务，只需要在实现类上加一个 @SofaService 注解即可，如下：\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } 提示\n@SofaService 的作用是将一个 Bean 发布成一个 JVM 服务，这意味着虽然你可以不用再写 \u0026amp;lt;sofa:service/\u0026amp;gt; 的配置，但是还是需要事先将 @SofaService 所注解的类配置成一个 Spring Bean。\n 在使用 XML 配置 \u0026amp;lt;sofa:service/\u0026amp;gt; 的时候，我们配置了一个 interface 属性，但是在使用 @SofaService 注解的时候，却没有看到有配置服务接口的地方。这是因为当被 @SofaService 注解的类只有一个接口的时候，框架会直接采用这个接口作为服务的接口。当被 @SofaService 注解的类实现了多个接口时，可以设置 @SofaService 的 interfaceType 字段来指定服务接口，比如下面这样：\n@SofaService(interfaceType=SampleInterface.class) public class SampleImpl implements SampleInterface, Serializable { public void test() { } } 和 @SofaService 对应，Sofa 提供了 @SofaReference 来引用一个 JVM 服务。假设我们需要在一个 Spring Bean 中使用 SampleJvmService 这个 JVM 服务，那么只需要在字段上加上一个 @SofaReference 的注解即可：\npublic class SampleServiceRef { @SofaReference private SampleService sampleService; } 和 @SofaService 类似，我们也没有在 @SofaReference 上指定服务接口，这是因为 @SofaReference 在不指定服务接口的时候，会采用被注解字段的类型作为服务接口，你也可以通过设定 @SofaReference 的 interfaceType 属性来指定：\npublic class SampleServiceRef { @SofaReference(interfaceType=SampleService.class) private SampleService sampleService; } 使用 @SofaService 注解发布服务时，需要在实现类上打上 @SofaService 注解；在 Spring Boot 使用 Bean Method 创建 Bean 时，会导致 @Bean 和 @SofaService 分散在两处，而且无法对同一个实现类使用不同的 unique id。因此自 SOFABoot v2.6.0 及 v3.1.0 版本起，支持 @SofaService 作用在 Bean Method 之上，例如：\n@Configuration public class SampleSofaServiceConfiguration { @Bean(\u0026amp;quot;sampleSofaService\u0026amp;quot;) @SofaService(uniqueId = \u0026amp;quot;service1\u0026amp;quot;) SampleService service() { return new SampleServiceImpl(\u0026amp;quot;\u0026amp;quot;); } } 同样为了方便在 Spring Boot Bean Method 使用注解 @SofaReference 引用服务，自 SOFABoot v2.6.0 及 v3.1.0 版本起，支持在 Bean Method 参数上使用 @SofaReference 注解引用 JVM 服务，例如：\n@Configuration public class MultiSofaReferenceConfiguration { @Bean(\u0026amp;quot;sampleReference\u0026amp;quot;) TestService …","date":-62135596800,"description":"","dir":"projects/sofa-boot/module-service/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"527472fbe57ce450e4e2b41d878704cb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/module-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/module-service/","summary":"SOFABoot 提供三种方式给开发人员发布和引用 JVM 服务 XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean： \u0026lt;bean id=\u0026quot;sampleService\u0026quot; class=\u0026quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026quot;\u0026gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上","tags":null,"title":"JVM 服务发布与引用","type":"projects","url":"/sofastack.tech/projects/sofa-boot/module-service/","wordcount":1926},{"author":null,"categories":null,"content":" 1. Create a Maven project and import the dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. Create the SOFARegistry client instance The key code for creating the SOFARegistry client instance is as follows:\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); Properties related to SOFARegistry are specified by the DefaultRegistryClientConfigBuilder class, which provides the following key properties:\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } Property Type Description instanceId String The ID of the instance. Default value: DEFAULT_INSTANCE_ID. The same instance ID must be used for data publishing and subscription. The unique data identifier consists of dataId+group+instanceId. zone String The zone where the instance is located. Default value: DEFAULT_ZONE. registryEndpoint String The endpoint of any session node of the servers. registryEndpointPort Integer The session.server.httpServerPort configured for a session node. Default value: 9603. dataCenter String The data center of SOFARegistry. Default value: DefaultDataCenter. appName String The name of the app that accesses SOFARegistry. connectTimeout Integer Specifies the timeout for establishing a connection with a server. Default value: 3000 ms. socketTimeout Integer Specifies the timeout for accessing the servers\u0026amp;rsquo; REST API. Default value: 3000 ms. invokeTimeout Integer Specifies the timeout for calling services on the servers. Default value: 1000 ms. recheckInterval Integer Specifies the interval for checking the task queue. Default value: 500 ms. observerThreadCoreSize Integer Specifies the number of core threads in the thread pool that process data pushed from the servers. Default value: 5. observerThreadMaxSize Integer Specifies the maximum number of threads in the thread pool that process data pushed from the servers. Default value: 10. observerThreadQueueLength Integer Specifies the maximum thread queue length of the thread pool that processes data pushed from the servers. Default value: 1000. syncConfigRetryInterval Integer Specifies the retry interval to synchronize the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/java-sdk/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"32cff5cc5d89ffa85b12c207a1c0c6f3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/java-sdk/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/java-sdk/","summary":"1. Create a Maven project and import the dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. Create the SOFARegistry client instance The key code for creating the SOFARegistry client instance is as follows:\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); Properties related to SOFARegistry are specified by the DefaultRegistryClientConfigBuilder class, which provides the following key properties:\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } Property Type Description instanceId String The ID of the instance.","tags":null,"title":"Java SDK","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/java-sdk/","wordcount":890},{"author":null,"categories":null,"content":" 1. Maven 坐标 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. 创建 SOFARegistry 客户端实例 构建 SOFARegistry 客户端实例的关键代码如下：\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); 其中注册中心相关的属性通过 DefaultRegistryClientConfigBuilder 构建指定，该类包含以下关键属性：\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } 属性名 属性类型 描述 instanceId String 实例ID，发布订阅时需要使用相同值，数据唯一标识由dataId+group+instanceId组成，默认值 DEFAULT_INSTANCE_ID。 zone String 单元化所属 zone，默认值 DEFAULT_ZONE。 registryEndpoint String 服务端任一 Session 节点地址。 registryEndpointPort int Session 节点配置的 session.server.httpServerPort 端口值，默认值 9603。 dataCenter String 数据中心，默认值 DefaultDataCenter。 appName String 应用名。 connectTimeout int 与服务端建立连接超时时间，默认值 3000ms。 socketTimeout int 访问服务端 REST 接口超时时间，默认值 3000ms。 invokeTimeout int 调用服务端服务超时时间，默认值 1000ms。 recheckInterval int 检测任务队列间隔时间，默认值 500ms。 observerThreadCoreSize int 处理服务端推送数据线程池核心线程大小，默认值 5。 observerThreadMaxSize int 处理服务端推送数据线程池最大线程大小，默认值 10。 observerThreadQueueLength int 处理服务端推送数据线程池队列大小，默认值 1000。 syncConfigRetryInterval int 同步服务端列表间隔时间，默认值 30000ms。 3. 发布数据 发布数据的关键代码如下：\n// 构造发布者注册表 PublisherRegistration registration = new PublisherRegistration(\u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); // 将注册表注册进客户端并发布数据 Publisher publisher = registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); // 如需覆盖上次发布的数据可以使用发布者模型重新发布数据 publisher.republish(\u0026amp;quot;10.10.1.1:12200?xx=zz\u0026amp;quot;); 发布数据的关键是构造 PublisherRegistration，该类包含三个属性：\n 属性名 属性类型 描述 dataId String 数据ID，发布订阅时需要使用相同值，数据唯一标识由 dataId + group + instanceId 组成。 group String 数据分组，发布订阅时需要使用相同值，数据唯一标识由 dataId + group + instanceId 组成，默认值 DEFAULT_GROUP。 appName String 应用 appName。 4. 订阅数据 订阅数据的关键代码如下：\n// 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { @Override public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, …","date":-62135596800,"description":"","dir":"projects/sofa-registry/java-sdk/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"32cff5cc5d89ffa85b12c207a1c0c6f3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/java-sdk/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/java-sdk/","summary":"1. Maven 坐标 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. 创建 SOFARegistry 客户端实例 构建 SOFARegistry 客户端实例的关键代码如下： RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); 其中注册中心相关的属性通过 DefaultRegistryClientConfigBuilder 构建指定，该类包含以下关","tags":null,"title":"Java SDK","type":"projects","url":"/sofastack.tech/projects/sofa-registry/java-sdk/","wordcount":1368},{"author":null,"categories":null,"content":"In addition to hundreds of unit tests and some chaos tests, SOFAJRaft also uses a distributed verification and fault injection testing framework Jepsen to simulate many cases, and has passed all these tests:\n Randomized partitioning with two partitions: a big one and a small one Randomly adding and removing nodes Randomly stopping and starting nodes Randomly kill -9 and starting nodes Randomly dividing a cluster into two groups, with one node connection the two to simulate network partitioning Randomly dividing a cluster into different majority groups sofa-jraft-jepsen project address\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jepson-test/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c60bc5083fdf888f6eef5b344b1ad157","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jepson-test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jepson-test/","summary":"In addition to hundreds of unit tests and some chaos tests, SOFAJRaft also uses a distributed verification and fault injection testing framework Jepsen to simulate many cases, and has passed all these tests:\n Randomized partitioning with two partitions: a big one and a small one Randomly adding and removing nodes Randomly stopping and starting nodes Randomly kill -9 and starting nodes Randomly dividing a cluster into two groups, with one node connection the two to simulate network partitioning Randomly dividing a cluster into different majority groups sofa-jraft-jepsen project address","tags":null,"title":"Jepsen tests","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jepson-test/","wordcount":89},{"author":null,"categories":null,"content":"除了几百个单元测试以及部分 chaos 测试之外, SOFAJRaft 还使用 jepsen 这个分布式验证和故障注入测试框架模拟了很多种情况，都已验证通过：\n 随机分区，一大一小两个网络分区 随机增加和移除节点 随机停止和启动节点 随机 kill -9 和启动节点 随机划分为两组，互通一个中间节点，模拟分区情况 随机划分为不同的 majority 分组 sofa-jraft-jepsen 项目地址\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jepson-test/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c60bc5083fdf888f6eef5b344b1ad157","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jepson-test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jepson-test/","summary":"除了几百个单元测试以及部分 chaos 测试之外, SOFAJRaft 还使用 jepsen 这个分布式验证和故障注入测试框架模拟了很多种情况，都已验证通过： 随机分区，一大一小两个网络分","tags":null,"title":"Jepsen 验证","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jepson-test/","wordcount":137},{"author":null,"categories":null,"content":"In the Interactive Instructions section, we have described the set of instructions that Jarslink2.0 supports. In this section, we will focus on all the possible state transitions behind these instructions in the following diagram of a Biz package being loaded from a static file to the runtime and to being uninstalled.\nThe diagram above basically shows the complete life cycle of a Biz package. Now we will explain the direction of each state transition in the diagram:\n Label 1: Execute the install instruction, and Jarslink2.0 will resolve the file format. If the format is correct, it is the Biz package file, and the Biz package will be registered and installed.\n Label 2: When the Biz package is successfully installed, the Biz package\u0026amp;rsquo;s main function is executed, the Spring context is loaded successfully, and passes the health check. If Biz packages with the same name but different versions are detected to be activated, the Biz package state will be set to an inactive state. The JVM services that are published by an inactive Biz package will not be called.\n Label 3: When the Biz package is successfully installed, the Biz package\u0026amp;rsquo;s main function is executed, the Spring context is loaded successfully, and passes the health check. If Biz packages with the same name but different versions are detected to be activated, the Biz package state will be set as active and can provide services.\n Label 4: If there are any exceptions or a health check failure, the Biz package state will be set to broken. During the installation, the resources that the Biz package occupies will be quickly released and unregistered, at which point the Biz state will be set to unresolved.\n Label 5: When running, Jarslink2.0 can load Biz packages with the same name but different versions, but only one Biz package is in the active state and can provide services. Execute the switch instruction, and the two Biz packages\u0026amp;rsquo; states will be interchanged.\n Label 6: Execute the uninstallation instruction, the Biz package will be uninstalled, and its occupied resources and published services will be unregistered.\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0f166dd5388f3dc7d968bce31d0f6e4f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","summary":"In the Interactive Instructions section, we have described the set of instructions that Jarslink2.0 supports. In this section, we will focus on all the possible state transitions behind these instructions in the following diagram of a Biz package being loaded from a static file to the runtime and to being uninstalled.\nThe diagram above basically shows the complete life cycle of a Biz package. Now we will explain the direction of each state transition in the diagram:","tags":null,"title":"Lifecycle","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","wordcount":346},{"author":null,"categories":null,"content":" The link data transparent transmission function allows the applications to store data in the calling context, and then any applications in the entire link can operate the data. This feature is used as follows. Data can be put into the request and response of the link for transparent transmission, and then the applications can get the corresponding data from the link.\nRpcInvokeContext.getContext().putRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;,\u0026amp;quot;value_request\u0026amp;quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;,\u0026amp;quot;value_response\u0026amp;quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;); Example For example, in the scenario of A -\u0026amp;gt; B -\u0026amp;gt; C, the request arguments set by A are transmitted to B and C. On return, response arguments of C and B are transmitted to A.\nRequester A is set as follows:\n// Set the value of the request transparently before calling RpcInvokeContext context = RpcInvokeContext.getContext(); context.putRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;, \u0026amp;quot;a2bbb\u0026amp;quot;); // Call service String result = service.hello(); // Get the result value context.getResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;); Business code for B is as follows:\npublic String hello() { / / Get the value of the request transparent transmission RpcInvokeContext context = RpcInvokeContext.getContext(); String reqBaggage = context.getRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;); // doSomthing(); // result passes a value transparently context.putResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;, \u0026amp;quot;b2aaa\u0026amp;quot;); return result; } If you start the child thread halfway, you need to set the context of the child thread:\nCountDownLatch latch = new CountDownLatch(1); final RpcInvokeContext parentContext = RpcInvokeContext.peekContext(); Thread thread = new Thread(new Runnable(){ public void run(){ Try { RpcInvokeContext.setContext(parentContext); / / Call a remote service xxxService.sayHello(); latch.countDown(); } finally { RpcInvokeContext.removeContext(); } } }, \u0026amp;quot;new-thread\u0026amp;quot;); thread.start(); // If failed to get the transparently transmitted data of the return value. latch.await(); //wait // Return ends, and you can get the value returned by transparent transmission. Compare with SOFATracer SOFATracer is an open-source distributed link tracing system of Ant Finanicial. RPC has been integrated with Tracer and is enabled by default.\nThe differences between data transparent transmission and data transfer by Tracer are as follows:\n RPC data transparent transmission is business-oriented. And it can implement two-way data transmission in the full link. The caller can transmit data to the service provider, and the service provider can also transmit data to the caller. SOFATracer is middleware-oriented and is more suitable for the data transfer without service itself perceving. It can only implement one-way data …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-chain-pass-data/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"96cfb41f07a6a2ad979b53093ff5eee9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","summary":"The link data transparent transmission function allows the applications to store data in the calling context, and then any applications in the entire link can operate the data. This feature is used as follows. Data can be put into the request and response of the link for transparent transmission, and then the applications can get the corresponding data from the link.\nRpcInvokeContext.getContext().putRequestBaggage(\u0026quot;key_request\u0026quot;,\u0026quot;value_request\u0026quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026quot;key_response\u0026quot;,\u0026quot;value_response\u0026quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026quot;key_request\u0026quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026quot;key_response\u0026quot;); Example For example, in the scenario of A -\u0026gt; B -\u0026gt; C, the request arguments set by A are transmitted to B and C.","tags":null,"title":"Link data transparent transmission","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","wordcount":427},{"author":null,"categories":null,"content":" 本文描述的是 MOSN listener 配置。\n Listener 配置详细描述了 MOSN 启动时监听的端口，以及对应的端口对应不同逻辑的配置。 Listener 的配置可以通过Listener动态接口进行添加和修改。 { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;address\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;bind_port\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;use_original_dst\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;access_logs\u0026amp;quot;:[], \u0026amp;quot;filter_chains\u0026amp;quot;:[], \u0026amp;quot;stream_filters\u0026amp;quot;:[], \u0026amp;quot;inspector\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;connection_idle_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } name 用于唯一区分 Listener，如果配置为空，会默认生成一个 UUID 作为 name。在对 Listener 进行动态更新时，使用 name 作为索引，如果 name 不存在，则是新增一个 listener，如果 name 存在则是对 listener 进行更新。\ntype 标记 Listener 的类型，目前支持 ingress 和 egress 两种类型。不同 type 的 Listener 输出的 tracelog 不同。\naddress IP:Port 形式的字符串，Listener 监听的地址，唯一。\nbind_port bool 类型，表示 Listener 是否会占用 address 配置的地址，通常情况下都需要配置为true。\nuse_original_dst bool 类型，用于透明代理。\naccess_logs 一组 access_log 配置。\nfilter_chains 一组 FilterChain 配置，但是目前 MOSN 仅支持一个 filter_chain。\nstream_filters 一组 stream_filter 配置，目前只在 filter_chain 中配置了 filter 包含 proxy 时生效。\ninspector bool 类型，当此值为 true 时，表示即便 listener 在 filter_chain 中配置开启了 TLS 监听，listener 依然可以处理非 TLS 的请求。\nconnection_idle_timeout Duration String，空闲连接超时配置。当 listener 上建立的连接空闲超过配置的超时时间以后，MOSN 会将此连接关闭。\n","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"028e9053b21853890114c38d55d15390","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/overview/","summary":"本文描述的是 MOSN listener 配置。 Listener 配置详细描述了 MOSN 启动时监听的端口，以及对应的端口对应不同逻辑的配置。 Listener 的配置可以通过Listener动态接口进行添加","tags":null,"title":"Listener 配置","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/overview/","wordcount":447},{"author":null,"categories":null,"content":" SOFARPC provides a variety of load balancing algorithms and currently supports the following five types:\n Type Name Description random Random algorithm The default load balancing algorithm. localPref Local preference algorithm Firstly detect whether the service is published locally, if not, random algorithm is used. roundRobin Round Robin algorithm Method-level polling, the polling is carried out separately to each method, without affecting each other. consistentHash Consistent hash algorithm The same method-level request is routed to the same node. weightRoundRobin Weighted Round Robin algorithm Poll nodes by weight. Not recommended due to poor performance. To use a specific load balancing algorithm, you can configure as follows:\nIn XML If you reference the service using XML, you can configure it by setting the loadBalancer property of the sofa:global-attrs tag:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs loadBalancer=\u0026amp;quot;roundRobin\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; In Annotation It is currently not supported to configure a load balancing algorithm for a reference in Annotation. The function will be provided in subsequent releases.\nIn API under Spring environment If you use the API in a Spring or Spring Boot environment, you can configure it by calling the setLoadBalancer method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setLoadBalancer(\u0026amp;quot;roundRobin\u0026amp;quot;); In API under non-Spring environment If you directly use the bare API provided by SOFARPC in a non-Spring environment, you can configure it by calling the setLoadBalancer method of ConsumerConfig:\nConsumerConfig consumerConfig = new ConsumerConfig(); consumerConfig.setLoadbalancer(\u0026amp;quot;random\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/load-balance/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"739984ca9a414429304f85010fd73ad0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/load-balance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/load-balance/","summary":"SOFARPC provides a variety of load balancing algorithms and currently supports the following five types:\n Type Name Description random Random algorithm The default load balancing algorithm. localPref Local preference algorithm Firstly detect whether the service is published locally, if not, random algorithm is used. roundRobin Round Robin algorithm Method-level polling, the polling is carried out separately to each method, without affecting each other.","tags":null,"title":"Load balance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/load-balance/","wordcount":230},{"author":null,"categories":null,"content":"To use local file as service registry center, you can configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg The /home/admin/registry/localRegistry.reg is the directory of the local files to be used.\nOn windows OS, the above path indicates the following directory:\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-local/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"33bc89393392e21b3917f090313c0df5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-local/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-local/","summary":"To use local file as service registry center, you can configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg The /home/admin/registry/localRegistry.reg is the directory of the local files to be used.\nOn windows OS, the above path indicates the following directory:\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","tags":null,"title":"Local","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-local/","wordcount":40},{"author":null,"categories":null,"content":" Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately. For single-core forwarding, in the case of specifying P=1, MOSN binds CPU with cores to improve the call execution efficiency of the system and the locality affinity of cache. For memory, in the case of binding single core, MOSN uses SLAB-style recycling mechanism to improve reuse and reduce memory copy. For IO, MOSN mainly implements optimization by controlling the read/write buffer size, read/write timing, read/write frequency and other parameters. The performance test data is as follows:\nTCP proxy performance data For the same deployment mode, this report compares MOSN 0.1.0 and envoy for the upper-layer protocol Bolt (SOFARPC related protocol) and HTTP1.1 respectively.\nDeployment mode The pressure test is deployed in a pure proxy mode. The client process accesses the server process through the MOSN process and serves as a forwarding proxy. The client process, MOSN process, and server process run on the machines which belong to different network segments. The network delay of the direct access from the client to server is about 2.5ms.\nClient Bolt protocol (send 1K string) The client that sends the Bolt protocol data uses the online pressure generators developed by Ant Financial and deploys the SOFARPC client.\nOn the pressure generator performance page, you can see the QPS, success/failure counts, RT and other parameters.\nHTTP1.1 protocol (send 1K string) Use ApacheBench/2.3. The test instructions are:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Mesh machine specifications The mesh runs in a container where the CPU is an exclusive logical core. The specifications are as follows:\n Category Information OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream machine specifications Category Information OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt protocol test result Performance data Indicators MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% Conclusion For single-core TCP forwarding, there is little difference between MOSN 0.1.0 and Envoy 1.7 in terms of performance in the condition with full load, such as QPS, RTT and success/failure counts. We will continue to optimize in the subsequent versions.\nHTTP/1.1 test result Since the HTTP/1.1 request response model is …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report010/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3cb22950b4be5a25b90f8aa1376786e9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/mosn/reference-performance-report010/","summary":"Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately.","tags":null,"title":"MOSN 0.1.0 performance report","type":"projects","url":"/sofastack.tech/en/projects/mosn/reference-performance-report010/","wordcount":730},{"author":null,"categories":null,"content":" Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately. For single-core forwarding, in the case of specifying P=1, MOSN binds CPU with cores to improve the call execution efficiency of the system and the locality affinity of cache. For memory, in the case of binding single core, MOSN uses SLAB-style recycling mechanism to improve reuse and reduce memory copy. For IO, MOSN mainly implements optimization by controlling the read/write buffer size, read/write timing, read/write frequency and other parameters. The performance test data is as follows:\nTCP proxy performance data For the same deployment mode, this report compares MOSN 0.1.0 and envoy for the upper-layer protocol Bolt (SOFARPC related protocol) and HTTP1.1 respectively.\nDeployment mode The pressure test is deployed in a pure proxy mode. The client process accesses the server process through the MOSN process and serves as a forwarding proxy. The client process, MOSN process, and server process run on the machines which belong to different network segments. The network delay of the direct access from the client to server is about 2.5ms.\nClient Bolt protocol (send 1K string) The client that sends the Bolt protocol data uses the online pressure generators developed by Ant Financial and deploys the SOFARPC client.\nOn the pressure generator performance page, you can see the QPS, success/failure counts, RT and other parameters.\nHTTP1.1 protocol (send 1K string) Use ApacheBench/2.3. The test instructions are:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Mesh machine specifications The mesh runs in a container where the CPU is an exclusive logical core. The specifications are as follows:\n Category Information OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream machine specifications Category Information OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt protocol test result Performance data Indicators MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% Conclusion For single-core TCP forwarding, there is little difference between MOSN 0.1.0 and Envoy 1.7 in terms of performance in the condition with full load, such as QPS, RTT and success/failure counts. We will continue to optimize in the subsequent versions.\nHTTP/1.1 test result Since the HTTP/1.1 request response model is …","date":-62135596800,"description":"","dir":"projects/occlum/reference-performance-report010/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"035dfbc7e310acf31561343432aea680","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/occlum/reference-performance-report010/","summary":"Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately.","tags":null,"title":"MOSN 0.1.0 performance report","type":"projects","url":"/sofastack.tech/en/projects/occlum/reference-performance-report010/","wordcount":730},{"author":null,"categories":null,"content":" 以下的的性能报告为 MOSN 0.1.0 在做 Bolt 与 HTTP1.x 协议的纯 TCP 转发上与 envoy 的一些性能对比数据，主要表现在 QPS、RTT、失败率/成功率等。\n这里需要强调的是，为了提高 MOSN 的转发性能，在 0.1.0 版本中，我们做了如下的一些优化手段：\n 在线程模型优化上，使用 worker 协程池处理 stream 事件，使用两个独立的协程分别处理读写 IO 在单核转发优化上，在指定 P=1 的情况下，我们通过使用 CPU 绑核的形式来提高系统调用的执行效率以及 cache 的 locality affinity 在内存优化上，同样是在单核绑核的情况下，我们通过使用 SLAB-style 的回收机制来提高复用，减少内存 copy 在 IO 优化上，主要是通过读写 buffer 大小以及读写时机和频率等参数的控制上进行调优 以下为具体的性能测试数据。\nTCP 代理性能数据 这里，针对相同的部署模式，我们分别针对上层协议为 \u0026amp;quot;Bolt(SofaRpc相关协议)\u0026amp;quot; 与 \u0026amp;quot;HTTP1.1\u0026amp;quot; 来进行对比。\n部署模式 压测采用纯代理模式部署，client 进程通过 MOSN 进程作为转发代理访问server进程。其中，client 进程，MOSN 进程，server 进程分别运行在属于不同网段的机器中。client 直连访问 server 网络延时为 2.5ms 左右。\n客户端 Bolt 协议（发送 1K 字符串） 发送 Bolt 协议数据的客户端使用 \u0026amp;ldquo;蚂蚁金服\u0026amp;rdquo;内部开发的线上压力机，并部署 sofa rpc client。 通过压力机的性能页面，可反映压测过程中的QPS、成功/失败次数，以及RT等参数。\nHTTP1.1 协议（发送 1K 字符串） 使用 ApacheBench/2.3, 测试指令:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Service mesh 运行机器规格 Service mesh 运行在容器中，其中 CPU 为独占的一个逻辑核，具体规格如下：\n 类别 信息 OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream 运行机器规格 类别 信息 OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt 协议测试结果 性能数据 指标 MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% 结论 可以看到，在单核 TCP 转发场景下，MOSN 0.1.0 版本和 Envoy 1.7版本，在满负载情况下的 QPS、RTT、成功数/失败数等性能数据上相差不大，后续版本我们会继续优化。\nHTTP/1.1 测试结果 由于 HTTP/1.1 的请求响应模型为 PING-PONG，因此 QPS 与并发数会呈现正相关。下面分别进行不同并发数的测试。\n并发20 指标 MOSN Envoy QPS 5600 5600 RT(mean) 3.549ms 3.545ms RT(P99) 4ms 4ms RT(P98) 4ms 4ms RT(P95) 4ms 4ms MEM 24m 23m CPU 40% 20% 并发40 指标 MOSN Envoy QPS 11150 11200 RT(mean) 3.583ms 3.565ms RT(P99) 4ms 4ms RT(P98) 4ms 4ms RT(P95) 4ms 4ms MEM 34m 24m CPU 70% 40% 并发200 指标 MOSN Envoy QPS 29670 38800 RT(mean) 5.715ms 5.068ms RT(P99) 16ms 7ms RT(P98) 13ms 7ms RT(P95) 11ms 6ms MEM 96m 24m CPU 100% 95% 并发220 指标 MOSN Envoy QPS 30367 41070 RT(mean) 8.201ms 5.369ms RT(P99) 20ms 9ms RT(P98) 19ms 8ms RT(P95) 16ms 8ms MEM 100m 24m CPU 100% 100% 结论 可以看到，在上层协议为 HTTP/1.X 时，MOSN 的性能和 Envoy 的性能存在一定差距，对于这种现象我们的初步结论为：在 PING-PONG 的发包模型下，MOSN 无法进行 read/write 系统调用合并，相比 SOFARPC 可以合并的场景，syscall 数量大幅上升，因此导致相比 SOFARPC 的场景，HTTP 性能上相比 Envoy 会存在差距。针对这个问题，在 0.2.0 版本中，我们会进行相应的优化。\n附录 Envoy 版本信息 version：1.7 tag：1ef23d481a4701ad4a414d1ef98036bd2ed322e7 Envoy TCP 测试配置 static_resources: listeners: - address: socket_address: address: 0.0.0.0 port_value: 12200 filter_chains: - filters: - name: envoy.tcp_proxy config: stat_prefix: ingress_tcp cluster: sofa_server clusters: - name: sofa_server connect_timeout: 0.25s type: static lb_policy: round_robin hosts: - socket_address: address: 10.210.168.5 port_value: 12222 - socket_address: address: 10.210.168.5 port_value: 12223 - socket_address: address: 10.210.168.5 port_value: 12224 - socket_address: address: 10.210.168.5 port_value: 12225 admin: access_log_path: …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report010/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3cb22950b4be5a25b90f8aa1376786e9","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/reference-performance-report010/","summary":"以下的的性能报告为 MOSN 0.1.0 在做 Bolt 与 HTTP1.x 协议的纯 TCP 转发上与 envoy 的一些性能对比数据，主要表现在 QPS、RTT、失败率/成功率等。 这里需要强调的是，为了提","tags":null,"title":"MOSN 0.1.0 性能报告","type":"projects","url":"/sofastack.tech/projects/mosn/reference-performance-report010/","wordcount":1229},{"author":null,"categories":null,"content":" 以下性能报告的基准版本为 MOSN 0.2.1。在 0.2.1 版本中，我们进行了如下一些优化手段： - 添加内存复用框架，涵盖 io/protocol/stream/proxy 层级，减少对象分配、内存使用和 GC 压力。 - 针对大量链接场景，新增 Raw Epoll 模式，该模式使用了事件回调机制 + IO 协程池，规避了海量协程带来的堆栈内存消耗以及调度开销。\n需要注意的是，由于目前 SOFARPC 和 H2 的压测工具还没有 pxx 指标的展示，我们在性能报告中选取的数据都为均值。后续需要我们自行进行相关压测环境工具的建设来完善相关指标（P99，P95……）\n总览 本次性能报告在0.1.0 性能报告的基础上，新增了若干场景的覆盖，总体包含以下几部分： - 单核性能（sidecar场景） - 7层代理 - Bolt（串联） - Http/1.1（串联） - Http/2（串联） - 多核性能（gateway场景） - 7层代理 - Bolt（直连） - Http/1.1（直连） - Http/2（直连） - 长连接网关 - Bolt（read/write loop with goroutine/raw epoll）\n单核性能（sidecar 场景） 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2430 0 @ 2.20GHz bolt client client 为压力平台，有 5 台压力机，共计与client MOSN 之间会建立 500 条链接 http1 client（10.210.168.5） ApacheBench/2.3 -n 2000000 -c 500 -k http2 client（10.210.168.5） nghttp.h2load -n1000000 -c5 -m100 -t4 部署结构 压测模式 部署结构 串联 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 请求内容 1K req/resp 7层代理 场景 QPS RT(ms) MEM(K) CPU(%) Bolt 16000 15.8 77184 98 Http/1.1 4610 67 47336 90 Http/2 5219 81 31244 74 多核性能（gateway 场景） 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2430 0 @ 2.20GHz bolt client client为压力平台，有5台压力机，共计与client MOSN之间会建立500条链接 http1 client（10.210.168.5） ApacheBench/2.3 -n 2000000 -c 500 -k http2 client（10.210.168.5） nghttp.h2load -n1000000 -c5 -m100 -t4 部署结构 压测模式 部署结构 直连 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 请求内容 1K req/resp 7层代理 场景 QPS RT(ms) MEM(K) CPU(%) Bolt 45000 23.4 544732 380 Http/1.1 21584 23 42768 380 Http/2 8180 51.7 173180 300 长连接网关 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2430 0 @ 2.20GHz 部署结构 压测模式 部署结构 直连 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 链接数 请求内容 2 台压力机，每台 5w 链接 + 500 QPS，共计10W链接 + 1000 QPS 1K req/resp 长连接网关 场景 QPS MEM(g) CPU(%) goroutine RWLoop + goroutine 1000 3.3 60 200028 Raw epoll 1000 2.5 18 28 总结 MOSN 0.2.1引入了内存复用框架，相比0.1.0，在 bolt 协议转发场景性能表现得到了大幅优化。在提升了20% 的 QPS 的同时，还优化了 30% 的内存占用。\n与此同时，我们对 HTTP/1.1 及 HTTP/2 的场景也进行 …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report021/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7b04a2e6cf1c4f9e732dc1dfdab74c57","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/reference-performance-report021/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/reference-performance-report021/","summary":"以下性能报告的基准版本为 MOSN 0.2.1。在 0.2.1 版本中，我们进行了如下一些优化手段： - 添加内存复用框架，涵盖 io/protocol/stream/proxy 层级，减少对象分配、内存使用和 GC 压力","tags":null,"title":"MOSN 0.2.1 性能报告","type":"projects","url":"/sofastack.tech/projects/mosn/reference-performance-report021/","wordcount":1616},{"author":null,"categories":null,"content":" MOSN 的官方网站 mosn.io 正在建设中，文档临时托管在这里。\nMOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称。MOSN 可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡，API Gateway，云原生 Ingress 等使用。\n快速开始 请参考快速开始。\n核心能力 Istio集成 集成 Istio 1.0 版本与 V4 API，可基于全动态资源配置运行 核心转发 自包含的网络服务器 支持 TCP 代理 支持 TProxy 模式 多协议 支持 HTTP/1.1，HTTP/2 支持 SOFARPC 支持 Dubbo 协议（开发中） 核心路由 支持 Virtual Host 路由 支持 Headers/URL/Prefix 路由 支持基于 Host Metadata 的 Subset 路由 支持重试 后端管理\u0026amp;amp;负载均衡 支持连接池 支持熔断 支持后端主动健康检查 支持 Random/RR 等负载策略 支持基于 Host Metadata 的 Subset 负载策略 可观察性 观察网络数据 观察协议数据 TLS 支持 HTTP/1.1 on TLS 支持 HTTP/2.0 on TLS 支持 SOFARPC on TLS 进程管理 支持平滑 reload 支持平滑升级 扩展能力 支持自定义私有协议 支持在 TCP IO 层，协议层面加入自定义扩展 社区 MOSN 仍处在初级阶段，有很多能力需要补全，所以我们欢迎所有人参与进来与我们一起共建。\n如有任何疑问欢迎提交 Issue。\n","date":-62135596800,"description":"","dir":"projects/mosn/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f25c59cbb758b4dae5de39e1f1c3a2f4","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/overview/","summary":"MOSN 的官方网站 mosn.io 正在建设中，文档临时托管在这里。 MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，","tags":null,"title":"MOSN 介绍","type":"projects","url":"/sofastack.tech/projects/mosn/overview/","wordcount":470},{"author":null,"categories":null,"content":" Service Mesh 中 Sidecar 运维一直是一个比较棘手的问题，数据平面的 Sidecar 升级是常有的事情，如何在升级 Sidecar（MOSN）的时候而不影响业务，对于存量的长连接如何迁移，本文将为你介绍 MOSN 的解决之道。\n背景 本文介绍 MOSN 支持平滑升级的原因和解决方案，对于平滑升级的一些基础概念，大家可以通过 Nginx vs Enovy vs Mosn 平滑升级原理解析了解。\n先简单介绍一下为什么 Nginx 和 Envoy 不需要具备 MOSN 这样的连接无损迁移方案，主要还是跟业务场景相关，Nginx 和 Envoy 主要支持的是 HTTP1 和 HTTP2 协议，HTTP1使用 connection: Close，HTTP2 使用 Goaway Frame 都可以让 Client 端主动断链接，然后新建链接到新的 New process，但是针对 Dubbo、SOFA PRC 等常见的多路复用协议，它们是没有控制帧，Old process 的链接如果断了就会影响请求的。\n一般的升级做法就是切走应用的流量，比如自己UnPub掉服务，等待一段时间没有请求之后，升级MOSN，升级好之后再Pub服务，整个过程比较耗时，并且会有一段时间是不提供服务的，还要考虑应用的水位，在大规模场景下，就很难兼顾评估。MOSN 为了满足自身业务场景，开发了长连接迁移方案，把这条链接迁移到 New process 上，整个过程对 Client 透明，不需要重新建链接，达到请求无损的平滑升级。\n正常流程 Client 发送请求 Request 到 MOSN MOSN 转发请求 Request 到 Server Server 回复响应 Response 到 MOSN MOSN 回复响应 Response 到 Client 上图简单介绍了一个请求的正常流程，我们后面需要迁移的是 TCP1 链接，也就是 Client 到 MOSN 的连接，MOSN 到 Server 的链接 TCP2 不需要迁移，因为 MOSN 访问 Server 是根据 LoadBalance 选择，我们可以主动控制断链建链。\n平滑升级流程 触发条件 有两个方式可以触发平滑升级流程：\n MOSN 对 SIGHUP 做了监听，发送 SIGHUP 信号给 MOSN 进程，通过 ForkExec 生成一个新的 MOSN 进程。 直接重新启动一个新 MOSN 进程。 为什么提供两种方式？最开始我们支持的是方法1，也就是 nginx 和 Envoy 使用的方式，这个在虚拟机或者容器内替换 MOSN 二级制来升级是可行的，但是我们的场景需要满足容器间的升级，所以需要新拉起一个容器，就需要重新启动一个新的 MOSN 进程来做平滑升级，所以后续又支持了方法2。容器间升级还需要 operator 的支持，本文不展开叙述。\n交互流程 首先，老的 MOSN 在启动最后阶段会启动一个协程运行 ReconfigureHandler() 函数监听一个 Domain Socket（reconfig.sock）, 该接口的作用是让新的 MOSN 来感知是否存在老的 MOSN。\nfunc ReconfigureHandler() { l, err := net.Listen(\u0026amp;quot;unix\u0026amp;quot;, types.ReconfigureDomainSocket) for { uc, err := ul.AcceptUnix() _, err = uc.Write([]byte{0}) reconfigure(false) } } 触发平滑升级流程的两种方式最终都是启动一个新的 MOSN 进程，然后调用GetInheritListeners()，通过 isReconfigure() 函数来判断本机是否存在一个老的 MOSN（就是判断是否存在 reconfig.sock 监听），如果存在一个老的 MOSN，就进入迁移流程，反之就是正常的启动流程。\n// 保留了核心流程 func GetInheritListeners() ([]net.Listener, net.Conn, error) { if !isReconfigure() { return nil, nil, nil } l, err := net.Listen(\u0026amp;quot;unix\u0026amp;quot;, types.TransferListenDomainSocket) uc, err := ul.AcceptUnix() _, oobn, _, _, err := uc.ReadMsgUnix(buf, oob) file := os.NewFile(fd, \u0026amp;quot;\u0026amp;quot;) fileListener, err := net.FileListener(file) return listeners, uc, nil } 如果进入迁移流程，新的 MOSN 将监听一个新的 Domain Socket（listen.sock），用于老的 MOSN 传递 listen FD 到新的 MOSN。FD 的传递使用了sendMsg 和 recvMsg。在收到 listen FD 之后，调用 net.FileListener() 函数生产一个 Listener。此时，新老 MOSN 都同时拥有了相同的 Listen 套接字。\n// FileListener returns a copy of the network listener corresponding // to the open file f. // It is the caller\u0026#39;s responsibility to close ln when finished. // Closing ln does not affect f, and closing f does not affect ln. func FileListener(f *os.File) (ln Listener, err error) { ln, err = fileListener(f) if err != nil { err = \u0026amp;amp;OpError{Op: \u0026amp;quot;file\u0026amp;quot;, Net: \u0026amp;quot;file+net\u0026amp;quot;, Source: nil, Addr: fileAddr(f.Name()), Err: err} } return } 这里的迁移和 Nginx 还是有一些区别，Nginx 是 fork 的方式，子进程自动就继承了 listen FD，MOSN 是新启动的进程，不存在父子关系，所以需要通过 sendMsg 的方式来传递。\n在进入迁移流程和 Listen 的迁移过程中，一共使用了两个 Domain Socket：\n reconfig.sock 是 Old MOSN 监听，用于 New MOSN 来判断是否存在 listen.sock 是 New MOSN 监听，用于 Old MOSN 传递 listen FD 两个 sock 其实是可以复用的，也可以用 reconfig.sock …","date":-62135596800,"description":"","dir":"projects/mosn/concept/smooth-upgrade/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2c09c045287c33c760368abe02bb8986","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/smooth-upgrade/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/mosn/concept/smooth-upgrade/","summary":"Service Mesh 中 Sidecar 运维一直是一个比较棘手的问题，数据平面的 Sidecar 升级是常有的事情，如何在升级 Sidecar（MOSN）的时候而不影响业务，对于存量的长连接","tags":null,"title":"MOSN 平滑升级原理解析","type":"projects","url":"/sofastack.tech/projects/mosn/concept/smooth-upgrade/","wordcount":3957},{"author":null,"categories":null,"content":" 1. registry-meta 1.1 Push switch When publishing new SOFARegistry versions, to minimize the impact on services, and avoid large amounts of push messages caused by large-scale service endpoint changes during the server restart process, we will temporarily turn off the push service at the management layer. After publishing the new SOFARegistry version, we can turn on the push service and restore the normal working conditions. Data subscription and service publication information generated for the period when the push service is turned off will be subject to global push for compensation.\nTurn on the push service:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/close\u0026amp;quot; Turn off the push service:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/open\u0026amp;quot; 1.2 Query the endpoint list View the endpoint list of the meta cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/META/node/query\u0026amp;quot; View the endpoint list of the data cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/DATA/node/query\u0026amp;quot; View the endpoint list of the session cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/SESSION/node/query\u0026amp;quot; 1.3 Scale up/down the meta cluster 1.3.1 Modify the cluster: changePeer You can call this operation to modify the Raft cluster list when you have scaled up/down the cluster. This allows you to correctly add nodes to or remove nodes from the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;ip1\u0026amp;gt;,\u0026amp;lt;ip2\u0026amp;gt;,\u0026amp;lt;ip3\u0026amp;gt;\u0026amp;quot; 1.3.2 Reset the cluster: resetPeer When a cluster is unavailable, for example, two of three servers are not functional, the cluster can not carry out leader election. Here, you can call this operation to reset the cluster list. For example, you can reset the cluster to a one-server cluster (with the only functional server) to resume election and restore service.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/manage/resetPeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;ip1\u0026amp;gt;,\u0026amp;lt;ip2\u0026amp;gt;,\u0026amp;lt;ip3\u0026amp;gt;\u0026amp;quot; 2. registry-data 2.1 Query data View the pub count:\ncurl \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/datum/count\u0026amp;quot; You can call this operation to view data published by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;\u0026amp;quot;:\u0026amp;quot;\u0026amp;lt;client port\u0026amp;gt;\u0026amp;quot;}\u0026#39; 3. registry-session 3.1 Query data You can call this operation to view data published by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/pub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client port\u0026amp;gt;\u0026amp;quot;]\u0026#39; You can call this operation to view data subscribed to by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/sub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: …","date":-62135596800,"description":"","dir":"projects/sofa-registry/management-api/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2cf59ac422c84c279d73c1f7f1cd0902","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/management-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/management-api/","summary":"1. registry-meta 1.1 Push switch When publishing new SOFARegistry versions, to minimize the impact on services, and avoid large amounts of push messages caused by large-scale service endpoint changes during the server restart process, we will temporarily turn off the push service at the management layer. After publishing the new SOFARegistry version, we can turn on the push service and restore the normal working conditions. Data subscription and service publication information generated for the period when the push service is turned off will be subject to global push for compensation.","tags":null,"title":"Management commands","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/management-api/","wordcount":406},{"author":null,"categories":null,"content":" pom dependencies \u0026amp;lt;!-- jraft --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jraft-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- jsr305 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.code.findbugs\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jsr305\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- bolt --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hessian\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- log --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.7.21\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- disruptor --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.lmax\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;disruptor\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-io\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-io\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-lang\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-lang\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protobuf --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.protobuf\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protobuf-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protostuff --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-runtime\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- rocksdb --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.rocksdb\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rocksdbjni\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.14.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- java thread affinity --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;net.openhft\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;affinity\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.1.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- metrics --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.dropwizard.metrics\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;metrics-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/maven-dependency/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"abb08cef5ebf1a10a723597a65415313","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","summary":"pom dependencies \u0026lt;!-- jraft --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jraft-core\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- jsr305 --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.code.findbugs\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jsr305\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.0.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- bolt --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;hessian\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- log --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.slf4j\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;slf4j-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.7.21\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- disruptor --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.lmax\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;disruptor\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.7\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-io\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-io\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.4\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-lang\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-lang\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protobuf --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.protobuf\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;protobuf-java\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.5.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protostuff --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.","tags":null,"title":"Maven dependencies","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","wordcount":104},{"author":null,"categories":null,"content":" pom依赖 \u0026amp;lt;!-- jraft --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jraft-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- jsr305 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.code.findbugs\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jsr305\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- bolt --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hessian\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- log --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.7.21\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- disruptor --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.lmax\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;disruptor\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-io\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-io\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-lang\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-lang\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protobuf --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.protobuf\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protobuf-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protostuff --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-runtime\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- rocksdb --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.rocksdb\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rocksdbjni\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.14.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- java thread affinity --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;net.openhft\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;affinity\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.1.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- metrics --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.dropwizard.metrics\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;metrics-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/maven-dependency/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"abb08cef5ebf1a10a723597a65415313","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/maven-dependency/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/maven-dependency/","summary":"pom依赖 \u0026lt;!-- jraft --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jraft-core\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- jsr305 --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.code.findbugs\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jsr305\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.0.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- bolt --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;hessian\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- log --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.slf4j\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;slf4j-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.7.21\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- disruptor --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.lmax\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;disruptor\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.7\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-io\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-io\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.4\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-lang\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-lang\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protobuf --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.protobuf\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;protobuf-java\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.5.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protostuff","tags":null,"title":"Maven 依赖说明","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/maven-dependency/","wordcount":107},{"author":null,"categories":null,"content":" In Jarslink 2.0, merged deployment refers to loading and running multiple Biz packages in the same JVM. In the section Application Packaging, we have described the relationship between the Spring Boot/SOFABoot application and the Biz package. We may think that merged deployment here refers to loading and running multiple Spring Boot/SOFABoot applications in the same JVM.\nIt is mentioned at the end of Application Packaging that a Biz package can be released to a remote repository through the mvn deploy command, similar to releasing common Jar packages. It comes naturally to mind that the advantage of doing so is that the Biz package generated by other applications can be introduced in the form of dependencies, just like introducing common Jar package dependencies. Then, what is the purpose of introducing the Biz package generated by other applications into your application? Also, how do we dynamically install and uninstall Biz packages in Jarslink 2.0?\nTo answer the two questions above is to understand the concepts of static merged deployment and dynamic merged deployment.\nStatic merged deployment To answer the first question: What is the purpose of introducing the Biz package generated by other applications into your application?\nIn the section Application Packaging, we have described how to package an application into an Ark package and offered a rough equation: Ark package = Biz package + SOFAArk framework + Ark Plugin. When a Biz package generated by other applications is introduced in the application, what kind of packaged Ark package will it be? The conclusion is that the packaging plugin will treat special dependency packages like the Biz package differently. The plugin will package all the non-Biz package dependencies into the application\u0026amp;rsquo;s Biz package, but will consider the introduced Biz package as equal to those of the current application. The final Ark package will contain multiple Biz packages. For details, refer to Ark Package Directory Structure. At this point, when you use java -jar to start this Ark package, you will find that all the contained Biz packages will be started as well.\nTo sum up, the application introduces the Biz packages generated by other applications in the form of dependencies, and the Ark package packaged by this application will contain multiple Biz packages. By executing this Ark package, all the Biz packages will be started, known as static merged deployment.\nStatic merged deployment does not depend on Jarslink 2.0 but is available directly with the SOFAArk packaging plugin.\nNote that the startup order of multiple Biz packages is controllable. When each Biz package is generated, you can use the packaging plugin to configure its priority, whose value is 100 by default. The higher the priority, the lower the value is. The priority determines the startup order of the Biz package.\nDynamic merged deployment To answer the second question: how do you dynamically install and uninstall Biz packages in Jarslink …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-deploy/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ce787203d9d834b7f796b3dbb40bf55d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","summary":"In Jarslink 2.0, merged deployment refers to loading and running multiple Biz packages in the same JVM. In the section Application Packaging, we have described the relationship between the Spring Boot/SOFABoot application and the Biz package. We may think that merged deployment here refers to loading and running multiple Spring Boot/SOFABoot applications in the same JVM.\nIt is mentioned at the end of Application Packaging that a Biz package can be released to a remote repository through the mvn deploy command, similar to releasing common Jar packages.","tags":null,"title":"Merged deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","wordcount":749},{"author":null,"categories":null,"content":" Quickly understand of ACTS models When you write a test case, you need to prepare some database tables, request parameter data of methods, or data for validating database tables and responses. You can save such data in models, and import it to preparation data or validation data when you edit the test case. This allows you to conveniently reuse data. Currently, ACTS models can be divided into database models and class models.\nIn conventional test case compilation, data preparation of models, such as database models, request parameter models, and response models, is based on the test code. The complexity of models increases with the business complexity, especially in financial-level business applications, where a class or data table may have dozens of properties or fields, and where class nesting is common. In this case, constructing complex objects is extremely difficult and prone to omissions. Some of the most frequently occurring problems are listed as follows:\n Omissions may occur and troubleshooting takes a lot of time for a large number of tables. Field names of tables are difficult to remember, and spelling errors frequently occur. The large number and complex types of interface request parameters are frustrating. There are so many class properties that important properties are prone to omission. Object construction with nested structures requires continuous effort in creating and setting values. Important properties are easily omitted when the inheritance and implementation relationships are complex. ACTS models can effectively address the above problems by formatting classes and tables in CSV, which makes the structure of classes easier to understand. Class models and data table models can help you quickly create objects, and serialize them into the YAML file. ACTS models allow you to conveniently manage test case data.\nStorage location of models You can view existing models under the resource/model directory of the test module.\nFigure 4\nGenerate data table model Sample data table model Figure 5\n1. Validation flag description\nY: indicates that the data is to be inserted. N: indicates that the data is not to be inserted. C: indicates that ACTS will clean the inserted data by taking this value as the where condition. F: indicates that the value of this column is a database function. L: indicates that a large field data record requires line wrap. The preparation method for this data record is: A=B;C=D. 2. Quickly import data from models during test case editing\nWhen editing database table data (including preparing table data and expectation data) in ACTS IDE, you can right click to add a model of the specified table, to import all fields and values of the specified table directly from the CSV file of the table model for quick editing. For more information about the use of DB models, see Prepare database data.\nGenerate table model Figure 6\nFigure 7\nFigure 8\nClick OK to generate the model as shown in Figure 9.\nFigure 9\nACTS also supports …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-model/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"65aaf62462b3b0ea142ca75a5b61eb0d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-model/","summary":"Quickly understand of ACTS models When you write a test case, you need to prepare some database tables, request parameter data of methods, or data for validating database tables and responses. You can save such data in models, and import it to preparation data or validation data when you edit the test case. This allows you to conveniently reuse data. Currently, ACTS models can be divided into database models and class models.","tags":null,"title":"Models","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-model/","wordcount":752},{"author":null,"categories":null,"content":" Since version 2.4.0, SOFABoot has started to support modular development capability based on Spring context isolation. To better understand the concept of modular development of SOFABoot, let\u0026amp;rsquo;s distinguish several common forms of modularization:\n Modularization based on code organization: This is the most common form. Codes with different functions are placed under different Java projects at development time and into different jar packages at compile time. At runtime, all Java classes are under the same classpath without any isolation; Modularization based on Spring context isolation: Use the Spring context to perform isolation of different function modules. At development and compile time, the codes and configurations are also placed under different Java projects. At runtime, however, if Spring beans are in different Spring contexts, they are invisible to each other, so dependency injection occurs within the same context. But, all the Java classes are still under the same ClassLoader; Modularization based on ClassLoader isolation: Borrow the ClassLoader to perform isolation. Each module has an independent ClassLoader, and the classpath between modules differs. SOFAArk is the practice of such modularization. SOFABoot Modular Development belongs to the second modularization form\u0026amp;ndash;modularization based on Spring context isolation. Each SOFABoot module uses an independent Spring context to avoid BeanId conflicts between different SOFABoot modules and effectively reduces the cost of communication between teams during enterprise-level multi-module development.\nMore details about SOFABoot module is introduced in the article.\nFeature Description Import Dependency To use SOFABoot module, you should import the following dependency: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;isle-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFABoot Module SOFABoot framework has defined the concept of SOFABoot module: A SOFABoot module is a common Jar package including Java code, Spring configuration files, and SOFABoot module identifiers. A SOFABoot application can be comprised of multiple SOFABoot modules, each of which has independent Spring context.\nThe modular development with SOFABoot provides developers with the following features:\n At runtime, the Spring context of each SOFABoot module is isolated, so the defined Beans between modules will not affect each other; Each SOFABoot module is full-featured and self-contained, allowing for easy migration and reuse in different SOFABoot applications. Developers only need to copy the whole SOFABoot module to the application and adjust the Maven dependence before running it. For the format definition of SOFABoot module, see: Module Configuration.\nInvocation between SOFABoot Modules After isolation of context, the Bean between modules cannot be directly injected, so the SOFA service is required for invocation between the modules. Currently, SOFABoot offers …","date":-62135596800,"description":"","dir":"projects/sofa-boot/modular-development/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"95bc080787c3614bfa485d2f3cd0de4c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/modular-development/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/modular-development/","summary":"Since version 2.4.0, SOFABoot has started to support modular development capability based on Spring context isolation. To better understand the concept of modular development of SOFABoot, let\u0026rsquo;s distinguish several common forms of modularization:\n Modularization based on code organization: This is the most common form. Codes with different functions are placed under different Java projects at development time and into different jar packages at compile time. At runtime, all Java classes are under the same classpath without any isolation; Modularization based on Spring context isolation: Use the Spring context to perform isolation of different function modules.","tags":null,"title":"Modular development","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/modular-development/","wordcount":578},{"author":null,"categories":null,"content":" The SOFABoot module combines a regular JAR with some SOFABoot-specific configurations, which enables a JAR to be identified by SOFABoot and modularized.\nThere are two differences between a complete SOFABoot module and a regular JAR:\n A SOFABoot module contains a sofa-module.properties file, where the name and the dependencies of the module are defined. We can place one or more Spring configuration files in the SOFABoot module\u0026amp;rsquo;s META-INF/spring directory; and SOFABoot will automatically load them as Spring configurations for that module. Inside the sofa-module.properties file Let\u0026amp;rsquo;s look at a complete sofa-module.properties file:\nModule-Name=com.alipay.test.biz.service.impl Spring-Parent=com.alipay.test.common.dal Require-Module=com.alipay.test.biz.shared Module-Profile=dev Module-Name This is the name of a SOFABoot module, which is also the unique identifier of the module. In a SOFABoot application, the Module-Name of a SOFABoot module must be different from that of another SOFABoot module. Note that the SOFABoot modules of a SOFABoot application runtime do not only cover the modules of the current application but also the modules introduced by dependency from other applications. When determining whether a module is unique, you must take these SOFABoot modules into consideration.\nRequire-Module This defines the dependency order of different modules. The value contains a comma-separated list of SOFABoot module names. For example, in the preceding configuration, it indicates that the current module depends on the com.alipay.test.biz.shared module. The SOFABoot framework processes this dependency by starting the com.alipay.test.biz.shared module before the current module.\nIn most cases, you do not have to define the Require-Module for a module. It is required only when the startup of a module\u0026amp;rsquo;s Spring context depends on that of another module\u0026amp;rsquo;s. For example, you have published a JVM Service in module A. In the init method of a Bean in module B, you need to call the JVM Service with a SOFA Reference. Assume that module B is started before module A, the Bean of module B will fail because the JVM Service of module A is not published yet and the init method fails. In this case, you can use the Require-Module to force module A to start before module B.\nSpring-Parent In a SOFABoot application, each SOFABoot module has a separate Spring context, and these Spring contexts are isolated from each other. Although this modular approach has many benefits, it can still cause some inconveniences in certain scenarios. For these scenarios, you can use the Spring-Parent to connect the Spring contexts of two SOFABoot modules. The name of a module can be configured with the Spring-Parent property. For example, in the preceding configuration, the Spring context of com.alipay.test.common.dal is set to the parent of the current module\u0026amp;rsquo;s Spring context.\nDue to Spring\u0026amp;rsquo;s limitations, a module\u0026amp;rsquo;s Spring-Parent contains only one …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-module/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2dbb8a536237f21afbee1e3f320b8193","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","summary":"The SOFABoot module combines a regular JAR with some SOFABoot-specific configurations, which enables a JAR to be identified by SOFABoot and modularized.\nThere are two differences between a complete SOFABoot module and a regular JAR:\n A SOFABoot module contains a sofa-module.properties file, where the name and the dependencies of the module are defined. We can place one or more Spring configuration files in the SOFABoot module\u0026rsquo;s META-INF/spring directory; and SOFABoot will automatically load them as Spring configurations for that module.","tags":null,"title":"Module configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","wordcount":565},{"author":null,"categories":null,"content":"SOFABoot will calculate the dependency tree based on the Require-Module. For example, the following dependency tree represents that Modules B and C depend on Module A, Module E depends on Module D, and Module F depends on Module E:\nThe dependency tree guarantees that Module A starts before Modules B and C, Module D before Module E, and Module E before Module F, but without defining the start orders between Modules B and C, or Modules B, C and Modules D, E and F, which can start either in serial or parallel.\nSOFABoot will start the modules in parallel by default. During use, if you want to disable parallel start, you can add the following parameter to application.properties:\ncom.alipay.sofa.boot.module-start-up-parallel=false ","date":-62135596800,"description":"","dir":"projects/sofa-boot/parallel-start/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a6ef51b78d2a4f9af0debbc25ea45e8a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/parallel-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/parallel-start/","summary":"SOFABoot will calculate the dependency tree based on the Require-Module. For example, the following dependency tree represents that Modules B and C depend on Module A, Module E depends on Module D, and Module F depends on Module E:\nThe dependency tree guarantees that Module A starts before Modules B and C, Module D before Module E, and Module E before Module F, but without defining the start orders between Modules B and C, or Modules B, C and Modules D, E and F, which can start either in serial or parallel.","tags":null,"title":"Module parallel startup","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/parallel-start/","wordcount":119},{"author":null,"categories":null,"content":"SOFARPC already supports using Nacos as a service registry. Suppose you have deployed Nacos Server locally according to Nacos\u0026amp;rsquo;s Quick Start, and the service discovery port is set to 8848 by default.\nTo use Nacos as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 If you use SOFARPC directly, not SOFABoot, you need to add dependency of nacos, notice that version is what you want to use in your project.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba.nacos\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;nacos-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; The current version of Nacos is supported:\nSOFARPC: 5.5.0, SOFABoot: 2.5.3。\nSOFARPC integration verification Nacos server version:0.6.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-nacos/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"cc161f22cd2145fe309e63087581adc1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","summary":"SOFARPC already supports using Nacos as a service registry. Suppose you have deployed Nacos Server locally according to Nacos\u0026rsquo;s Quick Start, and the service discovery port is set to 8848 by default.\nTo use Nacos as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 If you use SOFARPC directly, not SOFABoot, you need to add dependency of nacos, notice that version is what you want to use in your project.","tags":null,"title":"Nacos","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","wordcount":100},{"author":null,"categories":null,"content":" 前言 本文是对 Nginx、Envoy 及 MOSN 的平滑升级原理区别的分析，适合对 Nginx 实现原理比较感兴趣的同学阅读，需要具备一定的网络编程知识。\n平滑升级的本质就是 listener fd 的迁移，虽然 Nginx、Envoy、MOSN 都提供了平滑升级支持，但是鉴于它们进程模型的差异，反映在实现上还是有些区别的。这里来探讨下它们其中的区别，并着重介绍 Nginx 的实现。\nNginx 相信有很多人认为 Nginx 的 reload 操作就能完成平滑升级，其实这是个典型的理解错误。实际上 reload 操作仅仅是平滑重启，并没有真正的升级新的二进制文件，也就是说其运行的依然是老的二进制文件。\nNginx 自身也并没有提供平滑升级的命令选项，其只能靠手动触发信号来完成。具体正确的操作步骤可以参考这里：Upgrading Executable on the Fly，这里只分析下其实现原理。\nNginx 的平滑升级是通过 fork + execve 这种经典的处理方式来实现的。准备升级时，Old Master 进程收到信号然后 fork 出一个子进程，注意此时这个子进程运行的依然是老的镜像文件。紧接着这个子进程会通过 execve 调用执行新的二进制文件来替换掉自己，成为 New Master。\n那么问题来了：New Master 启动时按理说会执行 bind + listen 等操作来初始化监听，而这时候 Old Master 还没有退出，端口未释放，执行 execve 时理论上应该会报：Address already in use 错误，但是实际上这里却没有任何问题，这是为什么？\n因为 Nginx 在 execve 的时候压根就没有重新 bind + listen，而是直接把 listener fd 添加到 epoll 的事件表。因为这个 New Master 本来就是从 Old Master 继承而来，自然就继承了 Old Master 的 listener fd，但是这里依然有一个问题：该怎么通知 New Master 呢？\n环境变量。execve 在执行的时候可以传入环境变量。实际上 Old Master 在 fork 之前会将所有 listener fd 添加到 NGINX 环境变量：\nngx_pid_t ngx_exec_new_binary(ngx_cycle_t *cycle, char *const *argv) { ... ctx.path = argv[0]; ctx.name = \u0026amp;quot;new binary process\u0026amp;quot;; ctx.argv = argv; n = 2; env = ngx_set_environment(cycle, \u0026amp;amp;n); ... env[n++] = var; env[n] = NULL; ... ctx.envp = (char *const *) env; ccf = (ngx_core_conf_t *) ngx_get_conf(cycle-\u0026amp;gt;conf_ctx, ngx_core_module); if (ngx_rename_file(ccf-\u0026amp;gt;pid.data, ccf-\u0026amp;gt;oldpid.data) == NGX_FILE_ERROR) { ... return NGX_INVALID_PID; } pid = ngx_execute(cycle, \u0026amp;amp;ctx); return pid; } Nginx 在启动的时候，会解析 NGINX 环境变量：\nstatic ngx_int_t ngx_add_inherited_sockets(ngx_cycle_t *cycle) { ... inherited = (u_char *) getenv(NGINX_VAR); if (inherited == NULL) { return NGX_OK; } if (ngx_array_init(\u0026amp;amp;cycle-\u0026amp;gt;listening, cycle-\u0026amp;gt;pool, 10, sizeof(ngx_listening_t)) != NGX_OK) { return NGX_ERROR; } for (p = inherited, v = p; *p; p++) { if (*p == \u0026#39;:\u0026#39; || *p == \u0026#39;;\u0026#39;) { s = ngx_atoi(v, p - v); ... v = p + 1; ls = ngx_array_push(\u0026amp;amp;cycle-\u0026amp;gt;listening); if (ls == NULL) { return NGX_ERROR; } ngx_memzero(ls, sizeof(ngx_listening_t)); ls-\u0026amp;gt;fd = (ngx_socket_t) s; } } ... ngx_inherited = 1; return ngx_set_inherited_sockets(cycle); } 一旦检测到是继承而来的 socket，那就说明已经打开了，不会再继续 bind + listen 了：\nngx_int_t ngx_open_listening_sockets(ngx_cycle_t *cycle) { ... /* TODO: configurable try number */ for (tries = 5; tries; tries--) { failed = 0; /* for each listening socket */ ls = cycle-\u0026amp;gt;listening.elts; for (i = 0; i \u0026amp;lt; cycle-\u0026amp;gt;listening.nelts; i++) { ... if (ls[i].inherited) { /* TODO: close on exit */ /* TODO: nonblocking */ /* TODO: deferred accept */ continue; } ... ngx_log_debug2(NGX_LOG_DEBUG_CORE, log, 0, \u0026amp;quot;bind() %V #%d \u0026amp;quot;, \u0026amp;amp;ls[i].addr_text, s); if (bind(s, ls[i].sockaddr, ls[i].socklen) == -1) { ... } ... } } if (failed) { ngx_log_error(NGX_LOG_EMERG, log, 0, \u0026amp;quot;still could not bind()\u0026amp;quot;); return NGX_ERROR; } return NGX_OK; } Envoy Envoy 使用的是单进程多线程模型，其局限就是无法通过环境变量来传递 listener fd。因此 Envoy 采用的是 UDS（unix domain sockets）方案。当 New Envoy 启动完成后，会通过 UDS 向 Old Envoy 请求 listener fd 副本， …","date":-62135596800,"description":"","dir":"projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"63ca389b7e6e0a585d0183ad71887f65","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","summary":"前言 本文是对 Nginx、Envoy 及 MOSN 的平滑升级原理区别的分析，适合对 Nginx 实现原理比较感兴趣的同学阅读，需要具备一定的网络编程知识。 平滑升级的","tags":null,"title":"Nginx vs Envoy vs MOSN 平滑升级原理解析","type":"projects","url":"/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","wordcount":1525},{"author":null,"categories":null,"content":" If you need to call SOFARPC through NodeJs, you can start by following this document.\nInstall First install the SOFARPC Node.\nhttps://github.com/sofastack/sofa-rpc-node\nUse the following command:\n$ npm install sofa-rpc-node --save Code sample Expose an RPC service and publish it to registry center \u0026#39;use strict\u0026#39;; const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, Address: \u0026#39;127.0.0.1:2181\u0026#39;, // need to start a zkServer locally }); // 2. Create an RPC Server instance const server = new RpcServer({ logger, Registry, // incoming registry client port: 12200, }); // 3. Add service server.addService({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }, { async plus(a, b) { return a + b; }, }); // 4. Start the server and publish the service server.start() .then(() =\u0026amp;gt; { server.publish(); }); Call RPC service (Get service list from registry center) \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); async function invoke() { // 2. Create an RPC Client instance const client = new RpcClient({ logger, registry, }); // 3. Create a service consumer const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }); // 4. Wait for the consumer ready (subscribe to the service list from registry center...) await consumer.ready(); // 5. Execute generic call const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); Call RPC service (direct call) \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const logger = console; async function invoke() { // No need to pass in the registry instance const client = new RpcClient({ logger, }); const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, serverHost: \u0026#39;127.0.0.1:12200\u0026#39;, // directly specify the service address }); await consumer.ready(); const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); Expose and call the protobuf interface Define interface Define the interface with *.proto\nsyntax = \u0026amp;quot;proto3\u0026amp;quot;; package com.alipay.sofa.rpc.test; // optional option java_multiple_files = false; service ProtoService { rpc echoObj (EchoRequest) returns (EchoResponse) {} } message EchoRequest { string name = 1; Group group = 2; } message EchoResponse { int32 code = 1; string message = 2; } enum Group { A = 0; B = 1; } Server code \u0026#39;use strict\u0026#39;; const antpb = require(\u0026#39;antpb\u0026#39;); const protocol = require(\u0026#39;sofa-bolt-node\u0026#39;); const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/node-and-java-communicate/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3329852e9991868a3cdc473b861ca750","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","summary":"If you need to call SOFARPC through NodeJs, you can start by following this document.\nInstall First install the SOFARPC Node.\nhttps://github.com/sofastack/sofa-rpc-node\nUse the following command:\n$ npm install sofa-rpc-node --save Code sample Expose an RPC service and publish it to registry center 'use strict'; const { RpcServer } = require('sofa-rpc-node').server; const { ZookeeperRegistry } = require('sofa-rpc-node').registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, Address: '127.","tags":null,"title":"NodeJS support","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","wordcount":635},{"author":null,"categories":null,"content":" 快速上手 如果你有通过 NodeJs 调用 SOFARPC 的需求.可以按照如下的文档来开始.\n安装 首先按照文档安装\nhttps://github.com/sofastack/sofa-rpc-node\n使用命令.\n$ npm install sofa-rpc-node --save 代码示例 暴露一个 RPC 服务，并发布到注册中心 \u0026#39;use strict\u0026#39;; const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. 创建 zk 注册中心客户端 const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, // 需要本地启动一个 zkServer }); // 2. 创建 RPC Server 实例 const server = new RpcServer({ logger, registry, // 传入注册中心客户端 port: 12200, }); // 3. 添加服务 server.addService({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }, { async plus(a, b) { return a + b; }, }); // 4. 启动 Server 并发布服务 server.start() .then(() =\u0026amp;gt; { server.publish(); }); 调用 RPC 服务（从注册中心获取服务列表） \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. 创建 zk 注册中心客户端 const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); async function invoke() { // 2. 创建 RPC Client 实例 const client = new RpcClient({ logger, registry, }); // 3. 创建服务的 consumer const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }); // 4. 等待 consumer ready（从注册中心订阅服务列表...） await consumer.ready(); // 5. 执行泛化调用 const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); 调用 RPC 服务（直连模式） \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const logger = console; async function invoke() { // 不需要传入 registry 实例了 const client = new RpcClient({ logger, }); const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, serverHost: \u0026#39;127.0.0.1:12200\u0026#39;, // 直接指定服务地址 }); await consumer.ready(); const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); 暴露和调用 protobuf 接口 接口定义 通过 *.proto 来定义接口\nsyntax = \u0026amp;quot;proto3\u0026amp;quot;; package com.alipay.sofa.rpc.test; // 可选 option java_multiple_files = false; service ProtoService { rpc echoObj (EchoRequest) returns (EchoResponse) {} } message EchoRequest { string name = 1; Group group = 2; } message EchoResponse { int32 code = 1; string message = 2; } enum Group { A = 0; B = 1; } 服务端代码 \u0026#39;use strict\u0026#39;; const antpb = require(\u0026#39;antpb\u0026#39;); const protocol = require(\u0026#39;sofa-bolt-node\u0026#39;); const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 传入 *.proto 文件存放的目录，加载接口定义 const proto = antpb.loadAll(\u0026#39;/path/proto\u0026#39;); // 将 proto 设置到协议中 protocol.setOptions({ proto }); const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); const server = new RpcServer({ logger, protocol, // 覆盖协议 registry, codecType: \u0026#39;protobuf\u0026#39;, // 设置默认的序列化方式为 protobuf port: 12200, }); server.addService({ interfaceName: …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/node-and-java-communicate/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3329852e9991868a3cdc473b861ca750","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","summary":"快速上手 如果你有通过 NodeJs 调用 SOFARPC 的需求.可以按照如下的文档来开始. 安装 首先按照文档安装 https://github.com/sofastack/sofa-rpc-node 使用命令. $ npm install sofa-rpc-node --save 代码示例 暴露一个 RPC 服务，并发布到注册","tags":null,"title":"Node跨语言调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","wordcount":757},{"author":null,"categories":null,"content":" OkHttp Integration In this document will demonstrate how to use SOFATracer to track of OkHttp, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nDependency introduction \u0026amp;lt;!-- SOFATracer dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- okhttp dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.squareup.okhttp3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;okhttp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.12.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs # port server.port=8081 Add a Controller that provides RESTful services In the project, provide a simple Controller, for example:\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8081/okhttp?name=sofa * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/okhttp\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;okhttp\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } Construct OkHttp to initiate a call to the RESTful service above The code example is as follows:\n Construct the OkHttp Client instance: OkHttpClientInstance httpClient = new OkHttpClientInstance(); String httpGetUrl = \u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;; String responseStr = httpClient.executeGet(httpGetUrl); Run Start the SOFABoot app and see the log in the console as follows:\n2019-04-12 13:38:09.896 INFO 51193 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2019-04-12 13:38:09.947 INFO 51193 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8081 (http) 2019-04-12 13:38:09.952 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Started OkHttpDemoApplication in 3.314 seconds (JVM running for 4.157) When there is a log similar to the following, the call to OkHttp is successful:\n2019-04-12 13:38:10.205 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;sofa\u0026amp;quot;} View log In the application.properties, the log printing directory we configured is ./logs, which is the root directory of the current application (we can configure it based on actual situation). In the root directory, you can see log files in the structure similar to …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-okhttp/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2b665b984dd33a4c04b5cd7b4de2410c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","summary":"OkHttp Integration In this document will demonstrate how to use SOFATracer to track of OkHttp, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nDependency introduction \u0026lt;!-- SOFATracer dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- okhttp dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.squareup.okhttp3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;okhttp\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.12.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.","tags":null,"title":"OkHttp Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","wordcount":374},{"author":null,"categories":null,"content":" OkHttp Log Format SOFATracer integrates OkHttp and outputs the requested link log data format. The default is JSON data format.\nOkHttp digest log（okhttp-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code req.size.bytes Request Body Size resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.app remote app baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-12 13:38:10.187\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe85a1555047489980100151193\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:207,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} OkHttp stat log（okhttp-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-12 13:39:09.720\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:207,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-okhttp/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dbc9555f43d0b2eda22f10ed45713fb9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","summary":"OkHttp Log Format SOFATracer integrates OkHttp and outputs the requested link log data format. The default is JSON data format.\nOkHttp digest log（okhttp-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.","tags":null,"title":"OkHttp log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","wordcount":174},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 OkHttp 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;!-- SOFATracer 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- okhttp 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.squareup.okhttp3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;okhttp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.12.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=OkHttpClientDemo # logging path logging.path=./logs # port server.port=8081 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8081/okhttp?name=sofa * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/okhttp\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;okhttp\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } 构造 OkHttp 发起一次对上文的 RESTful 服务的调用 代码示例如下：\n 构造 OkHttp Client 调用实例： OkHttpClientInstance httpClient = new OkHttpClientInstance(); String httpGetUrl = \u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;; String responseStr = httpClient.executeGet(httpGetUrl); 运行 启动 SOFABoot 应用，在控制台中看到启动打印的日志如下：\n2019-04-12 13:38:09.896 INFO 51193 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2019-04-12 13:38:09.947 INFO 51193 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8081 (http) 2019-04-12 13:38:09.952 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Started OkHttpDemoApplication in 3.314 seconds (JVM running for 4.157) 当有类似如下的日志时，说明 OkHttp 的调用成功：\n2019-04-12 13:38:10.205 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;sofa\u0026amp;quot;} 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要进行配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── okhttp-digest.log ├── okhttp-stat.log ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 示例中通过构造 OkHttp 对象发起 RESTful 服务的调用，调用完成后可以在 okhttp-digest.log 中看到类似如下的日志:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-okhttp/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2b665b984dd33a4c04b5cd7b4de2410c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","summary":"在本文档将演示如何使用 SOFATracer 对 OkHttp 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;!-- SOFATracer 依","tags":null,"title":"OkHttp 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","wordcount":578},{"author":null,"categories":null,"content":" SOFATracer 集成 OkHttp 后输出请求的链路数据格式，默认为 JSON 数据格式。\nOkHttp 摘要日志（okhttp-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId request.url 请求 URL method 请求 HTTP 方法 result.code HTTP 返回状态码 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 time.cost.milliseconds 请求耗时（ms） current.thread.name 当前线程名 remote.app 目标应用 baggage 透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 11:35:28.429\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567481728265100112783\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;164ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} OkHttp 统计日志（okhttp-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 11:43:06.975\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:174,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-okhttp/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dbc9555f43d0b2eda22f10ed45713fb9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","summary":"SOFATracer 集成 OkHttp 后输出请求的链路数据格式，默认为 JSON 数据格式。 OkHttp 摘要日志（okhttp-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下","tags":null,"title":"OkHttp 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","wordcount":330},{"author":null,"categories":null,"content":" OpenFeign Integration In this document will demonstrate how to use SOFATracer to track of OpenFeign.\nPrepare Environment The versions of the framework components used in this case are as follows:\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 This case includes two submodules:\n tracer-sample-with-openfeign-provider service provider tracer-sample-with-openfeign-consumer service consumer New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026amp;rsquo;s dependency. First, you need to unzip the generated zip package of Spring Boot project and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more information about SOFABoot versions, refer to Release notes.\nNew tracer-sample-with-openfeign-provider Module Introducing dependence\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer versions are controlled by SOFABoot versions. If the SOFABoot versions used do not match, you need to manually specify a tracer version that is higher than 3.0.4.\n application.properties Configuration spring.application.name=tracer-provider server.port=8800 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-provider Simple resource class\n@RestController public class UserController { @RequestMapping(\u0026amp;quot;/feign\u0026amp;quot;) public String testFeign(HttpServletRequest request) { return \u0026amp;quot;hello tracer feign\u0026amp;quot;; } } New tracer-sample-with-openfeign-consumer Module Introducing dependence \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-openfeign/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"75d9940033ad3b4342eab9d5c7a191f1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","summary":"OpenFeign Integration In this document will demonstrate how to use SOFATracer to track of OpenFeign.\nPrepare Environment The versions of the framework components used in this case are as follows:\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 This case includes two submodules:\n tracer-sample-with-openfeign-provider service provider tracer-sample-with-openfeign-consumer service consumer New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026rsquo;s dependency.","tags":null,"title":"OpenFeign Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","wordcount":368},{"author":null,"categories":null,"content":" OpenFeign Log Format SOFATracer integrates Spring Cloud OpenFeign and outputs the requested link log data format. The default is JSON data format.\nSpring Cloud OpenFeign digest log（feign-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code error error massage req.size.bytes Request Body Size resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.host remote host remote.port remote port component.client.impl component name baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-03-28 18:08:06.800\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe88f1553767685981100124403\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.232.143:8800/feign\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:18,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:206,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8082-exec-1\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.232.143\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;8800\u0026amp;quot;,\u0026amp;quot;component.client.impl\u0026amp;quot;:\u0026amp;quot;open-feign\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring Cloud OpenFeign stat log（feign-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success ; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-03-28 18:09:06.800\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.232.143:8800/feign\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:206,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;Y\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-openfeign/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"81864817e297a7bf019705c72f8ff0a8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","summary":"OpenFeign Log Format SOFATracer integrates Spring Cloud OpenFeign and outputs the requested link log data format. The default is JSON data format.\nSpring Cloud OpenFeign digest log（feign-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.","tags":null,"title":"OpenFeign log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","wordcount":190},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 Spring Cloud OpenFeign 进行埋点。\n基础环境 本案例使用的各框架组件的版本如下：\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 本案例包括两个子工程：\n tracer-sample-with-openfeign-provider 服务提供方 tracer-sample-with-openfeign-consumer 服务调用方 新建 SOFABoot 工程作为父工程 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 Maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n新建 tracer-sample-with-openfeign-provider 在工程模块的 pom 文件中添加 SOFATracer 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer 版本受 SOFABoot 版本管控，如果使用的 SOFABoot 版本不匹配，则需要手动指定 tracer 版本，且版本需高于 3.0.4.\n 在工程的 application.properties 文件下添加相关参数 spring.application.name=tracer-provider server.port=8800 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-provider 简单的资源类\n@RestController public class UserController { @RequestMapping(\u0026amp;quot;/feign\u0026amp;quot;) public String testFeign(HttpServletRequest request) { return \u0026amp;quot;hello tracer feign\u0026amp;quot;; } } 新建 tracer-sample-with-openfeign-consumer 在工程模块的 pom 文件中添加 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 在工程的 application.properties 文件下添加相关参数\nspring.application.name=tracer-consumer server.port=8082 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-consumer 定义 feign 资源 @FeignClient(value = \u0026amp;quot;tracer-provider\u0026amp;quot;,fallback = FeignServiceFallbackFactory.class) public interface FeignService { @RequestMapping(value = \u0026amp;quot;/feign\u0026amp;quot;, method = RequestMethod.GET) …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-openfeign/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"75d9940033ad3b4342eab9d5c7a191f1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","summary":"在本文档将演示如何使用 SOFATracer 对 Spring Cloud OpenFeign 进行埋点。 基础环境 本案例使用的各框架组件的版本如下： Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 本案例包括两个子工程： tracer-sample-with-openfeign-provider 服务提供方 tracer-sample-with-openfeign-consumer","tags":null,"title":"OpenFeign 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","wordcount":602},{"author":null,"categories":null,"content":" SOFATracer 集成 Spring Cloud OpenFeign 后输出请求的链路数据格式，默认为 JSON 数据格式。\nSpring Cloud OpenFeign 摘要日志（feign-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method error 错误信息 req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:28:52.363\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477731347100110969\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8082-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;219ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.233.39:8800/feign\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:18,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.233.39\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;8800\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring Cloud OpenFeign 统计日志（feign-stat.log）ls stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:29:34.528\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.233.39:8800/feign\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:378,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-openfeign/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"81864817e297a7bf019705c72f8ff0a8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","summary":"SOFATracer 集成 Spring Cloud OpenFeign 后输出请求的链路数据格式，默认为 JSON 数据格式。 Spring Cloud OpenFeign 摘要日志（feign-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解","tags":null,"title":"OpenFeign 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","wordcount":341},{"author":null,"categories":null,"content":" MOSN\u0026amp;rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer Acknowledgement MOSN builds on open source projects such as Envoy and Istio, thanks to the efforts of the open source community.\n","date":-62135596800,"description":"","dir":"projects/mosn/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f25c59cbb758b4dae5de39e1f1c3a2f4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/mosn/overview/","summary":"MOSN\u0026rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/mosn/overview/","wordcount":245},{"author":null,"categories":null,"content":" MOSN\u0026amp;rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer Acknowledgement MOSN builds on open source projects such as Envoy and Istio, thanks to the efforts of the open source community.\n","date":-62135596800,"description":"","dir":"projects/occlum/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1d8851c81ed6dacf04ebbe841d1b2835","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/occlum/overview/","summary":"MOSN\u0026rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/occlum/overview/","wordcount":245},{"author":null,"categories":null,"content":" Introduction SOFALookout is a lightweight and open source middleware service of Ant Financial that solves the metrics and monitoring issues of the system. The services it provides include: Event logging, collecting, processing, storing, and querying of Metrics. The open source project consists of two separate parts, the client and server side services.\nClient-side service SOFALookout Client is a Java SDK that helps developers log events of metrics in project code. It also allows you to view real-time status information for the Java application.\n +------------------+ Reg: API: | dimension meters +--------+ +------------------+ | flatmap +---------------------------+ +-----------\u0026amp;gt; | Default/DropwizardMetrics| | +---------------------------+ | | http +--------------+ +-----------\u0026amp;gt; |Lookout server| | +--------------+ +----------------------+ | add common tags dimension EXTS: | JVM,OS,GC... +----+ +----------------------+ Server-side services SOFALookout Server helps you solve system state metrics in a distributed environment. Its data sources include, but not limited to the projects that use the lookout-client package. The server will be available in the next release, so stay tuned.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/overview/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"8a8a8ef02ca95d4d11e3e4b195bbae70","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/overview/","summary":"Introduction SOFALookout is a lightweight and open source middleware service of Ant Financial that solves the metrics and monitoring issues of the system. The services it provides include: Event logging, collecting, processing, storing, and querying of Metrics. The open source project consists of two separate parts, the client and server side services.\nClient-side service SOFALookout Client is a Java SDK that helps developers log events of metrics in project code.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/overview/","wordcount":160},{"author":null,"categories":null,"content":" SOFARPC is a Java-based RPC service framework open sourced by Ant Financial, which provides remote service call between applications, high scalability and fault tolerance features. Currently, all RPC calls of Ant Financial businesses use SOFARPC. SOFARPC provides users with functions such as load balancing, traffic forwarding, link tracing, link data transparent transmission, and fault removal.\nIn addition, SOFARPC supports different protocols, currently including bolt, RESTful, dubbo, and H2C. Bolt is a network communication framework based on Netty developed by Ant Financial Services Group.\nImplementation principle When an SOFARPC application is started, if the current application needs to publish RPC services, SOFARPC will register these services to the service registry center. As shown in the figure, the service points to the Registry. When the SOFARPC application that references this service is started, it subscribes to the metadata information of the corresponding service from the service registry. After receiving the subscription request, the service registry will push the publisher\u0026amp;rsquo;s metadata list to the service reference party in real time. As shown in the figure, Register points to Reference. When the service reference party gets the addresses, it can pick up the address and initiate the call. As shown in the figure, Reference points to Service. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"62f0806ad40fcaaeab6a82470b14a2e2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/overview/","summary":"SOFARPC is a Java-based RPC service framework open sourced by Ant Financial, which provides remote service call between applications, high scalability and fault tolerance features. Currently, all RPC calls of Ant Financial businesses use SOFARPC. SOFARPC provides users with functions such as load balancing, traffic forwarding, link tracing, link data transparent transmission, and fault removal.\nIn addition, SOFARPC supports different protocols, currently including bolt, RESTful, dubbo, and H2C. Bolt is a network communication framework based on Netty developed by Ant Financial Services Group.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/overview/","wordcount":203},{"author":null,"categories":null,"content":" Introduction This sample project shows how to build an executable-ark-jar based on a springboot project with the tool of sofa-ark-maven-plugin.\nPreparation As this project depends on the ark-plugin generated by the project of sample-ark-plugin, please ensure the sample sample-ark-plugin installed in your local maven repository before run this project.\nTools The Maven plugin of sofa-ark-maven-plugin is provided to build a standard executable-ark-jar, and just needs some simple configurations. Its maven coordinates is:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Refer to the document of plugin use for details\n Step By Step Based on the sample project, we will describe step by step how to package a Spring Boot Web project to an executable Ark package\nCreating Spring Boot Web Project Download a standard Spring Boot Web project from the official website https://start.spring.io/\nIntroducing sample-ark-plugin Configure items as follows under the main pom.xml of the project, and add the Ark Plugin dependency generated from another sample project, reference documents\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configuring Packaging Plugin Configure the Maven plugin (sofa-Ark-maven-plugin) as follows under the main pom.xml of the project:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; In this sample project, we have configured only a fraction of the items, but they are enough to generate an executable Ark package. The meaning of each configuration item is shown below: * outputDirectory: the directory for the output Ark package files after packaging of mvn package;\n arkClassifier: the value of classifier included in the Maven coordinates of the Ark specified for release, which is null by default; Note that arkClassifier is null by default. If you do not specify a classifier, the Jar package uploaded to the repository is actually an executable Ark package. If you need to distinguish it from common packaging, you need to configure a value for this …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-demo/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2c97c409788f41051c79836d277997be","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","summary":"Introduction This sample project shows how to build an executable-ark-jar based on a springboot project with the tool of sofa-ark-maven-plugin.\nPreparation As this project depends on the ark-plugin generated by the project of sample-ark-plugin, please ensure the sample sample-ark-plugin installed in your local maven repository before run this project.\nTools The Maven plugin of sofa-ark-maven-plugin is provided to build a standard executable-ark-jar, and just needs some simple configurations. Its maven coordinates is:","tags":null,"title":"Package into Ark JAR","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","wordcount":757},{"author":null,"categories":null,"content":" Introduction This sample project demonstrates how to use Maven plugins to package a general Java project into an Ark plugin that meets the standard specifications.\nBackground In actual development, dependency conflicts often occur. Suppose we have developed a class library named sample-lib, and it might conflict with the existing dependencies when the business application is imported. At this point, we hope the library can be isolated from other business dependencies, without negotiating with each other over dependency package versions. Ark Plugin is exactly the result of our best practice under this demand background. It runs on top of the Ark Container, which is loaded by a container. Any Ark Plugin is loaded by a separate ClassLoader to be isolated from each other. There are four concepts of Ark Plugin: * Import class: When the plugin starts up, a plugin used to export the class is first delegated to load the class. If that fails, it will attempt to load from inside this plugin;\n Export class: If the class has been imported by other plugins, it will be first loaded from this plugin;\n Import resource: When the plugin is searching for resources, a plugin used to export the class is first delegated to load the class. If that fails, it will attempt to load from inside this plugin.\n Export resource: If the resource has been imported by other plugins, it will be first loaded from this plugin;\n Refer to the plugin specifications for more details\n Tools Upon simple configurations, the officially provided Maven plugin sofa-ark-plugin-maven-plugin can package common Java projects into a standard-format Ark Plugin. The coordinates of Maven plugin are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; For more information, see the plugin configuration document\n Getting started Based on this sample project, we will describe how to build an Ark plugin step by step.\nCreate a Standard Maven Project This is a standard Maven project consisting of two modules: * The common module: contains the plugin export class\n The plugin module: contains com.alipay.sofa.ark.spi.service.PluginActivator interface implementation class and a plugin service class. The plugin packaging tool sofa-ark-plugin-maven-plugin can be configured in the module\u0026amp;rsquo;s pom.xml file; Configuring Packaging Plugin Package the plugin in the pom.xml file according to the following configurations:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${project.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--can only configure no more than one activator--\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin-demo/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d8125843ced13352dd228299f222c74d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","summary":"Introduction This sample project demonstrates how to use Maven plugins to package a general Java project into an Ark plugin that meets the standard specifications.\nBackground In actual development, dependency conflicts often occur. Suppose we have developed a class library named sample-lib, and it might conflict with the existing dependencies when the business application is imported. At this point, we hope the library can be isolated from other business dependencies, without negotiating with each other over dependency package versions.","tags":null,"title":"Package into Ark Plugin","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","wordcount":664},{"author":null,"categories":null,"content":"SOFA Mesh 项目 fork 了 Istio 项目，对 Pilot 的能力进行增强，目前在进行中的增强主要集中在下面三个方面： - 支持 Zookeeper 作为注册中心，并在此基础上支持 SOFA、DUBBO 等使用 Zookeeper 作为注册中心的微服务框架。 - 支持通用协议框架，使用一个通用协议，在 Kubernetes DNS 的基础上同时支持多种协议。 - 新增 register agent，支持 SOFA、DUBBO 和 HSF 的容器模型，即支持单个应用注册多个服务实例。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-readme/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7b098e394986596d8fb01e1fe2120829","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-readme/","summary":"SOFA Mesh 项目 fork 了 Istio 项目，对 Pilot 的能力进行增强，目前在进行中的增强主要集中在下面三个方面： - 支持 Zookeeper 作为注册中心，并在此基础上支持 SOFA、DUBBO","tags":null,"title":"Pilot 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-readme/","wordcount":168},{"author":null,"categories":null,"content":" Print traceId And spanId To Application Log SLF4J provides MDC (Mapped Diagnostic Contexts), which supports you to define and modify log output formats and content. This document introduces the SLF4J MDC feature integrated in SOFATracer, which allows you to output the current SOFATracer context TraceId and SpanId with simply modifying the log configuration file.\nPrerequisites In order to properly print the TraceId and SpanId parameters in the logs of the application, the log programming interface needs to be programmed for SLF4J. That is, the programming interface for printing log does not rely on specific log implementation.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce dependency For SOFABoot or Spring Boot application, you need to introduce the specific log implementation. It is recommended to introduce Logback and Log4j2 instead of Log4j. Also, it is suggested to use only one log implementation rather than multiple implementations.\n Logback implementation: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Log4j2 implementation: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-log4j2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!--SOFABoot does not control log4j2 version --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configuration method The corresponding TraceId and SpanId are printed based on SLF4J MDC. First, the log programming interface in application should be oriented to SLF4J, as follows:\n/ / Introduce interface import org.slf4j.Logger; import org.slf4j.LoggerFactory; / / Construct log printing instance private static final Logger logger = LoggerFactory.getLogger(XXX.class); Second, to correctly print the TraceId and SpanId parameters, we also need to configure the extra parameters of PatternLayout in the log configuration file. The two parameters are %X{SOFA-TraceId} and %X. {SOFA-SpanId}, whose values ​​can be obtained from MDC.\npattern parameter configured with Logback as an example:\n\u0026amp;lt;pattern\u0026amp;gt;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId}, %X{SOFA-SpanId}] ---- %m%n\u0026amp;lt;/pattern\u0026amp;gt; Key configuration items: As a part of the Logback pattern, [%X{SOFA-TraceId},%X{SOFA-SpanId}] replaces the placeholders in the pattern with the specific TraceId and SpanId in the current thread process when the corresponding appender is called. If there is no corresponding TraceId and SpanId in the current thread, the placeholder is replaced with \u0026amp;ldquo;null\u0026amp;rdquo;. Log4j2 PatternLayout configuration sample:\n\u0026amp;lt;PatternLayout pattern=\u0026amp;quot;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId},%X{SOFA-SpanId}] ---- %m%n \u0026amp;quot; /\u0026amp;gt; Log4j PatternLayout configuration sample:\n\u0026amp;lt;layout class=\u0026amp;quot;org.apache.log4j.PatternLayout\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;param …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/print-traceid-spanid/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0d8cc680f811d1db2cffddbba269571c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","summary":"Print traceId And spanId To Application Log SLF4J provides MDC (Mapped Diagnostic Contexts), which supports you to define and modify log output formats and content. This document introduces the SLF4J MDC feature integrated in SOFATracer, which allows you to output the current SOFATracer context TraceId and SpanId with simply modifying the log configuration file.\nPrerequisites In order to properly print the TraceId and SpanId parameters in the logs of the application, the log programming interface needs to be programmed for SLF4J.","tags":null,"title":"Print traceId and spanId in application log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","wordcount":360},{"author":null,"categories":null,"content":"Describe several methods to use SOFARPC in different environments. * Use API in non-Spring environment * Use XML in SOFABoot environment * Use Annotation in SOFABoot environment * Use dynamic API in SOFABoot environment\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programming/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"9a947dae761c84aa4d95121c076ac552","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programming/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programming/","summary":"Describe several methods to use SOFARPC in different environments. * Use API in non-Spring environment * Use XML in SOFABoot environment * Use Annotation in SOFABoot environment * Use dynamic API in SOFABoot environment","tags":null,"title":"Programming","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programming/","wordcount":34},{"author":null,"categories":null,"content":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-samples/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"600c182fdee786a59e14899ba0fce8a1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-run-samples/","summary":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-run-samples/","wordcount":42},{"author":null,"categories":null,"content":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-run-samples/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"93784b2fca67986e00aa3bc5ea0dbb6b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-run-samples/","summary":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-run-samples/","wordcount":42},{"author":null,"categories":null,"content":" Some sample projects are provided in the source project to assist in the use of the project. The readme file of the sample project has additional instructions for use, and you need to import these sample projects separately into IDE.\nClient-side sample project lookout-client-samples-java  This sample project demonstrates how to use and configure the client in code form in a normal Java project.\n lookout-client-samples-boot  This sample project demonstrates how to use and configure the client in a SpringBoot (or SofaBoot) project.\n lookout-client-samples-prometheus  The sample project demonstrates how to use and configure the client to use prometheus in a SpringBoot (or SofaBoot) project.\nServer-side sample project ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-samples/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a8a0fcd3f99ce2fb46e4d543e30797c9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","summary":"Some sample projects are provided in the source project to assist in the use of the project. The readme file of the sample project has additional instructions for use, and you need to import these sample projects separately into IDE.\nClient-side sample project lookout-client-samples-java  This sample project demonstrates how to use and configure the client in code form in a normal Java project.\n lookout-client-samples-boot  This sample project demonstrates how to use and configure the client in a SpringBoot (or SofaBoot) project.","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","wordcount":105},{"author":null,"categories":null,"content":" SOFABoot provides developers with three ways to publish and reference JVM services\n XML Annotation Programming API XML Service Publish First, we need to define a Bean:\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; Then, publish the Bean as a SOFA JVM service by using the Spring extension tag provided by SOFA.\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; In the preceding configuration, the interface parameter indicates the interface for releasing services, and the ref parameter indicates the Bean to be published as a JVM service.\nAt this point, we have published a JVM service success.\nService Reference We can also reference a JVM service by using the Spring extension tag provided by SOFA.\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; In the preceding configuration, the interface parameter indicates the service interface, which must be consistent with that configured during the service publish. The meaning of the ID attribute is the same as Spring BeanId. A Spring Bean with the ID sampleServiceRef will be generated from the above configuration. We can inject it anywhere in the Spring context of the current SOFABoot module.\n service/reference tag also supports RPC service publish, with related document: RPC Service Publish and Reference\n Annotation Warning\nIf a service has been annotated with @SofaService, it cannot be published in the mode of XML. Choose one mode to publish the service instead of a mixture of two modes.\n In addition to publishing JVM services and reference through XML, SOFABoot also provides Annotation for JVM services publish and reference. To publish JVM services through Annotation, we only need to add an annotation @SofaService to the implementation class, as follows:\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } Prompt\n@SofaService is used to publish a Spring Bean as a JVM service, which means that although you may not write the configuration of \u0026amp;lt;sofa:service/\u0026amp;gt;, you still need to configure the class annotated with @SofaService as a Spring Bean.\n When configuring \u0026amp;lt;sofa:service/\u0026amp;gt; in the XML mode, you have configured an interface for the service. However, when using the @SofaService annotation, you haven\u0026amp;rsquo;t configured the service interface. This is because when the class annotated with @SofaService has implemented only one interface, the framework directly uses the interface as the service interface. What if the class annotated with @SofaService has implemented multiple interfaces? In this case, you can set the interfaceType field of @SofaService to specify the service interface, as shown below: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/module-service/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"527472fbe57ce450e4e2b41d878704cb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/module-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/module-service/","summary":"SOFABoot provides developers with three ways to publish and reference JVM services\n XML Annotation Programming API XML Service Publish First, we need to define a Bean:\n\u0026lt;bean id=\u0026quot;sampleService\u0026quot; class=\u0026quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026quot;\u0026gt; Then, publish the Bean as a SOFA JVM service by using the Spring extension tag provided by SOFA.\n\u0026lt;sofa:service interface=\u0026quot;com.alipay.sofa.runtime.test.service.SampleService\u0026quot; ref=\u0026quot;sampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.jvm/\u0026gt; \u0026lt;/sofa:service\u0026gt; In the preceding configuration, the interface parameter indicates the interface for releasing services, and the ref parameter indicates the Bean to be published as a JVM service.","tags":null,"title":"Publish and reference JVM services","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/module-service/","wordcount":1001},{"author":null,"categories":null,"content":" To run this demo, you should sign up an Ant Financial technology account. Please see Ant Finanical Official Site to see more details.\nDemo content Service Mesh applies the communication capabilities between services to the infrastructure, thus decoupling and lightweighting applications.\nHowever, Service Mesh itself is still complex. CloudMesh can easily implement Service Mesh technology by hosting Service Mesh on the cloud.\nWith our workshop, you can easily deploy applications developed in multiple programming languages ​​to CloudMesh, thereby experiencing the capabilities of Service Mesh. The capabilities include accessing services, monitoring traffic, experiencing service goverance, managing Sidecar, and gray release of new versions of services.\nThis demo focuses on the powerful traffic control capability of CloudMesh. In the process of gray release, you can precisely control the gray traffic ratio, and monitor the actual traffic trend in CloudMesh:\nThe general gray release function occupies twice capacity in the gray process.\nThe gray release function of CloudMesh does not need to occupy extra capacity in gray release process, and also allows pausing the release process to modify gray ratio multiple times.\nOperation guide For convenience, we have prepared a detailed operation guide for this demo.\nClick here to visit online version.\n","date":-62135596800,"description":"This guide introduces how to quickly deploy applications to CloudMesh, access services, monitor traffic, experience service governance, manage Sidecar, and perform gray release of new versions of services.","dir":"guides/kc-cloud-mesh-demo/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e389a65e6736e909718275cd76505525","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-cloud-mesh-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/guides/kc-cloud-mesh-demo/","summary":"To run this demo, you should sign up an Ant Financial technology account. Please see Ant Finanical Official Site to see more details.\nDemo content Service Mesh applies the communication capabilities between services to the infrastructure, thus decoupling and lightweighting applications.\nHowever, Service Mesh itself is still complex. CloudMesh can easily implement Service Mesh technology by hosting Service Mesh on the cloud.\nWith our workshop, you can easily deploy applications developed in multiple programming languages ​​to CloudMesh, thereby experiencing the capabilities of Service Mesh.","tags":null,"title":"Put Service Mesh into practice with CloudMesh","type":"guides","url":"/sofastack.tech/en/guides/kc-cloud-mesh-demo/","wordcount":199},{"author":null,"categories":null,"content":" This topic comprises four parts:\n Part 1: Install the ACTS IDE visual editor on Intellij IDEA. Part 2: Import the ACTS dependency to a multi-module project. Part 3: Establish the ACTS framework in the test module to manage ACTS test cases. Part 4: Generate the ACTS test script. 1. Install ACTS IDE We recommend that you use Intellij IDEA 2017. For the sake of your data security, please download the ACTS IDE installation package from the following source only: Click to download ACTS IDE.\nLocal installation: Choose Preferences \u0026amp;gt; Plugins. Install the plugin from disk and restart Intellij IDEA. 2. Import the ACTS dependency Before introducing the dependencies, make sure your application is a multi-module project (including the test module). After you import the dependency, ACTS places all test code under the test module for convenient ACTS test case management.\nYou can read the following information based on the actual situation of your application:\nIf your application is a complete multi-module project, you can refer to section 2.1 to import the ACTS dependency. If your application is a multi-module project without a test module, you can refer to section 2.2 to quickly create a test module. If your application is not a multi-module project, you can refer to section 2.3 to quickly create a multi-module project. If you have not created a project yet, you can use SOFABoot to quickly create an application.\n2.1 Multi-module application - with the test module You only need to import acts-bom to the pom.xml file of the test module.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2 Multi-module application - without the test module Here, Intellij IDEA is used to create the submodule.\nRight click the parent project, choose New \u0026amp;gt; Module, and enter the name for the test module, which follows the pattern of appname-test. The step-by-step procedure is illustrated in the following figures.\nStep 1: Create a test module Step 2: Manage the test module Manage the test module that you have created in the pom.xml file under the parent project.\nStep 3: Import the ACTS dependency Find the test module that you just created and import acts-bom to its pom.xml file.\n\u0026amp;lt;! -- Import the pom file that contains SOFABootApplication --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.example\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;example-service\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;! -- Import the ACTS dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.3 Single-module application If you already have a sound single-module SOFABoot application, you can quickly create a multi-module project based on the existing project in the following …","date":-62135596800,"description":"","dir":"projects/sofa-acts/getting-started/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dfc5fb9b394ea14c280568dcb881a8b0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/getting-started/","summary":"This topic comprises four parts:\n Part 1: Install the ACTS IDE visual editor on Intellij IDEA. Part 2: Import the ACTS dependency to a multi-module project. Part 3: Establish the ACTS framework in the test module to manage ACTS test cases. Part 4: Generate the ACTS test script. 1. Install ACTS IDE We recommend that you use Intellij IDEA 2017. For the sake of your data security, please download the ACTS IDE installation package from the following source only: Click to download ACTS IDE.","tags":null,"title":"Quick start","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/getting-started/","wordcount":650},{"author":null,"categories":null,"content":" This topic helps you quickly download, install, and use SOFADashboard on your computer.\nPrepare the environment sofa-dashboard-backend needs to be run in a Java environment. Make sure that it can be used normally in the following runtime environments:\n JDK 1.8+: Download and Configure. Maven 3.2.5+: Download and Configure. sofa-dashboard-frontend uses the Ant Design Pro scaffold. For more information about the frontend environment, see Ant Design.\nInitialize the database MySQL version: 5.6+\n SOFAArk control uses MySQL for resource data storage. You can find the SofaDashboardDB.sql script under the project directory and run this script to initialize database tables.\nZooKeeper ZooKeeper 3.4.x and ZooKeeper 3.5.x\n Service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper, therefore you need to start the ZooKeeper service locally. For more information, see ZooKeeper Document.\nRun the backend project \u0026amp;gt; git clone https://github.com/sofastack/sofa-dashboard.git \u0026amp;gt; cd sofa-dashboard \u0026amp;gt; mvn clean package -DskipTests \u0026amp;gt; cd sofa-dashboard-backend/sofa-dashboard-web/target/ \u0026amp;gt; java -jar sofa-dashboard-web-1.0.0-SNAPSHOT.jar Run the frontend project sofa-dashboard-front is the frontend code-based project of SOFADashboard. It is developed based on the open-source frontend framework antd of Ant Financial.\n\u0026amp;gt; cd sofa-dashboard-front \u0026amp;gt; npm i \u0026amp;gt; npm start ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/quick-start/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fa4c5f48810727f71d675255f19617a3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/quick-start/","summary":"This topic helps you quickly download, install, and use SOFADashboard on your computer.\nPrepare the environment sofa-dashboard-backend needs to be run in a Java environment. Make sure that it can be used normally in the following runtime environments:\n JDK 1.8+: Download and Configure. Maven 3.2.5+: Download and Configure. sofa-dashboard-frontend uses the Ant Design Pro scaffold. For more information about the frontend environment, see Ant Design.\nInitialize the database MySQL version: 5.","tags":null,"title":"Quick start","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/quick-start/","wordcount":186},{"author":null,"categories":null,"content":" This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment. Install Go\u0026amp;rsquo;s build environment. Install dep. See the official installation documentation. Get codes The codes for the MOSN project are hosted in GitHub and can be obtained in the following way:\ngo get mosn.io/mosn If an error occurs when run \u0026amp;ldquo;go get\u0026amp;rdquo;, just create the project manually.\n# Enter src dirctory under GOPATH cd $GOPATH/src # Create mosn.io dirctory mkdir -p mosn.io cd mosn.io # clone MOSN codes git clone git@github.com:mosn/mosn.git cd sofa-mosn The final path of MOSN source codes is $GOPATH/src/mosn.io/mosn.\nImport by using IDE Use the Golang IDE to import the $GOPATH/src/mosn.io/mosn project. Goland is recommended.\nCompile codes In the project root directory, select the following command to compile the MOSN binary file according to your machine type and the environment where you want to execute binary:\nCompile with Docker image\nmake build // compile linux 64bit executable binary non-docker, local compilation\nCompile local executable binary files.\nmake build-local Non-Linux machine compiles Linux 64-bit executable binary files crosswise.\nmake build-linux64 Non-Linux machine compiles Linux 32-bit executable binary files crosswise.\nmake build-linux32 Once compiled, the compiled binary files can be found in the build/bundles/${version}/binary directory.\nCreate image Run the following command to create an image:\nmake image Run test In the project root directory, run the unit test:\nmake unit-test In the project root directory, run the integrate test(slow):\nmake integrate Start MOSN from configuration file ./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; Start MOSN forwarding sample program See the sample project in the examples directory.\nUse MOSN to build a Service Mesh platform See Integrate Istio.\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-setup/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d41615315adb522aa4b84762f113a574","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-setup/","summary":"This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-setup/","wordcount":325},{"author":null,"categories":null,"content":" This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment. Install Go\u0026amp;rsquo;s build environment. Install dep. See the official installation documentation. Get codes The codes for the MOSN project are hosted in GitHub and can be obtained in the following way:\ngo get mosn.io/mosn If an error occurs when run \u0026amp;ldquo;go get\u0026amp;rdquo;, just create the project manually.\n# Enter src dirctory under GOPATH cd $GOPATH/src # Create mosn.io dirctory mkdir -p mosn.io cd mosn.io # clone MOSN codes git clone git@github.com:mosn/mosn.git cd sofa-mosn The final path of MOSN source codes is $GOPATH/src/mosn.io/mosn.\nImport by using IDE Use the Golang IDE to import the $GOPATH/src/mosn.io/mosn project. Goland is recommended.\nCompile codes In the project root directory, select the following command to compile the MOSN binary file according to your machine type and the environment where you want to execute binary:\nCompile with Docker image\nmake build // compile linux 64bit executable binary non-docker, local compilation\nCompile local executable binary files.\nmake build-local Non-Linux machine compiles Linux 64-bit executable binary files crosswise.\nmake build-linux64 Non-Linux machine compiles Linux 32-bit executable binary files crosswise.\nmake build-linux32 Once compiled, the compiled binary files can be found in the build/bundles/${version}/binary directory.\nCreate image Run the following command to create an image:\nmake image Run test In the project root directory, run the unit test:\nmake unit-test In the project root directory, run the integrate test(slow):\nmake integrate Start MOSN from configuration file ./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; Start MOSN forwarding sample program See the sample project in the examples directory.\nUse MOSN to build a Service Mesh platform See Integrate Istio.\n","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-setup/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"cd757e2e2cca38a99b2de1c0be1f6807","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-setup/","summary":"This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-setup/","wordcount":325},{"author":null,"categories":null,"content":" In this document, we will create a Spring Boot project and introduce the basic dependencies of SOFABoot as well as its Health Check expansion capability, to demonstrate how to get started quickly with SOFABoot.\nEnvironment Preparation To use SOFABoot, we need to prepare the basic environment first. SOFABoot depends on the following environment: - JDK7 or JDK8 - Needs to be compiled with Apache Maven 3.2.5 or above\nCreate Project SOFABoot is directly built on Spring Boot, so it can be generated by Spring Boot Generators. In this document, we need to add a web dependency for final view of its effect in the browser.\nAdd SOFABoot dependencies When creating a Spring Boot project, we need to import SOFABoot dependencies. First, extract the \u0026amp;lsquo;zip\u0026amp;rsquo; package of the project generated above and modify the \u0026amp;lsquo;pom.xml\u0026amp;rsquo; file, or the maven project configuration file. Replace\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; as:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Here, ${sofa.boot.version} denotes the SOFABoot version (please refer to release note). Then, add a SOFABoot dependency of Health Check extension and Spring Boot Web Starter.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Finally, configure parameters commonly used in the SOFABoot project in the application.properties file. The spring.application.name parameter is required to name the current application; the logging path specifies the output directory for logging information.\n# Application Name spring.application.name=SOFABoot Demo # logging path logging.path=./logs Advice to refer to the SOFABoot Module document before learn this demo.\nRun it We can import the project into IDE and run the \u0026amp;lsquo;main\u0026amp;rsquo; method in the generated project (generally in the XXXApplication class) to start the application, or we can execute the mvn spring-boot:run command under the project\u0026amp;rsquo;s root directory, which will print the startup logging in the console:\n2018-04-05 21:36:26.572 INFO ---- Initializing ProtocolHandler [\u0026amp;quot;http-nio-8080\u0026amp;quot;] 2018-04-05 21:36:26.587 INFO ---- Starting ProtocolHandler [http-nio-8080] 2018-04-05 21:36:26.608 INFO ---- Using a shared selector for servlet write/read 2018-04-05 21:36:26.659 INFO ---- Tomcat started on port(s): 8080 (http) We can browse http://localhost:8080/sofaboot/versions to view the version summary generated by Maven plugin in SOFABoot. The result is …","date":-62135596800,"description":"","dir":"projects/sofa-boot/quick-start/","fuzzywordcount":1400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7f582b905fde4a56791c03d4dd6b5a57","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/quick-start/","summary":"In this document, we will create a Spring Boot project and introduce the basic dependencies of SOFABoot as well as its Health Check expansion capability, to demonstrate how to get started quickly with SOFABoot.\nEnvironment Preparation To use SOFABoot, we need to prepare the basic environment first. SOFABoot depends on the following environment: - JDK7 or JDK8 - Needs to be compiled with Apache Maven 3.2.5 or above\nCreate Project SOFABoot is directly built on Spring Boot, so it can be generated by Spring Boot Generators.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/quick-start/","wordcount":1381},{"author":null,"categories":null,"content":" SOFATracer integration component list reference:Introduction To SOFATracer, Please pay attention to the SOFATracer version and JDK version of different components when using.\nPrepare Environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: - JDK7 or JDK8 - Apache Maven 3.2.5+ required for compilation\nSamples List The following Samples projects are all SOFABoot projects (also supported in the SpringBoot project). For information on how to create SOFABoot projects, please refer to SOFABoot quick start.\n Component Integration Spring MVC Integration HttpClient Integration DataSource Integration RestTemplate Integration OkHttp Integration SOFARPC Integration Dubbo Integration Spring Cloud OpenFeign Integration Sampling Report Data To Zipkin ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/componentaccess/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"42fbb0f6b6d459b7b04d45cad143d4ff","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/componentaccess/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/componentaccess/","summary":"SOFATracer integration component list reference:Introduction To SOFATracer, Please pay attention to the SOFATracer version and JDK version of different components when using.\nPrepare Environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: - JDK7 or JDK8 - Apache Maven 3.2.5+ required for compilation\nSamples List The following Samples projects are all SOFABoot projects (also supported in the SpringBoot project). For information on how to create SOFABoot projects, please refer to SOFABoot quick start.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/componentaccess/","wordcount":108},{"author":null,"categories":null,"content":" This project demonstrates how to use SOFALookout in SOFABoot and connect to the Actuator of Spring Boot. If you want to connect to Prometheus or other Registry, see the Registry section.\nCreate a SpringBoot (or SofaBoot) project Create a new Spring Boot application (In case of SOFABoot project, import to SOFABoot as described in SOFABoot Documentation - Dependency Management.\nIntroduce Lookout\u0026amp;rsquo;s Starter dependency Introduce the following dependency in pom.xml:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; In case of Spring Boot project, it is required to specify a version.\nCreate a Metrics indicator After completing the introduction of dependencies, you can add the following methods to the startup class in Spring Boot:\n@Autowired private Registry registry; @PostConstruct public void init() { Counter counter = registry.counter(registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;).withTag(\u0026amp;quot;instant\u0026amp;quot;, NetworkUtil.getLocalAddress().getHostName())); counter.inc(); } The above code directly injects a Registry field through @Autowired. Through the Registry field, you can create the corresponding Counter, and then modify the Counter data to generate the Metrics of the SOFALookout.\nAdd configuration item In SOFABoot project, you need to add a configuration item for the application name: spring.application.name=xxx.\nConnect to Spring Boot Actuator After adding a new indicator, you can choose to connect to the Spring Boot Actuator. Then the following dependency is required:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; After adding the above dependency, you can launch the application locally, visit http://localhost:8080/metrics, and you can see the metrics added earlier, as follows:\n\u0026amp;quot;http_requests_total.instant-MacBook-Pro-4.local\u0026amp;quot;: 1, The above codes are at lookout-client-samples-boot, you can Download them as a reference.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-boot/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"27e057f8a8a4ac97f42ea66ca6a17fdd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","summary":"This project demonstrates how to use SOFALookout in SOFABoot and connect to the Actuator of Spring Boot. If you want to connect to Prometheus or other Registry, see the Registry section.\nCreate a SpringBoot (or SofaBoot) project Create a new Spring Boot application (In case of SOFABoot project, import to SOFABoot as described in SOFABoot Documentation - Dependency Management.\nIntroduce Lookout\u0026rsquo;s Starter dependency Introduce the following dependency in pom.xml:","tags":null,"title":"Quick start guide for SOFABoot project","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","wordcount":244},{"author":null,"categories":null,"content":" Quick start for client Common Java Project Add the Maven dependency of the client to the application:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Lookout-client relies on the lookout-reg-server module by default (supports reporting metrics data to the lookout server). If you want to use a different type of registry (such as lookout-reg-prometheus), then add the corresponding dependency.\nBefore starting to use the SOFALookout Client, you must firstly build a global client instance (com.alipay.lookout.client.DefaultLookoutClient).\nLookoutConfig lookoutConfig = new LookoutConfig(); DefaultLookoutClient client = new DefaultLookoutClient(\u0026amp;quot;appName\u0026amp;quot;); // Choose to build the Registry you need to use (if you need multiple registry types, it is recommended to use the same lookoutConfig instance for centralized management). LookoutRegistry lookoutRegistry = new LookoutRegistry(lookoutConfig); // Client can add a registry instance (at least one) after the client is created. client.addRegistry(lookoutRegistry); // (Optional) Uniformly register the metrics of extended modules for the registry instances that have been added or will be added to the client. client.registerExtendedMetrics(); Then get the Registry instance through the client and use it:\n// The registry is a \u0026amp;quot;combination\u0026amp;quot; registry Registry registry = client.getRegistry(); //demo Id id = registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;); Counter counter = registry.counter(id); counter.inc(); For the use of the client, see Project sample.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-java/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5dc476aa21ece4789859f1af598d4445","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","summary":"Quick start for client Common Java Project Add the Maven dependency of the client to the application:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa.lookout\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;lookout-client\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${lookout.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Lookout-client relies on the lookout-reg-server module by default (supports reporting metrics data to the lookout server). If you want to use a different type of registry (such as lookout-reg-prometheus), then add the corresponding dependency.\nBefore starting to use the SOFALookout Client, you must firstly build a global client instance (com.","tags":null,"title":"Quick start guide for common Java project","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","wordcount":197},{"author":null,"categories":null,"content":" For REST，we provide a Filter to support cors now.\nSOFARPC API Usage For users who use SOFARPC API directly，they can add parameters in ServerConfig.\nMap\u0026amp;lt;String,String\u0026amp;gt; parameters=new HashMap\u0026amp;lt;String, String\u0026amp;gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026amp;quot;abc.com,cdf.com\u0026amp;quot;); serverConfig.setParameters(parameters); XML Usage You can add this configuration to application.properties\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-cors/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"549f73920842ebb121abf87566761c47","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-cors/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-cors/","summary":" For REST，we provide a Filter to support cors now.\nSOFARPC API Usage For users who use SOFARPC API directly，they can add parameters in ServerConfig.\nMap\u0026lt;String,String\u0026gt; parameters=new HashMap\u0026lt;String, String\u0026gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026quot;abc.com,cdf.com\u0026quot;); serverConfig.setParameters(parameters); XML Usage You can add this configuration to application.properties\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com ","tags":null,"title":"REST Cors","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-cors/","wordcount":40},{"author":null,"categories":null,"content":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。如果希望有一个通用的 异常处理类，用来处理REST的某中异常类型的信息。可以实现一个REST 的处理类。如下示例是一个拦截SofaRpcException 的通用处理器。\n@PreMatching public class CustomExceptionMapper implements ExceptionMapper\u0026amp;lt;SofaRpcException\u0026amp;gt; { @Override public Response toResponse(SofaRpcException exception) { return Response.status(500).entity(exception.getMessage()).build(); } } 并将该处理器注册到JAXRSProviderManager中，时机可以在Main方法中。具体说明可以参考RESTful-Filter。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-exception/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0ff4ef4139b228537d2ce4d52a213651","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-exception/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-exception/","summary":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。如果希望有一个通用的 异常处理类，用来处理REST的某中异常类型的","tags":null,"title":"REST Exception","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-exception/","wordcount":204},{"author":null,"categories":null,"content":"For REST, we designed a JAXRSProviderManager manager class. It takes effect on the server when the service starts.\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider For the user-defined Filter class, you can call it after the initialization is complete.\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance To register filter, since the custom Filter follows REST specification, you need to implement the following interface:\njavax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.container.ContainerRequestFilter After the REST server is started, if using bare SOFARPC, you need to register filter first before starting the service. In SOFABoot environment, it is similar. The specific encoding method is as follows:\ncom.alipay.sofa.rpc.server.rest.TraceRequestFilter com.alipay.sofa.rpc.server.rest.TraceResponseFilter ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-filter/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"53eb86b2504bf3beda2aca24437d6dab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-filter/","summary":"For REST, we designed a JAXRSProviderManager manager class. It takes effect on the server when the service starts.\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider For the user-defined Filter class, you can call it after the initialization is complete.\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance To register filter, since the custom Filter follows REST specification, you need to implement the following interface:\njavax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.container.ContainerRequestFilter After the REST server is started, if using bare SOFARPC, you need to register filter first before starting the service.","tags":null,"title":"REST filter","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-filter/","wordcount":89},{"author":null,"categories":null,"content":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider 对于用户自定义的 Filter 类，可以在初始化完成后，调用\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance 进行注册，其中自定义的 Filter 遵循 REST 的规范，需要实现如下接口：\njavax.ws.rs.container.ContainerResponseFilter 或者 javax.ws.rs.container.ContainerRequestFilter REST server 启动之后，对于裸 SOFARPC 的使用，需要先注册，再启动服务。对于 SOFABoot 环境下的使用，也是类似的过程，具体的写法可以参考：\ncom.alipay.sofa.rpc.server.rest.TraceRequestFilter com.alipay.sofa.rpc.server.rest.TraceResponseFilter ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-filter/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"53eb86b2504bf3beda2aca24437d6dab","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-filter/","summary":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。 com.alipay.sofa.rpc.server.rest.RestServer#registerProvider 对于用户自定义的 Filter 类，可以在初始化完成后，调用 com.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance 进行注册，其中","tags":null,"title":"REST 自定义 Filter","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-filter/","wordcount":152},{"author":null,"categories":null,"content":" 对于 REST，我们内置了一个跨域 Filter 的支持。\nSOFARPC API 使用 对于使用 SOFARPC API 的用户，可以在 ServerConfig 中添加一个参数表明即可\nMap\u0026amp;lt;String,String\u0026amp;gt; parameters=new HashMap\u0026amp;lt;String, String\u0026amp;gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026amp;quot;abc.com,cdf.com\u0026amp;quot;); serverConfig.setParameters(parameters); XML 方式使用 直接通过配置\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com 即可\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-cors/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"549f73920842ebb121abf87566761c47","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-cors/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-cors/","summary":"对于 REST，我们内置了一个跨域 Filter 的支持。 SOFARPC API 使用 对于使用 SOFARPC API 的用户，可以在 ServerConfig 中添加一个参数表明即可 Map\u0026lt;String,String\u0026gt; parameters=new HashMap\u0026lt;String, String\u0026gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026quot;abc.com,cdf.com\u0026quot;); serverConfig.setParameters(parameters); XML 方式使用 直接通过配置 com.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com 即可","tags":null,"title":"REST 跨域","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-cors/","wordcount":70},{"author":null,"categories":null,"content":"SOFARPC supports RESTful protocol, making it convenient for users to publish an interface in the manner of RESTful. * Basic usage * Custom Filter * Integrate Swagger\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f238d7f58de0c4a0e12d566ea9e09f52","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful/","summary":"SOFARPC supports RESTful protocol, making it convenient for users to publish an interface in the manner of RESTful. * Basic usage * Custom Filter * Integrate Swagger","tags":null,"title":"RESTful","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful/","wordcount":27},{"author":null,"categories":null,"content":"SOFARPC 提供了 RESTful 协议的支持，可以让用户非常方便地将一个接口通过 RESTful 的方式发布出去。 * 基本使用 * 自定义 Filter * 通用异常处理 * 集成 Swagger\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f238d7f58de0c4a0e12d566ea9e09f52","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful/","summary":"SOFARPC 提供了 RESTful 协议的支持，可以让用户非常方便地将一个接口通过 RESTful 的方式发布出去。 * 基本使用 * 自定义 Filter * 通用异常处理 * 集成 Swagger","tags":null,"title":"RESTful 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful/","wordcount":58},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议即使用不同的 Binding 即可，如果需要使用 RESTful 协议，只要将 Binding 设置为 REST 即可。\n发布服务 在定义 RESTful 的服务接口的时候，需要采用 JAXRS 标准的注解在接口上加上元信息，比如下面的接口：\n@Path(\u0026amp;quot;sample\u0026amp;quot;) public interface SampleService { @GET @Path(\u0026amp;quot;hello\u0026amp;quot;) String hello(); } JAXRS 的标准的注解的使用方式可以参考 RESTEasy 的文档。\n 在定义好了接口之后，将接口的实现发布成一个服务，比如，通过 Annotation 的方式：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}) public class RestfulSampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } 如果要通过其他的方式发布服务，请参考 Bolt 协议基本使用。\n通过浏览器访问服务 在发布服务之后，用户可以通过浏览器来直接访问服务，对于上面的服务，访问的地址如下：\nhttp://localhost:8341/sample/hello SOFARPC 的 RESTful 服务的默认端口为 8341。\n引用服务 除了通过浏览器访问 SOFARPC 发布的 RESTful 服务之外，用户也可以通过 SOFARPC 标准的服务引用的方式来引用服务，比如通过 Annotation 的方式：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)) private SampleService sampleService; 如果要使用其他的方式引用服务，请参考 Bolt 协议基本使用。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-basic/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d41f976864ba8f8221f5b5d26f354d1c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-basic/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-basic/","summary":"在 SOFARPC 中，使用不同的通信协议即使用不同的 Binding 即可，如果需要使用 RESTful 协议，只要将 Binding 设置为 REST 即可。 发布服务 在定义 RESTful 的服务接口的时候，需要采用 JAXRS 标准的注","tags":null,"title":"RESTful 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-basic/","wordcount":358},{"author":null,"categories":null,"content":"In SOFABoot, the RPC framework provides some configuration parameters at the application level, and supports application-level parameter configuration, such as port and thread pool, which are bound by Spring Boot\u0026amp;rsquo;s @ConfigurationProperties. The binding attribute class is com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties, and the configuration prefix is as follows:\nstatic final String PREFIX = \u0026amp;quot;com.alipay.sofa.rpc\u0026amp;quot;; Then in the application.properties file, you can currently configure the following options. Also, you can write the codes based on your own coding habits as well as according to the Spring Boot specification, camel, underline and so on.\n#Standalone fault tolerance com.alipay.sofa.rpc.aft.regulation.effective # Whether to enable standalone fault tolerance com.alipay.sofa.rpc.aft.degrade.effective # Whether to enable degradation com.alipay.sofa.rpc.aft.time.window # Time window com.alipay.sofa.rpc.aft.least.window.count # Minimum number of calls com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple # minimum exception rate com.alipay.sofa.rpc.aft.weight.degrade.rate # Degradation rate com.alipay.sofa.rpc.aft.weight.recover.rate # Recovery rate com.alipay.sofa.rpc.aft.degrade.least.weight #Minimum degrading weight com.alipay.sofa.rpc.aft.degrade.max.ip.count # Maximum number of degraded IPs # bolt com.alipay.sofa.rpc.bolt.port # bolt port com.alipay.sofa.rpc.bolt.thread.pool.core.size # Number of bolt core threads com.alipay.sofa.rpc.bolt.thread.pool.max.size # Maximum number of bolt threads com.alipay.sofa.rpc.bolt.thread.pool.queue.size # bolt thread pool queue com.alipay.sofa.rpc.bolt.accepts.size # Number of connections that server allows client to establish # rest com.alipay.sofa.rpc.rest.hostname # rest hostname com.alipay.sofa.rpc.rest.port # rest port com.alipay.sofa.rpc.rest.io.thread.size # Number of rest io threads com.alipay.sofa.rpc.rest.context.path # rest context path com.alipay.sofa.rpc.rest.thread.pool.core.size # Number of rest core threads com.alipay.sofa.rpc.rest.thread.pool.max.size # Maximum number of rest threads com.alipay.sofa.rpc.rest.max.request.size # Maximum rest request size com.alipay.sofa.rpc.rest.telnet # Whether to allow rest telnet com.alipay.sofa.rpc.rest.daemon # Whether to hold the port. If true, exit with the main thread exit # dubbo com.alipay.sofa.rpc.dubbo.port # dubbo port com.alipay.sofa.rpc.dubbo.io.thread.size # dubbo io thread size com.alipay.sofa.rpc.dubbo.thread.pool.max.size # Maximum number of dubbo business threads com.alipay.sofa.rpc.dubbo.accepts.size # Number of connections that server allows client to establish com.alipay.sofa.rpc.dubbo.thread.pool.core.size #Number of dubbo core Threads com.alipay.sofa.rpc.dubbo.thread.pool.queue.size #Maximum number of dubbo threads # registry com.alipay.sofa.rpc.registry.address # Registry center address com.alipay.sofa.rpc.virtual.host # virtual host com.alipay.sofa.rpc.bound.host # bind host …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/application-rpc-config/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"bd19b2ced39a8deb802c13e525093fac","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","summary":"In SOFABoot, the RPC framework provides some configuration parameters at the application level, and supports application-level parameter configuration, such as port and thread pool, which are bound by Spring Boot\u0026rsquo;s @ConfigurationProperties. The binding attribute class is com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties, and the configuration prefix is as follows:\nstatic final String PREFIX = \u0026quot;com.alipay.sofa.rpc\u0026quot;; Then in the application.properties file, you can currently configure the following options. Also, you can write the codes based on your own coding habits as well as according to the Spring Boot specification, camel, underline and so on.","tags":null,"title":"RPC application parameter configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","wordcount":381},{"author":null,"categories":null,"content":" ProviderConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (unique identifier) filterRef Filter configuration example List filter Filter configuration alias separated by commas registry Registry center on the server List methods Method-level configuration Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect. subscribe Whether to subscribe true It depends on the implementation and may not take effect. proxy Proxy type javassist As well as JDK dynamic proxy ref Service interface implementation class server server List, and it can be sent to multiple servers at once delay Time for delaying service publishing Service delay weight Service static weight include Included methods exclude Methods not included dynamic Whether to dynamically register priority Service priority bootstrap Service publishing starter bolt executor Custom thread pool timeout Execution timeout period for server concurrents Concurrent execution request Maximum number of parallel executable requests per method under interface. -1 indicates turning off the concurrent filter, and 0 means that filtering is enabled but not limited cacheRef Result cache implementation class mockRef Mock implementation class mock Whether to enable Mock validation Whether to enable parameter verification (jsr303) compress Whether to start compression false cache Whether to enable result caching false parameters Extra attributes Map\u0026amp;lt;String, String\u0026amp;gt; ConsumerConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (Unique identifier) filterRef Filter configuration example List filter Filter configuration alias List registry Registry center on the server List methods Method-level configuration Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect. subscribe Whether to subscribe true It depends on the implementation and may not take effect. proxy proxy type javassist As well as JDK dynamic proxy protocol Call protocol bolt Currently supports bolt, rest, dubbo directUrl Direct address Directly connected to register generic Whether to generalize calls false connectTimeout Timeout period for connection establishment 3000(cover 5000) disconnectTimeout Timeout period for disconnection 5000(cover …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-common/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2eb5963f4785f5f828f0e15759272971","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration-common/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration-common/","summary":"ProviderConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (unique identifier) filterRef Filter configuration example List filter Filter configuration alias separated by commas registry Registry center on the server List methods Method-level configuration Map\u0026lt;String, MethodConfig\u0026gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect.","tags":null,"title":"RPC publishing and reference configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration-common/","wordcount":1118},{"author":null,"categories":null,"content":" ProviderConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 uniqueId 服务标签（唯一标识元素） filterRef 过滤器配置实例 List filter 过滤器配置别名 多个用逗号隔开 registry 服务端注册中心 List methods 方法级配置 Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization 序列化协议 hessian2 register 是否注册 true 取决于实现，可能不生效。 subscribe 是否订阅 true 取决于实现，可能不生效。 proxy 代理类型 javassist 还有JDK动态代理 ref 服务接口实现类 server 服务端 List，可以一次发到多个服务端 delay 服务延迟发布时间 服务延迟 weight 服务静态权重 include 包含的方法 exclude 不包含的方法 dynamic 是否动态注册 priority 服务优先级 bootstrap 服务发布启动器 bolt executor 自定义线程池 timeout 服务端执行超时时间 concurrents 并发执行请求 接口下每方法的最大可并行执行请求数，配置-1关闭并发过滤器，等于0表示开启过滤但是不限制 cacheRef 结果缓存实现类 mockRef Mock实现类 mock 是否开启Mock validation 是否开启参数验证(jsr303) compress 是否启动压缩 false cache 是否启用结果缓存 false parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; ConsumerConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 uniqueId 服务标签（唯一标识元素） filterRef 过滤器配置实例 List filter 过滤器配置别名 List registry 服务端注册中心 List methods 方法级配置 Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization 序列化协议 hessian2 register 是否注册 true 取决于实现，可能不生效。 subscribe 是否订阅 true 取决于实现，可能不生效。 proxy 代理类型 javassist 还有JDK动态代理 protocol 调用的协议 bolt 目前支持bolt，rest，dubbo directUrl 直连地址 直连后register generic 是否泛化调用 false connectTimeout 建立连接超时时间 3000(cover 5000) disconnectTimeout 断开连接等等超时时间 5000(cover 10000) cluster 集群模式 failover connectionHolder 连接管理器实现 all loadBalancer 负载均衡算法 random lazy 是否延迟建立长连接 false sticky 是否使用粘性连接 false 跳过负载均衡算法使用上一个地址 inJVM 是否转为JVM调用 true JVM发现服务提供者，转为走本地 check 是否检查强依赖 false 无可用服务端启动失败 heartbeat 心跳间隔 30000 客户端给服务端发心跳间隔。取决于实现，可能不生效。 reconnect 重连间隔 10000 客户端重建端口长连接的间隔。取决于实现，可能不生效。 router 路由器配置别名 List routerRef 路由器配置实例 List bootstrap 服务引用启动器 bolt addressWait 等待地址获取时间 -1 取决于实现，可能不生效。 timeout 调用超时时间 3000(cover 5000) retries 失败后重试次数 0 跟集群模式有关，failover读取此参数。 invokeType 调用类型 sync onReturn 并发执行请求数 接口下每方法的最大可并行执行请求数，\n配置-1关闭并发过滤器，等于0表示开启过滤但是不限制 cacheRef 结果缓存实现类 mockRef Mock实现类 cache 是否启用结果缓存 false mock 是否开启Mock validation 是否开启参数验证 基于JSR303 compress 是否启动压缩 false parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; rejectedExecutionPolicy 回调线程池满拒绝策略 DISCARD DISCARD：默认丢弃，CALLER_RUNS：IO 线程继续执行任务，CALLER_HANDLE_EXCEPTION：IO 线程执行异常回调任务 @since 5.8.1 MethodConfig 属性 名称 默认值 备注 name 方法名 timeout 调用超时时间 null retries 失败后重试次数 null invokeType 调用类型 null validation 是否开启参数验证 null 基于JSR303 onReturn 返回时调用的SofaResponseCallback null 用于实现Callback等 concurrent 并发执行请求数 null 接口下每方法的最大可并行执行请求数，配置-1关闭并发过滤器，等于0表示开启过滤但是不限制。 validation 是否开启参数验证 null compress 是否启动压缩 null parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; ServerConfig id Id 默认值 备注 protocol 协议 bolt 目前支持bolt，rest，dubbo host 主机 0.0.0.0 port 端口 12200 默认端口 bolt:12200, rest:8341, h2c:12300, dubbo:20880 contextPath …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-common/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2eb5963f4785f5f828f0e15759272971","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration-common/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration-common/","summary":"ProviderConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置","tags":null,"title":"RPC 发布订阅配置","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration-common/","wordcount":1868},{"author":null,"categories":null,"content":"在 SOFABoot 的使用场景下，RPC 框架在应用层面，提供一些配置参数，支持的应用级别的参数配置，如端口，线程池等信息，都是通过 Spring Boot的@ConfigurationProperties 进行的绑定。绑定属性类是com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties，配置前缀是\nstatic final String PREFIX = \u0026amp;quot;com.alipay.sofa.rpc\u0026amp;quot;; 那么在 application.properties 文件中，目前可以配置以下几个选项。其中使用者也可以根据自己的编码习惯，按照 Spring Boot的规范，按照驼峰，中划线等进行书写。\n单机故障剔除\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.aft.regulation.effective 是否开启单机故障剔除功能 Boolean false com.alipay.sofa.rpc.aft.degrade.effective 是否开启降级 Boolean false com.alipay.sofa.rpc.aft.time.window 时间窗口 Long 10 com.alipay.sofa.rpc.aft.least.window.count 最小调用次数 Long 10 com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple 最小异常率 Double 6.0 com.alipay.sofa.rpc.aft.weight.degrade.rate 降级速率 Double 0.05 com.alipay.sofa.rpc.aft.weight.recover.rate 恢复速率 Double 2.0 com.alipay.sofa.rpc.aft.degrade.least.weight 降级最小权重 Integer 1 com.alipay.sofa.rpc.aft.degrade.max.ip.count 最大降级 ip数量 Integer 2 Bolt\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.bolt.port bolt 端口 Integer 优先生效的是environment中是否设置rpc_tr_port，然后才是此处设置的值。默认12200 com.alipay.sofa.rpc.bolt.thread.pool.core.size bolt 核心线程数 Integer 20 com.alipay.sofa.rpc.bolt.thread.pool.max.size bolt 最大线程数 Integer 200 com.alipay.sofa.rpc.bolt.thread.pool.queue.size bolt 线程池队列 Integer 0 com.alipay.sofa.rpc.bolt.accepts.size bolt 服务端允许客户端建立的连接数 Integer 必须大于0，默认100000 com.alipay.sofa.rpc.bolt.process.in.io.thread bolt 服务端业务处理是否直接在worker中处理 Boolean false com.alipay.sofa.rpc.enable.swagger 是否开启针对bolt协议的swagger文档 Boolean false Rest\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.rest.hostname rest hostname String “” com.alipay.sofa.rpc.rest.port rest port Integer 8341 com.alipay.sofa.rpc.rest.io.thread.size rest io 线程数 Integer 机器cpu核数* 2 com.alipay.sofa.rpc.rest.context.path rest context path String “” com.alipay.sofa.rpc.rest.thread.pool.core.size rest 核心线程数 Integer 目前不可配置，默认20 com.alipay.sofa.rpc.rest.thread.pool.max.size rest 最大线程数 Integer 200 com.alipay.sofa.rpc.rest.max.request.size rest 最大请求大小 Integer 10485760 com.alipay.sofa.rpc.rest.telnet 是否允许 rest telnet Boolean true com.alipay.sofa.rpc.rest.daemon 是否hold住端口，true的话随主线程退出而退出 String true com.alipay.sofa.rpc.rest.allowed.origins 跨域设置 String “” com.alipay.sofa.rpc.rest.swagger 是否开启针对rest协议的swagger文档 boolean false Dubbo\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.dubbo.port dubbo port Integer 20880 com.alipay.sofa.rpc.dubbo.io.thread.size dubbo io 线程大小 Integer 0 com.alipay.sofa.rpc.dubbo.thread.pool.max.size dubbo 业务线程最大数 Integer 200 com.alipay.sofa.rpc.dubbo.accepts.size dubbo 服务端允许客户端建立的连接数 Integer 必须大于0，默认100000 com.alipay.sofa.rpc.dubbo.thread.pool.core.size dubbo 核心线程数 Integer 目前不可配置，默认20 com.alipay.sofa.rpc.dubbo.thread.pool.queue.size dubbo 线程池队列大小 Integer 目前不可配置，默认0 Http\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.http.port http port Integer 12400 com.alipay.sofa.rpc.http.thread.pool.core.size http 核心线程数 Integer 20 com.alipay.sofa.rpc.http.thread.pool.max.size http …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/application-rpc-config/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"bd19b2ced39a8deb802c13e525093fac","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/application-rpc-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/application-rpc-config/","summary":"在 SOFABoot 的使用场景下，RPC 框架在应用层面，提供一些配置参数，支持的应用级别的参数配置，如端口，线程池等信息，都是通过 Spring Boot的@Config","tags":null,"title":"RPC 应用参数配置","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/application-rpc-config/","wordcount":1496},{"author":null,"categories":null,"content":" Raft 新特性 Strong Leader 更强的领导形式 例如日志条目只会从领导者发送到其他服务器, 这很大程度上简化了对日志复制的管理 Leader Election 使用随机定时器来选举领导者 用最简单的方式减少了选举冲突的可能性 Membership Change 新的联合一致性 (joint consensus) 方法 复制状态机 1. 复制状态机通过日志实现 每台机器一份日志 每个日志条目包含一条命令 状态机按顺序执行命令 2.应用于实际系统的一致性算法一般有以下特性 确保安全性 高可用性 不依赖时序保证一致性 一条命令能够尽可能快的在大多数节点对一轮RPC调用响应时完成 Paxos 算法的不足 算法复杂度高, 较难理解 工程复杂度高, 难以在实际环境中实现 Raft 设计原则 概念分解 Leader election Log replication Membership changes 通过减少状态数量将状态空间简化 日志不允许出现空洞, 并且 raft 限制了日志不一致的可能性 使用随机化时钟简化了领导选举的算法 Raft 一致性算法 State (状态) 在所有服务器上持久存储的(响应RPC之前稳定存储的)\n currentTerm 服务器最后知道的任期号(从0开始递增) votedFor 在当前任期内收到选票的候选人Id(如果没有就为null) log[] 日志条目, 每个条目包含状态机要执行的命令以及从Leader收到日志时的任期号 在所有服务器上不稳定存在的\n commitIndex 已知被提交的最大日志条目索引 lastApplied 已被状态机执行的最大日志条目索引 在Leader服务器上不稳定存在的\n nextIndex[] 对于每一个follower, 记录需要发给他的下一条日志条目的索引 matchIndex[] 对于每一个follower, 记录已经复制完成的最大日志条目索引 AppendEntries RPC (日志复制) 由leader通过RPC向follower复制日志, 也会用作heartbeat\n入参\n term Leader任期号 leaderId Leader id, 为了能帮助客户端重定向到Leader服务器 prevLogIndex 前一个日志的索引 prevLogTerm 前一个日志所属的任期 entries[] 将要存储的日志条目列表(为空时代表heartbeat, 有时候为了效率会发送超过一条) leaderCommit Leader已提交的日志条目索引 返回值\n term 当前的任期号, 用于leader更新自己的任期号 success 如果其他follower包含能够匹配上prevLogIndex和prevLogTerm的日志, 那么为真 接收日志的follower需要实现的\n 如果term \u0026amp;lt; currentTerm, 不接受日志并返回false 如果索引prevLogIndex处的日志的任期号与prevLogTerm不匹配, 不接受日志并返回false 如果一条已存在的日志与新的冲突(index相同但是term不同), 则删除已经存在的日志条目和他之后所有的日志条目 添加任何在已有日志中不存在的条目 如果leaderCommit \u0026amp;gt; commitIndex, 则设置commitIndex = min(leaderCommit, index of last new entry) RequestVote RPC (投票请求) 入参\n term 候选人的任期号 candidateId 发起投票请求的候选人id lastLogIndex 候选人最新的日志条目索引 lastLogTerm 候选人最新日志条目对应的任期号 返回值\n term 目前的任期号, 用于候选人更新自己 voteGranted 如果候选人收到选票, 那么为true 接收日志的follower需要实现的\n 如果term \u0026amp;lt; currentTerm, 那么拒绝投票并返回false 如果votedFor为空或者与candidateId相同, 并且候选人的日志和自己一样新或者更新, 那么就给候选人投票并返回true 服务器要遵守的规则 所有服务器: 如果commitIndex \u0026amp;gt; lastApplied, 那么将lastApplied自增并把对应日志log[lastApplied]应用到状态机 如果RPC请求或响应包含一个term T大于currentTerm, 那么将currentTerm赋值为T并立即切换状态为follower Follower: 无条件响应来自candidate和leader的RPC 如果在选举超时之前没收到任何来自leader的AppendEntries RPC或RequestVote RPC, 那么自己转换状态为candidate Candidate: 转变为candidate之后开始发起选举 currentTerm自增 \u0026amp;ndash;\u0026amp;gt; 重置选举计时器 \u0026amp;ndash;\u0026amp;gt; 给自己投票 \u0026amp;ndash;\u0026amp;gt; 向其他服务器发起RequestVote RPC 如果收到了来自大多数服务器的投票, 转换状态成为leader 如果收到了来自新leader的AppendEntries RPC(Heartbeat), 转换状态为follower 如果选举超时, 开始新一轮的选举 Leader: 一旦成为leader, 向其他所有服务器发送空的AppendEntries RPC(Heartbeat), 并在空闲时间重复发送以防选举超时 如果收到来自客户端的请求, 向本地日志追加条目并向所有服务器发送AppendEntries RPC, 在收到大多数响应后将该条目应用到状态机并回复响应给客户端 如果leader上一次收到的日志索引大于一个follower的nextIndex, 那么通过AppendEntries RPC将nextIndex之后的所有日志发送出去; 如果发送成功, 将follower的nextIndex和matchIndex更新, 如果由于日志不一致导致失败, 那么将nextIndex递减并重新发送 如果存在一个N \u0026amp;gt; commitIndex和半数以上的matchIndex[i] \u0026amp;gt;= N并且log[N].term == currentTerm, 将commitIndex赋值为N 一致性算法总结 Election Safety 选举安全原则: 一个任期内最多允许有一个leader Leader Append-Only 只增加日志原则: Leader只会增加日志条目, 永远不会覆盖或删除自己的日志 Log Matching 日志匹配原则: 如果两个日志在相同的的索引位置上并且任期号相同, 那么就可以认为这个日志从头到这个索引位置之间的条目完 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/raft-introduction/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b811e803d23b40da67657798801f8b51","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/raft-introduction/","publishdate":"0001-01-01T00:00:00Z","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-jraft/raft-introduction/","summary":"Raft 新特性 Strong Leader 更强的领导形式 例如日志条目只会从领导者发送到其他服务器, 这很大程度上简化了对日志复制的管理 Leader Election 使用随机定时器来选举领导者 用最简单","tags":null,"title":"Raft 算法解读","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/raft-introduction/","wordcount":5182},{"author":null,"categories":null,"content":"TBD\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-register-agent/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"da6c96fadd94eedcf961d50ce7b00600","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","summary":"TBD","tags":null,"title":"Register Agent","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","wordcount":1},{"author":null,"categories":null,"content":" Register agent TBD\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-register-agent/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"da6c96fadd94eedcf961d50ce7b00600","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","summary":"Register agent TBD","tags":null,"title":"Register agent","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","wordcount":3},{"author":null,"categories":null,"content":" Related articles ISSUES User manual Chinese introductory article: Ant communication framework practices ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/related-links/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"6844d2a639b69fa3128132b8631f33e3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/related-links/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/related-links/","summary":" Related articles ISSUES User manual Chinese introductory article: Ant communication framework practices ","tags":null,"title":"Related articles","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/related-links/","wordcount":12},{"author":null,"categories":null,"content":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.\n","date":-62135596800,"description":"","dir":"projects/mosn/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"62efb8e40401ab4612bcccaa6e942c97","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/mosn/release-notes/","summary":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/mosn/release-notes/","wordcount":5},{"author":null,"categories":null,"content":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.\n","date":-62135596800,"description":"","dir":"projects/occlum/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"6b9dec1dd8c196e43129ab36a046a84f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/occlum/release-notes/","summary":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/occlum/release-notes/","wordcount":5},{"author":null,"categories":null,"content":" Release history For more information, refer to: https://github.com/sofastack/sofa-ark/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-release/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"994c3569ea416ee5b0dea253f08af6be","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","summary":"Release history For more information, refer to: https://github.com/sofastack/sofa-ark/releases","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","wordcount":8},{"author":null,"categories":null,"content":"## Release history For more information, refer to: https://github.com/sofastack/sofa-jarslink/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-release/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4554e362f42cbc42b9408d9507cdf689","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","summary":"## Release history For more information, refer to: https://github.com/sofastack/sofa-jarslink/releases","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","wordcount":9},{"author":null,"categories":null,"content":"For more information, see https://github.com/sofastack/sofa-dashboard/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/release-node/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3c8e6985123810c9692f47cc56b50081","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/release-node/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/release-node/","summary":"For more information, see https://github.com/sofastack/sofa-dashboard/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/release-node/","wordcount":5},{"author":null,"categories":null,"content":" 1.2.5 April 1, 2019\n Bugs fixed Fixed the conflict between jmh and the unit test code. Fixed the installation failure bug that would occur when the snapshot is too large. This bug may affect the addition of new nodes. Features Optimized part of the LogManagerImpl code to reduce CPU usage. Corrected some spelling errors. Breaking changes None We strongly recommend that you upgrade to this version.\n1.2.4 March 20, 2019\n Bugs fixed Fixed stale read of lease read in a circumstance. Modified part of timestamps to monotonic time. Fixed the problem of the replicator being blocked in one circumstance. Resolved directory creation failures for some unit tests on Windows. Resolved process crashes caused by improper rocksdb options settings on Windows. Features Made the RocksDB options available for users to set. Optimized the pre-vote process, and used the lease mechanism to avoid the current term\u0026amp;rsquo;s interruption on a disconnected node (caused by network partitioning or no writes in the cluster for a long time) to improve the system availability. Updated SOFABolt to 1.5.3. Modified ReadWriteLock of the BallotBox to StampedLock, and provided the OptimisticRead implementation. Fixed a few spelling errors. Breaking changes None Acknowledgements (in no particular order) @pifuant @huangyunbin @shiftyman @slievrly 1.2.3 March 5, 2019 Released the first open source version.\n1.2.2 February 21, 2019\n Bugs fixed Made PeerId and Endpoint immutable, to avoid concurrency problems on APIs such as getLeaderId. Upgraded sofa-common to 1.0.12. The earlier version 1.0.9 was not released to the public GitHub repository. Features The JRaft-RheaKV implemented auto range split. When placementDriver(pd) is enabled, the pd can calculate and issue the range split command based on state information reported by each node. When pd is disabled, RheaKVCliService is provided to allow users to manually trigger range split by using the CLI service. Provided LogExceptionHandler generic support. Added MetricThreadPoolExecutor (an updated version of LogThreadPoolExecutor) to print the uncaught exception log and record the time for task.run() and replaced all ThreadPoolExecutors in JRaft with MetricThreadPoolExecutor to record time-consumption metric statistics. This metric can be used as an important reference for adjusting the thread pool configuration in actual application. Breaking changes Removed the reset method of Endpoint/PeerId. V1.2.1 January 28, 2019\n Bugs fixed Fixed a bug that RaftGroupService may mistakenly disable the shared rpcServer. Fixed the bug of the apply-order change caused by batch write of the RheaKV state machine. Fixed the time usage API error. Features Merged the code of duplicate functions of Jraft and RheaKV. Reduced memory usage of the log replication request handling process on followers. Optimized the synchronized conf read/write of the RouteTable to the read/write lock. Implemented lock safe with fencing and the automatic lease …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/release-log/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"9e24fb74a3cda6a600252b01f8a85db9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/release-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/release-log/","summary":"1.2.5 April 1, 2019\n Bugs fixed Fixed the conflict between jmh and the unit test code. Fixed the installation failure bug that would occur when the snapshot is too large. This bug may affect the addition of new nodes. Features Optimized part of the LogManagerImpl code to reduce CPU usage. Corrected some spelling errors. Breaking changes None We strongly recommend that you upgrade to this version.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/release-log/","wordcount":855},{"author":null,"categories":null,"content":"For more information, see https://github.com/sofastack/sofa-registry/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d92dddf77bbbd6078f3f96ba2224a53d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/release-notes/","summary":"For more information, see https://github.com/sofastack/sofa-registry/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/release-notes/","wordcount":5},{"author":null,"categories":null,"content":"To learn more, see https://github.com/sofastack/sofa-rpc/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ab7d46caa6906863103b77b742ec7e84","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/release-notes/","summary":"To learn more, see https://github.com/sofastack/sofa-rpc/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/release-notes/","wordcount":5},{"author":null,"categories":null,"content":" This example demonstrates how to remotely report link data to Zipkin by configuring SOFATracer in an application that integrates SOFATracer.\nThe following examples demonstrate how to use them in SOFABoot/SpringBoot projects and non-SOFABoot/SpringBoot projects, respectively.\nPrepare environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: + JDK7 or JDK8 + Apache Maven 3.2.5+ required for compilation\nIntroduce SOFABoot After creating a Spring Boot project, you need to introduce the SOFABoot dependency. First, you need to unzip the zip package of the Spring Boot project generated above and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more about SOFABoot versions, see Release notes.\nAdd SOFATracer starter \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Application configuration Finally, add the properties to be used by SOFATracer under the project\u0026amp;rsquo;s application.properties file, including spring.application.name to indicate the name of the current application; logging.path to specify the output directory of the log.\n# Application Name spring.application.name=SOFATracerReportZipkin # logging path logging.path=./logs # open zipkin report com.alipay.sofa.tracer.zipkin.enabled=true # specify zipkin server address com.alipay.sofa.tracer.zipkin.baseUrl=http://localhost:9411 Configure Zipkin Dependencies Considering that Zipkin\u0026amp;rsquo;s data reporting capability is not the ability of SOFATracer to be enabled by default,it‘s desirable to add the following Zipkin data reporting dependencies when using SOFATracer for data reporting:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.zipkin2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.11.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.reporter2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin-reporter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.7.13\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt;\t Start the Zipkin server Start the Zipkin server to receive the link data reported by SOFATracer and display it. Zipkin Server can be configured with reference to this document.\nRunning You can import the project into IDE and run the main method in the project to start the application. In the console, you can see the log about startup as follows:\n2018-05-12 13:12:05.868 INFO 76572 --- …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/report-to-zipkin/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d28d192386829452262116de9c32b570","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","summary":"This example demonstrates how to remotely report link data to Zipkin by configuring SOFATracer in an application that integrates SOFATracer.\nThe following examples demonstrate how to use them in SOFABoot/SpringBoot projects and non-SOFABoot/SpringBoot projects, respectively.\nPrepare environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: + JDK7 or JDK8 + Apache Maven 3.2.5+ required for compilation\nIntroduce SOFABoot After creating a Spring Boot project, you need to introduce the SOFABoot dependency.","tags":null,"title":"Report data to Zipkin","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","wordcount":465},{"author":null,"categories":null,"content":" RestTemplate Integration In this document will demonstrate how to use SOFATracer to track of RestTemplate, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- SOFABoot version unified management --\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs Add a Controller that provides RESTFul services In the project, provide a simple Controller, for example:\n@RestController public class SampleController { private final AtomicLong counter = new AtomicLong(0); @RequestMapping(\u0026amp;quot;/rest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; rest() { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); return map; } @RequestMapping(\u0026amp;quot;/asyncrest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; asyncrest() throws InterruptedException { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); Thread.sleep(5000); return map; } } Construct the RestTemplate in API model to initiate a call to the RESTful service above Construct a RestTemplate synchronous call instance RestTemplate restTemplate = SofaTracerRestTemplateBuilder.buildRestTemplate(); ResponseEntity\u0026amp;lt;String\u0026amp;gt; responseEntity = restTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;, String.class); Construct a RestTemplate asynchronous call instance AsyncRestTemplate asyncRestTemplate = SofaTracerRestTemplateBuilder .buildAsyncRestTemplate(); ListenableFuture\u0026amp;lt;ResponseEntity\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; forEntity = asyncRestTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/asyncrest\u0026amp;quot;, String.class); Get the RestTemplate in an automatic injection @Autowired RestTemplate restTemplate; Run the project Start the SOFABoot app and see the log in the console as follows:\n2018-10-24 10:45:28.683 INFO 5081 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-10-24 10:45:28.733 INFO 5081 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-10-24 10:45:28.736 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Started RestTemplateDemoApplication in 2.163 seconds (JVM running for 3.603) Successful call：\n2018-10-24 10:45:28.989 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-resttemplate/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"8b66d6ad488bd59ecbf113b37825d58e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","summary":"RestTemplate Integration In this document will demonstrate how to use SOFATracer to track of RestTemplate, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;!-- SOFABoot version unified management --\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.properties file, including spring.","tags":null,"title":"RestTemplate Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","wordcount":434},{"author":null,"categories":null,"content":" RestTemplate Log Format SOFATracer integrates RestTemplate and outputs the requested link log data format. The default is JSON data format.\nRestTemplate digest log（resttemplate-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.app remote app name baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-10-24 10:45:28.977\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8b3154034912878910015081\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:188,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RestTemplate stat log（resttemplate-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success ; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-10-24 10:46:28.769\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5009,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-resttemplate/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c52c919080b467801700a8a1f156c513","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","summary":"RestTemplate Log Format SOFATracer integrates RestTemplate and outputs the requested link log data format. The default is JSON data format.\nRestTemplate digest log（resttemplate-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.","tags":null,"title":"RestTemplate log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","wordcount":172},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 RestTemplate 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括 spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=TestTemplateDemo # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleController { private final AtomicLong counter = new AtomicLong(0); @RequestMapping(\u0026amp;quot;/rest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; rest() { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); return map; } @RequestMapping(\u0026amp;quot;/asyncrest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; asyncrest() throws InterruptedException { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); Thread.sleep(5000); return map; } } 以 API 方式构造 RestTemplate 发起一次对上文的 RESTful 服务的调用 构造 RestTemplate 同步调用实例 RestTemplate restTemplate = SofaTracerRestTemplateBuilder.buildRestTemplate(); ResponseEntity\u0026amp;lt;String\u0026amp;gt; responseEntity = restTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;, String.class); 构造 RestTemplate 异步调用实例 AsyncRestTemplate asyncRestTemplate = SofaTracerRestTemplateBuilder .buildAsyncRestTemplate(); ListenableFuture\u0026amp;lt;ResponseEntity\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; forEntity = asyncRestTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/asyncrest\u0026amp;quot;, String.class); 以自动注入的方式获取 RestTemplate @Autowired RestTemplate restTemplate; 运行 启动 SOFABoot 应用，将会在控制台中看到启动打印的日志：\n2018-10-24 10:45:28.683 INFO 5081 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-10-24 10:45:28.733 INFO 5081 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-10-24 10:45:28.736 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Started RestTemplateDemoApplication in 2.163 seconds (JVM running for 3.603) 调用成功：\n2018-10-24 10:45:28.989 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Async Response is {\u0026amp;quot;count\u0026amp;quot;:2} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : test finish ....... 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要进行配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── resttemplate-digest.log ├── resttemplate-stat.log ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 示例中通过构造两个 RestTemplate（一个同步一个异步） 发起对同一个 RESTful 服务的调用，调用完成后可以在 restTemplate-digest.log 中看到类似如下的日志： …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-resttemplate/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8b66d6ad488bd59ecbf113b37825d58e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","summary":"在本文档将演示如何使用 SOFATracer 对 RestTemplate 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt;","tags":null,"title":"RestTemplate 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","wordcount":610},{"author":null,"categories":null,"content":" SOFATracer 集成 RestTemplate 后输出请求的链路数据格式，默认为 JSON 数据格式。\nRestTemplate 摘要日志（resttemplate-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SimpleAsyncTaskExecutor-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5009ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RestTemplate 统计日志（resttemplate-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:34:04.130\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5009,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-resttemplate/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c52c919080b467801700a8a1f156c513","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","summary":"SOFATracer 集成 RestTemplate 后输出请求的链路数据格式，默认为 JSON 数据格式。 RestTemplate 摘要日志（resttemplate-digest.log） 以 JSON 格式输出的数据，相应 key 的","tags":null,"title":"RestTemplate 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","wordcount":342},{"author":null,"categories":null,"content":" SOFARPC supports a framework-level retry strategy when the cluster mode is FailOver (SOFARPC uses FailOver mode by default). Retry is only initiated if there is a framework-level exception or a timeout exception on the server. If the business itself throws an exception, the service will not be called again. SOFARPC does not perform any retry by default.\n Note: Although the system will retry calling in case of timeout exception, the server still needs to guarantee the idempotency of the service. Otherwise there may be risks.\n Use XML If you subscribe to the service using XML, you can set the number of retries by setting the retries parameter of sofa:global-attrs:\n\u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;retriesServiceReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.retries.RetriesService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs retries=\u0026amp;quot;2\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation If you are using Annotation, you can set the retries attribute of @SofaReferenceBinding annotation:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, retries = 2)) private SampleService sampleService; Use API in Spring environment If you are using the API in Spring environment, you can call the setRetries method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setRetries(2); Use API in non-Spring environment If you are using the bare API of SOFARPC directly in non-Spring environment, you can call the setRetries method of ConsumerConfig:\nConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt;(); consumerConfig.setRetries(2); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/retry-invoke/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d60b44aa8f1b49ab6c1bbc55593a91da","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","summary":"SOFARPC supports a framework-level retry strategy when the cluster mode is FailOver (SOFARPC uses FailOver mode by default). Retry is only initiated if there is a framework-level exception or a timeout exception on the server. If the business itself throws an exception, the service will not be called again. SOFARPC does not perform any retry by default.\n Note: Although the system will retry calling in case of timeout exception, the server still needs to guarantee the idempotency of the service.","tags":null,"title":"Retry strategy","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","wordcount":205},{"author":null,"categories":null,"content":" SOFAJRaft 2019 年 4-7 月开发计划 (p1) Telnet 服务（或其他，越简单越好），作为一种在线排查问题的手段，主要提供以下几个功能 Raft_stat: 以 node 节点为 root，能列出大部分甚至所有相关 stat Metrics: 展示当前节点最新的所有 metrics 指标度量(虽然日志里有相关数据但是相对分散) (p1) 扩展点：引入 SPI 机制，先列出几个扩展点 LogStorage LogEntry codec RaftMetaStorage Metric 指标度量 (p1) 对于 multi-raft-group 场景，提供一个 manual rebalance api 用于平衡各个节点的 leaders 数量 (p2) 文档国际化 (p2) 添加 Learner 角色，只用于同步数据不参与投票 (p3) RheaKV 完成 jepsen 验证\n ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/road-map/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d39cc6e615d623f8dfc320f32dcbdfa6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/road-map/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/road-map/","summary":"SOFAJRaft 2019 年 4-7 月开发计划 (p1) Telnet 服务（或其他，越简单越好），作为一种在线排查问题的手段，主要提供以下几个功能 Raft_stat: 以 node 节点为 root，能列出大部分甚至所有","tags":null,"title":"Road Map","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/road-map/","wordcount":194},{"author":null,"categories":null,"content":" Roadmap Version 1.5.1 Fixed code style problems in the project: https://github.com/alipay/sofa-bolt/issues/85 Fixed known bugs in the project: https://github.com/alipay/sofa-bolt/issues/82 The RPC layer supports message list dispatching from the I/O thread: https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 Overall goal Unify lifecycle APIs for all components Extract and incorporate network component APIs Converge configuration methods and enhance configuration scalability Unify lifecycle APIs for all components In the current Bolt version, APIs of lifecycle management components are named inconsistently, for example:\n ReconnectManager does not need startup or initialization, and the disabling method is stop. The initialization method for DefaultConnectionMonitor of is start, and the disabling method is destroy. The initialization method forRpcClient init, and the disabling method is shutdown. The initialization method forRpcTaskScanner is start, and the disabling method is shutdown. We plan to unify lifecycle APIs of all components in V1.6.0:\n For components that are subject to lifecycle management, which require initialization before use and must release resources after use, their startup/shutdown APIs are to be unified. Extract and incorporate network component APIs Network operations of Bolt are mainly performed by using the remoting class, which is provided as an abstract class. We plan to converge methods of this class, and provide them in the form of APIs in the future. There are a few advantages of doing so:\n Standardized usage Stable service Convenient internal code iteration Taking the ReconnectManager as an example. It provides the public addCancelUrl method, which is not called in the Bolt project. This may cause problems:\n IDE will give a warning. Users may get confused on whether they should delete this method. We plan to solve the these problems in V1.6.0 by extracting a set of stable APIs, which are convenient for users to use, helpful to improve code readability, and can lay a solid foundation for future iterations.\nConverge configuration methods and enhance configuration scalability Currently, Bolt supports the following configuration methods:\n ProtocolSwitch: supports protocol configuration (enabling or disabling CRC validation), and creates configuration objects by static means. GlobalSwitch: offers instance-level configuration, and offers GlobalSwitch configuration items to every AbstractConfigurableInstance. The default value is taken from the SystemProperty, and the configuration can be adjusted through an API. ConfigItem: enumerates Netty-related configuration items that cannot be inherited or extended before you modify the source code. ConfigManager: reads SystemProperty configurations by static means. Configs: defines the configuration item names and specifies their default values. Generally, Bolt\u0026amp;rsquo;s configuration items look to be loose and scattered and are hard for users to extend their usage. …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-roadmap/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3d4eac90b5c8e657d14eb885ab1f9a92","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","summary":"Roadmap Version 1.5.1 Fixed code style problems in the project: https://github.com/alipay/sofa-bolt/issues/85 Fixed known bugs in the project: https://github.com/alipay/sofa-bolt/issues/82 The RPC layer supports message list dispatching from the I/O thread: https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 Overall goal Unify lifecycle APIs for all components Extract and incorporate network component APIs Converge configuration methods and enhance configuration scalability Unify lifecycle APIs for all components In the current Bolt version, APIs of lifecycle management components are named inconsistently, for example:","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","wordcount":539},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c4532d11cef15d8fe3ff5e04c7b08f90","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","summary":"","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","wordcount":0},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f1d0bf15efba08535f9574e1c8344cab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","summary":"","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","wordcount":0},{"author":null,"categories":null,"content":" Development plans of SOFAJRaft from April to July 2019 (p1) Implement the Telnet service (or similar equivalents, the simpler the better) as an online troubleshooting means. It should be able to provide the following functions: Raft_stat: List most or all stats of a Raft node. Metrics: Uniformly display the latest values of all metrics for the current node (the related data is scattered in the log). (p1) Extension points: introduce the SPI mechanism. Some of the extension points are listed as follows: LogStorage LogEntry codec RaftMetaStorage Metrics (p1) Provide a manual rebalance API for the multi-raft-group scenario to balance the number of leaders on each node. (p2) Translate the document into multiple languages. (p2) Add a learner role that only replicates data and does not vote. (p3) Complete jepsen tests for RheaKV. ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/road-map/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d39cc6e615d623f8dfc320f32dcbdfa6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/road-map/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/road-map/","summary":"Development plans of SOFAJRaft from April to July 2019 (p1) Implement the Telnet service (or similar equivalents, the simpler the better) as an online troubleshooting means. It should be able to provide the following functions: Raft_stat: List most or all stats of a Raft node. Metrics: Uniformly display the latest values of all metrics for the current node (the related data is scattered in the log). (p1) Extension points: introduce the SPI mechanism.","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/road-map/","wordcount":132},{"author":null,"categories":null,"content":" Task list Some of the existing internal features will be available in subsequent iterations.\nThe features that have been implemented are listed in the following table. You are welcome to claim the tasks and make contributions.\n Task type Task Degree of difficulty Claimant and time Planned completion time Progress Related issues Documentation Document translation Low Code Flexible persistent connection management Low #56 Code etcd registry center implementation Medium @wynn5a\n2018-6 #153 Code eureka registry center implementation Medium @liufeiit\n2018-4 #52 Code gRPC support High #57 Code CXF protocol High #58 Code TLS support High Version iteration Plan v5.5.0 Support JSON serialization Support H2 TLS Implement flexible connection pool Integrate Hystrix Support Consul registry center v5.6.0 Support GRPC communication layer Support etcd registry center Support SOFAMesh Implement BOLT version negotiation and CRC verification v5.7.0 Support Telnet built-in instructions Support SpringBoot 2.0 Support Mock function Support encryption v5.8.0 Support authorization Support SofaRegistry Support Reactive ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/roadmap/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"6064fc180911f520f6d1590b88595693","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/roadmap/","summary":"Task list Some of the existing internal features will be available in subsequent iterations.\nThe features that have been implemented are listed in the following table. You are welcome to claim the tasks and make contributions.\n Task type Task Degree of difficulty Claimant and time Planned completion time Progress Related issues Documentation Document translation Low Code Flexible persistent connection management Low #56 Code etcd registry center implementation Medium @wynn5a","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/roadmap/","wordcount":152},{"author":null,"categories":null,"content":" Tasks The following table lists the features that have not yet been implemented. We encourage you to claim the tasks and make a contribution.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document SOFADashboard Parameter Configuration Guide Simple Code Support for SOFARegistry Medium Code Support for Docker Medium Code Support for Kubernetes Medium Code Support for Apollo Medium Code Frontend optimization Medium ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a740c874742b504de9011b07f3a4ddb5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/roadmap/","summary":" Tasks The following table lists the features that have not yet been implemented. We encourage you to claim the tasks and make a contribution.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document SOFADashboard Parameter Configuration Guide Simple Code Support for SOFARegistry Medium Code Support for Docker Medium Code Support for Kubernetes Medium Code Support for Apollo Medium Code Frontend optimization Medium ","tags":null,"title":"Roadmap and task claim","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/roadmap/","wordcount":67},{"author":null,"categories":null,"content":" Roadmap Tasks We have some internal implementations of some new features, which will be released along with the iterations when sorted out.\nFeatures that are not implemented yet are listed in the following table. We encourage you to claim the tasks and contribute to SOFARegistry.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document Document Translation Low Code Support for Spring Cloud Medium Code Data self-check High Code Blacklist filtering Medium Code SOFARegistry Dashboard High Code Support for other microservice frameworks Medium Code Support for Docker \u0026amp;amp; Kubernetes High Code Multi-language client support High Version iteration plan v5.3.0 Support for Spring Cloud Data self-check Blacklist filtering v5.4.0 SOFARegistry Dashboard Support for other microservice frameworks v5.5.0 Support for Docker \u0026amp;amp; Kubernetes Multi-language client support ","date":-62135596800,"description":"","dir":"projects/sofa-registry/roadmap/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b0ab45d52ba3eb7db590a4f5e4197c9e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/roadmap/","summary":"Roadmap Tasks We have some internal implementations of some new features, which will be released along with the iterations when sorted out.\nFeatures that are not implemented yet are listed in the following table. We encourage you to claim the tasks and contribute to SOFARegistry.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document Document Translation Low Code Support for Spring Cloud Medium Code Data self-check High Code Blacklist filtering Medium Code SOFARegistry Dashboard High Code Support for other microservice frameworks Medium Code Support for Docker \u0026amp; Kubernetes High Code Multi-language client support High Version iteration plan v5.","tags":null,"title":"Roadmap and task claims","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/roadmap/","wordcount":128},{"author":null,"categories":null,"content":" AntCoreTest (ACTS) is a white-box test framework developed by Ant Financial based on years\u0026amp;rsquo; testing knowledge and experience with the financial-level distributed architecture for the purpose of providing enterprises with a highly efficient, precise, and automated interface testing services. In addition to general testing capabilities such as data-driven testing provided by conventional open source frameworks like TestNG, ACTS offers new features such as model-driven testing, visualized editing, and a standard process engine to assist engineers with efficient and high quality test case compilation as well as standard and precise test validation for interface testing.\nACTS is a next generation testing framework based on the data model-driven testing engine. ACTS is applicable to context environments that require the integration of TestNg and Spring. ACTS uses the YAML file as the data carrier and builds data model drivers upon it, providing features such as the all-in-one editor, precise validation, and efficient test case management to significantly improve testing efficiency.\nOperating principle Upon the start of the test script, ActsDataProvider starts the tested method (the method annotated by @Test), loads the corresponding test case data file (YAML file), and converts the data into corresponding PrepareData objects.\n When runTest starts running, it passes PrepareData and test case names to ACTS. ACTS then assembles such information into the ActsRuntimeContext class, transmits it in the entire process, and initializes the TestUnitHandler. The running period of the runTest process method consists of the following stages:\n | Action | Method | | :\u0026amp;mdash; | :\u0026amp;mdash; | | Clear | clear(actsRuntimeContext) | | Prepare | prepare(actsRuntimeContext) | | Execute | execute(actsRuntimeContext) | | Check | check(actsRuntimeContext) |\nDescription:\n Clear: Clean up the preparation data and validation data to avoid the negative impact of dirty data on the test script. Prepare: Prepare data such as DB data. Execute: Call the tested method, and capture the corresponding information, such as responses and exception messages. Check: Validate the corresponding information such as the responses, DB data, and exception messages based on the test data. Features ACTS provides the following features:\n2.1 All-in-one editor The ACTS framework separates the test data from the test code, and provides the visual editor ACTS IDE. ACTS IDE can help you quickly enter, view, and manage the test case data, which significantly reduces repetitive coding.\n2.2 Precise validation To improve data fill-in efficiency and reduce omission of check points among the expectation data, such as response expectations and database expectations, the ACTS framework provides a run and backfill function. In addition, ACTS uses validation rule flags to implement precise validation of the expectation data.\n2.3 Flexible scalability ACTS provides a rich variety of APIs, which are encapsulated …","date":-62135596800,"description":"","dir":"projects/sofa-acts/overview/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ac57071cd0d40a63359d476d05344c61","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/overview/","summary":"AntCoreTest (ACTS) is a white-box test framework developed by Ant Financial based on years\u0026rsquo; testing knowledge and experience with the financial-level distributed architecture for the purpose of providing enterprises with a highly efficient, precise, and automated interface testing services. In addition to general testing capabilities such as data-driven testing provided by conventional open source frameworks like TestNG, ACTS offers new features such as model-driven testing, visualized editing, and a standard process engine to assist engineers with efficient and high quality test case compilation as well as standard and precise test validation for interface testing.","tags":null,"title":"SOFAActs overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/overview/","wordcount":556},{"author":null,"categories":null,"content":" ACTS（AntCoreTest）源于蚂蚁金服多年金融级分布式架构工程的测试实践的积累与沉淀，是一款白盒测试框架，旨在为企业提供高效、精细化的接口自动化测试。 与现有的诸如 TestNG 等开源框架相比，ACTS 除了具备通用的数据自动化驱动等测试能力外，还具有契合快速的互联网发展和复杂的分布式金融系统特点的模型驱动、可视化编辑和标准流程引擎等新特性，可辅助工程师高效、高质量地完成接口测试用例编写以及标准化精准化测试验证。\nACTS 是基于数据模型驱动测试引擎执行的的新一代测试框架（如图1所示），适配 TestNg+Spring 的测试上下文环境，以 YAML 为数据载体并在此上构建数据模型驱动，实现了一站式编辑、精细化校验和高效用例管理等，可以有效提高测试效率。\n运行原理 测试脚本启动的时，ActsDataProvider 会启动被测方法（被 @Test 注解的方法），加载对应的用例数据文件(以 YAML 文件承载)，然后转换成对应的 PrepareData 对象； runTest 开始执行时会传入 PrepareData 和用例名称，ACTS 根据这些信息组装出 ActsRuntimeContext 上下文并在整个过程中传递，同时初始化 TestUnitHandler 测试处理器。runTest -\u0026amp;gt; process 方法执行期包含如下四个子流程：\n 说明 方法 清理 clear(actsRuntimeContext) 准备 prepare(actsRuntimeContext) 执行 execute(actsRuntimeContext) 检查 check(actsRuntimeContext) 方法功能说明： + 清理阶段：清理准备数据、校验数据，防止脏数据对测试脚本产生影响； + 准备阶段：准备 DB 数据等； + 执行阶段：调用被测方法，捕获返回结果和异常等信息； + 检查阶段：根据测试数据，校验返回结果、DB 数据和异常信息等内容。\n功能描述 ACTS 提供了以下能力：\n2.1 一站式编辑 框架实现了测试数据与测试代码的分离，同时配套提供可视化编辑器 ACTS IDE，通过 ACTS IDE 可以快速地录入、查看和管理用例数据，有效减少重复性编码。\n2.2 精细化校验 为了提高返回结果、DB 数据等期望数据的填写效率和减少检验点遗漏，框架提供了预跑返填功能；同时在 ACTS 校验规则标签的标记下，实现期望 DB 数据、期望结果等数据的精细化校验。\n2.3 灵活可扩展 ACTS 提供了丰富的 API ，其封装于 ActsRuntimeContext 类中，借助 API 可快速获取和设置自定义参数、用例入参、期望结果等，满足用户对用例数据的自定义操作；\n同时，框架的 ActsTestBase 测试基类对外暴露各个执行阶段方法，包括 prepare，execute，check，clear 等，例如在测试类中通过重写 process 方法可将整个测试脚本重新编排。\n2.4 统一配置能力 配置文件中提供丰富的配置能力以定制化框架的个性需求。\n应用场景 基于 SOFABoot 搭建的应用，在 Intellij IDEA 开发环境下快速编写和执行接口测试用例。推荐使用 Intellij IDEA 2017 以便能更好地兼容 ACTS IDE。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/overview/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ac57071cd0d40a63359d476d05344c61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/overview/","summary":"ACTS（AntCoreTest）源于蚂蚁金服多年金融级分布式架构工程的测试实践的积累与沉淀，是一款白盒测试框架，旨在为企业提供高效、精细化","tags":null,"title":"SOFAActs 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-acts/overview/","wordcount":998},{"author":null,"categories":null,"content":" SOFAArk offers a variety of methods to support multi-application (module) consolidation and deployment, including command line-based control and API-based control. SOFAArk control is an implementation of SOFADashboard\u0026amp;rsquo;s control over APIs. SOFAArk control is implemented by pushing commands to and parsing commands in ZooKeeper.\nSOFAArk control mainly provides the following functions:\n Plug-in registration: registers the ark-biz package with SOFADashboard as basic data processors. Application association: binds the ark-biz package with host applications. Plug-in details: On the plug-in details page, you can view the information about all host applications that are associated with the current ark-biz package, as well as the status information of the ark-biz package in these host applications. Command push: On the plug-in details page, you can push some commands for specific applications and IP addresses, such as install and uninstall. When these commands are written to a ZooKeeper node, all host applications that listen to this node will parse the commands and perform related operations. Plug-in registration Register the ark-biz package with SOFADashboard:\nEnter basic information of the plug-in\nAfter successful registration, the plug-in is displayed on the module list as follows.\nApplication association Click Associate application in the Actions column of a plug-in on the module list to associate it with an application.\nClick Associate application in the Actions column of the plug-in to associate it with an application.\nPlug-in details Click Details in the Actions column of a plug-in to view all apps and app instances associated with the current plug-in.\n Version switch After switching the plug-in to V2.0.0, the status information is empty, because the plug-in V2.0.0 has not been installed in the host application.\nCommand push SOFADashboard supports command push in two dimensions:\n Application-based command push, where all instances of the specified application listen to this command IP-based and group-based command push for single-IP address scenarios IP-based command push Click Install. The page is refreshed after about 1s to 1.5s.\n Application-based command push is similar.\n ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/ark-console/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b42cffbb8e55a4c47412e49de0e9b228","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/ark-console/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/ark-console/","summary":"SOFAArk offers a variety of methods to support multi-application (module) consolidation and deployment, including command line-based control and API-based control. SOFAArk control is an implementation of SOFADashboard\u0026rsquo;s control over APIs. SOFAArk control is implemented by pushing commands to and parsing commands in ZooKeeper.\nSOFAArk control mainly provides the following functions:\n Plug-in registration: registers the ark-biz package with SOFADashboard as basic data processors. Application association: binds the ark-biz package with host applications.","tags":null,"title":"SOFAArk control","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/ark-console/","wordcount":321},{"author":null,"categories":null,"content":" SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献；\n在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin） 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz) 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz 基于以上能力，SOFAArk 可以帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\n场景 包冲突 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError, NoSuchMethodError 等；实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法，统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突；这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题；如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题； OSGI 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGI 框架太过臃肿，功能繁杂；为了解决包冲突问题，引入 OSGI 框架，有牛刀杀鸡之嫌，且反而使工程变得更加复杂，不利于开发；\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如果工程需要引入两个三方包：A 和 B，但是 A 需要依赖版本号为 0.1 的 C 包，而恰好 B 需要依赖版本号为 0.2 的 C 包，且 C 包的这两个版本无法兼容：\n此时，即可使用 SOFAArk 解决该依赖冲突问题；只需要把 A 和版本为 0.1 的 C 包一起打包成一个 Ark 插件，然后让应用工程引入该插件依赖即可；\n合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n静态合并部署 SOFAArk 提供了静态合并部署能力，在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成可执行 Fat Jar 时，可以将其他应用 Biz 包一并打入，启动时，则会根据优先级依次启动各应用。每个 Biz 使用独立的 BizClassLoader 加载，不需要考虑相互依赖冲突问题，Biz 之间则通过 SofaService/SofaReference JVM 服务进行交互。\n动态合并部署 动态合并部署区别于静态合并部署最大的一点是，运行时通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态合并部署的设计理念图如下：\n无论是静态还是动态合并部署都会有宿主应用（master biz）的概念, 如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主应用不允许被卸载，一般而言，宿主应用会作为流量入口的中台系统，具体的服务实现会放在不同的动态 Biz 中，供宿主应用调用。宿主应用可以使用 SOFAArk 提供的客户端 API 实现动态应用的部署和卸载。除了 API, SOFAArk 提供了 Config Plugin，用于对接配置中心（目前支持 Zookeeper），运行时接受动态配置；Config Plugin 会解析下发的配置，控制动态应用的部署和卸载。\n原理 SOFAArk 包含三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下:\n在介绍这三个概念之前，先介绍上述 Ark 包概念；Ark 包是满足特定目录格式要求的可运行 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将单个或多个应用打包成标准格式的 Ark 包；使用 java -jar 命令即可在 SOFAArk 容器之上启动所有应用；Ark 包通常包含 Ark Container、Ark Plugin 和 Ark Biz；以下我们针对这三个概念简单做下名词解释：\n Ark Container: SOFAArk 容器，负责 Ark 包启动运行时的管理；Ark Plugin 和 Ark Biz 运行在 SOFAArk 容器之上；容器具备管理插件和应用的功能；容器启动成功后，会自动解析 classpath 包含的 Ark Plugin 和 Ark Biz 依赖，完成隔离加载并按优先级依次启动之；\n Ark Plugin: Ark 插件，满足特定目录格式要求的 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-plugin-maven-plugin 可以将一个或多个普通的 Java jar 打包成一个标准格式的 Ark Plugin；Ark Plugin 会包含一份配置文件，通常包括插件类导入导出配置、资源导入导出配置、插件启动优先级等；运行时，SOFAArk 容器会使用独立的 PluginClassLoader加载插件，并根据插件配置构建类加载索引表、资源加载索引表，使插件和插件之 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-readme/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cdb6729fc7a63954b7559c8ea319f550","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","summary":"SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献； 在大型软件开发过程中，通常会推荐底层","tags":null,"title":"SOFAArk 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","wordcount":2577},{"author":null,"categories":null,"content":" 【SOFAChannel 分享】SOFAArk 类隔离框架设计原理 https://www.bilibili.com/video/BV1gS4y1i7Fg/?spm_id_from=333.999.0.0\n\n【SOFA 开源四周年分享】Serverless 技术简介 https://www.bilibili.com/video/BV1nU4y1B7u3/?spm_id_from=333.999.0.0\n\n【SOFA Meetup 云原生技术沙龙】SOFAServerless 体系助力业务极速研发 https://www.bilibili.com/video/BV1Ld4y1P7VK/?spm_id_from=333.999.0.0\n\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-public-presentation/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c460ccc2d706f49e26eb4f74d5468d63","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","summary":"【SOFAChannel 分享】SOFAArk 类隔离框架设计原理 https://www.bilibili.com/video/BV1gS4y1i7Fg/?spm_id_from=333.999.0.0 【SOFA 开源四周年分享】Serverless 技术简介 https://www.bilibili.com/video/BV1nU4y1B7u3/?spm_id_from=333.999.0.0 【SOFA Meetup 云原生技","tags":null,"title":"SOFAArk 相关公开分享材料","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","wordcount":99},{"author":null,"categories":null,"content":" SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAARK 管控是 SOFADashboard 针对 API 的管控的一种实现。通过面向 Zookeeper 进行命令的推送和命令的解析执行。\nSOFAArk 管控主要包括以下功能：\n 插件注册：将 ark-biz 插件注册到 SOFADashboard，作为基础数据 关联应用：将 ark-biz 插件与宿主应用进行绑定 插件详情：通过插件详情页，可以看下当前 ark-biz 插件下所有关联的宿主应用信息，以及宿主应用中的ark-biz 状态信息 命令推送：插件详情页，可以针对应用维度、分组维度、IP 维度 推送一些指令，比如 install、uninstall 等等，当这些命令被写入到 Zookeeper 的某个节点上时，所有监听此节点的 宿主应用均会解析此指令，并进行相关的操作 插件管理 插件注册 将 ark-biz 插件注册到 SOFADashboard：\n插件删除 添加插件版本 插件版本 biz 包路径 删除版本 关联应用 点击模块列表操作菜单栏中的关联应用，可以将一个应用与插件进行绑定：\n动态管控 点击插件列表后面的 详情 按钮，可以查看当前插件下所有应用信息和应用实例信息。\n命令推送 SOFADashboard 提供三种维度的命令推送\n 基于应用维度，当前应用所有的实例都会监听到此命令变更 基于IP 维度，分组维度的单 ip 场景 动态模块详情 点击 状态详细按钮，左侧栏将会展开 \u0026amp;ldquo;抽屉\u0026amp;rdquo; 展示详情状态数据\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/ark-console/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b42cffbb8e55a4c47412e49de0e9b228","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/ark-console/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/ark-console/","summary":"SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAARK 管控是 SOFADashboard 针对 API 的管控的一种实现。通过面","tags":null,"title":"SOFAArk 管控","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/ark-console/","wordcount":541},{"author":null,"categories":null,"content":" SOFAArk 的配置目录不是必须存在，如果需要，统一放在工程根目录 ${baseDir}/conf/ark 下，执行 sofa-ark-maven-plugin 打包，将会自动将该目录下的配置打包至 Ark 包，例如 Ark 包目录为：\n. ├── META-INF │ └── MANIFEST.MF ├── SOFA-ARK │ ├── biz │ │ └── demo-0.0.1-SNAPSHOT-ark-biz.jar │ └── container │ └── sofa-ark-all-0.6.0-SNAPSHOT.jar ├── com │ └── alipay │ └── sofa │ └── ark │ ├── ... │ └── conf └── ark ├── bootstrap-dev.properties ├── bootstrap.properties └── log └── logback-conf.xml 注意事项：如果应用中包含 SOFAArk 配置，打包时需要注意 baseDir 配置，用于指定工程根目录，具体参考文档\n上述 conf/ark 目录中可以配置 SOFAArk 容器启动配置以及日志配置，下面介绍配置的使用.\nconf/ark/bootstrap.properties 是 SOFAArk 容器默认启动配置文件，配置内容包括：日志配置、plugin 激活和钝化配置、biz 激活和钝化配置.\n日志配置 SOFAArk 容器日志内部实现使用 logback, 日志配置参数包括： + logging.path \u0026amp;gt; 容器日志目录根路径，这里只影响 SOFAArk 容器日志路径，不影响应用日志，应用自身日志由自身配置决定，默认打印在 ${user.admin}/logs 目录\n logging.level.com.alipay.sofa.ark \u0026amp;gt; 设置 SOFAArk 容器日志级别，默认为 INFO\n logging.config.com.alipay.sofa.ark \u0026amp;gt; 指定自定义日志配置文件名，用于覆盖 SOFAArk 容器自带的日志配置文件。建议自定义配置文件放在 conf/ark/log 目录中\n sofa.middleware.log.com.alipay.sofa.ark.console \u0026amp;gt; 配置容器日志是否打印在 console，默认为 false.\n sofa.middleware.log.com.alipay.sofa.ark.console.level \u0026amp;gt; 配合上述配置项使用，如果打印在 console ，该配置项用于配置 SOFAArk 容器打印在 console 的日志级别\n 插件配置 ark.plugin.active.include \u0026amp;gt; 指定激活哪些插件，多个插件使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认激活 Ark 包中所有的插件。\n ark.plugin.active.exclude \u0026amp;gt; 指定排除哪些插件，多个插件使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认为空\n 注：如果同时配置了这两个属性，以 ark.plugin.active.include 为准\nbiz配置 ark.biz.active.include \u0026amp;gt; 指定激活哪些 Biz，多个 Biz 使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认激活 Ark 包中所有的 Biz.\n ark.biz.active.exclude \u0026amp;gt; 指定排除哪些 Biz，多个 Biz 使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认为空\n com.alipay.sofa.ark.master.biz \u0026amp;gt; 指定宿主 Biz 名，如果 Ark 包中只有一个 Biz，则不用设置，默认设置为宿主 Biz; 否则需要显示设置\n 注：如果同时配置了前两个属性，以 ark.biz.active.include 为准\n动态配置 SOFAArk 提供了对接 Zookeeper 的插件，目前用于动态接收 Biz 指令，目前只支持 Zookeeper，配置格式如下：\ncom.alipay.sofa.ark.config.address=zookeeper://ip:port?key1=value1\u0026amp;amp;key2=value2 特别注意，SOFAArk 有一个默认的逻辑，如果用户配置了 com.alipay.sofa.ark.config.address，且 Ark 包中打入了多个 Biz，则只会启动宿主应用(master biz)；这样做的原因是如果配置了动态配置，SOFAArk 会优先根据动态配置控制 Biz 的部署。\nProfile 机制 默认 SOFAArk 容器使用 bootstrap.properties 配置，实际开发中，可能根据运行环境加载不同的配置，SOFAArk 提供了 profile 机制. 指定 profile 值，SOFAArk 容器会加载 bootstrap-${profile}.properties 配置文件。指定 profile 的配置有两种方式： + 通过 -D VM 参数传入，例如：-Dark.profile=dev,dev2 多个值使用 \u0026amp;lsquo;,\u0026amp;rsquo; 隔开。 + 通过应用启动参数传入，例如：java -jar demo-executable-ark.jar -Aprofile=dev,dev2 多个值使用 \u0026amp;lsquo;,\u0026amp;rsquo; 隔开。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-config/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"70dd9c389e65ee3f89573cf93bd466ec","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","summary":"SOFAArk 的配置目录不是必须存在，如果需要，统一放在工程根目录 ${baseDir}/conf/ark 下，执行 sofa-ark-maven-plugin 打包，将会自动将该目录下的配置打包至 Ark 包，例如 Ark 包目录为： . ├── META-INF │ └─","tags":null,"title":"SOFAArk 配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","wordcount":1036},{"author":null,"categories":null,"content":" 背景 SOFAArk 框架包含有三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下：\n每次应用启动时，首先运行 Ark 包，Ark Container 优先启动，容器自动解析 Ark 包中含有的 Ark Plugin 和 Ark Biz，并读取他们的配置信息，构建类和资源的加载索引表；然后使用独立的 ClassLoader 加载并按优先级配置依次启动；需要指出的是，Ark Plugin 优先 Ark Biz 被加载启动。 详细介绍可阅读： SOFAArk 介绍\n在三层概念的基础上，衍生出复杂的类加载机制，如图：\n详细介绍可阅读：Ark 容器类加载机制\n问题一 由于Ark Plugin的存在，插件在依赖层面的强管控，造成了一些问题 - 业务使用的依赖是被插件管控导出的，但是插件管控导出的版本与业务实际期望的版本不符（比如插件管控的版本是 1.0，而业务需要的是 2.0）。 - 插件对于依赖的强管控，直接堵住了业务扩展插件能力的路；也存在部分依赖，当业务引入时会直接报错（其package 被导出了，但是依赖不在插件中），那么对于业务来说就只能等框架发版解决。 - 业务接入成本，学习成本较高，问题排查困难，需要非常熟悉Ark类加载机制。 - 由于管控依赖的增长，Ark Plugin难以持续维护\n问题二 另外，由于Ark Container先于master biz启动，master biz的启动入口和springboot/sofaboot不一致，导致Ark master biz的的启动在研发运维中需要定制镜像，定制启动入口，造成研发运维困难。\nSOFAArk2.0 针对这些问题，我们尝试从框架层面去优化三层结构，沉淀出了SOFAArk2.0方案，整体优化思路和原则是 Ark Master Biz保持和原生springboot/sofaboot保持一致，弱化复杂的Ark Plugin类管控机制，将Ark Plugin与master biz合并。\nSOFAArk2.0方案整体优化点： - 弱化Ark Plugin层，改为普通pom依赖； - Ark master biz和原生的springboot/sofaboot应用启动方式，类加载方式保持一致； - 优化Ark Biz启动速度；\n升级方式 版本升级 SOFAArk版本号第一位为大版本号，当为1.x.x时为SOFAArk1.0版，当为2.x.x时是SOFAArk2.0版，当前2.0版本已正式release，Release-Notes\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;sofa.ark.version\u0026amp;gt;1.1.6\u0026amp;lt;/sofa.ark.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; 改为\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;sofa.ark.version\u0026amp;gt;2.0.0\u0026amp;lt;/sofa.ark.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; 打包插件 在SOFAArk1.0中使用sofa-ark-maven-plugin打包，在SOFAArk2.0中采用spring-boot原生打包插件spring-boot-maven-plugin打包\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 替换为：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 运行启动 方式一：IDEA启动 本地启动需要加上启动参数\n -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二：命令行启动 Ark包是可执行Jar，可直接使用Java -jar的方式启动，先使用 mvn clean package 进行打包，打包得到 ${bizName}-${bizVersion}-ark-biz.jar，命令行启动\n java -jar -Dsofa.ark.embed.enable=true …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-migration-guide/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b924edd10ef0e13f7220cff7c019d137","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","summary":"背景 SOFAArk 框架包含有三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下： 每次应用启动时，首先运行 Ark 包，Ark Container 优先启动，容器自动解析 Ark 包中含有的 Ark","tags":null,"title":"SOFAArk2.0 升级","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","wordcount":1266},{"author":null,"categories":null,"content":" Introduction SOFABolt is a network communication framework implemented based on Netty and developed by Ant Finance.\n Netty was developed to let Java programmers focus more on the implementation of network communication-based business logic, and not worry excessively about network low-level NIO implementation or network problems that are difficult to debug. SOFABolt was developed to let middleware developers focus more on the implementation of products\u0026amp;rsquo; functional performance, and not on making the communication framework\u0026amp;rsquo;s wheels over and over again. Bolt takes its name from a Disney movie character. Bolt is a light, easy-to-use, high-performance, and flexibly scalable communication framework based on the Netty best practices. In the past few years, we have solved a lot of problems in terms of network communication for microservices and message oriented middleware. We have accumulated a lot of experience and have been constantly optimizing and improving our solutions. We hope that our solutions can be incorporated into the SOFABolt base component to serve more network communication scenarios. At present, SOFABolt has already been put to use in many Ant Middleware products, such as microservice products (SOFARPC), message queue, distributed transactions, distributed switches, and configuration centers.\nMultiple languages supported node Python cpp ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/overview/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5ee08df7c4bbd2c3be846e16f3bc81b1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/overview/","summary":"Introduction SOFABolt is a network communication framework implemented based on Netty and developed by Ant Finance.\n Netty was developed to let Java programmers focus more on the implementation of network communication-based business logic, and not worry excessively about network low-level NIO implementation or network problems that are difficult to debug. SOFABolt was developed to let middleware developers focus more on the implementation of products\u0026rsquo; functional performance, and not on making the communication framework\u0026rsquo;s wheels over and over again.","tags":null,"title":"SOFABolt overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/overview/","wordcount":196},{"author":null,"categories":null,"content":" 功能架构 SOFABolt　的基础功能： 基础通信功能 ( remoting-core ) 基于 Netty 高效的网络 IO 与线程模型运用 连接管理 (无锁建连，定时断链，自动重连) 基础通信模型 ( oneway，sync，future，callback ) 超时控制 批量解包与批量提交处理器 心跳与 IDLE 事件处理 协议框架 ( protocol-skeleton ) 命令与命令处理器 编解码处理器 心跳触发器 私有协议定制实现 - RPC 通信协议 ( protocol-implementation ) RPC 通信协议的设计 灵活的反序列化时机控制 请求处理超时 FailFast 机制 用户请求处理器 ( UserProcessor ) 双工通信 用法1 将 SOFABolt 用作一个远程通信框架，使用者可以不用关心如何实现一个私有协议的细节，直接使用我们内置的 RPC 通信协议。可以非常简单的启动客户端与服务端，同时注册一个用户请求处理器，即可完成远程调用。同时，像连接管理、心跳等基础功能特性都默认可以使用。 当前支持的调用类型如下图所示：\n 示例 Demo 请参考我们的 用户手册 用法2 将 SOFABolt 用作一个协议框架，使用者可以复用基础的通信模型、协议包含的接口定义等基础功能。然后根据自己设计的私有协议自定义 Command 类型、Command 处理器、编解码处理器等。如下图所示，RPC 和消息的 Command 定义结构：\n","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-functions/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fde29139cbd8b786326a6479e52814dd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","summary":"功能架构 SOFABolt 的基础功能： 基础通信功能 ( remoting-core ) 基于 Netty 高效的网络 IO 与线程模型运用 连接管理 (无锁建连，定时断链，自动重连) 基础通信模型 ( oneway，","tags":null,"title":"SOFABolt 功能介绍","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","wordcount":450},{"author":null,"categories":null,"content":" 参与贡献 开放代码允许在签署协议之后,提交贡献代码.\n版权协议 对 SOFABolt 代码的修改和变更，需要遵守版权协议。\n准备工作 贡献代码前需要先了解git工具的使用和GitHub网站的使用。 git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git协作流程 GitHub 贡献代码流程 提issue 不论你是修复 Bolt 的bug还是新增 Bolt 的功能，在你提交代码之前，在 Bolt 的GitHub上提交一个 issue, 描述你要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突,产生重复工作。Bolt 的维护人员会对你提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提issue后，点击左上角的fork按钮，复制一份 Bolt 主干代码到你的代码仓库。\n拉分支 Bolt 所有修改都在分支上进行，修改完后提交 pull request ， 在code review 后由项目维护人员 merge 到主干。 因此，在获取源码步骤介绍后，你需要：\n 下载代码到本地,这一步你可以选择git/https方式. git clone https://github.com/sofastack/sofa-bolt.git 拉分支准备修改代码 git branch add_xxx_feature 执行完上述命令后，你的代码仓库就切换到相应分支了。执行如下命令可以看到你当前分支： git branch -a 如果你想切换回主干，执行下面命令: git checkout -b master 如果你想切换回分支，执行下面命令： git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 想直接从github上拉取分支到本地 git clone -b branchname https://xxx.git 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 Bolt 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行 mvn clean package 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在bugs，而新的代码已经解决了这些bugs. 你可以用如下命令运行所有测试\nmvn clean test 也可以通过IDE来辅助运行.\n其它注意事项 请保持你编辑的代码的原有风格,尤其是空格换行等. 对于无用的注释, 请直接删除 对逻辑和功能不容易被理解的地方添加注释. 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地: git commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到github上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面你是通过fork来做的,那么那么这里的 origin 是push到你的代码仓库，而不是 Bolt 的代码仓库.\n提交合并代码到主干的请求 在你的代码提交到GitHub后，你就可以发送请求来把你改好的代码合入 Bolt 主干代码了。此时你需要进入你的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是主干master, 系统会通知 Bolt 的人员，Bolt 人员会 review 你的代码，符合要求后就会合入主干，成为 Bolt 主干代码的一部分。\n代码review 在你提交代码后，你的代码会被指派给维护人员review,请保持耐心。如果在数天后，仍然没有人对你的提交给予任何回复，可以在pull request下面留言,并@对应的人员. 对于代码review的意见会提交到对应issue。如果觉得建议是合理的，也请你把这些建议更新到你的补丁中。\n合并代码到主干 在代码 Bolt 通过后，就由 Bolt 维护人员操作合入主干了。这一步不用参与,review合并之后,你会收到合并成功的提示.\nContributing to SOFABolt SOFABolt is released under the Apache 2.0 license, and follows a very standard Github development process, using Github tracker for issues and merging pull requests into master . If you would like to contribute something, or simply want to hack on the code this document should help you get started.\nSign the Contributor License Agreement Before we accept a non-trivial patch or pull request we will need you to sign the Contributor License Agreement. Signing the contributor’s agreement does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do. Active contributors might be asked to join the core team, and given the ability to merge pull requests.\nCode Conventions None of these is essential for a pull request, but they will all help.\n we provided a code formatter file, it will formatting automatically your project when during process of building.\n Make sure all new .java files to have a simple Javadoc class comment with at least an @author tag identifying you, and preferably at least a paragraph on what the class is for.\n Add the …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-contribution/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c044ad534cf99e4d6d400113b490f816","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","summary":"参与贡献 开放代码允许在签署协议之后,提交贡献代码. 版权协议 对 SOFABolt 代码的修改和变更，需要遵守版权协议。 准备工作 贡献代码前需要先了解git工具的使","tags":null,"title":"SOFABolt 参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","wordcount":1650},{"author":null,"categories":null,"content":" 发展路线 Version 1.5.1 修复项目中代码风格的问题：https://github.com/alipay/sofa-bolt/issues/85 修复项目中已知的BUG：https://github.com/alipay/sofa-bolt/issues/82 RPC 层支持从 IO 线程派发 message list：https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 整体目标 统一生命周期组件 抽象并沉淀网络组件的API 收敛配置入口\u0026amp;amp;增强配置的可扩展性 统一生命周期组件 在1.5.x的Bolt版本中，管理组件的生命周期相关的API命名并不统一，比如：\n ReconnectManager不需要启动或者初始化，关闭方法为stop DefaultConnectionMonitor初始化方法为start，关闭的方法为destroy RpcClient初始化方法为init，关闭的方法为shutdown RpcTaskScanner初始化的方法为start，关闭方法为shutdown 在1.6.0版本里，统一了所有组件的生命周期接口：\n 对于有生命周期的组件，即使用前需要进行初始化，使用完毕需要释放资源的，统一提供startup/shutdown接口 抽象并沉淀网络组件的API Bolt中remoting类是网络操作的主要入口，目前以抽象类的形式提供，后续希望对方法进行收敛，暴露对应的接口：\n 标准化，规范使用 沉淀接口，保持稳定 收敛入口，便于内部的代码迭代 在1.5.x的版本中，ReconnectManager类尽管提供了public的addCancelUrl方法，但是这个方法在Bolt项目中没有调用：\n IDE会给出警告 给用户造成困惑：这个方法可否删除？ 在1.6.0版本中解决了以上的问题，抽象出一套稳定的API，便于用户使用、提升代码可读性，同时也为后续的迭代打下基础。\n收敛配置入口\u0026amp;amp;增强配置的可扩展性 1.5.x版本的Bolt配置入口有以下几个：\n ProtocolSwitch：协议配置（是否开启CRC校验），通过静态的方法创建配置对象 GlobalSwitch：实例级配置，每个AbstractConfigurableInstance拥有自己的GlobalSwitch配置，默认值取自SystemProperty，可以通过API调整配置 ConfigItem：Netty相关的配置项的枚举，不可以继承拓展（用户需要修改源码） ConfigManager：配置读取入口，通过静态方法读取SystemProperty的配置 Configs：配置项名称的定义和配置项的默认值 整体上看Bolt的配置项比较零散，且对用户来说难以拓展使用，有以接口暴露的配置项、有以静态方法暴露的配置项，配置项可以通过系统参数配置也可以通过API执行配置。\n且Bolt配置项存在相互影响的问题，比如一个产品同时使用了RPC和消息，而RPC和消息底层都依赖于Bolt，那么基于SystemProperty的配置将无法做到RPC和消息的配置隔离。\n在1.6.0版本中对配置模块进行了调整，在兼容当前版本配置的情况下：\n 收敛配置入口，提供统一的配置的编程界面（以类似Netty的Option的方式进行配置） 支持配置隔离，不同的Bolt实例使用不同的配置项 提升配置的可扩展性 ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-roadmap/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3d4eac90b5c8e657d14eb885ab1f9a92","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","summary":"发展路线 Version 1.5.1 修复项目中代码风格的问题：https://github.com/alipay/sofa-bolt/issues/85 修复项目中已","tags":null,"title":"SOFABolt 发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","wordcount":1356},{"author":null,"categories":null,"content":" 介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生。 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，积累了很多经验，并持续的进行着优化和完善，我们希望能把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。 目前该产品已经运用在了蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n多语言 node python cpp ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/overview/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5ee08df7c4bbd2c3be846e16f3bc81b1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/overview/","summary":"介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于","tags":null,"title":"SOFABolt 概述","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/overview/","wordcount":369},{"author":null,"categories":null,"content":" 用户指南 maven coordinator \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; check release note for version\n 1. 基础功能 1.1 实现用户请求处理器 (UserProcessor) 我们提供了两种用户请求处理器，SyncUserProcessor 与 AsyncUserProcessor。 二者的区别在于，前者需要在当前处理线程以return返回值的形式返回处理结果；而后者，有一个 AsyncContext 存根，可以在当前线程，也可以在异步线程，调用 sendResponse 方法返回处理结果。示例可参考如下两个类：\n 同步请求处理器 异步请求处理器 1.2 实现连接事件处理器 (ConnectionEventProcessor) 我们提供了两种事件监听，建连事件（ConnectionEventType.CONNECT）与断连事件（ConnectionEventType.CLOSE），用户可以创建自己的事件处理器，并注册到客户端或者服务端。客户端与服务端，都可以监听到各自的建连与断连事件。\n 处理连接建立事件 处理连接断开事件 1.3 客户端与服务端初始化 (RpcClient，RpcServer) 我们提供了一个 RpcClient 与 RpcServer，经过简单的必要功能初始化，或者功能开关，即可使用。一个最简单的例子如下：\n 客户端初始化示例 服务端初始化示例 1.4 基础通信模型 我们提供了四种通信模型：\n1.Oneway 调用\n当前线程发起调用后，不关心调用结果，不做超时控制，只要请求已经发出，就完成本次调用。注意 Oneway 调用不保证成功，而且发起方无法知道调用结果。因此通常用于可以重试，或者定时通知类的场景，调用过程是有可能因为网络问题，机器故障等原因，导致请求失败。业务场景需要能接受这样的异常场景，才可以使用。请参考示例。\n2. Sync 同步调用\n当前线程发起调用后，需要在指定的超时时间内，等到响应结果，才能完成本次调用。如果超时时间内没有得到结果，那么会抛出超时异常。这种调用模式最常用。注意要根据对端的处理能力，合理设置超时时间。请参考示例。\n3. Future调用\n当前线程发起调用，得到一个 RpcResponseFuture 对象，当前线程可以继续执行下一次调用。可以在任意时刻，使用 RpcResponseFuture 对象的 get() 方法来获取结果，如果响应已经回来，此时就马上得到结果；如果响应没有回来，则会阻塞住当前线程，直到响应回来，或者超时时间到。请参考示例。\n4. Callback异步调用\n当前线程发起调用，则本次调用马上结束，可以马上执行下一次调用。发起调用时需要注册一个回调，该回调需要分配一个异步线程池。待响应回来后，会在回调的异步线程池，来执行回调逻辑。请参考示例。\n1.5 日志打印 SOFABolt 只依赖 SLF4J 作为日志门面。同时提供了 log4j、log4j2、logback 三种日志模板，使用者只需要在运行时依赖某一种日志实现，我们依赖的 sofa-common-tools 组件，会在运行时动态感知是哪一种日志实现，同时加载正确的日志模板，进行打印。日志会打印在 ~/logs/bolt/ 目录下面，包括如下几种日志：\n common-default.log：默认日志，打印一些客户端、服务器启动、关闭等通信过程的普通日志 common-error.log：异常日志，框架运行过程中出现的异常 connection-event.log：连接事件日志 remoting-rpc.log：RPC 协议相关的日志 关于日志依赖，可以参考日志实现依赖参考\n2. 进阶功能 2.1 请求上下文 在调用过程中，我们还提供了带 InvokeContext 的接口，并一路传递下去，可以在自定义序列化器，用户请求处理器中获得。我们分为两种场景来使用请求上下文：\n 客户端：用户可以设置一些针对本次请求生效的参数，比如序列化类型，是否开启crc等机制。同时可以从上下文中获取建连耗时，连接信息等。 服务端：用户可以从用户请求处理器中获得请求到达后的排队耗时，连接信息等 注意：客户端与服务端的上下文是独立的，即客户端设置的上下文只在客户端可见，对服务端不可见；反之同理。 使用示例 2.2 双工通信 除了服务端可以注册用户请求处理器，我们的客户端也可以注册用户请求处理器。此时，服务端就可以发起对客户端的调用，也可以使用 1.4 提到了任何一种通信模型。\n 示例1：使用 Connection 对象的双工通信，注意使用 Connection 对象的双工通信，服务端需要通过事件监听处理器或者用户请求处理器，自己保存好 Connection 对象。 示例2：使用 Address 的双工通信，注意使用 Address 方式的双工通信，需要在初始化 RpcServer 时，打开 manageConnection 开关，表示服务端会根据客户端发起的建连，维护一份地址与连接的映射关系。默认不需要双工通信的时候，这个功能是关闭的。 2.3 建立多连接与连接预热 通常来说，点对点的直连通信，客户端和服务端，一个 IP 一个连接对象就够用了。不管是吞吐能力还是并发度，都能满足一般业务的通信需求。而有一些场景，比如不是点对点直连通信，而是经过了 LVS VIP，或者 F5 设备的连接，此时，为了负载均衡和容错，会针对一个 URL 地址建立多个连接。我们提供如下方式来建立多连接，即发起调用时传入的 URL 增加如下参数 127.0.0.1:12200?_CONNECTIONNUM=30\u0026amp;amp;_CONNECTIONWARMUP=true，表示针对这个 IP 地址，需要建立30个连接，同时需要预热连接。其中预热与不预热的区别是：\n 预热：即第一次调用（比如 Sync 同步调用），就建立30个连接 不预热：每一次调用，创建一个连接，直到创建满30个连接 使用示例 2.4 自动断连与重连 通常 RPC 调用过程，是不需要断链与重连的。因为每次 RPC 调用过程，都会校验是否有可用连接，如果没有则新建一个。但有一些场景，是需要断链和保持长连接的：\n 自动断连：比如通过 LVS VIP 或者 F5 建立多个连接的场景，因为网络设备的负载均衡机制，有可能某一些连接固定映射到了某几台后端的 RS 上面，此时需要自动断连，然后重连，靠建连过程的随机性来实现最终负载均衡。注意，开启了自动断连的场景，通常需要配合重连使用。 重连：比如客户端发起建连后，由服务端来通过双工通信，发起请求到客户端。此时如果没有重连机制，则无法实现。 使用示例，注意考虑一个进程可能会有多个 SOFABolt 的通信实例，我们提供了全局开关以及用户开关两种开关方式： …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-handbook/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2a0a2e3c7749dbcdceea064f6f850e33","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","summary":"用户指南 maven coordinator \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; check release note for version 1. 基础功能 1.1 实现用户请求处理器 (UserProcessor) 我们提供了两种用户请求处理器，SyncUserProcessor 与 Async","tags":null,"title":"SOFABolt 用户手册","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","wordcount":3516},{"author":null,"categories":null,"content":" 相关链接 ISSUES 用户手册 中文介绍文章: 蚂蚁通信框架实践 ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/related-links/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6844d2a639b69fa3128132b8631f33e3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/related-links/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/related-links/","summary":"相关链接 ISSUES 用户手册 中文介绍文章: 蚂蚁通信框架实践","tags":null,"title":"SOFABolt 相关链接","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/related-links/","wordcount":24},{"author":null,"categories":null,"content":" # Upgrade SOFABoot from 2.3.x/2.4.x to 2.5.x SOFABoot 2.3.x/2.4.x is developed based on Spring Boot 1.4.2.RELEASE, SOFABoot 2.5.x is developed based on Spring Boot 1.5.x. When upgrading SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x, we should pay special attention to the differences between the Spring Boot 1.5.x upgrade and the Spring Boot 1.4.x upgrade.\nRenamed Spring Boot Starters spring-boot-starter-ws \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-data-redis Endpoint Security Control Spring Boot 1.5.x has security control over all sensitive endpoints by default, that is, endpoints such as /beans and /dump, which were previously accessible by default in version 1.4.x, are not accessible in version 1.5.x. To access such endpoints, we need to configure Spring Boot as follows: \u0026amp;gt; management.security.enabled=false\nOnly /health, /info, and /docs are accessible by default in version 1.5.x. Please refer to official description for details: + endpoints + Accessing sensitive endpoints\nApplicationEvent Change ApplicationStartedEvent in 1.4.x has been renamed ApplicationStartingEvent in Spring Boot 1.5.x. The version 1.5.x remains forward compatible. Note that the ApplicationStartedEvent event has a completely different meaning in version 2.x.\n** Users who have upgraded the SOFABoot to the version 2.5.x are strongly advised to change ApplicationStartedEvent to ApplicationStartingEvent to avoid compatibility issues when upgrading SOFABoot to the version 3.0.x in the future.**\nProperty renaming server.max-http-post-size \u0026amp;ndash;\u0026amp;gt; server.tomcat.max-http-post-size spring.data.neo4j.session.scope is removed Refer to the configuration of Spring Boot 1.5.x changelog\nSummary The above are the major points worthy of notice when we upgrade SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x. For detailed information, refer to the Release Report of Spring Boot 1.5.x.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_2_5_x/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4b7dd4287b00106684831d2a8524a6f7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","summary":"# Upgrade SOFABoot from 2.3.x/2.4.x to 2.5.x SOFABoot 2.3.x/2.4.x is developed based on Spring Boot 1.4.2.RELEASE, SOFABoot 2.5.x is developed based on Spring Boot 1.5.x. When upgrading SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x, we should pay special attention to the differences between the Spring Boot 1.5.x upgrade and the Spring Boot 1.4.x upgrade.\nRenamed Spring Boot Starters spring-boot-starter-ws \u0026ndash;\u0026gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026ndash;\u0026gt; spring-boot-starter-data-redis Endpoint Security Control Spring Boot 1.","tags":null,"title":"SOFABoot 2.5.x upgrade","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","wordcount":251},{"author":null,"categories":null,"content":" SOFABoot 2.3.x/2.4.x 升级到 2.5.x SOFABoot 2.3.x/2.4.x 基于 Spring Boot 1.4.2.RELEASE 版本开发，SOFABoot 2.5.x 则是基于 Spring Boot 1.5.x 版本开发。 从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 需要重点考虑 Spring Boot 1.5.x 相较 Spring Boot 1.4.x 的升级注意点。\n重命名的 spring boot starters spring-boot-starter-ws \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-data-redis endpoint 安全性控制 Spring Boot 1.5.x 对所有 Sensitive Endpoint 默认进行了安全管控，即之前在 1.4.x 默认能访问的诸如 /beans, /dump 等 endpoints 在 1.5.x 版本均不能访问。如果需要访问，需要配置： \u0026amp;gt; management.security.enabled=false\n默认情况下，在 1.5.x 只有 /health, /info, /docs 能够访问。详细请参考官方描述： + endpoints + Accessing sensitive endpoints\nApplicationEvent 变更 Spring Boot 1.5.x 将 1.4.x 中的 ApplicationStartedEvent 重命名为 ApplicationStartingEvent，在 1.5.x 仍然保持向前兼容。需要格外注意的是，在 2.x 版本中，ApplicationStartedEvent 事件意义完全不一样。\n强烈建议升级到 SOFABoot 2.5.x 的用户，将应用中使用的 ApplicationStartedEvent 变更为 ApplicationStartingEvent；避免今后升级至 SOFABoot 3.0.x 出现兼容性问题\nProperty 重命名 server.max-http-post-size \u0026amp;ndash;\u0026amp;gt; server.tomcat.max-http-post-size spring.data.neo4j.session.scope 被移除 具体参考 Spring Boot 1.5.x 配置的 changelog\n总结 以上总结了从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 的几个主要注意点，详细可以参考 Spring Boot 1.5.x 的发布报告\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_2_5_x/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4b7dd4287b00106684831d2a8524a6f7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","summary":"SOFABoot 2.3.x/2.4.x 升级到 2.5.x SOFABoot 2.3.x/2.4.x 基于 Spring Boot 1.4.2.RELEASE 版本开发，SOFABoot 2.5.x 则是基于 Spring Boot 1.5.x 版本开发。 从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 需要重点考虑 Spring Boot 1.5.x 相较 Spring Boot 1.4.x 的升级注意点。 重命","tags":null,"title":"SOFABoot 2.5.x 升级注意事项","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","wordcount":404},{"author":null,"categories":null,"content":" ## Preface As a Spring Boot-based development framework open sourced by Ant Financial, SOFABoot provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nWe have received a lot of feedback from community users since SOFABoot was open sourced in April 2018. We are also very pleased to see many community users take an active part in building the SOFAStack open source, which greatly increases our determination to prosper SOFAStack community and ecosystem. Here, we announce the release of the SOFABoot 3.0, which is developed based on Spring Boot 2.0. SOFABoot 3.0 allows us to seamlessly integrate the extension capability of SOFABoot with official components of Spring Boot 2.x. In addition, SOFABoot 3.0 is compatible with Spring Cloud components, which allows us to easily integrate Spring Cloud components like Zuul and Config in the SOFABoot framework.\nBelow are the major changes of SOFABoot 3.0 compared with SOFABoot 2.x.\nUpgrade Spring Boot to version 2.x Upgrade Spring Boot in SOFABoot 3.0 to version 2.0. As the Spring Boot community recently announced that the maintenance for version 1.x will end in August 2019, we will focus on SOFABoot 3.x in the future and will release SOFABoot 3.1 with Spring Boot upgraded to version 2.1 soon.\nSpring Cloud compatible Some components are not compatible with SOFABoot in SOFABoot 2.x. In SOFABoot 3.x, we have run thorough compatibility tests on Spring Cloud components and fixed all problems found to ensure good compatibility between SOFABoot 3.x and Spring Cloud.\nWebFlux framework compatible Spring Boot 2.x introduces the WebFlux framework. SOFABoot 3.x is compatible with WebFlux in two major aspects; + Health Check is compatible with the ReactiveHealthIndicator extension interface. The Readiness Check will include the implementation of the interface extension; + Compatible with buried points of WebFlux web requests. Point burying logs and files are compatible with common MVC requests. For detailed information, refer to MVC point burying request.\nJDK version support SOFABoot 3.x must run on JDK 8 or higher versions and does not support JDK 6 and JDK 7.\nHealth Check SOFABoot adds Readiness Check capability to Spring Boot\u0026amp;rsquo;s Health Check capability, to ensure that all components and operations are in a healthy state before the application goes into services. Compared with SOFABoot 2.x, SOFABoot 3.0 features great adjustments to the Health Check. It abandons some internal compatibility logic of Ant Financial and uses a friendlier coding scheme. Besides, the Health Check of SOFABoot 3.0 offers extensions in various scenarios, supports the \u0026amp;lsquo;ReactiveHealthIndicator\u0026amp;rsquo; extension interface introduced in Spring Boot 2.x, and provides more Health Check extension features.\nAdjust the Readiness Check Endpoint path The Endpoint for checking the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_3_x/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"91ba09adf6bc42aaf70645b9a19b409b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","summary":"## Preface As a Spring Boot-based development framework open sourced by Ant Financial, SOFABoot provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nWe have received a lot of feedback from community users since SOFABoot was open sourced in April 2018. We are also very pleased to see many community users take an active part in building the SOFAStack open source, which greatly increases our determination to prosper SOFAStack community and ecosystem.","tags":null,"title":"SOFABoot 3.0 upgrade","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","wordcount":910},{"author":null,"categories":null,"content":" 前言 SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n自今年 4 月份 SOFABoot 开源至今，我们收到了非常多来自社区同学的反馈，也非常高兴的看到很多社区同学积极的参与到 SOFAStack 开源共建，这极大了鼓舞了我们建设 SOFAStack 开源社区的决心，力图把 SOFAStack 社区和生态建设更加繁荣。在此，我们宣布推出 SOFABoot 3.0 版本，SOFABoot 3.0 是基于 Spring Boot 2.0 版本开发。在 SOFABoot 3.0 中，可以将 SOFABoot 扩展能力和 Spring Boot 2.x 官方组件无缝集成。此外，我们在 SOFABoot 3.0 中兼容了 Spring Cloud 组件集成，可以很方便地在 SOFABoot 框架中集成 Spring Cloud 组件，如 Zuul, Config 等。\n以下，本文将详细介绍 SOFABoot 3.0 相较 SOFABoot 2.x 的变更。\nSpring Boot 升级 2.x SOFABoot 3.0 版本升级 Spring Boot 版本至 2.0。鉴于Spring Boot 社区最近刚公告 1.x 版本将维护至明年 8 月份为止，未来，我们也将主力维护 SOFABoot 3.x 版本，近期也将发布 SOFABoot 3.1 升级 Spring Boot 版本至 2.1。\nSpring Cloud 兼容 在 SOFABoot 2.x 中，存在部分组件和 SOFABoot 兼容性问题。在 SOFABoot 3.x 中，对 Spring Cloud 各组件进行了比较完备的兼容性测试和问题修复，保证了 SOFABoot 3.x 与 Spring Cloud 良好的兼容性。\nWebFlux 框架兼容 Spring Boot 2.x 引入了 WebFlux 框架，SOFABoot 3.x 主要在两个方面兼容了 WebFlux 框架； + 健康检查兼容了 ReactiveHealthIndicator 扩展接口，业务对这个接口的扩展实现将会纳入到 Readiness Check； + 兼容对 WebFlux 网络请求进行埋点，埋点日志格式和文件保持对普通 MVC 请求兼容，详细参考MVC 埋点请求\nJDK 版本支持 SOFABoot 3.x 最低要求运行在 JDK 8 及其以上版本，不支持 JDK 6，7。\n健康检查 SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 能力，以确保应用在正常对外服务前，所有组件及业务本身处于健康状态。相较于与 SOFABoot 2.x, SOFABoot 3.0 在健康检查做了很大的重构，主要是剥离了部分蚂蚁金服内部兼容逻辑，采用更加友好的编码方案；其次，SOFABoot 3.0 健康检查提供了多种不同场景下的健康检查扩展形式，支持 Spring Boot 2.x 引入的 ReactiveHealthIndicator 扩展接口，丰富了健康检查扩展特性。\n调整 Readiness Check Endpoint 路径 在 SOFABoot 2.x 中，查看健康检查结果的 Endpoint 为 /health/readiness，而在 SOFABoot 3.0 中，变更为 /actuator/readiness。\n扩展接口变更 在 SOFABoot 3.x 中，提供四种方式扩展健康检查，分别是 + HealthChecker + HealthIndicator(Spring Boot 原生) + ReactiveHealthIndicator(Spring Boot 原生) + ReadinessCheckCallback\n这四个接口的扩展实现执行顺序是 HealthChecker \u0026amp;gt; HealthIndicator, ReactiveHealthIndicator \u0026amp;gt; ReadinessCheckCallback，相同接口的扩展实现执行顺序则遵循 Spring Boot 标准的方案。即扩展类可以额外实现两个标准的 Order 接口：\n org.springframework.core.Ordered org.springframework.core.PriorityOrdered 或者使用注解\n org.springframework.core.annotation.Order 这些接口的扩展实现处理结果将会在健康检查结果查中展现。\n删除 SofaBootBeforeHealthCheckEvent 事件 在 SOFABoot 2.x 中，我们没有提供支持对健康检查扩展实现进行排序，导致用户无法预期自身扩展执行时机。如上述，SOFABoot 3.x 支持各组件扩展实现的排序，因此该事件可以统一使用 HealthChecker 接口和高优先级顺序实现替代。其次，在 SOFABoot 2.x 中，SofaBootBeforeHealthCheckEvent 事件的处理逻辑结果并不会反应在健康检查结果中，使用 HealthChecker 替代之后，这部分逻辑处理自然变成健康检查的一部分，可供查看。\n删除 DefaultHealthChecker 接口 使用 JDK8 默认方法特性，删除 DefaultHealthChecker 接口，用户可以直接使用 HealthChecker 接口替代 DefaultHealthChecker.\n删除 SofaBootMiddlewareAfterReadinessCheckCallback 和 SofaBootAfterReadinessCheckCallback 接口 在 SOFABoot 2.x 中，这两个接口是两种场景下的健康检查回调；推荐 SOFABoot 官方 Starter 使用 SofaBootMiddlewareAfterReadinessCheckCallback，而业务应用推荐使用SofaBootAfterReadinessCheckCallback，框架将优先执行 SofaBootMiddlewareAfterReadinessCheckCallback 的扩展实现，然后执行 SofaBootAfterReadinessCheckCallback 的扩展实现。这样的设计有两个缺陷： + 两个接口本质没有区别，但是隐藏了先后顺序逻辑，给用户引入了额外的学习成本； + 只考虑了 SofaBootMiddlewareAfterReadinessCheckCallback 和 SofaBootAfterReadinessCheckCallback 两个接口的顺序，但无法保证相同接口实现的执行顺序。\nSOFABoot 3.x …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_3_x/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"91ba09adf6bc42aaf70645b9a19b409b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_3_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_3_x/","summary":"前言 SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFA","tags":null,"title":"SOFABoot 3.0 升级注意事项","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_3_x/","wordcount":1687},{"author":null,"categories":null,"content":" Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开发。\n二方库升级 SOFABoot 4.0 基于 Spring Boot 3.0 与 Spring Framework 6 构建。在 Spring Boot 3.0 与 Spring Framework 6 引入的二方库升级列表可参考文档👉 Spring Boot 3.0 Release Notes\n在 SOFABoot 4.0 引入的二方库升级列表如下：\n Spring Boot 3.0.7 Spring Cloud 4.0.0 Spring Cloud Stream 3.2.6 SOFA Common tools 2.0.0 SOFATracer 4.0.0 SOFARPC 5.10.0 FastJson 1.2.83 Guava 31.1-jre Grpc 1.51.1 Grpc common protos 2.11.0 Druid 1.2.16 ASM 9.4 Javassist 3.29.2-GA Curator 4.3.0 Dubbo 3.1.8 Nacos 2.0.3 Swagger 1.6.7 Swagger2 2.2.8 基于 Jakarta EE Spring Boot 3.0 中依赖 Jakarta EE 规范的部分已经升级到了 Jakarta EE 10 版本。例如，使用 Servlet 6.0 和 JPA 3.1 规范。因此，部分包的命名空间也进行了替换，例如你应该使用：\n✅jakarta.servlet.Filter\n而不是 javax.servlet.Filter。\n同时，如果你使用了自己的依赖提供 Jakarta EE 规范的 API，需注意进行对应的依赖升级，例如你应该使用：\n✅jakarta.servlet:jakarta.servlet-api\n而不是 javax.servlet:javax.servlet-api。\n可参考文档：Migrate to Jakarta EE 9 来修改 Jakarta 相关的包名以及依赖。\n支持 SOFAArk 2.0 SOFAArk 2.0 模式是 SOFAArk 框架的整体优化版本，相较于 SOFAArk 1.0 模式，它的整体优化思路和原则是 Ark Master Biz 保持和原生 SOFABoot 保持一致，弱化复杂的 Ark Plugin 类管控机制，将 Ark Plugin 与 Master Biz 合并。使得 Ark Master Biz 和原生 SOFABoot 应用的启动方式、类加载方式保持一致，大大降低了 Master Biz 应用的编程难度。\nSOFABoot 4.0 版本不再支持 SOFAArk 1.0 模式，如果你想要在 SOFABoot 应用中使用 SOFAArk 2.0 模式，可以按照以下步骤进行操作：\n1、在项目中引入 SOFAArk 组件依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;ark-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2、添加 Spring Boot 的 Package 插件\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 3、启动应用\n 方式一： IDEA 启动，注意需要添加启动参数：-Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二： 命令行启动，先运行 mvn clean package 命令进行打包，生成 ${bizName}-${bizVersion}-ark-biz.jar 的可执行文件，然后在终端运行以下启动参数：\njava -jar -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName} ${bizName}-${bizVersion}-ark-biz.jar\n支持场景化的按配置加载能力 通常情况下，应用在不同的场景下可能需要开启或者关闭不同的功能，Spring Boot 提供了丰富的 Configuration 动态配置能力[4] 能力以支持应用在不同的场景下加载不同的 Bean。\nSOFABoot 在此基础上，对 org.springframework.context.ApplicationContextInitializer 等扩展点进行了增强，支持通过统一风格的配置定制各类 Bean 以及扩展点的开启与关闭，并提供了定制模版配置的开启方式以降低应用配置项的复杂度。\n 通过： com.alipay.sofa.boot.autoconfigure.condition.ConditionalOnSwitch 注解为 Bean 添加按配置开启能力：\n@Configuration(proxyBeanMethods = false) @ConditionalOnSwitch(id=\u0026amp;quot;sample\u0026amp;quot;) public class SampleConfiguration { @Bean public SampleBean sampleBean() { return new SampleBean(); } } 添加：\nsofa.boot.switch.bean.sample.enabled=false 配置后，SampleConfiguration 配置类将不再加载。\n 通过继承： …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_4_x/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5c33e340d1a0200b2dac6aa548142849","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_4_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_4_x/","summary":"Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开","tags":null,"title":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_4_x/","wordcount":3757},{"author":null,"categories":null,"content":" SOFABoot supports modular isolation. But in actual usage scenarios, There is one case that beans in one module sometimes need to open some entries for another module to expand. SOFABoot draws on and uses the Nuxeo Runtime project and the nuxeo project and expands on it, provides the ability to extend points with Spring, We call it Extension Point.\nUsage Using extension point capabilities in SOFABoot requires the following three steps:\nDefine a bean that provides extension capabilities When using the SOFABoot extension point capability, you first need to define an interface that needs to be extended, like:\npackage com.alipay.sofa.boot.test; public interface IExtension { String say(); } Define the implementation of this interface:\npackage com.alipay.sofa.boot.test.impl; public class ExtensionImpl implements IExtension { private String word; @Override public String say() { return word; } public void setWord(String word) { this.word = word; } public void registerExtension(Extension extension) throws Exception { Object[] contributions = extension.getContributions(); String extensionPoint = extension.getExtensionPoint(); if (contributions == null) { return; } for (Object contribution : contributions) { if (\u0026amp;quot;word\u0026amp;quot;.equals(extensionPoint)) { setWord(((ExtensionDescriptor) contribution).getValue()); } } } } Here you can see that there is a method: registerExtension, you can temporarily ignore this method, and later will introduce its specific role.\nIn the module\u0026amp;rsquo;s Spring configuration file, we add configuration of this bean:\n\u0026amp;lt;bean id=\u0026amp;quot;extension\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.test.impl.ExtensionImpl\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;word\u0026amp;quot; value=\u0026amp;quot;Hello, world\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; Defining extension points There is a field word in the above bean. In practice, we want this field to be overridden by other module customizations. Here we expose it as an extension point.\nFirst, you need a class to describe this extension point:\n@XObject(\u0026amp;quot;word\u0026amp;quot;) public class ExtensionDescriptor { @XNode(\u0026amp;quot;value\u0026amp;quot;) private String value; public String getValue() { return value; } } Then define the extension point in xml:\n\u0026amp;lt;sofa:extension-point name=\u0026amp;quot;word\u0026amp;quot; ref=\u0026amp;quot;extension\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:object class=\u0026amp;quot;com.alipay.sofa.boot.test.extension.ExtensionDescriptor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:extension-point\u0026amp;gt; among them: - name is the name of the extension point - ref is the bean to which the extension point is applied - object is a concrete description of the contribution point of the extension point. This description is done by XMap (XMap is used to map Java objects and XML files. It is recommended to search XMap documents on the Internet to understand XMap)\nDefining extension implements The above has defined the extension point, and we can extend this bean at this point:\n\u0026amp;lt;sofa:extension bean=\u0026amp;quot;extension\u0026amp;quot; point=\u0026amp;quot;word\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:content\u0026amp;gt; \u0026amp;lt;word\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/extension/","fuzzywordcount":1300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"93225b6c1f2b68f2047a7cf49b76650b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/extension/","summary":"SOFABoot supports modular isolation. But in actual usage scenarios, There is one case that beans in one module sometimes need to open some entries for another module to expand. SOFABoot draws on and uses the Nuxeo Runtime project and the nuxeo project and expands on it, provides the ability to extend points with Spring, We call it Extension Point. Usage Using extension point capabilities in SOFABoot requires the following three","tags":null,"title":"SOFABoot Extension Point","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/extension/","wordcount":1279},{"author":null,"categories":null,"content":" Spring 框架从 3.1.X 版本开始提供了 profile 功能: Bean Definition Profiles，SOFABoot 支持模块级 profile 能力，即在各个模块启动的时候决定模块是否能够启动。\n使用 Module-Profile 激活 module 使用 SOFABoot 的 profile 功能，需要在 application.properties 文件增加 com.alipay.sofa.boot.active-profiles 字段，该字段的值为逗号分隔的字符串，表示允许激活的 profile 列表，指定该字段后，SOFABoot 会为每个可以激活的模块指定此字段表示的 profile 列表。\nSOFABoot 模块的 sofa-module.properties 文件支持 Module-Profile 字段，该字段的值为逗号分隔的字符串，表示当前模块允许在哪些 profile 激活。Module-Profile 支持取反操作， !dev 表示 com.alipay.sofa.boot.active-profiles 不包含 dev 时被激活。\n当应用未指定 com.alipay.sofa.boot.active-profiles 参数时，表示应用所有模块均可启动。SOFABoot 模块未指定 Module-Profile 时，表示当前 SOFABoot 模块可以在任何 profile 启动。\n使用例子 激活 dev SOFABoot 模块 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev 该配置表示激活 profile 为 dev 的模块。\n在每个需要限定为 dev profile 被激活模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=dev 配置多个激活 profile application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev,test 该配置表示激活 profile 为 dev 或者 test 的模块。\n在 SOFABoot 模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=test,product 该配置表示当 com.alipay.sofa.boot.active-profiles 包含 test 或者 product 时激活模块，由于当前指定的 com.alipay.sofa.boot.active-profiles 为 dev,test ，此模块将被激活。\nModule-Profile 取反 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev 该配置表示激活 profile 为 dev 的模块。\n在 SOFABoot 模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=!product 该配置表示当 com.alipay.sofa.boot.active-profiles 不包含 product 时激活模块，由于当前指定的 com.alipay.sofa.boot.active-profiles 为 dev ，此模块将被激活。\n设置激活模块 Spring 上下文的 spring.profiles.active 属性 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev,test 该配置表示激活 profile 为 dev 或者 test 的模块，当一个模块满足上面的激活条件时，这个模块就会被启动，同时 Spring 上下文的环境信息 spring.profiles.active 也被设置为了 dev,test ，这样如下的配置 beanId 为 devBeanId 和 testBeanId 的bean都会被激活。\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:jdbc=\u0026amp;quot;http://www.springframework.org/schema/jdbc\u0026amp;quot; xmlns:jee=\u0026amp;quot;http://www.springframework.org/schema/jee\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.2.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;beans profile=\u0026amp;quot;dev\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;devBeanId\u0026amp;quot; class=\u0026amp;quot;com.alipay.cloudenginetest.sofaprofilesenv.DemoBean\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;name\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;demoBeanDev\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/property\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; \u0026amp;lt;beans profile=\u0026amp;quot;test\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBeanId\u0026amp;quot; class=\u0026amp;quot;com.alipay.cloudenginetest.sofaprofilesenv.DemoBean\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;name\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;demoBeanTest\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/property\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-profile/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b29d568fa057cad0b440790d5cc65d07","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-profile/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-profile/","summary":"Spring 框架从 3.1.X 版本开始提供了 profile 功能: Bean Definition Profiles，SOFABoot 支持模块级 profile 能力，即在各个模块启动的时候决定模块是否能够启动。 使用 Module-Profile 激","tags":null,"title":"SOFABoot Profile","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-profile/","wordcount":666},{"author":null,"categories":null,"content":" Background kc-sofastack-demo has introduced how to quickly build an e-commerce microservice application and has implemented the service calling link tracking and application status monitoring.\nIn e-commerce system, the platforms often are not satisfied with the default product listing order, and always want to arrange some products in the conspicuous places. Also, there are some cases where the platforms would like to show different products to different users based on the collected user behaviors.\nBased on the background of kc-sofastack-demo, this guide will implement sorting the products dynamically based on the total amount of products of each onsite attendee.\nDemo content Implement the dynamic change of product sorting via the dynamic module capability provided by SOFABoot and the dynamic module control capability of SOFADashboard.\nImplement the change of application behavior without restarting the host and without changing the application configuration.\nThe project architecture is as follows:\nTasks 1. Preparation Clone the demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-dynamic-demo.git Then, import the project into IDEA or Eclipse.\n2. Package SOFABoot project as Ark JAR As shown in the following screenshot, add the Ark package plugin in the POM file and configure it:\nStep 1: Copy the Ark plugin and configuration to the specified positions in the above screenshot \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!-- package configuration of ark-biz JAR --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Whether to package, install and publish ark biz. The default value is false. For details, see Ark Biz documentation.--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!-- The directory for ark package and ark biz package, defaulting to the build directory of project--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- The priority of starting ark-biz package. The smaller the value, the higher the priority.--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;200\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--Set the root directory of application, used to read ${base.dir}/conf/ark/bootstrap.application configuration file and defaulting to ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;../\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Step 2: Run mvn clean package to package the project. The successfully packaged JAR file is as shown in the following screenshot:\n3. Build host application In the downloaded project, dynamic-stock-mng is the host application model. In this task, we will build dynamic-stock-mng as the host application of dynamic module.\nStep 1: Introduce Ark …","date":-62135596800,"description":"This guide introduce how to implement the merged deployment and dynmaic module push provided by SOFAArck based on the Ark control function of SOFADashboard.","dir":"guides/kc-sofastack-dynamic-demo/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"8bfd4a50e21ce9fc867b1cf18a8c9af3","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","summary":"Background kc-sofastack-demo has introduced how to quickly build an e-commerce microservice application and has implemented the service calling link tracking and application status monitoring.\nIn e-commerce system, the platforms often are not satisfied with the default product listing order, and always want to arrange some products in the conspicuous places. Also, there are some cases where the platforms would like to show different products to different users based on the collected user behaviors.","tags":null,"title":"SOFABoot dynamic module practice","type":"guides","url":"/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","wordcount":630},{"author":null,"categories":null,"content":" SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nYou can view all the release notes in Release History. The correspondence between SOFABoot version and Spring Boot version is as follows:\n SOFABoot version Spring Boot version 2.3.x 1.4.2.RELEASE 2.4.x 1.4.2.RELEASE 2.5.x 1.5.16.RELEASE 3.0.x 2.0.3.RELEASE 3.1.0 2.1.0.RELEASE That is, the SOFABoot 2.3.x and 2.4.x series are based on Spring Boot 1.4.2.RELEASE; SOFABoot 2.5.x series are based on Spring Boot 1.5.x; SOFABoot 3.x series are based on Spring Boot 2.x. You can view and get the codes of all revisions in Release History. In addition, to facilitate users in the community to learn the latest development version of SOFABoot, we will release the SNAPSHOT version, which is a branch of the current development. To successfully pull the SNAPSHOT package from the central repository, it\u0026amp;rsquo;s necessary to add the following profile configuration to the local maven setting.xml file:\n\u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; Feature Description Based on Spring Boot, SOFABoot provides the following capabilities:\n Capability of expanding the Health Check of Spring Boot: Provide the Readiness Check based on the Health Check of Spring Boot, to ensure a secure launch of application examples. Capability of log space isolation: The middleware framework automatically finds the application\u0026amp;rsquo;s logs and realizes dependence on the logs and independent log printing, avoiding binding the middleware and the application logs. The capability is achieved through sofa-common-tools. Capability of providing class isolation: Provide class isolation based on the SOFAArk framework, making it easy for users to solve various class conflicts. Capability of providing modular development: Based on the Spring context isolation, provide modular development capability, with a separate Spring context for each SOFABoot module, to avoid BeanId conflicts between different SOFABoot modules. Integrated management of middleware: manage in a unified manner, provide a unified and easy-to-use …","date":-62135596800,"description":"","dir":"projects/sofa-boot/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"fe6aed461c61b86dfed846a2dc0b7dcb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/overview/","summary":"SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nYou can view all the release notes in Release History. The correspondence between SOFABoot version and Spring Boot version is as follows:","tags":null,"title":"SOFABoot overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/overview/","wordcount":461},{"author":null,"categories":null,"content":" Since 3.1.X Spring framework has started to support the profile function: Bean Definition Profiles, SOFABoot support modular-level profiling, it will determine whether a module can be started when each module is getting started.\nActivating Module Using Module-Profile To enable the SOFABoot profiling, we need to add the com.alipay.sofa.boot.active-profiles field in the application.properties file. The value of this field is a comma-separated string denoting a list of profiles allowed to be activated. After specifying it, SOFABoot will specify a profile list represented by the field for each module that can be activated.\nThe sofa-module.properties file of the SOFABoot module supports the Module-Profile field, which points to a comma-separated string of values representing which profiles are allowed to be activated. Module-Profile supports the inversion operation, !dev indicates that com.alipay.sofa.boot.active-profiles is activated when it does not contain dev.\nIf the value of the com.alipay.sofa.boot.active-profiles field is not specified in the application, all modules are allowed to be started. If the Module-Profile is not specified in the SOFABoot module, the current SOFABoot module can be started with any profile.\nExample Activating the dev SOFABoot Module Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev With this configuration, the module with dev profile will be activated.\nAdd the following configuration to each sofa-module.properties file where modules with dev profile need to be activated.\nModule-Profile=dev Configuring Multiple Activation Profiles Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev,test With this configuration, the modules with dev or test profile will be activated.\nAdd the following configuration to the SOFABoot\u0026amp;rsquo;s sofa-module.properties file:\nModule-Profile=test,product With this configuration, the module will be activated when the com.alipay.sofa.boot.active-profiles contains test or product. Since the com.alipay.sofa.boot.active-profiles is specified as dev and test, this module will be activated.\nThe Inverted Module-Profile Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev With this configuration, the module with dev profile will be activated.\nAdd the following configuration to the SOFABoot\u0026amp;rsquo;s sofa-module.properties file:\nModule-Profile=!product This will activate the module when the com.alipay.sofa.boot.active-profiles does not contain product. Since it is specified as dev, this module will be activated.\nSet the spring.profiles.active property that is used to activate the Spring context of the module. Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev,test With this configuration, the modules with dev or test profile will be activated. If a module meets those …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-profile/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b29d568fa057cad0b440790d5cc65d07","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","summary":"Since 3.1.X Spring framework has started to support the profile function: Bean Definition Profiles, SOFABoot support modular-level profiling, it will determine whether a module can be started when each module is getting started.\nActivating Module Using Module-Profile To enable the SOFABoot profiling, we need to add the com.alipay.sofa.boot.active-profiles field in the application.properties file. The value of this field is a comma-separated string denoting a list of profiles allowed to be activated.","tags":null,"title":"SOFABoot profile","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","wordcount":450},{"author":null,"categories":null,"content":" SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n你可以在发布历史中查看所有的发布报告，SOFABoot 版本和 Spring Boot 版本对应关系如下：\n SOFABoot 版本 Spring Boot 版本 3.3.0～3.3.1 2.1.11.RELEASE 3.3.2～3.6.0 2.1.13.RELEASE 3.7.0～3.10.0 2.3.9.RELEASE 3.11.0～3.11.1 2.3.12.RELEASE 3.12.0～3.13.0 2.4.13 3.14.0～3.14.1 2.6.9 3.15.0～3.16.3 2.7.3 3.17.0 2.7.8 3.18.0～3.19.1 2.7.10 4.0.0 ～ 4.0.2 3.0.7 4.1.0 3.1.5 4.2.0 3.2.2 4.3.0 3.2.6 SOFABoot 3.x 系列版本将构建在 Spring Boot 2.x 基础之上，SOFABoot 4.x 系列版本将构建在 Spring Boot 3.x 基础之上 。你可以在发布历史中查看获取所有的历史版本代码。另外为了方便社区同学能够基于最新开发版本的 SOFABoot 进行开发学习，我们会发布当前开发分支的 SNAPSHOT 版本。为顺利从中央仓库拉取 SNAPSHOT 包，需要在本地 maven setting.xml 文件增加如下 profile 配置:\n\u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; 目前 SOFABoot 最新版本为 4.0.0，基于 Spring Boot 3.0.7, 支持 JDK17。\n功能描述 SOFABoot 在 Spring Boot 基础上，提供了以下能力：\n 扩展 Spring Boot 健康检查的能力：在 Spring Boot 健康检查能力基础上，提供了 Readiness Check 的能力，保证应用实例安全上线。 提供模块化开发的能力：基于 Spring 上下文隔离提供模块化开发能力，每个 SOFABoot 模块使用独立的 Spring 上下文，避免不同 SOFABoot 模块间的 BeanId 冲突。 增加模块并行加载和 Spring Bean 异步初始化能力，加速应用启动； 增加日志空间隔离的能力：中间件框架自动发现应用的日志实现依赖并独立打印日志，避免中间件和应用日志实现绑定，通过 sofa-common-tools 实现。 增加类隔离的能力：基于 SOFAArk 框架提供类隔离能力，方便使用者解决各种类冲突问题。 增加中间件集成管理的能力：统一管控、提供中间件统一易用的编程接口、每一个 SOFA 中间件都是独立可插拔的组件。 提供完全兼容 Spring Boot的能力：SOFABoot 基于 Spring Boot 的基础上进行构建，并且完全兼容 Spring Boot。 应用场景 SOFABoot 本身就脱胎于蚂蚁金服内部对于 Spring Boot 的实践，补充了 Spring Boot 在大规模金融级生产场景下一些不足的地方，所以 SOFABoot 特别适合于这样的场景。\n当然，SOFABoot 的每个组件都是可选的，用户可以灵活选择其中的功能来使用，比如如果仅仅想在 Spring Boot 下面引入 SOFA 中间件，可以不需引入 SOFABoot 中的类隔离能力。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/overview/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fe6aed461c61b86dfed846a2dc0b7dcb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/overview/","summary":"SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABo","tags":null,"title":"SOFABoot 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-boot/overview/","wordcount":938},{"author":null,"categories":null,"content":" SOFABoot 提供了类隔离框架 SOFAArk, 弥补了 Spring Boot 在类隔离能力上的缺失，用以解决在实际开发中常见的类冲突、包冲突问题，详细请参考 SOFAArk。\n在 SOFABoot 工程中使用类隔离能力，只需两步操作；配置 sofa-ark-maven-plugin 打包插件以及引入 sofa-ark-springboot-starter 类隔离框架依赖；\n配置 Maven 打包插件 官方提供了 Maven 插件 - sofa-ark-maven-plugin ，只需要简单的配置项，即可将 SpringBoot 工程打包成标准格式规范的可执行 Ark 包，插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 配置模板如下：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- all class exported by ark plugin would be resolved by ark biz in default, if configure denyImportClasses, then it would prefer to load them by ark biz itself --\u0026amp;gt; \u0026amp;lt;denyImportClasses\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass1\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass2\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/denyImportClasses\u0026amp;gt; \u0026amp;lt;!-- Corresponding to denyImportClasses, denyImportPackages is package-level --\u0026amp;gt; \u0026amp;lt;denyImportPackages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/denyImportPackages\u0026amp;gt; \u0026amp;lt;!-- denyImportResources can prevent resource exported by ark plugin with accurate name to be resolved --\u0026amp;gt; \u0026amp;lt;denyImportResources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test1.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test2.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;/denyImportResources\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 插件配置项解释：\n outputDirectory: 执行 mvn package 命令后，指定打出来的 ark 包存放目录，默认存放至 ${project.build.directory} arkClassifier: 执行 mvn depleoy 命令后，指定发布到仓库的 ark 包的maven坐标的 classifer 值, 默认为空；我们推荐配置此配置项用于和普通的 Fat Jar 加以名字上区别； denyImportClasses: 默认情况下，应用会优先加载 ark plugin 导出的类，使用该配置项，可以禁止应用从 ark plugin 加载其导出类； denyImportPackages: 对应上述的 denyImportClasses, 提供包级别的禁止导入； denyImportResources: 默认情况下，应用会优先加载 ark plugin 导出的资源，使用该配置项，可以禁止应用从 ark plugin 加载其导出资源； 添加类隔离框架依赖 在实际开发中，为了在跑测试用例时使用 SOFABoot 类隔离能力，需要在 SOFABoot 工程中添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 根据 SpringBoot 依赖即服务的原则，添加该依赖之后，应用启动之前，会优先启动 SOFABoot 类隔离容器；\nSOFABoot 的类隔离框架会自动检测应用中是否有引入 Ark Plugin（即需要被隔离的jar包，详情请参考 SOFAArk）, 并隔离加载；例如为了避免 SOFABoot 官方提供的 SOFARPC 组件和应用产生依赖冲突，SOFABoot提供了 SOFARPC 组件对应的 ark plugin 版，用户如果需要隔离 SOFARPC，只需要添加如下组件：\n\u0026amp;lt;dependency\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/classloader-isolation/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e007416ab008c1dd4b886433dbf8af01","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/classloader-isolation/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/classloader-isolation/","summary":"SOFABoot 提供了类隔离框架 SOFAArk, 弥补了 Spring Boot 在类隔离能力上的缺失，用以解决在实际开发中常见的类冲突、包冲突问题，详细请参考 SOFAArk。 在 SOFABoot 工程中使用类","tags":null,"title":"SOFABoot 使用类隔离","type":"projects","url":"/sofastack.tech/projects/sofa-boot/classloader-isolation/","wordcount":1667},{"author":null,"categories":null,"content":" SOFABoot 动态模块实践 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n 实验背景 实验内容 任务 任务准备 将 SOFABoot 应用打包成 ark 包 修改动态模块名称 配置动态模块的打包插件 构建宿主应用 引入动态模块依赖 宿主应用配置 打包 \u0026amp;amp; 启动宿主应用 SOFADashboard 添加版本\u0026amp;amp;管理应用 查看详情 \u0026amp;amp; 推送安装命令 实验背景 kc-sofastack-demo 分享中已经通过 SOFAStack 快速构建了一个电商微服务应用， 并且完成了对应用服务调用链路的跟踪及应用状态的监控。\n在电商系统中，平台方往往不会满足商品的自然排序展示，必定会根据某种规则来将部分商品放置在列表最瞩目的地方， 当然也可能是平台方通过收集用户行为动态的为每个不同的用户推荐不同的商品展示列表。\n本实验背景就是基于kc-sofastack-demo的基础上， 根据现场同学对每个商品的购买总数（通过订单统计）来对商品列表进行动态排序。\n实验内容 通过 SOFABoot 提供的动态模块能力及 SOFADashboard 的动态模块管控能力，实现商品列表排序策略的动态变更。通过在不重启宿主机，不更改应用配置的情况下实现 应用行为的改变。\n 项目工程架构图如下 任务 1、任务准备 从 github 上将 demo 工程克隆到本地\ngit clone https://github.com/sofastack-guides/kc-sofastack-dynamic-demo.git 然后将工程导入到 IDEA 或者 eclipse。\n2、将 SOFABoot 应用打包成 ark 包 step1 : 修改动态模块名称 在实际的应用场景中，不需要对其进行任何修改\n 如下图所示，对 dynamic-module/pom.xml 中的 artifactId 进行修改，将 {your-number} 修改为当前座位上的编号\nstep2 : 配置动态模块的打包插件 在 dynamic-provider/pom.xml 中，增加 ark 打包插件，并进行配置：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!--ark-biz 包的打包配置 --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- ark-biz 包的启动优先级，值越小，优先级越高--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;200\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--设置应用的根目录，用于读取 ${base.dir}/conf/ark/bootstrap.application 配置文件，默认为 ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;../\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 3、构建宿主应用 在已下载下来的工程中，dynamic-stock-mng 作为实验的宿主应用工程模型。通过此任务，将 dynamic-stock-mng 构建成为动态模块的宿主应用。\nstep1 : 引入动态模块依赖 动态模块是通过 SOFAArk 组件来实现的，因此次数需要引入 SOFAArk 相关的依赖即可。关于 SOFAArk 可以参考SOFABoot 类隔离 一节进行了解。\n SOFAArk 相关依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;web-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;config-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.sofastack\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dynamic-provider-{your-number}\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 将此配置文件中的 {your-number} 替换为当前座位编号\n 宿主应用打包插件 \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; …","date":-62135596800,"description":"本指南将基于 SOFADashboard 的 ARK 管控能力来实现 SOFAArk 提供的合并部署和动态模块推送的功能。","dir":"guides/kc-sofastack-dynamic-demo/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8bfd4a50e21ce9fc867b1cf18a8c9af3","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-sofastack-dynamic-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/guides/kc-sofastack-dynamic-demo/","summary":"SOFABoot 动态模块实践 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 实验背景 实验内容 任务 任务准备 将 SOFABoot 应用打包成 ark 包 修改动态模","tags":null,"title":"SOFABoot 动态模块实践","type":"guides","url":"/sofastack.tech/guides/kc-sofastack-dynamic-demo/","wordcount":2025},{"author":null,"categories":null,"content":" SOFABoot 支持模块化隔离，在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项目，并在上面扩展，与 Spring 融合，提供扩展点的能力。\n使用 在 SOFABoot 中使用扩展点能力，需要以下三个步骤：\n定义提供扩展能力的 bean 在使用 SOFABoot 扩展点能力时，首先需要定一个需要被扩展的 bean，先定一个接口：\npackage com.alipay.sofa.boot.test; public interface IExtension { String say(); } 定义这个接口的实现：\npackage com.alipay.sofa.boot.test.impl; public class ExtensionImpl implements IExtension { private String word; @Override public String say() { return word; } public void setWord(String word) { this.word = word; } public void registerExtension(Extension extension) throws Exception { Object[] contributions = extension.getContributions(); String extensionPoint = extension.getExtensionPoint(); if (contributions == null) { return; } for (Object contribution : contributions) { if (\u0026amp;quot;word\u0026amp;quot;.equals(extensionPoint)) { setWord(((ExtensionDescriptor) contribution).getValue()); } } } } 在这里可以看到有一个方法：registerExtension ，暂时可以先不用管这个方法，后续会介绍其具体的作用。\n在模块的 Spring 配置文件中，我们把这个 bean 给配置起来：\n\u0026amp;lt;bean id=\u0026amp;quot;extension\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.test.impl.ExtensionImpl\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;word\u0026amp;quot; value=\u0026amp;quot;Hello, world\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; 定义扩展点 在上面的 bean 中有一个字段 word ，在实际中，我们希望这个字段能够被其他的模块自定义进行覆盖，这里我们将其以扩展点的形式暴露出来。\n首先需要一个类去描述这个扩展点：\n@XObject(\u0026amp;quot;word\u0026amp;quot;) public class ExtensionDescriptor { @XNode(\u0026amp;quot;value\u0026amp;quot;) private String value; public String getValue() { return value; } } 然后在 xml 中定义扩展点：\n\u0026amp;lt;sofa:extension-point name=\u0026amp;quot;word\u0026amp;quot; ref=\u0026amp;quot;extension\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:object class=\u0026amp;quot;com.alipay.sofa.boot.test.extension.ExtensionDescriptor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:extension-point\u0026amp;gt; 其中： - name 为扩展点的名字 - ref 为扩展点所作用在的 bean - object 为扩展点的贡献点具体的描述，这个描述是通过 XMap 的方式来进行的(XMap 的作用是将 Java 对象和 XML 文件进行映射，这里建议通过在网上搜索下 XMap 的文档来了解 XMap)\n定义扩展 上述已经将扩展点定义好了，此时我们就可以对这个 bean 进行扩展了:\n\u0026amp;lt;sofa:extension bean=\u0026amp;quot;extension\u0026amp;quot; point=\u0026amp;quot;word\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:content\u0026amp;gt; \u0026amp;lt;word\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;newValue\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/word\u0026amp;gt; \u0026amp;lt;/sofa:content\u0026amp;gt; \u0026amp;lt;/sofa:extension\u0026amp;gt; 其中： - bean 为扩展所作用在的 bean - point 为扩展点的名字 - content 里面的内容为扩展的定义，其会通过 XMap 将内容解析为：扩展点的贡献点具体的描述对象，在这里即为 com.alipay.sofa.boot.test.extension.ExtensionDescriptor 对象\n到这里，我们可以回头看一开始在 com.alipay.sofa.boot.test.impl.ExtensionImpl 中定义的 registerExtension 方法了，SOFABoot 在解析到贡献点时，会调用被扩展 bean 的 registerExtension 方法，其中包含了用户定义的贡献点处理逻辑，在上述的例子中，获取用户定义的 value 值，并将其设置到 word 字段中覆盖 bean 中原始定义的值。\n此时，调用 extension bean 的 say() 方法，可以看到返回扩展中定义的值: newValue 。\nXMap 支持和扩展 上述的例子中只是一个很简单的扩展，其实 XMap 包含了非常丰富的描述能力，包括 List, Map 等，这些可以通过查看 XMap 的文档来了解。\n在 SOFABoot 中，除了 XMap 原生的支持以外，还扩展了跟 Spring 集成的能力： - 通过 XNode 扩展出了 XNodeSpring - 通过 XNodeList 扩展出了 XNodeListSpring - 通过 XNodeMap 扩展出了 XNodeMapSpring\n这部分的扩展能力，让扩展点的能力更加丰富，描述对象中可以直接指向一个 SpringBean(用户配置 bean 的名字，SOFABoot 会根据名字从 spring 上下文中获取到 bean)，这里举一个使用 XNodeListSpring 的例子，依然是上述描述的三个步骤：\n定义提供扩展能力的 bean 接口定义：\n在这个接口里，返回一个 list，目标是这个 list 能够被通过扩展的方式填充\npackage com.alipay.sofa.boot.test; public interface IExtension { …","date":-62135596800,"description":"","dir":"projects/sofa-boot/extension/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"93225b6c1f2b68f2047a7cf49b76650b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/extension/","summary":"SOFABoot 支持模块化隔离，在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项","tags":null,"title":"SOFABoot 拓展点","type":"projects","url":"/sofastack.tech/projects/sofa-boot/extension/","wordcount":1959},{"author":null,"categories":null,"content":" 本文档将演示了如何在 SOFABoot 环境下应用 SOFARPC 进行服务的发布和引用。 您可以直接在工程下找到本文档的示例代码。注意，示例代码中需要本地安装 zookeeper 环境，如果没有安装。需要将application.properties中的com.alipay.sofa.rpc.registry.address 配置注释掉，走本地文件注册中心的方式。\n创建工程 环境准备：SOFABoot 需要 JDK7 或者 JDK8 ，需要采用 Apache Maven 2.2.5 或者以上的版本来编译。 工程构建：SOFABoot 构建在 Spring Boot 之上。因此可以使用 Spring\u0026amp;nbsp;Boot\u0026amp;nbsp;的工程生成工具来生成一个标准的Spring Boot 工程。 引入 SOFABoot 环境：生成的 Spring Boot 标准工程直接使用的 Spring Boot 的 parent 依赖，改为 SOFABoot 提供的 parent 依赖，该parent 提供并管控了多种 SOFABoot 提供的 starter。 \u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa-boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa-boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n 配置 application.properties ：application.properties 是 SOFABoot 工程中的配置文件。这里需要配置一个必不可少的配置项，即应用名。 spring.application.name=AppName 引入 RPC Starter： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 定义服务接口 public interface AnnotationService { String sayAnnotation(String string); } 服务端发布服务 通过 @SofaService注解发布服务，如下代码所示：\nSOFABoot 扫描到该注解，就会将该服务实现发布到服务器，同时指定了 bolt 协议与客户端进行通信地址，并将地址等元数据发布到了注册中心（这里默认使用的本地文件作为注册中心）。\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } 客户端引用服务 通过@SofaReference注解引用服务，如下代码所示： SOFABoot 会生成一个 AnnotationService RPC 的代理 bean，同时指定了 bolt 协议与服务端通信。这样就可以直接在代码中使用该 bean 进行远程服务的调用了。\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } 运行 在 SpringBoot 的启动类中编码如下： 启动服务端\n@SpringBootApplication public class AnnotationServerApplication { public static void main(String[] args) { SpringApplication springApplication = new SpringApplication( AnnotationServerApplication.class); ApplicationContext applicationContext = springApplication.run(args); } } 启动客户端，获取AnnotationClientImpl的实现 bean，并调用 sayClientAnnotation，间接通过@SofaReference生成的代理类调用远程服务 AnnotationServiceImpl。\npublic class …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-sofa-boot/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0dd5e0e5116473aee630cba38679d493","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","summary":"本文档将演示了如何在 SOFABoot 环境下应用 SOFARPC 进行服务的发布和引用。 您可以直接在工程下找到本文档的示例代码。注意，示例代码中需要本地安装 zookeeper 环境，如果没有","tags":null,"title":"SOFABoot 方式快速入门","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","wordcount":990},{"author":null,"categories":null,"content":"声明 SOFABoot 的 xsd 文件：在要使用的 XML 配置文件中将头部 xsd 文件的声明设置为如下。这样就能够使用 SOFABoot 定义的 XML 元素进行开发。\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xmlns:context=\u0026amp;quot;http://www.springframework.org/schema/context\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; 在xml方式中发布和引用服务的方式如下。 sofa:service 元素表示发布服务， sofa:reference 元素表示引用服务。 sofa:binding 表示服务发布或引用的协议。\n\u0026amp;lt;bean id=\u0026amp;quot;personServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 一个服务也可以通过多种协议进行发布，如下：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 服务引用\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 也可以是其他的协议\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceRest\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-xml/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9192a93415bee3070a9be62c0f693949","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","summary":"声明 SOFABoot 的 xsd 文件：在要使用的 XML 配置文件中将头部 xsd 文件的声明设置为如下。这样就能够使用 SOFABoot 定义的 XML 元素进行开发。 \u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;beans xmlns=\u0026quot;http://www.springframework.org/schema/beans\u0026quot; xmlns:xsi=\u0026quot;http://www.w3.org/2001/XMLSchema-instance\u0026quot; xmlns:sofa=\u0026quot;http://sofastack.io/schema/sofaboot\u0026quot; xmlns:context=\u0026quot;http://www.springframework.org/schema/context\u0026quot; xsi:schemaLocation=\u0026quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026quot; default-autowire=\u0026quot;byName\u0026quot;\u0026gt; 在xml","tags":null,"title":"SOFABoot 环境 XML 配置使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","wordcount":179},{"author":null,"categories":null,"content":"SOFABoot 为 RPC 服务的发布和引用提供了一套编程 API 方式，方便直接在代码中发布和引用 RPC 服务，与 Spring 的 ApplicationContextAware 类似，为使用编程 API 方式，首先需要实现 ClientFactoryAware 接口获取编程组件 API：\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } 以 DirectService 为例，看下如何使用 clientFactory 通过编程 API 方式发布 RPC 服务：\nServiceClient serviceClient = clientFactory.getClient(ServiceClient.class); ServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(DirectService.class); serviceParam.setInstance(new DirectServiceImpl()); List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); serviceClient.service(serviceParam); 上面的代码中\n 首先通过 clientFactory 获得 ServiceClient 对象 然后构造 ServiceParam 对象，ServiceParam 对象包含发布服务所需参数，通过 setInstance 方法来设置需要被发布成 RPC 服务的对象，setInterfaceType 来设置服务的接口 最后，调用 ServiceClient 的 service 方法，发布一个 RPC 服务 通过编程 API 方式引用 RPC 服务的代码也是类似的：\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt;(); referenceParam.setInterfaceType(DirectService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); DirectService proxy = referenceClient.reference(referenceParam); proxy.sayDirect(\u0026amp;quot;hello\u0026amp;quot;); 同样，引用一个 RPC 服务只需从 ClientFactory 中获取一个 ReferenceClient ，然后和发布一个服务类似，构造出一个 ReferenceParam，然后设置好服务的接口，最后调用 ReferenceClient 的 reference 方法即可。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-api/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2679388dc3459714f869d8f8a71739d7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","summary":"SOFABoot 为 RPC 服务的发布和引用提供了一套编程 API 方式，方便直接在代码中发布和引用 RPC 服务，与 Spring 的 ApplicationContextAware 类似，为使用编程 API 方式，首先需要实现 ClientFactoryAware 接口获取编程组件","tags":null,"title":"SOFABoot 环境动态 API 使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","wordcount":374},{"author":null,"categories":null,"content":" 这部分介绍在 SOFABoot 环境下,完整的 SOFARPC 服务发布与引用说明\n发布服务 \u0026amp;lt;bean id=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; thread-pool-ref=\u0026amp;quot;\u0026amp;quot; warm-up-time=\u0026amp;quot;60000\u0026amp;quot; warm-up-weight=\u0026amp;quot;10\u0026amp;quot; weight=\u0026amp;quot;100\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 属性 名称 默认值 备注 id ID bean名 class 类 无 ref 服务接口实现类 interface 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 unique-id 服务标签（唯一标识元素） filter 过滤器配置别名 多个用逗号隔开 registry 服务端注册中心 逗号分隔 timeout 服务端执行超时时间 serialize-type 序列化协议 hessian2,protobuf thread-pool-ref 服务端当前接口使用的线程池 无 weight 服务静态权重 warm-up-weight 服务预热权重 warm-up-time 服务预热时间 单位毫秒 引用服务 \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;helloSyncServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;sync\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; address-wait-time=\u0026amp;quot;1000\u0026amp;quot; connect.num=\u0026amp;quot;1\u0026amp;quot; check=\u0026amp;quot;false\u0026amp;quot; connect.timeout=\u0026amp;quot;1000\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; generic-interface=\u0026amp;quot;\u0026amp;quot; idle.timeout=\u0026amp;quot;1000\u0026amp;quot; idle.timeout.read=\u0026amp;quot;1000\u0026amp;quot; lazy=\u0026amp;quot;false\u0026amp;quot; loadBalancer=\u0026amp;quot;\u0026amp;quot; registry=\u0026amp;quot;\u0026amp;quot; retries=\u0026amp;quot;1\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;xxx:12200\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; type=\u0026amp;quot;sync\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 属性 名称 默认值 备注 id ID 自动生成 jvm-first 是否优先本地 true interface 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 unique-id 服务标签（唯一标识元素） type 调用方式 sync callback,sync,future,oneway filter 过滤器配置别名 List registry 服务端注册中心 List method 方法级配置 说明同上 serialize-type 序列化协议 hessian2 target-url 直连地址 直连后register generic-interface 泛化接口 connect.timeout 建立连接超时时间 3000(cover 5000) connect.num 连接数 1 idle.timeout 空闲超时时间 idle.timeout.read 读空闲超时时间 loadBalancer 负载均衡算法 random lazy 是否延迟建立长连接 false address-wait-time 等待地址获取时间 -1 取决于实现，可能不生效。 timeout 调用超时时间 3000(cover 5000) retries 失败后重试次数 0 跟集群模式有关，failover读取此参数。 callback-class callback 回调类 无 callback 才可用 callback-ref callback 回调类 无 callback 才可用 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/rpc-config-xml-explain/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4b5110e9eb6cf6c6f287aef0fd210047","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","summary":"这部分介绍在 SOFABoot 环境下,完整的 SOFARPC 服务发布与引用说明 发布服务 \u0026lt;bean id=\u0026quot;helloSyncServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;helloSyncServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026quot; unique-id=\u0026quot;\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs registry=\u0026quot;\u0026quot; serialize-type=\u0026quot;\u0026quot; filter=\u0026quot;\u0026quot; timeout=\u0026quot;3000\u0026quot; thread-pool-ref=\u0026quot;\u0026quot; warm-up-time=\u0026quot;60000\u0026quot; warm-up-weight=\u0026quot;10\u0026quot; weight=\u0026quot;100\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;sofa:binding.rest\u0026gt; \u0026lt;/sofa:binding.rest\u0026gt; \u0026lt;/sofa:service\u0026gt; 属性 名称 默认值 备注 id ID bean名 class 类 无 ref 服","tags":null,"title":"SOFABoot 环境发布订阅说明","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","wordcount":518},{"author":null,"categories":null,"content":" 注解服务发布与服务引用 除了常规的 xml 方式发布服务外，我们也支持在SOFABoot 环境下，注解方式的发布与引用，同 xml 类似，我们有 @SofaService 和 @SofaReference，同时对于多协议，存在@SofaServiceBinding 和 @SofaReferenceBinding 注解。\n服务发布 如果要发布一个 RPC 服务。我们只需要在 Bean 上面打上@SofaService注解。指定接口和协议类型即可。\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } 服务引用 对于需要引用远程服务的 bean, 只需要在属性，或者方法上，打上@SofaReference的注解即可，支持 bolt, dubbo, rest 协议。\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } 使用演示 可以在 sample 工程目录的 annotation 子项目中进行验证测试。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-annotation/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2c3afd33cbce4f5aa2473716b3afe5a6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","summary":"注解服务发布与服务引用 除了常规的 xml 方式发布服务外，我们也支持在SOFABoot 环境下，注解方式的发布与引用，同 xml 类似，我们有 @SofaService 和 @SofaR","tags":null,"title":"SOFABoot 环境注解使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","wordcount":317},{"author":null,"categories":null,"content":" SOFADashboard is designed to implement unified management over SOFA framework components, including service governance and SOFAArk control. All technology stacks used by SOFADashboard are developed and constructed based on open-source community products, such as Ant Design Pro, SOFABoot, Spring, and MyBatis.\nCurrently, service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper. Therefore, you need to ensure the ZooKeeper service is available when you decide to use SOFADashboard. You also need to ensure that MySQL is available, because SOFAArk control and deployment uses MySQL for resource data storage.\nArchitecture Currently, service governance and SOFAArk control of SOFADashboard are implemented upon ZooKeeper-based programming.\n SOFADashboard backend corresponds to the sofa-dashboard-backend project. It is the server end project of SOFADashboard, responsible for data interaction between ZooKeeper and MySQL and for providing the rest API to the SOFADashboard frontend. SOFADashboard frontend corresponds to the sofa-dashboard-frontend project. It is the frontend project of SOFADashboard. It provides UIs for interaction with users. Application rpc provider: service provider of SOFARPC, which registers services with ZooKeeper. rpc consumer: service consumer of SOFARPC, which subscribes to services on ZooKeeper. client: SOFADashboard client, which is available upon the installation of the sofa-dashboard-client package. Currently, the SOFADashboard client only supports registration of health-check status and port information of applications with ZooKeeper. Later on, it will evolve into SOFABoot client, and report more diversified application data. ark-biz host app: see SOFAArk. ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f0664d0ca7fc1fa87e67847525081993","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/overview/","summary":"SOFADashboard is designed to implement unified management over SOFA framework components, including service governance and SOFAArk control. All technology stacks used by SOFADashboard are developed and constructed based on open-source community products, such as Ant Design Pro, SOFABoot, Spring, and MyBatis.\nCurrently, service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper. Therefore, you need to ensure the ZooKeeper service is available when you decide to use SOFADashboard. You also need to ensure that MySQL is available, because SOFAArk control and deployment uses MySQL for resource data storage.","tags":null,"title":"SOFADashboard overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/overview/","wordcount":230},{"author":null,"categories":null,"content":" SOFADashboard 致力于对 SOFA 框架中组件进行统一管理，包括服务治理、SOFAArk 管控等。SOFADashboard 本身所用技术栈均基于开源社区产品来开发构建，包括：Ant Design Pro、SOFABoot、Spring、MyBatis 等。\n目前，SOFADashboard 中的服务治理、SOFAArk 管控等需要依赖于 Zookeeper，因此如果您需要使用 SOFADashboard 那么请确保 Zookeeper 服务可用；另外 SOFAArk 管控部署需要依赖 MySQL 进行资源数据存储，因此也需要保证 MySQL 可以正常使用。\n架构简图 SOFADashboard 目前服务治理与 SOFAArk 管控都是面向 Zookeeper 来编程实现的。\n SOFADashboard backend : 对应 sofa-dashboard-backend 工程，是 SOFADashboard 的服务端工程，负责与 Zookeeper 和 MySQL 进行数据交互，并且为 SOFADashboard frontend 提供 rest 接口。 SOFADashboard frontend : 对应 sofa-dashboard-frontend 工程，是 SOFADashboard 的前端工程，用于提供与用户交互的 UI 界面。 app 应用 rpc provider : SOFARPC 的服务提供方，会将服务注册到 Zookeeper 上。 rpc consumer : SOFARPC 的服务消费方，会从 Zookeeper 上订阅服务。 client : SOFADashboard 客户端，引入 sofa-dashboard-client 包即可。目前仅提供将应用的健康检查状态及端口信息注册到 Zookeeper ，后面将会演化成 SOFABoot client，上报更丰富的应用数据。 ark-biz 宿主应用: 参考 SOFAArk 。 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f0664d0ca7fc1fa87e67847525081993","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/overview/","summary":"SOFADashboard 致力于对 SOFA 框架中组件进行统一管理，包括服务治理、SOFAArk 管控等。SOFADashboard 本身所用技术栈均基于开源社区产品来开发构建","tags":null,"title":"SOFADashboard 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/overview/","wordcount":431},{"author":null,"categories":null,"content":" This topic is a part of the Braft document. To read the Braft document, click here. The Raft algorithm and its application are comprehensively described in the Braft document. As JRaft is designed on the basis of Braft, we strongly recommend that you read the Braft document first to understand the basic principles and application of the Raft algorithm.\nDistributed consensus Distributed consensus is a very fundamental problem in a distributed system. Simply put, it is about how to reach a consensus on a specific value among multiple servers, and ensure that the decision is not overthrown regardless of what failures may occur on these servers. Assume that, all processes of a distributed system needs to determine a value V. If the system has the following properties, we consider it solves the problem of distributed consensus:\n Termination: All normal processes will determine the specific value of V, and there is no process that keeps running in a loop. Validity: A value V\u0026amp;rsquo; determined by normal processes must have been proposed by one of them. For example, a random number generator does not have this property. Agreement: All normal processes choose the same value. Consensus state machine Assume we have an infinitely incrementing sequence (system) a[1, 2, 3…]. If for any integer i, the value of a[i] meets the distributed consensus requirement, the system meets the requirement of a consensus state machine. Basically, all systems are subject to continuous operations, and reaching consensus on a single value is definitely not enough. To make sure all replicas of a real-life system are consistent, we usually convert the operations into entries of a write-ahead-log(WAL). Then, we make sure all replicas of the system reach a consensus on the WAL entries, so that each process will perform operations corresponding to the WAL entries in order. As a result, the replicas are in consistent states.\nRAFT RAFT is a new and easy-to-understand distributed consensus replication protocol proposed by Diego Ongaro and John Ousterhout of Stanford University as a central coordination component of the RAMCloudproject. Raft is a leader-based multi-Paxos variant that provides a more complete and straightforward protocol description than existing protocols such as Paxos, Zab, and Viewstamped Replication. It also provides a clear description for adding and deleting nodes. In Raft, replicated state machines are the most important and fundamental to distributed systems. Raft allows commands to be replicated and executed in order, and ensures that the states of nodes remain consistent when their initial states are the same. A system is fully functional (available) as long as a majority of nodes function properly. It allows non-Byzantine conditions, including network delays, packet loss, and reordering, but does not allow tampering with any messages.\nRaft can solve the distributed consensus and partitioning problems, but cannot solve the availability problem. Raft covers …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/overview/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"eff7088d010aefabdffa2858e88d76c0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/overview/","summary":"This topic is a part of the Braft document. To read the Braft document, click here. The Raft algorithm and its application are comprehensively described in the Braft document. As JRaft is designed on the basis of Braft, we strongly recommend that you read the Braft document first to understand the basic principles and application of the Raft algorithm.\nDistributed consensus Distributed consensus is a very fundamental problem in a distributed system.","tags":null,"title":"SOFAJRaft overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/overview/","wordcount":645},{"author":null,"categories":null,"content":" 本介绍内容来自 braft 文档，原文链接请参见这里。braft 的关于算法和应用本身的文档非常优秀，由于 jraft 脱胎自 braft，我们强烈推荐阅读上述文档以了解 raft 算法的基本原理和应用。\n分布式一致性 分布式一致性 (distributed consensus) 是分布式系统中最基本的问题，用来保证一个分布式系统的可靠性以及容灾能力。简单的来讲，就是如何在多个机器间对某一个值达成一致, 并且当达成一致之后，无论之后这些机器间发生怎样的故障，这个值能保持不变。 抽象定义上， 一个分布式系统里的所有进程要确定一个值 v，如果这个系统满足如下几个性质， 就可以认为它解决了分布式一致性问题, 分别是:\n Termination: 所有正常的进程都会决定 v 具体的值，不会出现一直在循环的进程。 Validity: 任何正常的进程确定的值 v\u0026amp;rsquo;, 那么 v\u0026amp;rsquo; 肯定是某个进程提交的。比如随机数生成器就不满足这个性质。 Agreement: 所有正常的进程选择的值都是一样的。 一致性状态机 对于一个无限增长的序列 a[1, 2, 3…], 如果对于任意整数 i, a[i] 的值满足分布式一致性，这个系统就满足一致性状态机的要求。 基本上所有的系统都会有源源不断的操作, 这时候单独对某个特定的值达成一致是不够的。为了真实系统保证所有的副本的一致性，通常会把操作转化为 write-ahead-log(简称WAL)。然后让系统的所有副本对WAL保持一致，这样每个进程按照顺序执行WAL里的操作，就能保证最终的状态是一致的。\nRAFT RAFT 是一种新型易于理解的分布式一致性复制协议，由斯坦福大学的 Diego Ongaro 和 John Ousterhout 提出，作为 RAMCloud 项目中的中心协调组件。Raft 是一种 Leader-Based 的 Multi-Paxos 变种，相比 Paxos、Zab、View Stamped Replication 等协议提供了更完整更清晰的协议描述，并提供了清晰的节点增删描述。 Raft 作为复制状态机，是分布式系统中最核心最基础的组件，提供命令在多个节点之间有序复制和执行，当多个节点初始状态一致的时候，保证节点之间状态一致。系统只要多数节点存活就可以正常处理，它允许消息的延迟、丢弃和乱序，但是不允许消息的篡改（非拜占庭场景）。\nRaft 可以解决分布式理论中的 CP，即一致性和分区容忍性，并不能解决 Available 的问题。其中包含分布式系统中一些通常的功能：\n Leader Election Log Replication Membership Change Log Compaction RAFT 可以做什么 通过 RAFT 提供的一致性状态机，可以解决复制、修复、节点管理等问题，极大的简化当前分布式系统的设计与实现，让开发者只关注于业务逻辑，将其抽象实现成对应的状态机即可。基于这套框架，可以构建很多分布式应用：\n 分布式锁服务，比如 Zookeeper 分布式存储系统，比如分布式消息队列、分布式块系统、分布式文件系统、分布式表格系统等 高可靠元信息管理，比如各类 Master 模块的 HA JRAFT 一个纯 Java 的 Raft 算法实现库, 基于百度 braft 实现而来, 使用 Java 重写了所有功能, 支持:\n Leader election and priority-based semi-deterministic leader election. Replication and recovery. Snapshot and log compaction. Read-only member (learner). Membership management. Fully concurrent replication. Fault tolerance. Asymmetric network partition tolerance. Workaround when quorate peers are dead. Replication pipeline optimistic Linearizable read, ReadIndex/LeaseRead. 联系我们 更多讨论欢迎加入钉钉讨论群：44858463\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/overview/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"eff7088d010aefabdffa2858e88d76c0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-jraft/overview/","summary":"本介绍内容来自 braft 文档，原文链接请参见这里。braft 的关于算法和应用本身的文档非常优秀，由于 jraft 脱胎自 braft，我们强烈推荐阅读上述文档以了","tags":null,"title":"SOFAJRaft 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/overview/","wordcount":1132},{"author":null,"categories":null,"content":" SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\n1.客户端部分 SOFALookout Client 是一个 Java 的 SDK，可以帮助开发者在项目代码中进行 metrics 埋点。通过它也可以查看该 JAVA 应用的实时的状态信息。\n +------------------+ Reg: API: | dimension meters +--------+ +------------------+ | flatmap +---------------------------+ +-----------\u0026amp;gt; | Default/DropwizardMetrics| | +---------------------------+ | | http +--------------+ +-----------\u0026amp;gt; |Lookout server| | +--------------+ +----------------------+ | add common tags dimension EXTS: | JVM,OS,GC... +----+ +----------------------+ 2.服务器端服务 SOFALookout Server 可以帮助我们解决分布式环境下系统状态度量的问题，它提供丰富的协议接入支持，包括自有SDK（SOFALookout Client）上报协议，还支持 Prometheus 的数据协议（推模式和拉模式），Metricbeat 协议（版本是6），Opentsdb写入协议。 Lookout Server 兼容和增强了 Prometheus 的数据及元数据查询的 RESTful API。同样对应 PromQL 我们也基本实现了兼容和增强（不包括 Alert 相关语法）。\n2.1.Metrics 服务器端主要特性: 适配社区主要 Metrics 数据源协议写入（比如: Prometheus，Metricbeat等）； 数据的存储支持扩展，暂时开源版默认支持 Elasticsearch,并且透明和自动化了相关运维操作； 遵循 Prometheus 查询 API 的标准以及支持 PromQL，并进行了适当改进； 自带数据查询的控制台，并支持 Grafana 进行数据可视化； 使用简单，支持单一进程运行整个服务器端模块。 2.2.Metrics 服务器端工作机制: +----------------+ | Lookout Client +-----+ +----------------+ | +----------------+ | | Prometheus SDK +-----+ +-------------------+ +----------------------+ +------------------+ +-----------+ +----------------+ +--\u0026amp;gt; Lookout Gateway +---\u0026amp;gt; DB(ES/InfluxDB...) \u0026amp;lt;-----+ Lookout Server \u0026amp;lt;----+ Grafana | +----------------+ | +-------------------+ +----------------------+ +------------------+ +-----------+ | Metricbeat +-----+ +----------------+ | +----------------+ | | ... +-----+ +----------------+ ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/overview/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8a8a8ef02ca95d4d11e3e4b195bbae70","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/overview/","summary":"SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项","tags":null,"title":"SOFALookout 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/overview/","wordcount":602},{"author":null,"categories":null,"content":" 1.使用本机 ES 服务 1)本地启动 ES docker run -d --name es -p 9200:9200 -p 9300:9300 -e \u0026amp;quot;discovery.type=single-node\u0026amp;quot; elasticsearch:5.6 版本：V5，V6\n 2)检查 ES 是否健康 http://localhost:9200/_cat/health?v 3)启动 Lookout 服务 执行 all-in-one-bootstrap 编译后的 fat-jar 包，如何获得，见文末备注部分：\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -jar lookout-all-in-one-bootstrap-1.6.0-executable-ark.jar 注意 -Dcom.alipay.sofa.ark.master.biz=lookoutall 是必须的, 用于设置 sofa-ark 的 master biz。\n 4)最后进行功能验证\n 查询 （Gateway）的 metrics 作为功能验证，访问“localhost:9090”，在查询框输入：\njvm.memory.heap.used{app=\u0026amp;quot;gateway\u0026amp;quot;} 最后，也可以使用 grafana\n2.使用远程 ES 服务 总体步骤和“使用本机 ES 服务”类似，唯一不同的是，需要指定配置文件。\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -Dlookoutall.config-file=abc.properties \\ -jar lookout-all-in-one-bootstrap-1.6.0-executable-ark.jar -Dlookoutall.config-file（如果你本地启动 ES 测试的话则该配置项可以忽略！），该配置项制定的文件暂时只能引用文件系统上的 properties 文件(没有像 spring-boot 支持那么丰富），配置项必须以应用名开头，从而提供隔离能力。\n例如：在fat-jar同目录下创建一个abc.properties配置文件, 用于存放存放配置文件(下面列出了必须的配置项,用于指向使用的 ES 服务地址）：\ngateway.metrics.exporter.es.host=localhost gateway.metrics.exporter.es.port=9200 metrics-server.spring.data.jest.uri=http://localhost:9200 备注 如何获得 all-in-one-bootstrap 编译后的 fat-jar。\n方式1：本地编译\n./boot/all-in-one-bootstrap/build.sh 打包结果在boot/all-in-one-bootstrap/target/allinone-executable.jar\n 方式2：发布报告中附件获取\n临时方式（针对 1.6.0）暂时提供一个 v1.6.0的snapshot包，下载后（保证ES服务已经单独启动）运行：\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -jar lookout-all-1.6.0.snapshot.jar 方式3：使用docker镜像\n服务端默认会连接到 localhost:9200 的ES实例, 而我所用的开发机器是MacOS，无法使用 --net=host 模式启动容器，因此在容器内无法通过 localhost:9200 连接ES，需要使用如下方式绕过去：\n编辑一个配置文件，比如 foo.properties：\ngateway.metrics.exporter.es.host=es metrics-server.spring.data.jest.uri=http://es:9200 在 foo.properties 所在的目录下运行 all-in-one 镜像：\ndocker run -it \\ --name allinone \\ --link es:es \\ -p 7200:7200 \\ -p 9090:9090 \\ -v $PWD/foo.properties:/home/admin/deploy/foo.properties \\ -e JAVA_OPTS=\u0026amp;quot;-Dlookoutall.config-file=/home/admin/deploy/foo.properties\u0026amp;quot; \\ -e JAVA_OPTS=\u0026amp;quot;...定制JVM系统属性...\u0026amp;quot; \\ xzchaoo/lookout-allinone:1.6.0-SNAPSHOT 这里利用了docker的\u0026amp;ndash;link参数使得应用可以访问到ES实例 这里做测试用，所以不用-d参数在后台运行\n ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-metrics-server/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7c12565c66342c2f8e963cf1c1e26db5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","summary":"1.使用本机 ES 服务 1)本地启动 ES docker run -d --name es -p 9200:9200 -p 9300:9300 -e \u0026quot;discovery.type=single-node\u0026quot; elasticsearch:5.6 版本：V5，V6 2)检查 ES 是否健康 http://localhost:9200/_cat/health?v 3)启动 Lookout 服务 执行 all-in-one-bootstrap 编译后的 fat-jar 包，如何获得，见文","tags":null,"title":"SOFALookout 服务端快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","wordcount":808},{"author":null,"categories":null,"content":" This repository is deprecated. It will contribute to istio directly instead of developing in a forked repo. Please go to see Istio’s doc.\nSOFAMesh is a large-scale implementation scheme of Service Mesh based on Istio. On the basis of inheriting the powerful functions and rich features of Istio, in order to meet the performance requirements in large-scale deployments and to respond to the actual situation in the implementation, the following improvements are made:\n MOSN written in Golang instead of Envoy Merge Mixer to data plane to resolve performance bottlenecks Enhance Pilot for more flexible service discovery mechanism Added support for SOFA RPC, Dubbo The initial version was contributed by Ant Financial and Alibaba UC Business Unit.\nThe following figure shows the architectural differences between SOFAMesh and Istio:\nMain components MOSN In SOFAMesh, the data pane adopts Golang to write a module called MOSN (Modular Open Smart Network), and replaces Envoy with MOSN to integrate with Istio to implement the functions of Sidecar. MOSN is fully compatible with Envoy\u0026amp;rsquo;s APIs.\nSOFAMesh Pilot SOFAMesh greatly expands and enhances the Pilot module in Istio:\n Add an Adapter for SOFA Registry to provide solutions for super large-scale service registration and discovery; Add data synchronization modules to enable data exchange between multiple service registry centers; Add Open Service Registry API to provide standardized service registration. Together with Pilot and MOSN, SOFAMesh provides the ability to enable traditional intrusive frameworks (such as Spring Cloud, Dubbo and SOFARPC) and Service Mesh products to communicate with each other, thus it can smoothly evolve and transit to Service Mesh.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e44a7cb73f7b68217663bd75655f43d7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/overview/","summary":"This repository is deprecated. It will contribute to istio directly instead of developing in a forked repo. Please go to see Istio’s doc.\nSOFAMesh is a large-scale implementation scheme of Service Mesh based on Istio. On the basis of inheriting the powerful functions and rich features of Istio, in order to meet the performance requirements in large-scale deployments and to respond to the actual situation in the implementation, the following improvements are made:","tags":null,"title":"SOFAMesh overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/overview/","wordcount":260},{"author":null,"categories":null,"content":" 该项目仓库已弃用。该项目将直接向 Istio 贡献，不会继续在 fork 的仓库中开发，请转至 Istio 官网。\nSOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强大功能和丰富特性的基础上，为满足大规模部署下的性能要求以及应对落地实践中的实际情况，有如下改进：\n 采用 Golang 编写的 MOSN 取代 Envoy 合并 Mixer 到数据平面以解决性能瓶颈 增强 Pilot 以实现更灵活的服务发现机制 增加对 SOFA RPC、Dubbo 的支持 初始版本由蚂蚁金服和阿里大文娱UC事业部携手贡献。\n下图展示了SOFAMesh 和 Istio 在架构上的不同：\n主要组件 MOSN 在 SOFAMesh 中，数据面我们采用 Golang 语言编写了名为 MOSN（Modular Open Smart Network）的模块来替代 Envoy 与 Istio 集成以实现 Sidecar 的功能，同时 MOSN 完全兼容 Envoy 的 API。\nSOFA Pilot SOFAMesh 中大幅扩展和增强 Istio 中的 Pilot 模块：\n 增加 SOFA Registry 的 Adapter，提供超大规模服务注册和发现的解决方案 增加数据同步模块，以实现多个服务注册中心之间的数据交换 增加 Open Service Registry API，提供标准化的服务注册功能 MOSN 和 Pilot 配合，将可以提供让传统侵入式框架（如 Spring Cloud、Dubbo、SOFARPC 等）和 Service Mesh 产品可以相互通讯的功能，以便可以平滑的向 Service Mesh 产品演进和过渡。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e44a7cb73f7b68217663bd75655f43d7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/overview/","summary":"该项目仓库已弃用。该项目将直接向 Istio 贡献，不会继续在 fork 的仓库中开发，请转至 Istio 官网。 SOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强","tags":null,"title":"SOFAMesh 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/overview/","wordcount":474},{"author":null,"categories":null,"content":" SOFARPC Metrics SOFARPC currently measures two metrics.\nServer thread pool metric name metric tags specification rpc.bolt.threadpool.config bolt thread pool configuration Mainly includes thread pool configuration information for RPC server rpc.bolt.threadpool.active.count Running thread of the current thread pool rpc.bolt.threadpool.idle.count Idle thread of the current thread pool rpc.bolt.threadpool.queue.size Tasks in the queue of the current thread pool Client call information metric name metric tags specification rpc.consumer.service.stats.fail_count.count app,service,method,protocol,invoke_type,target_app Failure count of a certain interface rpc.consumer.service.stats.fail_count.rate app,service,method,protocol,invoke_type,target_app Number of failures per second of a certain interface rpc.consumer.service.stats.fail_time.elapPerExec app,service,method,protocol,invoke_type,target_app Average time per failed execution of a certain interface rpc.consumer.service.stats.fail_time.max app,service,method,protocol,invoke_type,target_app Maximum failure time of a certain interface rpc.consumer.service.stats.fail_time.totalTime app,service,method,protocol,invoke_type,target_app Total failure time of a certain interface rpc.consumer.service.stats.request_size.max app,service,method,protocol,invoke_type,target_app Maximum request size of a certain interface rpc.consumer.service.stats.request_size.rate app,service,method,protocol,invoke_type,target_app Average request size per second of a certain interface rpc.consumer.service.stats.request_size.totalAmount app,service,method,protocol,invoke_type,target_app Total request amount of a certain interface rpc.consumer.service.stats.response_size.max app,service,method,protocol,invoke_type,target_app Maximum response size of a certain interface rpc.consumer.service.stats.response_size.rate app,service,method,protocol,invoke_type,target_app Average response size per second of a certain interface rpc.consumer.service.stats.response_size.totalAmount app,service,method,protocol,invoke_type,target_app Total response amount of a certain interface rpc.consumer.service.stats.total_count.count app,service,method,protocol,invoke_type,target_app Total number of calls of a certain interface rpc.consumer.service.stats.total_count.count_service_sum_30000 app,service,method,protocol,invoke_type,target_app Total call information of a certain interface rpc.consumer.service.stats.total_count.rate app,service,method,protocol,invoke_type,target_app Number of calls per second of a certain interface rpc.consumer.service.stats.total_time.elapPerExec app,service,method,protocol,invoke_type,target_app Average time per execution of a certain interface rpc.consumer.service.stats.total_time.max app,service,method,protocol,invoke_type,target_app Maximum total time of a certain interface rpc.consumer.service.stats.total_time.totalTime …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/sofarpc-metrics/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1f444349855508f4b111d8f2d2b5e43d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","summary":"SOFARPC Metrics SOFARPC currently measures two metrics.\nServer thread pool metric name metric tags specification rpc.bolt.threadpool.config bolt thread pool configuration Mainly includes thread pool configuration information for RPC server rpc.bolt.threadpool.active.count Running thread of the current thread pool rpc.bolt.threadpool.idle.count Idle thread of the current thread pool rpc.bolt.threadpool.queue.size Tasks in the queue of the current thread pool Client call information metric name metric tags specification rpc.","tags":null,"title":"SOFARPC Metrics","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","wordcount":332},{"author":null,"categories":null,"content":" SOFARPC 目前度量了两个指标。\n 服务端线程池 metric name metric tags specification rpc.bolt.threadpool.config bolt 线程池配置 主要包括 rpc 服务端的线程池配置信息 rpc.bolt.threadpool.active.count 当前线程池的运行线程 rpc.bolt.threadpool.idle.count 当前线程池的空闲线程 rpc.bolt.threadpool.queue.size 当前线程池的队列中的任务 客户端调用信息 metric name metric tags specification rpc.consumer.service.stats.fail_count.count app,service,method,protocol,invoke_type,target_app 某个具体接口失败次数 rpc.consumer.service.stats.fail_count.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒失败 rpc.consumer.service.stats.fail_time.elapPerExec app,service,method,protocol,invoke_type,target_app 某个具体接口每秒执行时间 rpc.consumer.service.stats.fail_time.max app,service,method,protocol,invoke_type,target_app 某个具体接口失败时间最大值 rpc.consumer.service.stats.fail_time.totalTime app,service,method,protocol,invoke_type,target_app 某个具体接口失败时间总值 rpc.consumer.service.stats.request_size.max app,service,method,protocol,invoke_type,target_app 某个具体接口请求大小最大值 rpc.consumer.service.stats.request_size.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒平均请求大小 rpc.consumer.service.stats.request_size.totalAmount app,service,method,protocol,invoke_type,target_app 某个具体接口请求大小总金额 rpc.consumer.service.stats.response_size.max app,service,method,protocol,invoke_type,target_app 某个具体接口响应大小最大值 rpc.consumer.service.stats.response_size.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒平均响应大小 rpc.consumer.service.stats.response_size.totalAmount app,service,method,protocol,invoke_type,target_app 某个具体接口响应大小总金额 rpc.consumer.service.stats.total_count.count app,service,method,protocol,invoke_type,target_app 某个具体接口总的调用数目 rpc.consumer.service.stats.total_count.count_service_sum_30000 app,service,method,protocol,invoke_type,target_app 某个具体接口总的调用信息 rpc.consumer.service.stats.total_count.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒调用次数 rpc.consumer.service.stats.total_time.elapPerExec app,service,method,protocol,invoke_type,target_app 某个具体接口平均每次指定时间 rpc.consumer.service.stats.total_time.max app,service,method,protocol,invoke_type,target_app 某个具体接口总时间最大值 rpc.consumer.service.stats.total_time.totalTime app,service,method,protocol,invoke_type,target_app 某个具体接口总时间 服务端被调用信息 metric name metric tags specification rpc.provider.service.stats.fail_count.count app,service,method,protocol,caller_app 某个具体接口总的被调用失败次数 rpc.provider.service.stats.fail_count.rate app,service,method,protocol,caller_app 某个具体接口每秒失败次数 rpc.provider.service.stats.fail_time.elapPerExec app,service,method,protocol,caller_app 某个具体接口每次失败失败 rpc.provider.service.stats.fail_time.max app,service,method,protocol,caller_app 某个具体接口失败次数最大值 rpc.provider.service.stats.fail_time.totalTime app,service,method,protocol,caller_app 某个具体接口失败总时间 rpc.provider.service.stats.total_count.count app,service,method,protocol,caller_app 某个具体接口总的调用次数 rpc.provider.service.stats.total_count.rate app,service,method,protocol,caller_app 某个具体接口每秒调用次 …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/sofarpc-metrics/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1f444349855508f4b111d8f2d2b5e43d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","summary":"SOFARPC 目前度量了两个指标。 服务端线程池 metric name metric tags specification rpc.bolt.threadpool.config bolt 线程池配置 主要包括 rpc 服务端的线程池配置信息 rpc.bolt.threadpool.active.count 当前线程池的运行线程 rpc.bolt.threadpool.idle.count 当前线程池的空闲线程 rpc.bolt.threadpool.queue.size 当前","tags":null,"title":"SOFARPC Metrics 指标","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","wordcount":487},{"author":null,"categories":null,"content":" SOFARPC is divided into two layers from bottom to top:\n Core layer: It contains the core components of RPC (such as various interfaces, APIs and common packages) and some common implementations (such as random load balancing algorithms). Function implementation layer: All users of the function implementation layer are equal, and all functions are implemented based on the extension mechanism. The internal version specific for Ant Financial just has some internal extension based on the open source version.\nOf course, you can add your own third-party extension. See Extension mechanism for more information.\nModule division The implementation classes of each module only appear in the modules. Generally, the modules don\u0026amp;rsquo;t depend on each other. The modules that require cross dependency have been abstracted into the core or common modules.\nCurrently, SOFARPC is divided into the following modules:\nThe main modules and their corresponding dependencies are as follows:\n Module Submodule Definition Description Dependency all Publish and packing module All modules that need to be packaged bom Dependency control module Control dependency version None example Sample module all test Test module Include integration test all core api API module Include various basic process interfaces, messages, contexts, extension interfaces and others Common core common Public module Include utils and data structure exception core exception Exception module Include various exception interfaces and others common bootstrap Startup implementation module Include start class, service publish or reference logic, and registry operations core proxy Proxy implementation module Generate interface implementation proxy core Client Client implementation module Send request, receive response, maintain connections, routing, and implement load balancing, synchronization, asynchronization and other operations server Server implementation module Start listening, receive requests, send responses, distribute business threads, and implement other operations filter Interceptor implementation module Implement various interceptors for server and client core codec Coding and encoding implementation module Implement compression, serialization and other operations core protocol Protocol implementation module Package and process protocol and conduct negotiation core transport Network transmission implementation module Establish TCP connection, process sticky data packets, and distribute requested response objects registry Registry center implementation module Implement registration centers, such as ZooKeeper core ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/structure-intro/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1902232a50d57df7ab5b2c7eea1f8caa","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/structure-intro/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/structure-intro/","summary":"SOFARPC is divided into two layers from bottom to top:\n Core layer: It contains the core components of RPC (such as various interfaces, APIs and common packages) and some common implementations (such as random load balancing algorithms). Function implementation layer: All users of the function implementation layer are equal, and all functions are implemented based on the extension mechanism. The internal version specific for Ant Financial just has some internal extension based on the open source version.","tags":null,"title":"SOFARPC architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/structure-intro/","wordcount":347},{"author":null,"categories":null,"content":" SOFARPC Log Format After SOFARPC (v5.4.0 and above) is integrated in SOFATracer, the link data is output in JSON format by default. Each field meaning is as follows:\nRPC client digest log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type (bolt, rest) Service interface information Method name Current thread name Calling type (sync, callback, oneway, future) Routing record (DIRECT, REGISTRY) Target IP Target appName Local machine IP Return code (00=success; 01=business exception; 02=RPC logic error; 03=timeout failure;04=routing failure) Request serialization time (in ms) Response deserialization time (in ms) Response size (in Byte) Request size (in Byte) Client connection duration (in ms) Total call duration (in ms) Local client port Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;samples\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC server digest log (rpc-server-digest.log) Log printing time TraceId SpanId Span type Service interface information Method name Source IP Source appName Protocol (bolt, rest) Current appName Current thread name Return code (00=success; 01=business exception; 02=RPC logic error) Server thread pool waiting time (in ms) Business processing duration (in ms) Response serialization time (in ms) Request deserialization time (in ms) Response size (in Byte) Request size (in Byte) Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-sofarpc/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ad45177e2719b9a22f4bfb07a0481905","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","summary":"SOFARPC Log Format After SOFARPC (v5.4.0 and above) is integrated in SOFATracer, the link data is output in JSON format by default. Each field meaning is as follows:\nRPC client digest log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type (bolt, rest) Service interface information Method name Current thread name Calling type (sync, callback, oneway, future) Routing record (DIRECT, REGISTRY) Target IP Target appName Local machine IP Return code (00=success; 01=business exception; 02=RPC logic error; 03=timeout failure;04=routing failure) Request serialization time (in ms) Response deserialization time (in ms) Response size (in Byte) Request size (in Byte) Client connection duration (in ms) Total call duration (in ms) Local client port Transparently transmitted baggage data (kv format) Example:","tags":null,"title":"SOFARPC log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","wordcount":259},{"author":null,"categories":null,"content":" 项目简介 SOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有的业务的相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括 bolt，RESTful，dubbo，H2C 协议进行通信。其中 bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\n基本原理 当一个 SOFARPC 的应用启动的时候，如果发现当前应用需要发布 RPC 服务的话，那么 SOFARPC 会将这些服务注册到服务注册中心上。如图中 Service 指向 Registry。 当引用这个服务的 SOFARPC 应用启动时，会从服务注册中心订阅到相应服务的元数据信息。服务注册中心收到订阅请求后，会将发布方的元数据列表实时推送给服务引用方。如图中 Registry 指向 Reference。 当服务引用方拿到地址以后，就可以从中选取地址发起调用了。如图中 Reference 指向 Service。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"62f0806ad40fcaaeab6a82470b14a2e2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/overview/","summary":"项目简介 SOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有的业务的相互","tags":null,"title":"SOFARPC 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/overview/","wordcount":402},{"author":null,"categories":null,"content":" 架构图 SOFARPC 从下到上分为两层：\n 核心层：包含了我们的 RPC 的核心组件（例如我们的各种接口、API、公共包）以及一些通用的实现（例如随机等负载均衡算法）。 功能实现层：所有的功能实现层的用户都是平等的，都是基于扩展机制实现的。 蚂蚁内部使用的版本也只是开源版本上增加一些内部扩展而已。\n当然你也可以增加自己三方扩展，参见：扩展机制\n模块划分 各个模块的实现类都只在自己模块中出现，一般不交叉依赖。需要交叉依赖的全部已经抽象到core或者common模块中。\n目前模块划分如下:\n主要模块及其依赖如下：\n 模块名 子模块名 中文名 说明 依赖 all 发布打包模块 需要打包的全部模块 bom 依赖管控模块 依赖版本管控 无 example 示例模块 all test 测试模块 包含集成测试 all core api API模块 各种基本流程接口、消息、上下文、扩展接口等 common core common 公共模块 utils、数据结构 exception core exception 异常模块 各种异常接口等 common bootstrap 启动实现模块 启动类，发布或者引用服务逻辑、以及registry的操作 core proxy 代理实现模块 接口实现代理生成 core client 客户端实现模块 发送请求、接收响应、连接维护、路由、负载均衡、同步异步等 core server 服务端实现模块 启动监听、接收请求，发送响应、业务线程分发等 core filter 拦截器实现模块 服务端和客户端的各种拦截器实现 core codec 编解码实现模块 例如压缩，序列化等 core protocol 协议实现模块 协议的包装处理、协商 core transport 网络传输实现模块 TCP连接的建立，数据分包粘包处理，请求响应对象分发等 core registry 注册中心实现模块 实现注册中心，例如zk等 core ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/structure-intro/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1902232a50d57df7ab5b2c7eea1f8caa","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/structure-intro/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/structure-intro/","summary":"架构图 SOFARPC 从下到上分为两层： 核心层：包含了我们的 RPC 的核心组件（例如我们的各种接口、API、公共包）以及一些通用的实现（例如随机等负载均衡算法）","tags":null,"title":"SOFARPC 工程架构介绍","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/structure-intro/","wordcount":598},{"author":null,"categories":null,"content":" 本文档将演示了如何应用 SOFARPC 进行服务的发布和引用。 本例将在本地模拟服务端启动监听一个端口并发布一个服务，客户端引用该服务进行直连调用。\n您可以直接在工程下找到本文档的示例代码。\n创建工程 需要安装 JDK 6 及以上 和 Maven 3 以上.\n我们新建一个 Maven 工程，并引入 SOFARPC 的依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;最新版本\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 注：最新版本可以从 https://github.com/sofastack/sofa-rpc/releases 里找到。\n编写服务端实现 第一步：创建接口\n/** * Quick Start demo interface */ public interface HelloService { String sayHello(String string); } 第二步：创建接口实现\n/** * Quick Start demo implement */ public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string) { System.out.println(\u0026amp;quot;Server receive: \u0026amp;quot; + string); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; ！\u0026amp;quot;; } } 第三步：编写服务端代码\n/** * Quick Start Server */ public class QuickStartServer { public static void main(String[] args) { ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // 设置一个协议，默认bolt .setPort(12200) // 设置一个端口，默认12200 .setDaemon(false); // 非守护线程 ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // 指定接口 .setRef(new HelloServiceImpl()) // 指定实现 .setServer(serverConfig); // 指定服务端 providerConfig.export(); // 发布服务 } } 编写客户端实现 第一步：拿到服务端接口\n一般服务端会通过jar的形式将接口类提供给客户端。而在本例中，由于服务端和客户端在一个工程所以跳过。\n第二步：编程客户端代码\n/** * Quick Start client */ public class QuickStartClient { public static void main(String[] args) { ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // 指定接口 .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // 指定协议 .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12200\u0026amp;quot;); // 指定直连地址 // 生成代理类 HelloService helloService = consumerConfig.refer(); while (true) { System.out.println(helloService.sayHello(\u0026amp;quot;world\u0026amp;quot;)); try { Thread.sleep(2000); } catch (Exception e) { } } } } 运行 分别启动服务端和客户端，观察运行效果。\n服务端将打印：\n Server receive: world\n 客户端将打印：\n hello world ！\n 更多 更多示例请参考：example\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-rpc/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"192d252b0b36266622284b68d10e9fe4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","summary":"本文档将演示了如何应用 SOFARPC 进行服务的发布和引用。 本例将在本地模拟服务端启动监听一个端口并发布一个服务，客户端引用该服务进行直连调用。 您可以直接","tags":null,"title":"SOFARPC 方式快速入门","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","wordcount":563},{"author":null,"categories":null,"content":" SOFATracer 集成在 SOFARPC(5.4.0及之后的版本) 后输出链路数据的格式，默认为 JSON 数据格式，具体的字段含义解释如下：\nRPC 客户端 摘要日志（ rpc-client-digest.log） 日志打印时间 TraceId SpanId Span 类型 当前 appName 协议类型(bolt,rest) 服务接口信息 方法名 当前线程名 调用类型(sync,callback,oneway,future) 路由记录(DIRECT,REGISTRY) 目标ip 目标 appName 本机ip 返回码(00=成功/01=业务异常/02=RPC逻辑错误/03=超时失败/04=路由失败) 请求序列化时间(单位ms) 响应反序列化时间(单位ms) 响应大小(单位Byte) 请求大小(单位Byte) 客户端连接耗时(单位ms) 调用总耗时(单位ms) 本地客户端端口 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;samples\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 服务端 摘要日志（ rpc-server-digest.log） 日志打印时间 TraceId SpanId Span 类型 服务接口信息 方法名 来源ip 来源 appName 协议(bolt,rest) 当前 appName 当前线程名 返回码(00=成功/01=业务异常/02=RPC逻辑错误) 服务端线程池等待时间(单位ms) 业务处理耗时(单位ms) 响应序列化时间(单位ms) 请求反序列化时间(单位ms) 响应大小(单位Byte) 请求大小(单位Byte) 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:00:53.312\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526806853032100185011\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SOFA-BOLT-BIZ-12200-5-T1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;server.pool.wait.time\u0026amp;quot;:\u0026amp;quot;3\u0026amp;quot;,\u0026amp;quot;biz.impl.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;resp.serialize.time\u0026amp;quot;:\u0026amp;quot;4\u0026amp;quot;,\u0026amp;quot;req.deserialize.time\u0026amp;quot;:\u0026amp;quot;38\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 客户端 统计日志（ rpc-client-stat.log） 日志打印时间 日志关键key 方法信息 客户端 appName 服务接口信息 调用次数 总耗时(单位ms) 调用结果(Y/N) 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-05-18 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-sofarpc/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ad45177e2719b9a22f4bfb07a0481905","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","summary":"SOFATracer 集成在 SOFARPC(5.4.0及之后的版本) 后输出链路数据的格式，默认为 JSON 数据格式，具体的字段含义解释如下： RPC 客户端 摘要日志（ rpc-c","tags":null,"title":"SOFARPC 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","wordcount":705},{"author":null,"categories":null,"content":"SOFARPC already supports using SOFARegistry as a service registry. Suppose you have deployed SOFARegistry Server locally according to SOFARegistry\u0026amp;rsquo;s Quick Start, and the service discovery port is set to 9603 by default.\nTo use SOFARegistry as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 The current version of SOFARegistry is supported:\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\nBecause of the time of SOFABoot, users need to specify the version of rpc starter.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFARPC integration verification SOFARegistry server version: 5.2.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-sofa/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"65085018ce2b2b2ef452993bb79a69de","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","summary":"SOFARPC already supports using SOFARegistry as a service registry. Suppose you have deployed SOFARegistry Server locally according to SOFARegistry\u0026rsquo;s Quick Start, and the service discovery port is set to 9603 by default.\nTo use SOFARegistry as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 The current version of SOFARegistry is supported:\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\nBecause of the time of SOFABoot, users need to specify the version of rpc starter.","tags":null,"title":"SOFARegistry","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","wordcount":90},{"author":null,"categories":null,"content":" Product introduction SOFARegistry is a production-level, low-latency, and highly available service registry powered by Ant Financial. SOFARegistry was developed on the basis ConfigServer of Taobao. After more than ten years of business development of Ant Financial, SOFARegistry has evolved into the fifth generation architecture. Currently, SOFARegistry not only provides full support to Ant Financial and its numerous partners, but also embraces the open source community. Built on an AP architecture, SOFARegistry support s message push in seconds. It also adopts a layered architecture to support infinite horizontal scaling.\nFeatures High scalability SOFARegistry adopts a layered architecture and partition-based data storage to break the single machine performance and capacity bottleneck, and to support the theoretical \u0026amp;ldquo;infinite horizontal scaling\u0026amp;rdquo;. It has been providing reliable services to the Ant Financial production environment which has a massive number of nodes and services.\nLow latency By virtue of the SOFABolt communication framework, SOFARegistry implements TCP long connection-based heartbeat detection among nodes, and the customized push mode to send service messages between upstream and downstream nodes in seconds.\nHighly available Unlike CP-architecture based registry products such as ZooKeeper, Consul, and Etcd, SOFARegistry adopts the AP architecture based on the service characteristics of service discovery, which significantly improves the availability of the registry in the case of failures caused by network partitioning. SOFARegistry takes many measures, such as multi-replica clusters, to prevent service unavailability arising from node failures.\nArchitecture SOFARegistry has four roles: Client, SessionServer, DataServer, and MetaServer, each with unique capabilities and responsibilities. They are combined to provide external services. The relationships and structures of them are explained as follows.\nClient A client provides basic APIs to allow applications to access SOFARegistry. The client provides JAR packages to application systems, so that they can call the service subscription and publishing features of SOFARegistry.\nSessionServer The SessionServer grants clients access to SessionServer, and accepts service publishing and subscription requests from clients. It also serves as an intermediate layer to forward the published data to DataServer for storage. The SessionServer can be infinitely scaled up to support connection with large amounts of clients.\nDataServer The DataServer is responsible for storing data published by clients. The data is stored by dataId through consistent hashing. DataServer supports multi-replica backup to ensure high availability of the data. The Data can also be infinitely scaled up to support large amounts of data.\nMetaServer The MetaServer is responsible for maintaining the consistency lists of the SessionServer and DataServer within the cluster, and immediately notify other nodes in the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d444761f1ad8b0c52e3505926176b13f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/overview/","summary":"Product introduction SOFARegistry is a production-level, low-latency, and highly available service registry powered by Ant Financial. SOFARegistry was developed on the basis ConfigServer of Taobao. After more than ten years of business development of Ant Financial, SOFARegistry has evolved into the fifth generation architecture. Currently, SOFARegistry not only provides full support to Ant Financial and its numerous partners, but also embraces the open source community. Built on an AP architecture, SOFARegistry support s message push in seconds.","tags":null,"title":"SOFARegistry overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/overview/","wordcount":429},{"author":null,"categories":null,"content":" 项目简介 SOFARegistry 是蚂蚁集团开源的一个生产级、高时效、高可用的服务注册中心。SOFARegistry 最早源自于淘宝的 ConfigServer，十年来，随着蚂蚁金服的业务发展，注册中心架构已经演进至第六代。目前 SOFARegistry 不仅全面服务于蚂蚁集团的自有业务，还随着蚂蚁金融科技服务众多合作伙伴，同时也兼容开源生态。SOFARegistry 采用 AP 架构，支持秒级时效性推送，同时采用分层架构支持无限水平扩展。\n产品特点 高可扩展性 采用分层架构、数据分片存储等方式，突破单机性能与容量瓶颈，接近理论上的“无限水平扩展”。经受过蚂蚁集团生产环境海量节点数与服务数的考验。\n高时效性 借助 SOFABolt 通信框架，实现基于 TCP 长连接的节点判活与推模式的变更推送，服务上下线通知时效性在秒级以内。\n高可用性 不同于 Zookeeper、Consul、Etcd 等 CP 架构注册中心产品，SOFARegistry 针对服务发现的业务特点，采用 AP 架构，最大限度地保证网络分区故障下注册中心的可用性。通过集群多副本等方式，应对自身节点故障。\n架构 服务注册中心分为四个角色，客户端（Client）、会话服务器（SessionServer）、数据服务器（DataServer）、元数据服务器（MetaServer），每个角色司职不同能力组合后共同提供对外服务能力，各部分关系和结构如下：\nClient 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\nSessionServer 会话服务器，提供客户端接入能力，接受客户端的服务发布及服务订阅请求，并作为一个中间层将发布数据转发 DataServer 存储。SessionServer 可无限扩展以支持海量客户端连接。\nDataServer 数据服务器，负责存储客户端发布数据，数据存储按照数据 ID 进行一致性 hash 分片存储，支持多副本备份，保证数据高可用。DataServer 可无限扩展以支持海量数据量。\nMetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，在节点变更时及时通知集群内其他节点。MetaServer 通过 SOFAJRaft 保证高可用和一致性。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/overview/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d444761f1ad8b0c52e3505926176b13f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/overview/","summary":"项目简介 SOFARegistry 是蚂蚁集团开源的一个生产级、高时效、高可用的服务注册中心。SOFARegistry 最早源自于淘宝的 ConfigServer，十年来","tags":null,"title":"SOFARegistry 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-registry/overview/","wordcount":838},{"author":null,"categories":null,"content":" SOFAStack-Demos 分布式链路组件 SOFATracer 埋点机制 Demo Demo 地址：https://github.com/glmapper/tracers-guides 相关文章：https://www.sofastack.tech/blog/sofa-channel-15-retrospect/ 云原生网络代理 MOSN 扩展机制：MOSN Stream Filter 操作 Demo Demo：https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions Demo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions 操作视频：https://www.bilibili.com/video/BV1SQ4y1K7iw 相关文章：https://www.sofastack.tech/blog/sofa-channel-14-retrospect/ 云原生网络代理 MOSN 多协议机制：接入 SOFABolt 操作 Demo Demo 地址：https://github.com/mosn/mosn/tree/master/examples/codes/sofarpc-with-xprotocol-sample 操作视频：https://www.bilibili.com/video/BV1UZ4y1x7Sj 相关文章：https://www.sofastack.tech/blog/sofa-channel-13-retrospect/ 轻量级类隔离容器 SOFAArk 动态模块操作 Demo Demo：https://github.com/caojie09/sofachannel-demo 操作视频：https://www.bilibili.com/video/BV1wQ4y1T7rt 相关文章：https://www.sofastack.tech/blog/sofa-channel-11-retrospect/ 分布式事务 Seata 长事务解决方案 Saga 模式可视化状态机 Seata Saga 可视化状态机设计器演示地址： http://seata.io/saga_designer/index.html Seata Saga 可视化状态机设计器代码以及运行指南： https://github.com/seata/seata/tree/develop/saga/seata-saga-statemachine-designer 相关文章：https://www.sofastack.tech/blog/sofa-channel-10-retrospect/ SOFAJRaft 的 Counter 例子 Demo Demo 地址：https://www.sofastack.tech/projects/sofa-jraft/counter-example/ 相关文章：https://www.sofastack.tech/blog/sofa-channel-8-retrospect/ 轻量级监控分析系统 SOFALookout 客户端的相关演示操作 Demo Demo 地址：https://github.com/sofastack/sofa-lookout/tree/master/samples/metrics/client 相关文章https://www.sofastack.tech/blog/sofa-channel-6-retrospect/ SOFARPC 内存优化操作 Demo Demo 地址：https://github.com/leizhiyuan/rpcchannel 相关文章：https://www.sofastack.tech/blog/sofa-channel-3-retrospect/ ","date":-62135596800,"description":"本指南为 SOFAStack 多个组件的 Demo 合集。","dir":"guides/sofastack-demos/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6a1fada81ea88116efa0e30539da60a1","permalink":"https://sofastack.github.io/sofastack.tech/guides/sofastack-demos/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/sofastack-demos/","summary":"SOFAStack-Demos 分布式链路组件 SOFATracer 埋点机制 Demo Demo 地址：https://github.com/glmapper/tracers-guides 相关文章：https","tags":null,"title":"SOFAStack Demos","type":"guides","url":"/sofastack.tech/guides/sofastack-demos/","wordcount":1353},{"author":null,"categories":null,"content":" Since SOFARPC 5.4.0, the SOFATracer function is integrated, which is enabled by default. It can output the data information in the link.\nBy default, the output data is in JSON format. The involved fields are as follows:\nRPC client digest Log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type Service interface information Method name Current thread name Calling type Routing record Target IP Local machine IP Return code Request serialization duration Response deserialization duration Response size (in Byte) Request size (in Byte) Client connection duration Total duration for call Local client port Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC server digest log (rpc-server-digest.log) Log printing time TraceId SpanId Span type Service interface information Method name Source IP Source appName Protocol Local appName Current thread name Return code Server thread pool waiting time Business processing duration Response serialization duration Request deserialization duration Response size (in Byte) Request size (in Byte) Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/sofatracer-usage/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"dde9dc7a759b7c0c272d67bac1b315d4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","summary":"Since SOFARPC 5.4.0, the SOFATracer function is integrated, which is enabled by default. It can output the data information in the link.\nBy default, the output data is in JSON format. The involved fields are as follows:\nRPC client digest Log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type Service interface information Method name Current thread name Calling type Routing record Target IP Local machine IP Return code Request serialization duration Response deserialization duration Response size (in Byte) Request size (in Byte) Client connection duration Total duration for call Local client port Transparently transmitted baggage data (kv format) Example:","tags":null,"title":"SOFATracer","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","wordcount":222},{"author":null,"categories":null,"content":" SOFATracer Tools Get Span through SOFATracer context In the process of a distributed link call, the component that integrates SOFATracer generates a Span and caches it in the SOFATracer context. And the context is cached in ThreadLocal. You can get the current SOFATracer context in the following way:\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); Through the SOFATracer context SofaTraceContext, you can add, delete, modify, check, and empty the cached Spans. As the developers responsible for integrating components, we will add, delete, modify and check the SOFATracer context to integrate distributed link tracking. However, as the application developer to directly use SOFATracer, you only need to get the corresponding Span. That is to say, you only need to use the following method after getting the context:\nSofaTracerSpan sofaTracerSpan = sofaTraceContext.getCurrentSpan(); Get information through Span When using the SOFATracer plugin component, such as Spring MVC, the component integrates the capabilities of SOFATracer. So it can get all the information in the Span after getting Span. The specific acquisition method example (it demands that Span is not empty, namely that the corresponding component has integrated SOFATracer) is as follow:\nGet TraceId and SpanId: SofaTracerSpanContext sofaTracerSpanContext = currentSpan.getSofaTracerSpanContext(); String traceId = sofaTracerSpanContext.getTraceId(); String spanId = sofaTracerSpanContext.getSpanId(); Get Tags and Logs in OpenTracing specification Get Tags:\nMap\u0026amp;lt;String, String\u0026amp;gt; tagsStr = sofaTracerSpan.getTagsWithStr(); Map\u0026amp;lt;String, Boolean\u0026amp;gt; tagsBool = sofaTracerSpan.getTagsWithBool(); Map\u0026amp;lt;String, Number\u0026amp;gt; tagsNumber = sofaTracerSpan.getTagsWithNumber(); Get Logs:\nList \u0026amp;lt;LogData\u0026amp;gt; logDataList = sofaTracerSpan.getLogs (); Process transparently transmitted data Baggage element is a collection of key-value pairs that carries data to be transparently transmitted. In SOFATracer, Baggage data is divided into sysBaggage and bizBaggage; sysBaggage mainly refers to transparently transmitted system data, and bizBaggage mainly refers to transparently transmitted business data.\nConfigure and get BaggageItem BaggageItem is a data element in the Baggage collection.\n Configure the corresponding BaggageItem data through the standard interface: String baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageVal = \u0026amp;quot;val\u0026amp;quot;; sofaTracerSpan.setBaggageItem(baggageKey,baggageVal); Get the corresponding BaggageItem data through the standard interface: String baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageValue = sofaTracerSpan.getBaggageItem(baggageKey); Note: Configuring and getting Baggage data through the standard interface is actually operated on bizBaggage.\nConfigure and get \u0026amp;lsquo;Baggage\u0026amp;rsquo; data 1, Configure \u0026amp;lsquo;Baggage\u0026amp;rsquo; data\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggage …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/utils/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"d40318a5bd3ee5e1573f8770ea649dba","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/utils/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/utils/","summary":"SOFATracer Tools Get Span through SOFATracer context In the process of a distributed link call, the component that integrates SOFATracer generates a Span and caches it in the SOFATracer context. And the context is cached in ThreadLocal. You can get the current SOFATracer context in the following way:\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); Through the SOFATracer context SofaTraceContext, you can add, delete, modify, check, and empty the cached Spans. As the developers responsible for integrating components, we will add, delete, modify and check the SOFATracer context to integrate distributed link tracking.","tags":null,"title":"SOFATracer Tools","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/utils/","wordcount":443},{"author":null,"categories":null,"content":" SOFATracer configuration item After introducing SOFATracer, you can add related configuration items in Spring Boot configuration file application.properties to customize the behaviors of SOFATracer.\nFor SOFATracer log output directory, you can configure logging.path in application.properties, then the log output path is ${logging.path}/tracelog; if logging.path is not configured, the default output path is ${user.home}/logs/tracelog.\n Configuration item Description Default value logging.path log output directory SOFATracer output logs to logging.path directory in priority; If the directory is not configured, log will be output to ${user.home} by default. com.alipay.sofa.tracer.disableDigestLog Disable all integrated SOFATracer summary log printing false com.alipay.sofa.tracer.disableConfiguration[${logType}] Disable specific SOFATracer summary log printing of ${logType}. ${logType} indicates the log type, such as spring-mvc-digest.log false com.alipay.sofa.tracer.tracerGlobalRollingPolicy SOFATracer log rolling policy yyyy-MM-dd：roll by day；yyyy-MM-dd_HH：roll by hour;Logs are not rolled by day by default. com.alipay.sofa.tracer.tracerGlobalLogReserveDay Retention days of SOFATracer logs Retained for 7 days by default. com.alipay.sofa.tracer.statLogInterval Time interval of statistical logs, unit: second Output statistical logs once every 60 seconds by default com.alipay.sofa.tracer.baggageMaxLength Maximum length for retaining penetration data Default: 1024 com.alipay.sofa.tracer.zipkin.enabled Whether to enable SOFATracer remote data reporting to Zipkin true: enable; false: disable. Disabled by default. com.alipay.sofa.tracer.zipkin.baseUrl The address Zipkin address to which SOFATracer remotely reports data, which works only in the case of com.alipay.sofa.tracer.zipkin.enabled=true Format: http: //${host}:${port} com.alipay.sofa.tracer.springmvc.filterOrder Order validated by SOFATrace Filter intergrated in SpringMVC -2147483647(org.springframework.core.Ordered#HIGHEST_PRECEDENCE + 1) com.alipay.sofa.tracer.springmvc.urlPatterns URL Pattern paths validated by SOFATrace Filter intergrated in SpringMVC /*: All validated ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/configuration/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1a6bf2b7aa168440544f8d0d69358869","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/configuration/","summary":"SOFATracer configuration item After introducing SOFATracer, you can add related configuration items in Spring Boot configuration file application.properties to customize the behaviors of SOFATracer.\nFor SOFATracer log output directory, you can configure logging.path in application.properties, then the log output path is ${logging.path}/tracelog; if logging.path is not configured, the default output path is ${user.home}/logs/tracelog.\n Configuration item Description Default value logging.path log output directory SOFATracer output logs to logging.","tags":null,"title":"SOFATracer configuration items","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/configuration/","wordcount":231},{"author":null,"categories":null,"content":" SOFATracer is a distributed link tracing system based on OpenTracing specification developed by Ant Financial. Its core concept is to concatenate the same request distributed on each service node with a global TraceId. By the unified TraceId, it can record the various network call information in the call link in logs, and can remotely report the call records to Zipkin for presentation, thus implementing perspective network call.\nFeatures Distributed link tracing solution based on OpenTracing specification SOFATracer is a solution that provides link tracing based on and improved from the OpenTracing specification. Based on this implementation, each framework or component can provide the ability to link tracking by burying points.\nProvide asynchronous log printing to disks Based on high-performance lock-free loop queue of Disruptor, SOFATracer provides the ability to print logs asynchronously to local disk. The introduced framework or component can customize the output format of the log file under the premise of asynchronous log printing. SOFATracer provides two types of logs, digest log and statistical log. Digest log: logs that are printed to disk upon each call. Statistical log: logs that are printed at regular intervals.\nSupport automatic log cleanup and scrolling Asynchronous SOFATracer log supports automatic cleanup and scrolling, and supports cleaning by day and scrolling by hour or day.\nExtended based on SLF4J MDC SLF4J provides MDC (Mapped Diagnostic Contexts), which supports user to define and modify the output log format and content. SOFATracer integrates the SLF4J MDC function, which allows user to output the TraceId and SpanId of the current Tracer context by simply modifying the log configuration file.\nInterface presentation SOFATracer can remotely report link tracing data to the open-source product Zipkin for distributed link tracing presentation.\nUnified configuration The profile file provides various configuration options for you to customize the individual requirements of the application.\nScenario SOFATracer solves the problem of link tracing when implementing large-scale microservice architecture, achieves perspective network call, and can be used to rapidly Failures Discovery, Service Governance, and so on.\nComponent event tracking At present, SOFATracer supports Spring MVC, database connection pool (DBCP, Druid, c3p0, tomcat, HikariCP, BoneCP) acheived by standard JDBC interface, HttpClient and other open-source components. Event tracking for other open-source components (such as MQ, Redis) is still in development.\n Component Document Version Spring MVC doc link 2.1.0 DBCP doc link 2.2.0 Druid doc link 2.2.0 C3p0 doc link 2.2.0 HikariCP doc link 2.2.0 HttpClient doc link 2.2.0 RestTemplate doc link 2.3.0 OkHttp doc link 2.3.2 Dubbo doc link 2.4.0 OpenFeign doc link 3.0.4 Redis TODO MQ TODO ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e8d6bf5eec6c5ce1e41d461743f2c4f1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/overview/","summary":"SOFATracer is a distributed link tracing system based on OpenTracing specification developed by Ant Financial. Its core concept is to concatenate the same request distributed on each service node with a global TraceId. By the unified TraceId, it can record the various network call information in the call link in logs, and can remotely report the call records to Zipkin for presentation, thus implementing perspective network call.\nFeatures Distributed link tracing solution based on OpenTracing specification SOFATracer is a solution that provides link tracing based on and improved from the OpenTracing specification.","tags":null,"title":"SOFATracer overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/overview/","wordcount":421},{"author":null,"categories":null,"content":" SOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n功能描述 基于 OpenTracing 规范提供分布式链路跟踪解决方案 基于 OpenTracing 规范 并扩展其能力提供链路跟踪的解决方案。各个框架或者组件可以基于此实现，通过在各个组件中埋点的方式来提供链路跟踪的能力。\n提供异步落地磁盘的日志打印能力 基于 Disruptor 高性能无锁循环队列，提供异步打印日志到本地磁盘的能力。框架或者组件能够在接入时，在异步日志打印的前提下可以自定义日志文件的输出格式。SOFATracer 提供两种类似的日志打印类型即摘要日志和统计日志，摘要日志：每一次调用均会落地磁盘的日志；统计日志：每隔一定时间间隔进行统计输出的日志。\n支持日志自清除和滚动能力 异步落地磁盘的 SOFATracer 日志支持自清除和滚动能力，支持按照按照天清除和按照小时或者天滚动的能力\n基于 SLF4J MDC 的扩展能力 SLF4J 提供了 MDC（Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。SOFATracer 集成了 SLF4J MDC 功能，方便用户在只简单修改日志配置文件即可输出当前 Tracer 上下文的 TraceId 和 SpanId。\n界面展示能力 SOFATracer 可以将链路跟踪数据远程上报到开源产品 Zipkin 做分布式链路跟踪的展示。\n统一配置能力 配置文件中提供丰富的配置能力以定制化应用的个性需求。\n应用场景 解决在实施大规模微服务架构时的链路跟踪问题，达到透视化网络调用的目的，并可用于故障的快速发现，服务治理等。\n组件埋点 目前 SOFATracer 支持 Spring MVC、标准 JDBC 接口实现的数据库连接池(DBCP、Druid、c3p0、tomcat、HikariCP、BoneCP)、HttpClient、Dubbo、Spring Cloud OpenFeign 等开源组件，其他开源组件（如 MQ、Redis）埋点支持在开发中。\n 支持组件 接入文档 支持版本 Spring MVC doc link 2.1.0 DBCP doc link 2.2.0 Druid doc link 2.2.0 c3p0 doc link 2.2.0 HikariCP doc link 2.2.0 HttpClient doc link 2.2.0 OkHttp doc link 2.3.2 Dubbo doc link 2.4.0 Redis TODO MQ TODO ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/overview/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e8d6bf5eec6c5ce1e41d461743f2c4f1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/overview/","summary":"SOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调","tags":null,"title":"SOFATracer 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/overview/","wordcount":843},{"author":null,"categories":null,"content":" 通过 SOFATracer 上下文获取 Span 在一次分布式链路调用过程中，在集成了 SOFATracer 的组件会产生一个 Span 并会缓存到 SOFATracer 的上下文中，这个上下文是缓存在 ThreadLocal 中的，作为使用者可以通过如下的方式随时获取到当前 SOFATracer 的上下文：\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); SOFATracer 上下文 SofaTraceContext 通过这个实例，可以对其缓存的 Span 执行增、删、改、查和清空操作。作为组件集成的同学在集成过程中我们会对 SOFATracer 上下文做增、删、改和查等操作来集成分布式链路跟踪的能力；但是作为直接使用 SOFATracer 的应用开发者，我们只需要能够获取相应的 Span 即可，即只需要在获取上下文后使用如下的方法：\nSofaTracerSpan sofaTracerSpan = sofaTraceContext.getCurrentSpan(); 通过 Span 获取信息 在使用相应的组件如 Spring MVC 时，该组件集成了 SOFATracer 的能力后可以在获取到 Span 后获取到 Span 中的所有信息，具体获取方式示例（前提 Span 不为空即相应组件已经集成 SOFATracer）：\n获取 TraceId 和 SpanId ： SofaTracerSpanContext sofaTracerSpanContext = currentSpan.getSofaTracerSpanContext(); String traceId = sofaTracerSpanContext.getTraceId(); String spanId = sofaTracerSpanContext.getSpanId(); 获取 OpenTracing 规范中的 Tags 和 Logs 获取 Tags:\nMap\u0026amp;lt;String, String\u0026amp;gt; tagsStr = sofaTracerSpan.getTagsWithStr(); Map\u0026amp;lt;String, Boolean\u0026amp;gt; tagsBool = sofaTracerSpan.getTagsWithBool(); Map\u0026amp;lt;String, Number\u0026amp;gt; tagsNumber = sofaTracerSpan.getTagsWithNumber(); 获取 Logs:\nList\u0026amp;lt;LogData\u0026amp;gt; logDataList = sofaTracerSpan.getLogs(); 透传数据处理 Baggage 元素是一个键值对集合，其携带的是需要透传的数据。SOFATracer 中将 Baggage 数据分为 sysBaggage 和 bizBaggage；sysBaggage 主要是指系统维度的透传数据，bizBaggage 主要是指业务的透传数据。\n设置和获取 BaggageItem BaggageItem 是 Baggage集合中的数据元素。\n1、通过标准接口设置相应的 BaggageItem 数据：\nString baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageVal = \u0026amp;quot;val\u0026amp;quot;; sofaTracerSpan.setBaggageItem(baggageKey,baggageVal); 2、通过标准接口获取相应的 BaggageItem 数据：\nString baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageValue = sofaTracerSpan.getBaggageItem(baggageKey); 注：当通过标准接口进行设置和获取 Baggage 数据时，实际上操作的对象均为 bizBaggage\n设置和获取 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据 1、设置 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggage = new HashMap\u0026amp;lt;String, String\u0026amp;gt;(); bizBaggage.put(\u0026amp;quot;bizKey\u0026amp;quot;,\u0026amp;quot;bizVal\u0026amp;quot;); sofaTracerSpanContext.addBizBaggage(bizBaggage); Map\u0026amp;lt;String, String\u0026amp;gt; sysBaggage = new HashMap\u0026amp;lt;String, String\u0026amp;gt;(); sysBaggage.put(\u0026amp;quot;sysKey\u0026amp;quot;,\u0026amp;quot;sysVal\u0026amp;quot;); sofaTracerSpanContext.addSysBaggage(sysBaggage); 2、获取 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); //获取 bizBaggage Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggages = sofaTracerSpanContext.getBizBaggage(); //获取 sysBaggage Map\u0026amp;lt;String, String\u0026amp;gt; sysBaggages = sofaTracerSpanContext.getSysBaggage(); 遍历 Baggage 数据 OpenTracing 规范中 SpanContext 接口提供了 baggageItems() 方法，可以通过这个方法来遍历所有的 baggage 元素。SOFATracer 在 SofaTracerSpanContext 类中对 baggageItems() 方法进行了具体实现。\nIterable\u0026amp;lt;Map.Entry\u0026amp;lt;String, String\u0026amp;gt;\u0026amp;gt; entrySet = sofaTracerSpanContext.baggageItems(); 注：遍历 Baggage 数据返回的是 sysBaggage 和 bizBaggage 的合集。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/utils/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d40318a5bd3ee5e1573f8770ea649dba","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/utils/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/utils/","summary":"通过 SOFATracer 上下文获取 Span 在一次分布式链路调用过程中，在集成了 SOFATracer 的组件会产生一个 Span 并会缓存到 SOFATracer 的上下文中，这个上下文是缓存在 ThreadLocal 中的，作为使用者可以通","tags":null,"title":"SOFATracer 工具类","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/utils/","wordcount":738},{"author":null,"categories":null,"content":" 应用在引入 SOFATracer 后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 SOFATracer 的相关行为。\nSOFATracer 的日志输出目录，可以在 application.properties 中配置 logging.path 的路径，那么其日志输出路径为 ${logging.path}/tracelog；如果没有配置 logging.path，那么 SOFATracer 的默认输出路径为 ${user.home}/logs/tracelog。\nSpringBoot 工程配置 SOFATracer 配置项 说明 默认值 logging.path 日志输出目录 SOFATracer 会优先输出到 logging.path 目录下；如果没有配置日志输出目录，那默认输出到 ${user.home} com.alipay.sofa.tracer.disableDigestLog 是否关闭所有集成 SOFATracer 组件摘要日志打印 false com.alipay.sofa.tracer.disableConfiguration[${logType}] 关闭指定 ${logType} 的 SOFATracer 组件摘要日志打印。${logType}是指具体的日志类型，如：spring-mvc-digest.log false com.alipay.sofa.tracer.tracerGlobalRollingPolicy SOFATracer 日志的滚动策略 .yyyy-MM-dd：按照天滚动；.yyyy-MM-dd_HH：按照小时滚动。默认不配置按照天滚动 com.alipay.sofa.tracer.tracerGlobalLogReserveDay SOFATracer 日志的保留天数 默认保留 7 天 com.alipay.sofa.tracer.statLogInterval 统计日志的时间间隔，单位：秒 默认 60 秒统计日志输出一次 com.alipay.sofa.tracer.baggageMaxLength 透传数据能够允许存放的最大长度 默认值 1024 com.alipay.sofa.tracer.zipkin.enabled 是否开启 SOFATracer 远程上报数据到 Zipkin true：开启上报；false：关闭上报。默认不上报 com.alipay.sofa.tracer.zipkin.baseUrl SOFATracer 远程上报数据到 Zipkin 的地址，com.alipay.sofa.tracer.zipkin.enabled=true时配置此地址才有意义 格式：http://${host}:${port} com.alipay.sofa.tracer.springmvc.filterOrder SOFATracer 集成在 SpringMVC 的 Filter 生效的 Order -2147483647（org.springframework.core.Ordered#HIGHEST_PRECEDENCE + 1） com.alipay.sofa.tracer.springmvc.urlPatterns SOFATracer 集成在 SpringMVC 的 Filter 生效的 URL Pattern 路径 /* 全部生效 com.alipay.sofa.tracer.jsonOutput 是否以json格式输出日志 true，如果期望较少日志空间占用，可以使用非 json 格式输出（日志顺序与JSON 格式顺序一致） 非SpringBoot 工程配置 在非 SpringBoot 工程中，可以通过在 classpath 下新建一个 sofa.tracer.properties 配置文件，配置项如下：\n SOFATracer 配置项 说明 默认值 disable_middleware_digest_log 是否关闭中间件组件摘要日志打印 false disable_digest_log 关闭摘要日志打印。 false tracer_global_rolling_policy SOFATracer 日志的滚动策略 .yyyy-MM-dd：按照天滚动；.yyyy-MM-dd_HH：按照小时滚动。默认不配置按照天滚动 tracer_global_log_reserve_day SOFATracer 日志的保留天数 默认保留 7 天 stat_log_interval 统计日志的时间间隔，单位：秒 默认 60 秒统计日志输出一次 tracer_penetrate_attribute_max_length 透传数据能够允许存放的最大长度 默认值 1024 tracer_async_appender_allow_discard 是否允许丢失日志 false tracer_async_appender_is_out_discard_number 丢失日志数 0 spring.application.name 应用名 `` tracer_sampler_strategy_name_key 采样策略名 `` tracer_sampler_strategy_custom_rule_class_name 采样规则 spi 实现的类的全限定名 `` tracer_sampler_strategy_percentage_key 采样比率 com.alipay.sofa.tracer.jsonOutput 是否以json格式输出日志 true，如果期望较少日志空间占用，可以使用非 json 格式输出（日志顺序与JSON 格式顺序一致） ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/configuration/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1a6bf2b7aa168440544f8d0d69358869","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-tracer/configuration/","summary":"应用在引入 SOFATracer 后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 SOFATracer 的相关行为。 SOFATracer 的日志输出目录，可以在 application.properties 中配置 logging.path 的路径，那么其日志输出路径为 ${","tags":null,"title":"SOFATracer 配置项","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/configuration/","wordcount":1004},{"author":null,"categories":null,"content":" 在SOFARPC(5.4.0及之后的版本) 后的版本中，我们集成了SOFATracer的功能，默认开启，可以输出链路中的数据信息。\n默认为 JSON 数据格式，具体的字段含义解释如下：\nRPC 客户端 摘要日志（ rpc-client-digest.log） 日志打印时间 TraceId SpanId Span 类型 当前 appName 协议类型 服务接口信息 方法名 当前线程名 调用类型 路由记录 目标ip 本机ip 返回码 请求序列化时间 响应反序列化时间 响应大小(单位Byte) 请求大小(单位Byte) 客户端连接耗时 调用总耗时 本地客户端端口 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 服务端 摘要日志（ rpc-server-digest.log） 日志打印时间 TraceId SpanId Span 类型 服务接口信息 方法名 来源ip 来源 appName 协议 本应用 appName 当前线程名 返回码 服务端线程池等待时间 业务处理耗时 响应序列化时间 请求反序列化时间 响应大小(单位Byte) 请求大小(单位Byte) 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:00:53.312\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526806853032100185011\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SOFA-BOLT-BIZ-12200-5-T1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;server.pool.wait.time\u0026amp;quot;:\u0026amp;quot;3\u0026amp;quot;,\u0026amp;quot;biz.impl.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;resp.serialize.time\u0026amp;quot;:\u0026amp;quot;4\u0026amp;quot;,\u0026amp;quot;req.deserialize.time\u0026amp;quot;:\u0026amp;quot;38\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/sofatracer-usage/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dde9dc7a759b7c0c272d67bac1b315d4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","summary":"在SOFARPC(5.4.0及之后的版本) 后的版本中，我们集成了SOFATracer的功能，默认开启，可以输出链路中的数据信息。 默认为 JSON 数据","tags":null,"title":"SOFATracer 链路追踪","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","wordcount":529},{"author":null,"categories":null,"content":" Sampling Currently,SOFATracer provides two sampling modes. One is the fixed sampling rate based on BitSet. The other is the sampling provided to the user to customize the implementation sampling.The following example shows how to use it.\nThis example is based on the tracer-sampled-with-springmvc project,Except for application.properties, everything else is the same.\nSampling mode based on fixed sampling rate Add sampling related configuration items in application.properties #Sampling rate 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #Sampling type name com.alipay.sofa.tracer.samplerName=PercentageBasedSampler Verification When the sample rate is set to 100, the digest log is printed each time. When the sample rate is set to 0, the digest log is not printed. Print by probability when the sampling rate is set between 0 and 100. The result is verified by requesting 10 times.\n1、When the sample rate is set to 100, the digest log is printed each time.\nStart the project and enter in the browser:http://localhost:8080/springmvc ,And refresh the address 10 times, check the log as follows:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:47.643\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173568757510019269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:68,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:50.980\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569097710029269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:51.542\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569153910049269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-4\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/sampler/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"48856a040da01abc84213934c1c5fce4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/sampler/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/sampler/","summary":"Sampling Currently,SOFATracer provides two sampling modes. One is the fixed sampling rate based on BitSet. The other is the sampling provided to the user to customize the implementation sampling.The following example shows how to use it.\nThis example is based on the tracer-sampled-with-springmvc project,Except for application.properties, everything else is the same.\nSampling mode based on fixed sampling rate Add sampling related configuration items in application.properties #Sampling rate 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #Sampling type name com.","tags":null,"title":"Sampling modes","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/sampler/","wordcount":426},{"author":null,"categories":null,"content":" 1. Integrated deployment 1.1 Scale up registry-integration Assume that three registry-integration servers have been deployed currently, which are namely node1, node2, and node 3. The new node to be added to the cluster is node 4.\nOperation steps:\nStep 1. Deploy the new registry-integration node\nFirst, deploy registry-integration.tgz on node4 by referencing the Deployment topic. Note that you need to set the nodes.metaNode configuration item on node4 to a 4-server endpoint list:\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt; In this step, after node4 is started, visit curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check. The status will be unhealthy, because node4 has not been added to the cluster yet. To add it to the cluster, perform the next step.\nStep 2. Call the changePeer operation to add a new node to a cluster\nRun the changePeer command on one of the existing servers (node1, node2, and node3), to modify the current cluster from a three-node cluster (node1, node2, and node3) to a four-node cluster (node1, node2, node3, and node4):\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt;\u0026amp;quot; After completing this step, visit curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check. The status will be healthy.\n1.2 Scale down registry-integration Assume that you have three servers in one cluster, which are respectively node1, node2, and node3, and you want to scale down node3.\n1.2.1 Smooth scale-down Operation steps:\nStep 1. Call the changePeer operation to remove a node\nRun the changePeer command on either node1 or node2 to change the cluster list from \u0026amp;ldquo;node1, node2, node3\u0026amp;rdquo; to \u0026amp;ldquo;node1,node2\u0026amp;rdquo;. This removes node3 from the endpoint list of the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; After completing this step, visit curl http://\u0026amp;lt;node3\u0026amp;gt;:9615/health/check. The status will be unhealthy, because node3 has already been removed from the cluster.\nStep 2. Close node3\nThis step is optional, because node3 has already been removed from the cluster, and it does not affect the cluster even if it is still running.\n1.2.2 Handling of node failure If node3 is no longer functional, you need to remove it from the cluster.\nOperation steps:\nStep 1. Call the changePeer operation to remove a node\nRun the changePeer command on either node1 or node2 to change the cluster list from \u0026amp;ldquo;node1, node2, node3\u0026amp;rdquo; to \u0026amp;ldquo;node1,node2\u0026amp;rdquo;. This removes node3 from the endpoint list of the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 2. Independent deployment 2.1 Scale up registry-meta Assume that you have already deployed three registry-meta servers, which are respectively metaNode1, metaNode2, and metaNode3. The new node to be added to the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/scale/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"57de6dc4da1292063ff25ecea9ffbd08","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/scale/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/scale/","summary":"1. Integrated deployment 1.1 Scale up registry-integration Assume that three registry-integration servers have been deployed currently, which are namely node1, node2, and node 3. The new node to be added to the cluster is node 4.\nOperation steps:\nStep 1. Deploy the new registry-integration node\nFirst, deploy registry-integration.tgz on node4 by referencing the Deployment topic. Note that you need to set the nodes.metaNode configuration item on node4 to a 4-server endpoint list:","tags":null,"title":"Scaling","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/scale/","wordcount":954},{"author":null,"categories":null,"content":" Quickly understand ACTS scripts Do you have to frequently compile test cases? Are you frustrated by the following problems?\n You have to repeat assertEquals, which is definitely not creative. Missing an assert may lead to false success, while mistaking one may ruin your mood. If the scenario is complex, the test code may be longer than the service code, which is painful. You have to migrate utility classes every time you start writing test cases for a new application. A TestNG test case is shown on the left side, and an ACTS test case on the right. Repeated coding is gone, and the code size is significantly reduced. Unlike ordinary test scripts, ACTS scripts inherit from the ActsTestBase class, which is encapsulated with data loading methods, driving methods, execution engines, and validation rules. Users do not have to clean or prepare data, run test cases, or validate results. ACTS implements zero coding for simple services, which greatly reduces the coding and maintenance costs.\nGenerate test scripts Prerequisites: Be sure to use Maven to compile your project and generate the object model. Otherwise, ACTS IDE may encounter unexpected errors, such as edit failures and incorrect data.\nRight click a the method defined in the interface and select ACTS Function \u0026amp;gt; Generate Test Case.\nRun test script Method: Right click the tested method in ACTS script, and select TestNG to run the test script as shown in the following figure.\nSpecify a test script to run Set test_only＝^T in src/test/resource/config/acts-config.properties to run only the test case whose name starts with T. You can also replace ^T with other regular expressions.\n In this case, you can modify the name of the test case that you want to run by adding T in front of its name. ACTS only runs a test case whose name starts with T.\n Split test cases of the test script ACTS stores all test case data of a test script in the same YAML file by default. You can determine whether to store test case data by test script or by test case by configuring the option spilt_yaml_by_case. It is set to false by default, which means all test case data of the same test script is stored in one YAML file.\nYou can set spilt_yaml_by_case=true in acts-config.properties to store each test case of a new test script in a separate YAML file that is named after the case ID. This reduces the chances of file conflicts in the case where multiple developers work on the same interface.\nIn addition, ACTS provides a utility class that allows you split a legacy YAML file of a specified test script under a specified path by test case. See the following.\nBaseDataUtil.saveYamlDataToCaseByCase\n Note: Before the split, we recommend that you rename the original YAML file for backup, and then use the test case editor to check whether the content of the split files is correct. The original YAML file must be deleted if the split files are correct, because they cannot coexist. Coding for data preparation ACTS provides context APIs …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-script/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"0d20739dedad1f11277bd02ed65329c3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-script/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-script/","summary":"Quickly understand ACTS scripts Do you have to frequently compile test cases? Are you frustrated by the following problems?\n You have to repeat assertEquals, which is definitely not creative. Missing an assert may lead to false success, while mistaking one may ruin your mood. If the scenario is complex, the test code may be longer than the service code, which is painful. You have to migrate utility classes every time you start writing test cases for a new application.","tags":null,"title":"Scripts","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-script/","wordcount":825},{"author":null,"categories":null,"content":" SEATA Demo for SOFAStack Cloud Native Workshop on KubeCon China 2019\nAT mode 1.Introduce maven dependencies Introduce the following dependencies into the POM file of the parent project (seata-demo-at/pom.xml):\n... \u0026amp;lt;properties\u0026amp;gt; ... \u0026amp;lt;seata.version\u0026amp;gt;0.6.1\u0026amp;lt;/seata.version\u0026amp;gt; \u0026amp;lt;netty4.version\u0026amp;gt;4.1.24.Final\u0026amp;lt;/netty4.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; ... \u0026amp;lt;dependencyManagement\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; ... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;javax.servlet\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;servlet-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${netty4.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; \u0026amp;lt;/dependencyManagement\u0026amp;gt; Introduce the following dependencies into the POM file of the stock-mng project (seata-demo-at/stock-mng/pom.xml):\n\u0026amp;lt;dependencies\u0026amp;gt; .... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; Introduce the following dependencies into the POM file of the balance-mng-impl project (seata-demo-at/balance-mng/balance-mng-impl/pom.xml):\n\u0026amp;lt;dependencies\u0026amp;gt; .... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 2. Use Seata\u0026amp;rsquo;s DataSourceProxy to proxy actual data source and configure GlobalTransactionScanner to scan @GlobalTransaction annotation Add the following java snippet to the main methods in BalanceMngApplication and StockMngApplication classes:\n... import io.seata.rm.datasource.DataSourceProxy; import io.seata.spring.annotation.GlobalTransactionScanner; ... @Configuration public static class DataSourceConfig { @Bean @Primary @ConfigurationProperties(prefix = \u0026amp;quot;spring.datasource.hikari\u0026amp;quot;) public DataSource dataSource(DataSourceProperties properties) { HikariDataSource dataSource = createDataSource(properties, HikariDataSource.class); if (StringUtils.hasText(properties.getName())) { dataSource.setPoolName(properties.getName()); } return new DataSourceProxy(dataSource); } @SuppressWarnings(\u0026amp;quot;unchecked\u0026amp;quot;) …","date":-62135596800,"description":"This guide introduces how to use the AT mode and TCC mode of the open-source distributed transaction framework Seata to solve the final consistency of service data.","dir":"guides/kc-seata-demo/","fuzzywordcount":1500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"60071a0eb44bf0901fb187eefd63ccdb","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-seata-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/guides/kc-seata-demo/","summary":"SEATA Demo for SOFAStack Cloud Native Workshop on KubeCon China 2019\nAT mode 1.Introduce maven dependencies Introduce the following dependencies into the POM file of the parent project (seata-demo-at/pom.xml):\n... \u0026lt;properties\u0026gt; ... \u0026lt;seata.version\u0026gt;0.6.1\u0026lt;/seata.version\u0026gt; \u0026lt;netty4.version\u0026gt;4.1.24.Final\u0026lt;/netty4.version\u0026gt; \u0026lt;/properties\u0026gt; ... \u0026lt;dependencyManagement\u0026gt; \u0026lt;dependencies\u0026gt; ... \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.seata\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;seata-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${seata.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.seata\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;seata-server\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${seata.version}\u0026lt;/version\u0026gt; \u0026lt;exclusions\u0026gt; \u0026lt;exclusion\u0026gt; \u0026lt;groupId\u0026gt;javax.servlet\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;servlet-api\u0026lt;/artifactId\u0026gt; \u0026lt;/exclusion\u0026gt; \u0026lt;/exclusions\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.netty\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;netty-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${netty4.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;/dependencies\u0026gt; \u0026lt;/dependencyManagement\u0026gt; Introduce the following dependencies into the POM file of the stock-mng project (seata-demo-at/stock-mng/pom.","tags":null,"title":"Seata distributed transaction practice","type":"guides","url":"/sofastack.tech/en/guides/kc-seata-demo/","wordcount":1464},{"author":null,"categories":null,"content":"SOFABoot RPC Starter provides a variety of registry center options as well as convenient configurations.\nCurrently, bolt, rest, and dubbo all support Zookeeper as registry center. In addition, bolt and rest support the local file system as registry center, which is generally used for testing.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-usage/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5a1a4619c8ac4a9fc27b8576472aed9f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-usage/","summary":"SOFABoot RPC Starter provides a variety of registry center options as well as convenient configurations.\nCurrently, bolt, rest, and dubbo all support Zookeeper as registry center. In addition, bolt and rest support the local file system as registry center, which is generally used for testing.","tags":null,"title":"Select Service Registry","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-usage/","wordcount":45},{"author":null,"categories":null,"content":"When using the Bolt communication protocol, SOFARPC can choose different serialization protocols, which can be hessian2 or protobuf currently.\nBy default, SOFARPC uses hessian2 as the serialization protocol. If you need to set the serialization protocol to protobuf, you need to configure the following settings when publishing the service:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; That is to add the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag to the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag and set the serialize-type attribute to protobuf.\nCorrespondingly, when referencing the service, you also need to change the serialization protocol to protobuf. The setting method is similar to publishing the service:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot; jvm-first=\u0026amp;quot;false\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Currently, when you use Annotation for service reference, it is not yet supported to set serialization protocol. But this will be supported in future versions. For details, see ISSUE: https://github.com/sofastack/sofa-boot/issues/278\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/serialization/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"87e2faa84c2c7a7605243dc096bc4e17","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/serialization/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/serialization/","summary":"When using the Bolt communication protocol, SOFARPC can choose different serialization protocols, which can be hessian2 or protobuf currently.\nBy default, SOFARPC uses hessian2 as the serialization protocol. If you need to set the serialization protocol to protobuf, you need to configure the following settings when publishing the service:\n\u0026lt;sofa:service ref=\u0026quot;sampleService\u0026quot; interface=\u0026quot;com.alipay.sofarpc.demo.SampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs serialize-type=\u0026quot;protobuf\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:service\u0026gt; That is to add the \u0026lt;sofa:global-attrs\u0026gt; tag to the \u0026lt;sofa:binding.bolt\u0026gt; tag and set the serialize-type attribute to protobuf.","tags":null,"title":"Serialization protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/serialization/","wordcount":138},{"author":null,"categories":null,"content":" Local development Starting SOFARegistry locally is to use the H2 database as the configuration database used by the registry, which can be started directly com.alipay.sofa.registry.server.integration.RegistryApplication#main\nBy default, application-dev.properties will be used as the configuration file\nDeployment The deployment of SOFARegistry relies on mysql, which uses mysql as the metadata storage of the registry itself SOFARegistry supports two types of deployment modes, which are integrated deployment and independent deployment. This topic describes the simplest integrated single-node deployment. For more information about deployment modes, see the Deployment topic.\nDeployment steps 1. Download the source code or installation package Download the source code git clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all Download the installation package You can download the latest registry-all.tgz package from Releases.\nrecommended to download v6 or above\ntar -zxvf registry-all.tgz cd registry-all 2. Start registry-integration 2.1 If you start the development registry locally, you can use h2 as the database\nIDEA source code startup: run com.alipay.sofa.registry.server.integration.RegistryApplication#main\nFat jar script start command: sh bin/start_dev.sh\n2.2 MySQL is recommended for the official environment Create database and table\necho \u0026amp;quot;create database registrymetadb \u0026amp;quot; | mysql -u username -p mysql -u username -p registrymetadb \u0026amp;lt; create_table.sql Modify the configuration in conf/application.properties, the database password can also be passed in through the JDBC_PASSWORD environment variable\nStart command: sh bin/integration/start.sh\n3. Check the running status You can access the healthcheck API provided by these three roles, or view logs/registry-startup.log to check the running status.\n# View the healthcheck API of the meta role: $ curl http://localhost:9615/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... raftStatus:Leader\u0026amp;quot;} # View the healthcheck API of the data role: $ curl http://localhost:9622/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... status:WORKING\u0026amp;quot;} # View the healthcheck API of the session role: $ curl http://localhost:9603/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-registry/server-quick-start/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b620900b56ba04f4668838846a97698a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/server-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/server-quick-start/","summary":"Local development Starting SOFARegistry locally is to use the H2 database as the configuration database used by the registry, which can be started directly com.alipay.sofa.registry.server.integration.RegistryApplication#main\nBy default, application-dev.properties will be used as the configuration file\nDeployment The deployment of SOFARegistry relies on mysql, which uses mysql as the metadata storage of the registry itself SOFARegistry supports two types of deployment modes, which are integrated deployment and independent deployment. This topic describes the simplest integrated single-node deployment.","tags":null,"title":"Server deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/server-quick-start/","wordcount":290},{"author":null,"categories":null,"content":" 本文是关于 MOSN server 配置的说明。\n虽然 MOSN 的配置结构里 servers 是一个 server 数组，但是目前最多只支持配置一个server。\nserver 描述的 MOSN 的基本的全局参数如下所示。\n{ \u0026amp;quot;default_log_path\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;default_log_level\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;global_log_roller\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;graceful_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;processor\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;listeners\u0026amp;quot;:[] } default_log_path 默认的错误日志文件路径，支持配置完整的日志路径，以及标准输出（stdout）和标准错误（stderr）。\n 如果配置为空，则默认输出到标准错误（stderr）。 default_log_level 默认的错误日志级别，支持DEBUG、INFO、WARN、ERROR、FATAL。\n 如果配置为空，则默认为 INFO。 global_log_roller 日志轮转配置，会对所有的日志生效，如 tracelog、accesslog、defaultlog。 字符串配置，支持两种模式的配置，一种是按时间轮转，一种是按日志大小轮转。同时只能有一种模式生效。 按照日志大小轮转\n size， 表示日志达到多少 M 进行轮转。 age，表示最多保存多少天的日志。 keep，表示最多保存多少个日志。 compress，表示日志是否压缩，on 为压缩，off 为不压缩。\n\u0026amp;quot;global_log_roller\u0026amp;quot;: \u0026amp;quot;size=100 age=10 keep=10 compress=off\u0026amp;quot; 按照时间轮转\n time，表示每个多少个小时轮转一次。\n\u0026amp;quot;global_log_roller\u0026amp;quot;:\u0026amp;quot;time=1\u0026amp;quot; graceful_timeout Duration String 的字符串配置，表示 MOSN 在进行平滑升级时，等待连接关闭的最大时间。 如果没有配置，默认为 30s。 processor MOSN 使用的 GOMAXPROCS 数量 - 如果没有配置，默认为 CPU 数量。 - 如果配置为 0，等价于没有配置。\nListeners 一组 Listener 的配置。\n","date":-62135596800,"description":"","dir":"projects/mosn/configuration/server/overview/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3b43981b2aebeca5879d566d8264f6b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/server/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/configuration/server/overview/","summary":"本文是关于 MOSN server 配置的说明。 虽然 MOSN 的配置结构里 servers 是一个 server 数组，但是目前最多只支持配置一个server。 server 描述的 MOSN 的基本的全局参数如下所示。 { \u0026quot;default_log_path\u0026quot;:\u0026quot;\u0026quot;,","tags":null,"title":"Server 配置说明","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/server/overview/","wordcount":528},{"author":null,"categories":null,"content":"If you want to extend a registry center, you should take a look at the abstract classes of the registry center.\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026amp;lt;ProviderConfig\u0026amp;gt; configs); public abstract List\u0026amp;lt;ProviderGroup\u0026amp;gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026amp;lt;ConsumerConfig\u0026amp;gt; configs); } You can see the main necessary interfaces.\nStart the registry client and maintain the connection; Destroy the registry client and release resources; Publish service and cache publish information; Unpublish service and delete cache; Subscribe to service list, return data synchronously or asynchronously, and receive notifications upon changes Unsubscribe service list and delete cache Other interfaces:\nWhen the registry center node is disconnected, the local call is not affected. Switch from one disconnected registry center node to another one by itself. After switching to another registry center node, the system resumes the registration and subscription information automatically. The registry data is cached to the local file. Even if no registry center node is connected, the service provider and caller can restart and call normally. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-extension-guide/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c952ecbea16f7ae68ad095ab8baf0583","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","summary":"If you want to extend a registry center, you should take a look at the abstract classes of the registry center.\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026lt;ProviderConfig\u0026gt; configs); public abstract List\u0026lt;ProviderGroup\u0026gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026lt;ConsumerConfig\u0026gt; configs); } You can see the main necessary interfaces.","tags":null,"title":"Service Registry extension guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","wordcount":192},{"author":null,"categories":null,"content":" SOFADashboard\u0026amp;rsquo;s service governance mainly manages SOFARPC services.\nConsole The service governance console mainly provides two basic functions: service name query and service information display. When you click the hyperlink of a service ID, you are redirected to the details page of the service.\nService provider details page Service consumer details page ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/governance/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e547baf489fd5d125be9e67a366854b6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/governance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/governance/","summary":" SOFADashboard\u0026rsquo;s service governance mainly manages SOFARPC services.\nConsole The service governance console mainly provides two basic functions: service name query and service information display. When you click the hyperlink of a service ID, you are redirected to the details page of the service.\nService provider details page Service consumer details page ","tags":null,"title":"Service governance","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/governance/","wordcount":51},{"author":null,"categories":null,"content":" The basic configuration for SOFARPC service publishing and reference is described in the \u0026amp;ldquo;Programming Interface\u0026amp;rdquo; chapter. Here are some of the features of service publishing and referencing.\nOne service publishes multiple protocols In SOFARPC, a service can be published as multiple protocols, which allows the callers to call the service provider using different protocols.\nIf you use the Java API, you can build multiple ServerConfigs as follows to set different protocols for different ServerConfigs and then assign these ServerConfigs to ProviderConfig:\nList\u0026amp;lt;ServerConfig\u0026amp;gt; serverConfigs = new ArrayList\u0026amp;lt;ServerConfig\u0026amp;gt;(); serverConfigs.add(serverConfigA); serverConfigs.add(serverConfigB); providerConfig.setServer(serverConfigs); If you use XML, add multiple bindings directly in the \u0026amp;lt;sofa:service\u0026amp;gt; tag:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; If you use annotation, add multiple bindings in @SofaService:\n@SofaService ( interfaceType = SampleService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;), @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) } ) public class SampleServiceImpl implements SampleService { // ... } One service registers multiple registry centers If you use the API, build multiple RegistryConfigs and assign them to ProviderConfig:\nList\u0026amp;lt;RegistryConfig\u0026amp;gt; registryConfigs = new ArrayList\u0026amp;lt;RegistryConfig\u0026amp;gt;(); registryConfigs.add(registryA); registryConfigs.add(registryB); providerConfig.setRegistry(registryConfigs); Method-level parameter settings In the Java API mode, you can set the corresponding parameters by calling the set method of the MethodConfig object, as shown below:\nMethodConfig methodConfigA = new MethodConfig(); MethodConfig methodConfigB = new MethodConfig(); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfigA); methodConfigs.add(methodConfigB); providerConfig.setMethods(methodConfigs); //server settings consumerConfig.setMethods(methodConfigs); //Client settings In the XML mode, you can use the \u0026amp;lt;sofa:method\u0026amp;gt; tag in the corresponding binding to set the corresponding parameters:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;3000\u0026amp;quot; address-wait-time=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Call timeout; address wait time. --\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:22000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Directly connected address --\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;sayName\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Method level configuration --\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/publish-and-reference/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"6a78b8b84b226eaf1e6d2b1ff1d15fee","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","summary":"The basic configuration for SOFARPC service publishing and reference is described in the \u0026ldquo;Programming Interface\u0026rdquo; chapter. Here are some of the features of service publishing and referencing.\nOne service publishes multiple protocols In SOFARPC, a service can be published as multiple protocols, which allows the callers to call the service provider using different protocols.\nIf you use the Java API, you can build multiple ServerConfigs as follows to set different protocols for different ServerConfigs and then assign these ServerConfigs to ProviderConfig:","tags":null,"title":"Service publishing and reference","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","wordcount":348},{"author":null,"categories":null,"content":" This document describes the complete SOFARPC service publishing and reference in the SOFABoot environment.\nPublish service \u0026amp;lt;bean id=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; thread-pool-ref=\u0026amp;quot;\u0026amp;quot; warm-up-time=\u0026amp;quot;60000\u0026amp;quot; warm-up-weight=\u0026amp;quot;10\u0026amp;quot; weight=\u0026amp;quot;100\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Attribute Name Default value Comment id ID bean名 class Class None ref Service interface implementation class interface Service interface (unique identifier) Use actual interface class for both normal calls and return calls unique-id Service tag (unique identifier) filter Filter configuration alias Separated by commas registry Server registry center Separated by commas timeout Execution timeout period on the server serialize-type Serialization protocol hessian2,protobuf thread-pool-ref Thread pool used by the current interface of the server None weight Service static weight warm-up-weight Service warm-up weight warm-up-time Service warm-up time Unit: millisecond Reference service \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;helloSyncServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;sync\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; address-wait-time=\u0026amp;quot;1000\u0026amp;quot; connect.num=\u0026amp;quot;1\u0026amp;quot; check=\u0026amp;quot;false\u0026amp;quot; connect.timeout=\u0026amp;quot;1000\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; generic-interface=\u0026amp;quot;\u0026amp;quot; idle.timeout=\u0026amp;quot;1000\u0026amp;quot; idle.timeout.read=\u0026amp;quot;1000\u0026amp;quot; lazy=\u0026amp;quot;false\u0026amp;quot; loadBalancer=\u0026amp;quot;\u0026amp;quot; registry=\u0026amp;quot;\u0026amp;quot; retries=\u0026amp;quot;1\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;xxx:12200\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; type=\u0026amp;quot;sync\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Attribute Name Default value Comment id ID Generated automatically jvm-first Whether to call the service of local machine first true interface Service interface (unique identifier) Use actual interface class for both normal calls and return calls unique-id Service tag (unique identifier) local-first whether refer to the service via jvm call true set it to false if this is to call a remote service via rpc type Calling type sync callback,sync,future,oneway filter Filter configuration alias List registry Server …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/rpc-config-xml-explain/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"4b5110e9eb6cf6c6f287aef0fd210047","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","summary":"This document describes the complete SOFARPC service publishing and reference in the SOFABoot environment. Publish service \u0026lt;bean id=\u0026quot;helloSyncServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;helloSyncServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026quot; unique-id=\u0026quot;\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs registry=\u0026quot;\u0026quot; serialize-type=\u0026quot;\u0026quot; filter=\u0026quot;\u0026quot; timeout=\u0026quot;3000\u0026quot; thread-pool-ref=\u0026quot;\u0026quot; warm-up-time=\u0026quot;60000\u0026quot; warm-up-weight=\u0026quot;10\u0026quot; weight=\u0026quot;100\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;sofa:binding.rest\u0026gt; \u0026lt;/sofa:binding.rest\u0026gt; \u0026lt;/sofa:service\u0026gt; Attribute Name Default value Comment id ID bean名 class Class None ref Service interface implementation class interface Service interface (unique identifier) Use actual interface class for both normal calls","tags":null,"title":"Service publishing and reference in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","wordcount":356},{"author":null,"categories":null,"content":" Sidecar 模式是 Service Mesh 中习惯采用的模式，是容器设计模式的一种，在 Service Mesh 出现之前该模式就一直存在，本文将为您讲解 Sidecar 模式。\n什么是 Sidecar 模式 将应用程序的功能划分为单独的进程可以被视为 Sidecar 模式。如图所示，Sidecar 模式允许您在应用程序旁边添加更多功能，而无需额外第三方组件配置或修改应用程序代码。\n就像连接了 Sidecar 的三轮摩托车一样，在软件架构中， Sidecar 连接到父应用并且为其添加扩展或者增强功能。Sidecar 应用与主应用程序松散耦合。它可以屏蔽不同编程语言的差异，统一实现微服务的可观察性、监控、日志记录、配置、断路器等功能。\n使用 Sidecar 模式的优势 Sidecar 模式具有以下优势：\n 将与应用业务逻辑无关的功能抽象到共同基础设施降低了微服务代码的复杂度。\n 因为不再需要编写相同的第三方组件配置文件和代码，所以能够降低微服务架构中的代码重复度。\n 降低应用程序代码和底层平台的耦合度。\n Sidecar 模式如何工作 Sidecar 是容器应用模式的一种，也是在 Service Mesh 中发扬光大的一种模式，详见 Service Mesh 架构解析，其中详细描述使用了节点代理和 Sidecar 模式的 Service Mesh 架构。\n使用 Sidecar 模式部署服务网格时，无需在节点上运行代理，但是集群中将运行多个相同的 Sidecar 副本。在 Sidecar 部署方式中，每个应用的容器旁都会部署一个伴生容器，这个容器称之为 Sidecar 容器。Sidecar 接管进出应用容器的所有流量。在 Kubernetes 的 Pod 中，在原有的应用容器旁边注入一个 Sidecar 容器，两个容器共享存储、网络等资源，可以广义的将这个包含了 Sidecar 容器的 Pod 理解为一台主机，两个容器共享主机资源。\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/sidecar-pattern/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"38b45799d69d52f24f26008cd2ad7da5","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/sidecar-pattern/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/concept/sidecar-pattern/","summary":"Sidecar 模式是 Service Mesh 中习惯采用的模式，是容器设计模式的一种，在 Service Mesh 出现之前该模式就一直存在，本文将为您讲解 Sidecar 模式。 什么是 Sidecar 模式 将应用程序的功能划分为","tags":null,"title":"Sidecar 模式","type":"projects","url":"/sofastack.tech/projects/mosn/concept/sidecar-pattern/","wordcount":602},{"author":null,"categories":null,"content":" Since SOFARPC 5.4.0, the link analysis feature of Skywalking is supported. You can use it as needed. The Skywalking must be 6.0.0-alpha and above.\nThis document does not cover the backend deployment. If you need it, please refer to the official Skywalking documentation.\nInstall Java agent Locate the agent directory in the downloaded Skywalking release package.\n Set agent.service_name in config/agent.config, which can be any English character. Generally, it can be your own system name.\n Set the collector.backend_service Skywalking backend address in config/agent.config, which defaults to 127.0.0.1:11800. It is used for local verification.\n Add -javaagent:/path/to/skywalking-package/agenxt/skywalking-agent.jar to the application, which must be placed before the -jar parameter. The skywalking-agent can be gotten in official release package. The new directory structure is as follows:\n+-- agent +-- activations apm-toolkit-log4j-1.x-activation.jar apm-toolkit-log4j-2.x-activation.jar apm-toolkit-logback-1.x-activation.jar ... +-- config agent.config +-- plugins sofa-rpc-plugin-6.0.0-alpha.jar apm-feign-default-http-9.x.jar apm-httpClient-4.x-plugin.jar ..... skywalking-agent.jar Note: Ensure that the plugins/sofa-rpc-plugin-**.jar file exists.\n Start the application. After a period of RPC calls, you can view the UI to observe the calling link.\n More For more relevant documents, please refer to\nSkywalking Agent installation documentation Skywalking Backend deployment documentation\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/skywalking-usage/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3cd5fb45f1b981d0a8c54c8ce43b190b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","summary":"Since SOFARPC 5.4.0, the link analysis feature of Skywalking is supported. You can use it as needed. The Skywalking must be 6.0.0-alpha and above.\nThis document does not cover the backend deployment. If you need it, please refer to the official Skywalking documentation.\nInstall Java agent Locate the agent directory in the downloaded Skywalking release package.\n Set agent.service_name in config/agent.config, which can be any English character. Generally, it can be your own system name.","tags":null,"title":"Skywalking","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","wordcount":181},{"author":null,"categories":null,"content":" SOFARPC 在5.4.0 及之后的版本中，已经支持 Skywalking 的链路分析的功能，用户可以根据需要进行使用，其中Skywalking 的版本 要求6.0.0-alpha及以上。本文档，不涉及后端的部署，如有需要，可查看 Skywalking 官方文档。\n安装 Java agent 1.在下载的 Skywalking 的release 包中找到 agent 目录。\n2.在config/agent.config 中设置 agent.service_name，可以是任何英文字符，一般可以设置为自己的系统名。\n3.在config/agent.config 中设置 collector.backend_service Skywalking 的后端地址，默认指向 127.0.0.1:11800,这个是为了本地验证的。\n4.给应用程序添加 -javaagent:/path/to/skywalking-package/agenxt/skywalking-agent.jar，其中注意，一定要放在 -jar 参数之前。 Agent 在 kywalking 的 官方 release 包. 新的目录结构如下.\n+-- agent +-- activations apm-toolkit-log4j-1.x-activation.jar apm-toolkit-log4j-2.x-activation.jar apm-toolkit-logback-1.x-activation.jar ... +-- config agent.config +-- plugins sofa-rpc-plugin-6.0.0-alpha.jar apm-feign-default-http-9.x.jar apm-httpClient-4.x-plugin.jar ..... skywalking-agent.jar 注意，确保plugins/sofa-rpc-plugin-**.jar 文件存在。\n5.启动应用程序，经过一段时间RPC调用后，可以查看 UI 来观察链路。\n更多 更多文档请参考\n Skywalking Agent 安装文档 Skywalking Backend 部署文档 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/skywalking-usage/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3cd5fb45f1b981d0a8c54c8ce43b190b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/skywalking-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/skywalking-usage/","summary":"SOFARPC 在5.4.0 及之后的版本中，已经支持 Skywalking 的链路分析的功能，用户可以根据需要进行使用，其中Skywalking 的版本 要求6.0.0-alpha","tags":null,"title":"Skywalking 链路分析","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/skywalking-usage/","wordcount":482},{"author":null,"categories":null,"content":" SOFABoot 提供了模块并行启动以及 Spring Bean 异步初始化能力，用于加快应用启动速度。本文介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力以提高应用启动速度。\n使用场景 在实际使用 Spring/Spring Boot 开发中，一些 Bean 在初始化过程中执行准备操作，如拉取远程配置、初始化数据源等等。在应用启动期间，这些 Bean 会增加 Spring 上下文刷新时间，导致应用启动耗时变长。\n为了加速应用启动，SOFABoot 通过配置可选项，将 Bean 的初始化方法（init-method）使用单独线程异步执行，加快 Spring 上下文加载过程，提高应用启动速度。\n引入依赖 在工程的 pom.xml 文件中，引入如下 starter：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 使用方法 异步初始化 Bean 的原理是开启单独线程负责执行 Bean 的初始化方法（init-method）。因此，除了引入上述依赖，还需要在 Bean 的 XML 定义中配置 async-init=\u0026amp;ldquo;true\u0026amp;rdquo; 属性，用于指定是否异步执行该 Bean 的初始化方法，例如：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- async init test --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBean\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.beans.TimeWasteBean\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot; async-init=\u0026amp;quot;true\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 属性配置 SOFABoot 异步初始化能力提供两个属性配置，用于指定负责异步执行 Bean 初始化方法（init-method）的线程池大小：\n com.alipay.sofa.boot.asyncInitBeanCoreSize：线程池基本大小，默认值为 CPU 核数加一。 com.alipay.sofa.boot.asyncInitBeanMaxSize：线程池中允许的最大线程数大小，默认值为 CPU 核数加一。 此配置可以通过 VM -D 参数或者 Spring Boot 配置文件 application.yml 设置。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/bean-async-init/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1b7c2d94076ffb7ac96f64a557067917","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/bean-async-init/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/bean-async-init/","summary":"SOFABoot 提供了模块并行启动以及 Spring Bean 异步初始化能力，用于加快应用启动速度。本文介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力以提高应用启动速度。 使用场景 在实际使用","tags":null,"title":"Spring Bean 异步初始化","type":"projects","url":"/sofastack.tech/projects/sofa-boot/bean-async-init/","wordcount":578},{"author":null,"categories":null,"content":" 借助 SofaArk 框架，一个普通的 Java 应用可拆分为一个宿主应用（master biz，又称“基座”）与多个业务应用（普通 biz，又称“模块”）的模式，细化研发粒度，以此实现更快速的研发运维。本文将介绍 Spring Boot 应用如何结合 SofaArk 框架，以此构建宿主应用与业务应用。文章由以下七点展开：\n 简介 如何构建 Spring Boot 业务应用 如何构建 Spring Boot 宿主应用 如何执行 Spring Boot 宿主应用 如何执行 Spring Boot 业务应用 多 Host 与单 Host 模式 如何动态卸载 Spring Boot 业务应用 1. 简介 宿主应用（master biz）负责沉淀通用的逻辑，为业务应用提供计算和环境，为业务应用的开发者屏蔽基础设施，更新迭代较慢。各个业务应用（普通 biz）是独立的代码仓库，可以进行独立的研发运维，粒度小，更新迭代较快。业务应用将通用的依赖下沉至宿主应用，依赖宿主应用的环境运行，不是一个 可执行 Jar，因此业务应用自身的 jar 包可以不包含该通用依赖，以此得到轻量化的业务应用 jar 包。\n宿主应用与业务应用的运行关系是：宿主应用首先启动，拥有与普通应用相同的类加载器；业务应用 jar 包以热拔插的模式在宿主应用中动态部署，通用依赖通过宿主应用的类加载器加载，其它依赖使用业务自己的BizClassLoader进行加载。\n本文中宿主应用和业务应用均为 Web 应用，采用了单 host 模式，其样例代码地址如下：\n Spring Boot 宿主应用：Spring Boot 宿主应用 Spring Boot 业务应用：Spring Boot 业务应用 2. 如何构建 Spring Boot 业务应用 业务应用是一种普通 Biz，换而言之，“如何构建业务应用”即为“如何构建普通 Ark Biz”，Ark Biz的介绍请详见Ark Biz。\n2.1 依赖配置 首先，我们需要把业务应用构建成一种 SofaArk 框架可识别的Ark Biz，即：使用Ark Biz打包构建的依赖，配置如下：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;{sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;!-- 建议使用最新版本--\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;skipArkExecutable\u0026amp;gt;true\u0026amp;lt;/skipArkExecutable\u0026amp;gt; \u0026amp;lt;!-- 不生成可执行 fat jar--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!-- 生成的 Ark Biz 所在目录--\u0026amp;gt; \u0026amp;lt;bizName\u0026amp;gt;spring-boot-ark-biz\u0026amp;lt;/bizName\u0026amp;gt; \u0026amp;lt;!-- Ark Biz 名字--\u0026amp;gt; \u0026amp;lt;!-- webContextPath 是单 host 模式下的必要配置，详细配置见 5. 多 host 模式与单 host 模式 --\u0026amp;gt; \u0026amp;lt;webContextPath\u0026amp;gt;biz\u0026amp;lt;/webContextPath\u0026amp;gt; \u0026amp;lt;!-- 同一个host中设置不同的webContextPath--\u0026amp;gt; \u0026amp;lt;!-- declaredMode 开启后，业务应用可以使用自己声明过的、且宿主应用拥有的通用依赖--\u0026amp;gt; \u0026amp;lt;declaredMode\u0026amp;gt;true\u0026amp;lt;/declaredMode\u0026amp;gt; \u0026amp;lt;!-- 使用宿主应用的通用依赖--\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;!-- 此处不使用 spring boot 应用的原有构建依赖--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;plugin\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;/plugin\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 其次，由于业务应用运行时使用宿主应用的通用依赖，因此业务应用需要“排除”通用依赖，即：把 scope 设置成 provided。本样例代码中，业务应用直接使用宿主应用的 spring boot 各项依赖，配置如下：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2 打包 首先，使用 maven 打包业务应用，如下：\nmvn clean package -Dmaven.test.skip=true 在之前设定的 outputDirectory 目录下，后缀为ark-biz.jar的包是业务应用的 Ark …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-spring-boot-demo/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa8f11f9f806997290dac0ff5c105ab6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","summary":"借助 SofaArk 框架，一个普通的 Java 应用可拆分为一个宿主应用（master biz，又称“基座”）与多个业务应用（普通 biz，又称“模块”）的模式，细化研","tags":null,"title":"Spring Boot 应用如何结合 SofaArk","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","wordcount":3263},{"author":null,"categories":null,"content":" In this document will demonstrate how to use SOFATracer to track of SpringMVC, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs Add a simple Controller In the project code, add a simple Controller, for example:\n@RestController public class SampleRestController { private static final String TEMPLATE = \u0026amp;quot;Hello, %s!\u0026amp;quot;; private final AtomicLong counter = new AtomicLong(); /** * http://localhost:8080/springmvc * @param name name * @return map */ @RequestMapping(\u0026amp;quot;/springmvc\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; springmvc(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;SOFATracer SpringMVC DEMO\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; resultMap = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); resultMap.put(\u0026amp;quot;success\u0026amp;quot;, true); resultMap.put(\u0026amp;quot;id\u0026amp;quot;, counter.incrementAndGet()); resultMap.put(\u0026amp;quot;content\u0026amp;quot;, String.format(TEMPLATE, name)); return resultMap; } } Run the project Start Current SOFABoot Application. You will see the log about startup in the console:\n2018-05-11 11:55:11.932 INFO 66490 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcOpenTracingFilter\u0026#39; to urls: [/*] 2018-05-11 11:55:13.961 INFO 66490 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-05-11 11:55:13.970 INFO 66490 --- [ main] c.a.s.t.e.springmvc.DemoApplication : Started DemoApplication in 8.361 seconds (JVM running for 9.34) You can access the REST service by visiting http://localhost:8080/springmvc in your browser. You can see the result similar to the followings:\n{ content: \u0026amp;quot;Hello, SOFATracer SpringMVC DEMO!\u0026amp;quot;, id: 1, success: true } View log In the application.properties, the log printing directory we configured is ./logs, which is the root directory of the current application (we can configure it based on actual situation). In the root directory, you can see log files in the structure similar to the followings:\n./logs ├── spring.log └── tracelog ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log Every time you visit http://localhost:8080/springmvc, SOFATracer will log the digest log. You can open the spring-mvc-digest.log file to see the specific log content. As for the meaning of each output field, you can refer to here.\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-05-17 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-mvc/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"6c6389a6f994f43f08cbdf4a49d1755a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","summary":"In this document will demonstrate how to use SOFATracer to track of SpringMVC, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.","tags":null,"title":"Spring MVC Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","wordcount":356},{"author":null,"categories":null,"content":" SpringMVC Log Format After integrating SpringMVC, SOFATracer will output the link data format of the MVC requests, which is JSON by default.\nSpring MVC digest log (spring-mvc-digest.log) Data is ouput in JSON format. The meaning of each key is as follows:\n Key Meaning Time Log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.code HTTP return status code req.size.bytes Request body size resp.size.bytes Response body size Time.cost.milliseconds Request time (ms) Current.thread.name Current thread name Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-06-03 16:44:05.829\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SpringMvcJsonOutput\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;c0a80d9e1528015445828101064625\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:63933/greeting\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:50,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:1,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-auto-1-exec-10\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring MVC statistical log (spring-mvc-stat.log) stat.key is a collection of statistical keywords in this period., which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration for (ms) requests in this period success Request result: Y means success (the result code starting with 1 and 2 indicates success, and 302 indicates that the redirection is successful, and others indicate failure); N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-06-03 16:44:02.473\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:63933/greeting\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SpringMvcJsonOutput\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:5,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:149,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;Y\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-springmvc/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"af13acf5aee90a32f0fa143996063a91","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","summary":"SpringMVC Log Format After integrating SpringMVC, SOFATracer will output the link data format of the MVC requests, which is JSON by default.\nSpring MVC digest log (spring-mvc-digest.log) Data is ouput in JSON format. The meaning of each key is as follows:\n Key Meaning Time Log printing time Local.app Current application name traceId TraceId spanId SpanId Request.","tags":null,"title":"Spring MVC log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","wordcount":200},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 SpringMVC 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private static final String TEMPLATE = \u0026amp;quot;Hello, %s!\u0026amp;quot;; private final AtomicLong counter = new AtomicLong(); /** * http://localhost:8080/springmvc * @param name name * @return map */ @RequestMapping(\u0026amp;quot;/springmvc\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; springmvc(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;SOFATracer SpringMVC DEMO\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; resultMap = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); resultMap.put(\u0026amp;quot;success\u0026amp;quot;, true); resultMap.put(\u0026amp;quot;id\u0026amp;quot;, counter.incrementAndGet()); resultMap.put(\u0026amp;quot;content\u0026amp;quot;, String.format(TEMPLATE, name)); return resultMap; } } 运行 启动 SOFABoot 应用，将会在控制台中看到启动打印的日志：\n2018-05-11 11:55:11.932 INFO 66490 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcOpenTracingFilter\u0026#39; to urls: [/*] 2018-05-11 11:55:13.961 INFO 66490 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-05-11 11:55:13.970 INFO 66490 --- [ main] c.a.s.t.e.springmvc.DemoApplication : Started DemoApplication in 8.361 seconds (JVM running for 9.34) 可以通过在浏览器中输入 http://localhost:8080/springmvc 来访问 REST 服务，结果类似如下：\n{ content: \u0026amp;quot;Hello, SOFATracer SpringMVC DEMO!\u0026amp;quot;, id: 1, success: true } 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 通过访问 http://localhost:8080/springmvc SOFATracer 会记录每一次访问的摘要日志，可以打开 spring-mvc-digest.log 看到具体的输出内容。\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8801-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5006ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-mvc/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6c6389a6f994f43f08cbdf4a49d1755a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","summary":"在本文档将演示如何使用 SOFATracer 对 SpringMVC 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt;","tags":null,"title":"Spring MVC 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","wordcount":514},{"author":null,"categories":null,"content":" SOFATracer 集成 SpringMVC 后输出 MVC 请求的链路数据格式，默认为 JSON 数据格式。\nSpring MVC 摘要日志（spring-mvc-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8801-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5006ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring MVC 统计日志（spring-mvc-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功(1 开头和 2 开头的结果码算是成功的，302表示的重定向算成功，其他算是失败的)；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:34:04.129\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5006,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-springmvc/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"af13acf5aee90a32f0fa143996063a91","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","summary":"SOFATracer 集成 SpringMVC 后输出 MVC 请求的链路数据格式，默认为 JSON 数据格式。 Spring MVC 摘要日志（spring-mvc-digest.log） 以 JSON 格式输出的数据，相应 key 的","tags":null,"title":"Spring MVC 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","wordcount":380},{"author":null,"categories":null,"content":" 本文将向您展示 MOSN 的 TLS 安全能力。\n证书方案 MOSN 支持通过 Istio Citadel 的证书签发方案，基于 Istio 社区的 SDS （Secret Discovery Service）方案为 Sidecar 配置证书，支持证书动态发现和热更新能力。为了支持更高级的安全能力，MOSN 没有使用 Citadel 的证书自签发能力，而是通过对接内部 KMS 系统获取证书。同时提供证书缓存和证书推送更新能力。\n我们先来看看 MOSN 证书方案的架构图，如下图所示：\n各组件职能如下：\n Pilot：负责 Policy、SDS 配置下发，为简化复杂度，图中未标出 Citadel：Citadel 作为 Certificate Provider ，同时作为 MCP Server 为 Citadel Agent 提供 Pod、CR等资源 Citadel Agent：提供 SDS Server 服务，为MOSN、DB Sidecar、Security Sidecar 提供Certificate和CR下发能力 KMS：密钥管理系统负责证书签发 证书获取流程 对整体架构有个大致理解后，我们分解下 Sidecar 获取证书的流程，如下图所示：\n补充说明下图中的每一步环节：\n Citadel 与 Citadel agent（nodeagent）组件通过MCP协议（Mesh Configuration Protocol）同步Pod 和 CR 信息，避免 citadel agent 直接请求 API Server 导致 API Server 负载过高 MOSN 通过Unix Domain Socket 方式向 Citadel Agent 发起 SDS 请求 Citadel Agent 会进行防篡改校验，并提取appkey Citadel Agent 携带 appkey 请求 Citadel 签发证书 Citadel 检查证书是否已缓存，如果缓存证书未过期，Citadel 将直接响应缓存证书 证书不在缓存中，Citadel 会基于 appkey 构造证书签发请求，向 KMS 申请签发证书 KMS 会将签发的证书响应回Citadel，另外 KMS 也支持证书过期轮换通知 Citadel 收到证书后，会将证书传递给到对应的 Citadel Agent Citadel Agent 收到证书后，会在内存中缓存证书，并将证书下发给到 MOSN ","date":-62135596800,"description":"","dir":"projects/mosn/concept/tls/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"47ccccf9690bc65fa437463a8f5e55b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/tls/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/concept/tls/","summary":"本文将向您展示 MOSN 的 TLS 安全能力。 证书方案 MOSN 支持通过 Istio Citadel 的证书签发方案，基于 Istio 社区的 SDS （Secret Discovery Service）方案为 Sidecar 配置证书，支持证书","tags":null,"title":"TLS 安全链路","type":"projects","url":"/sofastack.tech/projects/mosn/concept/tls/","wordcount":654},{"author":null,"categories":null,"content":" SOFAArk 容器提供了一个简单的 telnet 服务端小工具，用于运行时查看容器状态，目前支持查看 Plugin 和 Biz 相关信息。\n使用方式 使用 telnet 连接服务端，端口号为 1234， 例如：\n telnet localhost 1234\n 进入交互界面:\n➜ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is \u0026#39;^]\u0026#39;. sofa-ark\u0026amp;gt; sofa-ark\u0026amp;gt; sofa-ark\u0026amp;gt; 目前支持查看 Plugin 和 Biz 相关信息，相关命令可参考提示信息：\nsofa-ark\u0026amp;gt;h Plugin Command Tips: USAGE: plugin [option...] [pluginName...] SAMPLE: plugin -m plugin-A plugin-B -h Shows the help message. -a Shows all plugin name. -m Shows the meta info of specified pluginName. -s Shows the service info of specified pluginName. -d Shows the detail info of specified pluginName. Biz Command Tips: USAGE: biz [option...] [arguments...] SAMPLE: biz -m bizIdentityA bizIdentityB. -h Shows the help message. -a Shows all biz. -m Shows the meta info of specified bizIdentity. -s Shows the service info of specified bizIdentity. -d Shows the detail info of specified bizIdentity. -i Install biz of specified bizIdentity or bizUrl. -u Uninstall biz of specified bizIdentity. -o Switch biz of specified bizIdentity. sofa-ark\u0026amp;gt; Plugin 命令 如提示信息所说，plugin 支持查看插件相关信息，包括类(资源)导入导出配置、插件打包配置等。例如：\nsofa-ark\u0026amp;gt;plugin -md runtime-sofa-boot-plugin PluginName: runtime-sofa-boot-plugin Version: 3.1.3 Priority: 1500 Activator: com.alipay.sofa.runtime.integration.activator.SofaRuntimeActivator Export Packages: com.alipay.sofa.runtime.api.*,com.alipay.sofa.runtime.client.*,com.alipay.sofa.runtime.component.*,com.alipay.sofa.runtime.constants.*,com.alipay.sofa.runtime.integration.*,com.alipay.sofa.runtime.model.*,com.alipay.sofa.runtime.service.component,com.alipay.sofa.runtime.service.helper,com.alipay.sofa.runtime.spi.client,com.alipay.sofa.runtime.spi.component,com.alipay.sofa.runtime.spi.health,com.alipay.sofa.runtime.spi.log,com.alipay.sofa.runtime.spi.binding,com.alipay.sofa.runtime.spi.util,org.aopalliance.aop,org.aopalliance.intercept Import Packages: \\ Export Classes: com.alipay.sofa.runtime.service.binding.JvmBinding,com.alipay.sofa.runtime.SofaFramework,com.alipay.sofa.runtime.SofaRuntimeProperties,com.alipay.sofa.runtime.service.binding.JvmBindingParam,com.alipay.sofa.runtime.spi.service.ServiceProxy Import Classes: \\ Export Resources: \\ Import Resources: \\ GroupId: com.alipay.sofa ArtifactId: runtime-sofa-boot-plugin Version: 3.1.3 URL: jar:file:/Users/qilong.zql/.m2/repository/com/alipay/sofa/runtime-sofa-boot-plugin/3.1.3/runtime-sofa-boot-plugin-3.1.3.jar!/ ClassLoader: com.alipay.sofa.ark.container.service.classloader.PluginClassLoader@420a63fb ClassPath: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-telnet/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f23d585e5439569b47ed83f7bc955b22","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","summary":"SOFAArk 容器提供了一个简单的 telnet 服务端小工具，用于运行时查看容器状态，目前支持查看 Plugin 和 Biz 相关信息。 使用方式 使用 telnet 连接服务端，端口号为 1234， 例如：","tags":null,"title":"Telnet 指令","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","wordcount":513},{"author":null,"categories":null,"content":" Ark package The Executed Fat Jar that meets the specific directory format requirements can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package the engineering application into a standard-format Ark package. Start the application on top of the SOFAArk container with the java -jar command. The Ark package usually contains the Ark Container, Ark Plugin dependency (if any), merged deployed Ark Biz (if any), and the Ark Biz of the application itself. For details, refer to the Ark package；\nArk Container The Ark container (Ark Plugin and Ark Biz) runs on top of the SOFAArk container. The container has the ability to manage multiple plug-ins and applications. After successful start, the container will resolve the configuration of Ark Plugin and Ark Biz, complete loading of the isolation and start them in turn based on their priorities. For details, refer to SOFAArk container startup；\nArk Plugin The Ark plug-in, which meets the specific fat jar directory format requirements, can use the officially provided Maven plug-in (sofa-Ark-plugin-maven-plugin) to package one or multiple common Java Jar packages into a standard-format Ark Plugin. Ark Plugin will contain a configuration file that usually contains the import and export configuration of plug-in classes and resources and the priority of plug-in startup. When running, the Ark container will use an independent PluginClassLoader to load the plug-ins, and build the index table for class loading according to the plug-in configuration, so that the plug-ins are isolated from each other and from the applications. For details, refer to Ark Plugin；\nArk Biz The Ark module, which meets the specific fat jar directory format requirements, can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package an engineering application into a standard-format Ark Biz package. The Ark Biz package has two roles: one is to be the organizational unit of the engineering application module and its dependent packages, and the other is to be used as a common jar package dependency by other applications to start multiple Ark Biz packages in the same SOFAArk container. Multiple Ark Biz packages share the Ark Container and Ark Plugin. For details, refer to Ark Biz；\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-terminology/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b6d0ed10afe9d04bc00307017ffba7c5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","summary":"Ark package The Executed Fat Jar that meets the specific directory format requirements can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package the engineering application into a standard-format Ark package. Start the application on top of the SOFAArk container with the java -jar command. The Ark package usually contains the Ark Container, Ark Plugin dependency (if any), merged deployed Ark Biz (if any), and the Ark Biz of the application itself.","tags":null,"title":"Terminologies","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","wordcount":351},{"author":null,"categories":null,"content":" Explanation of Terms Terminology Description TraceId TraceId refers to the ID that represents the unique request in SOFATracer. This ID is generally generated by the first system in the cluster that processes the request and is passed over the network to the next requested system in distributed calls. SpanId SpanId represents the location or level of the request in the entire call link. For example, the system A calls system B, C, and D in sequence when processing a request. Then the SpanId of the three calls are respectively: 0.1, 0.2, 0.3. If system B continues to call system E and F, the SpanIds of the two calls are: 0.1.1, 0.1.2. For other related terminologies, see OpenTracing specification.\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/explanation/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"8ba307b0679e918f7ac68c7efb7e53f7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/explanation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/explanation/","summary":"Explanation of Terms Terminology Description TraceId TraceId refers to the ID that represents the unique request in SOFATracer. This ID is generally generated by the first system in the cluster that processes the request and is passed over the network to the next requested system in distributed calls. SpanId SpanId represents the location or level of the request in the entire call link.","tags":null,"title":"Terminologies","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/explanation/","wordcount":118},{"author":null,"categories":null,"content":" General terminology Term Description Service A software function provided over the network with specific business logic processing capabilities. Service provider A computer node that provides services over the network. Service consumer A computer node that receives services through the network. The same computer node can both be the service provider of some services and the service consumer of others. Service discovery The process in which the service consumer obtains the network address of the service provider. Service registry A software system that provides service discovery functions to help service consumers obtain network addresses of service providers. Data center An independent physical area with a fixed physical location, stable power supply, and reliable network. A data center is usually an important factor that you want to consider in high availability design. Generally, deployment in the same data center features higher network quality, lower latency, but limited disaster recovery capability. However, deployment across different data centers features lower network quality, higher latency, but better disaster recovery capability. SOFARegistry terminology Terminology Description SOFARegistry A registry product open sourced by Ant Financial to provide service discovery based on the \u0026amp;ldquo;publishing-subscription\u0026amp;rdquo; mode. In addition to service discovery, SOFARegistry is applicable to more general \u0026amp;ldquo;publishing-subscription\u0026amp;rdquo; scenarios. Data In the context of service discovery, data specifically refers to the network address and some additional information of the service provider. In other circumstances, it also refers to information published to SOFARegistry. Zone The key concept of the zone-based architecture. In the context of service discovery, a zone is a collection of publishing and subscription requests. When you publish or subscribe to a service, you need to specify the zone name. For more information, see Active geo-redundant zone-based architecture solution. Publisher A node that publishes data to SOFARegistry. In the context of service discovery, the service provider is the publisher of the \u0026amp;ldquo;service provider\u0026amp;rsquo;s network address and additional information\u0026amp;rdquo;. Subscriber A node that subscribes to data from SOFARegistry. In the context of service discovery, the service consumer is the subscriber of the \u0026amp;ldquo;service provider\u0026amp;rsquo;s network address and additional information\u0026amp;rdquo;. Data ID A string that is used to identify the data. In the context of service discovery, DataId usually consists of the service port name, protocol, and version number. It is used as an identifier of the service. Group ID A string that is used for grouping data. It can be used in conjunction with DataId and InstanceId as a namespace identifier of data. Two services may be considered one same service only when their DataIds, GroupIds, and InstanceIds are identical. Instance ID A …","date":-62135596800,"description":"","dir":"projects/sofa-registry/terminology/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b678a49547c55f2a70e2d94dbce5b4a2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/terminology/","summary":"General terminology Term Description Service A software function provided over the network with specific business logic processing capabilities. Service provider A computer node that provides services over the network. Service consumer A computer node that receives services through the network. The same computer node can both be the service provider of some services and the service consumer of others.","tags":null,"title":"Terminology","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/terminology/","wordcount":508},{"author":null,"categories":null,"content":" Unit test Place the unit test cases in the modules developed by yourself.\nIf the cases rely on a third-party server (such as ZooKeeper), you must manually add the profile. See the registry-zookeeper module code.\nIf the cases rely on other modules and integration test is required, place them in the test/test-intergrated module.\nIf the cases also rely on a third-party server (such as ZooKeeper), place them in the test-intergrated-3rd module.\nPerformance test Close the following projects that are closed by default:\n-Dcontext.attachment.enable=false -Dserialize.blacklist.enable=false -Ddefault.tracer= -Dlogger.impl=com.alipay.sofa.rpc.log.SLF4JLoggerImpl -Dmultiple.classloader.enable=false -Devent.bus .enable=false\nA pressure test on BOLT+hessian has been done.\n Server: 4C8G virtual machine; gigabit network; jdk1.8.0_111;\n Client: 50 concurrent requests\n Protocol Request Response Server TPS Average RT (ms) bolt+hessian 1KB string 1KB string Directly return 10000 1.93 bolt+hessian 1KB string 1KB string Directly return 20000 4.13 bolt+hessian 1KB string 1KB string Directly return 30000 7.32 bolt+hessian 1KB string 1KB string Directly return 40000 15.78 bolt+hessian 1KB string 1KB string Directly return 50000 (Close to the utmost limit, error rate: 0.3%) 26.51 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/test/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ccda7c2372a7f55d61f682b72d3b1dc2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/test/","summary":"Unit test Place the unit test cases in the modules developed by yourself.\nIf the cases rely on a third-party server (such as ZooKeeper), you must manually add the profile. See the registry-zookeeper module code.\nIf the cases rely on other modules and integration test is required, place them in the test/test-intergrated module.\nIf the cases also rely on a third-party server (such as ZooKeeper), place them in the test-intergrated-3rd module.","tags":null,"title":"Test","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/test/","wordcount":169},{"author":null,"categories":null,"content":" When using the Bolt protocol for communication, invoke timeout defaults is 3 seconds. You can configure the timeout when referencing the service, and can also configure the timeout period from the dimension of service or method respectively. SOFARPC timeout can be set in milliseconds.\nService If you need to set the timeout from the dimension of service when publishing a service, just configure the timeout parameter to the corresponding value.\nUse XML If you reference the service using XML, set the value of the timeout attribute of the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag under the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation If you reference the service using Annotation, set the value of the timeout attribute of @SofaReferenceBinding:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, timeout = 2000)) private SampleService sampleService; Use API in Spring environment If you reference the service in Spring or Spring Boot environment, just set the value of timeout attribute of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setTimeout(2000) Use API in non-Spring environment If you reference service using the bare API of SOFARPC directly in non-Spring environment, just set the timeout attribute of ConsumerConfig:\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setTimeout(2000); Method If you want to adjust the timeout for a certain method in a service individually, you can set the timeout period from the dimension of method.\nFor a method, the timeout period of the method is prioritized. If not set, the timeout period of the service will be used.\nUse XML If you reference service using XML, just set the timeout attribute of the corresponding \u0026amp;lt;sofa: method\u0026amp;gt;:\n\u0026amp;lt;Sofa: Reference interface = \u0026amp;quot;com.example.demo .SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation No method is available for setting the method-level timeout with Annotation currenty.\nUse API in Spring environment To reference a service in Spring or Spring Boot environment, you can just set the value of timeout attribute of RpcBindingMethodInfo\nBoltBindingParam boltBindingParam = new BoltBindingParam(); RpcBindingMethodInfo rpcBindingMethodInfo = new RpcBindingMethodInfo(); rpcBindingMethodInfo.setName(\u0026amp;quot;hello\u0026amp;quot;); rpcBindingMethodInfo.setTimeout(2000); List\u0026amp;lt;RpcBindingMethodInfo\u0026amp;gt; rpcBindingMethodInfos = new ArrayList\u0026amp;lt;\u0026amp;gt;(); …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-timeout/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"cf14f73dc0c4672a9255ef55b56de419","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","summary":"When using the Bolt protocol for communication, invoke timeout defaults is 3 seconds. You can configure the timeout when referencing the service, and can also configure the timeout period from the dimension of service or method respectively. SOFARPC timeout can be set in milliseconds.\nService If you need to set the timeout from the dimension of service when publishing a service, just configure the timeout parameter to the corresponding value.","tags":null,"title":"Timeout control","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","wordcount":388},{"author":null,"categories":null,"content":" TraceId generation rule SOFATracer uses TraceId to concatenate the call logs of a request on each server. The TraceId is typically generated by the first server that receives the request. The generation rule is: server IP + generated time + incremental sequence + current process ID, such as:\n0ad1348f1403169275002100356696 The first 8 digits 0ad1348f is the IP of the machine that generates TraceId. This is a hexadecimal number, in which every two digits represents a part of IP. Based on the number, we can get a common IP address like 10.209.52.143 by converting every two digits into a decimal number. According to this rule, you can also figure out the first server that the request goes through. The next 13 digits 1403169275002 is the time to generate the TraceId. The next 4 digits 1003 is an auto-incrementing sequence that increases from 1000 to 9000. After reaching 9000, it returns to 1000 and then restarts to increase. The last 5 digits 56696 is the current process ID. Its role in tracerId is to prevent the TraceId conflicts caused by multiple processes in a single machine. Currently, TraceId\u0026amp;rsquo;s generated rules refer to Taobao\u0026amp;rsquo;s Hawkeye components.\n SpanId generation rule The SpanId in SOFATracer represents where the current call is in the entire calling link. If a Web system A receives a user request, then in the SOFATracer MVC log of this system, the recorded SpanId is 0, which means the root node of the entire call. If the system A processes this request and needs to call system B, C, and D through RPC, then the SpanIds in the SOFATracer RPC client log of system A are 0.1, 0.2, and 0.3 respectively. And in the SOFATracer RPC server logs of the system B, C, and D, the SpanIds are also 0.1, 0.2 and 0.3 respectively. If system C calls system E and F when processing the request, then in the corresponding SOFATracer RPC client log of system C, the SpanIds are 0.2.1 and 0.2.2. And the SpanIds in the SOFATracer RPC server logs of system E and F are also 0.2.1 and 0.2.2. As we can known from above, if all SpanIds in a call can be collected to compose a complete link tree.\nWe assume that the TraceId generated in a distributed call is 0a1234 (much longer in practice). Then, according to the generation process of SpanId, the call link tree is as shown in the following figure:\n Currently, SpanId\u0026amp;rsquo;s generated rules refer to Taobao\u0026amp;rsquo;s Hawkeye components.\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/traceid-generated-rule/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"8f0ef8df65deec2a4fa6591a316aa5e8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","summary":"TraceId generation rule SOFATracer uses TraceId to concatenate the call logs of a request on each server. The TraceId is typically generated by the first server that receives the request. The generation rule is: server IP + generated time + incremental sequence + current process ID, such as:\n0ad1348f1403169275002100356696 The first 8 digits 0ad1348f is the IP of the machine that generates TraceId. This is a hexadecimal number, in which every two digits represents a part of IP.","tags":null,"title":"TraceId and spanId generation rule","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","wordcount":415},{"author":null,"categories":null,"content":" TraceId 生成规则 SOFATracer 通过 TraceId 来将一个请求在各个服务器上的调用日志串联起来，TraceId 一般由接收请求经过的第一个服务器产生，产生规则是： 服务器 IP + 产生 ID 时候的时间 + 自增序列 + 当前进程号 ，比如：\n0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，大家也可以根据这个规律来查找到请求经过的第一个服务器。 后面的 13 位 1403169275002 是产生 TraceId 的时间。 之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。 最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。\n TraceId 目前的生成的规则参考了阿里的鹰眼组件。\n SpanId 生成规则 SOFATracer 中的 SpanId 代表本次调用在整个调用链路树中的位置，假设一个 Web 系统 A 接收了一次用户请求，那么在这个系统的 SOFATracer MVC 日志中，记录下的 SpanId 是 0，代表是整个调用的根节点，如果 A 系统处理这次请求，需要通过 RPC 依次调用 B，C，D 三个系统，那么在 A 系统的 SOFATracer RPC 客户端日志中，SpanId 分别是 0.1，0.2 和 0.3，在 B，C，D 三个系统的 SOFATracer RPC 服务端日志中，SpanId 也分别是 0.1，0.2 和 0.3；如果 C 系统在处理请求的时候又调用了 E，F 两个系统，那么 C 系统中对应的 SOFATracer RPC 客户端日志是 0.2.1 和 0.2.2，E，F 两个系统对应的 SOFATracer RPC 服务端日志也是 0.2.1 和 0.2.2。根据上面的描述，我们可以知道，如果把一次调用中所有的 SpanId 收集起来，可以组成一棵完整的链路树。\n我们假设一次分布式调用中产生的 TraceId 是 0a1234（实际不会这么短），那么根据上文 SpanId 的产生过程，有下图：\n SpanId 目前的生成的规则参考了阿里的鹰眼组件。\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/traceid-generated-rule/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8f0ef8df65deec2a4fa6591a316aa5e8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","summary":"TraceId 生成规则 SOFATracer 通过 TraceId 来将一个请求在各个服务器上的调用日志串联起来，TraceId 一般由接收请求经过的第一个服务器产生，产生规则是： 服务器 IP + 产","tags":null,"title":"TraceId 和 SpanId 生成规则","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","wordcount":707},{"author":null,"categories":null,"content":"By default, SOFARPC has integrated SOFATracer. Also, you can use other APM products, such as Skywalking, to achieve the corresponding functions. For details, see the relevant documents:\n SOFATracer Skywalking If you want to disable the tracing ability of SOFARPC, you can do it in two ways.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment, you can add a configuration com.alipay.sofa.rpc.defaultTracer= in application.properties.\nIf you are using sofa-rpc-all directly, you can add the following code in the main method of your application before publish any SOFARPC service or create any SOFARPC reference.\nRpcConfigs.putValue(RpcOptions.DEFAULT_TRACER, \u0026amp;quot;\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/tracing-usage/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"5f944f87d827ae060fb0528f6715af97","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","summary":"By default, SOFARPC has integrated SOFATracer. Also, you can use other APM products, such as Skywalking, to achieve the corresponding functions. For details, see the relevant documents:\n SOFATracer Skywalking If you want to disable the tracing ability of SOFARPC, you can do it in two ways.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment, you can add a configuration com.alipay.sofa.rpc.defaultTracer= in application.properties.\nIf you are using sofa-rpc-all directly, you can add the following code in the main method of your application before publish any SOFARPC service or create any SOFARPC reference.","tags":null,"title":"Tracing","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","wordcount":96},{"author":null,"categories":null,"content":" Use client API In the design of SOFALookout client, API is decoupled from the implementation. If you need to log the events based on the SOFALookout API, you only need to add the lookout-api Maven dependency to the pom.xml file in your application/project. If the dependencies (such as client dependencies or SOFABoot (Spring Boot) Starter) do not exist, the API package uses NoopRegistry automatically, to replace all the locations of which the events are logged.\n1.Introduce API dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.About ID Compared to the traditional metrics library\u0026amp;rsquo;s single-dimensional information description, Lookout metrics provides tag capability that supports multi-dimensional descriptions. ID class, the unique identification of Lookout metrics, consists of name and tags.\nId basicId = registry.createId(\u0026amp;quot;rpc.provider.service.stats\u0026amp;quot;); id = basicId.withTag(\u0026amp;quot;service\u0026amp;quot;, \u0026amp;quot;com.alipay.demo.demoService\u0026amp;quot;) .withTag(\u0026amp;quot;method\u0026amp;quot;, \u0026amp;quot;sayHi\u0026amp;quot;) .withTag(\u0026amp;quot;protocol\u0026amp;quot;, \u0026amp;quot;tr\u0026amp;quot;) .withTag(\u0026amp;quot;alias\u0026amp;quot;, \u0026amp;quot;group1\u0026amp;quot;); The above is a simple example of ID introducing how to create ID and how to tag. Note that every time you tag, a new ID object is generated and returned.\n Do not proactively cache Id or the specific Metric object, since Lookout\u0026amp;rsquo;s Registry has already recorded. When using a same Id (with the same name and tags), the existing Id and its corresponding Metric object will be reused.\n 2.1 Priority tag (optional) PRIORITY enumeration level: HIGH, NORMAL, LOW.\nid.withTag(LookoutConstants.LOW_PRIORITY_TAG); It is recommended that you do not add this tag, the default level will be NORMAL. The level represents the collection interval (HIGH: 2s, NORMAL: 30s, LOW: 1min).\n2.2 About tags General tags, such as local IP, data center, and other details, will be attached and no need to be specified separately. In a non-SOFABoot project, you must manually add tags to the client, especially the app tag which specifies the app name: app=appName. key contains only lowercase letters, numbers, and underscores. (especially the metrics at runtime, such as Counter, Timer, and DistributeSummary) The values ​​of a tag shall be within a stable finite set. Try to use as few tags as possible to prevent the number of metrics from exceeding the maximum limit. For example: In RPC service, the value of method\u0026amp;rsquo;s two tags shall be as few as possible. The counterexample is that each RPC call has a separate tag-value. Therefore, the overall principle is that there should be as few custom tags as possible, and the number of sets of the values ​​should be as small as possible. Specialized TAG name \u0026amp;ldquo;priority\u0026amp;rdquo; indicates priority. The tag key reserved by the system is _*_. Starting with an underscore and ending with an …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-api/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"76574f2435a3565fe1fc50831ff9ab0c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","summary":"Use client API In the design of SOFALookout client, API is decoupled from the implementation. If you need to log the events based on the SOFALookout API, you only need to add the lookout-api Maven dependency to the pom.xml file in your application/project. If the dependencies (such as client dependencies or SOFABoot (Spring Boot) Starter) do not exist, the API package uses NoopRegistry automatically, to replace all the locations of which the events are logged.","tags":null,"title":"Use API","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","wordcount":911},{"author":null,"categories":null,"content":" SOFARPC Service publishing The process of service publishing involves three classes RegistryConfig, ServerConfig, ProviderConfig.\n RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;) RegistryConfig represents the registry center. As above, the address and port of the service registry center is 127.0.0.1:2181, and the protocol is Zookeeper.\n ServerConfig java ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ServerConfig represents the container where service runs. The above declares a server using the 8803 port and the bolt protocol.\n ProviderConfig\nProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt;() .setInterfaceId(HelloWorldService.class.getName()) .setRef(new HelloWorldServiceImpl()) .setServer(serverConfig) .setRegistry(registryConfig); providerConfig.export(); ProviderConfig represents service publishing. The above declares the interface of the service, implements the server running the service, and eventually publishes the service by the export method.\nService reference Service reference involves two classes, namely RegistryConfig and ConsumerConfig.\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig); HelloService helloService = consumerConfig.refer(); ConsumerConfig represents service reference. The above declares the interface and service registry center of the referenced service interface, and finally references the service by the refer method to get the proxy for the remote call of the service.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-rpc/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"ee6f74a4974c7abf72322cef108d5ef0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","summary":"SOFARPC Service publishing The process of service publishing involves three classes RegistryConfig, ServerConfig, ProviderConfig.\n RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026quot;zookeeper\u0026quot;) .setAddress(\u0026quot;127.0.0.1:2181\u0026quot;) RegistryConfig represents the registry center. As above, the address and port of the service registry center is 127.0.0.1:2181, and the protocol is Zookeeper.\n ServerConfig java ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026quot;bolt\u0026quot;); ServerConfig represents the container where service runs. The above declares a server using the 8803 port and the bolt protocol.","tags":null,"title":"Use API in non-Spring environment","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","wordcount":173},{"author":null,"categories":null,"content":" This article describes how to quickly start installing and configuring Istio by using Docker Compose.\nSOFAMosn can not only support the standard Istio deployment mode, but also support the unilateral Inbound Sidecar or Outbound Sidecar deployment mode to meet the various requirements of users.\nPrerequisites Docker Docker Compose Install Istio Download the latest release package. Unzip the installation file and go to the decompressed path. The installation path contains: Sample application path samples/. The istioctl client executable file which is in the /bin path. The istioctl can be used to create routing rules and policies. Configuration file istion.VERSION. Add the Istio\u0026amp;rsquo;s bin path to your system\u0026amp;rsquo;s PATH. For example, execute the following command in the MacOS or Linux operating system:\nexport PATH=$PWD/bin;$PATH Pull up the Istio control plane container: SHELL docker-compose -f install/zookeeper/istio.yaml up -d Ensure that all Docker containers are running:\ndocker ps -a If the Istio pilot container terminates unexpectedly, you can run the istioctl context-create command and re-execute the previous command. 6. Configure istioctl to use the Istio API server:\nistioctl context-create -context istio-local --api-server Deploy application Now, you can start deploying the SOFABoot demo program. The demo program includes a client and a server, which communicate with each other through Bolt protocol.\ndocker-compose up -f sofa-sample-spec.yaml up -d Uninstall Istio docker-compose up -f install/zookeeper/istio.yaml down ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"1de4868fa0e9c73d932343847864d7fb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","summary":"This article describes how to quickly start installing and configuring Istio by using Docker Compose.\nSOFAMosn can not only support the standard Istio deployment mode, but also support the unilateral Inbound Sidecar or Outbound Sidecar deployment mode to meet the various requirements of users.\nPrerequisites Docker Docker Compose Install Istio Download the latest release package. Unzip the installation file and go to the decompressed path. The installation path contains: Sample application path samples/.","tags":null,"title":"Use Docker to get started with Istio","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","wordcount":219},{"author":null,"categories":null,"content":" Introduction This section is intended to demonstrate how to use Jarslink 2.0 to dynamically control the life cycle of the Biz package and to complete its installation, uninstallation, and query.\nDemo With reference to How to reform common Spring Boot applications, the reformed spring-boot-transform-sample project has integrated the Jarslink 2.0 component. By executing the Ark package that the application packaged and generated, you can dynamically install or uninstall the application during its running.\n java -jar starts the spring-boot-transform-sample application Ark package. telnet localhost 1234 enters the Jarslink 2.0 command interface, as follows:\n\u0026amp;gt; telnet localhost 1234 s \u0026amp;gt; Trying 127.0.0.1\u0026amp;hellip;\n\u0026amp;gt; Connected to localhost.\n\u0026amp;gt; Escape character is \u0026amp;lsquo;^]\u0026amp;rsquo;.\n\u0026amp;gt; sofa-ark\u0026amp;gt; Execute the check -b query command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=1\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt; With reference to How to reform a common Spring Boot application, create any SOFABoot application of non-Web type, package it into a Biz package, and execute the install -b installation command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;install -b file:///Users/qilong.zql/Desktop/test-ark-biz.jar\n\u0026amp;gt; Biz:\u0026amp;lsquo;test-biz:1.0.0\u0026amp;rsquo; is installing. \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the check -b query command again, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=2\n\u0026amp;gt; bizName=\u0026amp;lsquo;test-biz\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo;\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the uninstall -b -n -v uninstallation command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;uninstall -b -n test-biz -v 1.0.0\n\u0026amp;gt; Uninstall biz:\u0026amp;lsquo;test-biz:1.0.0\u0026amp;rsquo; success. \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the check -b query command again, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=1\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n For use of more commands, refer to Interactive Commands.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"749f6debe73b73b4882477779008bb99","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","summary":"Introduction This section is intended to demonstrate how to use Jarslink 2.0 to dynamically control the life cycle of the Biz package and to complete its installation, uninstallation, and query.\nDemo With reference to How to reform common Spring Boot applications, the reformed spring-boot-transform-sample project has integrated the Jarslink 2.0 component. By executing the Ark package that the application packaged and generated, you can dynamically install or uninstall the application during its running.","tags":null,"title":"Use Jarslink for multi-application dynamic deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","wordcount":277},{"author":null,"categories":null,"content":" This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio. Serving as a critical component of SOFAMesh, MOSN is used to complete data plane forwarding.\nThe following figure shows the workflow chart of MOSN based on the overall SOFAMesh framework.\nNote: Currently, MOSN cannot be directly used in the native Istio.\nPreparations This guide supposes you are using macOS. For other operating systems, you can install the corresponding software.\n1. Install HyperKit Install docker-for-mac, and then install driver.\n1.1 Install Docker Download the Docker software package to install it or run the following command to install it:\n$ brew cask install docker 1.2 Install driver $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. Install Minikube (or purchase the commercial version of k8s cluster) It is recommended to use Minikube V0.28 or later, see https://github.com/kubernetes/minikube.\n$ brew cask install minikube 3. Start Minikube Note that Pilot requires at least 2G memory, so you can add resources to Minikube by adding parameters at startup. If your machine has insufficient resources, it is recommended to use the commercial version of the k8s cluster.\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit Create Istio namespace\n$ kubectl create namespace istio-system 4. Install kubectl command line tool kubectl is a command line interface used to run commands for k8s cluster. For how to install it, see https://kubernetes.io/docs/tasks/tools/install-kubectl.\n$ brew install kubernetes-cli 5. Install Helm Helm is a package management tool for k8s. For how to install it, see https://docs.helm.sh/using_helm/#installing-helm.\n$ brew install kubernetes-helm Deploy SOFAMesh with source codes 1. Download SOFAMesh source codes $ git clone git@github.com:sofastack/sofa-mesh.git 2. Use Helm to install SOFAMesh You should change directory to sofa-mesh source code, and then use helm template to install isito crd and istio\n``` $ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template …","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-with-sofamesh/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"9c6461e92180417d3a8ec4f3f2c723fe","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","summary":"This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio.","tags":null,"title":"Use MOSN to build Service Mesh platform","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","wordcount":1078},{"author":null,"categories":null,"content":" This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio. Serving as a critical component of SOFAMesh, MOSN is used to complete data plane forwarding.\nThe following figure shows the workflow chart of MOSN based on the overall SOFAMesh framework.\nNote: Currently, MOSN cannot be directly used in the native Istio.\nPreparations This guide supposes you are using macOS. For other operating systems, you can install the corresponding software.\n1. Install HyperKit Install docker-for-mac, and then install driver.\n1.1 Install Docker Download the Docker software package to install it or run the following command to install it:\n$ brew cask install docker 1.2 Install driver $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. Install Minikube (or purchase the commercial version of k8s cluster) It is recommended to use Minikube V0.28 or later, see https://github.com/kubernetes/minikube.\n$ brew cask install minikube 3. Start Minikube Note that Pilot requires at least 2G memory, so you can add resources to Minikube by adding parameters at startup. If your machine has insufficient resources, it is recommended to use the commercial version of the k8s cluster.\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit Create Istio namespace\n$ kubectl create namespace istio-system 4. Install kubectl command line tool kubectl is a command line interface used to run commands for k8s cluster. For how to install it, see https://kubernetes.io/docs/tasks/tools/install-kubectl.\n$ brew install kubernetes-cli 5. Install Helm Helm is a package management tool for k8s. For how to install it, see https://docs.helm.sh/using_helm/#installing-helm.\n$ brew install kubernetes-helm Deploy SOFAMesh with source codes 1. Download SOFAMesh source codes $ git clone git@github.com:sofastack/sofa-mesh.git 2. Use Helm to install SOFAMesh You should change directory to sofa-mesh source code, and then use helm template to install isito crd and istio\n``` $ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template …","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-run-with-sofamesh/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"7353dfd1d668eb3e2a1c8cd26acca372","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","summary":"This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio.","tags":null,"title":"Use MOSN to build Service Mesh platform","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","wordcount":1078},{"author":null,"categories":null,"content":" Use Registry Different Registry integrations provide different ways to access Metrics.\n1. LookoutRegistry Provides the ability to count metrics by a time window. It is divided into two modes: “active” and “passive”. The passive mode is off currently.\n(1) Active mode\n You can specify the IP address of the remote agent through [Client Configuration], that is, check when start reporting, and regularly report data.\n(2) Passive mode\n This mode can be activated through [Client Configuration], and HTTP service is provided on port 19399.\n2. Connect to Prometheus The data of SOFALookout can be shared with Prometheus. In order to connect to Prometheus, you first need to add dependencies to your project:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-reg-prometheus\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; After adding the dependencies, launch the application, and you can see the data by visiting http://localhost:9494, where 9494 is the default port, you can configure com.alipay.sofa.lookout.prometheus-exporter-server-port in application.properties to change the port.\nOnce you have the URL to access the data, you can edit a prometheus.yml to grab the project information. Assuming that the local IP address is 10.15.232.20, you can configure prometheus.yml as follows:\nscrape_configs: - job_name: \u0026#39;lookout-client\u0026#39; scrape_interval: 5s static_configs: - targets: [\u0026#39;10.15.232.20:9494\u0026#39;] With the above configuration file, you can start Prometheus locally via Docker:\ndocker run -d -p 9090:9090 -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml --name prom prom/prometheus:master Then visit http://localhost:9090 through the browser, and you can query the corresponding Metrics through PromQL.\nAn example of connecting to Prometheus is also available in SOFALookout, so you can go and see it as a reference.\n3. Connect to SpringBoot actuator In addition to Prometheus, SOFALookout can be integrated with the Actuator of SpringBoot 1.x by adding the following dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Then, start and visit http://localhost:8080/metrics to see the data of events logged by the SOFALookout API.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-registry/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"3c51ba6519cee542b459a170dabcf32b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","summary":"Use Registry Different Registry integrations provide different ways to access Metrics.\n1. LookoutRegistry Provides the ability to count metrics by a time window. It is divided into two modes: “active” and “passive”. The passive mode is off currently.\n(1) Active mode\n You can specify the IP address of the remote agent through [Client Configuration], that is, check when start reporting, and regularly report data.\n(2) Passive mode\n This mode can be activated through [Client Configuration], and HTTP service is provided on port 19399.","tags":null,"title":"Use Registry","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","wordcount":297},{"author":null,"categories":null,"content":" XML mode Declare the xsd file of SOFABoot: In the XML configuration file to be used, configure the declaration of the header xsd file to the followings. This enables development using the XML elements defined by SOFABoot.\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www .w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xmlns:context=\u0026amp;quot;http://www.springframework.org/schema/context\u0026amp;quot; xsi:schemaLocation =\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack .io/schema/sofaboot.xsd\u0026amp;quot; The way to publish and reference services in xml mode is as follows. sofa:service represents publishing service, and sofa:reference represents referencing service. sofa:binding indicates the protocol for service publishing or reference.\n\u0026amp;lt;bean id=\u0026amp;quot;personServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; A service can also be published through multiple protocols, as follows:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Service reference\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; A service can also be referenced through other protocols:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceRest\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-xml/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"9192a93415bee3070a9be62c0f693949","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","summary":"XML mode Declare the xsd file of SOFABoot: In the XML configuration file to be used, configure the declaration of the header xsd file to the followings. This enables development using the XML elements defined by SOFABoot.\n\u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;beans xmlns=\u0026quot;http://www.springframework.org/schema/beans\u0026quot; xmlns:xsi=\u0026quot;http://www .w3.org/2001/XMLSchema-instance\u0026quot; xmlns:sofa=\u0026quot;http://sofastack.io/schema/sofaboot\u0026quot; xmlns:context=\u0026quot;http://www.springframework.org/schema/context\u0026quot; xsi:schemaLocation =\u0026quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack .io/schema/sofaboot.xsd\u0026quot; The way to publish and reference services in xml mode is as follows. sofa:service represents publishing service, and sofa:reference represents referencing service.","tags":null,"title":"Use XML in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","wordcount":130},{"author":null,"categories":null,"content":" Use annotation for service publishing/reference In addition to the regular xml mode, it is also supported to publish and reference services with annotation in the SOFABoot environment. Similar to xml, we provide @SofaService and @SofaReference as well as @SofaServiceBinding and @SofaReferenceBinding annotation for multi-protocol.\nService publishing To publish an RPC service, you only need to add a @SofaService annotation on the bean to specify the interface and protocol type.\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } Service reference For a bean that needs to reference a remote service, you only need to add the @SofaReference annotation on the attribute or method. This supports the bolt, dubbo, rest protocol.\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } Use the demo You can test in the annotation subproject of the sample project.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-annotation/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2c3afd33cbce4f5aa2473716b3afe5a6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","summary":"Use annotation for service publishing/reference In addition to the regular xml mode, it is also supported to publish and reference services with annotation in the SOFABoot environment. Similar to xml, we provide @SofaService and @SofaReference as well as @SofaServiceBinding and @SofaReferenceBinding annotation for multi-protocol.\nService publishing To publish an RPC service, you only need to add a @SofaService annotation on the bean to specify the interface and protocol type.","tags":null,"title":"Use annotation in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","wordcount":182},{"author":null,"categories":null,"content":" This topic mainly describes a JRaft-based distributed counter.\nScenario Save a distributed counter in a raft group of multiple nodes (servers). The counter can increment and be called while remaining consistent among all nodes. The counter can normally provide two external services when a minority of nodes fail:\n incrmentAndGet(delta): increments the value of delta and returns the incremented value. get(): gets the latest value. Remote procedure calls (RPCs) JRaft adopts the Bolt communication framework at the underlayer, and defines two requests:\n IncrementAndGetRequest: used for incrementing the value public class IncrementAndGetRequest implements Serializable { private static final long serialVersionUID = -5623664785560971849L; private long delta; public long getDelta() { return this.delta; } public void setDelta(long delta) { this.delta = delta; } } GetValueRequest: used for getting the latest value public class GetValueRequest implements Serializable { private static final long serialVersionUID = 9218253805003988802L; public GetValueRequest() { super(); } } ValueResponse responses include:\n success: indicates that the request was successful value: the latest value returned by a successful request errorMsg: the error message of a failed request redirect: indicates that a leader election occurred and the request needs to be sent to the new leader node public class ValueResponse implements Serializable { private static final long serialVersionUID = -4220017686727146773L; private long value; private boolean success; /** * redirect peer id */ private String redirect; private String errorMsg; public String getErrorMsg() { return this.errorMsg; } public void setErrorMsg(String errorMsg) { this.errorMsg = errorMsg; } ...... } IncrementAndAddClosure: used for receiving requests at the leader node IncrementAndGetRequest: used for handling callbacks of the request public class IncrementAndAddClosure implements Closure { private CounterServer counterServer; private IncrementAndGetRequest request; private ValueResponse response; private Closure done; // The network response callback public IncrementAndAddClosure(CounterServer counterServer, IncrementAndGetRequest request, ValueResponse response, Closure done) { super(); this.counterServer = counterServer; this.request = request; this.response = response; this.done = done; } @Override public void run(Status status) { // Return the response to the client if (this.done != null) { done.run(status); } } public IncrementAndGetRequest getRequest() { return this.request; } public void setRequest(IncrementAndGetRequest request) { this.request = request; } public ValueResponse getResponse() { return this.response; } } Server CounterStateMachine First hold an initial value:\npublic class CounterStateMachine extends StateMachineAdapter { /** * counter value */ private AtomicLong value = new AtomicLong(0); Implement the core onApply(iterator) method, and apply the user request to the state machine: …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/counter-example/","fuzzywordcount":1900,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"f9c54b9f7883ccb1d7c259b7101f4674","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/counter-example/","publishdate":"0001-01-01T00:00:00Z","readingtime":9,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/counter-example/","summary":"This topic mainly describes a JRaft-based distributed counter.\nScenario Save a distributed counter in a raft group of multiple nodes (servers). The counter can increment and be called while remaining consistent among all nodes. The counter can normally provide two external services when a minority of nodes fail:\n incrmentAndGet(delta): increments the value of delta and returns the incremented value. get(): gets the latest value. Remote procedure calls (RPCs) JRaft adopts the Bolt communication framework at the underlayer, and defines two requests:","tags":null,"title":"Use case of a counter","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/counter-example/","wordcount":1859},{"author":null,"categories":null,"content":" SOFABoot provides a class isolation framework SOFAArk, giving Spring Boot a class isolation ability to resolve class or package conflicts in the development. For detailed information, please refer to:SOFAArk\nTo use this feature in SOFABoot projects, we need only two steps: configure the sofa-ark-maven-plugin plugins for packaging and add sofa-ark-springboot-starter dependencies of the class isolation framework.\nConfigure Maven packaging plugins The Maven plugins - sofa-ark-maven-plugin are available on the Central Repository. Through simple configurations, a SpringBoot project can be wrapped into an executable Ark package in the standard format. The coordinate of sofa-ark-maven-plugin is:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; The configuration template is described as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- all class exported by ark plugin would be resolved by ark biz in default, if configure denyImportClasses, then it would prefer to load them by ark biz itself --\u0026amp;gt; \u0026amp;lt;denyImportClasses\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass1\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass2\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/denyImportClasses\u0026amp;gt; \u0026amp;lt;!-- Corresponding to denyImportClasses, denyImportPackages is package-level --\u0026amp;gt; \u0026amp;lt;denyImportPackages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/denyImportPackages\u0026amp;gt; \u0026amp;lt;!-- denyImportResources can prevent resource exported by ark plugin with accurate name to be resolved --\u0026amp;gt; \u0026amp;lt;denyImportResources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test1.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test2.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;/denyImportResources\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Description of plugin configuration:\n outputDirectory: Execute mvn package and then specify a directory to store the Ark package. The default directory is ${project. Build. Directory}. arkClassifier: Execute mvn docleoy, and then specify the coordinates of Maven repositories to locate the Ark package by setting the classfaulter value (the default is empty). We recommend that you configure this to give a different name from the ordinary Fat jar; denyImportClasses: By default, the application will first load …","date":-62135596800,"description":"","dir":"projects/sofa-boot/classloader-isolation/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"e007416ab008c1dd4b886433dbf8af01","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","summary":"SOFABoot provides a class isolation framework SOFAArk, giving Spring Boot a class isolation ability to resolve class or package conflicts in the development. For detailed information, please refer to:SOFAArk\nTo use this feature in SOFABoot projects, we need only two steps: configure the sofa-ark-maven-plugin plugins for packaging and add sofa-ark-springboot-starter dependencies of the class isolation framework.\nConfigure Maven packaging plugins The Maven plugins - sofa-ark-maven-plugin are available on the Central Repository.","tags":null,"title":"Use class isolation in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","wordcount":1129},{"author":null,"categories":null,"content":" Use API SOFABoot provides a set of programming APIs for RPC service publishing and reference. It is convenient to publish and reference RPC services directly in the code. Similar to Spring\u0026amp;rsquo;s ApplicationContextAware, in order to use the programming API, you first need to implement the ClientFactoryAware interface to get the programming component API:\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } With DirectService as an example, see how to use the clientFactory to publish an RPC service through the programming API:\nServiceClient serviceClient = clientFactory.getClient(ServiceClient.class); ServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(DirectService.class); serviceParam.setInstance(new DirectServiceImpl()); List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); serviceClient.service (serviceParam); In the code above:\n First, get the ServiceClient object through the clientFactory. Then, construct the ServiceParam object, which contains the parameters required to publish the service, and use the setInstance method to set the object to be published as an RPC service, setInterfaceType to set the interface of the service. Finally, call the service method of ServiceClient to publish an RPC service. The code that references the RPC service through the programming API is similar:\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt;(); referenceParam.setInterfaceType(DirectService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); DirectService proxy = referenceClient.reference(referenceParam); proxy.sayDirect(\u0026amp;quot;hello\u0026amp;quot;); Likewise, to reference an RPC service, the code simply needs to get a ReferenceClient from the ClientFactory and then construct a ReferenceParam similar to publishing a service, next set up the service interface, and finally call the ReferenceClient\u0026amp;rsquo;s reference method.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-api/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2679388dc3459714f869d8f8a71739d7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","summary":"Use API SOFABoot provides a set of programming APIs for RPC service publishing and reference. It is convenient to publish and reference RPC services directly in the code. Similar to Spring\u0026rsquo;s ApplicationContextAware, in order to use the programming API, you first need to implement the ClientFactoryAware interface to get the programming component API:\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } With DirectService as an example, see how to use the clientFactory to publish an RPC service through the programming API:","tags":null,"title":"Use dynamic API in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","wordcount":255},{"author":null,"categories":null,"content":" User guide Maven coordinator \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Check release notes for the version information.\n 1. Basic functions 1.1. Implement user request processor (UserProcessor) We provide two types of user request processors: SyncUserProcessor and AsyncUserProcessor. The difference between them is that the former returns the processing result in the form of a return value in the current processor thread, while the latter has an AsyncContext stub and can call the sendResponsemethod in the current thread or an asynchronous thread to return the processing result. For examples, refer to the following two types:\n Synchronous request processor Asynchronous request processor 1.2 Implement connection event processor (ConnectionEventProcessor) We provide two connection event processors: ConnectionEventType.CONNECT and ConnectionEventType.CLOSE. You can create your own event processors and register them with the client or the server. The client side and server side can each monitor both of their connection and disconnection events.\n Process connection event Process disconnection event 1.3 Client side and server side initialization (RpcClient, RpcServer) We have provided an RpcClient and RpcServer. They can be used after going through a simple initialization of necessary functions, or after switching on the functions. The most simple example is as follows:\n Client side initialization example Server side initialization example 1.4 Basic communication model We have provided four types of communication models:\n1. Oneway calls\nThe current thread initiates a call that is not interested in the call result and is not subject to timeout control. As long as the request is sent out, the call is completed. Note: Oneway calls are not guaranteed to succeed, and the initiator of the call has no way of knowing its result. For that reason, these calls are usually used in scenarios that can be retried or that have fixed-time notifications. Network problems or machine malfunctions during the call process may result in failure. This kind of call should only be used in business scenarios that accept such exceptions. For more information, see Example.\n2. Sync calls\nThe current thread initiates a call that only completes if it receives a result within the set timeout time. If a result is not received within the timeout time, it will generate a timeout error. This is the most commonly used call type. Ensure that the timeout time is set reasonably in accordance with the opposing terminal\u0026amp;rsquo;s processing capacity. For more information, see Example.\n3. Future calls\nThe current thread initiates a call and can then move onto executing the next call after getting an RpcResponseFuture object. The get() method of the RpcResponseFuture object can be used at any time to get the result. If the response has already been returned, the result …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-handbook/","fuzzywordcount":2000,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"2a0a2e3c7749dbcdceea064f6f850e33","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","publishdate":"0001-01-01T00:00:00Z","readingtime":10,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","summary":"User guide Maven coordinator \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Check release notes for the version information.\n 1. Basic functions 1.1. Implement user request processor (UserProcessor) We provide two types of user request processors: SyncUserProcessor and AsyncUserProcessor. The difference between them is that the former returns the processing result in the form of a return value in the current processor thread, while the latter has an AsyncContext stub and can call the sendResponsemethod in the current thread or an asynchronous thread to return the processing result.","tags":null,"title":"User guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","wordcount":1988},{"author":null,"categories":null,"content":" ## Version release\nVersion No. Major, minor, and revision version numbers are used. For example 2.0.0.\nRefer to: http://semver.org/lang/zh-CN/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Revision version number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance At most two versions can be maintained simultaneously.\nFor example, if the current major version is 2.2.0, the BugFix version 2.1.x will be maintained and bugs in version 2.0.x will no longer be fixed and a version upgrade is recommended.\nRelease process Daily development uses the SNAPSHOT version, such as 2.0.0-SNAPSHOT. When the modified version is officially released, the version number is revised to a formal version, such as 2.0.0. After release, the next version is pulled up, for example, 2.1.0-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-version/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b82f2d74eff3937e10f15b13cb503751","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","summary":"## Version release\nVersion No. Major, minor, and revision version numbers are used. For example 2.0.0.\nRefer to: http://semver.org/lang/zh-CN/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Revision version number: represents the BugFix version.","tags":null,"title":"Version release","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","wordcount":175},{"author":null,"categories":null,"content":" Version number The system adopts a three-digit versioning scheme. The three digits respectively are major version number, minor version number, and revision number, for example: 5.1.2.\nFor more information, see the http://semver.org/lang/zh-CN/.\n Major version number: All versions in the major version number must be compatible with each other. It is not necessary to be fully compatible with other major version numbers, but it is best to have backward compatibility. Minor version number: Represents new feature enhancements. The larger the version number, the richer the feature. Revision number: Represents the BugFix version. The revision number is only for bug fixes. The larger the version number, the more stable it is. Version maintenance You can maintain up to two versions at the same time.\nFor example, the current trunk is 5.3.0, then the bugfix branch of 5.2.x will be maintained. When any bugs arise in 5.1.x, users are prompted to upgrade the system.\nRelease process The daily development branch uses the SNAPSHOT version, for example: 5.3.0-SNAPSHOT. When it comes to official release, you can modify the version to official version, for example: 5.3.0. Pull up the next version after release, for example: 5.3.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/version-release/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"604f113607e6815757f4d1907190c13c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/version-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/version-release/","summary":"Version number The system adopts a three-digit versioning scheme. The three digits respectively are major version number, minor version number, and revision number, for example: 5.1.2.\nFor more information, see the http://semver.org/lang/zh-CN/.\n Major version number: All versions in the major version number must be compatible with each other. It is not necessary to be fully compatible with other major version numbers, but it is best to have backward compatibility.","tags":null,"title":"Version release","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/version-release/","wordcount":191},{"author":null,"categories":null,"content":" Version number Major, minor, and revision version numbers are used. For example, 1.0.0.\nFor more information, see https://semver.org/\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has. Revision version number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance Up to two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 1.2.0, the BugFix branch 1.1.x will be maintained, but bugs in branch 1.0.x will no longer be fixed. In this case, a version upgrade is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 1.0.0-SNAPSHOT. Upon formal release, the snapshot version is modified to the formal version, for example 1.0.0. After the formal release, the next version is pulled, for example, 1.0.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/version-rule/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a2093bdf478bdff0e15a2de70e522d03","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/version-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/version-rule/","summary":"Version number Major, minor, and revision version numbers are used. For example, 1.0.0.\nFor more information, see https://semver.org/\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has.","tags":null,"title":"Version rules","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/version-rule/","wordcount":180},{"author":null,"categories":null,"content":" Version number SOFARegistry uses a three-digit version number in the form of major, minor, and patch. For example, 5.2.0.\nFor more information, see https://semver.org/.\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has. Patch number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance Up to two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 5.4.0, the BugFix branch of version 5.3.x will be maintained, but bugs in branch 5.2.x will no longer be fixed. Therefore, a version upgrade for 5.2.x is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 5.3.0-SNAPSHOT. Upon formal release, SNAPSHOT is replaced with a formal version number, for example 5.3.0. After the formal release, the next version is pulled, for example, 5.3.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-standard/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"71aad9cbc42aba3d9f875ae9169cf005","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/release-standard/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/release-standard/","summary":"Version number SOFARegistry uses a three-digit version number in the form of major, minor, and patch. For example, 5.2.0.\nFor more information, see https://semver.org/.\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has.","tags":null,"title":"Version rules","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/release-standard/","wordcount":186},{"author":null,"categories":null,"content":" With SOFABoot, we can directly view the version of SOFA middleware and other detailed information in the browser.\nIntroducing SOFABoot Infra Dependency To view the version information of the SOFA middleware directly in the browser in SOFABoot, all you need to do is add the following to the Maven dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;infra-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Version Information Viewing After an application started successfully, you can visit http://localhost:8080/sofaboot/versions in the browser to view the version information of the SOFA middleware, the response such as:\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Build-Time: \u0026amp;quot;2018-04-05T20:55:22+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.0\u0026amp;quot; } ] ** Note: In SOFABoot 3.x, the endpoint path has been changed from sofaboot/versions to actuator/versions**.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/view-versions/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"c6b6d22e9038aa1f5e4ce74449ba1cda","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/view-versions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/view-versions/","summary":"With SOFABoot, we can directly view the version of SOFA middleware and other detailed information in the browser.\nIntroducing SOFABoot Infra Dependency To view the version information of the SOFA middleware directly in the browser in SOFABoot, all you need to do is add the following to the Maven dependency:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;infra-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Version Information Viewing After an application started successfully, you can visit http://localhost:8080/sofaboot/versions in the browser to view the version information of the SOFA middleware, the response such as:","tags":null,"title":"View version","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/view-versions/","wordcount":115},{"author":null,"categories":null,"content":"The warm-up weight feature allows the client machine to distribute traffic based on the corresponding weight of the server. This feature is also often used in the scenario where a few machines within a cluster are being started. The server machines can be warmed up in a short time with the traffic weight function, and then continue to receive the normal traffic.\nThe operating mechanism is as follows: When the server service starts, it pushes its own warm-up duration, weight during warm-up, and normal weight after warm-up to the Service Registry. As shown above, Service B points to Service Registry.\n When referencing service, the client obtains the warm-up weight information of each service instance. As shown above, Service Registry points to client.\n When calling service, the client distributes the traffic according to the warm-up weight of the address where the service is located. As shown above, the client points to Service A and Service B. Service A has completed warm-up, and its weight is 100 by default. Service B is in the warm-up period, and its weight is 10. Therefore, their traffic is 100%110 and 10%110 respectively.\n This feature is used as follows:\nProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt;() .setWeight(100) .setParameter(ProviderInfoAttrs.ATTR_WARMUP_WEIGHT,\u0026amp;quot;10\u0026amp;quot;) .setParameter(ProviderInfoAttrs.ATTR_WARM_UP_END_TIME, \u0026amp;quot;12000\u0026amp;quot;); As above, the warm-up duration of the service is 12s, the weight is 10 during warm-up, and the normal weight after warm-up is 100. If the service is published on two machines, such as machine A and B, and the machine A is in the warm-up period with the above configuration, while B has already completed warm-up, and the normal weight is 200, then when the client calls the service, the proportion of traffic distribution is 10:200. After the machine A is warmed up, the traffic distribution ratio is 100:200.\nIn SOFABoot, the warm-up duration and the weight during and after warm-up can be configured as follows:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleRestFacadeReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.endpoint.facade.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs weight=\u0026amp;quot;100\u0026amp;quot; warm-up-time=\u0026amp;quot;10000\u0026amp;quot; warm-up-weight=\u0026amp;quot;1000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/provider-warmup-weight/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"b9e320dfaa4f9700ecdca67d76e07d54","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","summary":"The warm-up weight feature allows the client machine to distribute traffic based on the corresponding weight of the server. This feature is also often used in the scenario where a few machines within a cluster are being started. The server machines can be warmed up in a short time with the traffic weight function, and then continue to receive the normal traffic.\nThe operating mechanism is as follows: When the server service starts, it pushes its own warm-up duration, weight during warm-up, and normal weight after warm-up to the Service Registry.","tags":null,"title":"Warm-up weight","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","wordcount":319},{"author":null,"categories":null,"content":" X-Protocol X-Protocol is a special common protocol supported by SOFAMesh. It can access different RPC protocols in a unified manner. Because it doesn\u0026amp;rsquo;t require to parse protocols, it can not only provide higher performance, but also reduce the development cost of accessing new protocols.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-x-protocol/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"220f4a76b277463bb1f7201519950450","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","summary":"X-Protocol X-Protocol is a special common protocol supported by SOFAMesh. It can access different RPC protocols in a unified manner. Because it doesn\u0026rsquo;t require to parse protocols, it can not only provide higher performance, but also reduce the development cost of accessing new protocols.","tags":null,"title":"X-Protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","wordcount":44},{"author":null,"categories":null,"content":"X-Protocol 协议是 SOFAMesh 支持的特殊通用协议，能够以统一的方式接入不同的 RPC 协议，因为无需进行协议解析，不仅能够提供更高的性能, 更能降低接入新协议的开发成本。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-x-protocol/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"220f4a76b277463bb1f7201519950450","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","summary":"X-Protocol 协议是 SOFAMesh 支持的特殊通用协议，能够以统一的方式接入不同的 RPC 协议，因为无需进行协议解析，不仅能够提供更高的性能, 更能降低接入新协议的开发成本。","tags":null,"title":"X-Protocol","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","wordcount":70},{"author":null,"categories":null,"content":" ZooKeeper Adapter ZooKeeper Adapter is an Adapter plug-in developed in accordance with the Istio registry center extension mechanism. It is used for docking all microservices frameworks that use ZooKeeper as a registry center. Currently, ZooKeeper Adapter supports SOFARPC and will be available for Dubbo soon.\nZooKeeper Adapter uses ZooKeeper\u0026amp;rsquo;s watch mechanism to listen to the change events of service registration information, providing better real-time performance than polling.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-zookeeper-adapter/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"a174a0de8dd47df7c3043f6d49fa1b07","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","summary":"ZooKeeper Adapter ZooKeeper Adapter is an Adapter plug-in developed in accordance with the Istio registry center extension mechanism. It is used for docking all microservices frameworks that use ZooKeeper as a registry center. Currently, ZooKeeper Adapter supports SOFARPC and will be available for Dubbo soon.\nZooKeeper Adapter uses ZooKeeper\u0026rsquo;s watch mechanism to listen to the change events of service registration information, providing better real-time performance than polling.","tags":null,"title":"ZooKeeper Adapter","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","wordcount":67},{"author":null,"categories":null,"content":" To use Zookeeper as service registry center, you only need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 Note: Considering the real-time nature of the service, the following features are not supported currently.\nSOFABoot RPC also provides a cache file (not supported currently), which is used for service discovery when ZooKeeper is not available. The way to configure this cache file is as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth When users need to auth the providers and consumers, they can use a auth key to write or read the dictionary normally, only when they use the same key, zookeeper server will process these requests.\nSOFARPC API Usage If you use SOFARPC API directly, you can add two parameters to registry config.\nparameters.put(\u0026amp;quot;scheme\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;); //if there was multi auth infos, you need to set the value as user1:passwd1,user2:passwd2 parameters.put(\u0026amp;quot;addAuth\u0026amp;quot;, \u0026amp;quot;sofazk:rpc1\u0026amp;quot;); registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181/authtest\u0026amp;quot;) .setParameters(parameters); then if another provider or consumer use a different auth info, they will not access these providers or consumers.\nXML Usage You only need to set it in application.properties\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry\u0026amp;amp;scheme=digest\u0026amp;amp;addAuth=sofazk:rpc1 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-zookeeper/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877533,"objectID":"71d6486c5577cc85d84c56688cdf2af1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","summary":"To use Zookeeper as service registry center, you only need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 Note: Considering the real-time nature of the service, the following features are not supported currently.\nSOFABoot RPC also provides a cache file (not supported currently), which is used for service discovery when ZooKeeper is not available. The way to configure this cache file is as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth When users need to auth the providers and consumers, they can use a auth key to write or read the dictionary normally, only when they use the same key, zookeeper server will process these requests.","tags":null,"title":"Zookeeper","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","wordcount":174},{"author":null,"categories":null,"content":"Zookeeper Adapter 是按照 Istio 注册中心扩展机制开发的一个 Adapter 插件，用于对接所有使用 Zookeeper 作为注册中心的微服务框架。目前已经支持了 SOFARPC，很快将提供对于 Dubbo 的支持。\nZookeeper Adapter 使用 zk 的 watch 机制监听服务注册信息的变化事件，提供了比轮询机制更好的实时性。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-zookeeper-adapter/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a174a0de8dd47df7c3043f6d49fa1b07","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","summary":"Zookeeper Adapter 是按照 Istio 注册中心扩展机制开发的一个 Adapter 插件，用于对接所有使用 Zookeeper 作为注册中心的微服务框架。目前已经支持了 SOFARPC，很快将提供对于 Dubbo 的支","tags":null,"title":"Zookeeper Adpater","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","wordcount":110},{"author":null,"categories":null,"content":" 在介绍 Biz 生命周期 时，我们提到了有三种方式控制 Biz 的生命周期，并且介绍了使用客户端 API 实现 Biz 的安装、卸载、激活。在这一章节我们介绍如何使用 SOFAArk 提供的动态配置插件，通过 Zookeeper 下发指令，控制 Biz 的生命周期。\n引入依赖 SOFAArk 提供了 config-ark-plugin 对接 Zookeeper 配置中心，用于运行时接受配置，达到控制 Biz 生命周期，引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;config-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置 ZK 地址 参考 SOFAArk 配置，在 SOFAArk 配置文件 conf/ark/bootstrap.properties 增加如下配置：\ncom.alipay.sofa.ark.config.address=zookeeper://ip:port 配置维度 SOFAArk 启动后，会在 ZK 注册两个节点配置，分别是宿主应用维度和 IP 维度：\n sofa-ark/${com.alipay.sofa.ark.master.biz}/ \u0026amp;gt; 宿主应用维度配置，应用启动时，会拉取该维度配置，控制相关 Biz 的部署；应用重启后，配置不会丢失\n sofa-ark/${com.alipay.sofa.ark.master.biz}/ip/ \u0026amp;gt; IP 维度配置，应用重启后丢失，通常用于运行时控制单台机器的 Biz 行为\n 通过写这两个节点的配置，可以控制相关机器和应用的 Biz 运行时状态。\n配置形式 下面介绍配置的形式，动态配置采用状态声明指令，SOFAArk 收到配置后，会根据状态描述解析出具体的指令（包括 install，uninstall, switch），指令格式如下：\nbizName:bizVersion:bizState?k1=v1\u0026amp;amp;k2=v2\n多条指令使用 ; 隔开，单条指令主要由 biz 名称，biz 版本，biz 预期状态及参数组成。简单记住一点，状态配置是描述指令推送之后，所有非宿主 Biz 的状态；\n例如当前 SOFAArk 容器部署了两个应用 A，B，版本均为 1.0，其中 A 应用为宿主应用，因为宿主应用不可卸载，因此不需要考虑宿主应用，可以简单认为当前容器的 Biz 状态声明为：\n B:1.0:Activated\n 如果此时你希望安装 C 应用，版本为 1.0，文件流地址为 urlC，那么推送指令应为：\n B:1.0:Activated;C:1.0:Activated?bizUrl=urlC\n 操作继续，如果你又希望安装安装 B 应用，版本为 2.0，文件流地址为 urlB，且希望 2.0 版本处于激活状态，那么你推送的指令应为：\n B:1.0:Deactivated;B:2.0:Actaivated?bizUrl=urlB;C:1.0:Activated\n解释下为什么是这样配置指令，因为 SOFAArk 只允许应用一个版本处于激活状态，如果存在其他版本，则应处于非激活状态；所以当希望激活 B 应用 2.0 版本时，B 应用 1.0 版本应该声明为非激活状态。另外你可能注意到了 C 应用参数 urlC 不用声明了，原因是目前只有当安装新 Biz 时，才有可能需要配置参数 bizUrl，用于指定 biz 文件流地址，其他场景下，参数的解析没有意义。\n 操作继续，如果你希望卸载 B 应用 2.0 版本，激活 B 应用 1.0 版本，卸载 C 应用，那么推送的指令声明为：\n B:1.0:Activated\n 从上面的操作描述看，在推送动态配置时，只需要声明期望的 Biz 状态即可，SOFAArk 会根据状态声明推断具体的执行指令，并尽可能保持服务的连续性，以上面最后一步操作为例，SOFAArk 推断的执行指令顺序如下： + 执行 switch 指令，激活 B 应用 1.0 版本，钝化 B 应用 2.0 版本，保证服务连续性 + 执行 uninstall 指令，卸载 B 应用 2.0 版本 + 执行 uninstall 指令，卸载 C 应用 1.0 版本\n注意事项 目前只有在安装新 Biz 时才可能使用指令参数 bizUrl，用于指定 Biz 文件流地址。文件流地址字符串是能够直接构建 URL 对象，例如 file://xxx 或者 http://xxx. 安装新 Biz 时，参数 bizUrl 不是必须的，SOFAArk 提供了扩展点：\n@Extensible public interface BizFileGenerator { File createBizFile(String bizName, String bizVersion); } 用于扩展实现，根据 biz 名称和 biz 版本返回 biz 文件。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-zk-config/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c675734b1cb5fa546f96a31d8b9e3533","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","summary":"在介绍 Biz 生命周期 时，我们提到了有三种方式控制 Biz 的生命周期，并且介绍了使用客户端 API 实现 Biz 的安装、卸载、激活。在这一章节我们介绍如何使用 SOFAArk 提供的","tags":null,"title":"Zookeeper 配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","wordcount":1160},{"author":null,"categories":null,"content":" connection_manager 用于描述 MOSN 的路由配置，通常与 proxy 配合使用。\n{ \u0026amp;quot;router_config_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;virtual_hosts\u0026amp;quot;: [ ] } router_config_name，唯一的路由配置标识，与 proxy 中配置的字段对应。 virtual_hosts，描述具体的路由规则细节。 VirtualHost { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;domains\u0026amp;quot;:[], \u0026amp;quot;routers\u0026amp;quot;:[] } name，字符串。用作 virtual host 的唯一标识。 domains，字符串数组。表示一组可以匹配到该 virtual host 的 domain，支持配置通配符。domain 的匹配优先级如下： 首先匹配精确的，如 www.foo.com。 其次匹配最长后缀的通配符，如 *.foo.com、*-bar.foo.com，其中如果一个 domain 是 foo-bar.foo.com，那么会优先匹配 *-bar.foo.com。 最后匹配任意domain的通配符 * 。 routers，一组具体的路由匹配规则。 Router { \u0026amp;quot;match\u0026amp;quot;:{}, \u0026amp;quot;route\u0026amp;quot;:{}, \u0026amp;quot;per_filter_config\u0026amp;quot;:{} } match，路由的匹配参数。 route，路由行为，描述请求将被路由的 upstream 信息。 per_filter_config，是一个 key: json 格式的 json。 其中 key 需要匹配一个 stream filter 的 type，key 对应的 json 是该 stream filter 的 config。 当配置了该字段时，对于某些 stream filter（依赖具体 filter 的实现），可以使用该字段表示的配置覆盖原有 stream filter 的配置，以此做到路由匹配级别的 stream filter 配置。 match { \u0026amp;quot;prefix\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;path\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;regex\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;headers\u0026amp;quot;: [] } 路径（path）匹配 prefix，表示路由会匹配 path 的前缀，该配置的优先级高于 path 和 regex。 如果 prefix 被配置，那么请求首先要满足 path 的前缀与 prefix 配置相符合。 path，表示路由会匹配精确的 path，该配置的优先级高于 regex。如果 path被配置，那么请求首先要满足 path 与 path 配置相符合。 regex，表示路由会按照正则匹配的方式匹配 path。如果 regex 被配置，那么请求首先要满足 path 与 regex 配置相符合。 路径匹配配置同时存在时，只有高优先级的配置会生效。 Heaer 匹配 headers，表示一组请求需要匹配的 header。请求需要满足配置中所有的 Header 配置条件才算匹配成功。 header { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;value\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;regex\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } name，表示 header 的 key。 value，表示 header 对应 key 的 value。 regex，bool 类型，如果为 true，表示 value 支持按照正则表达式的方式进行匹配。 route { \u0026amp;quot;cluster_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;metadata_match\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;retry_policy\u0026amp;quot;:{} } cluster_name，表示请求将路由到的 upstream cluster。 metadata_match，metadata，如果配置了该字段，表示该路由会基于该 metadata 去匹配 upstream cluster 的 subset 。 timeout，Duration String，表示默认情况下请求转发的超时时间。如果请求中明确指定了超时时间，那么这个配置会被忽略。 retry_policy，重试配置，表示如果请求在遇到了特定的错误时采取的重试策略，默认没有配置的情况下，表示没有重试。 retry_policy { \u0026amp;quot;retry_on\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;retry_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;num_retries\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } retry_on，bool 类型，表示是否开启重试。 retry_timeout，Duration String，表示每次重试的超时时间。当 retry_timeout 大于 route 配置的 timeout 或者请求明确指定的 timeout 时，属于无效配置。 num_retries，表示最大的重试次数。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/network-filter/connection-manager/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"88e2d06bd6137225eeebf9015b2192a2","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","summary":"connection_manager 用于描述 MOSN 的路由配置，通常与 proxy 配合使用。 { \u0026quot;router_config_name\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;virtual_hosts\u0026quot;: [ ] } router_config_name，唯一的路由配置标识，与 proxy 中配置的字段对应。 vir","tags":null,"title":"connection_manager","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","wordcount":1188},{"author":null,"categories":null,"content":"proxy 是 MOSN 最常用的 network filter，其配置格式如下。\n{ \u0026amp;quot;downstream_protocol\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;upstream_protocol\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;router_config_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;extend_config\u0026amp;quot;:{} } downstream_protocol 描述 proxy 期望收到的请求协议，在连接收到数据时，会使用此协议去解析数据包并完成转发，如果收到的数据包协议和配置不符，MOSN 会将连接断开。 upstream_protocol 描述 proxy 将以何种协议转发数据，通常情况下应该和downstream_protocol 保持一致，只有特殊的场景会进行对应协议的转换。 router_config_name 描述 proxy 的路由配置的索引，通常情况下，这个配置会和同 listener 下的 connection_manager 中配置的 router_config_name 保持一致。 extend_config 扩展配置，目前仅在 MOSN 的 XProtocol 协议中使用。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/network-filter/proxy/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b04f78179a47a64d7e209b6660bfa80f","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","summary":"proxy 是 MOSN 最常用的 network filter，其配置格式如下。 { \u0026quot;downstream_protocol\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;upstream_protocol\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;router_config_name\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;extend_config\u0026quot;:{} } downstream_protocol 描述 proxy 期望收到的请求协议，在连接收到数据时，会使用此协议去解析数据包并完成转发，","tags":null,"title":"proxy","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","wordcount":221},{"author":null,"categories":null,"content":" 打开 ACTS IDE 在 Package 视图下，右键含 @Test 注解的函数名，ACTS 功能 -\u0026amp;gt; 修改测试用例，如下图：\n编写测试数据 准备入参 根据被测的接口方法的入参（类型、顺序、数量）正确准备入参数据，简单类型包括 String、Date、Integer、Float、Double、Long、Short、Byte（包含其对应的基本类型，即 int、float 等）；复杂类型为 List、Map、Set、自定义类、Java 定义的类以及前面五者的嵌套等。\n简单入参 入参设置上右键 -\u0026amp;gt; 模版选择 -\u0026amp;gt; 简单入参选择：\n导入简单入参后，值直接在这里填写； 自上而下表示被测接口方法的第1个、第2个和第3个参数，右键可以调节顺序。\n复杂入参 如图27所示，AccountTransRequest 和 BusinessActionContext 类需要生成入参模板，一般情况下，在一键生成测试脚本时会自动生成方法的入参和返回结果的类模板，打开 ACTS IDE 可对其进行编辑，如图28。\n图28\n如果生成测试脚本时没有识别出方法的入参和返回结果模版，可先生成复杂入参和结果模版（具体操作参考 对象模型生成），然后打开 ACTS IDE 编辑器，在入参设置上右键 -\u0026amp;gt; 模版选择 -\u0026amp;gt; 复杂类型，添加后可以看到复杂对象，直接进行编辑。\nlist map 以示例2为例（Set 与此类似） 图32中，演示示例2的方法入参为 Map\u0026amp;lt;String,Object\u0026amp;gt; 类型。由于 Object 不是具体类型，如果要设置 Object 为复杂对象，则需要去编辑 YAML。例如设置 Object 为 AccountTransResult 类型，则按照如下编辑：\n图32\nenum 代码样例：\n 在 ACTS IDE 中编辑如下： 如果枚举嵌套在其他类中，则在该类的 CSV 模版中设置枚举的值为 DEBIT；\n 用例数据 YAML 中，如图37：\n interestRecoverTypeEnum: !!com.alipay.fc.loancore.common.util.enums.InterestRecoverTypeEnum \u0026#39;ALL\u0026#39; 图37\n编码方式准备入参 覆盖 prepare 方法，通过 ActsRuntimeContext 的方法，快速获取和设置用例入参，如图38所示：\n 获取所有入参：List getInputParams() 按位置获取：Object getInputParamByPos(int i) 新增用例参数：void addInputParam(Object obj) 图 38\n准备 DB 数据 准备 DB 数据-单列场景 如图39，在数据库准备设置位置右键，选择好要插入的 DB 模板（请先确保该DB模板已经生成），图中1、2、3步骤之后点击 OK 即插入 DB 准备模板，如图41，可对要插入 DB 的数据进行编辑：\n图39\n图40\n图41\n准备 DB 数据-多列场景 选中一列数据，点击复制，按此方法可复制多列数据，然后进行编辑即可：\n图42\n准备 DB 数据-flag说明 数据依赖标记：\nY: 插入 N：不插入 C：以此为where条件对插入后的数据进行清理 F：数据库函数 L: 大字段换行准备，准备方式为A=B;C=D 图43\n准备期望结果数据 生成期望结果的对象模型后，在 ACTS IDE 界面中，期望结果设置右键 -\u0026amp;gt; 模版选择，见下图。\n图44\n期望结果的 flag 说明 Y: 校验 N：不校验 D：时间偏移值比较，如 D200 ME：map 默认全 key 校验，ME则以期望 key 为准，实际值多余期望值的 key 不予校验 对于返回结果的时间 Date 类型字段校验说明： 1. Y | null -\u0026amp;gt; 代表期望为 null 2. Y | 2015-01-01 00:00:00 -\u0026amp;gt; 代表期望为 2015-01-01 00:00:00 3. N | null -\u0026amp;gt; 代表不校验 4. D200 | 2015-01-01 00:00:00/null -\u0026amp;gt; 代表与 2015-01-01 00:00:00/new Date() 相差 200 秒\n编码方式准备期望结果 覆盖 prepare 方法，通过 ActsRuntimeContext 的如下方法，快速获取和设置期望结果。 1. 获取期望结果：Object getExpectResult() 2. 设置期望结果：Boolean setExpectResult(Object objToSet)\n准备期望 DB 数据 准备期望 DB 数据-单列场景 在数据库期望设置里配置，操作参考准备 DB 数据-单列场景\n准备期望 DB 数据-多列场景 在数据库期望设置里配置，操作参考准备 DB 数据-多列场景\n期望 DB 数据的 flag 说明 数据校验标记：\nY: 校验 N：不校验 C：以此为条件 select 然后比较，如果结果有多个，则返回的结果所有记录都要和当前需要校验的数据进行校验 CN： 这个 flag 表示当前这张表中以 C 和 CN 为条件查询出的结果为空 D200：表示对比时间的时候误差 200s 之内都算通过，日期类型的格式为：today L： 数据库大字段换行数据校验，准备方式为 A=B;C=D P：DB 大字段校验，以期望结果的 kv 为基准，对 DB 大字段里的 kv 进行校验，要求 DB 里的 kv 之间是换行分隔 R：正则匹配校验 准备期望异常数据 编码方式准备期望异常数据 部分系统封装的异常类没有默认构造函数，这样通过模版添加的异常结果在加载 YAML 时会有问题（无默认构造函数无法构造当前类），需要通过代码方式，结合自定义参数编写异常脚本，如下图：\n图45\n准备自定义数据 自定义数据-用途 用户自定义的各类型数据，用于测试过程中自由使用。\n自定义数据-数据类型 数据类型可参考 入参 部分\n编码方式准备自定义数据 快速获取和设置自定义参数：\n 获取全部自定义参数：getParamMap getParamMap() 按 key 获取：Object getParamByName(String paraName) 新增自定义参数：void addOneParam(String paraName, Object paraObj) 替换自定义参数：void setParamMap(Map\u0026amp;lt;String,Object\u0026amp;gt; paramMap) 以范型方式获取自定义参数：T getParamByNameWithGeneric(String paraName) 不同数据类型编辑方式 简单类型编辑 以自定义参数设置添加简单类型数据为例。如图46，自定义参数设置右键 -\u0026amp;gt; 模板选择，弹框填写入参名字：\n图46\n图47\n选择 String 类型，在下方编辑框填写值即可，生成后也可自行编辑： ![填写值](enter-value.png) 图48\n图49\n复杂对象编辑 以自定义参数设置添加复杂对象数据为例\n参照 简单类型编辑，在弹框填 …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ide/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"697e7e6d35a2e058f3ca8b0a72032690","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-ide/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-ide/","summary":"打开 ACTS IDE 在 Package 视图下，右键含 @Test 注解的函数名，ACTS 功能 -\u0026gt; 修改测试用例，如下图： 编写测试数据 准备入参 根据被测的接口方法的入参（类型、顺序、数量","tags":null,"title":"一站式编辑","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-ide/","wordcount":2588},{"author":null,"categories":null,"content":" 快速理解 ACTS 的模型 在写测试用例的过程中，需要预先准备一些 DB 表、方法入参的数据，或者需要校验一些 DB 表、返回结果的数据，这些数据可以以模版的形式保存下来，在编辑用例时，可以方便的导入这些数据到准备数据或者校验数据，实现数据复用。目前 ACTS 模型可以分为 DB 模型和类模型。\n常规的测试用例编写，DB 、方法入参、返回结果等领域模型的数据准备是通过测试代码组织的，随着业务复杂度，领域模型复杂度也在不断增加，尤其在金融级业务用，往往一个类或者数据表有数十个属性或者字段，类与类的嵌套也是随处可见，代码构造复杂对象变得十分困难且容易疏漏，问题频现： * 表太多容易遗漏，排查时间太长； * 表的字段名记不住，时不时写错； * 接口入参数量多类型复杂，看见就头疼； * 类的属性太多，容易遗漏重要属性； * 嵌套构造对象，不断的 new 和 set 赋值； * 继承和实现关系复杂，遗漏重要属性；\nACTS 的模版有可以有效应对上述问题，通过将类和表固化为 CSV，类的结构一目了然，通过类、数据表的模版可以快速的模版化地创建对象，并序列化到 YAML 文件中，使用 ACTS IDE 可以方便的管理用例数据。\n模型存储位置 在 test 模块的 resource/model 目录可以查看已经存在的模型。\n图4\n数据表模型生成 数据表模型样例 图5\n1. 校验 flag 说明\n```plain Y: 插入 N：不插入 C：以此为 where 条件对插入后的数据进行清理 F：数据库函数 L: 大字段换行准备，准备方式为 A=B;C=D ``` 2. 用例编辑使用模型快速导入数据\n使用 ACTS IDE 编辑 DB 表数据（包括准备表数据、期望表数据）时，可右键新增指定表的模型，用于直接从表模型的 CSV 中导入表的全部字段和值，以便快速编辑。 DB 模版的使用可参考准备 DB 数据。\n生成表模型 图6\n图7\n图8\n点击 OK 后生成模板，如图9：\n图9\n同时支持不配置直连获取表结构的方式生成表模型，即在 DO 类上右键根据类生成表模型： DO 类上右击 -\u0026amp;gt; ACTS 功能 -\u0026amp;gt; 生成 DO 模型：\n图10\n![生产的模型](generated-do-model.png) 图11\n对象模型生成 对象模型样例 图12\n图13\n一个复杂对象是一个闭包，不但包含其自身模型还包含其嵌套对象的模型。\nACTS 使用模型快速导入数据、编辑复杂对象（包括入参、返回结果和异常等），在 ACTS IDE 中可右键选择类模型，用于构建该类的对象并赋值以便快速编辑。\n生成方法 有两种方式： 1.待构建模型的类定义的任意方法上点击； 1.接口定义的方法上点击，详细操作看下图示例。\n使用 IDEA 的同学请注意：请先确保代码已编译，IDEA 不会自动编译而需要手动 mvn clean install 或者打开自动编译 File -\u0026amp;gt; Settings -\u0026amp;gt; Build,Execution,Deployment -\u0026amp;gt; Compiler -\u0026amp;gt; Make project automatically。\nACTS IDE 生成对象模型 （1）待构建模型的类定义的任意方法上点击，生成当前类的模型\n图14\n（2）接口定义任意方法上点击，生成当前接口中，所有方法的复杂入参、复杂返回结果的模型\n图15\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-model/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"65aaf62462b3b0ea142ca75a5b61eb0d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-model/","summary":"快速理解 ACTS 的模型 在写测试用例的过程中，需要预先准备一些 DB 表、方法入参的数据，或者需要校验一些 DB 表、返回结果的数据，这些数据可以以模版的形式保","tags":null,"title":"一键模型化","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-model/","wordcount":1096},{"author":null,"categories":null,"content":" 快速理解 ACTS 中的脚本 如果你是一个经常编写测试用例的同学，是不是经常苦于这样的问题： * 不断的 assertEquals 写得快吐了，重复性编码毫无创意； * 少一个 assert 容易假绿，错一个败坏心情； * 场景一旦复杂，测试代码比业务代码还要长，写起来痛不欲生； * 每换一个应用，之前写的工具类就要搬一次；\n左图为 TestNG 用例，右图为 ACTS 用例，重复性代码一去不回，代码体积明显缩小。区别于普通测试脚本，ACTS 脚本继承自 ActsTestBase 类，封装了数据加载、驱动、执行引擎和校验规则，无需用户来组织清理数据、准备数据、执行用例和校验结果，对于简单业务可以做到零编码，极大释放代码编写和后期维护成本。\n测试脚本生成 前提条件：务必 mvn 编译工程和生成对象模型，否则会造成 ACTS IDE 不可预料的错误，如无法编辑、数据不正确等。\n接口定义的方法上点击，选择 ACTS 功能 -\u0026amp;gt; 生成测试用例。\n测试脚本运行 方法：右键 ACTS 脚本中的被测方法，选择 TestNG 来执行测试脚本，如下图：\n指定测试脚本运行 在 src/test/resource/config/acts-config.properties 中配置 test_only＝^T，表示只跑用例名称以 T 开头的用例，^T 也可以换成其他正则表达式；\n 修改要测试的用例名称，在用例名前面加 T，ACTS 运行时时仅执行用例名称以 T 开头的用例。\n 脚本用例拆分功能 默认每个测试脚本的所有用例数据保存在同一个 YAML 中，ACTS 支持用例数据根据开关 spilt_yaml_by_case 来决定同一测试脚本的所有用例数据存储在一个 YAML 中还是每个用例存储为一个 YAML。 开关默认为关闭，即同一测试脚本的所有测试数据存储在一个 YAML 文件中。\n在 acts-config.properities 中设置 spilt_yaml_by_case=true 即可打开开关，之后新生成测试脚本时每个用例对应一个单独的以 caseId 命名的 YAML文件，拆分的方式可以降低多人研发同一接口带来的文件冲突问题。\n此外，为了支持将老的 YAML 文件按用例拆分，ACTS 提供了工具类，如下，支持将指定脚本下，指定路径的 YAML 文件按用例拆分。\n BaseDataUtil.saveYamlDataToCaseByCase\n 注意：拆分后，建议先给原有 YAML 重命名做备份，然后打开用例编辑器检查拆分后的文件内容是否正确，确认无误后可删除原有 YAML 文件，两者不能并存。 编码方式准备数据 ACTS 提供了数据自定义 API 接口，封装于 ActsRuntimeContext 类中，如下： + 快速获取和设置自定义参数\n获取全部自定义参数：`getParamMap getParamMap()` 按 key 获取：`Object getParamByName(String paraName)` 新增自定义参数：`void addOneParam(String paraName, Object paraObj)` 替换自定义参数：`void setParamMap(Map\u0026amp;lt;String, Object\u0026amp;gt; paramMap)` 泛型方式获取自定义参数：`T getParamByNameWithGeneric(String paraName)` 快速获取和设置用例入参\n获取所有入参：List getInputParams() 按位置获取：Object getInputParamByPos(int i) 新增用例参数：void addInputParam(Object obj)\n 快速获取和设置期望结果\n获取期望结果：Object getExpectResult() 设置期望结果：Boolean setExpectResult(Object objToSet)\n Mock 功能使用 Mock 功能目前是采用 Mockito 的方案，具体资料见 Mockito 英文文档和 Mockito 中文文档\n增加依赖 在 test 模块增加如下依赖（如果已经引入 SOFABoot 的测试 starter 则无需重复引入）\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 默认 spring test 依赖的 mockito 版本是 1.x，想要升级的可以排除后再引入相应的版本\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.mockito\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mockito-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.18.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Mockito 用于测试时进行打桩处理，通过它可以指定某个类的某个方法在什么情况下返回什么样的值。Mockito 库能够 Mock 对象、验证结果以及打桩，示例如下：\n@SpringBootTest(classes = SOFABootApplication.class) @TestExecutionListeners(listeners = MockitoTestExecutionListener.class) public class RegisterUserActsTest extends ActsTestBase { @TestBean @Autowired // 这是测试类 public UserService userService; @MockBean // 这是要mock的bean public AccountManageFacadeClient accountManageFacadeClient; @Test(dataProvider = \u0026amp;quot;ActsDataProvider\u0026amp;quot;) public void registerUser (String caseId, String desc, PrepareData prepareData) { runTest(caseId, prepareData); } @Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { super.beforeActsTest(actsRuntimeContext); AccountManageResult accountManageResult = new AccountManageResult(); …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-script/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0d20739dedad1f11277bd02ed65329c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-script/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-script/","summary":"快速理解 ACTS 中的脚本 如果你是一个经常编写测试用例的同学，是不是经常苦于这样的问题： * 不断的 assertEquals 写得快吐了，重复性编码毫无创意； * 少一个 assert 容易假绿","tags":null,"title":"一键脚本化","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-script/","wordcount":1276},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 集成 Zipkin 进行数据上报展示。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n 下面的示例中将分别演示在 SOFABoot/SpringBoot 工程中 以及 非 SOFABoot/SpringBoot 工程中如何使用。\n 依赖引入 添加 SOFATracer 依赖 工程中添加 SOFATracer 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置 Zipkin 依赖 考虑到 Zipkin 的数据上报能力不是 SOFATracer 默认开启的能力，所以期望使用 SOFATracer 做数据上报时，需要添加如下的 Zipkin 数据汇报的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.zipkin2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.11.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.reporter2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin-reporter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.7.13\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置文件 在工程的 application.properties 文件下添加一个 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFATracerReportZipkin # logging path logging.path=./logs com.alipay.sofa.tracer.zipkin.enabled=true com.alipay.sofa.tracer.zipkin.baseUrl=http://localhost:9411 启动 Zipkin 服务端 启动 Zipkin 服务端用于接收 SOFATracer 汇报的链路数据，并做展示。Zipkin Server 的搭建可以参考此文档进行配置和服务端的搭建。\n运行 可以将工程导入到 IDE 中运行生成的工程里面中的 main 方法启动应用，也可以直接在该工程的根目录下运行 mvn spring-boot:run，将会在控制台中看到启动日志：\n2018-05-12 13:12:05.868 INFO 76572 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcSofaTracerFilter\u0026#39; to urls: [/*] 2018-05-12 13:12:06.543 INFO 76572 --- [ main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped \u0026amp;quot;{[/helloZipkin]}\u0026amp;quot; onto public java.util.Map\u0026amp;lt;java.lang.String, java.lang.Object\u0026amp;gt; com.alipay.sofa.tracer.examples.zipkin.controller.SampleRestController.helloZipkin(java.lang.String) 2018-05-12 13:12:07.164 INFO 76572 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 可以通过在浏览器中输入 http://localhost:8080/helloZipkin 来访问 REST 服务，结果类似如下：\n{ content: \u0026amp;quot;Hello, SOFATracer Zipkin Remote Report!\u0026amp;quot;, id: 1, success: true } 查看 Zipkin 服务端展示 打开 Zipkin 服务端界面，假设我们部署的 Zipkin 服务端的地址是 http://localhost:9411，打开 URL 并搜索 helloZipkin(由于我们本地访问的地址是 localhost:8080/helloZipkin)，可以看到展示的链路图。\nSpring 工程运行 对于一般的 Spring 工程，我们通常使用 tomcat/jetty 作为 servlet 容器来启动应用。具体工程参考 在 Spring 工程中使用 SOFATracer\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/report-to-zipkin/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d28d192386829452262116de9c32b570","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","summary":"在本文档将演示如何使用 SOFATracer 集成 Zipkin 进行数据上报展示。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 下面的示例中将分别演","tags":null,"title":"上报数据至 Zipkin","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","wordcount":661},{"author":null,"categories":null,"content":" 优雅关闭，包括两部分，一个是 RPC 框架作为客户端，一个是 RPC 框架作为服务端。\n作为服务端 作为服务端的时候，RPC 框架在关闭时，不应该直接暴力关闭。在 RPC 框架中\ncom.alipay.sofa.rpc.context.RpcRuntimeContext 在静态初始化块中，添加了一个 ShutdownHook\n// 增加jvm关闭事件 if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } 这个 ShutdownHook 的作用是当发布平台/用户执行 kill pid 的时候，会先执行 ShutdownHook 中的逻辑。在销毁操作中，RPC 框架会先执行向注册中心取消服务注册、关闭服务端口等动作。\nprivate static void destroy(boolean active) { RpcRunningState.setShuttingDown(true); for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.preDestroy(); } List\u0026amp;lt;ProviderConfig\u0026amp;gt; providerConfigs = new ArrayList\u0026amp;lt;ProviderConfig\u0026amp;gt;(); for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { providerConfigs.add(bootstrap.getProviderConfig()); } // 先反注册服务端 List\u0026amp;lt;Registry\u0026amp;gt; registries = RegistryFactory.getRegistries(); if (CommonUtils.isNotEmpty(registries) \u0026amp;amp;\u0026amp;amp; CommonUtils.isNotEmpty(providerConfigs)) { for (Registry registry : registries) { registry.batchUnRegister(providerConfigs); } } // 关闭启动的端口 ServerFactory.destroyAll(); // 关闭发布的服务 for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { bootstrap.unExport(); } // 关闭调用的服务 for (ConsumerBootstrap bootstrap : REFERRED_CONSUMER_CONFIGS) { ConsumerConfig config = bootstrap.getConsumerConfig(); if (!CommonUtils.isFalse(config.getParameter(RpcConstants.HIDDEN_KEY_DESTROY))) { // 除非不让主动unrefer bootstrap.unRefer(); } } // 关闭注册中心 RegistryFactory.destroyAll(); // 关闭客户端的一些公共资源 ClientTransportFactory.closeAll(); // 卸载模块 if (!RpcRunningState.isUnitTestMode()) { ModuleFactory.uninstallModules(); } // 卸载钩子 for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.postDestroy(); } // 清理缓存 RpcCacheManager.clearAll(); RpcRunningState.setShuttingDown(false); if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework has been release all resources {}...\u0026amp;quot;, active ? \u0026amp;quot;actively \u0026amp;quot; : \u0026amp;quot;\u0026amp;quot;); } } 其中以 bolt 为例，关闭端口并不是一个立刻执行的动作\n@Override public void destroy() { if (!started) { return; } int stopTimeout = serverConfig.getStopTimeout(); if (stopTimeout \u0026amp;gt; 0) { // 需要等待结束时间 AtomicInteger count = boltServerProcessor.processingCount; // 有正在执行的请求 或者 队列里有请求 if (count.get() \u0026amp;gt; 0 || bizThreadPool.getQueue().size() \u0026amp;gt; 0) { long start = RpcRuntimeContext.now(); if (LOGGER.isInfoEnabled()) { LOGGER.info(\u0026amp;quot;There are {} call in processing and {} call in queue, wait {} ms to end\u0026amp;quot;, count, bizThreadPool.getQueue().size(), stopTimeout); } while ((count.get() \u0026amp;gt; 0 || bizThreadPool.getQueue().size() \u0026amp;gt; 0) \u0026amp;amp;\u0026amp;amp; RpcRuntimeContext.now() - start \u0026amp;lt; stopTimeout) { // 等待返回结果 try { Thread.sleep(10); } catch (InterruptedException ignore) { } } } // 关闭前检查已有请求？ } // 关闭线程池 bizThreadPool.shutdown(); stop(); } 而是 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/graceful-shutdown/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"53af179e23ba184b01eb8234c055b15d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","summary":"优雅关闭，包括两部分，一个是 RPC 框架作为客户端，一个是 RPC 框架作为服务端。 作为服务端 作为服务端的时候，RPC 框架在关闭时，不应该直接暴力关闭。在","tags":null,"title":"优雅关闭","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","wordcount":866},{"author":null,"categories":null,"content":" 使用 CloudMesh 轻松实践 Service Mesh Demo 内容介绍 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。\nDemo内容介绍 Service Mesh 将服务间通信能力下沉到基础设施，让应用解耦并轻量化。\n但 Service Mesh 本身的复杂度依然存在，CloudMesh 通过将 Service Mesh 托管在云上，使得您可以轻松的实践 Service Mesh 技术。\n通过我们的 workshop，您可以将以多种编程语言开发的应用，简单部署到 CloudMesh 上，即可获得服务网格提供的强大能力。包括对服务进行访问，通过监控查看流量，体验服务治理、Sidecar 管理和对服务的新版本进行灰度发布等实用功能。\n本次 demo 中，我们将重点体验 CloudMesh 强大的流量控制能力。在灰度发布过程中，可以对灰度流量占比进行精准控制，并通过实时流量监控了解服务网格中流量的实际走向：\n常规的灰度发布，在灰度过程中需要占用两倍容量：\nCloud Mesh 提供的灰度发布功能，可以实现在灰度发布过程中不必占有额外的容量，而且容许在发布期间多次暂停以便修改灰度占比：\nDemo 操作指南 为了方便参加本次 demo 的同学，我们准备了整个 demo 流程的详尽的操作指南。\n更多 请 点击此处访问 在线版本。 下载本地 Demo 幻灯片。 ","date":-62135596800,"description":"使用该指南您可以快速部署应用到 CloudMesh ，对服务进行访问，通过监控查看流量，体验服务治理、Sidecar管理和对服务的新版本进行灰度发布等实用功能。","dir":"guides/kc-cloud-mesh-demo/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e389a65e6736e909718275cd76505525","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-cloud-mesh-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/guides/kc-cloud-mesh-demo/","summary":"使用 CloudMesh 轻松实践 Service Mesh Demo 内容介绍 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。 Demo内容介绍 Service Mesh 将服务间通信能力下沉到基础","tags":null,"title":"使用 CloudMesh 轻松实践 Service Mesh","type":"guides","url":"/sofastack.tech/guides/kc-cloud-mesh-demo/","wordcount":453},{"author":null,"categories":null,"content":"使用 Consul 作为服务注册中心需要添加如下依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.ecwid.consul\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;consul-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 中如下配置：\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 其中后面的值为 consul 的连接地址，如果需要设置一些其他参数，也可以通过\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;amp;b=2 进行设置\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-consul/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e6b0aa843ea0ad401c3184f6ce87649b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-consul/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-consul/","summary":"使用 Consul 作为服务注册中心需要添加如下依赖 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.ecwid.consul\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;consul-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.4.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 然后在 application.properties 中如下配置： com.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 其中后面的值为 consul 的连接地址，如果需要设置一些其他参数，也可以通过 com.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;b=2 进行","tags":null,"title":"使用 Consul 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-consul/","wordcount":72},{"author":null,"categories":null,"content":" 本文将介绍如何使用 MOSN 在 SOFAMesh 框架下搭建 Service Mesh 的开发环境，并验证 MOSN 的一些基础路由能力、负载均衡能力等。本文介绍的内容将包括 :\n MOSN 与 SOFAMesh 的关系 准备工作 源码方式部署 SOFAMesh Bookinfo 实验 MOSN 与 SOFAMesh 的关系 我们曾在 MOSN 介绍中介绍过，MOSN 是一款采用 Go 语言开发的 Service Mesh 数据平面代理。而 SOFAMesh 则是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案，MOSN 作为 SOFAMesh 的关键组件用来完成数据面的转发。\n下图是 SOFAMesh 整体框架下，MOSN 的工作示意图。\n注意：当前 MOSN 不支持在原生的 Istio 中直接使用。\n 准备工作 本文以 macOS 为例 ，其他环境可以安装对应版本的软件。\n1. 安装 hyperkit 先安装 docker-for-mac，之后安装驱动\n1.1 安装 docker 下载软件包安装，或者使用如下的命令安装。\n$ brew cask install docker 1.2 安装驱动 $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. 安装 Minikube(也可以购买商业 k8s 集群) 推荐使用 Minikube v0.28 以上来体验，请参考 https://github.com/kubernetes/minikube\n$ brew cask install minikube 3. 启动 Minikube 注意，pilot 至少需要 2G 内存，所以在启动的时候，可以通过加参数的方法给 minikube 添加分配的资源，如果你机器的资源不够，推荐使用商业版本的 k8s 集群。\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit 创建istio 命名空间\n$ kubectl create namespace istio-system 4. 安装 kubectl 命令行工具 kubectl 是用于针对 k8s 集群运行命令的命令行接口，安装参考 https://kubernetes.io/docs/tasks/tools/install-kubectl。\n$ brew install kubernetes-cli 5. 安装 Helm Helm 是一个 k8s 的包管理工具，安装参考 https://docs.helm.sh/using_helm/#installing-helm\n$ brew install kubernetes-helm 源码方式部署 SOFAMesh 1. 下载 SOFAMesh 源码 $ git clone https://github.com/sofastack/sofa-mesh.git 2. 通过 Helm 安装 SOFAMesh 使用 helm template 安装\n首先需要切换到SOFAMesh源码所在目录，然后使用Helm安装istio CRD以及各个组件\n$ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - 3. 验证安装 istio-system 命名空间下的 pod 状态都是 Running 时，说明已经部署成功。 如果仅仅是为了运行bookinfo，只需要pilot,injector,citadel这三个pods运行成功就可以满足最低要求\n$ kubectl get pods -n istio-system NAME READY STATUS RESTARTS AGE istio-citadel-6579c78cd9-w57lr 1/1 Running 0 5m istio-egressgateway-7649f76df4-zs8kw 1/1 Running 0 5m istio-galley-c77876cb6-nhczq 1/1 Running 0 5m istio-ingressgateway-5c9c8565d9-d972t 1/1 Running 0 5m istio-pilot-7485f9fb4b-xsvtm 1/1 Running 0 5m istio-policy-5766bc84b9-p2wfj 1/1 Running 0 5m istio-sidecar-injector-7f5f586bc7-2sdx6 1/1 Running 0 5m istio-statsd-prom-bridge-7f44bb5ddb-stcf6 1/1 Running 0 5m istio-telemetry-55ff8c77f4-q8d8q 1/1 Running 0 5m prometheus-84bd4b9796-nq8lg 1/1 Running 0 5m 4. 卸载安装 卸载SOFAMesh\n$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - $ kubectl delete namespace istio-system BookInfo 实验 BookInfo 是一个类似豆瓣的图书应用，它包含四个基础服务：\n Product Page：主页，由 python 开发，展示所有图书信息，它会调用 Reviews 和 Details 服务 Reviews：评论，由 java 开发，展示图书评论，会调用 Ratings 服务 Ratings：评分服务，由 nodejs …","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-with-sofamesh/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9c6461e92180417d3a8ec4f3f2c723fe","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","summary":"本文将介绍如何使用 MOSN 在 SOFAMesh 框架下搭建 Service Mesh 的开发环境，并验证 MOSN 的一些基础路由能力、负载均衡能力等。本文介绍的内容将包括 : MOSN 与 SOFAMesh 的关系 准备工作 源码","tags":null,"title":"使用 MOSN 搭建 Service Mesh 平台","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","wordcount":1654},{"author":null,"categories":null,"content":"SOFARPC 已支持使用 Nacos 作为服务注册中心。假设你已经根据 Nacos 的快速开始在本地部署好 Nacos Server，服务发现的端口默认设置在 8848。\n在 SOFARPC 中使用 Nacos 作为服务注册中心只需要在 application.properties 中加入如下配置即可：\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 如果你直接使用了 SOFARPC，而不是 SOFABoot，需要手动添加 nacos 的依赖，其中 version 为用户想使用的 version。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba.nacos\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;nacos-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 当前支持 Nacos 的版本： - SOFARPC：5.5.0 支持 Nacos 服务端版本 0.6.0，SOFABoot: 2.5.3。 - SOFARPC：5.6.0 支持 Nacos 服务端版本 1.0.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-nacos/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cc161f22cd2145fe309e63087581adc1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-nacos/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-nacos/","summary":"SOFARPC 已支持使用 Nacos 作为服务注册中心。假设你已经根据 Nacos 的快速开始在本地部署好 Nacos Server，服务发现的端口默认设置在 8848。 在 SOFARPC 中使用 Nacos 作为服务","tags":null,"title":"使用 Nacos 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-nacos/","wordcount":232},{"author":null,"categories":null,"content":"SOFARPC 已支持使用 SOFARegistry 作为服务注册中心。假设你已经根据 SOFARegistry 的快速开始在本地部署好 SOFARegistry Server，服务发现的端口默认设置在 9603。\n在 SOFARPC 中使用 SOFARegistry 作为服务注册中心首先要添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.2.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 中加入如下配置即可：\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 当前支持 SOFARegistry 的版本：\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\n由于本次发布的时间问题，暂时需要用户指定SOFARPC Starter的版本\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFARPC 集成验证 SOFARegistry 服务端版本：5.2.0\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-sofa/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"65085018ce2b2b2ef452993bb79a69de","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-sofa/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-sofa/","summary":"SOFARPC 已支持使用 SOFARegistry 作为服务注册中心。假设你已经根据 SOFARegistry 的快速开始在本地部署好 SOFARegistry Server，服务发现的端口默认设置在 9603。 在 SOFARPC 中使用 SOFARegistry 作为服务","tags":null,"title":"使用 SOFARegistry 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-sofa/","wordcount":182},{"author":null,"categories":null,"content":" 使用 SOFAStack 快速构建微服务 前置条件 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n [必选]部署注册中心：https://www.sofastack.tech/projects/sofa-registry/server-quick-start/ [必须]部署数据库：本地自行搭建数据库，然后导入 DDL.sql [可选]部署 LookoutServer：https://www.sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/ [可选]部署 Zipkin：https://zipkin.io/pages/quickstart.html 实验内容 本实验基于 SOFAStack 快速构建一个微服务，主要包括以下几个部分：\n 使用 SOFABoot + SOFARPC 发布服务 使用 SOFABoot + SOFARPC 调用服务 通过 ZipKin 查看 SOFATracer 上报的 Tracer 信息 通过 SOFALookout 查看上报的 Metrics 信息 架构图 任务 1、任务准备 从 github 上将 demo 工程克隆到本地\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git 然后将工程导入到 IDEA 或者 eclipse。导入之后界面如下：\n balance-mng：余额管理系统，提供扣减余额服务 stock-mng：库存管理系统，提供扣减库存服务 2、引入依赖 将下面的依赖引入到 balance-mng 和 stock-mng 工程模块的 pom.xml 文件中。\n\u0026amp;lt;!--SOFARPC 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFATracer 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFARegistry 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--runtime 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFALookout 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; balance-mng 工程需要将依赖引入 balance-mng/balance-mng-impl/pom.xml 文件：\nstock-mng 工程直接将依赖引入 stock-mng/pom.xml 文件：\n3、添加配置 将如下配置复制到 balance-mng 和 stock-mng 工程模块的 application.properties 中。\n# 1、添加服务注册中心地址 com.alipay.sofa.rpc.registry.address=sofa://localhost:9603 # 2、添加 tracer 数据上报的服务端 zipkin 地址 # 如果上面前置条件未搭建 tracer，可以不配置 com.alipay.sofa.tracer.zipkin.base-url=http://localhost:9411 # 3、添加 metrics 数据上报的服务端地址 # 如果上面前置条件未搭建 lookout-server，可以不配置 com.alipay.sofa.lookout.agent-host-address=localhost balance-mng 工程需要将配置添加至 balance-mng/balance-mng-bootstrap/src/main/resources/application.properties 文件：\n另外数据库配置修改为自己的数据库信息：\n# database config spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://localhost:3306/stock_db spring.datasource.username=root spring.datasource.password=root stock-mng 工程需要将配置添加至 stock-mng/src/main/resources/application.properties 文件：\n另外数据库配置修改为自己的数据库信息：\n# database config spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://localhost:3306/stock_db spring.datasource.username=root spring.datasource.password=root 4、修改 unique id 由于所有人共用一套服务发现，为区分不同用户发布的服务，需要为服务增加 unique id。\nKubeCon workshop 会给每个用户准备一个 SOFAStack 账号，格式为 user0@sofastack.io 到 user99@sofastack.io，去掉 @sofastack.io 部分，账户前半部分的 user0 至 user99 即可作为 unique id。\n 注意：balance-mng 和 stock-mng 里的 unique id 需要一致。 …","date":-62135596800,"description":"本指南将基于 SOFAStack 快速构建一个微服务。","dir":"guides/sofastack-quick-start/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"78bfd4806a86dc15ac86eee16fb85c82","permalink":"https://sofastack.github.io/sofastack.tech/guides/sofastack-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/sofastack-quick-start/","summary":"使用 SOFAStack 快速构建微服务 前置条件 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 [必选]部署注册中心：https://ww","tags":null,"title":"使用 SOFAStack 快速构建微服务","type":"guides","url":"/sofastack.tech/guides/sofastack-quick-start/","wordcount":1486},{"author":null,"categories":null,"content":" 使用 Seata 保障支付一致性 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n在开始该 demo 之前先完成《使用 SOFAStack 快速构建微服务》，如果没有完成，可以基于仓库里的 kc-sofastack-demo 工程为基线完成下面的 demo，该 demo 是在它基础上加上 Seata 分布式事务。但该 demo 不是只能应用于 SOFA，可以适用于任何 java 技术栈应用。\nAT 模式 1、引入 maven 依赖 将下面的依赖引入到父工程的 pom 文件中（kc-sofastack-demo/pom.xml）:\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;seata.version\u0026amp;gt;0.6.1\u0026amp;lt;/seata.version\u0026amp;gt; \u0026amp;lt;netty4.version\u0026amp;gt;4.1.24.Final\u0026amp;lt;/netty4.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; \u0026amp;lt;dependencyManagement\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;javax.servlet\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;servlet-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${netty4.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; \u0026amp;lt;/dependencyManagement\u0026amp;gt; 将下面的依赖引入到 stock-mng 工程的 pom 文件中（kc-sofastack-demo/stock-mng/pom.xml）:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 将下面的依赖引入到 balance-mng-impl 工程的 pom 文件中（kc-sofastack-demo/balance-mng/balance-mng-impl/pom.xml）:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 2、使用 Seata 的 DataSourceProxy 代理实际的数据源，并配置 GlobalTransactionScanner 扫描@GlobalTransaction 注解 将下面的 java 代码段加到 BalanceMngApplication 和 StockMngApplication 类的 main 方法下面:\nimport io.seata.rm.datasource.DataSourceProxy; import io.seata.spring.annotation.GlobalTransactionScanner; public static void main(String[] args) { SpringApplication.run(BalanceMngApplication.class, args); } @Configuration public static class DataSourceConfig { @Bean @Primary @ConfigurationProperties(prefix = \u0026amp;quot;spring.datasource.hikari\u0026amp;quot;) public DataSource dataSource(DataSourceProperties properties) { HikariDataSource dataSource = createDataSource(properties, HikariDataSource.class); if (properties.getName()!=null \u0026amp;amp;\u0026amp;amp; properties.getName().length() \u0026amp;gt; 0) { dataSource.setPoolName(properties.getName()); } return new DataSourceProxy(dataSource); } @SuppressWarnings(\u0026amp;quot;unchecked\u0026amp;quot;) protected …","date":-62135596800,"description":"该指南将向您展示如何使用开源分布式事务框架 Seata 的 AT 模式、TCC 模式解决业务数据的最终一致性问题。 ","dir":"guides/kc-seata-demo/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"60071a0eb44bf0901fb187eefd63ccdb","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-seata-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/guides/kc-seata-demo/","summary":"使用 Seata 保障支付一致性 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 在开始该 demo 之前先完成《使用 SOFAStack 快速构建微服务》，如果","tags":null,"title":"使用 Seata 保障支付一致性","type":"guides","url":"/sofastack.tech/guides/kc-seata-demo/","wordcount":2320},{"author":null,"categories":null,"content":" 使用 Zookeeper 作为服务注册中心只需要在 application.properties 中如下配置即可：\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 注意：考虑掉服务的实时性，以下特性暂不支持\nSOFABoot RPC 也提供一个缓存文件(目前暂不支持)，当 Zookeeper 不可用时，使用该缓存文件进行服务发现。配置该缓存文件的方式如下：\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth 支持 当用户需要对发布和消费服务，进行权限认证的时候，可以通过在操作 zookeeper 时，指定对应的目录和账号密码来进行读写。这样只有使用了相同密码的 服务方或者消费方才能进行读写。\nSOFARPC API 支持 在构造注册中心的时候，将Auth添加上\nparameters.put(\u0026amp;quot;scheme\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;); //如果存在多个认证信息，则在参数形式为为user1:passwd1,user2:passwd2 parameters.put(\u0026amp;quot;addAuth\u0026amp;quot;, \u0026amp;quot;sofazk:rpc1\u0026amp;quot;); registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181/authtest\u0026amp;quot;) .setParameters(parameters); 之后其他没有使用正确auth的，将无法访问authtest目录\nXML 方式支持 如下使用即可\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry\u0026amp;amp;scheme=digest\u0026amp;amp;addAuth=sofazk:rpc1 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-zookeeper/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"71d6486c5577cc85d84c56688cdf2af1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","summary":"使用 Zookeeper 作为服务注册中心只需要在 application.properties 中如下配置即可： com.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 注意：考虑掉服务的实时性，以下特性暂不支持 SOFABoot RPC 也提供一个缓存文件(目前暂不支持)，当 Zookeeper 不可","tags":null,"title":"使用 Zookeeper 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","wordcount":309},{"author":null,"categories":null,"content":"使用本地文件作为服务注册中心在 application.properties 中如下配置即可：\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg 其中 /home/admin/registry/localRegistry.reg 就是使用的本地文件的目录。\n对于 windows 用户，则以上地址类似：\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-local/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"33bc89393392e21b3917f090313c0df5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-local/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-local/","summary":"使用本地文件作为服务注册中心在 application.properties 中如下配置即可： com.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg 其中 /home/admin/registry/localRegistry.reg 就是使用的本地文件的目录。 对于 windows 用户，则以上地址类似： com.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg","tags":null,"title":"使用本地文件作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-local/","wordcount":56},{"author":null,"categories":null,"content":" SOFABoot 是在 Spring Boot 的基础上提供的功能扩展。基于 Spring Boot 的机制，SOFABoot 管理了 SOFA 中间件的依赖，并且提供了 Spring Boot 的 Starter，方便用户在 Spring Boot 中使用 SOFA 中间件。\nSOFABoot 依赖管理 \u0026amp;ndash; Maven 在使用 SOFA 中间件之前，需要引入 SOFABoot 依赖管理。类似 Spring Boot 引入方式，在工程中增加如下 \u0026amp;lt;parent/\u0026amp;gt; 标签配置的方式:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 其中 ${sofa.boot.version} 为具体的 SOFABoot 版本，参考发布历史。\nSOFABoot 依赖管理 \u0026amp;ndash; Gradle 从 SOFABoot 3.1.1 版本开始，SOFABoot 开始支持使用 Gradle 来进行依赖管理，如果要使用 Gradle 来进行依赖管理，需要按照如下的形式来配置 build.gradle：\nbuildscript { ext { sofaBootVersion = \u0026#39;3.1.1\u0026#39; } repositories { mavenLocal() mavenCentral() } dependencies { classpath(\u0026amp;quot;com.alipay.sofa:sofa-boot-gradle-plugin:${sofaBootVersion}\u0026amp;quot;) } } apply plugin: \u0026#39;java\u0026#39; apply plugin: \u0026#39;eclipse\u0026#39; apply plugin: \u0026#39;com.alipay.sofa.boot\u0026#39; apply plugin: \u0026#39;io.spring.dependency-management\u0026#39; group = \u0026#39;com.example\u0026#39; version = \u0026#39;0.0.1-SNAPSHOT\u0026#39; sourceCompatibility = 1.8 repositories { mavenLocal() mavenCentral() } dependencies { implementation(\u0026#39;com.alipay.sofa:rpc-sofa-boot-starter\u0026#39;) implementation(\u0026#39;org.springframework.boot:spring-boot-starter\u0026#39;) testImplementation(\u0026#39;org.springframework.boot:spring-boot-starter-test\u0026#39;) } 主要有几个步骤：\n 添加 buildScript，增加 sofa-boot-gradle-plugin 的依赖，其中版本号为你使用的 SOFABoot 的版本。 添加两个 plugin，分别是 com.alipay.sofa.boot 和 io.spring.dependency-management。 这样，在 dependencies 里面，就可以直接添加 SOFABoot 管理的各种中间件和依赖了，而不用声明版本号。\n引入 SOFA 中间件 SOFABoot 使用一系列后缀为 -sofa-boot-starter 来标示一个中间件组件，如果想要使用某个中间件，直接添加对应的依赖即可。例如，如果期望使用 SOFARPC，只需增加下面的 Maven 依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 注意上面的 Maven 依赖中并没有声明版本，这个是因为版本已经在 sofaboot-dependencies 里面声明好。这样做的好处是对于 SOFA 中间件，用户统一进行升级即可，不需要单独升级一个中间件的版本，防止出现依赖冲突以及兼容性的问题。目前管控的 SOFABoot 中间件列表如下:\n 中间件 starter SOFARPC rpc-sofa-boot-starter SOFATracer tracer-sofa-boot-starter SOFALookout lookout-sofa-boot-starter 引入 SOFABoot 扩展组件 SOFABoot 基于 Spring Boot 提供了健康检查，模块隔离，类隔离等扩展能力。遵循 Spring Boot 依赖即服务的理念，添加相关组件依赖之后，扩展能力即可生效。目前提供的扩展组件如下：\n 扩展组件 starter 健康检查 actuator-sofa-boot-starter 模块化隔离 isle-sofa-boot-starter 类隔离 sofa-ark-springboot-starter 测试扩展 test-sofa-boot-starter 引入 SOFA 中间件 ark 插件 SOFABoot 提供了类隔离组件 SOFAArk，借助 SOFAArk 容器，用户可以将依赖冲突的三方包打包成 ark 插件。运行时，ark 插件使用单独的类加载器加载，可以和其他 ark 插件以及业务依赖隔离，解决类冲突问题。SOFABoot 官方提供了 SOFARPC 和 SOFATracer 的 ark 插件，例如在应用中引入 SOFARPC ark 插件依赖替代 SOFARPC starter，从而隔离应用和 SOFARPC 及其间接依赖。目前管控的 ark 插件列表如下:\n Ark插件 plugin SOFARPC rpc-sofa-boot-plugin SOFATracer tracer-sofa-boot-plugin 引入 SOFABoot 命名空间 使用 SOFA 中间件时，需要在 XML 中根据中间件的具体使用方式添加相应的配置，这个时候需要引入 SOFABoot 的命名空间 xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; 以能够正确解析相应的配置标签，示例：\n\u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/dependency-management/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dabdbd425f20dee4d7ab580d43574456","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/dependency-management/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/dependency-management/","summary":"SOFABoot 是在 Spring Boot 的基础上提供的功能扩展。基于 Spring Boot 的机制，SOFABoot 管理了 SOFA 中间件的依赖，并且提供了 Spring Boot 的 Starter，方便用户在 Spring Boot 中使用","tags":null,"title":"依赖管理","type":"projects","url":"/sofastack.tech/projects/sofa-boot/dependency-management/","wordcount":981},{"author":null,"categories":null,"content":"SOFARPC 使用了一些三方开源组件，他们分别是：\n一些主要依赖：\n Netty under Apache License 2.0 SLF4j under the MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 一些扩展依赖：\n protobuf under New BSD License Snappy under Apache License 2.0 dubbo under Apache License 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b6c87388d5c1462f13d92012639a08b2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/notice/","summary":"SOFARPC 使用了一些三方开源组件，他们分别是： 一些主要依赖： Netty under Apache License 2.0 SLF4j under the MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 一些扩展依赖： protobuf under New BSD License","tags":null,"title":"依赖组件版权说明","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/notice/","wordcount":87},{"author":null,"categories":null,"content":" SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 的能力。如果你需要使用 SOFA 中间件，那么建议使用 SOFABoot 的健康检查能力的扩展，来更优雅的上线应用实例\n引入健康检查扩展 要引入 SOFABoot 的健康检查能力的扩展，只需要引入以下的 Starter 即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 如果不引入 SOFABoot 的健康检查扩展，用户依然可以直接依赖 HealthIndicator 接口进行原生的 Spring Boot Actuator 的 Liveness Check。\n安全提醒 从 SOFABoot 2.3.0 开始，由于健康检查能力依赖于 SpringBoot 1.4.x 里的 Actuator 组件，而 Actuator 会默认开启很多 EndPoint，例如 /dump，/trace 等等，可能存在安全风险，可以参照官方文档里的安全建议进行设置。\n SpringBoot 1.5.x 和 SpringBoot 2.x 已修复了部分安全行为，SOFABoot 将通过升级 SpringBoot 内核进行支持。\n 查看健康检查结果 加入健康检查扩展之后，我们可以直接在浏览器中输入 http://localhost:8080/health/readiness 来查看 Readiness Check 的结果。如果要查看 Liveness Check 的结果，可以直接查看 Spring Boot 的健康检查的 URL http://localhost:8080/health。\n除了通过 URL 来查看健康检查的结果之外，在 SOFABoot 中，还可以通过查看具体的日志来确定健康检查的结果，日志的目录位于 health-check 目录下，日志的内容大概如下：\n2018-04-06 23:29:50,240 INFO main - Readiness check result: success 目前 SOFA 中间件已经通过 SOFABoot 的 Readiness Check 的能力来控制了上游流量的进入，但是一个应用的流量可能并不是全部都是从中间件进入的，比较常见的还有从负载均衡器进入的，为了控制从负载均衡器进入的流量，建议使用者通过 PAAS 来访问 Readiness Check 的结果，根据结果来控制是否要在负载均衡器中上线对应的节点。\n注: 自 SOFABoot 2.x 之后，不再间接引入 spring-boot-starter-web 依赖，如果需要在浏览器中查看健康检查结果，需要额外在工程中引入 web 容器依赖。\n注: 在 SOFABoot 3.x 中调整了 endpoint 路径，health/readiness 更改为 actuator/readiness\n扩展 Readiness Check 能力 在 Readiness Check 的各个阶段，SOFABoot 都提供了扩展的能力，应用可以根据自己的需要进行扩展，在 2.x 版本中，可供扩展的点如下：\n 回调接口 说明 org.springframework.context.ApplicationListener 如果想要在 Readiness Check 之前做一些事情，那么监听这个 Listener 的 SofaBootBeforeHealthCheckEvent 事件。 org.springframework.boot.actuate.health.HealthIndicator 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 com.alipay.sofa.healthcheck.startup.SofaBootAfterReadinessCheckCallback 如果想要在 Readiness Check 之后做一些事情，那么可以扩展 SOFABoot 的这个接口。 在 3.x 版本中，可供扩展点如下：\n 回调接口 说明 com.alipay.sofa.healthcheck.core.HealthChecker 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，可以直接扩展该接口。相较于 Spring Boot 本身的 HealthIndicator 接口，该接口提供了一些额外的参数配置，比如检查失败重试次数等。 org.springframework.boot.actuate.health.HealthIndicator 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 org.springframework.boot.actuate.health.ReactiveHealthIndicator 在 WebFlux 中，如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 com.alipay.sofa.healthcheck.startup.ReadinessCheckCallback 如果想要在 Readiness Check 之后做一些事情，那么可以扩展 SOFABoot 的这个接口。 需要指出的是，上述四个扩展接口均可以通过 Spring Boot 标准的 Ordered, PriorityOrdered 和注解 @Order 实现执行顺序的设置。\nReadiness Check 配置项 应用在引入 SOFABoot 的健康检查扩展之后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 Readiness Check 的相关行为。\n Readiness Check 配置项 说明 默认值 开始支持版本 com.alipay.sofa.healthcheck.skip.all 是否跳过整个 Readiness Check 阶段 false 2.4.0 com.alipay.sofa.healthcheck.skip.component 是否跳过 SOFA 中间件的 Readiness Check false 2.4.0 com.alipay.sofa.healthcheck.skip.indicator 是否跳过 HealthIndicator 的 Readiness Check false 2.4.0 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/health-check/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a366b25125fa4aedb08a9cef572db1c8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/health-check/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/health-check/","summary":"SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 的能力。如果你需要使用 SOFA 中间件，那么建议使用 SOFABoot 的健康检查能力的扩展，来更优雅的上线应用实例 引入健康检查扩展 要","tags":null,"title":"健康检查","type":"projects","url":"/sofastack.tech/projects/sofa-boot/health-check/","wordcount":1269},{"author":null,"categories":null,"content":" 目前默认生效的的扩展模块是：lookout-ext-jvm，lookout-ext-os(from v1.5.0)。\n JVM 线程 metric name metric tags specification jvm.threads.totalStarted \u0026amp;mdash; jvm.threads.active \u0026amp;mdash; jvm.threads.peak \u0026amp;mdash; jvm.threads.daemon \u0026amp;mdash; JVM 类加载 metric name metric tags specification jvm.classes.unloaded \u0026amp;mdash; jvm.classes.loaded \u0026amp;mdash; jvm.classes.total \u0026amp;mdash; JVM 内存 metric name metric tags specification jvm.memory.heap.init \u0026amp;mdash; jvm.memory.heap.used \u0026amp;mdash; jvm.memory.heap.max \u0026amp;mdash; jvm.memory.heap.committed \u0026amp;mdash; JVM 垃圾回收 metric name metric tags specification jvm.gc.young.time \u0026amp;mdash; jvm.gc.young.count \u0026amp;mdash; jvm.gc.old.time \u0026amp;mdash; jvm.gc.old.count \u0026amp;mdash; 机器文件系统信息 metric name metric tags specification instance.file.system.free.space root（文件系统根目录名） \u0026amp;mdash; instance.file.system.total.space root \u0026amp;mdash; instance.file.system.usabe.space root \u0026amp;mdash; 机器信息 metric name metric tags specification instance.mem.free \u0026amp;mdash; instance.mem.total \u0026amp;mdash; instance.processors \u0026amp;mdash; instance.uptime \u0026amp;mdash; instance.systemload.average \u0026amp;mdash; Linux 操作系统信息 （1.5.0版本之后默认启用） metric name metric tags specification os.systemload.average.1min \u0026amp;mdash; os.systemload.average.5min \u0026amp;mdash; os.systemload.average.15min \u0026amp;mdash; os.cpu.idle \u0026amp;mdash; os.cpu.iowait \u0026amp;mdash; os.cpu.irq \u0026amp;mdash; os.cpu.nice \u0026amp;mdash; os.cpu.softirq \u0026amp;mdash; os.cpu.system \u0026amp;mdash; os.cpu.user \u0026amp;mdash; os.disk.usage.percent.used device,root,type \u0026amp;mdash; os.disk.usage.total.bytes device,root,type \u0026amp;mdash; os.disk.usage.used.bytes device,root,type \u0026amp;mdash; os.net.stats.in.bytes intfc \u0026amp;mdash; os.net.stats.in.compressed intfc \u0026amp;mdash; os.net.stats.in.dropped intfc \u0026amp;mdash; os.net.stats.in.errs intfc \u0026amp;mdash; os.net.stats.in.fifo.errs intfc \u0026amp;mdash; os.net.stats.in.frame.errs intfc \u0026amp;mdash; os.net.stats.in.multicast intfc \u0026amp;mdash; os.net.stats.in.packets intfc \u0026amp;mdash; os.net.stats.out.bytes intfc \u0026amp;mdash; os.net.stats.out.carrier.errs intfc \u0026amp;mdash; os.net.stats.out.collisions intfc \u0026amp;mdash; os.net.stats.out.compressed intfc \u0026amp;mdash; os.net.stats.out.dropped intfc \u0026amp;mdash; os.net.stats.out.errs intfc \u0026amp;mdash; os.net.stats.out.fifo.errs intfc \u0026amp;mdash; os.net.stats.out.packets intfc \u0026amp;mdash; os.memory.stats.buffers.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.cached.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.free.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.total.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-ext-metrics/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c8a4fb3d904e359e99db9d4e81e60812","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","summary":"目前默认生效的的扩展模块是：lookout-ext-jvm，lookout-ext-os(from v1.5.0)。 JVM 线程 metric name metric tags specification jvm.threads.totalStarted \u0026mdash; jvm.threads.active \u0026mdash; jvm.threads.peak","tags":null,"title":"内置扩展 Metrics 指标","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","wordcount":296},{"author":null,"categories":null,"content":" 分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等） Zab：被应用在 zookeeper 中，业界使用广泛，但没有抽象成通用的 library Raft：以容易理解著称，业界也涌现出很多 raft 实现，比如大名鼎鼎的 etcd, braft, tikv 等 什么是 Raft？ Raft 是一种更易于理解的分布式共识算法，核心协议本质上还是师承 paxos 的精髓，不同的是依靠 raft 模块化的拆分以及更加简化的设计，raft 协议相对更容易实现。\n模块化的拆分主要体现在：Raft 把一致性协议划分为 Leader 选举、MemberShip 变更、日志复制、Snapshot 等几个几乎完全解耦的模块\n更加简化的设计则体现在：Raft 不允许类似 paxos 中的乱序提交、简化系统中的角色状态（只有 Leader、Follower、Candidate三种角色）、限制仅 Leader 可写入、使用随机化的超时时间来设计 Leader Election 等等\n特点：Strong Leader 系统中必须存在且同一时刻只能有一个 leader，只有 leader 可以接受 clients 发过来的请求 Leader 负责主动与所有 followers 通信，负责将\u0026amp;rsquo;提案\u0026amp;rsquo;发送给所有 followers，同时收集多数派的 followers 应答 Leader 还需向所有 followers 主动发送心跳维持领导地位(保持存在感) 一句话总结 Strong Leader: \u0026amp;ldquo;你们不要 BB! 按我说的做，做完了向我汇报!\u0026amp;rdquo; 另外，身为 leader 必须保持一直 BB(heartbeat) 的状态，否则就会有别人跳出来想要 BB\n复制状态机 对于一个无限增长的序列 a[1, 2, 3…]，如果对于任意整数 i，a[i] 的值满足分布式一致性，这个系统就满足一致性状态机的要求 基本上所有的真实系统都会有源源不断的操作，这时候单独对某个特定的值达成一致显然是不够的。为了让真实系统保证所有的副本的一致性，通常会把操作转化为 write-ahead-log(WAL)。然后让系统中所有副本对 WAL 保持一致，这样每个副本按照顺序执行 WAL 里的操作，就能保证最终的状态是一致的\n Client 向 leader 发送写请求 Leader 把\u0026amp;rsquo;操作\u0026amp;rsquo;转化为 WAL 写本地 log 的同时也将 log 复制到所有 followers Leader 收到多数派应答, 将 log 对应的\u0026amp;rsquo;操作\u0026amp;rsquo; 应用到状态机 回复 client 处理结果 Raft 中的基本概念 Raft-node 的 3 种角色/状态 Follower：完全被动，不能发送任何请求，只接受并响应来自 leader 和 candidate 的 message，每个节点启动后的初始状态一定是 follower Leader：处理所有来自客户端的请求，以及复制 log 到所有 followers Candidate：用来竞选一个新 leader （candidate 由 follower 触发超时而来） Message 的 3 种类型 RequestVote RPC：由 candidate 发出，用于发送投票请求 AppendEntries (Heartbeat) RPC：由 leader 发出，用于 leader 向 followers 复制日志条目，也会用作 Heartbeat （日志条目为空即为 Heartbeat） InstallSnapshot RPC：由 leader 发出，用于快照传输，虽然多数情况都是每个服务器独立创建快照，但是leader 有时候必须发送快照给一些落后太多的 follower，这通常发生在 leader 已经丢弃了下一条要发给该follower 的日志条目(Log Compaction 时清除掉了) 的情况下 任期逻辑时钟 时间被划分为一个个任期 (term)，term id 按时间轴单调递增 每一个任期的开始都是 leader 选举，选举成功之后，leader 在任期内管理整个集群，也就是 \u0026amp;lsquo;选举 + 常规操作\u0026amp;rsquo; 每个任期最多一个 leader，可能没有 leader (spilt-vote 导致) Raft 功能分解 Leader 选举 超时驱动：Heartbeat/Election timeout 随机的超时时间：降低选举碰撞导致选票被瓜分的概率 选举流程： Follower \u0026amp;ndash;\u0026amp;gt; Candidate (选举超时触发) 赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Leader 另一个节点赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Follower 一段时间内没有任何节点器赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Candidate 选举动作： Current term++ 发送 RequestVote RPC New Leader 选取原则 (最大提交原则) Candidates include log info in RequestVote RPCs(index \u0026amp;amp; term of last log entry) During elections, choose candidate with log most likely to contain all committed entries Voting server V denies vote if its log is “more complete”: (lastTermV \u0026amp;gt; lastTermC) || ((lastTermV == lastTermC) \u0026amp;amp;\u0026amp;amp; (lastIndexV \u0026amp;gt; lastIndexC)) Leader will have “most complete” log among electing majority 安全性：一个 term，最多选出一个 leader，可以没 leader，下一个 term 再选 影响 raft 选举成功率的几个时间参数： RTT(Round Trip Time)：网络延时 Heartbeat timeout：心跳间隔，通常应该比 election timeout 小一个数量级，目的是让 leader 能够持续发送心跳来阻止 followers 触发选举 Election timeout：Leader 与 followers …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/consistency-raft-jraft/","fuzzywordcount":8000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a0e98df1bec305cca7db6fc34fc97771","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":16,"relpermalink":"/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","summary":"分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? P","tags":null,"title":"分布式一致性 Raft 与 JRaft","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","wordcount":7950},{"author":"林楠","categories":"SOFAStack","content":" 前言 在实践中，我们通常会使用业务功能模块化的开发模式，部署时将不同模块合并部署，由于团队间技术栈不统一，此时就有可能出现依赖冲突等问题。SOFAArk 定义了一种开发规范，将不同的应用模块打包成 Ark Biz，由一个基座 Biz 和多个 Biz 模块组成部署包，支持两种合并部署的方式，一种是静态合并部署，Ark Biz 以 Maven 依赖的方式引入项目；另一种是在运行时使用 API 或者 配置中心（Zookeeper）动态地安装或卸载 Biz，本文将重点讨论此方式。\nArk Biz 的生命周期 Ark Biz 的生命周期主要包含三条指令：\n install: 安装 Biz uninstall: 卸载 Biz switch: 激活 Biz 在动态的安装和卸载时，Ark Biz 会流转于生命周期的五个阶段，Biz 在不同阶段时的状态如下：\n unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时 Biz 包还没有安装或者安装中 activated: Biz 包启动完成，且处于激活状态，可以对外提供服务 broken: Biz 包启动失败后状态 deactivated: Biz 包启动完成，但处于未激活状态(注意这个状态只对 JVM 服务生效，对 RPC 等其他中间件无效) 这里我们可以看一下 Ark Biz 的数据模型 BizModel 类：\npublic class BizModel implements Biz { ... private String bizName; private String bizVersion; private BizState bizState; ... } 在 Ark Biz 的数据模型中 bizState 表示的就是当前状态，可以看到数据模型中定义了 Biz 包的名称和版本号，在运行时 SOFAArk 允许部署相同名称不同版本的 Biz，但只能有一个版本处于 activated 激活状态，其他版本的 Biz 状态将自动处于 deactivated 未激活状态。\ninstall 在入口方法 ArkClient#installOperation 中，下载 Biz 包到本地临时文件，临时文件命名规则：${bizName}-${bizVersion}-${时间戳}。准备好 Biz 包后，调用 installBiz 方法，进入安装主流程。\npublic static ClientResponse installOperation(BizOperation bizOperation) throws Throwable { return installOperation(bizOperation, arguments); } public static ClientResponse installOperation(BizOperation bizOperation, String[] args) throws Throwable { ... if (bizOperation.getParameters().get(Constants.CONFIG_BIZ_URL) != null) { URL url = new URL(bizOperation.getParameters().get(Constants.CONFIG_BIZ_URL)); bizFile = ArkClient.createBizSaveFile(bizOperation.getBizName(), bizOperation.getBizVersion()); FileUtils.copyInputStreamToFile(url.openStream(), bizFile); } return installBiz(bizFile, args); } 安装 Ark Biz 的主流程：\n 解析 Biz 包，创建 BizModel 将 Ark Biz 注册到 Biz Manager 中（如果已经注册过，安装流程将直接结束，并返回提示信息） 启动 Ark Biz 如果启动失败，则关停并卸载 Ark Biz public static ClientResponse installBiz(File bizFile, String[] args) throws Throwable { ... Biz biz = bizFactoryService.createBiz(bizFile); // 1 ClientResponse response = new ClientResponse(); if (bizManagerService.getBizByIdentity(biz.getIdentity()) != null || !bizManagerService.registerBiz(biz)) { // 2 return response.setCode(ResponseCode.REPEAT_BIZ).setMessage( String.format(\u0026amp;quot;Biz: %s has been installed or registered.\u0026amp;quot;, biz.getIdentity())); } try { biz.start(args); // 3 ... response .setCode(ResponseCode.SUCCESS) .setMessage( String.format(\u0026amp;quot;Install Biz: %s success, cost: %s ms, started at: %s\u0026amp;quot;, biz.getIdentity(), end - start, startDate)) .setBizInfos(Collections.\u0026amp;lt;BizInfo\u0026amp;gt; singleton(biz)); return response; } catch (Throwable throwable) { ... response.setCode(ResponseCode.FAILED).setMessage( String.format(\u0026amp;quot;Install Biz: %s fail,cost: %s ms, started at: %s\u0026amp;quot;, biz.getIdentity(), end - start, startDate)); ... try { biz.stop(); // 4 } catch (Throwable e) { ... throw e; } finally { bizManagerService.unRegisterBizStrictly(biz.getBizName(), biz.getBizVersion()); } return response; } } 解析 Ark Biz 当开启内嵌模式时，将 Biz 包解压到 ${Biz}-unpack 目录下，生成展开型的 Biz 包；当未开启内嵌模式时，直接使用原始的 Biz Jar 包，生成压缩型的 Biz …","date":-62135596800,"description":"源码解析 | 动态部署","dir":"projects/sofa-boot/sofa-ark-dynamic-deploy/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"49b198c473b8ee5d8de18d8260661df6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","summary":"前言 在实践中，我们通常会使用业务功能模块化的开发模式，部署时将不同模块合并部署，由于团队间技术栈不统一，此时就有可能出现依赖冲突等问题。SO","tags":["源码解析"],"title":"动态部署","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","wordcount":3759},{"author":null,"categories":null,"content":" 单元测试 单元测试例子放到自己开发的模块下。\n如果依赖了第三方服务端（例如Zookeeper），请手动加入 profile。参考 registry-zookeeper 模块代码。\n如果依赖了其它模块要集成测试，请放到 test/test-intergrated 模块中。\n如果还依赖了第三方服务端（例如Zookeeper），请放到 test-intergrated-3rd 模块中。\n性能测试 关闭了以下默认开启项目：\n-Dcontext.attachment.enable=false -Dserialize.blacklist.enable=false -Ddefault.tracer= -Dlogger.impl=com.alipay.sofa.rpc.log.SLF4JLoggerImpl -Dmultiple.classloader.enable=false -Devent.bus.enable=false\n我们对 BOLT+hessian 进行了压测。\n服务端：4C8G 虚拟机，千M网络，jdk1.8.0_111；\n客户端：50个客户端并发请求。\n 协议 请求 响应 服务端 TPS 平均RT(ms) bolt+hessian 1K String 1K String 直接返回 10000 1.93 bolt+hessian 1K String 1K String 直接返回 20000 4.13 bolt+hessian 1K String 1K String 直接返回 30000 7.32 bolt+hessian 1K String 1K String 直接返回 40000 15.78 bolt+hessian 1K String 1K String 直接返回 50000(接近极限,错误率0.3%） 26.51 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/test/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ccda7c2372a7f55d61f682b72d3b1dc2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/test/","summary":"单元测试 单元测试例子放到自己开发的模块下。 如果依赖了第三方服务端（例如Zookeeper），请手动加入 profile。参考 registry-zookeeper 模块代码。 如果依","tags":null,"title":"单元测试与性能测试","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/test/","wordcount":292},{"author":null,"categories":null,"content":" 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git 官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git 协作流程 GitHub 贡献代码流程 提交 issue 不论您是修复 ACTS 的 bug 还是新增 ACTS 的功能，在您提交代码之前，在 ACTS 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. ACTS 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 ACTS 主干代码到您的代码仓库。\n拉分支 ACTS 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式.\ngit clone https://github.com/您的账号名/acts.git 拉分支准备修改代码\ngit branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n 修改完代码后，执行如下命令提交所有修改到本地\ngit commit -am \u0026#39;添加xx功能\u0026#39; 修改代码注意事项 代码风格保持一致 ACTS 通过 Maven 插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码\n 新有修改应该通过已有的单元测试.\n 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\nmvn clean test 也可以通过 IDE 来辅助运行。\n 其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。 * 执行如下命令提交本地修改到 github 上\n``` git push origin \u0026amp;quot;branchname\u0026amp;quot; ``` 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 ACTS 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 ACTS 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 ACTS 的人员， ACTS 人员会 Review 您的代码，符合要求后就会合入主干，成为 ACTS 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 ACTS 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/contributing/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cd68baede6258921f83665ef0a446f1f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/contributing/","summary":"准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git 官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章G","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-acts/contributing/","wordcount":1224},{"author":null,"categories":null,"content":" 可以先去 发展路线 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看 git官方书籍，需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程。 GitHub 贡献代码流程 提交issue 不论您是修复 SOFAArk 的 bug 还是新增 SOFAArk 的功能，在您提交代码之前，在 SOFAArk 的 GitHub 地址上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFAArk 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的fork按钮，复制一份 SOFAArk 主干代码到您的代码仓库。\n拉分支 SOFAArk 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择git/https方式.\ngit clone https://github.com/您的账号名/sofa-ark.git 拉分支准备修改代码\ngit branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\n git branch -a 如果您想切换回主干，执行下面命令:\n git checkout -b master 如果您想切换回分支，执行下面命令：\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFAArk 通过 Maven 插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\n mvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\n git commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFAArk 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFAArk 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFAArk 的人员， SOFAArk 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFAArk 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFAArk 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-contribution/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dbf77f98884a71c5c7a3fbb4dd189cfe","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","summary":"可以先去 发展路线 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看 git官方书籍，需要阅","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","wordcount":1278},{"author":null,"categories":null,"content":" 可以先去 RoadMap 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看 git官方书籍，需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFADashboard 的 bug 还是新增 SOFADashboard 的功能，在您提交代码之前，在 SOFADashboard 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。\n这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFADashboard 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFADashboard 主干代码到您的代码仓库。\n拉分支 SOFADashboard 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式.\ngit clone https://github.com/您的账号名/sofa-dashboard.git 拉分支准备修改代码 bash git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令: bash git checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFADashboard 通过 Maven插件来保持代码格式一致。在提交代码前，务必本地执行\nmvn clean compile 补充单元测试代码\n 新有修改应该通过已有的单元测试.\n 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug\n您可以用如下命令运行所有测试\nmvn clean test 也可以通过 IDE 来辅助运行。 其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地：\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFADashboard 的代码仓库。\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFADashboard 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFADashboard 的人员， SOFADashboard 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFADashboard 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。 对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFADashboard 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/contribution/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"584584be9c13f2d36c85890dd192368a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/contribution/","summary":"可以先去 RoadMap 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看 git官方书籍，需要阅读前几","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/contribution/","wordcount":1262},{"author":null,"categories":null,"content":" 可以先去 发展路线 \u0026amp;amp; 任务认领 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFARegistry 的 bug 还是新增 SOFARegistry 的功能，在您提交代码之前，在 SOFARegistry 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFARegistry 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFARegistry 主干代码到您的代码仓库。\n拉分支 SOFARegistry 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式. git clone https://github.com/您的账号名/sofa-registry.git 拉分支准备修改代码 git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFARegistry 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug您可以用如下命令运行所有测试 mvn clean test 也可以通过 IDE 来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFARegistry 的代码仓库.\n提交合并代码到主干的请求 在您的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFARegistry 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request 按钮。选择目标分支,一般就是 master，系统会通知 SOFARegistry 的人员， SOFARegistry 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFARegistry 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFARegistry 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/contributing/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c08b5945719137833634c111c43a8d9e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/contributing/","summary":"可以先去 发展路线 \u0026amp; 任务认领 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git官方书","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-registry/contributing/","wordcount":1264},{"author":null,"categories":null,"content":" 可以先去 发展路线 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFARPC 的 bug 还是新增 SOFARPC 的功能，在您提交代码之前，在 SOFARPC 的GitHub上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFARPC 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的fork按钮，复制一份 SOFARPC 主干代码到您的代码仓库。\n拉分支 SOFARPC 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择git/https方式. git clone https://github.com/您的账号名/sofa-rpc.git 在提交pull request请求前, 请将您克隆的代码和远程代码库同步，这样您的pull request会简单清晰 git remote add upstream git@github.com:sofastack/sofa-rpc.git git fetch upstream git rebase upstream/master 拉分支准备修改代码 git checkout -b add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFARPC 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\nmvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFARPC 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFARPC 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFARPC 的人员， SOFARPC 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFARPC 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFARPC 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/contributing/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"448a7b9a949bd2d9e2e71ac6c237f9df","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/contributing/","summary":"可以先去 发展路线 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git官方书籍,需要阅","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/contributing/","wordcount":1351},{"author":null,"categories":null,"content":" 客户端发展规划 v2.0 ，在基于 Java 8 进行重构，v1.0 为支持 Java 6 做了些设计与性能妥协； 集成更多的开源产品； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/plan/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6153fc1f5e000f195d96dfdb03c5b381","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/plan/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/plan/","summary":"客户端发展规划 v2.0 ，在基于 Java 8 进行重构，v1.0 为支持 Java 6 做了些设计与性能妥协； 集成更多的开源产品；","tags":null,"title":"发展规划","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/plan/","wordcount":49},{"author":null,"categories":null,"content":" 任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 代码 支持多个 Web 应用合并部署，采用多 Host/单 Host 两种模式 难 代码 支持 telnet 指令查看 ark plugin 简单 代码 支持 telnet 指令查看 jvm/rpc 服务 中 版本迭代计划 v0.5.0 支持多个 Web 应用合并部署，采用多 Host/单 Host 两种模式 v0.6.0 支持 telnet 指令查看 ark plugin； 支持 telnet 指令查看 jvm/rpc 服务； ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-roadmap/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c4532d11cef15d8fe3ff5e04c7b08f90","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","summary":"任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 代码 支持多个 Web 应用合","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","wordcount":175},{"author":null,"categories":null,"content":" 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。\n如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关Issue 文档 文档翻译 低 代码 弹性长连接管理方式 低 #56 代码 etcd注册中心实现 中 @wynn5a\n2018-6 #153 代码 eureka注册中心实现 中 @liufeiit\n2018-4 #52 代码 gRPC 支持 高 #57 代码 CXF 协议 高 #58 代码 TLS 支持 高 版本迭代计划 v5.5.0 JSON 序列化支持 H2的TLS安全支持 弹性连接池 hystrix集成 Consul注册中心支持 v5.6.0 grpc 通讯层支持 etcd注册中心支持 SofaMesh支持 BOLT 版本协商与 CRC 校验 v5.7.0 Telnet 内置指令支持 SpringBoot 2.0 支持 Mock功能支持 加密功能支持 v5.8.0 授权支持 SofaRegistry 支持 Reactive 支持 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/roadmap/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6064fc180911f520f6d1590b88595693","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/roadmap/","summary":"任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。 如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。 类型","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/roadmap/","wordcount":292},{"author":null,"categories":null,"content":" 任务列表 欢迎大家领取任务参与贡献。\n 类型 任务 困难度 认领人及时间 计划发布时间 计划完成时间 进度 相关 issue 代码 SOFATracer 性能优化专题 高 issue 18和 issue 11 代码 SOFATracer 支持 HttpClient 中 已经完成，见 HttpClient 接入文档 代码 SOFATracer 数据汇报能力提供在非 SOFABoot 框架下的运行和配置能力 中 已经完成，见 Spring 工程中使用 SOFATracer issue 32 代码 SOFATracer 提供采样能力 中 已经完成，见使用 SOFATracer 的采样能力 issue 10 代码 SOFATracer 支持 Zipkin 2.X.X 版本 中 已经完成，见使用 SOFATracer 远程汇报数据到 Zipkin issue 23 代码 SOFATracer 支持 Druid 中 已经完成，见 DataSource 接入文档 代码 SOFATracer 支持 c3p0 中 已经完成 代码 SOFATracer 支持 Tomcat-JDBC 中 已经完成 代码 SOFATracer 支持 HikariCP 中 已经完成 代码 SOFATracer 支持 dbcp 中 已经完成，见 DataSource 接入文档 代码 SOFATracer 支持 dbcp2 中 已经完成 代码 SOFATracer 支持 Sharding-JDBC 中 代码 SOFATracer 支持 Mysql JDBC Driver 中 代码 SOFATracer 支持 Oracle JDBC Driver 中 代码 SOFATracer 支持 Dubbo 中 代码 SOFATracer 支持 RestTemplate 和 AsyncRestTemplate 中 已经完成 代码 SOFATracer 支持标准Servlet 中 已经完成，见对于标准 servlet 容器的支持（ tomcat/jetty 等） 代码 SOFATracer 支持单机版链路分析并给用户通过注解使用的埋点方式，数据汇报到 Zipkin 中 代码 SOFATracer 支持 Kafka 中 代码 SOFATracer 支持 Redis 中 代码 SOFATracer 支持 hystrix 中 文档 文档翻译 中 版本迭代计划 2.2.0 SOFATracer 支持 JDBC 数据源 SOFATracer 支持 Mysql Driver SOFATracer 支持 Sharding-JDBC SOFATracer 支持 Mysql-JDBC SOFATracer 支持 Druid SOFATracer 支持 c3p0 SOFATracer 支持 Tomcat-JDBC SOFATracer 支持 HikariCP SOFATracer 支持 HttpClient SOFATracer 支持 Zipkin 2.X.X 版本，开发验证并测试 2.3.0 SOFATracer 支持RestTemplate 和 AsyncRestTemplate SOFATracer 支持提供采样能力 SOFATracer 支持标准 servlet 容器 SOFATracer 支持 Zipkin UI 中文界面 SOFATracer 支持数据汇报能力提供在非 SOFABoot 框架下的运行和配置能力 2.4.0 SOFATracer 支持 Dubbo SOFATracer 支持 Kafka SOFATracer 性能优化专题 2.5.0 SOFATracer 支持单机版链路分析并给用户通过注解使用的埋点方式，数据汇报到 Zipkin 展示 SOFATracer 支持 manual report SOFATracer 支持 基于 Opentracing API 埋点方式 SOFATracer 支持 Opentracing 0.30.0+ 版本 ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/roadmap/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8b0a6fbe5f6ea5ae789f5186271073c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/roadmap/","summary":"任务列表 欢迎大家领取任务参与贡献。 类型 任务 困难度 认领人及时间 计划发布时间 计划完成时间 进度 相关 issue 代码 SOFATracer 性能优化专题 高 issue 18和 issue 11 代码 SOFATracer 支持 HttpClient 中","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/roadmap/","wordcount":605},{"author":null,"categories":null,"content":" 发展路线 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。\n如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关issue 文档 文档翻译 低 代码 支持Spring Cloud 中 代码 数据自检 高 代码 黑名单过滤 中 代码 SOFARegistry Dashboard 高 代码 支持其他微服务框架 中 代码 支持 Docker \u0026amp;amp; Kubernetes 高 代码 多语言客户端支持 高 版本迭代计划 v5.3.0 支持 Spring Cloud 数据自检 黑名单过滤 v5.4.0 SOFARegistry Dashboard 支持其他微服务框架 v5.5.0 支持 Docker \u0026amp;amp; Kubernetes 多语言客户端支持 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/roadmap/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b0ab45d52ba3eb7db590a4f5e4197c9e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/roadmap/","summary":"发展路线 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。 如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡","tags":null,"title":"发展路线 \u0026 任务认领","type":"projects","url":"/sofastack.tech/projects/sofa-registry/roadmap/","wordcount":216},{"author":null,"categories":null,"content":"更多参见：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md\n","date":-62135596800,"description":"","dir":"projects/mosn/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"62efb8e40401ab4612bcccaa6e942c97","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/release-notes/","summary":"更多参见：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md","tags":null,"title":"发布历史","type":"projects","url":"/sofastack.tech/projects/mosn/release-notes/","wordcount":61},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-rpc/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ab7d46caa6906863103b77b742ec7e84","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/release-notes/","summary":"更多参见：https://github.com/sofastack/sofa-rpc/releases","tags":null,"title":"发布历史","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/release-notes/","wordcount":51},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-ark/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-release/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"994c3569ea416ee5b0dea253f08af6be","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-release/","summary":"更多参见：https://github.com/sofastack/sofa-ark/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-release/","wordcount":51},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-dashboard/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/release-node/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3c8e6985123810c9692f47cc56b50081","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/release-node/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/release-node/","summary":"更多参见：https://github.com/sofastack/sofa-dashboard/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/release-node/","wordcount":57},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-registry/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d92dddf77bbbd6078f3f96ba2224a53d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/release-notes/","summary":"更多参见：https://github.com/sofastack/sofa-registry/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-registry/release-notes/","wordcount":56},{"author":null,"categories":null,"content":" SOFABoot 提供了模块并行加载以及 Spring Bean 异步初始化能力，用于加快应用启动速度。模块并行加载参考相应文档，下面介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力来提高应用启动速度。\n引入依赖 SOFABoot 在 v2.6.0 开始提供异步初始化 Spring Bean 能力，引入如下 Starter 即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 使用场景 在实际使用 Spring/Spring Boot 开发中，会有一些 Bean 在初始化过程中执行准备操作，如拉取远程配置、初始化数据源等等；在应用启动期间，这类 Bean 会增加 Spring 上下文刷新时间，导致应用启动耗时变长。为了加速应用启动，SOFABoot 通过配置可选项，将 Bean 的初始化方法(init-method) 使用单独线程异步执行，加快 Spring 上下文加载过程，提高应用启动速度。\n使用方法 异步初始化 Bean 的原理是开启单独线程负责执行 Bean 的初始化方法(init-method)，因此在使用过程中，除了引入上述依赖管理，还需要在 Bean 的 xml 定义中配置 sofa:async-init=\u0026amp;quot;true\u0026amp;quot; 属性，用于指定是否异步执行该 Bean 的初始化方法，例如：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- async init test --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBean\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.beans.TimeWasteBean\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot; sofa:async-init=\u0026amp;quot;true\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 配置 SOFABoot 异步初始化能力提供两个属性配置，用于指定负责异步执行 Bean 初始化方法(init-method)的线程池大小： + com.alipay.sofa.boot.asyncInitBeanCoreSize \u0026amp;gt; 线程池基本大小，默认值为 CPU 核数加一 + com.alipay.sofa.boot.asyncInitBeanMaxSize \u0026amp;gt; 线程池中允许的最大线程数大小，默认值为 CPU 核数加一\n配置可以通过 VM -D 参数或者 Spring Boot 配置文件 application.yml 设置。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/speed-up-startup/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ebd933894c7828948b87610d1d0ca020","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/speed-up-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/speed-up-startup/","summary":"SOFABoot 提供了模块并行加载以及 Spring Bean 异步初始化能力，用于加快应用启动速度。模块并行加载参考相应文档，下面介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力来提高应用启","tags":null,"title":"启动加速","type":"projects","url":"/sofastack.tech/projects/sofa-boot/speed-up-startup/","wordcount":519},{"author":null,"categories":null,"content":" 启动过程 Ark 1.0 非内嵌模式 打包方式 在 SOFAArk 1.0 中使用 sofa-ark-maven-plugin 打包\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 启动流程图 Ark 1.0 应用的整体启动流程如下图所述： 启动方式 方式一、IDEA 启动 使用 idea 启动 SpringBoot Application 即可\n方式二、命令行启动 Ark 包是可执行 Jar，可直接使用 java -jar 的方式启动，先使用 mvn clean package 进行打包，打包得到 ${bizName}-${bizVersion}-executable-ark.jar，命令行启动\njava -jar ${bizName}-${bizVersion}-executable-ark.jar 启动原理分析 Springboot 应用，ArkApplicationStartListener 实现了 ApplicationListener 接口，监听 Spring 的启动事件，调用SofaArkBootstrap.launch(args)启动 Ark。\npublic class ArkApplicationStartListener implements ApplicationListener\u0026amp;lt;SpringApplicationEvent\u0026amp;gt; { @Override public void onApplicationEvent(SpringApplicationEvent event) { try { if (isSpringBoot2() \u0026amp;amp;\u0026amp;amp; APPLICATION_STARTING_EVENT.equals(event.getClass().getCanonicalName())) { startUpArk(event); } if (isSpringBoot1() \u0026amp;amp;\u0026amp;amp; APPLICATION_STARTED_EVENT.equals(event.getClass().getCanonicalName())) { startUpArk(event); } } catch (Throwable e) { throw new RuntimeException(\u0026amp;quot;Meet exception when determine whether to start SOFAArk!\u0026amp;quot;, e); } } public void startUpArk(SpringApplicationEvent event) { if (LAUNCH_CLASSLOADER_NAME.equals(this.getClass().getClassLoader().getClass().getName())) { // Ark 启动入口，非 Springboot 应用需要手动调用该方法 SofaArkBootstrap.launch(event.getArgs()); } } public boolean isSpringBoot1() { return SpringBootVersion.getVersion().startsWith(\u0026amp;quot;1\u0026amp;quot;); } public boolean isSpringBoot2() { return SpringBootVersion.getVersion().startsWith(\u0026amp;quot;2\u0026amp;quot;); } } SofaArkBootstrap launch 方法里面启了一个线程执行SofaArkBootstrap.remain方法，remain 里面调ClasspathLauncher.launch方法。\npublic class SofaArkBootstrap { private static final String BIZ_CLASSLOADER = \u0026amp;quot;com.alipay.sofa.ark.container.service.classloader.BizClassLoader\u0026amp;quot;; private static final String MAIN_ENTRY_NAME = \u0026amp;quot;remain\u0026amp;quot;; private static EntryMethod entryMethod; public static void launch(String[] args) { try { if (!isSofaArkStarted()) { entryMethod = new EntryMethod(Thread.currentThread()); IsolatedThreadGroup threadGroup = new IsolatedThreadGroup( entryMethod.getDeclaringClassName()); // 参数中指定当前类的remain方法，LaunchRunner.run 里面会用反射调用remain方法 LaunchRunner launchRunner = new LaunchRunner(SofaArkBootstrap.class.getName(), MAIN_ENTRY_NAME, args); Thread launchThread = new Thread(threadGroup, launchRunner, entryMethod.getMethodName()); launchThread.start(); // 等待前面的线程 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup-process/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c89b63bd70a937cf29bbf165fda00444","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","publishdate":"0001-01-01T00:00:00Z","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","summary":"启动过程 Ark 1.0 非内嵌模式 打包方式 在 SOFAArk 1.0 中使用 sofa-ark-maven-plugin 打包 \u0026lt;build\u0026gt; \u0026lt;plugins\u0026gt; \u0026lt;plugin\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofa-ark-maven-plugin\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${sofa.ark.version}\u0026lt;/version\u0026gt; \u0026lt;executions\u0026gt; \u0026lt;execution\u0026gt; \u0026lt;id\u0026gt;default-cli\u0026lt;/id\u0026gt; \u0026lt;!--goal executed to generate executable-ark-jar --\u0026gt; \u0026lt;goals\u0026gt; \u0026lt;goal\u0026gt;repackage\u0026lt;/goal\u0026gt; \u0026lt;/goals\u0026gt; \u0026lt;configuration\u0026gt; \u0026lt;outputDirectory\u0026gt;./target\u0026lt;/outputDirectory\u0026gt; \u0026lt;!--default none--\u0026gt; \u0026lt;arkClassifier\u0026gt;executable-ark\u0026lt;/arkClassifier\u0026gt; \u0026lt;/configuration\u0026gt; \u0026lt;/execution\u0026gt; \u0026lt;/executions\u0026gt; \u0026lt;/plugin\u0026gt; \u0026lt;/plugins\u0026gt; \u0026lt;/build\u0026gt; 启动流程图 Ark 1.0 应用的整体启动流程如","tags":null,"title":"启动过程","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","wordcount":4023},{"author":null,"categories":null,"content":" 本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sidecar的部署模式，满足用户的各种需求。\n前置要求 Docker Docker Compose 安装步骤 下载最新的 release 包 解压安装文件，并且进入解压后的路径，安装路径包含： 示例应用路径 samples/ /bin 路径下应该能找到 istioctl 客户端可执行文件，istioctl 可用于创建路由规则和策略 配置文件 istion.VERSION 把 Istio 的 bin 路径添加到系统的 PATH。比如，在 MacOS 或者 Linux 系统下执行如下命令：\nexport PATH=$PWD/bin;$PATH 安装helm 创建命名空间 SHELL kubectl create namespace istio-system 使用helm安装istio CRD\nhelm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - 使用helm安装各个组件 SHELL helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - 确认所有 pod 都在运行中：\nkubectl get pod -n istio-system 如果 Istio pilot 容器意外终止，确保运行 istioctl context-create 命令，并且重新执行上一个命令。\n部署应用程序 现在开始部署 Bookinfo 示例程序 为 default 命名空间打上标签 istio-injection=enabled，实现 Sidecar 自动注入\nkubectl label namespace default istio-injection=enabled 使用 kubectl 部署Bookinfo的服务\nkubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml 确认所有的服务和 Pod 都已经正确的定义和启动\nkubectl get services kubectl get pods 卸载 Istio helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - kubectl delete namespace istio-system ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"1de4868fa0e9c73d932343847864d7fb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","summary":"本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sid","tags":null,"title":"在 Kubernetes 中快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","wordcount":465},{"author":null,"categories":null,"content":" 本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。\nSOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sidecar的部署模式，满足用户的各种需求。\n前置要求 Kubernetes 安装 Helm 安装步骤 Step 1. 下载最新的 release 包 Step 2. 把 Istio 的 bin 路径添加到系统的 PATH。比如，在 Linux 系统下执行如下命令：\nexport PATH=$PWD/bin;$PATH Step 3. 创建命名空间\nkubectl create namespace istio-system Step 4. 使用helm安装istio CRD\nhelm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - Step 5. 使用helm安装各个组件\nhelm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - Step 6. 确认所有 pod 都在运行中\nkubectl get pod -n istio-system 部署应用程序 现在开始部署 Bookinfo 示例程序。\n为 default 命名空间打上标签 istio-injection=enabled，实现 Sidecar 自动注入：\nkubectl label namespace default istio-injection=enabled 使用 kubectl 部署Bookinfo的服务：\nkubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml 确认所有的服务和 Pod 都已经正确的定义和启动：\nkubectl get services kubectl get pods 卸载 Istio helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - kubectl delete namespace istio-system ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/sofa-mesh-setup/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"940d012b4883e5c91bf777916cd3c6b3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","summary":"本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sid","tags":null,"title":"在 Kubernetes 中快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","wordcount":362},{"author":null,"categories":null,"content":" 基于 Serverless 轻松构建云上应用 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。\n作为云原生技术前进方向之一，Serverless 架构让您进一步提高资源利用率，更专注于业务研发。通过我们的 workshop，您 可以体验到快速创建 Serverless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错等产品新功能。\nWorkshop 操作内容 流程图 应用架构图 效果预览 \nStep 0: 前期准备 应用 clone：https://github.com/sofastack-guides/kc-serverless-demo \n讲师演示 \n快速发布后端 Java 应用 选择快速创建 选择 Java Runtime 上传代码包 balance-mng.jar 入口方法可自动识别 端口：8080 创建完成后，复制保存后端服务的地址 查看后端服务计算实例数量：0 快速发布前端 Node JS 应用 选择创建应用服务 创建应用，选择技术栈为 Node JS 上传代码包 prod-stockmng-v1.zip 运行时选择 nodejs-0.0.1.1-pre 入口方法可自动识别 端口： 3000 环境变量设置 BALANCEMNG_URL 为后端服务的地址 \nStep 1: 查看 Serverless 应用服务 访问 Serverless 应用服务地址 https://sas.shared.cloud.alipay.com/ 使用账号，密码登陆 选择 workspace： workspace0【user00-09】 workspace1【user10-19】 \u0026amp;hellip; workspace9【user90-99】 查看前端应用服务：kubectl frontend demo xx【00-99】 查看后端应用服务：kubectl backend demo xx【00-99】 查看目前后端应用的计算实例数量：0 \nStep 2: 查看 0-1 冷启能力 使用 Chrome 浏览器访问前端服务，域名为：*.kevinwang.cc 查看后端服务的计算实例数量的变化 \n讲师演示2 \n创建版本和流量控制 克隆前端应用，并创建新版本 上传代码包 prod-stockmng-v2.zip 配置权重，路由 1:1 访问 V1 和 V2 版本 通过浏览器查看效果 \nStep 3: 查看版本和流量控制 打开前端应用服务 查看当前应用服务的 V1 和 V2 版本，和路由 通过浏览器访问应用查看流控效果 \nStep 4: 时间触发器 创建时间触发器，定时 2 分钟后触发一次 为前端应用配置触发器 在指定时间，通过执行记录查看触发效果 [](https://github.com/sofastack-guides/kc-serverless-demo#step-2-%E6%9F%A5%E7%9C%8B-0-1-%E5%86%B7%E5%90%AF%E8%83%BD%E5%8A%9B) \nStep 5: Log Shell 和计量 打开 Log Shell 选择相应的应用服务，并输入日志地址/关键词 搜索查看应用服务日志，可全屏 打开计量信息 通过计量监控查看实例运行情况 \n讲师演示3 \nM-N 快速伸缩 打开应用服务 查看当前版本的计算实例限额 1-5 / 计算实例数量：目前为 1 开始压测模拟高并发，并同步查看计算示例数变化 快速从 1 变化为 4，演示结束 Step 6:【可选步骤】快速开始+测试执行 按照前文步骤，尝试自己创建一个新的前端应用 测试执行应用服务 快速发布前端 Node JS应用 选择创建应用服务 创建应用，选择技术栈为 Node JS 上传代码包 prod-stockmng-v1.zip 运行时选择 nodejs-0.0.1.1-pre 入口方法可自动识别 端口： 3000 环境变量设置 BALANCEMNG_URL 为后端服务的地址 测试执行应用服务 选择测试执行 触发查看效果 更多 下载本次 Demo 幻灯片 ","date":-62135596800,"description":"使用该指南您可以体验到快速创建 Serveless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错、按时间触发应用等产品新功能。","dir":"guides/kc-serverless-demo/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f355d1b598fed47b730bd74ad25f3683","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-serverless-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/kc-serverless-demo/","summary":"基于 Serverless 轻松构建云上应用 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。 作为云原生技术前进方向之一，Serverless 架构","tags":null,"title":"基于 Serverless 轻松构建云上应用","type":"guides","url":"/sofastack.tech/guides/kc-serverless-demo/","wordcount":1070},{"author":null,"categories":null,"content":" Ark 包 SOFAArk 定义特殊格式的可执行 Jar 包，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark 包；使用命令 java -jar 即可在 SOFAArk 容器之上启动应用；Ark 包 通常包含 Ark Container 、Ark Plugin 依赖（如果有）、合并部署的 Ark Biz （如果有）以及应用自身的 Ark Biz；详情可参考 Ark 包；\nArk Container Ark 容器，Ark Plugin 和 Ark Biz 运行在 SOFAArk 容器之上；容器具备管理多插件、多应用的功能；容器启动成功后，会解析 Ark Plugin 和 Ark Biz 配置，完成隔离加载并按优先级依次启动之；Ark Container 一般不会被用户直接感知，由打包插件 sofa-ark-maven-plugin 自动打入。详情可参考 SOFAArk 容器启动；\nArk Plugin Ark 插件，SOFAArk 定义特殊格式的 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-plugin-maven-plugin 可以将一个或多个普通的 Java Jar 包打包成一个标准格式的 Ark Plugin； Ark Plugin 会包含一份配置文件，通常包括插件类和资源的导入导出配置、插件启动优先级等；运行时，Ark 容器会使用独立的 PluginClassLoader 加载插件，并根据插件配置构建类加载索引表，从而使插件与插件、插件与应用之间相互隔离；详情可参考 Ark Plugin；\nArk Biz Ark 模块，SOFAArk 定义特殊格式的 Fat Jar ，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark Biz 包；作用有二点，一、在 Ark 包 中，作为工程应用模块及其依赖包的组织单元；二、可以被其他应用当成普通 Jar 包依赖，用于在同一个 SOFAArk 容器启动多个 Ark Biz；多个 Ark Biz 共享 Ark Container 和 Ark Plugin ；详情可参考 Ark Biz；\n合并部署 SOFAArk 允许将多个应用（Biz 包）合并打入到 Ark 包中，当启动 Ark 包时，会启动所有应用；也支持在运行时通过 API 或者配置中心（例如 Zookeeper）动态的部署和卸载应用，这些应用同时运行在同一个 JVM 中，由独立的 BizClassLoader 加载，各应用之间通过 SofaService/SofaReference 实现交互，称之为多应用的合并部署。\n宿主应用 宿主应用是相对合并部署而言，在打包 Ark 包时，至少有一个 Biz 包被打入，如果应用引入了其他 Biz 包，则 Ark 包中会存在多个 Biz 包。当只有一个 Biz 包时，默认将其设置为宿主应用；如果存在多个 Biz 包，则需要配置指定宿主应用。宿主应用相对其他 Biz 包最大的不同，即不允许被卸载。\n简单总结下，在 SOFAArk 框架中，应用(配置、源码、依赖)被打包成 Biz 包组织在一起，但是特殊的依赖（Ark Plugin 和其他应用 Biz 包）不会被打入 Biz 包中，Biz 包是不可执行的 Fat Jar; Ark Plugin 是特殊的二方包，可以将多个二方依赖打包成 Plugin，运行时由独立的 PluginClassLoader 加载，根据打包时配置的导出导入资源、类，构建运行时类加载模型；Ark 包是可执行 Fat Jar，一般由 Ark Container、Ark Plugin(0个或多个)、Ark Biz(至少一个)。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-terminology/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b6d0ed10afe9d04bc00307017ffba7c5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","summary":"Ark 包 SOFAArk 定义特殊格式的可执行 Jar 包，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark 包；使用命令 java -jar 即可在 SOFAArk 容器之上启动应用；Ark 包","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","wordcount":1015},{"author":null,"categories":null,"content":" 业界通用术语 术语 说明 服务（Service） 通过网络提供的、具有特定业务逻辑处理能力的软件功能。 服务提供者（Service Provider） 通过网络提供服务的计算机节点。 服务消费者（Service Consumer） 通过网络调用服务的计算机节点。一个计算机节点可以既作为一些服务的提供者，又作为一些服务的消费者。 服务发现（Service Discovery） 服务消费者获取服务提供者的网络地址的过程。 服务注册中心（Service Registry） 一种提供服务发现功能的软件系统，帮助服务消费者获取服务提供者的网络地址。 数据中心（Data Center） 物理位置、供电、网络具备一定独立性的物理区域，通常作为高可用设计的重要考量粒度。一般可认为：同一数据中心内，网络质量较高、网络传输延时较低、同时遇到灾难的概率较大；不同数据中心间，网络质量较低、网络延时较高、同时遇到灾难的概率较小。 SOFARegistry 约定术语 术语 说明 SOFARegistry 蚂蚁金服开源的一款服务注册中心产品，基于“发布-订阅”模式实现服务发现功能。同时它并不假定总是用于服务发现，也可用于其他更一般的“发布-订阅”场景。 数据（Data） 在服务发现场景下，特指服务提供者的网络地址及其它附加信息。其他场景下，也可以表示任意发布到 SOFARegistry 的信息。 单元（Zone） 单元化架构关键概念，在服务发现场景下，单元是一组发布与订阅的集合，发布及订阅服务时需指定单元名，更多内容可参考异地多活单元化架构解决方案。 发布者（Publisher） 发布数据到 SOFARegistry 的节点。在服务发现场景下，服务提供者就是“服务提供者的网络地址及其它附加信息”的发布者。 订阅者（Subscriber） 从 SOFARegistry 订阅数据的节点。在服务发现场景下，服务消费者就是“服务提供者的网络地址及其它附加信息”的订阅者。 数据标识（DataId） 用来标识数据的字符串。在服务发现场景下，通常由服务接口名、协议、版本号等信息组成，作为服务的标识。 分组标识（GroupId） 用于为数据归类的字符串，可以作为数据标识的命名空间，即只有 DataId、GroupId、InstanceId 都相同的服务，才属于同一服务。 实例 ID（InstanceId） 实例 ID，可以作为数据标识的命名空间，即只有DataId、GroupId、InstanceId都相同的服务，才属于同一服务。 会话服务器（SessionServer） SOFARegistry 内部负责跟客户端建立 TCP 长连接、进行数据交互的一种服务器角色。 数据服务器（DataServer） SOFARegistry 内部负责数据存储的一种服务器角色。 元信息服务器（MetaServer） SOFARegistry 内部基于 Raft 协议，负责集群内一致性协调的一种服务器角色。 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/terminology/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b678a49547c55f2a70e2d94dbce5b4a2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/terminology/","summary":"业界通用术语 术语 说明 服务（Service） 通过网络提供的、具有特定业务逻辑处理能力的软件功能。 服务提供者（Service Provider） 通","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-registry/terminology/","wordcount":1089},{"author":null,"categories":null,"content":" 名词 说明 TraceId TraceId 指的是 SOFATracer 中代表唯一一次请求的 ID，此 ID 一般由集群中第一个处理请求的系统产生，并在分布式调用下通过网络传递到下一个被请求系统。 SpanId SpanId 代表了本次请求在整个调用链路中的位置或者说层次，比如 A 系统在处理一个请求的过程中依次调用了 B，C，D 三个系统，那么这三次调用的的 SpanId 分别是：0.1，0.2，0.3。如果 B 系统继续调用了 E，F 两个系统，那么这两次调用的 SpanId 分别是：0.1.1，0.1.2。 其他相关的名词解释可以参考 OpenTracing 规范。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/explanation/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"8ba307b0679e918f7ac68c7efb7e53f7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/explanation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/explanation/","summary":"名词 说明 TraceId TraceId 指的是 SOFATracer 中代表唯一一次请求的 ID，此 ID 一般由集群中第一个处理请求的系统产生，并在分布式调用下通过网络传递到下一个被请求系统。 SpanId SpanId","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/explanation/","wordcount":211},{"author":null,"categories":null,"content":" 消息 内部全部使用 SofaRequest 和 SofaResponse 进行传递。\n如果需要转换为其它协议，那么在真正调用和收到请求的时候，转换为实际要传输的对象。\n可以对 SofaRequest 和 SofaResponse 进行写操作的模块： - Invoker - Filter - ServerHandler - Serialization\n对消息体是只读的模块： - Cluster - Router - LoadBalance\n日志 日志的初始化也是基于扩展机制。虽然是扩展，但是由于日志的加载应该是最早的，所以在 rpc-config.json 里有一个单独的 Key。\n{ // 日志实现，日志早于配置加载，所以不能适应Extension机制 \u0026amp;quot;logger.impl\u0026amp;quot;: \u0026amp;quot;com.alipay.sofa.rpc.log.MiddlewareLoggerImpl\u0026amp;quot; } 配置项 使用者的 RPC 配置 用户的配置，例如端口配置（虽然已经开放对象中设置端口的字段，但是sofa默认是从配置文件里取的），线程池大小配置等。 - 通过 SofaConfigs 加载配置，调用 ExternalConfigLoader 读取外部属性。 - 通过 SofaConfigs 提供的 API 进行获取。 - 所有内部配置的Key都在 SofaOptions 类 - 优先级： System.property \u0026amp;gt; sofa-config.properties(每个应用一个) \u0026amp;gt; rpc-config.properties\nRPC 框架配置 框架自身的配置，例如默认序列化，默认超时等。 未来要一个ClassLoader一个。 - 通过 RpcConfigs 加载配置文件。 - 通过 RpcConfigs 其提供的API进行获取和监听数据变化 - 所有内部配置的Key都在 RpcOptions 类 - 优先级： System.property \u0026amp;gt; custom rpc-config.json（可能存在多个自定义，会排序） \u0026amp;gt; rpc-config-default.json\n常量 全局的基本常量在 RpcConstants 中。例如： 调用方式 sync oneway 协议 bolt/grpc、 序列化 hessian/java/protobuf\n 上下文的key 等等。 如果扩展实现自身的常量，请自行维护。 例如 BOLT 协议的常量。 SERIALIZE_CODE_HESSIAN = 1 PROTOCOL_TR = 13 例如 DSR 配置中心相关的常量。 _WEIGHT、_CONNECTTIMEOUT 这种 配置中心特有的key 地址 地址信息放到 ProviderInfo 类中 ProviderInfo 的值主要分为三部分 字段，一般是一些必须项目。 例如IP，端口，状态等； 静态字段：例如应用名； 动态字段：例如预热权重等； 字段枚举维护在 ProviderInfoAttrs 类中。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/common-model/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b2cc3f7ed134408d6adc25e418e1978b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/common-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/common-model/","summary":"消息 内部全部使用 SofaRequest 和 SofaResponse 进行传递。 如果需要转换为其它协议，那么在真正调用和收到请求的时候，转换为实际要传输的对象。 可以对 SofaRequest 和 SofaResponse 进行写操作的模块","tags":null,"title":"基础模型","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/common-model/","wordcount":684},{"author":null,"categories":null,"content":" 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 - git 工具用法可以查看 git 官方书籍,需要阅读前几章来熟悉。 - git 协作流程可以查看这篇文章 git 协作流程。\nGitHub 贡献代码流程 提交issue 不论您是修复 SOFAJRaft 的 bug 还是新增 SOFAJRaft 的功能，在您提交代码之前，在 SOFAJRaft 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处: - 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作。 - SOFAJRaft 的维护人员会对您提的 bug 或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 - 在达成一致后再开发，并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。\n获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFAJRaft 主干代码到您的代码仓库。\n拉分支 在这之前，可以先看看 SOFAJRaft 的 分支管理策略\nSOFAJRaft 所有修改都在分支上进行，修改完后提交 pull request，在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要： - 下载代码到本地，这一步您可以选择git/https方式。\ngit clone https://github.com/您的账号名/sofa-jraft 拉分支准备修改代码: git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支： git branch -a 如果您想切换回主干，执行下面命令： git checkout -b master 如果您想切换回分支，执行下面命令： git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFAJRaft 通过 Maven 插件来保持代码格式一致。在提交代码前，务必本地执行 mvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试： mvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等。 对于无用的注释，请直接删除。 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档。 修改完代码后，请按照如下格式执行命令提交所有的修改到本地:\ngit commit -am \u0026#39;(feat) 添加xx功能\u0026#39; git commit -am \u0026#39;(fix) 修复xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，接下来就可以与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的，那么这里的 origin 是 push 到您的代码仓库，而不是 SOFAJRaft 的代码仓库。\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFAJRaft 主干代码了。此时您需要进入您在 GitHub 上的对应仓库，按右上角的 pull request 按钮。选择目标分支，一般就是 master，系统会通知 SOFAJRaft 的人员， SOFAJRaft 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFAJRaft 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFAJRaft 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"99034715298f73cd835672b872141609","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","summary":"准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 - git 工具用法可以查看 git 官方书籍,需要阅读前几章来熟悉。 - git 协作流程可以查看这篇文章 git","tags":null,"title":"如何参与 SOFAJRaft 代码贡献","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","wordcount":1276},{"author":null,"categories":null,"content":" 简介 该样例工程演示了如何借助 maven 插件将一个普通的 Java 工程打包成标准格式规范的 Ark Plugin\n背景 现实开发中，常常会遇到依赖包冲突的情况；假设我们开发了一个类库 sample-lib , 业务应用在引入使用时，可能存在跟已有的依赖发生冲突的情况；通常这个时候，我们会希望自己的类库能够和业务其他依赖进行隔离，互不协商双方依赖包版本。 Ark Plugin 正是基于这种需求背景下的实践产物； Ark Plugin 运行在 Ark Container 之上，由容器负责加载启动，任何一个 Ark Plugin 由独立的 ClassLoader 加载，从而做到相互隔离。Ark Plugin 存在四个概念：\n 导入类：插件启动时，优先委托给导出该类的插件负责加载，如果加载不到，才会尝试从本插件内部加载；\n 导出类：其他插件如果导入了该类，优先从本插件加载；\n 导入资源：插件在查找资源时，优先委托给导出该资源的插件负责加载，如果加载不到，才会尝试从本插件内部加载；\n 导出资源：其他插件如果导入了该资源，优先从本插件加载；\n 详细请参考插件规范\n 工具 官方提供了 Maven 插件 - sofa-ark-plugin-maven-plugin ，只需要简单的配置项，即可将普通的 Java 工程打包成标准格式规范的 Ark Plugin ，插件坐标为:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 详细请参考插件配置文档\n 入门 基于该用例工程，我们一步步描述如何构建一个 Ark Plugin\n创建标准 Maven 工程 该用例工程是一个标准的 Maven 工程，一共包含两个模块： * common 模块：包含了插件导出类\n plugin 模块：包含了 com.alipay.sofa.ark.spi.service.PluginActivator 接口实现类和一个插件服务类，插件打包工具 sofa-ark-plugin-maven-plugin 即配置在该模块的 pom.xml 中； 配置打包插件 在 plugin 模块的 pom.xml 中按如下配置打包插件：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${project.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--can only configure no more than one activator--\u0026amp;gt; \u0026amp;lt;activator\u0026amp;gt;com.alipay.sofa.ark.sample.activator.SamplePluginActivator\u0026amp;lt;/activator\u0026amp;gt; \u0026amp;lt;!-- configure exported class --\u0026amp;gt; \u0026amp;lt;exported\u0026amp;gt; \u0026amp;lt;!-- configure package-level exported class--\u0026amp;gt; \u0026amp;lt;packages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa.ark.sample.common\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/packages\u0026amp;gt; \u0026amp;lt;!-- configure class-level exported class --\u0026amp;gt; \u0026amp;lt;classes\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.ark.sample.facade.SamplePluginService\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/classes\u0026amp;gt; \u0026amp;lt;/exported\u0026amp;gt; \u0026amp;lt;!--specify destination where ark-plugin will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;../target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 在用例工程中，我们只配置了一部分配置项，这已经足够生成一个可用的 Ark Plugin，各配置项含义如下： * activator: Ark 容器启动插件的入口类，最多只能配置一个；通常来说，在插件的 activator 会执行一些初始化操作，比如发布插件服务；在本样例工程中，即发布了插件服务。\n 导出包：包级别的导出类配置，插件中所有以导出包名为前缀的类，包括插件的三方依赖包，都会被导出；\n 导出类：精确类名的导出类配置，导出具体的类；\n outputDirectory： mvn package 打包后，输出的 ark plugin 文件存放目录；\n 需要指出的是，在用例工程中，我们只导出了工程创建的类；实际在使用时，也可以把工程依赖的三方包也导出去。\n打包、安装、发布、引入 和普通的工程操作类似，使用 mvn package , mvn install , mvn deploy 即可完成插件包的安装和发布；需要注意的是，默认发布的 Ark Plugin 其 Maven 坐标会增加 classifier=ark-plugin ；例如在该样例工程中，如果需要使用该 ark plugin，必须如下配置依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin-demo/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d8125843ced13352dd228299f222c74d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","summary":"简介 该样例工程演示了如何借助 maven 插件将一个普通的 Java 工程打包成标准格式规范的 Ark Plugin 背景 现实开发中，常常会遇到依赖包冲突的情况；假设我们开发了一个类","tags":null,"title":"如何打包 Ark Plugin","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","wordcount":1171},{"author":null,"categories":null,"content":" 简介 该样例工程演示了如何借助 Maven 插件将一个 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包；\n准备 因该样例工程依赖 sample-ark-plugin，因此需要提前在本地安装该 Ark Plugin\n工具 官方提供了 Maven 插件 - sofa-ark-maven-plugin ，只需要简单的配置项，即可将 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包，插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 详细请参考插件使用文档\n 入门 基于该样例工程，我们一步步描述如何将一个 Spring Boot Web 工程打包成可运行 Ark 包\n创建 SpringBoot Web 工程 在官网 https://start.spring.io/ 下载一个标准的 Spring Boot Web 工程\n引入 sample-ark-plugin 在工程主 pom.xml 中如下配置，添加另一个样例工程打包生成的 Ark Plugin 依赖，参考文档\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置打包插件 在工程主 pom.xml 中如下配置 Maven 插件 sofa-ark-maven-plugin :\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- 让模块只能使用基座里模块声明过的依赖，详细查看 https://www.sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/ --\u0026amp;gt; \u0026amp;lt;declaredMode\u0026amp;gt;true\u0026amp;lt;/declaredMode\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 在该样例工程中，我们只配置了一部分配置项，这已经足够生成一个可用的可执行 Ark 包，各配置项含义如下： * outputDirectory: mvn package 打包后，输出的 Ark 包文件存放目录；\n arkClassifier: 指定发布的 Ark 包其 Maven 坐标包含的 classifier 值，默认为空； 关于 arkClassifier 配置项需要特别注意下，默认值为空；如果不指定 classifier ，上传到仓库的 Jar 包其实是一个可运行的 Ark 包；如果需要和普通的打包加以区分，需要配置该项值。\n打包、安装、发布 和普通的工程操作类似，使用 mvn package , mvn install , mvn deploy 即可完成插件包的安装和发布；\n运行 我们提供了两种方式在 Ark 容器上启动工程应用，通过命令行启动或者在 IDE 启动；在 IDE 启动时，需要额外添加依赖；使用命令行启动非常简便，直接使用 java -jar 即可启动应用；下面我们说下如何在 IDE 启动 Ark 应用；\n Spring Boot 工程：Spring Boot 工程需要添加如下依赖即可： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 普通 Java 工程： 相较于 SpringBoot 工程，普通的 Java 工程需要添加另一个依赖： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-support-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 除此之外，还需要在工程 main 方法最开始处，执行容器启动，如下：\npublic class Application{ public static void main(String[] args) { SofaArkBootstrap.launch(args); ... } } 运行测试用例 SOFAArk 提供了 org.junit.runner.Runner 的两个实现 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-demo/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2c97c409788f41051c79836d277997be","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","summary":"简介 该样例工程演示了如何借助 Maven 插件将一个 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包； 准备 因该样例工程依赖 sample-ark-plugin，因","tags":null,"title":"如何打包 Ark 包","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","wordcount":1293},{"author":null,"categories":null,"content":" 如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。\n 直接下载代码，然后执行如下命令：\ncd sofa-rpc mvn clean install 注意：不能在子目录（即子模块）下进行编译。因为 SOFARPC 模块太多，如果每个子模块都会install 和 deploy，仓库内会有较多无用记录。 所以在设计 SOFARPC 工程结构的时候，我们决定各个子模块组件是不需要 install 和 deploy 到仓库里的，我们只会install 和 deploy 一个sofa-rpc-all(all) 模块。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/how-to-build/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"52ad3debb35be8743c97bb4b6b77f22b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/how-to-build/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/how-to-build/","summary":"如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后执行如下命令： cd sofa-rpc mvn clean install 注意：不能在子目录（即子模块）下进行编译。因为 SOFARPC 模块太多","tags":null,"title":"如何编译 SOFARPC 工程","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/how-to-build/","wordcount":180},{"author":null,"categories":null,"content":" 在非 Kubernetes 环境下使用 Istio 需要达成以下的关键任务：\n 为 Istio 控制平面配置 Istio API server，也可以通过 memostore 的方式启动 Pilot 用作演示用途。 给所有微服务实例手工添加 SOFA MOSN，并以 Sidecar 模式启动。 确保请求都通过 SOFA MOSN 进行路由。 设定控制平面 Istio 控制平面由四个主要的服务组成：Pilot、Mixter、Citadel 以及 API server。\nAPI server Istio\u0026amp;rsquo;s API server (基于 kubernetes API server) 提供了配置管理和基于角色的访问控制。API server 需要 etcd 集群作为底层的持久化存储。\n本地安装 使用如下的 docker compose file 安装一个用于 POC 目的的 API server：\nversion: \u0026#39;2\u0026#39; services: etcd: image: quay.io/coreos/etcd:latest networks: default: aliases: - etcd ports: - \u0026amp;quot;4001:4001\u0026amp;quot; - \u0026amp;quot;2380:2380\u0026amp;quot; - \u0026amp;quot;2379:2379\u0026amp;quot; environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;/usr/local/bin/etcd\u0026amp;quot;, \u0026amp;quot;-advertise-client-urls=http://0.0.0.0:2379\u0026amp;quot;, \u0026amp;quot;-listen-client-urls=http://0.0.0.0:2379\u0026amp;quot; ] istio-apiserver: image: gcr.io/google_containers/kube-apiserver-amd64:v1.7.3 networks: default: aliases: - apiserver ports: - \u0026amp;quot;8080:8080\u0026amp;quot; privileged: true environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;kube-apiserver\u0026amp;quot;, \u0026amp;quot;--etcd-servers\u0026amp;quot;, \u0026amp;quot;http://etcd:2379\u0026amp;quot;, \u0026amp;quot;--service-cluster-ip-range\u0026amp;quot;, \u0026amp;quot;10.99.0.0/16\u0026amp;quot;, \u0026amp;quot;--insecure-port\u0026amp;quot;, \u0026amp;quot;8080\u0026amp;quot;, \u0026amp;quot;-v\u0026amp;quot;, \u0026amp;quot;2\u0026amp;quot;, \u0026amp;quot;--insecure-bind-address\u0026amp;quot;, \u0026amp;quot;0.0.0.0\u0026amp;quot; ] 其他控制平面组件 目前 SOFA MOSN 还没有集成 Pilot 之外的其他组件，因此我们暂时无需安装 Mixer、Citadel 等组件。\n为微服务实例添加 SOFA MOSN Sidecar 微服务应用的每个实例都必须有个伴生的 SOFA MOSN 实例。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-installation/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"4c0bd56673dc8aebef9011a22496392d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","summary":"在非 Kubernetes 环境下使用 Istio 需要达成以下的关键任务： 为 Istio 控制平面配置 Istio API server，也可以通过 memostore 的方式启动 Pilot 用作演示用途。 给所有微服务实例手工添加 SOFA","tags":null,"title":"安装指南","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","wordcount":372},{"author":null,"categories":null,"content":"提供可以允许配置的所有参数。 * 发布订阅配置 * 预热转发配置 * 自动故障剔除配置\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b1a8a8c426beab292165716f1dff1ae4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration/","summary":"提供可以允许配置的所有参数。 * 发布订阅配置 * 预热转发配置 * 自动故障剔除配置","tags":null,"title":"完整配置参数","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration/","wordcount":37},{"author":null,"categories":null,"content":" 客户端 API 使用说明 SOFALookout 客户端设计上保持了 API 与实现解耦。如果我们只需要基于 SOFALookout API 进行埋点，那么只需要依赖 API 包即可。在没有依赖具体实现模块依赖时（比如 client 依赖 或 SOFABoot（Spring Boot）Start 依赖），API 包会自动使用 NoopRegistry，使得所有埋点的地方都已空实现替代。\n1.API 依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.关于 ID Lookout metrics 相比传统的 metrics 库单一维度的信息描述，提供了支持多维度描述的 tags 能力。 Lookout metrics 的唯一标识 Id 类，由 name 和 tags 构成。\nId basicId = registry.createId(\u0026amp;quot;rpc.provider.service.stats\u0026amp;quot;); id = basicId.withTag(\u0026amp;quot;service\u0026amp;quot;, \u0026amp;quot;com.alipay.demo.demoService\u0026amp;quot;) .withTag(\u0026amp;quot;method\u0026amp;quot;, \u0026amp;quot;sayHi\u0026amp;quot;) .withTag(\u0026amp;quot;protocol\u0026amp;quot;, \u0026amp;quot;tr\u0026amp;quot;) .withTag(\u0026amp;quot;alias\u0026amp;quot;, \u0026amp;quot;group1\u0026amp;quot;); 上面是 Id 的简单示例了，如何创建 Id，如何打 tag，（每打一次 tag，都会生成并返回一个新的 Id 对象引用）切记！使用返回新的 Id 对象了哦。\n 不要主动缓存 Id 或具体的 Metric 对象,Lookout 的 Registry 已经登记记录了。相等的 Id （ name 和 tags 一样）会复用已有的Id 对应 Metric 对象。 2.1 Priority tag (不是必须) PRIORITY 枚举级别: HIGH, NORMAL, LOW;\nid.withTag(LookoutConstants.LOW_PRIORITY_TAG); 如果不打该 Tag (建议)，默认是 NORMAL 级别。级别代表了采集间隔周期（HIGH：2s, NORMAL: 30s, LOW: 1min）\n2.2 关于 tags 通用的 tags，比如：本机 ip，机房等详细会统一附上，不需要单独指定。 普通 Java 项目直接 lookout-client 时，tags 需要自己指定，特别记住：appName 别忘啦！tag:app=xx key 必须小写，尽量是字母，数字，下划线； （尤其是运行期的 Counter, Timer, DistributeSummary 这些 metrics）某个类型的 tag 的 values 尽量是稳定不变有限集合，而且 tags 尽量少，防止 metrics 数量超过最大限制！ 比如：rpc 场合 service, method 两个 tag 对应的值是有限较小的； 反例是每次 rpc 调用都有是个独立的 tag-value。 因此，总体原则自定义打 tags 时要尽量少，对应 values 的集合数量尽量小； 专门用途的 TAG 名称: \u0026amp;ldquo;priority\u0026amp;rdquo;: 表示优先级。 系统保留的 tag key 统配格式_*_,以下划线开始，以下划线结束（比如: \u0026amp;ldquo;type\u0026amp;rdquo; ）。 请不要使用这种格式的 key，可能会被系统覆盖或丢弃 3.可接入的统计( Metric )类型API Counter 「计数器」 场景：方法调用次数； 主动汇报的数据包括： count, rate (也就是 qps)； 使用方式 Counter counter=registry.counter(id); counter.inc(); Timer 「耗时统计器」 场景:统计任务，方法耗时，支持分桶统计 主动汇报的数据包括：elapPerExec (单次执行耗时), total 耗时，Max 耗时,（上报单位：秒）； 使用方式 Timer timer=registry.timer(id); timer.record(2, TimeUnit.SECONDS); DistributionSummary 「值分布情况统计器」 场景：比如 io 流量，支持分桶统计 主动汇报的数据包括: count, total(size), max(size)； 使用方式: DistributionSummary distributionSummary=registry.distributionSummary(id); distributionSummary.record(1024); Gauge 「即时数据观察」 场景：比如线程池，内存值等即时值； 主动汇报的数据包括: value； 往注册表中登记新 gauge 时，ID 值相等，注册表继续使用已有的(忽略新的)； 注意，推荐 gauge 观察的对象尽量是单例的（复用），并且建议在运行时一直活着（而不是作为一个临时的统计）！，如果不是单例或者只存活一段时间，那么一定要从 Registry 中 remove 掉，否则影响 GC（主要是它持有的外部对象引用无法释放，浪费空间）!!\n 使用方式: registry.gauge(id,new Gauge\u0026amp;lt;Double\u0026amp;gt;() { @Override public Double value() { return 0.1; } }); MixinMetric 「上述基本统计 metrics 的混合管理体」 MixinMetric 是 Lookout 特有的，表示多个基本 metrics 的混合体。引入该 Mixin 目的是优化对「同一度量目标」（即测量目标一致，tags 一致）的多测量指标传输和存储效率，比如：同一线程池的各种指标(线程总数，活跃总数，等待队列大小\u0026amp;hellip;)。\n 使用方式（比如，对一次服务调用，加入多个测量指标：调用耗时，输入字节，调用次数，输出字节等等） //1. getOrAdd MixinMetric MixinMetric rpcServiceMetric=registry.minxinMetric(id); //2. getOrAdd basic component metric to use Timer rpcTimer = rpcServiceMetric.timer(\u0026amp;quot;perf\u0026amp;quot;); DistributionSummary …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-api/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"76574f2435a3565fe1fc50831ff9ab0c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-api/","summary":"客户端 API 使用说明 SOFALookout 客户端设计上保持了 API 与实现解耦。如果我们只需要基于 SOFALookout API 进行埋点，那么只需要依赖 API 包即可。在没有依赖具体实现模块依赖时（比如","tags":null,"title":"客户端 API 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-api/","wordcount":1562},{"author":null,"categories":null,"content":" Registry 的使用 不同的 Registry 的集成提供了不同的访问 Metrics 的方式。\n1. LookoutRegistry 提供按照一定时间窗口统计 metrics 的能力。它又分为“主动推”和“被动拉”两种模式，暂时被动拉取模式处于关闭状态。\n（1）主动推模式\n可以通过【客户端配置】指定远程 Agent 的IP地址，即开始上报检查，和定时上报数据。 （2）被动拉模式\n可以通过【客户端配置】启动该模式，则在 19399 端口提供 HTTP 服务。更多交互细节请参考（待补充） 2. 对接到 Prometheus SOFALookout 的数据可以对接到 Prometheus 上面。为了将数据对接到 Prometheus 上面，首先需要在工程中加入依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-reg-prometheus\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 添加好依赖之后，启动应用，既可以访问 http://localhost:9494 来看到数据，其中 9494 为默认的端口，可以通过在 application.properties 里面配置 com.alipay.sofa.lookout.prometheus-exporter-server-port 来改变端口。\n有了访问数据的 URL 之后，可以编辑一个 prometheus.yml 来抓取该项目信息，假设本机 IP 地址为 10.15.232.20，那么可以配置如下的 prometheus.yml：\nscrape_configs: - job_name: \u0026#39;lookout-client\u0026#39; scrape_interval: 5s static_configs: - targets: [\u0026#39;10.15.232.20:9494\u0026#39;] 有了上面的配置文件之后，可以再到本地通过 Docker 来启动 Prometheus：\ndocker run -d -p 9090:9090 -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml --name prom prom/prometheus:master 然后通过浏览器访问: http://localhost:9090，再通过 PromQL 查询即可查询到对应的 Metrics。\nSOFALookout 中也提供了一个对接 Prometheus 的样例，大家可以前往自行查看。\n3. 对接 SpringBoot actuator 除了 Prometheus 之外，SOFALookout 可以与 SpringBoot 1.x 的 Actuator 的相集成，只需依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后启动后访问 http://localhost:8080/metrics 既可以看到通过 SOFALookout API 埋点的数据。\nSOFALookout 也提供了集成的样例工程，大家可以前往自行查看。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-registry/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3c51ba6519cee542b459a170dabcf32b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-registry/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-registry/","summary":"Registry 的使用 不同的 Registry 的集成提供了不同的访问 Metrics 的方式。 1. LookoutRegistry 提供按照一定时间窗口统计 metrics 的能力。它又分为“主动推”和“被动拉”两种模式，暂时被动拉取模","tags":null,"title":"客户端 Registry 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-registry/","wordcount":575},{"author":null,"categories":null,"content":" 1. 创建 Maven 工程 服务端部署完毕后，我们可以新建一个 Maven 工程使用 SOFARegistry 提供的服务。首先新建一个 Maven 工程，然后引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. 发布数据 // 构建客户端实例 RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // 构造发布者注册表 String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // 将注册表注册进客户端并发布数据 registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); 使用 SOFARegistry 发布数据一共包含三个步骤：\n 构建客户端实例; 构造发布者注册表; 将注册表注册进客户端并发布数据。 2.1 构建客户端实例 构建客户端实例的关键是创建 RegistryClientConfig 对象，创建 RegistryClientConfig 对象时需要指定 RegistryEndpoint 和 RegistryEndpointPort:\n RegistryEndpoint：注册中心任一 Session 节点地址； RegistryEndpointPort: Session 节点配置的 session.server.httpServerPort 端口值。 2.2 构造发布者注册表 构造发布注册表只需要创建 PublisherRegistration 并指定 dataId，dataId 是发布服务的唯一标识。\n2.3 发布数据 调用 RegistryClient 的 register 方法可以进行数据发布，该方法需要两个参数，第一个参数是发布注册表，指定了服务的 dataId，第二个参数是数据值，一般是一个字符串类型。\n3. 订阅数据 // 构建客户端实例 RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, global String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setScopeEnum(ScopeEnum.global); // 将注册表注册进客户端并订阅数据，订阅到的数据会以回调的方式通知 SubscriberDataObserver registryClient.register(registration); 使用 SOFARegistry 订阅数据一共包含四个步骤：\n 构建客户端实例; 创建 SubscriberDataObserver； 构造订阅者注册表； 将注册表注册进客户端并订阅数据。 其中创建客户端实例方式与上文发布数据时创建客户端实例的方法一致。\n3.1 创建 SubscriberDataObserver SubscriberDataObserver 是一个回调接口，该接口定义了 handleData 方法，该方法包含两个参数，分别是 dataId 及最终数据，当客户端收到服务端订阅的数据时会调用该方法。在 SOFARegistry 中，服务端返回数据用 UserData 表示，该类包含以下两个方法：\npublic interface UserData { Map\u0026amp;lt;String, List\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; getZoneData(); String getLocalZone(); } getLocalZone: 返回当前zone； getZoneData: 返回以 zone 为 key，每个 zone 的数据为 value 的数据。 3.2 构造订阅者注册表 构造订阅者注册表需要创建 SubscriberRegistration 对象，创建该对象需要指定 dataId 及 SubscriberDataObserver。\n3.3 订阅数据 调用 RegistryClient 的 register 方法可以进行数据订阅，该方法包含一个参数，只需传入 SubscriberRegistration 对象即可。\n如果先运行发布数据的程序，然后再运行订阅数据的程序，那么我们将在控制端看到如下输出：\nreceive data success, dataId: …","date":-62135596800,"description":"","dir":"projects/sofa-registry/client-quick-start/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"66e300d44b2f2a903d976bf83eb7c16e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/client-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/client-quick-start/","summary":"1. 创建 Maven 工程 服务端部署完毕后，我们可以新建一个 Maven 工程使用 SOFARegistry 提供的服务。首先新建一个 Maven 工程，然后引入如下依赖： \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. 发布数据 // 构建客户端","tags":null,"title":"客户端使用","type":"projects","url":"/sofastack.tech/projects/sofa-registry/client-quick-start/","wordcount":897},{"author":null,"categories":null,"content":" 该项目演示了如何在 SOFABoot 中使用 SOFALookout 并且对接到 Spring Boot 的 Actuator 中。如果想要对接到 Prometheus 上或者其他的 Registry 中，请参考 Registry 一节。\n新建 SpringBoot（或 SofaBoot ）项目 新建一个 Spring Boot 的应用（如果是 SOFABoot 工程按照 SOFABoot 文档 - 依赖管理中的方式引入 SOFABoot 即可）。\n引入 Lookout 的 Starter 依赖 在 pom.xml 中引入以下依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 如果 Spring Boot 项目需指定版本。\n新建一个 Metrics 指标 在完成依赖的引入之后，然后可以在 Spring Boot 中的启动类中，加入如下的方法：\n@Autowired private Registry registry; @PostConstruct public void init() { Counter counter = registry.counter(registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;).withTag(\u0026amp;quot;instant\u0026amp;quot;, NetworkUtil.getLocalAddress().getHostName())); counter.inc(); } 上面的代码中直接通过 @Autowired 注入了一个 Registry 的字段，通过这个 Registry 的字段，我们就可以创建对应的 Counter，然后通过修改这个 Counter 的数据来生成 SOFALookout 的 Metrics 的指标。\n添加配置项 在 SOFABoot 项目中，需要增加一个应用名的配置项：spring.application.name=xxx。\n与 Spring Boot Actuator 对接 新增了一个指标之后，我们可以选择对接到 Spring Boot Actuator 上，要对接到 Spring Boot Actuator 上面，需要添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 添加如上的依赖之后，我们在本地启动应用，访问 http://localhost:8080/metrics，就可以看到前面添加的指标，如下：\n\u0026amp;quot;http_requests_total.instant-MacBook-Pro-4.local\u0026amp;quot;: 1, 以上的 QuickStart 的代码在: lookout-client-samples-boot，大家可以下载作为参考。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-boot/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"27e057f8a8a4ac97f42ea66ca6a17fdd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","summary":"该项目演示了如何在 SOFABoot 中使用 SOFALookout 并且对接到 Spring Boot 的 Actuator 中。如果想要对接到 Prometheus 上或者其他的 Registry 中，请参考 Registry 一节。 新建 SpringBoot（或 SofaBoot ）项目 新建一","tags":null,"title":"客户端快速开始 - SOFABoot 项目","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","wordcount":490},{"author":null,"categories":null,"content":" 普通 Java 项目 在应用中加入 client 的 Maven 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; lookout-client 默认依赖了 lookout-reg-server 模块（支持向 lookout server 上报 metrics 数据），如果希望使用其他类型注册表(比如 lookout-reg-prometheus)，那么再加上对应依赖即可。\n开始使用 SOFALookout 的 Client 之前，首先需要构建一个全局的客户端实例（ com.alipay.lookout.client.DefaultLookoutClient ）\nLookoutConfig lookoutConfig = new LookoutConfig(); DefaultLookoutClient client = new DefaultLookoutClient(\u0026amp;quot;appName\u0026amp;quot;); //选择构建需要使用的 Registry(如果多个注册表类型，建议使用同一 lookoutConfig 实例，便于集中管理) LookoutRegistry lookoutRegistry = new LookoutRegistry(lookoutConfig); //客户端可以后置添加 registry 实例(至少要加一个) client.addRegistry(lookoutRegistry); //(可选)对已加入或后续加入的客户端的 registry 实例，统一注册扩展模块的 metrics client.registerExtendedMetrics(); 然后通过客户端拿取 Registry 实例，进行使用：\n//该注册表是个“组合”型的注册表 Registry registry = client.getRegistry(); //demo Id id = registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;); Counter counter = registry.counter(id); counter.inc(); 客户端的使用，可以详细参考样例工程。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-java/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5dc476aa21ece4789859f1af598d4445","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","summary":"普通 Java 项目 在应用中加入 client 的 Maven 依赖 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa.lookout\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;lookout-client\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${lookout.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; lookout-client 默认依赖了 lookout-reg-server 模块（支持向 lookout server 上报 metrics 数据），如果希望使用其他类型注册表(比如 lookout-reg","tags":null,"title":"客户端快速开始 - 普通 Java 项目","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","wordcount":311},{"author":null,"categories":null,"content":"客户端模块是一个较复杂的模块，这里包含了集群管理、路由、地址管理器、连接管理器、负载均衡器，还与代理、注册中心等模块交互。\n参见：\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/client-invoke-flow/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"310d99d64b808a3b526563e92c699952","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","summary":"客户端模块是一个较复杂的模块，这里包含了集群管理、路由、地址管理器、连接管理器、负载均衡器，还与代理、注册中心等模块交互。 参见：","tags":null,"title":"客户端调用流程","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","wordcount":64},{"author":null,"categories":null,"content":" 客户端配置项设置示例 lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026amp;quot;127.0.0.1\u0026amp;quot;); 客户端配置项说明 配置项 对应 SpringBoot 配置项 默认配置值 说明 lookout.enable com.alipay.sofa.lookout.enable true 功能开关，默认是 true。如果改为 false，那么所有 metrics 就几乎没有内存与计算消耗(空对象与空方法) lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 metrics 最大数目限制，超过会自动忽略 lookout.prometheus.exporter.server.port com.alipay.sofa.lookout.prometheus-exporter-server-port 9494 prometheus 抓取的端口 lookout.exporter.enable com.alipay.sofa.lookout.exporter-enable false 是否开启支持被动采集的服务 lookout.agent.host.address com.alipay.sofa.lookout.agent-host-address - 主动上报 Agent 服务器的注解地址，支持多个地址以逗号分隔 客户端日志配置说明 系统属性配置项 对应 SpringBoot 配置项 默认配置值 说明 -Dlogging.level.com.alipay.lookout=? logging.level.com.alipay.lookout warn lookout 客户端的日志级别，debug 可以看见汇报数据的详情 -Dlogging.path=? logging.path 当前用户目录 SpringBoot V1的日志目录调整，包括 \u0026amp;ldquo;lookout/\u0026amp;rdquo; 日志子目录 客户端配置自定义(适用于 SpringBoot 技术栈模式) 使用配置定制扩展: MetricConfigCustomizerConfig\n@Configuration public class MetricConfigCustomizerConfig { @Bean public MetricConfigCustomizer metricConfigCustomizer() { return new MetricConfigCustomizer() { @Override public void customize(MetricConfig metricConfig) { metricConfig.addProperty(\u0026amp;quot;testaa\u0026amp;quot;, \u0026amp;quot;testbb\u0026amp;quot;); } }; } } ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-configuration/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5fd84950d4d565d3fb20781337792bf1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/client-configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/client-configuration/","summary":"客户端配置项设置示例 lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026quot;127.0.0.1\u0026quot;); 客户端配置项说明 配置项 对应 SpringBoot 配置项 默认配置值 说明 lookout.enable com.alipay.sofa.lookout.enable true 功能开关，默认是 true。如果改为 false，那么所有 metrics 就几乎没","tags":null,"title":"客户端配置","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/client-configuration/","wordcount":298},{"author":null,"categories":null,"content":"包含单机故障剔除和 Hystrix 熔断。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e567dc5e291867e92c8dd1c4f953b768","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault/","summary":"包含单机故障剔除和 Hystrix 熔断。","tags":null,"title":"容灾恢复","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault/","wordcount":13},{"author":null,"categories":null,"content":" 本文档中提供了 MOSN 的示例工程。\n使用 MOSN 作为 HTTP 代理 请参考 MOSN 转发 HTTP 的示例工程 http-sample。\n使用 MOSN 作为 SOFARPC 代理 请参考 MOSN 转发 SOFARPC 的示例工程 sofarpc-sample。\n使用 MOSN 作为TCP 代理 请参考 MOSN 作为 TCP Proxy 的示例工程 tcpproxy-sample 。\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-samples/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"600c182fdee786a59e14899ba0fce8a1","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-run-samples/","summary":"本文档中提供了 MOSN 的示例工程。 使用 MOSN 作为 HTTP 代理 请参考 MOSN 转发 HTTP 的示例工程 http-sample。 使用 MOSN 作为 SOFARPC 代理 请参考 MOSN 转发 SOFARPC 的示例工程 sofa","tags":null,"title":"工程示例","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-run-samples/","wordcount":106},{"author":null,"categories":null,"content":" 源码工程中提供了一些样例工程，辅助说明项目的使用。样例工程的 readme 有使用补充说明，另外需要将这些 sample 工程单独的导入 IDE。\n客户端样例工程 lookout-client-samples-java 该样例工程展示了，在普通 Java 项目中,如何以代码形式使用和配置客户端。\n lookout-client-samples-boot 该样例工程展示了，在 SpringBoot(或SofaBoot) 项目中,如何使用和配置客户端。\n lookout-client-samples-prometheus 该样例工程展示了，在 SpringBoot(或SofaBoot) 项目中,如何使用和配置客户端使用 prometheus。\n lookout-samples-prom-push 该样例工程展示了，在 Java 项目中,使用 prometheus 客户端并以push方式（PushGateway）上报数据。\n服务器端样例工程 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-samples/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a8a0fcd3f99ce2fb46e4d543e30797c9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-samples/","summary":"源码工程中提供了一些样例工程，辅助说明项目的使用。样例工程的 readme 有使用补充说明，另外需要将这些 sample 工程单独的导入 IDE。 客户端样例工程 lookout-client-samples-java 该样例工","tags":null,"title":"工程示例","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-samples/","wordcount":261},{"author":null,"categories":null,"content":" Q：报错误 NoSuchMethodError 一般情况下该类错误由依赖冲突导致。已知的依赖冲突列举如下，遇到时选择性排除它们。\n日志冲突 commons-logging 冲突 \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-logging\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; logback-classic 冲突 在冲突位置将 logback-classic 排除，如 spring-boot-starter-logging 和 spring-test 为存在冲突的应用依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.3.4.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; snakeyaml 冲突 java.lang.NoSuchMethodError: org.yaml.snakeyaml.Yaml.\u0026amp;lt;init\u0026amp;gt;(Lorg/yaml/snakeyaml/constructor/BaseConstructor;)V spring-boot-starter-test 与 org.testng 中引用的 org.yaml 存在冲突。这里以排除 spring-boot-starter-test 中的 org.yaml 为例（也可在 org.testng 等冲突位置排除）\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.yaml\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;snakeyaml\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Q：报错 NoClassDefFoundError 一般情况下依赖缺失或者依赖冲突会导致该类问题。\nMockito 报错找不到类 SOFABoot 使用 Mockito 时，如果已经存在 spring-boot-starter-test 则无需重复引入 Mockito。\nQ：报错 No bean dataAccessConfigManager available ACTS 测试脚本指定的 Application 启动类中缺少 acts-core.xml，如图添加即可。\nQ：No runnable methods 一般是由于选择 Junit 运行 ACTS 测试脚本导致的，ACTS 测试脚本可使用 TestNG 方式运行。\nQ：生成模版异常 有较多情况会导致这一现象，常见的是新编写的类或者对类进行变更后，没有进行 mvn 编译。先执行 mvn clean install -Dmaven.test.skip=true，再进行模版生成。\nQ：编辑器设置入参错误 使用 ACTS IDE 操作入参时，出现无法选中或者设置数值出错等情况，一般是生成测试脚本操作有误，没有生成入参模版而直接生成测试脚本，导致初始生成的 YAML 中入参不正确。\n 解法一：删除测试脚本对应的 YAML 文件，然后打开 ACTS IDE 并右键入参设置 -\u0026amp;gt; 模版选择，编辑后保存则 YAML 文件会自动重建。 解法二：删除生成的测试脚本和 YAML 文件，首先生成入参的模版，再重新生成测试脚本即可，YAML 中会默认带入参设置； Q：报错 argument type mismatch 该问题一般是被测接口有多个同名重载方法导致的，从而引发反射时参数不匹配错误。\n解决方法 可以在脚本中重写 ACTS 测试基类的 findMethod 方法，返回真正被测的方法对象。下面的方法也适用于获取被测方法失败的情况。\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { Method method =null; try { method = VirtualAssetQueryService.class.getDeclaredMethod (\u0026amp;quot;query\u0026amp;quot;, QueryVirtualAssetListParam.class); } catch (NoSuchMethodException e) { e.printStackTrace(); } catch (SecurityException e) { e.printStackTrace(); } actsRuntimeContext.setTestedMethod(method); } 使用 ACTS IDE 编辑类的属性后保存取值失效 ACTS IDE 默认类是标准的 JavaBean 形式，会调用属性的 set 方法为其赋值，如果不存在 set 方法则无法保存取值。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/faq/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5f89d1f5695cbe6b669a8738741529bd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/faq/","summary":"Q：报错误 NoSuchMethodError 一般情况下该类错误由依赖冲突导致。已知的依赖冲突列举如下，遇到时选择性排除它们。 日志冲突 commons-logging 冲突 \u0026lt;exclusion\u0026gt; \u0026lt;artifactId\u0026gt;commons-logging\u0026lt;/artifactId\u0026gt; \u0026lt;groupId\u0026gt;commons-logging\u0026lt;/groupId\u0026gt; \u0026lt;/exclusion\u0026gt; logback-classic 冲突 在冲突位置将 logback-classic 排除，","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-acts/faq/","wordcount":776},{"author":null,"categories":null,"content":" Q: Readiness Check 有啥应用场景？ Liveness Check 和 Readiness Check 概念来自于 Kuberentes，分别代表运行时检查和启动时检查。Spring Boot 提供了 Liveness Check，但是没有提供 Readiness Check。利用 Readiness Check 的能力，SOFA 中间件中的各个组件只有在 Readiness Check 通过之后，才将流量引入到应用的实例中，比如 RPC，只有在 Readiness Check 通过之后，才会向服务注册中心注册，后面来自上游应用的流量才会进入。除了中间件可以利用 Readiness Check 的事件来控制流量，PAAS 系统也可以通过访问 http://localhost:8080/health/readiness 来获取应用的 Readiness Check 的状况，从而控制例如负载均衡设备等等的流量。\nQ: 是否可以在 SOFABoot 模块中定义 Controller 组件？ SOFABoot 模块一般用于封装对外发布服务接口的具体实现，属于业务层，Controller 属于展现层内容，我们不建议也不支持在 SOFABoot 模块中定义 Controller 组件，Controller 组件相关定义建议直接放在 Root Application Context。\nQ: 类隔离在蚂蚁内部使用是否广泛？ 类隔离在蚂蚁内部使用非常广泛，绝大部分业务应用都是运行在蚂蚁中间件自研的类隔离框架之上。主要是为了解决依赖冲突的问题，像蚂蚁金服这种体量的公司，业务线繁杂、基础服务组件众多，很难做到对所有 JAR 包做统一管控。特别涉及到跨团队模块组件相互依赖时，因为各自技术栈历史包袱的存在，难以有效统一冲突包版本。使用类隔离技术解决了实际开发中的很多痛点，业务开发者不需要担心自身依赖冲突的问题，在多团队协作开发中，也有很大的优势。\nQ: SOFABoot类隔离框架（SOFAArk）和 OSGI 容器有哪些差异？ 作为开源界早负盛名的动态模块系统，基于 OSGi 规范的 Equinox、Felix 等同样具备类隔离能力，然而他们更多强调的是一种编程模型，面向模块化开发，有一整套模块生命周期的管理，定义模块通信机制以及复杂的类加载模型。作为专注于解决依赖冲突的隔离框架，SOFAArk 专注于类隔离，简化了类加载模型，因此显得更加轻量。其次在 OSGi 规范中，所有的模块定义成 Bundle 形式，作为应用开发者，他需要了解 OSGi 背后的工作原理，对开发者要求比较高。在 SOFAArk 中，定义了两层模块类型，Ark Plugin 和 Ark Biz，应用开发者只需要添加隔离的 Ark Plugin 依赖，底层的类加载模型对应用开发者俩说是透明的，基本不会带来额外的学习成本。\nQ: SOFAArk 和 Java9 模块化有哪些差异？ Jigsaw 作为 Java9 模块化方案，抛开内部实现细节，在使用规范上和 OSGi 特别相似：模块的依赖、包导入导出、动态导出、可读性传递、模块服务注册与消费、开放模块、可选模块等等若干概念，相对于 SOFAArk 简单的包导入导出显然过于复杂。在实现细节上，考虑到 JDK 代码的兼容性，Jigsaw 没有采用类加载器隔离的方式，不同模块之间仍然可能是同一个类加载器加载。严格上来讲，Jigsaw 并没有解决同一个类多版本的问题，但是因为模块显示的依赖声明，使用纯 Jigsaw 模块化编程，不同版本类冲突的问题在编译期就能被检查或者启动失败，因为不允许不同模块含有相同类名的包。对于在实际开发中遇到的一类情况，例如两个组件依赖不同版本 hessian 包，即使这两个组件定义成了两个模块，运行时也只有一个hessian版本被加载，依然解决不了不同版本类共存的问题。另外，Jigsaw 相对 Ark 或者 OSGi 有一个明显的缺点，Jigsaw 不允许运行时动态发布模块服务，模块间的通信依赖在 module-info.java 中使用 provides 和 uses 静态注册和引用模块服务。当然，Jigsaw 有很多自己的优点，通过引入module-path，在 module 中显示声明模块依赖关系，避免了传统 maven/gradle 中因为间接依赖导致运行时加载类不确定的缺点；其次通过设置模块包的导入导出配置，可以完全做到接口和实现的分离，提升安全性；另外 Java9 本身借助模块化改造，使用jlink工具，开发者可以将自身应用必须的模块聚合，打包一个自定义的jre镜像。\nQ: 为什么使用 SNAPSHOT 版本拉取不到依赖？ 如果需要使用处于研发状态的 SNAPSHOT 版本，有两种方式：\n 拉取 sofa-ark 仓库代码，本地执行 mvn install。 在本地 maven setting.xml 文件增加如下 profile 配置: \u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; Q: 为什么使用 java -jar 启动 Spring Boot/SOFABoot 应用 Ark 包时，应用自动退出？ 因为 SOFAArk 容器不会开启任何非 Daemon 线程，如果是非 Web 应用或者应用启动时不会创建非 Daemon 线程，则应用在执行完 main 方法时，会正常退出。判断 Ark 包是否正常启动，可以观察是否有如下日志出现：\nArk container started in …","date":-62135596800,"description":"","dir":"projects/sofa-boot/faq/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"56f06d32d37d8a5947d7c7ee43d6d955","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/faq/","summary":"Q: Readiness Check 有啥应用场景？ Liveness Check 和 Readiness Check 概念来自于 Kuberentes，分别代表运行时检查和启动时检查。Spring Boot 提供了 Liveness Check，但是没有提供","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-boot/faq/","wordcount":2071},{"author":null,"categories":null,"content":" 与 Prometheus的差异 答：主要包括:（1）Lookout metrics server 支持适配更多的协议接入；（2）聚焦在围绕 ES 生态提供易使用和运维的最佳实践；（3）支持计算能力下推；（4）除了 Metrics 后期会有 tracing，eventing等方案； （5）对聚合函数和 REST API 都做了兼容性的扩展和增强；（6）支持分布式集群部署具备高可用能力。\nLookout客户端会提供多语言(c,go,python\u0026amp;hellip;)支持吗 答：暂时不会。因为 Lookout Gateway已经支持很多主流协议的数据上报，同时也支持自定义扩展。 如果非Java技术栈，我们推荐大家使用其他开源主流的sdk库，比如: Prometheus sdk，Metricbeat等\n\u0026amp;ldquo;In order to improve query performance, you need to add tag filtering! realQuery:jvm.classes.loaded\u0026amp;rdquo; 答：只输入metric name查询会影响查询性能，所以我们强制每个查询至少有一个 tag（label）的筛选能力，比如:\u0026amp;ldquo;jvm.classes.loaded{app=\u0026amp;ldquo;lookout-gateway\u0026amp;rdquo;}\u0026amp;ldquo;。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/faq/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"f05d40c9d503ad466634f0473a5fac40","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/faq/","summary":"与 Prometheus的差异 答：主要包括:（1）Lookout metrics server 支持适配更多的协议接入；（2）聚焦在围绕 ES 生态提供易使用和运维的最佳实践；","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/faq/","wordcount":430},{"author":null,"categories":null,"content":" 咨询 Q: SOFARPC 是蚂蚁金服内部使用的版本吗？ 是的，SOFARPC 有良好的扩展接口，内部使用的版本就是在开源的版本多一些扩展实现。例如我们云上的商业版本集成了蚂蚁金融云的共享版注册中心、链路跟踪等产品；蚂蚁内部的版本集成了蚂蚁内部的注册中心、LDC路由等特性扩展。\nQ: SOFARPC 内部是用 Zookeeper 作为注册中心的吗？可以集成其它 etcd 等注册中心吗？ 在蚂蚁内部使用的是蚂蚁自研的注册中心产品。SOFARPC 的注册中心模块是可扩展的，对内对外使用的都是一套核心接口。目前开源的版本中集成了 Zookeeper，其它的注册中心实现社区已经在集成中。\nQ: 与Dubbo对比？ Dubbo 是阿里集团开源的一款非常优秀的RPC框架，高性能，具有良好的扩展性。Dubbo在国内开源界起步较早，使用者较多，开源生态更加丰富，目前已进入Apache基金会进行孵化。Dubbo最早在阿里巴巴B2B部门广泛使用。更多信息这里就不多介绍了。\nSOFARPC 最早起源于阿里集团内部的 HSF，但是经过了蚂蚁金服集团内部多年的独立发展，目前脱离为一个独立的产品。SOFARPC 在协议，网络，路由，可扩展性等层面都进行了大量的改造和优化的工作，以满足蚂蚁金服大规模金融级的业务场景。在蚂蚁金服内部，SOFARPC 在蚂蚁中间件（SOFAStack）的生态下，有完善的微服务技术栈支持，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量等等。截止 2019 年双十一，SOFARPC 已经被蚂蚁几千个系统所使用，生产环境发布的接口数量超过了十几万。\n但是在开源领域，SOFARPC 目前还是一个起步阶段，开源生态还在建设当中，随着开源计划的推进，我们会在后续的版本里增加各个周边组件，完善微服务技术栈。同时也欢迎大家来贡献，共同打造 SOFAStack。\n对于性能的对比，类似协议下使用的技术点都是差不多的，所以基本上可比性不高。 对于扩展性的对比，两者都具有良好的扩展性。 对于其它功能差异点的话，这里列一些已经开源或者即将开源的功能点供参考：SOFARPC 协议上将支持 HTTP/2、GRPC，能力上如服务预热权重、自动故障降级、协商机制、CRC数据校验等，结合 SOFABoot 可以实现 RPC 框架与业务的类隔离防止类冲突等等，另外 SOFARPC 在跨单元机房的路由，包括配合服务注册体系实现的对异地多活的支撑也是非常有特色的，期望后面能逐步跟大家分享讨论，甚至形成行业标准。而 SOFARPC 结合内部微服务下做一致性的框架实现的「微交易」架构也是蚂蚁在金融领域非常有价值的沉淀，也是跟 dubbo 体系不一样的地方。\nQ: 对比其他 RPC 框架有何优势？ 作为RPC框架，最基本的能力就是 RPC 调用，其它都是些性能、扩展性、功能性的差异，可能各家的侧重点不一样。\nSOFARPC 在蚂蚁金服内部大规模应用足以证明 SOFARPC 是一款可靠的生产级的 RPC 框架。而蚂蚁金服的金融的属性决定了 SOFARPC 在金融场景下的功能侧重点。\nQ: 和Spring Cloud 的对比？ SOFARPC 定位在 RPC 框架，和 Spring Cloud 的比较不在一个对比维度上面。 Spring Cloud 可对比的是 SOFAStack，SOFAStack 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，以及分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案。SOFAStack 的各个组件会在未来逐渐开源。\n另外，SOFARPC 的 Starter 是基于 Spring Boot 开发的，Spring Cloud 的各个组件也是基于 Spring Boot 开发的，所以两者并不冲突。\n研发类 Q: 为什么不使用 JDK8 SOFARPC 在蚂蚁金服内部还有JDK6的使用场景，所以编译选择JDK7，而编译级别选择JDK6。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/faq/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a6ec77ce5a423c5345394f42c64a416b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/faq/","summary":"咨询 Q: SOFARPC 是蚂蚁金服内部使用的版本吗？ 是的，SOFARPC 有良好的扩展接口，内部使用的版本就是在开源的版本多一些扩展实现。例如我们云上的商业版","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/faq/","wordcount":1533},{"author":null,"categories":null,"content":"SOFARPC 可以在使用 Bolt 通信协议的情况下，可以选择不同的序列化协议，目前支持 hessian2 和 protobuf。\n默认的情况下，SOFARPC 使用 hessian2 作为序列化协议，如果需要将序列化协议设置成 protobuf，在发布服务的时候，需要做如下的设置：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 即在 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签内增加 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签，并且设置 serialize-type 属性为 protobuf。\n对应的，在引用服务的时候，也需要将序列化协议改成 protobuf，设置方式和发布服务的时候类似：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot; jvm-first=\u0026amp;quot;false\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 目前，使用注解的方式尚不能支持设置序列化协议，这个将在后续的版本中支持，详见 ISSUE：https://github.com/sofastack/sofa-boot/issues/278\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/serialization/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"87e2faa84c2c7a7605243dc096bc4e17","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/serialization/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/serialization/","summary":"SOFARPC 可以在使用 Bolt 通信协议的情况下，可以选择不同的序列化协议，目前支持 hessian2 和 protobuf。 默认的情况下，SOFARPC 使用 hessian2 作为序列化协议，如","tags":null,"title":"序列化协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/serialization/","wordcount":296},{"author":null,"categories":null,"content":" SLF4J 提供了 MDC （Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。本文将介绍 SOFATracer 集成的 SLF4J MDC功能，方便用户在只简单修改日志配置文件的前提下输出当前 SOFATracer 上下文 TraceId 以及 SpanId 。\n使用前提 为了在应用中的日志正确打印 TraceId 和 SpanId 参数，我们的日志编程接口需要面向 SLF4J 进行编程，即打印日志的编程接口不要依赖具体的日志实现。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入依赖 如果是 SOFABoot 或者 Spring Boot 的应用具体的日志实现需要大家去引入，我们推荐的日志打印实现是 Logback 和 Log4j2，不推荐 Log4j，同时日志实现建议只使用一个而不要使用多个实现。\n Logback 实现引入： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Log4j2 实现引入： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-log4j2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!--SOFABoot 没有管控 log4j2 版本 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置方法 我们基于 SLF4J MDC 的原理打印对应的 TraceId 和 SpanId，首先我们的应用中的日志编程接口应该面向 SLF4J，如通过如下的方式：\n//引入接口 import org.slf4j.Logger; import org.slf4j.LoggerFactory; //构造日志打印实例 private static final Logger logger = LoggerFactory.getLogger(XXX.class); 其次，我们为了正确打印 TraceId 和 SpanId 参数，我们还需要在日志的配置文件中配置 PatternLayout 的额外参数，这两个参数是 %X{SOFA-TraceId} 和 %X{SOFA-SpanId}，参数值我们均是从 MDC 中获取的值。\n以 Logback 为例配置的 pattern 参数：\n\u0026amp;lt;pattern\u0026amp;gt;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId}, %X{SOFA-SpanId}] ---- %m%n\u0026amp;lt;/pattern\u0026amp;gt; 关键配置项目：[%X{SOFA-TraceId},%X{SOFA-SpanId}] 作为 Logback pattern 的一部分，在对应的 appender 被调用的时候，会根据 pattern 中的占位符替换为当前线程上下文中 TraceId 和 SpanId 的具体值，当前线程中没有对应的 TraceId 和 SpanId 值时，会用“空字符串”替代。 Log4j2 配置 PatternLayout 样例：\n\u0026amp;lt;PatternLayout pattern=\u0026amp;quot;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId},%X{SOFA-SpanId}] ---- %m%n \u0026amp;quot; /\u0026amp;gt; Log4j 配置 PatternLayout 样例：\n\u0026amp;lt;layout class=\u0026amp;quot;org.apache.log4j.PatternLayout\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;param name=\u0026amp;quot;ConversionPattern\u0026amp;quot; value=\u0026amp;quot;%d %-5p %-32t [%X{SOFA-TraceId},%X{SOFA-SpanId}] - %m%n\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/layout\u0026amp;gt; 需要注意的是：[%X{SOFA-TraceId},%X{SOFA-SpanId}] 使我们推荐的打印格式，用户可以根据自己的实际需求场景进行定制\n 附:基于 Log4j2 示例工程的源代码地址。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/print-traceid-spanid/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0d8cc680f811d1db2cffddbba269571c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","summary":"SLF4J 提供了 MDC （Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。本文将介绍 SOFATracer 集成的 SLF4J MDC功能，方便用户在只","tags":null,"title":"应用日志打印 traceId 和 spanId","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","wordcount":701},{"author":null,"categories":null,"content":" SOFADashboard 支持查看应用的IP、端口、健康检查状态等基本信息。此功能依赖 SOFADashboard client ，如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可：\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dashboard-client-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; 除此之外，SOFADashboard 解耦了类似于 SpringBoot Admin 客户端和服务端直连的模式，引入了第三方的储存，目前默认是 redis，因此如果希望能够监控 更多 actuator 信息，可以添加如下依赖：\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dashboard-ext-redis-store\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; 功能展示 相关数据的展示采用了 react-json-view 组件，是的可以直观的看到原始数据集。\n应用维度展示 应用实例 基础信息 健康检查详细数据 环境变量 loggins mappings 配置 client , prefix : com.alipay.sofa.dashboard.client\n 属性 名称 默认值 备注 enable 是否可用 true 当开启时，dashboard client 的相应功能才会作用 instanceIp 指定当前实例的IP 地址 \u0026amp;rdquo;\u0026amp;rdquo; 一般用于测试或者需要指定 IP 的场景 storeInitDelayExp 初始上报延迟 30s Dashboard度量数据存储上报延迟期望(s) storeUploadPeriodExp 上报周期 60s Dashboard度量数据存储上报周期(s) virtualHost 虚拟地址 \u0026amp;rdquo;\u0026amp;rdquo; 服务发布虚拟host（同SofaRpc中相同定义），可使用-Dcom.alipay.sofa.rpc.virtual.host引入 virutalPort 虚拟端口 \u0026amp;rdquo;\u0026amp;rdquo; 服务发布虚拟port（同SofaRpc中相同定义），可使用-Dcom.alipay.sofa.rpc.virtual.port引入 internalHost 内部地址 \u0026amp;rdquo;\u0026amp;rdquo; 容器内部地址（例如podIp等)，可使用-Dcom.alipay.sofa.rpc.virtual.internal.host引入 arkEnable 是否启用ark管理 true 当开启时，dashboard client的相应功能才会作用 注：virtualHost，virutalPort 如果通过com.alipay.sofa.rpc指定了相应参数，则不需要通过dashborad再次指定\nzookeeper , prefix : com.alipay.sofa.dashboard.zookeeper\n 属性 名称 默认值 备注 address 地址 true baseSleepTimeMs 客户端错误重试间隔(ms). 1000 maxRetries 客户端最大重试次数 3 sessionTimeoutMs 客户端会话超时时间(ms) 6000 connectionTimeoutMs 客户端超时时间(ms) 6000 redis , prefix : com.alipay.sofa.dashboard.redis\n 属性 名称 默认值 备注 enble 是否可用 true 当开启时，dashboard会使用redis作为存储 recordTtl 上报周期(ms). 3600 url redis对应url 例如：redis://user:password@example.com:6379 host redis对应host（单实例模式） port redis对应port（单实例模式） password redis密码 Sentinel.master Sentinel模式master master节点名，需参阅集群搭建设置 Sentinel.nodes Sentinel模式节点地址 例如host1:port1;host2:port2;host3:port3 Cluster.nodes Cluster模式节点地址 例如host1:port1;host2:port2;host3:port3 Cluster.maxRedirects Cluster模式重定向次数 0 建议给值，例如10 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/dashboard-client/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"60586c6dfee1f2afcdac88cbe7a36b83","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/dashboard-client/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/dashboard-client/","summary":"SOFADashboard 支持查看应用的IP、端口、健康检查状态等基本信息。此功能依赖 SOFADashboard client ，如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可： \u0026lt;denpendency\u0026gt;","tags":null,"title":"应用面板","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/dashboard-client/","wordcount":1078},{"author":null,"categories":null,"content":" 首先参考基本代码贡献需知 注意测试用例覆盖率； 代码格式； 验证 Samples 单独导入 Samples 的 Maven 项目； 修改对应 Pom 文件中依赖版本； 验证 Samples 也能正确工作； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/development-use-guide/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"423a54ec3f5fbfc9c0e150eb853738ae","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/development-use-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/development-use-guide/","summary":"首先参考基本代码贡献需知 注意测试用例覆盖率； 代码格式； 验证 Samples 单独导入 Samples 的 Maven 项目； 修改对应 Pom 文件中依赖版本； 验证 Samples 也能正确工作；","tags":null,"title":"开发指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/development-use-guide/","wordcount":63},{"author":null,"categories":null,"content":" 1.如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后在代码目录下执行如下命令：\n mvn clean install 2.版本发布 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号，例如 1.0.1。\n参见: http://semver.org/lang/zh-CN/。\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表 BugFix 版本。只做 bug 修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 1.3.0，那么将会维护 1.2.x 的 bugfix 分支，而 1.1.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 1.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 1.3.0。 发布后拉起下一个版本，例如 1.3.1-SNAPSHOT。 3.测试 单元测试 单元测试例子放到自己开发的模块下，测试类的包名与被测试类所在包相同。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/developer-guide/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fcacc7e89b979f3aec8dc3333a7a3c37","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-acts/developer-guide/","summary":"1.如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后在代码目录下执行如下命令： mvn clean install 2.版本发布 版本号 采用三位版本号，分别是主版","tags":null,"title":"开发者手册","type":"projects","url":"/sofastack.tech/projects/sofa-acts/developer-guide/","wordcount":404},{"author":null,"categories":null,"content":"介绍实现架构和相关的细节介绍： * 如何编译 * 架构介绍 * 调用流程 * 基础模型 * 扩展点设计 * 版本发布 * 测试\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/developer-guide/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"903b9f3a5372a75d654f8eeaaf750eeb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/developer-guide/","summary":"介绍实现架构和相关的细节介绍： * 如何编译 * 架构介绍 * 调用流程 * 基础模型 * 扩展点设计 * 版本发布 * 测试","tags":null,"title":"开发者手册","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/developer-guide/","wordcount":49},{"author":null,"categories":null,"content":" 线程中使用 java.lang.Runnable 如果用户在代码中通过 java.lang.Runnable 新启动了线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFATracer 提供的 com.alipay.common.tracer.core.async.SofaTracerRunnable 默认完成了此操作，大家可以按照如下的方式使用：\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.start(); 线程中使用 java.util.concurrent.Callable 如果用户在代码中通过 java.util.concurrent.Callable 新启动线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFATracer 提供的 com.alipay.common.tracer.core.async.SofaTracerCallable 默认完成了此操作，大家可以按照如下的方式使用：\nExecutorService executor = Executors.newCachedThreadPool(); SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt; sofaTracerSpanSofaTracerCallable = new SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt;(new Callable\u0026amp;lt;Object\u0026amp;gt;() { @Override public Object call() throws Exception { return new Object(); } }); Future\u0026amp;lt;Object\u0026amp;gt; futureResult = executor.submit(sofaTracerSpanSofaTracerCallable); //do something in current thread Thread.sleep(1000); //another thread execute success and get result Object objectReturn = futureResult.get(); 这个实例中，假设 java.util.concurrent.Callable 返回结果的对象类型是 java.lang.Object，实际使用时可以根据情况替换为期望的类型。\nSOFATracer 对线程池、异步调用场景下的支持 异步场景 异步调用，以 rpc 调用为例，每次 rpc 调用请求出去之后不会等待到结果返回之后才去发起下一次处理，这里有个时间差，在前一个 rpc 调用的 callback 回来之前，又一个新的 rpc 请求发起，此时当前线程中的 TracerContext 没有被清理，则 spanId 会自增，tracerId 相同。\n 对于上面这种情况，SOFATracer 在对于异步情况处理时，不会等到 callback 回来之后，调用 cr 阶段才会清理，而是提前就会清理当前线程的 tracerContext 上下文，从而来保证链路的正确性。\n线程池 目前来说，不管是 SOFARPC 还是 Dubbo 的埋点实现，在使用单线程或者线程池时，情况是一样的：\n 同步调用，线程池中分配一个线程用于处理 rpc 请求，在请求结束之前会一直占用线程；此种情况下不会造成下一个 rpc 请求错拿上一个请求的 tracerContext 数据问题 异步调用，由于异步回调并非是在 callback 中来清理上下文，而是提前清理的，所以也不会存在数据串用问题。 callback 异步回调，这个本质上就是异步调用，所以处理情况和异步调用相同。 附：案例工程\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/async/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e755346c441115663c101638667fe4c0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/async/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/async/","summary":"线程中使用 java.lang.Runnable 如果用户在代码中通过 java.lang.Runnable 新启动了线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFA","tags":null,"title":"异步线程处理","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/async/","wordcount":726},{"author":null,"categories":null,"content":" 本文用于帮助初次接触 MOSN 项目的开发人员，快速搭建开发环境，完成构建，测试，打包和示例代码的运行。\n注：MOSN 基于 Go 1.12.7 开发，使用 dep 进行依赖管理。\n准备运行环境 如果您使用容器运行 MOSN，请先 安装 docker 如果您使用本地机器，请使用类 Unix 环境 安装 Go 的编译环境 安装 dep : 参考官方安装文档 获取代码 MOSN 项目的代码托管在 Github，获取方式如下：\ngo get -u mosn.io/mosn 如果您的 go get 下载存在问题，请手动创建项目工程\n# 进入 GOPATH 下的 src 目录 cd $GOPATH/src # 创建 mosn.io 目录 mkdir -p mosn.io cd mosn.io # 克隆 MOSN 代码 git clone git@github.com:mosn/mosn.git cd mosn 最终 MOSN 的源代码代码路径为 $GOPATH/src/mosn.io/mosn\n导入IDE 使用您喜爱的 Go IDE 导入 $GOPATH/src/mosn.io/mosn 项目，推荐 Goland。\n编译代码 在项目根目录下，根据自己机器的类型以及欲执行二进制的环境，选择以下命令编译 MOSN 的二进制文件。\n使用 docker 镜像编译 make build // 编译出 linux 64bit 可运行二进制文件 本地编译 使用下面的命令编译本地可运行二进制文件。\nmake build-local 在非 Linux 机器交叉编译 Linux 64bit 可运行二进制文件。\nmake build-linux64 在非 Linux 机器交叉编译 Linux 32bit 可运行二进制文件。\nmake build-linux32 完成后可以在 build/bundles/${version}/binary 目录下找到编译好的二进制文件。\n打包 在项目根目录下执行如下命令进行打包。\nmake rpm 完成后可以在 build/bundles/${version}/rpm 目录下找到打包好的文件。\n创建镜像 执行如下命令进行镜像创建。\nmake image 运行测试 在项目根目录下执行如下命令运行单元测试：\nmake unit-test 在项目根目录下执行如下命令运行集成测试（较慢）。\nmake integrate 从配置文件启动 MOSN 运行下面的命令使用配置文件启动 MOSN。\n./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; 开启 MOSN 转发示例程序 参考 examples 目录下的示例工程运行 Samples。\n使用 MOSN 搭建 Service Mesh 平台 请参考与 Istio 集成。\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-setup/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d41615315adb522aa4b84762f113a574","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-setup/","summary":"本文用于帮助初次接触 MOSN 项目的开发人员，快速搭建开发环境，完成构建，测试，打包和示例代码的运行。 注：MOSN 基于 Go 1.12.7 开发，使用 dep 进行依赖管理。","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-setup/","wordcount":614},{"author":null,"categories":null,"content":" 本文档共分为四部分：\n 第一部分：在 Intellij IDEA 上安装 ACTS IDE 可视化编辑器； 第二部分：向您介绍如何在多模块工程中引入 ACTS 依赖； 第三部分：测试模块下一键搭建 ACTS 框架以管理后续 ACTS 用例； 第四部分：一键生成 ACTS 测试脚本； 1.安装 ACTS IDE 推荐使用 Intellij IDEA 2017，为了您的安全，请仅从该下载源获取 ACTS IDE 安装包： 点击下载 ACTS IDE，\n本地磁盘安装：Preference -\u0026amp;gt; Plugins -\u0026amp;gt; Install plugin from disk -\u0026amp;gt; Restart IDEA 即可。 2.引入 ACTS 依赖 在引入依赖之前，需要您的应用是一个多模块工程（包含 test 模块），后续 ACTS 会将全部的测试代码放置在 test 模块下以便管理 ACTS 用例。\n您可以依据应用的具体情况，选择性阅读以下内容：\n应用已经是完整的多模块工程，可参考文档 2.1 部分，帮助您引入 ACTS 依赖； 应用是多模块工程但无 test 模块，可参考文档 2.2 部分，帮助您快速添加 test 模块； 应用不是一个多模块工程，可参考文档 2.3 部分，帮助您快速构建多模块工程。 如果还没有创建工程，可参考 SOFABoot 快速开始搭建应用。\n2.1多模块应用-包含 test 模块 只需在 test 模块的 pom.xml 中引入 acts-bom 即可。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2多模块应用-无 test 模块 这里是使用 Intellij IDEA 来创建子模块。\n对着父工程右键 -\u0026amp;gt; New -\u0026amp;gt; Module -\u0026amp;gt; 输入 test 模块名字（一般是 appname-test），分步示例图如下：\n第一步：新建 test 模块 第二步：管理 test 模块 在父工程的 pom.xml 中管理刚刚新建的 test 模块。\n第三步：依赖 ACTS 引入 最后，找到刚刚新建的 test 模块，并在其 pom.xml 中引入 acts-bom 即可。\n\u0026amp;lt;!-- 引入包含 SOFABootApplication 的 pom --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.example\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;example-service\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- 引入 ACTS 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.3非多模块应用 如果你已经有了一个不错的 SOFABoot 应用，但它不是一个多模块应用，下面的内容将帮助你快速地将现有工程构建为多模块工程。\n第一步：新建父工程 创建好一个 SOFABoot 工程，然后删除无关的文件，只需保留 pom.xml 文件。\n第二步：新建子模块 新建子工程模块，将原有应用作为子工程并入父工程下，相关依赖管理提到父工程中。以新建 service 模块和 test 模块为例。\n第三步：管理子模块 第四步：依赖引入 最后，在 test 模块的 pom.xml 文件中引入 acts-bom 即可。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 3.一键初始化 ACTS 测试框架 下面只需要你轻轻动动手指即可完成初始化工作。在图3.2中，您需要正确填写应用名称并选择适合应用的编码格式。\n有关一键初始化生成的文件有何作用，可以参考 ACTS 使用手册的框架准备部分。\n4.一键生成测试脚本 4.1启动类 将 service 模块中的启动类，如 SOFABootApplication 拷贝到 test 模块，并增加需要加载的配置文件：classpath*:META-INF/spring/acts-core.xml\n4.2测试脚本 前提条件：务必 mvn 编译工程和生成对象模型，否则会造成 ACTS IDE 不可预料的错误，如无法编辑、数据不正确等。\n接口定义的方法上点击，选择 ACTS 功能 -\u0026amp;gt; 生成测试用例，并在刚生成的测试脚本中矫正 SOFABoot 启动类的 import 位置。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/getting-started/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"dfc5fb9b394ea14c280568dcb881a8b0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/getting-started/","summary":"本文档共分为四部分： 第一部分：在 Intellij IDEA 上安装 ACTS IDE 可视化编辑器； 第二部分：向您介绍如何在多模块工程中引入 ACTS 依赖； 第三部分：测试模块下一键搭建 ACTS 框","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-acts/getting-started/","wordcount":1074},{"author":null,"categories":null,"content":" 在本文档中，将创建一个 Spring Boot 的工程，引入 SOFABoot 基础依赖，并且引入 SOFABoot 的健康检查扩展能力，演示如何快速上手 SOFABoot。\n环境准备 要使用 SOFABoot，需要先准备好基础环境，SOFABoot 依赖以下环境： - JDK7 或 JDK8 - 需要采用 Apache Maven 3.2.5 或者以上的版本来编译\n创建工程 SOFABoot 是直接构建在 Spring Boot 之上，因此可以使用 Spring Boot 的工程生成工具 来生成，在本文档中，我们需要添加一个 Web 的依赖，以便最后在浏览器中查看效果。\n引入 SOFABoot 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。 然后，添加 SOFABoot 健康检查扩展能力的依赖及 Web 依赖(方便查看健康检查结果)：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 最后，在工程的 application.properties 文件下添加 SOFABoot 工程常用的参数配置，其中 spring.application.name 是必需的参数，用于标示当前应用的名称；logging path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFABoot Demo # logging path logging.path=./logs 运行 可以将工程导入到 IDE 中运行生成的工程里面中的 main 方法（一般上在 XXXApplication 这个类中）启动应用，也可以直接在该工程的根目录下运行 mvn spring-boot:run，将会在控制台中看到启动打印的日志：\n2018-04-05 21:36:26.572 INFO ---- Initializing ProtocolHandler [\u0026amp;quot;http-nio-8080\u0026amp;quot;] 2018-04-05 21:36:26.587 INFO ---- Starting ProtocolHandler [http-nio-8080] 2018-04-05 21:36:26.608 INFO ---- Using a shared selector for servlet write/read 2018-04-05 21:36:26.659 INFO ---- Tomcat started on port(s): 8080 (http) 可以通过在浏览器中输入 http://localhost:8080/sofaboot/versions 来查看当前 SOFABoot 中使用 Maven 插件生成的版本信息汇总，结果类似如下：\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Built-Time: \u0026amp;quot;2018-04-05T20:55:26+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.4\u0026amp;quot; } ] 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，sofaboot/versions 更改为 actuator/versions\n可以通过在浏览器中输入 http://localhost:8080/health/readiness 查看应用 Readiness Check 的状况，类似如下：\n{ status: \u0026amp;quot;UP\u0026amp;quot;, sofaBootComponentHealthCheckInfo: { status: \u0026amp;quot;UP\u0026amp;quot; }, springContextHealthCheckInfo: { status: \u0026amp;quot;UP\u0026amp;quot; }, DiskSpace: { status: \u0026amp;quot;UP\u0026amp;quot;, total: 250140434432, free: 22845308928, threshold: 10485760 } } 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，health/readiness 更改为 actuator/readiness\nstatus: \u0026amp;quot;UP\u0026amp;quot; 表示应用 Readiness Check 健康的。可以通过在浏览器中输入 http://localhost:8080/health 来查看应用的运行时健康状态（可能会随着时间发生变化）。\n注: 在 SOFABOOT 3.X 中调整了 endpoint 路径，/health 更改 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/quick-start/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7f582b905fde4a56791c03d4dd6b5a57","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/quick-start/","summary":"在本文档中，将创建一个 Spring Boot 的工程，引入 SOFABoot 基础依赖，并且引入 SOFABoot 的健康检查扩展能力，演示如何快速上手 SOFABoot。 环境准备 要使用 SOFABo","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-boot/quick-start/","wordcount":2154},{"author":null,"categories":null,"content":" 这个快速开始可以帮您快速在您的电脑上，下载、安装并使用 SOFADashboard。\n环境准备 sofa-dashboard-backend 依赖 Java 环境来运行。请确保是在以下运行环境可以正常使用:\n JDK 1.8+；下载 \u0026amp;amp; 配置。 Maven 3.2.5+；下载 \u0026amp;amp; 配置。 sofa-dashboard-frontend 使用了 Ant Design Pro 脚手架，前端环境请参考 Ant Design\n数据库初始化 Mysql 版本：5.6+\n SOFAArk 管控需要依赖 MySQL 进行资源数据存储，工程目录下有一个 SofaDashboardDB.sql 脚本文件，可以通过执行这个脚本文件进行数据库表的初始化。\nZookeeper  ZooKeeper 3.4.x and ZooKeeper 3.5.x\n SOFADashboard 中的服务治理、SOFAArk 管控依赖于 Zookeeper，需要本地启动 Zookeeper 服务： ZooKeeper Document。\n后端运行 \u0026amp;gt; git clone https://github.com/sofastack/sofa-dashboard.git \u0026amp;gt; cd sofa-dashboard \u0026amp;gt; mvn clean package -DskipTests \u0026amp;gt; cd sofa-dashboard-backend/sofa-dashboard-web/target/ \u0026amp;gt; java -jar sofa-dashboard-web-1.0.0-SNAPSHOT.jar 前端运行 sofa-dashboard-front 是 SOFADashboard 的前端代码工程，基于蚂蚁金服开源的前端框架 antd 开发。\n\u0026amp;gt; cd sofa-dashboard-front \u0026amp;gt; npm i \u0026amp;gt; npm run dev 案例工程 sofastack-dashboard-guides ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/quick-start/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"fa4c5f48810727f71d675255f19617a3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/quick-start/","summary":"这个快速开始可以帮您快速在您的电脑上，下载、安装并使用 SOFADashboard。 环境准备 sofa-dashboard-backend 依赖 Java 环境来运行。请确保是在以下运行环境可以正常","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/quick-start/","wordcount":313},{"author":null,"categories":null,"content":"SOFARPC 有多种编程界面，下面会对各种界面进行举例： - SOFARPC 方式 - SOFABoot 方式\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"990bb2211b02b04c3ab6e03f3ba1f74b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started/","summary":"SOFARPC 有多种编程界面，下面会对各种界面进行举例： - SOFARPC 方式 - SOFABoot 方式","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started/","wordcount":30},{"author":null,"categories":null,"content":" SOFATracer 接入的组件列表参考：SOFATracer 介绍，在使用时请注意不同组件对应的SOFATracer 版本和 JDK 版本。\n环境准备 要使用 SOFABoot，需要先准备好基础环境，SOFABoot 依赖以下环境： - JDK7 或 JDK8 - 需要采用 Apache Maven 3.2.5 或者以上的版本来编译\n示例列表 下面所有 Samples 工程均为 SOFABoot 工程(同时支持 SpringBoot 工程中使用)，关于如何创建 SOFABoot 工程请参考 SOFABoot 快速开始。\n 组件接入 Spring MVC 埋点接入 HttpClient 埋点接入 DataSource 埋点接入 RestTemplate 埋点接入 OkHttp 埋点接入 Dubbo 埋点接入 采样 上报数据到 Zipkin ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/component-access/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"143f2b9022161ae5a7b10d261752ae5f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/component-access/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/component-access/","summary":"SOFATracer 接入的组件列表参考：SOFATracer 介绍，在使用时请注意不同组件对应的SOFATracer 版本和 JDK 版本。 环境准备 要使用 SOFABoot","tags":null,"title":"快速开始指南","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/component-access/","wordcount":209},{"author":"向旭","categories":null,"content":"TODO\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/code-analyze/summary/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d6fe0ca21825accb191a9eedccf17358","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/summary/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/summary/","summary":"TODO","tags":null,"title":"总览","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/summary/","wordcount":1},{"author":null,"categories":null,"content":" SOFATracer 此前的埋点均是基于组件维度的埋点，用户很难在自己业务代码中进行埋点操作，或者增加自定义 tag 值来监控一些链路信息。基于此，SOFATracer 从 2.4.1\u0026amp;frasl;3.0.6 版本开始支持手动埋点和基于注解的埋点方式，帮助用户解决自定义埋点问题。\n使用方式 自定义埋点提供了两种方式，一种是手动埋点，一种是基于注解方式埋点。\n手动埋点 手动埋点的方式遵循 opentracing 规范，SOFATracer 中通过 beforeInvoke 和 afterInvoke 两个函数封装了 span 的周期，如下：\n// 注入 tracer @Autowired Tracer tracer; private void testManual(){ try { // beforeInvoke 开始 SofaTracerSpan sofaTracerSpan = ((FlexibleTracer) tracer).beforeInvoke(\u0026amp;quot;testManual\u0026amp;quot;); sofaTracerSpan.setTag(\u0026amp;quot;manualKey\u0026amp;quot;,\u0026amp;quot;glmapper\u0026amp;quot;); // do your biz } catch (Throwable t){ // 异常结束 ((FlexibleTracer) tracer).afterInvoke(t.getMessage()); } finally { // 正常结束 ((FlexibleTracer) tracer).afterInvoke(); } } 这种方式在使用上没有直接使用注解方便，但是可以直观的了解到 span 的生命周期，另外手动埋点也是对基于注解方式埋点的一种补充，下面介绍。\n基于注解方式 SOFATracer 中提供了 @Tracer 注解，其作用域是 method 级别。\n// 在 hello 方法上使用 @Tracer 注解进行埋点 @Tracer public String hello(String word){ // 自定义 tag 数据 SpanTags.putTags(\u0026amp;quot;author\u0026amp;quot;,\u0026amp;quot;glmapper\u0026amp;quot;); // 失效 helloInner(word); return \u0026amp;quot;glmapper : hello \u0026amp;quot; + word; } // 在 hello 方法上使用 @Tracer 注解进行埋点 @Tracer private String helloInner(String word){ return \u0026amp;quot;glmapper : hello \u0026amp;quot; + word; } @Tracer 是基于 Spring Aop 实现，因此一定程度上依赖 Spring 中的代理机制。如代码片段中所示，helloInner 方法由于执行过程中不会使用代理对象，而是 this，所以会导致 helloInner 的注解埋点失效。那么对于此种情况，就可以使用手动埋点的方式来弥补。\nSpanTags 是 SOFATracer 中提供的工具类，在使用注解或者手动埋点的情况下，可以通过此类提供的静态方法来设置 tag 。\n日志格式 json 格式 {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-05 10:23:53.549\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;flexible-sample\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9291567650233504100130712\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.2\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;4ms\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;hello\u0026amp;quot;,\u0026amp;quot;param.types\u0026amp;quot;:\u0026amp;quot;java.lang.String\u0026amp;quot;,\u0026amp;quot;author\u0026amp;quot;:\u0026amp;quot;glmapper\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} 非 json 格式 2019-09-05 10:25:50.992,flexible-sample,0a0fe9291567650350953100130778,0.2,client,,http-nio-8080-exec-1,4ms,hello,param.types=java.lang.String\u0026amp;amp;author=glmapper\u0026amp;amp;,,\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/flexible/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5aaadb77e734e58428a0852d14888e92","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/flexible/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/flexible/","summary":"SOFATracer 此前的埋点均是基于组件维度的埋点，用户很难在自己业务代码中进行埋点操作，或者增加自定义 tag 值来监控一些链路信息。基于此，SOFATracer","tags":null,"title":"手动埋点","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/flexible/","wordcount":566},{"author":null,"categories":null,"content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAArk 实现原理》第二篇，本篇作者盲僧，来自 OYO。《剖析 | SOFAArk 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附系列共建列表，目前已完成领取。\n前言 SOFAArk 是 SOFA 团队开源的又一款扛鼎力作，它是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署的能力。\n从 2016 年底开始，蚂蚁金服内部开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2021 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构，也是为系列文章做好铺垫。\nSOFAArk Biz 的打包插件是 sofa-ark-maven-plugin ，它可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式的 Ark 包或者 Ark Biz 包，关于 Ark 包和 Ark Biz 包可以参考这里：\n Ark 包：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/ Ark Biz：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/ 本文将从如下三个方面进行介绍：先对插件的使用和打包出来的产物做一个简单介绍，然后告诉大家调试插件的方法，最后对整个插件的原理做一个流程图和阐述。\nSOFAArk ：https://github.com/sofastack/sofa-ark\nSOFAArk 插件使用 文中的示例代码可以参考 我的 github。\n 插件使用 先将 Spring Boot 的打包插件 spring-boot-maven-plugin 删除或者注释，然后再引入如下插件即可：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \n执行 mvn package 命令后，将会打出如下结构的 3 个 jar 包，大家可以自行解压这三个 jar 包，看一看里面的具体内容，下面我们简单分析一下：\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT.jar ：它是 maven 插件打出来的原生 jar 包，只包含我们写的代码和 manifest 文件，无特殊意义。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-biz.jar ：这个 jar 包称之为 Ark Biz 包，因为 SOFAArk 容器是支持运行多个 Ark Biz 的，所以打成这种包是为了和别的项目一起合并部署使用，另外 Ark 包里也包含了这个。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-executable.jar ：这个 jar 包称之为 Ark 包，从字面上来看它是一个可执行的 jar 包，即意味着它是一个可以用 java -jar 命令来单独运行的 Fat Jar，类似于我们用 Spring Boot 插件打出来的包。\n后面的分析主要是围绕 Ark 包来做讲解，因为它包含了 Ark Biz 包，所以只要搞明白它是如何生成的，那么对整个插件的原理也就基本了解了。\n与 Spring Boot 插件对比 要想分析出 sofa-ark-maven-plugin 插件的作用，我们需要先和 Spring Boot 的插件进行对比，从打包产物上直观的感受一下两者的区别。\nspring-boot-maven-plugin 插件 spring-boot-maven-plugin 是 SpringBoot 默认提供的打包插件，其功能就是将工程打包成一个可执行的 FATJAR。spring-boot-maven-plugin 打包产物的目录结构如下：\n. ├── BOOT-INF │ ├── classes # 应用的字节码目录 │ └── lib # 应用所依赖的 jar 包 ├── META-INF │ ├── MANIFEST.MF # manifest 文件信息 │ └── maven # 应用的坐标信息 └── org └── springframework └── boot └── loader # 存放的是 Spring Boot Loader 的 class 文件 ├── JarLauncher.class # Spring Boot 启动类 ├── archive ├── data ├── jar └── util MANIFEST.MF 文件内容：\nManifest-Version: 1.0 Archiver-Version: Plexus Archiver Built-By: rrz Start-Class: pers.masteryourself.tutorial.sofa.ark.maven.plugin.MavenP luginApplication Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Spring-Boot-Version: 2.1.4.RELEASE Created-By: Apache Maven 3.5.3 Build-Jdk: 1.8.0_101 Main-Class: org.springframework.boot.loader.JarLauncher MANIFEST.MF 文件中可以看到，描述了当前 jar 的一些核心元素，包括启动类、class 文件路径、lib 依赖路径、jdk 版本等等，这里需要关注的是 Main-Class，SpringBoot 就是通过该类来引导启动的。SOFAArk 应用也提供了类似的引导类及其自身特殊的结构， …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-build-package-plugin/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5ebfd73573e2f2d529f0303da2fe026c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":null,"title":"打包插件","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","wordcount":2994},{"author":null,"categories":null,"content":" 1. 集成部署模式 1.1 扩容 registry-integration 假设目前已经部署了 3 台 registry-integration，分别是 node1/node2/node3，扩容的新节点是 node4。\n操作步骤：\n第一步. 部署新的 registry-integration 节点\n首先参考部署文档，将 registry-integration.tgz 在新节点 node4 上部署起来，值得注意的是，node4 需要将 nodes.metaNode 配置项指定为4台机器的地址列表：\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt; 在这一步中，node4启动完成后，访问 curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check 状态显示是不健康，因为 node4 尚未加入集群，要加入集群，需要做第二步。\n第二步. 调用 changePeer 使新节点加入集群\n对已经存在的 node1/node2/node3 的任意一台，执行“修改节点列表”的运维命令，将原有由 node1/node2/node3 构成的集群，改为 node1/node2/node3/node4 集群：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check 状态显示应当是健康。\n1.2 缩容 registry-integration 假设集群目前有3台机器 node1/node2/node3，需要缩容 node3。\n1.2.1 平滑缩容 操作步骤：\n第一步. 调用 changePeer 移除节点\n对 node1/node2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“node1/node2/node3”改为“node1/node2”，即把node3移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;node3\u0026amp;gt;:9615/health/check 状态显示应当是不健康的，因为 node3 已经被踢出了集群。\n**第二步.关闭 node3 **\n这一步可选，因为 node3 已经被移除集群了，所以即便 node3 还在运行，也对原集群不影响。\n1.2.2 宕机处理 假设 node3 已经宕机，也需要将 node3 移除出集群\n操作步骤：\n第一步. 调用 changePeer 移除节点\n对 node1/node2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“node1/node2/node3”改为“node1/node2”，即把 node3 移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 2. 独立部署模式 2.1 扩容 registry-meta 假设目前已经部署了3台 registry-meta ，分别是 metaNode1/metaNode2/metaNode3，扩容的新节点是 metaNode4.\n操作步骤：\n第一步. 部署新的 registry-meta 节点\n首先参考部署文档，将 registry-meta.tgz 在新节点 metaNode4 上部署起来，值得注意的是，metaNode4 需要将 nodes.metaNode 配置项指定为4台机器的地址列表：\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;,\u0026amp;lt;metaNode3\u0026amp;gt;,\u0026amp;lt;metaNode4\u0026amp;gt; 在这一步中，metaNode4 启动完成后，访问 curl http://localhost:9615/health/check 状态显示是不健康，因为 metaNode4 尚未加入集群，要加入集群，需要做第二步。\n第二步. 调用 changePeer 使新节点加入集群\n对已经存在的 metaNode1/metaNode2/metaNode3 的任意一台，执行“修改节点列表”的运维命令，将原有由 metaNode1/metaNode2/metaNode3 构成的集群，改为 metaNode1/metaNode2/metaNode3/metaNode4 集群：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;metaNode1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;,\u0026amp;lt;metaNode3\u0026amp;gt;,\u0026amp;lt;metaNode4\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://localhost:9615/health/check 状态显示应当是健康。\n2.2 缩容 registry-meta 假设集群目前有3台机器 metaNode1/metaNode2/metaNode3，需要缩容 metaNode3。\n2.2.1 平滑缩容 操作步骤：\n第一步. 调用 changePeer 移除节点\n对 metaNode1/metaNode2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“metaNode1/metaNode2/metaNode3”改为“metaNode1/metaNode2”，即把 metaNode3 移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;metaNode1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;metaNode3\u0026amp;gt;:9615/health/check 状态显示应当是不健康的，因为metaNode3已经被踢出了集群。\n第二步. 关闭 metaNode3\n这一步可选，因为 metaNode3 已经被移除集群了，所以即便 metaNode3 还在运行，也对 …","date":-62135596800,"description":"","dir":"projects/sofa-registry/scale/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"57de6dc4da1292063ff25ecea9ffbd08","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/scale/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/scale/","summary":"1. 集成部署模式 1.1 扩容 registry-integration 假设目前已经部署了 3 台 registry-integration，分别是 node1/node2/node3，扩容的新节点","tags":null,"title":"扩容与缩容","type":"projects","url":"/sofastack.tech/projects/sofa-registry/scale/","wordcount":1695},{"author":null,"categories":null,"content":" 自定义引擎各个阶段 可以在测试脚本中或者基类中重写 ActsTestBase 提供的 API。\n 重写 prepare，execute，check，clear 等。可以通过在 super.prepare() 之前或者之后进行某些操作。 重写 process 方法，在 super.process() 之前或之后进行操作。可将整个脚本重新编排，例如在现有的清理 -\u0026amp;gt; 准备 -\u0026amp;gt; 执行 -\u0026amp;gt; 校验流程中增加一些个性化的步骤。 重写 beforeActsTest、afterActsTest，可以在每一个用例运行前后做一些个性化的操作，如准备上下文、缓存刷新等。 参数化 在结果期望和数据库期望中可以使用 $变量名 来标识某个值是变量，测试脚本中可以把值设置进去； 支持范围：入参、返回结果、数据库表字段，支持类型：目前仅支持 String 的参数化。\n使用方法：\n（1）界面以 $ 开头定义变量\n（2）代码中给变量赋值\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { actsRuntimeContext.paramMap.put(\u0026amp;quot;roleId\u0026amp;quot;, \u0026amp;quot;123\u0026amp;quot;); actsRuntimeContext.refreshDataParam(); } 在写 DB 数据期望的时候，也可以通过 = 符号来进行赋值，表示这个值来自于查询结果，后面的表就可以使用这个变量作为值。\n假设接口会向 2 张表插入数据。\n id_A value_A 123 abc id_B value_B abc efg 查询的时候要先通过接口返回的 A 表的 id_A 查到 value_A, 然后把 value_A 作为 B 表的查询条件，在插件上面可以这样写：\n 字段 flag 值 id_A C $param1 value_A Y =param2 字段 flag 值 id_B C $param2 value_B Y efg 上面操作说明：\n =param2 和 $param2 的操作，表示框架会先从 A 表查出 value_A 然后 select from B where id_B = value_A，进而得到全部 B 表的属性值； $param1 表示可以在代码中对 id_A 赋值，代码形如： actsRuntimeContext.paramMap.put(\u0026amp;quot;param1\u0026amp;quot;,\u0026amp;quot;123\u0026amp;quot;); 表示对变量 param1 赋值 123，上述代码可以写到脚本的 beforeActsTest 里面，这样在查询 A 表之前，框架就会将 123 赋值给 id_A。\n参数组件化 目前仅支持 String 的组件化\n如果属性是需要动态生成的字符串，例如某些 ID，可以通过 @ 符号来调用一个组件生成这个属性，组件要放在跟 test 同级的 component 包下，即：com.corpname.appname.acts.component (这里appname是系统名，corpname是公司名，如alipay)。\npublic class MyComponent { @TestComponent(id = \u0026amp;quot;test\u0026amp;quot;) public String test(String param) { return param+\u0026amp;quot;123\u0026amp;quot;; } } 并通过 acts-config.properties 配置指明参数化组件使其生效，多个组件使用英文逗号 , 分隔，末尾注意不必要的空格。\nparam_components=IdGenerateComponent,NoGenerateComponent 如上图 alis_value 值为 @test?param=123 则在用例运行时会自动替换 alis_value 的取值。\n组件的 ID 要保证唯一，否则默认调用第一个，如果声明了一个无参组件方法，调用方式为 @test 即可，同时支持组件化参数通过变量传入：@test?param=$id，实际执行时会替换 $id 的值为实际值。\n脚本中也可以通过代码调用：\nActsComponentUtil.run(\u0026amp;quot;@test?param=123\u0026amp;quot;); 自定义组件多个参数的场景使用 \u0026amp;amp; 分割参数，如 @test?param1=xxx\u0026amp;amp;param2=yyy\nDB 工具类 1. 指定数据源进行 DB 表访问 框架 ActsDBUtils 中提供了 DB 的指定数据源访问，用于个性化 DB 操作。例如某张表的某条纪录不是准备数据也不是校验数据，但是需要在运行后删掉或更新，此时就需要用到该工具操作 DB 数据。\n使用前配置\n使用指定数据源方式需要在 acts-config.properties 文件中首先将要指定的数据源进行配置，配置例子如下：\ndatasource_bean_name_exampleDataSource=com.alipay.example.dal;exampleDataSource #整体配置的格式为：datasource_bean_name_xxx(数据源名字)=yyy(数据源所在 Module);xxx(数据源名字) 指定数据源方法\nActsDBUtils 工具类中指定数据源方法说明：\npublic static int getUpdateResultMap(String sql,String tableName,String dbConfigKey); 该方法用于指定数据源进行表的增、删和改的操作。sql 为标准 sql 语句，tableName 为逻辑表名，dbConfigKey 为该 表所在的逻辑数据源配置，与 acts-config.properties 配置的 xxx（数据源名字）相同。\npublic static List\u0026amp;lt;Map\u0026amp;lt;String, Object\u0026amp;gt;\u0026amp;gt; getQueryResultMap(String sql, String tableName,String dbConfigKey); 该方法用于指定数据源进行表的查询操作，以上两个方法都是原子化的 DB 表的操作，如果有其他的 DB 需求可以在上面进行 封装。\n2. 不指定数据源进行 DB 表访问 该方式下 ACTS 框架默认根据表名搜索数据源，工具方法的使用步骤如下：\n使用前配置\ndatasource_bundle_name=com.alipay.example.common.dal ds_exampleDataSource=table1,tabal2 #整体配置的格式为 #datasource_bundle_name=数据源所在模块名 #ds_数据源名字=该数据源下的逻辑表名 不指定数据源方法\npublic static int getUpdateResultMap(String …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-api/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ce7e264713a6f7a3f0672e2432489f59","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-api/","summary":"自定义引擎各个阶段 可以在测试脚本中或者基类中重写 ActsTestBase 提供的 API。 重写 prepare，execute，check，clear 等。可以通过在 super.prepare() 之","tags":null,"title":"扩展功能","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-api/","wordcount":1955},{"author":null,"categories":null,"content":" ExtensionLoader 为了对 SOFARPC 各个环节的都有充足的可扩展性，SOFA-RPC定义了一套十分灵活的扩展机制，所有扩展实现都是平等的。\n这套机制不管是对SOFA-RPC本身的开发者其使用者而言都是非常有用的。SOFA-RPC将其自身抽象为了多个模块，各个模块之间无显示依赖，通过SPI的方式进行交互。\n这套扩展机制抽象了这一SPI的交互方式。如果你读了上面文档讲到的 Filter 和 Router，应该已经有所体会。\n这里讲一下如何使方式进行扩展的。\nSOFARPC 提供了 ExtensionLoader 的能力。\n扩展点设计 SOFARPC 定义了一个注解 @Extensible，该注解标识在接口或者抽象类上，标识该类是一个扩展点。即告诉 SOFARPC 该类是可扩展的，需要寻找该扩展点的实现，同时也定义了寻找实现类的文件名称，是否单例。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * 指定自定义扩展文件名称，默认就是全类名 * * @return 自定义扩展文件名称 */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * 扩展类是否使用单例，默认使用 * * @return 是否使用单例 */ boolean singleton() default true; /** * 扩展类是否需要编码，默认不需要 * * @return 是否需要编码 */ boolean coded() default false; } SOFARPC 同时定义了 @Extension 注解，标识该类是一个扩展实现类。也定义了扩展点在文件中寻找扩展实现时使用的名字。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * 扩展点名字 * * @return 扩展点名字 */ String value(); /** * 扩展点编码，默认不需要，当接口需要编码的时候需要 * * @return 扩展点编码 * @see Extensible#coded() */ byte code() default -1; /** * 优先级排序，默认不需要，大的优先级高 * * @return 排序 */ int order() default 0; /** * 是否覆盖其它低{@link #order()}的同名扩展 * * @return 是否覆盖其它低排序的同名扩展 * @since 5.2.0 */ boolean override() default false; /** * 排斥其它扩展，可以排斥掉其它低{@link #order()}的扩展 * * @return 排斥其它扩展 * @since 5.2.0 */ String[] rejection() default {}; } 新增扩展点 1.定义扩展点。\n@Extensible public interface Person { void getName(); } 2.定义扩展实现\n@Extension(\u0026amp;quot;A\u0026amp;quot;) public class PersonA implements Person{ @Override public void getName() { System.out.println(\u0026amp;quot;li wei\u0026amp;quot;); } } 3.编写扩展描述文件：META-INF/services/sofa-rpc/com.alipay.sofa.rpc.extension.Person。文件内容如下：\nA=com.alipay.sofa.rpc.extension.PersonA 4.加载扩展点，获取到扩展实现类使用。\nPerson person = ExtensionLoaderFactory.getExtensionLoader(Person.class).getExtension(\u0026amp;quot;A\u0026amp;quot;); 已有扩展点 如果想对 SOFARPC 的各个内置扩展点进行功能扩展，可直接实现已有扩展，配置扩展模式文件即可。\n目前已有的扩展点如下：\n 接口名 中文名 备注 内置实现 com.alipay.sofa.rpc.client.Client 客户端 Failover、Failfast com.alipay.sofa.rpc.client.ConnectionHolder 连接管理器 AllConnect（全部连接） com.alipay.sofa.rpc.client.AddressHolder 地址管理器 单组、多组 com.alipay.sofa.rpc.client.LoadBalancer 负载均衡 随机、轮询、最少并发、一致性hash、本机优先 com.alipay.sofa.rpc.client.Router 路由器 com.alipay.sofa.rpc.codec.Compressor 压缩 snappy、quicklz com.alipay.sofa.rpc.codec.Serializer 序列化器 java、hessian、pb com.alipay.sofa.rpc.filter.Filter 拦截器 com.alipay.sofa.rpc.protocol.Protocol 协议 bolt、dubbo、rest com.alipay.sofa.rpc.protocol.ProtocolDecoder 协议解码 bolt com.alipay.sofa.rpc.protocol.ProtocolEncoder 协议编码 bolt com.alipay.sofa.rpc.protocol.TelnetHandler telnet的响应 version、help、ls com.alipay.sofa.rpc.proxy.Proxy 代理类 java、javassist com.alipay.sofa.rpc.registry.Registry 注册中心 zookeeper com.alipay.sofa.rpc.server.Server 服务端实现 bolt、rest com.alipay.sofa.rpc.transport.ClientTransport 客户端长连接实现 netty com.alipay.sofa.rpc.transport.ServerTransport 服务端长连接实现 netty ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/extension-loader/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"acc5628da3a7ea2df5eb68bd8ec17159","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/extension-loader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/extension-loader/","summary":"ExtensionLoader 为了对 SOFARPC 各个环节的都有充足的可扩展性，SOFA-RPC定义了一套十分灵活的扩展机制，所有扩展实现都是平等的。 这套机制不管是对SOFA-RP","tags":null,"title":"扩展点设计","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/extension-loader/","wordcount":1131},{"author":null,"categories":null,"content":" SOFARPC 的服务发布和引用的基本配置已经在「编程界面」章节中说明，这里主要介绍服务发布和引用的一些特性。\n同一服务发布多种协议 在 SOFARPC 中，可以将同一个服务发布成多个协议，让调用端可以使用不同的协议调用服务提供方。\n如果使用 Java API，可以按照如下的代码构建多个 ServerConfig，不同的 ServerConfig 设置不同的协议，然后将这些 ServerConfig 设置给 ProviderConfig：\nServerConfig serverConfigA = new ServerConfig(); ServerConfig serverConfigB = new ServerConfig(); List\u0026amp;lt;ServerConfig\u0026amp;gt; serverConfigs = new ArrayList\u0026amp;lt;ServerConfig\u0026amp;gt;(); serverConfigs.add(serverConfigA); serverConfigs.add(serverConfigB); providerConfig.setServer(serverConfigs); 如果使用 XML 的方式，直接在 \u0026amp;lt;sofa:service\u0026amp;gt; 标签中增加多个 binding 即可：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 如果使用 Annotation 的方式，在 @SofaService 中增加多个 binding 即可：\n@SofaService( interfaceType = SampleService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;), @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) } ) public class SampleServiceImpl implements SampleService { // ... } 同一服务注册多个注册中心 如果使用 API 的方式，构建多个 RegistryConfig 设置给 ProviderConfig 即可：\nRegistryConfig registryA = new RegistryConfig(); RegistryConfig registryB = new RegistryConfig(); List\u0026amp;lt;RegistryConfig\u0026amp;gt; registryConfigs = new ArrayList\u0026amp;lt;RegistryConfig\u0026amp;gt;(); registryConfigs.add(registryA); registryConfigs.add(registryB); providerConfig.setRegistry(registryConfigs); 如果是使用 XML 的方式\n需要在properties里配置注册中心\ncom.alipay.sofa.rpc.registries.zookeeper=zookeeper://127.0.0.1:2181 com.alipay.sofa.rpc.registries.nacos=nacos://127.0.0.1:8848 \u0026amp;lt;bean id=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacadeImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;nacos,zookeeper\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 如果使用 Annotation 的方式\n需要在properties里配置注册中心\ncom.alipay.sofa.rpc.registries.zookeeper=zookeeper://127.0.0.1:2181 com.alipay.sofa.rpc.registries.nacos=nacos://127.0.0.1:8848 @SofaService(bindings = {@SofaServiceBinding(registry = \u0026amp;quot;nacos\u0026amp;quot;), @SofaServiceBinding(registry = \u0026amp;quot;zookeeper\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { // ... } 方法级参数设置 在 Java API 方式中，调用 MethodConfig 对象相应的 set 方法即可设置对应的参数，如下所示：\nMethodConfig methodConfigA = new MethodConfig(); MethodConfig methodConfigB = new MethodConfig(); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfigA); methodConfigs.add(methodConfigB); providerConfig.setMethods(methodConfigs); //服务端设置 consumerConfig.setMethods(methodConfigs); //客户端设置 使用 XML 的方式，在对应的 binding 里面使用 \u0026amp;lt;sofa:method\u0026amp;gt; 标签即可设置对应的参数：\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/publish-and-reference/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"6a78b8b84b226eaf1e6d2b1ff1d15fee","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/publish-and-reference/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/publish-and-reference/","summary":"SOFARPC 的服务发布和引用的基本配置已经在「编程界面」章节中说明，这里主要介绍服务发布和引用的一些特性。 同一服务发布多种协议 在 SOFARPC 中，可以将同一个服务","tags":null,"title":"服务发布与引用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/publish-and-reference/","wordcount":699},{"author":null,"categories":null,"content":" 自动化 推荐版本: ES 5\n自动初始化库 Lookout 服务器端启动时，会自动检查（默认开启，可关闭）所连接的ES机器(或集群)，检查 Metrics 数据存储的 Index和 Mapping 是否已经建立， 如果未初始化则进行初始化工作。默认初始化并产生索引alias: \u0026amp;ldquo;lookout-active-metrics，lookout-search-metrics\u0026amp;rdquo;。\n 看下 Alias 和 Indices\nhttp://localhost:9200/_cat/aliases lookout-active-metrics metrics-2019.05.30-1 - - - lookout-search-metrics metrics-2019.05.30-1 - - - 看下存储 Mapping：\nhttp://localhost:9200/lookout-active-metrics/_mapping { \u0026amp;quot;metrics-2019.05.30-1\u0026amp;quot;: { \u0026amp;quot;mappings\u0026amp;quot;: { \u0026amp;quot;metrics\u0026amp;quot;: { \u0026amp;quot;properties\u0026amp;quot;: { \u0026amp;quot;id\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;keyword\u0026amp;quot; }, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;keyword\u0026amp;quot; }, \u0026amp;quot;time\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;date\u0026amp;quot; }, \u0026amp;quot;value\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;float\u0026amp;quot; } } } } } } 自动运维 自动 Indices Rollover\n 如果超过1天，则切换新索引 如果单个索引的 docs 数目超过: 100000000，则切换新索引； 自动删除过期 Indices\n 默认最多只保留 7 天的数据，过期的 Index 会自动检查并被删除；\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-es/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"016a397aa24e885b5aaa32cf1cac3f35","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-es/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-es/","summary":"自动化 推荐版本: ES 5 自动初始化库 Lookout 服务器端启动时，会自动检查（默认开启，可关闭）所连接的ES机器(或集群)，检查 Metrics 数据存储的 Index和 Mapping 是","tags":null,"title":"服务器端 ES 存储使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-es/","wordcount":315},{"author":null,"categories":null,"content":"由于 SOFALookout Metrics Server 兼容 Prometheus API,所以 Grafana 集成 Lookout 很简单，只需要选择 Prometheus 作为数据源协议即可 （注意 Lookout Server 的默认查询端口也是: 9090）。\n下图展示 Grafana 新增数据源配置:\n使用 PromQL 查询展示数据:\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-grafana/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"45b8a5084ac2a151af28ff11413b13cb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","summary":"由于 SOFALookout Metrics Server 兼容 Prometheus API,所以 Grafana 集成 Lookout 很简单，只需要选择 Prometheus 作为数据源协议即可 （注意 Lookout Server 的默认查询端口也是: 9090）。 下图展示 Grafana 新增数据源配置","tags":null,"title":"服务器端 Grafana 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","wordcount":81},{"author":null,"categories":null,"content":" 如果需要扩展支持适配一个新的数据存储，可能需要下面的步骤:\n1.写入适配 需要在 gateway/metrics/exporter/ 下面添加新的 exporter; 参考已有的 \u0026amp;ldquo;gateway/metrics/exporter/elasticsearch\u0026amp;rdquo; 模块；\n 提供个新存储的 MetricExporter 功能是写入数据到存储中，参考\u0026amp;rdquo;com.alipay.sofa.lookout.gateway.metrics.exporter.es.ESMetricExporter\u0026amp;rdquo;，提供个新存储的 MetricExporter；\n 提供个该模块的spring配置类 参考 \u0026amp;ldquo;com.alipay.sofa.lookout.gateway.metrics.exporter.es.spring.bean.config.EsExporterConfiguration\u0026amp;rdquo;，它包括 ESProperties 的配置描述映射。尤其重要的是带有注解 @ConditionalOnExporterComponent方便该功能开关；\n 在 \u0026amp;ldquo;com.alipay.sofa.lookout.gateway.metrics.starter.MetricPipelineConfiguration\u0026amp;rdquo; 中 @import 上述存储spring配置类； 2.查询数据适配 需要在 server/metrics 目录下，添加新 storage 扩展； 参考 “server/metrics/storage-ext-es” 模块，比如新增“storage-ext-**”\n 提供个新的存储 Storage 实现； 参考已有 “com.alipay.sofa.lookout.server.storage.ext.es.ElasticSearchStorage”，实现Storage接口。这里也需要ES实现对应的 “QueryStmt”，”LabelValuesStmt“，”LabelNamesStmt“.\n 提供个该模块的spring配置类 参考\u0026amp;rdquo;com.alipay.sofa.lookout.server.storage.ext.es.spring.bean.config.ElasticSearchServerConfig\u0026amp;rdquo;,提供 Storage的实例。 另外参考支持”@ConditionalOnProperty“的功能开关配置；\n 在 \u0026amp;ldquo;com.alipay.sofa.lookout.server.starter.ServerAutoConfiguration\u0026amp;rdquo; 中 @import 上述存储spring配置类； 3.最后贡献建议 提issue说明需求，并可以介绍下方案； 保证测试覆盖； fork 代码，编译通过后，提交 PR； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-storage-ext/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b990dad82668bc22c24d4ad0468f0535","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","summary":"如果需要扩展支持适配一个新的数据存储，可能需要下面的步骤: 1.写入适配 需要在 gateway/metrics/exporter/ 下面添加新的 exporter; 参考已有的 \u0026ldquo;gateway/metrics/exporter/elasticsearch\u0026rdquo; 模块； 提供个新存储的 MetricExporter 功能是写入数据","tags":null,"title":"服务器端 Metrics 存储扩展机制","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","wordcount":864},{"author":null,"categories":null,"content":" 1. Tag选择器的“in”筛选 =~| 将tag符合表达式的提供的值选择出来，类似于SQL中的in语义\n示例\n将app为 foo 或 foo2的应用时序数据查询出来\njvm.memory.heap.used{app=~|\u0026amp;quot;foo|foo2\u0026amp;quot;,instance_id=\u0026amp;quot;xxx\u0026amp;quot;} 2. Tag选择器的\u0026amp;rdquo;not in\u0026amp;rdquo;筛选 !~| 将tag不符合表达式提供的值选择出来,类似SQL中的not in语义\n示例\njvm.memory.heap.used{app!~|\u0026amp;quot;foo|foo2\u0026amp;quot;,instance_id=\u0026amp;quot;xxx\u0026amp;quot;} 3. Increase2函数 （类似Increase），适用于Promethues的Counter型指标 increase 会根据根据查询步长，做个时间点上的函数估值（根据既有增长斜率）。所以可能是非整型。 如果你就想返回真实时间点的整数差值，不愿估算目标时刻的近视值。那么推荐使用 Increase2。\n需要组合聚合函数时，记住“Rate then sum, never sum then rate”（这里说的rate 与 increase 函数类似）\nsum by (job)(Increase2(http_requests_total{job=\u0026amp;quot;node\u0026amp;quot;}[5m])) # This is okay 4. \u0026amp;ldquo;histogram_quantile\u0026amp;rdquo; 与(Lookout)自定义 \u0026amp;ldquo;zhistogram_quantile\u0026amp;rdquo; histogram_quantile ，是对使用prometheus client得到的 metrics buckets进行分析；\nzhistogram_quantile，是对使用 lookout sdk的得到的 metrics buckets 进行分析;\n5. Promethues 一些最佳实践总结 rate，increase 函数用于计算指标的速率，在使用时要根据指标数据的采集或上报时间间隔来进行over_time时间的控制。比如metrics数据是1分钟上报一次,如果想获取某个metric指标的1分钟的速率，应该按如下方式写promql语句\nrate(http_requestl{token=\u0026amp;quot;mobile\u0026amp;quot;}[2m] step 表示最终显示的采样（步长），如果和range （比如2m）保持一致，表示原样输出，不采样。 如果想进行采样，step \u0026amp;gt; range 就行了！ 所以总的来说，step \u0026amp;gt;= range.\nrange, 从实际使角度，推荐 range 值要尽量明显大于数据实际的上报时间间隔才有意义，比如上报单位是30秒，那range尽量\u0026amp;gt;= 1分钟。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-promql-feature-enhancement/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3bd5cd1f9d3ce3f9ba5b503ef0ba9da1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","summary":"1. Tag选择器的“in”筛选 =~| 将tag符合表达式的提供的值选择出来，类似于SQL中的in语义 示例 将app为 foo 或 foo2的应用时序数据查询出来","tags":null,"title":"服务器端 PromQL 语法特性增强","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","wordcount":691},{"author":null,"categories":null,"content":" 使用 Lookout sdk是推荐方式，当然 Lookout gateway 还支持其他协议上报。（但由于属于非标接入，细节可联系我们）\n注意如果使用 非lookout sdk ，自己一定注意控制客户端metrics数量！ [Don\u0026amp;rsquo;t over use labels(tags)]\n1.Promethues Push协议写入支持 Lookout-gateway这里扮演的是一个 prometheus-pushgateway 角色：\necho \u0026amp;quot;some_metric{k1=\u0026amp;quot;v1\u0026amp;quot;} 3.14\u0026amp;quot; | curl --data-binary \\ @- http://localhost:7200/prom/metrics/job/{job}/app/{app}/step/{step} 区别在于：\u0026amp;rdquo;http://localhost:7200/prom/\u0026amp;ldquo;，端口为7200，加了级主路径为/prom.\n 【必选】URL路径变量 {app} {job} 和{step}，必须要指定哦。step 单位秒，表示您定时上报的时间间隔（假如10s 上报一次数据，那么 step=10）\n 【可选】如果和lookout gateway间有网络代理，建议URL 里也附带上客户端真实 ip （如 \u0026amp;ldquo;/ip/{ip}\u0026amp;ldquo;）。\n 上报格式样式: 【 http_requests_total{method=\u0026amp;ldquo;post\u0026amp;rdquo;,code=\u0026amp;ldquo;200\u0026amp;rdquo;} 1027 】，多个以换行符【\u0026amp;rsquo;\\n\u0026amp;rsquo;】分割；\n 更多细节可以参考：prometheus-pushgateway ，你可以选择官方对应编程语言的SDKs\n 2. Lookout 自有协议写入支持 默认的收集服务和数据协议标准(即Lookout自有的协议支持标准)\n localhost:7200/lookout/metrics/app/{app}/step/{step}\ncurl -H \u0026amp;quot;Content-type:text/plain\u0026amp;quot; -X POST -d \u0026#39;xx\u0026#39; \\ localhost:7200/lookout/metrics/app/{app}/step/{step} 请求体是一种批量复合形式。内容是多条 metrics 数据以 \u0026amp;ldquo;\\t\u0026amp;rdquo; 进行连接；\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;count\u0026amp;quot;:0,\u0026amp;quot;rate\u0026amp;quot;:0.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;value\u0026amp;quot;:99.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;elapPerExec\u0026amp;quot;:0.0,\u0026amp;quot;totalTime\u0026amp;quot;:0.0,\u0026amp;quot;max\u0026amp;quot;:0.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;totalAmount\u0026amp;quot;:0.0,\u0026amp;quot;rate\u0026amp;quot;:0.0,\u0026amp;quot;max\u0026amp;quot;:0}} 上面内容中组成部分分别是：counter型,gauge型,Timer型\n 其中单条数据结构\n{ \u0026amp;quot;time\u0026amp;quot;: \u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;k1\u0026amp;quot;: \u0026amp;quot;v1\u0026amp;quot; }, \u0026amp;quot;m_name\u0026amp;quot;: { \u0026amp;quot;count\u0026amp;quot;: 0, \u0026amp;quot;rate\u0026amp;quot;: 0 } } tag 的 value 需要转义;\n 如果内容由进行了 snappy 压缩，需添加请求头 \u0026amp;ldquo;Content-Encoding:snappy\u0026amp;rdquo;,且\u0026amp;rdquo;Content-type: application/octet-stream\u0026amp;rdquo;;\n 3.OPEN TSDB 协议写入支持 请求demo\ncurl -X POST \\ http://localhost:7200/opentsdb/api/put \\ -H \u0026#39;Content-Type: application/json\u0026#39; \\ -H \u0026#39;step: 10000\u0026#39; \\ -H \u0026#39;app: xx\u0026#39; \\ -H \u0026#39;X-Lookout-Token: xx\u0026#39; \\ -d \u0026#39;[{ \u0026amp;quot;metric\u0026amp;quot;: \u0026amp;quot;xzc.cpu\u0026amp;quot;, \u0026amp;quot;timestamp\u0026amp;quot;: 1530624430, \u0026amp;quot;value\u0026amp;quot;: 30, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;host\u0026amp;quot;: \u0026amp;quot;web02\u0026amp;quot;, \u0026amp;quot;dc\u0026amp;quot;: \u0026amp;quot;lga\u0026amp;quot; } }]\u0026#39; 注意timestamp的单位是秒(而且尽量是当前时间附近哦，否则不太好查询)\n post的内容可以是一个json对象或json数组(批量模式)\n 更多细节可以参考 OpenTSDB的 /api/put 接口 http://opentsdb.net/docs/build/html/api_http/put.html\n 4.Metricbeat 写入协议支持 （1）.metricbeat的配置 配置文件 metricbeat.yml\noutput.elasticsearch: hosts: [\u0026#39;10.15.232.67:7200\u0026#39;] path: /beat host 是 lookout-gateway 的地址,端口是7200. 另外加了级主路径/beat;\n(2).为了符合metrics2.0标准，gateway会对数据进行转换 这块后续去时序库查询，你需要关注：\n FROM:\n{ \u0026amp;quot;@timestamp\u0026amp;quot;: \u0026amp;quot;2018-03-29T08:27:21.200Z\u0026amp;quot;, …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-other-metrics-protocol-support/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"df745d82f3f681cfd94b8187934a8477","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","summary":"使用 Lookout sdk是推荐方式，当然 Lookout gateway 还支持其他协议上报。（但由于属于非标接入，细节可联系我们） 注意如果使用 非lookout sdk ，自己一定注意控制客","tags":null,"title":"服务器端常见数据采集协议支持","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","wordcount":1013},{"author":null,"categories":null,"content":" SOFADashboard 服务治理主要是对 SOFARpc 的服务进行管理。 目前已经支持基于 ZK 和 SofaRegistry 两个注册中心。\n功能展示 1、基于服务维度 服务列表 服务提供者详情： 2、基于应用维度 应用列表 应用服务详情 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/governance/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"e547baf489fd5d125be9e67a366854b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/governance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/governance/","summary":"SOFADashboard 服务治理主要是对 SOFARpc 的服务进行管理。 目前已经支持基于 ZK 和 SofaRegistry 两个注册中心。 功能展示 1、基于服务维度 服务列表 服务提供者详情： 2、基于应用维度 应用","tags":null,"title":"服务治理","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/governance/","wordcount":78},{"author":null,"categories":null,"content":" 本地开发 在本地启动 SOFARegistry 是使用的H2 database 作为注册中心使用的配置数据库, 可以直接启动\ncom.alipay.sofa.registry.server.integration.RegistryApplication#main\n默认会使用 application-dev.properties 作为配置文件\n部署模式 SOFARegistry 部署依赖 mysql, 使用 mysql 作为注册中心自身的元数据存储。\n支持两种部署模式，分别是集成部署模式及独立部署模式，本文将介绍最简单的单节点集成部署模式，更多更详细的部署模式介绍可以查看 部署文档。\n部署步骤 1.下载源码或者安装包 下载源码方式 git clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Pserver-release -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all 下载安装包方式 您可以从 release 页面 下载最新的 registry-all.tgz 包 。\n建议下载 v6 以上版本\ntar -zxvf registry-all.tgz cd registry-all 2.启动 registry-integration 2.1 如果是本地启动开发注册中心, 可以使用 h2 作为数据库\nIDEA 源码启动: 运行 com.alipay.sofa.registry.server.integration.RegistryApplication#main\nfat jar 脚本启动命令: sh bin/integration/start_dev.sh\n2.2 正式环境建议使用 mysql\n创建 database 和 table\necho \u0026amp;quot;create database registrymetadb \u0026amp;quot; | mysql -u username -p mysql -u username -p registrymetadb \u0026amp;lt; create_table.sql 修改 conf/application.properties 中的配置，数据库密码也可以通过 JDBC_PASSWORD 环境变量传入\n启动命令: sh bin/integration/start.sh\n3.确认运行状态 可访问三个角色提供的健康监测 API，或查看日志 logs/registry-startup.log：\n# 查看meta角色的健康检测接口： $ curl http://localhost:9615/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} # 查看data角色的健康检测接口： $ curl http://localhost:9622/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... status:WORKING\u0026amp;quot;} # 查看session角色的健康检测接口： $ curl http://localhost:9603/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-registry/server-quick-start/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b620900b56ba04f4668838846a97698a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/server-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/server-quick-start/","summary":"本地开发 在本地启动 SOFARegistry 是使用的H2 database 作为注册中心使用的配置数据库, 可以直接启动 com.alipay.sofa.registry.server.integration.RegistryApplication#main 默认会使用 application-dev.properties 作为配置文件 部署模式 SOFARegistry 部署依赖 mysql, 使用 mysql 作为注册中心","tags":null,"title":"服务端部署","type":"projects","url":"/sofastack.tech/projects/sofa-registry/server-quick-start/","wordcount":460},{"author":null,"categories":null,"content":" 如图: Node Raft 分组中的一个节点，连接封装底层的所有服务，用户看到的主要服务接口，特别是 apply(task) 用于向 raft group 组成的复制状态机集群提交新任务应用到业务状态机。\n存储 Log 存储，记录 raft 配置变更和用户提交任务的日志，将从 Leader 复制到其他节点上。LogStorage 是存储实现， LogManager 负责对底层存储的调用，对调用做缓存、批量提交、必要的检查和优化。 Meta 存储，元信息存储,记录 raft 实现的内部状态，比如当前 term,、投票给哪个节点等信息。 Snapshot 存储,，用于存放用户的状态机 snapshot 及元信息，可选。 SnapshotStorage 用于 snapshot 存储实现， SnapshotExecutor 用于 snapshot 实际存储、远程安装、复制的管理。 状态机 StateMachine： 用户核心逻辑的实现,核心是 onApply(Iterator) 方法，应用通过 Node#apply(task) 提交的日志到业务状态机。 FSMCaller： 封装对业务 StateMachine 的状态转换的调用以及日志的写入等，一个有限状态机的实现，做必要的检查、请求合并提交和并发处理等。 复制 Replicator： 用于 leader 向 follower 复制日志，也就是 raft 中的 appendEntries 调用，包括心跳存活检查等。 ReplicatorGroup: 用于单个 RAFT Group 管理所有的 replicator，必要的权限检查和派发。 RPC RPC 模块用于节点之间的网络通讯: 1. RPC Server: 内置于 Node 内的 RPC 服务器，接收其他节点或者客户端发过来的请求，转交给对应服务处理。 2. RPC Client: 用于向其他节点发起请求，例如投票、复制日志、心跳等。\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/engine-architecture/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d2cc9de133aed20695229d0cde5b6ff9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/engine-architecture/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-jraft/engine-architecture/","summary":"如图: Node Raft 分组中的一个节点，连接封装底层的所有服务，用户看到的主要服务接口，特别是 apply(task) 用于向 raft group 组成的复制状态机集群提交新任务应用到业务状态机","tags":null,"title":"核心引擎设计","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/engine-architecture/","wordcount":529},{"author":null,"categories":null,"content":" MOSN 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 xDS 等云原生能力。\nxDS（UDPA）支持 MOSN 支持云原生统一数据面 API（UDPA），支持全动态配置更新。\nxDS 是 Envoy 创建的一个关键概念，它是一类发现服务的统称，其包括如下几类：\n CDS：Cluster Discovery Service EDS：Endpoint Discovery Service SDS：Secret Discovery Service RDS：Route Discovery Service LDS：Listener Discovery Service 正是通过对 xDS 的请求来动态更新 Envoy 配置，另外还有个 ADS（Aggregated Discovery Service）通过聚合的方式解决以上 xDS 的更新顺序问题。\n业务支持 MOSN 作为底层的高性能安全网络代理，支撑了 RPC、消息（Messaging）、网关（Gateway）等业务场景。\nIO 模型 MOSN 支持以下两种 IO 模型：\n Golang 经典 netpoll 模型：goroutine-per-connection，适用于在连接数不是瓶颈的情况。\n RawEpoll 模型：也就是 Reactor 模式，I/O 多路复用（I/O multiplexing）+ 非阻塞 I/O（non-blocking I/O）的模式。对于接入层和网关有大量长链接的场景，更加适合于 RawEpoll 模型。\n netpoll 模型 MOSN 的 netpoll 模型如上图所示，协程数量与链接数量成正比，大量链接场景下，协程数量过多，存在以下开销：\n Stack 内存开销 Read buffer 开销 Runtime 调度开销 RawEpoll 模型 RawEpoll 模型如上图所示，使用 epoll 感知到可读事件之后，再从协程池中为其分配协程进行处理，步骤如下：\n 链接建立后，向 Epoll 注册 oneshot 可读事件监听；并且此时不允许有协程调用 conn.read，避免与 runtime netpoll 冲突。 可读事件到达，从 goroutine pool 挑选一个协程进行读事件处理；由于使用的是 oneshot 模式，该 fd 后续可读事件不会再触发。 请求处理过程中，协程调度与经典 netpoll 模式一致。 请求处理完成，将协程归还给协程池；同时将 fd 重现添加到 RawEpoll 中。 协程模型 MOSN 的协程模型如下图所示。\n 一条 TCP 连接对应一个 Read 协程，执行收包、协议解析； 一个请求对应一个 worker 协程，执行业务处理，proxy 和 Write 逻辑； 常规模型一个 TCP 连接将有 Read/Write 两个协程，我们取消了单独的 Write 协程，让 workerpool 工作协程代替，减少了调度延迟和内存占用。\n能力扩展 协议扩展 MOSN 通过使用统一的编解码引擎以及编/解码器核心接口，提供协议的 plugin 机制，包括支持：\n SOFARPC HTTP1.x/HTTP2.0 Dubbo NetworkFilter 扩展 MOSN 通过提供 network filter 注册机制以及统一的 packet read/write filter 接口，实现了 Network filter 扩展机制，当前支持：\n TCP proxy Fault injection StreamFilter 扩展 MOSN 通过提供 stream filter 注册机制以及统一的 stream send/receive filter 接口，实现了 Stream filter 扩展机制，包括支持：\n 流量镜像 RBAC 鉴权 TLS 安全链路 通过测试，原生的 Go 的 TLS 经过了大量的汇编优化，在性能上是 Nginx（OpenSSL）的80%，Boring 版本的 Go（使用 cgo 调用 BoringSSL）因为 cgo 的性能问题， 并不占优势，所以我们最后选择使用原生 Go 的 TLS，相信 Go Runtime 团队后续会有更多的优化，我们也会有一些优化计划。\nGo vs Nginx 测试结果如下图所示：\n Go 在 RSA 上没有太多优化，go-boring（CGO）的能力是 Go 的两倍。 p256 在 Go 上有汇编优化，ECDSA 优于go-boring。 在 AES-GCM 对称加密上，Go 的能力是 go-boring 的 20 倍。 在 SHA、MD 等 HASH 算法也有对应的汇编优化。 为了满足金融场景的安全合规，我们同时也对国产密码进行了开发支持，这个是 Go Runtime 所没有的。虽然目前的性能相比国际标准 AES-GCM 还是有一些差距，大概是 50%，但是我们已经有了后续的一些优化计划，敬请期待。\n支持国密的性能测试结果如下图所示：\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/core-concept/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5fd84bf5ceb2a4ab800cd0e2db774731","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/core-concept/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/concept/core-concept/","summary":"MOSN 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 xDS 等云原生能力。 xDS（UDPA）支持 MOSN 支持云原生统一数据面 API（UDPA），","tags":null,"title":"核心概念","type":"projects","url":"/sofastack.tech/projects/mosn/concept/core-concept/","wordcount":1332},{"author":null,"categories":null,"content":" 框架准备 在阅读前，您可以参考快速开始下载并安装 ACTS IDE 和引入 ACTS 框架.\n本部分主要包含编码说明、数据源配置和一键配置说明，以帮助您使用 ACTS 框架。\n编码说明 请确保 ACTS 的编码与系统代码的编码一致，即确定以下的编码保持一致：生成脚本选择的编码、workspace 的编码应该都与应用代码编码保持一致，不一致时会出现乱码问题。\n生成脚本选择的编码，如下图设置：\nIDEA workspace 的编码：\n数据源配置 ACTS 配置数据源的目的，是为了在数据准备、数据清理、数据校验阶段，能够使用系统的数据源正确的进行 DB 增删改查。\n数据源配置 在 src/test/resource/config/acts-config.properties 中配置 dal 层的 ModuleName、数据源以及表的对应关系，以 ds_ 开头，如下：\ndatasource_bundle_name =com.alipay.testapp.common.dal ds_bean1=table1,table2 ds_bean2=table3,table4 #配置格式 #ds_数据源bean=逻辑表名1,逻辑表名2 其中数据源 bean1、数据源 bean2 是应用代码中 dal 层的数据源 bean 的名称，支持多个数据源。表名支持正则表达式，无需带分库分表后缀，若有多个数据源时请注意，某张表只能属于一个数据源，如下图：\n数据库直连 数据库直连，用于 DB 数据模型的生成。在 src/test/resource/config/dbConf/ 下的 devdb.conf 或 testdb.conf 中配置如下：\nxxx_url = jdbc:oracle:thin:@localhost:1521:cifdb xxx_username = myname xxx_password = mypswd 一键配置的说明 一键配置测试框架主要生成包含两部分，一部分是基础 Java 类，另一类是必须的配置文件，具体生成内容如下：\nJava 类 AppNameActsBaseUtils.java\n测试脚本编写过程中常用的从框架中获取各种数据的工具类，初始化搭建只提供了常用的方法，可自行添加。\n AppNameActsTestBase.java\n封装后的应用测试基类，业务系统如有特殊需求可在其上自行封装，如果没有则可以忽略此文件。\n 配置文件 ","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ready/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c3a89cbf42d55c98206a08e94d05ffde","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-ready/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-ready/","summary":"框架准备 在阅读前，您可以参考快速开始下载并安装 ACTS IDE 和引入 ACTS 框架. 本部分主要包含编码说明、数据源配置和一键配置说明，以帮助您使用 ACTS 框架。 编码说","tags":null,"title":"框架准备","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-ready/","wordcount":593},{"author":null,"categories":null,"content":" SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力。为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式：\n 基于代码组织上的模块化：这是最常见的形式，在开发期，将不同功能的代码放在不同 Java 工程下，在编译期被打进不同 jar 包，在运行期，所有 Java 类都在一个 classpath 下，没做任何隔离； 基于 Spring 上下文隔离的模块化：借用 Spring 上下文来做不同功能模块的隔离，在开发期和编译期，代码和配置也会分在不同 Java 工程中，但在运行期，不同模块间的 Spring Bean 相互不可见，DI 只在同一个上下文内部发生，但是所有的 Java 类还是在同一个 ClassLoader 下； 基于 ClassLoader 隔离的模块化：借用 ClassLoader 来做隔离，每个模块都有独立的 ClassLoader，模块与模块之间的 classpath 不同，SOFAArk 就是这种模块化的实践方式。 SOFABoot 模块化开发属于第二种模块化形式 —— 基于 Spring 上下文隔离的模块化。每个 SOFABoot 模块使用独立的 Spring 上下文，避免不同 SOFABoot 模块间的 BeanId 冲突，有效降低企业级多模块开发时团队间的沟通成本。\n关于 SOFABoot 模块化产生的背景，可参考文章《蚂蚁金服的业务系统模块化 \u0026amp;mdash;- 模块化隔离方案》\n功能简介 依赖引入 使用 SOFABoot 模块化开发方案，需要引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;isle-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFABoot 模块 SOFABoot 框架定义了 SOFABoot 模块的概念，一个 SOFABoot 模块是一个包括 Java 代码、Spring 配置文件、SOFABoot 模块标识等信息的普通 Jar 包，一个 SOFABoot 应用可以包含多个 SOFABoot 模块，每个 SOFABoot 模块都含有独立的 Spring 上下文。\n以 SOFABoot 模块为单元的模块化方式为开发者提供了以下功能：\n 运行时，每个 SOFABoot 模块的 Spring 上下文是隔离的，模块间定义的 Bean 不会相互影响； 每个 SOFABoot 模块是功能完备且自包含的，可以很容易在不同的 SOFABoot 应用中进行模块迁移和复用，只需将 SOFABoot 模块整个拷贝过去，调整 Maven 依赖，即可运行。 SOFABoot 模块的格式定义见: 模块配置。\nSOFABoot 模块间通信 上下文隔离后，模块与模块间的 Bean 无法直接注入，模块间需要通过 SOFA 服务进行通信，目前SOFABoot 提供了两种形式的服务发布和引用，用于解决不同级别的模块间调用的问题：\n JVM 服务发布和引用：解决一个 SOFABoot 应用内部各个 SOFABoot 模块之间的调用问题， JVM 服务发布与引用 RPC 服务发布和引用：解决多个 SOFABoot 应用之间的远程调用问题，RPC 服务发布与引用。 模块并行化启动 每个 SOFABoot 模块都是独立的 Spring 上下文，多个 SOFABoot 模块支持并行化启动，与 Spring Boot 的单 Spring 上下文模式相比，模块并行化启动能够加快应用的启动速度。\nRoot Application Context SOFABoot 应用运行时，本身会产生一个 Spring Context，我们把它叫做 Root Application Context，它是每个 SOFABoot 模块创建的 Spring Context 的 Parent。这样设计的目的是为了保证每个 SOFABoot 模块的 Spring Context 都能发现 Root Application Context 中创建的 Bean，这样当应用新增 Starter 时，不仅 Root Application Context 能够使用 Starter 中新增的 Bean，每个 SOFABoot 模块的 Spring Context 也能使用这些 Bean。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/modular-development/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"95bc080787c3614bfa485d2f3cd0de4c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/modular-development/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/modular-development/","summary":"SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力。为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式： 基于代码组织上的模块化","tags":null,"title":"模块化开发概述","type":"projects","url":"/sofastack.tech/projects/sofa-boot/modular-development/","wordcount":1073},{"author":null,"categories":null,"content":"SOFABoot 会根据 Require-Module 计算模块依赖树，例如以下依赖树表示模块B 和模块C 依赖模块A，模块E 依赖模块D，模块F 依赖模块E：\n该依赖树会保证模块A 必定在模块B 和模块C 之前启动，模块D 在模块E 之前启动，模块E 在模块F 之前启动，但是依赖树没有定义模块B 与模块C，模块B、C与模块D、E、F之间的启动顺序，这几个模块之间可以串行启动，也可以并行启动。\nSOFABoot 默认会并行启动模块，在使用过程中，如果希望关闭并行启动，可以在 application.properties 中增加以下参数:\ncom.alipay.sofa.boot.module-start-up-parallel=false ","date":-62135596800,"description":"","dir":"projects/sofa-boot/parallel-start/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a6ef51b78d2a4f9af0debbc25ea45e8a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/parallel-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/parallel-start/","summary":"SOFABoot 会根据 Require-Module 计算模块依赖树，例如以下依赖树表示模块B 和模块C 依赖模块A，模块E 依赖模块D，模块F 依赖模块E： 该依赖树会保证模块A 必定在模块B 和","tags":null,"title":"模块并行化启动","type":"projects","url":"/sofastack.tech/projects/sofa-boot/parallel-start/","wordcount":204},{"author":null,"categories":null,"content":" SOFABoot 模块是一个普通的 Jar 包加上一些 SOFABoot 特有的配置，这些 SOFABoot 特有的配置，让一个 Jar 包能够被 SOFABoot 识别，使之具备模块化的能力。\n一个完整的 SOFABoot 模块和一个普通的 Jar 包有两点区别:\n SOFABoot 模块包含一份 sofa-module.properties 文件，这份文件里面定义了 SOFABoot 模块的名称以及模块之间的依赖关系。 SOFABoot 模块的 META-INF/spring 目录下，可以放置任意多的 Spring 配置文件，SOFABoot 会自动把它们作为本模块的 Spring 配置加载起来。 sofa-module.properties 文件详解 先来看一份完整的 sofa-module.properties 文件（src/main/resources 目录下）：\nModule-Name=com.alipay.test.biz.service.impl Spring-Parent=com.alipay.test.common.dal Require-Module=com.alipay.test.biz.shared Module-Profile=dev Module-Name Module-Name 是 SOFABoot 模块的名称，也是 SOFABoot 模块的唯一标示符。在一个 SOFABoot 应用中，一个 SOFABoot 模块的 Module-Name 必须和其他的 SOFABoot 模块的 Module-Name 不一样。需要注意的一点是，一个 SOFABoot 应用运行时的 SOFABoot 模块，不仅仅只包含本应用的模块，还包括依赖了其他应用的 SOFABoot 模块，确定是否唯一的时候需要把这些 SOFABoot 模块也考虑进去。\nRequire-Module Require-Module 用于定义模块之间的依赖顺序，值是以逗号分隔的 SOFABoot 模块名列表，比如上面的配置中，就表示本模块依赖于 com.alipay.test.biz.shared 模块。对于这种依赖关系的处理，SOFABoot 会将 com.alipay.test.biz.shared 模块在本模块之前启动，即com.alipay.test.biz.shared 模块将先启动 Spring 上下文。\n一般情况下，是不需要为模块定义 Require-Module 的，只有当模块的 Spring 上下文的启动依赖于另一个模块的 Spring 上下文的启动时，才需要定义 Require-Module。举一个例子，如果你在 A 模块中发布了一个 SOFA JVM Service。在 B 模块的某一个 Bean 的 init 方法里面，需要使用 SOFA Reference 调用这个 JVM Service。假设 B 模块在 A 模块之前启动了，那么 B 模块的 Bean 就会因为 A 模块的 JVM Service 没有发布而 init 失败，导致 Spring 上下文启动失败。这个时候，我们就可以使用 Require-Module 来强制 A 模块在 B 模块之前启动。\nSpring-Parent 在 SOFABoot 应用中，每一个 SOFABoot 模块都是一个独立的 Spring 上下文，并且这些 Spring 上下文之间是相互隔离的。虽然这样的模块化方式可以带来诸多好处，但是，在某些场景下还是会有一些不便，这个时候，你可以通过 Spring-Parent 来打通两个 SOFABoot 模块的 Spring 上下文。Spring-Parent 属性可以配置一个模块的名称，比如上面的配置中，就将 com.alipay.test.common.dal 的 Spring 上下文设置为当前模块的 Spring 上下文的父 Spring 上下文。\n由于 Spring 的限制，一个模块的 Spring-Parent 只能有一个模块\n关于 Spring 的父上下文的作用可以看 Spring 的 BeanFactory 的说明：http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/beans/factory/BeanFactory.html\nModule-Profile 支持 SOFABoot Profile 能力： SOFABoot Profile\nSpring 配置文件 SOFABoot 模块可以包含 Spring 配置文件，配置文件需要放置在 META-INF/spring 目录下，SOFABoot 启动时会自动扫描该目录，并把目录下所有 XML 文件作为本模块的 Spring 配置加载起来。在 Spring 配置文件中，我们可以定义 Bean、发布服务等等。\nSOFABoot 模块一般用于封装对外发布服务接口的具体实现，属于业务层，Controller 属于展现层内容，我们不建议也不支持在 SOFABoot 模块中定义 Controller 组件，Controller 组件相关定义请直接放在 Root Application Context。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-module/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2dbb8a536237f21afbee1e3f320b8193","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-module/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-module/","summary":"SOFABoot 模块是一个普通的 Jar 包加上一些 SOFABoot 特有的配置，这些 SOFABoot 特有的配置，让一个 Jar 包能够被 SOFABoot 识别，使之具备模块化的能力。 一个完整的 SOFABoot 模块和一个普通的 Jar 包","tags":null,"title":"模块配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-module/","wordcount":1194},{"author":null,"categories":null,"content":"如果你要扩展一个注册中心，我们先看下注册中心的抽象类。\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026amp;lt;ProviderConfig\u0026amp;gt; configs); public abstract List\u0026amp;lt;ProviderGroup\u0026amp;gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026amp;lt;ConsumerConfig\u0026amp;gt; configs); } 可以看到我们需要的主要接口。\n 启动注册中心客户端、维持连接 销毁注册中心客户端、释放资源 发布服务、缓存发布信息 取消发布服务、删除缓存 订阅服务列表、同步或者异步返回数据，有变化接收通知 取消订阅服务列表、删除缓存 其它\n 注册中心节点断连后，不影响本地调用 和一个注册中心节点断连后，可自己切换到其它注册中心节点 注册中心节点切换后，自动恢复注册和订阅信息 注册中心数据缓存到本地文件，就算连不上任何注册中心，服务提供者和服务调用者也能重启并正常调用 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-extension-guide/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c952ecbea16f7ae68ad095ab8baf0583","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","summary":"如果你要扩展一个注册中心，我们先看下注册中心的抽象类。 package com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026lt;ProviderConfig\u0026gt; configs); public abstract List\u0026lt;ProviderGroup\u0026gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public","tags":null,"title":"注册中心扩展指南","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","wordcount":290},{"author":null,"categories":null,"content":"SOFABoot RPC Starter 为用户提供多种注册中心选择和方便的配置。 目前 bolt ， rest ， dubbo 都支持 Zookeeper 作为注册中心。另外 bolt ， rest 支持本地文件系统作为注册中心，该种模式一般用于测试。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-usage/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5a1a4619c8ac4a9fc27b8576472aed9f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-usage/","summary":"SOFABoot RPC Starter 为用户提供多种注册中心选择和方便的配置。 目前 bolt ， rest ， dubbo 都支持 Zookeeper 作为注册中心。另外 bolt ， rest 支持本地文件系统作为注册中心，该种模式一般用于测","tags":null,"title":"注册中心选择","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-usage/","wordcount":72},{"author":null,"categories":null,"content":" 本文描述的是 MOSN 作为 Sidecar 使用时的流量劫持方案。\nMOSN 作为 Sidecar 和业务容器部署在同一个 Pod 中时，需要使得业务应用的 Inbound 和 Outbound 服务请求都能够经过 Sidecar 处理。区别于 Istio 社区使用 iptables 做流量透明劫持，MOSN 目前使用的是流量接管方案，并在积极探索适用于大规模流量下的透明劫持方案。\n流量接管 区别于 Istio 社区的 iptables 流量劫持方案，MOSN 使用的流量接管的方案如下：\n 假设服务端运行在 1.2.3.4 这台机器上，监听 20880 端口，首先服务端会向自己的 Sidecar 发起服务注册请求，告知 Sidecar 需要注册的服务以及 IP + 端口（1.2.3.4:20880） 服务端的 Sidecar 会向服务注册中心（如 SOFA Registry）发起服务注册请求，告知需要注册的服务以及 IP + 端口，不过这里需要注意的是注册上去的并不是业务应用的端口（20880），而是 Sidecar 自己监听的一个端口（例如：20881） 调用端向自己的 Sidecar 发起服务订阅请求，告知需要订阅的服务信息 调用端的 Sidecar 向调用端推送服务地址，这里需要注意的是推送的 IP 是本机，端口是调用端的 Sidecar 监听的端口（例如 20882） 调用端的 Sidecar 会向服务注册中心（如 SOFA Registry）发起服务订阅请求，告知需要订阅的服务信息； 服务注册中心（如 SOFA Registry）向调用端的 Sidecar 推送服务地址（1.2.3.4:20881） 服务调用过程 经过上述的服务发现过程，流量转发过程就显得非常自然了：\n 调用端拿到的服务端地址是 127.0.0.1:20882，所以就会向这个地址发起服务调用 调用端的 Sidecar 接收到请求后，通过解析请求头，可以得知具体要调用的服务信息，然后获取之前从服务注册中心返回的地址后就可以发起真实的调用（1.2.3.4:20881） 服务端的 Sidecar 接收到请求后，经过一系列处理，最终会把请求发送给服务端（127.0.0.1:20880） 透明劫持 上文通过在服务注册过程中把服务端地址替换成本机监听端口实现了轻量级的“流量劫持”，在存在注册中心，且调用端和服务端同时使用特定SDK的场景中可以很好的工作，如果不满足这两个条件，则无法流量劫持。为了降低对于应用程序的要求，需要引入透明劫持。\n使用 iptables 做流量劫持 iptables 通过 NAT 表的 redirect 动作执行流量重定向，通过 syn 包触发新建 nefilter 层的连接，后续报文到来时查找连接转换目的地址与端口。新建连接时同时会记录下原始目的地址，应用程序可以通过(SOL_IP、SO_ORIGINAL_DST)获取到真实的目的地址。\niptables 劫持原理如下图所示：\n使用 iptables 做流量劫持时存在的问题 目前 Istio 使用 iptables 实现透明劫持，主要存在以下三个问题： 1. 需要借助于 conntrack 模块实现连接跟踪，在连接数较多的情况下，会造成较大的消耗，同时可能会造成 track 表满的情况，为了避免这个问题，业内有关闭 conntrack 的做法，比如阿里巴巴就关闭了这个模块。 1. iptables 属于常用模块，全局生效，不能显式的禁止相关联的修改，可管控性比较差。 1. iptables 重定向流量本质上是通过 loopback 交换数据，outbond 流量将两次穿越协议栈，在大并发场景下会损失转发性能。\n上述几个问题并非在所有场景中都存在，比方说某些场景下，连接数并不多，且 NAT 表未被使用到的情况下，iptables 是一个满足要求的简单方案。为了适配更加广泛的场景，透明劫持需要解决上述三个问题。\n透明劫持方案优化 使用 tproxy 处理 inbound 流量\ntproxy 可以用于 inbound 流量的重定向，且无需改变报文中的目的 IP/端口，不需要执行连接跟踪，不会出现 conntrack 模块创建大量连接的问题。受限于内核版本，tproxy 应用于 outbound 存在一定缺陷。目前 Istio 支持通过 tproxy 处理 inbound 流量。\n使用 hook connect 处理 outbound 流量\n为了适配更多应用场景，outbound 方向通过 hook connect 来实现，实现原理如下：\n无论采用哪种透明劫持方案，均需要解决获取真实目的 IP/端口的问题，使用 iptables 方案通过 getsockopt 方式获取，tproxy 可以直接读取目的地址，通过修改调用接口，hook connect 方案读取方式类似于tproxy。\n实现透明劫持后，在内核版本满足要求（4.16以上）的前提下，通过 sockmap 可以缩短报文穿越路径，进而改善 outbound 方向的转发性能。\n总结 总结来看，如果应用程序通过注册中心发布/订阅服务时，可以结合注册中心劫持流量；在需要用到透明劫持的场景，如果性能压力不大，使用 iptables redirect 即可，大并发压力下使用 tproxy 与hook connect 结合的方案。\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/traffic-hijack/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5845d8478a48fcddc74f0b9d28ede2c2","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/traffic-hijack/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/concept/traffic-hijack/","summary":"本文描述的是 MOSN 作为 Sidecar 使用时的流量劫持方案。 MOSN 作为 Sidecar 和业务容器部署在同一个 Pod 中时，需要使得业务应用的 Inbound 和 Outbound 服务请求都能够经过 Sidecar 处理。区别于 Istio 社","tags":null,"title":"流量劫持","type":"projects","url":"/sofastack.tech/projects/mosn/concept/traffic-hijack/","wordcount":1671},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.1.2。\n参见: http://semver.org/lang/zh-CN/。\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 5.3.0，那么将会维护 5.2.x 的 bugfix 分支，而 5.1.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 5.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 5.3.0。 发布后拉起下一个版本，例如 5.3.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/version-release/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"604f113607e6815757f4d1907190c13c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/version-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/version-release/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.1.2。 参见: http://semver.org/lang/zh-CN/","tags":null,"title":"版本发布","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/version-release/","wordcount":315},{"author":null,"categories":null,"content":" 1.3.2 2020-06-19\n Bug Fixes 移除对 bolt address parser 的扩展，避免 check connection 返回结果不符合预期 SPI 组件 JRaftServiceLoader 改为延迟加载策略规避多余对象的创建 几个 corner case 修复，比如 replicate logs 如果比 appliedIndex（follower）更小，那么可以认为是成功的 关闭 Recyclers 时的 IndexOutOfBoundsException 问题修复 Features 抽象出网络通信层，增加 GRPC 实现并支持 Replication Pipeline，用户亦可自行对通信层进行其他实现的扩展 RheaKV 增加 reverseScan API 提供 Replicator 与 RPC 的线程池隔离，避免相互影响 read-index 线性一致读请求提供请求超时（timeout）配置 Breaking Changes 无 致谢（排名不分先后） @shibd @SteNicholas @killme2008 @zongtanghu 1.3.1 2020-04-17\n Bug Fixes 修复 bolt rpc callback 默认的任务饱和丢弃策略，改为抛出异常 修复 learner 启动晚于 leader 选举成功时无法复制日志的 bug Features multi raft group 之间共享 timer 和 scheduler 等较重的线程资源，优化 multi group 场景中的多余资源占用 提供 RPC adapter，用户可基于 SPI 扩展不同的 RPC 实现 正式提供稳定的 RocksDBSegmentLogStorage，适合 value 较大的数据存储 sofa-bolt 升级到 1.6.1，支持 SSL 以及具有更好的小数据包传输能力 引入一个新的数据结构 segment list 来解决 LogManager 中过多的 log memory copy 采纳 nacos 的建议，对 raft Task 增加 join API Breaking Changes 无 致谢（排名不分先后） @jovany-wang @SteNicholas @zongtanghu @OpenOpened 1.3.0 2019-11-29\n Bug Fixes 删除数据并重启且期间没有新的 task 提交的情况下 prev log index 紊乱的修复 修复一些选举和线性一致读相关的 corner case Recyclers 多个线程 recycle 资源时的 NPE 修复 Features 新增 Read-only member(learner) 角色，支持 learner 节点上的线性一致读 实现优先级选举 在 multi raft group 的场景中，随机打散每个 group 的第一次 snapshot timeout 时间，避免一个进程内多个 group 同时 snapshot RheaKV 新增 containsKey API RheaKV 实现 snapshot checksum 以及异步 snapshot 新增 replicator 的 state 监听器： ReplicatorStateListener RepeatedTimer 的默认实现替换为 HashedWheelTimer 修复 windows 上定时器 CPU 消耗偏高的问题 kill -s SIGUSR2 pid 中增加打印 rocksdb stats 和所有 ThreadPool 指标统计信息 升级 rocksdb 版本到 5.18.3 新增实验性质的 RocksDBSegmentLogStorage，适合 value 较大的数据存储 Counter 例子改进，演示 ReadIndex 线性一致读 当优化 checksum 中多余的 mem copy Breaking Changes 无 致谢（排名不分先后） @zongtanghu @devYun @masaimu @SteNicholas @yetingsky 1.2.6 2019-08-15\n Bug Fixes 修复 ReadIndex 并发情况下可能出现的读超时 保存 raft meta 失败后终止状态机 修复 windows 环境中无法原子 move 文件的问题 当 RheaKV apply 失败时终止状态机避免出现数据不一致情况 Features 增加 LogEntry checksum validation 优化 log replication 线程模型减少锁竞争 优化 RheaKV multi group snapshot 对于 multi-raft-group 场景，提供 manual rebalance API 在无 PD 模式手动平衡各节点 leader 数量 CliService 提供获取存活 follower 节点的 API 引入 SPI 扩展机制，LogStorage、SnapshotStorage、RaftMetaStorage、LogEntryCodec 均可基于 SPI 扩展 Linux 平台 SIGUSR2 信号输出节点状态以及 metric 信息 RheaKV 增加 CompareAndPut 原子更新 API 新增 pooled buf allocator 解决 log replication 时大量分配 byte[] 频繁触发 fullgc 默认关闭 RheaKV rocksdb 的 fsync 和 WAL，依靠 raft log 和 snapshot 确保数据一致性 当 raft node 过载时拒绝新的请求 Breaking Changes 无 致谢（排名不分先后） @SteNicholas @zongtanghu 1.2.5 2019-04-01\n Bug Fixes 修复 jmh 与 unit test 代码冲突问题 修复 snapshot 过大引起的安装失败 bug，会影响新增节点的加入 Features LogManagerImpl 中耗费 cpu 部分的代码优化 修正一些单词拼写错误 Breaking Changes 无 此版本强烈推荐升级\n1.2.4 2019-03-20\n Bug Fixes 修复一种情况下 lease read 的 stale read 部分 timestamp 修改为 monotonic time 修复一种情况下 replicator 被 block 住的问题 解决 windows 平台下某些单测无法创建目录 解决 windows 平台下某些 rocksdb options 设置不当导致进程 crash Features 开放 RocksDB options 的设置给用户层 Pre-vote 优化，启用 lease 机制来规避网络分区+集群长时间无写入的情况下，游离节点回归后打断当前 term，提升系统可用性 升级 bolt …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/release-log/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9e24fb74a3cda6a600252b01f8a85db9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/release-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-jraft/release-log/","summary":"1.3.2 2020-06-19 Bug Fixes 移除对 bolt address parser 的扩展，避免 check connection 返回结果不符合预期 SPI 组件 JRaftServiceLoader 改为延迟加载策略规避多余对象的创建 几个 corner case 修复，比如 replicate logs 如果比 appliedI","tags":null,"title":"版本发行日志","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/release-log/","wordcount":2298},{"author":null,"categories":null,"content":" 通过 SOFABoot，我们可以直接在浏览器中就可以查看 SOFA 中间件的版本等详细信息。\n引入 SOFABoot Infra 依赖 要在 SOFABoot 中直接通过浏览器查看 SOFA 中间件的版本信息，只需要在 Maven 依赖中增加如下的内容即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;infra-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 版本信息查看 在应用启动成功后，可以在浏览器中输入 http://localhost:8080/sofaboot/versions 查看 SOFA 中间件的版本信息，如：\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Built-Time: \u0026amp;quot;2018-04-05T20:55:22+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.0\u0026amp;quot; } ] 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，sofaboot/versions 更改为 actuator/versions\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/view-versions/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c6b6d22e9038aa1f5e4ce74449ba1cda","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/view-versions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/view-versions/","summary":"通过 SOFABoot，我们可以直接在浏览器中就可以查看 SOFA 中间件的版本等详细信息。 引入 SOFABoot Infra 依赖 要在 SOFABoot 中直接通过浏览器查看 SOFA 中间件的版本信息，只","tags":null,"title":"版本查看","type":"projects","url":"/sofastack.tech/projects/sofa-boot/view-versions/","wordcount":182},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 1.0.0。\n参见: http://semver.org/lang/zh-CN/\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 1.2.0，那么将会维护 1.1.x 的 bugfix 分支，而 1.0.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 1.0.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 1.0.0。 发布后拉起下一个版本，例如 1.0.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/version-rule/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a2093bdf478bdff0e15a2de70e522d03","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/version-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/version-rule/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 1.0.0。 参见: http://semver.org/lang/zh-CN/ 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本","tags":null,"title":"版本规范","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/version-rule/","wordcount":286},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.2.0。\n参见: http://semver.org/lang/zh-CN/\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 5.4.0，那么将会维护 5.3.x 的 bugfix 分支，而 5.2.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 5.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 5.3.0。 发布后拉起下一个版本，例如 5.3.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-standard/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"71aad9cbc42aba3d9f875ae9169cf005","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/release-standard/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/release-standard/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.2.0。 参见: http://semver.org/lang/zh-CN/ 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本","tags":null,"title":"版本规范","type":"projects","url":"/sofastack.tech/projects/sofa-registry/release-standard/","wordcount":286},{"author":null,"categories":null,"content":"SOFABoot 使用了一些三方开源组件，他们分别是：\n一些主要依赖：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License sofa-common-tools under Apache 2.0 license 一些扩展依赖：\n nuxeo under Apache License, Version 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"11f073a7a9965ab5690ed166fe319bbd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/notice/","summary":"SOFABoot 使用了一些三方开源组件，他们分别是： 一些主要依赖： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License sofa-common-tools under Apache 2.0 license 一些扩展依赖： nuxeo under Apache License, Version 2.0 \u0026hellip; 其它整理中。","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-boot/notice/","wordcount":67},{"author":null,"categories":null,"content":" 依赖组件版权说明 SOFADashboard 使用了一些三方开源组件，他们分别是：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFA Bolt under Apache License 2.0 SOFA Bolt under Apache License 2.0 Curator under Apache License 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a9ebe38d245302f94ab7bfa793329926","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/notice/","summary":"依赖组件版权说明 SOFADashboard 使用了一些三方开源组件，他们分别是： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFA Bolt under Apache License 2.0 SOFA Bolt under Apache License 2.0 Curator under Apache License 2.0 \u0026hellip; 其它整理中。","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/notice/","wordcount":67},{"author":null,"categories":null,"content":" 依赖组件版权说明 SOFARegistry 使用了一些三方开源组件，他们分别是：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1  SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 \u0026amp;hellip; 其它整理中，如若发现遗漏，还请主动告知。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"c40263ffd56a2f1292756c9fafea55e2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/notice/","summary":"依赖组件版权说明 SOFARegistry 使用了一些三方开源组件，他们分别是： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1 SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 \u0026hellip; 其","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-registry/notice/","wordcount":89},{"author":null,"categories":null,"content":" RheaKV：基于 JRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库。 AntQ Streams QCoordinator： 使用 JRaft 在 coordinator 集群内做选举、元信息存储等功能。 SOFA 服务注册中心元信息管理模块：IP 数据信息注册，要求写数据达到各个节点一致，并且在不小于一半节点挂掉，保证不影响数据正常存储。 AntQ NameServer 选主 ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/user-stories/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b233be7d9eed33645945293e637e28ea","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/user-stories/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/user-stories/","summary":"RheaKV：基于 JRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库。 AntQ Streams QCoordinator： 使用 JRaft 在 coordinator 集群内做选举、元信息存储等","tags":null,"title":"用户案例","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/user-stories/","wordcount":140},{"author":null,"categories":null,"content":"SOFARPC 支持指定地址进行调用的场景。用 Java API 的使用方式如下，设置直连地址即可：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); 用 XML 的使用方式如下：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sample.HelloService\u0026amp;quot; id=\u0026amp;quot;helloService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 用 Annotation 的使用方式如下：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, directUrl = \u0026amp;quot;127.0.0.1:12220\u0026amp;quot;)) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/peer-to-peer/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b1815c322f5dc9528f6429d1d5e38369","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/peer-to-peer/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/peer-to-peer/","summary":"SOFARPC 支持指定地址进行调用的场景。用 Java API 的使用方式如下，设置直连地址即可： ConsumerConfig\u0026lt;HelloService\u0026gt; consumer = new ConsumerConfig\u0026lt;HelloService\u0026gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026quot;bolt://127.0.0.1:12201\u0026quot;); 用 XML 的使用方式如下： \u0026lt;sofa:reference interface=\u0026quot;com.alipay.sample.HelloService\u0026quot; id=\u0026quot;helloService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:route target-url=\u0026quot;127.0.0.1:12200\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:reference\u0026gt; 用 Annotation 的使用方式如下","tags":null,"title":"直连调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/peer-to-peer/","wordcount":82},{"author":null,"categories":null,"content":" 类委托加载 注：这里委托加载不止包含类委托，还包含资源委托加载。\nSOFAArk 通过多 ClassLoader 的方式提供类隔离的能力，并在此基础上具备多版本隔离和热部署的能力。当然类如果纯粹隔离还不够，还需要考虑ClassLoader之间的类共享。SOFAArk 通过类委托机制，提供了一套丰富的委托加载能力。定义了PluginClassLoader 和 BizClassLoader，不同类型具备不同的类查找逻辑，同时提供ClassLoaderHook能力，允许自定义模块间的类委托加载。SOFAArk 框架本身的类委托加载是非常灵活的，但是在实际落地时，需要有一套类委托加载的最佳实践。\nSOFAArk 支持的场景主要分为两类： 1. 多Plugin的类隔离：考虑如何相同类不同版本不会相互冲突 2. 合并部署/热部署：原应用如何拆分，或多个应用如何合并\n这里我们主要考虑第2种，多 ClassLoader 如何布局，在内部探索出的最佳实践多 ClassLoader 布局为 模块里的类和资源查找优先从模块里查找列，查找不到从再基座里查找。\n最佳实践 类委托加载的准则是中间件相关的依赖需要放在同一个的 ClassLoader 里进行加载执行，达到这种方式的最佳实践有两种：\n强制委托加载 由于中间件相关的依赖一般需要在同一个ClassLoader里加载运行，所以可以制定一个中间件依赖的白名单，强制这些依赖委托给基座加载。SOFAArk 已经提供白名单能力，详细查看与 sofa.ark.plugin.export.class.enable 有关源码。\n强制加载优缺点 优点 模块开发者不需要感知哪些依赖属于需要强制加载由同一个 ClassLoader 加载的依赖\n 缺点 白名单里要强制加载的依赖列表需要维护，列表的缺失需要更新基座，较为重要的升级需要推所有的基座升级。\n自定义委托加载 模块里pom通过设置依赖的 scope 为 provided主动指定哪些要委托给基座加载。通过模块瘦身工具自动把与基座重复的依赖委托给基座加载，基座通过预置中间件的依赖（可选，虽然模块暂时不会用到，但可以提前引入，以备后续模块需要引入的时候不需再发布基座即可引入）\n1. 基座预置依赖 基座可以提前预置一些依赖\n2. 通过两种方式委托给基座加载 模块pom里依赖 scope 设置为 provided biz 打包插件sofa-ark-maven-plugin里设置 excludeGroupIds 或 excludeArtifactIds 3. 只有模块声明过的依赖才可以委托给基座加载 模块启动的时候，框架会有一些扫描逻辑，这些扫描如果不做限制会查找到模块和基座的所有类、资源，导致一些模块明明不需要的功能尝试去初始化，从而报错。SOFAArk 2.0.3之后新增了模块的 declaredMode, 来限制只有模块里声明过的依赖才可以委托给基座加载。只需在模块的 sofa-ark-maven-plugin 打包插件的 Configurations 里增加 true即可。\n自定义委托加载优缺点 优点 不需要维护强制加载列表，当部分需要由同一 ClassLoader 加载的依赖没有设置为统一加载时，可以修改模块就可以修复，不需要发布基座（除非基座确实依赖）。\n 缺点 对模块自动瘦身的依赖较强\n对比与总结 ||依赖缺失排查成本|修复成本|模块改造成本|维护成本| |-|-|-|-|-| |强制加载|类转换失败或类查找失败，成本中|更新 plugin，发布基座，高|低|高| |自定义委托加载 |类转换失败或类查找失败，成本中|更新模块依赖，如果基座依赖不足，需要更新基座并发布，中|高|低| |自定义委托加载 + 基座预置依赖 + 模块自动瘦身|类转换失败或类查找失败，成本中|更新模块依赖，设置为provided，低|低|低|\n推荐自定义委托加载方式 模块自定义委托加载 + 模块自动瘦身 模块开启 declaredMode 基座预置依赖 开启后的副作用 由于基座提前启动，模块再次启动的时候，如果依赖了基座的依赖里有发布服务，那么模块在启动的时候还会再次发布，如果该问题有一定影响可以模块pom里exclude掉对应的依赖。 ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-class-loader-delegation/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d3ea2dc9104433356ad82b6a772a971a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","summary":"类委托加载 注：这里委托加载不止包含类委托，还包含资源委托加载。 SOFAArk 通过多 ClassLoader 的方式提供类隔离的能力，并在此基础上具备多版本隔离和热部署的能力。当","tags":null,"title":"类委托加载","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","wordcount":1447},{"author":null,"categories":null,"content":"介绍几种 SOFARPC 在不同环境下的使用方式 * 非 Spring 环境 API 使用 * SOFABoot 环境 XML 配置使用 * SOFABoot 环境注解使用 * SOFABoot 环境动态 API 使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programming/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"9a947dae761c84aa4d95121c076ac552","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programming/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programming/","summary":"介绍几种 SOFARPC 在不同环境下的使用方式 * 非 Spring 环境 API 使用 * SOFABoot 环境 XML 配置使用 * SOFABoot 环境注解使用 * SOFABoot 环境动态 API 使用","tags":null,"title":"编程界面","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programming/","wordcount":50},{"author":null,"categories":null,"content":"自动故障剔除会自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复。目前支持 bolt 协议。\n在 SOFABoot 中，只需要配置自动故障剔除的参数到 application.properties 即可。可以不完全配置，只配置自己关心的参数，其余参数会取默认值。需要注意的是 com.alipay.sofa.rpc.aft.regulation.effective 是该功能的全局开关，如果关闭则该功能不会运行，其他参数也都不生效。\n 属性 描述 默认值 timeWindow 时间窗口大小：对统计信息计算的周期。 10s leastWindowCount 时间窗口内最少调用数：只有在时间窗口内达到了该最低值的数据才会被加入到计算和调控中。 10次 leastWindowExceptionRateMultiple 时间窗口内异常率与服务平均异常率的降级比值：在对统计信息进行计算的时候，会计算出该服务所有有效调用ip的平均异常率，如果某个ip的异常率大于等于了这个最低比值，则会被降级。 6倍 weightDegradeRate 降级比率：地址在进行权重降级时的降级比率。 1\u0026amp;frasl;20 weightRecoverRate 恢复比率：地址在进行权重恢复时的恢复比率。 2倍 degradeEffective 降级开关：如果应用打开了这个开关，则会对符合降级的地址进行降级，否则只会进行日志打印。 false(关闭) degradeLeastWeight 降级最小权重：地址权重被降级后的值如果小于这个最小权重，则会以该最小权重作为降级后的值。 1 degradeMaxIpCount 降级的最大ip数：同一个服务被降级的ip数不能超过该值。 2 regulationEffective 全局开关：如果应用打开了这个开关，则会开启整个单点故障自动剔除摘除功能，否则完全不进入该功能的逻辑。 false(关闭) 示例\ncom.alipay.sofa.rpc.aft.time.window=20 com.alipay.sofa.rpc.aft.least.window.count=30 com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple=1.4 com.alipay.sofa.rpc.aft.weight.degrade.rate=0.5 com.alipay.sofa.rpc.aft.weight.recover.rate=1.2 com.alipay.sofa.rpc.aft.degrade.effective=true com.alipay.sofa.rpc.aft.degrade.least.weight=1 com.alipay.sofa.rpc.aft.degrade.max.ip.count=2 com.alipay.sofa.rpc.aft.regulation.effective=true 如上配置，打开了自动故障剔除功能和降级开关，当节点出现故障时会被进行权重降级，在恢复时会被进行权重恢复。每隔 20s 进行一次节点健康状态的度量，20s 内调用次数超过 30 次的节点才被作为计算数据，如果单个节点的异常率超过了所有节点的平均异常率的 1.4 倍则对该节点进行权重降级，降级的比率为 0.5 。权重最小降级到 1 。如果单个节点的异常率低于了平均异常率的 1.4 倍则对该节点进行权重恢复，恢复的比率为1.2 。单个服务最多降级 2 个ip。\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-fault-tolerance/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a132b54b2398534d1773489e2b0db166","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","summary":"自动故障剔除会自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复。目前支持 bolt 协议。 在 SOFABoot 中，只需要配置自动故障剔除的","tags":null,"title":"自动故障剔除","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","wordcount":759},{"author":null,"categories":null,"content":"集群中通常一个服务有多个服务提供者。其中部分服务提供者可能由于网络，配置，长时间 fullgc ，线程池满，硬件故障等导致长连接还存活但是程序已经无法正常响应。单机故障剔除功能会将这部分异常的服务提供者进行降级，使得客户端的请求更多地指向健康节点。当异常节点的表现正常后，单机故障剔除功能会对该节点进行恢复，使得客户端请求逐渐将流量分发到该节点。单机故障剔除功能解决了服务故障持续影响业务的问题，避免了雪崩效应。可以减少人工干预需要的较长的响应时间，提高系统可用率。\n运行机制：\n 单机故障剔除会统计一个时间窗口内的调用次数和异常次数，并计算每个服务对应ip的异常率和该服务的平均异常率。 当达到ip异常率大于服务平均异常率到一定比例时，会对该服务+ip的维度进行权重降级。 如果该服务+ip维度的权重并没有降为0，那么当该服务+ip维度的调用情况正常时，则会对其进行权重恢复。 整个计算和调控过程异步进行，不会阻塞调用。 单机故障剔除的使用方式如下：\nFaultToleranceConfig faultToleranceConfig = new FaultToleranceConfig(); faultToleranceConfig.setRegulationEffective(true); faultToleranceConfig.setDegradeEffective(true); faultToleranceConfig.setTimeWindow(20); faultToleranceConfig.setWeightDegradeRate(0.5); FaultToleranceConfigManager.putAppConfig(\u0026amp;quot;appName\u0026amp;quot;, faultToleranceConfig); 如上，该应用会在打开了单机故障剔除开关，每20s的时间窗口进行一次异常情况的计算，如果某个服务+ip的调用维度被判定为故障节点，则会进行将该服务+ip的权重降级为0.5倍。\n更加详细的参数请参考单机故障剔除参数。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-tolerance/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7501b0fac1d1d89c61de0d591e29e1d0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault-tolerance/","summary":"集群中通常一个服务有多个服务提供者。其中部分服务提供者可能由于网络，配置，长时间 fullgc ，线程池满，硬件故障等导致长连接还存活但是程序已经无法正常","tags":null,"title":"自动故障剔除","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault-tolerance/","wordcount":528},{"author":null,"categories":null,"content":" 在使用自定义埋点组件的情况下，用户可以选择自定义 Reporter。\n自定义 Reporter 实现 public class MyReporter implements Reporter { @Override public String getReporterType() { return \u0026amp;quot;myReporter\u0026amp;quot;; } @Override public void report(SofaTracerSpan sofaTracerSpan) { // System.out 输出 System.out.println(\u0026amp;quot;this is my custom reporter\u0026amp;quot;); } @Override public void close() { // ignore } } 配置 com.alipay.sofa.tracer.reporter-name=com.glmapper.bridge.boot.flexible.MyReporter 自定义实现 Reporter 可以将业务埋点的日志输出到任何期望的地方。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/reporter-custom/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"521206c7f4051c1cc8ec8232c20bab6d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/reporter-custom/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/reporter-custom/","summary":"在使用自定义埋点组件的情况下，用户可以选择自定义 Reporter。 自定义 Reporter 实现 public class MyReporter implements Reporter { @Override public String getReporterType() { return \u0026quot;myReporter\u0026quot;; } @Override public void report(SofaTracerSpan sofaTracerSpan) { // System.out 输出 System.out.println(\u0026quot;this is my custom reporter\u0026quot;); } @Override","tags":null,"title":"自定义 Reporter","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/reporter-custom/","wordcount":108},{"author":null,"categories":null,"content":" SOFARPC 支持自定义业务线程池。可以为指定服务设置一个独立的业务线程池，和 SOFARPC 自身的业务线程池是隔离的。多个服务可以共用一个独立的线程池。\nSOFARPC 要求自定义线程池的类型必须是 com.alipay.sofa.rpc.server.UserThreadPool。\nXML 方式 如果采用 XML 的方式发布服务，可以先设定一个 class 为 com.alipay.sofa.rpc.server.UserThreadPool 的线程池的 Bean，然后设置到 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 thread-pool-ref 属性中：\n\u0026amp;lt;bean id=\u0026amp;quot;helloService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- 自定义一个线程池 --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;customExecutor\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.server.UserThreadPool\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;corePoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;maximumPoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;queueSize\u0026amp;quot; value=\u0026amp;quot;0\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloService\u0026amp;quot; interface=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;!-- 将线程池设置给一个 Service --\u0026amp;gt; \u0026amp;lt;sofa:global-attrs thread-pool-ref=\u0026amp;quot;customExecutor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation 方式 如果是采用 Annotation 的方式发布服务，可以通过设置 @SofaServiceBinding 的 userThreadPool 属性来设置自定义线程池的 Bean：\n@SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, userThreadPool = \u0026amp;quot;customThreadPool\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 在 Spring 环境使用 API 方式 如果是在 Spring 环境下使用 API 的方式发布服务，可以通过调用 BoltBindingParam 的 setUserThreadPool 方法来设置自定义线程池：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setUserThreadPool(new UserThreadPool()); 在非 Spring 环境下使用 API 方式 如果是在非 Spring 环境下使用 API 的方式，可以通过如下的方式来设置自定义线程池：\nUserThreadPool threadPool = new UserThreadPool(); threadPool.setCorePoolSize(10); threadPool.setMaximumPoolSize(100); threadPool.setKeepAliveTime(200); threadPool.setPrestartAllCoreThreads(false); threadPool.setAllowCoreThreadTimeOut(false); threadPool.setQueueSize(200); UserThreadPoolManager.registerUserThread(ConfigUniqueNameGenerator.getUniqueName(providerConfig), threadPool); 如上为 HelloService 服务设置了一个自定义线程池。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-threadpool/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"3f05f154bcb2b653ebeebb35b84d5ae1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-threadpool/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-threadpool/","summary":"SOFARPC 支持自定义业务线程池。可以为指定服务设置一个独立的业务线程池，和 SOFARPC 自身的业务线程池是隔离的。多个服务可以共用一个独立的线程池。 SOFARPC 要求自定义","tags":null,"title":"自定义线程池","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-threadpool/","wordcount":412},{"author":null,"categories":null,"content":"SOFARPC 中对服务地址的选择也抽象为了一条处理链，由每一个 Router 进行处理。同 Filter 一样， SOFARPC 对 Router 提供了同样的扩展能力。\n@Extension(value = \u0026amp;quot;customerRouter\u0026amp;quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026amp;lt;ProviderInfo\u0026amp;gt; route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) { return providerInfos; } 新建扩展文件 META-INF/services/sofa-rpc/com.alipay.sofa.rpc.client.Router 。内容如下：\ncustomerRouter=com.alipay.sofa.rpc.custom.CustomRouter 如上自定义了一个 CustomerRouter ，生效于所有消费者。其中 init 参数 ConsumerBootstrap 是引用服务的包装类，能够拿到 ConsumerConfig ，代理类，服务地址池等对象。 needToLoad 表示是否生效该 Router ， route 方法即筛选地址的方法。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-router/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"236e8d4bda3e856267a3575853aa900c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-router/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-router/","summary":"SOFARPC 中对服务地址的选择也抽象为了一条处理链，由每一个 Router 进行处理。同 Filter 一样， SOFARPC 对 Router 提供了同样的扩展能力。 @Extension(value = \u0026quot;customerRouter\u0026quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override","tags":null,"title":"自定义路由寻址","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-router/","wordcount":179},{"author":null,"categories":null,"content":" SOFARPC 提供了一套良好的可扩展性机制，为各个模块提供 SPI 的能力。 SOFARPC 对请求与响应的过滤链处理方式是通过多个过滤器 Filter 来进行具体的拦截处理，该部分可由用户自定义 Filter 扩展，自定义 Filter 的执行顺序在内置 Filter 之后。具体方式如下：\nBolt Filter 新建自定义 Filter 。\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 生效该自定义 Filter 到拦截器链中。这一步具体方式有三种。 方式1：API方式。该种方式能够生效到指定的 provider 或 consumer 。\n// 服务提供者 providerConfig.setFilterRef(Arrays.asList(new CustomFilter())); // 服务调用者 consumerConfig.setFilterRef(Arrays.asList(new CustomFilter())); 方式2：在类上加上 @Extension 注解+配置扩展文件方式。\n@Extension(\u0026amp;quot;customer\u0026amp;quot;) public class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 新建扩展文件 META-INF/services/sofa-rpc/com.alipay.sofa.rpc.filter.Filter 。内容如下：\ncustomer=com.alipay.sofa.rpc.custom.CustomFilter 编码注入。\n// 服务提供者 providerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); // 服务调用者 consumerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); 方式三：在类上加上 @Extension 注解+ @AutoActive 注解方式+配扩展文件方式。该种方式利用 @AutoActive 注解代替了上述第二中方式的编码注入步骤，能够生效于所有 provider 或 consumer 。其中 providerSide 参数表示是否生效于服务端， consumerSide 参数表示是否生效于客户端。\n@Extension(\u0026amp;quot;customer\u0026amp;quot;) @AutoActive(providerSide = true, consumerSide = true) public class customerFilter extends Filter { // ... } ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-filter/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"30ff5937b52a7c2dd8028e878979a33d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-filter/","summary":"SOFARPC 提供了一套良好的可扩展性机制，为各个模块提供 SPI 的能力。 SOFARPC 对请求与响应的过滤链处理方式是通过多个过滤器 Filter 来进行具体的拦截处理，该部分可由用户","tags":null,"title":"自定义过滤器","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-filter/","wordcount":409},{"author":null,"categories":null,"content":" 本文是对 MOSN 自定义配置的说明。\nDuration String 字符串，由一个十进制数字和一个时间单位后缀组成，有效的时间单位为 ns、us（或µs）、ms、s、m、h，例如 1h、3s、500ms。 metadata metadata 用于 MOSN 路由和 Cluster Host 之间的匹配。\n{ \u0026amp;quot;filter_metadata\u0026amp;quot;:{ \u0026amp;quot;mosn.lb\u0026amp;quot;:{} } } mosn.lb 可对应任意的 string-string 的内容。\ntls_context { \u0026amp;quot;status\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;server_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;ca_cert\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;cert_chain\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;private_key\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;verify_client\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;require_client_cert\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;insecure_skip\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;cipher_suites\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;ecdh_curves\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;min_version\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;max_version\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;alpn\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;fall_back\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;extend_verify\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;sds_source\u0026amp;quot;:{} } status，bool类型，表示是否开启 TLS，默认是 false。 type，字符串类型，描述 tls_context 的类型。tls_context 支持扩展实现，不同的 type 对应不同的实现方式，默认实现方式对应的 type 是空字符串。 server_name，当没有配置 insecure_skip 时，用于校验服务端返回证书的 hostname。作为Cluster配置时有效。 ca_cert，证书签发的根 CA 证书。 cert_chain，TLS 证书链配置。 private_key，证书私钥配置。 verify_client，bool 类型，作为 Listener 配置时有效，表示是否要校验 Client 端证书 require_client_cert，bool 类型，表示是否强制 Client 端必须携带证书。 insecure_skip，bool 类型，作为 Cluster 配置时有效，表示是否要忽略 Server 端的证书校验。 cipher_suites，如果配置了该配置，那么 TLS 连接将只支持配置了的密码套件，并且会按照配置的顺序作为优先级使用，支持的套件类型如下：\nECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-AES256-CBC-SHA ECDHE-RSA-AES128-CBC-SHA ECDHE-ECDSA-AES256-CBC-SHA ECDHE-ECDSA-AES128-CBC-SHA RSA-AES256-CBC-SHA RSA-AES128-CBC-SHA ECDHE-RSA-3DES-EDE-CBC-SHA RSA-3DES-EDE-CBC-SHA ECDHE-RSA-SM4-SM3 ECDHE-ECDSA-SM4-SM3 ecdh_curves，如果配置了该配置，那么 TLS 连接将只支持配置了的曲线。\n 支持 x25519、p256、p384、p521。 min_version，最低的 TLS 协议版本，默认是 TLS1.0。\n 支持 TLS1.0、TLS1.1、TLS1.2。 默认会自动识别可用的 TLS 协议版本。 max_version，最高的 TLS 协议版本，默认是 TLS1.2。\n 支持 TLS1.0、TLS1.1、TLS1.2。 默认会自动识别可用的 TLS 协议版本。 alpn，TLS 的 ALPN 配置。\n 支持 h2、http/1.1、 sofa。 fall_back，bool类型，当配置为 true 时，如果证书解析失败，不会报错而是相当于没有开启 TLS。\n extend_verify，任意 json 类型，当 type 为非空时，作为扩展的配置参数。\n sds_source，访问 SDS API 的配置，如果配置了这个配置，ca_cert、cert_chain 和 private_key 都会被忽略，但是其余的配置依然有效。\n sds_source { \u0026amp;quot;CertificateConfig\u0026amp;quot;:{}, \u0026amp;quot;ValidationConfig\u0026amp;quot;:{} } CertificateConfig 描述了如何获取 cert_chain 和 private_key 的配置。 ValidationConfig 描述了如何获取 ca_cert 的配置。 详细的 Config 内容参考 envoy: sdssecretconfig。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/custom/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"cdad467fd3551e47a7585511278767cd","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/custom/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/configuration/custom/","summary":"本文是对 MOSN 自定义配置的说明。 Duration String 字符串，由一个十进制数字和一个时间单位后缀组成，有效的时间单位为 ns、us（或µs）、ms、s、m、h，例如","tags":null,"title":"自定义配置说明","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/custom/","wordcount":1005},{"author":null,"categories":null,"content":" SOFARPC 支持进行框架层面的重试策略，前提是集群模式为 FailOver（SOFARPC 默认即为 FailOver 模式）。重试只有在发生服务端的框架层面异常或者是超时异常才会发起。如果是业务抛出异常，是不会重试的。默认情况下 SOFARPC 不进行任何重试。\n 请注意：超时异常虽然可以重试，但是需要服务端保证业务的幂等性，否则可能会有风险\n XML 方式 如果使用 XML 方式订阅服务，可以设置 sofa:global-attrs 的 retries 参数来设置重试次数：\n\u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;retriesServiceReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.retries.RetriesService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs retries=\u0026amp;quot;2\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 如果是使用 Annotation 的方式，可以通过设置 @SofaReferenceBinding 注解的 retries 属性来设置：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, retries = 2)) private SampleService sampleService; Spring 环境下 API 方式 如果是在 Spring 环境下用 API 的方式，可以调用 BoltBindingParam 的 setRetries 方法来设置：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setRetries(2); 非 Spring 环境下 API 方式 如果是在非 Spring 环境下直接使用 SOFARPC 的裸 API 的方式，可以通过调用 ConsumerConfig 的 setRetries 方法来设置：\nConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt;(); consumerConfig.setRetries(2); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/retry-invoke/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d60b44aa8f1b49ab6c1bbc55593a91da","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/retry-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/retry-invoke/","summary":"SOFARPC 支持进行框架层面的重试策略，前提是集群模式为 FailOver（SOFARPC 默认即为 FailOver 模式）。重试只有在发生服务端的框架层面异常或者是超时","tags":null,"title":"调用重试","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/retry-invoke/","wordcount":319},{"author":null,"categories":null,"content":" SOFARPC 提供多种负载均衡算法，目前支持以下五种：\n 类型 名称 描述 random 随机算法 默认负载均衡算法。 localPref 本地优先算法 优先发现是否本机发布了该服务，如果没有再采用随机算法。 roundRobin 轮询算法 方法级别的轮询，各个方法间各自轮询，互不影响。 consistentHash 一致性hash算法 同样的方法级别的请求会路由到同样的节点。 weightRoundRobin 按权重负载均衡轮询算法 按照权重对节点进行轮询。性能较差，不推荐使用。 要使用某种特定的负载均衡算法，可以按照以下的方式进行设置：\nXML 方式 如果使用 XML 的方式引用服务，可以通过设置 sofa:global-attrs 标签的 loadBalancer 属性来设置：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs loadBalancer=\u0026amp;quot;roundRobin\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 Annotation 方式目前暂未提供设置某一个 Reference 的负载均衡算法的方式。将在后续的版本中提供。\n在 Spring 环境下 API 方式 如果在 Spring 或者 Spring Boot 的环境下使用 API，可以通过调用 BoltBindingParam 的 setLoadBalancer 方法来设置：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setLoadBalancer(\u0026amp;quot;roundRobin\u0026amp;quot;); 非 Spring 环境下 API 方式 如果在非 Spring 环境下直接使用 SOFARPC 提供的裸 API，可以通过调用 ConsumerConfig 的 setLoadBalancer 方法来设置：\nConsumerConfig consumerConfig = new ConsumerConfig(); consumerConfig.setLoadbalancer(\u0026amp;quot;random\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/load-balance/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"739984ca9a414429304f85010fd73ad0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/load-balance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/load-balance/","summary":"SOFARPC 提供多种负载均衡算法，目前支持以下五种： 类型 名称 描述 random 随机算法 默认负载均衡算法。 localPref 本地优先算法 优先发现是否本机发布了该服务，如果没有再采用","tags":null,"title":"负载均衡","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/load-balance/","wordcount":375},{"author":null,"categories":null,"content":" 任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 文档 SOFADashboard 配置参数文档 简单 代码 支持 SOFARegistry 中 代码 支持 Docker 中 代码 支持 Kubernetes 中 代码 支持 Apollo 中 代码 优化前端 中 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/roadmap/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"a740c874742b504de9011b07f3a4ddb5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/roadmap/","summary":"任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 文档 SOFADashboard 配置参数文档 简","tags":null,"title":"路线图及任务认领","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/roadmap/","wordcount":102},{"author":null,"categories":null,"content":" 1. registry-meta 1.1 推送开关 在注册中心新版本发布的过程中为了把对业务的影响减少到最小，避免服务端重启动引发大规模服务地址信息变更产生大量推送，我们提供运维层面暂时关闭推送的能力。在服务端完成发布后，可以打开推送恢复正常工作状态，在关闭期间的数据订阅和服务发布信息会再次进行全局推送进行补偿。\n打开推送：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/close\u0026amp;quot; 关闭推送：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/open\u0026amp;quot; 1.2 查询地址列表 查看 meta 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/META/node/query\u0026amp;quot; 查看 data 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/DATA/node/query\u0026amp;quot; 查看 session 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/SESSION/node/query\u0026amp;quot; 2. registry-data 2.1 查询数据 查看 pub 数量：\ncurl \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/datum/count\u0026amp;quot; 根据客户端的 ip\u0026amp;amp;port 查询其发布的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;\u0026amp;quot;:\u0026amp;quot;\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;}\u0026#39; 3. registry-session 3.1 查询数据 根据客户端的 ip\u0026amp;amp;port 查询其发布的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/pub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]\u0026#39; 根据客户端的 ip\u0026amp;amp;port 查询其订阅的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/sub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]\u0026#39; 3.2 断开客户端链接：clientOff 根据客户端的 ip\u0026amp;amp;port 强制删除其所有 sub\u0026amp;amp;pub 数据（但不会断开连接）：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/api/clients/off\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;connectIds\u0026amp;quot;: [\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]}\u0026#39; ","date":-62135596800,"description":"","dir":"projects/sofa-registry/management-api/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"2cf59ac422c84c279d73c1f7f1cd0902","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/management-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/management-api/","summary":"1. registry-meta 1.1 推送开关 在注册中心新版本发布的过程中为了把对业务的影响减少到最小，避免服务端重启动引发大规模服务地址信息变更产生大量推送，我们提供运维","tags":null,"title":"运维命令","type":"projects","url":"/sofastack.tech/projects/sofa-registry/management-api/","wordcount":554},{"author":null,"categories":null,"content":"SOFARPC 支持不同的通信协议，目前支持 Bolt, RESTful 和 Dubbo，详细的事情请参考各个协议对应的文档： * Bolt 协议 * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化协议 * 自定义线程池 * RESTful * 基本使用 * 自定义 Filter * 集成 Swagger * Dubbo * 基本使用 * H2C * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/protocol/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"18f51cb12f7a0384a71ab22349292a08","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/protocol/","summary":"SOFARPC 支持不同的通信协议，目前支持 Bolt, RESTful 和 Dubbo，详细的事情请参考各个协议对应的文档： * Bolt 协议 * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化","tags":null,"title":"通信协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/protocol/","wordcount":109},{"author":null,"categories":null,"content":" 1. 环境准备 要使用 SOFARegistry，需要先准备好基础环境，SOFARegistry 依赖以下环境：\n Linux/Unix/Mac JDK8 需要采用 Apache Maven 3.2.5 或者以上的版本来编译 2. 资源配额 cpu: 4c memory: 8G disk: 50G 3. 两种部署模式 集成部署模式 将 meta/data/session 三个角色打包集成在一个 jvm 里运行，可单机或集群部署，部署简单。 独立部署模式 将 meta/data/session 三个角色分开部署，每个角色都可以单机或集群部署，可根据实际情况为每个角色部署不同的数量。 生产环境建议使用这种部署模式。 4. 配置参数 SOFARegistry 的部署，依赖于一些公共参数\n properties environment 默认值 作用 nodes.localDataCenter x DefaultDataCenter 集群名，多个注册中心公用同一个数据库用到 nodes.localRegion x DEFAULT_ZONE 逻辑 region, 创建多组 session jdbc.url JDBC_URL 必填 数据库地址 jdbc.username JDBC_USERNAME 必填 数据库用户名 jdbc.password JDBC_PASSWORD 必填 数据库密码 properties 可以写在 registry-all/conf/application.properties 中， kubernetes 下部署也可以使用 configmap 进行文件挂载\n5. 打包 jar release 页面 下载最新的 registry-all.tgz 包\ntar -zxvf registry-all.tgz cd registry-all 或者从源码打包\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Pserver-release -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all image image 托管于 https://hub.docker.com/r/sofaregistry/sofaregistry\n或者从源码 build: 修改 Makefile 中 image 的 repository\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true make image_build make image_push 6. 集成部署模式 集成部署模式，是将 meta/data/session 三个角色打包集成在一个 JVM 里运行，可单机或集群部署, 不建议大规模使用\n6.1 jar 单机部署 集成部署的单机部署模式可以直接参考快速开始-服务端部署部分。\n6.2 jar 集群部署 解压 registry-all.tgz，并修改配置文件 集群部署，即搭建 2 台以上的集群，建议至少使用 3 台（注意：目前不支持在同一台机器部署多个 SOFARegistry，因此您必须有 3 台不同的机器）。在每一台机器上的部署方法同上：\ncp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all 区别是每台机器在部署时需要修改 registry-all/conf/application.properties 配置, 组成同一个注册中心的多台机器需要配置相同的数据库和nodes.localDataCenter\nnodes.localDataCenter=DefaultDataCenter nodes.localRegion=DEFAULT_ZONE jdbc.url = jdbc:mysql://127.0.0.1:3306/registrymetadb?useUnicode=true\u0026amp;amp;characterEncoding=utf8 jdbc.username = root jdbc.password = root 启动 registry-integration 每台机器都修改以上配置文件后，按照“单机部署”的步骤去启动 registry-integration 即可。 sh bin/integration/start.sh\n6.3 docker 集群部署 客户端和 SOFARegistry 需要同一个三层网络内，因此利用 docker 部署需要使用 host network 可以通过配置文件挂载的方式进行部署，也可以通过环境变量传递的方式 同时需要添加 REGISTRY_APP_NAME=integration 进入集成模式，在一个 jvm 里启动 3 个角色\nimage 中， registry-all.tgz 的解压地址在 registry-distribution/registry-all, 配置需要挂载到正确的目录\ndocker run -e REGISTRY_APP_NAME=integration \\ --name=sofa-registry --rm --net=host \\ -v $PWD/conf/:/registry-distribution/registry-all/conf/ \\ -e JDBC_URL=jdbc:mysql://172.17.0.1:3306/registrymetadb -e JDBC_USERNAME=root -e JDBC_PASSWORD=root sofaregistry/sofaregistry:6.1.4 7. 独立部署模式 独立部署模式，是将 meta/data/session 三个角色分开部署，每个角色都可以单机或集群部署，可根据实际情况为每个角色部署不同的数量，生产环境推荐使用这种部署模式。\n以下介绍 332 模式（即 3 台 meta + 3 台 data + 2 台 session）的部署步骤。\n7.1 jar 集群部署 解压 registry-all.tgz，并修改配置文件 集群部署，即搭建 2 台以上的集群，建议至少使用 3 台（注意：目前不支持在同一台机器部署多个 SOFARegistry，因此您必须有 3 台不同的机器）。在每一台机器上的部署方法同上： cp …","date":-62135596800,"description":"","dir":"projects/sofa-registry/deployment/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"7e28583bc38be66af8d704d7fbcd9dd4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/deployment/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/deployment/","summary":"1. 环境准备 要使用 SOFARegistry，需要先准备好基础环境，SOFARegistry 依赖以下环境： Linux/Unix/Mac JDK8 需要采用 Apache Maven 3.2.5 或者以上的版本来编译","tags":null,"title":"部署","type":"projects","url":"/sofastack.tech/projects/sofa-registry/deployment/","wordcount":1558},{"author":null,"categories":null,"content":" MOSN 的配置文件可以分为以下四大部分：\n Servers 配置，目前仅支持最多 1 个 Server 的配置，Server 中包含一些基础配置以及对应的 Listener 配置 ClusterManager 配置，包含 MOSN 的 Upstream 详细信息 对接控制平面（Pilot）的 xDS 相关配置 其他配置 Trace、Metrics、Debug、Admin API 相关配置 扩展配置，提供自定义配置扩展需求 配置文件概览\nMOSN 的基本配置部分如下所示：\n{ \u0026amp;quot;servers\u0026amp;quot;: [], \u0026amp;quot;cluster_manager\u0026amp;quot;: {}, \u0026amp;quot;dynamic_resources\u0026amp;quot;: {}, \u0026amp;quot;static_resources\u0026amp;quot;: {}, \u0026amp;quot;admin\u0026amp;quot;:{}, \u0026amp;quot;pprof\u0026amp;quot;:{}, \u0026amp;quot;tracing\u0026amp;quot;:{}, \u0026amp;quot;metrics\u0026amp;quot;:{} } 配置类型 MOSN 的配置包括以下几种类型：\n 静态配置 动态配置 混合模式 静态配置 静态配置是指 MOSN 启动时，不对接控制平面 Pilot 的配置，用于一些相对固定的简单场景（如 MOSN 的示例）。 使用静态配置启动的 MOSN，也可以通过扩展代码，调用动态更新配置的接口实现动态修改。 静态配置启动时必须包含一个 Server 以及至少一个 Cluster。 动态配置 动态配置是指 MOSN 启动时，只有访问控制平面相关的配置，没有 MOSN 运行时所需要的配置。\n 使用动态配置启动的 MOSN，会向管控面请求获取运行时所需要的配置，管控面也可能在运行时推送更新 MOSN 运行配置。\n 动态配置启动时必须包含 DynamicResources 和 StaticResources 配置。\n 混合模式 MOSN 启动时的配置可以同时包含静态模式与动态模式，以混合模式启动的 MOSN 会先以静态配置完成初始化，随后可能由控制平面获取配置更新。\n配置示例 静态配置示例 动态配置的示例如下所示。\n{ \u0026amp;quot;servers\u0026amp;quot;: [ { \u0026amp;quot;default_log_path\u0026amp;quot;: \u0026amp;quot;/home/admin/logs/mosn/default.log\u0026amp;quot;, \u0026amp;quot;default_log_level\u0026amp;quot;: \u0026amp;quot;DEBUG\u0026amp;quot;, \u0026amp;quot;processor\u0026amp;quot;: 4, \u0026amp;quot;listeners\u0026amp;quot;: [ { \u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;0.0.0.0:12220\u0026amp;quot;, \u0026amp;quot;bind_port\u0026amp;quot;: true, \u0026amp;quot;filter_chains\u0026amp;quot;: [ { \u0026amp;quot;filters\u0026amp;quot;: [ { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;proxy\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;downstream_protocol\u0026amp;quot;: \u0026amp;quot;SofaRpc\u0026amp;quot;, \u0026amp;quot;upstream_protocol\u0026amp;quot;: \u0026amp;quot;SofaRpc\u0026amp;quot;, \u0026amp;quot;router_config_name\u0026amp;quot;: \u0026amp;quot;test_router\u0026amp;quot; } }, { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;connection_manager\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;router_config_name\u0026amp;quot;: \u0026amp;quot;test_router\u0026amp;quot;, \u0026amp;quot;virtual_hosts\u0026amp;quot;: [] } } ] } ] } ] } ], \u0026amp;quot;cluster_manager\u0026amp;quot;: { \u0026amp;quot;clusters\u0026amp;quot;: [ { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;example\u0026amp;quot;, \u0026amp;quot;lb_type\u0026amp;quot;: \u0026amp;quot;LB_ROUNDROBIN\u0026amp;quot;, \u0026amp;quot;hosts\u0026amp;quot;: [ {\u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;127.0.0.1:12200\u0026amp;quot;} ] } ] } } 动态配置示例 静态配置的示例如下所示。\n{ \u0026amp;quot;dynamic_resources\u0026amp;quot;: { \u0026amp;quot;ads_config\u0026amp;quot;: { \u0026amp;quot;api_type\u0026amp;quot;: \u0026amp;quot;GRPC\u0026amp;quot;, \u0026amp;quot;grpc_services\u0026amp;quot;: [ { \u0026amp;quot;envoy_grpc\u0026amp;quot;: {\u0026amp;quot;cluster_name\u0026amp;quot;: \u0026amp;quot;xds-grpc\u0026amp;quot;} } ] } } }, \u0026amp;quot;static_resources\u0026amp;quot;: { \u0026amp;quot;clusters\u0026amp;quot;: [ { \u0026amp;quot;name\u0026amp;quot;: \u0026amp;quot;xds-grpc\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;STRICT_DNS\u0026amp;quot;, \u0026amp;quot;connect_timeout\u0026amp;quot;: \u0026amp;quot;10s\u0026amp;quot;, \u0026amp;quot;lb_policy\u0026amp;quot;: \u0026amp;quot;ROUND_ROBIN\u0026amp;quot;, \u0026amp;quot;hosts\u0026amp;quot;: [ { \u0026amp;quot;socket_address\u0026amp;quot;: {\u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;pilot\u0026amp;quot;, \u0026amp;quot;port_value\u0026amp;quot;: 15010} } ], \u0026amp;quot;upstream_connection_options\u0026amp;quot;: { \u0026amp;quot;tcp_keepalive\u0026amp;quot;: { \u0026amp;quot;keepalive_time\u0026amp;quot;: 300 } }, \u0026amp;quot;http2_protocol_options\u0026amp;quot;: { } } ] } } ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/overview/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"0aa65950d2c24e8ce86d265bea275e2a","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/configuration/overview/","summary":"MOSN 的配置文件可以分为以下四大部分： Servers 配置，目前仅支持最多 1 个 Server 的配置，Server 中包含一些基础配置以及对应的 Listener 配置 ClusterManager 配置，包含 MOSN 的 Upstream 详细信","tags":null,"title":"配置概览","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/overview/","wordcount":663},{"author":null,"categories":null,"content":" 目前 SOFATracer 提供了两种采样模式，一种是基于 BitSet 实现的基于固定采样率的采样模式；另外一种是提供给用户自定义实现采样的采样模式。下面通过案例来演示如何使用。\n本示例基于 tracer-sample-with-springmvc 工程；除 application.properties 之外，其他均相同。\n基于固定采样率的采样模式 在 application.properties 中增加采样相关配置项 #采样率 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #采样模式类型名称 com.alipay.sofa.tracer.samplerName=PercentageBasedSampler 验证方式 当采样率设置为100时，每次都会打印摘要日志。 当采样率设置为0时，不打印 当采样率设置为0~100之间时，按概率打印 以请求 10 次来验证下结果。\n1、当采样率设置为100时，每次都会打印摘要日志\n启动工程，浏览器中输入：http://localhost:8080/springmvc ；并且刷新地址10次，查看日志如下：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:47.643\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173568757510019269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:68,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:50.980\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569097710029269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:51.542\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569153910049269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-4\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:52.061\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569205910069269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:2,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-6\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/sampler/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"48856a040da01abc84213934c1c5fce4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/sampler/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/sampler/","summary":"目前 SOFATracer 提供了两种采样模式，一种是基于 BitSet 实现的基于固定采样率的采样模式；另外一种是提供给用户自定义实现采样的采样模式。下面通过案例来演示如何使","tags":null,"title":"采样模式","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/sampler/","wordcount":719},{"author":null,"categories":null,"content":" 链路数据透传 链路数据透传功能支持应用向调用上下文中存放数据，达到整个链路上的应用都可以操作该数据。 使用方式如下，可分别向链路的 request 和 response 中放入数据进行透传，并可获取到链路中相应的数据。\nRpcInvokeContext.getContext().putRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;,\u0026amp;quot;value_request\u0026amp;quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;,\u0026amp;quot;value_response\u0026amp;quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;); 使用示例 例如 A -\u0026amp;gt; B -\u0026amp;gt; C 的场景中，将 A 设置的请求隐式传参数据传递给 B 和 C。在返回的时候，将 C 和 B 的响应隐式传参数据传递给 A。\nA 请求方设置的时候：\n// 调用前设置请求透传的值 RpcInvokeContext context = RpcInvokeContext.getContext(); context.putRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;, \u0026amp;quot;a2bbb\u0026amp;quot;); // 调用 String result = service.hello(); // 拿到结果透传的值 context.getResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;); B 业务代码中：\npublic String hello() { // 拿到请求透传的值 RpcInvokeContext context = RpcInvokeContext.getContext(); String reqBaggage = context.getRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;); // doSomthing(); // 结果透传一个值 context.putResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;, \u0026amp;quot;b2aaa\u0026amp;quot;); return result; } 如果中途自己启动了子线程，则需要设置子线程的上下文：\nCountDownLatch latch = new CountDownLatch(1); final RpcInvokeContext parentContext = RpcInvokeContext.peekContext(); Thread thread = new Thread(new Runnable(){ public void run(){ try { RpcInvokeContext.setContext(parentContext); // 调一个远程服务 xxxService.sayHello(); latch.countDown(); } finally { RpcInvokeContext.removeContext(); } } }, \u0026amp;quot;new-thread\u0026amp;quot;); thread.start(); // 此时拿不到返回值透传的数据的 latch.await(); //等待 // 此时返回结束，能拿到返回透传的值 和 SOFATracer 的比较 SOFATracer 是蚂蚁开源的一个分布式链路追踪系统,RPC 目前已经和 Tracer 做了集成,默认开启. 和 Tracer 进行数据传递不同的是\n RPC的数据透传更偏向业务使用,而且可以在全链路中进行双向传递,调用方可以传给服务方,服务方也可以传递信息给调用方,SOFATracer 更加偏向于中间件和业务无感知的数据的传递,只能进行单向传递. RPC的透传可以选择性地不在全链路中透传,而Tracer 中如果传递大量信息,会在整个链路中传递.可能对下游业务会有影响. 所以整体来看,两个信息各有利弊,在有一些和业务相关的透传数据的情况下,可以选择 RPC 的透传.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-chain-pass-data/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"96cfb41f07a6a2ad979b53093ff5eee9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","summary":"链路数据透传 链路数据透传功能支持应用向调用上下文中存放数据，达到整个链路上的应用都可以操作该数据。 使用方式如下，可分别向链路的 request 和 response 中放入数","tags":null,"title":"链路数据透传","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","wordcount":606},{"author":null,"categories":null,"content":"默认 SOFARPC 已经集成了 SOFATracer，用户也可以使用其他的 APM 产品，如 Skywalking来实现相应的功能。详见文档：\n SOFATracer Skywalking 如果想要关闭 SOFARPC 的链路追踪能力的话，在使用了 rpc-sofa-boot-starter 的情况下，可以在 application.properties 配置文件中配置 com.alipay.sofa.rpc.defaultTracer=。\n在直接使用 sofa-rpc-all 的情况下，可以在 main 函数里面加上如下的代码来关闭 SOFARPC 的链路追踪的能力（在发布任何 SOFARPC 的服务或者引用任何 SOFARPC 的服务之前）：\nRpcConfigs.putValue(RpcOptions.DEFAULT_TRACER, \u0026amp;quot;\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/tracing-usage/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"5f944f87d827ae060fb0528f6715af97","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/tracing-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/tracing-usage/","summary":"默认 SOFARPC 已经集成了 SOFATracer，用户也可以使用其他的 APM 产品，如 Skywalking来实现相应的功能。详见文档： SOFATracer Skywalking 如果想要关闭 SOFARPC 的链路","tags":null,"title":"链路追踪","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/tracing-usage/","wordcount":197},{"author":null,"categories":null,"content":" 从 rpc-sofa-boot-starter 6.0.1 版本开始，SOFARPC 提供了 RESTful 服务和 Swagger 的一键集成的能力。\n在使用了 rpc-sofa-boot-starter 的情况下，如果想要开启 swagger 的能力，首先需要在 pom.xml 中增加 Swagger 的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 里面增加 com.alipay.sofa.rpc.restSwagger=true。\n最后，访问 http://localhost:8341/swagger/openapi 就可以拿到 SOFARPC 的 RESTful 的 Swagger OpenAPI 内容。\n如果没有使用 rpc-sofa-boot-starter 或者在 rpc-sofa-boot-starter 的版本低于 6.0.1，可以采用如下的方式集成 Swagger。\n首先，需要在应用中引入 Swagger 相关的依赖，由于 SOFARPC 的 RESTful 协议走的是 JAXRS 标准，因此我们引入 Swagger 的 JAXRS 依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 上面引入 Guava 的 20.0 的版本是为了解决 Guava 的版本冲突。\n增加一个 Swagger 的 RESTful 服务 为了能够让 Swagger 将 SOFARPC 的 RESTful 的服务通过 Swagger OpenAPI 暴露出去，我们可以反过来用 SOFARPC 的 RESTful 的服务提供 Swagger 的 OpenAPI 服务。首先，需要新建一个接口：\n@Path(\u0026amp;quot;swagger\u0026amp;quot;) public interface OpenApiService { @GET @Path(\u0026amp;quot;openapi\u0026amp;quot;) @Produces(\u0026amp;quot;application/json\u0026amp;quot;) String openApi(); } 然后提供一个实现类，并且发布成 SOFARPC 的 RESTful 的服务：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}, interfaceType = OpenApiService.class) public class OpenApiServiceImpl implements OpenApiService, InitializingBean { private OpenAPI openAPI; @Override public String openApi() { return Json.pretty(openAPI); } @Override public void afterPropertiesSet() { List\u0026amp;lt;Package\u0026amp;gt; resources = new ArrayList\u0026amp;lt;\u0026amp;gt;(); resources.add(this.getClass().getPackage()); // 扫描当前类所在的 Package，也可以扫描其他的 SOFARPC RESTful 服务接口所在的 Package if (!resources.isEmpty()) { // init context try { SwaggerConfiguration oasConfig = new SwaggerConfiguration() .resourcePackages(resources.stream().map(Package::getName).collect(Collectors.toSet())); OpenApiContext oac = new JaxrsOpenApiContextBuilder() .openApiConfiguration(oasConfig) .buildContext(true); openAPI = oac.read(); } catch (OpenApiConfigurationException e) { throw new RuntimeException(e.getMessage(), e); } } } } 这样，应用启动后，访问 http://localhost:8341/swagger/openapi 即可得到当前的应用发布的所有的 RESTful 的服务的信息。\n解决跨域问题 如果用户在另外一个端口中启动了一个 Swagger UI，并且希望通过 Swagger UI 来访问 http://localhost:8341/swagger/openapi 查看 API 定义，发起调用，那么可能需要解决访问跨域的问题，要解决 SOFARPC RESTful 服务访问跨域的问题，可以在应用启动前增加如下的代码：\nimport org.jboss.resteasy.plugins.interceptors.CorsFilter; public static void main(String[] args) { CorsFilter corsFilter = new CorsFilter(); corsFilter.getAllowedOrigins().add(\u0026amp;quot;*\u0026amp;quot;); …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-swagger/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"d068767fe0dd2922eecef69736684be8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-swagger/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-swagger/","summary":"从 rpc-sofa-boot-starter 6.0.1 版本开始，SOFARPC 提供了 RESTful 服务和 Swagger 的一键集成的能力。 在使用了 rpc-sofa-boot-starter 的情况下，如果想要开启 swagger 的能力，首先需要在 pom.xml 中增加 Swagger 的依赖： \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.swagger.core.v3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;swagger-jaxrs2\u0026lt;/artifactId\u0026gt;","tags":null,"title":"集成 SOFARPC RESTful 服务和 Swagger","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-swagger/","wordcount":646},{"author":null,"categories":null,"content":" 服务发布 服务发布过程涉及到三个类 RegistryConfig ，ServerConfig ，ProviderConfig 。\n1. RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;) RegistryConfig 表示注册中心。如上声明了服务注册中心的地址和端口是127.0.0.1:2181，协议是 Zookeeper。\n2. ServerConfig\nServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ServerConfig 表示服务运行容器。如上声明了一个使用8803端口和 bolt 协议的 server 。\n3. ProviderConfig\nProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt;() .setInterfaceId(HelloWorldService.class.getName()) .setRef(new HelloWorldServiceImpl()) .setServer(serverConfig) .setRegistry(registryConfig); providerConfig.export(); ProviderConfig 表示服务发布。如上声明了服务的接口，实现和该服务运行的 server 。 最终通过 export 方法将这个服务发布出去了。\n服务引用 服务引用涉及到两个类， RegistryConfig 和 ConsumerConfig 。\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig); HelloService helloService = consumerConfig.refer(); ConsumerConfig 表示服务引用，如上声明了所引用服务的接口和服务注册中心。 最终通过 refer 方法将这个服务引用，获取到该服务的远程调用的代理。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-rpc/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"ee6f74a4974c7abf72322cef108d5ef0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-rpc/","summary":"服务发布 服务发布过程涉及到三个类 RegistryConfig ，ServerConfig ，ProviderConfig 。 1. RegistryConfig RegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026quot;zookeeper\u0026quot;) .setAddress(\u0026quot;127.0.0.1:2181\u0026quot;) RegistryConfig 表示注册中心。如上声明了服务","tags":null,"title":"非 Spring 环境 API 使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-rpc/","wordcount":300},{"author":null,"categories":null,"content":"预热权重功能让客户端机器能够根据服务端的相应权重进行流量的分发。该功能也常被用于集群内少数机器的启动场景。利用流量权重功能在短时间内对服务端机器进行预热，然后再接收正常的流量比重。 运行机制如下： 1.服务端服务在启动时会将自身的预热时间，预热期内权重，预热完成后的正常权重推送给服务注册中心。如上图 ServiceB 指向 Service Registry 。\n2.客户端在引用服务的时候会获得每个服务实例的预热权重信息。如上图 Service Registry 指向 client 。\n3.客户端在进行调用的时候会根据服务所在地址的预热时期所对应的权重进行流量分发。如上图 client 指向 ServiceA 和 ServiceB 。 ServiceA 预热完毕，权重默认 100 ， ServiceB 处于预热期，权重为 10，因此所承受流量分别为 100%110 和 10%110 。\n该功能使用方式如下。\nProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt;() .setWeight(100) .setParameter(ProviderInfoAttrs.ATTR_WARMUP_WEIGHT,\u0026amp;quot;10\u0026amp;quot;) .setParameter(ProviderInfoAttrs.ATTR_WARM_UP_END_TIME,\u0026amp;quot;12000\u0026amp;quot;); 如上，该服务的预热期为12s，在预热期内权重为10，预热期结束后的正常权重为100。如果该服务一共发布在两个机器A,B上，A机器正处于预热期内，并使用上述配置，B已经完成预热，正常权重为200。那么客户端在调用的时候，此时流量分发的比重为10：200，A机器预热结束后，流量分发比重为100：200。 在SOFABoot中，如下配置预热时间，预热期间权重和预热完后的权重即可。\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleRestFacadeReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.endpoint.facade.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs weight=\u0026amp;quot;100\u0026amp;quot; warm-up-time=\u0026amp;quot;10000\u0026amp;quot; warm-up-weight=\u0026amp;quot;1000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/provider-warmup-weight/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877533,"objectID":"b9e320dfaa4f9700ecdca67d76e07d54","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","summary":"预热权重功能让客户端机器能够根据服务端的相应权重进行流量的分发。该功能也常被用于集群内少数机器的启动场景。利用流量权重功能在短时间内对服务端","tags":null,"title":"预热权重","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","wordcount":497}] \ No newline at end of file +[{"author":null,"categories":["SOFAStack"],"content":" \nSOFAStack™ (Scalable Open Financial Architecture Stack) is a collection of cloud native middleware components, which are designed to build distributed systems with high performance and reliability, and have been fully validated by mission-critical financial business scenarios.\nLinks Home Page: https://www.sofastack.tech\nSource Code: https://github.com/sofastack\nProjects SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, log space isolation and asynchronous initialization of bean. SOFARPC is a high-performance, high-extensibility, production-level Java RPC framework. SOFAMesh SOFAMesh is a large-scale implementation solution for Service Mesh which is improved and extended based on Istio. SOFAMosn SOFAMosn(Modular Observable Smart Network) is a powerful proxy acting as Service Mesh\u0026amp;rsquo;s data plane written in Go. SOFATracer SOFATracer is a distributed link tracing system based onOpenTracing specification. SOFALookout SOFALookout is a lightweight and open source middleware service that solves the metrics and monitoring issues of the system. SOFABolt SOFABolt is a network communication framework implemented based on Netty. SOFAArk SOFAArk is a light-weight, java based classloader isolation framework. SOFAJarslink Is a dynamic modules and merged deployments solution based on SOFAArk. SOFAActs ACTS (AntCoreTest) is a white-box testing framework that is based on the accumulation of testing practices for financial-grade distributed architectures. SOFAJraft SOFAJRaft is a production-grade, high-performance Java implementation based on the RAFT consensus algorithm. SOFARegistry SOFARegistry is a production ready, high efficient, highly available service registry. SOFADashboard Is a one-stop console of SOFAStack. More projects in: github/sofastack\nCommunity Github\n WeChat\n Official Account：Antfin_SOFA is a technology exchange platform dedicated to building first-class distributed technologies in financial scenario applications, focusing on the most cutting-edge, reference-oriented technical solutions and implementation routes in the financial technology industry. WeChat Groups：We have ten groups and more than four thousand developers, Add ant-techfin02 as your friend, and reply SOFA will invite to joining into the group. DingTalk\n DingTalk Group:\n 「SOFAStack 1」 No: 23127468 Group is Full\n 「SOFAStack 2」 No: 23195297 Group is Full\n 「SOFAStack 3」 No: 23390449 Group is Full\n 「SOFAStack 4」 No: 23372465 Group is Full\n 「SOFAStack 5」 No: 30315793\n DingTalk Group:「SOFAStack Online service」, If you have used any SOFAStack related components in a production environment, please let us know, and we will invite you to join this group for faster communication and more efficient use of problem support online. Weibo\n SegmentFault\n juejin.im\n ","date":1524135415,"description":"Say hello to SOFAStack!","dir":"blog/hello-sofastack/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"26e249e6b2d0e482eb4404b76dabaec4","permalink":"https://sofastack.github.io/sofastack.tech/en/blog/hello-sofastack/","publishdate":"2018-04-19T11:56:55+01:00","readingtime":2,"relpermalink":"/sofastack.tech/en/blog/hello-sofastack/","summary":"SOFAStack™ (Scalable Open Financial Architecture Stack) is a collection of cloud native middleware components, which are designed to build distributed systems with high performance and reliability, and have been fully validated by mission-critical financial business scenarios.\nLinks Home Page: https://www.sofastack.tech\nSource Code: https://github.com/sofastack\nProjects SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, log space isolation and asynchronous initialization of bean.","tags":["SOFAStack"],"title":"Hello SOFAStack!","type":"blog","url":"/sofastack.tech/en/blog/hello-sofastack/","wordcount":383},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFA 六周年，Hello SOFA World！\n 活动时间：04 月 20 日 13:30\u0026amp;ndash;18:00\n 活动形式：线下 Meetup + 线上直播\n 资料下载：\n Apache Seata(incubating) 新征程\n探索微服务下一站，Koupleless 模块化研发框架与运维调度系统\n开源：除了代码之外还需要做哪些事？\n厚积薄发 - MOSN 社区开启新征程\nSOFABoot - 新一代研发框架\nEnvoy 网关基于 MOE 架构的落地与实践\n介绍 2024 年 4 月 20 日，\nSOFAStack 社区在上海 S 空间与社区小伙伴一起庆祝的第 6 个生日。\n大家一起进入到「SOFA 世界」\n非正式会议+室内露营的活动形式\n让 SOFAer 的技术交流更为轻松自在，现场的开源技术探索氛围十分浓厚。\n现场回顾 点击👉 云相册 进行查看\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 王特（花名：亦夏），Apache Seata(incubating) 社区 PPMC\n 赵真灵（花名：有济），Koupleless 社区负责人\n 马振军（花名：古今），Layotto 社区负责人\n 朱德江（花名：人德），MOSN 开源负责人\n 胡子杰（花名：致节），SOFABoot 社区 PMC\n 杜鑫，中国电子云技术专家、MOSN 社区开发者\n 议程 了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1713596400,"description":"2024 年 4 月 20 日，我们在上海一起庆祝了 SOFA 社区的六岁生日。","dir":"activities/sofa-6th-anniversary/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5711a60fad8f2916fe1fd7bbd9f07242","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-6th-anniversary/","publishdate":"2024-04-20T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-6th-anniversary/","summary":"概要 活动主题：SOFA 六周年，Hello SOFA World！ 活动时间：04 月 20 日 13:30\u0026ndash;18:00 活动形式：线下 Meetup + 线上直播 资料下载： Apache Seata(incubating) 新征程 探索微服务下一站，","tags":["SOFAStack","开源六周年"],"title":"SOFA 六周年，Hello SOFA World","type":"activities","url":"/sofastack.tech/activities/sofa-6th-anniversary/","wordcount":497},{"author":"呈铭","categories":"SOFAStack","content":" 王程铭（呈铭）\n蚂蚁集团技术工程师，Apache Committer\n专注 RPC、Service Mesh 和云原生等领域。\n本文 7368 字，预计阅读 15 分钟\n前言 MOSN（Modular Open Smart Network）是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并经过了双十一大促几十万容器的生产级验证。\nMOSN 为服务提供多协议、模块化、智能化、安全的代理能力，融合了大量云原生通用组件，同时也可以集成 Envoy 作为网络库，具备高性能、易扩展的特点。MOSN 可以和 Istio 集成构建 Service Mesh，也可以作为独立的四、七层负载均衡，API Gateway、云原生 Ingress 等使用。\nMOSN 作为数据面，整体由 NET/IO、Protocol、Stream、Proxy 四个层次组成，其中：\n NET/IO 用于底层的字节流传输\n Protocol 用于协议的 decode/encode\n Stream 用于封装请求和响应，在一个 conn 上做连接复用\n Proxy 做 downstream 和 upstream 之间 stream 的转发\n 那么 MOSN 是如何工作的呢？下图展示的是使用 Sidecar 方式部署运行 MOSN 的示意图，服务和 MOSN 分别部署在同机部署的 Pod 上， 您可以在配置文件中设置 MOSN 的上游和下游协议，协议可以在 HTTP、HTTP2.0 以及 SOFARPC 等中选择。\n以上内容来自官网 https://mosn.io\nRPC 场景下 MOSN 的工作机制 RPC 场景下，MOSN 的工作机制示意图如下：\n我们简单理解一下上面这张图的意义：\n Server 端 MOSN 会将自身 ingress 的协议端口写入到注册中心；\n Client 端 MOSN 会从注册中心订阅地址列表，第一次订阅也会返回全量地址列表，端口号是 Server 端 ingress 绑定的端口号；\n 注册中心会实时推送地址列表变更到 Client 端（全量）；\n Client 端发起 rpc 调用时，请求会被 SDK 打到本地 Client 端 MOSN 的 egress 端口上；\n Client 端 MOSN 将 RPC 请求通过网络转发，将流量通过负载均衡转发到某一台 Server 端 MOSN 的 ingress 端口处理；\n 最终到了 Server 端 ingress listener，会转发给本地 Server 应用；\n 最终会根据原来的 TCP 链路返回。\n 全局视野下的 MOSN 工作流程 现在我们已经了解了 MOSN 的工作机制，那么 MOSN 作为 MESH 的数据面，是怎么进行流量拦截并且将响应原路返回的呢？\n为了方便大家理解，我将以上时序图内容进行拆分，我们一一攻破。\n3.1 建立连接 MOSN 在启动期间，会暴露本地 egress 端口接收 Client 的请求。MOSN 会开启 2 个协程，分别死循环去对 TCP 进行读取和写处理。MOSN 会通过读协程获取到请求字节流，进入 MOSN 的协议层处理。\n// 代码路径 mosn.io/mosn/pkg/network/connection.go func (c *connection) Start(lctx context.Context) { // udp downstream connection do not use read/write loop if c.network == \u0026amp;quot;udp\u0026amp;quot; \u0026amp;amp;\u0026amp;amp; c.rawConnection.RemoteAddr() == nil { return } c.startOnce.Do(func() { // UseNetpollMode = false if UseNetpollMode { c.attachEventLoop(lctx) } else { // 启动读/写循环 c.startRWLoop(lctx) } }) } func (c *connection) startRWLoop(lctx context.Context) { // 标记读循环已经启动 c.internalLoopStarted = true utils.GoWithRecover(func() { // 开始读操作 c.startReadLoop() }, func(r interface{}) { c.Close(api.NoFlush, api.LocalClose) }) // 省略。。。 } 3.2 Protocol 处理 Protocol 作为多协议引擎层，对数据包进行检测，并使用对应协议做 decode/encode 处理。MOSN 会循环解码，一旦收到完整的报文就会创建与其关联的 xstream，用于保持 tcp 连接用于后续响应。\n// 代码路径 mosn.io/mosn/pkg/stream/xprotocol/conn.go func (sc *streamConn) Dispatch(buf types.IoBuffer) { // decode frames for { // 协议 decode，比如 dubbo、bolt 协议等 frame, err := sc.protocol.Decode(streamCtx, buf) if frame != nil { // 创建和请求 frame 关联的 xstream，用于保持 tcp 连接用于后续响应 sc.handleFrame(streamCtx, xframe) } } } func (sc *streamConn) handleFrame(ctx context.Context, frame api.XFrame) { switch frame.GetStreamType() { case api.Request: // 创建和请求 frame 关联的 xstream，用于保持 tcp 连接用于后续响应，之后进入 proxy 层 sc.handleRequest(ctx, frame, false) } } func (sc *streamConn) handleRequest(ctx context.Context, frame api.XFrame, oneway bool) { // 创建和请求 frame 关联的 xstream serverStream := sc.newServerStream(ctx, frame) // 进入 proxy 层并创建 downstream serverStream.receiver = sc.serverCallbacks.NewStreamDetect(serverStream.ctx, sender, span) serverStream.receiver.OnReceive(serverStream.ctx, frame.GetHeader(), frame.GetData(), nil) } 3.3 Proxy …","date":1711436400,"description":"从一次 RPC 请求，探索 MOSN 的工作流程","dir":"blog/explore-the-workflow-of-mosn-from-an-rpc-request/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9993f1cea8de40427d6ef6d8345f9d0c","permalink":"https://sofastack.github.io/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","publishdate":"2024-03-26T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","summary":"王程铭（呈铭） 蚂蚁集团技术工程师，Apache Committer 专注 RPC、Service Mesh 和云原生等领域。 本文 7368 字，预计阅读 15 分钟 前言 MOSN（Modul","tags":["SOFAStack"],"title":"从一次 RPC 请求，探索 MOSN 的工作流程","type":"blog","url":"/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/","wordcount":2760},{"author":null,"categories":"SOFAStack","content":" 梁栎鹏（立蓬）\n蚂蚁集团技术工程师,云原生领域工程师\n就职于蚂蚁集团中间件团队，参与维护与建设蚂蚁 SOFAArk 和 Koupleless 开源项目，参与内部 SOFAServerless 产品的研发和实践。\n本文 4603 字，预计阅读 10 分钟\nbackground-你的企业应用协作效率低吗？ 明明只改一行，但代码编译加部署要十分钟？\n多人开发一套代码库，调试却频频遇到资源抢占和相互覆盖，需求上线也因此相互等待？\n当项目代码逐渐膨胀，业务逐渐发展，代码耦合、发布耦合以及资源耦合的问题日益加重，开发效率一降再降。\n如何解决？来试试把单个 Spring Boot 应用拆分为多个 Spring Boot 应用吧！拆出后，多个 Spring Boot 应用并行开发，互不干扰。在 Koupleless 模式下，业务可以将 Spring Boot 应用拆分成一个基座和多个 Koupleless 模块（Koupleless 模块也是 Spring Boot 应用）。\n🙌拉到「Koupleless 拆分插件解决方案」部分，可直接查看单体应用拆分的插件演示视频！\n关键挑战 从单个 Spring Boot 应用拆出多个 Spring Boot 应用有三大关键挑战：\n一是拆子应用前，复杂单体应用中代码耦合高、依赖关系复杂、项目结构复杂，难以分析各文件间的耦合性，更难从中拆出子应用，因此需要解决拆分前复杂单体应用中的文件依赖分析问题。\n二是拆子应用时，拆出操作繁琐、耗时长、用户需要一边分析依赖关系、一边拆出，对用户要求极高，因此需要降低拆分时用户交互成本。\n三是拆子应用后，单体应用演进为多应用共存，其编码模式会发生改变。Bean 调用方式由单应用调用演进为跨应用调用，特殊的多应用编码模式也需根据框架文档调整，比如在 Koupleless 中，为了减少模块的数据源连接，模块会按照某种方式使用基座的数据源，其学习成本与调整成本极高，因此需要解决拆分后多应用编码模式演进问题。\nKoupleless 拆分插件解决方案 针对以上三大关键挑战，Koupleless IntelliJ IDEA 插件将解决方案分为 3 个部分：分析、交互和自动化拆出，提供依赖分析、友好交互和自动化拆出能力，如下图：\n在分析中，分析项目中的依赖关系，包括类依赖和 Bean 依赖分析，解决拆分前复杂单体应用中的文件依赖分析问题；\n在交互中，可视化类文件之间的依赖关系，帮助用户梳理关系。同时，可视化模块目录结构，让用户以拖拽的方式决定要拆分的模块文件，降低拆分时的用户交互成本；\n在自动化拆出中，插件将构建模块，并根据特殊的多应用编码修改代码，解决拆分后多应用编码模式演进问题。\n🙌 Koupleless 半自动拆分演示视频，带你更直观了解插件如何在分析、交互、自动化拆出中提供帮助。\n一个示例，秒懂 Koupleless 解决方案优势 假设某业务需要将与 system 相关的代码都拆出到模块，让通用能力保留在基座。这里我们以 system 的入口服务 QuartzJobController 为例。\n步骤一：分析项目文件依赖关系 首先，我们会分析 QuartzJobController 依赖了哪些类和 Bean。\n 方式一：使用 Idea 专业版，对 Controller 做 Bean 分析和类分析，得到以下 Bean 依赖图和类依赖关系图 优势：借助 IDEA 专业版，分析全面\n劣势：需要对每个类文件都做一次分析，Bean 依赖图可读性不强。\n 方式二：凭借脑力分析 当 A 类依赖了B、C、D、\u0026amp;hellip;、N类，在拆出时需要分析每一个类有没有被其它类依赖，能不能够拆出到模块应用。\n优势：直观\n劣势：当 A 的依赖类众多，需要层层脑力递归。\n 方式三：使用 Koupleless 辅助工具，轻松分析！ 选择你想要分析的任意类文件，点击“分析依赖”，插件帮你分析～ 不仅帮你分析类文件依赖的类和 Bean，还提示你哪些类可以拆出，哪些类不能拆出。\n以 QuartzJobController 为例，当选定的模块中有 QuartzJobController, QuartzJobService 和 QuartzJobServiceImpl 时，QuartzJobController 依赖的类和 Bean 关系如下图所示：\nQuartzJobController 的依赖类/Bean 分为四类：已在模块、可移入模块、建议分析被依赖关系和不建议移入模块：\n 如果在模块中，则被标记为绿色“已在模块”，如：QuartzJobService 和 QuartzJobServiceImpl；\n 如果只被模块类依赖，那么被标记为蓝色“可移入模块”，如 JobQueryCriteria；\n 如果只被一个非模块类依赖，那么被标记为黄色“建议分析被依赖关系”，如 QuartLog；\n 如果被大量非模块类依赖，那么被标记为红色“不建议移入模块”，如 BadRequestException。\n 当使用插件对 QuartzJobController 和 JobQueryCriteria 进行分析时，依赖树和被依赖树如下，与上述分析对应：\n优势：直观、操作便捷、提示友好\n劣势：插件只支持分析常见的 Bean 定义和类引用\n步骤二：拆出到模块\u0026amp;amp;修改单应用编码为多应用编码模式\n选择相关的类文件拆出到模块。\n 方式一：复制粘贴每个文件、脑力分析所有模块基座之间的 Bean 调用、根据多应用编码模式修改代码。 在拆出时不可避免会面临这些问题：刚拆到哪儿了？这文件在没在模块里？我要不要重构这些包名？Bean 调用跨应用吗？多应用编码的文档在哪？\n优势：可以处理插件无法处理的多应用编码模式\n劣势：用户不仅需要分析跨应用 Bean 依赖关系，还需要学习多应用编码方式，人工成本较高。\n 方式二：使用 Koupleless 辅助工具，轻松拆出！ 根据你想要的模块目录结构，拖拽需要拆出的文件至面板。点击“拆出”，插件帮你分析，帮你根据 Koupleless 多应用编码模式修改～\n优势：直观、交互方便、插件自动修改跨应用 Bean 调用方式和部分特殊的多应用编码模式\n劣势：插件只能根据部分多应用编码模式修改代码，因此用户需要了解插件能力的范围\n技术方案 在上文中我们已经知道，插件将整体流程分为 3 个阶段：分析阶段、交互阶段和自动化拆出阶段，整体流程如下图所示：\n 在分析阶段中，分析项目中的依赖关系，包括类依赖、Bean 依赖和特殊的多应用编码分析，如：MyBatis 配置依赖；\n 在交互阶段，可视化类文件之间的依赖关系和模块目录结构；\n 在自动化拆出阶段，插件首先将构建模块并整合配置，然后根据用户需要重构包名，接着修改模块基座 Bean 调用方式，并根据特殊的多应用编码修改代码，如：自动复用基座数据源。\n 接下来，我们将分别简单介绍分析阶段、交互阶段和自动化拆出阶段中用到的主要技术。\n分析阶段 插件分别使用 JavaParser 和 commons-configuration2 扫描项目中的 Java 文件和配置文件。\n类依赖分析 为了准确地分析出项目的类依赖关系，插件需要完整分 …","date":1710831600,"description":"单体应用协作开发太难？Koupleless 带来拆分插件，帮你抽丝剥茧提高协作开发效率！","dir":"blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"31cd46eb078e59933c6f2c5cf7b32bc8","permalink":"https://sofastack.github.io/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","publishdate":"2024-03-19T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","summary":"梁栎鹏（立蓬） 蚂蚁集团技术工程师,云原生领域工程师 就职于蚂蚁集团中间件团队，参与维护与建设蚂蚁 SOFAArk 和 Koupleless 开源项目，参与内部 SOFAServerless 产品的研发和实践。 本","tags":["SOFAStack"],"title":"单体应用协作开发太难？Koupleless 带来拆分插件，帮你抽丝剥茧提高协作开发效率！","type":"blog","url":"/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/","wordcount":3944},{"author":null,"categories":"SOFAStack","content":" 文｜祁晓波\n南京爱福路汽车科技基础设施负责人\n主要研究微服务、可观测、稳定性、研发效能、Java 中间件等领域。\n本文 4812 字 阅读 12 分钟\nKoupleless *（原 SOFAServerless）* 自 2023 年开源以来已经落地了若干企业，这些企业也见证了从 SOFAServerless 到 Koupleless 的品牌\u0026amp;amp;技术能力迭代升级。随着 Koupleless 1.0 的重磅发布，一些企业已经在内部取得了不错的效果，例如南京爱福路汽车科技有限公司。\n南京爱福路汽车科技有限公司和大多数科技企业一样，在企业生产开发过程遇到了微服务的一些问题，例如资源成本过高、启动慢等问题。在看到 Koupleless 项目正不断开源出实实在在的能力和案例，在解决很实际的微服务痛点问题，决定采用 Koupleless 进行尝试，并随着 Koupleless 一路走来，已经将 6 个应用合并成 1 个应用大幅降低资源成本，取得了不错的效果。\n1｜背景 南京爱福路汽车科技有限公司 *（以下简称爱福路）* 作为行业 top 的汽车后市场解决方案提供商，为维修门店提供智慧管理系统、为行业提供维修应用大数据，致力于成为汽车后市场数智化构建者。\n随着其服务的企业增多，爱福路也越来越多地接触到了各类体量的企业。\n这就对爱福路的服务提供形式提出了较多不同的诉求： 除了单纯的公有云 SAAS 之外，还包括私有化部署等解决方案的诉求。\n2｜问题提出 我们知道，随着微服务和云原生技术的普及，应用数量急剧膨胀。\n如此多的应用也带来了比较大的成本问题。\n爱福路在为海量公域客户提供服务的时候，更关注稳定、弹性。\n但是在为某个客户提供独立部署方案时，爱福路发现如此多的服务在部署到 K8s 时所带来的服务器成本非常高 *（通常来说，独立部署服务面向的客户群体比之公域客户少了 1-2 个数量级）*，而单个客户也很难有足够的预算负担整个部署方案。这就大大阻塞了爱福路后续持续拓展私有化部署客户的进度。\n举个例子：一个应用在进行 K8s 交付时，最少会提供两个副本；而大量这样的 Java 应用存在对于整体的集群利用率不高，继而造成较高的成本。\n因此爱福路面临着如下的课题： 当进行私有化交付时，如何能够更便捷地、低成本地交付我们现有的产物？\n其中，低成本至少应该包含如下几个角度：\n 既存代码的低成本改造； 新的交付方式低成本的维护； 运行产物低成本的 IT 成本。 3｜问题探索和推导 爱福路基于当前的微服务架构和云原生方式进行了思考和探索： 是否到了爱福路微服务架构进一步升级的时候了？\n在当前整体降本增效的大环境趋势中，在保持服务稳定的前提下对于服务器有更加极致的使用。\n从业务视角来看，服务单店的整体服务器成本越低，爱福路的竞争力就越强。\n那么，有没有可能在保持 Java 的生态环境下，低成本的同时能够保证爱福路继续享受云原生的红利？爱福路做了如下推导：\n通过上述的推导，爱福路判断也许「模块化+Serverless」将是一种解法。\n因此一款来自蚂蚁的开源框架成为他们重点的关注，那就是 Koupleless。（阅读原文可跳转官网地址：https://koupleless.io/user-cases/ant-group/）\n当然一个重要原因是蚂蚁开源一直做得不错，社区也比较活跃。除了社区群和 GitHub 之外，PMC 有济也积极地建立了独享的 VIP 群进行专门对接。\n4｜Koupleless（原 SOFAServerless） Koupleless 技术体系是在业务发展、研发运维的复杂性和成本不断增加的情况下，蚂蚁集团为帮助应用又快又稳地迭代而决定研发，从细化研发运维粒度和屏蔽基础设施的角度出发，演进出的一套低成本接入的「模块化+Serverless」解决方案。\n核心方式是通过类隔离和热部署技术，将应用从代码结构和开发者阵型拆分为两个层次：业务模块和基座，基座为业务模块提供计算环境并屏蔽基础设施，模块开发者不感知机器、容量、中间件等基础设施，专注于业务研发帮助业务快速向前发展。\n合并部署降成本 在企业中， “80%” 的长尾应用仅服务 “20%” 的流量，蚂蚁集团也不例外。\n在蚂蚁集团存在大量长尾应用，每个长尾应用至少需要 预发布、灰度、生产 3 个环境，每个环境最少需要部署 3 个机房，每个机房又必须保持 2 台机器高可用，因此大量长尾应用 CPU 使用率不足 10%。\n通过使用 Koupleless，蚂蚁集团对长尾应用进行了服务器裁撤，借助类委托隔离、资源监控、日志监控等技术，在保证稳定性的前提下，实现了多应用的合并部署，极大降低了业务的运维成本和资源成本。\n此外，采用这种模式，小应用可以不走应用申请上线流程，也不需要申请机器，可以直接部署到业务通用基座之上，从而帮助小流量业务实现了快速创新。\n2023 年底 SOFAServerless 品牌全新升级为 Koupleless（GitHub页面：https://github.com/koupleless/koupleless）。\n企业里不同业务有不同的发展阶段，因此应用也拥有自己的生命周期。\n  * 初创期：一个初创的应用一般会先采用单体架构。 * 增长期：随着业务增长，应用开发者也随之增加。此时您可能不确定业务的未来前景，也不希望过早把业务拆分成多个应用以避免不必要的维护、治理和资源成本，那么您可以用 Koupleless 低成本地将应用拆分为一个基座和多个功能模块，不同功能模块之间可以并行研发运维独立迭代，从而提高应用在此阶段的研发协作和需求交付效率。 * 成熟期：随着业务进一步增长，您可以使用 Koupleless 低成本地将部分或全部功能模块拆分成独立应用去研发运维。 * 长尾期：部分业务在经历增长期或者成熟期后，也可能慢慢步入到低活状态或者长尾状态，此时您可以用 Koupleless 低成本地将这些应用一键改回模块，合并部署到一起实现降本增效。\n 应用生命周期演进\n可以看到 Koupleless 主要通过将应用模块化来降低整个服务的运行成本，更值得称道的是支持模块和应用的来回切换，可以更低成本地接入，支持平滑演进。\n5｜架构适配尝试 Spring Boot 1「可行性确认」 爱福路的存量应用中，九成使用的是 Spring Boot 1，RPC 主要依赖 Dubbo 2.6。这点和社区是有一定出入的，社区仅仅支持 SpringBoot 2。\n为此爱福路需要尝试对于 Spring Boot 1 的支持，也因此提出了相应的 issue👇\nhttps://github.com/sofastack/sofa-ark/issues/268\n通过和社区沟通协调确认，爱福路发现只是社区没能够完全覆盖到这块，企业自身可以通过部分扩展进行支持。\n当时社区同学认为这个是比较重要的变更，可以进一步覆盖更多的社区用户，为此还特地调整了中央仓库的发版频次：加速 review、加速发 snapshot。\n正是这些细节让爱福路更加信任 Koupleless 团队👍，也坚定了此次方案能够实际落地的信心。\n应用合并 当 Spring Boot 1 得到支持之后，爱福路可以快速地将原来的 …","date":1709017200,"description":"高效降本｜深度案例解读 Koupleless 在南京爱福路的落地实践","dir":"blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0c6483ccd63328d158a35bc8b5b81940","permalink":"https://sofastack.github.io/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","publishdate":"2024-02-27T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","summary":"文｜祁晓波 南京爱福路汽车科技基础设施负责人 主要研究微服务、可观测、稳定性、研发效能、Java 中间件等领域。 本文 4812 字 阅读 12 分钟 Koupleless *（原 SOFA","tags":["SOFAStack"],"title":"高效降本｜深度案例解读 Koupleless 在南京爱福路的落地实践","type":"blog","url":"/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/","wordcount":3555},{"author":null,"categories":"SOFAStack","content":" 如果你是企业经营者，在为企业降本增效而发愁； 如果你是企业的开发、运维或架构同学，在日常工作中被开发效率、交付问题等困扰…… 欢迎来了解 Koupleless *（原 SOFAServerless）*！\n现在，Koupleless 重磅发布了1.0 版本！（👈点击查看 release note）\n那么，Koupleless 是什么？又将如何为你解决以上问题？除了以上这几种情境，Koupleless 还有哪些能力呢？欢迎你来社区探索发现。\nKoupleless 是什么？ Koupleless 由 SOFAServerless 品牌升级而来，是一款模块化研发框架与运维调度平台。它从应用架构角度出发，帮助应用解决从需求、到研发、到交付再到运维的全生命周期痛点问题。其最核心的架构图如下👇。如果想了解更详细的原理介绍也可以查看官网页面：https://koupleless.gitee.io/docs/introduction/architecture/arch-principle/。\n它能帮助解决的问题包括：\n 应用拆分过度，机器成本和长期维护成本高； 应用拆分不够，多人协作互相阻塞； 应用构建、启动与部署耗时久，应用迭代效率不高； SDK 版本碎片化严重，升级成本高周期长； 平台、中台搭建成本高，业务资产沉淀与架构约束困难； 微服务链路过长，调用性能不高； 微服务拆分、演进成本高； 如果你也被以上问题所困扰，那么欢迎来了解 Koupleless 给出的解决方案。 本模式在蚂蚁集团内部历经 4-5 年时间孵化而成，当前已经帮助 70W 核业务量完成 10 倍级降本增效，可以帮助应用做到秒级启动，只占 20M 内存。\n性能对比示例如下图👇。\n根据我们的模块化应用架构模型，可以看到我们是将传统应用从纵向和横向切分演变而来的。\n所以我们将 SOFAServerless 进行品牌升级成为 Koupleless，取自 Couple + less，寓意通过对应用进行拆分解耦，实现更好的职责分工，帮助业务降本增效。\n我们为什么开源？ 关注应用架构领域的同学，应该知道微服务很好地解决了组织分布式协作难题，但同时也带来了一些问题，并且这些问题正日益获得更多关注。 有人说，2023 年是微服务的转折年[1]，其中一些科技巨头*（如 Amazon 和 Google ）*已经开始尝试去解决和完善微服务带来的问题，例如 service weaver[2]，amazon prime video[3]的架构改造，甚至直接回归单体。\n而蚂蚁内部在 4-5 年前就开始着手解决微服务问题，并为此打造了 Koupleless 应用研发模式。 根据蚂蚁这些年的实践经验，我们相信模块化架构是一种有潜力的架构，真正能够较好地解决微服务问题；我们也希望通过模块化架构给行业内部提供一种新的解决方案，帮助更多企业降本增效。\n开源提供了哪些能力？ 自 2023 年下半年开源以来，经过这半年时间和社区的共同努力，我们已经开放了内部完整的能力，包括研发工具、框架、运维调度平台等；也沉淀了一些常用组件最佳实践和 samples 用例（具体查看 release note：https://github.com/koupleless/koupleless/releases/tag/v1.0.0）。 具备了线上接入使用的能力，一些企业也已经可以按照官网和文档自主接入使用了。\n 研发工具 Arkctl一键构建、部署和发布模块，方便用于本地开发测试验证。 Arklet、SOFAArk 和 Runtime 组件为多种研发框架如 Spring Boot、SOFABoot、Dubbo 提供多模块运行容器环境，适配 30+ 组件，沉淀 25+ samples 用例。 控制面组件 ModuleControllerModuleDeployment，提供模块发布与运维能力； ModuleScheduler，提供模块基础调度能力； ModuleScaler，提供模块扩缩容能力。 有了这些组件之后，从开发验证 -\u0026amp;gt; 交付上线 -\u0026amp;gt; 日常运维全流程的基本能力已经具备，1.0 版本实现生产可用级别。\n挑战与亮点 这套模式最大的挑战来自于将多个应用或代码片段合并在一起，在隔离与共享上如何找到最佳的平衡点，使得在存量应用低成本接入的同时，能享受到隔离的带来稳定可靠的好处，也能享受到共享的高性能、低资源消耗的收益。\n隔离可以确保运行时的稳定可靠，但带来了性能的下降、资源利用率的损失；共享提升了性能和资源利用率，但也带来了运行时的一些问题，例如 static 变量可能带来互相影响的问题。我们采用了模块化技术来解决这类问题。在 Java 领域模块化技术并不是我们首创的，20 年前就有了 OSGl 技术，那为什么我们的模块化技术能在蚂蚁内部规模化落地呢？我们是做了哪些工作来解决存量应用低成本接入和共享后的一些问题的呢？\n要解决这类问题，我们并没有太多可参考的行业案例，相当于是在无人区里摸索，除了解决隔离与共享的核心问题外，还要解决配套设施的建设、用户心智的培养等，这些都需要一个笃定的心力和持续的过程，这些问题就是这套模式的挑战所在。 好在最终，我们拨云见日探索了出来。我们在隔离和共享之间找到了一个最佳的平衡点，并且能让存量业务低成本的接入，这也是我们最自豪的地方。我们在蚂蚁集团用事实证明了模块化技术并不是停留在设计稿里的技术，或者小部分人才能使用的技术，它的问题和挑战并不可怕，是有固定模式的，可以通过工具和流程逐步治理、收敛的，现在将此模式进行开源分享，是希望可以帮助其他企业少走弯路，和社区一起把这套模式心智在行业里树立起来。\nKoupleless 已接入 15+ 企业 当前在统计内的，有 15+ 企业在使用 Koupleless 接入线上或者用于交付，还有 17+ 企业正在试用或者接入中，还有一些因为信息缺失未统计到的。详细企业接入列表可以查看官网信息[4]。 很高兴 Koupleless 能帮助到他们，也十分欢迎这些企业探索的更多使用场景，也欢迎更多企业开发者一起参与社区建设，推广这套技术。\nKoupleless 未来的规划 我们希望能让模块化架构成为应用架构领域里的新模式，并能在行业里推广开来。这不仅是我们作为技术人的技术追求，也是我们做开源的持续动力来源。 当前我们虽然发布了 1.0 版本，但开源工作才只是刚刚开始，还有更多规划。比如，我们希望未来能把模块化技术做得更加完善，将我们想要做到的效果完整地提供出来：\nSpeed as you need, Pay as you need， Deploy as you need， Evolve as you need 。 需要的能力包括支持各种框架、运行时组件、中间件服务，还有非常多相关的配套设施；也希望这套模式能在更多语言里发挥出效果，例如 Go 语言，以此和更多的小伙伴们一起探索出微服务领域的下一站。\n这里感谢所有参与贡献 Koupleless 1.0 的 51 位开发者： @QilingZhang @lvjing2 @glmapper @yuanyuancin @lylingzhen @yuanyuan2021 …","date":1707202800,"description":"成倍降本增效，提升企业竞争力！SOFAServerless 品牌升级为 Koupleless，重磅发布 1.0 版本","dir":"blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bf0d878bbdb545204ab25a89a7c592ac","permalink":"https://sofastack.github.io/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","publishdate":"2024-02-06T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","summary":"如果你是企业经营者，在为企业降本增效而发愁； 如果你是企业的开发、运维或架构同学，在日常工作中被开发效率、交付问题等困扰…… 欢迎来了解 Koupleless *（原","tags":["SOFAStack"],"title":"成倍降本增效，提升企业竞争力！SOFAServerless 品牌升级为 Koupleless，重磅发布 1.0 版本","type":"blog","url":"/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/","wordcount":2620},{"author":null,"categories":"SOFAStack","content":" 今天 SOFAStack 邀请到了开源之夏 2023 Layotto 社区的中选学生陈亦昺同学！在本项目中，他负责可插拔式组件的开发。希望他分享的这段经历，能让更多人了解到 Layotto 开源社区，感受开源的魅力～\n项目链接：https://summer-ospp.ac.cn/org/prodetail/23f080194?list=org\u0026amp;amp;navpage=org\n项目名称 Layotto support pluggable components\n项目导师 王文学\n项目背景描述 Layotto 是一款基于云原生的应用运行时，旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，比如状态管理、配置管理、事件发布订阅等能力，以简化应用的开发。同时，它以 MOSN 项目为底座，在提供分布式能力以外，还提供了 Service Mesh 的流量管控能力。\nLayotto 对用户程序暴露 API，用户程序可以通过 API 调度对应的运行时服务。例如 Layotto 支持 config 服务，其内部会使用含有各种 component (如 Nacos，Apollo，Etcd 等) 的 SDK 来提供 config API 能力。\n当前 Layotto 的 component 都是实现在 Layotto 的工程里面的。这也就使得用户在想要使用新的 component 时，必须使用 Golang 语言开发，同时必须在 Layotto 工程中实现，再进行统一编译。这种体验对于多语言用户来说非常不友好。\n因此 Layotto 需要提供 pluggable components 的能力，允许用户通过任何语言实现自己的 component，而 Layotto 则通过 gRPC 协议和外部的 component 进行通信。\n项目实现思路 方案 基于 UDS（Unix Domain Socket）实现本地跨语言组件服务发现，降低通信开销。\n 基于 proto 实现组件跨语言实现能力。\n 数据流架构 组件发现 如上图所示，用户自定义组件启动 socket 服务，并将 socket 文件放到指定目录中。Layotto 启动时，会读取该目录中的所有 socket 文件（跳过文件夹），并建立 socket 连接。\n目前，Layotto 向 Dapr 对齐，不负责用户组件的生命周期。这就意味着在服务期间，用户组件下线后不会进行重连，则该组件服务无法使用。后面会根据社区使用情况，来决定 Layotto 是否需要支持进程管理模块，或是使用一个单独的服务来管理。\n由于 Windows 对于 UDS 的支持还不是很完善，且 Layotto 本身取消了对 Windows 的兼容，所以新特性采用的 UDS 发现模式未对 Windows 系统做兼容。\n组件注册 如上面的数据流架构图所示，用户注册的组件需要实现 pluggable proto 定义的 gRPC 服务。Layotto 会根据 gRPC 接口，实现 Go interface 接口，这里对应于数据流图中的 wrapper component。wrapper component 与 built-in component 对 Layotto Runtime 来说没有任何区别，用户也不会有特殊的感知。\nLayotto 通过 gRPC reflect 库，获取到用户提供服务实现了哪些组件，然后注册到全局的组件注册中心，以供用户使用。\n开源之夏个人随访 自我介绍 大家好，我是陈亦昺，目前就读于杭州电子科技大学，大三学生。自从大二开始，我对开源产生了浓厚的兴趣，特别是在云原生和微服务领域。\n起初，我主要为我个人感兴趣的项目提供使用案例和文档支持，随后逐渐开始贡献一些简单的功能。例如，我为 Kratos 贡献了一个简单的 toml 配置文件解析器，并向 go-zero 提供了一些建议，改进了它的优雅关闭（Graceful Shutdown）功能。\n之后，我接触到了服务网格领域，认识了 MOSN 社区，并开始为其中的子项目 Layotto 做开源贡献：我修复了一些 makefile 脚本使用中的 bug、编写了 Go SDK 的使用文档、并尝试对 Nacos 组件进行封装。\n申请本社区项目的原因 SOFAStack 是一个金融级的云原生架构，内部孵化了许多吸引我的微服务项目。接触 SOFAStack 社区以来，我发现他们对开源贡献十分重视，仓库中有丰富的文档来帮助用户了解项目的背景、功能、代码模块等。\n👉SOFAStack 仓库地址：https://github.com/sofastack\nMOSN 项目也组织过源码阅读活动，将 MOSN 核心组件的代码设计整理成文档；仓库所有者也会为新人提供适合入手的 issue 作为开始。所以在 OSPP 活动开始之前，我其实就先认识了 SOFAStack 社区，并对其新兴项目 Layotto 做了一定的贡献。OSPP 开始后，我很快与导师取得联系，并得知可以参考 Layotto 对标项目 Dapr 的设计实现。于是，我翻阅了 Dapr 的相关文档、该功能实现时的 issues，阅读了该块功能的源码，最终得出适合移植到 Layotto 的方案。\n如何克服项目过程中的困难与挑战？ 在项目开发的初期阶段，导师会引导我了解项目的愿景、业务背景和代码结构；当我在开发过程中遇到困难时，导师为我提供了很多实质性的建议和改进方向；此外，社区每周三定期举行社区会议，让我们可以同步项目开发进度、讨论遇到的问题，共同寻求解决方案。\n在开发过程中我其实遇到了不少问题，其中一个让我印象深刻的是 Go 依赖冲突问题。早期，Layotto 参考了 Dapr 的一些组件接口设计，并直接引入了 Dapr 仓库的代码，这样直接复用了 Dapr 组件的功能，也避免了重复劳动。但是早期的 Dapr 并没有实现可插拔组件的功能，为了让新功能与 Dapr 组件保持兼容，我必须将 Dapr 升级到能够实现该功能的版本。\n然而，这两个版本之间存在许多不兼容的变化（尽管对外提供的服务接口并没有改变），所以一旦我升级了依赖，Layotto 就会出现大量错误。最终在与导师的沟通中，我们一致认为这部分兼容性工作的收益不大，只需实现新的接口供用户使用即可。\n你眼中的社区印象 SOFAStack 是一个充满开源精神的、热情的社区，欢迎并鼓励学生和开源爱好者积极参与其中。同时，SOFAStack 社区也是专业的，它专注于云原生和金融领域的技术创新和解决方案，旨在帮助开发者快速构建和管理云原生应用，提高应用的可伸缩性、弹性以及可靠性。\n一些收获 参加这次开源之夏项目使我获益匪浅。我对云原生有了进一步的深刻理解，并在实际业务操作中积累了宝贵的经验。同时，参加这个活动还扩展了我的知识技能，激发了我对开源项目做出贡献的热情。\n通过与导师和社区的合作，我学会了如何与其他开发者协作、如何提出和解决问题，并且还掌握了使用开源工具和资源的技巧。通过阅读 Layotto 和 Dapr 的源代码，我掌握了许多关于程序设计的经验，例如编写可测试的代码、命名规范、如何构建单元测试用例等等。这 …","date":1700550000,"description":"开源之夏经验分享｜Layotto 社区 陈亦昺：保持热情、全力以赴！","dir":"blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e50c0aaf2bd1fc9a639cb47390aa1839","permalink":"https://sofastack.github.io/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","publishdate":"2023-11-21T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","summary":"今天 SOFAStack 邀请到了开源之夏 2023 Layotto 社区的中选学生陈亦昺同学！在本项目中，他负责可插拔式组件的开发。希望他分享的这段经历，能让更多人了解到 Layotto 开源社区，","tags":["SOFAStack"],"title":"开源之夏经验分享｜Layotto 社区 陈亦昺：保持热情、全力以赴！","type":"blog","url":"/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/","wordcount":2488},{"author":null,"categories":"SOFAStack","content":" 北京时间 2023 年 10 月 29 日，分布式事务开源项目 Seata 通过 Apache 基金会的投票决议，以全票通过的优秀表现正式成为 Apache 孵化器项目！\n根据 Apache基金会邮件列表显示，包含 13 个约束性投票（binding votes）和 6 个无约束性投票（non-binding votes）的投票全部持赞同意见，无弃权票和反对票，投票顺利通过。\n“Welcome Seata to the ASF incubator.”\n项目历史 早在 2007 年\n蚂蚁集团和阿里巴巴就在内部开发了分布式事务中间件，用于解决电商、支付、物流等业务场景中应用数据的一致性问题。内部项目分别被称为 XTS（eXtended Transaction Service）/TXC（Taobao Transaction Constructor），该项目几乎在每笔订单的交易支付链路几乎都有使用。\n自 2013 年以来\n蚂蚁集团在金融云上向企业客户发布了分布式事务云服务产品 DTX（Distributed Transaction-eXtended），阿里巴巴在阿里云上发布 GTS（global transaction service），两者均在各个行业领域积累了大量用户。\n2019 年 1 月\n阿里巴巴集团正式开源了该项目，项目命名为 Fescar（Fast \u0026amp;amp; Easy Commit and Rollback）。项目开源以来，它受到了众多开发人员的热烈欢迎和赞扬，开源一周收获了超 3k star，曾一度蝉联 GitHub Trending 排行榜第一。\n2019 年 4 月\n蚂蚁集团数据中间件团队加入了 Fescar 社区。为了创建一个更加开放和中立的社区，Fescar 改名为 Seata（Simple Extensible Autonomous Transaction Architecture），代码仓库从 Alibaba organization 迁移到其独立的 Seata organization。\n2019 年 12 月\nSeata 开源项目正式发布 1.0.0 GA 版本，标志着项目已基本可生产使用。\n2023 年 10 月\n为了更好地通过社区驱动技术的演进，蚂蚁集团和阿里巴巴携手，正式将 Seata 捐赠给 Apache 基金会，提案通过了 Apache 基金会的投票决议。\n项目现状 Seata 开源 4 年来，主项目在 GitHub 累计收获 star 超 24k，累计发布版本超 40 次，参与代码贡献人数超 300 人。\n Seata 被各领域企业/组织广泛应用于解决分布式事务问题，在 GitHub「Used by」拥有超过 3.1k 的仓库依赖，金融领域企业纷纷试点使用。\n Seata 对于市面上主流的关系数据库、RPC 框架做了广泛的支持，同时被许多第三方社区做了主动和被动集成。\n 项目特性 提供 AT、TCC、Saga 和 XA 事务模式，支持事务模式的混用，以满足不同业务场景的数据一致性需求。\n 提供 Java、Golang 等多语言 SDK 支持。\n 支持了 Apache Dubbo、Spring Cloud Alibaba、gRPC、Motan、SOFARPC、HttpClient 等服务调用框架。\n 提供了 MySQL、MariaDB、Oracle、PostgreSQL、OceanBase、TiDB、SQLServer、PolarDB、Dameng 等关系数据库无侵入 AT 事务模式的支持。\n 支持基于多种关系数据库、Redis 存储的存算分离的集群模式，支持基于 Raft 的存算不分离集群模式，满足不同运维场景下的集群高可用需求。\n 支持了市面上主流的注册中心和配置中心。\n 提供了丰富的插件化扩展机制，支持用户自定义 SDK 侧 30 多个扩展点。\n 致谢 感谢所有曾经参与到社区建设中来的贡献者。\n特别感谢愿意为 Seata 提供指导的 Champion 和 Mentors:\nChampion：\nSheng Wu（wusheng @apache.org）\nMentors：\nSheng Wu(wusheng @apache.org）\nJustin Mclean(justin @classsoftware.com）\nHuxing Zhang(huxing @apache.org）\nHeng Du(duhengforever @apache.org）\n我们坚信，将 Seata 引入 ASF 可以推动开源社区向着更强大、更多元化发展。我们将努力践行 Apache Way，同时欢迎更多的公司和个人加入到开发队伍中来，让 Seata 社区更加健康、茁壮地成长，让更多人享受开源带来的技术红利！\n项目寄语 四年前，我们秉持开源开放的理念，在社区写下了第一行代码。回顾过去四年，Seata 开源社区的技术演进和社区运营就像一次创业旅程。这四年我们取得了不菲的成绩，Seata 的出现快速占领了开发者的心智，成为了分布式事务领域的事实标准，在理论实践中我们牵头推动了行业标准的建立。Seata 捐赠给 ASF 是我们迈向更多元化社区治理和全球化发展的重要里程碑。\n\u0026amp;ndash; 季敏（Seata 开源社区创始人）\n恭喜 Seata 全票通过进入 Apache 孵化器！2019 年，蚂蚁集团和阿里集团携手一起开源了分布式事务框架 Seata，各自贡献了内部分布式事务的最佳实践。经过了四年的发展，Seata 早已成为一个被社区广泛认可的分布式事务项目，大量的贡献者在 Seata 里面贡献代码，丰富了 Seata 的各种功能，很多用户在自己的环境中使用 Seata，给 Seata 带来了大量的实践落地案例。Seata 进入 Apache 孵化器不是终点，而是新的起点，期待 Seata 后面能够持续按照 The Apache Way 的方式运作，以更加中立的姿态，吸引更多的贡献者和用户，走向更加宽阔的未来。\n\u0026amp;ndash; 黄挺（蚂蚁集团中间件负责人）\n非常高兴 Seata 这个阿里和蚂蚁合作多年的开源项目进入 Apache 基金会进行孵化，相信 Apache Way 会帮助项目更加社区化、服务更多人，也期待 Apache 的 Seata 能为社区带来更多微小而美好的改变。对于蚂蚁开源来说，Seata 进入 Apache 孵化也是一个重要的里程碑，希望未来有更多蚂蚁团队发起的项目能走上 Apache 之路。\n\u0026amp;ndash; 王旭（蚂蚁开源技术委员会副主席）\n分布式事务是微服务架构最复杂，技术水位最深的部分。阿里\u0026amp;amp;蚂蚁在开源捐献之前申请了数十个专利，开源之后在社区推动下高速发展，吸收 70%+外部开发者，大幅降低分布式的复杂度，扩展了分布式事务的生态；未来随着微服务高速发展，随着数据一致性要求越来越高，相信分布式事务会发挥越来越大的作用！\n\u0026amp;ndash;李艳林（阿里云微服务团队负责人）\nSeata 是一款由阿里巴巴和蚂蚁集团共同参与开发的分布式事务解决方案，广泛应用于两家公司的内部系统。它的突出特点在于高性能和简单易用，为微服务架构下的分布式事务处理提供了高效且可靠的解 …","date":1700118000,"description":"携手开源，共同见证｜Seata 进入 Apache 孵化器","dir":"blog/open-source-together-seata-enters-apache-incubator/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bc69512b849467987dfe2349cb824154","permalink":"https://sofastack.github.io/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","publishdate":"2023-11-16T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","summary":"北京时间 2023 年 10 月 29 日，分布式事务开源项目 Seata 通过 Apache 基金会的投票决议，以全票通过的优秀表现正式成为 Apache 孵化器项目！ 根据 Apache基金会邮件列表显","tags":["SOFAStack"],"title":"携手开源，共同见证｜Seata 进入 Apache 孵化器","type":"blog","url":"/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/","wordcount":4740},{"author":null,"categories":"SOFAStack","content":" 文｜王连平（花名：烨川)\n蚂蚁集团容器团队专家\n本文 3441 字 阅读 9 分钟\n技术背景 Kubernetes 是容器编排的标杆平台，其标准化、插件化特性促使其拥有巨大的生态体系。众所周知，Kubernetes 是由其众多管控组件共同驱动容器交付的，但这种特性可会给开发人员和 SRE 在开发和运维过程中带来更高复杂性。\n当容器在交付过程出现错误，通常会使用 Kubectl 命令行工具查看 Pod 相关的事件，进而查看相关组件的日志定位具体的错误。这种方式存在效率低、信息少的缺点，导致问题排查耗时耗力。另外，容器在交付过程中会经历诸多阶段，比如调度、IP 分配、挂卷、容器创建和启动等，当此过程变得很慢时，需要精准定位到哪里是瓶颈点，最直接的方法是在所有管控组件做埋点，然后逐阶段分析问题。这种埋点方式带来了巨大的工作量，不易推进实施。\n针对这些问题，蚂蚁集团围绕 Kubernetes 平台构建了一套综合的容器观测服务——Lunettes。它利用 Kubernetes 多维度的交付信息（例如 API Server 请求、Audit 审计）构建了一套容器交付全生命周期观测服务，可以跟踪和诊断容器交付过程，并且基于诊断能力提供容器交付 SLI/SLO 服务，实现了数字化方式监控和管理 Kubernetes 容器服务。\n整体方案 在 Kubernetes 系统中，大量的管控组件在容器交付的过程中分工协作，为交付出来一个正常运行的容器不断的重试调和，过程中会产出大量的中间请求动作、日志等信息，Kubernetes 系统这种异步终态特性是容器交付可观测服务的一个关键挑战。那么在此类系统中观测容器交付过程，应该具备哪些特性呢？\n我们希望 Lunettes 应该具备：\n 提供多维度的容器交付信息，并且能优雅处理面向终态的机制\n 提供便捷的组件接入方式，尽可能小的侵入组件代码\n 提供较灵活的定制化或者配置方式\n 给用户提供简单易用的交互接口\n Lunettes 基于上述特性的考虑，整体采用旁路数据采集、数据分析和数据服务思路，围绕 Kubernetes 的审计日志做容器交付相关业务的分析，包括 Pod 基本信息、Pod 交付关键生命周期、Pod 交付诊断、Pod 交付跟踪和 Pod 交付 SLO 共 5 部分的交付数据。在数据分析链路上抽象出多个通用的模型，让用户灵活定制容器交付 Trace 及 SLO 诊断能力。同时，向上提供了 OpenAPI 和 Grafana UI 两种用户交互接口，便于用户信息消费。\n系统架构 上图示意了 Lunettes 系统的系统架构和数据链路，除了 Kubernetes API Server 审计数据源、数据采集和数据存储组件外，Lunettes 整体包括用户接口层和数据处理层两部分，其中数据处理层是 Lunettes 的核心业务逻辑所在。其处理流程如下：\n 从数据流向看，Filebeat 从 Kubernetes API Server 采集审计日志后，存储到 Elastic Search 中，在审计采集过程中使用 Filebeat Processor 进行冗余信息过滤，在数据存储 Elastic Search 时使用 Pipeline 增加必要时间序列，如此使得存储到 ES 中的数据量小而丰富。\n Lunettes 会近实时从 ES 拉取审计数据，审计进入 Lunettes 后首先会被 Share Processor 处理，这里处理主要分为 Pod 元数据信息提取、超事件（HyperEvent）抽象、以及并发反序列化审计请求中的 Raw Data，前置反序列化是为了减少后续 SLO、Trace 等业务处理时重复处理，提升性能。\n 数据经过 Share Processor之后，进入核心的交付分析模块，核心包括交付生命周期 Trace、交付 SLO 分析、交付原因分析及容器基础信息搜集，数据在模块之前按照需求做依赖 DAG，最终将产出 OTel、ES Table、Metrics 三种数据写入相关的数据服务。\n 存储到 ES、jaeger 和 prometheus 的数据，会被 Lunettes Rest API 和 Grafana di 处理，转换为 OpenAPI 数据接口和 Grafana Portal 上的数据进行展示。Grafana Portal 中一站式集成了 Lunettes 所有的功能，用户使用更便捷。\n Lunettes 核心能力 交付 SLO 交付 SLO 目的是基于 Kubernetes 交付链路能力对用户承诺交付保障。那么“交付 SLO”是什么呢？可以概括为：在一定时间内保障用户的容器可以成功交付。这个时间就是给用户的承诺，自然地 SLO 时间如何来定是非常关键的。Lunettes 主要从 Pod Spec 中获取资源规格、资源亲和配置等属性，计算出 Pod 的 SLO 时间。另外，Lunettes 也会根据 Pod 选择的不同交付链路（可以简单的理解为高速交付链路和普通低速链路）来给出保障时间。\n有了 SLO 超时计算标准，另一个挑战是如何计算 SLO 时间。如前文所述，容器交付链路中包含了多个阶段，Lunettes 将其区分为 Kubernetes 平台自身耗时和用户耗时两大类，通过 overlay 时间轴，去除用户时间后作为整体 SLO 时间保障。如此，对外承诺的 SLO 时间不会因为用户错误行为（配置、代码 bug 等）导致承诺失败。\n交付诊断 交付过程中出错是必然的，从庞大的 Kubernetes 系统快速定位容器交付过程中的问题是用户非常关心的。Lunettes 另一个重要的能力是从大量的容器交付行为信息中分析出容器交付的错误原因，用户通过 Portal 或者 OpenAPI 可以轻松获取容器交付的结果，如下图所示，Lunettes 在诊断结果中积累沉淀了 30 余种错误类型，帮用户快速定位问题。\n诊断过程中，Lunettes 采用回放审计日志技术，通过模拟容器交付过程抽象定义出原因分析 DAG 框架。审计日志回放输入 DAG 诊断框架后，各模块将分析自己阶段的交付是否完成，如果出错则抛出异常。最终，经过回放分析给出 Pod 出错位置，当然各分析模块是面向终态的分析过程。DAG 的框架既保证了分析过程行为的正确性，也提升了诊断流程的可扩展性。\n交付 Trace 交付 Trace 核心目的是跟踪每个 Pod 的交付过程，记录 Pod 交付过程中各阶段的耗时，以及对出错的阶段进行日志记录。一般地，在微服务系统中面向请求的 Trace 都是打桩，正如前文所述 Kubernetes 这种终态异步系统中，打桩每个管控组件是非常大的一个工程量，而且在组件之间异步分布式传递 Trace Context 很有挑战性。Lunettes 另辟蹊径，基于审计日志，抽象出 HyperEvent 概念，其包含了 Pod 交付过程中发生在 Pod 身上所有的 Verb 和 Event 两类信息，比如 Patch 一个 Condition 表示某个交付阶段完成，透出一个 Event 表示某个阶段结束。这两种信息被进一步用于定义交付 Trace 过程中每个阶段的开始和 …","date":1699945200,"description":"告别复杂性！用正确的工具轻松应对 K8s 管理挑战","dir":"blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"55bbf8c8afe1ee0fec5d19b4e8176065","permalink":"https://sofastack.github.io/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","publishdate":"2023-11-14T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","summary":"文｜王连平（花名：烨川) 蚂蚁集团容器团队专家 本文 3441 字 阅读 9 分钟 技术背景 Kubernetes 是容器编排的标杆平台，其标准化、插件化特性促使其拥有巨大的生态体系。","tags":["SOFAStack"],"title":"告别复杂性！用正确的工具轻松应对 K8s 管理挑战","type":"blog","url":"/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/","wordcount":2785},{"author":null,"categories":"SOFAStack","content":" 今天，我们邀请到了开源之夏 2023 活动 Dragonfly 社区的中选学生李从旺同学，他此次承担的项目是——「PyTorch Serve 基于 Dragonfly P2P 技术分发模型」。希望通过他的开源故事，能让更多人了解到开源的魅力，也可以从不同的视角去认识 Dragonfly 项目。\n关于 Dragonfly Dragonfly 提供高效、稳定、安全的基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为孵化级别的托管项目。Dragonfly 在解决大规模文件分发场景下有着无可比拟的优势。P2P 技术在 AI 推理服务分发大模型场景现阶段应用较少，并且 P2P 技术经过证实也可以真正解决大文件分发过程中的性能瓶颈。在 AI 推理服务分发大模型场景，通过集成 Dragonfly P2P 技术减少源站压力，并且提高模型分发效率。结合 AI 推理领域生态拓展 Dragonfly 应用场景，服务 AI 领域并且成为重要基础设施。\n项目信息 项目名称：PyTorch Serve 基于 Dragonfly P2P 技术分发模型\n项目导师：戚文博\n项目描述：本项目是在 PyTorch Serve 分发过程中解决推理模型拉取时，可能会存在性能带宽瓶颈的问题，所以本项目需要 Dragonfly 通过 P2P 能力提高 PyTorch Serve 模型拉取速度，主要供过 Plugin 方式将 Dragonfly P2P 能力集成到 PyTorch Serve 中。\n项目链接：https://github.com/dragonflyoss/dragonfly-endpoint\n项目实现思路 无论你是需要安装或是升级，对 Dragonfly 各个组件的理解很重要，这是后期顺利进行性能测试的一个前提。\n Manager: 维护各 P2P 集群之间的关系，动态配置管理和 RBAC。它还包括一个前端控制台，方便用户直观地操作集群。 Scheduler: 为下载对等体选择最优的下载父对等体。异常控制 Dfdaemon 的返回源。 Seed Peer：Dfdaemon 开启的种子节点模式，可以作为 P2P 集群中的背向源下载节点，它是整个集群中下载的根节点。 Peer: 与 Dfdaemon 一起部署，基于 C/S 架构，提供 dfget 命令下载工具，dfget 守护进程运行守护进程提供任务下载功能。 架构 TorchServe 通过集成 Dragonfly Endpoint 插件，发送模型下载请求到 Dragonfly ，Dragonfly 作为代理去对应的 Object Storage 下载模型并返回。\n模型下载步骤：\n1、TorchServe 发起模型下载请求到 Dragonfly Peer。 2、Dragonfly Peer 会到 Dragonfly Scheduler 注册任务。 3、返回拥有资源的候选的父节点。 - Scheduler 服务发现本地 Cache 对这个任务是缓存未命中状态，就触发从 Seed Peer 进行文件下载。 - Seed Peer 如果对于任务也是缓存未命中状态，就会触发回源下载，即到对应的对象存储下载模型文件。 4、到对应的候选的父节点进行分片下载文件。 5、模型下载返回后，TorchServe 会进行模型注册。\n在性能测试的步骤中，会对模型下载的几种情况分别进行测试，而结果显示下载性能在命中缓存的情况下确实有极大的提升。\n开源之夏个人随访 自我介绍 大家好，我叫李从旺，是佐治亚理工学院电子与计算机工程专业研二的学生。去年就曾参加过开源之夏的活动，当时的任务是为 Apache APISIX 网关做插件。\n参加活动的原因 我之前参与过开源之夏，发现这个活动非常适合学生去了解以及深入参与到开源社区。众多的开源项目与技术发现可以让我们了解到行业中的最新动态，比如去年的云原生和今年的 AI 基础设施、大模型等。\n同时这种实践搭配的任务难度，在导师与社区的热心帮助之下，无论是为了磨练技术、建立社区连接，还是作为新手开源入门的起点都非常合适。对我来说，第二次参与活动的主要目的是了解并学习新技术。\n申请本社区项目的原因 主要是我对 Dragonfly 的 P2P 技术很感兴趣，并且它也符合我的技术栈。我提前了解过 Dragonfly 在业界的使用情况与热度，得知它作为实用的基础设施广泛被各个公司使用，且仍然在迭代新功能，于是便有了申请的想法。其次就是我对于插件的编写比较有经验，上手本次的项目会更加顺利。\n如何克服项目过程中的困难与挑战？ 主要的困难在于，之前我没想到 TorchServe 官方对于前端的插件支持较少，因此在调研初期，花费了较多时间去了解 TorchServe 的架构细节与插件的实现机制等。在插件的设计方案上也踩了不少坑：比如起初只考虑增加模型加速下载的部分，而官方 API 模型的下载与注册却是同时进行的；同时官方的代码设计中许多内部方法是不对外开放的，这样一来插件编写的方案也会有限制。这一问题的克服方法主要是反复查看官方代码、文档以及和导师沟通，不合理的方案不断地被导师淘汰，最终我找到了代码侵入最小的实现方式。\n还有开源项目从零开始搭建的困难，包括目录设计、工作流的设计、测试用例、文档编写（需要不断打磨）等工作。这些非 coding 的部分往往会占据更多的时间。我的建议是——积极参考社区优秀活跃的开源项目和直接询问导师，这样效率会比用搜索引擎快得多。因为很多规范是会随时间变化的，新项目当然要符合最新的规范。\n困难还出现在测试环节！整个插件的使用涉及到不同的对象存储、Dragonfly 以及 TorchServe 等多个组件；多种环境的部署以及不同的配置细节也需要付出额外的关注。当然，最大的挑战是由我硬件资源不足的电脑带来的，解决的办法主要是详细地记录步骤以及利用一些云计算资源，这对后期使用文档的撰写也非常有帮助。\n导师与社区带来的帮助 在整个开发的过程中，包括前期调研环节，导师给予我的帮助是巨大的。耐心、细心、负责是 Dragonfly 社区以及我的导师给我的最大感受了。他们不仅在技术上给出指导，在文档编写乃至后期的技术交流方面也都非常用心。开发周期内的每周例会和平时的信息反馈也都非常及时，我作为学生，体验也非常好。\n你眼中的 Dragonfly 社区印象 Dragonfly 致力于提供高效、稳定、安全的基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。目前社区还在不断壮大发展中，欢迎大家一起来参与开源共建。\n超出预期的收获 在调研中，我学习到了 Dragonfly P2P 的实现原理以及 TorchServe 各个模块的实现方案。在每周例会中，也有许多来自其他社区的同学或嘉宾， …","date":1699340400,"description":"开源之夏经验分享｜Dragonfly 社区 李从旺：社区贡献也是一种影响力","dir":"blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f093077c7b660418d01cdd971f144de1","permalink":"https://sofastack.github.io/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","publishdate":"2023-11-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","summary":"今天，我们邀请到了开源之夏 2023 活动 Dragonfly 社区的中选学生李从旺同学，他此次承担的项目是——「PyTorch Serve 基于 Dragonfly P2P 技术分发模型」。希望通过他的开源","tags":["SOFAStack"],"title":"开源之夏经验分享｜Dragonfly 社区 李从旺：社区贡献也是一种影响力","type":"blog","url":"/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/","wordcount":2622},{"author":null,"categories":"SOFAStack","content":" 文｜谭崇康（*花名：见云*）\n蚂蚁集团高级技术专家\n本文 3781 字 阅读 10 分钟\n问题：K8s 服务运营需要更好的可观测能力 云原生系统以 Kubernetes*（K8s）*为基石，业界很多公司的基础设施也构建在 K8s 平台之上。作为公司的关键基础设施，K8s 平台的运营效率直接影响业务的稳定与效率。\n然而，将 K8s 作为服务运营与单纯的使用 K8s 存在很大的区别。在使用 K8s 时，我们关注是形形色色的功能，而在 K8s 服务运营过程中我们将更加聚焦 K8s 服务的质量以及效率。运营一个 K8s 服务需要关注的典型问题例如：\n 问题诊断及其效率：K8s 链路长、组件多、概念丰富、状态复杂等，如何快速诊断日常失败问题原因是一个很关键的能力； 服务质量衡量问题：如何衡量 K8s 平台服务整体资源交付效率以及调度、镜像拉取、IP 分配等各个环节的服务质量，进而引导服务能力的提升； 链路性能问题：如何发现、定位集群中的性能瓶颈，提升集群的资源交付吞吐； 运营体系化问题：当前社区的可观测服务更多关注的还是某些孤立的功能点，服务运营需要的是数字化、性能、效率、体系化等。 Lunettes：K8s 平台运营可观测工作空间 K8s 集群构成的容器服务平台，并努力提升平台服务的质量。在这个过程中，我们沉淀了很多运营工具以及相关的运营经验。基于这些工具及经验，我们构建了容器可观测服务 Lunettes，希望帮助大家更简单地运营 Kuberntes 服务。Lunettes 项目代码已经在 GitHub 平台开放，欢迎大家参与！\n项目链接：https://github.com/alipay/container-observability-service\nLunettes 服务提供的一些特性，包括：\n 定义了 K8s 资源交付效率的 SLO，并基于 SLO 产出了成功率相关的可观测数据，用户基于 SLO 衡量 K8s 整体及子服务的质量，同时发现服务能力受损等问题； 提供了容器一键诊断能力，Lunettes 分析 K8s 资源交付过程的各个阶段，产出当前运维过程中的问题，帮助用户快速定位及解决问题； 建设了一套无侵入的资源交付 Trace 能力，基于 Lunettes 分析的 HyperEvent 事件，用户可以看到资源交付链路中各个子阶段的耗时及错误，及时发现性能瓶颈点。 其他的一些易用特性包括：\n 统一的操作界面，支持多集群管理，一站式服务体验； 多维信息的聚合能力，提供日志、监控、Trace 等多维数据融合的能力。 Lunettes 是一个一站式的 K8s 容器可观测服务，能够为原生的 K8s 集群构建一个为服务运营打造的可观测工作空间，大幅降低了 K8s 服务运营的难度：\n 基于可扩展的多维可观测数据构建：Lunettes 将不同维度的可观测数据抽象为 HyperEvent，并在 HyperEvent 之上构建其他服务能力。我们可以方便地通过配置化封装能力将新的可观测数据维度封装成 HyperEvent 从而扩展 Lunettes 的数据聚合能力。 面向原生 K8s 集群，一键拉起：Lunettes 各个核心功能都具备灵活的配置能力，并且默认配置为原生 K8s 版本设计。Lunettes 可以采用普通 YAML 或 helm charts 部署，用户可以方便地在 K8s 集群一键拉起 Lunettes 服务。 构建 K8s 运营的完整的可观测工作空间*（workspace）*：Lunettes 提供了包含资源交付 SLO、容器生命周期诊断、容器生命周期 Trace、多维数据融合等常用的功能，为 K8s 集群提供一站式运营工作空间。 软件架构 Lunettes 服务的软件架构分为四层，分别为：\n 用户接口层 *（User-Portal）*：图形化交互基于 Grafana 构建，此外我们也提供 OpenAPI 接口； 可观测服务层 *（Observability-Services）*：包含阶段耗时分析、资源交付 SLO、资源交付诊断、资源交付 Trace 等多个可观测特性； 数据处理层 *（Data- Processing）*：Lunettes 具有可观测数据源扩展能力，支持 Operations、Events 等多种可观测数据，并将可观测数据统一封装为 HyperEvent，经由上层的 SharedProcessor 统一处理。在 Lunettes 中，可观测数据的处理是高度可配置化的，ConfigCenter 负责配置的管理。 存储层 *（Storage）*：Lunettes 的存储层支持多种存储服务，包含 Prometheus、ElasticSearch、SLS 等。 基础功能介绍 资源交付 SLO K8s 的核心功能是将资源以容器的形式交付出去。如何定义容器平台的资源交付质量是一个核心的话题。Lunettes 首先根据可观测数据定义容器生命周期中的各个阶段，区分基础设施阶段以及用户应用阶段，从而统计容器平台容器交付所花费的时间。进一步，Lunettes 根据容器交付的时间定义资源交付 SLO。下图中展示了集群的 1 分钟级以及 1 小时级 Pod 创建成功率的 SLO 数据。\n容器生命周期诊断 Lunettes 将诊断 Pod 创建流程中各个阶段的错误，形成典型容器创建错误码，例如 FailedScheduling 对应调度失败、FailedPullImage 对应镜像拉取失败等。典型的错误码将具备以下功能：\n 错误信息形成一个标准的错误集合，每个错误类型以可理解的方式代表特定的一类错误，给用户提供当前交付失败的诊断结果； 形成标准的 ErrorCode，作为上下游问题传递的依据，构建端到端的诊断链路； 当集群故障时，诊断结果作为聚合信息，当大量错误聚合时，方便我们快速定位到集群中的错误组件及错误原因。 在诊断过程中，Lunettes 将从底层的可观测数据中抽取生命周期中的关键事件，涵盖了 Operation、Events 等，帮助用户根据关键事件快速定位容器生命周期中的各种问题。\n资源交付 Trace Lunettes 设计了一套无侵入的资源交付*（创建、删除等）*过程 Trace 体系，基于 Lunettes 分析的 HyperEvent 事件，以用户可理解的方式分析资源交付过程中的各个阶段，例如 IP 分配、镜像拉取、Volume 绑定等，并基于这些分析构建了资源交付 Trace。通过资源交付 Trace，用户可以方便地找到资源交付过程中各个阶段的耗时及错误，从而掌握整个资源交付过程中的热点问题。Trace 与 Log、Event 等关联，帮助用户快速找到问题的根因。\n多维信息聚合能力 基于我们在过去多年积累的 K8s 运营经验，Lunettes 为日常运营活动中的多个典型场景设计，聚合了 YAML 信息、Event 信息、审计信息、Trace 信息、SLO 信息等多维度的可观测信息，为用户提供一个完整的 K8s 运营可观测工作空间。\n实践：几个典型的使用场景 Case1：诊断 Pod 创建失败 以镜像拉取失败为例，我们来看一下在 Lunettes 中， …","date":1698735600,"description":"Lunettes - 让 Kubernetes 服务运营更简单","dir":"blog/lunettes-makes-kubernetes-service-operations-easier/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"edc4c98af54696e29b070cc6ce02dea6","permalink":"https://sofastack.github.io/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","publishdate":"2023-10-31T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","summary":"文｜谭崇康（*花名：见云*） 蚂蚁集团高级技术专家 本文 3781 字 阅读 10 分钟 问题：K8s 服务运营需要更好的可观测能力 云原生系统以 Kubernetes*","tags":["SOFAStack"],"title":"Lunettes - 让 Kubernetes 服务运营更简单","type":"blog","url":"/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/","wordcount":3487},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack GitHub issue 精选 本周各项目回复 issue 精选 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n1.@MOSN #2347\n@huayangchan\n 我们目前在调研阶段，想用 envoy 做来做流量代理，但是考虑到研发效能，所以想用 MOE 的方案看看。因为涉及到 L4 的流量处理，顺便再确认下，那对于企业内部自定义的 RPC 协议，涉及到四层的流量 filter 操作，基于目前开源版 MOSN 是做不‍到哈？只能基于原生 envoy 的 L4 extension 来做么？\n A：这个我们内部的做法就是 MOSN 的 xprotocol 框架支持多协议，然后再用 L4 MOE 嫁接到 envoy 上。收益还是很可观，没有链接的常驻协程。如果直接用 envoy 的 L4 的话，你其实还是需要用 Go 搞一套 proxy 框架出来的。你可以先用纯 MOSN 支持你们的 RPC 协议，然后再用 MOE 移植到 envoy 上。\n「MOSN」：https://github.com/mosn/mosn/issues/2347\n2.@SOFABolt #332\n@tongtaodragonfly\n 在我们的环境中，连接事件日志文件中出现警告消息，如下所示：\n未知协议代码：[ProtocolVersion{version=[3]}] 在 ProtocolDecoder 中解码时。] 为什么会报告此警告消息？什么样的情况可能会触发此警告消息？\n A：协议版本是应用层网络帧的第一个字节。通常为 1*（对于 BoltV1）*和 2*（对于 BoltV2 协议）*。如果第一个字节是 3，bolt 找不到对应的协议，所以你会看到这个错误。\n此问题可能有两个常见原因：\n 一些未知的客户端向您的端口发送错误的数据包； 解码器没有消耗掉一个数据包中的所有数据，因此存中留下了一些错误的数据。Decoder 下次消费数据时，读取到了错误的数据。 「SOFARPC」：https://github.com/sofastack/sofa-registry/issues/332\n3.@SOFAArk #741\n@jgslvwy\n 请问下 SOFAArk 子应用支持用 spring-boot-maven-plugin 吗？为什么示例里面子应用还用的 sofa-ark-maven-plugin？\n A：子应用使用 sofa-ark-maven-plugin 构建产物是可以热部署到基座的 Jar 包，你要用 spring-boot-maven-plugin 也是可以，子应用本身也是独立的 Spring Boot，只是不能热部署到基座 JVM 上而已。\n「MOSN」：https://github.com/sofastack/sofa-ark/issues/741\n本周推荐阅读 MoE 系列（六）｜Envoy Go 扩展之并发安全\nSeata Saga 模式快速入门和最佳实践\nGo 语言，如何做逆向类型推导?\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\n","date":1696575600,"description":"SOFA 聊天室、issue 精选","dir":"blog/sofa-weekly-1006/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0dd36b93af4616c470c2dacf6b00830c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-1006/","publishdate":"2023-10-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-1006/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 聊天室、issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-1006/","wordcount":1117},{"author":null,"categories":"SOFAStack","content":" 文｜梁仕威（花名：栖川）\n蚂蚁集团算法专家\n方略平台技术负责人，专注于分布式计算领域，主要负责蚂蚁基础算法的分布式设计与开发。\n本文 3419 字，阅读 9 分钟\n在类似安全风控这种对抗性的场景中，由于欺诈者作案手法的频繁变化，使得训练数据并不总会包含足够的信息给算法自动挖掘出优质的拦截规则，这种场景下高质量拦截规则的挖掘需要结合专家领域知识。如何将算法和专家领域知识相结合成为了业界一个值得探索的课题。蚂蚁集团 AI Infra 团队针对上述问题，构建了一个交互式的规则研发系统——方略，提供了一种在规则研发过程中高效融入专家领域知识的解决方案。\n描述该系统的 Demonstration Paper 《Fanglue: An Interactive System for Decision Rule Crafting》 近期已经被数据库领域的重要会议 International Conference on Very Large Data Bases （VLDB2023） 所接收。VLDB 是中国计算机学会 （CCF） 推荐的 A 类会议，每年都会吸引国内外各大高校和科技公司的投稿。\n1｜背景 决策规则由于其直观可解释的 If-Then 结构，被广泛应用于欺诈预防等金融科技领域至关重要的任务中。标准的决策规则由两部分构成：一系列条件和预测值。 条件是由特征、操作符、值构成的三元组结构，例如 age\u0026amp;lt;50。当规则中的所有条件都被满足时，规则会输出预测值。\n目前大多数现有的规则挖掘系统都是以端到端形式运行的，即给定训练集后，专家设定规则挖掘算法的优化指标和超参数，然后等待算法运行结束就可以获得一组规则。在这种方式下，设置超参数和优化指标是融入专家领域知识的唯一途径，一旦规则挖掘过程开始，专家就没有其他方法能够干预规则的生成。但是在如风控这种对抗性的场景中，由于作案手法的频繁变化，训练数据里并不总会包含足够的信息给算法自动挖掘出优质的规则。在这种情况下，专家必须将领域知识更深入地融合到规则生成过程中才能获得有意义的结果。\n举个例子，假设支付宝的一位风控专家，想要编辑规则来拦截一种新型欺诈行为。由于该欺诈行为是最近才出现的，他准备的数据集中只有少数关于这种欺诈行为的黑样本。假设这种欺诈行为的一个关键步骤是要求受害者向欺诈者发送多个付款码，因此短时间内付款码刷新的次数是识别这种欺诈活动的重要特征。然而风控专家发现挖掘算法返回的规则中没有使用该特征，大多数规则都使用了交易金额来区分欺诈行为和正常行为，因为数据集中的交易金额巧合地将这两种行为区分开了。但是随着新型欺诈行为的普及，交易金额就不能继续作为识别这种欺诈行为的有力依据了。这种现象在反欺诈场景中并不罕见，当黑样本太少时，无关的特征也能够区分出输入数据中的黑白样本。虽然付款码刷新频次确实是规则挖掘过程中一个非常有竞争力的特征 （例如评估指标排名靠前） ，但由于数据中噪声的影响，使得其不能排到最前面，从而不能被算法挖掘出来。这种情况下，将专家领域知识融入进来，让付款码刷新频次这个特征应用到拦截规则中，对阻止新型欺诈行为扩散尤为重要。\n为了能在规则研发过程中高效融入专家领域知识，蚂蚁集团 AI Infra 团队构建了一个交互式的规则研发系统——方略。方略为用户提供了一个 Web 界面来可视化地制定决策规则。用户将数据上传到方略后就可以开始规则研发流程，方略会实时地推荐出规则的候选条件与对应评估指标，并生成数据分析结果，为用户提供有用的定量分析信息。同时方略使用 Ray 作为计算引擎并将数据分布式存储在内存中，以满足在交互式处理大规模数据时的实时响应需求。\n2｜系统架构 （图 1）\n图 1 展示了方略的系统架构。用户通过 Web 界面与方略进行交互。方略的界面上有三个核心模块：条件推荐模块、条件编辑模块和规则评估模块。服务端的 Task Manager 负责接收来自三个核心模块的请求①，并且会启动相应的 Ray 作业②。\n用于计算的数据水平切分后预先加载进 Ray 的一组 Actor 内存里。对于一个特定的计算任务，每个 Actor 都会基于分配到的数据计算出局部统计信息，这些局部统计信息会汇集到 Driver 里进一步处理得到全局统计信息③。然后全局统计信息返回给 Task Manager④，并被传递给 Data Processor。Data Processor 在全局统计信息的基础上进一步处理，例如计算出各个候选条件的评估指标，得到的处理结果会在 Web 界面上展示给用户⑤。然后整个系统会等待用户的下一步操作。\n一旦用户作出某些操作 （例如从候选条件中选择一个加入到当前规则中） 触发相应的核心模块，系统就会重复上述过程。用户编辑好的规则会保存到数据库里⑥。\n3｜技术细节 不同于标准规则，方略采用合取范式 （Conjunctive Normal Form） 的规则表示形式，即同时支持“AND”和“OR”条件。合取范式规则是由一个或多个子句和一个预测值组成的合取式 （AND 连接） ，其中子句是条件的析取式 （OR 连接） ，条件的形式为特征、运算符、值。方略专注于二分类问题，使用训练集和验证集上的精确度、召回率、F1 得分或黑样本覆盖率等指标来评估决策规则。\n方略提供三种实时的条件推荐帮助用户构建规则： “AND”条件推荐、 “OR”条件推荐、近似条件推荐。\n假设我们已经有了一些子句构成的决策规则，需要往这个规则中增加一个“AND”或者“OR”条件，方略会搜索所有可能的三元组 （特征、运算符、值） ，并通过将这些候选条件附加到当前规则里计算评估指标。标准的规则学习算法会选择具有最佳指标的候选条件，而方略会在 Web 界面上展示在验证集上取得 top 评估指标的候选条件列表供用户选择。\n为了快速计算所有候选条件的评估指标，方略使用 Ray 作为计算引擎，每个 Actor 计算出局部统计信息，然后聚合到 Driver 里得到全局统计信息。为了验证系统的效率，我们在一个包含 140 万个样本和 50 个特征的数据集上进行了实验。图 2 对比了在生成“AND”候选条件下，方略的实现与基于 Mars on Ray （基于 DataFrame 运算） 实现的耗时。可以看到方略的实现非常高效，使用 16 个 Actor 就可以在 1 秒内返回结果，满足交互式环境下高响应的需要。\n（图 2）\n在安全风控场景下，当规则中存在一些容易被攻击的条件时 （例如拦截规则里有条件：转账金额\u0026amp;gt;=500，欺诈方只需要使得转账金额小于 500 就可以绕过拦截规则） ，风控专家会希望通过寻找“语义上相似”的条件来增加另一层保护。为了加强规则的鲁棒性，方略提出并引入了近似条件。假设当前的规则是 C1 and C2 and C3，覆盖的样本集为 A，我们希望在 C2 上增加近似条件，那么方略会在 C1 and C3 的基础上遍历所有的候选条件 （特征、运算符、值） ，每个候选条件都会覆盖数据的一个子集，记为 B。一个理想的近似条件应该在 A 和 B 之间具有高重叠度，同时又不引入太多额外的白样本。方略基于图 3 所示的公式衡量条件的相似度，其中表示中带有正标签的子集，表示中带有负标 …","date":1696316400,"description":"VLDB2023｜方略：一个交互式的规则研发系统","dir":"blog/vldb2023-fanglue-an-interactive-rule-development-system/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"310a7da278d5e5a913dc0e0d09ac6c02","permalink":"https://sofastack.github.io/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","publishdate":"2023-10-03T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","summary":"文｜梁仕威（花名：栖川） 蚂蚁集团算法专家 方略平台技术负责人，专注于分布式计算领域，主要负责蚂蚁基础算法的分布式设计与开发。 本文 3419 字，阅读 9 分","tags":["SOFAStack"],"title":"VLDB2023｜方略：一个交互式的规则研发系统","type":"blog","url":"/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/","wordcount":3237},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议回顾 SOFAServerless：\n主题：SOFAServerless 社区会议 时间：09 月 27 日 19:30 - 20:30\n会议内容：\n 待跟进事项：\n ModuleController corner case 和多场景验证以及功能打磨\n 0.5 版本补充 ModuleController 和 Arklet 新 feature 使用文档\n 开源中间件排摸继续跟进\n 补充 0.5 版本原理文档\n 0.5 版本待合并收尾，开源之夏结项\n 发布内容：\n SOFAServerless 0.5.0 可试用版本已发布，详细可查看👇\n 试用手册 https://sofaserverless.netlify.app/docs/tutorials/base-create/springboot-and-sofaboot\n 试用样例 https://github.com/sofastack-guides/sofa-ark-spring-guides/tree/master/samples/web/tomcat\n 「SOFAServerless」：https://github.com/sofastack/sofa-serverless/issues/117\nSOFAStack 社区本周贡献 本周推荐阅读 蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata Saga 模式快速入门和最佳实践\n大象转身：支付宝资金技术 Serverless 提效总结\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\n","date":1695970800,"description":"SOFAServerless 社区会议回顾、社区本周贡献、SOFA 亚运特辑","dir":"blog/sofa-weekly-20230929/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5b9c3463eb10dee170d71426e96abb86","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230929/","publishdate":"2023-09-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230929/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议回顾、社区本周贡献、SOFA 亚运特辑","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230929/","wordcount":529},{"author":null,"categories":"SOFAStack","content":" 2023 年 9 月 20 日，KCL 项目通过了全球顶级开源基金会云原生计算基金会 （CNCF） 技术监督委员会评定，正式成为 CNCF 沙盒项目。\n这意味着 KCL 得到了云原生开源社区的认可，保障了项目的中立性，有利于开发者、合作伙伴等共同参与项目建设，协作共赢，并为云原生应用交付带来动态配置管理和自动化能力迈出了重要一步！\n 项目地址：https://github.com/kcl-lang/kcl 项目官网：https://kcl-lang.io 通过进入 CNCF 沙盒，KCL 社区将更多吸引更多开发者和用户参与共建，进一步推动项目在云原生业务场景的成熟应用，此外加入 CNCF 将为 KCL 提供一个增强的协作和创新平台。它提供了与处于云原生技术前沿的多元化开发者、组织和行业专家社区进行交流的机会。我们期待与其他 CNCF 项目进行更多合作，贡献我们的技术专业知识，并探索更多 CNCF 项目集成的可能性。\n什么是 CNCF CNCF，全称 Cloud Native Computing Foundation （云原生计算基金会） ，是 Linux 基金会旗下的子基金会。CNCF 致力于为云原生软件构建可持续生态系统，涉及领域包括存储、计算、编排、调度、CI/CD、DevOps、服务治理、服务网关等。\n比如 Kubernetes 便是 CNCF 最具代表性的项目之一。\n什么是 CNCF 沙盒项目 CNCF 社区将项目分为沙盒项目 （Sandbox） 、孵化项目 （Incubating） 、毕业项目 （Graduated） 。著名的毕业项目有：Kubernetes、Prometheus、Istio、ETCD、Containerd、ArgoCD 和 Helm 等。完整的毕业和孵化项目列表查看地址：https://www.cncf.io/projects/\nSandbox 是 CNCF 创建的，旨在为开源项目提供一个有益的、中立的家园，以促进开源项目的合作与开发。入选沙盒的项目，是被 CNCF TOC 认可的，并值得进行实验和开发的潜力项目。\nSandbox 对应的是 CNCF 社区早期项目，列表为：https://www.cncf.io/sandbox-projects/ 。进入 Sandbox 需要 66% 以上的 TOC （技术委员会） 成员赞成，即全部 11 人 https://github.com/cncf/toc#members 中的 8 人投赞成票。\n什么是 KCL KCL 是一个开源的基于约束的记录及函数语言，期望通过成熟的编程语言技术和实践来改进对大量繁杂配置比如云原生 Kubernetes 配置场景的编写，致力于围绕配置的模块化、扩展性和稳定性，打造更简单的逻辑编写体验，构建更简单的自动化和生态集成路径。\n项目主要里程碑如下：\n 2022 年 5 月，KCL 正式开源； 2023 年 6 月，KCL 正式成为 CNCF Landscape 项目； 2023 年 9 月，KCL 由 CNCF 应用交付 TAG 进行审核并通过 TOC 投票，顺利成为 CNCF Sandbox 项目 - https://github.com/cncf/sandbox/issues/48 为什么需要 KCL 正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在云原生配置和自动化的特定问题域内，我们使用专用配置和策略语言用于编写和管理规模化复杂配置及策略。不同于混合编写范式、混合工程能力的高级通用语言，专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将复杂配置和策略编写思路和方式沉淀到语言特性中。\n此外，KCL 期望通过更现代化的声明式配置语言和工具，在轻量级客户端云原生动态配置领域填补配置语言及工具的空白并解决如下问题：\n 维度爆炸: 大多数静态配置如云原生领域的 Kubernetes YAML 配置需要为每个环境单独进行配置；在最糟糕的情况下，它可能引入涉及环境交叉链接的难以调试的错误，稳定性和扩展性都较差。 配置漂移: 对于不同环境的静态管理应用程序和基础设施配置的方式，往往没有标准的方式去管理这些动态的不同环境的配置，采用非标准化的方法比如脚本和胶水代码的拼盘，会导致复杂度呈指数增长，并导致配置漂移。 认知负担: Kubernetes 等作为构建平台的平台技术手段在底层统一基础架构细节方面出色，但是缺乏更上层的应用软件交付抽象，对于普通开发者认知负担较高，影响了更上层应用开发者的软件交付体验。 针对如上问题，KCL 期望提供如下能力:\n 通过代码抽象等手段屏蔽基础设施和平台的细节和复杂性，降低研发者认知负担； 编辑和校验已有的存量配置或模版，直接解决云原生小配置场景问题如 Helm Chart 配置硬编码问题，但远不止如此； 通过配置语言无副作用地管理跨团队的大规模配置数据，提升团队协作效率。 具体来说，KCL 可以：\n 在代码层面提升配置语义验证的能力，比如 Schema 定义、字段可选/必选、类型、范围等配置检查校验能力； 提供配置分块编写、组合和抽象的能力，比如结构定义、结构继承、约束定义和配置策略合并等能力； 用现代编程语言的方式以编写代码的方式提升配置的灵活度，比如条件语句、循环、函数、包管理等特性提升配置重用的能力； 提供完备的工具链支持，丰富的 IDE 插件、语言和生态工具链支持用以降低上手门槛，提升使用体验； 通过包管理工具和 OCI Registry 使得配置以更简单的方式在不同团队/角色之间分享，传播和交付； 提供高性能的编译器满足规模化配置场景诉求，比如满足由一份基线配置根据部署上下文生成不同环境不同拓扑的配置的渲染性能以及配置自动化修改性能诉求； 通过多语言 SDK，KCL 语言插件等手段提升其自动化集成能力，在发挥配置及策略编写价值的同时显著降低 KCL 的学习成本。 除了语言自身，KCL 还提供了许多额外的工具如格式化，测试、文档等工具帮助您使用、理解和检查编写的配置或策略；通过 VS Code 等 IDE 插件，包管理工具和 Playground 降低配置编写和分享的成本；通过 Rust、Go 和 Python 多语言 SDK 自动化地管理和执行配置。\nKCL 能做什么 动态配置管理 作为一种配置语言，KCL 为应用程序和平台开发人员/SRE 提供的最重要的功能是动态配置管理。通过代码抽象，我们可以构建以应用为中心的模型屏蔽复杂的基础设施和平台概念，为开发人员提供一个以应用程序为中心且易于理解的界面。此外，KCL 还允许平台人员快速扩展和定义自己的模型，并且这些模型可以通过 OCI 注册表进行分享和复用。\n此外，KCL 还支持与 Kubernetes Resource Model (KRM) 规范直接集成，KRM KCL 是一个通用的配置模型规范，用于描述和管理各种云原生资源，如容器、Pod、服务的配置操作和抽象等。KRM KCL 规范提供了一种统一的方式来定义和管理这些资源，使得它们可以在不同的环境中进行移植和复用。它建立在一个完全开放的 Kubernetes 世界当中，几乎不与任何编排/引擎工具 …","date":1695711600,"description":"喜报！CNCF 基金会宣布 KCL 成为沙盒项目！","dir":"blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1b28ec99e654374176191b2a95853377","permalink":"https://sofastack.github.io/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","publishdate":"2023-09-26T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","summary":"2023 年 9 月 20 日，KCL 项目通过了全球顶级开源基金会云原生计算基金会 （CNCF） 技术监督委员会评定，正式成为 CNCF 沙盒项目。 这意味着 KCL 得到了云原生开","tags":["SOFAStack"],"title":"喜报！CNCF 基金会宣布 KCL 成为沙盒项目！","type":"blog","url":"/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/","wordcount":4030},{"author":null,"categories":"SOFAStack","content":" 文｜唐荦彦\n深信服高级开发工程师，主要负责 SASE 云化架构以及基础设施建设\n本文 3056 字，阅读 6 分钟\n1｜你将在本文学到什么 多 K8s 集群镜像分发方案 Dragonfly 的理解 Harbor 的预热机制 Dragonfly 的使用以及排障 2｜K8S 多集群镜像分发问题 在边缘云架构的生产环境下，演进过程中，一开始的镜像分发方案如下：\n每个边缘集群都存在节点的 Harbor 仓库，进行缓存操作，当边缘集群集体崩溃重启过程中，不会引发所有 worker 上中心仓拉取镜像。\n带来的问题是：\n 每套环境一个 Harbor，导致部署、维护的困难。 Harbor 的复制策略比较简单，无法单例执行。并且重试非常占用中心仓带宽。 那么面对这种场景存在以下两种方案：\n Harbor 仓库分级复制策略 P2P 镜像分发策略 Harbor 仓库分级复制策略，存在以下问题：\n 如何进行分级划分 升级过程，如果节点所处的是第三级，如何触发复制策略加速缓存 每个节点增加了安全暴露面 节点的不断增加，后续是否需要 3 级、4 级、5 级，维护管理成本指数增加。 所以在项目中，我的选择是 Dragonfly 的 P2P 镜像分发策略。\n3｜Dragonfly 是什么 在理解过程中，首先需要搞懂以下几个问题：\n P2P 是什么？\n 镜像的分层拉取策略。\n 什么是 P2P 此 P2P 不是金融圈里面经常爆雷的，而是 Peer to Peer 网络技术。有几个比较突出的使用：\n 迅雷； 某夭折的播放器（*快 B*）； 国内一些视频网站白嫖用户网络的 P2P CDN。 为什么需要 P2P 网络 P2P 网络对应的就是传统网络传输 C/S 模式。传统模式下，所有的客户端请求数据下载都需要访问服务器，那么服务器的压力会非常大，当客户端多的情况下，网络带宽也存在问题。\n以下来自 WIKI 百科：\n对等式网络（*英语：peer-to-peer，简称 P2P*），又称点对点技术，是去中心化、依靠用户群（*peers*）交换信息的互联网体系。它的作用在于，减低以往网路传输中的节点，以降低资料遗失的风险。与有中心服务器的中央网络系统不同，对等网络的每个用户端既是一个节点，也有服务器的功能，任何一个节点无法直接找到其他节点，必须依靠其户群进行信息交流。\n镜像分层拉取 Docker 镜像通过分层进行资源共享，通过 copy-on-write 完成文件隔离。在执行 Pull 的时候，可以看到：\nc1c792ed5250: Already exists fcac137f6aa5: Already exists c31aa26549dd: Already exists 04699d7e44fb: Pull complete 可以分析得出，在 Docker pull 时，先会判断本地是否存在当前层，如果没有则从远端服务器拉取层。\nDragonfly 架构** 组件包括：\nManager: 多 Dragonfly 调度节点进行管理，提供了 UI 管理界面、镜像预热机制。\nScheduler:\n 基于机器学习的多场景自适应智能 P2P 节点调度，为当前下载节点选择最优父节点； 构建 P2P 下载网络的有向无环图； 根据不同特征值评估节点下载能力, 剔除异常节点； 当下载失败情况，主动通知 Dfdaemon 进行回源下载。 Dfdaemon： （*分为 Peer、Seed Peer*）\n 基于 gRPC 提供下载功能, 并提供多源适配能力； 开启 Seed Peer 模式可以作为 P2P 集群中回源下载节点, 也就是整个集群中下载的根节点； 为镜像仓库或者其他 HTTP 下载任务提供代理服务； 下载任务基于 HTTP 或 HTTPS 或其他自定义协议。 使用场景流程说明如下：（*当需要下载某一层镜像时*）\n Docker 在请求下载镜像时，通过配置 Docker http proxy 代理，将请求转发到 Peer 节点。\n Peer 节点进行本地缓存判断，查看是否存在该层镜像；\n 是，则直接响应。如图： 如果当前 Peer 不存在，将当前请求转发到 Scheduler；\n Scheduler 将判断 Seed Peer 中是否存在：\n 是，则将对应的地址返回，通知 Peer 去指定的 Seed Peer 拉取资源,如图： 否，则通知 Seed Peer 回源拉取，拉取成功后，Peer 再进行拉取。 最长路径：Docker -\u0026amp;gt; Peer -\u0026amp;gt; Seed Peer -\u0026amp;gt; 源站 -\u0026amp;gt; Seed Peer -\u0026amp;gt; Peer -\u0026amp;gt; Docker。\nDragonfly 操作实践（*Docker 版*） 由于 K8s 版本过于简单，封装了 Docker 手动操作部分，这里讲源码版本如何使用。\n源码安装\n从上面已经了解到：Docker pull 通过 http proxy 配置即可通过 Peer 拉取镜像，那么操作就简单了。\n步骤如下：\n 配置 Docker；\n 安装依赖组件：MySQL、Redis、Jaeger（*为了研究操作路径以及代码*）;\n 配置 Manager、Scheduler、Seed Peer、Peer；\n 详细步骤如下：\na.配置 Docker 配置 http proxy  vi /etc/systemd/system/docker.service.d/http-proxy.conf [Service] Environment=\u0026amp;quot;HTTP_PROXY=http://127.0.0.1:65001\u0026amp;quot; Environment=\u0026amp;quot;HTTPS_PROXY=http://127.0.0.1:65001\u0026amp;quot; 私有仓库的话，配置忽略证书 insecure-registries； vi /etc/docker/daemon.json { \u0026amp;quot;insecure-registries\u0026amp;quot;: [\u0026amp;quot;your.private.registry\u0026amp;quot;] } 重启 Docker：systemctl restart docker。\nb.安装依赖 MySQL: docker run -d --name dragonfly-mysql --restart=always -p 3306:3306 \\ --env MARIADB_USER=\u0026amp;quot;dragonfly\u0026amp;quot; \\ --env MARIADB_PASSWORD=\u0026amp;quot;dragonfly\u0026amp;quot; \\ --env MARIADB_DATABASE=\u0026amp;quot;manager\u0026amp;quot; \\ --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=\u0026amp;quot;yes\u0026amp;quot; \\ mariadb:10.6 Redis：\ndocker run -d --name dragonfly-redis --restart=always -p 6379:6379 \\ redis:6-alpine \\ --requirepass …","date":1695106800,"description":"Docker 环境基于 Dragonfly 的 Kubernetes 多集群镜像分发实践","dir":"blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a9c41894dec9bab10278add3e654f859","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","publishdate":"2023-09-19T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","summary":"文｜唐荦彦 深信服高级开发工程师，主要负责 SASE 云化架构以及基础设施建设 本文 3056 字，阅读 6 分钟 1｜你将在本文学到什么 多 K8s 集群镜像分发方案 Dragonfly 的理解 Harbor 的","tags":["SOFAStack"],"title":"Docker 环境基于 Dragonfly 的 Kubernetes 多集群镜像分发实践","type":"blog","url":"/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/","wordcount":2798},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题： Layotto 社区会议\n时间： 09 月 20 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入： +02162681677（中国大陆）+057128095818（中国大陆）\n入会链接： https://meeting.dingtalk.com/j/r3Nq5pEd730\n议题：\n Layotto 项目规划和展望 #976 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910 2023 CSDI SUMMIT #987\n add uds support for Java SDK\n 「Layotto」：https://github.com/mosn/layotto/issues/989\nSOAFServerless：\n主题： SOFAServerless 社区会议\n时间： 09 月 19 日 19:30 - 20:30\n入会口令（钉钉）： 909 575 00367\n电话呼入： +02162681677（中国大陆）+057128095818（中国大陆）\n入会链接： https://meeting.dingtalk.com/j/eU7EoXJYiHK\n议题：\n 已完成部分\n 健康状态检查方案 review\n 基座引用的 starter，支持 Spring Boot、SOFABoot，Arklet 版本推到 Maven 中央仓库\n 增加锁控制\n 修复 ModuleController 使用 Arklet 遇到的问题\n 基座 Starter，Arklet 0.4 版本打包发版\n 待迭代事项\n SOFAArk\n 基座模块 1:1 复用\n 支持 SOFABoot 4\n SOFAServerless\n 支持中间件列表与优先级，排摸支持情况，设计评测标准\n 官网搭建\n ModuleController\n 先扩后缩\n 模块回滚\n 模块流量 Service\n 强推基线\n 单测达到 80/60、8+ 集成测试、CI 自动化、开发者指南 #72 #73\n ModuleController 各项参数校验\n replicas = -1 表示对等架构\n Arklet\n 服务的跨 Spring Context 发现与调用\n 健康状态检查方案 review\n 增加影响基座健康状态的能力，查询健康状态指令模块安装支持远程协议\n 【spring-boot-ark-plugin】#74\n 【Arklet】指令耗时统计和资源消耗统计设计 #77\n Arkctl\n Arkctl 增加模块对应实例与状态查询\n Arkctl 增加模块代码初始化能力 #83\n Arkctl 增加模块部署能力 #82\n Arkctl、Arklet、ModuleController 0.5 发版本\n 「SOFAServerless」：https://github.com/sofastack/sofa-serverless/issue/100\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：09 月 13 日 14:00 - 15:00\n会议内容：\n 项目规划方向补充\n Wasm 组件的规划 资源隔离 开源之夏\n Dapr component 升级的讨论 集成 K8s 注入的进度分享和思路讨论 CSDI Summit 社区成员分享同步\n add uds support for Java SDK 的同步\n 「Layotto」：https://github.com/mosn/layotto/issues/989\n「会议回放」：https://www.bilibili.com/video/BV1UF411D77o\nSOFAStack 社区本周贡献 本周推荐阅读 SOFABoot 4.0 正式发布，多项新特性等你来体验！\n蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata-DTX｜分布式事务金融场景案例介绍\nSOFARegistry | 大规模集群优化实践\n","date":1694761200,"description":"SOFA Weekly｜SOFAServerless 社区会议预告、Layotto 社区会议回顾与预告、C 位大咖说","dir":"blog/sofa-weekly-20230915/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa9ec5c3db35fbfd01dcafbf949b707b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230915/","publishdate":"2023-09-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230915/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议预告、Layotto 社区会议回顾与预告、C 位大咖说","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230915/","wordcount":1262},{"author":null,"categories":"SOFAStack","content":" 文｜王勤龙（*花名：长凡*）\n蚂蚁集团 AI 系统工程师\n文｜张吉（*花名：理之*）\n蚂蚁集团 AI 系统工程师\n文｜兰霆峰\n四川大学 20 级计算机系\n本文 5104 字 阅读 13 分钟\n01 背景 如今大语言模型（*LLM*）的分布式训练节点规模越来越大，训练耗时长。比如 OpenAI 在 1024 个 NVIDIA A100 GPU 上训练 GPT-3 大约需要 34 天。训练节点越多，耗时越长，训练期间节点故障概率就越大，况且 A100 GPU 的故障率也相对较高。所以大规模训练作业难免会遇到节点故障。据我们在蚂蚁 GPU 训练集群上观察，一个月内，单卡的故障率约 8%，那么一天单卡的故障率约为 0.27%。常见的故障原因有 Xid、ECC、NVLINK error 和 NCCL error 故障等。对于一个千卡训练作业来说，卡故障导致一天内训练失败的概率高达到 93%。所以训练作业几乎每天都会失败。作业失败后，用户需要手动重启作业，运维成本很高。如果用户重启不及时，中间间隔的时间就会导致 GPU 卡空闲，浪费昂贵的算力资源。\n有些故障会导致机器不可用，从而导致可用节点数量不能达到用户指定的数量。这时，训练就不能启动，用户需要手动减少节点数量后重新提交作业。待故障机修复后，用户又需要手动增加作业的节点数来重启作业。这样增大了用户的运维成本，也导致了新节点无法及时加入训练。\n为此，DLRover 在 Kubernetes 上基于 Torch Elastic 开发了弹性训练功能，实现 PyTorch 分布式训练的自动容错和弹性。具体功能如下：\n 出现故障后，快速执行节点健康检测，定位故障机并将其隔离，然后重启 Pod 来替换故障节点。\n 健康检测通过后，重启训练子进程来自动恢复模型训练，无需重启作业或者所有 Pod。\n 节点故障导致可用机器少于作业配置，自动缩容来继续训练。集群新增机器后，自动扩容来恢复节点数量。\n 优化 FSDP 并行训练的模型 save/load，支持根据实际卡数 reshard 模型参数，缩短 checkpoint 保存和加载时间。\n 在 DLRover 弹性容错应用在蚂蚁大模型训练前，一周内千卡训练运行时间占 60.8%，有效训练时间约 32.9%（*有效训练时间=模型迭代的步数*每步的时间*）。除此之外，训练运行时间还包括 checkpoint 保存时间和训练回退时间等。DLRover 上线后，一周内千卡训练运行时间占比提升至 83.6%，有效训练时间提升至 58.9%。\n02 PyTorch 弹性训练框架 弹性训练是指在训练过程中可以伸缩节点数量。当前支持 PyTroch 弹性训练的框架有 Torch Elastic 和 Elastic Horovod。二者显著的区别在于节点数量变化后是否需要重启训练子进程来恢复训练。Torch Elastic 感知到新节点加入后会立刻重启所有节点的子进程，集合通信组网，然后从 checkpoint 文件里恢复训练状态来继续训练。而 Elastic Horovod 则是每个训练子进程在每个 step 后检查新节点加入，子进程不退出的情况下重新集合通信组网，然后有 rank-0 将模型广播给所有 rank。二者的优劣对比如下：\n通过上述对比可以看出，Torch Elastic 重启训练子进程的方案对用户更加友好，支持更多的分布式训练策略和模型。而 FSDP 和 NCCL 是当前大模型分布式训练使用最为广泛的技术。所以 DLRover 选择使用 Torch Elastic 重启子进程的方案来实现 Kubernetes 集群上分布式训练的弹性容错。\n03 集合通信动态组网 动态组网是指训练进程可以自动根据动态变化的节点数量来组网集合通信，无需固定给各个节点指定集合通信的 rank 和 world size。动态组网是弹性容错训练必须的，因为弹性容错作业中，节点的失败、扩容或者缩容都会导致节点的 rank 和 world size 变化。所以我们无法在作业启动前给节点指定 rank 和 world size。\nTorch Elastic 动态组网 Torch Elastic 启动子进程后，所有子进程需要进行集合通信组网。Torch Elastic 使用 Dynamic Rendezvous 机制来协助子进程组网。每个节点上运行一个 ElasticAgent，ElasticAgent 会从一个共享存储中获取作业节点的 host group，然后将自己的 host 加入 group 并同步到共享存储里。这个共享存储当前默认使用 TCPStore。接着，ElasticAgent 不断从共享存储里获取查询 host group，直到 host group 里的节点数量达到最小节点数量 min_nodes 且一段时间内没有变化，即认为所有节点都准备好了。然后，ElasticAgent 就可以从 host group 里获取自己的节点 rank（*PyTorch 中称为 group rank*）和 world size。这样，ElasticAgent 就可以给拉起的子进程配置 local rank、global rank 和 world size 了。有了这些信息，子进程就可以进程集合通信组网。\n但是使用 Torch Elastic 原生方案中，我们发现一些问题：\n 节点不能容错。TCPStore 在一个训练节点上，如果该节点挂了，重组网就没法继续了。\n 节点 rank 是随机的。ElasticAgent 同步 host 到共享存储的顺序是随机的，导致节点 rank 的随机。在训练代码中，用户一般会将模型迭代信息输出在 rank-0 的日志里，比如 step、loss 和耗时等。用户只能通过进程日志寻找 rank-0 ，对于多节点的作业，这是比较麻烦的。\n Torch Elastic 的动态组网不能控制组网的节点数量。比如 LLM 模型训练中，用户可能会将 4 个节点作为一个数据预处理的组，那么弹性伸缩需要保证节点数量是 4 的整数倍。而 Torch Elastic 只要发现有一个新节点加入就会立刻重启训练。  DLRover 动态组网 针对上面问题，DLRover 重新实现了 PyTorch ElasticAgent 的动态组网模块 RendezvousHandler，利用 ElasticJob 点 Master 来协助 PyTorch 组网。Master 是一个纯 CPU 节点，不参与训练，稳定性比 GPU 节点高很多。\n（DLRover ElasticJob 动态组网）\nDLRover 的 ElasticJob 在启动 Pod 时，会给每个 Pod 一个唯一的编号 Pod ID 并配置到 Pod 的环境变量里。训练节点的 ElasticAgent 的 RendezvousHandler 会将自己的编号 Pod ID 和 GPU 卡数上报给 Master 的 Rendezvous Manager。然后不断从 Master 中请求通信 world，即所有节点的信息。Master 的 Rendezvous Manager …","date":1694502000,"description":"DLRover 在 K8s 上千卡级大模型训练稳定性保障的技术实践","dir":"blog/dlrover's-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9873bd3dccef5853a61dc3c706403d5d","permalink":"https://sofastack.github.io/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","publishdate":"2023-09-12T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","summary":"文｜王勤龙（*花名：长凡*） 蚂蚁集团 AI 系统工程师 文｜张吉（*花名：理之*） 蚂蚁集团 AI 系统工程师 文｜兰霆峰 四川大学 20 级计算机系 本文 5104 字 阅读 13 分","tags":["SOFAStack"],"title":"DLRover 在 K8s 上千卡级大模型训练稳定性保障的技术实践","type":"blog","url":"/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/","wordcount":5172},{"author":null,"categories":"SOFAStack","content":" 1. 前言 本文是支付宝资金技术团队在《大象转身-支付宝资金技术交付提效之路》系列总结之一。如果你正在负责一个所支撑的业务面临从平台到场景化创新的发展阶段，希望通过提升交付效率来提升技术团队的竞争力和团队研发幸福感， 那么这篇文章也许会让你有收获：\n Serverless 的技术理念是什么？对业务研发有什么借鉴意义？\n 如何基于 Serverless 驱动研发模式的升级，设计一个能让场景化创新快起来的技术架构，提升全局研发效率？\n 本篇作者：呆莫（代巍）、歆明（何鑫铭）\n文章较长，建议收藏和保存\n为什么写这篇文章 我们做了近两年的 Serverless 研发模式的探索和落地，目前该模式已经承接了大部分资金业务的场景，平台也已经进入推广期，有 20+ 团队经过 SOFAServerless 技术团队的介绍找到我们。未接入 SOFAServerless 的想从业务视角寻求架构选型依据和应用架构设计，已接入 SOFAServerless 的同学来寻找基座治理经验。因此决定写一篇文章，将我们的架构选型、设计和落地经验做一次完整的总结。\n2. 我们遇到的问题 我们的问题：随着场景创新增多，SOFA 应用变臃肿、团队研发人数变多导致研发和运维难度升高，阻碍了业务创新的交付效率，系统需要做重构。\n简单说说背景 资金在这两年时间，肩负了很多业务创新、寻找业务增量的目标。增量时代的创新是残酷的，成功的明星产品背后，是无数次的失败（这三年间，技术支撑了 15+ 个创新产品的建设，包括小程序、行业解决方案）。而支付团队转型做创新也面临着巨大的挑战：动辄 1-2 个月起的研发交付周期，在当时使得技术团队被按在地上摩擦，各种问题接踵而来。\n蚂蚁集团 CTO 苗人凤曾经说过，创新是九死一生，技术就是要帮助业务降低机会成本。\n我们逐渐意识到业务创新的快速发展，一定离不开业务快速交付的新型技术研发模式。如果我们还是沿用平台化的架构思路，在一个庞大的资金平台上写一堆创新场景的代码，在完成业务需求的同时还要思考如何抽象、如何保障增量的代码不影响平台稳定性，那一定快不了。\n2021 年，我们成立“资金场景创新提效项目”，试图通过平台架构升级、研发模式升级解决场景创新效率问题。\n问题定义：资金场景应用变成巨石应用带来一系列问题 试着代入一下案例：\n如果有那么 5 个创新业务迭代在同一个应用发布窗口进行推进，会存在各种各样导致延期的原因:\n1、A 业务验证延后 2 天，那么 5 个迭代都要延后 2 天；\n2、B 业务升级了中间件版本，那整个应用的业务都面临回归成本一样要延后整个发布期；\n3、C 业务想要在预发搭个车微调一些代码，但是由于动作慢没能成功验证，导致污染了主干，进而耽误了整体；\n……\n 在应用架构层面，资金部门早期孵化出了一个“大资金场景层应用”——Fundapplication。Fundapplication 在研发协作方面，从一开始的几个同学，到后来几个业务团队、几十个研发同学，都在一个应用系统上研发，通过多个 bundle 区分不同业务，公共的 bundle 沉淀通用能力和研发工具（*类似于之前的 mng 系统*），如下图：\n这种架构设计在遇到大量的彼此没有复用的业务创新需求时，就逐步沦为了巨石应用，如下图：\n1、研发运维效率低：作为入口系统，mgw 接口无法在本地开发自测，改动任何代码必须发布到联调环境。发布一次需要 10 分钟以上，还要忍受环境不稳定因素带来的额外时间花费。\n2、业务迭代抢占，协同成本高：系统作为创新应用系统，有 10+ 个创新产品，30+ 个正式员工和外包员工也在这个系统上做研发迭代，火车式发布迭代痛点明显——一人晚点，全体延期。\n3、研发时隔离效率低：30+ 研发同学（含外包）在一个系统内研发，经过不到一年的时间，我们的系统就变成 10+ 个 bundle、2w+ 个 Java 文件（*全站均值 4000*）的体量了，因为各种业务的各种依赖的增加，系统启动一次需要 15 分钟。随着创新场景增多会变得更加糟糕，而且很多代码没有办法随着业务的下线而删除。\n4、运行时不隔离：目前我们没有对不同的业务区分不同的机房，业务吃大锅饭，难以做到按产品的资源和稳定性保障。\n如果你的应用也存在上述问题，对业务创新的交付效率产生了一定的影响，那可以继续参考第 3、4 章我们的架构选型和关键设计。\n3. 应用架构的选型 当前蚂蚁基于 SOFABoot 的应用架构，在规模化创新场景研发的交付效率、分工协作模式上存在局限性。从行业的发展趋势分析，云原生等新技术引领的“集装箱”架构模式，有利于促进规模化的生产效率和分工协作方式。借助蚂蚁 SOFAServerless 的孵化，我们决定作为种子用户，使用 Serverless 中 BaaS+FaaS 的理念，重塑创新场景研发的研发模式。\n微服务应用架构的局限性 大应用创新的模式，是在一个应用系统中按照不同 bundle 来隔离创新应用，可复用的代码可能是放到一个公共的 bundle 中。优点当然是复用效率高，运维统一，缺点主要是协作效率、隔离成本和研发效率。大应用变成巨石应用如何解决？这个我们很容易就想到使用分治的思路，将一个大应用拆成多个应用，通过 RPC 来互相调用。\n在蚂蚁当前体系下，微服务系统的 0-1 成本、后续运维成本、硬件机器成本仍然会是一个不小的开销，创新试错还是快不起来。且后端业务创新具有巨大的不确定性，如果因为业务没量了变成长尾系统下线的成本也很高；在性能方面，多个系统间通用能力的调用，会使全链路的调用耗时增加，在业务上不可接受。所以有没有一种技术，可以让业务既能够隔离，又能够降低隔离带来的负向影响：运维成本、能力复用效率、性能？\n行业技术架构的发展趋势 一部分做架构的同学喜欢用“架构隐喻”来介绍架构的理念。近几年容器化、云原生、Serverless 等新技术层出不穷，作为架构师需要在对新技术保持敏感的同时，能够有一双洞察架构本质的眼睛。\n这些底层新技术的出现，本质上是通过抽象定义“集装箱”的方式，规范了构建、部署、运行、运维标准，提升了软件的生产效率。大家可以感受一下这些技术底层理念的相通之处：\n Docker 通过定义容器“集装箱”提升传统虚拟机、基础设施软件构建、运维效率；\n K8s 进一步抽象万物皆可定义为 CRD（*自定义资源*）提升“集装箱”的部署、运维效率；\n 中间件 Mesh 化将“集装箱”理念应用到中间件近端，将中间件近端与业务代码剥离解耦；\n BaaS、FaaS 等 Serverless 技术，将“集装箱”理念范围进一步扩大到可复用的“业务领域插件”。\n 可以这么说，集装箱改变世界航运效率，计算机软件行业的 Docker、K8s 们通过“集装箱”的架构理念改变了基础软件生产效率。而随着 Serverless 的兴起，“集装箱”的架构理念将会自底向上地，重塑对软件交付效率重度依赖的互联网、金融等行业。\n我们来看下，集装箱的理念对我们业务研发的启示：\n过去，业务研发需要关注独立的业务应用，既需要关注业务代码、中间件代码等代码信息，又需要关注 Java 进程、CPU、内存等运维信息，随着这两年蚂蚁 MOSN 等 Service …","date":1693897200,"description":"大象转身：支付宝资金技术 Serverless 提效总结","dir":"blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","fuzzywordcount":12500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d09a365280bac8113c2d8e53309c4911","permalink":"https://sofastack.github.io/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","publishdate":"2023-09-05T15:00:00+08:00","readingtime":25,"relpermalink":"/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","summary":"1. 前言 本文是支付宝资金技术团队在《大象转身-支付宝资金技术交付提效之路》系列总结之一。如果你正在负责一个所支撑的业务面临从平台到场景化创新的","tags":["SOFAStack"],"title":"大象转身：支付宝资金技术 Serverless 提效总结","type":"blog","url":"/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/","wordcount":12433},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAChannel#35 预告 SOFABoot 是蚂蚁集团开源的基于 Spring Boot 的研发框架。近期，SOFABoot 更新了 4.0 版本，带来了更多新特性。不仅正式支持了 Spring Boot 3 版本，也同时做出了包括历史功能演进在内的一系列调整优化，使得框架自身更加易用。\n本期 SOFAChannel#35 邀请到了蚂蚁集团技术专家、SOFABoot 项目 Maintainer 胡子杰跟大家分享 《SOFABoot 4.0 — 迈向 JDK 17 新时代》。\nSOFA 社区会议预告 SOFAServerless：\n主题：SOFAServerless 社区会议\n时间：09 月 04 日 19:30 - 20:30\n入会口令（钉钉）：909 575 00367\n电话呼入：+057128095818（中国大陆） +02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/EQzqQVtJoro\n议题：\n 8月回顾\n Arklet 待完成的动作\n 增加影响基座健康状态的能力，查询健康状态指令\n ModuleController 的功能\n 各项参数校验、单测达到 80/60、8+ 集成测试、CI 自动化、开发者指南\n 各组件的发版 release\n ModuleController 0.3\n Arklet 0.3\n SOFAArk 2.2.2\n 9 月迭代规划讨论\n SOFAArk\n 基座模块 1:1 复用 ClassLoader\n 支持 SOFABoot 4\n SOFAServerless\n 支持中间件列表与优先级，排摸支持情况，设计评测标准\n 基座 Starter，Arklet 的打包发布\n ModuleController\n 新扩后缩\n 模块回滚\n 模块流量 Service\n Arklet\n 服务的跨 Spring Context 发现与调用\n Arkctl、Arklet、ModuleController 0.5 发版本\n 「*SOFAServerless*」：https://github.com/sofastack/sofa-serverless/issues/44\nLayotto：\n主题：Layotto 社区会议\n时间：09 月 06 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+02162681677（中国大陆）+057128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/MkM4YQVrEE3\n议题：\n Layotto 项目规划和展望 #976\n 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959\n Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\n Develop a new component for sms API；为“短信 API”开发新的组件 #830\n 「*Layotto*」：https://github.com/mosn/layotto/issues/984\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：08 月 30 日 14:00 - 15:00\n会议内容：\n 下半年规划与展望\n SDK 模式、公有云部署的两个方向明确 开源之夏\n Layotto K8s 集成：关于动态配置注入思路的讨论\n 短信邮件 API：API 适配不同云厂商的组件具体开发\n 「*Layotto*」：https://github.com/mosn/layotto/issues/984\n「*会议回放*」：https://www.bilibili.com/video/BV1bz4y1K7RG\nSOFARPC 5.11.0 版本发布 发布 SOFARPC 5.11.0 版本，主要变更如下:\n 支持 SOFARPC 在 Mac M1 芯片环境编译\n 修复直连调用时，url 拼接错误的问题\n 升级 Hessian 到 3.5.0\n 升级 Bolt 到 1.6.6\n 升级 gRPC 到 1.53.0\n 升级 SOFARegistry 到 6.3.0\n 升级 Dubbo 到 3.1.8\n 升级 Javassist 到 3.29，引入新版 API，支持在 JDK 17 环境下使用\n 解决部分 SOFABoot 4.0 下的兼容性问题，现在 SOFARPC 支持基于 SOFABoot 4.0 运行\n 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.11.0\nSOFAHessian 3.5.0 版本发布 发布 SOFAHessian 3.5.0 版本，主要变更如下:\n 新增了 Currency、 Atomic、Throwable、StackTraceElement 类的定制序列化器，支持在 JDK 17 环境下运行\n 针对内部的反射逻辑做了一定的调整，支持在 JDK 17 环境下运行\n 详细发布报告：https://github.com/sofastack/sofa-hessian/releases/tag/v3.5.0\nSOFAStack 社区本周贡献 本周推荐阅读 SOFABoot 4.0 正式发布，多项新特性等你来体验！\n蚂蚁 SOFAServerless 微服务新架构的探索与实践\nSeata-DTX｜分布式事务金融场景案例介绍\nSOFARegistry | 大规模集群优化实践\n","date":1693551600,"description":"SOFAChannel#35 直播预告、SOFARPC/SOFAHessian 新版本发布、社区会议","dir":"blog/sofa-weekly-20230901/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4506495f5728921c30461c2adf82271f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230901/","publishdate":"2023-09-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230901/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAChannel#35 直播预告、SOFARPC/SOFAHessian 新版本发布、社区会议","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230901/","wordcount":1753},{"author":null,"categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区 活动时间：09 月 07 日，周四晚 19 点 活动形式：线上直播 资料下载： 点击获取 B 站直播间地址：http://live.bilibili.com/21954520 B 站直播回放：SOFAChannel#35 介绍 | SOFAChannel SOFA:Channel 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\nSOFA:Channel 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\nSOFABoot 项目简介 SOFABoot 是蚂蚁集团开源的基于 Spring Boot 的研发框架，提供了诸如 Readiness Check、模块化和日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\n近期，SOFABoot 更新了 4.0 版本，带来了更多新特性。不仅正式支持了 Spring Boot 3 版本，也同时做出了包括历史功能演进在内的一系列调整优化，使得框架自身更加易用。\n本期 SOFAChannel#35 邀请到了蚂蚁集团技术专家、SOFABoot 项目 Maintainer 胡子杰跟大家分享 《SOFABoot 4.0 — 迈向 JDK 17 新时代》。\n直播介绍 《SOFABoot 4.0—迈向 JDK 17 新时代》\n2023 年 9 月 7 日（周四）\n19：00 - 20：00\n「嘉宾简介」\n胡子杰（*花名：致节*）\n蚂蚁集团技术专家\nSOFABoot Maintainer\n「议题简介」\n本次分享将主要介绍 SOFABoot 4.0 新版本引入的新特性与变化，包括其设计理念与实现方式。再者就是介绍 SOFABoot 3 应用如何升级至 SOFABoot 4.0 版本，并展望 SOFABoot 未来的发展趋势。\n「听众收获」\n SOFABoot 4.0 的新特性与变化； 已有应用如何升级至 SOFABoot 4.0 版本； 一起探讨 SOFABoot 未来发展的趋势。 直播回放 点击查看\n了解更多技术干货 使用钉钉搜索群号：44858463 ，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1693465200,"description":"SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》","dir":"activities/sofa-channel-35/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"94eeffb4d40ce60a8be76d1892342c40","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-35/","publishdate":"2023-08-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-35/","summary":"概要 活动主题：SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区 活动时间：09 月 07 日，周四晚 19 点 活动","tags":["SOFAChannel"],"title":"SOFAChannel#35《SOFABoot 4.0 — 迈向 JDK 17 新时代》——SOFABoot 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-35/","wordcount":704},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题：Layotto 社区会议\n时间：08 月 30 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+057128095818（中国大陆）+02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/Wv0wyrJyDhA\n议题：\n Layotto 项目规划和展望 #976\n 2023 开源之夏-课题汇总 #894\n OSPP | Layotto 支持 plugable component 组件 #959\n Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\n Develop a new component for sms API；为“短信 API” 开发新的组件 #830\n 「*Layotto*」：https://github.com/mosn/layotto/issues/983\nSOFA 社区会议回顾 SOFAServerless：\n主题：SOFAServerless 社区会议\n时间：08 月 21 日 19:30 - 20:30\n会议内容：\n 8月回顾\n Arklet 待完成的动作\n 增加影响基座健康状态的能力，查询健康状态指令\n 健康状态检查方案 review\n 模块安装支持远程协议\n 修复 ModuleController 使用 Arklet 遇到的问题 #17\n 增加锁控制 #39\n 基座引用的 starter，支持 Spring Boot、SOFABoot，推到 Maven 中央仓库\n 9 月迭代规划讨论\n 支持中间件列表与优先级\n 支持 SOFABoot 4.0\n 回滚，先扩后缩，模块流量 Service\n Arkctl Arklet ModuleController 0.5 发版本\n 「*SOFAServerless*」：https://github.com/sofastack/sofa-serverless/issues/38\n「*会议回放*」：https://www.bilibili.com/video/BV19r4y1R761\nLayotto：\n主题：Layotto 社区会议\n时间：08 月 23 日 14:00 - 15:00\n会议内容：\n Layotto 社区下半年规划\n 开源之夏\n 自定义插件：等待同步动作\n 集成 K8s\n 此前遗留问题的讨论、动态配置的思路\n 在 K8s 上已跑通的 demo 分享\n 短信 API\n API 已完成，关闭 issue，将跟进开发各自组件\n 「*Layotto*」：https://github.com/mosn/layotto/issues/983\n「*会议回放*」：https://www.bilibili.com/video/BV15j411q7As\nSOFAStack 社区本周贡献 本周推荐阅读 蚂蚁 SOFAServerless 微服务新架构的探索与实践\n超越边界：FaaS 的应用实践和未来展望\nMoE 系列（七）｜ Envoy Go 扩展之沙箱安全\nSeata-DTX｜分布式事务金融场景案例介绍\n","date":1692946800,"description":"SOFAServerless 社区会议回顾、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-20230825/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"25a1f7a1856d6b2d7c1f7c87dd47da64","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230825/","publishdate":"2023-08-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230825/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAServerless 社区会议回顾、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230825/","wordcount":1130},{"author":null,"categories":"SOFAStack","content":" 作者简介 赵真灵（有济）\n蚂蚁集团技术专家，Serverless 和微服务领域专家\n曾负责基于 K8s Deployment 的应用发布运维平台建设、K8s 集群的 Node/pod 多级弹性伸缩与产品建设。当前主要负责应用架构演进和 Serverless 相关工作。同时也是 SOFAArk 社区的开发和维护者以及 KNative 社区的贡献者。\n本文 3612 字，预计阅读 12 分钟\n传统微服务架构面临的问题和挑战？ 应用架构从单体应用发展到微服务，结合软件工程从瀑布模式到当前的 DevOps 模式的发展，解决了可扩展、分布式、分工协作等问题，为企业提供较好的敏捷性与执行效率，给企业带来了明显的价值。但该模式发展至今，虽然解决了一些问题，也有微服务自身的问题慢慢暴露出来，在当前已经得到持续关注：\n1、业务开发者需要感知复杂的基础设施，启动慢（*分钟级*），研发效率低，运维负担重：\n对于基础设施的问题，在服务网格和应用运行时的工作已经取得了一定的成果，但是基础设施到业务开发之间还存在业务通用的部分，这里当前没有一个模式来给予支持。\n当前已经有一些开源项目在尝试解决基础设施的问题，例如服务网格、应用运行时，如 Dapr/Layotto，也都在实际应用中得到了不错的效果。但当前服务网格和应用运行时更多的是将中间件以下下沉到 sidecar，而一个应用一般还包括通用的业务逻辑部分，要让更广泛的业务也能享受到无基础设施的体感，也需要让业务以下（*可以把业务层以下的看作基础设施*）都能屏蔽。另外当前对于中小企业来说，使用服务网格和应用运行时的成本还是比较高的。\n2、拆分微服务的资源与维护成本高：\n拆分后每个子应用都包含公共部分（*框架、中间件等*），除了同样存在上述第一个问题之外，还需要独占机器资源成本高，如果部分业务萎缩，会面临长尾应用问题，需要承担长期维护的成本。\n3、拆分微服务的敏捷度与业务、组织发展的敏捷度不一致，导致如何合理地拆分微服务始终是个老大难的问题：\n 拆得多增加了资源和管理成本； 拆得不够造成协作效率问题。有些是应该拆但没拆，有些是因为业务领域已经较为细分不便再拆，特别在一些中小企业里，可能都没有微服务的配套设施。 蚂蚁的解决思路和方案 为了解决这些问题，我们对应用同时做了横向和纵向的拆分。纵向拆分：把应用拆分成基座和模块两层，这两层分别对应两层的组织分工。基座小组与传统应用一样，负责机器维护、通用逻辑沉淀、模块架构治理，并为模块提供运行资源和环境。模块在业务层以下所有的基础设施、应用框架、中间件可以不再关注，聚焦在业务逻辑研发本身；并且采用 jar 包的研发模式，具备秒级的验证能力，让模块开发得到极致的提效。\n这可以理解为这套架构的核心模型，核心的能力有两个：平台化 + 模块化。模块化是 20 年前 OSGI 就已经提出的概念，从 OSGI 到 JPMS 一直未被抛弃，到最近 Spring Modulith、Service Weaver 等行业里又兴起一些开源框架，它一直在发展；平台化从 2017 年出现在技术雷达到 2023 年被 Gartner 列为十大战略趋势之一，到现在国内的平台工程，不断得到重视和发展。而我们实际上在行业还没有对这两个技术方向充分关注的情况下，就在尝试把他们结合起来，并在蚂蚁内部得到规模化验证和落地，给业务带来极致的降本增效效果。\n该模式的另一个特点是可演进、可回滚。这里的模块随着业务发展壮大，可以独立部署成微服务；如果微服务拆分过多，可以低成本改造成模块，合并部署在一起，解决资源成本和长期维护成本。实际上可以理解为我们是在单体应用架构和传统微服务架构中间，增加了一个可以演进过渡的架构。\n总结下来这套新微服务架构可以解决这四个问题：\n1、横向拆分出基座屏蔽业务以下的基础设施、框架、中间件和业务通用逻辑等部分，从而极大降低了业务开发者的认知负荷、提高了开发效率。\n2、一个应用可以低成本改造或拆分出多个模块，模块间可以并行独立迭代，从而解决了多人协作阻塞问题，每个模块不单独占用机器资源，没有拆分的机器成本问题。\n3、存量微服务如果拆分过多，可以低成本改造成模块应用，合并部署在一起，解决拆分过多带来的资源成本和维护成本痛点。\n4、模块可以灵活部署，解决微服务拆分与组织发展灵敏度不一致导致的协作低效与分工不合理问题。应用拆分出多个模块，可以部署在一起，也可以进一步演进成独立微服务，同样如果微服务拆分过多，也可以低成本改回模块合并部署到一起。\n这里卖个关子——为什么这些技术在蚂蚁能规模化落地？存量的业务 owner 在业务迭代进度和升级新架构之间做权衡时，我们做了哪些工作？ 欢迎来到 9 月 3 号 QCon 大会现场获得更详细的信息。\n在采用新的微服务架构模式后的成果 举个当前蚂蚁实际业务采用新模式前后的对比数据：\n可以看到这些数据是十倍级以上的提升，当前蚂蚁所有 BU 都已经接入，将近 40W core 的在线业务，并为两种业务模式：中台模式和轻应用模式的业务都提供秒级研发运维的能力。一个基座上面最多有上百个模块，一个开发同学在研发验证阶段，一下午可以验证上百次，需求的交付效率最快可以到小时级别。\n在当下行情下，新技术落地的挑战与蚂蚁的思路 当前行情下，企业对新技术会更加谨慎，技术人也对新技术采取保守态度。新技术虽然很酷，但投入大落地场景有限。这其实是发展过程的转换，在高速发展的行情下，一方面是历史包袱少，另一方面是乐观态度占据主导，更加相信新技术能较快得到规模化落地，整个社会都对新技术充满热情。而在当下阶段，很多企业已经有一定的历史包袱，时间证明新技术规模化落地需要很长的周期，需要整个体系一起演进才可能达到最初的预想，可能也会带来越来越繁复的基础设施，所以当前行业对新技术更加偏保守也是非常合理的。\n所以蚂蚁在建设这套微服务新架构时，有一个非常关键的设计思路，那就是要接地气或者是可演进，也即是要让存量业务能低成本接入。这也是最初蚂蚁在落地该模式时踩过的最大的坑：一个普通应用转换成基座需要花费上月时间（*包括流量迁移*），模块研发与现有基础设施不匹配导致模块研发成本也很高，这个问题在当时也影响了该模式的生死存亡。后来蚂蚁在这块上投入了很大精力，最终让普通应用在小时内可以成为基座或模块，研发模式也与普通应用基本一致。\n经过这个过程，最终低成本、可演进也成为了该模式的一个核心优势。未来对外开源，我们会把接地气做得更加彻底，不对企业的基础设施程度有预设条件：\n 无需容器化也可以接入； 无需使用 K8s 平台也可接入； 无需具备微服务配套设施可也接入； 无需服务网格化也可接入。 微服务新架构落地实战中遇到的更具体的困难和挑战 我们做的这套模式在行业内没有先例，相当于是在无人区里摸索，因此面临多方面的挑战：\n1、关于模块化技术的质疑：为什么现在模块化技术又开始被关注？为什么我们基于 SOFAArk 的模块化技术能推广？挑战主要集中在如何制定合理的隔离和共享通信策略，我们需要避免 OSGI 之类的复杂度问题，做到可以低成本使用。\n2、模块化技术采用了多 ClassLoader，对于 ClassLoader 的隔离、卸载不干净等问题，我们一步一个脚印，深入并体系化 …","date":1692687600,"description":"蚂蚁 SOFAServerless 微服务新架构的探索与实践","dir":"blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b76d3b366c9f1902b9a16c8792999967","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","publishdate":"2023-08-22T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","summary":"作者简介 赵真灵（有济） 蚂蚁集团技术专家，Serverless 和微服务领域专家 曾负责基于 K8s Deployment 的应用发布运维平台建设、K8s 集群的 Node/pod 多级弹性伸缩","tags":["SOFAStack"],"title":"蚂蚁 SOFAServerless 微服务新架构的探索与实践","type":"blog","url":"/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/","wordcount":4058},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告 Layotto：\n主题： Layotto 社区会议\n时间： 08 月 23 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入：+057128095818（中国大陆）+02162681677（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/KPX3eRflTbk\n议题：\nLayotto 项目规划和展望 #976\n2023 开源之夏-课题汇总 #894\nOSPP | Layotto 支持 Pluggable Component 组件 #959\nSupport Pod Injection to deploy Layotto as a sidecar in Kubernetes #910\nDevelop a new component for sms API；为“短信 API”开发新的组件 #830\nDiscuss: whether the sms API definition needs to be modified；讨论一下是否需要修改 sms API 定义 #966\n「Layotto」：https://github.com/mosn/layotto/issues/981\nSOFA 社区会议回顾 Layotto：\n主题：Layotto 社区会议\n时间：8 月 16 日 14:00 - 15:00\n会议内容：\nLayotto 公有云部署想法、下半年产品演进路线讨论分析；\n开源之夏进展同步：\n可插拔插件初步方案的讨论；\nK8s 集成注入位置确认、Dapr 注入的实现方案讨论；\n短信 API 适应不同场景的设计方案\n「Layotto」：https://github.com/mosn/layotto/issues/981\n「会议回放」：https://www.bilibili.com/video/BV1wX4y1E7KQ/\nSOFAStack 社区本周贡献 本周推荐阅读 超越边界：FaaS 的应用实践和未来展望\nMoE 系列（七）｜ Envoy Go 扩展之沙箱安全\nSOFABoot 4.0 正式发布，多项新特性等你来体验！\nSeata-DTX｜分布式事务金融场景案例介绍\n","date":1692342000,"description":"SOFA Weekly｜Layotto 社区会议回顾与预告、SOFA 茶水间、社区本周贡献","dir":"blog/sofa-weekly-20230818/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f1f84d7ed240f62b5ec5da285c349dd4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230818/","publishdate":"2023-08-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230818/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜Layotto 社区会议回顾与预告、SOFA 茶水间、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230818/","wordcount":828},{"author":null,"categories":"SOFAStack","content":" 作者简介 邢奇（薯片）\n蚂蚁集团技术专家，云原生和 Service Mesh 领域专家\n长期从事服务治理和服务发现等相关领域的研究和实践，在 RPC 框架（*Dubbo、Spring Cloud 和 SOFARPC 等*）方面有源码级的研究和贡献；在 Service Mesh、云原生、容器和 K8s 等方面有深入的研究和实践经验。\n参与了多个开源项目的贡献，包括 MOSN、SOFA、Dubbo 和 Nacos 等。目前担任蚂蚁云开发技术负责人，负责支付宝云开发产品的研发和实践。\n本文 5689 字，预计阅读 16 分钟\n概述 什么是 FaaS ？\n在 ChatGPT 里面输入 FaaS 关键字，得到的结果是：*FaaS 是一种云计算服务模型*。它允许开发者编写和部署函数，而不需要管理底层基础设施的运行，即 Function as a Service。\n同时通过 ChatGPT 可以生成对应的函数代码——\nFaaS 的崛起 FaaS 的理念和函数研发模式，为传统的应用模式解决了许多问题，有着超前的优势。\n传统应用模式的困境 在研发态，不管是单体应用还是微服务应用，亦或是 Mesh 架构或者应用运行时，在研发态，开发者除了要关注业务逻辑本身之外，经常会被中间件所打扰，需要配合去做 SDK 升级改造，性能或者功能优化等。同时在使用云产品或者云服务的时候，需要被迫去感知多云的差异。\n在运维态，开发者面临着更重的运维压力。当一个应用上线，开发者需要对这个业务的未来发展进行一个复杂且不确定的容量评估，再去为这个容量去申请对应的资源，最后经过一个复杂的上线流程进行发布。在发布结束之后，开发者还得时刻关注线上流量的变化，去进行不断的扩容和缩容的调整。\n总而言之，整个中间件和基础设施对开发者的打扰是非常严重的：\n 应用研发模式的代码耦合严重，复杂度高； 运维流程繁琐，效率低； 容量评估一般很难符合真实情况，线上的资源利用率一般都较低，存在着浪费。 于是 FaaS 函数的研发模式应运而生。\n可以很直观地看到，在传统应用和微服务应用的改造和优化的基础之上，FaaS 希望做得更进一步，更面向未来。以函数为编程对象，用户无需关注应用、机器等数据和基础设施信息。\n通过这样的改变，大大提升研发效能，做到快速开发；并且提高运维效率，提供一站式免运维的 Serverless 平台；最后，函数会随着流量进行创建和销毁，最终降低成本和资源的消耗。\nFaaS 使用场景 尽管 FaaS 具有许多优势，但并非所有场景都适合采用函数编程模式。下面介绍一些 FaaS 适用的普遍场景：\n1、BFF 的场景。 即一些胶水代码（*对接多个接口、进行数据的组装和适配等*）。胶水代码的逻辑相对简单，但同时需求变化快、生命周期短。对应的应用场景如运营/营销活动等。活动结束之后，就不再有流量进入，也没有必要再进行代码和机器的维护。\n2、事件驱动的场景。 例如音视频转码，用户上传文件触发任务，或者通过消息触发调度，或者业务上有明显的波峰和波峰的流量特征。\n3、中台型业务。 例如算法平台的算子。算子计算是非常独立的业务逻辑，但是参与的研发人数非常多，逻辑相对来说不可控，需要有更高的隔离能力。\nFaaS 落地面临的技术问题 FaaS 技术产品的落地，可能会面临以下问题和挑战：\n性能问题：\n1、在传统的微服务架构下，开发者会为 RPC 调用性能进行了大量的优化；在 FaaS 的场景，也需要保证函数调用的性能。\n2、弹性扩缩容的反应时效性。很多 FaaS 产品会采用弹性的模型去采集 CPU、QPS 并发等指标，再通过平台去计算指标，进而进行一些扩容和缩容的操作，时效性很低。\n3、函数启动的速度。函数启动的速度在 FaaS 场景中至关重要，函数容器的创建和启动不仅仅是发布态的事情，而是一个数据面流量的依赖。\n安全问题：\n1、想要充分地利用计算资源以降低成本，其必要的前提就是有效地利用和隔离资源。\n2、代码容器。用户的函数代码跑在容器里面，防止容器逃逸就是重中之重。\n3、相较传统的编程模型而言，FaaS 的编程模型到底是如何屏蔽中间件以及云服务的干扰的呢？\n蚂蚁 FaaS 技术架构 蚂蚁在 FaaS 实践之初设定了 3 个 FaaS 技术架构实践的基本原则。\n原则 1：流量模型。 蚂蚁的函数容器是随着流量进行创建和销毁的，而不是通过指标数据进行分析的弹性模型。\n原则 2：函数冷启动。 尽管有 Warm Pool 或者 cache 技术可作选择，但为了最大程度降低成本和利用资源，蚂蚁将目标定为 100ms 以内的极致的冷启动。\n原则 3：安全隔离。 用户的函数都跑在我们的容器里面，因此必须保证高水位的安全隔离特性。\n其实，蚂蚁在实践 FaaS 技术架构时，有一个总的原则就是 one request per instance—极致的情况下，是创建一个函数容器去处理一个请求，类似编程模型创建一个线程去处理一个请求。在这里，创建函数容器就相当于创建一个线程，具有相似的快速、消耗低的优点，同时还有线程所不具备的安全隔离特性。\n架构说明 组件介绍和功能说明 函数网关：负责对函数请求进行转发和控制，并为每一个请求发起一次容器调度任务。\n容器调度引擎：负责对容器进行调度，维护容器的整个生命周期，并且可以对函数容器进行并发度和复用等状态控制，同时也负责管理整个集群的函数 Pod 资源池。（函数 Pod 资源池是函数容器运行的一个环境，一个集群内会有 N 多个 Pod 资源池。 ）\n函数运行时：函数运行时是 OCI 标准的实现，它负责快速地启动函数容器，并对容器的 runtime 进行有效的控制。\n函数容器：函数容器可以理解为是函数运行时+runtime+用户代码的一个运行态，用户的函数代码就跑在函数容器中。\n数据面流量和调度流程说明 从上图可以看到，所有请求都会通过函数网关进入到函数集群，函数网关会发起一次调度任务：通过容器调度引擎 Scheduler 为这一请求快速分配一个 Pod 资源。然后网关就会把这个流量转发给这个 Pod 资源里面的节点网关，节点网关随即缓存对应的请求，并且等待函数容器启动。同时函数节点调度器会并发地创建函数容器并且为容器挂载函数代码。函数容器在启动完成之后，就会立刻作为一个客户端去节点网关上拉取请求，然后进行业务逻辑处理。\n从上述流程中可以看到，蚂蚁 FaaS 场景中的 Serverless 有了第二层含义——no server（*没有 server*）。函数容器永远是作为一个 client 去处理请求。这样的方式从设计上就避免了对基础设施环境的依赖，同时减少了需要去打开一些网络端口、处理网络连接的损耗，也不需要像微服务应用那样去做一些 checkhealth 和 readliness 探针等之后才能进行注册，然后再进行服务发现和调用。\n性能优化实践 函数网关 FaaS 函数网关采用 Go 语言进行编写，网络编程模型是通过一个 go routine 处理一个请求的同步编程，比较符合开发者的习惯。同时由于 Go 语言良好的垃圾回收机制和 GPM 调度模型，网关也有了不错的性能。但是随着业务的不断增长，整个网关在高并发下会出现毛刺现象，P99 长尾也比 …","date":1692082800,"description":"超越边界：FaaS 的应用实践和未来展望","dir":"blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d4e9bc499a9bd2a868c56d990b3f4dc8","permalink":"https://sofastack.github.io/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","publishdate":"2023-08-15T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","summary":"作者简介 邢奇（薯片） 蚂蚁集团技术专家，云原生和 Service Mesh 领域专家 长期从事服务治理和服务发现等相关领域的研究和实践，在 RPC 框架（*Dubbo、Spri","tags":["SOFAStack"],"title":"超越边界：FaaS 的应用实践和未来展望","type":"blog","url":"/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/","wordcount":6592},{"author":null,"categories":"SOFAStack","content":" Dragonfly 最新正式版本 v2.1.0 已经发布！ 感谢赵鑫鑫[1]同学帮助重构 Console 代码，并且提供全新的 Console[2]控制台方便用户可视化操作 P2P 集群。欢迎访问 d7y.io[3]网站来了解详情，下面具体介绍 v2.1.0 版本带来了哪些更新。\n功能 Console v1.0.0[4]已经发布，它是一个全新的可视化控制台，方便用户操作 P2P 集群。 新增虚拟网络拓扑探索功能，能够在 P2P 运行时探测节点之间的网络延迟，从而构建一个虚拟网络拓扑结构提供调度使用。 Manager 提供控制 Scheduler 可以提供的服务，例如在 Manager 中设置 Scheduler 不提供预热功能，那么 Scheduler 实例就会拒绝预热请求。 Dfstore 提供 GetObjectMetadatas 和 CopyObject 接口，支持 Dragonfly 作为 JuiceFS 的后端存储。 新增 Personal Access Tokens 功能，用户可以创建自己的 Personal Access Tokens 在调用 Open API 的时候鉴权使用。 Manager REST 服务提供 TLS 配置。 修复当 Dfdaemon 没有可用的 Scheduler 地址时启动失败的现象。 新增 Cluster 资源单位，Cluster 代表一个 P2P 集群，其只包含一个 Scheduler Cluster 和一个 Seed Peer Cluster，并且二者关联。 修复 Dfstore 在 Dfdaemon 并发下载时，可能导致的对象存储下载失败。 Scheduler 新增 Database 配置，并且把之前 Redis 的配置信息移入到 Database 配置中，并且兼容老版本。 在 Dfdaemon 中使用 gRPC 健康检查代替 net.Dial。 修复调度器过滤以及评估过程中 candidateParentLimit 可能影响到调度结果的问题。 修复 Scheduler 中的 Storage 在 bufferSize 为 0 的时候，导致的无法写入下载记录的问题。 日志中隐藏敏感信息，例如 Header 中的一些 Token 信息等。 Manager 中 Scheduler、Seed Peer 等资源删除过程中，不再使用软删除。 Scheduler 数据库表中新增 uk_scheduler 索引，Seed Peer 数据库表中新增 uk_seed_peer 索引。 由于初期功能设计定位不清晰的原因，删除 Security Domain 和 Security 的功能。 Manager 和 Scheduler 新增 Advertise Port 配置，方便用户配置不同的 Advertise Port。 修复 Task 注册阶段状态机状态变更错误的问题。 破坏性变更 不再提供 Scheduler Cluster 和 Seed Peer Cluster 之间 M:N 的关系。提供了 Cluster 的概念，一个 Cluster 即表示一个 P2P 集群，并且一个 Cluster 只包含一个 Scheduler Cluster 和 Seed Peer Cluster，且二者是 1:1 的关联关系。 控制台 更多的关于控制台的内容可以参考官网文档 Manager Console[5]。\nAI 基础设施 Triton Inference Server[6]使用 Dragonfly 下载模型文件，可以参考 #2185[7]。如果有对集成 Triton Inference Server 项目 Drgaonfly Repository Agent[8]感兴趣的同学，可以联系 gaius.qi@gmail.com。 TorchServer[9]使用 Dragonfly 下载模型文件，现正在开发，预计 v2.1.1 版本可以使用，项目仓库在 Dragonfly Endpoint[10]。 Fluid[11]基于 JuiceFS[12]运行时通过 Dragonfly 下载数据，正在开发，预计 v2.1.1 版本可以使用。 Dragonfly 助力火山引擎 AIGC [13]推理业务 P2P 镜像加速。 社区中已经有很多案例，基于 P2P 技术使用 Dragonfly 分发 AI 场景中的文件。在 AI 推理阶段，推理服务并发下载模型可以有效通过 Dragonfly P2P 缓解模型仓库的带宽压力，从而提高整体下载速度。在 KubeCon + CloudNativeCon + Open Source Summit China 2023[14]社区联合快手做一次分享，主题是《Dragonfly: Intro, Updates and AI Model Distribution in the Practice of Kuaishou - Wenbo Qi, Ant Group \u0026amp;amp; Zekun Liu, Kuaishou Technology》[15]，感兴趣的同学可以关注。 维护者 社区新增四位 Maintainer，希望能够帮助更多的 Contributor 参与到社区的工作中。\n 黄逸炀[16]：就职于火山引擎，主要专注于社区代码工程方面。 温满祥[17]：就职于百度，主要专注于社区代码工程方面。 Mohammed Farooq[18]：就职于 Intel，主要专注于社区代码工程方面。 许洲[19]：大连理工大学在读博士，主要专注于智能调度算法方面。 其他 版本更新包含的更多细节可以参考👇 CHANGELOG：https://github.com/dragonflyoss/Dragonfly2/blob/main/CHANGELOG.md\n相关链接 [1].Xinxin Zhao Github：\nhttps://github.com/1zhaoxinxin\n[2].Dragonfly Console Github：\nhttps://github.com/dragonflyoss/console\n[3].Dragonfly 官网： https://d7y.io\n[4].Dragonfly Console Release v1.0.0： https://github.com/dragonflyoss/console/tree/release-1.0.0\n[5].Manager Console 文档： https://d7y.io/docs/reference/manage-console\n[6].Triton Inference Server： https://github.com/triton-inference-server/server\n[7].issue #2185： https://github.com/dragonflyoss/Dragonfly2/issues/2185\n[8].Dragonfly Repository Agent Github： …","date":1691478000,"description":"Dragonfly 发布 v2.1.0 版本！","dir":"blog/dragonfly-v-2-1-0-release/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d4047f2f246c79313ab932a67dc6b444","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-v-2-1-0-release/","publishdate":"2023-08-08T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/dragonfly-v-2-1-0-release/","summary":"Dragonfly 最新正式版本 v2.1.0 已经发布！ 感谢赵鑫鑫[1]同学帮助重构 Console 代码，并且提供全新的 Console[2]控制台方便用户可视化操作 P2P 集群。欢迎访问 d7","tags":["SOFAStack"],"title":"Dragonfly 发布 v2.1.0 版本！","type":"blog","url":"/sofastack.tech/blog/dragonfly-v-2-1-0-release/","wordcount":1667},{"author":null,"categories":"SOFAStack","content":" Dragonfly 项目简介 Dragonfly 是一款基于 P2P 的镜像加速和文件分发系统。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在 AI 数据分发、文件分发、日志分发和镜像分发等领域被大规模使用。在解决大规模文件分发场景下有着无可比拟的优势。\n自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF Sandbox 级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为 Incubating 级别的托管项目。\nSOFAChannel#34 就邀请到了蚂蚁集团技术专家、Dragonfly 项目 Maintainer 戚文博跟大家分享 Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的实践。\n直播介绍 《Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的加速实践》\n2023 年 8 月 9 日（周三）\n19：00 - 20：00\n「嘉宾简介」\n戚文博（花名：百蓦）\n蚂蚁集团技术专家\nDragonfly Maintainer\n「议题简介」\n在 AI 场景下，训练和推理两个过程中，数据的传输往往是关键瓶颈之一。Dragonfly \u0026amp;amp; Nydus 作为 CNCF Incubating 项目，其利用 P2P 技术和按需加载能力，能够大幅度提升数据传输的速度和效率，从而提高 AI 计算的整体效率和性能。这使得 AI 算法的训练和推理过程中数据传输更加高效和可靠，为 AI 技术的应用提供了强有力的支撑。\n「听众收获」\n1、了解并走进 Dragonfly 项目；\n2、镜像加速领域相关技术的分享；\n3、Dragonfly \u0026amp;amp; Nydus 在 AI 场景下的实践。\n直播预约 钉钉搜索：22880028764\n钉钉群同步直播，讲师在线答疑\nB 站直播预约 有机会获得 Dragonfly 精美贴纸～\nhttps://www.bilibili.com/opus/825142485488500792?spm_id_from=444.41.0.0\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1690959600,"description":"Dragonfly \u0026 Nydus 作为 CNCF Incubating 项目，其利用 P2P 技术和按需加载能力，能够大幅度提升数据传输的速度和效率，从而提高 AI 计算的整体效率和性能。","dir":"activities/sofa-channel-34/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0b819934f2ea5ec73a3cbc2f8470a87f","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-34/","publishdate":"2023-08-02T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-34/","summary":"Dragonfly 项目简介 Dragonfly 是一款基于 P2P 的镜像加速和文件分发系统。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在 AI 数据分发、文件分发、日志","tags":["SOFAStack"],"title":"SOFAChannel#34《Dragonfly \u0026 Nydus 在 AI 场景下的加速实践》——Dragonfly 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-34/","wordcount":663},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n*本文* 807 字 阅读 3分钟\n在本系列的第 5 篇《MoE 系列（五）｜Envoy Go 扩展之内存安全》中我们介绍了内存安全如何实现。第 6 篇《MoE 系列（六）｜ Envoy Go 扩展之并发安全》又谈到了并发场景下的内存安全。\n今天，我们来到了安全性的最后一篇：沙箱安全，也是相对来说，最简单的一篇。\n沙箱安全 所谓的沙箱安全，是为了保护 Envoy 这个宿主程序的安全，也就是说，扩展的 Go 代码运行在一个沙箱环境中，即使 Go 代码跑飞了，也不会把 Envoy 搞挂。\n具体到一个场景，也就是当我们使用 Golang 来扩展 Envoy 的时候，不用担心自己的 Go 代码写得不好，而把整个 Envoy 进程搞挂了。\n那么目前 Envoy Go 扩展的沙箱安全做到了什么程度呢？\n简单来说，目前只做到了比较浅层次的沙箱安全。不过，也是实用性比较高的一层。\n严格来说，Envoy Go 扩展加载的是可执行的机器指令，是直接交给 CPU 来运行的，并不像 Wasm 或者 Lua 一样由虚拟机来解释执行。所以，理论上来说，也没办法做到绝对的沙箱安全。\n实现机制 目前实现的沙箱安全机制，依赖的是 Go Runtime 的 recover 机制。\n具体来说，Go 扩展底层框架会自动地，或者（*代码里显示启动的协程*）依赖人工显示地，通过 defer 注入我们的恢复机制。所以，当 Go 代码发生了崩溃的时候，则会执行我们注入的恢复策略，此时的处理策略是，使用 500 错误码结束当前请求，而不会影响其他请求的执行。\n但是这里有一个不太完美的点，有一些异常是 recover 也不能恢复的，比如这几个：\nConcurrent map writes Out of memory Stack memory exhaustion Attempting to launch a nil function as a goroutine All goroutines are asleep - deadlock 好在这几个异常，都是不太容易出现的。唯一一个值得担心的是 Concurrent map writes，不熟悉 Go 的话，还是比较容易踩这个坑的。\n所以，在写 Go 扩展的时候，我们建议还是小心一些，写得不好的话，还是有可能会把 Envoy 搞挂的。\n当然，这个也不是一个很高的要求，毕竟这是 Gopher 写 Go 代码的很常见的基本要求。\n好在大多常见的异常，都是可以 recover 恢复的，这也就是为什么现在的机制，还是比较有实用性。\n未来 那么，对于 recover 恢复不了的，也是有解决的思路：\n比如 recover 恢复不了 Concurrent map writes，是因为 Runtime 认为 map 已经被写坏了，不可逆了。\n那如果我们放弃整个 runtime，重新加载 so 来重建 runtime 呢？那影响面也会小很多，至少 Envoy 还是安全的，不过实现起来还是比较地麻烦。\n眼下比较浅的安全机制，也足够解决大多数的问题了。\n了解更多…\nMOSN Star 一下🌟：\nhttps://github.com/mosn/mosn\n推荐阅读： MoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（四）｜Go 扩展的异步模式\n","date":1690873200,"description":"MoE 系列（七） - Envoy Go 扩展之沙箱安全","dir":"blog/moe-series (7) |envoy-go-extension-sandbox-security/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5f4a7e3872dbe224f8ed9d420af546dc","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","publishdate":"2023-08-01T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 *本文* 807 字 阅读 3分钟 在本","tags":["SOFAStack"],"title":"MoE 系列（七） - Envoy Go 扩展之沙箱安全","type":"blog","url":"/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/","wordcount":1055},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 1313 字 阅读 4 分钟\n前一篇介绍了 Envoy Go 扩展的内存安全，相对来说，还是比较好理解的，主要是 Envoy C++ 和 Go GC 都有自己一套的内存对象的生命周期管理。这篇聊的并发安全，则是专注在并发场景下的内存安全，相对来说会复杂一些。\n并发的原因 首先，为什么会有并发呢🤔️\n本质上因为 Go 有自己的抢占式的协程调度，这是 Go 比较重的部分，也是与 Lua 这类嵌入式语言区别很大的点。\n细节的话，这里就不展开了，感兴趣的可以看这篇👉cgo 实现机制 - 从 C 调用 Go\n这里简单交代一下，因为 C 调用 Go，入口的 Go 函数的运行环境是，Goroutine 运行在 Envoy worker 线程上，但是这个时候，如果发生了网络调用这种可能导致 Goroutine 挂起的，则会导致 Envoy worker 线程被挂起。\n所以，解决思路🪄就是像 Go 扩展的异步模式[1]中的示例一样，新起一个 Goroutine，它会运行在普通的 Go 线程上。\n那么此时，对于同一个请求，则会同时有 Envoy worker 线程和 Go 线程，两个线程并发在处理这个请求，这个就是并发的来源。\n但是，我们并不希望用户操心这些细节，而是在底层提供并发安全的 API，把复杂度留在 Envoy Go 扩展的底层实现里。\n并发安全的实现 接下来，我们就针对 Goroutine 运行在普通的 Go 线程上这个并发场景，来聊一聊如何实现并发安全。\n对于 Goroutine 运行在 Envoy 线程上，因为并不存在并发冲突，这里不做介绍。\n写 header 操作 我们先聊一个简单的，比如在 Go 里面通过 header.Set 写一个请求头。\n核心思路是，是通过 dispatcher.post，将写操作当做一个事件派发给 Envoy worker 线程来执行，这样就避免了并发冲突。\n读 header 操作 读 header 则要复杂不少，因为写不需要返回值，可以异步执行，读就不行了，必须得到返回值。\n为此，我们根据 Envoy 流式的处理套路，设计了一个类似于所有权的机制。\nEnvoy 的流式处理，可以看这篇👉 搞懂 http filter 状态码[2]。\n简单来说，我们可以这么理解，当进入 decodeHeaders 的时候，header 所有权就交给 Envoy Go 的 C++ 侧了，然后，当通过 cgo 进入 Go 之后，我们会通过一个简单的状态机，标记所有权在 Go 了。\n通过这套设计/约定，就可以安全地读取 header 了，本质上，还是属于规避并发冲突。\n为什么不通过锁来解决呢？因为 Envoy 并没有对于 header 的锁机制，C++ 侧完全不会有并发冲突。\n读写 data 操作 有了这套所有权机制，data 操作就要简单很多了。\n因为 header 只有一份，并发冲突域很大，需要考虑 Go 代码与 C++ 侧的其他 filter 的竞争。\ndata 则是流式处理，我们在 C++ 侧设计了两个 buffer 对象，一个用于接受 filter manager 的流式数据，一个用于缓存交给 Go 侧的数据。\n这样的话，交给 Go 来处理的数据，Go 代码拥有完整的所有权，不需要考虑 Go 代码与 C++ 侧其他 filter 的竞争，可以安全地读写，也没有并发冲突。\n请求生命周期 另外一个很大的并发冲突，则关乎请求的生命周期，比如 Envoy 随时都有可能提前销毁请求，此时 Goroutine 还在 Go thread 上继续执行，并且随时可能读写请求数据。\n处理的思路是：\n并没有有效的办法，能够立即 kill Goroutine，所以，我们允许 Goroutine 可能在请求被销毁之后继续执行。\n但是，Goroutine 如果读写请求数据，Goroutine 会被终止，panic + recover（*recover 细节我们下一篇会介绍*）。\n那么，我们要做的就是，所有的 API 都检查当前操作的请求是否合法，这里有两个关键：\n每请求有一个内存对象，这个对象只会由 Go 来销毁，并不会在请求结束时，被 Envoy 销毁，但是这个内存对象中保存了一个 weakPtr，可以获取 C++ filter 的状态。\n通过这个机制，Go 可以安全地获取 C++ 侧的 filter，判断请求是否还在。\n同时，我们还会在 onDestroy，也就是 C++ filter 被销毁的 Hook 点；以及 Go thread 读写请求数据，这两个位置都加锁处理，以解决这两个之间的并发冲突。\n最后 对于并发冲突，其实最简单的就是，通过加锁来竞争所有权，但是 Envoy 在这块的底层设计并没有锁，因为它根本不需要锁。\n所以，基于 Envoy 的处理模型，我们设计了一套类似所有权的机制，来避免并发冲突。\n所有权的概念也受到了 Rust 的启发，只是两者工作的层次不一样，Rust 是更底层的语言层面，可以作用于语言层面，我们这里则是更上层的概念，特定于 Envoy 的处理模型，也只能作用于这一个小场景。\n但是某种程度上，解决的问题，以及其中部分思想是一样的。\n了解更多…\nMOSN Star 一下🌟：\nhttps://github.com/mosn/mosn\n参考链接 [1]Go 扩展的异步模式:\nhttps://uncledou.site/2023/moe-extend-envoy-using-golang-4/\n[2]搞懂 http filter 状态码:\nhttps://uncledou.site/2022/envoy-filter-status/\n推荐阅读 MoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（四）｜Go 扩展的异步模式\nMoE 系列（五）｜Envoy Go 扩展之内存安全\n","date":1689663600,"description":"MoE 系列（六）｜Envoy Go 扩展之并发安全","dir":"blog/moe-series（6）｜envoy-go-extensions- concurrency- security/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1689663600,"objectID":"a7747e9132ae0170156edbe2e8b8b0f2","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","publishdate":"2023-07-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 1313 字 阅读 4 分钟 前一篇介","tags":["SOFAStack"],"title":"MoE 系列（六）｜ Envoy Go 扩展之并发安全","type":"blog","url":"/sofastack.tech/blog/moe-series6envoy-go-extensions-concurrency-security/","wordcount":1822},{"author":null,"categories":"SOFAStack","content":" Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开发。\n二方库升级 SOFABoot 4.0 基于 Spring Boot 3.0 与 Spring Framework 6 构建。在 Spring Boot 3.0 与 Spring Framework 6 引入的二方库升级列表可参考文档👉 Spring Boot 3.0 Release Notes\n在 SOFABoot 4.0 引入的二方库升级列表如下：\n Spring Boot 3.0.5 Spring Cloud 4.0.0 Spring Cloud Stream 3.2.6 SOFA Common tools 2.0.0 SOFATracer 4.0.0 SOFARPC 5.10.0 FastJson 1.2.83 Guava 31.1-jre Grpc 1.51.1 Grpc common protos 2.11.0 Druid 1.2.16 ASM 9.4 Javassist 3.29.2-GA Curator 4.3.0 Dubbo 3.1.8 Nacos 2.0.3 Swagger 1.6.7 Swagger2 2.2.8 基于 Jakarta EE Spring Boot 3.0 中依赖 Jakarta EE 规范的部分已经升级到了 Jakarta EE 10 版本。例如，使用 Servlet 6.0 和 JPA 3.1 规范。因此，部分包的命名空间也进行了替换，例如你应该使用：\n✅jakarta.servlet.Filter\n而不是 javax.servlet.Filter。\n同时，如果你使用了自己的依赖提供 Jakarta EE 规范的 API，需注意进行对应的依赖升级，例如你应该使用：\n✅jakarta.servlet:jakarta.servlet-api\n而不是 javax.servlet:javax.servlet-api。\n可参考文档：Migrate to Jakarta EE 9 来修改 Jakarta 相关的包名以及依赖。\n支持 SOFAArk 2.0 SOFAArk 2.0 模式是 SOFAArk 框架的整体优化版本，相较于 SOFAArk 1.0 模式，它的整体优化思路和原则是 Ark Master Biz 保持和原生 SOFABoot 保持一致，弱化复杂的 Ark Plugin 类管控机制，将 Ark Plugin 与 Master Biz 合并。使得 Ark Master Biz 和原生 SOFABoot 应用的启动方式、类加载方式保持一致，大大降低了 Master Biz 应用的编程难度。\nSOFABoot 4.0 版本不再支持 SOFAArk 1.0 模式，如果你想要在 SOFABoot 应用中使用 SOFAArk 2.0 模式，可以按照以下步骤进行操作：\n1、在项目中引入 SOFAArk 组件依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;ark-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2、添加 Spring Boot 的 Package 插件\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 3、启动应用\n 方式一： IDEA 启动，注意需要添加启动参数：-Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二： 命令行启动，先运行 mvn clean package 命令进行打包，生成 ${bizName}-${bizVersion}-ark-biz.jar 的可执行文件，然后在终端运行以下启动参数：\njava -jar -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName} ${bizName}-${bizVersion}-ark-biz.jar\n支持场景化的按配置加载能力 通常情况下，应用在不同的场景下可能需要开启或者关闭不同的功能，Spring Boot 提供了丰富的 Configuration 动态配置能力[4] 能力以支持应用在不同的场景下加载不同的 Bean。\nSOFABoot 在此基础上，对 org.springframework.context.ApplicationContextInitializer 等扩展点进行了增强，支持通过统一风格的配置定制各类 Bean 以及扩展点的开启与关闭，并提供了定制模版配置的开启方式以降低应用配置项的复杂度。\n 通过： com.alipay.sofa.boot.autoconfigure.condition.ConditionalOnSwitch 注解为 Bean 添加按配置开启能力：\n@Configuration(proxyBeanMethods = false) @ConditionalOnSwitch(id=\u0026amp;quot;sample\u0026amp;quot;) public class SampleConfiguration { @Bean public SampleBean sampleBean() { return new SampleBean(); } } 添加：\nsofa.boot.switch.bean.sample.enabled=false 配置后，SampleConfiguration 配置类将不再加载。\n 通过继承： …","date":1689058800,"description":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","dir":"blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2a9d6f15f257293795df8dec9fbc5130","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","publishdate":"2023-07-11T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","summary":"Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开","tags":["SOFAStak"],"title":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","type":"blog","url":"/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/","wordcount":3757},{"author":null,"categories":"SOFAStack","content":" 文｜魏陈豪（花名：无陈 Sam)\n蚂蚁集团 SOFAStack 产品专家\n本文 2966 字 阅读 8 分钟\n序言 今天给大家带来一篇 Seata-DTX[1] 商业版分布式事务在金融行业如何保证事务一致性的实践介绍。从一个全局视角出发看看一致性的保证、分别有哪些节点，事务组件在其中处在一个什么位置、担任什么工作。\n分布式系统下的事务问题阐述 云原生应用以分布式系统为主，应用会被切分到多个分布式的微服务系统下。拆分一般分为水平拆分和垂直拆分，这并不仅仅单指对数据库或者缓存的拆分，主要是表达一种分而治之的思想和逻辑。\n分布式系统的底层无法逃离“CAP 的不可能三角”*（C: Consistency，一致性；A: Availability，可用性；P: Partition Tolerance，分区容忍性）*。CAP 原理证明，任何分布式系统只可同时满足以上两点，无法三者兼顾。而分布式的服务化系统都需要满足分区容忍性，那么必须在一致性和可用性之间进行权衡。\n如果网络发生异常情况，导致分布式系统中部分节点之间的网络延迟不断增大，可能会导致分布式系统出现网络分区。复制操作可能会被延后，如果这时我们的使用方等待复制完成再返回，则可能导致在有限时间内无法返回，就失去了可用性；如果使用方不等待复制完成，而在主分片写完后直接返回，则具有了可用性，但是失去了一致性。\n图 1 CAP 理论\n图片出处：https://lushunjian.github.io/blog/2018/06/20/CAP%E7%90%86%E8%AE%BA/\n金融机构对一致性的诉求 对金融机构而言，架构层面的高可用和业务层面的强一致性，几乎同样重要。这就需要金融级云原生能够很好地平衡“CAP 的不可能三角”，需要尽可能兼顾业务强一致与系统高可用。\n但是“一致性挑战”在分布式系统中绝不仅仅是一个数据库问题，而是一个大的话题。其涵盖分布式系统的各个层面：事务一致性、节点一致性、系统间业务一致性、消息幂等一致性、缓存一致性、跨 IDC 一致性等等。所以也需要云原生架构有一系列技术能够应对金融级对一致性的严苛挑战。\n一致性控制的几个重要维度 这里挑选几个常见的金融场景下需要解决的一致性维度进行阐述。\n事务级：事务级别的一致性控制需要根据不同的金融场景选择合适的分布式事务模式。在我们针对 Seata-DTX 的客户进行调研后，发现大多数客户在平衡成本和性能后，基于 SAGA 和 TCC 是目前金融机构比较常用的两种分布式事务模式。SAGA 模式对应用实现侵入性更小，但基于补偿事务来保障一致性的设计、前后步骤执行过程中不保证事务隔离性；而 TCC 模式能做到比较好的事务隔离性，但需要应用层感知更多的复杂度。\n对于事务流程中部分不需要同步返回结果的节点，为提高执行效率可采用异步消息队列实现，对于一些事务流程较长的场景可明显降低事务实现复杂度、削峰填谷。典型场景如客户购买理财场景简化分为存款账户扣款和理财账户入账两个步骤，若选用 SAGA 模式，存款账户成功扣款后、理财账户入账失败，客户会看到“钱已付、货没到”的中间异常状态，需要系统进行冲正存款账户扣款来保障事务一致性。如选用 TCC 模式，先后完成存款账户扣款、理财账户入账的逻辑处理，各自需要存款系统和理财系统记录逻辑处理的状态，二者均成功后再发起统一提交。\n数据库级：接下来是数据库层面，金融场景下对于数据不丢有着极致的要求：一方面需要在同城、异地多个机房保存多个副本，另一方面需要在多个副本之间实现数据同步，Seata-DTX 的高可用也是依赖数据库之间的数据同步进行保障的。整体作用是以防一个 Seata-DTX 事务集群宕机后，切换到另外一套 Seata-DTX 事务集群后，可以恢复到正在进行中的事务记录，保障同城分布式事务的 RPO 为零、异地 RPO 接近零。数据库同步中，如果使用的是分布式事务库，分布式数据库一般通过对 Paxos 的支持来实现跨多服务器，甚至跨多中心的数据一致性保证。\n机房级：跨机房的路由能力、异常事务的跨机房恢复能力。发生机房故障时，数据库需要能够切到同城/异地的副本、并保障 RPO 为零，配合应用层的交易路由切换，完成机房级容灾切换、恢复业务。期间因机房故障导致的部分交易事务流程中断，分布式事务组件需要具备自动恢复能力，重新启动中断的事务流程按事先设定的业务规则向前完成或向后冲正。\n真实金融客户案例 以某资产规模超过 2 万亿元的省级农信为例，来看一下在核心整体下移的过程中，如何使用事务、配合数据库，机房容灾进行一致性控制。\n首先介绍一下整体的业务架构，在新核心平台中，大致可以分为产品服务层、交易中心层、交易中台层，如图 1 所示。交易中心收口所有的交易流程，对产品服务提供交易能力。最下面是交易原子能力层，主要包含 8 个中台，中台不直接对上提供服务，由交易中心统一处理。整个交易中心的能力，都基于服务编排构建，在编排流程中使用 SAGA 事务进行流程一致性控制。\n图 2 分布式新核心下移平台分层架构\n以贷款产品为例：整体的贷款支取、还款等长流程在信贷产品系统中，由 SAGA 事务进行串联，核心的资金交换部分由 TCC 事务把控一致性，做到对整体长流程里多个应用实现较小的侵入性。但基于补偿事务来保障一致性的设计、前后步骤执行过程中不保证事务隔离性，因此用 TCC 模式来处理对隔离性有较强诉求的核心资金交换服务，如图 3 所示。\n图 3 核心下移智能贷款系统流程\n如下图 4 是上述图 3 信贷产品中的还贷流程 TCC 流程示例。启动 TCC 事务后，使用 try 先尝试锁定客户账户余额，锁定成功后，等待二阶段提交。尝试 try 换贷款利息，锁定成功。整体提交事务，进行二阶段的扣账 confirm，以及还利息 confirm。\n图 4 核心下移智能贷款 TCC 流程\n事务层面的一致性进行了保证后，针对客户的 2 地机房进行事务的高可用部署，如图 5 所示。\n图 5 金融级云原生分布式事务部署架构\nConsole 是分布式事务的配置控制台，用户访问时通过 VIP 路由到不同机房的 console，数据写入到主 DB，主备 DB 数据实时同步。\nSeata-DTX Server 为分布式事务异库模式下的事务控制器和事务恢复器。其主要是记录事务日志，发起二阶段调用以及异常事务的恢复任务。\n业务应用用过 VIP 获取 Seata-DTX Server 对应的 IP。事务发起方发起事务时，事务日志都写入到主 DB 中，数据同步到备 DB。\n当福州 IDC 宕机或者断电时，流量会全部路由到上海 IDC。备数据库中因为有主 DB 的所有事务记录，当控制台查看事务数据和发起恢复事务任务时，仍然能正常执行。（当然可能会有人问这个情况下会不会频繁出现跨机房的分布式事务影响性能，此处负载均衡会基于入口流量的单元信息，自动调拨流量到对应的机房。此处不过多进行阐述。）\n综上可以看出，当前 Seata-DTX 的架构设计中，不单单是在事务层面去控制一致性。当有多个地域，多个副本时，可能需要结合数据库保证事务数据的一致。在多机房的情况下，需要依赖容灾能力，保证交易事务的流程可恢复。 …","date":1687849200,"description":"Seata-DTX｜分布式事务金融场景案例介绍","dir":"blog/seata-dtx｜distributed-transaction-financial-scenario-case-introduction/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1687849200,"objectID":"352eb80ff974af35f8069ba6c958fede","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","publishdate":"2023-06-27T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","summary":"文｜魏陈豪（花名：无陈 Sam) 蚂蚁集团 SOFAStack 产品专家 本文 2966 字 阅读 8 分钟 序言 今天给大家带来一篇 Seata-DTX[1] 商业版分布式事务在金融行业如何保证事务一致性的实践介绍。","tags":["SOFAStack"],"title":"Seata-DTX｜分布式事务金融场景案例介绍","type":"blog","url":"/sofastack.tech/blog/seata-dtxdistributed-transaction-financial-scenario-case-introduction/","wordcount":2760},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nLayotto：\n主题： Layotto 社区会议\n时间： 06 月 28 日 14:00 - 15:00\n入会口令（钉钉）： 688 824 34655\n电话呼入： +862162681677（中国大陆）+8657128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/NhOf1RUNqwL\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components #888 Support Pod injection to deploy Layotto as a sidecar in Kubernetes #910 Develop a new component for Encryption API #952 「Layotto」：https://github.com/mosn/layotto/issues/953\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 21 日 14:00 - 15:00\n会议内容：\n 本次社区会议预告开源之夏课题审核通过，等待 6 月 26 日 公示； 为 Configure API 开发 Nacos 组件问题，目前已经进入解决的最后阶段； 支持 Pluggable Components 及关于支持 Pod 注入，目前皆已审核通过，等待公示； 新增 Develop a new component for Encryption API 组件，相关任务已发布至社区群，感兴趣同学可留言加入其中。 「Layotto」：https://github.com/mosn/layotto/issues/953\n「会议回放」：https://www.bilibili.com/video/BV1kX4y1i75R/?spm_id_from=333.337.search-card.all.click\u0026amp;amp;vd_source=5dab7f4bd190defb59dcf6e727539b24\nSOFAStack 社区本周贡献\n本周推荐阅读\nSOFAStack 的下一个五年\nMOSN 反向通道详解\nSeata Saga 模式快速入门和最佳实践\n生产环境可用的 Seata-go 1.2.0 来啦！！！\n","date":1687503600,"description":"SOFA Weekly｜Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-20230623/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c0b300d2a38604aa46274b6323f27af1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230623/","publishdate":"2023-06-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230623/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230623/","wordcount":869},{"author":null,"categories":"SOFAStack","content":" 文｜宋顺（GitHub ID：nobodyiam)\nSOFAStack 社区开源负责人\n蚂蚁集团高级技术专家\n本文 3861 字 阅读 11 分钟 01 回顾开源这五年 回想起 2018 年 4 月 19 日 SOFAStack 首次开源，当时的官宣文章中就提到了我们开源的初心：\n期望通过逐步向社区开源 SOFA 中各个组件，从而一方面帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，另一方面也是期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固。\n所以这几年我们也是围绕着这个初心把 SOFAStack 体系的各个产品逐渐开源，包括首批开源的 SOFABoot、SOFARPC、SOFAArk，以及后来的 SOFARegistry、SOFAJRaft、Seata 等。同时我们也孵化了 MOSN 社区，开源了云原生网络代理 MOSN 以及应用运行时 Layotto。这些产品也是代表着 SOFAStack 在金融级云原生领域的沉淀和积累，目前已经在上百家企业中生根发芽。\n图 1 - 产品开源时间线\n我们再来看几个数字，在这 5 年中，我们举办了 18 场 Meetup，开展了 32 场直播分享，目前在 GitHub 组织层面有 438 名贡献者以及 3W 的 Star。\n图 2 - 开源 5 年的几个数字\n除了在项目上收获了不少贡献者和 Star 外，我们也逐渐地对开源有了更为深刻的认识。\n以开源指标为例，我们的初心是为了帮助更多机构和合作伙伴完成金融分布式转型，我们一开始最为关注的指标是用户数；但因开源的特殊性，我们无法直接获取实际的用户数，所以采用了 GitHub 的 Star 作为衡量指标。\n我相信这也是很多开源项目常见的第一反应，后期大家其实也发现了一些问题。举例来说，有些开源项目为了完成指标，采取了点 Star 送礼物等行为。这些虽然没有在我们的项目上发生，我们仍觉得有违开源初心，就放弃了 Star 数作为核心的指标。\n图 3 - Star 数作为衡量指标\n另一个开源项目常用的衡量指标是贡献者数量，很多开源项目是没有商业公司支撑的。为了项目的长期发展，需要持续的吸引新的贡献者加入，从而为社区带来活力。\n我们在放弃 Star 数指标后，把重心放在了贡献者数量上，会为新贡献者提供一些简单的任务，使他们能更快的融入社区，成为潜在的长期贡献者。\n不过和 Star 指标类似，在过程中我们也发现其它社区中出现了一些不好的现象。比如故意留一些明显的 bug，或者提供一些修改错别字的任务来刷贡献者数量，我们认为这些也是有违开源初心的。\n图 4 - Contributor 数作为衡量指标\n那么，我们该如何对待开源呢？\n我脑海中想起了 Envoy 作者 Matt Klein 在 Envoy 开源五周年时说的一句话：成功的开源软件就像创办一个企业。\n图 5 - 成功的开源软件就像创办一个企业\n其实开源项目和创业很类似，首先你需要有一个好的点子，然后去吸引人才一起加入来提升产品能力，再通过一些营销手段对项目做推广来获取客户，而后持续迭代改进。\n对企业而言，员工和客户固然很重要，不过我认为最核心的还是产品，只有一个定位准确、解决实际问题的产品才能受到市场欢迎，从而获取资金维持公司的运营。\n在开源项目上，用户对应着企业的客户，是提供场景的驱动力来源；贡献者对应着企业的员工，属于资源投入，是推动力来源；而产品才是真正能解决用户问题的，是整个开源飞轮中最为核心的部分。所以 Star 数和贡献者数量都只是过程指标，核心还是要提升产品力，不能本末倒置。\n图 6 - 开源飞轮\n02 展望下一个五年 聊完了过去五年的过程和收获，对 SOFAStack 而言，下一个五年的主要方向就比较明确：我们还是会着重放在产品力的提升上，希望能持续解决分布式场景中的核心问题。\n那核心问题究竟是哪些呢？我想起了泛在计算的提出者 Mark Weiser 曾经说过的一句话：最卓越的技术是那些“消失不见的”技术。\n图 7 - 消失不见的技术\n对这个判断，我也是深以为然。在日常生活中，这类案例也是比比皆是：比如电，我们现在都是即插即用，以至于已经不感知电力背后的复杂基础设施，类似的还有水、煤气等。它们背后都有着复杂的基础设施在支撑，经过了数十年的技术发展之后，已经非常稳定可靠，交互也非常简单，所以这些技术就像是“消失不见”一样。\n图 8 - 水电煤随开随用\n然而在我们实际的研发场景中，业务研发对基础设施的感知还远没有达到无感的地步。\n比如在研发态，我们除了要关注业务逻辑之外，还会经常被中间件 SDK 升级所打扰，在使用云产品时还得感知多云的差异。\n在运维态，除了要关注发布时的业务表现，还要时刻去关注资源状况。在其容量不足的时候要申请资源做扩容，在业务低峰的时候要缩容服务来节约成本。\n可以说，技术基础设施的存在感越强，研发运维的效率就越低，无法把精力集中在业务的创新上。\n图 9 - 实际研发场景\n那么，我们该如何才能让技术基础设施也消失不见呢？\n我们知道对微服务而言，可以通过服务网格来解耦业务逻辑和 RPC 通用能力，从而实现独立演进、透明升级。\n图 10 - Service Mesh 演进架构\n项目地址：https://github.com/mosn/mosn\n在实际场景中，除了微服务之外，业务往往还会使用其它的中间件能力。例如动态配置、消息、缓存、数据库等，如何降低这些中间件和业务应用的耦合是一个新的问题。另外，在多语言场景，我们仍然要为每种语言开发一套轻量 SDK 来实现通信协议和编解码逻辑，这部分也有很高的成本。所以我们如何进一步去降低多语言的支持成本是另一个亟待解决的问题。\n为此，我们也是借鉴了 Dapr 的应用运行时思路，基于 MOSN 设计开发了 Layotto，在下层对接了各种基础服务；在上层为应用提供了统一的、具备各种分布式能力的 API。\n开发者不需要再关心底层各种组件的实现差异，只需要关注应用本身需要哪些能力。比如调用 RPC、发送消息，然后通过 gRPC 调用对应的 API 即可。这样就可以彻底和底层基础服务解绑，同时也是极大地降低了多语言的支持成本。\n图 11 - Layotto 架构\n项目地址：https://github.com/mosn/layotto\n通过服务网格和应用运行时，我们解决了研发态对中间件 SDK 升级、多云差异感知等负担，我们再来看下如何通过 Serverless 技术来降低运维态的负担。\n我们知道业务研发一般是从需求到设计、开发、测试，最后发布生产的一个循环过程，其中不少业务还会出现多个迭代并行开发的场景。然而发布生产要求是串行的，就会导致迭代堵车的现象，后一个迭代必须得等前一个迭代发完才能开始发布，整体效率比较低。\n除此之外，随着业务重要性的提升，发布流程也会变重，发布周期短则几个小时，长则几天甚至几周也屡见不鲜。同时，业务逻辑的增加也会导致应用启动变慢，启动一个系统往往需要几十分钟，导致应用扩容等操作响应迟缓。\n图 12 - 研发迭代形式\n我们经过分析，发现不少应用代码本质上是可以分成两层的。一层是公共逻辑和核心模 …","date":1687244400,"description":"SOFAStack 的下一个五年","dir":"blog/the-next-five-years-of-sofastack/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"434c6a58fe31dc8becf81b773891362a","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-next-five-years-of-sofastack/","publishdate":"2023-06-20T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/the-next-five-years-of-sofastack/","summary":"文｜宋顺（GitHub ID：nobodyiam) SOFAStack 社区开源负责人 蚂蚁集团高级技术专家 本文 3861 字 阅读 11 分钟 01 回顾开源这五年 回想起 2018 年 4 月 19 日 SOFAStack 首","tags":["SOFAStack"],"title":"SOFAStack 的下一个五年","type":"blog","url":"/sofastack.tech/blog/the-next-five-years-of-sofastack/","wordcount":3990},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 21 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862162681677（中国大陆）+8657128095818（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/f4KJsKNnxfN\n议题：\n 2023 开源之夏-课题汇总 #894 为 Configure API 开发 Nacos 组件 #921 Support Pluggable Components #888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910 「Layotto」：https://github.com/mosn/layotto/issues/949\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：06 月 14 日 14:00 - 15:00\n会议内容：\n本次社区会议预告开源之夏目前已进入社区审核阶段；关于为 Configure API 开发 Nacos 组件问题，根据社区同学在 issue 中的沟通互动，已取得新的进展；支持 Pluggable Components 目前预计已完成审核，月底会有所公示；关于支持 Pod 注入，目前已审核部分，需等待官网公示；网站钉钉群二维码已修复与更新，可正常使用。\n「Layotto」：https://github.com/mosn/layotto/issues/949\n「会议回放」：https://www.bilibili.com/video/BV1wm4y1i7hv/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFARPC 5.10.1 版本发布\n发布 SOFARPC 5.10.1 版本，主要变更如下:\n 支持修改 gRPC Message Size #1333 升级 Hessian 到 3.4.0 以支持部分 java.time 类的序列化 #1338 详细发布报告：https://github.com/sofastack/sofa-rpc/compare/v5.10.0...5.10.1\nSOFAStack 社区本周贡献\n本周推荐阅读\nSeata Saga 模式快速入门和最佳实践\n生产环境可用的 Seata-go 1.2.0 来啦\nMOSN 基于延迟负载均衡算法-走得更快，期待走得更稳\nMoE 系列（五）｜Envoy Go 扩展之内存安全\n","date":1686898800,"description":"SOFA Weekly｜SOFARPC 5.10.1 版本发布、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230616/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cda466451816463410fd13477709f561","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230616/","publishdate":"2023-06-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230616/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFARPC 5.10.1 版本发布、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230616/","wordcount":996},{"author":null,"categories":"SOFAStack","content":" 文｜王特 （花名：亦夏）\nEmail：yixia.wt@antgroup.com\n蚂蚁集团数据中间件核心开发\n本文4927 字 阅读 13 分钟\nSeata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。Seata 为用户提供了 AT、TCC、SAGA、XA 等多种事务模式，帮助解决不同业务场景下的事务一致性问题。\n本文主要介绍 Seata Saga 模式的使用以及最佳实践，围绕三个部分展开，第一部分是 Seata Saga 的简介、第二部分旨在快速介绍 Seata Saga 模式的使用方法并帮助大家入门，最后一部分将会给大家分享一些 Seata Saga 实践中的经验，帮助用户更快、更好得使用 Seata Saga 模式。\n1 Seata Saga 简介 1.1 Saga 模式 Saga 模式是分布式事务的解决方案之一，理念起源于 1987 年 Hector \u0026amp;amp; Kenneth 发表的 Sagas 论文。它将整个分布式事务流程拆分成多个阶段，每个阶段对应我们的子事务，子事务是本地事务执行的，执行完成就会真实提交。\n它是一种基于失败的设计，如上图可以看到，每个活动或者子事务流程，一般都会有对应的补偿服务。如果分布式事务发生异常的话，在 Saga 模式中，就要进行所谓的“恢复”，恢复有两种方式，逆向补偿和正向重试。比如上面的分布式事务执行到 T3 失败，逆向补偿将会依次执行对应的 C3、C2、C1 操作，取消事务活动的“影响”。那正向补偿，它是一往无前的，T3 失败了，会进行不断的重试，然后继续按照流程执行 T4、T5 等。\n根据 Saga 模式的设计，我们可以得到 Saga 事务模式的优缺点。\n优点：\n 子事务 （或流程） ，提交是本地事务级别的，没有所谓的全局锁，在长事务流程下，避免了长时间的资源锁定；另外这种流水线的处理模型天然符合阶段式信号处理模型，能发掘出更高的性能和吞吐。 正向服务和补偿服务都是交给业务开发实现的，所以 Saga 模式和底层数据库协议是无关的。XA/AT 模式可能依赖特定的数据库类型和版本，比如 MySQL 是 5.0 之后才支持的 XA，那么低版本的 MySQL 就不能适用到 XA 模式。 缺点：\n 也是因为正向服务和补偿服务都由业务开发者实现，所以业务上是有开发成本的，侵入性相对 XA/AT 打一个注解的方式会高很多。 因为一阶段子事务活动提交是本地事务级别的，所以 Saga 模式不保证隔离性。提交之后就可能“影响”其他分布式事务、或者被其他分布式事务所“影响”。例如：其他分布式事务读取到了当前未完成分布式事务中子事务的更新，导致脏读；其他分布式事务更新了当前未完成分布式事务子事务更新过的字段，导致当前事物更新丢失；还有不可重复读的场景等。 所以 Saga 模式的使用也需要考虑这些问题带来的“影响”。一般 Saga 模式的使用场景有如下几个：\n 长事务流程，业务上难以接受长时间的资源锁定，Saga 的特性使得它在长事务流程上处理非常容易； 业务性质上，业务可以接受或者解决缺乏隔离性导致的“影响”。例如部分业务只要求最终一致性，对于隔离性要求没有那么严格，其实是可以落地 Saga 模式的； 分布式事务参与者包含其他机构或者三方的服务，数据资源服务不是我们自身维护，无法提供 TCC 模式要求的几个接口。 1.2 Seata Saga 接下来我们来看看 Seata Saga 的实现。Saga 主流的实现分为两种：编排式和协调式。Seata Saga 的实现方式是编排式，是基于状态机引擎实现的。 状态机执行的最小单位是节点：节点可以表示一个服务调用，对应 Saga 事务就是子事务活动或流程，也可以配置其补偿节点，通过链路的串联，编排出一个状态机调用流程。在 Seata 里，调用流程目前使用 JSON 描述，由状态机引擎驱动执行，当异常的时候，我们也可以选择补偿策略，由 Seata 协调者端触发事务补偿。\n有没有感觉像是服务编排，区别于服务编排，Seata Saga 状态机是 Saga+服务编排，支持补偿服务，保证最终一致性。\n我们来看看一个简单的状态机流程定义：\n上方是一个 Name 为 reduceIncentoryAndBalance 的状态机描述，里面定了 ServiceTask 类型的服务调用节点以及对应的补偿节点 CompensateReduceInventory。\n看看几个基本的属性：\n Type：节点类型，Seata Saga 支持多种类型的节点。例如 ServiceTask 是服务调用节点 ServiceName/ServiceMethod：标识 ServiceTask 服务及对应方法 Input/Output：定义输入输出参数，输入输出参数取值目前使用的是 SPEL 表达式 Retry：控制重试流程 Catch/Next：用于流程控制、衔接，串联整个状态机流程 更多类型和语法可以参考 Seata 官方文档[1]，可以看到状态机 JSON 声明还是有些难度的，为了简化状态机 JSON 的编写，我们也提供了可视化的编排界面[2]，如下所示，编排了一个较为复杂的流程。\n话不多说，我们进入下面的实践环节。\n2 Seata Saga 使用入门 2.1 从 Seata 官网新人文档开始 Seata 分 TC、TM 和 RM 三个角色，TC （Server 端） 为单独服务端部署，TM 和 RM （Client 端） 由业务系统集成。\nServer 端存储模式 （store.mode） 现有 file、db、redis 三种 （后续将引入 Raft、MongoDB） ，file 模式无需改动，直接启动即可。\n 部署 Seata Server\n从新人文档，可以看出 Seata 还是传统的 CS 模型。首先我们需要部署 Seata Server 端。Server 端默认的存储模式时 file 模式，无需改动，直接执行 SpringBoot 启动类 main 方法即可启动 Seata Server。为了方便，本次演示就使用 file 模式启动，其他模式的启动方式可以参考新人文档的详细介绍。\n创建 Client 端测试应用\n同时我们需要创建一个客户端的测试应用，这里命名 seata-saga-test，测试应用使用 SpringBoot 框架，配置好 spring 的 aplication.pname 和 port，并且引入 seata-spring-boot-starter 依赖，完成 Client 端应用的搭建。\n2.2 从 Seata Saga 单元测试看起 一般了解一个框架的功能，建议是从入口的单元测试类开始看起。在 Seata 仓库中找到 Seata Saga 的 test 模块，从最外围的测试类 io.seata.saga.engine.StateMachineTests 看起 （一般开源项目最外围的测试类即是入口类） ：\n从上面的截图可以看出，入口测试方法主要分为三个部分：\n【1】处的 spring 配置文件声明了 StateMachineEngine Bean 以及对应的属性，【2】处也引用 …","date":1686726000,"description":"Seata Saga 模式快速入门和最佳实践","dir":"blog/seata-saga-model-quick-start-and-best-practices/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7287981b4eabf6ef5f22582a62cd69ff","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","publishdate":"2023-06-14T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","summary":"文｜王特 （花名：亦夏） Email：yixia.wt@antgroup.com 蚂蚁集团数据中间件核心开发 本文4927 字 阅读 13 分钟 Seata 是一款开源的","tags":["SOFAStack"],"title":"Seata Saga 模式快速入门和最佳实践","type":"blog","url":"/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/","wordcount":3753},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n可信基础设施技术分论坛\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：6 月 14 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/f4KJsKNnxfN\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components#888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes#910 How to run layotto with congfig_mongo.json#932 「Layotto」：https://github.com/mosn/layotto/issues/949\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议 时间：06 月 07 日 14:00 - 15:00\n会议内容：\n本次社区会议讨论了开源之夏现阶段导师审核课题的情况，并同步最新进展情况；关于 support pluggable components 与 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes 两个课题，现阶段正常进行中，无风险存在；How to run layotto with congfig_mongo.json 的问题已经解决，具体的解决方案详情可看 issue 或 视频回放。\n「Layotto」：https://github.com/mosn/layotto/issues/937\n「会议回放」：https://www.bilibili.com/video/BV1Pu4y1f7oa/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFAStack 社区本周贡献\n","date":1686294000,"description":"SOFA Weekly｜可信基础设施技术分论坛、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230609/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c2b1e54167604c2f46d7caa6b28da98f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230609/","publishdate":"2023-06-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230609/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜可信基础设施技术分论坛、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230609/","wordcount":781},{"author":null,"categories":"SOFAStack","content":"文｜刘月财（GitHub ID：luky116)\n360 服务端开发专家\nSeata-go 项目负责人\n本文 2752 字 阅读 7 分钟\n发布概览\nSeata-go 1.2.0 版本支持 XA 模式。XA 协议是由 X/Open 组织提出的分布式事务处理规范，其优点是对业务代码无侵入。当前 Seata-go 的 XA 模式支持 MySQL 数据库。至此，Seata-go 已经集齐 AT、TCC、Saga 和 XA 四种事务模式，完成了与 Seata Java 的功能对齐。\nXA 模式的主要功能:\n 支持了 XA 数据源代理\n 支持了 XA 事务模式\n XA 相关的 Samples 可以参考示例：\nhttps://github.com/seata/seata-go-samples/tree/main/xa\n在本版本中还修复了近期大量用户在使用过程中提交的 issue。\n版本的主要更新如下\nFeature：\n[#467] 实现 XA 模式支持 MySQL\nhttps://github.com/seata/seata-go/pull/467\n[#534] 支持 Session 的负载均衡\nhttps://github.com/seata/seata-go/pull/534\nBugfix：\n[#540] 修复初始化 XA 模式的 bug\nhttps://github.com/seata/seata-go/pull/540\n[#545] 修复 XA 模式获取 db 版本号的 bug\nhttps://github.com/seata/seata-go/pull/545\n[#548] 修复启动 XA 时候会失败的 bug\nhttps://github.com/seata/seata-go/pull/548\n[#556] 修复 XA 数据源的 bug\nhttps://github.com/seata/seata-go/pull/556\n[#562] 修复提交 XA 全局事务的 bug\nhttps://github.com/seata/seata-go/pull/562\n[#564] 修复提交 XA 分支事务的 bug\nhttps://github.com/seata/seata-go/pull/564\n[#566] 修复使用 XA 数据源执行本地事务的 bug\nhttps://github.com/seata/seata-go/pull/566\nOptimize：\n[#523] 优化 CI 流程\nhttps://github.com/seata/seata-go/pull/523\n[#525] 将 Jackson 序列化重命名为 JSON\nhttps://github.com/seata/seata-go/pull/525\n[#532] 移除重复的代码\nhttps://github.com/seata/seata-go/pull/532\n[#536] 优化 go import 代码格式\nhttps://github.com/seata/seata-go/pull/536\n[#554] 优化 XA 模式的性能\nhttps://github.com/seata/seata-go/pull/554\n[#561] 优化 XA 模式的日志输出\nhttps://github.com/seata/seata-go/pull/561\nTest:\n[#535] 添加集成测试\nhttps://github.com/seata/seata-go/pull/535\nDoc:\n[#550] 添加 1.2.0 版本的改动日志\nhttps://github.com/seata/seata-go/pull/550\n英文版：https://github.com/seata/seata-go/releases/tag/v1.2.0\n致谢\n非常感谢以下 Contributors 的代码贡献。若有无意遗漏，请报告。\n@georgehao\nhttps://github.com/georgehao\n@luky116\nhttps://github.com/luky116\n@jasondeng1997\nhttps://github.com/jasondeng1997\n@106umao\nhttps://github.com/106umao\n@wang1309\nhttps://github.com/wang1309\n@iSuperCoder\nhttps://github.com/iSuperCoder\n@Charlie17Li\nhttps://github.com/Charlie17Li\n@Code-Fight\nhttps://github.com/Code-Fight\n@Kirhaku\nhttps://github.com/Kirhaku\n@Vaderkai\nhttps://github.com/VaderKai\n同时，我们收到了社区反馈的很多有价值的 issue 和建议，非常感谢大家。\n社区讨论\n加入钉钉群：\nSeata-go 社区群：33069364\nSeata-go 开发群：44816898\n未来展望\nSeata 社区近期与不少国内 Go 语言微服务框架以及 ORM 框架背后的开发社区达成合作，比如 GORM 框架，已经集成到了 Sample 中，后续会将更多的 ORM 框架集成在 Seata-go-samples 项目中。\nSeata-go-samples 集成到 Seata-go GitHub Actions 的集成测试环境，目前已经在进行中，用于测试每个 PR，保证系统的兼容性与稳定性。\nSeata-go 后续的 Saga 模式，计划采用 Temporal 框架来做服务编排，目前正在规划中，期待能给用户带来更实用便利的 Saga 使用体验。\n欢迎对开源感兴趣的朋友加入 Seata 开源建设中来。\n常用链接\nSeata：\nhttp://github.com/seata/seata\nhttps://github.com/seata/seata-php\nhttps://github.com/seata/seata-js\nhttps://github.com/seata/seata-go\nSamples：\nhttps://github.com/seata/seata-samples\nhttps://github.com/seata/seata-go-samples\n官网：\nhttps://seata.io/\n投稿\n欢迎大家将 Seata/Seata-go/Seata-php/Seata-js 相关的实践文章投稿至：https://www.yuque.com/fred-x/ngfgiz/le1h4u5kn0xyhhoh\nSeata Star 一下✨：\nhttps://github.com/seata/seata-go\n","date":1686034800,"description":"生产环境可用的 Seata-go 1.2.0 来啦！！！","dir":"blog/seata-go-1.2.0-available-for-production-environments-is-here/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7df64ba112ba3f76cfa911d05813d383","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","publishdate":"2023-06-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","summary":"文｜刘月财（GitHub ID：luky116) 360 服务端开发专家 Seata-go 项目负责人 本文 2752 字 阅读 7 分钟 发布概览 Seata-go 1.2.0 版本支持 XA 模式。XA 协议是由 X/Open 组织提","tags":["SOFAStack"],"title":"生产环境可用的 Seata-go 1.2.0 来啦！！！","type":"blog","url":"/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/","wordcount":920},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区 活动时间：05 月 31 日，周三晚 19 点 活动形式：线上直播 资料下载：点击获取 B 站直播间地址：http://live.bilibili.com/21954520 B 站直播ID：21954520 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》 Occlum 是蚂蚁集团于 2019 年开源的机密计算操作系统，也是 Linux 基金会机密计算联盟官方项目，荣列 2021“科创中国”开源创新榜。2022 年 12 月 10 日，Occlum 正式发布 v1.0 版本。学术成果发表在 ASPLOS\u0026amp;rsquo;20。Occlum 可让复杂应用轻松获得机密计算能力，是目前业界最受欢迎的开源机密计算操作系统。\nSOFAChannel 第 33 期邀请到了 LibOS 项目的 Contributor 惠春阳来做分享，带大家了解机密计算，讲述 Occlum 如何借助 EDMM，获得更高的安全性、易用性和更极致的性能，成为更好的机密计算 Library OS。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 惠春阳（花名：三仟） 蚂蚁集团技术专家 Occlum 机密计算 LibOS 项目 Contributor 议程 直播回放 点击查看\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1685516400,"description":"SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区","dir":"activities/sofa-channel-33/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"eb7a144641c7fa0312314ecca5edb8cb","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-33/","publishdate":"2023-05-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-33/","summary":"概要 活动主题：SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区 活动时间：05 月 31 日","tags":["SOFAStack"],"title":"SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》——Occlum 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-33/","wordcount":642},{"author":null,"categories":"SOFAStack","content":" 前面几篇介绍了 Envoy Go 扩展的基本用法，接下来几篇将介绍实现机制和原理。\nEnvoy 是 C++ 实现的，那 Envoy Go 扩展，本质上就相当于把 Go 语言嵌入 C++ 里了。\n在 Go 圈里，将 Go 当做嵌入式语言来用的，貌似并不太多见，这里面细节还是比较多的。比如：\n Envoy 有一套自己的内存管理机制，而 Go 又是一门自带 GC 的语言。 Envoy 是基于 libevent 封装的事件驱动，而 Go 又是包含了抢占式的协程调度。 为了降低用户开发时的心智负担，我们提供了三种安全保障。有了这三层保障，用户写 Go 来扩展 Envoy 的时候，就可以像平常写 Go 代码一样简单，而不必关心这些底层细节。\n三种安全 1. 内存安全 用户通过 API 获取到的内存对象，可以当做普通的 Go 对象来使用。\n比如，通过 Headers.Get 得到的字符串，在请求结束之后还可以使用，而不用担心请求已经在 Envoy 侧结束了，导致这个字符串被提前释放了。\n2. 并发安全 当启用协程的时候，我们的 Go 代码将会运行在另外的 Go 线程上，而不是在当前的 Envoy worker 线程上，此时对于同一个请求，则存在 Envoy worker 线程和 Go 线程的并发。\n但是，用户并不需要关心这个细节，我们提供的 API 都是并发安全的，用户可以不感知并发的存在。\n3. 沙箱安全 这一条是针对宿主 Envoy 的保障，因为我们并不希望某一个 Go 扩展的异常，把整个 Envoy 进程搞崩溃。\n目前我们提供的是，Go Runtime 可以 recover 的有限沙箱安全，这通常也足够了。\n更深度的，Runtime 不能 recover 的，比如 Map 并发访问，则只能将 Go So 重载，重建整个 Go Runtime 了，这个后续也可以加上。\n内存安全实现机制 要提供安全的内存机制，最简单的办法，也是*（几乎）*唯一的办法，就是复制。但是，什么时候复制、怎么复制，还是有一些讲究的。这里权衡的目标是降低复制的开销，提升性能。\n这里讲的内存安全，还不涉及并发时的内存安全，只是 Envoy*（C++）*和 Go 这两个语言运行时之间的差异。\nPS：以前用 OpenResty 的时候，也是复制的玩法，只是有一点区别是，Lua String 的 Internal 归一化在大内存场景下，会有相对较大的开销；Go String 则没有这一层开销，只有 Memory Copy + GC 的开销。\n复制时机 首先是复制时机，我们选择了按需复制，比如 Header，Body Data 并不是一开始就复制到 Go 里面，只有在对应的 API 调用时，才会真的去 Envoy 侧获取\u0026amp;amp;复制。\n如果没有被真实需要，则并不会产生复制，这个优化对于 Header 这种常用的，效果倒是不太明显，对于 Body 这种经常不需要获取内容的，效果则会比较的明显。\n复制方式 另一个则是复制方式，比如 Header 获取上，我们采用的是在 Go 侧预先申请内存，在 C++ 侧完成赋值的方式，这样我们只需要一次内存赋值即可完成。\n这里值得一提的是，因为我们在进入 Go 的时候，已经把 Header 的大小传给了 Go，所以我们可以在 Go 侧预先分配好需要的内存。\n不过呢，这个玩法确实有点 tricky，并不是 Go 文档上注明推荐的用法，但是也确实是我们发现的最优的解法了。\n如果按照 Go 常规的玩法，我们可能需要一次半或两次内存拷贝，才能保证安全，这里有个半次的差异，就是我们下回要说的并发造成的。\n另外，在 API 实现上，我们并不是每次获取一个 Header，而是直接一次性把所有的 Header 全复制过来，在 Go 侧缓存了。这是因为大多数场景下，我们需要获取的 Header 数量会有多个，在权衡了 CGO 的调用开销和内存拷贝的开销之后，我们认为一次性全拷贝是更优的选择。\n最后 相对来说，不考虑并发的内存安全，还是比较简单的，只有复制最安全，需要权衡考虑的则更多是优化的事情了。\n比较复杂的还是并发时的安全处理，这个我们下回再聊。\nMOSN Star 一下✨： https://github.com/mosn/mosn\n推荐阅读 MoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\n[MoE 系列（四）｜Go 扩展的异步模式](\n","date":1685430000,"description":"MoE 系列（五）｜Envoy Go 扩展之内存安全","dir":"blog/moe-series (5)｜envoy-go-extensions-memory-security/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1685430000,"objectID":"f5d59dc8bad34c82fb7116161068a117","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","publishdate":"2023-05-30T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","summary":"前面几篇介绍了 Envoy Go 扩展的基本用法，接下来几篇将介绍实现机制和原理。 Envoy 是 C++ 实现的，那 Envoy Go 扩展，本质上就相当于把 Go 语言嵌入 C++ 里了。 在 Go 圈里，将 Go","tags":["SOFAStack"],"title":"MoE 系列（五）｜Envoy Go 扩展之内存安全","type":"blog","url":"/sofastack.tech/blog/moe-series-5envoy-go-extensions-memory-security/","wordcount":1443},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAChannel#33 预告\n**Occlum 是蚂蚁集团于 2019 年开源的机密计算操作系统，也是 Linux 基金会机密计算联盟官方项目，荣列 2021“科创中国”开源创新榜。2022 年 12 月 10 日，Occlum 正式发布 v1.0 版本。学术成果发表在 ASPLOS\u0026amp;rsquo;20。Occlum 可让复杂应用轻松获得机密计算能力，是目前业界最受欢迎的开源机密计算操作系统。\nSOFAChannel 第 33 期邀请到了 LibOS 项目的 Contributor 惠春阳来做分享，带大家了解机密计算，讲述 Occlum 如何借助 EDMM，获得更高的安全性、易用性和更极致的性能，成为更好的机密计算 Library OS。\n本期为 SOFAStack 与博文视点联合举办的机密计算专题，直播中也将抽奖送出《机密计算：AI 数据安全和隐私保护》。欢迎所有对 Occlum、机密计算、TEE 感兴趣的小伙伴们一起来听直播！🧸\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 24 日 14:00 - 15:00\n会议内容：\n随着本周社区会议的召开，社区同学讨论了如何为 Configure API 开发 Nacos 组件问题。会议同步了开源之夏的学生招募进展，以及在课题沟通时推进了 Layotto 目前能够解决的问题，并进一步讨论了版本优化的方法。\n「Layotto」：https://github.com/mosn/layotto/issues/931\n「会议回放」：https://www.bilibili.com/video/BV1XM4y1v7A9/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 31 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题汇总#894 为 Configure API 开发 Nacos 组件#921 Support Pluggable Components#888 Support Pod Injection to deploy Layotto as a sidecar in Kubernetes#910 「Layotto」：https://github.com/mosn/layotto/issues/931\nSOFAStack 社区本周贡献\n本周推荐阅读\n直播预告 | SOFAChannel#33《Occlum x EDMM=更安全好用的机密计算 LibOS》\nMOSN 基于延迟负载均衡算法——走得更快，期待走得更稳\nMoE 系列（四）｜Go 扩展的异步模式\nSOFAServerless 体系助力业务极速研发\n","date":1685084400,"description":"SOFA Weekly｜SOFAChannel#33 直播预告、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230526/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6ce1b77204d6ef8dfa8d2dcae4a65d59","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230526/","publishdate":"2023-05-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230526/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAChannel#33 直播预告、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230526/","wordcount":1186},{"author":null,"categories":"SOFAStack","content":" 文｜纪卓志（GitHub ID：jizhuozhi)\n京东高级开发工程师\nMOSN 项目 Committer\n专注于云原生网关研发的相关工作，长期投入在负载均衡和流量控制领域\n前言 这篇文章主要是介绍 MOSN 在 v1.5.0 中新引入的基于延迟的负载均衡算法#2253。首先会对分布式系统中延迟出现的原因进行剖析，之后介绍 MOSN 都通过哪些方法来降低延迟，最后构建与生产环境性能分布相近的测试用例来对算法进行验证。\n在开始聊基于延迟的负载均衡算法之前，我们先介绍下什么是负载均衡。\n什么是负载均衡 Wikipedia中 Load Balancing (Computing) 词条是这样介绍负载均衡的：\n 负载均衡是将一组任务分配到一组资源（计算单元）上的过程，目的是使它们的整体处理更有效率。负载均衡可以优化响应时间，避免负载不均匀导致一些计算节点过载而其他计算节点处于空闲状态\n 负载均衡在大型分布式系统中是关键的组成部分。负载均衡解决了分布式系统中最重要的两个问题：可伸缩性*（Scalability）*和韧性*（Resilience）*。\n 可伸缩性：应用程序部署在多个相同的副本中。当计算资源不足时可以通过部署额外的副本来增加计算资源，而当计算资源大量冗余时可以通过减少副本来节省成本。通过负载均衡可以将请求负载分布到不同的副本中。\n 韧性：分布式系统的故障是部分的。应用程序通过冗余副本的方式，保证在部分组件故障时仍能正常地提供服务。负载均衡通过感知节点的故障，调整流量的分配，将流量更多的分配到那些能够正常提供服务的节点上。\n 走得更快 负载均衡使得现代软件系统具备了可扩展性和韧性。但在分布式系统中还存在不容忽视的问题：延迟。\n延迟来自哪里 现代软件系统通常是多层级结构大型分布式系统，即使是只服务单个终端用户的请求，它背后也有可能经过了上百次的数据访问，这种情况在微服务架构中更是尤为普遍。\n微服务架构（引用自 Microservices Pattern）\n单台性能稳定的服务器中延迟通常由以下几个方面造成：\n 计算任务本身的复杂度 内容的传输过程中的延迟 请求排队等待的延迟 后台任务活动所导的资源竞争 这些服务器之间的延迟将会叠加，任何显著的延迟增加都会影响终端用户的体验。此外，任何来自单个节点的延迟峰值也会直接影响到终端用户体验。同时越来越多地使用公有云部署应用程序也进一步加剧了响应时间的不可预测性。因为在这些环境中存在共享资源*（CPU、内存和 IO）*的争用，应用程序机几乎不可避免地遇到性能影响，而这种影响是随时发生的。\n如何减少延迟 有研究表明，在大型互联网应用中，延迟往往具有长尾特点，P99 比中位数高出几个数量级。如果在应用架构的每层都能够减少这些尾部延迟，那么对终端用户整体的尾部延迟将会显著降低。\n在服务网格中，所有接收和发送的流量都会经过边车代理，通过边车代理可以轻松地控制网格的流量，而无需对服务进行任何修改。如果边车代理在对应用层流量进行转发时，总是通过负载均衡时选择响应时间较短的服务器，那么将会显著降低对终端用户的尾部延迟。\n基于此，我们准备开始为 MOSN 引入基于延迟的负载均衡算法，并进行适当调整来保证能够在大多数使用场景下显著减少延迟。\n性能问题是局部的 前面提到了，每个节点的性能受到多种因素的影响，这些影响因素是动态的，难以准确预测每个节点的性能，因此我们无法精确地选择最好的节点，但是可以避免较差的节点。\n在云环境中，服务器的性能常常是难以预测的，但是我们可以通过对大量的数据进行分析，发现服务器性能的分布大多数情况下是符合正态分布的。因此，尽管有一部分的服务器在性能方面表现比较差，它们的数量通常都是少数的*（3Sigma）*，而绝大部分服务器节点的表现是正常的。\n除了服务器之间的差异，还存在由基础设施导致的动态延迟，这种延迟可能是由于网络拥塞、故障或不断增长的流量所导致。这种延迟通常具有持续性和局部性：持续性则表示延迟会长时间存在，不会在短时间内消失；而局部性指的是延迟往往只出现在某些特定服务器上，而不会在全局发生。\nPeakEWMA 面对这些问题，我们使用 Peak EWMA*（Peak Exponentially Weighted Moving Average）*计算响应时间指标，并根据这个指标来对节点进行负载均衡。\nEWMA 是一种动态权重调整算法，各数值的加权影响力随时间而指数式衰退，越近期的数据加权影响力越重，但较旧的数据也给予一定的加权值。\n它以相对较高的权重考虑了最近响应时间的影响，因此更具有针对性和时效性。加权的程度以常数 𝛼 决定，𝛼 数值介于 0 至 1，它用来控制数据加权影响力衰退的速率。\n作为一种统计学指标，EWMA 的计算过程不需要大量的采样点以及时间窗口的设定，有效地避免了计算资源的浪费，更适合在 MOSN 这样的边车代理中使用。\n由于响应时间是历史指标，当服务器出现性能问题导致长时间未返回时，负载均衡算法会错误地认为这台服务器仍是最优的，而不断地向其发送请求而导致长尾延迟增高。我们使用活跃连接数作为实时变化的指标对响应时间进行加权，表示等待所有活跃的连接都返回所需要的最大时间。\nP2C（Power of Two Choice） 在大规模集群中，如果使用遍历所有服务器选择最好的服务器的方法，虽然可以找到最轻负载的服务器来处理请求，但这种方法通常需要大量的计算资源和时间，因此无法处理大规模的请求。因此，我们使用 P2C 来选择最优节点。相比之下，P2C 算法可以在常数时间内选择两个服务器进行比较，并选择其中负载更轻的服务器来处理请求。P2C 基于概率分配，即不直接基于权重分配，而是根据每个服务器优于其他服务器的概率值来决定请求的分配。\n此外，在多个负载均衡器的情况下，不同负载均衡器可能会有不同的节点视图，这可能导致某些负载均衡器选择的最优节点总是最差的节点。这是因为负载均衡器选择最优节点时基于自己的视图信息，而节点视图随着时间的变化可能会发生变化，因此不同的负载均衡器选择的最优节点也可能不同。P2C 算法通过对随机选择的两个节点进行比较，可以使节点间的负载均衡更加均匀，即使节点视图发生变化，也能提供稳定的负载均衡效果。\n 在 MOSN 的 v1.5.0 版本中，只有节点权重相同时会使用 P2C，当权重不同时会使用 EDF 进行加权选择。后续会提供可配置的选项。\n 模拟流量验证 我们构建了与生产环境性能分布相近的测试用例来对算法进行验证。\n首先我们使用正态分布生成了 10 台服务器的基准性能，其中数学期望为 50ms，标准差为 10ms。接下来，我们将这些基准性能作为数学期望，并以标准差为 5ms 的正态分布随机生成了请求延迟，以模拟真实世界的情况。此外，我们还在其中一台服务器注入了概率为 0.1 的故障，故障发生时会产生 1000ms 的延迟，以测试系统的容错性。\n为了模拟请求倾斜时请求排队等待的延迟，我们限制了每台服务器的最大并发数为 8，当同时处理的最大请求数超过了最大并发数时，将会排队等待。这样能够更加真实地模拟出系统的运行情况。\n最后，我们使用了 Round Robin、Least Request 和 Peak EWMA 三 …","date":1684825200,"description":"MOSN 基于延迟负载均衡算法——走得更快，期待走得更稳","dir":"blog/mosn-delay-based-load-balancing-algorithm-go-faster, expect-to-go-steadier/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4ed40af7694979d98879f50bcaf9093c","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","publishdate":"2023-05-23T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","summary":"文｜纪卓志（GitHub ID：jizhuozhi) 京东高级开发工程师 MOSN 项目 Committer 专注于云原生网关研发的相关工作，长期投入在负载均衡和流量控制领域","tags":["SOFAStack"],"title":"MOSN 基于延迟负载均衡算法——走得更快，期待走得更稳","type":"blog","url":"/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/","wordcount":3277},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 大事记\nQCon 是由极客邦科技旗下 InfoQ 中国主办的综合性技术盛会，每年在伦敦、北京、纽约、圣保罗、上海、旧金山召开。自 2007 年 3 月份首次举办以来，已有超万名高级技术人员参加过 QCon 大会。QCon 内容源于实践并面向社区，演讲嘉宾依据热点话题，面向 5 年以上工作经验的技术团队负责人、架构师、工程总监、高级开发人员分享技术创新和典型实践。\n2023 年 5 月 26 日-27 日，QCon 广州站邀请了 MOSN 项目核心开发者、蚂蚁集团技术专家朱德江，将现场分享 《解密 MoE：将 Golang 嵌入 Envoy（C++）》。扫描上图二维码可参与报名。\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 17 日 14:00 - 15:00\n会议内容：\n随着本周社区会议的召开，社区同学进一步探讨了 Layotto 兼容 Dapr 的组件问题，解决思路逐渐清晰；对于如何使 Layotto 提供高性能的通信交互能力，社区同学将此问题与开源之夏的课题进行结合，并确定了版本优化的方向。\n「Layotto」：https://github.com/mosn/layotto/issues/929\n「会议回放」：https://www.bilibili.com/video/BV1Go4y1F7wo/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 社区会议\n时间：5 月 24 日 14:00 - 15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题汇总 #894\n Discussion：自建各种 Component #902\n 希望 Layotto 提供高性能的通信交互能力 #867\n 「Layotto」：https://github.com/mosn/layotto/issues/929\nSOFAStack 社区本周贡献\n本周推荐阅读\nMoE 系列（四）｜Go 扩展的异步模式\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\n【开源之夏 2023】欢迎报名 MOSN 社区项目！\n【开源之夏 2023】欢迎报名 SOFAStack 社区项目！\n","date":1684479600,"description":"SOFA Weekly｜SOFA 大事记、Layotto 社区会议回顾与预告、社区本周贡献","dir":"blog/sofa-weekly-230519/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bd81b1b8854e7bc553af2531bbdbe44a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230519/","publishdate":"2023-05-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230519/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 大事记、Layotto 社区会议回顾与预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230519/","wordcount":1102},{"author":null,"categories":"SOFAStack","content":"在《MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置》中我们体验了用 Istio 做控制面，给 Go 扩展推送配置，这次我们来体验一下，在 Go 扩展的异步模式下，对 Goroutine 等全部 Go 特性的支持。\n异步模式\n之前，我们实现了一个简单的 Basic Auth[1]，但是，那个实现是同步的，也就是说，Go 扩展会阻塞，直到 Basic Auth 验证完成，才会返回给 Envoy。\n因为 Basic Auth 是一个非常简单的场景，用户名密码已经解析在 Go 内存中了，整个过程只是纯 CPU 计算，所以，这种同步的实现方式是没问题的。\n但是，如果我们要实现一个更复杂的需求，比如，我们要将用户名密码调用远程接口查询，涉及网络操作，这个时候，同步的实现方式就不太合适了。因为同步模式下，如果我们要等待远程接口返回，Go 扩展就会阻塞，Envoy 也就无法处理其他请求了。\n所以，我们需要一种异步模式：\n 我们在 Go 扩展中，启动一个 Goroutine，然后立即返回给 Envoy，当前正在处理的请求会被挂起，Envoy 则可以继续处理其他请求。 Goroutine 在后台异步执行，当 Goroutine 中的任务完成之后，再回调通知 Envoy，挂起的请求可以继续处理了。 注意：虽然 Goroutine 是异步执行，但是 Goroutine 中的代码，与同步模式下的代码，几乎是一样的，并不需要特别的处理。\n为什么需要\n为什么需要支持 Goroutine 等全部 Go 的特性呢？\n有两方面的原因：\n 有了 Full-feature supported Go，我们可以实现非常强大、复杂的扩展。 可以非常方便的集成现有 Go 世界的代码，享受 Go 生态的红利。 如果不支持全部的 Go 特性，那么在集成现有 Go 代码的时候，会有诸多限制，导致需要重写大量的代码，这样，就享受不到 Go 生态的红利了。\n实现\n接下来，我们还是通过一个示例来体验，这次我们实现 Basic Auth 的远程校验版本，关键代码如下：\nfunc (f *filter) DecodeHeaders(header api.RequestHeaderMap, endStream bool) api.StatusType { go func() { // verify 中的代码，可以不需要感知是否异步 // 同时，verify 中是可以使用全部的 Go 特性，比如，http.Post if ok, msg := f.verify(header); !ok { f.callbacks.SendLocalReply(401, msg, map[string]string{}, 0, \u0026amp;quot;bad-request\u0026amp;quot;) return } // 这里是唯一的 API 区别，异步回调，通知 Envoy，可以继续处理当前请求了 f.callbacks.Continue(api.Continue) }() // Running 表示 Go 还在处理中，Envoy 会挂起当前请求，继续处理其他请求 return api.Running } 再来看 verify 的代码，重点是，我们可以在这里使用全部的 Go 特性：\n// 这里使用了 http.Post func checkRemote(config *config, username, password string) bool { body := fmt.Sprintf(`{\u0026amp;quot;username\u0026amp;quot;: \u0026amp;quot;%s\u0026amp;quot;, \u0026amp;quot;password\u0026amp;quot;: \u0026amp;quot;%s\u0026amp;quot;}`, username, password) remoteAddr := \u0026amp;quot;http://\u0026amp;quot; + config.host + \u0026amp;quot;:\u0026amp;quot; + strconv.Itoa(int(config.port)) + \u0026amp;quot;/check\u0026amp;quot; resp, err := http.Post(remoteAddr, \u0026amp;quot;application/json\u0026amp;quot;, strings.NewReader(body)) if err != nil { fmt.Printf(\u0026amp;quot;check error: %v\\n\u0026amp;quot;, err) return false } if resp.StatusCode != 200 { return false } return true } // 这里操作 header 这个 interface，与同步模式完全一样 func (f *filter) verify(header api.RequestHeaderMap) (bool, string) { auth, ok := header.Get(\u0026amp;quot;authorization\u0026amp;quot;) if !ok { return false, \u0026amp;quot;no Authorization\u0026amp;quot; } username, password, ok := parseBasicAuth(auth) if !ok { return false, \u0026amp;quot;invalid Authorization format\u0026amp;quot; } fmt.Printf(\u0026amp;quot;got username: %v, password: %v\\n\u0026amp;quot;, username, password) if ok := checkRemote(f.config, username, password); !ok { return false, \u0026amp;quot;invalid username or password\u0026amp;quot; } return true, \u0026amp;quot;\u0026amp;quot; } 另外，我们还需要实现一个简单的 HTTP 服务，用来校验用户名密码，这里就不展开了，用户名密码还是 foo:bar。\n完整的代码，请移步 Github[2]。\n测试\n老规矩，启动之后，我们使用 curl 来测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; HTTP/1.1 401 Unauthorized # valid foo:bar $ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39; HTTP/1.1 200 OK 依旧符合预期。\n总结\n在同步模式下，Go 代码中常规的异步非阻塞也会变成阻塞执行，这是因为 Go 和 Envoy 是两套事件循环体系。\n而通过异步模式，Go 可以在后台异步执行，不会阻塞 Envoy 的事件循环，这样，就可以用上全部的 Go 特性了。\n由 …","date":1684220400,"description":"MoE 系列（四）｜Go 扩展的异步模式","dir":"blog/moe-series (4)-go-extended-asynchronous-mode/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"34088a54a5896da249c7fab7e02b446e","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","publishdate":"2023-05-16T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","summary":"在《MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置》中我们体验了用 Istio 做控制面，给 Go 扩展推送配置，这次我们来体验一下，在 Go 扩展的异步模式下，对 Goroutine 等","tags":["SOFAStack"],"title":"MoE 系列（四）｜Go 扩展的异步模式","type":"blog","url":"/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/","wordcount":1459},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议回顾\nSOFAArk：\n主题：SOFAArk 社区会议（月会）\n时间：5 月 8 日 20:00 - 21:30\n会议内容：\n本次社区会议根据议题介绍了近期 SOFAArk 2.2.0 版本发布计划，更新内容预计包含支持 JDK 17 模式下运行、依据 JarLocation 解析 BUG 修复、Benchmark 的一期建设；会议同步了非迭代 issue 进展，包括搭建 SOFAArk Windows 环境 CI、修复因文件路径不支持跨平台导致的资源加载失败问题；介绍了今年开源之夏 SOFAArk 提交的两个项目，邀请社区同学关注与参与；最后，大家一起讨论了 GPT 在 SOFA 工程领域的探索，目前开发同学正在建设基于 ChatGPT + LangChain 的基础工具链，会议中也邀请了社区同学一起共建。\n「会议纪要」：https://github.com/sofastack/sofa-ark/issues/636\n「会议回放」：https://www.bilibili.com/video/BV1Qs4y1D7Lv/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 2023-05-17 社区会议\n时间：5 月 17 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题:\n 2023 开源之夏-课题汇总#894 Discussion：自建各种 Component#902 希望 Layotto 提供高性能的通信交互能力#867 CLA 机器人问题同步 「Layotto」：https://github.com/mosn/layotto/issues/920\nSOFAStack 社区本周贡献\n本周推荐阅读\n【开源之夏 2023】欢迎报名 SOFAStack 社区项目！\n【开源之夏 2023】欢迎报名 MOSN 社区项目！\nKCL v0.4.6 重磅发布！全新的 IDE 插件，Helm/Kustomize/KPT 工具集成\n恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n","date":1683874800,"description":"SOFA Weekly｜SOFAArk 社区会议回顾、Layotto 社区会议预告、社区本周贡献","dir":"blog/sofa-weekly-230512/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3897039aee7e06226e62c5d248b6a953","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230512/","publishdate":"2023-05-12T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230512/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAArk 社区会议回顾、Layotto 社区会议预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230512/","wordcount":1029},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\nDragonfly 项目介绍\nDragonfly 是一个基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱项目 （Sandbox） 。2020 年 4 月，CNCF 技术监督委员会 （TOC） 投票决定接受 Dragonfly 作为孵化项目 （Incubating） 。经过多年生产实践经验打磨的下一代产品，汲取了 Dragonfly 1.x 的优点并针对已知问题做了大量的优化，在解决大规模文件分发场景下有着无可比拟的优势。基于 P2P 技术的优势，在 AI Inference 分发模型场景可以解决大文件分发过程中的性能瓶颈。并且可以通过集成 Dragonfly P2P 技术减少源站压力，提高模型分发效率。在未来，Dragonfly 会结合 AI 领域生态进行拓展，服务 AI 领域并且成为其重要基础设施。\nKata Containers 项目介绍\n自 2013 年 Docker 问世以来，容器技术立刻让全球的开发者为之着迷，并逐渐成为现代应用程序、构建、发布和运维的主流方式。容器以标准格式对应用程序进行封装，应用程序可从一个计算环境快速、安全地切换到另一个计算环境，这对于想要快速构建、测试和部署软件的开发者而言至关重要。然而传统的以 runC 为代表的容器方案基于共享内核技术，通过 Linux 提供的 Cgroups 和 Namespace 等方案进行隔离和控制，如果某一容器中的恶意程序利用了系统缺陷从容器中逃逸，则会对宿主机系统构成严重威胁。尤其是在公有云环境，这一潜在威胁成为了容器技术普及和落地的一大障碍。如果将不同容器再嵌套放入到不同的虚拟机，通过增加一层相对安全、成熟的隔离技术，就能大大提高系统的安全性，减少系统被攻破的可能。基于这种思想的开源技术也随之出现，代表性的两个项目为 Intel 开源技术中心的 Clear Containers 和 Hyper.sh 的 runV。2017 年，这两个开源项目合并，共同创建了开源项目 Kata Containers，其目标是将虚拟机的安全优势与容器的高速及可管理性相结合，为用户提供标准化、安全、高性能的容器解决方案。Kata Containers 创建的不同 Pod （容器） 运行在不同的虚拟机 （Kernel） 之中，比传统容器提供了更好的隔离性和安全性，同时继承了容器快速启动和标准化等优点。\nNydus 项目介绍\n镜像是容器基础设施中的一个重要部分，目前 OCI 标准镜像的缺陷之一是容器需要等待整个镜像数据下载完成后才能启动，这导致了容器启动时消耗了过多的端到端时间。在大规模集群场景下，这对网络与存储负载的影响尤为明显。Nydus 镜像加速框架提供了容器镜像按需加载的能力，它在生产环境里支撑了每日百万级别的加速镜像容器创建，将容器端到端冷启动时间从分钟级降低到了秒级。Nydus 目前由蚂蚁集团，阿里云，字节跳动联合研发，与内核态 EROFS 做了深度集成，也是 Kata Containers 与 Linux 内核态原生支持的镜像加速方案。目前 Nydus 已经被容器生态主流项目支持，例如 Containerd，Docker，Podman，BuildKit, Nerdctl，Kata Containers。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nDragonfly 社区项目\n项目链接： https://summer-ospp.ac.cn/org/orgdetail/72e6f975-d2b8-4fa3-a377-441c1038db10?lang=zh\nPyTorch Serve 基于 Dragonfly P2P 技术分发模型\n导师： yxxhero\n邮箱： aiopsclub@163.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0132?list=org\u0026amp;amp;navpage=org\nTensorFlow Serving 基于 Dragonfly P2P 技术分发模型\n导师： 崔大钧\n邮箱： bigerous@qq.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0022?list=org\u0026amp;amp;navpage=org\nTriton Inference Server 基于 Dragonfly P2P 技术分发模型\n导师： 戚文博\n邮箱： gaius.qi@gmail.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/2372e0001?list=org\u0026amp;amp;navpage=org\nKata Containers 社区项目\n项目链接： https://summer-ospp.ac.cn/org/orgdetail/301597a0-ca46-418a-89d1-13ea3c050ee9?lang=zh\n基于 VSOCK FD Passthrough 对 Container IO Stream 进行重构\n导师： 李福攀\n邮箱： fupan.lfp@antgroup.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010451?list=org\u0026amp;amp;navpage=org\nNydus RAFS v6 guest 内核支持优化\n导师： 李亚南\n邮箱： alex.lyn@antgroup.com\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010419?list=org\u0026amp;amp;navpage=org\n跨容器 shared-mount 支持\n导师： 彭涛\n邮箱： bergwolf@hyper.sh\n项目难度： 进阶/Advanced\n项目链接： https://summer-ospp.ac.cn/org/prodetail/233010417?list=org\u0026amp;amp;navpage=org\nNydus 社区项目\n项目链接： …","date":1683788400,"description":"【开源之夏 2023】欢迎报名 Dragonfly、Kata Containers、Nydus 社区项目！","dir":"activities/[Summer-2023-of-open-source-promotion-plan]welcome-to-register-for-dragonfly,kata-containers,and-nydus-community-projects!/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d417195ca31984354ab9fba0f7f2cefe","permalink":"https://sofastack.github.io/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","publishdate":"2023-05-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["开源之夏"],"title":"【开源之夏 2023】欢迎报名 Dragonfly、Kata Containers、Nydus 社区项目！","type":"activities","url":"/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/","wordcount":2002},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2023 年，MOSN 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2023”，为大家准备了三个任务，涉及 Go、HTTP、Security、Software-Defined Networking、Container 等多个领域。\nMOSN 项目介绍\nMOSN*（Modular Open Smart Network）*是一款基于 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并在双 11 大促期间经过几十万容器的生产级验证。MOSN 为服务提供多协议、模块化、智能化、安全的代理能力，融合了大量云原生通用组件，同时也可以集成 Envoy 作为网络库，具备高性能、易扩展的特点。另外，MOSN 可以集成 Istio 构建 Service Mesh，也可以作为独立的四、七层负载均衡，API Gateway、云原生 Ingress 等使用。\nLayotto 项目介绍\nLayotto（/leɪˈɒtəʊ/） 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，例如状态管理、配置管理、事件发布订阅等，以简化应用的开发。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nMOSN 社区项目\n项目链接：https://summer-ospp.ac.cn/org/orgdetail/f0813e66-fa19-4302-a3e3-e6f2d210c83d?lang=zh\nMOSN\nGo、HTTP、Security\n项目社区导师：罗泽轩\nspacewanderlzx@gmail.com\n基于 Coraza 和 MOSN on Envoy 开发 Envoy 的 WAF 插件\n项目编号：23f080212\n项目难度：进阶/Advanced\nCoraza 是一个用 Go 实现的 WAF 引擎，我们希望能够借助 MOSN on Envoy 的能力，让 Coraza 运行在 Envoy 当中，并与官方的基于 Wasm 的实现*（https://github.com/corazawaf/coraza-proxy-wasm）*进行比较。\n 实现一个基本可用的 WAF 插件*（需要有详尽的文档+测试）*，并与 Wasm 版本做对比，输出一份比较报告。 了解 MOSN、Envoy 和 WAF，能够用 Go 写代码。 MOSN\nGo、Software-Defined Networking\n项目社区导师：纪卓志\njizhuozhi.george@gmail.com\n为 Envoy Go 扩展建设插件市场\n项目编号：23f080259\n项目难度：进阶/Advanced\nEnvoy 是当前最流行的网络代理之一，Go 扩展是 MOSN 社区为 Envoy 增加的 Go 生态基础，也是 MOSN 社区 MoE 框架的基础。\n受益于 Golang 生态系统，研发可以轻松在 Envoy 实现插件用于更多的长尾场景，其中很多场景都是通用的。\n本项目是为 Envoy Go 扩展构建插件市场。在插件市场中，人们可以在插件市场中分享插件，选用已经存在的插件。通过插件市场，可以让 Envoy、MoE 生态变得更加开放、共享、丰富。\n 提供一个 Envoy Go 插件的内容平台，在这里可以发布经过社区 Review 的优秀插件，需要拥有服务端与前端页面。\n 不自建账号体系，通过 GitHub OAuth2.0 完成用户认证与授权。\n 进阶——对接 GitHub OpenAPI，支持动态获取插件所在仓库信息，包括 README、分支版本以及 Star 数。\n 能够使用 Go 语言*（框架不限）*开发出带前端页面的小型站点。\n 对认证与授权及 OAuth2.0 有基本的了解。\n 熟悉 Git 和 GitHub 工作流程*（分支、版本、合并请求等）*。\n Layotto\nGo、gRPC\n项目社区导师：wenxuwan\nwangwenxue.wwx@antgroup.com\nLayotto Support Pluggable Components\n项目编号：23f080194\n项目难度：进阶/Advanced\n当前 Layotto 的 Components 都是实现在 Layotto 的工程里面的。用户若要想使用新的 Component，就必须使用 Golang 语言开发，同时必须在 Layotto 工程中实现，然后统一编译。对于多语言用户来说非常不友好，因此 Layotto 需要提供 Pluggable Components 的能力，允许用户可以通过任何语言实现自己的 Components，Layotto 通过 gRPC 协议和外部的 Components 进行通信。\n 完成 Pluggable Components 框架设计。\n 提供 Pluggable Components 接入文档和示例。\n 熟悉 Golang 和 gRPC，熟悉 Dapr 和 Layotto 运行时架构。\n 申请资格\n 本活动面向年满 18 周岁在校学生。\n 暑期即将毕业的学生，只要在申请时学生证处在有效期内，就可以提交申请。\n 中国籍学生参与活动需提供身份证、学生证、教育部学籍在线验证报告（学信网）或在读证明。\n 外籍学生参与活动需提供护照，同时提供录取通知书、学生卡、在读证明等文件用于证明学生身份。\n 活动流程\n添加 SOFAGirl 微信\n备注“开源之夏”进群交流\n","date":1683615600,"description":"【开源之夏 2023】欢迎报名 MOSN 社区项目！","dir":"activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project!/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1bdbf9f33dd6670508117cc1e5e907df","permalink":"https://sofastack.github.io/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","publishdate":"2023-05-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["开源之夏"],"title":"【开源之夏 2023】欢迎报名 MOSN 社区项目！","type":"activities","url":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/","wordcount":1852},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nSOFAArk：\n主题：SOFAArk 2023-05-08 社区会议\n时间：5 月 8 日（下周一）20:00-21:30\n入会口令（钉钉）：683 550 26227\n电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题：\n 近期版本发布计划和内容 非迭代 issue 处理同步 开源之夏活动介绍 GPT 在 SOFA 工程领域的探索 「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/636\nLayotto：\n主题：Layotto 2023-05-10 社区会议\n时间：5 月 10 日（下周三）14:00-15:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/07I8wgAxaS6\n议题：\n 2023 开源之夏-课题/导师招募 Discussion：自建各种 Component 希望 Layotto 提供高性能的通信交互能力 CLA 机器人问题同步 「Layotto」：https://github.com/mosn/layotto/issues/915\nMOSN 社区：\n 基于 coraza 和 MOSN on Envoy 开发 Envoy 的 WAF 插件 导师：罗泽轩\n联系邮箱：spacewanderlzx@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080212?lang=zh\u0026amp;amp;list=pro\n 为 Envoy Go 扩展建设插件市场 导师：纪卓志\n联系邮箱：jizhuozhi.george@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080259?list=org\u0026amp;amp;navpage=org\nLayotto 社区：\n Layotto 支持自动/手动注入 Pod 部署 导师：刘训灼\n联系邮箱：mixdeers@gmail.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/2395a0359?list=org\u0026amp;amp;navpage=org\n Layotto Support Pluggable Components 导师：王文学\n联系邮箱：wangwenxue.wwx@antgroup.com\n项目链接：\nhttps://summer-ospp.ac.cn/org/prodetail/23f080194?list=org\u0026amp;amp;navpage=org\n社区本周贡献\n本周推荐阅读\nMoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\n如何看待 Dapr、Layotto 这种多运行时架构？\n应用运行时 Layotto 进入 CNCF 云原生全景图\n","date":1683270000,"description":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","dir":"blog/sofa-weekly-0505/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d9d0126ce61dc5e57710e2db403ca34e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0505/","publishdate":"2023-05-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0505/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜开源之夏 MOSN 与 Layotto 项目简介、社区会议预告、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0505/","wordcount":1039},{"author":null,"categories":"开源之夏","content":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2023 年，SOFAStack 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2023”，一共为大家准备了五个任务，涵盖 SOFARPC、SOFAArk、SOFAJRaft 和 Layotto 等核心项目，涉及 Golang、Java、Kubernetes、Cloud Native、Distributed System 等多个领域。\nSOFARPC 项目介绍\nSOFARPC 是由蚂蚁集团开源的一款 Java RPC 框架，具有高可扩展性、高性能和生产级特性。该框架旨在简化应用之间的 RPC 调用，并为应用提供便捷透明、稳定高效的点对点远程服务调用方案。为方便用户和开发者进行功能扩展，SOFARPC 提供了丰富的模型抽象和可扩展接口，包括过滤器、路由、负载均衡等。\nSOFAArk 项目介绍\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，由蚂蚁集团开源贡献。该容器主要提供类隔离和应用（模块）合并部署能力。SOFAArk 提供多种方式来支持多应用（模块）合并部署，包括基于命令行的管控、基于 API 的管控等。\nSOFAJRaft 项目介绍\nSOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，适用于高负载低延迟的场景，支持 MULTI-RAFT-GROUP。使用 SOFAJRaft 可专注于业务领域，由 SOFAJRaft 解决与 RAFT 相关的技术难题。并且 SOFAJRaft 易于使用，可以通过几个示例快速掌握它。\nLayotto 项目介绍\nLayotto(/leɪˈɒtəʊ/) 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。它为应用提供了各种分布式能力，例如状态管理、配置管理、事件发布订阅等，以简化应用的开发。\n活动规则\n开源之夏官网：\nhttps://summer-ospp.ac.cn/\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\nSOFAStack 社区项目\n项目链接：https://summer-ospp.ac.cn/org/orgdetail/95a9e459-a200-4a26-bc0a-81074c2d89be?lang=zh\nSOFARPC\nJava、网络通信、RPC\n项目社区导师：EvenLiu\nevenljj@163.com\nSOFARPC 支持 Stream 流式处理方式\n项目编号：2395a0260\n项目难度：进阶/Advanced\nStream 方式是一种异步的流式处理方式，可以在数据传输过程中逐个处理数据，避免一次性传输大量数据造成的性能问题。服务端 Stream 是指服务端在处理请求时，将数据分成多个部分逐个返回给客户端的过程；客户端 Stream 是指客户端在请求服务器时，将请求参数分成多个部分逐个发送给服务器的过程。Stream 方式可以让我们在处理大量数据时更高效地使用资源，提高系统的性能和响应速度。SOFARPC 中需要 Triple、Bolt 协议支持 Stream 方式流式处理。\n SOFARPC 中 Triple 协议支持 Stream 流式处理。\n SOFARPC 中 Bolt 协议支持 Stream 流式处理。\n SOFAArk\nJava、SOFAArk 源代码\n项目社区导师：卫恒\nglmapper_2018@163.com\n开发一个客户端，支持 Biz 模块的热部署和热卸载，初步实现 Serverless 体验\n项目编号：2395a0267\n项目难度：基础/Basic\nSOFAArk 从最初的一个类隔离框架，逐步演进为支持合并部署与热部署的 “Serverless” 运行时框架，尤其在去年我们完成了 SOFAArk1.0 到 2.0 架构的演进。但是为了让开发者真正享受 Serverless 的研发体验，我们还需要建设一个客户端框架，对接 SOFAArk 实现 Biz 模块的热部署和热卸载，并暴露 HTTP API 接口可以让上游系统或者开发者直接使用。\n 设计并开发一个新的 SDK（SOFALet），新的 SDK 也就是 SOFALet 暴露一组 HTTP 接口，底层调用 SOFAArk 原子能力实现模块的热部署和热卸载。SOFALet 未来还会有 Node.js 版，这一期先支持 Java 版也就是对接 SOFAArk。\n 理解 SOFAArk 源代码，尤其是关于 telnet 指令安装和卸载模块的部分。\n SOFAArk\nGo、K8s\n项目社区导师：流铄\nxujinle300@126.com\n开发一个 K8s Operator，编排客户端 API 实现 Biz 模块的热部署，初步达成 Serverless 研发体验\n项目编号：2395a0392\n项目难度：基础/Basic\n为了让开发者真正享受 Serverless 的研发体验，我们需要先建设一个简易的 K8s Operator 和 SOFA Module Deployment、SOFA Module ReplicaSet CRD，对接编排模块热装载和热卸载的客户端，实现模块秒级发布的初步能力，让开发者能初步体验到 Serverless 的发布运维能力。\n 理解 SOFAArk 模块安装和卸载部分的源代码，并且熟悉 K8s CRD 和 Operator 体系的设计与开发。 SOFAJRaft\nJava、网络通信、RPC\n项目社区导师：刘源远\ngege87417376@qq.com\n结合 NWR 实现 Flexible RAFT，用于自定义 Quorum 的大小\n项目编号：2395a0390\n项目难度：进阶/Advanced\nJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，它运行过程分为两个阶段，即 Leader 选举和日志复制。在原始的 RAFT 算法中，Leader 选举和日志复制都需要获得多数派成员的支持。而 NWR 模型则可以在动态调整一致性强度的场景中使用，它需要满足 W+R\u0026amp;gt;N，以保证强一致性。JRaft 将 RAFT 和 NWR 结合起来，使得用户可以根据不同的业务需求来动态调整 Quorum 的数量。例如，在一个写多读少的场景中，用户可以将多数派的数量从 3 调整为 2，以降低达成共识的条件，从而提高写请求的效率。同时，为了保证 RAFT 的正确性，写 Quorum 的调整需要付出代价，即读 Quorum 的数量也需要相应调整。JRaft 支持成员变更，因此用户可以配置 (0,1] 范围内的小数来计算 W 和 R 的具体值。通过使用 JRaft，用户可以根据自己的业务需求来灵活地调整 …","date":1683270000,"description":"【开源之夏 2023】欢迎报名 SOFAStack 社区项目！","dir":"activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"def1ba20e3e6b79b6b9e2c6bae16ba91","permalink":"https://sofastack.github.io/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","publishdate":"2023-05-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["SOFAStack 开源之夏"],"title":"【开源之夏 2023】欢迎报名 SOFAStack 社区项目！","type":"activities","url":"/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/","wordcount":2742},{"author":null,"categories":"SOFAStack","content":"上一篇我们用 Go 扩展实现了 Basic Auth，体验了 Go 扩展从 Envoy 接受配置。\n之所以这么设计，是想复用 Envoy 原有的 xDS 配置推送通道，今天我们就来体验一番，云原生的配置变更。\n前提准备\n这次我们需要一套 K8s 环境，如果你手头没有，推荐使用 Kind 安装一套。具体安装方式，这里就不展开了。\n安装 Istio\n我们直接安装最新版的 Istio：\n# 下载最新版的 istioctl$ export ISTIO_VERSION=1.18.0-alpha.0$ curl -L https://istio.io/downloadIstio | sh - # 将 istioctl 加入 PATH$ cd istio-$ISTIO_VERSION/$ export PATH=$PATH:$(pwd)/bin # 安装，包括 istiod 和 ingressgateway$ istioctl install 是的，由于 Go 扩展已经贡献给了上游官方，Istiod（Pilot）和 Ingress Gateway 都已经默认开启了 Go 扩展，并不需要重新编译。\nIstio 配置 Ingress\n我们先用 Istio 完成标准的 Ingress 场景配置，具体可以看 Istio 的官方文档[1]。\n配置好了之后，简单测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot;HTTP/1.1 200 OKserver: istio-envoydate: Fri, 10 Mar 2023 15:49:37 GMT 基本的 Ingress 已经跑起来了。\n挂载 Golang so\n之前我们介绍过，Go 扩展是单独编译为 so 文件的，所以，我们需要把 so 文件，挂载到 Ingress Gateway 中。\n这里我们把上次 Basic Auth 编译出来的 libgolang.so，通过本地文件挂载进来。简单点搞，直接 edit deployment 加了这些配置：\n# 申明一个 hostPath 的 volumevolumes:- name: golang-so-basic-auth hostPath: path: /data/golang-so/example-basic-auth/libgolang.so type: File # 挂载进来volumeMounts:- mountPath: /etc/golang/basic-auth.so name: golang-so-basic-auth readOnly: true 开启 Basic Auth 认证\nIstio 提供了 EnvoyFilter CRD，所以，用 Istio 来配置 Go 扩展也比较方便，apply 这段配置，Basic Auth 就开启了。\napiVersion: networking.istio.io/v1alpha3kind: EnvoyFiltermetadata: name: golang-filter namespace: istio-systemspec: configPatches: # The first patch adds the lua filter to the listener/http connection manager - applyTo: HTTP_FILTER match: context: GATEWAY listener: filterChain: filter: name: \u0026amp;quot;envoy.filters.network.http_connection_manager\u0026amp;quot; subFilter: name: \u0026amp;quot;envoy.filters.http.router\u0026amp;quot; patch: operation: INSERT_BEFORE value: # golang filter specification name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: \u0026amp;quot;type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config\u0026amp;quot; library_id: example library_path: /etc/golang/basic-auth.so plugin_name: basic-auth plugin_config: \u0026amp;quot;@type\u0026amp;quot;: \u0026amp;quot;type.googleapis.com/xds.type.v3.TypedStruct\u0026amp;quot; type_url: typexx value: username: foo password: bar 虽然有点长，但是，也很明显，配置的用户名密码还是：foo:bar。\n测试\n我们测试一下：\n$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot;HTTP/1.1 401 Unauthorized # valid foo:bar$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39;HTTP/1.1 200 OK 符合预期。\n接下来，我们改一下 EnvoyFilter 中的密码，重新 apply，再测试一下：\n# foo:bar not match the new password$ curl -s -I -HHost:httpbin.example.com \u0026amp;quot;http://$INGRESS_HOST:$INGRESS_PORT/status/200\u0026amp;quot; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39;HTTP/1.1 401 Unauthorized 此时的 Envoy 并不需要重启，新的配置就立即生效了，云原生的体验就是这么溜~\n总结\n因为 Go 扩展可以利用 Envoy 原有的 xDS 来接受配置，所以，从 Istio 推送配置也变得很顺利。\n不过，Istio 提供的 EnvoyFilter CRD 在使用上，其实并不是那么方便和自然，后面我们找机会试试 Envoy Gateway，看看 K8s Gateway API 的体验如何。\n至此，我们已经体验了整个 Envoy Go 的开发\u0026amp;amp;使用流程，在云原生时代，人均 Golang 的背景下，相信可以很好的完成网关场景的各种定制需求。\n下一篇，我们将介绍，如何在 Go 扩展中使用异步 …","date":1683010800,"description":"MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置","dir":"blog/moe-series (3)｜dynamic-update-of-go-extension-configuration-with-istio/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1683010800,"objectID":"5ff7cec6ed4b29c51c1f65f47b32672c","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","publishdate":"2023-05-02T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","summary":"上一篇我们用 Go 扩展实现了 Basic Auth，体验了 Go 扩展从 Envoy 接受配置。 之所以这么设计，是想复用 Envoy 原有的 xDS 配置推送通道，今天我们就来体验一番，云原生的","tags":["SOFAStack"],"title":"MoE 系列（三）｜使用 Istio 动态更新 Go 扩展配置","type":"blog","url":"/sofastack.tech/blog/moe-series-3dynamic-update-of-go-extension-configuration-with-istio/","wordcount":974},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议预告\nSOFAArk：\n主题：SOFAArk 社区会议\n时间：5 月 8 日 20:00 - 21:30\n入会口令（钉钉）：683 550 26227\n电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆）\n入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题：\n 近期版本发布计划和内容。 非迭代 issue 处理同步。 开源之夏活动介绍。 GPT 在 SOFA 工程领域的探索。 「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/636\n每月一次的 SOFAArk 社区会议要开啦！有对议题感兴趣的同学不要错过哦～\nSOFA 社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：4 月 26 日 14:00 - 15:00\n会议内容：\n本次社区会议根据议题同步了 2023 开源之夏申报的课题，并号召社区同学踊跃参与；对于自建各种组件，会议详细讲解了问题痛点与解决方案；Layotto 在升级 gRPC 版本时出现的前置依赖问题，会议中的同学提出了方案；在会议的最后，同步了 CLA 机器人解决的进展与办法。\n「Layotto」：https://github.com/mosn/layotto/issues/915\n「会议回放」：https://www.bilibili.com/video/BV1Qg4y177dG/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@huayangchan #914\n 下载 Layotto-0.5.0 源码，在本地 Windows 系统编译启动时，报一些函数和变量未定义错误，如 undefined: syscall.GetsockoptIPv 6Mreq，这应该是 Unix 系统才调用的函数，为什么在 Windows 系统运行会调 Unix 系统相关的函数，还说源码只能在 Unix 系统上便已启动?\n A：Layotto 是基于 MOSN 为底座的，用到了 Linux 的系统函数，所以不支持 Windows 上的编译。可以参考：https://github.com/mosn/layotto/issues/801\n「Layotto」：https://github.com/mosn/layotto/issues/914\n2.@shuangchengsun #263\n 图片展示了实例（Client）的上下线过程， 假设这么一个场景，Client1 处于下线过程中，此时它已经和 Session Server 断链，但是 Session Server 在发出同步通知前因为某种原因挂了，此时 Client1 在路由表中的状态是如何维护的？\n A: Data 上有一个定时器去维护每个 Session 相关数据的。如果 Session 挂了，Data 大约 30s 后把挂掉的 Session 的数据清理掉，同时链接挂掉的 Client（除了要下线的那个）会自动重连到其他 Session 上。然后会把数据增长一个 Version 重新注册到 Session，Session 会再次发到那台 Data 上。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/issues/263\n本周推荐阅读\n缘起｜蚂蚁应用级服务发现的实践之路\nSOFARegistry 源码｜数据同步模块解析\nMoE 系列（一）｜如何使用 Golang 扩展 Envoy\nMoE 系列（二）｜Golang 扩展从 Envoy 接收配置\n","date":1682665200,"description":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","dir":"blog/sofa-weekly-20230428/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f7cd5d7b9340442e111c4dfeaf5a6813","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230428/","publishdate":"2023-04-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230428/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFAArk 社区会议预告、Layotto 社区会议回顾、社区本周贡献","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230428/","wordcount":1451},{"author":null,"categories":"SOFAStack","content":"文｜蚂蚁集团 ZOLOZ 团队\n使用全球领先安全科技，为用户和机构提供安全、便捷的安全风控解决方案。\n本文 6386 字 阅读 12 分钟\n背景简介\nZOLOZ[1]是蚂蚁集团旗下的全球安全风控平台，通过业内领先的生物识别、大数据分析和人工智能技术，为用户和机构提供安全又便捷的安全风控解决方案。ZOLOZ 已为中国、印尼、马来西亚、菲律宾等 14 个国家和地区的 70 余家合作伙伴提供数字化转型过程中的安全风控技术支持。目前，已经覆盖金融、保险、证券、信贷、电信、公众服务等领域，累计服务用户超 12 亿。\n随着 Kubernetes 和云原生的大爆发，ZOLOZ 应用开始在公有云上进行大规模容器化部署。ZOLOZ 业务的镜像经过长期维护和更新，无论是镜像层数还是整体大小都达到了一个较大的量级 （数百 MB 或者几个 GB） 。特别是 ZOLOZ AI 算法推理应用的基础镜像大小要远大于一般应用镜像 （Docker Hub 上 PyTorch/PyTorch：1.13.1-CUDA 11.6-cuDNN 8-Runtime 有 4.92GB，同比 CentOS：latest 只有约 234MB） ，对于容器冷启动，即在本地无镜像的情况下，需要先从 Registry 下载镜像才能创建容器，在生产环境中，容器的冷启动往往耗时数分钟，并且随规模扩大会导致 Registry 因集群内网络拥堵而无法快速地下载镜像，如此庞大的镜像给应用的更新和扩容等操作都带来了不少挑战。在公有云上容器化持续推进的当下，ZOLOZ 应用主要遇到了三大挑战：\n 算法镜像大，推送到云上镜像仓库耗时长，开发过程中，在使用测试环境进行测试时，往往希望快速迭代，快速验证，但是每次改完一个分支发布验证都要经过几十分钟，开发效率十分低下。\n 拉取算法镜像耗时长，在集群扩容大量机器拉取镜像文件会容易导致集群网卡被打满，影响业务正常运行。\n 集群机器拉起时间长，难以满足流量突增时，弹性自动扩缩容。\n 虽然也尝试过各种折中的解决方案，但这些方案都有缺陷，现在结合蚂蚁、阿里云、字节跳动等多个技术团队打造了一套更通用的公有云上解决方案，该方案改造成本低，性能好，目前看来是比较理想的方案。\n术语及定义\nOCI：Open Container Initiative，开放容器计划是一个 Linux 基金会项目，由 Docker 在 2015 年 6 月启动，旨在为操作系统级虚拟化 （最重要的是 Linux 容器） 设计开放标准。\nOCI Manifest：遵循 OCI Image Spec 的制品。\nBuildKit：是 Docker 公司出品的一款更高效、Dockerfile 无关、更契合云原生应用的新一代 Docker 构建工具。\n镜像：本文中的镜像指 OCI Manifest，也包括 Helm Chart 等其他 OCI Manifest。\n镜像仓库：遵循 OCI Distribution Spec 实现的制品仓库。\nECS：是一种由 CPU、内存、云盘组成的资源集合，每一种资源都会逻辑对应到数据中心的计算硬件实体。\nACR：阿里云镜像仓库服务。\nACK：阿里云容器服务 Kubernetes 版提供高性能可伸缩的容器应用管理能力，支持企业级容器化应用的全生命周期管理。\nACI：ACI 全称 Ant Continuous Integration （AntCI） ，是蚂蚁集团研发效能旗下一款以流水线 （Pipeline） 为核心的 CI/CD 效能产品。使用智能自动化构建、测试和部署，提供了以代码流为输入的轻量级持续交付解决方案，提高团队研发的工作效率。\nPrivate Zone：基于专有网络 VPC （Virtual Private Cloud） 环境的私有 DNS 服务。该服务允许在自定义的一个或多个 VPC 中将私有域名映射到 IP 地址。\nP2P：点对点技术，当 P2P 网络中某一个 Peer 从 Server 下载数据的时候，下载完数据后也能当作服务端供其他 Peer 下载。当大量节点同时下载的时候，能保证后续下载的数据，可以不用从 Server 端下载。从而减轻 Server 端的压力。\nDragonfly：Dragonfly 是⼀款基于 P2P 技术的文件分发和镜像加速系统，并且是云原生架构中镜像加速领域的标准解决方案以及最佳实践。现在为云原生计算机基金会 （CNCF） 托管作为孵化级项目。\nNydus：Nydus 镜像加速框架是 Dragonfly 的子项目，它提供了容器镜像按需加载的能力，在生产环境支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，端到端数据一致性，内核态支持等方面相比 OCIv1 有巨大优势。\nLifseaOS：面向容器场景，阿里云推出轻量、快速、安全、镜像原子管理的容器优化操作系统，相比传统操作系统软件包数量减少 60%，镜像大小减少 70%，OS 首次启动从传统 OS 的 1min 以上下降到了 2s 左右。支持镜像只读和 OSTree 技术，将 OS 镜像版本化管理，更新操作系统上的软件包、或者固化的配置时，以整个镜像为粒度进行更新。\n方案设计\n解决镜像大的问题\n1. 精简基础 镜像 大小\n基础 OS 从 CentOS 7 改为 AnolisOS 8，精简运维工具的安装，只默认安装一些必须的工具列表 （基础运维工具、运行时通用依赖、日志清理、安全基线等组件） ，并简化安全加固的配置，基础镜像从 1.63GB 减少到 300MB。\nAnolisOS 仓库：https://hub.docker.com/r/openanolis/anolisos/tags\n2. Dockerfile 优化\n通过 Dockerfile 编写约束、镜像检测等手段减少不必要的构建资源和时间。\nDockerfile 最佳实践原则: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/\n3. 并行构建和构建缓存\n蚂蚁构建中心采用 Nydus 社区优化版的 BuildKit[2]，BuildKit 支持 layer 级别缓存，准确引用先前的产出物并进行缓存匹配，使用方法与普通镜像并无区别，对于 Multistage 类型 Dockerfile，BuildKit 可以实现不同 stage 之间的并行执行。\n推送到云上镜像仓库耗时长\n1. 使用 Nydus 镜像进行块级别数据去重\n传统 OCI 镜像，不同镜像之间可以共享的最小单位是镜像中的层，在 deduplication 上的效率是非常低的，层内部存在重复的数据，层与层之间可能存在大量重复的数据，即使有微小的差别，也会被作为不同的层，根据 OCI Image Spec 对删除文件和 Hard Link 的设计，一个镜像内部可能存在已经被上层删除的文件仍然存在于下层中，并包含在镜像中。另外 OCI Image 使用了 tar+gzip 格式来表达镜像中的层，而 tar 格式并不区分 tar archive entries ordering， …","date":1682492400,"description":"蚂蚁安全科技 Nydus 镜像加速实践","dir":"blog/ant-security-technology-nydus-mirror-acceleration-practice/","fuzzywordcount":8700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c89b17510ce48eb33633af0051249102","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","publishdate":"2023-04-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","summary":"文｜蚂蚁集团 ZOLOZ 团队 使用全球领先安全科技，为用户和机构提供安全、便捷的安全风控解决方案。 本文 6386 字 阅读 12 分钟 背景简介 ZOLOZ[1]是蚂蚁集团旗","tags":["SOFAStack"],"title":"蚂蚁安全科技 Nydus 镜像加速实践","type":"blog","url":"/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/","wordcount":8656},{"author":null,"categories":"SOFA WEEKLY","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA社区会议回顾\nLayotto：\n主题：Layotto 社区会议\n时间：4 月 19 日 14:00 - 15:00\n会议内容：\n本次社区会议根据议题探讨了 2023 开源之夏申报课题的具体方式和内容，并号召同学踊跃参与报名；对于自建组件问题，方案已经敲定，感兴趣的同学可以尝试；Layotto 在升级 gRPC 版本时出现前置依赖问题，并在会议中同步进展；关于 CLA 机器人出现的问题，社区同学共同讨论了提供解决的思路。\n「Layotto」：https://github.com/mosn/layotto/issues/907\n「会议回放」：https://www.bilibili.com/video/BV1aT411p7cr/?share_source=copy_web\u0026amp;amp;vd_source=802e089175dbc2ea677914f78683b18a\nSOFA 社区会议预告\nLayotto：\n主题：Layotto 2023-04-26 社区会议\n时间：4 月 26 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2344343024\n议题：\n 2023 开源之夏-课题/导师招募#894\n Discussion：自建各种 Component#902\n 希望 Layotto 提供高性能的通信交互能力#867\n 「Layotto」：https://github.com/mosn/layotto/issues/907\nSOFA 五周年资料已上传 SOFAStack 官网\n回复公众号：“SOFA 五周年”\n即可获取链接啦～\n还可戳“阅读原文”跳转哦！\nSOFAStack 社区本周贡献\nSOFARPC 5.10.0 版本发布\n发布 SOFARPC 5.10.0 版本，主要变更如下:\n 重构了自定义序列化器的注册模式，使得主站版可以覆盖开源版的注册#1296\n 修改了反序列化时 Request Header 的处理逻辑#1325\n 更新了 Javassist Proxy 构造 class 时的 API 使之能在 JDK17 环境下运行#1316\n 详细发布报告：https://github.com/sofastack/sofa-rpc/compare/v5.9.2\u0026amp;hellip;v5.10.0\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n @LY1806620741 #1061 com.alipay.sofa.rpc.enable-swagger 是否已经废弃？在 3.16.3\ncom.alipay.sofa.rpc.enable-swagger=true 配置使用了 Objectway 的 ASM，与 Spring Boot 的 ASM 冲突。\n A：可以手动增加一个依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.ow2.asm\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;asm\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;9.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 看起来是 https://github.com/sofastack/sofa-rpc/blob/5.8.3.1/all/pom.xml 少添加了一个 ASM 的依赖，导致出现上面的问题。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n @Estom#642 多 Host 模式下，动态部署，无法启动第二个 Tomcat。需要添加特殊的配置吗？\n A：多 Host 模式配置建议看一下这份文档 https://www.sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/中的“6.多 Host 与单 Host 模式”。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/642\n","date":1682060400,"description":"SOFA Weekly｜SOFARPC 5.10.0 版本发布、SOFA 五周年回顾、Layotto 社区会议回顾与预告","dir":"blog/sofa-weekly-0421/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4477f615201d81a1e6578f20f910a5d2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0421/","publishdate":"2023-04-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0421/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA WEEKLY"],"title":"SOFA Weekly｜SOFARPC 5.10.0 版本发布、SOFA 五周年回顾、Layotto 社区会议回顾与预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0421/","wordcount":1547},{"author":null,"categories":"SOFAStack","content":"文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者\n蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 1445 字 阅读 5 分钟\n上一篇我们用一个简单的示例，体验了用 Golang 扩展 Envoy 的极速上手。\n这次我们再通过一个示例，来体验 Golang 扩展的一个强大的特性：\n从 Envoy 接收配置。\nBasic Auth\n我们还是从一个小示例来体验，这次我们实现标准的 Basic Auth 的认证，与上一次示例不同的是，这次认证的用户密码信息，需要从 Envoy 传给 Go，不能在 Go 代码中写死了。\n完整的代码可以看 example-basic-auth[1]，下面我们展开介绍一番。\n获取配置\n为了更加灵活，在设计上，Envoy 传给 Go 的配置是 Protobuf 的 Any 类型，也就是说，配置内容对于 Envoy 是透明的，我们在 Go 侧注册一个解析器，来完成这个 Any 配置的解析。\n如下示例：\nfunc init() { // 注册 parser http.RegisterHttpFilterConfigParser(\u0026amp;amp;parser{}) } func (p *parser) Parse(any *anypb.Any) interface{} { configStruct := \u0026amp;amp;xds.TypedStruct{} if err := any.UnmarshalTo(configStruct); err != nil { panic(err) } v := configStruct.Value conf := \u0026amp;amp;config{} if username, ok := v.AsMap()[\u0026amp;quot;username\u0026amp;quot;].(string); ok { conf.username = username } if password, ok := v.AsMap()[\u0026amp;quot;password\u0026amp;quot;].(string); ok { conf.password = password } return conf } 这里为了方便，Any 中的类型是 Envoy 定义的 TypedStruct 类型，这样我们可以直接使用现成的 Go pb 库。\n值得一提的是，这个配置解析，只有在首次加载的时候需要执行，后续在 Go 使用的是解析后的配置，所以，我们解析到一个 Go map 可以拥有更好的运行时性能。\n同时，由于 Envoy 的配置，也是有层级关系的，比如 http-filter, virtual host, router, virtual clusters 这四级，我们也支持这四个层级同时有配置，在 Go 侧来组织 merge。\n当然，这个只有在 Go 侧有复杂的 filter 组织逻辑的时候用得上，后面我们在 MOSN 的上层封装的时候，可以看到这种用法，这里暂时不做展开介绍。\n认证\n具体的 Basic Auth 认证逻辑，我们可以参考 Go 标准 net/http 库中的 Basic Auth 实现。\nfunc (f *filter) verify(header api.RequestHeaderMap) (bool, string) { auth, ok := header.Get(\u0026amp;quot;authorization\u0026amp;quot;) if !ok { return false, \u0026amp;quot;no Authorization\u0026amp;quot; } username, password, ok := parseBasicAuth(auth) if !ok { return false, \u0026amp;quot;invalid Authorization format\u0026amp;quot; } if f.config.username == username \u0026amp;amp;\u0026amp;amp; f.config.password == password { return true, \u0026amp;quot;\u0026amp;quot; } return false, \u0026amp;quot;invalid username or password\u0026amp;quot; } 这里面的 parseBasicAuth 就是从 net/http 库中的实现，是不是很方便呢。\n配置\n简单起见，这次我们使用本地文件的配置方式。如下是关键的配置：\nhttp_filters: - name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config library_id: example library_path: /etc/envoy/libgolang.so plugin_name: basic-auth plugin_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/xds.type.v3.TypedStruct value: username: \u0026amp;quot;foo\u0026amp;quot; password: \u0026amp;quot;bar\u0026amp;quot; 这里我们配置了用户名密码：foo:bar。\n预告一下，下一篇我们会体验通过 Istio 来推送配置，体会一番动态更新配置的全流程。\n测试\n编译，运行，跟上篇一样，我们还是使用 Envoy 官方提供的镜像即可。\n跑起来之后，我们测试一下：\n$ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; HTTP/1.1 401 Unauthorized # invalid username:password $ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;Authorization: basic invalid\u0026#39; HTTP/1.1 401 Unauthorized # valid foo:bar $ curl -s -I \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;Authorization: basic Zm9vOmJhcg==\u0026#39; HTTP/1.1 200 OK 是不是很简单呢，一个标准的 Basic Auth 扩展就完成了。\n总结\nEnvoy 是面向云原生的架构设计，提供了配置动态变更的机制，Go 扩展可以从 Envoy 接受配置，也就意味着 Go 扩展也可以很好的利用这套机制。\nGo 扩展的开发者，不需要关心配置的动态更新，只需要解析配置即可，非常的方便~\n下一篇我们会介绍，配合 Istio 来动态更新用户名密码，体验一番云原生的配置变更体验。\n后续还有更多 Golang 扩展的特性介绍，原理解析，以及，更上层的 MOSN 集成体验，欢迎持续关注。\n[1]example-basic-auth： …","date":1681801200,"description":"MoE 系列（二）｜Golang 扩展从 Envoy 接收配置","dir":"blog/moe-series (2)｜golang-extensions-receive-configuration-from-envoy/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1681801200,"objectID":"f19954b7d5ae3122eec6e6599e9d1be2","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","publishdate":"2023-04-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者 蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 1445 字 阅读 5 分钟 上一篇我","tags":["SOFAStack"],"title":"MoE 系列（二）｜Golang 扩展从 Envoy 接收配置","type":"blog","url":"/sofastack.tech/blog/moe-series-2golang-extensions-receive-configuration-from-envoy/","wordcount":1147},{"author":null,"categories":"SOFAStack","content":" 概要 活动主题：SOFA 五周年，Live Long and Prosper！\n 活动时间：04 月 15 日 12:00\u0026amp;ndash;17:00\n 活动形式：线下 Meetup + 线上直播\n 资料下载：\n 《SOFAStack 的下一个五年》\n《京东搜索基于Service Mesh的微服务治理探索与实践》\n《顺丰应用运行时落地实践》\n《Seata发展之路——昨天、今天、明天》\n《蚂蚁注册中心建设的思考与实践》\n B 站直播间地址：http://live.bilibili.com/21954520 介绍 2018 年 4 月 19 日，我们在北京启程，伴随种下希望的种子，举办了 SOFAStack 社区的第一个开放日。\n转眼来到 2023 年，瑞兔送福又逢春暖花开，怀揣着新的愿景，我们于 4 月 15 日回到北京庆祝 SOFA 的五岁生日。🎂\n今年的主题「Live Long and Prosper」相信对于不少“星际迷航”粉丝来说都已经耳熟能详了。这是瓦肯人在举瓦肯手礼的时候会说的祝词，却也非常符合 SOFAStack 开源社区的愿景。\n我们希望无论是 SOFAStack 社区项目，还是 SOFA 的生态伙伴，都能够“Live Long and Prosper”！👽\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 宋顺（花名：齐天），SOFAStack 社区开源负责人\n 王志龙，京东集团架构师、MOSN Contributor\n 杨定朝，顺丰集团高级研发工程师、Layotto 用户\n 李宗杰（花名：白鹰），Seata 蚂蚁开源负责人\n 肖健（花名：昱恒），SOFARegistry Maintainer\n 议程 直播回放 https://www.bilibili.com/video/BV1vL411e78B/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1681542000,"description":"2023 年 4 月 15 日，我们在北京一起庆祝了 SOFA 社区的五岁生日。","dir":"activities/sofa-anniversary-5/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3e1d3b14932e3e3e091b5cbce4868d80","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-anniversary-5/","publishdate":"2023-04-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-anniversary-5/","summary":"概要 活动主题：SOFA 五周年，Live Long and Prosper！ 活动时间：04 月 15 日 12:00\u0026ndash;17:00 活动形式：线下 Meetup + 线上直播 资料下载： 《SOFAStack 的下","tags":["SOFAStack","开源五周年"],"title":"SOFA 五周年，Live Long and Prosper！","type":"activities","url":"/sofastack.tech/activities/sofa-anniversary-5/","wordcount":633},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n**1.@SOFAJRaft **#965 提问：\n@a364176773\n RheaKV 中的 RocksDB 为何不支持选择其他压缩方式和压缩风格？\n貌似可以靠StorageOptionsFactory.registerRocksDBOptions注册进去，这样就不会走 default 了？\n A：是的，可以设置自己的选项。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/965\n2.@SOFARPC#1320\n@Misakami\n Spring Boot 3.1 + JDK 17 SOFARPC 显示发布成功但是客户端获取不到服务。\n A：看上去获取不到服务和 JDK17 并没有直接的联系。可以先确认:\n 服务端是否将自身地址发布到注册中心；\n 客户端是否接收到注册中心的推送。\n 「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1320\n本周推荐阅读\n缘起｜蚂蚁应用级服务发现的实践之路\nSOFARegistry | 聊一聊服务发现的数据一致性\nGo 语言，如何做逆向类型推导\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n","date":1681455600,"description":"SOFA Weekly｜SOFA 开源五周年来自社区家人的祝福、社区本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230414/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4e553c30969c289fec68bf7f78424e0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230414/","publishdate":"2023-04-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230414/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 开源五周年来自社区家人的祝福、社区本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230414/","wordcount":657},{"author":null,"categories":"SOFAStack","content":"文｜肖健（花名：昱恒）\n蚂蚁集团技术专家、SOFARegistry Maintainer\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。\n本文 8339 字 阅读 15 分钟\nPART. 1\n前言\n什么是服务发现？\n我们今天主要聊的话题是“应用级服务发现”的实践，聊这个话题之前，我们先简单介绍一下什么是“服务发现”，然后再聊聊，为什么需要“应用级服务发现”。\n在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信，而这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\n图 1（点击图片查看大图）\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑了蚂蚁庞大的服务集群，具有分布式可支撑海量数据、可云原生部署、推送延迟低、高可用等特点。\nPART. 2\n应用级服务发现的设想\n介绍完什么是服务发现之后，我们来看看什么是“接口级服务发现”，以及与之相对应的“应用级服务发现”。\n从 RPC 框架说起\n根据上述描述，我们先看看业界常用的 RPC 框架，是如何进行服务的发布和订阅的。以 SOFARPC 编程界面为例：\n｜服务发布\npackage com.alipay.rpc.sample; @SofaService(interfaceType = FooService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class FooServiceImpl implements FooService { @Override public String foo(String string) { return string; } } @SofaService(interfaceType = BarService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class BarServiceImpl implements BarService { @Override public String bar(String string) { return string; } } ｜服务使用\n@Service public class SampleClientImpl { @SofaReference(interfaceType = FooService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private FooService fooService; @SofaReference(interfaceType = BarService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private BarService barService; public String foo(String str) { return fooService.foo(str); } public String bar(String str) { return barService.bar(str); } } 上述两个编程界面，完成了两个服务 FooService 和 BarService 的发布、订阅、调用。\n微服务面临的挑战\n上述的服务发布、订阅、调用功能，离不开注册中心的服务发现提供准确的服务地址。将图 1 的服务发现场景进一步展开，此时的工作原理如下图：\n图 2（点击图片查看大图）\n服务发布者\n- 集群内部署了 100 个 pod，IP 分别为：1.1.1.1 ~ 1.1.1.100；\n- 服务发布者的 URL：1.1.1.1:12200?app=applicationB\u0026amp;amp;_SERIALIZETYPE=hessian2\u0026amp;amp;_TIMEOUT=3000\u0026amp;amp;zone=zone1\u0026amp;amp;version=1\u0026amp;amp;_WARMUPTIME=0，12200 端口为 sofarpc-bolt 协议默认的端口。\n服务订阅者：集群内部署了 100 个 pod，IP 分别为：2.1.1.1 ~ 2.1.1.100。\n基于上述的集群部署情况，我们来看看微服务的场景面临的挑战。\n｜挑战 1：注册中心 publisher 存储的挑战\n在上面的集群部署中，可以看到注册中心的数据存储模型，集群内部署了 100 个 provider pod，每个 provider 发布了 2 个服务，即每个 pod 有 2 个 publisher，以 provider1 为例：\n如果在每个 provider 提供更多服务的情况下呢？比如每个 provider 提供了 50 个服务，这样的量级在微服务场景中并不少见，那么此时注册中心对于 provider1，就需要存储 50 个 publisher，分别是：\n可以看到，随着 provider 的扩容，注册中心存储的 publisher 数据量是以 50 倍于 provider 的速度在增长。\n如果您对 SOFARegistry 有过了解，就会知道 SOFARegistry 是支持数据存储分片，可以存储海量数据的。\n但是数据量上涨带来的是 SOFARegistry 本身的服务器数量增涨，如果我们有办法可以降低 SOFARegistry 的数据存储量，那么就能节约 SOFARegistry 本身的服务器成本，同时 SOFARegistry 整个集群的稳定性也会得到提升。\n｜挑战 2：注册中心 subscriber 存储的挑战\n在上述的集群部署中，集群内部署了 100 个 consumer pod，每个 consumer 订阅了 2 个服务，即每个 pod 有 2 个 subscriber，同理于 publisher 的存储挑战，随着 consumer 订阅的接口持续增加，例如 consumer 订阅了 provider 的 10 个 service，此时注册中心存储 consumer1 的 10 个 subscriber 如下：\n随着 consumer 的扩容，注册中心内的 subscriber 存储同样面临着挑战。\n｜挑战 3：服务变更通知的挑战\n随着 publisher 和 subscriber 数量增长，除了对存储的挑战以外，对于数据变更通知同样面临着极大的挑战，让我们来看看如下的场景：provider 下线了 1 台，从 100 台减少到了 99 台，次数集群内发生了哪些变化呢？\n1、首先是在注册中心存储方面，需要将 provide 50 个 service …","date":1681196400,"description":"缘起｜蚂蚁应用级服务发现的实践之路","dir":"blog/origins｜ant's-practical-path-to-application-level-service-discovery/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1681196400,"objectID":"961f22ae0d2c39d1338da028adc43cbb","permalink":"https://sofastack.github.io/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","publishdate":"2023-04-11T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家、SOFARegistry Maintainer 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。 本文 8339 字 阅","tags":["SOFAStack"],"title":"缘起｜蚂蚁应用级服务发现的实践之路","type":"blog","url":"/sofastack.tech/blog/originsants-practical-path-to-application-level-service-discovery/","wordcount":3973},{"author":"肖健","categories":["SOFARegistry"],"content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家、SOFARegistry Maintainer\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。\n本文 8339 字阅读 15分钟\nPART. 1\n前言 什么是服务发现？ 我们今天主要聊的话题是“应用级服务发现”的实践，聊这个话题之前，我们先简单介绍一下什么是“服务发现”，然后再聊聊，为什么需要“应用级服务发现”。\n在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信，而这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\n图 1\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑了蚂蚁庞大的服务集群，具有分布式可支撑海量数据、可云原生部署、推送延迟低、高可用等特点。\nPART. 2\n应用级服务发现的设想 介绍完什么是服务发现之后，我们来看看什么是“接口级服务发现”，以及与之相对应的“应用级服务发现”。\n从 RPC 框架说起 根据上述描述，我们先看看业界常用的 RPC 框架，是如何进行服务的发布和订阅的。以 SOFARPC 编程界面[1]为例：\n服务发布 package com.alipay.rpc.sample; @SofaService(interfaceType = FooService.class, bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class FooServiceImpl implements FooService { @Override public String foo(String string) { return string; } } @SofaService(interfaceType = BarService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class BarServiceImpl implements BarService { @Override public String bar(String string) { return string; } } 服务使用 @Service public class SampleClientImpl { @SofaReference(interfaceType = FooService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private FooService fooService; @SofaReference(interfaceType = BarService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private BarService barService; public String foo(String str) { return fooService.foo(str); } public String bar(String str) { return barService.bar(str); } } 上述两个编程界面，完成了两个服务 FooService 和 BarService 的发布、订阅、调用。\n微服务面临的挑战 上述的服务发布、订阅、调用功能，离不开注册中心的服务发现提供准确的服务地址。将图 1 的服务发现场景进一步展开，此时的工作原理如下图：\n图 2（点击图片查看大图）\n服务发布者：\n- 集群内部署了 100 个 pod，IP 分别为：1.1.1.1 ~ 1.1.1.100；\n- 服务发布者的 URL：1.1.1.1:12200?app=applicationB\u0026amp;amp;_SERIALIZETYPE=hessian2\u0026amp;amp;_TIMEOUT=3000\u0026amp;amp;zone=zone1\u0026amp;amp;version=1\u0026amp;amp;_WARMUPTIME=0，12200 端口为 sofarpc-bolt 协议默认的端口。\n服务订阅者：集群内部署了 100 个 pod，IP 分别为：2.1.1.1 ~ 2.1.1.100。\n基于上述的集群部署情况，我们来看看微服务的场景面临的挑战。\n挑战 1：注册中心 publisher 存储的挑战 在上面的集群部署中，可以看到注册中心的数据存储模型，集群内部署了 100 个 provider pod，每个 provider 发布了 2 个服务，即每个 pod 有 2 个 publisher，以 provider1 为例：\n如果在每个 provider 提供更多服务的情况下呢？比如每个 provider 提供了 50 个服务，这样的量级在微服务场景中并不少见，那么此时注册中心对于 provider1，就需要存储 50 个 publisher，分别是：\n可以看到，随着 provider 的扩容，注册中心存储的 publisher 数据量是以 50 倍于 provider 的速度在增长。\n如果您对 SOFARegistry 有过了解，就会知道 SOFARegistry 是支持数据存储分片，可以存储海量数据的。\n但是数据量上涨带来的是 SOFARegistry 本身的服务器数量增涨，如果我们有办法可以降低 SOFARegistry 的数据存储量，那么就能节约 SOFARegistry 本身的服务器成本，同时 SOFARegistry 整个集群的稳定性也会得到提升。\n挑战 2：注册中心 subscriber 存储的挑战 在上述的集群部署中，集群内部署了 100 个 consumer pod，每个 consumer 订阅了 2 个服务，即每个 pod 有 2 个 subscriber，同理于 publisher 的存储挑战，随着 consumer 订阅的接口持续增加，例如 consumer 订阅了 provider 的 10 个 service，此时注册中心存储 consumer1 的 10 个 subscriber 如下：\n随着 consumer 的扩容，注册中心内的 subscriber 存储同样面临着挑战。\n挑战 3：服务变更通知的挑战 随着 publisher 和 subscriber 数量增长，除了对存储的挑战以外，对于数据变更通知同样面临着极大的挑战，让我们来看看如下的场景：provider 下线了 1 台，从 100 台减少到了 99 台，次数集群内发生了哪些变化呢？\n1、首先是在注册中心存储方面，需要将 provide 50 个 service 中的 publishers 列表都减 …","date":1681196400,"description":"缘起｜蚂蚁应用级服务发现的实践之路","dir":"projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c9a51341a37418edfd01dc26b64f56e4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","publishdate":"2023-04-11T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家、SOFARegistry Maintainer 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。 本文 8339 字阅","tags":["SOFAStack","SOFARegistry"],"title":"缘起｜蚂蚁应用级服务发现的实践之路","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/","wordcount":4116},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 会议预告\nLayotto：\n主题：Layotto 2023-04-12 社区会议\n时间：4 月 12 日（下周三）14:00\n入会口令（钉钉）：688 824 34655\n电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆）\n入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2344343024\n议题：\n- 2023开源之夏-课题/导师招募 #894；\n- Discussion: 自建各种 Component #902；\n- 希望 layotto 提供高性能的通信交互能力 #867。\n「Layotto」：\nhttps://github.com/mosn/layotto/issues/907\n社区本周贡献\nSOFAStack GitHub issue 精选\n本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@LSQGUANLIVV #1322\n 从 sofa2.3.5 升级到 3.6.3 的时候，启动应用报错，如下图所示。\n 按照报错的点去找发现是 applicationContext 为 null，这里是需要新增加什么配置吗？还是原来的什么地方需要改呢？\n A：有可能是 sofa-boot / sofa-rpc-starter / sofa-rpc 这三个包的兼容性问题。升级了 sofa-rpc，需要同时升级这三个包。可以通过 pom 依赖看下是否有版本冲突。\n 是用的 sofaboot-enterprise-dependencies 的父依赖的默认的，这个也会冲突吗？\n A：使用默认的一般不会有问题，担心有些配置把默认配置覆盖了。另外商业版需要咨询商业版客服，开源社区这边能提供的帮助有限。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1322\n2.@hanzhihua #956\n readCommittedUserLog 可能获得不到刚写入的数据。我在做 NodeTest 测试过程中，在测试 readCommittedUserLog 方法中，出现了错误。\n 我发现主要是日志写入后，但 lastAppliedIndex 没有原子级别更新，造成了读取不到错误。\n A：因为onApply中是可以回滚的，所以没法去实时更新 lastAppliedIndex，只有确认这一批次没有回滚或者回滚的正确 log index，才能去更新。如果你需要在onApply过程中去 commit，可以调用日志迭代器的Iterator#commit方法，将当前 apply 的 log index 确认提交。然后就可以调用readCommittedUserLog确保可以读取到，代价就是无法回滚到 commit 之前的位置了。\n 问一下，onApply 回滚是什么意思，是指状态机 apply 发生异常，还是获取日志为 null，另外怎么回滚呢？\n A：这个方法：\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/956\n本周推荐阅读\n《MoE 系列（一）｜如何使用 Golang 扩展 Envoy》\n《SOFAJRaft 在同程旅游中的实践》\n《Tongsuo/铜锁｜「开放原子开源基金会」拜访篇》\n《如何看待 Dapr、Layotto 这种多运行时架构？》\n","date":1680850800,"description":"SOFA Weekly｜SOFA 开源五周年活动报名、Layotto 会议预告、社区本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230407/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5deb7a12ba899d85e14ea36b8d21dec4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230407/","publishdate":"2023-04-07T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230407/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly｜SOFA 开源五周年活动报名、Layotto 会议预告、社区本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230407/","wordcount":1357},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区会议 SOFAArk 背景：SOFAArk 在社区开源将近 5 年，从最初的一个类隔离框架，逐步演进为支持合并部署与热部署的 “Serverless” 运行时框架。尤其在去年我们完成了 SOFAArk 1.0 到 2.0 架构的演进，在蚂蚁也基于 SOFAArk 2.0 完成了 Serverless 研发模式初步的规模化落地。\n主题：SOFAArk 社区化运作方式 KO（暨第一次月会） 时间：4 月 3 日（下周一）20:00 入会口令（钉钉）：683 550 26227 电话呼入：+862759771614（中国大陆）+8657128356290（中国大陆） 入会链接：https://meeting.dingtalk.com/j/hv0CVKasIgs\n议题： - SOFAArk 社区化运作计划同步与讨论； - 版本维护策略公告； - 项目 CY23 开源规划（含新人培养计划）； - 本次月会 issue 讨论。\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。\n「SOFAArk」：\nhttps://github.com/sofastack/sofa-ark/issues/635\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@Misakami #1321\n 请问 sofa-rpc 有支持 jdk 17 的计划么？现在虽然能正常使用，但是需要在启动参数加上 \u0026amp;ndash;add-opens java.base/java.lang=ALL-UNNAMED。\n A：有的，近期也正在做兼容 jdk 17 的开发。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/issues/1321\n2.@googlefan #939\n jraft-spring-boot-starter || NodeManager 设计目的的作用? 看到 jraft-core 有提供 NodeManage.nodeMap 这个针对 Node 节点进行管理的实例，我以为可以通过 NodeManage.nodeMap 来获取所有集群节点的 RPC 服务，如果是这样的话，这个类的设计的目的是?\n A：NodeManager 是 jraft 内部为了实现单个进程内多个 raft group 共享同一个网络端口设计的，不是给集成着或者用户使用的。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/939\n本周推荐阅读 应用运行时 Layotto 进入 CNCF 云原生全景图\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1680246000,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230331/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a01ecd144b06b6b3399f4474a92ab677","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230331/","publishdate":"2023-03-31T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230331/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230331/","wordcount":1071},{"author":null,"categories":"SOFAStack","content":"本文作为 MoE 系列第一篇，主要介绍用 Golang 扩展 Envoy 的极速开发体验。\n一、背景\nMoE*（MOSN on Envoy）*是 MOSN 团队提出的技术架构，经过近两年的发展，在蚂蚁内部已经得到了很好的验证；并且去年我们也将底层的 Envoy Go 七层扩展贡献了 Envoy 官方，MOSN 也初步支持了使用 Envoy 作为网络底座的能力。\n借此准备写一系列的文章，逐一介绍这里面的技术。本文作为开篇，将重点介绍 MoE 中的基础技术，Envoy Go 扩展。\n二、FAQ\n开始前，先给大家解答下几个基本的问题：\n 1、MoE 与 Envoy Go 扩展有什么区别？\n A：MoE 是技术架构，Envoy Go 扩展是连接 MOSN 和 Envoy 的基础技术。\n 2、Envoy Go 扩展，与用 Go 来编译 Wasm 有什么区别？\n A：Envoy Go 支持 Go 语言的所有特性，包括 Goroutine；Go Wasm 则只能使用少量的 Go 语言特性，尤其是没有 Goroutine 的支持。\n 3、Go 是静态链接到 Envoy 么？\n A：不是的，Go 扩展编译成为 so，Envoy 动态加载 so，不需要重新编译 Envoy\n 4、Envoy Go 支持流式处理么？\n A：支持的。\n由于 Go 扩展提供的是底层的 API，非常的灵活，使用上相对会稍微复杂一些；如果只想简单的使用，可以使用 MOSN 的 filter，后面我们也会介绍。\n三、需求\n我们先实现一个小需求，来实际体会一下：\n对请求需要进行验签，大致是从 URI 上的某些参数，以及私钥计算一个 token，然后和 header 中的 token 进行对比，对不上就返回 403。\n很简单的需求，仅仅作为示例，主要是体验一下过程。\n四、代码实现\n完整的代码可以看 envoy-go-filter-example[1] 这个仓库，这里摘录最核心的两个函数：\nconst secretKey = \u0026amp;quot;secret\u0026amp;quot; func verify(header api.RequestHeaderMap) (bool, string) { token, ok := header.Get(\u0026amp;quot;token\u0026amp;quot;) if ok { return false, \u0026amp;quot;missing token\u0026amp;quot; } path, _ := header.Get(\u0026amp;quot;:path\u0026amp;quot;) hash := md5.Sum([]byte(path + secretKey)) if hex.EncodeToString(hash[:]) != token { return false, \u0026amp;quot;invalid token\u0026amp;quot; } return true, \u0026amp;quot;\u0026amp;quot; } func (f *filter) DecodeHeaders(header api.RequestHeaderMap, endStream bool) api.StatusType { if ok, msg := verify(header); !ok { f.callbacks.SendLocalReply(403, msg, map[string]string{}, 0, \u0026amp;quot;bad-request\u0026amp;quot;) return api.LocalReply } return api.Continue } DecodeHeaders 是扩展 filter 必须实现的方法，我们就是在这个阶段对请求 header 进行校验。\nverify 是校验函数，这里的 RequestHeaderMap 是 Go 扩展提供的 interface，我们可以通过它来读写 header，其他都是常见的 Go 代码写法。\n五、编译\n编译很简单，与常见的 Go 编译一样，这里我们使用 Golang 官方的 docker 镜像来编译：\ndocker run --rm -v `pwd`:/go/src/go-filter -w /go/src/go-filter \\ -e GOPROXY=https://goproxy.cn \\ golang:1.19 \\ go build -v -o libgolang.so -buildmode=c-shared . Go 编译还是很快的，只需要几秒钟，当前目录下，就会产生一个 libgolang.so 的文件。反观 Envoy 的编译速度，一次全量编译动辄几十分钟，或者上小时的，这幸福感提升了不止一个档次。🥰\n六、运行\n我们可以使用 Envoy 官方提供的镜像来运行，如下示例：\ndocker run --rm -v `pwd`/envoy.yaml:/etc/envoy/envoy.yaml \\ -v `pwd`/libgolang.so:/etc/envoy/libgolang.so \\ -p 10000:10000 \\ envoyproxy/envoy:contrib-dev \\ envoy -c /etc/envoy/envoy.yaml 只需要把上一步编译的 libgolang.so 和 envoy.yaml 挂载进去就可以了。\n值得一提的是，我们需要在 envoy.yaml 配置中启用 Go 扩展，具体是这段配置：\nhttp_filters: - name: envoy.filters.http.golang typed_config: \u0026amp;quot;@type\u0026amp;quot;: type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config library_id: example library_path: /etc/envoy/libgolang.so plugin_name: example-1 跑起来之后，我们测试一下：\n$ curl \u0026#39;http://localhost:10000/\u0026#39; missing token $ curl -s \u0026#39;http://localhost:10000/\u0026#39; -H \u0026#39;token: c64319d06364528120a9f96af62ea83d\u0026#39; -I HTTP/1.1 200 OK 符合期望，是不是很简单呢？\n七、后续\n什么？这个示例太简单？\n是的，这里主要是体验下开发流程，下篇我们将再介绍更高级的玩法：\nGo 接受来自 Envoy 侧的配置、异步 Goroutine，以及与 Istio 配合的用法。\n｜相关链接｜\n[1]envoy-go-filter-example 仓库：\nhttps://github.com/doujiang24/envoy-go-filter-example/tree/master/example-1\n了解更多…\nMOSN Star 一下✨： https://github.com/mosn/mosn\n","date":1679986800,"description":"MoE 系列（一）｜如何使用 Golang 扩展 Envoy","dir":"blog/moe-series (1)|how-to-extend-envoy-with-golang/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e45d3681cf3bc1ea80ee4b37621b372a","permalink":"https://sofastack.github.io/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","publishdate":"2023-03-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","summary":"本文作为 MoE 系列第一篇，主要介绍用 Golang 扩展 Envoy 的极速开发体验。 一、背景 MoE*（MOSN on Envoy）*是 MOSN 团队提出的技术架构，经过近两年的发展，","tags":["SOFAStack"],"title":"MoE 系列（一）｜如何使用 Golang 扩展 Envoy","type":"blog","url":"/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/","wordcount":1163},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区会议 Layotto 主题：Layotto 社区会议 时间：3 月 29 号（下周三）下午 14 点 钉钉会议令：688 824 34655 电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆） 钉钉入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2316789049\n议题： - 2023 开源之夏-课题/导师招募 #894 - Discussion: 自建各种 Component #902 - 希望 Layotto 提供高性能的通信交互能力 #867\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。 想要参加社区建设的同学可以关注社区的新手任务列表，总有一个适合你。\n「Layotto」：\nhttps://github.com/mosn/layotto/issues/907\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@kunple-w #916\n SpringBoot 2.2 废弃了 logging.path，2.3 已删除该属性，应使用 logging.file.pat。 Steps to reproduce the behavior： - 使用 SOFA 3.10.0，按照 SOFA guides 配置 logging.path，启动后并没有出现文档中的一些日志文件。 - 降级为 sample 中的 3.2.0 版本，日志文件出现。 截图如下（2个属性同时配置）: A：SOFA 中间件中使用 sofa-common-tools 打印的日志，日志空间和 SOFABoot 应用程序是隔离的。因此可以同时使用 logging.path 以及 logging.file.path 属性分别定义 SOFA 中间件和 SOFABoot 应用程序的日志路径。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n2.@shuangchengsun #263\n 客户端的上下线，Client1 处于下线过程，此时 Client1 在路由表中的状态是如何维护的？ A：data 上有一个定时器去维护每个 Session 相关数据的，如果 Session 挂了，data 大约 30s 后把挂掉的 Session 的数据清理掉，同时链接挂掉的 Session 上的的 Client（除掉了下的 Client） 会自动重新连接到其他 Session 上，然后会把数据增加一个版本重新注册到 Session 上，Session 会再发到那台数据上。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/issues/263\n本周推荐阅读 应用运行时 Layotto 进入 CNCF 云原生全景图\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1679641200,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230324/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"84510ab87fdbaaab0b53efb84b3e8d41","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230324/","publishdate":"2023-03-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230324/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230324/","wordcount":1242},{"author":null,"categories":"SOFAStack","content":"文｜黄逸炀\nDragonfly Maintainer\n字节跳动火山引擎软件工程师\n专注于镜像存储及镜像 P2P 分发\nPART. 0\n背景\n火山引擎镜像仓库 CR 使用 TOS 来存储容器镜像。目前在一定程度上能满足并发大规模的镜像拉取。然而最终拉取的并发量受限于 TOS 的带宽和 QPS。\n这里简单介绍一下目前针对于大规模拉镜像遇到的两个场景的问题：\n1、客户端数量越来越多，镜像越来越大，TOS 带宽最终无法满足需求。 2、如果客户端使用了 Nydus 对镜像格式做转换之后，对 TOS 的请求量会有数量级的增加，TOS API 的 QPS 限制导致无法满足需求。\n不论是镜像仓库服务本身还是背后的存储，最终肯定是有带宽和 QPS 限制的。如果单纯依赖服务端提供的带宽和 QPS，很容易就无法满足需求。因此需要引入 P2P ，减轻服务端压力，进而满足大规模并发拉取镜像的需求。\nPART. 1\n基于 P2P 技术镜像分发系统调研\n目前开源社区有几个 P2P 项目，这里对这些项目进行简单介绍。\nDragonfly\n架构图\n术语\nManager\n1、存储动态配置供 Seed Peer 集群、Scheduler 集群以及 Dfdaemon 消费。\n2、维护 Seed Peer 集群和 Scheduler 集群之间关联关系。\n3、提供统一异步任务管理，用作预热等功能。\n4、监听各模块是否健康运行。\n5、为 Dfdaemon 筛选最优 Scheduler 集群调度使用。\n6、提供可视化控制台，方便用户操作管理 P2P 集群。\nScheduler\n1、基于机器学习的多场景自适应智能 P2P 节点调度, 为当前下载节点选择最优父节点。\n2、构建 P2P 下载网络的有向无环图。\n3、根据不同特征值评估节点下载能力, 剔除异常节点。\n4、当下载失败情况，主动通知 Dfdaemon 进行回源下载。\nDfdaemon\n1、基于 gRPC 提供下载功能, 并提供多源适配能力。\n2、开启 Seed Peer 模式可以作为 P2P 集群中回源下载节点, 也就是整个集群中下载的根节点。\n3、为镜像仓库或者其他 HTTP 下载任务提供代理服务。\n4、下载任务基于 HTTP 或 HTTPS 或其他自定义协议。\nKraken\n架构图\n术语\nAgent\n1、是 P2P 网络中的对等节点，需要在每个节点上部署。\n2、实现了 Docker Registry interface。\n3、通知 tracker 自己拥有的数据。\n4、下载其他 agent 的数据（tracker 会告诉该 agent 需要下载这块数据需要到哪个 agent 上下载）\nOrigin\n1、负责从存储中读取数据做种。\n2、支持不同的存储。\n3、通过 Hash 环的形式保证高可用。\nTracker\n1、P2P 网络中的协调者，追踪谁是 Peer，谁是 Seeder。\n2、追踪 Peer 拥有的数据。\n3、提供有序的 Peer 节点供 Peer 下载数据。\n4、通过 Hash 环的形式保证高可用。\nProxy\n1、实现了 Docker Registry Interface。\n2、将镜像层传给 Origin 组件。\n3、将 Tag 传给 BUILD INDEX 组件。\nBuild-Index\n1、Tag 和 digest 映射，agent 下载对应 Tag 数据时向 Build-Index 获取对应的 Digest 值。\n2、集群之间镜像复制。\n3、保存 Tag 数据在存储中。\n4、通过 Hash 环的形式保证高可用。\nDragonfly vs Kraken\nPART. 2\n方案\n在火山引擎上，主要考虑 VKE 和 VCI 通过 CR 拉取镜像。\n1、VKE 的产品特点是基于 ECS 部署的 K8S，因此十分适合每个节点部署 Dfdaemon，充分利用每个节点的带宽，进而充分利用 P2P 的能力。\n2、VCI 的产品特点是底层有一些资源很充足虚拟节点。上层的服务是以 POD 为载体，因此无法像 VKE 那样每个节点部署 Dfdaemon，所以部署的形式部署几个 Dfdaemon 作为缓存，利用缓存的能力。\n3、VKE 或 VCI 客户端拉取经过 Nydus 格式转化过的镜像。在该场景下，需要使用 Dfdaemon 作为缓存，不宜使用过多的节点，避免对 Scheduler 造成过大的调度压力。\n基于火山引擎对于以上产品的需求，以及结合 Dragonfly 的特点，需要设计一套兼容诸多因素的部署方案。部署 Dagonfly 的方案设计如下。\nPART. 3\n整体架构图\n1、火山引擎上的资源都是归属于主账号下。P2P 控制组件以主账号级别隔离，每个主账号下一套 P2P 控制组件。服务端实现 P2P Manager Controller，通过该 Controller 来管控控制面所有 P2P 控制组件。\n2、P2P 控制组件部署在镜像仓库数据面 VPC，通过 LB 与用户集群打通。\n3、在 VKE 集群上，Dfdaemon 以 DaemonSet 方式部署，每个节点上部署一个 Dfdaemon。\n4、在 VCI 上，Dfdaemon 以 Deployment 方式部署。\n5、ECS 上 Containerd 通过 127.0.0.1:65001 访问本节点上的 Dfdaemon。\n6、通过在用户集群部署一个 controller 组件，基于 PrivateZone 功能，在用户集群生成.p2p.volces.com 域名， controller 会根据一定的规则挑选特定节点*（包括 VKE、VCI）*的 Dfdaemon pod，以 A 记录的形式解析到上述域名。\n ECS 上 Nydusd 通过.p2p.volces.com 域名访问 Dfdaemon。 VCI 上镜像服务客户端和 Nydusd 通过.p2p.volces.com 域名访问 Dfdaemon。 PART. 4\n压测数据\n环境\n镜像仓库：带宽 10Gbit/s。\nECS: 4C8G，挂载本地盘，带宽 6Gbit/s。\n镜像\nNginx (500M)\nTensorFlow (3G)\n组件版本\nDragonfly v2.0.8。\nQuota\nDfdaemon: Limit 2C6G。\nScheduler: 2 Replicas，Request 1C2G，Limit 4C8G。\nManager: 2 Replicas，Request 1C2G，Limit 4C8G。\nPOD 启动时间对比\nNginx Pod 分别并发 50、100、200、500 的所有 Pod 从创建到启动消耗时间。\nTensorFlow Pod 分别并发 50、100、200、500 的所有 Pod 从创建到启动消耗时间。\n在大规模拉镜像的场景下，在使用 Dragonfly 和 Dragonfly \u0026amp;amp; Nydus 场景对比 OCIv1 场景能够节省 90% 以上的容器启动时间。使用 Nydus 之后启动时间更短是因为镜像 lazyload 的特性，只需要拉取很小的一部分元数据 Pod 就能启动。\n存储源端带宽峰值对比\nNginx Pod …","date":1679382000,"description":"火山引擎基于 Dragonfly 加速实践","dir":"blog/volcano-engine-based-on-dragonfly-acceleration-practices/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"21e4e09162503066e2909a462942331d","permalink":"https://sofastack.github.io/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","publishdate":"2023-03-21T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","summary":"文｜黄逸炀 Dragonfly Maintainer 字节跳动火山引擎软件工程师 专注于镜像存储及镜像 P2P 分发 PART. 0 背景 火山引擎镜像仓库 CR 使用 TOS 来存储容器镜像。目前在一定程度上能满足并发","tags":["SOFAStack"],"title":"火山引擎基于 Dragonfly 加速实践","type":"blog","url":"/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/","wordcount":3113},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA 社区会议\nMOSN\n主题：MOSN 2023 社区会议 时间：3 月 23 号（下周四）晚上 19 点 钉钉会议号：689 448 86753 电话呼入：+862759771614（中国大陆） 钉钉入会链接：https://meeting.dingtalk.com/j/vvE0uCA0vQT\n议题： 回顾 MOSN 去年进展及今年的规划。 邀请部分 MOSN 用户来分享落地经验、发展规划。 共商 MOSN 2023 发展大计。\n另外，还邀请了 Higress 社区来互动交流，探讨合作空间。 Service Mesh、Gateway、Envoy、Istio、ztunnel 等等大家关注的话题，也可以在这里交流。欢迎大家参会讨论~\n「 MOSN 」：https://github.com/mosn/mosn\nLayotto\n主题：Layotto 社区会议 时间：3 月 22 号（下周三）下午 14 点 钉钉会议令：688 824 34655 电话呼入：+862759771621（中国大陆）+8657128356288（中国大陆） 钉钉入会链接：dingtalk://dingtalkclient/page/videoConfFromCalendar?confId=1cebca80-e8cd-4f26-b529-79bac0ce7493\u0026amp;amp;appendCalendarId=1\u0026amp;amp;calendarId=2299840541\n议题： Discussion: 自建各种 Component #902 希望 Layotto 提供高性能的通信交互能力 #867\n欢迎感兴趣同学参加，有任何想交流讨论的议题可以直接留言。 想要参加社区建设的同学可以关注社区的新手任务列表，总有一个适合你。\n「Layotto」： https://github.com/mosn/layotto/issues/902 https://github.com/mosn/layotto/issues/867\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@LY1806620741 #1061\ncom.alipay.sofa.rpc.enable-swagger 在 3.16.3 是否已经废弃\n配置使用了 Objectway 的 asm，与 Springboot 的 asm 冲突。 另外，没有在 SOFABoot 文档上找到所有的属性说明。\n重现该行为的步骤：\n运动单 SOFABoot\n配置 com.alipay.sofa.rpc.enable-swagger=true\n启动并访问*http://localhost:8341/swagger/bolt/api *\ndebug 可以看到找不到 class objectway.classvisitor\n引入 asm.jar 后会与 sping 框架的 asm org.springframework.asm.ClassVisitor 冲突\nA：看起来是 https:/github.com/sofastack/sofa-rpc/blob/5.8.3.1/all/pom.xml 少添加了一个 asm 的依赖，导致出现上面的问题。\n「SOFABoot」：https://github.com/sofastack/sofa-boot/issues/1061\n2.@springcoco #589\n关于多部网站代码解析的一些疑问，在多网站这一章节，发现这样说： 我的疑惑是 Spring 是如何判定 ArkTomcatEmbeddedWebappClassLoader 类存在呢？ 在加载 ArkTomcatServletWebServerFactory 的时候，我发现也会加载 Tomcat 默认的 Server Factory，如何最终判定周 WebServer 使用 ArkWebServerFacticServletTomcat 使用 Ark。 A：ArkTomcatEmbeddedWebappClassLoader 作为一个判断条件，如果没有使用 web-ark-plugin，意味着没有 ArkTomcatEmbeddedWebappCl\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/589\nMOSN 1.0 发布，开启新架构演进\n社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析\nMOSN 反向通道详解\n蚂蚁集团境外站点 Seata 实践与探索\n","date":1679036400,"description":"SOFA Weekly | MOSN、Layotto 社区会议通知、Seata 版本发布","dir":"blog/sofa-weekly-230317/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1827a7e4749437ae2082098f18a52e18","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230317/","publishdate":"2023-03-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-230317/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、Layotto 社区会议通知、Seata 版本发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-230317/","wordcount":1402},{"author":null,"categories":"SOFAStack","content":" 发布概览 Seata-go 1.1.0 版本补齐了 AT 模式下对 Multi Delete、Multi Update、Insert on Update 和 Select for Update 的支持。至此 Seata-go 的 AT 模式与 Seata AT 模式全面对齐。\n此版本给出了在 Dubbo-go/Gin/gRPC 中使用 Seata-go TCC/AT 两种模式的示例。\n示例链接：https://github.com/seata/seata-go-samples/tree/main/at\nAT 模式:\n AT 模式支持并集成了 Multi Delete SQL 语法 AT 模式支持并集成了 Multi Update SQL 语法 AT 模式支持并集成了 Insert on Update SQL 语法 AT 模式支持并集成了 Select for Update SQL 语法 配置文件：\n完善了更多地方读取配置文件功能\n版本的主要更新如下 Feature： [#491] 支持查询全局事务锁 https://github.com/seata/seata-go/pull/491\n[#482] 支持 AT 模式 Multi Delete SQL 执行器 https://github.com/seata/seata-go/pull/482\n[#481] 支持 AT 模式 Multi Update SQL 执行器 https://github.com/seata/seata-go/pull/481\n[#478] 支持 AT 模式 Select for Update SQL 执行器 https://github.com/seata/seata-go/pull/478\n[#477] 支持 Undo Log 的 Json 序列化方式 https://github.com/seata/seata-go/pull/477\n[#456] 支持 AT 模式 Insert on Update SQL 执行器 https://github.com/seata/seata-go/pull/456\n[#444] 支持 BZip 压缩算法 https://github.com/seata/seata-go/pull/444\n[#436] 支持读取 RM 相关的配置文件 https://github.com/seata/seata-go/pull/436\n[#433] 支持 XA 连接管理器 https://github.com/seata/seata-go/pull/433\n[#430] 支持读取 Getty 相关的配置文件 https://github.com/seata/seata-go/pull/430\nBugfix：\n[#509] 修复 AT 模式下执行 Insert on Update 时 Undo Log 的 SQLType 字段的问题 https://github.com/seata/seata-go/pull/509\n[#495] 修复 Undo Log 的 SQLType 字段的问题 https://github.com/seata/seata-go/pull/495\n[#487] 修复 AT 执行时出现的问题 https://github.com/seata/seata-go/pull/487\n[#472] 修复全局事务中上下文丢失值问题 https://github.com/seata/seata-go/pull/472\n[#461] 修复 Error_Code_test 中变量未定义导致的 CI 失败问题 https://github.com/seata/seata-go/pull/461\n[#459] 修复 Error 日志重复打印问题 https://github.com/seata/seata-go/pull/459\n[#452] 修复 AT 模式执行 Insert SQL 时 ID 增的报错问题 https://github.com/seata/seata-go/pull/452\nOptimize：\nSeata-go 的示例项目已经全部迁移到新的仓库：https://github.com/seata/seata-go-samples\n[#507] 优化 AT 模式 Multiple Update SQL 执行器 https://github.com/seata/seata-go/pull/507\n[#505] 优化 AT 模式 Multi SQL 执行器 https://github.com/seata/seata-go/pull/505\n[#453] 优化 Message Type 和 Transaction error Code 枚举值 https://github.com/seata/seata-go/pull/453\n[#447] 优化数据源初始化流程 https://github.com/seata/seata-go/pull/447\n[#466] 优化变量的命名 https://github.com/seata/seata-go/pull/466\nTest:\n[#445] 添加 Transaction error Code 的单元测试 https://github.com/seata/seata-go/pull/445\nDoc:\n[#492] 更新 Readme 文件的已完成功能列表 https://github.com/seata/seata-go/pull/492\n[#489] 添加 1.1.0 版本的 Change Log https://github.com/seata/seata-go/pull/489\n英文版：https://github.com/seata/seata-go/releases/tag/v1.1.0\n致谢\n非常感谢以下 Contributors 的代码贡献。若有无意遗漏，请报告。\n@luky116 https://github.com/luky116\n@georgehao https://github.com/georgehao\n@lxfeng1997 https://github.com/lxfeng1997 @106umao https://github.com/106umao @wang1309 https://github.com/wang1309 @iSuperCoder https://github.com/iSuperCoder @Charlie17Li https://github.com/Charlie17Li @Code-Fight https://github.com/Code-Fight @Kirhaku https://github.com/Kirhaku @Vaderkai https://github.com/VaderKai @springrain https://github.com/springrain @Shaozhou Hu https://github.com/raspberry-hu …","date":1678777200,"description":"Seata-go 1.1.0 发布，补齐 AT 模式支持","dir":"blog/seata-go-1-1-0-released-completes-at-mode-support/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e92a21aaa50425c14c2a8462c1d96e2e","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","publishdate":"2023-03-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","summary":"发布概览 Seata-go 1.1.0 版本补齐了 AT 模式下对 Multi Delete、Multi Update、Insert on Update 和 Select for Update 的支持。至此 Seata-go 的 AT 模式与 Seata AT 模式全面对齐。 此","tags":["SOFAStack"],"title":"Seata-go 1.1.0 发布，补齐 AT 模式支持","type":"blog","url":"/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/","wordcount":1353},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 2 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@linkoog #602\n 首先我使用了 Ark-Guides 和 Ark-biz 的示例进行操作。 可以正常加载模板，但配置文件加载不到。 Start 是启动模块， Config 是配置的存储释放模块。 试了下面两种方式，都读到不到配置文件 1、直接打包 Config 的 Jar 中 2、在 Start 模板下面放 Conf/Ark/ 环境 沙发方舟版本：2.0.8 JVM 版本（例如 Java -Version ）：1.8.333 操作系统版本（例如 Uname -a ）：macOS 行家版本： 集成开发环境版本\n A：配置文件的配置应和 Spring Boot 应用保持一致，建议把配置文件放至 Resources 目录下。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/issues/602\n2.@SpringLin97 #928\n Jraft 支持 IPV6 组建集群吗？\n A：1.3.5 以后版本支持 IPV6。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft/issues/928\n本周推荐阅读 DLRover：蚂蚁开源大规模智能分布式训练系统\nNydus 在约苗平台的容器镜像加速实践\nWasm 原生时代已经来到\nGo 语言，如何做逆向类型推导?\n","date":1678431600,"description":"SOFA Weekly | SOFANews、开源人 \u0026 issue 精选","dir":"blog/sofa-weekly-20230310/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c8fb3a67d5797275149ca3410ab9631e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230310/","publishdate":"2023-03-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230310/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、开源人 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230310/","wordcount":684},{"author":null,"categories":"SOFAStack","content":" 文｜沙剑 蚂蚁集团高级技术专家 专注分布式深度学习领域 主要负责蚂蚁大规模分布式训练引擎的设计和开发\n 本文 4491 字 阅读 12 分钟\n本文整体介绍了 DLRover 的项目动机与核心能力，未来我们会发布一系列文章，来从同步/异步弹性训练，优化策略服务，多种集群和训练框架对接，策略定制开发等多个角度来介绍 DLRover 的更多细节，敬请期待。\n技术背景 2022 年 6 月，蚂蚁集团决定全面引入 ESG 框架，启动并确立了“数字普惠”、“绿色低碳”、“科技创新”、“开放生态”四位一体的可持续发展战略。针对“绿色低碳”，设立了 4 个子议题，包括绿色运营、科技助力产业碳中和、生态保护与修复绿色低碳生活。\n在此背景下，绿色 AI 也成为蚂蚁 AI Infra 团队的一个重要工作方向。作为绿色 AI 的重要板块，工程提效项目致力于打造高性能离在线 AI 工程体系，通过提升算力效率和资源利用率，最终达到节省资源降低碳排放的目的。\n当前，用户提交分布式训练作业的工具有 Yarn 或者 KubeFlow/Training-Operator。在提交作业时，用户需要在作业中指定作业资源，包括不同角色的节点数量和资源规格（CPU 核数、内存、GPU 等）。\n在训练作业提交后，作业可能遇到如下问题： - 集群资源不足以启动作业的所有节点，作业只能等待。 - 训练作业的节点可能会出错，比如被高优任务抢占、机器故障、IO 故障等，导致作业失败。\n出现这些问题后，用户只能修改作业资源来重新提交作业。\n针对这两个问题，蚂蚁集团早期基于 Kubernetes 开源了 ElasticDL 项目来支持 K8s 上 TF 2.x 分布式训练的弹性容错。在项目落地过程中我们又发现了如下问题： - 用户配置的资源可能过少引起 OOM 和训练性能差。 - 用户为了保障作业成功率和速度，通常会配置超额资源导致利用率低。 - 越来越多的用户使用 PyTorch 或其他 TF 之外的框架来开发和训练模型。 - 越来越多的分布式集群开始支持 AI 作业，比如 Ray、Spark 集群，能否适配任意计算集群？ - 在线学习越来越被广泛采用的情况下，如何运用一套系统同时解决兼容离在线训练？\n前两个问题使得集群 CPU 利用率通常只有 20% 上下，同时算法开发人员需要投入很多人工运维成本，为了解决训练端资源提效的需求，支持在不同集群上针对在离线多种训练模式，给不同框架的分布式训练作业自动地寻找最优资源配置。\n蚂蚁 AI Infra 团队基于 ElasticDL 弹性容错的思路，升级扩展并开源了 DLRover，其目标在于提升分布式模型训练的智能性，目前很多公司的训练作业都是跑在混部的集群中，运行环境复杂多变，正如其名，DLRover 作为分布式训练领域的 “路虎”，不管多么崎岖的地形，都可以轻松驾驭。\n整体方案 DLRover 提出了 “ML for System” 的理念来提升分布式训练的智能性，那么这样的系统应该具备哪些能力呢？\n我们认为主要体现在如下几个方面： - 解耦：不和底层训练框架耦合在一起，只依赖接口抽象，遵循依赖倒置原则。（*i.e. Elastic Runtime*） - 资源调度：具备上帝视角的资源调度管控能力。和建立在对作业精准画像的决策能力。 - 数据驱动：同时收集掌握集群资源数据，也掌握训练作业数据。以数据驱动智能。 - 作业交互：以对训练作业以及模型白盒化的理解，动态根据实际情况，对训练作业进行优化调整。超越简单机械的弹性容错！ - 智能：通过对集群以及作业信息的收集，结合算法模型+固定策略产出精准的作业优化策略。\n我们希望设计并实现一个系统，让用户完全摆脱资源配置的束缚，专注于模型训练本身。在没有任何资源配置输入的情况下，DLRover 仍然可以为每个训练作业提供最佳资源配置。考虑到用户可能会以不同的方式运行他们的训练作业，DLRover 除了面向训练平台进行作业统一管理的 Cluster Mode，也提供 Single-Job Mode 方便独立的算法开发者也能享受到弹性容错等基本特性。\n系统架构 DLRover 由四个主要组件组成：ElasticJob、Elastic Trainer、Brain 服务和 Cluster Monitor。\n上图显示了 DLRover 如何在 K8s 集群上管理深度学习训练作业。DLRover 以 ElasticJob CRD 的形式将作业提交到集群。收到 CRD 后，ElasticJob Operator 会拉起一个 Master Pod 作为 Elastic Trainer。其从 Brain 服务中获取初始资源计划。Elastic Trainer 用它来创建 Scale CRD，并应用 Scale CRD 通知 ElasticJob Controller 启动所需的 Pod，每个 Pod 将在其上启动一个 Elastic Agent。\n在训练过程中，Elastic Trainer 的 Training Master 将数据分片分发给 Worker。同时，Cluster Monitor 监控每个作业的运行状态（*i.e.每个节点的 Workload*）和集群状态（*i.e. 资源水位*）。这些数据将定期报告给 Brain，Brain 将数据持久化到数据库中。\n然后 DLRover Brain 根据作业的运行状态，选择合适的算法生成新的资源计划，并通知 Elastic Trainer 开始资源调整。\n总的来讲，DLRover 可以帮助分布式训练作业自动化运行在集群中，可以看作分布式作业的自动驾驶，模型开发者只需要关注模型的算法设计，DLRover 目前开源版则可以为用户提供如下能力： - 自动资源推导：帮助用户自动初始化训练资源，提升资源利用率与作业稳定性。 - 动态训练数据分片：针对不同 Worker 性能不通造成的木桶效应，根据实际消费速度分配训练数据，可配合 Failover 记录消费位点，数据不丢失。 - 单点容错：提供单点容错的能力，不需要完整重启作业。 - 资源弹性：支持运行时 Pod 级和 CPU/Memory 级的资源弹性扩缩容，动态全局优化决策。\nDLRover 能带来什么 1.作业零资源参数配置 用户提交分布式作业时无需提供任何资源信息，DLRover 会自动对作业进行画像，推导出最优的资源配置，同时运行时可以根据实际情况（*集群资源、样本流量、当前利用率、\u0026amp;hellip;*）自动对资源进行调整。下面展示了两种提交脚本的配置对比：\n2.单点容错提升作业稳定性与恢复效率 DLRover 支持单点恢复 Parameter Server 和 Worker 角色的失败退出而不需要整体作业重启，对于非用户代码和数据类型的错误可以实现用户无感的重启。例如集群中，很常见的一类错误是由于用户配置了不足的内存，导致训练 OOM。在 DLRover 的帮助下，我们可以自动拉起一个优化配置的节点来恢复失败的 Node。在真实环境下，DLRover 管理的训练作业，相比基线的 Kubeflow TF-Operator 作业，训练成功率从 84% 提升到了 95% 以上。 …","date":1678172400,"description":"DLRover：蚂蚁开源大规模智能分布式训练系统","dir":"blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d19aa2ffa0b2368819bac80add901dfb","permalink":"https://sofastack.github.io/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","publishdate":"2023-03-07T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","summary":"文｜沙剑 蚂蚁集团高级技术专家 专注分布式深度学习领域 主要负责蚂蚁大规模分布式训练引擎的设计和开发 本文 4491 字 阅读 12 分钟 本文整体介绍了 DLRover 的项目动机与","tags":["SOFAStack"],"title":"DLRover：蚂蚁开源大规模智能分布式训练系统","type":"blog","url":"/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/","wordcount":3919},{"author":null,"categories":"SOFAStack","content":" SOFA Weekly｜铜锁探「密」、本周贡献 \u0026amp;amp; issue 精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@ZhengweiHou #1313\n 同一台机器启动两个 SOFA 进程，开启端口自适应（AdaptivePort），但是两个进程服务注册端口一致，但实际生效端口不一致。通过验证端口自适应逻辑发现我的机器上（ServerSocket.bind) 预期结果不一致。详细情况如图所示：\n A：AdaptivePort 的逻辑在 可以看下这块代码。\ncom.alipay.sofa.rpc.server.ServerFactory#resolveServerConfig\n和你理解的应该不太一样。\n「SOFARPC」: https://github.com/sofastack/sofa-rpc/issues/1313\n**2.@hanzhihua ** #934\n 咨询一个问题，Closure Threadpool 使用 SynchronousQueue 而不使用其他的有缓存的 Queue，是怎么考虑的呢？\n A：主要是原因是希望在任务量大 Core Thread 饱和的时候尽快新增线程来更快的处理任务，中间加一个 Queue 会影响到，Java Threadpool 的策略你懂的，需要 Queue 满了后 MaximumThreads 参数的值才发挥作用。\n「SOFAJRaft」： https://github.com/sofastack/sofa-jraft/issues/934\n3.@penglinzhang #612\n 静态合并部署时，为什么宿主应用会把子业务应用中的 Bean 也会扫描注册到自己的 ApplicationContext 中，而不是仅仅把子应用作为一个特殊 Jar 包？\n A：由于你的宿主应用 @ComPonentScan 扫描了 “com.alipay.sofa”，并且你的业务 Bean 也是 com/alipay/sofa 路径下的，你可以尝试将业务包 Spring-Boot-Ark-Biz 的路径改成自定义的。\n「SOFAArk」： https://github.com/sofastack/sofa-ark/issues/612\n本周推荐阅读\nSOFARegistry | 聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1677826800,"description":"","dir":"blog/sofa-weekly-20230303/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1b93b164611c557c53757d288b2e2d77","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230303/","publishdate":"2023-03-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230303/","summary":"SOFA Weekly｜铜锁探「密」、本周贡献 \u0026amp; issue 精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Sta","tags":["SOFAStack"],"title":"SOFA Weekly｜铜锁探「密」、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230303/","wordcount":802},{"author":null,"categories":"SOFAStack","content":" 文 | 向申 约苗平台运维工程师 关注云原生领域\n本文字数 9574 阅读时间 24 分钟\n 本文是来自向申同学的分享，介绍了其在 K8s 生产环境集群部署 Nydus 的相关实践。\nNydus 是蚂蚁集团，阿里云和字节等共建的开源容器镜像加速项目，是 CNCF Dragonfly 的子项目，Nydus 在 OCI Image Spec 基础上重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。详情文档请参考如下地址：\n Nydus 官方网站：https://nydus.dev/\n Nydus Github：https://github.com/dragonflyoss/image-service\n PART.1\n容器镜像的概念 1. 容器镜像 容器镜像有一个官方的类比，\u0026amp;rdquo;生活中常见的集装箱\u0026amp;rdquo;，虽然拥有不同的规格，但箱子本身是不可变的（*Immutable*），只是其中装的内容不同。\n对于镜像来说，不变的部分包含了运行一个应用软件（如 MySQL ）所需要的所有元素。开发者可以使用一些工具（*如 Dockerfile*）构建出自己的容器镜像，签名并上传到互联网上，然后需要运行这些软件的人可以通过指定名称（*如 example.com/my-app*）下载、验证和运行这些容器。\n2. OCI 标准镜像规范 在 OCI 标准镜像规范出台之前，其实有两套广泛使用的镜像规范，分别是 Appc 和 Docker v2.2，但“合久必分，分久必合”，有意思的是两者的内容已经在各自的发展中逐步同化了，所以 OCI 组织顺水推舟地在 Docker v2.2 的基础上推出了 OCI Image Format Spec，规定了对于符合规范的镜像，允许开发者只要对容器打包和签名一次，就可以在所有的容器引擎上运行该容器。\n这份规范给出了 OCI Image 的定义：\nThis specification defines an OCI Image, consisting of a manifest, an Image Index (optional), a set of filesystem layers, and a Configuration.\n3. 容器的工作流程 一个典型的容器工作流程是从由 Developers 制作容器镜像开始的（*Build*），然后上传到镜像存储中心（*Ship*），最后部署在集群中（*RUN*）。\nPART.2\nOCI 镜像格式 通常所说的镜像文件其实指的是一个包含了多个文件的“包”，“包”中的这些文件提供了启动一个容器所需要的所有需要信息，其中包括但不限于，容器所使用的文件系统等数据文件，镜像所适用的平台、数据完整性校验信息等配置文件。当我们使用 Docker pull 或者 Nerdctl pull 从镜像中心拉取镜像时，其实就是在依次拉取该镜像所包含的这些文件。\nNerdctl 依次拉取了一个 Index 文件、一个 Manifest 文件、一个 Config 文件和若干个 Layer 数据文件。实际上，一个标准的 OCI 镜像通常就是由这几部分构成的。\n其中，Layer 文件一般是 tar 包或者压缩后的 tar 包，其包含着镜像具体的数据文件。这些 Layer 文件会共同组成一个完整的文件系统（*也就是从该镜像启动容器后，进入容器中看到的文件系统*） 。\nConfig 文件是一个 JSON 文件。其中包含镜像的一些配置信息，比如镜像时间、修改记录、环境变量、镜像的启动命令等等。\nManifest 文件也是一个 JSON 文件。它可以看作是镜像文件的清单，即说明了该镜像包含了哪些 Layer 文件和哪个 Config 文件。\n下面是一个 Manifest 文件的典型例子：\n\u0026amp;quot;schemaVersion\u0026amp;quot;: 2, \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.manifest.v1+json\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.config.v1+json\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:0584b370e957bf9d09e10f424859a02ab0fda255103f75b3f8c7d410a4e96ed5\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 7636 }, \u0026amp;quot;layers\u0026amp;quot;: [ { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:214ca5fb90323fe769c63a12af092f2572bf1c6b300263e09883909fc865d260\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 31379476 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:50836501937ff210a4ee8eedcb17b49b3b7627c5b7104397b2a6198c569d9231\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 25338790 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:d838e0361e8efc1fb3ec2b7aed16ba935ee9b62b6631c304256b0326c048a330\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 600 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:fcc7a415e354b2e1a2fcf80005278d0439a2f87556e683bb98891414339f9bee\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 893 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: …","date":1677567600,"description":"Nydus 在约苗平台的容器镜像加速实践","dir":"blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7e9b91c041e413e6e7587da7c34f0e22","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","publishdate":"2023-02-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","summary":"文 | 向申 约苗平台运维工程师 关注云原生领域 本文字数 9574 阅读时间 24 分钟 本文是来自向申同学的分享，介绍了其在 K8s 生产环境集群部署 Nydus 的相关实践。 Nydus 是蚂蚁","tags":["SOFAStak"],"title":"Nydus 在约苗平台的容器镜像加速实践","type":"blog","url":"/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/","wordcount":4215},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 4 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@linkoog #602\n SOFAArk 2.0 合并部署时，ark-biz 无法读取配置文件\n A：配置文件的配置应该和 Spring Boot 应用保持一致，建议把配置文件放置到 resources 目录下。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.@tdxafpdq #925\n 消息中间件业务场景下，如何使用 Snapshot 服务，以解决磁盘占用持续增长以及全量回放变慢。\n A：消息场景下，还是控制消息的总量，通过 TTL 等机制来及时删除过期的消息，如果是同步数据库的场景，可以使用 Snapshot 来做检查点（Checkpoint），Snapshot 本身可能只做一些数据库状态校验的动作，确保 Snapshot log index 之前的日志都已经同步复制完成，然后 JRaft 就可以释放之前的日志。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 SOFARegistry｜聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\n降本增效：蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构\n欢迎扫码关注：\n","date":1676617200,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230217/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f937156cef65231cd51d07b5c8c4f9c7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230217/","publishdate":"2023-02-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230217/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230217/","wordcount":695},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区\n 活动时间：02 月 25 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：待直播后更新\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#32 你的开源入门指南——Kata Containers 社区 如今“参与开源”已然成为很多技术人追赶的浪潮。但有些人苦于找不到参加途径，有些人畏畏缩缩不敢发声，或者是由于开源项目众多，不知道该如何挑选\u0026amp;hellip;\u0026amp;hellip;在本期 SOFAChannel#32 的节目中，我们邀请到了 Kata Containers 社区新星姚胤楠同学，给大家带来开源入门指南！Kata Containers 是一种基于硬件虚拟化技术、兼容 OCI/CRI 等协议的容器运行时技术，可以完美地运行在 Kubernetes 集群之上。Kata Containers 比传统容器提供了更高的安全性和更强的隔离性，同时具备快速启动和部署的优势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 姚胤楠\n Kata Containers Contributor\n 议程 直播回放 待直播后更新\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1676530800,"description":"2023 年 02 月 25 日 19：00 - 20：00 ，线上直播第 32 期。","dir":"activities/sofa-channel-32/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7ece90c394a1f25d260f0d79aa6a80b0","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-32/","publishdate":"2023-02-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-32/","summary":"概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区 活动时间：02 月 25 日，周四晚 19 点 活动形式：线上直播 资料下载：待","tags":["SOFAChannel","Kata Containers","你的开源入门指南"],"title":"SOFAChannel#32 你的开源入门指南——Kata Containers 社区","type":"activities","url":"/sofastack.tech/activities/sofa-channel-32/","wordcount":569},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区\n 活动时间：02 月 25 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：待直播后更新\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#32 你的开源入门指南——Kata Containers 社区 如今“参与开源”已然成为很多技术人追赶的浪潮。但有些人苦于找不到参加途径，有些人畏畏缩缩不敢发声，或者是由于开源项目众多，不知道该如何挑选\u0026amp;hellip;\u0026amp;hellip;在本期 SOFAChannel#32 的节目中，我们邀请到了 Kata Containers 社区新星姚胤楠同学，给大家带来开源入门指南！Kata Containers 是一种基于硬件虚拟化技术、兼容 OCI/CRI 等协议的容器运行时技术，可以完美地运行在 Kubernetes 集群之上。Kata Containers 比传统容器提供了更高的安全性和更强的隔离性，同时具备快速启动和部署的优势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 姚胤楠\n Kata Containers Contributor\n 议程 直播回放 待直播后更新\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1676444400,"description":"2023 年 02 月 16 日 19：00 - 20：00 ，线上直播第 32 期。","dir":"activities/sofachannel-32/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f529a5fffabf35600dcecdc9b513fe85","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofachannel-32/","publishdate":"2023-02-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofachannel-32/","summary":"概要 活动主题：SOFAChannel#32:你的开源入门指南——Kata Containers 社区 活动时间：02 月 25 日，周四晚 19 点 活动形式：线上直播 资料下载：待","tags":["SOFAChannel","Kata Containers","你的开源入门指南"],"title":"SOFAChannel#32 你的开源入门指南——Kata Containers 社区","type":"activities","url":"/sofastack.tech/activities/sofachannel-32/","wordcount":569},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者蚂蚁集团技术专家\n专注于云原生网关研发的相关工作。\n本文 224 字 阅读 8 分钟\nPART. 1\n引言 在上回的文章《Go 内存泄漏，pprof 够用了么？》中说到，从一个 core 文件生成内存引用关系火焰图时，虽然可以从 core 文件中读到所有的内存对象，但是并不知道它们的类型信息。\n这是因为 Go 作为静态类型语言，在运行时，内存对象的类型是已知的。也就是说，并不需要想动态类型语言那样，为每个内存对象在内存中存储其类型信息 （有点例外的是 interface） 。\n比如这个 Go 语言例子：\ntype Foo struct { a uint64 b int64} func foo(f *Foo) int64 { return f.b} Foo 函数在使用 f 这个指针时，并不需要判断其类型，直接读一个带偏移量地址就能得到 f.b，也就是一条指令：mov rax, qword ptr [rax + 8]，就是这么简单直接。\n再看 Lua 语言这个例子：\nfunction foo(f) return f.bendfoo({ b = 1 }) Foo 函数在执行的时候，首先得判断 f 的类型，如果是 table，则按照 key 取 b 的值；如果不是，则抛运行时 error。\n能够运行时判断 f 的类型，是因为 Lua 中变量是用 TValue 来表示的，这个 TValue 结构中，就有一个信息用来存储变量类型。\nPART. 2\n逆向类型推导 逆向类型推导的逻辑是：根据已知内存的类型信息，推导被引用的内存对象的类型信息。\n比如这个例子：\ntype Foo struct { a uint64 b int64}type Bar struct { f *Foo}var b Bar 如果我们知道了 b 的类型是 Bar，那么 b 中第一个 field 指向的内存对象，就是 Foo 类型了 （前提是合法的内存对象地址） 。\n既然存在推导，那我们怎么知道一些初始值呢？\n一共有两类来源：\n1.全局变量；\n2.协程中每一帧函数的局部变量。\nPART. 3\n全局变量 Go 在编译的时候，默认会生成一些调试信息，按照 DWARF 标准格式，放在 ELF 文件中 .debug_* 这样的段里。\n这些调试信息中，我们关注两类关键信息：\n 类型信息： 包括了源码中定义的类型，比如某个 struct 的名字、大小、以及各个 field 类型信息；\n 全局变量： 包括变量名、地址、类型，调试信息中的、全局变量的地址、以及其类型信息，也就是构成推导的初始值。\n 函数局部变量，要复杂一些，不过基本原理是类似的，这里就不细说了~\nPART. 4\n推导过程 推导过程，跟 GC-Mark 的过程类似，甚至初始值也跟 GC-Root 一样。\n所以，全部推导完毕之后，GC-Mark 认为是 alive 的内存对象，其类型信息都会被推导出来。\ninterface\nGo 语言中 interface 比较类似动态类型，如下是空接口的内存结构，每个对象都存储了其类型信息：\ntype eface struct { _type *_type data unsafe.Pointer} 按照类型推导，我们能知道一个对象是 interface{}，但是其中 Data 指向对象，是什么类型，我们则需要读取 _type 中的信息了。\n_type 中有两个信息，对我们比较有用：\n1.名字\n不过比较坑的是，只存了 pkg.Name 并没有存完整的 Include Path 这个也合理的，毕竟 Go 运行时并不需要那么精确，也就是异常时，输出错误信息中用一下。不过在类型推导的时候，就容易踩坑了。\n2.指针信息\n具体存储形式有点绕，不过也就是表示这个对象中，有哪些偏移量是指针。\n有了这两个信息之后，就可以从全量的类型中，筛选出符合上面两个信息的类型。\n通常情况下，会选出一个正确的答案，不过有时候选出多个，仅仅根据这两个信息还不能区分出来，一旦一步错了，后面可能就全推导不出来了。\n我们给 Go 官方 Debug 贡献了一个补丁，可以进一步的筛选，有兴趣的可以看 CL 419176[1]。\nunsafe.pointer\n其实，在上面的 interface 示例中，最根源的原因，也就是 data unsafe.pointer，这个指针并没有类型信息，只是 interface 的实现中，有另外的字段来存储类型信息。\n不过，在 Go Runtime 中还有其它的 unsafe.pointer，就没有那么幸运了。\n比如 map 和 sync.map 的实现都有 unsafe.pointer，这种就没有办法像 interface 那样统一来处理了，只能 case-by-case，根据 map/sync.map 的结构特征来逆向写死了\u0026amp;hellip;\n我们给 Go 官方 Debug 贡献了 sync.map 的逆向实现，有兴趣的可以看 CL 419177[2]。\nPART. 5\n隐藏类型 除了源码中显示定义的类型，还有一些隐藏的类型，比如：Method Value、Closure 的实现中，也都是用 struct 来表示的，这些属于不太容易被关注到的“隐藏”类型。\nMethod Value 在逆向推导中，还是比较容易踩坑的，我们给 Go 官方 Debug 贡献了这块的实现，有兴趣的可以看 CL 419179[3]。\n相比 Method Value 这种固定结构的，Closure 这种会更难搞一些，不过幸运的是，我们目前的使用过程中，还没有踩坑的经历。\nPART. 6\n逆向推导风险 这种逆向推导要做到 100% 完备还是挺难的，根本原因还是 unsafe.pointer。\n在 reflect.Value 中也有 unsafe.pointer，据我所知，这个是还没有逆向推导实现的，类似的应该也还有其它未知的。\n甚至，如果是标准库中的类型，我们还是可以一个个按需加上，如果是上层应用代码用到的 unsafe.pointer，那就很难搞了。\n还有一种可能，推导不出来的原因，就是内存泄漏的来源，我们就碰到这样一个例子，以后有机会再分享~\n幸运的是：如果是只是少量的对象没有推导出来，对于全局内存泄漏分析这种场景，通常影响其实也不大。\n另外，对于一个对象，只需要有一个路径可以推导出来也就够了。\n也就是说，如果一条推导线索因为 unsafe.pointer 断了，如果另外有一个线索可以推导到这个对象，那也是不影响的。因为从 GC root 到一个 GC obj 的引用关系链，可能会不止一条。\nPART. 7\n小结 Go 虽然是静态类型语言，不过由于提供了 unsafe.pointer，给逆向类型推导带来了很大的麻烦。好在 Go 对于 unsafe.pointer 的使用还是比较克制，把标准库中常用到的 unsafe.pointer 搞定了，基本也够用了。\n理论上来说，逆向推导这一套也适用于 C 语言，只不过 C 语言这种指针漫天飞的，动不动就来个强制类型转换，就很难搞了。\n｜相关链接｜\n[1]CL …","date":1676358000,"description":"Go 语言，如何做逆向类型推导?","dir":"blog/Go-language-how-to-do-inverse-type-derivation/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"38703e8299b15a8a7e65645ff69c5926","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","publishdate":"2023-02-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者蚂蚁集团技术专家 专注于云原生网关研发的相关工作。 本文 224 字 阅读 8 分钟 PART. 1 引","tags":["MOSN"],"title":"Go 语言，如何做逆向类型推导?","type":"blog","url":"/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/","wordcount":2248},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 8 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@shuangchengsun #266\n 我想知道对于 SOFARegistry 这样的系统是如何定义 SLA 的，以及有没有一个参考值。\n A：一般 SLA 的定义和系统的关键指标相关，类似 Registry 的核心就是 Pub Sub 模型，Pub 列表变化后及时推送给 Sub；那么 SLA 的定义就可以从类似 Pub 变更后在多长的周期内能推送给所有的 Sub，这个成功率应该高于多少。参考值这个看系统维护者对这个系统的要求吧，这个没什么标准值。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/\n2.@郑长青 #2197\n 我在宿主应用使用 Ark Biz，采用 Maven 依赖方式静态合并部署，但是通过 biz-a 查看，没有启动业务应用，这个问题遇到过吗？\n A：是打包业务 Biz 的 declared-libraries 赋值问题，所以动态部署和静态部署使用 2.1.0 版本的 sofa-ark-maven-plugin 插件无法正常运行。Bug 修复的 PR 已经合并，预计周五（2 月 10 日）发布新 2.1.1 版本。\n「SOFAArk」：https://github.com/sofastack/sofa-ark/\n本周推荐阅读 Special Weekly | 瑞兔送福，Live Long and Prosper\nSOFARegistry | 大规模集群优化实践\nNydus 加速镜像一致性校验增强\n一个 go-sql-driver 的离奇 bug\n欢迎扫码关注：\n","date":1676012400,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230210/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4c87dfeed2681923e2afaa93b04009bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230210/","publishdate":"2023-02-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230210/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230210/","wordcount":728},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.@wwg2017 #5222\n 如果二阶段提交 ：1.服务端没有接收到 TM 请求 report ；2. 服务端请求没有下发下来客户端没有接收到；3.客户端接收到了执行失败了。请问上面三种情况的话，对数据订单影响是什么？\n A：第一种情况会等到超时时间，默认是 60 秒后进行回滚。在 AT 模式下，订单数据由于是一个一阶段提交会有短暂的读未提交问题，这个需要按 @globallock 注解 +select for update 达到分布式下读已提交，但是会被阻塞到事务回滚后才可读到（默认 60s）。后面两种情况都会进行无限间隔 1s 的重试直至成功回滚/提交。\n「Seata」：https://github.com/seata/seata\n2.@antjack #2197\n Allow Setting Cluster Idle Timeout to Zero to Indicate Never Timeout.This issue requests the ability to set an idle_timeout = 0, to indicate the indefinite idle timeout for upstream connection timeout.\n 「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 Special Weekly | 瑞兔送福，Live Long and Prosper\nSOFARegistry | 大规模集群优化实践\nNydus 加速镜像一致性校验增强\n一个 go-sql-driver 的离奇 bug\n欢迎扫码关注：\n","date":1675407600,"description":"SOFA Weekly | 本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230203/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"17cef13c896ee0712ff7fad78ebafe52","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230203/","publishdate":"2023-02-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230203/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230203/","wordcount":656},{"author":null,"categories":"SOFAStack","content":" 导言：\n GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。这是去年（2022）的夏令营活动中，王瑞同学参加 Nydus 开源项目的总结，主要介绍了为 Nydus 支持镜像与文件系统一致性校验所做的相关工作。\n Nydus 简介 Nydus 是 CNCF 孵化项目 Dragonfly 的子项目，它提供了容器镜像，代码包，数据分析按需加载的能力，无需等待整个数据下载完成便可开始服务。\nNydus 在生产环境已经支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，网络带宽效率，端到端数据一致性等方面相比 OCIv1 格式有着巨大优势，并可扩展至例如 NPM 包懒加载等数据分发场景。\n目前 Nydus 由蚂蚁集团，阿里云，字节跳动联合开发，Containerd，Podman 社区接受了 Nydus 运行时作为其社区子项目，也是 KataContainers 以及 Linux v5.19 内核态原生支持的镜像加速方案。\nNydus 架构及原理 OCI 容器镜像是当前容器镜像的实现标准。它采用了分层的设计，每个镜像可包含多个镜像层。新层包含的是在旧层的基础上，新增加或者修改的文件或者被删除的文件。这种设计方式比较简单，不过也有着一定的缺陷。如需要镜像层全部堆叠后才能看到整个文件系统的视图，但不是所有数据都会被读取;同时可能已经删除或者被修改旧层中的文件，但是仍需要完整地下载和解压旧层;文件元数据修改导致整个镜像层被重新存储等。 Nydus 兼容目前的 OCI 生态，旨在通过细粒度的数据分割、去重和按需加载机制加速容器 的启动和分发，同时降低资源的消耗。\nNydus 的整体架构如下图所示。它可以通过 FUSE 给 runc 容器提供运行时的按需加载能力，也可以通过 virtiofs 承载 FUSE 协议，给 Kata Containers 等基于 VM 的容器运行时提供按需加载的能力。它可以从容器 Registry，OSS，NAS，Dragonfly supernode 等多个镜像源拉取镜像，同时内部会有本地的缓存加速容器的创建。\n在用户空间文件系统，Nydus 采用了数据和元数据分离的设计思想，元数据的修改不会导致整个镜像层的更新。原先的镜像层只存储文件的数据部分，同时数据被分块存储。拉取镜像是不需要拉取整层，只需要拉取所需文件对应的数据块即可。这也使得层与层之间，镜像与镜像之间共享数据块更加容易。上图展示了 Nydus 数据和元数据的存储格式。其中元数据以 merkle tree 的形式存储在 bootstrap 中，包含了容器启动所需要的信息。数据以 1MB 分块存储，不同镜像可以共享同一数据块。\nNydus 镜像校验意义及流程 Nydus 镜像在构建完成后，由于网络、磁盘等故障或者镜像被恶意修改，无法保证容器启动前镜像是合法的，所以需要对镜像的格式进行校验。当前的校验使用 nydusify 工具。主要分为三个部分:\n 对 Nydus 镜像的 bootstrap 进行校验，会通过 BootstrapRule 调用 nydus-image 二进制文件。nydus-image 首先检查 bootstrap 的 SuperBlock 格式是否正确，然后会从根结点开始按照文件系统层级结构检查文件或者目录的 inode 是否合法或被修改。\n 对镜像的 manifest 进行校验，会通过 ManifestRule 检验 Nydus 的 manifest 是否合法，ImageConfig 是否与原始 OCI 镜像一致等。\n 对镜像进行文件系统校验，会通过 FilesystemRule 分别挂载原始 OCI 镜像和 Nydus 镜像，然后进行校验。对于原始镜像，会使用 docker pull 拉取镜像，然后指定 lowerdir 和 upperdir，通过 OverlayFS 挂载 Rootfs；对于 Nydus 镜像，会使用 Nydusd 挂载。挂载完成后，会分别遍历两个目录，比较元数据和数据是否一致。\n 目前 Nydus 的校验方式仍有一定的限制，如元数据检查不完全，需要 docker 拉取镜像等。该项目旨在增强 nydusify 和 nydus-image 的校验功能，使校验更加易用和全面。\n文件系统校验方案 该项目当前分为以下三部分:\n 当前 nydusify check 在应用 FilesystemRule 进行校验时，对于文件元数据只检查文件路径、大小、模式和权限位以及 xattrs 是否和原始镜像一致，同时对文件数据用 blake3 计算得到哈希值并进行比较。但是由于校验内容不完整，可能会出现元数据不一致校验通过的情况。故对该结构体添加 dev、rdev、symlink、project id、uid、gid、nlink、ctime 等字段，实现对文件元数据更全面的检查。 当前 nydusify check 在应用 FilesystemRule 进行校验时，需要手动指定 source 和 Backend Type, Backend Config 才能成功应用 Nydusd 挂载并进行文件系统校验，在校验数据时，也会再次检查 Backend Type 是否指定。在大多数情况下，Backend Type 为 Registry，Backend Config 可以通过查看 Registry 的 config 文件获取相关信息，如 http.addr 字段获取地址，auth 字段获取认证信息等获取。因而用户在很多情况下并不需要手动输入上述参数。该任务旨在简化该命令，实现 Backend Type，Backend Config 的自动推断，使得用户更方便地进行校验。 (3) 当前 nydusify check 在应用 FilesystemRule 进行校验时，需要用户安装 docker，因为要使用 docker pull 命令拉取镜像。在没有 docker 的环境下，无法完成校验。可以修改该部分代码，手动下载、解压镜像，并使用 OverlayFS 挂载，从而去除对 docker 的依赖。\n文件系统校验实现细节 增加校验字段 该部分的实现较为简单。首先在原 Node 结构体增加 rdev, symlink, uid, gid, mtime 等字段。\n然后在遍历文件系统时，使用 Readlink 获取文件的软链接，通过 Lstat 系统调用获取 文件更详细的元数据信息（rdev, uid, gid, mtime 等），从而在进行比较时增加对上述字段的校验。值得注意的是 dev 不同是正常的，nlink 由于 OverlayFS 的问题无法进行校验。此外，还需要修改异常错误信息，从而遇到不一致时能够打印完整的文件元数据信息。\n简化校验参数 该部分需要实现 Backend Type 和 Backend Config 的自动推断，即如果镜像存储在 registry 中，用户无需指定上述两个参数即可完成校验。\n首先，我们需要添加上述结构体，即镜像源为 Registry 时的 Backend Config。对 …","date":1675148400,"description":"Nydus 加速镜像一致性校验增强","dir":"blog/nudus-20230131/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"483248448e3baf3c9667fae7d625f0e5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nudus-20230131/","publishdate":"2023-01-31T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/nudus-20230131/","summary":"导言： GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。这是去年（2022）的","tags":["SOFAStack"],"title":"Nydus 加速镜像一致性校验增强","type":"blog","url":"/sofastack.tech/blog/nudus-20230131/","wordcount":3175},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack GitHub issue 精选 本周各项目回复 issue 共计 5 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @fengjiachun #951\n 怎么通过GitHub Action 自动发布新版本 jar 到 maven 库？\n A：把 autoReleaseAfterClose 设置为 true，可以非常方便。\n「SOFAJraft」：https://github.com/sofastack/sofa-jraft/\n2. @canaan-wang #859\n Layotto 为什么要开发 SDK ？SDK 中的功能代码为什么不可以迁移到 Server 端？\n A：对于一些熟悉 gRPC 的用户来说，Client 端直接裸用 gRPC 都可以，但这种方式对于应用开发者是有理解成本的，所以 Layotto 的 SDK 提供的更多的是接口定义，让用户编程的时候不需要直接面向裸漏的 gRPC。举个简单的例子：假设用户可以往 gRPC 的 header 里面塞一个字段 “rpc-remote-address” 该字段用来指定 RPC 访问的远端目标地址，那么如果没 SDK，用户就得知道两件事：字段名和如何塞字段到 gRPC 的 header。但如果有 SDK，你可以提供一个函数 SetRpcTargetAddress（Address String）来直接给用户使用。\n「Layotto」：https://github.com/mosn/layotto/\n本周推荐阅读 WASM 将引领下一代计算范式[译]\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1674802800,"description":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20230127/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7f4e9f1a38f28d522bf4684610397dfa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230127/","publishdate":"2023-01-27T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20230127/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20230127/","wordcount":762},{"author":null,"categories":"SOFA Weekly","content":"送虎迎兔\n各位 SOFAStack 社区的朋友好：\n我是 SOFAStack 社区的负责人鲁直，度过了令人难忘的虎年，我们即将迈入充满希望的兔年，在这里给大家拜个早年，祝大家兔年吉祥。\n虎年虽然有诸多的不便与艰难，但是好在开源本就是倡导异步沟通、在线协作；无论你在世界的哪个角落，只要连上互联网，都可以参与到开源社区中来。在过去的一年中，SOFAStack 社区新增了 100 多位的 Committer；他们有来自腾讯、Shoppee、MiHoYo、华信永道、同程旅行等公司的员工；也有来自高校的学生，这些 Committer 和我们已有的 Committer 一起发布了大量的新 Feature，也修复了很多深藏的 Bug。\n不过，通过线上的协作虽然能够正常进行开源项目的开发，但是联络感情最好的方式一定还是线下的 Meetup。\n在虎年出行各种不便的情况下，我们和各个社区联合，在杭州、成都、广州、合肥和上海举行了 Meetup，不过遗憾的是 SOFAStack 社区开源四周年的活动没有能够在线下举办。\n伴随着兔年的即将到来，SOFAStack 社区的开源也即将迈入第五年，没有了出行的各种限制，SOFAStack 社区的五周年活动也将在线下和大家相见。\n兔年展望\n回望 SOFAStack 社区将近五年的开源时间，一开始我们只是按照自己的粗浅理解来做开源，把代码放到 GitHub 上面去，举办一些 Meetup。\n随着和开源社区朋友们的深入沟通，我们对于开源的理解、对于社区的理解也一步步深入和加强，意识到想要让 SOFAStack 社区长期发展，除了项目本身的优秀想法之外，更需要一个开放的、活跃的社区，只有两者结合一起才能够长久地经营下去。基于此我们设计了完善的社区晋升机制，也和项目的上下游保持良好的沟通和合作关系，融入到更大的开源大家庭中。\n今年我们也会在继续在开放和有趣方面做进一步的深入，包括会把部分的项目推进到基金会孵化，使它们能够更加健康地长期发展，也会把更多有趣的活动带给大家。\n兔年准备做的几件事\nSOFABoot 4.0\nSOFABoot 将会发布 4.0 版本，适配最新发布的 Spring Boot 3.0。回想 2019 年，我们在配套设施并不完善的情况下，尝试了使用 GraalVM 做 SOFABoot 的静态化，初步感受到了 Native 能够带来的启动速度的提升。随着 Spring Boot 3.0 的发布与 Spring 对于 GraalVM 支持的完善，我们终于有机会能够把 SOFABoot 的静态化做地更加完善。\nMOSN 2.0\nMOSN 将会发布 2.0 的版本，MoE 架构将会正式和大家见面。随着我们和 Envoy 社区的重要的合作点Envoy\u0026amp;rsquo;s L7 Go extension API，我们 MOSN 2.0 的开发和测试工作也已经接近尾声，新的架构将会给 MOSN 带来更多的可能性。\nLayotto 1.0\nLayotto 将会发布 1.0 的版本，提供更多的组件支持，并且进一步完善多云与多语言的支持。\nSeata\nSeata 将会继续丰富多语言的支持，也会走向更加开放的社区。\n除了上面的项目之外，SOFAStack 社区其他的一些项目在年后也会陆陆续续公布 RoadMap，期待大家一起加入进来玩。\nLive Long and Prosper\n星际迷航里面的瓦肯人在举瓦肯手礼的时候会说著名的瓦肯祝词：“Live Long and Prosper”，这句话也非常符合 SOFAStack 开源社区的愿景，我们希望无论是 SOFAStack 的项目还是 SOFAStack 的社区，都能够“Live Long and Prosper”。\n期待与大家在兔年线下相见，Let\u0026amp;rsquo;s build the community together! Live long and prosper!\n","date":1674284400,"description":"Special Weekly | 瑞兔送福，Live Long and Prosper","dir":"blog/sofa-special-weekly/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9bce67dda0b127c88ba3f0413516f2f7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-special-weekly/","publishdate":"2023-01-21T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-special-weekly/","summary":"送虎迎兔 各位 SOFAStack 社区的朋友好： 我是 SOFAStack 社区的负责人鲁直，度过了令人难忘的虎年，我们即将迈入充满希望的兔年，在这里给大家拜个早年，祝大家兔年吉祥。","tags":["SOFA Weekly"],"title":"Special Weekly | 瑞兔送福，Live Long and Prosper","type":"blog","url":"/sofastack.tech/blog/sofa-special-weekly/","wordcount":1241},{"author":null,"categories":"SOFAStack","content":" 文｜郝洪范\n京东技术专家\nSeata-go 项目共同发起人\n微服务底层技术的探索与研究。\n本文 3482 字 阅读 7 分钟\n 对于 Go CURD Boy 来说，相信 github.com/go-sql-driver/mysql 这个库都不会陌生。基本上 Go 的 CURD 都离不开这个特别重要的库。我们在开发 Seata-go 时也使用了这个库。不过最近在使用 go-sql-driver/mysql 查询 MySQL 的时候，就出现一个很有意思的 bug, 觉得有必要分享出来，以防止后来者再次踩坑。\n PART. 1 问题详述 为了说明问题，这里不详述 Seata-go 的相关代码，用一个单独的 demo 把问题详细描述清楚。\n1.1 环境准备 在一个 MySQL 实例上准备如下环境：\nCREATE TABLE `Test1` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `create_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, -PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=101 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; 从这个 SQL 语句中可以看出来， create_time 是 timestamp 类型，这里要特别留意 timestamp 这个类型。\n现在插入一条数据，然后查看刚插入的数据的值。\ninsert into Test1 values (1, \u0026#39;2022-01-01 00:00:00\u0026#39;) 查看下 MySQL 当前的时区。请记好相关值，草蛇灰线，伏笔于此。\nshow VARIABLES like \u0026#39;%time_zone%\u0026#39;; 查询结果：\n接下来使用 MySQL unix_timestamp 查看 create_time 的时间戳：\nSELECT unix_timestamp(create_time) from Test1 where id = 1; 查询结果：\n1.2 测试程序 有如下 demo 程序，示例使用 go-sql-driver 读取 create_time 的值：\npackage main import ( \u0026amp;quot;database/sql\u0026amp;quot; \u0026amp;quot;fmt\u0026amp;quot; \u0026amp;quot;time\u0026amp;quot; _ \u0026amp;quot;github.com/go-sql-driver/mysql\u0026amp;quot; ) func main() { var user = \u0026amp;quot;user\u0026amp;quot; var pwd = \u0026amp;quot;password\u0026amp;quot; var dbName = \u0026amp;quot;dbname\u0026amp;quot; dsn := fmt.Sprintf(\u0026amp;quot;%s:%s@tcp(localhost:3306)/%stimeout=100s\u0026amp;amp;parseTime=true\u0026amp;amp;interpolateParams=true\u0026amp;quot;, user, pwd, dbName) db, err := sql.Open(\u0026amp;quot;mysql\u0026amp;quot;, dsn) if err != nil { panic(err) } defer db.Close() rows, err := db.Query(\u0026amp;quot;select create_time from Test1 limit 1\u0026amp;quot;) if err != nil { panic(err) } for rows.Next() { t := time.Time{} rows.Scan(\u0026amp;amp;t) fmt.Println(t) fmt.Println(t.Unix()) }} 我们运行个程序会输出下面的结果:\n2022-01-01 00:00:00 +0000 UTC1640995200 1.3 问题详述 发现问题所在了吗？有图如下，把结果放在一块，可以详细说明问题。\n图中红色箭头指向的两个结果，用 go-sql-driver 读取的结果和在 MySQL 中用 unix_timestamp 获取的结果明显是不一样的。\nPART. 2 问题探案 1.3 小节中最后示图可以看出，数据库中 create_time 的值 2022-01-01 00:00:00 是东八区的时间，也就是北京时间，这个时间对应的时间戳就是 1640966400 。但是 go-sql-driver 示例程序读出来的却是 1640995200 ， 这是什么值？这是 0 时区的 2022-01-01 00:00:00。\n对问题的直白描述就是：MySQL 的 create_time 是 2022-01-01 00:00:00 +008 ，而读取到的是 2022-01-01 00:00:00 +000 ，他俩压根就不是一个值。\n基本能看出来 bug 是如何发生的了。那就需要剖析下 go-sql-driver 源码，追查问题的根源。\n2.1 go-sq-driver 源码分析 这里就不粘贴 \u0026amp;quot;github.com/go-sql-driver/mysql\u0026amp;quot; 的详细源码了，只贴关键的路径。\nDebug 的时候详细关注调用路径中红色的两个方块的内存中的值。\n// https://github.com/go-sql-driver/mysql/blob/master/packets.go#L788- L798 func (rows *textRows) readRow(dest []driver.Value) error { // ... // Parse time field switch rows.rs.columns[i].fieldType { case fieldTypeTimestamp, fieldTypeDateTime, fieldTypeDate, fieldTypeNewDate: if dest[i], err = parseDateTime(dest[i].([]byte), mc.cfg.Loc); err != nil { return err } }} func parseDateTime(b []byte, loc *time.Location) (time.Time, error) { const base = \u0026amp;quot;0000-00-00 00:00:00.000000\u0026amp;quot; switch len(b) { case 10, 19, 21, 22, 23, 24, 25, 26: // up to \u0026amp;quot;YYYY-MM-DD HH:MM:SS.MMMMMM\u0026amp;quot; year, err := parseByteYear(b) month := time.Month(m) day, err := parseByte2Digits(b[8], b[9]) hour, err …","date":1673938800,"description":"一个 go-sql-driver 的离奇 bug","dir":"blog/go-sql-driver-amazing-bug/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d7361909c70b2dd88fad050699609660","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-sql-driver-amazing-bug/","publishdate":"2023-01-17T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/go-sql-driver-amazing-bug/","summary":"文｜郝洪范 京东技术专家 Seata-go 项目共同发起人 微服务底层技术的探索与研究。 本文 3482 字 阅读 7 分钟 对于 Go CURD Boy 来说，相信 github.com/go-sql-driver/mysql 这个库都不会陌生。基本上 Go 的 CURD 都离","tags":["SOFAStack"],"title":"一个 go-sql-driver 的离奇 bug","type":"blog","url":"/sofastack.tech/blog/go-sql-driver-amazing-bug/","wordcount":1881},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 6 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @dengqian #2203\n 是否支持应用级服务发现，若支持能够给提供者和消费者的代号示例吗？\n A：SOFARegistry 本身是比较存粹的服务发布和订阅功能，应用级和接口级的区别在于 Client 发送给 Registry 的是应用级的 Publisher 还是接口级的 Publisher。所以相关的应用级 Publisher 聚合以及应用级 Subscriber 订阅的逻辑主要是在 Mesh 端，而这部分 Mesh 代码暂时还没开源。稍后我们会整理完整的应用级服务上线的过程以及设计方案，发布到社区文档中。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry/\n2. @yemoli #1290\n 请问 MOSN 支持增加订阅 xDS 吗？gRPC DeltaAggregatedResources。\n A：xDS 这个块还不支持，不过底层的资源是支持增加更新的，感兴趣的话语，欢迎共建~\n「MOSN」：https://github.com//mosn/mosn/\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1673593200,"description":"SOFA Weekly | 铜锁探「密」、本周贡献 \u0026 issue 精选","dir":"blog/sofa-weekly-20220113/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5558f66f4c819ff525bcb4708fab5700","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220113/","publishdate":"2023-01-13T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220113/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 铜锁探「密」、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220113/","wordcount":715},{"author":null,"categories":"SOFAStack","content":" 文｜李楠（GitHub ID : @loheagn）\n北京航空航天大学 21 级研究生\n云原生底层系统的开发和探索工作。\n本文 6369 字 阅读 16 分钟\nOSPP 开源之夏是由中科院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动。旨在鼓励在校学生积极参与开源软件的开发维护、促进优秀开源软件社区的蓬勃发展、培养和发掘更多优秀的开发者。\n这是去年（2022）的开源活动中，李楠同学参加 Nydus 容器开源生态集成课题的相关工作。\n| 作者有话说 |\n 大家好！我是来自北京航空航天大学的 2021 级研究生李楠，对云原生技术很感兴趣，GitHub ID 是 @loheagn。在今年上半年，我参加了 Linux 基金会的春季实习，完成了 CNCF - Kubevela: Management of Terraform state 项目的工作，并因此培养了对开源工作的兴趣。在开源之夏 2022 开放题目后，我了解到了 Nydus 项目，感觉这是一个很酷的项目，由于我之前对容器和镜像的底层技术并不是很熟悉，觉得这是个很不错的学习机会。于是便尝试投递了简历申请，最终很幸运地通过了筛选，并在严松老师的帮助下顺利完成了题目。\n PART. 1 项目背景 Nerdctl Nerdctl 是一个对标 Docker CLI 和 Docker Compose 的、用于与 Containerd （当下最流行的容器运行时，Docker 的后端也是调用的 Containerd，通常作为守护进程出现） 交互的命令行工具。\n用户可以像使用 Docker CLI 一样使用 Nerdctl 与 Containerd 进行交互，比如使用 nerdctl pull \u0026amp;lt;image_name\u0026amp;gt; 来拉取镜像、使用 nerdctl run \u0026amp;lt;image_name\u0026amp;gt; 来运行容器等等。\n相比于 Containerd 本身提供的 CTR 工具，Nerdctl 默认提供了更友好的用户体验，并尽量保持其使用方式与 Docker 一致。对于从 Docker 迁移到 Containerd 的用户，往往只需要 alias docker=nerdctl 就可以与之前获得一致的使用体验。\nOCI 镜像格式 OCI 镜像格式是 OCI （Open Container Initiative，开放容器计划） 的重要组成部分。它给出了一个厂商无关的镜像格式规范，即一个镜像应该包含哪些部分、每个部分的数据结构是如何的、这些各个部分应该以怎样的方式进行组织等等。\nOCI 镜像格式脱胎于 Docker 镜像格式，它与 Docker 镜像格式有着非常类似的结构；但它比 Docker 镜像格式有更好的兼容性，并得到了各个厂商的普遍认同。\n因此，在这里主要介绍一下 OCI 镜像格式的主要内容。\n通常所说的镜像文件其实指的是一个包含了多个文件的“包”，“包”中的这些文件提供了启动一个容器所需要的所有需要信息，其中包括但不限于，容器所使用的文件系统等数据文件，镜像所适用的平台、数据完整性校验信息等配置文件。当我们使用 docker pull 或 nerdctl pull 从镜像中心拉取镜像时，其实就是在依次拉取该镜像所包含的这些文件。\n例如，当我们使用 nerdctl pull 拉取一个 OCI 镜像时：\n从 Log 中可以清晰地看到，Nerdctl 依次拉取了一个 index 文件、一个 manifest 文件、一个 config 文件和若干个 layer 数据文件。实际上，一个标准的 OCI 镜像通常就是由这几部分构成的。\n其中，layer 文件一般是 tar 包或者压缩后的 tar 包，其包含着镜像具体的数据文件。这些 layer 文件会共同组成一个完整的文件系统（也就是从该镜像启动容器后，进入容器中看到的文件系统） 。\nconfig 文件是一个 JSON 文件。其中包含镜像的一些配置信息，比如镜像时间、修改记录、环境变量、镜像的启动命令等等。\nmanifest 文件也是一个 JSON 文件。它可以看作是镜像文件的清单，即说明了该镜像包含了哪些 layer 文件和哪个 config 文件。\n下面是一个 manifest 文件的典型例子：\n{ \u0026amp;quot;schemaVersion\u0026amp;quot;: 2, \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.manifest.v1+json\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.config.v1+json\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:0584b370e957bf9d09e10f424859a02ab0fda255103f75b3f8c7d410a4e96ed5\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 7636 }, \u0026amp;quot;layers\u0026amp;quot;: [ { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:214ca5fb90323fe769c63a12af092f2572bf1c6b300263e09883909fc865d260\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 31379476 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:50836501937ff210a4ee8eedcb17b49b3b7627c5b7104397b2a6198c569d9231\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 25338790 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:d838e0361e8efc1fb3ec2b7aed16ba935ee9b62b6631c304256b0326c048a330\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: 600 }, { \u0026amp;quot;mediaType\u0026amp;quot;: \u0026amp;quot;application/vnd.oci.image.layer.v1.tar+gzip\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;: \u0026amp;quot;sha256:fcc7a415e354b2e1a2fcf80005278d0439a2f87556e683bb98891414339f9bee\u0026amp;quot;, \u0026amp;quot;size\u0026amp;quot;: …","date":1673334000,"description":"Nerdctl 原生支持 Nydus 加速镜像","dir":"blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ef25c9d4c042e6feeca78cb7919f6fa5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","publishdate":"2023-01-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","summary":"文｜李楠（GitHub ID : @loheagn） 北京航空航天大学 21 级研究生 云原生底层系统的开发和探索工作。 本文 6369 字 阅读 16 分钟 OSPP 开源之夏是由中科院","tags":["SOFAStack"],"title":"Nerdctl 原生支持 Nydus 加速镜像","type":"blog","url":"/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/","wordcount":5660},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 SOFAStack GitHub issue 精选 本周各项目回复 issue 共计 3 条\n欢迎大家在 GitHub 提交 issue 与我们互动\n我们会筛选 issue 通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. @dengqian #2203\n Why pprof debug server do not support hot upgrade?\n A：Debug server init here：\nfunc DefaultInitStage(c *v2.MOSNConfig) { InitDefaultPath(c) InitDebugServe(c) InitializePidFile(c) InitializeTracing(c) InitializePlugin(c) InitializeWasm(c) InitializeThirdPartCodec(c) } And started here:\nfunc (m *Mosn) inheritConfig(c *v2.MOSNConfig) (err error) { m.Config = c server.EnableInheritOldMosnconfig(c.InheritOldMosnconfig) // default is graceful mode, turn graceful off by set it to false if !c.DisableUpgrade \u0026amp;amp;\u0026amp;amp; server.IsReconfigure() { m.isFromUpgrade = true if err = m.inheritHandler(); err != nil { return } } log.StartLogger.Infof(\u0026amp;quot;[mosn] [NewMosn] new mosn created\u0026amp;quot;) // start init services if err = store.StartService(nil); err != nil { log.StartLogger.Errorf(\u0026amp;quot;[mosn] [NewMosn] start service failed: %v, exit\u0026amp;quot;, err) } return } 「MOSN」：https://github.com//mosn/mosn/\n2. @yemoli #1290\n SOFARPC 发现了安全漏洞在哪提交呢？\n A：可以邮件给：khotyn.huangt@antgroup.com。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc/\n本周推荐阅读 SOFARegistry | 聊一聊服务发现的数据一致性\nSOFARegistry | 大规模集群优化实践\nMOSN 反向通道详解\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1672988400,"description":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","dir":"blog/sofaweekly-20230106/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f7cd3e95e772fe4b498452c1594986a2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaweekly-20230106/","publishdate":"2023-01-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofaweekly-20230106/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFANews、本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofaweekly-20230106/","wordcount":596},{"author":null,"categories":"SOFAStack","content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。\n本文 9492字 阅读 24 分钟\nPART. 1 前言 1.1 什么是服务发现 在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信。这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群；具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n1.2 服务发现的考量 设计和考量一个服务发现系统，可以从下面这些指标展开：\n各个指标之间并不是相互独立的。例如对于数据一致性方案的选型也会影响到数据分区、数据复制、集群容灾、多集群同步等方案的决策，也在很大程度上决定这个服务发现系统的整体架构。\n这篇文章重点分析了各个服务发现系统的数据一致性方案，以及基于这个方案延伸出来的特性，帮助大家初步了解服务发现系统。\nPART. 2 开源产品分析 2.1 为什么需要数据一致性 根据上述描述，数据一致性在服务发现系统中如此重要，甚至会影响到整个服务发现系统的各方面架构考量，那我们到底为什么需要数据一致性呢？\n要回答这个问题，让我们从单点故障说起：早期我们使用的服务，以及服务数据存储，它们往往是部署在单节点上的。但是单节点存在单点故障，一旦单节点宕机就整个服务不可用，对业务影响非常大。随后，为了解决单点问题，软件系统引入了数据复制技术，实现多副本。\n通过数据复制方案，一方面我们可以提高服务可用性，避免单点故障；另一方面，多副本可以提升读吞吐量、甚至就近部署在业务所在的地理位置，降低访问延迟。\n随着多副本的引入，就会涉及到多个副本之间的数据怎样保持一致的问题，于是数据一致性随之而来。\n2.2 开源产品分析\n对于多个副本之间进行数据同步，一致性关系从强到弱依次是：\n 线性一致性 （Linearizability consistency）\n 顺序一致性 （Sequential consistency）\n 因果一致性 （Causal consistency）\n 最终一致性 （Eventual consistency）\n 我们对比一下目前开源的比较典型的服务发现产品，在数据一致性上的方案实现：\nPART. 3 Etcd 数据一致性 3.1 Etcd 读数据流程 1. Client：Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： Client 发送 RPC 请求到了 Server 后，KV Server 基于拦截器记录所有请求的执行耗时及错误码、来源 IP 等，也可控制请求是否允许通过；\n3. Raft： Etcd 收到读请求后，向 Etcd Raft 模块发起 Read Index 读数据请求，返回最新的 ReadState 结构体数据；\n4. MVCC：KV Server 获取到 Read State 数据后，从 MVCC 模块的 Tree Index 读取基于 Key-Version 的唯一标识 Revision；再以 Revision 作为 Key 从 Boltdb 中读取数据。\n3.2 Etcd 写数据流程 1. Client： Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： 通过一系列检查之后，然后向 Raft 模块发起 （Propose） 一个提案 （Proposal） ，提案内容为存储的 value；\n3. Raft：\na.向 Raft 模块发起提案后，KV Server 模块会等待此 put 请求；如果一个请求超时未返回结果，会出现的 EtcdServer：request timed out 错误。\nb.Raft 模块收到提案后，如果当前节点是 Follower，它会转发给 Leader，只有 Leader 才能处理写请求。Leader 收到提案后，通过 Raft 模块将 put 提案消息广播给集群各个节点，同时需要把集群 Leader 任期号、投票信息、已提交索引、提案内容持久化到一个 WAL （Write Ahead Log） 日志文件中，用于保证集群的一致性、可恢复性。\n4. Raft 模块提交 Proposal 完成后，向 MVCC 模块提交写数据。\n3.3 Raft 功能分解 共识算法的祖师爷是 Paxos， 但是由于它过于复杂、难于理解，工程实践上也较难落地，导致在工程界落地较慢。\nStandford 大学的 Diego 提出的 Raft 算法正是为了可理解性、易实现而诞生的，它通过问题分解，将复杂的共识问题拆分成三个子问题，分别是：\n Leader 选举： Leader 故障后集群能快速选出新 Leader；\n 日志复制：集群只有 Leader 能写入日志， Leader 负责复制日志到 Follower 节点，并强制 Follower 节点与自己保持相同；\n 安全性： 一个任期内集群只能产生一个 Leader、已提交的日志条目在发生 Leader 选举时，一定会存在更高任期的新 Leader 日志中、各个节点的状态机应用的任意位置的日志条目内容应一样等。\n 下面以实际场景为案例，分别深入讨论这三个子问题，看看 Raft 是如何解决这三个问题，以及在 Etcd 中的应用实现。\n关于 Raft 的 Leader 选举与日志复制，可以从 *http://www.kailing.pub/raft/index.html* 动画中进一步了解。\n3.4 Etcd 读写一致性 3.4.1 线性一致性写 所有的 Read/Write 都会来到 Leader，Write 会有 Oplog Leader 被序列化，依次顺序往后 commit，并 Apply 然后在返回，那么一旦一个 Write 被 committed，那么其前面的 Write 的 Oplog 一定就被 committed 了。所有的 Write 都是有严格的顺序的，一旦被 committed 就可见了，所以 Raft 是线性一致性写。\n3.4.2 线性一致性读 Etcd 默认的读数据流程是 Linearizability Read，那么怎么样才能读取到 Leader 已经完成提交的数据呢？\n读请求走一遍 Raft 协议\n每个 Read 都生成一个对应的 Oplog，和 Write 一样，都会走一遍一致性协议的流程，会在此 Read Oplog 被 Apply 的时候读，那么这个 Read Oplog 之前的 Write Oplog 肯定也被 Applied 了，那么一定能够被读取到，读到的也一定是最新的。\n 有什么问题?\n 不仅有日志写盘开销，还有日志复制的 RPC 开销，在读比重较大的系统中是无法接受的；\n 还多了一堆的 Raft \u0026amp;lsquo;读日志\u0026amp;rsquo;。 …","date":1672729200,"description":"SOFARegistry | 聊一聊服务发现的数据一致性","dir":"blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","fuzzywordcount":7400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"87d55af6b45db61d5fb44c2096813f0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","publishdate":"2023-01-03T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。 本文 9492字 阅读 24 分钟 PART. 1 前言 1.1 什么是","tags":["SOFAStack"],"title":"SOFARegistry | 聊一聊服务发现的数据一致性","type":"blog","url":"/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","wordcount":7378},{"author":"肖健","categories":["SOFAStack"],"content":" 文｜肖健（花名：昱恒）\n蚂蚁集团技术专家\n专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。\n本文 9492字 阅读 24 分钟\nPART. 1 前言 1.1 什么是服务发现 在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信。这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。\nSOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群；具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n1.2 服务发现的考量 设计和考量一个服务发现系统，可以从下面这些指标展开：\n各个指标之间并不是相互独立的。例如对于数据一致性方案的选型也会影响到数据分区、数据复制、集群容灾、多集群同步等方案的决策，也在很大程度上决定这个服务发现系统的整体架构。\n这篇文章重点分析了各个服务发现系统的数据一致性方案，以及基于这个方案延伸出来的特性，帮助大家初步了解服务发现系统。\nPART. 2 开源产品分析 2.1 为什么需要数据一致性 根据上述描述，数据一致性在服务发现系统中如此重要，甚至会影响到整个服务发现系统的各方面架构考量，那我们到底为什么需要数据一致性呢？\n要回答这个问题，让我们从单点故障说起：早期我们使用的服务，以及服务数据存储，它们往往是部署在单节点上的。但是单节点存在单点故障，一旦单节点宕机就整个服务不可用，对业务影响非常大。随后，为了解决单点问题，软件系统引入了数据复制技术，实现多副本。\n通过数据复制方案，一方面我们可以提高服务可用性，避免单点故障；另一方面，多副本可以提升读吞吐量、甚至就近部署在业务所在的地理位置，降低访问延迟。\n随着多副本的引入，就会涉及到多个副本之间的数据怎样保持一致的问题，于是数据一致性随之而来。\n2.2 开源产品分析\n对于多个副本之间进行数据同步，一致性关系从强到弱依次是：\n 线性一致性 （Linearizability consistency）\n 顺序一致性 （Sequential consistency）\n 因果一致性 （Causal consistency）\n 最终一致性 （Eventual consistency）\n 我们对比一下目前开源的比较典型的服务发现产品，在数据一致性上的方案实现：\nPART. 3 Etcd 数据一致性 3.1 Etcd 读数据流程 1. Client：Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： Client 发送 RPC 请求到了 Server 后，KV Server 基于拦截器记录所有请求的执行耗时及错误码、来源 IP 等，也可控制请求是否允许通过；\n3. Raft： Etcd 收到读请求后，向 Etcd Raft 模块发起 Read Index 读数据请求，返回最新的 ReadState 结构体数据；\n4. MVCC：KV Server 获取到 Read State 数据后，从 MVCC 模块的 Tree Index 读取基于 Key-Version 的唯一标识 Revision；再以 Revision 作为 Key 从 Boltdb 中读取数据。\n3.2 Etcd 写数据流程 1. Client： Etcdctl 封装了操作 Etcd、KV Server、Cluster、Auth、Lease、Watch 等模块的 API；\n2. KV Server： 通过一系列检查之后，然后向 Raft 模块发起 （Propose） 一个提案 （Proposal） ，提案内容为存储的 value；\n3. Raft：\na.向 Raft 模块发起提案后，KV Server 模块会等待此 put 请求；如果一个请求超时未返回结果，会出现的 EtcdServer：request timed out 错误。\nb.Raft 模块收到提案后，如果当前节点是 Follower，它会转发给 Leader，只有 Leader 才能处理写请求。Leader 收到提案后，通过 Raft 模块将 put 提案消息广播给集群各个节点，同时需要把集群 Leader 任期号、投票信息、已提交索引、提案内容持久化到一个 WAL （Write Ahead Log） 日志文件中，用于保证集群的一致性、可恢复性。\n4. Raft 模块提交 Proposal 完成后，向 MVCC 模块提交写数据。\n3.3 Raft 功能分解 共识算法的祖师爷是 Paxos， 但是由于它过于复杂、难于理解，工程实践上也较难落地，导致在工程界落地较慢。\nStandford 大学的 Diego 提出的 Raft 算法正是为了可理解性、易实现而诞生的，它通过问题分解，将复杂的共识问题拆分成三个子问题，分别是：\n Leader 选举： Leader 故障后集群能快速选出新 Leader；\n 日志复制：集群只有 Leader 能写入日志， Leader 负责复制日志到 Follower 节点，并强制 Follower 节点与自己保持相同；\n 安全性： 一个任期内集群只能产生一个 Leader、已提交的日志条目在发生 Leader 选举时，一定会存在更高任期的新 Leader 日志中、各个节点的状态机应用的任意位置的日志条目内容应一样等。\n 下面以实际场景为案例，分别深入讨论这三个子问题，看看 Raft 是如何解决这三个问题，以及在 Etcd 中的应用实现。\n关于 Raft 的 Leader 选举与日志复制，可以从 *http://www.kailing.pub/raft/index.html* 动画中进一步了解。\n3.4 Etcd 读写一致性 3.4.1 线性一致性写 所有的 Read/Write 都会来到 Leader，Write 会有 Oplog Leader 被序列化，依次顺序往后 commit，并 Apply 然后在返回，那么一旦一个 Write 被 committed，那么其前面的 Write 的 Oplog 一定就被 committed 了。所有的 Write 都是有严格的顺序的，一旦被 committed 就可见了，所以 Raft 是线性一致性写。\n3.4.2 线性一致性读 Etcd 默认的读数据流程是 Linearizability Read，那么怎么样才能读取到 Leader 已经完成提交的数据呢？\n读请求走一遍 Raft 协议\n每个 Read 都生成一个对应的 Oplog，和 Write 一样，都会走一遍一致性协议的流程，会在此 Read Oplog 被 Apply 的时候读，那么这个 Read Oplog 之前的 Write Oplog 肯定也被 Applied 了，那么一定能够被读取到，读到的也一定是最新的。\n 有什么问题?\n 不仅有日志写盘开销，还有日志复制的 RPC 开销，在读比重较大的系统中是无法接受的；\n 还多了一堆的 Raft \u0026amp;lsquo;读日志\u0026amp;rsquo;。 …","date":1672729200,"description":"SOFARegistry | 聊一聊服务发现的数据一致性","dir":"projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","fuzzywordcount":7400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"27d048a94346192098907dd51a25e4ba","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","publishdate":"2023-01-03T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","summary":"文｜肖健（花名：昱恒） 蚂蚁集团技术专家 专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 设计、研发工作。 本文 9492字 阅读 24 分钟 PART. 1 前言 1.1 什么是","tags":["SOFAStack","SOFARegistry"],"title":"SOFARegistry | 聊一聊服务发现的数据一致性","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/","wordcount":7378},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 小白\n 在蚂蚁内部目前中间件升级采用的是业务方修改 POM 依赖的方式吗？\n A：是以这个方式为主的\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2. 肖文璧 提问\n Unrecognized VM option \u0026amp;lsquo;CMSParallelRemarkEnabled\u0026amp;rsquo; Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.导致 Seata-Server 无法启动是怎么回事？\n A：A：这个是因为使用了高版本的 JDK 导致。高版本的 JDK 取消了 CMS 处理器，转而采用了 ZGC 代替它。 解决方案有两个，选其中之一便可：1、降级 JDK 版本；2、在 Seata 的启动脚本中删除 CMS 的 JDK 命令。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1672383600,"description":"SOFA Weekly | 2023 我们一起加油、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221230/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"75c5a4519ec5c68e190926415dd7e767","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221230/","publishdate":"2022-12-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221230/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 2023 我们一起加油、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221230/","wordcount":607},{"author":null,"categories":"SOFAStack","content":" 文｜余硕\n上海交通大学22届毕业生阿里云开发工程师\n从事云原生底层系统的开发和探索工作。\n本文 6369 字 阅读 16 分钟\n GitLink 编程夏令营是在 CCF 中国计算机学会指导下，由 CCF 开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。 这是今年的夏令营活动中，余硕同学参加 Nydus 开源项目的总结，主要介绍了 Nydus 为支持镜像扫描与修复所做的研究与相关工作。\n PART. 1 课题背景 Nydus 开源镜像加速框架 Nydus 是 CNCF 孵化项目 Dragonfly 的子项目，它提供了容器镜像，代码包按需加载的能力。Nydus 应用时无需等待全部数据下载完成便可开始服务。\nNydus 在生产环境中已经支撑了每日百万级别的加速镜像容器创建。它在容器启动性能、镜像空间占用、网络带宽效率、端到端数据一致性等方面相比 OCI v1 格式有着巨大优势，并可扩展至其它数据分发场景，比如 NPM 包懒加载等。\n目前 Nydus 由蚂蚁集团、阿里云、字节跳动联合开发。Containerd、Podman 社区已经接受了 Nydus 运行时作为其社区子项目，它也是 Kata Containers 以及 Linux v5.19 内核态原生支持的镜像加速方案。\n有关 Nydus 镜像加速开源项目的详细介绍，可以参考：Nydus——下一代容器镜像的探索实践。\n项目描述 为 Nydus 镜像增加一个扫描和修复的命令行工具，包含以下功能：\n 提供一个 Nydus 镜像 url 和需要替换的文件列表；\n 使用工具拉取镜像 Bootstrap；\n 找到镜像中对应的文件并替换；\n 打包成新的镜像并上传回 Registry。\n 概括来说，原有项目目标是为 Nydus 镜像实现一个扫描和修复的命令行工具，其中这些功能是这个工具或者工具组的实现流程。\n但此项目具有一定的实验性，其核心是为 Nydus 格式的镜像提供扫描和修复的功能或者指引。如果存在更好的方式，项目最终不一定要按照原有项目描述去实现。因此在接下来的课题完成过程中，我们首先对已有镜像扫描/修复的工具与服务进行了调研，来确定此课题方案的最终形态。\n镜像扫描工具及服务 扫描和修复 镜像扫描和修复可以被拆解为两个过程。扫描不更改原有的镜像内容，只需要寻找扫描目标是否存在某种缺陷；镜像修复则需要根据缺陷改动镜像，包括但不限于镜像内容，镜像层级组织等。我们调研发现，当前主流开源镜像扫描引擎包括云厂商镜像安全服务都只涉及镜像扫描的功能， 不会主动添加镜像修复的功能。\n我们分析主要的原因有：\n 直接进行镜像修复可能引入新的安全问题；\n 镜像扫描的内容存在不同种类，很可能需要为不同种类的镜像安全问题设计不同的修复方式；\n 镜像修复功能可以通过重新打包镜像替代。\n 所以，镜像安全服务暂时只是提供扫描结果的安全报告，具体的修复操作由用户自行决定。我们也准备沿用这样的思路：在本课题中，为镜像实现安全扫描的功能，并提供报告作为用户镜像修复的参考依据。\n 我们也探索讨论了镜像修复的支持，或者 Nydus 特性在镜像修复场景下的增强，比如镜像内包替换后的去重与重组等，或许这些可以是未来 Nydus 中增加的功能特性。\n 镜像扫描介绍 镜像扫描的原因与内容 容器镜像是当前容器/软件分发的基础，里面包含了容器隔离环境以及软件执行环境的相关内容。因此保障其安全性变得十分重要。镜像扫描即是要扫描镜像中的所有内容，及时发现可能包含的安全漏洞或者隐私泄露。\n综合来看，镜像扫描需要关注镜像的安全性与健壮性，扫描的内容主要分为三类：\n1. 安全漏洞。 包括系统软件包和应用软件库中可能存在的安全漏洞。可以通过比对镜像中这些库/软件包的来源、版本等与 CVE 数据库中报告的漏洞的包的来源、版本来定位可能存在的安全漏洞。\n2. 配置。 包括镜像运行的环境配置和镜像中相关内容组合可能带来的问题。帮助尽早定位配置错误以及配置错误可能带来的安全风险。\n3. 隐私。 需要扫描的是用户指定的一些隐私信息。比如用户不小心将密钥等信息存入镜像。如果在扫描配置中进行指定，扫描过程可能发现这些隐私信息，避免隐私泄露以及可能带来的安全问题。\n扫描引擎 常见的扫描引擎有 Trivy、Synk 等。Docker 官方使用的是 Synk，但它比较商业化；Trivy 是 CNCF 的项目，开放性较好。\n镜像扫描的使用方式 在我们的调研中，镜像扫描主要应用方式有三种：\n1. 基础使用。 镜像扫描的过程可以直接通过集成了镜像扫描引擎的容器运行时或者镜像扫描引擎命令行触发。比如运行 $ docker scan image-url ，可以扫描镜像，并输出相应的报告。\nsource：https://docs.docker.com/engine/scan/\n2. 流程集成。 镜像扫描的过程可以集成到镜像中心或者 CI/CD 流程中。比如将镜像扫描集成到数据中心，在每次镜像上传到数据中心时触发镜像扫描，可以保证从数据中心下载的镜像总是经过安全扫描的；集成在 CI/CD 流程中，设置触发条件，可以保证镜像生成，镜像部署等过程所使用的镜像的安全性。\nsource: https://www.containiq.com/post/container-image-scanning\n3. 扫描服务。 云厂商提供了镜像安全的服务。它们背后可能是基于前两种使用方式实现，但是还可以有很多种功能的增强。用户想使用镜像扫描的功能也可以直接购买类似的安全服务，并进行灵活的配置。\nsource: https://cloud.google.com/container-analysis/docs/on-demand-scanning-howto\nPART. 2 课题解决思路 基本思路 课题首先要解决的基本思路是，如项目描述一般为 Nydus 实现一个专属的镜像扫描工具；还是复用已有的镜像扫描引擎，在 Nydus 侧实现对接支持，从而完成 Nydus 镜像扫描的功能实现。\n我们最终选择了结合已有镜像扫描引擎的实现思路。尽管为 Nydus 实现一个专属的镜像扫描工具可以更好的利用 Nydus 的特性，但是从镜像功能生态上考虑，这并不是一个很好的方式。复用或者集成到现有的镜像扫描工具，一方面可以直接使用已实现的镜像扫描引擎中全面的内容扫描能力；另一方面，与上层镜像安全服务的对接也不用再重写相关接口。这样也可以减少一些功能定制，减少用户使用的负担。因此此课题选择了后一种实现的基本思路。\n扫描思路：FileSystem vs Image Trivy 扫描功能实现的框架 1. 控制路径。\nTrivy 在镜像扫描上由以下路径控制，每触发一次命令，会由一个 Scanner 控制。其中关键的是 artifact 和 driver 。扫描引擎一般可以支持多种格式的扫描，比如 OCI v1 镜像或者镜像 Rootfs，同时一般也支持本地或者远端存储信息等。这些一般可由 ScannerConfig 配置或者自动解析。\natifact 存储着镜像 (包括文件系统) 元信息，如果已经扫描过其中的内容，还可以存储部分解析后的信息。另外，load …","date":1672124400,"description":"Nydus 镜像扫描加速","dir":"blog/nydus-mirror-scan-acceleration/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c1a6786f703b2475c84aad66b06e85b5","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-mirror-scan-acceleration/","publishdate":"2022-12-27T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/nydus-mirror-scan-acceleration/","summary":"文｜余硕 上海交通大学22届毕业生阿里云开发工程师 从事云原生底层系统的开发和探索工作。 本文 6369 字 阅读 16 分钟 GitLink 编程夏令营是在 CCF 中国计算机学会指导下","tags":["SOFAStack"],"title":"Nydus 镜像扫描加速","type":"blog","url":"/sofastack.tech/blog/nydus-mirror-scan-acceleration/","wordcount":5496},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 小白\n SOFAArk 可以把 2 个端口不一样的 Spring Boot 微服务合并到一起部署吗？比如一个是 8080 另一个端口是 8081，2 个服务都有各自的接口， 合并部署后还可以通过对应的端口来进行访问嘛？\n A：不使用 Web-Ark-Plugin 插件，每个模块会启动新的 Tomcat 实例，可以让服务用不同的 port。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2. 肖文璧 提问\n Seata 对 Java17 的版本有支持吗？\n A：A：需要 v1.6.0 版本。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Nerdctl 原生支持 Nydus 加速镜像\nSOFARegistry | 大规模集群优化实践\n降本增效: 蚂蚁在 Sidecarless 的探索和实践\n如何看待 Dapr、Layotto 这种多运行时架构？\n欢迎扫码关注：\n","date":1671778800,"description":"SOFA Weekly | 新年礼包已就位、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-202211223/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"af3eb0769d6765dd7994becf03bd4a1c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-202211223/","publishdate":"2022-12-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-202211223/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 新年礼包已就位、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-202211223/","wordcount":578},{"author":null,"categories":"SOFAStack","content":" 文｜戚文博 （花名：百蓦）\nDragonfly Maintainer蚂蚁集团软件工程师\n主要负责「基于 P2P 的文件以及镜像加速系统」。\n本文 2175 字 阅读 15 分钟\nPART. 1 背景 自 17 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 18 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会 （TOC） 投票决定接受 Dragonfly 作为孵化级别的托管项目。Dragonfly 多年生产实践经验打磨的下一代产品，它汲取了上一代 Dragonfly1.x[1] 的优点并针对已知问题做了大量的优化。\nNydus 作为 Dragonfly 的子项目优化了 OCIv1 镜像格式，并以此设计了一个用户态文件系统，使容器可以按需下载镜像，不再需要下载完整镜像即可启动容器。在最新版本中 Dragonfly 完成了和子项目 Nydus 的集成，让容器启动即可以按需下载镜像，减少下载量。也可以在传输过程中利用 Dragonfly P2P 的传输方式，降低回源流量并且提升下载速度。\nPART. 2 实践 注:如果没有可用的 Kubernetes 集群进行测试，推荐使用 Kind[2]。\n安装 Dragonfly\n基于 Kubernetes cluster 详细安装文档可以参考：\nhttps://d7y.io/docs/next/getting-started/quick-start/kubernetes/ 。\n使用 Kind 安装 Kubernetes 集群\n创建 Kind 多节点集群配置文件 kind-config.yaml ，配置如下:\nkind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker extraPortMappings: - containerPort: 30950 hostPort: 65001 - role: worker 使用配置文件创建 Kind 集群:\nkind create cluster --config kind-config.yaml 切换 Kubectl 的 context 到 Kind 集群:\nkubectl config use-context kind-kind Kind 加载 Dragonfly 镜像\n下载 Dragonfly latest 镜像:\ndocker pull dragonflyoss/scheduler:latest docker pull dragonflyoss/manager:latest docker pull dragonflyoss/dfdaemon:latest Kind 集群加载 Dragonfly latest 镜像:\nkind load docker-image dragonflyoss/scheduler:latest kind load docker-image dragonflyoss/manager:latest kind load docker-image dragonflyoss/dfdaemon:latest 基于 Helm Charts\n创建 Dragonfly P2P 集群\n创建 Helm Charts 配置文件 charts-config.yaml 并且开启 Peer 的预取功能, 配置如下:\nscheduler: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 seedPeer: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 download: prefetch: true dfdaemon: hostNetwork: true config: verbose: true pprofPort: 18066 metrics: :8000 download: prefetch: true proxy: defaultFilter: \u0026#39;Expires\u0026amp;amp;Signature\u0026amp;amp;ns\u0026#39; security: insecure: true tcpListen: listen: 0.0.0.0 port: 65001 registryMirror: dynamic: true url: https://index.docker.io proxies: - regx: blobs/sha256.* manager: replicas: 1 metrics: enable: true config: verbose: true pprofPort: 18066 使用配置文件部署 Dragonfly Helm Charts:\n$ helm repo add dragonfly https://dragonflyoss.github.io/helm-charts/$ helm install --wait --create-namespace --namespace dragonfly-system dragonfly dragonfly/dragonfly -f charts-config.yamlNAME: dragonflyLAST DEPLOYED: Wed Oct 19 04:23:22 2022NAMESPACE: dragonfly-system STATUS: deployedREVISION: 1TEST SUITE: None NOTES: 1. Get the scheduler address by running these commands: export SCHEDULER_POD_NAME=$(kubectl get pods --namespace dragonfly-system -l \u0026amp;quot;app=dragonfly,release=dragonfly,component=scheduler\u0026amp;quot; -o jsonpath={.items[0].metadata.name}) export SCHEDULER_CONTAINER_PORT=$(kubectl get pod --namespace dragonfly-system $SCHEDULER_POD_NAME -o jsonpath=\u0026amp;quot;{.spec.containers[0].ports[0].containerPort}\u0026amp;quot;) kubectl --namespace dragonfly-system port-forward $SCHEDULER_POD_NAME 8002:$SCHEDULER_CONTAINER_PORT echo \u0026amp;quot;Visit http://127.0.0.1:8002 to use your …","date":1671519600,"description":"Dragonfly 和 Nydus Mirror 模式集成实践","dir":"blog/dragonfly-and-nydus-mirror-mode-integration-practice/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"75467253523cbbd18d6aef01e3449eb4","permalink":"https://sofastack.github.io/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","publishdate":"2022-12-20T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","summary":"文｜戚文博 （花名：百蓦） Dragonfly Maintainer蚂蚁集团软件工程师 主要负责「基于 P2P 的文件以及镜像加速系统」。 本文 2175 字 阅读 15 分钟 PART. 1 背景 自 17 年开","tags":["SOFAStack"],"title":"Dragonfly 和 Nydus Mirror 模式集成实践","type":"blog","url":"/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/","wordcount":2729},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.小白 提问：\n 运行之后我发现和文档写的不一样 biz 和宿主的 Spring Boot 没有隔开，文档上写的是 2.6.6 和 2.5.0 但是实际启动都是 2.6.6，这是怎么回事？\n A：不建议用不同 Spring Boot，多 host 模式只要不使用 Web-Ark-Plugin 是可以的；我用 Sofa-Ark-Spring-Guides 试了一下，可以设置不同的 host。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.吴东梁 提问：\n 保存在内存里的事务信息多久会删除一次，来避免 OOM？\n A：结束就删。\n 那如果在事务结束之后只删内存的数据，不删除数据库里面数据会不会产生问题？\n A：没有内存和数据库共用的版本，不会的。\n「Seata」：https://github.com/seata/seata\nTongsuo 8.3.2 版本发布 主要变更如下：\n1.修复 C90 下的编译问题；\n2.修复 SSL_CTX_dup() 函数的 bug；\n3.修复 NTLS ServerKeyExchange 消息的 RSA 签名问题；\n4.修复 apps/x509 的 SM2 证书签名 bug；\n5.支持新特性 - 添加导出符号前缀。\n下载地址：\nhttps://github.com/Tongsuo-Project/Tongsuo/releases/tag/8.3.2\n本周推荐阅读 Tongsuo 支持半同态加密算法 Paillier\n金融级应用开发｜SOFABoot 框架剖析\nSeata AT 模式代码级详解\nSOFA 飞船 Layotto 星球登陆计划最新进展\n欢迎扫码关注：\n","date":1671174000,"description":"SOFA Weekly | Tongsuo 8.3.2 版本发布、C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221216/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a5844a518eb6396a88e6c0ad05c590bc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221216/","publishdate":"2022-12-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221216/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Tongsuo 8.3.2 版本发布、C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221216/","wordcount":728},{"author":null,"categories":"SOFAStack","content":" 文｜李大元 （花名：达远）\nKusion 项目负责人\n来自蚂蚁集团 PaaS 核心团队，PaaS IaC 基础平台负责人。\n本文 4331 字 阅读 11 分钟\nPART. 1 后云原生时代 距离 Kubernetes 第一个 commit 已经过去八年多了，以其为代表的云原生技术早已不再是什么新技术，而是现代化应用的“标配”。现代化应用依赖的基础服务远不止 Kubernetes 一种，稍微复杂点的应用往往会同时使用到 Kubernetes 生态云原生技术、IaaS 云服务、企业内部自建系统等各种异构基础设施，可能还会有多云、混合云的部署需求，我们已经进入到了 ”后云原生时代”，只针对 Kubernetes 的运维工具早已不能满足我们的诉求。\n更复杂的是，在企业内部，这些服务一般是由不同团队维护的，一次规模化运维需要多个团队的成员互相配合才能完成，但是 App Dev、Platform Dev、SRE 各个团队之间缺少高效的协作方式。技术自身的复杂性加上低效的团队协作，使得 “后云原生时代” 的规模化运维难度有了指数级的提高。\nPART. 2 规模化运维的问题一直都在 复杂异构基础设施的规模化运维，这并不是后云原生时代特有的问题，自分布式系统诞生以来，一直都是一个难题，只是在后云原生时代，这个问题变得更加困难。十多年前业界提出了 DevOps 理念，无数企业基于此理念构建了自己的 DevOps 平台，希望解决此问题，但在实际落地的过程中往往不尽人意，Dev 团队和 Ops 团队之间如何合作？职责如何划分？几十人的平台团队，如何支持几万工程师的运维诉求？底层基础设施复杂多样，能力日新月异，如何快速让一线 Dev 享受到技术红利？这些问题一直没有得到很好的解决，最近又有人提出了 DevOps 已死，Platform Engineering 才是未来的说法。抛开概念定义，无论是 DevOps 还是 Platform Engineering，本质上都是企业规模化运维这同一命题下的不同理念，我们更需要的是一个符合技术发展趋势，能解决当前问题的解决方案。\nPART. 3 传统架构不再适用 在传统的运维思路中，解决上述问题的方法一般是构建一个 PaaS 平台，例如我们早期的蚂蚁 PaaS 平台，他是一个 Web 控制台，有 UI 界面，用户（通常是 App Dev 或 SRE）通过 UI 交互可以完成诸如发布、重启、扩缩容等操作。在技术实现上大体可以分为三部分，一个前端系统，提供用户交互的能力，作为系统入口；中间是一个后端系统，对接各个基础设施；底层是各个基础设的 API。这种架构运行了近十年，一直运行的很好，既有用户友好的交互界面，又可以屏蔽基础设施复杂性，而且各个团队之间还职责分明，但是到了如今后云原生时代，这种架构不再适用，暴露出有两个致命缺点， “费人” 、 “费时” 。\n举一个常见的例子，网络团队为其负责的 Loadbalancer（负载均衡器）开发了一种新的负载算法，需要提供给用户使用。\n在上述架构下，整个工作流程是这个样子：\n1.网络团队开发好能力，提供出 API；\n2.PaaS 后端通过编码对接底层 API，进行互联互通，屏蔽复杂性，提供面向用户的更高级别 API；\n3.PaaS 前端根据新功能修改 UI，利用后端 API 把能力透出给最终用户。\n这里存在一个问题，即使一个再小的功能，也需要 PaaS 后端和前端修改代码，整个流程下来最快也要一周才能上线，而且涉及的基础设施团队越多，效率越低。这个问题在十年前并不算是一个问题，但是在今天就是一个很大的问题，一个后云原生时代的现代化应用，使用三个云原生技术（Kubernetes + Istio + Prometheus），两个云服务（Loadbalancer + Database），一个内部自建服务，已经是一个很常见的形态了，复杂应用只会依赖的更多。如果每个基础设施都由 PaaS 团队硬编码对接一遍，PaaS 团队的人再扩大十倍也不够用。\n“费人”讲完了，我们再看看“费时”的问题。上面例子里的一个小功能，需要进行两次跨团队的协作，一次基础设施和 PaaS 后端，另一次是 PaaS 后端与 PaaS 前端。团队协作是一个很难的问题，有时候比技术本身还要难。应用的架构已经很复杂了，如果要做一次规模化运维，一次运维 100 个应用，这要和多少个团队沟通协作？要花费多少时间？没有好的协作机制，这就变成了一个不可能完成的任务。\nPART. 4 探索与实践 我们在蚂蚁集团内部进行了近两年的探索，kustomize、helm、argoCD、Terraform 这些常见的工具我们都实践过，甚至还为一些工具自研了一些辅助系统，但结果并不尽人意。这些工具要么太局限于 Kubernetes 生态，运维不了其他类型的基础设施，要么就是支持了异构基础设施，但对于 Kubernetes 生态支持的不友好，无法发挥出云原生技术的优势，而且只是运维工具的升级对于团队协作效率几乎没有提升，我们需要一套更加体系化的方案。\n回到问题本身，针对“费人”、“费时”的问题，我们提出两个思路：\n1.能否不让 PaaS 做中转，而是由 App Dev 通过一种高效自助的方式，使用到互联互通的各种基础设施能力？\n2.能否构建一个中心化的协作平台，用技术的手段规范大家的行为，标准化的进行沟通？\n从技术的角度来看，PaaS 平台需要提供灵活的工具链和工作流，基础设施所有能力都通过模块化的方式暴露出来，App Dev 利用这些平台的基本能力，自己组合、编排来解决自己的问题，过程中不需要平台层的参与。并且整个过程中涉及的所有团队，都使用统一的语言和接口进行交流，全程无需人工参与。\nPART. 5 我们的实践 经过在蚂蚁内部 PaaS 平台近两年的探索与实践，沉淀出一套端到端的完整方案， 取名为 KusionStack，目前已经开源。试图从统一异构基础设施运维与团队协作两个角度解决传统 PaaS “费人”、“费时”的问题。\n整个体系主要分为三个部分：\n1.Konfig：Git 大库，是多团队协作的中心化平台，存放着各个团队的运维意图；\n2.KCL：蚂蚁自研的配置策略 DSL，所有团队间交流的工具；\n3.Kusion：KusionStack 引擎，负责所有的运维操作。\nPlatform Dev 通过 KCL 定义好基础能力模型，App Dev 通过 import、mixin 等语言特性在应用配置模型（AppConfig）里复用这些预定义好的能力，快速在 Konfig 里描述运维意图。AppConfig 是一个精心设计过的模型，只暴露 App Dev 需要关心的属性，屏蔽基础设施的复杂性。\n永远不要低估基础设施的专业性与复杂性，即使已经成为云原生技术标准的 Kubernetes，对普通用户来说依然有很高的门槛，一个 Deployment 就有几十个字段，再加上自定义的 labels、annotations 就更多了，普通用户根本无法全部理解。或者说普通 AppDev 不应该去了解 Kubernetes，他们需要的只是发布，甚至不需要关心底层是不是 Kubernetes。\nAppConfig 经过编译 …","date":1671174000,"description":"已来到 “后云原生时代” 的我们，如何规模化运维？","dir":"blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"79ce4a433a89df3cd7edcf19c450a1f0","permalink":"https://sofastack.github.io/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","publishdate":"2022-12-16T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","summary":"文｜李大元 （花名：达远） Kusion 项目负责人 来自蚂蚁集团 PaaS 核心团队，PaaS IaC 基础平台负责人。 本文 4331 字 阅读 11 分钟 PART. 1 后云原生时代 距离 Kubernetes 第一个 commit 已经过","tags":["SOFAStack"],"title":"已来到 “后云原生时代” 的我们，如何规模化运维？","type":"blog","url":"/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/","wordcount":3707},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#31:RPC 框架设计的考和量\n 活动时间：12 月 15 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#31 RPC 框架设计的考和量 本议题主要介绍 RPC 相关的概念和知识，和设计一个 RPC 框架需要关注的方面，以及从服务治理角度再谈 RPC 框架的设计，同时介绍 SOFARPC 在这些方面是如何实现的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 刘建军（花名：保义）\n SOFARPC Maintainer\n 蚂蚁集团基础组件研发，SOFARPC 开发者和维护者\n 议程 直播回放 https://www.bilibili.com/video/BV1pD4y187Gh/?spm_id_from=333.999.0.0\u0026amp;amp;vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1671087600,"description":"2022 年 12 月 15 日 19：00 - 20：00 ，线上直播第 31 期。","dir":"activities/sofachannel-31/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e59afb3aad30a8e2d7bc88251a256b03","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofachannel-31/","publishdate":"2022-12-15T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofachannel-31/","summary":"概要 活动主题：SOFAChannel#31:RPC 框架设计的考和量 活动时间：12 月 15 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播","tags":["SOFAChannel","SOFARPC","RPC 框架设计的考和量"],"title":"SOFAChannel#31 RPC 框架设计的考和量","type":"activities","url":"/sofastack.tech/activities/sofachannel-31/","wordcount":433},{"author":null,"categories":"SOFAStack","content":" 文｜王发康 （花名：毅松 ）\n蚂蚁集团技术专家、MOSN 项目核心开发者\n深耕于高性能网络服务器研发，目前专注于云原生 ServiceMesh、Nginx、MOSN、Envoy、Istio 等相关领域。\n本文 5574 字 阅读 14 分钟\n前言 从单体到分布式，解决了日益增长的业务在单体架构下的系统臃肿问题；从分布式到微服务，解决了服务化后的服务治理问题；从微服务到服务网格，解决了应用和基础设施耦合下的研发效能及稳定性问题。\n从微服务架构的演进历史来看，任何架构都不是一成不变，总是随着应用在不同阶段的痛点以及周边技术的发展而持续演进，而服务网格 （ServiceMesh） 概念从提出到生产落地至今已 6 年多了，那它的下一代架构应该是什么样？对此业界也有不同的声音 Service Mesh 的下一站是 Sidecarless 吗[1] ，本文主要介绍蚂蚁在这方面的探索和实践，最终如何帮业务降本增效，提升安全保障水位。\n一、 问题及挑战 谈起 ServiceMesh，大家的脑海中应该会呈现出下面这幅图，即 ServiceMesh 的 Sidecar 形态，它非常好的解决了应用和基础设施耦合下的系列问题，为业务的提效及稳定性等方面然禹功不可没。\n但是随着 ServiceMesh 的规模化增大，Sidecar 架构也随之暴露了一些劣势，譬如应用和 Sidecar 资源耦合导致相互抢占、生命周期绑定，导致应用扩缩容涉及额外 Sidecar 容器的创建及销毁开销、Sidecar 数量随着应用 Pod 数等比增加，导致其资源无法充分复用等。\n引用 redhat.com/architect/why-when-service-mesh\n1.1 资源耦合 Sidecar 形态虽然从代码维度是解耦了基础设施与应用的耦合，但是在资源方面目前仍然是和应用 Pod 绑定在一起，这就导致其资源管理成为一个难题。对此蚂蚁 ServiceMesh 在 Sidecar 资源管理[2] 进行改善，解决了初期的资源分配及管理。但随着业务的发展也暴露一些隐患，一方面 Sidecar 和应用相互抢占 CPU 可能导致引发时延毛刺问题，另一方面固定的 1\u0026amp;frasl;4 内存资源可能无法满足机房规模增大引发的网络连接数膨胀等系列问题。\n1.2 生命周期绑定 Sidecar 和应用属于同一个 Pod，而 K8s 是以 Pod 为最小单位进行管理的。这导致应用在扩缩容操作时会涉及额外 Sidecar 容器的创建及销毁开销，而 Sidecar 中的进程是基础设施软件本不应该随着应用的销毁而销毁。\n1.3 资源复用不充分 Sidecar 数量随着应用 Pod 数等比增加，而 Sidecar 上运行的都是基础设施通用能力，这将导致 Sidecar 中应用无关逻辑的 CPU 和内存等开销都在每个 Pod 中重复消耗。另外对于一些本能通过软件集中优化或硬件集中卸载的计数也无法充分施展。\n1.4 安全及业务侵入性 Sidecar 同应用同属一个 Pod，这无论对于 Sidecar 还是应用自身都是增大了安全攻击切面，另一方面 Sidecar 形态的服务治理也不算是完全业务无感的，至少要做一次 Sidecar 的注入，然后重启应用 Pod 才生效。\n二、思考及分析 对于上述 Sidecar 形态下的四个痛点：资源耦合、生命周期绑定、资源复用不充分、安全及业务侵入性，其实归根结底还是其架构导致。\n如果将 Sidecar 从应用 Pod 中剥离出来，对于资源耦合、生命周期绑定、安全侵入性问题都会迎刃而解，而资源复用粒度取决于剥离后部署的集中化程度。对于剥离后的集中化程度也并不是越集中越好，因为中心化后会增加交互时延以及能力的完整性缺失，所以在中心化和 Sidecar 化之间做一次折中，即通过 Node 化部署形态来解决，这样既可以做到同 Node 上的 Mesh 资源复用，又可以做到网络交互不跨 Node 的相关优化。\n虽然解决了 Sidecar 形态下的痛点，但是 Node 化后也引入了一些新的 “问题”。对于问题我们需要用辩证的眼光去看待，有时问题的背后可能是一个新机会。\n譬如 Sidecar 形态下的服务发现都是 Pod 级别，随着 Pod 规模的增大其服务条目成倍速增加，如果 Node 化后服务发现使用 Node IP 这样是不是可以成本的缩减服务条目，亦达到网络连接数的复用及收敛。\n- 隔离性、多租户： 多个应用共享 Mesh 后，涉及的一些应用维度的配置、内存、CPU 等资源如何相互隔离，另外对于 Sidecar 中各种基础设施组件如果自身来支持多租户，则改造成本是不可预估的。\n- 服务 pub/sub： 之前 Sidecar 形态下，Sidecar 和 APP 的 IP 是同一个 （Container 网络模式） ，Node 化后 IP 变成 Daemonset 容器的 IP，服务发现应如何管理？以及 Pod 和 Node 之间的流量如何管理。\n- 运维及安全合规\n a. Node 化后涉及到 Daemonset 自身以及应用维度的配置升级发布流程如何管控，同时出现故障时如何缩小爆炸半径；\n b. Node 化后涉及到的安全合规问题如何保证，如网络连通性如何隔离、身份等；\n c. Node 化后，Daemonset 所占用的机器成本如何规划 （超卖？独占？） 以及各个应用的资源消耗如何计算。\n三、方案介绍 将应用 Pod 中的 Sidecar 下沉到 Node，以 Daemonset 方式在每个 Node 部署。我们将该 Daemonset 命名为 NodeSentry，其定位是作为 Node 的网络基础设施，承载网络安全、流量治理、Mesh 下沉、连接收敛等 Node 相关网络治理平台。\n本文主要介绍 NodeSentry 承载 Mesh 下沉相关方案，Node 化后需要数据面 Proxy 能够高效、稳定的承载多个 Pod 的流量治理。这就要求数据面 Proxy 具备高处理性能及高研发效能，为此我们在 2021 年就其做了相关技术布局 MOSN2.0，详细介绍见 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态[3] 。\nMesh 下沉至 NodeSentry 其架构如上图所示，在新的架构下不仅能解决 Sidecar 形态的痛点，同时也具备了如下收益：\n- 资源解耦：解耦应用和基础设施的资源配额，多应用的 Mesh 资源池化、削峰填谷；\n- 资源复用：同 Node 同应用 Mesh 共享，ingress 方向连接收敛 、egress 方向连接共享、Node 级粒度 cache 命中率更高等；\n- Node 服务发现体系：解决注册中心等基础设施服务端压力以及调用端的内存消耗；\n- 提升启动速度：新架构下应用无需每次都启动 Mesh 的容器及镜像下载、SDK 初始化共享等额外操作；\n- 集中优化：云原生 L7 网络协议栈，软硬件结合性能优化，支持 IPV6，蚂蚁卡，RDMA or QUIC 等；\n- 解耦应用和网络： 同 Zero Trust Networking[4] 相关技术结合实现全局调度，有限互通等。 …","date":1670914800,"description":"降本增效：蚂蚁在Sidecarless 的探索和实践","dir":"blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7ece9ce602bb943fa14d61d09a0114a1","permalink":"https://sofastack.github.io/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","publishdate":"2022-12-13T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","summary":"文｜王发康 （花名：毅松 ） 蚂蚁集团技术专家、MOSN 项目核心开发者 深耕于高性能网络服务器研发，目前专注于云原生 ServiceMesh、Ngin","tags":["SOFAStack"],"title":"降本增效：蚂蚁在 Sidecarless 的探索和实践","type":"blog","url":"/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/","wordcount":4731},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.小白 提问：\n 这个配置是起到什么作用？true\n A：declaredMode 是指：如果 biz 和宿主 biz 依赖相同的包，biz 会使用宿主 biz 内的包。即：biz 该包设置成 provided 时，安装 biz 至宿主 biz 可以正常使用，从而减小了 biz 的体积。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.肖才稳 提问：\n Seata 的回滚模式，如果数据库被其他应用改了，是不是不能回滚了？Seata 必须保证数据库只有自己一个应用用了是吗？\n A：那你可以用 XA，AT 是要保证所有操作数据库的动作都在 Seata 事务的全局事务覆盖下。也就是说，如果你这个库的这个表被其他应用用了，让这个应用也集成 Seata 就行了。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 cgo 机制 - 从 c 调用 go\nGo 内存泄漏，pprof 够用了么?\nSeata AT 模式代码级详解\nSOFA 飞船 Layotto 星球登陆计划最新进展\n欢迎扫码关注：\n","date":1670569200,"description":"SOFA Weekly | MOSN v1.3.0 版本发布、公众号半自助投稿、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221209/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c276f5a6fa8b10d73ba44cb43b79ea22","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221209/","publishdate":"2022-12-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221209/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.3.0 版本发布、公众号半自助投稿、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221209/","wordcount":664},{"author":null,"categories":"SOFAStack","content":" 文｜田阳 （花名：烈元）\nMOSN Maintainer\n专注云原生等技术领域\n本文3042字 阅读 10 分钟\n1. 背景 Service Mesh 被越来越多的公司认可并实践，在实际落地过程中也遇到了形形色色的问题，同时架构也在持续演进去解决这些问题：有的从初始的 DaemonSet mode 转变为 Sidecar mode，如 Linkerd ；有的从做 CNI 延伸到 Service Mesh 场景， 结合 eBPF 使用 DaemonSet mode，如 Cilium ；如今 Istio 也新增了 Ambient Mesh ，支持 DaemonSet mode 作为其主推模式。\n不难看出一个演进趋势就是围绕着是否需要 Sidecar 而展开，那么 Service Mesh 的下一站将会是 Sidecarless 吗？本文将对目前的社区趋势做一个简要分析， 最后也将介绍蚂蚁在这方面的探索和实践。\n2. 社区趋势 2.1 Cilium Cilium[1] 是目前最火的云原生网络技术之一，基于革命性的内核技术 eBPF，提供、保护和观察容器工作负载之间的网络连接。\n在 6 月份，Cilium 发布了 1.12 版本，其中发布了 Service Mesh 能力、Sidecarless 架构，它提供了两种模式：\n通过图表我们可以发现：针对 L3/L4 的能力，Cilium 使用内核的 eBPF 直接支持；对于 L7 的部分能力，将使用 DaemonSet 部署的 Envoy 来支持。Cilium 认为大部分能力都不需要 L7 的参与，通过 eBPF 就能满足，所以 Cilium 也称自己为内核级服务网格。\n针对于此 Cilium 也有一个解释，结合应用程序 TCPD 最终被合入 linux kernel 发展为 iptables 为例，认为 Mesh 也应该作为基础能力下沉到 linux kernel 作为网络的基础组件，就类似于 TCP，作为 Linux 的一部分透明地提供的服务。\n在当需要 L7 代理能力的时候，会构建 DaemonSet Envoy 处理 L7 的能力。Envoy 也已经有了 Namespace 的初步概念，它们被称为监听器。监听器可以携带单独的配置并独立运行，从而可以支持多租户的配置隔离 (但目前还做不到资源和故障的隔离） 。\nCilium 认为 DaemonSet 相比 Sidecar 最明显的好处就是代理数大大减少，减少资源和管理成本。\n可以看出 Cilium Service Mesh 的发展历程是由下而上，从内核层慢慢向业务层扩展自己的服务边界，由 eBPF 来支持服务网络也是有一定的立场因素。但 eBPF 并不是银弹，DaemonSet mode 也是有一些其他的问题，收益和损失都是相对的。\n2.2 Linkerd 当然，Cilium 这个架构也不乏有挑战者，其中来头最大的就是 Linkerd[2] （Service Mesh 概念的提出者） 的创始人 William Morgan ，比较有意思的是 Linkerd 最开始的架构是 DaemonSet mode ，在后面的版本才换成 Sidecar mode ，对于此，作为逆行者的他应该最有发言权。\n在 William Morgan 的最新文章[3] 中也客观提出了 eBPF 的一些局限性，为了保证 eBPF 的安全执行而不影响 kernel ，需要通过验证器验证是否有不正确的行为，这就导致 eBPF 的编写存在一定的潜规则，比如不能有无界循环；不能超过预设的大小等，代码的复杂性也就受到了一定限制。所以较复杂的逻辑用 eBPF 来实现也是有较高的成本的。\n文章中也提到了 DaemonSet 的一些弊端：\n- 资源管理不可评估：这取决于 K8s 调度多少 Pod 到该 Node；\n- 隔离性：所有应用公用一个 Proxy ，相互影响稳定性；\n- 爆炸半径变大：影响整个 Node 的 Pod 实例；\n- 安全问题更复杂：比如 Proxy 保存有整个 Node 的秘钥。\n简而言之，Sidecar 模式继续贯彻了容器级别的隔离保护 —— 内核可以在容器级别执行所有安全保护和公平的多租户调度。容器的隔离仍然可以完美的运行，而 DaemonSet 模式却破坏了这一切，重新引入了争抢式的多租户隔离问题。\n当然他也认为 eBPF 可以更好的促进 Mesh 的发展，eBPF+Sidecar 的结合是 Mesh 的未来。\n 我们也比较认可他对于 eBPF 的看法， eBPF 就像是一把瑞士军刀，小巧精湛，作为胶水把各种网络数据面连接起来，提供基础网络能力，比如提供访问加速，透明劫持，网络可观察性等能力。但要开发复杂的业务能力，在实操之后，感觉还是有点力不从心。目前我们团队也正在使用 eBPF 开发 K8s Service 和透明拦截等基础网络能力。\n William Morgan 的说法看着也不无道理，我们先不急着站队，再来看看 Istio 是怎么做的，看是否会有新的想法~\n2.3 Istio 在 9 月份，Service Mesh 领域的当家花旦 Istio 毫无征兆的发布了 Ambient Mesh ，并作为自己后续的主推架构，简单来讲就是把数据面从 Sidecar 中剥离出来独立部署，Sidecarless 架构，以彻底解决 Mesh 基础设施和应用部署耦合的问题。\n 比较好奇 Istio 在没有经过社区讨论和落地案例的情况下，是怎样决策笃定这个新的架构方向的呢？\n Istio 认为 Sidecar mode 存在如下三个问题：\n- 侵入性\n必须通过修改应用程序的 Kubernetes pod spec 来将 Sidecar 代理 “注入” 到应用程序中，并且需要将 Pod 中应用的流量重定向到 Sidecar 。因此安装或升级 Sidecar 需要重新启动应用 Pod ，这对工作负载来说可能是破坏性的。\n- 资源利用不足\n由于每个 Sidecar 代理只用于其 Pod 中相关的工作负载，因此必须针对每个 Pod 可能的最坏情况保守地配置 Sidecar 的 CPU 和内存资源。这导致了大量的资源预留，可能导致整个集群的资源利用不足。\n- 流量中断\n流量捕获和 HTTP 处理 通常由 Sidecar 完成，这些操作的计算成本很高，并且可能会破坏一些实现和 HTTP 协议不完全兼容的应用程序。\nEnvoy 的创始人也来凑了个热闹，他对 Sidecar 架构也是颇有微词。\n我们在落地过程中也是遇到了类似的痛点，比如随着机房规模和应用规模的变大，应用的连接数继续膨胀导致 CPU 和 MEM 资源占用也在持续增加，但这一切都不是应用本身想去关心的。\n那么让我们来解开 Ambient Mesh 架构真面目，是怎样来解决 Sidecar mode 的问题， 架构主要提出了分层：\n从图中可以看出，跟 Cilium 有一些类似，这儿的两层数据面都是基于 Envoy 来构建的，Secure Overlay Layer 主要处理 L4 场景，DaemonSet 部署，L7 processing Layer 主要处理 L7 场景， …","date":1669705200,"description":"Service Mesh 的下一站是 Sidecarless 吗？","dir":"blog/is-sidecarless-the-next-stop-for-servicemesh/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"620c3d0c618cffbc58020852e1ed722d","permalink":"https://sofastack.github.io/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","publishdate":"2022-11-29T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","summary":"文｜田阳 （花名：烈元） MOSN Maintainer 专注云原生等技术领域 本文3042字 阅读 10 分钟 1. 背景 Service Mesh 被越来越多的公司认可并实践，在实际落地过程中也遇到了形形色色","tags":["SOFAStack"],"title":"Service Mesh 的下一站是 Sidecarless 吗？","type":"blog","url":"/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/","wordcount":3215},{"author":null,"categories":"SOFAStack","content":" 文｜王祖熙（花名：金九 )\n蚂蚁集团开发工程师\n负责国产化密码库 Tongsuo 的开发和维护\n专注于密码学、高性能网络、网络安全等领域\n本文 4316 字 阅读10 分钟\n1. 背景 在《Tongsuo 支持半同态加密算法 EC-ElGamal》中，已经阐述了同态和半同态加密算法的背景和原理，可以移步查阅。总之，同态算法在隐私计算领域有着重要的作用，目前应用比较广泛的是 Paillier 和 EC-ElGamal 半同态加密算法，它们接口类似且只支持加法同态。\n但是它们两者的性能和原理有很大的差异：\n原理方面，Paillier 是基于复合剩余类的困难性问题 （大数分解难题） 的公钥加密算法，有点类似 RSA；而 EC-ElGamal 是基于椭圆曲线数学理论的公钥加密算法，其安全性理论上要比 Paillier 要更好。\n性能方面，EC-ElGamal 的加密和密文加法性能要比 Paillier 好；而 Paillier 的解密和密文标量乘法性能要比起 EC-ElGamal 要更好更稳定 （EC-ElGamal 的解密性能与解密的数字大小有关系，数字越大可能需要解密的时间越长，这与 EC-ElGamal 解密用到的解密表有关系，而 Paillier 的解密就没有这个问题。） 。\n所以这两个产品各有优劣，大家可以根据自己的业务特点选择使用 Paillier 还是 EC-ElGamal。\n2. Paillier 原理 2.1 密钥生成 1.随机选择两个大素数 p、q，满足 ，且满足 p 和 q 的长度相等；\n2.计算以及 ，表示最小公倍数；\n3.随机选择整数，一般 g 的计算公式如下： a. 随机选择整数； b. 计算：，为了简化和提高性能，k 一般选 1，g=1+n；\n4.定义 L 函数：，计算：；\n5.公钥：(n, g)，私钥：(λ, μ)。\n2.2 加密 明文 m，满足 −n\u0026amp;lt;m\u0026amp;lt;n；\n 选择随机数 r，满足 0≤r\u0026amp;lt;n 且 ；\n 计算密文：。\n 2.3 解密\n 密文 c，满足；\n 计算明文：。\n 2.4 密文加法\n 密文：c1 和 c2，，c 就是密文加法的结果。 2.5 密文减法\n 密文：c1 和 c2，计算：，c 就是密文减法的结果。 2.6 密文标量乘法\n 密文：c1，明文标量：a，计算：，c 就是密文标量乘法的结果。 3. 正确性 3.1 加解密正确性 公式推导需要用到 Carmichael 函数和确定合数剩余的公式，下面简单说明一下：\n● Carmichael 函数\na. 设 n=pq，其中：p、q 为大素数；\nb. 欧拉函数：ϕ(n) ，Carmichael 函数：λ(n)；\nc. 当 和时，\n其中：。\n对于任意 ，有如下性质：。\n● 判定合数剩余\na. 判定合数剩余类问题是指 n=pq，其中：p、q 为大素数，任意给定，使得，则说 z 是模 的第 n 次剩余；\nb. 第 n 项剩余的集合是 的一个阶乘法子集；\nc. 每个第 n 项剩余 z 都正好拥有 n 个 n 阶的根，其中只有一个是严格小于 n 的 （即 ） ；d. 第n项剩余都可以写成 的形式。\n● 正确性验证\n解密：\n3.2 密文加法正确性 3.3 密文减法正确性 3.4 密文标量乘法正确性 4. 算法实现 4.1 接口定义 ●对象相关接口\n○公/私钥对象：PAILLIER_KEY ，该对象用来保存 Paillier 公钥和私钥的基本信息，比如 p、q、n、g、λ、μ 等信息，私钥保存所有字段，公钥只保存 n、g，其他字段为空或者 0。相关接口如下：\n// 创建 PAILLIER_KEY 对象 \\PAILLIER_KEY *PAILLIER_KEY_new(void); // 释放 PAILLIER_KEY 对象 void PAILLIER_KEY_free(PAILLIER_KEY *key); // 拷贝 PAILLIER_KEY 对象，将 src 拷贝到 dest 中 PAILLIER_KEY *PAILLIER_KEY_copy(PAILLIER_KEY *dest, PAILLIER_KEY *src); // 复制 PAILLIER_KEY 对象 PAILLIER_KEY *PAILLIER_KEY_dup(PAILLIER_KEY *key); // 将 PAILLIER_KEY 对象引用计数加1，释放 PAILLIER_KEY 对象时若引用计数不为0则不能释放其内存 intPAILLIER_KEY_up_ref(PAILLIER_KEY *key); // 生成 PAILLIER_KEY 对象中的参数，bits 为随机大素数 p、q 的二进制位长度 int PAILLIER_KEY_generate_key(PAILLIER_KEY *key, int bits); // 获取 key 的类型：公钥 or 私钥 // PAILLIER_KEY_TYPE_PUBLIC 为私钥，PAILLIER_KEY_TYPE_PRIVATE 为私钥 int PAILLIER_KEY_type(PAILLIER_KEY *key); ○上下文对象：PAILLIER_CTX，该对象用来保存公私钥对象以及一些其他内部用到的信息，是 Paillier 算法其他接口的第一个参数。相关接口如下：\n// 创建 PAILLIER_CTX 对象，key 为 paillier 公钥或者私钥，threshold 为支持最大的数字阈值，加密场景可设置为 0，解密场景可使用默认值： PAILLIER_MAX_THRESHOLDPAILLIER_CTX *PAILLIER_CTX_new(PAILLIER_KEY *key, int64_t threshold); // 释放 PAILLIER_CTX 对象 void PAILLIER_CTX_free(PAILLIER_CTX *ctx); // 拷贝 PAILLIER_CTX 对象，将 src 拷贝到 dest 中 PAILLIER_CTX *PAILLIER_CTX_copy(PAILLIER_CTX *dest, PAILLIER_CTX *src); // 复制 PAILLIER_CTX 对象 PAILLIER_CTX *PAILLIER_CTX_dup(PAILLIER_CTX *src); ○密文对象： PAILLIER_CIPHERTEXT ，该对象是用来保存 Paillier 加密后的结果信息，用到 PAILLIER_CIPHERTEXT 的地方，可调用如下接口：\n// 创建 PAILLIER_CIPHERTEXT 对象 PAILLIER_CIPHERTEXT *PAILLIER_CIPHERTEXT_new(PAILLIER_CTX *ctx); // 释放 PAILLIER_CIPHERTEXT 对象 void PAILLIER_CIPHERTEXT_free(PAILLIER_CIPHERTEXT *ciphertext); ●加密/解密接口\n// 加密，将明文 m 进行加密，结果保存到 PAILLIER_CIPHERTEXT 对象 …","date":1669100400,"description":"Tongsuo 支持半同态加密算法 Paillier","dir":"blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c3860b700dec4c686121bd9ef3565472","permalink":"https://sofastack.github.io/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","publishdate":"2022-11-22T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","summary":"文｜王祖熙（花名：金九 ) 蚂蚁集团开发工程师 负责国产化密码库 Tongsuo 的开发和维护 专注于密码学、高性能网络、网络安全等领域 本文 4316 字 阅读10 分钟 1. 背景 在","tags":["SOFAStack"],"title":"Tongsuo 支持半同态加密算法 Paillier","type":"blog","url":"/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/","wordcount":3758},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.卓俊良 提问：\n Q: 22. AT 模式和 Spring @Transactional 注解连用时需要注意什么 ？\n A：@Transactional 可与 DataSourceTransactionManager 和 JTATransactionManager 连用，分别表示本地事务和 XA 分布式事务，大家常用的是与本地事务结合。当与本地事务结合时， @Transactional 和 @GlobalTransaction 连用，@Transactional 只能位于标注在 @GlobalTransaction 的同一方法层次或者位于 @GlobalTransaction 标注方法的内层。这里分布式事务的概念要大于本地事务，若将 @Transactional 标注在外层会导致分布式事务空提交，当 @Transactional 对应的 connection 提交时会报全局事务正在提交或者全局事务的 xid 不存在。\n 如果要支持 istio1.14 是需要重新适配吗？还是说有其他简化的方式？\n A：是需要适配下的，主要看新增了多少改动。\n「Seata」：https://github.com/seata/seata\n2.快叫我去学习 提问：\n Q: 34.Seata 的 JDK 版本要求是什么？\n A：目前 Seata 支持的 JDK 版本为 JDK8、11。其余版本不确保 100% 兼容。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读 Dragonfly 中 P2P 传输协议优化\nNydus | 容器镜像基础\nSOFARegistry | 大规模集群优化实践\n开源项目文档社区化！Tongsuo/铜锁实践\n欢迎扫码关注：\n","date":1668754800,"description":"SOFA Weekly |开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221122/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a317262c02b5a9ed70ec67cae8b88892","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221122/","publishdate":"2022-11-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221122/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221122/","wordcount":726},{"author":null,"categories":"SOFAStack","content":" 文｜孙珩珂\n上海交通大学\n本文1987字 阅读 10 分钟\n01 优化背景 此前 Dragonfly 的 P2P 下载采用静态限流策略，相关配置项在 dfget.yaml 配置文件中：\n# 下载服务选项。 download: # 总下载限速。 totalRateLimit: 1024Mi # 单个任务下载限速。 perPeerRateLimit: 512Mi 其中 perPeerRateLimit 为单个任务设置流量上限， totalRateLimit 为单个节点的所有任务设置流量上限。\n静态限流策略的理想情况是： perPeerRateLimit 设置为20M ， totalRateLimit 设置为 100M ，且该节点目前运行了 5 个或更多的 P2P 下载任务，这种情况下可以确保所有任务总带宽不会超过 100M ，且带宽会被有效利用。\n这种限流策略的缺点是：若perPeerRateLimit 设置为 20M ， totalRateLimit 设置为 100M ，并且当前该节点只运行了一个下载任务，那么该任务的最大下载速度为 20M ，和最大带宽 100M 相比，浪费了 80% 的带宽。\n因此，为了最大限度地利用带宽，需要使用动态限流来确保任务数量少时能能充分利用总带宽，而任务数量多时也能公平分配带宽。最终，我们设计出一套根据上下文进行动态限流的算法，其中上下文指各任务在过去一秒内使用的带宽，此外，算法还考虑到了任务数量、任务剩余大小、任务保底带宽等因素，性能相比原来的静态限流算法有显著提升。\n02 相关代码分析 perPeerRateLimit 配置项最终赋值给 peerTaskConductor 的pt.limiter ，由 peerTaskConductor 的 DownloadPiece() 函数里进行限速，pt.waitLimit() 进行实际限流工作，底层调用 Go 自带的限流函数 WaitN() 。\nTotalRateLimit 配置项则在创建 Daemon 时被赋值给 pieceManager 的pm.limiter ，在 pieceManager 的 DownloadPiece() 和 processPieceFromSource() 函数中用到的 pm.limiter ，而这两个函数都会由 peerTaskConductor 调用，也就是说 P2P 下载会先进行总限速，之后再进行每个任务单独限速。\n根据以上分析，Dragonfly 进行任务限速的逻辑为，每个peer task（peerTaskConductor）会有单独的限速 perPeerRateLimit ，同时 pieceManager 会有 TotalRateLimit 的总限速，以此达到单任务单独限流，同时限制所有任务总带宽的效果。\n03 优化方案 为了解决此前静态限流算法总带宽利用率不佳的缺点，需要将其改进为动态限流算法，即总带宽限速仍恒定，但每个任务的单独带宽限速需要根据上下文适度、定期调整，已达到最大化利用总带宽、同时相对公平分配带宽的目的。\n在经过数个改版后，最终我们确定了根据上下文进行限流的 sampling traffic shaper 动态限流算法。具体方案为，每个任务的单任务限流交由 TrafficShaper 组建进行统一管理， TrafficShaper 维护当前正在运行的所有任务，并且定期（每秒）更新这些任务的带宽。\n具体来说，上下文指每个任务在上一秒使用的带宽、每个任务的剩余大小、任务数量、任务保底带宽（不能低于 pieceSize ）等因素， TrafficShaper 会根据这些上下文公平地、效率最大化地为每个任务分配其下一秒的带宽（具体分配方案详见下一小节），实现动态限流的效果。\n04 优化实现 定义 TrafficShaper 接口如下：\n// TrafficShaper allocates bandwidth for running tasks dynamically type TrafficShaper interface { // Start starts the TrafficShaper Start() // Stop stops the TrafficShaper Stop() // AddTask starts managing the new task AddTask(taskID string, ptc *peerTaskConductor) // RemoveTask removes completed task RemoveTask(taskID string) // Record records task\u0026#39;s used bandwidth Record(taskID string, n int) // GetBandwidth gets the total download bandwidth in the past second GetBandwidth() int64 } 该接口有两种实现，第一种是 samplingTrafficShaper 即基于上下文的 traffic shaper ，第二种是 plainTrafficShaper 只记录带宽使用情况，除此之外不做任何动态限流工作，用于和 samplingTrafficShaper 对比性能提升。\n同时，将相关配置项修改为如下内容：\n# 下载服务选项。 download: # 总下载限速。 totalRateLimit: 1024Mi # 单个任务下载限速。 perPeerRateLimit: 512Mi # traffic shaper类型，有sampling和plain两种可选 trafficShaperType: sampling Traffic shaper 的具体运行逻辑为，由peerTaskManager维护trafficShaper，在创建peerTaskManager时，根据配置初始化trafficShaper，并且调用Start()函数，启动trafficShaper，具体来说，新建time.NewTicker，跨度为 1 秒，也即每秒trafficShaper都会调用updateLimit()函数以动态更新所有任务的带宽限流。\nupdateLimit() 函数会遍历所有运行中的任务，得出每个任务上一秒消耗的带宽以及所有任务消耗的总带宽，随后根据任务上一秒使用的带宽、任务剩余大小等因素，按比例分配带宽，具体来说首先根据上一秒该任务使用带宽以及该任务剩余大小的最大值确定下一秒该任务带宽，接着所有任务带宽根据总带宽按比例缩放，得到下一秒的真实带宽；同时需要确保每个任务的带宽不低于该任务的 pieceSize ，以免出现持续饥饿状态。\n在 peerTaskManager 的 getOrCreatePeerTaskConductor() 函数中，若新建任务，需要带宽，那么调用 AddTask() 更新所有任务的带宽，即按照已有任务的平均任务分配带宽，然后再根据总带宽上限将所有任务的带宽等比例进行缩放；根据平均带宽分配新任务带宽的优势为，避免了已经有一个任务占满了所有带 …","date":1668495600,"description":"Dragonfly 中 P2P 传输协议优化","dir":"blog/p2p-transfer-protocol-optimization-in-dragonfly/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9af455951fd545b7e7fa74b3eca908ce","permalink":"https://sofastack.github.io/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","publishdate":"2022-11-15T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","summary":"文｜孙珩珂 上海交通大学 本文1987字 阅读 10 分钟 01 优化背景 此前 Dragonfly 的 P2P 下载采用静态限流策略，相关配置项在 dfget.yaml 配置文件中： # 下载服务选项。 download: # 总下载","tags":["SOFAStack"],"title":"Dragonfly 中 P2P 传输协议优化","type":"blog","url":"/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/","wordcount":2220},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周贡献 每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. 奇奇 提问：\n Seata 可以用于生产环境吗？\n A：0.4.2 版本之后就可以上生产环境。\n「Seata」：https://github.com/seata/seata\n2. 牛康龙 提问：\n 在使用时遇到了如下图这个问题，请问该如何解决啊？ A：换 Hikari Durid 的 bug 。\n「Seata」：https://github.com/seata/seata\n本周推荐阅读\ncgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\nGo 内存泄漏，pprof 够用了么？\nSeata AT 模式代码级详解\n欢迎扫码关注\n","date":1668150000,"description":"SOFA Weekly |本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221111/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a95c87454a97852938da43731c348498","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221111/","publishdate":"2022-11-11T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221111/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 本周贡献 \u0026 issue 精选","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221111/","wordcount":497},{"author":null,"categories":"SOFAStack","content":" 文｜唐斌\n字节跳动基础架构研发工程师\nNydus 与 Nydus snapshotter 社区贡献者，专注存储，云原生技术。\n本文 6964 字 阅读 15 分钟\n1 Nydus 1.1 存在的问题 对于容器镜像使用者\n问题一： 启动容器慢：容器启动慢的情况普遍发生在当用户启动一个很大的容器镜像时，由于在容器准备阶段需要三步（以 overlayfs 为例）：\n- 下载镜像；\n- 解压镜像；\n- 使用 overlayfs 将容器可写层和镜像中的只读层聚合起来提供容器运行环境。\n其中，下载镜像阶段需要下载整个镜像文件，不能实现文件数据按需加载。再加上下载镜像本身受限于网络带宽，当容器镜像达到 GB 级别时，下载时间会较长，破坏了容器原本优秀的用户体验。\n问题二： 较高的本地存储成本：不同镜像之间可以共享的最小单位是镜像中的层，缺点之一是重复数据的处理效率较低。\n原因如下：\n- 首先，层内部存在重复的数据；\n- 其次，层与层之间可能存在大量重复的数据，即使有微小的差别，也会被作为不同的层；\n- 再次，根据 OCI imagespec 对删除文件和 hardlink 的设计，镜像内部已经被上层删除的文件可能仍然存在于下层，并包含在镜像中。\n对于镜像提供者\n这里的提供者主要指容器服务的镜像中心。\n问题一： 巨大的存储资源浪费。\n- 存在大量相似镜像，造成这种情况有两个原因：\n 首先，上面提到的层的缺点，导致在容器镜像中心存在许多相似镜像；\n 其次，OCI image 使用了 tar+gzip 格式来表示镜像中的层，而 tar 格式并不区分 tar archive entries ordering，这带来一个问题，如果用户在不同机器上 build 同一个镜像，最终可能会因为使用了不同的文件系统而得到不同的镜像，用户上传之后，镜像中心中会存在若干不同镜像的实质内容是完全相同的情况。\n - 镜像去重效率低\n虽然镜像中心有垃圾回收机制来实现去重功能，但其仍然以层为单位，所以只能在有完全相同 hash value 的层之间去重。\n问题二： 云原生软件供应链带来的新需求。\n随着时间推移，和软件供应链一起发展的还有对软件供应链环节的多样性攻击手段。安全防护是软件供应链中非常重要的组成，不光体现在对软件本身的安全增强，也体现在对供应链的安全增强。因为应用运行环境被前置到了容器镜像中，所以对容器镜像的安全，包括对镜像的漏洞扫描和签名成为了容器服务提供者的必要能力。\nOCI 镜像规范的缺陷\n主要的缺陷有两点：\n- tar 格式标准\n tar 格式并不区分 tar archive entries ordering，这带来一个问题，即如果用户在不同机器上 ；build 同一个镜像，最终可能会因为使用了不同的文件系统而得到不同的镜像，比如在文件系统 A 上的 order 是 foo 在 bar 之前进入 tar ，在文件系统 B 上的 order 是 bar 在 foo 之前进入tar ，那么这两个镜像是不同的；\n 当 tar 被 gzip 压缩过之后不支持 seek ，导致运行之前必须先下载并解压 targz 的 image layers，而不能实现文件数据按需加载。\n - 以层为镜像的基本单位\n 内容冗余：不同层之间相同信息在传输和存储时都是冗余内容，在不读取内容的时候无法判断到这些冗余的存在；\n 无法并行：每一层是一个整体，对同一个层既无法并行传输，也不能并行提取；\n 无法进行小块数据的校验，只有完整的层下载完成之后，才能对整个层的数据做完整性校验；\n 其他一些问题：比如，跨层数据删除难以完美处理。\n 1.2 Nydus 基础 在容器的生产实践中，偏小的容器镜像能够很快部署启动。当应用的镜像达到 GB 级以上的时候，在节点上下载镜像通常会消耗大量的时间。Dragonfly 通过引入 P2P 网络有效地提升了容器镜像大规模分发的效率。然而，用户必须等待镜像数据完整下载到本地，然后才能创建自己的容器。\nNydus 是在最新的 OCI Image-Spec 基础之上设计的容器镜像加速服务，重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。Nydus 由阿里云和蚂蚁集团的工程师合作开发，并大规模部署在内部的 生产环境中。\nNydus 优化了现有的 OCI 镜像标准格式，并以此设计了一个用户态的文件系统。通过这些优化，Nydus 能够提供这些特性：\n 容器镜像按需下载，用户不再需要下载完整镜像就能启动容器\n 块级别的镜像数据去重，最大限度为用户节省存储资源\n 镜像只有最终可用的数据，不需要保存和下载过期数据\n 端到端的数据一致性校验，为用户提供更好的数据保护\n 兼容 OCI 分发标准和 artifacts 标准，开箱即可用\n 支持不同的镜像存储后端，镜像数据不只可以存放在镜像仓库，还可以放到 NAS 或者类似 S3 的对象存储上\n 与 Dragonfly 的良好集成 1.3 Nydus 架构 Nydus 的架构主要包含两部分内容：\n- 新的镜像格式（Rafs）\n- 负责解析容器镜像的 FUSE 用户态文件系统进程\nNydus 兼容多种文件系统，能够解析 FUSE 和 virtiofs 协议来支持传统的 runc 容器、 Kata容器。对于存储后端，支持使用容器仓库（ Registery ）、OSS 对象存储 、NAS、Dragonfly 的超级节点和 Peer 节点作为 Nydus 的镜像数据存储后端。此外，为了加速启动速度，Nydus 还可以配置一个本地缓存，避免每次启动容器时都从远端数据源拉取数据。\n1.4 Nydus 特性 容器启动速度变快\n用户部署了 Nydus 镜像服务后，由于使用了按需加载镜像数据的特性，容器的启动时间明显缩短。在官网的测试数据中，Nydus 能够把常见镜像的启动时间，从数分钟缩短到数秒钟。理论上来说，容器镜像越大，Nydus 体现出来的效果越明显。\n提供运行时数据一致校验\n在传统的镜像中，镜像数据会先被解压到本地文件系统，再由容器应用去访问使用。解压前，镜像数据是完整校验的。但是解压之后，镜像数据不再能够被校验。这带来的一个问题就是，如果解压后的镜像数据被无意或者恶意地修改， 用户是无法感知的。而 Nydus 镜像不会被解压到本地，同时可以对每一次数据访问进行校验，如果数据被篡改，则可以从远端数据源重新拉取。\n从图中可以看出，对容器镜像数据进行运行时一致性校验是通过对每个数据块计算 SHA 256 实现的，这得益于 Nydus 采用分块的方式管理镜像数据。如果在镜像文件非常大的时候，对整个镜像文件计算哈希值非常不现实。\n1.5 Nydus 镜像格式：RAFS RAFS 是对 EROFS 文件系统的增强，拓展在云原生场景下的能力，使其适应容器镜像存储场景。RAFS v6 是内核态的容器镜像格式，除了将镜像格式下沉到内核态，还在镜像格式上进行了一系列优化，例如块对齐、更加精简的元数据等。\nRAFS v6 镜像格式\n1.6 Nydus -snapshotter Nydus snapshotter 是 containerd 的一个外部插件， …","date":1667977200,"description":"Nydus | 容器镜像基础","dir":"blog/container-image-basics/","fuzzywordcount":6100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa785f9400252d3285438e7ad8a39218","permalink":"https://sofastack.github.io/sofastack.tech/blog/container-image-basics/","publishdate":"2022-11-09T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/container-image-basics/","summary":"文｜唐斌 字节跳动基础架构研发工程师 Nydus 与 Nydus snapshotter 社区贡献者，专注存储，云原生技术。 本文 6964 字 阅读 15 分钟 1 Nydus 1.1 存在的问题 对于容器镜像使用者 问题一： 启动","tags":["SOFAStack"],"title":"Nydus | 容器镜像基础","type":"blog","url":"/sofastack.tech/blog/container-image-basics/","wordcount":6057},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.康政恒 提问：\n MOSN 做链路追踪是否需要 APP 配合传递 traceID、spanID 这些吗? A：链路追踪都需要 APP 配合的，这是业务决定，跟是不是 MOSN 没关系。\n 「MOSN」：https://github.com/mosn/mosn/\n2.康政恒 提问：\n MOSN 是否和 APP 也保持长链接呀，这样可以知道 APP 的存活状态。 A：保持长链接。\n 「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 SOFARegistry | 大规模集群优化实践\ncgo 机制 - 从 c 调用 go\nSeata AT 模式代码级详解\nGo 内存泄漏，pprof 够用了么？\n欢迎扫码关注：\n","date":1667545200,"description":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20221104/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"32dcc5c5b6f04360aa073fe5820a4d12","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221104/","publishdate":"2022-11-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221104/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221104/","wordcount":519},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#30:Nydus 开源容器镜像加速服务的演进与未来\n 活动时间：11 月 03 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#30 Nydus 开源容器镜像加速服务的演进与未来 Nydus 在生产环境已经支撑了每日百万级别的加速镜像容器创建，在启动性能，镜像空间优化，网络带宽效率，端到端数据一致性等方面相比 OCIv1 格式有着巨大优势，并可扩展至例如 NPM 包懒加载等数据分发场景。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n嘉宾 严松（花名：井守）\n Nydus 镜像加速开源项目 Maintainer\n 负责蚂蚁集团基础设施研发，专注于云原生镜像与容器运行时生态。\n 议程 直播回放 https://b23.tv/Gnz9y6D\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1667458800,"description":"2022 年 11 月 03 日 19：00 - 20：00 ，线上直播第 30 期。","dir":"activities/sofa-channel-30/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"51b6ca632e0cf11ccff50820a472a320","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-30/","publishdate":"2022-11-03T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-30/","summary":"概要 活动主题：SOFAChannel#30:Nydus 开源容器镜像加速服务的演进与未来 活动时间：11 月 03 日，周四晚 19 点 活动形式：线上直播 资料","tags":["SOFAChannel","Nydus","开源容器镜像加速服务的演进与未来"],"title":"SOFAChannel#30 Nydus 开源容器镜像加速服务的演进与未来","type":"activities","url":"/sofastack.tech/activities/sofa-channel-30/","wordcount":485},{"author":null,"categories":"SOFARegistry","content":" 文｜李旭东\n专注于 SOFARegistry 及其周边基础设施的开发与优化\n本文 7016 字 阅读 15 分钟\n1 前言 SOFARegistry 在蚂蚁内部迭代升级过程中，每年大促都会引来一些新的挑战，通过不断的优化这些在大规模集群遇到的性能瓶颈，我们总结出一些优化方案，来解决大规模集群遇到的性能问题。\n通过阅读这篇文章，读者可以学习到一些 Java 和 Go 语言系统的优化技巧，在系统遇到瓶颈的时候，能够知道有哪些优化手段针对性的进行优化。\n2 大规模集群的挑战 随着业务的发展，业务的实例数在不断增长，注册中心所需要承载的数据量也在快速的增长 ，以其中 1 个集群为例，2019 年的数据为基准数据，在 2020 年 pub 接近千万级。下图是该集群历年双 11 时的数据对比。 相比 2019 年双 11，2021 年双 11 接口级的 pub 增长 200%，sub 增长 80%。实例数和数据量的增长带来推送量的二次方形式的增长，SOFARegistry 每一年大促都会经历新的挑战。\n比如，在某一年的新机房压测过程中，由于新机房规模特别大（普通机房的 4 倍），导致注册中心的推送压力变大了十倍多，出现了 ：\n- DataServer 的网络被打爆，导致大量数据变更没有及时通知到 Session ，推送延迟飙升；\n- 因为数据包过大， SessionServer 与客户端之间出现了大量的 channel overflow 推送失败，推送延迟飙升；\n- 由于实例数量过多，注册中心的推送包以及内部传输的数据包过大，很容易打满单机的网络处理上限，序列化数据也会占用大量的 CPU ；\n- 由于地址列表扩大了几倍，导致对应推送接收端 MOSN 也出现了问题，大量机器出现 OOM ， 出现大量 CPU 毛刺影响请求延迟；\n- 注册中心常见瞬间大量并发的请求，比如业务大规模重启，很容易导致瞬时注册中心自身处理能不足，如何进行限流，以及如何快速达到数据最终一致。\n3 优化方案 针对上述大规模集群遇到的挑战，我们做了以下的优化方案：\n3.1 横向扩展支撑大规模集群 在大规模集群场景下，单纯采用扩大机器规格的纵向扩展方式往往会遇到瓶颈，单机的配置是有上限的，超大的 heap gc 时也可能产生较高的暂停时间，而且恢复与备份会花费很长时间。\n3.1.1 双层数据架构进行数据分片 双层数据架构: Session (会话层：分散链接)、Data （数据层：分散数据）来实现横线扩展的能力，通过对链接和数据进行分片，SOFARegistry 可以通过横向扩容很容易的支撑更大的集群。单机采用小规格的机器，在容灾以及恢复方面也可以取得很好的效果。\nSOFARegistry 的架构可以参见： https://www.sofastack.tech/blog/explore-sofaregistry-1-infrastructure/\n3.2 应对瞬时大量请求 注册中心存在瞬时处理大量请求的场景，比如当在大量应用同时发生运维或者注册中心自身发生运维的时候，会有大量的注册请求发送到 Session 。\n同时有一些依赖注册中心的基础设施会通过变更发布数据到注册中心来通知到每一个订阅端。为了应对这种不可预见的瞬时大量请求变更，注册中心需要有一定的策略进行削峰。\n3.2.1 队列攒批处理 贴合蚂蚁的业务，为大规模集群而生，在大数据量，高并发写入下提供稳定的推送延迟，通过添加队列并进行攒批处理，提高吞吐量，对瞬间高并发请求进行削峰。\n举例：\n- Session 接收到大量 Publisher ，攒批发请求到 Data [1]\na.利用 BlockingQueue 存储需要发送 的请求，同时会配置最大容量防止 OOM\nb.独立的 Worker 线程从 BlockingQueue 中取出多个请求，创建多个 BlockingQueue 和 Worker 提高并发度\nc.按照分片规则进行分组，打包成一个请求发往不同的 DataServer\n- Session 接收到大量 Subscriber ，聚合去重后创建推送任务 *[2]*\na.Subscriber 存储到 Map的数据结构中，可以进行去重的避免短时间一个实例重复注册创建大量推送任务\nb.定时从 Map 中取出 Subscribers ，进行分组创建推送任务\nc.最大数据量是 Session 单机的所有 Subscriber ，容量可控\n- 用 Map 存储 DataServer 上发生变化数据的 DataInfoId ，聚合通知 Session 进行推送[3]\na.短时间 DataServer 的数据可能变化多次，比如大量 Publisher ，数据修复定时任务等等\nb.对这些数据变化记录 DataInfoId ， 短时间只会对 Session 通知一次变更创建推送任务\nc.最大数据量是 Data 单机全部的 DataInfoId\n- 用 Map 存储 PushTask 进行去重，避免数据连续变化触发大量推送任务[4]\na.添加了 Map size 的检查，过多的推送任务会直接丢弃，防止 OOM\nb.同样的推送任务高版本会替换掉低版本\n3.3 减少网络通讯开销 3.3.1 LocalCache Session 和 Data 之间会有大量的数据通讯，通过添加 LocalCache 可以在不增加代码架构复杂度的前提下大幅度提升系统的性能。\n对于注册中心，服务数据可以通过 dataInfoId + version 唯一标识。Session 在创建推送任务时会从 Data 拉取最新的服务数据，利用 Guava 的 LoadingCache ,大量推送任务被创建时，缓存的利用率会比较高，可以减少很多从 Data 拉取数据的开销。\n- Session 利用 LoadingCache 从 Data 拉取数据[5]\na.会传入创建推送任务时的版本（一般由 Data 的变更通知带过来）对比 Cache 内的数据是否足够新；\nb.如果不够新，清理缓存后利用 LoadingCache 从 Data 拉取一次数据；\nc. LoadingCache 会配置 maximumWeight 防止数据过多导致 OOM 。\n3.3.2 压缩推送 在集群规模比较大的时候，比如有一个应用发布了 100 个接口，每个接口的发布数据有 150B ，该应用有 8000 个实例，每个接口有 2w 订阅方。那么每次变更这个应用的机器造成的全量推送，每个推送包 1MB ， 累积需要发出 200w 个推送包，即使 Session 可以横向扩容到 100 台， Session 单机也需要在 7 秒内发出 20GB 的流量，严重阻塞 Session 的网络队列，也会很快打爆 netty buffer ，造成大量的推送失败，这么多推送包的序列化也会耗费 Session 大量的 CPU 。\n对于 Data ，如果 Session 的数量过多，每次变更需要给每台 Session 返回大量的大数据包，也会产生大量的出口流量，影响其他请求的成功率。\n由于每个实例发布的数据的相似度很高，几乎只有 IP 不一致，所以当采用压缩推送时压缩率会非常高，能压 …","date":1667458800,"description":"SOFARegistry | 大规模集群优化实践","dir":"blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"56b7649b36ba3889527d68dc2214c31d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","publishdate":"2022-11-03T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","summary":"文｜李旭东 专注于 SOFARegistry 及其周边基础设施的开发与优化 本文 7016 字 阅读 15 分钟 1 前言 SOFARegistry 在蚂蚁内部迭代升级过程中，每年大促都会引来一些新的挑战，通过不断的优","tags":["SOFARegistry"],"title":"SOFARegistry | 大规模集群优化实践","type":"blog","url":"/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/","wordcount":5846},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.康恒政 提问：\n MOSN 之间是维持长链接的吗，然后像 Spring Cloud、Dubbo、Bolt 协议的数据在这个长链接上面传递吗？\n A：支持的，MOSN 原生就支持 Dubbo，Bolt 协议。\n「MOSN」：https://github.com/mosn/mosn/\n2.康恒政 提问：\n 注册中心是不是可以支持其他种类的，比如 ZooKeeper、Eureka 什么的？\n A：可以的，可以自己扩展，默认支持了 ZK 。\n「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 cgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\n从规模化平台工程实践，我们学到了什么？\n直播预告丨SOFAChannel#30《Nydus 开源容器镜像加速服务的演进与未来》\n欢迎扫码关注：\n","date":1666940400,"description":"SOFA Weekly | MOSN v1.2.0 版本发布、开源人、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly/20221028/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8890ddd864d60166dc508e0ec80d9049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly/20221028/","publishdate":"2022-10-28T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly/20221028/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.2.0 版本发布、开源人、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly/20221028/","wordcount":605},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 4656 字 阅读 12 分钟\n一、前言 去年刚学 go 语言的时候，写了这篇 cgo 实现机制[1] ，介绍了 cgo 的基本情况。主要介绍的是 go=\u0026amp;gt;c 这个调用方式，属于比较浅的层次。随着了解的深入，发现 c=\u0026amp;gt;go 的复杂度又高了一级，所以有了这篇文章。\n二、两个方向 首先，cgo 包含了两个方向， c=\u0026amp;gt;go ，go=\u0026amp;gt;c 。\n相对来说，go=\u0026amp;gt;c 是更简单的，是在 go runtime 创建的线程中，调用执行 c 函数。对 go 调度器而言，调用 c 函数，就相当于系统调用。执行环境还是在本线程，只是调用栈有切换，还多了一个函数调用的 ABI 对齐，对于 go runtime 依赖的 GMP 环境，都是现有的，并没有太大的区别。\n而 c=\u0026amp;gt;go 则复杂很多，是在一个 c 宿主创建的线程上，调用执行 go 函数。这意味着，需要在 c 线程中，准备好 go runtime 所需要的 GMP 环境，才能运行 go 函数。以及，go 和 c 对于线程掌控的不同，主要是信号这块。所以，复杂度又高了一级。\n三、GMP 从哪里来 首先简单解释一下，为什么需要 GMP ，因为在 go 函数运行的时候，总是假设是运行在一个 goroutine 环境中，以及绑定有对应的 M 和 P 。比如，要申请内存的时候，则会先从 P 这一层 cache 的 span 中的获取，如果这些没有的话，go runtime 就没法运行了。\n虽然 M 是线程，但是具体实现上，其实就是一个 M 的数据结构来表示，对于 c 创建的协程，获取的是 extra M ，也就是单独的表示线程的 M 数据结构。\n简单来说，c 线程需要获取的 GMP ，就是三个数据对象。在具体的实现过程中，是分为两步来的：\n1. needm 获取一个 extra M\n开启了 cgo 的情况下，go runtime 会预先创建好额外的 M ，同时还会创建一个 goroutine，跟这个 M 绑定。所以，获取到 M，也就同时得到了 G。\n而且，go runtime 对于 M 并没有限制，可以认为是无限的，也就不存在获取不到 M 的情况。\n2.exitsyscall 获取 P\n是的，这个就是 go=\u0026amp;gt;c 的反向过程。只是 P 资源是有限的，可能会出现抢不到 P 的情况，此时就得看调度机制了。\n四、调度机制 简单情况下，M 和 P 资源都顺利拿到了，这个 c 线程，就可以在 M 绑定的 goroutine 中运行指定的 go 函数了。更进一步，如果 go 函数很简单，只是简单的做点纯 CPU 计算就结束了，那么这期间则不依赖 go 的调度了。\n有两种情况，会发生调度：\n1. exitsyscall 获取不到 P 此时没法继续执行了，只能：\n1.将当前 extra M 上绑定的 g ，放入全局 g 等待队列\n2.将当前 c 线程挂起，等待 g 被唤起执行\n在 g 被唤起执行的时候，因为 g 和 M 是绑定关系：\n1.执行 g 的那个线程，会挂起，让出 P ，唤起等待的 c 线程\n2.c 线程被唤起之后，拿到 P 继续执行\n2. go 函数执行过程中发生了协程挂起 比如，go 函数中发起了网络调用，需要等待网络响应，按照之前介绍的文章，Goroutine 调度 - 网络调用[2] 。当前 g 会挂起，唤醒下一个 g ，继续执行。\n但是，因为 M 和 g 是绑定关系，此时会：\n1. g 放入等待队列\n2.当前 c 线程被挂起，等待 g 被唤醒\n3. P 被释放\n在 g 被唤醒的时候，此时肯定不是在原来的 c 线程上了\n1.当前线程挂起，让出 P，唤醒等待的 c 线程\n2.c 线程被唤醒后，拿到 P，继续执行\n直观来说，也就是在 c 线程上执行的 goroutine，并不像普通的 go 线程一样，参与 go runtime 的调度。对于 go runtime 而言，协程中的网络任务，还是以非阻塞的方式在执行，只是对于 c 线程而言，则完全是以阻塞的方式来执行了。\n为什么需要这样，还是因为线程的调用栈，只有一个，没有办法并发，需要把线程挂起，保护好调用栈。\nPS：这里的执行流程，其实跟上面抢不到 P 的流程，很类似，底层也是同一套函数在跑（核心还是 schedule）。\n五、信号处理 另外一大差异是，信号处理。\n c 语言世界里，把信号处理的权利/责任，完全交给用户了。\n go 语言，则在 runtime 做了一层处理。\n 比如，一个具体的问题，当程序运行过程中，发生了 segfault 信号，此时是应该由 go 来处理，还是 c 来响应信号呢？\n答案是，看发生 segfault 时的上下文：\n1.如果正在运行 go 代码，则交给 go runtime 来处理\n2.如果正在运行 c 代码，则还是 c 来响应\n那具体是怎么实现的呢？信号处理还是比较复杂的，有比较多的细节，这里我们只介绍几个核心点。\n1. sighandler 注册 首先，对于操作系统而言，同一个信号，只能有一个 handler 。再看 go 和 c 发生 sighandler 注册的时机：\n go 编译产生的 so 文件，被加载的时候，会注册 sighandler（仅针对 go 需要用的信号），并且会把原始的 sighandler 保存下来。\n c 可以在任意的时间，注册 sighandler，可以是任意的信号。\n 所以，推荐的做法是，在加载 go so 之前，c 先完成信号注册，在 go so 加载之后，不要再注册 sighandler 了，避免覆盖 go 注册 sighandler。\n2.信号处理 对于最简单的情况，如果一个信号，只有 c 注册了 sighandler，那么还是按照常规 c 信号处理的方式来。\n对于 sigfault 这种，go 也注册了 sighandler 的信号，按照这个流程来：\n1.操作系统触发信号时，会调用 go 注册的 sighandler（最佳实践中，go 的信号注册在后面）；\n2.go sighandler 先判断是否在 c 上下文中（简单的理解，也就是没有 g，实际上还是挺复杂的）；\n3.如果，在 c 上下文中，会调用之前保存的原始 sighandler（没有原始的 sighandler，则会临时恢复 signal 配置，重新触发信号）；\n4.如果，在 go 上下文中，则会执行普通的信号处理流程。\n其中，2 和 3 是最复杂的，因为 cgo 包含了两个方向，以及信号还有 sigmask 等等额外的因素，所以这里细节是非常多的，不过思路方向还是比较清晰的。\n六、优化 上篇 cgo 实现机制[1] ，提过优化一些思路，不过主要针对 go =\u0026amp;gt; c 这个方向。因为 c =\u0026amp;gt; go 的场景中，还有其他更重要的优化点。\n1.复用 extra M 通常情况下，最大的性能消耗点在获取/释放 M。\n1.上面提到，从 c 进入 go，需要通过 needm 来获取 M 。这期间有 5 个信 …","date":1665212400,"description":"cgo 机制 - 从 c 调用 go","dir":"blog/c-go-mechanism-calling-go-from-c/20221008/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a233624b1a608f5d80599295f0599d5b","permalink":"https://sofastack.github.io/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","publishdate":"2022-10-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 4656 字 阅读 12 分钟 一、前言","tags":["SOFAStack"],"title":"cgo 机制 - 从 c 调用 go","type":"blog","url":"/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/","wordcount":4794},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. greedying 提问：\n 我发现 MOSN 去 cookie 时候，如果取不到，则返回中横线。这里万一 cookie 值就是中横线怎么办呢？\n A：你用啥接口取的？\n 用变量取的,前缀加 cookie 的 key。 \u0026amp;gt;\u0026amp;gt;MOSN 代码就是这么写的，那个 ValueNotFound 是一个短横，这是一个 feature 还是 bug？\n A：哦 确实，这儿应该返回 error 就行了，不然任何值都有可能不对。 要这样处理才合理，通过 error 来判断了。\n「MOSN」：https://github.com/mosn/mosn\n2. 卿同学 提问：\n 我看 Layotto 也在推动和 Envoy 的融合，这一块现在有进展吗？\n A：今年我们首先会开源 Envoy 的 cgo 插件，然后基于这个插件，可以把 Layotto 跑在 Envoy 上。\n「Layotto」：https://github.com/mosn/layotto\n本周推荐阅读\ncgo 机制 - 从 c 调用 go\n开源项目文档社区化！Tongsuo/铜锁实践\nGo 内存泄漏，pprof 够用了么？\nSeata AT 模式代码级详解\n欢迎扫码关注\n","date":1665126000,"description":"SOFA Weekly | C 位大咖说 \u0026 QA","dir":"blog/sofa-weekly-20221007/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2d8af727a21b1ea54ab966afa87a0c03","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221007/","publishdate":"2022-10-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20221007/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说 \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20221007/","wordcount":623},{"author":null,"categories":"SOFAStack","content":"文｜杨洋（花名：凯申 )\n铜锁开源密码库创始人蚂蚁集团高级技术专家\n本文 1284 字 阅读 5 分钟\n1 前言\n如大家所见，针对铜锁开源密码库（ *https://github.com/Tongsuo-Project*）的文档，我们正在逐步地进行一些改革。\n其中，最大的一个变化是：我们把原来放在 readthedocs.org（简记 rtfd.io）上的教程和说明文档转移到了语雀上。\n为此有必要和大家解释一下，这其中的原因以及背后的一些想法。\n2 说说历史原因\n铜锁开源项目自诞生以来，其文档管理不是那么的严格和统一。\n铜锁派生自 OpenSSL ，而 OpenSSL 的文档则是以 perldoc 体系为核心，且混合了一部分的纯文本和 markdown 。OpenSSL 的这些文档内容均散落在 OpenSSL 源代码仓库的各个目录中。\n对于 perldoc 所支持的 pod 格式的文件，可以被编译成多种不同最终格式的文档，这其中以 man 手册和 html 文件为主。\n综上所述，所以铜锁项目在早期延续了编写 pod 文件并编译成 html 和 man 手册的这种模式，随着项目的发展，我们发现此模式存在若干不足，例如：\n perldoc 这套体系过于古老，文档的编写依旧停留在“非可视化”的状态。且编译过程较为复杂，和 markdown 等相比不具备优势，也不够通用；\n man 手册也比较古老，是单机的本地模式。查询文档的功能较弱，效率较低，不如 readthedocs 这种可视化的查询文档的方式来得便捷；\n OpenSSL 的文档组织形式更多的是以 API 为出发点，而不是以“教程”为出发点，这对于很多新手用户来说无从下手。\n 3 早前的一些改进\n为了解决这些不足之处，铜锁项目将文档的重心从 API 视角切换到了教程视角，即以教会用户如何通过使用铜锁来完成某种功能为核心目标，重新组织了文档的形态，并以 markdown 写了若干教程类的文档。\n这些文档需要一个呈现平台，因此我们选择了成熟的 readthdocs.org 作为铜锁文档的发布地（https://tongsuo.rtfd.io ），并持续运行了一段时间。\n在这之后，我们又发现了一些问题：\n1.访问不便。readthedocs.org 是海外的文档托管网站，国内会出现访问比较慢甚至无法访问的状况；\n2.不容易交互。更多的是单方面的信息展示，用户真有问题还是要到 Github 上提交 issue，效率比较低。\n4 “文档社区化”的诞生\n前段时间，我机缘巧合的参与了一档播客节目的录制\n*（https://www.ximalaya.com/zhubo/343307074）*。\n在录制过程中，大家也讨论到：是否可以将互动引入到开源社区的文档体系中，将开源项目的文档“社区化”，进而形成除了代码托管平台之外的、更加贴近最终用户的社区交流讨论形式。\n受此启发，我们最后决定尝试将铜锁的全部文档迁移到语雀上，利用语雀的社区化能力，增强铜锁和其用户间的互动。具体来说有如下几点：\n1.新的文档网站地址为：*https://yuque.com/tsdoc* 。目前有两个知识库，铜锁的各种文档均分类到这些知识库中，而且都是对全网公开的，后续我们也会根据需要对知识库去做一些调整；\n2.用户可以在这些文档中进行评论；3.上述知识库的文档会每天同步备份到 Github 的指定仓库中；\n4.现有的 *https://tongsuo.rtfd.io* 将不再更新。\n此外，对于 API ，我们也会重新进行梳理，将铜锁特有的 API 整理后供用户检索查询。希望大家能和我们一起参与这场“文档社区化”的试验，欢迎伙伴们充分发表自己的意见、建议以及想法，一起将这次试验更好地落地。\n本周推荐阅读\n你好，我的新名字叫“铜锁/Tongsuo”\nBabaSSL：支持半同态加密算法 EC-ElGamal\nBabaSSL 发布 8.3.0｜实现相应隐私计算的需求\nSeata AT 模式代码级详解\n","date":1664434800,"description":"开源项目文档社区化！Tongsuo/铜锁实践","dir":"blog/20220929/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8f7a5b72bc271ef963ccea749cb0e888","permalink":"https://sofastack.github.io/sofastack.tech/blog/20220929/","publishdate":"2022-09-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/20220929/","summary":"文｜杨洋（花名：凯申 ) 铜锁开源密码库创始人蚂蚁集团高级技术专家 本文 1284 字 阅读 5 分钟 1 前言 如大家所见，针对铜锁开源密码库（ *https://gi","tags":["SOFAStack"],"title":"开源项目文档社区化！Tongsuo/铜锁实践","type":"blog","url":"/sofastack.tech/blog/20220929/","wordcount":1401},{"author":null,"categories":"SOFAStack","content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。\n本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同；\n- 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。\n平台工程旨在帮助企业构建面向应用研发者的自服务运维体系，尝试通过工程化的技术手段和工作流程解决以下关键问题：\n- 设计合理的抽象层次，帮助应用研发者降低对 Infra 、platform 等技术以及运维、稳定性工作的认知负担；\n- 为应用研发者提供统一的工作界面和空间，避免用户陷入割裂的平台产品界面、复杂的工作流中；\n- 帮助研发者通过有效的工作流程和推荐路径基于 内部工程平台[4] 快速开展工作；\n- 帮助研发者通过配套的 CI 、CD 、CDRA 等产品自服务管理应用生命周期；\n- 帮助平台产品研发团队简单、高效、一致的开放其平台基础能力；\n- 通过培训、布道、运营等手段营造协同工作和分享的文化。\n事实上，不是所有人都应该或者能够成为这个领域的专家，这非常困难！\n实际上平台技术团队的专家通常也仅擅长自己的专业领域而已，特别是在云原生理念和技术广泛应用的今天，面向大量高度开放、可配置的平台技术带来的成百上千的应用配置，PaaS 领域的业务复杂性，以及高稳定性和统一治理的要求，而平台工程的目的正是为了让应用研发者尽可能简单无痛的参与到这样规模化的 DevOps 工作中。\n在蚂蚁的实践中，我们更趋向于以下这种合作状态，在团队架构和工作模式上更靠近 Google 的最佳实践。平台研发者及 SRE 成为 “ Enabler ” 支持应用研发者自服务的完成研发及交付运维，同时应用研发者使其应用可交付运维的工作结果也成为运维人员可以接手应用运维工作的基础。最终 SRE 、应用研发及运维人员把工作过程中的问题和痛点反馈给平台研发者形成正向循环。\n三、专用语言：工程化方式的一极 有什么比一种专用语言更适合开放的、自服务的、面向领域业务的问题定义，同时需要满足自动化、低安全风险、低噪音、易治理的企业内部要求吗？正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在平台工程的特定问题域内，一批配置和策略语言用于编写和管理规模化复杂配置及策略。\n不同于混合编写范式、混合工程能力的高级通用语言，这类专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将规模化复杂配置和策略编写思路和方式沉淀到语言特性中。\n在蚂蚁的平台工程实践中，我们强化了客户端的工作方式，将围绕应用运维生命周期的模型、编排、约束和策略稳定、可扩展的通过专用语言 KCL[5] 编写维护在共享仓库 Konfig[6] 中。\nKCL 是一种面向有编程能力的应用研发者的静态强类型语言，提供现代高级语言的编写体验和围绕领域目的有限功能。在平台工程实践中 KCL 不是一种仅用于编写 K-V 对的语言，而是一种面向平台工程领域的专用语言。应用研发者、 SRE 、平台研发者面向 Konfig 协同研发，通过 KCL 原生功能编写应用配置，以及在 PaaS 领域更为高频和复杂的 模型抽象[7] 、 功能函数[8] 和 约束规则[9] ，即编写稳定、可扩展的业务模型、业务逻辑、防错约束和环境规则。\nKonfig 仓库则成为统一的编程界面，工作空间和业务层载体，而基于 KCL 的安全、低噪音、低副作用、一致的编写范式更有利于长期管理和治理。\n四、分治：解构规模化问题 分治思路是解决规模化问题的钥匙，从 MapReduce 到 Kubernetes 无不体现其功效。在规模化交付运维领域，经典运维平台试图在统一的黑盒平台产品中，以内置的统一模型、编排、 provision 技术来应对全量业务场景。这样的实践可以快速启动，在小范围内奏效，但随着不同业务主体采用率提升引入差异化需求，同时随着持续变化的平台技术逐渐进入疲态。\n在蚂蚁的实践中，Konfig monorepo 是内部工程平台向研发者开放的编程界面和工作空间，帮助应用研发者以统一的编程界面编写围绕应用运维生命周期的配置和策略，从而编排和使用存量和新增的平台基础设施，按需创建管理云原生环境以及基于 RBAC 的权限，并通过 GitOps 方式管理交付过程。\nKonfig monorepo 为不同场景、项目、应用提供了独立的白盒的编程空间，其内生的扩展性来源于：\n- 灵活、可扩展、独立的客户端的 工程结构设计[10] ；\n- 独立配置块自动合并技术[11] 支持任意分块、可扩展的配置块组织；\n- 静态类型系统[12] 技术提供现代编程语言可复用、可扩展的类型化建模和约束功能；\n- 项目粒度的 GitOps CI 工作流程定义支持；\n- 基于 Kusion[13] 引擎的 provision 技术选择。\nKonfig monorepo 提供了分治的、可组合的工程结构设计、代码组织、建模方式、工作流程定义和 provision 技术选择支持，同时又以一致的研发模式和工作流承载了可扩展的业务需求。这样客户端的工作方式在保证灵活性、可扩展性、可移植性的同时也降低了对服务 …","date":1664262000,"description":"从规模化平台工程实践，我们学到了什么？","dir":"blog/sofastack20220927/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa7d711a2d4e1a4f7c4242cbfe473fa2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack20220927/","publishdate":"2022-09-27T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofastack20220927/","summary":"文｜朵晓东（花名：奕杉 ) KusionStack 负责人、蚂蚁集团资深技术专家 在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作 一、摘要 本文尝试从平台","tags":["SOFAStack"],"title":"从规模化平台工程实践，我们学到了什么？","type":"blog","url":"/sofastack.tech/blog/sofastack20220927/","wordcount":6378},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.刘家燕 提问：\n MOSN 现在支持 TCP 服务按照端口灰度么？譬如：应用场景：接入了一个 TCP 服务，分别暴露了三个端口是 60403，60269，60129，每一个端口对应不同的业务来源，调用之后会对应不同的业务处理。目的：现在对其中一个端口例如 60403 逻辑处理做了一些调整，发版验证是否顺利调用。因此，将该服务进行灰度，创建 v1，v2 版本。当监听到 60403 端口调用时，路由到v2 ；其他端口，路由到v1 。\n A：最简单的就是你建两个 listener，不同端口的 listener 的路由对应不同的 cluster，比如 cluster_v1，cluster_v2。\n 意思是给创建灰度的版本各自创建一个 listener 吗？\n A：因为本来就要监听不同的端口，所以不同端口的 listener 配置不同的 router 就行了哦。\n「MOSN」：https://github.com/mosn/mosn/\n2.Lewise Liu \u0026amp;amp; 赵宇 提问：\n 请问，MOSN 可以与新版本 Istio 控制面集成吗？\n A：目前是支持的 1.10 ，新版本的话要做一些适配。\n 具体需要哪些适配？比如 1.14 。\n A：我的理解，主要是新版本的 xDS 会新增一些 feature，如果依赖这些新 feature 的话，就需要做一些对应的适配或许也有一些在新版本里，被废弃或者调整了的（这些应该不多的）。\n「MOSN」：https://github.com/mosn/mosn/\n本周推荐阅读 Seata AT 模式代码级详解\nGo 内存泄漏，pprof 够用了么？\n社区文章｜MOSN 构建 Subset 优化思路分享\nGo 代码城市上云——KusionStack 实践\n欢迎扫码关注：\n","date":1663916400,"description":"SOFA Weekly |开源人、本周 QA、本周 Contributor","dir":"blog/sofa-weekly/20220923/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0aeda2b5aff95f678add334d82d2e2b0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly/20220923/","publishdate":"2022-09-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly/20220923/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly |开源人、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly/20220923/","wordcount":879},{"author":null,"categories":"SOFAStack","content":" 文｜\n刘月财\nseata-go 项目负责人\n北京小桔科技有限公司【滴滴】开发工程师\n赵新（花名：于雨 )\n蚂蚁集团 Seata 项目开源负责人\n本文5343字 阅读 14分钟\n背景 Seata 四种事务模式中，AT 事务模式是阿里体系独创的事务模式，对业务无侵入，也是 Seata 用户最多的一种事务模式，兼具易用性与高性能。\n目前，Seata 社区正大力推进其多语言版本建设，Go、PHP、JS 和 Python 四个语言版本基本完成了 TCC 事务模式的实现。参照 Seata v1.5.2 版本的 AT 模式的实现，并结合 Seata 官方文档，本文尝试从代码角度详解 Seata AT 事务模式的详细流程，目的是梳理 Seata Java 版本 AT 模式的实现细节后，在多语言版本后续开发中，优先实现 AT 事务模式。\n1、什么是 AT 模式？ AT 模式是一种二阶段提交的分布式事务模式，它采用了本地 undo log 的方式来数据在修改前后的状态，并用它来实现回滚。从性能上来说，AT 模式由于有 undo log 的存在，一阶段执行完可以立即释放锁和连接资源，吞吐量比 XA 模式高。用户在使用 AT 模式的时候，只需要配置好对应的数据源即可，事务提交、回滚的流程都由 Seata 自动完成，对用户业务几乎没有入侵，使用便利。\n2、AT 模式与 ACID 和 CAP 谈论数据库的事务模式，一般都会先谈论事务相关的 ACID 特性，但在分布式场景下，还需要考虑其 CAP 性质。\n2.1 AT 与 ACID 数据库事务要满足原子性、一致性、持久性以及隔离性四个性质，即 ACID 。在分布式事务场景下，一般地，首先保证原子性和持久性，其次保证一致性，隔离性则因为其使用的不同数据库的锁、数据 MVCC 机制以及相关事务模式的差异， 具有多种隔离级别，如 MySQL 自身事务就有读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）、序列化（Serializable）等四种隔离级别。\n2.1.1 AT模式的读隔离 在数据库本地事务隔离级别读已提交（Read Committed） 或以上的基础上，Seata（AT 模式）的默认全局隔离级别是读未提交（Read Uncommitted） 。\n如果应用在特定场景下，必须要求全局的读已提交，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。 SELECT FOR UPDATE 语句的执行会查询全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到全局锁拿到，即读取的相关数据是已提交的，才返回。\n出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。\n详细例子参考 Seata 官网：https://seata.io/zh-cn/docs/dev/mode/at-mode.html\n2.1.2 AT 模式的写隔离 AT 会对写操作的 SQL 进行拦截，提交本地事务前，会向 TC 获取全局锁，未获取到全局锁的情况下，不能进行写，以此来保证不会发生写冲突：\n- 一阶段本地事务提交前，需要确保先拿到全局锁；\n- 拿不到全局锁，不能提交本地事务；\n- 拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。\n详细例子参考 Seata 官网：https://seata.io/zh-cn/docs/dev/mode/at-mode.html\n2.2 AT 与 CAP Seata 所有的事务模式在一般情况下，是需要保证 CP，即一致性和分区容错性，因为分布式事务的核心就是要保证数据的一致性（包括弱一致性）。比如，在一些交易场景下，涉及到多个系统的金额的变化，保证一致性可以避免系统产生资损。\n分布式系统不可避免地会出现服务不可用的情况，如 Seata 的 TC 出现不可用时，用户可能希望通过服务降级，优先保证整个服务的可用性，此时 Seata 需要从 CP 系统转换为一个保证 AP 的系统。\n比如，有一个服务是给用户端提供用户修改信息的功能，假如此时 TC 服务出现问题，为了不影响用户的使用体验，我们希望服务仍然可用，只不过所有的 SQL 的执行降级为不走全局事务，而是当做本地事务执行。\nAT 模式默认优先保证 CP，但提供了配置通道让用户在 CP 和 AP 两种模式下进行切换：\n- 配置文件的 tm.degrade-check 参数，其值为 true 则分支事务保证 AP，反之保证 CP；\n- 手动修改配置中心的 service.disableGlobalTransaction 属性为 true，则关闭全局事务实现 AP。\n3、AT 数据源代理 在 AT 模式中，用户只需要配置好 AT 的代理数据源即可， AT 的所有流程都在代理数据源中完成，对用户无感知。 AT 数据源代理的整体类结构如下图：\n AT 事务数据源代理类结构图【from *https://seata.io/zh-cn/docs/dev/mode/xa-mode.html*】\nAT 的数据源代理中，分别对目标数据库的 DataSource 、 Connection 和 Statement 进行了代理，在执行目标 SQL 动作之前，完成了 RM 资源注册、 undo log 生成、分支事务注册、分支事务提交/回滚等操作，而这些操作对用户并无感知。\n下面的时序图中，展示了 AT 模式在执行过程中，这几个代理类的动作细节：\n注：图片建议在 PC 端查看\n4、AT 模式流程 以下是 AT 模式的整体流程，从这里可以看到分布式事务各个关键动作的执行时机，每个动作细节，我们后面来讨论：\n注：图片建议在 PC 端查看\n4.1 一阶段 在 AT 模式的第一阶段， Seata 会通过代理数据源，拦截用户执行的业务 SQL ，假如用户没有开启事务，会自动开启一个新事务。如果业务 SQL 是写操作（增、删、改操作）类型，会解析业务 SQL 的语法，生成 SELECT SQL 语句，把要被修改的记录查出来，保存为 “before image” 。然后执行业务 SQL ，执行完后用同样的原理，将已经被修改的记录查出来，保存为 “after image” ，至此一个 undo log 记录就完整了。随后 RM 会向 TC 注册分支事务， TC 侧会新加锁记录，锁可以保证 AT 模式的读、写隔离。RM 再将 undo log 和业务 SQL 的本地事务提交，保证业务 SQL 和保存 undo log 记录 SQL 的原子性。\n4.2 二阶段提交 AT 模式的二阶段提交，TC 侧会将该事务的锁删除，然后通知 RM 异步删除 undo log 记录即可。\n4.3 二阶段回滚 如果 AT 模式的二阶段是回滚，那么 RM 侧需要根据一阶段保存的 undo log 数据中的 before image 记录，通过逆向 SQL 的方式，对 …","date":1663657200,"description":"Seata AT 模式代码级详解","dir":"blog/20220920/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6769242244447e5e61c3cd74b1d4fbbb","permalink":"https://sofastack.github.io/sofastack.tech/blog/20220920/","publishdate":"2022-09-20T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/20220920/","summary":"文｜ 刘月财 seata-go 项目负责人 北京小桔科技有限公司【滴滴】开发工程师 赵新（花名：于雨 ) 蚂蚁集团 Seata 项目开源负责人 本文5343字 阅读 14分钟 背景 Seata 四种事","tags":["SOFAStack"],"title":"Seata AT 模式代码级详解","type":"blog","url":"/sofastack.tech/blog/20220920/","wordcount":4292},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1.杜鑫 提问：\n 想问下 MOSN 的基于 Go plugin 实现的插件机制，有相关文档介绍嘛，源码大概在哪个部分呀？想接入下试试。\n A：有好几种，有 Go plugin 独立进程的，有 Go so 编译的，我发你文档先看看。\n 这个看啦，我看文档里说 so 的方式还在 beta，没有详细介绍，想了解下 so 方式的介绍。\n A：so 的，我们最近有位同学才分享了，干货满满：https://mp.weixin.qq.com/s/VAYrtYBdzvcAOa7G_cMZRg ，这里有个 demo，https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions 以及一些插件的实现，https://github.com/mosn/extensions/tree/master/go-plugin\n「MOSN」：https://github.com/mosn/mosn/\n2.林楠 提问：\n 有一个问题，动态部署时报找不到 CommonLoggingApplicationListener 类，这个类在基座中有这个类 https://github.com/sofastack/sofa-ark/issues/561\n A：说明这个类没有成功委托给基座加载，可以断下 BizClassLoader.loadClassInternal 方法，看下模块类加载的寻找过程。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 MOSN｜Go 原生插件使用问题全解析\nGo 内存泄漏，pprof 够用了么？\n如何看待 Dapr、Layotto 这种多运行时架构？\nSOFAServerless 助力业务极速研发\n欢迎扫码关注：\n","date":1663311600,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220916/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"810dfae8641310109a14ebe511d3d818","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220916/","publishdate":"2022-09-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220916/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220916/","wordcount":864},{"author":"SOFA 团队","categories":"SOFATalk","content":" 概要 活动主题：SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 活动时间：09 月 14 日，周三晚 19 点 活动形式：线上直播 直播回放：点击观看 资料下载：戳这里 查看文章：SOFARegistry 源码解析｜推送延迟 tracre 介绍 | SOFATalk \u0026amp;lt;SOFA:Talk/\u0026amp;gt; SOFATalk 系列活动是 SOFAStack 社区开展的全新直播栏目，与以往的直播不同的是，SOFATalk 为大家搭建了一个更加自由开放的交流环境，参与者不仅可以在直播间发送弹幕讨论，还能够进入钉钉会议与嘉宾直接连麦讨论！茶余饭后，跟着 SOFA Talk 一下～\n| SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 对于分布式注册中心，整个推送过程涉及到很多的流程和节点。如何计算从发布端变更到广播给全集群所有的订阅方的延迟？以及每个阶段的延迟分别是多少？这对排查集群内部的问题及注册中心的负载具有比较大的价值，因此需要对整个推送过程进行延迟链路跟踪。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：44858463（搜索群号加入即可）\n分享嘉宾 张晨\n SOFARegistry Contributor，开源爱好者。\n 嘉宾海报 了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1663138800,"description":"2022 年 9 月 14 日 19：00 - 20：00 ，Talk 第 1 期。","dir":"activities/sofa-talk-1/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7a05d225a66088112646cb4424d8f344","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-talk-1/","publishdate":"2022-09-14T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-talk-1/","summary":"概要 活动主题：SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace 活动时间：09 月 14 日，周三晚 19 点 活动形式：线上直播 直播回放：点击观看 资料下载：戳这里","tags":["SOFATalk","SOFARegistry","源码解析"],"title":"SOFATalk#1 SOFARegistry 源码解析：推送延迟 trace","type":"activities","url":"/sofastack.tech/activities/sofa-talk-1/","wordcount":473},{"author":null,"categories":"SOFAStack","content":" 文｜朱德江（GitHub ID：doujiang24)\nMOSN 项目核心开发者、蚂蚁集团技术专家\n专注于云原生网关研发的相关工作\n本文 2651 字 阅读 8 分钟\nMOSN 是主要使用 Go 语言开发的云原生网络代理平台，在蚂蚁集团有着几十万容器的大规模生产应用。在这种大规模的应用中，经常会遇到各种内存问题，通常情况下 pprof heap profile 可以很好帮助分析问题。不过，有时候 pprof 也不够用，也就需要我们有更合适的工具了。\nPart.1\u0026amp;ndash;出生证 vs 暂住证 首先 pprof 确实很好用，设计实现也都很精巧，有兴趣的可以查看这篇《Go 语言 pprof heap profile 实现机制》[1]。\n用 pprof 来分析内存泄漏，通常情况下是够用了，不过有时候，也会不够用。\n这是为什么呢？因为 pprof 只是记录了内存对象被创建时的调用栈，并没有引用关系。也就是说，没有办法知道，内存对象是因为被谁引用了而导致没有被释放。对此，我的同事\u0026amp;ndash;烈元同学有一个很形象的比喻，pprof 只能看到出生证，却查不了暂住证。\nPart.2\u0026amp;ndash;需要引用关系 有些场景下，我们知道了泄漏的内存是从哪里申请的，但是翻了半天代码，也搞不清楚内存为什么没有释放。比如，内存对象经过复杂的调用传递，或者复杂的内存池复用机制，又或者传给了某个不熟悉的第三方库，在第三方库中有非预期的使用……\n在这些情况下，我们会有一个很直觉的想法是，想看看这些内存对象的引用关系。\nPart.3\u0026amp;ndash;内存引用关系火焰图 内存引用关系火焰图，是一种内存对象引用关系的可视化方式，最早应用于 OpenResty XRay 产品。这个工具确实是内存分析神器，给不少的客户定位过内存问题，感兴趣的可以移步 OpenResty 官方博客[2]。\n下图是由一个 MOSN 服务产生的，自下而上表示的是从 GC root 到 GC object 的引用关系链，宽度表示的是对象大小 （也包括其引用的对象的大小之和） 。\n有了这样的可视化结果，我们就可以直观的看到内存对象的引用关系。\n比如下图最宽的部分，表示的是 MOSN 中 cluster_manager 全局变量中引用的 cluster 内存对象：\nhttps://github.com/mosn/mosn/blob/aecc93c4b2b4801e7992387f245fe9eefa45733d/pkg/upstream/cluster/cluster_manager.go#L82\nPart.4\u0026amp;ndash;实现原理 在生成火焰图之前，首先我们需要提取两个关键信息：\n- 每个内存对象之间的引用关系；\n- 每个内存对象的类型。\n引用关系 获取引用关系比较简单，首先，我们可以在 heap 中找到所有的 GC 对象。然后遍历所有的对象，再结合 bitmap 信息，获取这个对象引用的其他对象。基本原理跟 GC mark 是类似的，虽然实现上很不一样，但因为这个是离线工具，可以简单粗暴的实现。\n类型推导 Go 语言作为编译型静态语言，是不需要为每个内存对象存储类型信息的 （有点例外的是 interface） 。如果是动态类型语言，比如 Lua，则会方便很多，每个 GC 对象都存储了对象的类型。\n所以，要获取每个对象的类型，还是比较麻烦的，也是投入时间最多的一块。当然，还是有解决办法的，简单来说就是做逆向类型推导，根据已知内存的类型信息，推导被引用的内存对象的类型信息。\n这块还是比较复杂的，有兴趣的可以看这篇《Go 语言，如何做逆向类型推导》[3]的介绍。\n生成过程 有了这两个关键信息之后，生成过程如下还是比较清晰的：\n1. 获取所有的内存对象，包括类型、大小，以及他们之间的引用关系，形成一个图；\n2. 从 root 对象出发，按照层次遍历，形成一棵树 （也就是剪枝过程，每个对象只能被引用一次） ；\n3. 将这棵树的完整引用关系，当做 backtrace dump 下来，count 是当前节点的总大小 （包括所有子节点） ，也就是火焰图上的宽度；\n4. 从 bt 文件生成 svg，这一步是 brendangregg 的 FlameGraph 标准工具链。\nPart.5\u0026amp;ndash;使用方式 这个工具是基于 Go 官方的 viewcore 改进来的。不过，鉴于 Go 官方不那么热心维护 viewcore 了，MOSN 社区先 fork 了一份，搞了个 mosn 分支，作为 MOSN 社区维护的主分支。\n之前也给 Go 官方 debug 提交了好几个 bugfix，等后面有空，我们再去提交这个 feature。\n所以，使用方式如下：\n# 编译 mosn 维护的 viewcore git clone git@github.com:mosn/debug.git cd debug/cmd/viewcore go build . # 假设已经有了一个 core 文件（CORE-FILE） # 以及对应的可执行程序文件（BIN-FILE） viewcore CORE-FILE --exe BIN-FILE objref ref.bt # 下载 FlameGraph 工具 git clone git@github.com:brendangregg/FlameGraph.git ../FlameGraph/stackcollapse-stap.pl ref.bt | ../FlameGraph/flamegraph.pl\u0026amp;gt; ref.svg # 浏览器打开 ref.svg 即可看到火焰图 如果使用碰到问题，可以随时联系我们或提交 issue（https://github.com/mosn/mosn/issues）。\n当然，倘若你成功定位了某个问题，也欢迎与我们共同分享，Let\u0026amp;rsquo;s have fun together！\nMOSN 用户钉钉群：33547952\n相关链接 [1] 《Go 语言 pprof heap profile 实现机制》：https://uncledou.site/2022/go-pprof-heap/\n[2] OpenResty 官方博客：https://blog.openresty.com.cn/cn/openresty-xray-case-yundun/\n[3] 《Go 语言，如何做逆向类型推导》：https://uncledou.site/2022/go-type-derivation/\n了解更多… MOSN Star 一下✨： https://github.com/mosn/mosn\n插播一条好消息！🤩\n对 Go 语言开发感兴趣的小伙伴们,欢迎大家参与到近期正热的 GoCity 项目体验\n点击此处查看演示视频，快速入门吧🥳\n本周推荐阅读 MOSN 反向通道详解\nGo 原生插件使用问题全解析\nGo 代码城市上云\u0026amp;ndash;KusionStack 实践\nMOSN 文档使用指南\n欢迎扫码关注：\n","date":1663052400,"description":"Go 内存泄漏，pprof 够用了吗？","dir":"blog/is-pprof-enough-for-go-memory-leak/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c96e193420c2f17fd7653b33766f4296","permalink":"https://sofastack.github.io/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","publishdate":"2022-09-13T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","summary":"文｜朱德江（GitHub ID：doujiang24) MOSN 项目核心开发者、蚂蚁集团技术专家 专注于云原生网关研发的相关工作 本文 2651 字 阅读 8 分钟 MOSN 是主","tags":["SOFAStack"],"title":"Go 内存泄漏，pprof 够用了吗？","type":"blog","url":"/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/","wordcount":2059},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题通过\u0026amp;rdquo;SOFA WEEKLY\u0026amp;rdquo;的形式回复\n1.我是一个小胖子 提问：\n MOSN 现在是已经完整支持 xDS 协议了吗？\n A：支持 istio1.10。\n 如果要支持 istio1.14 是需要重新适配吗？还是说有其他简化的方式？\n A：是需要适配下的，主要看新增了多少改动。\n「MOSN」：https://github.com/mosn/mosn/\n2.林楠 提问：\n 关在 uninstall biz 包的时候，没有从内嵌 Tomcat 卸载掉，接口仍能访问。看到 demo 中的提示是由于未注册 BeforeBizStopEvent，所以不具备动态卸载能力。想问下 SOFAArk 是否有计划做 Tomcat 的动态卸载，如果想自行实现的话，是不是调用 ArkTomcatWebServer 实例的 stop 方法就能够实现动态卸载？\n A：Spring Boot 模块没有动态卸载能力：https://github.com/sofastack/sofa-ark/issues/554#issuecomment-1207183454\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 MOSN｜Go 原生插件使用问题全解析\n社区文章｜MOSN反向通道详解\nMOSN 文档使用指南\nSOFAServerless 助力业务极速研发\n欢迎扫码关注：\n","date":1662706800,"description":"SOFA Weekly | Go 代码城市、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220909/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b48f13a6692060ffac5ff1eeb1886fb2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220909/","publishdate":"2022-09-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220909/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Go 代码城市、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220909/","wordcount":749},{"author":null,"categories":"SOFAStack","content":"导语\nKusionStack 是面向 Kubernetes 云原生场景的 IaC 配置代码化实践的开源一站式可编程协议栈。其基本思想是让「应用方+平台方」的同学能够共同基于 IaC 构建的 Konfig 模型库同一平面进行 DevOps 协同工作。今天我们和大家分享一个好玩的 Go 代码城市应用，以及 KusionStack 是如何一键将其部署到 K8s 云原生环境的。\nKusionStack 项目主仓库：\nhttps://github.com/KusionStack/kusion\nPART. 1\n什么是代码城市（CodeCity）\nCodeCity 代码城市是瑞典工程师 Richard Wettel 开发的创意应用，可以通过类似数字城市的视觉形式展示和度量代码的复杂性。其效果如图：\n在 3D 形式展示的代码城市中的中心地标非常直观——最大、最高的建筑总是容易追踪的焦点。因为这个极具特色的创意，CodeCity 获得了 2008 年的\u0026amp;rdquo;Riconoscimento ated-ICT Ticino\u0026amp;rdquo; 一等奖，同时也可以免费用于非商业的科研和学习用途。\n今天要展示的 GoCity 是 Go 语言版本的代码城市，我们可以通过这种方式评估 KusionStack 等 Go 语言项目的代码复杂度。也可以通过在线的 GoCity 查看 KusionStack/kusion 仓库的展示效果。\nPART. 2\n本地执行 GO 代码城市\n之前的 GoCity 还是在 2021 年 10 月更新的，在最新的 Docker 和 Go1.18 环境有一些小问题，还好 KusionStack 相关同学为其提交了补丁进行了修复（_这也是开源项目的魅力所在，也希望开源社区小伙伴能够参与 KusionStack 的共建_），现在可以执行以下命令安装：go install github.com/rodrigo-brito/gocity@latest。然后通过 gocity open 打开 Github 或本地仓库。\n- 比如打开本地的 KusionStack/kusion 仓库\n- 然后浏览器打开对应页面\n本地执行一切正常！\nPART. 3\nGo 代码城市一键上云\n作为一个类似数字城市的应用，在云原生、元宇宙等背景下，部署上云也是一个自然的需求。同时我们也希望通过 GoCity 展示下 KusionStack 的基本用法。在 GoCity 上云之前，我们先尝试如何本地执行该应用。\n相应的容器镜像已经推送到 Docker Hubhttps://hub.docker.com/r/yuanhao1223/gocity，运行命令如下：\n运行成功后，可打开本地地址http://localhost:4000/查看 Go 项目的数字城市 3D 效果。\n容器化成功后，现在准备上云。从本地执行容器的方式可以看出，想要在 Kubernetes 部署，至少需要 Deployment 和 Service 两种资源。其中 Deployment 用来部署 Go 代码城市，Service 暴露端口，访问无状态应用。\n首先参考安装文档https://kusionstack.io/docs/user_docs/getting-started/install/安装好本地 Kusion 命令，然后通过 kusion init 的在线仓库提供了相应的模板。Kusion 命令支持一键初始化配置：\n输出类似以下信息：\n为了方便展示，Kusion 模板已经内置了 CodeCity 的例子。其中 code-city 模板依赖 konfig 大库中抽象化的前/后端模型，code-city 模板无依赖，可以自闭环。我们选择后者：\n初始化过程中，指定了容器镜像，并且容器端口和 Service 端口均为 4000，现在进入配置目录，目录结构如下：\n- 完整的代码可以参考 ：\nhttps://github.com/KusionStack/kusion-templates/tree/main/code-city-demo\n为了方便本地测试，可以通过 minikube start 本地启动 MiniKube 服务。然后命令行模式切换到 code-city-kcl 目录，然后执行 kusion apply 命令生效配置。到此，开始正式上云： kusion apply main.k\n输出类似于：\n检查 Deployment 的状态：\n输出类似于：\n使用 kubectl 端口转发：\n访问本地地址https://localhost:4000/)，点击 Example 处的链接 “KusionStack/kusion”，可以看到和本地执行一样的效果：\n至此，完成了 Go 代码城市的一键上云。有兴趣的读者，可以基于模型库 Konfig，选择其他模板，探索 KusionStack 支持的其它运维场景，下面我们将探索代码城市内部的原理。\nPART. 4\n认识数字城市中的建筑含义\n说实话代码城市第一眼看上去更像一个电路板，要理解其中的含义需要了解几个基本的参数映射关系，如预览页面的右下角图所示：\n以上的对应关系在其官方文档中也说明，如下图所示：\n其中地面的粉红色表示 Go 包对应的目录（_因为包的依赖关系可能再产生叠加_），灰色表示目录内部的文件，而蓝色表示结构体。其中表示文件的灰色建筑物的大小即文件的大小，表示结构体的蓝色建筑物的高度即方法的数量，建筑物的长宽表示结构体中属性的数量，蓝色颜色的深度表示相关代码行数。\n我们可以选择 DiffOptions 结构体对应建筑物查看其相关的属性参数：\n可以看到该结构体中有 15 个属性、3 个方法、共 156 行代码。通过点击其中的 “Github 链接” 按钮可以跳转到对应的位置：\n因此通过这种方式我们可以很容易查看全局有无特别高大的建筑，从而判断是否存在某些文件和结构体的代码需要改进。可以说 GoCity 是一个很有趣的代码分析工具，甚至可以集成到 Github PR 代码评审流程中。\nPART. 5\n分析 GoCity 的代码架构\nGoCity 代码架构主要分为代码数据提取和前端模型展示两块，如图所示：\n首先 Codebase 表示要展示的代码，通过 Git Service 被拉取，然后通过 Parser 和 Position 服务提取得到对应的参数信息，然后通过前端展示。Go 语言代码主要集中在模型数据提取部分，而前端展示主要为 JS 等实现。前端展示资源文件通过 embed.FS 内嵌到程序中，GoCity 命令启动 Web 服务展示页面。代码架构比较清晰，也是一个比较理想可用于 Go 语言学习的开源项目。\nPART. 6\n展望\n我们通过 KusionStack 的方式，配合少量的 KCL 配置代码，完成了 Go 代码城市一键上云的操作。虽然云上的 Go 代码城市和本地的版本看不出什么区别，但是云上程序的整个生命周期管理将大为不同。在后面的例子中我们将展示如何通过 KusionStack 结合 KCL 配置语言进行 IaC 方式的云原生应用的运维操作。感谢关注🙏\n参考链接\n● …","date":1661842800,"description":"Go 代码城市上云——KusionStack 实践","dir":"blog/go-code-city-cloud-kusionstack-practice/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"577810f0ec8cee7a80e6717647a67bbe","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","publishdate":"2022-08-30T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","summary":"导语 KusionStack 是面向 Kubernetes 云原生场景的 IaC 配置代码化实践的开源一站式可编程协议栈。其基本思想是让「应用方+平台方」的同学能够共同基于 IaC 构建的 Konfig 模型库同一平","tags":["SOFAStack"],"title":"Go 代码城市上云——KusionStack 实践","type":"blog","url":"/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/","wordcount":2203},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动,我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1. 孙春明 提问：\n 请问这个 mosnd 是做什么的？我如果想重新做 mosnio/proxyv2:v1.0.0-1.10.6 镜像，需要怎么处理呢？\n A：这个 mosnd 只是 mosn 的拷贝，可以看下这个文档：https://mosn.io/docs/user-guide/start/istio/#mosn-%E4%B8%8E-istio-%E7%9A%84-proxyv2-%E9%95%9C%E5%83%8F-build-%E6%96%B9%E6%B3%95\n「MOSN」：https://github.com/mosn/mosn\n2. 胡 提问：\n 请问这边有现成用 SOFAStack 搭建的框架包吗，内容涉及 SOFABoot、SOFARegistry、SOFARPC 的？\n A：现成的框架包的话，你可以从 SOFABoot 开始，参考这个：https://www.sofastack.tech/projects/sofa-boot/quick-start/\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n「SOFARegistry」： https://github.com/sofastack/sofa-registry\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nMOSN v1.1.0 版本发布\n发布 MOSN v1.1.0 版本，主要变更如下：\n 支持反向建连，云边互联场景，细节可以参考博客： https://mosn.io/blog/posts/mosn-tunnel/\n 支持自定义 xDS 解析扩展\n trace 支持 zipkin 扩展\n 优化创建 subset 负载均衡的算法，降低内存占用\n 详细发布报告：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md\n本周推荐阅读\nMOSN 构建 Subset 优化思路分享\nMOSN 1.0 发布，开启新架构演进\nMOSN 社区性能分析利器——Holmes 原理浅析\nMOSN 反向通道详解\n欢迎扫码关注\n","date":1661497200,"description":"SOFA Weekly | MOSN v1.1.0 版本发布、C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220826/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"60009aeca74279e2fb1f880466fa50dd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220826/","publishdate":"2022-08-26T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220826/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN v1.1.0 版本发布、C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220826/","wordcount":951},{"author":null,"categories":"SOFAStack","content":"文｜史贵明（花名：莫城)\n蚂蚁集团技术专家\n蚂蚁集团多云配置管理系统技术负责人\n云原生基础设施领域，容器服务、配置管理、IaC、PaC、GitOps 等方向\n本文 2369 字 阅读 7 分钟\n背景\n要讲 Kusion 在蚂蚁集团的实践，我们首先来了解下蚂蚁集团在此之前的配置管理状况。\n如上图所示，图中展示的是在结合 Kusion 之前的应用基线配置管理系统。这里提到的 “应用基线配置” 非应用动态开关，而是注入应用依赖的软件版本、中间件配置、网络数据库等基础设施配置。\n从上图可以看到，应用基线管理系统是标准 BS 架构，对用户提供 Console 和 API，历经 6、7 年发展历史，承担起蚂蚁集团历史上绝大多数应用基线配置需求，功能丰富且拥有极其复杂的配置计算能力。目前已经支撑了 15000+ 应用、近 400 项应用配置、50+ 全局配置。\n在这个架构下，最上层用户通过表单或者集成系统 API 来与系统交互，以 RDBMS 为存储介质，将应用的配置以类 Key-Value 形式存储。能力层主要包含通用的角色管理、认证鉴权、版本与配置审计等通用能力，还提供模板化的方式来计算应用配置，如将 Deployment 模板化，最终将用户的基线配置渲染为 Deployment，同时模板与基线配置都存在非常复杂而又灵活的继承能力，举个例子，可以给应用配置 Zone_（逻辑机房）_级别的基线，也可以配置环境级别的基线，或者应用级别的基线，前者可以继承后者，就像子类和父类的集成关系。\n除了应用本身的基线配置，同时也管理了全局配置，如全局的 DNS 配置、Load Balance、网路配置等等。这个架构非常经典，并且有效支持了历史上各种配置需求及各种 618、双 11 等场景，这些都是毋庸置疑的。但是随着蚂蚁集团云原生化进程的推进，上面的经典架构也逐渐出现一些瓶颈。 不知道大家对于这种架构的配置管理，或者架构有没有遇到这样的问题？我来举几个例子：\n● 灵活性： 业务越来越多，应用的基础设施配置也更加的灵活，各种定制化需求越来越多，原有架构主要解决标准应用的场景和通用场景；\n● 开放性： 基线系统的核心能力主要代码在 PaaS 同学这边负责，对于多种多样的需求需要内部排期支持，开放性不足，无法复用和沉淀强大的 SRE 团队的经验；\n● 透明性： 配置计算黑盒，很多配置的计算逻辑都 hardcoding 在代码中，一个配置的变更最终会影响什么、影响有多大无法确定。比如修改了全局 sidecar 版本，导致线上应用批量异常。\n业界对标\n带着上面这些问题，我们在业界做了一些对标和学习:\n1.在 Google的《The Site Reliability Workbook》这本书中，Google 同学从自身的实践中总结出一些常见问题，其中非常重要的一点是：在做配置管理过程中，没有意识到，大规模配置管理问题的本质是编程语言问题。配置需求的声明、校验都可以通过语言来解决。\n2.从 Google 自身的实践来讲，K8s 是基于 Google 多年大规模集群管理经验贡献的开源产品，但是其内部主要使用的是 Borg，Borg 团队是在 Borg master 之上研发的，Borg 接入的三件套分别是：\n● BCL： 用户通过编写 BCL 代码实现对基础设施需要的配置；\n● Borgcfg： 通过 Borgcfg 将配置执行到 Borg 集群；\n● Webconsole： 通过 Webconsole 查看发布情况。\n经过调研，我们了解到 Google 大量的运维能力、产品、质量生态都是基于上述三件套演进多年。\n基于上述的一些总结，我们推演出类 Borg 的思路来解决蚂蚁集团的基础设施配置管理，我们尝试用语言和工具及服务实现蚂蚁集团下一代配置管理架构。\n下一代配置管理架构\n在这个新的架构下，我们可以看到整体架构不仅仅是一个简单的 BS 架构，配置的用户界面也从浏览器 Form 表单演进为中央开放配置大库。而配置大库所使用的就是 Kusion，Kusion 的用户使用前面的同学已经讲过了，对于配置大库本身的技术细节我不做过多的展开，这里强调的是大库在设计上支持多站点交付的架构。\n新配置管理架构主要分为以下几个特点：\n● 基于配置代码化理念抽象建设统一的应用配置模型，沉淀可重用模型组件，实现配置代码一次编写多站点可迁移。抽象领域模型：Stack 是配置的最小集合，Project 是一组 Stack 的抽象，不仅囊括 App 的应用基线配置, 也支持其他如 DataBase 配置、负载均衡配置，甚至 Network Policy 等非应用配置。\n● 通过策略控制器机制，创建与组织独特的安全性，合规性和治理要求相对应的防护规则。\n● 声明式自动化，持续监控运行状态并确保符合 Git 中定义的期望状态。\n应用发布案例\n接下来结合一个具体产品案例做阐述，在这个案例中以应用迭代发布为例：\n1.用户在业务迭代中，修改业务代码、提交代码、CI 测试、构建镜像，并将构建的镜像推送到远程镜像中心。然后通过配置管理服务层——这里是 auto-image-updater 组件——自动将配置更新到配置大库对应的配置文件中。\n2.触发大库的变更扫描、测试、审核等一些列的质保手段，同时触发一次应用发布流程，应用发布流程是具有风险体系的、可视化的发布流程，包括推进流程要从预发、仿真、灰度逐步推进，最后进入生产环境。\n在每个推进阶段，需要从配置大库获取到配置代码并同时使用配置管理服务层获取 KCL 的编译结果，也就是 Spec 模型，然后通过产品化方式将 Spec 与生产环境中真实的 Runtime 进行“Live Diff”以供参与人更好地识别变更内容和变更范围，然后以分组发布等具有风险防控的手段变更到对应环境，如 apply 到 K8s 集群。\n3.我们看下过程中的具体可视化产品，可以看到发布进度、应用配置的 Diff，以及可以看到历史版本的配置。\n问题与展望\n回顾下我们开始提到的几个问题：\n1. 灵活性： 即对各种灵活定制化需求的支持;\n2. 开放性： 通过 KCL 语言及开放配置大库，用户的基础设施配置通过新的用户界面即可自主完成，不需要等待配置管理平台开发人员进行开发；\n3. 透明性： 变更过程可以通过产品化的“Live Diff”来识别变更风险；\n我们通过上述的一些探索，一定程度上解决了蚂蚁集团在推进云原生进程中的问题，过程中也遇到了方方面面的困难，比如如何从老架构切换到新架构？架构代际演进时新老系统并存问题是必须要解决的，可以通过如双写等方式解决。在新架构下更值得探讨的有如下问题，全局配置如何管理以及如何更好的扩展配置的维度。\n站点的全局配置，在老的基线配置的全局配置不仅仅是简单的 Key-Value， 在使用上是非常复杂的，比如 DNSConfig 配置，按照租户、环境、Zone 等做了不同的优先级编排，对于这些的描述比较复杂，使用 KCL 描述如此复杂的配置很困难。\n针对于配置的继承和扩展，以 APP 基线配置为例，目前更多的是支持应用和应用环境级别的配置，针对 Zone 等细粒度的配置需要在 KCL 代码中通过写 if else 来实现，这对 …","date":1661238000,"description":"KusionStack 在蚂蚁集团的探索实践 (上)","dir":"blog/kusionstack-in-practice-at-ant-group-first/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8bfaea9639af72bb640f142108de2d90","permalink":"https://sofastack.github.io/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","publishdate":"2022-08-23T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","summary":"文｜史贵明（花名：莫城) 蚂蚁集团技术专家 蚂蚁集团多云配置管理系统技术负责人 云原生基础设施领域，容器服务、配置管理、IaC、PaC、GitOp","tags":["SOFAStack"],"title":"KusionStack 在蚂蚁集团的探索实践 (上)","type":"blog","url":"/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/","wordcount":2774},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 卿同学 提问：\n 想咨询一下，目前蚂蚁内部使用 MOSN 外有使用到 Envoy 吗？\n A：目前蚂蚁的东西向网关是 MOSN on Envoy 的，Layotto on Envoy 也在试点中，所以没有直接使用 Envoy，不过很多场景是跑在 Envoy 上的。\n 那在 RPC、MQ、DB 流量这块都走 MOSN 流量拦截的方式吗？还是基于 Layotto API 的方式呢？\n A：目前主要是 MOSN，多语言和多云场景在走 Layotto 的方式。\n 我看 Layotto 也在推动和 Envoy 的融合，这一块现在有进展吗？\n A：今年我们首先会开源 Envoy 的 cgo 插件，然后基于这个插件，可以把 Layotto 跑在 Envoy 上。\n「MOSN」：https://github.com/mosn/mosn\n「Layotto」：https://github.com/mosn/layotto\n2. 古寒 提问：\n 咨询下， MOSN 部署有指导文档嘛？\n A：有的，看下这个文档，https://mosn.io/docs/user-guide/start/proxy/\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 社区文章｜MOSN 构建 Subset 优化思路分享\n如何看待 Dapr、Layotto 这种多运行时架构\nMOSN 文档使用指南\nMOSN 社区性能分析利器——Holmes 原理浅析\n欢迎扫码关注：\n","date":1660892400,"description":"SOFA Weekly | C 位大咖说、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220819/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"187a873747e511ae312c36058eb71f8c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220819/","publishdate":"2022-08-19T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220819/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220819/","wordcount":758},{"author":null,"categories":"SOFAStack","content":" 文｜\n赵新（花名：于雨)：蚂蚁集团 Seata 项目开源负责人、开放原子开源基金会代码贡献之星\n郭成（花名：星北)：Seata-php 项目共同发起人、蚂蚁集团技术专家\n刘岳健：Seata-php 项目共同发起人、Hyperf 开发组成员、广东快客电子商务有限公司高级后端工程师\n本文 5894 字 阅读 12 分钟\n导语 通俗地讲，seata-php 是 Seata 的 PHP 语言实现，它实现了 Java 和 PHP 之间的互通，让 PHPer 也能使用 seata-php 来实现分布式事务。\nSeata 是一个非常成熟的分布式事务框架，在 Java 领域是事实上的分布式事务技术标准平台。Seata 目前正在构建其多语言体系[1]，整个体系包含了目前常用的五大类语言：Java、Go、Python、JS 和 PHP。目前的态势是后四种语言都依据 Seata Java 版本构建起对应语言的实现。\n除了追求 Seata 多语言体系过程中因为开源价值要求构建 Seata 的 PHP 版本这个原因外，作为构建起 Web 1.0 时代技术基础 LAMP 架构中的要角，PHP 语言在电商和金融交易场景下依然被广泛使用。而这些场景对数据一致性要求非常强烈，这是构建 seata-php 最大的诱因，也是其技术价值所在。\nPART. 1\u0026amp;ndash;Seata 架构与多语言体系 图片来自 Seata 官网\n Seata 总体架构由如下角色构成：\n- 事务协调器 Transaction Coordinator\n简称 TC，维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n- 事务管理器 Transaction Manager\n简称 TM，定义全局事务的范围，提交或者回滚全局事务。\n- 资源管理器 Resource Manager\n简称 RM，和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\n从 C/S 通信架构角度来看，TC 是服务端，TM 和 RM 是客户端。TC 与 TM 以及各个 RM 之间使用 Netty 框架进行长链接通信。具体而言，Seata Java 版本的通信协议是在四层 TCP 协议之上又定义了一套私有的二进制双向通信协议，通信框架使用了 Netty。其他四种语言只要依据 Seata 的通信协议标准实现其通信功能，即可在多语言生态体系内任何语言之间进行通信和服务调用。\n三个角色中，TM 和 RM 以 SDK API 形式供上层 APP 调用，而 TC 是独立进程部署，使用任何语言实现都可以。据说懒惰是程序员的第一美德，在 Seata Java 已经实现了 Java 版本的 TC 的情况下，多语言体系内其他语言就没必要再做重复工作，只需要构建其对应语言的 TM 和 RM 的 SDK API 包，与 Seata Java TC 通信即可。\nPART. 2\u0026amp;ndash;Seata 与 PHP 技术 分布式事务技术是微服务技术体系的一环，构建 Seata PHP 首先需要选择其微服务技术平台，seata-php 目前使用的微服务框架是 Hyperf。\nPHP 在业界以入门门槛低著称，目前常用的微服务框架有 Laravel 以及在其上构建的 Lumen。Laravel 框架的最大优点就是其生态丰富，各种组件应有尽有，如果 Laravel 可以和 Spring 框架类比，Lumen 就是 Spring Boot。但其缺点是性能堪忧，例如在普通的 8C 机器上，空跑一个只运行 echo 逻辑的 HTTP 服务，其吞吐量仅有 1K QPS。\nHyperf 框架是近年内出现的由国人基于 Swoole 开发的一个微服务框架，特点如下：\n1. 类似于 Nginx，Hyperf 以多进程形式常驻内存，每个进程内都有一个弹性线程池。正常情况下 Hyperf 收到调用请求后，可以保证 1ms 之内分配服务线程，而 Lumen 的响应时间常在 10ms 左右；\n2. 因为 Hyperf 服务常驻内存的特点，其稳定性好，资源利用率当然比以 CGI 机制运行的 Lumen 低很多；\n3. Hyperf 的对请求的处理过程借鉴了 Go 语言机制，其 runtime 层面以异步方式执行上层的用户同步调用，相比 Lumen 其吞吐率高而延迟低。例如在同样环境下使用 Hyperf 实现同样的 echo HTTP 服务，可以轻松达到 60K QPS；\n除了 Hyperf 自身稳定性与高性能外，依赖于 Hyperf 服务进程常驻内存的特点，TC 可以很方便的对seata-php 的 RM 发起二阶段事务处理，即作为 Server 的 Java TC 对作为 Client 的 PHP 版本的 RM 发起 RPC 回调。如果使用 Lumen 作为 seata-php 的微服务框架，几乎不可能实现这个技术点。\nPART. 3\u0026amp;ndash;快速入门 seata-php 基于 Hyperf 微服务框架，seata-php 已经实现了 AT 事务模式，并给出了测试用例。本章节的目的是基于现有实现，让对 seata-php 这个项目感兴趣的同学能够快速入门 seata-php。\n3.1\u0026amp;ndash;搭建 PHP 开发环境 使用 Hyperf/Box 这个工具能够快速创建开发环境，并且能够与其他自建开发工具链隔离，避免污染日常的开发环境。\n3.1.1 下载 Hyperf/Box # Mac wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_x86_64_macos -O box # Linux x86_64 wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_x86_64_linux -O box # Linux aarch64 wget https://github.com/hyperf/box/releases/download/v0.0.3/box_php8.1_aarch64_linux -O box sudo mv ./box /usr/local/bin/box sudo chmod +x /usr/local/bin/box # 在 https://github.com/settings/tokens/new 创建 token 后，配置到 box 中 box config set github.access-token \u0026amp;lt;Your Token\u0026amp;gt; 注意：\n- 如果你是 Mac 用户首次使用的话，需要在“系统偏好设置”\u0026amp;ndash;\u0026amp;gt;“安全性与隐私”中给 Box 工具进行授权；\n- 已经测试过，X86 的 Box，可以在 M1 版本的 Mac 上使用；\n- 使用 Box 时，创建 GitHub access token 权限需要 repo、workflow。\n3.1.2 配置 PHP 环境 当 Box 下载好后，继续下载 PHP 8.0 版本\n# 下载 php8.0 box get …","date":1660633200,"description":"让 PHPer 也能使用 seata-php 来实现分布式事务","dir":"blog/seata-php-semi-annual-planning/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ee9381666d88165cad305e1b3880d181","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-php-semi-annual-planning/","publishdate":"2022-08-16T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/seata-php-semi-annual-planning/","summary":"文｜ 赵新（花名：于雨)：蚂蚁集团 Seata 项目开源负责人、开放原子开源基金会代码贡献之星 郭成（花名：星北)：Seata-php 项目共同发起人、蚂蚁集","tags":["SOFAStack"],"title":"Seata-php 半年规划","type":"blog","url":"/sofastack.tech/blog/seata-php-semi-annual-planning/","wordcount":4330},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup 合肥站-云原生技术沙龙\n 活动时间：2022 年 08 月 13 日（周六）13:30-17:00\n 活动地点：合肥市高新区创新创业园 D8 栋一楼集思空间\n 活动形式：线下活动\n 资料下载：\n《SOFA Serverless 体系助力业务极速研发》\n《KusionStack 在蚂蚁规模化运维的探索和总结》\n 本次分享涉及的项目地址：\n【SOFAArk】https://github.com/sofastack/sofa-ark\n【KusionStack】https://github.com/kusionstack/kusion\n 活动介绍 活动议程 直播回放 SOFA Serverless 体系助力业务极速研发\nKusionStack 在蚂蚁规模化运维的探索和总结\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1660374000,"description":"SOFA Meetup 合肥站-云原生技术沙龙","dir":"activities/sofa-meetup-17/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"717c5211a439598278a7cbb834d09bb0","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-17/","publishdate":"2022-08-13T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-17/","summary":"概要 活动主题：SOFA Meetup 合肥站-云原生技术沙龙 活动时间：2022 年 08 月 13 日（周六）13:30-17:00 活动地点：合肥市高新区创新创业园 D8 栋","tags":["SOFAMeetup"],"title":"SOFA Meetup 合肥站-云原生技术沙龙","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-17/","wordcount":346},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 信广健 提问：\n 经过十分曲折的故事了解到了 Layotto ， 进群后想看看后续发展，有什么好的文档可以学习下吗？\n A：目前还在活跃开发中，可以看下 https://github.com/mosn/layotto 了解下，相关的文档也在 https://mosn.io/layotto/\n「Layotto」：https://github.com/mosn/layotto\n2. 清源 提问：\n 现在 MOSN 除了适配 XDS 做到动态规则下发之外？有没有其他的动态规则下发办法？\n A：你可以自己实现的，XDS 也是调用 MOSN 的更新 API。\n「MOSN」：https://github.com/mosn/mosn\n3. 樊志超 提问：\n 问一下，MOSN 与业务容器间的信息交互是采用 socket 方式吗？\n A：这个看你怎么用了，自己选择。\n 默认的是哪种方式呢？\n A：TCP、UDS 都可以。\n「MOSN」：https://github.com/mosn/mosn\nSOFARPC 5.8.6 版本发布 SOFARPC 5.8.6 是一个功能优化、Bug 修复版本，建议使用 5.7.10 ~ 5.8.5 版本的用户都升级到 5.8.6。\n主要变更如下：\n- 功能优化：\n1.支持用户自定义 tracer 中 callerAppName\n2.添加 DomainRegistry 订阅域名数据, 支持 direct url 功能\n- BUG 修复：\n1.修复了 Triple 协议在多 classLoader 环境下的序列化问题\n详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.8.6\n本周推荐阅读 蚂蚁开源：开放自研核心基础软件技术，携手探索技术高地\n\nGo 原生插件使用问题全解析\n\nMOSN 反向通道详解\n\n如何看待 Dapr、Layotto 这种多运行时架构\n\n欢迎扫码关注：\n","date":1660287600,"description":"SOFA Weekly | SOFARPC 5.8.6 版本发布、Meetup 合肥站、本周 Contributor \u0026 QA","dir":"blog/sofa-weekly-20220812/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"06f5bddaf802462077c913d20d2f9d15","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220812/","publishdate":"2022-08-12T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220812/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 5.8.6 版本发布、Meetup 合肥站、本周 Contributor \u0026 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220812/","wordcount":861},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup 广州站-云原生技术交流\n 活动时间：2022 年 08 月 06 日（周六）14:00-18:00\n 活动地点：广州市海珠区阅江西路 88 号阿里中心北塔 4F 万松书院\n 活动形式：线下活动\n 资料下载：\n《基于 P2P 的文件和镜像加速系统 Dragonfly》\n《Buildpacks \u0026amp;amp; Argo CD GitOps》\n《KusionStack 实践探秘｜技术、角色与应用场景篇》\n《KubeSphere 在青花瓷的落地实践与展望》\n《Holmes｜Go 应用性能异常诊断定位利器》\n《云原生应用灾备最佳实践》\n 本次分享涉及的项目地址：\n【Dragonfly】https://github.com/dragonflyoss\n【KusionStack】https://github.com/kusionstack/kusion\n【MOSN】https://github.com/mosn/mosn\n 活动介绍 活动议程 直播回放 Dragonfly：基于 P2P 的文件和镜像加速系统\nKusionStack 实践探秘｜技术、角色与应用场景篇\nHolmes｜Go 应用性能异常诊断定位利器\n了解更多技术干货 使用钉钉搜索群号：44858463，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1659769200,"description":"SOFA Meetup 广州站-云原生技术交流","dir":"activities/sofa-meetup-16/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cc936d9167acee9569070c076ab0da31","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-16/","publishdate":"2022-08-06T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-meetup-16/","summary":"概要 活动主题：SOFA Meetup 广州站-云原生技术交流 活动时间：2022 年 08 月 06 日（周六）14:00-18:00 活动地点：广州市海珠区阅江西路 88 号阿","tags":["SOFAMeetup"],"title":"SOFA Meetup 广州站-云原生技术交流","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-16/","wordcount":504},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 吴宇奇 提问：\n 请问下，Bolt 协议里面的这个 cmdCode，除了心跳、request、response，还有别的用法吗？ A：举个例子，新增 goaway 扩展。https://github.com/sofastack/sofa-bolt/issues/278\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\n2. bobtthp 提问：\n 大佬们问下动态路由这块，有 example 可以看看嘛？ A：这篇文章就是例子哟，https://mosn.io/blog/posts/how-use-dynamic-metadata/#%E5%8A%A8%E6%80%81%E8%B7%AF%E7%94%B1-cluster ，原理就是 route 的配置是变量，然后 streamfilter 根据业务逻辑修改这个变量的值，很方便试试。\n 好的，这个我有一个疑问。这个变量如何注入进去呢？我理解应该每一个节点的变量都不一样嘛？还有一个疑问是，如果需要和配置中心交互这块是怎么做的，可以借鉴一下吗？\n A：变量就是 streamfilter 模块分配的，然后他来设置这个变量的值，值就是 cluster 的名字；后面那个问题指的是 cluster host 的更新吗？\n 指的是如果需要外部的配置中心那可能需要监听配置的动态变化；第一个这块我好像没理解好，我举个例子：如果是多个应用，那是不是我要设置多个变量？\n A：比如你 A 应用的 cluster 名字是 A，B 应用的 cluster 名字是 B， 那么这个变量只需要一个，只是 value 你可以根据逻辑设置为 A 或者 B。\n这个就是一些复杂的路由场景，用配置不能表达，就可以用代码的方式来做这个事。我们内部的一些复杂路由场景也是这样做的。\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 云原生 Meetup 广州站，等你来！\n\nGo 原生插件使用问题全解析\n\nMOSN 反向通道详解\n\nKusionStack｜Kusion 模型库和工具链的探索实践\n\n欢迎扫码关注公众号：\n","date":1659682800,"description":"SOFA Weekly | Meetup 广州站参会指南、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220805/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"51544dab85fa7fe78001737602f2536b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220805/","publishdate":"2022-08-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220805/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Meetup 广州站参会指南、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220805/","wordcount":1038},{"author":null,"categories":"SOFAStack","content":" 文｜郑泽超（GitHub ID：CodingSinger )\n字节跳动高级工程师\n热衷于微服务和 ServiceMesh 开源社区\n本文 6802 字，阅读 15 分钟\nPart.1\u0026amp;ndash;贡献者前言 说起来非常的抓马，当时和 MOSN 的相遇是在给于雨负责的开源项目 Dubbo-go 贡献代码那阵。在自己顺利当上了 Dubbo 开源社区的 Committer 之后，心想着能更深入的学习 Golang 语言，机缘巧合之下碰到了 MOSN 的老大哥烈元 （也是元总领我进了 MOSN 社区的大门） 。\n作为一款目标对齐 Envoy 的高性能可扩展安全网络代理，MOSN 支持的生态能力更贴近国内互联网公司的技术栈，并且对新功能的响应也很迅速。其次 MOSN 有着很多值得借鉴的巧妙设计和进阶的使用技巧，能充分满足自己在工作之外深入学习 Golang 语言的诉求。\n目前，我在社区里陆续参与了 EDF Scheduler、LAR、WRR 负载均衡、DSL 路由能力、UDS Listener、Plugin 模式的 Filter 扩展以及反向通道等一些比较大的 feature 能力建设。再次感谢雨哥、元总、鹏总、毅松等社区内一众大佬们帮我考究方案并且帮我 Review 代码。\n本文主要介绍之前新合入 master 分支的「反向通道」的使用场景和设计原理，欢迎大家留言探讨。\nMOSN 项目概述 MOSN（Modular Open Smart Network）是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并经过双 11 大促几十万容器的生产级验证，具备高性能、易扩展的特点。MOSN 可以和 Istio 集成构建 Service Mesh，也可以作为独立的四、七层负载均衡、API Gateway、云原生 Ingress 等使用。\nPart.2\u0026amp;ndash;MOSN 的反向通道实现 在云边协同的网络场景，通常都是单向网络，云侧节点无法主动发起连接与边缘节点通讯。这种限制虽然在极大程度上保证了边缘节点的安全，但缺点也很明显，即只允许边缘节点主动发起访问云端节点。\n云边隧道旨在解决云端无法主动访问边缘节点的问题，其本质是一个反向通道 （后文统称为反向通道） 。通过在边缘侧主动发起建连的方式与云端节点之间构建一条专用的全双工连接，用来传输云端节点的请求数据和回传最终的响应结果。\n目前例如 SuperEdge、Yurttunnel 等业界知名云边协同开源框架，对于云边通信的实现方案都是基于反向通道。\n本文将着重介绍 MOSN 之上的反向通道运作流程和原理。总体架构如下所示 (图中箭头表示 TCP 建连反向) ：\n整个运作流程可以简单概括为：\n1. 边缘侧的 MOSN 实例 （后文统称为 Tunnel Agent） 在启动时 Tunnel Agent 相关服务协程。\n2. 通过指定的静态配置或者动态服务发现方式拿到需要反向建连的公有云侧的 MOSN Server 地址列表 （后文统称 Tunnel Server ） ，并且建立反向连接。\n3. 云侧的 Frontend 与 Tunnel Server 侧的转发端口进行数据交互，这部分数据会被托管到之前建立的反向连接进行发送。\n4. 边缘节点接受到请求之后，再将请求转发给实际的后端目标节点，回包过程则远路返回。\nPart.3\u0026amp;ndash;反向通道启动过程 MOSN Agent 通过 ExtendConfig 特性，在 MOSN 启动时加载和完成初始化 Tunnel Agent 的工作。\nExtendConfig 中定义 AgentBootstrapConfig 结构如下：\ntype AgentBootstrapConfig struct { Enable bool `json:\u0026amp;quot;enable\u0026amp;quot;` // The number of connections established between the agent and each server ConnectionNum int `json:\u0026amp;quot;connection_num\u0026amp;quot;` // The cluster of remote server Cluster string `json:\u0026amp;quot;cluster\u0026amp;quot;` // After the connection is established, the data transmission is processed by this listener HostingListener string `json:\u0026amp;quot;hosting_listener\u0026amp;quot;` // Static remote server list StaticServerList []string `json:\u0026amp;quot;server_list\u0026amp;quot;` // DynamicServerListConfig is used to specify dynamic server configuration DynamicServerListConfig struct { DynamicServerLister string `json:\u0026amp;quot;dynamic_server_lister\u0026amp;quot;` } // ConnectRetryTimes ConnectRetryTimes int `json:\u0026amp;quot;connect_retry_times\u0026amp;quot;` // ReconnectBaseDuration ReconnectBaseDurationMs int `json:\u0026amp;quot;reconnect_base_duration_ms\u0026amp;quot;` // ConnectTimeoutDurationMs specifies the timeout for establishing a connection and initializing the agent ConnectTimeoutDurationMs int `json:\u0026amp;quot;connect_timeout_duration_ms\u0026amp;quot;` CredentialPolicy string `json:\u0026amp;quot;credential_policy\u0026amp;quot;` // GracefulCloseMaxWaitDurationMs specifies the maximum waiting time to close conn gracefully GracefulCloseMaxWaitDurationMs int `json:\u0026amp;quot;graceful_close_max_wait_duration_ms\u0026amp;quot;` TLSContext *v2.TLSConfig `json:\u0026amp;quot;tls_context\u0026amp;quot;` } - ConnectionNum：Tunnel Agent 和每个 Tunnel Server 建立的物理连接数量。\n- HostingListener：指定 Agent 建立连接之后托管的 MOSN …","date":1659423600,"description":"本文主要介绍之前新合入 master 分支的「反向通道」的使用场景和设计原理，欢迎大家留言探讨。","dir":"blog/mosn-reverse-channel-explained/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7e5e0314310caad88df4a18ccf8bb436","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-reverse-channel-explained/","publishdate":"2022-08-02T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-reverse-channel-explained/","summary":"文｜郑泽超（GitHub ID：CodingSinger ) 字节跳动高级工程师 热衷于微服务和 ServiceMesh 开源社区 本文 6802 字，阅读 15 分钟 Part.1\u0026ndas","tags":["SOFAStack"],"title":"MOSN 反向通道详解","type":"blog","url":"/sofastack.tech/blog/mosn-reverse-channel-explained/","wordcount":3101},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. bobtthp 提问：\n 请教下 MOSN 转发 HTTP/2 协议，listener filter 和 router match 两个部分要怎么写呀？\n A：就用这个 exmple 就行了。\nhttps://github.com/mosn/mosn/blob/master/configs/mosn_config_dev.json\n「MOSN」：https://github.com/mosn/mosn\n2. 黄大宇 提问：\n Biz 版本更新时，如果不卸载旧版本，安装新版本时会报 webContextPath 冲突异常。比如现在运行 1.0.0，而我要升级到 2.0.0，那么能否先安装 2.0.0，然后再切换，再把 1.0.0 卸载。目前是这一过程出现了 webContextPath 冲突的问题。\n A：有两种解法，一种是让流量走宿主，然后分发给 Biz。另一种是 context path 挂钩版本，调用时带上版本，类似 v1，v2 这样。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n3. 黄润良 提问：\n Cluster Manager 这块配置，如果要实现动态配置，有没有什么最佳实践之类的？MOSN 有开放 API 或者接入配置中心的案例吗？\n A：直接使用 XDS 协议就行了，获取你也可以直接调用 MOSN 的 API，这里有个 ZK 的例子：\nhttps://github.com/mosn/mosn/tree/master/pkg/upstream/servicediscovery/dubbod\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 Go 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\nSOFAServerless 助力业务极速研发\n\nSeata 在蚂蚁国际银行业务落地实践\n\n欢迎扫码关注公众号：\n","date":1659078000,"description":"SOFA Weekly | Meetup 广州站、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220729/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"876d0f78f149dc93f464e53e5474a250","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220729/","publishdate":"2022-07-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220729/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | Meetup 广州站、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220729/","wordcount":760},{"author":null,"categories":"SOFAStack","content":" 文｜杨洋（花名：凯申 )\n铜锁开源密码库创始人、蚂蚁集团高级技术专家\n本文 2816 字，阅读 8 分钟\n再见 BabaSSL ，你好 Tongsuo!\n BabaSSL 这个名字由于其历史上的若干特殊原因，导致了其看起来是主要 SSL/TLS 协议的密码学产品，这其实并不符合整个产品的功能特性，名字本身也不够中立，这会让用户产生一定程度的误解。\n目前 BabaSSL 在积极推进向开放原子开源基金会的捐赠行动，并结合社区未来发展的方向，现决定对 BabaSSL 项目进行更名。新名字需要更加中立化，而且需要体现项目的功能特性。基于这些考虑，计划取新名字为：铜锁，对应拉丁字母名称为铜锁的汉语拼音“Tongsuo”。铜锁是在中华文明 5000 年历史的进程中得到了广泛应用的安全设施，且小巧、设计精妙，极具中国传统特色，符合密码库的产品特色和发展目标。\n 一、BabaSSL 从何而来，为何而改？ BabaSSL 于 2019 年诞生在蚂蚁和阿里集团内部，是基于 OpenSSL 1.1.1 版本 fork 而来的一个变种版本。创建 BabaSSL 项目的动机是在蚂蚁和阿里内部得到一个统一的 OpenSSL 变种版本，以便使用此统一版本来支撑蚂蚁和阿里内部的各种业务。这样可以减小各个业务方维护 OpenSSL 的成本，实现密码学能力的统一管理和维护，进而降低潜在的安全风险。\n针对蚂蚁和阿里内部的业务特点，BabaSSL 需要采用和 OpenSSL 完全不同的发展路线。简单来说，BabaSSL 需要覆盖的场景非常的多样化，包括移动端、服务器端、资源受限的嵌入式环境等。而且在算法和密码学特性的支持上，蚂蚁和阿里的业务对前沿的技术存在较大需求，因此要求 BabaSSL 需要采用相对激进的演进策略，但还要确保很高的质量标准以应对蚂蚁和阿里的业务规模。所以我们当年使用 Brisk and Better Assured Cryptography and SSL/TLS toolkit 来命名这个密码学基础库，并缩写为 BabaSSL。\n随着 BabaSSL 项目的发展，我们发现除了蚂蚁和阿里内部的业务对其有着重大的依赖之外，业界也对国密合规和前沿密码学技术存在较大需求。因此在 2020 年 10 月份，我们将 BabaSSL 进行了开源，并维持 BabaSSL 名称不变。随着 BabaSSL 开源社区的发展、用户数量的增多，我们逐渐发现 BabaSSL 这个名称已经无法继续肩负整个社区更大的目标和使命，因此取一个新名字就十分必要。\n二、我的新名字——\u0026amp;rdquo;铜锁/Tongsuo\u0026amp;rdquo; 经过与开源社区小伙伴们共同探讨，并与开放原子开源基金会沟通后，我们最终选定了 “铜锁/Tongsuo” 作为 BabaSSL 开源项目的新名字，其含义如下：\n1. 铜锁的设计形象和密码学的锁形象异曲同工，都是保障安全的技术\n2. 铜锁的历史悠久，应用十分广泛\n3. 铜锁诞生于中国汉代，流行至明清，极具中国特色，代表了中国的传统文化\n4. 铜锁设计精妙、体积小巧，安全性高\n铜锁的这些特点，符合 BabaSSL 的项目定位和发展目标：适应场景最广、性能最好、可靠性最高且监管合规的开源密码学基础库。正如铜锁是中国 5000 年历史长河中为人民生命财产提供保证的最基础元素，“铜锁密码库”作为信息安全领域基础组件、中国网络空间安全和数据安全的核心基础元素，也希望能为中国人民的信息和财产安全贡献力量。\n铜锁的拉丁字母名称则直接采用铜锁的汉语拼音：Tongsuo，除此之外不再赋予其他含义解释，目的是集中体现中国的品牌名称和文化价值。\n三、更名后的一系列操作 我们近期会针对 BabaSSL 开源项目进行如下的更名举措，其中部分举措可能会对用户造成影响，需额外注意：\n「代码库名称变更」\n1. 在 Github 上创建新的 Tongsuo 组织，并将 BabaSSL 代码仓库更名为 Tongsuo 后迁移其下；\n2. BabaSSL 代码仓库的转地址会在 Github 上自动跳转到新的 Tongsuo 仓库地址，方便已有用户访问；\n3. 新的 Tongsuo 代码仓库的 master 分支变更为基于 OpenSSL 3.0 代码基础，并整体迁移为 Apache License 2.0 开源许可证。由此进行相关分支变更如下：\na. 现有的 master 分支更名为 master-babassl，并设置为只读模式，即不再接受新的代码合并，只留做参考用；\nb. 将 master-tongsuo 分支更名为 master，作为下个大版本 tongsuo-8.4.0 的开发分支。由于新的 master 分支和旧的 master 分支之间没有代码提交的逻辑关系，因此需要用户手动重新检出新的master 分支并覆盖本地的旧 master 分支内容。在此过程中如果你的本地 master 分支存在代码修改，请注意保存以免代码修改丢失。\n「网站改名」\n1. 启动 tongsuo.net 网站，并更新网站内容/品牌；\n2. 将对 babassl.cn 网站的访问重定向到 tongsuo.net；\n3. 新增 tongsuo.readthedocs.org 网站，作为铜锁项目的文档库。\n「Release 改名和版本策略」\n1. 在 8.3.x 版本中将沿用 BabaSSL 名称，即 BabaSSL 8.3.1 等后续版本；\n2. 从 8.4.0 开始更名为 Tongsuo。Tongsuo 延续 BabaSSL 的版本编号，不再重新定义编号。主要是考虑软件版本的升级和比较的前后兼容性问题。新的 release 包名称为：tongsuo-a.b.c.tar.gz 或 tongsuo-a.b.c.zip。\n「代码 API 命名修改」\n需要考虑兼容问题，因此 BABASSL_ 开头的 API 还需持续保留，直到 9.0 大版本发布。\n四、期待与你共“铜”成长 经过这一年的努力，铜锁/Tongsuo 开源密码库项目通过了开放原子开源基金会的 TOC 答辩。接下来我们的重心是继续推进铜锁 8.4.0 版本的研发工作，该版本会在半同态加密算法等前沿密码学领域进行相关特性的大力支持，为铜锁的用户带来隐私计算领域的底层密码学原语能力。\n希望能有更多朋友参与进来，与我们共同去完善铜锁/Tongsuo，不论你所处哪一个研究领域，我们都非常期待和欢迎你的加入。此外，我们于近期建立了铜锁 （BabaSSL） 的开源项目钉钉群，方便铜锁密码库的用户们进行沟通交流，期待着能有更多的社区朋友在铜锁 （BabaSSL） 共同成长！\n钉钉用户交流群群号：44810299\n 铜锁（BabaSSL）的更名涉及到较多的现有资产名称变更事宜，例如代码库改名、文档内容名称替换等。具体的相关进展和状态，我们会及时在上述钉钉群中向大家通告。\n 了解更多…\n铜锁/Tongsuo Star 一下✨： https://github.com/BabaSSL/BabaSSL\n本周推荐阅读 BabaSSL：支持半同态加密算法 EC-ElGamal\n\nBabaSSL 发布 8.3.0｜ …","date":1659078000,"description":"再见 BabaSSL ，你好 Tongsuo!","dir":"blog/my-new-name-is-tongsuo/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b06ddb637930e9c54104c4e1f05501d7","permalink":"https://sofastack.github.io/sofastack.tech/blog/my-new-name-is-tongsuo/","publishdate":"2022-07-29T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/my-new-name-is-tongsuo/","summary":"文｜杨洋（花名：凯申 ) 铜锁开源密码库创始人、蚂蚁集团高级技术专家 本文 2816 字，阅读 8 分钟 再见 BabaSSL ，你好 Tongsuo! BabaSSL 这个名字由于其历史上的若干特殊原因，导致","tags":["SOFAStack"],"title":"你好，我的新名字叫“铜锁/Tongsuo”","type":"blog","url":"/sofastack.tech/blog/my-new-name-is-tongsuo/","wordcount":2336},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#29:基于 P2P 的文件和镜像加速系统 Dragonfly\n 活动时间：07 月 28 日，周四晚 19 点\n 活动形式：线上直播\n 直播回放：点击观看\n 资料下载：戳这里\n 推荐阅读：Dragonfly\u0026amp;ndash;基于 P2P 的文件和镜像分发系统\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”等多种形式期待你的参与！\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#29 基于 P2P 的文件和镜像加速系统 Dragonfly Dragonfly 是一款基于 P2P 的智能镜像和文件分发工具。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在应用分发、缓存分发、日志分发和镜像分发等领域被大规模使用。自 17 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 18 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF 沙箱级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为孵化级别的托管项目。分享主要介绍 Dragonfly 项目，并与大家共同分享开发过程中的设计思想以及最佳实践。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 戚文博（花名：百蓦）\n Dragonfly Maintainer\n 基于 P2P 的文件以及镜像加速系统, 负责 Scheduler 以及 Manager 子模块\n 马金晶（花名：楚贤）\n Dragonfly Maintainer\n 基于 P2P 的文件以及镜像加速系统, 负责 Dfdaemon 子模块\n 议程 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1658818800,"description":"2022 年 7 月 26 日 19：00 - 20：00 ，线上直播第 29 期。","dir":"activities/sofa-channel-29/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d3727242c6f0f12aead78985904e20bb","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-29/","publishdate":"2022-07-26T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-29/","summary":"概要 活动主题：SOFAChannel#29:基于 P2P 的文件和镜像加速系统 Dragonfly 活动时间：07 月 28 日，周四晚 19 点 活动形式：线上直播 直播回放：点击观看","tags":["SOFAChannel","Dragonfly","文件和镜像加速系统"],"title":"SOFAChannel#29 基于 P2P 的文件和镜像加速系统 Dragonfly","type":"activities","url":"/sofastack.tech/activities/sofa-channel-29/","wordcount":623},{"author":null,"categories":"SOFAStack","content":" 文｜李乔（花名：南桥)、李宗杰（花名：白鹰)\n李乔：蚂蚁集团高级开发工程师，负责蚂蚁境外银行支付结算系统开发\n李宗杰：蚂蚁集团技术专家，负责蚂蚁分布式事务中间件研发\n本文 11580 字 阅读 25 分钟\nPART. 1\u0026amp;ndash;背景 蚂蚁国际境外银行业务正在部分迁移至阿里云，原内部使用的 SOFA 技术栈无法在阿里云上得到支持。为了满足银行业务快速发展、简化银行系统技术栈的目标，我们采用了 Spring+Dubbo 等一套开源的技术方案重新构建起了新的技术栈。蚂蚁集团作为金融机构，内部应用采用了微服务架构，数据间的一致性极其重要，但蚂蚁内部原有的分布式事务框架，在阿里云上也无法提供技术支持。\nSeata 是分布式事务解决方案，囊括了阿里集团的 TXC （阿里云版本称为 GTS） 和蚂蚁集团的 TCC/SAGA 等多种模式，是一款经过多年双十一大规模流量验证的金融级分布式事务框架。因此在综合比较各个现有的分布式事务框架之后，我们选择了 Seata。\n本文介绍了蚂蚁集团境外银行技术部在国际站点建设过程中，使用开源的 Seata 1.4.2 版本进行分布式事务管理的详细方案。同时本文也介绍如何在客户端实现对事务悬挂、幂等、空提交以及空回滚等情形的处理方法。\nPART. 2\u0026amp;ndash;调研 Seata 经过四年建设后，已经形成了一个非常庞大的技术体系。但不管其如何演进，Seata 整体保持了架构的稳定性与使用接口的向后兼容性。\n2.1\u0026amp;ndash;Seata 架构 Seata 官网给出了其如下架构图：\n总体由如下角色构成：\n●TC: Transaction Coordinator\n事务协调器：维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n●TM: Transaction Manager\n事务管理器：定义全局事务的范围，提交或者回滚全局事务。\n●RM：Resource Manager\n资源管理器：和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\nTC 与 TM 以及各个 RM 之间使用 netty 框架进行长链接通信，通信协议是在四层 TCP 协议之上自定义的一套二进制双向通信协议，所以 Seata 总体的通信效率非常高。\n2.2\u0026amp;ndash;事务模式 在这套架构之上，Seata 提供了 TCC、AT、SAGA 和 XA 四种事务模式：\nTCC 模式\n参与者需要实现 Prepare/Commit/Rollback 接口，在一阶段实现数据资源的预处理，在二阶段实现提交和回滚逻辑完成两阶段的提交。优点是通过业务逻辑实现数据可见性和隔离性，快速释放本地事务，提高对同一个资源的并发度，缺点是引入了中间数据的预处理过程，增加了业务复杂度。因此 TCC 模式具有很好的性能与隔离性，尤其适合在银行金融场景下同一个账户的并发交易处理。\nAT 模式\n在一阶段时通过解析 SQL，生成二阶段回滚日志：二阶段提交时，删除回滚日志；二阶段回滚时，通过回滚日志来恢复记录到一阶段之前的状态。类似于 TCC 的两阶段，不过二阶段的 Commit/Rollback 由框架自动生成，自动实现了二阶段操作，易用性好于 TCC。但 AT 模式通过全局锁来实现数据的隔离性，因此对于同一个资源的事务处理只能串行操作，所以性能逊于 TCC。当然如果不存在并发使用同一个资源的场景，则 AT 模式可以很好的兼顾性能和隔离性，以及更好的开发效率。\nSAGA 模式\n是一种长事务解决方案，其一阶段正向服务和二阶段补偿服务都由业务开发实现，它在微服务编排领域有大量应用。但其数据隔离性不好，业务数据有被脏写的风险。\nXA 模式\n其使用接口与 AT 模式一致，提供了最严格的隔离性，可以保证了用户不会出现脏读。XA 模式的缺点是其事务范围较长，其性能较低。\n2.3\u0026amp;ndash;小结 Seata 四种模式都是二阶段事务的技术实现。结合 Seata 自身的技术架构，其事务模型总体有如下特点：\nPART. 3\u0026amp;ndash;实践 进行总体技术调研后，我们认为 Seata 的总体技术栈可以满足我们所有金融业务场景的需求。在实施过程中，在不同的业务场景下根据不同的技术需求进行了取舍，我们在发起者本地的交易流水部分使用了 AT 模式，在下游账户相关的服务中使用了 TCC 模式。本章接下来我们将以业务中最经典的账务余额模型为例详述本次实践，包括为了适配相应的事务模型所做的工作。\n3.1\u0026amp;ndash;交易流水使用 AT 模式 为了记录每次的交易流水状态，在发起每笔交易前，我们都要将本次交易流水做记录，交易状态流水简化模型如下：\n在接收到请求时，首先记录初始化状态的交易流水，然后发起分布式事务。本次交易的分布式事务执行成功后，预期该笔交易流水需要是执行成功状态。为了对失败的交易发起重试，我们启动了一个定时任务，定时扫描交易流水状态，扫描到一定时间后未完成的记录需要重新发起重试。\n从上面的场景可以看出，在发起者的交易流水记录的状态变更中，也需要参与到整个分布式事务中。分布式事务成功，则流水状态需要更新为成功，如果分布式事务失败，则需要更新为失败。同时交易流水记录之间是独立的，不存在并发操作的可能，只有异步任务的扫描才会和交易中的事务做抢锁处理。\n针对这个场景，就非常适合使用 AT 模式，无需通过业务代码记录事务执行状态，而是直接在发起者中通过 AT 模式提供的代理数据源执行修改流水状态为“执行成功”状态，由框架自动完成 AT 模式下的一二阶段的提交和回滚，保证交易流水状态和整体分布式事务的状态一致，同时可以保持简洁的代码和更高的开发效率。\n3.2\u0026amp;ndash;账户使用 TCC 模式 从业务原理上来分析，账户的余额是不能凭空增加或者减少的，每个余额变动必须有明细对应。所以账户余额模型应该具备以下几个关键要素：账户 （明确到底是谁的账户）、 余额 （承载的客户资产具体数值）、 账务明细 （记载账户余额变动的数值、时间和原因） 。这三个其实构成了最朴素的账户余额模型。\n根据从业务原理的分析，我们就产生了一个最简单的账户余额基础数据模型：\n账户（ip_account）\n账户模型确定了基本的账户信息：\n●账号：该账号与会员的信息映射在一起，作为会员的余额资产；\n●账户类型：对公 （商户账号） ，对私 （个人账号） ，平台户、营销户、商户待结算账户等类型；\n●余额：记录当前客户资产具体数据的余额；\n●交易状态：控制四种交易方式：流入、流出、充值、提现，这是在账务层做的一个资金安全兜底保障。每一种类型用 T/F 来表示是否可以进行此类交易，T 是可以，F 是不可以 ；\n●核算主体：用于表示当前账号在那个核算主体下面进行核算。\n账户明细（ip_account_log,ip_trans_log）\nip_trans_log 是指账户的交易明细，用于解释为什么这个账户是要发生这笔记账请求。可以理解为业务原始凭证，用于和业务系统数据关联校验。以你用支付宝在便利店买了一瓶矿泉水为例，就是记录的这花 2 元买水的原始信息。\nip_account_log 是指账务明细，用于解释这个账户到底扣减了多少钱，记账的对方账户是谁。仍然以你用支付宝在便利店 …","date":1658818800,"description":"蚂蚁国际境外银行业务正在部分迁移至阿里云，原内部使用的 SOFA 技术栈无法在阿里云上得到支持。为了满足银行业务快速发展、简化银行系统技术栈的目标，我们采用了 Spring+Dubbo 等一套开源的技术方案重新构建起了新的技术栈。","dir":"blog/seata-in-practice-in-ant-international-banking/","fuzzywordcount":9000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8c90a02142b9bb70cfc93d7828e502ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","publishdate":"2022-07-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","summary":"文｜李乔（花名：南桥)、李宗杰（花名：白鹰) 李乔：蚂蚁集团高级开发工程师，负责蚂蚁境外银行支付结算系统开发 李宗杰：蚂蚁集团技术专家，负责蚂蚁","tags":["SOFAStack"],"title":"Seata 在蚂蚁国际银行业务的落地实践","type":"blog","url":"/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/","wordcount":8943},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 罗坤 提问：\n 您好，请问一下可以用 SOFATracer 的摘要日志是 result.code 判断交易是否成功来告警么？result.code 有哪些状态？\n A：是可以的，如果是监控，可以用 stat 日志。\n「SOFATracer」： https://github.com/sofastack/sofa-tracer\n2. xiaoyu 提问：\n 咨询一个问题，现在使用 MOSN 作为 Istio 数据面，还是只能使用 Istio 1.10.6 版本吗？\n A：是的，目前支持的这个版本。\n「MOSN」： https://github.com/mosn/mosn\n3. 高岩 提问：\n 请教下， MOSN 官网的集成 Istio 的例子，在 Katacoda 上练习 step 4 的测试 curl productpage 时失败，然后在我本地 Minikube 的环境测试结果也一样，请问下这个 demo 问题怎么排查？\n A：我试了一下，这个 Katacode 上执行 grep 会报错，但是不执行就没问题。\n 好的，我再试一下，感谢。\n A：如果遇到问题，可以看一下 MOSN 的日志。kubectl logs $pod -c istio-proxy 就可以了，还有问题可以建个 issue。\n「MOSN」：https://github.com/mosn/mosn\n本周推荐阅读 Kusion 模型库和工具链的探索实践\n\nSeata 多语言体系建设\n\nGo 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\n欢迎扫码关注：\n","date":1658473200,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220722/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"077f31118a42474e52018a9f6b870b4f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220722/","publishdate":"2022-07-22T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220722/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220722/","wordcount":675},{"author":"梁倍宁","categories":"SOFAStack","content":" 前言 SOFABoot的isle模块为Spring Boot应用提供了上下文隔离的能力以更好的支持模块化开发。借助该能力，可以很好的解决不同模块中的Bean冲突问题，有效的提高了团队协作开发的效率，尽可能的避免因冲突带来的额外时间成本\n SOFABoot的模块隔离能力，也叫做Spring上下文隔离能力，相较于类加载器隔离的实现方式，Spring上下文隔离的实现更为简单。SOFA给每一个模块都提供了一个独立的Spring上下文，这样各模块之间的Bean就无法直接引用，直接引用时通常会出现NoSuchBeanDefinitionException表示当前容器没有指定的Bean，以达到各模块在运行时隔离的效果。\n模块化启动相关类 类名 描述 com.alipay.sofa.isle.stage.PipelineStage 该接口是PipelineContext中一个步骤的描述，SOFA将启动行为抽象成了一条流水线中的各个步骤 com.alipay.sofa.isle.stage.ModelCreatingStage 该类是PipelineStage实现之一，其主要作用是创建模块 com.alipay.sofa.isle.stage.SpringContextInstallStage 该类是PipelineStage实现之一，其主要作用是将SOFA定义的“模块”安装到Spring的上下文中，也是SOFA模块化中最关键的一个步骤 com.alipay.sofa.isle.stage.ModuleLogOutputStage 该类是PipelineStage实现之一，其主要作用只是模块化的相关日志 com.alipay.sofa.isle.spring.SofaModuleContextLifecycle 该类是SOFA模块化核心实现的入口类，实现了SmartLifecycle接口，会在Spring发布ContextRefreshed事件之前调用 主体流程 SofaModuleContextLifecycle SOFABoot的模块化能力主要是基于Spring的Lifecycle来实现的，核心的入口类为com.alipay.sofa.isle.spring.SofaModuleContextLifecycle，该类实现了Spring的org.springframework.context.SmartLifecycle接口，会在ContextRefreshedEvent事件发布之前调用。当Spring的上下文刷新时会触发SOFA模块化的装配流程，其源码如下：\npublic void start() { if (isleRefreshed.compareAndSet(false, true)) { try { pipelineContext.process(); } catch (Throwable t) { SofaLogger.error(ErrorCode.convert(\u0026amp;quot;01-10000\u0026amp;quot;), t); throw new RuntimeException(t); } } } 检查当前状态是否是已经调用，如已调用则直接返回。 如果是Root上下文，则直接调用PipelineContext的process，该调用会顺序执行模块化流水线上的各个步骤ModelCreatingStage、SpringContextInstallStage、ModuleLogOutputStage 接下来我们逐个解析PipelineStage的行为。\nModelCreatingStage 顾名思义模型构造阶段，该阶段会对应用程序构造一个应用模型，用以描述应用的基本属性以及所拥有的模块。ModelCreatingStage的process源码码如下：\nprotected void doProcess() throws Exception { ApplicationRuntimeModel application = new ApplicationRuntimeModel(); application.setAppName(appName); SofaRuntimeManager sofaRuntimeManager = applicationContext .getBean(SofaRuntimeManager.class); application.setSofaRuntimeContext(sofaRuntimeManager.getSofaRuntimeContext()); application.setModuleDeploymentValidator(new DefaultModuleDeploymentValidator()); getAllDeployments(application); applicationContext.getBeanFactory().registerSingleton(SofaBootConstants.APPLICATION, application); } 为应用构造运行时模型ApplicationRuntimeModel\n 为ApplicationRuntimeModel设置应用名，即环境变量中的spring.application.name对应的值\n 为应用模型设置SOFA运行时上下文\n 读取所有的Deployment并装载到ApplicationRuntimeModel中\n 将该ApplicationRuntimeModel注册到应用程序的Root Spring上下文中\n 这里详细说明一下第3步中是如何加载Deployment的，以下是getAllDeployments的代码:\nprotected void getAllDeployments(ApplicationRuntimeModel application) throws IOException, DeploymentException { Enumeration\u0026amp;lt;URL\u0026amp;gt; urls = appClassLoader.getResources(SofaBootConstants.SOFA_MODULE_FILE); if (urls == null || !urls.hasMoreElements()) { return; } while (urls.hasMoreElements()) { URL url = urls.nextElement(); UrlResource urlResource = new UrlResource(url); Properties props = new Properties(); props.load(urlResource.getInputStream()); DeploymentDescriptorConfiguration deploymentDescriptorConfiguration = new DeploymentDescriptorConfiguration( …","date":1658473200,"description":"源码解析｜SOFABoot 上下文隔离机制解析","dir":"projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e980cc3e12470d9a9f803973bb5c1a48","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","publishdate":"2022-07-22T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","summary":"前言 SOFABoot的isle模块为Spring Boot应用提供了上下文隔离的能力以更好的支持模块化开发。借助该能力，可以很好的解决不同模块","tags":["“源码解析”"],"title":"源码解析｜SOFABoot 上下文隔离机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/","wordcount":5953},{"author":null,"categories":"SOFAStack","content":" 文｜杨英明（花名：向野)\nKusionStack 核心贡献者、蚂蚁集团高级研发工程师\n在基础设施技术领域深耕，专注 IaC/XaC、GitOps 等方向\n本文 4912 字 阅读 12 分钟\n前言 KusionStack 最早是为了解决蚂蚁内部复杂的运维场景而诞生的解决方案。思路是通过自研的 DSL （KCL） 沉淀运维模型 （Kusion Model） ，将基础设施部分能力的使用方式从白屏转为代码化，同时结合 DevOps 工具链 （Kusion CLI） 实现配置快速验证和生效，以此提升基础设施的开放性和运维效率。\n其中，Kusion Model 就是题中所说的 Kusion 模型库，而 Kusion CLI 就是 Kusion 工具链了。具体概念如下：\nKusion 模型库 Kusion 模型库是基于 KCL 抽象的配置模型。它的特点包括了开箱即用、用户友好、以及业务抽象。其实模型库最初朴素的出发点就是改善 YAML 用户的编写效率和体验，因为目前其实有不少配置是基于 YAML 描述的，比如 Kubernetes 在成为容器编排的事实标准之后，基于 K8s 的声明式配置就越来越多了起来。\n但是由于 K8s 本身的复杂性导致 YAML 配置越来越冗长、复杂。我们希望通过将复杂的配置描述通过 KCL 这门配置语言抽象封装到统一的模型中，从而简化用户侧配置代码的编写。\nKusion 工具链 Kusion 工具链是基于 KCL 的 DevOps 工具集合，它是用来辅助用户在 Kusion 生态里更好的生成、驱动他们的 KCL 配置。\n简单来说，Kusion 模型库是用 KCL 语言沉淀下来的可复用组件，工具链是 Kusion 模型的驱动器。\n本文主要介绍 KusionStack 中 Kusion 模型库和工具链在蚂蚁内部的实践探索和总结，重点阐述了如何利用 KusionStack 提升复杂基础设施的开放性和运维效率，希望对同样面临此类困境的伙伴有所启示。\nPART. 1\u0026amp;ndash;为什么要做 Kusion 模型库和工具链？ 我们可以先来看一张“现象\u0026amp;ndash;问题”图：\n在这张图中，我们列出了一些在内部大规模场景下的实践过程中会遇到的问题。\n举个应用部署的例子，应用 A 有 10+ 组件，内部对于这种非标应用没有提供很好的支持，每次部署需要经历繁多的步骤，比如元数据准备、申请证书、VIP、域名、手动部署 CRD、RBAC、Webhook、监控配置等。这个过程没有自动化，交付部署复杂，定制程度高，其中任何一个步骤出现问题，都需要找对应的研发同学沟通，应用部署的人工成本很高。\n总体来说，当时蚂蚁内部在大规模场景下利用现有基础设施进行运维的困境，主要就是来源于以上列出的这些现象，所以去解决这些现象背后的问题，成了亟待我们去做的事情。\nPART. 2\u0026amp;ndash;困境中的应对思路 经过反复的探讨和一致认同，我们最终摸索出一套解决方案，即通过 Kusion 模型库和工具链，从以下几个方面解决上述复杂基础设施运维困境的问题。\n可读性 面向业务 \u0026amp;amp; 屏蔽底层实现\n我们基于 KCL 抽象了 Kusion 模型库，其中包含一些开箱即用的模型，这些模型针对业务进行了抽象和提炼，面向用户的这层模型界面暴露的都是用户关心的属性，一些实现的细节被屏蔽掉了，所以它是面向业务的，也更容易被用户所接受和上手使用。\n符合工程直觉\nKusion 模型库作为用 KCL 编写的模型集合，更加符合工程直觉。因为 KCL 既然作为一门语言，它支持定义变量，编写条件判断，比如你可以通过 if-else 编写一些差异化的配置。\n解决的问题\n本节介绍的可读性的提升主要分为两个方面。一方面是 KCL 这门 KusionStack 自研的配置语言本身足够强的表达力，使得通过 KCL 描述配置和抽象模型更加丝滑；另一方面，使用 KCL 定义的 Kusion Model 封装了复杂的配置转换逻辑，屏蔽业务细节，抽象出清晰易懂的用户界面。这两方面的带来的可读性的优势可以比较好的解决使用传统配置语言维护困难的问题。\n工程性 前后端模型解耦\n我们对 Kusion 模型库根据功能，区分了前端模型和后端模型。为什么要区分前端模型和后端模型？直接目的是将「用户界面」和「模型实现」进行分离：\n前端模型\n前端模型即「用户界面」。包含平台侧暴露给用户的所有可配置属性，其中省略了一些重复的、可推导的配置，抽象出必要属性暴露给用户。\n用户只需要像实例化一个类 （Class） 一样，传入必要参数构成一份应用的「配置清单」，再经过工具链编译即可得到完整的面向基础设施的配置描述，比如说 K8s 的 YAML；\n后端模型\n后端模型是「模型实现」。后端模型和前端模型不同，是对用户不感知，刚才提到前端模型可以构成用户的配置清单，那么怎么让用户的配置清单生效呢？\n我们将属性的渲染逻辑全部下沉到后端模型中，后端模型中可借助 KCL 编写校验、逻辑判断、代码片段复用等逻辑，提高配置代码复用性和健壮性。\nMixin 复用\nMixin 是 KCL 提供的一种复用代码片段的方式。举个具体的例子，比如说有个模型的属性叫做超卖，开启超卖开关可以将 Pod 调度到可以超卖的机器当中，应用一般在发布线下环境的时候会开启超卖，以充分利用集群的资源。这段超卖配置生效的逻辑可能会被不同的应用运维模型使用，那么就可以借助 Mixin 机制实现一个 OverQuotaMixin，OverQuotaMixin 可以被不同后端模型引用，解决复用性的问题，无需重复造轮子。\nAppConfiguration 沉淀\n我们针对不同应用运维场景或者部署场景抽象为不同的应用运维模型，这些应用运维模型我们叫做 AppConfiguration。\n它们暴露的属性是不一样的，比如适应于标准基础设施的标准应用模型，适应于网络应用的网络应用模型。这些不同的应用运维模型暴露给用户可配置的属性是不同的，这些模型沉淀下来可以描述越来越多场景的应用运维配置，沉淀为在推动配置代码化过程中重要的资产。\n解决的问题\n本节介绍的是团队在建设蚂蚁的 Kusion 模型库过程中形成的一套最佳实践，它是推动建设 Kusion 模型库和工具链的一站式和开放性的基础。\n一站式 全生命周期配置描述 \u0026amp;amp; Single Source of Truth\n我们在完善可读性和工程性的过程中实现了全生命周期配置描述。我们将应用的部署配置、网络配置、监控配置等等和应用生命周期相关的配置尽可能的放到了一个模型中。\n这样做的好处是，将散落在各个系统的配置片段收集到了一起，用户可以在一个统一界面中维护他的应用配置，同时对于第三方系统，也不需要对接不同系统，他只需要运维一份统一的配置即可。\n「全生命周期配置描述」其实在做一件事情，就是业界经常提到的 Single Source of Truth，也就是所谓的“唯一真实来源”。这是实现 IaC 的重要前提之一。\n从下图可以看到，Kusion 模型库中的前后端模型将不同维度的运维能力通过 KCL 模块化，并灵活组织在各种 AppConfiguration 模型中。同时基于 AppConfiguration 实例化出的 …","date":1658214000,"description":"KusionStack 最早是为了解决蚂蚁内部复杂的运维场景而诞生的解决方案。思路是通过自研的 DSL（KCL）沉淀运维模型（Kusion Model），将基础设施部分能力的使用方式从白屏转为代码化，同时结合 DevOps 工具链（Kusion CLI）实现配置快速验证和生效，以此提升基础设施的开放性和运维效率。","dir":"blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e4c34198e41bd1986c646cf6f0ab041b","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","summary":"文｜杨英明（花名：向野) KusionStack 核心贡献者、蚂蚁集团高级研发工程师 在基础设施技术领域深耕，专注 IaC/XaC、GitOps 等方向 本文 4912 字 阅读 12 分钟","tags":["SOFAStack"],"title":"KusionStack 开源｜Kusion 模型库和工具链的探索实践","type":"blog","url":"/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/","wordcount":5102},{"author":null,"categories":"SOFAStack","content":" 文｜赵新（花名：于雨 )\n蚂蚁集团可信原生部工程师阿里开源先锋人物、阿里开源大使\n负责蚂蚁可信原生技术部 DB Mesh 系统开发，以及容器和分布式事务开源工作\n本文 3846 字，阅读 10 分钟\n｜引语｜ 分布式事务是微服务技术体系中非常关键的的一个技术节点，当下最流行且经过大规模生产验证的高质量分布式事务实现无疑是 Seata。Seata 社区过去四年长期专注于 Java 语言实现，在 Java 领域是事实上的分布式事务技术标准平台。\n在诸如 gRPC 等微服务体系都在进行多语言建设的当下，分布式事务也应该有多种语言支持。所以在规划 2022 年 Seata Roadmap 时，其中一个非常的关键点就是 Seata 的多语言技术体系建设。在经过半年的准备特别是完成了 Seata v1.5.2 发版后，社区在今年 （2022年） 下半年的重点任务就是全力建设 Seata 的多语言实现。\nPART. 1\u0026amp;ndash;关键技术点 Seata Java 版本经过四年建设后，已经形成了一个非常庞大的技术体系。在进行多语言建设时，想要在半年内让多语言版本 Seata 的功能与 Seata Java 完全对齐，是不可能的。社区需要综合考量当下的实际迫切需求以及未来的发展方向，先找出 Seata 多语言版本的关键技术点。\n1. 事务模式 Seata 提供了 TCC、SAGA、AT 和 XA 四种经典事务模式。下图是四种模式的发布时间。\n各种模式有其各样的特点：\nAT 模式\n算是阿里体系独创的事务模式，其本质属于两阶段事务，其二阶段的 commit/rollback 由框架自动生成，对业务没有侵入，用户友好度高于 TCC 模式，可完美接续 Spring 事务，开发效率也较高，也是当前用户最多的一种模式。在 v1.5.2 已经发版的当下时间节点来看，AT 模式下通过全局锁来实现数据的隔离性，对于同一个资源的事务处理只能串行操作，性能一般。\nTCC 模式\n需要业务层参与者实现 prepare/commit/rollback 接口，其性能在四种模式下最好，数据可见性、隔离性也不错，流行程度仅次于 AT。特别适用于对吞吐、性能、隔离性要求都比较高的金融业务。\nSAGA 模式\n是一种长事务解决方案，其一阶段正向服务和二阶段补偿服务都由业务开发实现，可以很方便地与微服务框架进行结合，其性能仅次于 TCC 模式。因为其方便编排的特点，它在微服务编排领域有大量应用，当然使用时需要用户写 JSON 文件对服务进行编排。但其数据隔离性不好，业务数据有被脏写的风险。社区目前正在进行 SAGA 注解化工作（https://github.com/seata/seata/pull/4577），可进一步提升其性能与易用性。\nXA 模式\n不同于其他三种「补偿型」事务，它提供了最严格的隔离性：可以保证全局视角的数据一致性，即保证了用户不会出现脏读。Seata XA 模式的接口与 AT 模式基本一致，算是对用户比较友好的一种事务模式，它是对 XA 协议的严格实现。XA 模式的缺点是其事务范围比较长，其性能最低。\n四种模式的发版顺序如下：\n每种事务模式在阿里体系内都有各自的业务场景，其出现与演进都是迎合了各自业务场景现有的痛点。AT 和 XA 是不需要理解业务语义的，作用于 DB driver + DB 层面，TCC 和 SAGA 则需要业务层面自实现回滚幂等类逻辑，按照数据面和业务面来切分，依据对业务的入侵程度，四种模式归类如下图。\n分布式事务的基石是通信框架、SQL 解析以及数据库连接驱动实现等。得益于 Java 语言丰富的生态，Seata Java 版本可以很方便地站在这些 “巨人” 肩上展开相应的工作，这也是其他语言无法望其项背的。例如，主流数据库都提供了其 Java 版本的 DB driver。但当把工作背景放到多语言场景下时，就需要考量各个语言相关技术点的实现程度了。\n四种事务模式，AT 模式本质是应用层的事务，需要把数据库层面做过的 Redo/Undo 在应用层再做一遍，其中非常关键的一个技术点是：AT 模式需要介入数据源做 SQL 拦截，对 SQL 进行解析。单单考量 SQL 解析这个单技术点，Java 和 Python 语言有 antlr，Go 语言有 TiDB 提供的可自由使用的 pingcap/parser，但目前很多其他语言在这块都是空白的。\n所以社区在考量现实情况后，除了 Go 和 Python 版本，在进行多语言版本建设时，没有 SQL 解析包的语言版本先不提供 AT 模式的实现。\n2. 通信协议 不论哪种事务模式，都构建在 Seata 独有的架构之上。\n图片来自 seata 官网\nSeata 总体架构由如下角色构成：\n事务协调器 Transaction Coordinator\n简称 TC，维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。\n事务管理器 Transaction Manager\n简称 TM，定义全局事务的范围，提交或者回滚全局事务。\n资源管理器 Resource Manager\n简称 RM，和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。\nTC 与 TM 以及各个 RM 之间使用 netty 框架进行长链接通信。具体而言，Seata Java 版本的通信协议是在四层 TCP 协议之上又定义了一套私有的二进制双向通信协议。其关键点在于 Seata Java 版本站在了 netty 这个巨人肩上。\n回到多语言这个背景下，很多语言并没有提供一套成熟的 TCP 通信框架。譬如 Dubbo 在建设其 Go 版本 dubbo-go 时，为了在 TCP 之上实现与 Dubbo 的私有二进制协议通信，本人前期的工作重点是先实现 TCP 通信框架 getty（https://github.com/apache/dubbo-getty），然后再实现其序列化协议 dubbo-go-hessian2（https://github.com/apache/dubbo-go-hessian2）。如果把语言切换成 JS、PHP 或者 Python，相关通信协议建设需要耗费社区大量精力。\nSeata 2019 年就在 API 层适配了 gRPC 的事务上下文传递，为了方便 Seata 多语言版本的建设，Seata Java 框架本身正在进行一项重要工作：Seata Client （包括 TM 和 RM） 基于 gRPC 与 Seata Server （TC） 集群进行通信。希望借助于 gRPC 的多语言优势，节省多语言版本在通信层面的工作量。\n3. 配置和注册中心 类似于其他微服务框架，Seata 自身除了上一节提到的内部组件外，还依赖于注册中心和配置中心。微服务上层的应用通过配置中心找到注册中心，再通过注册中心发现 Seata 的各个服务组件。一个典型的完备的 Seata 服务架构如下图。\nSeata Java 这套架构可以很方便的嵌入注入 Dubbo、SOFARPC 以及 Spring 等 Java 微服务框架中。其中两种非常重要的外部依赖组件是：\nConfig …","date":1658214000,"description":"在诸如 gRPC 等微服务体系都在进行多语言建设的当下，分布式事务也应该有多种语言支持。所以在规划 2022 年 Seata Roadmap 时，其中一个非常的关键点就是 Seata 的多语言技术体系建设。在经过半年的准备特别是完成了 Seata v1.5.2 发版后，社区在今年 （2022 年） 下半年的重点任务就是全力建设 Seata 的多语言实现。","dir":"blog/seata-multi-programming-language-system-construction/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"60da96ebbdbc644758f505352c5e2d13","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-multi-programming-language-system-construction/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/seata-multi-programming-language-system-construction/","summary":"文｜赵新（花名：于雨 ) 蚂蚁集团可信原生部工程师阿里开源先锋人物、阿里开源大使 负责蚂蚁可信原生技术部 DB Mesh 系统开发，以及容器和分布式事务开源工作","tags":["SOFAStack"],"title":"Seata 多语言体系建设","type":"blog","url":"/sofastack.tech/blog/seata-multi-programming-language-system-construction/","wordcount":4266},{"author":"林楠","categories":"SOFAStack","content":" 前言 SOFABoot 提供两种服务通信能力，一种是 JVM 服务，用于同一应用内不同模块间的通信，一种是 RPC 服务，用于不同应用间的通信。SOFABoot 提供三种方式实现服务的发布和引用，分别是XML 配置文件、注解和 API 的方式，本文从源码角度解析从服务的发布和引用到组件协议 binding 机制的实现原理。\n服务发布与引用 在了解组件协议 binding 机制之前，我们先简单了解一下服务的发布与引用的源码。\nXML 通过 XML 方式发布或引用服务时，使用 sofa:service 发布服务，使用 sofa:reference 引用服务，示例代码如下：\n\u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleJvmService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.isle.sample.SampleJvmService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; \u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleJvmService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.isle.sample.SampleJvmService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 我们可以看到在 xml 中使用 xmlns:sofa，将 sofa 前缀的命名空间定义为 http://sofastack.io/schema/sofaboot ，Spring 在解析 sofa:* 标签时会与该命名空间相关联。对于 xml 的解析，SOFABoot 在 sofa-boot 模块中使用 spring.handlers 配置文件中注册了 sofa 命名空间的 XML 处理器。\nhttp\\://sofastack.io/schema/sofaboot=com.alipay.sofa.boot.spring.namespace.handler.SofaBootNamespaceHandler SofaBootNamespaceHandler 在初始化阶段，基于 SPI 机制查找所有标签解析器，调用 registerTagParser 方法注册标签解析器。\npublic void init() { ServiceLoader\u0026amp;lt;SofaBootTagNameSupport\u0026amp;gt; serviceLoaderSofaBoot = ServiceLoader.load(SofaBootTagNameSupport.class); serviceLoaderSofaBoot.forEach(this::registerTagParser); } 注册标签解析器时，调用解析器的 supportTagName 方法获取标签名，将解析器与标签名关联起来。\nprivate void registerTagParser(SofaBootTagNameSupport tagNameSupport) { if (tagNameSupport instanceof BeanDefinitionParser) { registerBeanDefinitionParser(tagNameSupport.supportTagName(), (BeanDefinitionParser) tagNameSupport); } else if (tagNameSupport instanceof BeanDefinitionDecorator) { registerBeanDefinitionDecoratorForAttribute(tagNameSupport.supportTagName(), (BeanDefinitionDecorator) tagNameSupport); } else { ... } } sofa:service 标签的解析器是 ServiceDefinitionParser，使用 doParseInternal 方法读取 xml 标签属性值，并解析为 bean 定义，根据 getBeanClass 定义的类型，将 sofa:service 标签定义的服务转换为 ServiceFactoryBean，并注册到 Spring 上下文中。\npublic class ServiceDefinitionParser extends AbstractContractDefinitionParser { ... @Override protected void doParseInternal(Element element, ParserContext parserContext, BeanDefinitionBuilder builder) { String ref = element.getAttribute(REF); builder.addPropertyReference(REF, ref); if (element.hasAttribute(\u0026amp;quot;id\u0026amp;quot;)) { String id = element.getAttribute(\u0026amp;quot;id\u0026amp;quot;); builder.addPropertyValue(BEAN_ID, id); } else { builder.addPropertyValue(BEAN_ID, ref); } } @Override protected Class getBeanClass(Element element) { return ServiceFactoryBean.class; } @Override public String supportTagName() { return \u0026amp;quot;service\u0026amp;quot;; } } 根据 Spring 的机制，在注册 bean 时，对 bean 的属性赋值后会调用 bean …","date":1658214000,"description":"源码解析 | SOFABoot 组件协议 binding 机制解析","dir":"projects/sofa-boot/sofaboot-component-protocol-binding/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"acfba7d02af62462b2f1c32fb39c9265","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","publishdate":"2022-07-19T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","summary":"前言 SOFABoot 提供两种服务通信能力，一种是 JVM 服务，用于同一应用内不同模块间的通信，一种是 RPC 服务，用于不同应用间的通信。SOFABoot 提供三种方式实","tags":["“源码解析”"],"title":"源码解析：SOFABoot 组件协议 binding 机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/","wordcount":5465},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展\n欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 清源 提问：\n 咨询个问题，MOSN 能做协议转换吗？类似于 API 网关那种功能，像 HTTP 调 Dubbo 的服务。\n A：可以的哈，这里是一个 HTTP 到 SOFA 的例子，\nhttps://github.com/mosn/mosn/tree/master/pkg/filter/stream/transcoder/http2bolt\n 我看了下，例子中并没有对 buf 做编解码，是 Bolt 自动识别 HTTP 的报文吗？\n A：这个 filter 就是把 HTTP 的字段转换为 Bolt 的哟，这还有个 Spring Cloud 到 Dubbo 的转换，MOSN 已经对 buf 解码好了，暴露给你的是 HTTP 解码之后的 header 和 body，\nhttps://www.github.com/mosn/extensions/tree/master/go-plugin%2Fplugins%2Ftranscoders%2Fspringcloud2dubbo%2Fmain\n「MOSN」：\nhttps://github.com/mosn/mosn\n2. 国奇 提问：\n 你好，请问有能用的 SOFARegistry 安装步骤吗？\n A：用 start_dev 启动 integrate 模式，registry-run.sh 是给其他脚本调用的：\n也可以参考下面这个文档，fatjar docker 的部署模式都可以：\n*https://www.sofastack.tech/projects/sofa-registry/deployment/***\n「SOFARegistry」：\nhttps://github.com/sofastack/sofa-registry\n3. 国奇 提问：\n 你好，发现一个问题，比如 A 应用 1.0 升级到 2.0 得改 webContextPath 才可以。也就是说要升级版本，要改版本号，还需要改 webContextPath 对吧？\n A：按这里文章介绍的，不引入 web-ark-plugin 的话，就用不同的端口来部署多个 web 服务。你们可以保留这个使用方式，就不需要改 webContextPath，\nhttps://github.com/WuHang1/sofa-ark/blob/code_analyse_multi_web_deploy/doc/CODE_ANALYSE_MULTI_WEB.md\n 发布就会更改不同的端口号，否则端口号被占用。可不可以，我自己不用改端口号，也不用改 webContextPath？\n A：目前不可以，你可以看下之前介绍 SOFAArk Web 插件的文档，里面介绍了必须要改这两个中的其中一个。如果有方案能做到这点那是挺好的，可以提个 proposal。\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n本周推荐阅读 Go 原生插件使用问题全解析\n\nSOFARegistry 源码｜数据同步模块解析\n\n社区文章｜MOSN 构建 Subset 优化思路分享\n\nNydus —— 下一代容器镜像的探索实践\n\n欢迎关注：\n","date":1657868400,"description":"SOFA Weekly | 开源人—牛学蔚、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220715/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f60972f54e7daee19a80b6022c644290","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220715/","publishdate":"2022-07-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220715/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展 欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人—牛学蔚、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220715/","wordcount":912},{"author":null,"categories":"SOFAStack","content":" 文｜丁飞（花名：路德 )\n蚂蚁集团高级工程师\n深耕于 SOFAMesh 产品的商业化落地\n主要方向为基于服务网格技术的系统架构升级方案设计与落地\n本文 4394 字 阅读 10 分钟\n｜前言｜ MOSN 作为蚂蚁集团在 ServiceMesh 解决方案中的数据面组件，从设计之初就考虑到了第三方的扩展开发需求。目前，MOSN 支持通过 gRPC、WASM、以及 Go 原生插件三种机制对其进行扩展。\n我在主导设计和落地基于 Go 原生插件机制的扩展能力时遇到了很多问题，鉴于这方面的相关资料很少，因而就有了这个想法来做一个非常粗浅的总结，希望能对大家有所帮助。\n注：本文只说问题和解决方案，不读代码，文章最后会给出核心源码的 checklist。\nPART. 1\u0026amp;ndash;文章技术背景 一、运行时 通常而言，在计算机编程语言领域，“运行时”的概念和一些需要使用到 VM 的语言相关。程序的运行由两个部分组成：目标代码和“虚拟机”。比如最为典型的 JAVA，即 Java Class + JRE。\n对于一些看似不需要“虚拟机”的编程语言，就不太会有“运行时”的概念，程序的运行只需要一个部分，即目标代码。但事实上，即使是 C/C++，也有“运行时”，即它所运行平台的 OS/Lib。\nGo 也是一样，因为运行 Go 程序不需要前置部署类似于 JRE 的“运行时”，所以它看起来似乎跟“虚拟机”或者“运行时”没啥关系。但事实上，Go 语言的“运行时”被编译器编译成了二进制目标代码的一部分。\n图 1-1. Java 程序、runtime 和 OS 关系\n图 1-2. C/C++ 程序、runtime 和 OS 关系\n图 1-3. Go 程序、runtime 和 OS 关系\n二、Go 原生插件机制 作为一个看起来更贴近 C/C++ 技术栈的 Go 语言来说，支持类似动态链接库的扩展一直是社区中较为强烈的诉求。\n如图 1-5，Go 在标准库中专门提供了一个 plugin 包，作为插件的语言级编程界面，src/plugin 包的本质是使用 cgo 机制调用 unix 的标准接口：dlopen() 和 dlsym() 。因此，它给 C/C++ 背景的程序员一种“这题我会”的错觉。\n图 1-4. C/C++ 程序加载动态链接库\n图 1-5. Go 程序加载动态链接库\nPART. 2\u0026amp;ndash;典型问题解决 很遗憾，与 C/C++ 技术栈相比，Go 的插件的产出物虽然也是一个动态链接库文件，但它对于插件的开发、使用有一系列很复杂的内置约束。更令人头大的是，Go 语言不但没有对这些约束进行系统性的介绍，甚至写了一些比较差的设计和实现，导致插件相关问题的排错非常反人类。\n本章节重点跟大家一起看下，在开发、使用 Go 插件，主要是编译、加载插件的时候，最常见、但必须定位到 Go 标准库 （主要包括编译器、链接器、打包器和运行时部分） 源码才能完全弄明白的几个问题，及对应的解决方法。\n简而言之，Go 的主程序在加载 plugin 时，会在“runtime”里对两者进行一堆约束检查，包括但不限于：\n- go version 一致\n- go path 一致\n- go dependency 的交集一致\n 代码一致 path 一致 - go build 某些 flag 一致\n一、不一致的标准库版本 主程序加载插件时报错：\nplugin was built with a different version of package runtime/internal/sys\n从这个报错的文本可以得知，具体有问题的库是 runtime/internal/sys ，很显然这是一个 go 的内置标准库。看到这里，你可能会有很大的疑惑：我明明用的是同一个本地环境编译主程序和插件，为什么报标准库不是一个版本？\n答案是，Go 的 error 日志描述不准确。而这个报错出现的根本原因可以归结为：主程序和插件的某些关键编译 flag 不一致，跟“版本”没啥关系。\n比如，你使用下面的命令编译插件：\nGO111MODULE=on go build \u0026amp;ndash;buildmode=plugin -mod readonly -o ./codec.so ./codec.go\n但是你使用 goland 的 debug 模式调试主程序，此时，goland 会帮你把 go build 命令按下面的例子组装好：\n注意，goland 组装的编译命令里包含关键的 -gcflags all=-N -l 参数，但是插件编译的命令里没有。此时，你在尝试拉起插件时就会得到一个有关 runtime/internal/sys 的报错。\n图 2-1. 编译 flag 不一致导致的加载失败\n解决这一类标准库版本不一致问题的方案比较简单：尽可能对齐主程序和插件编译的 flag。事实上，有一些 flag 是不影响插件加载的，你可以在具体的实践中慢慢摸索。\n二、不一致的第三方库版本 如果使用 vendor 来管理 Go 的依赖库，那么当解决上一节的问题之后，你 100% 会立即遇到以下这个报错：\nplugin was built with a different version of package xxxxxxxx\n其中，xxxxxxxx 指的是某一个具体的三方库，比如 github.com/stretchr/testify。这个报错有几个非常典型的原因，如果没有相关的排查经验，其中几个可能会烧掉开发人员不少时间。\nCase 1. 版本不一致\n如报错所示，似乎原因很明确，即主程序和插件所共同依赖的某个第三方库版本不一致，报错中会明确告诉你哪一个库有问题。此时，你可以对比排查主程序和插件的 go.mod 文件，分别找到问题库的版本，看看他们是否一致。如果这时候你发现主程和插件确实有 commitid 或 tag 的不一致问题，那解决的方法也很简单：对齐它们。\n但是在很多场景下，你只会用到三方库的一部分：如一个 package，或者只是引了某些 interface。这一部分的代码在不同的版本里可能根本就没有变更，但其他没用到的代码的变更，同样会导致整个三方库版本的变更，进而导致你成为那个“版本不一致”的无辜受害者。\n而且，此时你可能立即会遇到另一个问题：以谁为基准对齐？主程序？还是插件？\n从常理上来说，以主程序为基线进行对齐是一个比较好的策略，毕竟插件是新添加的“附属品”，且主程序与插件通常是“一对多”的关系。但是，如果插件的三方库依赖因为任何原因就是不能和主程序对齐怎么办？在尝试了很久以后，我暂时没有找到一个完美解决这个问题的办法。\n如果版本无法对齐，就只能从根本上放弃走插件这条路。\nGo 语言的这种对三方库的、几乎无脑的强一致性约束，从一方面来说，避免了运行时因为版本不一致带来的潜在问题；从另一方面来说，这种刻意不给程序员灵活度的设计，对插件化、定制化、扩展化开发非常的不友好。\n图 2-2. 共同依赖的三方库版本不一致导致的加载失败\nCase 2. 版本号一致，代码不一致\n当你按照 case 1 的思路排查 go.mod 文件，但是惊讶的发现报错的库版本是一致的时候，事情就会变得复杂起来。你可 …","date":1657609200,"description":"作者在主导设计和落地基于 Go 原生插件机制的扩展能力时遇到了很多问题，鉴于这方面的相关资料很少，因而就有了这个想法来做一个非常粗浅的总结，希望能对大家有所帮助。","dir":"blog/go-native-plug-in-use-problem-full-analysis/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"734cc212a753d53c15717c92d859d34c","permalink":"https://sofastack.github.io/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","publishdate":"2022-07-12T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","summary":"文｜丁飞（花名：路德 ) 蚂蚁集团高级工程师 深耕于 SOFAMesh 产品的商业化落地 主要方向为基于服务网格技术的系统架构升级方案设计与落地 本文 4394 字 阅读 10 分钟 ｜前","tags":["SOFAStack"],"title":"Go 原生插件使用问题全解析","type":"blog","url":"/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/","wordcount":4545},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1. 何烨 提问：\n 请问一下这个配置现在支持 Nacos 了吗？\n A：SOFABoot 已经支持 Nacos 了。\n「SOFABoot」： https://github.com/sofastack/sofa-boot\n2. 鲍之知 提问：\n 下图中这个 SOFATracer 日志默认是生成在哪里呀？\n A：~/logs。\n「SOFATracer」： https://github.com/sofastack/sofa-tracer\n3. Philip Guan 提问：\n 请问 biz 可以独立引入 master biz 中没有的依赖吗？例如 Hutool、master biz 没有，希望在 biz 里使用。\n A：可以的，打包完后可以 check 一下是否 /biz/ 里有这个包。如果没有的话，可以在 master biz 里引入这个依赖，在 biz 里引入但设置 为 provided 也可以使用。\n 期望是 master biz 不引入 Hutool 的情况下，在 biz 里使用 Hutool。\n A：可以的。\n「SOFAArk」： https://github.com/sofastack/sofa-ark\n本周推荐阅读 KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境 \n GLCC｜Kata Containers、Nydus、Layotto、KusionStack 中选名单公示！ \n SOFARegistry 源码｜数据同步模块解析 \n 社区文章｜MOSN 构建 Subset 优化思路分享 \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1657263600,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220708/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"897429d0434f7577dd9a8efd3b70056f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220708/","publishdate":"2022-07-08T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220708/","summary":"SOFA WEEKLY | 每周精选 筛选每周精华问答，同步开源进展，欢迎留言互动～ SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220708/","wordcount":661},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@魏顺利 提问：\n runtime-sofa-boot-starter 和 rpc-sofa-boot-starter 区别是什么？\n A：runtime-sofa-boot-starter 是 SOFA 的核心能力 starter，rpc-sofa-boot-starter 是 SOFARPC 能力的 starter。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n2.@寒鸦少年 提问：\n 请问 Plugin 是一个微服务的概念吗，是否提供 HTTP 接口呢？\n A：Plugin 自己管理的依赖，通过 ark 中提到的 导出机制，将其自己管理的类能够暴露给 biz 使用 （多 biz 可以共享某个 plugin 导出的类） ；plugin 和 biz 之间更多说的是类加载的委托关系，biz 之间是通信。\n 那 biz 的 class loader 的加载逻辑应该很复杂吧，因为它要区分什么类自己加载，什么类委托 plugin 加载。\n A：可以看下这个，https://www.sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/\n「SOFAArk」https://github.com/sofastack/sofa-ark\n本周推荐阅读 社区文章｜MOSN 构建 Subset 优化思路分享 \n SOFA 星球”闯关计划 2.0——Layotto 飞船焕新出发 \n Nydus —— 下一代容器镜像的探索实践 \n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1656054000,"description":"SOFA Weekly | 开源人-于雨、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220624/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bc4cc62919a28554b99dc8a812b88dcc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220624/","publishdate":"2022-06-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220624/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源人-于雨、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220624/","wordcount":813},{"author":null,"categories":"SOFAStack","content":" 文｜李旭东（花名：向旭 )\n蚂蚁集团技术专家\n蚂蚁中间件研发，专注于 SOFARegistry 及其周边基础设施的开发与优化\n本文 2098 字 阅读 8 分钟\n｜前言｜ MOSN 使用了 Subset 算法作为其标签匹配路由负载均衡的方式。本文主要介绍 Subset 的原理，包括了在超大规模集群下 MOSN 的 Subset 所遇到的一些性能瓶颈与采用的优化算法。\n首先，为什么要优化 Subset 呢？\n总体而言，性能瓶颈往往会由于集群规模的增大逐渐暴露出来。在蚂蚁的超大规模的集群上，注册中心推送地址列表会对应用造成一定的开销。\n在我所参与过的某一次大规模压测中，核心应用的机器数目非常庞大，当进行发布或者运维的时候，它的地址列表会被推送给所有调用它的应用。\n而 MOSN 会接收这份地址列表重新构建自己的路由。当地址列表非常庞大的时候，MOSN 更新 cluster 的性能瓶颈逐渐地暴露出来，出现了较高的 CPU 毛刺，内存在短时间内出现了上涨，gc 频率也大幅度增加。\n通过下方的火焰图，我们可以看到这次压测期间对某应用的 MOSN 的 pprof：\n- Alloc：\n- CPU：\n从 pprof 可以看到，无论是 CPU 还是 alloc 的开销， 构建 SubsetLoadBalancer 都明显占了大头，所以优化这部分的构建是亟待去做的一件事。\n最终通过探索优化，我们可以减少 SubsetLoadBalancer 构建过程中 95% 的 CPU 开销和 75% 的 alloc 开销。\n下面让我们一起回顾下本次优化的过程与思路。\nPART. 1\u0026amp;ndash;Subset 基本原理介绍 在一个集群里，通常机器会有不同的标签，那么如何将一个请求路由到指定标签的一组机器呢？\nMOSN 的做法是把一个服务下的机器按照机标签组合进行预先分组，形成多个子集。在请求的时候，根据请求中的 metadata 信息可以快速查询到这个请求对应应该匹配到的子集。\n如下图所示，可以看到当前有 4 个节点：\n标签匹配规则会根据 zone 、mosn_aig 、mosn_version 这 3 个字段进行匹配路由，根据这 3 个 key 的排序进行组合得到以下匹配路径：\n相对应的匹配树如下：\n假设需要访问 {zone: zone1, mosn_aig: aig1}，那么经过排序后查找顺序为 mosn_aig:aig1 -\u0026amp;gt; zone:zone1，查找到 [h1, h2]。\n以上就是 Subset 的基本原理介绍。\nPART. 2\u0026amp;ndash;MOSN 对 Subset 的构建 首先需要输入的参数有两个：\n- 带标签的机器列表 hosts，比如 [h1, h2, h3, h4]；\n- 用于匹配的 subSetKeys, 如下图：\n接着我们先带上思路，然后阅读源码来看一下 MOSN 的 SubsetLoadBalancer 是如何构建这棵树的。\n核心思路如下：\n- 遍历每一个 host 的 labels 和 subSetKeys 递归去创建一棵树；\n- 对于树的每一个节点，都会遍历一次 hosts 列表，过滤出匹配这个节点的 kvs 的 subHosts，每个节点创建一个子 load balancer。\n我们来看源码图：\n整体的构建复杂度是 O *(M*NK) (M: Subset 树节点个数，N: Hosts 个数, K: 匹配的 Keys）\nPART. 3\u0026amp;ndash;构建性能瓶颈分析 通过对生产的 profile 分析，我们发现 SubsetLoadBalancer 的 createSubsets 在 CPU 和 alloc 的火焰图中的占比都较高。所以下面我们开始编写 benchmark，来优化这一部分的性能。\n我们的输入参数为：\n- subSetKeys：\n- 8000 个 hosts （每个 hosts 都有 4 个 label, 每个 label 对应 3 种 value） ：\n接着，我们来看 CPU 和 alloc_space 的占用情况。\n- CPU：\n- alloc_space：\n从上面两张火焰图中，我们可以看出 HostMatches 和 setFinalHost 占用了较多的 CPU_time 和 alloc_space。我们首先来看下 HostMatches：\n它的作用是判断一个 host 是不是完全匹配给定的键值对，且判断这个 host 是否匹配这个匹配树节点。\n它的开销主要在于执行次数过多：treeNodes * len(hosts) ，所以在集群变大时，这边的运行开销会大幅度上升。\n然后我们再来看一下 setFinalHost：\n他的主要逻辑是按 IP 进行去重，同时会附带 copy。如果我们在 SubsetLoadBalancer 的顶层进行去重，那么它的任意 Subset 都不需要再次去重。因此，这边可以把它改成不去重。\nPART. 4\u0026amp;ndash;倒排索引优化构建 在 HostMatches 的这么多次匹配中，实际上有很多的重复操作，比如对 host label 中某个 kv 判断 equals，在构建过程中重复的次数相当之多。\n所以优化的思路可以基于避免这部分重复的开销，从预先构建倒排索引出发。具体步骤展开如下：\n1. 输入两项参数:\n- subSetKeys：\n- hosts：\n2. 遍历一次 hosts，针对每个 kv 我们用 bitmap 构建倒排索引：\n3. 根据 subSetKeys 和倒排索引中的 kvs，构建出匹配树，因为索引中是去重的与 hosts 数目无关，这个操作开销占比很低；\n4. 对于树的每个节点，利用倒排索引中的 bitmap 做交集快速得到匹配全部 kv 的 hosts 的索引 bitmap；\n5. 使用 bitmap 中存储的 index 从 hosts 中取出对应 subHosts 构建子 load balancer，同时注意此处不需要使用 setFinalHosts 进行去重。\n基于上述思路过程开发新的 Subset preIndex 构建算法，可以在 MOSN 的对应 Pull Request 页面查看详情：\nhttps://github.com/mosn/mosn/pull/2010\n再分享下添加 benchmark 进行测试的地址：\nhttps://github.com/mosn/mosn/blob/b0da8a69137cea3a60cdc6dfc0784d29c4c2e25a/pkg/upstream/cluster/subset_loadbalancer_test.go#L891\n可以看到相对之前的构建方式，构建速度快了 20 倍，alloc_space 减小了 75% 。同时，alloc 次数出现了少量的上升，这是因为需要额外的构建一次倒排索引所致。\n下面观察一下 gc：\n我们可以发现，相较于之前的构建方式，运行期间的内存更小了，而且 CPU 回收的内存也变少了，同时 gc 并行扫描的时长小幅上涨，STW 时间变的更短。\n最后，测试一下在不同 hosts 数目下的优化程度，可以看到在 hosts …","date":1655708400,"description":"MOSN 使用了 Subset 算法作为其标签匹配路由负载均衡的方式。本文主要介绍 Subset 的原理，包括了在超大规模集群下 MOSN 的 Subset 所遇到的一些性能瓶颈与采用的优化算法。","dir":"blog/build-subset-optimization/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d1475506aa7ef2b35d302df89924b72d","permalink":"https://sofastack.github.io/sofastack.tech/blog/build-subset-optimization/","publishdate":"2022-06-20T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/build-subset-optimization/","summary":"文｜李旭东（花名：向旭 ) 蚂蚁集团技术专家 蚂蚁中间件研发，专注于 SOFARegistry 及其周边基础设施的开发与优化 本文 2098 字 阅读 8 分钟 ｜前言｜ MOSN 使用了 Subset 算法作为其标","tags":["SOFAStack"],"title":"社区文章｜MOSN 构建 Subset 优化思路分享","type":"blog","url":"/sofastack.tech/blog/build-subset-optimization/","wordcount":2243},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@魏顺利 提问：\n 生成的 ark-biz.jar 这个怎么打到 maven 仓库？\n A：加上true配置然后 mvn install/deploy，参考：\nhttps://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n2.@寒鸦少年 提问：\n 请教个问题，SOFAStack 商业版里面，SOFABoot 在集成中间件的时候，中间件的客户端咱这边有自己封装的版本，还是纯走开源的那些客户端比如 Jedis 之类的。\n A：SOFAStack 有些中间件会有自己的封装，也会有独立的客户端。\n 可以给个列表么，具体有哪些独立的客户端和开源版本的升级点对比之类的？\n A：可以看下这个：\n「SOFABoot」https://github.com/sofastack/sofa-boot\n本周推荐阅读 「开源之夏」SOFASTack \u0026amp;amp; MOSN 社区项目中选结果 \n SOFA 星球”闯关计划 2.0——Layotto 飞船焕新出发 \n Nydus —— 下一代容器镜像的探索实践 \n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers \n更多文章请扫码关注“金融级分布式架构”公众号\n","date":1655449200,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220617/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3d55fba6e2019654f9dccb079b67ba5d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220617/","publishdate":"2022-06-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220617/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220617/","wordcount":699},{"author":"吴航","categories":"SOFAStack","content":" 背景 原生springboot-web应用部署流程 两种合并部署模式 支持单Host合并部署的关键点 多Biz共用tomcat实例 多Biz接口区分 总结 背景 SOFAArk基于java类加载机制，为我们提供了一种java进程内多模块隔离的方案。每个业务模块——Ark Biz，都是一个完整的springboot项目，可独立运行；也可作为一个maven依赖或远程jar包，引入被称为Master Biz的基座Biz，随着Master Biz的启动合并部署运行，并由专属的BizClassLoader加载来实现隔离。\n当多个合并部署的Biz为web应用时，则面临着更多的挑战，这里我们可以对比独立tomcat部署多个webapp的实现，其除了各webapp之间的隔离外，还要保证tomcat自身资源的共享和统一管控。SOFAArk从0.6.0开始支持基于springboot embedded tomcat的多web应用合并部署，它是如何做到的，是否可以继续扩展支持其它类型web容器应用，下文将会进行具体分析。\n原生springboot-web应用部署流程 我们先从原生的springboot构建的基于内置tomcat的web应用说起。其在运行main函数初始化时，使用TomcatServletWebServerFactory#getWebServer这一工厂方法，创建了一个实现WebServer接口的TomcatWebServer实例，用来控制一个tomcat服务器，其中包括了一个Catalina Server的实现StandardServer，Server中的Engine、Host、Context容器也都是一个，Context中包含了唯一的contextPath。\nspringboot自身还有jetty、netty等WebServer的实现，同样由其对应的工厂方法创建。对应的工厂bean基于springboot的自动装配机制加载。\n两种合并部署模式 首先我们可以参考非Web的多Biz合并部署，SOFAArk使用不同的类加载器加载不同的Biz，其中Master Biz为LaunchedURLClassLoader加载，非Master Biz有其专属的BizClassLoader加载。对于每个Web Biz，也会使用其类加载器完成上述原生springboot web应用的启动流程，创建自己的Server、Host等。\n这种情况下，为了区分不同Biz的接口，需要为每个Biz配置不同的port。\n这种方式由于一个Jvm进程中包含了多个Server及其Host，因此被称为多Host模式。\n多Host模式的问题首先在于重复创建了tomcat相关的资源，造成资源的浪费；其次是每个Biz有自己的端口，不利于整个Ark包应用整体对外提供服务。因此SOFAArk提供了类似独立tomcat部署多webapp的方式。所有Biz共用同一个Server及Host，每个Biz只创建自己的Context，通过Context中的contextPath将自身接口与其它Biz接口做区分。\n这种方式由于一个Jvm进程中共用一个Server及其Host，因此被称为单Host（多Context）模式。下面将就其实现做重点介绍。\n支持单Host合并部署的关键点 相较于单纯的springboot应用，一个Ark包的复杂之处在于，它可以包含多个Ark Biz，其中每个Ark Biz都是一个完整的springboot项目。因此在使用单个内置tomcat实例部署时会面临以下问题：\n 多个Biz(springboot项目)需要共用tomcat实例；\n 需要像独立tomcat下部署多webapp一样，通过添加前缀的方式区分不同Biz的http接口。\n 因此sofa-ark对springboot的相关实现做了替换，具体如下：\n sofa-ark springboot ArkTomcatServletWebServerFactory TomcatServletWebServerFactory ArkTomcatEmbeddedWebappClassLoader TomcatEmbeddedWebappClassLoader ArkTomcatWebServer TomcatWebServer 并使用其插件机制来扩展，ArkTomcatEmbeddedWebappClassLoader位于web-ark-plugin插件中，当maven依赖该插件时，springboot判断ArkTomcatEmbeddedWebappClassLoader类存在，加载ArkTomcatServletWebServerFactory，该Factory再创建ArkTomcatWebServer，由此使用单Host模式合并部署。\n若未依赖该插件，则ArkTomcatEmbeddedWebappClassLoader不存在，springboot自动加载其原生实现，使用多Host模式合并部署。\n多Biz共用tomcat实例 针对第一个问题——多个Biz要共用tomcat实例，sofa-ark定义了EmbeddedServerService接口，插件web-ark-plugin里包含了接口的实现EmbeddedServerServiceImpl，来持有公共tomcat实例。\npackage com.alipay.sofa.ark.web.embed.tomcat; //作为ark plugin导出 public class EmbeddedServerServiceImpl implements EmbeddedServerService\u0026amp;lt;Tomcat\u0026amp;gt; { //共享tomcat private Tomcat tomcat; private Object lock = new Object(); @Override public Tomcat getEmbedServer() { return tomcat; } @Override public void setEmbedServer(Tomcat tomcat) { if (this.tomcat == null) { //通过加锁，避免多Web Biz并发启动加载时重复创建tomcat实例 synchronized (lock) { if (this.tomcat == null) { this.tomcat = tomcat; } } } } } 如果Biz引入了web-ark-plugin，则在ArkTomcatServletWebServerFactory中注入EmbeddedServerServiceImpl，持有最先初始化的Web Biz创建的Tomcat实例(TomcatWebServer的核心)，并在后续初始化的其它Biz调用getWebServer获取tomcat实例时，返回持有的同一个实例，以此来保证多个Biz运行在同一个tomcat中。\npackage com.alipay.sofa.ark.springboot.web; //每个Web Biz启动中都会创建一 …","date":1655362800,"description":"SOFAArk 源码解析-多 Web 应用合并部署","dir":"projects/sofa-boot/sofa-ark-multi-web-component-deploy/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e279d4b44741b8b88e22bf6420d8b5a6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","publishdate":"2022-06-16T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","summary":"背景 原生springboot-web应用部署流程 两种合并部署模式 支持单Host合并部署的关键点 多Biz共用tomcat实例 多Biz接口区分 总","tags":["“源码解析”"],"title":"SOFAArk 源码解析-多 Web 应用合并部署","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/","wordcount":3703},{"author":"林楠","categories":"SOFAStack","content":" 前言 spring-boot-starter-actuator模块为 Spring Boot 应用提供了监控能力，内置一系列健康指标，如数据源、磁盘空间等，并且允许开发者自定义健康指标。Spring Boot 提供 health 端点，将所有健康指标聚合，当应用中有一个组件状态异常，那么应用的整体状态视为down，开发者可以访问 health 端点来了解应用当前的运行状况。\n SOFABoot 基于 actuator 模块扩展了健康指标，为应用提供 SOFA 组件的健康检查能力。同时，在 Spring Boot 原生的健康检查能力基础之上，增加了 Readiness Check 的能力。在这里我们做一个区分，Spring Boot 原生的健康检查称为 Liveness Check，SOFABoot 增加的健康检查称为 Readiness Check。Liveness Check 关注应用运行是否正常，如果 Liveness 状态异常，表示这个应用已经无法对外提供服务；Readiness Check 则关注的是应用有没有启动完成，是否进入“准备就绪”状态，能否对外提供服务。\n Readiness Check 只在应用启动阶段执行一次，通过请求 readiness 端点获取就绪状态，准备就绪后流量将进入应用。Readiness Check 完成后，多次请求 readiness 端点，不会重新发起检查。因此，在运行阶段应使用 Liveness Check 检查应用健康情况。\n 总体流程 在介绍总体流程前，先看一下 SOFABoot 健康检查机制中的一些重要接口：\n 接口类 说明 org.springframework.boot.actuate.health.HealthIndicator Spring Boot 原生的健康检查接口，想要新增一个自定义健康指标，可以直接扩展此接口 com.alipay.sofa.healthcheck.core.HealthChecker SOFABoot 提供的健康检查接口，相比 HealthIndicator 接口，增加了一些扩展参数，如失败重试次数，超时时间等 com.alipay.sofa.boot.health.NonReadinessCheck SOFABoot 默认会将所有 HealthIndicator 和 HealthChecker 纳入 Readiness Check 中，可以实现该接口将指标项标记为不参与 Readiness Check com.alipay.sofa.healthcheck.startup.ReadinessCheckCallback SOFABoot在 Readiness Check 之后会回调这个接口，如果想要在健康检查后做一些处理，可以直接扩展此接口 SOFABoot 的健康检查是基于 Spring 事件机制实现的，核心是 com.alipay.sofa.healthcheck.ReadinessCheckListener。ReadinessCheckListener 类实现了 GenericApplicationListener 接口，并监听 ContextRefreshedEvent事件，当 Spring 上下文刷新时触发健康检查流程：\npublic void onContextRefreshedEvent(ContextRefreshedEvent event) { if (applicationContext.equals(event.getApplicationContext())) { healthCheckerProcessor.init(); healthIndicatorProcessor.init(); afterReadinessCheckCallbackProcessor.init(); readinessHealthCheck(); readinessCheckFinish = true; } } 初始化 HealthCheckerProcessor：在 Spring 上下文中查找所有 HealthChecker 类型的 Bean； 初始化 HealthIndicatorProcessor：在 Spring 上下文中查找所有 HealthIndicator 类型的 Bean，并排除掉不参与 Readiness Check 的Bean。默认会排除 NonReadinessCheck 类型的 Bean，还可以通过参数com.alipay.sofa.boot.excludedIndicators 配置要排除的类型； 初始化 AfterReadinessCheckCallbackProcessor：在 Spring 上下文中查找所有 ReadinessCheckCallback 类型的 Bean ； 执行 Readiness Check 从上文中可以看出，readinessHealthCheck 方法是 Readiness Check 的入口：\npublic void readinessHealthCheck() { ...... healthCheckerStatus = healthCheckerProcessor .readinessHealthCheck(healthCheckerDetails); ...... healthIndicatorStatus = healthIndicatorProcessor .readinessHealthCheck(healthIndicatorDetails); ...... if (healthCheckerStatus \u0026amp;amp;\u0026amp;amp; healthIndicatorStatus) { ...... healthCallbackStatus = afterReadinessCheckCallbackProcessor .afterReadinessCheckCallback(healthCallbackDetails); } determineReadinessState(); } Readiness Check 的主要流程是依次执行 HealthChecker 和 HealthIndicator 的检查，如果所有健康指标状态均正常，才会执行ReadinessCheckCallback 回调。最后聚合所有指标状态，判断应用是否准备就绪。 健康检查的核心逻辑就在三个处理器HealthCheckerProcessor、HealthIndicatorProcessor和AfterReadinessCheckCallbackProcessor中，接下来我们依次分析一下。\nHealthCheckerProcessor 首先看一下 HealthChecker 接口为开发者提了哪些方法：\n 方法签名 说明 Health isHealthy() 指标项检查，返回值标识指标项状态是否正常 String getComponentName() 指标项名称 int getRetryCount() 失败重试次 …","date":1655276400,"description":"源码解析 | SOFABoot HealthCheck 机制解析","dir":"projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"33693ca9474cc5e3a509fca7935b1cbb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","publishdate":"2022-06-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","summary":"前言 spring-boot-starter-actuator模块为 Spring Boot 应用提供了监控能力，内置一系列健康指标，如数据源、磁盘空间等，并且允许","tags":["“源码解析”"],"title":"源码解析：SOFABoot HealthCheck 机制解析","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/","wordcount":5393},{"author":null,"categories":"SOFAStack","content":" 文｜严松（花名：井守）\nNydus 镜像开源项目 Maintainer蚂蚁集团技术专家\n蚂蚁集团基础设施研发，专注云原生镜像与容器运行时生态\n本文 7060 字 阅读 15 分钟\n｜前言｜ 容器镜像是云原生的基础设施之一，作为容器运行时文件系统视图基础，从它诞生到现在，衍生出了镜像构建、存储、分发到运行时的整个镜像生命周期的各种生态。\n然而，虽然镜像生态众多，但自它诞生以来，镜像设计本身并没有多少改进。这篇文章要探讨的就是对容器镜像未来发展的一些思考，以及 Nydus 容器镜像的探索和实践。\n读完这篇文章，你能够了解到：\n- 容器镜像的基本原理，以及它的组成格式；\n- 目前的镜像设计有哪些问题，应该如何改进；\n- Nydus 容器镜像做了哪些探索，以及怎么实践。\nPART. 1 容器镜像 OCI 容器镜像规范 容器提供给了应用一个快速、轻量且有着基本隔离环境的运行时，而镜像提供给了容器 RootFS，也就是容器内能看到的整个 Filesystem 视图，其中至少包括了文件目录树结构、文件元数据以及数据部分。镜像的特点如下：\n- 易于传输，例如通过网络以 HTTP 的方式从 Registry 上传或下载；\n- 易于存储，例如可以打包成 Tar Gzip 格式，存储在 Registry 上；\n- 具备不可变特性，整个镜像有一个唯一 Hash，只要镜像内容发生变化，镜像 Hash 也会被改变。\n早期的镜像格式是由 Docker 设计的，经历了从 Image Manifest V1[1]、V2 Scheme 1[2]到 V2 Scheme 2[3]的演进。后来出现了诸如 CoreOS 推出的其他容器运行时后，为了避免竞争和生态混乱，OCI 标准化社区成立。它定义了容器在运行时、镜像以及分发相关的实现标准，我们目前用的镜像格式基本都是 OCI 兼容的。\n镜像主要是由镜像层和容器配置两大部分组成的。\n什么是镜像层？\n可以回想下平时写的 Dockerfile 文件：每条 ADD、COPY、RUN 指令都可能会产生新的镜像层，新层包含的是在旧层的基础上，新增加或修改的文件 （包含元数据和数据） ，或被删除的文件 （用称之为  Whiteout **[4] 的特殊文件表示删除） 。\n所以简单来说镜像的每一层存储的是 Lower 与 Upper 之间的 Diff，非常类似 Git Commit。这层 Diff 通常会被压缩成 Tar Gzip 格式后上传到 Registry。\n在运行时，所有 Diff 堆叠起来后，就组成了提供给容器的整个文件系统视图，也就是 RootFS。镜像的另外一部分是容器运行时配置，这部分包含了命令、环境变量、端口等信息。\n镜像层和运行时配置各自有一个唯一 Hash （通常是 SHA256） ，这些 Hash 会被写进一个叫 Manifest[5]的 JSON 文件里，在 Pull 镜像时实际就是先拉取 Manifest 文件，然后再根据 Hash 去 Registry 拉取对应的镜像层/容器运行时配置。\n目前的镜像设计问题 第一，我们注意到镜像层需要全部堆叠后，容器才能看到整个文件系统视图，所以容器需要等到镜像的每一层都下载并解压之后才能启动。有一篇 FAST 论文研究分析[6]说镜像拉取占了大约容器 76% 的启动时间，但却只有 6.4% 的数据是会被容器读取的。这个结果很有趣，它激发了我们可以通过按需加载的方式来提高容器启动速度。另外，在层数较多的情况下，运行时也会有 Overlay 堆叠的开销。\n第二，每层镜像是由元数据和数据组成的，那么这就导致某层镜像中只要有一个文件元数据发生变化，例如修改了权限位，就会导致层的 Hash 发生变化，然后导致整个镜像层需要被重新存储，或重新下载。\n第三，假如某个文件在 Upper 层里被删除或者被修改，旧版本文件依然留存在 Lower 层里不会被删除。在拉取新镜像时，旧版本还是会被下载和解压，但实际上这些文件是容器不再需要的了。当然我们可以认为这是因为镜像优化做的不够好，但在复杂场景下却很难避免出现这样的问题。\n第四，镜像 Hash 能够保证镜像在上传和下载时候的不可变，但在镜像被解压落盘后，很难保证运行时数据不被篡改，这也就意味着运行时的数据是不可信的。\n第五，镜像是以层为基本存储单位，数据去重是通过层的 Hash，这也导致了数据去重的粒度较粗。从整个 Registry 存储上看，镜像中的层与层之间，镜像与镜像之间存在大量重复数据，占用了存储和传输成本。\n镜像设计应该如何改进 我们看到了 OCI 镜像设计的诸多问题，在大规模集群场景下，存储与网络负载压力会被放大，这些问题的影响尤为明显，因此镜像设计急需从格式、构建、分发、运行、安全等各方面做优化。\n首先，我们需要实现按需加载。 在容器启动时，容器内业务 IO 请求了哪些文件的数据，我们再从远端 Registry 拉取这些数据，通过这种方式，可以避免镜像大量数据拉取阻塞容器的启动。\n其次，我们需要用一个索引文件记录某个文件的数据块在层的 Offset 偏移位置。 因为现在的问题是，Tar 格式是不可寻址的，也就是说需要某个文件时，只能从头顺序读取整个 Tar 流才能找到这部分数据，那么我们自然就想到了可以用这种方式来实现。\n接着，我们改造层的格式以支持更简单的寻址。 由于 Tar 是会被 Gzip 压缩的，这导致了就算知道 Offset 也比较难 Unzip。\n我们让原来的镜像层只存储文件的数据部分 （也就是图中的 Blob 层） 。Blob 层存储的是文件数据的切块 （Chunk） ，例如将一个 10MB 的文件，切割成 10 个 1MB 的块。这样的好处是我们可以将 Chunk 的 Offset 记录在一个索引中，容器在请求文件的部分数据时，我们可以只从远端 Registry 拉取需要的一部分 Chunks，如此一来节省不必要的网络开销。\n另外，按 Chunk 切割的另外一个优势是细化了去重粒度，Chunk 级别的去重让层与层之间，镜像与镜像之间共享数据更容易。\n最后，我们将元数据和数据分离 。 这样可以避免出现因元数据更新导致的数据层更新的情况，通过这种方式来节省存储和传输成本。\n元数据和 Chunk 的索引加在一起，就组成了上图中的 Meta 层，它是所有镜像层堆叠后容器能看到的整个 Filesystem 结构，包含目录树结构，文件元数据，Chunk 信息等。\n另外，Meta 层包含了 Hash 树以及 Chunk 数据块的 Hash，以此来保证我们可以在运行时对整颗文件树校验，以及针对某个 Chunk 数据块做校验，并且可以对整个 Meta 层签名，以保证运行时数据被篡改后依然能够被检查出来。\n如上所述，我们在 Nydus 镜像格式中引入了这些特性，总结下来如下：\n- 镜像元数据和数据分离，用户态按需加载与解压；\n- 更细粒度的块级别数据切割与去重；\n- 扁平化元数据层 （移除中间层） ，直接呈现 Filesystem 视图；\n- 端到端的文件系统元数据树与数据校验。\nPART. 2 Nydus 解决方案 镜像加速框架 Nydus 镜像加速框架是 Dragonfly[7] …","date":1655190000,"description":"容器镜像是云原生的基础设施之一，虽然镜像生态众多，但自它诞生以来，镜像设计本身并没有多少改进。这篇文章要探讨的就是对容器镜像未来发展的一些思考，以及 Nydus 容器镜像的探索和实践。","dir":"blog/nydus-exploratory-practice-of-next-generation-container-images/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"66c30936f5c0aa0e2bdf61ffdb88288e","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","publishdate":"2022-06-14T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","summary":"文｜严松（花名：井守） Nydus 镜像开源项目 Maintainer蚂蚁集团技术专家 蚂蚁集团基础设施研发，专注云原生镜像与容器运行时生态 本文 7060 字 阅读 15 分","tags":["SOFAStack"],"title":"Nydus —— 下一代容器镜像的探索实践","type":"blog","url":"/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/","wordcount":8779},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@有时候 提问：\n SOFARPC 注册服务和订阅服务用到的 interface，Java 类文件内容是一样的，但如果包路径不是完全一样有问题么？\n A：路径不一样就是不同接口，注册中心不感知到 method 这层。dataid 不一样的，https://www.sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/ 。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n2.@啥也不是 提问：\n 大佬们，在现有协议拓展框架下，在 choose host 以后根据节点信息动态选择上游的协议，实现起来感觉不是很方便，有大佬指点一下吗？\n A：你是上下游协议不一样吗？\n 是的，而且同一个集群里面协议也可能不一样。我们自己的 RPC 协议存在多个版本，上下游的版本我们没办法控制，想着每个版本分别作为一种协议，利用框架能力，让协议版本的选择跟序列化解偶，每个 host 的版本是通过我们自己配置中心获取的。cluster 中 host 协议版本不受我们控制。\n A：Upstream 的协议本来就是在 filter 里面转换，你在 choose host 之后进行 filter 设置就行了。这个是一个协议转换框架 filter，根据配置的协议转换，你可以复用这个，区别就是 upstream 的协议是动态指定的，但没有本质区别：https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ftranscoder\n「MOSN」https://github.com/mosn/mosn\n3.@曹飞 提问：\n 大佬，监控指标可以显示到应用维度吗？ A：Metric 可以自定义输出的。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 ID API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 Wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 蚂蚁集团获得 OpenInfra Superuser 2022 年度大奖！\n KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境\n 如何看待 Dapr、Layotto 这种多运行时架构？\n GLCC 首届编程夏令营｜欢迎报名 Layotto、KusionStack、Nydus、Kata Containers！\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1654844400,"description":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220610/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2b864568ab02c9da5090b213d0ff984a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220610/","publishdate":"2022-06-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220610/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | C 位大咖说、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220610/","wordcount":1483},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#28:SOFAArk 类隔离框架设计\n 活动时间：06 月 09 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#28 SOFAArk 类隔离框架设计 SOFAArk 是一款基于 Java 实现的轻量级类隔离框架，主要提供类隔离、动态部署、合并部署能力。本次分享将用 30 分钟的时间，带你深入 SOFAArk 框架，一起剖析其技术背景及设计思想，并展望其未来的发展趋势。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 张冯君（花名：远远）\n 蚂蚁集团开发工程师\n 负责蚂蚁集团 SOFAArk 框架方向的相关工作\n 议程 直播回放 https://www.bilibili.com/video/BV1gS4y1i7Fg/?vd_source=65cf108a3fb8e9985d41bd64c5448f63\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1654758000,"description":"2022 年 6 月 09 日 19：00 - 20：00 ，线上直播第 28 期。","dir":"activities/sofa-channel-28/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bfe5796985a7bfb85eb7b19614b05a57","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-28/","publishdate":"2022-06-09T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-28/","summary":"概要 活动主题：SOFAChannel#28:SOFAArk 类隔离框架设计 活动时间：06 月 09 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B","tags":["SOFAChannel","SOFAArk","类隔离框架"],"title":"SOFAChannel#28 SOFAArk 类隔离框架设计","type":"activities","url":"/sofastack.tech/activities/sofa-channel-28/","wordcount":452},{"author":null,"categories":"SOFAStack","content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团高级技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n本文 2580 字 阅读 6 分钟\n｜前言｜ 本文撰写于 KusionStack 开源前夕，作者有感而发，回顾了团队从 Kusion 项目开发之初到现今成功走上开源之路的艰辛历程。当中既描述了作者及其团队做 Kusion 项目的初心和项目发展至今的成果，也表达了作者自身对团队的由衷感激，字里行间都散发着真情实感。\nKusionStack 是什么？\nKusionStack 是开源的可编程云原生协议栈！\nKusion 一词来源于 fusion （意为融合） ，希望通过一站式的技术栈融合运维体系的多个角色，提升运维基础设施的开放性、扩展性，从整体上降本增效。KusionStack 通过定义云原生可编程接入层，提供包括配置语言 KCL、模型界面、自动化工具、最佳实践在内的一整套解决方案，连通云原生基础设施与业务应用，连接定义和使用基础设施的各个团队，串联应用生命周期的研发、测试、集成、发布各个阶段，服务于云原生自动化系统建设，加速云原生落地。\nPART. 1 为了一个理想的运维体系 2019 年秋，MOSN 的工作已持续了近两年，期间我们逐步完成了在支付宝核心链路的形态验证。整个过程中除了 MOSN 本身面对的种种技术挑战和困难，所谓的云原生技术红利，实际上也已经掣肘于运维系统固化所造成的效率制约。\n有一天主管找我吃饭 （下套） ，期间向我描述了他理想中的运维体系：\n他希望 SRE 能通过一种专用语言来编写需求，通过写代码来定义基础设施的状态，而不是花费极大的精力在检查、发现、修复的循环上。基础设施团队则通过提供开放的可编程语言和工具支撑不同诉求的 SRE 团队，达到更高的整体 ROI。\n我立刻意识到这和 Hashicorp 的 Terraform 神之相似 （后来 Hashicorp 在 2021 年底上市，以超过 150 亿美元的市值成为迄今为止市值最高的一次开源 IPO） 。另一方面，不同于 IaaS 交付场景，蚂蚁面对着大量更规模化、复杂度更高的云原生 PaaS 场景，又让我想到了 Google 内部运用专用语言、工具等技术开放 Borg[1]运维能力的实践[2]，当时感觉这是一个既有意思又有挑战的事[3]。\n饭桌上我们聊了一些思路以及一些还不太确定的挑战，他问我想不想搞一个试试，搞不成也没关系。当时没想太多，饭没吃完就答应了。\nPART. 2 漫长的学习、探索与实践 隔行如隔山。\n没有过语言设计研发的经验，也没有过开放自动化系统设计的经验，项目开展之初，我们就陷入了举步维艰的困境。\n经历了一段漫长时间的学习、摸索和实践的反复循环之后，项目依旧没有大的起色，更困难的是我们不但要面对蚂蚁内部复杂又耦合的场景和问题，还要经受「这种高度工程化的方式在蚂蚁是否有生存土壤」的质疑。\n屋漏偏逢连夜雨，期间又令人惋惜且无奈的经历了一些人事变化，同时由于种种原因，项目一度陷入了各种困境。整个 2020 年，我们在未知、纠结、无奈中度过……\n感谢瓴熙、庭坚和我的主管，感谢你们当时没有放弃这个项目，依然与我一同坚守。\nPART. 3 痛并快乐的孵化之旅 通过持续地布道、交流和沟通，我们逐步在基础设施技术团队和 SRE 团队找到了更多有共识的朋友。\n同时在技术上，我们亦脱离了迷茫，真正意义上地启动了 Kusion 项目，也成功地从 PoC 过渡到了 MVP 的阶段。\n最终，我们以“非标”应用为切入点，开始了痛并快乐着的孵化之旅。\n感谢零执、青河、子波、李丰、毋涯、向野、达远……在这里无法一一列举，感谢你们的坚持让这个想法逐步成为现实。\nPART. 4 突破与进展 略过中间的种种探索和实践，回顾这段历程，在这一年多的时间里我们结合了编译技术、运维及平台技术，成功建立了一个基于 Kusion 可编程技术栈的运维体系。\n在业务场景上，项目覆盖了从 IaaS 到 SaaS 的大量运维场景，截至目前共接入了 800+ 应用，覆盖 9 个 BG，21 个 BU，其中典型案例交付运维提效 90% 以上，这也是蚂蚁内部第一次将大量异构应用纳入到一整套运维技术栈。\n在蚂蚁我们基于云原生容器和微服务技术深入探索了 DevOps、CICD 实践，完善了蚂蚁的云原生技术体系，逐步释放了云原生效率红利，同时形成了一个近 300 人的虚拟运维研发团队。\n不同职能不同团队的参与者凝聚在一起解决各自所面对的问题，贡献了 3W+ commit 和 35W+ 行代码，有一些参与者自发成为 Kusion 的研发者 。我认为这些工程师文化理念和领域知识的积累带来了远超运维业务本身的价值。\n此外，Kusion 也成为了可编程基线产品、云原生运维产品、多云交付产品等新一代运维产品的基础技术，成为蚂蚁运维体系架构升级的一部分。\n不忘初心，我们希望通过技术手段促进与运维参与方的合作关系的合理化、基于开放技术栈的自动化，以及运维数据与知识的沉淀积累，以达到整体协作运维效率的不断提升。\n同时，因蚂蚁内部运维场景较多且链路复杂，每个环节都需要最懂运维业务的 SRE 密切参与，与平台、应用研发协同工作，最终各环节联合在一起形成了一套完整的运维体系，在这样的思路下开放技术也会越来越重要。\n平台研发、SRE、应用研发等多种角色协同编写的代码是一种数据的沉淀，亦是一种业务知识的沉淀，基于这些数据和知识，未来会有更多的可能性。\nPART. 5 走上开源之路 在历经了一段内部探索之后，我们希望把 KusionStack 开源到技术社区。因为我们意识到自身面对的问题，其他公司、团队其实也同样正在面对。借助开源这件事，我们希望团队的这些工作成果能对更多人有所帮助。\n当然，也受限于自身能力以及精力和资源的投入，我们希望能有更多朋友参与进来，与我们共同去完善 KusionStack，不论你是工作在云原生、运维自动化、编程语言或者是编译器中的哪一个领域，我们都非常期待和欢迎你的加入。\nPART. 6 期待与你共成长 这段经历对我来说异常宝贵，不仅仅是在于自身再一次在新的技术领域和蚂蚁的技术升级方面尝试了新的探索并实现了突破，更宝贵的是，自己还拥有了一段与一群人均 95 后的小伙伴一起将想法落地实现的奇幻历程。\n在未来， Kusion 的朋友圈不再局限于蚂蚁内部，面向开源，我们期待着能有更多的社区朋友在 KusionStack 与我们共同成长！\n了解更多\u0026amp;hellip;\nKusionStack Star 一下✨：\nhttps://github.com/KusionStack\nKusionStack 的开源，希望能对大家有所帮助，也希望能跟更多朋友共同完善 KusionStack。欢迎对云原生、运维自动化、编程语言、编译器感兴趣的同学一起参与社区共建，在新的技术领域升级方面进行探索和突破，实现更多新的想法。\n点击文末阅读原文直达项目地址。\n【参考链接】\n[1]《Large-scale cluster management at Google with …","date":1654585200,"description":"KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境","dir":"blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"688d35ea65772596c3a0115a62a63b53","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","publishdate":"2022-06-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","summary":"文｜朵晓东（花名：奕杉 ) KusionStack 负责人、蚂蚁集团高级技术专家 在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作 本文 2580 字 阅读 6 分钟 ｜前","tags":["SOFAStack"],"title":"KusionStack 开源有感｜历时两年，打破“隔行如隔山”困境","type":"blog","url":"/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/","wordcount":2772},{"author":"周群力","categories":"SOFAStack","content":" 文｜周群力（花名：仪式 )\nLayotto PMC；Layotto 和 SOFAStack 开源社区的建设，Dapr 贡献者，Dapr sig-api 的 Co-chair\n本文 10963 字 阅读 20 分钟\n2019 年，微软开源了 Dapr 项目。2021 年，蚂蚁参照 Dapr 思想开源了 Layotto 项目。如今，蚂蚁已落地 Layotto，服务了很多应用。从理想落地到现实的过程中，我们遇到了不少问题，也对项目做了很多改变。回过头再看，如何看待 Dapr、Layotto 这种多运行时架构？我们能从中学到什么？\n本次我将从以下几个方面，分享蚂蚁在落地多运行时架构之后的思考：\n1. 如何看待“可移植性”\n2. 多运行时架构能带来哪些价值\n3. 与 Service Mesh、Event Mesh 的区别\n4. 如何看待不同的部署形态\nPART. 1 快速回顾\n如果你熟悉 Multi-Runtime、Dapr 和 Layotto 的概念，可以跳过这一章节，直接进入下一章节。\n快速回顾：什么是 Multi-Runtime 架构？\nMulti-Runtime 是一种服务端架构思路，如果用一句话来概括，就是把应用里的所有中间件挪到 Sidecar 里，使得“业务运行时”和“技术运行时”分离开。\n更详细的解释如下：首先来看 Service Mesh，和传统 RPC 框架相比，Service Mesh 的创新之处在于引入了 Sidecar 模式。Service Mesh 只解决了服务间通讯的需求，而现实中的分布式应用存在更多需求，比如“协议转换”、“状态管理”等。Multi-Runtime 架构提出将各种各样的分布式能力外移到独立 Runtime，最后和应用 Runtime 共同组成微服务，形成所谓的“Multi-Runtime” （多运行时） 架构。\n具体细节可以详阅《Multi-Runtime Microservices Architecture》和《Mecha：将 Mesh 进行到底》。\n哪些项目实现了 Multi-Runtime 架构？\nDapr\nDapr 的全称是“Distributed Application Runtime”，即“分布式应用运行时”，是一个由微软发起的开源项目。\nDapr 项目是业界第一个 Multi-Runtime 实践项目，Dapr 的 Sidecar，除了可以和 Service Mesh 一样支持服务间通讯，还可以支持更多的功能，如 state （状态管理） 、pub-sub （消息通讯） ，resource binding （资源绑定，包括输入和输出） 。Dapr 将每种功能抽象出标准化的 API （如 state API） ，每个 API 都有多种实现，比如用户可以面向 state API 编程，但是可以随意切换存储组件，今年用 Redis，明年改成用 MongoDB，业务代码不用改。\n如果之前没有接触过 Dapr，更详细的介绍可以阅读《Dapr v1.0 展望：从 Service Mesh 到云原生》这篇文章。\nLayotto\nLayotto 是由蚂蚁集团 2021 年开源的一个实现 Multi-Runtime 架构的项目，核心思想是在 Service Mesh 的数据面（MOSN里支持 Dapr API 和 WebAssembly 运行时，实现一个 Sidecar 同时作为 Service Mesh 数据面、多运行时 Runtime、FaaS 运行时。项目地址为：https://github.com/mosn/layotto\n以上是本文背景，接下来是本次主题分享。\nPART. 2 你真的需要这种“可移植性”吗？\n社区比较关注 Dapr API 的“可移植性”，但在落地过程中，我们不禁反思：你真的需要这种“可移植性”吗？\n标准化 API 能满足所有需求吗？\n数据库领域曾出现过一个有趣的讨论：同一个数据库能否适用于所有场景，满足所有需求？ 比如，一个数据库能否同时支持 OLAP+OLTP+ACID 等等需求？\n今天，我们在建设 Dapr API 的过程中也遇到了有趣的问题：在某个产品领域 （比如消息队列） ，能否定义一套“标准 API”同时适用于所有的消息队列？\n当然，这两个问题不能混为一谈：即使是两种不同类型的数据库，比如两个数据库，一个只做 OLAP，另一个只做 OLTP，它们都可以支持 SQL 协议。两个差距那么大的数据库都能用同样的协议，我们有理由相信：在特定领域，设计一个适用于所有产品的“标准 API”是可行的。\n可行，但现在还不完全行。\n现在的 Dapr API 还比较简单，简单场景足以胜任，但在复杂的业务场景下，做不到“帮助应用 Write once,run on any cloud”。对这个问题，敖小剑老师的文章《死生之地不可不察：论 API 标准化对 Dapr 的重要性》有过详细描述，大意是说：\n现在的 Dapr API 比较简单，在生产落地的时候满足不了复杂需求，于是开发者只能添加很多自定义的扩展字段，在 Sidecar 的组件里做特殊处理。比如下面是用 State API 时候的一些自定义扩展字段：\n（图片摘自敖小剑老师的文章）\n这些自定义的扩展字段会破坏可移植性：如果你换一个组件，新组件肯定不认识这些字段，所以你得改代码。\n之所以出现这个问题，背后的根本原因是 Dapr API 的设计哲学。\n社区在设计 Dapr API 时，为了可移植性，设计出的 API 倾向于 “功能交集” 。比如在设计 Configuration API 时，会考察各种配置中心 A、B、C，如果 A、B、C 都有同一个功能，那么这个功能才会出现在 Dapr API 中：\n然而，在现实世界中，人们的需求可能是 A 和 B 的交集，B 和 C 的交集 （如下图红色部分） ，而不是 A、B、C 的交集：\n或者更常见，用户的需求是“B 的所有功能”，其中必然包括一些 B 独有的功能，Dapr API 无法覆盖：\nDapr 提供“标准 API”、“语言 SDK”和“Runtime”，需要应用进行适配 （这意味着老应用需要进行改造） ，侵入性比较大。\n因此 Dapr 更适合新应用开发 （所谓 Green Field） ，对于现有的老应用 （所谓 Brown Field） 则需要付出较高的改造代价。但在付出这些代价之后，Dapr 就可以提供跨云跨平台的可移植性，这是 Dapr 的核心价值之一。\n这些听起来是解决不了的问题。那怎么办？\n跨云部署时，你真的需要从 Redis 换成 Memcached 吗？\n在设计 API 时，常常出现类似的讨论：\nA：嘿，这个功能只有 Redis 和 xxx 有，但是 Memcached 和其他存储系统没有。我们该怎么办，要不要把这个功能纳入 API 规范里？\nB：如果我们把这个功能纳入 API 里，会有什么问题？\nA：那样的话，使用我们 API 的用户就没法从 Redis 迁移到 Memcached 了，这破坏了可移植性！\n等一等……你真的需要从 Redis 换成 Memcached 吗？\n你真的需要这种“可移植性”吗？\n不需要吧！如果 …","date":1653980400,"description":"本文讨论了 Layotto 落地之后，关于 Multi-Runtime 架构“可移植性”、落地价值以及部署形态等方面的思考。","dir":"blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","fuzzywordcount":9200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d0732e32f9b202c205fb1e03b195eb8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","publishdate":"2022-05-31T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","summary":"文｜周群力（花名：仪式 ) Layotto PMC；Layotto 和 SOFAStack 开源社区的建设，Dapr 贡献者，Dapr sig-api 的 Co-chair 本文 10963 字 阅读 20 分钟 2019 年，微软开源了 Dapr 项目。","tags":["SOFAStack"],"title":"如何看待 Dapr、Layotto 这种多运行时架构","type":"blog","url":"/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/","wordcount":9182},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@周衡 提问：\n 请问一下，我需要调度 RPC 的上下文是哪一个类？有一些参数想直接通过上下文传递。\n A：RpcInvokeContextv6\n「SOFARegistry」：https://github.com/sofastack/sofa-rpc\n@bobtthp 提问：\n MOSN 对接 dubbo 目前注册中心支持 zk 吗？\n A：FaaS 示例么？那个还没上过生产，还在探索阶段。支持的，可以参考这个文档：https://www.github.com/mosn/mosn/tree/master/pkg%2Fupstream%2Fservicediscovery%2Fdubbod%2Fcommon.go\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n 深入 HTTP/3（2）｜不那么 Boring 的 SSL\n 【2022 开源之夏】欢迎报名 MOSN 社区项目！\n 蚂蚁集团 Service Mesh 进展回顾与展望\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1653634800,"description":"SOFA Weekly | Kusion 开源啦、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220527/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1f1971d6ef1280f9bc0fa21d099dfd99","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220527/","publishdate":"2022-05-27T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220527/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | Kusion 开源啦、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220527/","wordcount":1025},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#27:深入 HTTP/3｜从QUIC-TLS 看协议的安全设计\n 活动时间：05 月 26 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#27 深入 HTTP/3｜从 QUIC-TLS 看协议的安全设计 安全通信是网络技术中绕不开的话题，而 QUIC 作为目前炙手可热的协议技术，在这上面也理所应当的有着非常多的优秀实践，本次分享将用 50 分钟的时间，带你深入 QUIC-TLS，一起剖析其技术背景及设计思想，并展望其未来的发展趋势。\n当然，本次直播也分享一些蚂蚁自己的工程实践经验及相关的产品。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 曾柯（花名：毅丝）\n 蚂蚁集团高级工程师\n 负责蚂蚁集团的接入层建设工作，主要方向为高性能安全网络协议的设计及优化\n 议程 直播回放 https://www.bilibili.com/video/BV1xg411o7Jo/\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1653634800,"description":"2022 年 5 月 26 日 19：00 - 20：00 ，线上直播第 27 期。","dir":"activities/sofa-channel-27/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cdb2bb81c619db029bb9a62a1374b721","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-27/","publishdate":"2022-05-27T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-27/","summary":"概要 活动主题：SOFAChannel#27:深入 HTTP/3｜从QUIC-TLS 看协议的安全设计 活动时间：05 月 26 日，周四晚 19 点 活动形式：线","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#27 深入 HTTP/3｜从 QUIC-TLS 看协议的安全设计","type":"activities","url":"/sofastack.tech/activities/sofa-channel-27/","wordcount":543},{"author":"曾柯","categories":"SOFAStack","content":" 文｜曾柯（花名：毅丝 )\n蚂蚁集团高级工程师*负责蚂蚁集团的接入层建设工作* 主要方向为高性能安全网络协议的设计及优化\n本文 10924 字，阅读 20 分钟\nPART. 1 引言 从前一篇文章《深入 HTTP/3（1）｜从 QUIC 链接的建立与关闭看协议的演进》对于 QUIC 的浅述中我们了解到，QUIC 的优化很大程度上是一种基于 TLS 流程的优化，由此也可见 TLS 对于 QUIC 的重要性，那么今天我们就来聊一聊 QUIC-TLS。为了表述尽量没有歧义，我们先来规范下文章中各个术语的意义。\n本文目前既然已经提到了 SSL、TLS 这两个术语，我们不妨先来简短回顾下安全协议的发展史，这既可以帮我们理清两个术语的关系，也能帮助我们对这项技术的进化有一个简短的概念。\nSSL (Secure Sockets Layer) 协议本身是网景公司为了保证互联网上数据传输的安全性，在 1994 年设计的一套协议。这套协议在当时被广泛使用在各大浏览器上，但 SSL 协议最初的几个版本安全性都非常堪忧，初期的更迭非常频繁，从 1994 年到 1995 年连续迭代了 3 个大版本，而现在大家最耳熟能详的应该就是 SSLv3.0 了。可惜 SSLv3.0 也没有逃脱更迭的厄运，由于硬件算力的迭代，大量 SSLv3.0 中广泛使用的加密算法不再安全，并且协议交互流程也存在不安全之处。1999 年，IETF 正式介入安全协议的设计及开发，并推出了 TLS (Transport Layer Security) 协议的第一个版本 TLS1.0，随后 TLS 协议的发展开始变得迟缓，在 2006 年 IETF 组织推出了 TLS1.1，并在 2008 年再次发布了 TLS1.2，两个版本都是针对一些握手交互过程中的细节的安全提升，握手流程其实是没有大的变化的。\n直到 2013 年，Google 在推出 gquic 的同时，也推出了其设计的安全交互流程 quic-crypto，quic-crypto 是一次交互流程的重大创新，也以此成为了 TLS1.3 的前身。TLS1.3 从某种意义上来说，应该被称作 TLS2.0，因为其革新力度非常大，当然这也导致其标准化流程非常长，TLS1.3 的标准化整整历经了 4 年，直到 2018 年才正式成为 RFC。而 TLS1.3 本身也成为了 IETF-QUIC 的安全交互技术的基础，所以这条时间线里也揉杂了 QUIC-TLS 的设计历程，我们来简单理一下：\n图 1. TLS 发展简史\n当然 DTLS 等相关安全技术的进化也融合在这条时间线中，限于篇幅问题，这里暂时不表。说了这么多废话，我们现在来正式标准化一下我们的名词：\n【SSL、TLS】 ：在本文中都指安全传输协议，后续的文章中只会使用 TLS 作为相关技术的代名词\n【QUIC-crypto】 ：Google quic 中使用的握手流程，本文不对其进行具体分析\n【QUIC-TLS】 ：本文指 IETF-QUIC 使用的安全交互流程，即 RFC9001 中标准化的流程，也是本文详细描述的重点\n【PTO】 ：全称为 Probe Timeout，定义于 RFC9002 中，留待下一篇文章来对其进行详细分析，本文将其理解成一个通信端设置的针对报文的超时重传的时间即可\n【DTLS】 ：全称为 Datagram Transport Layer Security，即面向报文的 TLS 协议，限于篇幅的问题，本文并不详细对其分析，而 DTLS 中存在有很多和 QUIC-TLS 类似思路的设计，感兴趣的同学可以参见 RFC9147\n“make infrastructure boring”是 Google 一直以来的口号，BoringSSL 这个开源产品则是他们在安全通信领域的行动，而文章的标题既然叫“不那么 Boring 的 SSL”，除了蹭一蹭 BoringSSL 和 OpenSSL 这些著名的 SSL 开源项目的热度之外，也是想给文章制造一点悬念：Boring 往往意味着相关技术简单好用到了令人发指的地步，而 QUIC 到底遇见了什么问题，才让本身相对成熟的 TLS 协议用起来不再 Boring？\n本文后续也将围绕这个话题展开，来看看 QUIC-TLS 设计中那些值得玩味的地方。\nPART. 2 浅看 TLS 本着由浅入深的思路，在开始介绍 QUIC-TLS 之前，我们也先浅析一下 TLS，这也非常有助于我们后面对于 QUIC-TLS 的理解。\nTLS 协议从某种程度上来说解决了几个哲学问题：你是谁？你怎么证明你是你？\n当然这些问题的答案还不足以保证整个的安全\u0026amp;hellip;\n1. 我们还需要一种技术来保证中间人无法获取到我们的数据，这也就是我们相对比较熟悉的 「对称加密技术」，比如 AES、SM4 等加密技术；\n2. 为了加密的数据也能证明通信一端的身份，我们引入了 「AEAD 加密即认证的模式」；\n3. 为了协商出这种对称加密的密钥，TLS 引入了 「非对称密钥交换技术」，典型如 ECDHE、RSA 等密钥交换算法；\n4. 为了身份管理的统一及身份的有效携带，TLS 引入了 「数字证书技术」，包括整个 pki 公钥体系及 X509 数字证书标准；\n5. 为了数据的不可篡改，TLS 引入了 「数字签名技术」，典型如 ECDSA、RSA 等签名算法；\n6. 为了各个阶段的加密密钥独立及签名流程的简洁，TLS 引入了 「Hash 算法」，典型如 SHA 系列算法。\n上述的各种机制再整个 TLS 协议中被抽象为两部分协议：\n一层是 Handshake 协议，负责核心密钥的交互及身份认证；一层是 Record 协议，负责数据的安全，完整性及握手完成后数据的可信证明，而 Handshake 协议则坐落于 Record 协议之上，这也就形成了这样的协议栈。\n图 2. TLS 协议栈简图\n简而言之，Handshake 过程中的数据也依赖 Record 层来进行数据加密，而 Record 层加密的 key 则依赖 Handshake 层进行交互得到。这看似是个逻辑死锁，实际上是通过一个层层递进的状态机完成的，抛开繁琐的 TLS 状态机本身，这个流程基本可以用下图来表述：\n图 3. TLS 密钥状态更新流程图\n至于 TLS 的初始阶段使用明文传输的数据，也并不违背这个流程，我们可以将其理解为 TLS 初始阶段对应一个值为空的 key。而从上图中我们也可以看到，实现和虚线部分对应的两个阶段切换，必须有严格的先后顺序，如果发生乱序，一端是无法完成数据的解析的，所以 TLS 协议非常依赖底层传输协议来保证数据的有序到达，而这也是 TLS 的设计区别于 DTLS 和 QUIC-TLS 的最大根因之一。有了这部分知识储备，我们再来看 TLS 的握手 (以 TLS1.3 的 0-RTT 交互场景为例) ，就会清晰很多：\n图 4. TLS 握手流程图\n可以看到，明文\u0026amp;rdquo;()\u0026amp;ldquo;,\u0026amp;rdquo;{}\u0026amp;ldquo;,\u0026amp;rdquo;[]\u0026amp;ldquo;对应的加密状态的切换，和上面的图的流程基本是一致的，而典型如 EndOfEarlyData 这种标 …","date":1653375600,"description":"深入 HTTP/3（2）｜不那么 Boring 的 SSL","dir":"blog/deeperinto-http-3-2-the-not-so-boring-ssl/","fuzzywordcount":9500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e7a8be2c91c093af30cba5045b0b6516","permalink":"https://sofastack.github.io/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","publishdate":"2022-05-24T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","summary":"文｜曾柯（花名：毅丝 ) 蚂蚁集团高级工程师*负责蚂蚁集团的接入层建设工作* 主要方向为高性能安全网络协议的设计及优化 本文 10924 字，阅读 20 分钟 PART. 1 引言","tags":["SOFAStack"],"title":"深入 HTTP/3（2）｜不那么 Boring 的 SSL","type":"blog","url":"/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/","wordcount":9435},{"author":null,"categories":"SOFA Weekly","content":" SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@林楠 提问：\n SOFARegistry 使用数据库做存储，未来有没有计划做一个简洁版，不依赖数据库？\n A：v6 使用存储主要是存放元数据而不是服务数据，元数据存储接口未来计划使用 jraft 作为存储。这也是 v5—\u0026amp;gt;v6 的过程中去掉的一个功能，因为在内部，引入 jraft 有一定运维成本，需要 operator 这种非标组件。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@jiaxin shan 提问：\n 想知道 Layotto 的成熟案例，有没有一些大公司进行使用呢？体量是多少？1.miscro-service 方向 2.FaaS 方向也有一些落地实例吗？\n A：目前蚂蚁在生产环境使用，另外也有某大厂准备上测试环境了。官网的 WASM 跑 FaaS 示例么？那个还没上过生产，还在探索阶段。\n 我理解目前像 FaaS、WASM 等更多是从社区角度，开源侧进行牵引，慢慢孵化一些场景？\n A：对，结合 WASM 做 FaaS 是开源社区探索方向；其他的 runtime、service mesh 属于生产需求驱动，更严肃一些。属于蚂蚁发起、社区共建，如果担心独裁，可以关注下 contributor 数、月活跃贡献者数这些指标，现在活跃贡献者有腾讯、同程等公司的朋友，3个 committor 都不是蚂蚁的。我们每周五有社区周会，你感兴趣可以来聊聊。钉钉群码：41585216\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 【2022 开源之夏】欢迎报名 SOFAStack 社区项目！\n 恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n 【2022 开源之夏】欢迎报名 MOSN 社区项目！\n 蚂蚁集团 Service Mesh 进展回顾与展望\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1653030000,"description":"SOFA Weekly | 我是开源人、本周 QA、本周 Contributor","dir":"blog/sofa-weekly-20220520/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"27d18203e02fa487e39f1f9e1032271d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220520/","publishdate":"2022-05-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220520/","summary":"SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微","tags":["SOFA Weekly"],"title":"SOFA Weekly | 我是开源人、本周 QA、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220520/","wordcount":1274},{"author":"石建伟","categories":"SOFAStack","content":" 一、引言 继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么，值此 SOFAStack 开源 4 周年之际，欢迎大家一起进入《蚂蚁集团 Service Mesh 进展回顾与展望》章节探讨交流。\n本次交流将以如下次序展开：\n二、蚂蚁集团 Service Mesh 发展史 2018 年 3 月份蚂蚁集团的 Service Mesh 起步，MOSN 数据面诞生，起步就坚持走核心开源，内部能力走扩展的道路。 2019 年 6.18 我们在三大合并部署应用上接入了 MOSN 并且顺利支撑了 6.18 大促。 2019 年双 11 蚂蚁所有大促应用平稳的度过双大促。 2020 年 MOSN 对内沉稳发展把接入应用覆盖率提升至 90%，对外商业化开始展露头角。蚂蚁集团全站 90% 标准应用完成 Mesh 化接入。在商业版本中，SOFAStack“双模微服务”架构也在江西农信、中信银行等众多大型金融机构成功落地实践。 2021 年随着 Mesh 化的逐步成熟，多语言场景的逐步丰富，Mesh 化的对中间件协议的直接支撑带来的扩展性问题也逐步凸显，Dapr 的应用运行时概念也逐步崛起，这一年我们开源了 Layotto，期望通过对应用运行时 API 的统一来解决应用和后端中间件具体实现耦合的问题，进一步解耦应用和基础设施，解决应用在多云运行时的厂商绑定问题。 2022 年随着 Mesh 化落地的基础设施能力逐步完善，我们开始考虑 Mesh 化如果给业务带来更多价值，在 Mesh 1.0 时代，我们把中间件相关的能力尽可能做了下沉，提升了基础设施的迭代效率，在 Mesh 2.0 时代，我们期望能有一种机制可以让业务侧相对通用的能力，也可以做到按需下沉，并且具备一定的隔离性，避免下沉的能力影响 Mesh 数据代理主链路。这部分将在看未来部分做一些介绍。 图示的方式简诉一下 Service Mesh 架构演进的几个阶段：\n SOA 时代，中间件的客户端均直接集成在业务进程内： Mesh 化阶段一：中间件能力下沉，应用和基础设施实现部分解耦： 应用运行时阶段：将应用和具体基础设施的类型解耦，仅依赖标准 API 编程： 三、东西向流量规模化挑战 Mesh 化后的数据面 MOSN 承载了应用间非常核心的东西向通信链路，目前在蚂蚁集团内部覆盖应用数千，覆盖容器数十W+，海量的规模带来了如长连接膨胀、服务发现数据量巨大、服务治理困难等问题。接下来我们来聊一聊我们在演进的过程中遇到并解决掉的一些经典问题。\n3.1 长连接膨胀问题 在海量规模的应用背后存在着复杂的调用关系，部分基础性服务被大部分应用所依赖，由于调用方全连服务提供方的机制存在，一个基础性服务的单 Pod 需要日常承载近 10W 长连接，单机 QPS 一般还是有上限的，我们以 1000 QPS 的 Pod 举例，10w 长连接的场景下，每条长连接上的 QPS 是非常低的，假设所有连接的请求均等，平均每条长连接每 100s 仅有一次请求产生。\n为了保证长连接的可用性，SOFA RPC 的通信协议 Bolt 有定义心跳包，默认心跳包是 15s 一次，那么一条长连接上的请求分布大概如下图所示：\n在上诉场景中，一条长连接上，心跳包的请求数量远大于业务请求的数量，MOSN 在日常运行中，用于维护长连接可用句柄持有内存的开销，还有心跳包发送的 CPU 开销，在海量规模集群下不可忽视。\n基于以上问题，我们找到了两个解法：\n 在保证连接可用的前提下减少心跳频率 在保证负载均衡的前提下降低应用间的连接数 3.1.1 心跳退避 由于心跳的主要作用是尽可能早的发现长连接是否已不可用，通常我们认为经过 3 次心跳超时即可判定一条长连接不可用，在一条长连接的生命周期里，不可用的场景占比是非常低的，如果我们把长连接的检测周期拉长一倍就可以减少50%的心跳 CPU 损耗。为了保障检测的及时性，当出现心跳异常（如心跳超时等）场景时，再通过降低心跳周期来提高长连接不可用时的判定效率，基于以上思路我们设计了 MOSN 里的长连接心跳退避策略：\n 当长连接上无业务请求且心跳正常响应时，逐步将心跳周期拉长 15s -\u0026amp;gt; 90s 当长连接上出现请求失败或心跳超时的场景时，将心跳周期重置回 15s 当长连接上存在正常业务请求时，降级本次心跳周期内的心跳请求 通过以上心跳退避的手段，MOSN 的常态心跳 CPU 消耗降低至原来的 25%。\n3.1.2 服务列表分片 从心跳退避的优化可以看出，在海量长连接的场景下，单长连接上的请求频率是很低的，那么维护这么多长连接除了对负载均衡比较友好之外，其他的收益并不大，那么我们还有另外一个优化方向，就是减少客户端和服务端之间建立的长连接数量。\nMOSN 使用一致性哈希的策略对服务端机器进行分组：在客户端的内存中，首先将全量的服务端机器列表加入到一致性哈希环中，然后基于配置计算预期分片情况下的机器列表数 N，随后根据客户端机器 IP，从一致性哈希环中获取 N 个机器列表作为本机器的分片列表。每个客户端计算的哈希环都是一样的，不同的机器 IP 使得最终选择的机器分片列表是不同的。实现了不同客户端机器持有不同的服务端集群分片的效果。\n通过对服务列表的分片优化，客户端向服务端建立的长连接数量急剧减小，在 6w 长连接且采用 50% 的负载均衡分片的场景下：单机 CPU 降低约 0.4 Core，内存降低约 500M。\n3.2 海量服务发现问题 MOSN 的服务发现能力没有使用 Pilot，而是在内部直接和 SOFARegistry（服务注册中心） 对接，使用这种架构的原因之一就是 RPC 的接口级服务发现，节点的 Pub、Sub 量巨大，海量应用的频繁运维产生的节点变更推送对 Pilot 的性能和及时性挑战都很大，社区有使用 Pilot 在稍大规模下做 CDS 下发的过程中也发现非常多的性能问题并提交 PR 解决，但对于蚂蚁集团一个机房就有 200W Pub，2000W Sub 的规模下，Pilot 是完全无法承载的。SOFARegistry 的架构是存储和连接层分离，存储为内存分片存储，连接层也可以无限水平扩容，在内部海量节点变更下也能实现秒级变更推送。\n虽然 SOFARegistry 的推送能力没什么问题，不过海量节点变更后产生的推送数据，会导致 MOSN 内有大量的 Cluster 重构，列表下发后到 Cluster 构建成功的过程中，会有大量的临时内存产生，以及 CPU 计算消耗。这些尖刺型内存申请和 CPU 占用，是可能直接影响请求代理链路稳定性的。为了解决这个问题，我们也考虑过两个优化方向：\n SOFARegistry 和 MOSN 之间把全量推送改造为增量推送 服务发现模型从接口级切换为应用级 其中第一点能带来的效果是每次列表推送变化为原推送规模的 1/N，N 取决于应用变更时的分组数。第二点能带来的变化是更加明显的，我们假设一个应用会发布 20个接口，100个应用的 Pod 产生的服 …","date":1652770800,"description":"继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么，值此 SOFAStack 开源 4 周年之际，欢迎大家一起进入《蚂蚁集团 Service Mesh 进展回顾与展望》章节探讨交流。","dir":"blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8c0eeb7a88e858fcfef4b4c9824ebb3f","permalink":"https://sofastack.github.io/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","publishdate":"2022-05-17T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","summary":"一、引言 继 2019 年的 《蚂蚁金服 Service Mesh 落地实践与挑战》之后，蚂蚁集团在 Service Mesh 方向已经继续探索演进近 3 年，这 3 年里有哪些新的变化，以及对未来的思考是什么","tags":["SOFAStack","Service mesh"],"title":"蚂蚁集团 Service Mesh 进展回顾与展望","type":"blog","url":"/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/","wordcount":5542},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFAMeetup 成都站-云原生技术交流专场\n 活动时间：2022 年 05 月 14 日（周六）14:00-18:00\n 活动形式：线上直播\n 资料下载：\n 《Nydus-面向下一代的容器镜像》\n《云原生应用配置代码化实践》\n活动回顾 直播回放：\nNydus-面向下一代的容器镜像\n云原生应用配置代码化实践\n活动议程 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1652511600,"description":"SOFAMeetup 成都站-云原生技术交流专场","dir":"activities/sofa-meetup-15/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f637fdc7cae0e17bb6c6cf1302cd7f80","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-15/","publishdate":"2022-05-14T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-15/","summary":"概要 活动主题：SOFAMeetup 成都站-云原生技术交流专场 活动时间：2022 年 05 月 14 日（周六）14:00-18:00 活动形式：线上直播 资料","tags":["SOFA"],"title":"【活动回顾】《SOFAMeetup 成都站-云原生技术交流专场》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-15/","wordcount":211},{"author":null,"categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@曹飞提问：\n MOSN 集成 prometheus 是怎么使用呢？看到读取相应配置，是在自定义配置里面吗？\n A：你可以自定义收集指标，然后通过 promoetheus 格式输出。在配置加这个 metric 的就行了。https://github.com/mosn/mosn/blob/f3248bf2ed6c5d13635e8ce4af921f665ccdf96c/configs/mosn_config_dev.json#L69\n「MOSN」：https://github.com/mosn\n@沈冰 提问：\n SOFAArk 2.0 怎么创建 ark-plugin? 使用的场景是做类隔离。\n A：当前这个还和 1.0 的使用方式一致的，完全按照 1.0 的方式来。https://developer.aliyun.com/article/625338\n「SOFAArk」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto v0.4.0 版本 发布 Layotto v0.4.0 版本，主要变更如下：\n1.文件能力增加了七牛云 oss、hdfs、腾讯云 oss 的实现；\n同时增加了Java SDK 的实现\n2.支持 API 插件和自定义组件能力\n3.支持 SkyWalking\n4.支持基于内存的和 mongo 的分布式锁和分布式自增 ID\n5.支持 secret 接口\n6.支持 Dapr 的 state、InvokeService、InvokeBinding API\n7.优化了当前 CI 流程\n7.修复及优化若干 bug\n详细发布报告:https://github.com/mosn/layotto/releases/tag/v0.4.0\n本周推荐阅读 【2022 开源之夏】欢迎报名 SOFAStack 社区项目！\n 恭喜 黄章衡 成为 SOFAJRaft committer！（附赠开源之夏攻略）\n SOFAServerless 体系助力业务极速研发\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1652425200,"description":"SOFA Weekly | Layotto v0.4.0 版本发布、开源之夏项目讲解、本周 Contributor","dir":"blog/sofa-weekly-20220513/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0d42b166bf83ba9a3cc657d29b0b64b2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220513/","publishdate":"2022-05-13T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220513/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto v0.4.0 版本发布、开源之夏项目讲解、本周 Contributor","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220513/","wordcount":1311},{"author":"Webster-Yang","categories":"SOFAStack","content":" 背景 SOFARgeistry 分为 Session、Data 和 Meta 三个模块。Session 模块用于 client 交互，可以横向扩容，可以承受大量 client 连接请求；Data 是数据存储模块，利用 slot 分片机制来均衡负载，使用备份来解决高可用问题；Meta 是 Session、Data 的注册中心，采用分布式锁来选举 leader，本文详细阐述 Meta 如何选主。\n基于 MySQL 的分布式锁 MySQL 表\ndrop table if exists distribute_lock; CREATE TABLE distribute_lock ( id bigint(20) NOT NULL AUTO_INCREMENT primary key, data_center varchar(128) NOT NULL, lock_name varchar(1024) NOT NULL, owner varchar(512) NOT NULL, duration bigint(20) NOT NULL, term bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT \u0026#39;任期\u0026#39;, term_duration bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT \u0026#39;租期\u0026#39;, gmt_create timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, gmt_modified timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_data_center_lock` (`data_center`, `lock_name`), KEY `idx_lock_owner` (`owner`) ); 表的增改查等操作\npublic interface DistributeLockMapper { /** * query by dataCenter and lockName * * @param dataCenter * @param lockName * @return */ public DistributeLockDomain queryDistLock( @Param(\u0026amp;quot;dataCenter\u0026amp;quot;) String dataCenter, @Param(\u0026amp;quot;lockName\u0026amp;quot;) String lockName); /** * compete lock, it will throw exception if lockName existed * * @param lock */ public void competeLockOnInsert(DistributeLockDomain lock) throws Exception; /** * compete lock with cas * * @param competeLock * @return */ public void competeLockOnUpdate(FollowCompeteLockDomain competeLock); /** renew lock last update time */ public void ownerHeartbeat(DistributeLockDomain lock); /** force reset owner and duration */ public void forceRefresh(DistributeLockDomain lock); } 整体流程 step1：启动时创建锁记录，\n\u0026amp;lt;insert id=\u0026amp;quot;competeLockOnInsert\u0026amp;quot; parameterType=\u0026amp;quot;com.alipay.sofa.registry.jdbc.domain.DistributeLockDomain\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;![CDATA[ INSERT /*+ QUERY_TIMEOUT(2000000) */ INTO distribute_lock ( data_center, lock_name, owner, duration, gmt_create, gmt_modified, `term`, `term_duration` ) VALUES ( #{dataCenter}, #{lockName}, #{owner}, #{duration}, NOW(3), NOW(3), 1, 0 ) ON DUPLICATE KEY UPDATE lock_name = #{lockName} ]]\u0026amp;gt; \u0026amp;lt;/insert\u0026amp;gt; step2：leader 每秒提交心跳，更新表\n\u0026amp;lt;update id=\u0026amp;quot;ownerHeartbeat\u0026amp;quot; parameterType=\u0026amp;quot;com.alipay.sofa.registry.jdbc.domain.DistributeLockDomain\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;![CDATA[ update /*+ QUERY_TIMEOUT(2000000) */ distribute_lock set owner = #{owner}, gmt_modified = NOW(3), `term_duration` = (`term_duration` + 1) where data_center = #{dataCenter} and lock_name = #{lockName} and owner = #{owner} and term = #{term} and `term_duration` = #{termDuration} and timestampdiff(SECOND, gmt_modified, NOW()) \u0026amp;lt; #{duration}/1000 ]]\u0026amp;gt; \u0026amp;lt;/update\u0026amp;gt; step3：follower 每秒判断锁是否过期，如果过期，则 cas 竞选 leader\npublic DistributeLockDomain onFollowWorking(DistributeLockDomain lock, String myself) { /** as follow, do compete if lock expire */ if (lock.expire()) { LOG.info(\u0026amp;quot;lock expire: {}, meta elector start: {}\u0026amp;quot;, lock, myself); distributeLockMapper.competeLockOnUpdate( new FollowCompeteLockDomain( lock.getDataCenter(), lock.getLockName(), lock.getOwner(), …","date":1652252400,"description":"源码解析｜registry meta选主","dir":"projects/sofa-registry/code-analyze/code-analyze-registry-meta/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1ed6ac5b5251011241bc8ec391f4e720","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","publishdate":"2022-05-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","summary":"背景 SOFARgeistry 分为 Session、Data 和 Meta 三个模块。Session 模块用于 client 交互，可以横向扩容，可以承受大量 client 连接请求；Data 是数据存储模块，","tags":["“源码解析”"],"title":"源码解析｜registry meta 选主","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/","wordcount":1236},{"author":"赵真灵、刘晶","categories":"SOFAStack","content":" 文｜赵真灵（花名：有济）蚂蚁集团技术专家、刘晶（花名：飞廉） 蚂蚁集团技术专家\n以下内容整理自 SOFAStack 四周年的分享\n本文 5332 字 阅读 10 分钟\nSOFAServerless 研发运维平台是蚂蚁集团随着业务发展、研发运维的复杂性和成本不断增加的情况下，为帮助应用又快又稳地迭代而研发。从细化研发运维粒度和屏蔽基础设施的角度出发，演进出的一套解决方案。\n核心方式是通过类隔离和热部署技术，将应用从代码结构和开发者阵型拆分为两个层次：业务模块和基座，基座为业务模块提供计算环境并屏蔽基础设施，模块开发者不感知机器、容量等基础设施，专注于业务研发帮助业务快速向前发展。\nPART. 1 背 景 当前 Serverless 的发展有两个演进方向，一个是从面向函数计算的架构往在线应用演进，另一种是面向在线应用的架构往类函数计算方向演进。\nSOFAServerless 体系选择了后者，是从面向应用研发运维过程中遇到的一些问题展开的。在应用架构领域，不可避免的问题是应用随着业务的复杂度不断增加，研发运维的过程中的问题会不断暴露出来。\n首先我们先看一下对于普通应用，研发和运维过程中的流程是什么样的？\n如图所示，从需求到设计、开发、线下测试，再到发布线上的研发运维不断反馈、循环迭代的过程。可以简化为开发同学提交代码到代码仓库，在线下做并行的验证测试，测试通过之后在线上发布，发布过程是串行的，只能够有一个发布窗口，这样的过程在应用体量业务还不太复杂的情况下问题，并不是很明显。\n但当业务复杂度不断增加，普通应用迭代过程在会出现一些新的问题，如下图：\n1.管理成本高：需求管理、代码管理、人员管理\n2.时间成本高：线上验证与发布互相阻塞；单次启动慢\n3.变更风险高： 一次变更涉及所有代码；一次变更涉及所有机器\n4.可扩展性不够\n另外，由于这些问题是因为多业务单元与研发任务耦合在某些单点上导致的，这些研发运维的成本随着业务的复杂度，呈现出指数增长的特点。\nPART. 2 SOFAServerless 研发运维体系 解决方案介绍\n对于这些问题，业界已经发展并演进出了多种应用架构，从单体架构 -\u0026amp;gt; 垂直架构 -\u0026amp;gt; SOA 架构 -\u0026amp;gt; 分布式微服务架构 -\u0026amp;gt; 服务网格架构等，我们分析这些演进过程为解决遇到的研发运维问题提出 SOFAServerless 研发运维体系，主要的核心思路是：\n 研发运维力度的细化 通过细化的方式，让多人协作之间不互相 block；\n迭代的范围变小，速度变快。\n 屏蔽基础设施 屏蔽基础设施，让业务开发同学只关注代码服务和流量。\n对于这两点，我们采用了 SOFAArk ClassLoader 类隔离和热部署能力，将应用拆分成基座和模块。\n基座和模块 从这张图里面可以看到我们拆分的形态，把一个普通的 JVM 应用拆出多个模块，进一步对模块进行了一些分工：基座和模块，对应的研发人员也分为基座开发者和模块开发者。\n基座沉淀通用的逻辑，为模块提供计算和环境，并会模块开发者屏蔽基础设施，让模块开发者不需要关心容量、资源、环境。各个模块是独立的代码仓库，可以进行独立的研发运维，这样研发运维粒度得到细化，并且由于基座为模块屏蔽了环境与基础设施，模块开发者可以专注业务开发，提高整体效率。\n如何共享和通信 应用如果只是做拆分，没有共享和通信能力是不完整的方案也难以解决实际问题。对于共享和通信，基座作为共享的一层，能帮模块预热 RPC 数据库缓存通用类、通用方法、通用逻辑，可以供安装一些模块去复用。这样模块实现的比较轻，所以模块的部署密度也可以做得很高。\n对于模块通信，当前模块之间的通信可以支持任意的通信方式，比如说基座调模块、模块调基座模块和模块之间调用。由于模块通信是 JVM 内跨 ClassLoader 调用，与普通 JVM 内方法调用增加了序列化与反序列化的开销，目前这部分开销已经优化到约等于 JVM 内部的方法调用。\n在这一能力建设之后，可以较大降低模块的接入改造成本并扩大可适用的业务范围。\n如何解决业务痛点 管理成本\n相较于原来的研发模式，研发人员拆分成不同小组，代码仓库也拆分出多个模块仓库，并且可以独立并行的发布到线上，整个 pipelien 都可以做到独立进行。\n如此一来，需求管理、代码管理、人员管理的成本就得到下降了，线上发布过程中也不会再有互相阻塞的问题存在。\n当然这些成本下降不代表这些问题完全没有了，只是从原来的指数增长转变成了这种线性增长。随业务的复杂度不断增加，它的收益会更加的明显。\n时间成本 相对于普通应用的镜像构建需要 3 分钟，发布需要镜像下载、启动、挂载流量大概 3 分钟，总共平均需要 6 分钟；模块构建只需要 10 秒，启动大概 1~10 秒 （模块大小可大可小，对于较小的模块，速度可以做到毫秒级别） 。\n把一次发布耗时从原来的 6 分钟下降到 15 秒，一次迭代从原来 2 周下降到了 2 天，最快可以 5 分钟上线的。\n可扩展性 对于线上集群的部署形态，不同的机器上部署的模块不尽相同。例如对于模块 1，只安装在了第一第二台机器上，那么模块升级时只会涉及到这两台机器本身，变更的机器范围就比较小了。另外，模块 1 如果要扩容的话，可以从集群内筛选出较空闲的机器进行模块热部署即可，一般也就是 10s 级别，所以能做大快速的水平扩展能力。\n变更风险 对于一次模块的升级变更，只会涉及模块自身的代码本身不会设计整个应用代码。模块变更需要更新的机器也只是模块安装过的机器本身，不会涉及到整个集群，所以变更范围大大缩小，变更风险也相较普通应用能得到明显减少。\n高可用和配套能力 SOFAServerless 体系在解决业务研发运维痛点基础上，建设了高可用和配套的能力。\n资源隔离 资源隔离体现在单个 JVM 内部的，这里采用了我们公司内部 AliJDK 多租户隔离能力，每一个模块可以指定自己的资源使用的上限。\n比如说，其中一个模块的逻辑有一些问题，消耗的资源比较大，不会影响到其他的模块，相当于得到了故障的隔离。\n流量隔离能力 对于单个集群内部，我们做了一些精细化的流量路由。主要是因为发服务时能够动态增加 tag，流量路由时能够配一些规则，推送到 MOSN、Layotto 里，能让流量根据对应的 tag 进行一些精细化路由，这样就具备了流量的精细化路由和流量隔离能力。\n可观测性能力与变更防御能力 具备模块粒度的健康检查、资源监控、日志监控还有排障能力，在此基础上建设模块粒度的变更防御。\n一个模块可以同时存在多个版本，可以做一些快速的 A/B 测试、灰度、回滚这些能力。\nPART. 3 业务的落地形态** SOFAServerless 发展到现在，已经在蚂蚁内部接入了 700 多个 Java、nodejs 应用，基本涵盖了蚂蚁所有业务线，支撑了 1 万多次的完整的生产研发迭代。线下可以做到秒级发布，支付宝应用内很多业务就是跑在 SOFAServerless 上的，比如投放展位、公益游戏、营销玩法。\n去年 SOFAServerless 成功支撑了 618、双 12、五福等重量级大促和活动，经受住了大流量高并发场景下的考验，托管在 SOFAServerless 的资 …","date":1652166000,"description":"SOFAServerless 体系助力业务极速研发","dir":"blog/sofaserverless-system-for-speedy-business-development/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"760d9079310bd5202d52c369c1603bec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","publishdate":"2022-05-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","summary":"文｜赵真灵（花名：有济）蚂蚁集团技术专家、刘晶（花名：飞廉） 蚂蚁集团技术专家 以下内容整理自 SOFAStack 四周年的分享 本文 5332 字 阅读 10 分钟 SOFAServerless 研发运维平台是蚂","tags":["SOFAStack"],"title":"SOFAServerless 体系助力业务极速研发","type":"blog","url":"/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/","wordcount":5533},{"author":"范明柯","categories":"SOFAStack","content":" 前言 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析\n 一、架构流程图 二、订阅流程 以客户端首次订阅，且服务发布方已注册的场景为例，订阅流程主要分为三步，\n 客户端发起订阅 session server 处理订阅任务，从缓存（或 data server）拉取地址列表 向客户端推送地址列表 2.1 客户端发起订阅 客户端发起订阅的方式是异步的，首先将订阅注册的任务添加到客户端的内存队列中。\n2.2 session server 处理订阅请求 session server 接收到订阅注册任务后，主要是通过 SessionRegistry#regsiter 方法处理的，判断当前是服务消费方，添加到订阅者缓存中； case SUBSCRIBER: Subscriber subscriber = (Subscriber) storeData; // if (!sessionInterests.add(subscriber)) { break; } sessionRegistryStrategy.afterSubscriberRegister(subscriber); break; 触发RegProcessor#fireOnReg方法，将订阅者放入buffer中，参考源码如下： boolean fireOnReg(Subscriber subscriber) { final String dataInfoId = subscriber.getDataInfoId(); // 从若干个BufferWorker数组找到其中一个 BufferWorker worker = indexOf(subscriber.getDataInfoId()); // 将dataInfoId和subscriber存到BufferWorker线程中的subMap中 // subMap的key为dataInfoId，value为SubBuffer SubBuffer buffer = worker.subMap.computeIfAbsent(dataInfoId, k -\u0026amp;gt; new SubBuffer()); return buffer.add(subscriber); } 2.3 session server 拉取地址列表 BufferWorker 线程循环处理 map 缓存中的订阅注册任务，处理流程如下：\n 从 worker 的 subMap 取出所有 dataInfoId 和订阅者列表，并对每个 dataInfoId 分别处理 通过 RegProcessor#processBuffer 方法处理每个 dataInfoId 和对应的订阅者 int processBuffer(Ref ref, int hitSize) { List\u0026amp;lt;Subscriber\u0026amp;gt; subscribers = Lists.newArrayListWithCapacity(hitSize); for (Map.Entry\u0026amp;lt;String, Subscriber\u0026amp;gt; e : ref.subscriberMap.entrySet()) { final Subscriber sub = e.getValue(); // 若订阅者已经推送过，直接忽略 if (!sub.hasPushed()) { subscribers.add(sub); } // 这里因为subscriberMap是引用，没有锁保护，所以sub可能已经被新的subscriber替换掉 // try to remove the sub, but subs maybe changes ref.subscriberMap.remove(sub.getRegisterId(), sub); } if (!subscribers.isEmpty()) { // 从缓存中获取dataInfoId的地址列表，并推送给subscribers regHandler.onReg(ref.dataInfoId, subscribers); } // 返回推送地址列表的订阅者数量 return subscribers.size(); } 通过 FirePushService#getDatum 方法从缓存中获取地址列表。该缓存使用 Guava Cache 的LoadingCache，当缓存中没有 dataInfoId 的地址列表时，会自动从 data server 获取地址列表，并放在缓存中。\n 通过 FirePushService#processPush 方法将地址列表推送给所有订阅者\n 首先通过 firePush 方法将 PushTas k放入 buffer 等待 PushTaskBuffer.BufferWorker 线程异步处理任务 2.4 session server 推送地址列表 PushProcessor 初始化时默认创建 4 个 PushTaskBuffer.BufferWorker 线程； BufferWorker 线程循环执行 watchBuffer 方法，将 worker 中缓存的过期任务删除后进行处理，具体逻辑见下边源码； int watchBuffer(BufferWorker worker) { int bufferedSize = worker.bufferMap.size(); if (bufferedSize \u0026amp;gt;= MAX_BUFFERED_SIZE) { LOGGER.warn(\u0026amp;quot;arrived max buffered size: buffered={}\u0026amp;quot;, bufferedSize); } // 获取推送任务 List\u0026amp;lt;PushTask\u0026amp;gt; pending = worker.transferAndMerge(); int count = 0; for (PushTask task : pending) { // 将任务放进线程池执行 if (task.commit()) { count++; } } if (pending.size() \u0026amp;gt; 0 || count \u0026amp;gt; 0) { LOGGER.info(\u0026amp;quot;buffers={},commits={}\u0026amp;quot;, pending.size(), count); } return count; } 推送地址列表给客户端。 三、发布流程 服务发布流程主要分为下面5步：\n 客户端服务注册 session server 处理服务发布请求 data server 保存服务注册数据，并生成数据变更通知 session server 接收数据变更通知，拉取数据 session server 推送地址列表 3.1 服务注册 客户端进行发布注册，与上面客户端订阅的逻辑一样，都是先将请求放在队列里，等待异步处理，此处不再赘述。\n3.2 session server 处理服务发布请求 SessionRegistry#register 方法判断请求来自服务发布方； …","date":1652079600,"description":"源码解析｜发布订阅推送","dir":"projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","fuzzywordcount":3100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"981d3695a0bbf202fbb64b22687b1f25","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","publishdate":"2022-05-09T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","summary":"前言 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析 一、架构流程图 二、订阅流程 以客户端首次订阅，且服务发布方已注册的场景为例，订阅流程主要分为三步， 客户端发起订","tags":["“源码解析”"],"title":"源码解析｜发布订阅推送","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/","wordcount":3020},{"author":null,"categories":"SOFA Weekly","content":" 开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。\n活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。\n2022 年，SOFAStack 和 MOSN 社区再次加入中国科学院软件研究所的高校开源活动——“开源之夏 2022”，为大家准备了六个任务，涉及 Cloud Native、Micro Service、Distributed System、Kubernetes、Container 等多个领域。\n活动规则 进入：https://summer-ospp.ac.cn/#/homepage\n各位同学可以自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。\n项目任务 1.SOFARegistry 客户端负载均衡\nSOFARegistry 的客户端目前采用长连接与其中一台 Session 相连，随后会用这根链接注册和订阅服务，在注册中心进行运维期间，客户端会断链重连到别的机器上，经过一轮滚动升级，就会造成 Session 上链接分布的不均衡，一是数据不均衡，二是推送压力不均衡，严重的时候会造成单机热点，影响推送的效率。\n由于长连接快速检测节点宕机的机制，主动断链会造成节点数据下线，因此客户端链接的稳定性也是一个很重要的考虑。\n对服务发现来说，发布和订阅对链接稳定性的要求不同：\n 对发布，链接断开会造成服务数据下线\n 对订阅，会造成轻微的数据推送延迟，延迟时间通常是重连间隔\n 项目社区导师：dzdxdzidaxie@gmail.com\n2.增强 layotto-java-sdk 和 layotto-spring-boot\n项目编号：2295a0213\n任务难度：基础/Basic\n1.增强 Layotto 的 java-sdk 的功能，使其与 go-sdk 对齐。现在的 java-sdk 有 file、lock、pubsub、sequencer、state 的 API，缺少 secret、config 等 API。\n 完善 layotto-sdk-springboot, 将 Layotto 的更多功能集成进 spring-boot。layotto-sdk-springboot 的设计目标是帮助 spring-boot 的用户低成本接入 Layotto，比如用户在代码中添加一个 Java 注解后，就能方便的进行消息监听、收到新消息后自动调用方法。\n 在 layotto-sdk-springboot 的基础上，开发 layotto-sdk-sofaboot, 方便 SOFABoot 用户使用 Layotto。\n 项目社区导师：张立斌1098294815@qq.com\n3.Layotto 中实现 ceph 文件系统，同时打通 SOFABoot\n项目编号：2295a0214\n任务难度：基础/Basic\n用 ceph 实现 Layotto 的 file API 组件，并通过 SOFABoot 调通。\n 首先熟悉 Layotto 的架构设计，基于现在的 file 接口实现 ceph 文件系统。（此处需要调研 Layotto 的 file 组件的可移植性以及 ceph 文件系统，判断当前的 Layotto 接口能否满足 ceph 文件系统）\n 通过 SOFABoot 和 Layotto 打通，可以通过 SOFABoot 应用调通 Layotto 的 file 接口。\n 项目社区导师：wenxuwanwangwx_junction@163.com\n4.SOFATracer upgrade opentracing api version \u0026amp;amp; adapter opentelemetry api\n项目编号：2295a0196\n任务难度：进阶/Advanced\nCurrently, sofa-tracer relies on the openTracing version 0.22.0. This version has been out of date for a long time and we need to update to the official recommended stable version. In addition, we need to provide an API layer to accommodate OpentElemetry.\nTasks:\n1、upgrade opentracing version torelease-0.33.0\n2、adapter https://opentelemetry.io/docs/migration/opentracing/\n3、provide intergration doc and guides\n项目社区导师：卫恒（宋国磊）glmapper_2018@163.com\n5.为 MOSN 适配社区 Proxy-Wasm v2 开源规范\n项目编号：22f080190\n任务难度：进阶/Advanced\nWebAssembly(Wasm) 是近几年从 Web 领域诞生，并快速出圈的一项虚拟机指令格式，是一种可移植的、语言无关并兼容 Web 的全新格式，支持在浏览器和非 Web 环境运行不同语言编写的应用程序。\nMOSN 是一款主要使用 Go 语言开发的网络代理 (类似 Envoy、Nginx)，融合了大量云原生通用插件，为服务提供了多协议、模块化、智能化、安全的代理能力。\n如何为这些插件提供一个安全隔离的运行环境，甚至支持不同语言编写的插件，成为了一个非常具有挑战性的课题。Wasm 技术和 Proxy-Wasm 规范的诞生为解决上述问题提供了一种全新的思路。\n本题目将基于 MOSN 中已有的 Wasm 框架，适配开源社区专门为网络代理场景提出的 Proxy-Wasm v2 规范，使 MOSN 具备运行符合 v2 规范的 Wasm 插件的能力。\n项目社区导师：叶永杰yongjie.yyj@antgroup.com\n6.Layotto 集成 Istio\n项目编号：22f080198\n任务难度：进阶/Advanced\n1.Istio 是 ServiceMesh 方向上一个非常火热的解决方案，默认使用 envoy 作为数据面。\n MOSN 作为一个对标 envoy 的另一种数据面实现，也可以跟 Istio 集成，作为 envoy 的一种替代方案。\n Layotto 作为 Application Runtime 的一种实现，基于 MOSN 开发，期望可以结合 Service Mesh 跟 Application Runtime 两种思想。\n 既然 Istio 可以集成 MOSN ，且 Layotto 跟 MOSN 是一体的，因此本次的任务是把 Layotto 作为数据面跟 Istio 进行集成，以服务调用为例，在应用通过 Layotto …","date":1651906800,"description":"【2022 开源之夏】欢迎报名 SOFAStack 社区和 MOSN 社区项目！","dir":"blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"38cfc44c56af96fa7b7700c470ce5931","permalink":"https://sofastack.github.io/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","publishdate":"2022-05-07T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","summary":"开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬","tags":["SOFA Weekly"],"title":"【2022 开源之夏】欢迎报名 SOFAStack 社区和 MOSN 社区项目！","type":"blog","url":"/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/","wordcount":2100},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@尚之 提问：\n SOFARegistry 和应用绑定有多深，Serverless 场景下有没有更动态的方案和应用解绑？\n A：其实不需要和应用进行绑定，更准确的说法是节点级的服务发现，就算应用下面每个节点之间发布的服务不一样，应用级的这个方案也是可以支持的。而且目前蚂蚁的 Serverless 的场景实际上已经是应用级了，只是对于业务 owner 没有感知。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@沄澈|che 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?\n A：要看 SerializerFactory 对 Localdatetime 的支持了。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 MOSN 1.0 发布，开启新架构演进\n HAVE FUN | SOFABoot 源码解析活动\n SOFARegistry 源码｜数据分片之核心-路由表 SlotTable 剖析\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1651820400,"description":"SOFA Weekly | 神奇技术、本周贡献者、新手任务","dir":"blog/sofa-weekly-20220506/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d89becc4edace0dc4e93d5a8b39f9e61","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220506/","publishdate":"2022-05-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220506/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 神奇技术、本周贡献者、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220506/","wordcount":1010},{"author":"周书伟","categories":"SOFAStack","content":" 源码解析：无损运维 SOFARegistry 是一个基于内存存储的分布式注册中心，数据是分散存储在各个节点，为了做到注册中心自身运维期间依然能够对外正常提供服务，需要进行节点下线快速感知和数据迁移。\n session 存储 client 发送的发布和订阅数据，由于 client 断连重放的特性，session 单机下线后 client 会重放数据到其他节点。\n data 会接收 session 发送的发布数据，data 单机下线后，meta 会通过 SlotTable 的变更把对应 Slot 的所有权移交其他 data，data 启动后会进行数据同步到达数据完整可对外提供服务的状态。\n session、data下线的过程，如何避免下线期间数据丢失和抖动 SessionServer 和 DataServer 下线的相关代码都位于各自 bootstrap 类的 dostop 方法中。\n首先讨论 SessionServer 的下线过程：\nprivate void doStop() { try { LOGGER.info(\u0026amp;quot;{} Shutting down Session Server..\u0026amp;quot;, new Date().toString()); stopHttpServer(); clientNodeConnectionHandler.stop(); // stop process disconnect event stopServer(); // stop http server and client bolt server before add blacklist // make sure client reconnect to other sessions and data gracefulShutdown(); stopDataSyncServer(); stopConsoleServer(); executorManager.stopScheduler(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Shutting down Session Server error!\u0026amp;quot;, e); } LOGGER.info(\u0026amp;quot;{} Session server is now shutdown...\u0026amp;quot;, new Date().toString()); } 从代码中可以看出，SessionServer 服务在下线时，首先会停掉 HttpServer，HttpServer 提供一系列 REST 接口，用于 dashboard 管理、数据查询等；然后停掉 clientNodeConnectionHandler，clientNodeConnectionHandler 是 Exchange 设置的一系列 ChannelHandler 之一，Exchange 作为 Client / Server 连接的抽象，负责节点之间的连接。gracefulShutdown 方法则是通知 Meta（元数据服务器）将本节点加入 Meta 的黑名单中。HttpServer 和客户端的 bolt Server 是在本节点加入黑名单前关停，以保证 client 已经重连到了其他 session 节点上。这样就保证了运维的 session 节点下线期间，client 的数据不会因为 session 节点的不可用，导致数据丢失和抖动。接下来又依次关停了 DataSyncServer，ConsoleServer。\nDataServer 下线过程的代码如下：\nprivate void doStop() { try { LOGGER.info(\u0026amp;quot;{} Shutting down Data Server..\u0026amp;quot;, new Date().toString()); gracefulShutdown(); stopHttpServer(); stopServer(); stopDataSyncServer(); stopNotifyServer(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Shutting down Data Server error!\u0026amp;quot;, e); } LOGGER.info(\u0026amp;quot;{} Data server is now shutdown...\u0026amp;quot;, new Date().toString()); } DataServer 的下线则和 Session 的下线有些区别，由于 DataServer 数据服务器，负责存储具体的服务数据，而且 Slot 均匀地分配给每个节点上，所以下线前需要检测 DataServer 上的插槽状态，所以 doStop 的方法中，首先调用了如下的优雅下线的方法，其中代码中的主要内容如下：\naddBlacklistRetryer.call( () -\u0026amp;gt; { LOGGER.info(\u0026amp;quot;[GracefulShutdown] add self to blacklist\u0026amp;quot;); metaServerService.addSelfToMetaBlacklist(); return true; }); addBlacklistRetryer.call( () -\u0026amp;gt; { if (fetchStopPushService.isStopPushSwitch()) { return true; } SlotTableStatusResponse statusResponse = metaServerService.getSlotTableStatus(); if (statusResponse.isProtectionMode()) { return true; } LOGGER.info(\u0026amp;quot;[GracefulShutdown] wait no slot\u0026amp;quot;); if (slotManager.hasSlot()) { throw new RuntimeException(\u0026amp;quot;current data server still own slot, waiting...\u0026amp;quot;); } return true; }); LOGGER.info(\u0026amp;quot;add data self to blacklist successfully\u0026amp;quot;); 首先节点通知 Meta 加入黑名单，stopmetaServerService.getSlotTableStatus() 获取节点上 SlotTable 的状态，当 Slot 重新分配给其他节点后，该 Data 节点才会成功加入黑名单，并进行接下来 HttpServer、DataSyncServer、NotifyServer 的下线动作。\n整体流程是 Data 上的 Slot 逐步迁移，期间仍然对外提供服务。\n迁移完成后主动从列表中剔除并设置节点黑名单并下线。\n以下图为例，假设要下线的节点是 DataServer-1： …","date":1651820400,"description":"源码解析｜无损运维","dir":"projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ffe7f76f483d5fbc2827a237b6c48093","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","publishdate":"2022-05-06T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","summary":"源码解析：无损运维 SOFARegistry 是一个基于内存存储的分布式注册中心，数据是分散存储在各个节点，为了做到注册中心自身运维期间依然能够对外正常提供服务，需要","tags":["“源码解析”"],"title":"源码解析｜无损运维","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/","wordcount":3684},{"author":"朱德江","categories":"SOFAStack","content":" 文｜朱德江（花名：人德）\n蚂蚁集团技术专家 负责 MOSN 核心开发，关注云原生流量网关的演进\n以下内容整理自 SOFAStack 四周年的分享\n本文 5332字 阅读 10 分钟\nMOSN 1.0 发布 MOSN 是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源，经过双 11 大促几十万容器的生产级验证。\n经过 4 年的蓬勃发展，在 11 位 commiter，100 多个 contributor 和整个社区的共同努力下，经历 27 个小版本的迭代，MOSN 1.0 版本正式发布了。\n一个足够成熟稳定，有开源用户共建、有商业化落地、有社区，拥抱云原生生态的 MOSN 1.0 来了。\n除了在蚂蚁集团的全面落地，MOSN 在业界也有较广泛的应用，比如有工商银行的商业化落地，还有阿里云、去哪儿网、时速云等企业的生产实践。\n同时，随着 1.0 的发布，进入少年期的 MOSN 也将开启新一代 MOE 架构演进，奔向星辰大海。\n发展历史 MOSN 起源于 Service Mesh，原本在微服务之间的调用是通过比较重的 SDK 来完成的，当 SDK 升级的时候，需要应用配合一起升级，有比较强的打扰。\nMOSN 为了解决这一痛点，向着把 SDK 剥离出来的方向演进。在应用所在的 Pod 内，单独有一个运行 MOSN 的 sidecar，那么应用本身只需要跟 MOSN 去通讯，就可以完成整个的服务调用的流程。把 SDK 剥离出来，相当于 MOSN 作为一个独立的组件去演进，其演进过程对应用本身没有打扰。这在蚂蚁内部的收益其实是非常明显的。\n在整个演进的过程中，有两个比较深的体会：一个比较明显的是，有一个独立的 sidecar，可以去跟业务逻辑做解耦；另外一个标准化，在云原生的时代里，控制面和数据面被拆分为两个独立的组件，MOSN 作为数据面的组件，演进过程中要跟很多控制面的服务对接，这期间标准化是一个很重要的。在整个标准化的过程中，它并不像业务解耦那么直观，但是用的时间越长，对其越深有体会。\n现在 MOSN 已经在蚂蚁内部全面的铺开，部署有几十万 Pod，峰值 QPS 千万级。\nMOSN 的演进历程 2018 年： 开始创建；\n2019 年： 在双 11 完成了核心链路的覆盖，在 19 年底的时候，MOSN 开始独立运营；\n2020 年： 7 月份获得 Istio 官方的推荐。同时，MOSN 开启了商业化的探索，年底完成了江西农信的落地；\n2021 年： 对接了 Envoy、Dapr、WASM 生态，和主流的社区合作。同年 12 月份， 在工商银行完成了商业化的落地，树立了业界新标杆。\nMOSN 除了在蚂蚁内部全面铺开，以及商业化的落地实践，还有逐渐完善的社区。MOSN 社区目前有 11 个 Committer，其中超过 70% 是非蚂蚁的 Committer，有 100 多位的 Contributor，经过了 28 个小版本的迭代。MOSN 还有很多开源的用户，他们将 MOSN 在自己公司落地，也对 MOSN 有很多的贡献。\n社区除了在 MOSN 项目的贡献之外，还有对其他项目/社区的贡献，包括Holmes、BabaSSL、Proxy-Wasm 等项目，以及跟其他生态项目的对接。\n总体来说，MOSN 现在足够成熟稳定，有商业化的落地，有社区、有周边、有生态，所以我们选择这个时间点发布 MOSN 1.0 版本。\n1.0 的核心能力以及扩展生态 MOSN 1.0 版本标志性的成果是已经集成了 Istio 的 1.10 版本。\nMOSN 作为网络代理的软件，在核心转发方面已经支持了 TCP、UDP、透明劫持的模式。MOSN 所处在东西向网关场景下，有很多内部的、私有的非标协议，MOSN 除了支持 HTTP 标准协议以外，还有很重要的 XProtocol 框架，可以非常简单、方便支持私有的非标协议，内置的 Bolt、 Dubbo 协议，也是通过 XProtocol 框架来实现的。我们还支持了多协议的自动识别，也是在东西向流量网关里面比较核心的、比较特别的能力支持。\n后端管理和负载均衡是在网络代理情况下，比较基本的常规能力。MOSN 也支持了连接池、主动健康检查、各种各样的负载均衡的策略。\n在核心路由上，MOSN 支持基于 Domain 的 VirtualHost，引入了一个非常强大的变量支持，通过变量做复杂的路由规则，也支持了 Metadata 的分组路由。还有路由级别的超时、重试的配置，以及请求头、响应头的处理。\n简单来说，作为一个网络代理的平台，通用的核心能力 MOSN 都已经完全具备了。\n同时在网络代理的场景，通常需要做很多扩展，MOSN 的扩展生态做到了什么样的程度了呢？\nRPC 协议： 有 Dubbo 和 SOFABolt 的支持，同时基于 BabaSSL 做了国密的支持；\n控制面： MOSN 已经做了 Istio 的支持；\n注册中心： SOFARegistry；\n可观测性：Skywalking 以及 Holmes 针对 Go 运行时期间，资源使用异常的自动分析和诊断。\n在网关场景里，有很多的逻辑是需要做定制的。除了常规的用 Go 写一些 filter 扩展之外，还支持 Go Plugin 这种轻量级的模式，也支持 Proxy-Wasm 标准的 Wasm 扩展运行在 MOSN 中，服务治理方面也对接了 Sentinel。\nIstio 1.10 MOSN 会通过标准的 xDS 协议和 Istio 通讯，这是一个非常标准的使用方式，同时我们也在积极的参与标准的建设。\n我们在标准的制定过程中，积极提案参与讨论，比如说限流的和路由的 proto，也正是我们和 Istio 有非常多的合作，才能够获得 Istio 官方的推荐。\nMOSN 起源于 ServiceMesh 东西向流量的场景，我们经过了四年的努力，选择在今天这个时间点发布 MOSN 1.0 版本，作为一个成熟稳定、有商业化落地、有社区、有生态的一个版本呈现出来，我们欢迎更多的人来使用 MOSN，也欢迎大家一起来共建和成长。\n二、MoE 新架构 做这个的愿景初衷是什么？\n这样做的优势是什么？\nMoE 新架构的探索有什么新的进展？\n首先 Enovy 和 MOSN 是作为目前市面上的两个数据面，它们都各有特点， Enovy 是 C++写的，处理性能会比较高。MOSN 的研发性和效能高，有很好的生态。\nMoE 就是 MOSN 加 Enovy。我们希望能够做把两者的优势给融合起来，相互融合，各取所长，把高性能和高研发效能结合到一起，支持我们做大做强，走得更远。\nMoE 架构在 Enovy 的角度来看，MOSN 作为 Enovy 的一个插件扩展，在所有的 Enovy 的扩展方式里面，做一个横向的对比。\n1.首先第一个是 Lua\n嵌入式的脚本语言有比较强的优势，它操作简单。但是作为相对小众的语言，劣势也很明显——生态不好。我们目的是为了提高研发效能， Lua 无法让我们达到目标。\n2.WASM 是比较诱人的方案\nWASM 在发展初期，有很多东西还只是停留在愿景上。很多的语言支持不友好，以及 runtime 性能不够好，这都是很现实的痛点。\n3. …","date":1650956400,"description":"MOSN 1.0 发布，开启新架构演进","dir":"blog/mosn-1-0-released-starting-a-new-architectural-evolution/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6319d8cdb62702760f6c4d04c3f996a7","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","publishdate":"2022-04-26T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","summary":"文｜朱德江（花名：人德） 蚂蚁集团技术专家 负责 MOSN 核心开发，关注云原生流量网关的演进 以下内容整理自 SOFAStack 四周年的分享 本文 5332字 阅读 10 分钟 MOSN 1.0 发布","tags":["SOFAStack"],"title":"MOSN 1.0 发布，开启新架构演进","type":"blog","url":"/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/","wordcount":4640},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@黄昊 提问：\n 同一个网格里，不同的 Pod 可以注入不同版本的 Sidecar 吗？\n A：去改 inject 程序可以实现，相关资料可以搜索：K8s准入控制。\n 利用 webhook，动态匹配返回 sidecar-image 是这个意思吗？看代码，貌似 Istio 里面可以通过sidecar.istio.io/proxyImage 这个 annotation 来指定。\n A：是的。\n「MOSN」：https://github.com/mosn\n@service mesh 提问：\n gateway 有开源计划吗？\n A：有考虑，但是目前还没有具体的时间点，可以看下这个初期的 issue，有个demo.\nhttps://github.com/mosn/mosn/issues/1563\n「MOSN」：https://github.com/mosn\n@Tom 提问：\n Wasm 还有啥好玩的待实现的特性吗？\n A：目前关于 Wasm 主要想尝试两个方向：\n 以 Wasm 作为用户开发函数的载体，可以参考下：https://github.com/mosn/layotto/issues/191\n 以 Wasm 作为开发 Layotto 各个组件的载体，可以参考下：https://github.com/mosn/layotto/issues/476\n 第二个应该需要尝试使用 Rust 为 Layotto 的 API 开发一个组件然后编译成 Wasm。\n「Layotto」：https://github.com/layotto\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 金融级应用开发｜SOFABoot 框架剖析\n “SOFA 星球”闯关计划 ——Layotto 飞船\n HAVE FUN | 飞船计划、源码解析活动最新进展\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1650610800,"description":"SOFA Weekly | 年度优秀 Committer 、本周 Contributor、本周 QA","dir":"blog/sofa-weekly-20210422/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a78268fffd513c90682e116743a482e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210422/","publishdate":"2022-04-22T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210422/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 年度优秀 Committer 、本周 Contributor、本周 QA","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210422/","wordcount":1213},{"author":"顾叶宸","categories":"SOFAStack","content":" 前言 某些场景下 SOFARegistry 需要暂时关闭推送功能，这样集群内的业务可以利用 client 的缓存继续工作，比如说 SOFARegistry 需要进行不兼容升级，需要全集群下线，更新版本后再拉起。\n推送开关的状态存储在数据库中，通过 Meta 修改数据后，Session 可以通过读取到推送开关的变更通知，并在对应的推送流程上进行切断。\n本文将聚焦推送开关功能的三个关键问题：\n meta 如何存储开关配置数据。 session 如何获取到开关配置的变更并触发更新（通知、定时）。 session 关闭推送功能的实现。 总体流程 关闭推送的请求，主要由 StopPushDataResource类下的closePush负责处理。我们来看看它的实现：\npublic Result closePush() { boolean ret; Result result = new Result(); // 1.重设灰度推送开关 ret = resetGrayOpenPushSwitch(); if (!ret) { result.setSuccess(false); return result; } PersistenceData persistenceData = PersistenceDataBuilder.createPersistenceData( ValueConstants.STOP_PUSH_DATA_SWITCH_DATA_ID, \u0026amp;quot;true\u0026amp;quot;); try { // 2.重设全局推送开关 ret = provideDataService.saveProvideData(persistenceData); ...... } catch (Throwable e) { ...... } if (ret) { // 3.发送数据变更通知 fireDataChangeNotify( persistenceData.getVersion(), ValueConstants.STOP_PUSH_DATA_SWITCH_DATA_ID); } result.setSuccess(ret); return result; } 可以看到，closePush函数主要做了三件事：\n 重设灰度推送开关 灰度推送开关中，存储着一个 IP 列表。灰度推送允许 SOFARegistry 即使在全局推送关闭的情况下，仍满足特定 IP 的推送请求。因此想要完全关闭推送功能，需要重设该开关，清空其中的 IP 列表。\n 重设全局推送开关 关闭推送功能，需要重设全局推送开关，保存开关配置为关闭的新数据。\n 发送数据变更通知 数据变更通知将告诉 Session，开关配置已经改变，需要进行更新。\nMeta存储开关配置数据 我们以重设全局推送开关中，开关数据的存储为例：\n meta 首先从内存中读取旧的开关配置版本号，并与当前数据版本号进行比较。  只有确定是更新的数据，才会进行后续存储。\n 存储新的开关配置数据，并更新数据库中该数据的版本号。\n 更新内存中的开关配置数据。\n public boolean saveProvideData(PersistenceData persistenceData, long expectVersion) { // 1.比较版本号 if (persistenceData.getVersion() \u0026amp;lt;= expectVersion) { ...... return false; } // 2.更新数据库 boolean success = provideDataRepository.put(persistenceData, expectVersion); if (success) { lock.writeLock().lock(); try { // 3.更新内存 provideDataCache.put( PersistenceDataBuilder.getDataInfoId(persistenceData), persistenceData); } catch (Throwable t) { ...... return false; } finally { lock.writeLock().unlock(); } } return success; } 重设灰度开关中的步骤与之类似，因此这里不再赘述。\nSession 获取开关配置 通知更新 继续上文，closePush会调用fireDataChangeNotify函数，通知外界开关配置发生了更新。\nprivate void fireDataChangeNotify(Long version, String dataInfoId) { ...... if (TASK_LOGGER.isInfoEnabled()) { ...... } provideDataNotifier.notifyProvideDataChange(provideDataChangeEvent); } 这一通知首先会进行判断，是哪一种事件类型。在本例中，开关配置的更新是与 Session 有关的事件。 public void notifyProvideDataChange(ProvideDataChangeEvent event) { Set\u0026amp;lt;Node.NodeType\u0026amp;gt; notifyTypes = event.getNodeTypes(); // 判断事件类型 if (notifyTypes.contains(Node.NodeType.DATA)) { defaultDataServerService.notifyProvideDataChange(event); } if (notifyTypes.contains(Node.NodeType.SESSION)) { defaultSessionServerService.notifyProvideDataChange(event); } } 随后，通知会被交付给 Session 相关的消息交换类，并进行Request请求。 public void notifyProvideDataChange(ProvideDataChangeEvent event) { new NotifyTemplate\u0026amp;lt;ProvideDataChangeEvent\u0026amp;gt;().broadcast(event); } public void broadcast(E event) { ...... getNodeExchanger().request(new NotifyRequest(event, connection, executors)); ...... } 在消息交换类中，系统使用getClientHandlers得到了负责消息响应的handler。 public Response request(Request request) throws RequestException { final URL url = …","date":1650610800,"description":"源码解析｜推送开关","dir":"projects/sofa-registry/code-analyze/code-analyze-push-switch/","fuzzywordcount":2900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"38175885eb9d257b9f176246010b34b3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","publishdate":"2022-04-22T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","summary":"前言 某些场景下 SOFARegistry 需要暂时关闭推送功能，这样集群内的业务可以利用 client 的缓存继续工作，比如说 SOFARegistry 需要进行不兼容升级，需要全集群下线，更新版本后再拉起","tags":["“源码解析”"],"title":"源码解析｜推送开关","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/","wordcount":2840},{"author":"SOFA 团队","categories":"周年庆","content":" 概要 活动主题：见证 SOFAStack 社区开源四周年!\n 活动时间： 2022 年 04 月 16 日 （14:00-17:40）\n 活动形式：线上直播\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | 一、宋顺四周年致辞 点击下载资料\n| 二、《蚂蚁服务发现的大规模实践和展望》 讲师：蚂蚁集团技术专家李旭东（花名：向旭）\n点击下载资料\n议题简介\nnaming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。\n蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。\n本次将会分享蚂蚁内部实践经验，以及 naming 在云原生时代下的发展方向及趋势。\n| 三、《蚂蚁集团 Service Mesh 进展回顾与展望》 讲师：蚂蚁集团高级技术专家 石建伟（花名：卓与）\n点击下载资料\n议题简介\n练内功：内部集群规模化扩张带来的技术挑战，长连接膨胀，服务治理智能化演进和人工介入说再见\n定标准：Mesh 化是终点么？应用运行时标准\n建通路：让业务飞速发展的秘诀\n看未来：云原生运行时的下一个五年\n| 四、《MOSN 1.0 发布，开启新一代架构演进》 讲师：MOSN 核心成员 朱德江（花名：人德）\n点击下载资料\n议题简介\n一、MOSN 1.0 发布\n回顾 MOSN 的发展历史、新版本的特性介绍\n二、新架构演进\n发力南北向网关数据面、整合控制面，开源新产品\n| 五、《Ark Serverless 体系助力业务极速研发》 讲师：蚂蚁集团技术专家 赵真灵（花名：有济）\n讲师：蚂蚁集团技术专家刘晶（花名：飞廉）\n点击下载资料\n议题简介\nArk Serverless 技术体系让用户以开发模块（代码块）的方式快速上线新功能，同时让模块开发者不感知机器、环境与容量等基础设施，助力企业实现业务的快速发展。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1650092400,"description":"见证 SOFAStack 社区开源四周年!","dir":"activities/sofastack-four-years-of-open-source/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"08b0bec521b5328d71dcc39370feb260","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofastack-four-years-of-open-source/","publishdate":"2022-04-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofastack-four-years-of-open-source/","summary":"概要 活动主题：见证 SOFAStack 社区开源四周年! 活动时间： 2022 年 04 月 16 日 （14:00-17:40） 活动形式：线上直播 B 站直播间地址：http://live","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFA 四周年，开源正当时！","type":"activities","url":"/sofastack.tech/activities/sofastack-four-years-of-open-source/","wordcount":827},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@ 尚之 提问：\n SOFARegistry 和应用绑定有多深，Serverless 场景下有没有更动态的方案和应用解绑？\n A：其实不需要和应用进行绑定，更准确的说法是节点级的服务发现，就算应用下面每个节点之间发布的服务不一样，应用级的这个方案也是可以支持的。而且目前蚂蚁的 Serverless 的场景实际上已经是应用级了，只是对于业务 owner 没有感知。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@ 黄润良 提问：\n 两个组合为什么不生效呢？按照时间轮转，就不需要管理日志数量了吗？\n A：按照时间轮转还没有支持这个日志数量。\n 按时间轮转的，轮转后的文件名应该是带日期时间字符串的把，配个定制任务清理一下就可以了吗？\n A：我们也是用的这个库，然后根据时间轮转是我们扩展的，我们是统一平台做这个事，就没在 MOSN 里实现。\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto Java-sdk 本周发布 Layotto Java-sdk 发布 v1.1.0 版本，主要变更如下：\n 支持 File API\n 支持 Sequencer API\n 新增 layotto-springboot\n 「发布报告」：https://github.com/layotto/java-sdk/releases/tag/v1.1.0\n本周推荐阅读 HAVE FUN | Layotto 源码解析\n 异构注册中心机制在中国工商银行的探索实践\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1649401200,"description":"SOFA Weekly |开源新知、本周 QA、Layotto Java-sdk 本周发布","dir":"blog/sofa-weekly-20220408/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c70e2662ec9434d8229f900636d39af1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220408/","publishdate":"2022-04-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220408/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |开源新知、本周 QA、Layotto Java-sdk 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220408/","wordcount":1202},{"author":"行动","categories":"SOFAStack","content":" SOFARegistry 对于服务数据是分片进行存储的，因此每一个 data server 只会承担一部分的服务数据，具体哪份数据存储在哪个 data server 是有一个称为 SlotTable 的路由表提供的，session 可以通过 SlotTable 对对应的 data derver 进行读写服务数据， slot 对应的 data follower 可以通过 SlotTable 寻址 leader 进行数据同步。\n维护 SlotTable 是由 Meta 的 leader 负责的，Meta 会维护 data 的列表，会利用这份列表以及 data 上报的监控数据创建 SlotTable，后续 data 的上下线会触发 Meta 修改 SlotTable， SlotTable 会通过心跳分发给集群中各个节点。\n1. DataServer 更新SlotTable 路由表过程。 如上图所示 session 和 data 节点定时会向 Meta 节点上报心跳、Meta节点维护了 data 以及 session 节点列表信息、并且在心跳请求中将返回 SlotTable 路由表信息、data 节点将路由表 SlotTable 保存在本地中。\n2. SlotTable 更新平衡算法 由前文可知、SOFARegistry 采用了数据分片存储在 DataServer 节点之上、那么随之而来的问题就是数据如何分片呢?\nSOFARegistry 采用预分配的方式。\n传统的一致性 Hash 算法有数据分布范围不固定的特性，该特性使得服务注册数据在服务器节点宕机、下线、扩容之后，需要重新存储排布，这为数据的同步带来了困难。大多数的数据同步操作是利用操作日志记录的内容来进行的，传统的一致性 Hash 算法中，数据的操作日志是以节点分片来划分的，节点变化导致数据分布范围的变化。\n在计算机领域，大多数难题都可以通过增加一个中间层来解决，那么对于数据分布范围不固定所导致的数据同步难题，也可以通过同样的思路来解决。\n这里的问题在于，当节点下线后，若再以当前存活节点 ID 一致性 Hash 值去同步数据，就会导致已失效节点的数据操作日志无法获取到，既然数据存储在会变化的地方无法进行数据同步，那么如果把数据存储在不会变化的地方是否就能保证数据同步的可行性呢？答案是肯定的，这个中间层就是预分片层，通过把数据与预分片这个不会变化的层相互对应就能解决这个数据同步的难题。\n目前业界主要代表项目如 Dynamo、Casandra、Tair、Codis、Redis cluster 等，都采用了预分片机制来实现这个不会变化的层。\n事先将数据存储范围等分为 N 个 slot 槽位，数据直接与 slot 相对应，数据的操作日志与相应的 solt 对应，slot 的数目不会因为节点的上下线而产生变化，由此保证了数据同步的可行性。除此之外，还需要引进“路由表”的概念，如图 13，“路由表”负责存放每个节点和 N 个 slot 的映射关系，并保证尽量把所有 slot 均匀地分配给每个节点。这样，当节点上下线时，只需要修改路由表内容即可。保持 slot 不变，即保证了弹性扩缩容，也大大降低了数据同步的难度。\n实际上上述 Slot 和 **节点 **的映射关系在源码中以 **SlotTable 和 Slot **的方式进行表达。源码如下代码块所示。\npublic final class SlotTable implements Serializable { public static final SlotTable INIT = new SlotTable(-1, Collections.emptyList()); // 最后一次更新的时间 epoch private final long epoch; //保存了 所有的 slot 信息； slotId ---\u0026amp;gt; slot 对象的映射 private final Map\u0026amp;lt;Integer, Slot\u0026amp;gt; slots; } public final class Slot implements Serializable, Cloneable { public enum Role { Leader, Follower, } private final int id; //当前slot的leader节点 private final String leader; //最近更新时间 private final long leaderEpoch; //当前slot的follow节点 private final Set\u0026amp;lt;String\u0026amp;gt; followers; } 由于节点在动态变化中、所以 Slot 和 节点的映射也在时刻变化中、那么我们接下来的重点就是 SlotTable 的变更过程。SlotTable 的变更是在 Meta 节点中触发、当有服务上下线的时候会触发SlotTable 的变更、除此之外也会定期执执行 SlotTable的变更。\nSlotTable的整个同步更新步骤如图所示。\n代码参考 com.alipay.sofa.registry.server.Meta.slot.arrange.ScheduledSlotArranger#arrangeSync.\nSlotTable 的定期变更是通过在初始化 ScheduledSlotArranger 时候实例化守护线程不断的 定期执行 内部任务 Arranger 的 arrangeSync 方法来实现 SlotTable 变更的。大致流程如下所示。\n因为负责 SlotTable 的更新是在 MetaServer 中的主节点更新的。\n所以更新 SlotTable的第一步就是判断是否是主节点。主节点才负责真正的 SlotTable 变更步骤。\n第二步是获取最新的 DataServer 节点，因为 重新分配 SlotTable 本质上是 对 DataServer 节点和 slot 槽位之间的映射关系进行重新分配。所以肯定需要获取到当前正在存活的 DataServer 节点信息，从而方便的对之进行 slot 分配。\n(这里获取正在存活的 DataServer 也就是有和 MetaServer 维持心跳的 DataServer, 底层是从 com.alipay.sofa.registry.server.Meta.lease.impl.SimpleLeaseManager中获取，感兴趣可以查看相关源码) 。\n第三部是分配前置校验，实际上一些边界条件的判断、例如 DataServer 是否为空、 DataServer 的大小是否大于配置的 minDataNodeNum，只有满足这些条件才进行变更。\n第四步 执行 trayArrageSlot 方法、进入到该方法内部之中。\n首先获取进程内部锁、实际上是一个 ReentrantLock，这里主要是为了避免定时任务多次同时执行 SlotTable 的分配工作。\nprivate final Lock lock = new ReentrantLock(); 随后便是根据当前的 Data …","date":1649401200,"description":"源码解析｜SlotTable","dir":"projects/sofa-registry/code-analyze/code-analyze-slottable/","fuzzywordcount":8900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8705a6ead8d88f09270c5c19a3f6e6e6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","publishdate":"2022-04-08T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","summary":"SOFARegistry 对于服务数据是分片进行存储的，因此每一个 data server 只会承担一部分的服务数据，具体哪份数据存储在哪个 data server 是有一个称为 SlotTable 的路由表提供的，sessio","tags":["“源码解析”"],"title":"源码解析｜SlotTable","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/","wordcount":8810},{"author":"宋国磊","categories":"SOFAStack","content":" 本篇主要对 SOFARegistry 的数据同步模块进行解析，对于注册中心的概念以及 SOFARegistry 的基础架构不做过多阐述，相关介绍可以见海量数据下的注册中心 - SOFARegistry 架构介绍\n本文主要写作思路大致分为下面 2 个部分：第一部分借助 SOFARegistry 中的角色分类来说明哪些角色之间会进行数据同步，第二部分对数据同步的具体实现进行解析。\nSOFARegistry 的角色分类 如上图，SOFARegistry 包含 4 个角色：\n 角色 说明 Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。 SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。 DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。 MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。 在这 4 个角色中，MetaServer 作为元数据服务器本身不处理实际的业务数据，仅负责维护集群 SessionServer 和 DataServer 的一致列表，不涉及数据同步问题；Client 与 SessionServer 之间的核心动作是订阅和发布，从广义上来说，属于用户侧客户端与 SOFARegistry 集群的数据同步，可以见：https://github.com/sofastack/sofa-registry/issues/195，因此不在本文讨论范畴之内。\nSessionServer 作为会话服务，它主要解决海量客户端连接问题，其次是缓存客户端发布的所有 pub 数据；session 本身不持久化服务数据，而是将数据转写到 DataServer。DataServer 存储服务数据是按照 dataInfoId 进行一致性 Hash 分片存储的，支持多副本备份，保证数据高可用。\n从 SessionServer 和 DataServer 的功能分析中可以得出：\n SessionServer 缓存的服务数据需要与 DataServer 存储的服务数据保持一致 DataServer 支持多副本来保证高可用，因此 DataServer 多副本之间需要保持服务数据一致。 SOFARegistry 中对于上述两个对于数据一致性保证就是通过数据同步机制来实现的。\n数据同步的具体实现 下面主要介绍数据同步的实现细节，主要包括 SessionServer 和 DataServer 之间的数据同步 和 DataServer 多副本之间的数据同步两块。\nSessionServer 和 DataServer 之间的数据同步 SessionServer 和 DataServer 之间的数据同步，是基于推拉结合的机制\n 推：DataServer 在数据有变化时，会主动通知 SessionServer，SessionServer 检查确认需要更新（对比 version） 后主动向 DataServer 获取数据。\n 拉：除了上述的 DataServer 主动推以外，SessionServer 每隔一定的时间间隔，会主动向 DataServer 查询所有 dataInfoId 的 version 信息，然后再与 SessionServer 内存的 version 作比较，若发现 version 有变化，则主动向 DataServer 获取数据。这个“拉”的逻辑，主要是对“推”的一个补充，若在“推”的过程有错漏的情况可以在这个时候及时弥补。\n 关于推和拉两种模式检查的 version 有一些差异，可以详见下面 推模式下的数据同步 和 拉模式下的数据同步 中的具体介绍\n 推模式下的数据同步流程 推模式是通过 SyncingWatchDog 这个守护线程不断 loop 执行来实现数据变更检查和通知发起的。\n// 这里遍历所有的 slot for (SlotState slotState : slotTableStates.slotStates.values()) { try { sync(slotState, syncSessionIntervalMs, syncLeaderIntervalMs, slotTableEpoch); } catch (Throwable e) { SYNC_ERROR_LOGGER.error( \u0026amp;quot;[syncCommit]failed to do sync slot {}, migrated={}\u0026amp;quot;, slotState.slot, slotState.migrated, e); } } 按 slot 分组汇总数据版本。data 与每个 session 的连接都对应一个 SyncSessionTask，SyncSessionTask 负责执行同步数据的任务，核心同步逻辑在com.alipay.sofa.registry.server.data.slot.SlotDiffSyncer#sync\n方法中完成，大致流程如下面时序图所示：\n这上图圈红部分的逻辑第四步，根据 dataInfoId diff 更新 data 内存数据，这里仅处理了被移除的 dataInfoId，对于新增和更新的没有做任务处理，而是通过后面的第 5 -7 步来完成；这么做的主要原因在于避免产生空推送导致一些危险情况发生。\n第 5 步中，比较的是所有变更 dataInfoId 的 pub version，具体比较逻辑参考后面 diffPublisher 小节中的介绍。\n数据变更的事件通知处理 数据变更事件会被收集在 DataChangeEventCenter 的 dataCenter2Changes 缓存中，然后由一个守护线程 ChangeMerger 负责从 dataCenter2Changes 缓存中不断的读取，这些被捞到的事件源会被组装成 ChangeNotifier 任务，提交给一个单独的线程池(notifyExecutor)处理，整个过程全部是异步的。\n拉模式下的数据同步流程 拉模式下，由 SessionServer 负责发起， com.alipay.sofa.registry.server.session.registry.SessionRegistry.VersionWatchDog\n默认情况下每 5 秒扫描一次版本数据，如果版本有发生变更，则主动进行拉取一次，流程大致如下：\n需要注意的是，拉模式对推送流程的补充，这里的 version 是每个 sub …","date":1649228400,"description":"源码解析｜数据同步","dir":"projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b78da7b0c10e92e61edba8aeb05d8bac","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","publishdate":"2022-04-06T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","summary":"本篇主要对 SOFARegistry 的数据同步模块进行解析，对于注册中心的概念以及 SOFARegistry 的基础架构不做过多阐述，相关介绍可以见海量数据下的注册中心 - SOFARegistry 架构介绍 本文主要写","tags":["“源码解析”"],"title":"源码解析｜数据同步","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/","wordcount":3696},{"author":"Junlong Liu","categories":"SOFAStack","content":" 文｜Junlong Liu\nShopee Digital Purchase \u0026amp;amp; Local Services Engineering\n本文1743字 阅读 6分钟\n贡献者前言 我是在开发工作过程中了解到 Holmes 的，为了保障系统稳定性需要一个性能排查工具，因此也需要一个保留现场的性能监控工具。当我在网上查询该方面的开源库时，发现可用的并不多。后续找到 MOSN 社区的 Holmes ，发现这个开源库功能基本齐全、扩展性也高，特别是 GCHeapDump 这个业界领先的功能，对解决内存升高的问题十分有用。\n2021 年年末了解到的 Holmes 组件，然后开始了解 Holmes 所在的 MOSN 社区。Holmes 作为性能排查工具，核心功能是及时发现性能指标异常，并对系统进行 Profiling。\n由于 Holmes 还处于萌芽期，除了 Readme 之外的文档资料并不多。还有一些 Holmes 当时不支持的功能，比如动态配置调整与上报。Holmes 当时也还没发布第一个版本，但是自己对这方面也有兴趣和理解，于是在 GitHub 上提了几个 Issue 讨论，社区回复的速度十分快。后续在社区前辈们的指导下提了 PR，也因此通过 Holmes 的代码设计学习到了很多关于开源组件的设计理念。\n因此我决定参与开源社区并贡献代码，以解决实际需求。有了一定的了解和经验之后，通过和人德前辈讨论，总结这样一篇分享文章。\n本文将介绍 Holmes 的使用场景、快速开始案例、多个监控类型、设计原理、扩展功能与如何借助 Holmes 搭建起一套简单的性能排查系统，欢迎大家留言指导。\nHolmes 使用场景 对于系统的性能尖刺问题，我们通常使用 Go 官方内置的 pprof 包进行分析，但是难点是对于一闪而过的“尖刺”，开发人员很难及时保存现场：当你收到告警信息，从被窝中爬起来，打开电脑链接 VPN，系统说不定都已经重启三四趟了。\nMOSN 社区的 Holmes 是一个基于 Golang 实现的轻量级性能监控系统，当应用的性能指标发生了异常波动时，Holmes 会在第一时间保留现场，让你第二天上班可以一边从容地喝着枸杞茶，一边追查问题的根因。\nQuick Start 使用 Holmes 的方式十分简单，只需要在您的系统初始化逻辑内添加以下代码：\n// 配置规则 h, _ := holmes.New( holmes.WithCollectInterval(\u0026amp;quot;5s\u0026amp;quot;), // 指标采集时间间隔 holmes.WithDumpPath(\u0026amp;quot;/tmp\u0026amp;quot;), // profile保存路径 holmes.WithCPUDump(10, 25, 80, 2 * time.Minute), // 配置CPU的性能监控规则 holmes.WithMemDump(30, 25, 80, 2 * time.Minute),// 配置Heap Memory 性能监控规则 holmes.WithGCHeapDump(10, 20, 40, 2 * time.Minute), // 配置基于GC周期的Heap Memory 性能监控规则 holmes.WithGoroutineDump(500, 25, 20000, 100*1000, 2 * time.Minute), //配置Goroutine数量的监控规则 ) // enable all h.EnableCPUDump(). EnableGoroutineDump(). EnableMemDump(). EnableGCHeapDump().Start() 类似于 holmes.WithGoroutineDump(min, diff, abs,max,2 * time.Minute) 的 API 含义为:\n当 Goroutine 指标满足以下条件时，将会触发 Dump 操作。\n当 Goroutine 数大于 Max 时，Holmes 会跳过本次 Dump 操作，因为当 Goroutine 数过大时，Goroutine Dump 操作成本很高。\n2 * time.Minute 是两次 Dump 操作之间最小时间间隔，避免频繁 Profiling 对性能产生的影响。\n更多使用案例见文末的 Holmes 使用案例文档。\nProfile Types Holmes 支持以下五种 Profile 类型，用户可以按需配置。\nMem: 内存分配\nCPU: CPU 使用率\nThread: 线程数\nGoroutine: 协程数\nGCHeap: 基于 GC 周期监控的内存分配\n指标采集 Mem、CPU、Thread、Goroutine 这四种类型是根据用户配置的 CollectInterval，每隔一段时间采集一次应用当前的性能指标，而 gcHeap 时基于 GC 周期采集性能指标。\n本小节会分析一下两种指标。\n根据 CollectInterval 周期采集 Holmes 每隔一段时间采集应用各项指标，并使用一个固定大小的循环链表来存储它们。\n根据 GC 周期采集 在一些场景下，我们无法通过定时的 memory dump 保留到现场。比如应用在一个 CollectInterval 周期内分配了大量内存，又快速回收了它们。此时 Holmes 在周期前后的采集到内存使用率没有产生过大波动，与实际情况不符。\n为了解决这种情况，Holmes 开发了基于 GC 周期的 Profile 类型，它会在堆内存使用率飙高的前后两个 GC 周期内各 Dump 一次 Profile，然后开发人员可以使用 pprof \u0026amp;ndash;base 命令去对比两个时刻堆内存之间的差异。\n根据 GC 周期采集到的数据也会放在循环列表中。\n规则判断 本小节介绍 Holmes 是如何根据规则判断系统出现异常的。\n阈值含义 每个 Profile 都可以配置 min、diff、abs、coolDown 四个指标，含义如下:\n当前指标小于 min 时，不视为异常。\n当前指标大于 (100+diff)100% 历史指标，说明系统此时产生了波动，视为异常。\n当前指标大于 abs (绝对值)时，视为异常。\nCPU 和 Goroutine 这两个 Profile 类型提供 Max 参数配置，基于以下考虑：\nCPU 的 Profiling 操作大约会有 5% 的性能损耗，所以当在 CPU 过高时，不应当进行 Profiling 操作，否则会拖垮系统。\n当 Goroutine 数过大时，Goroutine Dump 操作成本很高，会进行 STW 操作，从而拖垮系统。（详情见文末参考文章）\nWarming up 当 Holmes 启动时，会根据 CollectInterval 周期采集十次各项指标，在这期间内采集到的指标只会存入循环链表中，不会进行规则判断。\n扩展功能 除了基本的监控之外，Holmes 还提供了一些扩展功能：\n事件上报 您可以通过实现 Reporter 来实现以下功能：\n发送告警信息，当 Holmes 触发 Dump 操作时。\n将 Profiles 上传到其他地方，以防实例被销毁，从而导 …","date":1649142000,"description":"社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析","dir":"blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"87409f8ec80db088a42f856f0baf16da","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","publishdate":"2022-04-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","summary":"文｜Junlong Liu Shopee Digital Purchase \u0026amp; Local Services Engineering 本文1743字 阅读 6分钟 贡献者前言 我是在开发工作过程中了解到 Holmes 的，为了保障系统稳定性需要一个性能排查工具，","tags":["SOFAStack"],"title":"社区文章｜MOSN 社区性能分析利器——Holmes 原理浅析","type":"blog","url":"/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/","wordcount":2934},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@ 毛晨斌 提问：\n 使用 Layotto 是不是客户端代码需要重新实现，全部调用 Layotto 提供的API？多少正式的项目正在使用 Layotto?\n A：目前蚂蚁的落地用户将客户端 SDK，改成调用 Layotto；现在在搞无侵入方案。\n 开源版服务器端支持哪些中间件，客户端无侵入支持哪些中间件？\n A：1. 已经落地的方案是：将各种中间件的 Java SDK，改成调用 Layotto （比如把 xxx-MQ-sdk 内部逻辑改成调layotto pubsub API，但是对业务代码暴露的接口不变)。业务系统需要升级下 SDK，业务代码不用改。这部分没开源，因为是改内部中间件的 SDK，这些中间件本身没开源。 2. 开源版服务器端支持那些中间件：每类 API 有支持的组件列表。 https://mosn.io/layotto/#/zh/component_specs/sequencer/common 其中 state API、pubsub API 因为复用了 Dapr 的组件，所有 Dapr 组件都支持。https://docs.dapr.io/zh-hans/reference/components-reference/supported-state-stores/\n3.客户端支持哪些：目前有 .net java go 的 Layotto SDK，有个 layotto-springboot 刚合并。SDK 在 https://github.com/layotto\n 关于无侵入方案：后面想把协议转换的事情放到 Layotto 做、让用户接入 Layotto 时不用改客户端 SDK，不过方案还在讨论，最近会写个 proposal。 5.现在还没有现成的客户端无侵入 SDK，老系统接入 Layotto 需要改原来的 SDK。\n「SOFABolt」：https://github.com/sofastack/sofa-boot\n黄润良 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?upstream 的 ip access 日志怎么打印来访日志呢，主要是负载均衡后访问到后段的哪个 IP?\n A：你要在 errorlog 打印吗？你可以配置 accesslog，一个请求一条的。你的 tracelog 也可以打印的。https://github.com/mosn/mosn/blob/master/pkg/log/accesslog.go\n [WARN][downStream]reset stream reason ConnectionTermination[proxy][downstream]processError=downstreamReset proxyld:2204350,reason:ConnectionTermination\n A：downstream 的连接断链了。比如你 curl 访问 MOSN，在 reponse 回复之前 Ctrl+C 终止断链接，MOSN 就会打印这个日志，也就是还没有回复请求，client 就断链了。 然后 client 自己有超时，可能就断链了。\n「MOSN」：https://github.com/mosn\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nHolmes 本周发布 Holmes 发布 v1.0 版本\nHolmes 是 MOSN 社区开源的 go 语言 continous profiling 组件，可以自动发现 cpu、 memory、goroutine 等资源的异常，并自动 dump 异常现场 profile，用于事后分析定位。也支持上传 profile 到自动分析平台，实现自动问题诊断、报警。\n「发布报告」：https://github.com/mosn/holmes/releases/tag/v1.0.0\n「Holmes 原理介绍」：https://mosn.io/blog/posts/mosn-holmes-design/\n本周推荐阅读 HAVE FUN | Layotto 源码解析\n 异构注册中心机制在中国工商银行的探索实践\n Nydus 镜像加速插件迁入 Containerd 旗下\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1648796400,"description":"SOFA Weekly | 开源新知、本周 QA、新手任务","dir":"blog/sofa-weekly-20220401/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b94eecd772ed0839dc842cdafb587990","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220401/","publishdate":"2022-04-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220401/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源新知、本周 QA、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220401/","wordcount":1838},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFAMeetup\u0026amp;amp;木兰技术开放日（云原生专场）\n 活动时间：2022 年 04 月 01 日（周五）09:30-12:00\n 活动形式：线上直播\n 资料下载：\n 《如何建立云原生时代的 DevOps 工具链》\n《在大规模集群中落地 Layotto 这种多运行时架构是一种什么样的体验》\n《云原生多集群治理实践》\n《蚂蚁服务发现的大规模实践与展望》\n活动议程 活动回顾 直播主题：木兰技术开放日\u0026amp;amp;SOFAMeetup（云原生专场）\n直播时间：2022 年 4 月 1 日 上午 9:30\n议题分享：\n《中国木兰社区助力云原生扬帆远航》 王庆 英特尔研发总监、木兰开源社区技术委员会成员\n 嘉宾简介：\n王庆，英特尔软件与先进技术事业部云基础设施软件研发总监、开放基础设施基金会个人独立董事、Linux 基金会下属 SODA 基金会外联委员会主席。木兰开源社区技术委员会成员、中国计算机学会CCF开源发展委员会常务委员。\n曾经参与或领导团队开发 Xen、tboot、Yocto、OpenStack 等开源项目。 目前，他和他的团队正在积极致力于云计算、云原生、边缘计算、网络和存储、以及云性能评估与优化等方向，涵盖 Kubernetes、Containerd、Istio、Envoy、Ceph、Akraino 等等。该团队多年来和业界建立了良好的合作关系，是开源云计算软件的一支中坚力量。\n《如何建立云原生时代的 DevOps 工具链》 刘新 都广科技创始人、建木核心开发者。\n 嘉宾简介：\n刘新，都广科技创始人、建木核心开发者。\n从事软件开发与架构设计工作超过 10 年。 曾在通讯、金融、医疗与云计算等行业担任过首席架构师、技术总监、产品总监和CTO等技术职务。\n个人主要兴趣在分布式架构、DevOps、系统优化、工程质量提升等方面。 目前主要精力在开源建木社区运营并负责后端代码的开发贡献。\n议题简介：\n云原生离不开 DevOps，DevOps 作为云原生架构落地的三驾马车的重要性不言而喻。而 DevOps 的成功实施，往往依赖一组集成化的工具链。那么在当前 DevOps 工具百花齐放的情况下，云原生时代的 DevOps 工具链又应该如何建立呢？\n《在大规模集群中落地 dapr 或 Layotto 这种多运行时架构是什么样的体验》 周群力（目前在蚂蚁集团中间件团队负责 Layotto 项目研发）\n 嘉宾简介：\n周群力（花名：仪式）目前在蚂蚁集团中间件团队负责 Layotto 项目研发\n议题简介：\n随着 Service Mesh 在蚂蚁集团内部的大规模落地，我们逐渐遇到了新的挑战，这让我们迫切的寻找新的解决方案。 Service Mesh 通过引入 sidecar 来简化服务治理，而 dapr 这种“多运行时”项目告诉大家：sidecar 能做的事情远不止于此。\n\u0026amp;ldquo;多运行时\u0026amp;rdquo;这种架构真的有这么好么？会不会太过理想化？\n实际落地时会踩什么坑，怎么解决，最终又能带来什么价值？\n在大规模集群中，落地 dapr或layotto 这种多运行时架构是什么样的体验？\n听众收益：\n了解蚂蚁集团在Service Mesh大规模落地以后遇到的新问题以及对于如何解决这些问题的思考。\n了解“多运行时架构”是什么，解决什么问题 了解目前“多运行时架构”相关开源项目在大规模集群落地时会遇到什么问题，有什么不足，如何解决，以及最终带来什么收益 帮助同样在做“多运行时架构”项目的朋友们躲坑、少走弯路。\n《云原生多集群治理实践》 徐迪 腾讯云技术专家，Clusternet 项目发起人。\n 嘉宾简介：\n腾讯云技术专家，Clusternet 项目发起人。在云原生领域有着丰富的经验，也是国内较早参与 Kubernetes 社区的开发者。热爱开源，拥抱开源，并多次在 KubeCon 各大峰会上发表演讲。\n议题简介：\n在过去的数年里，云计算领域经历了多次巨大的变革，当前越来越多的组织将应用部署在本地和云上的多个基础设施平台上，这些平台可能是两个公共云服务提供商，或者两个私有云，或者多地域的边缘云。新的形态导致基础设施的管理和应用治理的方式发生变化，传统的技术架构与管理方式增加了复杂性和风险，难以满足跨多个平台的应用服务部署和治理的挑战，代表业内最新理念的 Clusternet 项目应运而生。在这次演讲中，你将了解到 Clusternet 的最新进展和先进特性。\n《蚂蚁服务发现的大规模实践与展望》 肖健 目前在蚂蚁集团中间件团队负责 SOFARegistry 项目研发\n 嘉宾简介：肖健（花名：昱恒）目前在蚂蚁集团中间件团队负责 SOFARegistry 项目研发\n议题简介：\nnaming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。\n本次分享将会包含以下内容：\n 蚂蚁内部实践\n naming在云原生时代下的发展方向及趋势\n 总结和展望\n 听众收益：\n 了解蚂蚁集团在SOFARegistry新挑战及云原生时代的思考。\n 了解SOFARegistry实践经验。\n 了解蚂蚁集团对未来naming的思考及naming在云原生方向上的探索。\n 了解未来SOFARegistry的发展和相关的社区动向。\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1648796400,"description":"SOFAMeetup\u0026木兰技术开放日-云原生专场","dir":"activities/sofa-meetup-14/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"89cf0108c9b9e15c842c69bdc4a95876","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-14/","publishdate":"2022-04-01T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-14/","summary":"概要 活动主题：SOFAMeetup\u0026amp;木兰技术开放日（云原生专场） 活动时间：2022 年 04 月 01 日（周五）09:30-12:00 活动形式：","tags":["SOFA"],"title":"【活动回顾】《SOFAMeetup\u0026木兰技术开放日-云原生专场》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-14/","wordcount":2074},{"author":"Carver_007","categories":"SOFAStack","content":" 为了支撑超大规模集群以及大内容传输的支持，增加传输效率，减少网络带宽，考虑对消息进行压缩处理，SOFARegistry的data和session以及session和client (目前只有go支持）添加了对压缩数据传输的支持，同时增加缓存来减少压缩带来的较高的cpu的消耗。\n SOFARegistry 通讯默认支持了哪些压缩算法 目前 SOFARegistry 默认支持了 gzip 和 zstd 两种压缩算法。 gzip 是目前使用最广泛，压缩比较高的一种压缩算法。 zstd 是由 Facebook 的 Yann Collet 开发的一个无损数据压缩算法，Zstandard 在设计上与DEFLATE（.zip、gzip）算法有着差不多的压缩比，但是相比 gzip 有更高的压缩和解压缩速度。\n 两种压缩的基本实现代码如下： 整体结构如下如： CompressUtils 工具类采用静态 Map 对象（compressorMap），以编码方式为 key，以具体编码对应的压缩对象为 value 进行装载，然后待其使用的时候通过编码方式进行获取对应的编码对象实现类。 启动的时候装载到一个 Map 对象，key 为上图的两种编码常量，value 为具体实现类。当需要压缩的时候通过一下 find 方法或者重载方法进行获取具体压缩对象。代码如下：\n缓存的使用 由于压缩和解压缩的对资源的消耗极大，SOFARegistry采用了Google的Guava缓存来提升部分性能，当需要获取压缩的时候首选从缓存中获取，缓存中没有, 才进行压缩操作，同时将压缩结果缓存起来，以便下次获取的时候能直接获取。 具体代码细节参考如下：\n 小注：默认采用hession进行序列化\n 3.数据推送以及通讯两端的数据协商机制 发送端压缩对象的选择由订阅者接收端配置信息决定，所以可以保证发送端和接收端的压缩格式的统一。\n小结： SOFARegistry 是一种定位大型金融级分布式注册中心，数据通信定位偏向于大数据包大流量，因此对于数据传输效率和数据安全较为关注，采用高效的压缩方式，能有效的增加传输效率和使用安全性。目前支持的两种压缩方式都是市面上主流的压缩算法，同时配合这缓存的机制，极好的解决了大数据包带来大流量对网络带宽的压力，因此非常适合大型项目，但是相较于小型项目，这种压缩机制就显得很多余，压缩带来较高的 cpu 压力，因此 SOFARegistry 同时支持关闭压缩传输方式，以支持一些小型项目，具体使用根据业务来定。\n","date":1648623600,"description":"源码解析｜通讯数据压缩","dir":"projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1eea84eb058815d251783d98ba763865","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","publishdate":"2022-03-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","summary":"为了支撑超大规模集群以及大内容传输的支持，增加传输效率，减少网络带宽，考虑对消息进行压缩处理，SOFARegistry的data和sessi","tags":["“源码解析”"],"title":"源码解析｜通讯数据压缩","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/","wordcount":901},{"author":"SOFAStack","categories":"SOFAStack","content":" 文｜颜高飞\n【工商银行】金融科技研究院云计算实验室\n本文 2651 字 阅读 5 分钟\n前言 中国工商银行于 2014 年率先启动银行核心业务系统的分布式架构转型探索，自主研发了同业领先的分布式服务平台。\n注册中心为服务平台提供了核心的服务发现功能，其健壮性对服务调用的成功率起着至关重要的作用。近年来，随着服务架构落地范围迅速扩大，注册中心性能容量支撑能力面临更高挑战。\n工商银行结合金融业实际运行场景，对注册中心架构进行了深度定制及优化，不断探索性能容量和高可用能力极限。\nPART. 1 问题及挑战 工商银行分布式服务平台选用 zookeeper 作为分布式服务注册中心。\nzookeeper 在业界分布式系统中使用广泛，具有大规模应用场景，为用户提供高效、稳定的分布式协调服务。zookeeper 支持集群化部署、性能可扩展，可用性也较高，主要表现有：\n1、半数存活即可用特性，使其容灾性能较强\n只要选举节点中有过半节点正常工作，集群即可正常对外提供服务。若集群内个别服务器宕机，客户端会自动切换连接至其他可用服务器。\n2、会话机制，使客户端注册信息保持稳定\n客户端与 zookeeper 服务端之间通过心跳保持会话，默认会话超时 40s。若集群正常对外服务，在会话超时后，zookeeper 服务端将剔除客户端注册信息。而若集群整体不可用，会话不会过期，在注册中心集群恢复后，能自动从快照中重新恢复故障前的会话和注册信息，无需外部干预。\n3、集群提供 observer 机制，实现读写分离、流量隔离\nobserver 节点不参与集群选举，只承担客户端连接和请求，提升整体吞吐量；分担选举节点压力，提升集群稳定性。在实施 observer 分组的情况下，还可实现客户端流量隔离。\n在金融业务实际运行场景中，工商银行搭建了以选举节点为核心、扩展部署 observer 节点的 zookeeper 注册中心集群，并在工商银行稳定运行多年。\n理论上，当 zookeeper 注册中心集群出现故障时，服务调用不会受到影响。\n但在实际混沌工程故障演练过程中，我们发现：偶发场景下，分布式服务平台存在因 zookeeper 系统资源故障或其他问题导致影响业务交易的现象。\n具体问题列举如下：\n 问题一：单服务扩容后提供方节点数过多 触及 zookeeper 推送报文 4M 的上限，从而导致 zookeeper 服务器性能压力过大，未能及时处理其他服务注册请求，影响交易。\n 问题二：zookeeper 集群 leader 服务器内存故障 进程僵死后集群重新选举产生新 leader，但集群内部分服务器未及时感知新 leader，导致部分服务提供方掉线，影响交易。\n 问题三：zookeeper 注册数据大幅增大后 集群故障重新选举后 leader 向其他节点同步的数据量过大，服务器网络到达瓶颈，导致部分服务器未及时加入新集群，影响交易。\n基于以上问题，工商银行一方面对 zookeeper 源码进行了深度定制，另一方面开始着手研究提升服务注册和服务发现高可用能力的机制。\nPART. 2 建设多注册多订阅机制，提升服务调用稳定性 为规避单注册中心集群故障而影响服务调用的问题，工商银行构建了多点接入的高可用注册模型（如图 1 所示）。\n说明：上图中 DC1 和 DC2 为 2 个机房，分别部署有 2 个独立的注册中心集群。DC1 和 DC2 中部署的提供方和消费方均注册、订阅自两个注册中心集群。DC1 中的消费方优先使用 DC1 注册中心推送的提供方列表，DC2 中的消费方优先使用 DC2 注册中心推送的提供方列表。\n在同城双机房内独立部署两个 zookeeper 集群，提供方注册服务至双注册中心，消费方也从双注册中心订阅服务。消费方优先使用与其在同一机房内的注册中心推送的数据，当同机房注册中心集群发生故障时，其他机房的注册中心可接管。注册中心集群故障接管过程中，服务正常调用。\n双注册双订阅机制建成后，分布式服务平台多次完美应对了底层系统资源故障、网络隔离等问题，分布式服务注册和服务发现稳定性显著提升。\n基于双 zookeeper 集群部署的双活架构，因双集群注册中心组件技术栈相同，极小概率下仍存在系统性交易风险——若两个 zookeeper 注册中心集群在同一时刻均出现同一类型故障时（比如同时达到性能瓶颈），业务交易仍然可能会受到影响。\n因此，为规避极小概率的系统性风险，工商银行进一步开展异构注册中心建设，追求极致的服务注册和发现高可用能力。\nPART. 3 建设异构注册中心，规避单一技术栈风险 注册中心异构部署，进一步提升高可用能力\n工商银行开展异构注册中心建设，在部署 zookeeper 集群的同时对等部署一套独立的异构注册中心集群。业务系统同时向 zookeeper 和异构注册中心两个集群注册并进行服务订阅（如图 2 所示）。\n异构注册中心与 zookeeper 协同工作，提升注册中心整体对外服务能力。当 zookeeper 集群与异构注册中心任一集群发生系统性故障时，另一注册中心集群可接管（如图 3 所示数据表结构）。\n说明：上图中 zookeeper 集群故障，异构注册中心正常工作，服务仍可正常注册、订阅及调用。\n提出合并订阅机制，使注册中心故障时迁移更加平滑\n工商银行原有多注册中心订阅机制，消费方优先使用某一注册中心推送的提供方列表，仅当该注册中心上无任一可用提供方，消费方才切换使用下一注册中心推送的数据。此时若优先使用的注册中心因故障推送了不完整的提供方列表，消费方集中调用这些提供方，可能导致“提供方负载不均”、“触发并发限流”等问题。\n为保障建设异构注册中心后注册中心故障时迁移更加平滑，工商银行研究并提出了消费方合并订阅机制：在消费方侧合并 zookeeper 和异构注册中心的订阅视图，各注册中心订阅数据合并后再刷新 invoker 缓存。\n即使某注册中心故障推送了空或者不完整的提供方列表，合并后的数据仍是有效的，提高了消费方筛选提供方的效率，提升交易成功率。\n注册中心异构部署和消费方合并订阅机制建成后，混沌模拟注册中心 CPU 满载、内存高负荷、磁盘故障、网络抖动、网络隔离等故障场景，提供方负载均衡，交易无失败，符合预期。同时，合并订阅机制还能额外降低多注册中心模式下消费方缓存提供方列表所占用的内存。\n基于以上技术储备及基础建设，工商银行于 2020 年开展异构注册中心建设，规避行内注册中心单一技术栈风险，进一步提升了注册中心核心组件在整个分布式体系中的高可用能力。\nPART. 4 未来展望 为满足分布式服务平台金融级高可用的需求，工商银行探索并提出异构注册高可用方案，消除了大规模服务注册场景下单一注册中心存在的系统性风险，保障金融系统的稳健运行。\n未来，工商银行将在异构注册的基础上进一步推动单元化部署运维转型，打破注册中心为全局唯一流量枢纽的现状，实现交易流量在单元内部最大限度完成闭环，辅以单元自动切换实现故障隔离，进一步控制区域性故障场景下的故障爆炸半径，全面提升分布式服务平台流量控制、高可用接管能力，为同业微服务架构规模化应用提供最佳实践和范例。\n本周推荐阅读 “SOFA 星球” …","date":1648537200,"description":"异构注册中心机制在中国工商银行的探索实践","dir":"blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"29e6ac47144c6efb8a23731c2f6351d2","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","publishdate":"2022-03-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","summary":"文｜颜高飞 【工商银行】金融科技研究院云计算实验室 本文 2651 字 阅读 5 分钟 前言 中国工商银行于 2014 年率先启动银行核心业务系统的分布式架构转型探索，自主研","tags":["SOFAStack"],"title":"异构注册中心机制在中国工商银行的探索实践","type":"blog","url":"/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/","wordcount":2684},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@韩升 提问：\n 问下 SOFABolt 是否可以单独集成到 Spring Cloud 体系中？不依赖与 SOFABoot？还是直接引用 Bolt 的组件，然后使用原生的方式处理？\n A：直接用 Bolt 自己的 API 就行。\n「SOFABolt」：https://github.com/sofastack/sofa-boot\n**沄澈|che ** 提问：\n RPC 序列化 Localdatetime 有问题，改为 Date 类型后正常, 你知道原因吗?\n A：要看 SerializerFactory 对 Localdatetime 的支持了。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nHolmes 本周发布 Holmes 发布 v1.0 版本\nHolmes 是 MOSN 社区开源的 go 语言 continous profiling 组件，可以自动发现 cpu、 memory、goroutine 等资源的异常，并自动 dump 异常现场 profile，用于事后分析定位。也支持上传 profile 到自动分析平台，实现自动问题诊断、报警。\n「发布报告」：https://github.com/mosn/holmes/releases/tag/v1.0.0\n「Holmes 原理介绍」：https://mosn.io/blog/posts/mosn-holmes-design/\n本周推荐阅读 SOFAArk Committer 专访｜看它不爽，就直接动手改！\n “SOFA 星球”闯关计划 ——Layotto 飞船\n 探索 SOFARegistry（一）｜基础架构篇\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1648278000,"description":"SOFA Weekly | 开源新知、Holmes 本周发布、新手任务","dir":"blog/sofa-weekly-20220329/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b4b14b0e38ee5d01c12019bbab406c50","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220329/","publishdate":"2022-03-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220329/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开源新知、Holmes 本周发布、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220329/","wordcount":1205},{"author":"kuaile-zc","categories":"SOFAStack","content":" 大致代码流程 推送延迟的计算方式 首次订阅和后续推送延迟计算的区分 如何统计各个阶段的耗时 前言： 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析\n 1、大致代码流转流程 起源于此类 com.alipay.sofa.registry.server.session.push.PushProcessor @PostConstruct 注解由 java 源码提供初始化类会运行此方法，那么就从 init() 函数开始我们今天的故事！\n1.初始化 KeyedThreadPoolExecutor 类（com.alipay.sofa.registry.task.KeyedThreadPoolExecutor）\n2.初始化 initTaskBuffer()\n3.创建针对 push 的 cleaner 者创建过程中会将此线程设置为守护者线程 t.setDaemon(true)\n守护者线程：是指在程序运行的时候在后台提供一种通用服务的线程，比如垃圾回收线程就是一个很称职的守护者，并且这种线程并不属于程序中不可或缺的部分。因此，当所有的非守护线程结束时，程序也就终止了，同时会杀死进程中的所有守护线程。反过来说，只要任何非守护线程还在运行，程序就不会终止。\n源码给的默认值\ncoreSize = OsUtils.getCpuCount() * 3 CPU 数量 * 3\ncoreBufferSize = coreSize * 3000\n让我们来看看初始 KeyedThreadPoolExecutor 会发生的故事。\n1.设置基本参数，添加 Prometheus 监控。\n2.通过配置创建 AbstractWorker[] workers 数组类型。\n3.设置每个 worker 线程为\n让我们来看一下 createWorkers（） 这个方法干了什么事。\n1.创建阻塞队列\n2.创建多个 worker 数量根据 coreSize 并且所以的 worker 都共享所有队列\n阻塞队列被包装了一层详解如下：\n前置知识原生阻塞队列具有以下特性 ArrayBlockingQueue：基于数组的阻塞队列实现，在 ArrayBlockingQueue 内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外， ArrayBlockingQueue 内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。\nLinkedBlockingQueue：基于链表的阻塞队列，同 ArrayListBlockingQueue 类似，其内部也维持着一个数据缓冲队列（该队列由一个链表构成），当生产者往队列中放入一个数据时，队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时（LinkedBlockingQueue 可以通过构造函数指定该值），才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而 LinkedBlockingQueue 之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。\ncom.alipay.sofa.registry.task.BlockingQueues 存储队列的变量是 BlockingQueue[] queues 因为入参 array（false）所以最终生成的是数组类型的 LinkedBlockingQueue 阻塞队列 coreSize 个数组 coreBufferSize 个初始队列大小。\n我们可以看到 WorkerImpl 类的结构如下\n我们用图来解析一下 WorkerImpl 的工作原理\n所以当有服务订阅之后会生成订阅任务 WorkerImpl 将会执行任务，然后在任务执行过程中延迟链路跟踪。整个推送结束之后会有回调函数进行统计。\n2.推送延迟的计算方式 创建推送任务的时候 PushTask（）\nPushProcessor 中的都 push（）开启 push 任务\n1.检查是否是停止的推送任务和是否是灰度推送功能。\n2.task.trace.startPush() 开始任务记录当前开始时间值 PushTrace.pushStartTimestamp\n3.检查 push 任务运行情况 如果没有记录则表示正常， 如果已经有记录则：一种情况超时删除任务第二则是重试\n4.task.createPushData() 创建 Push data\n5.放入 push 记录为了未来重试或者异常情况获取记录做判断\n6.创建回调函数，完成 push 任务之后回调函数生效\n回调函数代码如下\nPushClientCallback.onCallback\n回调函数 PushClientCallback(task) onCallback(Channel channel, Object message) 调用了 this.pushTask.trace.finishPush（）结束了整个 push 链路追踪。\n最后算出大量的数据进行追踪 PushTrace.finish()\n3.首次订阅和后续推送延迟计算的区分 见下表/图统计\n4.如何统计各个阶段的耗时 此图为理解链路追踪过程：\n 字段 字段解释 表达式 根据上图分析步骤 首次订阅和后续推送计算方式是否有区别（默认不填为否） 注解 subRegTimestamp 订阅者订阅请求的时候的时间戳 pushStartTimestamp push 推送开始的时间戳 System.currentTimeMillis() 任务开始获取当前时间戳 pushFinishTimestamp push 推送完成的时间戳 System.currentTimeMillis() 结束之后调用结束方法之后获取当前时间戳 pushCause.triggerPushCtx.firstTraceTimes 第一次通知 seesion 数据变更的时间 lastTriggerSession(pushCause.triggerPushCtx.lastTraceTimes) 最后一次触发session(SOFARegistry 的组件之一）进行变更推送 pushCause.datumTimestamp 主动 pub：那时间就是在 data 端触发修改 datum 的时间如果是主动 sub：那时间就是 sub 注册的当前时间 是 lastPushTimestamp 上一次 push 的时间首次订阅：如果是首次订阅，就是订阅注册的时间，用于后续的过滤，防止重复计算已经推送过的数据的延迟。后续推送：上一次 push 的时间 是 lastPushTimestamp 上一次 push 的时间首次订阅：如果是首次订阅，就是订阅注册的时间，用于后续的过滤，防止重复计算已经推送过的数据的延迟。后续推送：上一次 push …","date":1648018800,"description":"源码解析｜推送延迟 trace","dir":"projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"585ac9eb55d6cd8f21a0fd12a313e8d8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","publishdate":"2022-03-23T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","summary":"大致代码流程 推送延迟的计算方式 首次订阅和后续推送延迟计算的区分 如何统计各个阶段的耗时 前言： 此次源码解析均在 sofa-registry:6.1.4-SNAPSHOT 版本下分析 1、大致代码流转流程 起","tags":["“源码解析”"],"title":"源码解析｜推送延迟 trace","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/","wordcount":2584},{"author":"行动","categories":"SOFAStack","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁集团开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁集团的业务发展驱动下，近十年间已经演进至第六代。\n 本文为《源码解析｜数据倒排索引》，作者行动，来自高德。\n 《源码解析》系列由 SOFA 团队和源码爱好者们出品。\n GitHub 地址：https://github.com/sofastack/sofa-registry\nSOFARegistry 分层设计 我们知道一个典型的服务发布流程是这样的。\n 图1 服务发布流程\n 如上图、服务注册中心在RPC远程调用中的通常是中间协调者的角色，服务发布者Publisher将服务的发布信息（服务名称、ip、端口号等信息)）发布到注册中心 Registry 中、通常保存在 Registry 内部的数据结构中。服务订阅者在第一次调用服务的时候、会通过 Registry 找到所要调用服务的提供者列表。缓存在本地然后通过负载均衡算法找到一个具体的服务提供者。调用这个具体的服务提供者接口。\n了解了一个典型的 RPC 调用的流程、我们来看看 SOFARegistry 作为一个注册中心内部包含哪几种角色。\n Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\n SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\n DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。\n MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n 图2 SOFARegistry 分层设计 如图 2 所示、在 SOFARegistry 中、客户端 client 直接和 session 通讯，而不是传统意义上的Data节点、这种添加中间一层隔离 DataServer 和客户端的做法。主要是为了处理客户端连接风暴。对这种分层设计。\n感兴趣的可以参考 《海量数据下的注册中心 - SOFARegistry 架构介绍》的 “如何支持海量客户端” 章节，这里不再赘述。文章下面也是主要围绕 Session层展开。\nSessionServer 启动过程 SessionServer 模块的各个 bean 在 JavaConfig 中统一配置，JavaConfig 类为 SessionServerConfiguration，启动入口类为 SessionServerInitializer，该类不由 JavaConfig 管理配置，而是继承了 SmartLifecycle 接口，在启动时由 Spring 框架调用其 start 方法。 该方法中调用了 SessionServerBootstrap#start 方法（图 3），用于启动一系列的初始化服务。 从代码中可以看出，SessionServer 服务在启动时，会启动 SessionServer、SessionSyncServer、HttpServer 三个 bolt 服务。在启动这些 Server 之时，DataServer 注册了一系列 bolt Handler 来处理各类消息。\npublic void start() { try { openSessionSyncServer(); startupRetryer.call( () -\u0026amp;gt; { connectMetaServer(); return true; }); startupRetryer.call( () -\u0026amp;gt; systemPropertyProcessorManager.startFetchPersistenceSystemProperty()); startScheduler(); openHttpServer(); startupRetryer.call( () -\u0026amp;gt; { connectDataServer(); return true; }); sessionRegistryStrategy.start(); configProvideDataWatcher.start(); openSessionServer(); } catch (Throwable e) { LOGGER.error(\u0026amp;quot;Cannot bootstrap session server :\u0026amp;quot;, e); throw new RuntimeException(\u0026amp;quot;Cannot bootstrap session server :\u0026amp;quot;, e); } } SessionServer 保存了哪些数据 在了解了 SessionServer 的启动过程、明白 SessionServer 作为 DataServer 的代理层、有着非常重要的位置。能够分摊一部分对 DataServer 的压力。那么在 SessionServer 在注册的时候会保存了哪些数据呢?\n SessionCacheService 从名称可以看出是缓存数据，当 Subscriber 注册到 SessionServer 中的时候、我们会给 Client 推送 Client 感兴趣的服务提供者信息列表。但是我们不可能在每次 Client 有变化的时候都去 Data层获取数据、这样对 Data 层的压力会很大。在 SessionServer 上缓存数据服务提供者信息可以对 DataServer 层屏蔽 Client 的变化，从而有效减轻 DataServer 的压力。SessionCacheService 内部的 readWriteCacheMap 缓存了服务提供者列表信息。使用 guava cache 缓存数据。数据有 ttl ，除此之外 Data 层有数据变化也会通知 cache 数据失效。\n Subscriber 和 Publisher 会话缓存信息正排索引信息。 SessionServer 的设计之初就是为了和 Client 直接通讯。通过 SessionServer 来负责与 Client 的连接，将每个 Client 的连接数收敛到 1，每个 SessionServer 负责与若干个 Client 连接，这样当 Client 数量增长时，只需要扩容 SessionServer 集群就可以了。 …","date":1648018800,"description":"源码解析｜数据倒排索引","dir":"projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"40d37578e58543cd340847fbdef907c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","publishdate":"2022-03-23T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["“源码解析”"],"title":"源码解析｜数据倒排索引","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/","wordcount":4102},{"author":"葛长伟","categories":"SOFAStack","content":" 文｜葛长伟（花名：川朗 )\n蚂蚁集团技术专家\n负责容器镜像加速项目 Nydus 的开发和维护，专注于容器镜像存储、持久存储和文件系统领域。\n本文 1344 字 阅读 4 分钟\n前言 今年 1 月 ，Containerd 社区通过投票接收 Nydus-snapshotter 成为 Containerd 社区的子项目。这是继 ttrpc-rust 之后，蚂蚁容器团队再次向 Containerd 捐赠子项目。\n此举将方便 Nydus 和 Containerd 的开发协同，减少项目迭代过程中可能出现的不兼容问题，也让用户可以更容易地使用 Nydus 镜像加速服务。\n目前 Nydus 已经将 Nydus-snapshotter 的代码迁移到了 Containerd 组织下的新仓库[1]。\nNydus 简介 Nydus 是蚂蚁集团和阿里云共同开源的容器镜像加速项目，属于 CNCF Dragonfly 项目，是其中的镜像服务部分。\nNydus 是在最新的 OCI Image-Spec 基础之上设计的容器镜像加速服务，重新设计了镜像格式和底层文件系统，从而加速容器启动速度，提高大规模集群中的容器启动成功率。\nNydus 设计了一个为镜像优化的文件系统—Rafs。\nNydus 镜像可以推送和保存在标准的容器镜像中心，Nydus 镜像格式完全兼容 OCI Image Spec 和 Distribution Spec。成功转换或者创建镜像后，Nydus 镜像会生成一个元数据文件 Bootstrap、若干个数据文件 blob、manifest.json、config.json。\n目前可以通过 Nydusify 、Acceld 或者 Buildkit 创建 Nydus 加速镜像。\n其中，Acceld[2] 是 Nydus 和 eStargz 的开发者正在合作开发的 Harbor 开源企业级镜像中心的一个子项目，它提供了一个通用的加速镜像转换服务和框架。基于 Acceld，Nydus 和 eStargz 可以方便地从 Harbor 触发加速镜像转换。\n与此同时，Nydus 也在开发 Buildkit 相关的支持，在未来也可以直接通过 Buildkit 从 Dockerfile 直接创建加速镜像。\nNydus-snapshotter 是 Containerd 的 Remote Snapshotter 插件，它是一个独立于 Containerd 的进程。\n当集成 Nydus-snapshotter 到 Containerd 后，Nydus-napshotter 在容器镜像准备阶段，只会将 Nydus 镜像的元数据部分 Bootstrap 从镜像中心下载下来，并且创建了一个新的进程 Nydusd。Nydusd 是处理文件系统操作的用户态进程。通过配置，Nydusd 可以作为基于 Linux FUSE 的用户态文件系统 Virtio-fs Vhost-user Backend，甚至可以是 Linux Fscache 的用户态进程。\nNydusd 负责从镜像中心或者对象存储下载文件数据以响应读文件的请求，并可以将文件数据块缓存在 Host 的本地文件系统。\nNydus 特性 Nydus 有如下重要的特性：\n1、镜像层间块级数据去重，可以减少镜像中心的存储成本，降低数据传输的带宽消耗。\n2、Whiteout 文件不会再被打包进 Nydus 镜像。\n3、端到端的数据完整性校验。\n4、作为 CNCF 孵化项目 Dragonfly 的子项目，Nydus 可以接入 P2P 分发系统，以此降低对镜像中心的压力。\n5、支持数据和元数据分离存储。可以将数据保存在 NAS、阿里云 OSS 或者 AWS S3。\n6、支持文件访问行为记录，这样就可以审计和分析容器内应用的访问行为。增强安全能力、优化镜像数据排布。\n除了以上的关键特性，Nydus 可以灵活地配置成 Linux FUSE 用户态文件系统、基于轻量虚拟化技术容器的 Virtio-fs daemon，或者 Linux 内核磁盘文件系统 EROFS 的用户态 on-demand 数据下载服务：\n1、轻量化地集成到 vm-based 容器运行时。现在 KataContainers 正在考虑原生地支持 Nydus 作为容器镜像加速方案。\n2、Nydus 和 EROFS 紧密合作，期望可以直接使用 EROFS 作为容器镜像的文件系统。相关修改的第一部分已经合并入 Linux Kernel v5.16。\nNydus 部署形态 支持 Runc 时，Nydus 作为 FUSE 用户态文件系统进程：\n支持 KataContainers 时，Nydus 作为 Virtio-fs daemon：\n目前 EROFS 正在尝试联合 Fscache 一起，以内核文件系统 EROFS 直接作为容器 Rootfs：\nNydus 将与 Containerd 社区紧密合作，致力于提供更优秀的容器镜像加速方案，提高镜像的存储和分发效率，提供安全可靠的容器镜像服务。\n求贤若渴： 关于蚂蚁集团可信原生技术部安全容器和存储团队\n在蚂蚁集团内部主要负责公司内部容器运行时和云原生存储技术，是公司数据链路的守护者，运行时环境的看门人。我们团队也是 Kata Containers 的创立者，镜像加速服务 Nydus 的发起者，分布式事务服务 Seata 的维护者，也维护着公司内数据访问组件 ZDal/ZCache/XTS 等产品。\n我们是开源精神的信徒，也是实现开源软件和公司业务双赢的践行者。我们是一个关注业务、关注业界前沿、关注基础设施技术，更关心成员成长的团队。目前我们正在招收 2023 届实习生，有兴趣的可以参考蚂蚁集团2023届实习生招聘。\n联系邮箱：liyuming.lym@antgroup.com\n本周推荐阅读 恭喜 李志强 成为 Layotto committer！\n社区文章｜MOSN 路由框架详解\nHAVE FUN | SOFARegistry 源码解析\nBabaSSL：支持半同态加密算法 EC-ElGamal\n","date":1647932400,"description":"Nydus 镜像加速插件迁入 Containerd 旗下","dir":"blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ad4cca5257474169e5ca87f15437235d","permalink":"https://sofastack.github.io/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","publishdate":"2022-03-22T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","summary":"文｜葛长伟（花名：川朗 ) 蚂蚁集团技术专家 负责容器镜像加速项目 Nydus 的开发和维护，专注于容器镜像存储、持久存储和文件系统领域。 本文 1344 字 阅读 4 分钟 前","tags":["SOFAStack"],"title":"Nydus 镜像加速插件迁入 Containerd 旗下","type":"blog","url":"/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/","wordcount":1715},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动，我们会筛选重点问题，通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@rust-rust 提问：\n 建议开发各种语言的 API。\n A：Java 和 Python 在设计中，争取注册到 jsse 里。\nBabaSSL：https://github.com/BabaSSL\n@会飞的小胖子 提问：\n tengine 现在可使用 BabaSSL 了吗？\n A：tengine master 已经支持，稳定版还得等等。\nBabaSSL：https://github.com/BabaSSL\nSOFAStack 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory configuration 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n用 mysql、consul 或 leaf 等系统实现分布式自增 id API\n Hard 让 Layotto 支持通过接口调用的方式动态加载 wasm，以支持 FaaS 场景动态调度\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nSOFAJRaft 本周发布 发布 1.3.10 版本，主要变更如下：\nFeatures： 优化 read-index 读，增加 maxReadIndexLag 参数设置快速失败阈值\nLogEntry 增加切片读取 API\n在删除 rocksdb 大 range 数据时，优化空间回收速度\n在节点过载时，将原有的快速失败策略修改为反压策略，依赖于这个特性的用户推荐升级\nBug Fixes： 升级 Log4j 以解决安全漏洞\nsnapshot 文件使用 atomic move 避免文件重新命名是被损坏\n修复 Counter demo 不兼容 gRPC 的问题\n修复对 snapshot 并行压缩/解压的配置项错误\n修复在某种竞争条件下 Replicator 可能停止发送心跳的 bug\n「详细参考」：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.10\n本周推荐阅读 SOFAArk Committer 专访｜看它不爽，就直接动手改！\n HAVE FUN | SOFARegistry 源码解析\n 探索 SOFARegistry（一）｜基础架构篇\n 社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1647586800,"description":"SOFA Weekly | Committer 聊天室、SOFAJRaft 本周发布、新手任务","dir":"blog/sofa-weekly-20220318/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"71d080ef0a61bca724b03bf0f44daa07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220318/","publishdate":"2022-03-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220318/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Committer 聊天室、SOFAJRaft 本周发布、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220318/","wordcount":1155},{"author":"连文湧","categories":"SOFAStack","content":" 数据表结构要求 以应用级服务发现元数据表为例\n param type description data_center String local data center revision String revision app_name String appName client_version String clientVersion base_params String base_params service_params String service_params deleted boolean delete or no gmt_create Date create time gmt_modified Date last update time 写入 写入缓存 cachedExecutor.execute 执行缓存写入操作防止无法瞬间处理大量相同数据写入操作。防止大量节点上报相同的应用级服务发现元数据。\npublic V execute(K key, Callable\u0026amp;lt;V\u0026amp;gt; callable) throws Exception { V v = cache.getIfPresent(key); if (v != null) { //发现元素，命中+1 hitCount.increment(); return v; } return cache.get( key, () -\u0026amp;gt; { //未发现元素，未命中+1 missingCount.increment(); onMiss(key); return callable.call(); }); } 二参数的 execute 统计修订号revision的命中和未命中次数统计 metrics，在通讯数据压缩暴露到 prometheus。\n写入数据 protected void refreshEntryToStorage(AppRevisionDomain entry) { try { cachedExecutor.execute( entry.getRevision(), () -\u0026amp;gt; { //判断是否执行replace写入数据 if (appRevisionMapper.heartbeat(entry.getDataCenter(), entry.getRevision()) == 0) { appRevisionMapper.replace(entry); } //省略日志操作 } } cachedExecutor 默认指定 silentMs=10s，当缓存项在指定的时间段内没有更新就会被回收（移除 key），需要等待获取新值才会返回。10s 内没有更新说明数据量不大，也不需要进行写入缓存的操作。\n通过 hearbeat() 底层通过 update 原子判断数据是否存在。刷新 gmt_modified 字段时间防止被误删。\nupdate app_revision set gmt_modified=CURRENT_TIMESTAMP where data_center = #{dataCenter} and revision=#{revision} and deleted = \u0026#39;0\u0026#39; 当 update 没有命中的时候，使用 replace，保证能生成一个新的 id，用于后续的 watch 方法监听表获取元素更新变化，并刷新 gmt_modified 防止字段超时被删除。\nreplace into app_revision( data_center, revision, app_name, client_version, base_params, service_params, deleted, gmt_create, gmt_modified ) values ( #{dataCenter}, #{revision}, #{appName}, #{clientVersion}, #{baseParams}, #{serviceParams}, #{deleted}, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP ) 获取数据增量改变 Watch 数据库没有提供订阅的操作，watch 方法缓存最新 id 值，增量读取数据库中更新的 id 值并更新最新的 id 值保证 lastLoadId 一直保持最新的状态\nprivate void watch() { syncStart(); try { long start = lastLoadId; if (listStableEntries(start, 1).size() == 0) { return; } logger.info(\u0026amp;quot;start watch from {}\u0026amp;quot;, start); long maxId = listToTail( (T entry) -\u0026amp;gt; { container.onEntry(entry); logger.info(\u0026amp;quot;watch received entry: {}\u0026amp;quot;, entry); }, start, 100); logger.info(\u0026amp;quot;end watch to {}\u0026amp;quot;, maxId); lastLoadId = maxId; } finally { syncEnd(); } } listStableEntries 提供从数据库获取最新数据的 id 值的方法，写入数据的方法底层通过 replace 写入，因此一定会有新的 id 生成。\n机制存在问题：如果数据中间出现不连续的间断，无法得到更新后存在间隔的 id 值。\n此方法主要列出所有创建完成 1s 后更新的元素。\nif (entry.getGmtCreate().getTime() \u0026amp;gt;= now.getTime() - DB_INSERT_DELAY_MS) { break; } 其中 DB_INSERT_DELAY_MS=1s\n为什么是 1s？\n内部是分布式数据库，表内数据会被拆分到多个机器上，每台机器批量获取 id 属性，此时如果大量并发插入，可能产生 id 值高的已经入库，而低 id 还没有完全写入，这时 watch 方式会出现问题，漏掉低 id 值的数据，直到 list 调用才能被重新填入。而这种问题产生的间隔很短，因此 1s 的间隔能保证id值较低的数据已经被填入。\nlistToTail 方法返回当前最大可靠 id 值\nprivate long listToTail(EntryCallable\u0026amp;lt;T\u0026amp;gt; callable, final long start, final int page) { long curStart = start; while (true) { List\u0026amp;lt;T\u0026amp;gt; entries = listStableEntries(curStart, page); if (CollectionUtils.isEmpty(entries)) { break; } for (T entry : …","date":1647586800,"description":"源码解析｜数据表监听","dir":"projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1343a0bf78782bc53e05233bbdcde0cf","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","publishdate":"2022-03-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","summary":"数据表结构要求 以应用级服务发现元数据表为例 param type description data_center String local data center revision String revision app_name String appName client_version String clientVersion base_params String base_params service_params String service_params deleted boolean delete or no gmt_create Date create time gmt_modified Date last update time 写入 写入缓存 cachedExecutor.execute 执行缓存写","tags":["“源码解析”"],"title":"源码解析｜数据表监听","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/","wordcount":1597},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展\n 活动时间：03 月 17 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#26 解读 BabaSSL ：项目概况和最新进展 从数据存储到网络通信，从密码合规再到隐私计算，这些场景都离不开密码学算法和协议。\nBabaSSL 密码库作为蚂蚁和阿里的统一基础密码库，广泛的应用在各类蚂蚁和阿里的业务当中，提供了 TLS 通信、数据加密、国密合规等关键的密码学相关能力，确保了各项业务平稳、安全、合规的运行。\nBabaSSL 自 2020 年开源以来，在行业内得到了广大用户的使用和验证。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 张成龙（花名：刻一） -蚂蚁集团技术专家\n-负责蚂蚁 BabaSSL 密码库核心研发\n议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:50 BabaSSL 项目的概况和最新进展 张成龙（花名：刻一），蚂蚁集团技术专家，负责蚂蚁 BabaSSL 密码库核心研发\n你将收获 1.了解 BabaSSL 项目的诞生背景\n2.了解 BabaSSL 密码库的主要功能和技术特点\n3.了解 BabaSSL 8.3.0 新功能\n4.了解 BabaSSL 的未来发展趋势\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇\n","date":1647500400,"description":"03 月 17 日周四晚 19 点，线上直播第 26 期。","dir":"activities/sofa-channel-26/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e998e41cd8ea96210efdbecbb3ae0e95","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-26/","publishdate":"2022-03-17T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-26/","summary":"概要 活动主题：SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展 活动时间：03 月 17 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#26：解读 BabaSSL ：项目概况和最新进展","type":"activities","url":"/sofastack.tech/activities/sofa-channel-26/","wordcount":633},{"author":"曹先胜","categories":"SOFAStack","content":" 文｜曹先胜\ne签宝中间件开发\n负责e签宝中间件开发和维护，包括 MQ、网关、微服务、数据同步、全链路压测等\n贡献者前言 「 开源就是在使用中，共同成长的过程 」\n从 2018 年学习 SOFAStack 的一些开源项目，到如今深入使用 MOSN，伴随着 SOFA 走到四周年。\n因为兴趣也接触了不少的开源社区，唯独对 SOFA 社区的组件体验颇多， 例如 SOFAArk、SOFARPC、MOSN。长年混迹在钉钉群里提问题，都能得到及时回复，这对我们研究 MOSN 有很大的帮助。也因此通过 MOSN 的代码设计，学习到了很多关于 Sidecar 的设计理念。\n我们使用 MOSN 的出发点是公司框架使用了很多的中间件，每个中间件有自己的依赖，这些依赖经常性的会发生冲突。虽然我们使用了类似 Spring Boot 的 Pom 管理机制，但升级框架过程中，如果有同学自行引入了 jar 包，就不可避免的会发生 jar 冲突。为了解决这个问题，我们调研了很多方案，最终认为 Service Mesh 是解决这个问题的一个比较合适的方案。\n同时，也调研了一些其他的开源产品，经过内部讨论和各种取舍，我们选择了MOSN。\n在使用 MOSN 时，因为要对接 Eureka，需要进行动态路由，而官网关于路由的文章不是很多。因此，在自己和烈元老师学习后，总结了这样一篇路由分享文章。\nMOSN 作为网络边缘代理组件，路由功能是核心功能，本文将介绍 MOSN 路由如何使用，以及 MOSN 路由的一些高级使用技巧，欢迎大家留言指导。\n路由基本设计 在 MOSN 的路由设计中，Cluster 和 Route 是高度关联的，说白了 Route 的配置，就是为了表达如何准确找到你想找到的 Cluster，另外一个 Cluster 可以有多个 Host 机器。\n例如一个 Cluster 有 100 台机器，其中有 50 台是 v1 版本，50 台是 v2 版本，如何根据一些特定的规则，准确地把请求路由到 v1 版本或者 v2 版本呢？\n再例如，我想根据 Header 里的某个值，再将这个值和“配置中心”里的某个值进行计算，才能找到 Cluster，那么我该如何配置呢？\n 首先，我们看最简单的路由设置。 上图是一个简单的 Json 配置。其中，Cluster Manager 和 Routers 的配置是路由的关键。我们可以根据 Cluster Manager 配置多个 Cluster，每个 Cluster 配置多个 Host。\n然后在 Routers 配置中，根据一些规则，告诉 MOSN 如何将请求路由到 Cluster 中。\n如下图：\n此配置表示，现在有一个 Rouer 配置名为 Server_Router，有一个虚拟主机，可配置多个域名，这里匹配所有域名。\n同时，这个域名有多个路由配置，这里暂且配置了一个路由配置：前缀匹配，只要是 / 开头的，就转发到 ServerCluster 里的 Host 中，也就是下面的 Cluster Manager 配置里的 ServerCluster。\n这样，就实现了一个简单的 MOSN 路由的配置。\n动态路由 Cluster 大部分情况下，如果我们的路由逻辑很简单，例如根据 Header 里的某个名字，找到对应的 Cluster，代码或者配置就是这么写的：\n、、、java router := v2.Router{ // header 匹配 RouterConfig: v2.RouterConfig{ Match: v2.RouterMatch{ Headers: []v2.HeaderMatcher{ // 这个 header 匹配, 就转发到 app.Name cluster. { Name: \u0026amp;ldquo;X-service-id\u0026amp;rdquo;, Value: app.Name, }, }, }, // cluster 名称匹配. Route: v2.RouteAction{ RouterActionConfig: v2.RouterActionConfig{ ClusterName: app.Name, }, }, }, } r.VirtualHosts[0].Routers = append(r.VirtualHosts[0].Routers, router) 、、、\n上面代码的意思是如果 Header 里有 X-service-id 这个 kv，那么就能找到下面 RouteAction 对应的 Cluster 了。\n那如果是更复杂的逻辑呢？\n比如利用请求里的 Header 和“配置中心”的某个值进行计算，如何才能找到 Cluster呢？\n此时，通过配置已经无法解决这个需求，因为这其中涉及到了计算逻辑，MOSN 通过动态配置可以支持该需求。\n如下图配置：\n我们设置了一个（\u0026amp;rdquo;Cluster_Variable\u0026amp;rdquo;: \u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;） 的 KV 配置。\n同时，我们还需要在 StreamFilter 中，利用变量机制设置 key 为 “My-ClusterVariable” 的 Value ，这个 Value 就是计算出来的 Cluster 名称。\n代码如下：\n、、、Java // 先注册这个 key 到变量表中。 func init() { variable.Register(variable.NewStringVariable(\u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;, nil, nil, variable.DefaultStringSetter, 0)) }\nvar clusterMap = make(map[int]string, 0)\nfunc (f *MyFilter) OnReceive(ctx context.Context, headers api.HeaderMap, buf buffer.IoBuffer, trailers api.HeaderMap) api.StreamFilterStatus { l := len(clusterMap) // 找 Cluster cluster := // 执行一些计算 // 设置到上下文变量中。这个 key 必须和配置文件中保持一致。 variable.SetString(ctx, \u0026amp;ldquo;My-ClusterVariable\u0026amp;rdquo;, cluster) return api.StreamFilterContinue } 、、、\nMOSN Subset 如上面所述，我们经常有在一个集群里有多个版本，如何根据某些标签将请求路由到指定的版本呢？\n通常，我们会使用 Subset 方案，即“子集合”。可在一个 Cluster 里面，为每个应用打标。同时我们的路由也配置相关的配置（MOSN 称为 Metadata），实现较为复杂的路由。\nMOSN 官方文档中，简单介绍了 Metadata 的使用。\n下面让我们更详细的介绍 Subset 的使用：\n上图中左边是 Cluster Host 配置，右边是 Router 配置。\n这个路由配 …","date":1647327600,"description":"社区文章｜MOSN 路由框架详解","dir":"blog/community-article-mosn-routing-framework-explained/","fuzzywordcount":3100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5de6ebad45acd0c8edc9e9b104c8c333","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","publishdate":"2022-03-15T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","summary":"文｜曹先胜 e签宝中间件开发 负责e签宝中间件开发和维护，包括 MQ、网关、微服务、数据同步、全链路压测等 贡献者前言 「 开源就是在使用中，共同成长的","tags":["SOFAStack"],"title":"社区文章｜MOSN 路由框架详解","type":"blog","url":"/sofastack.tech/blog/community-article-mosn-routing-framework-explained/","wordcount":3087},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@麦兜兜 提问：\n 我这边在 MOSN 上新增了一种私有协议，基本路由功能已经跑通了，其他的流量治理相关配置有样例吗？\n A：治理如果是说的限流限速的话，通常 MOSN 里面的 stream filter 基本上都是和协议无关的，都是可以使用的。\n@张宁 提问：\n snapshot 做起来，打快照后会删除日志的，所以调一下打快照的时间间隔。\n SOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 HAVE FUN | SOFARegistry 源码解析\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\nBabaSSL：支持半同态加密算法 EC-ElGamal\n","date":1646982000,"description":"SOFA Weekly | MOSN 社区会议、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220311/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"58a24de0efaa2ed6d21cbdd80894b214","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220311/","publishdate":"2022-03-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220311/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 社区会议、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220311/","wordcount":697},{"author":"王祖熙","categories":"SOFAStack","content":" 文｜王祖熙（花名：金九 )\n蚂蚁集团开发工程师\n负责蚂蚁 Kubernetes 集群容器交付专注于集群交付能力、交付性能及交付 Trace 等相关领域\n—— 数据不出域、可用不可见\n01背 景 随着大数据与人工智能的快速发展，个人隐私数据泄露和滥用时有发生，隐私安全问题也越来越被重视。\n国家于 2020 年施行密码法、2021 年施行个人信息保护法，对个人隐私数据和数据安全加密有更高的要求。\n因此，隐私计算也不断地被提及和关注，源于其有优秀的数据保护作用，使得『数据不出域、可用不可见』，限定了数据的使用场景，防止了数据的泄露，而引起了业界的热捧。\n隐私计算是指在保护数据本身不对外泄露的前提下，实现数据共享和计算的技术集合，共享数据价值，而非源数据本身，实现数据可用不可见。\n 隐私计算对于个人用户来说，有助于保障个人信息安全；\n 对于企业来说，隐私计算是数据协作过程中履行数据保护义务的关键路径；\n 对于政府来说，隐私计算实现数据价值最大化的重要支撑。\n 隐私计算目前在金融、医疗、电信、政务等领域均在开展应用试验，比如：\n银行和金融机构\n在不泄露各方原始数据的前提下，进行分布式模型训练，可以有效降低信贷、欺诈等风险；\n医疗机构\n无需共享原始数据便可进行联合建模和数据分析，数据使用方在不侵犯用户隐私的情况下，可以使用建模运算结果数据，有效推动医疗行业数据高效利用。\n隐私计算的相关技术有多方安全计算 （MPC） 、可信执行环境 （TEE） 、联邦学习 （FL） 、同态加密 （HE） 、差分隐私 （DP） 、零知识证明 （ZKP） 、区块链 （BC） 等等。\n这些技术各有优缺点，隐私计算的产品或者平台也是由这些技术来搭建。\n其中与密码学明显相关的是同态加密，目前同态加密算法的开源项目各有千秋，用户使用比较复杂。BabaSSL 作为基础密码库，应该提供一套简单易用和高效的同态加密算法实现和接口，让上层应用更方便简单地使用同态加密算法。\n此外，随着隐私计算技术的兴起，蚂蚁集团推出了开箱即用、软硬件结合的隐私计算基础设施，一站式解决方案，即可信原生一体机。\nBabaSSL 作为蚂蚁可信原生一体机中的核心基础软件密码库，将同态加密等隐私计算所需的相关密码学能力整合其中，为可信原生一体机的用户带来更加便捷高效的使用体验。\n02 同态加密 同态加密 （Homomorphic Encryption, HE） 是指满足密文同态运算性质的加密算法，按性质分为加法同态和乘法同态：\n加法同态\n乘法同态\n同态加密后得到密文数据，对密文数据进行同态加法或者乘法得到密文结果，将密文结果同态解密后可以得到原始数据直接加法或者乘法的计算结果。\n如下图：\n根据满足加法和乘法的运算次数又分为：全同态加密和半同态加密。\n全同态加密\n（ Fully Homomorphic Encryption, FHE ）\n1.支持任意次的加法和乘法运算\n2.难实现、性能差 （密钥过大，运行效率低，密文过大）\n3.主流算法：Gentry、BFV、BGV、CKKS\n4.需要实现的接口\n半同态加密\n（Partially Homomorphic Encryption, PHE）\n1.只支持加法或乘法中的一种运算，或者可同时支持有限次数的加法和乘法运算\n2.原理简单、易实现、性能好\n3.主流算法：RSA、ElGamal、Paillier\n4.需要实现的接口：\n*（1）KeyGen()： 密钥生成算法，用于产生加密数据的公钥 PK（* Public Key）和私钥 SK（Secret Key），以及一些公共参数 PP（Public Parameter）。\n*（2）Encrypt()： 加密算法，使用 PK 对用户数据 Data 进行加密，得到密文 CT（Ciphertext）。*\n*（3）Decrypt()： 解密算法，使用 SK 对密文 CT 解密得到数据原文 PT（Plaintext）。*\n*（4）Add()： 密文同态加法，输入两个 CT 进行同态加运算。*\n*（5）Sub()： 密文同态减法，输入两个 CT 进行同态减法算。*\n*（6）ScalaMul() 或者 Mul() ：密文同态标量乘法，输入一个 CT 和一个标量 PT，计算 CT 的标量乘结果。*\nEC-ElGamal 原理\nElGamal 加密算法是基于 Diffie-Hellman 密钥交换的非对称加密算法，EC-ElGamal 是 ECC 的一种，是把 ElGamal 移植到椭圆曲线上来的实现，主要计算有：椭圆曲线点加、点减、点乘、模逆和离散对数。\n以下是 EC-ElGamal 的算法原理：\n公共参数\n1.G：椭圆曲线基点\n2.SK：私钥，SK=d\n（d 是 0 到椭圆曲线的阶 q 之间的随机数）\n3.PK：公钥，PK=dG\n加密\n1.明文 m，随机数 r\n2.计算密文 C：\n（3）明文 m 的取值范围为模 order(G) 的模空间，但实际使用时 m 需限制为较小的数 （例如 32 比特长度） ，否则椭圆曲线离散对数问题 （ECDLP） 无法求解。\n解密\n1.计算 rPK：\n2.计算 mG：\n3.计算 mG 的 ECDLP，获得明文 m。\n密文加法、密文减法\n1.两个密文：\n2 .密文加：\n对 2 个密文的 2 个 ECC 点分别做点加，共 2 个点加，公式如下：\n3.密文减：\n对 2 个密文的 2 个 ECC 点分别做点减，共 2 个点减，公式如下：\n密文标量乘法\n1.密文\n2.对密文的 2 个 ECC 点分别用 𝑚_2 做点乘，共 2 个点乘，公式如下：\n3.如上公式与明文m2m1的同态加密结果一致：\n这里 r=m2r1\n03 算法实现 接口定义\n对象相关接口\n1.上下文对象：\nEC_ELGAMAL_CTX，该对象用来保存公私钥以及一些其他内部用到的信息，是 EC-ElGamal 算法其他接口的第一个参数。\n接口如下：\n//创建 EC_ELGAMAL_CTX 对象，key 为 ECC 公钥或者私钥的 EC_KEY 对象 2.解密表对象：\nEC_ELGAMAL_DECRYPT_TABLE，该对象用来保存解密表的内部信息。椭圆曲线离散对数问题（ECDLP）只有爆力破解的方法可求解，而爆力破解的速度比较慢，通常的做法是使用小步大步算法（Baby-Step，Giant-Step，BSGS）。总体思想是提前将所有可能的明文结果提前运算后，保存到 hash 表中，下次只需要进行少量的运算和 hash 表查找就可以得到结果，大大提高 ECDLP 的解密效率，但解密表的初始化可能比较慢，而且解密表的实现事关解密速度，后面考虑可以开放接口的实现给上层应用，所以这里先定义了一个解密表的对象和默认实现。\n接口如下：\n//创建 EC_ELGAMAL_DECRYPT_TABLE 对象 //decrypt_negative 为 1 时表示该解密表可以解密负数，初始化解密表时将可能的负数运算后插入到 hash 中。 EC_ELGAMAL_DECRYPT_TABLE *EC_ELGAMAL_DECRYPT_TABLE_new(EC_ELGAMAL_CTX *ctx, int32_t …","date":1646809200,"description":"BabaSSL：支持半同态加密算法 EC-ElGamal进","dir":"blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"efc7daaf960e5998f9fee0a1457a986e","permalink":"https://sofastack.github.io/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","publishdate":"2022-03-09T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","summary":"文｜王祖熙（花名：金九 ) 蚂蚁集团开发工程师 负责蚂蚁 Kubernetes 集群容器交付专注于集群交付能力、交付性能及交付 Trace 等相关领域 —— 数据不出域、可用不可见 01","tags":["SOFAStack"],"title":"BabaSSL：支持半同态加密算法 EC-ElGamal","type":"blog","url":"/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/","wordcount":3244},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@冷建伟 提问：\n 启动 SOFABoot 报错：Can not found binding converter for binding type bolt。跟到源码发现：bindingTypeBindingConverterMap 只有 jvm，没有 bolt。跟到源码发现 SPI load 的 converter 只有 JVM。版本：runtime-sofa-boot-starter-3.1.4.jar。想问下是不是要升级我的 SOFA SDK 版本 ？\n A：这个引入 rpc starter 即可。\n@leon 提问：\n SOFARegistry 是不需要用 K8s 吗？\n A：SOFARegistry 在内部是基于 K8s 部署的，提供更细粒度更高性能的服务发现。\n 为什么不是想办法优化 K8s 服务发现性能，而是搞代码侵入性的方案？\n A：基于 K8s 的实现的无侵入式服务发现是云原生下的一套较为后期和理想的方案，这也是 SOFARegistry 后续演进的规划之一。\n目前依然采用侵入的发布订阅模式，一是性能的考量，现有的 K8s 很难支撑起数千万级别数量的服务以及稳定推送延迟的要求；二是迁移有一个过程，对大量现有应用进行服务发现的改造是一个很长周期，无侵入式服务发现会采用逐渐接入的方式。\n目前重点还在于如何更好更稳定的支撑起超大规模集群的问题上。\n@来永国 提问：\n SOFATracer 加了 sofa-tracer-rocketmq-plugin 扩展包，还需要做什么配置吗？\n A：需要配置一下 SendMessageHook 和 ConsumeMessageHook 这两个 hook，分别是：SofaTracerSendMessageHook、SofaTracerConsumeMessageHook。\n本周发布 BabaSSL 开源发布 8.3.0 版本，主要更新如下：\n修复 CVE-2021-4160\nopenssl enc 命令支持 wrap 模式\nASYNC: 支持 job 的嵌套\n支持 TLS 证书压缩 (RFC 8879)\n发行版上游 patch 集合合并 [hustliyilin]\n支持 NTLS session ticket\n支持祖冲之消息完整性算法 128-EIA3\n支持 NTLS 客户端认证\n移除 ARIA 算法\n支持国密合规的软随机数生成器\n支持半同态加密算法 EC-ElGamal\n在 NTLS 中支持 RSA_SM4 加密套件\nARM 平台上提供 SM3 和 SM4 的性能优化\nSM4 算法逻辑优化以提升性能 [zzl360]\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nMOSN 本周发布 发布 MOSN V0.26.0 版本，主要变更如下：\n主要更新如下：\n XProtocol 进行了重构，XProtocol 不再是一种协议，而是便于协议扩展实现的框架\n 新增 ip_access filter，基于来源 IP 的 ACL 控制器\n 支持 go plugin 加载协议转化插件，并支持动态选择协议转换插件\n 支持动态设置上游协议，使用 transcoder filter 来替换 Proxy 中的协议转换\n 其他优化与BUG Fix\n 「详细参考」：\nhttps://mosn.io/blog/releases/v0.26.0/\n本周推荐阅读 BabaSSL 发布 8.3.0｜实现相应隐私计算的需求\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1646377200,"description":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","dir":"blog/sofa-weekly-20220304/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9e14d6832e36d94e116c499a9ef62278","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220304/","publishdate":"2022-03-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220304/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |BabaSSL 发布新版本、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220304/","wordcount":1478},{"author":"小蚂蚁","categories":"SOFAStack","content":" 在近日中国科协召开的 2022“科创中国”年度会议上，中国工程院院士周济发布了 2021“科创中国”开源创新榜单。\n蚂蚁集团开发的可信执行环境隐私计算操作系统 Occlum 入选“科创中国”开源创新榜年度优秀开源产品。\n其中，可信执行环境隐私计算操作系统 Occlum 也是该榜单中唯一聚焦隐私计算领域的入选产品。\nOcclum 发展里程 2015 年 蚂蚁集团开始布局隐私计算，成功推出了 TEE 开源操作系统 Occlum。目前，Occlum 也是蚂蚁集团所有隐私计算业务的 TEE 底座，支撑了蚂蚁隐私计算的核心场景。\n2019 年 Occlum 正式开源，是国内第一个面向可信执行环境(Trusted Execution Environments，简称 TEE)的隐私计算操作系统，解决了云端 TEE 技术额外的功能限制和兼容性问题，降低了隐私计算应用开发门槛。\n目 前 Occlum 已捐赠到由微软、谷歌、IBM、阿里巴巴、腾讯等领先科技公司成立的隐私计算联盟(Confidential Computing Consortium,The LinuxFoundation)，是联盟中唯一由中国发起的项目。\n开源隐私计算操作系统 Occlum 还支持了阿里巴巴、微软等公司的云端隐私计算业务场景和大批隐私计算创业公司的隐私计算平台。国际著名开源项目也在使用 Occlum 开源产品，如 Hyperledger Avalon、Inclavare Container 等。\nOcclum 获得了产、学、研多方认可，相关技术成果已在操作系统领域顶级会议 ASPLOS 2020 发表。\n从 1869 项开源产品中被推选出来，Occlum 长期以来在基础技术领域的努力和坚持得到了认可。\n开源路漫漫，我们也很开心地看到，中国开发者正在成为全球开源社区的重要力量。\n对 SOFAStack - Occlum 感兴趣的话\n👏 等你加入我们！\n本周推荐阅读 BabaSSL 发布 8.3.0｜实现相应隐私计算的需求\n探索 SOFARegistry（一）｜基础架构篇\n社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进\n从 generator 的角度看 Rust 异步代码\n","date":1646290800,"description":"Occlum 入选 2021“科创中国”开源创新榜","dir":"blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3d995f09ef72a3b41105b1315cb3c29f","permalink":"https://sofastack.github.io/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","publishdate":"2022-03-03T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","summary":"在近日中国科协召开的 2022“科创中国”年度会议上，中国工程院院士周济发布了 2021“科创中国”开源创新榜单。 蚂蚁集团开发的可信执行环境隐私","tags":["SOFAStack"],"title":"Occlum 入选 2021“科创中国”开源创新榜","type":"blog","url":"/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/","wordcount":723},{"author":"SOFAStack","categories":"SOFAStack","content":" BabaSSL 8.3.0 稳定版本发布！ 密码学开源项目 BabaSSL 近日发布了 8.3.0 稳定版本，该版本中提供了若干 bug 修复以及较多的新特性支持。\n从具体特性角度来看，BabaSSL 8.3.0 版本在国际前沿技术标准、国内密码合规能力以及国密算法的性能优化上均进行了能力的提升。其中：\n前沿技术标准： RFC8879 所定义的 TLS 证书压缩功能为 TLS 握手带来了很大的性能提升、进一步降低了 TLS 加密通信时的延迟，对于提升用户体验起到了很好的增强，可直接降低 TLS 握手带宽 80% 以上。\n国内密码合规能力： 支持 NTLS session ticket、客户端认证以及 RSA_SM4 加密套件，为目前国内各行业也在进行的国密改造提供了功能上的大力支持；\n而对国密合规的软随机数生成器的支持，更是满足了国密改造过程中的合规性要求。\n国密算法性能优化： 此次 BabaSSL 连同 ARM、阿里云对国密 SM3 和 SM4 算法在 ARM v8 架构上进行了特殊硬件指令的优化，使得 BabaSSL 在具备相关指令集的 ARM 架构 CPU 上可以取得更好的 SM3 和 SM4 的计算性能。\n例如，在阿里云倚天 710上，SM3 获得最高 74% 以及 SM4 算法最高 36 倍的性能提升；此外，SM4 算法逻辑的 C 语言优化，也实现了在通用 CPU 上性能的提升。\nBabaSSL 8.3.0 主要存在如下方面的更新： 修复 CVE-2021-4160\n openssl enc 命令支持 wrap 模式\n ASYNC: 支持 job 的嵌套\n 支持 TLS 证书压缩 (RFC 8879)\n 发行版上游 patch 集合合并 [hustliyilin]\n 支持 NTLS session ticket\n 支持祖冲之消息完整性算法 128-EIA3\n 支持 NTLS 客户端认证\n 移除 ARIA 算法\n 支持国密合规的软随机数生成器\n 支持半同态加密算法 EC-ElGamal\n 在 NTLS 中支持 RSA_SM4 加密套件\n ARM 平台上提供 SM3 和 SM4 的性能优化\n SM4 算法逻辑优化以提升性能 [zzl360]\n 值得一提的是，针对数据安全和隐私保护市场的兴起，BabaSSL 8.3.0 中实现了对半同态加密算法 EC-ElGamal 的支持，隐私计算领域的用户可以便捷的使用该算法实现相应隐私计算的需求，并同时利用 BabaSSL 提供的国密能力实现技术合规。\n此外，BabaSSL 目前作为蚂蚁隐私计算一体机中默认集成的软件密码库，为蚂蚁隐私计算一体机的用户提供统一的密码学 API 接口，方便隐私计算应用程序的开发和调试。\n欢迎下载 BabaSSL 8.3.0 版本，下载地址：\nhttps://github.com/BabaSSL/BabaSSL/releases/tag/8.3.0\nBabaSSL 是什么 ？ BabaSSL 是一个提供现代密码学算法和安全通信协议的开源基础密码库，为存储、网络、密钥管理、隐私计算等诸多业务场景提供底层的密码学基础能力。实现数据在传输、使用、存储等过程中的私密性、完整性和可认证性的保证，为数据生命周期中的隐私和安全提供保护能力。\n作为国内稀缺的密码学开源项目，BabaSSL 填补了国内信息基础设施领域相关产品的空白，是我国建设国产密码学大生态、解决密码学技术“卡脖子”问题、发展前沿密码学技术的关键一环。\n除了在国家商用密码算法领域之外，BabaSSL 还在前沿密码学领域进行了支持，包括隐私计算场景下所需的各种密码学算法以及为了应对量子计算而产生的后量子密码学算法等。\nBabaSSL 对国际和国内的新型技术标准采用快速跟进的策略，因此支持的功能十分丰富。同时基于蚂蚁和阿里海量的用户场景，其性能和稳定性也达到了互联网生产级别。\n自 2020 年开源以来，BabaSSL 也在行业内得到了广大用户的使用和验证，并应用到了众多业务场景里。\nBabaSSL 的前世今生 BabaSSL 诞生于蚂蚁集团和阿里集团内部，目前作为蚂蚁和阿里的统一基础密码库，广泛应用在各类蚂蚁和阿里的业务当中，提供了 TLS、数据存储、国密合规等关键的密码学相关能力，确保了各项业务平稳、安全、合规的运行。\n2020 年进行开源以来，BabaSSL 将蚂蚁和阿里内部所积累的密码学技术能力提供给业界使用，同时在申请商用密码产品软件密码模块一级资质，也是首个有望获得商用密码产品型号证书的开源密码学产品。\n从具体场景来看，有如下三个方面，分别是存储、网络和端上的设备。其中网络服务的场景，是 BabaSSL 最大的支撑场景，例如淘宝、天猫、阿里云等各种涉及到链路加密的服务器端。此外移动端 App，例如支付宝手机 App 中集成了 BabaSSL 来实现多种密码学的能力。\n1. 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了 有了基础国密算法支持，我们在 AnolisOS 上构建出一个围绕国密算法展开的基础软件生态，同时它也是一个全栈国密解决方案：从底层固件，内核，到基础密码学库，在主要链路上做国密改造，最终形成一个完整的基于国密的安全信任链条。\n2. RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海 TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。随着 TLS 1.3+ 国密正式成为了国家/国际层面均认可的标准（RFC8998），我们也正式在 BabaSSL 中支持了相关能力并将其开源，并建设了 BabaSSL 社区。\n3. TLS 握手带宽直降 80%，BabaSSL 是怎么做到的 为了保障数据的安全性，通常使用 TLS/SSL 进行加密传输。当客户端访问服务器后台时，客户端会先和服务器进行 TLS 握手。RFC 8879 TLS Certificate Compression 就是为了解决这个问题，在 TLS 1.3 握手时提供证书压缩功能，大大降低数据传输，减少 TLS 握手的带宽消耗呢。\n4. Tengine + BabaSSL ，让国密更易用！ 国内著名 Web 服务器和反向代理开源软件 Tengine 完成了对 BabaSSL的适配工作。Tengine 对 BabaSSL 提供的特殊 API 进行了适配，并增加对 NTLS 相关能力的支持。无需额外的 patch 或者代码改动，从用户使用的角度进一步提升了便利性。\n对密码学、隐私计算感兴趣的话\n等你加入我们！\n本周推荐阅读 Tengine + BabaSSL ，让国密更易用！\nTLS 握手带宽直降 80%，BabaSSL 是怎么做到的\nRFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n","date":1646204400,"description":"BabaSSL 发布 8.3.0｜实现相应隐私计算的需求","dir":"blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f9693f85dce6fd979f0323ae3797b3cc","permalink":"https://sofastack.github.io/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","publishdate":"2022-03-02T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","summary":"BabaSSL 8.3.0 稳定版本发布！ 密码学开源项目 BabaSSL 近日发布了 8.3.0 稳定版本，该版本中提供了若干 bug 修复以及较多的新特性支持。 从具体特性角度来看，BabaSSL 8.3.0 版","tags":["SOFAStack"],"title":"BabaSSL 发布 8.3.0｜实现相应隐私计算的需求","type":"blog","url":"/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/","wordcount":2108},{"author":"李旭东","categories":"SOFAStack","content":" 简介 SOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群，具有分布式可水平扩容、容量大、推送延迟低、高可用等特点。\n蚂蚁生产集群 — SOFARegistry 支撑 1000 万服务发布者、4000 万服务订阅者，在业务应用大规模变更触发千万级别推送量的场景下，推送延迟的 p99 依然能够保持在 7s 以下。\n《认识 SOFARegistry》 这一系列文章将会基于 SOFARegistry 新版本（V6）的代码，讲解注册中心在超大规模集群场景下落地的解析与实践，同时介绍 SOFARegistry 的各项功能，方便业务落地。\n部署架构 SOFARegistry 现有的架构设计：采用双层存储架构，外加一个负责内部元数据管理的 meta 组件。\nSOFARegistry 的角色分为 4 个: client、session、data、meta。\n角色分工如下：\nClient\n提供应用接入服务注册中心的基本 API 能力，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\nSessionServer ｜ 会话服务器\n负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\nDataServer ｜ 数据服务器\n负责存储具体的服务数据，数据按 dataInfoId 进行分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模增长而扩容。\nMetaServer ｜ 元数据服务器\n负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n借助双层数据分片的架构，SOFARegistry 具有了支撑海量数据的基石\n● 支持海量数据：每台 DataServer 只存储一部分的分片数据，随数据规模的增长，只要扩容 DataServer 服务器即可。\n● 支持海量客户端：连接层的 SessionServer 只负责跟 Client 打交道，SessionServer 之间没有任何通信或数据复制，所以随着业务规模的增长，SessionServer 可以较轻量地扩容，不会对集群造成额外负担。\n数据结构 作为注册中心的基础功能，SOFARegistry 提供发布订阅的接口：Subscriber、Publisher。\n在服务发现场景下，Subscriber 需要通过服务名称从注册中心订阅到多个服务方的地址，进行负载均衡的访问。\n当存在服务方机器宕机时，注册中心通知所有的订阅方从服务列表中摘除这个 IP 地址，这样就不会再访问宕机的机器。\n下面给出简化后的发布者和订阅者的字段，贴合上述服务发现的需求。\nclass Subscriber{ String dataId; // 服务名称 String group; // 业务类型，比如RPC、MSG等等 String instanceId; // 租户名称 String zone; // 所在分区，结合scope实现逻辑隔离 ScopeEnum scope; // 订阅范围: zone、dataCenter、global } class Publisher{ String dataId; String group; String instanceId; String zone; List\u0026amp;lt;String\u0026amp;gt; dataList; // 发布的数据, sofarpc 用法中常见url } 常见用法（JAVA SDK）\n发布者\n// 构造发布者注册表 PublisherRegistration registration = new PublisherRegistration(\u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); // 将注册表注册进客户端并发布数据 Publisher publisher = registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); // 如需覆盖上次发布的数据可以使用发布者模型重新发布数据 publisher.republish(\u0026amp;quot;10.10.1.1:12200?xx=zz\u0026amp;quot;); 订阅者\n// 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { @Override public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, global String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); registration.setScopeEnum(ScopeEnum.global); // 将注册表注册进客户端并订阅数据，订阅到的数据会以回调的方式通知 SubscriberDataObserver Subscriber subscriber = registryClient.register(registration); 更详细的用法文档参考官方文档: https://www.sofastack.tech/projects/sofa-registry/java-sdk/\n特点与优势 这是一张 SOFARegistry 和其他注册中心产品的特性对比图，可以看出相比其他产品，SOFARegistry 在功能特性方面还是不足（未来 SOFARegistry 在特性方面会进行完善）。 SOFARegistry 的主要优势还是在于支撑超大规模集 …","date":1646118000,"description":"探索 SOFARegistry（一）｜基础架构篇","dir":"blog/explore-sofaregistry-1-infrastructure/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ae1a4db92cf2dea8d057ba7dede8c440","permalink":"https://sofastack.github.io/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","publishdate":"2022-03-01T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","summary":"简介 SOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑蚂蚁庞大的服务集群，具有分布式可水平扩容、容量大、推送延迟低、高可","tags":["SOFAStack"],"title":"探索 SOFARegistry（一）｜基础架构篇","type":"blog","url":"/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/","wordcount":3704},{"author":"SOFA 团队","categories":"SOFAStack","content":" 2 月 24 日，MOSN 举办了 2022 年首次的社区会议。\nMOSN 社区在会议上提出了新一年的 Roadmap，社区成员分享了 MOSN 在不同场景下落地实践的经验，以及大家一起大开脑洞，探讨了更多我们可以创造的可能性。\nMOSN 社区 Roadmap MOSN 在 2022 年主要的目标是发布 MOSN 1.0，以及开源一个新的开箱即用的产品。同时推动 MOE （ MOSN 2.0 架构）演进，对接更多的生态组件。\n随着 MOSN 的落地用户越来越多，稳定性建设也是今年的重点发展方向，让大家用得放心。\n社区会议分享嘉宾 来自探探科技、阿里云、去哪儿网的用户，在本次会议中都积极分享了自己的使用案例，供大家借鉴参考。\n探探科技 谢正尧同学详细地列出了 MOSN 落地过程中遇到的问题和踩到的坑，给 MOSN 的后续优化提供了很好的思路。\n有不少坑我们都已经安排上了日程，MOSN 的开发者都赶在填坑的路上。\n阿里云 沐沂同学列出了新财年的规划，和大家分享了边缘的跨集群服务发现场景的租户拆分，以及新的部署形式。\n去哪儿网 佳龙同学比较关注 Roadmap 中的 GC 方面，希望可以引入一些高性能的网络框架，对性能优化方面有更多的需求。\n以及很期待 MOSN 社区的 holmes，希望可以解决查问题时的难题。\nQA 回顾 1.Q：MOE 的落地场景、最佳实践的博客有哪些？\nA：具体内容我们会在 Service Mesh Summit 2022 首届服务网格峰会进行分享。今年会有更多的落地场景，在尝试替换接入层网关，也会试点上线的，可以期待一下！\n2.Q：我可不可以理解为——假如 MOE 在 Envoy 被接收后，可以通过 Go 代码去写一个 filter，让它跑在 Envoy 上，之后我的数据链直接用 Envoy 就可以？\nA：是的，就这个意思。现在我们的 demo 就可以玩起来了，只是有些接口还没标准化，现在我们内部落地的 sofagw 就是这个架构。\n「demo文档」⬇️： https://github.com/mosn/mosn/blob/master/pkg/networkextention/README-cn.md\n3.关于 GC 优化方式的讨论\nA：（1）降低 GC 频率确实是有效的，可以减少长期存活对象的重复 mark。（2）不过这种预分配的，其实不是很灵活，最好的还是动态调整 GC Percent，保持 GC goal 在预期的水位。\n本质上是一个内存换 CPU 的方案，在内存够用的时候，提高 GC goal 的水位。\n我们搞 holmes 内存异常捕获的时候，也考虑过这种情况。https://uncledou.site/2022/go-pprof-heap/\n大家在本次会议中畅所欲言，大开脑洞。也正是与使用用户的沟通交流，让 MOSN 的发展规划和用户需求相辅相承。\n感谢大家的积极配合，在你们的帮助下，MOSN 社区会持续推动性能优化、技术落地，与用户共同成长。\n我们之后还会举办社区会议，比如在 MOSN 发布新版本或者有大进展时。听取用户反馈，同步业界动态，期待下次会议啦～\n想要预定下次的社区会议,了解更多 MOSN 社区动态,钉钉搜索:21992058\n本周推荐阅读 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\nMOSN 多协议扩展开发实践\nService Mesh 在中国工商银行的探索与实践\n云原生运行时的下一个五年\n","date":1646031600,"description":"社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进","dir":"blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ee484f870924be25bf5ccddd91840b89","permalink":"https://sofastack.github.io/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","publishdate":"2022-02-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","summary":"2 月 24 日，MOSN 举办了 2022 年首次的社区会议。 MOSN 社区在会议上提出了新一年的 Roadmap，社区成员分享了 MOSN 在不同场景下落地实践的经验，以及大家","tags":["SOFAStack"],"title":"社区会议｜MOSN 社区将会发布 1.0 版本，同时推动下一代架构演进","type":"blog","url":"/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/","wordcount":1114},{"author":"陈岸琦","categories":"SOFAStack","content":" 文｜陈岸琦（花名：敖清 )\n蚂蚁集团高级开发工程师\n负责蚂蚁 Prometheus 监控原生功能，在蚂蚁集团的落地与产品化建设\n本文 6566 字 阅读 15 分钟\n前 言 日志和指标是监控不可或缺的两种数据源，为应用系统提供完整的可观测性。\nAntMonitor 作为蚂蚁的统一监控平台，是一款主要以日志方式采集监控数据的监控产品。在社区，开源的云原生监控，主要以 Metrics （指标）的方式实现监控，其中以 Prometheus 为代表。\n并且 Prometheus 监控因其强大的用户功能、结合 PromQL 的数据后分析能力，在业界有广泛的用户群体。实际上已成为开源标准，广泛用于开源 Kubernetes 的集群监控。\nPrometheus 本身是一款单机监控产品，在蚂蚁庞大的高可用集群场景落地，具有一定的局限性和困难，包括但不限于：\n Prometheus 没有提供稳定的、长期的数据存储功能，无法满足蚂蚁场景下对历史数据的查询；\n Prometheus 是有损监控，不保证数据的完整性，无法满足蚂蚁场景下对交易笔数等数据的精确性要求；\n Prometheus 不支持日志监控。\n 但是为了满足用户对 Metrics 监控的需求，经过近两年的努力，我们成功地将 Prometheus 的主要功能融合进了 AntMonitor 的现有架构，提供了一套具有蚂蚁场景特色的集群化解决方案。\n今年大促，我们成功地将 Sigma 集群监控（蚂蚁原生的集群管理和资源调度平台）完整迁移至 AntMonitor。配合告警和大盘，实现了 Sigma 监控的覆盖。AntMonitor 凭借 Sigma 监控的迁移，成功孵化了完善的的云原生 Prometheus 监控能力。\n本文简要介绍了AntMonitor 对 Prometheus 监控功能的支持，以及 Sigma 监控的落地实践。\nPART. 1 海量数据下的采集架构 以下是一段 Prometheus metrics 数据的样例：\nMetrics（指标）数据和日志数据拥有较大差别，包括但不限于：\n第一、日志数据写在磁盘上，每条日志都有标准时间戳，而 Prometheus metrics 是存在内存里，采集时间以拉取的时间为准，因此数据的准确性对调度的准确性有较高要求。\n第二、日志的每次采集均采集增量即可，每次采集的数据量有限，但是 Metrics 数据每次采集均要采集全量，数据的文本大小动辄上百 MB，因此 Metrics 数据量巨大，很容易超限。\n第三、日志数据均需要按照某些固定 schema（数据表结构）作切分清洗、计算聚合，但是原生 Metrics 通常存储单机原始数据。\nAntMonitor 现有的数据链路大致为由 agent 采集日志数据缓存于内存，由 Spark 计算集群从 agent 内存中拉取数据，进行聚合，存储于 CeresDB。\n然而 Metrics 数据不同于日志数据，单机明细数据通常具备可观测性，具备完整的信息。因此通常 Metrics 数据，可以跳过计算步骤，直接进行存储。因此，Metrics 数据在保留单机明细数据的情况下，由 agent 内存和 Spark 拉取的方式已经不合时宜，不仅浪费了计算资源，agent 内存也无法支撑住庞大的 Metrics 数据量。\n因此，我们根据用户的业务需求，提供了两条数据链路：\n 在需要保留单机明细数据的情况下，走基于网关的明细数据采集链路；\n 在需要数据聚合的情况下，走基于 Spark 的聚合数据采集。\n 1.1 基于网关的明细数据采集 为了使保留明细数据跳过计算集群直接存储，我们研发上线了一套专门服务 Metrics 数据的中心化采集 + push 存储的链路。\n中心化采集相对于传统的 agent 采集，不再需要依赖于部署在每台物理机，而是只通过 HTTP 请求的方式采集 Metrics 数据。中心化采集对 Metrics 的采集配置进行结构化的下发和调度，以此满足了 Metrics 采集对时间戳调度精确性的要求。并且，中心采集对采集到的数据不存内存，而是直接以 push 的方式推送给 PushGateway，由 gateway 直接存储至底层 CeresDB。\n这套采集方案，满足了 Metrics 对时间精度和存储单机数据的要求。并且将 Metrics 数据采集与现有的日志采集接耦，使二者互不干扰，解放了对 agent 内存和计算资源的高消耗。\n该套方案已经成功用于蚂蚁 Sigma 等多个技术栈和基础设施的 Prometheus 采集，目前每分钟处理上亿条指标数据。\n1.2 基于 Spark 的聚合数据采集 以 Sigma 为代表的基础设施监控，对单机明细数据有较大需求。但是保留明细数据也有较大的缺点，例如：数据量庞大，对存储消耗较高；数据查询时，耗时和数据读取量巨大。\n但是对于一些业务应用用户，对单机明细数据并不关注，只关注于一些维度的聚合数据。例如，以机房维度、集群维度等。因此在这种场景下，存储明细数据，会造成较大的存储浪费，并且在数据查询时，会带来很差的用户体验。因此在这种场景下，我们保留了目前 AntMonitor 传统的日志链路，对采集的 Metrics 单机明细数据进行了聚合进行存储。在业务不关注单机明细数据的场景下，这条链路拥有明显的好处，节省了存储空间，提升了用户查询的速度。\n但是不同于日志监控的数据聚合，必须由用户配置聚合规则，由于 Metrics 数据本身就包含 schema 信息，我们通过自动化的配置项，自动对 Gauge、Counter、Histogram 等 metric type 自动为用户生成了聚合配置，免去了用户手动配置聚合的繁琐：\n下图总结对比了数据聚合与不聚合的区别和优劣：\nPART. 2 维表体系下的元数据统一 原生 Prometheus 提供多种服务发现机制，如 K8s 服务发现通过 apiserver 可以自动获取发现采集的 targets。但是，AntMonitor 作为一个蚂蚁统一监控系统，显然是不能通过 apiserver 自动发现监控目标。\nAntMonitor 在日志监控的现有基础上，建设有一套较为完善的元数据维表体系，包含了 SOFA、Spanner、OB 等多个蚂蚁技术栈元数据。元数据告诉我们去哪里采集监控数据，对应原生的服务发现机制。为了拉齐原生功能，我们对部分维表进行了必要改造，此处我们以 Sigma 监控的落地实践为例，简要介绍下我们的元数据同步流程。\n2.1 Sigma 元数据同步 AntMonitor 进行 Sigma 监控的前提是要获取元数据，元数据告诉我们去哪里采集监控数据。\n为此，我们设计了基于 RMC（蚂蚁的统一元数据平台） 的 “全量同步+增量同步” 元数据同步方案。前者保证元数据齐全可靠，后者基于 AntQ 实现，保证了元数据的实时性。\n从图中可以看到，为了对齐原生的 staleness 功能，Sigma pod 元数据统一添加了下线 (offline) 这个中间状态。\n原生 Prometheus 通过 relabeling 功能实现采集目标过滤等，还可以通过 metric relabeling 对拉取到 …","date":1645772400,"description":"2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践","dir":"blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a8d933b0202e682ad456783714a58ed6","permalink":"https://sofastack.github.io/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","publishdate":"2022-02-25T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","summary":"文｜陈岸琦（花名：敖清 ) 蚂蚁集团高级开发工程师 负责蚂蚁 Prometheus 监控原生功能，在蚂蚁集团的落地与产品化建设 本文 6566 字 阅读 15 分钟 前 言 日志和指标是监控不可","tags":["SOFAStack"],"title":"2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践","type":"blog","url":"/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/","wordcount":4491},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@徐豪 提问：\n 想了解 Ark 动态模块，如何在 IDEA 里面进行开发调试？\n A：这个和普通工程基于 idea 调试没有什么区别的，你的 issue 里面提到要调试模块，那就在安装模块的时候，将断点打在你关注的代码行。\n 目前我没有看到相关的 guide，然后自行尝试，先启动容器，再手工启动模块，感觉没成功，不清楚问题出在哪？\n A：～/logs/sofa-ark 看看有日志吗？\n@孙英雄 提问：\n 请问伙伴们有在用 SOFA 技术栈在非金融的项目开发吗？\n A：有的哈，可以看下使用者登记 https://github.com/sofastack/sofa-rpc/issues/375https://github.com/sofastack/sofastack.tech/issues/5\n@来永国 提问：\n 升 SpringBoot to 2.4.x 还有计划吗？\n A：GitHub 上有一些 exmaple，你可以先玩玩。这个今年在规划了，下个 SOFABoot 版本 3.11.0 将会升级到 Spring Boot 2.4.13。\nhttps://www.github.com/mosn/mosn/tree/master/examples%2Fcn_readme%2Fdubbo-examples\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 技术人聊开源：这并不只是用爱发电\n应用运行时 Layotto 进入 CNCF 云原生全景图\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\n","date":1645772400,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220228/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a61ff0d87e7608cc95b2de68338812bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220228/","publishdate":"2022-02-25T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220228/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220228/","wordcount":838},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践\n 活动时间：02 月 24 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践 Kubernetes 已经成为行业内，容器编排的标准。越来越多的企业开始在生产中使用 Kubernetes，拥抱云原生。\nKubernetes 为什么要持续迭代升级？大规模集群下升级过程将面临哪些问题？如何在复杂问题中找到一条无损升级路子？本次分享将用40分钟时间带你一起庖丁解牛 Kubernetes 的升级难题。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 王连平（花名：烨川） 蚂蚁集团高级工程师。 负责蚂蚁 Kubernetes 集群容器交付方面工作，专注于集群交付能力、交付性能及交付Trace等相关领域。 议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:50 蚂蚁大规模 Kubernetes 集群无损升级实践 王连平（花名：烨川），蚂蚁集团高级工程师\n你将收获 了解大规模 Kubernetes 集群升级核心问题 了解核心问题背后的 Kubernetes 设计理念 了解蚂蚁在解决这些问题的一些思路 一起探讨 Kubernetes 这个庞然大物的未来升级之道 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1645686000,"description":"02 月 24 日周四晚 19 点，线上直播第 25 期。","dir":"activities/sofa-channel-25/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4e7019a0dffc50381dc10af4c627eaf6","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-25/","publishdate":"2022-02-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-25/","summary":"概要 活动主题：SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践 活动时间：02 月 24 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#25：蚂蚁大规模 Kubernetes 集群无损升级实践","type":"activities","url":"/sofastack.tech/activities/sofa-channel-25/","wordcount":655},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区获奖啦 SOFAStack 团队在 segmentfault 思否颁布的2021 年中国技术先锋年度评选中，荣获“中国技术品牌影响力企业” 。\n SOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@Nothing 提问：\n 请教个问题，一个服务的订阅者实例数很多的情况下，如果所有订阅者都与 provider 建立连接，provider 的连接数压力大，SOFARegistry 是怎么考虑这种情况的?\n A：目前正在做 host subset 的设计，注册中心端会直接进行分片，减少客户端压力。现在开源版本的 SOFARegistry 还不具备这个的能力，我们内部也是采用全链接。可以了解一下 MOSN ，MOSN 有类似分片功能，内部也有大规模落地。\n@老段 提问：\n 如果启动三个节点的话，停掉一个节点，系统就会一直选举，不再提供服务了；如果启动五个节点的话，停掉两个节点，系统就会一直选举，也不再提供服务了。这个正常么？\n A：不正常，我这边 3 个节点，kill 一个 follower 完全没影响，kill leader 也可以很快选举完成。不会一直选举，服务可以提供，只不过日志里会去找那个挂了的节点。\n@张永欣 提问：\n MOSN 怎么配置 dubbo 连接，支持自发现 dubbo 服务吗？\n A：github 上有一些 exmaple，你可以先玩玩：\nhttps://www.github.com/mosn/mosn/tree/master/examples%2Fcn_readme%2Fdubbo-examples\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 技术人聊开源：这并不只是用爱发电\n应用运行时 Layotto 进入 CNCF 云原生全景图\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\n","date":1645167600,"description":"SOFA Weekly |荣获“中国技术品牌影响力企业”、开发者的搬砖日常、QA 整理","dir":"blog/sofa-weekly-20220218/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ba96ccb01c0806da34a4f846db7ccdec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220218/","publishdate":"2022-02-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220218/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |荣获“中国技术品牌影响力企业”、开发者的搬砖日常、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220218/","wordcount":990},{"author":"金融级分布式架构","categories":"SOFAStack","content":" 2022 年 2 月 10 日，CNCF 发布了最新版本的 Landscape。\nLayotto 正式加入 CNCF 云原生全景图!\n分类在 Serverless framework 板块下，详情见 ：https://l.cncf.io/serverless\n意味着 Layotto 正式成为了CNCF 认可的构建云原生最佳实践中的一环。\nCNCF 简介 云原生计算基金会（CNCF, Cloud Native Computing Foundation）致力于云原生技术的普及和可持续发展。\nCNCF Landscape 意图从云原生的层次结构，以及不同的功能组成上，让用户了解云原生体系的全貌。同时，也受到广大开发者和使用者对该项目的关注和重视。\nLayotto 简介 Layotto(/leɪˈɒtəʊ/) 是一款使用 Golang 开发的应用运行时, 旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。\n它为应用提供了各种分布式能力，比如状态管理、配置管理、事件发布订阅等能力，以简化应用的开发。\n更多关于 Layotto 的内容可以查看：\n云原生运行时的下一个五年\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\nLayotto Star 一下✨： https://github.com/mosn/layotto\n新的一年 Layotto 除了继续优化 service mesh 和 multi-runtime 方面的功能外，也会投入精力融入开源 serverless 生态。\n接下来会和大家分享下 2021 年 Layotto 的落地总结，以及新一年的 roadmap，欢迎关注!\n想要初步接触 Layotto 的技术同学，可以从我们的技术任务入手，欢迎大家一起来玩～\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n想要了解更多关于 Layotto 的最新动态\n👐 欢迎添加微信小助手进群，随时提问 👐\n本周推荐\n云原生运行时的下一个五年\n蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】\n喜迎虎年｜开源正当时！\nMOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n","date":1644822000,"description":"应用运行时 Layotto 进入 CNCF 云原生全景图","dir":"blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6521f348ceee0dc3067e03c8209f4a01","permalink":"https://sofastack.github.io/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","publishdate":"2022-02-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","summary":"2022 年 2 月 10 日，CNCF 发布了最新版本的 Landscape。 Layotto 正式加入 CNCF 云原生全景图! 分类在 Serverless framework 板块下，详情见 ：https://l.cncf.","tags":["SOFAStack"],"title":"应用运行时 Layotto 进入 CNCF 云原生全景图","type":"blog","url":"/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/","wordcount":742},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@小楼 提问：\n 请问 session 是如何支持 Dubbo 的元数据的？\n A：Registery 的元数据现在不是通用的，只针对 SOFARPC。\n session 之间应该是没有数据同步的吧，跨 session 节点怎么办呢？\n A：现在会同步两个信息，一个是元数据，一个是接口级订阅，接口级订阅是用于兼容没升级的应用。同步的路径是通过存储，类似 K8 的 listwatch 机制，内部落地存储的插件实现是 db，这个块数据比较少，就几千行吧，而且变化很小。\n「SOFARegistery」：https://github.com/sofastack/sofa-registry\n@来永国 提问：\n 为什么我起了 RPC 服务端客户端和注册中心，然后连接调用是可以的，然后我把注册中心关了，它还是跑得通？\n A：client 会有缓存的。\n 获取注册中心的服务有 API 接口吗?\n A：有的，有个从单机 session 获取数据的接口 curl localhost:9603/digest/pub/data/query?dataInfoId=com.test.SimpleService#@#DEFAULT_INSTANCE_ID#@#DEFAULT_GROUP dataInfoId 参数需要进行 url encode 应该还没公开的 API 文档，获取数据的 HTTP 接口也不太易用，我最近会补一下文档还有方便使用的接口。\n 那看样子这个相当于是指定搜索了吗？\n A：是的，目前没有模糊查询的接口， curl localhost:9603/digest/getDataInfoIdList 你可以用这个 API grep 一下。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@东仔 提问：\n SOFABolt 的最新分支是哪个？\n A：https://github.com/sofastack/sofa-bolt master 就是最新分支。\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n","date":1644562800,"description":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220211/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b55336c3e1f02336f659e4eedb771ea7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220211/","publishdate":"2022-02-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220211/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220211/","wordcount":1170},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@来永国 提问：\n 想问下，发现在 SOFA 的 spi 加载扩展的时候，是有做到 getExtensionLoader 遍历 META-INF 的，但是没搞懂是怎么做到的。br/ A：在这个方法里: com.alipay.sofa.rpc.ext.ExtensionLoader#loadFromFile，getResource 这边可以获得多个文件。\n@半个馒头 提问：\n 多次提交 raft 日志会自动触发 jraft 的 leader 转移吗？\n A：不会，可能是其他场景触发的。\n steps down when alive nodes don\u0026amp;rsquo;t satisfy quorum.\n A：是 leader 中发现半数节点在心跳周期内没有心跳了。\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 喜迎虎年｜开源正当时！\n2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n","date":1643958000,"description":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20220204/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b8eaeb7040dab97c5de595df79e1bc7c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220204/","publishdate":"2022-02-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220204/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220204/","wordcount":747},{"author":"金融级分布式架构","categories":"SOFAStack","content":" Awesome SOFAer 👋:\n大家好，\n我是 SOFAStack 社区的负责人——齐天\n虎年伊始，我谨代表 SOFAStack 社区\n祝大家新年快乐！\n在新的一年事事如意，虎虎有生气！\nPart 01 开源正当下！ 回想起 6 年前，在 Github 写下第一行 Apollo 的代码时。\n那时国内的开源社区是这样一番景象：\nDubbo 还没被唤醒、很多现在耳熟能详的项目还在襁褓中、开源社区的贡献者寥寥无几、少量的活跃项目凭着核心个人开发者对技术的热爱维持着。虽然使用开源产品的公司很多，但是做开源产品却是一种非常小众的行为。\n然而最近几年开源却一下子火了起来，成为了技术圈的时髦热词，在各种场合被频频提起。\n究其原因，我想一方面是开源商业化的模式诞生了以 Confluent、GitLab、HashiCorp 为代表的百亿美元上市公司群体，证明了开源的商业价值，吸引到了资本的关注；\n另一方面从政策层面，工业和信息化部印发了《“十四五”软件和信息技术服务业发展规划》，其中提到了要提升关键软件供给能力，加快繁荣开源生态，建设 2-3 个有国际影响力的开源社区。\n在这些因素的刺激影响下，国内的开源行业得到了迅猛的发展，诞生了开放原子基金会以及以木兰社区为代表的诸多综合性开源社区，众多基于开源项目的创业公司也纷纷获得融资，不完全统计列表如下：\n● 2021 年 3 月深圳支流科技 API7 完成 Pre-A 轮（基于 Apache APISIX 项目）\n● 2021 年 4 月上海硅智信息技术 Kyligence 完成 D 轮融资（基于 Apache Kylin 项目）\n● 2021 年 5 月北京思斐软件 SphereEx 完成天使轮融资（基于 Apache ShardingSphere 项目）\n● 2021 年 5 月涛思数据 TaosData 完成 B 轮融资（开源物联网大数据平台 TDengine）\n● 2021 年 10 月 StreamNative 获得 A 轮融资（基于 Apache Pulsar 项目）\n● 2021 年 11 月白鲸开源获得数百万美元种子轮融资（基于 Apache DolphinScheduler）\n● 2021 年 11 月开源数据库结构变更和版本管理 ByteBase 获得三百万美元种子轮融资\n● 2022 年 1 月 SphereEx 又完成了 Pre-A 轮融资\n可以说，「开源正当时！」\nPart 02 如何正确对待开源？ 然而，繁华之下也有隐忧。\n很多企业看到了开源的商业价值，所以纷纷投入大量资源，有了投入自然对回报就有着期待。在这种情形下一个不合理的 KPI 很容易就会让开源动作走样，诸如点 star 拿礼物、大量提交修改错别字的 commit 等行为也屡见不鲜。\n而另一方面有些底层开源项目如 Log4j2 虽然很重要，但是由于没有明显的商业价值，企业没有动力投入资源，以至于只有少数开发者无偿、自愿地进行维护，在曝出严重漏洞后大家才意识到原来开源软件供应链的根基竟是如此脆弱。\n那么，回到我们自身\u0026amp;hellip;\n应该如何正确对待开源呢？ 我的思绪再次拉回到 6 年前，当时的我对开源还懵懵懂懂，把代码贡献到 GitHub 的出发点非常纯粹：作为一名软件工程师，写了一份自己认为还过得去的代码，解决了一些通用问题，就希望让这份代码发挥更大的作用，同时也能通过代码会友，大家一起交流技术、分享心得，岂不乐哉？至于能获得多大的影响力、有多大的商业价值，当时是没有任何概念的。\n现在想来，似乎是有一分盲目和冲动在，一种想把好东西分享出去的冲动。\n当然了，要把开源项目做好，光有一时的冲动是不够的。做过开源项目的朋友基本都有一个共识，那就是做开源项目非常枯燥，日复一日地处理 issue、review pr，时不时还会遇到伸手党不合理的需求，稍有怠慢还会招来无端的指责。\n那到底是什么支撑我投入开源这么多年呢？ 想来想去应该还是兴趣吧\u0026amp;hellip;\n对技术的兴趣让这些重复性的事情显得不那么枯燥，而通过开源又结交了很多志趣相投的朋友，大家在一起既可以聊技术，也可以聊生活，虽然身处五湖四海，甚至素未谋面，但相谈甚欢，正是这样开放、有趣的社区让兴趣得以持续保鲜。\n而这也正是 SOFAStack 的开源理念，我们希望在喧嚣中依然保持乐于分享的初心，打造开放、有趣的技术社区。通过开放让更多的人加入进来，通过有趣让大家留下来并持续分享、交流，相互学习、相互成长。\n比如在开放方面，我们通过 Github、Meetup、直播、公众号、视频号等多种渠道和大家进行技术交流。\n 在社区治理上，我们也是完善了社区的晋升机制，鼓励贡献者以不同形式来影响社区走向，不少项目如 MOSN、Layotto 都有较大比例的外部 Committer。\n 在社区合作方面，我们和包括 Envoy、Dapr、Seata 等国内外社区进行了深度的技术共建，在传播方面也是和云原生社区、字节码联盟的 WAMR 社区等一起联合举办了多场 Meetup，为社区带来了精彩的技术分享。\n 而在有趣方面，虽然我们这些工程师平时看上去都挺严谨的，但其实私下里还都有好玩的一面。所以我们的视频号也是不断尝试新的视频形式，就是希望营造一个比较轻松、有趣的环境来和大家进行技术交流，在快乐中学习和成长。\n虎年准备做的几件事 SOFARegistry V6 虽然 SOFARegistry V5 版本早已在 GitHub 上开源，其性能、容量、稳定性上也都达到了比较高的水平，不过在日常运行中还是存在不少痛点。所以我们对 V6 版本做了大幅重构，在性能、稳定性、可运维性等方面都取得了较大的突破并在生产环境完成全量上线（降本提效！注册中心在蚂蚁集团的蜕变之路），相信不管是一家中小规模的公司还是一家大型企业，SOFARegistry 都会是一个比较靠谱的选项。\n而在研发这个版本的过程中我们也沉淀了针对注册中心场景的混沌测试工具，也将于近期和大家见面，希望能帮大家更好地评估各类开源注册中心的能力极限，以便选择最适合自己的产品。\nMOSN 目前 MOSN 作为 Service Mesh 的数据面在蚂蚁生产环境已经覆盖了数十万容器，切实解决了我们在基础设施独立演进上的痛点，在社区也有将近 20 家公司登记使用。不过总体来看，使用门槛还是比较高。\n所以今年我们会开源一个 MOSN 的管控面产品，从而端到端打通 MOSN 的使用场景，降低使用难度，造福更多的用户。\nLayotto Layotto 作为云原生运行时的下一个五年的重要载体，今年我们会继续投入精力和 Dapr 社区一起推动 API 标准化向前演进，重新定义基础设施的边界。同时也会探索 Layotto on Envoy 的运行方式，从而只需运维一个 Sidecar 即可同时具备 Service Mesh 和应用运行时的能力。\n在函数运行时方面，去年我们在 KubeCon 演示了通过 K8s 标准语义把一个 WASM 模块调度到 Layotto 进程中运行，今年在这个方向也会继续向前探索更多可能性。\n去年 4 月，SOFAStack 社区在北京和大家度过了一个愉快的三周岁生日，也标志着社区逐渐走向成 …","date":1643871600,"description":"喜迎虎年｜开源正当时！","dir":"blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d95d0ce2c5f132fcd207d1701c64c415","permalink":"https://sofastack.github.io/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","publishdate":"2022-02-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","summary":"Awesome SOFAer 👋: 大家好， 我是 SOFAStack 社区的负责人——齐天 虎年伊始，我谨代表 SOFAStack 社区 祝大家新年快乐！ 在新的一年事事如意，虎虎有生气！ Part 01 开源正当下！ 回想起 6 年","tags":["SOFAStack"],"title":"喜迎虎年｜开源正当时！","type":"blog","url":"/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/","wordcount":2729},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@李雪涛 提问：\n 请问 MOSN 插件的管理接口应该怎么调用，里面的 IP 和 port，IP 应该指的是 Pod 的 IP 吧，那 port 指的是什么呢?br/ A：通过 admin 得配置。 https://www.github.com/mosn/mosn/tree/master/configs%2Fmosn_config.jso\n「MOSN」：https://github.com/mosn/mosn\n@李雪涛 提问：\n 我的插件参考的： https://github.com/mosn/mosn/blob/istio-1.10/examples/codes/plugin/pluginfilter/pluginfilter.go\n 但是我利用 admin 接口 enable 的时候输出的是插件未注册的错误，能帮我看一下我的插件注册部分哪里写的不对吗？\n插件的 client 的注册相关的代码： https://www.codepile.net/pile/EK6Om3A6\nA：镜像的配置有这个 plugin 吗？或者你先别用那个 Istio，现本地打包测试下，直接二进制启动试试： 1. 看配置，有没有 paper 的 filter 配置 2. MOSN 的 main 文件需要 import 你的 paper 文件，因为注册用的 init 3. 看下启动日志： https://github.com/mosn/mosn/blob/master/cmd/mosn/main/mosn.go\n「MOSN」：https://github.com/mosn/mosn\n@来永国 提问：\n 我把透传写在 SOFARPC 拦截器里，服务端接收不到客户端透传的参数。\n A：确实是这样，baggage 处理在 filter 之前。\n 还有什么更优雅的方式吗？那我非要只在 filter 里加透传要怎么做呢？\n A：非要在 filter 里面处理 baggage 的话,可以直接操作 SOFARequest 对象的 RequestProp. RemotingConstants.RPC_REQUEST_BAGGAGE，可以参考 com.alipay.sofa.rpc.context.BaggageResolver#carryWithRequest 类。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 2021 大促 AntMonitor 总结 - 云原生 Prometheus 监控实践\n蚂蚁大规模 Sigma 集群 Etcd 拆分实践\nTengine + BabaSSL ，让国密更易用！\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n","date":1643439600,"description":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220129/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"930109d877cef64f3e5441f23528dd16","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220129/","publishdate":"2022-01-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220129/","wordcount":1066},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王辉 提问：\n 那 6.x 版本相比 5.x 版本，缺失了哪些功能，有列表么？\n A：providedata 的功能还在，但通过 session 透出的 watcher 还没有支持，其他的功能没有缺失。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@李雪涛 提问：\n 请问自定义一个 streamfilter，可以在这个 filter 中获取当前请求的目的 IP 吗?\n A：可以的哈，通过变量就可以获取 。\n具体内容可以参考下方文档：\nhttps://www.github.com/mosn/mosn/tree/master/pkg%2Fproxy%2Fvar.go\n「MOSN」：https://github.com/mosn/mosn\n@王宇阳 提问：\n 请教一下 MOSN 做网关会对 HTTP 协议中没有带 content-type 的请求头做处理吗，比如加一个默认的这样？\n A：如果响应 header 没有携带 content-type 的话则默认加一个 “text/plain; charset=utf-8” 的 content-type。\n（注：MOSN 中的 HTTP 解析这块使用的 fasthttp 的库，目前这块会有这个默认操作。）\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、C、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 叮，你有一份开发者问卷到了\n一图看懂 SOFAStack 社区的 2021 ｜文末有“彩蛋”\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n","date":1642748400,"description":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划 ","dir":"blog/sofa-weekly-20220121/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e77bc7011b07dcfa07b22d729631a09d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220121/","publishdate":"2022-01-21T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220121/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220121/","wordcount":971},{"author":"SOFA 团队","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#24：漫谈 HTTP/3 进化史\n 活动时间：01 月 20 日，周四晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#24：漫谈 HTTP/3 进化史 HTTP/3 协议栈可以说是当前 4\u0026amp;frasl;7 层协议的集大成者，它浓缩了大量现有协议的最佳实践及优化技巧。\n那么 HTTP/3 是如何一步一步发展成今天这个样子的呢？它解决了什么样的问题？未来又还会走向何方？\n本次分享将用 50 分钟的时间，带你走近 HTTP/3 的世界，一一解读这些问题\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 曾柯（花名：毅丝） 蚂蚁集团高级工程师。 负责蚂蚁集团的接入层建设工作，主要方向为高性能安全网络协议的设计及优化 议程 18:50-19:00 主持人开场 SOFA 社区小助手-泡椒 主持人\n19:00-19:50 漫谈 HTTP/3 进化史 曾柯（花名：毅丝），蚂蚁集团高级工程师\n你将收获 了解4/7层协议的发展历程 了解HTTP/3解决的问题 一起展望HTTP/3的未来 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1642662000,"description":"01 月 20 日周四晚 19 点，线上直播第 24 期。","dir":"activities/sofa-channel-24/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2f719fc9371adf2f0f5a9de7f21c47cd","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-24/","publishdate":"2022-01-20T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-24/","summary":"概要 活动主题：SOFAChannel#24：漫谈 HTTP/3 进化史 活动时间：01 月 20 日，周四晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播间地址：h","tags":["SOFAChannel","HTTP/QUIC"],"title":"SOFAChannel#24：漫谈 HTTP/3 进化史","type":"activities","url":"/sofastack.tech/activities/sofa-channel-24/","wordcount":584},{"author":"杜克伟","categories":"SOFAStack","content":" 文｜杜克伟（花名：苏麟 )\n蚂蚁集团高级开发工程师\n负责蚂蚁 Kubernetes 集群的稳定性方面的工作，专注于集群组件变更、稳定性风险保障\n本文 15738 字 阅读 20 分钟\n前 言 为了支撑蚂蚁业务的迭代升级，蚂蚁基础设施今年启动了 Gzone 全面云化项目。要求 Gzone 需与已经云化的 Rzone 合并部署在同一个集群，Sigma 单集群实际管理的节点规模将超过万台，单集群承担的业务也将更加复杂。\n因此我们启动了大规模 Sigma 集群的性能优化方案，在请求延迟上期望能够对齐社区标准，不因规模增长的原因下降。\netcd 作为 Sigma 集群的数据存储数据库，是整个集群的基石，能够直接决定性能天花板。社区建议的单 etcd 集群存储限制是 8G, 而蚂蚁 Sigma 集群的单 etcd 集群存储量早已超过了这个限制，Gzone 上云项目势必会加重 etcd 的负担。\n首先，蚂蚁业务混合了流失计算、离线计算和在线业务，混合大量的生命周期在分钟级甚至是秒级的 Pod，单集群每天的 Pod 创建量也提升到了数十万, 都需要 etcd 来支撑；\n其次，复杂的业务需求催生了大量的 List (list all、list by namespace、list by label)、watch、create、update、delete 请求，针对 etcd 的存储特性，这些请求性能均会随着 etcd 存储规模的增大而严重衰减，甚至导致 etcd OOM，请求超时等异常；\n最后，请求量的增长也加剧了 etcd 由于 compact、defrag 操作对请求 RT P99 的暴涨，甚至请求超时，从而导致集群关键组件调度器、CNI 服务等 Operator 类组件间断性丢失，造成集群不可用。\n根据前人的经验，针对 etcd 集群进行数据水平拆分是一个有效的优化手段，典型的拆分是把 Pod 等重要数据单独 etcd 集群来存储，从而降低单 etcd 存储和请求处理的压力，降低请求处理延迟。但是 Pod 资源数据针对 Kubernetes 集群具有特殊性，具有其他资源没有的高要求，尤其是针对已颇具规模正在服务的 K8s 集群进行拆分更是需要万分谨慎小心。\n本文主要记录了蚂蚁集团在进行 Pod 资源数据拆分过程中一些实践经验和心得。\n抛砖引玉，请大家多多指教！\nPART. 1 面临的挑战 从前人的 Pod 数据拆分经验了解到，Pod 数据拆分是一个高危且复杂的流程，原因来自于 Pod 数据自身的特殊性。\nPod 是一组容器的组合，是 Sigma 集群中可调度的最小单位，是业务 workload 的最终承载体。Sigma 集群的最核心最终的交付资源就是 Pod 资源。\nSigma 集群最核心的 SLO 也是 Pod 的创建删除升级等指标。Pod 资源数据可以说是 Sigma 集群最重要的资源数据。同时 Sigma 集群又是由事件驱动的，面向终态体系设计，所以 Pod 资源数据拆分除了考虑基本的前后数据一致性问题外，还要考虑拆分过程中对其他组件的影响。\n前人的拆分经验流程中最核心的操作是数据完整性校验和关键服务组件停机。数据完整性校验顾名思义是为了保证数据前后的一致性，而关键服务组件停机是为了避免拆分过程中如果组件不停机造成的非预期后果，可能会有 Pod 非预期删除，Pod 状态被破坏等。但是如果照搬这套流程到蚂蚁 Sigma 集群，问题就来了。\n蚂蚁 Sigma 作为蚂蚁集团核心的基础设施，经过 2 年多的发展已经成为拥有 80+ 集群、单集群节点数可达到 1.2w+ 规模的云底座。在如此规模的集群上，运行着蚂蚁内部百万级别的 Pod，其中短运行时长 Pod 每天的创建量在 20w+次。为了满足各种业务发展需求，Sigma 团队与蚂蚁存储、网络、PaaS 等多个云原生团队合作，截止目前 Sigma 共建的第三方组件量已经达到上百个。如果 Pod 拆分要重启组件，需要大量的与业务方的沟通工作，需要多人共同操作。如果操作不慎，梳理不完全漏掉几个组件就有可能造成非预期的后果。\n从蚂蚁 Sigma 集群现状总结一下已有的 Pod 数据拆分经验流程的问题：\n1. 人工操作大量组件重启时间长、易出错 潜在需要重启的组件高达数十个，需要与各个组件 owner 进行沟通确认，梳理出需要重启的组件，需要耗费大量的沟通时间。万一遗漏就可能造成非预期的后果，比如资源残留、脏数据等。\n2. 完全停机持续时间长打破 SLO 数据拆分期间组件完全停机，集群功能完全不可用，且拆分操作极为耗时，根据前人经验，持续时间可能长达 1~2 小时，完全打破了 Sigma 集群对外的 SLO 承诺。\n3. 数据完整性校验手段薄弱 拆分过程中使用 etcd 开源工具 make-mirror 工具来迁移数据，该工具实现比较简单，就是读取一个 etcd 的 key 数据然后重新写到另一个 etcd，不支持断点续传，同时因重新写入 etcd 造成原有 key 的重要字段 revision 被破坏，影响 Pod 数据的 resourceVersion, 可能会造成非预期后果。关于 revision 后文会详细说明。最后的校验手段是检验 keys 的数量是否前后一致，如果中间 key 的数据被破坏，也无法发现。\nPART. 2 问题解析 美好的期望 作为一个懒人，不想和那么多的组件 owner 沟通重启问题，大量组件重启也易造成操作遗漏，造成非预期问题。同时是否有更好的数据完整性校验的手段呢？\n如果组件不重启，那么整个过程后演变为下面的流程，预期将简化流程，同时保障安全性。\n为了达成美好的期望，我们来追本溯源重新 review 整个流程。\n数据拆分是在做什么？ 众所周知，etcd 存储了 Kubernetes 集群中的各种资源数据，如 Pod、Services、Configmaps、Deployment 等等。\nKube-apiserver 默认是所有的资源数据都存储在一套 etcd 集群中，随着存储规模的增长，etcd 集群会面临性能瓶颈。以资源维度进行 etcd 的数据拆分来提升 Kube-apiserver 访问 etcd 的性能是业内所共识的经验优化思路，本质是降低单 etcd 集群的数据规模，减少单 etcd 集群的访问 QPS。\n针对蚂蚁 Sigma 集群自身的规模和需求，需拆分为 4 个独立的 etcd 集群，分别存储 Pods、Leases、event 和其他资源数据，下面分别简要说明这前三类(Pods、Lease、event)需要拆分出去的资源数据。\nEvent 资源 K8s event 资源数据并不是 watch 中的 event，一般是表示关联对象发生的事件，比如 Pod 拉取镜像，容器启动等。在业务上一般是 CI/CD 需要流水式展示状态时间轴，需要频繁拉取 event 资源数据。\nevent 资源数据本身就是有效期的（默认是 2 小时），除了通过 event 观测资源对象生命周期变化外，一般没有重要的业务依赖，所以说 event 数据一般认为是可以丢弃，不需要保障数据前后一致性的。\n因为上述的数据特点，event 的拆分是最为简 …","date":1642489200,"description":"蚂蚁大规模 Sigma 集群 Etcd 拆分实践","dir":"blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d2c7a90fb1f46225bb634988b092d058","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","publishdate":"2022-01-18T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","summary":"文｜杜克伟（花名：苏麟 ) 蚂蚁集团高级开发工程师 负责蚂蚁 Kubernetes 集群的稳定性方面的工作，专注于集群组件变更、稳定性风险保障 本文 15738 字 阅读 20 分钟 前 言 为了","tags":["SOFAStack"],"title":"蚂蚁大规模 Sigma 集群 Etcd 拆分实践","type":"blog","url":"/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/","wordcount":8750},{"author":"杨洋","categories":"SOFAStack","content":" 文｜杨洋（花名：凯申 )\n蚂蚁集团高级技术专家\n负责密码学工程能力建设、BabaSSL 开源社区建设\n本文 2366 字 阅读 5 分钟\n近日，国内著名 Web 服务器和反向代理开源软件 TengineBabaSSL 完成了对 BabaSSL的适配工作。\nTengine 对 BabaSSL 提供的特殊 API 进行了适配，并增加对 NTLS 相关能力的支持。\n「详细 Pull Request 请见」：https://github.com/alibaba/tengine/pull/1595\n至此，对我国密码行业相关安全通信协议，有使用需求的用户可以直接使用 Tengine + BabaSSL 的组合。而无需额外的 patch 或者代码改动，从用户使用的角度进一步提升了便利性。\nPART. 1 NTLS 目前，我国密码行业中有两个主要的通信协议相关的技术标准。一个是由信安标委于 2020 年发布的 TLCP 协议，即传输层密码协议；另外一个则是由密标委在 2012 年发布的 GM/T 0024《SSL VPN 技术规范》（以下简称 0024）。\nTLCP 和 0024 的具体内容差别不大，均是从 TLS 协议发展而来，他们的主要特点是将商用密码算法 SM2、SM3 和 SM4 应用到了 TLS 协议中，并使用 SM2 密钥交换机制替换掉了 TLS 协议原有的密钥交换流程。\nTLCP 和 0024 另外一个显著的特点将 TLS 协议中使用的数字证书拆分成了加密和签名两种用途的证书，加密证书和签名证书以及对应私钥均需要进行配置使用，所以 TLCP 和 0024 也俗称“国密双证书”协议。\nBabaSSL 对上述国密双证书协议进行了支持，并统称为 NTLS。\nNTLS 的全名为 National TLS，即我国核准的传输层安全协议，所以也可以叫做国密 TLS。\n由此可见，NTLS 并不是指某一种具体的符合商用密码相关技术标准要求的网络协议，而是多个协议的统称。在 BabaSSL 中代指 TLCP 和 0024 国密双证书协议，因为 NTLS 和标准 TLS 协议存在工作方式的不同，因此 BabaSSL 中增加了一些新的 API 来对其进行支持。而应用程序若想使用 NTLS 功能，就需要调用这些新增 API，给现有基于 OpenSSL API 进行适配的应用程序带来了额外的开发工作量。\nPART. 2 Tengine + BabaSSL Tengine 是由淘宝网发起的 Web 服务器项目，它在 Nginx 的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。\nTengine 的性能和稳定性已经在大型的网站(如淘宝网，天猫商城等)得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的 Web 平台。\nTengine 作为国内知名的开源 Web 服务器软件，在各领域均得到了广泛的使用且享有很高的知名度。\nBabaSSL 是一款轻巧、灵活且靠谱的密码学和 TLS 协议工具集。BabaSSL 是蚂蚁集团和阿里集团的各主要业务中所使用的底层密码库，目前开源出来供业界使用。BabaSSL 广泛的应用在包括网络、存储、移动端 App 等场景中。\nTengine 来源于 Nginx，所以默认使用的是 OpenSSL。此次 Tengine 针对 BabaSSL 中的 NTLS 功能进行了适配，用户如果选择使用 BabaSSL 作为 Tengine 的底层密码库来实现通信加密的能力，则可以无需对 Tengine 进行任何代码改动，原生开启 NTLS 能力。\nPART. 3 Tengine 启用 NTLS 具体来说，此次在 Tengine 中增加了几个新的指令，对 NTLS 进行支持。\n1. 下载 BabaSSL 和 Tengine 前往 👇 下载 BabaSSL 的源代码包: https://github.com/BabaSSL/BabaSSL/releases\n 前往 👇 获取 Tengine 的最新代码: 「git clone」\nhttps://github.com/alibaba/tengine.git\n2. 编译 BabaSSL 和 Tengine 使用如下配置：\n./configure --add-module=modules/ngx_openssl_ntls \\ --with-openssl=../path/to/BabaSSL \\ --with-openssl-opt=\u0026amp;quot;--strict-warnings enable-ntls\u0026amp;quot; \\ --with-http_ssl_module --with-stream \\ --with-stream_ssl_module --with-stream_sni 3. 配置 Tengine 开启 NTLS 一个开启了 NTLS 的 Tengine 配置文件的例子：\nworker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; server { listen 443 ssl; server_name localhost; enable_ntls on; ssl_sign_certificate server_sign.crt; ssl_sign_certificate_key server_sign.key; ssl_enc_certificate server_enc.crt; ssl_enc_certificate_key server_enc.key; location / { return 200 \u0026amp;quot;body $ssl_protocol:$ssl_cipher\u0026amp;quot;; } } } stream { server { listen 8443 ssl; enable_ntls on; ssl_sign_certificate server_sign.crt; ssl_sign_certificate_key server_sign.key; ssl_enc_certificate server_enc.crt; ssl_enc_certificate_key server_enc.key; return \u0026amp;quot;body $ssl_protocol:$ssl_cipher\u0026amp;quot;; } } 4. 测试 NTLS 可以使用 BabaSSL 的 s_client 工具对开启了 NTLS 的 Tengine 进行测试。\n「具体可以参考」：\nhttps://babassl.readthedocs.io/zh/latest/Tutorial/SM/ntls/\nPART. 4 总 结 随着互联网业务的发展，在新时期下，数据成为了影响人们正常生活的核心要素。\n因此数据安全和个人信息保护等问题变得更加需要重视，国家近期也针对数据安全领域进行了相关立法。\n密码学技术作为整个信息安全领域的基础技术能力，对数据安全也存在着很大的影响。同时 …","date":1641884400,"description":"Tengine + BabaSSL ，让国密更易用！","dir":"blog/tengine-babassl-making-state-secrets-easier-to-use/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"45a5b2c753bc2a5c371c606d1177571e","permalink":"https://sofastack.github.io/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","publishdate":"2022-01-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","summary":"文｜杨洋（花名：凯申 ) 蚂蚁集团高级技术专家 负责密码学工程能力建设、BabaSSL 开源社区建设 本文 2366 字 阅读 5 分钟 近日，国内著名 Web 服务器和反向代","tags":["SOFAStack"],"title":"Tengine + BabaSSL ，让国密更易用！","type":"blog","url":"/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/","wordcount":1930},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王勇旭 提问：\n com.alipay.sofa.rpc.boot.runtime.adapter.processor.ConsumerConfigProcessor 没有提供注解上的支持，自己实现来处理吗？Cluster 指定 failover、failfast 或者自己实现，这种在 SOFA 中是怎么使用的呢？ A：这种的话，单个注解的 API 是不支持的。不过可以通过调整整体的 RPC 的配置，来实现切换到你想使用的 Cluster 上。具体如何配置可以看代码这里，支持自定义的配置文件，也支持 -D 环境变量的方式传入，key 为 consumer.Cluster。\n 为啥不支持单个 API 的配置啊，是出于某种考虑吗?\n A：单个 API 的话，可以单独通过 ConsumerConfig 的 setCluster(String Cluster)去设置。但是不是通用功能，所以没加到 annotation 上。\n 感觉和 loadbalance 是差不多同一级的，注解上 lD 支持，Cluster 不支持\u0026amp;hellip;\n A：这个功能感觉更偏全局一些，当然也是有单个 API 自定义的需求，之前的设计可能也是基于这个考量。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@崔伟协 提问：\n 所有整个流程里的异常返回（那些没转发到 Upstream/或者转发失败的，直接返回给 client)都会经过这里吗？ https://github.com/mosn/mosn/blob/master/pkg/proxy/downstream.go#L1359\n A：也不一定，你的诉求是啥呢？但是所有请求基本都会走 filter，你可以在 append filter 劫持返回的请求。\n 就是捕获一波没转发的或者转发失败的，不包括已经转发的然后返回失败的。\n A：这个可能还不太好区分，超时也算是转发的了，但超时之后也会调用 hijack。返回的包是不是 Upstream 发过来是可以判断的， 你写一个 append filter，然后判断 types.VarProxyIsDirectResponse 这个变量。\n「MOSN」：https://github.com/mosn/mosn\n@我是一个小胖子 提问：\n 这个统一路由框架，已经 ready，还是在计划中？\n A：https://mosn.io/blog/posts/how-use-dynamic-metadata/\n可以参考这篇文章，是更加灵活的方案。还有一部分没在文档里，就是路由的 match 规则也支持变量和 DSL。\n「MOSN」：https://github.com/mosn/mosn\n@Noob Xu 提问：\n 请问一下，MOSN 的国密 TLS 支持，是不是先用 \u0026amp;ndash;prefix=/usr/local/BabaSSL/linux_BabaSSL_lib 构建 BabaSSL，然后用 CGO_ENABLED=1 go build -tags BabaSSL 构建 MOSN，是不是就支持 TLS 1.3 + 国密单证书了 ？\n A：在/usr/local/BabaSSL/linux_BabaSSL_lib 这个路径下放上 BabaSSL 的 lib，比如/usr/local/BabaSSL/linux_BabaSSL_lib，然后 CGO_ENABLED=1 go build -tags=BabaSSL 之后配置里 TLS 的 CipherSuite 按照 MOSN 支持的几种格式配置，比如 ECDHE-RSA-SM4-SM3 就可以了。在 MOSN 和 MOSN 之间的 TLS 通信就可以走 1.3 和国密了。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 叮，你有一份开发者问卷到了\n一图看懂 SOFAStack 社区的 2021 ｜文末有“彩蛋”\n服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n","date":1641538800,"description":"SOFA Weekly |SOFA 社区插话小剧场、本周 Contributor、QA 整理 ","dir":"blog/sofa-weekly-20220107/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e8f7168b6d3204a6c3f130a563ead237","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220107/","publishdate":"2022-01-07T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220107/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |SOFA 社区插话小剧场、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220107/","wordcount":1625},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@东仔 提问：\n SOFARegistry 的 client、meta、data、session 的四个模块间怎么交互的？\n A：client API 参考 :\nhttps://www.sofastack.tech/projects/sofa-registry/java-sdk/\nmeta、data、session 没有提供 API 文档, 相关介绍可以看下:\nhttps://github.com/sofastack/sofa-registry/releases/tag/v6.1.4\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@刚刚 提问：\n 获取有效链接，这个方法不是每次 new 一个 TCP 链接？\n A：会复用的，为 0 的时候才新建，不为 0 的时候我看是去到一个，直接把那个位置重置为 nil 了。\n 复用是体现在？还是我 down 大代码不是最新的。\n A：用完了会放回这个 avliableclients 的数组里，你的代码不是最新，但大致逻辑也就这样。\n「MOSN」：https://github.com/mosn/mosn\n3、之前有同学问到 OpenKruise 怎么热升级 MOSN，欢迎大家阅读这篇文档试用反馈！\nhttps://mosn.io/blog/posts/mosn-sidecarset-hotupgrade/\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nMOSN 本周发布 发布 MOSN V0.26.0 版本，主要变更如下：\n主要更新如下：\n XProtocol 进行了重构，XProtocol 不再是一种协议，而是便于协议扩展实现的框架\n 新增 ip_access filter，基于来源 IP 的 ACL 控制器\n 支持 go plugin 加载协议转化插件，并支持动态选择协议转换插件\n 支持动态设置上游协议，使用 transcoder filter 来替换 Proxy 中的协议转换\n 其他优化与BUG Fix\n 「详细参考」：\nhttps://mosn.io/blog/releases/v0.26.0/\n本周推荐阅读 一行降低 100000kg 碳排放量的代码！\nSOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1640934000,"description":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","dir":"blog/sofa-weekly-20211231/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1e143008505428e2046bc3c99bd99e51","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211231/","publishdate":"2021-12-31T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211231/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区新年祝福、QA 整理、MOSN 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211231/","wordcount":1172},{"author":"张稀虹","categories":"SOFAStack","content":" 文｜张稀虹（花名：止语 )\n蚂蚁集团技术专家\n负责蚂蚁集团云原生架构下的高可用能力的建设 主要技术领域包括 ServiceMesh、Serverless 等\n本文 3631 字 阅读 8 分钟\nPART. 1 故事背景 今年双十一大促后，按照惯例我们对大促期间的系统运行数据进行了详细的分析，对比去年同期的性能数据发现，MOSN 的 CPU 使用率有大约 1% 的上涨。\n为什么增加了？\n是合理的吗？\n可以优化吗？\n是不可避免的熵增，还是人为的浪费？\n带着这一些列灵魂拷问我们对系统进行了分析\nPART. 2 问题定位 我们从监控上发现，这部分额外的开销是在系统空闲时已有，并且不会随着压测流量增加而降低，CPU 总消耗增加 1.2%，其中 0.8% 是由 cpu_sys 带来。\n通过 perf 分析发现新版本的 MOSN 相较于老版本， syscall 有明显的增加。\n经过层层分析，发现其中一部分原因是 MOSN 依赖的 sentinel-golang 中的一个StartTimeTicker 的 func 中的 Sleep 产生了大量的系统调用，这是个什么逻辑？\nPART. 3 理论分析 查看源码发现有一个毫秒级别的时间戳缓存逻辑，设计的目的是为了降低高调用频率下的性能开销，但空闲状态下频繁的获取时间戳和 Sleep 会产生大量的系统调用，导致 cpu sys util 上涨。我们先从理论上分析一下为什么这部分优化在工程上通常是无效的，先来看看 Sentinel 的代码：\npackage util import ( \u0026amp;quot;sync/atomic\u0026amp;quot; \u0026amp;quot;time\u0026amp;quot; ) var nowInMs = uint64(0) // StartTimeTicker starts a background task that caches current timestamp per millisecond, // which may provide better performance in high-concurrency scenarios. func StartTimeTicker() { atomic.StoreUint64(\u0026amp;amp;nowInMs, uint64(time.Now().UnixNano())/UnixTimeUnitOffset) go func() { for { now := uint64(time.Now().UnixNano()) / UnixTimeUnitOffset atomic.StoreUint64(\u0026amp;amp;nowInMs, now) time.Sleep(time.Millisecond) } }() } func CurrentTimeMillsWithTicker() uint64 { return atomic.LoadUint64(\u0026amp;amp;nowInMs) } 从上面的代码可以看到，Sentinel 内部用了一个 goroutine 循环的获取时间戳存到 atomic 变量里，然后调用 Sleep 休眠 1ms，通过这种方式缓存了毫秒级别的时间戳。外部有一个开关控制这段逻辑是否要启用，默认情况下是启用的。从这段代码上看，性能开销最大的应该是 Sleep，因为 Sleep 会产生 syscall，众所周知 syscall 的代价是比较高的。\ntime.Sleep 和 time.Now 对比开销到底大多少呢？ 查证资料（1）后我发现一个反直觉的事实，由于 Golang 特殊的调度机制，在 Golang 中一次 time.Sleep 可能会产生 7 次 syscall，而 time.Now 则是 vDSO 实现的，那么问题来了 vDSO 和 7 次系统调用相比提升应该是多少呢？\n我找到了可以佐证的资料，恰好有一个 Golang 的优化（2），其中提到在老版本的 Golang 中（golang 1.9-)，Linux/386 下没有这个 vDSO 的优化，此时会有 2 次 syscall，新版本经过优化后理论性能提高 5～7x+，可以约等于一次 time.Now \u0026amp;lt;= 0.3 次 syscall 的开销。\nCache 设计的目的是为了减少 time.Now 的调用，所以理论上这里调用量足够大的情况下可能会有收益，按照上面的分析，假设 time.Now 和 Sleep 系统调用的开销比是 0.3:7.3（7+0.3），Sleep 每秒会执行 1000 次（不考虑系统精度损失的情况下），这意味着一秒内 CurrentTimeMillsWithTicker 的调用总次数要超过 2.4W 才会有收益。\n所以我们再分析一下 CurrentTimeMillsWithTicker 的调用次数，我在这个地方加了一个 counter 进行验证，然后模拟请求调用 Sentinel 的 Entry，经过测试发现：\n 当首次创建资源点时，Entry 和 CurrentTimeMillsWithTicker 的放大比为 20，这主要是因为创建底层滑动窗口时需要大量的时间戳计算\n 当相同的 resource 调用 Entry 时，调用的放大比⁰为 5:1\n ｜注 0: 内部使用的 MOSN 版本基于原版 Sentinel 做了一些定制化，社区版本放大比理论上低于该比值。\n考虑到创建资源点是低频的，我们可以近似认为此处调用放大比为 5。所以理论上当单机 QPS 至少超过 4800 以上才可能会取得收益\u0026amp;hellip;\u0026amp;hellip;我们动辄听说什么 C10K、C100K、C1000K 问题，这个值看上去似乎并不很高？但在实际业务系统中，这实际上是一个很高的量。\n我随机抽取了多个日常请求量相对大的应用查看 QPS（这里的 QPS 包含所有类型的资源点，入口/出口调用以及子资源点等，总之就是所有会经过 Sentinel Entry 调用的请求量），日常峰值也未超过 4800QPS，可见实际的业务系统中，单机请求量超过这个值的场景是非常罕见的。¹\n｜注 1: 此处监控为分钟级的数据监控，可能与秒级监控存在一定的出入，仅用于指导日常请求量评估。\n考虑到这个优化还有一个好处，是可以降低同步请求时间戳时的耗时，所以我们可以再对比一下直接从 atomic 变量读取缓存值和通过 time.Now() 读取时间戳的速度。\n可以看到单次直接获取时间戳确实比从内存读取开销大很多，但是仍然是 ns 级别的，这种级别的耗时增长对于一笔请求而言是可以忽略不计的。\n大概是 0.06 微秒，即使乘以 5，也就是 0.3 微秒的增加。在 4000QPS 这个流量档位下我们也可以看一下 MOSN 实际 RT。\n两台机器的 MOSN RT 也没有明显的差异，毕竟只有 0.3 微秒\u0026amp;hellip;\nPART. 4 测试结论 同时我们也找了两台机器，分别禁用/启用这个 Cache 进行测试，测试结果佐证了上述分析的结论。\n从上图的数据可以看出来，启用 Cache 的情况下 cpu sys util 始终比不启用 Cache 的版本要大，随着请求量增加，性能差距在逐步缩小， …","date":1640674800,"description":"一行降低 100000kg 碳排放量的代码！","dir":"blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"93ce5b0bb923a249ebd161465f032ce8","permalink":"https://sofastack.github.io/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","publishdate":"2021-12-28T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","summary":"文｜张稀虹（花名：止语 ) 蚂蚁集团技术专家 负责蚂蚁集团云原生架构下的高可用能力的建设 主要技术领域包括 ServiceMesh、Serverles","tags":["SOFAStack"],"title":"一行降低 100000kg 碳排放量的代码！","type":"blog","url":"/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/","wordcount":3103},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@微光 提问：\n 有一个嵌入式分布式 KV 存储需求，JRaft RheaKV 能用在生产吗？\n A：我们的时序数据库集群基于 RheaKV 做元数据存储和集群调度。\n有关内容可以参考这个文件：《\u0026amp;rdquo;使用组件及场景：时序数据库集群基于 RheaKV 做元数据存储和集群调度\u0026amp;rdquo;》\nhttps://github.com/sofastack/sofa-jraft/issues/524\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@微光 提问：\n RheaKV 中这样移除一个节点 Node，好像不行。在 DefaultRheaKVCliService 中是否可以提供动态上线 Node 和下线 Node 的 API？\n A：你提的都支持。所谓动态，不是说 JRaft 决定的，是你的运维系统可以使用 JRaft API 动态执行。\nissue 详细回复：https://github.com/sofastack/sofa-jraft/issues/747\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@苏泽东 提问：\n 哪位老师帮我解答下这个 Endstream 方法?\n A：这个主要是请求发出去后，一直等到收到响应后，记录下 RT 时间等监控数据。\n「MOSN」：https://github.com/mosn/mosn\n@火种 提问：\n 咨询一个问题：看 MOSN 的源码，如果非 netpoll，是通过在 startRWLoop 来实现的，如果是使用 netpoll 的情况下，长链接是怎么迁移的？\n A：https://mp.weixin.qq.com/s/ts_qsUee6mUFv0FpykaOXQ 推荐你看下这个文件。\n startRWloop 会调用 startreadloop 和 startwriteloop，在这两个函数中进行了长链接的数据的交换，但是使用 netpoll 后，代码分支就变成 netpoll 相应的分支了，不会进入上述两个函数了。\n A：没有支持 netpoll 模式的迁移。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n网商双十一基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\n","date":1640329200,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211224/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9977b0cb01909a1c2ef21e4a2026b36b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211224/","publishdate":"2021-12-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211224/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211224/","wordcount":1292},{"author":"马振雄","categories":"SOFAStack","content":" 近几年云计算的发展如火箭般迅猛，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施的统一资源调度带来了极大挑战。\n在越来越复杂的异构基础设施上，存量应用和增量应用应该如何上云？面对大量异构基础设施带来的挑战，企业如何最大化上云价值？\n12 月 15 日，在以“引领分布式云变革，助力湾区数字经济”为主题的全球分布式云大会上，蚂蚁集团数字科技事业部产品总监马振雄分享了分布式云异构基础设施之上，蚂蚁集团在构建分布式云 PaaS 平台 SOFAStack 背后的实践和思考。\nPART. 1 服务网格定义新的应用上云路径 随着云原生的发展，企业在技术升级的过程中伴随着大量的历史包袱，这些历史包袱是所有存量的异构功能，这些异构功能有以下几个特征：技术架构异构、通信协议异构、开发框架异构。\n这些存量的应用如何在异构的基础设施上统一纳管，背后就涉及到了应用的全生命周期，从研发时的应用改造成本，到运行时如何对异构应用做统一服务治理，再到运维时如何对基础设施进行统一元数据管理、统一变更、统一容灾、统一应急以及资金安全，这些都是存在于 PaaS 层的挑战。\n如果说 IaaS 层的统一资源调度以资源为视角和出发点，那么在上层 PaaS 则需要以应用为视角思考整个分布式基础设施的复杂度到底会带来哪些挑战，以及企业应该如何应对。\n企业存在大量的历史包袱，历史包袱五花八门，如果要把这些历史包袱全部改造成分布式应用或者云原生应用，背后需要的代价非常昂贵，很难有一家企业在短时间内愿意负担起这样的时间和成本，彻底将所有的历史包袱云原生化。\n相比于其他上云方式，Service Mesh 能够实现跨平台、跨协议，并且业务代码无侵入改造，从而快速地将应用植入 Sidecar 完成 Mesh 化，获得分布式红利、安全可观测，并且整个架构平滑演进。企业在架构升级过程中可以按部就班、循序渐进，并且实现端到端的安全可信以及全链路可观测能力。\n总体来说网格服务首先降低了传统应用改造成分布式、云原生应用的成本问题；其次是解决了所有企业新老系统的互联互通和统一纳管的问题；第三是让企业应用架构在升级过程变得更平滑；第四是让所有企业保留自己存量系统的技术栈，且保留了企业自身自主可控性要求。\nForrester 长期以来对蚂蚁集团的创新技术保持关注，Forrester 首席分析师、Serving Technology Executives 服务技术决策者戴鲲发布《蚂蚁集团服务网格总体经济影响》，并分享了他对于 Mesh 的研究，\n未来要实现开发的智能化，需要通过微服务来进行智能化进程，不再像以前一样零敲碎打。对传统应用进行定制化，要通过网格服务动态地组装，实现云上开发。\n通过对蚂蚁集团客户的访谈，Forrester 发现无论是传统金融机构还是互联网金融机构，都面临在混合架构下存在的共性挑战，包括基础设施升级换代、应用开发升级、云上云下交互等方方面面。Forrester 发现网格服务从单体应用改造成本节省到运维安全管理效率提升等方面都有明显的收益，通过研究三年数据测算，使用蚂蚁服务网格产品后，客户的投资回报率达到 99%。\nPART. 2 SOFAStack 实现异构统一运维与弹性容灾 基于自身的技术积累和场景打磨，蚂蚁数字科技定义了分布式云 PaaS 平台在运维态的六大能力，包括统一元数据管理、统一集群资源管理、统一变更能力、统一应急能力、统一容灾能力，和统一端到端从业务、应用到基础设施的可观测能力。在此基础上，蚂蚁数字科技重新定义 SRE，实现统一应用运维能力。\n行业一般认为 SRE 中的“R”（Reliability）是可靠性，蚂蚁数字科技结合自身十几年来对业务可用性和连续性的极致追求，经历了十多次双十一大规模验证，对 SRE 进行重新定义，将 SRE 里的 R 从 Reliability 转变为 Risk，意味着蚂蚁自身的保障体系是以风险为核心。最终通过十几年来的技术沉淀，打造了自己的技术风险保障平台 TRaaS。也正是因为这十几年沉淀的精华，才能让蚂蚁做到业务、应用、基础设施的运维无人值守，运维“自动驾驶”。\n蚂蚁的技术风险防控体系从上到下分别代表了三个目标：高可用、资金安全、低成本。三个组织保障：团队、文化、制度。再到需求、研发、发布以及监控的四条防线，最终沉淀出一套完整的技术风险保障体系的平台能力，整个平台由四个能力板块组成，包括了从应急、变更到容量、资金安全。\n应急平台建立起了以风险为核心的事前、事中、事后的故障风险保障体系，分别对应故障风险检测能力、故障定位能力、故障应急和自愈能力，以及故障的回溯能力。变更平台建立起了以变更为核心的事前、事中、事后的变更风险自动分析、防御、阻断能力。容量平台建立起了对于全局数据中心和系统整体瓶颈的自动探测、容量规划和容量保鲜能力。最后的资金平台，通过对业务应用无侵入地建立起了资金核对第二道防线，帮助企业彻底规避资金安全风险，减少资损。\n如果说第一个核心的挑战解决的是研发态和运行态的问题，第二个核心挑战解决运维态问题，第三个核心挑战，要解决的是从整体架构上解决容灾态的问题。\n随着分布式云基础设施的蓬勃发展，企业数据中心从集中化走向离散化，这意味着企业任何一个应用随时随地可以跑在全国的任何一家数据中心机房的任何一个节点。这种变化背后，从应用视角来看，迫切需要整体的系统应用架构，支撑业务突破地域和城市级别的无限可扩展能力。基于蚂蚁对于业务连续性的极致追求，蚂蚁在支撑业务发展过程中，建立起了金融行业超大规模的三地五中心，并沉淀了一套异地多活单元化架构，解决企业在容灾、弹性、灰度方面的三大痛点。\n容灾方面，可以支撑企业的数据中心架构彻底从单活走向同城双活、两地三中心、再走向多地多活。一个业务单元发生故障不会影响到另外一个业务单元，从架构本身原生保障了业务的可靠性和连续性。\n弹性方面，由于灵活部署和快速扩容机制，能够结合灵活的流量调拨机制，支撑企业的数据中心突破城市和地域级别的扩展，做到真正意义上的无限可扩展。\n灰度，结合跨单元的路由分发，可以轻易地做到蓝绿单元这样具有创新的业务灰度方式。\n多地多活的架构非常复杂，从上至下包含了四层，从接入层做路由规则和路由分发，到应用层的中间件路由，再到数据层的数据分片和数据路由，最后到运维层的统一容灾、统一监控、单元拓扑。\n以金融行业为例，大型银行在主机下移过程中，需要面临的重要课题就是如何将核心系统下沉到分布式集群，在分布式集群下移过程中如何匹配主机系统性能和稳定性，背后很重要的能力就是多地多活架构。\n最终，蚂蚁在以上三个核心挑战的实践过程中，沉淀出新一代分布式云 PaaS 平台 SOFAStack。平台在金融行业有非常多的头部客户案例，从原生能力就满足了金融行业远高于其他行业在容量、性能、规模、高可用、合规、降本提效等方面的高标准要求。更重要的是 SOFAStack 来源于金融行业，但不止于金融行业，蚂蚁希望通过 SOFAStack 赋能到更多的行业，完成更多企业的数字化转型。\nPART. 3 SOFAStack 未来演进方向 Mesh 的未来会经历三个重要的发展阶段：\n第一个阶段，不止是 Service …","date":1640242800,"description":"SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验","dir":"blog/the-practice-and-thinking-behind-sofastack/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cb8e3ab2323cb918eeb7a4cb68408c61","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","publishdate":"2021-12-23T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","summary":"近几年云计算的发展如火箭般迅猛，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施","tags":["SOFAStack"],"title":"SOFAStack 背后的实践和思考｜新一代分布式云 PaaS 平台，打造企业上云新体验","type":"blog","url":"/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/","wordcount":3335},{"author":"吕冰洁","categories":"SOFAStack","content":" 吕冰洁（花名：尚之）蚂蚁集团技术专家\n我们团队是在做蚂蚁集团内部 Serverless 项目，深度依赖 SOFAArk。SOFAArk 作为 Serverless 项目的核心热部署组件，在无感接入、快速启动方面有很大的诉求。\n因此为 SOFAArk 2.0 提供了最核心的内嵌式运行模式，同时对 1.0 版本存在的一些问题做了较多的性能优化。\n2022 年 03 月 07 日，吕冰洁@zjulbj 被投票选为，SOFAArk Committer。\nBefore 我主要是负责让传统的 SOFABoot 的应用平滑迁移到 SOFAArk 上。\n开始走了很多弯路，接入成本上可能需要半个月到一个月。最初选择了新建应用切流这种比较间接的方案，基于这个方案做迁移过程中的平滑迁移、切流工具。\n但是没解决根本问题，只是通过工具减少了部分工作量。\n过程 我们就尝试通过修改架构把这些问题解掉，推动自己深入了解底层，思考它为什么是这么设计的，为什么导致现在的问题？\n通过研究之后，发现最开始 SOFAArk 是面向终态去设计的，是比较理想化的容器。但实际落地过程中，业务是逐步演进而来的。刚接入就要感知特别大的变化，涉及部署脚本、镜像、测试脚本等一系列的改造，导致业务无法快速享受 SOFAArk 带来的红利。\n我们就借鉴之前的经验，比如 Tomcat 最开始是一个容器，后面往内嵌化发展。我们内部的 CloudEngine 最开始也是一个容器，后面往 SOFABoot 演进也是一个往内嵌化的发展。\nAfter 所以从我们整个迁移和落地的角度，设计了这套方案，修改其中的相关代码。\n从原来需要 2~3 周到现在的一天，降低迁移的成本，省去了大量迁移工作。也为我们后面全站规模化、商业化的一键开启 ark 奠定了基础。\n作为业务研发深入中间件开发底层 Q:如何看待自己作为业务研发的身份接触到开源？\nA:作为业务研发，深入到开源组件的底层设计，不仅对我们自己使用组件有很大的帮助，也能让我们和开源社区的组件同步节奏，不至于脱节。\n另外我们解决了实际问题，其他的使用方肯定也会遇到同样的问题。那我们是不是可以把已有的经验，回馈到开源社区帮助到更多的人。我觉得这是一个良性循环的开源环境，而不是向开发者提一些需求 pr 就结束了。\nQ:你觉得解决这个问题的难点在哪里？\nA:主要的难点还是我以业务研发的身份，参与到整个 SOFAArk 中间件的开发中。\n首先我需要对它的整个设计有清晰的把握，尽管之前有半年的使用经验，也依然花费了一周的时间才搞懂了核心架构。还好 ark 的文档写得很详细，大大降低了我的理解成本。\nQ:在沟通的过程中有没有什么困难的？\nA:沟通没有困难，毕竟大家都是技术，其实都是相通的。只要把自己的使用场景说清楚，中间过程遇到的一些具体问题说清楚。然后结合整个社区的生态，思考一下自己的需求处于什么样的定位，毕竟大家都是基于问题出发。\n也是通过这次深入开发底层，让我们更清晰的认识到大家都是绑在一条船上的，也更理解开发者，毕竟大家初心都是为了共同的目标去努力。\n业务研发和开发者的双重身份是否有可持续性？ Q:这个状态还会一直持续下去吗？\nA:目前我已经成为了 SOFAArk 2.0 的核心开发人员，还会推进 SOFAArk 在蚂蚁主站大规模落地，作为开发的角色维护下去的。本身我们的 Serverless 产品它下面依赖的部署组建就是 SOFAArk，我们要去大规模落地的过程中，涉及到对 ark 的一些支持问题，所以我们可能需要深入到底层去剖析，让组件真正的更易用。\nQ:业务研发深入到中间件底层设计，在开源社区是一个普遍的现象吗？\nA:我理解应该是都有这样的现象，比如说我们用到动态热部署的能力，那我们对启动优化的东西，后面也会把它那个反馈到 SOFABoot、 Spring Boot 社区。\n在我们自己落地过程中遇到的问题，想到的创新解决方案，如果是通用的话，会往各个社区去提 pr、做一些反馈的进行同步。\n比如，我们在 SOFAArk 启动加速这一块，针对 Classloader 做了启动类加载的优化，启动速度平均提升了 50% 左右。\n目前这个已经在 Spring Boot 提了 pr，他们那边正在跟进；\nSOFABoot 这边也有相关的同学在保持跟进，之后我们会在我们主站率先去做一个 backport 的支持。\n业务研发专属经验分享 A:SOFAArk 负责人说你是一个追求细节、追求极致的同学。\nQ:我们团队是做 Serverless 产品的，产品的要求是“更快、更高效、性能更好、体验更好”。\n这就要求了我们在做代码优化的过程中去追求细节、追求极致，也是我们整个团队的风格。\nA:有了这种特殊经历后，有哪些经验可以分享给其他业务研发的吗？\nQ:作为业务研发，最开始我对 ark 也不是很了解的，刚接手 ark 的迁移的东西，也没敢想说去对 ark 做这么大的改造。\n一切基于我们团队的问题出发，一步步深入了解它的原理，去尝试实践自己想法，最终做出了开源的贡献，回过头来看才发现自己做了这么多。\n大部分业务研发不太愿意去参与这种开源贡献，可能就是把它想得比较难了。\n大家不用担心深入底层开发是很有门槛的事情，只要你带着问题出发，其他的都不是问题！\n看他不爽，就直接动手改吧！\n本周推荐阅读 社区文章｜MOSN 路由框架详解\nHAVE FUN | SOFARegistry 源码解析\nBabaSSL：支持半同态加密算法 EC-ElGamal\n恭喜 吕冰洁 成为 SOFAStack committer！\n","date":1640070000,"description":"SOFAArk Committer 专访｜看它不爽，就直接动手改！","dir":"blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"af2c0c99370a29c6e191e9a912277670","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","publishdate":"2021-12-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","summary":"吕冰洁（花名：尚之）蚂蚁集团技术专家 我们团队是在做蚂蚁集团内部 Serverless 项目，深度依赖 SOFAArk。SOFAArk 作为 Serverless 项目的核心热部署组件，在无","tags":["SOFAStack"],"title":"SOFAArk Committer 专访｜看它不爽，就直接动手改！","type":"blog","url":"/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/","wordcount":1947},{"author":"曾柯","categories":"SOFAStack","content":" 文｜曾柯（花名：毅丝 )\n蚂蚁集团高级工程师\n负责蚂蚁集团的接入层建设工作,主要方向为高性能安全网络协议的设计及优化\n本文 10279 字 阅读 18 分钟\nPART. 1 引言 作为系列文章的第一篇，引言部分就先稍微繁琐一点，让大家对这个系列文章有一些简单的认知。\n先介绍下这个系列文章的诞生背景。QUIC、HTTP/3 等字眼想来对大家而言并不陌生。从个人的视角来看，大部分开发者其实都已经有了一些背景知识，比如 HTTP/3 的核心是依赖 QUIC 来实现传输层及 TLS 层的能力。而谈及其中细节之时，大家却又知之甚少，相关的文章大多只是浅尝辄止的对一些 HTTP/3 中的机制和特性做了介绍，少有深入的分析，而对于这些机制背后诞生原因，设计思路的分析，就更难得一见了。\n从个人并不大量的 RFC 阅读及 draft 写作经历来看，和撰写论文文献一样，为了保证一份 RFC 的精简以及表述准确，当然也是为了编写过程的简单。在涉及到其他相关协议时，作者往往是通过直接引用的方式来进行表述。这也就意味着直接通过阅读 RFC 来学习和了解网络协议是一个曲线相对比较陡峭的过程，往往读者在阅读到一个关键部分的时候，就不得不跳转到其他文档，然后重复这个令人头痛的过程，而当读者再次回到原始文档时，可能都已经忘了之前的上下文是什么。\n而 HTTP/3，涉及到 QUIC、TLS、HTTP/2、QPACK 等标准文档，而这些标准文档各自又有大量的关联文档，所以学习起来并不是一个容易的事。\n当然，系列文章的立题为“深入 HTTP/3”，而不是“深入 QUIC”，其背后的原因就是 HTTP/3 并不仅仅只是 QUIC 这么一个点，其中还包含有大量现有 HTTP 协议和 QUIC 的有机结合。在系列文章的后续，也会对这一部分做大篇幅的深入分析。\n一个协议的性能优秀与否，除了本身的设计之外，也离不开大量的软硬件优化，架构落地，专项设计等工程实践经验，所以本系列除了会针对 HTTP/3 本身特性进行分享之外，也会针对 HTTP/3 在蚂蚁落地的方案进行分享。\n引言的最后，也是本文的正式开始。\n据统计，人类在学习新的知识时，比较习惯从已有的知识去类比和推断，以产生更深刻的感性和理性认识。我想对大部分同学而言，“TCP 为什么要三次握手以及四次挥手？”这个问题，颇有点经典的不能再经典的味道，所以今天这篇文章也将从 QUIC 链接的建立流程及关闭流程入手，开始我们系列的第一篇文章。\nPART. 2 链接建立 2.1 重温 TCP “TCP 为什么要三次握手？”\n在回答问题之前我们需要了解 TCP 的本质，TCP 协议被设计为一种面向连接的、可靠的、基于字节流的全双工传输层通信协议。\n“可靠”意味着使用 TCP 协议传输数据时，如果 TCP 协议返回发送成功，那么数据一定已经成功的传输到了对端，为了保证数据的“可靠”传输，我们首先需要一个应答机制来确认对端已经收到了数据，而这就是我们熟悉的 ACK 机制。\n“流式”则是一种使用上的抽象(即收发端不用关注底层的传输，只需将数据当作持续不断的字节流去发送和读取就好了)。“流式”的使用方式强依赖于数据的有序传输，为了这种使用上的抽象，我们需要一个机制来保证数据的有序，TCP 协议栈的设计则是给每个发送的字节标示其对应的 seq(实际应用中 seq 是一个范围，但其真实效果就是做到了每个字节都被有序标示)，接收端通过检视当前收到数据的 seq，并与自身记录的对端当前 seq 进行比对，以此确认数据的顺序。\n“全双工”则意味着通信的一端的收发过程都是可靠且流式的，并且收和发是两个完全独立，互不干扰的两个行为。\n可以看到，TCP 的这些特性，都是以 seq 和 ACK 字段作为载体来实现的，而所有 TCP 的交互流程，都是在为了上述特性服务，当然三次握手也不例外，我们再来看 TCP 的三次握手的示意图：\n为了保证通信双方都能确认对端数据的发送顺序，收发端都需要各自记录对端的当前 seq，并确认对端已经同步了自己的 seq 才可以实现，为了保证这个过程，起码需要 3 个 RTT。而实际的实现为了效率考虑，将 seq 和 ACK 放在了一个报文里，这也就形成了我们熟知的三次握手。\n当然，三次握手不仅仅是同步了 seq，还可以用来验证客户端是一个正常的客户端，比如 TCP 可能会面临这些问题：\n(1)有一些 TCP 的攻击请求，只发 syn 请求，但不回数据，浪费 socket 资源；\n(2)已失效的连接请求报文段突然又传送到了服务端，这些数据不再会有后续的响应，如何防止这样的请求浪费资源？\n而这些问题只是三次握手顺手解决的问题，不是专门为了它们设计的三次握手。\n细心的你，可能已经发现了一个问题，如果我们约定好 client 和 server 的 seq 都是从 0(或者某个大家都知道的固定值)开始，是不是就可以不用同步 seq 了呢？这样似乎也就不需要三次握手那么麻烦了？可以直接开始发送数据？\n当然，协议的设计者肯定也想过这个方案，至于为什么没这么实现，我们在下一章来看看 TCP 面临什么样的问题。\n2.2 TCP 面临的问题 2.2.1 seq 攻击 在上一节我们提到，TCP 依赖 seq 和 ACK 来实现可靠，流式以及全双工的传输模式，而实际过程中却需要通过三次握手来同步双端的 seq，如果我们提前约定好通信双方初始 seq，其实是可以避免三次握手的，那么为什么没有这么做呢？答案是安全问题。\n我们知道，TCP 的数据是没有经过任何安全保护的，无论是其 header 还是 payload，对于一个攻击者而言，他可以在世界的任何角落，伪造一个合法 TCP 报文。\n一个典型的例子就是攻击者可以伪造一个 reset 报文强制关闭一条 TCP 链接，而攻击成功的关键则是 TCP 字段里的 seq 及 ACK 字段，只要报文中这两项位于接收者的滑动窗口内，该报文就是合法的，而 TCP 握手采用随机 seq 的方式（不完全随机，而是随着时间流逝而线性增长，到了 2^32 尽头再回滚）来提升攻击者猜测 seq 的难度，以增加安全性。\n为此，TCP 也不得不进行三次握手来同步各自的 seq。当然，这样的方式对于 off-path 的攻击者有一定效果，对于 on-path 的攻击者是完全无效的，一个 on-path 的攻击者仍然可以随意 reset 链接，甚至伪造报文，篡改用户的数据。\n所以，虽然 TCP 为了安全做出过一些努力，但由于其本质上只是一个传输协议，安全并不是其原生的考量，在当前的网络环境中，TCP 会遇到大量的安全问题。\n2.2.2 不可避免的数据安全问题 相信 SSL/TLS/HTTPS 这一类的字眼大家都不陌生，整个 TLS(传输安全层)实际上解决的是 TCP 的 payload 安全问题，当然这也是最紧要的问题。\n比如对一个用户而言，他可能能容忍一次转账失败，但他肯定无法容忍钱被转到攻击者手上去了。TLS 的出现，为用户提供了一种机制来保证中间人无法读取，篡改的 TCP 的 payload 数据，TLS 同时还提供了一套安全的身份认证体系，来防止攻击者冒充 Web 服务提供者。然而 TCP …","date":1640070000,"description":"深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进","dir":"blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","fuzzywordcount":9100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"399aa26268182488b3d65e0618367a35","permalink":"https://sofastack.github.io/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","publishdate":"2021-12-21T15:00:00+08:00","readingtime":19,"relpermalink":"/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","summary":"文｜曾柯（花名：毅丝 ) 蚂蚁集团高级工程师 负责蚂蚁集团的接入层建设工作,主要方向为高性能安全网络协议的设计及优化 本文 10279 字 阅读 18 分钟 PART. 1 引言 作为","tags":["SOFAStack"],"title":"深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进","type":"blog","url":"/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/","wordcount":9072},{"author":"SOFA 团队","categories":"SOFA","content":" 概要 活动主题：SOFA x 字节码联盟 WAMR 社区「WebAssembly Open Day」\n 活动时间：2021 年 12 月 18 日（周六）13:00-17:00\n 活动形式：线上直播\n 资料下载：\n 《蚂蚁集团 WASM 编译器虚拟机基础能力建设》 \n《WebAssembly Micro Runtime 开源技术解析与展望》\n《Waft: 基于 WebAssembly 的 AIoT 应用框架实践》\n《WASM 中的 GC 遐想》\n《WebAssembly 在区块链中的实践》\n《Wasm \u0026amp;amp; WAMR 在 AIOT 领域的应用》\n活动议程 活动回顾 嘉宾简介：\n《字节码联盟与 WAMR 开源社区进展介绍》\n王鑫 intel 技术经理 任职英特尔公司，关注计算机语言与运行引擎，可信计算和物联网等技术领域。开发与创建开源项目 WebAssembly Micro Runtime，参与推动英特尔、微软、Mozilla 等公司成立字节码联盟（Bytecode-Alliance），任字节码联盟技术管理委员会（TSC）成员。\n杨斌（花名：凯撒） 蚂蚁集团技术总监 任职蚂蚁集团技术总监，关注操作系统，计算机语言与运行引擎等技术领域。\nTill Schneidereit 字节码联盟董事会主席\nRalph Squillace 微软高级总监 字节码联盟董事会成员\n汤伟\n蚂蚁集团资深技术专家\n《蚂蚁集团 WASM 编译器虚拟机基础能力建设》\n嘉宾简介：\n汤伟，一直从事编译器和虚拟机相关工作，2020年11月加入蚂蚁金服，主导webassembly相关工具链的设计与开发。\n议题简介： 作为面向蚂蚁的 wasm 编译器、虚拟机基础平台团队，面向蚂蚁 wasm 用户核心诉求，针对开发效率、性能提升以及生态拓展，确定 wasm 编译器、虚拟机上的技术选型，探索未来编译器、虚拟机协同设计空间。\n听众收益： 了解wasm在蚂蚁的业务场景中的需求和我们的编译器、虚拟机技术能力建设上的一些探索。\n何良\nintel 资深软件工程师\n《WebAssembly Micro Runtime 开源技术解析与展望》\n嘉宾简介：何良，INTEL 资深软件工程师， WAMR开源项目核心开发者\n议题简介：主要介绍 WebAssembly Micro Runtime(WAMR) 的技术特性，发展历程以及路线图。面对嵌入式设备独特的资源条件和使用场景，WAMR进行了有针对性的特性开发，比如选用不同的运行模式适应不同的资源水平，利用XIP在文件系统中直接执行，在RUNTIME中支持 Sensor API 等。此外，WAMR努力打造高效的开发环境，提供源码级调试的功能框架和VSCODE插件。目前，支持高级语言（比如JAVA,KOTLIN等）和SOCKET APIs的功能开发正在有序展开。\n唐兹源\n阿里巴巴前端技术专家\n《Waft: 基于 WebAssembly 的 AIoT 应用框架实践》\n嘉宾简介：\n唐兹源，天猫精灵工程技术前端团队负责人，在智能硬件应用研发领域拥有超过 4 年的经验，专注于 AIoT 体验技术创新\n议题简介：\n本次分享将为大家带来天猫精灵技术团队基于 WAMR 和自研渲染引擎打造的应用框架实践经验，介绍 WebAssembly 在天猫精灵智能音箱以及生态硬件（如电视大屏、投影仪等）的应用场景，以及 Waft 应用框架体系的设计和思考\n听众收益：\n了解 WebAssembly 在智能音箱及电视大屏中的应用场景 了解天猫精灵技术团队如何结合 WAMR 和自研渲染引擎设计动态化容器 了解如何运用 AssemblyScript 设计适合 Web 开发者的应用框架及工具链建设\n臧琳\n腾讯云高级工程师\n《WASM中的GC遐想》\n嘉宾简介：腾讯云编程语言团队高级工程师，OpenJDK committer，专注于编程语言 Runtime 技术在云计算领域的优化与应用。\n议题简介：内存管理及垃圾回收技术是现代高级语言的核心技术之一，也是webassembly承载多语言支持的必经之路， wasm社区已经将GC proposal提上日程，本话题和大家一起进行一次头脑风暴，探讨未来wasm的内存管理及垃圾收集技术可能的发展方向。\n张磊\n蚂蚁集团技术专家\n《WebAssembly在区块链中的实践》\n嘉宾简介：毕业于北京大学，曾就职于华为编译器实验室。目前在蚂蚁链智能合约团队，从事编译器和虚拟机相关研发工作。\n议题简介：Wasm 的安全性、高性能和跨平台等优点，使其天然适合用作区块链智能合约的执行环境。另一方面，区块链对于安全性和确定性的极致要求，也对 Wasm 本身提出了一些技术挑战。本次分享将会结合蚂蚁链的实践经验，介绍 Wasm与区块链之间的各种奇妙“化学反应”。\n听众收益：将会了解到wasm在区块链领域的应用现状和面临的技术挑战。\n黄齐\n小米软件工程师/Vela OS 框架业务技术负责人\n《Wasm \u0026amp;amp; WAMR在AIOT领域的应用》\n嘉宾简介：负责小米Vela OS内核、中间件的研发和在不同架构上的落地，带领团队完成了基于Wasm的应用开发框架的开发和落地，支撑了小米内部多项业务发展\n议题简介：Wasm 作为诞生于浏览器的技术，为何能在 IoT 领域大放异彩？在内存只有数十 KB 级别的运行环境里使用 Wasm，我们将面临怎样的挑战和困难？本次向大家分享小米对 Wasm 技术在 IoT 应用中的实践与思考\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1639810800,"description":"【活动回顾】《WebAssembly Open Day》","dir":"activities/sofa-meetup-13/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6055a6cf6a48ee5bfe63e2c249c2e3d4","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-13/","publishdate":"2021-12-18T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-13/","summary":"概要 活动主题：SOFA x 字节码联盟 WAMR 社区「WebAssembly Open Day」 活动时间：2021 年 12 月 18 日（周六）13:00-17:00 活动形式","tags":["SOFA"],"title":"【活动回顾】《WebAssembly Open Day》","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-13/","wordcount":1931},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@孙军超 提问：\n 请教一下 JRaft 里， Bolt 的 logback 日志怎么关掉 ?\n A：可以参考这个文件。https://github.com/sofastack/sofa-jraft/issues/724\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@超 提问：\n 这种方式运行 Wasm 的时候，Layotto 自身加上运行时部分初始化需要加载 Dapr 组件时间可能总共要 1-2s（还没有实测，因为目前只用过 Dapr，后面会实际运行一下）。这方面冷启动延迟一方面可以精简 Wasm 的 runtime 仅包括 Dapr 或者 Layotto 的 SDK 通过网络来通信；另一方面就是优化运行时的启动时间。作者对这方面问题有想法吗？\n A:这个问题属于 Layotto 自身如何快速初始化，目前我们也在这方面做一些尝试，比如优化调度算法，让某些特征的函数调度到特定的 Layotto 上，这样就可以让 Layotto 提前初始化好资源。不过这只是函数急速调度中的一个环节，实际落地过程中还有调度算法执行耗时，Pod 启动耗时，函数自身启动耗时等等因素，这也是我们目前正在努力的方向。\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n Medium 让 Layotto 支持 Dapr API\n开发 Python 或 C++ 、SDK\n开发 Spring-Boot-Layotto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 让用户使用@SofaService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nSOFARegistry 本周发布 SOFARegistry V6 正式发布的第一个版本。\n主要更新如下：\n 运维难度大幅度降低 自身元数据存储插件化，如果不希望引入 raft 运维的复杂性，支持基于 db 实现。meta、session 无状态化，data 弱状态化。\n 性能和可扩展能力大幅提升 横向扩展能力大幅度提升，能够横向扩展至 300+ session 节点，能够承载亿级服务数据。\n「详细参考」：https://github.com/sofastack/sofa-registry/releases/tag/v6.1.4\n网商双十一基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\n降本提效！注册中心在蚂蚁集团的蜕变之路\n","date":1639724400,"description":"开发者的搬砖日常、社区本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211217/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"42ba6063d3d0ebea2b80a70c23e77497","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211217/","publishdate":"2021-12-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211217/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 本周 Contributor、QA 整理、SOFARegistry 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211217/","wordcount":1387},{"author":"张化仁","categories":"SOFAStack","content":" 文｜张化仁（花名：花伦 )\n网商银行基础技术架构部架构师\n校对｜阚广稳(花名：空门)\n本文 4832 字 阅读 10 分钟\n｜引言｜ 微服务架构下，服务之间的调用错综复杂，一个应用可能会承载着多种不同的业务流量。由于运行在同一个应用进程内，多种业务流量之间势必会存在相互影响的情况。\n如果某种业务流量陡增，导致应用进程负载激增，进而请求排队，其它业务流量也势必会受影响。多数时候这种相互影响的情况都是在容忍范围以内或者可以规避的，特定场景下我们可能就需要考虑通过隔离某些业务流量的方式，来消除业务之间相互影响的风险：\n 例如，当后台调度型的流量影响了在线用户请求；\n 再如，当低敏的甚至可失败的业务影响了高敏的需要重保的业务。\n 业务链路隔离的诉求是业内普遍存在的。通常的方案是新创建一个应用，然后将需要隔离的业务迁移到这个新应用上。\n新建应用的方式，研发运维等都需要付出成倍的成本，相关应用还需要配合改造和迁移。对于只有单个应用需要创建的情况或许还能勉强接受，网商银行部分应用例如高保极简网关、高保客户视图等当前就是采用的这种方案。这种方式是非常笨重的，而且当我们期望特定业务关联的整条链路上的多个应用都进行业务隔离的话，这种方案的成本将非线性上升进而变得难以接受。\n云原生架构下，对容器和流量可以进行更精细化的管控，对于上述业务流量隔离的场景，我们有了更简洁、更灵活、更通用的替代方案\u0026amp;ndash;我们称之为「业务单元隔离」，可以在不创建新应用的情况下实现上述诉求。此方案当前已在包括核心链路在内的网商多个业务场景得到应用，也顺利通过了今年双十一大促的考验。\n那么「业务单元隔离」具体是什么？我们是如何借助「业务单元隔离」实现业务链路的隔离呢？本文将和大家细述。\nPART. 1 概念及基本原理 概念及运维模型 「业务单元隔离」是一套流量染色和资源隔离的方案，可以帮助业务相对简单地实现业务链路隔离。在调研和验证的过程我们也提出了优化改进方案并推进落地，最终进一步减轻了业务接入的成本。\n「业务单元隔离」需要结合两个新的概念来阐述：「AIG」和「业务单元」。\nAIG 是某个应用为了支撑某些业务而隔离出来的一组资源。由一个或多个应用的 AIG 组成的、服务与某个或某类特定业务的业务链路我们称为一个业务单元。保证有且只有符合特征的流量引流到某个业务单元，我们称之为「业务单元的隔离部署」。\n主要任务及配套设施 从「业务单元隔离」的概念中我们不难看出：要实现某个业务链路的流量隔离，至少需要做有以下几件事情：\n1.业务单元构建：给链路上的应用分别创建 AIG 组成一个业务单元，且须保证不能有流量流入新建的业务单元。\n2.业务流量识别：需要通过某种方式识别出上游应用流入的特定业务的流量。\n3.特定业务引流：对于识别到的特定业务的流量，需要有机制让这些流量流向新创建的业务单元。\n很显然，上述的这些事情，必然需要基础设施侧和应用侧相互配合才可实现。如下图所示，相关的基础设施及作用如下：\n1.业务单元构建：需要为 AIG 提供完整的研发/运维/监控支持；\n2.流量识别（RPC）：链路中业务单元上游的应用（A）需要接入打标染色 SDK，以便通过染色管控平台下发打标染色规则；\n3.流量识别（调度）：复杂调度（消息触发，应用单 LDC 内自主分发批任务）通过转换成基于 SOFARPC 的流式任务，从而实现染色和隔离。\n4.特定业务引流：MOSN 侧的精细化路由需要支持 AIG，让流量可以流入到新特定的业务单元。\n业务单元构建 业务单元实际是一个相对抽象的概念，对应一条业务链路。\n网商的实践中，为了让业务单元更加具象化，我们规定一个业务单元内的多个应用，其 AIG 名称（appname-aigcode）中的 aigcode 部分必须尽可能一致。\n因此，构建一个特定的业务单元，本质上是要给链路上相关的应用，都创建出服务于特定业务隔离的资源组（AIG）。\n对于单个应用，构建 AIG 包含两部分：\n一是初始化 AIG 元数据；\n其次是围绕此 AIG 的各种运维操作（扩缩容、上下线、重启、sidecar 注入升级等）。\n可以看到要支持 AIG，PaaS 侧几乎所有运维操作都需要适配，工作量非常很大。所以 PaaS 侧在支持 AIG 这件事情上也必须权衡取舍，决定只在终态的 workload 运维模式下支持了 AIG，这也导致 AIG 强依赖应用从现有的 image 的模式迁移到 workload 的模式。\nworkload 运维模式下，PaaS 将发布和运维的内容都编排成 CRD 资源，交给底层 sigma（K8s）做运维。切换到 workload 运维模式有利于集团统一发布运维体系，也可以更好的支持弹性扩缩容、自愈等场景。\n但相比 image 模式，workload 模式对用户使用习惯和体验上冲击很大，初期相关的问题也非常多。因此尽管网商 workload 一直在有序推进，在后续核心业务接入 AIG 的项目中，为了避免强制切换到 workload 运维模式影响核心业务运维应急，我们也给 PaaS 提了支持仅对 AIG 机器开启了 workload 的诉求，并且针对这种情况做了完备的混合运维验证。\nRPC 流量隔离 业务单元创建好之后，如何确保新的业务单元在不引流的情况下默认没有 RPC 流量流入呢？\n应用的机器之所以有 RPC 流量流入，是因为注册中心（SOFARegistry）和跨机房负载均衡（AntVip）中挂载了机器 IP：应用进程启动成功 MOSN 感知到后，MOSN 会将服务信息注册到 SOFARegistry，发布运维过程机器健康检查通过后 PaaS 侧会调用接口往 AntVip 上挂载机器的 IP。\n所以，要确保新的 AIG 机器默认没有流量流入，就需要 MOSN 和 PaaS 侧做出调整。\n整体调整方案如下图所示：\n如何识别特定业务的 RPC 流量呢？\n上游应用接入打标染色 SDK 之后，其在作为服务端被其它应用调用、作为客户端调用其它应用的时候，都可以被 SDK 中的 RPC 拦截器拦截，拦截器对比 RPC 请求和下发的打标染色规则，一旦 match 就会在 RPC Header 中增加业务请求标识。\n最后，就是将流量引流到特定业务单元。\n借助 MOSN 强大的精细化路由能力，我们可以让流量路由到指定的业务单元,并在业务单元内部收敛。业务单元隔离主要用到了 MOSN 的客户端路由能力，在客户端应用发起调用、请求流经当前 Pod 的 MOSN 时，可以按我们下发的路由规则控制流量的走向。\n调度流量隔离 调度本质是消息，简单的调度场景通常也不会有隔离的诉求。很多有隔离诉求的场景当前都是“消息任务+三层分发”的模式，利用调度触发批处理逻辑。\n三层分发协议是基于 tb-remoting 协议分发请求的，不是标准的 SOFARPC 协议，不经过 MOSN，因此 MOSN 也无法控制这种请求的走向。\n为了解决这个问题，AntScheduler 推出了全新的流式调度模式，通过将三层分发模式转变成多次标准 SOFARPC 调用，从而和 MOSN 无缝配合，满足流量隔离的诉求。\n对于希望调度流量直接路由到 AIG 的场 …","date":1639465200,"description":"网商双十一-基于 ServiceMesh 技术的业务链路隔离技术及实践","dir":"blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"472fb3f3bcfec5e7e03683b781646824","permalink":"https://sofastack.github.io/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","publishdate":"2021-12-14T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","summary":"文｜张化仁（花名：花伦 ) 网商银行基础技术架构部架构师 校对｜阚广稳(花名：空门) 本文 4832 字 阅读 10 分钟 ｜引言｜ 微服务架构下，服务之间的调用错综复杂","tags":["SOFAStack"],"title":"网商双十一-基于 ServiceMesh 技术的业务链路隔离技术及实践","type":"blog","url":"/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/","wordcount":4521},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@证道者 提问：\n MOSN 的网络性有做新的技术尝试吗?\n A：这个是我们今年在网络性能上的尝试，内部也在网关场景落地，后续也会开源出来。iouringv 之前我们做过测试，在我们的场景提升有限。\nhttps://mp.weixin.qq.com/s/ioewVcwiB5QA8w3A3gaikg\n「MOSN」：https://github.com/mosn/mosn\n@赵一凡 提问：\n 问下 SOFALookout 的客户端可以直接把默认已有度量指标推送到 ES 吗？\n A：一般客户端是上报到 lookout 服务端, 再由服务端决定要写到哪。\n「SOFALookout」：https://github.com/sofastack/sofa-lookout\n@开发者 提问：\n 这个 Test 模块是用来开发者做测试的还是做自动化测试的？\n A：用于 jraft 的 jepsen 验证，参考这个项目：\nhttps://github.com/sofastack/sofa-jraft-jepsen\njraft 每次发版前要确保通过 jepsen 验证。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@小楼 提问：\n 请问 session 是如何支持 Dubbo 的元数据的？\n A：Registery 的元数据现在不是通用的，只针对 SOFARPC。\n session 之间应该是没有数据同步的吧，跨 session 节点怎么办呢？\n A：现在会同步两个信息，一个是元数据，一个是接口级订阅，接口级订阅是用于兼容没升级的应用。同步的路径是通过存储，类似 K8 的 listwatch 机制，内部落地存储的插件实现是 db，这个块数据比较少，就几千行吧，而且变化很小。\n「SOFARegistery」：https://github.com/sofastack/sofa-jraft\n@小楼 提问：\n 是用什么 db 存储的?\n A：蚂蚁内部的 db 普遍都是 ob，不过代码是兼容 mysql 的。\n「SOFARegistery」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API、分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 Service Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\nService Mesh 双十一后的探索和思考(下)\n蚂蚁 Service Mesh 大规模落地实践与展望\n","date":1639119600,"description":"开发者的搬砖日常、社区本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20211210/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c8ef24b5957863311a11eff48080bc30","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211210/","publishdate":"2021-12-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211210/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 开发者的搬砖日常、社区本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211210/","wordcount":1289},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#23：蚂蚁服务发现的大规模实践与展望\n 活动时间：12 月 09 日，周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#23：蚂蚁服务发现的大规模实践与展望 naming 作为一个有着较长发展历史的领域，同时 naming 作为分布式系统的核心，它能支撑的数据规模，稳定性的 SLO 都会对业务造成重大的影响。蚂蚁集团在站内运维着上百个 SOFARegistry 集群，对于 naming 在规模和稳定性都有极高的要求，其中最大集群规模达到千万 pub/sub。我们也对如何向云原生架构演进逐步形成了思路，进行相关的探索实践，并取得了相应的阶段性成果。本次分享将会包含以下内容：\n 蚂蚁内部实践 naming 在云原生时代下的发展方向及趋势 总结和展望 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 林育智 蚂蚁集团高级技术专家。 目前在蚂蚁集团中间件团队负责 naming 等项目的研发工作 议程 18:50-19:00 主持人开场 SOFAGirl-英花 主持人\n19:00-19:30 蚂蚁服务发现的大规模实践与展望 林育智，蚂蚁集团高级技术专家\n你将收获 了解蚂蚁集团在 SOFARegistry 新挑战及云原生时代的思考。\n了解 SOFARegistry 实践经验。\n了解蚂蚁集团对未来 naming 的思考及 naming 在云原生方向上的探索。\n了解未来 SOFARegistry 的发展和相关的社区动向。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1639033200,"description":"12 月 09 日周三晚 19 点，线上直播第 23 期。","dir":"activities/sofa-channel-23/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"781a397af19af21ad03eef254f28fe69","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-23/","publishdate":"2021-12-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-23/","summary":"概要 活动主题：SOFAChannel#23：蚂蚁服务发现的大规模实践与展望 活动时间：12 月 09 日，周三晚 19 点 活动形式：线上直播 资料下载：戳这里","tags":["SOFAChannel","SOFARegistry"],"title":"SOFAChannel#23：蚂蚁服务发现的大规模实践与展望","type":"activities","url":"/sofastack.tech/activities/sofa-channel-23/","wordcount":709},{"author":"顾欣","categories":"SOFAStack","content":" Service Mesh 是下一代的微服务架构基础。蚂蚁集团从 2018 年初就开始了技术探索并进行了落地试点。目前， Service Mesh 覆盖了蚂蚁数千个应用，实现了核心链路全覆盖。\n蚂蚁集团通过 Service Mesh 的大规模落地，向云原生走出了坚实的一步，验证了可行性，真切看到了基础设施下沉后无论是对业务还是对基础设施团队都带来了研发和运维效率的提升，成本的降低。\n与此同时，蚂蚁也在积极将成熟的技术开放给社会，目前已将自研数据面 MOSN 开源，欢迎开源爱好者一起共建。\nhttps://github.com/mosn/mosn\n｜前言｜ 微服务架构是当今互联网和金融机构渐趋主流的系统架构模式，其核心是集成服务通信、服务治理功能的服务框架，微服务框架在持续演进同时，服务网格（Service Mesh）作为一种新型的微服务架构，因架构灵活、普适性强，被认为具有较好发展前景。\n中国工商银行（后简称工行）主动探索服务网格领域，从 2019 年开始服务网格技术预研工作，通过对服务网格技术深入研究和实践后，于 2021 年建设了服务网格平台。服务网格与现有微服务架构融合发展，助力工行应用架构向分布式、服务化转型，承载未来开放平台核心银行系统。\nPART. 1 业界服务网格发展现状 自 2016 年服务网格技术诞生以来，业界涌现了诸多的开源产品，如 Istio（Google + IBM + Lyft）、Linkerd（Twitter）、Consul（Hashicorp）等。其中以 Istio 社区活跃度和认可度最高，被作为服务网格的标杆开源产品。\n服务网格是一个专门处理服务通讯的基础设施层。它通过在业务 Pod 中注入 Sidecar 容器，接管业务容器的通信流量，同时 Sidecar 容器与网格平台的控制平面对接，基于控制平面下发的策略，对代理流量实施治理和管控，将原有服务框架的治理能力下层到 Sidecar 容器中，从而实现了基础框架能力的下沉，与业务系统解耦。\n图 1：服务网格示意图\nSidecar 容器接管后端服务通信的进出流量后，通过标准协议进行服务间通信，可实现跨语言、跨协议的服务互访。此外，Sidecar 容器可对代理的流量进行管控，如统一的服务路由、安全加密、监控采集等。\n图 2：服务网格请求流转过程示意图\nPART. 2 服务网格技术在工行的 探索与实践 工行从 2015 年开启了 IT 架构转型工程，截止目前分布式体系已覆盖 240 余个关键应用，生产已有约超 48 万个提供方分布式服务节点，日均服务调用量超 127 亿，逐步实现了超越主机性能容量的集群处理能力。工行分布式服务平台在稳定支撑已有业务系统的平稳运行同时，也存在一些业界共性的挑战，诸如：\n（1）跨语言技术栈的互联互通需研发多套基础框架，技术研发和维护成本高。\n（2）多产品线下，各应用使用了不同版本的基础框架，推动各应用升级框架周期较长，生产并行运行多版本的基础框架，兼容压力较大。\n为解决当前痛点，工行积极引入服务网格技术，探索解耦业务系统与基础设施，完善服务治理能力。\n与微服务框架融合发展，构建企业级服务网格平台 服务网格（Service Mesh）平台在建设过程中，集成了原有分布式体系的注册中心、服务监控等基础设施，将原服务框架客户端中最基础的通讯协议编解码能力以轻量级客户端的形式保留在业务系统中，其余服务框架客户端的能力均下沉至 Sidecar 中，可与服务框架兼容发展，平滑过渡。\n目前工行已完成服务网格（Service Mesh）平台的建设，在与分布式服务平台融合发展过程中，打通了异构语言系统的服务治理与监控体系，解耦了业务与中间件系统，丰富了流量治理能力，并已在智能投顾、文字识别等应用完成业务试点。\n图 3：服务网格边车（Sidecar）与微服务 SDK 对比图\n服务网格控制平面包含了配置中心、注册中心、安全中心、管控中心、监控中心、日志中心等模块。数据平面 Sidecar 与原服务框架使用相同的通讯协议（Dubbo/Spring Cloud），支持服务网格系统与原服务框架系统互联互通，平滑迁移。\n图 4：工行服务网格架构图\n探索企业级方案，支持规模化部署和平滑迁移 工行服务网格在大数据、高频联机等服务场景下，对流量代理部署模式、平滑迁移、性能优化等方面开展了落地实践。\n（1）大数据场景下的无侵入流量代理部署模式\n工行应用开发语言主要使用 Java，但在大数据领域 Python 语言也被广泛使用。针对异构语言场景，服务网格平台提供了无侵入透明劫持的流量代理方案，简化了异构语言应用接入难度。无侵入流量代理的核心是通过修改网络 Iptables 规则，强制拦截进出业务容器的流量，并将这部分流量重定向至 Sidecar 容器。\n其具体实现为：在启动业务 Pod 时，通过 Init Container（初始化容器）修改业务 Pod 的网络 Iptables 规则，该规则让进出业务容器的流量都强制重定向至 Sidecar 容器，实现 Sidecar 容器对业务容器的流量接管。\n图 5：透明劫持流量代理示意图\n但是 Iptables 对性能和可维护性都存在较大的挑战，故在联机高频服务场景，我们提供了轻量级客户端与 Sidecar 协作的流量代理方案。\n（2）高频联机场景下的低侵入流量代理部署模式\n在联机高频服务场景，我们通过对业务应用引入轻量级的客户端，该客户端在对业务透明的前提下，改变业务应用的服务注册发现行为，将原往注册中心发起的服务注册与订阅的行为转变为往本地 127.0.0.1 的 Sidecar 地址发起服务注册与订阅，并由 Sidecar 代理向注册中心发起服务注册与订阅。业务容器通过 Sidecar 代理订阅后，本地获取的服务目的地址则为 127.0.0.1 的 Sidecar 地址，后续所有请求将会直接发往 Sidecar，再由 Sidecar 转发至真实的服务目的地址，实现流量代理能力。\n图 6：端口流量代理示意图\n（3）传统部署向网格化部署的平滑迁移\n目前工行微服务主要有基于 Dubbo 和 Spring Cloud 两种服务实例组成，且已在生产环境大规模运行，在引入服务网格系统时需具备与原微服务系统的平滑过渡能力。工行通过服务网格系统同时支持 Dubbo 与 Spring cloud 协议，服务网格实例可与原服务框架实例通过相同协议互相访问。使在同一注册中心下，服务网格系统与原分布式服务系统可融合发展，平滑过渡。\n图 7：平滑迁移示意图\n（4）规模化部署后的性能挑战与优化\n目前工行最大的注册中心集群上有超 48 万提供者的超大规模业务场景，而在开源 Isito 架构中，服务发现的目的地址、配置信息等会通过 Pilot 的 Xds API 进行全量下发。在大量服务实例的情况下，全量下发会影响 Pilot 和 Sidecar 的性能和稳定性。服务网格平台通过引入第三方注册中心与配置中心。由 Sidecar 直接对接注册中心与配置中心，支持按需订阅，配置精准下发，大幅降低 Pilot 和 Sidecar 压力。通过压测，控制平面具备支持百万级实例的性能容量能力。\n图 8：工行控制面组件演进 …","date":1639033200,"description":"Service Mesh 在中国工商银行的探索与实践","dir":"blog/exploration-and-practice-of-service-mesh-in-icbc/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a597abc497eb1d695c4aa838d6cb6545","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","publishdate":"2021-12-09T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","summary":"Service Mesh 是下一代的微服务架构基础。蚂蚁集团从 2018 年初就开始了技术探索并进行了落地试点。目前， Service Mesh 覆盖了蚂蚁数千个应用，实现了核心链路全覆盖。 蚂蚁集","tags":["SOFAStack"],"title":"Service Mesh 在中国工商银行的探索与实践","type":"blog","url":"/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/","wordcount":3781},{"author":"马振军","categories":"SOFAStack","content":" 文｜马振军（花名：古今 )\n在基础架构领域耕耘多年\n目前在蚂蚁集团中间件团队\n负责 MOSN、Layotto 等项目的开发工作\n校对｜卓与、齐天\n本文 9053 字 阅读 18 分钟\n｜前言｜ 在过去几年里，蚂蚁集团的基础设施进行了广受瞩目的大规模 Mesh 化改造，成为业内服务网格化的一个标杆。在收获了基础架构团队掌握数据平面带来业务敏捷性的同时，也享受到了将基础设施 SDK 从应用中剥离出来后，带来的应用和基础设施双方更高的易维护性。\n然而服务网格并不是银弹，大规模落地后也面临着新的问题。\n适逢其时，微软牵头的 Dapr 横空出世，把分布式应用运行时的概念带入了大众视野，我们也尝试使用这种思路来解决 Mesh 化后遗留的问题。\n本文通过回顾蚂蚁集团一路从微服务架构到 Service Mesh 再到分布式应用运行时的整个演进历程，结合生产落地过程中遇到的各种问题及思考，尝试探讨一下未来五年，云原生运行时可能的发展方向。\nPART. 1 从 Service Mesh 到应用运行时 2018 年，蚂蚁集团在 Service Mesh 刚刚开始流行的时候，就在这个方向上大力投入，如今已三年有余。Sevice Mesh 早已在公司内大规模落地，支持了生产环境数十万容器的日常运行。\n19 年下半年，Dapr 项目正式开源并持续火爆，应用运行时的概念引起了人们的关注，蚂蚁集团也踏上了从 Service Mesh 到应用运行时的演进道路。\nA、蚂蚁 Service Mesh 实践的收获与遗留问题 在传统的微服务架构下，基础架构团队一般会为应用提供一个封装了各种服务治理能力的 SDK，这种做法虽然保障了应用的正常运行。但缺点也非常明显，每次基础架构团队迭代一个新功能都需要业务方参与升级才能使用，而遇到 bugfix 版本，往往需要强推业务方升级，这里面的痛苦程度基础架构团队的每一个成员都深有体会。\n伴随着升级的困难，随之而来的就是应用使用的 SDK 版本差别非常大。生产环境同时跑着各种版本的 SDK ，这种现象又会让新功能的迭代必须考虑各种兼容，时间一长就会让代码维护非常困难，有些祖传逻辑更是不敢改也不敢删。\n同时这种“重” SDK 的开发模式，导致异构语言的治理能力始终很难对标主语言，各种保障高可用的能力都无法作用于异构语言应用。\n后来有人提出了 Service Mesh 的理念，这种理念旨在把服务治理能力跟业务解耦，让两者通过进程级别的通信方式进行交互。在这种架构下，各种服务治理能力从应用中剥离，运行在独立的进程中，让业务团队跟基础架构团队可以各自进行迭代更新，大幅度提升效率。\n同时 SDK 因为功能减少而变“轻”则降低了异构语言的接入门槛，让这些语言开发的应用有机会对标主语言的治理能力。\n在看到 Service Mesh 理念的巨大潜力之后，蚂蚁集团很快就在这个方向上进行了大力投入，如上图所示，首先是使用 Go 语言自研了可以对标 envoy 的数据面。然后把 RPC 中各种治理能力下沉了到 MOSN 中，这样 RPC 的 SDK 变“轻”，而其他基础设施的 SDK 则依旧维持现状。\n在 RPC 能力完成 Mesh 化改造之后，我们进行了快速推广，如今达到了数千个应用，数十万个容器的生产规模。与此同时，全站升级频率最快可以达到 1~2 次/月，这跟传统微服务架构下 1~2 次/年的升级频率相比达到了一个质的提升。\nB、蚂蚁初步泛 Mesh 化的探索 在 RPC 能力完成 Mesh 化改造并且验证了这种架构的可行性以及体验到 Mesh 化带来的迭代效率大幅度提升的收益以后，我们正式走上了整个基础设施泛 Mesh 化改造的道路。\n如上图所示，在泛 Mesh 化改造的大趋势下，除了 RPC 以外，缓存、消息、配置等一些常用的基础设施能力迅速从应用中剥离，下沉到 MOSN 中，这套架构极大的提高了整个基础架构团队的迭代效率。\n正如软件工程没有银弹说的那样，随着泛 Mesh 化落地规模逐渐扩大，我们逐渐意识到它遗留的问题，如上图所示。\n在这种架构下，虽然应用跟基础设施之间加了一层网络代理，但对于基础设施协议部分的处理依然保留在 SDK 中，这就导致应用本质上还是要面向某个基础设施做开发，比如想使用 Redis 作为缓存实现，那么应用需要引入 Redis 的 SDK，未来如果想切换到 Memcache 等其他缓存实现，则必须对应用进行改造。\n除了替换 SDK 之外，甚至还涉及到调用 API 的调整，因此这种架构完全无法满足当前公司面临的同一个应用在多个平台部署的需求。\n与上述问题类似，泛 Mesh 化改造后，“轻” SDK 的低开发成本让各种异构语言都有机会接入到整个基础设施体系中来，享受多年基础设施建设的红利。\n但由于 SDK 里仍然保留了通信、序列化等协议的处理逻辑，因此随着接入的语言越来越多样化，这里依然存在不能忽视的开发成本。换句话说，泛 Mesh 化改造带来的“轻” SDK 跟传统微服务架构相比虽然降低了异构语言接入基础设施的门槛，但是随着接入语言越来越多样，依赖的中间件能力越来越丰富，我们还需要尝试进一步降低这种门槛。\n如果对上述两个问题做一层抽象，本质上都可以归结为应用跟基础设施之间的边界不够清晰，或者说应用中始终嵌入了某种基础设施实现中特有的处理逻辑，导致两者一直耦合在一起。\n因此如何定义应用跟基础设施之间的边界，让两者彻底解绑是我们当下必须要思考解决的问题。\nPART. 2 重新定义基础设施边界 A、如何看待 Dapr Dapr 项目由微软牵头，于 19 年下半年正式开源，作为分布式应用运行时的一种实现方案登上舞台，引起了广泛关注，它向我们展示了如何定义应用跟基础设施之间的边界。\n上图是 Dapr 官方提供的架构图，跟 Service Mesh 架构类似，Dapr 采用 Sidecar 的模型部署在应用跟基础设施之间。但与之不同的是，Dapr 基于 HTTP/gRPC 这类标准协议向应用提供了一套语义明确、面向能力的 API ，让应用可以不再关心基础设施的实现细节，只需专注业务本身依赖哪些能力即可。\n目前 Dapr 已经提供了较为丰富的 API，包括状态管理、发布订阅、服务调用等常见基础设施能力，基本能够覆盖业务日常开发的需求，并且每种能力都对应了多种具体的基础设施实现，开发者可以按需自由切换且这种切换对应用完全透明。\n除了能力之外，Dapr 官方也给出了 Dapr 跟 Service Mesh 之间的异同点，如上图所示。\n两者虽然有一些交集，但本质不同，Service Mesh 强调的是透明的网络代理，它并不关心数据本身，而 Dapr 强调的是提供能力，是真正站在应用的角度来思考如何降低应用的开发成本。\nDapr 本身的优势非常明显，不过 Service Mesh 所提供的丰富的网络治理能力，也是保障应用生产稳定性的关键点。\n与此同时 Dapr 跟基础设施的交互也无法离不开网络，因此有没有一种解决方案可以让应用运行时跟 Service Mesh 双剑合璧，降低应用开发成本的同时保留丰富的网络治理能力？\nB、Layotto：Servcie Mesh \u0026amp;amp; …","date":1638860400,"description":"云原生运行时的下一个五年","dir":"blog/the-next-five-years-of-cloud-native-runtime/","fuzzywordcount":8100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2498666960b384ded6da40a6158f9535","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","publishdate":"2021-12-07T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","summary":"文｜马振军（花名：古今 ) 在基础架构领域耕耘多年 目前在蚂蚁集团中间件团队 负责 MOSN、Layotto 等项目的开发工作 校对｜卓与、齐天 本文 9053 字 阅","tags":["SOFAStack"],"title":"云原生运行时的下一个五年","type":"blog","url":"/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/","wordcount":8008},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@xj 提问：\n 请问在 UseNetpollMode 模式下，for 循环读取链接里面的数据，那么如果遇到链接数据源源不断的情况：比如刚 readOnce 读取完毕所有数据后，再下一个循环，又有数据被写入到链接接收缓冲区里面，那么又会继续读取到。此时会损耗很多时间处理这个链接的 io 事件，影响其他链接的处理。\n A：执行久了这个协程会被 runtime 调度走哟,当然也可以多少次 read 就主动 schedule, 这个可能就要看压测数据了，配置多少合适。最开始 nginx 也是存在类似问题。\nhttps://github.com/nginx/nginx/commit/fac4c7bdf53ee7d8fec6568f1e9fecefcde6feba#diff-8f5c3450fb35200b97b96bb249ca15d6\n「MOSN」：https://github.com/mosn/mosn\n@子旦 提问：\n 请教下群里的大佬，SOFARPC 相较于 Dubbo RPC 的优势在哪？有没有相关资料，求分享～\n A：可以看下 FAQ 里面有描述。\nhttps://www.sofastack.tech/projects/sofa-rpc/faq/\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@福自奇 提问：\n 5 个 jraft 节点，一个节点挂了没及时维修，剩下四个节点两两网络分区，2|2，此时集群是不是不可用了。\n A：是，因为已经多数派不可用了（最多只有 2 个节点可用）。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@福自奇 提问：\n bolt 下面输出的日志，jraft 提供了归档或者自动删除的选项吗？现在发现 bolt 下面的日志占用内存 7g 了，是要自己写脚本定时删除吗？\n A：日志没有自动删，可以自己用脚本删。\n 这个如果没有节点异常，好像不会打？只有节点挂了才会打？\n A：bolt 日志正常都会有，如果想关掉可以看下 GitHub 上最新被 close 的 issue。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy 开发 in-memory 组件\nfail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 降本提效！注册中心在蚂蚁集团的蜕变之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1638514800,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211203/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3866acfa6aee9d270af2995d820dcb64","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211203/","publishdate":"2021-12-03T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211203/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211203/","wordcount":1289},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@洪艺辉 提问：\n 无损迁移 TCP Listener 之后，在新 MOSN 上重新 server.Serve(net.Listener)，老 MOSN 那个 Listenr 能马上死掉的 API?\n A：New MOSN 启动成功之后，就关闭老的。\n「MOSN」：https://github.com/mosn/mosn\n@大白 提问：\n MOSN 借助 FastHTTP 解析，是不是就没考虑大的请求了。这边不做处理的考虑是什么呢？\n A：MOSN 有个地方限制太大的请求，好像还可以配置来着。\n 是的，注意到有限制最大 body 大小，但是遇到一些大请求对 Sidecar 压力会很大吧。\n A：RPC 场景一般没有大包，我们有个 issue 是直接 Stream。FastHTTP 也支持流式，要适配下，有兴趣可以一起来搞搞。\nhttps://github.com/mosn/mosn/issues/1676\n「MOSN」：https://github.com/mosn/mosn\n@xj 提问：\n 咨询下 MOSN 在做 gRPC 代理的时候，如何解决代理识别客户端新增的 proto ？难道客户端多一个 proto 代理也要增加？ 还是说直接在 HTTP2.0 层面做？\n A：就是 HTTP2.0 层面，代理一般不需要识别 body。\n「MOSN」：https://github.com/mosn/mosn\n@TyCoding 提问：\n 请问 SOFARPC 不使用 SOFABoot 的话，就只能用这种方式发布服务和消费吗？那如果多个接口呢?\n A：多个接口，就多个 providerconfig 即可。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@王金鹏 提问：\n 有个问题想请教一下 SOFABoot 和 bolt 之间版本兼容的问题，SOFABoot 版本 2.3.4，bolt 原版本 1.4.2 升级到 1.5.8 会不会有兼容性的问题？\n A：最好不要这么升级，bolt 不同版本 API 可能存在差异，最好直接把 SOFABoot 版本升级上去，对应的依赖都是我们测试过的。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy 开发 in-memory 组件\nfail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python 或 C++、SDK\n开发 Spring-Boot-Laytto\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 降本提效！注册中心在蚂蚁集团的蜕变之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1637910000,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211126/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"134422b15d1bd92c49604b5b45687076","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211126/","publishdate":"2021-11-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211126/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211126/","wordcount":1331},{"author":"林育智","categories":"SOFAStack","content":" 文｜林育智（花名：源三 )\n蚂蚁集团高级专家 专注微服务/服务发现相关领域\n校对｜李旭东\n本文 8624 字 阅读 18 分钟\n｜引 言｜ 服务发现是构建分布式系统的最重要的依赖之一， 在蚂蚁集团承担该职责的是注册中心和 Antvip，其中注册中心提供机房内的服务发现能力，Antvip 提供跨机房的服务发现能力。\n本文讨论的重点是注册中心和多集群部署形态（IDC 维度），集群和集群之间不涉及到数据同步。\nPART. 1 背 景 回顾注册中心在蚂蚁集团的演进，大概起始于 2007\u0026amp;frasl;2008 年，至今演进超过 13 年。时至今日，无论是业务形态还是自身的能力都发生了巨大的变化。\n简单回顾一下注册中心的历代发展：\nV1：引进淘宝的 configserver V2：横向扩展 从这个版本开始，蚂蚁和阿里开始独立的演进，最主要的差异点是在数据存储的方向选择上。蚂蚁选择了横向扩展，数据分片存储。阿里选择了纵向扩展，加大 data 节点的内存规格。\n这个选择影响到若干年后的 SOFARegistry 和 Nacos 的存储架构。\nV3 / V4：LDC 支持和容灾 V3 支持 LDC 单元化。\nV4 增加了决策机制和运行时列表，解决了单机宕机时需要人工介入处理的问题，一定程度上提升高可用和减少运维成本。\nV5：SOFARegistry 前四个版本是 confreg，17 年启动 V5 项目 SOFARegistry，目标是：\n1.代码可维护性：confreg 代码历史包袱较重\n 少量模块使用 guice 做依赖管理，但大部分模块是静态类交互，不容易分离核心模块和扩展模块，不利于产品开源。\n 客户端与服务端的交互模型嵌套复杂，理解成本极高且对多语言不友好。\n 2.运维痛点：引入 Raft 解决 serverlist 的维护问题，整个集群的运维包括 Raft，通过 operator 来简化。\n3.鲁棒性：在一致性 hash 环增加多节点备份机制（默认 3 副本），2 副本宕机业务无感。\n4.跨集群服务发现：站内跨集群服务发现额外需要 antvip 支撑，希望可以统一 2 套设施的能力，同时商业化场景也有跨机房数据同步的需求。\n这些目标部分实现了，部分实现的还不够好，例如运维痛点还残留一部分，跨集群服务发现在面对主站的大规模数据下稳定性挑战很大。\nV6：SOFARegistry 6.0 2020 年 11 月，SOFARegistry 总结和吸收内部/商业化打磨的经验，同时为了应对未来的挑战，启动了 6.0 版本大规模重构计划。\n历时 10 个月，完成新版本的开发和升级工作，同时铺开了应用级服务发现。\nPART. 2 挑 战 当下面临的问题 集群规模的挑战 数据增长：随着业务的发展，业务的实例数在不断增长，pub/sub 的数量也相应增长。以其中一个集群为例，2019 年的数据为基准数据，在 2020 年 pub 接近千万级。 下图是该集群历年双十一时的数据对比和切换应用级的优化效果。相比 2019 年双十一，2021 年双十一接口级的 pub 增长 200%，sub 增长 80%。\n 故障爆炸半径增长：集群接入的实例越多，故障影响的业务和实例数也就越多，保障业务的稳定是最基础也是优先级最高的要求。\n 考验横向扩展能力：集群达到一定的规模后，是否还具备继续横向扩展的能力，需要集群具备良好的横向扩展能力，从 10 扩到 100 和从 100 扩到 500 是不一样的难度。\n HA 能力：集群实例数多了后，面临的节点总体的硬件故障率也相应增高，各种机器故障集群是否能快速恢复？有运维经验的同学都知道，运维一个小集群和运维一个大集群面临的困难简直是指数级增长。\n 推送性能：大多数服务发现的产品都选择了数据的最终一致性，但是这个最终在不同集群的规模下到底是多久？相关的产品其实都没有给出明确的数据。\n 但是实际上，我们认为这个指标是服务发现产品的核心指标。这个时长对调用有影响：新加的地址没有流量；删除的地址没有及时摘除等。蚂蚁集团的 PaaS 对注册中心的推送时延是有 SLO 约束的：如果变更推送列表延时超过约定值，业务端的地址列表就是错误的。我们历史上也曾发生过因推送不及时导致的故障。\n业务实例规模增加的同时也带来推送的性能压力：发布端 pub 下面的实例数增加；订阅端业务实例数增加；一个简单的估算，pub/sub 增长 2 倍，推送的数据量是 2*2，增长 4 倍，是一个乘积的关系。同时推送的性能也决定了同一时间可以支持的最大运维业务实例数，例如应急场景下，业务大规模重启。如果这个是瓶颈，就会影响故障的恢复时间。\n集群规模可以认为是最有挑战性的，核心的架构决定了它的上限，确定后改造成本非常高。而且往往等到发现瓶颈的时候已经是兵临城下了，我们要选择能拉高产品技术天花板的架构。\n运维的挑战 SOFARegistryX 立项时的一个主要目标是具备比 confreg 更好的运维能力：引入 meta 角色，通过 Raft 选举和存储元信息，提供集群的控制面能力。但是事实证明，我们还是低估了可运维的重要性，正如鲁迅先生说：【程序员的工作只有两件事情，一件是运维，另一件还是运维】。\n三年前的目标放到今天已经严重滞后了。\n 集群数增长：蚂蚁集团内部的业务是分站点部署的（简单理解为每个站点是一块相对比较独立的业务，需要不同级别的隔离），同时一个站点需要部署多套集群：容灾需要分机房部署；开发需要分多环境。部署站点的数目增长超出我们的想像。现在已经达到数百个集群了，还在迅速增长中，增长速度参考最近几年美联储的货币供应量增长速度。以前认为有些运维工作可以苟且，人肉顶一下，集群数增长后，苟且次数太多了，挤占了开发/运维同学的精力，完全没资源去规划诗和远方。 业务打扰：业务的运维是全天候 7*24 的，容量自适应/自愈/MOSN 每月一版本把全站应用犁一遍等等。下图是每分钟运维的机器批数，可以看到，就算是周末和深夜，运维任务也是不断的。 蚂蚁集团的同学对注册中心的运维公告应该是比较熟悉和痛恨的。因为业务的敏感性，注册中心之前一直是停机发布和运维，这个时候需要锁定全站的发布/重启动作。为了尽量少影响业务，注册中心相关的同学只能献祭一头黑发，在深夜低峰期做相关的操作。即使这样，仍然没办法做到对业务零打扰。\n云原生时代 naming 的挑战 云原生的技术时代下，可以观察到一些趋势：\n 微服务/FaaS 的推广导致轻型应用增多：实例数增多，需要能支撑更大的业务规模\n 应用实例的生命周期更短：FaaS 按需使用，autoscale 容量自适应等手段导致实例的涨潮退潮更频繁，注册中心的性能主要体现在实例变更的响应速度上\n 多语言支持：在过去，蚂蚁集团主要的开发体系是 Java，非 Java 语言对接基础设施都是二等公民，随着 AI 和创新性业务的需求，非 Java 体系的场景越来越多。如果按照每种语言一个 SDK，维护成本会是个噩梦，当然 sidecar（MOSN）是个解法，但是自身是否能支持低侵入性的接入方式，甚至 sdk-free 的能力？\n 服务路由：在过去绝大部分的场景都可以认为 endpoint 是平等的，注册中心只提 …","date":1637650800,"description":"降本提效！注册中心在蚂蚁集团的蜕变之路","dir":"blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","fuzzywordcount":7800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f75ce63f7162ca26342a52f74ce577ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","publishdate":"2021-11-23T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","summary":"文｜林育智（花名：源三 ) 蚂蚁集团高级专家 专注微服务/服务发现相关领域 校对｜李旭东 本文 8624 字 阅读 18 分钟 ｜引 言｜ 服务发现是构建分布式系统的最重要的","tags":["SOFAStack"],"title":"降本提效！注册中心在蚂蚁集团的蜕变之路","type":"blog","url":"/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/","wordcount":7736},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@黄润良 提问：\n 有什么办法可以获取日志的这两个值吗？\n A：可以参考下图\n MOSN：https://github.com/mosn/mosn\n@爱德华 提问：\n 请教一下，SOFAJRaft 在 leader 晋升后，给每个 follower 发送的探测请求是什么？是 Raft 论文中，为了“提交上一个 term 日志项”，才发送的空请求吗？\n A：是为了探测该 follower 与 leader 的日志差异。找对 nextIndex 对吧？提交上一个 term 要通过 noop 日志。Raft 论文里有个 nextIndex，你可以看看相关内容， 日志复制那个小节。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@Bazingga 提问：\n 源码里面是怎么支持的呀，RheaKV 是使用了这个功能是吧。\n A：可以参考下这个 https://blog.csdn.net/SOFAStack/article/details/91458041\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@爱德华 提问：\n 我请教一下关于 follower 截断日志的问题。leader 拥有日志：101,102,103，它们的 term 为 2；follower 拥有日志：101,102,103,104，它们的 term 为 2；按照正常逻辑，follower 应该截断 104 的日志。根据上面的代码，在探测消息中，这种情况，follower 会返回了 success=true，并携带 lastLogIndex=104。那么 follower 是在什么时候截断 104 的呢？\n A：checkAndResolveConflict 方法。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 在服务注册时，使用枚举值替代字符串硬编码\n优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n开发 spring-boot-laytto\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 rometheus on CeresDB 演进之路\n 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n ","date":1637305200,"description":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211119/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"05f1b91614900f1434b7748905df364b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211119/","publishdate":"2021-11-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211119/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211119/","wordcount":1249},{"author":"刘家财","categories":"SOFAStack","content":" 文｜刘家财（花名：尘香 )\n蚂蚁集团高级开发工程师 专注时序存储领域\n校对｜冯家纯\n本文 7035 字 阅读 10 分钟\nCeresDB 在早期设计时的目标之一就是对接开源协议，目前系统已经支持 OpenTSDB 与 Prometheus 两种协议。Prometheus 协议相比 OpenTSDB 来说，非常灵活性，类似于时序领域的 SQL。\n随着内部使用场景的增加，查询性能、服务稳定性逐渐暴露出一些问题，这篇文章就来回顾一下 CeresDB 在改善 PromQL 查询引擎方面做的一些工作，希望能起到抛砖引玉的作用，不足之处请指出。\nPART. 1 内存控制 对于一个查询引擎来说，大部分情况下性能的瓶颈在 IO 上。为了解决 IO 问题，一般会把数据缓存在内存中，对于 CeresDB 来说，主要包括以下几部分：\n MTSDB：按数据时间维度缓存数据，相应的也是按时间范围进行淘汰\n Column Cache：按时间线维度缓存数据，当内存使用达到指定阈值时，按时间线访问的 LRU 进行淘汰\n Index Cache：按照访问频率做 LRU 淘汰\n 上面这几个部分，内存使用相对来说比较固定，影响内存波动最大的是查询的中间结果。如果控制不好，服务很容易触发 OOM 。\n中间结果的大小可以用两个维度来衡量：横向的时间线和纵向的时间线。\n控制中间结果最简单的方式是限制这两个维度的大小，在构建查询计划时直接拒绝掉，但会影响用户体验。比如在 SLO 场景中，会对指标求月的统计数据，对应的 PromQL 一般类似 sum_over_time(success_reqs[30d]) ，如果不能支持月范围查询，就需要业务层去适配。\n要解决这个问题需要先了解 CeresDB 中数据组织与查询方式，对于一条时间线中的数据，按照三十分钟一个压缩块存放。查询引擎采用了向量化的火山模型，在不同任务间 next 调用时，数据按三十分钟一个批次进行传递。\n在进行上述的 sum_over_time 函数执行时，会先把三十天的数据依次查出来，之后进行解压，再做一个求和操作，这种方式会导致内存使用量随查询区间线性增长。如果能去掉这个线性关系，那么查询数量即使翻倍，内存使用也不会受到太大影响。\n为了达到这个目的，可以针对具备累加性的函数操作，比如 sum/max/min/count 等函数实现流式计算，即每一个压缩块解压后，立即进行函数求值，中间结果用一个临时变量保存起来，在所有数据块计算完成后返回结果。采用这种方式后，之前 GB 级别的中间结果，最终可能只有几 KB。\nPART. 2 函数下推 不同于单机版本的 Prometheus ，CeresDB 是采用 share-nothing 的分布式架构，集群中有主要有三个角色：\n datanode：存储具体 metric 数据，一般会被分配若干分片(sharding)，有状态\n proxy：写入/查询路由，无状态\n meta：存储分片、租户等信息，有状态。\n 一个 PromQL 查询的大概执行流程：\n1.proxy 首先把一个 PromQL 查询语句解析成语法树，同时根据 meta 中的分片信息查出涉及到的 datanode\n2.通过 RPC 把语法树中可以下推执行的节点发送给 datanode\n3.proxy 接受所有 datanode 的返回值，执行语法树中不可下推的计算节点，最终结果返回给客户端\nsum(rate(write_duration_sum[5m])) / sum(rate(write_duration_count[5m])) 的执行示意图如下：\n为了尽可能减少 proxy 与 datanode 之间的 IO 传输，CeresDB 会尽量把语法树中的节点推到 datanode 层中，比如对于查询 sum(rate(http_requests[3m])) ，理想的效果是把 sum、rate 这两个函数都推到 datanode 中执行，这样返回给 proxy 的数据会极大减少，这与传统关系型数据库中的“下推选择”思路是一致的，即减少运算涉及的数据量。\n按照 PromQL 中涉及到的分片数，可以将下推优化分为两类：单分片下推与多分片下推。\n单分片下推 对于单分片来说，数据存在于一台机器中，所以只需把 Prometheus 中的函数在 datanode 层实现后，即可进行下推。这里重点介绍一下 subquery【1】 的下推支持，因为它的下推有别于一般函数，其他不了解其用法的读者可以参考 Subquery Support【2】。\nsubquery 和 query_range【3】 接口（也称为区间查询）类似，主要有 start/end/step 三个参数，表示查询的区间以及数据的步长。对于 instant 查询来说，其 time 参数就是 subquery 中的 end ，没有什么争议，但是对于区间查询来说，它本身也有 start/end/step 这三个参数，怎么和 subquery 中的参数对应呢？\n假设有一个步长为 10s 、查询区间为 1h 的区间查询，查询语句是\n那么对于每一步，都需要计算 3600\u0026amp;frasl;10=360 个数据点，按照一个小时的区间来算，总共会涉及到 360*360=129600 的点，但是由于 subquery 和区间查询的步长一致，所以有一部分点是可以复用的，真正涉及到的点仅为 720 个，即 2h 对应 subquery 的数据量。\n可以看到，对于步长不一致的情况，涉及到的数据会非常大，Prometheus 在 2.3.0 版本后做了个改进，当 subquery 的步长不能整除区间查询的步长时，忽略区间查询的步长，直接复用 subquery 的结果。这里举例分析一下：\n假设区间查询 start 为 t=100，step 为 3s，subquery 的区间是 20s，步长是 5s，对于区间查询，正常来说：\n1.第一步\n需要 t=80, 85, 90, 95, 100 这五个时刻的点\n2.第二步\n需要 t=83, 88, 83, 98, 103 这五个时刻的点\n可以看到每一步都需要错开的点，但是如果忽略区间查询的步长，先计算 subquery ，之后再把 subquery 的结果作为 range vector 传给上一层，区间查询的每一步看到的点都是 t=80, 85, 90, 95, 100, 105…，这样就又和步长一致的逻辑相同了。此外，这么处理后，subquery 和其他的返回 range vector 的函数没有什么区别，在下推时，只需要把它封装为一个 call （即函数）节点来处理，只不过这个 call 节点没有具体的计算，只是重新根据步长来组织数据而已。\ncall: avg_over_time step:3 └─ call: subquery step:5 └─ binary: == ├─ selector: a_gauge └─ literal: 2 在上线该优化前，带有 subquery 的查询无法下推，这样不仅耗时长，而且还会生产大量中间结果，内存波动较大；上线该功能后，不仅有利于内存控制， …","date":1637046000,"description":"Prometheus on CeresDB 演进之路","dir":"blog/prometheus-on-ceresdb-evolutionary-path/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c56a0b61329eb6462295f7bfb16ee6b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","publishdate":"2021-11-16T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","summary":"文｜刘家财（花名：尘香 ) 蚂蚁集团高级开发工程师 专注时序存储领域 校对｜冯家纯 本文 7035 字 阅读 10 分钟 CeresDB 在早期设计时的目标之一就是对接开源协议，目前系","tags":["SOFAStack"],"title":"Prometheus on CeresDB 演进之路","type":"blog","url":"/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/","wordcount":4807},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFA\u0026amp;amp;MOSN 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@zjw 提问：\n 请教个 SOFARegistry 的问题，sessionServer 启动后，地址是上报给 Meta 的吗？如果 sessionServer 意外关闭，地址是什么时候怎么摘除的？\n A：session 会定时向 Meta 发送请求对自己的地址进行心跳续约，session 宕机后，Meta 端一段时间接收不到心跳就会摘除宕机的 session，然后广播给所有其他的 session。目前是靠心跳，超时之后 Meta 会把 session 或者 data 剔除。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\n@滕川 提问：\n 如果 leader 节点挂了，新选举的 leader 节点如何知道各个 follower 节点的 match index。\n A：leader 不需要知道，leader 节点就直接发 appendEtries 即可。如果哪个 follower 还缺更之前的 log，那么它拒绝掉这次 appendEntries 就可以了， leader 会有相应的回退处理逻辑。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@橙橙不是澄澄 提问：\n Raft 里面为什么不要 observer 呢？恰好之前看到 ZooKeeper 里面有这个角色。\n A：Raft 里面可以有类似的角色，叫 learner。learner 不参与选举，只接收 leader 日志，JRaft 也支持 learner。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\n@邓君武 提问：\n SOFAJRaft 文档中说支持 MULTI-RAFT-GROUP，目前 SOFAJRaft-RheaKV 这个存储组件中用到了。那么如果我想根据 SOFAJRaft 实现一个分布式的业务系统，MULTI-RAFT-GROUP 该怎么用呢？\n A：MULTI-RAFT-GROUP 主要用于解决 SIGLE-RAFT-GROUP 单点瓶颈问题（存储或是吞吐），多个 group 中每个 group 都有一个 leader，可以把 leader 打散到不同的机器上，提高并发度。JRaft 天然支持 MULTI-RAFT-GROUP ，使用的话可以参考 RheaKV。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nSOFARPC\n Easy 在服务引用和发布时，使用枚举值替代字符串硬编码\n优化集成 Nacos、ZK 注册中心的文档\n Medium 让用户使用@SOFAService 后不需要再写@Component\n优化 SOFARPC 的异步编程体验\n Hard JFR 埋点\n「详细参考」：https://github.com/sofastack/sofa-rpc/issues/1127\nLayotto\n Easy fail fast，让 Layotto 启动报错时自杀\n为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n升级由 Rust 开发的 Wasm demo\n Hard 集成 Jaeger 等 tracing 系统\n支持 Dapr Config API\n「详细参考」：https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 如何在生产环境排查 Rust 内存占用过高问题\n 新一代日志型系统在 SOFAJRaft 中的应用\n 终于！SOFATracer 完成了它的链路可视化之旅\n 蚂蚁集团技术风险代码化平台实践（MaaS）\n ","date":1636700400,"description":"SOFA WEEKLY | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","dir":"blog/sofa-weekly-20211112/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"801d338b492a06363ed6a129c2da9774","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211112/","publishdate":"2021-11-12T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211112/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA Weekly | 社区本周 Contributor、QA 整理、新手任务计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211112/","wordcount":1544},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft\n 活动时间：11月10日,周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft SOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 冯家纯 蚂蚁集团高级技术专家。 蚂蚁集团-智能监控-技术中台（存储）团队技术负责人，团队负责时序数据库相关。 分布式服务框架 Jupiter 作者。 基于 Raft 的分布式共识算法库 SOFAJRaft 开源负责人、核心开发者。 议程 18:50-19:00 主持人开场 小助手-泡椒 主持人\n19:00-19:30 分布式共识：Raft 与 SOFAJRaft 冯家纯，蚂蚁集团高级技术专家\n你将收获 对 Raft 共识算法有所了解，还可以了解到 SOFAJRaft 基于 Raft 算法做了哪些优化，以及实现 Raft 算法的一些好的实践经验。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1636527600,"description":"11 月 10 日周三晚 19 点，线上直播第 22 期。","dir":"activities/sofa-channel-22/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"896e421f2df319f46ec573a77343446c","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-22/","publishdate":"2021-11-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-22/","summary":"概要 活动主题：SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft 活动时间：11月10日,周三晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站","tags":["SOFAChannel","HTTP/3"],"title":"SOFAChannel#22：分布式共识：Raft 与 SOFAJRaft","type":"activities","url":"/sofastack.tech/activities/sofa-channel-22/","wordcount":643},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@玄灭 提问：\n 大佬，关于 downStream 和 upStream，你看看我这个理解对不对哈？一个 MOSN 进程，既会代理当前 pod 的业务进程流量请求，此时 downStream 是当前 pod 进程；同时，这个 MOSN 进程也会代理其他 pod 请求当前 pod 的流量，此时当前 pod 就不能成为 downStream；也就是说，角色会互换。从另一个角度，从 server 端口进来的，都是 downStream，使用 client 向外其他进程发送数据，都是 upStream。 A：一般来说，downStream 就是 server listen 请求，upStream 是 client，发送请求。你说的第一种，一般用 Ingress、Egress 来区分。\n 在 MOSN 里，downStream 永远是 side 进程吗？\n A：MOSN 里面，downStream 就是 server 端，接收请求的。\n MOSN 两个端口的话，server 端可能是 side 进程，也可能是其他 MOSN 进程。所以 downStream 可以是 side 进程的请求，也可以是其他 MOSN 进程的请求。\n A：站在 MOSN 角度，给我发请求的就是 downStream。\n「MOSN」：https://github.com/mosn/mosn\n@zzzZ 提问：\n 怎么将实现的 Eventhandler 注册进容器中，监听容器启动和停止事件？\n A：这里有具体讲解，https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/\n 事件能传播吗？比如 master 传播给子模块内。 A：容器级别的会传播。\n 「SOFABoot」：https://github.com/sofastack/sofa-boot\n@苏千 提问：\n 如何让 Layotto 打印日志，将 metadata 打印出来，我传递了没有生效，想看看是否传递错误。\n A：Layotto 现在默认 log 就是打印的，但没打印 metadata 里面的值，现在 oss 的实现就没传 prefix，所以不生效吧。\n可以试一下这个方法，如果这样的话，你 SDK 测需要适配一下。https://github.com/mosn/layotto/issues/98#issuecomment-957479097\n「Layotto」：https://github.com/mosn/layotto\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n升级由 Rust 开发的 Wasm demo\n Hard 集成 Skywalking、Jaeger 等系统\n支持 Dapr Config API\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 如何在生产环境排查 Rust 内存占用过高问题\n 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1636095600,"description":"SOFA Weekly |Layotto 本周 Contributor、QA 整理、新手任务","dir":"blog/sofa-weekly-20211105/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f2607e9479571a83a8453798866de8f9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211105/","publishdate":"2021-11-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211105/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly |Layotto 本周 Contributor、QA 整理、新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211105/","wordcount":1382},{"author":"魏熙凯","categories":"SOFAStack","content":" 📄\n文｜魏熙凯（蚂蚁集团技术专家）\n本文 6320 字 阅读 10 分钟\n▼\n内存安全的 Rust，虽然基本不会出现内存泄漏，但如何合理分配内存，是每个复杂应用都要面临的问题。往往随着业务的不同，相同的代码可能会产生不同的内存占用。因此，有不小的概率会出现内存使用过多、内存逐渐增长不释放的问题。\n本文我想分享一下，我们在实践过程中遇到的关于内存占用过高的问题。对于这些内存问题，在本文中会做出简单的分类，以及提供我们在生产环境下进行排查定位的方法给大家参考。\n 本文最先发表于 RustMagazine 中文月刊\n(https://rustmagazine.github.io/rust_magazine_2021/chapter_5/rust-memory-troubleshootting.html）\n 内存分配器 首先在生产环境中，我们往往不会选择默认的内存分配器（malloc），而是会选择 jemalloc，可以提供更好的多核性能以及更好的避免内存碎片（详细原因可以参考[1]）。Rust 的生态中，对于 jemalloc 的封装有很多优秀的库，这里我们就不纠结于哪一个库更好，我们更关心如何使用 jemalloc 提供的分析能力，帮助我们诊断内存问题。\n阅读 jemalloc 的使用文档，可以知道其提供了基于采样方式的内存 profile 能力，而且可以通过 mallctl 可以设置 prof.active 和 prof.dump 这两个选项，来达到动态控制内存 profile 的开关和输出内存 profile 信息的效果。\n内存快速增长直至 oom 这样的情况一般是相同的代码在面对不同的业务场景时会出现，因为某种特定的输入（往往是大量的数据）引起程序的内存快速增长。\n不过有了上面提到的 memory profiling 功能，快速的内存增长其实一个非常容易解决的情况，为我们可以在快速增长的过程中打开 profile 开关，一段时间后，输出 profile 结果，通过相应的工具进行可视化，就可以清楚地了解到哪些函数被调用，进行了哪些结构的内存分配。\n不过这里分为两种情况：可以复现以及难以复现，对于两种情况的处理手段是不一样的，下面对于这两种情况分别给出可操作的方案。\n**可以复现\n可以复现的场景其实是最容易的解决的问题，因为我们可以在复现期间采用动态打开 profile，在短时间内的获得大量的内存分配信息即可。\n下面给出一个完整的 demo，展示一下在 Rust 应用中如何进行动态的内存 profile。\n本文章，我会采用jemalloc-sys jemallocator jemalloc-ctl 这三个 Rust 库来进行内存的 profile，这三个库的功能主要是：\n```jemallocator```: 实现了 Rust 的 ```GlobalAlloc```，用来替换默认的内存分配器。 ```jemalloc-ctl```: 提供了对于 mallctl 的封装，可以用来进行 tuning、动态配置分配器的配置、以及获取分配器的统计信息等。 下面是 demo 工程的依赖： ``` java [dependencies] jemallocator = \u0026amp;quot;0.3.2\u0026amp;quot; jemalloc-ctl = \u0026amp;quot;0.3.2\u0026amp;quot; [dependencies.jemalloc-sys] version = \u0026amp;quot;0.3.2\u0026amp;quot; features = [\u0026amp;quot;stats\u0026amp;quot;, \u0026amp;quot;profiling\u0026amp;quot;, \u0026amp;quot;unprefixed_malloc_on_supported_platforms\u0026amp;quot;] [profile.release] debug = true 其中比较关键的是jemalloc-sys 的几个 features 需要打开，否则后续的 profile 会遇到失败的情况，另外需要强调的是 demo 的运行环境是在 Linux 环境下运行的。\n然后 demo 的 src/main.rs 的代码如下：\nuse jemallocator; use jemalloc_ctl::{AsName, Access}; use std::collections::HashMap; #[global_allocator] static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc; const PROF_ACTIVE: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;prof.active\\0\u0026amp;quot;; const PROF_DUMP: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;prof.dump\\0\u0026amp;quot;; const PROFILE_OUTPUT: \u0026amp;amp;\u0026#39;static [u8] = b\u0026amp;quot;profile.out\\0\u0026amp;quot;; fn set_prof_active(active: bool) { let name = PROF_ACTIVE.name(); name.write(active).expect(\u0026amp;quot;Should succeed to set prof\u0026amp;quot;); } fn dump_profile() { let name = PROF_DUMP.name(); name.write(PROFILE_OUTPUT).expect(\u0026amp;quot;Should succeed to dump profile\u0026amp;quot;) } fn main() { set_prof_active(true); let mut buffers: Vec\u0026amp;lt;HashMap\u0026amp;lt;i32, i32\u0026amp;gt;\u0026amp;gt; = Vec::new(); for _ in 0..100 { buffers.push(HashMap::with_capacity(1024)); } set_prof_active(false); dump_profile(); } demo 已经是非常简化的测试用例了，主要做如下的说明：\n编译完成之后，直接运行程序是不行的，需要设置好环境变量（开启内存 profile 功能）： export MALLOC_CONF=prof:true 然后再运行程序，就会输出一份 memory profile 文件，demo 中文件名字已经写死 —— ```profile.out```，这个是一份文本文件，不利于直接观察（没有直观的 symbol）。 通过 jeprof 等工具，可以直接将其转化成可视化的图形： ```jeprof --show_bytes --pdf \u0026amp;lt;path_to_binary\u0026amp;gt; ./profile.out \u0026amp;gt; ./profile.pdf``` 这样就可以将其可视化，从下图中，我们可以清晰地看到所有的内存来源： …","date":1635836400,"description":"如何在生产环境排查 Rust 内存占用过高问题","dir":"blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a2811b69df2016f531d4d42a431a7683","permalink":"https://sofastack.github.io/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","publishdate":"2021-11-02T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","summary":"📄 文｜魏熙凯（蚂蚁集团技术专家） 本文 6320 字 阅读 10 分钟 ▼ 内存安全的 Rust，虽然基本不会出现内存泄漏，但如何合理分配内存，是每个复杂应用都要面临","tags":["SOFAStack"],"title":"如何在生产环境排查 Rust 内存占用过高问题","type":"blog","url":"/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/","wordcount":3930},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1.@崔伟协 提问：\n PingPong 是类似 HTTP 的 req/resp 吗? Multiplex 是类似 HTTP2.0 的没有队头阻塞吗？ A：是的。\n 自己实现的 xprotocol 自定义子协议，要怎么配置 downstream 是 PingPong 还是 Multiplex 呢，PoolMode() api.PoolMode 这个方法似乎只影响 upstream 的 conn pool?\n A：downstream 不用感知，这个访问你的 client 就决定他的行为。\n「MOSN」：https://github.com/mosn/mosn\n2.@玄灭 提问：\n 请教下 MOSN 可以同时支持多个协议吗？比如同时支持 HTTP1.1、rocketmq 协议。\n A：可以的，一个端口都可以。协议可以做自动识别，协议配置就可以配置 Auto。\n「MOSN」：https://github.com/mosn/mosn\n3.@玄灭 提问：\n 业务层的 SDK 用的什么协议呢？比如 mq 用的是私有协议，还是和 RPC 统一是一个协议啊？\n A：我们两种模式，一种是私有协议，一种是统一协议都有再用，统一协议是用 Layotto 支持的。\n 你们的大方向是统一协议，还是私有协议啊？我理解的私有协议对于上游改造成本，会比较小吧；统一协议的话，成本比较大。\n A：私有协议你认为是 Mesh 了，现有业务的支持；统一协议就是类似 Dapr 这种，新业务使用不同场景。\n「MOSN」：https://github.com/mosn/mosn\n4.@晓辰 提问：\n 请问一下 MOSN 有支持 windows 的计划吗？\n A：Go 语言跨平台应该支持的，你提个 pr 看看，是不是有些 Linux 需要跳过？\n「MOSN」：https://github.com/mosn/mosn\n5.@王磊 提问：\n MOSN 目前支持的 Istio 版本是 1.5.2 吗？更高的 Istio 版本支持有计划吗？\n A：这个分支，近期会合到 Master。\nhttps://github.com/mosn/mosn/tree/istio-1.10\n「MOSN」：https://github.com/mosn/mosn\n6.@孙力 提问：\n MOSN 有剔除上游故障节点的功能吗? 比如上游服务有 5 台服务器，访问其中一台总报错，下次就不选这台了。\n https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ffaulttolerance\n 这个 stream_filter 应该是只要上游 host 返回的状态码代表异常就会统计，达到一定比例就会 healthFlag 置为 false。但我们其实想做接口 + host 的，比如访问上游的某个 HTTP 接口总失败，只是针对下次访问这个接口时，才剔除节点，这样是不是需要自己定制一下 InvocationKey ？\n A：还是有区别的，这个是把 host 置为失败了，是全局的，其他接口也会失败。删除了之后，其他访问这个接口请求也不会访问这个 host 了。\n「MOSN」：https://github.com/mosn/mosn\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 Java SDK 新增分布式锁 API\n为 Java SDK 新增分布式自增 ID API\n Medium 开发 Python SDK\n用某种存储实现 File API 组件（例如本地文件系统、hdfs、ftp 等）\n升级由 rust 开发的 wasm demo\nSOFARPC 本周发布 本周 SOFARPC 发布 v5.8.0 版本代码。\n主要更新如下：\n RpcInvokeContext 中增加调用时精细化耗时埋点信息\n Java 集合的使用优化\n 修复 RouterChain 加入不存在的 Router 时 NPE 问题\n 增加泛型修复配置类中类型传递问题\n bolt 版本从 1.5.6 升级到 1.5.9\n hessian 版本从 3.3.7 升级到 3.3.13\n nacos 版本从 1.0.0 升级到 2.0.3\n httpclient 版本从 4.5.11 升级到 4.5.13\n commons-io 版本从 2.4 升级到 2.7\n 「详细参考」：https://github.com/sofastack/sofa-rpc/releases/tag/v5.8.0\n本周推荐阅读 蚂蚁集团技术风险代码化平台实践（MaaS）\n 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1635490800,"description":"SOFA WEEKLY |Layotto 本周 Contributor、QA 整理、 SOFARPC 本周发布","dir":"blog/sofa-weekly-20211029/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dc10182aab6b4170339c958ac73dd2bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211029/","publishdate":"2021-10-29T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211029/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、 SOFARPC 本周发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211029/","wordcount":1667},{"author":"黄章衡","categories":"SOFAStack","content":" 📄\n文｜黄章衡（SOFAJRaft 项目组）\n福州大学 19 级计算机系\n研究方向｜分布式中间件、分布式数据库\nGithub 主页｜https://github.com/hzh0425\n校对｜冯家纯（SOFAJRaft 开源社区负责人）\n本文 9402 字 阅读 18 分钟\n▼\nPART. 1 项目介绍 1.1 SOFAJRaft 介绍 SOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\nGithub 地址：\nhttps://github.com/sofastack/sofa-jraft\n1.2 任务要求 目标：当前 LogStorage 的实现，采用 index 与 data 分离的设计，我们将 key 和 value 的 offset 作为索引写入 rocksdb，同时日志条目（data）写入 Segment Log。因为使用 SOFAJRaft 的用户经常也使用了不同版本的 rocksdb，这就要求用户不得不更换自己的 rocksdb 版本来适应 SOFAJRaft， 所以我们希望做一个改进：移除对 rocksdb 的依赖，构建出一个纯 Java 实现的索引模块。\nPART. 2 前置知识 Log Structured File Systems\n如果学习过类似 Kafka 等消息队列的同学，对日志型系统应该并不陌生。\n如图所示，我们可以在单机磁盘上存储一些日志型文件，这些文件中一般包含了旧文件和新文件的集合。区别在于 Active Data File 一般是映射到内存中的并且正在写入的新文件(基于 mmap 内存映射技术)，而 Older Data File 是已经写完了，并且都 Flush 到磁盘上的旧文件，当一块 Active File 写完之后，就会将其关闭，并打开一个新的 Active File 继续写。\n并且每一次的写入，每个 Log Entry 都会被 Append 到 Active File 的尾部，而 Active File 往往会用 mmap 内存映射技术，将文件映射到 os Page Cache 里，因此每一次的写入都是内存顺序写，性能非常高。\n终上所述，一块 File 无非就是一些 Log Entry 的集合，如图所示:\n同时，仅仅将日志写入到 File 中还不够，因为当需要搜索日志的时候，我们不可能顺序遍历每一块文件去搜索，这样性能就太差了。所以我们还需要构建这些文件的 “目录”，也即索引文件。这里的索引本质上也是一些文件的集合，其存储的索引项一般是固定大小的，并提供了 LogEntry 的元信息，如:\n- File_Id : 其对应的 LogEntry 存储在哪一块 File 中\n- Value_sz : LogEntry 的数据大小\n(注: LogEntry 是被序列化后, 以二进制的方式存储的)\n- Value_pos: 存储在对应 File 中的哪个位置开始\n- 其他的可能还有 crc，时间戳等\u0026amp;hellip;\u0026amp;hellip;\n那么依据索引文件的特性，就能够非常方便的查找 IndexEntry。\n- 日志项 IndexEntry 是固定大小的\n- IndexEntry 存储了 LogEntry 的元信息\n- IndexEntry 具有单调递增的特性\n举例，如果要查找 LogIndex = 4 的日志:\n- 第一步，根据 LogIndex = 4，可以知道索引存储的位置：IndexPos = IndexEntrySize * 4\n- 第二步，根据 IndexPos，去索引文件中，取出对应的索引项 IndexEntry\n- 第三步，根据 IndexEntry 中的元信息，如 File_Id、Pos 等，到对应的 Data File 中搜索\n- 第四步，找到对应的 LogEntry\n内存映射技术 mmap\n上文一直提到了一个技术：将文件映射到内存中，在内存中写 Active 文件，这也是日志型系统的一个关键技术，在 Unix/Linux 系统下读写文件，一般有两种方式。\n传统文件 IO 模型\n一种标准的 IO 流程, 是 Open 一个文件，然后使用 Read 系统调用读取文件的一部分或全部。这个 Read 过程是这样的：内核将文件中的数据从磁盘区域读取到内核页高速缓冲区，再从内核的高速缓冲区读取到用户进程的地址空间。这里就涉及到了数据的两次拷贝：磁盘-\u0026amp;gt;内核，内核-\u0026amp;gt;用户态。\n而且当存在多个进程同时读取同一个文件时，每一个进程中的地址空间都会保存一份副本，这样肯定不是最优方式的，造成了物理内存的浪费，看下图：\n内存映射技术\n第二种方式就是使用内存映射的方式\n具体操作方式是：Open 一个文件，然后调用 mmap 系统调用，将文件内容的全部或一部分直接映射到进程的地址空间(直接将用户进程私有地址空间中的一块区域与文件对象建立映射关系)，映射完成后，进程可以像访问普通内存一样做其他的操作，比如 memcpy 等等。mmap 并不会预先分配物理地址空间，它只是占有进程的虚拟地址空间。\n当第一个进程访问内核中的缓冲区时，因为并没有实际拷贝数据，这时 MMU 在地址映射表中是无法找到与地址空间相对应的物理地址的，也就是 MMU 失败，就会触发缺页中断。内核将文件的这一页数据读入到内核高速缓冲区中，并更新进程的页表，使页表指向内核缓冲中 Page Cache 的这一页。之后有其他的进程再次访问这一页的时候，该页已经在内存中了，内核只需要将进程的页表登记并且指向内核的页高速缓冲区即可，如下图所示：\n对于容量较大的文件来说（文件大小一般需要限制在 1.5~2G 以下），采用 mmap 的方式其读/写的效率和性能都非常高。\n当然，需要如果采用了 mmap 内存映射，此时调用 Write 并不是写入磁盘，而是写入 Page Cache 里。因此，如果想让写入的数据保存到硬盘上，我们还需要考虑在什么时间点 Flush 最合适(后文会讲述)。\nPART. 3 架构设计 3.1 SOFAJRaft 原有日志系统架构 下图是 SOFAJRaft 原有日志系统整体上的设计：\n其中 LogManager 提供了和日志相关的接口，如:\n/** * Append log entry vector and wait until it\u0026#39;s stable (NOT COMMITTED!) * * @param entries log entries * @param done callback */ void appendEntries(final Listentries, StableClosure done); /** * Get the log entry at index. * * @param index the index of log entry * @return the …","date":1635231600,"description":"新一代日志型系统在 SOFAJRaft 中的应用","dir":"blog/a-new-generation-of-log-based-systems-in-sofajraft/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0d3a13e7ed41a72bee7fe7973424e4e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","publishdate":"2021-10-26T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","summary":"📄 文｜黄章衡（SOFAJRaft 项目组） 福州大学 19 级计算机系 研究方向｜分布式中间件、分布式数据库 Github 主页｜https://github.com","tags":["SOFAStack"],"title":"新一代日志型系统在 SOFAJRaft 中的应用","type":"blog","url":"/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/","wordcount":5282},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）\n 活动时间：2021 年 10 月 23 日（周六）13:30-17:30\n 活动地点：上海市浦东新区南泉北路 447 号蚂蚁 S 空间 1210 明月台\n 活动形式：线下活动\n 资料下载： 《攀登规模化的高峰蚂蚁集团大规模 Sigma 集 ApiServer 优化实践》\n 活动回顾 《攀登规模化的高峰蚂蚁集团大规模 Sigma 集 ApiServer 优化实践》\n嘉宾介绍\n唐博：蚂蚁集团技术专家，目前主要致力于 Kubernetes 性能和规模化方向，在资源编排调度，以及机器学习平台等领域有所涉猎，是 Kubernetes/istio/volcano 等云原生相关项目的代码贡献者。\n谭崇康：蚂蚁集团高级技术专家，负责大规模 K8s 集群设计、集群性能及 Pod 交付成功率及吞吐保障。长期从事云平台领域的新架构研发工作，研究兴趣包括 Kubernetes 领域的最新技术、操作系统、大数据、AIOps 等。\n议题简介\n 蚂蚁集团运行着全球最大的 Kubernetes（内部称为 Sigma） 集群之一，本次分享将介绍蚂蚁集团构建万级节点的大规模 Kubernetes 集群以及优化 Kubernetes apiserver 的过程当中的挑战和解决方案. 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1634972400,"description":"【活动回顾】SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）","dir":"activities/sofa-meetup-12/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"590a0e1f5b8a6a4035844058f4361490","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-12/","publishdate":"2021-10-23T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-12/","summary":"概要 活动主题：SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day） 活动时间：2021 年 10 月 23 日（周六）13:30-17:30 活","tags":["SOFAMeetup"],"title":"【活动回顾】SOFAMeetup#9 上海站 云原生开放日（Cloud Native Open Day）","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-12/","wordcount":479},{"author":"赵陈","categories":"SOFAStack","content":" 📄\n文｜赵陈（SOFA 开源之夏链路项目组)\n武汉理工大学计算机工程硕士在读\n研究方向：唐卡线稿的自动上色\n校对｜宋国磊（SOFATracer commiter)\n本文 6971 字 阅读 18 分钟\n▼\n背 景 有幸参与开源软件供应链点亮计划——暑期 2021 支持的开源项目，目前 SOFATracer 已经能够将埋点数据上报到 Zipkin 中，本项目的主要目标是将产生的埋点数据上报给 Jaeger 和 SkyWalking 中进行可视化展示。\nPART. 1 SOFATracer SOFATracer 是蚂蚁集团基于 OpenTracing 规范开发的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer 提供了异步落地磁盘的日志打印能力和将链路跟踪数据上报到开源产品 Zipkin 做分布式链路跟踪展示的能力。这次参加开源之夏活动的任务是要把链路跟踪数据上报到 Jaeger 和 SkyWalking 中进行展示。\nSOFATracer 数据上报 上图是 SOFATracer 中的链路上报流程，Span#finish 是 span 生命周期的最后一个执行方法，这是整个数据上报的入口，SOFATracer 的 report span 方法中含有上报链路展示端和日志落盘两个部分。SOFATracer 中没有把上报数据采集器和日志落盘分开只是在日志落盘之前调用 SOFATracer#invokeReporListeners 方法，找到系统中所有实现了 SpanReportListener 接口并加入了 SpanReportListenersHolder 的实例，调用其 onSpanReport 方法完成链路数据上报至数据采集器。下面的代码片段是 invokeReportListeners 方法的具体实现。\nprotected void invokeReportListeners(SofaTracerSpan sofaTracerSpan) { List\u0026amp;lt;SpanReportListener\u0026amp;gt; listeners = SpanReportListenerHolder .getSpanReportListenersHolder(); if (listeners != null \u0026amp;amp;\u0026amp;amp; listeners.size() \u0026amp;gt; 0) { for (SpanReportListener listener : listeners) { listener.onSpanReport(sofaTracerSpan); } } } SpanReportListenerHolder 中的实例在项目启动的时候加入，且分为 Spring Boot 应用和 Spring 应用两种情况：\n 在 Spring Boot 应用中自动配置类 SOFATracerSpanRemoteReporter 会将当前所有 SpanReportListener 类型的 bean 实例保存到 SpanReportListenerHolder 的 List 对象中。SpanReportListener 的实例对象会在各自的 AutoConfiguration 自动配置类中注入到 IOC 容器中。\n 在 Spring 应用中通过实现 Spring 提供的 bean 生命周期接口 InitializingBean，在 afterPropertiesSet 方法中实例化 SpanReportListener 的实例对象并且加入到 SpanReportListenerHolder 中。\n 要实现把 SOFATracer 中的 trace 数据上传到 Jaeger 和 SkyWalking 需要实现 SpanReportListener 接口并在应用启动的时候把对应实例加入到 SpanReportListenersHolder 中。\nPART. 2 Jaeger 数据上报 下图是 Jaeger 中数据上报的部分图示，图中 CommandQueue 中存放的是刷新或添加指令，生产者是采样器和 flush 定时器，消费者是队列处理器。采样器判断一个 span 需要上报后向 CommandQueue 中添加一个 AppendCommand，flush 定时器根据设置的 flushInterval 不断向队列中添加 FlushCommand，队列处理器不断从 CommandQueue 中读取指令判断是 AppendCommand 还是 FlushCommand，如果刷新指令把当前 byteBuffer 中的数据发送到接受端，如果是添加指令把这个 span 添加到 byteBuffer 中暂存。\n在实现上报到 Jaeger 过程中主要工作是 Jaeger Span 和 SOFATracer Span 模型的转换，转换过后利用上面的逻辑发送 span 到后端。\n上图是 Jaeger 中 Sender 的 UML 图，从图中可以看到有两种类型的 Sender 分别是 HTTPSender 和 UDPSender 。分别对应用 HTTP 发送数据和 UDP 发送数据，在实现 SOFATracer 上报 Jaeger 中使用 UDPSender 发送 span 数据到 Jaeger Agent 中，使用 HTTPSender 直接发送数据到 Jaeger-Collector 中。\nJaeger Span 与 SOFATracer Span 模型的转换 模型转换对照 TraceId 和 SpanId 的处理 TraceId 的转换：\n 问题在 SOFATracer 中的 TracerId 的产生规则是：服务器 IP + ID 产生的时间 + 自增序列 + 当前进程号 例如 ：0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，您也可以根据这个规律来查找到请求经过的第一个服务器。后面的 13 位 1403169275002 是产生 TraceId 的时间。之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。——TraceId 和 SpanId 生成规则\n 在 SOFATracer 中 TraceId 是 String 类型，但是在 Jaeger 中 TraceId 是使用的两个 Long 型的整数来构成最终的 TraceId。\n解决方案 在 Jaeger …","date":1634626800,"description":"终于！SOFATracer 完成了它的链路可视化之旅","dir":"blog/sofatracer-completes-its-link-visualisation-journey/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"260c9a0bc64d5f84afc37ee442e347c6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","publishdate":"2021-10-19T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","summary":"📄 文｜赵陈（SOFA 开源之夏链路项目组) 武汉理工大学计算机工程硕士在读 研究方向：唐卡线稿的自动上色 校对｜宋国磊（SOFATracer commiter) 本文 6971","tags":["SOFAStack"],"title":"终于！SOFATracer 完成了它的链路可视化之旅","type":"blog","url":"/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/","wordcount":4273},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@崔伟协 提问：\n 我们的项目基于 MOSN，请问这里 panic了，要怎么解决？\n https://github.com/mosn/mosn/blob/master/pkg/proxy/downstream.go#L393-L399\nA：有异常的时候可以直接返回一个异常的数据包，m.receiveHandler.SendHijackReply(api.SuccessCode, m.headers) 在 filter 里面可以直接返回一个包。\n「MOSN」：https://github.com/mosn/mosn\n@玄灭 提问：\n 请问 MOSN 有计划支持 eureka 注册中心吗？\n A：目前没有，欢迎 pr，有个 zk 的例子，实现起来也简单。\nhttps://www.github.com/mosn/mosn/tree/master/pkg%2Fupstream%2Fservicediscovery%2Fdubbod\n「MOSN」：https://github.com/mosn/mosn\n@张昊 提问：\n 仓库中 /jarslink-samples/spring-boot-transform-sample 对照文档启动后，telnet 中 install -b *ark-biz.jar，控制台报错，大家有遇到类似问题嘛？\n A：这个项目不维护了，相关功能已经 merge 到 SOFAArk 里面去了，以后建议直接用 SOFAArk。\nSOFAArk 有相关的适应样例：https://github.com/sofastack-guides\n「SOFAArk」：https://github.com/sofastack/sofa-ark\n@春少 提问：\n 这一段逻辑，是为了避免在执行 add peer 的时候，出现 raft 选举的情况吗？ A：是的，所以这个时候就交给新的 leader 负责继续推进新的成员节点变更。\n「SOFAJRaft」：https://github.com/sofastack/sofa-jraft\nSOFAStack\u0026amp;amp;MOSN : 新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n-Easy\n为 Layotto 中的关键模块添加注释（例如限流/分布式锁等模块）\n添加 nodejs sdk\n-Medium\n用某种存储实现 File API 组件（例如本地文件系统、hdfs、ftp 等）\n升级由 rust 开发的 wasm demo\n升级由 AssemblyScript 开发的 wasm demo\n详见： https://github.com/mosn/layotto/issues/108#issuecomment-872779356\n另外最近更新了社区晋升规则，大家贡献 pr 后只要满足条件即可晋升，成为社区的维护者之一。\n详见： https://mosn.io/layotto/#/zh/community/promote\n本周推荐阅读 蚂蚁集团技术风险代码化平台实践（MaaS）\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n ","date":1634281200,"description":"SOFA Weekly | QA 整理、SOFAStack\u0026MOSN 新手任务","dir":"blog/sofa-weekly-20211015/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"498a7a535dc938be0783eab5c808d792","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211015/","publishdate":"2021-10-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211015/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly | QA 整理、SOFAStack\u0026MOSN 新手任务","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211015/","wordcount":1130},{"author":"吴成辉","categories":"SOFAStack","content":" 📄\n文｜吴成辉（花名：清霄 蚂蚁集团高级技术专家)\n校对｜陈真、庄晓丹、冯家纯\n本文 6250 字 阅读 11 分钟\n▼\n我们一起回顾下监控上层业务曾经面临的问题：\n 烟囱式的监控分析重复建设 在技术风险领域，一度有超过 5 个系统在做监控分析的能力建设，大致逻辑基本都是拉监控的 Raw Data，做基础的聚合、分析处理后（类似同环比、阈值类的方式），根据一些当前的场景输入，结合一些算法能力，得出一个结论并触发一系列的 Action。类似这种烟囱式的监控分析场景，都是比较初级的重复建设，缺乏智能化、体系化。\n SRE 经验标准化沉淀的问题 在分析场景里也面临 SRE 经验无法标准化沉淀复用的问题，什么是 SRE 经验？拿交易付款下跌来举例，如果当前交易付款下跌 10%，SRE 通常有这么几个分析路径，首先看下淘宝交易是否下跌（来源），再看交易创建，收银台渲染是不是下跌等，这一类我们称为业务依赖。从全局看是否有大规模的压测、变更等动作，这一类称为变更关联，以及如何根据当前故障情况决策进行切流、限流等恢复措施，我们称为分析后置操作。\n 长尾需求 比如比较常见的，算多数据之间的成功率，流量损耗等等需求，通过产品化解决的成本非常高，而且用户不能快速修改、定制相关能力。\n同时我们看到当前监控系统自身面临的问题：\n 监控的数据使用复杂 包含了几万张数据表、十几万张自定义数据表，数据类型超过 20+，以及跨站点、数据源异构等等问题。\n 监控服务不够开放 如何动态日志清洗计算、如何做分析后的时序存储、监控的时序检测能力如何复用等等。我们需要把监控的数据、能力完全服务化出来。\n 高效的可编程代码化平台缺失 没有一个高效平台帮助 SRE 先沉淀经验、再促进经验的标准化、复用，最后产品化。\n基于上面问题，我们提出了 MaaS 的设想（Monitoring as a Service), 监控能力服务化，开放、融合监控能力到技术风险各个领域，快速完成 SRE 场景建设，沉淀可复用能力，主要包含以下 4 个阶段目标：\n1.开放服务把监控的计算、存储、算法、视图等等能力开放出来。\n2.核心共建几个重点的技术风险领域场景，比如变更防御、压测引流、无损注入、定位应急等等。\n3.促进服务的标准化沉淀，让更多的场景可以复用、共同建设这部分的能力。\n4.解决“监”与“控”之间的链接问题。\n（我们的这里的 AIOPS 更多指的是\n一系列专家经验的集合、沉淀、持续维护优化）\nPART. 1 平台技术概览 能力服务化\n监控的服务化能力整体包含这么几部分，数据服务化、配置服务化、计算、存储服务化、算法服务化、通知、云原生服务化等等，也包括一些外部能力集成比如消息缓存等等。\n我简单举两个服务化的例子来介绍下什么是服务化：\n比如视图服务，当某个变更发起后，这个变更关联的 100 个应用指标、20 个业务指标中的 10 个指标出现了问题，这个时候，我们需要动态为这个 10 个指标创建一个数据视图，来分析业务影响范围，这个时候就会用到我们的视图服务。\n动态计算服务，比如我需要实时计算下某个应用在 A 机房（或某个 ZONE 如：GZXXX）的其中 5 台机器在 11:00~12:00 的接口方法调用情况，动态的计算服务就会派得上用场。\n数据服务化\n能力服务化中非常重要的一环就是数据服务化，因为数据是所有监控分析的基础，数据服务化主要分成两部分。\n 第一步是监控数据模型化 我们从数据的使用视角把数据抽象出数据虚拟表、虚拟表列定义、列关系。以及虚拟表的实现绑定，包含指标数据，也包含关系元数据，最后把这些物理实现映射到监控具体的数据指标或者底层的元数据服务上。\n 第二步是服务模板化 我们把一个数据服务抽象出三类：\n实体查询，比如查询一个应用或者一个 Tbase 的集群；\n数据查询，比如查询一个应用的 Sofa Service 在 APP 聚合维度上的数据；\n关系查询，查询一个实体的关联实体，比如 cif 关联的 Tbase 集群等。\n 最后，我们实现了 5w+ 数据服务自动生成，分钟级别 SDK 更新的能力，我们可以通过非常语义化的访问方式来访问监控的所有数据，我们可以做到只要是监控体系内的数据，都可以通过我们这套能力访问到对应的数据服务，从而达到整个监控数据的服务化开放。 研发效能\n 大库管理，我们设计了一种可以支持服务沉淀、权限隔离（可以独立按目录管理 CR）、逻辑复用的代码结构，比如缓存 Tbase 的研发 + SRE 可以共同在 cache 目录里面定义缓存问题的发现、分析、恢复。同时可以复用到 core-service 里面的比如容器是否健康，网络是否异常等标准服务。平台能够提供一致的多环境调试能力，方便监控分析逻辑可以直接运行在本地 IDE 环境中，我们通过动态代理的模式把本地访问的数据、函数服务代理到服务端，从而达到了本地跟线上完全一致的研发体验。这项能力极大地提高了研发效率，研发过程中可以直接 debug 线上数据，比传统的日志模式的调试方式有非常大的效率提升，一个基础的分析函数基本可以在小时级别内完成。\n 一站式发布运维，传统的 Serverless 发布模式大致要经历这么几个阶段，从工程打包到 Jar 文件，耗时 1min，大概在 100-300MB，从 Jar 文件打包 Build 出镜像，大致 10min，最后做镜像化发布整体耗时约 20min, 整体流程大概耗费半个小时。我们研发了一套基于函数粒度的发布运维模式，以 MaaSFunction 为入口，做跨文件 Linker，如何做 Linker，看这个示意图，我们从 MaasFunction 入口开始解析本类依赖的文件，比如这边依赖的其他函数，到下面的 service，再到 util 层的相互依赖，从而通过这种方式解析出业务代码片段，通过动态编译完 Jar 大小目前最大在 500KB 左右，根据代码大小一般在 5s 内，再通过热加载到目标机器上，整体可以做到 5s 级发布，1s 回滚，其他还有配套的日志、监控等等能力。\n 多语言 Runtime\n我们在初期建设的时候函数是都运行在一个集群里面，经常会遇到例如：死循环、OOM、线程频繁创建等等性能问题，因为业务代码不可控，CR 不能完全杜绝这类问题，这样我们就需要完全隔离的函数运行环境，从图中可以看到，每个函数至少具备 2 个独立的容器（容灾的需要），函数 1OOM（Out Of Memory），不会影响到函数 2。这样我们就可以基本做到函数级别的执行层隔离，我们通过 SLO 的度量，平台稳定性有了非常大的提升。\n当我们按照函数级别隔离的模式大规模上线的时候遇到了成本问题，底层 sigma 支持的 pod 调度的最小规模是 0.5c（底层物理网卡等等限制），如果 2 台容灾，基本上一个函数至少占用 1c 的物理资源，随着函数业务的大规模使用，这块成本是很难持续的。通过我们的观察，绝大多数函数占用实际的 CPU10% 不到，甚至更低。我们同 Serverless Paas 团队一起共建了函数的高密度部署模式，通过 0.5c 的 pod 中隔离 5 个 0.1c 的容器，然后通过容器 IP + 端口的方式绑定 …","date":1634022000,"description":"蚂蚁集团技术风险代码化平台实践（MaaS）","dir":"blog/ant-group-technical-risk-coding-platform-in-practice-maas/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"87ede64d8d98af4c1bf7bf4d51ee9cdf","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","publishdate":"2021-10-12T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","summary":"📄 文｜吴成辉（花名：清霄 蚂蚁集团高级技术专家) 校对｜陈真、庄晓丹、冯家纯 本文 6250 字 阅读 11 分钟 ▼ 我们一起回顾下监控上层业务曾经面临的问题： 烟囱式","tags":["SOFAStack"],"title":"蚂蚁集团技术风险代码化平台实践（MaaS）","type":"blog","url":"/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/","wordcount":5838},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\nLayotto 本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@风 提问：\n 麻烦问下 SOFA 中的 consumerConfig 的 uniqueId 和 application 分别起什么作用，有什么区别呀？\n A：发布 RPC 服务的时候做配置，uniqueId 是服务的唯一标识，比如你想同一个 service 类发两个服务，就起两个 uniqueId。\n「SOFARPC」：https://github.com/sofastack/sofa-rpc\n@郑楚齐 提问：\n 我在 K8s 上测试将使用 spring-cloud-feign 的服务接入 MOSN Proxy，但是目前 consumer 端一直访问不到 provider，我还在排查问题，想问一下，如果要调用的话，FeignClient 这边是不是需要直接将 URL 指向代理？ A：不是透明劫持的话，就要直接指向 Proxy 的端口。\n「MOSN」：https://github.com/mosn/mosn\n@东仔 提问：\n MOSN 在 Linux 上的 idea 如何启动？\n A：参考下图，\n 「MOSN」：https://github.com/mosn/mosn\n@王逸飞 提问：\n A -\u0026amp;gt; B, A 没有问题，执行到 B 的更新操作时候， Could not found global transaction xid = 192.168.0.112:8091:1893025023560908，会是什么原因产生的？\n A：debug 到 b 的时候看下 TC 的 global table 里面数据存不存在。可能是服务重试或者网络超时造成，自己看下 tm 的决议是什么?\n java.time.LocalDateTime 序列化失败，这样的情况一般如何解决呢? A：改数据库类型，mkyro + datatime 改为时间戳类型，或者等 1.5。\n「Seata」：https://github.com/seata/seata\n本周发布 Layotto 发布了0.2.0 版本，包括以下功能：\n 支持 File API\n 支持 Binding API\n Tracing 和 metrics\n 为已有 API 添加更多组件\n 修复安全问题以及减少 panic 风险\n 不同组件之间保证数据隔离、代码复用\n WASM 模块支持热加载\n go sdk 添加更多 feature\n 一个简单的 Java sdk\n 添加更多文档、修复文档错误\n 添加社区治理和晋升规则\n 详细参考：\nhttps://github.com/mosn/layotto/releases/tag/v0.2.0\n本周推荐阅读 下一个 Kubernetes 前沿：多集群管理\n 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁智能监控\n ","date":1633676400,"description":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、Layotto 发布新版本","dir":"blog/sofa-weekly-20211008/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b71750e53df5357dc922e1a7d952c265","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211008/","publishdate":"2021-10-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211008/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFAStack"],"title":"SOFA Weekly | Layotto 本周 Contributor、QA 整理、Layotto 发布新版本","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211008/","wordcount":1050},{"author":"金敏、邱见","categories":"SOFAStack","content":" 文｜金敏（蚂蚁集团技术专家)\\邱见（Red Hat)\n校对｜ 冯泳（蚂蚁集团资深技术专家)\n本文 3311 字 阅读 6 分钟\n从最初 Kubernetes 技术问世，业界一遍一遍的质疑它能否能经得住生产级的考验，到今天许多大型企业已经采用 Kubernetes 技术“云化”之前大规模的基础设施，在企业内部创建了数十个甚至数百个集群。\nKubernetes 原生的管理能力目前仍然停留在单集群级别。每一个集群可以稳定地自治运行，但是却缺乏横贯多个集群的统筹管理能力。基础设施的建立者需要协调分散在各处的管理组件，形成一个统一的管理平台。\n通过它，运维管理人员能够获知多集群水位的变化，节点健康状态的震荡等信息；业务应用负责人能够决策如何调配应用服务在各个集群中的部署分布；应用的运维人员能够获知服务状态，下发腾挪的策略。\n与多集群相关的创新正在不断涌现。例如 ClusterAPI 和 Submariner 就是处理特定多集群管理问题比较成功的项目。\n而本文要讨论的是那些试图解决企业在面对多集群管理时遇到的所有问题的技术探索。\n在过去五年中，中国的技术公司蚂蚁集团在多集群管理的思考、使用和实施等方面学习到了很多宝贵的经验。\n蚂蚁集团管理着遍布全球的数十个 Kubernetes 集群，每个集群平均拥有数千个节点（服务器）。他们将应用程序及其所需组件（包括中间件，数据库，负载均衡等等）在架构层面组织成逻辑数据中心（LDC）的弹性逻辑单元中，并将它们规划部署到物理基础设施上。这种架构设计帮助他们实现基础设施运维的两个关键目标：高可用性和事务性。\n 首先，部署在某个 LDC 上的业务应用的可用性在所属 LDC 内能够得到保障。\n 其次，部署在 LDC 内的应用组件可以被验证，并在故障发生时，可以被回滚。\n 蚂蚁集团 PaaS 团队的资深技术专家冯泳表示：\n “蚂蚁集团拥有数十个 Kubernetes 集群、数十万个节点和数千个关键应用的基础设施。在这样的云原生基础设施中，每天都会有数以万计的 Pod 被创建和删除。构建一个高度可用、可扩展且安全的平台来管理这些集群和应用程序是一项挑战。”\n PART. 1 始于 KubeFed 在 Kubernetes 项目生态中，多集群功能主要由与之同名的 SIG-Multicluster 团队处理。这个团队在 2017 年开发了一个集群联邦技术叫做 KubeFed。\n联邦最初被认为是 Kubernetes 的一个内置特性，但很快就遇到了实现以及用户诉求分裂的问题，Federation v1 可以将服务分发到多个 Kubernetes 集群，但不能处理其他类型的对象，也不能真正的以任何方式“管理”集群。一些有相当专业需求的用户——尤其是几个学术实验室——仍在使用它，但该项目已被 Kubernetes 归档，从未成为核心功能。\n然后，Federation v1 很快被一种名为“ KubeFed v2 ”的重构设计所取代，世界各地的运营人员都在使用该设计。它允许单个 Kubernetes 集群将多种对象部署到多个其他 Kubernetes 集群。KubeFed v2 还允许“控制平面”主集群管理其他集群，包括它们的大量资源和策略。这是蚂蚁集团多集群管理平台的第一代方案。\n蚂蚁集团使用多集群联邦的首要任务之一是资源弹性，不止包括节点级别弹性也包括站点级别弹性。通过在需要时添加节点和整个集群起到提高效率和扩展系统的能力。例如年度性的资源弹性，每年 11 月 11 日是中国一年一度的光棍节，蚂蚁集团通常需要快速部署大量额外容量来支持高峰在线购物工作负载。然而，可惜的是正如他们发现的那样 KubeFed 添加新集群的速度很慢，而且在管理大量集群方面效率低下。\n在 KubeFed v2 集群中，一个中枢 Kubernetes 集群会充当所有其他集群的单一“控制平面”。蚂蚁集团发现，在管理托管集群和托管集群中应用程序的时候，中枢集群的资源使用率都非常高。\n在管理仅占蚂蚁集团总量 3% 的应用程序工作负载的测试中，他们发现由中等规模的云实例构成的中枢集群就已经饱和了，并且响应时间很差。因此，他们从未在 KubeFed 上运行全部工作负载。\n第二个限制与 Kubernetes 的扩展功能有关，称为自定义资源定义或 CRD。类似蚂蚁集团这样的“高级用户”往往会开发众多的自定义资源来扩充管理能力。为了要在多集群间分发 CRD，KubeFed 要求为每个 CRD 都创建一个“联合 CRD”。这不仅使集群中的对象数量增加了一倍，也为在集群间维护 CRD 版本和 API 版本一致性方面带来了严重的问题，并且会造成应用程序因为不能兼容不同的 DRD 或者 API 版本而无法顺利升级。\nCRD 的这种数量激增也导致了严重的故障排除问题，同时 CRD 的使用定义不规范/字段变更随意等坏习惯会使 KubeFed 控制面的鲁棒性雪上加霜。在本地集群有自定义资源的地方，联邦控制平面上也有一个代表该本地集群资源的图形聚合视图。但是如果本地集群出现问题，很难从联邦控制平面开始知道问题出在哪里。本地集群上的操作日志和资源事件在联邦级别也是不可见的。\nPART. 2 转向 Open Cluster Management Open Cluster Management 项目（OCM）是由 IBM 最初研发，并由红帽在去年开源。OCM 在蚂蚁集团和其他合作伙伴的经验基础上，改进了多集群管理的方法。它将管理开销从中枢集群下放到每个被管理集群上的代理（Agent）上，让它在整个基础设施中分布式自治并维护稳定。这使得 OCM 理论上能管理的集群数量至少比 KubeFed 多一个数量级。到目前为止，用户已经测试了同时管理多达 1000 个集群。\nOCM 还能够利用 Kubernetes 本身的发展来提高自身的能力。例如，那些以 CRD 封装的能力扩展可以使用 OCM 的 WorkAPI（一个正在向 SIG-Multicluster 提议的子项目）在集群之间分发 Kubernetes 对象。WorkAPI 将本地 Kubernetes 资源的子集嵌入其中，作为要部署的对象的定义，并将其留给代理进行部署。此模型更加灵活，并且最大限度地减少了对任何中央控制平面的部署需求。WorkAPI 可以一起定义一个资源的多个版本，支持应用程序的升级路径。同时 WorkAPI 兼顾了中枢集群和被管理集群网络链接故障时的状态保持问题，并可以在重连的情况下保障资源状态的最终一致性。\n最重要的是，OCM 在集群部署中实现了更多的自动化。在 KubeFed 中，集群的纳管是一个“双向握手”的过程，以中枢集群和被管理集群之间“零信任”作为基础，在此过程中涉及许多手动步骤来保障安全性。新平台能够简化这一过程。例如，因为它在 “PULL” 的基础上运行，不再需要多阶段手动证书注册，也不需要任何明文的 KubeConfig 证书的流通，就可以做到让被管理集群获取中枢集群的管理命令。\n尽管注册的流程注重双向的“信任性”，但是在 OCM 中添加新集群只需要很少的操作；工作人员可以简单地在目标 Kubernetes 集群上部署 “Klusterlet” 代理实现自动纳 …","date":1633330800,"description":"下一个 Kubernetes 前沿：多集群管理","dir":"blog/next-kubernetes-frontier-multi-cluster-management/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7120f96fca72cfca3c6fbfd9ab9e3172","permalink":"https://sofastack.github.io/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","publishdate":"2021-10-04T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","summary":"文｜金敏（蚂蚁集团技术专家)\\邱见（Red Hat) 校对｜ 冯泳（蚂蚁集团资深技术专家) 本文 3311 字 阅读 6 分钟 从最初 Kubernetes 技术问世，业界一遍一遍的质疑它能否能","tags":["SOFAStack"],"title":"下一个 Kubernetes 前沿：多集群管理","type":"blog","url":"/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/","wordcount":2933},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nLayotto 本周新晋 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@郑楚齐 提问：\n 我们在 Istio 环境下，因为 MOSN 是自动 sidecar 注入的，我怎么控制他读取我的配置文件内容呢？而且我看官方的 Istio 案例也是可以通过 virsual service 进行流量控制的，我们这个 config.json 也是可以进行流量控制的，是不是我理解的 config.json 是在 virsualService.yaml 的功能上进行拓展的功能(比如这种 tag 路由是 virsualService 不能控制的)。\n A：Istio 场景下对应的 sidecar 的静态配置是一些通用的模板（如 pilot 地址渲染等）。关于 service 相关的路由及治理控制都是通过 Istio 定义的 CRD 控制：\nhttps://istio.io/latest/docs/reference/config/networking/\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n MOSN 执行的这个 config.json 是如何使用呢？因为目前 Istio 的这个配置 DestinationRule VirsualService 是不满足需求的，或者说 MOSN 收到我们订制的DestinationRule VirsualService，会自动转为 config.json 供给 MOSN 使用呢？\n A：cluster subset 配置目前 Istio 的 Destination Rule 还不支持，不过目前是可以通过 Envoy Filter 来给对应的 cluster 打 patch 实现（比较麻烦点）。\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n 如果是在 Envoy Filter 打 patch 的话，有没有什么例子吗?\n A：这个就是上面说的 cluster subset 配置。目前 Istio 的 Destination Rule 里面还不支持这个（详细见上面的那个讨论 issue），目前唯一的方法就是使用 Envoy Filter 的这个 CRD 打 patch 实现。\n可参考文档：https://istio.io/latest/docs/reference/config/networking/envoy-filter/#EnvoyFilter-ClusterMatch\nMOSN：https://github.com/mosn/mosn\n@郑楚齐 提问：\n 看了官方的 EnvoyFilter，不过感觉跟我们 MOSN 的 config.json 里面的内容想对照匹配起来确实很难。\n A：你可以用 xds 动态更新或者扩展用我们的 API 更新，不需要直接用这个配置文件。直接调用 MOSN 自己的 API，xds 其实也是 adapt 到这些 API 接口的，如果你们不用 Istio 的话，自己封装可能更简单，主要就 route 和 cluster 两个 API 就行了。\n这是一个用 zk 更新 Dubbo 的例子：\nhttps://github.com/mosn/mosn/blob/38b3b922b59500acc082e0ac9d705e41944c94ee/pkg/upstream/servicediscovery/dubbod/common.go#L99\nMOSN：https://github.com/mosn/mosn\n@孤若 提问：\n 当空回滚时，如果是因为远程方法调用 try 响应超时，怎么解决终止 try 执行？比如 rollback 执行远比 try 阶段快，rollback 结束 try 还在执行。\n A：我之前有参考这个，有提到 TCC 异常控制：\nhttps://www.infoq.cn/article/g33hcc-qosjplkt4e64e\nSeata：https://github.com/seata/seata\n@林祥标 提问：\n Seata 1.3.0 jdk 1.8 使用 jackson 对 localDateTime 进行序列化时报错，有大佬知道怎么解决吗？\n A：如果数据库用 datetime，实体又是 localdatetime，目前我发现只能 spi、替换序列化方式、依赖等等都没用。通过 spi 定义三个序列化方式就行了：LocalDate、LocalDateTime、LocalTime\u0026amp;hellip;反正如果数据库不是时间戳，目前给的适配方式是无用的(个人用下来的结果)。\nSeata：https://github.com/seata/seata\nSOFAStack：新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nEasy\n为 Layotto 中的关键模块添加注释（例如限流/分布式锁等模块）、添加 nodejs sdk。\nMedium\n用某种存储实现 File API 组件（例如本地文件系统、minio、hdfs、ftp 等）。\n「详见」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁智能监控\n 2021 年云原生技术发展现状及未来趋势\n ","date":1633071600,"description":"SOFA Weekly | Layotto 本周新晋 Contributor、QA 整理、新手任务）","dir":"blog/sofa-weekly-20211001/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8a010b34f9a0dbd849f07463c4b6c9b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211001/","publishdate":"2021-10-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20211001/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto 本周新晋 Contributor、QA 整理、新手任务）","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20211001/","wordcount":1710},{"author":"唐博、谭崇康","categories":"SOFAStack","content":" 文｜唐博（花名：博易 蚂蚁集团技术专家)\n谭崇康（花名：见云 蚂蚁集团高级技术家)\n本文 10316 字 阅读 18 分钟\n▼\n蚂蚁集团运行着全球最大的 Kubernetes（内部称为 Sigma) 集群之一。Kubernetes 社区官方以 5K node 作为 Kubernetes 规模化的事实标准，而蚂蚁集团在 2019 年的时候，就已经维护着单集群规模超过 1W node 的 Kubernetes 集群。\n这不仅仅是单集群节点量级上的差异，更是业务规模的差异，业务多样化和复杂度上的差异。\n一个形象化的比喻就是，如果官方以及跟着官方的 Kubernetes 使用者能想象到的 Kubernetes 的集群规模是泰山，那么蚂蚁集团在官方的解决方案之上已经实现了一个珠穆朗玛峰。\n蚂蚁集团的 Kubernetes 的演进，从 2018 年至今已经走过了 3 年多的岁月，虽然在 2019 年的时候就构建了万台集群的规模，但时至今日，无论是业务形态还是集群的服务器都发生了巨大的变化。\n 首先，当时的集群万台节点，主要还是偏小规格的服务器，而如今都是大机型，虽然机器的数量也是万台，实际管理的 CPU 数量已经成倍增长。\n 其次是当时集群里面几乎全量是 Long running 的在线业务，Pod 的创建频率每天只有几千个，如今我们的集群上几乎跑满了流式计算和离线计算业务等按需分配的 Pod，因此在 Pod 数量上成倍增长，实际管理的 Pod 数量超过了百万。\n 最后，是 Serverless 的业务快速发展，Serverless Pod 的生命周期基本在分钟级甚至是秒级，集群每天的 Pod 创建量也超过了几十万，伴随着大量的 Kubernetes list watch 和 CRUD 请求，集群的 apiserver 承受了数倍于以往的压力。\n 因此在业务 Serverless 的大背景下，我们在蚂蚁启动了大规模 Sigma 集群的性能优化方案，根据业务的增长趋势，我们设定的目标是，构建 1.4W 个节点规模的集群，同时通过技术优化，期望达成在请求延迟上不会因为规模的原因有所下降，能够对齐社区标准，即 create/update/delete 请求的天级别 P99 RT 在 1s 之内。\n可想而知，挑战是非常巨大的。\nPART. 1 大规模集群的挑战 毋庸置疑，大规模集群带来了很多挑战：\n 随着集群规模增大，故障的爆炸半径也将扩大。Sigma 集群承载了蚂蚁集团诸多重要应用，保障集群的稳定和业务的稳定是最基础也是优先级最高的要求。\n 用户大量的 list 操作，包括 list all，list by namespace，list by label 等，均会随着集群的规模增大而开销变大。这些合理或者不合理的 list 请求，将让 apiserver 的内存在短时间内快速增长，出现 OOM 异常，无法对外响应请求。此外，业务方的 list 请求也会因为 apiserver 无法处理请求而不断重试，造成 apiserver 重启后因过载不可恢复服务能力，影响整个集群的可用性。\n 大量 List 请求透过 apiserver 直接访问 etcd 服务，也会让 etcd 实例的内存剧增而出现 OOM 异常。\n 随着业务量的增长，特别是离线任务的增多，create/update/delete 等请求的数量也迅速增加，导致客户端请求 apiserver 的 RT 极速上升，进而使得调度器和一些控制器因为选主请求超时而丢主。\n 业务量增长将加剧 etcd 由于 compact 等操作自身存在的性能问题，而使 etcd 的 P99 RT 暴涨，进而导致 apiserver 无法响应请求。\n 集群中的控制器服务，包括 Kubernetes 社区自带的控制器例如 service controller，cronjob controller 以及业务的 operator 等，自身存在的性能问题都将在大规模集群面前被进一步放大。这些问题将进一步传导到线上业务，导致业务受损。\n 如计算机学科的古老格言所说：\n「 All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection\u0026amp;hellip; and the performance problems. 」\n大规模集群既是照妖镜，也是试金石。\nPART. 2 大规模集群的收益 诚然，构建一个大规模的 Kubernetes 集群也提供了诸多收益：\n 为运行大型服务提供更为便利的基础设施 ，便于应对业务扩容时大幅飙升的资源需求。例如在双十一等电商大促活动期间，可以通过扩展现有集群而不是新建其它小集群来应对业务的增长。同时集群管理者可以管理更少的集群，并且以此来简化基础架构管理 。\n 为大数据和机器学习的离线计算任务提供更多的资源，为分时复用/分时调度等调度手段提供更大的施展空间，让离线的计算任务在在线业务的低峰期时可以使用更多的资源进行计算，享受极致弹性和极速交付。\n 还有非常重要的一点，在更大的集群中可以通过更加丰富的编排调度手段来更为有效地提升集群整体的资源利用率。\n PART. 3 SigmaApiServer性能优化 Sigma apiserver 组件是 Kubernetes 集群的所有外部请求访问入口，以及 Kubernetes 集群内部所有组件的协作枢纽。apiserver 具备了以下几方面的功能:\n 屏蔽后端数据持久化组件 etcd 的存储细节，并且引入了数据缓存，在此基础上对于数据提供了更多种类的访问机制。\n 通过提供标准 API，使外部访问客户端可以对集群中的资源进行 CRUD 操作。\n 提供了 list-watch 原语，使客户端可以实时获取到资源中资源的状态。\n 我们对于 apiserver 性能提升来说可以从两个层面进行拆解，分别是 apiserver 的启动阶段和 apiserver 的运行阶段。\napiserver 启动阶段 的性能优化有助于：\n 减少升级变更影响时长/故障恢复时长，减少用户可感知的不可用时间，给 Sigma 终端用户提供优质的服务体验（面向业务的整体目标是 Sigma 月度可用性 SLO 达到 99.9%，单次故障不可用时间 \u0026amp;lt; 10min）。\n 减少因为发布时客户端重新 list 全量资源而导致的 apiserver 压力过大情况出现。\n apiserver 运行阶段 的性能优化的意义在于：\n 稳定支持更大规模的 Kubernetes 集群。\n 提高 apiserver 在正常平稳运行的状态中，单位资源的服务能力；即提高可以承受的请求并发和 qps， 降低请求 RT。\n 减少客户端的超时以及超时导致的各种问题；在现有资源下提供更多的流量接入能力；\n 整体优化思路\n构建一个大规模的 Kubernetes 集群以及性能优化不是一件容易的事，如 Google Kubernetes Engine K8s 规模化文章所 …","date":1632812400,"description":"攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践","dir":"blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b6cc47242239f350d5aca9717037f061","permalink":"https://sofastack.github.io/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","publishdate":"2021-09-28T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","summary":"文｜唐博（花名：博易 蚂蚁集团技术专家) 谭崇康（花名：见云 蚂蚁集团高级技术家) 本文 10316 字 阅读 18 分钟 ▼ 蚂蚁集团运行着全球最大的 Kubernetes","tags":["SOFAStack"],"title":"攀登规模化的高峰 - 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践","type":"blog","url":"/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/","wordcount":7129},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@证道者 提问：\n MOSN 怎么将 HTTP 转到 Dubbo 的数据,怎么实现新的协议？\n A：这个你要写个 filter ，因为每个 HTTP 字段怎么对应 Dubbo 的字段，是没有固定标准的。\nA：「HTTP 转 SOFA 的例子」 https://www.github.com/mosn/mosn/tree/master/pkg%2Ffilter%2Fstream%2Ftranscoder%2Fhttp2bolt\nA：这个需要 client 满足这个字段对应规范，所以一般就自己实现了。\n 公司很多这种 RPC 的接口，每一个接口都要写一下 filter 吗？没有通用的转换吗？\n A：一个协议就一个吧，比如 HTTP 的 header：service 对应 Dubbo 的 service。你也可以用其他的 HTTP header 来对应，比如用 dubbo-service，所以没有一个标准，就需要自己简单做个对应关系。\nMOSN：https://github.com/mosn/mosn\n@王夕 提问：\n 咨询一个问题，TCC 的嵌套子事务，如果发生重试的话，如下图中的 2、6，会产生不同的 branch 记录吗？ A：有可能,要么关了重试,要么做幂等\n 也就是说根据 xid 做幂等，而不要根据 branchid 做幂等对吗？\n A：branchid 进来一次就变一次,肯定不行,该分支同入参同 xid 一般就可以作为幂等的校验条件。\nSeata：https://github.com/seata/seata\n@江培泉 提问：\n 请教下，oracle 用户没获取到行信息，导致 undo_log 无法插入，也无法回滚。 主键字段类型和 JAVA 的类型： A：主键的 Long 改成 BigDecimal，Oracle 的 number 长度超过 19 之后，用 Long 的话，setObject 会查不出数据来。\nSeata：https://github.com/seata/seata\n本周推荐阅读 SOFAJRaft 在同程旅游中的实践\n 技术风口上的限流\n 蚂蚁智能监控\n 2021 年云原生技术发展现状及未来趋势\n ","date":1632466800,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210924/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"88a73b7a463bc79a5bcb81ae4e0a4fee","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210924/","publishdate":"2021-09-24T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210924/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210924/","wordcount":903},{"author":"赵延","categories":"SOFAStack","content":"文｜赵延（SOFAJRaft Committer)\n校对｜冯家纯（SOFAJRaft Committer)\n本文 15717 字 阅读 23 分钟\n▼\n同程艺龙作为对 Raft 研究较早的公司，早在 14 年算法的 paper 刚发布的时候，便已经对其进行了调研。同时也与 paxos 、zab 等算法进行了详细的对比，并在公司内部的计数器、任务调度元信息存储等场景进行试点。\n不过早期对于 Raft 的尝试较多的是在 C++ 技术栈试水，在 Java 技术栈里却很少有涉及。\n近期刚好有基于 etcd 的老项目由于需要自定义的数据结构需要重构，原有的 etcd 无法在底层数据结构层面满足需求，因此决定采用 Java 技术栈结合开源项目 SOFAJRaft 进行底层数据存储的开发，以期解决多节点数据强一致的问题。\n本文假设读者对 Raft 及强一致的概念已经有了较深的理解，详细介绍了公司内部如何使用 *JRaft* 的进行老系统的改造以及使用过程中遇到的工程问题，希望其他对 Raft 有兴趣的同学可以一起讨论。\nPART. 1\n背 景\n公司内部原本存在一个系统 mdb (metadata database)，go 语言编写，用于管理所有的实例元数据信息，元数据的内容就是一个 map。\n该组件提供对元数据增删改查的接口，并且使用 go 语言编写，在检索数据时引入了 K8s selector 的包，使用 K8s selector 的解析规则筛选特定标签的元数据信息。\n数据持久化则是实用了强一致组件 etcd 进行存储，key 为元数据的 ID，保证唯一，value 为具体的元信息，包含各个标签以及对应的值。\n该系统大体架构如图 -1 所示:\n 图-1：原来的架构\n「该架构的弊端」\n 每隔一段时间需要去拉取 etcd 的全量数据，担心单次请求数据量太大的情况，对数据 ID 进行了 hash 分片，依次获取每个分片下个 key，再通过 key 去获取 value，导致 etcd 的查询频率非常高。\n 非 ID 查询条件的一致性查询，和上面的问题一样，也需要做拉取全量数据的操作。\n 更新删除操作也是一样，需要拉取全量数据再操作。\n 分析以上问题可以发现，使用 etcd 作为强一致存储，但 etcd 是基于 KV 存储的组件，并且解析组件 mdb 和 etcd 是分离的，在需要保证数据最新的情况下，必须得去 etcd 拿最新的数据到本地再进行操作。\n而 etcd 基于 KV，就得拿到 etcd 的全量数据都给拉到本地后再做操作。\n如果有一个组件，提供强一致的存储能力，又能直接去解析 K8s selector 的规则，存储的数据结构和元数据信息更加亲和，那么中间的那一层 mdb 就可以直接去掉了，由这个组件来解析对应的 crud 规则，将解析过后的规则直接在本地查询，那么以上问题就能够直接解决了。\nPART. 2\n改 造\n基于以上问题，我们准备自己开发一个强一致存储的组件，能够自己解析 K8s selector 的规则，并且将数据保存在自己本地。\n因为个人对 Java 语言比较了解，并且之前使用 Nacos 时，对 SOFAJRaft 也有一定了解，最终选择了 SOFAJRaft 来构建强一致存储组件，将它命名为 mdb-store。\n主要改造点：\n 使用 SOFAJRaft 编程模型构建业务状态机，业务状态机中根据 Raft log 中的 data 类型，进行 crud 的操作。\n mdb-store 提供与原来 mdb 相同的 api，让改造对用户透明，改造完成后只需要切换域名对应的实例即可。\n 迁移 K8s selector 的解析逻辑，这里用 Java 写了一套和 go 版本 K8s selector 一样解析逻辑的组件 K8s-selector-Java。\n 改造过后的架构如图-2所示:\n 图-2：重构后的架构\n通过改造过后，将 mdb 移除，让用户直接和 mdb-store 进行通信，中间的通信少了一跳，加快了访问效率。将 mdb 和 etcd 也进行了移除，减少了整个系统的组件，降低运维成本。\nPART. 3\nSOFAJRaft 的具体使用\n将写操作转换成 Raft log\n在 SOFAJRaft 中，编程模型和通常的 Spring MVC 的编程模式不太一样。\n在 Spring MVC 中，一个请求到达了后端，通常会通过 Controller -\u0026amp;gt; Service -\u0026amp;gt; Processor 这么几层。Controller 负责本次 http 请求的资源映射， 再由 Controller 去调用特定的 Service 方法，在 Service 层中，对参数进行一些处理和转换，再交由 Processor 层去对请求做真正的处理。\n大体逻辑如图 -3 所示，\n 图-3：通常的编程模型\n在 SOFAJRaft 中，所有的写操作都要通过状态机去执行（读操作不需要经过状态机）。需要将写操作转换成 task，状态机去应用 task 然后再进行业务处理。\ntask 中包含两个属性是需要关注的，一个是 done，一个是 data。\n- done 就是本次 task 被状态机处理完成后的回调，比如在 done 的回调逻辑中，将 response flush 到客户端。\n- data 就是 Raft log 中的具体数据，比如要执行一条插入元数据的命令。data 就会包含本次操作的类型（插入），以及本次操作的具体数据。\nprivate ByteBuffer data = LogEntry.EMPTY_DATA; private Closure done; /// 省略部分代码 } 大体逻辑如图 -4 所示，\n 图-4：SOFAJRaft 的编程模型\n所有的操作都抽象成一个实体 Operation，在 Service 层，就根据业务把参数转换成不同的 Operation，然后再将 Operation 序列化，设置到 Task 中的 data 属性，再由 Node 将 task 提交。\n这里可以将 task 看成是一个 Raft log，一旦 Raft log 被半数的机器给提交。状态机就会应用 Raft log，应用完成之后就会触发 done 中的回调。\n· 抽象过后的实体类\n//操作类型，比如增删改查 int type; //操作的哪个表，某些类型不需要此字段 String table; //具体的操作数据，根据 type 的不同，数据类型也会不同 T params;} · 构建 task 并通过 node 提交给状态机\n//定义回调的逻辑，当该 Raft log 被状态机应用后，会进行回调 task.setDone(new StoreClosure(operation, status -\u0026amp;gt; { StoreStatus storageStatus = (StoreStatus) status; closure.setThrowable(storageStatus.getThrowable()); …","date":1632207600,"description":"SOFAJRaft 在同程旅游中的实践","dir":"blog/sofajraft-in-practice-in-the-same-tour/","fuzzywordcount":7500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7c319b747ce3bc0df7adbd820d690ed3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","publishdate":"2021-09-21T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","summary":"文｜赵延（SOFAJRaft Committer) 校对｜冯家纯（SOFAJRaft Committer) 本文 15717 字 阅读 23 分钟 ▼ 同程艺龙作为对 Raft 研究较早的公司，早在 14 年算法的 paper 刚发布的","tags":["SOFAStack"],"title":"SOFAJRaft 在同程旅游中的实践","type":"blog","url":"/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/","wordcount":7461},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@证道者 提问：\n 今天看了文章，好像蚂蚁 MOSN 结合 envoy，性能更好，不知道有没有开源这个？\n A：有开源，有个镜像可以玩。\nhttps://mp.weixin.qq.com/s/ioewVcwiB5QA8w3A3gaikg，\n今年 GopherChina 的文字版, 可以了解下。我们内部已经落地，线上跑飞起来了，适合不同的场景了。目前我们用在南北和网关，比较大规模的场景。这个目前也在跟 envoy 官方共建合作，还有场景就是本来就是 envoy 的用户，也可以更简单的写扩展。\n2、@朱仕智 提问：\n 请问这个限流在开源版本 MOSN 里面吗？\n A：在开源，内部的做了一些业务相关的扩展。\n3、@Glennxu 提问：\n请问下现在统一限流中心能使用么？\n A：现在开源版本还用不了集群限流，自适应限流的实现也和我们的有一些差异,后面我们会考虑移植到开源版本的。\n4、@朱仕智 提问：\n 今天正好在看 kratos 里面限流的文章，那个限流就是自适应限流，这里提到统一限流中心，这个哪里能看到？\n A：这个短期我们估计不会开源的，主要是这部分功能本身比较简单，而我们内部的规则和开源的模型也有所不同，加上现在我们跟自己的基础设施绑定了，不太方便直接开源。\n5、@魏小亮 提问：\n 是不是简单理解为 MOSN 作为 cpp 的动态库，作为一个插件给 envoy 调用？\n A：可以这么简单认为，对于一般用户的话就是用关心 MOSN 就行了，写 MOSN 的 filter，不需要了解底层机制。就像大家用 openresty，也很少去关心 nginx 和 luajit。\n 我以为要实现一个 envoy 的 filter 需要 c++ 代码来实现。\n A：其实 lua 也可以， 比如用 go 你可以启动一个 zk，然后去调用 envoy 的 xds 做服务发现可以做的事情就很多了。\n6、@茄子 提问：\n请教一下，在使用 rheakv 的过程中出现这个问题要怎么排查?\n A：可以看下 bolt 怎么设置写入的高低水位线，这应该是触发了 netty 的 channel 写入水位线。\ncom.alipay.remoting.config.BoltGenericOption#NETTY_BUFFER_HIGH_WATER_MARK com.alipay.remoting.config.BoltGenericOption#NETTY_BUFFER_LOW_WATER_MARK\n刚才找了下，你看些这个类的 options。\n com.alipay.sofa.jraft.rpc.impl.BoltRaftRpcFactory#CHANNEL_WRITE_BUF_LOW_WATER_MARK com.alipay.sofa.jraft.rpc.impl.BoltRaftRpcFactory#CHANNEL_WRITE_BUF_HIGH_WATER_MARK\njraft 也开放了设置。\n本周发布 SOFABoot 开源发布 3.9.0 版本，\\主要更新如下\\：\n SOFABoot 异常日志添加错误码；\n 去除 AbstractContractDefinitionParser 对 Autowire 注解的使用；\n 为 RPC 服务提供方添加开关，可以不注册到服务注册容器中；\n 添加健康检查进度；\n 去除 SOFARuntimeManager 对 Value 注解的使用；\n 优化 Spring 上下文并行启动的线程池配置。\n 详细参考：\nhttps://github.com/sofastack/sofa-boot/releases/tag/v3.9.0\n**SOFARPC 发布 v5.7.10 版本代码，主要更新如下：\n SOFARPC 支持接口中静态方法的使用；\n 使用 TransmittableThreadLocal 解决 RpcInternalContext 中 ThreadLocal 值传递问题；\n 优化超时时间的获取与校；\n 反序列化过程中正确感知 header 变化；\n 修复 RpcInvokeContext 中线程安全问题；\n 修复 ProviderInfo中getAttr 类型转换问题。\n 详细参考：\nhttps://github.com/sofastack/sofa-rpc/releases/tag/v5.7.10\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1631862000,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210917/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"83215c365789c806399a2ca00fc114e9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210917/","publishdate":"2021-09-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210917/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210917/","wordcount":1344},{"author":"张稀虹","categories":"SOFAStack","content":" 站在风口上 要问近两年最火的技术话题是什么？\nService Mesh 一定不会缺席。\n如果用一句话来解释什么是 Service Mesh。\n可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。*\n对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关心服务之间的那些原本通过服务框架实现的事情，只要交给 Service Mesh 就可以了。\nService Mesh 作为 sidecar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在 Serivce Mesh 中实现，这对于限流熔断而言就是一个天然的流量劫持点。\n如今蚂蚁 80% 以上的应用都已经完成了 Mesh 化，Mesh 统一限流熔断的建设自然是水到渠成了。\n服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。\n在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。\n 相较于传统的限流组件，Mesh 限流具备很多优势，在研发效能和研发成本上都取得了明显的收益：\n- MOSN 架构天然的流量劫持让应用无需逐个接入 SDK\n- 也无需为特定语言开发不同版本的限流组件\n- 限流能力的升级也无需业务同步升级\n「背景业务」\n 在 Mesh 统一限流实现前，蚂蚁集团内部存在多个不同的限流产品，分别提供不同的流量控制策略：\n不同类型的流量（SOFARPC、无线网关 RPC、HTTP、消息等）限流配置分散在不同的平台，由不同的团队维护，产品质量和文档质量参差不齐，学习成本高、使用体验差。\n不同的限流策略需要接入不同的 SDK，引入很多间接依赖，安全漏洞引起的升级频繁，维护成本高。\n不仅在开发建设上存在不必要的人力投入，也给业务方使用造成了困扰和不便。\n另一方面，我们的业务规模越来越大，但大量服务仍在使用最简单的单机限流策略。没有通用的自适应限流、热点限流、精细化限流、集群限流等能力。\n因为限流能力缺失、限流漏配、错误的限流配置等问题引起的故障频发。\nMesh 架构下，sidecar 对流量管理具备天然的优势，业务无需在应用中接入或升级限流组件，中间件也无需针对不同的技术栈开发或维护多个版本的限流组件。\n在目前 Service Mesh 蚂蚁内部大规模接入完成的背景下，将多种不同的限流能力统一收口至 MOSN，将所有限流规则配置统一收口至“统一限流中心”，可以进一步提高 MOSN 的流量管理能力，同时大幅降低业务限流接入及配置成本。\n基于这样的背景下，我们在 MOSN 中进行了统一限流能力建设。\n站在巨人肩膀上 在建设统一限流能力的过程中，我们调研了许多成熟的产品，既包括我们自己的 Guardian、Shiva、都江堰等，也包括开源社区的 concurrency-limits 、Hystrix、Sentinel 等产品。\n我们发现阿里巴巴集团开源的 Sentinel 是其中的集大成者。\n之前我们在打造 Shiva 的过程中也与集团 Sentinel 的同学进行过交流学习，他们也正在积极建设 Golang 版本的 sentinel-golang。\nMOSN 作为一款蚂蚁自研的基于 Golang 技术建设的 Mesh 开源框架，如果搭配上 Sentinel 的强大的流控能力和较为出色的社区影响力，简直是强强联合、如虎添翼、珠联璧合、相得益彰\u0026amp;hellip;啊。\n不过 Sentinel 对于我们而言也并不是开箱即用的，我们并不是完全没有历史包袱的全新业务，必须要考虑到蚂蚁的基础设施和历史限流产品的兼容，经过我们调研发现主要存在几个需要投入建设的点：\n 控制面规则下发需要走蚂蚁的基础设施\n *Sentinel-golang 的单机限流、熔断等逻辑，*和我们之前的产品有较大差异\n 集群限流也要用蚂蚁的基础设施实现\n *Sentinel 自适应限流粒度太粗，*蚂蚁有更加精细化的需求\n 日志采集方案需要调整\n 综合考虑后，我们决定基于 Sentinel 做扩展，站在巨人的肩膀上打造蚂蚁自己的 Mesh 限流能力。\n基于 Sentinel 良好的扩展能力，我们对单机限流、服务熔断、集群限流、自适应限流等都做了蚂蚁自己的实现，也将部分通用的改动反哺到了开源社区，同时配套建设了统一的日志监控报警、统一限流中心。\n 最终我们在 MOSN 里将各种能力都完成了建设，下表展示了 MOSN 限流和其他限流组件的能力对比：\n 奥卡姆剃刀 Pluralitas non est ponenda sine necessitate.\n如无必要，勿增实体\n 一个限流策略就配套一个 SDK 和一个管理后台七零八落，交互体验参差不齐，文档和操作手册质量也良莠不齐，交由不同的团队维护和答疑，如果你全都体验过一遍一定会深恶痛绝。\n而 Mesh 统一限流的核心目的之一就是砍掉这些东西，化繁为简，降低业务同学的学习成本和使用成本，降低我们自己的维护成本。\n- 流量控制的能力全部集成到 MOSN 里，取众家之长，去其糟粕\n- 流量控制的管控台全部收口到统一限流中心\n 这应该是我们造的最后一个限流轮子了吧\n青出于蓝而胜于蓝\n上文提到了我们是站在 Sentinel 的肩膀上实现的 Mesh 统一限流，那我们又做了什么 Sentinel 所不具备的能力呢？\n实际上我们对几乎所有的 Sentinel 提供的限流能力都做了一套自己的实现，其中也有不少的亮点和增强。\n下面分享几个我们的技术亮点。\n自适应限流\n- 对于业务同学而言逐个接口做容量评估和压测回归费时费心，有限的精力只能投入到重点的接口保障上，难免会漏配一些小流量接口的限流。\n- 而负责质量和稳定性保障的同学经常在故障复盘时看到各种漏配限流、错配限流、压测故障、线程阻塞等造成的各种故障。\n我们希望即使在系统漏配错配限流的情况下，在系统资源严重不足时 MOSN 能够精准的找到导致系统资源不足的罪魁祸首，并实时根据系统水位自动调节异常流量。\n在此需求背景下我们实现了一套符合成熟云原生定义的自检测、自调节的限流策略。\n 自适应限流的实现原理并不复杂，朴素的解释就是，触发限流后实时检测系统整体水位，同时秒级按比例调节流量。\n核心逻辑如下：\n- 系统资源检测：秒级检测系统资源占用情况，如果连续超过阈值 N 秒（默认 5 秒）则触发基线计算，同时将压测流量阻断腾挪出资源给线上业务使用；\n- 基线计算：将当前所有的接口统计数据遍历一遍，通过一系列算法找出资源消耗大户，再把这些大户里明显上涨的异常流量找出来，把他们当前的资源占用做个快照存入基线数据中；\n- 基线调节器：将上一步骤存入的基线数据根据实际情况进行调整，根据系统资源检测的结果秒级的调整基线值，仍然超过系统阈值则按比例下调基线值，否则按比例恢复基线值，如此反复；\n- 限流决策：\n系统流量不断经过自适应限流模块，会尝试获取该接口的基线数据，如果没有说明 …","date":1631602800,"description":"技术风口上的限流","dir":"blog/restricted-flow-on-the-technology-windfall/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cb0fcdbcc898f63e21810897fcd0a0d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","publishdate":"2021-09-14T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","summary":"站在风口上 要问近两年最火的技术话题是什么？ Service Mesh 一定不会缺席。 如果用一句话来解释什么是 Service Mesh。 可以将它比作是应用程序或者说微服务间的 TCP","tags":["SOFAStack"],"title":"技术风口上的限流","type":"blog","url":"/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/","wordcount":4850},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA x Erda Meetup#8 成都站，云原生基础设施建设的现在及未来\n 活动时间：2021 年 09 月 11 日（周六）13:30-17:00\n 活动地点：四川省成都市武侯区蚂蚁 C 空间 101 猎户座\n 活动形式：线下活动\n 资料下载： 《从云原生视角，解读 Erda 微服务观测系统的实现》 《Service Mesh落地之后：为 sidecar 注入灵魂》 《技术风口上的限流—蚂蚁集团的 Mesh 限流落地与实践 》 《Erda 关于云原生数据开发平台的思考和实践》\n 活动议程 活动回顾 《从云原生视角，解读 Erda 微服务观测系统的实现》\n嘉宾介绍\n刘浩杨，Erda 微服务和监控团队负责人，主要负责云原生 PaaS 的架构设计、微服务观测治理平台的产品技术规划等工作，对分布式、可观察性、云原生等方向有深入的研究和实践经验。同时也是开源爱好者，Apache SkyWalking PMC 成员，在 Apache SkyWalking 的多语言生态和社区建设中起到重要作用。\n议题简介\n 在云原生架构下，基于 DevOps、微服务、容器化等云原生的能力，可以帮助业务团队快速、持续、可靠和规模化地交付系统，同时也使得系统的复杂度成倍提升，由此带来了前所未有的运维挑战。 在此背景下，对分布式系统的“可观测性”应运而生，可观察性提供了一套理念来监控、诊断云原生应用系统。和监控相比，可观察性从单一的度量扩展为 Metrics、Tracing、Logging 三大支柱，Erda MSP (MicroService Platform) 中的 APM 系统也在逐渐演进为以可观察性分析诊断为核心的微服务观测平台，本次主题将会解读 Erda 对微服务观测系统的探索和实践。 听众收获\n可快速了解监控和可观测性技术的发展历程，了解云原生场景下可观测性的痛点和解决方案，及获取 Erda 微服务观测平台的功能特性。\n《Service Mesh落地之后：为 sidecar 注入灵魂》\n嘉宾介绍\n周群力（花名：仪式），开源爱好者, co-founder of Layotto，Dapr contributor。目前在蚂蚁中间件团队工作，对SOFAStack和MOSN的开源影响力负责。虽然工作是做云原生基础设施，但业余时间也喜欢折腾前端和数据。\n议题简介\n 随着Service Mesh在蚂蚁集团内部的大规模落地，我们逐渐遇到了新的挑战，这让我们迫切的寻找新的解决方案。 Service Mesh通过引入sidecar来简化服务治理，但是随着探索实践，我们发现 sidecar 能做的事情远不止于此。一方面，给 sidecar 添加 Multi-Runtime 能力可以帮助基础设施团队更好的和业务团队解耦，简化多语言治理；另一方面，中立的 Runtime API 可以抽象基础设施、简化编程，帮助 K8s 生态成为真正的“分布式操作系统”，也帮助应用彻底和厂商解绑，保证多云环境的可移植性；与此同时，在 WebAssembly 日益火爆的当下，WASM 也能帮助 sidecar 实现 FaaS、业务系统 sdk 下沉等功能。 那么，Service Mesh落地之后，架构演进的思路是什么？我们的思路是：为sidecar注入灵魂。 听众收获\n 了解蚂蚁集团在Service Mesh大规模落地以后遇到的新问题以及对于如何解决这些问题的思考。 了解Multi-Runtime解决的问题及实践经验。 了解中立的Runtime API解决什么问题，以及相关实践经验 了解WASM在FaaS等方向的探索。 《技术风口上的限流—蚂蚁集团的 Mesh 限流落地与实践 》\n嘉宾介绍\n张稀虹，蚂蚁集团技术专家，专注于云原生相关技术在业务生产中的落地与实践，开源项目 MOSN 核心成员，目前关注云原生 ServiceMesh、Serverless 等相关领域。\n议题简介\n ServiceMesh 可谓是站在风口上的技术热点，流量控制正是 Mesh 架构下的核心功能。Mesh 的架构优势使得业务可以更低成本的使用上通用的限流熔断能力，本次分享为大家介绍蚂蚁集团的 Mesh 限流能力的建设以及业务落地推广的实践经验。 听众收获\n 了解 Mesh 架构下的限流熔断技术优势 分享蚂蚁集团 Mesh 限流熔断能力建设经验 拓宽思路了解限流熔断未来的探索方向 《Erda 关于云原生数据开发平台的思考和实践》\n嘉宾介绍\n侯璐瑶，高级技术专家，Erda 数据团队负责人，主要负责基于云原生的数据平台的架构设计、负责数据应用产品架构和产品演进，对于大数据领域数据组件和数据应用等方向有比较深入的研究和实践经验。\n议题简介\n 数据 on 云原生是必然的路径，云原生对于数据平台带来了比传统平台更容易的扩展性和便捷性。本次分享主要介绍 Erda 数据开发平台在云原生上的建设和实战经验。 听众收获\n 了解云原生的整体数据架构； 分享 Erda 的落地实践经验。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；\n或微信扫码关注“金融级分布式架构”微信公众号👇\n ","date":1631343600,"description":"【活动回顾】SOFAMeetup#8 成都站 云原生基础设施建设的现在及未来","dir":"activities/sofa-meetup-10/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"270d57821d3a01ac4bc85082d157f6d9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-10/","publishdate":"2021-09-11T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-10/","summary":"概要 活动主题：SOFA x Erda Meetup#8 成都站，云原生基础设施建设的现在及未来 活动时间：2021 年 09 月 11 日（周六）13:30-17:00 活动地点：四川省","tags":["SOFAMeetup"],"title":"【活动回顾】SOFAMeetup#8 成都站 云原生基础设施建设的现在及未来","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-10/","wordcount":1791},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@胡希国 提问：\n 这个 start 函数在父进程执行完 WaitConnectionsDone()之后在哪调用的，新的子进程在迁移长连接的时候监听 conn.sock 等着老进程调 startRWloop 去连接和发送 connfd，看源码一直到 WaitConnectionsDone() 就断了，实在没找到接下来在哪执行的 ReadLoop 和 WriteLoop。\n https://github.com/mosn/mosn/blob/0ea3e3b4b2abfde2a845edc006a3e866ff0b1201/pkg/network/connection.go#L186\nA：迁移连接之后，创建连接最后就会 start 了。\n 2、@胡希国 提问：\n 父进程的每个长连接 connection fd 里面都有一个 readloop 逻辑是吗？一旦 WaitConnectionsDone() 触发了 stopchan 那个条件，就自动做迁移了是吧。\n A：是的，每个连接都有 readloop 的， WaitConnectionsDone 就是等他们迁移完。\nhttps://mosn.io/docs/concept/smooth-upgrade/\n这篇文章里面有写的。\n 3、@汪晓涛 提问：\n 镜像地址有吗？可以对接 dapr 吗？\n A：目前是七层扩展哈，对接 dapr 是四层，这个月底应该就可以支持了。\nhttps://github.com/mosn/mosn/issues/1563\n4、@徐泽唯 提问：\n 大佬帮我看下这是什么问题？xid in change during RPC from 192.168.2.115:8091:178170994535436288 to null。\n A：不影响，直接升级最新的 spring-cloud-starter-alibaba-seata 和最新的 seata-all 或者 seata-spring-boot-starter 即可，只是一个日志警告。\n5、@北京jht 提问：\n 如果想了解一下这个组件对系统带来的开销和性能，可能会出现在哪个问题上。\n A：没有实际的业务场景，结果出入比较大。RPC 开销应该是最大的消耗。\n 咱们这个 Seata-Server 的回查和提交都是异步的吧，会对 RPC 本身的耗时产生影响吗？\n A：你算 RPC 一次 1ms tm begin 1ms rmregisty 1ms 如果有 3 个 rm，就是 4ms。然后 tm 决议发给 tc，5ms。如果是 tcc，那么就是 5ms + tc 下发到 3 个 rm 执行，rm 执行二阶段业务也要时间。\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1631257200,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210910/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e29e1740eb32b19f715b92a21a2dfd02","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210910/","publishdate":"2021-09-10T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210910/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210910/","wordcount":907},{"author":"向万鹏","categories":"SOFAStack","content":" AntMonitor简介 AntMonitor 是蚂蚁集团的智能监控系统，通过构建面向监控可观测数据的、实时的、稳定的采集、清洗、计算及存储数据链路，为技术风险大脑及体系提供实时、稳定、可靠、丰富的可观测数据与告警服务。\nAntMonitor 日常服务于蚂蚁全站 100+ 业务域，分钟峰值数据清洗量 20TB、数据聚合量 1TB、数据存储量 1.5 亿条，大促期间这些指标更是成倍增长，如此庞大且复杂的系统是如何对自身的稳定性进行保障的，这篇文章将从思考、策略与实现的角度带领大家一探究竟。\n系统构架 系统架构上，AntMonitor 可以分为产品、告警、计算和存储等四个子系统，各个子系统可以独立提供服务，又相互协调配合，承担起了蚂蚁技术风险的数据底盘角色。\n 产品系统 产品系统直接为用户提供各项可视化服务，包括 monitormeta 和 monitorprod 两个组件。\n monitormeta 负责元数据的管理与同步，例如计算配置、告警规则以及各类运维元数据等；\n monitorprod 为产品中台核心服务，对外提供数据服务；对内支持数据模型定义，数据模型抽象，数据模型转换等能力。\n 计算系统 计算系统提供一体化的数据采集、清洗、聚合与数据生命周期管理服务。计算系统内组件较多，可以分为服务层、计算层和采集层进行介绍。\n一、服务层\n tableapi 对外提供标准的数据服务接口；\n dimservice 为列式的元数据缓存服务中心。\n 二、计算层\n global-scheduler（gs） 为全局任务调度组件，负责对注册过来的 compute-space 计算集群进行生命周期管理，并基于配置生成任务拓扑，随后投递到计算集群。\n compute-space（cspace） 为一个抽象的计算能力资源池，负责对gs投递过来的任务拓扑进行解析执行以产出数据，写入存储系统，并将任务状态反馈给 gs ，cspace 并不与具体的数据计算资源池绑定，底层的实现可以是任意计算引擎。当前，一个 cspace 节点的实现为一个 spark 集群。\n三、采集层\n gaea-registry为整个采集侧的管控中心，它将采集配置下发给 agent 和 vessel ，同时也负责维护所有 agent 和 vessel 的健康状态与路由信息等。\n agent为部署在物理机上的采集服务进程，负责对日志、系统指标、事件等原始数据进行读取。\n vessel为数据清洗集群，负责拉群 agent 采集的原始数据进行结构化清洗，并以 rpc 形式返回给 cspace 。\n 告警系统 告警系统基于用户配置的告警规则对计算产出的指标数据进行巡检，产出告警事件并推送给订阅者。告警系统的组件与计算系统有些类似，包括：\n alarm-global-scheduler（alarm-gs）为告警调度组件；\n alarm-compute-space（alarm-cspace）为告警计算资源池；\n alarm-gateway 为告警推送网关。\n 如果将告警系统和计算系统进行类比的话，可以抽象地认为：告警的输入不是采集，而是计算系统产出的数据；告警的输出也不是存储系统，而是告警通知网关 alarm-gateway 。\n存储系统 存储系统（ceresdb）为 AntMonitor 提供时序数据的读写服务。\n ceresdbconsole 为可视化的运维管控组件；\n ceresmeta 为元数据管理组件，负责存储集群的主备切换、扩缩容等协调工作；\n ceresproxy 与 ceresbase 为部署在同一个容器内的两个伴随进程，其中 ceresproxy 为路由层，负责对查询或写入的数据进行汇总，并将结果返回给客户端，同时提供租户校验、流控、黑名单等能力；ceresbase 为数据存储节点，负责时序数据的存储、索引维护等功能。\n 稳定性建设 监控系统在整个蚂蚁的体系架构内是一个特殊的角色，它在承载所有业务系统的可观测与告警能力的同时，还为容量、自愈、故障应急等技术风险其他子域提供着数据服务。\n因此，监控对自身的稳定性要求更加严苛，在诸如大规模宕机、机房网络中断或更极端情况下，监控也需要保障自身是可以稳定运行的。\n针对蚂蚁智能监控自身的稳定性建设，我们主要从两方面进行推进，包括稳定性架构的设计与运行时的稳定性保障，整体如下图所示。\n 稳定性架构 稳定性架构是建设稳定性中最重要的一环，一个经过缜密设计的稳定性架构，可以使我们后期尽可能优雅从容地处理各类稳定性问题，而不是疲于奔命地打地鼠。\n具体来说，在设计稳定性架构之初，我们首先应该意识到系统的运行时环境和输入都不会是稳定的。\n运行时环境的不稳定 ，主要体现在机器的故障宕机、网络的抖动，或者更极端的机房光纤被挖断、城市自然灾害等客观因素影响。处理这类问题通常从两方面出发：\n第一、尽可能地提升系统的容灾等级。\n例如单点、机房级容灾、城市级容灾等，以最基础的去单点来说，我们需要保证所有的调度或同步类节点（例如 monitormeta、gs）都是基于主备架构的，所有的服务类节点（例如 monitorprod、tableapi）都是无状态的，所有的分片节点（例如 gaea-registry、ceresbase）都是存在冗余副本的，所有的工作类节点（例如 cspace、alarm-cspace），宕机后也都是可以自行恢复的。\n第二、所有的数据处理流程都应该面向失败进行设计。\n因为当故障发生后，可能某几个周期的任务已经失败，这时候需要有能力驱动这些任务进行重试，例如 cspace 需要有能力对某一个计算任务的采集失败进行容忍和重试、alarm-gs 需要对告警任务的执行失败进行重新调度等。\n针对系统输入的不确定性 ，我们也分两种情况进行处理：\n第一种情况是入口数据的错乱。\n例如脏配置、脏元数据、不合法的数据类型等，错误的数据流入系统可能会导致不可预期的行为，针对此类问题，我们通常需要在入口处进行校验，拒绝非预期的数据流入系统。\n第二种情况是入口数据量级管控。\n任何系统，其性能都是和容量挂钩的，其设计也都是在一定的性能容量平衡假设下进行的。监控系统的输入通常是业务日志，而且监控配置的定义是直面用户的，那么很可能一个随意定义的配置将导致海量的服务调用明细日志流入监控系统，导致集群崩溃，所以对流量的限制与管控非常重要。在 AntMonitor 中，各个关键的入口例如采集入口、计算入口、存储入口、数据查询入口等都有严格的流量管控校验规则，确保监控系统在预期容量下能够稳定运行，而不会被突发的流量所压垮。\n综上，我们将重点从容灾架构和架构单元化两方面出发来阐述 AntMonitor 稳定性架构的设计思路。\n容灾架构 前文简要提及了架构去单点问题的解决思路，这足以覆盖日常可能发生的节点宕机、网络抖动等小规模故障场景，但是当真正的毁灭性灾难来临时，还需要更高层面的容灾方案来应对。\n目前基于不同租户保障等级的区分以及资源配额等客观因素的权衡，AntMonitor 实施了两套不同等级的容灾策略，即针对常规业务域租户的机房级容灾和针对高保业务域租户的城市级容灾。\n机房级容灾 对于常规的业务域租 …","date":1630998000,"description":"蚂蚁智能监控","dir":"blog/ant-intelligent-monitoring/","fuzzywordcount":6700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3529d1b46b4e16c43414a1cd3e89fb02","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-intelligent-monitoring/","publishdate":"2021-09-07T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/ant-intelligent-monitoring/","summary":"AntMonitor简介 AntMonitor 是蚂蚁集团的智能监控系统，通过构建面向监控可观测数据的、实时的、稳定的采集、清洗、计算及存储数据链路，为技术风险大","tags":["SOFAStack"],"title":"蚂蚁智能监控","type":"blog","url":"/sofastack.tech/blog/ant-intelligent-monitoring/","wordcount":6622},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过\n\u0026amp;ldquo;SOFA WEEKLY\u0026amp;rdquo; 的形式回复\n1、@黄润良 提问：\n 在写 filter 扩展的时候，如何获取一些请求的信息？比如请求 ip 之类的。\n A：*pkg/server/handler.go*，这里面可以看到设置进去的。\n MOSN：https://github.com/mosn/mosn\n2、@黄润良 提问：\n 一些 filter 只能用于某些协议的，但从配置来看，filter 应该是对所有协议都生效的吧？那我在设计 filter 的是需要考虑协议的兼容性吗？\n A：你配置的 listener 块里面有协议，就可以和 filter 对应上了。\n如果你怕别人误用，可以简单处理绕过。比如 dubbofilter 就是 Dubbo 协议自有的，怕其他协议误配置了，可以在代码跳过。\n MOSN：https://github.com/mosn/mosn\n3、@黄润良 提问：\n 目前有方法可以控制 filter 的执行的先后顺序吗？\n A：按照配置的顺序。\n 4、@楼政浩 提问： 往 raft 集群提交数据，都得通过 RPC 吗？ 如果我的 raft 节点的 fsm 又输出了 log，我想往集群提交这个 log，可以通过什么接口？\n A：jraft 通过 raft log 将数据复制到你各个节点的 fsm，fsm 的输入数据全部来自 raft log，你说的 fsm 又输出了 log 如果我没理解错的话，就是说本质上 fsm log 的输入全部来自 raft log，那么你这个所谓 log 就存在你自己的 fsm 就行，本来就是每个节点都会有的，不要再提交。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n5、@陈华洋 提问：\n SOFABoot 的模块化是怎么解决数据库链接的问题。 就是 SOFABoot 模块化之后，我把 mybatis 配置到了公共模块里面，然后其他模块父上下文指定为公共模块，但是其他模块内的 @Mapper 在项目启动的时候都扫描不到。\n A：建议把所有数据库相关的操作都放同一个模块，封装成 dal 层。可以配一个配置,让一个 spring 上下文里的 bean 暴露出来、能给别的 Spring 上下文用。\nSOFABoot：https://github.com/sofastack/sofa-boot\n6、@Z 提问：\n 请问在大数据量操作的时候，配置上有什么建议吗？\n A：把 6000 多条数据的操作在一个本地事务中完成，合并成一个分支注册。\nSeata：https://github.com/seata/seata\n7、@金箍 提问：\n 请问全局事务提交成功或者失败之后，有回调方法可以用吗？\n A：tm 有个 hook，其他没有。源码搜索「transactionlHook」有相关的文档。\nSeata：https://github.com/seata/seata\n8、@仪式 提问：\n 如果事务进行的过程中事务发起者（TM）宕机了，Seata 会怎么做故障处理呀。\n A：超时回滚，如果 TM 是决议提交给了 TC，那么“是”提交，“否”就只能等待超时回滚。TC 里的定时任务来做超时回滚。\nSeata：https://github.com/seata/seata\nSOFAStack \u0026amp;amp; MOSN：新手任务计划\n作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nSOFA-Boot\n设计实现一个新的配置项，用于判断 SOFA-Boot 是否由 IDE 启动。\nhttps://github.com/sofastack/sofa-boot/issues/861\nLayotto\n减少 panic 风险，给所有创建新协程的代码加上 recover。 设计实现 actuator metrics API，用于统计、展示 metrics 指标 WASM 通过 State API 访问存储：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n","date":1630652400,"description":"SOFA WEEKLY | QA 整理，新手计划","dir":"blog/sofa-weekly-20210903/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b8e03b60dc613f8a724cc3f95441bc2e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210903/","publishdate":"2021-09-03T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210903/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理，新手计划","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210903/","wordcount":1569},{"author":"SOFA 团队","categories":"SOFAStack","content":" 真的吗？真的吗？\nSOFA 志愿者开始招募啦？\n直视他！直视他！\nSOFA 星球在等你加入呀！\n我们正式启动“SOFA 星途者”计划\n只差一个你 即可成团出道\n不要感觉成团困难\n只要我们一起就能所向披靡\n谁是SOFA“星途者” SOFA 星途者是一群对开源宇宙感兴趣，希望在这片“宇宙”其中探索到更多“星辰”的人。SOFA 星途者们能够为千千万万的开发者们，提供丰富的 Meetup 及线上直播等交流平台。\n现在面向一切有理想、有追求的你们进行招募。\n“星”字代表 SOFA 星球，“途”代表在开源宇宙的征途。所以“星途”的意思即 SOFA 星球在开源宇宙的探索与征途。\n那么“星途者”就是加入 SOFA 星球的你们，让我们一起在开源宇宙中驰骋探索。\n“SOFA 星途者，探索开源宇宙中的星辰大海”\n即将进入，SOFA 社区 SOFAStack™（Scalable Open Financial Architecture Stack）是一套用于快速构建金融级云原生架构的中间件，也是在金融场景里锤炼出来的最佳实践，并且具备以下特点：\n开放：技术栈全面开源共建、 保持社区中立、兼容社区、兼容开源生态，组件可插拔， SOFAStack 组件与其它开源组件可相互集成或替换。\n金融级：包含构建金融级云原生架构所需的各个组件，让用户更加专注于业务开发，满足用户场景的现状和未来需求，经历过大规模场景的锤炼，特别是严苛的金融场景。\n云原生：基于 SOFAStack 可快速搭建云原生微服务体系，快速开发更具可靠性和扩展性、更加易于维护的云原生应用。\n开启 SOFA 征途 SOFA 陆续在全国各地组织了多场 Meetup 活动，活动全程直播，线上线下参与人数累计破万。Meetup 为 SOFA 星途者提供面对面沟通探讨的机会，收到了业界人士的一致好评。\n目前在北京、上海、杭州、合肥举办过 Meetup 活动，后续的还会点亮更多城市（成都、深圳、广州、南京等），欢迎你作为 SOFA 星途者加入我们的征途。\n杭州站\n 上海站\n 北京站\n 合肥站\n 召唤装备！ 在 SOFA 星球，大家不仅能够与每个领域的技术大牛面对面交流技术、认识新朋友，更能够收获 SOFA 星途者的周边衣服、杯子、双肩包等……\n最重要的是可以收获 SOFA 社区颁发的专属证书。\nSOFA 星途者的成员在参加 SOFA 的活动时可享受 VIP 通道，也会获得一些特大活动的 VIP 门票赠送～\n如果你是大学生“星途者”，那么你有可能会获得互联网大厂的实习推荐机会，在你感兴趣的星辰领域继续探索成长，有机会获得更多的学习机会。\n想成为一名“星途者”需要做些什么？\n扫描下方二维码\n 勇敢迈出成为“星途者”的第一步\n剩下的九十九步\n我们一起走\n","date":1630393200,"description":"SOFA 星球招募啦～","dir":"blog/sofa-star-is-recruiting/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d889b6b480fa6731f51805443e5ca5db","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-star-is-recruiting/","publishdate":"2021-08-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-star-is-recruiting/","summary":"真的吗？真的吗？ SOFA 志愿者开始招募啦？ 直视他！直视他！ SOFA 星球在等你加入呀！ 我们正式启动“SOFA 星途者”计划 只差一个你 即可成团出道 不要感觉成团","tags":["SOFAStack"],"title":"SOFA 星球招募啦～","type":"blog","url":"/sofastack.tech/blog/sofa-star-is-recruiting/","wordcount":960},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@胡希国 提问：\n 想和大家请教一下 MOSN 的热升级方案，就是我看到 MOSN 也是通过接收到 hup 信号然后 fork 的方式生成的一个新的子进程，（确切来说是 forkexec），和 Envoy 的解决方案应该是相同的，那为什么说和 Nginx 不一样呢？这种也是存在父子进程关系的吧（我看到 Envoy 是存在的），那为什么说没有继承 listenerfd 而需要通过 uds 来传递呢？\n A：Nginx reload 的过程是 master 不会退出，只是新 fork 了子进程。MOSN 是先启动一个 MOSN 进程，然后通过 socket 把 fd 继承过去之后，老的 MOSN 会退出。\nMOSN：https://github.com/mosn/mosn\n2、@鹏程万里 提问：\n FailureHandler 怎么实现自定义类呢？需要做回滚失败的通知。\n A：自己创建一个 Failurehandler bean return 一个实现类。\nSeata：https://github.com/seata/seata\n3、@随风 提问：\n 请问下，如果 A 方法和 B 方法上都有注解 GlobalTransactional，那么 A 方法可以直接调用 B 方法吗？\n A：可以的，用的还是一个 xid。\nSeata：https://github.com/seata/seata\n4、@zero 提问：\n 有分布式数据库了还需要用 Seata 吗？\n A：分布式数据库解决的是单个 connection 中每个 SQL 请求到了不同的库上的事务。一个分布式数据库背后可能有 N 个数据库被操作，内部用 xa 保证了事务。\nSeata：https://github.com/seata/seata\n本周发布 本周 SOFAJRaft 发布 1.3.8v版本。主要更新如下：\n Snapshot 支持并行压缩/解压缩，充分利用多核，加速在 snapshot 较大的时的 load 和 save 速度；\n CliService 提供 learner 到 follower 的转换 API；\n 修复 install snapshot retry 失败的 bug；\n 修复 RheaKV 在成员发生变更时没有刷新路由表的 bug。\n 详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.8\n新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing ！\nSOFA-Boot\n 发布服务时 增加 interfaceType 校验；\n 增加 SOFATracer 插件。\n 详见：\nhttps://github.com/sofastack/sofa-boot/issues/841\nLayotto\n 选择喜欢的组件实现分布式锁和分布式自增 id；\n 让 Layotto 能够简单方便的部署在 Kubernetes 上；\n 提供 Dockerfile，以便用户用 docker 部署 Layotto 。\n 详见：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 2021 年云原生技术发展现状及未来趋势\n 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1629442800,"description":"SOFA WEEKLY | SOFAJRaft 发布新版本,QA 整理","dir":"blog/sofa-weekly-20210820/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"60274ff33263cdb109e3d4342c35a45a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210820/","publishdate":"2021-08-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210820/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本,QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210820/","wordcount":1223},{"author":"泡椒","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#21：走进下一代互联网：HTTP/3\n 活动时间：08月18日,周三晚19点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#21：走进下一代互联网：HTTP/3 近年来，具备优秀基因的 QUIC 协议成为互联网领域炙手可热的传输技术。基于 QUIC 承载的 HTTP/2 也被正式命名为下一代传输协议： HTTP/3。这次直播会给大家介绍 QUIC，HTTP/3 的核心设计理念，以及在蚂蚁的应用实践。​\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 孔令涛（花名：伯琴） 蚂蚁集团技术专家，主要从事四七层协议优化，网关开发等工作。 议程 19:00-19:05 主持人开场 小助手-泡椒 主持人\n19:05-20:00 用安全计算保护关键业务 伯琴 蚂蚁集团技术专家，主要从事四七层协议优化，网关开发等工作。\n你将收获 你将了解 QUIC/HTTP/3 协议的前世今生、优良特性、落地实践、普及情况、与未来发展趋势等。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1629270000,"description":"8 月 18 日周三晚 19 点，线上直播第 21 期。","dir":"activities/sofa-channel-21-1/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b77dae9fff7d781959845f53872d0eee","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-21-1/","publishdate":"2021-08-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-21-1/","summary":"概要 活动主题：SOFAChannel#21：走进下一代互联网：HTTP/3 活动时间：08月18日,周三晚19点 活动形式：线上直播 资料下载：戳","tags":["SOFAChannel","HTTP/3"],"title":"SOFAChannel#21：走进下一代互联网：HTTP/3","type":"activities","url":"/sofastack.tech/activities/sofa-channel-21-1/","wordcount":588},{"author":"于雨","categories":"SOFAStack","content":" 个人有幸担任了 2021 年 GIAC 会议云原生专场的出品人兼讲师，组织了前后四个场子的演讲，在这个过程中个人同时作为听众从这些同行的演讲中学到了很多非常有用的知识。本文算是对 2021 GIAC 云原生专场的侧记，管中窥豹，以观 2021 年云原生技术发展现状及未来一段时间内的趋势。\n 云原生这个词含义广泛，涉及到资源的高效利用、交付、部署及运维等方方面面。从系统层次分可以区分出云原生基础设置【如存储、网络、管理平台 K8s】、云原生中间件、云原生应用架构以及云原生交付运维体系，本次专场的四个议题也基本涵盖了这四大方向：\n 亚马逊的资深技术专家黄帅的 《一个云原生服务的爆炸半径治理》 快手基础架构中心服务网格负责人姜涛的 《快手中间件 Mesh 化实践》 Tetrate 可观测性工程师柯振旭的 《使用 SkyWalking 监控 Kubernetes 事件》 本人以 Dubbogo 社区负责人出品的《Dubbogo 3.0：Dubbo 在云原生时代的基石》 下面根据个人现场笔记以及个人回忆分别记述各个议题的要点。因时间以及本人能力有限，一些错误难免，还请行家多多指正。\n云原生服务的爆炸半径 个人理解，黄的这个议题属于云原生应用架构范畴。\n其演讲内容首先从亚马逊 AWS 十年前的一个故障说开：AWS 某服务的配置中心是一个 CP 系统，一次人为的网络变更导致配置中心的冗余备份节点被打垮，当运维人员紧急恢复变更后，由于配置中心不可用【有效副本数少于一半】导致了整个存储系统其他数据节点认为配置数据一致性不正确拒绝服务，最终导致整个系统服务崩溃。\n复盘整个事故的直接原因是：CAP 定理对可用性和一致性的定义限定非常严格，并不适合应用于实际的生产系统。因此作为线上控制面的配置中心的数据应该在保证最终一致性的前提下，首先保证可用性。\n更进一步，现代分布式系统的人为操作错误、网络异常、软件 Bug、网络/存储/计算资源耗尽等都是不可避免的，分布式时代的设计人员一般都是通过各种冗余【如多存储分区、多服务副本】手段保证系统的可靠性，在不可靠的软硬件体系之上构建可靠的服务。\n但是这中间有一个误区：有时候一些冗余手段可能因为雪崩效应反而会导致系统可靠性地降低。如上面的事故，人为的配置错误导致了一连串的软件体系故障，且这些故障之间是高度强相关的，最终导致了雪崩效应，可以称之为 “水平扩展的毒药效应”。此时思考的维度就从 “在不可靠软硬件体系上提供可靠服务” 进一步拓展为 “通过各种隔离手段减小事故的爆炸半径”：当不可避免的故障发生时，尽量把故障损失控制到最小，保障在可接受范围内，保证服务可用。\n针对这个思路，黄给出了如下故障隔离手段：\n 服务粒度适中 微服务的服务粒度并不是拆分的越细越好。如果服务粒度过细，会导致服务数量过多，其第一个后果就是导致一个组织内几乎无人能搞清楚服务整体逻辑的来龙去脉，增加维护人员的负担：大家只敢小修小补无人敢做出大幅度的优化改进。\n服务粒度过细的第二个后果是造成整体微服务单元体指数级增加，造成容器编排部署成本上升。适中的服务粒度要兼顾架构体系的进化与部署成本的降低。\n 充分隔离 进行服务编排时，获取数据中心的电源和网络拓扑信息，保证强相关系统之间部署做到 “不远” 且 “不近”。\n“不近”是指同一个服务的副本不在使用同一个电源的同一个机柜部署，也不在使用了同一个网络平面的 Azone 内部署。“不远” 是指部署距离不能太远，例如多副本可以同城多 IDC 部署。使用这两个原则兼顾性能与系统可靠性。\n 随机分区 、所谓的随机分区这块，其实质就是在混合服务请求，保证某个服务的请求可以走多通道【队列】，保证在某些通道挂掉的情况下不影响某个服务的请求处理，应用随机分区技术，将用户打散在多个 Cell 中，大幅度降低爆炸半径。\n与 K8s APF 公平限流算法中的洗牌分片（Shuffle Sharding）颇为相似。\n 混沌工程 通过持续内化的混沌工程实践，提前踩雷，尽量减少 “故障点”，提升系统可靠性。\n使用 SkyWalking 监控 Kubernetes 事件 这个议题虽然被安排在第三场演讲，属于云原生交付运维体系，但是与上个议题关联性比较强，所以先在此记述。\n如何提升 K8s 系统的可观测性，一直是各大云平台的中心技术难题。K8s 系统可观测性的基础数据是 K8s event，这些事件包含了 Pod 等资源从请求到调度以及资源分配的全链路信息。\n SkyWalking 提供了 logging/metrics/tracing 等多维度可观测性能力，原来只是被用于观测微服务系统，今年提供了 skywalking-kubernetes-event-exporter 接口，专门用于监听 K8s 的 event，对事件进行提纯、收集、发送至 SkyWalking 后端进行分析和存储。\n 柯同学在演讲过程中花费了相当多的精力演讲整个系统的可视化效果如何丰富，个人感兴趣的点如下图所示：以类似于大数据流式编程的手段对 event 进行过滤分析。\n 其可视化效果与流式分析手段都是蚂蚁 Kubernetes 平台可借鉴的。\n快手中间件mesh化实践 快手的姜涛在这个议题中主要讲解了快手 Service Mesh 技术的实践。\n 姜把 Service Mesh 分为三个世代。其实划分标准有很多，如何划分都有道理。很明显，姜把 Dapr 划入了第三个世代。\n 上图是快手的 Service Mesh 架构图，很明显借鉴了 Dapr 的思想：下沉基础组件的能力到数据平面，把请求协议和接口标准化。一些具体的工作有：\n 1 统一运维，提高可观测性与稳定性，进行故障注入和流量录制等 2 对 Enovy 等做了二次开发，只传输变更的数据、按需获取，解决单实例服务数过多的问题 3 对协议栈和序列化协议做了大量的优化 4 实施了面向失败设计，Service Mesh 可以 fallback 为直连模式 个人感兴趣的是姜提到了 Service Mesh 技术在快手落地时面临的三个挑战：\n 成本问题：复杂环境下的统一部署与运维。 复杂度问题：规模大、性能要求高、策略复杂。 落地推广：对业务来说不是强需求。 特别是第三个挑战，Service Mesh 一般的直接收益方不在业务端，而是基础架构团队，所以对业务不是强需求，而且快手这种实时业务平台对性能非常敏感，Service Mesh 技术又不可避免地带来了延迟的增加。\n为了推动 Service Mesh 技术的落地，快手的解决手段是：\n 1 首先务必保证系统稳定性，不急于铺开业务量； 2 搭车公司重大项目，积极参与业务架构升级； 3 基于 WASM 扩展性，与业务共建； 4 选取典型落地场景，树立标杆项目。 姜在最后给出了快手下半年的 Service Mesh 工作：\n 很显然这个路线也是深受 Dapr 影响，理论或者架构上创新性不大，更侧重于对开源产品进行标准化并在快手落地。\n在演讲中姜提到了 Serivce Mesh 技术落地的两个标杆：蚂蚁集团和字节跳动。其实他们成功的很重要原因之一就是高层对先进技术的重视以及业务侧的大力配合。 …","date":1629183600,"description":"2021 年云原生技术发展现状及未来趋势","dir":"blog/2021-cloud-native-technology-development-status-and-future-trends/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ee44d71749f600f689656893c5b607af","permalink":"https://sofastack.github.io/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","publishdate":"2021-08-17T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","summary":"个人有幸担任了 2021 年 GIAC 会议云原生专场的出品人兼讲师，组织了前后四个场子的演讲，在这个过程中个人同时作为听众从这些同行的演讲中学到了很多非常有用","tags":["SOFAStack"],"title":"2021 年云原生技术发展现状及未来趋势","type":"blog","url":"/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/","wordcount":3976},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙运盛 提问：\n 我想咨询大家一个问题，假如二阶段提交或者回滚的方法里，再发生异常的话，应该如何处理呢？\n A：这个异常后，重新捞取之前没结束的事务，重试就可以了吧，二阶段反正已经不阻塞其它一阶段的流程了。\nSeata：https://github.com/seata/seata\n2、@胡希国 提问：\n 我想请教一个问题，这里 New MOSN 收到 Old MOSN 传来的监听文件描述符之后，利用 filelistener 函数产生一个 listener 的作用是和 bind 一样么？就在 New MOSN 上开始监听了是吗？那这时候 Old MOSN 不也同时在监听么，这里的内部逻辑是什么样的？\n A：跟 bind 不一样，这儿是同一个 fd，两个进程都监听，常规操作。你可以想象成 Nginx 的多个进程都可以监听一个 listen 一样。\nMOSN：https://github.com/mosn/mosn\n3、@胡希国 提问：\n MOSN 的 forkexec 是个怎么样的方式呢？它也和 Envoy 一样有一个独立的 python（envoy）进程来负责产生新的 MOSN 进程么？\n A：MOSN 启动起来之后检查到有 socket 文件，然后和 Old MOSN 通信继承 fd，继承完了通知 Old MOSN 退出，所以你可以直接启动一个 MOSN 来。\nMOSN：https://github.com/mosn/mosn\n4、@胡希国 提问：\n 想请问下 MOSN 实现的过程为什么没有采用直接 fork 父进程的方式呢？\n A：容器间升级是不能 fork 的。\nMOSN：https://github.com/mosn/mosn\n5、@ch 提问：\n 今天发生了一个 rollback status: TimeoutRollbacking 超时问题。 描述: Seata 提示 rollback status: TimeoutRollbacking。 出现原因：全局事务在执行 order 库和 account 库，因为 account 库被 IO 堵死 导致业务超时执行了 70s。 然后 Seata 就报 timeout 导致 order 库回滚了数据 account 没有回滚数据（account 已经被 IO 流撑死,无法读写数据）。 版本：client 1.3.0 server 1.3.0。\n A：account 没有回滚诗句，tc 会重试。回滚事务，只要注册了的事务就一定能回滚，没注册的本地事务就会回滚，所以其实没有任何问题。\nSeata：https://github.com/seata/seata\nSOFAStack \u0026amp;amp; MOSN：新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发，但是不知道从何下手“的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing！\nLayotto 新手任务：\n 支持运行多个 Wasm 模块，以便让 Layotto 成为 FaaS 容器；\n 提供 Dockerfile，以便用户用 docker 部署 Layotto；\n 看懂 Wasm 模块的实现并为 Wasm 模块编写单元测试。\n 详见 ：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\n本周推荐阅读 蚂蚁集团 SOFATracer 原理与实践\n KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1628838000,"description":"SOFA Weekly | SOFAStack \u0026 MOSN：新手任务计划，QA 整理","dir":"blog/sofa-weekly-20210813/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"84929b0bd678bf23739507e3920d0293","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210813/","publishdate":"2021-08-13T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210813/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAStack \u0026 MOSN：新手任务计划，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210813/","wordcount":1357},{"author":"郑志雄（纶珥）","categories":"SOFAStack","content":" 背景 微服务架构带来很多好处的同时也让系统的复杂度提升了，传统的单体应用按照不同的维度拆分成一个一个分布式微服务，不同的微服务甚至可能采用不同的语言编写；此外，服务的部署往往都是分布式的，可能有几千台服务器，横跨多个不同的城市数据中心。下图是一个典型的微服务架构，图中的节点数还比较少，在支付宝，一个线下支付整体交易付款链路，涉及上百个节点。\n 图片来源：https://www.splunk.com/en_us/data-insider/what-is-distributed-tracing.html#benefits-of-distributed-tracing\n微服务化引入了以下几个典型问题：\n 故障定位难，一次请求往往需要涉及到多个服务，排查问题甚至需要拉上多个团队;\n 完整调用链路梳理难，节点调用关系分析;\n 性能分析难，性能短板节点.\n 以上这几个问题其实都是应用的可观测性问题：\n Log；\n Trace；\n Metrics。\n 本文将会专注于 Trace 方面，完整地说是分布式链路跟踪 (Distributed tracing)。2010 年谷歌发表了 Dapper 的论文，分享了他们的解决方案，算是业界比较早的分布式链路追踪系统。之后各大互联网公司纷纷参照 Dapper 的思想推出各自的链路跟踪系统，包括 Twitter 的 Zipkin、阿里的鹰眼，还有 PinPoint，Apache 的 HTrace 和 Uber 的 Jaeger；当然，也有我们的本文的主角：SOFATracer。分布式链路的实现有多种多样，因此也催生了分布式链路追踪的规范：OpenTracing，2019 年 OpenTracing 和 OpenCensus 合并成为了 OpenTelemetry。\nOpenTracing 在深入 SOFATracer 之前先简单解释一下 OpenTracing，因为 SOFATTracer 是基于 OpenTracing 规范（基于 0.22.0 的 OpenTracing，新版的规范 API 有所不同）构建的。一个 Trace 由服务调用生成的 Span 及其之间的引用构成，一个 Span 是一个时间跨度，一次服务调用创建一个新 Span，分为调用 Span 和被调 Span，每个 Span 包含：\n TraceId and SpanId\n 操作名称\n 耗时\n 服务调用结果\n 一个 Trace 链路中一般会有多个服务调用，那么也就会有多个 Span，Span 之间的关系由引用声明，引用从调用者指向服务提供者，OpenTracing 中指定了两个引用类型：\n ChildOf，同步服务调用，客户端需要服务端的结果返回才能进行后续处理；\n FollowsFrom，异步服务调用，客户端不等待服务端结果。\n 一个 Trace 是一个有向无环图，一次调用的拓扑可以如下展示：\n 图中的 SpanContext 是一次请求中会共享的数据，因此叫做 Span 上下文，一个服务节点在上下文中放入的数据对于后续的所有节点都可见，因此可以用来做信息传递。\nSOFATracer TraceId 生成 TraceId 收集一次请求中的所有服务节点。其生成规则需要避免不同 TraceId 之间的冲突，并且开销不能很高，毕竟 Trace 链路的生成是业务逻辑之外的额外开销。SOFATracer 中的 TraceId 生成规则是：服务器 IP + 产生 ID 时候的时间 + 自增序列 + 当前进程号，比如：\n0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，大家也可以根据这个规律来查找到请求经过的第一个服务器。 后面的 13 位 1403169275002 是产生 TraceId 的时间。 之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。 最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。\n 伪代码如下：\nTraceIdStr.append(ip).append(System.currentTimeMillis()) append(getNextId()).append(getPID()); SpanId 生成 SpanId 记录服务调用拓扑，在 SOFATracer 中：\n 点代表调用深度\n 数字代表调用顺序\n SpanId 由客户端创建\n SOFATracer 中 TraceId 和 SpanId 的生成规则参考了阿里的鹰眼组件\n 合并调用 Span 和被调 Span，结合 TraceId 和 SpanId 就能构建完整的服务调用拓扑：\n Trace 埋点 但是，我们如何生成并获取到 Trace 数据呢？这就得 Trace 采集器（Instrumentation Framework）登场了，其负责：\n Trace 数据的生成、传递和上报\n Trace 上下文的解析和注入\n 并且 Trace 采集器还要做到自动、低侵入和低开销等。典型的 Trace 采集器结构如下，其在业务逻辑之前埋点：\n Server Received (SR), 创建一个新的父 Span 或者从上下文中提取\n 调用业务代码\n 业务代码再次发起远程服务调用\n Client Send (CS) 创建一个子 Span，传递 TraceId、SpanId 和透传数据\n Client Received (CR), 结束当前子 Span，记录/上报 Span\n Server Send (SS) 结束父 Span，记录/上报 Span\n 步骤 3-5 可能没有，也可能重复多次。\n埋点逻辑的实现多种多样，目前主流的有如下几种方式：\n Filter，请求过滤器 (dubbo, SOFARPC, Spring MVC)\n AOP 切面 (DataSource, Redis, MongoDB)\n a.Proxy\nb.ByteCode generating\n Hook 机制 (Spring Message, RocketMQ) Java 语言中，SkyWalking 和 PinPoint 都使用 javaagent 方式做到自动、无侵入埋点。典型的，SOFATracer 实现 Spring MVC 的 Trace 埋点如下：\n SOFATracer 的 Span 100% 创建，只是 log/report 支持采样，相对来说，log/report 的 overhead 更高，更容易在大流量/负载下成为性能瓶颈。而其他 Trace 系统，Span 是采样生成的，但为了在调用出错的情况下能 100% 有 Trace，他们采用了逆向采样的策略。\nSOFATracer 默认把 Trace …","date":1628578800,"description":"蚂蚁集团 SOFATracer 原理与实践","dir":"blog/ant-group-sofatracer-principles-and-practices/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"235d67352aa5a94ae53bf00b4e8c1730","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","publishdate":"2021-08-10T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","summary":"背景 微服务架构带来很多好处的同时也让系统的复杂度提升了，传统的单体应用按照不同的维度拆分成一个一个分布式微服务，不同的微服务甚至可能采用不同","tags":["SOFAStack"],"title":"蚂蚁集团 SOFATracer 原理与实践","type":"blog","url":"/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/","wordcount":3268},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定 时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@非余 提问：\n 我有个需求，就是我们有自己的配置中心，我的配置加载不想用默认的文件配置，这里如果我要开发的话应该怎么样加会比较漂亮？\n A：把 config.Load 重写成你自己的配置解析，configmanager.RegisterConfigLoadFunc。\nMOSN：https://github.com/mosn/mosn\n@飒 提问：\n 一个方法先 insert 而后另一个方法 update 事物回滚失败怎么解决？\n A：不会，可能你没有保证写函数被 @GlobalTransactional 注解覆盖或建表语句不是最新的导致了你回滚顺序变了。\nSeata：https://github.com/seata/seata\n@飒 提问：\n A 服务使用了 @GlobalTransactional（rollbackFor = Exception.class），调用了 B 服务，B 服务报错了，结果都提交成功，数据库数据也更新了，一般是什么原因？\n A：应该是你被调用的服务，没有加入到全局事务中去（也就是说，被调用的服务没加上 @GlobalTransactional）。\nSeata：https://github.com/seata/seata\n@冯仁彬 提问：\n 被调用的服务也必须添加 @GlobalTransactional?\n A：被调用的服务如果自身不会有任何地方访问自己身的写库方法，那么仅需集成 Seata，如果自身有，那么自身的写库操作全部要被带有 @GlobalTransactional 注解的地方调用，至于这个入库你自己设计。\nSeata：https://github.com/seata/seata\n本周推荐阅读 KCL：声明式的云原生配置策略语言\n 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周发布详情如下：\n本周 MOSN 发布了 v0.24.0 版本。主要更新如下：\n 支持 jaeger tracing；\n grpc 框架支持热升级；\n 变量机制支持 interface 类型的变量；\n 路由模块优化，支持端口匹配、支持变量模式；\n 负载均衡模块多处优化；\n 其他优化与 Bug Fix。\n 详细发布报告：https://github.com/mosn/mosn/releases/tag/v0.24.0\n更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1628233200,"description":"SOFA WEEKLY | MOSN 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210806/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"29e513237a11de947612fdc004f8ddde","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210806/","publishdate":"2021-08-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210806/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210806/","wordcount":1125},{"author":"柴树杉","categories":"SOFAStack","content":" 楔子: 以蚂蚁典型的建站场景为例，在接入 Kusion 后，用户侧配置代码减少到 5.5%，用户面对的 4 个平台通过接入统一代码库而消减，在无其他异常的情况下交付时间从 2 天下降到 2 小时……\n注：本文是柴树杉在 2021 GIAC 大会上分享的内容。相关 PPT 内容请点击下方自行下载\n GIAC 大会 PPT 下载：KCL声明式的云原生配置策略语言 \n0. 你好GIAC 大家好，我是来自蚂蚁的同学，很高兴能在GIAC的编程语言新范式板块和大家分享《KCL配置策略语言》。KCL语言是蚂蚁内部的Kusion解决方案中针对云原生基础设施配置代码化自研的DSL语言，目前已经在建站场景等一些场景开始小范围推广试用。\n我们先看一下简单的KCL代码：\nschema GIACInvitation[name: str]: Name: str = name Topic: str = \u0026amp;quot;分享主题\u0026amp;quot; Company?: str = None Type: str = \u0026amp;quot;分享嘉宾\u0026amp;quot; Address: str = \u0026amp;quot;深圳\u0026amp;quot; invitation = GIACInvitation(\u0026amp;quot;姓名\u0026amp;quot;) { Topic: \u0026amp;quot;KCL配置策略语言\u0026amp;quot; Company: \u0026amp;quot;蚂蚁集团\u0026amp;quot; } 这个例子代码先通过 schema 定义了一个 GIACInvitation 结构体：该结构体有一个 str 类型的 name 参数，同时还有一组标注了类型和默认值的属性。然后通过声明式的语法构造了GIACInvitation 的实例 invitation。\n这个例子虽然简单，但是包含了 KCL 最重要的 schema 语言结构。从例子可以看出 KCL 尝试通过声明式的语法、静态类型检查特性来改进配置代码的编写和维护工作。这也是设计 KCL 语言的初衷，我们希望通过编程领域成熟的技术理论来解决云原生领域的配置代码化的问题。\n1. KCL语言的诞生背景 在经典的 Linux/UNIX 操作系统中，我们通过 Shell 和系统内置的各种工具和内核进行交互，同时通过 Shell 脚本来管理更上层的 App。可以说 Shell 语言极大地简化了内核的编程界面，不仅仅提升了操作系统易用性也简化了上层 App 的管理和运维，也提高了生产效率。而 Kubernetes 作为容器管理领域的事实标准，已经成为云计算时代的Linux/UNIX。类比 UNIX 系统，Kubernetes 目前还缺少一种符合其声明式、开放、共享设计理念的交互语言及工具。\n 1.1 为何要设计KCL语言？ K8s已经成为云计算的操作系统，但是目前尚缺少功能完备的SHELL交互界面。目前虽然有很多而且开源方案，但是还没有像UNIX的Shell那种出现比较成熟的方案，特别是尚无法满足头部互联网企业大规模工程化的要求。云原生技术与企业落地之间存在Gap需要填补，这正是云原生工程化要解决的问题，也是设计KCL语言的出发点。\n1.2 目前是一个好时机 云原生的思路是高度的开放化和民主化，结果就是万物可配置，一切配置都是代码。带配置代码面前人人平等，每个用户都可以通过调整配置代码和基础平台设施进行交互。因此对配置的编写和维护正在成为云计算时代软件工程师的必备的技能和需求。基于对云原生配置代码化需求的日益旺盛，硅谷的诸多头部公司已经对这个方向进行了大规模的实践和验证，这些都给了我们大量可以参考的经验。\n因此蚂蚁的 Kusion 项目尝试通过 KCL 配置策略语言正是为了简化云原生技术设施的接入方式设计，其设计目标不仅仅是为了提升蚂蚁基础设施的开放程度及使用效率，同时希望能够优化共享、协同的开发流程，可以说其定位正是云原生时代的 Shell 语言。虽然目前还处于探索和实践阶段，我们通过此文和大家分享下 KCL 语言的设计与实现的一些理念，为云原生的快速到来贡献一点绵薄之力。\n1.3 KCL诞生历史 KCL 语言从2019年开始初期的调研和设计工作。到2020年3月发布kcl-0.1，基于Python定制语法，采用Go版本的Grumpy和AntLR等工具开发。2020年下半年改用Python语言并加快了开发和迭代速度，发布的kcl-0.2.x引入了大量语言特性、增加了Plugin扩展支持、同时支持IDEA插件。2021年上半年开始统一优化和整合语言特性，发布的kcl-0.3优化类型系统、集成单元测试工具、优化执行性能并提供了Go等多语言的API支持、同时通过LSP为VSCode提供支持。2021年下半年开始在建站等常见落地，同时引入静态类型检查和优化性能，完善语言的文档支持。\n2. KCL语言的设计原则 基于蚂蚁践行多年的经典运维中台沉淀的经验和对各种问题利弊的思考，Kusion 项目对如何充分利用云原生技术带来的红利，打造一个开放、透明、声明式、可协同的运维体系进行了探索和思考，提出并实践了基于基础设施代码化的云原生协同开发的模型。而 KCL 语言正是 Kusion 项目为了解决云原生协同开发而设计的声明式的配置编程语言，简单、稳定、高效和工程化是 KCL 语言设计的设计理念。\n 2.1 简单为王 简单不仅仅可以降低学习和沟通的成本，而且可以减少代码出问题的风险。不论是 UNIX 奉行的 KISS 原则还是 Go语言推崇的 Less is more 设计理念，简化易用的界面始终是各种成功产品追求的一个目标。同样从简单原则出发，KCL 语言在参考现代编程语言之上只保留了必要的元素，同时通过类型自动推导、引入受限的控制流和 schema 提供了基础灵活的配置定义编写能力，删减语言特性始终是 KCL 语言设计工作的一个重要目标。\n2.1.1 声明式语法 声明式编程是和命令式编程并列的一种编程范式，声明式编程只告诉你想要的结果，执行引擎负责执行的过程。声明式编程使用更加简单，可以降低命令式拼装造成的复杂性和副作用，保持配置代码清晰可读，而复杂的执行逻辑已经由 Kubernetes 系统提供支持。KCL 语言通过简化对 schema 结构体实例化的语法结构对声明式语法提供支持，通过仅提供少量的语句来减少命令过程式编程带来的复杂性。 围绕 schema 和配置相关的语法，KCL 希望每种配置需求尽可能通过固定的写法完成，使得配置代码尽可能的统一化。\n比如作为 KCL 声明式语法的核心结构 schema 可以采用声明式方式实例化：\nschema Name: firstName: str lastName: str schema Person: name: Name = { firstName: \u0026amp;quot;John\u0026amp;quot; lastName: \u0026amp;quot;default\u0026amp;quot; } JohnDoe = Person { name.lastName: \u0026amp;quot;Doe\u0026amp;quot; } 首先通过schema定义了一个 Name 结构，结构包含2个字符串类型的必填属性。然后在 Person 中复用 Name 类型声明一个name属性，并且给name属性设置了默认值以简化用户使用。最终 …","date":1627974000,"description":"KCL：声明式的云原生配置策略语言","dir":"blog/kcl-a-declarative-cloud-native-configuration-policy-language/","fuzzywordcount":8200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"30b5034f7ce40b32a13a09cfe141b101","permalink":"https://sofastack.github.io/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","publishdate":"2021-08-03T15:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","summary":"楔子: 以蚂蚁典型的建站场景为例，在接入 Kusion 后，用户侧配置代码减少到 5.5%，用户面对的 4 个平台通过接入统一代码库而消减，在无其他异常的情况下交","tags":["SOFAStack"],"title":"KCL：声明式的云原生配置策略语言","type":"blog","url":"/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/","wordcount":8120},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张鹏 提问：\n 比如我在新模块中添加 Service 实现，宿主应用没有调用相关的 Service 啊，我其实想实现代码的热部署通过 SOFAArk 可以？\n A：可以动态部署的（所有的 bean 会刷新，服务会发布），跟宿主应用有没有调用没有关系的。\nSOFAArk：https://github.com/sofastack/sofa-ark\n2、@周永平 提问：\n 我想请教下，SOFABoot 如果使用 Spring 的 event，跨模块会被通知到吗？\n A：默认情况下，Spring 事件只在本模块中，不会传递的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@孙力 提问：\n 蚂蚁内部与 MOSN 对应的应该是有统一的控制面吗？其中熔断限流组件是使用的 sentinel 吗？控制面与 MOSN 中的 sentinel-client 对接更新限流规则，使用的 sentienl 的 dynamic-rule，还是 xds 下发的？\n A：我们内部是有统一的控制面的，我们的限流熔断算法是基于 sentinel 去扩展实现的，底层的限流框架是基于 sentinel 的，更新规则时我们用的是我们内部的一套配置管理中间件。\nMOSN：https://github.com/mosn/mosn\n4、@孟晓冬 提问：\n 目前的问题是，Dubbo 应用在注入 MOSN 时，MOSN 启动时，要么报权限问题，要么报各种 not support，想请教一下是什么原因？\n A：你用的 1.7.x 的 Istio 的话，那要用对应分支的 MOSN 版本镜像。\nMOSN：https://github.com/mosn/mosn\n本周发布 本周 Layotto 发布了 v0.1.0\n这是 Layotto 的第一次发布，包含功能：\n 支持 configuration API\n 支持 pubsub API\n 支持 state API\n 支持 distributed lock API\n 支持 sequencer API\n 支持 rpc API\n 支持通过 4 层或者 7 层进行流量治理（例如 dump 流量,限流等功能)\n 支持 Actuator API，用于健康检查和运行时元数据查询\n 支持集成 Istio\n 支持基于 WASM 进行多语言编程\n Go sdk\n 感谢各位贡献者这段时间的付出！\n详细参考：https://github.com/mosn/layotto/\n文章解读： https://mosn.io/layotto/#/zh/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/index\n本周 SOFABoot 发布了 3.8.0 版本。主要更新如下：\n 支持 JDK11\n 添加 proxyBeanMethods=false 字段在 @Configuration 类上\n 调整 SOFARPC 注解的超时优先级\n 修复 Ark 环境处理注解时抛出 TypeNotPresentExceptionProxy 异常的问题\n 详细参考： https://github.com/sofastack/sofa-boot\n本周推荐阅读 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路\n 我们做出了一个分布式注册中心\n 还在为多集群管理烦恼吗？OCM来啦！\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1627628400,"description":"SOFA Weekly | Layotto、SOFABoot 发布新版本、QA 整理","dir":"blog/sofa-weekly-20210730/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa875b307e883aea56f46eab071f52d0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210730/","publishdate":"2021-07-30T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210730/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Layotto、SOFABoot 发布新版本、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210730/","wordcount":1199},{"author":"祝辰（忘禅）","categories":"SOFAStack","content":" 开篇 这篇文章是基于SOFA Meetup合肥站的分享总结，主要针对于注册中心的定位以及功能介绍，通过对蚂蚁注册中心发展史的分析，带领大家了解，蚂蚁的注册中心是如何一步一步演变为现在的规模和特性的。\n更多深入的技术细节，欢迎大家加入到SOFA和SOFARegistry的社区中，探寻结果。\n注册中心是什么 服务发现 \u0026amp;amp; 服务注册 注册中心简单来说，是为了解决分布式场景下，服务之间互相发现的问题。\n如下图所示，服务A想要调用服务B的时候，需要知道B的地址在哪里，如何解决这个问题？\n 一般来说，分为两个点：\n 服务发现可以有一个中心化的组件或者说是存储，它承载了所有服务的地址，同时提供出来一个可供查询和订阅的能力，服务的消费方可以通过和这个中心化的存储交互，获取服务提供方的地址列表。 服务注册：同样是上文中中心化的组件，但是，这个时候的服务信息可以有两种措施 服务连接注册中心，同时上报自身的服务以及元数据（也是今天本文讲述的重点） 有一个集中的控制面（control plane）将用户定义的服务和IP的映射写入注册中心，例如AWS的CloudMap 调用流程 如上图所示，就是目前一种主流的注册中心模式，SOFARegistry和Nacos都是这种模式。\n 服务A，服务B通过SDK或者REST将自身的服务信息上报给注册中心 服务A需要调用服务B的时候，就对注册中心发起请求，拉取和服务B相关的服务IP列表以及信息 在获取到服务B的列表之后，就可以通过自身定义的负载均衡算法访问服务B 心跳 心跳是注册中心用于解决服务不可用时，及时拉出服务降低影响的默认方式，如下图所示\n 服务B的一个节点断网或是hang住，引发心跳超时；或是宕机、断链直接引发心跳失败 注册中心把问题节点从自身的存储中拉出（这里拉出根据具体实现：有的是直接删除，有的是标记为不健康） 服务A收到注册中心的通知，获取到服务B最新的列表 DUBBO 注册中心 下面通过DUBBO的例子，我们来看一下注册中心是如何使用的，以及流程\n首先，DUBBO在2.7和3.0中的配置略有不同，但是都是简单易懂的，这里都放上来\nDUBBO-2.7\n DUBBO-3.0\n 在RPC客户端只需要配置一个注册中心的地址即可，地址中包含了基础三元素\n protocol（协议类型）比如，zookeeper host port 基于此，dubbo的注册流程如下图所示\n 服务的生产方通过DUBBO客户端向注册中心（Registry）发起注册行为（register） 服务的消费方通过DUBBO客户端订阅信息（subscribe） 注册中心通过通知的方式，下发服务列表给服务消费方 注册中心的本质 通过前文的讲解，以及DUBBO组件的具体例子，我们大概可以归纳注册中心的本质\n“存储” + “可运维”\n 一方面，注册中心需要存储能力去记录服务的信息，比如应用列表 另一方面，注册中心在实践过程中，需要提供必需的运维手段，比如关闭某一服务流量 蚂蚁注册中心编年史 史前时代 史前时代的蚂蚁是相当久远的架构，当时所有的服务部署在同一台物理机上或者JVM上，服务之间不存在有跨机器调用的场景，这里略过不表\n 硬负载时代 后来，为了解决应用之间的耦合带来的部署难，运维难问题，我们对服务进行了拆分，拆分后的服务，遇到了一个问题，就是如何处理服务之间的调用关系，这个时候，蚂蚁用了两种硬负载 F5 或是 LVS。\n通过简单的4层代理，我们可以把服务部署在代理的后面，服务与服务之间通过代理互相访问，达到了跨机调用的目的\n 第一代注册中心 \u0026amp;ndash; 硬负载到软负载的演变 通过硬负载访问的方式，一方面解决了服务之间互相调用的问题，部署架构也简单易懂；另一方面，在业务快速增长之后，却带来了一定的问题：\n 单点的问题（所有调用都走F5的话，F5一旦挂了，很多服务会不可用） 容量问题（F5承载的流量太高，本身会到一个性能瓶颈） 这个时候，蚂蚁引进了阿里集团的一款产品叫ConfigServer，作为注册中心进行使用，这个注册中心的架构就和开头提到的架构很像了，服务之间可以通过IP直接访问，而降低了对负载均衡产品的强依赖，减少了单点风险。\n 第二代注册中心 \u0026amp;ndash; ScaleUp？ScaleOut？It\u0026amp;rsquo;s a problem 但是，问题还在持续，那就是注册中心，本身是一个单点，那么，他就会继续遇到上文中所说的两个问题\n 单点风险（注册中心本身是单机应用） 容量瓶颈（单台注册中心的连接数和存储数据的容量是有限的） 解决的方式有两种\n scale-up（淘宝）：通过增加机器的配置，来增强容量以及扛链接能力；同时，通过主-备这样的架构，来保障可用性 scale-out（蚂蚁）：通过分片机制，将数据和链接均匀分布在多个节点上，做到水平拓展；通过分片之后的备份，做到高可用 蚂蚁和淘宝走了两条不同的路，也推进了蚂蚁后面演进出一套独立的生态系统\n蚂蚁的演进架构如下，产生了两种不同的应用节点\n session节点，专门用来抗链接使用，本身无状态可以快速扩展，单机对资源的占用很小 data节点，专门用来存储数据，通过分片的方式降低单个节点的存储量，控制资源占用 第五代注册中心 \u0026amp;ndash; Meta节点的诞生 上面的架构已经很符合目前主流的分布式架构了，但是在运维过程中，产生了一系列问题，比如\n 所有data都是分布式的，data之间的服务发现需要通过启动时给定一个配置文件，这样就和标准运维脱钩 data节点的上下线需要去及时修改配置文件，否则集群重启会受到影响 分布式存储一致性问题，每次迭代发布，需要锁定paas平台，防止节点变动带来的不一致 所有这些问题的产生，我们发现可以引入一个元数据管理中心（Meta）节点来，解决对data和session管理的问题，data和session通过4层负载或是7层负载对meta访问即可.\n对比业界的解决方案，都有类似的模型，比如HDFS的Name Node、Kafka依赖于ZK，Oceanbase依赖于RootServer 或者 配置中心Apollo依赖于Euraka。\nMeta节点的出现，缓解了手工运维注册中心的瓶颈，但是，依然没有从根本上解决问题，那么问题在哪里？详见下文分析。\n 第六代注册中心 \u0026amp;ndash; 面向运维的注册中心 上文说道，Meta节点的出现，承接了Data以及Session之间服务发现的问题，但是，丛云未测来讲，还是有很多问题解决不了，比如\n Data节点的发布在数据量大的前提下，依然是个痛点 Session节点的新加节点上，可能很久都没有流量 等等，对于这些问题，在SOFARegistry5.x的基础上，我们快速迭代了6.0版本，主要是面向运维的注册中心。\nData节点发布难的问题，说到底是一个影响范围的问题，如何控制单一data节点发布或者挂掉对数据的影响面，是解决问题的本源，这里我们采用了两个措施\n 改进数据存储算法（consistent-hash -\u0026amp;gt; hash-slot） 应用级服务发现 存储算法的演进 之前我们使用了一致性hash的算法，如下图所示， …","date":1627369200,"description":"我们做出了一个分布式注册中心","dir":"blog/we-made-a-distributed-registry/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"991c52c34e8dc2370ae08263b297cbe0","permalink":"https://sofastack.github.io/sofastack.tech/blog/we-made-a-distributed-registry/","publishdate":"2021-07-27T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/we-made-a-distributed-registry/","summary":"开篇 这篇文章是基于SOFA Meetup合肥站的分享总结，主要针对于注册中心的定位以及功能介绍，通过对蚂蚁注册中心发展史的分析，带领大家了解，","tags":["SOFAStack"],"title":"我们做出了一个分布式注册中心","type":"blog","url":"/sofastack.tech/blog/we-made-a-distributed-registry/","wordcount":4390},{"author":"","categories":"SOFAStack","content":" 蚂蚁集团运维着可能是全球最大的 K8s 集群：K8s 官方以 5k node 作为 K8s 规模化的顶峰，而蚂蚁集团事实上运维着规模达到 10k node 规模的 K8s 集群。一个形象的比喻就是，如果官方以及跟着官方的 K8s 使用者能想象到的 K8s 的集群规模是泰山，那么蚂蚁集团在官方的解决方案之上已经实现了一个珠穆朗玛峰，引领了 K8s 规模化技术的提升。\n这个量级的差异，不仅仅是量的差异，更是 K8s 管理维护的质的提升。能维护有如此巨大挑战巨量规模的 K8s 集群，其背后原因是蚂蚁集团付出了远大于 K8s 官方的优化努力。\n所谓万丈高楼平地起，本文着重讨论下蚂蚁集团的在 K8s 的基石 \u0026amp;mdash; etcd 层面做出的高可用建设工作：只有 etcd 这个基石稳当了，K8s 这栋高楼大厦才保持稳定性，有 tidb 大佬黄东旭朋友圈佐证【图片已获黄总授权】。\n 面临的挑战 etcd 首先是 K8s 集群的 KV 数据库。 从数据库的角度来看，K8s 整体集群架构各个角色如下：\n etcd 集群的数据库\n kube-apiserver etcd 的 API 接口代理、数据缓存层\n kubelet 数据的生产者和消费者\n kube-controller-manager 数据的消费者和生产者\n kube-scheduler 数据的消费者和生产者\n etcd 本质是一个 KV 数据库，存储了 K8s 自身资源 、用户自定义的 CRD 以及 K8s 系统的 event 等数据。每种数据的一致性和数据安全性要求不一致，如 event 数据的安全性小于 K8s 自身的资源数据以及 CRD 数据。\nK8s 的早期拥护者在推广 K8s 时，宣称其比 OpenStack 的优势之一是 K8s 没有使用消息队列，其延迟比 OpenStack 低。这其实是一个误解，无论是 etcd 提供的 watch 接口，还是 K8s client 包中的 informer 机制，无不表明 K8s 是把 etcd 当做了消息队列，K8s 消息的载体很多，譬如 K8s event。\n从消息队列的角度来看，K8s 整体集群架构各个角色如下：\n etcd 消息路由器\n kube-apiserver etcd 生产者消息代理和消息广播【或者成为次级消息路由器、消费者代理】\n kubelet 消息的生产者和消费者\n kube-controller-manager 消息的消费者和生产者\n kube-scheduler 消息的消费者和生产者\n etcd 是推模式的消息队列。etcd 是 K8s 集群的 KV 数据库和消息路由器，充当了 OpenStack 集群中的 MySQL 和 MQ 两个角色，这样的实现貌似简化了集群的结构，但其实不然。在 large scale 规模 K8s 集群中，一般经验，首先都会使用一个单独 etcd 集群存储 event 数据：把 KV 数据和一部分 MQ 数据物理隔离开，实现了 KV 和 MQ 角色的部分分离。 如 参考文档 2 中提到美团 “针对 etcd 的运营，通过拆分出独立的 event 集群降低主库的压力”。\n当 K8s 集群规模扩大时，etcd 承载着 KV 数据剧增、event 消息暴增以及消息写放大的三种压力。 为了证明所言非虚，特引用部分数据为佐证：\n etcd KV 数据量级在 100 万以上；\n etcd event 数据量在 10 万以上；\n etcd 读流量压力峰值在 30 万 pqm 以上，其中读 event 在 10k qpm 以上；\n etcd 写流量压力峰值在 20 万 pqm 以上，其中写 event 在 15k qpm 以上；\n etcd CPU 经常性飙升到 900% 以上；\n etcd 内存 RSS 在 60 GiB 以上；\n etcd 磁盘使用量可达 100 GiB 以上；\n etcd 自身的 goroutine 数量 9k 以上；\n etcd 使用的用户态线程达 1.6k 以上；\n etcd gc 单次耗时常态下可达 15ms。\n 使用 Go 语言实现的 etcd 管理这些数据非常吃力，无论是 CPU、内存、gc、goroutine 数量还是线程使用量，基本上都接近 go runtime 管理能力极限：经常在 CPU profile 中观测到 go runtime 和 gc 占用资源超过 50% 以上。\n蚂蚁的 K8s 集群在经历高可用项目维护之前，当集群规模突破 7 千节点规模时，曾出现如下性能瓶颈问题：\n etcd 出现大量的读写延迟，延迟甚至可达分钟级；\n kube-apiserver 查询 pods / nodes / configmap / crd 延时很高，导致 etcd oom；\n etcd list-all pods 时长可达 30 分钟以上；\n 2020 年 etcd 集群曾因 list-all 压力被打垮导致的事故就达好几起；\n 控制器无法及时感知数据变化，如出现 watch 数据延迟可达 30s 以上。\n 如果说这种状况下的 etcd 集群是在刀锋上跳舞， 此时的整个 K8s 集群就是一个活火山：稍不留神就有可能背个 P 级故障， 彼时的整个 K8s master 运维工作大概是整个蚂蚁集团最危险的工种之一。\n高可用策略 实现一个分布式系统高可用能力的提升，大概有如下手段：\n 提升自身稳定性与性能；\n 精细管理上游流量；\n 保证服务下游服务 SLO。\n etcd 经过社区与各方使用者这么多年的锤炼，其自身的稳定性足够。蚂蚁人能做到的，无非是使出周扒皮的本事，提高集群资源整体利用率，scale out 和 scale up 两种技术手段双管齐下，尽可能的提升其性能。\netcd 自身作为 K8s 的基石，其并无下游服务。如果说有，那也是其自身所使用的物理 node 环境了。下面分别从 etcd 集群性能提升、请求流量管理等角度阐述我们在 etcd 层面所做出的高可用能力提升工作。\n文件系统升级 在山窝里飞出金凤凰，诚非易事。让 etcd 跑的更快这件事，没有什么手段比提供一个高性能的机器更短平快地见效了。\n1.使用 NVMe ssd etcd 自身 = etcd 程序 + 其运行环境。早期 etcd 服务器使用的磁盘是 SATA 盘，经过简单地测试发现 etcd 读磁盘速率非常慢，老板豪横地把机器鸟枪换炮 \u0026amp;mdash; 升级到使用了 NVMe SSD 的 f53 规格的机器：etcd 使用 NVMe ssd 存储 boltdb 数据后，随机写速率可提升到 70 MiB/s 以上。\n参考文档 2 中提到美团 “基于高配的 SSD 物理机器部署可以达到日常 5 倍的高流量访问”，可见提升硬件性能是大厂的首选，能折腾机器千万别浪费人力。\n2.使用 tmpfs NVMe ssd 虽好，理论上其读写极限性能跟内存比还是差一个数量级。我们测试发现使用 tmpfs【未禁止 swap out】替换 NVMe ssd 后，etcd 在读写并发的情况下性能仍然能提升 20% 之多。考察 K8s 各种数据类型的特点后，考虑到 event …","date":1627282800,"description":"蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路","dir":"blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"49c1cbed799517497d7760e5717c5843","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","publishdate":"2021-07-26T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","summary":"蚂蚁集团运维着可能是全球最大的 K8s 集群：K8s 官方以 5k node 作为 K8s 规模化的顶峰，而蚂蚁集团事实上运维着规模达到 10k node 规模的 K8s 集群。一个形象的比喻就是","tags":["SOFAStack"],"title":"蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路","type":"blog","url":"/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/","wordcount":7144},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践\n 活动时间：2021 年 07 月 24 日（周六）13:30-17:30\n 活动地点：合肥高新区创新产业园D8栋一楼集思空间\n 活动形式：线下活动\n 资料下载： 《蚂蚁注册中心 SOFARegistry 分享》 《基于API 网关的微服务治理演进与架构实践》 《蚂蚁集团分布式链路组件 SOFATracer 原理与实践》 《准实时的日志聚合平台》 《Service Mesh在蚂蚁集团的实践》\n 本次分享涉及的项目地址\n sofa-registry开箱即用计划 https://github.com/sofastack/sofa-registry/projects/5\nsofa-registry深度解析计划 https://github.com/sofastack/sofa-registry/projects/4\n(这两个计划想帮助对参与开源项目感兴趣的同学由浅入深的上手，成为社区的一员)\nsofa-tracer https://github.com/sofastack/sofa-tracer\nmosn https://github.com/mosn/mosn\n活动介绍 活动议程 本期议题以及嘉宾详解 《蚂蚁注册中心 SOFARegistry 分享》\n嘉宾介绍\n祝辰（花名忘禅），蚂蚁集团技术专家，2020年加入蚂蚁集团致力于服务发现领域的技术建设，开源项目sofa-registry、x-pipe核心开发人员。\n议题简介\n大规模微服务场景下的注册中心：SOFARegistry v6 新特性介绍 SOFARegistry 是蚂蚁集团内部在使用的服务注册中心，它支撑起了蚂蚁集团海量规模的业务服务。 但随着蚂蚁集团业务规模的日渐庞大，SOFARegistry 在资源、容量、运维等方面也遇到了一些挑战，针对这一系列的挑战，我们对 SOFARegistry 进行了大量的改造，开发了 v6 版本的 SOFARegistry。\n项目地址\nsofa-registry开箱即用计划 https://github.com/sofastack/sofa-registry/projects/5\nsofa-registry深度解析计划 https://github.com/sofastack/sofa-registry/projects/4\n(这两个计划想帮助对参与开源项目感兴趣的同学由浅入深的上手，成为社区的一员)\n听众收获\n1、全面了解不同注册中心的设计及架构；\n2、深入了解千万级别微服务场景下服务发现的问题和解法。\n《基于API 网关的微服务治理演进与架构实践》\n嘉宾介绍\n王晔倞，现任API7 VP，Apache APISIX Contributor。公众号「头哥侃码」作者，曾在好买财富、大智慧、中通服软件、东方购物任职，21年IT从业经验，对技术管理和架构设计有一定的经验。TGO 鲲鹏会上海理事会成员，腾讯云TVP，QCon北京2017明星讲师，QCon北京2018优秀出品人。\n议题简介\n内容讲述随着业务的发展，规模扩大，服务颗粒越来越细，数量也越来越多。 我们在过程中有过很多经验和探索，并将系统从一个服务于单个业务方的后台系统逐渐改造成为一个支持海量内容，服务多个业务方，业务规则复杂多变的微服务治理架构。 通过API网关，我们有效协调线上运行的各个服务，保障服务的SLA。基于服务调用的性能KPI数据进行容量管理，并通过对技术中台的升级，对故障进行降级、熔断、限流等一系列升级。\n听众收获\n1、微服务治理当前面临的问题；\n2、API网关在微服务治理中的价值；\n3、从“单体“到”微服务“的转型过程中，该如何使用API网关实现微服务治理。\n《蚂蚁集团分布式链路组件 SOFATracer 原理与实践》\n嘉宾介绍\n郑志雄（花名纶珥），SOFABoot 开源负责人，主要负责蚂蚁集团应用研发框架的开发。\n议题简介\n当下的微服务技术架构，应用的各种服务通常都比较复杂、分布在不同的机器上；同时，这些应用可能又构建在不同的软件模块上，这些软件模块有可能是由不同的团队开发，可能使用不同的编程语言来实现、有可能部署了几千台服务器。为了能够分析应用的线上调用行为以及调用性能，蚂蚁金服基于 OpenTracing 规范，提供了分布式链路跟踪 SOFATracer 的解决方案，帮助理解各个应用的调用行为，并可以分析远程调用性能的组件。\n项目地址\nhttps://github.com/sofastack/sofa-tracer\n听众收获\n1、了解微服务场景下分布式链路组件的作用及价值；\n2、了解蚂蚁集团 SOFATracer 组件的基本原理。\n《准实时的日志聚合平台》\n嘉宾介绍\n吕思泉是思科 Webex 产品线 MATS（媒体分析与问题诊断服务）团队的技术专家，热爱开源，热爱分享，热爱生活，在MATS团队主要工作方向为基础技术的研究与应用，在分布式系统和微服务方面有丰富的经验，由其本人编写并开源的jgossip项目解决了MATS分布式Job Engine的水平扩展难题，由其本人研究并实践的基于Loki+Promtail+Grafana的日志平台大幅度提高了MATS团队在分布式系统日志管理与监控方面的效率。\n议题简介\n简要介绍基于 Loki 的日志可视化套件，以及思科内部如何使用该技术进行监控和告警。\n听众收获\n通过讲师介绍，大家可以了解到一种轻巧灵活的日志聚合系统，帮助开发人员快速定位问题以及实时了解系统状况。\n《Service Mesh 在蚂蚁集团的实践》\n嘉宾介绍\n李唯（良恩），蚂蚁集团技术专家。2017 年加入蚂蚁集团中间件团队。参与了 Service Mesh 在蚂蚁的落地建设，目前主要负责 MOSN 在蚂蚁内部的设计开发。\n议题简介\n随着业务发展，越来越多公司选择了微服务架构，它帮助业务解决了很多问题，但是在实践过程中也不免会遇到一些问题。在这些利与弊的权衡之中，Service Mesh 能够帮助到我们什么呢？本次内容分享 Service Mesh 在微服务的实践中解决的一些问题以及其背后的思考。\n项目地址\nhttps://github.com/mosn/mosn\n听众收获\n1、了解 Service Mesh 在微服务中的实践场景和意义；\n2、了解 Service Mesh 在蚂蚁实践中为业务带来的价值。\n了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1627110000,"description":"SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践","dir":"activities/sofa-meetup-8/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4f05d75ae1c87e74010079dc175e3420","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-8/","publishdate":"2021-07-24T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-8/","summary":"概要 活动主题：SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践 活动时间：2021 年 07 月 24 日（周六）13:30-17:30 活动地点","tags":["SOFAMeetup"],"title":"SOFAStack Meetup#7 合肥站-SOFA 微服务架构技术生态与实践","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-8/","wordcount":2084},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@王辉 提问：\n SOFARegistry 的 data 节点，连接 meta 节点，为什么设计成随机选择一个节点连接，如果 meta 节点 3 个节点，其中有一个节点挂了，而 data 节点又随机选择到这个挂的节点，就启动失败了。\n A：通过 slb 查询到主节点，然后所有的 session 和 data 都连接 meta 主节点。不是随机连接一个 meta。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n2、@刚刚 提问：\n SOFARPC 是通过 MOSN 转发协议？SOFARPC 对外注册的 IP 在 k8 的容器是什么策略？\n A：MOSN 支持 SOFARPC 协议的转发。服务发布订阅没有做啥特殊的，就和原来是一样的。\nMOSN：https://github.com/mosn/mosn\n3、@证道者 提问：\n Layotto 中 wasm 是怎么设置 cpu 和内存的？\n A：目前官方提供的 Wasm 运行时还不支持对 cpu 内存等资源进行限制，不过我们已经在跟 WasmEdge 社区沟通了，他们是可以支持这种场景的，所以后面同时会支持 WasmEdge 作为 Layotto 的 Wasm 运行时。\nLayotto：https://github.com/mosn/layotto\n3、@Q 提问：\n 两个 tc 节点，就有两套 global，branch，lock 表，当一个事物的调用链中，不同的 rm 连接的是不同的 tc 节点时，是不是会在各自 tc 的 branch 表里生成分支事物啊，这个时候怎么保证一致性呢？\n A：tc 集群无状态的，共用一套 db 数据。\nSeata：https://github.com/seata/seata\n本周推荐阅读 RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n 还在为多集群管理烦恼吗？OCM来啦！\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1627023600,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210723/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2d78986f9ca335444ed265e7bfac0648","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210723/","publishdate":"2021-07-23T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210723/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210723/","wordcount":972},{"author":"","categories":"SOFAStack","content":" 作者简介：冯泳（花名鹿惊），资深技术专家，拥有西北工业大学计算机科学博士学位，在高性能计算，大数据和云计算领域拥有十多年的设计开发经验，专注于调度，资源和应用管理领域。也深度参与相关开源项目的开发和商业化，例如 OpenStack, Mesos, Swarm, Kubernetes, Spark 等，曾在 IBM 领导过相关的开发团队。\n 前言 在云计算领域如果还有人没听过 Kubernetes，就好像有人不知道重庆火锅必须有辣椒。Kubernetes 已经像手机上的 Android，笔记本上的 Windows 一样成为管理数据中心事实上的标准平台了。围绕着 Kubernetes，开源社区构建了丰富的技术生态，无论是 CI/CD、监控运维，还是应用框架、安全反入侵，用户都能找到适合自己的项目和产品。可是，一旦将场景扩展到多集群、混合云环境时，用户能够依赖的开源技术就屈指可数，而且往往都不够成熟、全面。\n为了让开发者、用户在多集群和混合环境下也能像在单个 Kubernetes 集群平台上一样，使用自己熟悉的开源项目和产品轻松开发功能，RedHat 和蚂蚁、阿里云共同发起并开源了 OCM（Open Cluster Management）旨在解决多集群、混合环境下资源、应用、配置、策略等对象的生命周期管理问题。目前，OCM 已向 CNCF TOC 提交 Sandbox 级别项目的孵化申请。\n项目官网：https://open-cluster-management.io/\n 多集群管理发展历史 让我们把时间拉回到几年前，当业界关注/争论的焦点还在 Kubernetes 是否生产级可用的时候，就出现了最早一批登陆“多集群联邦“技术的玩家。它们大都是体量上远超平均水准的 Kubernetes 实践先驱，从最早 Redhat、谷歌入场做了 KubeFed v1 的尝试，再到后来携手 IBM 吸取经验又推出 KubeFed v2。除了这些大型企业在生产实践 Kuberentes 的场景中探索多集群联邦技术，在商业市场上，各个厂商基于 Kubernetes 包装的服务产品也大多经历了从单集群产品服务到多集群形态、混合云场景进化的过程。其实，无论是企业自身还是商业用户都有共性的需求，聚焦在以下几个方面：\n多地域问题：当集群需要在异构基础设施上或者横跨更广地域进行部署\nKubernetes 集群依赖 etcd 作为数据持久层，而 etcd 作为分布式系统对系统中各个成员之间的网络延迟上有要求，对成员的数量也有一些限制，虽然在延迟能够容忍的情况下可以通过调整心跳等参数适配，但是不能满足跨国跨洲的全球性部署需求，也不能保证规模化场景下可用区的数量，于是为了让 etcd 至少可以稳定运行，一般会按地域将 etcd 规划为多个集群。此外，以业务可用和安全性为前提，混合云架构越来越多地被用户接受。跨越云服务提供商很难部署单一 etcd 集群，随之对应的，Kubernetes 集群也被分裂为多个。当集群的数量逐渐增多，管理员疲于应对时，自然就需要一个聚合的管控系统同时管理协调多个集群。\n规模性问题：当单集群规模性遇到瓶颈\n诚然，Kubernetes 开源版本有着明显的规模性瓶颈，然而更糟糕是，我们很难真正量化 Kubernetes 的规模。社区一开始提供了 kubemark 套件去验证集群的性能，可是现实很骨感，kubemark 所做的事情基于局限于在不同节点数量下反复对 Workload 进行扩缩容调度。可是实践中造成 Kubernetes 性能瓶颈的原因复杂、场景众多，kubemark 很难全面客观描述多集群的规模性，只能作为非常粗粒度下的参考方案。后来社区支持以规模性信封来多维度衡量集群容量，再之后有了更高级的集群压测套件 perf-tests。当用户更清晰地认识到规模性的问题之后，就可以根据实际场景（比如 IDC 规模、网络拓扑等）提前规划好多个 Kubernetes 集群的分布，多集群联邦的需求也随之浮出水面。\n容灾/隔离性问题：当出现更多粒度的隔离和容灾需求\n业务应用的容灾通过集群内的调度策略，将应用部署到不同粒度的基础设施可用区来实现。结合网络路由、存储、访问控制等技术，可以解决可用区失效后业务的连续性问题。但是如何解决集群级别，甚至是集群管理控制平台自身的故障呢？\netcd 作为分布式系统可以天然解决大部分节点失败的问题，可是不幸的是实践中 etcd 服务也还是可能出现宕机的状况，可能是管理的操作失误，也可能是出现了网路分区。为了防止 etcd 出现问题时“毁灭世界”，往往通过缩小“爆炸半径”来提供更粒度的容灾策略。比如实践上更倾向于在单个数据中心内部搭建多集群以规避脑裂问题，同时让每集群成为独立的自治系统，即使在出现网络分区或者更上层管控离线的情况下可以完整运行，至少稳定保持现场。这样自然就形成了同时管控多个 Kubernetes 集群的需求。\n另一方面，隔离性需求也来自于集群在多租户能力上的不足，所以直接采取集群级别的隔离策略。顺带一提的好消息是 Kubernetes 的控制面公平性/多租户隔离性正在一砖一瓦建设起来，通过在 1.20 版本进入 Beta 的 APIPriorityAndFairness 特性，可以根据场景主动定制流量软隔离策略，而不是被动的通过类似 ACL 进行流量的惩罚限流。如果在最开始进行集群规划的时候划分为多个集群，那么隔离性的问题自然就解决了，比如我们可以根据业务给大数据分配独占集群，或者特定业务应用分配独占请集群等等。\nOCM 的主要功能和架构 OCM 旨在简化部署在混合环境下的多 Kubernetes 集群的管理工作。可以用来为 Kubernetes 生态圈不同管理工具拓展多集群管理能力。OCM 总结了多集群管理所需的基础概念，认为在多集群管理中，任何管理工具都需要具备以下几点能力：\n1.理解集群的定义；\n2.通过某种调度方式选择一个或多个集群；\n3.分发配置或者工作负载到一个或多个集群；\n4.治理用户对集群的访问控制；\n5.部署管理探针到多个集群中。\nOCM 采用了 hub-agent 的架构，包含了几项多集群管理的原语和基础组件来达到以上的要求：\n●通过 ManagedCluster API 定义被管理的集群，同时 OCM 会安装名为 Klusterlet 的 agent 在每个集群里来完成集群注册，生命周期管理等功能。\n●通过 Placement API 定义如何将配置或工作负载调度到哪些集群中。调度结果会存放在 PlacementDecision API 中。其他的配置管理和应用部署工具可以通过 PlacementDecisiono 决定哪些集群需要进行配置和应用部署。\n●通过 ManifestWork API 定义分发到某个集群的配置和资源信息。\n●通过 ManagedClusterSet API 对集群进行分组，并提供用户访问集群的界限。\n●通过 ManagedClusterAddon API 定义管理探针如何部署到多个集群中以及其如何与 hub 端的控制面进行安全可靠的通信。\n架构如下图所示，其中 registration 负责集群注册、集群生命周期管 …","date":1626764400,"description":"还在为多集群管理烦恼吗？OCM来啦！","dir":"blog/still-worried-about-multi-cluster-management/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"aef61122b990c692c05ed45907471ef8","permalink":"https://sofastack.github.io/sofastack.tech/blog/still-worried-about-multi-cluster-management/","publishdate":"2021-07-20T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/still-worried-about-multi-cluster-management/","summary":"作者简介：冯泳（花名鹿惊），资深技术专家，拥有西北工业大学计算机科学博士学位，在高性能计算，大数据和云计算领域拥有十多年的设计开发经验，专注","tags":["SOFAStack"],"title":"还在为多集群管理烦恼吗？OCM来啦！","type":"blog","url":"/sofastack.tech/blog/still-worried-about-multi-cluster-management/","wordcount":5878},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈拥军 提问：\n 我想求教一个问题，非 Spring 工程中使用 SOFARPC 的泛化调用是否可行？\n A：使用 SOFARPC 的 API 方式构造 泛化 Reference 就可以。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@孙明 提问：\n 请教大家，SOFARPC 可以相互依赖吗？比如 a 依赖 b，同时 b 也依赖 a。\n A：只要不是应用启动期的循环依赖，都是可以的。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n3、@周杰慧 提问：\n 请教个问题，使用 shardingsphere 与 Seata AT 模式结合，我看 Seata 源代码回滚时用主键更新，但对于数据库分片来讲更新时 where 条件需要带上分片的列，这样的话我应该怎么解决这个问题呢？\n A：看他们的 demo 来集成。\nSeata：https://github.com/seata/seata\n4、@Q 提问：\n eureka 做注册中心，TC 高可用时，如何在 TC 端覆盖 eureka 属性？\n A：在 seata\\conf 目录下新增 eureka-client.properties 文件，添加要覆盖的 eureka 属性即可。例如，要覆盖 eureka.instance.lease-renewal-interval-in-seconds 和 eureka.instance.lease-expiration-duration-in-seconds添加如下内容：\neureka.lease.renewalInterval=1\neureka.lease.duration=2\n属性前缀为 eureka，其后的属性名可以参考类 com.netflix.appinfo.PropertyBasedInstanceConfigConstants，也可研究 Seata 源码中的 discovery 模块的 seata-discovery-eureka 工程。\nSeata：https://github.com/seata/seata\n本周推荐阅读 开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态\n RFC8998+BabaSSL\u0026amp;mdash;让国密驶向更远的星辰大海\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1626418800,"description":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210716/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cd4f09022c5b4338855eea46f50d5a9a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210716/","publishdate":"2021-07-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210716/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210716/","wordcount":993},{"author":"曾柯","categories":"SOFAStack","content":" 01 引言-TLS 1.3 协议及 SM 算法 说起 TLS，大家一定不会陌生，TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。自从 2014 年 Heartbleed 漏洞被发现以来，网络安全受人关注的程度越来越高，出于更安全更快捷的需求，TLS 1.3 协议也随之被提出，其相应的 RFC 于 2018 年正式发布。随着网络安全越来越受到重视，安全战略也逐步上升到国家战略的高度，国家密码局在 2010 年底公布了我国自主研制的“椭圆曲线公钥密码算法”（SM2 算法），并随后陆续发布了国密算法 SM1-SM9（SM 代表商密的拼音大写）。今天我们要分享的东西，就和 TLS 1.3 及国密有关。\n首先先让大家对这两者之间的关系有一个基本的概念，我们以一个典型的 TLS 1.2 中的密钥套件为例：\n 对应到我们的国密的算法上，则各个算法对应的套件如下：\n1、密钥交换算法：ECC-SM2，ECDHE-SM2（这里先不详细展开，只简单介绍一下，国密的密钥交换算法基于当前的椭圆曲线算法设计了两种专门的算法，而对应的曲线则是 SM2 曲线）；\n2、数字签名算法：SM2（SM2 既是签名算法的名称，同时在椭圆曲线算法中对应的曲线名也叫 SM2，有的博客文档里也将密钥交换算法称作 SM2，读者请注意不要混淆）；\n3、对称加密算法：SM4；\n4、hash 算法：SM3。\n也就是说，国密局针对安全握手各个阶段所需要的算法都出台了一份自主可控的算法。\n02 why 国密？why not 国密？ 先说说为什么要用国密，国密算法作为国密局的主力产品，肯定是在很多地方有优势的，先来总结下国密的典型优势：\n1、更安全：SM2 作为一种 ECC 算法（256 位）的安全性是要高于 2048 位的 RSA 的。同时 SM3 的摘要长度为 256 bit，安全强度也是要高于当时主流的 MD5 算法及 SHA1 算法的。\n2、更快速：在通讯过程中，256 位的 SM2 算法相比于 2048 位的 RSA 算法（国密算法在设计时，RSA2048 是主流签名算法，所以这里暂不讨论ECDSA等算法），可以传输更少的数据，也就意味着更少的传输时间，并且在理论上来说，SM2 签名算法的计算速度是要快过 RSA2048 不少的。\n3、自主可控：在目前这个国际形势下，这是最最最关键的一点！\n国密听起来像是中国密码的一次革新，但这些年却一直没有大面积推行开来，说明其本身肯定有一些问题的，这里抛开一些细节的小问题，谈一谈国密算法在大规模落地过程中遇到的一些比较棘手的问题：\n1.速度不够快（麻烦指数★★★）\n国密整个 TLS 会话流程中涉及到的几个算法，相对主流国际算法来说，大部分情况下性能均相对弱势，这里针对一些给出一些简单的性能对比表：\n对称加密算法性能对比：\n 签名算法性能对比：\n hash 算法性能对比：\n 从对比中我们可以看到，国密的这些算法目前和国际算法性能常常不在一个量级，无论是对称加密还是非对称加密的部分。究极根本原因，还是由于各种通用的国际算法普及程度太大，在工程上有着相应的多层次的优化（硬件计算和各种软加速手段），以对称加密为例：国密对称加密算法 SM4 对标的算法是 aes-128，从本身的加密原理上来看，SM4 在理论上不会和 aes-128 产生如此大的差距，然而 AES 由于普遍性实在太强，典型的 AES 实现都基于 Intel 的 SIMD 指令集对其进行了并行化加速，而 SM4 目前只有纯软的实现，性能上自然有不小的差距。不仅如此，目前的主流对称加密模式为 GCM 及 CCM 模式，其背后的思想为加密即认证技术（AEAD），而国密算法尚不支持这种模式，在安全性上也存在着一些弱点。\n2.需要双证书（★★★★）\n要把双证书讲清楚首先需要大家理解下 PKI 密钥协商机制，典型的密钥协商算法分为两种：RSA，ECDHE。国密的 ECC-SM2 密钥协商流程和 RSA 比较类似，算法核心的性质在于用公钥加密的数据可以用私钥解密，整个密钥协商流程简化如下图：\n 而 ECDHE-SM2 比较类似 ECDHE 算法，均是基于 DH 和 ECC 的算法，理解起来更加容易，流程简化如下图：\n 我们再来谈双证书这个事情，双证书分为签名证书和加密证书，这套体系的目的是满足国家对于敏感数据强管控诉求，即只要能抓到所有数据包，则管控机构则可以在理论上恢复出所有明文数据，由此催生出了加密证书这个东西，加密证书的私钥需要在专门的机构留底。我们来看 RSA 的密钥交换流程，只要拥有了私钥，则中间的密钥生成的材料（随机数）也就可以在理论上进行导出。而对于 ECDHE-SM2 来说，对称密钥的导出流程不仅仅只由随机数 a/c 来决定，同时也需要加密证书对应的私钥参与到计算中（具体流程比较繁琐，这里不展开，读者可参考 GM/T 0024 标准阅读详细的细节），也就意味着当私钥被监管，则对称密钥可以理论上被导出。\n这套体系很强悍，但难就难在目前所有主流密码库如 openssl，boringssl 都不支持，那么这也就意味着如果要推进这套体系的普适度，要么基于主流密码库开发，并推进开源社区接受，进而慢慢渗透到国内用户把这套体系用起来，要么在尽可能兼容目前密码体系的情况下开发一套新的密码库并强制国内用户替换，每一种办法都存在不小的难度。\n3.需要客户端也持有证书（★★★★★）\n国密在 GM/T 0024 标准里面定义了基于 ECDHE-SM2 算法的密钥交换流程，但这个算法的要求十分苛刻，必须要求 Client 也持有证书，的确这对于安全性有一定提升，但麻烦也就随之而来，支付宝的客户端目前没有证书，如果加上证书会让 App 更重，握手交互的数据更多，极大降低用户体验。这些问题还不够致命，如何管理海量的端上证书，才是真正令人头疼的麻烦。\n也许你会问：不用 ECDHE 不就好了嘛，但从技术的演进趋势来看，高效/安全是我们孜孜不倦的追求，而类 RSA 的握手流程则从根源上限制了国密 ECC 密钥交换流程无法演进到 1-RTT 握手，0-RTT 信息传输。不仅如此，ECHDE 的安全性及性能，也要好很多。在 TLS 1.3 的 1RTT 标准握手流程中，明确定义了废除 RSA 握手，只支持 ECDHE。目前这个情况就造成了一个死锁，想用 TLS 1.3-\u0026amp;gt;需要 ECDHE-\u0026amp;gt;需要 Client 有证书-\u0026amp;gt;没有证书且不想用证书-\u0026amp;gt;问题无解。\n03 重磅推出，TLS 1.3+ 国密算法套件 针对国密落地过程中的这些痛点问题，2019 年 8 月份，由蚂蚁的同学牵头，撰写了一份 TLS 1.3+ 国密算法 draft，并最终成为了一份 IETF 标准文档：\n 整个标准设计的核心思想是：整合目前国密算法优势，全面贴合国际上的安全技术思路，把不好用的东西先暂时剔除掉，提升国密算法在国内及国际上的影响力，从而让更多组织及个人参与到国密算法的使用和建设中来。基于这个思路，我们联合了 360 等公司，经过和国密局的多次沟通，正式推出了相关标准。在整个流程上，我们在 ECDHE 算法上取消了 Client 证书的要求，并暂时放 …","date":1626159600,"description":"RFC8998+BabaSSL---让国密驶向更远的星辰大海","dir":"blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"54dc71c8ea8dcfb0408a430934cb90c3","permalink":"https://sofastack.github.io/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","publishdate":"2021-07-13T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","summary":"01 引言-TLS 1.3 协议及 SM 算法 说起 TLS，大家一定不会陌生，TLS 可以说是整个互联网安全的基石，保障着我们的通信数据的安全。自从 2014 年 Heartbleed 漏洞被发","tags":["SOFAStack"],"title":"RFC8998+BabaSSL---让国密驶向更远的星辰大海","type":"blog","url":"/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/","wordcount":3534},{"author":"王发康","categories":"SOFAStack","content":" 注：本文是王发康（毅松）在 2021 GopherChina 上演讲的文字稿，相关分享 PPT 可自行到 MOSN meetup 下载。MOSN meetup 地址；MOSN 官方 Github 地址；GitHub 地址。\n 前言 MOSN 在 Service Mesh 领域作为东西向服务治理网络在蚂蚁集团双 11 、春节红包等活动及开源社区都得到了一定实践。为了能够让社区用户更好的享受到这一技术红利，MOSN 从 2018 年开源以来在社区开发者、用户的共同努力下，使得 MOSN 在云原生演进方面做了很多探索和实践。比如 Istio 下另一个数据面 — MOSN、WebAssembly 在 MOSN 中的探索与实践、MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章、MOSN 基于 Sentinel 的限流实践、MOSN 中玩转 Dubbo-go 等周边生态展开合作。\n2021 年为了更好的为业务提效，MOSN 开启了将云原生进行到底的决心。本文介绍了 MOSN 在网络扩展层的思考和技术选型，以及最终是如何通过使用 Envoy 作为 MOSN 的网络层扩展，从而实现 MOSN 和 Envoy 生态打通。使得网络层具备 C++ 高性能的同时，上层业务治理能力也能借助 GoLang 进行高效的定制化开发。\n 面临的问题及挑战 一、社区生态，如何最大化求同存异 最近几年 Service Mesh 技术在云原生社区也是百花齐放，虽然 MOSN 在开源社区也是备受开发者的关注，但是 Envoy 经过长久的发展其社区的活跃度和用户量的积累这点是不可忽略的。另外选择 MOSN 的用户都是看重其二次开发的便捷性以及 GoLang 的生态丰富，选择 Envoy 的用户主要是看重其高性能的网络处理能力及社区的活跃度。那我们是否能够通过技术的手段将其二者优势融为一体，发挥各自的特长，不要让用户顾此失彼。\n二、单一的 Proxy，无法支撑其架构的演进 在 Proxy 层面，无论是 MOSN 还是 Envoy 都是在各自领域中发挥优势。随着云原生技术的快速发展和成熟以及业务的增长，既要 Proxy 能够具备高研发效能，还要具备高处理性能，而单一的 Proxy 已经无法满足当前业务架构上的持续演进。\n东西向和南北向数据面 Proxy 逐步统一：两套数据面定位不同但功能上存在一定重叠，导致维护成本高，未来需要逐步收敛。这就要求 Proxy 不仅具备易扩展性方便业务方扩展东西向业务上的流量治理能力，而且还要具备抗高并发的能力满足南北向高流量转发。\nService Mesh 部署形态逐步向 Node 化架构演进：Service Mesh 规模化后，由于多出的 Proxy 势必会导致一定资源上的浪费，那在中心化和 Mesh 化之间做一次折中，即通过 Node 化部署形态来解决。Node 化后就要求 Proxy 能够高效、稳定的承载多个 POD 的流量治理。\nService Mesh 需要同时具备 Application Runtime 能力：虽然 Service Mesh 解决了微服务治理的痛点，但在实际业务开发中，缓存、数据库、消息队列、配置管理等，仍然需要维护一套重量级的 SDK 并且侵入应用代码。目前业界的解决方案是在 Service Mesh 的基础上多引入一个 Proxy 如 Dapr 来解决，这就导致应用的 POD 需要维护多个容器，所以如何让 Service Mesh 的 Proxy 具备快速复用 Dapr 能力成为解决该问题的关键。\n我们的思考 针对上述问题分析过后，其实背后的原因是有共性的。比如将其统一为一个 sidecar，如果单纯的从一个数据面改为另一个，那其中的改造成本是巨大的。那是否可以换个思路，为 MOSN 的网络层增加可扩展性，即可以让 MOSN 的网络处理直接下沉至 Envoy，同时将这个能力剥离出来成为 Envoy 在 GoLang 上的一个标准能力，这样就能够让 Envoy 和 MOSN 互相复用已有的能力。二者相互融合，各取所长，使其同时具备高研发效能和处理性能高，自然而然就解决上述“单一的 Proxy，无法支撑架构的演进”和“社区生态，如何最大化求同存异”所面临的问题。相互融合后，不仅融合了各种的优势，而且也能够把两边的生态打通，借此 MOSN 社区和 Envoy 社区能形成双赢的局面。\n 方案调研与分析 知道当前面临问题的原因后，便有了一个宏观的解决方向。于是就对此展开了相关调研，梳理了业界针对此问题的一些解决方案，综合各种方案的优劣势并结合蚂蚁业务现状以及开源社区用户的痛点进行了分析和评估。\n扩展方案调研\n 扩展方案评估\n 通过上述方案优劣势的对比以及评估，MOE（MOSN on Envoy） 相比 ext-proc 无需跨进程 gRPC 通信，性能高，易管理；相比 Envoy WASM 扩展无需网络 IO 操作转换成本；相比 Lua 扩展生态好、能复用现有的 SDK，对于处理上层业务更合适。\n同时我们将 Envoy 中增加 GoLang 扩展的这个方案也在 Envoy 社区进行了讨论，也得到了 Envoy 社区 Maintainer 的赞同。其中依赖的技术 CGO 是 GoLang 官方出品，该技术基本上在 GoLang 每个 release notes 中都有提到，说明也一直在维护的。另外业界也有很多项目在使用这项技术（比如：NanoVisor、Cilium、NginxUnit、Dragonboat、Badger、Go withOpenCV etc）其稳定性已经过一定的考验了，同时我们自己也测试了 CGO 自身的开销在 0.08 ~ 1.626 微秒，而且调用开销也是属于线性增长而非指数增长趋势。\n 所以综合稳定性、性能、改造成本以及社区生态等因素评估，MOE 解决方案无论在当前阶段还是未来都具备一定优势。\n方案介绍 一、整体架构 如下是 MOE 的整体架构图，最下面是各种高性能数据面，目前我们主要适配的是 Envoy。在数据面之上剥离了一层 GoLang L7 extension filter 的抽象，用于和底层的数据面连通；然后在 MOSN 侧通过 GoLang L7 extension SDK 将 MOSN 连通；最后通过 CGO 这个通道将 Envoy 和 MOSN 打通。\n 整体架构如上图所示，其核心包括如下三部分组成：\n1、GoLang L4/L7 extension filter\n使用 C++ 实现的 Envoy 侧的 GoLang L4/L7 filter ，该模块通过 CGO API 来调用 GoLang 实现的 L4/L7 extension filter。\n2、GoLang L4/L7 extension SDK\nGoLang L4/L7 extension SDK 会导出一些 CGO API，用于 Golang L4/L7 extension filter 和 L4/L7 extension GoLang filter 交互。\n3、L4/L7 extension filter via GoLang\nL4/L7 …","date":1625554800,"description":"开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态","dir":"blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e570e9fb3aba7b066d2e3b332ae18dbc","permalink":"https://sofastack.github.io/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","publishdate":"2021-07-06T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","summary":"注：本文是王发康（毅松）在 2021 GopherChina 上演讲的文字稿，相关分享 PPT 可自行到 MOSN meetup 下载。MOSN meetup 地址；MOSN 官方 Github 地址；GitHub 地址。 前言 MOSN 在 Service Mesh","tags":["SOFAStack"],"title":"开启云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态","type":"blog","url":"/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/","wordcount":5977},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@刘世杰 提问：\n 新接触 SOFABoot，有 2 个问题想请教一下： 1.如何根据不同的贡献方选择对应的扩展实现？贡献方有多个的情况下，覆盖了原始的对象，没看到如何根据身份定位具体实现的逻辑，不知道是遗漏了什么说明文档，我看的这个文档：https://www.sofastack.tech/projects/sofa-boot/extension/\n2.如何确保贡献方提供的 jar 包不对服务提供方产生影响？如果多个贡献方提供的 jar 包里间接依赖了不同版本的二三方的 jar 包。在同一个 classloader 下只能加载一个版本的 class，那对某些贡献方的逻辑处理可能会出现 NoClassDefFoundError 类的异常。SOFAArk 是具备了这种隔离的能力的，是否需要引入这种方式？\n A：1.如果有多个扩展点 x 的扩展地方，那么 A 的 registerExtension 就会被调用多次（与被扩展的次数一样，这个方法需要线程安全）；框架无法获知扩展者的身份，这个就需要扩展点提供方自行甄别。\n2.第二种情况，其实不仅限于 SOFABoot 中的扩展点，仅有一个 class loader 的情况下，会出现这种情况。个人认为在没有动态性要求的情况下，优先解决 maven 依赖冲突。\nSOFABoot：https://github.com/sofastack/sofa-boot\n2、@刘世杰 提问：\n 1.按照官网的 Demo，如果有多个贡献方 A、B、C，按照顺序执行了 registerExtension 方法，那 word 的值会以 C 为准吗？意思是不是说在运行时一个扩展点只有一个贡献方？\n2.如果贡献方比较多的话，这个后期的解决冲突的成本会不会比较高。还有些比较隐蔽的实现，可能不是太好测试出来，到生产才发现问题。另外，如果做动态的话在 SOFABoot 的技术栈里是扩展点 +Ark 的方式？\n A：1.这个顺序是没有保证的，SOFABoot 为了启动速度，并行化了上下文刷新的，因此可能是 A、B、C 顺序，也有可能是 C、B、A；运行时可以有多个实现的，这个取决于你的服务类型，以及如何实现的。\n2.可以这么理解，SOFAArk 就是一种动态扩展的方案。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@证道者 提问：\n MOSN mirror 功能是只能转发 Dubbo 的流量么？\n A：不是只能转发 Dubbo，都可以的。\nMOSN：https://github.com/mosn/mosn/\n本周推荐阅读 【感谢有你，SOFAer】一图看懂 SOFAStack 2021 半年报\n MOSN 多协议扩展开发实践\n MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1625209200,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210702/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5808aa4a754ad5a4024b619e1d61cba8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210702/","publishdate":"2021-07-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210702/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210702/","wordcount":1290},{"author":"永鹏","categories":"SOFAStack","content":" Service Mesh 是当今云原生的关键部分，蚂蚁已经在生产环境完成了大规模的落地，但是业界整体 Service Mesh 改造程度还不高。其中平稳的进行 Mesh 化改造是可以对已上线的业务进行 Mesh 化改造的前提，在平稳改造过程中，协议的支持又是最基础的部分。MOSN 提供的多协议扩展开发框架旨在降低使用私有协议的场景进行 Mesh 化改造的成本，帮助业务快速落地。\n MOSN 是蚂蚁自研的一款高性能网络代理，主要用于 Service Mesh 的数据面 Sidecar。Service Mesh，是近几年来云原生方向比较热门的话题，其主旨就是构建一个基础设施层，用来负责服务之间的通信。主要就是有一个和服务应用共同部署的 Sidecar 来实现各种中间件的基础能力，实现基础设施的标准化、和业务逻辑解耦，做到业务无感知的基础能力快速演进。目前国内很多公司都开始拥抱 Service Mesh，和蚂蚁合作的一些企业，如中信银行、江西农信等也基于 MOSN 完成了 Mesh 化的改造。\nService Mesh 架构的目的就是为了降低基础设施改造升级对业务造成的影响，但是如何平滑的从传统微服务架构转向 Service Mesh 架构也是一个非常有挑战的工作，这里涉及的细节很多，但是无论如何有一个最基础的问题就是我们在进行灰度 Mesh 化改造的时候，已经 Mesh 化的节点需要能和没有 Mesh 化的节点维持正常通信。而不同的公司选择的通信协议都有所不同，这就直接导致在技术选型的时候，选择的 Sidecar 需要能够支持所使用的协议。一些受到广泛应用的协议可能还会被陆续的支持，而有的协议可能还是公司自己定制的，因此不可避免的是需要基于 Sidecar 的扩展能力，进行二次开发以支持私有的协议。\n 多协议扩展框架 谈到 Service Mesh 的 Sidecar，就不得不提到 Envoy，这是一款被广泛应用的 Service Mesh Sidecar 代理。Envoy 的扩展框架支持开发者进行二次开发扩展，其中 Envoy 目前支持的不少协议就是基于其扩展框架开发实现的。在 Envoy 的扩展框架下，要扩展一个协议可以参考 Envoy 中 HTTP 协议处理的流程，包括 4 层 Filter 实现编解码部分与 Connection Manager 部分，在 Connection Manager 的基础上再实现 7 层的 Filter 用于支持额外的业务扩展、路由的能力、和 Upstream 的连接池能力。可以看到一个协议处理的流程几乎是贯穿了各种模块，实现一个协议扩展成本还是比较高的。\n 再来看一下 MOSN 的框架。MOSN 在一次协议处理上可以划分为四个层次，除开基本的从网络 IO 中获取数据的网络层以外，还可以划分为 protocol 层、stream 层与 proxy 层。其中 protocol 层负责协议解析相关编解码的工作，负责将数据流解析成 MOSN 可以理解的协议帧，或者将协议帧编码成二进制流；stream 层负责的内容就比较多了，包括处理不同的请求类型，初始化请求的上下文，关联事件，响应与请求之间的关联，还有 upstream 连接池相关的处理等，不同的协议处理的细节也会有所不同；proxy 层是一个协议无关的代理转发层，负责请求的路由与负责均衡等能力，同时也具备七层的扩展能力用于不同业务实现的扩展。根据这个架构，可以看到协议处理的核心就在于 protocol 层和 stream 层，相比于 Envoy 的设计来说，路由、七层扩展等部分是具备多协议复用的能力的。但是同时也可以看到 stream 层涉及的细节比较多，实现起来难度也是比较大的，为此 MOSN 在此基础上又提出了一个多协议扩展的框架，用于简化协议的实现。\n MOSN 的多协议框架主要就是针对 stream 层的复用扩展能力，在 MOSN 的协议处理分层设计中， network 层和 proxy 层在设计上就是协议无关可复用的，如果能做到 stream 层也进行复用，那么协议实现就只需要关注 protocol 层的编解码本身，实现难度就会大大降低了。那么 stream 层是不是具备可复用的能力的呢，我们认为对于大部分协议，尤其是 RPC 协议来说是可以的。首先我们对协议进行一个抽象，定义成 XProtocol 接口，表示任意的协议。每个协议实现都是实现一个 XProtocol 接口，它包括基础的编解码接口、一些特殊请求响应的构造接口（如心跳、异常）、还有协议的模型（如类似 HTTP 的 pingpong 模型，常见的 RPC 多路复用模型等），以及协议匹配的接口。所有的 XProtocol 协议实现通过 XProtocol Engine 关联起来，除了通过配置指定使用哪种协议进行处理以外，对于实现了协议匹配接口的协议来说，可以基于请求特征进行自动识别。然后我们对于 XProtocol 解析出的协议帧也进行统一的抽象，包括多路复用相关的接口、协议类型的判断（是请求，还是响应，或者是类似 Goaway 一类的控制帧，请求又可以细分为心跳请求、无响应的 oneway 请求等）、支持对协议帧的数据进行修改（Header/Body 的修改）、还有统一的状态码管理映射等。\n 在 MOSN 的协议处理分层机制下，以及有了以 XProtocol 和 XFrame 的抽象定义为核心的多协议扩展框架以后，我们在 stream 层就可以完全基于接口进行协议的处理，而不同的协议扩展实现者只需要专注于协议编解码本身，以及对编解码后的结果进行简单的接口适配，就可以完成在 MOSN 中的接入，由此获得 MOSN 中各种通用能力的支持，如限流扩展、路由引流等。对比 Envoy 中扩展协议实现部分可以看到是简化了不少的。当然 MOSN 这个多协议框架不能满足所有的协议情况，但是对于目前我们看到的大部分 RPC 协议，在配合上 proxy 层中七层 stream filter 扩展的基础上，都是可以很好的满足的。\n实践案例 下面以 MOSN 在社区合作伙伴中 Dubbo 协议落地的案例来详细的了解 MOSN 的多协议扩展。这里很多代码也是 MOSN 社区的同学贡献的。 在这个案例中，除了要求协议需要支持 Dubbo 以外，还希望使用像限流等这些基础的扩展能力，同时需要蓝绿分组等路由的能力，选择的控制面是 Istio，用于动态配置的下发。那这些需求在 MOSN 中是如何实现的呢？\n首先是协议解析部分，这里采用了基于开源的 dubbo-go 框架做协议实现，基于 dubbo-go 封装出了 MOSN 的 XProtocol 和 XFrame 模型；限流、xDS 等能力直接复用 MOSN 已有的实现，无需额外实现。但是这里有一个问题点就是 Istio 动态下发的路由配置是 HTTP 相关的，HTTP 的路由配置模型与 Dubbo 还是存在一定差异的，而修改 Istio 的成本会比较高，在这里就做了另外一层扩展。基于 MOSN 七层的 StreamFilters，在进行路由匹配之前对 Dubbo 协议进行定制化的处理，用来满足 HTTP 的 …","date":1624950000,"description":"MOSN 多协议扩展开发实践","dir":"blog/mosn-multi-protocol-extension-development-practice/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d5691b6aa90017e49d9726b702475306","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","publishdate":"2021-06-29T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","summary":"Service Mesh 是当今云原生的关键部分，蚂蚁已经在生产环境完成了大规模的落地，但是业界整体 Service Mesh 改造程度还不高。其中平稳的进行 Mesh 化改造是可以对已上线的业务","tags":["SOFAStack"],"title":"MOSN 多协议扩展开发实践","type":"blog","url":"/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/","wordcount":4141},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@证道者 提问：\n 应用调用端多语言可以，Layotto 服务能力是不是目前只能 golang 开发，java 可以开发服务能力集成到 Layotto 里吗？还有就是 Layotto 底座是 MOSN 可以不用这个吗？我目前有一个需要处理，就是数据库单表 crud，跨表的 crud，自己分页检索这个能力可以用 Layotto 吗？\n A：如果想用别的语言给 Layotto 做扩展的话，目前感觉可行的方法就是借助 wasm，但具体的方案我们还得调研一下，目前是只能用 golang 开发。 至于你说的这个需求，可应该以作为 Layotto state API 的一种实现组件。\nLayotto：https://github.com/mosn/layotto\n2、@证道者 提问：\n 目前提供 pub/sub 能力，流 stream 能力，状态能力，以后也会将一些通用的业务能力抽象下移到 Layotto 吗？我觉得有点像组件化，面向能力编程。\n A：是的，主要就是希望业务同学可以面向能力编程，比如只需要考虑自己是否需要 pub/sub 能力就行，而不需要管背后是 kafka 还是 rocketMQ 之类的，我们目前在规划的有分布式锁、可观测性能力的下沉，其他的能力会参考社区的反馈。\nLayotto：https://github.com/mosn/layotto\n3、@证道者 提问：\n 所有的都在 Layotto 里面跑，pubsub PRC 不会相互干扰吗?\n A：你指的是资源使用上的互相争抢是吧，目前我们 Service Mesh 落地，Sidecar 也是集成的有 RPC 和 消息能力的，Sidecar 本身主要还是一个转发通道，本身资源占用还是极少的，目前生产上也没有因为同时 Run RPC 和 消息导致互相干扰的现象产生。在 Layotto 这也是类似的场景，大部分业务在单机维度很难跑到极限性能峰值，基本上不会有互相干扰的情况出现。\nLayotto：https://github.com/mosn/layotto\n本周推荐阅读 MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章\n 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1624604400,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210625/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"edfd61aa9405dccf65be9b8703fa5a1f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210625/","publishdate":"2021-06-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210625/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210625/","wordcount":1070},{"author":"SOFAStack","categories":"SOFAStack","content":" 作者简介： 马振军，花名古今，在基础架构领域耕耘多年，对 Service Mesh 有深度实践经验，目前在蚂蚁集团中间件团队负责 MOSN、Layotto 等项目的开发工作。\n Layotto 官方 GitHub 地址:https://github.com/mosn/layotto\n点击链接即可观看现场视频：https://www.bilibili.com/video/BV1hq4y1L7FY/\nService Mesh 在微服务领域已经非常流行，越来越多的公司开始在内部落地，蚂蚁从 Service Mesh 刚出现的时候开始，就一直在这个方向上大力投入，到目前为止，内部的 Mesh 方案已经覆盖数千个应用、数十万容器并且经过了多次大促考验，Service Mesh 带来的业务解耦，平滑升级等优势大大提高了中间件的迭代效率。\n在大规模落地以后，我们又遇到了新的问题，本文主要对 Service Mesh 在蚂蚁内部落地情况进行回顾总结，并分享对 Service Mesh 落地后遇到的新问题的解决方案。\n一、Service Mesh 回顾与总结 A、Service Mesh 的初衷 在微服务架构下，基础架构团队一般会为应用提供一个封装了各种服务治理能力的 SDK，这种做法虽然保障了应用的正常运行，但缺点也非常明显，每次基础架构团队迭代一个新功能都需要业务方参与升级才能使用，尤其是 bugfix 版本，往往需要强推业务方升级，这里面的痛苦程度每一个基础架构团队成员都深有体会。\n伴随着升级的困难，随之而来的就是应用使用的 SDK 版本差别非常大，生产环境同时跑着各种版本的 SDK，这种现象又会让新功能的迭代必须考虑各种兼容，就好像带着枷锁前进一般，这样随着不断迭代，会让代码维护非常困难，有些祖传逻辑更是一不小心就会掉坑里。\n同时这种“重”SDK 的开发模式，导致异构语言的治理能力非常薄弱，如果想为各种编程语言都提供一个功能完整且能持续迭代的 SDK 其中的成本可想而知。\n18 年的时候，Service Mesh 在国内持续火爆，这种架构理念旨在把服务治理能力跟业务解耦，让两者通过进程级别的通信方式进行交互。在这种架构模式下，服务治理能力从应用中剥离，运行在独立的进程中，迭代升级跟业务进程无关，这就可以让各种服务治理能力快速迭代，并且由于升级成本低，因此每个版本都可以全部升级，解决了历史包袱问题，同时 SDK 变“轻”直接降低了异构语言的治理门槛，再也不用为需要给各个语言开发相同服务治理能力的 SDK 头疼了。\nB、Service Mesh 落地现状 蚂蚁很快意识到了 Service Mesh 的价值，全力投入到这个方向，用 Go 语言开发了 MOSN 这样可以对标 envoy 的优秀数据面，全权负责服务路由，负载均衡，熔断限流等能力的建设，大大加快了公司内部落地 Service Mesh 的进度。\n现在 MOSN 在蚂蚁内部已经覆盖了数千个应用、数十万容器，新创建的应用默认接入 MOSN，形成闭环。而且在大家最关心的资源占用、性能损耗方面 MOSN 也交出了一份让人满意的答卷： 1. RT 小于 0.2ms\n CPU 占用增加 0%~2%\n 内存消耗增长小于 15M\n 由于 Service Mesh 降低了异构语言的服务治理门槛，NodeJS、C++等异构技术栈也在持续接入到 MOSN 中。\n在看到 RPC 能力 Mesh 化带来的巨大收益之后，蚂蚁内部还把 MQ，Cache，Config 等中间件能力都进行了 Mesh 化改造，下沉到 MOSN，提高了中间件产品整体的迭代效率。\nC、新的挑战 应用跟基础设施强绑定 一个现代分布式应用，往往会同时依赖 RPC、Cache、MQ、Config 等各种分布式能力来完成业务逻辑的处理。\n当初看到 RPC 下沉的红利以后，其他各种能力也都快速下沉。初期，大家都会以自己最熟悉的方式来开发，这就导致没有统一的规划管理，如上图所示，应用依赖了各种基础设施的 SDK，而每种 SDK 又以自己特有的方式跟 MOSN 进行交互，使用的往往都是由原生基础设施提供的私有协议，这直接导致了复杂的中间件能力虽然下沉，但应用本质上还是被绑定到了基础设施，比如想把缓存从 Redis 迁移到 Memcache 的话，仍旧需要业务方升级 SDK，这种问题在应用上云的大趋势下表现的更为突出，试想一下，如果一个应用要部署在云上，由于该应用依赖了各种基础设施，势必要先把整个基础设施搬到云上才能让应用顺利部署，这其中的成本可想而知。 因此如何让应用跟基础设施解绑，使其具备可移植能力，能够无感知跨平台部署是我们面临的第一个问题。\n 异构语言接入成本高 事实证明 Service Mesh 确实降低了异构语言的接入门槛，但在越来越多的基础能力下沉到 MOSN 以后，我们逐渐意识到为了让应用跟 MOSN 交互，各种 SDK 里都需要对通信协议，序列化协议进行开发，如果再加上需要对各种异构语言都提供相同的功能，那维护难度就会成倍上涨，\nService Mesh 让重 SDK 成为了历史，但对于现在各种编程语言百花齐放、各种应用又强依赖基础设施的场景来说，我们发现现有的 SDK 还不够薄，异构语言接入的门槛还不够低，如何进一步降低异构语言的接入门槛是我们面临的第二个问题。\n二、Multi Runtime 理论概述 A、什么是 Runtime? 20 年初的时候，Bilgin lbryam 发表了一篇名为 Multi-Runtime Microservices Architecture 的文章，里面对微服务架构下一阶段的形态进行了讨论。\n如上图所示，作者把分布式服务的需求进行了抽象，总共分为了四大类： 1. 生命周期（Lifecycle） 主要指应用的编译、打包、部署等事情，在云原生的大趋势下基本被 docker、kubernetes 承包。\n 网络（Networking） 可靠的网络是微服务之间进行通信的基本保障，Service Mesh 正是在这方面做了尝试，目前 MOSN、envoy 等流行的数据面的稳定性、实用性都已经得到了充分验证。\n 状态（State） 分布式系统需要的服务编排，工作流，分布式单例，调度，幂等性，有状态的错误恢复，缓存等操作都可以统一归为底层的状态管理。\n 绑定（Binding） 在分布式系统中，不仅需要跟其他系统通信，还需要集成各种外部系统，因此对于协议转换，多种交互模型、错误恢复流程等功能也都有强依赖。\n 明确了需求以后，借鉴了 Service Mesh 的思路，作者对分布式服务的架构演进进行了如下总结：\n 第一阶段就是把各种基础设施能力从应用中剥离解耦，通通变成独立 sidecar 模型伴随着应用一起运行。\n第二阶段是把各种 sidecar 提供的能力统一抽象成若干个 Runtime，这样应用从面向基础组件开发就演变成了面向各种分布式能力开发，彻底屏蔽掉了底层实现细节，而且由于是面向能力，除了调用提供各种能力的 API 之外，应用再也不需要依赖各种各样基础设施提供的 SDK 了。\n作者的思路跟我们希望解决的问题一致， …","date":1624258800,"description":"MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章","dir":"blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","fuzzywordcount":7600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4ea3e26c4f2e5422816a186691849af5","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","publishdate":"2021-06-21T15:00:00+08:00","readingtime":16,"relpermalink":"/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","summary":"作者简介： 马振军，花名古今，在基础架构领域耕耘多年，对 Service Mesh 有深度实践经验，目前在蚂蚁集团中间件团队负责 MOSN、Layotto 等项目的开发工","tags":["SOFAStack"],"title":"MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章","type":"blog","url":"/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/","wordcount":7525},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙力 提问：\n 请问和 MOSN 相关的健康检查有什么可行的方案吗？比如如何检查 MOSN 的健康状态，MOSN 检查业务容器健康，检查失败后有什么降级或动作？\n A：MOSN 有获取运行状态的 API ，\nhttps://github.com/mosn/mosn/blob/master/pkg/admin/server/apis.go#L301\n检查业务容器健康通常来说需要自己扩展。\nhttps://github.com/mosn/mosn/blob/9a53d7239d8d5ca987410c15d791e780b5809558/pkg/upstream/healthcheck/factory.go#L53\n健康检查也有回调可以注册，可以实现自己的降级逻辑。\nMOSN：https://github.com/mosn/mosn\n2、@许玉杰 提问：\n AT 模式是怎么做到的空回滚、防悬挂和幂等的啊？\n A：幂等是用户自己做的，防悬挂和空回滚有 undolog，AT 的幂等等于接口幂等，自己的接口保证即可。\nSeata：https://github.com/seata/seata\n3、@jueming 提问：\n Seata 支持 mybatis 的注解开发吗？目前用的 seata1.0 的版本，需要配置代理数据源，但是配置之后，影响了其他 sql 的执行，代理执行了 sql 的方法，打印了相关 sql 语句（数据库里有数据），但是得到的实体却为空。我把代理关闭以后则不影响 sql 的查询，这种情况应该怎么解决？\n A：这里的问题是添加代理数据源的时候，使之前的 datasource 自动失效，没有读取 mybatis 的配置，解决方法是在设置新的 sqlsessionfactory 的时候，把需要配置的属性通过 ibatis 包下的 Configuration 注入进去。\nSeata：https://github.com/seata/seata\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623999600,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-20210618/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c8d740f2b60544b872580120fd456cde","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210618/","publishdate":"2021-06-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210618/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210618/","wordcount":902},{"author":"SOFAStack","categories":"SOFAStack","content":" GoCN：贵司从什么时候开始用 Go，基于什么原因，还记得第一个用 Go 的项目是什么吗?\n宋顺：早在 2015 年，蚂蚁的基础设施团队就已经使用 Go 来尝试优化资源调度能力，当时还是基于 Docker Swarm 做的一些调度平台，这个时期没有持续太长就逐步切换到了 Kubernetes，蚂蚁内部的版本叫 Sigma，当前 Sigma 已经承担起了蚂蚁内部所有集群的资源调度，并且也在逐年提升资源利用率，为公司节省了不少的成本。\nGoCN：现在有多少人用 Go，或者 Go 开发比例占到多少？\n宋顺：目前 Go 主要用于蚂蚁的基础设施团队，在资源调度、弹性伸缩、安全容器、日志无盘、Service Mesh、Serverless 等场景中广泛应用，Go 的开发人员在基础设施团队内部占比高达 50% 以上，业务团队大部分还是以 Java 为主。\nGoCN：Go 有哪些特性是非常匹配贵司业务和开发需求的，有哪些是让人很抓马的，希望有哪些改进？\n宋顺：Go 的简单易学、安全编码、研发效率、活跃生态等特性是非常符合我们的需求的。抓马的主要还是性能，如大规模下 gc 抖动，调度延迟等。改进方面希望能够有比 channel 更轻量的 Go block/wake 机制，这块我们也在和社区讨论中：https://github.com/golang/go/issues/46431\nGoCN：目前来看 Go 在项目中普及的难度是什么，在招聘方面有困难吗?\n宋顺：在基础设施层面普及没有太大难度，后续如果在业务团队中也能顺畅的使用 Go 还是需要我们的 Service Mesh 体系对多语言体系的支撑更加完善，让业务能更少的感知底层能力从而专注业务开发。我们即将开源的 Layotto 就是希望在 Runtime 层面通过统一的 API 定义，从而可以让各种语言都非常简单的享受到分布式架构的红利，为业务提效。 在招聘方面由于目前 Go 主要用于基础设施，所以我们需要的是对网络、系统内核、高性能有较多经验的人才，不过眼下这类人才还是比较稀缺的。\nGoCN：希望招到具备哪方面能力的 Go 工程师？\n宋顺：有高性能网络编程和性能优化经验，对分布式系统有较深理解，对 Go Runtime 有一定研究的 Gopher 工程师。\nGoCN：对本次大会的期待是什么？\n宋顺：希望了解 Go 在更多公司的实践经验、学习 Go 语言自身的特性演进以及和更多的 Gopher 现场交流。\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623740400,"description":"Gopher China 2021 专访之宋顺：Go 在蚂蚁集团的应用、实践","dir":"blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e6d1f215ee12ebb60c2cc4fda0b64d82","permalink":"https://sofastack.github.io/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","publishdate":"2021-06-15T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","summary":"GoCN：贵司从什么时候开始用 Go，基于什么原因，还记得第一个用 Go 的项目是什么吗? 宋顺：早在 2015 年，蚂蚁的基础设施团队就已经使用 Go 来尝试优化资","tags":["SOFAStack"],"title":"Gopher China 2021 专访之宋顺：Go 在蚂蚁集团的应用、实践","type":"blog","url":"/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/","wordcount":990},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@孙军超 提问：\n 实际项目中，怎么动态的配置 # 集群列表中所有节点的地址列表initialServerList: 127.0.0.1:8181,127.0.0.1:8182,127.0.0.1:8183比如加一个节点 这个列表怎么自动刷新 。\n A：通过 CliService 动态增上改节点。\nSOFAJraft：https://github.com/sofastack/sofa-jraft\n2、@王国鑫 提问：\n 请教一下，其中一个 follow 机器，在状态机 onApply 里执行任务，有一些异常，这个异常状态如何上报给 leader？\n A：异常分两种，跟上不上报 leader 没什么关系，也不需要上报 leader。leader 只负责感知对应 follower 能不能跟上 raft log， 不论 raft 还是 paxos，都可以理解为分布式日志状态机，你这个异常是你自己的业务状态机里的事情了，raft 只保证 raft log 一致，你自己需要保证相同的 raft log 你要产生相同的结果。\nSOFAJraft：https://github.com/sofastack/sofa-jraft\n3、@陈泽胜 提问：\n 我想问一下我这个是什么问题？ 这是偶发的，两三天会出现一次，有时候一小时内会出现多次。\n Seata：https://github.com/seata/seata\n本周推荐阅读 揭秘 AnolisOS 国密生态，想要看懂这一篇就够了\n 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1623394800,"description":"SOFA Weekly | QA 整理","dir":"blog/sofa-weekly-0611/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"74bd4ee2b575599848e566b632980c07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0611/","publishdate":"2021-06-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0611/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0611/","wordcount":896},{"author":"","categories":"SOFAStack","content":" 主题：从数据库到架构，我们来聊透分布式\n时间：2021年6 月 19 日（周六）13：00 -17：30\n活动地点：北京海淀中关村创业大街 72 号拓荒族众创空间\n报名方式：点击http://hdxu.cn/Iq6Ef 即可报名。\n扫描海报上面的二维码，即可报名。\n【重要提醒】2021 年 6 月 19 日将有惊喜送出，欲知惊喜为何，请待 619 给您分解。\n6月初， OceanBase 诚意开源，正式揭开 300 万 C++ 数据库内核代码的神秘面纱。\n本次线下 Meetup，由 OceanBase \u0026amp;amp; SOFAStack 联合举办，也是 OceanBase 开源之后的首次线下活动。\n本次分享将邀请来自 OceanBase 和 SOFAStack 两个开源项目的四位专家，分别从云原生分布式架构、分布式 HTAP 数据库，以及新发布的时序数据库 CeresDB 来层层解开分布式的魅力。\n 报名方式：\n1、 扫描海报二维码，立即报名；\n2、 点击http://hdxu.cn/Iq6Ef 即可报名。\n在活动现场不仅仅可以和讲师面对面交流\n还有精美礼品发放，快来现场吧~\n","date":1623135600,"description":"【活动报名】SOFAMeetup#6 北京站，从数据库到架构，聊透分布式，玩转 Layotto","dir":"activities/sofa-meetup-7/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"884ed3d8cfc6d7b0784dbda5a27315b1","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-7/","publishdate":"2021-06-08T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-meetup-7/","summary":"主题：从数据库到架构，我们来聊透分布式 时间：2021年6 月 19 日（周六）13：00 -17：30 活动地点：北京海淀中关村创业大街 72 号拓荒族众创空","tags":["SOFAStack"],"title":"【活动报名】SOFAMeetup#6 北京站，从数据库到架构，聊透分布式，玩转 Layotto","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-7/","wordcount":371},{"author":"","categories":"SOFAStack","content":" 此文原系 2021 年阿里云开发者大会，开源操作系统社区和生态分论坛，题为《国密技术开发与实践》的分享会后解读。 AnolisOS 国密是社区在 AnolisOS 上做的国密技术解决方案，非常欢迎业界有兴趣的开发者能够参与到 OpenAnolis 社区，为国内的基础软件生态添砖加瓦。\n演讲嘉宾： 杨洋：蚂蚁集团高级技术专家，主导开发了 BabaSSL，也是国内唯一的一个 OpenSSL maintainer，参与起草并推动 RFC8998 标准国际化。 张天佳：阿里云技术专家，主要负责 AnolisOS 上国密技术的开发和应用，参与实现了 libgcrypt 中的国密算法和 linux 内核中的 SM2 算法。\n 让我们穿越回现场： \u0026amp;gt;\u0026amp;gt;缘起 说到密码算法，大家一定很熟悉 MD5，AES，RSA 这些通用的国际标准算法，这也是目前我们普遍采用的密码学算法，它们在数据安全、通信、区块链等众多领域都有着广泛的应用。\n众所周知，这些算法标准都是国外制定的，在某些情况下这会对国内信息安全有不利影响。当下有实力的国家，甚至有些大公司都制定了自己的算法标准。\n顾名思义，国密就是密码算法的国产化，跟其它领域一样，密码算法的国产化已经势不可挡，这也是我们必须要做的事情。中国的国密算法为我们提供了一个新的选择，在必要的场合中可以选择替代那些国际主流算法，尤其是当下国际贸易冲突，技术封锁不可忽视的大环境下，大规模推广和采用国密算法将为国内重要的网络基础设施提供可靠的数据安全保障。\n国密简介 我是谁，从哪里来\n国密是一个口语化的称呼，官方名称是国家商用密码，简称商密，拼音缩写是 SM，这也是国密标准中具体算法名字的来源。国密是用于商用的、不涉及国家秘密的密码技术。\n国密标准完全由中国密码管理局制定，主要的技术实现也基本是国内开发人员完成的，这对摆脱国外的密码技术和产品依赖是非常有利的。\n到哪里去\n自 2012 年以来，SM2/3/4 的国密标准陆续公布，目前国密技术生态基本处于一个正在逐步走向成熟的阶段，但国内密码基础软件在采用国密算法方面仍处于碎片化的状态，比如我们经常可以看到各种个人或组织名义开源的支持国密算法的库；此外这些开源项目的安全更新和社区活跃也都做的不好。国密的推广仍然需要我们中国基础软件的开发者和用户共同努力。\n2020 年 1 月 1 日，《中华人民共和国密码法》正式实施，从法律层面规范了国家商用密码的应用和管理，这也为推广和应用国密提供了必要的法律保障。\n与国际算法的对比\n这里是国密算法和国际通用算法的一个对比，可以直观地看到国密的一个基本情况：\n 针对各种常用的国际能用算法类型，比如对称算法，公钥算法和消息摘要算法，国密标准都定义了对应的相同功能的国密算法，比如 SM4 提供了与 AES 同样的加密强度，并且支持各种加密模式； SM2 是基于椭圆曲线的公钥算法，同时定义了非对称加解密，数字签名和密钥交换标准，相对于 RSA，SM2 的密钥更短，但支持的加密强度却更高；SM3 是国密定义的消息摘要算法标准，摘要长度是固定的 256 位，强度等同于 SHA256。\n除了基础的算法，国密标准也定义了 TLCP 国密双证书协议，用以支持国内的传输层安全协议。这里还有一个好消息，今年三月份，TLS1.3+国密单证书协议正式被国际标准所承认，并且以 RFC8998 标准发布，这意味着我们可以选择在 TLS1.3 协议中使用完整的国密套件，目前我们也在联系正规浏览器厂商支持这个标准的实施和应用。\n同时国密也定义了使用国密算法的 X509 证书，使用 SM3 哈希算法，SM2 算法作为数字签名，证书类型是 SM2-with-SM3。\n对开发者来说，国密提供了一个选择，可以选择从国际通用算法平滑迁移过来。除此之外，国密还有其它一些算法标准，是不太常用的，比如 SM9，ZUC 算法等。\nBabaSSL 前世今生 BabaSSL 是主打国密的密码算法库，与 OpenSSL 1.1.1 保持兼容，作为国密的密码算法解决方案而诞生。\nBabaSSL 是基于之前蚂蚁集团和阿里集团内部的 OpenSSL 版本合并而来，并首次进行了开源。BabaSSL 的含义是：灵巧、轻快且靠谱的密码学和 SSL/TLS 工具库。\nBabaSSL 的绿色商标，是基于阿里的橙色和蚂蚁的蓝色混合而来，也意味着我们希望将 BabaSSL 打造成一个灵活、小巧并且健壮的基础密码学库。\nBabaSSL 目前在阿里集团和蚂蚁集团内部得到了非常广泛的使用。从具体场景来看，有如下三个方面，分别是存储、网络和端上的设备。其中网络服务的场景，是 BabaSSL 最大的支撑场景，例如淘宝、天猫、阿里云等各种涉及到链路加密的服务器端。此外移动端 App，例如支付宝手机 App 中集成了 BabaSSL 来实现多种密码学的能力。\n开源 BabaSSL 已经在去年的 10 月份进行了开源，目前代码是托管在 OpenAnolis 上，当前开源的版本是 8.2.0，也是我们目前最新的稳定版本。\n目前 BabaSSL 在阿里内部使用的版本和开源版本之间存在一定的差异，我们目前正在逐步把内部版本的功能特性迁移到开源版本上进行开源，最终变成一个统一的开源版本，那么届时阿里内部也完全依赖于这个开源的版本，而不会再保留内部的闭源版本。\n特色功能 以下是 BabaSSL 当前最新稳定版本 8.2.0 的主要特色功能特性：\n 基于 OpenSSL 1.1.1，具备 OpenSSL 1.1.1 的全部能力并且保持兼容 支持国密 SM2, SM3 和 SM4，并对 OpenSSL 1.1.1 中所欠缺的 SM2 能力，比如 X509 证书的签发和验证功能进行了补全 GM/T 0024 和 TLCP 国密双证书 TLS 协议 支持 RFC 8998：TLS 1.3+国密单证书 提供了对 IETF 正在标准化过程中的 Delegated Credentials 支持 IETF QUIC API 底层密码学能力 更加完善的 SM2 算法支持，比如 X.509 证书签发、验签的支持 正在申请软件密码模块一级资质 与 OpenSSL 对比 接下来是大家很关心的 BabaSSL 和 OpenSSL 这种老牌的密码算法库之间的区别：\n 从图上可以看到一些主要区别：\n对于一些新的密码学技术标准，BabaSSL 会采取一种相对激进的策略快速跟进，比如在 IETF 中一些正在标准化流程中的技术方案，例如 delegated credentials, compact TLS 等，会进行原型的实现和快速跟进，而 OpenSSL 则是相对保守，因为 OpenSSL 社区的策略是原则上只实现已经发布了的国际标准和国家标准。 在对于国密算法、国密协议、国密的监管合规、云计算厂商的深度集成、以及国产化硬件等方面， BabaSSL 会进行更加深度和广泛的支持，而 OpenSSL 则支持的比较有限。 对于 API 的易用程度，由于没有历史包袱，所以 BabaSSL 可以提供更加简单易用的 API，而OpenSSL 的 API 则相对复杂。对于资源受限的嵌入式设备，BabaSSL 会进行体积裁剪和内 …","date":1623135600,"description":"揭秘 AnolisOS 国密生态，想要看懂这一篇就够了","dir":"blog/the-secret-of-anolisos/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"447fa6eedb1d5ccdea4c37803a2b0dc3","permalink":"https://sofastack.github.io/sofastack.tech/blog/the-secret-of-anolisos/","publishdate":"2021-06-08T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/the-secret-of-anolisos/","summary":"此文原系 2021 年阿里云开发者大会，开源操作系统社区和生态分论坛，题为《国密技术开发与实践》的分享会后解读。 AnolisOS 国密是社区在 AnolisOS 上做的国密技术解决方案","tags":["SOFAStack"],"title":"揭秘 AnolisOS 国密生态，想要看懂这一篇就够了","type":"blog","url":"/sofastack.tech/blog/the-secret-of-anolisos/","wordcount":3702},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@郭晶晶 提问：\n 蚂蚁内部的 SOFAMesh 对 Istio 的 pilot 进行了哪些扩展？是不是内部的 SOFAMesh 才支持 zk 注册中心。\n A：蚂蚁内部用的注册中心是 https://github.com/sofastack/sofa-registry 在服务发现这块是有跟 SOFARegistry 做对接，内部的模块更多还是适应内部的各种配套设置和架构做的一些定制。\nMOSN：https://github.com/mosn/mosn\n2、@王庆振 提问：\n https://github.com/sofastack/sofa-bolt/issuse/257 Connection 对象不应该是对应一个 poolkey（ip:port）吗？为什么 Connection 中还会持有 poolkey 的集合\n A：这个是因为 Bolt 还要服务消息中间件的，消息这边有一个 Connection 对应多个上层对象的场景，poolKey 不是 ip:port 的形式。\nSOFABolt：https://github.com/sofastack/sofa-bolt\n3、@jueming 提问：\n 这一步如果抛出异常，那么是不是不会释放 connection 连接？导致长期占有数据库连接。 A: 会释放，close 是框架层面出现异常自动就会调，如果你自己写 jdbc，你也肯定捕获一次做 rollback close了，这属于框架和业务上的处理，Seata 只不过把异常抛出去。\nSeata：https://github.com/seata/seata\n本周推荐阅读 助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案\n 用安全计算保护关键业务\n 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 本周发布 本周发布详情如下：\n本周发布 MOSN v0.23.0 版本，主要变更如下： 1.新增基于 networkfilter 的 grpc server 扩展实现能力；\n2.新增 TLS 连接的证书缓存，降低内存占用；\n3.修复 HTTP1 协议的 URL 编码与大小写敏感问题；\n4.新增 so plugin 扩展协议实现的示例；\n5.其他 BUG Fix 与优化。\n详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.23.0\n更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1622790000,"description":"SOFA Weekly | MOSN 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210604/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"47a5a019bacbf28f24ea5e9cbad7fc20","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210604/","publishdate":"2021-06-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210604/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210604/","wordcount":951},{"author":"","categories":"SOFAStack","content":" 机器学习（ML）和深度学习（DL）在众多真实的应用场景中愈发重要。这些模型使用已知数据进行训练，并部署在图像分类、内容推荐等场景中进行新数据的处理。总体而言，数据越多，ML/DL 模型就越完善。但囤积和处理海量数据也带来了隐私、安全和监管等风险。 隐私保护机器学习（PPML）有助于化解这些风险。其采用加密技术差分隐私、硬件技术等，旨在处理机器学习任务的同时保护敏感用户数据和训练模型的隐私。 在英特尔® 软件防护扩展（英特尔® SGX）和蚂蚁集团用于英特尔® SGX 的内存安全多进程用户态操作系统 Occlum 的基础上，蚂蚁集团与英特尔合作搭建了 PPML 平台。在本篇博客中，我们将介绍这项运行在 Analytics Zoo 上的解决方案，并展示该解决方案在第三代英特尔® 至强® 可扩展处理器上得到英特尔® 深度学习加速（英特尔® DL Boost）技术助力时的性能优势。\n 英特尔® SGX 是英特尔的受信任执行环境（TEE），它提供基于硬件的内存加密，隔离内存中的特定应用代码和数据。英特尔® SGX 使得用户层代码可以分配内存中的受保护区域，即 “飞地”，这些区域不受更高权限等级程序运行的任何影响（如图一所示）。\n 图一 通过英特尔® SGX 加强防护\n 与同态加密和差分隐私相比，英特尔® SGX 在操作系统、驱动、BIOS、虚拟机管理器或系统管理模型已瘫痪的情况下仍可帮助防御软件攻击。因此，英特尔® SGX 在攻击者完全控制平台的情况下仍可增强对隐私数据和密钥的保护。第三代英特尔® 至强® 可扩展处理器可使 CPU 受信任内存区域增加到 512GB，使得英特尔® SGX 技术能够为隐私保护机器学习解决方案打下坚实的基础。\n2014 年正式成立的蚂蚁集团服务于超 10 亿用户，是全球领先的金融科技企业之一。蚂蚁集团一直积极探索隐私保护机器学习领域，并发起了开源项目 Occlum。Occlum 是用于英特尔® SGX 的内存安全多进程用户态操作系统（LibOS）。使用 Occlum 后，机器学习工作负载等只需修改极少量（甚至无需修改）源代码即可在英特尔® SGX 上运行，以高度透明的方式保护了用户数据的机密性和完整性。用于英特尔® SGX 的 Occlum 架构如图二所示。\n 图二 用于英特尔® SGX 的 Occlum 架构（图片来源：Occlum · GitHub）\n Analytics Zoo 赋能端到端 PPML 解决方案 Analytics Zoo 是面向基于 Apache Spark、Flink 和 Ray 的分布式 TensorFlow、Keras 和 PyTorch 的统一的大数据分析和人工智能平台。使用 Analytics Zoo 后，分析框架、ML/DL 框架和 Python 库可以在 Occlum LibOS 以受保护的方式作为一个整体运行。此外，Analytics Zoo 还提供安全数据访问、安全梯度与参数管理等安全性功能，赋能联邦学习等隐私保护机器学习用例。端到端 Analytics Zoo PPML 解决方案如图三所示。\n 图三 端到端 PPML 解决方案为金融服务、医疗卫生、云服务等应用领域提供安全分布式计算\n 在 Analytics Zoo PPML 平台上，蚂蚁集团与英特尔共同打造了一个更加安全的分布式端到端推理服务流水线（如图四所示）。 该流水线采用 Analytics Zoo Cluster Serving 打造，后者是轻量级分布式实时服务解决方案，支持多种深度学习模型，包括 TensorFlow、PyTorch、Caffe、BigDL 和 OpenVINOTM。 Analytics Zoo Cluster Serving 包括 web 前端、内存数据结构存储 Redis、推理引擎（如面向英特尔® 架构优化的 TensorFlow 或 OpenVINO™ 工具套件），以及分布式流处理框架（如 Apache Flink）。 推理引擎和流处理框架在 Occlum 和英特尔® SGX “飞地” 上运行。web 前端和 Redis 受到传输层安全（TLS）协议加密，因此推理流水线中的数据（包括用户数据和模型）在存储、传输、使用的过程中都受到更多地保护。\n 图四 推理服务流水线\n 共创美好未来：英特尔® DL Boost 加速端到端 PPML 解决方案 1.该解决方案执行如下端到端推理流水线： RESTful http API 接收用户输入，Analytics Zoo pub/sub API 将用户输入转化成输入队列，并由 Redis 管理。用户数据受加密保护。 2.Analytics Zoo 从输入队列中抓取数据。它在分布式流处理框架（如 Apache Flink）上采用推理引擎进行推理。英特尔® SGX 使用 Occlum 来保护推理引擎和分布式流处理框架。英特尔® oneAPI 深度神经网络库（oneDNN）利用支持 Int8 指令集的英特尔® DL Boost 提高分布式推理流水线的性能。 3.Analytics Zoo 从分布式环境中收集推理输出，并送回到由 Redis 管理的输出队列。随后，解决方案使用 RESTful http API 将推理结果作为预测返回给用户。输出队列中的数据和 http 通信内容都被加密。\n性能分析 Analytics Zoo PPML 解决方案的性能进行了验证。\n 表一 测试配置\n 图五为测试结果。与不受英特尔® SGX 保护的推理流水线相比，当推理解决方案受到英特尔® SGX 保护，ResNet50 推理流水线的吞吐量会有少许损失。而采用支持 INT8 指令集的英特尔® DL Boost 后，受英特尔® SGX 保护的推理流水线吞吐量翻了一番。\n 图五 英特尔® SGX、英特尔® DL Boost 和第三代英特尔® 至强® 可扩展处理器提供高性能安全能力\n 基于英特尔® SGX 打造的 Analytics Zoo PPML 解决方案继承了受信任执行环境（TEE）的优点。和其它数据安全解决方案相比，它的安全性和数据效用性十分突出，性能方面仅略逊于纯文本。英特尔® DL Boost 和英特尔® oneDNN 则进一步提升了 Analytics Zoo PPML 推理解决方案的性能。表二总结了该解决方案（TEE）相对于同态加密（HE）、差分隐私（DP）、安全多方计算（MPC）和纯文本的优势。\n 表二 Analytics Zoo PPML 解决方案（TEE）与其他方案的比较\n 总结 在日益复杂的法律和监管环境中，对于企业和组织来说，保护客户数据隐私比以往任何时候都更加重要。在隐私保护机器学习的助力下，企业和组织就能在继续探索强大的人工智能技术的同时，面对大量敏感数据处理降低安全性风险。 Analytics Zoo 隐私保护机器学习解决方案基于 Occlum、英特尔® SGX、英特尔® DL Boost 和 Analytics Zoo 打造，为助力确保数据的安全性和大数据人工智能工作负载性能提供了平台解决方案。蚂蚁集团和英特尔共同打造并验证了这一 PPML 解决方案，并将继续合作探索人工智能和数据安全性领域的最佳实践。\n测试 …","date":1622530800,"description":"助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案","dir":"blog/Helping data security: Ant and Intel work together to create a verified PPML solution/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ccebaadae29c36d85ccb2d8216b6f9b4","permalink":"https://sofastack.github.io/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","publishdate":"2021-06-01T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","summary":"机器学习（ML）和深度学习（DL）在众多真实的应用场景中愈发重要。这些模型使用已知数据进行训练，并部署在图像分类、内容推荐等场景中进行新数据","tags":["SOFAStack"],"title":"助力数据安全：蚂蚁携手英特尔共同打造验证PPML解决方案","type":"blog","url":"/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/","wordcount":2757},{"author":"顾宗敏","categories":"SOFAStack","content":" 什么是安全计算？ Linux 基金会旗下的安全计算联盟对安全计算下了一个定义：\n Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential Computing Consortium\n 在这个定义中强调了这么几点：\n1.安全计算保护的是运算过程中的数据安全;\n2.安全计算需要借助硬件的能力。\n下面就对这两点做一个阐述： 在云计算场景，我们可以把云计算简化为三个部分：数据的传输，数据的运算和数据的存储。\n 这个三个部分的安全解决方案的完整度是有差别的。在数据的传输环节，业界有很完整的安全标准和实现比如 SSL， TLS。在数据存储环节，密码学也提供了非常好的解决方案，我们可以将数据用恰当的方式加密以后保存，防止在存储环节泄密。在数据的运算环节，还没有和其他两个环节那样完整的解决方案。安全计算正是以解决这个问题为目标的。\n安全计算是如何实现的呢？ 我们以英特尔的 SGX 技术为例来看一下具体的技术方案。\n 英特尔的 SGX 技术是将 CPU 作为运算的信任起点，在应用程序中构建安全的运算环境（飞地）。从计算机发明的那一天起，我们就假设 CPU 会按照软件的指令正确地执行，只是没有强调这一点。在软件大发展的今天，各种软件在一台硬件上协作运行，整个生态越来越复杂，恶意软件也出现了。为了防止恶意软件的破坏，CPU 为需要保护的应用隔离出一个独立的飞地环境。飞地外的应用既不能观察也不能修改飞地中的代码和数据，从而保证了飞地中的数据安全。CPU 对飞地的保护非常强，即使是拥有高特权的操作系统和虚拟化管理软件也无法突破这种保护。事实上，不仅仅可以防软件的攻击，哪怕是外围硬件提供者（比如：主板制造者，内存提供者）都无法突破这个保护。\n英特尔 SGX 是目前最成熟的安全计算产品，但并不是唯一的安全计算产品。其他硬件厂商如 AMD，ARM，Nvidia 都在推出安全计算产品。所有这些产品都是软硬件一体的解决方案，总结起来有以下这些特点：\n 在了解了安全计算的概念后，介绍一些安全计算的典型场景：\n 有了安全计算环境，用户可以放心地将应用放到共有云计算环境中，计算中用到的数据和计算的结果都可以加密传输。这样可以统一基础设施的架构，避免复杂的混合云部署方式。\n 云上的数据交易和数据服务也成为了可能。数据拥有方和算法提供方可以分别提供数据和算法至安全计算平台完成计算而不用担心机密泄露的问题。\n 安全计算也可以促成更多的数据合作。各方数据可以在一个安全的环境中做融合运算，让数据产生更大的价值。\n 在边缘计算场景中，计算节点部署在非常复杂的环境中，机器不受控。安全计算可以有效地保护用户数据和隐私。\n安全计算这么多的应用场景，为什么还没有看到大规模部署呢？这是因为安全计算目前还有一个非常大的短板：易用性不强。具体表现为3点：\n应用分割难：将一个现有的应用改造为一个安全计算应用的改造难度很大。需要做代码分割。\n场景部署难：安全计算是要依托于硬件的。在实际部署中需要对应用调度系统做改造。\n安全分析难：一个应用使用了安全计算是不是就一定安全了呢？答案是不确定。这需要对整个应用做非常细致的安全分析。\n针对这些难题，蚂蚁集团和阿里巴巴集团的工程师提出了独到的解决方案。 首先是解决应用分割难的问题。\n 蚂蚁集团开源的 Occlum 项目在飞地中开发了 LibOS 适配层，让 Linux 下的应用可以无修改地运行在 SGX 环境中，彻底解决了应用分割的问题。Occlum 使用 Rust 语言开发，保证内存了安全性；支持多进程和加密文件系统，应用无需修改。 例如：基于蚂蚁集团金融级云原生框架 SOFABoot 开发的应用可以完全无修改的运行在 Occlum 环境中。\n👇网站链接🔗： https://github.com/occlum/occlum/tree/master/demos/sofaboot\n针对部署难的问题，阿里云推出了 Inclavare 开源项目。\n Inclavare 基于 Occlum，为用户提供了安全计算容器。用户只需将关注的重点放在应用本身即可，Inclavare 会将计算调度至合适的计算节点。 针对安全分析难，蚂蚁集团的 MORSE 多方安全计算引擎和 MYTF 区块链计算平台分别为不同的计算场景提供了解决方案。用户无需再承担高昂的安全分析成本。\n 蚂蚁集团在安全计算领域持续投入，用科技的力量来保护数据安全，保护用户隐私，给用户提供更安全的服务。蚂蚁集团开源了 TEE 安全 LibOS Occlum。 用户可以在 https://github.com/occlum/occlum 找到所有的实现代码。用户既可以审查 Occlum 的源代码，以确保整体方案的安全性；也可以参考已有的 demo 来学习 Occlum 的使用方法，快速上手安全计算。\n本周推荐阅读 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 金融级能力成核心竞争力，服务网格驱动企业创新\n 更多文章请扫码关注“金融级分布式架构”公众号\n ","date":1622530800,"description":"用安全计算保护关键业务","dir":"blog/Protecting Critical Operations with Secure Computing/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"800c9227ecb01253319dc8df2eb14d68","permalink":"https://sofastack.github.io/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","publishdate":"2021-06-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","summary":"什么是安全计算？ Linux 基金会旗下的安全计算联盟对安全计算下了一个定义： Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential Computing Consortium 在这个定义中强调了这么几点： 1.安全计","tags":["SOFAStack"],"title":"用安全计算保护关键业务","type":"blog","url":"/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/","wordcount":1810},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@非余 提问：\n 对于 Kata 我有些地方还是不太理解，我现在说说我的理解，麻烦你看对不 对，我的理解是 Kata 有两个缓存： 1. virtiofs 需要一个缓存。virtiofsd 和 guest 交互需要缓存做文件系统 buffer ，这个缓存的对应 qemu 的参数就是 memory-backend-file 。（这个缓存和 vhost-user 使用的 vring 是不是同一个？每一个 vm 有自己的缓存空间 ） 在 Kata 配置文件对应的是 default_memory。缓存策略是 virtio_fs_cache。 2. dax 缓存，对应的参数是 virtio_fs_cache_size，没有缓存策略控制。\n A：1、是的；2、dax的缓存控制是依靠guest的文件系统语义实现的。\nSOFAStack：https://github.com/sofastack\n2、@张鹏科 提问：\n SofaReferenceBinding 这个注解有一个属性：serializeType，默认序列化协议使用的是 Hessian2，我想替换成 protobuf，我看文档说这个目前不支持在注解中替换，只能以 xml 的方式。有点蒙，到底支持不支持？\n A：支持。\nSOFAStack：https://github.com/sofastack\n3、@jueming 提问：\n 请问一下 sofa-rpc和 Dubbo 区别在哪呢，是不是可以无缝接入 mosn sidecar？\n A: 核心差别目前主要是在协议上吧，协议的可扩展性双方都有，SOFARPC 的 Bolt 协议是基于最早 HSF 协议的一些痛点做了改良设计，整个协议的请求头是能包含更多信息，比如在 MOSN 里支持 Bolt 协议，整个请求在 MOSN 内只解析 header 就可以拿到足够信息做路由，header 的解析也是类似简单 kv 的方式，Dubbo 使用的协议在 Mosn 或者 Envoy 里需要做 Hessian 反序列化才能拿到足够的信息，性能损耗会稍微大一点，其他方面的扩展性上机制略有不同，但是都有比较强的扩展能力。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n4、@汪辉 提问\n Caused by:io.seata.core.exception.TmTransactionException: TransactionException[begin global request failed. xid=null, msg=Communications link failure. 请问这个 突然没有 xid 是什么情况？\n A：因为是 begin 时的异常，所以没有 xid，begin 成功了才有 Communications link failure。\nSeata：https://github.com/seata/seata\n5、@贾云森 提问\n 常见的就是并没有对 Select 语句进行 forupdate,如果你不开启 forupdate,Seata 默认是遇到并发性竞争锁并不会去尝试重试,导致拿不到 lock 当前事务进行回滚.不影响一致性,如果你想没 forupdate 也开启竞争锁client.rm.lock.retryPolicyBranchRollbackOnConflict 设置为 false（有死锁风险）。 请问是参数开启会出现死锁风险，还是自己手动添加 forupdate ，也会出现死锁风险呢？\n A：不加for update，也会竞争锁。但是因为可能存在二阶段需要回滚的事务，所以retryPolicyBranchRollbackOnConflict 为 true 的时候，优先会给需要回滚的事务进行回滚，所以需要放弃锁，这是 at 模式的一个缺陷。因为 at 就是 2 个锁，1 先获取数据库本地锁，2 获取全局，此事后如果获取全局锁后会释放本地锁，造成了死锁。所以 at 上出现 get global lock fail 是正常的，自己应该在业务上做好重试，当一个全局事务因为获取锁失败的时候，应该重新完整的发起，所谓的完整应该是从 globaltransational 的 tm 端重新发起。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海\n 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周 sofa-rpc 发布 v5.7.8 版本代码。主要更新如下：\n 支持 Dubbo service version 设置 修复 tracer 采样标志位无法正确透传的问题 修复重试逻辑中丢失最初异常的问题 详细参考： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.8\n","date":1622185200,"description":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20200528/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c1c3882d7e68e5fce4c25a088adaa109","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200528/","publishdate":"2021-05-28T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200528/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200528/","wordcount":1758},{"author":"章耿","categories":"SOFAStack","content":" Mesh 模式的引入是实现应用云原生的关键路径，蚂蚁集团已在内部实现大规模落地。随着 Message、DB、Cache Mesh 等更多的中间件能力的下沉，从 Mesh 演进而来的应用运行时将是中间件技术的未来形态。应用运行时旨在帮助开发人员快速的构建云原生应用，帮助应用和基础设施进一步解耦，而应用运行时最核心是 API 标准，期望社区一起共建。\n 蚂蚁集团 Mesh 化介绍 蚂蚁是一家技术和创新驱动的公司，从最早淘宝里的一个支付应用，到现在服务 全球十二亿用户的大型公司，蚂蚁的技术架构演进大概会分为如下几个阶段：\n2006 之前，最早的支付宝就是一个集中式的单体应用，不同的业务做了模块化的开发。\n2007 年的时候，随着更多场景支付的推广，开始做了一下应用、数据的拆分，做了 SOA 化的一些改造。\n2010 年之后，推出了快捷支付，移动支付，支撑双十一，还有余额宝等现象级产品，用户数到了亿这个级别，蚂蚁的应用数也数量级的增长，蚂蚁自研了很多全套的微服务中间件去支撑蚂蚁的业务；\n2014 年，像借呗花呗、线下支付、更多场景更多业务形态的出现，对蚂蚁的可用性和稳定性提出更高的要求，蚂蚁对微服务中间件进行了 LDC 单元化的支持，支撑业务的异地多活，以及为了支撑双十一超大流量的混合云上的弹性扩缩容。\n2018 年，蚂蚁的业务不仅仅是数字金融，还有数字生活、国际化等一些新战略的出现，促使我们要有更加高效的技术架构能让业务跑得更快更稳，所以蚂蚁结合业界比较流行的云原生的理念，在内部进行了 Service Mesh、Serverless、可信原生方向的一些落地。\n 可以看到蚂蚁的技术架构也是跟随公司的业务创新不断演进的，前面的从集中式到 SOA 再到微服务的过程，相信搞过微服务的同学都深有体会，而从微服务到云原生的实践是蚂蚁近几年自己探索出来的。\n为什么要引入 Service Mesh 蚂蚁既然有一套完整的微服务治理中间件，那为什么还需要引入 Service Mesh 呢？\n 拿蚂蚁自研的服务框架 SOFARPC 为例，它是一个功能强大的 SDK，包含了服务发现、路由、熔断限流等一系列能力。在一个基本的 SOFA(Java) 应用里，业务代码集成了 SOFARPC 的 SDK，两者在一个进程里运行。在蚂蚁的大规模落地微服务之后，我们就面临了如下的一些问题：\n升级成本高：SDK 是需要业务代码引入的，每次的升级都需要应用修改代码进行发布。由于应用规模较大，在一些大的技术变更或者安全问题修复的时候。每次需要数千个应用一起升级，费时费力。 版本碎片化：由于升级成本高，SDK 版本碎片化严重，这就导致我们写代码的时候需要兼容历史逻辑，整体技术演进困难。 跨语言无法治理：蚂蚁的中后台在线应用大多使用 Java 作为技术栈，但是在前台、AI、大数据等领域有很多的跨语言应用，例如 C++/Python/Golang 等等，由于没有对应语言的 SDK，他们的服务治理能力其实是缺失的。\n我们注意到云原生里有 Service Mesh 一些理念开始出现，所以开始往这个方向探索。在 Service Mesh 的理念里，有两个概念，一个是 Control Plane 控制平面，一个是 Data Plane 数据平面。控制面这里暂时不展开，其中数据平面的核心思想就是解耦，将一些业务无需关系的复杂逻辑（如 RPC 调用里的服务发现、服务路由、熔断限流、安全）抽象到一个独立进程里去。只要保持业务和独立进程的通信协议不变，这些能力的演进可以跟随这个独立的进程自主升级，整个 Mesh 就可以做到统一演进。而我们的跨语言应用，只要流量是经过我们的 Data Plane 的，都可以享受到刚才提到的各种服务治理相关的能力，应用对底层的基础设施能力是透明的，真正的云原生的。\n蚂蚁 Mesh 落地过程 所以从 2017 年底开始，蚂蚁就开始探索 Service Mesh 的技术方向，并提出了 基础设施统一，业务无感升级 的愿景。主要的里程碑就是：\n2017 年底开始技术预研 Service Mesh 技术，并确定为未来发展方向；\n2018 年初开始用 Golang 自研 Sidecar MOSN 并开源，主要支持 RPC 在双十一小范围试点；\n2019 年 618，新增 Message Mesh 和 DB Mesh 的形态，覆盖若干核心链路，支撑 618 大促；\n2019 年双十一，覆盖了所有大促核心链路几百个应用，支撑当时的双十一大促；\n2020 年双十一，全站超过 80% 的在线应用接入了 Mesh 化，整套 Mesh 体系也具备了 2 个月从能力开发到全站升级完成的能力。\n蚂蚁 Mesh 落地架构 目前 Mesh 化在蚂蚁落地规模是应用约数千个，容器数十万的级别，这个规模的落地，在业界是数一数二的，根本就没有前人的路可以学习，所以蚂蚁在落地过程中，也建设一套完整的研发运维体系去支撑蚂蚁的 Mesh 化。\n 蚂蚁 Mesh 架构大概如图所示，底下是我们的控制平面，里面部署了服务治理中心、PaaS、监控中心等平台的服务端，都是现有的一些产品。还有就是我们的运维体系，包括研发平台和 PaaS 平台。那中间是我们的主角数据平面 MOSN，里面管理了 RPC、消息、MVC、任务四种流量，还有健康检查、监控、配置、安全、技术风险都下沉的基础能力，同时 MOSN 也屏蔽了业务和基础平台的一些交互。DBMesh 在蚂蚁是一个独立的产品，图里就没画出来。然后最上层是我们的一些应用，目前支持 Java、Nodejs 等多种语言的接入。 对应用来说，Mesh 虽然能做到基础设施解耦，但是接入还是需要一次额外的升级成本，所以为了推进应用的接入，蚂蚁做了整个研发运维流程的打通，包括在现有框架上做最简化的接入，通过分批推进把控风险和进度，让新应用默认接入 Mesh 化等一些事情。\n同时随着下沉能力的越来越多，各个能力之前也面临了研发协作的一些问题，甚至互相影响性能和稳定性的问题，所以对于 Mesh 自身的研发效能，我们也做了一下模块化隔离、新能力动态插拔、自动回归等改进，目前一个下沉能力从开发到全站推广完成可以在 2 个月内完成。\n云原生应用运行时上的探索 大规模落地后的新问题与思考\n蚂蚁 Mesh 大规模落地之后，目前我们遇到了一些新的问题： 跨语言 SDK 的维护成本高：拿 RPC 举例，大部分逻辑已经下沉到了 MOSN 里，但是还有一部分通信编解码协议的逻辑是在 Java 的一个轻量级 SDK 里的，这个 SDK 还是有一定的维护成本的，有多少个语言就有多少个轻量级 SDK，一个团队不可能有精通所有语言的研发，所以这个轻量级 SDK 的代码质量就是一个问题。\n业务兼容不同环境的新场景：蚂蚁的一部分应用是既部署在蚂蚁内部，也对外输出到金融机构的。当它们部署到蚂蚁时，对接的是蚂蚁的控制面，当对接到银行的时候，对接的是银行已有的控制面。目前大多数应用的做法是自己在代码里封装一层，遇到不支持的组件就临时支持对接一下。\n从 Service Mesh 到 Multi-Mesh：蚂蚁最早的场景是 Service Mesh，MOSN 通过网络连接代理的方式进行了 …","date":1621926000,"description":"蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海 ","dir":"blog/Exploration and Practice of AntCloud Native Application Runtime - ArchSummit Shanghai/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"da69750163f92aa73f15821202ee07e6","permalink":"https://sofastack.github.io/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","publishdate":"2021-05-25T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","summary":"Mesh 模式的引入是实现应用云原生的关键路径，蚂蚁集团已在内部实现大规模落地。随着 Message、DB、Cache Mesh 等更多的中间件能力的下沉，从 Mesh","tags":["SOFAStack"],"title":"蚂蚁云原生应用运行时的探索和实践 - ArchSummit 上海 ","type":"blog","url":"/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/","wordcount":4840},{"author":"SOFAStack社区","categories":"Summer 2021","content":"警告警告⚠️暑期即将到来，\n在暑期到来之前你有没有考虑过这样一个问题？\n那就是这个夏天怎么过？\n我相信你读完问题后脑海里浮现出了 N 多个想法，我相信那都是对你有意义的，但是你有没有考虑过让这个夏天过的更有“意义”一些。\n让你在这个夏天不仅可以让还是学生的你参与到知名开源项目，体验开源文化，与开源社区导师一同交流探讨的同时又可以收获一笔不菲的奖金，最重要的是可以获得一份特别亮眼的项目经历！！！\n动没动心？？？❤️\n 2021年的夏天被称为“开源之夏”\n那么什么是“开源之夏”？\n“开源之夏”全名开源软件供应链计划-暑期2021，是由中国科学院软件研究所与 openEuler 社区共同举办的一项面向高校学生的暑期活动，是一项专门面向高校学生的开源项目开发活动，旨在鼓励在校学生积极参与开源软件的开发维护。主办方联合各大开源社区，针对对重要开源软件的开发与维护提供项目任务，学生根据兴趣申请项目，中选后将在社区导师指导下进行开发，并将成果贡献给社区。根据项目的难易程度和完成情况，学生将获得 6000、9000、12000元不等的项目奖金。完成SOFAStack社区项目的优秀贡献者可以获得蚂蚁内推机会（蚂蚁中间件团队很多优秀的工程师都是被挖过来的开源社区贡献者🤫）\n活动官网：https://summer.iscas.ac.cn/\n暑期 2021 项目任务活动自发布以来，众多开源社区踊跃报名，5 月 20 日社区报名截止，共有 109 家海内外社区报名，并上线了 877 个开源项目任务。其中 SOFAStack 社区上线了 9 个项目任务，包含云计算、云原生、分布式系统、微服务中间件、前端等多个方向结合的项目任务，涉及的开源项目包括：JRaft、SOFA-RPC、SOFA-Registry、SOFADashboard、SOFATracer，有中、高等级不同难度的任务以供选择。\nSOFAStack 社区项目任务列表：https://summer.iscas.ac.cn/#/org/orgdetail/s\nsofastack 学生指南：https://summer.iscas.ac.cn/help/student/\n学生如何申请？\n学生申请通道 5 月 24 号正式开放啦！\n申请时间：5 月 24 日\u0026amp;ndash; 6 月 13 日\nSTEP 1 ：查看项目任务列表，你感兴趣的任务。可同步在官网报名系统注册账号进行报名。\n报名系统：\nhttps://portal.summer-ospp.ac.cn/summer/login\n STEP 2：就感兴趣的任务与对应的导师取得联系，沟通清楚项目需求，也可就项目方案和导师讨论。\nSTEP 3：撰写项目申请书，并在报名系统提交项目申请书和个人简历。\nSTEP 4：6 月 30 号公布中选结果，中选学生在导师指导下，按计划在 7-9 月进行开发。\nSTEP 5：完成开发，获得项目奖金和证书。\n详情可进一步阅读暑期 2021 学生指南：https://summer.iscas.ac.cn/help/student/\n暑期 2021 面向人群 本活动面向年满 18 周岁在校学生，不限国籍暑期即将毕业的学生，只要在申请时学生证处在有效期内，就可以提交申请海外学生可提供录取通知书/学生卡/在读证明证明学生身份\n ","date":1621839600,"description":"“开源之夏” SOFAStack 社区 9 个项目任务上线，学生申请正式开始！","dir":"activities/Summer 2021 of Open Source Promotion Plan/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9917f037c993814f23d2049396c438eb","permalink":"https://sofastack.github.io/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","publishdate":"2021-05-24T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","summary":"警告警告⚠️暑期即将到来， 在暑期到来之前你有没有考虑过这样一个问题？ 那就是这个夏天怎么过？ 我相信你读完问题后脑海里浮现出了 N 多个想法，我相信","tags":["Summer 2021"],"title":"“开源之夏” SOFAStack 社区 9 个项目任务上线，学生申请正式开始！","type":"activities","url":"/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/","wordcount":1198},{"author":"朵晓东","categories":"SOFAStack","content":" 本文是云原生开放协同技术探索与实践一阶段的总结和综述。\n蚂蚁基础技术在过去3年多以来持续、深入推进全面的云原生化技术演进，我们将在线、离线计算资源装进了一台计算机，将服务体系通过 mesh 的思路和技术手段进行了下沉解耦，可以说比较充分的拥抱了云原生技术，并获取了其带来的技术红利。\n当完成了资源、服务的云原生化，我们发现在云原生基础能力之上的运维体系与云原生技术开放、共享的思路有较大的距离，在技术体系上也与云原生技术声明式、白盒化的思路相悖，同时由于缺少匹配的技术支撑，历史包袱等问题也成为了云原生运维难以真正代际演进的障碍。今天我要介绍的就是蚂蚁在这样的背景下在云原生运维方向进行的技术探索和实践。\n规模化云原生运维探索 我们先来回顾一下在蚂蚁真实的实践方式和面对的问题。首先，我们来看看蚂蚁践行多年的经典运维中台，这类运维平台一般包括了控制器、业务模型、编排引擎、原子任务及管道，在蚂蚁这样的平台是一系列服务的集合，他们较好的满足了集中式、标准化、低变更频率的应用发布及运维需求。但这种模式在实践中也存在着明显的不足。\n首先对于非标准应用、应用个性化需求、高成本需求、非紧急需求、技改类需求，往往无法较好的满足。在蚂蚁的实践中，非标运维需求、对核心应用模型及运维模型冲击较大的高成本改造需求、大量基础能力或运维功能的透出需求等长期无法得到较好的满足，需求往往是合理的，是难以获得足够的优先级执行落地。在研发阶段，运维平台长期积累了高复杂度的业务逻辑，修改测试涉及跨系统的长改造链路，同时基础能力的透出、运维能力的产品化依赖前端、服务端研发资源。这些问题使得运维平台研发日渐吃力，特别是在产品 GUI、业务模型、编排引擎等变更热点上，受限于扩展机制能力不足，内部实践中甚至出现过线上不断修改代码、发布服务以满足需求的情况。平台上线后，统一的质保和线上全链路功能验证同样面对较大的压力。对于最终的使用者，命令式按钮背后的黑盒计算透明度低，审计难，结果难预测，同时激情操作、操作界面不熟悉等问题也一直影响着线上的稳定性。这些问题长期存在，我们寄希望于代际的技术演进来解决这些问题。 \u0026amp;gt;当云原生基础服务逐渐稳定后，对于自身场景不在运维平台管理范围内的应用，研发同学自发的借助云原生社区工具链解决问题。基于 Kubernetes 生态高度开放、高度可配置的特点，研发者可以自助、灵活、透明的声明式应用运行、运维需求，以应用粒度完成发布、运维操作。\n用户通过 kustomize 等社区技术缩短了对接基础设施的路径，并通过如 velocity 等文本模板技术部分解决了静态 YAML 文件在较多变量时维度爆炸的问题，解决了默认值设定的问题，同时通过 code review 的方式进行多因子变更及评审。由于 Kubernetes 及其生态提供了面向资源、服务、运维、安全的横向能力，使得这种简单的方式可有很好的普遍性和适用性，通过对不同的 Kubernetes 集群 “播放” 这些数据即可完成对基础设施的变更，本质上是一种声明数据的流转。面向 git 仓库的研发方式和 gitops 流程支持对运维产品研发资源的诉求较低，往往可以比较简单的搭建起来，不强依赖产品研发资源投入。相比经典运维中台，这些好处清晰明确，但从工程视角缺点也非常明显。 \u0026amp;gt;首先 Kubernetes API 的设计较为复杂，仅是 Kubernetes 原生提供的 low level API 就暴露了 500 多种模型，2000 多字段，场景上几乎涵盖了基础设施应用层的方方面面，即使是专业同学也很难理解所有细节。其次这种方式的工程化程度很低，违反 DRY 原则，违反各团队职责能力高内聚低耦合的原则，即使在有一定的工具支持的情况下，在内部的典型案例中一个多应用的 infra 项目仍然维护了多达 5 万多行 YAML，同时由于团队边界造成的多个割裂的平台，用户需在多个平台间切换，每个平台的操作方式各异，加上跳板机黑屏命令，完成一次完整的发布需要 2 天时间。\n由于低工程化程度的问题，各团队间协同依赖人肉拉群同步，最终 YAML 由多个团队定义的部分组合而成，其中一大部分属于 Kubernetes 及运维平台团队的定义，这些内容需要持续跟踪同步避免腐化，长期维护成本高。\nKUSION: 云原生开放协同技术栈 以上两种模式各有利弊，优势和问题都比较清晰。那么能不能既要也要呢，能不能在继承经典运维平台优势的情况下，充分利用云原生技术带来的红利，打造一个开放、透明、可协同的运维体系？\n带着这样的问题，我们进行了探索和实践，并创建了基于基础设施代码化思路的云原生可编程技术栈 Kusion。\n大家都知道 Kubernetes 提供了声明式的 low level API，提倡其上生态能力通过 CRD 扩展的方式定义并提供服务，整个生态遵循统一的 API 规范约束，复用 API 技术和工具。Kubernetes API 规范提倡 low level API 对象松耦合、可复用，以支持 high level API 由 low level API “组合” 而成。Kubernetes 自身提供了利于开源传播的极简方案，并不包括 API 之上的技术和方案。\n回到云原生技术的本源，我们回看了 Kubernetes 前身 Borg 的应用技术生态。如下图示，在 BorgMaster 之上，Borg 团队研发了 Borg 接入三件套，即 BCL（Borg Configuration Language），Command-line tools，以及相应的 web service。用户可以通过 BCL 声明式编写需求，通过 Command-line tools 将 BCL 文件执行到 Borg 集群，并通过 web GUI 视图查看任务细节。经过大量的调研，我们了解到 Google 内部的运维能力及产品生态、质量技术生态都依赖这三件套构建而成，在内部也进行了多年的迭代演进。 \u0026amp;gt;这给了我们启发，今天我们有了容器技术、服务体系，有了大量用户和差异化的需求，有了一定数量的自动化运维平台，我们希望能通过云原生专用的语言和工具来链接 Kubernetes 生态、各个运维平台以及大量的用户，通过唯一事实定义消除运维平台孤岛，完成云原生基础设施在应用、运维层面的代际演进，达到 “Fusion on Kubernetes” 的目标。\n带着这样的目标，我们持续地进行做技术探索和实践，目前已经形成了 Kusion 技术栈，并在蚂蚁的生产实践中进行应用。 \u0026amp;gt;Kusion 技术栈基于这样的基础能力而工作，包括如下组成部分：\n云原生配置策略专用语言 KCL (Kusion Configuration Language)\nKCL 解释器及其 Plugin 扩展机制\nKCL 研发工具集: Lint, Format, Doc-Gen，IDE Plugin(IDEA, VsCode)\nKusion Kubernetes 生态工具: OpenAPI-tool, KusionCtl(Srv)\nKonfig 配置代码库，其中包括平台侧及用户侧代码\nOCMP (Open CloudNative Management …","date":1621321200,"description":"带你走进云原生技术：云原生开放运维体系探索和实践","dir":"blog/Take you into cloud-native technology: cloud-native open operation and maintenance system exploration and practice/","fuzzywordcount":10400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"365cd296d63b8ea2fa2e70b06830c734","permalink":"https://sofastack.github.io/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","publishdate":"2021-05-18T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","summary":"本文是云原生开放协同技术探索与实践一阶段的总结和综述。 蚂蚁基础技术在过去3年多以来持续、深入推进全面的云原生化技术演进，我们将在线、离线计算","tags":["SOFAStack"],"title":"带你走进云原生技术：云原生开放运维体系探索和实践","type":"blog","url":"/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/","wordcount":10395},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@姚远 提问：\n 请问下 SOFAArk，master-biz 是个 Spring Boot 应用，A-biz 是个普通的Spring，一起打成一个 Executable-Ark 包。那么 Spring 相关的 Jar 是不是就要加载 2 次。 A：如果没有下沉插件的话，是会加载两次。\n SOFAArk：https://github.com/sofastack/sofa-ark\n@colin 提问：\n 内部服务之间的路由策略，是推荐用 service-mesh 来做吗？还是内部服务之间也用服务网关？ A：内部东西向流量推荐走 mesh ，一般来说网关更适合做南北向网络边界上的出入口。\n MOSN：https://github.com/mosn/mosn/\n@colin 提问：\n 这种场景，推荐用网关还是 service-mesh？目前我们是自己的内部网关来做的，网络不隔离，只是 jvm 进程隔离。 A：如果逻辑上也不隔离，互相能够服务发现，互相信任不需要额外鉴权的话，可以认为是内部流量，走 mesh 比走集中式的网关更合适。如果逻辑隔离，那么走网关比较合理。\n MOSN：https://github.com/mosn/mosn/\n@骆伟康 提问：\n 请问一下 这里我使用 dynamic 多数据源 结合 Seata 但是为啥只回滚了主库的数据 另外的库回滚失败？ A：看官网 FAQ，关闭 Seata 的自动代理，mp 的 dynamic 组件你开启他的 Seata 开关他自己会代理的。\n Seata：https://github.com/seata/seata\n@贾云森 提问：\n Could not commit JDBC transaction; nested exception is io.seata.rm.datasource.exec.LockConflictException: get global lock fail, xid:192.168.3.239:8092:138223831620784128, lockKeys:outpat_medical:135231296034705408,135231296034705409,135231296034705410,135231296034705411,135231296034705412,135231296034705413)\u0026amp;ldquo;,\u0026amp;ldquo;code\u0026amp;rdquo;:85550,\u0026amp;ldquo;data\u0026amp;rdquo;:null,\u0026amp;ldquo;time\u0026amp;rdquo;:\u0026amp;ldquo;2021-05-19 10:12:10\u0026amp;rdquo; 想问一下为什么会发生这种异常啊？ A：正常输出，竞争锁没竞争到。\n Seata：https://github.com/seata/seata\n@winyQ 提问：\n 项目里 Seata 用 AT 模式，可以在项目里再集成 JTA 吗，两个并存有没有什么问题？ A：JTA 是 XA ，无法跟 AT 兼容。\n Seata：https://github.com/seata/seata\n本周推荐阅读 带你走进云原生技术：云原生开放运维体系探索和实践\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n 金融级能力成核心竞争力，服务网格驱动企业创新\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n 本周发布 本周发布详情如下：\n本周 SOFAJRaft 发布 1.3.7 版本，主要更新如下：\n 1.修复 TCP 建连被 block 导致选主超时 2.升级 commons.io 到 2.8.0 以修复安全漏洞\n详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.7\n ","date":1621234800,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210521/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d7be1cbefe37ff9c846ea84f7ad52755","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210521/","publishdate":"2021-05-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210521/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210521/","wordcount":1146},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼\n欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张思雨提问：\n 我配置中心里加了 transport.threadFactory.clientSelectorThreadSize\u0026amp;hellip;设置了个 100，这个值是不是一般设置成 cpu 核数*2 就够了啊？ 我之前遇到了 tc 调客户端的 commit 超时。我就把这种值都调大了试试效果 ， transport.threadFactory.clientSelectorThreadSize 100 transport.threadFactory.workerThreadSize 3000\n A：线程数这个东西这不该开放出去，很危险，对 netty 了解一点应该也知道 NioEventLoopGroup 的最多应该就核心数的两倍。 Seata：https://github.com/seata/seata\n2、@林南行提问：\n 大家好，请教一个问题：我现在用的 seata-server 的 1.3.0 的版本，客户端用的是 1.4.1 版本。当同时启动 10+个微服务连接 seata-server 的时候，只有 10 个能注册成功，剩余的必须重启后才能重新注册成功，这个是什么问题呢？\n A：试一下把 logSerialization 改成 kyro。 Seata：https://github.com/seata/seata\n3、@林南行提问：\n seata-server-1.3.0 和 seata-server-1.4.2 在配置上有什么区别吗？ 两边的 registry.conf 配置是一样的，但是 1.3.0 能正常启动，1.4.2 就报错，global_table 找不到。\n A：没区别，说明配置有问题，看看 global_table 写了没，写了的话，写的是什么，配置中心是什么，检查清除。 Seata：https://github.com/seata/seata\n4、@潘顾昌提问：\n 请问什么情况这个状态会是 Finished？现在导致这部分数据没有提交，但是也没有报错，正常的数据提交后看到的都是这个。 现在有些情况会返回 Finished，导致没有正常提交。\n A：事务结束了不就是 Finished，自己服务降级了吧，导致没回滚，部分插入部分没插入了。 Seata：https://github.com/seata/seata\n5、@潘顾昌提问：\n Finished 已经插入的数据会回滚丢失吗？我们后台实时监控到，一开始是插入到数据库的，确实是有的，但是结束以后数据就丢失了\n A：seata 没有执行二阶段回滚，不会消失数据，数据丢失要么是本地事务发生异常，你们捕获异常了，用 spring API 来回滚了本地事务，导致异常没抛出去，事务回滚了，要么发生异常，被你们的全局异常捕获器捕获了，导致决议了提交，实际上数据已经被本地事务回滚，seata 在二阶段不是 rollback 相关状态的时候不会干预业务数据。 Seata：https://github.com/seata/seata\n本周推荐阅读\n 稳定性大幅度提升：SOFARegistry v6 新特性介绍\n Rust 大展拳脚的新兴领域：机密计算\n 开源项目是如何让这个世界更安全的？\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 本周发布 本周发布详情如下：\n本周 sofa-registry 发布 V6-alpha 代码，本版本不建议生产使用，正式版本会在近期 release。主要更新如下：\n 支持应用级服务发现 基于 slot 分配的数据分片存储 详细参考：https://github.com/sofastack/sofa-registry/tree/v6-alpha1 文章解读：https://mp.weixin.qq.com/s/-5oK-EuZWpvIATvTzSMRAw\n","date":1620975600,"description":"SOFA WEEKLY | SOFARegistry 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210514/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7c193377953cba7840c05a3ff7d6d4ec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210514/","publishdate":"2021-05-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210514/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARegistry 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210514/","wordcount":1488},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@Chrosing 提问：\n Seata 被锁的 xid 数据 一直卡住的时候， 为啥丢失了一部分 undo_log 语句？导致直接删除 lock_table 的 xid 时候，没有回滚数据回去，当前版本 1.3.0。\n A：不会丢 undolog，只可能回滚了部分，部分因为脏写了导致没法回滚，这部分的 undolog 留着；所以看起来 undolog 少了，其实是分支回滚调了，留着的都是没有回滚的。\nSeata：https://github.com/seata/seata\n2、@洪波森 提问：\n 这算一个 bug 吗，永远跑不进来？\n A：不是，读不到你事务分组对应的值，就是 null。\nSeata：https://github.com/seata/seata\n3、@陈承邦 提问：\n sharding-transaction-base-seata-at 这个包只对 Seata 做了代理，我看了一早上源码，直接用 Seata 包 好像也不影响 分布式事务\n A：Seata 无法找到具体那个 datasource，Seata 只能代理 sharding-jdbc 最外层的 datasource，这个 datasource 里面有 N 个 datasource 来实现分库分表的功能，这个才是真正对数据库的 Seata：https://github.com/seata/seata\n4、@杨政伟 提问：\n 请教一个问题，如果 A 方法调用 B 方法，B 方法启用了事务，并发生异常时，但 B 方法并没有回滚，怎么能实现 B 方法的回滚？\n A：在同一个类里面被其他方法调用，是不能开启事务的，看一下 aop 的机制。a 是个实例 cglib 代理了 a 成为了一个包装了它的实例，此时你直接调了内部的实例，怎么走到它的切面去呢？\nSeata：https://github.com/seata/seata\n本周推荐阅读 下一代机密计算即将到来：性能比肩普通应用\n 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n Rust 大展拳脚的新兴领域：机密计算\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n ","date":1620370800,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-20210507/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4606adcc9195341f35c6dd05b0e93da1","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210507/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210507/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210507/","wordcount":957},{"author":"英花","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#20：用安全计算保护关键业务\n 活动时间：05 月 19 日周三晚 19 点\n 活动形式：线上直播\n 资料下载：戳这里\n B 站直播间地址：http://live.bilibili.com/21954520\n B 站直播ID：21954520\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#20：用安全计算保护关键业务 随着全社会对隐私保护越来越关注安全计算也成了近期的热点。蚂蚁做为一家金融科技公司，特别注重用科技的方法来保护用户隐私。这次直播会介绍蚂蚁在安全计算方面的一些方法和实践。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：34197075（搜索群号加入即可）\n嘉宾 相和 蚂蚁集团安全计算团队 Occlum 项目负责人 （从事 Intel SGX 相关开发工作十多年，期间设计和主持开发了 Intel SGX SDK） 议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 用安全计算保护关键业务 相和 蚂蚁集团安全计算团队 Occlum 项目负责人\n你将收获 了解Intel SGX 技术和蚂蚁开源的 Occlum 产品。 了解如何用 Occlum 来保护已有的 SOFABoot 应用。 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1620370800,"description":"05 月 19 日周三晚 19 点，线上直播第 20 期。","dir":"activities/sofa-channel-20/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f41faefa3f35c17635d73634cf7a50f5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-20/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-20/","summary":"概要 活动主题：SOFAChannel#20：用安全计算保护关键业务 活动时间：05 月 19 日周三晚 19 点 活动形式：线上直播 资料下载：戳这里 B 站直播间","tags":["SOFAChannel","Occlum"],"title":"SOFAChannel#20：用安全计算保护关键业务","type":"activities","url":"/sofastack.tech/activities/sofa-channel-20/","wordcount":551},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAStack Meetup#5 上海站 容器沙箱专场\n 活动时间：2021 年 05 月 22 日（周六）14:00-17:00\n 活动地点：上海市浦东新区蚂蚁 S 空间 南泉北路 447 号 201\n 活动形式：线下活动\n 资料下载： 《边缘计算中的 Kata Containers\u0026amp;gt; 《快速闪电：Nydus 镜像加速服务》 《WebAssembly Micro Runtime：云原生时代的超轻量级新型沙箱》 《WebAssembly 在 MOSN 中的探索与实践》\n 活动介绍 活动议程 本期议题以及嘉宾详解 《边缘计算中的 Kata Containers》\n嘉宾介绍\n李枫，先后就职于摩托罗拉, 三星等IT公司, 现为独立开发者。在移动平台上积累了十年以上的研发经验, 近几年主要专注于云计算/边缘计算基础设施领域。是《灰帽黑客 第4版：正义黑客的道德规范、渗透测试、攻击方法和漏洞分析技术》和《恶意网络环境下的Linux防御之道 》中文版的主要译者。对技术创新具有浓厚的兴趣和实践能力，热心参与开源社区的各种活动，多次参加各种IT会议并作技术分享。\n议题简介\n Kata Containers 具有的轻量和高安全等特性使它在资源受限和安全性需求的物联网/边缘计算领域有很好的应用前景, 并且可以与其他轻量级解决方案（如 K3S 等）进一步结合使用。本话题包含下列子话题： 1) LF Edge（由 Akraino 和 EdgeX 合并而成）中的 Kata Containers； 2) 打造轻量级 K8S 集群\u0026amp;ndash;Kata-Containers 与 K3S 的结合； 3) 在 ACRN 中运行 Kata Containers； 4) 将 Kata Containers 应用于边缘云。 听众收获\n 了解 Kata Containers 的基本情况 了解 Kata Containers 在边缘计算场景的应用前景 《快速闪电：Nydus 镜像加速服务》\n嘉宾介绍\n彭涛，蚂蚁集团可信原生技术部高级技术专家，Linux 内核和文件系统开发者，近年来主要关注容器运行时相关技术，是 Kata Containers 维护者和架构委员会成员，Dragonfly 镜像服务 nydus 的作者之一，云原生技术浪潮的坚定支持者。\n徐佶辉，蚂蚁集团可信原生技术部技术专家，Dragonfly 镜像服务 nydus 的作者之一，负责 nydus 在蚂蚁的落地。\n议题简介\n 有研究表明，容器镜像拉取占据了容器启动时间的 70%，而容器启动实际上只需要访问容器镜像不到 6% 的数据量。基于此，我们设计实现了可以按需加载容器镜像的 nydus 镜像加速服务，在内部大规模部署，并开源贡献给 Dragonfly 社区。本话题将向大家介绍 nydus 项目的背景，架构和技术细节，以及我们对容器镜像生态的展望。 听众收获\n 了解当前 OCI 容器镜像格式优缺点 了解 nydus 项目的背景，架构和技术细节 了解容器镜像生态的发展趋势 《WebAssembly Micro Runtime：云原生时代的超轻量级新型沙箱》\n嘉宾介绍\n王鑫，英特尔高级工程经理，WAMR(WebAssembly Micro Runtime)项目的创建者，主要工作集中在管理语言运行时和Web技术，2009年以来领导了Java和WebAssembly虚拟机运行时开发、V8 JavaScript引擎的性能优化等相关工作。加入英特尔之前，在摩托罗拉主要作为技术Leader，负责无线基站系统相关的工作。\n议题简介\n 近年来WebAssembly在服务器侧及云原生场景中越来越流行，WAMR(WebAssembly Micro Runtime)是字节码联盟(Bytecode Alliance)旗下的WebAssembly独立运行时开源项目，支持多种软硬件平台，支持解释器/AOT/JIT等多种执行方式，性能优异，资源占用少，对多线程和SIMD也有良好的支持。这次分享将介绍WAMR的架构、特性、社区合作及在云原生场景中的应用。 听众收获\n 了解WebAssembly这一新兴技术 了解WAMR开源项目的架构、特性及社区合作 了解WAMR在云原生场景中的应用实例 《WebAssembly 在 MOSN 中的探索与实践》\n嘉宾介绍\n叶永杰，蚂蚁集团可信原生技术部软件工程师，开源项目 MOSN 核心成员，目前关注云原生 ServiceMesh、WebAssembly 等相关领域。\n议题简介\n 随着云原生数据面 MOSN 在蚂蚁金服内部的大规模落地，安全隔离逐渐成为急需解决的问题之一。为此，我们利用 WebAssembly 基于给定资源的安全模型，依托于社区 Proxy-Wasm 开源规范，为 MOSN 中的扩展插件提供了一个独立隔离的沙箱环境。这次分享将介绍 MOSN 的背景，WebAssembly 在 MOSN 中的实践、以及我们在 Proxy-Wasm 开源规范上的贡献。 听众收获\n 了解云原生数据平面 MOSN 的基本情况 了解 Proxy-Wasm 开源规范的基本情况 了解 WebAssembly 技术在云原生数据平面的实践案例 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1620370800,"description":"SOFAStack Meetup#5 上海站 容器沙箱专场","dir":"activities/sofa-meetup-6/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"411a4b0f323c4d5ced46847b710a948d","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-6/","publishdate":"2021-05-07T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-6/","summary":"概要 活动主题：SOFAStack Meetup#5 上海站 容器沙箱专场 活动时间：2021 年 05 月 22 日（周六）14:00-17:00 活动地点：上海市浦东新区蚂蚁 S","tags":["SOFAMeetup"],"title":"SOFAStack Meetup#5 上海站 容器沙箱专场","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-6/","wordcount":1805},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@李明 提问：\n 请教一下： SOFATracer 用 3.1.0 版本对应 SOFABoot，应该使用 3.1. 版本吗？\n A：都可以，不依赖 SOFABoot 版本。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@黄海淇 提问：\n 有没有 SOFABoot 从零开始的文档哇？这家公司用的 SOFA 相关的组件做的银行项目。\n A：https://www.sofastack.tech/projects/sofa-boot/overview/ ，在我们社区各个项目的主页介绍里面都是有文档的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@陈承邦 提问：\n undo_log 日志当时回滚删除，还是过一段时间批量删除？ A：回滚删除，status 为 1 的 7 天删除。\nSeata：https://github.com/seata/seata\n4、@贾云森 提问：\n @GlobalTransactional 这个注解下的，不同 Service 的数据库操作，都要加本地事务吗？\n A：AT 模式下不需要。\nSeata：https://github.com/seata/seata\n5、@天成 提问：\n 问下：生产跟预发感觉也得搭建 2 个 seata-server，不能共用一个对吧？\n A：可以共用一个，因为锁需要共享才能排他；也可以分开，但是要用表共享，具体看官网事务分组。\nSeata：https://github.com/seata/seata\n本周推荐阅读 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述\n 开发 Wasm 协议插件指南\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n ","date":1619766000,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-0430/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8225fa5618621f7b6ea3e7504b74610a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0430/","publishdate":"2021-04-30T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0430/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0430/","wordcount":903},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谭新宇 提问：\n 请教 SOFAJRaft 的问题：默认的 election timeout 这么小嘛？业务压力比较大的话感觉很可能发生超过 1s 的 STW GC 吧，这时会不会导致频繁换主。\n A：最好调整下默认参数，不过 1s 的 STW 实际上也不太正常，需要优化。\nSOFAJRaft：https://github.com/sofastack/sofa-jrafta\n2、@刚刚 提问：\n SOFARPC 是通过 MOSN 转发协议？SOFA RPC 对外注册的 IP 在 k8 的容器是什么策略？\n A：：MOSN 支持 SOFARPC 协议的转发。\nA：服务发布订阅没有做啥特殊的，就和原来是一样的。\nMOSN:https://github.com/mosn/mosn\n3、@王哲 提问：\n 问下 MOSN 对 Kubernetes 版本有限制么？\n A：MOSN 对 K8s 没有强制版本要求，不过 Istio 是对其有版本要求的，具体可以看文档：https://istio.io/latest/about/supported-releases/#support-status-of-istio-releases。\nMOSN:https://github.com/mosn/mosn\n4、@王哲 提问：\n 我试了下 mosn bookinfo出现了这个问题：那个 demo Istio 注入后 yaml 文件是 OK 的，但是运行时 describe pod 看 binaryPath 又变成了 envoy，下面是运行时的，不知道是不是因为这个问题？\n A：看起来是你修改的路径没有生效，可以先在 configmap 里面修改下这个 binarypath 。\nMOSN:https://github.com/mosn/mosn\n5、@朱闯 提问：\n 请教个问题：saga 模式下是无锁的，一阶段就提交了本地事务，那么也会出现脏写而导致没法正常回滚事务的情况吧。\n A：所以允许向前重试，最终一致。向前是最终一致，没有脏写。\nSeata：https://github.com/seata/seata\n6、@何凯博 提问：\n 请教下各位大佬，xa 模式下 Seata 是怎么实现事务隔离的？\n A：xa 就是本地事务隔离，把本地事务 prepare，到二阶段再提交或者回滚。\nSeata：https://github.com/seata/seata\n7、@谢太阳 提问：\n A 项目独立库，B 项目用 sharding jdbc 分库分表，A 项目发起分布式事务，出现异常，B 项目不回滚，请教这个一般是什么问题呢？上面是 A 调用 B 的日志，没有分支的回滚记录。下面 B 调用 A 是正常的。\n A：xid 传递检查一下，数据源代理没成功，或者 xid 没传递。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Rust 大展拳脚的新兴领域：机密计算\n 开发 Wasm 协议插件指南\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n 本周发布 本周发布详情如下：\n1、Occlum 发布了 0.22.0 版本，主要变更如下：\n 三个新的 demo：redis，Flink 和 Enclave RA_TLS 支持 /dev/shm 文件子系统 支持 golang1.16.3 详细参考：\nhttps://github.com/occlum/occlum/releases/tag/0.22.0\n","date":1619161200,"description":"SOFA WEEKLY |QA 整理","dir":"blog/sofa-weekly-20210423/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"30345ac491d8918983986d2f4cf1d058","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210423/","publishdate":"2021-04-23T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210423/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210423/","wordcount":1277},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@藜蒿 提问：\n 请问一下，SOFATracer+SpringBoot 如何在 spring-mvc-digest.log 增加 rest 请求的请求体数据在 json 日志中。需要打印 request 数据，不单单是 url 上的，可能是 post 请求放在 body 里面的。A：可以用这里的命名空间：\n A：这个暂时不行，不过你可以通过手动埋点的方式去拿这些信息，可以提个 issue ，详细描述下场景诉求。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@南桥 提问：\n 请问下 select * for update, 在 Seata 的事务中，除了会加一个全局的锁，还会加数据库锁吗？ 如果一条记录在分布式事务中，已经加了 for update 读。 那么这条记录再在数据库本地事务中，不加 @GlobalLock，加 for update 读，能读到吗？\n A：不会加全局锁，先加本地锁。\nA：如果要根据读的结果来写，为了得到分布式事务下的已提交数据，需要 for update。数据库层面可以快照读，但是无法当前读（for update 会阻塞），上了分布式事务后，结果都是二阶段后才是准确的，因为有了分布式事务的概念，在此之下的所有本地事务，也就是数据库方的数据已经不能算是准确的了，因为在 AT 模式下随时都有会回滚数据。\nSeata：https://github.com/seata/seata\n3、@姜广兴 提问：\n saga 模式 demo 中的服务都有对应的补偿服务，如果对接外部系统，没有提供相应的补偿服务，还可以使用 saga 模式吗？\n A：可以，没有补偿服务就不补偿，可以向前重试。\nSeata：https://github.com/seata/seata\n4、@彭勃 提问：\n 看到这段，我请教一下。目前，我们自己通过再加一个 mysql MGR 集群去回避这个外部持久化单点故障的问题请问有人有过相关实践吗？您觉得可行吗？\n A：可以这么做，MGR 的话性能应该就比单 DB 要下降了，但是比主备要靠谱，主备的话还是有可能丢数据，MGR 有一致性协议存在，理论上没什么大问题。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Rust 大展拳脚的新兴领域：机密计算\n Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n 本周发布 本周发布详情如下：\n1、SOFATracer **** 发布 v3.1.1 版本，主要变更如下：\n 添加数据脱敏扩展点，默认无对应的开源实现，用户可以自定义；商业版则提供了该实现 。\n详细参考：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.1.1 ","date":1618556400,"description":"SOFA WEEKLY |SOFATracer 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210416/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6e17e1cbdfbb154ddbe2066aa24dabfa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210416/","publishdate":"2021-04-16T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210416/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210416/","wordcount":1212},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA开源三周年，Let\u0026amp;rsquo;s have fun together\n 活动时间：2021 年 04 月 24 日（周六）14:00-17:00\n 活动地点：北京海淀中关村创业大街72号拓荒族众创空间（三层路演厅）\n 活动形式：线下活动\n 资料下载：\n 《SOFAStack 三周年分享》下载链接\n 《Enabling Financial-Grade Secure Infrastructure with Confidential Computing》下载链接\n 《云原生网络代理 MOSN 新的助推器—Envoy》下载链接\n 《注册中心 6.0 新特性》下载链接\n 《服务网格在企业落地的典型场景与实践》下载链接\n 活动介绍 SOFA 开源三周年， Let\u0026amp;rsquo;s have fun together！北京，我们来啦！\n不知不觉，我们已相识三年，\n很开心能邀请你一起来见证 SOFAStack 社区三周年，\n三年的时间，见证了 SOFAStack 在各个行业环境中的成长，是我们 SOFA 星球的骄傲。\n我们将在北京迎来 SOFA 三周岁的生日，期待与你一同分享！\n活动议程 本期议题以及嘉宾详解 《SOFA 三周年 \u0026amp;mdash;- 一起做些有趣的事儿吧！》\n嘉宾介绍\n黄挺，蚂蚁集团资深技术专家，目前主要负责蚂蚁中间件团队，推动了蚂蚁 Service Mesh，Serverless 等云原生技术在蚂蚁落地。\n议题简介\n SOFA 开源已经进行了三年的时间，在本次分享中，将会带大家了解 SOFA 开源三周年以来的一些心路历程，介绍 SOFA 开源未来的发展方向. 听众收获\n 了解 SOFA 开源的现状 了解 SOFA 开源的未来的发展方向\n 《机密计算如何为金融级基础设施保驾护航》\n嘉宾介绍\n田洪亮，蚂蚁集团高级技术专家，在机密计算、可信执行环境（TEE）和系统软件方面拥有丰富的经验，是蚂蚁自主研发的开源 TEE 操作系统 Occlum 的架构师。在加入蚂蚁之前，供职于 Intel 中国研究院。他于清华大学获得博士学位。\n议题简介\n 构建金融级基础设施的重要一环就是金融级安全性，而这正是 SOFAStack 技术栈中的 Occlum 项目所瞄准的目标。本次演讲将介绍蚂蚁集团在机密计算（Confidential Computing）和可信执行环境（TEE）方面所做的努力，尤其是如何通过蚂蚁自研的、开源TEE操作系统 Occlum 来实现零门槛、高性能的机密计算。 听众收获\n 了解机密计算这一激动人心的新兴技术方向；\n 了解机密计算领域的重要进展\n 《云原生网络代理 MOSN 新的助推器 —Envoy》\n嘉宾介绍\n王发康，蚂蚁集团技术专家，专注于高性能网络服务器研发，MOSN、Tengine 开源项目核心成员，目前关注云原生 ServiceMesh、Nginx、Envoy、Istio 等相关领域。\n议题简介\n MOSN 在 Service Mesh 领域作为东西向服务治理网络在蚂蚁集团双 11 、红包等活动及开源社区都得到了实践，为进一步节省研发及运维等相关成本，目前业界也有东西和南北向数据面进行统一的趋势。该演讲主题介绍了如何使用 Envoy 作为 MOSN 的网络层扩展，将 MOSN 和 Envoy 生态打通，同时使得 MOSN 底层网络处理能力具备 C/C++ 同等高性能、满足南北向高并发场景，又能复用 MOSN 的服务治理能力及 GoLang 的高研发效率。 听众收获\n 可快速了解如何使用 MOSN/GoLang 来扩展 Envoy 的服务治理能力\n 收获 MOSN 扩展 Envoy 时遇到的踩坑事项\n 了解 MOSN 开源社区进展\n 《新版 SOFARegistry 的多个 10X 提升》\n嘉宾介绍\n李旭东，蚂蚁集团中间件高级开发工程师，SOFARegistry Committer，专注于分布式中间件开发与优化。毕业后先后参与分布式服务发现体系构建和企业级 ServiceMesh 平台的开发。\n议题简介\n 随着集群的规模越来越大，服务注册中心的压力也越来越大。如何通过应用级服务发现改造减少服务数据一到两个数量级。现有服务如何利用 MOSN 无感知平滑迁移到应用级服务发现。分布式注册中心如何提高稳定性，如何利用混沌测试提前发现问题。SOFARegistry未来的发展方向。 听众收获\n 了解应用级服务发现如何进行实现和改造以及迁移的方案\n 分布式注册中心的质量和稳定性如何保障\n 《服务网格在企业落地的典型场景与实践》\n嘉宾介绍\n王磊，时速云CTO，负责时速云企业级容器 PaaS、中间件、DevOps、微服务治理、API 网关等多个云原生产品及相关解决方案的架构、产品和研发管理工作，对云原生相关领域有较深的理解及丰富的落地经验，致力于为企业构建新一代以应用为中心的云原生基础平台。曾在IBM中国开发实验室从事IBM中间件、Bluemix PaaS平台等产品的研发和设计工作。\n议题简介\n 当前，应用的微服务改造正在许多企业中如火如荼地进行，然而，微服务改造后的治理问题成了其进一步发展的障碍。在这一背景下，Service Mesh 应运而生，通过将治理能力下沉到基础设施层的方式来降低对业务应用的侵入。从实际需求出发，时速云基于 MOSN 等技术研发了自己的服务网格产品，克服了落地中的各种障碍，目前已在金融客户的核心生产系统中运行了1年多的时间，算是较早落地服务网格的典型案例。在这个过程中我们也感悟到，技术的先进性是持续追求的方向，而如何更好的结合实际场景才是推进服务网格落地的关键。本次分享主要介绍一下我们在落地服务网格时碰到的一些典型需求场景及实践经验。 听众收获\n 了解企业对于服务网格的典型诉求\n 了解服务网格落地时面临的主要问题与相关解决方案\n 服务网格的典型使用场景及未来展望\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1618210800,"description":"SSOFA 开源三周年，Let's have fun together！","dir":"activities/sofa-meetup-5/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"aee1e29a3825c8fdcafee69bc8a1613e","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-5/","publishdate":"2021-04-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/activities/sofa-meetup-5/","summary":"概要 活动主题：SOFA开源三周年，Let\u0026rsquo;s have fun together 活动时间：2021 年 04 月 24 日（周六）14:00-17:00 活动地点：北京海淀中","tags":["SOFAMeetup"],"title":"SOFA 开源三周年，Let's have fun together！","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-5/","wordcount":2041},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@闫文超 提问：\n 问下 SOFARPC 注册到 nacos 上，可以指定 group 的名字吗？想用于不同租户的隔离的功能。\n A：可以用这里的命名空间：\nnamespace :com.alipay.sofa.rpc.registry.nacos.NacosRegistry。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@霂白 提问：\n 注解方式发布的服务，有插件能自动生成给其他语言使用的 protobuf 的文件吗？Java 已经写了接口和 bean 的结构，直接转换为对应 pb 的文件。现在有 pb的定义文件转换注解方式的，Java 的代码的 maven 插件吗？写 pb 转 Java 或者写 Java 转 pb 两个方向总有一个通的吧，不然又写 Java，又写pb？\n A：这个我理解目前应该是没有的，不过确实是一个比较有意思的方向。\nA：pb 转 Java 问题不大，有现成的工具， 自己写一个也不是很复杂，Java 转 pb 不太兼容；pb 不支持两个参数，这里的问题在于传输协议，不在于代码格式，有需要我们开个 issue 详细聊下 ，鉴权这块后续应该会交给 MOSN 来做。 SOFAStack：https://github.com/sofastack/sofastack.tech\n3、@阿怪 提问：\n 请教大佬一个问题：TCC 模式，事务异常，回滚走自定义实现的 cancel 方法，这个方法里面操作了数据库回滚并且报错，有两个问题： 1.重试次数如何配置？ 2.线程的 ThreadLocal 的数据无法获取，BusinessActionContext 这个类获取不到，可不可以配置？\n A：那就用 localtcc，一开始的 TCC 不支持 spring cloud，后续开发了个 localtcc 的注解和功能来满足。 Seata：https://github.com/seata/seata\n4、@冯明明 提问：\n 我用的是最新版的 spring-cloud-ablibaba rpc 使用的 Dubbo 。截图中这种依赖方式，必须在接口上增加@LocalTcc 才能应用 TCC 模式。我看源码 这种依赖生成的是 xxx.proxy0 这种实现类不能被 RemotingParser解析，接口提供者倒是能被解析，但 DubboRemotingParser 生成的 RemoteSpec 的 protocol 属性是 Dubbo，源码中只有 injvm 能走 TCC 的相关逻辑，请问我是哪里没有配置正确吗 ?\n A：1.方便以后出控制台可以实时查看分支事务状态； 2.比如某些分支吞了异常后，有 report 的情况下方便判断。比如：a 调 b 再调 c，b 其实已经出现异常并且本地事务下已经回滚了，此时 c 响应给 a，a 做后续处理的时候异常，此时 TC 发现 b 已经由本地事务回滚了，就无需驱动了，这样就减少了下发的数量。 Seata：https://github.com/seata/seata\n5、@张红亮 提问：\n 能在 service 实现里再次调用的方法上加 @GlobalTransactional 吗？\n A：可以的，跟本地事务注解一样，支持事务传播。 Seata：https://github.com/seata/seata\n本周推荐阅读 Protocol Extension Base On Wasm——协议扩展篇\n WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n 本周发布 本周发布详情如下：\n1、SOFAJRaft 发布 v1.3.6 版本，主要变更如下：\n 增加 Replicator 的状态变化监听器  RheaKV 增加批量原子更新 API  Grpc 模块支持 max_inbound_message_size 配置  优化 RheaKV 内存占用  详细参考：\nhttps://github.com/sofastack/sofa-jraft/releases/tag/1.3.6\n","date":1617951600,"description":"SOFA WEEKLY | SOFAJRaft 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210409/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"403b28d70a485885d5c8b391175a5f81","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210409/","publishdate":"2021-04-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210409/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210409/","wordcount":1512},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 请教一下：为什么 KVStoreStateMachine#onSnapshotLoad 是 leader 的时候，不去做；leader 节点如果之前进行过 snapshot 之后，raft log 应该会被删除吧；后续集群重启的时候，leader 不用 snapshot 怎么保证数据还原呢？\n A：想一下，如果它还需要 load snapshot 的话，它是怎么变成 leader 的，如果已经是 leader 了，肯定不需要 load snapshot；理论上不会走到这个分支，只是防御性的代码，如果走到这个分支，就直接报错停止状态机了。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@明惑 提问：\n 现在创建 Grpc Server 的时候，只提供了 port 配置，考虑放开一些参数可以用户配置吗？比如 grpc 的 messageSize。\n A：helper.config看一下。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@刘明明 提问：\n 请教一下：我现在想用 Go 去写一个组件当一个简易的 Sidecar 去对其他服务做健康检查。这个 Go 组件要整合 nacos 注册发现和元数据管理，后期也会整合 Istio，这个组件干的事情应该和 MOSN 类似，Go 这边 0 基础，我是写 JAVA 的，就比如这个用 JAVA 实现只需要 springboot 就好了，Go 这边我调研了下准备用 go-Micro，请问各位这个方向是否正确？\n A：可以参考这个实现： https://github.com/mosn/mosn/issues/1087 这个是直接对接 zk 做的。\nMOSN：https://github.com/mosn/mosn\n4、@彭勃 提问：\n 请教一下，关于 TCC 模式下，会有发生空回滚，资源悬挂，幂等性等问题，需要通过事务控制表去管理。我此前看到同学介绍它们会将事务控制表变成 TCC 模式的一部分（2020 年初），让业务开发者不用自己关注这些问题，请问现在 TCC 模式已经做了吗？\n A：目前只能支持单数据源下的防悬挂，直接利用开启 spring 本地事务，然后做一些前置操作来预防。\nSeata：https://github.com/seata/seata\n5、@王译锌 提问：\n 请教一下：既然回滚依赖于异常上报给 TM，那为什么分支事务的状态还要上报给 TC 呢？一直没想通这个问题。\n A：1.方便以后出控制台可以实时查看分支事务状态； 2.比如某些分支吞了异常后，有 report 的情况下方便判断。比如：a 调 b 再调 c，b 其实已经出现异常并且本地事务下已经回滚了，此时 c 响应给 a，a 做后续处理的时候异常，此时 TC 发现 b 已经由本地事务回滚了，就无需驱动了，这样就减少了下发的数量。\nSeata：https://github.com/seata/seata\n本周推荐阅读 WebAssembly 在 MOSN 中的实践 - 基础框架篇\n MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n ","date":1617346800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210402/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"99c3b3c82b2f3fb86b66e6632aef8a20","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210402/","publishdate":"2021-04-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210402/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210402/","wordcount":1337},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 使用 jraft 跨 IDC 搭建了集群，一旦读 follower 节点，有 13ms 的网络延迟，用了lease read，读 leader 还好，直接返回。读 follower，要和 leader 通信，hreadb 有跨机房部署的场景吗？\n A：ollower 节点提供读能力，属于额外赠送的能力，其实 readIndex 的实现必须要和 leader 现有一个通信，这个没办法；我们不开 follower 读，从 leader 读；etcd 的 read-index 也是一样的原理，都需要请求一次 leader， zk 我了解貌似还不支持 follower 读；当然如果你不要求线性一致读，那么你绕开 raft 状态机，直接从你的存储里面读就好，如果你要的是最终一致性，那么你直接从 follower 节点上绕过 raft 直接读。 A：核心就是：follower 节点必须知道 leader 此时的 applyIndex 到哪里，然后需要再等待自己状态机的 applyIndex 也到达这个位置了才能提供读，否则就有可能一个数据 leader 上有，follower 上没有，这就很明显违背了线性一致读，所以和 leader 的这一次通信必须有，不过数据包很小，通常应该很快。 SOFAJRaft：https://github.com/sofastack/sofa-jraft 2、@吴岳奇 提问：\n 需求场景：AbstractRoutingDataSource 动态切换数据源，同一方法下，对两个不同服务器上数据表新增，涉及分布式事务。 问题: springboot 整合 Seata AT 模式 ，但无法动态代理数据源，一直代理的 yml 配置的默认的数据源。\n A：多数据源关闭自动代理；bstractRoutingDataSource 内部的多个数据源手动代理后放进去。 Seata：https://github.com/seata/seata 3、@彭勃 提问：\n 我在启动 Seata server 的时候，日志里报告了这种找不到 zookeeper 相关节点的异常；KeeperErrorCode = NoNode for /seata/store.mode。\n A：应该是用了zk 当配置中心，但是又没有写配置进去。 Seata：https://github.com/seata/seata \n本周推荐阅读 MOSN 的无人值守变更实践\n SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n ","date":1616742000,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210326/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"617144edd18f95b94e5860ed416ed165","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210326/","publishdate":"2021-03-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210326/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210326/","wordcount":1116},{"author":"嘉祁","categories":"Service mesh","content":" 本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。主要分为 3 个部分： -介绍 MOSN 在规模化运维中遇到的挑战 -无人值守上的实践 -MOSN 与技术风险方面的思考\n MOSN 规模化后的运维挑战 MOSN 早期在内部推进的时候，变更方面的支持是比较传统的。早期的变更工具只有基础的 pod 粒度的 MOSN 升级的能力。变更过程中的问题，最初依赖于上层业务系统的监控和反馈，稍后我们又在 MOSN 内建设了错误码。发布控制上，将版本区分为稳定版和灰度版本，升级的灰度过程和大范围的覆盖过程都由人工控制。这些方式在小范围、大量人力投入的情况下，保证了 MOSN 早期的快速演进和范围覆盖，也兼顾了基本的稳定性需求。\n随着 MOSN 的成熟，MOSN 的接入规模快速增长到了覆盖多个技术栈，数千应用的数十万 pod，涉及蚂蚁内部几乎所有的业务，早期的这些做法也遇到了很多问题。我们接入的应用不再只是 SOFA 技术栈的某些版本，业务也不再局限在某几条链路，大范围变更影响范围数倍甚至数十倍增长，风险变得极高，需要投入大量的人力评估每一个版本变更的影响。 举个例子，早期的 MOSN 几乎只需要考虑与较新版本的 SOFA 的对接。而当 node.js 应用开始接入时，MOSN 的变更也需要相应的考虑对 node.js 应用的影响。\n同样是为了减小风险，变更过程中尽可能减少单位时间的可能的影响范围，变更时长不可避免被拉长。\n早期的 MOSN 可能只需发布数十个应用，当范围扩大到过千时，如果单位时间发布的 pod 数据不变，那么变更时长即增加数十倍，变更的总时长变得荒谬。而如果总时长不变，则影响面和风险增加数十倍，风险不可控，业务也无法接受。\n最终结果是平衡单位时间的影响面和变更时长，风险放大无法避免，整体的迭代周期同样变长。更糟糕的是，新的特性不断堆积在下一个大版本，bugfix 也难以及时上线。这些问题最终不仅推高了下一次变更的风险，甚至直接影响当前生产的稳定。\n这么一个负向的循环需要如何打破呢。我们希望跳出传统的运维模式，既要变更的高效率，又要整体的稳定性。我们希望用技术来解决问题。\nMOSN 的无人值守变更 关于无人值守，一个可以借鉴的定义来源于近年火热的自动驾驶领域。同样都是希望把人从乏味的工作中解放出来，同样都需要面临复杂的环境问题。\n自动驾驶领域的等级定义方式也给了无人值守变更一个很好的参考点。最低级别的是 L0，一切都是人工操作，像云时代之前的时代，从装系统到应用部署，都依赖于人工命令行处理。 然后是 L1，平台提供了原子粒度的变更工具支持和基础的观察工具支持，如同早期的 MOSN。\n当这些工具更完善，提供一些基本的流程编排能力之后，开始进入自动化的时代，但可能随时需要人工介入处理。在此基础上，加上自动化的观测规则，把人工观察介入变成系统自动阻断，变更开始具备了无人值守的基本能力。 历经一年多的演进，MOSN 当前就处于这个阶段。我们也还在持续的完善和打磨，向着完全无人干预的方向演进。\n接下来我们来看 MOSN 是如何逐步达到无人值守的。 首先来看下风险的防控。前面我们提到，在传统的变更流程里面，需要人工介入的有变更范围控制；还有变更准入的检查，变更批次完成后，还要抽查确认变更结果以及业务异常情况。 也就是图上标红的这些内容。\n但是人本身是不可靠的。人为控制变更范围意味着灰度过程无法保证，准入的检查会存在比如信息不同步，规则遗漏的情况，完成情况的检查在大量应用或 pod 同步变更时，也只能做到少量抽检，无法避免问题被漏过。 把人工介入的部分交给系统，我们就有了一个初步可以脱离手动操作和人工观察的流程。\n上图展示了变更防御的介入流程。 变更范围改为由算法来自动产生的带有强度灰度的批次范围。前置准入与后置检查通过将变更类型与变更范围传递给变更防御的检查，通过检查才能继续执行。\n举一个简单的场景。MOSN 覆盖很多不同业务的链路，各业务有不同的变更保护时段，怎么来解决呢？\n首先在已经业务有保护时段的情况下，我们当然不能不管业务的风险强行变更。在有变更自动防控之前，我们只能找个共同的可变更时段，很多时候这就是半夜，但对于 MOSN 这么大规模的变更，半夜变更不仅仅是影响研发和运维幸福感的问题，只有半夜能变更的话，效率也无法接受。而有了变更的自动准入阻断规则，这个时间选择的问题立即就不存在了，我们只需要把所有应用的变更都跑起来，系统自动判断各自的可执行时段，甚至不需要参与变更的各方都知道所有业务的可变更时段。\n变更防控上线以后，极大的解决了我们的变更风险问题。但它并没有解决效率问题，一段时间来看，我们的效率甚至下降了。为什么? 我们分析了自身的变更过程，注意到两点：一是我们引用的业务错误的检查标准不一，部分业务的敏感度偏高或是阈值不合理，导致变更被持续阻断，无法继续；二则我们的全面检查放大了上面的问题，多个批次下来被中断的的概率也极大的提高了\n仔细来看业务的错误检查。这些检查不仅说明了 MOSN 自身的检查，还包括了业务的自身的错误和其它中间件、基础设施的问题。这些检查无法直接说明 MOSN 自身的健康情况。怎么解决呢？我们决定不再依赖这个不靠谱的检查，由 MOSN 自己来说明自己的健康情况。\n我们在 MOSN 中建设了两个层面的健康度观测能力。第一层是静态健康度，主要是 MOSN 的启动自检，在流量进入前完成，体现 MOSN 运行环境和基本启动依赖的健康情况；第二层是动态健康度，主要是 error metrics 日志，体现核心功能运行状态。结合这两层健康层，MOSN 就具备了完整了自身状态的观察能力，可以把业务的错误检查从变更检查中移除。\n我们还做了一个进一步提升变更效率的事情，彻底解决业务冷启动消耗的时间。\n无论是传统的原地升级或者是滚动升级的模式，过程都无法避免业务需要冷启动。由于业务依赖比较多，大部分业务的启动速度和成功率是大幅低于 MOSN 的，因此业务的冷启动时间一直是 MOSN 变更时间的大头。\n一个很好的解决方案是热升级。MOSN 自身是具备热升级能力的，下图展示了热升级的过程。 稍微解释一下的 MOSN 热升级过程。sidecar operator 会给待升级的 pod 注入一个新版本的 MOSN sidecar，旧版本的 MOSN 会收到连接迁移的请求，所有的长连接会被新版本的 MOSN 接管，完成之后旧版本 MOSN 会停止，sidecar container 被删除。\n热升级是一个很理想的升级方式，但是完善的热升级需要的条件和环境都比较复杂，需要 k8s 和 operator 的相应支持，而且被迁移的长连接需要同步的迁移状态，对于 MOSN 内的有状态协议也带来比较大的研发压力。\n我们的选择是把复杂做到了运维侧，做一个相对折中的方式。相对于热升级，这个方案没有那么热，我们称为温升级。 上图展示了温升级的过程。概括起来是三步：关闭待运维 pod 的所有入流量，升级 MOSN 的容器，打开流量。\n温升级去掉了业务的冷启动时间，避免了业务重启失败。MOSN 只需要做好配置的向下兼容，升级过程和传统升级过程几乎完全一样，但成倍的提升了升级效率。\n最后，我们说 …","date":1616677200,"description":" 本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。","dir":"blog/mosn-meetup-4-deploy-automation-at-large-scale/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"aec6af134a0e93f3576b7d5f3fd9101d","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","publishdate":"2021-03-25T21:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","summary":"本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。主要分为 3 个部分： -介绍 MOSN 在规模化运维中遇到的挑战 -无人值守上的实践 -MOSN 与技术风险","tags":["Service mesh","Service Mesh 落地实践"],"title":"mosn的无人值守变更实践","type":"blog","url":"/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/","wordcount":3465},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明惑 提问：\n 请教一下：JRaft 的 StateMachine 的 onApply 方法是线程安全的吗？如果在 onApply 里面有一些耗时操作的话，整个应用吞吐会下降很明显吧。\n A：是，对于同一个 st，onApply 必须由 JRaft 的单线程去执行，因为 raft 算法本身需要保证 raft log 被顺序 apply，所以这里没有线程安全问题；把结果同步了就好了，计算别放里头。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@孙军超 提问：\n 请教个问题：我现在直接跑 jraft-example 的 rheakv 的测试代码 PutExample，第一次调用 Rocksdb put 函数总会先阻塞整整 5 秒钟，server 端也没有任何报错。 A：猜测是 DefaultChannelId 里的 getProcessId() 太慢了，或者是 NetUtil 里获取 loopback 地址太慢，有一个办法可以证实：在 main 方法最开始提前 Class.forName 去加载这俩个类，应该会先卡住 5 秒，等到 rheakv 的逻辑执行时就不会卡住了；试一下我上面说的方法，猜测就是这两个类其中之一导致的：https://stackoverflow.com/questions/33289695/inetaddress-getlocalhost-slow-to-run-30-seconds； 配 etc/hosts 生效后可以解决。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@明惑 提问：\n 请教一下：状态机中 onApply 和 onSnapshot 的方式是线程安全的吗，我在这两个方法中操作同一个数据，会不会出现并发问题呢？\n A：onSnapshot 会暂停其他线程；不会有影响，onApply 又是单线程执行的。\nSOFAStack：https://github.com/sofastack/sofastack.tech\n4、@胡志奇 提问：\n Snapshot 的 save/load 方法都将阻塞状态机，应该尽力优化，避免阻塞。Snapshot 的保存如果可以做到增强备份更好。 onSnapshotSave 需要在保存后调用传入的参数 closure.run(status) 告知保存成功或者失败，推荐的实现类似：\n @Override public void onSnapshotSave(SnapshotWriter writer, Closure done) { // 同步获取状态机的当前镜像状态 state // 异步保存 state // 保存成功或者失败都通过 done.run(status) 通知到 jraft } 官网上说的，异步保存也会阻塞？\n A：没有问题，安全的；你截取的内容其实已经说得很清楚了，异步是指存储操作，同步是指获取当前状态机的镜像必须是同步操作；就是说：你必须在状态机被后续的 raft log 更改之前，拿到镜像，也就是拿镜像和 apply 是串行操作，一旦拿到镜像，你可以用异步的方式把镜像保存的磁盘上，甚至再压缩一下。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n5、@闫文超 提问：\n 问下大佬，SOFABoot 启动服务端暴露两个接口，但是 nacos 注册中心只注册了一个 RPC 端口，客户端调用接口报错\n A：SOFARPC + NACOS 有实践案例：https://www.sofastack.tech/projects/sofa-rpc/registry-nacos/ 如果还是解决不了可以上传一个可以复现问题的 demo 工程到 GitHub。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n6、@游侠 提问：\n 请教一下：在 SOFAJRaft，Learner 这种复制器，怎么理解？表示这个节点，只读？\n A：learner 不参与选举，可理解为冷备。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案\n 可信原生负责人入选“2021年度全球青年领袖”名单\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n ","date":1616137200,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210319/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"196034de19b2d4c77fbe5c88e6721a8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210319/","publishdate":"2021-03-19T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210319/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210319/","wordcount":1712},{"author":"SOFA 团队","categories":"sofagw","content":" 简介：本周将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会重点说明如何解决在安全、互通、接入成本、高效等几方面问题，接着介绍了SOFAGW网关的内部实现架构，最后是SOFAGW网关达成的业务成果。\n 1. 业务痛点 随着业务发展越来越多元化，部分业务域相对比较独立，或因其业务属性，会建立成独立的站点（租户），比如：国际业务和蚂蚁保等。这些站点之间网络是隔离的，但实际业务上会存在一些通信的需求，所以我们碰到的核心问题是：网络互相隔离的多个站点之间怎么做高效可信的通信？对此我们有两种针对站点间互通的解决思路：\n思路1：为每个业务创建跨域 VIP 为每个业务创建跨域 VIP，站点的业务通过 VIP 来做通信。这种方式，运维管理员要在两个网络间开很多 VIP，加访问白名单，最终网络拓扑会变成如下；将面临网络口子多、运维成本高、业务接入成本高、安全阈值低等问题。\n这个方案有以下几个问题：\n 很多服务需要开 VIP 口子，服务多了之后，VIP 难以维护； VIP 的 ACL 控制很弱，只能基于 IP 端口或 IP 段控制，不能按业务应用或服务来做控制； 安全管控能力很弱，对请求不可审计； 业务适配改造工作量大，技术栈不统一，存在多种 RPC 框架。 思路2：实现一个高效可信的互通网关，来承接站点之间的通信代理 这就是我们采用的多站点互相通信的解决方案，下面详细介绍我们的互通方案和重点解决的问题。\n2. 解决方案：SOFAGW 互通网关 鉴于上面提到的问题，我们研发了 SOFAGW 互通网关，致力于实现一个简单高效、安全可信的跨域 RPC/消息 互通网关。\n如上面的整体架构图所示，我们的解决方案是各站点部署一套 SOFAGW 网关，把站点间的通信都收敛到 SOFAGW 上，由 SOFAGW 来保证安全通信，而在研发体验上，业务方同学按照本地服务做开发，不用为跨域通信做特殊处理，做到无缝接入。\nRPC互通过程： 在 SOFAGW 网关上，申请接入需要互通的 RPC 服务。接入后，消费方 SOFAGW 网关会把这个 RPC 服务发布到本站点注册中心上，服务方 SOFAGW 网关会从注册中心订阅这个 RPC 服务提供方地址。 消费方应用通过注册中心订阅到目标服务是本站点的 SOFAGW，把请求发送到本站点的 SOFAGW。 本站点的 SOFAGW 根据 API 配置信息，把请求转发到对端站点的 SOFAGW。 对端站点的 SOFAGW 根据注册中心订阅到的地址，把请求发送给真实的服务提供方。 完成跨展达 RPC 通信。 消息互通过程： 消息的互通和 RPC 互通非常类似，差别主要在于需要通过消息中心来收发消息。\n 在 SOFAGW 网关上，申请需要接入互通的消息服务。 客户端把消息投递到本站点的消息中心，消息中心把消息封装成 RPC 请求发送到本站点 SOFAGW。 本站点的 SOFAGW 根据API配置信息，把请求转发到对端站点的 SOFAGW。 对端站点的 SOFAGW 把请求发送到消息中心，消息中心再把消息投递到真实的消费方。 完成跨站点消息投递。 SOFAGW 互通网关重点解决以下几个痛点：\n2.1 安全通信 首先我们要解决网络不可达问题。从图里可以看到：每个站点都部署了 SOFAGW 网关，网关之间可以用专线或 VIP 之类的产品打通，这样站点间把流量就收敛到了 SOFAGW 网关，避免到处开网络通道口子，便于安全管理。\n网络安全 为了保证 SOFAGW 网关之间的通信安全可信，我们开启了 mTLS 双向认证，既能对数据做加密，也能确认对方的身份可信，从而确保通信安全。\n数据安全 一个站点（租户）会给其他多个站点提供服务，这些暴露的服务首先要确保租户级别的水平权限隔离，也就是说，A 站点暴露给 B 站点的服务，不能被 C 站点的应用调用到。如何做到这点？\n SOFAGW 网关会给不同站点提供不同的访问域名（这些域名都会解析到 SOFAGW 的 VIP 上）。 SOFAGW 之间通过 mTLS 双向认证通过后，可以确认请求的域名（ host ）可信，也就是 C 站点的应用无法用 B 站点的域名与 A 站点的 SOFAGW 网关建立 TLS 连接。 SOFAGW 会通过请求头里的 host + path 路由做路由转发，C 站点的请求无法匹配上提供给 B 站点的域名，也就无法访问到提供给 B 站点的服务。 除了要确保租户级别的水平权限控制，SOFAGW 还具备应用级别的 ACL 权限控制，如果一个 API 服务只暴露给某特定应用，那其他的应用是无法访问这个 API 服务的。\n另外，站点间的通信数据不是任意的，目前在业务 API 接入过程中，我们会有严格的数据安全审计流程。\n2.2 统一技术栈，跨域 RPC/消息 互通 不同的业务方会使用不同 RPC 框架，如 SOFARPC、HSF、Dubbo，底层用的通信协议和序列化协议也不一样，很难直接通信，如果做协议转化适配又会有很大的成本。在性能、扩展性和新特性支持等方面，老的各种协议难以满足发展需求，也很难在原有协议的基础上扩展以支持新的功能。为了更好的支持业务发展，对齐各 RPC 框架通用能力，需要设计一种新的通用的协议，从协议层解决以上问题。\n所以，阿里巴巴及蚂蚁集团共同制定了 Triple 协议，让内部使用的编程框架都支持 Triple 协议，这样大家互通时就会很顺畅。\nTriple 协议是什么？\nTriple 协议本身，是基于 gRPC-over-HTTP2 扩展的 RPC 协议，与现有的其他 RPC 协议比较， 有以下优势：\n 多种 RPC 模式 ( P2P/ Reactive Streams/ Bidirectional / Pub-Sub ) 基于 protobuf 提供统一的服务定义以及 API 治理 更好的性能 ( Protobuf / Protostuff / Back Pressure ) 原生跨语言支持 ( C++/ Dart/ Go/ Java/ Python/ Ruby/ C# / OC / JS / PHP )，原生兼容 gRPC 客户端 易于升级和修改协议 兼容现有的 RPC 框架，易于协议升级和互通 ( gRPC / SOFA-RPC / HSF / Dubbo \u0026amp;hellip;) 对网关型应用友好，原生支持 gRPC-over-HTTP2 支持移动设备原生调用 Triple 遵循 gRPC-over-HTTP2 协议规范，使用 CUSTOM-METADATA 扩展元数据。对于已经存在的 grpc- 开头的 Header 保持不变，保证与原生 gRPC 客户端/服务端互通，对于协议中不存在需要新扩展的 Header，将以tri- 开头。另外，去年发布的 Dubbo 3.0 也是以gRPC为基础，Triple 能和 Dubbo 3.0 保持良好兼容。\n举例，当前我们约定的 Triple 协议头：\n2.3 无缝接入 为了让业务方无缝接入，SOFAGW 网关和注册中心专门做了联动，具体原理从上面的整体架构图可以看到：\n 在调用 …","date":1615878000,"description":"将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会重点说明如何解决在安全、互通、接入成本、高效等几方面问题，接着介绍了SOFAGW网关的内部实现架构，最后是SOFAGW网关达成的业务成果。","dir":"blog/sofagw-cross-domain-communication-solution/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"158827766506b1c5f49729b31a6f66e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","publishdate":"2021-03-16T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","summary":"简介：本周将介绍蚂蚁的SOFAGW互通网关，首先介绍我们在跨站点通信时碰到的核心痛点，然后我们引入SOFAGW互通网关的解决方案，这里我们会","tags":["Service mesh","Service Mesh 落地实践"],"title":"SOFAGW 网关：安全可信的跨域 RPC/消息 互通解决方案","type":"blog","url":"/sofastack.tech/blog/sofagw-cross-domain-communication-solution/","wordcount":4308},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@孙军超 提问：\n 请教一下 jraft-rheakv rocksdb 的 get put 操作，耗时要 5 秒钟，是服务端配置需要优化吗？ 以下是我的服务端配置截图。 A：kill -s sigusr2 可以看到性能指标度量，官方文档请看一下有相关说明。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n@戚金奎 提问：\n 请教一个问题：如图，目前服务都是通过 openfeign 远程调用，如果 setScore 所在的服务抛出了异常，是能直接出发事务回滚吗（我本地的无法出发回滚），还是需要在这个 seata1 里面接受一下返回值然后抛出异常才可以回滚吗（目前我这边是这种可以回滚）？\n A：决议全局提交/回滚的只能是\n@GlobalTransactional 注解的发起者，它 catch 到异常才会触发回滚；远端的异常应该是没抛给调用者，或者被框架拦截了异常。\nSeata：https://github.com/seata/seata\n@谭玖朋 提问：\n 这两个地方调用 rollback 有特殊意义吗？我发现在此之前没有更新操作啊。 A：这个地方应该是一个编码的习惯，在 autocommit=false 的时候，返回前都做一次 commit 或者 rollback 操作，确保当前的事务能够提交或者回滚，同时释放数据库的锁（哪怕前面并没有事务和锁）。\nSeata：https://github.com/seata/seata\n@戚金奎 提问：\n 请教一个问题：如果出现如图的这种情况， 执行的这个全局事务在获取全局锁之后，会获取 m 字段最新的值，再和自己的 before_image 里面记录的值去比较，发现不一致，全局事务失败并回滚。 A：所有写场景要被 globaltransational 覆盖，不允许直接去数据库改数据。否则就会出现在全局事务被决议回滚的时候，别的地方把这个数据改了。\nSeata：https://github.com/seata/seata\n@姜世存 提问：\n 请教一个问题，这个 LoadLevel 注解有什么作用\n A：所以别的业务要继承 Seata，写入口加入 globaltransational 注解，只读无需加注解。\nSeata：https://github.com/seata/seata\n@winyQ 提问：\n 项目里 Seata 用 AT 模式，可以在项目里再集成 JTA 吗，两个并存有没有什么问题？\n A：JTA 是 XA ，无法跟 AT 兼容。\nSeata：https://github.com/seata/seata\n本周推荐阅读 可信原生负责人入选“2021年度全球青年领袖”名单\n Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 本周发布 本周发布详情如下：\n1、sofa-common-tools 发布 v1.3.3 版本，主要变更如下：\n 修复 log space factory 的懒初始化模型问题  详细参考：\nhttps://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.3\n","date":1615532400,"description":"SOFA WEEKLY | sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210312/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f2a08527a8868ee63936378b903d5b07","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210312/","publishdate":"2021-03-12T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210312/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | sofa-common-tools 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210312/","wordcount":1269},{"author":"SOFA 团队","categories":"SOFAMeetup","content":" 概要 活动主题：SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望\n 活动时间：2021 年 03 月 21 日（周日）14:00-17:00\n 活动地点：浙江杭州西湖区学院路77号黄龙万科中心-I座\n 活动形式：线下活动\n 资料地址：点击链接\n 活动介绍 SOFAMeetup 牛年首站：3月21日 杭州见！\n久别重逢，朋友们，SOFAMeetup 回来了。 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁集团超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n本期 SOFA Meetup 将带来 Service Mesh专题： Service Mesh 在蚂蚁、美团的落地后，如何开展能力及基础设施的建设？如何更好的支撑业务发展？在Service Mesh 大规模落地后，MOSN 如何解决变更风险和效率问题？ 如何支撑 Service Mesh 的演进与优化？本次分享将会提供我们一些思考和实践！\n活动议程 本期议题以及嘉宾详解 《Service Mesh 在蚂蚁落地后的探索与实践》\n嘉宾介绍\n李唯，蚂蚁集团技术专家，2017 年加入蚂蚁集团中间件团队。参与了 Service Mesh 在蚂蚁的落地建设，目前主要负责 MOSN 在蚂蚁内部的设计开发。\n议题简介\n Service Mesh 在蚂蚁落地之后的能力建设，结合 MOSN 在蚂蚁的实践和探索，分析 Service Mesh 在大规模场景下持续向前演进的挑战及其背后的思考。 听众收获\n 了解 Service Mesh 在蚂蚁实践过程中遇到的困难和思考 收获 Service Mesh 在赋能业务方面的案例经验与启发\n 收获 Service Mesh 在研发效能方面的最佳实践\n 《MOSN 的无人值守变更实践》\n嘉宾介绍\n黄家琦，蚂蚁金服技术专家，SRE，专注于基础设施与中间件稳定性建设。深度参与了 Service Mesh 在蚂蚁内部大规模生产落地过程中的技术风险能力建设。SOFABolt-Python 组件维护者。\n议题简介\n 自 Service Mesh 在蚂蚁大规模落地之后，MOSN 的变更风险和效率问题愈发突出，本次将介绍从 SRE 视角下对于 MOSN 变更问题的思考，以及对于无人值守变更的实践。 听众收获\n 了解大规模 Service Mesh 下的变更问题与思考\n 收获 Service Mesh 在无人值守变更方面的经验与启发\n 《Service Mesh 在美团的落地挑战与实践》\n嘉宾介绍\n薛晨，美团基础架构团队技术专家，一直专注于分布式系统架构、服务治理领域和基础软件产品化。毕业以来先后深度参与了分布式调度系统、分布式配置服务、PaaS 平台构建和 Service Mesh 方向的探索和实践，在相关领域有较多的思考和沉淀。\n议题简介\n 云原生时代的到来，美团的服务治理系统 OCTO 也向 Service Mesh 的方向演进。作为集团的标准化基础设施，覆盖所有业务线和日均万亿调用，在演进的过程中我们面临着诸多挑战。 如何支撑和更好的支撑业务的发展？如何尽可能的保证演进过程的可靠和丝滑？如何更好的兼顾效率与稳定性？ 听众收获\n 了解超大规模服务治理系统 Mesh 化的最新进展\n 了解 Service Mesh 规模化落地的挑战和应对方案\n 对服务治理和 Service Mesh 未来的一些思考\n 《过往可鉴，未来可期 — MOSN 社区周年回顾与展望》\n嘉宾介绍\n田阳，蚂蚁金服高级技术专家，专注于高性能网络服务器研发，MOSN 开源项目维护者，Tengine 项目成员。\n议题简介\n MOSN 开启开源社区，独立运营已一年有余。在这期间，社区持续投入开源生态建设和云原生演进，并成为了 Istio 官方推荐的数据平面。本次我们将对过去一年的成绩进行回顾与总结，对未来社区的发展进行探讨与展望。 听众收获\n 了解 MOSN 的核心能力和支撑的业务场景\n 了解 MOSN 怎样支撑蚂蚁 Mesh 的演进和大规模落地所做的优化\n 了解 MOSN 后续规划，与 Envoy 社区的合作进展等\n 了解更多技术干货 使用钉钉搜索群号：34197075，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇 ","date":1615273200,"description":"SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望","dir":"activities/sofa-meetup-4/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2619f4f8ba15ac0f4fe43a82ef297db1","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-4/","publishdate":"2021-03-09T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/sofa-meetup-4/","summary":"概要 活动主题：SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望 活动时间：2021 年 03 月 21 日（周日）14:00-17:00 活动地","tags":["SOFAMeetup"],"title":"SOFAMeetup#4 杭州站 Service Mesh 领域的最新生产实践和未来展望","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-4/","wordcount":1552},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@刘嘉伟 提问：\n 请教一下：我在纯 TCC 事务 a、b、c个服务调用中 c 服务异常了，b 服务回滚日志是 rm handle undo log process: UndoLogDeleteRequest{resourceId=\u0026amp;lsquo;insert\u0026amp;rsquo;, saveDays=7, branchType=AT} 明明是纯 TCC 事务，怎么 AT 都出来了，导致了一个问题：TCC 数据源也没有代理的，也没有相应的 undo log表，然后 AT 事务回滚肯定无效的，TCC 的 cancel 也没有执行。\n A：这个理论上来说是没影响的，定时触发的，跟你本身的回滚逻辑应该没关系；这个 pr 会优化这个点：https://github.com/seata/seata/pull/3501。\nSeata：https://github.com/seata/seata\n@刘嘉伟 提问：\n 请问 AT 模式中如何防止事务回滚时，系统中一闪而过的脏数据，有时页面刚好打开，被用户感知到这些脏数据了；人工处理很麻烦，触发异常因为回滚操作有耗时，脏数据通常怎么处理；TCC 就没有这个问题，隔离的资源用户感知不到。\n A：数据在数据库，在数据库写被隔离的；前端本身就会有脏读出现，要靠后端保证。\nSeata：https://github.com/seata/seata\n@赵勇 提问：\n 比如这个图：A、B、C 各自都有自己的代码、自己的数据库，分开部署的；A 调用 B、C 提供的服务，那 undo_log 要在 db-a、db-b、db-c 里都建一份，然后 A、B、C 的代码里都要引入全局事务相关的类、包， 再加上把 GlobalTransaction 标到 A 的代码上，是这样实现吗；我看 GTS 的文档，感觉 undo_log 是 A 的代码引入的类包去写的，不是 B、C 自己写的，B、C 的代码还是该怎么写怎么写，不需要接全局事务相关的东西。 A：Undo_log 是每一个微服务的业务数据库都要建立，各自维护自己的 Undo_log；如果刚入门了解的话，先看看官网和跑一跑 demo。\nSeata：https://github.com/seata/seata\n@吴宗杰 提问：\n 2020 年 4 月份 Seata 从 1.2.0 支持 XA 协议，Mycat 支持 XA 分布式事务，是不是说明 Seata 和 Mycat 可以一起用？不过看到 19 年 slievrly 有和 Mycat 方沟通，后面应该也会支持的吧。\n A：可以试试，因为 Seata 所谓的 XA 模式是对支持了 XA 协议的数据库的 API 进行自动化的，XA 事务开启和统一提交回滚，Mycat 是属于一种 proxy，伪装的数据库层来代理背后的数据库，不知道这种结合会不会有什么问题存在，特别是 XA 这种出现中间层和 Seata 的兼容问题导致 XA 死锁就麻烦大了。\nSeata：https://github.com/seata/seata\n@谭玖鹏 提问：\n 请教一个问题，这个 LoadLevel 注解有什么作用\n A：看一下 EnhancedServiceLoader#getUnloadedExtensionDefinition 这个函数，跟一下 spi 那块加载的代码就知道了，跟 dubbo 那边差不多，dubbo 有个博客解析：https://dubbo.apache.org/zh/docs/v2.7/dev/source/dubbo-spi/。\nSeata：https://github.com/seata/seata\n@winyQ 提问：\n 不用 Seata 事务的数据操作方法里用的 datasource 还是代理数据源对象，这个没办法改吗，一旦设置 datasourceproxy，好像就一直只能用这个了。\n A：虽然拿到的都是 datasourceproxy，但是没有 globaltransational 和线程中没有 xid 的时候都是不会干预的；内部还是原来的 datasource 做操作，如果你确定没有 2 个服务以上参与的函数，可以用 globallock+ 对要修改的数据进行 for update 先再做写操作，会比直接加 globaltransational 注解效率高，但是相对而言入侵也高了。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Serverless 给任务调度带来的变化及蚂蚁集团落地实践\n Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 蚂蚁 Service Mesh 大规模落地实践与展望\n ","date":1614927600,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210305/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c5c658590a95eee0eb2c13cfb67d7d49","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210305/","publishdate":"2021-03-05T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210305/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210305/","wordcount":1701},{"author":"雪连","categories":"MOSN","content":" Serverless Task 是蚂蚁集团在分布式调度和批处理中间件发展而来的解决方案。通过 ServiceMesh 的精细化引流能力，再利用研发框架的“服务分组”配置能力，将 Serverless Task 流量全部收敛在指定的“服务分组”集群内。结合定时任务本身具备的周期、可预测等特点，根据任务执行情况弹性伸缩“服务分组”内的机器资源从而提升资源利用率和系统稳定性。\n 分布式调度在蚂蚁的场景和遇到的问题 在单体架构中，为了解决一台机器在固定的周期间隔执行相同的任务，避免人工干预过多，有了基于 Cron 的单机调度；随着企业级应用的发展和微服务化以及云原生架构的逐渐演进，原先的单体架构逐渐演变为服务化或者云原生架构。在此背景下，既要解决原先单机要解决的定时调度问题，还需要解决任务管理、负载均衡以及高可用、容灾等问题，同时兼顾用户体验的简单高效，分布式调度产品就应运而生。\n在蚂蚁域内，分布式调度广泛应用于各个 BU 的业务场景中，举例：如在支付宝上购买基金的用户每天需要计算基金收益，那么就需要在分布式调度的基础上结合批处理的能力，充分利用应用集群的处理能力，完成每一个用户基金净值的收益计算，典型处理场景如下：\n为了充分利用集群的能力，业务会采用按照业务各个维度拆分的方式对数据进行分片，然后根据分片原则加载数据，最后尽可能的将数据分散在集群机器上完成每一个用户基金净值的计算。通过类似上述集群执行的方式，结合分布式调度及批处理的能力，可以完成业务的计算诉求，但是由于这部分计算逻辑被原有的应用集群承载，随着业务的发展和数据量的不断增加，就会有如下的问题：\n稳定性问题：在线流量如 RPC/MSG 等与任务调度流量（简称异步任务流量）在 CPU/MEM/线程池 资源共享而引发的相互抢占导致的稳定性问题。\n资源利用率问题：异步任务流量最常用 Cron 表达式来描述，对于一天 24 小时只需要运行 7 个小时的任务来说，剩余的 17 个小时的资源就是浪费掉的。\n效率问题：业务同学在接入任务调度以及对批处理执行的控制，数据量统计、异常归类和动态调整参数等复杂性导致的研发效率较低；发布上线后，对处理速度、资源容量评估以及稳定性投入导致的运维效率较低。\nServerless Task 解决方案 为了解决上文分布式调度在蚂蚁的多年实践中遇到的问题，我们提供了 Serverless Task 的解决方案。\n通过故障隔离的方式来提高稳定性。Serverless Task 在不影响大家研发习惯的前提下，业务同学只需要通过在 PaaS 平台中，在同一个集群下申请“服务分组”集群，这些机器用于达到只承担异步任务的流量，而屏蔽其他在线流量的访问的目的。机器资源承载的流量做区分后，再配合 ServiceMesh 的精细化引流能力能够将流量收敛在指定的“服务分组”内，同时结合框架的“服务分组”配置能力，能够指定 Bean、消息、任务或者服务是否注册或者启动。通过上述的方式，最终能够实现，指定的异步任务收敛在指定的“服务分组”机器资源内，以此实现在线流量和异步任务流量的故障隔离，避免相互影响，而提升系统的整体稳定性。\n通过弹性伸缩的方式来提高资源利用率。基于可控弹性伸缩 HPA 技术，通过分析任务的 Cron 表达式或者基于 CPU/Mem/线程池等各项正常或者异常指标，能够将隔离在指定“服务分组”内运行异步任务的机器动态调整其 Pod 数量，在满足业务处理诉求的前提下，通过弹性伸缩技术最大化的提升资源利用率。\n提供更加产品化的能力。Serverless Task 支持处理器编排、支持迭代隔离、自定义参数和自定义限流等能力以提升业务的研发效率；同时，异步任务在故障隔离的基础上，利用弹性伸缩技术动态调整业务的 Pod 资源数量，可以让业务研发同学尽可能少的关注资源而只需关注任务的运行情况，以此极大的提升运维效率。\nServerless Task 关键能力介绍 弹性伸缩技术 上文介绍了 Serverless Task 的解决方案思路，为了真正实现 Serverless ，让业务同学不关注容量只关注业务逻辑，一个很重要的技术能力就是弹性伸缩。\n弹性伸缩技术，通过分析任务的 Cron 表达式或者基于 CPU/Mem 等各项指标计算出来的画像（每个时刻期望的 Pod 副本数量），来确定每个时刻的应该 Ready 的 Pod 数量，当在流量低峰或者任务没有在运行的时间就可以将机器缩容到相对较小的副本数。同时为了能够在最短的时间内恢复业务 Pod 的运行，启动速度是一个至关重要的指标，采用基于 ServiceMesh、JVM Elastic Heap 和内存 swap 的容器保活技术实现极速启动，来保证业务容器再恢复到期望的副本数时，有足够快的速度。\n 任务链路隔离与伸缩能力 通过上面描述的 Serverless Task 的解决方案，能够将异步任务的流量收敛在一个业务集群指定的“服务分组”集群内，并能够在弹性伸缩的基础上充分利用机器资源。但是，这样就会导致新的问题，当上游系统被隔离后，其处理速度和稳定性都会一定程度的增加，但是对下游的调用量就会激增，导致下游出现热点或者稳定性问题。基于此，我们提供了任务链路的解决方案，期望将 Serverless Task 触发异步任务的门面系统以及对下游系统的调用，都能够通过“服务分组”的方式隔离开，期望组合成一条异步任务流量作为入口流量的任务链路，具体的实现方案如下所示。\n每一个 Serverless Task 在周期触发时都会自动携带染色标识（每一个异步任务的唯一标识），通过在任务调度平台选择当前异步任务要引流到的“服务分组”，就可以完成门面系统的 Serverless Task 到指定“服务分组”的引流。每一次 Serverless Task 调用门面系统均携带染色标识，门面系统紧接着对下游系统再发起调用，门面系统结合控制面的业务引流能力，就可以在控制面对门面系统下发引流规则，并配置流量比例，便可以将门面系统对下游系统的调用也收敛在指定的“服务分组”集群内。以此类推，下游系统如果继续有对后续系统的调用，也可以采用类似的方式推送引流规则来完成指定调用流量的“服务分组”集群收敛，以此来完成一条 Serverless Task 作为入口流量的任务链路的流量隔离，并具有单独的业务语义，比如：批扣链路、计价链路。\n在完成了任务链路的隔离之后，由于入口的流量是由异步任务驱动或者触发的，流量是能够通过 Cron 或者运行状态做比较准确的预测，那么在任务链路执行完毕后，就可以将整个链路的资源全部伸缩掉，同样当异步任务的流量高峰到来之前时再扩容出足够的机器资源，以此在隔离出任务链路的同时，还能提升整体任务链路的稳定性以及整个任务链路的资源利用率。\n总结与展望 通过 ServiceMesh 的精细化引流能力，可以将 Serverless Task 流量收敛在指定的“服务分组”集群内，再利用框架（如 SOFA Boot）的“服务分组”配置能力，控制非期望的 Bean 和服务在“服务分组”集群内关闭，最终就能够做到将 Serverless Task 流量完整的收敛在指定的服务器集群内，达到流量收敛的目的后，再结 …","date":1614668400,"description":"如何实现任务调度和存量应用的 Serverless 化，本文为大家介绍 Serverless Task 是如何实现这一解决方案。","dir":"blog/antgroup-serverless-task/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cb83515191621dc518d49a84ac297f0e","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-serverless-task/","publishdate":"2021-03-02T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/antgroup-serverless-task/","summary":"Serverless Task 是蚂蚁集团在分布式调度和批处理中间件发展而来的解决方案。通过 ServiceMesh 的精细化引流能力，再利用研发框架的“服务分组”配置能力，将 Serverless Task 流量全部收敛","tags":["Serverless","任务调度","弹性伸缩","ServerlessTask","Service Mesh"],"title":"Serverless 给任务调度带来的变化及蚂蚁集团落地实践","type":"blog","url":"/sofastack.tech/blog/antgroup-serverless-task/","wordcount":2748},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@宓文明 提问：\n 请教：大家有没有遇到过 SOFAArk 工程这样的情况：双机房集群部署（检查模块 jar 大小相同、MD5 相同、部署时间相同），其中一台服务器中报错 NoClassDefFoundError（调用模块工具类的静态方法时，工具类找不到），其余的服务器都 OK。 A：你们登录到机器上去，堆栈是有的；这种问题可能是因为底层有 class 没找到，两个思路： - 版本冲突 ，不一定局限在你的 JsonUtil 这个类，里面的类也有可能引发 。 - 通过 arthas ，分析下不同 bizClassLoader 加载 JsonUtil 的情况。\nSOFAArk:https://github.com/sofastack/sofa-ark\n@郭强 提问：\n MOSN 是如何保证一定是先于业务容器启动，并且保证是后于业务容器销毁呢？\n A：启动就是按 pod 里的容器顺序启动，MOSN 容器在 APP 容器前。APP 容器内的应用进程启动前会检查 MOSN 的端口是否存活，得等到 MOSN 进程启动完成才能继续。销毁 pod 的时候没有特别处理，就是摘了pod 的流量整个销毁。\nMOSN:https://github.com/mosn/mosn\n@郭强 提问：\n APP 容器内的应用进程启动前会检查 MOSN 的端口是否存活。 这个是怎么做到的呢，是自动修改应用容器的 command 配置？还是说需要应用进程的 dockerfile 保证一定规范吗？\n A：蚂蚁内部的 Kubernetes 有针对性的做一些定制改造支持，标准 k8s 目前是控制不了容器启动顺序的； 最好的方式还是 k8s 原生支持 sidecar lifecycle，没有这个的话，相对折中的方式就是在应用启动脚本前 check 下了。\nMOSN:https://github.com/mosn/mosn\n@饶文强 提问：\n 请教一下：我不是很理解这一步锁撤销的步骤：线程 A 进入同步代码块方法，尝试获取偏向锁，此时若 CAS 线程 id 替换失败，为什么涉及一个偏向锁撤销，线程 A 不是没有获取到锁。我的理解是此时锁对象的偏向锁线程 id 不是线程A本身，为什么还需要偏向锁撤销？ A：因为偏向锁可以被降级，其他的不可以，这个时候需要升级锁或降级锁；偏向锁持有者是不会做降级操作的，只有前来竞争锁的线程会去判断。\nSeata:https://github.com/seata/seata\n@莹 提问：\n 有个场景：tcc 模式，try 方法创建订单记录，插入到数据库，然后异常回滚，在 rollback 方法中把这个订单记录根据主键删除，请问数据库主键字段怎么传过去？\n A：可以通过一阶段把 xid 对应业务信息存在 redis 中，二阶段通过 xid 拿出来使用。\nSeata:https://github.com/seata/seata\n@敲跃 提问：\n 问个问题：Seata 的 at 和 saga 模式 一阶段本地事务已提交，为了防止这部分数据被其他事务读到，文档给的解决方案 \u0026amp;gt; 脏读 select 语句加 for update，代理方法增加 @GlobalLock+@Transactional 或 @GlobalTransaction ； \u0026amp;gt; 实际操作的时候：涉及到本地事务的表的所有 sql 和方法都要这么改造，会不会成本太大，有没有其他好点的解决方案？\n A：涉及到所有的写入口加上 @GlobalTransaction 即可；只读场景 @GlobalLock +for update 即可；读了就写场景一定要 @GlobalTransaction，只读了给前端展示之类的。\nSeata:https://github.com/seata/seata\n本周推荐阅读 Service Mesh 双十一后的探索和思考(上)\n Service Mesh 双十一后的探索和思考(下)\n 蚂蚁 Service Mesh 大规模落地实践与展望\n 基于 MOSN 和 Istio Service Mesh 的服务治理实践\n ","date":1614322800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly20210226/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fff3af65c30bb18078a3222b86261205","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly20210226/","publishdate":"2021-02-26T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly20210226/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly20210226/","wordcount":1351},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@王盛 提问：\n 这个配置在 sidecar 里面怎么改，这个怎么配到 Istio 里面?\n A：在 Istio 中关于 tracing 这块的 driver 目前是通过配置 xxx_bootstrap.json 静态配置的，然后通过 istioctl 命令参数来选择使用哪个 driver。当前由于 skywalking 自身配置还没作为 bootstrap 的静态默认配置，所以需要你自己修改下 xxx_bootstrap.json，这个配置就好了（即把上面的那个配置加进去）。简单说就是修改下 sidecar 的静态默认配置文件，增加 skywalking 为 tracing 的 driver 配置。\nMOSN：https://github.com/mosn/mosn\n@卞平超 提问：\n TCC 多阶段；rollback 可以设置顺序吗？比如被调用的服务，先回滚，再回滚主服务的，A-\u0026amp;gt;B，想先回滚 B 的数据，commit 和 rollback；方法中的业务代码有异常，是会不断的重复执行。\n A：TC 的表字段 datetime 看下精度，二阶段都决议了，没有从 commit 异常，直接到 rollback。如果 10 个参与方，就 1 个 commit 异常，不去重试保证最终一致的话，数据不就乱了；已经决议了，就要保证起码能最终一致，而不应该串改结果，参考消息队列设计，为什么消费异常要重试。\nSeata：https://github.com/seata/seata\n@方舟 提问：\n 请问一下，在 TCC 模式中，如果 TM 和 TC 断开连接，能够保证全局事务的回滚吗，重连超时后，全局事务会回滚吗？\n A：会重连，然后重试；需要你自己保证幂等和悬挂，会等你连上之后再重试。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁集团轻量级类隔离框架概述 | SOFAArk 源码解析\n 蚂蚁集团研发框架总览 | SOFABoot 框架剖析\n SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理\n 蚂蚁集团 API Gateway Mesh 思考与实践\n 本周发布 本周发布详情如下：\n1、SOFARPC发布 v5.7.7版本，主要变更如下：\n 使用 Github Action 替代 Travis 进行持续集成 升级 jackson-datebind 到 2.9.10.7 升级 junit 到 4.13.1 修复了Rest中，当请求经过代理源IP获取不准确的问题 修复了内置 Protobuf Compiler 的 BUG 详细参考：https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.7\n","date":1613718000,"description":"SOFA WEEKLY | SOFARPC 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210219/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"29b9f9ae46cecd6979ce334f8e11baf0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210219/","publishdate":"2021-02-19T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210219/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210219/","wordcount":1096},{"author":"李唯","categories":"云原生","content":" Service Mesh 双十一后的探索和思考(上) 引言 2019 年 Service Mesh 在蚂蚁大规模落地并完美支撑双十一核心链路，对于落地过程在去年已经有系列文章解读。而在此之后的一年多时间，Service Mesh 在蚂蚁又在如何演进呢。本文介绍蚂蚁 Service Mesh 在双十一落地之后所做的探索和思考。\n能力建设 得益于 Service Mesh 将业务和基础设施解耦，在过去一年中我们的基础设施能力得到了飞快的发展。大量能力大规模落地蚂蚁。例如链路加密，可信身份认证，服务鉴权，自适应限流，集群限流，精细化引流，服务自愈等。这里先对四个能力进行解读，其它能力后续再有文章讲述。\n链路加密 为了达到一个更高的安全水位，我们预期在蚂蚁内部所有的通信 100% 加密覆盖，这就是链路加密。\n设计 链路加密落地最大的挑战就是加密对业务不能造成影响，包括几个问题：\n 必须简化大规模场景下的运维复杂度问题，需要具备可灰度、可回滚的能力； 灰度运行期间，明文和加密切换不能对业务请求造成影响，需要进行热切换； 开启加密以后，对性能的影响必须控制在可接受的范围内； 基于这些需求，完成了链路加密的架构设计，主要思路包括：\n 通过统一的管控面控制服务端应用的配置，基于动态服务发布与订阅机制，在服务端支持加密能力以后，客户端自动进行加密的切换，运维人员只需要控制服务端配置节奏完成灰度；在灰度运行期间，服务端同一个端口需要同时支持明文和加密的能力； 相比于明文通信，基于 TLS 加密的通信主要消耗在连接建立的握手期间，服务端和客户端采用长连接的方式，减少连接的建立，以减少开启加密对性能的影响； 客户端在感知到服务端明文和加密状态变化以后，需要在不同的长连接之间进行稳定的切换，后文会详细介绍； 完整的一个加密开启流程如图所示，首先运维人员在管控面选择需要开启加密的应用，通过 XDS 完成配置下发。MOSN 在收到配置以后，会基于 SDS 机制获取到证书和私钥在内存中，证书和私钥由统一的 Secret 进行管理，应用侧不持久化保存。收到证书和私钥以后，会向注册中心发布本机已经支持了加密，注册中心会向所有订阅的客户端进行推送，客户端收到推送以后，与服务端的通信切换到加密状态。\n加密状态热切换：连接淘汰机制 我们的加密通信是基于 TLS 进行的实现，一个连接在建立好并且开始传输数据以后，连接上的数据是 TLS 加密的还是明文的就已经固定了，不存在将一个明文通信的连接变成 TLS 加密连接的情况。基于 TLS 这个机制，通信从明文切换到加密时，一定是需要新建一个连接，并且成功完成 TLS 握手。\n为了做到在连接切换期间业务请求不受影响，MOSN 实现了一个连接淘汰机制，用于连接加密状态的热切换。 每一个请求在 MOSN 中经过了路由和负载均衡以后，会选择到一个后端地址，基于这个地址从连接池中选择对应的长连接转发请求，在引入了加密切换以后，每次选择到连接以后，都需要判断当前预期的加密状态和连接的加密状态是否匹配，如果不匹配，则会创建新的连接进行加密状态的切换，并且使用新连接将连接池中的旧连接代替，这样就可以确保后续的请求都使用状态匹配的连接。对于被替换的旧连接，我们需要进行淘汰，但是这个淘汰不是简单的断开连接，因为旧连接上可能还有正在处理的请求，如果直接将连接断开就会导致请求有损，这是不能接受的。\n那么是如何淘汰旧连接的呢？这里就要讲到 MOSN 的长连接保持机制了。为了避免因为异常断网等导致连接“假死”的情况，在连接空闲时，会主动发起心跳请求，确保连接处于活跃状态，而如果服务端一段时间内都没有收到心跳，则会主动将连接断开。连接淘汰就是利用这个机制，对于准备淘汰的连接，我们将停止该连接的心跳发送，当连接上的请求处理结束后，这个连接上就不再会有任何数据的传输，经过一段时间后，服务端就会主动将这个连接断开，此时连接断开是安全的，不会影响任何请求。 优化 对应用无感知开启加密，除了指开启过程中不需要重启、请求无损等，还包括在开启以后的资源消耗、RT 影响也需要是无感知的。在实际落地应用过程中，由于我们都是使用长连接，TLS 握手带来的建连消耗只占用了很少一部分，在长连接通信过程中的对称加密消耗经过实际测试几乎可以忽略不计，看上去链路加密对性能的指标没有什么问题。\n但是在实际大规模落地以后，我们发现部分应用开启了加密以后，内存占用有显著的上涨，经过排查，定位到属于Golang TLS 标准库实现问题（ MOSN 是使用 Golang 编写的），我们自行优化以后，也向 Golang 官方提了 PR回馈社区，目前该 PR 已经被 Golang 官方所接受，预计在 go1.16 中发布，具体实现可以见 crypto/tls: pool Conn\u0026amp;rsquo;s outBuf to reduce memory cost of idle connections\n自适应限流 流量管理本身就是 Mesh 架构最为核心的功能之一，我们在 MOSN 中实现了多种策略的限流能力，包括单机 QPS限流、集群限流、热点限流、接口熔断、自适应限流等，其中自适应限流是一大亮点。\n限流是每个技术同学都不陌生的名词，同时也是很多不同角色的同学头疼的事情。对于业务同学而言逐个接口做容量评估和压测回归费时费心，有限的精力只能投入到重点的接口保障上，难免会漏配一些小流量接口的限流；而负责质量和稳定性保障的同学经常在故障复盘时看到各种漏配限流、错配限流、压测故障、线程阻塞等造成的各种故障\u0026amp;hellip;\u0026amp;hellip;\n我们希望即使在系统漏配错配限流的情况下，在系统资源严重不足时 MOSN 能够精准的找到导致系统资源不足的罪魁祸首，并实时根据系统水位自动调节异常流量。这就是自适应限流想要实现的效果。\n技术原理 能用一句话说清楚你们的技术原理吗？ 类 PID 控制流量闭环自适应调节 朴素的解释就是，触发限流后一边观察系统整体水位，一边秒级按比例调节流量的策略，用一张图来解释具体的原理： 1.系统资源检测：秒级检测系统资源占用情况，如果连续超过阈值N秒则触发基线计算，同时开始拒绝压测流量进入； 2.基线计算：将当前所有的接口统计数据遍历一遍，通过一系列算法找出资源消耗大户，再把这些大户里明显上涨的流量找出来，把他们当前的资源占用做个快照存入基线数据中； 3.基线调节器：将上一步骤存入的基线数据根据实际情况进行调整，根据系统资源检测的结果秒级的调整基线值，若系统水位超过阈值则按比例下调基线值，否则按比例恢复基线值，如此反复； 4.限流决策：根据上述步骤生产的基线数据决策是否限流；\n自适应限流已在全站线上应用中大规模启用，成功防范了多起业务故障。为新春红包压测和线上业务保驾护航。\n技术优势 相较于传统的限流组件，MOSN 中的自适应限流具备很多优势，MOSN 架构天然的流量劫持让应用无需逐个接入SDK，也无需为特定语言开发不同版本的限流组件，同时给业务同学降低了配置的难度，也为业务实现了兜底保护。在研发效能和研发成本上都取得了明显的收益。\n MOSN 自适应限流 传统 QPS …","date":1613548800,"description":"本文介绍蚂蚁 Service Mesh 在双十一落地之后所做的探索和思考。","dir":"blog/service-mesh-exploration-thinking-after-1111-1/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3a08e94a57454e3ef36f8eee6da6795e","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","publishdate":"2021-02-17T16:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","summary":"Service Mesh 双十一后的探索和思考(上) 引言 2019 年 Service Mesh 在蚂蚁大规模落地并完美支撑双十一核心链路，对于落地过程在去年已经有系列文章解读。而在此之后的一年多","tags":["云原生"],"title":"Service Mesh 双十一后的探索和思考(上)","type":"blog","url":"/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/","wordcount":5691},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" 本文作者：蚂蚁集团黄挺（花名鲁直），SOFAStack 社区主理人，同时负责蚂蚁集团云原生方向的推动和落地，包括 Service Mesh、Serverless、消息、微服务等领域，带领 SOFA 团队扎根技术完成很多落地实践。\n 大家好，我是鲁直，有段时间没有和大家见面，今天是农历一年的起点，首先祝大家新年快乐，在新的一年牛气冲天！在这样特别的日子里，我想和大家分享对于 Service Mesh 未来方向的思考，再谈谈 SOFAStack 社区接下来计划做的一些事情，希望大家接下来能够在社区里面玩得开心，let\u0026amp;rsquo;s have fun together! Service Mesh 是否已经解决了所有问题？ 2020 年， SOFA 团队宋顺（花名齐天，当前蚂蚁集团 Service Mesh 负责人）在 QCon 上海站分享了《蚂蚁 Service Mesh 大规模落地实践与展望》，详细讲述了 Service Mesh 在蚂蚁集团的进展和未来规划。 在过去的几年里面，Service Mesh 在整个云原生社区如火如荼地发展，从刚开始的 Linkerd，到后面的 Istio，不断地有大公司加入到 Service Mesh 的领域的开拓之中，随着小剑、净超等同学在国内布道 Service Mesh，Service Mesh 从 2017 开始在国内火热程度也不断升温，SOFA 团队也在这个时候开始关注到 Service Mesh 这个领域，并且开始在内部尝试做落地的事情，也和业界的很多朋友一起举办了一场又一场的 Service Mesh Meetup。\n应该说我们是幸运的，成功在 2019 年实现了 Service Mesh 在蚂蚁大促业务链路上的全面落地，获得了大规模落地 Service Mesh 的经验，并且在这之后持续应对 Service Mesh 大规模落地之后的遇到的各种挑战，截止到 2020 年底，蚂蚁集团已经基本上实现了在线业务的全面 Service Mesh 化，在一部分网关场景上，也采用了 Service Mesh 的架构，实现了南北向和东西向流量架构的统一。\n但是随着 Mesh 化的进程不断地往前推进，一直在我们心中萦绕这一个问题，Service Mesh 在一定程度上解决了基础设施和业务耦合的问题，但是是否已经把所有的问题都解决完毕了？这个问题的答案显然是没有全部解决完毕，这个尚待解决的问题还是基础设施和业务耦合的问题。\n目前包括蚂蚁集团在内的各种各样的 Service Mesh 的解决方案，都是会选择采用尽量透明的方式去适配应用已有的协议，让业务尽量减少接入 Service Mesh 的成本，即使不是全透明的方式，而是采用瘦 SDK 的方式接入（蚂蚁集团目前采用了这种方式），也是为了这个目的。在这种形态下，应用固然可以透明地获得非常多的能力，包括限流，服务发现，安全通信等等，但是一旦涉及到 RPC 协议的变化（从 SOFARPC 到 gRPC），后端缓存的变化（从 Memcached 到 Redis），应用还是需要去修改代码适配新框架的 SDK，这又是一件无论让应用还是让基础设施团队非常痛苦的事情，本质上还是应用去适配基础设施的变化，而不是反过来。\n###\nService Mesh 的未来方向：Cloud Native Application Runtime 那么我们应该如何去解决这个问题？在一次内部的会议上，我们和几个同事在讨论如何对 K8s 里面我们自定义的 Operator 进行规范化的问题，防止一个有问题的 Operator 把整个 K8s 搞挂了，但是一个同事提出了 Operator Framework 的想法，在 Operator 里面运行一个 Sidecar，这个 Sidecar 提供 Operator Framwork 的能力，这里面给了我们一个启发，可以用 Sidecar 这种模式去实现一个开发框架，一个运行时，来更好地帮助业务屏蔽掉对于后端基础设施的访问，我们看到业界也出现了这样的一些产品，比如 Dapr，CloudState 等，在这种模式下 Sidecar 已经不是一个简简单单的 Proxy，而是一个 Runtime，我们把这种形态称之为 Cloud Native Application Runtime。\n这种模式之所以可以称之为 Cloud Native Application Runtime，关键还是 Sidecar 定义了一套面向应用的 API，这套 API 正是解耦应用和基础设施的关键。有了这套 API Spec，就相当于在应用和基础设施之间构建了一层防腐层，只要这一层 API Spec 能够持续往前保持兼容，后面的基础设施不断地演进和变化，都不会动到应用侧，基础设施和应用之间才能够实现更加彻底的分离，未来基础设施无缝升级才会成为可能。未来云原生的应用在不同的云之间迁移，甚至基于多朵云来构建应用，应用这一侧也不用重复进行适配的工作，应该说，这种模式也是符合未来混合云的方向的。所以，我们大胆的预测，未来 Service Mesh 持续往前继续演进，必然会发展到 Cloud Native Application Runtime 这样的方向。\n基于这样的思考，在 2021 年，SOFAStack 社区一方面会继续推进已有的项目的健康发展，另一方面在继续在Service Mesh 的方向上深耕：继续分享在 Service Mesh 领域上的一些新思考之外，比如 Service Mesh 大规模落地之后的研发效率和运维效率的解决思路，我们也会和社区中的其他的组织一起通过 Service Mesh 的 Meetup 等活动继续推动 Service Mesh 的理念在国内的影响力，以及企业落地实践。（PS：最近 MOSN 刚刚公布了 2021 年的 RoadMap，欢迎大家关注：https://github.com/mosn/mosn/issues/1559，其他项目的 RoadMap 也会在春节后陆续和社区讨论然后公布；我们计划在 3 月份举办一次 Service Mesh 的 Meetup，欢迎感兴趣的社区同学报名)。\nSOFAStack 开源社区即将成立三周年，SOFA 团队深刻地体会到一个开源项目的持续健康地发展，关键在于社区和社区中的每一位开发者，是你们每一个 star，每一个 issue 和 PR 推动着项目的成长。特别感谢接近三年时间，大家一同参与社区建设，感谢一起帮助社区成长的小伙伴们。SOFAStack 开源社区还有很长的路要和你们走，我们也会联合其他社区一起推动 Cloud Native Application Runtime 的理念的落地和实践，希望有更多开发者可以和我们一起去探索 Service Mesh 的未来形态，一起推动其成为云原生应用构建的一种标准方式。\nAwesome SOFAer, then awesome SOFAStack， Let\u0026amp;rsquo;s have fun together！\n","date":1613113200,"description":"Special Weekly | SOFAStack 社区牛年展望，Let's have fun together!","dir":"blog/sofa-weekly-20210212/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3ef0208984bc034e62f2db51cf66a8e4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210212/","publishdate":"2021-02-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210212/","summary":"本文作者：蚂蚁集团黄挺（花名鲁直），SOFAStack 社区主理人，同时负责蚂蚁集团云原生方向的推动和落地，包括 Service Mesh、Serverles","tags":["SOFA Weekly"],"title":"Special Weekly | SOFAStack 社区牛年展望，Let's have fun together!","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210212/","wordcount":2162},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@李明阳 提问：\n SOFAArk 的项目里面 controller 层可以是 Biz 包么，这样 mng 里面引入 one，然后启动 mng 访问不到 one 里面的接口呢？ A：SOFAArk 的项目里面 controller 层不限制的，biz 包部署普通的依赖包，它是一个可执行的 jar，ark包 = biz + plugin + container，动态部署你可以通过 telnet 指令的方式去动态安装，不建议直接塞到 pom 里面去。\nSOFAArk：https://github.com/sofastack/sofa-ark\n@王盛 提问：\n 请教个问题：\u0026amp;ndash;set meshConfig.defaultConfig.binaryPath=\u0026amp;ldquo;/usr/local/bin/mosn\u0026amp;rdquo; 这个不起作用，有谁碰见过这个情况？ A：你用的是 istio1.5.2 吧，这个是不行的，istio 代码写死了的。这种手动注入应该可以的。这一块儿有些细节没有说明，你可以重新提交一下 pr。 MOSN：https://github.com/mosn/mosn\n@杨星 提问：\n 如果 Seata 使用注册中心的话，Client 端的 registry.type，与 config.type 需要改成对应的注册中心吧，Client 端的这两项配置的作用是什么？SeataServer 的这两项配置倒好理解，Client 端的config.type 目的是读取client端的配置信息，那 registry.type 是干什么的呢？\n A：我认为，registry.type 指的是注册中心的类型，config.type 指的是配置中心的类型。注册和配置中心是 2 个东西，我认为是从注册中心里拿 seata-server 实例，客户端找协调者。\nSeata：https://github.com/seata/seata\n本周推荐阅读 干货 | 蚂蚁集团是如何实现经典服务化架构往 Service Mesh 方向的演进的？\n 开源 | SOFAMesh 的通用协议扩展\n 【剖析 | SOFAMosn】系列之 SOFAMosn 的诞生和特性总览\n Service Mesh 发展趋势：云原生中流砥柱\n MOSN 项目进展 本月我们还认证了一位新的 Committer，是来自字节跳动的 郑泽超 同学，感谢 郑泽超 同学为 MOSN 社区做出的贡献。\n本周发布详情如下：\n1、MOSN发布 v0.21.0 版本，主要变更如下：\n 限流模块升级与优化，支持自定义过滤条件等能力 为适配路由支持变量机制对部分常量名进行了不兼容的删除和新增，可能会影响部分基于 MOSN 的代码编写 新增了 DSL(Domain-Specific Language)的路由支持 StreamFilter 模块支持加载基于 Go 动态连接库编写的 Filter 基于 XProtocol 实现了 DubboThrift 协议的支持 其他 BUG Fix 与优化 详细参考：https://github.com/mosn/mosn/releases/tag/v0.21.0\nSOFABoot 项目进展 本周发布详情如下：\n1、SOFABoot发布 v3.6.0 版本，主要变更如下：\n 支持本地开发时自动将 SOFABoot 日志输出到控制台 startup endpoint 采用新的数据格式，支持按时间轴分析 修复 baen 加载耗时的图形化展示问题 修复 ReadinessCheckListener 的启动顺序问题 SOFARPC 升级版本至 5.7.7 SOFATracer 升级版本至 3.1.0 SOFA-common-tools 升级版本至 1.3.2 Tomcat 升级版本至 9.0.37 使用 Github Action 进行CI 移除默认的 Maven Profile 配置 详细参考：https://github.com/sofastack/sofa-boot/releases/tag/v3.6.0\nSOFATracer 项目进展 本周发布详情如下：\n1、SOFATracer 发布 v3.1.0 版本，主要变更如下：\n 修复 flexible result.code 返回成功、失败 code 码 修复 DubboSofaTracerFilter Server span tag value error 修复 SofaTracerFeignClient 中 UnsupportedOperationException 问题 优化 spring mvc filter 的 error tag 支持 kafka 支持 RabbitMQ 支持 oracle rac JDBC URL 支持 hikari 详细参考： https://github.com/sofastack/sofa-tracer/releases/tag/v3.1.0\n","date":1612508400,"description":"SOFA WEEKLY | MOSN、SOFABoot、SOFATracer 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210205/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4cde1d3e68e2e13cbca7278164a4ab12","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210205/","publishdate":"2021-02-05T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210205/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、SOFABoot、SOFATracer 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210205/","wordcount":1518},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@潘麒安 提问：\n 请教下 session-server 报这个错，是需要扩更多的 session 么，但是 session进程本身 CPU 和内存占用不高。 A：看错误是把 session 发向 data 的处理队列打满了，可以排查一下，检查一下使用的版本，data 的资源使用和common-error.log 下的错误日志。\n SOFARegistry：https://github.com/sofastack/sofa-registry\n@刘达 提问：\n MOSN 怎么配置监听一个端口，这个端口上会接受有多种协议的数据，根据协议转发到不同的集群地址。ISTIO+MOSN， 用户 http 请求 gateway，通过 gateway 调 dubbo，每个应用自动注入 sidecar，测试没跑起来。 A：配置 Auto，支持协议自动识别，转发不同的集群，那就看路由了；用新版本，然后这样配置。 MOSN：https://github.com/mosn/mosn\n本周推荐阅读 剖析 | 详谈 SOFABoot 模块化原理\n 网商银行是如何建设金融级云原生分布式架构的？\n 实操 | 基于 SOFABoot 进行模块化开发\n 开源 | SOFABoot 类隔离原理剖析\n SOFABolt 项目进展 本周发布详情如下：\n1、SOFABolt 发布 v1.5.7 版本，主要变更如下：\n 优化 log4j2 日志配置，解决在异常场景下的性能问题 详细参考：https://github.com/sofastack/sofa-bolt/releases/tag/v1.5.7\nsofa-common-tools 项目进展 本周发布详情如下：\n1、sofa-common-tools 发布 v1.3.2 版本，主要变更如下：\n 修复 LogCode2Description 性能问题 详细参考：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.2\n","date":1611903600,"description":"SOFA WEEKLY | SOFABolt、 sofa-common-tools 发布新版本，QA 整理","dir":"blog/sofa-weekly-20210129/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4f4f43ac764d4c99010c408e4d53c92e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210129/","publishdate":"2021-01-29T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt、 sofa-common-tools 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210129/","wordcount":934},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@叶毅威 提问：\n 请教下 SOFARegistry 数据持久化在哪里啊?\n A：SOFARegistry 的元数据（注册中心自身的 IP 列表之类的数据）存储在 meta 角色内，使用 JRaft 进行存储。 应用的发布数据保存在 data 角色的内存中，采用三副本（可配置）的方式实现高可用。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n@叶毅威 提问：\n 我用 SDK 调用注册了一个 datainfo 但是关掉之后 这个并没有下线，是哪里需要配置么，不是默认链接断开就下线么？\n A：session 上采用 HTTP 方式获取的数据都是当前节点的注册数据，只有 data 上才会做数据聚合。 dataInfo 是不会被删除的，连接断开后对应 dataInfo 下的对应 Publisher 会被自动移除。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n@田冲 提问：\n 现象：canal 监听到某个被分布式事务控制的表的 insert-binlog 日志后再去查询 MySQL 表里数据时发现这条数据不存在，延迟1秒钟左右再查询就能查询到。 疑问：seata-at 模式-两阶段提交的设计会出现 MySQL 先生成了 binlog 日志，后提交事务的情况吗？\n A：这个问题其实很简单，你 canal 读不到，那你自己应用本地事务提交后马上读这个 insert 的数据看能不能读到；如果读到，理论上来说这个过程不可能超过一秒，所以如果你应用能查到，你canal查不到，排查canal的问题，而不是 Seata 的问题；Seata 最后也只不过做了 connection.commit；最后事务的提交落库是数据库方本地事务流程落库，Seata 不会起到任何干扰，Seata 代理的是 jdbc 层的处理；redo 后写 binlog 时马上就会广播的，而不是事务提交才把 binlog 广播出去；所以内 xa 的二阶段没提交你就去查主库，由于隔离级别不一定查得到。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Kubernetes 是下一代操作系统 | 面向 Kubernetes 编程\n 蚂蚁集团生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理\n 蚂蚁集团服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析\n 开箱即用的 Java Kubernetes Operator 运行时\n ","date":1611298800,"description":"SOFA WEEKLY | QA 整理","dir":"blog/sofa-weekly-20210122/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"16aa2c7282629fe75b244cdce08845e7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210122/","publishdate":"2021-01-22T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210122/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210122/","wordcount":1098},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@吴小彬 提问：\n 请教下，如果分支事务中使用了分库分表中间件（shardingsphere-proxy、mycat 等），Seata-AT 模式是不是不能用的？是只可以用 TCC 模式吗？现在的 shardingsphereProxy 中间件（不是 shardingsphereJdbc ）用 AT 模式，它对微服务来说就是一个 MySQL 连接，它是怎么知道微服务调用链中的 xid 的？\n A：可以用，shardingsphere 4.1 支持 Seata AT， proxy 我估摸着有点悬，因为他属于一个代理层。Jdbc 是直接在应用的 Jdbc 层提供服务的，所以 AT 可以很好的支持。\n@谭玖朋 提问：\n 在关于 AT 模式，第一阶段执行完后生成行锁然后注册分支事务，其中的行锁具体是指什么锁呢？因为发现第一阶段执行完后，其实再查数据的话是已经改变了。所以关于这个行锁这么解释？\n A：Select for update 的时候，首先 Seata 会代理这个语句，去查询 TC 这个行有没有锁住，如果没锁住，客户端业务用了 for update 那么就拿到了本地锁，此时因为本地锁排他，这个时候没有全局锁的 for update 就是分布式下的读已提交。 不是允许脏读，是读已提交。读未提交是默认的，所以只有在你 update 的时候（update 是当前读），但是如果你的 update 是基于快照度的 select 结果，可能会出现事与愿违的结果，如果你要基于某个数据来 update，要么 for update 来读分布式下的已提交，要么就用 update x=x-1 之类的写法，因为提交时会抢占全局锁，没抢到会 rollback，释放当前锁进行重试，这样就能保证抢到锁的时候，update 的数据当前读是分布式下的读已提交并修改 目前好像没人写关于 AT 行锁及全局锁部分源码有分析讲解的资料，如果感兴趣可以去阅读一下，写出来投稿给我们。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Mecha：将 Mesh 进行到底 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 Service Mesh 和 API Gateway 关系深度探讨 Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍 Occlum 项目进展 Occlum 发布 v0.19.1 版本，主要变更如下：\ni.同时兼容 Glibc 和 musl libc的应用\nii. 支持基于 DCAP (Intel SGX Data Center Attestation Primitives) 的远程验证\niii. 修复了内存泄漏问题\n详细发布报告： https://github.com/occlum/occlum/releases/tag/0.19.1\n","date":1610694000,"description":"SOFA WEEKLY | Occlum 发布新版本，Seata QA 整理","dir":"blog/sofa-weekly-20210115/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"48d18f44f20f4b6d5f8b219e383bfa51","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210115/","publishdate":"2021-01-15T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210115/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | Occlum 发布新版本，Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210115/","wordcount":1106},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFAStack 社区本周 Contributor 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题\n通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@王家爵 提问：\n SOFABoot 项目要一两分钟才能启动，目前这边有监控工具可以看到启动过程中各个步骤的耗时吗？\n A：3.6.0 之后可以通过 actuator/startup 查看启动的耗时分布。\n「SOFABoot」：https://github.com/sofastack/sofa-boot\n@东仔 提问：\n SOFABolt 的最新分支是哪个？\n A：master 就是最新分支。https://github.com/sofastack/sofa-bolt\n「SOFABolt」：https://github.com/sofastack/sofa-bolt\n我是一个小胖子 提问：\n 请问现在已经支持自适应限流了吗？\n A：开源版本里有基于 sentinel 的自适应限流，这个你可以看看 sentinel-golang 的文档，但是和我们内部用的自适应限流有一些差异。\n 你们内部不用 sentinel 是吗？\n A：也用，我们基于 sentinel 做了一些扩展。\n「MOSN」：https://github.com/mosn/mosn\n来永国 提问：\n 为什么我起了 RPC 服务端客户端和注册中心，然后连接调用是可以的，然后我把注册中心关了，它还是跑得通？\n A：client 会有缓存的。\n 获取注册中心的服务有 API 接口吗?\n A：有的，有个从单机 session 获取数据的接口 curl localhost:9603/digest/pub/data/query?dataInfoId=com.test.SimpleService#@#DEFAULT_INSTANCE_ID#@#DEFAULT_GROUP dataInfoId 参数需要进行 url encode 应该还没公开的 API 文档，获取数据的 HTTP 接口也不太易用，我最近会补一下文档还有方便使用的接口。\n 那看样子这个相当于是指定搜索了吗？\n A：是的，目前没有模糊查询的接口， curl localhost:9603/digest/getDataInfoIdList 你可以用这个 API grep 一下。\n「SOFARegistry」：https://github.com/sofastack/sofa-registry\nSOFAStack\u0026amp;amp;MOSN:新手任务计划 作为技术同学，你是否有过“想参与某个开源项目的开发、但是不知道从何下手”的感觉？\n为了帮助大家更好的参与开源项目，SOFAStack 和 MOSN 社区会定期发布适合新手的新手开发任务，帮助大家 learning by doing!\nLayotto\n Easy 为 actuator 模块添加单元测试\n为 Java SDK 新增分布式锁、分布式自增 ID API\n开发 in-memory 组件\n Medium 让 Layotto 支持 Dapr API\n开发 Rust、Python、SDK\n「详细参考」：\nhttps://github.com/mosn/layotto/issues/108#issuecomment-872779356\nSOFARPC\n Easy 优化 SOFARPC 使用文档\n Medium 优化 SOFARPC 的异步编程体验\n「详细参考」：\nhttps://github.com/sofastack/sofa-rpc/issues/1127\n本周推荐阅读 服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书\n一行降低 100000kg 碳排放量的代码\n深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进\n「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\n","date":1610607600,"description":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","dir":"blog/sofa-weekly-20220114/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7e0323f9034710384e38cbb6f2176adf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220114/","publishdate":"2021-01-14T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20220114/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack)是蚂蚁集团自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly |社区开发者的搬砖日常、本周 Contributor、QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20220114/","wordcount":1222},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@梁俊 提问：\n 有一台物理服务器，没有安装 OS，是不是可以把 Occlum LibOS 像通用操作系统一样当做 host OS 用，运行 Occlum LibOS，需不需要在物理服务器上安装 host OS?\n A：Occlum 对硬件也是有要求的。这个机器需要支持 Intel SGX 技术。简单得说，就是必须可以安装 SGX 驱动。 Guest OS 是虚拟机的概念，从 guest OS 的角度看，OS 依然运行在 kernel 态。简单来说，如果想使用 Occlum，那么建议方案： 1 . 找一台 SGX 机器 （比如 W55）； 2. 安装一个OS，并且装上 SGX 驱动； 3. 安装 Occlum；\n Occlum 相对于 Docker 有哪些优势，比 Docker 快吗?\n A：Occlum 的优势是安全。外界无法探测运行在 Occlum 中的程序和这个程序使用的内存以及寄存器。也就是说，可以把机密信息（比如密钥）放在 Occlum 中而不用担心信息泄露。\nOcclum：https://github.com/occlum/occlum\n2、@李天宇 提问：\n 可不可以定义一个这样的准则每个 RPC 后面，必须得有一个 TM，每个 TM 维护一个 TM 块，RPC +1，就应该等于 TM 块？ A：这样一个完整的链路有多少个参与者，发起者可以获得，校验规则就是 spanid 是否与参与者数量 +1，是否相等？认为 RPC 向下的服务资源都是一个完整的事务，不管它是否与 db 交互，即可以无 RM ，我的想法就是让 TM 发起者，可以随着链路信息感知所有的 TM。 Tm 可以在每个微服务上都标注下 注解，默认是加入到之前的事务中。TraceId 可以塞到 Seata 的协议中传递到 RPC 下游。\n3、@李天宇 提问：\n 支持不同 branch 不同的 type 吗？\n A：AT 和 TCC 可以共存，Saga 不行。比如 a 数据在 AT 下被改，又被 Saga 或者 xa 分支改动，因为它们不是 AT 无法通过全局锁保证隔离性，除非所有的模式只要内部含有 AT 分支，都去获取全局锁，这样带来了一个问题，如何提前知晓某个 TM 的调用链路中有 AT 分支，靠用户注解上写，那入侵性就有点大了。\nSeata：https://github.com/seata/seata\n本周推荐阅读 SOFAEnclave：蚂蚁机密计算如何解决现实挑战？ 蚂蚁集团宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 开源项目是如何让这个世界更安全的？ 网商银行是如何建设金融级云原生分布式架构的？ MOSN 项目进展 本周发布详情如下：\n1、MOSN 发布 v0.20.0 版本，主要变更如下：\n 路由模块进行了优化与重构，支持变量机制与可配置的扩展模式 使用的 Go 版本升级到了 1.14.13 支持 XDS 非持久化模式下配置的热升级 完善支持了 Netpoll 模式 其他一些新功能、优化与 Bug Fix 详细参考：https://github.com/mosn/mosn/releases/tag/v0.20.0\n","date":1610089200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20210108/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"86ee4a89adc2c475c6f406d2774743c8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210108/","publishdate":"2021-01-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20210108/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20210108/","wordcount":1294},{"author":"小蚂蚁","categories":"SOFAStack","content":" Forrester 认为：\n包括容器、微服务与服务网格等领域在内的云原生平台，将成为构建适应未来的现代企业的核心引擎。\n在常态化混合异构环境下，面对云原生应用路径的多样化趋势与全维度挑战，企业必须将服务网格技术与微服务有效结合，才能真正释放云原生技术的红利。\n近几年云计算发展如火如荼，异构变革日新月异，这是基础设施层明确的发展趋势。值得关注的是，随着基础设施的复杂度越来越高，也为整个基础设施的统一资源调度带来了极大挑战。\n在越来越复杂的异构基础设施上，存量应用和增量应用应该如何上云？面对大量异构基础设施带来的挑战，企业如何最大化上云价值？\n服务网格（SOFAStack Mesh）是蚂蚁集团自主研发的基于金融级生产实践的增强版服务网格平台，将传统微服务和 Service Mesh 技术进行了深度融合，其核心技术经过了蚂蚁集团的大规模生产实践验证。\n它深度、无缝对接了 SOFAStack 经典应用服务和容器应用服务，为客户提供了简单易用的 Service Mesh 架构的支撑平台。目前， 服务网格已经广泛应用在大型金融机构。\n近日，蚂蚁集团联合 Forrester 公司发布了《蚂蚁集团服务网格总体经济影响》（以下简称白皮书）。\n白皮书基于蚂蚁集团云原生分布式架构 SOFAStack，结合客户使用的成本节省情况和业务收益，为企业上云提供新的路径方法与参考实践。\n白皮书首先系统地分析了全球企业在资产现代化、数字化等市场趋势下面临的风险与挑战，面对挑战。Forrester 提出适应未来 (Future Fit) 的技术战略模型。\n即以客户为中心，帮助企业快速重构业务结构和能力，调整运营方式，以自适应性、创造力和韧性满足未来客户和员工的需求。而平台、实践与合作伙伴将成为构建这一技术战略的关键因素。\nForrester 认为，包括容器、微服务与服务网格等领域在内的云原生平台将成为构建适应未来的现代企业的核心引擎。\nForrester 在报告中指出，在常态化混合异构环境下，面对云原生采用路径的多样化趋势与全维度挑战，企业必须将服务网格技术与微服务有效结合，才能真正释放云原生技术的红利。\n具体而言，企业技术决策者与实践者应当积极拥抱服务网格技术，并致力于在以下四个方面实现异构分布式环境下的策略化、平台化赋能：可观测性、微服务治理、灰度发布与部署、微服务框架可管理性。\n 可观测性 通过服务网格，Sidecar 代理可以主动观测相关微服务的调用关系，并将链路信息进行统一日志记录。而企业级的服务网格监控工具，应当可以对服务网格产生的遥测数据进行分析与关联。为企业开发与运维团队提供可视化的链路拓扑、实时的监控报告、基于策略的告警，以及分布式追踪与故障定位能力。\n 微服务治理微服务 主要治理能力还包括服务发现、流量治理、安全通信和应用弹性伸缩。服务网格通过基于策略的运行状况检查、动态路由、自动重试、服务熔断、服务降级、服务限流等机制提升微服务运行时的可配置性与健壮性，从而显著简化异构环境下微服务治理的技术复杂性。\n 灰度发布与部署 服务网格提供对调用方与服务方透明的灰度代理开启机制和有效的回滚机制，从而实现一体化、精细化与智能化的灰度发布与部署能力。在保障业务连续性与客户体验稳定性的同时，加速客户价值交付。\n 微服务框架可管理性 借助服务网格，企业能够将服务治理能力从各类异构的微服务框架下沉到服务网格所在的基础设施层面。而微服务框架自身只需要聚焦业务核心实现和语言差异性，从而实现微服务框架在服务治理层面的轻量化。\n面对技术发展和市场需求，蚂蚁集团在近十多年五代架构的演进过程中，经过充分的迭代和验证，逐渐沉淀出了一套金融级分布式架构 SOFAStack。\n其中的服务网格产品 SOFA Mesh 是基于 Istio 开源项目研发的企业级云原生网络通信方案，为分布式应用提供流量管理、安全加密、可观察性、服务治理等能力，实现灰度发布、蓝绿部署、滚动升级，助力企业数字化转型。\n蚂蚁集团数字科技事业部产品总监马振雄认为，相比于其他上云方式，Service Mesh 能够实现跨平台、跨协议，并且业务代码无侵入改造。从而快速地将应用植入 Sidecar 完成 Mesh 化，获得分布式红利、安全可观测，并且整个架构平滑演进。企业在架构升级过程中可以按部就班、循序渐进，并且实现端到端的安全可信以及全链路可观测能力。\n蚂蚁集团客户的访谈提到，Forrester 发现无论是传统金融机构还是互联网金融机构，都面临在混合架构下存在的共性挑战，包括基础设施升级换代、应用开发升级、云上云下交互等方方面面。\nForrester 表示，对于金融机构而言，网格服务在单体应用改造成本、云原生环境开发人员效率提升、运维安全管理效率提升以及替代旧有系统等方面能实现明显的降本增效。通过研究三年数据测算，使用蚂蚁服务网格产品后，其客户的投资回报率达到 99%。\n以某资产总额超一万亿的省级农信为例。\n随着金融科技的迅速发展，该银行积极加速数字化转型。在转型过程中，遇到了异构系统难以统一治理，技术栈绑定等一系列问题。蚂蚁集团 SOFA Mesh 帮助该用户：\n构建全行级通信网络，异构系统服务治理， 低成本云原生落地，实现无侵入平滑上云，无需修改业务代码，无需考虑依赖关系；\n同时支持架构灵活演进，兼容 ESB 等传统异构系统，帮助客户最大化上云价值。\n此外，SOFA Mesh 还能够实现以下重要的非量化重要收益：\n 统一监控能力 SOFA Mesh 能够实现传统技术栈和云原生环境的统一监控，提升问题定位效率。\n 精准故障定位 对于已完成了微服务化改造的服务云原生环境来说，服务网格提供了强大的流量管控能力，通过调用链精准定位故障。\n 故障复盘资源消耗节省 对于监管要求极高的金融企业，在故障出现后要进行全面复盘，以确保系统未来的可用性，避免类似事故发生。但复盘也消耗大量开发运维人员的时间，对工作效率产生影响。\n 组件能力提升 解耦后的微服务的公共组件、业务组件、及安全组件都得以实现性能上的提升。\n未来，蚂蚁集团希望和更多合作伙伴一起，借助 SOFAStack 以及服务网格的成功实践经验，让更多企业用户低成本上云，迈向数字化云原生的新时代。\nSOFAStack 社区为了能提供更好更优质的内容来满足大家的需求、口味\n特别设计了本次的问卷，大概占用您 2 分钟的时间～\n我们会选取 5 份认真回答的问卷送出SOFAStack 社区的 2022 限量新年礼物\n快扫描二维码一起写问卷吧～\nhttps://www.wjx.cn/vj/rXjIC9b.aspx\n本周推荐阅读 「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践\nService Mesh 在中国工商银行的探索与实践\nService Mesh 双十一后的探索和思考(上)\nService Mesh 双十一后的探索和思考(下)\n","date":1609743600,"description":"服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书","dir":"blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9fdc287491ed68fe45196c70d88a67c9","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","publishdate":"2021-01-04T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","summary":"Forrester 认为： 包括容器、微服务与服务网格等领域在内的云原生平台，将成为构建适应未来的现代企业的核心引擎。 在常态化混合异构环境下，面对云原生应用路径","tags":["SOFAStack"],"title":"服务网格定义企业上云新路径！ | Forrester X 蚂蚁集团 发布服务网格白皮书","type":"blog","url":"/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/","wordcount":2531},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News  SOFA 社群元旦快乐！新的一年我们也要在一起哦！\n同时，也有一个好消息要和大家共享： MOSN 荣获 「2020 年中国优秀开源项目」，感谢所有开发者们的支持和喜爱，MOSN 团队会继续努力，提供更好的开源产品和服务，也期待大家的持续共建。\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@苏榴结 提问：\n 对于某个全局事务来说，向 tc 注册说你是 tm 也是 rm，但因为这个全局事务已经有了 tm，所以它就会被认定为rm 是吗？\n A :服务起来的时候就跟 TC 说了你可以做 TM ，也可以做 RM (分别建立一个长连接与 TC 通信)，然后在需要进行某个全局事务的时候，如果他是发起全局事务的那个，那么他就发挥了他 TM 那部分职能，如果他是负责操作数据库，那他就发挥了 RM 那部分的职能。\n2、@刘亚飞 提问：\n 为什么图 1 中描述用协程池来处理可读 conn，图 2 中，又说每一个 conn 有一个读协程呢？是因为图 1 描述的是 rawpoll 模型下的代码方式，而图 2 是 goroutine-per-connection 模式下的一个 write goroutine 池化吗？\n 图1\n图2\nA：图 1 图 2 属于两种模型。Rawpoll 模型的话就是自己做 epoll_wait，有可读事件从协程池拿一个协程来读取数据；协程模型的话就是一个连接一个协程，标准的 go 编码模式，runtime 来处理 epoll_wait，可配置选择不同模式。\n本周推荐阅读 云原生网络代理 MOSN 的进化之路 基于 MOSN 和 Istio Service Mesh 的服务治理实践 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 SOFA项目进展 本周发布详情如下：\n1、SOFA-Common-Tools 发布 1.3.1 版本：\n 修复多 classloader 场景下 commons-logging 的兼容性 修复 SOFAThreadPoolExecutor 被删除的方法，提高向下兼容性 详细参考: https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.1\n2、SOFA-Ark 发布 1.1.6 版本：\n 支持插件扩展，通过宿主动态扩展指定 plugin 依赖和导出关系 SOFA-Ark-manve-plugin 支持打包按规则排除依赖（from file） 详细参考： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.6\n","date":1609398000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201231/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ca60ed7c9ac011477c8861c0f5650629","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201231/","publishdate":"2020-12-31T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201231/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA 社区元旦快乐，MOSN 荣获 2020 中国优秀开源项目","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201231/","wordcount":994},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@薛帅领 提问：\n 多数据源切换后，增加事务但不起作用（切数据源是执行方法后才切换的），本地事务及 Seate 分布式事务也不行，这个有什么好的解决方案吗？\n A：Spring 本地事务注解本身就不支持多数据源事务，且如果你开启了本地事务，之后并不会进入你的切换数据源的切面。 在多数据源下，去掉本地事务注解就好了。用 globaltransactional 注解在多数据源的入口加上，多个数据源都被 Seata 代理的话，就会保证多数据源的事务。\n2、@李天宇 提问\n 如果在分布式事务中，另一个线程做批处理 update 之类的，是否会锁住呢?\n A：不会，另一个线程也要记得加上 globaltransactional 注解就行了。在 a 线程要提交之前要去尝试拿到它修改数据的全局锁的，如果 a 拿到了，但是还没到二阶段提交，b 也是要去尝试拿，拿不到就会不执行 SQL，等待全局锁释放了，也就是 a 发起的事务结束了，b 才能执行 SQL 提交。这样就保证了利用全局锁（粒度行级），来达到隔离性。\nSeata：https://github.com/seata/seata\n相关推荐阅读 Kubernetes: 微内核的分布式操作系统 走出微服务误区：避免从单体到分布式单体\n 网商银行是如何建设金融级云原生分布式架构的？\n 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构\n SOFA 项目进展 本周发布详情如下：\nSOFA-Common-Tools 发布1.3.0 版本，主要变更如下：\n SOFA 线程池支持 ScheduledThreadPoolExecutor 与 ThreadPoolTaskScheduler 新增 SofaConfigs 支持统一的配置获取 新增 LogCode2Description 支持统一的错误码获取 重构线程池实现，支持更丰富的监控数据 所有组件统一 spce 属性获取逻辑 修复配置日志输出到控制台时不生效的问题 详细参考：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.3.0\n祝大家圣诞节快乐！\n","date":1608879600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201225/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"59bc2ae2a6b06f7ca356aeb61a6c78fd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201225/","publishdate":"2020-12-25T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201225/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFA-Common-Tools 发布新版本， QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201225/","wordcount":963},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@缪文 提问:\n SOFA-Boot 框架，模块隔离时，子 module 中引入 mybatis 框架，@MapperScan 注解是在RootContext 中扫描，还是在子 module 中扫描？\n A: 非 auto 的 configuration 都是在对应模块进行解析的。\nSOFABoot：https://github.com/sofastack/sofa-boot\n2、@李扬 提问：\n 分支事务被回滚是同步还是异步的,如果是异步的,能加监听方法吗?\n A：可以实现 transactionhook 这个类，然后在 tm 发起者里加入到 Transaction HookManager#registerHook 。这样在二阶段决议后，可以做一些小动作，比如二阶段提交的时候，再执行 redis ，mongo 的数据插入。\n3、@吴国柱 提问：\n 本地事务与全局事务一起开启会有问题吗？\n A：全局事务要在本地事务的外层,就是包裹本地事务，不能由本地事务包裹全局事务。本地事务出异常都不会进行注册，也就代表本地事务如果出问题本地事务自行会回滚(基础知识)，如果本地事务提交了，其它服务的本地事务出现异常，或者业务代码出现异常，将有 Seata来负责把已提交的事务回滚。\nSeata：https://github.com/seata/seata\nSOFAChannel 部分合辑 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 蚂蚁集团分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁集团分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 相关推荐阅读 剖析 | 详谈 SOFABoot 模块化原理 蚂蚁集团研发框架日志隔离解析 | SOFABoot 框架剖析 蚂蚁集团研发框架总览 | SOFABoot 框架剖析 ","date":1608274800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201218/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"712d560758c60f16cc7d2651bb781e65","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201218/","publishdate":"2020-12-18T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201218/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 线上直播合辑整理，QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201218/","wordcount":949},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 【12/07 - 12/11】每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@bruce 提问：\n SOFAJRaft 可以实现在三个节点中选出一个 leader , 其他逻辑由自己实现吗?\n A：可以，可以不用状态机，也不用加载和持久化快照, 只需要选个 leader。 \u0026amp;gt; 各个节点如何知道自己是主还是从?\nA：示例 2、@李明 提问:\n 全局事务执行过程中，有其他线程操作数据库，这时全局事务执行失败，在回滚的时校验数据发现数据被修改过，导致回滚失败，这种情况怎么避免?\n A：其他线程也加上 global transactional 注解。分布式事务下，没有单个分支是独立的个体存在，需要拿到全局事务中，让其他事务知晓他的存在，从而避免在分布式调用链路中，恰好遇到同一个数据进行修改时，发生的脏写脏读 globallock 是在更新前去 tc 看下这个时候这个数据有没有被其他事务锁定，没有的话就说明这个数据没有被其他事务使用，是提交的数据，所以这叫读分布式事务下的已提交。 但是他并没有去注册分支，也就是他没有去占有这个全局锁，来达到分布式事务下的排他性。他在得到 tc 响应的时候，去执行 update 是有时间的，此时有个分布式事务下的分支 update 后，拿到了全局锁，然后他的链路二阶段是回滚 ，但是数据就被你这个认为没有全局锁的本地线程给改了，这就导致被干扰无法回滚。 所以 globallock 需要配合 sql 语句，在 update 前，先做 for update 这个数据，拿到这个数据的本地锁，拿到本地锁之后，再去 tc 判断有没有全局锁，如果 tc 没有锁，因为本地已经拿到本地锁了，具有本地事务的排他性，其他分支事务拿不到该数据的本地锁，是无法去注册分支去拿到全局锁，也就是禁止了其他分支事务的干扰，所以不会脏写。 目前 tcc 下一般就是 globallock+select for update 来防止被其他 at 事务改动后，进行了脏写。\n3、@ 尚攀 提问:\n Raft 是为了解决目前的什么问题？\n A: 依赖外部存储。AT 有 before 镜像、after 镜像，after 镜像是在 undo_log 表里存储，那么 before 在哪里存着了？未来的 Raft 模式，集群支持动态扩缩容，事务信息存储在内存中（测试下来比 redis 快），现在的全局事务信息，分支事务信息，全局锁都是持久化到 db，或者 redis 去的。如果这个时候持久化用的 db 宕机了，Seata-Server会不可用，而集成了 Raft ，leader 宕机后自动选举新 leader，继续运转。所以，利用 raft 一致性算法，可以让多个Seata集群内存中的数据保持一致。\n相关推荐阅读 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑\n 蚂蚁集团生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理\n 蚂蚁集团 SOFAJRaft 优先级选举剖析 | 特性解析\n 剖析 | 蚂蚁集团生产级 Raft 算法 SOFAJRaft 合辑\n Seata 项目进展 本周发布详情如下： 发布 Seata 1.4.0 版本，主要变更如下：\n 支持 yml 配置文件 支持 Oracle nclob 类型 支持客户端最少的活动负载均衡 支持客户端一致性哈希的负载均衡 支持 Spring Boot 使用自定义配置中心和注册中心 支持配置默认全局事务超时时间 多处 BUG 修复和功能优化 详细参考：https://github.com/seata/seata/releases/tag/v1.4.0\n","date":1607670000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201211/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dc10639aea7c443d918ac8f8355ed64c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201211/","publishdate":"2020-12-11T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201211/","summary":"SOFA WEEKLY | 【12/07 - 12/11】每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是","tags":["SOFA Weekly"],"title":"SOFA Weekly | Seata 发布新版本， QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201211/","wordcount":1418},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\n SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@刘江涛 提问： \u0026amp;gt; 已知在同一个分布式事务中，各个 RM 的模式都应该与对应 TM 模式相同。那同一个微服务可以多种模式并存吗？比如 AT , XA , Saga 并存，然后 A 业务使用 AT 模式，B 业务使用其他模式之类的。\nA：不可以，隔离性无法得到保证。如果要一起用，就要保证一条调用链路中所有数据的隔离性，也就是跟 AT 一样都得去竞争锁，而且 Saga，TCC 之类的对 SQL 没要求，可能在跟 AT 一起使用的时候就有要求了，得不偿失。\n 如果公司要引入多种模式的话，微服务之间的关系是这样的吗？\n A ：是的，当然 AT 集群是可以调 Saga 集群的，但是他们不能属于同一个全局事务,也就是 AT 那个事务提交了，Saga 的如果回滚了，是 Saga 集群的问题，等于有 2 个全局事务的诞生。 Seata：https://github.com/seata/seata\n相关推荐阅读 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化\n 云原生网络代理 MOSN 透明劫持技术解读 | 开源\n 基于 MOSN 和 Istio Service Mesh 的服务治理实践\n 云原生网络代理 MOSN 的进化之路\n MOSN 项目进展 本周发布详情如下： 1、MOSN 发布了 v0.19.0 版本： - 重构了 StreamFilter 框架，提供更强的可复用的能力 - 支持 MaxProcs 可基于 CPU 使用限制自动识别的能力 - 支持指定 Istio cluster 的网络 - 针对高并发场景的内存使用进行了优化 - 多处BUG修复\n详细参考：https://github.com/mosn/mosn/releases/tag/v0.19.0\n","date":1607065200,"description":"SOFA WEEKLY | 【11/30 - 12/04】每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201204/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4123f0805fdf3799cbafcc143f8d6bac","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201204/","publishdate":"2020-12-04T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201204/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布新版本、 Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201204/","wordcount":843},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech\n SOFAStack：https://github.com/sofastack\n 社区 Big News  SOFAStack 获得 2020 年度 OSC 中国开源项目评选「优秀 Gitee 组织」，感谢所有开发者们的支持和喜爱，SOFA 团队会继续努力，提供更好的开源产品和服务，也期待大家的持续共建。 2020 年度 OSC 中国开源项目评选结果公布\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张松 提问： \u0026amp;gt; SOFARPC 支持提供者注册的时候配置一个标识，然后消费者根据这个标识来获取到对应的服务提供者吗？类似于对服务提供者做一个分组。\nA：你是指 SOFARPC 的 unique-id 吧，支持的。 \u0026amp;gt; 不是，类似于分组的配置，因为我这边现在需要多环境，要来区分同一个注册中心下的同一个接口的不同分组。\nA：SOFARPC 就是用 uniqueId 来区分同一个接口，不同实现的。SOFARPC 没有 group 的概念，只有一个 uniqueId，需要服务方和调用方配置一样，强隔离的。 SOFARPC：https://github.com/sofastack/sofa-rpc\n2、@徐泽唯 提问： \u0026amp;gt; 自动降级以后如果调用的服务抛错了 数据是不是就不对了？\nA：自动降级只是发起者那边发现 SeataServer 不可用后，不去走 begin 。你业务数据就完全没全局事务的允许运行，是会出现数据不一致。比如seata-server宕机了，后续的服务因为 Seata-Server 宕机，不走分布式事务，此时全局事务有部分数据是需要回滚的，但是由于Seata-Server宕机了，导致没法回滚，这个时候不经过全局事务的事务执行就会导致数据不一致。所以说，tc 最好集群搭建，以免宕机后，降级代表了你允许 at 模式下数据不一致。 Seata：https://github.com/seata/seata\n相关推荐阅读 蚂蚁金服微服务实践 | 开源中国年终盛典分享实录 火了 2 年的服务网格究竟给微服务带来了什么？ 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下： 1、SOFAJRaft 发布了 1.3.5 版本： - 增加对IPv6的支持＃526 ＃527 - 升级\u0026amp;rsquo;rocksdb\u0026amp;rsquo;到5.18.4以支持AArch64\n- 优化：心跳响应不经过管道直接发送，避免管道影响心跳响应的及时性 详细参考：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.5 2、SOFABoot 发布 3.4.6 版本: - 支持手动 readiness 回调（健康检查二阶段） - 扩展点失败反馈健康检查，默认为否 - 提供上下文隔离场景下获取所有 Spring 上下文的标准方法 - Bean 加载时间和层级树形分层显示\n详细参考：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.6\n","date":1606460400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201127/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f379c4483cff2807f5cfe8c6bbab5d8c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201127/","publishdate":"2020-11-27T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201127/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/23 - 11/27】SOFA Weekly | SOFAJRaft 、SOFABoot发布新版本，SOFAStack 获优秀 Gitee 组织奖","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201127/","wordcount":1352},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech\n SOFAStack：https://github.com/sofastack\n 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@小刘 提问： \u0026amp;gt; 刚开始用 Seata ，方法上用了 @GlobalTrasactional + mybatis 插入一条数据的时候返回的自增id不正确,取消@GlobalTrasactional用普通的事务@Trasactiona 插入数据的时候返回的自增 id 正常了。\nA: 这个基础是有问题的。全局锁的作用是锁定并发修改时的数据的，不是针对接口。接口并发肯定是多线程走的，不可能阻塞等待排队。 Seata：https://github.com/seata/seata\n2、@初识 提问： \u0026amp;gt; 防悬挂是怎么理解的？能简单说说吗？\nA: 保证一致性，幂等用的。比如a-\u0026amp;gt;b，因为特殊原因，比如全局事务超时，b注册上了分支事务，本地事务的 commit 还没执行的时候，全局事务回滚下发到了，如果这个时候本地事务 commit 了，那么数据就不一致了，所以全局事务回滚下发到了，会插入一个 undolog ，让本地事务 commit 的时候因为 undolog 唯一索引冲突使本地事务提交失败，触发回滚，保证了当全局事务状态是回滚时，分支事务都是回滚的。 当然，如果是 commit 了，再收到下发回滚，因为 commit 了已经有 undolog了，那么会通过 undolog 回滚，这个针对的是没有 undolog 时的情况。\n**3、@StevenCheney **提问： \u0026amp;gt; Nmosn 的版本 和 Istio 有对应关系吗？\nA：目前的 Master 支持 1.5._，但是上次看1.5._的时候有一些注入的问题，你可以看一下 feature-istio_adapter 这个分支，最近应该会合并一些pr进来，到时候可以直接适配1.7._，理论上1.6._也是可以支持的，需要测试一下。 \u0026amp;gt; Docker image 会同步更新吗？\nA：主要是看你的需求，如果你是只要 MOSN ，不要 Envoy，就直接使用https://github.com/istio/istio/issues/23753 这个来打包，如果你都需要的话或者说不介意多一个 Envoy，就直接使用 proxyv2 打一个就好了。 MOSN：https://github.com/mosn/mosn\n本周推荐阅读 蚂蚁智能运维：单指标异常检测算法初探 蚂蚁宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 企业数字化转型指南，《SOFAStack 解决方案白皮书》正式发布 SOFA 项目进展** 本周发布详情如下： 1、SOFA-Common-Tools 发布1.2.1版本：\n 重构了本地控制台输出日志逻辑； 移除了 log-sofa-boot-starter 相关代码； 详细参考： https://github.com/sofastack/sofa-common-tools/releases/tag/v1.2.1\n","date":1605855600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201120/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a81d6649eb11649a90e54eef8a5a57e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201120/","publishdate":"2020-11-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201120/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/16 - 11/20】SOFA-Common-Tools 项目发布新版本、Seata、MOSN 相关 QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201120/","wordcount":1234},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@杨文鹏 提问：\n 感觉 SOFAArk 在静态合并部署情况下,和 SOFABoot 的类隔离起到的作用是一样的？不知道我理解对不对。\n A：SOFABoot 没类隔离，它的类隔离就是继续 SOFAArk。 \u0026amp;gt; 比如新建一个 SOFABoot 应用，需要再手动集成 SOFAArk 吗？\nA：需要的。\n SOFABoot：https://github.com/sofastack/sofa-boot SOFAArk：https://github.com/sofastack/sofa-ark 2、@倪绍东 提问：\n 如果是提交阶段有数据库失败了，其他成功的怎么办呢，没办法了吧？\n A：一阶段提交,二阶段不可能提交的情况下还失败，XA 本地事务一阶段持久化在数据库层面不可能丢失，本地事务undolog跟redolog了解一下。对 Seata-server 来说保存了事务状态，如果二阶段有节点执行失败，就重试，直到成功。也就是你节点二阶段执行失败，自己了解下为什么你数据库出问题了，而不是分布式事务有什么问题。 \u0026amp;gt; 会不会出现重试过程中，其他事务修改了现有数据，而最终又被重试成功的情况?\n A：二阶段提交代表了什么？代表了整个调用链是成功的，一个成功的分布式事务，一阶段已经持久化了，你再去改，这个数据又不是脏的有什么问题？XA 来说，本地事务的本地锁先了解一下，一阶段不提了，锁被本地持有，如何修改？本地排它锁都没释放，何来脏写。\n3、@李艺渊 提问：\n Seata TCC 模式下，订单微服务和库存微服务。订单微服务try阶段添加订单信息，现阶段可以支持在库存微服务try阶段获取订单信息吗？或者说能把创建好的订单信息存储到 Seata-server ，然后在其他微服务可以获取到吗？\n  A：我理解 Server只负责全局事务的流转，try 出错就 cancel ，成功就 commit。Try 里面对两个库操作，正常是可以拿到数据吧。 \u0026amp;gt; 这2个微服务是分开部署的，数据库也是分开的。像订单微服务的 try 阶段，把订单信息存储到 order 数据库了。那库存微服务是不会去访问 order 数据库的。现在就是看库存微服务如何获取到新增的订单信息，看有没有什么 好的方式。\n Seata：https://github.com/seata/seata Service Mesh 相关推荐阅读 Service Mesh 中的可观察性实践 陌陌的 Service Mesh 探索与实践 - 直播回顾 Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 Apache SkyWalking 在 Service Mesh 中的可观察性应用 ","date":1605254400,"description":"【11/9-11/13】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201113/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"59cb50e2977d5e0b3ad675ca234c2b0f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201113/","publishdate":"2020-11-13T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201113/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 相关阅读合集、SOFABoot 以及 Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201113/","wordcount":1270},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、《Service Mesh Webinar#4:阿里云 CDN 微服务架构演进之路》直播回顾以及 QA 整理 视频回顾地址：https://www.bilibili.com/video/BV13D4y1R7do/\n@道酉 提问： \u0026amp;gt; 请问阿里云 MOSN 两个容器的热更新怎么实现的，就是怎么在pod内添加一个容器再去掉一个\nA：我们其实也没用跨容器热升级的方式，两个 Pod 挂载相同目录的方式是支持的。\n@陈鹏 提问：\n 请问一下同一个容器的热升级是怎么做的呢？\n A：我们是通过 RPM 升级的方式，容器内 systemd 管理的进程。\n@梁昌泰 提问：\n 重启不叫热升级吧？\n A：没有重启哈，直接起来一个新的进程。\n2、@谢子华 提问：\n Seata Saga 中，TC 的作用是什么？在 Saga 执行过程中 TM、TC、RM 和状态机的交互过程是怎样的？\n A：1）发起重试。2）根据分支响应状态，判断是否切换重试方向。目前，Sage 的分支默认情况下不会注册到 TC 了的，因为 Saga 本地库里有各 RM 的数据。 只有全局事务注册和全局事务提交或回滚时，与 TC 交互。\n 现在二阶段重试失败不断发起重试在 1.4.0 版本解决了吗？判断是否切换重试方向是只有可能 TC 会决定向后或者向前重试？\n A：是由 RM 端返回的状态为依据，由 TC 端切换重试方向，决定权在 RM 端。\n 我的理解是 RM 告诉 TC 回滚失败，然后有可回滚和不可回滚两个状态，TC 根据这个决定是否继续重试？那如何在 RM 进行配置？\n A：我刚才的截图是 TC 端发起全局提交时，RM 返回“回滚”失败重试回滚，这种情况，默认情况下不存在了，因为 Saga 不会注册分支到 TC。 实际上，应该是在 SagaCore 的全局回滚时，RM 端如果返回“提交”失败，重试提交状态时，会切换到向前重试。\n看了下源码，只有全局事务是因超时而进入全局回滚时，才会切换重试方向。\n 切换重试方向是指本来流程图配置是向后重试，然后超时了，TC 会切换为向前重试？\n A：意思是全局事务正在运行时，因超时60秒，TC 端自动将全局事务标记为超时回滚状态，然后会异步发起全局回滚请求。 这种情况下，碰到回滚失败时，会切换为向前重试。\n 哦哦，原来是这个样子。默认情况下，本地只会把全局的 RM，状态发送给 TC?\n A：默认情况下，RM 的数据只会存在本地。TC 端可以说是不管 Saga 分支的情况的。TC 只管接收 1）TM 的开始全局事务、完成全局事务；2）超时进入全局回滚；3）根据状态判断是否继续重试，还是切换重试方向。\n 1)是 TM 监测到所有 RM 都已完成然后告诉 TC 全局事务结束？3)TC 根据状态判断是否重试，现在 RM 不把状态发送给 TC，那这个状态是从哪里来?\n A：1）是的。 3）这个请求是从 TC 向 RM 端发起的。RM 只是返回一个状态而已。\n 我在实践中的问题就是在二阶段执行出现异常会不断地重试，如之前跟你聊过的补偿触发后补偿服务执行异常会不断重试。上述 TC 发起的全局回滚如果回滚过程中出现异常是不是也会不断地重试？不断地重试感觉比较占用资源？是否有应对策略让他能够只是有限次重试？\n A：重试策略的 PR 已经有了，但是因为 PR 依赖关系较多，暂时还没有合并，后续我会精简 PR 代码，单单引入重试策略的功能及其配置的功能。到时候会能够配置重试策略。目前，基本上是1秒钟就会发起一次重试。\n 现在没有重试策略的情况下，是否有其他的应对方法？\n A：将重试时间间隔配置稍微大一些，默认1秒。\n本周推荐阅读 云原生网络代理 MOSN 的进化之路 基于 MOSN 和 Istio Service Mesh 的服务治理实践 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 云原生网络代理 MOSN 平滑升级原理解析 | 开源 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.18.0 版本，主要变更如下：\n 新增 MOSN 配置文件扩展机制； 新增 MOSN 配置工具，提升用户配置体验； 优化 HTTP 协议处理对内存的占用； TLS 模块优化，增加了客户端降级配置逻辑、降低了 TLS 内存占用； 支持大于 4M 的 XDS 消息； 部分 API 接口进行了重构； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.18.0\n2、发布 Seata v1.4.0 版本，主要变更如下：\n 支持 yml 配置文件； 支持 Oracle nclob 类型； 支持客户端最少的活动负载均衡； 支持客户端一致性哈希的负载均衡； 支持 Spring Boot 使用自定义配置中心和注册中心； 支持 Apollo 密钥 key 配置； 修复禁止执行更新主键值的 SQL； 重构 Redis 存储模式下 session 的存储结构； 详细发布报告： https://github.com/seata/seata/releases/tag/v1.4.0\n","date":1604646000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201106/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dc199415476133ea6f6ee6adf2bf91fa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201106/","publishdate":"2020-11-06T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201106/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN、Seata 发布新版本、MOSN 相关阅读整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201106/","wordcount":2032},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@王钢 提问： \u0026amp;gt; https://github.com/sofastack-guides/kc-sofastack-dynamic-demo/issues/11 基于 SOFAArk 和 SOFADashboard 实现动态模块管控时遇到宿主应用能够下载biz安装成功，但是不能在zookeeper下生成对应的/apps/biz节点，导致管理端不能更新状态，不知道应该怎么排查解决。使用的 ZK 版本是 3.4.10。\nA：可以 debug 下写 /apps/biz 的逻辑，这里是不是宿主客户端没有连接上来，具体可以看一下：https://github.com/sofastack/sofa-dashboard-client SOFADashboard 之前只做了一个简单的模型，后面陆续其他同学也在上面做了一些开发，如果有兴趣可以一起参与共建哈。\nSOFADashboard：https://github.com/sofastack/sofa-dashboard\n2、@钟文豪 提问： \u0026amp;gt; SOFAJRaft 是如何计算 commitIndex 的呢？\nA：可以看看这个文档：https://www.sofastack.tech/projects/sofa-jraft/raft-introduction/\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@张潇 提问： \u0026amp;gt; 各位好 问个概念的问题。我三个服务 A,B,C，在 A 服务方法加了 @GlobalTransactional，调用 B ，C。启动三个服务的时候看 Seata 日志 ,A,B,C 服务每一个都是 RM 也是 TM。是这样的吗？不是 A 服务才是 TM 吗？\nA：在你这个事务当中，A 是对应着 TM，B、C 对应着 RM。 但是在注册的时候，他们都同时向 seata-server 注册了 TM 和 RM，意味着他们可以作为 TM，也可以作为 RM。 比如你有一个全局事务从 B 发起的，那这个时候他就是 TM。如果你认为你的业务场景中 B、C 这两个服务不会作为 TM 存在，你也可以把 TM 相关的配置删了，然后他就不会去注册 TM 了。可以从定义上去看 TM 和 RM，会发起全局事务的就是 TM，对应着数据库资源的就是 RM。一个服务可能只是 TM，也可能只是 RM，也可能都是。\nSeata：https://github.com/seata/seata\n本周推荐阅读 网商银行是如何建设金融级云原生分布式架构的？ 开源项目是如何让这个世界更安全的？ SOFA 项目进展 本周发布详情如下：\n开源 MOSN Golang 系统诊断工具 holmes beta 版：\n 支持基于 goroutine 波动的自动 goroutine profile dump； 支持基于 RSS 统计的 heap profile dump； 支持基于 CPU 使用率的自动 cpu profile dump； 详细参考： https://github.com/mosn/holmes/blob/master/readme.md\nSOFA 直播预告 传统 CDN 节点内组件间通信通过 IP 分组渲染的方式实现，当更多参差不齐的异构节点资源出现的时候则不再能很好地满足我们的需求。\n本期主要分享阿里云将传统的 CDN 节点改造成微服务架构的落地过程，主要使用了蚂蚁 SOFAStack–Service Mesh 的数据面 MOSN，主要分为两个阶段，第一个阶段是由传统 CDN 节点到数据面先行的微服务架构，通过数据面 MOSN+coredns 实现服务发现；第二个阶段是由数据面先行到数据面+控制面的标准 Service Mesh 架构。根据我们的落地和改造经验，介绍基于 MOSN+coredns/Istio 的 Service Mesh 架构改造的实际案例。上期分享了《Service Mesh 在 CDN 边缘场景的落地实践》，大家也可以温故一下～ 视频回顾地址：https://tech.antfin.com/community/live/1289\n分享主题：《Service Mesh Webinar#4:阿里云 CDN 节点微服务架构演进之路》\n分享嘉宾：邓茜（花名沐沂），阿里云高级开发工程师\n听众收获：\n 了解边缘场景下，使用 Service Mesh 架构的好处； 了解如何利用 MOSN + coredns 实现简单的服务发现； 了解如何利用 MOSN+ Istio 配置 http/tcp/udp 的转发规则以及如何动态配置持久化； 线上直播时间：2020 年 11 月 4 日（周三）20:00-21:00\n欢迎报名：点击“这里”，即可报名。\n","date":1604041200,"description":"【10/26-10/30】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201030/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a67a4e194b658ba2f0427011c0b56dba","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201030/","publishdate":"2020-10-30T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201030/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 项目更新及直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201030/","wordcount":1772},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@廖虹剑 提问：\n 我们想扩展一下 Dubbo 的 thrift 协议，遇到一个问题，consumer -\u0026amp;gt; mosn-client -\u0026amp;gt; provider，现在请求可以正常 decode -\u0026amp;gt; encode 到达 provider，并且 provider 可以正常调用，在返回的时候，数据包已经发回 MOSN，并且成功 decode，但是会阻塞在 read 处直到超时，没办法 write 回 consumer。 请问有什么排查思路吗？MOSN 里面这个网络模型看得有点晕。\n A：先 read 再 decode 的呀，你说的阻塞在 read 是阻塞在哪？\n read 方法已经正常调用，并且 decode了，但是没有触发写事件，consumer端 会一直在等待。 然后又会到这里卡住直到超时 A：数据 read 了没有新数据，这里就是会超时啊。你要看 decode 之后做了什么。\n 我打断点看到的 remote ip 和端口是 provider 端的。或者我换一个问法，MOSN 在获取到 upstream 的响应数据并且 decode 之后，是如何怎么触发 encodeResponse 并写回 writebuffer 的。我调试发现它 read 完数据之后无法进入到 endStream 方法。 也没看到什么异常日志。 我对 go 还不是特别了解，如果有什么问题还请多指正，辛苦了。\n A：你从 Decode 的逻辑往下跟一下就可以了，Dubbo 目前是 xprotocol 协议的实现 Decode 以后会经过 proxy 的流程最后再 encode，然后 write。read 是异步的，这个有点简单的介绍： https://mosn.io/blog/code/mosn-eventloop/\n 找到问题了，是 encode 的时候 replace requestId 的时候出了点问题，导致找不到对应的 stream，感谢~\n MOSN：https://github.com/mosn/mosn\n2、@Bernie G 提问：\n 我这边项目是 Spring Boot，没有用 Dubbo， 这种情况可以用 Seata 做 Saga 事务吗？\n A：你的服务调用是通过 feign，resttemplate？Saga 跟 RPC 框架不是强绑定的，你的远程服务可用在被调用方作为类似 reference bean 的形式调用就可以。\n 我们这边主要用的是 RestfulApi 还有 gRPC 来作为微服务之间的调用， Seata 能支持吗？ 如果能给个代码 Sample 最好。\n A：Test 中有 gRPC 的实例，看下是否满足需求。 https://github.com/seata/seata/tree/develop/integration/grpc\nSeata：https://github.com/seata/seata\n本周推荐阅读 开源项目是如何让这个世界更安全的？ Hey，邀请你加入我们一起玩耍 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.4.5 版本，主要变更如下：\n 支持 triple 线程监控； 升级 sofa-ark 版本至 1.1.5； 升级 junit 版本至 4.13.1； 修复 jvm filter npe 问题； 修复http server 线程池配置问题； 详细发布报告： https://github.com/sofastack/sofa-boot/releases/tag/v3.4.5\n2、发布 SOFAArk v1.1.5 版本，主要变更如下：\n 修复 web 模块并发安装问题； 修复支持 web 环境测试 webContext 默认为 null 导致的 NPE 问题； 详细发布报告： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.5\nSOFA 直播预告 在边缘计算和 5G 商业化风起云涌的当下，阿里云 CDN 开展了节点全面云原生化的改造，在此背景下，我们尝试利用 CDN 资源池为底座，在大规模复杂边缘场景下建设 Service Mesh 的基础能力，打造边缘 PaaS 平台。落地实践过程中我们使用了蚂蚁 SOFAStack–Service Mesh 体系中的 MOSN 作为数据面，Istio 作为控制面。本次分享将从 Service Mesh 技术以及 CDN 边缘场景介绍入手，重点分析 Istio 和 MOSN 结合的落地实战过程。\n分享主题：《Service Mesh Webinar#3：Service Mesh 在 CDN 边缘场景的落地实践》\n分享嘉宾：肖源（花名萧源），阿里云技术专家\n听众收获：\n 了解 Service Mesh 技术； 了解 Service Mesh 在阿里云 CDN 边缘场景的落地实践； 给到想要落地 Service Mesh 的同学一些案例与建议； 线上直播时间：2020 年 10 月 28 日（周三）20:00-21:00\n欢迎报名：点击“这里”，即可报名。\n","date":1603436400,"description":"【10/19-10/23】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201023/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cf0c4a06a60155202353fe19c3185072","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201023/","publishdate":"2020-10-23T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201023/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAArk、SOFABoot 发版、10月28日线上直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201023/","wordcount":1640},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谢子华 提问：\n SOFARPC 客户端A调用服务端 B，B在方法中想异步调用C（不同步等结果），在callback里面才响应结果返回给A。这种有 Demo 吗？\n A：链路异步吗？ 可直接看测试用例 https://github.com/sofastack/sofa-rpc/blob/master/test/test-integration/src/test/java/com/alipay/sofa/rpc/test/async/AsyncChainTest.java\n 谢谢，看了下用例。我理解是 服务端接口执行时在 RpcInvokeContext 设置了 SendableResponseCallback 类型的 callback。SOFA 就会忽略接口的返回值。然后在 callback 中主动调用 sendAppResponse 返回结果。对吗？\n A：对的。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@明丽 提问：\n 有没有存在经常锁表的童鞋？lock_table 里存在锁表数据和 undo_log 里面有历史几天的数据没有被删除掉？\n A：locktable 如果没删除，说明可能遇到脏数据导致分支事务无法回滚，此时就会有锁无法释放，这时候要根据 locktable 的信息去找对应的分支事务是那个应用，去看下日志提示，如果是脏数据会说镜像校验不通过\n 这里的脏数据具体是指什么样的数据？\n A：全局事务是回滚时，需要回滚的数据被改动。\n 通常报错的就是并发情况下扣减库存，操作同一条 update 库存数量语句。\n A：比如 a=1，update 后时 a=2。此时其他的分支事务异常，导致全局事务决议时回滚，这个时候 a 被改为了3，这个 a 的数据脏了，隔离性没被保证。此时回滚的时候会校验 a 还是不是当前事务修改的值，如果不是，说明这个数据脏了，已经不正确了，不能盲目的直接回滚成1，说明隔离性没保证，有数据被 Seata 全局事务外的地方修改了，如果想保证隔离性，就需要保证任何一个写场景，都被全局事务注解覆盖。\n 我们这边的更新场景都有加全局事务的注解，好像没有起作用，还有别的不起作用的情况吗？\n A：那就检查是否都覆盖了，比如定时任务，或者会不会有认为的去数据库层面直接修改。\n 另外一个问题，我在订单服务下单的时候发起扣库存请求，这个时候只需要在订单服务的方法加上全局注解就可以了，对吗？不需要在库存服务被调用的方法加注解？\n A：只要保证 xid 传递跟数据源代理即可，但是如果有订单服务之外，没有被全局事务注解覆盖的地方操作了库存，一样会脏。这个文章我借鉴了清铭、屹远、煊意的博客，总结了一下 XA 跟 AT 的关系，也谈到了隔离性方面的问题，希望你看过后可以理解 AT 的隔离性是如何保证的。 https://blog.csdn.net/qq_35721287/article/details/108982806\nSeata：https://github.com/seata/seata\n剖析 SOFAJRaft 实现原理合集 SOFAJRaft 实现原理 - 生产级 Raft 算法库存储模块剖析原理 SOFAJRaft 实现原理 - SOFAJRaft-RheaKV 是如何使用 Raft 的 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析 | SOFAJRaft 实现原理 SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.5.Alpha1 版本，主要变更如下：\n 升级 \u0026amp;lsquo;rocksdb\u0026amp;rsquo; 到 5.18.4 以支持 AArch64； 优化：心跳响应不经过 pipeline 直接发送，避免 pipeline 影响心跳响应的及时性； 修复使用 grpc 时，在一定情况下无法自动重连的问题； 修复使用 grpc 时，在 error response 处理的错误； 致谢（排名不分先后）：@cmonkey @odidev 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.5.Alpha1\nSOFA 团队欢迎你加入 蚂蚁集团招聘技术运营专家啦～欢迎加入我们一起为可信技术带来更多的想象。\n岗位名称：可信原生技术运营专家\n岗位描述：\n 挖掘技术内容和业务价值，并形成体系，构建传播矩阵，形成并提高产品和技术的行业美誉度； 完整策划并执行线上、线下的技术活动、大赛，构建围绕可信原生技术的开发者活跃群体，并有更多创造性的技术玩法，使技术可感知； 维护重点 KOL，并吸纳行业专业意见，加大行业贡献，并深化行业影响力。 岗位要求：\n 具备用户细分、市场定位、产品规划、产品包装的能力中的一项或多项； 具备良好的创新思维、有技术前瞻性； 良好的沟通协作能力，及横向驱动能力； 有线上市场推广经验，或线下活动策划经验者优先考虑； 对于云计算领域有较深入的了解，有相关工作背景者优先考虑。 欢迎简历投递至：khotyn.huangt@antgroup.com\n","date":1602831600,"description":"【10/12-10/16】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201016/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a7a2f16f7c62d777b8aff0f90a85ba7b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201016/","publishdate":"2020-10-16T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201016/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布、SOFAJRaft 源码解析文章合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201016/","wordcount":1951},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@叶翔宇 提问： \u0026amp;gt; 想请教一个问题，使用 MOSN 的过程中，我们想通过 request 的 header 中带的 version 信息来实现灰度的机制。比如：目标 service 有 3 个 host，其中一台版本1.0，其他两个版本2.0。\nA：你这个加一个 route 的判断就可以路由到不同的 cluster 了。\n 我们的是同一个 cluster 里面的不同 hosts\u0026amp;hellip;\n A：你就把不同版本的 hosts 归为不同的 cluster 就可以啦。\n2、@李样兵 提问： \u0026amp;gt; 我们现在生产环境中没有使用 K8s, 只使用 MOSN+自定义配置和注册中心，可行吗？\nA：你们是 Dubbo 么？\n 对，dubbo+http， 生产环境是 docker 还没有 K8s。\n A：你可以用这个方案，MOSN 直接连接注册中心。 https://github.com/mosn/mosn/issues/1087 MOSN：https://github.com/mosn/mosn\n线上直播 SOFAChannel 合集 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 蚂蚁金服分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 ","date":1602226800,"description":"【10/05-10/09】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201009/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a83b0d192a605f994a1379ab41578403","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201009/","publishdate":"2020-10-09T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201009/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN QA 整理、SOFAChannel 线上直播合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201009/","wordcount":938},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@周爽 提问： \u0026amp;gt; 我现在基于springcloud 集成 nacos,sentinel,zipkin,jpa,shardingjdbc，昨天说的做了防止重复代理，如果我是多数据源呢？后续1.3.1是配置也需要开启，代码也需要写代理吗？\nA：多数据源就关掉自动代理，自己手动\n 就在我多数据源里面加上右边的 DataSourceProxy 就可以了吗？ @Primary 这个只需DataSource1Config加上，DataSource2Config是否需要加呢？\n A：代理这个 reresult；\n AT 和 XA 1.3版本可以理解为代码“使用”上就一个 new poxy 不同吗？\n A：一个是 new DataSourceProxy，一个是 new DataSourceXAProxy\n Seata “实现”一个是二阶，一个是基于 XA 事务规范？\n A：都是二阶段，一个模式是自研，一个是基于数据库底层实现。 Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁宣布开源 KubeTEE：让机密计算支持大规模 K8s 集群 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 SOFAEnclave：蚂蚁金服新一代可信编程环境，让机密计算为金融业务保驾护航102年 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.7.6 版本，主要变更如下：\n 支持精细化配置 Jackson 序列化； Triple 协议支持用户自定义元数据； Triple 协议支持 SPI 编程模式； 升级 hibernate-validator 版本到 5.3.6.Final； TripleServer 启动时发送启动事件； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.6\n2、发布 MOSN v0.17.0 版本，主要变更如下：\n 重构 XProtocol 连接池，支持 pingpong 模式、多路复用模式与连接绑定模式； 优化 XProtocol 多路复用模式，支持单机 Host 连接数可配置； Listener 配置新增对 UDS 的支持； 新增在 Dubbo 协议下通过 xDS HTTP 配置进行转换的过滤器； 部分框架实现优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.17.0\n","date":1601622000,"description":"【09/28-10/02】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20201002/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bc9b38b8088d82138a46a8318e944840","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201002/","publishdate":"2020-10-02T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20201002/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":" SOFA Weekly | MOSN、SOFARPC 发版、Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20201002/","wordcount":1018},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@刘源远 提问：\n 请教一下大家，这个本地事务提交，是指这个本地事务在分布式事务中提交，还是指在自己的事务中提交啊？ 如果是指分布式事务中提交，那不就应该在分支事务提交之前，才存在回滚嘛？如果是指自己的事务中提交，那我断点下来，本地业务事务已经提交了，为什么还产生这条记录呢？ A：只要二阶段回滚的时候，发现你的 undolog 没插入就会做一条防御性的 undolog，你可以认为你没产生资源悬挂，但是二阶段确实没读到你的 undolog。所以才会插入一个防御性，你完全不需要理会 status=1 的记录。\n 奇怪的是，我断点下来，在一阶段会产生 undolog 记录（两条），然后抛异常回滚之后，一阶段的 undolog 记录（两条）被删除了，产生一条 status=1 的记录。会不会是因为某些原因，一阶段会产生 undolog 记录被删除了，所有二阶段没有查询到？\n A： 多数据源？\n 对的，多数据源。\n A：确认下是不是重复代理了？把自动代理关了，一般多数据源都是已经手动代理了，因为二阶段的时候，下发找 datasource，找到的不是你当时操作数据库的 datasource，导致没发现 undolog，就插了一条 status=1。\n 我现在手动配置代理，有两个数据源，一个用了 DataSourceProxy，一个没有。现在处于分布式事务中是使用了 DataSourceProxy 的数据源，但是回滚后还是会产生一条 status=1 的 undolog。\n A： 自动代理关了吗，看下怎么代理的。\n 你指的自动代理是 springboot-start 吗？还是其他的？\n A：Seata 的数据源自动代理，设置 Seata: enable-auto-data-source-proxy: false\n OK，好啦\n Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服通信框架 SOFABolt 解析 | 超时控制机制及心跳机制 蚂蚁金服通信框架 SOFABolt 解析 | 连接管理剖析 蚂蚁金服通信框架 SOFABolt 解析 | 协议框架解析 蚂蚁金服通信框架 SOFABolt 解析 | 序列化机制(Serializer) 蚂蚁金服通信框架 SOFABolt 解析 | 编解码机制 社区活动预告 CSDI summit 中国软件研发管理行业技术峰会（Software development management industry technology summit）由国内专业咨询机构百林哲匠心打造的软件行业技术领域顶级盛会，将于2020年9月24-27日举办。 话题涵盖：组织数字化转型、研发效能、产品创新、用户增长、云原生、架构创新、微服务、AI 大数据、数据安全和云安全、AIOT 实践等方面。蚂蚁集团也应邀参与本次大会分享。\n分享主题：金融级云原生 PaaS 实践之路\n分享嘉宾：成旻 蚂蚁金服高级技术专家\n分享时间：2020-09-26 16:40 - 18:00\n分享亮点：\n 蚂蚁 PaaS 产品的缘起； 经典应用服务的能力和特色； 容器应用服务的进阶能力； 面向未来\u0026amp;ndash;混合云发展发向； 活动形式：线上峰会\n活动详情：点击“这里”，了解日程详情\n","date":1601017200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200925/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c7562a535d9b34b23d0b559dd756ef6a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200925/","publishdate":"2020-09-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200925/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt 源码解析合辑、CSDI summit 活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200925/","wordcount":1385},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 社区大事件 MOSN 支持 Istio 啦～详见链接：\n 英文版：《Using MOSN with Istio: an alternative data plane》 中文版：《在 Istio 中使用 MOSN：另一个数据平面》 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@梓郁 提问：\n 我最近刚刚接触分布式链路监控，看了 SOFATracer 的 slf4j 的 demo。现在有一个问题。就是我想在日志里面打印出 span 的 parentid，但是我不想在我自己的代码里面显性地用 MDC 添加，有什么其他方法吗？（我现在是打算在 MDCSpanExtension 里面用 mdc.put 添加;再重新打包添加依赖这样可行吗？）\n A：自己扩展下这个接口 SpanExtension。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@石评 提问：\n 我有个关于 Seata 的疑问：A -\u0026amp;gt; B-\u0026amp;gt;C 的时候，不管 B 有没有本地事务，如果 C 失败了 B 的都会回滚，那么 B 的本地事务的作用是什么呢？\n A：分布式事务认为由若干个分支事务（本地事务）构成的，如果加了 autocommit=false，那么 B 服务的几条 sql构成一个本地事务，如果不加那么每条 DML 语句都是一个本地事务。本地事务越少那么与 TC 的交互次数越少。\n3、@徐成阳 提问：\n Seata 的 TCC 强一致的嘛？\n A：AT、XA、TCC 应该都属于强一致性。 SAGA 无法保证事务隔离性，在部分情况下可能会存在无法回滚，而选择向前继续重试来保证事务最终一致性。 四种模式都是属于最终一致性。SAGA 性能更高，因为没有二阶段提交，而且分支数据都是保存在本地的。\nSeata：https://github.com/seata/seata\n本周推荐阅读 来了！2020 云栖大会 蚂蚁金融科技产品能力再升级 企业数字化转型指南，《SOFAStack 解决方案白皮书》正式发布 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.4.bugfix_2 版本，主要变更如下：\n 修复使用 grpc 时，在一定情况下无法自动重连的问题； 详细发布报告： https://github.com/sofastack/sofa-jraft/releases/tag/1.3.4.bugfix_2\n社区活动预告 这里有一个您的专属日程提醒，请查收：\n日程主题：OceanBaseDev Meetup#1 上海站「深入分布式数据库：事务·高可用·云原生」\n出品人： - 杨传辉（花名：日照）蚂蚁集团研究员、OceanBase 总架构师 - 韩富晟（花名：颜然）蚂蚁集团资深技术专家、OceanBase 事务研发负责人\n日程时间：2020-09-20 本周日 13:00-17:30\n日程地点：上海市杨浦区政学路77号 InnoSpace+\n日程详情：点击“这里”，了解日程详情\n","date":1600412400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200918/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d3e2feb22ec7504b5fc6648eeba4769f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200918/","publishdate":"2020-09-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200918/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFAWeekly｜MOSN 支持 Istio、SOFAJRaft 发布、本周日您有一条待办日程","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200918/","wordcount":1251},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈健斌 提问：\n Seata 使用注册中心只存储个地址列表，引入 SOFAJRaft 后感觉注册中心没必要了？用户用起来就跟 zk 集群、kafka 集群一样，ip:port,ip:port 这样。\n A：这个 看需求了，都可以啊。我感觉还是可以继续使用注册中心，然后 SOFAJRaft 的地址从注册中心回去，动态构建 SOFAJRaft 集群。\n 可以噢，这样 client 端不需要设置 server 的集群了，通过注册中心来就可以了，自动组装了。 我目前是这么设计的，有空的话还望指点一二。\n A：Sesta server 经常会经常替换吗？\n 这个得看用户了，要不咱假设2个情况吧，如果不经常替换，此方案适用不。经常替换下要做哪些改进？\n A：经常替换的话要考虑 raft 集群的替换，要处理 addpeer removepeer 这是要走 raft 协议的（用 cliservice 这个接口），就是换一台 server 不是换个地址就完事了，需要调用 addpeer把新机器加入 raftgroup 然后 SOFAJRaft 会自动同步数据，移除一个节点需要调用 removepeer。\n 也就是，如果我现在扩容，比如我原来的节点是127.0.0.1:7091，127.0.0.1:7092，127.0.0.1:7093 然后我现在要加一个127.0.0.1:7094，我能不能直接跟 zk 那边扩容一样，我新加入进来的节点设置的地址是127.0.0.1:7091，127.0.0.1:7092，127.0.0.1:7093，127.0.0.1:7094，先让他加入进去，然后手动挨个重启其余3台。目前这样的扩缩容，我的设计方案能满足吗？\n A：不需要重启，需要 addpeer，参考第11小结，最有效的排查 SOFAJRaft 问题工具 https://www.sofastack.tech/projects/sofa-jraft/jraft-user-guide/ SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@koutatu 提问： \u0026amp;gt; 想咨询下，Seata Saga 模式下，TC 的作用是什么呢，回滚操作还是 TC 触发吗？感觉 Saga 状态机模式下，状态机可以控制回滚，TC 是不是只是记录下状态，不做什么实际处理了呢？\nA：你说的应该是对的，Saga 脱离 TC 理论上都是可行的。\n 目前的回滚操作是不是也是状态机自身控制的，也就是链路里面的每一步都需要有一个状态机。TC 只负责接收消息，而不是像 TCC 或者拦截器式的 Saga 一样，回滚由 TC 统一控制。\n A：TC 在 Saga 模式的作用就是记录全局事务分支事务状态。 Seata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析 SOFABoot 扩展点初体验 | SOFALab 实践系列 剖析 | 详谈 SOFABoot 模块化原理 实操 | 基于 SOFABoot 进行模块化开发 开源 | SOFABoot 类隔离原理剖析 SOFA 项目进展 1、发布 SOFAArk v1.1.4 版本，主要变更如下：\n 支持动态替换 biz name； TestClassLoader 导出 mockito 包以支持 mockito 测试框架； 修复 AfterBizStopEvent 事件处理时机问题导致的 NPE； 修复 web 模块卸载问题； 支持 ark telnet 使用安全模式启动； 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.1.4\n2、发布 SOFABoot v3.4.4 版本，主要变更如下：\n 提供 jvm 调用拦截扩展； 修复若干测试用例； 修复在 ark 环境使用 sofa:reference 引用 jvm 服务出现 NPE bug； 修复健康检查通过但 ExtensionComponent activate 失败 bug； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.4\n社区活动预告 近几年，越来越多的传统企业面临互联网化，IOT、区块链、AI、5G 等技术也在高速发展，任何一个技术的推广到成熟都会带来数据量的指数级增长，都会对存储带来巨大的冲击。相信随着这些技术的突破，未来越来越多的核心场景会走向分布式的领域。国内很多团队也在进行分布式数据库的探索与实践。\nOceanBaseDev Meetup 是以城市站展开的数据库技术交流活动，旨在为关注分布式数据库技术的同学提供技术交流、分享、探讨的空间与平台。\nOceanBaseDev Meetup#1 上海站，将邀请蚂蚁集团 OceanBase 团队的三位核心研发专家以及网易杭研资深研发工程师，针对分布式数据库的分布式事务以及落地实践展开分享。现场更有外滩大会门票等你来拿～\n活动主题：**OceanBaseDev Meetup#1 上海站「深入分布式数据库：事务·高可用·云原生」\n出品人： - 杨传辉（花名：日照）蚂蚁集团研究员、OceanBase 总架构师 - 韩富晟（花名：颜然）蚂蚁集团资深技术专家、OceanBase 事务研发负责人\n活动时间：2020-09-20 13:00-17:30\n活动地点：上海市杨浦区政学路77号 InnoSpace+\n活动报名：点击“[阅读原文**](https://www.huodongxing.com/event/5562442480600)”，了解活动详细议题并锁定席位\n","date":1599807600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200911/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"25ab3501e7db2cd836d05f86bb6c17ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200911/","publishdate":"2020-09-11T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200911/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot、SOFAArk 发布、9/20 上海线下活动推荐","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200911/","wordcount":2145},{"author":"王发康（毅松）","categories":"MOSN","content":" 本文根据 2020 年 8 月 15 号在深圳 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会云原生专场现场实录整理。\n分享嘉宾：王发康（毅松）蚂蚁集团可信原生技术部 技术专家，专注于高性能网络服务器研发，是 MOSN、Tengine 开源项目核心成员，目前关注云原生 Service Mesh、Nginx、Istio 等相关领域，喜欢开源，乐于分享。\nGItHub：https://github.com/wangfakang\n以下是分享全文。\n前言 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，本文就其在演进过程中遇到的问题及思考进行展开。对接 UDPA，实现 Istio 融合，并增强 MOSN 服务治理及流量控制能力对接云原生周边组件，实现 MOSN 开箱即用。\n大家下午好，我叫王发康，来自蚂蚁集团可信云原生应用网络团队，之前几年一直从事南北向网关（接入层）的开发和维护，说来也是和流量有着别样的渊缘，现在主要做东西向的流量网关（Service Mesh）开发和设计。今天演讲的主题是《云原生网络代理 MOSN 的进化之路》，主要从如下几点介绍：\n MOSN 介绍； 云原生演进； 总结与展望； MOSN 介绍 接下来，就 MOSN 的诞生背景、发展历程、MOSN 具备的功能和架构以及内部的落地情况这几个维度介绍下 MOSN。\nMOSN 诞生背景 随着云计算、物联网等技术迅速发展，也促使着微服务的架构一直在进化，其演进过程通常经历了如下四个阶段：\n单体：一般起始阶段业务很简单，流量也不大，所有的处理都可以在一个服务中完成；\n分布式：随着业务操作的多样化以及流量的日益增长，不得不按照服务维度进行拆分，这样相同的服务资源消耗可对等，方便容量评估及管理；\n微服务：随着服务的拆分粒度越来越细，其服务的数量一直在增加，由此出现各种微服务治理的需求（限流、鉴权、路由等），于是便出现各种治理组件并以 SDK 插件的方式集成到不同应用中；\nService Mesh：伴随着服务治理的 SDK 种类、版本、重复等一系列问题，于是把 SDK 的能力剥离到 Sidecar，和业务进行解耦，从而实现业务和中间件能力的并行迭代；\n业务痛点\n 多语言，中间件组件开发适配成本高； SDK 升级困难； 服务治理能力弱； 技术不通用，无法复用； 业界解决方案\n Envoy (C++)； Linkerd (活跃度较低)； NginxMesh (活跃度低)； 综合以上业务痛点以及业界现有方案的评估，于是 MOSN 就诞生了。MOSN（Modular Open Smart Network）是用 GoLang 编写的网络代理服务器。作为 Sidecar、API Gateway、云原生 Ingress、Layer 4 或 Layer 7 负载均衡器等场景构建的。随着时间的推移，我们添加了额外的功能，例如多协议框架，多进程插件机制，DSL 以及对 xDS API 等的支持，支持 xDS 意味着我们现在可以将 MOSN 用作 Istio 的数据平面。\nMOSN 发展历程 从 2017 年底开始 Service Mesh 技术调研，2018 年 3 月份 MOSN 雏形问世并进行了小规模试点，秉着让更多的用户能够享受这一技术红利的思路，于是 2018 年 6 月正式开源 MOSN。2019 年 618 进行了规模化落地，并在同年的双 11 大促达到了核心支付链路的全覆盖。在通过大规模验证后，MOSN 社区开始在其标准化以及生态方面进行发展和演进。\nMOSN 功能视图 MOSN 作为一个通用的数据转发平面，提供多协议卸载、动态服务发现、服务治理（Trace、限流、重试、重写、超时控制等）、丰富的负载均衡算法等功能，可用于 Sidecar、API Gateway、云原生 Ingress、Layer 4 或 Layer 7 负载均衡器等场景。\nMOSN 架构解析 MOSN 采用的是分层的体系结构，其系统分为 NET/IO、Protocol、Stream、Proxy 四层：\n NET/IO 作为网络层，监测连接和数据包的到来，同时作为 listener filter 和 network filter 的挂载点; Protocol 作为多协议引擎层，对数据包进行检测，并使用对应协议做 decode/encode 处理; Stream 对 decode 的数据包做二次封装为 stream，作为 stream filter 的挂载点; Proxy 作为 MOSN 的转发框架，对封装的 stream 做 proxy 处理; 其中，每一层通过工厂设计模式向外暴露其接口，方便用户灵活地注册自身的需求。通过协程池的方式使得用户以同步的编码风格实现异步功能特性。通过区分协程类型，MOSN 实现了 read 和 proxy worker 两大类协程，read 协程主要是处理网络的读取及协议解析，proxy worker 协程用来完成读取后数据的加工、路由、转发等。其架构如下图所示：\nMOSN 为了降低 Runtime GC 带来的卡顿，自身做了内存池的封装方便多种对象高效地复用，另外为了提升服务网格之间的建连性能还设计了多种协议的连接池从而方便地实现连接复用及管理。\n在连接管理方面，MOSN 设计了多协议连接池， 当 Proxy 模块在 Downstream 收到 Request 的时候，在经过路由、负载均衡等模块处理获取到 Upstream Host 以及对应的转发协议时，通过 Cluster Manager 获取对应协议的连接池 ，如果连接池不存在则创建并加入缓存中，之后在长连接上创建 Stream，并发送数据，如下图所示：\n在内存管理方面，MOSN 在 sync.Pool 之上封装了一层资源对的注册管理模块，可以方便的扩展各种类型的对象进行复用和管理。其中 bpool 是用来存储各类对象的构建方法，vpool 用来存放 bpool 中各个实例对象具体的值。运行时通过 bpool 里保存的构建方法来创建对应的对象通过 index 关联记录到 vpool 中，使用完后通过 sync.Pool 进行空闲对象的管理达到复用，如下图所示：\nMOSN 落地情况 服务在做了 Mesh 化后，有人可能会质疑，增加一跳 Sidecar 转发是否会导致性能下降，其实不然，在蚂蚁的部分业务场景中，部分业务上了 Mesh 后，其 CPU 消耗还比之前低了，原因是之前的一些通用 SDK 能力都下沉到 Sidecar 中，并统一做了一定的优化。另一个好处是，由于 MOSN 使用 GoLang 开发，天然具备其高开发效率，所以也大大的提升了中间件相关能力的研发速度。\nMOSN 云原生演进 在 MOSN 大规模落地并通过双 11 大考后，MOSN 也开始在实践的道路上进行标准化演进。并通过和 Istio 社区的合作，MOSN 实现了 xDS 的适配，可方便的实现 Istio 作为 MOSN 的控制面进行服务配置的管理。另一方面， …","date":1599022800,"description":"MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，本文就其在演进过程中遇到的问题及思考进行展开。","dir":"blog/cloud-native-network proxy-mosn-evolutionary-path/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"080e78e9d0103daed414ee3a8b5b7996","permalink":"https://sofastack.github.io/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","publishdate":"2020-09-02T13:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","summary":"本文根据 2020 年 8 月 15 号在深圳 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会云原生专场现场实录整理。 分享嘉宾：王发康（毅松）","tags":["MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 的进化之路","type":"blog","url":"/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/","wordcount":5065},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@晏伦 提问：\n 请问 Seata 的全局锁粒度是数据库级别还是表级别？全局锁会带来并发的问题吧？如何权衡的呢？\n A：全局锁是行级别的；如果2个事务在同时更新同一行，会出现锁竞争问题，所以 AT 模式的适用场景是并发请求较低，不会产生行锁竞争的业务场景。\nSeata：https://github.com/seata/seata\n本周推荐阅读 少年五年升阿里 P8，他如何从低谷登上“光明顶”？ 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构 Forrester中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求 组件解析部分合辑 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 SOFA 项目进展 发布 sofa-common-tools v1.2.0 版本，主要变更如下：\n 修复多线程日期打印问题； SOFAThreadPool 支持一个 Runnable 在多个 thread 运行； 停止 JDK6 支持； 详细发布报告：https://github.com/sofastack/sofa-common-tools/releases/tag/v1.2.0\n社区活动预告 CSDI summit 中国软件研发管理行业技术峰会（Software development management industry technology summit）是软件行业技术领域顶级盛会，协同国内外知名软件、互联网等企业研发一线技术专家从 AI 和大数据、产业变革、技术创新、生态发展、业务创新、商业模式等方面重点研讨软件研发趋势。蚂蚁集团也受邀参与本次峰会分享“云原生”相关主题。\n分享主题：金融级云原生 PaaS 实践之路\n分享嘉宾：成旻 蚂蚁集团高级技术专家\n分享时间：2020-09-26 16:40-18:00\n听众收获：\n 蚂蚁 PaaS 产品的缘起； 经典应用服务的能力和特色； 容器应用服务的进阶能力； 面向未来\u0026amp;ndash;混合云发展发向； 活动地点： 线上活动\n活动报名： 点击“这里\n","date":1598598000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200828/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"474484cd88c8a1971016217eb9c1438d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200828/","publishdate":"2020-08-28T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200828/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | sofa-common-tools 发布、组件解析合辑、云原生活动推荐","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200828/","wordcount":1038},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@谢小东 提问：\n 请教一个问题，在使用 AT 模式的时候，新增的一条数据，回滚之前我在 db 改了我刚新增的数据，这个时候如果我抛出异常，但是就不发回滚，该怎么处理？\n A：不要在全局事务包裹之外进行对数据的并发操作，如果你这样做，就跳过了 AT 的全局锁，隔离性无法保证，如果你有这方面需求的，可以用 XA 模式，并且使用数据库自身带有排它锁的操作，数据库的自身支持了 XA 模式，就可以帮你保证隔离性。\n 你的意思就是我在这种情况下 XA 模式适合？XA 模式是行锁么？\n A：XA 是数据库自身实现的隔离机制，AT 是统一到 TC 去竞争行锁，而没用到 AT 的地方修改数据库当然就不会去 TC 竞争行锁，隔离性只能保证再全局事务注解下的操作生效。\n2、@彭兴家 提问：\n 请问 Seata 里说的全局锁和本地锁对应 MySQL 的什么锁呀？\n A：全局锁就是从 TC 竞争的锁，本地锁就是参与方自己本地的 MySQL 连接，比如 update 不就有排他锁的作用吗，因为一阶段提交，连接释放了，这个本地数据库的锁就解开了。而全局锁是从 TC 拿的，这个锁保证了你的入口只要是分布式事务注解下，就会去竞争这个全局锁。保证了再分布式事务注解下的全局事务间的隔离性\n 谢谢，明白了。但这样的话，Seata 通过前置镜像回滚。在全局事物执行的过程中，要是其他项目(没在全局事物下的项目)对该条数据进行了修改，那么按照 Seata 的机制，前置镜像对比不同了就不能回滚，需要手动处理？\n A：是的，需要人工介入，因为只有人为分析才能校准数据了。对 Seata 来说他只知道要把数据回滚到发生前，但是数据被干扰了，就无法回滚了。\n 理论上来说这种情况出现的几率很大呀，多个不同项目操作同一条数据。\n A：全局事务，字面意思要理解一下。你让他不全局了，让它不覆盖到，如何保证隔离性？要么涉及到的库对应的应用全局使用 Seata AT，要么就换 XA，修改的数据，用 select for update，这个本地锁在二阶段下发通知前不会释放，保证了隔离性。\n3、@苏龙飞 提问：\n 请问，现在我们的 cloud 项目中用了 Seata，数据库只有一个，然后发现性能不够，所以想换成多主从数据库，并且能和 Seata 兼容，有没有好的方案呀？\n A：主从方案本就应该是允许暂时的不一致，只要你保证读写都需要的时候，一定是主库，并把主库的 datasource 代理掉就好了，保证需要读后马上写的，一定要是主库操作。 Seata：https://github.com/seata/seata\nSOFAChannel 部分合辑 人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | 开源 蚂蚁集团网络通信框架 SOFABolt 功能介绍及协议框架解析 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 [链接]()蚂蚁金服分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理 云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 本周推荐阅读 蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO？ 蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？ ","date":1597993200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200821/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"34ac475f8a4ec2435b62a9bf4d520e2a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200821/","publishdate":"2020-08-21T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200821/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 线上直播合辑整理、Seata QA 整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200821/","wordcount":1515},{"author":"樱桃","categories":"Occlum","content":" \u0026amp;lt; SOFA:Channel/ \u0026amp;gt;，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 本文根据 SOFAChannel#18 直播分享整理，主题：零门槛的机密计算：Occlum LibOS 使用入门和技术揭秘。\n大家好，我是今天的讲师田洪亮（花名：樱桃），蚂蚁集团技术专家，也是 Occlum 开源负责人。今天我和大家分享一下如何使用 Occlum 的轻松开发机密计算应用以及 Occlum 技术架构和特色。\n前言 云计算、大数据、人工智能，我们正处在一个数据爆炸的时代。如何能够在享受和利用海量数据所产生的价值的同时，保证数据的安全和用户的隐私呢？这无异是一个用户、企业和监管部门共同关注的问题。\n近年来兴起的机密计算（Confidential Computing），正是为了解决这个问题而来。利用可信执行环境（Trusted Execution Environments，简称 TEE）技术，机密计算使得数据始终保持加密和强隔离状态，从而确保了用户数据的安全和隐私。机密计算可以解决诸多应用场景中“信任”难题，比如多个不互信组织之间的数据融合与联合分析、区块链上的智能合约的机密性保护、公有云平台对外部或内部攻击的防御、高敏感信息（比如密码学材料、医疗档案等）的安全保护等等。\n但是，机密计算底层依赖的 TEE 技术——比如目前最成熟的云端 TEE 技术 Intel SGX——也带来了额外的功能限制和兼容问题。这使得机密计算的开发者面领一个巨大的阻碍：应用开发难。\n在本文中，我们会首先分析当前 SGX 应用开发者会遇到的各种挑战和痛点，然后介绍蚂蚁集团自研的开源 TEE OS 系统 Occlum 如何大幅降低 SGX 应用开发的门槛，真正做到人人都可以玩转机密计算。\n为什么 SGX 应用开发难？ SGX 应用程序是一种基于划分的模型：在用户态的（不可信）应用程序（上图红色部分）可以嵌入 SGX TEE 保护的区域（上图绿色部分），被称为 Enclave。支持 SGX 的 Intel CPU 保证 Enclave 中的受保护内容是在内存中加密的，并且与外界强隔离。外界的代码如果想进入 Enclave 中执行其中的可信代码必须通过指定的入口点，后者可以实施访问控制和安全检查以保证 Enclave 无法被外界滥用。\n由于 SGX 应用程序是基于这种划分的架构，应用开发者通常需要使用某种 SGX SDK，比如 Intel SGX SDK、Open Enclave SDK、Google Asylo 或 Apache Rust SGX SDK。但无论使用上述哪种 SDK，开发者会遭遇下面的开发困境：\n 必须将目标应用做二分：开发者需要决定哪些组件应该置于 Enclave 内部，哪些置于 Enclave 外部，以及双方如何通信。对于复杂的应用，确定高效、合理且安全的划分方案本身就是一件颇具挑战的工作，更不要说实施划分所需的工程量。 被限定在某个编程语言：无论使用上述哪种 SDK 开发，一个开发者都将被限定在该 SDK 所支持的语言，这通常意味着 C/C++（当使用 Intel SGX SDK、Open Enclave SDK 或 Google Asylo 时），而无法使用 Java、Python、Go 等更加友好的编程语言。 只能获得很有限的功能：处于硬件限制和安全考虑，Enclave 中是无法直接访问 Enclave 外的（不可信）OS 的。由于 Enclave 中缺乏 OS 的支持，各种 SDK 只能提供普通不可信环境下的一个很小的功能子集，这使得很多现有的软件库或工具都无法在 Enclave 中运行。 上述困境使得为 SGX 开发应用成为一件十分痛苦的事，制约了 SGX 和机密计算的普及度和接受度。\n学会 Occlum 的“三板斧” Occlum 是一款蚂蚁集团开源的 TEE OS，可以大幅降低 SGX 应用的开发门槛。那到底多低呢？只需要学会 Occlum的三条命令：new、build和run。本节我们以利用 Occlum 在 SGX 中运行一个 Hello World 程序为例进行说明。\n这里有一个非常简单的 Hello World 程序。\n$ cat hello_world.c #include \u0026amp;lt;stdio.h\u0026amp;gt; int main() { printf(\u0026amp;quot;Hello World!\\n\u0026amp;quot;); return 0; } 首先，我们用 Occlum 提供的 GCC 工具链（occlum-gcc）编译这个程序，并验证它在 Linux 上能正常工作。\n$ occlum-gcc hello_world.c -o hello_world $ ./hello_world Hello World! 然后，我们为这个程序创建一个 Occlum 的实例目录（使用 occlum new 命令）。\n$ occlum new occlum_hello $ cd occlum_hello 该命令会创建一个名为 occlum_hello 的目录，并在该目录中准备一些必要的文件（如 Occlum.json 配置文件）子目录（如 image/）。\n接下来，我们基于刚刚编译好的 hello_world 制作一个 Occlum 的 Enclave 文件和可信镜像（使用 occlum build 命令）。\n$ cp ../hello_world image/bin $ occlum build 最后，我们在 SGX 中运行 hello_world（使用 occlum run 命令）。\n$ occlum run /bin/hello_world Hello World! 更复杂的程序也可以用类似上面的流程通过 Occlum 移植进 SGX 中。用户无需理解 SGX 的二分编程模型，无需或只需少量修改应用代码，还可以自由选择编程语言（比如 Java、Python、Go 等）。使用 Occlum，应用开发者可以将宝贵的精力集中在编写应用上，而非为 SGX 做应用移植。\n用起来像 Docker 的 TEE OS 在了解了 Occlum 的基本用法和体验之后，很自然地会好奇 Occlum 的技术原理：Occlum 的用户接口为什么这样设计？而简单接口背后的技术架构又是怎样的？本节就试图回答这些问题。\nOcclum 的一个设计理念是 Enclave-as-a-Container。在云原生时代，容器至关重要，容器无处不在。容器最常见的实现方式是基于 Linux 的 cgroup 和 namespace（比如 Docker），但也有基于虚拟化的实现（比如 Kata）。我们观察到，TEE 或者 Enclave 也可以作为一种容器的实现手段。因此，为了传达这种理念，同时给用户提供一种熟悉的体验，我们特意将 Occlum 的用户接口设计成与 Docker 和 OCI 标准接近。除了前面提到的 new、build和run 三个命令，Occlum 还提供 start、exec、stop、kill 等命令，其语意与 Docker 同 …","date":1597906800,"description":"本文分享如何使用 Occlum 的轻松开发机密计算应用以及 Occlum 技术架构和特色。","dir":"blog/sofa-channel-18-retrospect/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a1d55e5deb00aa8cde8d14f250569013","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-18-retrospect/","publishdate":"2020-08-20T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-channel-18-retrospect/","summary":"\u0026lt; SOFA:Channel/ \u0026gt;，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。 本文根据 SOFAChannel#18 直","tags":["Occlum","SOFAchannel"],"title":"人人都可以“机密计算”：Occlum 使用入门和技术揭秘 | SOFAChannel#18 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-18-retrospect/","wordcount":2939},{"author":"田晓旭","categories":"Kubernetes","content":" 随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。\n 根据 CNCF 2019 Kubernetes 使用调查报告的显示：目前 84% 的用户已经在生产环境中使用 Kubernetes，生产环境中容器部署规模超过 1000 的比例是 34%，其中超过 5000 的大规模应用比例是 19%。当集群越来越大、越来越复杂，集群可用性就会面临挑战。\n 整体指标：集群是否健康，所有组件是否正常工作，集群中 Pod 创建的失败数量有多少等等； 追踪能力：集群中发生了什么，是否有异常，用户做了什么事情等等； 原因定位：出现异常之后，找到是哪个组件出了问题； 想要解决这些问题，比较好的一个方法就是 SLO，通过定义 SLO 来描述集群的可用性，追踪集群中 Pod 的生命周期，一旦出现失败 Pod，快速定位异常组件。本文采访了蚂蚁集团技术专家范康和姚菁华来分享蚂蚁集团的 SLO 体系是如何建立的。\n大家常会听到 SLA，其实 SLA 是 SLO 衍生出来的协议，SLA 协议会形成具有法律效力的合同，通常是服务供应商和外部客户之间签订的，而 SLO 是用于内部服务之间，定义服务所提供功能的一种期望状态。\n1 SLO 指标定义 如果我们要通过定义来描述集群的可用性，那么具体的描述指标就成为了需要解决的关键问题。在蚂蚁 集团 内部，集群可用性的关键指标包含五个：集群健康度、Pod 创建成功率、残留 Terminating Pod 的数量、服务在线率和故障机数量。\n 集群健康度：通常使用 Healthy，Warning，Fatal 三个值来描述，其中 Warning 和 Fatal 对应告警体系，例如 P2 告警发生，那集群就是 Warning，而 P0 告警发生，那集群就是 Fatal，必须进行处理； Pod 创建成功率：这是一个非常重要的指标，蚂蚁集团一周的 Pod 创建量在百万级别，如果成功率波动会造成大量 Pod 失败，同时 Pod 成功率下跌也是集群异常的最直观反映； 残留 Terminating Pod 的数量：有人可能会好奇为什么使用残留 Terminating Pod 的数量，而不用删除成功率？这是因为当 Pod 数量达到百万级别后，即使删除成功率达到了 99.9%，Terminating Pod 的数量也有数千，残留这么多 Pod 占用应用容量，在生产环境中是不可接受的； 服务在线率：这个指标是通过探针来衡量的，探针失败则意味着集群不可用； 故障机数量：这是一个节点维度的指标，故障机通常是指无法正确交付 Pod 的物理机，集群故障机需要做到“快速发现，快速隔离，及时修复”，否则会对集群容量造成影响； 以上指标的阈值和 SLO 性能目标都是根据业务方的增长来定义的，随着业务的不断增长，这些指标的定义也可能需要跟着做调整。\n以 Pod 创建成功率为例，蚂蚁集团将 Pod 分为了普通 Pod 和 Job 类 Pob，普通 Pod 的 RestartPolicy 为 Never，Job 类 Pod 的 RestartPlicy 为 Never 或 OnFailure，两者都设定有交付时间，普通 Pod 的交付标准是 1min 内 Pod 已经 Ready；Job 类 Pod 的交付标准是 1min 内 Pod 的状态已达 Running、Succeeded 或 Failed。最开始 Pod 创建成功率的定义是成功创建的 Pod 和总 Pod 的比值，但是很快就发现在排查原因时，系统很难分辨，所以又将 Pod 失败原因调整成用户和系统两部分，创建成功率的定义就变成了创建成功的 Pod 和总的 Pod 减去用户失败 Pod 的比值。\n2 蚂蚁集团的 SLO 体系 确定好 SLO 各项关键指标的定义之后，接下来就是构建 SLO 体系。\n据范康介绍，蚂蚁集团 SLO 系统主要包括两个方面，一个方面用于向终端用户 / 运维人员展示当前集群各项指标状，另一方面是各个组件相互协作，分析当前集群状态，获取影响 SLO 的各项因素，为提升集群 pod 交付成功率提供数据支持。\n蚂蚁集团 SLO 体系架构图\n自顶向下而看，蚂蚁集团 SLO 的分层架构包括 SLO、Trace system、Increase of SLO、Target 和 The unhealthy node。\n其中，顶层组件主要面向各种指标数据，如集群健康状态、pod 创建、删除、升级成功率、残留 pods 数量、不健康节点数量等指标。其中 Display Board 是指监控大盘，可能不会实时查看，为避免错过处理紧急事件的最佳时机，同时构建了 Alert 告警子系统，支持配置多种告警方式；Analysis System 通过分析指标历史数据以及采集到的节点 metrics 和 master 组件指标，给出更详细的集群运营报告；Weekly Report 子系统给出当前集群本周 pod 创建 / 删除 / 升级的数据统计，以及失败案例原因汇总；Terminating Pods Number 给出一段时间内集群内新增的无法通过 Kubernetes 机制删除的 Pods 列表和 Pods 残留原因；Unhealthy Nodes 则给出一个周期内集群所有节点的总可用时间占比，每个节点的可用时间、运维记录、以及不能自动恢复，需要人工介入恢复的节点列表。\n为了支撑上述这些功能，蚂蚁集团还开发了 Trace System，用来分析展示单个 pod 创建 / 删除 / 升级失败的具体原因。其中包含日志和事件采集、数据分析、pod 生命周期展示三个模块。日志和事件采集模块采集各 master 组件以及节点组件的运行日志和 pod、node 事件，分别以 pod/node 为索引存储日志和事件；数据分析模块分析还原出 pod 生命周期中各阶段用时，判断 pod 失败原因，节点不可用原因。最后，由 Report 模块向终端用户暴露接口和 UI，向终端用户展示 pod 生命周期以及出错原因。\n3 经验总结 目前蚂蚁集团的 SLO 实践不仅提高了集群 pod 的交付成功率，同时通过构建 tracing 系统，分析到集群内 pod 交付关键链路的耗时，整理失败原因，实现了数据分析 / 诊断平台。对于如何实现高 SLO，范康也给出了自己的五点经验。\n 在提升成功率的进程中，SLO 治理团队面临最大的问题是镜像下载。Pod 必须在规定时间内交付，而镜像下载通常需要非常多的时间。所以，团队通过计算镜像下载时间，专门设置了一个 ImagePullCostTime 的错误，即镜像下载时间太长，导致 Pod 无法按时交付。另外，阿里镜像分发平台蜻蜓支持了 Image lazyload 技术，在 Kubelet 创建容器时，不用再下载镜像，大大加速了 Pod 的交付速度； 提升单个 Pod 成功率：随着成功率的提升，再提升的难度会越来越大，这是可以引入 workload 进行重试。蚂蚁集团内部的 PaaS 平台会不断重试，直到 Pod 成功交付或者超时。需要注意的是，重试时要先排除之前的失败节点； 检查关键 Daemonset： …","date":1597820400,"description":"随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。本文分享蚂蚁集团的 SLO 体系是如何建立的。","dir":"blog/antgroup-kubernetes-high-slo/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f15367978d8b820ec3fcddf3ab6d7779","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-kubernetes-high-slo/","publishdate":"2020-08-19T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/antgroup-kubernetes-high-slo/","summary":"随着 Kubernetes 逐渐成为云计算的标准，企业中的 Kubernetes 应用正成为主流。 根据 CNCF 2019 Kubernetes 使用调查报告的显示：目前 84% 的用户已经在生产环境中使用 Kubernetes，生","tags":["Kubernetes"],"title":"蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO？","type":"blog","url":"/sofastack.tech/blog/antgroup-kubernetes-high-slo/","wordcount":2530},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@陈亚兵 提问：\n 我想单独使用注册中心 SOFARegistry，可能的服务有 Java 和 Python，SOFARegistry 支持 Python 服务接口的注册吗？\n A：SOFARegistry 注册中心是支持各个语言的服务发现和订阅的，目前开源版中只有 Java client。实现其他语言的服务发现和订阅，需要自己实现相关语言的 Registry client。\n sofa-bolt-python 也有服务发现和发布，它和 sofa-registry 的发现有什么不同吗？\n A：sofa-bolt-python 只做了使用 MOSN 的服务接口的客户端。sofa-registry 是服务端。 SOFARegistry：https://github.com/sofastack/sofa-registry\n2、@刘明 提问：\n Seata 的 XA 模式做了一个压测，tps=1000，开始报错，ORA-24756：事务处理不存在。 看了下数据库global_table，状态是 3。 3 是 CommitRetrying ， 这说明 phase 1 阶段过了，2 阶段提交报事务不存在。 目前 global_table 里有700多条记录，95%是状态3，还有状态1的。\n A：应该是一个原因，很可能就是2阶段提交失败了。begin 的你查看下他的分支事务状态是什么。\n begin 的分支表里没有数据，可能注册就失败了。\n A：是的，有可能，TC 收到了，然后 TM 超时了，我建议你 1000tps 的测试，搞个 TC 集群，就一台可能撑不住。\n 我想在出错的时候，有个日志轨迹，可以知道数据目前是不是脏的？\n A：select for update 或者 update x=x+n 这样写法一般没事。\n 会不会锁住记录呢？\n A：不锁住怎么保证隔离性。这个 for update xa 没提交前会锁住的，这个锁由数据库方自己已经实现了。\n 是的，那1阶段已经过了，记录会一直锁在那里了吗？\n A：二阶段没提交，锁在数据库肯定没释放。不过看起来你应该提交了吧，因为已经提示你事务不存在了。\n 是的，事务提示不存在，但是数据没有提交。 我研究下。\n A：可以的，seata-xa 现在还不是特别完善，可以多研究下，发现问题可以提交 PR 来贡献，一起让 XA 更稳定更好。\n 并发情况下，事务已经提交，TCC 发起 global commit 请求超时导致了 commitRetry，因此事务不再存在，只是 TCC 会一直去重试。 这导致了性能下降很快，不断重复已经不存在事务的 commit 动作，使用 Oralce 测试下来耗时很大，MySQL 可能也不会更好。考虑在 RM 端做 xaCommit 的时候，引入一个 Redis 检查 xid 是否已经提交，已经提交返回提交成功。\n Seata：https://github.com/seata/seata\n本周推荐阅读 基于 RAFT 的生产级高性能 Java 实现 - SOFAJRaft 系列内容合辑 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？ SOFA 项目进展 本周发布详情如下：\n发布 SOFABoot v3.4.3 版本，主要变更如下：\n 新增 endpoint，支持展示启动耗时信息； 升级 Tomcat 版本，修复安全隐患 CVE-2020-11996； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.3\n社区活动报名 A2M 峰会旨在发现全球互联网领域在人工智能、大数据、互联网架构等领域的创新工程和杰出团队，整合国际最佳技术实践，构建行业案例研究智库，帮助中国企业在人工智能时代成功转型、升级。蚂蚁集团受邀进行云原生构建之路的专题分享。\n分享主题：Dubbo 基于 MOSN 在 Service Mesh 场景下的落地实践\n分享嘉宾：曹春晖 蚂蚁集团 可信原生技术部技术专家\n蚂蚁集团技术专家，对 Go 语言有深入的研究，《Go 语言高级编程》作者。在后端业务开发、数据平台等领域有多年的实践经验。目前正在领导 MOSN 社区进行 Dubbo 生态在 Service Mesh 场景下的落地工作。\n背景介绍：过去一段时间，云原生和 Service Mesh 大火。很多公司希望借着东风推动公司的微服务架构演进到下一阶段。然而在实践过程中不会事事如意，问题接踵而至。\n在使用 Dubbo 来做微服务框架的公司中，因为每个公司发展阶段不同，上云的进度不同，社区方案却要求必须要在完全上云之后才能沐浴 Service Mesh 的春风，这着实令人失望。\n解决思路：借助前人的落地经验，在 MOSN 与 Dubbo 结合的探索中，我们思考出一些可供处于不同上云阶段的公司参考的落地方案。经过对数据面的简单改造，在控制风险的前提下，能够渐进地将 Service Mesh 落地到公司内。\n成果：基于 MOSN 和 Dubbo-go，实现 Service Mesh 在 Dubbo 场景下的落地。\n听众收益：\n 了解落地 Service Mesh 对于整体架构的收益； 了解 MOSN 社区的发展现状和规划； 了解 Dubbo 在各种业务场景和上云发展阶段中如何优雅落地 Service Mesh； 分享时间：2020-09-05 16:50-17:50\n活动地点：上海\n活动报名：点击“这里”锁定席位\n","date":1597388400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200814/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"68d4b22d401ef51b62f39c8680895b36","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200814/","publishdate":"2020-08-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200814/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot 发布、SOFAJRaft 以及 SOFARPC 内容合辑、MOSN 活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200814/","wordcount":2113},{"author":"万佳","categories":"Kubernetes","content":" 在 Kubernetes 中，Secret 显得尤其重要。因为它是 K8s 中存储所有敏感信息的对象。据悉，这些敏感信息包含密码、集群的证书、OAuth token、ssh key 以及其他用户自定义的敏感文件等。因此，一旦 K8s 中 Secret 出现安全问题，后果将非常严重。此外，虽然社区提供了一定的安全防护方案，但是依然存在诸多问题。\nK8s Secret 面临着哪些安全问题？这些安全问题会带来什么影响？社区提供的解决方案存在哪些不足？\u0026amp;hellip;\u0026amp;hellip;针对这些问题，InfoQ 记者采访了蚂蚁集团高级工程师秦凯伦，他专注于可信计算、系统安全和虚拟化等领域，对 K8s Secret 有着深入的研究和探索。\nK8s Secret 的安全问题 根据 Kubernetes 文档，Secret 是 K8s 中存储所有敏感信息的对象。事实上，如果敏感信息直接存放于 K8s 的 Pod spec 或镜像中，不仅管控困难，而且存在较大的安全隐患。因此，K8s 通过创建、管理、应用 Secret 对象，可以更好地控制敏感信息的用途，并降低其意外暴露的风险。\n秦凯伦称，虽然引入 K8s Secret 对象，这在一定程度上降低了意外泄露的风险（更多地是通过集中式的管理），但是 K8s Secret 对象自身的安全性，“社区默认方案中仍存在许多安全问题”。\n一般来说，K8s 中，Secret 数据以纯文本的方式存储在 etcd 中，默认只有 base64 编码，未经加密。同时，共享该文件或将其检入代码库，密码容易泄露。\n社区解决方案的不足 针对此问题，K8s 社区提供了基于 KMS 的 K8s Secret 加密方案，谷歌云、AWS 和 Azure 均支持该方案。他说，“这虽然解决了 etcd 中 Secret 明文存储问题，但依然有一些问题。”\n Secret、加密 Secret 的密钥在内存中明文存放、易被攻破； 攻击者可以假冒合法用户，调用解密接口，窃取密钥； 密钥一旦泄露，将导致所有数据的泄露，从而引起用户对整个系统的信任崩溃。“为此，社区和一些公司尝试为该方案中的 Plugin 加上基于硬件的安全保护，从而提升攻击难度。但对某些特定用户来说，保护的覆盖面和程度依然不够”。\n实际上，我们可以从 K8s Secret 的整个生命周期来看：\n Secret 的生成及访问 Secret 的身份证书明文存放在用户侧内存中，用户侧环境复杂，容易被攻击者攻破； 加密 Secret 的密钥的生成、cache 等在 K8s API server 中明文存放在内存中，安全根易被窃取或破坏； 与 KMS 交互的 Plugin 的加解密接口无法防止攻击者假冒，存在泄漏风险； Secret 在 Node 中消费，依然明文内存存放，暴露出一定攻击面； 在秦凯伦看来，理想中，对 K8s 中 Secret 的保护程度应该考虑其整个生命周期的安全、可信，做到端到端的安全防护。\n蚂蚁集团的探索 为此，他们基于 TEE 技术，将 K8s Secret 整个生命周期和端到端使用过程中的关键组件、步骤保护起来。整体方案大致如下：\n 将 API Server 端与 KMS 交互的 KMS Plugin 用 TEE 保护，在保障了 Plugin 中根密钥（安全根）、数据加密密钥无泄漏风险的前提下，降低了性能开销； 将 API Server 端的 KMS provider 用 TEE 保护，避免数据密钥及 Secret 在任何时候明文直接暴露在内存中；同时，通过 TEE 的本地证明机制能够认证解密数据密钥接口的调用者，防止攻击者假冒，确保密钥的安全； 将用户端的 kubectl、kubeconfig 等使用 TEE 保护，一方面 kubeconfig 不落盘同时被硬件保护，提升了安全水位；另一方面，用户的 Secret 通过安全信道直通到 TEE 中进行处理，避免了直接暴露在内存中，规避了被恶意窃取的风险，且用户对 API Server 进行 TEE 远程证明，可以帮助用户确信他正在把自己的 Secret 托付给可信的软件实体（没有含有故意泄露用户秘密的恶意逻辑），建立对 API Server 的信任； 将 Node 端的 kubelet 中 Secret 的消费过程用 TEE 保护，进一步避免了 Secret直接暴露在内存中，规避了被恶意窃取的风险； 秦凯伦向 InfoQ 记者指出，“这种方案是基于 TEE 的端到端 K8s Secret 保护，还引入 LibOS 技术，实现 TEE 保护对用户、开发者和运维团队完全透明。”\n据悉，KMS Plugin 和 TEE-based KMS Plugin 没有标准和开源的社区实现，因此他们设计并开发了自己的 KMS Plugin，并在灰度发布、应急处理、监控管理等方面进行了生产增强。“在与 TEE 结合的过程中，我们为了应对 SGX 机型存在的性能问题，提供了 standalone 和服务化 KMS Plugin 两套方案”。\n同样，TEE-based kubectl 也没有标准和开源的社区实现，他说：“我们基于 kubeproxy 开发了自己的安全 kubectl，实现了 kubeconfig 对用户透明、与用户身份绑定、不落盘并采用TEE保护内存安全等设计目标。”\n此外，考虑到 TEE 保护的易用性、可靠性、可扩展性和可维护性等，他们在评估多套方案后，引入了由蚂蚁开源的 Occlum LibOS，屏蔽了 TEE 对用户、开发者和运维团队的影响，大大降低了 TEE 开发的门槛和成本。\n在秦凯伦看来，K8s 作为蚂蚁大规模容器集群的管控根基，应用基于 TEE 的端到端 K8s Secret 保护防护方案，增强了其自身安全和可信，提升了蚂蚁核心管控平面的安全水位，“这对于金融场景下高标准的数据安全和隐私保护来说不可或缺”。\nK8s 相关阅读 备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？ Kubernetes: 微内核的分布式操作系统 开箱即用的 Java Kubernetes Operator 运行时 深入Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统 深度 | 蚂蚁金服自动化运维大规模 Kubernetes 集群的实践之路 ","date":1597215600,"description":"K8s Secret 面临着哪些安全问题？这些安全问题会带来什么影响？社区提供的解决方案存在哪些不足？","dir":"blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"39e435e749635a88bce9e36771e5b2e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","publishdate":"2020-08-12T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","summary":"在 Kubernetes 中，Secret 显得尤其重要。因为它是 K8s 中存储所有敏感信息的对象。据悉，这些敏感信息包含密码、集群的证书、OAuth token、ssh key","tags":["Kubernetes"],"title":"蚂蚁是如何改进 K8s 集群敏感信息的安全防护的？","type":"blog","url":"/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/","wordcount":1958},{"author":"SOFA 团队","categories":"SOFAStack","content":" PS：阅读本文大约需要 15 分钟，或者您可以选择直接拉至文末投递简历，加入云上江湖。\n 有人说，历史是由懒汉推动的。\n科技的演进史，其实就是人类不断偷懒的过程。我们懒得浪费体力，于是有了蒸汽机；我们懒得动笔演算，于是有了电子计算机；我们懒得随身携带现钞，于是有了线上交易和无接触支付……程序和信息成为这个时代的基底，服务和应用围绕着我们的指尖打转。\n我们从网络上索取一切，海量的数据和代码在赛博空间里奔流不息。\n突然有一天，构筑代码世界的工人们也犯懒了。为首的“懒汉”开始思考，能不能把一些通用的代码模块打包起来，供给上层随时取用，这样就省下了重复“造轮子”的力气，让敲代码也成为一种模块化的工作？\n这一“偷懒”，就偷出了一个新概念：中间件。\n无人探索的道路 对普通人来说，“中间件”是一个很遥远的词汇。\n从技术层面来讲，中间件是介于基础设施和业务系统之间的特殊软件。程序员们别出心裁地构思了各种比喻：有人说它是建筑工地上的“预制件”，让工人不必从头开始搅拌水泥；有人说它是整合货源的“中间商”，让商家免于一次次询价比价的操劳……\n“基础设施和业务系统之间，有很多通信和集成方面的要求，让每个业务系统都去做一遍是很浪费人力的。”蚂蚁集团高级产品专家马振雄这么说，“大家都有这样的诉求。”\n时势造英雄，SOFAStack 在蚂蚁集团应运而生。\n它诞生得悄无声息，初衷只是为了“解救”支付宝。那还是青涩年代的支付宝，没有琳琅满目的蚂蚁森林、花呗和健康码，用4个“一”就能概括它的全部：一个简单的应用，装在一台应用服务器上，使用一个数据库，服务一个大客户——淘宝。\n简单、轻快、便捷，这个系统支撑了支付宝从2004年到2006年早期的发展。但是随着交易量的攀升、业务的复杂化，支付宝很快遭遇了成长中的阵痛。\n“从刚开始几十个人，后来几百人，到现在几千人的技术团队，在不同规模下的研发方式和组织方式都是不一样的。”蚂蚁集团高级技术专家黄挺说，“人一多，你发现不同的人写的代码会不一样，冲突也越来越多。”\n概而言之，研发效率出现了问题。\n如果说从前的支付宝是一间平房，如今则要发展成一座城市。而每搭建一座建筑，工人都必须从头开始烧制砖块、搅拌水泥——没有挖掘机，没有液压锤，一切从手无寸铁开始，对以“建设城市”为己任的团队来说，这是完全不可接受的。\n举个例子，当时支付宝的一个电子钱包系统 iWallet，每次启动需要五六分钟，足够开发人员下楼抽一支烟。如果发现错误，就得修改后重新启动，开发人员每天深陷在代码编译和重启的“死循环”之中。\n究其原因，就是因为 iWallet 系统包含了几十个工程，有十多个团队并行开发。支付宝原本的系统无法支撑这么复杂的业务逻辑，也难以让那么多工程师在一起并行工作，大家把它称为 monolithic——庞大的单体系统。\n支付宝的诉求显而易见：第一，希望成百上千个项目并行进行，每个工程师可以不受干扰地工作；第二，当业务逻辑增加的时候，系统的复杂度不要成指数级上升。 它需要一套能够力挽狂澜的“中间件”。\n2006年，契机来临。技术团队在这一年开了一连串的会，会议的核心议题只有一个：决定支付宝未来的技术架构。团队内部分成两派：第一派提议向银行老大哥学习，走集中式架构的老路；第二派则认为分布式架构才能支撑未来的交易支付系统，而且不是客户端/服务器时代那种小规模架构，是互联网时代的超大规模分布式架构。\n毫无疑问，这是一条无人探索过的道路。\n当然，你知道阿里人的秉性，退缩和守成从来不是他们的标签。经过长达一年左右的思考和论证，技术团队果断驶入第二条赛道。2007年起，支付宝率先启动了对交易系统、商户系统、会员系统、支付清算系统的改造，一个全新的架构正在孕育之中。\n这套分布式架构就叫“SOFA”。\n为什么叫这个名字？其一是源于当时正火的“SOA”概念，即 Service-Oriented Architecture，“面向服务的架构”，在此基础上加入金融业务，就构成了 SOFA 的全称：Service-Oriented Fabric Architecture。\n其二则是开发者的私心，“希望能够像沙发（Sofa）一样，让工程师可以非常爽地工作。” 从“连接器”到“工具库” 什么是 SOA？用偏技术的语言表述，就是把企业的 IT 系统以“服务”的方式重新组织，再通过“服务总线”连接起来，形成可插拔式的企业 IT 架构，这个架构就是 SOA。\n你或许觉得这个释义很难懂，没关系，因为在那个年代，SOA 纯粹只是一套面向传统企业 IT 架构的思想，换句话说，一套理论框架罢了。\n你问业界具体的成功实践？抱歉，没有。\n初次试水，蚂蚁的“探路者”们走得非常谨慎：第一代 SOFA 只解决两个问题，一是充当一个类似于“胶水”、“连接器”的机制，把分布式系统连接成整体；二是做到每一个服务组件化，让每个工程师专注做好各自的组件，最后把组件拼装在一起成为“服务”，再把“服务”拼装在一起组成整个系统。\n用黄挺的话来说，“SOFA 能够隔离出一些不同的模块，由不同的人去做开发，每个人有了更加细致的分工，不会跟别人出现太多的交叉。”\n第一代 SOFA 清晰地定义了团队之间的边界，何时分工协作，何时紧密联合，安排得明明白白。黄挺举了个例子：简单的一次转账业务，系统需要调用用户的通讯录，调用账务相关的子系统——可能还得去问银行，账户余额到底够不够？整个流程涉及到非常复杂的系统交互，这些由不同团队开发和运维的系统，怎样才能高效交互、稳定完成每一笔业务呢？这就仰赖 SOFA 从中协调和沟通了。\n燃眉之急解决了，但初生的分布式中间件 SOFA 并不能处理所有问题。它还需要打怪升级，积累经验，向下一代、再下一代演化。\n无人探索的道路上没有先驱者，只有野蛮生长的技术难题在横冲直撞。\n在 SOFA 的加持下，支付宝一边拆分金融业务系统（后来的业务中台）一边拆分底层 IT 系统（后来的数据中台和计算中台），在拆分过程中还要应对历年双十一的海量数据冲刷，以及不断涌现、千奇百怪的技术问题。甚至在解决分布式服务一致性问题时，由于业界提出的两个 SOA 事务标准都无法支撑支付宝核心系统的交易量，团队干脆一狠心一咬牙：现有的标准都不可行，要不我们自己提一个吧！\n逢山开路，遇水搭桥。很难说清 SOFA 这些年来的演进中，他们遭遇过多少类似的阻碍，又有多少奇思妙想和技术实践沉淀下来，最后凝练成 SOFA 内部的几行代码。\n他们在无人区设下哨塔，漫漫长夜被灯火点亮。\n第一代 SOFA，做到了模块化。\n第二代 SOFA，完成了服务化。\n第三代 SOFA 的亮点，则是被誉为“蚂蚁黑科技”的单元化，“异地多活”架构让服务器资源水平扩容的难度大大下降，保障了用户的每一笔订单平稳顺滑。团队坦诚，面向超大规模互联网金融交易的分布化改造，单元化这一技术构想完全是被业务倒逼的，业界没有先例可循。\n“我们找到过一些论文、一些概念，但以支付宝这么大的体量，没有人确定这事儿真的能做成。”团队成员感慨。\n就这样，随着支付宝架构的逐次优化，SOFA 也在不断迭代和成长。从最初仅是一个简单的框架，到后来强化通讯性能、提升容灾效率、建设异地容灾架构、单元化改造、添加 LDC 逻辑数据中心项目……SOFA 羽 …","date":1597042800,"description":"从初试锋芒到大展拳脚，从无人区的前哨到数字化转型的领航员，云上自有江湖，欢迎加入云上江湖","dir":"blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","fuzzywordcount":8900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dc1065f8e3a2e016a6fc8750bbfab2c2","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","publishdate":"2020-08-10T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","summary":"PS：阅读本文大约需要 15 分钟，或者您可以选择直接拉至文末投递简历，加入云上江湖。 有人说，历史是由懒汉推动的。 科技的演进史，其实就是人类不断偷","tags":["SOFAStack"],"title":"蚂蚁 SOFAStack：云上自有江湖","type":"blog","url":"/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/","wordcount":8849},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网：https://www.sofastack.tech SOFAStack：https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@丁浪 提问：\n 这个跟 TCP 长链接的心跳没根本区别啊！也只能保证链路上的通畅，应用僵死或者苟延残喘了可能发现不了，可以补充从注册中心去主动探测 URL，反正现在 SpringBoot 和 SOFABoot 应用都可以开启 healthcheck 的 endpoint，为啥不从注册中心发探测请求，反正都有 healthcheck 的 endpoint。链路上的保活那只是基本生存需求，稍微高级一点就不行了，应用僵死或者苟延残喘那种可能还有心跳的。我看你们把这个问题交给 RPC 框架去做了，让 RPC 框架去做故障剔除和容错。 A：SOFARegistry 目前设计是比较依赖网络连接的，网络连接只要出发了断链事件（这个目前监听是靠 Netty 的事件通知过来的）就会进行数据清理，这个敏感性也决定了服务发现比较快，但是对于抖动和其他大面积不稳定情况处理确实显得不足。我们说的 RPC 框架剔除是对于经常性的链接不通地址采取自动降级不进行调用处理，至于 Spring 那种心跳检测机制，我们开始实现也考虑过，因为这个健康检查机制和网络断连触发的敏感性差别较大，健康检是定期轮训的可能确定服务下线没有这么快速发现，所以没有采用，后续也想过兼容两种模式解决这个断链处理，引入类似 ZK 那种 Session 过期等机制可以在快速发现和稳定性做一个取舍。\n 那种应用进程僵死、较长时间 fullgc 之类的，长链接心跳还在注册中心发现不了流量过来就有问题的，RPC 框架的剔除机制我个人认为只能是种兜底降级。我目前是结合 K8s 探针去请求应用的 healthcheck 路径的，K8s 健康检查不通过就会杀进程重启 Pod，这样注册中心也会感知到 RPC 流量也就剔了。\n SOFARegistry：https://github.com/sofastack/sofa-registry\n2、@倪美俭 提问：\n 这是 AT 模式，store:db，rollback 的交互图，麻烦帮忙瞅瞅有问题吗？ A：是的，一阶段都是提交的，二阶段如果是回滚就会把之前的本地 commit 回滚掉。\n 这种场景是否要优化下，直接发起二阶段回滚，就不再进行这个本地事务一阶段的提交呢？这里为什么会进入到本地事务的 commit 方法里，而不是 rollback 方法里呢？\n A：这种你把本地的事务注解加到全局事务注解下面就好了，这样发起方所在的本地事务是直接走 rollback，其余参与方才是二阶段决议通知下来。\n 强一致性需求的场景，Seata 里只能用 XA，但 XA 是依赖数据库本身对 XA 协议的支持来实现的，那是不是这种模式下性能上会比 LCN 要逊色一些呢？\n A：首先 LCN 的原理是通过 connection 的代理，使之做空提交，二阶段决议后，把 hold 住的 connection 进行真正的 commit 或者 rollback，然而这个方式的隔离性交由本地事务来实现，因为 connection 未提交，所以事务还未提交，强依赖了本地事务。其次除非你的服务不会宕机，否则不建议你使用 LCN 模式，因为如果在二阶段决议后，宕机了一个参与者，那么 LCN 是无法恢复之前的数据，导致数据丢失。\n而 XA 你可以认为他跟 LCN 也很像，但是 LCN 面对的是数据源连接，而 XA 你会发现这个才是由数据库真正意义上去支持的一个协议，即使宕机了，Seata XA 也是做了 XA 的预提交，持久化提交数据在数据库层面，但未真正提交，从而可达到宕机后重启也可以提交事务。\n这是我做在 Seata 中 LCN 原理实现的 PR：https://github.com/seata/seata/pull/2772 ，你可以阅读下，很容易发现他的缺陷，LCN 的性能高是基于啥也基本没干，就多了个几个 RPC 通信的消耗，无需解析 SQL，做镜像校验，全局锁解锁等操作，他仅仅只是把本地事务的提交延迟到其余的参与者都完成了业务并且没发生异常的情况下。看过这个 PR 或者 LCN 的源码后，你就会真正的理解为什么 LCN 说自己不产生事务，而是事务的协调者而已。\n 去年看过 LCN 的源码，它也是代理了数据库连接，在一阶段会 hold 住所有的数据库连接，并不真正提交，二阶段会全部一起提交或回滚，那么有参与者宕机的话不应该会全部回滚吗？\n A：因为是基于本地连接的回滚，连接断开会自动回滚，所以即使二阶段决议形成提交时，若应用或网络出问题，连接断开就自动回滚了，不能保证极端一致性。 Seata：https://github.com/seata/seata\n本周推荐阅读 少年五年升阿里 P8，他如何从低谷登上“光明顶”？ 生产级高性能 Java RPC 框架 - SOFARPC 系列内容合辑 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.15.0 版本，主要变更如下：\n 新增 UDP Listener 的支持； 新增配置扩展能力，Dubbo 服务发现可通过扩展配置扩展，支持 Yaml 格式的配置解析； 新增流量镜像功能的扩展实现； 支持了更多路由配置； Skywalking 升级到 0.5.0 版本； 针对 Upstream 与 XProtocol 进行了优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.15.0\n同时，恭喜邓茜（@dengqian）成为 MOSN Committer，感谢她为 MOSN 社区所做的贡献。\n2、发布 SOFARPC v5.7.5 版本，主要变更如下：\n 修复日志打印的问题； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.5\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题： …","date":1596783600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200807/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3ae77ff6536d0104b38d51679b7f078b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200807/","publishdate":"2020-08-07T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200807/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN \u0026 SOFARPC 发布、MOSN 社区活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200807/","wordcount":2576},{"author":"陈伟荣","categories":"智能监控","content":" 电影《太空旅客》里，无人驾驶的阿瓦隆号飞船去往家园2号要经历120年，飞船的顺利抵达必须依赖一套高端智能运维系统。在蚂蚁，技术风险部的智能监控就好比那个智能运维系统，而智能监控团队便是背后那群看不见的守护飞船的人。\n 2019年双十一的凌晨三四点，阿里西溪园区附近的某家网咖里门客冷清，只有几个神色淡定的青年小伙聚在一排座位上愉快地进行 DOTA 游戏， 他们时不时看一眼手机上发来的消息，像是在守着什么不敢掉以轻心，但脸上又流露出胜券在握的信心。\n就在几个小时前，这群看似“不务正业”的网咖少年还坐在阿里双十一最核心的作战室“光明顶”，与阿里众大佬高管一起值班，助力双十一决胜千里。\n他们正是蚂蚁集团技术风险部智能监控团队。\n对于阿里人来说，“光明顶之战”为每年大促中的巅峰一战，能够登上“光明顶”的非泰山北斗即拥有超强武功的高手。作为该团队主力之一的陈伟荣说，光明顶上各路阿里大神、大佬汇聚一堂，每年的双十一就是智能监控团队的“高光时刻”。\n从象牙塔走向“光明顶” 在蚂蚁技术大事记上，智能监控团队于2012年就曾被留名：首次实现秒级交易监控。之后，他们每隔一段时间就会有技术突破。2014年至2016年期间，蚂蚁监控就用一套 xflush 系列产品成功走出蚂蚁实现与阿里集团监控团队的合作，为当时的淘系赋能。之后的 sunfire 监控、新一代阿里集团网络监控与 IDC 监控均是在此基础上迭代而来，并且沿用至今。\n这期间，一位青涩少年正从象牙塔走向阿里。他就是陈伟荣，2015年以应届毕业生身份加入阿里监控团队成为一名工程师。\n和很多刚毕业的同学一样，陈伟荣对互联网公司的技术体系并不熟悉，彼时他眼中的监控团队更像是一个运维工具组，日常工作就是服务器上看看日志，看看 CPU、内存指标，再做下数据展现就完事了。相较于消息中间件、数据中间件、虚拟化、块存储等各种基础技术团队相比，初入职场的陈伟荣偶尔也会觉得智能监控好像并没有那么高端大气上档次。因此才刚工作几个月，他就判定自己在监控团队肯定呆不了多久就会转岗。\n但是随着进一步深入工作领域，他发现大家工作对标的是各类流式计算，加之团队重视底层引擎研发，在对计算框架和时序存储研究一番后，陈伟荣意识到团队在做的事一点都不比其他基础技术团队简单：这是一个非常典型的垂直领域大数据应用，技术和业务上都非常具有相当挑战性。\n在技术层面上，实时、稳定、低成本、高精度都是对监控的要求，这些约束条件做到一点两点不难，但是要同时做到，极难。但陈伟荣所在的团队就是落地了这样一个高度稳定，秒级延迟，PB 级吞吐的监控平台，他透露后面团队还将重点发力算法和智能化能力。\n2016年发生了很多让陈伟荣迄今难忘的事，有一些事情的影响至今存留。\n那年支付宝新春红包登上了央视春晚，春晚直播屏幕前是全国人民一双双充满期待的眼睛。对于春节红包项目组的技术同学来说自然是严阵以待、不允许有丝毫差池。入职仅半年的陈伟荣有幸和团队其他精兵强将一起加入项目组，承担实时数据计算部分的任务，他主动提出要做项目内相对复杂的内存缓存部分研发。\n但代码写出来后陈伟荣被师兄狠狠痛批了。本来对于自己的技术和工作态度都很有信心的陈伟荣看到师兄一边改 bug 一边骂、一副恨铁不成钢的架势，心中的底气彻底被击碎。\n此后，少年卸下傲气，行路时步步夯实。\n2016年的双十一如约而至，这是陈伟荣在监控团队的第二年，面孔依旧很新，但是双十一活动却已经迎来了第八年。恰逢又一年的光明顶之战，团队却正好缺位，陈伟荣主动挺身而出，承担起阿里16年双十一监控系统稳定性负责人的角色。\n那次双十一，陈伟荣首次挑大梁，最终拼尽全力不负众望完成任务。双十一交易巅峰来临的那十几分钟也成为陈伟荣至今回忆起来最难忘的一段时间。据后来公布的数据了解到，2016年的双十一支付宝支付峰值已达到12万笔/秒，全天交易量达十亿，但是没有一笔交易异常。\n“平时研发中只要我认定这个事情从长期，或者更高视角看能帮助到团队和用户，我就愿意去做一些非常危险的，甚至短期都看不到收益的研发工作，”陈伟荣说。\n2017年，陈伟荣从阿里集团转到了蚂蚁集团，随后逐步切入工作，带领着蚂蚁技术风险部监控技术中台，负责数据的采集链路和实时计算的架构，并在此基础上构筑监控的数据服务体系。猛将加持，蚂蚁监控团队持续发力，2018年后，他们便结合自身的定位和业务目标，重新审视监控这个领域，又推出了 Antmonitor 系列的监控产品，现已发展到了2.0版本。 五年升P8，回首依然是少年 十年前，高考在陈伟荣生命里落下帷幕。只不过这场尽力准备了三年的考试，结果并不如意。\n高考成绩出来后陈伟荣大失所望，比正常发挥时几乎掉了一个层次，最后被南开大学德语专业录取，几乎等同于被调剂。高考后的暑假，难以接受打击的陈伟荣一度靠游戏度日。在复读和将就之间纠结了很久后，最终他决定向前看，并开始着手调研和规划大学的学习计划，为转专业作准备。\n高考失意，大学时奋起直追，陈伟荣通过各种努力走出了一条独特的发展道路：从文科的德语专业到软件工程专业，期间还修了金融学学位。\n毕业前的校招季，不少互联网公司开始招实习生，陈伟荣把简历投递给了阿里。但那时他心里更想走的是继续出国深造的路，所以当年投的简历更多是无心插柳之举。\n经过几轮紧张的现场面试后，没想到第二天阿里面试官就电话通知陈伟荣面试通过了。人生就是这样不可预料，同期报名的同学中仅他一个临时起意投递简历的被录取了。来了阿里后，陈伟荣一下子被阿里技术体系的先进性吸引了，实习转正后，他便决定不再继续读书直接工作了。\n他不知道自己本科拼命几年扭转的人生方向是否正确，只携一身热血前往，不回头。\n从2015年加入阿里开始，陈伟荣一直在监控领域做事，但是工作范围逐渐放大，从最初采集 agent 研发到逐步深入理解整个数链路、开始掌握数据技术架构，到现在能带领团队推进技术架构演进，他不断挑战自己的极限。\n五年时间弹指一挥间，说起过去，陈伟荣的回忆里酸甜苦辣翻涌。但要说最开心的时刻，他觉得是今年年初完成 pontus2.0 项目研发并最终上线支撑业务监控场景这个事。这次的技术升级突破了先前的监控技术框架，真正统一了监控数据层模型为未来数据建设铺平了道路，大家一起攻克艰难让项目按时落地，过程中的不易最后都变成了开心的回忆。\n团队里同事们年龄相仿，组队打篮球或者去网吧开黑打 DOTA 成为大家最放松的时刻，或嬉笑怒骂，或相互扶持，抛去工作上的对接合作与依赖关系，他们可以聊天南地北，聊海阔天空……\n最近，有一件事让 92 年的陈伟荣比较开心，那就是他专门定制的电吉他终于到货了。\n原来，这位少年还是一位重金属音乐爱好者。说着，他给我发来一个 Arch Enemy 在 2016 年 wacken 音乐节现场的视频链接，还提醒我要关小声音听。\n“我去过两次这个乐队在上海的 live，还跟主唱的那个妹子击过掌。”\n我眼前浮现这样一幅画面：“光明顶”少年与 Arch Enemy 歌曲中那些真实直白歌词达成了共识——人生也要“不断突破，向死而生”。\n","date":1596438000,"description":"坐在光明顶的少年。","dir":"blog/five-years-to-ali-p8/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"80f2d7c63c3dfb1ee561e79745630a68","permalink":"https://sofastack.github.io/sofastack.tech/blog/five-years-to-ali-p8/","publishdate":"2020-08-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/five-years-to-ali-p8/","summary":"电影《太空旅客》里，无人驾驶的阿瓦隆号飞船去往家园2号要经历120年，飞船的顺利抵达必须依赖一套高端智能运维系统。在蚂蚁，技术风险部的智能监","tags":["智能监控"],"title":"少年五年升阿里 P8，他如何从低谷登上“光明顶”？","type":"blog","url":"/sofastack.tech/blog/five-years-to-ali-p8/","wordcount":2786},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@刘明 提问\n 请问，分支事务在回滚过程中，服务器宕机了，重新启动后，TC 如果发送过来的回滚请求，是否还能继续回滚？\n A：可以。\n 是使用 XA 模式的 Oracle 数据库，分支服务器即使宕机了，回滚日志还在 Oracle 上是么？\n A：是的，xa_prepare 在 DB 实现 XA 层面做了持久化，MySQL 要求 5.7.7+。\n 刚测试了下 Oracle 的，xid 就像一个字符串 key 一样，任何时候只要告诉 Oracled 对 xid 做 rollback 都可以成功。我以为需要在 start/end 同一个连接里才行，是我理解错了。\n A：lcn 才需要这样，xa 不需要一个连接，所以 lcn 那种宕机了数据就没了。\n LCN 没有了解，他难道不是基于数据库自带的 XA 实现的？\n A：lcn 是 lcn 框架的一个原理，就是通过 connection 来统一提交和回滚。\n 我是用 jdbc 直接操作 Oracle 测试的，用 Oracle 的 XAResource。 这个特性是数据库自带的？\n A：XA 协议本来就是由数据库方进行的支持。\n 使用 DatabaseSessionManager 去存储 globalsession，这个 lockAndExecute 方法没有 lock 的逻辑，多个进程在获取 global 会话做超时、重试提交等时，会有资源冲突吗？\n A：多个 TC 会出现资源争抢冲突，倒是不影响一致性。\n 多个 TC 会对同一个 XID 做 retryCommitingg 操作吧，2个 TC 会做2次，3个 TC 会做3次？\n A：是的，没有分布式任务调度。\n 2个事务分支，TC 在发起提交请求后，分支一正常提交，分支二网络波动没有收到提交请求。 这个时候 TC 会尝试重试提交。 如果一直重试失败，会因为全局事务 timeout 发起回滚请求吗？\n A：提交一阶段就是持久化了，不会影响。\n 但是全局事务会有个超时检查，超时的事务处理方式就是回滚，会不会这样？分支二的提交重试一直不能成功，最后global 会话超时的吧？这时候分支一已经 commit，再做 rollback 肯定不行了。\n A：二阶段结果已经出现了，已经决议好了的，二阶段的提交只不过是空提交而已，异步的。\n 二阶段 TC 成功发送 commit，RM 接收到了后，执行 XA 提交动作，这时候数据才真正可以看到，如果 RM 接收不到 commit 请求，他本地数据时没有提交的吧？\n A：XA 模式确实是这样的。\n 那参与者中有人收到 commit 请求了，有人没收到，最后 global 超时，是不是也没法回滚了？\n A：XA 一阶段只是做了预备数据的持久化，保持操作，并没有真正入库，等到 commit 的时候才会入库，每个模式2阶段都不一样。 Seata：https://github.com/seata/seata\n本周推荐阅读 Kata Containers 2.0 的进击之路 Kata Containers 创始人：安全容器导论 Kata创始人王旭：远程工作可以从开源中借鉴哪些经验？ SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.4.2 版本，主要变更如下：\n 修复 ServiceComponent 和 ReferenceComponent 的健康检查结果不包含抛出的内部异常； 修复默认情况下 SOFA runtime 忽略组件抛出的内部异常； 增加引流操作的阻断性，fail fast； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.2\n2、发布 SOFAJRaft v1.3.4 版本，主要变更如下：\n 升级 SOFABolt 到 1.6.2（支持异步非阻塞建连机制）； 移除对 log4j 的直接依赖； RouteTable、RegionEngine、StoreEngine 实现 Describer 以提供更详细的调试信息； 修复 snapshot 文件创建漏洞，禁止跳出 snapshot 目录之外创建文件； 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.4\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题：云原生网络代理 MOSN 的进化之路 分享嘉宾：王发康（毅松）蚂蚁集团 可信原生技术部 技术专家 背景介绍：网络通信代理 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，增强 MOSN 服务治理及流量控制能力，对接云原生周边组件，实现 MOSN 开箱即用，MOSN 成为云原生 Service Mesh 的标准 Sidecar 之一，从而借力开源，反哺开源。 听众收益：可快速基于 MOSN 和 Istio 进行 Service Mesh 实践，了解微服务的发展历程、遇到的痛点以及解决方案，获取 MOSN 的功能特性，解决微服务常见的问题。 分享时间：2020-08-15 13:30-14:30 活动地点：深圳 活动报名：点击“这里” ","date":1596178800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200731/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ba067c1a03b386adff832962bb27dd52","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200731/","publishdate":"2020-07-31T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200731/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 以及 SOFABoot 发布、MOSN 社区活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200731/","wordcount":1941},{"author":"李昊阳","categories":"Kata Containers","content":" Kata Containers 开源项目于2017年底正式启动，其目标是将虚拟机（VM）的安全优势与容器的高速及可管理性相结合，为用户带来出色的容器解决方案。该项目在过去两年取得了哪些进展？下一版本的路线图包含什么特性？首先让我们快速回顾一下 Kata Containers 项目的奋进之路… 缘起：Kata Containers 2013 年，Docker 问世，容器成为热门新事物，全球的开发者为之着迷。也难怪，容器以标准格式封装，将运行于标准操作系统环境上的应用打包，使应用程序可从一个计算环境快速可靠的切换至另一个计算环境，这对于那些想要快速构建、测试和部署软件的开发者而言至关重要。容器具有轻量化、低开销的特性，几乎可以立即被调度和启动，可在任何环境中运行，为微服务提供便利，扩展资源等（以上仅列举了一些流行的优势）。 尽管有许多技术优势，但容器有一个缺点 - 容器与宿主机共享内核，这可能会引发严重的安全漏洞问题。理论上，如果您在单个主机上部署了多个容器，一旦其中某个容器被恶意代码利用，由于共享namespace，该主机上的其他所有容器也容易受到攻击，在这种情况下，可能会对云基础设施整体构成严重的安全威胁。如果您是云供应商，安全威胁可能会扩展到云端客户的数据和业务，这是绝对要避免的。\n图1. 传统容器：主要通过共享内核的 Cgroup 和 Namespace 来达到容器隔离和资源限制的目的\n因此，许多负责大规模容器运行的运维人员将容器“嵌套”在虚拟机中，从逻辑上将其与运行在同一主机上的其他进程隔离开，但在虚拟机中运行容器会丧失容器的速度和敏捷性优势。Intel 和 Hyper.sh（已加入蚂蚁集团）的开发人员意识到了这个问题，同时开始独立研发解决方案，两家公司都希望容器可以摆脱传统虚机的所有包袱，换言之，就是开发“面向云原生的虚拟化”技术：\n 来自 Intel 开源技术中心的工程师在 Intel Clear Containers 项目中运用 Intel Virtualization Technology（Intel VT）技术来强化性能和安全隔离； 与此同时，Hyper.sh 的工程师采用相似的策略启动了开源项目 runV，将容器放在一个安全“沙箱”中，通过支持多种 CPU 架构和管理程序，侧重于开发技术中立的解决方案； 2017年，两家公司将项目合并，互为补充，创建了开源项目 Kata Containers。Intel 和 Hyper.sh 联合开发者社区，希望在各方的共同努力下，兼顾性能和兼容性，在为终端用户提供出色应用体验的同时，加速开发新的功能特性以满足未来新兴用例的需求。Kata Containers 成为 OpenStack 基金会（OSF）除 OpenStack 之外的首个托管项目，该项目于2017年12月在北美 KubeCon 上正式公开亮相，社区座右铭是“快如容器，稳似虚机”。 其实质是，通过 Kata Containers 让每个容器/pod 采用其单独的内核，运行在一个轻量级的虚拟机中。由于每个容器/pod 现在都运行在专属虚拟机中，恶意代码无法再利用共享内核来访问邻近的容器，因此，容器即服务(CaaS)供应商能够更安全的提供在裸金属上运行容器的服务。由于容器之间的硬件隔离，Kata Containers 允许互不信任的租户，甚至生产应用及未经认证的生产应用程序都能在同一集群内安全运行。\n图2. Kata Containers: 每个容器/pod 被隔离在各自的轻量级虚拟机中\n因此，Kata Containers 与容器一样轻便快捷，并且可与容器生态系统无缝集成（包括流行的编排工具，如 Docker 和 Kubernetes），同时还具有虚拟机的安全优势。\n社区进展 Kata Containers 项目成立的第一年，社区主要致力于合并 Intel 及 Hyper.sh 的代码，并在全球的行业活动中介绍该项目独特的硬件隔离方案，这是其他容器运行时所缺乏的功能，同时也邀请了大量的社区开发者共同推进该项目。 Kata Containers 社区如今已经拥有众多的贡献者和支持者，包括来自九州云、阿里巴巴、AMD、AWS、百度、Canonical、中国移动、CityNetwork、戴尔易安信、易捷行云、烽火通信、谷歌、华为、IBM、微软、红帽、SUSE、腾讯、同方有云、中兴、英伟达、Mirantis、NetApp、PackageCloud、Packet、Vexxhost 等许多有影响力公司的开发者。随着社区的不断壮大，该项目正在稳步发展中。 社区成就包括：\n 加入开放容器倡议（OCI）规范，Kata Containers 社区持续与 OCI 和 Kubernetes 社区紧密合作，并在 AWS、Azure、GCP 和 OpenStack 公有云环境以及所有主要 Linux 发行版中对 Kata Containers 进行定期测试； 添加了对主要架构的支持，除 x86_64 外，还包括 AMD64，ARM，IBM p- 系列和 IBM z- 系列等架构； 无缝集成上游 Kubernetes 生态系统，Kata Containers 现在可以立即连接到大多数开箱即用的 Kubernetes 网络； 删除不必要的间接层，社区已经去掉了 kata-proxy 组件，并在 KubernetesSIG-Node 开发者和 containerd 社区的帮助下引入了 shim-v2，从而减少了 Kata Containers 辅助进程的数量； 降低开销，提升速度，社区正努力提升启动速度，减少内存消耗，并朝着创建（几乎）“零开销”沙箱技术的目标迈进。为此引入多个虚拟机管理程序，包括 QEMU，QEMU-lite，NEMU和AWSFirecracker。还与 containerd 项目整合，推动建立了 rust-vmm 项目，2019年，社区用 Rust 重写了一个沙箱内的 agent，显著减少了匿名页。总之，社区正通过一系列的改进工作来最大限度地减少开销，通过引入 FirecrackerVMM 将内存开销减少到 10MB，而通过 rust-agent 的合并将 agent 的匿名页从10MB减少到1.1MB； “面向云原生的虚拟化”，与面向虚拟机领域不同，容器领域是以应用为中心的，为了解决这种差异，社区引入了 virtio-vsock 和 virtio-fs，后续将引入更灵活的内存弹性技术virtio-mem； 如需详细了解项目进展，可查看王旭的系列博客：KataContainers: 两年而立 百度智能云的 Kata Containers 应用实践 百度，中国领先的搜索引擎运营商，全球最大的中文网站托管商，全球领先的 AI 公司-正在其百度智能云中大规模（超过 43k CPU 内核！）应用 Kata Containers，包括百度智能云函数计算（CFC）、百度智能云容器实例（BCI）、百度边缘计算等多种实践场景。 百度智能云是百度面向企业和开发人员的智能云计算平台，致力于为各行各业的企业提供一体化的人工智能、大数据和云计算服务。根据 Synergy Research Group 发布 …","date":1595919600,"description":"Kata Containers 项目的奋进之路","dir":"blog/kata-container-2.0-road-to-attack/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2eaaa668460266fb66b2b44f5611c472","permalink":"https://sofastack.github.io/sofastack.tech/blog/kata-container-2.0-road-to-attack/","publishdate":"2020-07-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/kata-container-2.0-road-to-attack/","summary":"Kata Containers 开源项目于2017年底正式启动，其目标是将虚拟机（VM）的安全优势与容器的高速及可管理性相结合，为用户带来出色的容器解决方案。该项目在过","tags":["Kata Containers"],"title":"Kata Containers 2.0 的进击之路","type":"blog","url":"/sofastack.tech/blog/kata-container-2.0-road-to-attack/","wordcount":4042},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网https://www.sofastack.tech SOFAStack:https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@Zhengguang 提问：\n 想问下，默认的 RMClient.init(applicationId, txServiceGroup); 这个方式启动 RM 的时候有个问题，它传递的 resourceId 为 null 也就是说 RM 初始化的时候虽然在 TC 注册了，但是注册的信并非之前断开始后那个 resourceId，所以 RM 重启后并不会立即收到来自 TC 的 retry。 以下是日志，可以看到默认 RM 初始化的时候 resourceIds 是空的： [timeoutChecker_2] INFO io.seata.core.rpc.netty.NettyPoolableFactory - NettyPool create channel to transactionRole:RMROLE,address:127.0.0.1:8091,msg:\u0026amp;lt; RegisterRMRequest{resourceIds=\u0026amp;lsquo;null\u0026amp;rsquo;, applicationId=\u0026amp;lsquo;api\u0026amp;rsquo;, transactionServiceGroup=\u0026amp;lsquo;my_test_tx_group\u0026amp;rsquo;} \u0026amp;gt;\n使用 API 方式，跑的是 seata-sample-api 这个 demo，AT 模式。\n A：1.其实 RMClient.init 的时候，并不会进行注册，真正进行注册的是初始化 DataSourceProxy的 时候。 2.如果注册的时候 resourceIds=\u0026amp;lsquo;null\u0026amp;rsquo;，很有可能你的 DataSourceProxy 没有初始化，也即是数据源没代理成功。\n 是的我观察到的就是这个现象，我这边项目更希望在 API 模式下使用 Seata，所以并没有通过 spring 启动，可能 DataSourceProxy 没有自动初始化，所以这里是不是应该有什么方式可以手动触发 DataSourceProxy 初始化的过程。\n A：手动配置一样就可以了，像这样子：\n\u0026amp;lt;bean id=\u0026amp;quot;dataSourceProxy\u0026amp;quot; class=\u0026amp;quot;io.seata.rm.datasource.DataSourceProxy\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;constructor-arg ref=\u0026amp;quot;dataSource\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; 哦哦，所以我要在 RMClient.init 启动后，马上手动获取一次 DataSourceProxy。Demo 中的这个 DataSourceUtil 要在第一次 getDataSource 的时候才会初始化 proxy，所以我要在 RMClient.init 启动后马上 get 一次数据源就好了， 测试通过。\n Seata：https://github.com/seata/seata\n本周推荐阅读 基于 MOSN 和 Istio Service Mesh 的服务治理实践 再启程，Service Mesh 前路虽长，尤可期许 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 云原生网络代理 MOSN 透明劫持技术解读 | 开源 SOFA 项目进展 本周发布详情如下：\n发布 SOFABolt v1.6.2 版本，主要变更如下：\n 支持检查连接并异步创建连接； 支持用户设置 UserProcessor 的 ClassLoader； 修复 URL 对象默认连接数为0导致不创建连接的问题； 修复无可用连接的 ConnectionPool 无法被回收的问题； 详细发布报告：https://github.com/sofastack/sofa-bolt/releases/tag/v1.6.2\n社区活动报名 机密计算（Confidential Computig）是近年来发展迅速的一种安全技术，它利用可信执行环境（TEE）——如 Intel SGX——来保证内存数据始终处于加密状态，因而将安全性提高到前所未有的程度，并赋能了诸多新型应用场景，比如多方联合数据分析、隐私保护的机器学习、保证机密性的区块链合约等等。虽然技术本身令人兴奋，但机密计算对应用开发者有比较高的门槛，令人望而却步。\n针对上面的问题，蚂蚁集团开源了 Occlum 项目，一款使用 Rust 语言开发的、面向机密计算的 TEE OS，可使得任何语言的任何应用程序轻松地移植进 TEE 环境。本次分享既会从用户角度介绍如何使用 Occlum 的轻松开发机密计算应用，也会从技术角度分享 Occlum 技术架构和特色。\nOcclum 网站：https://occlum.io\nOcclum Github：https://github.com/occlum/occlum\n本期主题：《SOFAChannel#18：零门槛的机密计算：Occlum LibOS 使用入门和技术揭秘》\n分享嘉宾：田洪亮（花名：樱桃） 蚂蚁集团技术专家 Occlum 开源负责人\n你将收获：\n 了解机密计算领域的最新进展； 了解 Occlum 的技术架构； 了解使用 Rust 语言开发安全软件的一手经验； 了解如何将创新工作转化为实用系统； 直播时间：2020-07-30 19:00-20:00\n报名方式：点击“这里”，即可报名\n","date":1595574000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200724/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6efe8af3dfb578bdfd495367e78b60e4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200724/","publishdate":"2020-07-24T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200724/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABolt 发布新版本、MOSN 相关文章整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200724/","wordcount":1603},{"author":"姚昌宇","categories":"Service Mesh","content":" Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。\n 本文根据7月22日晚 Service Mesh Webinar#2 有米科技高级后端工程师、MOSN Committer 姚昌宇，线上主题分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》整理，文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 大家好, 欢迎大家参加第二期 Service Mesh Webinar。本期的分享主题是《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。我是今天的分享嘉宾姚昌宇，来自有米科技，目前在公司也是负责服务治理相关的工作，我本身也是一名云原生爱好者，在空余时间关注和参与 Service Mesh 社区，最近参与了 MOSN 新版本的开发，也是有了很多收获。这次受社区邀请来给大家做这次分享，希望能给大家带来收获。\n今天的分享将从以下几个方面进行：\n 第一部分会简单介绍一下什么是 Service Mesh、Service Mesh 可以给我们带来什么红利以及我参与社区的过程和一些收获； 第二部分是这次分享的重点，我会从一个开发者的角度，说说如何基于 MOSN 和 Istio 去做服务治理，中间会包括 MOSN 源码的分析和 Istio 功能的实操，也是比较多 Service Mesh 爱好者关注的如何落地的问题，比如流量的控制啊、服务监控等等的功能； 第三部分会总结一下今天的分享以及 MOSN 一些近况和未来愿景的介绍； Service Mesh 简介以及社区共建实践分享 Service Mesh 简介 首先，什么是 Service Mesh 呢？相信这是众多爱好者刚接触 Service Mesh 时的最初疑问。Service Mesh 发展了这么多年，网上介绍和分析的文章也是很多，在这里我也再啰嗦一句。如果用一句话来概括 Service Mesh，我会说，它是一种微服务的通信方案，是不断演进而成的。\n大家都知道，服务端架构经历了一系列的演进，从最开始的单体服务到 SOA，再到微服务，服务间通信也从最开始的无需通信、到集成在代码里、再到胖客户端库，再演进为 Service Mesh 的 network stub 模式，又或者称为 sidecar 模式。\nService Mesh 主要解决了之前的服务间通信方案的几个问题：\n 语言绑定； 升级困难； 重复开发、标准不一； 语言绑定：在将服务治理逻辑抽离到 Sidecar 之前，这些治理逻辑需要集成在代码里面。这就容易导致业务要么要绑死在同一种开发语言上，要么就要相同的逻辑不同语言维护多份。这样既不灵活，维护起来成本也比较大。\n升级困难：企业里的基础设施团队，在升级服务治理逻辑之后，需要推动各个业务去重启他们的服务，这样一个周期通常会拖的非常长，重启过程也会有各种问题，导致线上各个版本的治理功能不一致，落地起来相当费劲。\n重复开发、标准不一：每个公司都会根据他们的实际情况落地微服务，有的会使用各个语言比较成熟的微服务框架，比如 Java 的 Spring Cloud、Dubbo；或者 Golang 的 go-micro 之类的框架。有的团队或者会使用集成组件的方式，在各个语言的基础上，加上一些成熟的服务治理组件，比如 Consul、Zookeeper、Hytrix、Vault 等。通常，通过对接这些组件来抽象出一个类似于微服务控制平面需要一定的开发成本，而且这些框架和组件标准也是不一致的，维护起来也会有不少成本。\n那么，Service Mesh 是如何解决这些问题的呢？\n首先，Service Mesh 架构将服务治理的逻辑抽离到一个单独的 Sidecar 进程中，而 Sidecar 进程是与语言无关的。Sidecar 通过代理的形式劫持业务进程的流量，从而做到与具体的业务开发语言解耦。\n其次，Sidecar 通过边车模式和业务进程部署在一起，但是又与业务进程分离。Sidecar 进程可以随时重启更新，业务进程无需感知这个过程。这样可以加速治理逻辑更新换代的过程，解决了传统服务治理，升级困难的问题。\n最后，Service Mesh 定义了控制面和数据面的概念。控制面提供 UI 给操作者去控制整个集群的流量，数据面，顾名思义就是数据流动的平面，负责接收这些配置信息，表现出对应的代理行为。控制面和数据面通过统一的协议进行通信，也就是 Service Mesh 里的 xDS 协议来交换配置信息。通过这样的方式，理论上实现了 xDS 协议的控制面/数据面可以互相插拔替换，这就统一了标准，解决了第三点重复开发和标准不一的问题。\n社区共建经历分享 那了这么多，那我是如何从关注 Service Mesh 社区，到参与到 MOSN 开源共建的呢？觉得整个过程可以概括成3点：\n 找到组织； 知识积累； 参与贡献； 其实一开始我也是一个初学者，刚接触到 Service Mesh 也会被一大堆不知名的名词砸得晕头转向的，像是 xDS、控制面、metrics tracing 之类的名词。所幸的是，ServiceMesher 的中文社区相当完善和活跃。我相信有了解过 Service mesh 的同学，肯定有加过2个微信 \u0026amp;ndash; 一个就是宋净超宋大的微信，一个就是 ServiceMesher 社区的微信群。也是得益于众多的前辈将 ServiceMesher 中文社区维护的这么好，将各种内部实践分享出去，以及外部一手资讯搬运甚至翻译过来，乃至是这样子的不定期的线上线下分享。这些都是非常好的资源。只要你想去学，就肯定有方法的。而对于新人的疑问，社区里的大神们也是非常乐意解答。\n既然有了目标和资源，那就差去做了。接下来我通过不断的去理解这些新领域的概念，理解它们的含义和背后的设计目的以及应用场景，再加上源码分析和动手实践，慢慢也就搭建起了整个关于 Service Mesh 的知识体系。\n在摸清门道之后，其实参与开发也不是什么难事了。那为什么我会选择 MOSN 呢？其实蚂蚁集团有整个 SOFAStack，也就是金融级云原生架构的开源共建计划，其中有服务注册、流量跟踪、rpc 协议、分布式事务等等的项目。我选择 MOSN 主要是有两点考虑：\n 第一是 MOSN 是使用 Golang 实现的，这一点和个人的技术栈比较吻合； 那第二点，我认为 Sidecar 在 Mesh 的位置是比较关键的。在大型的集群里，上百万的 Sidecar 在集群里互相通信，为业务进程转发处理数据包，其稳定性、性能要求和灵活性都是比较高的； 近期我也参与到了 MOSN 的 Istio Roadmap 开发中，主要目标是将 MOSN无 缝地接入到 Istio 里，成为在里面可以工作的 Sidecar。我主要做的几个功能是pilot-agent 的适配以及一致性哈希负载均衡功能的开发。其实和做业务需求是类似的，首先要知道功能要达到什么目的，然后预演改动的地方，最后实践：fork 一份 MOSN、开发 …","date":1595498400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/mosn-istio-service-mesh/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"03b066886bc7e069eca5654ee35e4782","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-istio-service-mesh/","publishdate":"2020-07-23T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/mosn-istio-service-mesh/","summary":"Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。 本文根据7月22日晚 Service Mesh Webinar#2 有米科技高级后端","tags":["Service Mesh","MOSN"],"title":"基于 MOSN 和 Istio Service Mesh 的服务治理实践","type":"blog","url":"/sofastack.tech/blog/mosn-istio-service-mesh/","wordcount":4565},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@古月 提问：\n 请问 SOFARPC 可以在 Spring MVC 环境 XML 配置使用?老项目 ssm，非 Spring Boot 环境。\n A：可以的。和直接用 SOFARPC 没区别。 SOFARPC 相关 Demo：https://www.sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@伍月 提问：\n 工程使用 OperatingSystemMXBean（osBean）类对系统 CPU 情况进行监控。 osBean.getSystemCpuLoad() = -1 ？？？ osBean.getProcessCpuLoad() = -1 ？？？ 有没有人知道是怎么回事。 注：正常情况下 CPU 返回值在 0 到 1 之间。\n A：抛出异常的时候会返回 -1，之前记得 arthas 也会返回 -1。\n 感谢回答。 工程在 Linux 服务器上运行时获取 CPU 数据正常。只是在本地 Windows 上运行时获取 CPU 数据返回 -1。后来百度得知可能由于本地 Windows 用户没有获取系统 CPU 数据的权限。\n Seata：https://github.com/seata/seata\n本周推荐阅读 我们需要什么样的端到端 AI 系统？蚂蚁 SQLFlow 的思考与答案 火了 2 年的服务网格究竟给微服务带来了什么？ Kubernetes: 微内核的分布式操作系统 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.7.4版本，主要变更如下：\n 允许用户设置 Triple 服务的版本； protobuf 编译器升级到 0.0.2； hibernate-validator 升级到 5.3.5.Final； jackson-databind 升级到 2.9.10.5； 修复了 Hessian over triple 不支持基本类型的问题； 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.4\n2、发布 Seata v1.3.0 版本，主要变更如下：\n AT 模式支持了像多主键，自动升降级，redis 存储等大量 feature； TCC 模式支持了模式支持 Dubbo 和 SOFARPC 注解调用； Saga 模式支持 Groovy 脚本任务、支持 jackson 序列化、代码重构将内部扩展点 SPI 化； 整体性能得到大幅度提升，修复了旧版本的存量 bug； 本次 release 变动文件数：442，代码变动：+17062 −8419，参与代码 commit 人数：31，合并 PR 数：90，其中：feature：20，bugfix：29，代码优化重构：41； 详细发布报告：https://github.com/seata/seata/releases/tag/v1.3.0\n社区活动报名 Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#2，邀请有米科技高级后端工程师姚昌宇，带来分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。本期分享可以收获对 Service Mesh 技术以及如何落地有更多的认识。\n分享主题：基于 MOSN 和 Istio Service Mesh 的服务治理实践\n分享嘉宾：姚昌宇 有米科技高级后端工程师、MOSN committer\n你将收获：\n 了解如何参与到 MOSN 开源社区共建中； 了解如何使用 MOSN 在 Istio 场景下的服务治理实践 ; 了解 MOSN 新版本的功能以及未来远景； 结合 Istio 各个场景的 Demo，分享 MSON 的多协议/私有协议实现； 直播时间：2020-07-22 20:00-21:00\n直播间地址：关注直播间，7月22日不见不散\n","date":1594969200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200717/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"54ea1b69911fe82c9674739a421a0ce5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200717/","publishdate":"2020-07-17T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200717/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARPC、Seata 组件发布以及社区 QA 整理、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200717/","wordcount":1475},{"author":"沈凋墨","categories":"Kubernetes","content":" 如今，Kubernetes 已经成为分布式集群管理系统和公有云/私有云的事实标准。实际上，Kubernetes 是一个分布式操作系统，它是 Google 在分布式操作系统领域十余年工程经验和智慧的结晶，而 Google 一直以来都管理着世界上最大的分布式集群，在分布式操作系统领域的研究和认识领先于全世界。因此，2014年发布的 Kubernetes 能在短短几年时间内就超越了诸多前辈，大获成功。\n作为分布式操作系统，Kubernetes（包括其前代产品 Google Borg）的出现远远晚于 UNIX、Linux、Windows 等著名的单机操作系统，Kubernetes 架构设计自然地继承了很多单机操作系统的珍贵遗产，微内核架构就是这些遗产中最重要的一份。在本文接下来的部分，我们将专注于微内核（microkernel）这个概念及其对 Kubernetes 架构的影响。\n什么是微内核？ 在介绍微内核的时候，我们有必要同时回顾一下单机操作系统的历史，以理解其价值所在。本章中以「操作系统」指代「单机操作系统」。\nUNIX 的兴起 电子计算机诞生之后，在上个世纪70年代以前，出现过许许多多的操作系统，DOS、OS/360、Multics 是其中的知名代表，这是操作系统领域的拓荒时代。20年来的拓荒孕育出了伟大的成果：随着 CPU 技术的发展，UNIX 于1969年诞生了，这是一个真正意义上的分时操作系统。\n图片来源：维基百科\n借助新的 CPU 技术的支持，UNIX 将软件系统划分为内核（kernel）和用户态程序（userland programs）两部分。内核是一组中断处理程序的集合，把硬件的能力封装为操作系统功能调用（system calls），用户态程序通过系统调用使用硬件功能，用户态程序运行于各自的进程中，所有用户态进程都共享同一个内核，每当系统调用或中断发生，UNIX 便陷入（trap）内核，内核执行系统调用，与此同时，内核中的分时调度算法将决定把 CPU 交给哪个进程，并管理进程的上下文切换。另外，UNIX 把（几乎）所有硬件都封装为文件。UNIX 还提供了一个特殊的用户态程序 shell，供用户直接使用系统，通过内核提供的进程间通信能力，shell让 用户可以把一系列应用程序组合起来，处理复杂的需求，作者称这个设计思想为「KISS」（Keep It Simple and Stupld）。UNIX 的所有设计思想在当时是都是非常了不起的创举。\nUNIX 不但自身对业界产生了巨大的直接贡献，还成为所有现代操作系统的蓝本，两位作者 Ken Tompson 和 Dennis Ritchie 因此荣获1983年度的图灵奖。\nUNIX 诞生于贝尔实验室，该实验室属于美国国家电信电报公司（AT\u0026amp;amp;T），见识到 UNIX 的强大威力之后，AT\u0026amp;amp;T 做出了一个看似无私的决定：将 UNIX 开源（初期只对大学开源），这使得所有现代操作系统得以诞生。虽然 AT\u0026amp;amp;T 最终被分拆，辉煌不再，但这个决定对人们的贡献绵延至今。在21世纪20年代的今天，无论是 MacOS、Windows、Linux，都直接受到 UNIX 的影响，而 iOS 来自 MacOS，Android 来自 Linux，因此 UNIX 的灵魂仍然活在每个人的手机中、活在每个手机 App 后台的服务中。\n此外，UNIX 诞生之时，还附送了一项比操作系统本身价值更大的副产品：Dennis Ritchie 为开发 UNIX 设计了C语言，C语言成为了所有流行的现代编程语言的主要设计来源，不仅如此，C语言在其诞生近40年后的今天，仍然是最重要的编程语言之一。\n值得一提的是，当时 UNIX 的主要开放对象是伯克利、卡内基梅隆等研究型大学，文理学院规模较小，没有研究生项目，不属于 AT\u0026amp;amp;T 的主要开放目标，因此 Olivet College 毕业的一位小哥未受到 UNIX 思潮的影响。这位名叫 David Cutler 的软件天才于1975年在 DEC 设计了 VMS 操作系统，VMS 和最初的 UNIX 一样，运行在 PDP-11 上，但并不是基于 UNIX，而是独立设计的。VMS 在业界没有掀起大浪，以兼容 UNIX 告终。后来 David Cutler 离开 DEC，加入微软，在那里谱写了属于他自己的传奇。有趣的是，乔布斯也曾在文理学院就读，看来美国文理学院的学生是不走寻常路的。\n微内核的兴起 UNIX「一切皆文件」的设计带来了用户程序设计的很多便利，但它要求所有对硬件的封装都要在内核态，因此内核中模块的 bug 会让整个系统受到影响，比如说，如果某个设备驱动有内存泄漏，所有使用该设备的用户态进程都会有内存泄漏，如果某个内核模块有安全漏洞，整个系统的安全性将不再可控。\n为了解决这类问题，上个世纪70年代，操作系统研究者们开始发展「微内核」的概念，微内核的本质是让操作系统的内核态只保留内存地址管理、线程管理和进程间通讯（IPC）这些基本功能，而把其它功能如文件系统、设备驱动、网络协议栈、GUI 系统等都作为单独的服务，这类服务一般是单独的用户态 daemon 进程。\n用户态应用程序通过 IPC 访问这些服务，从而访问操作系统的全部功能，如此一来，需要陷入内核的系统调用数量将大大减少，系统的模块化更加清晰。同时系统更加健壮，只有内核中的少量系统调用才有权限访问硬件的全部能力，如设备驱动的问题只会影响对应服务，而不是影响整个系统。和 micro kernel 相对，UNIX 的设计被称为 monolithic kernel。\nUNIX 开放后，AT\u0026amp;amp;T 继续着版本迭代，而各大学基于 AT\u0026amp;amp;T 的 UNIX 开发了很多新的操作系统内核，其中较为知名的有：\n BSD，monolithic，由伯克利的传奇人物 Bill Joy 于1974年发布（据说 Bill Joy 花三天便完成了 BSD 内核的第一个版本开发，Bill Joy 的作品还包含第一个 TCP/IP 协议栈、vi、Solaris、SPARK 芯片等等）。该内核对业界影响非常之大，后来发展为 FreeBSD、OpenBSD、NetBSD 等分支。现代操作系统如 Solaris、MacOS X、Windows NT 对其多有借鉴。 Mach，微内核，由卡内基梅隆大学于1984年发布，主要作者是 CMU 的两位研究生 Avie Tevanian 和 Rick Rashid。该内核对业界影响也很大，GNU Hurd、MacOS X 对其多有借鉴，但该项目本身以失败告终。 MINIX，微内核，由阿姆斯特丹自由大学（Vrije Universiteit Amsterdam）的 Andrew Tanenbaum 教授于1987年发布。无数计算机系学生通过 MINIX 及其配套教材掌握了操作系统的设计原理，Linux 的初始版本就是基于 MINIX 复刻的。MINIX 虽然著名，但主要用于教学，从未在工业界获得一席之地。 微内核的沉寂 从上世纪90年代至本世纪10年代，UNIX 和 VMS 的后裔们展开了一场混战，从结果来看，微内核的概念虽然美好，但现实非常 …","date":1594882800,"description":"本文将专注于微内核（microkernel）这个概念及其对 Kubernetes 架构的影响分享。","dir":"blog/microkernel-distributed-operating-system-kubernetes/","fuzzywordcount":7100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9fc5956b0fc0551dfdcf50df35ee8a84","permalink":"https://sofastack.github.io/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","publishdate":"2020-07-16T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","summary":"如今，Kubernetes 已经成为分布式集群管理系统和公有云/私有云的事实标准。实际上，Kubernetes 是一个分布式操作系统，它是 Google 在分","tags":["Kubernetes"],"title":"Kubernetes: 微内核的分布式操作系统","type":"blog","url":"/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/","wordcount":7097},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践\n 活动时间：7 月 22 日周四晚 8 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 Service Mesh Webinar Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#2 Service Mesh Webinar#2，邀请有米科技高级后端工程师姚昌宇，带来分享《基于 MOSN 和 Istio Service Mesh 的服务治理实践》。\n本期嘉宾将为大家分享从关注 ServiceMesher 社区，到参与 MOSN 开源共建的心路历程，包括 Service Mesh 技术的相关介绍、如何参与社区共建以及如何将 MOSN 结合 Istio 根据实际场景落地的示范。本期分享可以使你对 Service Mesh 技术，以及如何落地有更多的认识。\n分享主题：\n《基于 MOSN 和 Istio Service Mesh 的服务治理实践》\n分享嘉宾：\n姚昌宇 有米科技高级后端工程师、MOSN committer。多年后端开发经验、云原生爱好者。目前负责公司内部数据和算法能力接口的服务治理相关的开发工作，2018年起关注并参与 ServiceMesher 社区发起的各种活动，近期参与 MOSN v0.14.0 版本功能的开发。\n直播时间：2020年5月28日（周四）20:00-21:00\n大纲：\n Service Mesh 带来的红利 参与 MOSN 开源共建给我带来的收获 如何参与 MOSN 开源共建 找到组织：进入 MOSN 开发者群 熟悉 MOSN \u0026amp;amp; 搭建本地调试环境：现场演示（http、grpc 服务流量控制演示，指标收集，请求跟踪演示） 发现优化点/参与 Roadmap 感悟总结，以及 MOSN 近况\u0026amp;amp;未来远景介绍 用户收获：\n 了解如何参与到 MOSN 开源社区共建中； 了解如何使用 MOSN 在 Istio 场景下的服务治理实践 ; 了解 MOSN 新版本的功能以及未来远景； 结合 Istio 各个场景的 Demo，分享 MSON 的多协议/私有协议实现； ","date":1594710000,"description":"7 月 22 日周四晚 8 点，Service Mesh Webinar#2 线上直播。","dir":"activities/service-mesh-webinar-2/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"856529bdb9666c8bad4c59a80444662f","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-webinar-2/","publishdate":"2020-07-14T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-webinar-2/","summary":"概要 活动主题：Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践 活动时间：7 月 22 日周四晚 8 点 活动形式：线上直播 报名方式：戳这里","tags":["MOSN","Service Mesh Webinar"],"title":"Service Mesh Webinar#2：基于 MOSN 和 Istio Service Mesh 的服务治理实践","type":"activities","url":"/sofastack.tech/activities/service-mesh-webinar-2/","wordcount":657},{"author":"罗广明","categories":"Service Mesh","content":" 本文节选自 ServiceMesher 社区出品的开源电子书《Istio Handbook——Istio 服务网格进阶实战》，作者罗广明，来自百度。\n 在过去几年中，微服务成为了业界技术热点，大量的互联网公司都在使用微服务架构，也有很多传统企业开始实践互联网技术转型，基本上也是以微服务和容器为核心。本文将主要介绍微服务架构的概述以及云原生环境下的 Service Mesh 和传统微服务应用的区别。\n微服务架构概述 微服务架构可谓是当前软件开发领域的技术热点，在各种博客、社交媒体和会议演讲上的出镜率非常之高，无论是做基础架构还是做业务系统的工程师，对微服务都相当关注，而这个现象与热度到目前为止，已经持续了近 5 年之久。\n尤其是近些年来，微服务架构逐渐发展成熟，从最初的星星之火到现在的大规模落地与实践，几乎已经成为分布式环境下的首选架构。微服务成为时下技术热点，大量互联网公司都在做微服务架构的落地和推广。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。\n而在这个技术转型中，国内有一个趋势，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。然而软件开发没有银弹，基于这些传统微服务框架构建的应用系统在享受其优势的同时，痛点也越加明显。这些痛点包括但不限于以下几点：\n 侵入性强。想要集成 SDK 的能力，除了需要添加相关依赖，往往还需要在业务代码中增加一部分的代码、或注解、或配置；业务代码与治理层代码界限不清晰。 升级成本高。每次升级都需要业务应用修改 SDK 版本，重新进行功能回归测试，并且对每一台机器进行部署上线，而这对于业务方来说，与业务的快速迭代开发是有冲突的，大多不愿意停下来做这些与业务目标不太相关的事情。 版本碎片化严重。由于升级成本高，而中间件却不会停止向前发展的步伐，久而久之，就会导致线上不同服务引用的 SDK 版本不统一、能力参差不齐，造成很难统一治理。 中间件演变困难。由于版本碎片化严重，导致中间件向前演进的过程中就需要在代码中兼容各种各样的老版本逻辑，带着 “枷锁” 前行，无法实现快速迭代。 内容多、门槛高。Spring Cloud 被称为微服务治理的全家桶，包含大大小小几十个组件，内容相当之多，往往需要几年时间去熟悉其中的关键组件。而要想使用 Spring Cloud 作为完整的治理框架，则需要深入了解其中原理与实现，否则遇到问题还是很难定位。 治理功能不全。不同于 RPC 框架，Spring Cloud 作为治理全家桶的典型，也不是万能的，诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。而这些功能往往是企业大规模落地不可获缺的功能，因此公司往往还需要投入其它人力进行相关功能的自研或者调研其它组件作为补充。 以上列出了传统微服务框架的局限性，但这并不意味着它们就一无是处了。在中小企业，采用 Spring Cloud 这样的传统微服务框架已经可以满足绝大部分服务治理的需求，并且借此快速推进微服务化改造。这些痛点往往是技术发展到一定的程度必然要经历的阶段，这些痛点促使技术不断发展、不断前进。\n在众多热门技术趋势中，云原生的关注度居高不下，很多开发者都对由此兴起的一众技术十分追捧，众多企业又开始探索云原生架构的转型与落地。这一年，中国的开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变。而 Service Mesh 技术也因此越来越火热，受到越来越多开发者的关注，并拥有了大批拥趸。那么 Service Mesh 是什么呢？它为什么会受到开发者的关注？它和传统微服务应用有什么区别？\nService Mesh 定义 Service Mesh 一词最早由开发 Linkerd 的 Buoyant 公司提出，并于 2016 年 9 月29 日第一次公开使用了这一术语。William Morgan，Buoyant CEO，对 Service Mesh 这一概念定义如下：\n A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.\n 翻译成中文如下：\nService Mesh 是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。\n以上这段话有四个关键点：\n 本质：基础设施层； 功能：请求分发； 部署形式：网络代理； 特点：透明； 2017 年，随着 Linkerd 的传入，Service Mesh 进入国内社区的视野，并且由国内的技术布道师们翻译成“服务网格”。\n服务网格概述 服务网格从总体架构上来讲比较简单，不过是一堆紧挨着各项服务的用户代理，外加一组任务管理流程组成。代理在服务网格中被称为数据层或数据平面（data plane），管理流程被称为控制层或控制平面（control plane）。数据层截获不同服务之间的调用并对其进行“处理”；控制层协调代理的行为，并为运维人员提供 API，用来操控和测量整个网络。\n更进一步地说，服务网格是一个专用的基础设施层，旨在“在微服务架构中实现可靠、快速和安全的服务间调用”。它不是一个“服务”的网格，而是一个“代理”的网格，服务可以插入这个代理，从而使网络抽象化。在典型的服务网格中，这些代理作为一个 sidecar（边车）被注入到每个服务部署中。服务不直接通过网络调用服务，而是调用它们本地的 sidecar 代理，而 sidecar 代理又代表服务管理请求，从而封装了服务间通信的复杂性。相互连接的 sidecar 代理集实现了所谓的数据平面，这与用于配置代理和收集指标的服务网格组件（控制平面）形成对比。\n总而言之，Service Mesh 的基础设施层主要分为两部分：控制平面与数据平面。当前流行的两款开源服务网格 Istio 和 Linkerd 实际上都是这种构造。\n控制平面的特点：\n 不直接解析数据包。 与控制平面中的代理通信，下发策略和配置。 负责网络行为的可视化。 通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。 数据平面的特点：\n 通常是按照无状态目标设计的，但实际上为了提高流量转发性能， …","date":1594710000,"description":"本文将主要介绍微服务架构的概述以及云原生环境下的 Service Mesh 和传统微服务应用的区别。","dir":"blog/microservices-service-mesh/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f6d713862b049df801c82f5c52ec6ed1","permalink":"https://sofastack.github.io/sofastack.tech/blog/microservices-service-mesh/","publishdate":"2020-07-14T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/microservices-service-mesh/","summary":"本文节选自 ServiceMesher 社区出品的开源电子书《Istio Handbook——Istio 服务网格进阶实战》，作者罗广明，来自百度。 在过去几年中，微服务成为","tags":["Service Mesh"],"title":"火了 2 年的服务网格究竟给微服务带来了什么？","type":"blog","url":"/sofastack.tech/blog/microservices-service-mesh/","wordcount":5219},{"author":"SOFA 团队","categories":"SQLFlow","content":" 端到端机器学习是一种由输入端的数据直接得到输出端结果的AI系统，它可以对业务人员屏蔽复杂技术细节，同时给模型以更多自动调节空间，增加模型整体契合度。近两年来，端到端机器学习成为 AI 领域研发热点，蚂蚁集团于2019年5月发布端到端 AI 系统 SQLFlow 开源项目，受到业界广泛关注。今天，就让我们来看看它对端到端 AI 的思考与解答。\n SQLFlow 是蚂蚁集团开源的使用 SQL 完成 AI 工作流构建的编译系统。SQLFlow 将多种数据库系统（MySQL, Hive, MaxCompute）和多种机器学习引擎（Tensorflow, Keras, XGBoost）连接起来，将 SQL 程序编译成可以分布式执行的工作流，完成从数据的抽取，预处理，模型训练，评估，预测，模型解释，运筹规划等工作流的构建。\n接下来我们会根据以下内容逐步介绍 SQLFlow：\n 为什么要使用 SQL 语言描述端到端 AI 任务； 使用 SQLFlow SQL 语句构建 AI 任务； 使用 SQL 程序构建端到端 AI 工作流； 使用 SQLFlow Model Zoo 沉淀模型； 应用 SQLFlow 的场景案例； 为什么要使用 SQL 语言描述端到端 AI 任务 首先，思考一个问题，人工智能和金融有哪些耳熟能详的结合呢？  在智能征信风控方向，可以运用大数据进行机器学习，刻画用户画像，抽取个性化典型特征，推进反欺诈评估、用户征信评估。 用到的技术：聚类（将有相似特征的群体聚类，确定人群标签）、分类（学习已有分类标签的用户特征，识别新用户所属的类型、标签）、模型解释\n 在智能投资顾问方向，我们以人工智能算法为基础，为客户提供自动化投资管理解决方案，包括提供投资资讯、构建投资组合、直接投资管理等服务。 用到的技术：时序模型、回归、运筹规划\n 智能营销方向，上世纪90年代沃尔玛超市将「啤酒」与「尿布」摆在同一区域的做法，大大增加了商品销售收入，成为借助数据分析实现智能营销的经典案例。而今天，在人工智能等新技术的加持下，数据分析技术正在不断进化，千人千面的智能营销已有广泛的应用。 用到的技术：推荐算法、Ranking、CTR、运筹规划\n然而，构建传统的机器学习工作流程，需要经历非常多的步骤并使用复杂的技术栈： 构建完整的 AI 应用，首先需要获取用于构建模型的数据，这些数据通常可以从日志、订单数据、交易记录等获得。之后通过数据抽取，将其中我们需要用到的部分信息，从多个存储位置抽取出来。抽取数据之后需要进行数据预处理，比如去掉错误的数据，填充缺失的数据，整理，排序等。预处理完成之后，我们需要从这部分数据中得到用于训练模型的特征，比如提取时间序列的周期性特征，获取交叉特征等，最后将构建的特征转换成训练框架可以接收的数据格式，才能开始训练。 另外，在开始训练之前，我们还需要确定使用哪个模型，XGBoost 模型还是深度学习模型，哪个模型更适合当前的场景？模型可以从现有模型库中获取并根据需要修改，或者从头编写新的模型使用。另外在构建机器学习模型时，我们需要不断的评估模型的表现如何，以获得最优的模型，这时就要使用各种评价指标描述训练好的模型。当模型评估结果验证达标之后，就需要将模型代码发布一个新的版本，部署到线上环境。发布之前还要通过线下测试，小流量 ABTest，然后推全部署。如果是离线任务则需要更新定时任务使用新的模型代码。\n当模型的时效性比较强的时候，我们还需要不断的使用新的数据更新模型，就是“增量训练“，这样每次增量训练就不得不再次从头走一次完整的流程。\n要完成这一整套流程，需要用到复杂的技术栈。\n我们需要的数据可能存储在磁盘，或者像 HDFS 这样的分布式文件系统，或者可以从结构化的数据库系统中获得，或者是 NoSQL 引擎（比如 mongodb）存储的数据；在预处理阶段，有可能需要编写 MapReduce Job 来处理 HDFS 上的大量的数据，或者使用 Hive 编写 SQL 语句完成处理，亦或直接编写 Python 代码处理数据；在特征工程阶段，又需要使用类似 statsmodels, tsfresh 或者编写 Python 程序使用诸如 Pandas 之类的库完成预处理；在模型训练阶段，算法工程师首先需要掌握各种建模的能力，算法原理和基础知识，也需要熟练使用各种机器学习引擎如 sklearn, XGBoost, Tensorflow, Pytorch 等；最后在上线部署阶段，还需要了解模型如何接入 Serving 系统，怎么样做 ABTest，怎么编写 CI/CD 任务保证模型上线不影响线上业务。\n构建 AI 应用，不仅需要冗长的链路和复杂的技术，从业务需求到 AI 系统上线也需要特别长的沟通链路。\n比如业务同学和产品同学在构建产品思路的时候，在他的脑海中的 AI 系统需要完成的任务，传达给开发同学之后，有可能传达不到位，需要反复的沟通。有时甚至做了一半还需要重做。\n另外从需求到上线，为了保证线上服务和数据产出的稳定，也需要通过许多的步骤。比如业务同学说：「活动要上线了，时间点很关键，明天必须发布！」开发同学接到需求，加班加点，开发验证完成之后，模型准确率提升10个点，准备发布模型。SRE 同学则会把控上线之前的各项准备，包括预发测试是否通过，压力测试是否通过，CPU 负载是否有提升，硬件资源是否能承载新的模型，模型预测延迟是否提升了等……完成流程也需要很长时间。然而如果没有 SRE 的把关，线上的服务很难保证稳定性。\n使用 SQL 作为描述和构建 AI 任务的语言，可以降低构建 AI 应用的门槛，提升效率。\n首先需要区分编程语言主要的两种描述方法：描述意图和描述过程。简而言之，描述意图是在描述「做什么」，描述过程是描述「怎么做」。比如，夏天大家有空喜欢吃点烧烤喝点啤酒，描述意图的方式，说「我想去撸串」这一句就够了。而描述过程，就需要说「我今天晚上下班后，叫上老王小李，去公司楼下的烧烤店，点100个串和10个啤酒，最后用支付宝扫码付款」。可以看到描述意图可以非常简洁，而具体的执行方案，可以根据意图中构建得出。这点也是 SQL 不同于其他语言的关键点。\n在描述模型训练任务时，使用 SQLFlow SQL 只需要编写 SELECT * FROM iris.train TO TRAIN DNNClassifier LABEL class INTO my_dnn_model; 即可，如果使用 Python 完成相同的任务则需要编写如下图这样的较长的代码。\nSQL 语言除了有非常简洁的优势之外，在数据科学领域，SQL 语言的已有用户量大，并且在不断的增加。这里也有两个统计图，统计了数据科学类任务所使用的工具的流行程度和增长趋势。SQL 语言流行程度排名第三，增量排在第四名。数据科学领域正在更多的使用 SQL 是我们希望使用 SQL 语言描述 AI 任务的原因。除了在表达能力上 SQL 语言有非常简洁的优势之外，在蚂蚁内 MaxCompute 被广泛使用也是我们选择 SQL 的一个原因。\n如何使用 SQLFlow SQL 语句构建 AI 任务 SQLFlow 是一个开源项目， …","date":1594623600,"description":"近两年来，端到端机器学习成为 AI 领域研发热点，蚂蚁集团于2019年5月发布端到端 AI 系统 SQLFlow 开源项目，受到业界广泛关注。今天，就让我们来看看它对端到端 AI 的思考与解答。","dir":"blog/end-to-end-ai-system-sqlflow/","fuzzywordcount":6700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"667a8ff160a9c7f54a5ceba7c20b7437","permalink":"https://sofastack.github.io/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","publishdate":"2020-07-13T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","summary":"端到端机器学习是一种由输入端的数据直接得到输出端结果的AI系统，它可以对业务人员屏蔽复杂技术细节，同时给模型以更多自动调节空间，增加模型整体","tags":["SQLFlow"],"title":"我们需要什么样的端到端 AI 系统？蚂蚁 SQLFlow 的思考与答案","type":"blog","url":"/sofastack.tech/blog/end-to-end-ai-system-sqlflow/","wordcount":6621},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网:https://www.sofastack.tech SOFAStack:https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@郝连帅 提问： \u0026amp;gt; 如果回滚失败有没有告警机制实现？比如钉钉告警。\nA：可以的，实现 FailureHandler 接口。\n本周推荐阅读 支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.3，主要变更如下：\n RheaKV 允许不同分片各自配置不同的 learner 节点； 在只有一个成员变更的情况下，仍然使用 raft 联合一致性算法； 替换基于 GPL-2.0 licence 的 Bits.java； 升级 jackson.databind 版本到 2.10.4 已修复安全漏洞； 修复在 node panic 后可能因为未及时刷盘导致快照元数据丢失的 bug； 致谢（排名不分先后）：@zongtanghu\n此版本强烈建议升级 详细发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.3.3\n社区活动报名 CNCF 的旗舰会议聚集了全球领先开源社区和云原生社区的使用者和技术大咖参加线上峰会。相约 2020 年 7 月 30 日 - 8 月 1 日三天的线上峰会，共同探讨云原生计算的未来和方向。蚂蚁集团也受邀进行两个云原生主题分享。\n分享主题：在大规模 Kubernetes 集群上实现高 SLO 的方法\n 分享嘉宾：霜林 蚂蚁集团技术专家、散樗 蚂蚁集团高级开发工程师 议题介绍：随着 Kubernetes 集群的规模和复杂性的增加，集群越来越难以提供高成功率和低延迟的合格 pod。在本次演讲中，蚂蚁集团的工程师将分享他们在设计 SLO架构和实现高服务水平目标的方法的经验。他们将引入适当的指标，首先衡量 Kubernetes 集群是否健康。然后，他们将解释如何设计和实现跟踪和分析平台，以收集有效的度量和计算这些指标。有了跟踪分析平台，pod 提供过程中出现的问题可以很容易的被诊断出来。最后，他们将展示如何沉淀人工体验到自我修复系统，以自动修复已知的问题。 分享时间：2020-07-30 20:10-20:40 报名方式：点击“这里”，即可报名 分享主题：为 Kubernetes 的秘密披上无形的盾牌\n 分享嘉宾：柯粟 蚂蚁集团高级开发工程师 议题介绍：K8s 的秘密广泛应用于生产中，用于对敏感信息进行存储管理。与 KMS 的集成，甚至与基于硬件的插件，确实增强了保护，但还远远不够，特别是对于财务级的安全需求。由于缺乏端到端的秘密加固解决方案，攻击面在很大程度上在 K8s 集群中其他关键元素/流的威胁中仍然不受保护。通过聚合可信执行环境（TEE）和增强的身份验证，本讲座探索在使用、静止和传输中保护 K8s 秘密的答案。对 kubectl、K8S主节点和节点进行了更改，以保证可用性和机密性。TEE 对开发人员和用户的透明性将通过一个演示进行阐述和演示。最后，将分享在蚂蚁集团的实践经验和 KEP 给社区。 分享时间：2020-07-31 20:10-20:40 报名方式：点击“这里”，即可报名 ","date":1594364400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200710/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"304a9dc50d507f12e1b562491d6b5546","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200710/","publishdate":"2020-07-10T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200710/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft 发布、CNCF 旗舰会议活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200710/","wordcount":1362},{"author":"尹博学","categories":"分布式架构","content":" 过去几年是云原生理念高速普及的黄金时期。微服务、容器、无服务器架构、服务网格等新技术的出现，在技术社区中激起了一浪又一浪的创新热潮。然而由于金融行业对性能和安全的严苛要求，云原生技术在企业实际场景中的实施落地，特别是在金融场景的实施落地，仍然面临诸多挑战。\n本文整理自2020阿里云线上峰会蚂蚁集团资深技术专家尹博学的主题演讲，为大家分享蚂蚁关于金融级 IT 架构及分布式架构的思考和应用实践。关注本网站，蚂蚁 SOFAStack 白皮书即将发布，不要错过哦～\n 以下为演讲整理全文：\n大家好，我是蚂蚁集团的尹博学，今天和大家分享一下蚂蚁关于金融级 IT 架构及分布式架构的一些思考和应用案例，主要包含三个部分，分别是行业常见的分布式架构介绍、蚂蚁单元化架构的介绍以及单元化架构的应用案例。\n行业常见分布式架构 行业常见的分布式架构主要包含，单活架构、双活架构和冷备架构。从容灾能力角度来看，双活架构和冷备架构均能做到应用级跨机房容灾，但是数据库因为使用了异步复制的技术，无法做到机房级 RPU=0 的容灾。再看灰度发布的能力，冷备架构和双活架构都只能做到机房级灰度发布，无法做到更细粒度的灰度发布。\n蚂蚁集团单元化架构介绍 在介绍完行业常见的分布式架构后，我们来看一下蚂蚁的分布式架构发展历程，和单元化架构的详细介绍。\n这是蚂蚁分布式架构发展历程。蚂蚁也经历了单活、同城双活、两地三中心三个阶段。其中两地三中心是同城双活加一个冷备。随着蚂蚁业务和业务量复杂度的越来越高，业务对于基础架构的要求也越来越高，即扩展能力、容灾能力、灰度能力要求越来越高。最终蚂蚁发展到了单元化架构，将主要业务拆分单元即分片，装入不同的逻辑单元内，每个分片的数据库实现三地五中心部署即三地五中心的单元化架构。\n首先我们来看一下蚂蚁单元化架构的整体架构设计，整体架构包含 RZone、GZone 和 CZone。其中 GZone 部署的是无法拆分的数据和业务，GZone 的数据和业务被 RZone 依赖，GZone 全局只部署一份，而 RZone 部署的是可拆分的业务和对应的数据。每个 RZone 内的数据分片如图所示有五副本，实现三地五中心部署，每个分片内只有一个可写入的主副本，其余副本按照 Paxos 协议做数据强一致。每个 RZone 内实现业务单元封闭，独立完成自己的所有业务。而 CZone 的出现是因为 GZone 全局只有一份，不同城市的 RZone 可能依赖 GZone 服务和数据的时候需要远距离调用，延迟比较大，所以在每个城市部署一个 CZone 作为 GZone 的只读副本，为本城市的 RZone 提供服务。\n介绍完单元化架构的整体设计之后，我们从容灾、灰度发布、弹性三个方面详细看一下该架构的能力。\n首先看容灾能力，容灾能力分为同城容灾和异地容灾，以图中所示为例，RZone1 出现故障先看同城容灾能力，我们目标将 RZone1 切换至同城容灾 RZone2。先做数据库分片切换，RZone1 对应的分片为分片1，把分片1在 RZone2 的副本提升为主副本，数据库副本提升完毕后将 RZone1 的流量切换至 RZone2，实现同城容灾 RPO=0、RTO\u0026amp;lt;1min。\n再看异地容灾，同样以 RZone1 故障为例。目标切换至 RZone3，先做数据库切换，分片1在 RZone3 的副本切换成主副本，完成后将 RZone1 的流量切换至 RZone3，实现异地容灾，该过程 RPO=0、RTO\u0026amp;lt;1min。\n接下来我们看弹性。弹性的背景是业务在大促、节假日等流量出现大幅上涨的过程，我们可以短期租借新的城市和新的 IDC。如图所示，我们租借城市 X 的 IDCX 作为 RZoneX，将 RZone5 的部分流量弹出至 RZoneX，对应流量的数据也弹出至 RZoneX 内。在节假日大促结束之后，将 RZoneX 内的流量和数据弹回至 RZone5，然后回收 RZoneX，这样大幅节约了机房成本。\n介绍完弹性之后，我们来看灰度能力。如图所示，我们将四个 RZone（RZone1、RZone2、RZone3、RZone4）的业务和应用分为 A、B 组，日常 A 组和 B 组各承担50%的应用流量。在应用新版本发布时，我们将 A 组的流量全部切换至 B 组，此时在 A 组上部署新版本，部署完毕后将 B 组的流量按粒度切换至 A 组上，切换粒度等于数据分片的粒度。在切换的过程中可以做 A 组和 B 组的服务对比，如果发现 A 组的服务异常，可以快速将流量切换回 B 组。在 A 组服务一段时间后无异常发生，最终可以将 B 组的流量全部切换至 A 组，把 B 组的版本更新为新的版本，在整个切换的过程中实现了可灰度、可回滚、可监控。\n我们再深入到架构内部，来阐释一下架构内关键模块是如何支撑该架构的。\n首先我们看流量路由模块。流量路由模块的核心是将用户的 uid 信息和对应的 Zone 信息植入到 cookie 中，供流量路由模块做精准路由。我们以用户 uid=68、RZone=RZ03 为例来看流量路由模块是如何工作的，首次用户接入时 cookie 内无 Zone 信息，流量接入模块会随即将该请求发到一个 RZone 内，如发到 RZone1 内，RZone1 通过 zoneClinet 会准确计算该请求应发至 RZone3，即通过 RouteClinet 将该请求发送。发送过程中将计算出的 uid 信息和对应的 Zone 信息植入 cookie 内转发至 RZone3，RZone3 完成本次业务请求后将结果返回给用户，其后用户同意 session 内的其它请求，因为在 cookie 内已经有了准确的路由信息，会被流量路由模块准确的发至 RZone3 完成业务请求。\n接着我们再看一下服务路由，服务路由分为本机房服务路由和跨机房服务路由调用。先看本机房服务路由，服务调用端向本机房服务注册中心订阅服务，发现服务地址后做本机房服务路由调用。再看跨机房服务路由调用，服务调用端向其他 IDC 的注册中心订阅服务地址，发现服务地址后做跨机房服务调用。\n最后我们看数据是如何实现高可靠的。蚂蚁使用自研的分布式关系数据库 OceanBase，每个分片的数据库做5副本部署，部署地域实现三地五中心部署，5副本中有3副本实现强一致，如图所示可以实现同城、IDC 容灾和异地容灾。\n单元化架构实践场景 介绍完蚂蚁单元化架构的主要概念即关键模块信息之后，我们看一下单元化架构在外部客户实施的一些案例。\n第一个案例是一家城商行，它的业务系统、IT系统历史比较长，无法一步跨越到单元化架构，我们为其推荐了大 GZone 的模式，即把城商行的所有服务和数据不做拆分，直接装入一个 GZone 内，在 GZone 的基础上实现同城双活即应用同城双中心部署，数据库同城三中心部署，从而实现同城容灾能力，RPO=0、RTO\u0026amp;lt;1min，但无法实现异地容灾能力，其可灰度能力和弹性能力都无法做到更细力度。\n再看第二个区域银行的案例。我们为这家区域银行实现了同城单元化，即将这家区域银行的主要业务拆分成两个逻辑业务单元两个分片，将其装入一个城市的两个 IDC 内，在另外一个城市建设冷 …","date":1594278000,"description":"本文整理自2020阿里云线上峰会蚂蚁集团资深技术专家尹博学的主题演讲，为大家分享蚂蚁关于金融级 IT 架构及分布式架构的思考和应用实践。","dir":"blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dec27e85a58fcb573b33b9de6125bbc5","permalink":"https://sofastack.github.io/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","publishdate":"2020-07-09T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","summary":"过去几年是云原生理念高速普及的黄金时期。微服务、容器、无服务器架构、服务网格等新技术的出现，在技术社区中激起了一浪又一浪的创新热潮。然而由于","tags":["分布式架构"],"title":"支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构","type":"blog","url":"/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/","wordcount":3642},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@guotaisu 提问：\n 根据 jraft-example, 使用“fake PD”, 怎样手动 rebalance。使用 PD 自管理体现在哪？\n A：手动 API： https://github.com/sofastack/sofa-jraft/blob/master/jraft-core/src/main/java/com/alipay/sofa/jraft/CliService.java#L190\nPD 目前只实现了 leader 平衡和自动分裂，支持很容易基于 SPI 扩展增加自己的逻辑(增加并实现自己的 com.alipay.sofa.jraft.rhea.util.pipeline.Handler 即可)，文档见：https://www.sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/\n regionEngineOptionsList 配置：实例中的 regionId 的 startKey：01000000-endKey：23000000 根据什么来定义的，假设我一个 store 节点只部署 1-3 个 region，可以自定义上下界是吗，依据什么来定义？\n A：rheakv multi group 按照 range 分片，左闭右开，可以自定义，怎么定义取决于你对自己场景 key 分布的评估。\n yaml 配置中 regionEngineOptionsList.RegionEngineOptions 中的 serverAddress、initialServerList 等配置和外部与 regionEngineOptionsList 平级的 serverAddress 配置以及与 storeEngineOptions 平级的 initialServerList 是什么关系，谁覆盖谁？\n A：store 和 region 为1：n， region 包含在 store 中，store 的参数会 copy 传递到 region。\n jraft-example 展示，Rhea-kv 是客户端+服务端模式，其中 benchmark 使用分片集群部署模式，需要先同时使用 BenchmarkClient、BenchmarkServer 拉启后台服务，而后面的 rheakv 使用分节点配置和启动，如何区分二者的场景和使用姿势。\n A：rheakv 可以作为 client+server 部署，也可以单独作为 client 部署，通常你不想在每个节点提供服务但是还需要调用服务，那么就只 client 部署即可（配置的区别就在于是否配置了 StoreEngineOptions）。\n 本人项目使用 SOFAJRaft 场景是分布式单体服务快速便捷存储业务元数据，实现一致性访问。请问后台需要拉取这么多服务如何还能保证我的应用轻量快捷？另外，这些后台 jraft-kv 选举和存储服务启动后，是独立进程吗，整合到自己到项目中后，可否一个进程并且其服务生命周期随同我的母体应用的生命周期。\n A：SOFAJRaft 是一个 jar 包，是不是独立进程完全取决于你自己的意愿，都可以。\n 参考 jraft-example 实例，基于 rheakv 部署 multi group，加减 learnner 节点等，应该是以分组为单位操作，目前只看到 NodeOptions 中有 groupId 属性，多组时怎么配置和分别操作。\n A：这应该是两个问题。 问题1（groupId 多组如何配置）：在 rheakv 里，groupId 是 clusterName + ‘-’ regionId。 问题2（多组如何配置 learner）：目前没有很灵活，我们内部使用还是单独指定几台机器，上面的节点全部是 learner 节点，只要配置 initialServerList: 127.0.0.1:8181,127.0.0.1:8182,127.0.0.1:8183/learner 即所有 group 的 learner 都在 127.0.0.1:8183/learner 一个节点上，你的需求收到了，下个版本会增加每个 region 单独指定 learner，需要修改 RegionEngineOptions.initialServerList 在不为空的时候不被 StoreEngineOptions 的值覆盖即可。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n本周推荐阅读 网络通信框架 SOFABolt 功能介绍及协议框架解析 | SOFAChannel#17 直播回顾 走出微服务误区：避免从单体到分布式单体 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.14.0，主要变更如下：\n 支持 Istio 1.5.x 版本； 升级了一些依赖库，如 FastHTTP、Dubbo-go、Tars； 支持 Maglev 负载均衡、支持 HostRewrite Header； 新增了一些 Metrics 输出与查询接口； 部分实现优化与 Bug 修复； 详细发布报告：https://mosn.io/zh/blog/releases/v0.14.0/\n同时，恭喜姚昌宇（@trainyao）成为 MOSN Committer，感谢他为 MOSN 社区所做的贡献。\n社区活动报名 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。蚂蚁集团也受邀进行 CloudNative(云原生) 的主题分享。\n 分享主题：云原生网络代理 MOSN 的进化之路 分享嘉宾：王发康（毅松）蚂蚁集团 可信原生技术部 技术专家 背景介绍：网络通信代理 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，增强 MOSN 服务治理及流量控制能力，对接云原生周边组件，实现 MOSN 开箱即用，MOSN …","date":1593759600,"description":"【06/29-07/03】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200703/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6f65c94a70fdd3d222fb510cbec05abf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200703/","publishdate":"2020-07-03T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200703/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁集团自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 版本发布以及社区活动预告、SOFABolt 直播回顾整理","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200703/","wordcount":1989},{"author":"丞一","categories":"SOFAChannel","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 大家好，我是本期 SOFAChannel 的分享讲师丞一，来自蚂蚁集团，是 SOFABolt 的开源负责人。今天我们来聊一下蚂蚁集团开源的网络通信框架 SOFABolt 的框架解析以及功能介绍。本期分享将从以下四个方面展开：\n SOFABolt 简介； 基础通信能力解析； 协议框架解析； 私有协议实现解析； SOFABolt 是什么 SOFABolt 产生背景 相信大家都知道 SOFAStack，SOFAStack(Scalable Open Financial Architecture Stack)是一套用于快速构建金融级云原生架构的中间件，也是在金融场景里锤炼出来的最佳实践。\nSOFABolt 则是 SOFAStack 中的网络通信框架，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架，他的名字 Bolt 取自迪士尼动画《闪电狗》。他一开始是怎么在蚂蚁集团内部产生的，我们可以类比一下 Netty 的产生原因：\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生； 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生； 这些年，在微服务与消息中间件在网络通信上，蚂蚁集团解决过很多问题、积累了很多经验并持续进行着优化和完善，我们把总结的解决方案沉淀到 SOFABolt 这个基础组件里并反馈到开源社区，希望能够让更多使用网络通信的场景受益。目前该组件已经运用在了蚂蚁集团中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n同时，已有数家企业在生产环境中使用了 SOFABolt，感谢大家的肯定，也希望 SOFABolt 可以给更多的企业带来实践价值。\n以上企业信息根据企业用户 Github 上反馈统计 — 截止 2020.06。\nSOFABolt：https://github.com/sofastack/sofa-bolt\nSOFABolt 框架组成 SOFABolt 整体可以分为三个部分：\n 基础通信能力（基于 Netty 高效的网络 IO 与线程模型、连接管理、超时控制）； 协议框架（命令与命令处理器、编解码处理器）； 私有协议实现（私有 RPC 通信协议的实现）； 下面，我们分别介绍一下 SOFABolt 每个部分的具体能力。\n基础通信能力 基础通信模型 如上图所示，SOFABolt 有多种通信模型，分别为：oneway、sync、future、callback。下面，我们介绍一下每个通信模型以及他们的使用场景。\n oneway：不关注结果，即客户端发起调用后不关注服务端返回的结果，适用于发起调用的一方不需要拿到请求的处理结果，或者说请求或处理结果可以丢失的场景； sync：同步调用，调用线程会被阻塞，直到拿到响应结果或者超时，是最常用的方式，适用于发起调用方需要同步等待响应的场景； future：异步调用，调用线程不会被阻塞，通过 future 获取调用结果时才会被阻塞，适用于需要并发调用的场景，比如调用多个服务端并等待所有结果返回后执行特定逻辑的场景； callback：异步调用，调用线程不会被阻塞，调用结果在 callback 线程中被处理，适用于高并发要求的场景； oneway 调用的场景非常明确，当调用方不需要拿到调用结果的时候就可以使用这种模式，但是当需要处理调用结果的时候，选择使用同步的 sync 还是使用异步的 future 和 callback？都是异步调用，又如何在 future、callback 两种模式中选择？\n显然同步能做的事情异步也能做，但是异步调用会涉及到线程上下文的切换、异步线程池的设置等等，较为复杂。如果你的场景比较简单，比如整个流程就一个调用并处理结果，那么建议使用同步的方式处理；如果整个过程需要分几个步骤执行，可以拆分不同的步骤异步执行，给耗时的操作分配更多的资源来提升系统整体的吞吐。\n在 future 和 callback 的选择中，callback 是更彻底的异步调用，future 适用于需要协调多个异步调用的场景。比如需要调用多个服务，并且根据多个服务端响应结果执行逻辑时，可以采用 future 的模式给多个服务发送请求，在统一对所有的 future 进行处理完成协同操作。\n超时控制机制 在上一部分的通信模型中，除了 oneway 之后，其他三种（sync、future、callback）都需要进行超时控制，因为用户需要在预期的时间内拿到结果。超时控制简单来说就是在用户发起调用后，在预期的时间内如果没有拿到服务端响应的结果，那么这次调用就超时了，需要让用户感知到超时，避免一直阻塞调用线程或者 callback 永远得不到执行。\n在通信框架中，超时控制必须要满足高效、准确的要求，因为通信框架是分布式系统的基础组件，一旦通信框架出现性能问题，那么上层系统的性能显然是无法提升的。超时控制的准确性也非常重要，比如用户预期一次调用最多只能执行3秒，因为超时控制不准确导致用户调用时线程被阻塞了4秒，这显然是不能接受的。\nSOFABolt 的超时控制采用了 Netty 中的 HashedWheelTimer，其原理如上图。假设一次 tick 表示100毫秒，那么上面的时间轮 tick 一轮表示800毫秒，如果需要在300毫秒后触发超时，那么这个超时任务会被放到\u0026amp;rsquo;2\u0026amp;rsquo;的 bucket 中，等到 tick 到\u0026amp;rsquo;2\u0026amp;rsquo;时则被触发。如果一个超时任务需要在900毫秒后触发，那么它会被放到如\u0026amp;rsquo;0\u0026amp;rsquo;的 bucket 中，并标记 task 的 remainingRounds=1，当第一次 tick 到\u0026amp;rsquo;0\u0026amp;rsquo;时发现 remainingRounds 不等于0，会对 remainingRounds 进行减1操作，当第二次 tick 到\u0026amp;rsquo;0\u0026amp;rsquo;，发现这个任务的 remainingRounds 是0，则触发这个任务。\n如果将时间轮的一次 tick 设置为1秒，ticksPerWheel 设置为60，那么就是现实时钟的秒针，走完一圈代表一分钟。如果一个任务需要再1分15秒后执行，就是标记为秒针走一轮之后指向第15格时触发。关于时间轮的原理推荐阅读下面这篇论文： 《Hashed and Hierarchical Timing Wheels: data structures to efficiently implement a timer facility》。\n快速失败机制 超时控制机制可以保证客户端的调用在一个预期时间之后一定会拿到一个响应，无论这个响应是由服务端返回的真实响应，还是触发了超时。如果因为某些原因导致客户端的调用超时了，而服务端在超时之后实际将响 …","date":1593694800,"description":"开源网络通信框架 SOFABolt 首次线上直播文字回顾。","dir":"blog/sofa-channel-17-retrospect/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9f88cb52dccf190278f16c9eab448644","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-17-retrospect/","publishdate":"2020-07-02T21:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-17-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播","tags":["SOFAChannel","SOFABolt"],"title":"网络通信框架 SOFABolt 功能介绍及协议框架解析 | SOFAChannel#17 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-17-retrospect/","wordcount":5457},{"author":"敖小剑","categories":"微服务","content":" 最近社区频繁出现的对微服务的各种质疑和反思的声音，甚至放弃微服务回归单体。本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Event/EDA 来走出微服务实践误区：从单体到微服务，却最后沦为分布式单体。\n 回顾：从单体到微服务到 Function 在过去几年间，微服务架构成为业界主流，很多公司开始采用微服务，并迁移原有的单体应用迁移到微服务架构。从架构上，微服务和单体最大的变化在于微服务架构下应用的粒度被“拆小”：将所有业务逻辑都在一起的单体应用，按照领域模型拆分为多个内聚而自治的“更小”的应用。而 Function 则在拆分上更进一步，拆分粒度变成了“单个操作”，基于 Function 逐渐演进出现 FaaS 形态和 Serverless 架构。\n在微服务和 Serverless 的喧嚣中，也逐渐出现了很多质疑和反对的声音：越来越多的人发现，当他们兴冲冲的迁移单体应用到微服务和 Serverless 架构之后，得到的收益并没有期望中的那么理想。最近，出现了对微服务的各种质疑、反思的声音，甚至放弃微服务回归单体。举例，我在 InfoQ 中国网站 简单搜索关键字“微服务”，前三页中就出现了如下的内容：\n 我们为什么停用微服务？ 这些公司为什么放弃微服务？ 什么？你的团队没有100人，那就不要用微服务了！ 致传统企业朋友：不够痛就别微服务，有坑 微服务带来的心理阴影 微服务到底该多大？如何设计微服务的粒度？ Uber 团队放弃微服务改用宏服务，网友评论炸锅了 为什么 Segment 从微服务回归单体 无论是支持还是反对微服务的声音，大多都是着眼于组织架构（康威定律，对应用和代码的 ownership）、微服务拆分（粒度大小，如何识别领域模型和业务边界）、分布式事务（跨多个微服务调用时维持一致性），工具（自动化构建、部署，可测试性，监控，分布式链路跟踪，CI/CD），数据库分离（避免多个微服务尤其是领域模型外的微服务共享数据库）等方面进行合理性分析和观点阐述，相信大家都对这些问题都有了解。\n而我今天的文章，将从另外一个角度来看待微服务（也包括 Serverless）实践中存在的误区——辛辛苦苦从单体走到微服务，却最后沦为分布式单体。\n分布式单体 “Distributed Monolith”，分布式单体，这真是一个悲伤的技术术语。而这偏偏是企业采用微服务后通常最容易踏进去的一个“陷阱”，事实上我看到的很多微服务落地最终都是以\u0026amp;rdquo;分布式单体\u0026amp;rdquo;收场，无法获得微服务的完整收益。\n问题源于微服务实施的方式 —— 按照业务逻辑拆解单体，划分为多个微服务，定义 API 接口，然后通过 REST 或者 RPC 进行远程调用，最终把这些微服务组合起来提供各种业务功能。简单说，就是在业务拆分的基础上，用进程间的远程调用简单替代原来进程内的方法调用。期间，对于原来使用的各种分布式能力，继续沿用之前的方式，简单说：方式不变，只是粒度变小。\n从方法论说这样做无可厚非，这也是微服务采用过程中非常标准的做法。但问题在于，止步于此是不够的 —— 至少存在两个有待继续努力改进的地方。\n分布式单体起因之一：通过共享库和网络客户端访问分布式能力 分布式能力的共享库和网络客户端是造成分布式单体问题的原因之一，关于这一点，来自 verizon 的 Mohamad Byan 在他的名为 Avoid the Distributed Monolith!! 的演讲中有详细的阐述，我这里援引他的图片和观点：\n上图是微服务体系的逻辑架构，由两部分组成：\n 内层架构（图上浅蓝色部分），是每个微服务的实现架构； 外层架构（图上黄色部分），是构建强大微服务架构所需要的各种能力，这里通常有大家熟悉的各种分布式能力； 特别提示：这里说的“网络客户端”是各种分布式能力的客户端，如服务注册发现/ MQ 中间件/ Redis 等 key-value 存储/数据库/监控日志追踪系统/安全体系等，不是服务间通讯如 RPC 的客户端。\n 而内层的微服务是通过 共享类库 和 网络客户端 来访问外层架构提供的分布式能力：\n分布式能力的 共享类库 和 网络客户端 会迫使内层微服务和外层架构的各种分布式能力之间产生强耦合，增加运维的复杂性（如升级困难造成版本碎片化），多语言受限于类库和网络客户端支持的语言，各种组件（如消息中间件）往往使用自定义数据格式和通讯协议 —— 所有这些迫使内层微服务不得不实质性受限于外层架构的技术选型。\n对于 Function，这个问题就更加明显了：Function 的粒度更小，更专注业务逻辑。某些简短的 Function 可能只有几百行代码，但是，为了让这几百行代码运转起来而需要引入的共享类库和网络客户端可能相比之下就规模惊人了。援引一张网上图片作为示意：\n分布式单体起因之二：简单用远程调用替代进程内方法调用 在微服务架构改造过程中，熟悉单体系统和架构的开发人员，习惯性的会将这些单体时代的知识和经验重用到新的微服务架构之中。其中最典型的做法就是：在遵循领域模型将现有单体应用按照业务边界拆分为多个微服务时，往往选择用 REST 或者 RPC 等远程调用方式简单替代原有的进程内方法调用。\n当两个逻辑上的业务模块存在协作需求时：\n从单体到微服务，直接方法调用被替换为远程调用（REST 或者 RPC），即使采用 Service Mesh 也只是在链路中多增加了 Sidecar 节点，并未改变远程调用的性质：\n这导致了前面所说的 “分布式单体”：\n 在微服务之前：应用程序由多个耦合在一起的模块组成，这些模块通过内存空间进行方法调用….. 在微服务之后：应用程序由多个耦合在一起的微服务组成，这些微服务通过网络进行远程调用….. 抛开调用方式的差异来看采用微服务前后的系统架构，会发现：两者几乎是完全一样的！！\n而微服务版本在某些情况下可能表现的更糟糕：因为调用方式更脆弱，因为网络远比内存不可靠。而我们将网络当成 “胶水” 来使用，试图把分散的业务逻辑模块（已经拆分为微服务）按照单体时代的同样方式简单粘在一起，这当然比单体在同一个进程内直接方法调用更加的不可靠。\n 关于这一点，在 \u0026amp;ldquo;The Eight Fallacies of Distributed Computing/分布式计算的8个谬论\u0026amp;rdquo; 一文中有详细阐述。\n 类似的，在采用 Function 时，如果依然沿用上面的方式，以单体或微服务架构的思维方式和设计模式来创建 FaaS/Serverless 架构：\n其本质不会发生变化 —— 不过是将微服务变成粒度更小的函数，导致系统中的远程调用数量大为增加：\n系统内的耦合并没有发生变化，Serverless 并不能改变微服务中存在的这个内部耦合问题：调用在哪里，则耦合就在哪里！只是把将组件的粒度从 “微服务“换成了 “Function/函数”。\n耦合的存在是源于系统不同组件之间的通讯模式，而不是实现通讯的技术。\n如果让两个组件通过“调用”（后面再展开讲何为调用）进行远程通信，那么不管调用是如何实现的，这两个组件都是紧密耦合。因此，当系统从单体到微服务到 Serverless，如果止步于简单的用远程调 …","date":1593414000,"description":"本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Event/EDA 来走出微服务实践误区：从单体到微服务，却最后沦为分布式单体。","dir":"blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","fuzzywordcount":9800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9ab906cecb82200b18dceb4ab43ba46a","permalink":"https://sofastack.github.io/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","publishdate":"2020-06-29T15:00:00+08:00","readingtime":20,"relpermalink":"/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","summary":"最近社区频繁出现的对微服务的各种质疑和反思的声音，甚至放弃微服务回归单体。本文从“分布式单体”问题出发，介绍通过引入非侵入式方案和引入Eve","tags":["微服务","分布式"],"title":"走出微服务误区：避免从单体到分布式单体","type":"blog","url":"/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/","wordcount":9732},{"author":"王旭","categories":"镜像","content":" 众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知道，最初的 Docker = LXC + aufs，前者就是所谓的 Linux 容器了，而后者则是我今天要聊的镜像。\n 千禧年：惊艳的 Live CD 说到 Linux distro，除了做差异化的界面主题之外，核心差异一般都在于：\n 如何更方便地安装； 如何更方便地升级； 而在 distro 界却有一股清流，超脱于这两件事情之外，它们就是 Live CD，它们装在一张光盘里，或者是一个 U盘上，不需要安装、也不会改变。之前创业的时候，我司的运维大佬——彤哥曾经说过：\n 第一次见到 liveCD 时我内心是震惊的。。\n 这我当然是赞同的，那时我也是震惊的同学之一，要知道 Knoppix 在 2000 千禧年就来到了世界，而它所基于的著名的 Debian，直到2005年6月，Sarge (3.1) 发布的时候才正式在 stable release 里带上了图形界面的安装程序 debian-installer （简称 d-i），此前版本的安装还在用文本菜单。就在这个年代，这样一个开光盘即用、启动起来就是图形界面的系统，给我们这些玩家带来的震撼，当然是可想而知的。那时候的 Live CD 就是十三年后的 Docker，绝对配得上“惊艳”两个字。\n要知道，一张 700MB 左右的光盘里塞下个完整的操作系统并不容易（当然有人开头之后也不太难，后来我爱的 DSL 可以做到 50MB）。Knoppix 有个很棒的想法——把装好的操作系统给压缩一下，放在光盘里， 随用随解压，这样，一张 700MB 光盘里可以放下大约 2GB 的根文件系统，这样就跑 KDE 桌面也就没啥问题了，当是时，distrowatch.com 上可以看到，一大片 distro 都是基于 Knoppix 魔改的，足见其影响力。\n进化：可读写层与 UnionFS Knoppix 在诞生之初的一个执念是“绝不碰本地存储一根指头”，而光盘，CD-ROM，所使用的 ISO9600 文件系统也是只读的，这无疑暗合了当今流行的“不可变基础设施”的潮流，但是，即使在今天，没有可写文件系统对于很多 Linux 软件仍然是非常困难的，毕竟随随便便一个程序也要写一点配置文件、状态信息、锁、日志之类的嘛。而诞生之初的 Knoppix 是不可写的，那么，要有什么东西要罗盘，就得手工挖掘出本地硬盘来挂上，或者是挂个 NAS 到 /home 或其他挂载点上来，当你不想只是做个紧急启动盘的时候，这就有点麻烦了。\n如果我们从今天穿越回去，毫不费力就可以指出，用 overlayfs 加上一个 tmpfs 做可写层嘛。但是，overlayfs 要到2010年才首次提交 patchset，2014年才被合并到 3.18内核（这中间，当时的淘宝内核组也有不少贡献和踩坑呢）。当然，比 overlay 早的类似的 unionfs 还是有的，Docker 最早采用的 Aufs 就是其中之一，它是2006年出现的，这里 AUFS 的 A，可以理解成 Advanced，但它最早的意思实际是 Another——是的，“另一个 UFS”，而它的前身就是 UnionFS。\n在2005年5月，也就是十五年前，Knoppix 创造性地引入了 UnionFS，而在一年半以后的 5.1 版本中，Knoppix 引入了当年诞生的更稳定的 aufs，此后，包括大家熟悉的 Ubuntu LiveCD、Gentoo LiveCD 全都使用了 aufs。可以说，正是 Live CD 们，提前了8年，为 Docker 和 Docker Image 的诞生，做好了存储上的准备。\n这里简单说一句给不了解的人听，所谓 union fs，是指多个不同文件系统联合（堆叠）在一起，呈现为一个文件系统，它和一般的 FHS 规定的那种树装组织方式是不同的，如下图，对于左边的标准的目录树结构，任何一个文件系统，挂载在树上的一个挂载点，根据路径，就可以指到一个确定的文件系统，比如，下图中，所有的 /usr/local/ 下面的路径都在一个文件系统上，而其他 /usr 就会在另一个文件系统上；而 UnionFS 是多层堆叠的，你写的文件会停留在最上层，比如图中，你修改过的 /etc/passwd 就会在最上的可写层，其他的文件就要去下面的层中去找，也就是说，它允许同一个目录中的不同文件在不同层中，这样，Live CD 操作系统跑起来就像真正的本地操作系统一样可以读写所有路径了。\n块或文件：Cloop 与 SquashFS 让我们把目光放在只读层上，这一层是 Live CD 的基础，在 Live CD 还没有 union FS 来做分层的时候就已经存在这个只读 rootfs 了。对 Knoppix 来说，这一层是不能直接放完整、无压缩的操作系统的，因为在21世纪初，大家都还在用 24x 到 40x 速光驱的时代，Knoppix Live CD 面临的一个大问题是 700MB 的光盘和庞大的桌面操作系统之间的矛盾。\n开头我们提到了，Knoppix 的想法就是“把装好的操作系统给压缩一下，放在光盘里， 随用随解压”，这样精心选择后的 2GB 的 Distro 就可以压到一张光盘里了，不过“随用随解压“不是说有就有的，文件系统访问块设备，是要找到块的偏移量的，压缩了之后，这个偏移量就并不那么好找了，全解压到内存里再找偏移并不那么容易。\n回到2000年，那时候还是2.2内核，Knoppix 的作者 Klaus Knopper 在创立 Knoppix 之初就引入了一种压缩的(compressed) loop 设备，称为 cloop，这种设备是一种特殊的格式，它包含了一个索引，从而让解压缩的过程对用户来说是透明的，Knoppix 的 cloop 设备看起来就是一个大约 2GB 大的块设备，当应用读写一个偏移的数据的时候，它只需要根据索引解压缩对应的数据块，并返回数据给用户就可以了，无需全盘解压缩。\n尽管 Knoppix 把众多 distro 带上了 Live CD 的船，但是，众多后继者，诸如 arch、Debian、Fedora、Gentoo、Ubuntu 等等 distro 的 LiveCD，以及大家熟悉的路由器上玩的 OpenWrt，都并没有选择 cloop 文件，它们选择了和应用语义更接近的文件系统级的解决方案——Squashfs。Squashfs 压缩了文件、inode 和目录，并支持从 4K 到 1M 的压缩单元尺寸。同样，它也是根据索引按需解压的，和 cloop 的不同之处是，当用户访问一个文件的时候，它来根据索引解压相应的文件所在的块，而非再经过一层本地文件系统到压缩块的寻址，更加简单直接。事实上，Knoppix 里也一直有呼声想要切换到 squashfs，比如，2004年就有开发者在转换 knoppix 到squashfs 上，而且，一些测试数据似乎也表明 Squashfs 的性能似乎要更好一些，尤其在元数据操作方面。\n在 wiki 上是这么评价 cloop 的缺点的： …","date":1592895600,"description":"众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知道，最初的 Docker = LXC + aufs，前者就是所谓的 Linux 容器了，而后者则是今天要聊的镜像。","dir":"blog/twenty-years-of-image-format-from-Knoppix-to-OCI-Image-v2/","fuzzywordcount":6100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f918e4318b9157894559ba289b29553d","permalink":"https://sofastack.github.io/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","publishdate":"2020-06-23T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","summary":"众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知","tags":["镜像"],"title":"镜像格式二十年：从 Knoppix 到 OCI-Image-v2","type":"blog","url":"/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/","wordcount":6095},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@雷霆 提问：\n 各位大佬 请问 TCC 拦截器这块为什么 xid 要先解绑，再绑定呢，这样做是有什么考虑吗？ A：执行 TCC 分支时，首先会解绑 xid，这是因为在 TCC 分支内，是不需要执行 AT 的 SQL 解析和自动补偿的（可以在 seata-rm-datasource 的 ExecuteTemplate 里看下实现），同时需要绑定下当前的拦截类型 TCC，这个拦截器类型在跨服务传递时也有特殊处理，建议也看下跨服务传递的源码。最后然后执行完 TCC 分支后的解绑、还原 xid 的操作，就是一个事务上下文的还原了。你目前看到的这个源码，后续我们还会优化下，更方便理解。这一系列操作是为了根据分支类型来区分分支事务的行为：AT 分支的行为是自动补偿，会走 SQL 解析和 undo 回滚，TCC 分支的行为是手动补偿，不会走 undo，而是执行用户自定义的 try 和 confirm。\n2、@taking 提问：\n 为何 TCC 模式的分支事务 commit 需要同步呢？\n A：因为如果异步 commit 会存在，退款的问题，如果没有 commit 那么事务没有完成，这时来了一笔退款交易，则原交易状态没有完成，会失败。当然也可以异步化，但是需要能够容忍一些反向交易的失败，或对反向交易做特殊处理。\n 如果 commit 被阻塞，退款请求也一样还是会失败吧？\n A：commit 被阻塞，说明支付还没有成功，前面不会发起退款的。\n 可以考虑在 LocalTCC 注解上加个属性表示是否允许异步执行。\n A：也可以的，然后在反向交易时需要能判断这个正交易是否已经完成，没有完成，触发一次事务恢复，进行 commit，然后再执行反交易。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服智能监控云原生可观测大盘设计概览 再启程，Service Mesh 前路虽长，尤可期许 蚂蚁金服在 Service Mesh 监控落地经验分享 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFAJRaft v1.3.2 版本，主要变更如下：\n 抽象出网络通信层，增加 GRPC 实现并支持 Replication Pipeline，用户亦可自行对通信层进行其他实现的扩展； RheaKV 增加 reverseScan API ； 提供 Replicator 与 RPC 的线程池隔离，避免相互影响； read-index 线性一致读请求提供请求超时（timeout）配置； 几个 corner case 修复，比如 replicate logs 如果比 appliedIndex（follower）更小，那么可以认为是成功的； 致谢（排名不分先后） @shibd 、@SteNicholas 、@killme2008 、@zongtanghu 详细发布报告： https://github.com/sofastack/sofa-jraft/releases/tag/1.3.2\n2、发布 Occlum v0.13.0 版本，主要变更如下：\n 扩展了Occlum.json的配置格式，更强大，更易读； 增加了3个新的系统调用； 增强了编程语言支持：支持了 Rust、改进了 Python 和 Go 的 demo； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.13.0\n社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1592550000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200619/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4b795b006dbfdc77ff65a693f80f1e6c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200619/","publishdate":"2020-06-19T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200619/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFAJRaft、Occlum 发布、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200619/","wordcount":1726},{"author":"申尘","categories":"智能监控","content":" 背景 蚂蚁金服业务自定义监控是蚂蚁金服监控产品中的一个重要功能，主要是通过自定义日志数据源并配置大盘的方式来解决蚂蚁金服业务实时监控的需求。在产品功能上，用户可以通过对一系列日志数据源的创建、组织、管理及表单配置化的方式，简单、快速组织出一个多维监控大盘。这项能力在当时是一个具有创新性的能力，从功能到产品体验上很好解决了当时蚂蚁金服复杂业务监控的痛点。\n但是，随着蚂蚁金服监控产品的不断迭代更新，以及云原生可观测性对于监控大盘的高要求，大家对自定义监控的体验诉求也越来越多，包括更便捷的交互方式、更丰富的图表、更丰富的数据源、更多扩展点等，因此对监控大盘的升级也势在必行。\n本文将介绍蚂蚁金服监控产品在监控大盘方面的创新设计与尝试，新版自定义监控大盘 Barad-Dur 目标成为业界体验最优秀的自定义监控大盘，在交互、体验与设计理念上有诸多创新点，同时将以模块的形式发布，支持二次开发，可以同时为蚂蚁金服内外监控系统服务。\n产品体验 WYSIWYG 当前优秀的监控大盘产品都标配一个“所见即所得（WYSIWYG）”编辑器，这方面能力是蚂蚁金服监控产品一直缺失的。在蚂蚁金服监控产品中配置大盘还是通过传统的表单方式，对用户非常不友好、学习曲线陡峭、配置效率不高。导致用户经常将配置大盘作为一项需求提给监控团队，由监控团队的“大盘配置专家”来进行配置，不仅存在较高的沟通成本，也给监控团队增加了很大的负担。\n在新版监控大盘 Barad-Dur 中，对 WYSIWYG 编辑器的交互体验进行了大量工作，力求做到市面上最优秀的编辑体验。\n体验1：缩放 Barad-Dur 的缩放是可以在四周以及四角上进行的，而市面上常见的大盘产品只支持右下角的缩放。由于坐标系统一般采用的是 (left, top, width, height) 来定义一个矩形，最容易实现的就是右下角缩放，只需要变动 width 和 height 两个参数即可。最难实现的是左上角的缩放，四个参数需要同时变动，且关系比较复杂。特别是在引入网格布局后，缩放时要自动“吸附”临近的网格点，难上加难。\n体验2：拖动 Barad-Dur 的图表拖动可以实现图表位置的一步交换，而市面上常见的大盘产品需要进行多次拖动才能实现两个图表的交换。且在拖动过程中，图表的整体布局会被打乱，而 Barad-Dur 不会存在这样的问题。\n体验3：自动重布局 Barad-Dur 的自动重布局功能非常强大，可以支持实时布局预览（当然市面上常见的大盘产品也支持），同时大盘的布局调整会根据具体操作（缩放、拖动）的方向进行。而市面上常见的大盘产品只能在垂直方向上进行布局调整，因为所用的算法非常简单，只是粗暴地把所有图表向页面上“推”。\n体验4：任意位置 Barad-Dur 的布局支持图表在任意位置摆放，而市面上常见的大盘产品由于上述的简陋算法，不支持此功能，所有的图表必须堆叠在页面的顶部。\n体验5：布局复位 Barad-Dur 的自动重布局能够在对单个图表进行调整时将其他图表“推开”，然后更强大的是可以再将被推开的图表复位。这里找到了市面上常见的大盘产品直接拿来用的开源布局框架进行对比。该框架其实提供了上述的任意位置功能，然而由于没有布局复位的功能，导致该功能一旦启用，会令整个大盘在编辑过程中布局被扰乱，对用户起不到任何帮助，所以市面上常见的大盘产品没有启用这个功能。\n体验6：文字编辑 Barad-Dur 支持在大盘中添加静态文字以及对于文字的编辑。静态文字可用于公告、标题、说明等一些常见的大盘场景。\n功能对比 Barad-Dur 市面上常见的大盘产品 任意拖动 ✔︎ ✔︎ 任意缩放 ✔︎ ✘ 多样图表 ✔︎ ✔︎ 图表实时编辑 ✔︎ ✔︎ 图表导入导出 ✔︎ ✔︎ 任意布局 ✔︎ ✘ 添加文字 ✔︎ ✘ 综上对比，可以看出 Barad-Dur 的 WYSIWYG 编辑器在各项功能上已经领先于市面上常见的大盘产品。\n控制器 大盘，即 Dashboard (in an automobile or similar vehicle) a panel beneath the front window having various gauges and accessories for the use of the driver; instrument panel。其本意是指汽车上的仪表板，这里的仪表板包括了两类组成部分：监视器、控制器。在仪表板上不仅能看到汽车的当前状态，也能对汽车进行各种控制。这是大盘的本意，但是就目前看来，市面上所有的监控大盘产品都缺失了控制器这个重要的组成部分，导致监控大盘其实只是监视大盘。如果只是用来监视的，那大盘独立存在就没有意义，就像汽车的仪表板上只有转速表、时速表、里程表，却没有油门、刹车、换挡杆。\n我们再来看几个工业产品的大盘：\n面向普通消费者的量产产品\n面向专业消费者的量产产品\n面向专家的定制产品\n控制器是不可或缺的组成部分，甚至比监视器更加重要。Barad-Dur 提供了在大盘中设置控制按钮的功能，可以实现一些简单的控制，比如关闭/启动报警、打开钉钉聊天窗口、启动控制预案等。日后会不断加入更加强大的控制功能，让蚂蚁金服监控大盘变成一个完整的监控系统。\n技术实现 自定义数据源 上文提到 Barad-Dur 支持二次开发，支持自定义数据源，仅需一点点工作即可接入自己的数据源：\n 继承 AbstractDatasource，并实现 doRequestData 接口； 调用 registerDatasource 将数据源注册至 Barad-Dur（如果使用 Barad-Dur 的数据源编辑器，可在注册时指定自定义的数据源的编辑器）； Barad-Dur 会对所有的数据源进行包装，提供缓存、增量加载、请求合并等功能。\n统一时序数据源 为了实现自定义数据源能够在任意图表中正确展现，Barad-Dur 定义了一种 universal 的时序数据格式，支持多 key 以及多 value。所有的时序数据源（以后可能会支持非时序数据源）都会将查询结果转换为这种格式，所有的图表也都会使用这种数据格式进行展现。\n使用统一数据格式的优势在于，图表和数据源都是按照同样的数据接口（约定）来实现的，所以图表和数据源是可以独立变化的。即图表可以任意切换而不需要改动数据源配置，数据源也可以任意切换而不需要调整图表配置。这是市面上常见的大盘产品做不到的。\n另一大优势在于计算。Barad-Dur 支持数据源的简单前端计算（如计算比率的场景需要将数据 A 与数据 B 相除），在使用了统一的数据格式之后，将计算也视为一个时序数据源，它的输入是一组时序数据源，也就是说一个计算数据源可以引用另一个计算数据源。这也是市面上常见的大盘产品做不到的。\nScene Graph Scene Graph 的概念常用于游戏引擎对于场景的渲染。由于场景中各个节点有父子关系且子节点的空间关系常常用相对于父节点的量来表示，所以需要一种数据结构来将这些 local 空间的量（translation、rotation）转变为 global 空间的量，才能最终转换成屏幕空间的量用于渲染。 …","date":1592463600,"description":"本文将介绍蚂蚁金服监控产品在监控大盘方面的创新设计与尝试。","dir":"blog/antfin-monitoring-cloud-native-observable-market-design-overview/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"30e37e5824f0c80a9aef838c5db03a3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","publishdate":"2020-06-18T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","summary":"背景 蚂蚁金服业务自定义监控是蚂蚁金服监控产品中的一个重要功能，主要是通过自定义日志数据源并配置大盘的方式来解决蚂蚁金服业务实时监控的需求。在","tags":["智能监控"],"title":"蚂蚁金服智能监控云原生可观测大盘设计概览","type":"blog","url":"/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/","wordcount":3490},{"author":"涵畅","categories":"Service Mesh","content":" 前言 几乎所有人都在说 Service Mesh；貌似没人知道怎么落地 Service Mesh；但是大家都觉得其他人在大力做 Service Mesh；所以大家都宣称自己在做 Service Mesh。\n上面只是开一个玩笑，但是从某种程度反映了一些实际情况：Service Mesh 是一种设计思想和理念，而不是具体的架构或者实现方式，虽然 Istio+Envoy 的配置似乎已经成了事实标准，当我们环顾四周，却发现理想太丰满，现实太骨感，因为各企业当前切实原因，导致各种形态的 Service Mesh 百花齐放。\n蚂蚁金服的 Service Mesh 就属于上面提到的百花齐放中的一员，我们已经渡过探索期，全面进入生产应用。去年的双十一完成了交易支付核心链路，几十万容器规模的生产级验证。但是业界对于 Service Mesh 仍然有很多种不同的声音，一方面是众星捧月式的支持，另一方面是困惑和质疑，包括对价值、架构以及性能的质疑。那么我们对此是什么态度？双十一深度实践之后蚂蚁金服的 Service Mesh 路又在何方？Service Mesh 架构是终点吗？\n本文将结合蚂蚁金服内部实际场景以及思考，讲述继 2019 双十一之后，蚂蚁金服在 Service Mesh 路上的规划和持续演进。\n蚂蚁金服 Service Mesh 实践回顾 上图是 2019 年蚂蚁金服双十一的实践架构，云原生网络代理 MOSN（https://github.com/mosn）作为蚂蚁金服自研数据面产品，承载了 Mesh 架构的东西向流量。对于控制平面，基于务实的前提我们探索出一套当前阶段切实可行的方案，基于传统服务发现体系落地了 Service Mesh 架构。\n这里是数据化的落地总结，在满足业务的同时，我们真正做到了对业务的低侵入：极低的资源消耗以及快速迭代能力，业务和基础技术都享受到云原生 Mesh 化所带来的红利。\nService Mesh 前路漫漫 我们再来看看 InfoQ 发布的 2020 年 4 月份 Software Architecture and Design 趋势报告，Service Mesh 目前处于 Early Adoption 代，在云原生技术圈仍处于大热阶段，各种技术论坛我们都能见到 Mesh 架构的专场，本篇文章我们不过多讨论 Service Mesh 的选型、使用场景、合理性等等问题，需要的同学可以参考一下文末历史文章，有很多蚂蚁金服对 Service Mesh 的思考。\n对于我们来说，既然在深度思考后选择了这条路，并且在去年双十一进行了深度实践，那么棋到中盘，下一步应该如何落子，除了务实落地之外，我们还要仰望星空，必须知道离诗和远方还有哪些 Gap：\n非全面云原生 前面提到我们落地 Service Mesh 时，仍然采用了传统微服务体系，虽然整体架构基于 K8s，但在控制面上并没有采用社区的方案，当然这些是有考虑的，但是随着整体架构的演进，非全面云原生化势必会成为我们持续享受云原生红利的最大障碍。\n平台能力不足 Service Mesh 的定位是解耦基础设施与业务，但是目前看来，不管是社区 Istio+Envoy 的组合，还是蚂蚁金服传统微服务+MOSN 的实践，均是把东西流量的治理作为了重点，离诗和远方还有很长的路。目前还有大量的基础设施逻辑作为 SDK 镶嵌在业务系统中，我们仍然要面临基础设施升级对业务带来的影响。\n边界流量覆盖不全 随着云原生在数据中心内部愈演愈烈，但是对于数据中心边界以及边缘网络，七层应用网络流量仍然没有形成一个全局体系，由于体系的缺失我们不得不在边界网关与 Mesh 网络两者之间各自分裂发展，均有独立的流量调度体系以及安全可信体系。\n生态融合度低 传统服务体系发展了这么多年，积累了大量宝贵的财富，Service Mesh 作为新贵出现，从两个方面来说：Service Mesh 需要传统服务体系的融入支撑，才能使现有业务迁移到 Mesh 体系；同时传统服务体系的组件也需要有和 Mesh 体系融合的能力才能持续保持竞争力。\n性能 性能是一个老生常谈的问题，Mesh 架构中质疑性能的声音也层出不穷 ，包括 Mixer 控制面，还有引入 Sidecar 造成的额外网络消耗、编解码消耗等等。不过我们可以看到社区一直在解决这些问题，包括对 Mixer 架构的重构，引入 ebpf 来加速流量劫持等等。\n综上所述，我们在 Service Mesh 上任重道远。\n将 Service Mesh 进行到底 今年我们的目标是 Mesh 全面覆盖主要业务，这将面临非常大的挑战：\n 金融级安全可信的要求，需要我们做到全链路加密与服务鉴权； 统一 Sidecar 与 Ingress Web Server； 云原生控制面的落地； 透明劫持能力； 需要承载更多的中间件能力下沉； 上面分析了目前存在的各种问题，同时结合蚂蚁金服自身的业务发展需求，那么我们可以很清晰的对症下药了，我们将上述问题抽象成三类，并进行专项攻坚：\n 以开源生态建设，来应对生态融合问题； 通过云原生标准演进，来解决非全面云原生问题； 最后通过基础核心能力增强，来治理平台能力，覆盖场景以及性能的不足的问题； 开源生态建设 我们再来回顾一下双十一之后我们做的第一个动作：在 2019 年 12 月 28 日由蚂蚁金服主办的第九期 Service Mesh Meetup 上，我们对外宣布了 MOSN 完成在 SOFAStack 的孵化，开始独立运营，以更加开放的姿态寻求合作共建伙伴：\n我们认为，未来会更多地属于那些告别大教堂、拥抱集市的人们。《大教堂与集市》\n在宣布独立运营的同时，我们也做了一系列措施：\n 独立的项目域名：mosn.io 项目地址：github.com/mosn/mosn 社区组织：MOSN Community Organization 项目管理条例：PMC、Committer 选举晋升机制等等 接下来，开源社区我们也持续做了非常多的事情，包括专题 Working Group的创建，例如 Isito WG， Dubbo WG 等等。\n同时也寻求了非常多的外部合作，超过一半的 contributor 均来自外部，接受了第一个来自 BOSS 直聘的 Committer 等等，针对生态融合，我们同Skywalking，Sentinel和Dubbo-go社区进行了深度合作。\nSkywalking 调用依赖以及服务与服务之间的调用状态，是微服务管理中一个重要指标。Skywalking 是该领域非常优秀的一款 APM 软件，MOSN 与 Skywalking 社区展开了合作，进行了两个系统的深度整合工作，目前支持：\n 调用链路拓扑展示； QPS 监控； 细粒度 RT 展示； 在今年五月份，SkyWalking 8.0 版本进行了一次全面升级，采用新的探针协议和分析逻辑，探针将更具互感知能力，更好的在 Service Mesh 下使用探针进行监控。同时，SkyWalking 将开放之前仅存在于内核中的 Metrics 指标分析体系。Prmoetheus、Spring Cloud Sleuth、Zabbix …","date":1592298000,"description":"本文将结合蚂蚁金服内部实际场景以及思考，讲述继 2019 双十一之后，蚂蚁金服在 Service Mesh 路上的规划和持续演进。","dir":"blog/service-mesh-the-road-ahead-long/","fuzzywordcount":7300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"81941474b0c2d163a199a461aaa3f2f3","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-the-road-ahead-long/","publishdate":"2020-06-16T17:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/service-mesh-the-road-ahead-long/","summary":"前言 几乎所有人都在说 Service Mesh；貌似没人知道怎么落地 Service Mesh；但是大家都觉得其他人在大力做 Service Mesh；所以大家都宣称自己在做 Service Mesh。 上","tags":["Service Mesh","源创会"],"title":"再启程，Service Mesh 前路虽长，尤可期许","type":"blog","url":"/sofastack.tech/blog/service-mesh-the-road-ahead-long/","wordcount":7212},{"author":"霄鸿","categories":"Service Mesh","content":" 引言 Service Mesh 是目前社区最为炙手可热的技术方向，去年双11在蚂蚁金服得到全面的应用，并平稳顺滑的支撑了大促服务。作为目前规模最大的 Service Mesh 集群，本文从监控的领域对 Service Mesh 落地进行经验总结，主要从以下几方面进行介绍：\n 云原生监控，介绍蚂蚁金服 Metrics 监控的落地； 用户视角分析，介绍从应用 owner 的角度对这一基础服务设施的体验以及 SRE 从全站服务的稳定性对监控提出的要求； 未来的思考，介绍后续发展方向； 云原生监控 云原生应用的设计理念已经被越来越多的开发者接受与认可，今年蚂蚁金服应用服务全面云原生化，对我们监控服务提出更高的要求。目前 Metrics 指标监控服务也逐渐形成体系，如下图所示基于社区原生 Prometheus 采集方案在蚂蚁金服监控场景下落地。\n怎么采集 蚂蚁金服监控采集 AGENT 是部署在物理机上，支持多个采集插件，如下图，包括执行命令、日志、HTTP 请求、动态 SQL 采集、系统指标采集、JVM 采集以及进程监控等，同时支持多个解析插件自定义解析、单行文本解析、Lua 脚本解析、JSON 解析以及 Prometheus 解析等。\n在Service Mesh 监控落地中，业务方参考业界标准输出 Metrics 指标数据，监控采集该物理机不同 Pod、App 和 Sidecar 的各项指标，包含 Metrics 指标和系统服务指标（CPU、MEM、DISK、JVM、IO 等），然后计算清洗集群节点通过拉取最近周期数据进行数据汇总、groupby 等，数据采集周期又分为：5秒级数据和分钟级数据。 对于 Service Mesh 来说，主要关注的指标有系统指标和 Metrics 指标：\n 系统指标（包括 Pod、App 和 MOSN 等 Sidecar 多个维度的系统指标）： 系统指标, 包含 CPU、LOAD、MEM、BYTES、TCP、UCP 等信息； 磁盘，包含分区可用空间、使用率等信息； IO，包含 IOPS 等信息； Metrics 指标： PROCESSOR，包含 MOSN 进程打开的 fd 数量、申请的虚拟内存大小等进程资源信息； GO，包含 MOSN 进程 goroutine 数量(G)、thread 数量(M)以及 memstats 等 go runtime 信息； Downstream，包含全局下游累计建链数、总读取字节数、累计请求数、请求耗时等； Upstream，包含上游请求失败次数、集群累计建链数、累计断链数、异常断链次数、上游请求平均耗时等； MQ Mesh，包含发送消息总数、耗时、失败数等以及消费消息总数、耗时、失败数等； Gateway Mesh，包含 qps、rt、限流以及多维度的成功数和失败数等； 数据计算 对于 Agent 采集的数据需要从不同维度向上汇聚，满足不同用户对不同视角（LDC、IDC、APP、架构域、站点等视角）的数据需求，以适配蚂蚁金服运维架构体系。\n此时对于这么大规模的数据体系，我们团队建设蚂蚁金服统一的监控数据计算平台。\n 使用统一的监控数据标准、插件化的数据采集接入、通用的数据服务 API 服务来帮助不同的监控产品的快速迭代； 建立一套健全的数据质量体系、高可用计算集群来保障监控数据质量； 通过类 SQL 任务定义、自定义计算任务、插件化来提供丰富、开放的数据分析能力，来满足技术风险业务领域下各种复杂数据分析的需求； 其中计算任务调度（spark）执行的关键组件包括 GS(Global-Scheduler 全局图调度)和 CS (Compute-Space 计算空间)。\nGS 是平台的任务调度中心，如下图所示，它收集了所有业务的数据源配置，根据数据源之间的计算关系，构建出全局计算任务拓扑模型(GlobalGraph)。再根据不同的任务执行策略，将全局任务拓扑图切割成小范围的任务拓扑(Graph)。主要特性有：\n GS 根据任务优先级、资源质量、负载情况等策略，将 Graph 分发到不同的计算空间进行计算(Cspace)； 同一个 Graph 内部的数据依赖是计算过程中直接依赖的； 不同的 Graph 之间的数据依赖会通过存储进行数据解耦； GS 会管理所有 Graph 及计算节点的任务状态，根据 Graph 的依赖关系和依赖 Graph 的执行状态，控制 Graph 的执行时间； CS 是计算平台抽象的计算任务执行空间，如下图所示，主要负责 Graph 的解析和具体计算任务的提交执行，适用于不同的计算引擎，如 Spark/Flink。以 Spark 为例，CS 接收到 GS 发出的 GraphTask，根据 GraphTask 中的 Node(Transform) 解析成 Spark 的 Transfomation 算子和 Action 算子，组成计算 DAG 并提交到 Spark 集群执行。\n在任务执行过程中，CS 会向 GS 同步各任务的执行状态，用于任务跟踪监控。\n多个 CSpace 组成一个 CSpaceGroup，CSpace 之间可以根据负载均衡、资源等级、蓝绿发布等具体场景划分不同的计算分组，多个 CSpace 之间的任务切流可以满足负载均衡、资源隔离、蓝绿发布、灰度等高可用的要求。\n规模化问题 对于蚂蚁金服这么大规模的 Service Mesh 集群数据，产品请求无法都通过 PromQL 方式实时查询结果，以及报警及时通知。此时我们对于监控数据进行分类，其中应用、机房、站点等维度数据进行预计算聚合，例如不同机房的 QPS、RPC 转发成功量、Error 错误等等，前端通过自定义配置出自己关注的大盘视图。\n其中今年大促 MOSN 容器达到几十万，在频繁的发布部署，上线下线过程中，对监控查看的实时性提出更高的要求。其中 Meta 元数据模块对接 K8s 集群，部署监控 operator 监控容器状态变化，达到秒级将最新采集配置通过 Agent registry 更新到 Agent 模块。\n大促保障 我们一方面对监控高可用进行保障，做到采集计算水平扩缩容，另一方面对容量进行评估，通过对不同任务进行分级处理，在大促的时候对高优先级任务进行重点保障，对低优先级任务和业务方进行沟通做降级处理。这样在监控计算资源紧张的情况下，保障核心数据稳定。\n产品视角 Service Mesh 是蚂蚁金服内部应用服务所使用的基础服务设施，对不同的用户看的视角不一样。在监控产品上，用户对产品的使用主要集中在“配、看、用”数据这三个层面。我们早期也做过类似的用户分析。在蚂蚁金服按使用方式将用户分为全局关注者，产品 owner、SRE、领域专家和普通用户等，这里监控产品对于 Service Mesh 也提供不同的视角满足不同的用户需求，举例来说：\n 产品 Owner 视角：特指 MOSN 产品的开发们，他们重点负责 MOSN 的监控指标数据覆盖、数据准确性以及重点调优目标； 普通用户视角：特指应用 Owner，应用 Owner 主要看 MOSN 服务对应用 RPC 调用的影响以及该应用使用 MOSN 服务带来的效率提升； SRE 视角：他们 …","date":1592204400,"description":"作为目前规模最大的 Service Mesh 集群，本文从监控的领域对 Service Mesh 落地进行经验总结","dir":"blog/antfin-service-mesh-monitor-landing-experience/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5728ecea53b7505a29fdd8d498a8f111","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","publishdate":"2020-06-15T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","summary":"引言 Service Mesh 是目前社区最为炙手可热的技术方向，去年双11在蚂蚁金服得到全面的应用，并平稳顺滑的支撑了大促服务。作为目前规模最大的 Service Mesh 集群，本文从","tags":["Service Mesh","智能运维"],"title":"蚂蚁金服在 Service Mesh 监控落地经验总结","type":"blog","url":"/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/","wordcount":3749},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 这里有个机会和 SOFAStack 一起玩，你要不要来？ 阿里巴巴编程之夏（Alibaba Summer of Code，以下简称 ASoC）是面向全球18岁及以上本科、硕士、博士高校学生的编程普惠计划，鼓励高校学生深度参与开源开发活动，以第一视角感受开源世界的魅力，成为开源社区新鲜“血液”。\n今年 SOFAStack 开源社区也加入了选题，有兴趣的同学可以尝试下以下 feature：\nSOFAJRaft\n是基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 RAFT 相关的技术难题，并且 SOFAJRaft 非常易于使用。\n Feature1:当前 LogStorage 的实现，采用 index 与 data 分离的设计，我们将 key 和 value 的 offset 作为索引写入 rocksdb，同时日志条目（data）写入 Segnemt Log，因为使用 SOFAJRaft 的用户经常也使用了不同版本的 rocksdb，这就要求用户不得不更换自己的 rocksdb 版本来适应 SOFAJRaft， 所以我们希望做一个改进：移除对 rocksdb 的依赖，构建出一个纯 java 实现的索引模块。这个 feature 难度适中，https://github.com/sofastack/sofa-jraft/issues/453\n Feature2:这个 feature 更有挑战些，在 multi raft group 场景中，可能有多个 raft node 在同一个进程中并且很多都是 leader，当他们各自向自己的 followers 发送心跳时会过多的消耗 CPU 和网络 IO。例如我们可以在同一个进程内共享心跳计时器并将这些 leaders 发往同一台机器的心跳请求合并起来发送出去，以此来减少系统消耗，当然你还可以提供更多的优化方案。欢迎尝试 https://github.com/sofastack/sofa-jraft/issues/454\n SOFABolt\n是基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，我们把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。\n Feature：当前的SOFABolt实现中私有协议是直接和整体框架耦合在一起的，在使用SOFABolt的同时需要使用提供的私有协议，当用户希望使用自己的自定义协议时需要进行比较有挑战的代码拓展才能实现。因此我们希望对SOFABolt的协议框架做一些重构以支持快速方便的集成用户的自定义协议。这个 feature 稍有难度，欢迎尝试，https://github.com/sofastack/sofa-bolt/issues/224 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@明詹 提问：\n 问下 SOFATracer 现在支持 RabbitMQ 吗？\n A：原生 RabbitMQ API ，Tracer 是没有埋点的；如果和 Spring 集成的，可以基于 Spring Message 方式埋点。使用最新版本即可。 SOFATracer：https://github.com/sofastack/sofa-tracer\n2、@雷霆 提问：\n 请问一下，如果 TCC 在提交全局事务时失败了，比如网络或者 TC 服务异常，导致 TC 压根没有收到全局事务提交的通知，此时 TM 会抛一个异常，导致整个业务处理失败，这个时候已经在一阶段冻结的资源还会回滚吗？看了 Seata 源码，对于这种情况没有看到有触发回滚的操作。\n A：TCC 先注册分支再执行 Try，如果注册分支失败那么 Try 不会执行，如果注册分支成功了 Try 方法失败了，那应该抛出异常触发主动回滚或者触发 Server 超时回滚。\n 那如果分支已经注册成功，且 Try 也执行成功了，就是在 TM 向 TC 发起 global commit 时失败了，TM 多次重试失败后抛了异常，TC 没有收到 commit，这种情况下还会有 rollback 吗？\n A：这种情况触发超时回滚，TC 主动来回滚超时的事务。\n 明白了 谢谢~\n Seata：https://github.com/seata/seata\n本周推荐阅读 记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化 Forrester 中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求 社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1591945200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200612/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a85bdf92bd596c0809df4b4464b8a85b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200612/","publishdate":"2020-06-12T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200612/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 绝妙的机会与 SOFAStack 一起玩、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200612/","wordcount":2201},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析\n 活动时间：7 月 2 日周四晚 7 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#16：不得不说的云原生隔离性 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。本期分享将介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1265\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 不得不说的云原生隔离性 丞一 SOFABolt 开源负责人\n你将收获 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 嘉宾 SOFAGirl 主持人 丞一 SOFABolt 开源负责人 ","date":1591945200,"description":"7 月 2 日周四晚 7 点，线上直播第 17 期。","dir":"activities/sofa-channel-17/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6b021a35ee168e2bc4cb3350c6828d68","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-17/","publishdate":"2020-06-12T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-17/","summary":"概要 活动主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 活动时间：7 月 2 日周四晚 7 点 活动形式：线上直播 报名方式：戳","tags":["SOFAChannel","SOFABolt"],"title":"SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-17/","wordcount":574},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" 6月9日，在2020阿里云线上峰会上，蚂蚁联合全球知名市场研究与咨询机构 Forrester 发布《蚂蚁 SOFAStack 总体经济影响报告——金融级云原生市场趋势以及云原生平台带来的成本节省和业务优势》（以下简称“白皮书”）。《白皮书》指出，随着云计算在各行各业的落地不断深化，被技术赋能的企业早已加速构建企业级平台，通过推进数字化转型来塑造可持续的竞争力。其中云平台使能新型基础设施，赋能数字商业模式，成为了社会经济新旧动能转换和信息化应用创新发展的重要数字底座。\n云原生技术已趋向成熟 为金融企业带来全新业务价值与技术优势 Forrester 首席分析师戴鲲表示，越来越多的企业正在借助以云计算为代表的数字技术的巨大潜力，不断提供数字化的客户体验，改进卓越运营能力，加速数字创新进程，构建和扩展数字生态体系，从而加速数字化转型来塑造可持续的竞争力。\n他指出，尤其是一些积极采用新兴技术的泛金融企业，更在加速构建企业级云平台，取得了显著的早期业务成果。而伴随着在应用基础设施、应用软件架构、开发模式与部署架构四个层面协同进化与趋向成熟，云原生技术已为包括金融行业在内的各行各业的企业与机构带来了全新的业务价值与技术优势，具体表现在：\n应用基础设施 从物理机和虚拟机向大规模容器集群进化 容器技术可以实现更高密度的宿主机部署能力和伸缩性，提供更好的性能、更低的空间占用率以及更高的资源利用率，可以实现基础架构的自动化与高效率，帮助金融企业更好地满足大规模互联网业务的动态工作负载支撑要求，从而为客户获得一致的差异化体验提供有效保障。\n应用软件架构 从集中式单体和多层架构向分布式微服务架构进化 微服务框架进一步增强了应用架构伸缩性，通过模块化的复用能力与渐进式的变更能力加速应用价值交付；服务网格为微服务应用带来更为强大的服务间网络连接、可见性和安全性；无服务器计算以全新的编程模型实现应用松耦合和自动伸缩性，有效屏蔽基础架构的复杂性；而边缘计算与物联网技术的发展也使得企业计算架构从中心化向分布式演进，加速洞察的获得与决策反馈的闭环。\n开发模式 从瀑布式和敏捷式向 DevOps 进化 容器技术可以提供良好定义、一致的、高度可迁移的应用软件包，帮助改善开发和运营团队之间的协作过程。而微服务架构的细粒度可重用模块化特性可以帮助技术部门通过技术组件与业务服务的动态组装，通过与持续集成和持续交付流水线的有效集成，实现面向 DevOps 的软件交付，从而加速企业创新进程，有效提升市场响应效率，迅速满足企业内部不同业务部门与区域环境的差异化客户与业务需求。\n运营模式 从单一云环境向混合私有云与公有云的多云环境进化 根据 Forrester 的研究，面向多云、混合云环境的云平台管理能力已经成为了中国乃至全球企业的常态化需求。企业不仅需要在基础架构层面实现跨集群发布部署和跨云平台管控，而且需要具备面向异构资源的一体化管理能力，包括虚机与容器集群的混合管控、经典多层架构与微服务架构的混合支持、传统开发框架与包括大数据和机器学习等在内的新兴技术框架混合使能等。\n如何借助合作伙伴力量 以平台化方式构建金融级云原生能力？ 在迈向云原生的路上，新兴技术带来战略业务价值的同时，也必然引入更多的不确定性。一方面云原生技术依然处在快速演进阶段，距离金融行业所需要的在云端运行关键任务系统的金融级特性仍存在显著差距，另一方面，云原生技术本身在应用架构、开发测试部署过程、应用重构与迁移路径以及系统运维等各个领域都具有技术和管理复杂性。\n戴鲲指出，金融机构在云原生技术的落地实践过程中，必须通过审慎务实的整体战略规划，以平台化的方式有效构建金融级云原生能力，借助合作伙伴的技术深度、生态系统广度以及相关行业实践的专业度，加速可持续的信息化应用创新，真正释放数字基础设施的巨大潜能，需要从以下三大领域进行考虑。\n面向架构敏捷性 构建稳健的集成技术平台，打造业务创新引擎 金融行业的传统企业在长期发展历程中往往积累了大量的技术资产，因此，金融级云原生平台不仅必须具备融合支持能力，还应当以工具化、产品化的方式，帮助开发与运维团队实现云原生应用的快速开发迭代与对存量应用资产的平滑迁移，从而加速金融业务创新进程。\n聚焦业务连续性 基于金融技术风险防控，保障业务稳妥演进 金融级云原生平台必须能够在混合环境下，具备业务同城双活甚至异地多活的高可用容灾能力，而且能够基于单元化架构和数据分片等技术，实现多活容灾的单元化。同时，还应当具备灵活可控的应用发布进程，通过按需暂停回滚、分组灰度发布和原地升级等能力，实现应用的平滑演进；并具备可定制的流程编排能力，实现巡检诊断与容灾应急的自动化。\n追求运维精益性 关注安全可信稳定连续，降低运维保障成本 首先，金融级云原生平台必须具备基于策略的弹性规则配置能力，并通过多维度资源分析、网络流量调拨、实时指标评估以及灵活的回滚方式支持等技术，实现优雅的弹性伸缩。其次，平台必须为全链路可观测性提供支持，不仅提供多维度的监控数据，而且具备场景化的支持能力。最后，平台必须从应用视角出发，结合服务目录、服务网格、日志服务、链路跟踪等技术组件，为大规模分布式业务系统提供可视化的自动化运维能力，有效简化云原生运维过程。\nForrester 为众多希望推动完成数字化转型的金融企业和机构在云计算发展领域提出了以上有关发展方向的战略建议。蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）作为构建金融级云原生架构的应用平台，沉淀了金融场景的最佳实践。在企业面向金融级环境采用云原生技术过程中面临困难时，蚂蚁 SOFAStack 能够提供从服务构建、应用开发、部署发布、服务治理、监控运维、容灾高可用等全生命周期、全栈式解决方案，兼容 Dubbo、Spring Cloud 等微服务运行环境，助力客户各类应用轻松转型分布式架构。\n点击，获取完整 《白皮书》\n","date":1591858800,"description":"云原生技术已趋向成熟 为金融企业带来全新业务价值与技术优势","dir":"blog/forrester-daipeng-white-paper-cloud-native/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"eb590c61c39c7b48afdb5abd95889b99","permalink":"https://sofastack.github.io/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","publishdate":"2020-06-11T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","summary":"6月9日，在2020阿里云线上峰会上，蚂蚁联合全球知名市场研究与咨询机构 Forrester 发布《蚂蚁 SOFAStack 总体经济影响报告——金融级云原生市场趋势以及云原生平台","tags":["SOFAStack","云原生"],"title":"Forrester 中国首席分析师戴鲲：云原生技术趋向成熟，金融企业选择云原生平台需满足三大要求","type":"blog","url":"/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/","wordcount":2340},{"author":"诣极","categories":"MOSN","content":" 背景 蚂蚁金服内部对 Service Mesh 的稳定性和性能要求是比较高的，内部 MOSN 广泛用于生产环境。在云上和开源社区，RPC 领域 Dubbo 和 Spring Cloud 同样广泛用于生产环境，我们在 MOSN 基础上，支持了 Dubbo 和 Spring Cloud 流量代理。我们发现在支持 Dubbo 协议过程中，经过 Mesh 流量代理后，性能有非常大的性能损耗，在大商户落地 Mesh 中也对性能有较高要求，因此本文会重点描述在基于 Go 语言库 dubbo-go-hessian2 、Dubbo 协议中对 MOSN 所做的性能优化。\n性能优化概述 根据实际业务部署场景，并没有选用高性能机器，使用普通 Linux 机器，配置和压测参数如下：\n Intel\u0026amp;reg; Xeon\u0026amp;reg; Platinum 8163 CPU @ 2.50GHz 4核16G； pod 配置 2c、1g，jvm 参数 -server -Xms1024m -Xmx1024m； 网络延迟 0.23ms, 2台 Linux 机器，分别部署 server+MOSN, 压测程序 rpc-perfomance； 经过3轮性能优化后，使用优化版本 MOSN 将会获得以下性能收益(框架随机512和1k字节压测)：\n 512字节：MOSN+Dubbo 服务调用 tps 整体提升55-82.8%，rt 降低45%左右，内存占用 40M； 1k数据：MOSN+Dubbo 服务调用 tps 整体提升51.1-69.3%，rt 降低41%左右, 内存占用 41M； 性能优化工具 pprof 磨刀不误砍柴工，在性能优化前首先要找到性能卡点，找到性能卡点后，另一个难点就是如何用高效代码优化替代 slow code。因为蚂蚁金服 Service Mesh 是基于 Go 语言实现的，我们首选 Go 自带的 pprof 性能工具，我们简要介绍这个工具如何使用。如果我们 Go 库自带 http.Server 时并且在 main 头部导入import _ \u0026amp;quot;net/http/pprof\u0026amp;quot;，Go 会帮我们挂载对应的 handler, 详细可以参考 godoc 。\n因为 MOSN 默认会在34902端口暴露 http 服务，通过以下命令轻松获取 MOSN 的性能诊断文件：\ngo tool pprof -seconds 60 http://benchmark-server-ip:34902/debug/pprof/profile # 会生成类似以下文件，该命令采样cpu 60秒 # pprof.mosn.samples.cpu.001.pb.gz 然后继续用 pprof 打开诊断文件，方便在浏览器查看，在图1-1给出压测后 profiler 火焰图：\n# http=:8000代表pprof打开8000端口然后用于web浏览器分析 # mosnd代表mosn的二进制可执行文件，用于分析代码符号 # pprof.mosn.samples.cpu.001.pb.gz是cpu诊断文件 go tool pprof -http=:8000 mosnd pprof.mosn.samples.cpu.001.pb.gz 在获得诊断数据后，可以切到浏览器 Flame Graph(火焰图，Go 1.11以上版本自带)，火焰图的 X 轴坐标代表 CPU 消耗情况，Y 轴代码方法调用堆栈。在优化开始之前，我们借助 Go 工具 pprof 可以诊断出大致的性能卡点在以下几个方面(直接压 Server 端 MOSN)：\n MOSN 在接收 Dubbo 请求，CPU 卡点在streamConnection.Dispatch； MOSN 在转发 Dubbo 请求，CPU 卡点在 downStream.Receive； 可以点击火焰图任意横条，进去查看长方块耗时和堆栈明细（请参考图1-2和1-3所示）：\n性能优化思路 本文重点记录优化了哪些 case 才能提升 50%+ 的吞吐量和降低 rt，因此后面直接分析当前优化了哪些 case。在此之前，我们以 Dispatch 为例，看下它为啥那么吃性能 。在 terminal 中通过以下命令可以查看代码行耗费 CPU 数据（代码有删减）：\ngo tool pprof mosnd pprof.mosn.samples.cpu.001.pb.gz (pprof) list Dispatch Total: 1.75mins 370ms 37.15s (flat, cum) 35.46% of Total 10ms 10ms 123:func (conn *streamConnection) Dispatch(buffer types.IoBuffer) { 40ms 630ms 125:\tlog.DefaultLogger.Tracef(\u0026amp;quot;stream connection dispatch data string = %v\u0026amp;quot;, buffer.String()) . . 126: . . 127:\t// get sub protocol codec . 250ms 128:\trequestList := conn.codec.SplitFrame(buffer.Bytes()) 20ms 20ms 129:\tfor _, request := range requestList { 10ms 160ms 134:\theaders := make(map[string]string) . . 135:\t// support dynamic route 50ms 920ms 136:\theaders[strings.ToLower(protocol.MosnHeaderHostKey)] = conn.connection.RemoteAddr().String() . . 149: . . 150:\t// get stream id 10ms 440ms 151:\tstreamID := conn.codec.GetStreamID(request) . . 156:\t// request route . 50ms 157:\trequestRouteCodec, ok := conn.codec.(xprotocol.RequestRouting) . . 158:\tif ok { . 20.11s 159:\trouteHeaders := requestRouteCodec.GetMetas(request) . . 165:\t} . . 166: . . 167:\t// tracing 10ms 80ms 168:\ttracingCodec, ok := conn.codec.(xprotocol.Tracing) . . 169:\tvar span types.Span . . 170:\tif ok { 10ms 1.91s 171:\tserviceName := tracingCodec.GetServiceName(request) . 2.17s 172: …","date":1591686000,"description":"本文将重点描述在基于 Go 语言库 dubbo-go-hessian2、Dubbo 协议中对 MOSN 所做的性能优化。","dir":"blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2584f4b7cd5bf07fb458ef9fbe60433c","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","publishdate":"2020-06-09T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","summary":"背景 蚂蚁金服内部对 Service Mesh 的稳定性和性能要求是比较高的，内部 MOSN 广泛用于生产环境。在云上和开源社区，RPC 领域 Dubbo 和 Spring Cloud 同样广泛用于生产环境，我们在","tags":["MOSN"],"title":"记一次在 MOSN 对 Dubbo、Dubbo-go-hessian2 的性能优化","type":"blog","url":"/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/","wordcount":4450},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@林尤庆 提问：\n 请问 SOFARPC 支持 fegin 不？\n A：SOFARPC 发的 rest 服务，feign 的方式是可以调用的，但是跟 ribbon 是没打通的。\n 有具体的例子不？\n A：https://github.com/sofastack/spring-cloud-sofastack-samples\n 我想问下 SOFARegistry 能像 Nacos 那样注册的是整个服务的名称么，现在 SOFARegistry 是细到接口。Spring Cloud是以整个应用注册的，SOFARegistry 是以每一个SofaServicce 注册的。\n A：SOFARegistry 和 Nacos 都是注册中心服务端产品，存的都是 key: list\u0026amp;lt; string \u0026amp;gt; 这样的数据结构，里面存什么数据是由他们的客户端决定的。SOFARPC 就算是注册中心的客户端。\n SOFARegistry 是以每一个 SofaServicce 注册的，fegin 访问的话也是每一个 SofaServicce 去访问的，不是整个应用访问的？\n A：跟 SOFARegistry 没关系，是 SOFARPC 的实现，目前按接口维度注册的。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n2、@姜哲 提问：\n SOFARPC 能发布一个 https 协议的服务吗？\n A：https 不行，h2（http/2+tls）是可以的。\n SOFABoot 环境下怎么发布？有 Demo 吗？\n A：基于 SOFABoot 可能没有适配， 可以先看下 API 方式的： https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/http2/Http2WithSSLServerMain.java\nSOFARPC：https://github.com/sofastack/sofa-rpc\n本周推荐阅读 多点生活在 Service Mesh 上的实践 | 线上直播整理 Service Mesh 中的可观察性实践 | 线上直播整理 Apache SkyWalking 在 Service Mesh 中的可观察性应用 | 线上直播回顾 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 陌陌的 Service Mesh 探索与实践 | 线上直播回顾 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.13.0 版本，主要变更如下：\n 新增 Strict DNS Cluster、GZIP 处理、单机故障隔离； 集成 Sentinel 实现限流能力； 优化 EDF 算法，使用 EDF 算法重新实现 WRR 算法； 支持 Dubbo 服务发现 Beta 版本，优化 Dubbo Decode 性能； 部分实现优化与 Bug 修复； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.13.0\n社区活动报名 SOFABolt 是蚂蚁金服开源的一套基于 Netty 实现的，轻量、易用、高性能、易扩展的网络通信框架。在蚂蚁金服的分布式技术体系下，我们有大量的技术产品都需要在内网进行节点间的通信。每个产品都需要考虑高吞吐、高并发的通信，私有协议设计、连接管理、兼容性等问题。\n为了将开发人员从通信框架的实现中解放出来，专注于自己产品的能力建设上，我们将在微服务与消息中间件在网络通信上解决的问题以及积累的经验进行了总结，设计并实现了 SOFABolt。\n本期分享将邀请 SOFABolt 开源负责人丞一，介绍 SOFABolt 的基本功能和部分实现原理，并介绍协议框架的实现。\n你将收获：\n 了解 SOFABolt 的基础使用及 SOFABolt 部分功能的实现原理； 了解 SOFABolt 协议框架的设计以及如何拓展实现自定义私有协议； 了解如何设计一个通信框架； 活动详情：\n 直播主题：SOFAChannel#17：网络通信框架 SOFABolt 的功能介绍及协议框架解析 分享嘉宾：丞一，蚂蚁金服技术专家，主要从事通信中间件相关的开发工作，SOFABolt 开源负责人。 直播时间：2020/7/2（周四）19:00-20:00 直播间：点击“这里”，即可报名 ","date":1591340400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200605/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9ba8595438771312ed9c187e57789bad","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200605/","publishdate":"2020-06-05T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200605/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发版、Service Mesh 相关文章整理、社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200605/","wordcount":1488},{"author":"陈鹏","categories":"Service Mesh","content":" Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。\n 本文根据5月28日晚 Service Mesh Webinar#1 多点生活平台架构组研发工程师陈鹏，线上主题分享《多点生活在 Service Mesh 上的实践 \u0026amp;ndash; Istio + Mosn 在 Dubbo 场景下的探索之路》整理，文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处。如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点。\n今天主要给大家分享一下 Service Mesh 的一些技术点以及多点生活在 Service Mesh 落地过程中适配 Dubbo 的一些探索。\n首先我们从三个方面入手：\n 为什么需要 Service Mesh 改造； 探索 Istio 技术点； Dubbo 场景下的改造； 为什么需要 Service Mesh 改造 说到为什么需要改造，应该先说一下 Service Mesh 和传统微服务架构的一些特点。\n微服务 微服务一般有这些模块：\n 安全； 配置中心； 调用链监控； 网关； 监控告警； 注册和发现； 容错和限流； 这些模块在传统的微服务架构中有的是和 SDK 结合在一起，有的是一个独立的中间件。\n特点：\n 独立部署； 模块的边界； 技术多样性； 正是由于技术多样性，我的微服务系统可以使用不同的语言进行开发，比如我一个商城系统，订单系统使用 Java 开发，库存系统使用 Go 开发，支付系统使用 Python 开发，微服务之间通过轻量级通信机制协作，比如：HTTP/GRPC 等。比如目前多点使用的 Dubbo(服务治理框架)，随着多点生活的业务发展，目前遇到最棘手的问题就是中间件在升级过程中，推进很慢，需要业务方进行配合，接下来我们看看 Service Mesh。\nService Mesh 优点：\n 统一的服务治理； 服务治理和业务逻辑解藕； 缺点：\n 增加运维复杂度； 引入延时； 需要更多技术栈； 看了 Service Mesh 的优缺点，如果我们 Mesh 化了之后就可以解决我们目前的痛点，升级中间件只需要重新发布一下 Sidecar 就好了，不同语言开发的微服务系统可以采用同样的服务治理逻辑，业务方就可以尝试更多的技术。\n探索 Istio 技术点 在谈 Dubbo 场景下的改造之前我们先介绍一下 Istio 相关的技术点，然后结合 Dubbo 场景应该如何进行适配\nMCP MCP（Mesh Configuration Protocol）提供了一套用于订阅(Watch)、推送(Push)的 API，分为 Source 和 Sink 两个角色。\n Source 是资源提供方(server)，资源变化了之后推送给订阅者(Pilot)，Istio 1.5 之前这个角色就是 Galley 或者自定义 MCP Server； Sink 是资源的订阅者(client)，在 Istio 1.5 之前这个角色就是 Pilot 和 Mixer，都是订阅 Galley 或者自定义 MCP Server 的资源 MCP 的订阅、推送流程图:\n为了和实际情况结合，我们就以 MCPServer 作为 Source，Pilot 作为 Sink 来介绍订阅、推送流程，其中 MCP 通信过程中所传输的「资源」就是 Istio 定义的 CRD 资源，如：VirtualService、DestinationRules 等。\n订阅 Pilot 启动后会读取 Configmap 的内容，里面有一个 configSources 的一个数组配置（Istio 1.5 之后没有这个配置，需要自己添加）、存放的是 MCP Server 的地址； Pilot 连接 MCPServer 之后发送所关注的资源请求； MCPServer 收到资源请求，检查请求的版本信息（可能为空），判断版本信息和当前最新维护的版本信息是否一致，不一致则触发 Push 操作，一致则不处理； Pilot 收到 Push 数据，处理返回的数据（数据列表可能为空，为空也标示处理成功），根据处理结果返回 ACK（成功）/ NACK（失败），返回的应答中包含返回数据的版本信息，如果返回的是 NACK，Pilot 会继续请求当前资源； MCPServer 收到 ACK（和资源请求一致）之后对比版本号，如果一致则不推送，否则继续推送最新数据； 推送 MCPServer 自身数据发生变化，主动推送变化的资源给 Pilot； Pilot 收到之后处理这些数据，并根据处理结果返回 ACK / NACK； MCPServer 收到 ACK（和资源请求一致） 之后对比版本号，如果一致则不推送，否则继续推送最新数据； 这样的订阅、推送流程就保证了 MCPServer 和 Pilot 资源的一致。MCPServer 只能通过 MCP 协议告诉 Pilot 资源发生变化了么？当然不是，MCPServer 可以使用创建 CR 的方式，Pilot 通过 Kubernetes 的 Informer 机制也能感知到资源发生变化了，只是通过 MCP 传输的资源在 Kubernetes 里面看不到，只是存在于 Pilot 的内存里面，当然也可以通过 Pilot 提供的 HTTP debug 接口（istiod_ip:8080/debug/configz）来查。\nhttps://github.com/champly/mcpserver 提供了一个 MCPServer 的一个 demo，如果需要更加细致的了解 MCP 原理可以看一看。\n 更多 debug 接口可以查看: https://github.com/istio/istio/blob/5b926ddd5f0411aa50fa25c0a6f54178b758cec5/pilot/pkg/proxy/envoy/v2/debug.go#L103\n Pilot Pilot 负责网格中的流量管理以及控制面和数据面之前的配置下发，在 Istio 1.5 之后合并了 Galley、Citadel、Sidecar-Inject 和 Pilot 成为 Istiod。我们这里说的是之前 Pilot 的功能，源码里面 pilot-discovery 的内容。\n功能 根据不同平台（Kubernetes、Console）获取一些资源，Kubernetes 中使用 Informer 机制获取 Node、Endpoint、Service、Pod 变化； 根据用户的配置（CR、MCP 推送、文件）触发推送流程； 启动 gRPC server 用于接受 Sidecar 的连接； 推送流程 记录变化的资源类型； 根据变化的资源类型(数组)整理本地数据； 根据变化的资源类型判断需要下发的 xDS 资源； 构建 xDS 资源， …","date":1591264800,"description":"本文主要给分享 Service Mesh 的一些技术点以及多点生活在 Service Mesh 落地过程中适配 Dubbo 的一些探索。","dir":"blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"99f4c0638c5fbd0b762ce8d373142ae0","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","publishdate":"2020-06-04T18:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","summary":"Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，为大家带来 Service Mesh 领域的知识和实践分享。 本文根据5月28日晚 Service Mesh Webinar#1 多点生活平台架构","tags":["Service Mesh","Service Mesh Webinar"],"title":"多点生活在 Service Mesh 上的实践 -- Istio + Mosn 在 Dubbo 场景下的探索之路","type":"blog","url":"/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/","wordcount":5590},{"author":"叶志远","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖如何使用 SkyWalking 来观测 Service Mesh，来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务监控的区别。\n本文根据5月14日晚，G7 微服务架构师叶志远的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 谈到 Service Mesh，人们总是想起微服务和服务治理，从 Dubbo 到 Spring Cloud (2016开始进入国内研发的视野，2017年繁荣)再到 Service Mesh (2018年开始被大家所熟悉)，正所谓长江后浪推前浪，作为后浪，Service Mesh 别无选择，而 Spring Cloud 对 Service Mesh 满怀羡慕，微服务架构的出现与繁荣，是互联网时代架构形式的巨大突破。Service Mesh 具有一定的学习成本，实际上在国内的落地案例不多，大多是云商与头部企业，随着性能与生态的完善以及各大社区推动容器化场景的落地，Service Mesh 也开始在大小公司生根发芽，弥补容器层与 Kubernetes 在服务治理方面的短缺之处。本次将以一个选型调研者的视角，来看看 Service Mesh 中的可观察性主流实践方案。\n可观察性的哲学 可观察性（Observability）不是一个新名词，它在很久之前就已经诞生了，但是它在 IT 领域却是一个新兴事物。可观察性在维基百科中原文是这样定义的：“In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. ”。云原生领域第一次出现这个词，是在云原生理念方兴未艾的2017年，在云原生的思潮之下，运用传统的描述方式已经不足以概括这个时代的监控诉求，而 Observability 就显得贴切许多。\n回想一下传统的监控方式，除去运维层面的主机监控、JVM 监控、消息队列监控之外，有多少监控是事先就想好怎么做的？很少！其实很多时候，我们做的事情就是在故障发生之后，对故障复盘的过程中，除了 bug 重现与修复，也会去定制加一些监控，以期望下次发生同样的情况时有一个实时的告警。研发人员收到告警之后得以快速地处理问题，尽可能地减少损失。所以，传统的监控模式大多都是在做亡羊补牢的事情，缺少一个主动性。\n在云原生时代的容器化体系当中就不一样了，容器和服务的生命周期是紧密联系在一起的，加上容器完美的隔离特性，再加上 Kubernetes 的容器管理层，应用服务跑在容器当中就显得更加地黑盒化，相较在传统物理主机或者虚拟机当中，排查问题的时候显得非常不便。所以在云原生时代强调的是可观察性，这样的监控永远都是兵马未动而粮草先行的，需要提前想好我们要如何观察容器内的服务以及服务之间的拓扑信息、各式指标的搜集等，这些监测能力相当重要。\n关于可观察性在云原生领域是何时开始流行起来的，没有一个很明确的时间。业界认为可观察性最早是由 Cindy Sridharan 提出的，其实一位德国柏林的工程师 Peter Bourgon 早在2017年2月就已经有文章在讨论可观察性了，Peter 算是业界最早讨论可观察性的开发者，他写的著名的博文《Metrics, Tracing, and Logging》被翻译成了多种语言。真正可观察性成为一种标准，是来自 Pivotal 公司的 Matt Stine 定义的云原生标准，可观察性位列其中，由此可观察性就成为了云原生时代一个标准主题。\nPeter Bourgon 提出的可观察性三大支柱围绕 Metrics、Tracing 和 Logging 展开，这三个维度几乎涵盖了应用程序的各种表征行为，开发人员通过收集并查看这三个维度的数据就可以做各种各样的事情，时刻掌握应用程序的运行情况，关于三大支柱的理解如下：\n Metrics：Metrics 是一种聚合态的数据形式，日常中经常会接触到的 QPS、TP99、TP95 等等都属于Metrics 的范畴，它和统计学的关系最为密切，往往需要使用统计学的原理来做一些设计； Tracing：Tracing 这个概念几乎是由 SOA 时代带来的复杂性补偿，服务化带来的长调用链，仅仅依靠日志是很难去定位问题的，因此它的表现形式比 Metrics 更复杂，好在业界涌现出来了多个协议以支撑 Tracing 维度的统一实现； Logging：Logging 是由请求或者事件触发，应用程序当中用以记录状态快照信息的一种形式，简单说就是日志，但这个日志不仅仅是打印出来这么简单，它的统一收集、存储以及解析都是一个有挑战的事情，比如结构化(Structured)与非结构化(Unstructed)的日志处理，往往需要一个高性能的解析器与缓冲器； 此外，Peter Bourgon 在博文中还提到了三大支柱结合态的一些理想输出形式，以及对存储的依赖，Metrics、Tracing、Logging 由于聚合程度的不同，对存储依赖由低到高。更多细节，感兴趣的同学可以查看文末的原文链接。\nPeter Bourgon 关于可观察性三大支柱的思考不止于此，他还在2018年的 GopherCon EU 的分享上面再次讨论了 Metrics、Tracing 和 Logging 在工业生产当中的深层次意义，这次他探讨了4个维度。\n CapEx：表示指标初始收集成本，很明显日志的成本最低，埋点即可；其次是 Metrics，最难是 Tracing 数据，在有了协议支撑的情况下，依然要定义许多数据点，以完成链路追踪必须的元数据定义收集； OpEx：表示运维成本，一般指存储成本，这个之前已经讨论过； Reaction：表示异常情况的响应灵敏度，显然聚合之后的数据可以呈现出波动情况，因此 Metrics 是对异常情况最灵敏的；Logging 次之，也可以从 Logging 清洗之中发现异常量；而 Tracing 在响应灵敏度上面似乎沾不上边，最多还是用在排障定位的场景； Investigation：标准故障定位能力，这个维度是 Tracing 的强项，可以直观看出链路当中的故障，精确定位；Logging 次之；Metrics 维度只能反馈波动，对定位故障帮助不大； 在 CNCF Landscape 当中，有一块区域专门用作展示云原生场景下的可观察性解决方案，里面又分为好几个维度，图中是截至2020年5月14日的最新版图，未来还会有更多优秀的解决方案涌现出来。CNCF 目前毕业的10个项目库当中，有3个是和可观察性有关的， …","date":1591092000,"description":"本文根据 G7 微服务架构师叶志远线上分享整理，以一个选型调研者的视角，来看看 Service Mesh 中的可观察性主流实践方案。","dir":"blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","fuzzywordcount":8800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a4bde9dc8721fabf285171be403d7f5a","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","publishdate":"2020-06-02T18:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖如何使","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Service Mesh 中的可观察性实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/","wordcount":8781},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@钱德鹏 提问：\n 官网的泛化调用 Demo 地址为https://www.sofastack.tech/projects/sofa-rpc/generic-invoke，代码如下： 这段代码里 consumerConfig 没有指定 directUrl，那么是如何获取服务地址的？自己测试时，如果不指定 directUrl，那么会报找不到服务的错误；如果指定 directUrl，可以正常调用。所以想问一下到底需不需要指定？\n ConsumerConfig consumerConfig = new ConsumerConfig() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); A：你这个跟是否跟泛化调用没关系。 RPC 调用肯定是要拿到对方的服务端地址的，这里要么走注册中心去做服务发现，要么走指定直连地址。\n 明白，我的意思是官网的 Demo 里面没指定 URL，那么他是怎么调用成功的？既然官网没有指定，为什么我不指定就调用不到？另外附加一个问题，如果说一定要指定地址，那么我指定成 SLB 地址，由 SLB 去分发，是否可行？\n A：你说官网的 Demo 是哪个？\n https://www.sofastack.tech/projects/sofa-rpc/generic-invoke\n A：这里应该是代码片段，不是完整 Demo。Example 可以参加 https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/invoke/generic/GenericClientMain.java 指定成 SLB 地址是可以的，不过是 slb 跟服务端是长连接，建立了就不断了，服务端负载不一定会均衡。\n 好的，是否可以认为如果像 Demo 里这样调用，就必须指定 directUrl？\n A：对，使用 ZK 为注册中心的例子就是： https://github.com/sofastack/sofa-rpc/blob/master/example/src/test/java/com/alipay/sofa/rpc/zookeeper/start/ZookeeperBoltClientMain.java\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@王振 提问：\n 请问，配置 Nacos，如果 Nacos 是集群部署的话，那 Seata 配置 Nacos 地址的时候是不是只需要填写 Nacos 集群地址就行了，不要三个都填的吧？\n A：Nacos 集群不是填3个地址嘛？你自己做了前端负载？\n 用 Nginx 去做了，在 Nacos 之上加入了 Nginx 做了负载均衡，那在 Seata 配置上是不是只需要配置负载均衡的地址就可以了是吗？如果不做负载的话，那填三个地址是逗号隔开吗？\n A：是的，跟直接使用 Nacos 集群写法一致，我们把这个属性透传给 Nacos。\n 是 ip:port,ip:port,ip:port 这种形式对吧？\n A：是的。\n 另外，请问 Seata 对服务器有最低要求吗？\n A：server 推荐 2C4G+ 吧，jvm 内存2G+。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Apache SkyWalking 在 Service Mesh 中的可观察性应用 Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾 陌陌的 Service Mesh 探索与实践 - 直播回顾 剖析 SOFARPC 框架 【剖析 | SOFARPC 框架】系列之SOFARPC 序列化比较 【剖析 | SOFARPC 框架】系列之SOFARPC跨语言支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 路由实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 优雅关闭剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 数据透传剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 泛化调用实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 单机故障剔除剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 线程模型剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 同步异步实现剖析 【剖析 | SOFARPC 框架】系列之连接管理与心跳剖析 【剖析 | SOFARPC 框架】系列之链路追踪剖析 【剖析 | SOFARPC 框架】系列之总体设计与扩展机制 ","date":1590735600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200529/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2009de6439107016241e7f8efc5a665c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200529/","publishdate":"2020-05-29T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200529/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 系列直播回顾、SOFARPC 剖析回顾","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200529/","wordcount":1431},{"author":"高洪涛","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖 Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh，来自陌陌和百度的 Service Mesh 生产实践。\n本文根据5月7日晚，美国 Service Mesh 服务商 Tetrate 创始工程师高洪涛的主题分享《Apache SkyWalking 在 Service Mesh 中的可观察性应用》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 本次演讲为大家分享的是 Apache SkyWalking 对 Service Mesh 可观测性方面的应用实践，共分为三个部分：\n 第一部分是 Apache SkyWalking 的相关背景； 第二部分是 Service Mesh 场景下 SkyWalking 所面临的挑战； 最后是针对 Service Mesh 场景方案的演化； SkyWalking 的历史沿革及其特点 SkyWalking 项目的建设目的是为了解决在微服务环境下，如何快速的定位系统稳定性问题。创始团队于2016年启动项目，经过一年的努力完善了最初的版本。2017年，团队启动将项目捐献给 Apache 基金会的流程。在 Apache 基金会孵化器内，经过了多轮系统升级迭代，并获得近乎翻倍的贡献者和关注度，于2019年顺利毕业。经过经年的升级与维护，SkyWalking 从最开始专注于分布式追踪系统的单一平台，发展为包含多个门类并拥有丰富的功能的全领域 APM 系统。\nSkyWalking 整体的系统架构包括有三个部分:\n 第一个是数据采集端，可以使用语言探针对系统的监控指标进行采集，同时也提供了一套完整的数据采集协议。第三方系统可以使用协议将相关的监控数据上报到分析平台。 第二部是分析平台，主要包括对监控指标数据的搜集，流式化处理，最终将数据写到存储引擎之中。存储引擎可使用Elasticsearch，MySQL数据库等多种方案。 第三部分是 UI。UI 组件有丰富的数据展示功能，包含指标展板，调用拓扑图，跟踪数据查询，指标比较和告警等功能。 在此基础上，SkyWalking 本身组件具有丰富的定制功能，方便用户去进行二次开发以支持自己特有的场景。\nSkyWalking 定义了三个维度用来绑定相关的监控指标数据。\n 服务(Service)：表示对请求提供相同行为的一系列或一组工作负载。在使用打点代理或 SDK 的时候, 你可以定义服务的名字。如果不定义的话，SkyWalking 将会使用你在平台上定义的名字, 如 Istio。 实例(Instance)：上述的一组工作负载中的每一个工作负载称为一个实例。就像 Kubernetes 中的 Pod 一样, 服务实例未必就是操作系统上的一个进程。但当你在使用打点代理的时候，一个服务实例实际就是操作系统上的一个真实进程。 端点(Endpoint)：对于特定服务所接收的请求路径，如 HTTP 的 URL 路径和 gRPC 服务的类名 + 方法签名。 预定义的维度可以方便的进行数据预汇集操作，是 SkyWalking 分析引擎重要的组成部分。虽然其相对的会有使用不够灵活的缺点，但在 APM 场景下，指标往往都是预先经过精心设计的，而性能才是关键因素。故 SkyWalking 采用这种预定义维度模式来进行数据汇集操作。\nService Mesh 场景下 SkyWalking 面对的挑战 在描述 Service Mesh 的场景下所面临的挑战之前，需要去解释可观测性所包含的含义。可观测性一般包含有三个部分:\n 第一点，日志系统。由其可以构建出系统运行的实时状态。故日志成为非常方便的观测手段。 第二点，分布式追踪。这部分数据在微服务场景下具有强大的生命力，可以提供给用户分布式系统观测指标。 第三点，指标监控。相比于日志和分布式追踪，其具有消耗小，处理简便等特点，通常作为系统监测告警的重要数据来源。 如上所示是 Istio1.5 的架构图。重点看一下他对可观测性的支持。从图上看，所有的监控指标都汇聚到中间的 Mixer 组件，然后由 Mixer 再发送给他左右的 Adapter，通过 Adapter 再将这些指标发送给外围的监控平台，如 SkyWalking 后端分析平台。在监控数据流经 Mixer 的时候，Istio 的元数据会被附加到这些指标中。另一种新的基于 Telemetry V2 观测体系是通过 Envoy 的 Proxy 直接将监控指标发送给分析平台，这种模式目前还处于快速的演进和开发中，但是它代表着未来的一种趋势。\n从架构图中我们可以看到，这里面的第一个挑战就是 Service Mesh 场景下，对于可观测性的技术体系的支持是非常多变的。\nIstio 本身就包括两种不融合的体系，第一种是基于 Mixer 的场景，第二种是 Mixerless 场景。\nMixer 是基于访问日志进行指标生成的，也就是说服务与服务之间的访问日志经过 Mixer 增加相关的原数据后再发给外围分析系统。其特点是这个模式非常的成熟、稳定，但是性能会非常的低。它的低效源于两个方面，第一点是他的数据发送通道很长，中间节点过多。可以看到数据需要到从 Proxy 发送到 Mixer 节点，再发送给外围的 Adapter 节点。另一个效能低下的原因主要是体现在它发送的是原始访问日志，其数据量是非常大的，会消耗过多的带宽，这对整体的数据搜集与分析提出了非常大的挑战。\n另一种模式是 Mixerless，它完全是基于 Metrics 指标的。通过可观测性包含的技术及其特点分析可知，它是一种消耗比较小的技术，对带宽以及分析后台都是非常友好的。但是它同时也有自己的问题，第一个问题就是他需要的技术门槛是比较高的（使用 WASM 插件来实现），并且对于 Proxy 端的性能消耗也是比较大的。同时由于是新的技术，稳定性较差，相关接口与规范并不完整。\n第二个挑战就是无 Tracing 数据。SkyWalking 最早是为了收集处理跟踪数据（Tracing）而设计的一套系统，但是我们可以从右边的图发现，对于 Service Mesh 上报的数据其实是基于调用的，也就是说它不存在一条完整的跟踪链路。这样就对后台的分析模型有比较大的挑战，如何才能同时支持好这两种模式成为后端分析系统所要处理的棘手问题。\n第三个挑战就是维度匹配的问题。我们从前一章可以看到 SkyWalking 是包括三个维度的，其中对于实例和端点，在 Service Mesh 场景下都是有比较好的支持。这里多说一句，不仅仅是对 Mesh 场景，对于大部分场景都可以很好的去匹配它们。但是对于服务的匹配是有相当大难度的，因为 SkyWalking 只有服务这一层的概念，而在 Istio 中有好几个概念可以称之为“服 …","date":1590649200,"description":"本文根据5月7日晚，美国 Service Mesh 服务商 Tetrate 创始工程师高洪涛的主题分享《Apache SkyWalking 在 Service Mesh 中的可观察性应用》整理。","dir":"blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2414682129ca15d4cfc86bffc6694aaa","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","publishdate":"2020-05-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖 Service Mesh 的","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Apache SkyWalking 在 Service Mesh 中的可观察性应用","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/","wordcount":4356},{"author":"罗广明","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。\n本文根据5月13日晚，百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 Service Mesh 在企业落地中有诸多挑战，当与传统微服务应用共同部署治理时可用性挑战更为严峻。本次分享将以 Service Mesh 与 Spring Cloud 应用互联互通共同治理为前提，着重介绍基于 Consul 的注册中心高可用方案，通过各种限流、熔断策略保证后端服务的高可用，以及通过智能路由策略（负载均衡、实例容错等）实现服务间调用的高可用。\nService Mesh 与 Spring Cloud 应用的互通、互联 微服务是时下技术热点，大量互联网公司都在做微服务架构的推广和落地。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。而在这个技术转型中，国内有一个现象，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。近年来，新兴的 Service Mesh 技术也越来越火热，受到越来越多开发者的关注，大有后来居上的趋势。\n在听到社区里很多人谈到微服务技术选型时，注意到他们讨论一个非此即彼的问题：采用 Spring Cloud 还是以 Istio 为代表的 Service Mesh 技术？然而这个答案并非非黑即白、非你即我，一部分应用采用 Spring Cloud，另一部分采用 Service Mesh（Istio）是完全可能的。今天我就和大家一起来讨论这个问题。\n首先，我们来看一下 Spring Cloud 这个传统侵入式微服务框架。它包含以下优点：\n 集大成者，Spring Cloud 包含了微服务架构的方方面面；选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架； 轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者； 开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发； 开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件； 特别感谢 Netflix，这家很早就成功实践微服务的公司，几年前把自家几乎整个微服务框架栈贡献给了社区，早期的 Spring Cloud 主要是对 Netflix 开源组件的进一步封装。不过近两年，Spring Cloud 社区开始自研了很多新的组件，也接入了其他一些互联网公司的优秀实践。\n接下来，我们简单看一下 Service Mesh 框架。它带来了两大变革：微服务治理与业务逻辑的解耦，异构系统的统一治理。此外，服务网格相对于传统微服务框架，还拥有三大技术优势：可观察性、流量控制、安全。服务网格带来了巨大变革并且拥有其强大的技术优势，被称为第二代“微服务架构”。\n然而就像之前说的软件开发没有银弹，传统微服务架构有许多痛点，而服务网格也不例外，也有它的局限性。这些局限性包括：增加了链路与运维的复杂度、需要更专业的运维技能、带来了一定的延迟以及对平台的适配。\n更多关于 Spring Cloud 与 Service Mesh 的优缺点与比较，请阅读 Istio-Handbook [Service Mesh 概述]。\n前面提到过，对于传统微服务框架 Spring Cloud 与新兴微服务框架 Service Mesh，并非是个非黑即白，非你即我，延伸到微服务与单体架构，它们也是可以共存的。\n也可以将其与混合云相类比，混合云中包含了公有云、私有云，可能还有其它的自有基础设施。目前来看，混合云是一种流行的实践方式；实际上，可能很难找到一个完全单一云模式的组织。对多数组织来说，将一个单体应用完全重构为微服务的过程中，对开发资源的调动是一个很严峻的问题；采用混合微服务策略是一个较好的方式，对开发团队来说，这种方式让微服务架构触手可及；否则的话，开发团队可能会因为时间、经验等方面的欠缺，无法接受对单体应用的重构工作。\n构建混合微服务架构的最佳实践：\n 最大化收益的部分优先重构； 非 Java 应用优先采用 Service Mesh 框架； 混合微服务出现的原因是为了更好的支持平滑迁移，最大限度的提升服务治理水平，降低运维通信成本等，并且可能会在一个较长的周期存在着。而实现这一架构的前提，就是各服务的“互联互通”。\n要想实现上述“混合微服务架构”，运行时支撑服务必不可少，它主要包括服务注册中心、服务网关和集中式配置中心三个产品。\n传统微服务和 Service Mesh 双剑合璧（双模微服务），即“基于 SDK 的传统微服务”可以和“基于 Sidecar 的 Service Mesh 微服务”实现下列目标：\n 互联互通：两个体系中的应用可以相互访问； 平滑迁移：应用可以在两个体系中迁移，对于调用该应用的其他应用，做到透明无感知； 灵活演进：在互联互通和平滑迁移实现之后，我们就可以根据实际情况进行灵活的应用改造和架构演进； 这里还包括对应用运行平台的要求，即两个体系下的应用，既可以运行在虚拟机之上，也可以运行在容器/K8s 之上。我们不希望把用户绑定在 K8s 上，因此 Service Mesh 没有采用 K8s 的 Service 机制来做服务注册与发现，这里就突出了注册中心的重要性。\n百度智能云 CNAP 团队实现了上述混合微服务架构，即实现了两个微服务体系的应用互联互通、平滑迁移、灵活演进。上述混合微服务架构图包括以下几个组件：\n API Server：前后端解耦，接口权限控制、请求转发、异常本地化处理等等； 微服务控制中心：微服务治理的主要逻辑，包括服务注册的多租户处理、治理规则（路由、限流、熔断）的创建和转换、微服务配置的管理； 监控数据存储、消息队列：主要是基于 Trace 的监控方案使用的组件； 配置中心：微服务配置中心，最主要的功能是支持配置管理，包括治理规则、用户配置等所有微服务配置的存储和下发，微服务配置中心的特色是借助 SDK 可以实现配置/规则热更新； 接下来主要看一下注册中心的服务注册和发现机制：\n Spring Cloud 应用通过 SDK、Service Mesh 应用实现 Sidecar 分别向注册中心注册，注册的请求先通过微服务控制中心进行认证处理与多租户隔离； Mesh 控制面直接对接注册中心获取服务实例、Spring Cloud 应用通过 SDK 获取服务实例； 双模异构，支持容器与虚机两种模型； 注册中心与高可用方案 前面提到过，要想实现实现混合微服务架构，注册中心很关键。谈到注册中心，目前主流的开源注 …","date":1590476400,"description":"本文根据5月13日晚，百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。","dir":"blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","fuzzywordcount":9100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2cea7fee830cbfcc69ee7732909b231c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","publishdate":"2020-05-26T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌","tags":["Service Mesh","Service Mesh Virtual Meetup"],"title":"Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾","type":"blog","url":"/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/","wordcount":9014},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n1、@张晓明 提问：\n 关于 SOFATracer 采样率的配置，只在请求经过的第一个服务配置采样率就可以吗，还是每个服务都需要配置采样率，每个服务都配置的话，要求各服务采样率必须一致吗？\n A：第一个，只在请求经过的第一个服务配置采样率就可以。\n 上报 Zipkin 的话，也只在第一个服务配置就可以吧，其他服务只需要引入 tracer-sofa-boot-starter 就行吧？\n A：上报每个服务节点都要配，不然你下游链路数据拿不到。\n 采样率支持动态更新吗，就是修改后需要重启服务吗？\n A：可以通过自定义采样，配合个配置中心就可以。\n 采样模式用 PercentageBasedSampler，配合配置中心可以吗？\n A：可以，比较麻烦，要反射去改配置类的值，配置类初始化时采样率就确定了，如果要动态改只能通过反射去改。或者通过拿到配置类对象去设置也行，思路差不多。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n2、@李振鸿 提问：\n 请问，分布式事务执行 (只插入两条数据) 执行时间 0.3 会不会比较慢？\n A：嗯，Seata 是消耗了不少性能，尤其是跟 TC 通信、TC 那边的处理。 Seata：https://github.com/seata/seata\n本周推荐阅读 云原生网络代理 MOSN 透明劫持技术解读 | 开源 不得不说的云原生隔离性 | SOFAChannel#16 直播回顾 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.12.0版，主要更新如下：\n 支持 Go 语言，并增加了 Demo； 新增三个命令行子命令：start, exec 和 stop； 新增 signal 子系统； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.12.0\n社区直播报名 随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处？如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点？服务之间主要通过 Dubbo 交互。本次分享将探索 Istio + MOSN 在 Dubbo 场景下的改造方案，结合现有业务场景和可切入点，明确需要修改的场景，制定符合自己业务场景的 Service Mesh 落地方案，介绍多点生活在 Dubbo 案例的探索及改造方案。\n将从以下几个方面，与大家交流分享：\n 传统微服务架构与 Service Mesh 架构 传统微服务架构在多点遇到的痛点； Service Mesh 架构能带来的福利； Istio 技术点介绍 在 Dubbo 场景下的改造分析 对比 MOSN 和 Envoy 对现有场景的支持； Istio+MOSN 和 Istio+Envoy 在 Dubbo 场景下如何改造； MOSN + Istio 具体实现探索 MOSN 配置文件介绍、从一个流量进来到转发到具体的远端的流程分析； Provider 配置信息如何下发到 Sidecar； 从多点现在的实际场景对现有的 Dubbo 改造方案； Demo 演示 直播主题： Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路\n分享嘉宾：陈鹏，多点生活平台架构组研发工程师，开源项目与云原生爱好者，有多年的网上商城、支付系统相关开发经验，2019年至今从事云原生和 Service Mesh 相关开发工作。\n直播时间：2020/5/28（周四）20:00-21:00\n直播间：点击“这里”，关注直播间即可\n","date":1590138000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200522/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b5778b2bc8e9e6cd92abd8bd7bfc387b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200522/","publishdate":"2020-05-22T17:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200522/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Occlum 发布、技术直播回顾\u0026预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200522/","wordcount":1432},{"author":"巴德","categories":"Kata Containers","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 本文根据 SOFAChannel#16 直播分享整理，主题：不得不说的云原生隔离性。\n大家好，我是今天的讲师巴德，来自蚂蚁金服，主要从事 Kata 容器相关的开发，也是 Kata Containers 项目的维护者之一。今天我和大家分享一下云原生场景下容器隔离性的需求以及我们如何运用 Kata Containers 来提升容器的隔离性。\n从 Kubernetes Pod 说起 在讲云原生隔离性之前，我们先来回顾一下历史。这张图是生产环境应用部署形态的变迁过程。从最左边的物理机上直接部署，到后来的虚拟化兴起，大家把应用部署在虚拟机里，再到 Docker 兴起，大家都把应用部署到容器里面，到现在 Kubernetes 成为主流，大家都把应用部署在 Pod 里面。\n我们看一下 Kubernetes 的一个基本架构，它本身是一个容器的编排系统，主要角色是管理和调度 Pod 以及相关的资源。今天我们主要关注的就是在节点上部署的 Pod，这也是 Kubernetes 资源调度的基本单位。\nKubernetes 官方对 Pod 的定义是一个应用的逻辑主机，其中包含了一个或者多个应用容器，这些容器在资源上是相对紧密的耦合在一起的。Pod 包含了这些容器共享的网络和存储以及如何运行这些容器的声明。Pod 中的内容总是放置在一起并且一同调度，并在共享的上下文中运行。\n这段定义有些抽象，其目的是为了说明 Pod 是可以用不同的隔离技术来实现的。我们先来看一下一个经典的 Pod 实现，基于 Linux namespace 和 cgroups 做抽象的 Pod 实现。\n这个示意图中，我们在一台主机上运行了两个 Pod，这两个 Pod 之间通过主机内核提供的 namespace 和 cgroups 能力来进行隔离。他们之间的所有 namespace 资源都是隔离的。然后在 pod 内部，不同容器之间的 IPC 和网络 namespace 是共享的，但是他们的 mnt/pid/user/uts namespace 又是相互隔离的。这就是一个经典的基于 Linux namespace 和 cgroups 来做隔离的 Pod 的实现。\n对于这种 Pod 的实现，我们可以关注到这两个 Pod 虽然所有的 namespace 都是隔离的，但是他们共享了同一个内核。\n共享内核引入的问题 那么，我们来看一下 Pod 共享同一个内核可能造成什么问题。\n首先我们关注到的是安全问题。也就是说 Pod 中的容器应用会不会通过共享内核的漏洞逃逸出 Pod 的资源隔离？这里我们列了两个近几年的内核 bug，一个是 CVE-2016-5915，另外一个是 CVE-2017-5123，这两个 bug 都曾经造成容器应用通过触发内核 bug 获取宿主机 root 权限并逃逸出 Pod 资源隔离限制。\n另外一个点是故障影响。这个好理解，如果一个 Pod 中的容器应用触发了一个严重的内核 bug，造成内核 panic，这时候同一台宿主机上的所有 Pod 都会被牵连。\n还有一个我们非常关注的点，是共享内核造成的内核资源竞争。同一个宿主机上的不同 Pod，实际上是不同的用户态进程的集合，这些用户态进程虽然在 namespace 上是相互隔离的，但他们还是会共享很多内核资源，比如调度器、某些内核线程或者对象。这种级别的资源共享会引入很多可以观测到的性能抖动，对在线业务的影响也很明显。\n如何避免共享内核造成的这些问题呢？大家最直接的想法就是，把 Kubernetes 装到虚拟机里不就可以更好的隔离起来了吗？如图所示，这本质上是通过增加一个 VM 间接层来解决隔离性问题。\n看起来问题解决了，不是吗？这时候我们就需要抛出计算机届大佬 David Wheeler 的一个名言，“计算机科学中的所有问题都可以通过增加一个间接层来解决，当然，除了间接层过多的问题”。\n那么增加 VM 间接层的方案有什么问题呢？第一，同一个 VM 内的 Pod 之间还是共享内核的。第二，整个集群里出现了虚拟机和 Pod 两层调度系统。\n上帝说，要有光；我们说，要有 Kata 面对这些问题，我们要怎么做呢？我们要部署 Kata 容器 ：)\nKata 容器的一个基本思路是，用虚拟机来作为 Pod 的一种隔离方式。我们把 Pod 中的多个容器资源，放到同一个虚拟机里面，利用虚拟机来实现不同 Pod 独占内核的目的。而 Pod 仍然是 Kubernetes 的基本调度单位，集群里也不会有虚拟机和 Pod 两层调度系统。\n我们简单介绍一下 Kata Containers 这个项目，这是 Openstack 基金会管理下的开放基础设施顶级项目。Kata Containers 的 slogen 是 The speed of containers, the security of VMs。其设计是基于虚拟机完美符合 Pod 抽象这个理念，为用户提供强隔离，易用的容器基础设施。\nKata Containers：https://github.com/kata-containers/kata-containers\n这是 Kata Containers 项目的发展历史概要。在 2015 年的五月，一帮国内的创业者(就是我们) 和 Intel 的同学们分别独立发布了两个叫 runV 和 Clear Containers 的虚拟化容器项目，这就是 Kata Containers 的前身。这两个项目互相有很多交流，在分别独立发展了两年半之后，在 2017 年底，合并成了 Kata Containers 项目，并把这个项目捐给 Openstack 基金会管理，这也是 Openstack 基金会的第一个 Pilot 项目，有一些探索转型的味道。在去年的四月，Kata Containers 被 Openstack 基金会认可为其第二个顶级项目，在这之前的十多年里，Openstack 基金会都只有 Openstack 一个顶级项目。\n目前 Kata Containers 的稳定版本发布到了 1.10.0，而且 2.0 也正在紧锣密鼓地开发中。\n我们再简单介绍下 Kata Containers 的架构。左边蓝色部分是 Kata Containers 对接的上游组件，也就是 Kubernetes 通过 CRI 接口访问 CRI daemon，这里是用 containerd 做展示。 Containerd 通过一个 Shim API 来访问 Kata Containers。右边的就都是 Kata 的组件了。对每一个 Pod，我们有一个名叫 containerd-shim-kata-v2 的服务进程，这个服务进程会负责基于虚拟机的 Pod 的生命周期管理。最后边的 Pod Sandbox 就是我们基于虚拟机来实现的一个 Pod 抽象。在里面我们要运行一个叫 kata-agent 的服务进程，来负责 Pod 内容器的生命周期管理。\nKata 容器特性大放送 介绍了 Kata …","date":1590123600,"description":"本文根据线上直播整理，一起来看看云原生场景下容器隔离性的需求以及我们如何运用 Kata Containers 来提升容器的隔离性。欢迎阅读","dir":"blog/sofa-channel-16-retrospect/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c57953062af87158c42de61e48d1676f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-16-retrospect/","publishdate":"2020-05-22T13:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-channel-16-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播","tags":["Kata Containers","SOFAChannel"],"title":"不得不说的云原生隔离性 | SOFAChannel#16 直播回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-16-retrospect/","wordcount":3573},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路\n 活动时间：5 月 28 日周四晚 8 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 Service Mesh Webinar Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#1 Service Mesh Webinar#1，邀请多点生活平台架构组研发工程师陈鹏，带来分享《多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路》。\n随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处。如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点。服务之间主要通过 Dubbo 交互，本次分享将探索 Istio + MOSN 在 Dubbo 场景下的改造方案。\n分享主题：\n《多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路》\n分享嘉宾：\n陈鹏，多点生活平台架构组研发工程师，开源项目与云原生爱好者，有多年的网上商城、支付系统相关开发经验，2019年至今从事云原生和 Service Mesh 相关开发工作。\n直播时间：2020年5月28日（周四）20:00-21:00\n解决思路:\n从 MCP、Pilot、xDS、MOSN 技术，对 Service Mesh 的可切入点分析。\n成果：\n结合现有业务场景和可切入点，明确需要修改的场景，制定符合自己业务场景的 Service Mesh 落地方案，介绍多点生活在 Dubbo 案例的探索及改造方案。\n大纲：\n 传统微服务架构与 Service Mesh 架构 传统微服务架构在多点遇到的痛点 Service Mesh 架构能带来的福利 Istio 技术点介绍 在 Dubbo 场景下的改造分析 对比 MOSN 和 Envoy 对现有场景的支持 Istio+MOSN 和 Istio+Envoy 在 Dubbo 场景下如何改造 MOSN + Istio 具体实现探索 MOSN 配置文件介绍、从一个流量进来到转发到具体的远端的流程分析 Provider 配置信息如何下发到 Sidecar 从多点现在的实际场景对现有的 Dubbo 改造方案 Demo 演示 ","date":1589958000,"description":"5 月 28 日周四晚 8 点，Service Mesh Webinar#1 线上直播。","dir":"activities/service-mesh-webinar-1/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d146e6a876059c0f8da819f408add6fa","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-webinar-1/","publishdate":"2020-05-20T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-webinar-1/","summary":"概要 活动主题：Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路 活动时间：5 月 28 日周四晚 8 点 活","tags":["MOSN","Service Mesh Webinar"],"title":"Service Mesh Webinar#1：多点生活在 Service Mesh 上的实践","type":"activities","url":"/sofastack.tech/activities/service-mesh-webinar-1/","wordcount":742},{"author":"无在","categories":"MOSN","content":" MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称，可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡、API Gateway、云原生 Ingress 等使用。 MOSN：https://github.com/mosn/mosn\n 在由 Istio 定义的 Service Mesh 体系中，服务治理相关逻辑由独立的 Sidecar 进程处理，如服务发现、故障注入、限流熔断等等。这些处理逻辑是 Service Mesh 着重要解决的问题。通常在谈论到 Service Mesh 时，会优先关注在这些点上，但是在落地过程中，有一个问题同等重要但往往容易被忽视。这个问题概括起来，就是流量是如何被导入到 Sidecar 的监听端口的。\n在数据平面的 Sidecar 中拦截进出应用容器的流量，这一直以来就是 Istio Service Mesh 中一切功能的基础，如何实现透明高效的拦截也是 Service Mesh 设计中的一大难点，本文为大家介绍云原生网络代理 MOSN 是如何做到这一点的。\n流量接管 如果服务注册/发布过程能够允许适当的修改，这个问题会得到极大的简化，比如 Sidecar 将服务发布方的监听地址修改为 127.0.0.1:20882，订阅方 Sidecar 监听本机 20882 端口，当订阅方访问 127.0.0.1:20882 时，流量就自然到达了本端 Sidecar。在这种情况下，无需在网络层面使用重定向技术就可以达到目的。\n服务发布订阅修改逻辑框图\n流量转发流程图\n如上图中，在发布服务时，Sidecar 将服务端原本的地址转换为 Sidecar 自身的端口；服务订阅时，订阅方获取到的端口则是本地 Sidecar 监听的端口。这一方案的优势很明显，逻辑都收敛在了 Sidecar 中，除了需要对 Sidecar 服务注册/发布流程进行改造外，不需要其他组件的参与，但是缺点也很明显，如果业务模型不存在注册中心，或者是服务发布/订阅 SDK 不能进行改造，这个方案就行不通了，而在 Mesh 落地场景中，这个条件恰恰较难满足。\n目前大多数业务的逻辑架构都不符合 Istio 定义的云原生体系，为了享受到 Service Mesh 在服务治理方面的优势，需要选择合适的流量劫持方案。一般而言，流量劫持工作在 L4 层，在进行劫持技术选型时需要考虑三个方面的问题：\n 第一是环境适配，包括容器、虚拟机、物理机、内核、系统发行版等方面的考虑，确保劫持方案在运行环境中能够正常工作； 第二是控制灵活简单，包括如何维护劫持规则，劫持规则如何下发等； 第三是性能，确保在业务运行期间，劫持本身不会带来过大的开销； 下面将从这三个层面分析 MOSN 在落地过程中的一些思考。\n环境适配 在环境适配性上，最容易想到的是 iptables，作为一项古典网络技术，iptables 使用简单，功能灵活，几乎所有现代生产级内核版本与 OS 发行版都默认具备使用条件，Istio 社区也使用 iptables 做流量透明劫持。\niptables 流量劫持原理图\n尽管环境适应性强，但是基于 iptables 实现透明劫持存在以下问题：\n DNAT 模式下，需要借助于 conntrack 模块实现连接跟踪，在连接数较多的情况下，会造成较大的消耗，同时可能会造成 track 表满的情况。为了避免这个问题，可以使用 TProxy 取代 DNAT，但受限于内核版本，TProxy 应用于 outbound 存在一定缺陷。 iptables 属于常用模块，全局生效，不能显式的禁止相关联的修改，可管控性比较差。 iptables 重定向流量本质上是通过 loopback 交换数据，outbond 流量将两次穿越协议栈，在大并发场景下会损失转发性能。 针对 oubound 流量，还可以使用 hook connect 来实现，如图所示：\nhook connect 逻辑框图\n无论采用哪种透明劫持方案，均需要解决获取真实目的 IP/端口的问题，使用 iptables 方案通过 getsockopt 方式获取，TProxy 可以直接读取目的地址，通过修改调用接口，hook connect 方案读取方式类似于 TProxy。\n由于 MOSN 落地的场景十分复杂，有容器与 VM 甚至物理机环境，有基于 K8s 的云原生应用，有基于注册中心的微服务，也存在单体应用，有些场景对性能要求非常高，有些则是够用即可，针对不同的场景，我们选择不同的劫持方案进行适配。如果应用程序通过注册中心发布/订阅服务时，可以结合注册中心劫持流量；在需要用到透明劫持的场景，如果性能压力不大，使用 iptables DNAT 即可，大并发压力下使用 TProxy 与 sockmap 改善性能。\n配置管理 通常基于申明式体系构建的服务在部署时能够得到全局信息，而非申明式体系往往需要在运行期间进行动态的配置修改，由于缺乏全局信息，在运行期间很难获取到准确的服务间调用信息。在生成透明劫持规则时，我们需要明确哪些流量要被重定向到 Sidecar，否则一旦出错，而 Sidecar 又无法处理这部分流量时，将会使得 Sidecar 变成流量黑洞，比如，某一个容器内的 TCP 流量全部被重定向至 Sidecar，而该容器中存在一个使用私有协议承载应用数据的监控 Agent，而 Sidecar 不能识别该协议导致无法争取转发，只能选择丢弃。\n通常情况下，为了确保 Sidecar 能够正确的转发流量，需要满足两个条件，首先是要能够正确识别协议，其次是需要配置转发规则，明确下一跳。对于不满足这两个条件的流量，不应将其重定向至 Sidecar。对于现有的非云原生应用，同时满足这两个条件的代价非常高，比如，某个虚拟机上运行了一个业务，同时还运行了收集 Metrics 的 Agent、日志采集工具、健康检查工具等等。而基于 L4 规则很难精确的将业务流量重定向至 Sidecar，如果多个业务混部，可能导致无法在 L4 层进行业务流量的区分。总结起来，为了精确的把流量引至 Sidecar，需要获得全局的调用关系，这一目标原本应该由 Service Mesh 来完成，而在流量劫持的场景下，却成为了 Service Mesh 的前提。\n为了使用 Service Mesh 而引入大量的部署运维开销是得不偿失的。在落地的过程中，MOSN 引入了多项手段来降低流量劫持的配置难度。我们将需要精确配置重定向规则的工作模式定义为精确匹配，与之相对应的是模糊匹配，即不要求精确区分出需要劫持的流量。降低配置难度的关键在于取消对于精确规则的依赖，在配置模糊规则的前提下，既做到对于关心的业务流量的治理，同时也不影响非业务流量的正常流程。\n我们采用 L4 规则与 L7 规则融合的方式下发模糊的匹配规则，此规则下除了包含关心的业务流量外，还可能包含预期之外的非业务流量。对于业务流量，Sidecar 根据相应的服务治 …","date":1589871600,"description":"如何实现透明高效的拦截也是 Service Mesh 设计中的一大难点，本文为大家介绍云原生网络代理 MOSN 是如何做到这一点的。","dir":"blog/mosn-transparent-hijacking/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c2505ec6bd3034e6cf3222dca8e1b83e","permalink":"https://sofastack.github.io/sofastack.tech/blog/mosn-transparent-hijacking/","publishdate":"2020-05-19T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/mosn-transparent-hijacking/","summary":"MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简","tags":["MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 透明劫持技术解读 | 开源","type":"blog","url":"/sofastack.tech/blog/mosn-transparent-hijacking/","wordcount":3410},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n **SOFAStack 官网: **https://www.sofastack.tech **SOFAStack: **https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n**1、@黄泽宏 **提问：\n SOFAJRaft 中 rheakv 不实现 region 新增删除，是因为分片迁移比较复杂么？\n A：不知道您说的新增删除是指什么？ 分裂与合并？ 分裂是有的，合并没有，不过分裂还没有经过严格的验证，也暂时不建议使用，分裂和合并确实比较复杂，复杂的不是分片迁移，分片迁移只要 raft 协议实现的没问题就是很自然的事情了。\n 对，sharding 合并分裂迁移，代码大概在哪个位置呢，想先看下实现。\n A：com.alipay.sofa.jraft.rhea.StoreEngine#applySplit 从这里看吧。 SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@廖景楷 提问：\n 请教 Seata 在做超时处理时怎么协调多个节点不会同时对某个事务做多次处理？还是说要求业务容许多次commit，rollback，Seata 就不协调了？ 我在测试 seata-server 多节点 HA 部署，用 MySQL 存储，看代码貌似所有节点都是无差别无状态的，在多个实例的 DefaultCoordiantor 里头有定时器去扫描超时的事务进行重试或者回滚，打开 general log 也发现有多个客户端 IP 在用同样的语句在扫描 global_table 表进行超时等处理。想确认一下多节点间是否有协调机制？ 我在 K8s下面部署3节点的 seata-server statefulset，镜像 docker.io/seataio/seata-server:latest 使用 Nacos 作为 registry。\n A：目前没有，多次不会导致数据问题，不过确实浪费资源，可以考虑引入分布式 job。\n 也就是说比如同一个超时的未 commit Global Session 被多个节点同时扫描到，可能会调用业务做多次 commit，然后由业务自己去重？\n A：是的，不过不是业务处理，框架会处理。\n3、@Cheng cheng 提问：\n 最近正在做 Seata 跟我们产品集成到研究，问一个小白问题，我们需要把 Seata 部署到 K8s 里，那么如果 Seata server 的一个 pod 突然挂了，那在途的调用会突然中断，这样依然可以完美控制事务达成数据一致性吗？\n A：如果 Server 是公用的一个 DB，理论上没问题的。\n 没有理解你说的公用 DB\u0026amp;hellip;. Seata Server 在 K8s 上用独立的几个 pod 部署，那相应的我们会给它单独创建数据库。\n A：Seata 高可用要求就是需要 server 的集群共用同一个 Seata 库，不然无法数据共享，也就是无法知晓当前运作的事务信息。首先你要保证 Server 集群用的同一个注册中心集群，并且共用同一个 Seata 库，这样才能保障数据共享、高可用。\nSeata：https://github.com/seata/seata\n本周推荐阅读 Mecha：将 Mesh 进行到底 陌陌的 Service Mesh 探索与实践 | 线上直播回顾 《Service Mesh Virtual Meetup#1》：视频回顾 *SOFA 项目进展* 本周发布详情如下：\n1、发布 SOFABoot v3.4.0 版本，主要变更如下：\n 支持基于 gRPC 的 triple 协议； 修复 bolt callback 方式的兼容问题； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.4.0\n2、发布 SOFAHessian v4.0.4 版本，主要变更如下：\n 修复 JDK 判断逻辑有锁问题； 修复 _staticTypeMap 为 ConcurrentMap，和 v3.x 对齐； 详细发布报告： https://github.com/sofastack/sofa-hessian/releases/tag/v4.0.4\n社区直播报名 在云原生时代，容器和 Kubernetes 在日常工作和实际生产中越来越普遍，随之而来的隔离性问题在不断被提起同时也受到了越来越多的关注。\nSOFAChannel#16 线上直播带来《不得不说的云原生隔离性》分享，将邀请 Kata Containers 维护者彭涛（花名：巴德）带我们走近云原生基础设施 \u0026amp;ndash; Kata Containers，详细分享它是如何在云原生框架下解决容器隔离性问题的。\n将从以下几个方面，与大家交流分享：\n 从 Kubernetes Pod 说起，经典容器场景下的 Pod 分享； 共享内核存在的问题以及解决办法； 上帝说，要有光；我们说，要有 Kata； The speed of containers, the security of VMs； Kata Containers 特性大放送； What? 你刚说过增加一个 VM 间接层的问题？ 活动详情：\n 直播主题：SOFAChannel#16：不得不说的云原生隔离性 直播时间：2020/5/21（周四）19:00-20:00 报名方式：点击“这里”，即可报名 ","date":1589533200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200515/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f02bec7b5443778e602b655210ee33fb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200515/","publishdate":"2020-05-15T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200515/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot\u0026SOFAHessian 发布、5/21 社区直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200515/","wordcount":1781},{"author":"敖小剑","categories":"Service Mesh","content":" 内容摘要：Service Mesh 落地实践三年，效果一直并不理想，到了该反思的时候了。Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化版本，预计也将是云原生化和 Mesh 化的必然趋势，让我们将 Mesh 进行到底。\nMecha 介绍 什么是 Macha？ Mecha 一词，相信爱好动漫的同学应该都不陌生。是的，就是大家熟悉的那个 Mecha（机甲）：\nMecha 这个词之所以出现在这里，主要是因为 Bilgin Ibryam 的这个博客文章 “Multi-Runtime Microservices Architecture”，提出了微服务架构的一个新的设想：Multiple Runtime。\n 备注：这篇博客文章强烈推荐阅读，我甚至建议在阅读本文之前先阅读这篇文章，因为我今天的内容，可以视为对这个文章的深度解读和思考。为了方便，这里提供一份中文翻译版本 多运行时微服务架构。\n 在这篇博客中，Bilgin Ibryam 首先分析并总结了分布式应用的四大需求:\n 生命周期（Lifecycle） 网络（Networking） 状态（State） 捆绑（Binding） 由于每种需求存在的问题和局限性，导致传统解决方案如企业服务总线（ESB）及其变体（例如面向消息的中间件，更轻量级的集成框架等）不再适用。随着微服务架构的发展，以及容器和 Kubernetes 的普及和广泛使用，云原生思想开始影响这些需求的实现方式。未来的架构趋势是通过将所有传统的中间件功能移至其他运行时来全面发展，最后的目标是在服务中只需编写业务逻辑。\n 备注：详情请见原文，为了节约篇幅，这里只做简单概述，不完全引用原文内容。\n 下图是传统中间件平台和云原生平台的对比，传统中间件以各种SDK的方式提供能力，而云原生平台则通过各种外围Runtime（典型如大家熟悉的Servicemesh/Istio）：\n因此作者引入了 Multiple Runtime 的概念：\n作者提出：很可能在将来，我们最终将使用多个运行时来实现分布式系统。多个运行时，不是因为有多个微服务，而是因为每个微服务都将由多个运行时组成，最有可能是两个运行时-自定义业务逻辑运行时和分布式原语运行时。\n对多运行时微服务架构和 Mecha 的说明：\n 您还记得电影《阿凡达》和科学家们制作的用于去野外探索潘多拉的 Amplified Mobility Platform (AMP)“机车服”吗？这个多运行时架构类似于这些 Mecha-套装，为人形驾驶员赋予超能力。在电影中，您要穿上套装才能获得力量并获得破坏性武器。在这个软件架构中，您将拥有构成应用核心的业务逻辑（称为微逻辑/micrologic）和提供强大的开箱即用的分布式原语的 Sidecar Mecha 组件。Micrologic 与 Mecha 功能相结合，形成多运行时微服务，该服务将进程外功能用于其分布式系统需求。最棒的是，Avatar 2 即将面世，以帮助推广这种架构。我们最终可以在所有软件会议上用令人赞叹的机甲图片代替老式的边车摩托车；-)。接下来，让我们看看该软件架构的详细信息。 这是一个类似于客户端-服务器体系结构的双组件模型，其中每个组件都是独立的运行时。它与纯客户端-服务器架构的不同之处在于，这两个组件都位于同一主机上，彼此之间有可靠的网络连接。这两个组件的重要性相当，它们可以在任一方向上发起操作并充当客户端或服务器。其中的一个组件称为 Micrologic，拥有非常少的业务逻辑，把几乎所有分布式系统问题都剥离出去了。另一个伴随的组件是 Mecha，提供了我们在本文中一直讨论的所有分布式系统功能（生命周期除外，它是平台功能）。\n 作者在这里正式提出了 Mecha 的理念：\n思路大体是：Smart Runtime， Dumb Pipes。\n我对 Mecha 的理解是：业务逻辑在编码开始阶段应该是“裸奔”的，专注于业务逻辑的实现，而尽量不涉及到底层实现逻辑；而在运行时，则应该装备“机甲”，全副武装，大杀四方。熟悉的味道是吧？标准而地道的云原生思想。\nMecha 的本质 作者在原文中探讨了 Mecha 运行时的特性：\n Mecha 是通用的，高度可配置的，可重用的组件，提供分布式原语作为现成的能力。 Mecha 可以与单个 Micrologic 组件一起部署(Sidecar 模式)，也可以部署为多个共享(注：我称之为 Node 模式)。 Mecha 不对 Micrologic 运行时做任何假设，它与使用开放协议和格式（例如 HTTP/gRPC、JSON、Protobuf、CloudEvents）的多语言微服务甚至单体一起使用。 Mecha 以简单的文本格式（例如 YAML、JSON）声明式地配置，指示要启用的功能以及如何将其绑定到Micrologic 端点。 与其依靠多个代理来实现不同的目的（例如网络代理、缓存代理、绑定代理），不如使用一个 Mecha 提供所有这些能力。 下面是我对上述特性的个人理解：\n Mecha 提供的是能力，以分布式原语体现的各种能力，而不局限于单纯的网络代理。 Mecha 的部署模型，不局限于 Sidecar 模式，Node 模式在某些场景下（如 Edge/IoT，Serverless FaaS）可能会是更好的方式。至少，Mecha下有机会按需选择，而不是绑死在 Sidecar 模式上。 Mecha 和 Micrologic 之间的交互是开放而有 API 标准的，Mecha 和 Micrologic 之间的“协议”体现在 API 上，而不是 TCP 通讯协议。这提供了一个契机：一个统一 Micrologic 和 Mecha 之间通讯方式的契机。 Mecha 可以以声明式的方式进行配置和控制，这非常符合云原生的理念，同样也使得 API 更关注于能力本身，而不是能力如何配置。 应用需要的能力如此之多（参见上面的图：分布式应用的四大需求），如果每个能力都对应一个代理（不管是 Node 还是 Sidecar），数量会非常夸张，带来的运维压力会很可怕。因此，如 Mecha 这个名字暗示的，运行时应该是整套的形式提供能力，而不是分散。 如果用一句话来总结，那么我认为 Mecha 的本质应该是：\n“面向应用的分布式能力抽象层”\n如 Service Mesh 的本质是服务间通讯的抽象层一样，Mecha 的本质是应用需要的各种分布式能力和原语，包括但不限于服务间通讯。\n从这个角度上说，Mecha 覆盖的范围是 Service Mesh 的超集：毕竟 Service Mesh 只覆盖到应用的部分需求（服务间通讯，还只限于同步/一对一/request-response 模式），还有更多的分布式能力和原语有待覆盖。\n换一句话说，Mecha 的目标应该是：“将 Mesh 进行到底！”\nMecha 的优势和未来 作者指出：Mecha 的好处是业务逻辑和越来越多的分布式系统问题之间的松耦合。\n下图是业务逻辑和分布式系统问题在不同架构中的耦合：\n其实思路和 Service Mesh 是一脉相承的，只是覆盖的分布式能力更广泛一些。\n有一个问题：Mecha 会不会成为微 …","date":1589364000,"description":"Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化版本，预计也将是云原生化和 Mesh 化的必然趋势，让我们将 Mesh 进行到底。","dir":"blog/mecha-carry-mesh-to-the-end/","fuzzywordcount":7500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2ef4b817d0dc0018551a25d24b174ee0","permalink":"https://sofastack.github.io/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","publishdate":"2020-05-13T18:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","summary":"内容摘要：Service Mesh 落地实践三年，效果一直并不理想，到了该反思的时候了。Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化","tags":["Service Mesh"],"title":"Mecha：将 Mesh 进行到底","type":"blog","url":"/sofastack.tech/blog/mecha-carry-mesh-to-the-end/","wordcount":7479},{"author":"高飞航","categories":"Service Mesh","content":" Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。\n本文根据5月6日晚，陌陌中间件架构师高飞航的主题分享《陌陌的 Service Mesh 探索与实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 本次演讲为大家分享的是陌陌目前正在进行的 Service Mesh 实践的相关内容。共分为三个部分：\n 第一部分是原有微服务架构的相关背景； 第二部分是原有架构遇到的问题以及决定采用 Service Mesh 方案的思考过程； 最后的部分对Service Mesh落地实践的方案进行介绍； 陌陌微服务体系演进历程 单体应用到微服务 各个应用的发展过程，都会经历从单体应用、到应用拆分再到微服务架构这样一个过程。陌陌的这个演进过程，有一点比较特别的是，在应用拆分时加入了由 PHP 开发、与客户端 App 进行对接的 API 层，并采用 Java 开发底层具有复杂运算的业务逻辑，这样能够兼得 PHP 的开发效率与 Java 高性能的优势。\n但这个选择的影响也是十分深远的，由于 PHP 在业务中的比重很高，我们在后续进行微服务改造和服务治理时，需要不断地去应对多语言架构带来的挑战。\n微服务体系演进 陌陌的微服务架构改造从 2013 年就开始了，在当时还没有较为完善的服务框架产品的情况下，我们自研了服务框架产品 MOA，支撑了陌陌 IM、附近动态、直播、短视频等核心业务的高速发展历程。\n在多年的迭代发展中，我们逐步完善了服务框架产品功能，同时也扩充了其他基础架构产品，最终形成了一个完善的微服务体系。其他基础架构产品也都是采用了自研的方案，因此整体是一个非常定制化的架构。这一点也成为后续 Service Mesh 落地选型时重点要考量的因素。\n微服务体系整体架构 下面对微服务体系的整体架构进行介绍。我们采用了一个 Redis 作为底层存储的注册中心。服务实例的存活检测主要依赖一个中心化的检测应用 MOA Watcher，能够将无法连通的实例从注册中心的在线列表中移除、摘除实例的业务流量。\n在多语言支持方面，我们除了支持最核心的 Java 与 PHP 应用之外，后续还支持了 Python、C++、Go、NodeJS 等非常多的语言接入微服务体系。由于陌陌的中间件团队是以 Java 工程师为主导的，服务框架组件的核心产品也是一个 Java 的 SDK。在没有足够的资源投入到其他语言 SDK 开发的情况下，我们采用了很多能够简化多语言开发工作的方案。\n例如跨语言调用和 Java 应用内部调用会采用不同的协议，Java 内部是较为传统的自定义二进制传输协议与 Hessian 序列化，跨语言则采用了 Redis 传输协议与 JSON 序列化。Redis 协议分别利用 GET 命令的 key 和 value 的位置传递 Request 和 Response，这样每种语言都可以基于成熟的 Redis 客户端开发 SDK，避免重复编写复杂的网络通信逻辑。此外还增加了一个地址发现服务 Lookup，使其他语言能够像调用普通服务的方式，轮询获取目标服务地址。跨语言场景的这些方案虽然简化了开发工作，但却不是最优方案。这也为整体架构的长期发展埋下了隐患。\n微服务体系的其他产品还包括统一的配置中心、监控平台、日志采集平台、分布式跟踪系统等，这些都是为微服务体系保驾护航的重要基础架构能力。\n流量代理机制 在多语言支持的场景中，我们很早就采用了两个和 Service Mesh 非常相近的方案。一个是为了支持多语言发布服务的入流量代理方案，使用 Java 开发的 Proxy 复用了 Java SDK 注册发现与监控等诸多服务治理能力，使得其他语言仅简单处理本地请求后就能实现发布服务。这些 Java Proxy 与多语言的业务进程是 1:1 部署的，但当时的方案是和业务进程放在一个容器里，升级时需要和业务进程一起重新发布。\n另外一个方案是为了解决 PHP 并行调用下游服务而实现的出流量代理，但这个方案中代理层的进程是运行在独立的服务器上，没有部署在与调用端相同的服务器。\n我们将流量代理机制应用于多语言服务治理的经历，在某种程度上突显了 Service Mesh 的价值，我们可能想到类似的方案去解决问题，但都没有像 Service Mesh 一样系统地给出一种最佳方案。不过这些相近方案的经验是有助于我们后续去推进 Service Mesh 落地的。\n微服务体系规模 随着业务的发展，整个微服务体系也达到了一个很具有挑战的量级。特别是在服务数量大幅增长后，Java 应用的服务治理问题也逐步暴露出来，其中最难以解决的是 SDK 升级的问题，这一点也是进一步推动我们转向 Service Mesh 架构的原因。\n借助 Service Mesh 解决现有架构痛点 架构痛点分析  前面我们提到的各种问题，其实都可以归结为微服务体系中服务治理能力滞后的问题。对于非 Java 的应用，由于没有足够的开发资源，会导致服务框架的 SDK 迭代进度非常缓慢。对于 Java 应用，虽然 SDK 具备最完善的功能，但使全量应用完成升级需要耗费大量人力和时间。根据以往的经验来看，一次推广至少需要一个季度的时间，并且为业务团队带来很多不必要的负担。\n两种场景最终的危害是一致的，都会导致架构能力上无法实现统一，先进的功能无法覆盖到全部应用，使应用稳定性受到损失，甚至引发故障。我们在多语言方案中依赖的中心化的 Lookup 服务，曾经就因为一次服务异常导致整个 API 层不可用，原因就是 PHP 的 SDK 采用了一种有缺陷的机制没有升级。在我们设计新方案时，也会因为架构能力无法统一而无法采用最佳的方案。例如我们在设计多机房架构时，由于流量调度机制无法快速覆盖到全部应用，因此只能采用从应用入口整体调度流量的一种粗粒度的方案。\n引入 Service Mesh Service Mesh 将基础架构逻辑与业务逻辑解耦、并支持独立升级的方式，能够很好地解决前面描述的架构痛点。但引入 Service Mesh 是一项非常重大的架构变更，并且需要多方面的成本投入。因此在实际落地实施前，我们必须思考以下几个问题，并在不同阶段完成对应的工作。\n 第一个是方案是否足够成熟。这里的方案不局限于 Service Mesh 本身，也依赖公司内其他基础设施的演进积累。例如我们在观察阶段实现了应用容化的推广覆盖、日志 Agent 方案的经验积累等。 第二个是遇到的问题是否有其他替代方案。例如我们之前急需在多语言场景覆盖的一个能力是流量调度机制，尝试过一个只提供地址路由机制，不代理流量的 Agent 方案。 …","date":1589266800,"description":"本文根据5月6日晚，陌陌中间件架构师高飞航的主题分享《陌陌的 Service Mesh 探索与实践》整理。","dir":"blog/momo-service-mesh-exploration-and-practice/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9c4d2df383550d5412e3de24312862ed","permalink":"https://sofastack.github.io/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","publishdate":"2020-05-12T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","summary":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌","tags":["Service Mesh"],"title":"陌陌的 Service Mesh 探索与实践 - 直播回顾","type":"blog","url":"/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/","wordcount":6499},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n**SOFAStack 官网: **https://www.sofastack.tech\n**SOFAStack: **https://github.com/sofastack\n社区大事件 MOSN 社区新认证一位 Committer\n孙福泽（@peacocktrain）认证成为 MOSN Committer：\n主要贡献： 贡献 3 个 feature PR\n 使 MOSN 支持 Istio 1.4； 协议支持 HTTP2 双向流式； 添加管道缓冲区； MOSN：https://github.com/mosn/mosn\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n**1、@chromosome **提问：\n 这个视频中提到因为 log server 中存储得到 commitedId 和 applyId 不是任意时刻都同步的，这样的话，如果说状态机的 apply 速度较慢，很可能 client 的 read request 并不能读取到状态机最新 committed 的操作的结果。 https://tech.antfin.com/community/live/821/data/902\n A：commitedIndex 和 applyIndex 的不完全同步，并不影响 read request 的结果，所以上面的后半句理解还是有点问题，可以看一下 SOFAJRaft 线性一致读的原理介绍，参考这个链接线性一致读章节 https://www.sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/\n 所以 counter 例子中的 readindex 写法就是为了读线性一致性吗？例如 this.counterServer.getNode().readindex\n A：是的。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、**@王勇 **提问：\n 在 AT 模式下，事务的回滚如何补偿三方的缓存操作呢？有没有额外的接口，还是只能是变成 TC 模式，或是自己写 aop？\n A：TCC 嵌套 AT，TCC 二阶段行为做补充。\n TCC 内应该说是不存在 AT 吧。\n A：AT 保证数据库的一致性，TCC 做来二阶段时的三方处理，比如发出 MQ 消息、缓存之类的。\n 就是 AT 和 TCC 在同一全局事务中一起使用是吧。这个 TCC 一阶段可以是空的，二阶段回滚时清理缓存嘛？\n A：嗯。\n OK，我明白了。就是让 TCC 嵌套 AT，通常情况下 TCC 为空，需要补偿的时候向 TCC 里写入东西。\n A：可以这么说，如果 TCC 触发二阶段是回滚，你就把缓存删掉，如果是提交就啥也不干，大概是这么个意思。\n TCC 模式下 AT 是默认的吗？对于大事务，Saga 模式，您用过吗？\n A：一、首先需要创建状态机引擎的 bean。 1.2.0里，状态机引擎的 bean 需要自己创建的。 1.3.0里，spring-boot-starter-seata 里会提供自动配置类。（可以先参考我修改过的代码吧。https://github.com/wangliang1986/seata） 二、需要创建 Saga 模式所需的三张表。github 上可以找到建表 SQL。 三、使用 Seata 的在线状态机设计器来定义流程。地址：http://seata.io/saga_designer/index.html 四、将设计器生成的 json 文件放到自己项目的 resources 中，由状态机引擎去加载它。状态机配置类中有一个配置项可以配置 json 文件路径。 五、使用状态机引擎启动 Saga 事务即可。（要注意的是 1.2.0 版本中，Saga 无法与 AT 一起启用。1.3.0 将修复此问题。） Seata：https://github.com/seata/seata\n本周推荐阅读 （含直播报名）Kata Containers 创始人：安全容器导论 蚂蚁金服 SOFAJRaft 优先级选举剖析 | 特性解析 Service Mesh 和 API Gateway 关系深度探讨 SOFA 项目进展 本周发布详情如下：\n1、发布SOFARPC v5.7.0,主要变更如下：\n 支持基于 grpc 的 triple 协议； 重构项目模块结构； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.7.0\n2、发布 SOFA MOSN v0.12.0，主要变更如下：\n 支持 SkyWalking； 支持流式 HTTP2； 熔断功能、负载均衡逻辑优化，负载均衡新增 ActiveRequest 和 WRR 算法； 优化 HTTP 连接建立性能； 底层实现优化； Bug Fix； 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/v0.12.0\n社区直播报名 本期为第一期 Service Mesh Virtual Meetup 线上系列直播第一期，邀请了四位来自不同公司的嘉宾，从四个角度对 Service Mesh 的应用实践展开分享。\n本次线直播分享涵盖 Service Mesh 的可观察性和生产实践，为大家介绍 Service Mesh 中的可观察性与传统微服务中可观察性的区别，如何使用 SkyWalking 来观测 Service Mesh，还有来自百度和陌陌的 Service Mesh 生产实践。\n本系列采用线上直播的形式，从 5 月 6 日开始到 5 月 14 日，每周三、周四晚上 19:00-20:00 我们相约进行一个主题分享。\n 时间 分享主题 分享嘉宾 嘉宾介绍 5\u0026amp;frasl;6 陌陌的 Service Mesh 实践 高飞航 陌陌中间件架构师 5\u0026amp;frasl;7 Apache SkyWalking 在 Service Mesh 中的可观察性应用 高洪涛 Tetrate 创始工程师 5\u0026amp;frasl;13 Servicre Mesh 高可用在企业级生产中的实践 罗广明 百度高级研发工程师 5\u0026amp;frasl;14 Servicre Mesh 中的可观察性实践 叶志远 G7 微服务架构师 观看直播方式：点击“这里”，关注直播 …","date":1588928400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200508/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c743041c871c1b4fdd685334ab29add6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200508/","publishdate":"2020-05-08T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200508/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN\u0026amp;SOFARPC 发布、社区活动报名","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200508/","wordcount":1872},{"author":"王旭","categories":"Kata Container","content":" 从2015年5月初开始创业开发 HyperContainer (runV) 到现在，也快五年了，在这个时候还来写一篇什么是安全容器，显得略有尴尬。不过，也正是经过这五年，越来越多到人开始感到，我需要它却说不清它，这个时候来给大家重新解释 “\u0026amp;gt; 安全容器” 也正是时候。\n缘起：安全容器的命名 Phil Karlton 有一句名言—— _计算机科学界只有两个真正的难题——缓存失效和命名。_ 就容器圈而言，我相信命名绝对配得上这句话，这毫无疑问是一件让老开发者沉默，让新人落泪的事情。\n仅就系统软件而言，我们当今比较通行地称为 Linux 容器（LinuxContainer）的这个概念，曾经用过的名字大概还有——jail, zone, virtualserver, sandbox\u0026amp;hellip; 而同样，在早期的虚拟化技术栈里，也曾经把一个虚拟机环境叫做容器。毕竟这个词本身就指代着那些用来包容、封装和隔离的器物，实在是太过常见。以至于，以严谨著称的 Wikipedia 里，这类技术的词条叫做“系统级虚拟化”，从而回避了“什么是容器”这个问题。\n当2013年 Docker 问世之后，容器这个概念伴随着“不可变基础设施”、“云原生”这一系列概念，在随后的几年间，以摧枯拉朽之势颠覆了基于“软件包+配置”的细粒度组合的应用部署困境，用简单地声明式策略+不可变容器就清爽地描述了软件栈。应用怎么部署似乎离题了，我们这里想要强调的是——\n云原生语境下的容器，实质是“应用容器”——以标准格式封装的，运行于标准操作系统环境（常常是 Linux ABI）上的应用打包——或运行这一应用打包的程序/技术。\n这个定义是我在这里写下的，但是它并不是我的个人意志，这是基于 OCI (Open ContainerInitiative) 规范这一共识的，这个规范规定了容器之中的应用将被放置在什么环境中，如何运行，比如启动容器根文件系统上的哪个可执行文件，用什么用户，需要什么样的 CPU、内存资源，有什么外置存储，有什么样的共享需求等等。\n有了这一共识做基础，我们来说安全容器，这又是一段命名血泪史。当年，我的联合创始人赵鹏是用“虚拟化容器”命名的我们的技术的，为了搏人眼球，用了“Secure as VM, Fast asContainer”的大字标语，自此，被容器安全性问题戳中心坎的人们立刻用“Secure Container”来称呼这类东西，一发而不可收。而我们的内心中，这项技术提供了一层额外的隔离，隔离可能意味着安全性中的一环，也意味着某些运维效率、某些优化可能或者其他的功能。实际上，给安全容器这样的定义更合理——\n一种运行时技术，为容器应用提供一个完整的操作系统执行环境（常常是 LinuxABI），但将应用的执行与宿主机操作系统隔离开，避免应用直接访问主机资源，从而可以在容器主机之间或容器之间提供额外的保护。\n间接层：安全容器的精髓 安全问题的唯一正解在于允许那些（导致安全问题的）Bug 发生，但通过额外的隔离层来阻挡住它们。 —— LinuxCon NA 2015, Linus Torvalds 为了安全，为什么要引入间接层？因为以 Linux 之类的目前主流宿主机操作系统的规模，是无法从理论上验证程序是没有 Bug 的，而一旦合适的 Bug 被合适地利用，安全性风险就变成了安全性问题了，框架和修补并不能确保安全，所以，进行额外的隔离、缩减攻击面，就成了缓解安全问题的法宝——我们不能确保没有漏洞，但我们通过组合来减少漏洞被彻底攻破的风险。\nKata: 云原生化的虚拟化 2017年12月，我们在 KubeCon上对外发布了 Kata Containers 安全容器项目，这个项目的两个前身——我们发起的的 runV 和Intel 发起的 Clear Container 都发布于2015年5月（是的，早于上面 Linus 的引语）。这组项目的思路很简单 ——   操作系统本身的容器机制没办法解决安全性问题，需要一个隔离层；  虚拟机是一个现成的隔离层，AWS 这样的云服务已经让全世界相信，对户来说，\u0026amp;rdquo;secure of VM\u0026amp;rdquo; 是可以满足需求的；  虚机里面只要有个内核，就可以支持 OCI 规范的语义，在内核上跑个 Linux 应用这并不太难实现；  虚机可能不够快，阻碍了它在容器环境的应用，那么可不可以拥有 \u0026amp;ldquo;speed of container\u0026amp;rdquo; 呢？  现在，如果最后一个问题可以解决，那么它就是我们要的“安全的容器”了——这就是 Kata Containers。 目前 Kata Containers 通常是在 Kubernetes 环境中使用的，Kubelet 通过CRI 接口让 containerd 或 CRI-O 执行运行时操作，通常镜像操作由这些 CRI Daemon 来进行，而根据请求，把 Runtime 操作写成一个 OCI Spec 交给 OCI Runtime 执行。这里，对于 1.2 以上的 containerd 和 1.5 版本上后的 Kata Containers（对应 ），通常是利用 containerd 来完成的：\n 每个 Pod 会有一个 shim-v2 进程来为 containerd/CRI-O 执行各种运行时操作，这个进程和整个 Pod 的生命周期一致，通过一个 ttRPC 接口为 containerd/CRI-O 提供服务； Shim-v2 会为 Pod 启动一个虚拟机作为 PodSandbox提供隔离性，其中运行着一个 Linux 内核，通常这个 Linux 内核是一个裁剪过的内核，不会支持没有必要的设备； 这里用的虚拟机可以是 Qemu 或是 Firecracker，如果是 Firecracker，那么根本就没有模拟的设备，而如果是 Qemu，通过配置和补丁，也会让它尽量小一些，支持的其他虚拟机还包括 ACRN 和 cloud-hypervisor，未来后者可能会被越来越多的用到； 这个虚拟机在启动的时候可能根本就是一个 initrd 而没有完整操作系统，或者有个极小的操作系统，总之，它完全不是按照一台模拟机的操作系统来配置的，它只是支撑容器应用运行的基础设施，以及相关的应用环境 Metrics 采集或应用跟踪调试需要的资源； 容器本身的 rootfs 会在 Sandbox 启动之后，在收到 contaienrd/CRI-O 的创建容器的 OCI 请求之后，以热插拔的方式动态插入到虚机中，容器的 rootfs 准备和虚机本身的启动是可以并行的； 依照 CRI 语义和 OCI 规范，Pod 里可以启动多个相关联的容器，它们被放在同一个虚机里，并且可以互相共享 namespace； 外来的存储卷可以以块设备或文件系统共享的方式插入到 PodSandbox 中，但对于 Pod 里的容器来说，它们都是加载好的文件系统，目前开始逐渐普及的文件系统方式是专为 Kata 这样的场景设计的 virtio-fs，它不仅比传统的 9pfs 更快、有更完整的 POSIX 文件系统的支持，而且借由所谓 vhost-user 和 DAX 技术，它还可以在不 …","date":1588921200,"description":"隔离，让云原生基础设施更完美。","dir":"blog/kata-container-introduction-to-safe-containers/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6075ee3441970bada70f11c633f4ba85","permalink":"https://sofastack.github.io/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","publishdate":"2020-05-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","summary":"从2015年5月初开始创业开发 HyperContainer (runV) 到现在，也快五年了，在这个时候还来写一篇什么是安全容器，显得略有尴尬。不过，也正是经过这五年，越来越多到人","tags":["Kata Container"],"title":"（含直播报名）Kata Containers 创始人：安全容器导论","type":"blog","url":"/sofastack.tech/blog/kata-container-introduction-to-safe-containers/","wordcount":4686},{"author":"Committer 胡宗棠","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文作者胡宗棠，SOFAJRaft Committer，来自中国移动。本文主要介绍 SOFAJRaft 在 Leader 选举过程中的重要优化方案—一种半确定性的优先级选举机制，将会先简单地介绍下原 Raft 算法中随机超时选举机制的大致内容，如果读者对这块内容理解得不够深入，建议可以先阅读下《SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理》。阅读完这篇文章后，再来看本篇的内容会对半确定性的优先级选举机制有更为深刻的理解。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n一、Raft 算法中选举机制的概念与特点 Raft 算法是一种“共识性”算法，这里所谓的“共识性”主要体现在让多个参与者针对某一件事达成完全一致：一件事一个结论，同时对已达成一致的结论，是不可推翻的。基于这个根本特征，就决定了 Raft 算法具有以下几个主要特点：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成。这是主要为了保证在任何的时间段内，Raft 集群最多只能存在一个 Leader 角色的节点； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务； 在 Raft 算法中，选举是很重要的一部分。所谓选举就是在由多个节点组成的一个 Raft 集群中选出一个 Leader 节点，由他来对外提供写服务 （以及默认情况下的读服务）。\n这里先介绍一个任期的概念—Term， 其用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。同时，该 Term ID 的值是按照时间轴单调递增的，它构成了 Raft Leader 选举的必要属性。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。为了让 Raft 集群中的所有节点尽可能的客观公平公正，采用了随机超时时间触发选举，来避免若干个节点在同一时刻尝试选举而导致选票被瓜分的情况，保证选举的顺利完成。SOFAJRaft 的做法是，在 Node 触发选举的定时任务— electionTimer 中的设置每次定时执行的时间点：时间区间 [electionTimeoutMs，electionTimeoutMs + maxElectionDelayMs) 中的任何时间点。\n在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求； 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳； 同时，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。当选举 Leader 选举成功后，整个 Raft 集群就可以正常地向外提供读写服务了，如上图所示，集群由一个 Leader 和两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳和将日志 Log 复制给 Follower。\n但 Raft 算法的“随机超时时间选举机制”存在如下问题和限制：\n 下一个任期 Term，Raft 集群中谁会成为 Leader 角色是不确定的，集群中的其他节点成为 Leader 角色的随机性较强，无法预估。试想这样的一个场景：假设部署 Raft 集群的服务器采用不同性能规格，业务用户总是期望 Leader 角色节点总是在性能最强的服务器上，这样能够为客户端提供较好的读写能力，而上面这种“随机超时时间选举机制”将不能满足需求； 如上图所示，由于会存在选票被瓜分的场景，集群中的各个 Candidate 角色节点将在下一个周期内重新发起选举。而在这个极短的时间内，由于集群中不存在 Leader 角色所以是无法正常向客户端提供读写能力，因此业务用户需要通过其他方式来避免短时间的不可用造成的影响； 二、SOFAJRaft 基于优先级的半确定性选举机制 2.1 SOFAJRaft 基于优先级选举机制的原理 为了解决原本 Raft 算法“随机超时时间选举机制”带来的问题，增加选举的确定性，作者贡献了一种“基于优先级的半确定性选举机制”。主要的算法思想是：通过配置参数的方式预先定义 Raft 集群中各个节点的 priority 选举优先级的值，每个 Raft 节点进程在启动运行后是能够知道集群中所有节点的 priority 的值（包括它自身的、本地会维护 priority 变量）。\n对每个 Raft 节点的配置如下（下面以其中一个节点的配置举例），其中 PeerId 的字符串值的具体形式为：{ip}:{port}:{index}:{priority}；\n在 Raft 节点进程初始化阶段，通过对所有节点 priority 值求最大值来设置至节点自身维护的 targetPriority 本地全局变量里。在上面这个例子中，节点的 targetPriority 本地全局变量值就被设置为 160，而自身的 priority 值为 100。\n在每个 Raft 节点通过随机超时机制触发 PreVote 预选举阶段之前，会通过先比较自身的 priority 值和 targetPriority 值来决定是否参加本轮的 Leader 选举投票。所以，一组 Raft 节点组成的集群在刚启动运行的阶段，priority 值最大的节点（上面例子中 160 的那个节点）必然会优先被选择成为这个集群中 Leader 角色的节点向外提供读和写的服务。\n2.2 SOFAJRaft 优先级选 …","date":1588759200,"description":"继源码解析系列后，推出特性解析系列，本文为 SOFAJRaft 特性解析第一篇，主要介绍 SOFAJRaft 在 Leader 选举过程中的重要优化方案—一种半确定性的优先级选举机制。","dir":"blog/sofa-jraft-priority-election/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d867df257326471e46ce05ed548f72e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-priority-election/","publishdate":"2020-05-06T18:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-jraft-priority-election/","summary":"SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFAJRaft 特性解析"],"title":"蚂蚁金服 SOFAJRaft 优先级选举剖析 | 特性解析","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-priority-election/","wordcount":5415},{"author":"敖小剑","categories":"Service Mesh","content":" 前言 关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做一个资料的整理和汇总，结合个人的理解给出一些看法。另外在本文最后，介绍蚂蚁金服在 Service Mesh 和 API Gateway 融合的这个最新领域的一些开创性的实践和探索，希望给大家一个更有体感的认知。\n 备注1：为了节约篇幅，我们将直奔主题，假定读者对 Service Mesh 和 API Gateway 已有基本的了解。 备注2: 这边文章更关注于梳理整个脉络，内容不会展开的特别细，尤其是其他文章已经详细阐述的部分。如果您在浏览本文之后，还想更深入的了解细节，请继续阅读文章最后的参考资料和推荐阅读。\n 原本清晰的界限：定位和职责 首先，Service Mesh 和 API Gateway 在功能定位和承担的职责上有非常清晰的界限：\n Service Mesh：微服务的网络通信基础设施，负责（系统内部的）服务间的通讯； API Gateway： 负责将服务以 API 的形式暴露（给系统外部），以实现业务功能； 如上图所示：\n从功能和职责上说：\n 位于最底层的是拆分好的原子微服务，以服务的形式提供各种能力； 在原子微服务上是（可选的）组合服务，某些场景下需要将若干微服务的能力组合起来形成新的服务； 原子微服务和组合服务部署于 系统内部，在采用 Service Mesh 的情况下，由 Service Mesh 提供服务间通讯的能力； API Gateway 用于将系统内部的这些服务暴露给 系统外部，以 API 的形式接受外部请求； 从部署上说：\n Service Mesh 部署在系统内部：因为原子微服务和组合服务通常不会直接暴露给外部系统； API Gateway 部署在系统的边缘：一方面暴露在系统之外，对外提供 API 供外部系统访问；一方面部署在系统内部，以访问内部的各种服务。 在这里引入两个使用非常广泛的术语：\n 东西向通讯：指服务间的相互访问，其通讯流量在服务间流转，流量都位于系统内部； 南北向通讯：指服务对外部提供访问，通常是通过 API Gateway 提供的 API 对外部保罗，其通讯流量是从系统外部进入系统内部； 解释一下“东西南北”的由来：如上图所示，通常在地图上习惯性的遵循“上北下南，左东右西”的原则。\n 总结：Service Mesh 和 API Gateway 在功能和职责上分工明确，界限清晰。但如果事情就这么结束，也就不会出现 Service Mesh 和 API Gateway 关系的讨论了，自然也不会有本文。\n问题的根源在哪里？\n 强烈推荐阅读：附录中 Christian Posta 的文章 \u0026amp;ldquo;Do I Need an API Gateway if I Use a Service Mesh?\u0026amp;ldquo;对此有深度分析和讲解。\n 哲学问题：网关访问内部服务，算东西向还是南北向？ 如下图所示，图中黄色的线条表示的是 API Gateway 访问内部服务：\n问题来了，从流量走向看：这是外部流量进入系统后，开始访问对外暴露的服务，应该属于“南北向”通讯，典型如上图的画法。但从另外一个角度，如果我们将 API Gateway 逻辑上拆分为两个部分，先忽略对外暴露的部分，单独只看 API Gateway 访问内部服务的部分，这时可以视 API Gateway 为一个普通的客户端服务，它和内部服务的通讯更像是“东西向”通讯：\n所以，API Gateway 作为一个客户端访问内部服务时，到底算南北向还是东西向，就成为一个哲学问题：完全取决于我们如何看待 API Gateway ，是作为一个整体，还是逻辑上分拆为对内对外两个部分。\n这个哲学问题并非无厘头，在 API Gateway 的各种产品中，关于如何实现 “API Gateway 作为一个客户端访问内部服务” ，就通常分成两个流派：\n 泾渭分明：视 API Gateway 和内部服务为两个独立事物，API Gateway 访问内部服务的通讯机制自行实现，独立于服务间通讯的机制； 兼容并济：视 API Gateway 为一个普通的内部服务的客户端，重用其内部服务间通讯的机制； 而最终决策通常也和产品的定位有关：如果希望维持 API Gateway 的独立产品定位，希望可以在不同的服务间通讯方案下都可以使用，则通常选择前者，典型如 Kong；如果和服务间通讯方案有非常深的渊源，则通常选择后者，典型如 Spring Cloud 生态下的 Zuul 和 SpringCloud Gateway。\n但无论选择哪个流派，都改变不了一个事实，当 “API Gateway 作为一个客户端访问内部服务” 时，它的确和一个普通内部服务作为客户端去访问其他服务没有本质差异：服务发现、负载均衡、流量路由、熔断、限流、服务降级、故障注入、日志、监控、链路追踪、访问控制、加密、身份认证\u0026amp;hellip;\u0026amp;hellip; 当我们把网关访问内部服务的功能一一列出来时，发现几乎所有的这些功能都是和服务间调用重复。\n这也就造成了一个普遍现象：如果已有一个成熟的服务间通讯框架，再去考虑实现 API Gateway，重用这些重复的能力就成为自然而然的选择。典型如前面提到的 Spring Cloud 生态下的 Zuul 以及后面开发的 Spring Cloud Gateway，就是以重用类库的方式实现了这些能力的重用。\n这里又是一个类似的哲学问题：当 “API Gateway 作为一个客户端访问内部服务” 时，它以重用类库的方式实现了代码级别的能力重用，相当于自行实现了一个和普通服务间通讯方案完全一样的客户端，那这个“客户端”发出来的流量算东西向还是南北向？\n答案不重要。\nSidecar：真正的重合点 在进入 Service Mesh 时代之后，Service Mesh 和 API Gateway 的关系开始是这样：\n 功能和职责清晰划分； 客户端访问服务的功能高度重叠； 此时两者的关系很清晰，而且由于当时 Service Mesh 和 API Gateway 是不同的产品，两者的重合点只是在功能上。\n而随着时间的推移，当 Service Mesh 产品和 API Gateway 产品开始出现相互渗透时，两者的关系就开始变得暧昧。\n在 Service Mesh 出现之后，如何为基于 Service Mesh 的服务选择合适的 API Gateway 方案，就慢慢开始提上日程，而其中选择重用 Service Mesh 的能力也自然成为一个探索的方向，并逐步出现新式 API Gateway 产品，其想法很直接：\n如何融合东西向和南北向的通讯方案？\n其中的一个做法就是基于 Service Mesh 的 Sidecar 来实现 API Gateway，从而在南北向通讯中引入 Service Mesh 这种东西向通讯的方案。这里我们不展开细节，我这里援引一个图片(鸣谢赵化冰同学)来解释这个方案的思路：\n这个时候 Service …","date":1588143600,"description":"Service Mesh 和 API Gateway 之间的关系，是“泾渭分明”还是“兼容并进”？","dir":"blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"17986a3e65f4db0f66b6ba707cf27a40","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","publishdate":"2020-04-29T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","summary":"前言 关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做","tags":["Service Mesh","API Gateway "],"title":"Service Mesh 和 API Gateway 关系深度探讨","type":"blog","url":"/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/","wordcount":5306},{"author":"卫恒","categories":"SOFATracer","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。\n 本文根据 SOFAChannel#15 直播分享整理，主题：分布式链路组件 SOFATracer 埋点机制解析。\n大家好，我是宋国磊，花名卫恒，是 SOFATracer 的开源负责人。今天要和大家分享的是分布式链路组件 SOFATracer 埋点机制解析，将通过具体 Demo 演示快速上手 SOFATracer，同时介绍 SOFATracer 功能点，并详细介绍其核心关键「埋点机制」的原理。\nSOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFATracer：https://github.com/sofastack/sofa-tracer\nSOFATracer 作为 SOFAStack 中的分布式链路组件，也伴随着 SOFAStack 走过了两年的时间，在此首先对两年来对 SOFATracer 保持关注并且参与社区建设的同学表示感谢，也希望大家能够继续关注 SOFAStack 的发展，也欢迎更多的同学加入到 SOFAStack 的社区参与中来。\n今天的分享内容主要将会围绕以下三个部分展开：\n SOFATracer 功能点详细介绍； SOFATracer 埋点机制原理详解； 快速上手 SOFATracer 演示； 关于 SOFATracer 更多的问题也欢迎在 Github 上跟我们交流。\nSOFATracer 简介 首先简单介绍一下 SOFATracer。上图展示的是 SOFATracer 目前所包括的基本能力和所支持的插件。下面虚线框中绿色背景部分，是 SOFATracer 提供的基本功能，具体可以参考官方文档描述。上面虚线框中是 SOFATracer 目前所支持的组件，大概分了以下几种类型：客户端、Web、数据存储、消息、RPC、Spring Cloud。\n之前社区也发起过 剖析 | SOFATracer 框架 的源码解析系列文章，在此系列中对 SOFATracer 所提供的能力及实现原理都做了比较全面的分析，有兴趣的同学可以看下。\n今天主要聊一下埋点机制。不同组件的埋点机制也是有很大的差异，SOFATracer 是如何实现对上述组件进行埋点的，下面就详细分析下不同组件的埋点机制。\n埋点机制 目前 SOFATracer 已经支持了对以下开源组件的埋点支持：Spring MVC、RestTemplate、HttpClient、OkHttp3、JDBC、Dubbo(2.6\u0026amp;frasl;2.7)、SOFARPC、Redis、MongoDB、Spring Message、Spring Cloud Stream (基于 Spring Message 的埋点)、RocketMQ、Spring Cloud FeignClient、Hystrix。\n 大多数能力提供在 3.x 版本，2.x 版本从官方 issue 中可以看到后续将不再继续提供新的功能更新；这也是和 SpringBoot 宣布不再继续维护 1.x 版本有关系。\n 标准 Servlet 规范埋点原理 SOFATracer 支持对标准 Servlet 规范的 Web MVC 埋点，包括普通的 Servlet 和 Spring MVC 等，基本原理就是基于 Servelt 规范所提供的 javax.servlet.Filter 过滤器接口扩展实现。\n 过滤器位于 Client 和 Web 应用程序之间，用于检查和修改两者之间流过的请求和响应信息。在请求到达 Servlet 之前，过滤器截获请求。在响应送给客户端之前，过滤器截获响应。多个过滤器形成一个 FilterChain，FilterChain 中不同过滤器的先后顺序由部署文件 web.xml 中过滤器映射的顺序决定。最先截获客户端请求的过滤器将最后截获 Servlet 的响应信息。\n Web 应用程序一般作为请求的接收方，在 SOFATracer 中应用是作为 Server 存在的，其在解析 SpanContext 时所对应的事件为 sr (server receive)。\nSOFATracer 在 sofa-tracer-springmvc-plugin 插件中解析及产生 Span 的过程大致如下：\n Servlet Filter 拦截到 request 请求； 从请求中解析 SpanContext； 通过 SpanContext 构建当前 MVC 的 Span； 给当前 Span 设置 tag、log； 在 Filter 处理的最后，结束 Span； 当然这里面还会设计到其他很多细节，比如给 Span 设置哪些 tag 属性、如果处理异步线程透传等等。本次分享就不展开细节探讨，有兴趣的同学可以自行阅读代码或者和我们交流。\nDubbo 埋点原理 Dubbo 埋点在 SOFATracer 中实际上提供了两个插件，分别用于支持 Dubbo 2.6.x 和 Dubbo 2.7.x；Dubbo 埋点也是基于 Filter ，此 Filter 是 Dubbo 提供的 SPI 扩展-调用拦截扩展 机制实现。\n像 Dubbo 或者 SOFARPC 等 RPC 框架的埋点，通常需要考虑的点比较多。首先， RPC 框架分客户端和服务端，所以在埋点时 RPC 的客户端和服务端必须要有所区分；再者就是 RPC 的调用方式包括很多种，如常见的同步调用、异步调用、oneway 等等，调用方式不同，所对应的 Span 的结束时机也不同，重要的是基本所有的 RPC 框架都会使用线程池用来发起和处理请求，那么如何保证 SOFATracer 在多线程环境下不串也很重要。\n另外 Dubbo 2.6.x 和 Dubbo 2.7.x 在异步回调处理上差异比较大，Dubbo 2.7.x 中提供了 onResponse 方法（后面又升级为 Listener，包括 onResponse 和 onError 两个方法）；而 Dubbo 2.6.x 中则并未提供相应的机制，只能通过对 Future 的硬编码处理来完成埋点和上报。\n 这个问题 Zipkin Brave 对 Dubbo 2.6.x 的埋点时其实也没有考虑到，在做 SOFATracer 支持 Dubbo 2.6.x 时发现了这个 bug，并做了修复。\n SOFATracer 中提供的 DubboSofaTracerFilter 类：\n@Activate(group = { CommonConstants.PROVIDER, CommonConstants.CONSUMER }, value = \u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;, order = 1) public class …","date":1588068000,"description":"SOFATracer 埋点机制解析直播文字回顾。","dir":"blog/sofa-channel-15-retrospect/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4e4c9d4539119eb12ece83c8228ee4a3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-15-retrospect/","publishdate":"2020-04-28T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-channel-15-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["SOFATracer","SOFAChannel"],"title":"分布式链路组件 SOFATracer 埋点机制解析 | SOFAChannel#15 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-15-retrospect/","wordcount":4579},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#16：不得不说的云原生隔离性\n 活动时间：5 月 21 日周四晚 7 点\n 活动形式：线上直播\n 报名方式：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#16：不得不说的云原生隔离性 在云原生时代，容器和 Kubernetes 在日常工作和实际生产中越来越普遍，随之而来的隔离性问题在不断被提起同时也受到了越来越多的关注。\nKata Containers 是 OpenStack 基金会旗下又独立于 OpenStack 项目之外的开放基础设施顶级项目，旨在把虚拟机的安全隔离优势与容器的速度和可管理性统一起来，为用户提供安全快速易用的容器基础设施。\n本期直播，将邀请 Kata Containers 维护者彭涛（花名：巴德）带我们走近云原生的一项基础设施 \u0026amp;ndash; Kata Containers，看它是如何在云原生框架下解决容器隔离性问题的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1197\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 不得不说的云原生隔离性 卫恒 SOFATracer 开源负责人\n你将收获 从 Kubernetes Pod 说起，经典容器场景下的 Pod 分享； 共享内核存在的问题以及解决办法； 上帝说，要有光；我们说，要有 Kata； The speed of containers, the security of VMs； Kata Containers 特性大放送； What? 你刚说过增加一个 VM 间接层的问题？ 嘉宾 SOFAGirl 主持人 卫恒 SOFATracer 开源负责人 ","date":1588057200,"description":"5 月 21 日周四晚 7 点，线上直播第 16 期。","dir":"activities/sofa-channel-16/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4756bc76f718255ad5fc4fd172a706b4","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-16/","publishdate":"2020-04-28T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-16/","summary":"概要 活动主题：SOFAChannel#16：不得不说的云原生隔离性 活动时间：5 月 21 日周四晚 7 点 活动形式：线上直播 报名方式：戳这里 介绍 | SOFAChannel \u0026lt;SOFA:Channel/\u0026gt; 有","tags":["SOFAChannel","Kata Container"],"title":"SOFAChannel#16：不得不说的云原生隔离性","type":"activities","url":"/sofastack.tech/activities/sofa-channel-16/","wordcount":568},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\n**SOFAStack 官网: **https://www.sofastack.tech\n**SOFAStack: **https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n@闫圣哲 提问：\n 请问：关于 SOFAJRaft 线性读，为什么读失败了要应用到状态机呢，是为了拉齐 readindex 吗？\n A：线性一直读不走 raft log （应该是你说的状态机的意思），在 rheakv 里面，如果线性一直读失败了，那么会和write操作一样通过 raft log 达成一致再走状态机读，这是个兜底策略，否则 readIndex 失败了能怎么办呢？ 另一只方式就是直接返回用户失败了。可以具体看一下「JRaft 实现细节解析之高效的线性一致读」这一小节的内容～\nhttps://www.sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFA 项目进展 本周发布详情如下：\n发布 Seata v1.2.0 版本，主要变更如下：\n 支持 XA 事务模式； 支持事务传播机制； 支持批量更新和删除 SQL； TCC 模式支持 hsf 服务调用； Saga 模式性能优化默认不注册分支事务等； 本次发布涉及代码改动文件数 324个，代码行 +11,907 −3,437。 此版本在 feature 和稳定性相对 1.1.0 版本都有较大幅度增强，强烈推荐大家验证和升级到此版本。 详细发布报告：https://seata.io/zh-cn/blog/download.html\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 社区直播报名 本期为第一期 Service Mesh Virtual Meetup 线上系列直播第一期，邀请了四位来自不同公司的嘉宾，从四个角度对 Service Mesh 的应用实践展开分享。\n本次线上 meetup 分享涵盖 Service Mesh 的可观察性和生产实践。为大家介绍 Service Mesh 中的可观察性与传统微服务中可观察性的区别，如何使用 SkyWalking 来观测 Service Mesh，还有来自百度和陌陌的 Service Mesh 生产实践。\n本系列采用线上直播的形式，从 5 月 6 日开始到 5 月 14 日，每周三、周四晚上 19:00-20:00 我们相约进行一个主题分享。\n观看直播方式：保存图片扫码 或 点击“这里”，关注直播间，即可观看直播\n","date":1587722400,"description":"【04/20-04/24】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200424/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"455d22426589849b45f59083c641ee7c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200424/","publishdate":"2020-04-24T18:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200424/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 系列直播预告、Seata 发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200424/","wordcount":1092},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析\n 活动时间：4 月 23 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：30315793（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1167\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 分布式链路组件 SOFATracer 埋点机制解析 卫恒 SOFATracer 开源负责人\n你将收获 带你快速上手 SOFATracer； SOFATracer 功能点详细介绍； SOFATracer 埋点机制原理详解； 嘉宾 SOFAGirl 主持人 卫恒 SOFATracer 开源负责人 ","date":1587114000,"description":"4 月 23 日周四晚 7 点，线上直播第 15 期。","dir":"activities/sofa-channel-15/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e1323556a7e34b0937a8d3c1f6815a77","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-15/","publishdate":"2020-04-17T17:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-15/","summary":"概要 活动主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 活动时间：4 月 23 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍 |","tags":["SOFAChannel","SOFATracer"],"title":"SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-15/","wordcount":442},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@杨俊 提问：\n AT 模式下，当 seata-server 挂掉之后，有未完成的全局事务还在 undo_log 表中，这里有两个问题问一下： 1. seata-server 再次重启后，之前未完成的全局事务偶尔会出现回滚失败的问题，就是一直重试，但始终回滚失败，这个问题如何解决？ 1. seata-server 再次重启后，大多数情况下会成功回滚，但是等待时间过长，感觉要至少3-5分钟才会回滚，这期间涉及到的相关业务服务无法处理其他请求，直至之前的未完成全局事务成功回滚了，才能处理其他请求，请问这个问题如何解决，还有回滚时间在哪里配置能够缩短？ ※上述两个问题都是基于 seata-sample 产生的。\n A：1. 要确认下客户端日志中回滚失败的原因，重启后会恢复重启前未完成的事务。一般是出现脏写数据了，需要人工订正。如果单纯跳过可以删除 server 或 undo_log 对应记录。 2. server.recovery.rollbackingRetryPeriod , 是不是重启前未完成事务过多？\n 好的，谢谢。 1. seata-sample 中三个服务，Account、Order 回滚成功，Storage 回滚失败，然后 seata-server 就一直反复重试，seata 和 storage 及其他服务重启也无用，然后手工将日志删除，依然不停重试，最后重启 seata 服务，系统把删掉的日志又给重写到日志表了，但是 log_status 为1，至此不再重试，但是事务未能成功回滚。 1. 重启未完成的事务只有那么三个而已，并不多。\n A：问题1，你还是要看下回滚失败的原因，客户端日志会打印。 问题2，你提个 issue ，我们排查下。\n2、@吕布 提问：\n 请教一下, AT 下分支事务提交后释放资源, 虽然资源释放了, 但别的事务操作它时还是被全局锁了, 这种释放的好处体现在哪些方面？ A：即使你数据库本地事务也是排队执行的，全局锁是 AT 模式的排队机制，所以如果是相同数据主键的这个与连接无关。释放连接是因为数据库连接资源是宝贵的，不会因为连接池连接数不够导致的其他数据无关的事务得不到执行，从更大的层面认为是一定程度提高了吞吐。\n 明白了，一方面就是说提高吞吐, 然后一方面是避免本地事务的间隙锁和表锁, 导致其他不相关数据被锁, 可以说锁粒度变小了。谢谢。\n Seata：https://github.com/seata/seata\nSOFATracerLab 系列阅读 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览 | 剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码分析 | 剖析 蚂蚁金服分布式链路跟踪组件链路透传原理与SLF4J MDC的扩展能力分析 | 剖析 蚂蚁金服分布式链路跟踪组件采样策略和源码 | 剖析 蚂蚁金服分布式链路跟踪组件埋点机制 | 剖析 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.3.1 版本，主要变更如下：\n multi raft group 之间共享 timer 和 scheduler 等较重的线程资源，优化 multi group 场景中的多余资源占用； 提供 RPC adapter，用户可基于 SPI 扩展不同的 RPC 实现； 正式提供稳定的 RocksDBSegmentLogStorage，适合 value 较大的数据存储； SOFABolt 升级到 1.6.1，支持 SSL 以及具有更好的小数据包传输能力； 引入一个新的数据结构 segment list 来解决 LogManager 中过多的 log memory copy； 采纳 nacos 建议，对 raft Task 增加 join API； 修复 learner 启动晚于 leader 选举成功时无法复制日志的 bug； 致谢（排名不分先后） @jovany-wang 、@SteNicholas 、@zongtanghu 、@OpenOpened\n详细发布报告：https://github.com/sofastack/sofa-jraft/issues/420\n社区直播报名 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n本期直播将通过具体 Demo 带你快速上手 SOFATracer，同时将介绍 SOFATracer 具体功能，并详细介绍其核心关键「埋点机制」的原理。\n 主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 时间：2020年4月23日（周四）19:00-20:00 嘉宾：卫恒 SOFATracer 开源负责人 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1587106800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200417/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1bb16db78404cb9d09dd18ec48374246","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200417/","publishdate":"2020-04-17T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200417/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 直播预告、SOFAJRaft 组件发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200417/","wordcount":1836},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@熊胜 提问：\n 请教个问题，biz 卸载中的关闭 ApplicationContext 这一步是哪里处理的呢？我在 com.alipay.sofa.ark.container.model.BizModel#stop 方法中没看到相应的实现。\n A： biz stop 会发出一个事件，这个时间会被 runtime 拿到处理，可以看下 sofa-boot runtime 里面有处理 biz 卸载事件的 handler。\nSOFAArk：https://github.com/sofastack/sofa-ark\n2、@揭印泉 提问：\n 请问 registry.conf 中的 registry 作用是向 Seata 服务器注册分支事务？\n A：registry 是注册中心，seata server 和 client 都需要的，server 往注册中心注册服务，client 往注册中心找寻 server 服务。\n seata server 和 client 是共用 nacos-config.sh 脚本跑到 Nacos 配置？ 如果他们都配置了 Nacos。\n A：随你，你也可以分开，配置中心没约束，你可以 server 用 nacos，client 用 file，只要读取到即可。\n 服务器端配置了 store.mode=\u0026amp;ldquo;db\u0026amp;rdquo;, 启动参数需要加参数：-m db ?\n A：可以不加，优先级启动参数\u0026amp;gt;配置。\nSeata：https://github.com/seata/seata\nSOFARegistryLab 系列阅读 服务注册中心如何实现 DataServer 平滑扩缩容 | SOFARegistry 解析 服务注册中心数据一致性方案分析 | SOFARegistry 解析 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFAChannel 线上直播合集 SOFAChannel#14：云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理 SOFAChannel#13：云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 SOFAChannel#12：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 SOFATracer v3.0.12 版本，主要变更如下：\n 2个 Dubbo 插件融合, 新的用户请直接使用 sofa-tracer-dubbo-common-plugin； 修复 Dubbo 插件传递错误 spanId 的问题； 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.12\n社区直播报名 SOFATracer 是蚂蚁金服开源的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n本期直播将通过具体 Demo 带你快速上手 SOFATracer，同时将介绍 SOFATracer 具体功能，并详细介绍其核心关键「埋点机制」的原理。\n 主题：SOFAChannel#15：分布式链路组件 SOFATracer 埋点机制解析 时间：2020年4月23日（周四）19:00-20:00 嘉宾：卫恒 SOFATracer 开源负责人 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1586509200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200410/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9f805804c54d097bea99536c21da6387","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200410/","publishdate":"2020-04-10T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200410/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFATracer 直播预告、SOFARegistry 解析系列合集、线上直播回顾合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200410/","wordcount":1705},{"author":"永鹏","categories":"SOFAChannel","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。\n 本文根据 SOFAChannel#14 直播分享整理，主题：云原生网络代理 MOSN 扩展机制解析。\n大家好，我是今天的讲师永鹏，来自蚂蚁金服，目前主要负责 MOSN 的开发，也是 MOSN 的Committer。今天我为大家分享的是云原生网络代理 MOSN 的扩展机制，希望通过这次分享以后，能让大家了解 MOSN 的可编程扩展能力，可以基于 MOSN 的扩展能力，按照自己实际的业务需求进行二次开发。\n前言 今天我们将从以下几个方面，对 MOSN 的扩展机制进行介绍：\n MOSN 扩展能力和扩展机制的详细介绍； 结合示例对 MOSN 的 Filter 扩展机制与插件扩展机制进行详细介绍； MOSN 后续扩展能力规划与展望； 欢迎大家有兴趣一起共建 MOSN。在本次演讲中涉及到的示例就在我们的 Github 的 examples/codes/mosn-extensions 目录下，大家有兴趣的也可以下载下来运行一下，关于这些示例我们还做了一些小活动，也希望大家可以踊跃参与。\nMOSN：https://github.com/mosn/mosn\nMOSN 简介 MOSN 作为云原生的网络代理，旨在为服务提供多协议、模块化、智能化、安全的代理能力。在实际生产使用中，不同的厂商会有不同的使用场景，通用的网络代理能力面对具体的业务场景会显得有些不足，通常都需要进行二次开发以满足业务需求。MOSN 在核心框架中，提供了一系列的扩展机制和扩展点，就是为了满足需要基于业务进行二次开发的场景，同时 MOSN 提供的部分通用逻辑也是基于扩展机制和扩展点的实现。\n比如通过 MOSN “内置实现”的透明劫持的能力，就是通过 MOSN Filter 机制实现。而要实现消息的代理，则可以通过类似的扩展实现。在通用代理的情况下，可以通过 Filter 机制实现业务的认证鉴权，也可以实现定制的负载均衡逻辑；除了转发流程可以扩展实现以外，MOSN 还可以扩展日志的实现，用于对标已有的日志系统，也可以扩展 XDS 实现定制的配置更新；根据不同的业务场景还会有很多具体的扩展情况，就不在此展开了，有兴趣的可以关注MOSN 社区正在建设的源代码分析系列文章与文档。\nMOSN 作为一款网络代理，在转发链路上的网络层、协议层、转发层，在非转发链路上的配置、日志、Admin API 等都提供了扩展能力，对于协议扩展的部分，有兴趣的可以看一下上期直播讲的 MOSN 多协议机制解析，我们今天将重点介绍一下转发层的 Stream Filter 扩展机制与 MOSN 的插件机制。\nStream Filter 机制 在实际业务场景中，在转发请求之前或者回写响应之前，都可能需要对请求/响应做一些处理，如判断是否需要进行转发的认证/鉴权，是否需要限流，又或者需要对请求/响应做一些具有业务语义的记录，需要对协议进行转换等。这些场景都与具体的业务高度耦合，是一个典型的需要进行二次开发的情况。MOSN 的 Stream Filter 机制就是为了满足这样的扩展场景所设计的，它也成为目前 MOSN 扩展中使用频率最高的扩展点。\n在目前的内置 MOSN 实现中，Stream Filter 机制暂时与内置的 network filter: proxy 是绑定的，后面我们也考虑将这部分能力进行抽象，让其他 network filter 也可以复用这部分能力。\n关于 Stream Filter，今天会为大家讲解两个部分的内容： 1. 一个 Stream Filter 包含哪些部分以及在 MOSN 中是如何工作的； 2. 通过一个 Demo 演示来加深对 Stream Filter 的实现与应用；\n一个完整的 Stream Filter 一个完整的 StreamFilter，包含三个部分的内容：\n 一个 StreamFilter 对象，存在于每一个请求/响应当中，在 MOSN 收到请求的时候发挥作用，我们称为 ReceiverFilter，在 MOSN 收到响应时发挥作用，我们称为 SenderFilter。一个 StreamFilter 可以是其中任意一种，也可以是两种都是； 一个 StreamFilterFactory 对象，用于 MOSN 在每次收到请求时，生成 StreamFilter 对象。在 Listener 配置解析时，一个 StreamFilter 的配置会生成一个其对于的 StreamFilterFactory。同一个 StreamFilter 在不同的 Listener 下可能对应不同的 StreamFilterFactory，但是也有的特殊情况下，StreamFilterFactory 可能需要实现为单例； 一个 CreateStreamFilterFactory 方法，配置解析时生成 StreamFilterFactory 就是调用它； Stream Filter 在 MOSN 中是如何工作的 接下来，我们看下 Stream Filter 在 MOSN 中是如何工作的。\n当 MOSN 经过协议解析，收到一个完整的请求时，会创建一个 Stream。此时收到请求的 Listener 中每存在 StreamFilterFactory，就会生成一个 StreamFilter 对象，随后进入到 proxy 流程。\n进入 proxy 流程以后，如果存在 ReceiverFilter，那么就会执行对应的逻辑，ReceiverFilter 包括两个阶段，“路由前”和“路由后”，在每个 Filter 处理完成以后，会返回一个状态，如果是 Stop 则会中止后续尚未执行的 ReceiverFilter，通常情况下，返回 Stop 状态的 Filter 都会回写一个响应。如果是 Continue 则会执行下一个 ReceiverFilter，直到本阶段的 ReceiverFilter 都执行完成或中止；路由前阶段的 ReceiverFIlter 执行完成后，就会执行路由后阶段，其逻辑和路由前一致。如果是正常转发，那么随后 MOSN 会收到一个响应或者发现其他异常直接回写一个响应，此时就会进入到 SenderFilter 的流程中，完成 SenderFilter 的处理。SenderFilter 处理完成以后，MOSN 会写响应给 Client，并且完成最后的收尾工作，收尾工作包括一些数据的回收、日志的记录，以及 StreamFilter 的“销毁”（调用 OnDestroy）。\nStream Filter Demo 对 Stream Filter 有了一个基本的认识以后，我们来看一个实际的 Demo 代码来看下如何实现一个 StreamFilter 并且让它在 MOSN 中发挥作用。\n按照刚才我们的介绍，一个 StreamFIlter 要包含三部分：Filter、Factory、CreateFactory。\n 首先我们实现一个 Filter，其逻辑是模拟一个鉴权的 Filter： …","date":1586437200,"description":"本文根据 SOFAChannel#14 直播分享整理，主题：云原生网络代理 MOSN 扩展机制解析。","dir":"blog/sofa-channel-14-retrospect/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"54f04c153ed4827819de6a6716ad46e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-14-retrospect/","publishdate":"2020-04-09T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-14-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["SOFAChannel","MOSN","Service Mesh"],"title":"云原生网络代理 MOSN 扩展机制解析 | SOFAChannel#14 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-14-retrospect/","wordcount":6144},{"author":"404P","categories":"SOFARegistry ","content":" SOFAStack（Scalable Open Financial Architecture Stack ）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。  SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》最后一篇，本篇作者404P(花名岩途)。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n前言 在微服务架构体系下，服务注册中心致力于解决微服务之间服务发现的问题。在服务数量不多的情况下，服务注册中心集群中每台机器都保存着全量的服务数据，但随着蚂蚁金服海量服务的出现，单机已无法存储所有的服务数据，数据分片成为了必然的选择。数据分片之后，每台机器只保存一部分服务数据，节点上下线就容易造成数据波动，很容易影响应用的正常运行。本文通过介绍 SOFARegistry 的分片算法和相关的核心源码来展示蚂蚁金服是如何解决上述问题的。~~\n服务注册中心简介 在微服务架构下，一个互联网应用的服务端背后往往存在大量服务间的相互调用。例如服务 A 在链路上依赖于服务 B，那么在业务发生时，服务 A 需要知道服务 B 的地址，才能完成服务调用。而分布式架构下，每个服务往往都是集群部署的，集群中的机器也是经常变化的，所以服务 B 的地址不是固定不变的。如果要保证业务的可靠性，服务调用者则需要感知被调用服务的地址变化。\n图1 微服务架构下的服务寻址\n既然成千上万的服务调用者都要感知这样的变化，那这种感知能力便下沉成为微服务中一种固定的架构模式：服务注册中心。\n图2 服务注册中心\n服务注册中心里，有服务提供者和服务消费者两种重要的角色，服务调用方是消费者，服务被调方是提供者。对于同一台机器，往往兼具两者角色，既被其它服务调用，也调用其它服务。服务提供者将自身提供的服务信息发布到服务注册中心，服务消费者通过订阅的方式感知所依赖服务的信息是否发生变化。\nSOFARegistry 总体架构 SOFARegistry 的架构中包括4种角色：Client、Session、Data、Meta，如图3所示：\n图3 SOFARegistry 总体架构\n Client 层 应用服务器集群。Client 层是应用层，每个应用系统通过依赖注册中心相关的客户端 jar 包，通过编程方式来使用服务注册中心的服务发布和服务订阅能力。\n Session 层 Session 服务器集群。顾名思义，Session 层是会话层，通过长连接和 Client 层的应用服务器保持通讯，负责接收 Client 的服务发布和服务订阅请求。该层只在内存中保存各个服务的发布订阅关系，对于具体的服务信息，只在 Client 层和 Data 层之间透传转发。Session 层是无状态的，可以随着 Client 层应用规模的增长而扩容。\n Data 层 数据服务器集群。Data 层通过分片存储的方式保存着所用应用的服务注册数据。数据按照 dataInfoId（每一份服务数据的唯一标识）进行一致性 Hash 分片，多副本备份，保证数据的高可用。下文的重点也在于随着数据规模的增长，Data 层如何在不影响业务的前提下实现平滑的扩缩容。\n Meta 层 元数据服务器集群。这个集群管辖的范围是 Session 服务器集群和 Data 服务器集群的服务器信息，其角色就相当于 SOFARegistry 架构内部的服务注册中心，只不过 SOFARegistry 作为服务注册中心是服务于广大应用服务层，而 Meta 集群是服务于 SOFARegistry 内部的 Session 集群和 Data 集群，Meta 层能够感知到 Session 节点和 Data 节点的变化，并通知集群的其它节点。\nSOFARegistry 如何突破单机存储瓶颈 在蚂蚁金服的业务规模下，单台服务器已经无法存储所有的服务注册数据，SOFARegistry 采用了数据分片的方案，每台机器只保存一部分数据，同时每台机器有多副本备份，这样理论上可以无限扩容。根据不同的数据路由方式，常见的数据分片主要分为两大类：范围分片和 Hash（哈希）分片。\n图4 数据分片\n 范围分片 每一个数据分片负责存储某一键值区间范围的值。例如按照时间段进行分区，每个小时的 Key 放在对应的节点上。区间范围分片的优势在于数据分片具有连续性，可以实现区间范围查询，但是缺点在于没有对数据进行随机打散，容易存在热点数据问题。\n Hash （哈希）分片 Hash 分片则是通过特定的 Hash 函数将数据随机均匀地分散在各个节点中，不支持范围查询，只支持点查询，即根据某个数据的 Key 获取数据的内容。业界大多 KV（Key-Value）存储系统都支持这种方式，包括 cassandra、dynamo、membase 等。业界常见的 Hash 分片算法有哈希取模法、一致性哈希法和虚拟桶法。\n哈希取模 哈希取模的 Hash 函数如下：\nH(Key) = hash(key) mod K; 这是一个 key-machine 的函数。key 是数据主键，K 是物理机数量，通过数据的 key 能够直接路由到物理机器。当 K 发生变化时，会影响全体数据分布。所有节点上的数据会被重新分布，这个过程是难以在系统无感知的情况下平滑完成的。\n图5 哈希取模\n一致性哈希 分布式哈希表（DHT）是 P2P 网络和分布式存储中一项常见的技术，是哈希表的分布式扩展，即在每台机器存储部分数据的前提下，如何通过哈希的方式来对数据进行读写路由。其核心在于每个节点不仅只保存一部分数据，而且也只维护一部分路由，从而实现 P2P 网络节点去中心化的分布式寻址和分布式存储。DHT 是一个技术概念，其中业界最常见的一种实现方式就是一致性哈希的 Chord 算法实现。\n 哈希空间 一致性哈希中的哈希空间是一个数据和节点共用的一个逻辑环形空间，数据和机器通过各自的 Hash 算法得出各自在哈希空间的位置。\n图6 数据项和数据节点共用哈希空间\n图7是一个二进制长度为5的哈希空间，该空间可以表达的数值范围是0～31（2^5），是一个首尾相接的环状序列。环上的大圈表示不同的机器节点（一般是虚拟节点），用 $$Ni$$ 来表示，$$i$$ 代表着节点在哈希空间的位置。例如，某个节点根据 IP 地址和端口号进行哈希计算后得出的值是7，那么 N7 则代表则该节点在哈希空间中的位置。由于每个物理机的配置不一样，通常配置高的物理节点会虚拟成环上的多个节点。\n图7 长度为5的哈希空间\n环上的节点把哈希空间分成多个区间，每个节点负责存储其中一个区间的数据。例如 N14 节点负责存储 Hash 值为8～14范围内 …","date":1586340000,"description":"本文介绍 SOFARegistry 分片算法和相关核心源码来展示蚂蚁金服是如何解决数据分片带来的节点上下线数据波动的问题。","dir":"blog/sofa-registry-dataserver-smooth-expansion-contraction/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"35c77b7278ad2675b56540b1f97ecf8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","publishdate":"2020-04-08T18:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","summary":"SOFAStack（Scalable Open Financial Architecture Stack ）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里","tags":["SOFARegistry ","剖析 | SOFARegistry 框架","SOFALab"],"title":"蚂蚁金服服务注册中心如何实现 DataServer 平滑扩缩容 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/","wordcount":6179},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@王磊 提问：\n SOFARPC 注册的 Dubbo 服务和通过 Dubbo 组件注册的服务可以互通的吧？\n A：可以的， Dubbo 是桥接模式。\n 这个怎么配置的。现在注册的 Dubbo 服务 generic=false。 A：现在只支持泛化调用不支持泛化服务，可以关注一下这个 Issue，后期会排期做，也欢迎共建。 https://github.com/sofastack/sofa-rpc/issues/894\nSOFARPC：https://github.com/sofastack/sofa-rpc\n2、@黄振祥 提问：\n 使用 SOFAStack 快速构建微服务的 Demo 时遇到的一些问题，可以怎么解决呢？ https://github.com/sofastack-guides/kc-sofastack-demo\n A：可以详细看一下这个 issue： https://github.com/sofastack-guides/kc-sofastack-demo/issues/9\n3、@哈哈哈 提问：\n AT 和 Saga 有什么区别吗，AT 我感觉是自动的 Saga。\n A：也可以这么说，Saga 框架上没有加锁，AT 有加锁，事实上 Seata Saga 是一个具备“服务编排”和“Saga 分布式事务”能力的产品。\n4、@全 提问：\n 麻烦问一下，Seata TCC 只支持 Dubbo、SOFARPC 吗？\n A：还有 local，其他的 rpc 框架可以基于 local 包装一下或者扩展下 parser，也欢迎大家贡献。\n 如果通过 spring-cloud 整合的话需要扩展这个 Parser 是吧？\n A：是的，但是像 resttemplate 这种 rest 请求没办法走 parser，需要你 local 包一下。 Seata：https://github.com/seata/seata\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n发布 SOFA MOSN v0.11.0 版本，主要变更如下：\n 重构 XProtocol Engine，优化了协议层的实现； 支持 Listener Filter 的扩展，基于 Listener Filter 重新实现了透明劫持能力； 优化了 LDS 接口，修改了路由配置结构，完善了变量机制； 完善了 TraceLog 的实现； Bug Fix； 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/v0.11.0\n社区直播报名 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n本期直播包含 Demo，可以先下载 Demo，提前体验 MOSN 拓展机制的使用（报名页面有详细 Demo 链接）。\n 主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 时间：2020年4月9日（下周四）19:00-20:00 嘉宾：永鹏 蚂蚁金服高级开发工程师、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1585908000,"description":"【03/30-04/03】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200403/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e109585632269dffffd2819dd121da2b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200403/","publishdate":"2020-04-03T18:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200403/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告 \u0026 发布更新、Service Mesh 落地实践解析合辑","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200403/","wordcount":1376},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@John Deng 提问：\n 现在 MOSN 对 Dubbo 协议支持怎样？\n A：这儿，协议支持了：https://github.com/mosn/mosn/tree/master/pkg/protocol/xprotocol/dubbo 完整的支持，我们已经创建了 Dubbo WG 专门来做这个事情，https://github.com/mosn/community/blob/master/wg-dubbo.md\n 已经生产就绪了吗？\n A：如果是 Dubbo 的话，目前还没有生产可用，主要是相关生态还没对齐，我们正在推进 Dubbo WG kick off，有兴趣可以加入一起完善。 如果指 MOSN 的话，我们去年双11已经线上部署几十万容器，生产可用。 MOSN：https://github.com/mosn/mosn\n2、@Liang 提问：\n SOFAJRaft 的 Leader 节点执行完状态机，把这次的 index 提交之后，什么时候通知的 Follower 节点也提交呢？ 我看现象是 Follower 也立刻跟着提交了，但是这块代码没有找到。想问下具体是怎么实现的，谢谢~\n A：Leader 会往 Follower 发送 lastCommittedIndex， 详情见：\ncom.alipay.sofa.jraft.core.NodeImpl#handleAppendEntriesRequest com.alipay.sofa.jraft.core.BallotBox#setLastCommittedIndex SOFAJRaft：https://github.com/sofastack/sofa-jraft\n3、@琦玉 提问：\n 这种情况下，状态机怎么确定是执行回滚，还是执行重试呢？ A：这个是由开发者决定的。 Server 事务恢复的逻辑是：\n 当提交失败时，重试提交； 补偿失败时，重试补偿； 如果超时默认是进行重试补偿，如果配置了这个\u0026amp;rdquo;RecoverStrategy\u0026amp;rdquo;: \u0026amp;ldquo;Forward\u0026amp;rdquo;则进行重试向前执行； 这个\u0026amp;rdquo;RecoverStrategy\u0026amp;rdquo;: \u0026amp;ldquo;Forward\u0026amp;rdquo;配置是告诉状态机默认的事务恢复策略。如果发现这条事务无法向前，也可以通过手动调状态机“补偿”。\n 这种是否最终成功可能有其它业务上的条件，比如取决于另外一个步骤的成功与否。没法在状态语言里面定义。如果 A 充值成功，事务失败，B 就不能回退，必须重试到最终成功。如果 A 充值失败，事务失败，B 就可以回退。这种具体是要怎么去处理呢？分布式事务内先给用户 A 充值, 然后给用户 B 扣减余额, 如果在给 A 用户充值成功, 在事务提交以前, A 用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了\n A：不允许这样设计，业务流水，必须先扣，再充，必须要遵循“宁可长款，不可短款”的原则。\n 意思是分成两个独立的事务，Saga 模式中不定义在同一个状态机流程里？先把B的扣钱流程执行完，再去执行 A 的充值流程 ？\n A：不是，是在同一个事务里，同一个流程，要先进行扣 B 的款，再给 A 充值，那和如果充值失败，可以回滚 B。\n 假如同时给 B 和 C 充值呢？\n A：那就都向前重试，因为充钱业务上不会失败。\n 如果做重试的话，是不是整个流程其它做回退的动作都要在充值动作之前完成?在重试动作之后的动作都只能做重试?\n A：也不是完全只能这样，要根据业务场景来吧。做一个合理的流程设计。 相关阅读：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 Seata：https://github.com/seata/seata\n本周推荐阅读 Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍 云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 SOFARegistry v5.4.2 版本，主要变更如下：\n 修复 cloud 模式推送时客户端 cell 设置错误的问题； 详细发布报告： https://github.com/sofastack/sofa-registry/releases/tag/v5.4.2\n社区直播报名 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n本期直播包含 Demo，可以先下载 Demo，提前体验 MOSN 拓展机制的使用（报名页面有详细 Demo 链接）。\n 主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 时间：2020年4月9日（周四）19:00-20:00 嘉宾：永鹏 蚂蚁金服高级开发工程师、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 ","date":1585299600,"description":"【03/23-03/27】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-0327/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0c6b194e66eeb4c95efa4260e279bab7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0327/","publishdate":"2020-03-27T17:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-0327/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告、本周直播回顾整理、SOFARegistry 发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-0327/","wordcount":1980},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析\n 活动时间：4 月 9 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁金服开源并经过几十万容器的生产级验证。\nMOSN 作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。在实际的生产使用场景中，通用的网络代理总会与实际业务定制需求存在差异，MOSN 提供了一系列可编程的扩展机制，就是为了解决这种场景。\n本次分享将向大家介绍 MOSN 的扩展机制解析以及一些扩展实践的案例。\n欢迎先下载 Demo，提前体验 MOSN 拓展机制的使用，成功完成预习作业—— Demo 完整操作的，有机会获得小礼物哟（记得留下完成的证明，获得方式在直播中公布），我们将在直播中公布答案——进行 Demo 的详细演示。PS：在直播中也会发布闯关任务，完成闯关任务也有机会获得小礼物哟～\nDemo：https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions\nDemo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions\n欢迎了解 MOSN：https://github.com/mosn/mosn\n| 针对人群 对云原生、Service Mesh、网络代理有基本了解，想要了解云原生以及对云原生网络代理 MOSN 有二次开发需求的人群\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：21992058（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1131\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 永鹏 蚂蚁金服高级开发工程师， MOSN Committer\n你将收获 快速了解 MOSN 的多种扩展能力 3 个案例，实际体验 MOSN 扩展能力 多案例多形式，使用 MOSN 实现个性化业务需求 嘉宾 SOFAGirl 主持人 永鹏 蚂蚁金服高级开发工程师， MOSN Committer ","date":1585299600,"description":"4 月 9 日周四晚 7 点，线上直播第 14 期。","dir":"activities/sofa-channel-14/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0e1d5c0ea19ec82218fbf675b891ee5a","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-14/","publishdate":"2020-03-27T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-14/","summary":"概要 活动主题：SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析 活动时间：4 月 9 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍","tags":["SOFAChannel","MOSN"],"title":"SOFAChannel#14：云原生网络代理 MOSN 的扩展机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-14/","wordcount":901},{"author":"无钩","categories":"MOSN","content":" SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。 本文根据 SOFAChannel#13 直播分享整理，主题：云原生网络代理 MOSN 多协议机制解析。\n 大家好，我是今天的讲师无钩，目前主要从事蚂蚁金服网络代理相关的研发工作，也是 MOSN 的 Committer。今天要和大家分享的是《云原生网络代理 MOSN 多协议机制解析》，并介绍对应的私有协议快速接入实践案例以及对 MOSN 实现多协议低成本接入的设计进行解读。\n我们将按以下顺序进行介绍：\n 多协议机制产生的背景与实践痛点； 常见的协议扩展思路初探； SOFABolt 协议接入实践；（重点） MOSN 多协议机制设计解读；（重点） 后续规划及展望； 其中第三点「接入实践」是今天分享的重点，希望能给大家就「如何在 MOSN 中快速扩展私有协议接入」有一个具体的感受。另外「MOSN 如何实现多协议框架」也是很多人关心和问题，我们将摘选几个技术功能，对其背后的设计思考进行解读。\nMOSN 简介 云原生网络代理 MOSN 定位是一个全栈的网络代理，支持包括网络接入层(Ingress)、API Gateway、Service Mesh 等场景，目前在蚂蚁金服内部的核心业务集群已经实现全面落地，并经受了 2019 年双十一大促的考验。今天要向大家介绍的是云原生网络代理 MOSN 核心特性之一的多协议扩展机制，目前已经支持了包括 SOFABolt、Dubbo、TARS 等多个协议的快速接入。\nMOSN：https://github.com/mosn\n多协议机制产生的背景与实践痛点 首先介绍一下多协议机制产生的背景。\n前面提到，蚂蚁金服 2019 年双十一核心链路百分之百 Mesh 化，是业界当时已知的最大规模的 Service Mesh 落地，为什么我们敢这么做？因为我们具备能够让架构平滑迁移的方案。\u0026amp;rdquo;兼容性\u0026amp;rdquo;是任何架构演进升级都必然要面对的一个问题，这在早已实践微服务化架构的蚂蚁金服内部同样如此。为了实现架构的平滑迁移，需要让新老节点的外在行为尽可能的表现一致，从而让依赖方无感知，这其中很重要的一点就是保持协议兼容性。\n因此，我们需要在 Service Mesh 架构下，兼容现有微服务体系中的通信协议——也就是说需要在 MOSN 内实现对目前蚂蚁金服内部通信协议的扩展支持。\n基于 MOSN 本身的扩展机制，我们完成了最初版本的协议扩展接入。但是在实践过程中，我们发现这并不是一件容易的事情：\n 相比编解码，协议自身的处理以及与框架集成才是其中最困难的环节，需要理解并实现包括请求生命周期、多路复用处理、链接池等等机制； 社区主流的 xDS 路由配置是面向 HTTP 协议的，无法直接支持私有协议，存在适配成本； 基于这些实践痛点，我们设计了 MOSN 多协议框架，希望可以降低私有协议的接入成本，加快普及 ServiceMesh 架构的落地推进。\n常见的协议扩展思路初探 前面介绍了背景，那么具体协议扩展框架要怎么设计呢？我们先来看一下业界的思路与做法。\n协议扩展框架 - Envoy 注：图片来自 Envoy 分享资料\n第一个要介绍的是目前发展势头强劲的 Envoy。从图上可以看出，Envoy 支持四层的读写过滤器扩展、基于 HTTP 的七层读写过滤器扩展以及对应的 Router/Upstream 实现。如果想要基于 Envoy 的扩展框架实现 L7 协议接入，目前的普遍做法是基于 L4 filter 封装相应的 L7 codec，在此基础之上再实现对应的协议路由等能力，无法复用 HTTP L7 的扩展框架。 协议扩展框架 - Nginx 第二个则是老牌的反向代理软件 Nginx，其核心模块是基于 Epoll/Kqueue 等 I/O 多路复用技术之上的离散事件框架，基于事件框架之上构建了 Mail、Http 等协议模块。与 Envoy 类似，如果要基于 Nginx 扩展私有协议，那么也需要自行对接事件框架，并完整实现包括编解码、协议处理等能力。\n协议扩展框架 - MOSN 最后回过头来，我们看一下 MOSN 是怎么做的。实际上，MOSN 的底层机制与 Envoy、Nginx 并没有核心差异，同样支持基于 I/O 多路复用的 L4 读写过滤器扩展，并在此基础之上再封装 L7 的处理。但是与前两者不同的是，MOSN 针对典型的微服务通信场景，抽象出了一套适用于基于多路复用 RPC 协议的扩展框架，屏蔽了 MOSN 内部复杂的协议处理及框架流程，开发者只需要关注协议本身，并实现对应的框架接口能力即可实现快速接入扩展。\n三种框架成本对比 最后对比一下，典型微服务通信框架协议接入的成本，由于 MOSN 针对此类场景进行了框架层面的封装支持，因此可以节省开发者大量的研发成本。\nSOFABolt 协议接入实践 初步了解多协议框架的设计思路之后，让我们以 SOFABolt 协议为例来实际体验一下协议接入的过程。\nSOFABolt 简介 这里先对 SOFABolt 进行一个简单介绍，SOFABolt 是一个开源的轻量、易用、高性能、易扩展的 RPC 通信框架，广泛应用于蚂蚁金服内部。\nSOFABolt：https://github.com/sofastack/sofa-bolt\n基于 MOSN 的多协议框架，实际编写了 7 个代码文件，一共 925 行代码(包括 liscence、comment 在内)就完成了接入。如果对于协议本身较为熟悉，且具备一定的 MOSN/Golang 开发经验，甚至可以在一天内就完成整个协议的扩展，可以说接入成本是非常之低。\nGithub: https://github.com/mosn/mosn/tree/master/pkg/protocol/xprotocol/bolt\n下面让我们进入正题，一步一步了解接入过程。\nStep1：确认协议格式 第一步，需要确认要接入的协议格式。为什么首先要做这个，因为协议格式是一个协议最基本的部分，有以下两个层面的考虑：\n 任何协议特性以及协议功能都能在上面得到一些体现，例如有无 requestId/streamId 就直接关联到协议是否支持连接多路复用； 协议格式与报文模型直接相关，两者可以构成逻辑上的映射关系；而这个映射关系也就是所谓的编解码逻辑； 以 SOFABolt 为例，其第一个字节是协议 magic，可以用于校验当前报文是否属于 SOFABolt 协议，并可以用于协议自动识别匹配的场景；第二个字节是 type，用于标识当前报文的传输类型，可以是 Request / RequestOneway / Response 中的一种；第三个字节则是当前报文的业务类型，可以是心跳帧，RPC 请求/响应等类型。后面的字段就不一一介绍了，可以发现，理解了协议格式本身，其实对于协议的特性支持和模型编解码就理解了一大半，因此第一步协议格式的确认了解是重中之重，是后续一切工作开展的前提。\nStep2：确认报文模型 顺应第一步，第二步的主要工作是确认报文编程模型。一般地，在第 …","date":1585227600,"description":"本文根据昨晚直播整理，主要分享云原生网络代理 MOSN 多协议机制解析，并介绍对应私有协议快速接入实践案例以及对其实现多协议低成本接入的设计进行解读。","dir":"blog/sofa-channel-13-retrospect/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"683f36d11af9e48e910e694bf1a119fc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-13-retrospect/","publishdate":"2020-03-26T21:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-channel-13-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播","tags":["MOSN","Service Mesh","SOFAChannel"],"title":"云原生网络代理 MOSN 多协议机制解析 | SOFAChannel#13 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-13-retrospect/","wordcount":6523},{"author":"敖小剑","categories":"Service Mesh","content":" 在2019年5月，CNCF 筹建通用数据平面 API 工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API。\n当时我写了一个博客文章 “CNCF 正在筹建通用数据平面 API 工作组，以制定数据平面的标准 API” 对此进行了介绍。当时 UDPA 还处于非常早期的筹备阶段，信息非常的少。\n现在9个月过去了，我最近收集并整理了一下 UDPA 目前的情况和信息，给大家介绍一下 UDPA 目前最新的进展（截止2020年2月24日）。\n另外蚂蚁金服开源的云原生网络代理 MOSN 目前已经支持 xDS v2 API，后面也会逐步向着 UDPA 的方向去演进，兼容标准 Istio，感兴趣的读者可以去了解下。\nMOSN：https://github.com/mosn/mon\nUDPA 介绍 首先快速介绍一下什么是 UDPA：\n UDPA ：“Universal Data Plane API”的缩写， “通用数据平面 API” UDPA-WG：”Universal Data Plane API Working Group”的缩写，这是 CNCF 下的一个工作组，负责制定 UDPA； UDPA 的目标，援引自 https://github.com/cncf/udpa 的描述：\n 通用数据平面 API 工作组（UDPA-WG）的目标是召集对数据平面代理和负载均衡器的通用控制和配置 API 感兴趣的业界人士。\n UDPA 的愿景，同样援引：\n 通用数据平面 API（UDPA）的愿景在 https://blog.envoyproxy.io/the-universal-data-plane-api-d15cec7a 中阐明。我们将寻求一组 API，它们为 L4/L7 数据平面配置提供事实上的标准，类似于 SDN 中 L2/L3/L4 的 OpenFlow 所扮演的角色。 这些 API 将在 proto3 中规范定义，并通过定义良好的、稳定 API 版本控制策略，从现有的 Envoy xDS API 逐步演进。API 将涵盖服务发现、负载均衡分配、路由发现、监听器配置、安全发现、负载报告、运行状况检查委托等。 我们将对 API 进行改进和成型，以支持客户端 lookaside 负载均衡（例如 gRPC-LB），Envoy 之外的数据平面代理，硬件 LB，移动客户端以及其他范围。我们将努力尽可能与供应商和实现无关，同时坚持支持已投入生产的 UDPA 的项目（到目前为止，Envoy 和 gRPC-LB）。\n 对 UDPA 感兴趣的同学，可以通过以下两个途径进一步深入了解：\n UDPA @ GitHub：UDPA 在 github 上的项目，UDPA API 定义的代码都在这里； Universal Data Plane API Working Group (UDPA-WG)：CNCF 的 UDPA 工作组，可以通过加入工作组的方式了解更多信息； UDPA 和 xDS 的关系 在展开 UDPA 的细节之前，有必要先解释清楚 UDPA 和 xDS 的关系，因为这对理解 UDPA 会有很大帮助。\n在2019年11月的 EnvoyCon 上，Envoy 的开发者，也是目前 UDPA 最主要的负责人之一，来自 Google 的 Harvey Tuch，有一个演讲非常详细而清晰的解答了这个问题，这个演讲的标题是：“The Universal Dataplane API (UDPA): Envoy’s Next Generation APIs”。\n 备注：这里我直接援引这份演讲的部分内容，以下两张图片均出自 这份演讲的PPT 。鸣谢 Harvey。\n 下图展示了近年来 xDS 协议的演进历程和未来规划：\n 2017年，xDS v2 引入 proto3 和 gRPC，同年 Istio 项目启动； 2018和2019年，xDS v2 API 继续发展，陆续引入了新的 API 定义，如 HDS / LRS / SDS 等，尤其是为了改进 Pilot 下发性能，开始引入增量推送机制； xDS v3 API 原计划于2019年年底推出，但目前看技术推迟，目前 v3 还是 alpha1 状态，预计在即将发布的 Istio 1.5 中会有更多的 v3 API 引入。同时 v3 API 也引入了 UDPA 的部分内容，但是由于 UDPA 目前进展缓慢，对 xDS 的影响并不大，主要还是 xDS 自身的发展，比如对 API 和技术债务的清理； 但在2020年，预计 UDPA 会有很大的进展，尤其是下面我们将会展开的 UDPA-TP 和 UDPA-DM 的设计开始正式制定为 API 之后。而 xDS v4 预计将基于 UDPA ，因此 xDS v4 可能会迎来比较大的变动； 简单总结说：xDS 将逐渐向 UDPA 靠拢，未来将基于 UDPA 。\n下图则展示了 Envoy 在 xDS 版本支持上的时间线：\n目前看这个计划在执行时稍微有一点点延误，原计划于2019年年底推出的 v3 的 stable 版本实际上是在1月中定稿的。（备注：具体可参考 Envoy PR api: freeze v3 API ）。然后目前正在广泛使用的 v2 API 将被标记为 depreated。而且在2020年底，v3 API 预计被 v4 API 取代（注意 v4 API 将会是基于 UDPA），而目前我们最熟悉的 v2 API 将计划在2020年底移除，不再支持！\n上图也展示了未来 xDS 协议的大版本演进和更替的方式，总的来说规律是这样：\n 一年一个大版本：2019 v2 -\u0026amp;gt; 2020 v3 -\u0026amp;gt; 2021 v4 -\u0026amp;gt;2022 v5； 每个大版本都要经历 alpha -\u0026amp;gt; stable -\u0026amp;gt; deprecated -\u0026amp;gt; removed 四个阶段，每个阶段历时一年； 稳定后 Envoy 会同时存在三个 API 大版本：正在使用的稳定版本，已经弃用的上一个稳定版本，准备开发的新的下一个大版本（但只会是Alpha）； 发布一个新的 stable 的大版本，就一定会 deprecated 上一个稳定的大版本，同时 remove 更前一个已经 deprecated 的大版本； 所谓 “长江后浪推前浪，前浪死在沙滩上”，又或者说，“江山代有新版出，各领风骚12个月”。\n 备注：Envoy 具体的稳定 API 版本控制策略，可以参见 Envoy 的设计文档 “Stable Envoy API versioning” ，不过这个文档长的有点过分，嫌长的同学可以直接看这个文档的缩减版本 API versioning guidelines。\n UDPA API 进展 言归正传，我们来看一下 UDPA 目前的最新进展。从 https://github.com/cncf/udpa ，可以看到目前 UDPA 中已经定义好的部分 API 内容：\n类型定义 目前只定义了一个类型 TypedStruct。\nTypedStruct 包含任意 JSON …","date":1585130400,"description":"本文收集并整理了一下 UDPA 目前的情况和信息，给大家介绍一下 UDPA 目前最新的进展。","dir":"blog/service-mesh-api-udpa-follow-up/","fuzzywordcount":11000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7293f926580393ddac18da73da056d07","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","publishdate":"2020-03-25T18:00:00+08:00","readingtime":22,"relpermalink":"/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","summary":"在2019年5月，CNCF 筹建通用数据平面 API 工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API。 当时我写了一","tags":["Service Mesh"],"title":"Service Mesh 通用数据平面 API（UDPA）最新进展深度介绍","type":"blog","url":"/sofastack.tech/blog/service-mesh-api-udpa-follow-up/","wordcount":10901},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@木易 提问：\n 请问，这个并发隔离是怎么做到的？二阶段是一阶段的最后去做的对吧，在 TCC 模式下的，RPC 调用二阶段失败了或者 MQ 异步调二阶段失败了，那二阶段失败了可咋整？ A：一阶段如果都成功了，说明所有分支的事务的“资源”已经预留成功了，这时候的失败都是“技术上”的失败比如网络抖动，这时会要重试提交。举个例子，如果二阶段一部份服务 commit 成功了，然后有一个失败了，这时只能重试提交，不能回滚，因为那些二阶段已经成功的服务，不能回滚了。\n 是不是一阶段的发起方还得根据业务编号记录一条 response，然后参与方定时去扫状态未更新的记录，然后根据业务编号去查 response 中的状态再更新自己的状态？\n A：业务流水是肯定要记的。\n 有行锁可用余额肯定没问题，就是这个预扣冻结字段如果放这行数据里，一阶段一释放锁，另一个事务给他改了就不对了，所以我感觉表里加这个字段不行啊，还是得用业务流水加这个预扣字段形成一条记录，这样事务之间的这个才是隔离的 。\n A：是的，是在业务上还要记录一条流水，一来为是业务上的要求，二来可以做幂等和防悬挂控制，三也是在回滚的时候需要这条流水才知道要回滚多少金额。\n相关阅读：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理\nSeata：https://github.com/seata/seata\n2、@邓从宝 提问：\n 您好，合并部署是个什么概念？什么时候会用到合并部署？\n A： 就是将原本独立开发的应用部署在一起，比如资源有限要高密度部署的时候，比如两个微服务应用频繁 rpc 交互想要部署到一个进程里提高性能的时候。\n3、@苏东东 提问：\n SOFAJRaft 能不能不通过 rpcserver 注册 GetValueRequestProcessor，我想用自己的 RPC 框架。\n A：暂时不能，请关注这个 pr 合并以后就可以了 https://github.com/sofastack/sofa-jraft/pull/402 详细 issue： https://github.com/sofastack/sofa-jraft/issues/268 SOFAJRaft：https://github.com/sofastack/sofa-jraft\nSOFAArk 解析文章集合 蚂蚁金服轻量级类隔离框架 Maven 打包插件解析 | SOFAArk 源码解析 蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析 从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFATracer 解析文章集合 蚂蚁金服分布式链路跟踪组件 SOFATracer 中 Disruptor 实践（含源码） 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 埋点机制剖析 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 采样策略和源码剖析 蚂蚁金服开源分布式链路跟踪组件 SOFATracer 链路透传原理与SLF4J MDC 的扩展能力剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析 社区直播报名 作为云原生网络代理，Service Mesh 是 MOSN 的重要应用场景。随着 Service Mesh 概念的日益推广，大家对这套体系都已经不再陌生，有了较为深入的认知。但是与理论传播相对应的是，生产级别的大规模落地实践案例却并不多见。这其中有多方面的原因，包括社区方案饱受诟病的“大规模场景性能问题”、“配套的运维监控基础设施演进速度跟不上”、“存量服务化体系的兼容方案”等等。\n现实场景中，大部分国内厂商都有一套自研 RPC 的服务化体系，属于「存量服务化体系的兼容方案」中的协议适配问题。为此，MOSN 设计了一套多协议框架，用于降低自研体系的协议适配及接入成本，加速 Service Mesh 的落地普及。SOFAChannel#13，将向大家介绍 MOSN 实现多协议低成本接入的设计思路以及相应的快速接入实践案例。\n 主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 时间：2020年3月26日（周四）19:00-20:00 嘉宾：无钩，蚂蚁金服技术专家、MOSN Committer 形式：线上直播 报名方式：点击“这里”，即可报名 欢迎参与投票 MOSN Logo 社区投票，在本期直播结束将公布投票结果，确定最新 Logo。\n 投票方式：回复 issue 你喜欢的方案编号以及原因 ","date":1584691200,"description":"【03/16-03/20】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200320/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e2add88606de2be4ddcf9c9ac2e4bbef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200320/","publishdate":"2020-03-20T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200320/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 直播预告、SOFAArk\u0026SOFATracer 解析文章合集","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200320/","wordcount":1761},{"author":"盲僧","categories":"SOFAArk","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAArk 实现原理》第二篇，本篇作者盲僧，来自 OYO。《剖析 | SOFAArk 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附系列共建列表，目前已完成领取。\n前言 SOFAArk 是 SOFA 团队开源的又一款扛鼎力作，它是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署的能力。\n从 2016 年底开始，蚂蚁金服内部开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构，也是为系列文章做好铺垫。\nSOFAArk biz 的打包插件是 sofa-ark-maven-plugin ，它可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式的 Ark 包或者 Ark Biz 包，关于 Ark 包和 Ark Biz 包可以参考这里：\n Ark 包：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/ Ark Biz：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/ 本文将从如下三个方面进行介绍：先对插件的使用和打包出来的产物做一个简单介绍，然后告诉大家调试插件的方法，最后对整个插件的原理做一个流程图和阐述。\nSOFAArk ：https://github.com/sofastack/sofa-ark\nSOFAArk 插件使用 文中的示例代码可以参考 我的 github\n 插件使用 先将 Spring Boot 的打包插件 spring-boot-maven-plugin 删除或者注释，然后再引入如下插件即可：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 执行 mvn package 命令后，将会打出如下结构的 3 个 jar 包，大家可以自行解压这三个 jar 包，看一看里面的具体内容，下面我们简单分析一下：\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT.jar ：它是 maven 插件打出来的原生 jar 包，只包含我们写的代码和 manifest 文件，无特殊意义。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-biz.jar ：这个 jar 包称之为 Ark Biz 包，因为 SOFAArk 容器是支持运行多个 Ark Biz 的，所以打成这种包是为了和别的项目一起合并部署使用，另外 Ark 包里也包含了这个。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-executable.jar ：这个 jar 包称之为 Ark 包，从字面上来看它是一个可执行的 jar 包，即意味着它是一个可以用 java-jar 命令来单独运行的 Fat Jar，类似于我们用 Spring Boot 插件打出来的包。\n后面的分析主要是围绕 Ark 包来做讲解，因为它包含了 Ark Biz 包，所以只要搞明白它是如何生成的，那么对整个插件的原理也就基本了解了。\n与 Spring Boot 插件对比 要想分析出 sofa-ark-maven-plugin 插件的作用，我们需要先和 Spring Boot 的插件进行对比，从打包产物上直观的感受一下两者的区别。\nspring-boot-maven-plugin 插件 spring-boot-maven-plugin 是 SpringBoot 默认提供的打包插件，其功能就是将工程打包成一个可执行的 FATJAR。spring-boot-maven-plugin 打包产物的目录结构如下：\n. ├── BOOT-INF │ ├── classes # 应用的字节码目录 │ └── lib # 应用所依赖的 jar 包 ├── META-INF │ ├── MANIFEST.MF # manifest 文件信息 │ └── maven # 应用的坐标信息 └── org └── springframework └── boot └── loader # 存放的是 Spring Boot Loader 的 class 文件 ├── JarLauncher.class # Spring Boot 启动类 ├── archive ├── data ├── jar └── util MANIFEST.MF 文件内容：\nManifest-Version: 1.0 Archiver-Version: Plexus Archiver Built-By: rrz Start-Class: pers.masteryourself.tutorial.sofa.ark.maven.plugin.MavenP luginApplication Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Spring-Boot-Version: 2.1.4.RELEASE Created-By: Apache Maven 3.5.3 Build-Jdk: 1.8.0_101 Main-Class: org.springframework.boot.loader.JarLauncher MANIFEST.MF 文件中可以看到，描述了当前 jar 的一些核心元素，包括启动类、class 文件路径、lib 依赖路径、jdk 版本等等，这里需要关注的是 Main-Class，SpringBoot 就是通过该类来引导启动的。SOFAArk 应用也提供了类似的引导类及其自身特殊的结构， …","date":1584612000,"description":"本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构","dir":"blog/sofa-ark-maven- packaging-plugins/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dd530d14f20a460c2f49300c0d784c32","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","publishdate":"2020-03-19T18:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAArk","SOFAArkLab"],"title":"蚂蚁金服轻量级类隔离框架 Maven 打包插件解析 | SOFAArk 源码解析","type":"blog","url":"/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/","wordcount":3304},{"author":"卫恒","categories":"SOFATracer","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n Disruptor 简介 Disruptor 旨在在异步事件处理体系结构中提供低延迟，高吞吐量的工作队列。它确保任何数据仅由一个线程拥有以进行写访问，因此与其他结构相比，减少了写争用。目前，包括 Apache Storm、Camel、Log4j 2 在内的很多知名项目都应用了 Disruptor 以获取高性能。\nSOFATracer 也是基于 Disruptor 高性能无锁循环队列来提供异步打印日志到本地磁盘能力的，SOFATracer 提供两种类似的日志打印类型即摘要日志和统计日志，摘要日志：每一次调用均会落地磁盘的日志；统计日志：每隔一定时间间隔进行统计输出的日志；无论是哪种日志的输出，对于 SOFATracer 来说都需要保证较高的性能，以降低对于业务整体流程耗时的影响。\n关于 Disruptor 的 一些原理分析可以参考：Disruptor 。\n A High Performance Inter-Thread Messaging Library 高性能的线程间消息传递库\n 案例 先通过 Disruptor 的一个小例子来有个直观的认识；先看下它的构造函数：\npublic Disruptor( final EventFactory\u0026amp;lt;T\u0026amp;gt; eventFactory, final int ringBufferSize, final ThreadFactory threadFactory, final ProducerType producerType, final WaitStrategy waitStrategy) { this( RingBuffer.create(producerType, eventFactory, ringBufferSize, waitStrategy), new BasicExecutor(threadFactory)); } eventFactory : 在环形缓冲区中创建事件的 factory； ringBufferSize:环形缓冲区的大小，必须是2的幂； threadFactory：用于为处理器创建线程； producerType：生成器类型以支持使用正确的sequencer和publisher创建RingBuffer；枚举类型，SINGLE、MULTI两个项。对应于 SingleProducerSequencer和MultiProducerSequencer两种Sequencer； waitStrategy : 等待策略； 如果我们想构造一个 disruptor，那么我们就需要上面的这些组件。从 eventFactory 来看，还需要一个具体的 Event 来作为消息事件的载体。【下面按照官方给的案例进行简单的修改作为示例】\n消息事件 LongEvent ，能够被消费的数据载体 public class LongEvent { private long value; public void set(long value) { this.value = value; } public long getValue() { return value; } } 创建消息事件的 factory public class LongEventFactory implements EventFactory\u0026amp;lt;LongEvent\u0026amp;gt; { @Override public LongEvent newInstance() { return new LongEvent(); } } ConsumerThreadFactory public class ConsumerThreadFactory implements ThreadFactory { private final AtomicInteger index = new AtomicInteger(1); @Override public Thread newThread(Runnable r) { return new Thread(r, \u0026amp;quot;disruptor-thread-\u0026amp;quot; + index.getAndIncrement()); } } OK ，上面的这些可以满足创建一个 disruptor 了：\nprivate int ringBufferCapacity = 8; //消息事件生产Factory LongEventFactory longEventFactory = new LongEventFactory(); //执行事件处理器线程Factory ConsumerThreadFactory consumerThreadFactory = new ConsumerThreadFactory(); //用于环形缓冲区的等待策略。 WaitStrategy waitStrategy = new BlockingWaitStrategy(); //构建disruptor Disruptor\u0026amp;lt;LongEvent\u0026amp;gt; disruptor = new Disruptor\u0026amp;lt;\u0026amp;gt;( longEventFactory, ringBufferCapacity, longEventThreadFactory, ProducerType.SINGLE, waitStrategy); 现在是已经有了 disruptor 了，然后通过：start 来启动：\n//启动 disruptor disruptor.start(); 到这里，已经构建了一个disruptor；但是目前怎么使用它来发布消息和消费消息呢？\n发布消息 下面在 for 循环中 发布 5 条数据：\nRingBuffer\u0026amp;lt;LongEvent\u0026amp;gt; ringBuffer = disruptor.getRingBuffer(); for (long l = 0; l \u0026amp;lt; 5; l++) { long sequence = ringBuffer.next(); LongEvent event = ringBuffer.get(sequence); event.set(100+l); System.out.println(\u0026amp;quot;publish event :\u0026amp;quot; + l); ringBuffer.publish(sequence); Thread.sleep(1000); } 消息已经发布，下面需要设定当前 disruptor 的消费处理 …","date":1584439200,"description":"本文将对 SOFATracer 中使用 Disruptor 来进行日志输出的代码进行了具体的分析。","dir":"blog/sofa-trcaer-disruptor-practice/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a97d804a20a7af180c889c55210ab2fa","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","publishdate":"2020-03-17T18:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFATracer"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 中 Disruptor 实践（含源码）","type":"blog","url":"/sofastack.tech/blog/sofa-trcaer-disruptor-practice/","wordcount":5441},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析\n 活动时间：3 月 26 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 作为云原生网络代理，Service Mesh 是 MOSN 的重要应用场景。随着 Service Mesh 概念的日益推广，大家对这套体系都已经不再陌生，有了较为深入的认知。但是与理论传播相对应的是，生产级别的大规模落地实践案例却并不多见。这其中有多方面的原因，包括社区方案饱受诟病的“大规模场景性能问题”、“配套的运维监控基础设施演进速度跟不上”、“存量服务化体系的兼容方案”等等。\n现实场景中，大部分国内厂商都有一套自研 RPC 的服务化体系，属于「存量服务化体系的兼容方案」中的协议适配问题。为此，MOSN 设计了一套多协议框架，用于降低自研体系的协议适配及接入成本，加速 Service Mesh 的落地普及。本次演讲将向大家介绍 MOSN 实现多协议低成本接入的设计思路，以及相应的快速接入实践案例。\n本期为 SOFAChannel 线上直播第 13 期，将邀请蚂蚁金服技术专家\u0026amp;amp; MOSN Committer 无钩分享《云原生网络代理 MOSN 的多协议机制解析》。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：21992058（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1131\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 无钩 蚂蚁金服技术专家 MOSN Committer\n本期分享大纲 一个请求的 MOSN 之旅 如何在 MOSN 中接入新的协议 SOFABolt 协议接入实践 未来发展：统一路由框架 嘉宾 SOFAGirl 主持人 无钩 蚂蚁金服技术专家 MOSN Committer ","date":1584349200,"description":"3 月 26 日周四晚 7 点，线上直播第 13 期。","dir":"activities/sofa-channel-13/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ba88bba5176867c90fb18dc045408d84","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-13/","publishdate":"2020-03-16T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-13/","summary":"概要 活动主题：SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析 活动时间：3 月 26 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介","tags":["SOFAChannel","MOSN"],"title":"SOFAChannel#13：云原生网络代理 MOSN 的多协议机制解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-13/","wordcount":692},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@胡秋林 提问：\n 请教一个问题，服务拆分然后使用分布式事务，会不会事务链路过长，然后整体性能下降很大呢？\n A：用了分布式事务性能肯定会下降，这是大家对一致性和性能的取舍。在性能对比这块我建议大家去和同类的分布式事务框架对比，而不是只和不用分布式事务去对比。分布式事务很大一部分是处理的系统异常时的一致性，如果针对系统异常这个点，大家如果相信自己的框架 100% 正常的，不会出现超时，网络和宕机等问题，那可以不使用分布式事务，所以保证一致性的很多场景是极端情况下的一致性，在同类框架的对比中，一定是看框架一致性场景的覆盖，如果场景覆盖不全的基础上和我们对比性能我觉得这个没太大意义。这就好比我系统有 1% 几率出现极端情况，我不用 Seata 和使用 Seata 的对比是一样的。\n2、@吴攀 提问：\n 麻烦问下，我现在做的一个销售订单的流程。需要监听审批的状态变化，然后状态机才往下进行流转。Saga 能否满足呢？  A：目前是不支持的，因为 Saga 的状态机定位是服务编排的事务处理，不应该包含人工审批动作，建议做成两个流程，包含人工审批动作，中间状态时间会很长。\n 我来状态想能否把“状态”配置成“IsAsync = true”来实现，然后异步任务来监听审批状态的变化。感觉有些负责。所以来咨询下？有没有更好其他的推荐的方案呢？Netflix Conductor 能满足这个场景么？我现在的场景是：一个销售单出库的流程。销售单建立成功后，要经过审批流程进行审批，然后进入仓库进行库存分配。分配成功后，进行分拣，然后进行打包。最后进行出库。老板想把这些状态流转编制成一个 Saga 支持的状态机。\n A：isAsync 是这个服务异步调用，应该解决不了你这个问题。我的建议是把这个流程差分一下，拆分成两个，或者，销售订单不要纳入状态机，只是插入一条记录，审批通过后，把后面的流程配置成状态机，而且我理解你们这流程是每一步都是人工做完，然后在系统里点一下，然后继续，如果是这样，这不是服务编排的需求，为是工作流的需求。\nSeata：https://github.com/seata/seata\n3、@兴元 提问：\n SOFABoot 版本 v3.3.0，目前官网文档里只有整合 Nacos 0.6.0 版本的，请问怎么使用 Nacos 的命名空间功能？SOFABoot 版本 v3.3.0，maven 引用里 nacos-client 版本是 1.0.0，请问现在支持 nacos 最新版本是多少。\n A：Nacos 配置格式参考：https://www.sofastack.tech/projects/sofa-rpc/registry-nacos/ 对于 namespace 的，可以配置成这样即可：namespace nacos://yyy:8848/namespaceNacos 客户端应该是兼容的，你可以直接升级这个包的版本。\n 命名空间问题解决了，感谢。因为我使用的时候指定了 nacos client 版本为0.6.0，升级到 0.8.0 以上nacos://yyy:8848/namespace 这种形式是可以的，而且只能使用 nacos://yyy:8848/namespace 这种形式，nacos://yyy:8848 是不行的。还望官方文档可以及时更新一下。\n A：这里应该是要配置成：nacos://yyy:8848/ 后面有个/。好的，最近我们升级一下 Nacos 的 client 版本。文档我们同步修改下。\n 刚试了nacos://yyy:8848/，服务依然无法发布到默认命名空间。Nacos server 是1.2.0，客户端是使用SOFABoot v3.3.0。\n A：不会发到默认的，这个会发到的是 SOFARPC 这个 Namespace：private static final String DEFAULT_NAMESPACE = \u0026amp;quot;sofa-rpc\u0026amp;quot;;\nSOFARPC：https://github.com/sofastack/sofa-rpc\n期待见到，每一个精彩的你 蚂蚁金服云原生团队实习生招聘开始啦 【岗位继续增了】蚂蚁金服云原生团队招聘~欢迎加入我们 SOFAChannel 直播回顾 SOFAChannel#12：蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFABoot v3.3.1 版本，主要变更如下：\n 升级 Spring Boot 至 2.1.13.RELEASE； 修复 Tomcat AJP 漏洞； …","date":1584086400,"description":"【03/09-03/13】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200313/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cd22bd67fe25923bca65eae188627da8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200313/","publishdate":"2020-03-13T16:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200313/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 3/26 直播预告、多个组件发布、云原生团队校招社招信息汇总","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200313/","wordcount":2967},{"author":"仁空","categories":"SOFA Weekly","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#12 直播分享整理，主题：蚂蚁金服分布式事务实践解析。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。\n 大家好，我是今天分享的讲师仁空，目前是蚂蚁金服分布式事务产品的研发。今天跟大家分享的是蚂蚁金服分布式事务实践解析，也就是分布式事务 Seata 在蚂蚁金服内部的实践。\n今天我们将从以下 4 个主题进行详细介绍：\n 为什么会有分布式事务产品的需求； 理论界针对这个需求提出的一些理论和解决方案； 蚂蚁金服在工程上是如何解决这个问题的； 针对蚂蚁金服业务场景的性能优化； 分布式事务产生背景 首先是分布式事务产生的背景。\n支付宝支付产品在 2003 年上线的时候，那时候的软件形态是单体应用，在一个应用内完成所有的业务逻辑操作。随着软件的工业化，场景越来越复杂，软件也越做越大，所有的业务在一个应用内去完成变的不可能，出现了软件模块化、服务化。\n在从单体应用升级到分布式架构过程中，很自然得需要进行业务服务拆分，将原来糅在一个系统中的业务进行梳理，拆分出能独立成体系的各个子系统，例如交易系统、支付系统、账务系统等，这个过程就是服务化。业务服务拆分之后，原来一个服务就能完成的业务操作现在需要跨多个服务进行了。\n另一个就是数据库拆分，分库分表。原来的单体数据库存不下的这么多信息，按服务维度拆库，比如把用户相关的存一起，形成用户库，订单放一块形成订单库，这个是拆库的过程；另一个是拆表，用户信息按照用户 ID 散列到不同的 DB 中，水平拆分，数据库的容量增大了。这样分库分表之后，写操作就会跨多个数据库了。\n分布式事务理论基础 我们可以看到，在分布式架构中，跨数据库、跨服务的问题是天然存在的。一个业务操作的完成，需要经过多个服务配合完成，这些服务操作的数据可能在一个机房中，也可能跨机房存在，如果中间某一个服务因为网络或机房硬件的问题发生了抖动，怎么保证这笔业务最终的状态是正确的，比如支付场景，怎么防止我转钱给你的过程中，我的钱扣了，而对方的账户并没有收到钱。这个就是业务最终一致性的问题，是分布式事务需要解决的问题。\n2PC 协议 针对这个问题，理论界也提出了解决方案，其中最为人熟知的就是二阶段协议了，简称2PC（Two Phase Commitment Protocol）两阶段提交协议。\n两阶段提交协议，就是把整个过程分成了两个阶段，这其中，它把参与整个过程的实体分成了两类角色，一个叫事务管理器或事务协调者，一个叫资源管理器，事务管理器我们也把它叫做事务发起方，资源管理器称为事务参与者。\n两个阶段，第一个阶段是资源准备阶段，比如我要转账，我要先查询下我的余额够不够，够的话我就把余额资源预留起来，然后告诉发起方“我准备好了”，第二个阶段，事务发起方根据各个参与者的反馈，决定事务的二阶段操作是提交还是取消。\nTCC 协议 另一个协议是 TCC 协议，各个参与者需要实现3个操作：Try、Confirm 和 Cancel，3个操作对应2个阶段，Try 方法是一阶段的资源检测和预留阶段，Confirm 和 Cancel 对应二阶段的提交和回滚。\n图中，事务开启的时候，由发起方去触发一阶段的方法，然后根据各个参与者的返回状态，决定二阶段是调 Confirm 还是 Cancel 方法。\n蚂蚁金服分布式事务介绍 2019年，蚂蚁金服跟阿里巴巴共同开源了分布式事务 Seata ，目前 Seata 已经有 TCC、AT、Saga 模式，Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。今天的分享也是 Seata 在蚂蚁金服内部的实践。\n分布式事务在蚂蚁金服的发展 基于上述的理论，接下来我们详细看下蚂蚁金服的分布式事务实现。\n经过多年的发展，蚂蚁金服内部针对不同的场景发展了几种不同的模式，最早的是 TCC 模式，也就是上面讲的 Try - confirm - Cancel，我们定义接口规范，业务自己实现这3个操作。这个模式提供了更多的灵活性，因为是业务自己实现的，用户可以介入两阶段提交过程，以达到特殊场景下的自定义优化及特殊功能的实现，这个模式能几乎满足任何我们想到的事务场景，比如自定义补偿型事务、自定义资源预留型事务、消息事务等场景。TCC 模式广泛用于蚂蚁金服内部各金融核心系统。\n这里要强调一点的是，TCC 模式与底层数据库事务实现无关，是一个抽象的基于 Service 层的概念，也就是说，在 TCC 的范围内，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，或者列式存储数据库 HBase，只要将对它们的操作包装成 TCC 的参与者，就可以接入到 TCC 事务范围内。\nTCC 模式的好处是灵活性，弊端是牺牲了易用性，接入难度比较大，所有参与者需要进行改造提供 Try - Confirm - Cancel 三个方法。为了解决 TCC 模式的易用性问题，蚂蚁金服分布式事务推出了框架管理事务模式（Framework - Managed Transactions，简称 FMT），也就是 Seata 中的 AT 模式。FMT 模式解决分布式事务的易用性问题，最大的特点是易于使用、快速接入、对业务代码无侵入。\nXA 模式是依赖于底层数据库实现的。\nSaga 模式是基于冲正模型实现的一个事务模式，现在的银行业金融机构普遍用的是冲正模型。\n这期我们重点讲 TCC 和 FMT，关于 Saga 模式，之前 Saga 模式也有专场直播分享过，感兴趣的可以看一下之前的直播回顾：《Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾》。\nTCC 模式在蚂蚁金服内的使用 首先看下 TCC 模式，主要包含一下几个模块：\n 参与者，它要实现全部的三个方法，Try、Confirm 和 Cancel； 发起方，主要是作为协调者的角色，编排各个参与者，比如调用参与者的一阶段方法，决策二阶段是执行提交还是回滚； 举个例子，比如在这个流程图中，存在一个发起方和两个参与者，两个参与者分别实现了 Try、Confirm 和 Cancel 接口，第一阶段被包含在发起方的本地事务模版中（图中黄颜色的两条虚线就是发起方本地事务的范围），也就是说发起方负责调用各个参与者的一阶段方法，发起方的本地事务结束后，开始执行二阶段操作，二阶段结束则整个分布式事务结束。\n二阶段是通过 Spring 提供的事务同步器实现的，发起方在发起一个分布式事务的时候，会注册一个事务同步器，当发起方本地事务结束的时候，会进入事务同步器的回调方法中。如果发起方的本地事务失败，则在回调中自动回滚所有参与者。如果发起方的本地事务成功，则二阶段自动提交所有参与者。二阶段结束后，删除所有事务记录。\n总结一下：\n 事务发起方是分布式事务的协调者； 分布式事务必须在本地事务模板中进行，发起方本地事务的最终状态（提交或回滚）决定整个分布式事务的最终状态； 发起方主职责：开启一个分布式事务 + 调用参 …","date":1584016200,"description":"分布式事务 TCC、FMT 模式在蚂蚁金服内部的实践分享。","dir":"blog/sofa-channel-12-retrospect/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1aaf09602548f4204f00c7b02260e180","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-12-retrospect/","publishdate":"2020-03-12T20:30:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-channel-12-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#12 直播分享整理，主题：蚂蚁金服分布式事务实践解析。 回顾视频以及 PPT 查看地址见文末","tags":["SOFAChannel","分布式事务"],"title":"蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-12-retrospect/","wordcount":6522},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@水木今山 提问：\n 请问下 SOFAJRaft 能否在日志复制到大多数后就响应客户端？我看 rhea 和 counter 的例子好像都是应用到状态机后才通过 closure 响应客户端。\n A：SOFAJRaft 没有限制，可以在自己的 statemachine 里不直接返回客户端再应用， rheakv 不能。举个例子， compareAndSet 操作，需要先读取再设置，最后返回 client，那么怎么能做到不应用状态机就返回呢，对吧？\n 有道理，但直接返回客户端的逻辑只能在 StateMachine 提供的 onApply 方法里实现吗，因为 onApply 的调用应该会滞后许久吧？\n A：onApply 里面实现就可以，onApply 就可以理解为和达成多数派之间没有延迟。\n 我在文档中有看到 TaskClosure 这么一个接口，在它的 onCommitted 方法里响应客户端会不会更高效？据我所知，raft 仅需写入日志就可保证强一致性，可以异步去 apply，所以在复制日志给大多数后就通过 onCommitted方法响应客户端（尽管还没有任何一个节点 apply 了该日志），这样效率好像会高一点，不知道我对这个接口理解有没有误。\n A：com.alipay.sofa.jraft.core.FSMCallerImpl#doCommitted\n可以看看这个方法，里面会在调用状态机之前调用 TaskClosure，想用 TaskClosure 也可以，不过两者没什么延迟区别。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@匿名 提问：\n MOSN 支持 Istio 的什么版本？什么时候可以在 Istio 中可用？\n A：目前 MOSN 可基于 Istio 1.1.4 跑通 bookinfo example，由于最新版本的 Istio 对 XDS 协议进行了升级以及部分能力增强，MOSN 当前正在适配中，预计 2020 年 10 月份会完整支持高版本 Istio 的 HTTP 系能力；同时我们一直在关注 UDPA 的发展，也在尝试参与到标准的制定中。控制平面方面，我们和社区一直保持紧密沟通与合作，大力发展控制平面，MOSN 也将与控制平面共同前进。\nMOSN：https://github.com/mosn/mosn\n3、@孙俊 提问：\n 请问下，全局事务开启后，全局事务锁未释放时，此时又来个操作同一个数据的本地请求，这个请求没有开启全局事务，是可以修改这个数据的呀。\n A：全局事务的分支事务结束后，不在全局事务的本地数据请求可修改数据。\n 那这样，全局事务的其他分支出现异常，分支事务回滚，从undo里读，发现数据已经被修改了，就得人工处理了？\n A：是，从业务设计上来说如果使用 AT 模式要把数据修改都交给 AT 来管理来避免这类问题。 Seata：https://github.com/seata/seata\n剖析 SOFARegistry 系列 服务注册中心数据一致性方案分析 | SOFARegistry 解析 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 1、发布 SOFARegistry v5.4.0 版本，主要变更如下：\n SessionServer 与 DataServer 通讯性能优化； jraft 从 1.2.5 更新到 1.2.7.beta1； 解决 MethodHandle 在某些 jdk 版本存在内存泄露的 bug； Bug Fix； 详细发布报告：https://github.com/sofastack/sofa-registry/releases/tag/v5.4.0\n2、发布 SOFAArk v1.1.1 版本，主要变更如下：\n 优化biz 卸载，清理临时文件； 支持 biz 打包 指定 bizName -D 参数； 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.1.1\n社区直播预告 SOFAChannel#12 线上直播将邀请蚂蚁金服分布式事务核心开发仁空分享介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1583481600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200306/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"762ff425feef89f406716a6c0c4fff9d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200306/","publishdate":"2020-03-06T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200306/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFARegistry 发版以及源码系列合辑、SOFAArk 发版、3/12直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200306/","wordcount":1922},{"author":"SOFA 团队","categories":"云原生","content":" 2月19日-2月26日，蚂蚁金服开展了“共战‘疫情’，技术破局”数字课堂线上直播，邀请资深专家从“云原生”、“研发效能”、“数据库”三方面分享蚂蚁金服的实践经验并在线答疑，解析 PaaS 在金融场景的落地建设实践，解析支付宝移动端弹性动态架构，分享 OceanBase 2.2版本的特性和实践。\n 本文根据 蚂蚁金服 SOFAStack 产品专家俞仁杰，在蚂蚁金服数字课堂直播间分享的云原生应用 PaaS 平台的建设实践内容整理，以下为演讲整理全文：\n大家好，欢迎来到蚂蚁金服数字课堂直播间。今年 2 月，SOFAStack 金融分布式架构产品已经在阿里云上完成了商业化发布，为了让更多朋友了解到我们的产品的能力、定位以及背后的设计思路，后续我们会有一系列的直播分享。我们今天想分享给大家的话题叫《云原生应用 PaaS 平台的建设实践》，主要会围绕 PaaS 产品能力在一些需要稳妥创新的金融场景下的落地思路，并且能够更好地与云原生架构做好链接。\n金融场景云原生落地面临挑战 云原生是业务快速变化背景下的必然技术趋势 回顾 IT 的发展史，云计算分类为 IaaS PaaS 和 SaaS 已经有十几年了。而事实上，整个云计算行业的发展，我们能够明显看到企业在落地云计算战略的时候经历的三个阶段，Cloud-Based, Cloud-Ready, Cloud-Native。这三个阶段其实是因为业务的变化越来越敏捷，要求企业关注重心上移，把更多的精力和人才投入到业务逻辑的建设上，而把下层自已并不擅长并且越来越复杂的基础设施、中间件逐渐交给云计算厂商去实现，专业的人做专业的事。\n这本质是社会分工的进一步细化，也符合人类社会发展的规律。在云原生时代，业界所提出的容器技术，Service Mesh 技术，Serverless 技术都是希望让业务研发与基础技术更加的解耦，让业务创新和基础技术创新都更容易的发生。\n容器技术带来的是一种应用交付模式的变革 云原生就是业务快速变化背景下的必然技术趋势。而这个趋势背后的实质载体，就是我们所说的云原生、Kubernetes 以及以 Docker 为代表的容器技术，这些所带来的，本质是一种应用交付模式的变革。而为了真正能够使业界、社区所倡导的新兴应用交付模式落地到实际的企业环境，我们需要一个以应用为中心的平台来进行承载，贯穿应用运维的各项生命周期。\n围绕“云原生”这个关键词，其实在社区和业界已经有了非常多的交流和资料，围绕Docker/K8S 的最佳实践、DevOps CICD、容器网络存储设计、日志监控对接优化等等等等，而我们今天的分享，主要想表达的是我们围绕在 K8S 之上塑造一个 PaaS 平台的产品价值主张。Kubernetes 是一个非常好的编排和调度框架，它核心的贡献是让应用的编排和资源的调度更加的标准化，同时提供了一个高度可扩展的架构，方便上层进行各种控制器和调度器的定制。但是，它并不是一个 PaaS。PaaS 底层可以基于 Kubernetes 去实现，但是在上层要补足非常多的能力才能真正把 Kubernetes 用于生产环境，特别是金融行业的生产环境。\n金融场景需要“稳妥创新” 生产环境落地云原生需要着重考虑哪些挑战？\n我们之前做过一些调研和客户访谈。就现在 2020 年来说，绝大多数金融机构都展现出了对 Kubernetes、容器等技术的极大兴趣，有不少机构也已经在一些非关键的业务、或开发测试环境搭建了开源或商业版的集群。驱动力很简单，金融机构非常希望这一整套新的交付模式帮助到业务飞速迭代。然而对比落差非常明显的是，真正敢于在核心生产环境落地云原生架构的，又少之又少。因为金融业务创新的前提，是要保障稳妥。\n我们团队在服务蚂蚁内部业务、外部金融机构的过程中，总结了以上这几个方面，事实上这六大方面也是我们内部 SRE 不断挑战的几点。我们在今天以及未来的分享中，会逐步总结深化应对这些挑战的产品思路。\nK8S 体系下的应用变更与发布管控 我们今天分享的一个核心内容，就是我们如何在产品层面做应用变更的风险保障的。并围绕此话题向大家介绍变更“三板斧”的背景、K8S 原生部署能力、我们产品围绕变更需求做的扩展并向大家介绍我们在开源方面的规划。\n需求背景：变更“三板斧” 所谓“三板斧”就是可灰度、可监控、可应急。这是蚂蚁内部运维的一条红线准则，所有的变更，都必须要遵从这个规则，即使再细小的变更，再严密的测试，也不能忽略这条规则。为了满足这个需求，我们在 PaaS 产品层设计了各种各样的精细化发布策略，比如分组发布、beta 发布，灰度发布，蓝绿发布等。这些发布策略跟我们在做传统运维时用的手段是非常相似的，但很多使用容器的用户认为在 K8S 里实现会非常的困难。\n有些时候，由于对业务连续性的极高要求，也很难接受原生 K8S 模型标准化模式，比如原生 Deployment 做灰度或者金丝雀发布时，默认情况下在 Pod 变更和流量治理层面的管控还稍显不足，无法完全做到无损发布或按需过程管控。因此，我们在 PaaS 产品层面做了定制，在 Kubernetes 层面做了自定义资源的扩展，目的是能够在云原生的场景下，依然对整个发布过程实现精细化管控，使得大规模集群发布、灰度、回滚时更加优雅，符合技术风险三板斧原则。 Kubernetes 原生发布能力 我们先来回顾一下 K8S 的原生 Deployment 对象，及其背后的 ReplicaSet，其实已经是在最近好几个大版本中已经逐渐的稳定了。 简单的来说，最常见的 K8S 发布场景，我们会通过 Deployment 的对象，声明出我希望的发布模式以及 Pod Spec 定义。在运行时，会有 ReplicaSet 对象来管理 Pod 数量的预期，默认情况下会提供滚动发布或重建发布能力。\nimage.png\n这幅图的下半部分，是围绕 Deployment 作滚动发布时的示意图，这里不再做过多的展开，它的本质根据用户根据我们的运维需求设定好一定的步长，创建新的 Pod，销毁旧的 Pod，因此能做到整个应用版本的变更和发布过程中，都能有对应的容器对外提供服务。 对大部分场景来说，它是够用的，而且整个过程也是非常好的理解，事实上在 K8S 体系，大家除了 Pod/Node，看的最多的就是 Deployment了。\nCAFEDeployment：感知底层拓扑和领域模型 回顾完 Deployment，我们可以再给大家看一下我们根据实际需求作的 CRD 扩展，CAFEDeployment。CAFE 是我们 SOFAStack PaaS 产品线的名称，本文的最后会作一些介绍。\nCAFEDeployment 有一个很重要的能力，就是能够感知到底层拓扑，这个拓扑是什么意思呢？能够知道我想把我的 Pod 发布到哪里，哪边的 Node，不只是基于亲和性的规则作绑定，而是真正能把高可用、容灾、以及部署策略等场景息息相关的信息，带到整个围绕发布的领域模型中。对此，我们提出了一个叫部署单元的领域模型，他是一个逻辑概念，在 yaml 中简单的叫做 Cell。在实际使用中，Cell 的背后，可以是不同的 AZ 不同的物理机房，不同的机架，一切都是围绕着不同级别的高可 …","date":1583395200,"description":"云原生应用 PaaS 平台的建设实践","dir":"blog/distributed-architecture-and-cloud-native/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6c1ff3975ace44ac5189b1f845a43fcb","permalink":"https://sofastack.github.io/sofastack.tech/blog/distributed-architecture-and-cloud-native/","publishdate":"2020-03-05T16:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/distributed-architecture-and-cloud-native/","summary":"2月19日-2月26日，蚂蚁金服开展了“共战‘疫情’，技术破局”数字课堂线上直播，邀请资深专家从“云原生”、“研发效能”、“数据库”三方面分","tags":["云原生"],"title":"技术破局：如何实现分布式架构与云原生？| 含 ppt 下载","type":"blog","url":"/sofastack.tech/blog/distributed-architecture-and-cloud-native/","wordcount":5553},{"author":"明不二","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第七篇，本篇作者明不二。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 在前面的文章已经做过介绍，与其他注册中心相比，SOFARegistry 主要特点在于支持海量数据、支持海量客户端、秒级的服务上下线通知以及高可用特性。本文将从如下几个方面来讲述 SOFARegistry 的一致性方案：\n MetaServer 数据一致性 为支持高可用特性，对于 MetaServer 来说，存储了 SOFARegistry 的元数据，为了保障 MetaServer 集群的一致性，其采用了 Raft 协议来进行选举和复制。\n SessionServer 数据一致性 为支持海量客户端的连接，SOFARegistry 在客户端与 DataServer 之间添加了一个 SessionServer 层，客户端与 SessionServer 连接，避免了客户端与 DataServer 之间存在大量连接所导致的连接数过多不可控的问题。客户端通过 SessionServer 与 DataServer 连接的时候，Publisher 数据同时会缓存在 SessionServer 中，此时就需要解决 DataServer 与 SessionServer 之间数据一致性的问题。\n DataServer 数据一致性 为支持海量数据，SOFARegistry 采用了一致性 Hash 来分片存储 Publisher 数据，避免了单个服务器存储全量数据时产生的容量瓶颈问题。而在这个模型中，每个数据分片拥有多个副本，当存储注册数的 DataServer 进行扩容、缩容时，MetaServer 会把这个变更通知到 DataServer 和 SessionServer，数据分片会在集群内部进行数据迁移与同步，此时就出现了 DataServer 内部数据的一致性问题。\nMetaServer 数据一致性 MetaServer 在 SOFARegistry 中，承担着集群元数据管理的角色，用来维护集群成员列表，可以认为是 SOFARegistry 注册中心的注册中心。当 SessionServer 和 DataServer 需要知道集群列表，并且需要扩缩容时，MetaServer 将会提供相应的数据。\n图1 MetaServer 内部结构 图源自 《蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析》\n因为 SOFARegistry 集群节点列表数据并不是很多，因此不需要使用数据分片的方式在 MetaServer 中存储。如图 1 所示，集群节点列表存储在 Repository 中，上面通过 Raft 强一致性协议对外提供节点注册、续约、列表查询等 Bolt 请求，从而保障集群获得的数据是强一致性的。\nRaft 协议 关于 Raft 协议算法，具体可以参考 The Raft Consensus Algorithm 中的解释。在 SOFA 体系中，对于 Raft 协议有 SOFAJRaft 实现。下面对 Raft 协议算法的原理进行简要介绍。\nRaft 协议由三个部分组成，领导人选举（Leader Election）、日志复制（Log Replication）、安全性（Safety）。\n 领导人选举 通过一定的算法选举出领导人，用于接受客户端请求，并且把指令追加到日志中。\n图2 Raft 状态机状态转换图 图源自Understanding the Raft consensus algorithm: an academic article summary\n 日志复制 领导人接受到客户端请求之后，把操作追加到日志中，同时与其他追随者同步消息，最终 Commit 日志，并且把结果返回给客户端。\n图3 复制状态机 图源自 Raft一致性算法笔记\n 安全性 安全性保证了数据的一致性。\n基于 Raft 协议的数据一致性保障 图4 SOFARegistry 中的 Raft 存储过程 图源自 《蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析》\n如图 4 所示，SOFARegistry 中的 Raft 协议数据存储经历了如上的一些流程。客户端发起 Raft 协议调用，进行数据注册、续约、查询等操作时，会通过动态代理实现 ProxyHandler 类进行代理，通过 RaftClient 把数据发送给 RaftServer ，并且通过内部的状态机 Statemachine ，最终实现数据的操作，从而保证了 MetaServer 内部的数据一致性。\nSessionServer 数据一致性 SessionServer 在 SOFARegistry 中，承担着会话管理及连接的功能。同时，Subscriber 需要通过 SessionServer 来订阅 DataServer 的服务数据，Publisher 需要通过 SessionServer 来把服务数据发布到 DataServer 中。\n在这个场景下，SessionServer 作为中间代理层，缓存从 DataServer 中获取的数据成了必然。DataServer 的数据需要通过 SessionServer 推送到 Subscriber 中，触发 SessionServer 推送的场景有两个：一个是 Publisher 到 DataServer 的数据发生变化；另外一个是 Subscriber 有了新增。\n而在实际的场景中，Subscriber 新增的情况更多，在这种场景下，直接把 SessionServer 缓存的数据推送到 Subscriber 中即可，能够大大减轻 SessionServer 从 DataServer 获取数据对 DataServer 的压力。因此，这也进一步确认了在 SessionServer 缓存数据的必要性。\n图5 两种场景的数据推送对比图\nSessionServer 与 DataServer 数据对比机制 当服务 Publisher 上下线或者断连时，相应的数据会通过 SessionServer 注册到 DataServer 中。此时，DataServer 的数据与 SessionServer 会出现短暂的不一致性。为了保障这个数据的一致性，DataServer 与 SessionServer 之间通过 推 和 拉 两种方式实 …","date":1583224200,"description":" 本文为《剖析 | SOFARegistry 框架》第七篇，作者明不二","dir":"blog/sofa-registry-data-consistency/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"356cd2beadad494a22e2d480948fce8d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-data-consistency/","publishdate":"2020-03-03T16:30:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-data-consistency/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心数据一致性方案分析 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-data-consistency/","wordcount":4336},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:BootLab/\u0026amp;gt;是《剖析 | SOFABoot 框架》系列，会逐步详细介绍 SOFABoot 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFABoot SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\nSOFABoot :https://github.com/sofastack/sofa-boot\n| SOFA:Boot Lab 认领列表：\n 【已认领】《SOFABoot 总览》 【已认领】《SOFABoot runtime 机制解析》 【已认领】《SOFABoot HealthCheck 机制解析》 【已认领】《SOFABoot 日志隔离解析》 【已认领】《SOFABoot 上下文隔离机制解析》 领取方式：关注 「金融级分布式架构」 回复可领取的文章标题，我们将会主动联系你，确认资质后，即可加入 SOFA:BootLab/，It\u0026amp;rsquo;s your show time！\n 如果有同学对以上某个主题特别感兴趣的，可以留言讨论，我们会适当根据大家的反馈调整文章的顺序，谢谢大家关注 SOFAStack ，关注 SOFABoot，我们会一直与大家一起成长的。\n除了源码解析，也欢迎提交 issue 和 PR： SOFABoot：https://github.com/sofastack/sofa-boot\n欢迎领取，参与共建~\n","date":1583208000,"description":"","dir":"activities/sofa-boot-lab/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ee08908ed6148190ca7ebcc0cdc5a3fc","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-boot-lab/","publishdate":"2020-03-03T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-boot-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:BootLab/\u0026gt;是《剖析 | SOFABoot 框架》系列，会逐步详细","tags":["SOFALab","SOFABoot","剖析 | SOFABoot 框架"],"title":"\u003cSOFA:BootLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-boot-lab/","wordcount":542},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@朱楠 提问：\n SpringBoot 集成 Seata Saga 模式后启动报了这个错，有谁知道是什么情况吗？不知道问题出在哪，我就参照Saga 的 demo 来配置的。 A：这个事务异常了，然后 server 端出发了事务恢复，但是这条事务在客户端已经没有了。\n @Reference 这个注解没有 id 或者 name 的属性，试了几次还是不行，实在不行我就用配置文件的方式主入 Dubbo 服务了。 A：其实这也合理，因为 @Reference 是作用在一个类的 field 或 method 上面的，而状态机引擎它不是一个 field 或 method，所以状态机引擎不应该用访问这个类的 reference，而是应该访问一个 spring 上下文作用域的 reference 。我看了一下 Dubbo 的源码 @Reference 这种它并不会注册成为一个 bean，只是生成一个代理然后注入到这个引用它的属性里。所以状态机默认是取 bean 的形式拿不到 bean，你用 xml 的方式引用一个服务。状态机的编排本来就不是用 Java 代码上编排的，而 @Reference 是用于编程方式使用的。 Seata：https://github.com/seata/seata\n2、@魏敏 提问：\n 请问一下，关于 tomcat 的 ajp 漏洞，使用的 SOFABoot 是否受影响呢？https://www.cnvd.org.cn/webinfo/show/5415\n A：针对此次 Tomcat 的 AJP 协议漏洞，SOFABoot 内置的 Tomcat 默认是不会打开 AJP Connector 的，也就是说默认情况下所有版本的 SOFABoot 都是安全的。但是如果你自行打开了 AJP Connector，或者认为风险较大，可以通过覆盖 SOFABoot 管控的 Tomcat 版本进行升级，在主 pom 中的 properties section 指定 Tomcat 版本：\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;!-- other properties goes here --\u0026amp;gt; \u0026amp;lt;tomcat.version\u0026amp;gt;9.0.31\u0026amp;lt;/tomcat.version\u0026amp;gt; \u0026amp;lt;!-- Tomcat 升级规则如下： - 9.x 版本升级至 9.0.31 及以上 - 8.x 版本升级至 8.5.51 及以上 - 7.x 版本升级至 7.0.100 及以上 --\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; SOFABoot：https://github.com/sofastack/sofa-boot\n3、@jinn 提问：\n MOSN 与 Envoy 不同点是什么？优势在哪里？\n A：简单描述一下：\n 语言栈的不同：MOSN 使用 Go 语言技能栈对于使用 Java 语言的公司和个人心智成本更低。 核心能力的差异化： MOSN 支持多协议框架，用户可以比较容易的接入私有协议，具有统一的路由框架； 多进程的插件机制，可以通过插件框架很方便的扩展独立 MOSN 进程的插件，做一些其他管理，旁路等的功能模块扩展； 具备中国密码合规的传输层国密算法支持； MOSN：https://github.com/mosn/mosn\nSOFAChannel 线上直播集锦 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理 SOFAChannel#10：Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 SOFAChannel#9：Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 | SOFAChannel#9 回顾 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n发布 MOSN v0.10.0 版本，主要变更如下：\n 分离部分 MOSN 基础库代码到 mosn.io/pkg； 分离部分 MOSN 接口定义到 mosn.io/api； 支持多进程插件模式； 部分代码实现细节优化； Bug Fix； 详细发布报告： https://github.com/mosn/mosn/releases/tag/v0.10.0\n社区直播预告 SOFAChannel#12 线上直播将邀请蚂蚁金服分布式事务核心开发仁空分享介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1582873200,"description":"【02/24-02/28】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200228/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"825d23ac19f5c5ae4cfaca517a9a87fd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200228/","publishdate":"2020-02-28T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200228/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 发布、直播系列整理、0312直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200228/","wordcount":1935},{"author":"SOFA 团队","categories":"SOFAArk","content":" SOFA:Channel/，有趣实用的分布式架构频道。\n本文根据 SOFAChannel#11 直播分享整理，主题：从一个例子开始体验轻量级类隔离容器 SOFAArk。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群：23372465，不错过每场直播。\n 大家好，我是玄北，SOFAArk 开源负责人，今天跟大家分享的主题是《从一个例子开始体验轻量级类隔离容器 SOFAArk》，会跟大家一起解读 SOFAArk ，也会讲解一个 Demo 案例，希望大家可以跟我一起实际操作，体验 SOFAArk 具体操作以及功能实现。\nSOFAArk：https://github.com/sofastack/sofa-ark\n今天的分享将从一下面三个方面展开：\n 初识 SOFAArk； 组件运行时； 动手实践； 今天的重点是最后一个部分的动手实践，前面两部分会跟大家简单介绍一下 SOFAArk 的基础概念，希望在最后一个实践部分，大家可以跟着我一起通过 Demo 实际操作体验 SOFAArk，也可以在实践过程中帮助大家更好得了解前面介绍到的概念。\n一、初识 SOFAArk 现在我们就开始了解 SOFAArk，在实践之前，我们先来了解一下什么是 SOFAArk。SOFAArk 是蚂蚁金服开源的一款基于 Java 实现的轻量级类隔离容器，欢迎大家关注并 Star SOFAArk。\nSOFAArk：https://github.com/sofastack/sofa-ark\n在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案。产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin）； 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz)； 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制； 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz； SOFAArk 可以帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\nSOFAArk 中有三个最主要的概念，分别是 Ark 包、Ark Biz 包、Ark Plugin 包：\nArk 包：类似 Spring Boot 的打包产物，是一个 Fat Jar，即应用交付终态，一个 Ark 包，可以通过 Java-jar 的方式把它运行起来。\nArk Biz 包: 简称 Biz，是组件的交付终态，大家通过名字也可以理解，里面主要封装了一些业务逻辑。\nArk Plugin 包: 简称 Plugin，提供把非业务基础组件下沉的能力，比如 RPC、消息等。\n接下来按照上述三个的顺序，我们来看一下这三个包里主要是什么。\nArk 包目录结构 下图是 Ark 包的目录结构，Ark 包下有 Biz 目录，Container 目录，Plugin 目录，Biz 目录中就是一个一个的 Ark Biz，Plugin 目录保存了所有的 Ark Plugin，Container 是 Ark 容器，Ark 容器会负责启动 Ark Plugin 及 Ark Biz。\nArk Biz 包目录格式 介绍完 Ark 包的目录格式，接下来介绍 Ark Biz 包的格式：\n在 Ark Biz 包的目录格式里同样有几个比较关键的目录格式，分别是：\n application.properties：标准 Spring Boot/SOFABoot 工程配置文件； lib 目录：应用依赖目录； META-INF/MANIFEST：Biz 配置文件。 Ark Plugin 包目录结构 接下来跟大家介绍 Ark Plugin 包，Ark Plugin 包的目录结构与 Ark Biz 包的目录结构类似，但是 Ark Plugin 包的 META-INF/MANIFEST.MF 文件会比 Ark Biz 包复杂一点，Ark Plugin 支持在 META-INF/MANIFEST.MF 文件中定义 Import package、Export package、Import classes 以及 Export classes 等属性，这些属性支持 Plugin ClassLoader 在加载类或者资源文件时可以委托给其他 Plugin 加载。\n上文介绍了 Ark 包、Ark Biz 包、Ark Plugin 包的目录结构，接下来我们介绍下 Ark 包运行时的整个运行时结构。通过下面这张图我们可以看到，在整个运行时，Ark 包分为三层，底层是 Ark Container，中间层是 Ark Plugin，上层是 Ark Biz。Ark Container 负责启动所有 Ark Plugin 及 Ark Biz，Ark Plugin 支持类导入导出能力，所以 Ark Plugin 之间有双向箭头相互委托。为了简化 Ark Biz 的使用，Ark Biz 不支持导入导出类，Ark Biz默认会导入所有 Ark Plugin 的类。\nSOFAArk 的不同 Plugin 相互委托类加载的能力可以帮助我们解决一个文件场景，那就是依赖冲突：\n以上图的场景为例，有一个 Project，依赖了 Dependency A 以及 Dependency B，这两个依赖依赖了不同版本的 Hessian，Dependency A 依赖了 Hessian 3，Dependency B 依赖了 Hessian 4，Hessian 3 与 Hessian 4 是不兼容的，会出现冲突，那么要如何解决这个问题呢？\nSOFAArk 就给出了一个解决方案。如果我们的 Dependency A 跟 Dependency B 的 Hessian 依赖有冲突的话，我们可以把 Dependency A 作为一个整体打包成一个 Ark Plugin， Dependency B 作为一个整体打包成一个 Ark Plugin，每个 Ark plugin 都是一个单独的 Classloader，这样 Dependency A 使用的 Hessian 3 和 Dependency B 使用的 Hessian 4 将不再冲突。\n解决依赖冲突是 SOFAArk 的一个主要使用场景，但是今天我们不详细介绍这个场景，今天主要介绍 SOFAArk 的另一个能力，即组件运行时能力。\n二、组件运行时 组件运行时提供了一种能力，它能够在不重启应用的前提下，通过动态安装、卸载、切换 Biz 模块，实现修改应用运行方式的目的。下图展示了组件运行时的运行时结构，整个运行时结构与上文的 Ark 包运行时结 …","date":1582700400,"description":"本文根据 SOFAChannel#11 直播分享整理。","dir":"blog/sofa-channel-11-retrospect/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a3216377eb47b27325f279f124c2bfd8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-11-retrospect/","publishdate":"2020-02-26T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-channel-11-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#11 直播分享整理，主题：从一个例子开始体验轻量级类隔离容器 SOFAArk。 回顾视","tags":["SOFAArk","SOFAChannel"],"title":"从一个例子开始体验轻量级类隔离容器 SOFAArk | SOFAChannel#11 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-11-retrospect/","wordcount":4342},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@朱楠 提问：\n 请教下，我看文档上有说json可以热部署，有demo吗，没怎么看明白如何热部署 A：就是用这个回答里的这个方法 registerByResource，Java 代码的热部署可以用 SOFAArk，stateMachineEngine 是一个 bean，可以在代码里注入这个 bean，然后你可以实现一个 web 页面，可以上传 json 文件和 jar 包，调用图片中的方法注册状态机，用 SOFAArk 注册 jar 包。\n 我在看 registryByResources 这个方法的源码，注册状态机是不是就不需要修改本地的 json 文件了？\n A：注册了 json，如果数据库里有名称相同的，它会对比字节码，如果不一样，则创建新版本，一样则不注册，新启动的状态机实例用新版本，已启动的状态机实例用老的。\n 懂了，你这里说的上传 jar 包是什么意思？\n A：因为状态机里定义了要调用服务，这个服务可能是目前在系统里没有引用，所以需要上传 jar。\n2、@刘川江 提问：\n Seata Saga 模式服务（ServiceTask）之间如何在运行时传递业务参数？如将服务A运行后的生成的业务对象传递到后续的服务中进行处理。\n A：用 Output 和 Input 属性： Input: 调用服务的输入参数列表, 是一个数组, 对应于服务方法的参数列表, $.表示使用表达式从状态机上下文中取参数，表达使用的 SpringEL, 如果是常量直接写值即可； Ouput: 将服务返回的参数赋值到状态机上下文中, 是一个 map 结构，key 为放入到状态机上文时的 key（状态机上下文也是一个 map），value 中$.是表示 SpringEL 表达式，表示从服务的返回参数中取值，#root 表示服务的整个返回参数。\n 是否支持根据业务参数中的某些值作为条件判断状态机中的服务（ServiceTask）是否执行？\n A: 支持的，可以用 Status 属性来判断 Service 是否执行成功。 Status: 服务执行状态映射，框架定义了三个状态，SU 成功、FA 失败、UN 未知, 我们需要把服务执行的状态映射成这三个状态，帮助框架判断整个事务的一致性，是一个 map 结构，key 是条件表达式，一般是取服务的返回值或抛出的异常进行判断，默认是 SpringEL 表达式判断服务返回参数，带 $Exception{ 开头表示判断异常类型。value 是当这个条件表达式成立时则将服务执行状态映射成这个值。\n 是否支持状态机中的部分服务开启事务。如状态机配置了服务流程A-\u0026amp;gt;B-\u0026amp;gt;C，只在服务B和C上开启分布式事务。\n A：可以，比如 A 是一个查询类的服务，可以将 A 设置成 IsForUpdate=false，如果这个服务不想记录执行日志，可以设置这个服务为 IsPersist=false。\nSeata：https://github.com/seata/seata\n3、@SUNBIAO 提问：\n 请问 SOFA 消费者端可以同时配置多个注册中心嘛？例如一个 web 控制器接入端当作消费者，配置连接多个注册中心，订阅不同注册中心上的生产者服务，但是这个消费者端不同的具体消费者调用不同注册中心的服务，前提是注册中心不能合成一个，现实有多个不同的注册中心。\n A：可以的，可以看这个类 com.alipay.sofa.rpc.config.AbstractInterfaceConfig#registry， 是个 list。\nSOFARPC：https://github.com/sofastack/sofa-rpc\n4、@七美 提问：\n SOFATracer 目前落盘的摘要 log 是固定格式的，能否直接以 zipkin 的 json 数据格式落盘？如果可以如何操作？\n A：使用自定义 reporter ： https://www.sofastack.tech/projects/sofa-tracer/reporter-custom/ + ZipkinV2SpanAdapter 来实现。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n每周读者问答提炼 蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 SOFA 项目进展 本周发布详情如下：\n1、发布 Seata v1.1.0 版本，主要变更如下：\n 支持 postgreSQL； 支持自定义 Saga 恢复策略超时时间； 支持 Saga 模式跳过成功分支事务的 report； 支持httpClient 自动集成； 详情发布报告：https://seata.io/zh-cn/blog/download.html\n2、发布 SOFARPC v5.6.4 版本，主要变更如下：\n 试验性支持 RPC 可能的多版本发布； 升级 Dubbo 依赖版本到2.6.7； 优化 gRPC 支持代码； 升级 Netty 版本4.1.44.final，解决安全问题； 修复 Tracer 采样兼容问题； 修复注册中心虚拟端口的问题； 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.4\n3、发布 SOFABoot v3.3.0 版本，主要变更如下：\n 健康检查页面显示组件的具体绑定类型； RPC XML 超时配置支持字符串变量； 修复无法使用 zk 以外注册中心的 bug； 修复控制台大量输出的 bug； 升级 Spring Boot 依赖版本至 2.1.11.RELEASE； 升级 RPC 版本至 5.6.4； 升级 sofa-common-tools 版本至 1.0.21； 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.3.0\n4、发布 sofa-common-tools v1.0.21 版本，主要变更如下：\n 修复类隔离情况下 classloader 加载问题； 详 …","date":1582268400,"description":"【02/17-02/23】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200221/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b82b9b4c82bc3905d736962bd157238c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200221/","publishdate":"2020-02-21T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200221/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 3/12直播预告、SOFARPC、SOFABoot 组件发布","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200221/","wordcount":2625},{"author":"盲僧","categories":"SOFABoot","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFABoot 框架》第二篇，本篇作者盲僧，来自遨游酒店信息技术。《剖析 | SOFABoot 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:BootLab/]()，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFABoot 是蚂蚁金服开源的基于 SpringBoot 的研发框架，提供了诸如 Readiness Check、类隔离、日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\n本文将从 Java 的日志体系谈起，对 JCL、SLF4J 两个经典的日志框架做一个阐述，引出 SOFABoot 开源的日志隔离框架 sofa-common-tools ，并且有实战 Demo，能够帮助我们快速上手和了解这款框架的使用和作用，最后从源码角度对其进行分析，不仅知其然，还要知其所以然。\nSOFABoot ：https://github.com/sofastack/sofa-boot\nsofa-common-tools ：https://github.com/sofastack/sofa-common-tools\nJava 日志问题 业务开发对日志的选择 众所周知，Java 的日志体系非常复杂，有 Log4j、Log4j2、Logback、JUL 等实现，这么多的日志实现让开发人员在选择上不得不犯晕，因为每个日志实现都对外提供了不同的 API，而且还要担心与项目中现有的第三方框架依赖的日志实现产生冲突问题，甚至还要去维护第三方框架带来的日志依赖。在这些问题的基础上，Java 日志框架应运而生，典型的有 JCL 和 SLF4J。\nJCL JCL 即 Apache Commons Logging，它的原理是提供了一套接口，用户使用了它的接口进行编程，具体实现交由它的 LogFactoryImpl 去动态查找， 但是它并不能绑定所有的日志实现，因为查找绑定的日志实现是放在 classesToDiscover 数组里写死的，导致扩展起来比较麻烦，当前最新版本是 1.2 版本，还不支持绑定 Log4j2 和 Logback。\nSLF4J 于是乎，大名鼎鼎的 SLF4J 出现了，它的存在就是为了替换 JCL，所以肯定提供了比 JCL 更强大的功能。同样是面向接口编程的设计，但是 SLF4J 充分考虑到了后期的扩展问题：一旦市面上有新的日志实现，那么只需要提供新的绑定包即可，相对于 JCL 的动态绑定，SLF4J 实际上是静态绑定，因为应用程序具体要选用哪种日志组件是由开发人员使用哪个绑定包决定的。绑定原理请看下图：\n除此之外，SLF4J 还提供了桥接包，它的意思是指可以把使用某个具体 Log 组件的 API 重定向到 SLF4J 的 API 里（前提需要排除具体实现包，然后引入桥接包），然后 SLF4J 会根据具体的绑定包输出内容，从而达到多种日志实现统一输出的目的。绑定原理请看下图：\n中间件对日志的选择 上面解决了业务开发人员的问题，那么对于从事中间件的开发者来说呢？日志依旧是一个痛点。参考一些中间件项目，如 zookeeper 使用的是 log4j ，hibernate-validator 使用的是 jboss-logging，当业务开发人员去集成这些第三方组件时，就会感到头疼，因为这些组件的日志实现很有可能会和当前业务自身的日志依赖产生冲突。常用的解决方法就是排除某一种日志实现依赖，然后修改 appender 和 logger 达到日志隔离。但这并不是一个一劳永逸的方法，因为每次引入新的 jar 包，你都需要考虑是否有日志冲突。\n那么市面上是否有成熟的框架来解决这个问题呢？当然是有的，蚂蚁金服开源的 SOFABoot 就提供了这样的功能，底层主要是通过 sofa-common-tools 实现的。那么 sofa-common-tools 又是个啥呢？借用官网的描述： sofa-common-tools 是 SOFAStack 中间件依赖的一个通用工具包，通过自动感知应用的日志实现，提供中间件与应用隔离的日志空间打印能力。\n本篇将通过一个案例 demo 先来直观的体验下 sofa-common-tools 所能解决的问题，然后再在此基础上，通过源码解析了解其内部的具体实现原理，以帮助大家更好的认识和了解 sofa-common-tools 这个“小而美”的日志工具包。\n日志隔离实战 完整项目已经上传到 https://github.com/masteryourself/study-sofa.git ，工程是 study-sofa-common-tools\n 有这样一个场景：公司的中间件团队做了一款 middleware-apm 监控系统，并且通过以输出日志的方式向监控系统提供基础数据。由于公司并没有制定统一的日志规范，各个业务方所使用的日志也是千差万别；如：如订单系统使用的是 log4j，账务系统用的 Logback，用户中心用的是 Log4j2； 如果期望 apm 提供的日志输出和业务的不冲突，可以独立的并且完整的兼容业务日志的不同实现，此时便可以使用 SOFABoot 提供的日志隔离框架；其可以帮助我们解决日志实现冲突、日志文件隔离以及动态调试日志级别等功能。下面就先来看下 apm 是如何使用 sofa-commons-tools 来实现的。\nmiddleware-apm 项目 新建 middleware-apm 工程，然后执行 mvn clean install 命令，安装到本地仓库。具体代码可以参考 middleware-apm ，下面对一些核心代码进行简单的说明和分析。代码结构如下：\n日志资源文件配置 这里主要是在 pers.masteryourself.study.sofa.apm.log 目录下创建 log4j、log4j2、logback 的配置文件，详情请参考 github 链接。\n核心日志工厂类-ApmLoggerFactory ApmLoggerFactory 主要是对外提供获取 Logger 实例的 API 方法，其作用类似于 slf4j 中的 LoggerFactory 类；对于想使用 SOFABoot 日志特性的类，只要使用它调用 getLogger 方法获得的 Logger 实例即可。\nLoggerFactory 和 ApmLoggerFactory 的最本质区别在于 ApmLoggerFactory 引入了 LOG_SPACE 的概念。\npublic class ApmLoggerFactory { // 日志空间 private static final String APM_LOG_SPACE = \u0026amp;quot;pers.masteryourself.study.sofa.apm\u0026amp;quot;; static { if …","date":1582016400,"description":"本文将从 Java 的日志体系谈起，对 JCL、SLF4J 两个经典的日志框架做一个阐述，引出 SOFABoot 开源的日志隔离框架 sofa-common-tools，并且有实战 Demo，能够帮助我们快速上手和了解这款框架的使用和作用，最后从源码角度对其进行分析，不仅知其然，还要知其所以然。","dir":"blog/sofa-boot- log-isolation/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a428e36a94180c1e33920579423b4402","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-log-isolation/","publishdate":"2020-02-18T17:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-boot-log-isolation/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFABoot","剖析 | SOFABoot 框架","SOFALab"],"title":"蚂蚁金服研发框架日志隔离解析 | SOFABoot 框架剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-log-isolation/","wordcount":4632},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@乘疯破浪 提问：\n 咨询一个性能问题，一个 2C 的业务场景：本地库操作多次 db，再调用分布式服务，再 TC 端注册多个分支事务耗时较多，用户 C 端等待时间较长，这种问题有处理方案吗？client 已设置 report 分支状态 =false。\n A：确实比较长，个人建议从架构入手去改良，可以通过存入 redis 等一个消息，告诉用户正在插入-\u0026amp;gt;然后一步出力业务，出现异常同样 redis 里的信息改为异常。如果成功就为成功存储 id 或者其它看业务具体情况,然后用户端页面做个倒计时，或者转圈圈，或者直接告诉他正在插入稍等。比如以前用 MQ 削峰就差不多是这个思路吧。长事务尝试用用 Saga、AT 上手快，但是因为锁的存在，效率比较低，后续会逐步优化，性能高入侵也高的 TCC 如果能尝试也可以试试。\n2、@孟昊 提问：\n 请问一下，我今天看了一下文档，好像 cloud 通过 feign 调用方式只能使用 AT 模式, 在并发量比较高的场景下会有问题么(小事务)。\n A：微服务框架跟分布式事务模式没有绑定，还可以用 TCC、Saga。Saga 目前理论上支持所有 RPC 框架，只要是个 bean 即可。\n3、@小孟 提问：\n MOSN 是否支持了 Dubbo 协议？\n A：MOSN 在本周已通过 x-protocol 支持了 Dubbo 和 Tars 协议，具体可见： https://github.com/mosn/mosn/pull/950\n4、关于线上直播 SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk 提问回答\n直播视频回顾：https://tech.antfin.com/community/live/1096\n@鸿关 提问：\n 用 SOFAArk 的话，能直接集成到 SOFABoot 工程不？还是说必须要建个 SOFAArk 的工程？SOFAArk 可以运用于非 SOFABoot 的项目么？\n A： 能直接继承到 SOFABoot 工程，不需要新建 SOFAArk 工程，也可以用于非 SOFABoot 工程，只要是 Spring Boot 工程即可，但是不引入 SOFA 相关依赖的话，@SofaService 及 @SofaReference 等注解就没法用了。\n@盲僧 提问：\n 运行期间安装 biz，然后激活模块这一过程做了哪些事情 ，如果这个 biz jar 包放在远程仓库怎么加载里面的代码呢？是拉下来放到本地的一个磁盘用 classloader 去加载使用吗？\n A：安装和激活是的两个操作，安装支持两种协议获取 biz 包：http 和 file，激活只是在内部调整了同 biz 不同版本的状态。\n 运行期间安装 biz 后，那个 execute jar 包里会有这个 biz 包吗？ A：可以尝试用插件打个包出来解压看下哦。\n @曾鹏 提问：\n SOFAArk 有什么实际的应用场景吗？\nA：可以看下这个：蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析\n SOFAArk：https://github.com/sofastack/sofa-ark\n本周推荐阅读 SOFAStack Community | 欢迎加入 蚂蚁金服研发框架总览 | SOFABoot 框架剖析 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFATracer v2.4.5\u0026amp;frasl;3.0.9 版本，主要变更如下：\ni. 默认禁用上报数据到zipkin, 需要显式设置 com.alipay.sofa.tracer.zipkin.enabled=true 才能开启； 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.5 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.9\n2、发布 SOFATracer v2.4.6v/v3.0.10 版本，主要变更如下：\ni. 支持使用 JVM系统属性 或 环境变量 SOFA_TRACER_LOGGING_PATH 来定制 tracelog 的路径 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.6 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.10\n社区直播预告 本期为 SOFAChannel 线上直播第 12 期，将邀请蚂蚁金服分布式事务核心开发仁空分享《蚂蚁金服分布式事务实践解析》。\n软件开发模式从原来的单应用，到现在的微服务、分布式架构，一个大型分布式系统内，单业务链路往往需要编排多个不同的微服务，如何实现分布式场景下业务一致性，是摆在软件工程师面前的一个技术难题。\n本期分享将介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n时间：2020年3月12日（周四）19:00-20:00\n嘉宾：仁空，蚂蚁金服分布式事务核心开发\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1581667200,"description":"【02/10-02/14】| 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200214/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3deaf12dd1b6589f41c57291d9061534","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200214/","publishdate":"2020-02-14T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200214/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 2/13直播回顾、3/12直播预告、SOFATracer 发版","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200214/","wordcount":1781},{"author":"SOFA 团队","categories":"Service Mesh","content":" 2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。\n参与问卷调查的人员情况 共收集到 516 份问卷结果，问卷填写者 94.2% 来自 ServiceMesher 社区，21.7% 的人参与过社区线上活动，27.5% 的人参与过社区 meetup，86.6% 看好 Service Mesh 的未来发展前景。\n下面是参与问卷调查人员的基本情况。\n公司所属行业\n所在公司的 Service Mesh 使用情况\n工作年限\n在公司中担任的职务\n关注 Service Mesh 技术的时长\n周围关注或了解 Service Mesh 技术的人员情况\n学习 Service Mesh 技术的方式\n关注的 Service Mesh 相关开源项目\n除了 Service Mesh 外关注的其他云原生领域\n对 Service Mesh 的了解程度\n关注 Service Mesh 技术中的哪部分\n社区参与 了解社区活动的情况\n对社区的建议\n还有很多对社区的建议，反馈比较多的如下：\n 更多落地实践和指南 发布一些入门级的文章，结合案例，让技术在中小企业中落地 组织一些线上或线下活动 对普通开发者的职业发展的建议 出系列教程 结论 从结果中可以看出，Service Mesh 在互联网公司中关注的比例最高，但是它仍然还在高速发展中，还缺乏完善的教程和案例。\n本次问卷调查旨在了解 ServiceMesher 社区成员对 Service Mesh 的了解及社区参与程度，帮助 ServiceMesher 社区做的更好，还需要社区成员们共同的努力。\n欢迎关注 Service Mesh 技术的小伙伴们加入 ServiceMesher 社区，共同交流学习和成长。\n关于本次调查问卷的最终解释权归 ServiceMesher 社区所有。\n","date":1581667200,"description":"2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。","dir":"blog/service-mesh-end-user-survey-report/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e2f1dc19ca9ab916db565bdd2bd5a50f","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-end-user-survey-report/","publishdate":"2020-02-14T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/service-mesh-end-user-survey-report/","summary":"2020 年 2 月 4 日到 2 月11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。 参与问卷调查的人员情况 共收集到 516 份问卷结","tags":["Service Mesh"],"title":"Service Mesh 终端用户调查报告","type":"blog","url":"/sofastack.tech/blog/service-mesh-end-user-survey-report/","wordcount":530},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析\n 活动时间：3 月 12 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#12：蚂蚁金服分布式事务实践解析 软件开发模式从原来的单应用，到现在的微服务、分布式架构，一个大型分布式系统内，单业务链路往往需要编排多个不同的微服务，如何实现分布式场景下业务一致性，是摆在软件工程师面前的一个技术难题。\n蚂蚁金服作为一家金融科技公司，业务涉及金融核心的各个领域，从2007年开始就自主研发了分布式事务框架，解决跨数据库、跨服务的业务一致性问题；随着13来年的不断打磨和沉淀，历经双十一、双十二等大促的洗礼，如今所有核心业务都已经在使用这套框架来保障交易的完整性和最终一致性，做到知托付，让用户放心。\n本期分享将介绍蚂蚁金服内部的分布式事务实践，包括 TCC（Try-Confirm-Cancel） 模式以及 FMT （Framework-Managerment-Transaction，框架管理事务）模式。同时也会与大家分享在面对双十一大促这种世界级的流量洪峰前，我们又是如何应对这个挑战。\n本期为 SOFAChannel 线上直播第 12 期，将邀请蚂蚁金服分布式事务核心开发仁空分享《蚂蚁金服分布式事务实践解析》。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1096\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服分布式事务实践解析 仁空，蚂蚁金服分布式事务核心开发\n本期分享大纲 分布式事务产生的背景； 蚂蚁金服分布式事务理论与实践； TCC 模式 FMT 模式 蚂蚁金服分布式事务极致性能提升； 蚂蚁金服分布式事务开源与展望； 嘉宾 SOFAGirl 主持人 仁空，蚂蚁金服分布式事务核心开发 ","date":1581498000,"description":"3 月 12 日周四晚 7 点，线上直播第 12 期。","dir":"activities/sofa-channel-12/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c80a24fd4e76747f0ed57c139a2bfae9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-12/","publishdate":"2020-02-12T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-12/","summary":"概要 活动主题：SOFAChannel#12：蚂蚁金服分布式事务实践解析 活动时间：3 月 12 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这里 介绍 | SOFAChannel","tags":["SOFAChannel","分布式事务"],"title":"SOFAChannel#12：蚂蚁金服分布式事务实践解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-12/","wordcount":784},{"author":"纶珥","categories":"SOFALab","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFABoot 框架》第一篇，本篇作者纶珥，来自蚂蚁金服。《剖析 | SOFABoot 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:BootLab/]()，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFABoot 是蚂蚁金服开源的基于 SpringBoot 的研发框架，提供了诸如 Readiness Check、类隔离、日志空间隔离等能力，用于快速、敏捷地开发 Spring 应用程序，特别适合构建微服务系统。\nSpringBoot 基于 Spring 的按条件配置（Conditional Configuration），结合 starter 依赖机制提供了快捷、方便开发 Spring 项目的体验，获得了极大的成功；SOFABoot 同样在这两个能力上基于 SpringBoot 扩展出适应于金融级应用开发框架。作为脱胎于蚂蚁金服内部对于 SpringBoot 的实践，SOFABoot 补充了 SpringBoot 在大规模金融级生产场景下一些不足的地方，例如 Readiness 检查、类隔离和日志空间隔离等等能力。在增强了 SpringBoot 的同时，SOFABoot 还提供了让用户可以在 SpringBoot 中非常方便地使用 SOFAStack 中间件的能力。\nSOFABoot ：https://github.com/sofastack/sofa-boot\n功能点概览 SOFABoot 完全兼容 SpringBoot，SpringBoot 技术栈可以快速切换到 SOFABoot 技术栈：修改项目 pom 依赖的 \u0026amp;lt;parent/\u0026amp;gt; 节点，例如将：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 当前 SOFABoot 的最新版本为 v3.2.2。\n应用 Readiness 检查 一个应用启动之后，是否是“准备”好能够处理外部请求呢？作为应用流量入口的组件是否可以接收外部连接？这就很有必要引入应用 Readiness 的检查，SOFABoot 提供除 SpringBoot 健康检查之外的应用 Readiness 检查能力，保证应用组件的正常启动、应用安全上线。\nSOFABoot 通过 HealthChecker 检查各组件的 ready 情况。在 Spring 上下文刷新完成之后（所有的 Spring Bean 已经实例化完成），SOFABoot 会获取 IoC 容器中所有的 HealthChecker 实现类，检查其返回的组件健康状况；在应用开启了模块化隔离之后，模块 HealthChecker 还会 kicks in，检查模块的健康状况。Spring 原生的 HealthIndicator 作为 Readiness 的一部分也会纳入 Readiness 的结果中，若 HealthIndicator 出现了失败的情况，那么应用的 Readiness 也是不通过。\nReadiness 检查包含组件的后置检查，流量入口组件（例如：RPC、REST）需要保证后置检查通过之后能接受外部流量的请求，应用才是真正 ready 了。\n应用 Readiness 与 Liveliness 不同的是 Readiness 表示的是应用启动完成之后是否“准备”好的状态，启动完成之后是不变的；两次部署间的 Readiness 的所有请求结果是一致的。\n应用模块化 应用模块化的方案多种多样。传统方案是以应用功能为边界做模块划分；研发期间，不同职责的类放在不同的模块下，但在运行期间都在同一个 classpath 下，没有任何隔离。而与传统的模块划分方案不同，人们发现可以利用 Java 的 ClassLoader 机制，将模块与模块间的类完全隔离；当某个模块需要与另一个模块通信时，可以通过类的导入和导出来实现。OSGi 和 SOFAArk 都是基于 ClassLoader 隔离的模块化实践方案。\n传统的模块化方案没有任何的隔离手段，模块间的边界得不到保障，容易出现模块间的紧耦合；而基于 ClassLoader 的模块化方案则过于彻底，研发人员必须十分清楚类的导入与导出、Java 的类加载体系，模块划分的负担转嫁到了普通研发人员身上。\nSOFABoot 综合以上两种方案的利弊，引入了介于两者之间的模块化方案：每个模块有独立的 Spring 上下文，通过上下文的隔离，让不同模块之间的 Bean 的引用无法直接进行，达到模块在运行时的隔离。这样既保证了不引入过多的复杂性，也避免了没有任何隔离措施的模块边界保障。如下图所示：\n所有的 SOFABoot 模块都会有一个相同的 Spring Context 的 Parent，称之为 Root Application Context。对于所有模块都需要引入的 Bean，可以选择将其放置于 Root Application Context 中，在所有的模块间共享。此外，SOFABoot 框架提供两种 Spring 上下文隔离方案后的模块间通信能力：\n JVM 服务的发布和引用：同一个应用内不同模块间的通信 // Publish a JVM service @Component @SofaService public class MyServiceImpl implements MyService { // implementation goes here } // Reference a JVM service public class AnyClass { @SofaReference private MyService myService; } RPC 服务的发布和引用：不同应用间的通信 // Publish a RPC service @Component @SofaService(interfaceType = MyService.class, bindings = { …","date":1581321600,"description":"本文为《剖析 | SOFABoot 框架》第一篇，主要介绍 SOFABoot 的基础特效。","dir":"blog/sofa-boot-overview/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d1a5fa7654f26a159c65061d4f7712d7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-overview/","publishdate":"2020-02-10T16:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-boot-overview/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFALab","剖析 | SOFABoot 框架","SOFABoot"],"title":"蚂蚁金服研发框架总览 | SOFABoot 框架剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-overview/","wordcount":3219},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@张一心 提问：\n 建议 Seata 全局加锁时候支持快速抢占机制，在不同重要程度事务处理中优先满足重要业务的加锁处理以优先保证紧急重要逻辑的处理，实现方式有多种的，可以根据情况直接回滚干掉非紧急事务也可以在等待加锁队列中做插队处理。\n A：不是通用场景，这个不是通过 API 来实现，后续添加控制台后，在控制台页面对活动事务可以进行控制，可单个事务降级或 redo。\n 之前我是通过改造其值来源于 Nacos 配置的全局事务注解完成的，有了单独事务控制台能起到各司其职更好，既然后续补充了控制台，是不是事务处理的各类统计也能在控制台上面看得到，作为一系列资源分配的参考指标。\n A：控制台主要包括监控统计和事务控制介入，你说的应该是动态降级，这个是全局的，细化不到刚才说的那种抢占机制比如手动在控制台的具体某个事务进行降级释放锁，直接通过 API 这个数据破坏性无法控制，对于这种需要人工去介入并且有 trace。\n 实际生产中涉及金钱交易的优先级往往高于非金钱交易的优先级。破坏性来源主要是加锁中的破坏性回滚，实际业务中往往会存在不能锁刚好被加在队列中等待一阵的现象，这时候完全可以根据全局标记做全局性插队，在处理中加快相关业务处理。监控粒度不应该忽视锁的名称，全局业务的加锁顺序和持有时间，不然当业务量大且相互交叉发生全局性死锁也是会存在的。确切说是业务量大并且分布在不同 TC 上加锁情况下可能会产生哲学家就餐问题带来的死锁。\n A：这里不存在死锁，先拿的是数据库的 X 锁，在拿的是全局锁，你可以举个栗子。一种优先级是处理前优先级类似于 mq 的优先级队列，这种是哪个事务优先被处理，这种是需要兼顾顺序和锁优先级排序，高优先级事务分支优先被处理。 一种是处理中的锁被剥夺，这种是破坏性的，如果在一个不重要的事务中分支1执行完成，另外一个重要事务请求分支1同样的锁，这个锁这时可被剥夺，不重要事务释放锁降级非分布式事务。大多数冲突的情况应该属于处理中而不是处理前。\n 根据测试经验，量小的时候会等，量大的时候会直接碰撞，量进一步加大则除了碰撞而且跑队列里一起挤挤的概率就会飙上去。这时候会遇到几个难点，1队列下是不是插队（这个通过认为设置比较好解决）2抢占是否必要，这时候需要通过对之前加锁的统计（包括业务处理时间与网络通信等综合指标）和潜在破坏性做评估，如果破坏性较小或无且不抢占下对业务预等待时间较长且其他回滚表较为独立则直接回滚抢占，最典型场景就是扣钱的时候充值，或者出货的时候补货。\n A：第2中的破坏性来源于不重要事务锁被剥夺降级为非分布式事务，但是由于后续事务分支出现异常，会导致这个事务分支无法参与回滚，若参与回滚必会导致重要事务全局回滚时数据校验不通过而无法回滚。\n 对，校验不通过关键在于目前采用的是全量型业务，而不是基于对 sql 语句解析之后的增量型业务（即 TCC 的 cancel 步骤里反向对冲）。\n A：对于 AT 模式都是基于数据的不是基于 sql 的，与 binlog 同步方式类型同理。\n 下面问题来了，数据破坏是因为先去 TC 报道还是先去数据库加锁造成的。如果先去 TC 报道，等报道成功再去 DB 加锁就不会发生数据破坏的问题，因为报道失败就直接返回了不会对 DB 造成影响。\n A：那个锁的范围更大些，肯定是 DB 的 X 锁。服务是操作 DB 的，如果连 DB 锁拿不到，拿全局锁有什么意义，假设先拿全局锁，数据库锁拿不到时是不是又需要 RPC 去释放全局锁？\n 不知道有没必要添加对全局读写锁的支持，这个个人未实践过，纯属个人观点，也不知道现在是否已经实现了？\n A：这个说的是类似 JUC 的读写锁嘛？如果单纯这样没什么实际意义，现在是类似数据库 select for update 的 X 锁上升到全局锁。\nService Mesh 大规模落地系列 蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.9.0 版本，主要变更如下：\n 引入嵌入模式； 升级 SGX SDK 依赖到最新版； 大幅提升网络 I/O 的性能； 正式支持 Python 语言的应用； 正式支持 Ubuntu 18.04 和 CentOS 7.2； 修复了多个 bug； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.9.0\n社区直播预告 春节后直播预告来啦～本期为 SOFAChannel 线上直播第 11 期，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n时间：2020年2月13日（周四）19:00-20:00\n嘉宾：玄北，蚂蚁金服技术专家 SOFAArk 开源负责人\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1581066000,"description":"【02/03 - 02/07】 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200207/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4e10f9b05976b3f0f8ce4d9128fa8d79","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200207/","publishdate":"2020-02-07T17:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200207/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | Service Mesh 落地系列文章、2/13直播预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200207/","wordcount":2288},{"author":"柑橘、西经、柏翘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，该系列从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n前言 Service Mesh 在蚂蚁金服内部已经大规模落地，经历刚刚双十一的检阅，将现有的体系快速演进至 Service Mesh 架构，无异于给飞机换发动机。本主题主要分享在蚂蚁金服当前的体量下，我们如何做到给飞机换发动机，还确保不出问题。同时在 Mesh 对外客户输出同样有高质量的保障。\n本文结合蚂蚁金服 Mesh 化落地质量保障落地的思考，给大家带来如下三个方面的一些质量保障的分享：\n Mesh 化质量保障体系； Mesh 化测试技术； Mesh 化双十一大规模落地的性能保障； 质量保障体系 首先给大家介绍下我们的质量保障体系。\n测试保障体系\n我们从测试环境、测试用例、基础功能测试原子镜像能力、测试工具平台、测试场景组合调度、测试方案制定、线上巡检监控、灰度发布三板斧、交付验证、性能、自动化测试等多个方面进行系统性测试保障。通过内外部的质量数据度量和双十一大促来检阅我们的质量能力。\nMesh 测试技术 在开始介绍测试技术之前，我们先了解一下什么是 Service Mesh 以及 Service Mesh 是如何工作的，在蚂蚁金服的技术架构中是以什么形式存在，发挥着怎样的作用。\n简单的说 Service Mesh 存在两个面，一个面叫数据面（比如 MOSN），就是处理应用数据请求的一个独立代理模块，脱离于应用，为应用提供请求代理及一些复杂通信逻辑处理，另外一个叫控制面（比如 SOFAMesh），管理应用配置及业务规则等（比如业务开关/服务路由规则），通过下发配置“指挥”数据面去执行，满足不同阶段实现不同的业务支持。\nMesh 框架简图\n我们先简单介绍下经典微服务请求路由。\n经典微服务模式请求路由\n经典微服务模式下 Docker 镜像化服务在一个 Pod 一般只有一个业务应用容器在运行，这种情况下测试框架只要关心业务应用即可。\n经典微服务测试架构\nMesh 测试架构改进 Mesh 测试架构在经典微服务测试架构上也做了新的演进。MOSN 作为 Sidecar 与业务容器共存在一个 Pod，资源与业务应用容器共享，每个业务逻辑都需要通过 MOSN 去处理，因而只关心业务应用肯定不够，需要再扩展支持到 MOSN 这类 Sidecar 的测试验证。在 MOSN 中集成了控制面 xds client，与控制面 pilot 建立通信，用于接收 pilot 下发的配置信息。在蚂蚁金服技术架构存在三地五中心/同城双活等容灾能力，因而产生了 LDC，一个集群多个 zone 情况，控制面 pilot下发是可以配置集群+zone+应用+ip 组合粒度，要验证这个多 zone 下发规则准确性，那就需要创建多个 xds client（或者 MOSN）。另外 Sidecar 是不能直接访问的，通过测试应用暴露出接口，给上层测试。\nMesh 化测试架构\n构建高仿真测试环境 那么，我们测试环境要做到足够仿真，面临哪些挑战呢？首先看下我们自研的 MOSN 具备的能力和技术复杂性。\n MOSN 能力大图\n应对 MOSN 测试场景复杂性，我们搭建了一套高仿真测试环境，这里以 MOSN 中的 RPC 功能为例，阐述这套环境的构成要素及环境部署架构。\n集成测试环境构成要素\n这里可以举一个 RPC 路由的例子来详细讲述。我们知道，业务在做跨 IDC 路由时，主要通过跨域 VIP 实现，这就需要业务在自己的代码中设置 VIP 地址，例如：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.APPNAME.facade.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleRpcService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.tr\u0026amp;gt; \u0026amp;lt;sofa:vip url=\u0026amp;quot;APPNAME-pool.zone.alipay.net:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.tr\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 这时候假如业务配置了不合法的 URL，如：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.APPNAME.facade.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleRpcService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.tr\u0026amp;gt; \u0026amp;lt;sofa:vip url=\u0026amp;quot;http://APPNAME-pool.zone.alipay.net:12200?_TIMEOUT=3000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.tr\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上述 VIP URL 指定了 12200 端口，却又同时指定了 http，这种配置是不合法的，就会出现问题，这时候测试环境就需要跨 zone、跨 LDC 的测试环境。我们在多数复杂产品测试里都会遇到，极度复杂测试场景无法 100% 分析充分。一般对于这种场景，我们可以借助于线上流量回放的能力，将线上的真实流量复制到线下，作为我们测试场景的补充。这也需要非常仿真的测试环境做 MOSN 的流量回放支撑。\n兼容性测试 MOSN 兼容性验证\n我们通过一个例子来详细阐述：老版本的 RPC 中我们支持 TR 协议，后续的新版支持 BOLT 协议，应用升级过程中，存在同时提供 TR 协议和 BOLT 协议服务的情况，如下图：\n应用升级过程中，相同接口提供不同协议的服务\n首先，应用向 MOSN 发布服务订阅的请求，MOSN 向配置中心订阅，配置中心返回给 MOSN 两个地址，分别支持 TR 和 BOLT，MOSN 从两个地址中选出一个返回给应用 APP。\n这里兼容性风险是：MOSN 返回给 APP 的地址是直接取配置中心返回的第一条数据，这里可能是 TR 也可能是 BOLT。\n如果 MOSN 返回给应用的地址是支持 BOLT 协议的服务端，那么后续应用发起服调用时，会直接以 BOLT 协议请求 MOSN，MOSN 选址时，会以轮询的方式两个服务提供方，如果调用到 Server1，就会出现协议不支持的报错。 因此我们针对各种兼容性具体场景都要做好分析和相应的测试。\nMOSN 的鲁棒测试（稳定性、健壮性） 从 MOSN 的视角来看，其外部依赖如下：\nMOSN 外部依赖图\n除了验证 MOSN 自身的功能外，我们还通过故障注入的方式，对 MOSN 的外部依赖做了专项测试。通过这种方式，我们发现了一些上述功能测试未覆盖的场景，这里以应用和 MOSN 之间的 12199 端口举例。\n应用 APP 接入 MOSN 后，原先应用对外提供的 12200 端口改由 MOSN 去监听，应用的端口修改为 12199，MOSN 会向应用的 12199 端口发送心跳，检测应用是否存活。\n如果应 …","date":1579514400,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，结合蚂蚁金服 Mesh 化落地质量保障落地的思考，给大家带来一些质量保障的分享。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8dfd6e1dabd16bc85d9876ce9764e3ab","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","publishdate":"2020-01-20T18:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后 一篇 - 质量篇，该系列从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/","wordcount":3163},{"author":"嘉祁","categories":"Service mesh","content":" 本文根据蚂蚁金服中间件 SRE技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。\n背景 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。而在具体部署上，保守的做法是以独立进程的方式与业务进程共同存在于业务容器内。蚂蚁金服的做法是从开始就选择了拥抱云原生。\n大规模落地的过程中，我们在看到 Service Mesh 带来的巨大红利的同时，也面临过很多的挑战。为此，蚂蚁金服配备了“豪华”的技术团队阵容，除了熟悉的 SOFA 中间件团队，还有安全、无线网关以及专门配备了专属的 SRE 团队，使得 MOSN 能力更加全面更加可靠。\n今天我们详细聊聊技术风险这个方面。对于一个新的中间件技术，在落地过程中总会面临稳定性、运维模式变化等等很多的问题与挑战，需要建设相应的技术风险能力，确保整个落地过程以及长期运行的稳定和可靠。\n本次分享主要从以下三个方面展开：\n 落地过程中对于部署模式和资源分配的思考； 变更包括接入、升级的支持、问题与思考； 整个生产生命周期中稳定性面临的挑战与技术风险保障； Sidecar 部署模式 业务容器内独立进程的好处在于与传统的部署模式兼容，易于快速上线；但独立进程强侵入业务容器，对于镜像化的容器更难于管理。而云原生化，则可以将 Service Mesh 本身的运维与业务容器解耦开来，实现中间件运维能力的下沉。在业务镜像内，仅仅保留长期稳定的 Service Mesh 相关 JVM 参数，从而仅通过少量环境变量完成与 Service Mesh 的联结。同时考虑到面向容器的运维模式的演进，接入 Service Mesh 还同时要求业务完成镜像化，为进一步的云原生演进打下基础。\n 优 劣 独立进程 兼容传统的部署模式；改造成本低；快速上线 侵入业务容器； 镜像化难于运维 Sidecar 面向终态；运维解耦 依赖 K8s 基础设施；运维环境改造成本高；应用需要镜像化改造 在接入 Service Mesh 之后，一个典型的 POD 结构可能包含多个 Sidecar：\n MOSN：RPC Mesh, MSG Mesh, \u0026amp;hellip;（扩展中）； 其它 Sidecar； MOSN：https://github.com/mosn/mosn\n这些 Sidecar 容器与业务容器共享相同的网络 Namespace，使得业务进程可以以本地端口访问 Service Mesh 提供的服务，保证了与保守做法一致的体验。\n基础设施云原生支撑 我们也在基础设施层面同步推进了面向云原生的改造，以支撑 Service Mesh 的落地。\n运维平台模型支撑 首先是运维平台需要能够理解 Sidecar，支撑 Sidecar 模型的新增元数据，包括基于 POD 的 Sidecar 的多种标签，以及 Sidecar 基线配置的支持。\n业务全面镜像化 其次我们在蚂蚁金服内部推进了全面的镜像化，我们完成了内部核心应用的全量容器的镜像化改造。改造点包括：\n 基础镜像层面增加对于 Service Mesh 的环境变量支撑； 应用 Dockerfile 对于 Service Mesh 的适配； 推进解决了存量前后端分离管理的静态文件的镜像化改造； 推进了大量使用前端区块分发的应用进行了推改拉的改造； 大批量的 VM 模式的容器升级与替换； 容器 POD 化 除了业务镜像层面的改造，Sidecar 模式还需要业务容器全部跑在 POD 上，来适应多容器共享网络。由于直接升级的开发和试错成本很高，我们最终选择将接入 Service Mesh 的 数百个应用的数万个非 K8s 容器，通过大规模扩缩容的方式，全部更换成了 K8s PODs。\n经过这两轮改造，我们在基础设施层面同步完成了面向云原生的改造。\n资源的演进 Sidecar 模式的带来一个重要的问题，如何分配资源。\n理想比例的假设独占资源模型 最初的资源设计基于内存无法超卖的现实。我们做了一个假设：\n MOSN 的基本资源占用与业务选择的规格同比例这一假设。 CPU 和 Memory 申请与业务容器相应比例的额外资源。这一比例最后设定在了 CPU 1/4，Memory 1/16。\n此时一个典型 Pod 的资源分配如下图示：\n独占资源模型的问题 这一方式带来了两个问题：\n 蚂蚁金服已经实现了业务资源的 Quota 管控，但 Sidecar 并不在业务容器内，Service Mesh 容器成为了一个资源泄漏点； 业务很多样，部分高流量应用的 Service Mesh 容器出现了严重的内存不足和 OOM 情况； 共享资源模型 讨论之后，我们追加了一个假设：\n Service Mesh 容器占用的资源实质是在接入 Service Mesh 之前业务已使用的资源。接入 Service Mesh 的过程，同时也是一次资源置换。 基于这个假设，推进了调度层面支持 POD 内的资源超卖，新的资源分配方案如下图，Service Mesh 容器的 CPU、MEM 都从 POD 中超卖出来，业务容器内仍然可以看到全部的资源。\n考虑到内存超卖也引入了 POD OOM 的风险，因此对于 Sidecar 容器还调整了 OOM Score，保证在内存不足时，Service Mesh 进程能够发挥启动比 Java 业务进程更快的优势，降低影响。\n新的分配方案解决了同时解决了以上两个问题，并且平稳支持了蚂蚁金服的双十一大促。\n变更-Service Mesh 是如何在蚂蚁金服内部做变更的 Service Mesh 的变更包括了接入与升级，所有变更底层都是由 Operator 组件来接受上层写入到 POD annotation 上的标识，对相应 POD Spec 进行修改来完成，这是典型的云原生的方式。\n接入-从无至有 标准的云原生的接入方式，是在创建时通过 sidecar-operator webhook 注入一个 Sidecar 容器。\n这个方式的固有缺陷在于：\n 滚动替换过程需要 Buffer 资源； 过程缓慢； 回滚慢，应急时间长； 原地接入 原地接入是为了支撑大规模的快速接入与回滚，通过在存量的 POD 上操作修改 POD Spec。\n尽管看起来不太云原生，但期望能绕过以上几个痛点，从而可以：\n 不需要重新分配资源； 可原地回滚； 升级 Service Mesh 是深度参与业务流量的，最初的 Sidecar 的升级方式也需要业务伴随重启。\n带流量的平滑升级 为了规避 Java 应用重启带来的重新预热等问题，MOSN 提供了更为灵活的平滑升级机制：由 Operator 控制启动第二个 MOSN Sidecar，完成连接迁移，再退出旧的 Sidecar。整个过程业务可以做到流量不中断，几近无感。\n变更能力的取舍 虽然提供了原地接入与平滑升级，但从实践的效果来看，对存量 POD spec 的修改带来的问题，比收益要多得多。\n 创建时注入/普通升级 原地注入/平滑升级 不改变现存 POD spec 改变现存 POD 资源预分配，不影响调度； 逻辑简单，成功率高；与原有业务升级逻辑一致； …","date":1579514400,"description":" 本文根据蚂蚁金服中间件 SRE 技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。","dir":"blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7e1941c7099e109de92394b49df59a2b","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","publishdate":"2020-01-20T18:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","summary":"本文根据蚂蚁金服中间件 SRE技术专家黄家琦（嘉祁）于 Service Mesh Meetup#9 杭州站上的分享整理。 背景 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。","tags":["Service mesh","Service Mesh Meetup"],"title":"蚂蚁金服 Service Mesh 技术风险思考和实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/","wordcount":4057},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n 活动时间：2 月 13 日周四晚 7 点\n 活动形式：线上直播\n 直播回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道，前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本期为 SOFAChannel 线上直播第 11 期，将邀请 SOFAArk 开源负责人玄北和大家一起解读 SOFAArk ，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk：https://github.com/sofastack/sofa-ark\n你将收获：\n 快速认识轻量级类隔离容器 SOFAArk； Demo 案例实操，了解如何使用 SOFAArk 实现类隔离； SOFAArk 完整功能详解； | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1096\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 从一个例子开始体验轻量级类隔离容器 SOFAArk 玄北，蚂蚁金服技术专家 、SOFAArk 开源负责人\n本期分享大纲： 快速认识轻量级类隔离容器 SOFAArk； Demo 案例实操，了解如何使用 SOFAArk 实现类隔离； SOFAArk 完整功能详解； 嘉宾 SOFAGirl 主持人 玄北，蚂蚁金服技术专家 、SOFAArk 开源负责人 ","date":1579251600,"description":"2 月 13 日周四晚 7 点，线上直播第 11 期。","dir":"activities/sofa-channel-11/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b110f76087d52e5c6d8ccbe31c76a7f5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-11/","publishdate":"2020-01-17T17:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-11/","summary":"概要 活动主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk 活动时间：2 月 13 日周四晚 7 点 活动形式：线上直播 直播回顾：戳这","tags":["SOFAChannel","SOFAArk"],"title":"SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk","type":"activities","url":"/sofastack.tech/activities/sofa-channel-11/","wordcount":709},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@J~杰 提问：\n 咨询一下，Seata TCC 中这个 BusinessActivityContext 是用于做什么的？\n A：比如说在 rollback 服务里需要用到 try 服务里的参数时，可以放到 BusinessActivityContext，然后在 rollback 和 comfirm 服务里可以取到这个参数。\n 那是要自己在 try 阶段需要手动实例化 BusinessActivityContext？\n A：不需要，可以在 try 方法上的参数加注解，它会自动把这个参数放入 BusinessActivityContext。\nSeata：https://github.com/seata/seata\n2、王国柱 提问：\n 有一个问题想要请教一下： HBX：如果是 spanner - \u0026amp;gt; gateway -\u0026amp;gt; app1 这种架构，每次上新的应用，应该是需要在 geteway 中配置新应用的 ip 地址路由信息。 如果是 spanner -\u0026amp;gt; gateway.jar,app1 这种架构，如果新增加 app2， spanner 如何知道新的应用地址在哪里。\nHBX：我理解集中式的 gateway，应该会把后端 app 的应用地址信息配置在集中式的 gateway 中。如果做成 jar，那 app 和 jar 的地址信息，该如何被 spanner 知道？\n A：Spanner 其实就是 ingress，不管是 gateway 还是 app x，都可以通过服务发现来发现服务器的 ip 信息。\n 那像这种的话，就是后台服务上线，可以自己注册到 spanner 上，然后外部应用就可以直接访问了。\n A：是的。 MOSN：https://github.com/mosn/mosn\nKubeCon NA2019 回顾 开箱即用的 Java Kubernetes Operator 运行时 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 本周推荐文章 10年后，阿里给千万开源人写了一封信 蚂蚁金服消息队列 SOFAMQ 加入 OpenMessaging 开源标准社区 蚂蚁金服 API Gateway Mesh 思考与实践 社区直播预告 春节后直播预告来啦～本期为 SOFAChannel 线上直播第 11 期，将从 SOFAArk 的特性出发，了解轻量级类隔离容器 SOFAArk 的主要功能，并通过一个 Demo 案例，跟讲师一起操作，实际体验 SOFAArk 具体操作以及功能实现。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n主题：SOFAChannel#11：从一个例子开始体验轻量级类隔离容器 SOFAArk\n时间：2020年2月13日（周四）19:00-20:00\n嘉宾：玄北，蚂蚁金服技术专家 SOFAArk 开源负责人\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1579248000,"description":"【01/13-01/17】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200117/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2fd8dd14cb119400890ef134622ad4d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200117/","publishdate":"2020-01-17T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200117/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":" SOFA Weekly | 2.13直播预告、KubeCon NA2019 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200117/","wordcount":1210},{"author":"何子波、金敏","categories":null,"content":" 本篇分享的内容难度为“初学者/Beginner”级别，以下是阅读本文前推荐您了解的背景知识：\n Java 语言编程基础； 了解过 Kubernetes 平台上的 Operator/Controller 工作机制； 也可以同步参考 Kubernetes 官方博客内容：https://kubernetes.io/blog/2019/11/26/develop-a-kubernetes-controller-in-java\n图为何子波和金敏在 KubeCon NA2019 大会分享后的交流\n何子波 蚂蚁金服技术专家： _(adohe@github) _Kubernetes 维护者，SIG CLI Co-Chair（包括 Kubectl 及其扩展插件，Kustomize 以及客户端运行时），同时关注安全容器，多租户等领域。\n金敏 蚂蚁金服软件工程师： _(yue9944882@github) _Kubernetes SIG API-Machinery 维护者及其子领域 Owner（CRD 服务实现，APIAggregation SDK 套件，控制面流控，OpenAPIv2/3，Java SDK 等），同时也是 OpenAPI 开源生态工具链openapitools.org 的 Techincal Committee。\n本文根据两位在 KubeCon NA2019 的分享内容整理。本次演讲与大家分享蚂蚁金服金融科技扩展云原生 Java 能力到云的实践和改造，并将收获的产出回馈开放给 Kubernetes 社区。\n分享概要 在 Kubernetes 平台上开发部署运行 Operator 已经是在 Kubernetes 上拓展开发能力的默认范式。最早是 CoreOS 的工程师们创新提出了 Operator 的开发理念并且在社区收获了良好的反响，在经过一段时间的波折、打磨和实践之后，我们今天才看到丰富多样的 Operator 层出不穷。实际上 Operator 的效力往往要结合 Kubernetes API 的扩展能力才能更好发挥。所以其广泛传播反过来锤炼演进了 Kubernetes 上 CustomResourceDefinition 承载第三方 API 模型的能力。水涨船高，这也是社区集中投入人力从 v1.14 开始启动 Extensibility GA Sprint 小组冲刺 Kubernetes 扩展性建设的推动原因。\n图为何子波和金敏在 KubeCon NA2019 大会现场演示\n随着 Operator 的受众越来越多，社区也衍生出了面向 Operator 开发提效的工具链项目比如 operator-sdk、kubebuilder、metacontroller 等等优秀的开源项目。可是这些项目大都是面向 Go 语言研发者的，虽然越来越多的研发者向 Go 靠扰已是事实，但是 Go 语言尚不及其他主流编程语言成熟，倒是慢慢铺开的 Kubernetes 等其他开源项目的工业实践在“倒逼”Go 语言底层库的修复和稳固，比如 http2 的底层网络库[1]。与此相似的，我们最早内部孵化的 Java 语言的 Operator 运行时框架也是被实际业务“倒逼”出来的，并在 Kubernetes 社区露头试水之初便收获了许多反馈推动发展直到今天走到全面开放。\n你为什么需要使用 Java 开发 Operator 如果你在犹豫不决是否要使用 Java 开发 Operator 并应用到实际中来，我们从以下几个方面进行对比看看哪一点是足够吸引你尝鲜：\n 适配存量系统：如果在登陆 Kubernetes 之前你的基础设施底层系统都是通过 Java 开发的，那么恭喜你已经有了使用 Java Operator 的天然土壤。反过来把存量系统接口逐个“翻译”为 Go 语言既消耗大量人力又引出持续同步维护 Go 语言库的成本。 堆内存快照：相比于 Java，Go 语言很难将运行中的程序的内存进行完整的快照分析，PProf 相关工具链能做的只是将内存的使用概况汇总输出，虽然也可以帮助分析锁定出泄漏的对象类型，但是粒度有限。反过来 Java 程序的堆内存进行快照分析已经具有成熟的工具链支持，研发者通过一份完整的堆快照可以直接锁定出比如 WorkQueue 中积压的内容，甚至限流器中逐个 Key 的瞬时状态，也可以在 Operator 静默不响应的场景下快速锁定问题。 性能诊断/在线调试：结合比如 JMX Exporter 等工具链的帮助，我们直接将 Java 虚拟机的细节运行状态以 Prometheus Metrics 的形式收集起来，虽然 Go 程序也可以暴露出其运行时的 Metrics，但是对比后我们发现 Java 的 Metrics 在分析 GC 状态和堆分布上更加强大。除此之外，Java Operator 的远程调试更加方便上手。 线程模型：与 Java 显著不同的是，Go 语言中的 Routine 不具有直接从外部“杀死”的功能，你需要结合 Channel/Context 等模型间接实现。而在 Java 虚拟机上的线程模型有和操作系统类似的生命周期管理，开发者可以白盒的操作干涉线程的生命周期。这对于某些业务场景是重要的。 OOP 范型编程接口： Go 语言本身的设计哲学是不认可面向对象编程的，尽管好处很多但是在 API 模型繁多的 Kubernetes 项目中，维护者不得己转向使用代码生成器批量为这些模型生成大量模版代码。Java 的优势之一是范型编程，这可以彻底取代代码生成器的工作，同一套代码可以自由地适配在各种模型，比如 Pod 到 Service 等等。 第三方研发者库生态：经过数十年的演进，Java 积累的第三方工具库远比 Go 语言丰富的多，至少目前而已可以算得上是一个优势。 示例代码速览 下面两张代码片段为你展示了具体开发 Java Operator 所需要的全部工作，相信接触过 Kubernetes Client-Go 的开发者通过名字大致了解如何使用了：\n（如何构造出一个 Informer 实例） https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/InformerExample.java\n（如何构造出一个 Operator 实例） https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/ControllerExample.java\n开发 Java Operator 需要额外注意什么 仅仅是通过代码开发 Operator 显然不是大结局，你还需要注意其他的问题，以下是我们在实际运用的获得的经验总结：\n 严谨管理 CRD Yaml 定义：如最开始提到的，当 Java Operator 操作的是自定义资源比如 CRD 时，我们自然需要操作/维护该 CRD 对应的 Java 模型。 …","date":1579176000,"description":" 本文介绍了如何快速上手使用 Java 开发 Operator，感兴趣的读者可以根据官方实例在本地开发环境体验。","dir":"blog/java-kubernetes-operator-kubecon-na2019/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4af2ef3082aeed080e87501fd71134d9","permalink":"https://sofastack.github.io/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","publishdate":"2020-01-16T20:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","summary":"本篇分享的内容难度为“初学者/Beginner”级别，以下是阅读本文前推荐您了解的背景知识： Java 语言编程基础； 了解过 Kubernetes 平台上的 Operator/Controller 工作机制； 也可","tags":["Kubernetes"],"title":" 开箱即用的 Java Kubernetes Operator 运行时","type":"blog","url":"/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/","wordcount":2778},{"author":"贾岛","categories":"Service Mesh","content":" 本文整理自蚂蚁金服高级技术专家贾岛在 12 月 28 日 Service Mesh Meetup 杭州站现场分享。\nMOSN 完成孵化， 启用独立 Group 2020.2019.12.18，MOSN 项目负责人、蚂蚁金服应用网络组负责人涵畅宣布 MOSN 完成从 SOFAStack 的孵化，将启用独立 Group 进行后续运作，欢迎大家共同建设社区。\nMOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称，可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡，API Gateway，云原生 Ingress 等使用。\n项目地址：https://github.com/mosn/mosn\n导语 在 Service Mesh 微服务架构中，我们常常会听到东西流量和南北流量两个术语。蚂蚁金服开源的 Service Mesh Sidecar：MOSN（Modular Observable Smart Network）已经多次与大家见面交流，以往的议题重点在东西流量的服务发现与路由，那么蚂蚁金服在南北流量上的思考是怎样的？\n本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的、解决了什么问题、双十一的实践表现以及我们对未来的思考。\n今天的分享分为三个部分：\n API Gateway Mesh 的定义：我在 Google 上搜了下 API Gateway Mesh 这个词，找到的都是 API Gateway vs Service Mesh，大家估计也会很好奇：这个词具体的定义是怎样的呢？所以我们下面会做将 API Gateway 和 Service Mesh 做个对比，然后讲一下我个人对这个词有理解和思考。 API Gateway Mesh 在蚂蚁金服的实践：今年阿里巴巴核心系统 100% 云原生化，撑住了双11的世界级流量洪峰，这其中，蚂蚁金服的 Service Mesh 大放光彩，核心链路全上 Mesh，数万容器规模，我们 API Gateway 在其中也承担了部分钱包链路和支付链路 100% 的请求。这个章节，我会从蚂蚁金服 API 网关的发展历程来看，我们为什么做 API Gateway Mesh，我们的架构是如何的，以及我们在过程中的一些风险和考验。 云原生下 API Gateway 的思考：大家现在都在讲云原生，但是真正实践云原生的过程中，会越到各种各样的问题，怎么样的 API Gateway 方案和形态是最合适你们的业务的？在云原生的架构中，Service Mesh，API Gateway 都是最核心的组件之一，我们对于云原生下的 API Gateway 在 Service Mesh 架构中的定位是如何思考的？还有，未来我们的一些计划是怎样的？都会在这个章节跟大家分享一下。 API Gateway Mesh 的定义 上面这张图是一个云原生，南北+东西流量的架构图，这里面包含了核心的一些组件，我快速介绍一下：\n LB\\ingress：负责 ssl 卸载、入口流量的负载均衡，通常会做一些简单的路由； API Gateway：负责更偏向业务的 API 验签、限流、协议转换、用户会话、负载均衡等逻辑； Sidecar in POD：业务系统中的 Sidecar，代理机房内东西流量的转发，一般走内部的 RPC（比如SOFARPC \\ Dubbo \\ Thrift \\ SpringCloud），这里面的流量全部通过 Service Mesh 的 Sidecar Proxy 来承载，这个 Sidecar 负责路由（单元化\\灰度\\金丝雀），负载均衡、服务鉴权等等； Control Plane：流量控制「大管家」，云原生里目前最主流的方案是 Istio，负责路由策略、安全、鉴权等等下发和控制； 上面的架构大家都比较了解了，从上面的描述大家也看出来了，API Gateway 和 Service Mesh 的 Sidecar 很多能力都是类似的，比如都是一个网络代理，都具备负载均衡，都具备一些限流和鉴权能力。下面，我们将做一个 API Gateway 和 Service Mesh 的对比。\nAPI Gateway vs Service Mesh  从本质概念上来讲，API Gateway 用一句话概括：「Exposes your services as managed APIs」，将内部的服务以更加可控可管理的方式暴露出去，这里的关键词是「暴露」和「可控」。Service Mesh 用一句话概括：「A infrastructure to decouple the application network from your service code」，一种将服务代码与应用网络解耦的基础设施，这里的关键词是「解耦」。\n在流量上，API Gateway 是管理南北流量的，而 Servcie Mesh 中的 Sidecar 一般情况下是用来负载东西流量的Proxy。两者都具备负责均衡的能力，API Gateway 一般情况下是通过 lvs 、nginx 中心化的一个负载均衡器，我们管这个叫硬负载；而 Service Mesh 一般情况下是通过服务发现，Sidecar 之间是点对点的调用，我们叫软负载。\n通信协议上，API Gateway 一般对外接收开放的通信协议，一般是 HTTP、gRPC 等，而且可能涉及到协议的转换，将 HTTP 转换成内部的 RPC 协议，而 Service Mesh 代理的内部流量一般是内部的私有 RPC 协议（WebService、Dubbo、SOFABolt、Thrift 等等）。在鉴权、流控、安全等控制流量的层面上，对于 API Gateway 来讲都是强依赖的，这样才体现「可控」的特点，而 Service Mesh 代理的内部流量，由于一般处于内网环境，这些控制一般情况下都是弱依赖。\n我们对 Service Mesh 的真正理解 大家可以看到，API Gateway 和 Service Mesh 实际上有很多共同点，也有很多区别。那 API Gateway Mesh 到底是如何定义的呢？那要介绍下，我们对 Service Mesh 的真正理解！\nService Mesh 中的 Sidecar 就是这样一辆边车摩托车，Sidecar 将 Service Code 和内部通信 RPC 逻辑解耦掉。但是 Sidecar 的座位上，不仅仅可以坐「内部通信的 RPC」，也可以将其他中间件放到这辆 Sidecar 中，API Gateway + Sidecar = API Gateway Mesh，我们也可以把 MessageQueue Client 放在 Sidecar 中，就是 Message Mesh。\n所以，大家看，其实 Service Mesh 是一种模式和架构，关键词就是「解耦」你的服务代码和你的「中间件」。\nAPI Gateway Mesh …","date":1579078800,"description":" 本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的、解决了什么问题、双十一的实践表现以及我们对未来的思考。","dir":"blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"370ccd30a2edcf559eb2c82976bcb8a0","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","publishdate":"2020-01-15T17:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","summary":"本文整理自蚂蚁金服高级技术专家贾岛在 12 月 28 日 Service Mesh Meetup 杭州站现场分享。 MOSN 完成孵化， 启用独立 Group 2020.2019.12.18，MOSN 项目负责人、","tags":["Service Mesh","MOSN","Service Mesh Meetup"],"title":"蚂蚁金服 API Gateway Mesh 思考与实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/","wordcount":5174},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@李彦迎 提问：\n TCC 模式我可以作为 Saga 模式使用不？譬如 try 为空，永远成功。\n A：可以，不过应该是 confirm 为空，不是 try 为空。\n 请问 Seata 的 Saga 模式能支持 DB2 数据库吗？\n A：可以支持 DB2。\n 请教基础问题：Gateway 调用微服务 A、B，B内部失败了，补偿交易应该回退A的，这个补偿交易应该定义在微服A里面还是微服务B里面？\n A：原服务是谁提供的，补偿服务就应该谁提供。\n 请问能否 Client 用 DB2，Server 用 MySQL? Client 的必须和业务数据库保持一致吧？\n A：也可以的。是的，Client端必须与业务数据库保持一致。\n2、@米晓飞 提问：\n Saga 和现有框架有啥区别呢，优劣比较？\n A：我们在实践中发现，长流程的业务场景，往往有服务编排的需求，同时又要保证服务之间的数据一致性。目前开源社区也有一些 Saga 事务框架，也有一些服务编排的框架，但是它们要么只有 Saga 事务处理能力、要么只有服务编排能力，Seata Saga 是将这两者能力非常优雅的结合在一起，为用户提供一个简化研发、降低异常处理难度、高性能事件驱动的产品。\n3、@张春雨 提问：\n Saga 的模式补偿和 XA 回滚有啥区别呀？\n A：XA 是数据库提交的两阶段提交协议，Saga 的是需要业务层来实现的。\n Seata server 端使用 mysql 去记录事务日志,感觉性能上不是很好、 有没有其他的可替代的持久化方案吗？\n A：Seata 每个模块都设计有 SPI，持久化也一样，未来可以扩展更多持久化方式。 Seata：https://github.com/seata/seata 更多关于 Seata Saga 的内容可以看下文直播回顾。\n4、@FAN 提问：\n MOSN 的平滑升级原理是什么？跟 Nginx 和 Envoy 的区别是什么？\n A：MOSN 的平滑升级方案和 Envoy 类似，都是通过 UDS 来传递 listener fd。但是其比 Envoy 更厉害的地方在于它可以把老的连接从 Old MOSN 上迁移到 New MOSN 上。也就是说把一个连接从进程 A 迁移到进程 B，而保持连接不断！Nginx 的实现是兼容性最强的。 可以详细阅读：https://ms2008.github.io/2019/12/28/hot-upgrade/ MOSN：https://github.com/mosn/mosn\nSOFAArkLab 系列 蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析 本篇开始将正式启动SOFA:ArkLab/源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。文中附共建列表，欢迎领取共建~\nSOFAChannel 集锦 Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v3.2.2 版本，主要变更如下：\n ReadinessCheckListener 的 Order 过高 删除 jaxrs-api 依赖项 详细发布报告：https://github.com/sofastack/sofa-boot/releases/tag/v3.2.2\n","date":1578643200,"description":"【01/05-01/10】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200110/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1143431da4314982069d5d5465391dc5","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200110/","publishdate":"2020-01-10T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200110/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | SOFABoot 发版、直播回顾、SOFAArkLab共建启动","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200110/","wordcount":1463},{"author":"屹远","categories":"Seata","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#10 直播分享整理，主题：分布式事务 Seata 长事务解决方案 Saga 模式详解。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群：23372465，不错过每场直播。\n 大家好，我是陈龙，花名: 屹远（_long187@github_），是蚂蚁金服分布式事务核心研发，也是 Seata Committer。今天分享的主题是《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\nSeata：https://github.com/seata/seata\n金融分布式应用开发的痛点 分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。\u0026amp;mdash;《左耳听风-弹力设计之“补偿事务”》\n而在金融领域微服务架构下的业务流程往往会更复杂，流程很长，比如一个互联网微贷业务流程调十几个服务很正常，再加上异常处理的流程那就更复杂了，做过金融业务开发的同学会很有体感。\n所以在金融分布式应用开发过程中我们面临一些痛点：\n 业务一致性难以保障 我们接触到的大多数业务（比如在渠道层、产品层、集成层的系统），为了保障业务最终一致性，往往会采用“补偿”的方式来做，如果没有一个协调器来支持，开发难度是比较大的，每一步都要在 catch 里去处理前面所有的“回滚”操作，这将会形成“箭头形”的代码，可读性及维护性差。或者重试异常的操作，如果重试不成功可能要转异步重试，甚至最后转人工处理。这些都给开发人员带来极大的负担，开发效率低，且容易出错。\n 业务状态难以管理 业务实体很多、实体的状态也很多，往往做完一个业务活动后就将实体的状态更新到了数据库里，没有一个状态机来管理整个状态的变迁过程，不直观，容易出错，造成业务进入一个不正确的状态。\n 业务监控运维难 业务的执行情况监控一般通过打印日志，再基于日志监控平台查看，大多数情况是没有问题的，但是如果业务出错，这些监控缺乏当时的业务上下文，对排查问题不友好，往往需要再去数据库里查。同时日志的打印也依赖于开发，容易遗漏。\n 缺乏统一的差错守护能力 对于补偿事务往往需要有“差错守护触发补偿”、“人工触发补偿”操作，没有统一的差错守护和处理规范，这些都要开发者逐个开发，负担沉重。\n理论基础 对于事务我们都知道 ACID，也很熟悉 CAP 理论最多只能满足其中两个，所以，为了提高性能，出现了 ACID 的一个变种 BASE。ACID 强调的是一致性（CAP 中的 C），而 BASE 强调的是可用性（CAP 中的 A）。在很多情况下，我们是无法做到强一致性的 ACID 的。特别是我们需要跨多个系统的时候，而且这些系统还不是由一个公司所提供的。BASE 的系统倾向于设计出更加有弹力的系统，在短时间内，就算是有数据不同步的风险，我们也应该允许新的交易可以发生，而后面我们在业务上将可能出现问题的事务通过补偿的方式处理掉，以保证最终的一致性。\n所以我们在实际开发中会进行取舍，对于更多的金融核心以上的业务系统可以采用补偿事务，补偿事务处理方面在30多年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较也公认 Saga 是作为长事务的解决方案。\n https://github.com/aphyr/dist-sagas/blob/master/sagas.pdf http://microservices.io/patterns/data/saga.html\n Saga 模式用一种非常纯朴的方式来处理一致性：补偿。上图左侧是正常的事务流程，当执行到 T3 时发生了错误，则开始执行右边的事务补偿流程，返向执行T3、T2、T1 的补偿服务，其中 C3 是 T3 的补偿服务、C2 是 T2 的补偿服务、C1 是 T1 的补偿服务，将T3、T2、T1 已经修改的数据补偿掉。\n使用场景 一些场景下，我们对数据有强一致性的需求时，会采用在业务层上需要使用“两阶段提交”这样的分布式事务方案。而在另外一些场景下，我们并不需要这么强的一致性，那就只需要保证最终一致性就可以了。\n例如蚂蚁金服目前在金融核心系统使用的就是 TCC 模式，金融核心系统的特点是一致性要求高（业务上的隔离性）、短流程、并发高。\n而在很多金融核心以上的业务（比如在渠道层、产品层、集成层的系统），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务（如金融网络）。这是如果每个服务都开发 Try、Confirm、Cancel 三个方法成本高。如果事务中有其它公司的服务，也无法要求其它公司的服务也遵循 TCC 这种开发模式。同时流程长，事务边界太长，加锁时间长，会影响并发性能。\n所以 Saga 模式的适用场景是：\n 业务流程长、业务流程多； 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口； 典型业务系统：如金融网路（与外部机构对接）、互联网微贷、渠道整合、分布式架构下服务集成等业务系统； 银行业金融机构使用广泛； 其优势：\n 一阶段提交本地事务，无锁，高性能； 参与者可异步执行，高吞吐； 补偿服务易于实现，因为一个更新操作的反向操作是比较容易理解的； 其缺点：\n 不保证隔离性，后面我们会讲到如何应对隔离性的缺失。 基于状态机引擎的 Saga 实现 基于状态机引擎的 Saga 实现的基本原理：\n 通过状态图来定义服务调用的流程并生成 json 定义文件； 状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点（虚线关联的节点）； 状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚； 异常发生时是否进行补偿也可由用户自定义决定； 可以实现服务编排需求，路由、异步、重试、参数转换、参数映射、服务执行状态判断、异常捕获等功能 ； Seata 目前的 Saga 模式采用了状态机+DSL 方案来实现，原因有以下几个：\n 状态机+DSL 方案在实际生产中应用更广泛； 可以使用 Actor 模型或 SEDA 架构等异步处理引擎来执行，提高整体吞吐量； 通常在核心系统以上层的业务系统会伴随有“服务编排”的需求，而服务编排又有事务最终一致性要求，两者很难分割开，状态机+DSL 方案可以同时满足这两个需求； 由于 Saga 模式在理论上是不保证隔离性的，在极端情况下可能由于脏写无法完成回滚操作，比如举一个极端的例子，分布式事务内先给用户 A 充值，然后给用户 B 扣减余额，如果在给A用户充值成功，在事务提交以前，A 用户把线消费掉了，如果事务发生回滚，这时则没有办法进行补偿了，有些业务场景可 …","date":1578574800,"description":"本文根据 SOFAChannel#10 直播分享整理，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用","dir":"blog/sofa-channel-10-retrospect/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2ba15ca1c710e1be2e6758950246d1ee","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-10-retrospect/","publishdate":"2020-01-09T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-10-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#10 直播分享整理，主题：分布式事务 Seata 长事务解决方案 Saga 模式详解。 回顾视频以及 PPT 查看","tags":["Seata","SOFAChannel"],"title":"Seata 长事务解决方案 Saga 模式 | SOFAChannel#10 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-channel-10-retrospect/","wordcount":6186},{"author":"卫恒","categories":"SOFAArk","content":" 本篇开始将正式启动 SOFAArk:Lab/ 源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。\n本文为《剖析 | SOFAArk 源码》第一篇，本篇作者卫恒，SOFAArk 开源负责人。《剖析 | SOFAArk 源码》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附共建列表，欢迎领取共建~\n 在大型软件开发过程中，通常会推荐底层功能插件化、业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。对于模块化，从语言层面，原计划在 Java7 就有的模块化特性，终于在 Java9 里面提供了。在 Java语言级对模块化提供支持之前，业界内最知名的 Java 模块化规范当属 OSGi 了，直至到今天，OSGi 在众多企业、厂商中被广泛使用，比如我们常用的 Web 应用服务器、Eclipse 等均采用了 OSGi 规范。\n蚂蚁金服内部，CE 作为使用了 10 年的\u0026amp;rdquo;元老级\u0026amp;rdquo;容器组件，见证了和支撑了每年的大促、新春红包等流量场景。作为中间件的常青树，CE 以足够的稳定性为业务保驾护航。CE 容器也是基于 OSGi 实现了模块化，但是由于 CE 背负了太多包袱，使得其自身变得太重，在云原生及商业化输出上逐渐失去了优势。\n从 2016 年底开始，框架组内部开始在 CE 的基础上进行抽离和整合，开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2019 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\nSOFAArk 简介 SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin） 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz) 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz。 SOFAArk：https://github.com/sofastack/sofa-ark\n应用场景 基于模块化及模块的动态能力，SOFAArk 有非常丰富的落地场景，如：通过从 classloader 层面解决 依赖冲突问题、基于 arkcontainer 的多应用合并部署，基于动态 biz 的 SOFAServerless 等等。\n依赖冲突 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError、NoSuchMethodError 等；实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法，统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突；这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题；如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题； OSGi 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGi 框架太过臃肿，功能繁杂；为了解决包冲突问题，引入 OSGi 框架，有牛刀杀鸡之嫌，且反而使工程变得更加复杂，不利于开发。\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 – Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如果工程需要引入两个三方包：A 和 B，但是 A 需要依赖版本号为 0.1 的 C 包，而恰好 B 需要依赖版本号为 0.2 的 C 包，且 C 包的这两个版本无法兼容：\n此时，即可使用 SOFAArk 解决该依赖冲突问题；只需要把 A 和版本为 0.1 的 C 包一起打包成一个 Ark 插件，然后让应用工程引入该插件依赖即可。\n合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 - Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成可执行 Fat Jar 时，可以将其他应用 Biz 包一并打入，启动时，则会根据优先级依次启动各应用。每个 Biz 使用独立的 BizClassLoader 加载，不需要考虑相互依赖冲突问题，Biz 之间则通过 SofaService / SofaReference JVM 服务进行交互。\n 静态合并部署是将多个应用打包在一个 ARK 可执行 JAR 包中，然后通过 java -jar 启动，这种方式可以在 ARK 容器内同时运行多个应用，对于一些资源要求不高、流量较少的应用可以使用这种方式部署以节省资源。\n 动态模块 模块是 ark biz 在动态模型场景下的一种别名，其实质就是一个 ark biz 包。\n 动态模块相对于静态合并部署最大的不同点是，运行时通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态模块的设计理念图如下：\n无论是静态合并部署还是动态模块都会有宿主应用（master biz）的概念, 如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主应用不允许被卸载，一般而言，宿主应用 …","date":1578398400,"description":" 本文为《剖析 | SOFAArk 源码》第一篇，作者卫恒","dir":"blog/sofa-ark-overview/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"56bc84e9737dbad9c77b9700b12bf63d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-overview/","publishdate":"2020-01-07T20:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-ark-overview/","summary":"本篇开始将正式启动 SOFAArk:Lab/ 源码共建系列，在此对长期以来对 SOFAStack 关注的朋友表示感谢。 本文为《剖析 | SOFAArk 源码》第一篇，本篇作者卫恒，SOFAArk 开源负责人","tags":["SOFAArk","剖析 | SOFAArk 源码 ","SOFALab"],"title":"蚂蚁金服轻量级类隔离框架概述 | SOFAArk 源码解析","type":"blog","url":"/sofastack.tech/blog/sofa-ark-overview/","wordcount":3810},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\nSeata：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，其中长事务解决方案 Saga 模式有着无锁高性能、异步架构高吞吐的优势。\nSeata：https://github.com/seata/seata\nSaga 状态机在线设计器：http://seata.io/saga_designer/index.html\nSaga 状态机设计器视频教程：http://seata.io/saga_designer/vedio.html\n1、@李宇博 提问：\n 您好，我这边看视频直接把 Catch 直接拖到 serviceTask 上，好像没有生效，需要连线还是配置什么属性吗？\n A：没有生效是指什么？Catch 要连一个线到一个其它的 state，意思是捕获到异常后，去执行一个分支，这个 state可以是任何类型的 state，比如 CompensationTrigger、ServiceTask，通常是 CompensationTrigger，立即触发补偿。\n 我是直接连接到 compensateTrigger 上的，然后我手动抛出异常，并没有执行补偿方法，而是在不停的重试调用之前抛出异常的方法。\n A：需要在线上配置异常类型：\n2、@J～杰 提问：\n 咨询一个问题，AT 模式分支事物注册的时候会获取锁，锁名就是和 table+主键有关系的，由于压力测试的时候，有个 check 去数据库查询同一个 rowkey，导致直接获取锁失败，在业务上就是业务失败回滚了，这种有啥办法？\n A：你的意思是热点数据问题吗？\n 可以理解成热点数据，我这边的测试场景就是下单减库存，2个微服务，库存由于基本上是同一行库存数据。\n A：热点数据撞锁是正常的，你可以用自旋锁，让其它事务等待一下再获取锁，而不是立即失败。http://seata.io/zh-cn/docs/user/configurations.html\n 本地调用 Dubbo 微服务是可以的，用 Saga 状态机就报这个问题，报服务没有提供者。\n A：你的 Service 是用的 XML 注册的还是用的注解注册的？\n 注解的方式。\n A：嗯嗯。你尝试用 XML 方法注册一个 Bean 看看行不行，机制上可能有不一样，因为 Saga 状态机是通过 getBean 反射去调方法。而 Dubbo 的注解是通过代理的方式来注入一个对象，这个对象是不是一个有完全成功的 Bean，不确定。之前我遇到过 TCC 用注解不好使，用 XML 好使的问题。\n本周推荐阅读 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 SOFARegistryLab 系列 服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析 蚂蚁金服服务注册中心 Session 存储策略 | SOFARegistry 解析 蚂蚁金服服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.9.0 版本，主要变更如下： i. 重构了包引用路径，从 sofastack.io/sofa-mosn 变更为 mosn.io/mosn； ii. 支持变量机制，accesslog 修改为使用变量机制获取信息； iii. 修复在 proxy 协程 panic 时导致的内存泄漏； iv. 修复在特定的场景下，读写协程卡死导致的内存泄漏； v. 修复 HTTP2 Stream 计数错误的 bug；\n详细发布报告：https://github.com/mosn/mosn/releases/tag/0.9.0\n社区直播预告 新年快乐~2020年第一期线上直播来啦，SOFAChannel#10 将和大家一起探讨 《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\n主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解\n时间：2020年1月9日（下周四）19:00-20:00\n嘉宾：陈龙（花名：屹远） 蚂蚁金服分布式事务核心研发、Seata Committer\n形式：线上直播\n报名方式：点击“这里”，即可报名\n","date":1578038400,"description":"【12/31-01/03】 | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20200103/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"aa8f76ccca9d7d700e3d9b16c2b0df21","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200103/","publishdate":"2020-01-03T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20200103/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 1.9直播预告、MOSN 发版、Saga 状态机设计器视频教程","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20200103/","wordcount":1862},{"author":"米麒麟","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第六篇，本篇作者子懿，来自阿里云。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n前言 微服务架构为了保证所有服务可用，当服务发生问题时能及时摘除有问题的服务，需要定期检测服务可用性即健康检测。健康检测包括客户端心跳和服务端主动探测两种方式，定期发送 TCP 或 HTTP 请求根据响应确定服务是否正常。服务注册中心提供服务注册和订阅服务，在服务发布者服务信息发生变化、或者节点上下线时通知变更，动态更新消费方的服务地址列表信息，支持服务注册和下线的快速变更通知。\n本文重点围绕服务的健康检测、SOFARegistry 的健康检测以及基于 SOFARegistry 实现秒级服务注册下线等方面剖析 SOFARegistry 如何实现秒级服务上下线通知原理，阐述如何使用 SOFARegistry 对于服务的注册下线场景通过推送机制快速实现端到端的传达功能：\n 如何实现服务的健康检测？业界服务注册中心的健康机制是怎样的？SOFARegistry 的健康检测实现方式？ SOFARegistry 服务注册下线数据流转过程是怎样的？SOFARegistry 内部角色如何实现秒级服务上下线通知？ 服务的健康检测 服务的健康检测是如何实现？健康检测分为客户端心跳和服务端主动探测两种方式：\n 客户端心跳 客户端采取每隔一定时间间隔主动发送心跳方式向服务端表明自己的服务状态正常，心跳是 TCP 或者 HTTP 的形式； 通过维持客户端和服务端的 Socket 长连接自己实现客户端心跳的方式； ZooKeeper 没有主动的发送心跳，而是依赖组件本身提供的临时节点的特性，通过 ZooKeeper 连接的 Session 维持临时节点； 客户端心跳中长连接的维持和客户端的主动心跳偏重服务链路是否正常，不一定是服务状态正常；服务端主动调用服务健康检查是比较准确的方式，通过返回结果成功判断服务状态健康情况； 服务端主动探测 服务端调用服务发布者 HTTP 接口来完成健康检测； 对于没有提供 HTTP 服务的 RPC 应用，服务端调用服务发布者的接口来实现健康检测； 通过执行脚本形式来进行定时检测； 服务端主动探测依然存在问题。服务注册中心主动调用 RPC 服务的某个接口无法做到通用性；在很多场景下服务注册中心到服务发布者的网络是不通的，服务端无法主动发起健康检查； 注册中心的健康检测 业界服务注册中心的健康检测机制：\n Eureka：定期有 Renew 心跳，数据具有 TTL（Time To Live）；并且支持自定义 HealthCheck 机制，当 HealthCheck 检测出系统不健康时主动更新 Instance 的状态； Zookeeper：定期发送连接心跳以保持会话 （Session），会话本身 （Session） 具有TTL； Etcd：定期通过 HTTP 对数据进行 Refresh，数据具有 TTL。申请 Lease 租约，设置服务生存周期TTL； Consul：Agent 定期对服务进行 healthcheck，支持 HTTP/TCP/Script/Docker；由服务主动定期向 agent 更新 TTL； SOFARegistry 的健康检测 业界服务注册中心的健康检测都有个共同的关键词：“定期”。定期检测的时间周期通常设置为秒级，比如 3 秒、5 秒或 10 秒，甚至更长，也就是说服务的健康状态总是滞后的。蚂蚁金服的注册中心从最初的版本设计开始，就把健康状态的及时感知，当做一个重要的设计目标，特别是需要做到“服务宕机能被及时发现”。因此 SOFARegistry 在健康检测的设计方面决定“服务数据与服务发布者的实体连接绑定在一起，断连马上清数据”，简称此特点叫做连接敏感性。连接敏感性是指在 SOFARegistry 里所有 Client 都与 SessionServer 保持长连接，每条长连接都设置基于 SOFABolt 的连接心跳，如果长连接断连客户端立即发起重新建连，时刻保持 Client 与 SessionServer 之间可靠的连接。\nSOFARegistry 将服务数据 （PublisherRegister） 和服务发布者 （Publisher） 的连接的生命周期绑定在一起：每个 PublisherRegister 定义属性 connId，connId 由注册本次服务的 Publisher 的连接标识 （IP 和 Port）构成，也就是只要该 Publisher 和 SessionServer 断连，服务信息数据即失效。客户端重新建连成功后重新注册服务数据，重新注册的服务数据会被当成新的数据，考虑更换长连接后 Publisher 的 connId 是 Renew 新生成的。\n譬如当服务的进程宕机时，一般情况下 OS 立刻断开进程相关的连接（即发送 FIN），因此 SessionServer 能够实时感知连接断开事件，然后把该 connId 相关的所有 PublisherRegister 都清除，并且及时推送给所有服务订阅者 （Subscriber）。如果只是网络问题导致连接断开，实际的服务进程没有宕机，此时客户端立即发起重新连接 SessionServer 并且重新注册所有服务数据。对服务订阅者本身来说接收到的是服务发布者经历短暂的服务下线后以及再次重新上线。假如此过程耗时足够短暂（例如 500ms 内发生断连和重连），服务订阅者可能感受不到服务下线，因为 DataServer 内部的数据通过 mergeDatum 延迟合并变更的 Publisher 服务信息，version 是合并后最新的版本号。\n服务上下线过程 服务的上下线过程是指服务通过代码调用执行常规注册（Publisher#register） 和下线（Publisher#unregister）操作，不考虑因为服务宕机等意外情况导致的下线场景。\n“一次服务注册过程”的服务数据在 SOFARegistry 内部流转过程：\n 客户端 Client 调用服务发布者 Publisher 的 register 向 SessionServer 注册服务。 SessionServer 接收到服务数据即 PublisherRegister 写入内存 （SessionServer 存储 Client 的服务数据到内存，用于后续跟 DataServer 做定期检查）， …","date":1577955600,"description":" 本文为《剖析 | SOFARegistry 框架》第六篇，作者米麒麟","dir":"blog/sofa-registry-service-offline-notification/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"289ee5ccb8ee61cdd0a42ce60874284b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-service-offline-notification/","publishdate":"2020-01-02T17:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-service-offline-notification/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心如何实现秒级服务上下线通知 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-service-offline-notification/","wordcount":4114},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解\n 活动时间：1 月 9 日周四晚 7 点\n 活动形式：线上直播\n 活动回顾：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，其中长事务解决方案 Saga 模式有着无锁高性能、异步架构高吞吐的优势。\n本期为 SOFAChannel 线上直播第 10 期，将邀请 蚂蚁金服 分布式事务核心研发 \u0026amp;amp; Seata Committer 屹远 和大家一起探讨 《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23372465（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1076\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服 Service Mesh 双十一落地详解 屹远 蚂蚁金服分布式事务核心研发、Seata Committer\n本期分享大纲： 金融分布式应用开发的痛点 Seata Saga 理论基础以及使用场景 基于状态机引擎的 Saga 实现 Seata Saga 模式最佳实践以及优势 嘉宾 SOFAGirl 主持人 屹远 蚂蚁金服分布式事务核心研发、Seata Committer ","date":1577765400,"description":"1 月 9 日周四晚 7 点，线上直播第 10 期。","dir":"activities/sofa-channel-10/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a2f7bb983d4cbad1bda1a48a3c99abb7","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-10/","publishdate":"2019-12-31T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-10/","summary":"概要 活动主题：SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解 活动时间：1 月 9 日周四晚 7 点 活动形式：线上直播 活动回顾：戳这","tags":["SOFAChannel","Seata"],"title":"SOFAChannel#10：分布式事务 Seata 长事务解决方案 Saga 模式详解","type":"activities","url":"/sofastack.tech/activities/sofa-channel-10/","wordcount":627},{"author":"董一韬、王轲","categories":null,"content":" 本文推荐知道的背景知识：\n Kubernetes 的基本原理和各大组件的职责； Serverless 计算的基本概念和它的优势； Plus: 对社区 Knative 项目的基本了解； 本文根据董一韬和王轲在 KubeCon NA 2019 大会分享整理。\n董一韬 蚂蚁金服，产品经理，致力于驱动云计算相关产品，包括云原生 PaaS 平台、容器与 Serverless 产品等，与最终顾客紧密合作，帮助客户在规模化的金融场景下采用与落地云原生相关解决方案。\n王轲 蚂蚁金服，软件工程师，建设基于 Kubernetes/Knative 的企业级 Serverless 产品，Knative 的早期使用者，Kubernetes 社区成员、控制面流控早期维护者，长期致力于用创新的方式优化、落地云原生技术。\n一. 分享概要 Knative 是 Google 主导的基于 Kubernetes 的 Serverless 平台，在社区上有较高的知名度。然而，身为社区项目的 Knative 主要关心的是标准、架构。虽有先进的理念，却离可在生产上使用有不少的差距。\n本次 KubeCon 的演讲中，来自蚂蚁金服 SOFAStack-PaaS 平台产品技术团队的隐秀和仲乐与大家分享蚂蚁金服金融科技 Knative 的实践和改造：基于 Knative 构建一个优秀的 Serverless 计算平台，详细分析如何用独特的技术，解决性能、容量、成本三大问题。\n从 Serverless 计算的应用场景开始，提炼客户真正的 Use Case，分公有云、私有云、行业云等，讲述 Serverless 计算的多种用途。之后我们将介绍在 Kubernetes 上运行 Knative 平台的方案，详细介绍要使其生产可用，不得不克服的问题。演讲最后，将刚刚的这些问题一一攻破，做出一个比社区版本优秀的 Knative 平台。\n二. 解决性能问题：使用 Pod 预热池 熟悉 Kubernetes 的同学可能知道，Kubernetes 的首要目标并不是性能。\n在一个大规模的 Kubernetes 集群下，要创建一个新的 Pod 并让它跑起来，是很慢的。这是因为这整个链路很长：先要向 APIServer 发一个 POST 请求，再要等 Scheduler 收到新 Pod 资源被创建的事件，再等 Scheduler 在所有的 Node 上运行一遍筛选、优选算法并把调度结果返回给 API Server，再到被选中 Node 的 Kubelet 收到事件，再到Docker 镜像拉取、容器运行，再到通过安全检查并把新的容器注册到 Service Mesh 上…\n任何一个步骤都有可能出现延时、丢事件，或失败（如调度时资源不足是很常见的）。就算一切都正常工作，在一个大规模的 Kubernetes 集群里，整个链路延时达到20s，也是很常见的。\n这便导致在 Kubernetes 上做 Serverless 的窘境：Serverless 的一大特点是自动扩缩容，尤其是自动从0到1，不使用时不占任何资源。但如果一个用户用 Serverless 跑自己的网站/后端，但用户的首个请求花费20s才成功，这是无法接受的。\n为了解决冷启性能问题，我们团队提出了一个创造性的解决方案：使用 Pod 预热池（Pod Pool）。\n我们的产品会预先创建许多个 Pod 并让它们运行起来，当 Kubernetes 的控制器希望创建一个新的 Pod 的时候，我们不再是从零开始新建一个 Pod，而是找到一个处于待命状态的符合条件的 Pod，并把代码注入这个 Pod，直接使用。\n在演讲中，我们分享了一定技术实现的细节，例如如何创建 CRD 并 fork Kubernetes 的 ControllerManager，来以较小的成本实现新 Workload；如何自动根据历史的使用数据来自动伸缩 Pod 池的水位；如何做代码注入等。我们提了3种方式，分别是给容器发指令让容器中的进程下载并执行代码包、使用 Ephemeral Container、魔改 Kubelet允许替换 Container。\n实际的实现比这个还要复杂，要考虑的问题更多，例如如何响应 Pod 中不同的资源 request、limit。我们实际上也实现了一个调度器。当某个预热好的 Pod 不能满足，会看那个 Pod 所在 Node 上的资源余量，如果余量够则动态改 Kubernetes 控制面数据和 cgroups，实现“垂直扩容”。\n实际操作证明，这个冷启优化的效果非常好，当 Pod 大小固定、代码包缓存存在时，启动一个最简单的 HTTP 服务器类型应用的耗时从近20秒优化到了2秒，而且由于不需要当场调度 Pod，从0到1的稳定性也提升了很多。\n这个优化主要是跳过了若干次 API Server 的交互、Pod Schedule 的过程和 Service Mesh 注册的过程，用户程序从零到一的体验得到极大的提升，又不会招致过多的额外成本。一般来讲多预留10-20个 Pod 就可以应付绝大多数情况，对于少见的短时间大量应用流量激增，最坏情况也只是 fallback 到原先的新创建 Pod 的链路。\nPod 预热池不光可以用来做冷启优化，还有很多其他的应用场景。演讲中我呼吁将这种技术标准化，来解决 Kubernetes 数据面性能的问题。会后有观众提出 cncf/wg-serverless 可能有兴趣做这件事情。\n三. 降低成本：共享控制面组件 在成本方面，我们和大家分享了多租户改造和其他的降低成本的方式。\n如果以单租户的方式运行社区版的 Knative，成本是昂贵的：需要部署 Kubernetes 控制面和 Service Mesh 控制面，因为这些都是 Knative 的依赖，Knative 本身的控制面也很占资源。十几C几十G 的机器就这样被使用了，不产生任何业务价值。因此，共享这些控制面的组件是非常必要的。\n通过共享，用户不必再单独为基础设施买单。控制面的成本也只和每个租户创建的应用的数量之和有关，而不会再和租户多少产生关联。\n我们推荐两种共享的方式，一种是 Namespace 隔离+ RBAC 权限控制，这种控制面共享的方法是最简单、Kubernetes 原生支持，也广为使用的一种方法。另一种方法是蚂蚁金服金融科技自研 Kubernetes 实现的多租户方案，通过在 etcd 中多加一级目录并把每个用户的数据存在他们自己的目录中，实现真正全方位多租户的 Kubernetes。\n演讲中还提到了其他的一些降低成本的方法，如通过 Virtual Kubelet 对接阿里云的 ECI（按需的容器服务）、通过 Cluster AutoScaler 来自动释放使用率低的 Kubernetes 节点或从阿里云购置 ECS 来增加新的节点以水平扩容等。还简单提了一下多个租户的容器共享同一个宿主机可能面临的安全问题，如 Docker 逃逸。一种可能的解决方法是使用 Kata Container（虚拟机）以避免共享 Linux 内核。\n四. 解决容量问题：每个层级都做好对分片的支持 容量方面的挑战在于当 Workload 数量增多后， …","date":1577707200,"description":" 本文基于 Knative 构建一个优秀的 Serverless 计算平台，详细分析如何用独特的技术，解决性能、容量、成本三大问题。","dir":"blog/knative-serverless-kubecon-na2019/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ceeb7bee775048b0c23fe553fc5cd335","permalink":"https://sofastack.github.io/sofastack.tech/blog/knative-serverless-kubecon-na2019/","publishdate":"2019-12-30T20:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/knative-serverless-kubecon-na2019/","summary":"本文推荐知道的背景知识： Kubernetes 的基本原理和各大组件的职责； Serverless 计算的基本概念和它的优势； Plus: 对社区 Knative 项目的基本了解； 本文根据董一韬和王轲在 KubeCon NA 2019 大会","tags":["Knative","Serverless"],"title":" 基于 Knative 打造生产级 Serverless 平台 | KubeCon NA2019","type":"blog","url":"/sofastack.tech/blog/knative-serverless-kubecon-na2019/","wordcount":3400},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News SOFAStack 社区上线了 SOFA Community 试运行方案，欢迎社区内更多的同学参与我们，加入共建❤\n社区随时都欢迎各种贡献，无论是简单的错别字修正、bug 修复还是增加新功能，欢迎提 issue 或 pull request 至 Github 社区。\nSOFA Community 期待你的加入：https://www.sofastack.tech/community/\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@包和平 提问：\n 请问 Seata Saga 状态机可以跨服务来配置吗？案例中的 springcloud-eureka-feign-mybatis-seata 这个和我们的情况类似。这个默认的不是 AT 模式吗？我想使用 Saga 的状态机来配置整个流程，这个情况就涉及了三个服务 storage order account，我看 demo 中都是在单个服务中配置的状态机，所以想询问一下怎么配置。 A：可以跨服务调用，而且服务用不同的 RPC 框架也是可以的，Saga 的事例在 seata-sample 仓库有，Seata 仓库的 test 模块也有很多事例。文档地址：http://seata.io/zh-cn/docs/user/saga.html\n 有 Saga 模式的 spring feign 方式的配置 demo 吗？\n A：没有，不过 Seata Saga 只需要是一个 bean 就可以调用，理论上和什么 RPC 框架无关。\n A 服务的状态机 a_state.json 设置的子状态机是在 B 服务上配置的 b_state.json，可以这样设置吗？\n A：A 服务如果是通过状态机实现的，例如 a_state.json，这个状态机可以调用 B 服务，B 服务也可以是状态机实现的，例如 b_state.json，这两个状态机都不是子状态机，而 a_state.json 其实只知道调到了一个服务，而它内部是什么实现的它不知道。子状态机是要再同一个应用内，才可以被其它状态机调用，跨了应用，则认为只是一个服务。\n Seata 还支持其他方式实现 Saga？ 我看好像都是状态机呢，是我遗漏了哪里吗?\n A：目前是只有状态机。未来会有通过注解+拦截器实现。我所说的“A 服务如果是通过状态机实现的”，服务的实现是可以任何方式的，不是 Saga 的实现。实现一个服务，自己编码也能实现，和框架无关。\n 这个意思其实只是在 A 中调用了 feignClient 是这个意思吧?\n A：是的。\n2、@李宇博 提问：\n Saga 状态机设计器很多属性和文档不太一样呢。\n A：没有和文档不一致的属性吧。你看到的设计器生成的 json，是因为它带了布局信息，它的 stateProps 是和文档是一致的，其它属性是设计器生成的，不需要关心。\n 我没有找到 startState 属性，然后我以为要自己写 next 属性，好像是连线解决了这个问题，还有一点不太明白，就是一个事务只用设计一个 compensationTrigger么？\n A：是的，是用 Start 后面的连线解决，所以不需要 startState 属性了。 compensationTrigger 可以有任意多个，看怎么画好看就行。\n start、success、fail、choice 节点都省去了配置么？还有 compensationtrigger。\n A： Start 里有配置状态机的名称，描述，版本什么的、fail 里可以配置错误码和错误信息，succed 和 choice 应该只有一个名称，没其他的了。\n 嗯嗯，compensationTrigger 是不是也不用配置了?\n A：不用，也是 id 不重就行。\n3、@赵润泽 提问：\n TCC 模式下的事务发起者和 AT 模式下的事务发起者，被代理后执行的操作是一样的吗？\n A：TccActionInterceptor 拦截的是 TwoPhaseBusinessAction 注解也就是拦截的是分支事务，在之前 TM 已经做了 begin，这个是通过 GlobalTransactional 的 intercept 开启的。\n TCC 事务的开启和 AT 事务的开启流程是一样的吗，毕竟都是一个注解？\n A： 是一样的，都是发起方加 GlobalTransactional 注解，对于 TCC 分支来说都要额外加一个 TwoPhaseBusinessAction 注解。\n本周推荐阅读 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 社区活动预告 就在明天，Service Mesh Meetup 第9期杭州站，本期与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用，现场还有机会获得 Istio 官方 T 恤 以及 相关技术书籍。明天，不见不散~\n主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond\n时间：2019年12月28日（明天）13:00-17:30\n地点：杭州西湖区紫霞路西溪谷G座8楼\n报名方式：点击“这里”，即可报名\n","date":1577430000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191227/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"026916366f7c75abaf698dabaed81047","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191227/","publishdate":"2019-12-27T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191227/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 明日活动信息、社区方案上线、落地系列阅读","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191227/","wordcount":1949},{"author":"封尘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，本次主题主要分享在蚂蚁金服当前的体量下，控制面平稳支撑大规模 Sidecar 的落地实践。聚焦控制面核心组件 Pilot 和 Citadel，分享蚂蚁金服双十一控制面如何管理并服务好全站 Sidecar。\n本次分享主要分为两大部分，分别是：\n Pilot 落地实践； Citadel 安全加固； Pilot 落地实践 在开始分享落地实践之前，我们先来看看 Istio 的架构图：\n理想很丰满，现实很骨感。由于性能等方面的综合考虑，我们在落地过程中，将控制面的组件精简为 Pilot 和 Citadel 两个组件了，不使用因性能问题争议不断的 Mixer，不引入 Galley 来避免多一跳的开销。\n在架构图中，控制面组件 Pilot 是与 Sidecar 交互最重要的组件，负责配置转化和下发，直面 Sidecar 规模化带来的挑战。这也是双十一大促中，控制面最大的挑战。\n规模化的问题在生产实践中，是一个组件走向生产可用级的必经之路。接下来将会分别从稳定性、性能优化、监控这三个方面分别展开。\n稳定性增强 我们先梳理下 Pilot 提供的服务能力，从功能实现上来看，Pilot 是一个 Controller + gRPC Server 的服务，通过 List/Watch 各类 K8s 资源，进行整合计算生成 XDS 协议的下发内容，并提供 gRPC 接口服务。本次分享我们先把关注点放在 gRPC 接口服务这个环节，如何保证接口服务支撑大规模 Sidecar 实例，是规模化的一道难题。\n负载均衡\n要具备规模化能力，横向扩展能力是基础。Pilot 的访问方式我们采用常用的 DNSRR 方案，Sidecar 随机访问 Pilot 实例。由于是长连接访问，所以在扩容时，原有的连接没有重连，会造成负载不均。为解决这个问题，我们给 Pilot 增加了连接限流、熔断、定期重置连接功能，并配合 Sidecar 散列重连逻辑，避免产生连接风暴。\n 连接限流 为了降低大量 MOSN 同时连接同一个 Pilot 实例的风险，在 gRPC 首次连接时，Pilot 增加基于令牌桶方案的流控能力，控制新连接的处理响应，并将等待超时的连接主动断连，等待 Sidecar 下一次重连。\n 熔断 基于使用场景的压测数据，限制单实例 Pilot 同时可服务的 Sidecar 数量上限，超过熔断值的新连接会被Pilot 主动拒绝。\n 定期重置 为了实现负载均衡，对于已经存在的旧连接，应该怎么处理呢？我们选择了 Pilot 主动断开连接，不过断开连接的周期怎么定是个技术活。要考虑错开大促峰值，退避扩缩容窗口之类，这个具体值就不列出来了，大家按各自的业务场景来决定就好了。\n Sidecar 散列重连 最后还有一点是 Client 端的配合，我们会控制 Sidecar 重连 Pilot 时，采用退避式重试逻辑，避免对 DNS 和 Pilot 造成负载压力。\n性能优化 规模化的另一道难题是怎么保证服务的性能。在 Pilot 的场景，我们最关注的当然是配置下发的时效性了。性能优化离不开细节，其中部分优化是通用的，也有部分优化是面向业务场景定制的，接下来会分享下我们优化的一些细节点。\n 首次请求优化 社区方案里 Pilot 是通过 Pod.Status 来获取 Pod 的 IP 信息，在小集群的测试中，这个时间基本秒级内可以完成。然而在大集群生产环境中，我们发现 Status 的更新事件时间较慢，甚至出现超过 10s 以上的情况，而且延迟时间不稳定，会增加 Pilot 首次下发的时延。我们通过与基础设施 K8s 打通，由 PaaS 侧将 Pod 分配到的 IP 直接标记到Pod.Annotation 上，从而实现在第一次获取 Pod 事件时，就可以获取到 IP，将该环节的时延减少到0。\n 按需获取 \u0026amp;amp; Custom Resource 缓存 这是一个面向 DBMesh 业务场景的定制性优化，是基于按需获取的逻辑来实现的。其目的在于解决 DBMesh CR 数量过多，过大导致的性能问题，同时避免 Pilot 由于 List/Watch CR 资源导致 OOM 问题，Pilot 采用按需缓存和过期失效的策略来优化内存占用。  局部推送 社区方案中当 Pilot List/Watch 的资源发生变更时，会触发全部 Sidecar 的配置推送，这种方案在生产环境大规模集群下，性能开销是巨大的。举个具体例子，如果单个集群有 10W 以上的 Pod 数量，任何一个 Pod 的变更事件都会触发全部 Sidecar 的下发，这样的性能开销是不可接受的。\n优化的思路也比较简单，如果能够控制下发范围，那就可以将配置下发限制在需要感知变更的 Sidecar 范围里。为此，我们定义了 ScopeConfig CRD 用于描述各类资源信息与哪些 Pod 相关，这样 Pilot 就可以预先计算出配置变更的影响范围，然后只针对受影响的 Sidecar 推送配置。\n 其他优化 强管控能力是大促基本配备，我们给 Pilot Admin API 补充了一些额外能力，支持动态变更推送频率、推送限流、日志级别等功能。\n监控能力 安全生产的基本要求是要具备快速定位和及时止血能力，那么对于 Pilot 来说，我们需要关注的核心功能是配置下发能力，该能力有两个核心监控指标：\n 下发时效性 针对下发的时效性，我们在社区的基础上补充完善了部分下发性能指标，如下发的配置大小分布，下发时延等。\n 配置准确性 而对于配置准确性验证是相对比较复杂的，因为配置的准确性需要依赖 Sidecar 和 Pilot 的配置双方进行检验，因此我们在控制面里引入了 Inspector 组件，定位于配置巡检，版本扫描等运维相关功能模块。\n配置巡检的流程如下：\n Pilot 下发配置时，将配置的摘要信息与配置内容同步下发； MOSN 接收配置时，缓存新配置的摘要信息，并通过 Admin API 暴露查询接口； Inspector 基于控制面的 CR 和 Pod 等信息，计算出对应 MOSN 的配置摘要信息，然后请求 MOSN 接口，对比配置摘要信息是否一致； 由于 Sidecar 的数量较大，Inspector 在巡检时，支持基于不同的巡检策略执行。大体可以分为以下两类：\n 周期性自动巡检，一般使用抽样巡检； SRE 主动触发检查机制； Citadel 安全方案 证书方案 Sidecar 基于社区 SDS 方案 （Secret Discovery Service），支持证书动态发现和热更新能力。同时蚂蚁金服是一家金融科技公司，对安全有更高的要求，不使用 Citadel 的证书自签发能力，而是通过对接内部 KMS 系统获取证书。同时提供证书缓存和证书推送更新能力。\n我们先来看看架构图，请看图：\n对整 …","date":1577271600,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，聚焦控制面核心组件 Pilot 和 Citadel，分享蚂蚁金服双十一控制面如何管理并服务好全站 Sidecar。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f7e9ad6fafaa6db46864cf0704d2b145","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","publishdate":"2019-12-25T19:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第七篇 - 控制面篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 控制面篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/","wordcount":3783},{"author":"徐迪、张晓宇","categories":null,"content":" 图为 KubeCon NA 2019 大会分享现场照\nSpeaker:\n 徐迪 蚂蚁金服技术专家：负责蚂蚁金融云PaaS平台建设，Kubernetes 社区老兵，核心代码库贡献量社区前50； 张晓宇 阿里云技术专家：负责阿里巴巴云原生应用容器平台的生态建设，主要设计和研发节点稳定性和资源利用率相关解决方案，同时也是 Kubernetes 社区热心的成员和贡献者。 本文根据徐迪和张晓宇在 KubeCon NA2019 大会分享整理。分享将会从以下几个方面进行切入：首先会简单介绍一下什么是 Sidecar 容器；其次，我们会分享几个蚂蚁金服和阿里巴巴集团的通用场景，以及我们是如何解决这些挑战的。当然，现在还是有很多的挑战需要后续继续解决，邀请大家与我们一同努力。\nSidecar 简介 Sidecar 容器并不是一个新鲜事物。它是一种设计模式，主要用来做一些辅助的工作，比如网络连通性、下载拷贝文件之类的事情；如果大家熟悉 Docker Swarm 的话，就会发现 Docker Ambassador 其实就是 Sidecar。\n看看如上这个例子，Service Consumer 和 Redis Provider 强耦合，部署在同一个节点上。如果这个时候，Redis Provider 出现问题，需要连接到另外一个 Redis 实例上，需要重新配置，并重启 Service Provider。\n那么在引入了 Ambassador 以后，问题变得相对简单些，只需要重启这里的 Redis Ambassador 即可，并不需要 Service Consumer 进行任何变动。\n当然这种模式，还可以进行跨节点通信，比如下图。这样 Service Consumer 和 Redis Provider 就可以部署在不同的节点上。在某种程度上，很容易地就将两种服务进行了解耦。\nSidecar 案例分享 Sidecar 容器能用来干什么？ 一般来讲，Sidecar 容器可以：\n 日志代理/转发，例如 fluentd； Service Mesh，比如 Istio，Linkerd； 代理，比如 Docker Ambassador； 探活：检查某些组件是不是正常工作； 其他辅助性的工作，比如拷贝文件，下载文件等； \u0026amp;hellip; 仅此而已？ 事实上，Sidecar 越来越被大家接受，并且使用越来越广泛。Sidecar 容器通常和业务容器（非 Sidecar 容器）部署在同一个 Pod 里，共享相同的生命周期，为业务容器提供辅助功能。这是一个非常好的模式，能够极大程度解耦应用，并且支持异构组件，降低技术壁垒。\n但目前 Kubernetes 对 Sidecar 的管理还不完善，越来越不满足我们的使用，尤其是在生产环境中使用 Sidecar。\n几个典型案例 1. 顺序依赖 假设我们在一个 Pod 内注入了多个 Sidecar，但是 Sidecar 之间或者 Sidecar 和业务容器之间有相互依赖关系。\n如下这个例子，我们需要先启动 proxy Sidecar 容器用于建立网络连接，这样 mysql client 才能连接到远端的 mysql 集群，并在本地暴露服务。而后主的业务容器才能正常工作。\n#1 proxy_container (sidecar) #2 mysql_client #3 svc_container 当然，有的人会觉得这个地方，可以通过诸如更改镜像启动脚本延迟启动等方法来解决。但是这些方法侵入性太强，不利于扩展，还很难进行准确的配置。\n2. Sidecar 管理 我们来看看另外一个案例。Sidecar 容器和业务容器耦合在同一个 Pod 内，共享相同的生命周期。因此，单独来管控 Sidecar 容器非常不方，比如更新 Sidecar 的镜像。\n比如，我们已经给很多 Pod 注入了 Istio Proxy 这样的 Sidecar 容器，目前运行状态良好。但是如果这个时候我们想升级这个 Proxy 镜像的话，该怎么办？\n如果按照 Istio 社区官方的文档，我们需要重新注入这些 Sidecar 容器。具体来说，需要删除原有 Pod，重新生成一份新的 Pod（有些 workload 关联的 Pod，会由相应的 workload 控制器自动生成）。\n那如果我们有很多个这样的 Pod 需要处理的话，怎么办？通过命令行的话，太不方便，而且容易出错。通过自己单独写的代码的话，可扩展性是个问题，需要频繁更改这些代码。\n而且这里还有另外一个问题，我们肯定不会一下子升级所有的 Sidecar，肯定要有个灰度的过程，也就是只升级一部分 Sidecar，这个时候又该怎么办呢？\n社区进展 上游社区 这里我们非常感谢 Joseph Irving (@Joseph-Irving) 提出了一个 Sidecar kep，通过定义 LifecycleType 来区分是否是 Sidecar 容器。\ntype Lifecycle struct { // Type // One of Standard, Sidecar. // Defaults to Standard // +optional Type LifecycleType `json:\u0026amp;quot;type,omitempty\u0026amp;quot; protobuf:\u0026amp;quot;bytes,3,opt,name=type,casttype=LifecycleType\u0026amp;quot;` } // LifecycleType describes the lifecycle behaviour of the container type LifecycleType string const ( // LifecycleTypeStandard is the default container lifecycle behaviour LifecycleTypeStandard LifecycleType = \u0026amp;quot;Standard\u0026amp;quot; // LifecycleTypeSidecar means that the container will start up before standard containers and be terminated after LifecycleTypeSidecar LifecycleType = \u0026amp;quot;Sidecar\u0026amp;quot; ) 未来只需要在 Pod Spec 中，按如下方式标记即可：\nname: sidecarContainer image: foo lifecycle: type: Sidecar Pod 内容器的启动顺序按照：初始化容器-\u0026amp;gt;Sidecar 容器-\u0026amp;gt;业务容器 的顺序依次启动。\n其中上述 kep 的 kubelet 端实现 正在进行中。\n为了支持 Sidecar 更多的使用场景，我们以此为基础提出了 PreSidecar 和 PostSidecar，分别用于在业务容器之前和之后启动。具体的使用场景见 我们的 PR。\n为什么我们觉得 Sidecar 应该区分前置和后置呢？\n这是因为在一些场景下， …","date":1577188800,"description":" 本文主要介绍了什么是 Sidecar 容器，蚂蚁金服和阿里巴巴集团的通用场景，以及我们是如何解决这些挑战的。","dir":"blog/sidacar-kubecon-na2019/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"db0769ed83607e39fba6020d4eba87b8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sidacar-kubecon-na2019/","publishdate":"2019-12-24T20:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sidacar-kubecon-na2019/","summary":"图为 KubeCon NA 2019 大会分享现场照 Speaker: 徐迪 蚂蚁金服技术专家：负责蚂蚁金融云PaaS平台建设，Kubernetes 社区老兵，核心代码库贡献量社区前50； 张","tags":["Sidecar 容器"],"title":" 将 Sidecar 容器带入新的阶段 | KubeCon NA 2019","type":"blog","url":"/sofastack.tech/blog/sidacar-kubecon-na2019/","wordcount":2993},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@番番 提问：\n MOSN 的配置信息在哪里呢？\n A：MOSN 配置信息已更新到文档中：https://www.sofastack.tech/projects/sofa-mosn/configuration/overview/\n2、@古月 提问：\n 请问 SOFARPC 服务注册 ip 怎么使用主机 ip，不使用分配给容器的 ip？开发时调用容器内的服务调用不到，容器内的服务注册 ip 为 docker 分配的 ip。\n A：https://www.sofastack.tech/projects/sofa-rpc/application-rpc-config/ com.alipay.sofa.rpc.enabled.ip.range # 多网卡 ip 范围 com.alipay.sofa.rpc.bind.network.interface # 绑定网卡 可以通过网卡/ip段过滤；\nSOFARPC：https://github.com/sofastack/sofa-rpc\n SOFABoot 的服务运行在容器内，注册到注册中心的 ip 为容器的 ip，开发机器的调用不到。\n A：下面的两个参数，容器内端口映射到宿主机，virtual.host 用宿主机的去注册， com.alipay.sofa.rpc.virtual.host com.alipay.sofa.rpc.virtual.port\nSOFABoot：https://github.com/sofastack/sofa-boot\n3、@聂风 提问：\n SpringCloud 的项目怎么迁移到 SOFA 有这方面的教程文档吗？\n A：可以先参考下这个工程 https://github.com/sofastack/spring-cloud-sofastack-samples ，SOFAStack 集成 SpringCloud 的案例工程，不知道是不是对你有帮助。\n4、@周小斌 提问：\n Seata 以后会考虑集成分库分表和读写分离功能吗（无业务入侵的方式）？\n A：一般是分库分表组件内部中集成 Seata，负载均衡本质上是在切换数据源，一种是通过 DB URL 这种对外是个黑盒，Seata 不需要关注。另外一种是分库分表组件中使用配置中心做对等库物理库配置，这种需要通过 Resource 的 Group 来定义，比如我在一个节点上执行完一阶段，但是在进行二阶段的时候进行了主备切换，这时候需要在新主节点完成回滚。\n5、@温明磊 提问：\n Saga 项目开启时间长了后，会报 java.sql.SQLException: No operations allowed after statement closed. 这个错误。这个类 DbAndReportTcStateLogStore 方法 recordStateMachineStarted。\n A：是不是因为你的数据源连接池配置有问题呢？可能没有配置 testOnBorrow 或者 testOnReturn。\n 是没有。\n A：你配置一个 testOnBorrow。\n 那能不能在数据库连接的代码里判断，还是必须配置 testOnBorrow？Seata Saga 的数据库连接那代码处理异常。\n A：testOnBorrow 是数据源连接池的配置，和 Seata Saga 无关的，连接池你可以用任何连接池，比如 durid，dbcp。\nSeata：https://github.com/seata/seata\n本周推荐阅读 蚂蚁金服 ZSearch 在向量检索上的探索 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 Occlum v0.8.0 版本，主要变更如下：\n 重构 futex 实现，增加 FUTEX_REQUEUE 支持 支持 SGX 远程证明 增加 sendmsg 和 recvmsg 系统调用 增加 gRPC demo 增加 Intel OpenVINO demo 增加 SGX 远程证明 demo 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.8.0\n2、发布 SOFABolt v1.6.1 版本，主要变更如下：\n 支持 SSL 支持 UserProcessor 生命周期的方法 支持用户自定义 SO_SND_BUF 和 SO_RCV_BUF 支持 RejectedException 的处理策略 优化了生命周期的检查，避免组件在关闭或启动前后仍然能够提供服务 优化了 DefaultConnectionManager 的构造方法以及其它的部分代码 修复 DefaultConnectionManager#check(Connection) 异常信息不完整的问题 修复 AbstractLifeCycle 启动/关闭的并发问题 详细发布报告： https://github.com/sofastack/sofa-bolt/releases/tag/v1.6.1\n社区活动预告 下周六 Service Mesh Meetup 第9期杭州站来啦，本期与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。欢迎参加~\n主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond\n时间：2019年12月28日（下周六）13:00-17:30\n地点：杭州西湖区紫霞路西溪谷G座8楼\n报名方式：点击“这里”，即可报名\n","date":1576825200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191220/","fuzzywordcount":1800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c9e61e735545e48bd341dd6da7310440","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191220/","publishdate":"2019-12-20T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191220/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | MOSN 配置文档、SOFABolt 等组件发布、社区活动预告","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191220/","wordcount":1781},{"author":"十倍","categories":null,"content":" 图为 ZSearch 基础架构负责人十倍 2019 Elastic Dev Day 现场分享\n引言 ElasticSearch（简称 ES）是一个非常受欢迎的分布式全文检索系统，常用于数据分析，搜索，多维过滤等场景。蚂蚁金服从2017年开始向内部业务方提供 ElasticSearch 服务，我们在蚂蚁金服的金融级场景下，总结了不少经验，此次主要给大家分享我们在向量检索上的探索。\nElasticSearch 的痛点 ElasticSearch 广泛应用于蚂蚁金服内部的日志分析、多维分析、搜索等场景。当我们的 ElasticSearch 集群越来越多，用户场景越来越丰富，我们会面临越来越多的痛点：\n 如何管理集群； 如何方便用户接入和管理用户； 如何支持用户不同的个性化需求； \u0026amp;hellip; 为了解决这些痛点，我们开发了 ZSearch 通用搜索平台：\n 基于 K8s 底座，快速创建 ZSearch 组件，快捷运维，故障机自动替换； 跨机房复制，重要业务方高保； 插件平台，用户自定义插件热加载； SmartSearch 简化用户搜索，开箱即用； Router 配合 ES 内部多租户插件，提高资源利用率； 向量检索需求 基于 ElasticSearch 的通用搜索平台 ZSearch 日趋完善，用户越来越多，场景更加丰富。\n随着业务的飞速发展，对于搜索的需求也会增加，比如：搜索图片、语音、相似向量。\n为了解决这个需求，我们是加入一个向量检索引擎还是扩展 ElasticSearch 的能力使其支持向量检索呢？\n我们选择了后者，因为这样我们可以更方便的利用 ElasticSearch 良好的插件规范、丰富的查询函数、分布式可扩展的能力。\n接下来，我来给大家介绍向量检索的基本概念和我们在这上面的实践。\n向量检索基本概念 向量从表现形式上就是一个一维数组。我们需要解决的问题是使用下面的公式度量距离寻找最相似的 K 个向量。\n 欧式距离： 两点间的真实距离，值越小，说明距离越近； 余弦距离： 就是两个向量围成夹角的 cosine 值，cosine 值越大，越相似； 汉明距离： 一般作用于二值化向量，二值化的意思是向量的每一列只有0或者1两种取值。 汉明距离的值就两个向量每列数值的异或和，值越小说明越相似，一般用于图片识别； 杰卡德相似系数： 把向量作为一个集合，所以它可以不仅仅是数字代表，也可以是其他编码，比如词，该值越大说明越相似，一般用于相似语句识别； 因为向量检索场景的向量都是维度很高的，比如256，512位等，计算量很大，所以接下来介绍相应的算法去实现 topN 的相似度召回。\n向量检索算法 KNN 算法 KNN 算法表示的是准确的召回 topK 的向量，这里主要有两种算法，一种是 KDTtree，一种是 Brute Force。我们首先分析了 KDTree 的算法，发现 KDTree 并不适合高维向量召回，于是我们实现的 ES 的 Brute Force 插件，并使用了一些 Java 技巧进行加速运算。\nKDTree 算法 简单来讲，就是把数据按照平面分割，并构造二叉树代表这种分割，在检索的时候，可以通过剪枝减少搜索次数。\n构建树\n以二维平面点(x,y)的集合(2,3)，(5,4)，(9,6)，(4,7)，(8,1)，(7,2)为例：\n图片来源\n 按照 x 排序，确定中间值7，其他坐标分两边； 第二层按照 y 排序，第三层按照 x 排序； 并且在构建时维护每个节点中的 x 最大最小，y 最大最小四个值； 查找最近点\n图片来源\n搜索(3,5)的最近邻：\n 到根节点距离为5； 遍历到右节点(9,6)，发现整棵右子树的x轴，最小值是8，所以所有右子树的节点到查询节点的距离一定都大于8-3=5，于是所有右子树的节点都不需要遍历； 同理，在左子树，跟(5，4)节点比较，(7,2)被排除； 遍历完(2,3),(4,7)，最近点(5,4) 返回； 结论 Lucene 中实现了 BKDTree，可以理解为分块的 KDTree，并且从源码中可以看到 MAX_DIMS = 8，因为 KDTree 的查询复杂度为 O(kn^((k-1)/k))，k 表示维度，n 表示数据量。说明 k 越大，复杂度越接近于线性，所以它并不适合高维向量召回。\nBrute Force 顾名思义，就是暴力比对每一条向量的距离，我们使用 BinaryDocValues 实现了 ES 上的 BF 插件。更进一步，我们要加速计算，所以使用了 JAVA Vector API 。JAVA Vector API 是在 openJDK project Panama 项目中的，它使用了 SIMD 指令优化。\n结论 使用 avx2 指令优化，100w 的 256 维向量，单分片比对，RT 在 260ms，是常规 BF 的 1/6。 ElasticSearch 官方在7.3版本也发布了向量检索功能，底层也是基于 Lucene 的 BinaryDocValues，并且它还集成入了 painless 语法中，使用起来更加灵活。\nANN 算法 可以看到 KNN 的算法会随着数据的增长，时间复杂度也是线性增长。例如在推荐场景中，需要更快的响应时间，允许损失一些召回率。\nANN 的意思就是近似 K 邻近，不一定会召回全部的最近点。ANN 的算法较多，有开源的 ES ANN 插件实现的包括以下这些：\n 基于 Hash 的 LSH； 基于编码的 IVFPQ； 基于图的 HNSW； ZSearch 依据自己的业务场景也开发了 ANN 插件（适配达摩院 Proxima 向量检索引擎的 HNSW 算法）。\nLSH 算法 Local Sensitive Hashing 局部敏感 hash，我们可以把向量通过平面分割做 hash。例如下面图例，0表示点在平面的左侧，1表示点在平面的右侧，然后对向量进行多次 hash，可以看到 hash 值相同的点都比较靠近，所以在 hash 以后，我们只需要计算 hash 值类似的向量，就能较准确的召回 topK。\nIVF-PQ 算法 PQ 是一种编码，例如图中的128维向量，先把向量分成4份，对每一份数据做 kmeans 聚类，每份聚类出256个聚类中心，这样，原始向量就可以使用聚类中心的编号重新编码，可以看出，现在表示一个向量，只需要用4个字节就行。然后当然要记录下聚类中心的向量，它被称之为码本。\n图片来源\nPQ 编码压缩后，要取得好的效果，查询量还是很大，所以前面可以加一层粗过滤，如图，把向量先用 kmeans 聚类成1024个类中心，构成倒排索引，并且计算出每个原始向量与其中心的残差后，对这个残差数据集进行 PQ 量化。用 PQ 处理残差，而不是原始数据的原因是残差的方差能量比原始数据的方差能量要小。\n这样在查询的时候，我们先找出查询出靠近查询向量的几个中心点，然后再在这些中心点中去计算 PQ 量化后的 top 向量，最后把过滤出来的向量再做一次精确计算，返回 topN 结果。\n图片来源\nHNSW 算法 讲 HNSW 算法之前，我们先来讲 NSW 算法，如下图，它是一个顺序构建图流程：\n 例如第5次构造 D …","date":1576670400,"description":" 本文整理自 2019 Elastic Dev Day 现场分享，主要给大家分享蚂蚁金服在向量检索上的探索。","dir":"blog/antfin-zsearch-vector-search/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"194a0b7104c5147b2fd54e8c74b17e22","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-zsearch-vector-search/","publishdate":"2019-12-18T20:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/antfin-zsearch-vector-search/","summary":"图为 ZSearch 基础架构负责人十倍 2019 Elastic Dev Day 现场分享 引言 ElasticSearch（简称 ES）是一个非常受欢迎的分布式全文检索系统，常用于数据分析，搜索","tags":["ZSearch"],"title":" 蚂蚁金服 ZSearch 在向量检索上的探索","type":"blog","url":"/sofastack.tech/blog/antfin-zsearch-vector-search/","wordcount":4634},{"author":"应明","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第六篇 - Operator 篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 是蚂蚁金服下一代技术架构的核心，也是蚂蚁金服内部双十一应用云化的重要一环，本文主要分享在蚂蚁金服当前的体量下，如何支撑应用从现有微服务体系大规模演进到 Service Mesh 架构并平稳落地。\n本文作者：杜宏伟（花名：应明），蚂蚁金服技术专家，关注 API 网关，Service Mesh 和容器网络，蚂蚁金服 Service Mesh 核心成员。\n为什么需要 Service Mesh 在此之前，SOFAStack 作为蚂蚁金服微服务体系下服务治理的核心技术栈，通过提供 Cloud Engine 应用容器、SOFABoot 编程框架（已开源）、SOFARPC（已开源） 等中间件，来实现服务发现和流量管控等能力。经过若干年的严苛金融场景的锤炼，SOFAStack 已经具备极高的可靠性和可扩展性，通过开源共建，也已形成了良好的社区生态，能够与其他开源组件相互替换和集成。在研发迭代上，中间件类库已经与业务解耦，不过避免不了的是，运行时两者在同一个进程内，意味着基础库的升级需要推动业务方升级对应的中间件版本。\n我们一直在探索更好的技术实现方式。我们发现，Service Mesh 通过将原先通过类库形式提供的服务治理能力进行提炼和优化后，下沉到与业务进程协同，但独立运行的 Sidecar Proxy 进程中，大量的 Sidecar Proxy 构成了一张规模庞大的服务网络，为业务提供一致的，高质量的用户体验的同时，也实现了服务治理能力在业务无感的条件下独立进行版本迭代的目标。\n应用 Service Mesh 的挑战 Service Mesh 带给我们的能力很美好，但现实为我们带来的挑战同样很多。比方说数据面技术选型和私有协议支持，控制面与蚂蚁金服内部现有系统对接，配套监控运维体系建设，以及在调用链路增加两跳的情况下如何优化请求延迟和资源使用率等等。\n本文着重从 MOSN（Sidecar Proxy）的运维和风险管控方面，分享我们的实践经验，其他方面的挑战及应对方案，请参考系列分享中的其他文章。\nMOSN：https://github.com/sofastack/sofa-mosn\nSidecar 注入 创建注入 已经完成容器化改造，运行在 Kubernetes 中的应用，如何接入到 Service Mesh 体系中？最简单的方式，也是以 Istio 为代表的 Service Mesh 社区方案所采用的方式，即是在应用发布阶段，通过 mutating webhook 拦截 Pod 创建请求，在原始 Pod Spec 的基础上，为 Pod 注入一个新的 MOSN 容器。\n值得注意的是，在资源分配上，起初我们依据经验值，在应用 8G 内存的场景下，为 Sidecar 分配 512M 内存，即：\nApp: req=8G, limit=8G Sidecar: req=512M, limit=512M\n很快我们就发现了这种分配方案带来的问题，一方面部分流量比较高的应用的 MOSN 容器，出现了严重的内存不足甚至 OOM；另一方面注入进去的 Sidecar 容器额外向调度器申请了一部分内存资源，这部分资源脱离了业务的 quota 管控。\n因此，为了消除内存 OOM 风险和避免业务资源容量规划上的偏差，我们制定了新的“共享内存”策略。在这个策略下，Sidecar 的内存 request 被置为0，不再向调度器额外申请资源；同时 limit 被设置为应用的 1/4，保障 Sidecar 在正常运行的情况下，有充足的内存可用。为了确实达到“共享”的效果，蚂蚁金服 sigma 团队针对 kubelet 做了调整，使之在设置 Sidecar 容器 cgroups limit 为应用 1\u0026amp;frasl;4 的同时，保证整个 Pod 的 limit 没有额外增加（细节这里不展开）。\n当然，Sidecar 与应用“共享”分配到的内存资源，也导致了在异常情况（比如内存泄露）下，sidecar 跟应用抢内存资源的风险。如何应对这个风险？我们的做法是，通过扩展 Pod Spec（及相应的 apiserver, kubelet 链路），我们为 Sidecar 容器额外设置了 Linux oom_score_adj 这个属性，以保障在内存耗尽的情况下，Sidecar 容器会被 OOM Killer 更优先选中，以发挥 sidecar 比应用能够更快速重启，从而更快恢复到正常服务的优势。\n此外，在 CPU 资源的分配上，我们也遇到过在一些场景下，MOSN 抢占不到 CPU 资源从而导致请求延迟大幅抖动，解决方案是确保在注入 Sidecar 时，根据 Pod 内的容器数量，为每个 Sidecar 容器计算出相应的 cpushare 权重，并通过工具扫描并修复全站所有未正确设置的 Pod。\n原地注入 在创建 Pod 的时候注入 Sidecar，是一件相对比较“舒服“的接入方式，因为这种做法，操作起来相对比较简单，应用只需先扩容，再缩容，就可以逐步用带有 Sidecar 的 Pod，替换掉旧的没有 Sidecar 的 Pod。可问题是，在大量应用，大规模接入的时候，需要集群有较大的资源 buffer 来供应用实例进行滚动替换，否则替换过程将变得十分艰难且漫长。而蚂蚁金服走向云原生的目标之一则是，双十一大促不加机器，提高机器使用率。如果说我们要花更多的钱购买更多的机器来支持云原生，就多少有点事与愿违了。\n为了解决这个问题，我们提出了“原地注入”的概念，也就是说在 Pod 不销毁，不重建的情况下，原地把 Sidecar 注入进去。\n如图所示，原地注入由以下步骤构成：\n 在 PaaS 提交工单，选择一批需要原地注入的 Pod； PaaS 调用中间件接口，关闭业务流量并停止应用容器； PaaS 以 annotation 的形式打开 Pod 上的原地注入开关； Operator 观察到 Pod 原地注入开关打开，渲染 sidecar 模版，注入到 Pod 中并调整 cpu/memory 等参数； Operator 将 Pod 内容器期望状态置为运行； kubelet 将 Pod 内容器重新拉起； PaaS 调用中间件接口，打开业务流量； Sidecar 升级 我们将 RPC 等能力从基础库下沉到 Sidecar 之后，基础库升级与业务绑定的问题虽然消除了，但是这部分能力的迭代需求依然存在，只是从升级基础库变成了如何升级 Sidecar。\n最简单的升级就是替换，即销毁 Pod 重新创建出一个新的，这样新建出来的 Pod 所注入的 Sidecar 自然就是新版本了。但通过替换的升级方式，与创建注入存在相似的问题，就是需要大量的资源 buffer，并且，这种升级方式对业务的影响最大，也最慢。\n非平滑升级 为了避免销毁重建 Pod，我们通过 Operator 实现了“非平滑升级” …","date":1576501200,"description":" 本文着重从 MOSN（Sidecar Proxy）的运维和风险管控方面，分享我们的实践经验。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3528d4d6bd82bd170eccd20d98f5f7e2","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","publishdate":"2019-12-16T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第六篇 - Operator 篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模","tags":["Service mesh","Service Mesh 落地实践"],"title":" 蚂蚁金服 Service Mesh 大规模落地系列 - Operator 篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/","wordcount":3725},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@温明磊 提问：\n 我用的 ShardingSqhere 分库分表，按照各个业务方分库。\u0026amp;gt; 所以我们项目里所有分库的表都带了业务方字段biz_code，这个字段的值也就是虚库的名字，都是写在配置里的。 A：从你的需求看，比较简单只是需要按业务方进行分库，而 biz_code 不在状态机日志表的字段里，你可以考虑先算好分库位，然后用 ShadingJDBC 的 hint 功能来设置分库位即可。\n A：我看了一下 ShardingJDBC 也是用的 ThreadLocal 来设置 hint：https://shardingsphere.apache.org/document/current/cn/manual/sharding-jdbc/usage/hint/\n ShadingJDBC 的 hint 功能是基于 ThreadLocal 的，Saga 异步的方式不能用 sharding jdbc 的吗?\n A：有一个优雅的办法：你实现 StateLogStore 接口，然后代理 Seata Saga 的DbAndReportTcStateLogStore，在每个方法前后加上：hintManager.addDatabaseShardingValue();、hintManager.close()，这样就和同步异步没有关系了，因为设置 hint 和 sql 执行都在同一个线程。\n另外，DbAndReportTcStateLogStore 如何传到你自己实现的 StateLogStore 里，你需要继承 DbStateMachineConfig，然后在 afterProperties 方法，先调 super.afterProperties 方法，然后 getStateLogStore()，传入你自己实现的 StateLogStore 里，然后把自己实现的 StateLogStore 调 setStateLogStore 覆盖。\n2、@Purge yao 提问：\n Saga 状态机在线设计器： http://seata.io/saga_designer/index.html 这个状态机可以让流程引擎用吗？\n A：不可以当工作流用，没有人工节点。\n Seata 用这个流程是干嘛用的？\n A：事实上 Seata Saga 模式 是一个具备“服务编排”和“Saga 分布式事务”能力的产品，总结下来它的适用场景是：\n 适用于微服务架构下的“长事务”处理； 适用于微服务架构下的“服务编排”需求； 适用于金融核心系统以上的有大量组合服务的业务系统（比如在渠道层、产品层、集成层的系统）； 适用于业务流程中需要集成遗留系统或外部机构提供的服务的场景（这些服务不可变不能对其提出改造要求）。 Seata：https://github.com/seata/seata\n3、@anorqiu9 提问：\n 关于 MOSN 我们目前遇到一个架构方面的问题，就是原基于 Dubbo 的服务和现在基于 Spring Cloud 的服务互调如何做？一种方案设计服务同时开启两个服务框架的服务接口为两个框架的服务同时提供服务;另一种方案是异构系统基于网关交互.这两种方案有什么优缺点？大家有没有碰到过类似的场景，是如何处理的？谢谢！\n A：Dubbo 和 Spring Cloud 互相调用，需要使用的是 http 接口来调用，个人推荐用网关来做交互，这样 API 的管理上更方便，当然也可以通过 Sidecar 来解决。\n 是的，我也倾向于网关交互，由网关完成协议的转换，进行包括流量控制、安全访问控制等在内的 API 管理工作。如果一个服务同时处于两种服务框架治理之下，就意味着对这个服务的治理（如限流、熔断及安全访问等）必须在两个地方进行，这将会是一个挑战。 当然，如果使用 Service Mesh 架构，通过 Sidecar 如 MOSN 来实现多 RPC 协议的支持，同时又能通过 Service Mesh 的控制平面实现服务治理的统一，这样就不存在上述说的挑战。 MOSN：https://github.com/sofastack/sofa-mosn\n 本周推荐阅读 蚂蚁金服 DB Mesh 的探索与实践 Mesh 化落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布SOFARPC v5.6.3，主要变更如下：\n 试验性支持 grpc； 试验性支持 H2 的 tls； 序列化方式支持 msgpack； 修复直接通过线程上下文指定的地址调用； 扩展加载过程日志改为 debug，防止错误信息过多； 升级 jackson 和 netty 的小版本； 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.3\n2、发布 SOFAArk v1.1.0，主要变更如下：\n 支持在 Biz 中使用 Ark 扩展点机制； 修复遗漏处理加载 ark spi 类资源 bug； 提供全新的biz/plugin 生命周期事件； 优化SOFAArk 自身日志输出； 优化 SOFAArk 与 SOFABoot 日志依赖管控； telnet 服务支持退出指令； 升级 netty 版本到 4.1.42.Final； 迁移 sofa-ark-samples 到 https://github.com/sofastack-guides/sofa-ark-samples 详细发布报告： https://github.com/sofastack/sofa-ark/releases/tag/v1.1.0\n3、发布 SOFABoot v3.2.1，主要变更如下：\n 版本升级： …","date":1576220400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191213/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"37b96cc1a849775521b4d2b78d6602ce","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191213/","publishdate":"2019-12-13T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191213/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"活动报名、本周 QA、组件发布 | SOFA Weekly","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191213/","wordcount":2258},{"author":"潘潘","categories":"Service Mesh","content":" 概要 活动主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond 活动时间：时间：2019 年 12 月 28 日（周六）13:00-17:30 活动地点：杭州西湖区紫霞路西溪谷G座8楼 活动形式：线下活动 活动回顾：请戳这里 活动介绍 关于 Service Mesh\n服务网格（Service Mesh）是致力于解决服务间通讯的基础设施层。它负责在现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，Service Mesh 通常是通过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一起来实现，而无需感知应用程序本身。\n关于 ServiceMesher 社区\nServiceMesher 社区，专注于 Service Mesh 和云原生技术，立足开源，分享技术资讯和实践，致力于新技术的推广和普及。\nService Mesh Meetup #9 杭州站\nService Mesh Meetup 是由蚂蚁金服联合 CNCF 官方共同出品，ServiceMesher 社区主办，主题围绕服务网格、Kubernetes 及云原生，在全国各地循环举办的技术沙龙。\n本期 Meetup 与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。\n活动议程 时间 环节（分享主题） 分享嘉宾 13:00-13:30 签到 13:30-14:15 《蚂蚁金服 API Gateway Mesh 的思考与实践》 贾岛 蚂蚁金服 高级技术专家 14:15-15:00 《酷家乐的 Istio 与 Knative 踩坑实录》 付铖 酷家乐 容器化负责人 15:00-15:10 MOSN 社区化发布 涵畅 15:10-15:20 茶歇 15:20-16:00 圆桌环节-《Service Mesh 落地的务实与创新》 鲁直 16:00-16:45 《蚂蚁金服 Service Mesh 技术风险思考和实践》 嘉祁 蚂蚁金服 技术专家 16:45-17:30 《网易严选的 Service Mesh 实践》 王国云 网易严选 架构师 本期议题以及嘉宾详解 13:30-14:15《蚂蚁金服 API Gateway Mesh 的思考与实践》\n 讲师：贾岛 蚂蚁金服 高级技术专家 讲师介绍：靳文祥（花名贾岛），2011年毕业后加入支付宝无线团队，一直从事移动网络接入、API 网关、微服务等相关的研发工作，目前负责蚂蚁金服移动网络接入架构设计与优化。 Topic 介绍：在 Service Mesh 微服务架构中，我们常常会听到东西流量和南北流量两个术语。蚂蚁金服开源的Service Mesh Sidecar MOSN 已经多次与大家见面交流了，以往的议题重点在东西流量的服务发现与路由，那么蚂蚁金服在南北流量上的思考是怎样的？本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的，解决了什么问题，双十一的实践表现，以及我们对未来的思考。 14:15-15:00《酷家乐的 Istio 与 Knative 踩坑实录》\n 讲师：付铖 酷家乐 技术专家 讲师介绍：先后负责酷家乐户型图, 渲染引擎等模块，目前负责酷家乐国际站的研发。在业务开发过程中推动和布道云原生技术，并在部分业务落地了 Istio 服务治理和基于 Knative 的 Serverless 基础设施。 Topic 介绍：酷家乐在部分业务模块，自2018年使用了 Istio 进行服务治理，自2019年使用了 Knative 作为 FaaS 基础设施，在实践过程中解决了大量问题，也积累了不少第一手经验。本次分享，将重点讨论服务网格的性能损耗，存量业务迁移难题，函数计算的冷启动时间问题以及解决方案等。 15:20-16:00 圆桌环节《Service Mesh 落地的务实与创新》\n 主持人：鲁直 蚂蚁金服云原生落地负责人 嘉宾： 涵畅 蚂蚁金服高级技术专家 张超盟 华为云微服务平台架构师 付铖 酷家乐技术专家 王国云 网易严选架构师 16:00-16:45《蚂蚁金服 Service Mesh 技术风险思考和实践》\n 讲师：嘉祁 蚂蚁金服 技术专家 讲师介绍：黄家琦（花名：嘉祁）2012年毕业后加入阿里巴巴技术保障，2015年转入蚂蚁金服SRE，长期从事稳定性相关工作，当前重点关注于中间件，Service Mesh 与云原生基础设施的稳定性。 Topic 介绍：Servish Mesh 是微服务架构与云原生碰撞出的火花，对于传统的中间件体系与运维支撑能力是极大的挑战。本次分享的主题主要关注于在蚂蚁金服内部如何应对这些挑战，并建设相应的技术风险能力来保障其稳定。 16:45-17:30《网易严选的 Service Mesh 实践》\n 讲师：王国云 网易高级技术专家、网易严选架构师 讲师介绍：2008年加入网易，长期从事一线的研发与管理工作，曾参与或负责过网易博客、网易邮箱、网易有钱等多个核心产品的研发工作，擅长服务端架构及技术体系建设，现任严选支持业务研发部技术负责人，负责严选的容器化及 Service Mesh 演进。 Topic 介绍：网易严选在2016年选择了 Service Mesh 作为未来微服务改造的基础架构，并在过去几年支持了业务的持续快速增长。本次分享主要介绍 Service Mesh 在严选的落地和演进情况，讨论 Service Mesh 在混合云架构下落地遇到的挑战和我们的解决方案，同时也希望和大家交流一下在架构方面的一些思考。 加入 SOFA 钉钉互动群 群号：23390449，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n主办方与合作伙伴 主办方：CNCF、ServiceMesher 协办方：蚂蚁金服、SOFAStack、滴滴 合作伙伴：掘金社区、开源中国、养码场、SegmentFault、麦思博、开源社 ","date":1576051200,"description":"本次 Meetup 与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。","dir":"activities/service-mesh-meetup-9/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a7103ed15ed823b9156082c37b7d464a","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-meetup-9/","publishdate":"2019-12-11T16:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/activities/service-mesh-meetup-9/","summary":"概要 活动主题：Service Mesh Meetup#9 杭州站：To Infinity and Beyond 活动时间：时间：2019 年 12 月 28 日（周六）13:00-17:30 活动地点：杭州西湖区紫霞路","tags":["Meetup","Service Mesh"],"title":"Service Mesh Meetup#9 杭州站：To Infinity and Beyond","type":"activities","url":"/sofastack.tech/activities/service-mesh-meetup-9/","wordcount":1855},{"author":"改之","categories":"Service mesh","content":" 蚂蚁金服数据访问层有三个核心组件：数据访问框架 ZDAL、数据访问代理 DBP 和 OceanBase 代理服务器 OBProxy。本篇主要涉及 ZDAL 和 OBProxy 两个组件。ZDAL 作为全站数据访问的标准组件，不仅提供了分库分表、读写分离、分布式 Sequence等标准的应用能力，还提供了链路跟踪、影子压测、单元化、容灾切换等技术风险能力 。OBProxy 作为 OceanBase 的访问入口，提供了 OceanBase 路由寻址、读写分离等数据库能力，同时从执行效率和资源成本角度考虑，从 OBProxy 诞生那天我们就采用了近应用的独立进程部署模式，目前生产环境上保持在几十万级别的进程数。\n本篇文章通过介绍当前蚂蚁金服数据访问层遇到的问题，解决的思路，演进的方向三个方面，期望能够用阐述下 DB Mesh 发展的一些思考并让更多同学认识到 DB Mesh。期望能够 DB Mesh 的方式将数据访问层下沉到统一的基础设施之上，让新业务快速使用上全站多年的技术风险能力，并能够持续享受到更多的性能、资源等技术红利。\n背景 随着业务的快速发展，ZDAL 作为客户端模式的组件，一直存在业务耦合、版本迭代推进、多语言支持等问题。OBProxy 是为 OceanBase 数据库专门量身定制的代理服务器，天然就是业务无耦合、支持多语言。用户的数据在 OceanBase 上以多副本的形式存放在各个 OBServer 上，OBProxy 则负责接收用户发过来的 SQL 请求，解析 SQL 请求并计算分区信息后，将用户请求转发到最佳目标 OBServer 上，并将执行结果给用户。在蚂蚁金服内部也存在分库分表组件 ZDAL，用在多 OceanBase 集群以及单元化的场景。两者配合使用，分库分表组件 ZDAL 做业务层的流量调拨，OceanBase 分区功能支持数据库的水平扩容能力。\n我们进一步看 ZDAL 和 OBProxy 这两个组件的核心逻辑。\nZDAL 的核心逻辑：\n SQL 解析器：获得表名及分库分表字段； 规则引擎：计算分库分表结果； 执行层：将 SQL 改写发给数据库，并做结果集合并用户； OBProxy 的核心逻辑：\n 协议解析器：解析协议中的 SQL，Parse 后获得表名及分区字段； 路由器：计算分区表所在的 OBServer； IO 层：将请求转发给 OBServer，将结果集返回给客户端； 可以看出，OBProxy 和 ZDAL 这两个组件的执行路径有一定的重复度，比如两个组件都做了 SQL 解析，并分析表名和字段。这对性能带来一定的损耗，而且这种重复给研发迭代带来更多的工作量。\n基于前面的考虑将 ZDAL 和 OBProxy 两者合并成一个组件的是一个自然的方案，通过将 ZDAL 逻辑下沉到 OBProxy 中，让 OBProxy 提供了分库分表、读写分离、分布式序列等中间件能力，这个组件我们命名为 ODP（Open Database Proxy）。\nODP 作为近业务端部署的进程，虽然逻辑独立出来，升级时但是依然需要去改动业务的容器，所以迭代过程中的升级推进工作也是比较费时费力，而且 ODP 只是整个产品的冰山一角，需要大量的精力来构建冰山之下的基础设施，比如说如何解决 ODP 的运维问题、用户透明切换的方案、复杂配置的推送问题、金融级数据库密钥管理问题等。我们发现这部分与蚂蚁金服内部大规模实践的 ServiceMesh 遇到的问题有比较大的重合度，所以与 ServiceMesh 一起共建底层基础设施，为这块的完整产品方案命名为 DBMesh。下文会简单介绍一下我们的演进路线和发展方向。\n解决思路 Sidecar 模式以解耦部署 从执行效率和资源成本角度考虑，OBProxy 在蚂蚁金服一直都在采用近业务端部署的方式，日常保有的服务数在数十万的级别。近业务端部署虽然提供了高效率，但是也带来了运维上的复杂度，同时需要升级版本时，也需要和通知业务一起来做发布和升级。要让单个应用升级，基本都是按月计，如果涉及到全站层面的升级，时间基本不太好估算。\n但是随着云原生以及 Kubernetes 的发展，让 Sidecar 模式更为成熟，即在业务的容器旁边再运行一个容器，这个非常贴合我们近业务端部署的 OBProxy 进程，只需要将 OBProxy 进程改造成 OBProxy Sidecar，即可进行独立升级、发布、运维等。同时蚂蚁金服在云原生领域有非常深的实践，有着世界上最大规模的 Kubernetes 集群和 ServiceMesh 集群，将 OBProxy 变成 Sidecar 也是比较合理和方便实施的了。\n今年双十一切了约 10% 的数万个的 PODs 到 ODP Sidecar 模式，通过 Sidecar 的方式能够让业务快速享受到基础软件迭代的好处，本次双十一 ODP 修复了一个非预期日志打印导致某个机房出现慢 SQL 问题，在传统的本地进程方式，需要推动所有的业务进行拉迭代、发布、打包时间周期基本不太可控。而今年让所有涉及应用独立的灰度、升级仅花费两天时间。\n合并重复逻辑拿技术红利 解决了部署模式的问题，通过快速迭代并且独立升级的方式，才能让功能下沉的落地成为可能。我们将分库分表组件的大多数功能都下沉到了 ODP 上，比如：分库分表功能、读写分离功能、分布式 Sequence 功能、全链路跟踪等。如下图：\n整个分库分表组件功能下沉之后，在今年双十一我们在核心系统上线，拿到了一些非常可观的技术红利：\n 性能提升：通过功能的合并可以省去额外的 SQL 解析和路由计算过程，双十一上线的系统 SQL 平均响应时间可以下降上百微秒； 启动速度：应用只需要和 ODP 建立连接即可，无需初始化多个分库的数据源，初始化时间从数十秒降到数十毫秒； 内存下降：和启动速度一样，由于应用和 ODP 的连接数减少了，同样也可以节省应用端的内存使用，生产上能够下降上百 MB； 共建 Mesh 基础设施完善技术风险 研发同学会将更多的关注点放在 ODP 数据链路上，如何提高数据平面的性能，如何增加更多的 SQL 特性，而会忽略非 SQL 执行链路上的诉求。DBMesh 作为应用侧的基础设施，更多的要考虑如何更好的管理 Sidecar、数据访问高安全防控、满足配置变更的三板斧要求、最大程度的节省资源成本等。\n我们在与蚂蚁金服 ServiceMesh 团队共建整个云原生下 Mesh 的技术风险能力，优先完善 Sidecar 的运维能力和变更三板斧能力，后续会将 ODP Sidecar 部署到宿主机上以最大程度优化 ODP 的资源占用，也会逐步下沉更多如影子压测、灰度机房、流量镜像等的技术风险能力。\n总结 DBMesh 让数据访问从客户端模式切换到代理模式，给应用带来了启动速度的极大优化。Sidecar 的部署模式则是 SQL 平均响应时间、资源利用的最优模式。将更多的技术风险能力沉淀进来，让新应用快速享受到金融级的技术风险能力，存量应用的技术风险指标更完善。我们期望通过统一的数据访问基础设施，让业务都使用标准的技术组件，降低学习以及维护成本，仅专注在业务开发和创新上。\n作者介绍 易鸿伟（花名：改 …","date":1575982800,"description":" 本篇文章通过介绍当前蚂蚁金服数据访问层遇到的问题，解决的思路，演进的方向三个方面，期望能够用阐述下 DB Mesh 发展的一些思考并让更多同学认识到 DB Mesh。","dir":"blog/ant-financial-db-mesh-explore-practice/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9732786e2e2be0688d1e6a594838f87e","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","publishdate":"2019-12-10T21:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","summary":"蚂蚁金服数据访问层有三个核心组件：数据访问框架 ZDAL、数据访问代理 DBP 和 OceanBase 代理服务器 OBProxy。本篇主要涉及 ZDAL 和 OBProxy 两个组件。ZDAL 作为","tags":["Service mesh","DB Mesh"],"title":"蚂蚁金服 DB Mesh 的演进之路","type":"blog","url":"/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/","wordcount":2561},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@温明磊 提问：\n 我们还是想用 redis 存状态机上下文一个大的实体，输入输出只放 id，我想问下，redis 宕机或者其它情况下，状态机 redis 宕机节点之前的节点都是幂等可重复的，那我怎样让它重新跑一边状态机？只能人工干预吗？\n A：你的意思是因为参数没有了，所以你想重跑状态机回放参数？\n 是的。从最开始跑，因为之前的节点幂等， 也没有变更数据，或者数据已经被 catch 住然后补偿了。\n A：我理解是你可以新启动一个状态机事例，把之前的生成的 id 传进上下文，这样和从新开始没有区别吧？不然你人工处理的话，需要把 state_inst 表里的数据删除。\n 嗯 ，我明白 ，通过定时就可以，因为在状态机开始之前 数据已经落库了。redis 宕机捕获异常后，可以给最开始的数据设置状态，然后定时开启状态机。但是 Saga 确实不能帮我完成定时重启状态机这个事情对吧，或者我就设置个补偿节点，专门用来重启新状态机实例的？这样可以？\n A：我建议是不要搞个补偿节点来处理非补偿的事，我觉得可以自己做个定时任务，然后处理这种情况。\nSeata：https://github.com/seata/seata\n2、@李林 提问：\n 数据面默认是能感知到所有服务的变更么？\n A：是的，因为对接了 SOFARegistry。\n 那当集群规模比较大的时候，是不是会出现感知较慢的情况呢？\n A：SOFARegistry 里有全量的服务订阅信息，MOSN 和 SOFARegistry 对接只会感知当前 MOSN 必须的服务信息，所以 MOSN 内的数据总量不会很大。\n Istio 控制面占用的资源比较多，MOSN 是做了优化么？\n A：你指的 Istio 控制面占用资源比较多指的是哪一部分？Mixer 么？\n 可以理解为只告知当前服务需要依赖的信息吧，这样的话数据量就小多了。\n A：是的。\n Pilot 在我们自己的集群里部署了，占用资源也挺多的，不过比 Mixer 小。 另外我查看数据面 Envoy 从 Pilot 拿到的数据信息挺多的，config_dump 的信息有 30 万行左右。\n A：我们暂时没有从 Pilot 拿服务注册数据，只有一些服务流量管控的配置从 Pilot 下发，Mixer 的能力是集成在 MOSN 内部的所以控制面的消耗还好，不是很重。\n 那应该是做了挺多优化调整的吧。\n A：是的，集成后省去了 Mixer 的两跳，Metrics 数据可以直接被采集。\n 那服务的依赖关系需要通过配置提供才能做到只感知需要依赖的服务吧？Metrics 的直接采集是通过 prometheus 直接抓取每个数据面节点的数据么？\n A：是的，通过 prometheus 协议定时有专门的 agent 抓取的数据。\nMOSN：https://github.com/sofastack/sofa-mosn\n3、@NameHaibinZhang 提问：\n 将 MOSN 按照容器化的方式部署，通过读取默认配置，暴露 15001 端口，MOSN 能够同时在一个端口接收不同协议的请求么，如 Http、SOFARPC 请求。\n A：MOSN 的默认配置都是一些 example，没有 15001 端口，你需要按照你的需求写你的配置。一个 listener 目前不能同时处理两种协议，listener 中 proxy 的配置指定了可以处理的协议。\n 15001 端口是按 Sidecar 方式部署的时候开启的端口，比如通过 Istio 来部署，iptables 中 Envoy 开启 15001 端口。\n A：目前同一个端口支持 tls/明文自定识别， http1/http2 的自动识别，协议哪儿配置 Auto。Http 和 SOFA 的识别目前不支持，有需求的话支持也很方便。\n 嗯，因为作为 Sidecar 部署的时候，http 的接口和 SOFA 接口都希望能通过 Sidecar 来做流量劫持，Auto 可以做 rpc 协议的支持和识别不？\n A：如果是做流量劫持的话，其实是不需要支持识别的，这个 15001 不会实际处理请求，会转发给正确的端口来处理。\n Sidecar 内部做一个转发是吧，开另外2个端口，那15001这个端口配置 TCP 协议了，然后接收到之前做判断是什么协议，转给对应的端口。\n A：可以看一下这篇文章：《SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案》。\nSOFA 项目进展 本周发布详情如下：\n发布 Occlum v0.7.0 版本，主要变更如下：\n 重构了 ioctl 的实现； 增加了 socketpair； 实现了与Alpine Linux的二进制兼容性； 增加了 nanosleep； 增加了外部可调用命令的路径检查（即 occlum run 的）； 增加了 XGBoost 的 demo； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.7.0\n社区活动 回顾： 11月24日 Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动回顾（含现场PPT以及视频回顾）：\n Service Mesh 在『路口』的产品思考与实践：务实是根本 深入Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统 12月5日 SOFAChannel#9 直播回顾：\n https://tech.antfin.com/community/live/1021/data/957 预告-专享福利： “剑指源码，尖峰对话”2019 OSC源创会是由 OSCHINA 主办的线下技术沙龙，理念为“自由、开放、分享”，SOFAStack 也受邀参加本次年终盛会，并带来主题分享。\n主题：《蚂蚁金服 Service Mesh 超大规模实践以及开源》\n嘉宾：卓与，蚂蚁金服 Mesh 化落地负责人\n时间：2019年12月15日下午14:05-14:40（架构分会场）\n专享福利：点击“这里”，验证码填写“SOFAStack”即可获得大会免费票。\nTopic 简 …","date":1575615600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191206/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"aa9ec52b9b85a6c8830ff752423d1248","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191206/","publishdate":"2019-12-06T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191206/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【12/2 - 12/6】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191206/","wordcount":2358},{"author":"曹寅","categories":"Kubernetes","content":" 一、前言 经过超过半年的研发，蚂蚁金服在今年完成了 Kubernetes 的全面落地，并使得核心链路100% 运行在 Kubernetes。到今年双十一，蚂蚁金服内部通过 Kubernetes 管理了数以万计的机器以及数十万的业务实例，超过90%的业务已经平稳运行在 Kubernetes 上。整个技术切换过程平稳透明，为云原生的资源基础设施演进迈好了关键的一步。\n本文主要介绍 Kubernetes 在蚂蚁金服的使用情况，双十一大促对 Kubernetes 带来史无前例的挑战以及我们的最佳实践。希望通过分享这些我们在实践过程中的思考，让大家在应用 Kubernetes 时能够更加轻松自如。\n二、蚂蚁金服的 Kubernetes 现状 2.1 发展历程与落地规模 Kubernetes 在蚂蚁金服落地主要经历了四个阶段：\n 平台研发阶段：2018年下半年蚂蚁金服和阿里集团共同投入 Kubernetes 技术生态的研发，力求通过 Kubernetes 替换内部自研平台； 灰度验证：2019年初 Kubernetes 在蚂蚁金服灰度落地，通过对部分资源集群进行架构升级以及灰度替换生产实例两种方式，让 Kubernetes 得以小规模的验证； 云化落地（蚂蚁金服内部基础设施云原生化）：2019年4月蚂蚁金服内部完成 Kubernetes 适配云化环境的目标，并于618之前完成云化机房100% 使用 Kubernetes 的目标，这是 Kubernetes 第一次在蚂蚁金服内部得到规模化的验证； 规模化落地：2019年618之后，蚂蚁金服内部开始全面推动 Kubernetes 落地，在大促之前完成核心链路100% 运行在 Kubernetes的目标，并完美支撑了双十一大考。 2.2 统一资源调度平台 Kubernetes 承载了蚂蚁金服在云原生时代对资源调度的技术目标：统一资源调度。通过统一资源调度，可以有效提升资源利用率，极大的节省资源成本。要做到统一调度，关键在于从资源层面将各个二层平台的调度能力下沉，让资源在 Kubernetes 统一分配。\n蚂蚁金服在落地 Kubernetes 实现统一调度目标时遵循了标准化的扩展方式：\n 一切业务扩展均围绕 Kubernetes APIServer，通过CRD + Operator方式完成业务功能的适配和扩展； 基础服务通过 Node 层定义的资源接口完成个性化适配，有益于形成资源接入的最佳实践。 得益于持续的标准化工作，我们在落地 Kubernetes 的大半年内应用了多项技术，包含安全容器，统一日志，GPU 精细调度，网络安全隔离及安全可信计算等，并通过 Kubernetes 统一使用和管理这些资源服务了大量在线业务以及计算任务型业务。\n三、双十一 Kubernetes 实践 下面我们通过以下几种场景介绍蚂蚁金服内部是如何使用 Kubernetes，以及在此过程中我们面对的挑战和实践之路。\n3.1 资源分时复用 在大促过程中，不同业务域的洪峰流量通常都是在不同时间段来临，而应对这些不同时间到来的业务流量往往都需要大量的额外计算资源做保障。在以往的几次活动中，我们尝试了通过应用快速腾挪的方式来做到资源上的分时复用，但是服务实例上下线需要预热，腾挪耗时不可控，大规模调度的稳定性等因素都影响了最终腾挪方案的实践效果。\n今年双十一我们采用了资源共享调度加精细化切流的技术以达到资源分时利用的目标，为了达到资源充分利用和极速切换的目标，我们在以下方面做了增强：\n 在内部的调度系统引入了联合资源管理（Union-Resource Management），他可以将波峰波谷不重叠的业务实例摆放在相同的资源集合内，达到最大化的资源利用。 研发了一套融合资源更新，流量切换及风险控制的应用分时复用平台，通过该平台SRE可以快速稳定的完成资源切换以应对不同的业务洪峰。 整套平台和技术最终实现了令人激动的成果：蚂蚁金服内部不同业务链路数以万计的实例实现了最大程度的资源共享，这些共享资源的实例可分钟级完成平滑切换。这种技术能力也突破了当下资源水平伸缩能力的效率限制，为资源的分时复用打开了想象空间。\n3.2 计算型任务混部 Kubernetes 社区的落地案例中，我们往往看到的都是各种各样的在线业务，计算型业务往往通过“圈地”式的资源申请和独立的二层调度跑在 Kuberentes 集群中。但是在蚂蚁内部我们从决定使用 Kubernetes 的第一天起，就将 Kubernetes 融合计算型业务实现资源的统一调度作为我们的目标。\n在蚂蚁金服内部我们持续的使用 Kubernetes 支持各类计算业务，例如各类AI 训练任务框架，批处理任务和流式计算等。他们都有一个共同的特点：资源按需申请，即用即走。\n我们通过 Operator 模型适配计算型任务，让任务在真正执行时才会调用 Kubernetes API 申请 Pod 等资源，并在任务退出时删除 Pod 释放资源。同时我们在调度引擎中引入了动态资源调度能力和任务画像系统，这为在线和计算的不同等级业务提供了分级资源保障能力，使在线业务不受影响的情况下资源被最大化的利用。\n今年双十一除了洪峰时间段（00：00~02：00），蚂蚁金服 Kubernetes 上运行的任务均未做降级，每分钟仍有数以百计的计算任务在 Kubernetes 上申请和释放。未来蚂蚁金服内部将会持续推动业务调度融合，将 Kubernetes 打造成为资源调度的航空母舰。\n3.3 规模化核心 蚂蚁金服是目前少数运行了全球最大规模的 Kubernetes 集群的公司之一，单集群机器规模过万，Pods 数量数十万。随着类似计算型任务混部和资源分时复用这类业务的落地，资源的动态使用以及业务自动化运维都对 Kubernetes 的稳定性和性能带来的巨大的挑战。\n首先需要面对的挑战是调度性能，社区的调度器在5k规模测试中调度性能只有1~2 pods/s，这显然无法满足蚂蚁金服的调度性能需求。\n针对同类业务的资源需求往往相同的特点，我们自研了批量调度功能，再加上例如局部的filters性能优化等工作，最终达到了百倍的调度性能提升！\n在解决了调度性能问题后，我们发现规模化场景下 APIServer 逐渐成为了影响 Kubernetes 可用性的关键组件，CRD+Operator 的灵活扩展能力更是对集群造成巨大的压力。业务方有100种方法可以玩垮生产集群，让人防不胜防。 造成这种现象一方面是由于社区今年以前在规模化上的投入较少 APIServer 能力较弱，另一方面也是由 Operator 模式的灵活性决定。开发者在收益于 Operator 高灵活度的同时，往往为集群管理者带来业务不受控制的风险。即使对 Kubernetes 有一定熟悉程度的开发者，也很难保障自己写出的 Operator 在生产中不会引爆大规模的集群。\n面对这种“核按钮”不在集群管理员手上的情况，蚂蚁内部通过两方面入手解决规模化带来的问题：\n 我们通过持续总结迭代过程中的经验，形成了内部的最佳实践原则，以帮助业务更好的设计Operator CRD 在定义时需要明确未来的最大数量，大量CR …","date":1575464400,"description":"本文主要介绍 Kubernetes 在蚂蚁金服的使用情况，双十一大促对 Kubernetes 带来史无前例的挑战以及我们的最佳实践。","dir":"blog/kubernetes-practice-antfinal-shopping-festival/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5e1572fd3da2309cb49050bc05e24450","permalink":"https://sofastack.github.io/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","publishdate":"2019-12-04T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","summary":"一、前言 经过超过半年的研发，蚂蚁金服在今年完成了 Kubernetes 的全面落地，并使得核心链路100% 运行在 Kubernetes。到今年双十一，蚂蚁金服内部通","tags":["Kubernetes"],"title":"深入 Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统","type":"blog","url":"/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/","wordcount":3956},{"author":"齐天","categories":"Service mesh","content":" 一、引言 Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』，我们在产品设计上的思考和实践，希望能给大家带来一些启发。\n二、为什么需要 Service Mesh? 2.1 微服务治理与业务逻辑解耦 在 Service Mesh 之前，微服务体系的玩法都是由中间件团队提供一个 SDK 给业务应用使用，在 SDK 中会集成各种服务治理的能力，如：服务发现、负载均衡、熔断限流、服务路由等。\n在运行时，SDK 和业务应用的代码其实是混合在一个进程中运行的，耦合度非常高，这就带来了一系列的问题：\n 升级成本高 每次升级都需要业务应用修改 SDK 版本号，重新发布； 在业务飞速往前跑的时候，是不太愿意停下来做这些和自身业务目标不太相关的事情的； 版本碎片化严重 由于升级成本高，但中间件还是会向前发展，久而久之，就会导致线上 SDK 版本各不统一、能力参差不齐，造成很难统一治理； 中间件演进困难 由于版本碎片化严重，导致中间件向前演进过程中就需要在代码中兼容各种各样的老版本逻辑，戴着『枷锁』前行，无法实现快速迭代； 有了 Service Mesh 之后，我们就可以把 SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以 Sidecar 的模式部署。通过将服务治理能力下沉到基础设施，可以让业务更加专注于业务逻辑，中间件团队则更加专注于各种通用能力，真正实现独立演进，透明升级，提升整体效率。\n2.2 异构系统统一治理 随着新技术的发展和人员更替，在同一家公司中往往会出现使用各种不同语言、不同框架的应用和服务，为了能够统一管控这些服务，以往的做法是为每种语言、每种框架都重新开发一套完整的 SDK，维护成本非常高，而且对中间件团队的人员结构也带来了很大的挑战。\n有了 Service Mesh 之后，通过将主体的服务治理能力下沉到基础设施，多语言的支持就轻松很多了，只需要提供一个非常轻量的 SDK、甚至很多情况都不需要一个单独的 SDK，就可以方便地实现多语言、多协议的统一流量管控、监控等治理需求。\n图片来源\n2.3 金融级网络安全 当前很多公司的微服务体系建设都建立在『内网可信』的假设之上，然而这个原则在当前大规模上云的背景下可能显得有点不合时宜，尤其是涉及到一些金融场景的时候。\n通过 Service Mesh，我们可以更方便地实现应用的身份标识和访问控制，辅之以数据加密，就能实现全链路可信，从而使得服务可以运行于零信任网络中，提升整体安全水位。\n三、在当下『路口』的思考 3.1 云原生方案？ 正因为 Service Mesh 带来了上述种种的好处，所以这两年社区中对 Service Mesh 的关注度越来越高，也涌现出了很多优秀的 Service Mesh 产品，Istio 就是其中一款非常典型的标杆产品。\nIstio 以其前瞻的设计结合云原生的概念，一出现就让人眼前一亮，心之向往。不过深入进去看了之后发现，在目前阶段要落地的话，还是存在一些 gap 的。\n图片来源\n3.2 Greenfield vs Brownfield 在正式展开讨论之前，我们先来看一副漫画。\n图片来源\n上面这幅漫画描绘了这样一个场景：\n 有两个工人在工作，其中一个在绿色的草地（Greenfield）上，另一个在棕色的土地（Brownfield）上； 在绿色草地上的工人对在棕色土地上的工人说：“如果你没有给自己挖这么深的坑，那么你也可以像我一样做一些很棒的新东西”； 然后在棕色土地上的工人回答道：“你倒是下来试试！”； 这是一幅很有意思的漫画，从表面上看我们可以认为在绿色草地上的工人是站着说话不腰疼，不过其实本质的原因还是两者所处的环境不同。\n在一片未开发过的土地上施工确实是很舒服的，因为空间很大，也没有周遭各种限制，可以使用各种新技术、新理念，我们国家近几十年来的一些新区新城的建设就属于这类。而在一片已经开发过的土地上施工就大不一样了，周围环境会有各种限制，比如地下可能有各种管线，一不小心就挖断了，附近还有各种大楼，稍有不慎就可能把楼给挖塌了，所以做起事来就要非常小心，设计方案时也会受到各种约束，无法自由发挥。\n对于软件工程，其实也是一样的，Greenfield 对应着全新的项目或新的系统，Brownfield 对应着成熟的项目或遗留系统。\n我相信大部分程序员都是喜欢做全新的项目的，包括我自己也是一样。因为可以使用新的技术、新的框架，可以按照事物本来的样子去做系统设计，自由度很高。而在开发/维护一个成熟的项目时就不太一样了，一方面项目已经稳定运行，逻辑也非常复杂，所以无法很方便地换成新的技术、新的框架，在设计新功能时也会碍于已有的架构和代码实现做很多妥协，另一方面前人可能不知不觉挖了很多坑，稍有不慎就会掉进坑里，所以行事必须要非常小心，尤其是在做大的架构改变的时候。\n3.3 现实场景 3.3.1 Brownfield 应用当道 在现实中，我们发现目前大部分的公司还没有走向云原生，或者还刚刚在开始探索，所以大量的应用其实还跑在非 k8s 的体系中，比如跑在虚拟机上或者是基于独立的服务注册中心构建微服务体系。\n虽然确实有少量 Greenfield 应用已经在基于云原生来构建了，但现实是那些大量的 Brownfield 应用是公司业务的顶梁柱，承载着更大的业务价值，所以如何把它们纳入 Service Mesh 统一管控，从而带来更大的价值，也就成了更需要优先考虑的话题。\n图片来源 独立的服务注册中心\n3.3.2 云原生方案离生产级尚有一定距离 另一方面，目前 Istio 在整体性能上还存在一些有待解决的点（引述小剑老师在蚂蚁金服 Service Mesh 深度实践中的观点）：\n Mixer Mixer 的性能问题，一直都是 Istio 中最被人诟病的地方； 尤其在 Istio 1.1\u0026amp;frasl;1.2 版本之后引入了 Out-Of-Process Adapter，更是雪上加霜； 从落地的角度看，Mixer V1 糟糕至极的性能，已经是“生命无法承受之重”。对于一般规模的生产级落地而言，Mixer 性能已经是难于接受，更不要提大规模落地…… Mixer V2 方案则给了社区希望：将 Mixer 合并进 Sidecar，引入 web assembly 进行 Adapter 扩展，这是我们期待的 Mixer 落地的正确姿势，是 Mixer 的未来，是 Mixer 的『诗和远方』。然而社区望穿秋水，但Mixer V2 迟迟未能启动，长期处于 In Review 状态，远水解不了近渴； Pilot Pilot 是一个被 Mixer 掩盖的重灾区：长期以来大家的性能关注点都在 Mixer，表现糟糕而且问题明显的Mixer 一直在吸引火力。但是当选择放弃 Mixer（典型如官方在 Istio 新版本中提供的关闭 Mixer 的配置开关）之后，Pilot 的性能问题也就很快浮出水面； 我们实践下来发现 Pilot 目前主要有两大问题：1）无法支撑海量数据 2）每次变化都会触发全量推送，性能较差； 图片来源\n3.4 当 …","date":1575291600,"description":"Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』，我们在产品设计上的思考和实践。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-wushi/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"30414154356f38408eac8044657b5d63","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","publishdate":"2019-12-02T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","summary":"一、引言 Service Mesh 是蚂蚁金服下一代架构的核心，经过了2年的沉淀，我们探索出了一套切实可行的方案并最终通过了双十一的考验。本文主要分享在当下『路口』","tags":["Service mesh","Service Mesh 落地实践"],"title":"Service Mesh 在『路口』的产品思考与实践：务实是根本","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/","wordcount":6226},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n社区 Big News NO.1 社区新认证一位 Committer\nGithub ID @zongtanghu 成为 SOFAJRaft Committer：\n主要贡献：\n 贡献了两个重要 Feature： 基于优先级配置的自动选举； 为 Replicator 日志复制实现 ReplicatorStateListener 监听器； 添加一些优化功能和 Bugfix： 优化 SOFAJRaft 的工具类，减少冗余代码，增加单元测试用例代码； 优化常量类，实现 Copiable 接口； 原创文章贡献 《SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理》; 《中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说》; 目前，社区已经认证超过四十位 Committer。\n感谢对 SOFAStack 的支持和帮助，也欢迎你加入 SOFAStack community~ SOFAStack 社区：https://www.sofastack.tech/awesome/\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@kaka19ace 提问：\n 为什么 MOSN 热重启机制需要新老进程，两个 unix domain socket server 通信交互? 目前分为 旧进程 reconfigerServer 新进程 transferServer, 1. reconfigerServer 只是新进程主动判断 isReconfigure() 就结束了连接； 1. 迁移 listener fd 以及 connection fd 让旧进程作为 client 角色；\n如果仅使用 reconfigerServer 作为交互通信会存在哪些问题？\n A：你的意思就是旧进程 reconfigerServer在收到 isReconfigure() 后，直接传输旧进程的fd给新进程。原理上也是可以的。这儿其实有个历史原因，最开始支持信号 fork 子进程的方式，是不需要 isReconfigure() 来判断是否存在旧进程的，通过环境变量就可以了，后来为了支持容器升级的方式，单独启一个新的进程，才需要一个机制来判断是否存在旧进程，为了改动更小，之前的逻辑不受影响，才加了这个新的 us 来通讯。\n 翻了老版本代码阅读： reconfigure 这块是基于环境变量设置 fd. fork exec 参数使用 sys.ProcAttr 继承 fd 信息。 这块有一个问题确认，老版本场景里如果升级新版的二进制文件，也是基于同目录下替换了相同的 bin 文件，然后再给老进程 hup 信号触发重启吧？\n A：是的，老版本是发送 hup 信号，然后 fork 一个子进程来做二进制升级，这个适用于虚拟机升级。而基于容器的话，是重新拉起一个容器，一个新的进程，就需要跟老的进程来交互。\n 早期版本和 Envoy uds 迁移方式不同，当时设计是有什么考虑吗？后续基于 SCM_RIGHTS 传输 fd 方式与 Envoy 类似，这块重构原因有哪些?想了解代码演进的过程。\n A：你看到代码是 listen fd 的迁移，和 Envoy 最大的不同是我们会把存量的长链接也做迁移。 代码演进是： 第一阶段， 只支持 listen fd 的迁移。 第二阶段， 支持存量长链接的迁移，hup 信号，然后 fork 的方式。 第三阶段， 支持容器间存量长链接的迁移，通过 uds 查找子进程。\n 非常感谢丰富的演进说明。重新拉起容器这块不太明白，对 Envoy 的场景理解： - 热重启是同一个容器内，Sidecar 新老进程的交接，业务进程继续运行； - Sidecar 进程管理是由 pilot-agent 进行管理，当前容器内 agent 发送热重启信号，非重新拉起容器；\nMOSN 这里指的是拉起新容器, 容器间迁移数据？uds 的路径是挂载盘?\n A：Envoy 的方式不能用镜像来管理二进制了。MOSN 除了支持 Envoy 这种容器内热升级，也支持容器间。MOSN 会拉起新容器，然后做容器间的连接迁移，uds 的路径是共享卷，2个 container 共享。\n 容器间迁移是否和业务场景有关，为何不是让旧容器自己销毁（摘掉服务发现, 并延迟一段时间自己销毁）？\n A：是的，就是为了 Sidecar 的发布对用户无感知，连接不断，升级 Sidecar 的时候服务也一直在运行。 MOSN：https://github.com/sofastack/sofa-mosn\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFAJRaft v1.3.0 版本，主要变更如下：\n 新增 Read-only member(learner) 角色，支持 learner 节点上的线性一致读 实现优先级选举 在 multi-raft-group 的场景中，随机打散每个 group 的第一次 snapshot timeout 时间，避免一个进程内多个 group 同时 snapshot RheaKV 实现 snapshot checksum 以及异步 snapshot 致谢（排名不分先后）：@zongtanghu @devYun @masaimu @SteNicholas @yetingsky 详细发布报告： https://github.com/sofastack/sofa-jraft/issues/362\n社区活动 回顾 11月24日 Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动回顾：\n 蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇（文末含分享视频回顾以及 PPT 查看地址） 预告 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔 …","date":1575010800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191129/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"af340bf3bee03aa71221229aee4c986b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191129/","publishdate":"2019-11-29T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191129/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/25 - 11/29】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191129/","wordcount":2060},{"author":"鲁直、碧远","categories":"Service mesh","content":" 蚂蚁金服云原生负责人鲁直 双十一后首次线下分享\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA（service-oriented architecture，面向服务的架构）体系快速演进至 Service Mesh 架构。聚焦 RPC 层面的设计和改造方案，本次将分享蚂蚁金服双十一核心应用是如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本。\n蚂蚁金服每年双十一大促会面临非常大的流量挑战，在已有 LDC（Logical Data Center，逻辑数据中心，是蚂蚁金服原创的一种“异地多活单元化架构”实现方案）微服务架构下已支撑起弹性扩容能力。本次分享主要分为 5 部分：\n Service Mesh 简介； 为什么要 Service Mesh； 方案落地； 分时调度案例； 思考与未来； 作者简介 黄挺（花名：鲁直）：蚂蚁金服云原生负责人 主要 Focus 领域：\n SOFAStack 微服务领域； Service Mesh，Serverless 等云原生领域； 雷志远（花名：碧远）：蚂蚁金服 RPC 框架负责人 主要 Focus 领域：\n 服务框架：SOFARPC（已开源）； Service Mesh：MOSN（已开源）； SOFARPC：https://github.com/sofastack/sofa-rpc\nMOSN：https://github.com/sofastack/sofa-mosn\nService Mesh 简介 在讲具体的蚂蚁金服落地之前，想先和大家对齐一下 Service Mesh 的概念，和蚂蚁金服对应的产品。这张图大家可能不陌生，这是业界普遍认可的 Service Mesh 架构，对应到蚂蚁金服的 Service Mesh 也分为控制面和数据面，分别叫做 SOFAMesh 和 MOSN，其中 SOFAMesh 后面会以更加开放的姿态参与到 Istio 里面去。\n今天我们讲的实践主要集中在 MOSN 上，以下我的分享中提到的主要就是集中在数据面上的落地，这里面大家可以看到，我们有支持 HTTP/SOFARPC/Dubbo/WebService。\n为什么我们要 Service Mesh 有了一个初步的了解之后，可能大家都会有这样一个疑问，你们为什么要 Service Mesh，我先给出结论：\n因为我们要解决在 SOA 下面，没有解决但亟待解决的：基础架构和业务研发的耦合，以及未来无限的对业务透明的稳定性与高可用相关诉求。\n那么接下来，我们一起先看看在没有 Service Mesh 之前的状况。\n在没有 Service Mesh 之前，整个 SOFAStack 技术演进的过程中，框架和业务的结合相当紧密，对于一些 RPC 层面的需求，比如流量调度，流量镜像，灰度引流等，是需要在 RPC 层面进行升级开发支持，同时，需要业务方来升级对应的中间件版本，这给我们带来了一些困扰和挑战。如图所示：\n 线上客户端框架版本不统一； 业务和框架耦合，升级成本高，很多需求由于在客户端无法推动，需要在服务端做相应的功能，方案不够优雅； 机器逐年增加，如果不增加机器，如何度过双十一； 在基础框架准备完成后，对于新功能，不再升级给用户的 API 层是否可行；  流量调拨，灰度引流，蓝绿发布，AB Test 等新的诉求； 这些都困扰着我们。我们知道在 SOA 的架构下，负责每个服务的团队都可以独立地去负责一个或者多个服务，这些服务的升级维护也不需要其他的团队的接入，SOA 其实做到了团队之间可以按照接口的契约来接耦。但是长期以来，基础设施团队需要推动很多事情，都需要业务团队进行紧密的配合，帮忙升级 JAR 包，基础设施团队和业务团队在工作上的耦合非常严重，上面提到的各种问题，包括线上客户端版本的不一致，升级成本高等等，都是这个问题带来的后果。\n而 Service Mesh 提供了一种可能性，能够将基础设施下沉，让基础设施团队和业务团队能够解耦，让基础设施和业务都可以更加快步地往前跑。\n我们的方案 说了这么多，那我们怎么解决呢？我们经历了这样的选型思考。\n总体目标架构 我们的 MOSN 支持了 Pilot、自有服务发现 SOFARegistry 和自有的消息组件，还有一些 DB 的组件。在产品层，提供给开发者不同的能力，包括运维、监控、安全等能力，这个是目前我们的一个线上的状态。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n 看上去很美好，要走到这个状态，我们要回答业务的三个灵魂拷问。\n这三个问题后面，分别对应着业务的几大诉求，大家做过基础框架的应该比较有感触。\n框架升级方案 准备开始升级之后，我们要分析目前我们的线上情况，而我们现在线上的情况，应用代码和框架有一定程度的解耦，用户面向的是一个 API，最终代码会被打包，在 SOFABoot 中运行起来。\n SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n 那么，我们就可以在风险评估可控的情况下，直接升级底层的 SOFABoot。在这里，我们的 RPC 会检测一些信息，来确定当前 Pod 是否需要开启 MOSN 的能力。然后我们完成如下的步骤。\n我们通过检测 PaaS 传递的容器标识，知道自己是否开启了 MOSN，则将发布和订阅给 MOSN，然后调用不再寻址，直接完成调用。\n可以看到，通过批量的运维操作，我们直接修改了线上的 SOFABoot 版本，以此，来直接使得现有的应用具备了 MOSN 的能力。有些同学可能会问，那你一直这么做不行吗？不行，因为这个操作是要配合流量关闭等操作来运行的，也不具备平滑升级的能力，而且直接和业务代码强相关，不适合长期操作。\n这里我们来详细回答一下，为什么不采用社区的流量劫持方案？\n主要的原因是一方面 iptables 在规则配置较多时，性能下滑严重。另一个更为重要的方面是它的管控性和可观测性不好，出了问题比较难排查。蚂蚁金服在引入 Service Mesh 的时候，就是以全站落地为目标的，而不是简单的“玩具”，所以我们对性能和运维方面的要求非常高，特别是造成业务有损或者资源利用率下降的情况，都是不能接受的。\n容器替换方案 解决了刚刚提到的第一个难题，也只是解决了可以做，而并不能做得好，更没有做得快，面对线上数十万带着流量的业务容器， 我们如何立刻开始实现这些容器的快速稳定接入？\n这么大的量，按照传统的替换接入显然是很耗接入成本的事情，于是我们选择了原地接入，我们可以来看下两者的区别：\n在之前，我们做一些升级操作之类的，都是需要有一定的资源 Buffer，然后批量的进行操作， …","date":1574946000,"description":" 聚焦 RPC 层面的设计和改造方案，本次将分享蚂蚁金服双十一核心应用是如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3d67d3c4d38ced6f9de8a92364c0827c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","publishdate":"2019-11-28T21:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","summary":"蚂蚁金服云原生负责人鲁直 双十一后首次线下分享 引言 Service Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/","wordcount":4496},{"author":"悟尘","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第五篇 - 网关篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 本文结合无线网关的发展历程，解读进行 Service Mesh 改造的缘由和价值，同时介绍在双十一落地过程中如何保障业务流量平滑迁移至新架构下的 Mesh 网关。分享将从如下三个方面展开：\n 网关的前世今生，解释网关为什么要 Mesh 化； 网关 Mesh 化，阐述如何进行 Mesh 化改造； 双十一落地，介绍在此过程中实现三板斧能力； 前世今生 蚂蚁金服无线网关当前接入数百个业务系统，提供数万个 API 服务，是蚂蚁金服客户端绝对的流量入口，支持的业务横跨支付宝、网商、财富、微贷、芝麻和国际 A+ 等多种场景。面对多种业务形态、复杂网络结构，无线网关的架构也在不断演进。\n中心化网关 在 All In 无线的年代，随着通用能力的沉淀，形成了中心化网关 Gateway。\n 客户端连接到网关接入层集群 Spanner ； Spanner 会把客户端请求转发到无线网关集群 Gateway； Gateway 提供通用能力如鉴权、限流等处理请求，并根据服务标识将请求路由到正确的后端服务；服务处理完请求，响应原路返回； 2016 年新春红包爆发，蚂蚁森林等新兴业务发展壮大，网关集群机器数不断增长。这加剧了运维层面的复杂性，IT成本也不能承受之重。同时，一些核心链路的业务如无线收银台、扫一扫等，迫切需要与其他业务隔离，避免不可预知的突发流量影响到这些高保业务的可用性。因此，2016 年下半年开始建设和推广去中心化网关。\n去中心化网关 去中心化网关将原先集中式网关的能力进行了拆分：\n 转发逻辑：将 Gateway 中根据服务标识转发的能力迁移到 Spanner 上； 网关逻辑：将网关通用能力如鉴权、限流、LDC 等功能，抽成一个 mgw jar 集成到业务系统中，与后端服务同JVM 进程运行； 此时，客户端请求的处理流程如下：\n 客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务的 mgw 中； mgw 进行通用网关能力处理，90% 的请求随即进行 JVM 内部调用； 去中心化网关与集中式网关相比，具有如下优点：\n 提升性能： 少一层网关链路，网关 jar 调用业务是 JVM 内部调用； 大促期间，无需关心网关的容量，有多少业务就有多少网关； 提高稳定性： 集中式网关形态下，网关出现问题，所有业务都会收到影响； 去中心化后，网关的问题，不会影响去中心化的应用； 但凡事具有两面性，随着在 TOP30 的网关应用中落地铺开，去中心化网关的缺点也逐步显现：\n 研发效能低： 接入难：需要引入 15+ pom 依赖、20+ 的配置，深度侵入业务配置； 版本收敛难：当前 mgw.jar 已迭代了 40+ 版本，当前还有业务使用的是初版，难以收敛； 新功能推广难：新能力上线要推动业务升级和发布，往往需要一个月甚至更久时间； 干扰业务稳定性： 依赖冲突，干扰业务稳定性，这种情况发生了不止一次； 网关功能无法灰度、独立监测，资源占用无法评估和隔离； 不支持异构接入：财富域大部分系统是 Node 技术栈，无法使用去中心化网关；  Mesh 网关 去中心化网关存在的诸多问题，多数是由于网关功能与业务进程捆绑在一起造成的。这引发了我们的思考：如果网关功能从业务进程中抽离出来，这些问题是否就可以迎刃而解了？这种想法，与 Service Mesh 的 Sidecar 模式不谋而合。因此在去中心化网关发展了三年后，我们再出发对蚂蚁金服无线网关进行了 Mesh 化改造，以期籍此解决相关痛点。\nMesh 网关与后端服务同 Pod 部署，即 Mesh 网关与业务系统同服务器、不同进程，具备网关的全量能力。客户端请求的处理流程如下：\n 客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务同 Pod 中的 Mesh 网关； Mesh 网关执行通用逻辑后调用同机不同进程的业务服务，完成业务处理； 对比去中心化网关的问题，我们来分析下 Mesh 网关所带来的优势：\n 研发效能： 接入方便：业务无需引入繁杂的依赖和配置，即可接入 Mesh 网关； 版本容易收敛、新功能推广快：新版本在灰度验证通过后，即可全网推广升级，无需维护和排查多版本带来的各种问题； 业务稳定性： 无损升级：业务系统无需感知网关的升级变更，且网关的迭代升级将可利用 MOSN 现有的特性进行细粒度的灰度和验证，做到无损升级； 独立监测：由于和业务系统在不同进程，可以实时遥测 Mesh 网关进程的表现，并据此评估和优化，增强后端服务稳定性； 异构系统接入：Mesh 网关相当于一个代理，对前端屏蔽后端的差异，将支持 SOFARPC、Dubbo 和 gRPC 等主流 RPC 协议，并支持非 SOFA 体系的异构系统接入； 至此，我们卖瓜自夸式地讲完了无线网关的前世今生，解释了为何要撸起袖子进行网关 Mesh 化。但细心的你想必怀疑：\n Mesh 化之后的请求处理流程不是同进程调用，比起去中心化网关多了一跳，是否有性能损耗？ 毕竟进行了大刀阔斧的变革，在上线过程中如何保障稳定性？ 接下来的章节将对上述问题进行解释。\nMesh 化 架构 首先，从架构层面详细介绍网关 Mesh 化所做的相关工作。依照 Service Mesh 的分层模型，Mesh 网关分为数据面和控制面。\n解读：\n 蓝色箭头线是客户端请求的处理流程，Mesh 网关数据面在蚂蚁金服内部 MOSN 的 Sidecar 中； 绿色箭头线是网关配置下发过程，Mesh 网关控制面当前还是由网关管控平台来承载； 红色箭头线条是 MOSN Sidecar 的运维体系； MOSN：https://github.com/sofastack/sofa-mosn\n数据面 采用 Go 语言实现了原先网关的全量能力，融合进 MOSN 的模型中，复用了其他组件已有的能力。 同时网络接入层 Spanner 也实现了请求分发决策能力。\n数据转换 将客户端的请求数据转换成后端请求数据，将后端响应数据转换成客户端响应。利用 MOSN 协议层扩展能力，实现了对网关自有协议 Mmtp 的解析能力。\n通用功能 授权、安全、限流、LDC 和重试等网关通用能力。利用 MOSN Stream Filter 注册机制以及统一的 Stream Send/Receive Filter 接口扩展而来。\n请求路由 客户端请求按照特定规则路由到正确的后端系统。在网关层面实现 LDC 逻辑后，复用 MOSN RPC 组件的路由匹配能力。其中大部分请求都会路由到当前 Zone，从而直接请求到当前 Pod 的业务进程端口。\n后端调用 支持调用多种类型的后端服务，支持对 SOFARPC、Chair 等后端，后期计划支持更多的 RPC 框架和异构系统。\n控制面 为网关用户提供新增、配置 API 等服务的管控系统，可将网关配置数据下发至 Mesh …","date":1574946000,"description":" 本文结合无线网关的发展历程，解读进行 Service Mesh 改造的缘由和价值，同时介绍在双十一落地过程中如何保障业务流量平滑迁移至新架构下的 Mesh 网关。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a51651ca16ad1df8e867f4e25296c50b","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","publishdate":"2019-11-28T21:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第五篇 - 网关篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/","wordcount":3545},{"author":"嘉祁","categories":"Service mesh","content":" 《蚂蚁金服 Service Mesh 大规模落地系列》将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析，文末包含往期系列文章。本文为该系列文章的第三篇 - 运维篇。\n引言 Service Mesh 是蚂蚁金服下一代架构的核心，也是蚂蚁金服内部向云原生演进的重要一环。本文为 Service Mesh 系列文章的运维篇，作者：黄家琦 （花名：嘉祁），蚂蚁金服运维专家，Service Mesh SRE，主要关注云原生基础设施、中间件及 Service Mesh 的稳定性，同时也是 Pythoner，sofa-bolt-python 作者。\n本文将主要分享大规模服务网格在蚂蚁金服当前体量下落地到支撑蚂蚁金服双十一大促过程中，运维角度所面临的挑战与演进。内容包括云原生化的选择与问题，对资源模型的挑战，大规模下运维设施的演进，以及周边技术风险能力的建设。\nService Mesh 在2019年得到了大规模的应用与落地，截止目前，蚂蚁金服的 Service Mesh 数据平面 MOSN 已接入应用数百个，接入容器数量达数十万，是目前已知的全世界最大的 Service Mesh 集群。同时，在刚刚结束的双十一大促中，Service Mesh 的表现也十分亮眼，RPC 峰值 QPS 达到了几千万，消息峰值 TPS 达到了几百万，且引入 Service Mesh 后的平均 RT 增长幅度控制在 0.2 ms 以内。\n拥抱云原生 Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。而在具体部署上，保守的做法是以独立进程的方式与业务进程共同存在于业务容器内。我们在蚂蚁金服内部的做法，则从开始，就选择了拥抱云原生。\nSidecar 模式 业务容器内独立进程的好处在于与传统的部署模式兼容，易于快速上线；但独立进程强侵入业务容器，对于镜像化的容器更难于管理。而云原生化，则可以将 Service Mesh 本身的运维与业务容器解耦开来，实现中间件运维能力的下沉。在业务镜像内，仅仅保留长期稳定的 Service Mesh 相关 JVM 参数，从而仅通过少量环境变量完成与 Service Mesh 的联结。同时考虑到面向容器的运维模式的演进，接入 Service Mesh 还同时要求业务完成镜像化，为进一步的云原生演进打下基础。\n 优 劣 独立进程 兼容传统的部署模式；改造成本低；快速上线 侵入业务容器；镜像化难于运维 Sidecar 面向终态；运维解耦 依赖 K8s 基础设施；运维环境改造成本高；应用需要镜像化改造 在接入 Service Mesh 之后，一个典型的 POD 结构可能包含多个 Sidecar：\n MOSN：RPC Mesh, MSG Mesh, \u0026amp;hellip;（扩展中）； 其它 Sidecar； MOSN：https://github.com/sofastack/sofa-mosn\n这些 Sidecar 容器，与业务容器共享相同的网络 Namespace，使得业务进程可以以本地端口访问 Service Mesh 提供的服务，保证了与保守做法一致的体验。\n基础设施云原生支撑 我们也在基础设施层面同步推进了面向云原生的改造，以支撑 Service Mesh 的落地。\n业务全面镜像化 首先是在蚂蚁金服内部推进了全面的镜像化，我们完成了内部核心应用的全量容器的镜像化改造。改造点包括：\n 基础镜像层面增加对于 Service Mesh 的环境变量支撑； 应用 Dockerfile 对于 Service Mesh 的适配； 推进解决了存量前后端分离管理的静态文件的镜像化改造； 推进了大量使用前端区块分发的应用进行了推改拉的改造； 大批量的 VM 模式的容器升级与替换； 容器 POD 化 除了业务镜像层面的改造，Sidecar 模式还需要业务容器全部跑在 POD 上，来适应多容器共享网络。由于直接升级的开发和试错成本很高，我们最终选择将接入 Service Mesh 的 数百个应用的数万个非 K8s 容器，通过大规模扩缩容的方式，全部更换成了 K8s PODs。\n经过这两轮改造，我们在基础设施层面同步完成了面向云原生的改造。\n资源的演进 Sidecar 模式的带来一个重要的问题，如何分配资源。\n理想比例的假设 最初的资源设计基于内存无法超卖的现实。我们做了一个假设：\n MOSN 的基本资源占用与业务选择的规格同比例这一假设。 CPU 和 Memory 申请与业务容器相应比例的额外资源。这一比例最后设定在了 CPU 1/4，Memory 1/16。\n此时一个典型 Pod 的资源分配如下图示：\n这一方式带来了两个问题：\n 蚂蚁金服已经实现了业务资源的 Quota 管控，但 Sidecar 并不在业务容器内，Service Mesh 容器成为了一个资源泄漏点； 业务很多样，部分高流量应用的 Service Mesh 容器出现了严重的内存不足和 OOM 情况； 完美分割的不完美 不止于此，为了快速支撑 Service Mesh 在非云环境的铺开，上线了原地接入 Service Mesh。而原地接入 Service Mesh 的资源无法额外分配，在内存不能超卖的情况下，采取了二次分割的分配方式。此时的 POD 内存资源被切分为1/16内存给 Sidecar，与15/16给业务容器。除了以上两个问题，还带来一些新的问题：\n 业务可见内存不一致，业务监控偏差，业务进程 OOM 风险。 讨论之后，我们追加了一个假设：\n Service Mesh 容器占用的资源实质是在接入 Service Mesh 之前业务已使用的资源。接入 Service Mesh 的过程，同时也是一次资源置换。 共享 基于这个假设，推进了调度层面支持 POD 内的资源超卖，新的资源分配方案如下图，Service Mesh 容器的 CPU、MEM 都从 POD 中超卖出来，业务容器内仍然可以看到全部的资源。\n考虑到内存超卖也引入了 POD OOM 的风险，因此对于 Sidecar 容器还调整了 OOM Score，保证在内存不足时，Service Mesh 进程能够发挥启动比 Java 业务进程更快的优势，降低影响。\n新的分配方案解决了同时解决了以上两个问题，并且平稳支持了大促前的多轮压测。\n重建 但新的分配方案上线时，Service Mesh 已经在弹性建站时同步上线。同时我们还发现在一些场景下，Service Mesh 容器无法抢占到 CPU 资源，导致业务 RT 出现了大幅抖动，原因是在 CPU Share 模式下，POD 内默认并没有等额的分配 CPU Quota 给 Sidecar。\n于是还有两个问题待解决：\n 存量的已分配 Sidecar 仍有 OOM 风险； Sidecar 无法抢占到 CPU； 我们已经无法承受更换全部 POD 的代价。最终在调度的支持下，通过对 Pod Annotation 的手动重新计算+修改，在 POD 内进行了全部资源的重分配，来修复这两个风险。最终的修复容器总数约 25w 个。 …","date":1574859600,"description":" 本文将主要分享大规模服务网格在蚂蚁金服当前体量下落地到支撑蚂蚁金服双十一大促过程中，运维角度所面临的挑战与演进。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b4428f1c979dfa574a7ec8b4d96bc191","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","publishdate":"2019-11-27T21:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","summary":"《蚂蚁金服 Service Mesh 大规模落地系列》将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析，文末","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/","wordcount":4049},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解\n 活动时间：12 月 5 日周四晚 7 点\n 活动形式：线上直播\n 直播回看：戳这里\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。\n12 月 5 日周四晚 7 点，将邀请蚂蚁金服技术专家卓与 ，聚焦 RPC 层面的设计和改造方案，分享蚂蚁金服双十一核心应用如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本，并从核心、RPC、消息等模块展开本次双十一落地实践的实现细节分享。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/1021\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 蚂蚁金服 Service Mesh 双十一落地详解 卓与 蚂蚁金服 Service Mesh 落地负责人\n本期分享大纲： 蚂蚁金服 Service Mesh 架构双十一大规模落地实践案例分析； 从核心、RPC、消息等模块分享蚂蚁金服 Service Mesh 落地实践细节； 欢迎先阅读Service Mesh 落地系列文章，收看直播收获更好的效果； 嘉宾 SOFAGirl 主持人 卓与 蚂蚁金服 Service Mesh 落地负责人 ","date":1574741400,"description":"12 月 5 日周四晚 7 点，线上直播第 9 期。","dir":"activities/sofa-channel-9/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"33ec75a1b0e23d96934a7ec43dfa5df5","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-9/","publishdate":"2019-11-26T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-9/","summary":"概要 活动主题：SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解 活动时间：12 月 5 日周四晚 7 点 活动形式：线上直播 直播回看：戳这里 介绍 | SOFAChannel","tags":["SOFAChannel","Service Mesh"],"title":"SOFAChannel#9：蚂蚁金服 Service Mesh 双十一落地详解","type":"activities","url":"/sofastack.tech/activities/sofa-channel-9/","wordcount":554},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@J～杰 提问：\n 帮我看个问题，标红的这个状态没执行是啥原因？ A：没有 Next 属性，可以下载 seata-sample，里面有例子，https://github.com/seata/seata-samples。\n 好的，CompensateState 这个属性是正向失败后，重试这个状态？\n A：正向失败后，触发这个补偿状态。 https://github.com/seata/seata/tree/develop/test/src/test/java/io/seata/saga/engine 为里有很多单元测试案例，代码对应的json在：https://github.com/seata/seata/tree/develop/test/src/test/resources/saga/statelang。 正向失败后，触发这个 CompensateState 状态，但失败后并不会默认就触发补偿流程，需要在 Catch 属性里，Next 到一个 CompensateTrigger。\n 那 Saga 模式下，如果 TC 端发出回滚命令，Saga 怎么处理，没发现有回滚状态？\n A：Saga 模式的 TCC 模式有点不一样的是，Saga 的回滚不是由 TC 来协调，而是只 TC 触发，回滚流程是由状态机执行的。 https://github.com/seata/seata/blob/develop/test/src/test/resources/saga/statelang/simple_statelang_with_compensation.json\n这里是 Catch 到异常后，可以自定义捕获某些异常，然后 Next 到一个处理 state，这个 state 可以是任何 state，如果是 CompensateTrigger 则立即进行回滚。\n Saga 是通过检测异常来识别回滚命令？\n A：Catch 属性是用来检测异常的，但异常的处理可能不仅仅是进行回滚，可能有别的处理逻辑，因业务不同而不同，catch 到这些异常处理，你可以 Next 到任何一个 state 来处理异常；如果希望回滚，框架提供了 CompensateTrigger 这种一个特定的 state，Next 到 CompensateTrigger，则立即进行回滚。\n 如果一个 Saga 状态失败后，RM 一直会重试，这个重试有没有次数限制的？\n A：https://github.com/seata/seata/blob/develop/server/src/main/resources/file.conf.example 重试间隔和重试超时时间, -1是无限重试，比如可以配置成 1d ，只重度一天。\n 还有个问题，发现 catch 没有捕捉到 RuntimeExcepeion 异常： A：它走到 Fail 那个状态去了吗？另外就是 Status 是会执行的，catch 异常和状态判断是两个互不干扰的事情。\n 就是没有走到 Fail 那个状态才奇怪，刚开始我是把 Status 给去掉的，也没走，后来就加上的。这个重试是状态为 un 的时候，TC 就会一直发起重试的吧？\n A：如果没有发起过回滚（补偿流程），失败后 TC 会重试继续完成状态机正向执行，如果发了回滚，回滚失败后 TC 会重试回滚。\n 那如果发生回滚，是从哪个状态节点开始回滚的？\n A：从失败的节点开始。\n 是通过读这张表的数据 seata_state_inst？\n A：对。\nSeata：https://github.com/seata/seata\n2、@胡文伟 提问：\n 双模微服务是指什么？\n A：所谓双模，是指 SOFA 微服务和 Service Mesh 技术的双剑合璧，即“基于 SDK 的 SOFA 微服务”可以和“基于 Sidecar 的 Service Mesh 微服务”实现下列目标： 互联互通：两个体系中的应用可以相互访问； 平滑迁移：应用可以在两个体系中迁移，对于调用该应用的其他应用，做到透明无感知； 异构演进：在互联互通和平滑迁移实现之后，我们就可以根据实际情况进行灵活的应用改造和架构演进。\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题 SOFA 项目进展 本周发布详情如下：\n1、发布 MOSN v0.8.1，主要变更如下：\n 新增 MOSN 处理失败请求数的统计； 提升写共享内存时的性能； 优化内存占用与日志输出； 修复日志文件轮转的 Bug； 详细发布报告：https://github.com/sofastack/sofa-mosn/releases/tag/0.8.1\nSOFAChannel 直播推荐 Service Mesh 是蚂蚁金服下一代架构的核心，本期直播主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。聚焦 RPC 层面的设计和改造方案，分享蚂蚁金服双十一核心应用如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并降低大促成本，并从核心、RPC、消息等模块展开分享本次双十一落地实践的实现细节。\n你将收获：\n 蚂蚁金服 Service Mesh 架构双十一大规模落地实践案例分析； 从核心、RPC、消息等模块分享蚂蚁金服 Service Mesh 落地实践细节； 时间：2019年12月5日（周四）19:00-20:00 形式：线上直播 报名方式：点击“这里”即可报名\n","date":1574406000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191122/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d1021e16b4acefdf05a527584900ba69","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191122/","publishdate":"2019-11-22T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191122/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/18 - 11/22】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191122/","wordcount":2007},{"author":"无勤","categories":"Service mesh","content":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。\n引言 Service Mesh 作为蚂蚁金服向下一代云原生架构演进的核心基础设施，在2019年得到了大规模的应用与落地，截止目前，蚂蚁金服的 Service Mesh 数据平面 MOSN 已接入应用数百个，接入容器数量达数十万，一举成为全世界最大的 Service Mesh 集群。同时，在刚刚结束的双十一大促中，Service Mesh 的表现也十分亮眼，RPC 峰值 QPS 达到了几千万，消息峰值 TPS 达到了几百万，且引入 Service Mesh 后的平均 RT 增长幅度控制在 0.2 ms 以内。\n本文作为整个 Service Mesh 系列文章的消息篇，作者：刘翔（花名：无勤），蚂蚁金服消息 Mesh 负责人， 消息中间件核心研发成员，专注于高吞吐、低延迟的消息中间件研发，以及云原生时代下一代消息系统的架构设计与研发。本文将从以下几个方面对消息 Mesh 进行解读：\n 对消息 Mesh 进行介绍，解答消息 Mesh 在整个 Service Mesh 中的地位是什么，它又能为业务带来哪些价值； 结合蚂蚁金服消息中间件团队 Mesh 化的实践与思考，阐述如何在消息领域进行 Mesh 化改造； 消息 Mesh 在蚂蚁金服内部大规模落地过程中遇到的问题与挑战，以及对应的解决方案； 消息流量精细化调度上的思考与在 Mesh 上的实现与落地； 消息 Mesh 简介 Service Mesh 作为云原生场景下微服务架构的基础设施（轻量级的网络代理），正受到越来越多的关注。Service Mesh 不仅负责在微服务架构的复杂拓扑中可靠地传递请求，也将限流、熔断、监控、链路追踪、服务发现、负载均衡、异常处理等与业务逻辑无关的流量控制或服务治理行为下沉，让应用程序能更好地关注自身业务逻辑。\n微服务架构中的通信模式实际上是多种多样的，既包含同步的请求调用，也包含异步的消息/事件驱动，然而流行的 Service Mesh 实现（Istio，Linkerd，Consul Connect等），都仍局限在对微服务中同步请求调用的关注，却无法管理和追踪异步消息流量。而消息 Mesh 则是对这一块的重要补充，通过将消息 Mesh 有机地融合到 Service Mesh 中，可以帮助 Service Mesh 实现对所有微服务流量的管控和追踪，从而进一步完善其架构目标。\n消息 Mesh 的价值 在传统的消息中间件领域，我们更关注的是消息服务端的性能、服务可用性、数据可靠性等核心指标，而与业务应用密切相关的一些能力，包括消息的流量控制（限流、熔断、灰度、着色、分组等），消息的服务治理（消息量级与消息应用拓扑等），消息链路的追踪（消息轨迹）却往往不尽如人意。\n这不仅是因为传统模式下上述能力的提供和优化都涉及客户端的改造与大规模升级，整个过程常常比较漫长，难以快速根据有效反馈不断优化，更重要的是缺乏一个统一的架构指导思想，混乱无序地向客户端叠加相关功能只会让消息客户端变得越来越臃肿和难以维护，也变向增加了业务系统的接入、调试和排查问题的成本。而消息 Mesh 作为 Service Mesh 的补充，能显著带来如下价值和收益：\n 快速升级 - 通过将与业务逻辑无关的一些核心关键能力下沉到 Sidecar 中，使这些能力的单独快速迭代与升级成为可能； 流量控制 - 可以向 Sidecar 中集成各种流量控制策略，例如可根据消息类型、消息数量、消息大小等多种参数来控制消息的发送和消费速率； 流量调度 - 通过打通 Sidecar 节点之间的通信链路，可以利用 Sidecar 的流量转发来实现任意精度的消息流量调度，帮助基于事件驱动的微服务应用进行多版本流量管理、流量着色、分组路由、细粒度的流量灰度与A/B策略等； 消息验证 - 消息验证在基于事件驱动的微服务架构中正变得越来越重要，通过将这部分能力下沉到 Sidecar，不仅可以让业务系统无缝集成消息验证能力，也可以让 Sidecar 通过 Schema 理解消息内容，并进一步具备恶意内容识别等安全管控能力； 可观测性 - 由于所有的消息流量都必须通过 Sidecar，因此可以为 Sidecar 上的消息流量按需增加 Trace 日志，Metrics 采集，消息轨迹数据采集等能力，并借此进一步丰富消息服务的治理能力； 消息 Mesh 化改造 在蚂蚁金服内部，Msgbroker 基于推模型提供高可靠、高实时、事务消息、header 订阅等特性，帮助核心链路进行异步解耦，提升业务的可扩展能力，并先后伴随蚂蚁金服众多核心系统一起经历了分布式改造、单元化改造与弹性改造，目前主要承载蚂蚁内部交易、账务、会员、消费记录等核心在线业务的异步消息流量。\n由于 Service Mesh 的推进目标也是优先覆盖交易支付等核心链路，为在线业务赋能，因此我们优先选择对 Msgbroker 系统进行 Mesh 化改造。下面将以 Msgbroker 为例，重点剖析 Mesh 化后在整体架构和核心交互流程上的变化，为消息领域的 Mesh 化改造提供参考。\n整体架构 消息 Mesh 化后的整体架构如上图所示，与原有的消息架构相比，主要的变化有：\n 客户端不再与服务端直连，而是通过 Sidecar 进行请求的中转，对客户端而言，Sidecar 实际上是它唯一能感知到的消息服务端，对服务端而言，Sidecar 则扮演着客户端的角色； 所有 Sidecar 都会与控制平面交互，接收服务端地址列表、流量管控和调度配置、运行时动态配置等的下发，从而使数据平面具备限流、熔断、异常重试、服务发现、负载均衡、精细化流量调度等能力； 核心交互流程 当 Sidecar 代理了消息客户端的所有请求后，一旦 Sidecar 完成消息服务的发现与服务端/客户端路由数据的缓存，无论是客户端的发消息请求还是服务端的推消息请求，都能由 Sidecar 进行正确的代理转发，而这一切的关键，则是 Sidecar 与消息客户端协同完成一系列的初始化操作。\n消息 Mesh 化后具体的初始化流程如下所示，与原有的初始化流程相对比，主要有如下不同：\n 在经过 Mesh 化改造后，消息客户端不再直接向 SOFARegistry 订阅消息服务端的地址，而是将所有消息元数据（包含业务应用声明的消息 Topic、发送/订阅组 GroupId 等关键信息）通过 HTTP 请求上报给 MOSN，由 MOSN 进行元数据的持久化（用于 MOSN 异常 Crash 后的恢复）以及消息服务端地址的订阅和处理； 当客户端收到 MOSN 对于注册请求的响应时，会主动与 MOSN 建立连接，并将与该连接相关的 Group 集合信息通过控制指令发送给 MOSN，由于客户端与 MOSN 可能存在多个连接，且不同连接上的 Group 集合可以不同，而 MOSN 与同一个消息服务端只维持一个连接，因此控制指令无法向消息数据一样直接进行转发，而是需要 …","date":1574326800,"description":" 本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇-消息篇","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1778dffdda6a839ad3e72183df3393d6","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","publishdate":"2019-11-21T17:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","summary":"本文为《蚂蚁金服 Service Mesh 大规模落地系列》第二篇，该系列将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/","wordcount":4722},{"author":"卓与","categories":"Service mesh","content":" 2019 年的双十一是蚂蚁金服的重要时刻，大规模落地了 Service Mesh 并顺利保障双十一平稳渡过。我们第一时间与这次的落地负责人进行了交流。\n采访的开头： 花肉：“这次大规模上了 Service Mesh ，双十一值班感觉是什么？” 卓与：“Service Mesh 真的稳。”\n 图为卓与 TOP100 北京峰会分享现场图\n落地负责人介绍 Service Mesh 是蚂蚁金服下一代架构的核心，今年蚂蚁金服大规模的 Service Mesh 落地，我有幸带领并面对了这个挑战，并非常平稳的通过了双十一的大考。\n我个人主要专注在微服务领域，在服务注册与服务框架方向深耕多年，主导过第五代服务注册中心（SOFARegistry）设计与实施，在微服务的架构演进中持续探索新方向，并在蚂蚁金服第五代架构演进中负责内部 Service Mesh 方向的架构设计与落地。\nSOFAStack：https://github.com/sofastack SOFAMosn：https://github.com/sofastack/sofa-mosn\nService Mesh 在蚂蚁金服 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已经渡过探索期，今年已经全面进入深水区探索。\n2019 年的双十一是我们的重要时刻，我们进行了大规模的落地，可能是目前业界最大规模的实践。作为技术人能面对世界级的流量挑战，是非常紧张和兴奋的。当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？我们借助四个“双十一考题”一一为大家揭晓。\nService Mesh 背景知识 Service Mesh 这个概念社区已经火了很久，相关的背景知识从我们的公众号内可以找到非常多的文章，我在这里不做过于冗余的介绍，仅把几个核心概念统一，便于后续理解。\n图1. Service Mesh 开源架构来自 https://istio.io/\nIstio 的架构图上清晰的描述了 Service Mesh 最核心的两个概念：数据面与控制面。数据面负责做网络代理，在服务请求的链路上做一层拦截与转发，可以在链路中做服务路由、链路加密、服务鉴权等，控制面负责做服务发现、服务路由管理、请求度量（放在控制面颇受争议）等。\nService Mesh 带来的好处不再赘述，我们来看下蚂蚁金服的数据面和控制面产品，如下图：\n图2. 蚂蚁金服 Service Mesh 示意架构\n数据面：SOFAMosn。蚂蚁金服使用 Golang 研发的高性能网络代理，作为 Service Mesh 的数据面，承载了蚂蚁金服双十一海量的核心应用流量。\n控制面：SOFAMesh。Istio 改造版，落地过程中精简为 Pilot 和 Citadel，Mixer 直接集成在数据面中避免多一跳的开销。\n2019 Service Mesh 双十一大考揭秘 双十一 SOFAMosn 与 SOFAMesh 经历海量规模大考，顺利保障双十一平稳渡过。今年双十一蚂蚁金服的百十多个核心应用全面接入 SOFAMosn，生产 Mesh 化容器几十万台，双十一峰值 SOFAMosn 承载数据规模数千万 QPS，SOFAMosn 转发平均处理耗时 0.2ms。\n图3. 双十一落地数据\n在如此大规模的接入场景下，我们面对的是极端复杂的场景，同时需要多方全力合作，更要保障数据面的性能稳定性满足大促诉求，整个过程极具挑战。下面我们将从几个方面来分享下我们在这个历程中遇到的问题及解决方案。\n双十一考题 如何让 Service Mesh 发挥最大的业务价值？ 如何达成几十万容器接入 SOFAMosn 的目标？ 如何处理几十万容器 SOFAMosn 的版本升级问题？ 如何保障 Service Mesh 的性能与稳定性达标？ 落地架构 为了更加方便的理解以上问题的解决与后续介绍中可能涉及的术语等，我们先来看下 Service Mesh 落地的主要架构：\n图4. Service Mesh 落地架构\n以上架构图中主要分几部分：\n 数据面：借助 Kubernetes 中的 Pod 模型，SOFAMosn 以独立镜像和 App 镜像共同编排在同一个 Pod 内，共享相同的 Network Namespace、CPU、Memory，接入 SOFAMosn 后所有的 App RPC 流量、消息流量均不在直接对外，而是直接和 SOFAMosn 交互，由 SOFAMosn 直接对接服务注册中心做服务发现，对接 Pilot 做配置下发，对接 MQ Server 做消息收发等； 控制面：由 Pilot、Citadel 和服务注册中心等组件组成，负责服务地址下发、服务路由下发、证书下发等； 底层支撑：Sidecar 的接入与升级等均依赖 Kubernetes 能力，通过 webhook 做 Sidecar 的注入，通过 Operator 做 Sidecar 的版本升级等，相关运维动作均离不开底层的支撑； 产品层：结合底层提供的原子能力做运维能力封装，监控对接，采集 Sidecar 暴露的 Metrics 数据做监控与预警，流量调控，安全等产品化能力； 蚂蚁金服的答卷 1. 如何让 Service Mesh 发挥最大的业务价值？ 作为一个技术人，我们非常坚持不要为了技术革新本身去做技术革新，一定要让技术帮助业务，用技术驱动业务。这几年随着大家消费习惯以及网络行为的改变，双十一面对的业务场景远比想象中复杂。举个例子大家感受下，大家有没有发现你的女友或者老婆每天对着李佳琦的淘宝直播购物，主播们不断的、实时的红包、上新等等，带来了远比秒杀更复杂的业务场景和体量。大促的模式也更加丰富，不同场景下的大促涉及的应用是不同的，每一类应用在应对独特的洪峰时都需要有足够的资源。\n假如运营同学在不同时间点设计了两种活动，两种活动分别会对应两类不同的应用，如果这两类应用都在大促前准备充足的资源自然是轻松渡过大促峰值，但大促洪峰时间短暂，大量的资源投入有很长一段时间都处于空闲状态，这自然不符合技术人的追求。\n那么如何在不增加资源的场景下渡过各种大促呢？\n核心问题就是如何在足够短的时间内做到大规模资源腾挪，让一批机器资源可以在不同时间点承载起不同的大促洪峰。\n面对这样的挑战，我们会有怎样的解法呢？\nService Mesh 618 大促落地试点时，我们有介绍到为什么要做这个事情，核心价值是业务与基础设施解耦，双方可以并行发展，快速往前走。那么并行发展究竟能为业务带来哪些实际的价值？除了降低基础组件的升级难度之外，我们还在资源调度方向做了以下探索：\n1.1 腾挪调度 说到资源调度，最简单的自然是直接做资源腾挪，比如大促A峰值过后，大促A对应的应用通过缩容把资源释放出来，大促B对应的应用再去申请资源做扩容，这种方式非常简单，难点在于当资源规模非常庞大时，缩容扩容的效率极低，应用需要把资源申请出来并启动应用，耗时很长，假如多个大促 …","date":1574154000,"description":" 当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？我们借助四个“双十一考题”一一为大家揭晓。","dir":"blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"269c9444948a5f83a5a17f907b72ce4a","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","publishdate":"2019-11-19T17:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","summary":"2019 年的双十一是蚂蚁金服的重要时刻，大规模落地了 Service Mesh 并顺利保障双十一平稳渡过。我们第一时间与这次的落地负责人进行了交流。 采访的开头： 花肉：“这","tags":["Service mesh","Service Mesh 落地实践"],"title":"Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/","wordcount":6239},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@瀚墨 提问：\n 请问 SOFARPC 本地多人开发有没有最佳实践分享一下了？\n A：你说的多人开发具体是指啥协作场景？\n 开发人员开发本地的服务时，需要依赖的服务可以来自一个开发环境！这样的开发人员就不需要启动自己本地所有的服务了。我们已经有一个开发环境，会部署所有的服务，但是当开发人员开发某一个功能时，可能只希望其中几个接口走本地，其他的接口走开发环境！\n A：你的这个开发环境是一组不确定的机器，还是一台指定 IP 的机器？\nSOFARPC：https://github.com/sofastack/sofa-rpc\n 指定的 IP 地址。\n A：一种方法本地调用方直接配开发环境的机器直连调用， 另外一个方法就是开发环境统一使用一个 uniqueId，和本地用不同的uniqueId。\n2、@温明磊 提问：\n Seata Saga 向前重试状态机 json 该怎么配置，节点代码内部和节点 json 的 catch 都不捕获异常吗，这样就会一直调用该节点。\n A：运行过程中向前重试：通过 Catch 到异常然后 Next 到当前节点（这种实现了 Retry 配置之后就不需要了），事后向前重试：直接调 forward 方法即可（一般不需要自己调，server 端会自动触发）。\n Retry 配置什么时候实现，事后向前重试是一定会发生的吗？\n A：Retry 配置正在做了。事后向前重试目前 server 端的逻辑是这样的：失败时，如果没有触发回滚，那么 server 端会不断发起重试，如果触发过回滚（也就是回滚失败了）server 端会不断触发 compensate。\n 这个没用触发回滚，是不是像我上面说的这个出错节点，代码内部没用捕获异常，json 也没有 catch 异常，然后就不断重试了。\n A：是的。\n3、@金雷-上海 提问：\n 看代码，Saga 二阶段提交成功不删分支事务？回滚也是不删，有特殊原因？\n A：你是 server 端的分支事务吗？客户端的状态机日志不会删，server 端没有显示删除分支事务，只是提交或回滚全局事务。\n 嗯，我看了代码是这样，不清楚为什么这么操作。 全局事务表删了，分支事务不删。\n A：是这样的，Saga 模式的回滚是在客户端状态机协调的，不是用 TC 协调的，TC 只是触发，客户端回滚或成功后会调 server 端上报回滚成功。所以我理解是 server 端这时会删除全局事务记录，而没有删除分支事务记录。因为是客户端协调，所以 TC 也没有循环去调每一个分支事务的 rollback，所以分支事务实际上是留下了，没有被删除。\n 既然全局事务都删除了，如果留着没有什么意义，我觉得可以删除分支事务。\n A：是的。提个 issue，修改一下。\n你提的那个 issue 修复了 ，https://github.com/seata/seata/pull/1893 同时做了一个优化，重试和补偿服务不向 Seata server 注册分支事务，仅原始服务注册分支事务，重试和补偿服务执行完成时向原始服务注册的分支事务上报成功与否的状态。\nRetry 功能，\u0026amp;rdquo;BackoffRate\u0026amp;rdquo;: 1.5，表示重试间隔增量，1.5表示本次重试间隔是上次的1.5倍：https://github.com/seata/seata/issues/1899\n还有一个点，当重试过程中生了别的异常，框架会重新匹配这个异常对应的重试规则，并按新规则来重试，但同一种规则的总次数的不会超过它配置的 MaxAttempts，避免不同异常来回切换而一直重试。\n 新规则就是下面这个配置吗？\n A： 就是你可以配置多个重试规则，根据 Exceptions 属性来匹配，下面那个没有带 Exceptions 表示框架自动匹配网络超时异常。\n 配置了 Exceptions，不只是可以匹配节点的异常，还可以匹配重试的异常，执行新的重试规则。\n A：对的。\n4、@J～杰 提问：\n 我看整个 Saga 流程引擎都是自己开发的，那个 json 的参数属性含义哪里可以参考？\n A：这是官网文档，每个属性的含义，可以看 State language referance 节。 http://seata.io/zh-cn/docs/user/saga.html\n 如果用了 @GlobalTransactional，在并发场景中，是不是还要用 @GlobalLock 保证数据的隔离性？\n A：@GlobalLock 是用于非分布式事务场景下的读分布式事务中数据。在分布式事务的场景本身有全局锁来隔离。\nSeata：https://github.com/seata/seata\n双十一落地实践特辑阅读 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 万字长文丨1分36秒，100亿，支付宝技术双11答卷：没有不可能 SOFA 项目进展 本周发布详情如下：\n发布 SOFATracer v2.4.2\u0026amp;frasl;3.0.8，主要变更如下：\n 迁移 samples 到 sofastack-guides空间下 修复 Server Receive 阶段出现 spanId 增长问题 优化 Zipkin 远程上报问题 详细发布报告： https://github.com/sofastack/sofa-tracer/releases/tag/v2.4.2 https://github.com/sofastack/sofa-tracer/releases/tag/v3.0.8\n云原生活动推荐  本期为 Service Mesh Meetup#8 特别场，联合 CNCF、阿里巴巴及蚂蚁金服共同举办。\n不是任何一朵云都撑得住双 11。\n成交 2684 亿，阿里巴巴核心系统 100% 上云。\n蚂蚁金服的核心交易链路大规模上线 Service Mesh。\n这次，让双 11 狂欢继续，让云原生经得起双 11 大考，也让云原生走到开发者身边。\n你将收获 3 大经验加持：\n 双 11 洗礼下的阿里巴巴 K8s 超大规模实践经验 蚂蚁金服首次 Service Mesh 大规模落地经验 阿里巴巴超大规模神龙裸金属 K8s …","date":1573801200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191115/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c08a41ec62ae153bbc0ce35958093192","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191115/","publishdate":"2019-11-15T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191115/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/11 - 11/15】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191115/","wordcount":2326},{"author":"烈元","categories":"Service mesh","content":" 揭秘 2019 Service Mesh 双十一大考 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已经渡过探索期，今年已经全面进入深水区探索。\n2019 年的双十一是我们的重要时刻，我们进行了大规模的落地。作为技术人能面对世界级的流量挑战，是非常紧张和兴奋的。当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？让我们一起来揭秘蚂蚁金服 Service Mesh 双十一实战。\nService Mesh 基础概念 Istio 清晰的描述了 Service Mesh 最核心的两个概念：数据面与控制面。数据面负责做网络代理，在服务请求的链路上做一层拦截与转发，可以在链路中做服务路由、链路加密、服务鉴权等，控制面负责做服务发现、服务路由管理、请求度量（放在控制面颇受争议）等。\nService Mesh 带来的好处不再赘述，我们来看下蚂蚁金服的数据面和控制面产品：\n 数据面：SOFAMosn。蚂蚁金服使用 Golang 研发的高性能网络代理，作为 Service Mesh 的数据面，承载了蚂蚁金服双十一海量的核心应用流量。\n 控制面：SOFAMesh。Istio 改造版，落地过程中精简为 Pilot 和 Citadel，Mixer 直接集成在数据面中避免多一跳的开销。\n 双十一落地情况概览 今年，蚂蚁金服的核心应用全面接入 SOFAMosn，生产 Mesh 化容器几十万台，双十一峰值 SOFAMosn 承载数据规模数千万 QPS，SOFAMosn 转发平均处理耗时 0.2ms。\n在如此大规模的接入场景下，我们面对的是极端复杂的场景，同时需要多方全力合作，更要保障数据面的性能稳定性满足大促诉求，整个过程极具挑战。\n同时，Service Mesh 的落地也是一个跨团队合作的典范案例，集合了核心、RPC、消息、无线网关、控制面、安全、运维、测试等团队的精诚合作，接下来我们会按照以上几个模块来解析 Service Mesh 的双十一落地情况，更多解析关注本网站。\n本文为《蚂蚁金服 Service Mesh 落地实践系列》第一篇 - 核心篇，作者：田阳（花名：烈元），蚂蚁金服技术专家，专注于高性能网络服务器研发，Tengine 开源项目核心成员，蚂蚁金服开源 SOFAMosn 项目核心成员。\n基础能力建设 SOFAMosn 的能力大图 SOFAMosn 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 XDS 等云原生能力。\n业务支持 SOFAMosn 作为底层的高性能安全网络代理，支撑了 RPC，MSG，GATEWAY 等业务场景。\nIO 模型 SOFAMosn 支持两种 IO 模型，一个是 Golang 经典模型，goroutine-per-connection；一个是 RawEpoll 模型，也就是 Reactor 模式，I/O 多路复用(I/O multiplexing) + 非阻塞 I/O(non-blocking I/O)的模式。\n在蚂蚁金服内部的落地场景，连接数不是瓶颈，都在几千或者上万的量级，我们选择了 Golang 经典模型。而对于接入层和网关有大量长链接的场景，更加适合于 RawEpoll 模型。\n协程模型 一条 TCP 连接对应一个 Read 协程，执行收包，协议解析； 一个请求对应一个 worker 协程，执行业务处理，proxy 和 Write 逻辑； 常规模型一个 TCP 连接将有 Read/Write 两个协程，我们取消了单独的 Write 协程，让 workerpool 工作协程代替，减少了调度延迟和内存占用。\n能力扩展 协议扩展\nSOFAMosn 通过使用同一的编解码引擎以及编/解码器核心接口，提供协议的 plugin 机制，包括支持：\n SOFARPC； HTTP1.x/HTTP2.0； Dubbo； NetworkFilter 扩展\nSOFAMosn 通过提供 network filter 注册机制以及统一的 packet read/write filter 接口，实现了 Network filter 扩展机制，当前支持：\n TCP proxy； Fault injection； StreamFilter 扩展\nSOFAMosn 通过提供 stream filter 注册机制以及统一的 stream send/receive filter 接口，实现了 Stream filter 扩展机制，包括支持：\n 流量镜像； RBAC鉴权； TLS 安全链路 作为金融科技公司，资金安全是最重要的一环，链路加密又是其中最基础的能力，在 TLS 安全链路上我们进行了大量的调研测试。\n通过测试，原生的 Go 的 TLS 经过了大量的汇编优化，在性能上是 Nginx(OpenSSL）的80%，Boring 版本的 Go(使用 cgo 调用 BoringSSL) 因为 cgo 的性能问题， 并不占优势，所以我们最后选型原生 Go 的 TLS，相信 Go Runtime 团队后续会有更多的优化，我们也会有一些优化计划。\n go 在 RSA 上没有太多优化，go-boring（CGO）的能力是 go 的1倍； p256 在 go 上有汇编优化，ECDSA 优于go-boring； 在 AES-GCM 对称加密上，go 的能力是 go-boring 的20倍； 在 SHA、MD 等 HASH 算法也有对应的汇编优化； 为了满足金融场景的安全合规，我们同时也对国产密码进行了开发支持，这个是 Go Runtime 所没有的。虽然目前的性能相比国际标准 AES-GCM 还是有一些差距，大概是 50%，但是我们已经有了后续的一些优化计划，敬请期待。\n平滑升级能力 为了让 SOFAMosn 的发布对应用无感知，我们调研开发了平滑升级方案，类似 Nginx 的二进制热升级能力，但是有个最大的区别就是 SOFAMosn 老进程的连接不会断，而是迁移给新的进程，包括底层的 socket FD 和上层的应用数据，保证整个二进制发布过程中业务不受损，对业务无感知。除了支持 SOFARPC、Dubbo、消息等协议，我们还支持 TLS 加密链路的迁移。\n容器升级\n基于容器平滑升级 SOFAMosn 给了我们很多挑战，我们会先注入一个新的 SOFAMosn，然后他会通过共享卷的 UnixSocket 去检查是否存在老的 SOFAMosn，如果存在就和老的 SOFAMosn 进行连接迁移，然后老的 SOFAMosn 退出。这一块的细节较多，涉及 SOFAMosn 自身和 Operator 的交互。\nSOFAMosn 的连接迁移\n连接迁移的核心主要是内核 Socket 的迁移和应用数据的迁移，连接不断，对用户无感知。\nSOFAMosn 的 metric 迁移\n我们使用了共享内存来共享新老进程的 metric 数据，保证在迁移的过程中 metric 数据也是 …","date":1573779600,"description":" 当 Service Mesh 遇到双十一又会迸发出怎样的火花？蚂蚁金服的 LDC 架构继续演进的过程中，Service Mesh 要承载起哪方面的责任？让我们一起来揭秘蚂蚁金服 Service Mesh 双十一实战。","dir":"blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f758a3d4476cd3e8516947fa6fff5747","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","publishdate":"2019-11-15T09:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","summary":"揭秘 2019 Service Mesh 双十一大考 蚂蚁金服很早开始关注 Service Mesh，并在 2018 年发起 ServiceMesher 社区，目前已有 4000+ 开发者在社区活跃。在技术应用层面，Service Mesh 的场景已","tags":["Service mesh","Service Mesh 落地实践"],"title":"蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇","type":"blog","url":"/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/","wordcount":3391},{"author":"潘潘","categories":"Service Mesh","content":" 概要 活动主题：Kubernetes \u0026amp;amp; Cloud Native X Service Mesh Meetup 活动时间：2019 年 11 月 24 日（星期日）9:30-16:30 活动地点：北京朝阳大望京科技商务园区宏泰东街浦项中心B座2层多功能厅 活动形式：线下活动 活动报名：请戳这里 活动介绍 Service Mesh Meetup#8 特别场 本期为 Service Mesh Meetup#8 特别场，联合 CNCF、阿里巴巴及蚂蚁金服 共同举办。\n不是任何一朵云都撑得住双 11。\n成交 2684 亿，阿里巴巴核心系统 100% 上云。\n蚂蚁金服的核心交易链路大规模上线 Service Mesh。\n这次，让双 11 狂欢继续，让云原生经得起双 11 大考，也让云原生走到开发者身边。\n你将收获 3 大经验加持：\n 双 11 洗礼下的阿里巴巴 K8s 超大规模实践经验； 蚂蚁金服首次 Service Mesh 大规模落地经验； 阿里巴巴超大规模神龙裸金属 K8s 集群运维实践经验； 错过一次，再等一年哦。\n议程 时间 环节（分享主题） 分享嘉宾 9:00-9:30 签到 9:30-10:10 《释放云原生价值，双 11 洗礼下的阿里巴巴 K8s 超大规模实践》 曾凡松（逐灵），阿里巴巴高级技术专家；汪萌海（木苏），阿里巴巴技术专家 10:10-10:50 《蚂蚁金服双十一Service Mesh超大规模落地揭秘》 黄挺（鲁直），蚂蚁金服云原生负责人；雷志远（碧远），蚂蚁金服技术专家 10:50-11:30 《阿里巴巴超大规模神龙裸金属 K8s 集群运维实践》 周涛 （广侯），阿里巴巴高级技术专家 11:30-12:10  《深入Kubernetes的“无人区” — 蚂蚁金服双十一的调度系统》 曹寅，蚂蚁金服 Kubernetes 落地负责人 12:10-13:30 午休 13:30-14:10  《服务网格在“路口”的产品思考与实践》 宋顺（齐天），蚂蚁金服高级技术专家，开源配置中心Apollo作者 14:10-14:50 《阿里集团核心应用落地 Service Mesh 的挑战与机遇》 李云（至简），阿里巴巴高级技术专家 14:50-13:10 茶歇 15:10-15:50 《蚂蚁金服云原生 PaaS 实践之路》 王成昌（晙曦），蚂蚁金服技术专家 15:50-16:30 《函数计算在双十一小程序场景的应用》 吴天龙（木吴），阿里云函数计算技术专家 加入 SOFA 钉钉互动群 群号：23390449，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n","date":1573639200,"description":"11月24日，Service Mesh Meetup#8 双十一特别场邀您参加，本期联合 CNCF、阿里巴巴及蚂蚁金服共同举办。","dir":"activities/service-mesh-meetup-8/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f127ede30ff37760f648b79ecf887ffa","permalink":"https://sofastack.github.io/sofastack.tech/activities/service-mesh-meetup-8/","publishdate":"2019-11-13T18:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/service-mesh-meetup-8/","summary":"概要 活动主题：Kubernetes \u0026amp; Cloud Native X Service Mesh Meetup 活动时间：2019 年 11 月 24 日（星期日）9:30-16:30 活动地点：北京朝阳大望京科技商务园","tags":["Meetup","Service Mesh","Kubernetes"],"title":"Kubernetes \u0026 Cloud Native X Service Mesh Meetup","type":"activities","url":"/sofastack.tech/activities/service-mesh-meetup-8/","wordcount":758},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@温明磊 提问： \u0026amp;gt; 出参入参都放在 Saga 的上下文中，如果参数内容较多较大，业务量又大的话，对内存有限制吗?\nA: 没有做限制，建议无关的参数不要放到上下文。下一个服务需要用的参数、或用于分支判断的参数可以放入上下文。\n 确认个事情：每个节点，要么自己方法内部 Catch 异常处理，使最终有返回信息。要么自己内部可以不处理，交由状态机引擎捕获异常，在 json 中定义 Catch 属性。 而不是补偿节点能够自动触发补偿，需要补偿必须手动在 json，由 Catch 或者 Choices 属性路由到 CompensationTrigger。\n A：对的，这个是为了提高灵活性。用户可以自己控制是否进行回滚，因为并不是所有异常都要回滚，可能有一些自定义处理手段。\n 所以 Catch 和 Choices 可以随便路由到想要的 state 对吧？\n A：是的。这种自定义出发补偿的设计是参考了 bpmn2.0 的。\n 还有关于 json 文件，我打算一条流程，就定义一个 json，虽然有的流程很像，用 Choices，可以解决。但是感觉 json 还是要尽量简单。这样考虑对吗？\n A：你可以考虑用子状态机来复用，子状态机会多生成一行 stateMachineInstance 记录，但对性能影响应该不大。\nService Mesh 相关阅读 从网络接入层到 Service Mesh，蚂蚁金服网络代理的演进之路\n 诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录\n Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录\n 蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录\n Service Mesh 发展趋势：云原生中流砥柱\n 企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录\n 蚂蚁金服Service Mesh新型网络代理的思考与实践 | GIAC 分享实录\n 蚂蚁金服 Service Mesh 渐进式迁移方案|Service Mesh Meetup 实录\n 蚂蚁金服 Service Mesh 实践探索 | Qcon 实录\n 干货 | 蚂蚁金服是如何实现经典服务化架构往 Service Mesh 方向的演进的？\n 活动推荐 2019年度TOP100全球软件案例研究峰会即将举行，蚂蚁金服也受邀参与本次案例分享。\nService Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，我们如何做到在奔跑的火车上换轮子，将现有的 SOA 体系快速演进至 Service Mesh 架构。RPC、消息、DB、安全、运维等每一个环节均充满挑战。本次实战分享蚂蚁金服双十一核心应用如何大规模落地 Service Mesh 架构并降低大促成本。\n主题：《蚂蚁金服 Service Mesh 双十一实战》\n嘉宾：石建伟，花名：卓与，蚂蚁金服中间件技术专家，主要负责蚂蚁金服服务注册中心、配置中心与 Service Mesh 的研发与架构。当前专注在蚂蚁金服 Service Mesh 内部落地。\n时间：2019年11月15日（周五）16:50-17:50\n地点：北京国际会议中心\n报名方式：点击“这里”即可锁定席位\n","date":1573196400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191108/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4615f39bbae97f3f8b4b1705fcbc5d2f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191108/","publishdate":"2019-11-08T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191108/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【11/04 - 11/08】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191108/","wordcount":1255},{"author":"涵畅","categories":"Service mesh","content":" 本文作者：肖涵（涵畅）\n上篇文章《诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录》中，介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，帮助大家了解 Service Mesh 未来发展方向和前景。蚂蚁金服持续在进行 Service Mesh 布道和交流。本文内容整理自 10 月 26 日 Service Mesh Meetup#7 成都站主题演讲，现场视频以及分享 PPT 获取方式见文章底部。\n从网络硬件设备到自研平台，从传统服务治理到 Service Mesh，本文将介绍蚂蚁金服网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑起秒级百万支付，千万春晚咻一咻的。\n前言 在云计算和 SDN 下，我们经常听到流量的东西南北向概念，简单来说从外部 Internet 等到数据中心内部的流量走向被称为南北流量，数据中心内部的 VM 之间的流量被称为东西流量。\n当我们追踪南北向的网络流，请求通常会经过四层负载均衡，七层负载均衡等，这通常被我们称为网络接入层代理。当数据中心内部主动访问公网时候，流量通常也会经过 NAT 网关等做网络地址的转换，这也被我们称为网络代理。当我们把视角转向数据中心内部，网络代理的存在感似乎不是那么强，随着 SOA 的发展我们形成了各种成熟的服务通信框架，例如蚂蚁金服的 SOFAStack，阿里集团的 HSF，Google 的 gRPC 等等，网络代理功能被集成进了各种通信框架中，似乎已经 Proxyless 化了，但是随着微服务以及 Service Mesh 的架构提出，东西向的网络代理以独立的姿态又出现了。\n本文将围绕蚂蚁金服近十年网络代理的变迁，揭示整个蚂蚁金服接入层网络以及 Service Mesh 的演进过程，同时带来我们的思考。\n旧瓶新装 我们先来看看业界情况，传统四层负载均衡的代表产品当然是 IPVS，百度阿里等公司早年均对 IPVS 做了非常深度的定制功能，支撑了早期业务的飞速发展。接着也有 DPDK(阿里云 SLB)，类 DPDK 技术的代表 Google 的 Maglev 以及 eBPF 技术的代表 Facebook 的 Katran 出现。\n七层网络代理各个大厂均有产品代表，Google 的 GFE、百度 的 BFE、腾讯 的 TGW，阿里经济体内部也因为场景等原因有众多，例如手淘的 Aserver，集团 web 统一接入 Tengine，当然还有蚂蚁金服的 Spanner（后面会详细介绍）。同时随着 Service Mesh 概念的提出和技术的逐渐成熟，Mesh 中 Sidecar 角色的网络代理也像雨后春笋一样多了起来，包括蚂蚁金服的 SOFAMosn，Istio 社区方案的 Envoy 以及 Rust 编写的 Linkerd，当然 Service Mesh 场景的网络代理和网络接入层的代理我认为没有本质的差别，随着云原生的深入化，大家终将会形成合力并保持一致的形态。\n上图是2019年 Gartner Networking 方向的曲线，可以看到在上升和爆发区有着非常多的网络代理的影子（Secure Access Service Edge，Service Mesh，Edge Networking，Firewall as a Service etc.），虽然网络代理是一项古老的技术以及产品形态，但是仍然随着基础设施以及业务的变化以新的能力和角色展现在世人眼前。\n网络代理的十年 网络代理技术一直围绕“高效接入，访问加速，稳定高可用，安全合规”四个关键词，不断升级核心能力，架构以及运维能力，底层基础网络物理带宽从1G到10G、25G、100G；阿里骨干广域网络走出杭州扩展到全国、全球规模，不断地通过前瞻技术架构研发，技术自主能力的提升和转变，助力业务发展。\n蚂蚁金服应用网络架构概览 产品理念 我们应该以什么样的业务设计来满足上层业务以及市场的需要？产品理念决定了产品的走向，我们设定了网络产品的核心理念模型：\n网络产品设计理念\n接入层代理十年变迁 接入层网络代理的十年变迁之路，我们可以总结为三个时代，四个阶段：PC 时代、移动时代和万物互联云原生时代，伴随着这三个时代，我们经历了四个关键路径。\n前世 2010年前蚂蚁金服网络代理是商用设备的时代，包括 F5 的 bigip，Netscaler 等产品，对于商业设备白盒化，大家比较熟知的是去 IOE，其实网络设备走在了更前面。使用商用设备主要有几个问题，厂商的 Lockin，成本以及灵活扩展等问题，所以从2010年蚂蚁金服开始向自主研发演进。\n自主研发 我们同时开启了四七层网络接入的自研之路，四七层网络由于场景的不同，在整个演进路线上也有较大的差异。\n四层负载均衡 四层网络由于不理解业务语义，主要进化路线是伴随着系统技术，硬件技术的变化，围绕提高吞吐，降低延迟的目标而演进。2014年全面使用 DPDK 进行技术重构，将传统基于内核技术的 IPVS 新建，转发指标分别从万级，十万级提高到百万和千万级的每秒包转发。\n同时随着 Ebpf，Xdp 技术的出现，基于内核的高速转发平面产品又横空出世（包括 Facebook 开源的 Katran）打破了 DPDK 技术的垄断，同时可编程交换芯片以及 P4 语言也加入了这一站场，这里不具体讨论每种技术的优劣。\nSpanner Spanner 是蚂蚁金服的统一接入网关，其意为扳手，主要是为蚂蚁金服 SSL 卸载和网络接入提供了白盒化解决方案，承载了蚂蚁金服所有的业务流量，包括支付宝 App，Web，商户等的终端访问。\n金融级三地五中心架构的流量调度\n上图展示了 Spanner 的编年史，在2013年蚂蚁金服上架了自己的逻辑数据中心架构 LDC，同时随着演进支持了目前的蚂蚁金服金融级的三地五中心容灾架构：\n为了支持这套架构，蚂蚁金服的所有基础设施都进行了改造和技术升级，流量调拨能力作为最基础的能力，是一个基本盘，Spanner 通过对请求头的识别以及全站转发规则映射来实现流量调度，支撑并不限于以下场景：\n 机房内随机路由； 蓝绿发布； 容灾： 逻辑机房内容灾； 机房级别； 城市级别； 弹性调度； 压测流量调度； 灰度流量调度； SSL/TLS 实践\n蚂蚁金服作为全集团最早实践 https 全站的 BU，一直围绕着安全，合规，性能的主题进行全站加密体系的建设。\n成本之战\n前面提到2012年 Spanner 全面上线后，我们接入层具备了定制业务逻辑的能力，在2013年很好支撑了 LDC 的上线，同时我们在性能成本方面也有机会去进行持续的提升，同年我们引入 SSL 加速卡软硬件一体解决方案，从现在来看该套方案已经非常成熟了，集团 Tengine，Openssl 都提供了非常方便的接入框架，但是当年这一块还一直处于探索阶段。我们在 Spanner 里做了 Nginx 的 SSL 握手异步化改造，改造了 Openssl 同 Cavium 的 SSL 加速卡进行适配，整套方案在当时的机型上较 CPU 提升了基于 RSA2048 算法的 SSL 握手3倍的性能，同时也对后续各大厂商在这方面的实践产生了指导性意 …","date":1573030800,"description":" 从网络硬件设备到自研平台，从传统服务治理到 Service Mesh，本文将介绍蚂蚁金服网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑起秒级百万支付，千万春晚咻一咻的。","dir":"blog/antfin-service-mesh-network-agents/","fuzzywordcount":7600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b539a4c29754f9e761c2027426566250","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-service-mesh-network-agents/","publishdate":"2019-11-06T17:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/antfin-service-mesh-network-agents/","summary":"本文作者：肖涵（涵畅） 上篇文章《诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录》中，介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，帮助大家了","tags":["Service mesh"],"title":"从网络接入层到 Service Mesh，蚂蚁金服网络代理的演进之路","type":"blog","url":"/sofastack.tech/blog/antfin-service-mesh-network-agents/","wordcount":7507},{"author":"敖小剑","categories":"Service mesh","content":" 2019 年，蚂蚁金服在 Service Mesh 领域继续高歌猛进，进入大规模落地的深水区。本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的演讲，他介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，以及大规模落地时遇到的困难和解决方案，助你了解 Service Mesh 的未来发展方向和前景。\n 前言 大家好，我是敖小剑，来自蚂蚁金服中间件团队，今天带来的主题是“诗和远方：蚂蚁金服 Service Mesh 深度实践”。\n在过去两年，我先后在 QCon 做过两次 Service Mesh 的演讲：\n 2017年，当时 Service Mesh 在国内还属于蛮荒时代，我当时做了一个名为“Service Mesh: 下一代微服务”的演讲，开始在国内布道 Service Mesh 技术； 2018年，做了名为“长路漫漫踏歌而行：蚂蚁金服 Service Mesh 实践探索”的演讲，介绍蚂蚁金服在 Service Mesh 领域的探索性的实践，当时蚂蚁金服刚开始在 Service Mesh 探索。 今天，有幸第三次来到 QCon，给大家带来的依然是蚂蚁金服在 Service Mesh 领域的实践分享。和去年不同的是，今年蚂蚁金服进入了 Service Mesh 落地的深水区，规模巨大，而且即将迎来双十一大促考验。\n 备注：现场做了一个调研，了解听众对 Servicve Mesh 的了解程度，结果不太理想：在此之前对 Service Mesh 有了解的同学目测只有10%多点（肯定不到20%）。Service Mesh 的技术布道，依然任重道远。\n 今天给大家带来的内容主要有三块：\n 蚂蚁金服落地情况介绍：包括大家最关心的双十一落地情况； 大规模落地的困难和挑战：分享一下我们过去一年中在大规模落地上遇到的问题； 是否采用 Service Mesh 的建议：这个问题经常被人问起，所以借这个机会给出一些中肯的建议供大家参考； 蚂蚁金服落地情况介绍 发展历程和落地规模 Service Mesh 技术在蚂蚁金服的落地，先后经历过如下几个阶段：\n 技术预研 阶段：2017年底开始调研并探索 Service Mesh 技术，并确定为未来发展方向； 技术探索 阶段：2018年初开始用 Golang 开发 Sidecar SOFAMosn，年中开源基于 Istio 的 SOFAMesh； 小规模落地 阶段：2018年开始内部落地，第一批场景是替代 Java 语言之外的其他语言的客户端 SDK，之后开始内部小范围试点； 规模落地 阶段：2019年上半年，作为蚂蚁金融级云原生架构升级的主要内容之一，逐渐铺开到蚂蚁金服内部的业务应用，并平稳支撑了618大促； 全面大规模落地 阶段：2019年下半年，在蚂蚁金服内部的业务中全面铺开，落地规模非常庞大，而且准备迎接双十一大促； 目前 ServiceMesh 正在蚂蚁金服内部大面积铺开，我这里给出的数据是前段时间（大概9月中）在云栖大会上公布的数据：应用数百个，容器数量（pod 数）超过10万。当然目前落地的pod数量已经远超过10万，这已经是目前全球最大的 Service Mesh 集群，但这仅仅是一个开始，这个集群的规模后续会继续扩大，明年蚂蚁金服会有更多的应用迁移到 Service Mesh。\n主要落地场景 目前 Service Mesh 在蚂蚁金服内部大量落地，包括支付宝的部分核心链路，落地的主要场景有：\n 多语言支持：目前除了支持 Java 之外，还支持 Golang，Python，C++，NodeJS 等语言的相互通信和服务治理； 应用无感知的升级：关于这一点我们后面会有特别的说明； 流量控制：经典的 Istio 精准细粒度流量控制； RPC 协议支持：和 Istio 不同，我们内部使用的主要是 RPC 协议； 可观测性； Service Mesh 的实际性能数据 之前和一些朋友、客户交流过，目前在 Service Mesh 方面大家最关心的是 Service Mesh 的性能表现，包括对于这次蚂蚁金服 Service Mesh 上双十一，大家最想看到的也是性能指标。\n为什么大家对性能这么关注？\n因为在 Service Mesh 工作原理的各种介绍中，都会提到 Service Mesh 是将原来的一次远程调用，改为走 Sidecar（而且像 Istio 是客户端和服务器端两次 Sidecar，如上图所示），这样一次远程调用就会变成三次远程调用，对性能的担忧也就自然而然的产生了：一次远程调用变三次远程调用，性能会下降多少？延迟会增加多少？\n下图是我们内部的大促压测数据，对比带 SOFAMosn 和不带 SOFAMosn 的情况（实现相同的功能）。其中 SOFAMosn 是我们蚂蚁金服自行开发的基于 Golang 的 Sidecar/数据平面，我们用它替代了 Envoy，在去年的演讲中我有做过详细的介绍。\nSOFAMosn：https://github.com/sofastack/sofa-mosn\n CPU：CPU 使用在峰值情况下增加8%，均值约增加2%。在最新的一次压测中，CPU 已经优化到基本持平（低于1%）； 内存：带 SOFAMosn 的节点比不带 SOFAMosn 的节点内存占用平均多 15M； 延迟：延迟增加平均约0.2ms。部分场景带 SOFAMosn 比不带 SOFAMosn RT 增加约5%，但是有部分特殊场景带 SOFAMosn 比不带 SOFAMosn RT 反而降低7.5%； 这个性能表现，和前面\u0026amp;rdquo;一次远程调用变三次远程调用\u0026amp;rdquo;的背景和担忧相比有很大的反差。尤其是上面延迟的这个特殊场景，居然出现带 SOFAMosn（三次远程调用）比不带 SOFAMosn（一次远程调用） 延迟反而降低的情况。\n是不是感觉不科学？\nService Mesh 的基本思路 我们来快速回顾一下 Service Mesh 实现的基本思路：\n在基于 SDK 的方案中，应用既有业务逻辑，也有各种非业务功能。虽然通过 SDK 实现了代码重用，但是在部署时，这些功能还是混合在一个进程内的。\n在 Service Mesh 中，我们将 SDK 客户端的功能从应用中剥离出来，拆解为独立进程，以 Sidecar 的模式部署，让业务进程专注于业务逻辑：\n 业务进程：专注业务实现，无需感知 Mesh； Sidecar 进程：专注服务间通讯和相关能力，与业务逻辑无关； 我们称之为\u0026amp;rdquo;关注点分离\u0026amp;ldquo;：业务开发团队可以专注于业务逻辑，而底层的中间件团队（或者基础设施团队）可以专注于业务逻辑之外的各种通用功能。\n通过 Sidecar 拆分为两个独立进程之后，业务应用和 Sidecar 就可以实现“独立维护”：我们可以单独更新/升级业务应用或者 Sidecar。\n性能数据背后的情景分析 我们回到前面的蚂蚁金服 Service Mesh 落地后的性能对比数据：从原理上说，Sidecar 拆分之后，原来 SDK 中的各种功能只是拆分到 Sidecar 中。整体上并没有增减，因 …","date":1572922800,"description":" 本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的演讲。","dir":"blog/service-mesh-antfin-deep-practice-qcon/","fuzzywordcount":12500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"561edcf88763b36e72894da214d2b123","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","publishdate":"2019-11-05T11:00:00+08:00","readingtime":25,"relpermalink":"/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","summary":"2019 年，蚂蚁金服在 Service Mesh 领域继续高歌猛进，进入大规模落地的深水区。本文整理自蚂蚁金服高级技术专家敖小剑在 QCon 全球软件开发大会（上海站）2019 上的","tags":["Service mesh"],"title":"诗和远方：蚂蚁金服 Service Mesh 深度实践 | QCon 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/","wordcount":12438},{"author":"屹远","categories":"Seata","content":" Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的 Saga 模式。 项目地址：https://github.com/seata/seata\n本文作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。\n金融分布式应用开发的痛点 分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。\u0026amp;mdash;《左耳听风-弹力设计之“补偿事务”》\n而在金融领域微服务架构下的业务流程往往会更复杂，流程很长，比如一个互联网微贷业务流程调十几个服务很正常，再加上异常处理的流程那就更复杂了，做过金融业务开发的同学会很有体感。\n所以在金融分布式应用开发过程中我们面临一些痛点：\n 业务一致性难以保障 我们接触到的大多数业务（比如在渠道层、产品层、集成层的系统），为了保障业务最终一致性，往往会采用“补偿”的方式来做，如果没有一个协调器来支持，开发难度是比较大的，每一步都要在 catch 里去处理前面所有的“回滚”操作，这将会形成“箭头形”的代码，可读性及维护性差。或者重试异常的操作，如果重试不成功可能要转异步重试，甚至最后转人工处理。这些都给开发人员带来极大的负担，开发效率低，且容易出错。\n 业务状态难以管理 业务实体很多、实体的状态也很多，往往做完一个业务活动后就将实体的状态更新到了数据库里，没有一个状态机来管理整个状态的变迁过程，不直观，容易出错，造成业务进入一个不正确的状态。\n 幂等性难以保障 服务的幂等性是分布式环境下的基本要求，为了保证服务的幂等性往往需要服务开发者逐个去设计，有用数据库唯一键实现的，有用分布式缓存实现的，没有一个统一的方案，开发人员负担大，也容易遗漏，从而造成资损。\n 业务监控运维难，缺乏统一的差错守护能力 业务的执行情况监控一般通过打印日志，再基于日志监控平台查看，大多数情况是没有问题的，但是如果业务出错，这些监控缺乏当时的业务上下文，对排查问题不友好，往往需要再去数据库里查。同时日志的打印也依赖于开发，容易遗漏。对于补偿事务往往需要有“差错守护触发补偿”、“工人触发补偿”操作，没有统一的差错守护和处理规范，这些都要开发者逐个开发，负担沉重。\n理论基础 一些场景下，我们对数据有强一致性的需求时，会采用在业务层上需要使用“两阶段提交”这样的分布式事务方案。而在另外一些场景下，我们并不需要这么强的一致性，那就只需要保证最终一致性就可以了。\n例如蚂蚁金服目前在金融核心系统使用的就是 TCC 模式，金融核心系统的特点是一致性要求高（业务上的隔离性）、短流程、并发高。\n而在很多金融核心以上的业务（比如在渠道层、产品层、集成层的系统），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务（如金融网络）。这是如果每个服务都开发 Try、Confirm、Cancel 三个方法成本高。如果事务中有其它公司的服务，也无法要求其它公司的服务也遵循 TCC 这种开发模式。同时流程长，事务边界太长会影响性能。\n对于事务我们都知道 ACID，也很熟悉 CAP 理论最多只能满足其中两个，所以，为了提高性能，出现了 ACID 的一个变种 BASE。ACID 强调的是一致性（CAP 中的 C），而 BASE 强调的是可用性（CAP 中的 A）。我们知道，在很多情况下，我们是无法做到强一致性的 ACID 的。特别是我们需要跨多个系统的时候，而且这些系统还不是由一个公司所提供的。BASE 的系统倾向于设计出更加有弹力的系统，在短时间内，就算是有数据不同步的风险，我们也应该允许新的交易可以发生，而后面我们在业务上将可能出现问题的事务通过补偿的方式处理掉，以保证最终的一致性。\n所以我们在实际开发中会进行取舍，对于更多的金融核心以上的业务系统可以采用补偿事务，补偿事务处理方面在30年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较也公认 Saga 是作为长事务的解决方案。 \u0026amp;gt; https://github.com/aphyr/dist-sagas/blob/master/sagas.pdf \u0026amp;gt; http://microservices.io/patterns/data/saga.html\n社区和业界的方案 Apache Camel Saga Camel 是实现 EIP（Enterprise Integration Patterns）企业集成模式的一款开源产品，它基于事件驱动的架构，有着良好的性能和吞吐量，它在2.21版本新增加了 Saga EIP。\nSaga EIP 提供了一种方式可以通过 camel route 定义一系列有关联关系的 Action，这些 Action 要么都执行成功，要么都回滚，Saga 可以协调任何通讯协议的分布式服务或本地服务，并达到全局的最终一致性。Saga 不要求整个处理在短时间内完成，因为它不占用任何数据库锁，它可以支持需要长时间处理的请求，从几秒到几天，Camel 的 Saga EIP 是基于 Microprofile 的 LRA（Long Running Action），同样也是支持协调任何通讯协议任何语言实现的分布式服务。\nSaga 的实现不会对数据进行加锁，而是在给操作定义它的“补偿操作”，当正常流程执行出错的时候触发那些已经执行过的操作的“补偿操作”，将流程回滚掉。“补偿操作”可以在 Camel route 上用 Java 或 XML DSL（Definition Specific Language）来定义。\n下面是一个 Java DSL 示例：\n// action from(\u0026amp;quot;direct:reserveCredit\u0026amp;quot;) .bean(idService, \u0026amp;quot;generateCustomId\u0026amp;quot;) // generate a custom Id and set it in the body .to(\u0026amp;quot;direct:creditReservation\u0026amp;quot;) // delegate action from(\u0026amp;quot;direct:creditReservation\u0026amp;quot;) .saga() .propagation(SagaPropagation.SUPPORTS) .option(\u0026amp;quot;CreditId\u0026amp;quot;, body()) // mark the current body as needed in the compensating action .compensation(\u0026amp;quot;direct:creditRefund\u0026amp;quot;) .bean(creditService, \u0026amp;quot;reserveCredit\u0026amp;quot;) .log(\u0026amp;quot;Credit ${header.amount} …","date":1572861600,"description":" 一起来解读 Seata Saga 模式到底解决了什么问题。","dir":"blog/seata-saga-flexible-financial-applications/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9c17449b81e0f1fe51d46bbaeaaa5516","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-saga-flexible-financial-applications/","publishdate":"2019-11-04T18:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/seata-saga-flexible-financial-applications/","summary":"Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的","tags":["Seata"],"title":"基于 Seata Saga 设计更有弹性的金融应用","type":"blog","url":"/sofastack.tech/blog/seata-saga-flexible-financial-applications/","wordcount":6384},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@罗健 提问： \u0026amp;gt; SOFAJRaft 跨机房支持吗？\nA： 跨机房不需要特殊支持，只是网络延时大一点而已。\n 延时大了，读写性能就会降低了吧？ 像 ZooKeeper 一样。\n A：1. SOFAJRaft 支持 transfer leader，把 leader transfer 到和业务就近的机房（目前需要手动调用 cli 服务）； 2. SOFAJRaft 1.3.0 会增加一个选举优先级特性，可以将指定机房节点优先级调高，尽量保证 leader 在指定机房。 SOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、@阮仁照 提问： \u0026amp;gt; SOFAArk 在打多个 ark-biz 包时，如果有多个 biz 包之间互相调用，默认是会走 injvm 协议的，这是如何做到的。我看了 SOFABoot 那块对 injvm 的支持，是通过 sofaRuntimeContext 来查找实现类，sofaRuntimeContext 是被 spring 容器管理的 bean，这就要求多个 biz 包之间是共用一套 spring 环境（或者说有个统一的父容器），是这样的吗？还是有什么其他实现的思路？\nA：可以看下 com.alipay.sofa.runtime.invoke.DynamicJvmServiceProxyFinder 这个类。\n 懂了，原来在这之上还有个 SofaFramework维护一个静态变量，真巧妙，用这个来解决多个 spring 容器里的 rpc 调用问题吗？\n A：多个 spring 容器之间的调用，不是 rpc 调用，是进程内调用。\n 对的， 这里不是 rpc 调用了， 所以这里也是 filter 会失效的原因。这样的话，那 SofaFramework 这个类就要被所有子容器都共享才对，但是我看打出来的 executable-ark 包，并没有在 classpath 下加载这个类啊，子容器咋共享的？\n A：这个会打包成一个插件，放在 ark plugin 层。 既然说插件之间是隔离的，那你把 SofaFramework 打在插件里，别的 biz 包启动时从会从 plugin里拿一个 SofaFramework ，互相不可见，这不是有问题吗？\n A：不同 biz 会共享同一个。 SOFAArk：https://github.com/sofastack/sofa-ark\n3、@温明磊 提问： \u0026amp;gt; Seata 的 Saga 模式的 json 文件，支持热部署吗？\nA：支持，stateMachineEngine.getStateMachineConfig().getStateMachineRepository().registryByResources()。不过 Java 代码和服务需要自己实现支持热部署。\n Seata 服务部署集群是需要怎么配置? 还是现在不支持\n A：异步执行一个服务，已实现。https://github.com/seata/seata/issues/1843\n Saga 的参数是不是只能在状态机启动时定义。如果第二个服务，依赖第一个服务返回的信息，或者里面组装好的信息怎么办？\n A：有个 Output 参数定义，可以把服务返回的参数映射到状态机上下文，然后在下一个服务的 Input 里定义参数引用。\n 异步执行服务的话，需要在 file 加上这个配置吗? A：这个是状态机定义的 Json 文件，不是 Seata 的客户端配置文件。 Seata：https://github.com/seata/seata\n本周推荐阅读 备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？\n K8s 1.14 发布了，Release Note 该怎么读？\n SOFA 项目进展 本周发布详情如下：\n发布 SOFAMosn v0.8.0，主要变更如下： i. 内存占用优化，优化在连接数、并发数较多的场景下的内存占用 ii. Metrics 统计优化，RPC 心跳场景不计入 QPS 等 Metrics 统计 iii. XDS 处理优化，修改为完全无阻塞启动，并且降低了重试的频率 详细发布报告，请见： https://github.com/sofastack/sofa-mosn/releases/tag/0.8.0\n","date":1572591600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191101/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cd5f758d6d5d28784524b55169ae0a98","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191101/","publishdate":"2019-11-01T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191101/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/28 - 11/01】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191101/","wordcount":1512},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:ArkLab/\u0026amp;gt;是《剖析 | SOFAArk 源码》系列，会逐步详细介绍 SOFAArk 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFAArk SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力。在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\nSOFAArk :https://github.com/sofastack/sofa-ark\n|\u0026amp;lt; SOFA:ArkLab/\u0026amp;gt; 认领列表：\n 【已完成】轻量级类隔离框架 SOFAArk 简介 【已认领】 SOFAArk 容器模型解析 【已认领】 SOFAArk 类加载模型机制解析 【已认领】 SOFAArk 合并部署能力解析 【已认领】 SOFAArk SPI 机制和 ClassLoaderHook 机制解析 【已认领】 SOFAArk 动态配置机制解析 【已认领】 SOFAArk maven 打包插件解析 【已认领】 （实践）SOFAArk 插件化机制解析与实践 领取方式：关注「金融级分布式架构」 回复可领取的文章标题，我们将会主动联系你，确认资质后，即可加入 SOFA:ArkLab/，It\u0026amp;rsquo;s your show time！\n 如果有同学对以上某个主题特别感兴趣的，可以留言讨论，我们会适当根据大家的反馈调整文章的顺序，谢谢大家关注 SOFAStack ，关注 SOFAArk，我们会一直与大家一起成长的。\n除了源码解析，也欢迎提交 issue 和 PR： SOFAArk :https://github.com/sofastack/sofa-ark\n欢迎领取，参与共建~\n","date":1572408000,"description":"欢迎参与 SOFAArk 源码解析系列文章共建。","dir":"activities/sofa-ark-lab/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"02869baa65a4730cea247cf1763d920c","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-ark-lab/","publishdate":"2019-10-30T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-ark-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:ArkLab/\u0026gt;是《剖析 | SOFAArk 源码》系列，会逐步详细介","tags":["SOFALab","SOFAArk","剖析 | SOFAArk 源码"],"title":"\u003cSOFA:ArkLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-ark-lab/","wordcount":572},{"author":"沧漠","categories":"Kubernetes","content":" 本文 PPT 下载\n导读：Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统，它大幅降低了容器化应用部署的门槛，但运维和管理一个生产级的高可用 Kubernetes 集群仍十分困难。本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。\nKubernetes 以其超前的设计理念和优秀的技术架构，在容器编排领域拔得头筹。越来越多的公司开始在生产环境部署实践 Kubernetes，在阿里巴巴和蚂蚁金服 Kubernetes 已被大规模用于生产环境。\n系统概览 Kubernetes 集群管理系统需要具备便捷的集群生命周期管理能力，完成集群的创建、升级和工作节点的管理。在大规模场景下，集群变更的可控性直接关系到集群的稳定性，因此管理系统可监控、可灰度、可回滚的能力是系统设计的重点之一。除此之外，超大规模集群中，节点数量已经达到 10K 量级，节点硬件故障、组件异常等问题会常态出现。面向大规模集群的管理系统在设计之初就需要充分考虑这些异常场景，并能够从这些异常场景中自恢复。\n设计模式 基于这些背景，我们设计了一个面向终态的集群管理系统。系统定时检测集群当前状态，判断是否与目标状态一致，出现不一致时，Operators 会发起一系列操作，驱动集群达到目标状态。这一设计参考控制理论中常见的负反馈闭环控制系统，系统实现闭环，可以有效抵御系统外部的干扰，在我们的场景下，干扰对应于节点软硬件故障。\n架构设计 如上图，元集群是一个高可用的 Kubernetes 集群，用于管理 N 个业务集群的 Master 节点。业务集群是一个服务生产业务的 Kubernetes 集群。SigmaBoss 是集群管理入口，为用户提供便捷的交互界面和可控的变更流程。元集群中部署的 Cluster-Operator 提供了业务集群集群创建、删除和升级能力，Cluster-Operator 面向终态设计，当业务集群 Master 节点或组件异常时，会自动隔离并进行修复，以保证业务集群 Master 节点达到稳定的终态。这种采用 Kubernetes 管理 Kubernetes 的方案，我们称作 Kube on Kube 方案，简称 KOK 方案。业务集群中部署有 Machine-Operator 和节点故障自愈组件用于管理业务集群的工作节点，提供节点新增、删除、升级和故障处理能力。在 Machine-Operator 提供的单节点终态保持的能力上，SigmaBoss 上构建了集群维度灰度变更和回滚能力。\n核心组件 集群终态保持器 基于 K8s CRD，在元集群中定义了 Cluster CRD 来描述业务集群终态，每个业务集群对应一个 Cluster 资源，创建、删除、更新 Cluster 资源对应于实现业务集群创建、删除和升级。Cluster-Operator watch Cluster 资源，驱动业务集群 Master 组件达到 Cluster 资源描述的终态。业务集群 Master 组件版本集中维护在 ClusterPackageVersion CRD 中，ClusterPackageVersion 资源记录了 Master 组件（如：api-server、controller-manager、scheduler、operators 等）的镜像、默认启动参数等信息。Cluster 资源唯一关联一个 ClusterPackageVersion，修改 Cluster CRD 中记录的 ClusterPackageVersion 版本即可完成业务集群 Master 组件发布和回滚。\n节点终态保持器 Kubernetes 集群工作节点的管理任务主要有：\n 节点系统配置、内核补丁管理； docker / kubelet 等组件安装、升级、卸载； 节点终态和可调度状态管理（如关键 DaemonSet 部署完成后才允许开启调度）； 节点故障自愈。 为实现上述管理任务，在业务集群中定义了 Machine CRD 来描述工作节点终态，每一个工作节点对应一个 Machine 资源，通过修改 Machine 资源来管理工作节点。\nMachine CRD 定义如下图所示，spec 中描述了节点需要安装的组件名和版本，status 中记录有当前这个工作节点各组件安装运行状态。除此之外，Machine CRD 还提供了插件式终态管理能力，用于与其它节点管理 Operators 协作，这部分会在后文详细介绍。\n工作节点上的组件版本管理由 MachinePackageVersion CRD 完成。MachinePackageVersion 维护了每个组件的 rpm 版本、配置和安装方法等信息。一个 Machine 资源会关联 N 个不同的 MachinePackageVersion，用来实现安装多个组件。\n在 Machine、MachinePackageVersion CRD 基础上，设计实现了节点终态控制器 Machine-Operator。Machine-Operator watch Machine 资源，解析 MachinePackageVersion，在节点上执行运维操作来驱动节点达到终态，并持续守护终态。\n节点终态管理 随着业务诉求的变化，节点管理已不再局限于安装 docker / kubelet 等组件，我们需要实现如等待日志采集 DaemonSet 部署完成才可以开启调度的需求，而且这类需求变得越来越多。如果将终态统一交由 Machine-Operator 管理，势必会增加 Machine-Operator 与其它组件的耦合性，而且系统的扩展性会受到影响。因此，我们设计了一套节点终态管理的机制，来协调 Machine-Operator 和其它节点运维 Operators。设计如下图所示：\n 全量 ReadinessGates: 记录节点可调度需要检查的 Condition 列表； Condition ConfigMap: 各节点运维 Operators 终态状态上报 ConfigMap； 协作关系：\n 外部节点运维 Operators 检测并上报与自己相关的子终态数据至对应的 Condition ConfigMap； Machine-Operator 根据标签获取节点相关的所有子终态 Condition ConfigMap，并同步至 Machine status 的 conditions 中； Machine-Operator 根据全量 ReadinessGates 中记录的 Condition 列表，检查节点是否达到终态，未达到终态的节点不开启调度。 节点故障自愈 我们都知道物理机硬件存在一定的故障概率，随着集群节点规模的增加，集群中会常态出现故障节点，如果不及时修复上线，这部分物理机的资源将会被闲置。\n为解决这一问题，我们设计了一套故障发现、隔离、修复的闭环自愈系统。\n如下图所示，故障发现方面，采取 Agent 上报和监控系统主动探测相结合的方式，保证了故障发现的实时性和可靠性（Agent 上报实时性比较好，监控系统主动探测可以覆盖 Agent 异常未上 …","date":1572246000,"description":"本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。","dir":"blog/ant-financial-managing-large-scale-kubernetes-clusters/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0fbce82d736863f9039c6a8f15c6f5d5","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","publishdate":"2019-10-28T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","summary":"本文 PPT 下载 导读：Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统，它大幅降低了容器化应用部署的门槛，但运维和管理一个生产级","tags":["Kubernetes"],"title":"备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？","type":"blog","url":"/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/","wordcount":4899},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@罗健 提问：\n 请问，SOFAJRaft 跨机房支持吗？\n A：跨机房不需要特殊支持，只是网络延时大一点而已。\n 延时大了，读写性能就会降低了吧？ 像 ZooKeeper 一样。\n A：1. SOFAJRaft 支持 transfer leader，把 leader transfer 到和业务就近的机房（目前需要手动调用 cli 服务） 2. SOFAJRaft 1.3.0 会增加一个选举优先级特性，可以将指定机房节点优先级调高，尽量保证 leader 在指定机房。\n2、@梁开心 提问：\n 使用 Seata 的时候，现在是 AT 模式 如果改成 Saga 模式的话，改造会大吗？\n A：AT 模式完全是透明的，Saga 是有侵入性的，要配置状态机 json，如果服务多改造会比较大。\n Saga 模式是不是基于 AT 来加强的长事务处理呢？\n A：没有基于 AT，客户端完全是两套，Server 端是复用的。你也可以看 Saga 的单元测试，那里有很多示例：https://github.com/seata/seata/tree/develop/test/src/test/java/io/seata/saga/engine\n Saga 服务流程可以不配置吗，使用全局事务 id 串起来，这样省去配置的工作量，再加上人工配置难免会配置错误。\n A：Saga 一般有两种实现，一种是基于状态机定义，比如 apache camel saga、eventuate，一种是基于注解+拦截器实现，比如 service comb saga，后者是不需要配置状态图的。由于 Saga 事务不保证隔离性, 在极端情况下可能由于脏写无法完成回滚操作, 比如举一个极端的例子, 分布式事务内先给用户 A 充值, 然后给用户B扣减余额, 如果在给 A 用户充值成功, 在事务提交以前, A 用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了，有些业务场景可以允许让业务最终成功, 在回滚不了的情况下可以继续重试完成后面的流程, 基于状态机引擎除可以提供“回滚”能力外, 还可以提供“向前”恢复上下文继续执行的能力, 让业务最终执行成功, 达到最终一致性的目的，所以在实际生产中基于状态机的实现应用更多。后续也会提供基于注解+拦截器实现。\n3、@温明磊 提问：\n 关于 Saga 的使用，有两个问题咨询下 1、比如有服务 A 在系统1里面，服务 B 在系统2里面。全局事务由 A 开启，流程调用 B 开启子事务，那系统2也需要维护 Saga 状态机的三个表吗，也需要在 Spring Bean 配置文件中配置一个 StateMachineEngine 吗？\n2、如果 系统1和系统2里面的服务，可以相互调用。系统12都可以开启全局事务，可以这样使用吗。那1和2 都需要维护Saga状态机的三个表，也需要在Spring Bean配置文件中配置一个StateMachineEngine。\n A：1、不需要，只在发起方记录日志。由于只在发起方记录日志同时对参与者服务没有接口参数的要求，使得Saga可以方便集成其它机构或遗留系统的服务。 2、可以这样使用，如果两个系统都开启 Saga 事务，那就要记录那三个表配置 StateMachineEngine。\n 这个 EventQueue 只是开启分布式事务的系统 来进行事件驱动，调用其它系统服务像调用本地一样。系统之间还是 RPC 调用是吧，而不是系统之前也是纯事件驱动的？ A：是的。你指的\u0026amp;rdquo;系统之间也是纯事件驱动的\u0026amp;rdquo; 是不是说 RPC 也是非阻塞的？\n 是的，也可以是异步的。\n A：那 RPC 的非阻塞需要 rpc client 支持，理论上也是可以的。rpc client 如果也是非阻塞 IO，那么所有环节都是异步了。\n 就是考虑一个业务流程， 它后续的子流程， 不管谁先运行都不会相互影响，可以异步调用。子流程是其它系统服务。Seata Saga 是不是实现了这点，其实我没看明白 ，Seata Saga 异步调用具体是不是各个节点异步了。是不是两个 ServiceTask 类型，可以同时 process ？\n A：你说的是并发节点类型，还未实现，接下来会实现。目前的事件驱动是指的节点的执行是事件驱动的，流程的顺序是同步的。上一个节点执行完成后，产生事件，触发下一个节点执行。如果要满足你刚说的需求要扩展并发节点。\n 那目前区分同步 BUS 和异步 BUS 是什么作用？\n A：同步 BUS 是线程阻塞的，等整个状态机执行完毕才返回，异步 BUS 是非线程阻塞的，调用后立即返回，状态机执行完毕后回调你的 Callback。\n IsPersist: 执行日志是否进行存储，默认是 true，有一些查询类的服务可以配置在 false，执行日志不进行存储提高性能，因为当异常恢复时可以重复执行？\n A：是的，可以配置成 false, 不过建议先保持默认，这样在查询执行日志比较全，真的要做性能调优再配，一般不会有性能问题。\n每周推荐阅读 蚂蚁金服开源背后的“有意思”工程师 | 1024快乐 蚂蚁金服云原生专家招聘 | 1024有你更快乐 SOFA 项目进展 本周发布详情如下：\n1、Occlum 是一个多任务、内存安全的库操作系统，专门针对可信执行环境（如 Intel SGX）。\n发布 Occlum v0.6.0，主要变更如下： i. 支持 release 模式运行 enclave，轻松发布基于 Occlum 的 SGX 应用； ii. 给 SEFS 增加额外的 MAC 和权限检查，保证 Occlum 的 FS 镜像的完整性； iii. 重构底层错误处理机制，使得报错对用户友好，且附带详细的调试信息； iv. 增加3个新 demo，包括 Bazel、HTTPS file server 和 Tensorflow Lite； v. 在 Docker 镜像中默认安装 Occlum，使得用户开箱即用； 详细发布报告： https://github.com/occlum/occlum/releases/tag/0.6.0\n2、发布SOFARPC v5.5.9，主要变更如下： …","date":1571986800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191025/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7927ee3392339de5283b8c4e75f9b4e9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191025/","publishdate":"2019-10-25T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191025/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/21 - 10/25】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191025/","wordcount":2571},{"author":"SOFAStack","categories":"1024","content":" !important 希望我们是最早给你祝福的朋友\n去年的1024，我们回顾了第一代到第五代架构 去年的今天，我们和大家分享了 SOFAStack 背后的这群工程师。比如程立，花名鲁肃，蚂蚁金服 CTO。胡喜，蚂蚁金服副总裁、副CTO。杨冰，蚂蚁金服智能科技产品技术部总监。\n也与大家分享了从第一代到第五代架构的进化历程，详解了 SOFAStack 走的这一条跟传统金融行业不同的分布式架构之路。要基于不可靠的硬件系统实现金融级的性能和可靠性，要应对支付宝这样的超大规模互联网金融应用，有很多难题要解决。蚂蚁金服构建了一整套处理金融级交易的分布式架构与平台，在金融级的一致性要求和海量并发处理能力上达到了很好的平衡，并在快速容灾恢复、弹性伸缩能力、多地多活高可用保证能力和按需供给的精细化资源调度能力方面沉淀了丰富的实践经验。\n前往去年此刻的时光机：蚂蚁金服自研架构SOFA背后的工程师|1024快乐\n今年，SOFAStack 团队在忙什么呢？ 近几年来，“云原生架构”的相关话题讨论比较热烈，我们也相信这也将是金融 IT 架构的关键发展趋势之一。IT 架构转型绝不是一蹴而就的，积极探索和应用以“云原生”为代表的新兴技术的同时，还需考虑与传统模式和技术融合并存，沿着一条稳妥的可落地路径进行创新变革，确保架构转型的价值交付能够稳妥支撑甚至积极引领业务创新。\nService Mesh 是蚂蚁金服下一代架构的核心，这一年，我们在奔跑的火车上换轮子，将现有的微服务架构快速演进到云原生架构。RPC、消息、DB、安全、运维等每一个环节均充满挑战。\n蚂蚁金服每年双十一大促会面临非常大的流量挑战，在已有 LDC 微服务架构下已支撑起弹性扩容能力。当有多个大促分阶段进行时，如何在架构上保障资源最大程度复用降低大促成本极具挑战。期望在最小规模的资源集群下可通过灵活的架构来支撑起快速的资源腾挪来达成多个大促链路最大化利用资源的目的。通过 Service Mesh 架构的支持，基础设施层在应用外具备更强的管控能力，通过流量的调拨，JVM 内存的动态 Swap 等手段可以使用技术手段达成节省资源的目的。 今年即将到来的双十一，蚂蚁金服这套 Service Mesh 将迎来第一次大考 — 双十一实战，也或许是业界第一个如此大规模的实战，请持续关注本公众号，我们会逐步进行技术揭秘。\n今天，我们想介绍蚂蚁金服开源背后的这位“有意思”工程师： 对于蚂蚁金服研究员王益而言，2019年是个颇有纪念意义的年份。今年他整40岁。从10岁开始，写代码整30年。这30年来，他当过“不务正业”的学生，创纪录地在大一就考下系统分析员，“单枪匹马”闯荡过从国内到硅谷的多家知名互联网科技公司，和AI领域许多传奇人物都有所交集。不惑之年对于许多工程师来说，或许已是需要焦虑的年龄，但40岁的王益在蚂蚁金服每天都过得很充实：起床，自由泳一千米，然后去做他最喜欢的事——写代码和组织大家一起写代码。\n 2019年9月11日，在上海举办的Google开发者大会上，蚂蚁金服研究员王益分享了新开发的分布式深度学习系统ElasticDL。这是他来到蚂蚁金服的一年之中所做的第二个开源项目，主要用于大幅提升集群总体利用率以及深度学习团队的工作效能。之前开源的 SQLFlow系统在短短的几个月之间，已经在GitHub上获得了三千多颗星星。\n2019对于王益而言是个颇有纪念意义的年份，今年他整40岁，写代码整30年。 这听上去是一件不可思议的事——30年前，上世纪的80年代末，他在⻓沙上小学，全城都很难找出一位能教编程的老师，个人电脑更是一个陌生名词，一台以苹果2为原型、可以用BASIC语言编程的 “中华学习机”售价7000人民币，在当时几乎可以买下一套房子。\n幸运的是，王益在10岁那年得到了这样一件贵重的礼物，从这台学习机和一本BASIC语言教材开始，他开启了与代码结缘的人生。\n“我那时不是个好学生，经常受‘别人家的孩子’打击，老师和同学都觉得写代码是不务正业。”回想起30年来的经历，这位清华博士、足迹从国内到硅谷历经多家知名互联网科技公司的学霸笑谈自己“活得比较任性”，“但我就是想做与众不同的事。别人越说这样不行，我就越想用这种方式证明自己。”\n初中毕业那年的暑假，他用“中华学习机”和自己焊接的电路板，把自家的老式“威力牌”双筒洗衣机改造成了自动洗衣机。同时，他用Apple BASIC语言和6502汇编混合编程，写了人生中第一个游戏。高中三年，其他同学努力备考，他却加班加点自学了大学计算机系所有课程，随后参加计算机水平考试，先后获得了程序员、高级程序员、以及最高级别系统分析员资格。2018年，他获得Google APAC Innovation Award。从不断摸索代码世界的少年时代，到专注于AI基础架构和系统开发的求学工作生涯，这份“任性”一直伴随他走到今天。\n“我经常从零开始。选择去做什么的一大标准是‘有意思’。”\n相比于规划一条稳妥的职业发展道路，王益更愿意顺应自己强烈的好奇心，去选择最困难但最有意思的探索方向。他在中国和美国互联网公司都工作过，也分别在美国公司的中国分部和中国公司的美国分部工作过。他的足迹遍及国内BAT三家。任性的是，每次跳槽， 他都从一个人coding一个创新项目开始，吸引同事们加入，从而组建团队。虽然2011年就在腾讯作为广告系统技术总监，但是他从不在跳槽时要求带何等规模的团队。\n2014年，王益带着妻子和两个月大的女儿离开腾讯移居硅谷。“一切都归零了。工资减半。”他笑笑说。不过凭着多位学界和业界领袖的推荐，他很快就安顿下来，不到一年就开始在硅谷创业，作为Head of Research Scienets 参与创建了AI创业公司 ScaledInference。这是一家人才济济的创业公司。人工智能行业的领袖人物、加州大学伯克利分校的Michael Jordan教授是这家公司顾问。陆奇曾代表微软到访，讨论技术合作。“可惜我们不够关注业务落地，做的不够好。技术研发一定要有落地的能力。”事后，王益不无遗憾的说。\n在加入蚂蚁金服之前，王益在百度硅谷研究院工作，负责开源深度学习系统PaddlePaddle。在历经两年的艰苦开发，新一代技术Fluid开始系统地落地百度各个业务之后，他发起了他在 PaddlePaddle的最后一个子项目——一条太阳能驱动的无人驾驶船。这是一条双体船，由他和五岁女儿的两条划艇构成。船上的笔记本电脑运行基于immitation learning的人工智能系统，自动学习驾驶者的技巧。为了船体稳定，他在自家车库里焊接了连接两条划艇的金属框架。便于拆装的结构，可以装上他的皮卡，方便下水测试。\n做出加入蚂蚁金服的决定，也是出于同样的理由——“有意思”。“这里的业务很新颖，对AI 有着更加多样化的需求。”如何用AI解决金融行业的问题，是和他以往所面对的完全不同的全新挑战。 SQLFlow：分析师与AI模型间的翻译  加入蚂蚁金服不久，王益就意识到自己之前的朦胧猜想越来越清晰地被验证：和主要依靠流量与广告赚钱的传统互联网公司不同，蚂蚁金服不是纯互联网公司，它有独特的商业模式和对于工具的独到需求。\n此前的十多年中，他的大部分经历是在传统互联网 …","date":1571883840,"description":"不管世界如何，永远永远希望开发者能感觉技术“有意思”，永远希望开发者快乐不复杂。","dir":"blog/ant-financial-happy-1024/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c89decd5fb9b75c59f487dc58bac0365","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-happy-1024/","publishdate":"2019-10-24T10:24:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/ant-financial-happy-1024/","summary":"!important 希望我们是最早给你祝福的朋友 去年的1024，我们回顾了第一代到第五代架构 去年的今天，我们和大家分享了 SOFAStack 背后的这群工程师。比如程立，花名鲁肃","tags":["1024"],"title":"蚂蚁金服开源背后的“有意思”工程师 | 1024快乐","type":"blog","url":"/sofastack.tech/blog/ant-financial-happy-1024/","wordcount":5806},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@温明磊 提问： \u0026amp;gt; 最近在选型 Zeebe 还是 Seata Saga 来实现微服务编排。Zeebe 使用了基于行业标准 BPMN 2.0 的可视工作流。 但是考虑到 Seata 的开源和生态，如果 Seata 能实现流程可视就好了。\nA：未来我们会做可视化的也可以社区贡献。另外给一个调研服务编排选型的建议，遵循 bpmn 2.0 行业标准没有问题的，不过 bmpn2.0 xml 格式太复杂了，我们微服务的编排不需要那么多标签，另外微服务的编排里有很重要一块就是要保证编排的服务的事务一致性，所以需有能支持分布式事务的处理能力，这里面就会涉及服务的状态判断定义，异常处理定义，复杂服务参数的映射，这些在 bpmn 2.0 标准里是没有定义的（当然框架可以在扩展节点里自己扩展）。用 json 定义之后，你会发现其实有没有可视化开发工具没有那么重要了，只是如果有个可视化监控更好。\n 是的，json 我们都可以自己组装。只要把业务接口做成可视可配，完全可以用配置信息组装 json。这样说不知道对不对。但是像您说的，有个可视化的工具 肯定要更好点。\n A：是的，json 还有一个好处是，服务调用的参数可以直接在 json 里组织好。\nSOFARegistryLab 系列阅读 服务注册中心 Session 存储策略 | SOFARegistry 解析 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 云原生推荐阅读 云原生时代，什么是蚂蚁金服推荐的金融架构？ 当金融科技遇上云原生，蚂蚁金服是怎么做安全架构的？ SOFA 项目进展 发布 Seata v0.9.0，主要变更如下：\ni. 长事务解决方案: Saga 模式（基于状态机实现） ii. 支持自定义配置和注册中心类型 iii. 支持 spring cloud config 配置中心 iv. 修复对象锁和全局锁可能造成的死锁和优化锁的粒度 v. 修复 oracle 的批量获取问题 vi. 优化了一些基于 java5 的语法结构 vii. 抽象 undologManager 的通用方法\n详细发布报告： https://github.com/seata/seata/releases/tag/v0.9.0\n云原生活动推荐 Service Mesh Meetup 是由蚂蚁金服联合 CNCF 官方共同出品，ServiceMesher 社区主办，主题围绕服务网格、Kubernetes 及云原生，在全国各地循环举办的技术沙龙。\n本期 Meetup 邀请社区大咖，从服务网格下微服务架构设计、在 5G 时代的应用、如何使用开源的 Traefik 构建云原生边缘路由及蚂蚁金服的服务网格代理演进角度给大家带来精彩分享。\n时间：2019年10月26日（周六）13:00-17:0 0地点：成都武侯区蚂蚁C空间 报名方式：点击这里，即可锁定席位\n","date":1571382000,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191018/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"91ccf1c351bfb03d7e18f70fad5f5224","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191018/","publishdate":"2019-10-18T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191018/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/14 - 10/18】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191018/","wordcount":1198},{"author":"力鲲","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第五篇，本篇作者力鲲，来自蚂蚁金服。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n回顾：服务注册 SOFARegistry 作为服务注册中心，面临的一个很重要的挑战就是如何解决海量的客户端连接问题，这也是本文要剖析的内容。不过作为一篇完整的文章，我们还是会先花一点时间介绍 SOFARegistry 的相关信息，以便读者了解其背景。\n服务注册中心在服务调用的场景中，扮演一个“中介”的角色，服务发布者 (Publisher) 将服务发布到服务注册中心，服务调用方 (Subscriber) 通过访问服务注册中心就能够获取到服务信息，进而实现调用。\n图1 - 服务的“中介”\n流程：订阅 / 发布 在《海量数据下的注册中心 - SOFARegistry 架构介绍》一文中，我们提到了一个典型的 “RPC 调用的服务寻址” 应用场景，服务的提供方通过如下两个步骤完成服务发布：\n 注册，将自己以 Publisher 的角色注册到 SOFARegistry； 发布，将需要发布的数据 (通常是IP 地址、端口、调用方式等) 发布到 SOFARegistry； 与此相对应的，服务的调用方通过如下步骤实现服务调用：\n 注册，将自己以 Subscriber 的角色注册到 SOFARegistry； 订阅，收到 SOFARegistry 推送的服务数据； 从上面我们可以看到，整个流程中很重要的一个步骤就是注册，不管是 Publisher 还是 Subscriber 都只能在注册成功后才能实现发布订阅的需求。因此 SOFARegistry 要解决的一个问题就是如何维护与 Client 连接而产生的 Session，尤其是当 Client 数量众多的时候。\n图2 - 海量啊海量\n设计：分层隔离 在 SOFARegistry 的应用场景中，体量庞大的数据主要有两类：Session 数据、服务信息数据。两类数据的相同之处在于其数据量都会不断扩展，而不同的是其扩展的原因并不相同：Session 是对应于 Client 的连接，其数据量是随着业务机器规模的扩展而增长，而服务信息数据量的增长是由 Publisher 的发布所决定。所以 SOFARegistry 通过分层设计，将两种数据隔离，从而使二者的扩容互不影响。\n图3 - 分层，扩容互不影响\n当然，对于分层设计的概念介绍，在《海量数据下的注册中心 - SOFARegistry 架构介绍》的 “如何支持海量客户端” 章节已经有了很完整的介绍，这里不再赘述。本文是想从代码层面来看看其设计实现的方式。\n通信 Exchange Exchange 作为 Client / Server 连接的抽象，负责节点之间的连接。在建立连接中，可以设置一系列应对不同任务的 handler (称之为 ChannelHandler)，这些 ChannelHandler 有的作为 Listener 用来处理连接事件，有的作为 Processor 用来处理各种指定的事件，比如服务信息数据变化、Subscriber 注册等事件。\n图4 - 每一层各司其职，协同实现节点通信\nSession 节点在启动的时候，利用 Exchange 设置了一系列 ChannelHandler：\n PublisherHandler SubscriberHandler\n WatcherHandler\n ClientNodeConnectionHandler\n CancelAddressRequestHandler\n SyncConfigHandler\n 其中 SubscriberHandler 和 PublisherHandler 主要是与服务发布方 (Publisher) 以及服务调用方 (Subscriber) 的行为相关，我们在下面说明。\n任务处理 由于 SubscriberHandler 在 Session 节点启动时就已经初始化并设置，所以当有 Subscriber 注册时，就由 SubscriberHandler 负责后续一系列的处理逻辑。\n图5 - Subscriber 的注册过程\n上面的流程图展示了 Subscriber 注册的处理过程，SessionSever 在处理注册请求时，除了保存 Subscriber 的会话信息，还要为新注册的 Subscriber 提供其所订阅的服务信息数据，最后通过推送的方式将数据发送 Subscriber。\n下面是上述流程在代码模块上的实现，我们依然用图的方式展示出来，大家按图索骥也便于查阅相关源码中的细节。\n图6 - 代码流转：Subscriber 注册\n可以看到，SOFARegistry 采用了 Handler - Task \u0026amp;amp; Strategy - Listener 的方式来应对服务注册中的各种场景和任务，这样的处理模型能够尽可能的让代码和架构清晰整洁。\nPublisher 的注册过程和 Subscriber 基本一致，略有不同的是 Publisher 在注册完毕之后将要发布的数据写到 DataServer 上。\n图7 - Publisher 的注册过程\n这个过程也是采用了 Handler - Task \u0026amp;amp; Strategy - Listener 的方式来处理，任务在代码内部的处理流程和订阅过程基本一致。\n图8 - 代码流转：Publisher 注册\n会话缓存 在二层架构中 (即 Client 直接连接 DataServer)，连接数是一个很难收敛的指标，因为当一个 Subscriber 订阅的服务位于不同 DataServer 上时，他就会与多个 DataServer 同时保持连接，这样“每台 DataServer 承载的连接数会随 Client 数量的增长而增长，每台 Client 极端的情况下需要与每台 DataServer 都建连，因此通过 DataServer 的扩容并不能线性的分摊 Client 连接数”。\n图9 - 两层结构中，扩容无法减少连接数\n这也是 SOFARegistry 设计三层模型的原因，通过 SessionServer 来负责与 Client 的连接，将每个 Client 的连接数收敛到 1，这样当 Client 数量增长时，只需要扩容 SessionServer 集群就可以了。 所以从设计初衷上我们就能够看出来 SessionServer 必须要满足的两个主要能力： …","date":1571223600,"description":" 本文为《剖析 | SOFARegistry 框架》第五篇，作者力鲲","dir":"blog/sofa-registry-session-storage/","fuzzywordcount":2900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5ae2be3be1d395dd7ccb2bddc97b346f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-session-storage/","publishdate":"2019-10-16T19:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-registry-session-storage/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心 Session 存储策略 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-session-storage/","wordcount":2821},{"author":"杨延昭","categories":"云原生","content":" 蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀，以及面向未来的金融技术创新和参会者分享。我们将其中的优秀演讲整理成文并将陆续发布在本网站，本文为其中一篇。\n 本文作者：杨延昭（杨冰），蚂蚁金服智能科技产品技术部总监\n互联网技术发展日新月异，我们正在进入云原生时代，这个过程中金融行业要如何拥抱云原生？在近两年蚂蚁金服将云原生在金融领域落地，沉淀下一些实践经验，接下来我想分享在蚂蚁的演进过程当中，我们心中的云原生是什么样的，在金融领域落地的时候遇到什么问题，以及我们是怎么解决的。\n经过多年云计算的蓬勃发展，上云已经不是太大问题，接下来的问题是怎么把云用好，用得更高效。RightScale 2019年最新数据显示，现在公有云规模占22%，只使用私有云的客户占3%，更多客户通过混合的模式去使用云，通过混合云取得数据隐私、安全与效率、弹性的平衡。\n再看全球整个 IT 行业，公有云的比例只占整个基础 IT 市场的10%，市场空间仍然很大，IT 市场中剩下很多都是传统企业客户。为什么传统行业无法很好地利用公有云，一个重要的原因是因为他们的 IT 系统经过很长时间建设，很多都有自己的机房。另外有些则业务比较稳定，对上公有云没有很强的需求。它们通常会发展混合云策略，把一些核心业务留在私有云，而把一些边缘业务或创新业务放在公有云上。\n这些特点在金融行业也非常明显，除此之外金融行业还有两个特征：\n 业务形态走向开放和互联网化：随着互联网和数字化经济的发展，金融机构需要进行数字化转型，以及业务敏捷化、服务场景化，以应对新的商业模式带来的冲击； 监管合规的诉求：金融行业的业务特点决定了必须是强隔离，强监管的，所以公有云上的资源共享模式在监管方面会有比较大的挑战。 因此，混合云战略对金融机构更为适用。这一结论也得到研究支持，根据调研机构 Nutanix 的报告，全球金融业在混合云应用方面的发展速度超过其它行业，目前部署普及率达到21%，而全球平均水平为18.5%。\n那么，什么样的混合云是适合金融机构的呢？以蚂蚁的演进历程为例。\n蚂蚁在第四代架构的时候演变成为云平台架构，而且为了应对互联网业务形态下突发性业务对资源的弹性需求，蚂蚁也在同一阶段将架构直接进化成弹性混合云架构。现在蚂蚁已经演进到第五代云原生架构。蚂蚁又是如何在云原生的架构下，把混合云变成金融级的混合云，我想会对各位有些启发。在这个发展过程中，有一条主线，是不同阶段蚂蚁对研发的标准和要求，包括：自主、成本、安全、稳定、海量、敏捷，这也是在在线金融的时代，我们对云原生架构的要求。\n从分布式到云原生 建立金融级交易支付系统  建立金融级的在线交易系统，第一步是要实现金融级分布式的架构，蚂蚁在这方面的代表技术是 SOFAStack 和 OceanBase，目前都已对外商业化，并有丰富的案例。SOFAStack 代表的是，在整个应用层或者无状态服务这个层面上，如何去做可伸缩、可扩展的一套架构。OceanBase 代表的是以数据库为代表的存储或者是有状态服务层面，如何在架构上面去进行分布式。它们拥有四个特性：\n 高可用，99.99%+的可用性保证，确保系统始终连续运行不中断； 一致性，在任何异常情况下数据最终一致，确保资金安全； 可扩展，支持应用级、数据库级、机房级、地域级的快速扩展； 高性能，存储采用读写分离架构，计算引擎全链路性能优化，准内存数据库性能。 而这四个关键的特性都是金融业务最为看重的，而且需要在应用和存储上端到端实现。 以一致性为例，在单个数据库内是可以确保数据一致性的，但在大规模应用的情况下，单个数据库总是会出现瓶颈，数据往往会像服务或者应用一样，按照类似交易、支付、账目等粒度垂直拆开，当这些数据分别存储在不同的数据库集群后，就需要在应用层来解决一致性问题了，同时为了支持海量数据，数据库集群内部也会做分别和多副本，OceanBase 就是这样一套分布式数据库，在其内部也要实现分布式事务。只有这样上下配合才能解掉所有分布式架构下的一致性问题，缺一不可。\n再比如可扩展性方面，有些系统号称做了分布式架构，实际可能只是用了微服务框架，做了应用层的服务化改造，但数据库层既没有用水平扩展的技术，也没用分布式数据库，整个系统的可扩展性就卡在数据层的短板上。\n所以，真正的分布式系统，需要实现端到端的分布式，才能实现无限可扩展和高性能，而真正的金融级分布式系统则要实现端到端的高可用和一致性。\n蚂蚁金服三地五中心异地多活架构我们认为，高可用架构最关键的目标是数据不丢，业务不停。在这个目标的基础上，我们设计并实施了三地五中心的异地多活架构。它的核心优势包括城市级容灾，低成本交易，无限可扩展，以及 RPO=0，PTO\u0026amp;lt;30s. 大家知道我们在去年云栖大会上做了一次剪网线的demo，它演示了整个架构层面上怎么样做到跨城市多活和灾难情况下的恢复快速恢复能力。同时在高可用达标的情况下，我们也做了很多风险相关的事情，总结起来就是在高可用的基础上还要做到资金的安全、变更的免疫和故障的快速恢复。\n解决了高可用的问题，其实金融级最被高频提到的话题就是安全，在云原生时代，我们要解决的是全链路、端到端的安全风险。具体分为三个层面：\n 云原生网络安全，包括策略化高效流量控制，全链路加密，流量劫持与分析； 云原生基础设施安全，包括安全容器，不共享内核，以及安全沙箱； 云原生业务安全，包括 SOFAEnclave 机密计算中间件，以及内存安全的、多任务 Enclave LibOS Occlum。  这个部分我的同事在《金融服务的云原生安全架构》演讲中会详细介绍。小结一下，所谓金融级的能力，最主要是要实现端到端的金融级的高可用，同时实现端到端的安全。接下来我想分享的是，在云原生这个阶段往前走遇到了哪些问题。\n从单元化到弹性架构 应对互联网爆炸式的流量脉冲  从单元化到云原生下的弹性架构\n首先解释下什么是单元化，大家可能比较容易理解数据库层的分库分表或者说 Sharding，能够通过分片的方式解决集中存储计算性能问题，单元化的核心思想是把数据的分片提前到了入口请求的分片，在机房的网络接入层将用户请求根据某个纬度（比如用户 ID）进行 Sharding，这就好比把每个机房就当做了一个巨大无比的有状态的数据库分片，当你是一个 ID 尾号为007或者008用户的时候，当请求通过手机端或者网页域名发送到机房，接入层就已经识别出应该将你路由到华东地区还是在华南地区。当你进入到某个地区的机房时，大部分请求处理工作可以在机房内部完成。偶尔会有一些业务可能会发生跨机房的服务调用，比如说数据在 A 机房的用户给数据在 B 机房的用户转账。这个时候就需要在这个机房上去做有状态的设计。\n我们走向云原生时代的时候，在大的架构上面用 Kubernetes 为基础来设计，在单元化架构下，我们选择在每个单元里部署一个 Kubernetes 集群，将支持多 K8s 集群管理和管控指令下发的 Federated APIServer 做逻辑上的全局部署，其中管控元数据是存储在一个 ETCD 集群的，以保持全局数据一 …","date":1571209200,"description":"本文将分享在蚂蚁金服的演进过程当中，我们心中的云原生是什么样的，在金融领域落地的时候遇到什么问题，以及我们是怎么解决的。","dir":"blog/ant-financial-native-cloud-financial-architecture/","fuzzywordcount":5400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b0fce431d72c523e27e31f1fe831fdee","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","publishdate":"2019-10-16T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","summary":"蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀","tags":["云原生"],"title":"云原生时代，什么是蚂蚁金服推荐的金融架构？","type":"blog","url":"/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/","wordcount":5366},{"author":"何征宇","categories":"云原生","content":" 蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀，以及面向未来的金融技术创新和参会者分享。我们将其中的优秀演讲整理成文并将陆续发布在“ 金融级分布式架构”公众号上，本文为其中一篇。\n 本文作者：何征宇，gVisor 创始人，蚂蚁金服研究员\n在云原生发展趋势之下，金融行业想要应用云原生技术，安全问题是一个非常大的拦路虎，而云原生社区对安全问题的重视程度远远不够。蚂蚁金服在落地云原生的时候，解决安全问题是重中之重，经过探索与实践，我们沉淀出了一套从底层硬件到软件、从系统到应用层的全链路金融级云原生安全架构。\n金融行业最重要的就是信任，我们认为，安全所带来的信任，是一种无形的产品，支撑着所有金融业务。\n顺应互联网时代发展，金融行业与机构也发生了很多的变化，包括 App、小程序等更多的访问渠道，更快的业务变化，更多的第三方供应商。但是，不管怎么变化，金融行业有一点始终不变，那就是 Zero Fault，对错误的零容忍，也就是对稳定性和安全性的极高要求。\n这里，我还想澄清大家对金融行业的一个错误看法，就是，大家都说金融机构有很多遗留系统，很多技术是十几年前的，就认为金融机构的技术是落后的。但其实，金融行业一直是科技含量非常高的。前段时间有一部电影上映，叫《蜂鸟计划》，根据真实事件改编，讲一帮做高频交易的人，为了降低从堪萨斯到纽约交易所的时间，建造了一条上千英里直通两地的光纤，想尽办法去争取那最后一毫秒。所以，金融行业并不只有平庸保守的科技，它同样也在追逐最前沿最先进的技术，我们的使命就是要用科技来进一步武装金融行业，为金融科技注入更多的活力。\n云原生架构其实代表一种新的生产力，金融行业肯定是需要云原生的，它为我们带来了节约成本和敏捷开发的能力，但是在它前面还需要加一个定语，就是安全的云原生架构，它里面不仅仅包含之前的相对简单的安全方案，而是一个从端到端的全链路可信的安全解决方案。包括明晰代码所有权，做到可信启动，对镜像的制作和发布收口，配合账号体系，明晰应用的所有权和访问权限；以及安全可独立部署的精细化隔离方案，将安全策略和实施集成在基础架构中，对软件开发和测试透明。\n这里我们着重分享蚂蚁金服正在实践的几项云原生安全技术，包括云原生网络安全 Service Mesh，安全容器，以及机密计算。\n云原生网络安全：SOFAMesh  当前，云原生里除了容器之外第二大技术其实就是 Service Mesh，从蚂蚁的实践来看，其实它对金融安全有非常高的帮助。它至少可以做到三点：\n 策略化高效流量控制，可以帮助运维迅速适应业务快速变化； 全链路加密，保护端到端数据安全； 流量劫持与分析，当发现异常流量与容器时，进行流量阻断。 并且，这些工作对业务是透明的，不需要给业务开发增加负担，同时我们还可以对流量进行实时的语义分析等等，做比传统的防火墙更多的事情。\n蚂蚁金服在对 Service Mesh 的探索中，推出了自己用 Golang 打造的 SOFAMesh，并且已经对外开源，希望和社区一起努力，让 Service Mesh 的理念和技术更加普及。\nSOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强大功能和丰富特性的基础上，为满足大规模部署下的性能要求以及应对落地实践中的实际情况，所做的改进包括采用 Golang 编写的 SOFAMosn 取代 Envoy，极大降低了 Mesh 本身的开发难度，并做了一些创新性工作，例如合并Mixer到数据平面以解决性能瓶颈，增强 Pilot 以实现更灵活的服务发现机制，增加对 SOFARPC、Dubbo 的支持，等等。\n更多详情可查看 SOFAMesh 的 GitHub 主页：https://github.com/sofastack/sofa-mesh\n蚂蚁金服率先在生产环境中大规模落地 SOFAMesh，超过 10W+ 容器做到了 Mesh 化，平稳支撑了 618 大促，给我们带来了多协议支持、UDPA、平滑升级、安全等多方面的好处，并且对性能仅有轻微的影响，单跳 CPU 增加 5% 损耗，RT增加不到 0.2ms，甚至部分业务经过 Mesh 化改造将业务链路下沉，RT 反而下降 7%。\n安全容器：Kata Containers  传统容器架构\n提云原生大家肯定都会提容器，传统容器从虚拟机到容器，其实是牺牲了隔离性的，从上图可以很清楚的看到，当我们的应用在容器里，其实共享着同一个 CPU、内存、网络和存储，只是从外面看起来是不同的。这会导致安全上的问题，就是不同的容器之间不存在真正的隔离，一旦一个容器发生安全问题，很可能影响到其它容器，甚至入侵整个系统。蚂蚁金服在这方面做的工作就是安全容器，具体就是 Kata Containers。\n安全容器架构\nKata Containers 安全容器是 OpenStack 基金会的顶级开放基础设施项目，由蚂蚁金服和 Intel 共同主导开发。在安全容器里，每个 Pod 运行在独立的沙箱中，彼此不共享内核，提供强安全保障。这里给大家分享一下 Kata Containers 的近期进展，针对大家最关注的性能问题有了非常大的提升：\n 引入 shimv2 每 Pod 辅助进程数量从 2N+2 减少到 1 个； 引入 virtiofs，提升文件系统性能约 70% 到 90%； 引入 Firecracker， VMM 内存开销从 60MB 降到约 15MB； 改用 rust 实现 agent，占用内存从 11MB 下降到约 1MB。 我们也会和社区一起继续共建 Kata Containers，让安全容器成为云原生的标配。\n安全容器可以有效的保护主机，但是，金融业务本身仍然需要更强的隔离保护，蚂蚁金服引入了机密计算，并根据实际场景研发了大规模落地解决方案 SOFAEnclave。\n机密计算中间件：SOFAEnclave 所谓机密计算，也就是基于例如 Inte SGX，ARM Trustzone 等可信执行环境（Trusted Execution Environment, TEE），也称为 Enclave ，访问计算机内存时隔离用户数据，以避免将数据暴露给其他应用程序、操作系统或其他云服务器租户的解决方案。\nEnclave架构\nEnclave 是运行时的双向保护，比如说你的金融业务跑在 Enclave 上的时候，操作系统都看不到 Enclave 里的内存，同时会进行完整性检查，保证访问 Enclave 的代码不被替换。\n但是 Enclave 目前存在一些问题，阻碍了它在实际生产环境中的应用。总结这些问题包括：\n第一，需要改写应用，因为可信执行环境里面没有内核和基础库，所以没法把应用直接在 Enclave 中执行；第二，需要分割应用，需要把业务程序划分为 Enclave 内和 Enclave 外的部分；第三，未集群化，与客户端场景不同，Enclave 中的应用如何 failover，容灾也是阻止其在数据中心中大规模使用的一个原因。 …","date":1571036400,"description":"本文着重分享蚂蚁金服正在实践的几项云原生安全技术，包括云原生网络安全 Service Mesh，安全容器，以及机密计算。","dir":"blog/ant-financial-native-cloud-security-architecture/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d65835b57ec0e3e24af2c65db5f41824","permalink":"https://sofastack.github.io/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","publishdate":"2019-10-14T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","summary":"蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀","tags":["云原生"],"title":"当金融科技遇上云原生，蚂蚁金服是怎么做安全架构的？","type":"blog","url":"/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/","wordcount":3402},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@陈文龙 提问：\n 请问一下，使用 Seata 时，undo_log 表的 rollback_info 字典的内容为｛｝（相当于空），事务回滚后记录又没被清除，而服务的日志打出的是成功回滚，log_status 是 1，这是什么原因呢？\n A：1 是防御性的，是收到 globalrollback 回滚请求，但是不确定某个事务分支的本地事务是否已经执行完成了，这时事先插入一条 branchid 相同的数据，插入的假数据成功了，本地事务继续执行就会报主键冲突自动回滚。假如插入不成功说明表里有数据这个本地事务已经执行完成了，那么取出这条 undolog 数据做反向回滚操作。\n相关阅读：分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾\nSOFARegistryLab 系列阅读 服务注册中心数据分片和同步方案详解 | SOFARegistry 解析 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 活动推荐 2019中国开源年会 (COSCon\u0026amp;rsquo;19) 正式启动啦~\n时间： 2019-11-02 09:00 ~ 11-03 17:00\n地址： 上海普陀区中山北路3663号华东师范大学（中北校区）\n本次大会的主题是“开源无疆、携手出航”（Let’s Cross the Boundaries Together!），这也代表主办方对于中国开源，走向世界，走向辉煌的殷切期望。\nSOFAStack 开源社区也受到主办方的邀请参加此次开源年会。\n更多重磅议题与开源嘉宾，点击“这里”，即可了解。\n","date":1570777200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191011/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"98ed37338b0cd1036114b205bcb980c2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191011/","publishdate":"2019-10-11T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191011/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【10/7 - 10/11】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191011/","wordcount":776},{"author":"明不二","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第四篇，本篇作者明不二。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 在前面的章节中我们已经提到，SOFARegistry 与其他服务发现领域的产品相比，最大的不同点在于支持海量数据。本章即将讲述 SOFARegistry 在支撑海量数据上的一些特性。\n本文将从如下几个方面进行讲解：\n DataServer 总体架构：对 SOFARegistry 中支持海量数据的总体架构做一个简述，讲解数据分片和同步方案中所涉及到的关键技术点； DataServer 启动：讲解 DataServer 启动的服务，从而为接下来更直观地理解数据分片、数据同步的触发时机以及触发方式等做一个铺垫； 数据分片：讲解 SOFARegistry 中采用的一致性 Hash 算法进行数据分片的缘由以及具体实现方法； 数据同步方案：讲解 SOFARegistry 采用的数据同步方案； DataServer 总体架构 在大部分的服务注册中心系统中，每台服务器都存储着全量的服务注册数据，服务器之间通过一致性协议（paxos、Raft 等）实现数据的复制，或者采用只保障最终一致性的算法，来实现异步数据复制。这样的设计对于一般业务规模的系统来说没有问题，而当应用于有着海量服务的庞大的业务系统来说，就会遇到性能瓶颈。\n为解决这一问题，SOFARegistry 采用了数据分片的方法。全量服务注册数据不再保存在单机里，而是分布于每个节点中，每台服务器保存一定量的服务注册数据，同时进行多副本备份，从理论上实现了服务无限扩容，且实现了高可用，最终达到支撑海量数据的目的。\n在各种数据分片算法中，SOFARegistry 采用了业界主流的一致性 Hash 算法做数据分片，当节点动态扩缩容时，数据仍能均匀分布，维持数据的平衡。\n在数据同步时，没有采用与 Dynamo、Casandra、Tair、Codis、Redis cluster 等项目中类似的预分片机制，而是在 DataServer 内存里以 dataInfoId 为粒度进行操作日志记录，这种实现方式在某种程度上也实现了“预分片”，从而保障了数据同步的有效性。\n图 1 SOFARegistry 总体架构图\nDataServer 启动 启动入口 DataServer 模块的各个 bean 在 JavaConfig 中统一配置，JavaConfig 类为 DataServerBeanConfiguration， 启动入口类为 DataServerInitializer，该类不由 JavaConfig 管理配置，而是继承了 SmartLifecycle 接口，在启动时由 Spring 框架调用其 start 方法。\n该方法中调用了 DataServerBootstrap#start 方法（图 2），用于启动一系列的初始化服务。\n从代码中可以看出，DataServer 服务在启动时，会启动 DataServer、DataSyncServer、HttpServer 三个 bolt 服务。在启动这些 Server 之时，DataServer 注册了一系列 Handler 来处理各类消息。\n图2 DataServerBootstrap 中的 start 方法\n这几个 Server 的作用如下：\n DataServer：数据服务，获取数据的推送，服务上下线通知等； DataSyncServer：数据同步服务； HttpServer：提供一系列 REST 接口，用于 dashboard 管理、数据查询等； 各 Handler 具体作用如图 3 所示：\n图 3 各 Handler 作用\n同时启动了 RaftClient 用于保障 DataServer 节点之间的分布式一致性，启动了各项启动任务，具体内容如图 4 所示：\n图 4 DataServer 各项启动任务\n各个服务的启动监听端口如图 5 所示：\n图5 监听端口\n其他初始化 Bean 除上述的启动服务之外，还有一些 bean 在模块启动时被初始化, 系统初始化时的 bean 都在 DataServerBeanConfiguration 里面通过 JavaConfig 来注册，主要以如下几个配置类体现（配置类会有变更，具体内容可以参照源码实现）：\n DataServerBootstrapConfigConfiguration：该配置类主要作用是提供一些 DataServer 服务启动时基本的 Bean，比如 DataServerConfig 基础配置 Bean、DataNodeStatus 节点状态 Bean、DatumCache 缓存 Bean 等；\n LogTaskConfigConfiguration：该配置类主要用于提供一些日志处理相关的 Bean；\n SessionRemotingConfiguration：该配置类主要作用是提供一些与 SessionServer 相互通信的 Bean，以及连接过程中的一些请求处理 Bean。比如 BoltExchange、JerseyExchange 等用于启动服务的 Bean，还有节点上下线、数据发布等的 Bean，为关键配置类；\n DataServerNotifyBeanConfiguration：该配置类中配置的 Bean 主要用于进行事件通知，如用于处理数据变更的 DataChangeHandler 等；\n DataServerSyncBeanConfiguration：该配置类中配置的 Bean 主要用于数据同步操作；\n DataServerEventBeanConfiguration：该配置类中配置的 Bean 主要用于处理与数据节点相关的事件，如事件中心 EventCenter、数据变化事件中心 DataChangeEventCenter 等；\n DataServerRemotingBeanConfiguration：该配置类中配置的 Bean 主要用于 DataServer 的连接管理；\n ResourceConfiguration：该配置类中配置的 Bean 主要用于提供一些 Rest 接口资源；\n AfterWorkingProcessConfiguration：该配置类中配置一些后处理 Handler Bean，用于处理一些业务逻辑结束后的后处理动作；\n ExecutorConfiguration： …","date":1570690800,"description":" 本文为《剖析 | SOFARegistry 框架》第四篇，作者明不二","dir":"blog/sofa-registry-data-fragmentation-synchronization-scheme/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e4e0cf21756799897553099d37f73100","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","publishdate":"2019-10-10T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心数据分片和同步方案详解 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/","wordcount":5784},{"author":"闫守孟等","categories":"SOFAEnclave","content":" 近日，Linux 基金会宣布全球多家巨头企业成立机密计算联盟（Confidential Computing Consortium），在对于数据安全和隐私担忧的不断增长下，基于可信执行环境技术的机密计算作为一种可行的解决方案，成为互联网巨头关注的焦点。 蚂蚁金服很早就关注此类技术，并基于机密计算打造了蚂蚁金服新一代可信编程中间件 SOFAEnclave，为金融业务保驾护航。 机密计算是蚂蚁安全计算的一环，也是金融级云原生的一块重要版图，蚂蚁金服表示：相信未来机密计算将和 HTTPS 一样，成为云计算的标配。\n 作者 | 闫守孟、肖俊贤、田洪亮 引言 互联网金融本质上是对大量敏感数据的处理以及由此沉淀的关键业务智能。近年来涌现出来的新业态更是将数据处理的范畴从单方数据扩展到了涉及合作方的多方数据。\n另一方面，从 GDPR 到 HIPAA，数据隐私监管保护的范围愈加扩大，力度日益增强。可见，对金融数据和关键业务智能的安全保护，不仅是互联网金融业务的基础，也是其创新发展的依托，更是攸关合规的关键因素。\n近年来迅速发展的机密计算技术是一种创新的数据隔离和加密处理技术，其重要特点是，TCB(trusted computing base 可信计算基) 中仅包含应用自身和基础硬件，即使 OS kernel、Hypervisor、甚至 BIOS 等特权软件都已经遭到破坏甚至本来就是恶意的，敏感数据和代码依然能安全无虞。\n蚂蚁金服在自身的实践过程中，基于机密计算底层技术发展出金融级的机密计算中间件，确保金融应用数据和代码的机密性和完整性，为关键业务提供易用、安全、集群化的计算环境。\n本文从机密计算的技术背景、关键问题、蚂蚁的技术突破、以及典型应用场景等方面展开。\n机密计算的技术背景 随着云计算的快速发展，越来越多的关键性服务和高价值数据被迁移到了云端。云安全也因此成为学术界和工业界关注的一个焦点。\n近年来，云安全领域最重要的一项技术进展名为机密计算（Confidential Computing）。机密计算填补了当前云安全的一项空白——使用中数据（Data-in-use）的加密。过去通行的做法是对数据在存储中（比如硬盘）和传输中（比如网络）加密，而在使用中（比如内存）解密，以便处理。而机密计算可以保护使用中数据的机密性和完整性。\n目前，多家云计算巨头都在不约而同地推广这项技术：微软已于 2017 年 7 月宣布开始接受 Azure 机密计算的早期试用申请；IBM 于 2017 年 12 月宣布 IBM 云数据保护（Cloud Data Guard）的预览版；谷歌也于 2018 年 5 月开源了名为 Asylo 的机密计算框架。\n那么，机密计算究竟是如何实现的呢？\n实际上，上述所有云计算巨头在实现机密计算时都离不开一种称为“可信执行环境（TEE）”的技术。\n顾名思义，TEE 提供一种与不可信环境隔离的安全计算环境，正是这种隔离和可信验证机制使得机密计算成为可能。\nTEE 一般是直接基于硬件实现的，比如 Intel SGX，AMD SEV，ARM TrustZone，以及 RISC-V Keystone 等；基于虚拟化技术也可以构造 TEE，比如微软的 VSM，Intel 的 Trusty for iKGT \u0026amp;amp; ACRN，但尚不能匹敌硬件 TEE 的安全性。\n其中，Intel 软件防护拓展（Software Guard Extensions，简称 SGX）是目前商用 CPU 中最为先进的 TEE 实现，它提供了一套新的指令集使得用户可以定义称为 Enclave 的安全内存区域。CPU 保证 Enclave 与外界隔离，从而保护其中的代码和数据的机密性、完整性和可验证性。不同于之前的 TEE 实现，比如 ARM TrustZone，SGX 每个 APP 都可以有自己独立的 TEE，甚至可以创建多个 TEE，而 TrustZone 是整个系统有一个 TEE；这里也省去了向设备厂商申请将 TA 装入 TEE 的过程。由于 SGX 的先进性，目前云端机密计算领域甚至已公认用 Enclave 这个词来指代 TEE。\n典型 TEE 安全特性和使用流程 [1]\n典型的 Enclave 达到的安全目标可以用 CIA 概括，即机密性（Confidentiality）、完整性（Integrity）和真实性（Authenticity）。在实现上具有以下基本要求：\n1) Enclave 内存保护\nEnclave 内存只有 Enclave 本身的代码可以访问。CPU 通过内存隔离和加密来防止对安全内存的软件攻击和硬件嗅探。SGX 更通过内存控制器的 integrity tree 防止了对 Enclave 内存的物理篡改。\n2) Enclave 的可信验证\nCPU 支持对 Enclave 中数据和代码的测量，以及对 Enclave 合法性的本地或远程验证。有了测量和验证，本地的 Enclave 之间、客户端与远程 Enclave 之间，就可以认证身份，进而建立安全的通信信道。\n如何开发受 Enclave 保护的应用程序呢？\n以 SGX 为例，其中一种方法是利用 Intel SGX SDK。如下图所示，基于 SGX SDK 的应用程序分为两部分：Enclave 外的不可信组件（左边黄色部分）和 Enclave 内的可信组件（右边绿色部分）。两边可以通过跨 Enclave 的函数调用通信：不可信组件可以通过 ECall 调用可信组件中定义的函数；反之，可信组件也可以通过 OCall 调用不可信组件中定义的函数。\nEnclave 编程模型 [2]\n机密计算面临的关键问题 Enclave 给我们带来了前文所谓 CIA 的安全保障，但是目前面临较大的易用性问题。主要体现在几个方面。\n第一，需要将原有应用分割成两部分，一部分是 enclave 外的 untrusted 部分，一部分在 enclave 里面作为 trusted 部分；\n第二，需要精心设计两部分之间的接口，规划好什么时候进入 Enclave，什么时候退出 Enclave——这存在一定技术门槛，而且比较繁琐容易出错；\n第三，即使我们做了完美的分割， Enclave 里面的环境相对于我们熟悉的通常的 Linux 运行环境来说是非常受限的。例如，enclave 里面不能进行系统调用，libc、pthread 不完整，没有 openmp，多进程支持欠缺等等。\n可见，把应用移植到 Enclave 里面是极具挑战的，在某些时候甚至是不可能做到的。而且，由于开发过程中必须考虑业务无关的繁杂琐细的方面，即使最终能完成应用开发移植目标，也会导致低下的开发效率，极高的开发成本，这对于快节奏的互联网业务来说是难以接受的。\n机密计算走向工程实用面临的另一较大问题是，如何将机密计算从单节点向集群扩展。由于缺乏标准的做法，或者没有一个 best practice 作为参考，很多时候各个业务不得不各自从头造轮子，搭建跟业务逻辑过度耦合的 Enclave 集群基础设施。从而导致低下的开发效率和重复的资源投入。\n另一方面，互联网业务日趋云原生化， …","date":1570258800,"description":"基于机密计算打造的新一代可信编程中间件。","dir":"blog/sofa-enclave-confidential-computing/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f994d83c7c4b263b08e4d2fd22a461b4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-enclave-confidential-computing/","publishdate":"2019-10-05T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-enclave-confidential-computing/","summary":"近日，Linux 基金会宣布全球多家巨头企业成立机密计算联盟（Confidential Computing Consortium），在对于数据安全和隐私担忧的不断","tags":["SOFAEnclave"],"title":"SOFAEnclave：蚂蚁金服新一代可信编程环境，让机密计算为金融业务保驾护航102年","type":"blog","url":"/sofastack.tech/blog/sofa-enclave-confidential-computing/","wordcount":6249},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\nSOFALab 系列文章 十一特刊带来 SOFALab 系列源码解析文章集合~\nSOFA:RPCLab/ 系列文章 【剖析 | SOFARPC 框架】系列之总体设计与扩展机制 【剖析 | SOFARPC 框架】系列之链路追踪剖析 【剖析 | SOFARPC 框架】系列之连接管理与心跳剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 同步异步实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 线程模型剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 单机故障剔除剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 泛化调用实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 数据透传剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 优雅关闭剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 路由实现剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 跨语言支持剖析 【剖析 | SOFARPC 框架】系列之 SOFARPC 序列化比较 SOFA:BoltLab/ 系列文章 蚂蚁金服通信框架SOFABolt解析 | 编解码机制 蚂蚁金服通信框架SOFABolt解析 | 序列化机制(Serializer) 蚂蚁金服通信框架SOFABolt解析 | 协议框架解析 蚂蚁金服通信框架SOFABolt解析 | 连接管理剖析 蚂蚁金服通信框架SOFABolt解析 | 超时控制机制及心跳机制 SOFA:TracerLab/ 系列文章 蚂蚁金服分布式链路跟踪组件 SOFATracer 总览 | 剖析 蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码分析 | 剖析 蚂蚁金服分布式链路跟踪组件链路透传原理与SLF4J MDC的扩展能力分析 | 剖析 蚂蚁金服分布式链路跟踪组件采样策略和源码 | 剖析 蚂蚁金服分布式链路跟踪组件埋点机制 | 剖析 SOFA:JRaftLab/ 系列文章 SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFARPC v5.5.8，主要变更如下：\n 优化 log4j2 日志异步化 修复故障剔除模块的事件接收问题 修复 tracelog 日志 local 地址打印不正确的问题 优化泛化调用的方法名显示 修复特殊场景下的泛化调用超时设置 详细发布报告：https://github.com/sofastack/sofa-rpc/releases/tag/v5.5.8\n","date":1570172400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20191004/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"81a2a8115038fb193b50618c4d845bf4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191004/","publishdate":"2019-10-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20191004/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/30 - 10/4】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20191004/","wordcount":1056},{"author":"SQLFlow","categories":"SQLFlow","content":" 2018 年 1 月，Oracle 的官方博客上发表了一篇文章，标题是“It\u0026amp;rsquo;s Pervasive：AI Is Everywhere”。作为全球最著名的商业数据库系统提供商，Oracle 在这篇文章里历数了 AI 在企业信息系统中的发展空间。在面向最终用户的互联网行业，巨头们招募 AI 专家，用 Python 和 C++ 打造服务大众的特定 AI 能力——搜索、推荐、以及精准定向的互联网广告系统。在企业业务中，使用 SQL 的分析师是大多数。\n滴滴首席数据科学家谢梁（左）与蚂蚁金服研究员王益开启共建SQLFlow之旅\n2019 年 7 月，滴滴的数据科学（Data Science）团队的几名数据科学家在北京新澄海大厦见到了来自蚂蚁金服的几位工程师。在那之前两个月，蚂蚁金服从事 AI 基础架构研发的王益团队开源了一款机器学习工具 SQLFLow，将 SQL 程序翻译成 Python 程序，调用数据库和 AI 引擎，实现端到端的 AI。滴滴首席数据科学家谢梁敏锐地关注到这个项目。这次拜访双方一拍即合，开启了共建 SQLFlow 之旅。\n用 SQLFlow 构建 AI 的训练和预测任务\n数据分析师的普适 AI  数据驱动决策是很多公司的追求，在国内很多业务人员都了解 SQL，但是对于 AI、深度学习模型的训练，需要长时间系统性的学习，有一定的门槛。SQLFLow 的出现让包括数据分析师在内的业务人员通过写简单的 SQL 去调用 AI 模型成为了可能。滴滴数据科学团队长期地直面一线业务，了解业务需求，也沉淀了很多常用模型。本次合作双方希望优势互补共同助力 AI 的落地，据悉合作分为三步，第一步滴滴为蚂蚁金服贡献更多针对于业务产品的理解和洞见；第二步滴滴将公司自身业务场景最有价值用的最好的模型贡献到 SQLFLow；第三步滴滴加入到建设到整个 SQLFLow 开源社区的建设，双方要在模型、社区、文化等全方位共建。\nSQLFlow的技术架构\n一个多月的时间，滴滴已经为 SQLFLow 贡献了基于 DNN 分类预测模型、可解释模型和无监督聚类模型三个高价值模型。这三个模型覆盖的场景非常广泛，对于滴滴内部来说，包括网约车、单车、金融等在内的诸多业务场景都可应用起来，于外部而言，“因为整个模型它是一种基础能力，其实它不会局限于某一个公司或某一个行业，它具有普适性。”滴滴高级数据科学家高梓尧强调。\nSQLFlow 和滴滴数据的整合逻辑\n比如分类预测模型，适用于做产品增长的场景，对特定人群进行定向推荐。而无监督聚类模型，也就是模式识别，在滴滴的产品的应用非常广，比如会根据司机出车时长分布，去整合归纳司机出车的偏好，更好地为司机提供调度建议，进而帮助缓解出行供需。\n滴滴首席数据科学家谢梁认为在共建 SQLFlow 过程中，充分体现了算法和数据科学在对数据的理解和应用上的两个不同，以及双方优势互补形成 1+1 大于 2 的合力效果。因为对于传统的算法来讲主要强调对于预测一个给定事件的预测精准性。但是数据科学在预测精准性之上，还强调预测的可解释性。实际上在更广泛的商业层面上，比如运营、营销等更需要了解为什么会这这样发生，这对于业务战略制定、营销方案的确定，以及整个产品序列的设计都有非常大的帮助。\n滴滴数据科学团队在过去不到两个月的共建工作中显著扩大了 SQLFlow 的应用场景。根据蚂蚁金服 SQLFlow 项目的产品负责人刘勇峰介绍，滴滴的同事们建议并且参与研发了 SQLFlow 对接 XGBoost 的功能，从而在深度学习模型之外支持树模型；以及对接 unsupervised learning 的能力，支持聚类分析。此外，SQLFlow 基于 SHAP 支持了深度学习模型和树模型的图示化解释。SQLFlow 也支持了滴滴常用的 Hive 数据库系统。\n基于 XGBoost 的汽车价格预测模型（数据来自 Kaggle）的 SHAP 解释图（注：SHAP 值表征了每个特征对模型输出的影响，如图中，较小的 engine_hp“引擎马力”值会降低汽车的预测价格）\n“我们是希望通过 SQLFlow 真正能够把数据驱动业务、科学决策的思想，能够在中国传播得更好更远，也希望就是能够通过我们自己的努力，真正让 AI 模型能力大众化和普及化，然后使得我们整个国内的数据分析的科学性、合理性和洞察性，能够逐步提升，甚至达到国际领先。”高梓尧说。\n而所有参与项目的同事们对 SQLFlow 的未来都有更大的期待，这是对于开源社区作为一种高效率的工作模式的信任。\n打造一个 SQL 花园生态 在强调数据驱动的滴滴其实一直积极参与到开源建设中，截至目前，滴滴和蚂蚁金服分别开源了数十个项目。SQLFlow 是双方开源共建的首秀。\n对于双方仅一个多月的时间就能够共建三个高价值的模型，谢梁认为很重要的原因是 SQLFlow 已经给滴滴搭建好了底层能力，滴滴相当于做了一个交通领域的几个核心插件，并且通过滴滴插件能力，对整个 SQLFlow 覆盖面和深度方面的底层能力进行了验证和提升，“那么再把这个基础打好之后，我们就相当于造了一个大的花园，我们把土都铺好了，需要什么营养的土，要种什么类型的花，都给他做好了，之后就需要有更多的农民伯伯一起来种田，他们要去种向日葵，我们毕竟精力有限可能就是以种小麦和种主粮为主，更多的经济作物就需要其他开源社区的同学一起来贡献。”\n在整个 SQLFlow 开源社区建设方面双方都有更大的愿景，滴滴的分析团队总结的很多模型在 BI 领域具备普适性，而 SQLFlow 在蚂蚁的场景使用模型在金融领域颇有普适性，未来要让更多的人去用上普适的 AI 能力，在 SQLFlow 社区之上会形成一个开源货架式的交易市场，更多懂业务的人把更多商业场景抽象成模型打造成模型库，模型库是 SQLFlow 生态中的重要一环，双方正在讨论如何共建。“你就像走进一个超市，里面有 10万个 SQL，每一个 SQL 就是一个实现了你商业逻辑的模型，你就拿来用就行了，这是终极的一个目标”，谢梁兴奋地谈到。\n当然现在的 SQLFlow 还是一个非常年轻的开源项目，需要更多的呵护。虽然目前在开源合作方面中国相比美国还有不少差距，但正是因为越来越多的公司和个人去投身其中为之贡献，差距正在缩小。实际上，几乎所有的 SQLFlow 项目成员都是利用业余时间参与到开源项目中。比如滴滴资深算法工程师陈祥，他平时负责数据治理和应用方向上数据、应用与算法的结合和落地, 在 8 月初听到 SQLFlow 项目就决定参与进来，未来他也会号召很多的人参与到开源建设中。\n“开源社区所说的构建大生态，其实大生态还包含着另外一层，就是大家互相学习，然后行业内的所有从业人员进行知识交流。所以当各行各业的同学都在里面贡献自己的经验、技能时，我们其实也能从其他的同学那学习到很多处理数据，或者解决实际问题的方法。”高梓尧所言恰如其分地诠释了开源社区众人拾柴火焰高的魅力。\nGartner 预测“到 2020 年，AI 技术将普遍出现在几乎每一个新的软件产品和服务中。”这其中有蚂蚁金服与滴滴 DS 团队的一份力。\n项目地址 欢迎感兴趣的同学加入社区讨论： 项目官 …","date":1569740400,"description":"让AI 像 SQL 查询一样简单。","dir":"blog/sqlflow-ai-didi-antfin-open-source-construction/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d8e2fdbfc1d48f984a2adf17474cb983","permalink":"https://sofastack.github.io/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","publishdate":"2019-09-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","summary":"2018 年 1 月，Oracle 的官方博客上发表了一篇文章，标题是“It\u0026rsquo;s Pervasive：AI Is Everywhere”。作为全球最著","tags":["SQLFlow"],"title":"让 AI 无处不在：滴滴与蚂蚁金服开源共建 SQLFlow","type":"blog","url":"/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/","wordcount":2732},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、关于 SOFAJRaft 的提问：\n@LoFi 提问：\n 关于 SOFAJRaft，请教几个问题：不管 raft log 是并行，batch 还是 pipeline 复制，都是为了提高 throughput，但对 latency 没有好处，因为最终日志必须要顺序 commit 和顺序 Apply ，这是 Raft 论文的要求。但是在某些简单的 KV 场景，上层业务可以根据需求去乱序 commit 和 Apply 么？这样可以降低 latency 。\n A：pipeline 对 latency 会有一些好处，总体上讲 batch 对吞吐有好处，SOFAJRaft 里的 batch 设计也不会对 latency 有坏处，所以它还是好的，乱序 apply 理论上影响一致性。\n 如果 raft log commit 成功，但是 apply 失败，系统目前的处理方式是什么？直接 crash?\n A：apply 异常失败会阻塞住状态机，只有重启才可能恢复，为了保证一致性。\n 如果 leader 本地磁盘 error 或者本地 log flush 失败, 但收到了多数派的响应，日志会 commit 么？怎么处理这种情况？\n A：你说的这种异常状态机就挂掉了，原因同上一条。\n关于扩容：\n 扩容时，新节点的角色不能为 follow 吧？会影响 ballot，不应该先增加一个 Follow 角色，等 snapshot 加载成功后再变为 follow 么？\n A：新加节点首先要求日志追上才行，你说的这个不存在。\n 扩容时，如果是 follow 的话，根据论文就会影响 leader 的投票吧\n A：那首先得你说的这个 follower 在这个组里呀。首先要追上数据，才能变更配置，这个节点才会进入 group，另外再退一步，没有最新日志的 follower 也无法影响投票。SOFAJRaft 比 Raft 论文里面多了一个 preVote。\n 明白，就是先追上数据，然后才能再走一遍 addpeer raftlog ?\n A：不是额，是 addPeer 的流程里第一步就是要先追数据。\n 你的意思是：当新的节点加入集群时，会先追日志 , 然后再把这个节点加入到 raft goup 中，成为投票中的一员 是么？ 也就是说在追日志的过程中，这个新的节点是不会参与 raft log 的投票么？那如果说我只是为一个 raft goup 增加副本数，比如从 3 副本变成 4 副本时，这个时候是怎么处理的呢？反正就是不管哪种情况，都是先追数据，然后再加入到 Goup 里？\n A：新加的 follower 一启动，就会 electiontimeout 发起选举，但是不会成功，然后 leader 会为这个节点新起一个 replicator 开始复制数据日志（通常包含 snapshot），等到数据追上后，leader 会再提交一条配置变更日志，此时这个节点就正式加入到 group 了。\n2、关于 Seata 的提问：\n@姜伟锋 提问：\n 最近在看 Seata 的源码，发现 rpc 相关的 Request、Response 网络传输对象太多了，在保证扩展性的基础上是不是可以优化下，因为主要参数也就是事务组 id、事务组 status、分支事务 id、分支事务 status，再加上附加信息字段，感觉这块设计还有相关序列化设计有点复杂了，这样设计的目的是什么呢，求大佬解。\n A：是指字段冗余还是指外层的包装协议复杂了？\n rpc 传输对象感觉有点冗余，一些 request response 对象是不是可以合并，主要字段应该是固定的，这样设计的目的扩展性是很好，复用性是不是还有优化空间呢？\n A： 这里是按照非事务消息（注册鉴权之类）和事务消息，事务消息又按照 RM，TM 角色以及传输的方向做了分类，你说的冗余能举个栗子嘛？\n 看到是按角色定义的 rpc req，res 传输对象，这些词传输对象中主要的字段是全库事务 id，全库事务状态，分支事务 id，分支事务状态，资源 id，还有一些附加字段，TM、TC、RM 交互时为什么不设计成一个 req res 对象公用或者是否可以在现有框架上提高下复用性，个人是觉得这块设计了好多传输对象，每个对象有对应的序列化和反序列化，有点复杂，这样设计扩展性这个点我明白，复用性不是太好，还有其他考虑吗？\n A：每个消息都有一个名称（code），消息名对于整个事务的链路流程上理解比较清晰，结合着我们的事务流程图来看，每个阶段的 rpc 都有一个确切的含义，即使从字段上来说是相同的比如GlobalRollbackRequest，GlobalCommitRequest 从名称上来看不一样，但从传输层面来看除了code 不一样其他的是一样的。但是大部分消息的字段还是不一样的，对于这种通用字段比如 xid begin 消息就是空的，设计成通用这里只能是 null，非通用比如 lockkey 那这里如果使用通用消息就可能直接塞到一个 applicationData 的扩展字段里，这种写法我觉得不确切，同时有增加了我私有协议序列化时不必要的长度标识字段，每条消息都是由确切的所需的字段，宁愿复杂一些，也要从设计上更清晰些。\nSeata：https://github.com/seata/seata\nSOFAJRaft 解析文章全系列 《剖析 | SOFAJRaft 实现原理》系列文章完结啦，感谢 SOFAStack 社区的核心贡献者们的编写，也欢迎更多感兴趣的技术同学加入。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft …","date":1569567600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190927/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d1709ae51d5099a6263d7269a435e264","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190927/","publishdate":"2019-09-27T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190927/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/23 - 9/27】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190927/","wordcount":2458},{"author":"胡宗棠","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》最后一篇，本篇作者胡宗棠，来自中国移动。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文末包含往期系列文章。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n导读 本文主要介绍 SOFAJRaft 在日志复制和管理中所采用的快照机制。考虑到单独介绍 SOFAJRaft 中的快照机制原理和实现或许有一些唐突，我会先通过一个读者都能够看得明白的例子作为切入点，让大家对快照这个概念、它可以解决的主要问题，先有一个比较深刻的理解。\n一、快照的概念与特点 SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法，就不可避免的要对需要达成共识的内容，在多个服务器节点之间进行传输，一般将这些共识的内容称之为日志块（LogEntry）。如果读过《剖析 | SOFAJRaft 实现原理》系列前面几篇文章的同学，应该了解到在 SOFAJRaft 中，可以通过“节点之间并发复制日志”、“批量化复制日志”和“复制日志pipeline机制”等优化手段来保证服务器节点之间日志复制效率达到最大化。\n但如果遇到下面的两个场景，仅依靠上面的优化方法并不能有效地根本解决问题：\n 当对某个 SOFAJRaft Group 集群以新增节点方式来扩容，新节点需要从当前的 Leader 中获取所有的日志并重放到本身的状态机中，这对 Leader 和网络带宽都会带来不小的开销，还有其他方法可以优化或解决这个问题么？ 因为服务器节点需要存储的日志不断增加，但是磁盘空间有限，除了对磁盘卷大小扩容外，还有其他方式来解决么？ 带着上面两个疑问，我们可以先来看一个大家日常生活中都会遇到的场景—重新安装操作系统，然后再通俗易懂地为大家介绍快照的概念与特点。\n有一天，你的笔记本电脑的 Windows 操作系统因为某一些原因出现启动后多次崩溃问题，不管通过任何方式都没办法解决。这时候，我们想到解决问题的第一个方案就是为这台电脑重新安装操作系统。如果，我们平时偶尔为自己电脑的操作系统做过镜像，直接用之前的镜像文件即可快速还原系统至之前的某一时间点的状态，而无需从零开始安装 Windows 操作系统后，再花大量时间来重新安装一些自己所需要的系统软件（比如 Chrome 浏览器、印象笔记和 FoxMail 邮件客户端等）。\n在上面的例子中，电脑操作系统的镜像就是系统某一时刻的“快照”，因为它包含了这一时刻，系统当前状态机的值（对于用户来说，就是安装了哪些的应用软件）。在需要重新安装操作系统时候，通过镜像这一“快照”，可以很高效地完成还原电脑操作系统这个任务，而无需从零开始安装系统和相应的应用软件。所以，我们这里可以为“快照”下一个简单的定义：一种通过某种数据格式文件来保存系统当前的状态值的一个副本。\n“快照”的特点，就如同它字面意思一样，可以分为“快”和“照”：\n “快”：高效快捷，通过快照可以很方便的将系统还原至某一时刻的状态； “照”：通过快照机制是保存系统某一时刻的状态值； 二、SOFAJRaft 的 Snapshot 机制 2.1 SOFAJRaft Snapshot 机制的原理 读到这里，再去回顾第一节内容开头提出的两个问题，大家应该可以想到解决问题的方法就是通过引入快照机制。\n1. 解决日志复制与节点扩容的瓶颈问题 在 SOFAJRaft 中，Snapshot 为当前 Raft 节点状态机的最新状态打了一个“镜像”单独保存，保存成功后在这个时刻之前的日志即可删除，减少了日志文件在磁盘中的占用空间。而在 Raft 节点启动时，可以直接加载最新的 Snapshot 镜像，直接重放在此之后的日志文件即可。如果设置保存 Snapshot 的时间间隔比较合理，那么节点加载镜像后重放的日志文件较少，启动速度也会比较快。对于新 Raft 节点加入某个 SOFAJRaft Group 集群的场景，新节点可先从 Leader 节点上拷贝最新的 Snapshot 安装到本地状态机，然后拷贝后续的日志数据即可，这样可以在快速跟上整个 SOFAJRaft Group 集群进度的同时，又不会占用 Leader 节点较大的网络带宽资源。\n2. 解决 Raft 节点故障恢复中的时效问题 在一个正常运行的 SOFAJRaft Group 集群中，当其中某一个 Raft 节点出现故障了（假设该故障的原因不是由磁盘损坏等不可逆因素导致的），该 Raft 节点修复故障重新启动时，如果节点禁用 Snapshot 快照机制，那么会重放所有本地的日志到状态机以跟上最新的日志，这样节点启动和达到日志备份完整的耗时均会比较长。但是，如果此时节点开启了 Snapshot 快照机制，那么一切就会变得非常高效，节点只需要加载最新的 Snapshot 至状态机，然后以 Snapshot 数据的日志为起点开始继续回放日志至状态机，直到使得状态机达到最新状态。\n图1 在 Snapshot 禁用情况下集群节点扩容\n图2 在 Snapshot 启用情况下集群节点扩容\n从上面两张 SOFAJRaft 集群的结构图上，可以很明显地看出在开启和禁用 Snapshot 时，扩容的新 Raft 节点需要从 Leader 节点传输过来不同的日志数量。在禁用 Snapshot 情况下，新 Raft 节点需要把 Leade 节点内从起始的 T1 时刻至当前 T3 时刻这一时间范围内的所有日志都重新传至本地后提交给状态机。而在开启 Snapshot 情况下，新 Raft 节点则无需像 图1 中那么逐条复制 T1~T3 时刻内的所有日志，而只需先从 Leader 节点加载最新的镜像文件 Snapshot_Index_File 至本地，然后仅复制 T3 时刻以后的日志至本地并提交状态机即可。\n在这里可能有同学会有疑问：“在 图 1 中，从 Leader 节点传给新扩容的 Raft 节点的数据是 T1~T3 的日志，而 图2 中取而代之的是 Snapshot_Index_File 快照镜像文件，似乎还是不可避免额外的数据传输么？”仔细看下图 2，会发现其中 Snapshot_Index_File 快照镜像文件是对 T1~T3 时刻内日志数据指令的合并（包括数集合[Add 1,Add 6,Add 4,Sub 3,Sub 4,Add 3]），也即为最终的数据状态值。\n2.2 SOFAJRaft Snapshot 机制的实践应用 如果用户需开启 SOFAJRaft 的 Snapshot 机制，则需要在其客户端中设置配置参数类 NodeOptions …","date":1569232800,"description":"本文为《剖析 | SOFAJRaft 实现原理》最后一篇，本篇作者胡宗棠。","dir":"blog/sofa-jraft-snapshot-principle-analysis/","fuzzywordcount":4500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"39ff132d4c11bccb0059665f6e9c4b31","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","publishdate":"2019-09-23T18:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft Snapshot 原理剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/","wordcount":4407},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题 通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@wy223170 提问：\n 你好，请问下 SOFAJRaft 如何在虚拟化环境下使用，比如部署三个实例，三个实例都是 docker 的。因为虚拟化实例可能漂移，怎么保证 snapshot 的迁移呢？另外怎么控制多个实例的同时漂移，导致集群不可用的问题？\n A：SOFAJRaft 本身是有状态的，你说的实例漂移就可以理解为这个节点挂掉并新拉起了一个节点，我们内部的做法是通过一个 manager 节点监听容器上下线并执行 CliService removePeer 和 addPeer，利用 raft 协议本身的能力达到数据迁移的目的，但是对于半数以上节点同时漂移是无解的，可能出现丢数据的情况。这是 etcd 的一个解决类似问题的方式，供参考：https://github.com/coreos/etcd-operator\n 感谢回答，是不是只要 manager 节点监听到容器变化就会立刻进行 removePeer 或 addPeer，需不需等待容器已经达到某种状态，比如迁移完 snapshot 等才进行 addPeer 之类的，这可能就需要实例迁移后完成一个打标记的功能标志迁移完成了。\n A：流程是先 addPeer 成功以后再 removePeer。其中 addPeer 在追数据成功后才会返回成功。看到你多次强调 snapshot，其实这里你不用关注 snapshot，这是 SOFAJRaft 内部会考虑的 raft 层的东西，不需要额外做特殊处理。\n开源项目 ElasticDL：蚂蚁金服开源基于 TensorFlow 的弹性分布式深度学习系统 蚂蚁金服开源机器学习工具 SQLFlow，技术架构独家解读 SOFA 项目进展 本周发布详情如下：\n发布 Seata v0.8.1，主要变更如下：\n 支持配置文件使用绝对路径 支持 DataSource 的自动代理 支持通信协议的 kryo 编解码 修复 file 存储模式的 selectForUpdate lockQuery exception 修复数据库连接使用后的 autocommit 问题 优化 etcd3 中 watcher 订阅的效率 优化当数据表无索引时抛出显式异常 详细发布报告： https://github.com/seata/seata/releases/tag/v0.8.1\nSOFAJRaftLab 系列阅读 SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 ","date":1568962800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190920/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4519012918ba68bf9e39b0daed78cfc4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190920/","publishdate":"2019-09-20T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190920/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/16 - 9/20】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190920/","wordcount":1043},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第七篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文末包含往期系列文章。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 在分布式部署、高并发、多线程场景下，我们经常会遇到资源的互斥访问的问题，最有效、最普遍的方法是给共享资源或者对共享资源的操作加一把锁。在 JDK 中我们可以使用 ReentrantLock 重入锁或者 synchronized 关键字达成资源互斥访问目的，但是由于分布式系统的分布性（即多线程和多进程并且分布在不同机器中），使得两种锁失去原有锁的效果，需要用户自定义来实现分布式锁。\n本文重点围绕分布式锁概览、实现方式以及基于 SOFAJRaft 实现等方面剖析 SOFAJRaft-RheaKV 基于 SOFAJRaft 实现分布式锁原理，阐述如何使用 SOFAJRaft 组件提供分布式锁服务功能：\n 什么是分布式锁？分布式锁具备哪些条件？分布式锁有哪些实现方式？ RheaKV 基于 SOFAJRaft 如何实现分布式锁？解决分布式锁哪些问题？ 分布式锁 分布式锁是控制分布式系统之间同步访问共享资源的一种方式，用于在分布式系统中协调他们之间的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下便需要使用到分布式锁。分布式锁通过共享标识确定其唯一性，对共享标识进行修改时能够保证原子性和对锁服务调用方的可见性。\n分布式锁概览 Martin Kleppmann 是英国剑桥大学的分布式系统研究员，之前和 Redis 之父 Antirez 关于 RedLock 红锁是否安全的问题激烈讨论过。Martin 认为一般我们使用分布式锁有两个场景：\n 效率：使用分布式锁能够避免不同节点重复相同的工作导致浪费资源，譬如用户付款之后有可能不同节点发出多条短信； 正确性：添加分布式锁同样避免破坏正确性事件的发生，如果两个节点在同一条数据上面操作，譬如多个节点机器对同一个订单操作不同的流程有可能导致该笔订单最后状态出现错误造成资金损失； 分布式锁需要具备的条件包括：\n 获取锁和释放锁的性能要好； 判断获得锁是否是原子性的，否则可能导致多个请求都能获取到锁； 网络中断或者宕机无法释放锁时，锁必须被清除； 可重入一个线程中多次获取同一把锁，譬如一个线程在执行带锁的方法，该方法调用另一个需要相同锁的方法，则该线程直接执行调用的方法，而无需重新获得锁； 阻塞锁和非阻塞锁，阻塞锁即没有获取到锁，则继续等待获取锁；非阻塞锁即没有获取到锁，不继续等待直接返回获取锁失败； 分布式锁实现 分布式 CAP 理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance），最多只能同时满足两项。”，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。在很多场景中为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候需要保证一个方法在同一时间内只能被同一个线程执行。 分布式锁一般有三种实现方式：\n 基于数据库实现分布式锁； 基于缓存（Redis，Memcached，Tair）实现分布式锁； 基于 ZooKeeper 实现分布式锁； 基于数据库实现分布式锁 基于数据库实现分布式锁的核心思想：在数据库中创建一张表，表里包含方法名等字段，并且在方法名字段上面创建唯一索引，执行某个方法需要使用此方法名向表中插入数据，成功插入则获取锁，执行结束则删除对应的行数据释放锁。\n基于缓存实现分布式锁 基于缓存通常选用 Redis 实现分布式锁，考虑到 Redis 有非常高的性能，Redis 命令对分布式锁支持友好，并且实现方便。基于单 Redis 节点的分布式锁在 Failover 的时候产生解决不了的安全性问题，Redlock 是 Redis 的作者 Antirez 提出的集群模式 Redis 分布式锁，基于 N 个完全独立的 Redis 节点（通常情况下 N 可以设置成5），运行 Redlock 算法依次执行下面各个步骤完成获取锁的操作\n 获取当前时间（毫秒数）； 按顺序依次向 N 个 Redis 节点执行获取锁的操作。此获取操作包含随机字符串 my_random_value，也包含过期时间(比如 PX 30000，即锁的有效时间)。为了保证在某个 Redis 节点不可用的时候算法能够继续运行，获取锁的操作还有超时时间(time out)，它要远小于锁的有效时间（几十毫秒量级）。客户端在向某个 Redis 节点获取锁失败以后应该立即尝试下一个Redis 节点。这里的失败包含任何类型的失败，比如该 Redis 节点不可用，或者该 Redis 节点上的锁已经被其它客户端持有（注：Redlock 原文中这里只提及 Redis 节点不可用的情况，但也应该包含其它的失败情况）； 计算整个获取锁的过程总共消耗了多长时间，计算方法是用当前时间减去第1步记录的时间。如果客户端从大多数 Redis 节点（\u0026amp;gt;= N/2+1）成功获取到了锁，并且获取锁总共消耗的时间没有超过锁的有效时间（lock validity time），那么这时客户端才认为最终获取锁成功；否则认为最终获取锁失败； 如果最终获取锁成功了，那么此锁的有效时间应该重新计算，它等于最初锁的有效时间减去第3步计算出来的获取锁消耗的时间； 如果最终获取锁失败（可能由于获取到锁的 Redis 节点个数少于 N/2+1，或者整个获取锁的过程消耗的时间超过了锁的最初有效时间），那么客户端立即向所有 Redis 节点发起释放锁的操作； 基于 ZooKeeper 实现分布式锁 ZooKeeper 是以 Paxos 算法为基础的分布式应用程序协调服务，为分布式应用提供一致性服务的开源组件，其内部是分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于 ZooKeeper 实现分布式锁步骤包括：\n 创建一个锁目录 lock； 希望获得锁的线程 A 在 lock 目录下创建临时顺序节点； 当前线程获取锁目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在表示当前线程顺序号最小，获得锁； 线程 B 获取所有节点，判断自己不是最 …","date":1568721600,"description":"本文为《剖析 | SOFAJRaft 实现原理》第七篇，本篇作者米麒麟。","dir":"blog/sofa-jraft--rheakv-distributedLock/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"be578aa3941f24a603a7053e7c7e1107","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","publishdate":"2019-09-17T20:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","剖析 | SOFAJRaft 实现原理","SOFALab"],"title":"SOFAJRaft-RheaKV 分布式锁实现剖析　| SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/","wordcount":6176},{"author":"Oschina","categories":"ElasticDL","content":" 9 月 11 日，蚂蚁金服在2019谷歌开发者大会上海站上开源了 ElasticDL 项目，这是业界首个基于 TensorFlow 实现弹性深度学习的开源系统。\n开源地址为：https://github.com/sql-machine-learning/elasticdl/\n开源中国采访了 ElasticDL 项目负责人王益，对该深度学习系统的技术细节进行了全面介绍。\n基于 TensorFlow 2.0 和 Kubernetes实现弹性深度学习 这个基于 Eager Execution 模式的开源项目名为“ElasticDL”，它是一个Kubernetes 原生深度学习框架，根据介绍，ElasticDL 主要有四大特点：\n 容错性 弹性调度 易用性 高效 其中又以容错与弹性调度特性最具特色。\nElasticDL 实现了容错和弹性调度的分布式深度学习，可以极大提升集群的总体利用率，同时显著减少用户提交作业之后等待作业启动的时间（pending time）。\n王益介绍：“ElasticDL 是我们知道的第一个基于 TensorFlow 实现弹性深度学习的开源系统。具体地说，ElasticDL 是基于 TensorFlow 2.0 和 Kubernetes 实现弹性深度学习的。”\n集群效用从 1/N 到 N/N 在深度学习技术研发的早期，公用一个计算集群的人相对少， 计算作业之间的协调可以通过口头交流实现。开发者更关心缩短运行时间，也就是从作业启动到结束的这段时间。高性能计算技术（HPC）是解决这个问题的有效途径，比如 NVIDIA 的 cuBLAS 和 cuDNN 优化高性能数学计算、NCCL 优化 GPU 之间的通信效率。\n随着深度学习技术的大规模应用，在许多工程师和研究员公用一个集群的情况下，通过商量来协调调度显然不可行，于是大家开始使用集群管理系统调度分布式作业。\nKubernetes 近年来已经逐渐成为集群管理的重要工具，目前已经在各大公有云中广泛采用。因此，让 TensorFlow 能更好地运行在 Kubernetes 集群上，同时提升利用集群进行深度学习的效率和资源利用率（效用），显得非常具有实际意义。\n关于提升集群资源利用率，王益举了一个比较极端的例子：假设一个集群有 N 个 GPU，而一个任务只使用其中一个，现在有一个任务占用了一个 GPU。当没有弹性调度机制时，一个要求所有 N 个 GPU 的任务需要等待前一个任务结束才能开始，这个等待时间可能高达数天甚至数周，在等待期间，集群的效用是 1/N；而拥有弹性调度能力之后，新的任务可以在 N-1 个 GPU 上立即运行，并且 Kubernetes 可以在第一个任务完成后将占用的 GPU 赋予这个任务，这种情况下，集群整体效用是 100%。\nElasticDL 在容错与弹性调度上都有不错的表现，它的现实意义便是高效解决集群效用问题。\nElasticDL 如何实现？ 前边讲到集群资源利用率提高的前提其实就是ElasticDL 的“弹性调度”特性带来的，而弹性调度依赖于容错能力。\n容错是指作业不受其中进程数量变化的影响，在弹性调度过程中，作业里的进程数量会随集群 workload 情况相应增减，所以作业必须是容错的，才能配合调度系统，实现弹性调度。\n在这个过程中，容错通常由分布式框架实现，比如 Spark 和 ElasticDL 都可以做到当有进程挂掉，或者新的进程加入时，作业不会暂停或者重启，而是平滑地继续。而弹性调度是由分布式框架和分布式操作系统（集群管理系统）一起实现的。比如，当有进程挂掉的时候，分布式框架应该通知集群管理系统新启进程来补位 —— 至于集群管理系统能不能启动起来，取决于用户剩余 quota 和集群的忙碌情况。\n1. 基于 Kubernetes-native 通常使用 Keras 的 model-fit API 和 Estimator，开发者只需要调用 API 即可进行分布式训练或预测，然而 ElasticDL 不依赖于 TensorFlow runtime 实现分布式计算，它的实现在 runtime 之外。\nElasticDL 通过 Kubernetes-native 机制来完成分布式计算，而这也为其带来了容错性与弹性调度的能力。\n所谓 Kubernetes-native指的是一个程序调用 Kubernetes API 来起止进程，它与 Google MapReduce 的机制类似。MapReduce 是一个 Borg-native 的分布式计算框架，用户通过运行一个 Borg 客户端程序启动一个 MapReduce 作业；Borg 客户端调用 Borg API 提交作业，并且启动一个 master 进程；这个 master 调用 Borg API 启动其它 workers 进程。\n在 ElasticDL 中，用户调用 ElasticDL 的命令行客户端程序启动作业；这个客户端程序调用Kubernetes API 启动 master 进程，master进程继续调用 Kubernetes API 启动其它进程。\n“ElasticDL 的整个容错和弹性调度机制都依赖于 Kubernetes-native 架构”，王益介绍：“如果 worker 挂了，按照分布式深度学习训练算法的数学特性，可以不用处理，即可确保训练过程继续。如果一个 parameter server 进程挂了，master会选择一个 worker 进程，让它转换角色替补上挂掉的parameter server 进程。”\n在这两种情况下，master 都会调用 Kubernetes API，请它再启动一个额外的 worker 进程。如果启动成功，master 会带其加入到与其它进程的协作中。master 进程的状态（主要是三个 task queues：todo、doing与 done）可以保留在 Kubernetes 集群的 etcd 存储系统中。\n“这样，万一 master 挂了，重启的 master 进程可以从 etcd 继承前世的状态。任何进程挂了，master 都会请 Kubernetes 去启动一个新的进程代替挂掉的进程。而 Kubernetes 是否能完成使命取决于用户剩余 quota 和集群剩余资源情况。”\n2. 基于 TensorFlow 2.0 EagerExecution 为什么 ElasticDL 又基于 TensorFlow 2.0 呢？王益介绍，这是因为 TensorFlow 2.0 带来了 Eager Execution 特性，正是针对这一特性的尝试，让开发团队实现了Kubernetes-native 的调度方式，从而让 ElasticDL 支持容错和弹性调度。\n分布式学习需要了解每个进程根据局部训练数据计算得到的 gradients，才能汇总这些 gradients 来更新模型。\nTensorFlow 1.x 的执行方式被称为 Graph Mode —— 深度学习计算步骤被表示成一个 graph 数据结构，TensorFlow runtime 会解释执行这个 graph。其中，gradients 的计算过程是 graph …","date":1568635200,"description":"业界首个基于 TensorFlow 实现弹性深度学习的开源系统 ElasticDL 项目的技术细节全面介绍。","dir":"blog/alipay-deep-learning-tensorflow-elasticdl/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"74eedc82d0b4a438d332dd5443605318","permalink":"https://sofastack.github.io/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","publishdate":"2019-09-16T20:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","summary":"9 月 11 日，蚂蚁金服在2019谷歌开发者大会上海站上开源了 ElasticDL 项目，这是业界首个基于 TensorFlow 实现弹性深度学习的开源系统。 开源地址为：https://g","tags":["ElasticDL"],"title":"ElasticDL：蚂蚁金服开源基于 TensorFlow 的弹性分布式深度学习系统","type":"blog","url":"/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/","wordcount":4705},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n中秋特辑推荐阅读 【中秋特辑】（含视频回顾）SOFAStack 活动回顾整理集合 SOFARegistry 系列解析文章 服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 SOFA 项目进展 本周发布详情如下：\n发布 SOFARPC v5.6.1，主要变更如下：\n 升级 sofa-bolt 的版本到 1.5.6 修复 com.alipay.sofa.rpc.log.LoggerFactory 提供的 Logger 实现方案在多 classloader 场景下存在会出现类型不匹配的问题 修复 providerInfo 中可能出现的 staticAttrs 空指针问题 详细发布报告： https://github.com/sofastack/sofa-rpc/releases/tag/v5.6.1\nHey，中秋快乐呀 ","date":1568271600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190913/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"85b998cb10df30ee42c04a8571b73598","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190913/","publishdate":"2019-09-12T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190913/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/9 - 9/13】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190913/","wordcount":423},{"author":"Yavin","categories":"SOFARegistry","content":" SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第三篇，本篇作者 Yavin，来自考拉海购。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n导读 集群成员管理是分布式系统中绕不开的话题。MetaServer 在 SOFARegistry 中，承担着集群元数据管理的角色，用来维护集群成员列表。本文希望从 MetaServer 的功能和部分源码切入剖析，为学习研究、或者项目中使用SOFARegistry 的开发者带来一些启发，分为三个部分：\n 功能介绍 内部架构 源码分析 功能介绍 MetaServer 作为 SOFARegistry 的元数据中心，其核心功能可以概括为集群成员管理。分布式系统中，如何知道集群中有哪些节点列表，如何处理集群扩所容，如何处理集群节点异常，都是不得不考虑的问题。MetaServer 的存在就是解决这些问题，其在 SOFARegistry 中位置如图所示： MetaServer 通过 SOFAJRaft 保证高可用和一致性，类似于注册中心，管理着集群内部的成员列表：\n 节点列表的注册与存储 节点列表的变更通知 节点健康监测 内部架构 内部架构如下图所示：\nMetaServer 基于 Bolt, 通过 TCP 私有协议的形式对外提供服务，包括 DataServer, SessionServer 等，处理节点的注册，续约和列表查询等请求。\n同时也基于 Http 协议提供控制接口，比如可以控制 session 节点是否开启变更通知, 健康检查接口等。\n成员列表数据存储在 Repository 中，Repository 被一致性协议层进行包装，作为 SOFAJRaft 的状态机实现，所有对 Repository 的操作都会同步到其他节点, 通过Rgistry来操作存储层。\nMetaServer 使用 Raft 协议保证数据一致性， 同时也会保持与注册的节点的心跳，对于心跳超时没有续约的节点进行驱逐，来保证数据的有效性。\n在可用性方面，只要未超过半数节点挂掉，集群都可以正常对外提供服务， 半数以上挂掉，Raft 协议无法选主和日志复制，因此无法保证注册的成员数据的一致性和有效性。整个集群不可用 不会影响 Data 和 Session 节点的正常功能，只是无法感知节点列表变化。\n源码分析 服务启动 MetaServer 在启动时，会启动三个 Bolt Server，并且注册 Processor Handler，处理对应的请求, 如下图所示：\n DataServer：处理 DataNode 相关的请求； SessionServer：处理 SessionNode 相关的请求； MetaServer：处理MetaNode相关的请求； 然后启动 HttpServer, 用于处理 Admin 请求，提供推送开关，集群数据查询等 Http 接口。\n最后启动 Raft 服务， 每个节点同时作为 RaftClient 和 RaftServer, 用于集群间的变更和数据同步。\n各个 Server 的默认端口分别为：\nmeta.server.sessionServerPort=9610 meta.server.dataServerPort=9611 meta.server.metaServerPort=9612 meta.server.raftServerPort=9614 meta.server.httpServerPort=9615 节点注册 由上节可知，DataServer 和 SessionServer 都有处理节点注册请求的 Handler。注册行为由 Registry 完成。注册接口实现为：\n@Override public NodeChangeResult register(Node node) { StoreService storeService = ServiceFactory.getStoreService(node.getNodeType()); return storeService.addNode(node); } Regitsry 根据不同的节点类型，获取对应的StoreService，比如DataNode，其实现为 DataStoreService 然后由 StoreService 存储到 Repository 中，具体实现为：\n// 存储节点信息 dataRepositoryService.put(ipAddress, new RenewDecorate(dataNode, RenewDecorate.DEFAULT_DURATION_SECS)); //... // 存储变更事件 dataConfirmStatusService.putConfirmNode(dataNode, DataOperator.ADD); 调用 RepositoryService#put 接口存储后，同时会存储一个变更事件到队列中，主要用于数据推送，消费处理。\n节点数据的存储，其本质上是存储在内存的哈希表中，其存储结构为：\n// RepositoryService 底层存储 Map\u0026amp;lt;String/*dataCenter*/, NodeRepository\u0026amp;gt; registry; // NodeRepository 底层存储 Map\u0026amp;lt;String/*ipAddress*/, RenewDecorate\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; nodeMap; 将RenewDecorate存储到该 Map 中，整个节点注册的流程就完成了，至于如何和 Raft 协议进行结合和数据同步，下文介绍。\n节点移除的逻辑类似，将节点信息从该 Map 中删除，也会存储一个变更事件到队列。\n注册信息续约和驱逐 不知道有没有注意到，节点注册的时候，节点信息被 RenewDecorate 包装起来了，这个就是实现注册信息续约和驱逐的关键：\nprivate T renewal; // 节点对象封装 private long beginTimestamp; // 注册事件 private volatile long lastUpdateTimestamp; // 续约时间 private long duration; // 超时时间 该对象为注册节点信息，附加了注册时间、上次续约时间、过期时间。那么续约操作就是修改lastUpdateTimestamp，是否过期就是判 …","date":1568271600,"description":" 本文为《剖析 | SOFARegistry 框架》第三篇，作者 Yavin ，来自考拉海购。","dir":"blog/sofa-registry-metaserver-function-introduction/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6e08281a1d2851d95121fc739cf80669","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","publishdate":"2019-09-12T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","summary":"SOFAStack （Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析","type":"blog","url":"/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/","wordcount":3311},{"author":"潘潘","categories":"SOFAStack","content":" SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时任务、限流/熔断框架、动态配置推送、分布式链路追踪、Metrics 监控度量、分布式高可用消息队列、分布式事务框架和分布式数据库代理层等。\nSOFAStack：https://github.com/sofastack\n本文为 SOFAStack 相关线上线下活动的回顾集合，并且会不定时更新。\n/ SOFAChannel 线上直播系列 / SOFAChannel#8 从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 视频回顾资料 SOFAChannel#7 自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 视频回顾资料 SOFAChannel#6 蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 视频回顾资料 SOFAChannel#5 给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 视频回顾资料 SOFAChannel#4 分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 视频回顾资料 SOFAChannel#3 SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 视频回顾资料 SOFAChannel#2 SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 视频回顾资料 SOFAChannel#1 从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 视频回顾资料 / SOFAMeetup 系列 / SOFAMeetup#3\u0026amp;lt;广州站\u0026amp;gt; 分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾 视频回顾资料\n 蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾 视频回顾资料\n SOFAMeetup#2\u0026amp;lt;上海站\u0026amp;gt; 当 Spring Cloud 遇上 SOFAStack | Meetup#2 回顾 视频回顾资料\n 基于 SOFAArk 和 SOFADashboard 实现动态模块管控 | Meetup#2 回顾 视频回顾资料\n SOFAMeetup#1\u0026amp;lt;北京站\u0026amp;gt; 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼 视频回顾资料\n 蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼 视频回顾资料\n 详解蚂蚁金服 SOFAJRaft | 生产级高性能 Java 实现 视频回顾资料\n / 技术大会系列 / 2019 年技术大会实录集合 五小时构建云原生电商平台 | KubeCon SOFAStack Workshop 详解\n 蚂蚁金服大规模分布式事务实践和开源历程 | GIAC 实录\n 蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录\n 2018 年技术大会实录集合 企业实施分布式架构的挑战以及应对建议 | 上海 ATEC 大会实录\n 企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录\n Knative：重新定义 Serverless | GIAC 实录\n 蚂蚁金服微服务实践 | 开源中国年终盛典分享实录\n 蚂蚁金服Service Mesh新型网络代理的思考与实践 | GIAC 分享实录\n 蚂蚁金服 Service Mesh 渐进式迁移方案|Service Mesh Meetup 实录\n 蚂蚁金服SOFAMesh在多语言上的实践 | CNUTCon 实录\n 从平台到中台 | Elaticsearch 在蚂蚁金服的实践经验\n 从“挖光缆”到“剪网线”|蚂蚁金服异地多活单元化架构下的微服务体系\n 蚂蚁金服 Service Mesh 实践探索 | Qcon 实录\n ","date":1568260800,"description":"本文为 SOFAStack 相关线上线下活动的回顾集合，并且会不定时更新。","dir":"blog/sofa-activity-retrospect-collection/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b1f0034b1e2c249a33c57be88f5a184c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-activity-retrospect-collection/","publishdate":"2019-09-12T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-activity-retrospect-collection/","summary":"SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时","tags":["SOFAStack"],"title":"（含视频回顾）SOFAStack 活动回顾整理集合","type":"blog","url":"/sofastack.tech/blog/sofa-activity-retrospect-collection/","wordcount":986},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@王冰 提问：\n 请问个问题，SOFATracer 在采样计算时 rootSpan 为什么会计算两次，第一次是生成 span 时，第二次是在上报前又计算了一次？\n A：这种是考虑到产生 span 的逻辑是业务自己来构建，非正常逻辑情况下的一种兼容处理。对于 Tracer 来说，所有的上报是必须 SOFATracer 的行为，因此在 report 之前也会基于当前采样策略计算一次计算。默认情况下产生跟 span 时的计算更多是 span 或者说 span context 的，这个会作为向下透传的。另外产生不一致的情况不会出现，上报那段逻辑会先检查当前 span 的父 span，如果父 span 是 null 也就意味着当前 span 是 root span，所以也必须要计算。\n2、@迟广文 提问：\n 在使用 Seata 的时候，使用了 restful 框架，我的 TCC 调通了，是在接口上加了 @LocalTCC，实现类加 @Component，本以为会冲突，结果没有。\n A：TCC 的代理会代理二种类型的分支：在本地标注为 localTcc，第二种是 RPC 框架（dubbo、sofa-rpc）当 consumer 端使用作为 reference bean 且在 provider 端标注了二阶段注解时，这二种类型时互斥的，一个 TCC 分支只属于其一类型。\nSOFAChannel 回顾集合 SOFAChannel#8：从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下：\n1、SOFATracer v2.4.1/v3.0.6 版本发布，主要变更如下：\n 支持自定义埋点 (FlexibleTracer) 支持 Dubbo 2.6.x 日志输出支持非 json 格式(xstringbuilder)\n 支持自定义扩展 Repoter 上报\n Dubbo 2.7.x 系列支持 2.7.3 版本\n 修复 BasePreparedStatement 初始化问题\n 修复 SQLException 被覆盖问题\n 优化常量命名及代码注释等\n 更新案例及官方文档\n 详细发布报告：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v2.4.1\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.0.6\n官方文档：\nhttps://www.sofastack.tech/projects/sofa-tracer/overview/\n2、SOFABoot v3.2.0 版本发布，主要变更如下：\n 升级 sofa-bolt 版本至 1.5.6 根据 Spring Boot 官方文档建议重构工程代码和组织结构 详细发布报告：\nhttps://github.com/sofastack/sofa-boot/releases/tag/v3.2.0\n官方文档：\nhttps://www.sofastack.tech/projects/sofa-boot/overview/\nSOFA 用户召集 如果您已经在生产环境使用了 SOFAStack 相关组件，请在下方链接登记告诉我们，方便我们更好地为您服务，我们将会把您加入到 “SOFAStack金牌用户服务群【邀约制】”里面，以便更加快捷的沟通和更加高效的线上使用问题支持。 https://github.com/sofastack/sofastack.tech/issues/5 已有用户查看： https://www.sofastack.tech/awesome\n","date":1567753200,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190906/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"94743dfe34353e1f6910291d127a73d6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190906/","publishdate":"2019-09-06T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190906/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【9/2 - 9/6】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190906/","wordcount":1296},{"author":"潘潘","categories":"SOFALab","content":" | SOFALab \u0026amp;lt;SOFA:Lab/\u0026amp;gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~\n\u0026amp;lt;SOFA:RegistryLab/\u0026amp;gt;是《剖析 | SOFARegistry 实现原理》系列，会逐步详细介绍 SOFARegistry 各个部分的代码设计和实现，欢迎领取文章进行共建。\n| SOFARegistry SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nSOFARegistry:https://github.com/sofastack/sofa-registry\n| SOFA:RegistryLab 认领列表：\n 【已完成】海量数据下的注册中心 - SOFARegistry 架构介绍 【已完成】SOFARegistry 服务发现优化之路 【已完成】SOFARegistry 数据分片和同步方案详解 【已完成】SOFARegistry MetaServer 功能介绍和实现剖析 【已完成】SOFARegistry Session 存储策略 【已领取】SOFARegistry 如何实现秒级服务上下线通知 【已领取】SOFARegistry 如何实现 DataServer 平滑扩缩容 参与方式：关注「金融级分布式架构」回复可领取的文章标题，会有相关同学联系进行确认。\n 欢迎领取，参与共建~\n","date":1567483200,"description":"","dir":"activities/sofa-registry-lab/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ebbc0e9574d88e21f39926e750c848e9","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-registry-lab/","publishdate":"2019-09-03T12:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-registry-lab/","summary":"| SOFALab \u0026lt;SOFA:Lab/\u0026gt; 源码研究实验室，由 SOFA 团队和源码爱好者们出品，欢迎你的加入~ \u0026lt;SOFA:RegistryLab/\u0026gt;是《剖析 | SOFARegistry 实现原理》系列","tags":["SOFALab","SOFARegistry"],"title":"\u003cSOFA:RegistryLab/\u003e","type":"activities","url":"/sofastack.tech/activities/sofa-registry-lab/","wordcount":435},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFA:Channel/，有趣实用的分布式架构频道。\n本文根据 SOFAChannel#8 直播分享整理，主题：从一个例子开始体验 SOFAJRaft。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23390449，不错过每场直播。\n 大家好，我是力鲲，来自蚂蚁金服， 现在是 SOFAJRaft 的开源负责人。今天分享主题是《从一个例子开始体验 SOFAJRaft》，其实从这个题目大家也能看出来，今天是要从一个用户而非 owner 的视角来了解 SOFAJRaft。这么设计题目的原因是 SOFAJRaft 作为一种共识算法的实现，涉及到了一些概念和术语，而这些内容更适合通过一系列文章进行阐述，而在直播中我们希望能够分享对用户更有用、更容易理解的信息——SOFAJRaft 是什么，以及我们怎么去用它。\n首先介绍一下 SOFAJRaft 的背景知识，接下来说说这个例子源于什么需求，第三部分是架构的选型，第四部分来看看我们如何使用 SOFAJRaft，最后运行代码，看看 SOFAJRaft 是如何支撑业务运行的。\n欢迎加入社区成为 Contributor，SOFAJRaft。\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务； 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\n图1 - 复制状态机\nSOFAJRaft SOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统。\n图2 - SOFAJRaft 结构\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依然用之前的银行账户系统举例来说明 SOFAJRaft 的各模块是如何工作的。\n当 Client 向 SOFAJRaft 发来一个“存 100 元”的命令之后，Node 的 Log 存储模块首先将这个命令以 Log 的形式存储到本地，同时 Replicator 会把这个 Log 复制给其他的 Node，Replicator 是有多个的，集群中有多少个 Follower 就会有多少个 Replicator，这样就能实现并发的日志复制。当 Node 收到集群中半数以上的 Follower 返回的“复制成功” 的响应之后，就可以把这条 Log 以及之前的 Log 有序的送到状态机里去执行了。状态机是由用户来实现的，比如我们现在举的例子是银行账户系统，所以状态机执行的就是账户金额的借贷操作。如果 SOFAJRaft 在别的场景中使用，状态机就会有其他的执行方式。\nSnapshot 是快照，所谓快照就是对数据当前值的一个记录，Leader 生成快照有这么几个作用：\n 当有新的 Node 加入集群的时候，不用只靠日志复制、回放去和 Leader 保持数据一致，而是通过安装 Leader 的快照来跳过早期大量日志的回放； Leader 用快照替代 Log 复制可以减少网络上的数据量； 用快照替代早期的 Log 可以节省存储空间； 图3 - 需要用户实现：StateMachine、Client\nSOFAJRaft 需要用户去实现两部分：StateMachine 和 Client。\n因为 SOFAJRaft 只是一个工具，他的目的是帮助我们在集群内达成共识，而具体要对什么业务逻辑达成共识是需要用户自己去定义的，我们将用户需要去实现的部分定义为 StateMachine 接口。比如账务系统和分布式存储这两种业务就需要用户去实现不同的 StateMachine 逻辑。而 Client 也很好理解，根据业务的不同，用户需要去定义不同的消息类型和客户端的处理逻辑。\n图4 - 需要用户实现一些接口\n前面介绍了这么多，我们引出今天的主题：如何用 SOFAJRaft 实现一个分布式计数器？\n需求 我们的需求其实很简单，用一句话来说就是：提供一个 Counter，Client 每次计数时可以指定步幅，也可以随时发起查询。\n我们对这个需求稍作分析后，将它翻译成具体的功能点，主要有三部分：\n 实现：Counter server，具备计数功能，具体运算公式为：Cn = Cn-1 + delta； 提供写服务，写入 delta 触发计数器运算； 提供读服务，读取当前 Cn 值； 除此之外，我们还有一个可用性的可选需求，需要有备份机器，读写服务不能不可用。\n系统架构 根据刚才分析出来的功能需求，我们设计出 1.0 的架构，这个架构很简单，一个节点 Counter Server 提供计数功能，接收客户端发起的计数请求和查询请求。\n图5 - 架构 1.0\n但是这样的架构设计存在这样两个问题：一是 Server 是一个单点，一旦 Server 节点故障服务就不可用了；二是运算结果都存储在内存当中，节点故障会导致数据丢失。\n图6 - 架构 1.0 的不足：单点\n针对第二个问题，我们优化一下，加一个本地文件存储。这样每次计数器完成运算之后都将数据落盘，当节点故障之时，我们要新起一台备用机器，将文件数据拷贝过来，然后接替故障机器对外提供服务。这样就解决了数据丢失的风险，但是同时也引来另外的问题：磁盘 IO 很频繁，同时这种冷备的模式也依然会导致一段时间的服务不可用。\n图7 - 架构 1.0 的不足：冷备\n所以我们提出架构 2.0，采用集群的模式提供服务。我们用三个节点组成集群，由一个节点对外提供服务，当 Server 接收到 Client 发来的写请求之后，Server 运算出结果，然后将结果复制给另外两台机器，当收到其他所有节点的成功响应之后，Server 向 Client 返回运算结果。\n图8 - 架构 2.0\n但是这样的架构 …","date":1567400400,"description":"本文根据 SOFAChannel#8 直播分享整理，以 Counter 为例，介绍 SOFAJRaft 的概念，并从需求提出开始，一步步完善架构，明确业务要实现哪些接口，最后启动日志观察 SOFAJRaft 如何支撑业务执行。","dir":"blog/sofa-channel-8-retrospect/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7eab29bc73ad095706ad2daef197b1bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-8-retrospect/","publishdate":"2019-09-02T13:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-channel-8-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#8 直播分享整理，主题：从一个例子开始体验 SOFAJRaft。 回顾视频以及 PPT 查看","tags":["SOFAJRaft","SOFAChannel"],"title":"从一个例子开始体验 SOFAJRaft | SOFAChannel#8 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-8-retrospect/","wordcount":5541},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@柴炜晨 提问：\n 求问下 SOFAJRaft rhea split 后，原片1 [0,100) 分裂为 1 [0, 50) , 新片 2[50, 100)，新片 2 上的初始数据是从怎么来的呢？\n A：一个 store 里的所有 region 实际上是共享一个存储，split 只是新增一个逻辑 region 并修改被分裂的和新 region 的 range，后续的 snoapshot ，副本迁移等就均以新的 region 为最小单位了。\nSOFAJRaft：https://github.com/sofastack/sofa-jraft\n2、关于 SOFARegistry 的几个问题：\n@虞家成 提问：\n 服务 Sub 数据的一致性问题，其中主要的机制是通过 client, session 对缓存的逐级回放和比对，再加上版本号机制来实现最终一致性，问题是：这个版本号的生成，与递增是由谁来管理与维护？client? session? 还是 data ?\n A：这个版本号主要是在 data 上产生，版本号和最终写入内存时间戳关联产生，所有数据是指服务发布数据保证一致性。\n 对于每条服务的 Pub 数据，是否需要维护一个 ttl 值，否则在某些情况下，这条数据不能释放？\n A：如果你说的 ttl 值是指 pub 数据的生存时间，是有的，我们 pub 数据会有租约机制进行定时更新保证一致性，如果过期会进行清理释放。\n Data 节点是通过广播的方式来通知每个 session 节点？那每个 session 节点是否会存在所有服务的全量 Pub 数据？ 这对内存及网络资源消耗会不会过大？\n A：Data 是通过广播方式通知每个 session 节点，session上有订阅关系按照自己订阅关系判断是否需要推送给客户端。每个 session 没有全量的 pub 数据，但会存在和其连接部分客户端发布数据作为一致性备份回放使用。这个堆内存目前看压力还是可以的。\nSOFARegistry：https://github.com/sofastack/sofa-registry\n3、@黄剑 提问：\n 关于 Seata 有一个问题，全局锁用进去之后，意思就是要等 2 阶段完成后，进行当前资源释放，全局锁那边的接口才进行调用到，如果业务有很多地方都操作到相同表的某一条数据，那岂不是每个业务上面加全局锁？可是我并不知道哪些业务可能会有冲突的哇！\n A：目前只查锁不加锁。\n 我需要查到最终 2 阶段的那张表数据，意思自己的业务上面全部都要使用 @GlobalLock 注解？是这个意思么？\n A：如果你查询的业务接口没有 GlobalTransactional 包裹，也就是这个方法上压根没有分布式事务的需求，这时你可以在方法上标注 @GlobalLock 注解，并且在查询语句上加 for update。如果你查询的接口在事务链路上外层有 GlobalTransactional 注解，那么你查询的语句只要加 for update 就行。设计这个注解的原因是在没有这个注解之前，需要查询分布式事务读已提交的数据，但业务本身不需要分布式事务。若使用 GlobalTransactional 注解就会增加一些没用的额外的 rpc 开销比如 begin 返回 xid，提交事务等。GlobalLock 简化了 rpc 过程，使其做到更高的性能。\n 好的，感谢回复，因为现在出现了一个业务，但是不同接口，上游有全局事务来调用，然后又有其他业务操作了相同的表，所以现在导致我现在根本不知道哪些业务要考虑使用 GlobalLock。\n Seata：https://github.com/seata/seata\n本周推荐阅读 Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录 Service Mesh 发展趋势：云原生中流砥柱 SOFA 项目进展 本周发布详情如下：\n发布 SOFA Mosn v0.7.0，主要变更如下：\n 新增 FeatureGates 的支持 新增一项 Metrics 统计:mosn_process_time 支持 Listener 重启 升级 Go 版本到 1.12.7 修改 XDS Client 启动时机，优先于 MOSN Server 的启动 BUG 修复 详细发布报告： https://github.com/sofastack/sofa-mosn/releases/tag/0.7.0\n","date":1567148400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190830/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"afd535d1a14ed1fc010e93bcff36553d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190830/","publishdate":"2019-08-30T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190830/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/26 - 8/30】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190830/","wordcount":1599},{"author":"敖小剑","categories":"Service Mesh","content":" 敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。\n本文内容整理自 8 月 11 日 Service Mesher Meetup 广州站主题演讲，完整的分享 PPT 获取方式见文章底部。\n 前言 标题“Service Mesh发展趋势(续)”中的“续”是指在今年5月底，我在 CloudNative Meetup上做了一个“Service Mesh发展趋势：云原生中流砥柱”的演讲，当时主要讲了三块内容：Service Mesh 产品动态、发展趋势、与云原生的关系。后来有同学反应希望部分感兴趣的内容能讲的更深一些，所以今天将继续“Service Mesh 发展趋势”这个话题。\n今天给大家分享的内容有部分是上次演讲内容的深度展开，如社区关心的 Mixer v2 以及最近看到的一些业界新的技术方向，如 web assembly 技术，还有产品形态上的创新，如 google traffic director 对 Service Mesh 的虚拟机形态的创新支持。\n在 Service Mesh 出道四年之际，也希望和大家一起带着问题来对 Service Mesh 未来的发展进行一些深度思考。\n在正式开始分享之前，让我们先轻松一下，下面是最近流行的梗，各种灵魂拷问：\n我们今天的分享内容，将效仿上面的方式，对 Servic Mesh 进行四个深入灵魂的拷问。\nService Mesh 灵魂拷问一：要架构还是要性能？ 第一个灵魂拷问针对 Istio 的：要架构还是要性能？\nIstio 的回答：要架构 Istio 的回答很明确：架构优先，性能靠边。\n左边是 Istio 的架构图，从 2017 年的 0.1 版本开始，一直到 Istio1.0，控制平面和数据平面完全物理分离，包括我们今天要关注的 Mixer 模块。Sidecar 通过和 Mixer 的交互实现策略检查和遥测报告。\n右边是 Mixer 的架构图，在 Mixer 内部提供了很多 Adapter 实现，用来提供各种功能。这些 Adapter 运行在 Mixer 进程中，因此被称为进程内适配器（In-Process Adapter）。\n为什么 Istio 选择 Mixer 和 Proxy 分离的架构？\n我们先来看这个架构的优点，概括地说优点主要体现为：\n 架构优雅 职责分明 边界清晰 特别指出，上图右侧的红色竖线，是 Istio0.1 到 Istio1.0 版本中 Istio 和后台基础设施的边界。这意味着，从 k8s API Server 中读取 Adapter 相关的配置信息 （以 Istio CRD 的形式存在），是作为 Istio 功能的一部分。\n具体的优点是：\n Mixer 的变动不影响 Sidecar：包括 Mixer 的部署调整和版本升级； Sidecar 无需和 Adapter 耦合，具体有： Sidecar 不需要读取配置，因此也无需直接连接到 k8s AP Server/Istio Galley； Adapter 的运行时资源开销和 Sidecar 无关； Sidecar 不受 Adapter 增减/更新/升级影响； 保持 Sidecar 代码简单：数以几十计的 Adapter 的代码无需直接进入 Sidecar 代码； 数据平面可替换原则：如果有替换数据平面的需求，则 Mixer 分离的架构会让事情简单很多； 至于缺点，只有一个：性能不好。\n而 1.1 版本之后，Istio 给出了新的回答：架构继续优先，性能继续靠边。\n上图是 Istio1.1 版本之后新的架构图，和之前的差异在于 Mixer 发生了变化，增加了进程外适配器（Out-of-Process Adapter），而 Mixer 和新的 Out-of-Process Adapter 之前依然是远程调用。\n为什么 Istio 改而选择 Out-of-Process Adapter?\n下图是采用 Out-of-Process Adapter 之后的请求处理流程图，Mixer 通过 Bypass Adapter 选择需要的属性列表，然后通过远程调用发送给 Out-of-Process Adapter。Out-of-Process Adapter 实现和之前的 In-Process Adapter 类似的功能，但是改为独立于 Mixer 的单独进程。\n采用 Out-of-Process Adapter 之后，Istio 的优点更加明显了，简单说就是：架构更优雅，职责更分明，边界更清晰。\n而且，请注意：按照 Istio 的设想，此时 Out-of-Process Adapter 已经不再作为 Istio 的组成部分，它的代码实现、安装部署、配置、维护等职责也不再由 Istio 承担，请留意上图中的红色竖线位置。Out-of-Process Adapter 的引入，对于 Istio 来说职责和边界的改变会让 Istio 简单，但是对于使用者（主要指运维）来说则增加了额外的负担，因此造成了很大的争议。\n至于缺点，除了上述的职责转移造成争议外，依然只有一个：性能不好，原来 Sidecar 和 Mixer 之间的远程调用已经让性能变得非常糟糕，现在 Mixer 和 Out-of-Process Adapter 之间再增多加一次远程调用，可谓雪上加霜。\nMixer v1 架构的优缺点分析 Mixer v1 架构的优点主要体现为：\n 集中式服务：提高基础设施后端的可用性，为前置条件检查结果提供集群级别的全局 2 级缓存； 灵活的适配器模型，使其以下操作变得简单： 运维添加、使用和删除适配器； 开发人员创建新的适配器（超过20个适配器）； 而 Mixer v1 架构的缺点，则主要体现为：\n 管理开销： 管理 Mixer 是许多客户不想负担的； 而进程外适配器强制运维管理适配器，让这个负担更加重； 性能： 即使使用缓存，在数据路径中同步调用 Mixer 也会增加端到端延迟； 进程外适配器进一步增加了延迟； 授权和认证功能是天然适合 mixer pipeline 的，但是由于 mixer 设计的延迟和 SPOF（单点故障）特性，导致直接在 Envoy 中实现(Envoy SDS)； 复杂性： Mixer 使用一组称为模板的核心抽象，来描述传递给适配器的数据。这些包括“metrics”，“logentry”，“tracepan”等。这些抽象与后端想要消费的数据不匹配，导致运维需要编写一些手动配置，以便在规范的 Istio 样式和后端特定的样式之间进行映射。原本期望这种映射可以在适配器中实现很大程度上的自动化，但是最终还是太复杂并需要手动配置。 备注：上述优点和缺点的描述摘录自 mixer v2 proposal 。\n 其中，Mixer 性能问题一直以来都是 Istio 最被人诟病的地方。\n那问题来了：如果要性能，该怎么做？\n下图是 Mixer v1 的调用流程，Proxy/Sidecar 是请求数据的起点，Infrastructure Backend 是终点。Mixer v1 …","date":1566972000,"description":"继续探讨 Service Mesh 发展趋势：深度分析 Istio 的重大革新 Mixer v2，Envoy 支持 Web Assembly 的意义所在；深入介绍 Google Traffic Director 对虚拟机模式的创新支持方式，以及最近围绕 SMI 发生的故事。","dir":"blog/service-mesh-development-trend-2/","fuzzywordcount":8100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"51e4af6a0771823fe055c5aebd2e76bd","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-development-trend-2/","publishdate":"2019-08-28T14:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/service-mesh-development-trend-2/","summary":"敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。 本文内容整理","tags":["Service mesh"],"title":"Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-development-trend-2/","wordcount":8088},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n1、@廖春涛 提问：\n 在 SOFAJRaft 中，snapshot load 后应该会有个日志重放的实现，但是我目前看代码没看到说 snapshot 和 LogEntry 有关联的地方，请问是什么关系呢？\n A：snapshot 就是为了压缩日志，以及加快新节点加入。snapshot 后，会将上上次的 snapshot 当时对应的日志级之前的删掉，为什么是上上次？ 因为本次 snapshot 的日志，可能还没有复制到所有 follower，这是一个小优化。 具体到日志重放，如果启动是 leader，会写入一条当前配置的日志，触发 fsm caller 的 onCommitted，然后去重放从 snapshot 的日志到最新的 committed 的日志到状态机。如果是 follower，安装 snapshot 后， leader 会发送该 snapshot 对应的日志之后的日志，走正常的复制流程，因此也会重放到最新的状态机。\n SOFAJRaft 当 Leader 的 Node 执行 apply 后，将 LogEntry 提交给 follower 是通过通知来进行的吗？是不是在 LogManagerImpl 里面的这串代码 A：这段是 wakeup replicators，复制日志到 follower 都是在 Replicator 中实现的。\n2、关于 Seata 的 grouplist 问题：\n 什么时候会用到 file.conf 中的 default.grouplist？\n A：当 registry.type=file 时会用到，其他时候不读。\n default.grouplist 的值列表是否可以配置多个？\n A：可以配置多个，配置多个意味着集群，但当 store.mode=file 时，会报错。原因是在 file 存储模式下未提供本地文件的同步，所以需要使用 store.mode=db，通过 db 来共享 TC 集群间数据\n 是否推荐使用 default.grouplist？\n A：不推荐，如问题1，当 registry.type=file 时会用到，也就是说这里用的不是真正的注册中心，不具体服务的健康检查机制当tc不可用时无法自动剔除列表，推荐使用 nacos 、eureka、redis、zk、consul、etcd3、sofa。registry.type=file 或 config.type=file 设计的初衷是让用户再不依赖第三方注册中心或配置中心的前提下，通过直连的方式，快速验证 Seata 服务。\n3、关于 Seata 事务分组：\n 什么是事务分组？\n A：事务分组是 Seata 的资源逻辑，类似于服务实例。在 file.conf 中的 my_test_tx_group 就是一个事务分组。\n 通过事务分组如何找到后端集群？\n A：首先程序中配置了事务分组（GlobalTransactionScanner 构造方法的 txServiceGroup 参数），程序会通过用户配置的配置中心去寻找 service.vgroup_mapping. 事务分组配置项，取得配置项的值就是 TC 集群的名称。拿到集群名称程序通过一定的前后缀+集群名称去构造服务名，各配置中心的服务名实现不同。拿到服务名去相应的注册中心去拉取相应服务名的服务列表，获得后端真实的 TC 服务列表。\n 为什么这么设计，不直接取服务名？\n A：这里多了一层获取事务分组到映射集群的配置。这样设计后，事务分组可以作为资源的逻辑隔离单位，当发生故障时可以快速 failover。\nSOFA 项目进展 本周发布详情如下：\n1、发布 Seata v0.8.0 版本，主要变更如下：\n 支持 oracle 数据库的 AT 模式 支持 oracle 数据库的批量操作 支持 undo_log 表名可配置 修复 xid 在 db 模式可重复的问题 优化数据镜像比对日志 详细参考发布报告：https://github.com/seata/seata/releases/tag/v0.8.0\n2、发布 SOFAARK v1.0.0 版本，主要变更如下：\n 支持插件批量导出资源和 ark-biz 禁止批量导入资源 支持指定版本调用，解决对于非激活状态的ark-biz服务访问问题（主要用于灰度验证，测试等） 支持打包时跳过打ark-executable 包的过程（优化） 支持从目录运行启动 ArkClient api 支持指定 biz 的 arguments 参数 使用 netty 代替 java NIO 实现 telnet server 支持 SpringBoot testNG 优化示例工程 详细发布报告：https://github.com/sofastack/sofa-ark/releases/tag/v1.0.0 SOFA 活动推荐 SOFA:Channel/线上直播第 8 期报名中~ 8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。\n 本期主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft 直播时间：8 月 29 日下周四晚 7点 你将收获： 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 报名方式：点击“这里” 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可） ","date":1566543600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190823/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"067db1c93be21087cc809be0294c1b32","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190823/","publishdate":"2019-08-23T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190823/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/19 - 8/23】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190823/","wordcount":1855},{"author":"苟利","categories":"SOFAMeetup","content":" 作者：苟利（陈自欣），蚂蚁金服中间件产品专家， 负责蚂蚁金服分布式链路跟踪系统的产品化工作，在日志分析、监控领域有多年工作经验。\n本文根据 8 月 11 日 SOFA Meetup#3 广州站 《蚂蚁金服在云原生架构下的可观察性的探索和实践》主题分享整理。现场回顾视频以及 PPT 查看地址见文末链接。\n前言 随着应用架构往云原生的方向发展，传统监控技术已经不能满足云原生时代运维的需求，因此，可观察性的理念被引入了 IT 领域。\n下面我将会就可观察性在云原生的起源，可观察性发展动力， 可观察性与监控的关系，可观察性的三大支柱，社区发展方向及产品现状，以及蚂蚁金服对相关问题的理解及实践进行探讨。\n才疏学浅，欢迎拍砖。\n为什么云原生时代需要可观察性 可观察性的由来 在云原生语境下的可观察性这个词，最早出现于2017年7月， Cindy Sridharan 在 Medium 写的一篇博客， \u0026amp;ldquo;Monitoring and Observability\u0026amp;ldquo;，谈到了可观察性与云原生监控的关系。\n而在2017年10月， 来自 Pivotal 公司的 Matt Stine，在接受 InfoQ 采访的时候，对云原生的定义进行了调整， 将Cloud Native Architectures 定义为具有以下六个特质：\n 模块化 （Modularity） (通过微服务) 可观察性 （Observability） 可部署性 （Deployability） 可测试性 （Testability） 可处理性 （Disposability） 可替换性 （Replaceability） 可见，在2017年下半年， 可观察性成为了一个 buzzword（时髦词） ，正式出现在了云计算领域。\n可观察性的定义 虽然“可观察性”这个词在 IT 行业是一个新的术语，但它其实是在上世纪60年代，由匈牙利裔工程师鲁道夫·卡尔曼提出的概念。\n术语“可观察性”，源于控制论，是指系统可以由其外部输出推断其内部状态的程度。\n这个外部输出， 在云原生的语境下，即 Telemetry ，遥测，通常由服务（services）产生，划分为三个维度或者说支柱， Tracing（跟踪），Metrics（指标） , Logging（日志）。\n为什么云原生需要可观察性 近年可以看到，云计算对基础架构改变甚为巨大，无论是互联网行业，还是传统行业，云化在提升资源利用率，提高业务敏捷性的价值已经成为了公式。而在应用层面，由于业务特性的原因，互联网公司大部分已经完成云化，应用架构也不同程度上，完成了从单体应用向微服务应用演进。 在转型后，整体系统复杂性大大增加，倒逼相应的工具及方法论进行升级改造， 去 hold 住这么复杂的局面。\n上图为 Uber 展示的总体调用链图。考虑到业务多样性及复杂度，在蚂蚁金服内部，相关调用关系只会更为复杂，用人类的智力，已经没有办法去理解如此复杂的调用关系。而上图只是展示了可观察性的链路调用， 如果再加上指标及日志， 不对工具及方法论进行革新， 是难以实现对复杂微服务架构的管控的。\n微服务只是云原生的模块化特性的体现， 再考虑到近年被广泛应用容器，Kubernetes , 以及大家关注度极高的 Service Mesh , Istio， 每一个新的技术的出现，在带来了更优雅的架构、更灵活的调度、更完善的治理的同时，也带来更多新的复杂性。\n因此，可观察性对于云原生的应用架构，是必不可少的特性。\n可观察性和传统监控的区别 说半天，不少同学就会说，这个可观察性与我们谈的最多的监控有什么区别。 虽然有不少的人认为， 这词就是个buzzword，就是赶时髦的，没有太大的意义， 但是我结合网上的讨论， 个人认为可观察性与监控， 含义上虽然接近，但是也有一些理念上的差别，使得讨论可观察性这个词，是有具有现实意义，并能真正产生相应的价值。\n 监控更多关注的是基础设施，更多与运维工程师相关，更强调是从外部通过各种技术手段去看内部，打开黑盒系统。 可观察性更多的是描述应用，在我们谈论具体某应用，或者是某些应用是否具备客观性的时候，通常与开发人员相关，因为在常见的可观察性的实践之中，开发人员需要在应用的开发过程中嵌入例如 statd 或者是 opentracing，或者是 opencensus 等所提供的库，对相关的 telemetry 进行输出，或者是俗话说的埋点。通过埋点，将服务内部的状态白盒化，使得其在运维阶段具备可观察性。某种程度上可以说，可观察性遵循了 DevOps 及 SRE 的理念，即研发运维一体化，从开发侧就考虑系统的可运维性。  这里值得补充说明的是，目前市面上，有商用或者开源APM 方案，通过入侵 JVM 或者其他技术手段，对应用进行自动埋点的，输出 trace 及 metrics 信息。 这同样也是一种可观察性的实现方式，这样做的最大的好处是，不需要对现有的应用进行改造，但是相应的 agent 对应用进行实时的监控， 必然会或多或少的增加资源的占用，例如每实例额外 30+MB 内存，5~10% 的 CPU 占用，在大规模的运行环境之中， 会有不少的成本增加。\n可观察性的三大支柱及社区进展 可观察性的三大支柱 可观察性的三大支柱及其之间的关系， Peter Bourgon 在2017年2月撰写了一篇简明扼要的文章， 叫 \u0026amp;ldquo;Metrics, tracing, and logging\u0026amp;rdquo; ， 有兴趣的可以去看一下， 以下仅为简单的提及。\n指标数据（Metrics Data） 描述具体某个对象某个时间点的值。在 Prometheus 中， 指标有四种类型，分别 Counter（计数器）、Gauge（瞬时值）、Histogram（直方图）和 Summary （概要）， 通过这四种类型，可以实现指标的高效传输和存储。\n日志数据 ( Logging Data） 描述某个对象的是离散的事情，例如有个应用出错，抛出了 NullPointerExcepction，或者是完成了一笔转账，个人认为 Logging Data 大约等同于 Event Data，所以告警信息在我认为，也是一种 Logging Data。 但是也有技术团队认为，告警应该算是可观察性的其中一个支柱。 跟踪数据（Tracing Data） Tracing Data 这词貌似现在还没有一个权威的翻译范式，有人翻译成跟踪数据，有人翻译成调用数据，我尽量用Tracing 这个词。 Tracing 的特点就是在单次请求的范围内处理信息，任何的数据、元数据信息都被绑定到系统中的单个事务上。 一个Trace 有一个唯一的Trace ID ，并由多个Span 组成。\n社区方案进展 由于可观察性在云原生中，是一个非常重要的特性， 因此，在开源世界中，先后出现了两个定位都比较类似的项目，分别是源自 Google 的 OpenCensus （定位上报 Tracing + metris） 和由 CNCF 孵化的 OpenTracing（定位上报 Tracing）。 两者都定位于提供厂商中立的技术规范，及实现该规范各种编程语言遥测库，使得用户在使用了相关的库以后，可 …","date":1566381600,"description":"本文根据 8 月 11 日 SOFA Meetup#3 广州站 《蚂蚁金服在云原生架构下的可观察性的探索和实践》主题分享整理，文中包含本次分享视频回顾以及 PPT 查看地址。","dir":"blog/sofa-meetup-3-cloud-original-retrospect/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"85eba21fd9adf73841d7b7ee103723ae","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","publishdate":"2019-08-21T18:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","summary":"作者：苟利（陈自欣），蚂蚁金服中间件产品专家， 负责蚂蚁金服分布式链路跟踪系统的产品化工作，在日志分析、监控领域有多年工作经验。 本文根据 8 月 11","tags":["SOFAMeetup"],"title":"蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/","wordcount":4758},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n本周推荐阅读 分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾 中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说 溢米教育推荐平台的效率与稳定性建设 | SOFAStack 用户说 SOFA 项目进展 本周发布详情如下：\n发布 SOFAJRaft v1.2.6, 主要变更如下： - i. 修复 ReadIndex 并发情况下可能出现的读超时 - ii. 保存 raft meta 失败后终止状态机 - iii. 增加 LogEntry checksum validation - iv. 优化 log replication 线程模型减少锁竞争 - v. 优化 RheaKV multi group snapshot - vi. 致谢（排名不分先后）@SteNicholas @zongtanghu\n详细参考发布报告：https://github.com/sofastack/sofa-jraft/releases/tag/1.2.6\nSOFA 活动推荐  SOFA:Channel/线上直播第 8 期《从一个例子开始体验 SOFAJRaft》报名中~\n8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。 在本次直播中，我们将重点放在如何去使用这个工具上，用示例来说明如何使用 SOFAJRaft 实现自己的分布式应用。在此过程中，我们会对涉及到的一些 SOFAJRaft 经典概念进行讲解。\n| 点击“这里”即可报名\n| 本期将带来：\n 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23390449（搜索群号加入即可）\n","date":1565942400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190816/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"277754f72430d4473dc3920edbaf2ddb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190816/","publishdate":"2019-08-16T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190816/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/12 - 8/16】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190816/","wordcount":724},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft\n 活动时间：8 月 29 日周四晚 7 点\n 活动形式：线上直播\n 视频回顾：https://tech.antfin.com/community/live/821\n 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#8：从一个例子开始体验 SOFAJRaft SOFAJRaft 是 Raft 算法的 Java 实现，其本质是一个工具项目。在本次直播中，我们将重点放在如何去使用这个工具上，用示例来说明如何使用 SOFAJRaft 实现自己的分布式应用。在此过程中，我们会对涉及到的一些 SOFAJRaft 经典概念进行讲解。\n为了更好地直播体验，可以在直播前，预习 SOFAJRaft 相关源码解析文章，文章集合：https://www.sofastack.tech/tags/sofajraft/\n8 月 29 日周四晚 7 点，将邀请 SOFAJRaft 开源负责人力鲲，从一个 SOFAJRaft 实例出发，带大家体验 SOFAJRaft 的应用。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/737\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 SOFAChannel#8：从一个例子开始体验 SOFAJRaft 力鲲 SOFAJRaft 开源负责人\n本期分享大纲： 如何使用 SOFAJRaft 实现自己的分布式应用 基于实例理解 SOFAJRaft 中的概念和术语 嘉宾 SOFAGirl 主持人 力鲲 SOFAJRaft 开源负责人 ","date":1565842200,"description":"8 月 29 日周四晚 7 点，线上直播第 8 期。","dir":"activities/sofa-channel-8/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"92590333a35992bc201c798645cbf7ea","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-8/","publishdate":"2019-08-15T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-8/","summary":"概要 活动主题：SOFAChannel#8：从一个例子开始体验 SOFAJRaft 活动时间：8 月 29 日周四晚 7 点 活动形式：线上直播 视频回顾：https://tec","tags":["SOFAChannel","SOFAJRaft"],"title":"SOFAChannel#8：从一个例子开始体验 SOFAJRaft","type":"activities","url":"/sofastack.tech/activities/sofa-channel-8/","wordcount":561},{"author":"屹远","categories":"Seata","content":" 作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。 本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，着重分享分布式事务产生的背景、理论基础，以及 Seata 分布式事务的原理以及三种模式（AT、TCC、Saga）的分布式事务实现。\n本次分享的视频回顾以及 PPT 查看地址：https://tech.antfin.com/community/activities/779/review\n一、分布式事务产生的背景 1.1 分布式架构演进之 - 数据库的水平拆分 蚂蚁金服的业务数据库起初是单库单表，但随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。所以我们对数据库进行了水平拆分，将原单库单表拆分成数据库分片。\n如下图所示，分库分表之后，原来在一个数据库上就能完成的写操作，可能就会跨多个数据库，这就产生了跨数据库事务问题。\n1.2 分布式架构演进之 - 业务服务化拆分 在业务发展初期，“一块大饼”的单业务系统架构，能满足基本的业务需求。但是随着业务的快速发展，系统的访问量和业务复杂程度都在快速增长，单系统架构逐渐成为业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。\n如下图所示，蚂蚁金服按照面向服务架构（SOA）的设计原则，将单业务系统拆分成多个业务系统，降低了各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。\n业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，如何保证多个服务间的数据一致性成为一个难题。\n二、分布式事务理论基础 2.1 两阶段提交协议 两阶段提交协议：事务管理器分两个阶段来协调资源管理器，第一阶段准备资源，也就是预留事务所需的资源，如果每个资源管理器都资源预留成功，则进行第二阶段资源提交，否则协调资源管理器回滚资源。\n2.2 TCC TCC（Try-Confirm-Cancel） 实际上是服务化的两阶段提交协议，业务开发者需要实现这三个服务接口，第一阶段服务由业务代码编排来调用 Try 接口进行资源预留，所有参与者的 Try 接口都成功了，事务管理器会提交事务，并调用每个参与者的 Confirm 接口真正提交业务操作，否则调用每个参与者的 Cancel 接口回滚事务。\n2.3 Saga Saga 是一种补偿协议，在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。\n分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。\nSaga 理论出自 Hector \u0026amp;amp; Kenneth 1987发表的论文 Sagas。\nSaga 正向服务与补偿服务也需要业务开发者实现。\n三、Seata 及其三种模式详解 3.1 分布式事务 Seata 介绍 Seata（Simple Extensible Autonomous Transaction Architecture，一站式分布式事务解决方案）是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。Seata 开源半年左右，目前已经有超过 1.1 万 star，社区非常活跃。我们热忱欢迎大家参与到 Seata 社区建设中，一同将 Seata 打造成开源分布式事务标杆产品。\nSeata：https://github.com/seata/seata\n3.2 分布式事务 Seata 产品模块 如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。\n在 Seata 中，分布式事务的执行流程：\n TM 开启分布式事务（TM 向 TC 注册全局事务记录）； 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）； TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）； TC 汇总事务信息，决定分布式事务是提交还是回滚； TC 通知所有 RM 提交/回滚 资源，事务二阶段结束； 3.3 分布式事务 Seata 解决方案 Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。\n3.3.1 AT 模式 今年 1 月份，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。\nAT 模式如何做到对业务的无侵入 ： 一阶段： 在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。\n 二阶段提交： 二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。\n 二阶段回滚： 二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。\nAT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。\n3.3.2 TCC 模式 2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。\nTCC 三个方法描述：\n Try：资源的检测和预留； Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功； Cancel：预留资源释放； 蚂蚁金服在 TCC 的实践经验\n1 TCC 设计 - 业务模型分 2 阶段设计：\n用户接入 TCC ，最重要的是考虑如何将自己的业务模型拆成两阶段来实现。\n以“扣钱”场景为例，在接入 TCC 前，对 A 账户的扣钱，只需一条更新账户余额的 SQL 便能完成；但是在接入 TCC 之后，用户就需要考虑如何将原来一步就能完 …","date":1565776800,"description":"本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，文中包含本次分享视频回顾以及 PPT 查看地址。","dir":"blog/sofa-meetup-3-seata-retrospect/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"841ac02b2ce20e10748bf97db9d644ec","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","publishdate":"2019-08-14T18:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","summary":"作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。 本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，着重分享分布式事务","tags":["Seata","SOFAMeetup"],"title":"分布式事务 Seata Saga 模式首秀以及三种模式详解 | Meetup#3 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/","wordcount":5793},{"author":"胡宗棠","categories":"SOFAJRaft","content":" 文章摘要：BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云服务中的最佳应用实践。\n前言： 高可用的定义，指的是“一个系统经过特有的设计与改造，减少因不确定故障停服的时间，从而对业务使用方来说可以保证其服务的高度可用性”。在生产环境中，往往会存在很多不可预知的故障因素，比如虚拟机宕机、磁盘损坏和网络故障等，因此系统自身的高可用是任何工业级产品所需重点考虑的因素。\n对于消息队列服务来说，考虑到故障切换和业务感知等问题，传统的高可用方式（冷备或者热备）一般都不太适用。在经过多种技术方案对比后，我们发现采用基于 Raft 共识算法的多副本设计方案可以满足我们产品的要求，因此在鉴权认证组件和API计量服务组件中，我们集成了蚂蚁金服开源的 SOFAJRaft 库，实现这两个组件应对单点故障的高可用。\nGitHub 地址：https://github.com/sofastack/sofa-jraft\n一、背景知识：Raft 共识性算法是什么？ Raft 是一种分布式系统中易于理解的共识算法，该协议本质上是 Paxos 算法的精简版，而不同的是依靠 Raft 模块化的拆分以及更加简化的设计，其实现起来更加容易和方便。[1]\n模块化的拆分主要体现在 Raft 把一致性协议划分为如下几部分：\n Leader 选举； Membership 变更； 日志复制； Snapshot。 而更加简化的设计则体现在：Raft 不允许类似 Paxos 中的乱序提交、简化系统中的角色状态（算法定义 Leader、Follower 和 Candidate 三种角色）、限制仅 Leader 可写入、采用随机超时触发 Leader Election 机制来避免“瓜分选票”等等。[2]\n1.1 Raft 算法的整体结构概览 从上面的 Raft 算法整体结构图中可以看出，整个分布式系统中同一时刻有且仅有一个 Leader 角色的节点（如图最右边的服务器），只有 Leader 节点可以接受 Client 发送过来的请求。Leader 节点负责主动与所有 Follower 节点进行网络通信（如图左边两个服务器），负责将本地的日志发送给所有 Follower 节点，并收集分布式系统中多数派的 Follower 节点的响应。此外，Leader 节点，还需向所有 Follower 节点主动发送心跳维持领导地位（即：保持存在感）。\n所以，只要各个节点上的日志保持内容和顺序是一致的，那么节点上的状态机就能以相同的顺序执行相同的命令，这样它们执行的结果也都是一样的。\n1.2 Raft 算法的三种角色及转换 Follower：完全被动，不能发送任何请求，只接受并响应来自 Leader 和 Candidate 的 Message，每个节点启动后的初始状态一般都是 Follower； Leader：处理所有来自客户端的请求、复制 Log 到所有 Follower，并且与 Follower 保持心跳请求； Candidate：节点竞选 Leader 时的状态。Follower 节点在参与选举之前，会将自己的状态转换为 Candidate。 1.3 任期与逻辑时钟概念 时间被划分为多个任期 term（如同总统选举一样），term id 按时间轴单调递增； 每一个任期开始后要做的第一件事都是选举 Leader 节点，选举成功之后，Leader 负责在该任期内管理整个分布式集群，“日志复制”、“通过心跳维护自己的角色”； 每个任期至多只有一个 Leader 节点，也可能没有 Leader (由于“分票”导致)。 1.4 Raft 算法的实际应用实现 目前，Raft 算法已经成熟地应用于诸多知名的开源项目中。业界非常著名的 Etcd(Kubernetes 高可用强一致性的服务发现组件)和 TiKV (高性能开源 KV 存储)均是 Raft 算法的实现。\n二、BC-MQ 基于 Raft 的高可用设计 为满足企业上云和构建万物相连的物联网业务需求，中国移动苏州研发中心结合自身在云计算产品和技术的较多积累，研发了大云消息队列中间件产品 BC-MQ。该产品基于 Apache 开源社区的 RocketMQ 内核，同时结合云端 PAAS 产品架构和消息中间件的应用业务需求进行深度优化和定制化的研发，提供了一款可以满足于云端场景的高性能、高可靠、低延迟和高可用的工业级产品。\n本节从解决原有高可用技术方案的问题视角出发，同时结合选型 SOFAJRaft 库的缘由，将详细阐述 BC-MQ 产品中的安全认证和 API 计量采集服务的高可用设计方案（注：这里不会涉及到安全认证和 API 计量采集组件本身的技术方案细节）。\n2.1 GlusterFS+Keepalived 高可用方案与问题 1. GlusterFS+Keepalived 高可用设计方案 在BC-MQ原有的方案中，多组安全认证服务各自独立部署组建集群，各个安全认证服务相互独立，没有主从关联，服务本身无状态，可水平任意扩展。安全认证服务的高可用依赖于RPC通信的客户端保证，其主要通过负载均衡算法从安全认证服务集群选择一个节点发送RPC请求来实现租户级鉴权认证元数据的获取。在生产环境中，如果出现其中一个安全认证节点宕机不可用时，客户端的RPC通信层能够及时感知并从本地的Node列表中剔除不可用节点。\n集群中有状态的租户级安全认证元数据的强一致性由GlusterFS分布式文件存储的同步机制来保证。安全认证服务组建高可用集群的具体设计方案图如下所示：\n而 BC-MQ 中 API 计量采集服务组件的高可用性则是依靠 Keepalived 组件的冷备模式结合 GlusterFS 分布式文件存储的同步机制共同保证，从而在一定程度上解决了 API 计量采集服务的单点不可用问题。API 计量采集服务的具体高可用设计方案图如下所示：\n2. GlusterFS+Keepalived 高可用方案遇到的问题 初步看上面的这种高可用技术方案挺完美的。但是经过验证和仔细推敲后就发现在生产环境中可能会存在如下几个问题：\n 上面所述的高可用设计方案中引入了 GlusterFS 分布式文件存储系统和 Keepalived 组件，这增加了系统整体的运维复杂度，给运维人员带来很多人工介入排查和部署的工作负担；另一方面，GlusterFS 和 Keepalived 本身的可靠性、稳定性和性能指标等问题也需要软件研发人员重点关注，这增加了系统整体设计的复杂度； 在实际的生产环境中，Keepalived 组件采用冷备方式作为高可用方案需要考虑主机故障宕机后切换到备机的时间成本消耗。在这段时间内，API 计量服务是短暂不可用的。因此，Keepalived 组件的主备切换会造成业务感知影响，导致一些业务的风险发生。 2.2 基于 SOFAJRaft 库的高可用设计方案 由于“GlusterFS+Keepalived”的高可用方案存在上一节阐述的两个问题，所以我们考虑是否可以采用其他的高可用方案来解决这两个问题？目标：即使生产环境出现部分节点故障后， …","date":1565694000,"description":"BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云服务中的最佳应用实践。","dir":"blog/sofa-jraft-user-china-mobile/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a7eb984bdb11d8c0b47133af4c16f48f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-user-china-mobile/","publishdate":"2019-08-13T19:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-user-china-mobile/","summary":"文章摘要：BC-MQ 是中国移动苏州研发中心结合自身在云计算产品和技术的较多积累、自主研发的大云消息队列中间件产品，本文详细解读了 SOFAJRaft 在其消息云","tags":["SOFAJRaft"],"title":"中国移动苏州研发中心消息队列高可用设计之谈 | SOFAStack 用户说","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-user-china-mobile/","wordcount":6179},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 \u0026amp;ldquo; SOFA WEEKLY \u0026amp;rdquo; 的形式回复\n关于 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 的讨论： @龚小涛 提问： \u0026amp;gt; 对于快照部分讲解是对某一刻时间点的数据做的快照吗，然后此快照最新的记录下 logindex term 等信息？\nA：快照里记录的数据不是日志复制的数据，而是状态机执行的结果，这个快照数据保存的动作是由用户通过实现这个接口来实现的： com.alipay.sofa.jraft.StateMachine#onSnapshotSave 。当然，里面的快照里面还包括了一些 index、term 等元信息。所以如果你理解的数据是由状态机执行的结果，那理解是对的。\n 关于快照的解决方案中是对数据集合的快照，这里可以细说下吗？\n A：快照中保存的是用户自定义的状态机的当前的状态，具体内容需要用户自己去实现，你可以看下这个接口： com.alipay.sofa.jraft.StateMachine#onSnapshotSave，比如 Counter 这个 example 中，保存的就是计数器当前的 value。\nSOFAJRaftLab 系列阅读 SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 项目进展 本周发布详情如下：\n发布 SOFARegistry 5.2.1, 主要变更如下： i. 安全修改，升级 Jettyserver 版本到 9.4.17.v20190418. ii. jraft bug 修正版本到1.2.5 iii. 修复 dataServer 启动没有 working 时刻一些操作延迟处理问题 iv. data 重连 meta 逻辑 bug 导致所有 data 无法连接 meta 修改 v. data 从 working 状态变回 init 状态 bug 修改 详细发布报告： https://github.com/sofastack/sofa-registry/releases/tag/v5.2.1\nSOFA 活动推荐 SOFA Meetup #3《从开源技术到产品能力》，本周日我们在广州等你~\n本期活动将为大家带来蚂蚁金服在这些方面的探索和实践，解析 SOFARPC、分布式事务 Seata、无线自动化测试框架 SoloPi 等开源项目的内部大规模落地和社区发展，并且通过可观察性的理念，实现对微服务，Service Mesh 以至未来的 Serverless 架构的应用进行监控，帮助大家应对从应用架构过渡到云原生架构的挑战。\n报名方式：点击“这里”了解活动详情。\n","date":1565337600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190809/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"31aa100cb2b1edaacaa1874644af50ff","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190809/","publishdate":"2019-08-09T16:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190809/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【8/5 - 8/9】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190809/","wordcount":1018},{"author":"力鲲、徐家锋","categories":"SOFAJRaft","content":" SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第六篇，本篇作者徐家锋，来自专伟信息，力鲲，来自蚂蚁金服。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：\u0026amp;lt;SOFA:JRaftLab/\u0026amp;gt;，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n本文的目的是要介绍 SOFAJRaft 在日志复制中所采用的 pipeline 机制，但是作者落笔时突然觉得这个题目有些唐突，我们不应该假设读者理所应当的对日志复制这个概念已经了然于胸，所以作为一篇解析，我觉得还是应该先介绍一下 SOFAJRaft 中的日志复制是要解决什么问题。\n概念介绍 SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法，就不可避免的要对需要达成共识的内容在多个服务器节点之间进行传输，在 SOFAJRaft 中我们将这些内容封装成一个个日志块 (LogEntry)，这种服务器节点间的日志传输行为在 SOFAJRaft 中也就有了专门的术语：日志复制。\n为了便于阅读理解，我们用一个象棋的故事来类比日志复制的流程和可能遇到的问题。\n假设我们穿越到古代，要为一场即将举办的象棋比赛设计直播方案。当然所有电子通讯技术此时都已经不可用了，幸好象棋比赛是一种能用精简的文字描述赛况的项目，比如：“炮二平五”, “马８进７”, “车２退３”等，我们将这些描述性文字称为棋谱。这样只要我们在场外同样摆上棋盘 (可能很大，方便围观)，通过棋谱就可以把棋手的对弈过程直播出来。\n图1 - 通过棋谱直播\n所以我们的直播方案就是：赛场内两位棋手正常对弈，设一个专门的记录员来记录棋手走出的每一步，安排一个旗童飞奔于赛场内外，棋手每走一步，旗童就将其以棋谱的方式传递给场外，这样观众就能在场外准实时的观看对弈的过程，获得同观看直播相同的体验。\n图2 - 一个简单的直播方案\n这便是 SOFAJRaft 日志复制的人肉版，接下来我们完善一下这个“直播系统”，让它逐步对齐真实的日志复制。\n改进1. 增加记录员的数量 假设我们的比赛获得了很高的关注度，我们需要在赛场外摆出更多的直播场地以供更多的观众观看。\n这样我们就要安排更多的旗童来传递棋谱，场外的每一台直播都需要一个旗童来负责，这些旗童不停的在赛场内外奔跑传递棋谱信息。有的直播平台离赛场远一些，旗童要跑很久才行，相应的直播延迟就会大一些，而有些直播平台离得很近，对应的旗童就能很快的将对弈情况同步到直播。\n随着直播场地的增加，负责记录棋局的记录员的压力就会增加，因为他要针对不同的旗童每次提供不同的棋谱内容，有的慢有的快。如果记录员一旦记混了或者眼花了，就会出现严重的直播事故(观众看到的不再是棋手真正的棋局)。\n图4 - 压力很大的记录员\n为此我们要作出一些优化，为每个场外的直播平台安排一个专门的记录员，这样 “赛局-记录员-旗童-直播局” 就构成了单线模式，专人专职高效可靠。\n图5 - “赛局-记录员-旗童-直播棋局”\n改进2. 增加旗童每次传递的信息量 起初我们要求棋手每走一步，旗童就向外传递一次棋谱。可是随着比赛进行，其弊端也逐渐显现，一方面记录员记录了很多棋局信息没有传递出去，以至于不得不请求棋手停下来等待 (不可思议)；另一方面，场外的观众对于这种“卡帧”的直播模式也很不满意。\n所以我们做出改进，要求旗童每次多记几步棋，这样记录员不会积攒太多的待直播信息，观众也能一次看到好几步，而这对于聪明的旗童来说并不是什么难事，如此改进达到了共赢的局面。\n图6 - 旗童批量携带信息\n改进3. 增加快照模式 棋局愈发精彩，应棋迷的强烈要求，我们临时增加了几个直播场地，这时棋手已经走了很多步了，按照我们的常规手段，负责新直播的记录员和旗童需要把过去的每一步都在直播棋盘上还原一遍(回放的过程)，与此同时棋手还在不断下出新的内容。\n从直觉上来说这也是一种很不聪明的方式，所以这时我们采用快照模式，不再要求旗童传递过去的每一步棋谱，而是把当前的棋局图直接描下来，旗童将图带出去后，按照图谱直接摆子。这样新直播平台就能快速追上棋局进度，让观众欣赏到赛场同步的棋局对弈了。\n图7 - 采用快照模式\n改进4. 每一个直播平台用多个旗童传递信息 虽然我们之前已经在改进 2 中增加了旗童每次携带的信息量，但是在一些情况下(棋手下快棋、直播平台很远等)，记录员依然无法将信息及时同步给场外。这时我们需要增加多个旗童，各旗童有次序的将信息携带到场外，这样记录员就可以更快速的把信息同步给场外直播平台。\n图8 - 利用多个旗童传递信息，实现 pipeline 效果\n现在这个人肉的直播平台在我们的逐步改进下已经具备了 SOFAJRaft 日志复制的下面几个主要特点：\n特点1: 被复制的日志是有序且连续的 如果棋谱传递的顺序不一样，最后下出的棋局可能也是完全不同的。而 SOFAJRaft 在日志复制时，其日志传输的顺序也要保证严格的顺序，所有日志既不能乱序也不能有空洞 (也就是说不能被漏掉)。\n图9 - 日志保持严格有序且连续\n特点2: 复制日志是并发的 SOFAJRaft 中 Leader 节点会同时向多个 Follower 节点复制日志，在 Leader 中为每一个 Follower 分配一个 Replicator，专用来处理复制日志任务。在棋局中我们也针对每个直播平台安排一个记录员，用来将对弈棋谱同步给对应的直播平台。\n图10 - 并发复制日志\n特点3: 复制日志是批量的 SOFAJRaft 中 Leader 节点会将日志成批的复制给 Follower，就像旗童会每次携带多步棋信息到场外。\n图11 - 日志被批量复制\n特点4: 日志复制中的快照 在改进 3 中，我们让新加入的直播平台直接复制当前的棋局，而不再回放过去的每一步棋谱，这就是 SOFAJRaft 中的快照 (Snapshot) 机制。用 Snapshot 能够让 Follower 快速跟上 Leader 的日志进度，不再回放很早以前的日志信息，即缓解了网络的吞吐量，又提升了日志同步的效率。\n特点5: 复制日志的 pipeline 机制 在改进 4 中，我们让多个旗童参与信息传递，这样记录员和直播平台间就可以以“流式”的方式传递信息，这样既能保证信息传递有序也能保证信息传递持续。\n在 SOFAJRaft 中我们也有类似的机制来保证日志复制流式的进行，这种机制就是 pipeline。Pipeline 使得 Leader 和 Follower 双方不再需要严格遵从 “Request - Response - Request” 的交互模式，Leader …","date":1565080200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第六篇，本篇作者徐家锋、力鲲。","dir":"blog/sofa-jraft-pipeline-principle/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c88030d7b6620240943e8326565b0ec2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-pipeline-principle/","publishdate":"2019-08-06T16:30:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-jraft-pipeline-principle/","summary":"SOFAStack（Scalable Open Financial Architecture Stack） 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 日志复制 - pipeline 实现剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-pipeline-principle/","wordcount":3903},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答\n同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动\n我们会筛选重点问题通过 \u0026amp;rdquo; SOFA WEEKLY \u0026amp;ldquo; 的形式回复\n@屈冉 提问：\n SOFAJRaft 目前支持 Multi-Raft 嘛?\n A：支持的，可以参考 rheakv 实现，就是用的 multi raft group。\n 好的，另外想问一下，SOFAJRaft 有没有和 Braft 的性能比较数据，或者同类实现的？\n A：这里有一份 Benchmark 数据可以参考一下，我们暂时没有计划和同类实现对比性能：\nhttps://github.com/sofastack/sofa-jraft/wiki/Benchmark-%E6%95%B0%E6%8D%AE\nSOFA 开源系列 SoloPi：支付宝 Android 专项测试工具 | 开源 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源 蚂蚁金服分布式事务开源以及实践 | SOFA 开源 蚂蚁金服开源自动化测试框架 SOFAACTS 蚂蚁金服开源 SOFAJRaft：生产级 Java Raft 算法库 SOFA 项目进展 本周发布详情如下：\n1、发布 SOFATracer 2.4.1\u0026amp;frasl;3.0.6, 主要变更如下：\ni. 升级 Dubbo 版本至 2.7.3.\nii. 修复 Dubbo 插件中相关埋点参数获取问题\niii. 修复 Datasource 埋点中的若干问题\niv. Cheery pick 代码优化至 3.x 分支\n详细发布报告：\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v2.4.1\nhttps://github.com/sofastack/sofa-tracer/releases/tag/v3.0.6\n2、发布 SOFA MOSN v0.6.0，主要变更如下：\ni. Listener 支持配置空闲连接超时关闭\nii. 日志新增 Alertf 接口\niii. 支持 SDS 方式获取证书\niv. Metrics统计与输出优化\nv. IO 协程优化\nvi. 后端模块实现重构，提升了动态更新性能，降低了内存的使用\nvii. racer 模块实现重构，支持更完善的扩展机制\n详细发布报告：\nhttps://github.com/sofastack/sofa-mosn/releases/tag/0.6.0\nSOFA 活动推荐 SOFA Meetup #3 广州站《从开源技术到产品能力》报名进行中~\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 SoloPi 的首秀分享~\n8 月 11 日，我们广州见~\n报名方式：点击“这里”即可报名。\n","date":1564732800,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190802/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4edd066a5855f1a118fd562cfc299571","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190802/","publishdate":"2019-08-02T16:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190802/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【7/29- 8/2】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190802/","wordcount":818},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech\nSOFAStack: https://github.com/sofastack\n本周推荐阅读 大公司开源怎么做？SOFAStack 给出了一个很好的例子 对话鲁直：蚂蚁金服中间件的开源头羊 | 穿山甲专访 SOFAJRaftLab 系列阅读 SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理 SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFA 活动推荐  SOFA Meetup #3 广州站《从开源技术到产品能力》报名开始啦~\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 Soloπ 的首秀分享~\n8 月 11 日，我们广州见~\n报名方式：点击“这里”了解活动详情。\n","date":1564124400,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190726/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"70e3dace7979772fdf90f9f5a47d2e13","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190726/","publishdate":"2019-07-26T15:00:00+08:00","readingtime":1,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190726/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"（含活动报名）SOFA Weekly | 每周精选【7/22 - 7/26】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190726/","wordcount":485},{"author":"潘潘","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#3 广州站-从开源技术到产品能力 活动时间：8 月 11 日周日下午 13 点 活动地点：广州市广电平云 B 塔 15F 活动形式：线下活动 报名方式：https://tech.antfin.com/community/activities/779 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n欢迎 Star 我：https://github.com/sofastack\nSOFA Meetup#3 广州站-从开源技术到产品能力 适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n本期 SOFA Meetup 将带来开源技术：SOFARPC、Seata 模式详解以及发展进程，并拓展分享云原生产品能力，更有无线自动化测试框架 Soloπ 的首秀分享~\n随着应用架构往云原生的方向发展，传统监控手段已经不能满足云原生时代运维的需求，因此，可观察性的理念被引入了 IT 领域。如何通过可观察性的理念，对微服务，Service Mesh 以至未来的 Serverless 架构的应用进行监控， 将是应用架构往云原生迁移过程中的一个重要命题。\n加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n点击即可报名 https://tech.antfin.com/community/activities/779\n议程 时间 环节 分享大纲 分享嘉宾 13:00-13:30 签到 13:30-14:15 《RPC 服务框架 SOFARPC 在蚂蚁金服的发展与进化》 - SOFARPC 在蚂蚁金服的应用现状\n- 协议和通信层的变化与设计\n- 跨机房与弹性的挑战\n- RPC 框架发展中的经验与教训\n- 拥抱开源，SOFARPC 的未来\n 碧远@SOFARPC 开源负责人 14:15-15:00 《蚂蚁金服在云原生架构下的可观察性的探索和实践》 \n- 为什么云原生时代需要可观察性\n- 可观察性的三大支柱\n- 现在社区方案的缺陷\n- 蚂蚁金服对云原生的可观察性的理解及实践\n 苟利@蚂蚁金服中间件团队产品专家 15:00-15:10 茶歇 15:10-15:55 《分布式事务 Seata 三种模式详解》 \n- 分布式事务产生的背景\n- 分布式事务理论基础\n- 蚂蚁金服分布式事务实践\n- 开源分布式事务 Seata 简介(AT，TCC，SAGA)\n 屹远@Seata 核心贡献者 15:55-16:40 《无线自动化测试框架 Soloπ 的跨平台实践》 \n- 移动端自动化测试转向轻量化\n- “Android+iOS”双端核心功能介绍\n- “Android+iOS”双端功能打通介绍\n- 结合云测平台、用例管理、IDE 的自动化测试解决方案\n 茅舍@Soloπ 核心作者\n不溯@Soloπ 核心作者 ","date":1564038000,"description":"SOFA Meetup#3 广州站-从开源技术到产品能力，8 月 11 日周日下午 13 点，广州市广电平云 B 塔 15F 等你。","dir":"activities/sofa-meetup-3/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0e50b11d1a8e52f8cefbac0bb4826ffe","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-3/","publishdate":"2019-07-25T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofa-meetup-3/","summary":"概要 活动主题：SOFA Meetup#3 广州站-从开源技术到产品能力 活动时间：8 月 11 日周日下午 13 点 活动地点：广州市广电平云 B 塔 15F 活动形式：线下活动 报名方式：","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#3 广州站-从开源技术到产品能力","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-3/","wordcount":1067},{"author":"袖扣","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第五篇，本篇作者袖扣，来自蚂蚁金服。\n《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：\u0026amp;lt;SOFA:JRaftLab/\u0026amp;gt;，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/alipay/sofa-jraft\n前言 RheaKV 是首个以 JRaft 为基础实现的一个原生支持分布式的嵌入式键值（key、value）数据库，现在本文将从 RheaKV 是如何利用 MULTI-RAFT-GROUP 的方式实现 RheaKV 的高性能及容量的可扩展性的，从而进行全面的源码、实例剖析。\nMULTI-RAFT-GROUP 通过对 Raft 协议的描述我们知道：用户在对一组 Raft 系统进行更新操作时必须先经过 Leader，再由 Leader 同步给大多数 Follower。而在实际运用中，一组 Raft 的 Leader 往往存在单点的流量瓶颈，流量高便无法承载，同时每个节点都是全量数据，所以会受到节点的存储限制而导致容量瓶颈，无法扩展。\nMULTI-RAFT-GROUP 正是通过把整个数据从横向做切分，分为多个 Region 来解决磁盘瓶颈，然后每个 Region 都对应有独立的 Leader 和一个或多个 Follower 的 Raft 组进行横向扩展，此时系统便有多个写入的节点，从而分担写入压力，图如下：\n此时磁盘及 I/O 瓶颈解决了，那多个 Raft Group 是如何协作的呢，我们接着往下看。\n选举及复制 RheaKV 主要由 3 个角色组成：PlacementDriver（以下成为 PD） 、Store、Region。由于 RheaKV 支持多组 Raft，所以比单组场景多出一个 PD 角色，用来调度以及收集每个 Store 及 Region 的基础信息。\nPlacementDriver PD 负责整个集群的管理调度、Region ID 生成等。此组件非必须的，如果不使用 PD，设置 PlacementDriverOptions 的 fake 属性为 true 即可。PD 一般通过 Region 的心跳返回信息进行对 Region 调度，Region 处理完后，PD 则会在下一个心跳返回中收到 Region 的变更信息来更新路由及状态表。\nStore 通常一个 Node 负责一个 Store，Store 可以被看作是 Region 的容器，里面存储着多个分片数据。Store 会向 PD 主动上报 StoreHeartbeatRequest 心跳，心跳交由 PD 的 handleStoreHeartbeat 处理，里面包含该 Store 的基本信息，比如，包含多少 Region，有哪些 Region 的 Leader 在该 Store 等。\nRegion Region 是数据存储、搬迁的最小单元，对应的是 Store 里某个实际的数据区间。每个 Region 会有多个副本，每个副本存储在不同的 Store，一起组成一个Raft Group。Region 中的 Leader 会向 PD 主动上报 RegionHeartbeatRequest 心跳，交由 PD 的 handleRegionHeartbeat 处理，而 PD 是通过 Region的Epoch 感知 Region 是否有变化。\nRegionRouteTable 路由表组件 MULTI-RAFT-GROUP 的多 Region 是通过 RegionRouteTable 路由表组件进行管理的，可通过 addOrUpdateRegion、removeRegion 进行添加、更新、移除 Region，也包括 Region 的拆分。目前暂时还未实现 Region 的聚合，后面会考虑实现。\n分区逻辑与算法 Shard “让每组 Raft 负责一部分数据。”\n数据分区或者分片算法通常就是 Range 和 Hash，RheaKV 是通过 Range 进行数据分片的，分成一个个 Raft Group，也称为 Region。这里为何要设计成 Range 呢？原因是 Range 切分是按照对 Key 进行字节排序后再做每段每段切分，像类似 scan 等操作对相近 key 的查询会尽可能集中在某个 Region，这个是 Hash 无法支持的，就算遇到单个 Region 的拆分也会更好处理一些，只用修改部分元数据，不会涉及到大范围的数据挪动。\n当然 Range 也会有一个问题那就是，可能会存在某个 Region 被频繁操作成为热点 Region。不过也有一些优化方案，比如 PD 调度热点 Region 到更空闲的机器上，或者提供 Follower 分担读的压力等。\nRegion 和 RegionEpoch 结构如下：\nclass Region { long id; // region id // Region key range [startKey, endKey) byte[] startKey; // inclusive byte[] endKey; // exclusive RegionEpoch regionEpoch; // region term List\u0026amp;lt;Peer\u0026amp;gt; peers; // all peers in the region } class RegionEpoch { // Conf change version, auto increment when add or remove peer long confVer; // Region version, auto increment when split or merge long version; } class Peer { long id; long storeId; Endpoint endpoint; } Region.id：为 Region 的唯一标识，通过 PD 全局唯一分配。\nRegion.startKey、Region.endKey：这个表示的是 Region 的 key 的区间范围 [startKey, endKey)，特别值得注意的是针对最开始 Region 的 startKey，和最后 Region 的 endKey 都为空。\nRegion.regionEpoch：当 Region 添加和删除 Peer，或者 split 等，此时 regionEpoch 就会发生变化，其中 confVer 会在配置修改后递增，version 则是每次有 split 、merge（还未实现）等操作时递增。 …","date":1563955200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第五篇，本篇作者袖扣，来自蚂蚁金服。","dir":"blog/sofa-jraft-rheaKV-multi-raft-group/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fbebe45fe1ffaa4e8f134c2531cde55c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","publishdate":"2019-07-24T16:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft-RheaKV MULTI-RAFT-GROUP 实现分析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/","wordcount":4503},{"author":"SOFA 团队","categories":"SOFA Weekly","content":" SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动\nSOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。\nSOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack\n社区 Big News NO.1 社区新认证一位 Committer\n@SteNicholas 成为 SOFAJRaft Committer。\n主要贡献\n一、贡献了 SOFAJRaft 源码剖析系列一共三篇文章\n 蚂蚁金服生产级 Raft 算法库 SOFAJRaft 存储模块剖析 | SOFAJRaft 实现原理 SOFAJRaft-RheaKV 是如何使用 Raft 的 | SOFAJRaft 实现原理 SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理 二、贡献了 4 个 feature PR\n Multi-raft-group 的手动集群 Leader 平衡实现 实现了 RheaKV 的 CompareAndPut API 实现了 RheaKV 的 putIfAbsent batch 优化 实现了 RheaKV 的 batch delete API 目前，社区已经认证超过四十位 Committer。 感谢对 SOFAStack 的支持和帮助~\n也欢迎你加入 SOFAStack community，指南：\nhttps://github.com/sofastack/community\nSOFARegistryLab 系列阅读 蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路 海量数据下的注册中心 - SOFARegistry 架构介绍 蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼 SOFAChannel 回顾集合 SOFAChannel#7：自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理 SOFAChannel#6：蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理 SOFAChannel#5：给研发工程师的代码质量利器 | SOFAChannel#5 直播整理 SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理 SOFAChannel#3：SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理 SOFAChannel#2：SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理 SOFAChannel#1：从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理 SOFA 项目进展 本周发布详情如下\nSOFAActs 1.0.1 版本发布，主要变更如下：\n 插件兼容性问题修复 详细参考 发布报告\n","date":1563519600,"description":"SOFA WEEKLY | 每周精选，筛选每周精华问答，同步开源进展，欢迎留言互动。","dir":"blog/sofa-weekly-20190719/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"03bd5ad0ca023620792ed7ee60d4c448","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190719/","publishdate":"2019-07-19T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofa-weekly-20190719/","summary":"SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分","tags":["SOFA Weekly"],"title":"SOFA Weekly | 每周精选【7/15 - 7/19】","type":"blog","url":"/sofastack.tech/blog/sofa-weekly-20190719/","wordcount":776},{"author":"枫晟","categories":"CafeDeployment","content":" 本文简单介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。\n相关直播视频以及 PPT 查看地址\n背景介绍 Kubernetes 原生社区 Deployment 和 StatefulSet 解决了“服务节点版本一致性”的问题，并且通过 Rolling Update 实现了滚动升级，提供了基本的回滚策略。对于高可用建设要求不高的“年轻”业务，是一个不错的选择。\n但是，在金融场景下，要解决的场景复杂得多。因此我们在金融分布式架构-云应用引擎（SOFAStack-CAFE，参见《金融级云原生探索实践系列——开篇》）中提出了 CafeDeployment 的云原生模型，致力于解决以下问题：\n1. IP 不可变\n对于很多运维体系建设较为早期的用户，使用的服务框架、监控、安全策略，大量依赖 IP 作为唯一标识而被广泛使用。迁移到 Kubernetes 最大的改变就是 IP 会飘，而这对于他们来说，无异于运维、服务框架的推倒重来。\n2. 金融体系下的高可用\nDeployment/StatefulSet 无法根据特定属性进行差异化部署。而在以同城双活为建设基础的金融领域，为了强管控 Pod 的部署结构（即保证每个机房/部署单元都有副本运行），若通过原生组件进行部署，我们不得不维护多个几乎一模一样的 Deployment/StatefulSet，来保证 Pod 一定会飘到指定机房/部署单元的 node 上。在规模上到一定程度后，这无疑加大了运维管控的复杂度和成本。\n3. 灵活的部署策略\nDeployment 无法控制发布步长，StatefulSet 虽然可以控制步长，但是每次都需要人工计算最新版本需要的副本数并修改 Partition，在多机房/部署单元的情况下，光想想发布要做的操作都脑袋炸裂。\n在面对以上这些问题的时候，我们思考：能不能有一个类似 Deployment 的东西，不仅可以实现副本保持，并且能协助用户管控应用节点部署结构、做 Beta 验证、分批发布，减少用户干预流程，实现最大限度减少发布风险的目标，做到快速止损，并进行修正干预。这就是我们为什么选择定义了自己的资源——CafeDeployment。\n模型定义 CafeDeployment 主要提供跨部署单元的管理功能，其下管理多个 InPlaceSet。每个 InPlaceSet 对应一个部署单元。部署单元是逻辑概念，他通过 Node 上的 label 来划分集群中的节点，而 InPlaceSet 则通过 NodeAffinity 能力，将其下的 Pod 部署到同一个部署单元的机器上。由此实现 CafeDeployment 跨部署单元的管理。\nCafeDeployment 作为多个部署单元的上层，除了提供副本保持，历史版本维护等基本功能，还提供了跨部署单元的分组扩容，分组发布，Pod 调度等功能。模型定义如下：\napiVersion: apps.cafe.cloud.alipay.com/v1alpha1 kind: CafeDeployment metadata: ...... spec: historyLimit: 20 podSetType: InPlaceSet\t# 目前支持底层PodSet：InPlaceSet，ReplicaSet，StatefulSet replicas: 10 selector: matchLabels: instance: productpage name: bookinfo strategy: batchSize: 4\t# 分组发布时，每组更新的Pod数目 minReadySeconds: 30 needWaitingForConfirm: true\t# 分组发布中，每组结束时是否需要等待确认 upgradeType: Beta\t# 目前支持发布策略：Beta发布，分组发布 pause: false template: ...... volumeClaimTemplates:\t# 用于支持statefulSet serviceName:\t# 用于支持statefulSet topology: autoReschedule: enable: true\t# 是否启动Pod自动重调度 initialDelaySeconds: 10 unitType: Cell\t# 部署单元类型：Cell，Zone，None unitReplicas: CellA: 4\t# 固定某部署单元的Pod数目 values:\t# 部署单元 - CellA - CellB 因为我们将大部分的控制逻辑都抽取到上层 CafeDeployment 中，因此我们重新设计了 InPlaceSet，将它做得足够简单，只关注于“InPlace”相关的功能，即副本保持和原地升级，保持 IP 不变的能力，模型定义如下：\nspec: minReadySeconds: 30 replicas: 6 selector: matchLabels: instance: productpage name: bookinfo deployUnit: CellB strategy: partition: 6\t# 控制发布时更新Pod的进度 template: ...... 功能特性 灵活的分组定义 CafeDeployment 支持跨部署单元的分组扩容，Pod 调度，分组发布。分组策略主要分为两种，Beta 分组和 Batch 分组：\n Batch 分组 即根据 BatchSize 将 Pod 分为多个批次，每批中的 Pod 会同时发布。待用户确认（needWaitingForConfirm=true时）无误时，或当前批次所有 Pod 都 ready 后（needWaitingForConfirm=false 时），则会开始进行下一组的发布。\n在分组暂停时，CafeDeployment 会被打上 Annotation: cafe.sofastack.io/upgrade-confirmed=false，用户可通过将 Annotation 的值改为 true，确认当前分组。\n Beta 分组 相比 Batch 发布，会在第一组发布之前多一步 Beta 分组。此组会在每个部署单元内选择一个 Pod 进行发布，以减小错误配置带来的影响。若用户确认无误，可以确认继续，以进入正常的 Batch 发布流程。\n安全的分组扩容和发布能力 分组扩容 为预防不正确的配置造成大量错误 Pod 同时创建，占用大量资源等意外情况出现，CafeDeployment 支持分组扩容，以降低风险。\n在如下配置时，CafeDeployment 会创建两个 InPlaceSet 实例，并开始分组创建（扩容）Pod。\nspec: ...... replicas: 10\t# 副本数为10 strategy: upgradeType: Beta\t# Beta发布 batchSize: 4\t# 每组Pod数为4 needWaitingForConfirm: true\t# 分组暂停 topology: ...... values:\t# …","date":1563454800,"description":"本文根据 SOFAChannel#7 直播分享整理，介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。","dir":"blog/sofa-channel-7-retrospect/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a1185b6bb7c21fd49c4118950c16a2a9","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-7-retrospect/","publishdate":"2019-07-18T21:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-channel-7-retrospect/","summary":"本文简单介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性。 相关直播视频以及 PPT 查看地址 背景介绍 Kubernetes 原生社区 Deployment 和 StatefulSet 解决了“服务节点版本一致性”","tags":["CafeDeployment","SOFAChannel"],"title":"自定义资源 CAFEDeployment 的背景、实现和演进 | SOFAChannel#7 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-7-retrospect/","wordcount":3476},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\n本文为《剖析 | SOFARegistry 框架》第二篇，本篇作者尚彧，是 SOFARegistry 开源负责人。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末附共建列表，欢迎领取共建~\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概述 无论传统的 SOA 还是目前的微服务架构，都离不开分布式的特性，既然服务是分布的就必须解决服务寻址的问题。服务注册中心是这个过程最主要的组件，通过服务注册和服务发现特性收集服务供求关系，解耦服务消费方对服务提供方的服务定位问题。\n服务注册中心的最主要能力是服务注册和服务发现两个过程。服务注册的过程最重要是对服务发布的信息进行存储，服务发现的过程是把服务发布端的所有变化（包括节点变化和服务信息变化）及时准确的通知到订阅方的过程。\n本文详细描述服务注册中心 SOFARegistry 对于服务发现的实现和技术演进过程，主要涉及 SOFARegistry 的服务发现实现模式以及服务数据变化后及时推送到海量客户端感知的优化过程。\n服务发现分类 分布式理论最重要的一个理论是 CAP 原理。关于注册中心的解决方案，根据存储数据一致性维度划分业界有很多实现，比如最有代表性的强一致性 CP 系统 ZooKeeper 和最终一致性 AP 系统 Eureka。SOFARegistry 在数据存储层面采用了类似 Eureka 的最终一致性的过程，但是存储内容上和 Eureka 在每个节点存储相同内容特性不同，采用每个节点上的内容按照一致性 Hash 数据分片来达到数据容量无限水平扩展能力。\n服务端发现和客户端发现 抛开数据存储的一致性，我们从服务发现的实现维度考虑服务注册中心的分类，业界也按照服务地址选择发生主体和负载均衡策略实现主体分为客户端服务发现和服务端服务发现。\n 客户端服务发现：即由客户端负责决定可用的服务实例的\u0026amp;rdquo;位置\u0026amp;rdquo;以及与其相关的负载均衡策略，就是服务发现的地址列表在客户端缓存后由客户端自己根据负载均衡策略进行选址完成最终调用，地址列表定期进行刷新或服务端主动通知变更。最主要的缺点是需要有客户端实现，对于各种异构系统不同语言不同结构的实现必须要进行对应的客户端开发，不够灵活，成本较高。 服务端服务发现：在服务端引入了专门的负载均衡层，将客户端与服务发现相关的逻辑搬离到了负载均衡层来做。客户端所有的请求只会通过负载均衡模块，其并不需要知会微服务实例在哪里，地址是多少。负载均衡模块会查询服务注册中心，并将客户端的请求路由到相关可用的微服务实例上。这样可以解决大量不同实现应用对客户端的依赖，只要对服务端的负载均衡模块发请求就可以了，由负载均衡层获取服务发现的地址列表并最终确定目标地址进行调用。 SOFARegistry 服务发现模式：以客户端服务发现模式为主。这样的模式实现比较直接，因为在同一个公司内部实践面对的绝大多数应用基本上都是同一个语言实现的，客户端实现也只需要确定一套，每个客户端通过业务内嵌依赖方式部署，并且可以根据业务需求进行定制负载均衡策略进行选址调用。当然也会遇到特殊的异构系统，这个随着微服务架构 RPC 调用等通信能力下沉到 Mesh 执行也得到解决，可以在 Mesh 层进行特定的服务注册中心客户端嵌入，选择路由都在这里统一进行，对不同语言实现的系统进行无感知。 服务发现的推、拉模型 服务发现最重要的过程是获取服务发布方地址列表的过程，这个过程可以分为两种实现模式：客户端主动获取的拉模式和服务端主动变更通知的推送模式：\n 拉模式主要是在客户端按照订阅关系发起主动拉取过程。客户端在首次订阅可以进行一次相关服务 ID 的服务列表查询，并拉取到本地缓存，后续通过长轮询定期进行服务端服务 ID 的版本变更检测，如果有新版本变更则及时拉取更新本地缓存达到和服务端一致。这种模式在服务端可以不进行订阅关系的存储，只需要存储和更新服务发布数据。由客户端主动发起的数据获取过程，对于客户端实现较重，需要主动获取和定时轮训，服务端只需要关注服务注册信息的变更和健康情况及时更新内存。这个过程由于存在轮训周期，对于时效性要求不高的情况比较适用。 推模式主要是从服务端发起的主动变更推送。这个模式主要数据压力集中在服务端，对于服务注册数据的变更和提供方，节点每一次变更情况都需要及时准确的推送到客户端，更新客户端缓存。这个数据推送量较大，在数据发布频繁变更的过程，对于大量订阅方的大量数据推送频繁执行，数据压力巨大，但是数据变更信息及时，对于每次变更都准确反映到客户端。 SOFARegistry 服务发现模式采用的是推拉结合方式。客户端订阅信息发布到服务端时可以进行一次地址列表查询，获取到全量数据，并且把对应的服务 ID 版本信息存储在 Session 回话层，后续如果服务端发布数据变更，通过服务 ID 版本变更通知回话层 Session，Session 因为存储客户端订阅关系，了解哪些客户端需要这个服务信息，再根据版本号大小决定是否需要推送给这个版本较旧的订阅者，客户端也通过版本比较确定是否更新本次推送的结果覆盖内存。此外，为了避免某次变更通知获取失败，定期还会进行版本号差异比较，定期去拉取版本低的订阅者所需的数据进行推送保证数据最终一致。 SOFARegistry 服务发现模式 数据分层 前面的文章介绍过 SOFARegistry 内部进行了数据分层，在服务注册中心的服务端因为每个存储节点对应的客户端的链接数据量有限，必须进行特殊的一层划分用于专门收敛无限扩充的客户端连接，然后在透传相应的请求到存储层，这一层是一个无数据状态的代理层，我们称之为 Session 层。\n此外，Session 还承载了服务数据的订阅关系，因为 SOFARegistry 的服务发现需要较高的时效性，对外表现为主动推送变更到客户端，所以推送的主体实现也集中在 Session 层，内部的推拉结合主要是通过 Data 存储层的数据版本变更推送到所有 Session 节点，各个 Session 节点根据存储的订阅关系和首次订阅获取的数据版本信息进行比对，最终确定推送给那些服务消费方客户端。\n触发服务推送的场景 直观上服务推送既然是主动的，必然发生在主动获取服务时刻和服务提供方变更时刻：\n 主动获取：服务订阅信息注册到服务端时，需要查询所有的服务提供方地址，并且需要将查询结果推送到客户端。这个主动查询并且拉取的过程，推送端是一个固定的客户端订阅方，不涉及服务 ID 版本信息判定，直接获取列表进 …","date":1563433200,"description":"本文为《剖析 | SOFARegistry 框架》第二篇，本篇作者尚彧，来自蚂蚁金服。","dir":"blog/sofa-registry-service-discovery-optimization/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f99d259a0c323df2ddaaea719da2f93c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","publishdate":"2019-07-18T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"蚂蚁金服服务注册中心 SOFARegistry 解析 | 服务发现优化之路","type":"blog","url":"/sofastack.tech/blog/sofa-registry-service-discovery-optimization/","wordcount":5056},{"author":"隐秀","categories":"SOFAStack","content":" \u0026amp;gt; KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。\n市场观察 当我们回顾云计算的发展历程，会看到基础架构经历了从物理机到虚拟机，从虚拟机再到容器的演进过程。在这大势之下，应用架构也在同步演进，从单体过渡到多层，再到当下的微服务。在变化的背后，有一股持续的动力，它来自于三个不变的追求：提高资源利用率，优化开发运维体验，以及更好地支持业务发展。\n目前， Serverless 已成为云原生社区关注的重点之一，它的发展也不例外。相比容器技术，Serverless 可以将资源管理的粒度更加细化，使开发者更快上手云原生，并且倡导事件驱动模型支持业务发展。从而帮助用户解决了资源管理复杂、低频业务资源占用等问题；实现面向资源使用，以取代面向资源分配的模式。根据 CNCF 在2018年底基于 2400 人的一份统计报告，已有 38% 的组织正在使用 Serverless 技术，相比 2017 同期增长了 22%。(数据来源：CNCF Survey)\n\u0026amp;gt; 图片来源：Gartner Report: China Summary Translation Evolution of Server Computing - VMs to Containers to Serverless - Which to Use When\n目前市场上，云厂商提供了多种 Serverless 产品和解决方案，大致可划分为：\n 函数计算服务：如 AWS Lambda，特点是以代码片段为单位运行，并对代码风格有一定要求。 面向应用的 Serverless 服务：如 Knative，特点是基于容器服务，并提供了从代码包到镜像的构建能力。 容器托管服务：如 AWS Fargate，特点是以容器镜像为单元运行，但用户仍需感知容器。 从社区来看，CNCF 云原生基金会正通过 Serverless 工作组协调社区讨论并促进规范和标准的形成，工作组产出了 Serverless 白皮书和全景图等重要内容。其中，全景图将目前的生态划分为了平台层，框架层，工具链层和安全层这四个模块。\n\u0026amp;gt; 图片来源：https://landscape.cncf.io/\n落地挑战 在交流过程中，我们发现 Serverless 很好地解决了客户的一些诉求：包括通过 0-1-0 的伸缩能力来提高资源时用率，降低成本；支持代码包出发，从而让客户无感化实现云原生，历史应用无需经过容器化改造；支持灵活的触发器配置，引导用户对应用进行事件驱动的改造，从而适应业务的高速发展等。这些优势，使得 Serverless 在小程序开发的场景下大放异彩。\n同时，对于在企业级应用的生产环境落地 Serverless，各方也有了很多探索和突破。在本周刚结束的 KubeCon China 2019 大会上，Serverless 工作组会议也以此为话题展开了讨论。目前的核心挑战可归纳为：\n平台可迁移\n目前众多平台都推出了自己的 Serverless 标准，包括代码格式、框架和运维工具等，用户既面临较高的学习成本和选择压力，也担心无法在平台之间灵活迁移 Serverless 应用。\n0-M-N 性能\n线上应用对控制请求延迟有严格的要求，因此，用户需要谨慎地验证 Serverless 0-1 冷启动速度、M-N 扩容速度以及稳定性都达到了生产要求。\n调试和监控\n用户对底层资源无感知，只能借助平台能力对应用进行调试和监控，用户需要平台提供强大的日志功能进行排错，和多维度的监控功能时刻了解应用状态。\n事件源集成\n采用 Serverless 架构后，应用往往进行更细粒度的拆分，并通过事件串联。因此用户希望平台能集成大多数通用的事件源，并支持自定义事件，使得触发机制更加灵活。\n工作流支持\n完成某个业务，往往涉及多个 Serverless 应用之间的配合，当数目较多时，用户希望可以用工作流工具来进行统一编排和状态查看，提高效率。\n蚂蚁金服实践 SOFAStack 致力于通过产品技术解决云上客户实际痛点，沉淀蚂蚁金服技术实践，帮助用户以高效、低成本的方式迁移到云原生架构。Serverless 应用服务（Serverless Application Service，简称 SOFA SAS）是一款源自蚂蚁金服实践的一站式 Serverless 平台。SAS 基于 SOFAStack CAFE 云应用引擎 （Cloud Application Fabric Engine 简称 CAFE），CAFE 的容器服务已经通过了 CNCF 的一致性认证，是一个标准的 Kubernetes。\nServerless 应用服务产品在兼容标准 Knative 同时，融入了源自蚂蚁金服实践的应用全生命周期管理能力，提供了 Serverless 引擎管理、应用与服务管理、版本管理与流控、根据业务请求或事件触发较快的 0-M-N-0 自动伸缩、计量、日志及监控等配套能力。同时结合金融云上客户实际痛点，产品独居匠心的提供独占版与共享版两种形态，以及传统代码包、容器镜像与纯函数三种研发模式，以解决用户的不同需求，降低客户准入门槛。\n 一键部署：用户可以通过代码包或容器镜像的方式一键部署应用并在任意时刻测试执行。 引擎管理：SAS 提供了丰富的引擎全生命周期管理、诊断、监测等能力，为独占版客户赋能 Serverless 引擎数据面的全方位管理与运维运营能力。 服务及版本：SAS 提供应用管理、应用服务管理以及版本管理。版本可以采用容器镜像方式部署也可以采用传统VM发布模式下的代码包部署，很多情况下用户代码无需修改也无需编写维护 Dockerfile 即可迁移。 0-M-N：SAS 提供 0-M-N-M-0 的 Serverelss 快速伸缩能力，支持事件触发或流量触发的 0-M，多种指标的 M-N（如 QPS、CPU、MEM 等等） 日志监控计量：产品内置了日志、监控、计量等配套设施能力，帮助用户进行调试和应用状态监控。 流量控制：基于 SOFAMesh，SAS提供基本流控能力，后续会与服务网格进一步深度集成提供大规模多维跨地域及混合云的流控能力。 触发器管理：产品支持基于常见周期以及秒级精度的cron表达式触发器，可关联并触发无服务器应用，后续将支持更多 IaaS、PaaS 管控型与数据型事件。 性能简析：横轴为完全在同一时刻触发冷启的Java应用个数，纵轴为冷启应用的平均与最小耗时。随着压力增大，50个Java应用同一时刻调度加冷启平均耗时2.5秒左右，100个Java应用同一时刻调度冷启平均耗时3-4秒，最短耗时1.5到2秒。\n 性能简析：Pooling 快弹慢缩时序算法，池容量和实际单位时间申请量关系可做到如图所示（蓝色为实际申请量，绿色为池容量）\n 目前产品已顺利支撑生产环境小程序 Serverless 模式。同时通过 0-M-N-M-0 的能力在很大程度上降低了小程序的运营成本。在行业客户领域，某保险公司决定近期迁移部分日结前置和长尾应用到 Serverless 产品平台，这也是我们产品又一个重要突破。未来， …","date":1562828400,"description":"KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。","dir":"blog/serverless-market-challenge/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e2a95cbe3e0343e3908f17bea5a55d70","permalink":"https://sofastack.github.io/sofastack.tech/blog/serverless-market-challenge/","publishdate":"2019-07-11T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/serverless-market-challenge/","summary":"\u0026gt; KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。 市场观察 当我们回顾云计算的发展历程，会看到基础架构经历了从物理机到","tags":["SOFAStack","Serverless"],"title":"Serverless 市场观察和落地挑战","type":"blog","url":"/sofastack.tech/blog/serverless-market-challenge/","wordcount":2537},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，ServiceMesh，Serverless，安全容器等方向，并发挥自己的力量。SOFAStack 作为蚂蚁金服重要的开源项目，最近也与 CNCF 有故事发生。\n 近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nCNCF \u0026amp;amp; CNCF Cloud Native Landscape CNCF(Cloud Native Computing Foundation)，是由 Google 牵头创立的云原生计算开源软件基金会。它致力于云原生(Cloud Native)技术的普及和可持续发展。2016 年 11 月，CNCF 开始维护 Cloud Native Landscape，汇总流行热门的云原生技术与工具，并加以分类，为企业构建云原生体系提供参考，在云生态研发、运维领域具有广泛影响力。\nSOFAStack \u0026amp;amp; CNCF Cloud Native Landscape 蚂蚁金服金融级分布式架构 SOFAStack 中的 3 个项目加入这次最新版本的 Cloud Native Landscape ，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 **SOFATracer ** 和 RPC 服务框架 SOFARPC。\nSOFAMosn Star 一下✨： https://github.com/sofastack/sofa-mosn\nSOFAMosn(Modular Observable Smart Network)，是一款采用 GoLang 开发的 Service Mesh 数据平面代理， 功能和定位类似 Envoy ，旨在提供分布式，模块化，可观察，智能化的代理能力。 SOFAMosn 支持 Envoy 和 Istio 的 API，可以和 Istio 集成，在 SOFAMesh 中，我们使用 SOFAMosn 替代 Envoy。 SOFAMosn 初始版本由蚂蚁金服和阿里大文娱 UC 事业部携手贡献，期待社区一起来参与后续开发，共建一个开源精品项目。\nSOFARPC Star 一下✨： https://github.com/sofastack/sofa-rpc\nSOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有业务相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括Bolt， RESTful ， Dubbo ， H2C 协议进行通信。其中 Bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\nSOFATracer Star 一下✨： https://github.com/sofastack/sofa-tracer\nSOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFAStack 开源家族 SOFAStack™（Scalable Open Financial Architecture Stack）是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n图为 SOFAStack 开源全景图，其中橙色部分为 SOFAStack 包含的开源组件，白色部分为兼容或集成开源社区其它优秀的开源产品\n特别感谢 SOFAStack 开源社区的每一个你 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。 到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期认证了两位社区 Committer，再次感谢开发者和企业的信任和认可，因为你们，SOFAStack 社区才能会更好。\n","date":1562749200,"description":"Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC 加入 CNCF 云原生全景图","dir":"blog/sofastack-projects-joined-cncf-landscape/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"219e8daac9b49b95c7d5afd94d9ee791","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","publishdate":"2019-07-10T17:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","summary":"2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kuberne","tags":["SOFAStack","CNCF","开源"],"title":"蚂蚁金服 3 个项目进入 CNCF 云原生全景图 | 开源","type":"blog","url":"/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/","wordcount":1278},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第四篇，本篇作者力鲲，来自蚂蚁金服。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 在 Raft 算法中，选举是很重要的一部分，所谓选举也就是在多个节点中选出一个 Leader 节点，由他来对外提供写服务 （以及默认情况下的读服务）。\n在剖析源码时，对选举机制的理解经常会遇到两极分化的情况，对于了解 Raft 算法基本原理的同学，阅读源码就是品味实现之巧妙的过程，而对初体验的同学，却会陷入丈二和尚的窘境，仿佛坠入云里雾里。\n为了提升文章的可读性，我还是希望花一部分篇幅讲清楚选举机制的基本原理，以便后面集中注意力于代码实现。下面是一段图文比喻，帮助理解的同时也让整篇文章不至于过早陷入细节的讨论。\n问题1：选举要解决什么 一个分布式集群可以看成是由多条战船组成的一支舰队，各船之间通过旗语来保持信息交流。这样的一支舰队中，各船既不会互相完全隔离，但也没法像陆地上那样保持非常密切的联系，天气、海况、船距、船只战损情况导致船舰之间的联系存在但不可靠。\n舰队作为一个统一的作战集群，需要有统一的共识、步调一致的命令，这些都要依赖于旗舰指挥。各舰船要服从于旗舰发出的指令，当旗舰不能继续工作后，需要有别的战舰接替旗舰的角色。\n图1 - 所有船有责任随时准备接替旗舰\n如何在舰队中，选出一艘得到大家认可的旗舰，这就是 SOFAJRaft 中选举要解决的问题。\n问题2：何时可以发起选举 何时可以发起选举？换句话说，触发选举的标准是什么？这个标准必须对所有战舰一致，这样就能够在标准得到满足时，所有舰船公平的参与竞选。在 SOFAJRaft 中，触发标准就是通信超时，当旗舰在规定的一段时间内没有与 Follower 舰船进行通信时，Follower 就可以认为旗舰已经不能正常担任旗舰的职责，则 Follower 可以去尝试接替旗舰的角色。这段通信超时被称为 Election Timeout （简称 ET）， Follower 接替旗舰的尝试也就是发起选举请求。\n图2 - ET 触发其他船竞选旗舰\n问题3：何时真正发起选举 在选举中，只有当舰队中超过一半的船都同意，发起选举的船才能够成为旗舰，否则就只能开始一轮新的选举。所以如果 Follower 采取尽快发起选举的策略，试图尽早为舰队选出可用的旗舰，就可能引发一个潜在的风险：可能多艘船几乎同时发起选举，结果其中任何一支船都没能获得超过半数选票，导致这一轮选举无果，然后失败的 Follower 们再一次几乎同时发起选举，又一次失败，再选举 again，再失败 again ···\n图3 - 同时发起选举，选票被瓜分\n为避免这种情况，我们采用随机的选举触发时间，当 Follower 发现旗舰失联之后，会选择等待一段随机的时间 Random(0, ET) ，如果等待期间没有选出旗舰，则 Follower 再发起选举。\n图4 - 随机等待时间\n问题4：哪些候选者值得选票 SOFAJRaft 的选举中包含了对两个属性的判断：LogIndex 和 Term，这是整个选举算法的核心部分，也是容易让人产生困惑的地方，因此我们做一下解释：\n Term：我们会对舰队中旗舰的历史进行编号，比如舰队的第1任旗舰、第2任旗舰，这个数字我们就用 Term 来表示。由于舰队中同时最多只能有一艘舰船担任旗舰，所以每一个 Term 只归属于一艘舰船，显然 Term 是单调递增的。 LogIndex：每任旗舰在职期间都会发布一些指令（称其为“旗舰令”，类比“总统令”），这些旗舰令当然也是要编号归档的，这个编号我们用 Term 和 LogIndex 两个维度来标识，表示“第 Term 任旗舰发布的第 LogIndex 号旗舰令”。不同于现实中的总统令，我们的旗舰令中的 LogIndex 是一直递增的，不会因为旗舰的更迭而从头开始计算。 图5 - 总统令 Vs 旗舰令，LogIndex 稍有区别\n所有的舰船都尽可能保存了过去从旗舰接收到的旗舰令，所以我们选举的标准就是哪艘船保存了最完整的旗舰令，那他就最有资格接任旗舰。具体来说，参与投票的船 V 不会对下面两种候选者 C 投票：一种是 lastTermC \u0026amp;lt; lastTermV；另一种是 (lastTermV == lastTermC) \u0026amp;amp;\u0026amp;amp; (lastLogIndexV \u0026amp;gt; lastLogIndexC)。\n稍作解释，第一种情况说明候选者 C 最后一次通信过的旗舰已经不是最新的旗舰了，至少比 V 更滞后，所以它所知道的旗舰令也不可能比 V 更完整。第二种情况说明，虽然 C 和 V 都与同一个旗舰有过通信，但是候选者 C 从旗舰处获得的旗舰令不如 V 完整 (lastLogIndexV \u0026amp;gt; lastLogIndexC)，所以 V 不会投票给它。\n图6 - Follower 船 b 拒绝了船 c 而投票给船 a，船 a 旗舰令有一个空白框表示“第 Term 任旗舰”没有发布过任何旗舰令\n问题5：如何避免不够格的候选者“捣乱” 如上一小节所说，SOFAJRaft 将 LogIndex 和 Term 作为选举的评选标准，所以当一艘船发起选举之前，会自增 Term 然后填到选举请求里发给其他船只 （可能是一段很复杂的旗语），表示自己竞选“第 Term + 1 任”旗舰。\n这里要先说明一个机制，它被用来保证各船只的 Term 同步递增：当参与投票的 Follower 船收到这个投票请求后，如果发现自己的 Term 比投票请求里的小，就会自觉更新自己的 Term 向候选者看齐，这样能够很方便的将 Term 递增的信息同步到整个舰队中。\n图7 - Follower 船根据投票请求更新自己的 Term\n但是这种机制也带来一个麻烦，如果一艘船因为自己的原因没有看到旗舰发出的旗语，他就会自以为是的试图竞选成为新的旗舰，虽然不断发起选举且一直未能当选（因为旗舰和其他船都正常通信），但是它却通过自己的投票请求实际抬升了全局的 Term，这在 SOFAJRaft 算法中会迫使旗舰 stepdown （从旗舰的位置上退下来）。\n图8 - 自以为是的捣乱者，迫使旗舰 stepdown\n所以我们需要一种机制阻止这种“捣乱”，这就是预投票 (pre-vote) 环节。候选者在发起投票之前，先发起预投票，如果没有得到半数以上节点的反馈，则候选者就会识趣的放弃参选，也就不会抬升全局的 Term。\n图9 - Pre-vote 预 …","date":1562742000,"description":"本文为《剖析 | SOFAJRaft 实现原理》第四篇，本篇作者力鲲，来自蚂蚁金服","dir":"blog/sofa-jraft-election-mechanism/","fuzzywordcount":3200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e40fefafd980ac2308a3ba6f3fda9cdd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-election-mechanism/","publishdate":"2019-07-10T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-jraft-election-mechanism/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 选举机制剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-election-mechanism/","wordcount":3152},{"author":"SOFAStack","categories":"SOFAStack","content":" 本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。\n 2019 年 6 月 25 日，在 KubeCon China 2019，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，Service Mesh，Serverless，安全容器等方向，并发挥自己的力量。\n在本次大会，蚂蚁金服也与数百名云原生爱好者用五个小时搭建了一个云原生的电商平台，具体怎么做？希望本文能提供一些思路。\n近二十年技术发展：从集中式架构到云原生架构 过去的十几年里，技术发生了翻天覆地的变化，先来简单回顾下：在二十一世纪初，大部分企业的应用还处于集中式架构。这个阶段企业开始做一些信息化的建设工作，典型的一些技术例如集群部署（Tomcat 集群、Weblogic 集群）来保证系统的高可用，以及采购 IOE（IBM，Oracle，EMC）等这些商业化的软硬件产品，通过更高的配置、更好的性能等方式来抗住业务的增长。\n慢慢的，随着公司规模的扩大，集中式架构已经不足以再支撑复杂的业务系统，很多企业开始做一些系统拆分的改造，典型的技术例如 SOA 化。当系统拆分后，就不再需要使用之前昂贵的小型机去部署服务，慢慢的虚拟机的部署方式变成了主流。同样的，服务化后数据库和存储也不再必须采用商业化软硬件的解决方案，企业转为一些开源的解决方案，例如把 Oracle 换成了 MySQL。\n系统的拆分虽然可以带来很多好处，例如使业务内聚，系统之间松耦合，方便快速迭代等。但是随之带来的问题也很明显，例如拆分后系统越来越多，系统间的交互也会变得更加复杂，调用链路变长可能引起性能问题，分布式后数据存储等数据一致性也有不少挑战，还有服务化后带来资源分配、隔离等问题。这时候一些虚拟化和容器化的技术开始涌现，典型技术就是 OpenStack 和 Docker，OpenStack 帮助我们解决了 IaaS 层的建设与管理问题，而 Docker 给了我们资源隔离的最佳实践，但这些并没有解决掉运维复杂的一些问题。\n而近几年，新的云原生的一些技术产品和理念开始出现，例如 Kubernetes、Service Mesh、Serverless 等，这些可以解决应用部署、运维复杂的一些实际问题。\n技术发展下的蚂蚁金服 蚂蚁金服从 2007 年开始从集中式架构走向分布式架构。我们把过去十多年的技术演进过程中自主研发的一套金融级分布式架构沉淀成为 SOFAStack™（Scalable Open Financial Architecture Stack）。\n从 2007 年到 2012 年，蚂蚁金服完成所有业务系统的模块化、服务化改造。通过 TCC 模式解决了服务化、数据拆分等带来的数据一致性的问题，通过注册中心解决了服务单点的问题。\n在完成服务化改造后，随着服务集群的增大，系统的伸缩性遇到了瓶颈，另外为了满足金融级的属性，蚂蚁金服对系统可用性、数据一致性提出了更高的要求。蚂蚁金服从 2013 年开始摸索出了一套单元化的思想，并基于此，推出了同城双活、异地多活、弹性调度等能力，保证业务不停机，数据不丢失。\n再之后随着国内互联网金融的崛起、蚂蚁金服的国际化，蚂蚁金服也将自己的能力和技术开放出来，在金融云上以云产品的形式存在，开发者可以基于此快速搭建金融级能力的分布式系统，同时我们也将内部的一些实践开源出来。\n从 2017 年开始，我们注意到云原生的理念正在快速发展，面对云原生带来的机会和改变，蚂蚁金服的策略是积极拥抱云原生。 因为云原生带来的思想和理念刚好可以用来解决蚂蚁金服内部遇到的一些场景和问题。\n例如 Service Mesh 可以解决中间件等基础能力下层的问题，Serverless 可以解决研发效能的问题，可以让业务开发更专注于业务。这些新的技术和理念蚂蚁金服都会在内部探索并在生产落地，最近我们在深圳 GIAC 首次分享了大规模落地的实践总结，蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录。同时，我们也会将这些云原生落地实践开源出来，并和社区一起共同推进和建设金融级的云原生标准。\nSOFAStack 开源版本： 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期也认证了两位社区 Committer，这里想再次感谢开发者和企业的信任和认可，我们将持续优化和扩大开源版图。\n我们看下这张图，这里可以看到 SOFAStack 体系下开源了很多微服务相关的技术组件，例如 SOFABoot、SOFARPC 等，我们也和社区其它优秀的开源产品进行了兼容或者集成，利用这些组件可以快速的搭建出金融级分布式架构系统。开源的源码可以在这张图下面的 Github 地址上找到。本次的 Workshop 我们就会利用到开源的一些技术组件。\nSOFAStack 云产品： 上图是云上 SOFAStack 的架构图，我们可以看到 SOFAStack 商业化对外输出的是完整的解决方案。支撑解决方案的就是本次要体验的分布式中间件和云应用引擎等等能力。除此之外还有完善的研发效能平台服务以及技术风险防控平台。关于这部分内容，在本次下午场会有更详细的介绍和体验。\nLet\u0026amp;rsquo;s get started! 刚聊了这么多，大家是不是想动手试试了呢？本次 Demo 将带领大家综合利用开源版本的 SOFAStack 和云上产品，五小时实现一个在线电商平台。\n下面简单介绍下本次 Workshop 的内容，如下图：\n上午\n 构建基础电商平台（书店） ，并改造为微服务架构； 基于 SOFABoot 动态模块能力实时的电商平台（书店）增加智能推荐的能力； 用分布式事务 Seata 来解决微服务拆分后的分布式事务的问题，保证购买和余额的数据一致性； 下午\n 通过 Serverless 快速上云，利用 SOFA SAS 发布书店到云环境上，根据流量自动扩缩容； 通过 Service Mesh 的方式来实现精度灰度和流控的能力； 这是提到的是在线书店的系统架构图，最上面是部署好的一些基础设施，包括注册中心 SOFARegistry，服务管控台 SOFADashboard，监控度量 SOFALookout 等，我们已经提前准备好了这部分内容。\n下面就是业务的内容。为了方便，我们不再做前后端分类部署，本次大家只需要操作 2 个应用：\n左边是网页系统和库存系统，提供库存操作服务，右边是账务系统，提供余额相关服务，当用户的请求进来时，库存系统需要通过 RPC 调到账务系统。\n另外库存服务和余额服务分别对应的是独立的数据库，这个后面会用分布式事务 Seata 去解决分布式事务的问题。\nSOFAStack Cloud …","date":1562742000,"description":"本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。","dir":"blog/sofastack-cloud-native-workshop-show/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bed45f24a92c60ca5b141952abdc2049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","publishdate":"2019-07-10T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","summary":"本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理，文末包含文档、PPT 地址，欢迎试用和提出建议。 2019 年 6 月 25 日，在 KubeCon China 2019，全球知名开源组织云原生计","tags":["分布式事务","SOFABoot","Service Mesh","开源","Seata"],"title":"五小时构建云原生电商平台 | KubeCon SOFAStack Workshop 详解","type":"blog","url":"/sofastack.tech/blog/sofastack-cloud-native-workshop-show/","wordcount":2648},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 活动时间：7 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 在 6 月 KubeCon 大会期间，蚂蚁金服正式宣布加入了 CNCF 成为黄金会员，同时 SOFAStack-CAFE 云应用引擎产品也通过了 K8S 一致性认证，旨在向广大金融机构提供云原生的可落地路径。\n为满足金融级云原生发布部署、变更管控场景对于可灰度、可监控、可应急的需求，SOFAStack 产品研发团队在 Kubernetes 基础上实现了自定义资源 CAFEDeployment ，它能够通过可靠而灵活的分发、风险控制的部署策略以及高性能的原地升级更新扩展部署能力。它尤其消除了金融服务行业所面临的技术障碍，使用户能够专心发展核心业务。\n与 Kubernetes 原生工作负载对象 Deployment 所提供的简洁轻量的滚动发布相比，CAFEDeployment 旨在满足金融场景对分批发布、多活容灾、原地升级等方面的诉求。\n7 月 18 日周四晚 7 点，将邀请 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人 枫晟 为大家分享《扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进》。\n在此次分享中，将介绍对此 Kubernetes 扩展能力的相关观点主张、产品探索和实际演示。\n| 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/737\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 枫晟 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人\n本期分享大纲： Kubernetes Deployment 发展历史与现状 Kubernetes Deployment 在互联网金融云场景下的问题与挑战 CafeDeployment 适配互联网金融发布的工作负载 CafeDeployment 的运行机制 CafeDeployment 功能演示 嘉宾 SOFAGirl 主持人 枫晟 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人 ","date":1562573400,"description":"7 月 18 日周四晚 7 点，线上直播第 7 期。","dir":"activities/sofa-channel-7/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"51c929733c988190de480a3a0dc5e735","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-7/","publishdate":"2019-07-08T16:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-7/","summary":"概要 活动主题：SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进 活动时间：7 月 18 日周四晚 7 点 活动形式","tags":["SOFAChannel","CAFEDeployment"],"title":"SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进","type":"activities","url":"/sofastack.tech/activities/sofa-channel-7/","wordcount":813},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，ServiceMesh，Serverless，安全容器等方向，并发挥自己的力量。SOFAStack 作为蚂蚁金服重要的开源项目，最近也与 CNCF 有故事发生。\n 近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nCNCF \u0026amp;amp; CNCF Cloud Native Landscape CNCF(Cloud Native Computing Foundation)，是由 Google 牵头创立的云原生计算开源软件基金会。它致力于云原生(Cloud Native)技术的普及和可持续发展。2016 年 11 月，CNCF 开始维护 Cloud Native Landscape，汇总流行热门的云原生技术与工具，并加以分类，为企业构建云原生体系提供参考，在云生态研发、运维领域具有广泛影响力。\nSOFAStack \u0026amp;amp; CNCF Cloud Native Landscape 蚂蚁金服金融级分布式架构 SOFAStack 中的 3 个项目加入这次最新版本的 Cloud Native Landscape，分别是 Service Mesh 数据平面代理 SOFAMosn 、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。\nSOFAMosn Star 一下✨：https://github.com/sofastack/sofa-mosn\nSOFAMosn(Modular Observable Smart Network)，是一款采用 GoLang 开发的 Service Mesh 数据平面代理， 功能和定位类似 Envoy ，旨在提供分布式，模块化，可观察，智能化的代理能力。 SOFAMosn 支持 Envoy 和 Istio 的 API，可以和 Istio 集成，在 SOFAMesh 中，我们使用 SOFAMosn 替代 Envoy。 SOFAMosn 初始版本由蚂蚁金服和阿里大文娱 UC 事业部携手贡献，期待社区一起来参与后续开发，共建一个开源精品项目。\nSOFARPC Star 一下✨：https://github.com/sofastack/sofa-rpc\nSOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有业务相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括Bolt， RESTful ， Dubbo ， H2C 协议进行通信。其中 Bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\nSOFATracer Star 一下✨：https://github.com/sofastack/sofa-tracer\nSOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\nSOFAStack 开源家族 SOFAStack™（Scalable Open Financial Architecture Stack）是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n图为 SOFAStack 开源全景图，其中橙色部分为 SOFAStack 包含的开源组件，白色部分为兼容或集成开源社区其它优秀的开源产品\n特别感谢 SOFAStack 开源社区的每一个你 2018 年 4 月 19 日正式宣布逐步开源 SOFAStack，开源的策略是 Open Core，也就是把核心的接口和实现都开源出来，内部保留老的兼容代码。到现在为止差不多 1 年 2 个月的时间，已经开源了十几个项目，累计超过 25,600 Star，120 多位贡献者， 以及 30 多家生产用户，近期认证了两位社区 Committer，再次感谢开发者和企业的信任和认可，因为你们，SOFAStack 社区才能会更好。\n文中涉及的相关链接：\n SOFAMosn：https://github.com/sofastack/sofa-mosn SOFARPC：https://github.com/sofastack/sofa-rpc SOFATracer：https://github.com/sofastack/sofa-tracer SOFAMesh：https://github.com/sofastack/sofa-mesh ","date":1562569200,"description":"近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入。","dir":"blog/sofastack-cncf-cloud-native-landscape/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7146cdd7e74b9901a8ac20cb3e80cf6e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","publishdate":"2019-07-08T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","summary":"2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kuberne","tags":["SOFAStack"],"title":"蚂蚁金服 3 个项目进入 CNCF 云原生全景图 | 开源","type":"blog","url":"/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/","wordcount":1590},{"author":"SOFAStack","categories":"SOFAStack","content":" 2019 年 7 月 3 日，在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开源技术创新奖（自主研发）。云计算开源产业大会由中国信息通信研究院主办，是中国云计算开源领域最权威和专业的行业盛会。\n本次大会上，中国信息通信研究院还发布了《混合云白皮书（2019年）》，该白皮书梳理了混合云的最新发展现状、关键能力、应用案例和技术发展趋势。基于完全自主研发的 SOFAStack 金融级分布式架构的网商银行三地五中心异地多活部署方案被作为典型应用案例入选其中。\n完全自主研发的金融级分布式架构 SOFAStack SOFAStack 是蚂蚁金服完全自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，如微服务研发框架、RPC 框架、服务注册中心、分布式定时任务、限流/熔断框架、动态配置推送、分布式链路追踪、Metrics 监控度量、分布式高可用消息队列、分布式事务框架和分布式数据库代理层等。\n据了解，经过数代架构演进和“双十一”考验的 SOFAStack，已于 2018 年 4 月正式对外开源，仅一年时间，SOFAStack 所有相关的开源代码，累计获得 16,000+ 个 Star，并有 110+ 个代码贡献者参与其中。\nSOFAStack 助力客户数字化转型 作为一套分布式架构的完整的解决方案，SOFAStack 在真实的金融场景里锤炼出不少最佳实践。\n2017 年 10 月，SOFAStack 与南京银行共同打造出“鑫云+”互金开放平台。该平台具备高性能承载、敏捷开发、强数据一致性和容灾能力等特性，从而使得南京银行互金核心系统在贷款交易处理能力、成本控制和对接效率都得到了极大的提升。南京银行与互联网平台合作开展线上业务仅一年时间，业务量就已经达到了过去十年传统线下消费金融业务的总和。南京银行“鑫云+”平台上线后，业务快速增长，贷款交易处理量增长了数倍。\n据介绍，SOFAStack 还帮助中国人保健康打造行业领先的互联网保险云核心业务系统，助力网商银行成为中国第一家将核心系统架构在金融云上的银行。\nSOFAStack 引领开源技术创新 2019 年 6 月 25 日，蚂蚁金服正式成为 CNCF 云原生计算基金会黄金会员，SOFAStack 云应用引擎产品 CAFE 已通过 CNCF 一致性认证，积极拥抱云原生的同时，满足严苛金融业务场景需求、保障金融技术风险。\n蚂蚁金服是金融级云原生的首倡者，主张金融级的云原生容器产品必须拥有稳定性与高可用保障、无限弹性扩展、运行时安全的能力，这些理念也集中体现在蚂蚁金服的金融级分布式开源项目 SOFAStack 里。\n蚂蚁金服一直积极参与开源社区共建。截至目前，蚂蚁金服已经有 400 多个开源项目。除了 SOFAStack 系列，Ant Design、SQLFlow、EggJS、Seata（与阿里巴巴共建）等也成为社区热门。\n蚂蚁金服金融科技产品技术总监杨冰表示：“开源是一种可以使客户和上下游产业共同参与和发展的可行模式，是个共赢的模式。在贡献蚂蚁金服的技术沉淀给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。只有开放才能求同存异，共同发展。”\n","date":1562223600,"description":"在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开源技术创新奖（自主研发）。","dir":"blog/sofastack-2019-oscar/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"21da7fc5e118681336c84d2dc46fe6bb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-2019-oscar/","publishdate":"2019-07-04T15:00:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/blog/sofastack-2019-oscar/","summary":"2019 年 7 月 3 日，在 2019 云计算开源产业大会上，蚂蚁金服自主研发的金融级分布式架构 SOFAStack（Scalable Open Financial Architecture Stack）荣获 OSCAR 尖峰开","tags":["SOFAStack"],"title":"蚂蚁金服 SOFAStack 荣获云计算开源产业大会尖峰开源技术创新奖","type":"blog","url":"/sofastack.tech/blog/sofastack-2019-oscar/","wordcount":1223},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第三篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 线性一致读是在分布式系统中实现 Java volatile 语义，当客户端向集群发起写操作的请求并且获得成功响应之后，该写操作的结果要对所有后来的读请求可见。实现线性一致读常规手段是走 Raft 协议，将读请求同样按照 Log 处理，通过日志复制和状态机执行获取读结果返回给客户端，SOFAJRaft 采用 ReadIndex 替代走 Raft 状态机的方案。本文将围绕 Raft Log Read，ReadIndex Read 以及 Lease Read 等方面剖析线性一致读原理，阐述 SOFAJRaft 如何使用 ReadIndex 和 Lease Read 实现线性一致读：\n 什么是线性一致读？共识算法只能保证多个节点对某个对象的状态是一致的，以 Raft 为例只能保证不同节点对 Raft Log 达成一致，那么 Log 后面的状态机的一致性呢？ 基于 ReadIndex 和 Lease Read 方式 SOFAJRaft 如何实现高效的线性一致读？ 线性一致读 什么是线性一致读? 所谓线性一致读，一个简单的例子是在 t1 的时刻我们写入了一个值，那么在 t1 之后，我们一定能读到这个值，不可能读到 t1 之前的旧值(想想 Java 中的 volatile 关键字，即线性一致读就是在分布式系统中实现 Java volatile 语义)。简而言之是需要在分布式环境中实现 Java volatile 语义效果，即当 Client 向集群发起写操作的请求并且获得成功响应之后，该写操作的结果要对所有后来的读请求可见。和 volatile 的区别在于 volatile 是实现线程之间的可见，而 SOFAJRaft 需要实现 Server 之间的可见。\n如上图 Client A、B、C、D 均符合线性一致读，其中 D 看起来是 Stale Read，其实并不是，D 请求横跨 3 个阶段，而 Read 可能发生在任意时刻，所以读到 1 或 2 都行。\nRaft Log read 实现线性一致读最常规的办法是走 Raft 协议，将读请求同样按照 Log 处理，通过 Log 复制和状态机执行来获取读结果，然后再把读取的结果返回给 Client。因为 Raft 本来就是一个为了实现分布式环境下线性一致性的算法，所以通过 Raft 非常方便的实现线性 Read，也就是将任何的读请求走一次 Raft Log，等此 Log 提交之后在 apply 的时候从状态机里面读取值，一定能够保证这个读取到的值是满足线性要求的。\n当然，因为每次 Read 都需要走 Raft 流程，Raft Log 存储、复制带来刷盘开销、存储开销、网络开销，走 Raft Log不仅仅有日志落盘的开销，还有日志复制的网络开销，另外还有一堆的 Raft “读日志” 造成的磁盘占用开销，导致 Read 操作性能是非常低效的，所以在读操作很多的场景下对性能影响很大，在读比重很大的系统中是无法被接受的，通常都不会使用。\n在 Raft 里面，节点有三个状态：Leader，Candidate 和 Follower，任何 Raft 的写入操作都必须经过 Leader，只有 Leader 将对应的 Raft Log 复制到 Majority 的节点上面认为此次写入是成功的。所以如果当前 Leader 能确定一定是 Leader，那么能够直接在此 Leader 上面读取数据，因为对于 Leader 来说，如果确认一个 Log 已经提交到大多数节点，在 t1 的时候 apply 写入到状态机，那么在 t1 后的 Read 就一定能读取到这个新写入的数据。\n那么如何确认 Leader 在处理这次 Read 的时候一定是 Leader 呢？在 Raft 论文里面，提到两种方法：\n ReadIndex Read Lease Read ReadIndex Read 第一种是 ReadIndex Read，当 Leader 需要处理 Read 请求时，Leader 与过半机器交换心跳信息确定自己仍然是 Leader 后可提供线性一致读：\n Leader 将自己当前 Log 的 commitIndex 记录到一个 Local 变量 ReadIndex 里面； 接着向 Followers 节点发起一轮 Heartbeat，如果半数以上节点返回对应的 Heartbeat Response，那么 Leader就能够确定现在自己仍然是 Leader； Leader 等待自己的 StateMachine 状态机执行，至少应用到 ReadIndex 记录的 Log，直到 applyIndex 超过 ReadIndex，这样就能够安全提供 Linearizable Read，也不必管读的时刻是否 Leader 已飘走； Leader 执行 Read 请求，将结果返回给 Client。 使用 ReadIndex Read 提供 Follower Read 的功能，很容易在 Followers 节点上面提供线性一致读，Follower 收到 Read 请求之后：\n Follower 节点向 Leader 请求最新的 ReadIndex； Leader 仍然走一遍之前的流程，执行上面前 3 步的过程(确定自己真的是 Leader)，并且返回 ReadIndex 给 Follower； Follower 等待当前的状态机的 applyIndex 超过 ReadIndex； Follower 执行 Read 请求，将结果返回给 Client。 不同于通过 Raft Log 的 Read，ReadIndex Read 使用 Heartbeat 方式来让 Leader 确认自己是 Leader，省去 Raft Log 流程。相比较于走 Raft Log 方式，ReadIndex Read 省去磁盘的开销，能够大幅度提升吞吐量。虽然仍然会有网络开销，但是 Heartbeat 本来就很小，所以性能还是非常好的。\nLease Read 虽然 ReadIndex Read 比原来的 Raft Log Read 快很多，但毕竟还是存在 Heartbeat 网络开销，所以考虑做更进一步的优化。Raft 论文里面提及一种通过 Clock + Heartbeat 的 Lease Read  …","date":1562050800,"description":"本文为《剖析 | SOFAJRaft 实现原理》第三篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-jraft-linear-consistent-read-implementation/","fuzzywordcount":4800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cfa43268e0ca8424ff44bd4397f720b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","publishdate":"2019-07-02T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 线性一致读实现剖析 | SOFAJRaft 实现原理","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/","wordcount":4732},{"author":"绍辉","categories":"Seata","content":" 获取本次分享完整 PPT：下载地址\n本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。详细讲解了在分布式架构演进中，蚂蚁金服面对的跨服务、跨数据库的业务数据一致性问题以及应对措施，并分享了分布式事务 Seata 的 AT、TCC、Saga 和 XA 四种模式。\nSeata：https://github.com/seata/seata\n一、自研分布式事务解决数据一致性问题 1.1 分布式事务问题产生原因 1.1.1 数据库的水平拆分 蚂蚁金服的业务数据库起初是单库单表，但随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。所以我们对数据库进行了水平拆分，将原单库单表拆分成数据库分片。\n如下图所示，分库分表之后，原来在一个数据库上就能完成的写操作，可能就会跨多个数据库，这就产生了跨数据库事务问题。\n1.1.2 业务服务化拆分 在业务发展初期，“一块大饼”的单业务系统架构，能满足基本的业务需求。但是随着业务的快速发展，系统的访问量和业务复杂程度都在快速增长，单系统架构逐渐成为业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。\n如下图所示，蚂蚁金服按照面向服务（SOA）的架构的设计原则，将单业务系统拆分成多个业务系统，降低了各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。\n业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，如何保证多个服务间的数据一致性成为一个难题。\n1.2 蚂蚁金服遇到的数据一致性问题 在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。在分布式网络环境下，我们无法保障所有服务、数据库都百分百可用，一定会出现部分服务、数据库执行成功，另一部分执行失败的问题。\n当出现部分业务操作成功、部分业务操作失败时，业务数据就会出现不一致。以金融业务中比较常见的“转账”场景为例：\n如下图所示，在支付宝的“转账”操作中，要分别完成 4 个动作：\n 创建交易订单； 创建支付订单； A 账户扣钱； B 账户加钱； 而完成以上操作要分别访问 3 个服务和 4 个数据库。\n在分布式环境下，肯定会出现部分操作成功、部分操作失败的问题，比如：A 账户的钱扣了，但是 B 账户的钱没加上，这就造成了资金损失，影响资金安全。\n在金融业务场景下，我们必须保证“转账”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象。\n为了解决跨数据库、跨服务的业务数据一致性问题，蚂蚁金服自主研发了分布式事务中间件。\n从 2007 年开始做分布式事务并支持双十一，至今已经有 12 年。\n2013 年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014 年，蚂蚁金服分布式事务中间件 DTX(Distributed Transaction-eXtended)开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户。在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。所以在 2015 年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务（Distributed Transaction-eXtended，简称 DTX）链接：\nhttps://tech.antfin.com/products/DTX\n二、投入开源社区，共建开源分布式事务 Seata  2.1 分布式事务 Seata 介绍 Seata（Simple Extensible Autonomous Transaction Architecture，简单可扩展自治事务框架）是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。Seata 开源半年左右，目前已经有接近一万 star，社区非常活跃。我们热忱欢迎大家参与到 Seata 社区建设中，一同将 Seata 打造成开源分布式事务标杆产品。\nSeata：https://github.com/seata/seata\n2.2 分布式事务 Seata 产品模块 如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。\n在 Seata 中，分布式事务的执行流程：\n TM 开启分布式事务（TM 向 TC 注册全局事务记录）； 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）； TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）； TC 汇总事务信息，决定分布式事务是提交还是回滚； TC 通知所有 RM 提交/回滚 资源，事务二阶段结束。 2.3 分布式事务 Seata 解决方案 Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。\n2.3.1 AT 模式 今年 1 月份，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。\nAT 模式如何做到对业务的无侵入 ： 一阶段： 在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。\n 二阶段提交： 二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。\n 二阶段回滚： 二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。\nAT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。\n2.3.2 TCC 模式 2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段 执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。\nTCC 三个方法描述：\n Try： …","date":1562050800,"description":"本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。","dir":"blog/seata-distributed-transaction-deep-dive/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d87c4d85b8c16bfc24a0b9bea52b604d","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","publishdate":"2019-07-02T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","summary":"获取本次分享完整 PPT：下载地址 本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。详细讲解了","tags":["分布式事务","实践","开源","Seata"],"title":"Seata 分布式事务实践和开源详解 | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/seata-distributed-transaction-deep-dive/","wordcount":5775},{"author":"响风","categories":"SOFALookout","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23195297，不错过每场直播。\n 大家好，我是响风，来自蚂蚁金服， 现在是 SOFALookout 的开源负责人。本期 SOFAChannel 我给大家带来主题是《轻量级监控分析系统 SOFALookout 原理讲解和功能演示》的分享。本期的讲解内容如下将从以下四个部分展开：\n 监控预警基本概念介绍 SOFALookout 的客户端使用（包括系统设计简介与实现） SOFALookout 的服务端使用（包括系统设计简介与实现） SOFALookout 发展规划 欢迎大家 Star 我，SOFALookout：https://github.com/sofastack/sofa-lookout\n1 监控预警基本概念介绍 1.1 什么是 SOFALookout 现在我们开始第一部分，先介绍一些基本概念。6 月初，SOFALookout 服务端开源，具体内容可以查看相关文章：蚂蚁金服轻量级监控分析系统 SOFALookout 服务端开源，SOFALookout 客户端在之前也已经开源。目前整个系统是真正地可以玩转起来的，这里先介绍一下 SOFALookout。\nSOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。开源版本只提供对 Metrics 的处理部分：涵盖 Metrics 数据的产生，也就是 Metrics 的埋点、收集、加工、存储与查询等一系列服务。\n1.2 Metrics 的前置知识 介绍一些 Metrics 的前置知识：\n第一是时序数据，比较正式的解释是“基于稳定频率持续产生的一系列指标监测数据”。简单说横轴是时间，纵轴是数值的情况下，第一印象可以做成走势图的数据通常就是时序数据。比如 2009 年到 2018 年每年双十一天猫的成交额，就构成了时序数据。\n第二是标签（Tag），它用于表明指标项监测针对的具体对象。还是以刚才的成交额为例子，其实我们要监测的指标是“成交额”，但是“成交额”并没有标明要监测的对象，即谁的成交额，哪个省的成交额，也就是缺少“定语”。标签的作用就相当于是“定语”。比如“天猫的 浙江省的 成交额”，在代码中通常会有键值对来描述，比如 type=\u0026amp;ldquo;天猫\u0026amp;rdquo;，province=\u0026amp;ldquo;浙江\u0026amp;rdquo;。\n第三是时序数据库，即专门为存查时序数据而设计的数据管理系统。主要有以下几个特点：\n 写多读少 数据多维度，无 schema，需要多维度查询或聚合 通常无删除和更新操作， 或受限 以下是一些常见的开源时序数据库，由于篇幅关系，就不一一介绍了。\n Graphite InfluxDB OpenTSDB Prometheus 1.3 传统 Metrics 和 Metrics 2.0 的对比 下面再来看一下传统 Metrics 和 Metrics 2.0 的对比。\n1.3.1 传统 Metrics 传统 Metrics 是我对它的称呼，简单来说它只有 Name 和 Value，没有显式的 Tags 概念。比如 \u0026amp;ldquo;temperature = 29\u0026amp;rdquo;，温度=29，当然这里都省略了时间戳。这个表达式并没有指出监测对象，传统 Metrics 的做法是，将监测对象的信息编码到 Name 里，因此可能就变成了 \u0026amp;ldquo;temperature.hangzhou=29\u0026amp;rdquo;。这里是有一些隐式的 Tags 信息的，只是被编码到 Name 里了。\n这种做法很快会导致一个问题，我们来看下一个例子： shanghai.host1.foo.exporter.bar 。 只看这个名字的话几乎很难知道这个 Metrics 统计的是什么。这是因为它并没有把字段对应的 Key 编码到名字里，所以在缺少一些上下文的情况下，我们很难读懂它的含义。\n另外，字段的顺序也是很重要的，不能写错，这是因为编码到 Name 里的只有 Tag 的 Value，Key 不在里面，于是又有了另外一种编码方式：zone.shanghai.host.host1.app.foo.counters.exporter.bar 。这种方式将 Tag 的 Key 也编码在Name 里。但带来的问题也很明显：Name 越来越长。\n我们再看下一个例子： login.success.h5，它想表达来自 H5 平台登录成功的次数。假设我们还有其他平台，比如安卓、IOS，我们想求所有平台的总登录成功次数，那么就需要做一个聚合操作。通常时序数据库会提供型号来匹配所有值。\n其实上面这些都是旧版本 Graphite 的例子, 不过它在 2017 年底的版本支持了 Tags 概念，所以已经不能拿新版来当反面教材了。\n这是 Dropwizard 客户端的一个简单 Demo，它是一个很流行的 Metrics 埋点客户端，但是只能支持传统 Metrics 的概念。\nMetricRegistry registry = new MetricRegistry(); Counter h5Counter = registry.counter(\u0026amp;quot;login.success.h5\u0026amp;quot;); h5Counter.inc(); 1.3.2 Metrics 2.0 我们再来看 Metrics 2.0，其实 Metrics 2.0 也就只是多了 Tags 的概念，这里同样省略了 Timestamp。\n这是 OpenTSDB 风格的数据描述。\n{ \u0026amp;quot;metric\u0026amp;quot;: \u0026amp;quot;login.counter\u0026amp;quot;, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;result\u0026amp;quot;: \u0026amp;quot;success\u0026amp;quot;, \u0026amp;quot;platform\u0026amp;quot;: \u0026amp;quot;h5\u0026amp;quot; }, \u0026amp;quot;timestamp\u0026amp;quot;: 1560597254000, \u0026amp;quot;value\u0026amp;quot;: 100 } 这是 Prometheus 的描述方式。\ntemperature{city=\u0026amp;quot;hangzhou\u0026amp;quot;}=29 这是对应的 lookout-client 的埋点代码。\nRegistry registry = …; Id loginCounter = registry.createId(\u0026amp;quot;login.counter\u0026amp;quot;); Id id = loginCounter.withTags( \u0026amp;quot;result\u0026amp;quot;, \u0026amp;quot;success\u0026amp;quot;, \u0026amp;quot;platform\u0026amp;quot;, \u0026amp;quot;ios\u0026amp;quot; ); registry.counter(reqId).increment(); 可以看到它们都显式支持了 Metrics 2.0 的概念。\n这里我们花了点时间强调传统 Metrics …","date":1561705200,"description":"本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。","dir":"blog/sofa-channel-6-retrospect/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"27fcb53174efd0b72fcee578993cae38","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-6-retrospect/","publishdate":"2019-06-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-channel-6-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#6 直播分享整理，主题：轻量级监控分析系统 SOFALookout 原理讲解和功能演示。 回顾视频以及 PPT 查","tags":["SOFALookout","SOFAChannel"],"title":"蚂蚁金服轻量级监控分析系统解析 | SOFAChannel#6 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-6-retrospect/","wordcount":4165},{"author":"卓与","categories":"SOFAStack","content":" 本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。分享基于 Service Mesh 的理念，结合蚂蚁金服内部实际场景，将中间件、数据层、安全层等能力从应用中剥离出来后下沉至独立的 Sidecar SOFAMosn 中，结合 Kubernetes 运维体系，提供应用无感知的情况下升级基础设施层能力的案例。\n本次分享将从以如下次序展开进行：\n蚂蚁金服当前的服务化现状 在看蚂蚁金服的服务化架构之前我们先从一个简单的服务化调用示例说起，下图是 SOFARPC 基本原理：\n我们从上图可以看出，构建一个服务化框架需要有服务注册中心，有服务定义，调用方和服务提供方使用相同的服务定义来互相通讯。通过服务注册中心，调用方可以直接订阅到服务提供方的地址，采用点对点的方式直接发起请求。客户端内可实现服务发现、路由寻址、负载均衡、限流熔断等能力来增强服务通讯能力。通过我们开源的 SOFARPC、SOFARegistry、SOFABoot，用户已经可以直接构建起微服务体系，助力业务发展。\n蚂蚁金服发展至今，双 11 系统需要应对的交易洪峰逐年递增：\n每秒 26.5 万笔交易是 2017 年双 11 的峰值数据，这个数据背后有非常复杂的架构支持，LDC 单元化架构是蚂蚁金服沉淀多年的核心架构，依靠这个架构实现每年峰值交易量飞速增长下系统依然能平滑渡过。我们来简要看下 LDC 架构：\n上图摘自 金融级分布式架构 中的 素描单元化 一文，这里不详细展开。LDC 的单元化架构给应用的服务化带来更多的规范与抽象，服务路由中需要考虑单元间的调用，跨机房调用等更多场景。这里主要希望表达的是 LDC 架构给 RPC 调用带来更高的复杂度。\n服务化痛点 中间件版本升级 在上面介绍背景时，有介绍到目前 LDC 架构下服务调用的复杂度，这些复杂度目前是直接体现在应用的代码中。对于业务同学来讲，一个应用的关注重点是如何实现业务逻辑，至于高可用、容灾等能力更多是整体架构层面会考虑的点。应用内通过引入 RPC 的 jar 包即可获得 LDC 架构下服务调用各种能力的支撑，带来便利的同时也可以看到这种模式的缺点：\n应用内除业务逻辑之外，由中间件的 SDK 引入大量外部依赖，来完成服务发现、路由寻址、负载均衡、限流熔断、序列化、通讯等能力，每个组件的引入都可能带来稳定性风险，以及更高的升级成本。\n根据目前 SOFARPC 在内部的版本举例，服务发现依赖 SOFARegistry 的客户端做 IDC 内的服务发现，依赖 Antvip 做跨 IDC 的服务发现，ZoneClient 集成 LDC 架构的单元化信息，路由寻址需要根据请求的入参计算目前 Zone 然后确定调用目标，限流熔断依赖 Guardian 组件，通讯协议与序列化协议相对稳定，变更较少。仅为了完成服务调用，应用需要额外引入 7+ 客户端包。\n每年双 11 需要涉及到架构调整时：比如支持弹性架构，需要做很多中间件客户端的版本升级来支撑更优的架构，对于业务同学来讲，这些升级是很耗费精力的，拿 200 个核心应用举例，每个应用升级中间件版本经过研发、测试、再到部署预发、灰度、生产等环境需要 5个人日的话，200 个核心应用中间件升级需要耗费 1000 人日，如果这部分时间可以节省出来，每年架构升级可以节约大量人力资源。\n跨语言通讯 蚂蚁金服发展至今，内部业务百花齐放，搜索推荐、人工智能、安全等各种业务使用到的技术栈非常多样化，跨语言的服务通讯能力也十分重要。早在几年前，Java 之外规模最大的就是 NodeJS 应用，为了让 Java 和 NodeJS 应用之间可以复用蚂蚁金服内部的各种中间件和基础设施，前端团队使用 NodeJS 逐步重写了各种中间件客户端，让整个 NodeJS 和 Java 体系可以完美互通。\n中间件 SDK 跨语言重写与维护成本极高，随着语言种类的增多，跨语言通讯的诉求也越来越多。\nJava, NodeJS, Go, Python, C++ 等，5+ 语言，中间件 SDK 全部重写成本极高。这些问题不得不激励我们寻找更优的解法。\n解决痛点 SDK 能力下沉 依然以上述 RPC SDK 举例，SDK 中的能力我们可以根据稳定性与不可剥离等特性来看，哪些是可以从应用中抽出来的，尽量把 SDK 做薄，做的足够稳定无需变更，那么升级成本将不复存在。\nRPC SDK 中的服务发现、路由寻址、限流熔断等特性，是更易于变更的，我们将这部分能力下沉至独立的 Sidecar 中，可以复用这部分能力，让多语言的 SDK 只实现最基本的序列化与通讯协议，而这些能力是很轻量且易于实现的。这里的 Sidecar 我们是希望它作为独立进程存在，和业务应用的进程剥离，并和业务应用的升级解耦开来，实现业务和基础设施并行发展，互不干扰的愿景。\n除了 RPC 通讯，我们还可以下沉消息、数据源等能力至 Sidecar 中，业务应用可以越来越薄，SDK 实现成本也降低到可接受的程度，基础设施层与业务剥离，双方均可独立演进。\n落地架构 整体架构 不同于开源的 Istio 体系，蚂蚁金服内部版 Service Mesh 落地优先考虑数据面的实现与落地，控制面在逐步建设中，整体的架构上看，我们使用数据面直接和内部的各种中间件服务端对接，来完成 RPC、消息等能力的下沉，给业务应用减负。由上图可以看出，我们将不同的 Sidecar 与业务应用编排在同一个 Pod 中，App 与 Mosn 直接通讯，Mosn 来负责目标接口的服务发现、路由寻址，并且由 Mosn 内置的安全模块来做应用间调用的加密鉴权。通过 DBMesh 的 Sidecar 来实现数据层的下沉，App 不在需要与多个数据源建立连接，只需要连接本 Pod 内的 DBMesh 即可完成数据层调用，数据库的用户名、密码、分库分表规则等均不再需要关心。\n图中名词解析：\nConfigServer：配置中心，负责各种元数据配置、动态开关等。\nRegistry：服务注册中心，负责 IDC 内服务发现。\nAntVip：类 DNS 解析的产品，可通过域名解析一组目标地址，用于跨 IDC 服务发现。\nMQ：消息中心服务端，用于收发消息。\n落地数据 目前这套架构已经在支付核心链路中做试点，618 大促 Mesh 化应用对比无 Mesh 化应用 CPU 损耗增长 1.7%，单笔交易整体耗时增长 5ms。CPU 增长是由于多出一个进程，请求增加一条之后，RT 会有稳定的小幅增长，但这些成本相比于整体架构带来的红利，微乎其微，并且针对整个数据面的持续优化是有望逐步减少资源占用，提升资源利用率。\n降低打扰度 中间件能力下沉在架构上看是可行的，实际落地如何做到无打扰的在奔跑的火车上换轮子，低打扰是一个非常重要的考量点。借助于 Kubernetes 的优秀实践，将业务容器与 Sidecar 容器编排在同一个 Pod 中是比较合理的架构，Sidecar 与业务容器互不干扰，互相升级均可做到双方无感。\n我们为了让业务应用升级尽可能如丝般顺滑，主要做了 …","date":1561359600,"description":"本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。","dir":"blog/service-mesh-giac-2019/","fuzzywordcount":4600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7cfc7c8a7b735c31418186aae0ca99a2","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-giac-2019/","publishdate":"2019-06-24T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/service-mesh-giac-2019/","summary":"本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，蚂蚁金服平台数据技术事业群技术专家石建伟（花名：卓与）的分享。","tags":["SOFAStack","Service mesh"],"title":"蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-giac-2019/","wordcount":4572},{"author":"雾渊","categories":"SOFAArk","content":"  本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。感谢溢米教育对 SOFAStack 的支持，同时也欢迎更多用户投稿 Join us。\nSOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服开源贡献。\n写在前面 个性化推荐，相信大家都不陌生，简单来说就是根据每个人的偏好经过模型计算推荐出适合的东西，这些东西可以是视频、商品、文章、电影等。经过互联网这几年的发展，个性化推荐已经无处不在，不管是电商、教育、游戏、金融行业，推荐系统对业务的提升都有着非常重要的帮助。溢米教育作为一家互联网教育平台，近几年推荐业务发展非常迅速，技术团队也在持续的进行能力提升。业务快速增长的同时，亟需一个高效率、高稳定的推荐系统来支持推荐场景。\n本文是根据我们内部推荐平台效率与稳定性建设的实际经验整理，介绍了溢米教育推荐系统的改造优化。在整个过程中我们基于公司架构做了分析，确认了技术选型和改造方案，最终选择基于 SOFAStack 社区开源的 SOFAArk 组件开发框架，极大的提升了我们推荐系统的开发效率和稳定性。希望能给有同样困扰的技术团队参考。\n背景 一次完整的个性化推荐，通常包括召回、过滤、排序等步骤。虽然步骤不多，但是涉及到的逻辑是非常多的，包括 abtest、用户画像、物品画像、离线数据、在线数据、模型系统、字段补全等等。个性化推荐极为依赖场景定制化，不同的场景对应不同的处理逻辑。\n我们可以想象，把这一堆处理逻辑都放在一个系统里面，应用会变得十分臃肿和复杂，随着业务系统不断的迭代更新，逐渐会变得难以维护，开发效率和系统稳定性都会面临不小的挑战。不幸的是，随着溢米业务快速发展，内部的推荐平台已经变得 “过劳肥”。不管是迭代效率、性能、稳定性都遇到了瓶颈，比如：\n 发布耗时：算法团队一个人跟进一条业务线，导致业务迭代频繁、应用发布非常频繁，由于系统本身复杂性，这么一个庞然大物发布一次非常慢，降低了工程师效率；\n 系统臃肿：所有模块统一维护，包含了存储、算法、业务等，几乎每次迭代都是只增不减，降低了系统可维护性；\n 覆盖风险：多个团队共同维护一份代码，分支上容易存在冲突，合并代码存在覆盖风险，降低了团队合作效率；\n 版本不一致：不同业务团队使用的 jar 包版本不一致，每次升级一个 jar 包都会引起很多问题，导致各个团队在开发期间都要花费不少精力解决依赖冲突；\n 基于上述背景，溢米推荐平台不得不进行应用瘦身和系统改造，从而提升平台的开发效率和稳定性。然而在实际的改造过程中，我们不难发现这两者其实是互相冲突的。为了提高稳定性，我们肯定要做到流程上的把控，比如测试、灰度、发布等流程的规范，这势必会影响业务迭代效率；反过来如果要提升效率，那么在流程上肯定会有一定的舍弃，随之而来的是稳定性的潜在风险。 但是人总是需要梦想驱动的，每个工程师都希望能用一种架构或者方案，同时解决很多通用的问题，节约成本，提升效率， 让设计人员能够不至于疲于奔命， 解放生产力来完成更多有创新有挑战的工作。\n调研 效率和稳定性并非一定是二选一，在进行推荐平台升级改造之前，我们梳理了溢米内部影响业务效率和系统稳定性的主要因素。\n 开发效率 系统稳定 影响因素 业务复杂度+开发复杂度 业务变更：代码变更+数据变更 业务迭代流程+开发流程 非业务变更：配置变更+代码变更 业务变更+服务变更上线 流量变化 稳定性流程 硬件故障 关于开发效率，从上面可以看出来除了开发部分是依赖平台所能提供的便利和开发者个人技术能力之外，其余大部分都是流程上的把控。这些流程上的把控一是为了保障业务迭代的正确性，二是为了提升业务迭代带来的线上服务稳定性，但是简单的流程不足以把控住这些点，而过度复杂的流程会很大程度上影响业务迭代效率，所以我们需要思考并且寻求一种平衡，比如如何降低业务开发复杂度？如何提升平台提供的便利？如何在不影响稳定性的情况下简化业务迭代和维护流程？\n关于稳定性，我列举几个在溢米内部遇到的几个类似案例：\n 推荐服务性能优化上线，功能性测试没有问题，但是没有经过压测导致高峰期服务能力下降，最终导致整个服务不可用，而上游由于没有做好服务治理也受影响变成了服务不可用； 推荐服务所依赖的某个数据源或者 RPC 响应从 10ms 突然增长到 100ms，从而导致推荐服务主要线程池耗尽，最终导致服务不可用； 上游压测或者流量推广或者爬虫导致流量激增，但是推荐服务没有做好限流导致服务被打垮而不可用； 推荐系统依赖业务系统提供的RPC服务进行过滤，由于此RPC服务变更导致响应变慢，而推荐服务没有区分强弱依赖导致整体服务超时； 某个业务由于排期时间紧张，测试周期太短，上线后导致其它业务异常； 结合这些案例和上文总结的系统稳定性影响因素，可以发现除了硬件故障是不可控之外，其余几点基本都是因为变更而引起的。那么如何不受变更影响而提升稳定性呢？上面我们介绍过最主要也是最有效的是变更流程控制，通过测试、灰度、发布流程规范，其余也可以通过技术手段来控制，比如性能优化、服务治理、业务隔离、强弱依赖区分、多机房容灾、扩容等等。\n针对以上开发效率和稳定性分析，最开始确定如下了改造目标：\n 场景模块化 系统瘦身，拆分模块，提高系统可维护性 模块复用，提升开发效率 模块开发时隔离 各模块单独迭代开发，解决之前统一迭代开发的代码冲突问题 各模块单独测试，提升测试效率 模块运行时隔离 模块运行时类隔离，解决模块间包冲突问题 模块间有明确的服务边界，一定程度的故障隔离 模块动态可插拔 动态升级，秒级发布回滚 改造 为了满足改造目标，我们初步确认了三个选择：\n 采用自定义 SPI 的 ServiceLoader 动态加载实现； 采用自定义 Classloader 实现； 寻求开源软件支持。 基于资源成本、时间成本的考虑，我们选择了寻求开源支持，蚂蚁金服开源其分布式架构吸引了我们的关注，经过技术判断，我们最终决定使用 SOFAStack 社区开源的 SOFAArk 组件开发框架。\nSOFAArk 定义了一套相对简单的类加载模型、特殊的打包格式、统一的编程界面、事件机制、易扩展的插件机制等，从而提供了一套较为规范化的插件化、组件化的开发方案。更多内容可以参考官方文档：\nSOFA JVM 服务： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-ark-jvm\nSOFAArk 官方文档： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-readme\nSOFAArk 源码： https://github.com/sofastack/sofa-ark\n通过 SOFAArk+SOFABoot 的组合，我们将应用进行拆分，分为宿主应用+数据模块+业务模块：\n 主应用：负责整个容器的状态保持； 数据模块：负责数据通信，包括 Redis，DB，RPC 等基础服务； 业务模块：只需要负责调用数据模块进行业务实现， …","date":1560409200,"description":"本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。","dir":"blog/sofastack-user-yimi/","fuzzywordcount":3400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"967e9a815b24a3b000d5ecd90c59b8fb","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-user-yimi/","publishdate":"2019-06-13T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofastack-user-yimi/","summary":"本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。感谢溢米教育对 SOFAStack 的支持，同时也欢迎更多用户","tags":["SOFAArk"],"title":"溢米教育推荐平台的效率与稳定性建设 | SOFAStack 用户说","type":"blog","url":"/sofastack.tech/blog/sofastack-user-yimi/","wordcount":3303},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 活动时间：6 月 12 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 6 月 27 日周四晚 7 点，将邀请 蚂蚁金服 SOFALookout 开源负责人 响风 为大家分享，通过对多个模块的剖析，详解 SOFALookout 服务端以及客户端，带你了解 SOFALookout 具体是如何支持主流 Metrics协议的数据收集、存储、查询计算和可视化的。欢迎报名参加~\nSOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务，提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\n本期分享大纲：\n 监控预警基本概念介绍 SOFALookout 客户端使用 Gateway - 多协议数据收集与处理的设计与实现 Server - PromQL 与多种存储层的设计与实现 SOFALookout 发展路线 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/687\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 轻量级监控分析系统 SOFALookout 原理讲解和功能演示 响风 蚂蚁金服轻量级监控分析系统 SOFALookout 开源负责人\n本期分享大纲： 监控预警基本概念介绍 SOFALookout 客户端使用 Gateway - 多协议数据收集与处理的设计与实现 Server - PromQL 与多种存储层的设计与实现 SOFALookout 发展路线 嘉宾 SOFAGirl 主持人 响风 蚂蚁金服轻量级监控分析系统 SOFALookout 开源负责人 ","date":1560312000,"description":"6 月 12 日周四晚 7 点，线上直播第 6 期。","dir":"activities/sofa-channel-6/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"29a5673d4608770bbe7598954fcecc78","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-6/","publishdate":"2019-06-12T12:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-6/","summary":"概要 活动主题：SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示 活动时间：6 月 12 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直","tags":["SOFAChannel","SOFALookout"],"title":"SOFAChannel#6：轻量级监控分析系统 SOFALookout 原理讲解和功能演示","type":"activities","url":"/sofastack.tech/activities/sofa-channel-6/","wordcount":637},{"author":"卿祤、 首仁","categories":"SOFAStack","content":" 由蚂蚁金服主办的 SOFAStack Cloud Native Workshop 将在 6月24日于 KubeCon + CloudNativeCon + Open Source Summit China 大会的同场活动中进行，欢迎报名参与，更多信息可见此链接。 欢迎加入 SOFA 钉钉互动群（钉钉搜索群号）：23195297\n 楔子 为支撑业务高速发展并积极拥抱主流技术，我们从 2017 年开始探索并构建以Kubernetes为核心的云原生应用 PaaS 平台。在 2018 年，我们已在网商银行顺利落地了 K8S 容器引擎，并顺利支撑了 2018 年双十一。2019 年伊始，国泰产险作为互金行业的典型代表，正基于 SOFAStack 容器应用服务和监控分析产品探索云原生架构转型。时至今日，已完成了关键业务 SOFABoot 应用的容器化改造，在开发、测试乃至灰度生产环境践行云原生的运维实践。\n这将是一系列技术分享文章的开端，基于在实际金融机构和场景中落地的云原生产品项目经验，我们希望和大家一起分享从中获得的洞察和总结，探讨我们的产品观点、技术实现，并非常期待大家的建议和指点，欢迎一起交流共创。\n云原生容器产品的金融机构落地挑战 从去年开始，云原生、Kubernetes、容器这些关键字逐渐从社区走向金融科技圈，越来越多的金融机构客户开始向我们咨询，云原生技术是什么，能够给企业带来什么价值，对现有业务有什么影响？落地的路径可能会是哪些？\n我们的观点是，金融场景下的云原生，绝对不止是 12Factors，亦不止是 CNCF TOC 所定义的 5 大件，我们不仅要提供标准、通过一致性认证的 Kubernetes 产品，还需要满足更多金融场景需求，创造实际业务价值。\n经过很长一段时间的产品研发实践、深挖内外容器平台落地诉求，金融客户的关注点可能包括但不限于以下几点：\n 业务采用了云原生能否节省资源，提升工程效率？ 发现问题后如何做到快速止损，甚至线上零故障？ 如何在云原生下做到业务同城双活甚至异地多活的高可用容灾能力？ 能否和现有业务能无缝集成，如何做平滑升级？ 采用了云原生平台能否保证和现有云上一致的安全性？ 云原生能否支撑大规模分布式系统的架构？ \u0026amp;hellip; 而基于以上实际场景下的落地挑战，我们对自身容器平台产品的设计和实施，提出了以下六大关键价值主张：\n云原生容器产品的价值主张 一 使用 Immutable Infrastructure 的思想进行设计 在 PaaS 平台中，核心是应用。在之前的经典运维体系中，要对应用打一个全量快照不是件容易的事情，但在云原生世界中，会方便许多。从描述流量接入层的 Service 到描述应用配置和代码包的 Pod template，这些已是 kubernetes 的标准 Resources。\n为了解决应用管理需求，我们定义了一个 CafeAppService 对象，用于整体描述上述内容，并通过 Revision 对象属性作版本控制（和 Knative 中的 Revision 类似）。用户每次的修改都是一个 Revision，发布一个应用本质上是发布该应用的一个 Revision，故可做到快速的弹性扩缩容，并且可以方便回滚到之前发布成功过的 Revision。相比之前基于包的经典发布运维体系，效率有极大提升。\n二 可审计和无损应用发布的能力 发布变更是 PaaS 平台提供的重要能力。对于金融客户来说，每次发布必须要有据可查，而且要保证安全无损。这里，我们将蚂蚁的安全生产理念融入其中，在产品层面上提供“可灰度，可回滚（应急），可监控”的能力。\n为了做到上述能力，我们提供了发布单的概念，并定义了一个原生的 CRD：CafeDeployment。接下来逐一介绍。\n发布单 主要两个用途：做应用发布的审查记录，用于统计分析，故障复盘回顾等；协调多个应用的发布顺序，这是由于金融业务对系统的可靠性要求高，尤其在涉及资金的主链路，另外，不少系统由于业务原因，存在依赖关系，必须做有序发布。\nCafeDeployment 在这里只做简单介绍，后续会有专题介绍。该 CRD 拥有三种能力：\n 原地升级（InplaceSet）:升级过程中 Pod 的 IP 保持不变，可和经典的运维监控体系做无缝集成。 替换升级（ReplicaSet）:和社区版本的 ReplicaSet 能力保持一致。 有状态应用（StatefulSet）:和社区版本的 StatefulSet 能力保持一致。 除此之外，相比社区的 deployment，还具备 beta 验证，自定义分组策略，分组暂停，引流验证（配合 ServiceMesh）的能力。\n三 具有高可用容灾能力的工作负载 金融业由于监管的要求对系统可用性和容灾能力具有很高的要求。从应用的生命周期来看，最主要有两个状态：发布态 和 运行态。\n对于发布态，由于存在 Pod 上下线的过程，线上有抖动不可避免，要做的是尽可能的降低抖动幅度以及降低系统报错率。kubernetes 的 deployment 在发布一个 pod 时，pod 里容器的 kill 和对应 endpoint 的销毁是异步的，这就意味着可能出现 pod 里应用容器已经 kill 了，但仍然会有流量打到该 Pod，导致出现报错，甚至故障。为了防止这种情况，我们采用 finalizer 的机制，保证在南北流量和东西流量（7 层协议）都切断的情况下才对 Pod 进行更新。\n同时，还通过 CafeDeployment 里的灰度发布策略，保证发布态时线上系统的水位不会过低，防止出现流量过载，造成系统异常。\n对于运行态，要考虑以下几个方面：Pod 异常退出后的重新上线，Node 故障后的 Pod 的迁移，机房级故障后系统仍然可用。对于第一点，Kubernetes 本身已经有了较好的机制；第二点，我们做了增强，使用自定义的 NodeLifecycle Controller 结合更加详细的监控信息来判断Node是否出现故障，然后做 Pod 迁移；第三点，从 Scheduler 方面进行保障，CafeDeployment 可以定义相应的高可用拓扑结构，以同城双活为例，在创建 Pod 时，调度器会根据定义好的拓扑信息尽量将 Pod 均分到不同的可用区，达到同城双活的状态。\n四 一致的验证授权体验 蚂蚁金服 PaaS 平台在近 4 年的时间里，已经有了一套完整的 IAM 体系，并且许多客户已经基于此定义了许多的角色，用做安全防护。我们从两方面来提供一致性的体验：\n首先，在产品上的操作上提供和原先一样的验证授权机制。只要客户将 K8S 内预先定义好的角色或者权限分配相应的用户或用户组，那该用户或者属于该用户组的用户就能在产品上做相应的操作。\n其次，IAM 的权限和角色与 Kubernetes 的 RBAC 做映射。根据用户在 IAM 所具备的角色，在 Kubernetes 集群中创建相应的 ClusterRole，并生成访问 Kubernetes 集群的 token，创建 ClusterRoleBinding 与 token 绑定。这样用户使用 kubectl 操作集群时也可以具备相同的权限，保证权限 …","date":1559890800,"description":"这将是一系列技术分享文章的开端，基于在实际金融机构和场景中落地的云原生产品项目经验，我们希望和大家一起分享从中获得的洞察和总结，探讨我们的产品观点、技术实现，并非常期待大家的建议和指点，欢迎一起交流共创。","dir":"blog/sofa-financial-cloud-native-exploration/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9c93781d7d4b980b1990e4655445d4bf","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","publishdate":"2019-06-07T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","summary":"由蚂蚁金服主办的 SOFAStack Cloud Native Workshop 将在 6月24日于 KubeCon + CloudNativeCon + Open Source Summit China 大会的同场活动中进行，欢迎报名参与，更多信息可见此链接。 欢迎加入 SOFA 钉钉互动群（钉钉搜","tags":["SOFAStack"],"title":"金融级云原生探索实践系列 - 开篇","type":"blog","url":"/sofastack.tech/blog/sofa-financial-cloud-native-exploration/","wordcount":3874},{"author":"墨睿","categories":"SOFALookout","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFALookout 是在 SOFAStack 体系内研发开源的一款解决系统的度量和监控问题的轻量级中间件服务。本文给大家介绍下 SOFALookout 服务器端主要提供的特性以及使用方式。 SOFALookout：https://github.com/sofastack/sofa-lookout\n 前言 容器，K8S，微服务，Mesh 以及 Serverless 这些新技术方向正在根本的变革我们运行软件的方式。我们构建的系统更加分布式化，另外由于容器，系统的生命周期更加短，变得易逝。针对这些变化，SOFALookout 希望提供一套轻量级解决方案。之前 SOFALookout 已经开源客户端的能力。今天，SOFALookout 服务器端 Metrics 部分的代码终于正式开源啦！本文给大家介绍下 SOFALookout 服务器端的主要特性以及使用方法。\n什么是 SOFALookout SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\nSOFALookout 目标是打造一套轻量级 Observability 实时工具平台，帮助用户解决基础设施、应用和服务等的监控和分析的问题。SOFALookout（目前已开源部分） 是一个利用多维度的 metrics 对目标系统进行度量和监控的项目。SOFALookout 的多维度 metrics 参考 Metrics2.0 标准。\nSOFALookout ：https://github.com/sofastack/sofa-lookout\nSOFALookout 安装文档：https://www.sofastack.tech/sofa-lookout/docs/quickstart-metrics-server\n SOFALookout 服务器端的主要特性:\n 适配社区主要 Metrics 数据源协议写入（比如: Prometheus，Metricbeat 等）； 数据的存储支持扩展，暂时开源版默认支持 Elasticsearch， 并且透明和自动化了相关运维操作； 遵循 Prometheus 查询 API 的标准以及支持 PromQL，并进行了适当改进； 自带数据查询的控制台，并支持 Grafana 进行数据可视化； 使用简单，支持单一进程运行整个服务器端模块。 随着 SOFALookout （metrics）服务器端代码开源，metrics 数据的处理已经形成闭环。后续我们将会进一步开源 Trace 和 Event 相关的服务能力，敬请期待。\nSOFALookout 项目结构 服务器端代码分别包括两部分：Gateway 模块和 Server 模块。如下图所示（展示了 SOFALookout 源码项目的模块概要结构）\n├── boot ├── client ├── gateway └── server 项目中的 boot 模块作用是方便集成和运行服务端的模块，既可以单独运行 Gateway 和 Server 的服务，也可以借助 SOFAArk 完成（Gateway 和 Server）的 All in One 的合并为单一进程运行。\nSOFALookout 工作机制 下图完整展示了 SOFALookout 如何从 metrics 数据采集、上报、存储到最终展示的完整流程路径。\n目前 SOFALookout 支持灵活的 metrics 数据存储选型。但开源版本我们暂时只支持了 Elasticsearch 作为存储的方案（后续可能继续支持 Cassandra,InfluxDB\u0026amp;hellip;），其他存储地适配我们希望更多同学能参与共建和支持。优先支持 Elasticsearch 是因为我们考虑到了 ELK 解决方案在业界已经广泛使用，尤其是日志数据。\n为了开箱即用，同时考虑到不熟悉 Elasticsearch 的同学的使用，SOFALookout已经内置了关于 metrics 数据存储的自动化运维工具，可以免除大家自己建 Index，和日常维护 ES Index 的麻烦，更多细节后续单独讲解。\n本次新增开源模块 一、SOFALookout Gateway 模块 SOFALookout Gateway 轻量的数据管道，它提供丰富的协议接入支持，包括自有SDK（SOFALookout Client）上报协议，还支持 Prometheus 的数据协议（推模式和拉模式），Metricbeat 协议（版本是6），OpenTSDB 写入协议。每种数据来源对应于一个 Importer 的概念。\nSOFALookout Gateway 对于远程（推模式）上报提供本地硬盘缓冲的支持。Gateway 总体设计是围绕数据加工的Pipeline 形式，包括前置后置的数据过滤器方便进行开发者数据加工。 另外 Gateway 可以支持自定义 Exporter，默认提供了 Elasticsearch Exporter，Standard Exporter(用于 Gateway 间数据中继)，开发者也可以自定义其他存储的 或 Kafka 等各式各样 Exporter。\n二、SOFALookout Server 模块 SOFALookout Server 兼容和增强了 Prometheus 的数据及元数据查询的 RESTful API。同样对应 PromQL 我们也基本实现了兼容和增强（不包括 Alert 相关语法），SOFALookout 的 promQL 相关解析逻辑是从 Prometheus 移植而来，做了一些优化和改进， 感谢 Prometheus 开源了如此易用和强大的 golang 版本的 QL 实现。\n为了方便方便开发者做数据探索和试验，我们也提供了自有 Web-UI 的支持，能够满足基本功能使用。\n我们还是推荐大家使用 Grafana 进行数据展示。Grafana 集成 SOFALookout 很简单，只需要选择 Prometheus 作为数据源协议即可（SOFALookout默认查询端口也是: 9090）。下图展示 Grafana 新增数据源配置：\n近期计划 下图是近期的 Roadmap：\n非常欢迎更多同学参与 SOFALookout 共建，尤其是支持更多的 Metrics 存储库。\n","date":1559804400,"description":"本文给大家介绍下 SOFALookout 服务器端主要提供的特性以及使用方式。","dir":"blog/sofa-lookout-server-open-source/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d80fe27f8652b6e8a8da8d712a90a027","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-lookout-server-open-source/","publishdate":"2019-06-06T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/sofa-lookout-server-open-source/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFALookout 是在 SOFAStack 体系内","tags":["SOFALookout"],"title":"轻量级监控分析系统 SOFALookout 服务端开源","type":"blog","url":"/sofastack.tech/blog/sofa-lookout-server-open-source/","wordcount":1970},{"author":"Jimmy Song","categories":null,"content":" SOFAStack Cloud Native Workshop hosted by Ant Financial (KubeCon China 2019 Co-Located Event) Date: Monday, 24 June, 2019 Time: 9:00 – 16:00 Location: Shanghai Expo Centre Room 616 Registration Fees: Complimentary Register here: https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop Note: This event is hands-on, please bring your personal computer. The language of communication in this workshop is Chinese. SOFAStack (Scalable Open Financial Architecture Stack) is a financial-grade distributed architecture independently developed and open sourced by Ant Financial. It contains the components required to build a financial-grade cloud native architecture. It is a best practice tempered in financial scenarios. SOFAStack official website: https://www.sofastack.tech/\nAttendees can get:\n Rapidly build microservices based on SOFAStack Best Practices for Distributed Transactions in Financial Scenarios Cloud native deployment experience based on Kubernetes Service Mesh basic usage scenario experience on the cloud Get started on Serverless apps Easily build applications on the cloud based on Serverless How to Register: Pre-registration is required. To register for SOFAStack Cloud Native Workshop, add it on during your KubeCon + CloudNativeCon + Open Source Summit registration. You can get KubeCon half price tickets with KCCN19COMATF coupon code!\nFor questions regarding this event, please reach out to jingchao.sjc@antfin.com.\nEvent details 9:00 - 9:20 Opening speech SOFAStack Cloud Native\n9:20 - 10:10 Quickly build microservices with SOFAStack by Jie Cao\nBuilding a microservices application based on the SOFAStack. Through this workshop, you can learn how to report application monitoring data, service link data, and publish and subscribe services in the SOFAStack.\n10:15 - 11:05 SOFABoot dynamic module practice by Guolei Song\nIn this workshop, you can implement the combined deployment and dynamic module push capabilities provided by SOFAArk based on the ARK control capabilities of SOFADashboard.\n11:10 - 12:00 Using Seata to guarantee the consistency of payment by Long Chen\nUnder the microservice architecture, the distributed transaction problem is an industry problem. Through this workshop, you can understand the background of distributed transaction problems under distributed architecture, as well as common distributed transaction solutions and experience on how to use the open source distributed transaction framework - Seata\u0026amp;rsquo;s AT mode, TCC mode to solve the ultimate consistency of the business data.\n12:00 - 13:00 Lunch time\n13:00 - 13:30 Cloud Native exlporation and practice in Ant Fnancial by Renjie Yu\n13:30 - 14:40 Migrating to cloud based on Serverless by Yitao Dong\nAs one of the pioneering technologies of cloud technology, Serverless architecture allows you to further improve resource utilization and focus on business development. Through our workshop, you can experience new product …","date":1559643600,"description":"","dir":"activities/sofastack-cloud-native-workshop/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"57c6b0262af34c2010179000834d8363","permalink":"https://sofastack.github.io/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","publishdate":"2019-06-04T10:20:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","summary":"SOFAStack Cloud Native Workshop hosted by Ant Financial (KubeCon China 2019 Co-Located Event) Date: Monday, 24 June, 2019 Time: 9:00 – 16:00 Location: Shanghai Expo Centre Room 616 Registration Fees: Complimentary Register here: https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop Note: This event is hands-on, please bring your personal computer. The language of communication in this workshop is Chinese. SOFAStack (Scalable Open Financial Architecture Stack) is a financial-grade distributed architecture independently developed and open sourced by Ant Financial.","tags":["KubeCon","Workshop","Cloud Native"],"title":"KubeCon China 2019 Co-Located Event SOFAStack Cloud Native Workshop","type":"activities","url":"/sofastack.tech/en/activities/sofastack-cloud-native-workshop/","wordcount":515},{"author":"宋净超","categories":null,"content":" 蚂蚁金服 SOFAStack 云原生工作坊（KubeCon China 2019 同场活动） 日期：2019年6月24日，星期一 时间：9:00 – 16:00 地点：上海世博中心 616 房间 注册费：免费 注册地址：https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/#sofastack-cloud-native-workshop 备注：本次活动为动手实践，请携带个人电脑。本沙龙沟通语言为中文。 SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发并开源的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。SOFAStack 官方网站：https://www.sofastack.tech/\n参加此次 Meetup 您将获得：\n 基于 SOFAStack 快速构建微服务 金融场景下的分布式事务最佳实践 基于 Kubernetes 的云原生部署体验 云上的 Service Mesh 基本使用场景体验 基于 Serverless 轻松构建云上应用 如何注册：此活动须提前注册。请将 SOFAStack Cloud Native Workshop 添加到您 KubeCon + CloudNativeCon + Open Source Summit 的注册表里。您可以使用 KCCN19COMATF 折扣码获取 KubeCon 半价门票！\n如果对此活动有任何疑问，请发送邮件至 jingchao.sjc@antfin.com。\n活动详情 9:00 - 9:20 开场演讲 SOFAStack 云原生开源体系介绍 by 余淮\n9:20 - 10:10 使用 SOFAStack 快速构建微服务 by 玄北\n基于 SOFA 技术栈构建微服务应用。通过本 workshop ，您可以了解在 SOFA 体系中如何上报应用监控数据、服务链路数据以及发布及订阅服务。\n10:15 - 11:05 SOFABoot 动态模块实践 by 卫恒\n在本 workshop 中，您可以基于 SOFADashboard 的 ARK 管控能力来实现 SOFAArk 提供的合并部署和动态模块推送的功能。\n11:10 - 12:00 使用 Seata 保障支付一致性 by 屹远\n微服务架构下，分布式事务问题是一个业界难题。通过本workshop，您可以了解到分布式架构下，分布式事务问题产生的背景，以及常见的分布式事务解决方案；并亲身体验到如何使用开源分布式事务框架Seata的AT模式、TCC模式解决业务数据的最终一致性问题。\n12:00 - 13:00 午餐时间\n13:00 - 13:30 蚂蚁金服的云原生探索与实践 by 首仁\n13:30 - 14:40 通过 Serverless 快速上云 by 隐秀\n作为云原生技术前进方向之一，Serverless 架构让您进一步提高资源利用率，更专注于业务研发。通过我们的 workshop，您可以体验到快速创建 Serveless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错、按时间触发应用等产品新功能。\n14:50 - 16:00 使用 CloudMesh 轻松实践 Service Mesh by 敖小剑\nService Mesh 将服务间通信能力下沉到基础设施，让应用解耦并轻量化。但 Service Mesh 本身的复杂度依然存在，CloudMesh 通过将 Service Mesh 托管在云上，使得您可以轻松的实践 Service Mesh 技术。通过我们的 workshop，您可以快速部署应用到 CloudMesh ，对服务进行访问，通过监控查看流量，体验服务治理、Sidecar管理和对服务的新版本进行灰度发布等实用功能。\n","date":1559643600,"description":"","dir":"activities/sofastack-cloud-native-workshop/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"57c6b0262af34c2010179000834d8363","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofastack-cloud-native-workshop/","publishdate":"2019-06-04T10:20:00Z","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofastack-cloud-native-workshop/","summary":"蚂蚁金服 SOFAStack 云原生工作坊（KubeCon China 2019 同场活动） 日期：2019年6月24日，星期一 时间：9:00 – 16:00 地点：上海世博中心 616 房间 注册费：免费","tags":["KubeCon","Workshop","Cloud Native"],"title":"KubeCon 上海同场活动 SOFAStack Cloud Native Workshop","type":"activities","url":"/sofastack.tech/activities/sofastack-cloud-native-workshop/","wordcount":1134},{"author":"卫恒","categories":"SOFAMeetup","content":" 作者：卫恒（宋国磊），SOFATracer 以及 SOFADashboard 开源负责人。\n本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，着重分享如何使用 SOFADashboard 来管控 SOFAArk ，对于 SOFAArk 中的一些基础概念和知识不过多涉及；建议大家在阅读之前，先了解下 SOFAArk 的相关基本知识。\n现场回顾视频以及 PPT 见文末链接。\n前言 SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署能力，由蚂蚁金服开源贡献。SOFAArk 在 0.6.0 版本 提供了非常丰富的功能特性，其中最核心的当属多应用（模块）合并部署这个能力。SOFAArk 本身提供了多种方式来支持多应用（模块）合并部署 ，包括基于命令行的管控，基于 API 的管控等。本篇将结合 SOFA 开源的管控端组件 SOFADashboard，来实现 SOFAArk 提供的合并部署和动态模块推送的功能。\n案例工程地址\n背景 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n案例模型 本篇所演示案例是上图的一个简化版，从整体上可以体现 SOFAArk多应用合并部署的能力。主要包括已经几个工程：\n sofa-dashboard-ark-hostapp : 宿主应用 sofa-dashboard-ark-facade : 提供接口 API sofa-dashboard-ark-provider ：提供接口 API 的具体实现，将发布一个 JVM 服务 sofa-dashboard-ark-hostapp 和 sofa-dashboard-ark-provider 均作为 SOFAArk 中的 ark-biz 存在；sofa-dashboard-ark-hostapp 作为宿主应用对外提供服务。\n上图的模型中，在宿主应用不重启的情况下，实现 provider 模块的动态替换，从而实现版本升级。\n 在宿主应用启动时，provider 1.0.0 以静态合并部署方式“寄宿”到宿主应用中，这部分实际上与 SOFADashboard 管控是没有什么关系的，为了案例效果，在下面的案例中，关于静态合并部署的操作也会涉及到。\n 最终的工程结构图如下：\n环境准备 本文需要启动 SOFADashboard 服务端，具体请参考 : Quick Start ；其他基础设施环境如 Zookeeper 、Mysql 等需提前准备。\n工程构建 本篇将通过 step by step 的方式来构建整个工程，为大家在实际的应用过程中提供一种简单的思路，同时也帮助大家更好的理解 SOFAArk 中的一些点。\nsofa-dashboard-ark-facade 基础 API 提供模块，不需要依赖任何其他二方或者三方 JAR，这里仅提供一个接口。\npublic interface SofaJvmService { String test(); } sofa-dashboard-ark-provider 这个模块是 JVM 服务的提供方，也是后面需要在宿主应用中进行替换演示的模块包，这个模块本身也是一个 Web 应用。这里就来一步步分解下，如何将一个普通的 SpringBoot 工程改造成一个 ark-biz 工程。\n1、新建一个 SpringBoot 工程 新建 SpringBoot 工程推荐的方式有两种，一种是在 https://start.spring.io/ 进行下载，另外一种是基于 IDEA 的 Spring 插件来生成；此处不在过多描述过程。\n2、工程基本能力实现 引入 sofa-dashboard-ark-facade 依赖，先将需要提供的 JVM 服务实现： @SofaService @Service public class SofaJvmServiceImpl implements SofaJvmService { @Override public String test() { return \u0026amp;quot;first version biz\u0026amp;quot;; } } NOTE: SofaService 的作用是将一个 Bean 发布成一个 JVM 服务， 所以这里需要加上 Spring 提供的 @Service 注解将 SofaJvmServiceImpl 标注为一个 Bean。\n 配置文件： spring.application.name=biz-ark-test server.port=8800 logging.path=./logs 3、配置打包插件，将应用打包成 ark-biz  根据官方文档，可以使用 sofa-ark-maven-plugin 插件将一个普通的工程打包成一个 ark biz 包。这里直接给出本篇中工程的配置：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!--ark-biz 包的打包配置 --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- ark-biz 包的启动优先级，值越小，优先级越高--\u0026amp;gt; …","date":1559286000,"description":"本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，着重分享如何使用 SOFADashboard 来管控 SOFAArk ，对于 SOFAArk 中的一些基础概念和知识不过多涉及。","dir":"blog/sofa-meetup-2-2-retrospect/","fuzzywordcount":3700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"61a156b1a9f1a80f555200bfea5a20b6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","publishdate":"2019-05-31T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","summary":"作者：卫恒（宋国磊），SOFATracer 以及 SOFADashboard 开源负责人。 本文根据 5月26日 SOFA Meetup#2上海站 《使用 SOFAStack 快速构建微服务》主题分享整理，","tags":["SOFAMeetup","SOFAArk","SOFADashboard"],"title":"基于 SOFAArk 和 SOFADashboard 实现动态模块管控 | Meetup#2 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-2-2-retrospect/","wordcount":3608},{"author":"玄北","categories":"SOFAStack","content":" 本文作者：玄北（曹杰），蚂蚁金服 SOFAStack 开源组核心成员。\n本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理，主要来聊聊 spring-cloud-antfin 包含的主要特性及如何使用 SOFAStack 和 SpringCloud 快读构建微服务系统。\n现场回顾视频以及 PPT 见文末链接。\n概念 Spring Cloud 是 Spring 社区开源的一套微服务开发框架，帮助开发人员快速构建分布式应用，Spring Cloud 的官网介绍如下：\n Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state).\n 蚂蚁金服从 2007 年开始在公司内部使用 SOFAStack 框架，2014 年基于 Spring Boot 研发了 SOFABoot，2016 年将 SOFAStack 在公有云输出，2018 年 4 月，蚂蚁金服宣布开源 SOFAStack。SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服开源的，用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。SOFAStack ：https://github.com/sofastack\nSOFAStack 包含以下主要特性：\n 全面：覆盖多种场景，让用户更加专注于业务开发； 可靠：经历过大规模场景的锤炼，特别是严苛的金融场景； 丰富：包含构建金融级云原生架构所需的各个组件，满足用户场景的现状和未来需求； 开放：兼容开源生态，组件可插拔， SOFAStack 组件与其它开源组件可相互集成或替换。 SOFAStack 开源全景图涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的 Nacos、Sentinel 等，为用户提供更加广泛地选择。\nSOFAStack 开源已经超过一年，Spring Cloud 作为当下流行的微服务框架，社区用户以及公司内部用户迫切希望能够将这两个优秀的框架进行整合，将 SOFAStack 中间件适配 Spring Cloud 规范也就产生了我们今天的主角——spring-cloud-antfin。\nspring-cloud-antfin 全景图 Spring 官网提供了一份 Spring Cloud 的架构图：\n从 Spring Cloud 的架构图可以看到，Spring Cloud 框架涵盖了分布式应用开发的方方面面，包括：\n API 网关  熔断与限流 服务发现 分布式配置 分布式链路 spring-cloud-antfin 是 Spring Cloud 微服务规范的 antfin 实现，同样的，我们也有一份 spring-cloud-antfin 全景图，涵盖了蚂蚁金服所有中间件：\n与 Spring Cloud 全景图不同，在 spring-cloud-antfin 中每种分布式组件都有具体的蚂蚁中间件实现：\n API 网关：SOFAGateway 熔断与限流：Guardian 服务发现：SOFARegistry 分布式配置：DRM 分布式链路：SOFATracer 在 spring-cloud-antfin 适配 Spring Cloud 的过程中，我们发现 Spring Cloud 制定的规范并不完整，对于一些 Spring Cloud 规范并未涵盖的方面，spring-cloud-antfin 进行了扩展。\n扩展 Spring Cloud 虽然 Spring Cloud 定义了很多微服务规范，但是在具体业务开发过程中，我们发现 Spring Cloud 还有很多不足，例如 Spring Cloud 对以下能力没有进行规范化：\n 属性级别动态配置 事务消息 Big Table 分布式事务 属性级别动态配置 Spring Cloud 的动态配置基于 RefreshScope 接口，默认 RefreshScope 会对整个 Bean 进行刷新，而且实现自动刷新需要配合 spring-cloud-bus，我们认为与 Apollo、Nacos 等属性级别刷新相比，这个是明显的退步，所以 spring-cloud-antfin 定义一个 DynamicConfig 注解，对于打有这个注解的 Bean，spring-cloud-antfin 支持属性级别动态配置：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) public @interface DynamicConfig { } 事务消息 spring-cloud-stream 默认不支持事务消息，但是在金融级场景中事务消息是必不可少的，所以 spring-cloud-antfin 扩展了 spring-cloud-stream 的定义，对事务消息进行了支持：\n MQ 支持事务：对于使用 MQ 本身就支持事务消息的，spring-cloud-antfin 会在 MessageHeaders 中增加 Transcation 相关属性，以此支持事务消息； MQ 不支持事务：对于使用 MQ 本身不支持事务的，spring-cloud-antfin 支持用本地事件表的模式支持事务消息。 消息发送端在同一个本地事务中记录业务数据和消息事件； 事件恢复服务定时从事件表中恢复未发布成功的事件，重新发布成功后删除记录的事件。 通过事件恢复服务的不停执行，我们保证了本地事件和消息发送到 Message Broker 必定同时成功或者同时失败。\nBig Table 一些 SOFAStack 的使用者，一套代码会在多种技术栈使用，当使用开源技术栈时，Big Table 的实现会使用 HBase，在使用商业技术栈时，Big Table 会使用阿里云的 TableStore，为了让用户实现不修改代码在不同技术栈使用，spring-cloud-antfin 会定义一套统一接口，然后让用户针对 spring-cloud-antfin 的接口进行编程，这样在替换底层实现时用户代码不需要修改：\npublic interface BigTableService { Result get(Get get) throws StoreException; Result[] get(List\u0026amp;lt;Get\u0026amp;gt; get) …","date":1559113200,"description":"本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理。","dir":"blog/sofa-meetup-2-1-retrospect/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ffc229811fe6c3065b010a9730e6d895","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","publishdate":"2019-05-29T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","summary":"本文作者：玄北（曹杰），蚂蚁金服 SOFAStack 开源组核心成员。 本文根据 5月26日 SOFA Meetup#2 上海站 《当 Spring Cloud 遇上 SOFAStack》主题分享整理，主要来聊聊 spring-cloud-antfin 包含","tags":["SOFAStack","SOFAMeetup"],"title":"当 Spring Cloud 遇上 SOFAStack | Meetup#2 回顾","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-2-1-retrospect/","wordcount":2918},{"author":"敖小剑","categories":"Service Mesh","content":" 前言 本文内容整理自5月25日在 Kubernetes \u0026amp;amp; Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 ServiceMesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁金服的上云实践，阐述在云原生背景下 Service Mesh 的核心价值，以及对云原生落地的关键作用。\n内容主要有三个部分：\n Service Mesh 产品动态：介绍最近半年 Service Mesh 的产品动态，包括开源项目和云厂商推出的云上服务 Service Mesh 发展趋势：根据最近的产品动态，总结 Service Mesh 的发展趋势，推断未来的走向 Service Mesh 与云原生：结合云原生，更好的理解 Service Mesh 的价值和作用 Service Mesh 产品动态 Istio1.1 发布 Istio 是目前 Service Mesh 社区最引人注目的开源项目，在今年的3月份发布了期待已久的 Istio 1.1 版本，我们来看看 Istio 最近几个版本的发布情况：\n 2018年6月1日，Istio 发布了 0.8 版本，这是 Istio 历史上第一个 LTS 版本，也是 Istio 历史上变动最大的一个版本； 2018年7月31日，Istio 发布了 1.0 版本，号称 \u0026amp;ldquo;Product Ready\u0026amp;rdquo;； 然后就是漫长的等待，Istio 1.0 系列以每个月一个小版本的方式一路发布了 1.0.1 到 1.0.6，然后才开始 1.1.0 snapshot 1 到 6，再 1.1.0-rc 1 到 6，终于在 2019年3月20日 发布了 1.1 版本，号称 \u0026amp;ldquo;Enterprise Ready\u0026amp;rdquo;。 从 Istio 1.0 到 Istio 1.1，中间的时间跨度高达9个月！我们来看看经过这漫长的开发时间才发布的 Istio 1.1 版本带来了哪些新的东西：\n图中标红的部分，涉及到 Istio 的架构调整，下面将详细介绍 Istio 1.1 版本中带来的架构变化。\nIstio 1.1 架构变化 下图是 Istio 1.0 和 Istio 1.1 的架构图对比：\nIstio 1.1 的第一个架构变化来自 Galley：在 Istio 1.1 的架构图中增加了 Galley 组件。但是实际上在 Istio 1.0 版本中 Gallay 组件就已经存在，只是当时 Galley 的功能非常简单，只是做配置更新之后的验证（Validation），在 Istio 1.0 的架构图中都没有出现。而在 Istio 1.1 版本之后，Galley 的定位发生了巨大的变化：Galley开始分担 Pilot/Mixer 的职责。\n在 Istio 1.1 版本之前的设计中，Istio 的三大组件 Pilot/Mixer/Citadel 都需要访问 Kubernetes 的 API Server，以获取服务注册信息和配置信息，包括 Kubernetes 原生资源如 service/deployment/pod 等，还有 Istio 的自定义资源（数量多达50多个的 CRD） 。这个设计导致 Istio 的各个组件都不得不和 Kubernetes 的 API Server产生强绑定，不仅仅代码大量冗余，而且在测试中也因为需要和 Kubernetes 的 API Server 交互导致 Pilot/Mixer 模块测试困难。\n为了解决这个问题，在 Istio 1.1 之后，访问 Kubernetes 的 API Server 的工作将逐渐交给 Galley 组件，而其他组件如 Pilot/Mixer 就会和 Kubernetes 解耦。\n这个工作还在进行中，目前 Istio 的 CRD 已经修改为由 Galley 读取，而 K8s 的原生资源（Service / Deployment / Pod等），暂时还是由 Pilot 读取。\n为了方便在各个组件中同步数据，Istio 引入了MCP（Mesh Configuration Protocol）协议。在 Istio 1.1 版本中，Pilot 通过 MCP 协议从 Galley 同步数据。MCP 是受 xDS v2 协议（准确说是 aDS）的启发而制定的新协议，用于在Istio 各模块之间同步数据。\nIstio 1.1 的第二个架构变化来自于 Mixer，在 Istio 1.1 版本中，推荐使用 Out-of-Process Adapter，即进程外适配器。Istio 预计下一个版本将弃用 In-Proxy Adapter，目前所有的 Adapter 都将改为 Out-of-Process adapter。\n什么是 In-Proxy Adapter？下图是 Mixer 的架构图，在 Istio 的设计中，Mixer 是一个独立进程，Proxy 通过远程调用来和 Mixer 交互。而 Mixer 的实现了 Adapter 模式，定义了 Adapter API，然后内建了数量非常多的各种Adapter。这些 Adatper 的代码存放在 Mixer 代码中，运行时也在 Mixer 的进程内，因此称为 In-Process Adapter。\nIn-Process Adapter 的问题在于所有的 Adapter 的实现都和 Mixer 直接绑定，包括代码和运行时。因此当 Adapter 需要更新时就需要更新整个 Mixer，任意一个 Adapter 的实现出现问题也会影响整个 Mixer，而且数量众多的 Adapter 也带来了数量众多的CRD。为此，Istio 1.1 版本中通过引入 Out-of-Process Adapter 来解决这个问题。\nOut-of-Process Adapter 以独立进程的方式运行在 Mixer 进程之外，因此 Out-of-Process Adapter 的开发/部署和配置都可以独立于 Mixer，从而将 Mixer 从 Adaper 的实现细节中解脱出来。\n但是，Out-of-Process Adapter 的引入，会导致新的性能问题：原来 Mixer 和 In-Process Adapter 之间是方法调用，现在改成 Out-of-Process Adapter 之后就变成远程调用了。而 Mixer 一直以来都是 Istio 架构设计中最大的争议，之前 Proxy 和 Mixer 之间的远程调用，已经造成非常大的性能瓶颈，而引入 Out-of-Process Adapter 之后远程调用会从一次会变成多次（每个配置生效的 Out-of-Process Adapter 就意味着一次远程调用），这会让性能雪上加霜。\n总结 Out-of-Process Adapter 的引入：架构更加的优雅，性能更加的糟糕。\n在 Istio 1.1 为了架构而不顾性能的同时，Istio 内部也有其他的声音传出，如正在规划中的 Mixer v2。这个规划最重要的决策就是放弃 Mixer 独立进程的想法，改为将 Mixer 的功能合并到 Envoy 中，从而避免 Envoy …","date":1559026800,"description":"本文内容整理自5月25日在 Kubernetes \u0026 Cloud Native Meetup 上海站发表的主题演讲。","dir":"blog/service-mesh-development-trend-1/","fuzzywordcount":8400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8756e6985e0df28a5150ebd3af0e48c5","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-development-trend-1/","publishdate":"2019-05-28T15:00:00+08:00","readingtime":17,"relpermalink":"/sofastack.tech/blog/service-mesh-development-trend-1/","summary":"前言 本文内容整理自5月25日在 Kubernetes \u0026amp; Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 ServiceMesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁金服的上云实践，","tags":["Service Mesh"],"title":"Service Mesh 发展趋势：云原生中流砥柱","type":"blog","url":"/sofastack.tech/blog/service-mesh-development-trend-1/","wordcount":8383},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAJRaft 实现原理》第二篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，目前领取已经完成，感谢大家的参与。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n前言 SOFAJRaft-RheaKV 是基于 SOFAJRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库，SOFAJRaft 是基于 Raft 一致性算法的生产级高性能 Java 实现，支持 Multi-Raft-Group。SOFAJRaft-RheaKV 集群主要包括三个核心组件：PD，Store 和 Region。本文将围绕 SOFAJRaft-RheaKV 架构设计，存储概览，核心模块，使用场景以及基于 Raft 实现等方面剖析 SOFAJRaft-RheaKV 基于 SOFAJRaft 实现原理，阐述如何使用 Raft 协议支持 KV 存储类库功能特性：\n SOFAJRaft-RheaKV 基础架构如何设计？核心组件负责哪些功能？模块内部处理流程是怎样？ 基于 SOFAJRaft 如何使用 Raft 实现 SOFAJRaft-RheaKV 强一致性和自驱动等特性？  SOFAJRaft-RheaKV 概览 SOFAJRaft-RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 Library， RheaKV 包含在 SOFAJRaft 项目里，是 SOFAJRaft 的子模块。SOFAJRaft-RheaKV 定位是嵌入式 jar 包方式嵌入到应用中，涵盖以下功能特性：\n 强一致性，基于 Multi-Raft 分布式一致性协议保证数据可靠性和一致性； 自驱动，自诊断，自优化，自决策，自恢复； 可监控基于节点自动上报到 PD 的元信息和状态信息； 基本 API get/put/delete 和跨分区 scan/batch put，distributed lock 等。 架构设计 SOFAJRaft-RheaKV 存储类库主要包括 PD，Store 和 Region 三个核心组件，支持轻量级的状态/元信息存储以及集群同步，分布式锁服务使用场景：\n PD 是全局的中心总控节点，负责整个集群的调度管理，维护 RegionRouteTable 路由表。一个 PDServer 管理多个集群，集群之间基于 clusterId 隔离；PD Server 需要单独部署，很多场景其实并不需要自管理，RheaKV 也支持不启用 PD，不需要自管理的集群可不启用 PD，设置 PlacementDriverOptions 的 fake选项为 true 即可。 Store 是集群中的一个物理存储节点，一个 Store 包含一个或多个 Region。 Region 是最小的 KV 数据单元，可理解为一个数据分区或者分片，每个 Region 都有一个左闭右开的区间 [startKey, endKey)，能够根据请求流量/负载/数据量大小等指标自动分裂以及自动副本搬迁。Region 有多个副本 Replication 构建 Raft Groups 存储在不同的 Store 节点，通过 Raft 协议日志复制功能数据同步到同 Group 的全部节点。 存储设计 SOFAJRaft-RheaKV 存储层为可插拔设计，实现 RawKVStore 存储接口，目前 StoreEngine 存储引擎支持 MemoryDB 和 RocksDB 两种实现：\n MemoryRawKVStore：MemoryDB 基于 ConcurrentSkipListMap 实现，有更好的性能，但是单机存储容量受内存限制； RocksRawKVStore：RocksDB 在存储容量上只受磁盘限制，适合更大数据量的场景。 SOFAJRaft-RheaKV 存储引擎基于 MemoryDB 和 RocksDB 实现 KV 存储入口：\ncom.alipay.sofa.jraft.rhea.storage.RawKVStore com.alipay.sofa.jraft.rhea.storage.MemoryRawKVStore com.alipay.sofa.jraft.rhea.storage.RocksRawKVStore SOFAJRaft-RheaKV 数据强一致性依靠 SOFAJRaft 同步数据到其他副本 Replication, 每个数据变更都会落地为一条 Raft 日志, 通过 Raft 协议日志复制功能将数据安全可靠地同步到同 Raft Group 的全部节点里。\n核心设计 SOFAJRaft-RheaKV 核心模块包括 KV 模块[RheaKVStore 基于 RegionRouteTable 路由表使用 RaftRawKVStore 存储 KeyValue]，PD 模块[PlacementDriverServer 基于 StoreHeartbeat/RegionHeartbeat 心跳平衡节点分区 Leader 以及分裂]。\nKV 模块内部处理 RheaKVStore：最上层 User API，默认实现为 DefaultRheaKVStore， RheaKVStore 为纯异步实现，所以通常阻塞调用导致的客户端出现瓶颈，理论上不会在 RheaKV 上遭遇，DefaultRheaKVStore 实现包括请求路由、Request 分裂、Response 聚合以及失败重试等功能。 PlacementDriverClient：非必须，作为与 PlacementDriver Server 集群沟通的客户端，通过它获取集群完整信息包括但不仅限于\u0026amp;rdquo;请求路由表\u0026amp;rdquo;，对于无 PD 场景， RheaKV 提供 Fake PD Client。 RegionRouteTable：分片逻辑基于 RegionRouteTable 路由表结构，最适合的数据结构便是跳表或者二叉树(最接近匹配项查询)。作为本地路由表缓存组件，RegionRouteTable 根据 KV 请求的具体失败原因来决策是否从 PD Server 集群刷新数据，并且提供对单个 Key、多个 Key 列表以及 Key Range 进行计算返回对应的分区 ID。选择 Region 的 StartKey 作为 RegionRouteTable 的 Key ，主要取决于 Region Split 的方式，父 Region 分裂成两个子 Region 导致其中一个子 Region 的 StartKey …","date":1558681200,"description":"本文为《剖析 | SOFAJRaft 实现原理》第二篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-jraft-rheakv/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4d79102c8300ca628483bdba44c13049","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv/","publishdate":"2019-05-24T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-jraft-rheakv/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 实现原理 - SOFAJRaft-RheaKV 是如何使用 Raft 的","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-rheakv/","wordcount":5817},{"author":"Linux 中国老王","categories":"SOFAStack","content":" — 本文转载自 Linux 中国老王\n蚂蚁金服的 SOFAStack 作为一个成功地将企业私有项目转化为开源核心模式的知名案例，我们之前对背后的思考和推动力做过专题分析，但是具体这件事是如何在蚂蚁金服内部发生的、是如何实操的，有很多读者向我们表示非常感兴趣，而我觉得这也是其它技术公司所正在探索和思考的方向。\n因此，上个月底，老王在参加上海举办的 KubeCon 2019 时，遇到了蚂蚁金服 SOFA 团队的余淮，他目前在蚂蚁金服中间件团队服务与框架组具体负责开发框架与 SOFAStack 的开源工作。于是，参会之余，我和余淮就 SOFA 开源的实操方面进行了深入的沟通，现将谈话所得整理给大家。\nSOFA 与开源 继去年开始开源 SOFAStack 以来，今年上半年他们又开源了分布式事务框架 Seata 和服务注册中心 SOFARegistry，之前我曾经向蚂蚁金服中间件负责人杨冰了解过为什么要将 SOFA 开源的背后思考，以及 SOFA 发展迭代的历程，详情可以看之前的文章《蚂蚁金服技术总监杨冰：金融科技公司为什么要拥抱开源？ 》进行了解。\n目前，SOFA 的架构已经发展到 SOFA 5 阶段，在今年 2 月，前任 SOFA 开源负责人鲁直还向我分享了 SOFA 5 中重点推进的方向，主要包括 Service Mesh 和 Serverless，以及分布式事务 Seata 的落地，具体内容见文章《蚂蚁金服开源负责人鲁直：不只是中间件，未来会开源更多》。\n作为一个成功的开源核心模式的项目，我非常关注 SOFA 开源的实操是如何进行的，是如何进行开源治理的，作为 SOFA 团队的老朋友，我们话题就直接从 SOFA 的开源治理聊起。\n以 SOFA 为例：公司内部软件的开源流程 余淮说，从 2015 年开始，蚂蚁金服开启了金融科技对外输出的战略，SOFAStack 也走出了蚂蚁金服，甚至跨越了国界，被更多金融机构与合作伙伴所使用，如天弘基金、信美互信、南京银行、PayTM、DANA 钱包等。\n在与合作伙伴以及客户的沟通、合作过程中，他们发现了 SOFAStack 的理念和能力也正是很多金融行业的企业所需要的。在蚂蚁金融科技对外输出的过程中，内部已经对 SOFAStack 进行了一定程度的代码重构，例如历史兼容逻辑的剥离等，但是并未能达到直接开源的标准。\n关于开源，内部一直有开源的讨论，到 2017 年双十一结束后正式决定开源。经过了一系列的准备，2018 年 4 月，完成了对 SOFA 项目的满足了开源改造的标准后，SOFAStack 马上宣布正式开源框架中部分重要组件。\nSOFA 团队采用的开源策略叫「Open Core」，顾名思义就是要将接口层以及核心实现都开源，以可扩展化的方式来层层构建 SOFAStack 的能力，保证 SOFAStack 的内部版本和开源的版本采用的是同一个内核。为此 SOFAStack 做了大量的改造和重构工作。\n在开源的具体考量上，余淮表示，SOFAStack 的开源改造基本上有三条原则，分别是高可扩展性、对内兼容历史版本、对外兼容业界标准。\n以 SOFARPC 重构为例，大概经历了这样的过程：\n 首先需要将 SOFARPC 进行了一次核心接口和模型抽象，然后增加了扩展点机制和事件总线机制，所有的对内对外实现都基于这些核心接口和模型去扩展，并且保证这些扩展能力都是平等的、可选的； 接着将核心的处理逻辑实现迁移到这套接口和模型上来，保证 SOFARPC 能力完整可用； 然后需要将 SOFARPC 里一些对接内部系统的、兼容历史逻辑的代码做成内部扩展，并进行全量测试验证，确保和已有线上的历史方案的兼容，发布上线； 最后会调研业界的一些开源标准方案和实现，并对其进行兼容，例如 SOFARPC 不仅对接自己的 SOFARegistry 的实现，还兼容了 Zookeeper、Etcd、Nacos 等业界优秀的注册中心方案。 虽然上面重构过程听上去没那么复杂，但是在实际过程中还是非常考验团队的技术能力的，特别是在抽象核心接口和模型的时候，为了做到既兼容内部又兼容外部，这需要进行大量的调研工作，才能做好这层较为通用抽象。其次在对内逻辑兼容的时候，由于内部的历史负担还是比较重的，为了能让重构的代码安全上线，团队也做了很多事情。\n还是举 SOFARPC 的例子，蚂蚁金服内部的服务路由过程比开源是要复杂很多的，特别是配合蚂蚁金服特有的单元化部署以及异地多活的能力，有时候需要多层路由才能找到目标地址。为了验证重构后逻辑的正确性，除了在开源代码里有单元测试用例外，SOFA 团队在内部也构建了一套非常完善的集成框架，专门用来测试已有逻辑的兼容性及正确性。\n基于 Open Core 这套思想建设 SOFAStack 以后，其实对开发同学的工作量来不会变少，反而可能是增多的。这是因为在写代码的同时，需要更多的考虑内部外部的使用情况，对代码质量也提出了更高的要求，开发流程会变得更加复杂。\n例如，内部新增一个特性，在以前可能直接修改代码经过测试就发布上线了，但现在的话会去思考这其中哪些能力是通用的，把这些能力抽象一下放到开源版本里去，然后开源版测试后发布，这个时候内部版本在基于这个开源版进行扩展，再经过测试后发布上线。\n虽然开发同学工作变多了，但是这样的话可以让 SOFAStack 的核心代码被更多的开发者 Review，在更多的系统中运行，在更多的场景下进行验证，对 SOFAStack 的品质保证有非常大的帮助。\n此外在开源进度上，余淮表示， SOFAStack 并不追求开源全部内部的组件，而是会根据产品的特性和开源准备的情况有选择的开源。\n例如 SOFAStack 下的分库分表组件，因为产品特性和 OB 等内部结合紧密就暂时不会开源。金融级分布式架构下未开源部分能力，SOFAStack 会和与业界其它优秀的开源项目做集成，保证整个金融级分布式架构功能的完整性和多样性。\n所以对于 SOFAStack 来说，并不只有自己开源的产品，而更多关注的是，和整个社区里所有开源优秀的产品一起，打造一套快速构建金融级分布式架构的套件。\n开源项目管理 开源一个项目，作为背后推动的公司事实上要付出相当多的人力和资金成本，同时，也不可避免的会涉及到审批流程。随着蚂蚁金服越来越多领域的项目开源，包括 SOFAStack，AI，区块链等，蚂蚁金服内部出台了相应的严格的审核机制，包括技术、合规、法务、安全等部门进行审核，同时还会考察项目开源对公司的意义，以及是否对社区有价值，在审核通过之后项目就会正式开源与大家见面了。\n蚂蚁金服对于开源文化是十分友好的，其内部的代码也大多都是公开在内网的 GitLab 仓库，经常会有业务团队对 SOFAStack 提交一些合并请求（拉取请求）来帮助项目的发展。\n同时，蚂蚁金服的工程师也普遍地拥抱开源，开源能够帮助项目产生更多、更好的想法，同时也可以吸收来自社区的贡献，让项目本身能够做的更好，这是大家所喜闻乐见的。 SOFA 的社区治理 开源项目并不是开放源代码就是终点，事实上，这只是开始，之后持续不断的开源治理才是开源之路。而如何将一个开源项目从最开始的由开源项目背后的公司主导转变为社 …","date":1558681200,"description":"SOFAStack 开源如何在蚂蚁金服内部发生、是如何实操的、如何运营，Lunix中国老王进行了采访和分析，欢迎阅读","dir":"blog/sofastack-linux-china/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c1896b9b50b60432bb345d583a9be24a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-linux-china/","publishdate":"2019-05-24T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofastack-linux-china/","summary":"— 本文转载自 Linux 中国老王 蚂蚁金服的 SOFAStack 作为一个成功地将企业私有项目转化为开源核心模式的知名案例，我们之前对背后的思考和推动力做过专题分析，但是具","tags":["SOFAStack"],"title":"大公司开源怎么做？SOFAStack给出了一个很好的例子","type":"blog","url":"/sofastack.tech/blog/sofastack-linux-china/","wordcount":3968},{"author":"花肉","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 活动时间：5 月 26 日周日下午 13 点 活动地点：上海市徐汇区田林路200号A7栋一楼 活动形式：线下活动 报名方式：https://tech.antfin.com/community/activities/576 活动介绍 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。\n欢迎 Star 我：https://github.com/sofastack\nSOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 适合自身企业的技术架构才是最佳的方案，SOFAStack 提供了一套的金融级解决方案，提供多种场景下需要的多种组件。\n5 月 26 日，SOFAMeetup#2 上海站，SOFAStack 开源核心成员集体出动。本期我们将侧重于各个落地的实际场景进行架构解析。\n分布式事务 Seata 详解、与 Spring Cloud 生态的融合案例、使用 SOFAStack 快速构建微服务 Demo 实操、更有最新开源的《让 AI 像 SQL 一样简单 — SQLFlow Demo 》首秀，期待与你不见不散~\n建议：参会者可带上电脑，现场有 Demo 实操环节~\n加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n点击即可报名 https://tech.antfin.com/community/activities/576\n议程 时间 环节 讲师 13:00 - 13:30 签到 13:30 - 14:15 《研发框架 SOFABoot 的特性及落地场景介绍》 蚂蚁金服 SOFABoot 负责人 善逝 14 :15 - 15:00 《谈注册中心 SOFARegistry 架构设计 》 蚂蚁金服 SOFARegistry 负责人 琪祥 15:00 - 15:05 茶歇休息 15:05 - 15:15 《SOFALab 社区共建分享》 SOFALab 杰出贡献者 米麒麟 15:15 - 16:00 《当 SpringCloud 遇上 SOFAStack》 蚂蚁金服 SOFAStack 开源组核心负责人 玄北 16:00 - 16:45 《分布式事务 Seata 实现原理及实践详解》 Seata Committer 绍辉 16:45 - 17:30 《使用 SOFAStack 快速构建微服务》SOFADashboard 演示 + SOFARegistry + SOFARPC + SOFAArk 蚂蚁金服 SOFADashboard 负责人 卫恒 17:30 - 17:45 《让 AI 像 SQL 一样简单 — SQLFlow Demo 演示》 蚂蚁金服深度学习引擎开源产品负责人 三平 ","date":1558437600,"description":"SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务，5 月 26 日周日下午 13 点，上海市徐汇区田林路200号A7栋一楼。","dir":"activities/sofa-meetup-2/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5765309cb693fc8cc45958ecab5a9c3b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-2/","publishdate":"2019-05-21T11:20:00Z","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-meetup-2/","summary":"概要 活动主题：SOFA Meetup#2 上海站-使用 SOFAStack 快速构建微服务 活动时间：5 月 26 日周日下午 13 点 活动地点：上海市徐汇区田林路200号A7栋一楼 活动形式：线","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#2 上海站——使用 SOFAStack 快速构建微服务","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-2/","wordcount":849},{"author":"SOFA 团队","categories":"SOFAStack","content":" SOFAStack 启用独立 Group ，社区更加开放 今日，SOFAStack 将启用独立 Group： https://github.com/sofastack\n感谢大家的一路支持，未来，我们继续相伴~\n背景：分布式架构 SOFAStack 开源历史 金融级分布式架构 SOFAStack 产生于蚂蚁金服内部需求，起初是为了解决高速发展下的业务问题。到 2019 年，已经历12年的业务锤炼，变成了一套成熟的金融级最佳实践。\nSOFAStack 的发展受益于开源社区的优秀产品，我们也决定结合我们的实践积累，把这些技术反馈给开源社区。\n2018 年 4 月，SOFAStack 宣布开源。这一年，SOFAStack 逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFABolt、SOFAMosn、SOFAMesh、SOFAJRaft、SOFAActs、SOFARegistry、SOFADashboard 等组件。2019 年 3 月，蚂蚁金服加入分布式事务Seata的社区共建中，并贡献其 TCC 模式。\nSOFAStack 未来也将持续开源，丰富生态。\nSOFA 开源全景图，涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的 Nacos、Sentinel 等，为用户提供更加广泛地选择。\nSOFAStack 启用独立 Group 和邮件订阅列表 为了开源管理更加清晰，更社区化的运作，更中立的技术态度，开放给更多的开发者和企业参与，SOFAStack 将启用独立 Group：\n SOFAStack 项目地址： https://github.com/sofastack 原项目地址： https://github.com/alipay 继续可访问，会跳转到新的地址上。\n 邮件订阅列表 加入 SOFAStack 邮件组 https://groups.google.com/forum/#!forum/sofastack 获取邮件订阅。\n感谢大家的一路支持，未来，我们继续相伴~\n","date":1557990000,"description":"SOFAStack 将启用独立 Group，社区更加开放今日。感谢大家的一路支持，未来，我们继续相伴","dir":"blog/sofastack-independent-droup/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f25b8521e498ebce982a98b882f941b3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-independent-droup/","publishdate":"2019-05-16T15:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofastack-independent-droup/","summary":"SOFAStack 启用独立 Group ，社区更加开放 今日，SOFAStack 将启用独立 Group： https://github.com/sofastack 感谢大家的一路支持，未来，我们继续相伴~ 背景：分布式架构 SOFAStack 开源历史","tags":["SOFAStack"],"title":"持续技术开放 | SOFAStack 启用独立 Group","type":"blog","url":"/sofastack.tech/blog/sofastack-independent-droup/","wordcount":617},{"author":"SQLFlow","categories":"SQLFlow","content":" 5 月 6 日，在 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow，他在演讲中表示：“未来三年，AI 能力会成为每一位技术人员的基本能力。我们希望通过开源 SQLFlow，降低人工智能应用的技术门槛，让技术人员调用 AI 像 SQL 一样简单。”\nSQLFlow 的目标是将 SQL 引擎和 AI 引擎连接起来，让用户仅需几行 SQL 代码就能描述整个应用或者产品背后的数据流和 AI 构造。其中所涉及的 SQL 引擎包括 MySQL、Oracle、Hive、SparkSQL、Flink 等支持用 SQL 或其某个变种语言描述数据，以及描述对数据的操作的系统。而这里所指的 AI 引擎包括 TensorFlow、PyTorch 等深度学习系统，也包括 XGBoost、LibLinear、LibSVM 等传统机器学习系统。\nSQLFlow 开源项目链接：https://sqlflow.org/sqlflow\n5 月 26 日，将在上海迎来 SQLFlow 线下首秀 —《让 AI 像 SQL 一样简单— SQLFlow Demo》，还有 SOFAStack 开源生态交流分享，点击链接，即可报名~期待你的到来~\nhttps://tech.antfin.com/community/activities/576\nSQLFlow 的研发团队认为，在 SQLFlow 和 AI 引擎之间存在一个很大的空隙——如何把数据变成 AI 模型需要的输入。谷歌开源的 TensorFlow 项目开了一个好头，TFX Data Transform 和 feature column API 都是意图填补这个空缺的项目。但是这个空缺很大，是各种 SQL 引擎和各种 AI 引擎的笛卡尔积，远不是 TensorFlow 的这两个子项目就足以填补的，需要一个开源社区才行。要填补好这个空缺，需要先让用户意识到其重要性，这也是蚂蚁金服开源 SQLFlow 的意图之一。\nSQLFlow 位于 AI 软件系统生态的最顶端，最接近用户，它也位于数据和数据流软件生态之上。\n其实，将 SQL 和 AI 连接起来这个想法并非 SQLFlow 原创。谷歌于 2018 年年中发布的 BigQueryML 同样旨在“让数据科学家和分析师只用 SQL 语言就可以实现流行的机器学习功能并执行预测分析”。除了 Google 的 BigQueryML，微软基于 SQL Server 的 AI 扩展，以及 Teradata 的 SQL for DL 同样旨在连接 SQL 和 AI，让人工智能的应用变得像 SQL 一样简单。而 SQLFlow 与上述各个系统最根本的差异在于：SQLFlow 是开源的，以上系统都不是。\n开发 SQLFlow 的初衷 蚂蚁金服和很多互联网公司一样，不同产品背后有很多功能都依赖于 AI，比如用户信用的评估就是一套预测模型。到目前为止，每一个这样的功能的实现，都依赖一个工程师团队开发多个子系统——读取数据库或者在线日志流、这两类数据的 join、各种数据筛选、数据到模型输入（常说的 features）的映射、训练模型、用训练好的模型来做预测。整个过程下来耗时往往以月计，如果加班加点放弃写 unit test 代码，可能缩短到以周记。\n以上问题正是 SQLFlow 系统希望替工程师们解决的问题。蚂蚁金服拥有数千数据分析师，他们日常工作用的就是 SQL 语言。虽然数据分析师在互联网行业往往不像用 Python、Java、C++ 的工程师那样醒目，但是在很多有面向商业伙伴的业务的公司里，比如 LinkedIn，他们的贡献和人数都能与工程师相匹敌。SQLFlow 最早的初衷，就是希望解决分析师既要操作数据又要使用 AI、往往需要在两个甚至更多的系统之间切换、工作效率低的窘境。\nSQLFlow 旨在大幅提升效率，让上述功能实现所花费的时间进一步缩短到能以日计，甚至以小时计的程度。\n要达到这样的效率，必须有一种效率极高的描述工作意图的方式。SQL 是一种典型的描述意图，而不描述过程的编程语言。用户可以说我要 join 两个表，但是不需要写循环和构造 hash map 来描述如何 join 两个表。这个特性使得 SQL 能极大地提升开发效率，这正是 SQLFlow 选择扩展 SQL 语法支持 AI 这条思路的原因。\n不过，高效率的背后是更大的工程技术挑战。SQLFlow 需要做到能根据用户的意图，自动生成达到意图的 Python、C++、Go 语言的程序。\nSQLFlow 的架构设计 设计目标 在连接 SQL 和 AI 应用这一方向上，业内已有相关工作。开发者可以使用像 DOT_PRODUCT 这样的运算符在 SQL 中编写简单的机器学习预测（或评分）算法。但是，从训练程序到 SQL 语句需要进行大量的模型参数复制粘贴的工作。目前在一些商业软件中，已经有部分专有 SQL 引擎提供了支持机器学习功能的扩展。\n Microsoft SQL Server：Microsoft SQL Server 支持机器学习服务，可以将 R 或 Python 编写的机器学习程序作为外部脚本运行。 Teradata SQL for DL：Teradata 也提供了 RESTful 服务，可以通过扩展的 SQL SELECT 语法调用。 Google BigQuery：Google BigQuery 通过引入 CREATE MODEL 语句让用 SQL 实现机器学习成为可能。 但上述已有的解决方案都无法解决蚂蚁金服团队的痛点，他们的目标是打造一个完全可扩展的解决方案。\n 这一解决方案应与许多 SQL 引擎都兼容，而不是只能兼容特定版本或类型的 SQL 引擎。 它应该支持复杂的机器学习模型，包括用于深度学习的 TensorFlow 和用于树模型的 XGBoost。 能够灵活地配置和运行前沿机器学习算法，包括指定特征交叉，无需在 SQL 语句中嵌入 Python 或 R 代码，以及完全集成超参数估计等。 应对上述挑战的关键在于打造一套 SQL 扩展语法。研发团队首先从仅支持 MySQL 和 TensorFlow 的原型开发开始，后续计划支持更多 SQL 引擎和机器学习工具包。\n从 SQL 到机器学习 SQLFlow 可以看作一个翻译器，它把扩展语法的 SQL 程序翻译成一个被称为 submitter 的程序，然后执行。 SQLFlow 提供一个抽象层，把各种 SQL 引擎抽象成一样的。SQLFlow 还提供一个可扩展的机制，使得大家可以插入各种翻译机制，得到基于不同 AI 引擎的 submitter 程序。\nSQLFlow 对 SQL 语法的扩展意图很简单：在 SELECT 语句后面，加上一个扩展语法的 TRAIN 从句，即可实现 AI 模型的训练。或者加上一个 PREDICT 从句即可实现用现有模型做预测。这样的设计大大简化了数据分析师的学习路径。\n此外，SQLFlow 也提供一些基本功能，可以供各种 submitter 翻译插件使用，用来根据数据的特点，推导如何自动地把数据转换成 features。这样用户 …","date":1557903600,"description":"本文整理于 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow 的现场演讲。","dir":"blog/sqlflow-open-source/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fcd6535619144aec695ee9afbf2fc36b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sqlflow-open-source/","publishdate":"2019-05-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sqlflow-open-source/","summary":"5 月 6 日，在 QCon 全球软件开发大会（北京站）2019 上，蚂蚁金服副 CTO 胡喜正式宣布开源机器学习工具 SQLFlow，他在演讲中表示：“未来三年，AI","tags":["SQLFlow"],"title":"蚂蚁金服开源机器学习工具 SQLFlow，技术架构独家解读","type":"blog","url":"/sofastack.tech/blog/sqlflow-open-source/","wordcount":5106},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs\n活动时间：5 月 16 日周四晚 7 点\n活动形式：线上直播\n报名方式：https://tech.antfin.com/activities/552\n介绍 | SOFAChannel\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs\n如何自动生成测试用例？\n如何减少测试用例设计过程中的阻力？\n如何进行精细化校验以及用例的高效管理，从而保障代码质量，有效提高测试效率？\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 线上直播第 5 期《给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs》报名开启！\n5 月 16 日周四晚 7 点，围绕蚂蚁金服的多年测试实践的积累与沉淀，自动化测试框架 SOFAActs 核心成员青勤将为大家带来精彩分享，不要错过哦。\nSOFAActs 是基于数据模型驱动测试引擎的的新一代测试框架，它的数据以 YAML 为载体，在此上构建基于数据模型的驱动引擎，适配 TestNg+SOFABoot 的测试上下文环境；支持高效、标准化构建用例，可视化编辑测试数据，精细化校验结果数据和自动清理 DB 数据，可以有效降低人工录入用例数据的成本，同时支持 API 重写提高测试代码的可扩展可复用性，提供特有注解提高测试代码编排的灵活性。\n| 加入 SOFA 钉钉互动群\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n| 点击即可报名\nhttps://tech.antfin.com/activities/552\n议程 19:00-19:05 主持人开场\nSOFAGirl 主持人\n19:05-20:00 给研发工程师的代码质量利器 — 自动化测试框架 SOFAActs\n青勤 蚂蚁金服自动化测试框架 SOFAActs 核心成员\n本期分享大纲：\n 蚂蚁金服接口自动化测试理念 如何接入 SOFAActs 自动化测试框架 SOFAActs 自动化测试框架的基本使用 嘉宾 SOFAGirl 主持人 青勤 蚂蚁金服自动化测试框架 SOFAActs 核心成员 ","date":1557310800,"description":"5 月 16 日周四晚 7 点，线上直播。","dir":"activities/sofa-channel-5/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e000553c2c76f43ed8df5b8e56491a7b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-5/","publishdate":"2019-05-08T10:20:00Z","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-5/","summary":"概要 活动主题：SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs 活动时间：5 月 16 日周四晚 7 点 活动形式：线上直播 报名方","tags":["SOFAChannel","SOFAActs"],"title":"SOFAChannel#5：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs","type":"activities","url":"/sofastack.tech/activities/sofa-channel-5/","wordcount":733},{"author":"米麒麟","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\n本文为《剖析 | SOFAJRaft 实现原理》第一篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:JRaftLab/，文章尾部有参与方式，欢迎同样对源码热情的你加入。\nSOFAJRaft ：https://github.com/sofastack/sofa-jraft\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。\nSOFAJRaft 存储模块分为：\n Log 存储记录 Raft 配置变更和用户提交任务日志； Meta 存储即元信息存储记录 Raft 实现的内部状态； Snapshot 存储用于存放用户的状态机 Snapshot 及元信息。 本文将围绕日志存储，元信息存储以及快照存储等方面剖析 SOFAJRaft 存储模块原理，阐述如何解决 Raft 协议存储问题以及存储模块实现：\n Raft 配置变更和用户提交任务日志如何存储？如何调用管理日志存储？ SOFAJRaft Server 节点 Node 是如何存储 Raft 内部配置？ Raft 状态机快照 Snapshot 机制如何实现？如何存储安装镜像？ 日志存储 Log 存储，记录 Raft 配置变更和用户提交任务的日志，把日志从 Leader 复制到其他节点上面。\n LogStorage 是日志存储实现，默认实现基于 RocksDB 存储，通过 LogStorage 接口扩展自定义日志存储实现； LogManager 负责调用底层日志存储 LogStorage，针对日志存储调用进行缓存、批量提交、必要的检查和优化。 LogStorage 存储实现 LogStorage 日志存储实现，定义 Raft 分组节点 Node 的 Log 存储模块核心 API 接口包括：\n 返回日志里的首/末个日志索引； 按照日志索引获取 Log Entry 及其任期； 把单个/批量 Log Entry 添加到日志存储； 从 Log 存储头部/末尾删除日志； 删除所有现有日志，重置下任日志索引。 Log Index 提交到 Raft Group 中的任务序列化为日志存储，每条日志一个编号，在整个 Raft Group 内单调递增并复制到每个 Raft 节点。LogStorage 日志存储实现接口定义入口：\ncom.alipay.sofa.jraft.storage.LogStorage RocksDBLogStorage 基于 RocksDB 实现 Log Structured Merge Tree 简称 LSM ，把一颗大树拆分成 N 棵小树，数据首先写入内存，内存里构建一颗有序小树，随着小树越来越大，内存的小树 Flush 到磁盘，磁盘中的树定期做合并操作合并成一棵大树以优化读性能，通过把磁盘的随机写转化为顺序写提高写性能，RocksDB 就是基于 LSM-Tree 数据结构使用 C++ 编写的嵌入式 KV 存储引擎，其键值均允许使用二进制流。RocksDB 按顺序组织所有数据，通用操作包括 get(key), put(key), delete(Key) 以及 newIterator()。RocksDB 有三种基本的数据结构：memtable，sstfile 以及 logfile。memtable 是一种内存数据结构\u0026amp;ndash;所有写入请求都会进入 memtable，然后选择性进入 logfile。logfile 是一种有序写存储结构，当 memtable 被填满的时候被刷到 sstfile 文件并存储起来，然后相关的 logfile 在之后被安全地删除。sstfile 内的数据都是排序好的，以便于根据 key 快速搜索。\nLogStorage 默认实现 RocksDBLogStorage 是基于 RocksDB 存储日志，初始化日志存储 StorageFactory 根据 Raft节点日志存储路径和 Raft 内部实现是否调用 fsync 配置默认创建 RocksDBLogStorage 日志存储。基于 RocksDB 存储实现 RocksDBLogStorage 核心操作包括：\n init()：创建 RocksDB 配置选项调用 RocksDB#open() 方法构建 RocksDB 实例，添加 default 默认列族及其配置选项获取列族处理器，通过 newIterator() 生成 RocksDB 迭代器遍历 KeyValue 数据检查 Value 类型加载 Raft 配置变更到配置管理器 ConfigurationManager。RocksDB 引入列族 ColumnFamily 概念，所谓列族是指一系列 KeyValue 组成的数据集，RocksDB 读写操作需要指定列族，创建 RocksDB 默认构建命名为default 的列族。 shutdown()：首先关闭列族处理器以及 RocksDB 实例，其次遍历列族配置选项执行关闭操作，接着关闭RocksDB 配置选项，最后清除强引用以达到 Help GC 垃圾回收 RocksDB 实例及其配置选项对象。 getFirstLogIndex()：基于处理器 defaultHandle 和读选项 totalOrderReadOptions 方法构建 RocksDB 迭代器 RocksIterator，检查是否加载过日志里第一个日志索引，未加载需调用 seekToFirst() 方法获取缓存 RocksDB 存储日志数据的第一个日志索引。 getLastLogIndex()：基于处理器 defaultHandle 和读选项 totalOrderReadOptions 构建 RocksDB 迭代器 RocksIterator，调用 seekToLast() 方法返回 RocksDB 存储日志记录的最后一个日志索引。 getEntry(index)：基于处理器 defaultHandle 和指定日志索引调用 RocksDB#get() 操作返回 RocksDB 索引位置日志 LogEntry。 getTerm(index)：基于处理器 defaultHandle 和指定日志索引调用 RocksDB#get() 操作获取 RocksDB 索引位置日志并且返回其 LogEntry 的任期。 appendEntry(entry)：检查日志 LogEntry 类型是否为配置变更，配置变更类型调用 RocksDB#write() 方法执行批量写入，用户提交任务的日志基于处理器 defaultHandle 和 LogEntry 对象调 …","date":1557066600,"description":"本文为《剖析 | SOFAJRaft 实现原理》第一篇，本篇作者米麒麟，来自陆金所。。","dir":"blog/sofa-jraft-algorithm-storage-module-deep-dive/","fuzzywordcount":6400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b48c76bf76b0c77d11af1a6265c9b78b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","publishdate":"2019-05-05T14:30:00Z","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft","tags":["SOFAJRaft","SOFALab","剖析 | SOFAJRaft 实现原理"],"title":"SOFAJRaft 实现原理 - 生产级 Raft 算法库存储模块剖析","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/","wordcount":6384},{"author":"卫恒","categories":"SOFADashboard","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 为了建设更完整的 SOFAStack 微服务体系，我们计划发起 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。欢迎共建~ SOFADashboard：https://github.com/sofastack/sofa-dashboard  背景 从 2018 年 4 月 19 日宣布开源至今，SOFAStack 目前已经开源了包括 SOFABoot、 SOFARPC、SOFALookout、SOFATracer、SOFARegistry 等在内的一系列微服务相关的项目，并投入分布式事务 Seata 进行重要贡献。随着 SOFAStack 架构体系的不断丰富和完善，外部对于 SOFAStack 的管控平台的需求也愈加强烈。\n由于 SOFAStack 内部的管控平台依赖众多的内部基础设施，为了建设更完整的 SOFAStack 微服务体系，我们计划发起全新的 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。\n能力大图 SOFADashboard 作为一站式 SOFAStack 管控台，希望对 SOFAStack 各个组件的使用等进行统一管理。为此我们为 SOFADashboard 规划一版能力图，包含了微服务里的一些能力点，例如应用信息管理、服务治理、配置管控、动态模块等等。见下图所示：\n每个能力点对应的实现我们都做了一层抽象。例如服务查看需要从注册中心获取数据，我们封装了一层服务列表获取接口，底层可以是从 Zookeeper 或者 SOFARegistry 等不同的注册中心实现读取服务列表。\n技术栈选择 为了最大限度的降低开发成本、部署成本及运维成本，SOFADashboard 会基于开源社区优秀的产品来进行开发构建。经过讨论，最终选择社区主流的前后端分离思路，具体的组件包括：\n Ant Design：基于 React封装的一套 Ant Design 的组件库，主要用于研发企业级中后台产品。从产品成熟度、社区活跃度、框架上手难易程度等各个方面均有很好的表现。 SOFABoot：蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。 MyBatis：Mybatis 相对于 JPA 来说，上手难度略低，JPA 更加倾向于结合 DDD 使用(业务越复杂，对于DDD 的需求越高)；对于简单的增删改查业务操作，Mybatis 相对来说更灵活和可控。 v1.0 发布 4 月 30 日，我们上传了第一个 SOFADashboard 版本，主要能力包括：应用信息、服务查看、动态模块管控等。\n目前演示地址：http://dashboard.dev.sofastack.tech:8000/ 详细设计图 基础依赖 从架构图中可以看到，目前 SOFADashboard 中的服务治理、SOFAArk 管控等需要依赖于 Zookeeper 和 MySQL；它们承担的解决如下：\n 外部依赖 作用 备注 Zookeeper 注册中心 SOFARPC 服务治理 配置推送 SOFAArk 管控 MySql 资源存储 注册的 ark-biz 信息，插件与应用的关联信息，插件版本信息等 应用面板 SOFADashboard 支持查看应用的 IP、端口、健康检查状态等基本信息，此功能依赖 SOFADashboard client。SOFADashboard client 用于向 SOFADashboard 服务端注册 IP、端口、健康检查状态等应用基本信息；SOFADashboard client 并非是直接通过 API 调用的方式将自身应用信息直接注册到 SOFADashboard 服务端 ，而是借助于 Zookeeper 来完成。\n客户端向 Zookeeper 中如上图所示的节点中写入数据，每一个 ip:port 节点代表一个应用实例，应用本身信息将写入当前节点的 data 中。\n如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可，具体使用参考 SOFADashboard client 快速开始 。\n服务治理 SOFADashboard 服务治理是对 SOFARPC 的服务进行管理，服务治理管控台部分，主要包括基于服务名查询和服务信息列表展示两个基础能力。在服务治理管控台界面，可以直观的看到当前服务的一些基本元数据信息：\n当点击 服务 ID 对应的超链接时，会进入到当前服务的详情页；服务提供者详情页中，可以看到当前服务所有的提供方信息列表，每个 item 行对应一个服务提供方实例，通过此界面可以快速查看服务的 providers 信息。\n服务消费者详情页中，可以看到当前服务所有的消费方信息列表。\nSOFAArk 管控 SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAArk 管控是 SOFADashboard 针对 API 管控的一种实现。通过面向 Zookeeper 进行命令的推送和命令的解析执行。SOFAArk 管控主要包括以下功能：\n 插件注册 将 ark-biz 插件注册到 SOFADashboard，作为基础数据，统一管控。\n插件基本信息录入：\n插件列表：\n 关联应用 将 ark-biz 插件与宿主应用进行绑定，此关联信息在 SOFAArk 多应用（模块）合并部署中作为重要的基础信息存在。在后续的操作中，可以通过此关联关系查看到某个插件下挂载的应用信息。\n 插件详情 通过插件详情页，可以看下当前 ark-biz 插件下所有关联的宿主应用信息，以及宿主应用中的 ark-biz 状态信息，插件详情页中，可以查看所有关联此插件的应用中，插件的状态信息。\n 命令推送 命令推送是 SOFADashboard 中提供 SOFAArk 管控的核心能力，通过面向 Zookeeper 编程的方式，将指令信息传递给各个宿主应用中的 ark-biz 模块，ark-biz 在接收到相关指令之后再进行相应的行为，如安装、切换、卸载等。\n可以针对应用维度、IP 维度推送一些指令，比如 install、uninstall 等等，当这些命令被写入到 Zookeeper 的某个节点上时，所有监听此节点的宿主应用均会解析此指令，并进行相关的操作。\n基于 IP 维度推送如图例所示，每个应用实例表单默认会有对应的操作，可以通过展示的命令按钮操作当前实例行为：\n点击 安装按钮，延迟 1~1.5s 之后 界面将会刷 …","date":1557039600,"description":"为了建设更完整的 SOFAStack 微服务体系，我们计划发起 SOFADashboard 项目，计划通过社区的方式共建，将其打造为一站式的 SOFAStack 管控平台。欢迎共建~","dir":"blog/sofa-dashboard-open-source/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f9a78639fd427da4c3ea19d32e8420e7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-dashboard-open-source/","publishdate":"2019-05-05T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-dashboard-open-source/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 为了建设更完整","tags":["SOFADashboard"],"title":"SOFADashboard 启动开源共建 | SOFAStack 一站式管控平台","type":"blog","url":"/sofastack.tech/blog/sofa-dashboard-open-source/","wordcount":2602},{"author":"老王","categories":"SOFAStack","content":" 本文转自 Linux 中国\n谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。\u0026amp;ndash; 老王\n二月初春，在西子湖畔的细雨中，我拜访了蚂蚁金服中间件团队，和 SOFA 技术负责人鲁直做了一次深入交谈，更妙的是，鲁直也是负责 SOFA 开源事务推进的人，而这样一个切实践行开放核心模式的开源项目，也正是我非常感兴趣的。\n两个技术人的谈话，自然是朴实而直白的，话题主要围绕着 SOFA 和开源主题展开，希望也能一样引起同是技术人的你的共鸣。\n 人物介绍 受访者：鲁直，蚂蚁金服 SOFA 开源负责人。 采访者：老王，开源布道人，有 20 年互联网从业经历的技术老兵。\n 虽然我和鲁直在微信上已经联系很久了，但这还是第一次见面。交谈中，我了解到鲁直是 2009 年加入阿里巴巴工作，已经有十年了。刚开始是在 1688.COM 做业务系统，对中间件技术非常感兴趣，也会经常研究各种中间件的实现和功能。后来在 2013年时，为了更深入地学习研究中间件框架，转到了蚂蚁金服中间件团队，从那个时候开始就一直在做 SOFA。\n目前鲁直在 SOFA 的团队主要负责的工作包括几个部分。其中一个主要部分就是 SOFA 开源相关的工作。SOFA 的产品体系非常广，包括已经对外开源的部分、内部整个微服务体系，以及 SOFA 框架等等——而这些开源相关的工作主要是由鲁直负责推动的。\n当然，作为技术负责人，鲁直既要带技术团队也要做技术工作。谈及这一点，鲁直说：\n“我觉得做技术管理，跟普通的管理不太一样，因为技术管理最重要的一个点是除了管理之外，还要保持一定的技术判断力和敏锐度。对一些新技术，包括团队中遇到一些重大的技术问题，你都要有一些方向性的判断。虽然最后不一定是你具体解决的，但是在整个团队的技术攻坚和技术选型上，要一起确立方向。”\n我以前也做过十余年的技术管理，我很能够感受这种情况，重大问题技术负责人更要迎难而上。\nSOFA 5 落子 Service Mesh 就我了解的情况，现在 SOFA 已经发展到了 SOFA5 了。在 SOFA4 阶段，主要的任务是将开源体系捋清楚了，然后开始按步骤地开源；到现在发展到了 SOFA5。我想知道从 SOFA4 发展到 SOFA5，是什么让蚂蚁金服中间件团队判断 SOFA4 的阶段性目标已经达成，可以迈进到新的 SOFA5 阶段了呢？\n “从整个业界趋势上来讲，SOFA4 的架构相对来说还是偏传统一些，更多是对我们之前的技术框架的整理和梳理。在这个阶段，SOFA 的代码经过了非常多的优化和重构，才达到了对外开源的要求，从而 SOFA 走上了开源核心的模式，逐步分阶段的将各个部分进行了开源。”鲁直讲到，“但是，从我们对业界的整体判断上来说，未来无疑是云的时代，所以说要考虑怎么让所有的业务系统能够提供云的能力，比如说 Serverless。”\n接着这个话题，鲁直讲了他对云计算的理解：“一方面云计算肯定要为整个业务的发展提供更加方便的基础资源，可以不用去关心底层的基础设施。Serverless 字面的意思就是说‘无服务器’——我不用关心服务器怎么来的，不用关心基础设施，只要关心业务代码就可以了。那反过来对于云服务商来说，经过了这一层抽象，其资源利用率会更高，可以有更多的利润空间，这是一个双赢的局面。对于用户来讲，这种好处是实实在在的，可以更少关注基础设施，只关心代码就可以了。”\n  “我们希望在 SOFA5 的方向上，在这个新的迭代中，去让业务——包括让未来我们开源出来各种功能、各样服务模式——都更多地去关心自己的业务代码，而不用再过多地关心基础设施。”鲁直说。\n 在 SOFA5 中，一个重要的方向就是 Service Mesh 这个方向，这将是 SOFA5 中非常重要的特性。鲁直强调了其对 Service Mesh 技术的看好：“我认为 Service Mesh 是迈向未来往前走的非常关键的一步，让业务不用再关心基础设施。通过 Service Mesh，我们可以将很多技术能力直接放到基础设施里面，而业务可以不用感知到这一层。原来可能需要花几个小时或者更多的时间解决的基础设施问题，现在可以通过 Service Mesh 解决掉。”\n“目前我们我们已经在生产环境中应用了 Service Mesh。我们在这方面有非常大的决心，我们希望能够在今年，在更大的范围中去落地 Service Mesh。当前这个阶段更聚焦在这种技术的内部落地上，希望用好了，再给社区做更多的贡献。”\n Service Mesh 这个词最早是由开发 Linkerd 的 Buoyant 公司于 2016 年提出的，随着 Linkerd 的传入，Service Mesh 也进入国内技术社区的视野。Service Mesh 也被翻译为“服务网格”。Linkerd 则是业界第一个 Service Mesh。 Service Mesh 是一个基础设施层，用于处理服务间通信，负责实现请求的可靠传递。在实践中，服务网格通常实现为轻量级网络代理，通常与应用程序部署在一起，但是对应用程序透明。\nService Mesh 的部署模型，有两种情况： ◈ 对于一个简单请求，作为请求发起者的客户端应用实例，会首先用简单方式将请求发送到本地的 Service Mesh 实例。这是两个独立进程，它们之间是远程调用。Service Mesh 会完成完整的服务间调用流程，如服务发现负载均衡，最后将请求发送给目标服务。这就是 Sidecar，它在原有的客户端和服务端之间加多了一个代理。 ◈ 多个服务调用的情况，Service Mesh 出现在所有的服务的下面，这一层被称之为服务间通讯专用基础设施层。Service Mesh 会接管整个网络，把所有的请求在服务之间做转发。在这种情况下，上面的服务不再负责传递请求的具体逻辑，只负责完成业务处理。服务间通讯的环节就从应用里面剥离出来，呈现出一个抽象层。\n如果有大量的服务，Sidecar 之间的连接就会形成一个网络，这个就是服务网格名字的由来。\n “我们将以 Service Mesh 为跳板再往前走。”鲁直表示，“Serverless 更多的还是应该聚焦在其字面本身，其含义就是‘无服务器’，后面的技术都是为了让无服务器承载具体的业务。”\nServerless 这个概念虽然提出来已经有几年了，目前 AWS 在 Serverless 和 FaaS 方面处于比较前沿的位置，但是在国内，Serverless、FaaS 这些技术的发展还是相对比较滞后。\n鲁直指出，“我觉得 Serverless 想要成功，还是要从覆盖业务的整个广度上打开，否则可能还是停留在 FaaS 上，那场景就比较受限。”\n Service Mesh 将是微服务的下一个时代，关于它还在持续进行理论研究和实践探索。\n 鲁直说：“坦白来讲，我觉得 istio 的理念非常好，但是在整个工程设计上，如果放到蚂蚁金服这样体量较大的环境里面，可能跑起来还需要做一些工作。我们希望今年 Service Mesh 在蚂蚁金服有了更大规模落地之后，可以把我们在 Service Mesh 方面的一些实践经验用到产品环境的工程中去实践，然后贡献出去。目前更多的一些工作，是将整个 …","date":1556607600,"description":"谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。-- 老王","dir":"blog/antfin-middleware-open-source-key-figure-luzhi/","fuzzywordcount":6000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6779f59b05648131b0d635a71cd95d0d","permalink":"https://sofastack.github.io/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","publishdate":"2019-04-30T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","summary":"本文转自 Linux 中国 谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。\u0026ndash; 老王 二月初春，在西子湖畔的细雨中，我拜访了蚂蚁金服中间","tags":["SOFAStack"],"title":"对话鲁直：蚂蚁金服中间件的开源头羊 | 穿山甲专访","type":"blog","url":"/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/","wordcount":5979},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nGitHub 地址：https://github.com/sofastack/sofa-jraft\n之前，我们有一篇介绍 SOFAJRaft 的文章，可在文末获得链接，延续这个内容，今天的演讲分为三部分，先简要介绍 Raft 算法，然后介绍 SOFAJRaft 的设计，最后说说它的优化。\n分享嘉宾：力鲲 蚂蚁金服 SOFAJRaft 核心成员\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务。 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\nLeader 选举 复制状态机集群在利用 Raft 算法保证一致性时，要做的第一件事情就是 Leader 选举。在讲 Leader 选举之前我们先要说一个重要的概念：Term。Term 用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求；\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳；\n 当然了，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。\n当选举 Leader 成功之后，整个集群就可以向外提供正常读写服务了，如图所示，集群由一个 Leader 两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳或者把 Log 复制给 Follower。\nLog 复制 下面我们就详细说一下 Log 复制。我们之前已经说了 Log 就是 Client 发送给复制状态机的一系列命令。这里我们再举例解释一下 Log，比如我们的复制状态机要实现的是一个银行账户系统，那么这个 Log 就可以是 Client 发给账户系统的一条存钱的命令，比如“存 100 元钱”。\nLeader 与 Follower 之间的日志复制是共识算法运用于复制状态机的重要目的，在 Raft 算法中 Log 由 TermId、LogIndex、LogValue 这三要素构成，在这张图上每一个小格代表一个 Log。当 Leader 在向 Follower 复制 Log 的时候，Follower 还需要对收到的 Log 做检查，以确保这些 Log 能和本地已有的 Log 保持连续。我们之前说了，Raft 算法是要严格保证 Log 的连续性的，所以 Follower 会拒绝无法和本地已有 Log 保持连续的复制请求，那么这种情况下就需要走 Log 恢复的流程。总之，Log 复制的目的就是要让所有的 Server 上的 Log 无论在内容上还是在顺序上都要保持完全一致，这样才能保证所有状态机执行结果一致。\n目前已经有一些很优秀的对 Raft 的实现，比如 C++ 写的 braft，Go 写的 etcd，Rust 写的 TiKV。当然了，SOFAJRaft 并不是 Raft 算法的第一个 Java 实现，在我们之前已经有了很多项目。但是经过我们的评估，觉得目前还是没有一个 Raft 的 Java 实现库类能够满足蚂蚁生产环境的要求，这也是我们去写 SOFAJRaft 的主要原因。\nSOFAJRaft 介绍 接下来我们介绍 SOFAJRaft。 SOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。从去年 3 月开发到今年 2 月完成，并在今年 3 月开源。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统，目前使用案例有 RheaKV，这是 SOFAJRaft 中自带的一个分布式 KV 存储，还有今天开源的 SOFA 服务注册中心中的元信息管理模块也是用到了 SOFAJRaft，除此之外还有一些内部的项目也有使用，但是因为没有开源，所以就不再详述了。\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依 …","date":1556202600,"description":"本文根据 SOFAChannel#4 直播分享整理，主题：SOFAJRaft 详解。","dir":"blog/sofa-jraft-deep-dive/","fuzzywordcount":5700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f2d4559ece4184ef09b96899a1aeb900","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-deep-dive/","publishdate":"2019-04-25T14:30:00Z","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-jraft-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFAJRaft","剖析 | SOFAJRaft 实现原理","SOFALab"],"title":"蚂蚁金服开源 SOFAJRaft 详解| 生产级高性能 Java 实现","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-deep-dive/","wordcount":5688},{"author":"琪祥","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。 GitHub 地址：https://github.com/sofastack/sofa-registry \n 3 月 31 日，蚂蚁金服正式开源了内部演进了近 10 年的注册中心产品-SOFARegistry。先前的文章介绍了 SOFARegistry 的演进之路，而本文主要对 SOFARegistry 整体架构设计进行剖析，并着重介绍一些关键的设计特点，期望能帮助读者对 SOFARegistry 有更直接的认识。\n如有兴趣，也欢迎加入《剖析 | SOFARegistry 实现原理》系列的共建，认领列表见文末。\n服务注册中心是什么 不可免俗地，先介绍一下服务注册中心的概念。对此概念已经了解的读者，可选择跳过本节。\n如上图，服务注册中心最常见的应用场景是用于 RPC 调用的服务寻址，在 RPC 远程过程调用中，存在 2 个角色，一个服务发布者（Publisher）、另一个是服务订阅者（Subscriber）。Publisher 需要把服务注册到服务注册中心（Registry），发布的内容通常是该 Publisher 的 IP 地址、端口、调用方式 （协议、序列化方式）等。而 Subscriber 在第一次调用服务时，会通过 Registry 找到相应的服务的 IP 地址列表，通过负载均衡算法从 IP 列表中取一个服务提供者的服务器调用服务。同时 Subscriber 会将 Publisher 的服务列表数据缓存到本地，供后续使用。当 Subscriber 后续再调用 Publisher 时，优先使用缓存的地址列表，不需要再去请求Registry。\n如上图，Subscriber 还需要能感知到 Publisher 的动态变化。比如当有 Publisher 服务下线时， Registry 会将其摘除，随后 Subscriber 感知到新的服务地址列表后，不会再调用该已下线的 Publisher。同理，当有新的 Publisher 上线时，Subscriber 也会感知到这个新的 Publisher。\n初步认识 在理解了常见的服务注册中心的概念之后，我们来看看蚂蚁金服的 SOFARegistry 长什么样子。如上图，SOFARegistry 包含 4 个角色：\n Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\n SessionServer 会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。\n DataServer 数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。\n MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。\n产品特点 （图片改编自 https://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products ）\n首先放一张常见的服务注册中心的特性对比，可以看出，在这些 Feature 方面，SOFARegistry 并不占任何优势。那么，我们为什么还开源这样的一个系统？SOFARegistry 开源的优势是什么？下面将着重介绍 SOFARegistry 的特点。\n支持海量数据 大部分的服务注册中心系统，每台服务器都是存储着全量的服务注册数据，服务器之间依靠一致性协议（如 Paxos/Raft/2PC 等）实现数据的复制，或者只保证最终一致性的异步数据复制。“每台服务器都存储着全量的服务注册数据”，在一般规模下是没问题的。但是在蚂蚁金服庞大的业务规模下，服务注册的数据总量早就超过了单台服务器的容量瓶颈。\nSOFARegistry 基于一致性 Hash 做了数据分片，每台 DataServer 只存储一部分的分片数据，随数据规模的增长，只要扩容 DataServer 服务器即可。这是相对服务发现领域的其他竞品来说最大的特点，详细介绍见后面《如何支持海量数据》一节。\n支持海量客户端 SOFARegistry 集群内部使用分层的架构，分别为连接会话层（SessionServer）和数据存储层（DataServer）。SessionServer 功能很纯粹，只负责跟 Client 打交道，SessionServer 之间没有任何通信或数据复制，所以随着业务规模（即 Client 数量）的增长，SessionServer 可以很轻量地扩容，不会对集群造成额外负担。\n相比之下，其他大多数的服务发现组件，如 eureka，每台服务器都存储着全量的数据，依靠 eurekaServer 之间的数据复制来传播到整个集群，所以每扩容 1 台 eurekaServer，集群内部相互复制的数据量就会增多一份。再如 Zookeeper 和 Etcd 等强一致性的系统，它们的复制协议（Zab/Raft）要求所有写操作被复制到大多数服务器后才能返回成功，那么增加服务器还会影响写操作的效率。\n秒级的服务上下线通知 对于服务的上下线变化，SOFARegistry 使用推送机制，快速地实现端到端的传达。详细介绍见后面《秒级服务上下线通知》一节。\n接下来，我将围绕这些特点，讲解 SOFARegistry 的关键架构设计原理。\n高可用 各个角色都有 failover 机制：\n MetaServer 集群部署，内部基于 Raft 协议选举和复制，只要不超过 1\u0026amp;frasl;2 节点宕机，就可以对外服务。 DataServer 集群部署，基于一致性 Hash 承担不同的数据分片，数据分片拥有多个副本，一个主副本和多个备副本。如果 DataServer 宕机，MetaServer 能感知，并通知所有 DataServer 和 SessionServer，数据分片可 failover 到其他副本，同时 DataServer 集群内部会进行分片数据的迁移。 SessionServer 集群部署，任何一台 SessionServer 宕机时 Client 会自动 failover 到其他 SessionServer，并且 Client …","date":1556175600,"description":"本文为《剖析 | SOFARegistry 框架》第一篇，本篇作者琪祥。","dir":"blog/sofa-registry-introduction/","fuzzywordcount":11100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"04394de7d7b0ecba5303baa6949a40d4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-introduction/","publishdate":"2019-04-25T15:00:00+08:00","readingtime":23,"relpermalink":"/sofastack.tech/blog/sofa-registry-introduction/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFARegistry 是蚂蚁金服开","tags":["SOFARegistry","剖析 | SOFARegistry 框架","SOFALab"],"title":"海量数据下的注册中心 - SOFARegistry 架构介绍","type":"blog","url":"/sofastack.tech/blog/sofa-registry-introduction/","wordcount":11079},{"author":"觉生","categories":"Seata","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。 Seata：https://github.com/seata/seata 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23127468，不错过每场直播。\n 2019 年 3 月，蚂蚁金服加入分布式事务 Seata 的社区共建中，并贡献其 TCC 模式。本期是 SOFAChannel 第四期，主题：分布式事务 Seata TCC 模式深度解析，本文根据觉生的直播整理。\n大家晚上好，我是 Seata Committer 觉生，来自蚂蚁金服数据中间件团队。今天的内容主要分为以下四个部分：\n Seata TCC 模式的原理解析； 从 TCC 的业务模型与并发控制分享如何设计一个 TCC 接口，并且适配 TCC 模型； 如何控制异常； 性能优化，使得 TCC 模式能够满足更高的业务需求。 1、 Seata 的 TCC 模式 1.1 服务化拆分 下面我们就进入第一个主题，Seata 的 TCC 模式。蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个系统中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，而网络、机器等不可靠，数据一致性的问题很容易出现，与可扩展性、高可用容灾等要求并肩成为金融 IT 架构支撑业务转型升级的最大挑战之一。\n从图中可以看到，从单系统到微服务转变，其实是一个资源横向扩展的过程，资源的横向扩展是指当单台机器达到资源性能瓶颈，无法满足业务增长需求时，就需要横向扩展资源，形成集群。通过横向扩展资源，提升非热点数据的并发性能，这对于大体量的互联网产品来说，是至关重要的。服务的拆分，也可以认为是资源的横向扩展，只不过方向不同而已。\n资源横向扩展可能沿着两个方向发展，包括业务拆分和数据分片：\n 业务拆分。根据功能对数据进行分组，并将不同的微服务分布在多个不同的数据库上，这实际上就是 SOA 架构下的服务化。业务拆分就是把业务逻辑从一个单系统拆分到多个微服务中。\n 数据分片。在微服务内部将数据拆分到多个数据库上，为横向扩展增加一个新的维度。数据分片就是把一个微服务下的单个 DB 拆分成多个 DB，具备一个 Sharding 的功能。通过这样的拆解，相当于一种资源的横向扩展，从而使得整个架构可以承载更高的吞吐。\n 横向扩展的两种方法可以同时进行运用：交易、支付与账务三个不同微服务可以存储在不同的数据库中。另外，每个微服务内根据其业务量可以再拆分到多个数据库中，各微服务可以相互独立地进行扩展。\nSeata 关注的就是微服务架构下的数据一致性问题，是一整套的分布式事务解决方案。Seata 框架包含两种模式，一种是 AT 模式。AT 模式主要从数据分片的角度，关注多 DB 访问的数据一致性，当然也包括多服务下的多 DB 数据访问一致性问题。\n另外一个就是 TCC 模式，TCC 模式主要关注业务拆分，在按照业务横向扩展资源时，解决微服务间调用的一致性问题，保证读资源访问的事务属性。\n今天我们主要讲的就是TCC模式。在讲 TCC 之前，我们先回顾一下 AT 模式，这样有助于我们理解后面的 TCC 模式。\n1.2. AT 模式 对于 AT 模式，之前其他同学已经分享过很多次，大家也应该比较熟悉了。AT 模式下，把每个数据库被当做是一个 Resource，Seata 里称为 DataSource Resource。业务通过 JDBC 标准接口访问数据库资源时，Seata 框架会对所有请求进行拦截，做一些操作。每个本地事务提交时，Seata RM（Resource Manager，资源管理器） 都会向 TC（Transaction Coordinator，事务协调器） 注册一个分支事务。当请求链路调用完成后，发起方通知 TC 提交或回滚分布式事务，进入二阶段调用流程。此时，TC 会根据之前注册的分支事务回调到对应参与者去执行对应资源的第二阶段。TC 是怎么找到分支事务与资源的对应关系呢？每个资源都有一个全局唯一的资源 ID，并且在初始化时用该 ID 向 TC 注册资源。在运行时，每个分支事务的注册都会带上其资源 ID。这样 TC 就能在二阶段调用时正确找到对应的资源。\n这就是我们的 AT 模式。简单总结一下，就是把每个数据库当做一个 Resource，在本地事务提交时会去注册一个分支事务。\n1.3 TCC 模式 那么对应到 TCC 模式里，也是一样的，Seata 框架把每组 TCC 接口当做一个 Resource，称为 TCC Resource。这套 TCC 接口可以是 RPC，也以是服务内 JVM 调用。在业务启动时，Seata 框架会自动扫描识别到 TCC 接口的调用方和发布方。如果是 RPC 的话，就是 sofa:reference、sofa:service、dubbo:reference、dubbo:service 等。\n扫描到 TCC 接口的调用方和发布方之后。如果是发布方，会在业务启动时向 TC 注册 TCC Resource，与DataSource Resource 一样，每个资源也会带有一个资源 ID。\n如果是调用方，Seata 框架会给调用方加上切面，与 AT 模式一样，在运行时，该切面会拦截所有对 TCC 接口的调用。每调用一次 Try 接口，切面会先向 TC 注册一个分支事务，然后才去执行原来的 RPC 调用。当请求链路调用完成后，TC 通过分支事务的资源ID回调到正确的参与者去执行对应 TCC 资源的 Confirm 或 Cancel 方法。\n在讲完了整个框架模型以后，大家可能会问 TCC 三个接口怎么实现。因为框架本身很简单，主要是扫描 TCC 接口，注册资源，拦截接口调用，注册分支事务，最后回调二阶段接口。最核心的实际上是 TCC 接口的实现逻辑。下面我将根据蚂蚁金服内部多年的实践来为大家分析怎么实现一个完备的 TCC 接口。\n2、 TCC 业务模型与并发控制 2.1 TCC 设计原则 从 TCC 模型的框架可以发现，TCC 模型的核心在于 TCC 接口的设计。用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。下面我会分享蚂蚁金服内多年的 TCC 应用实践以及在 TCC 设计和实现过程中的注意事项。\n设计一套 TCC 接口最重要的是什么？主要有两点，第一点，需要将操作分成两阶段完成。TCC（Try-Confirm-Cancel）分布式事务模型相对于 XA 等传统模型，其特征在于它不依赖 RM 对分布式事务的支持，而是通过对业务逻辑的分解来实现分布式事务。\nTCC 模型认为对于业务系统中一个特定的业务逻辑 ，其对外提供服务时，必须接受一些不确定性，即对业务逻辑初步操作的调用仅是一个临时性操作，调用它的主业务服务保留了后续的取消权。如果主业务服务认为全局事务应该回滚，它会要求取消之前的临时性操作，这就对应从业 …","date":1556089200,"description":"本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。","dir":"blog/sofa-channel-4-retrospect/","fuzzywordcount":10500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"75094c50f180bcd31d84bc687e4c93e0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-4-retrospect/","publishdate":"2019-04-24T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/sofa-channel-4-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#4 直播分享整理，主题：分布式事务 Seata TCC 模式深度解析。 Seata：https://","tags":["Seata","SOFAChannel"],"title":"分布式事务 Seata TCC 模式深度解析 | SOFAChannel#4 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-4-retrospect/","wordcount":10459},{"author":"青勤","categories":"SOFAActs","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。 回顾视频以及 PPT 查看地址见文末。 欢迎加入直播互动钉钉群：23195297，不错过每场直播。\n 大家晚上好，我是蚂蚁金服自动化测试框架 SOFAActs 开源核心成员青勤，目前从事测试技术相关的研发工作，今晚将由我来给大家分享交流自动化测试框架 SOFAActs 的基本原理和使用，今天的内容主要分为以下四个章节：\n 项目介绍 SOFAActs 接入 功能介绍与使用 升阶功能使用 欢迎大家 Star 我，SOFAActs：https://github.com/sofastack/sofa-acts\n1 项目介绍 在分享使用操作前，我将引导大家来熟悉下 SOFAActs 的项目背景、基本原理等。\n对于研发质量保障而言，金融系统和金融业务的多样性、复杂性同样也会在测试场景、测试验证和测试流程的复杂程度上得到充分体现。\n譬如，对于包含出参、RPC 调用、DB 变更和异常等多个测试验证点的用例而言，在研发和测试人员维护和验证用例场景的过程中，时常发生业务结果校验遗漏，对我们及早发现和纠错问题造成干扰，进而无法严格保障产品质量。这些问题对研发质量保障提出了很高的挑战，相应的自动化、精细化的白盒测试工具需求日益增长，这其中就包括 SOFAActs。\n为了解决上述痛点、满足精细化测试需要，在多年测试实践积累与沉淀下，我们研发了基于模型驱动的 SOFAActs 测试框架，它可以灵活、可扩展的提供一站式用例管理，标准化测试执行和精细化校验。目前 SOFAActs 测试框架逐渐成熟并在蚂蚁金服内部得到广泛应用。\n1.1 项目架构 介绍完背景，我们来看下 SOFAActs 的大体框架，SOFAActs 底层封装并集成适配 SOFABoot 等运行环境。\n在重要的引擎层，SOFAActs 封装了工具类和数据模型，并将测试模式的过程进行了标准化，提供通用测试能力和扩展点。对于有自动化测试经验的同学来讲，测试模式其实并不复杂，这其中有很多工作是可以抽象和固定的，SOFAActs 将这部分内容内聚到引擎层，封装成标准测试流程等，尤其是模型驱动和精细化校验等，从而释放精力，将更多关注点聚焦在待测目标上。\n引擎层之上，是 SOFAActs 提供的可视化用例管理功能，可以一站式的维护测试脚本、测试数据和数据模型，借助可视化编辑器可成倍提高用例管理等等操作效率，整体而言 SOFAActs 围绕模型驱动引擎和可视化编辑器，将测试代码的编写工作量极尽降低，目标聚焦在测试对象上。\n这里我们示例看下，SOFAActs 对测试代码和效率的优化。这里以 Credit 接口为例，业务处理开始之前会检查传参，构造上下文、随后发起业务处理，涉及对三张表的读取或变更，并在数据库事物结束之后，返回业务处理结果。\n 针对这一业务逻辑，这里我们构造一个 Credit 接口的完整测试用例，在代码驱动测试时，它需要一下 9 个步骤，手动准备依赖数据、构造请求参数、执行业务逻辑、校验业务结果以及数据清理等等，人工介入成本居高，尤其当存在多个用例时，测试代码可复用性低，测试效率是难以得到有效提升。而与之对比，在模型驱动测试下，Credit 接口的 SOFAActs 测试脚本会对固有的测试模式进行封装，用例复杂度得到极大精简，众多用例数据可以得到高效的可视化管理。\n1.2 执行原理 在开始使用 SOFAActs 之前，我们来了解一下有关 SOFAActs 执行引擎的运作原理。SOFAActs 框架也提供了非常多的扩展点，如果需要个性化的定义，可以对每一个环节进行扩展。\n上文中已提到过 SOFAActs 执行引擎是对测试模式过程的封装，Setup 方法是引擎入口，用于加载初始化 SOFAActs 运行时的必需资源，如获取数据源。\n以下是主体测试过程：clear、prepare、execute、check 这 4 个方法依次负责环境清理、依赖准备、执行、结果校验等。这些内容是代码驱动测试时需要手写的测试代码和内容，每个测试脚本的完成意味着上面的过程会被我们重复一遍，于是 SOFAActs 将这部分内容进行了封装，实现了最通用基础的功能。\n右侧，我们对高频数据如方法入参、出参、异常和依赖DB数据进行了抽象，给出 SOFAActs 的模型，这是代码驱动转向模型驱动、精细化校验的基础。左侧的数据总线会贯穿每个用例的执行生命周期，即贯穿中间的主体测试过程，如果大家对框架封装的基础功能有自定义需要，可以通过数据总线对 SOFAActs 的对象、方法进行获取、重写，以便更灵活的控制框架行为。当然 SOFAActs 对这些内容作了较好的封装，覆盖了大部分的测试需求，无需大家过度关注。\n以上就是 SOFAActs 的执行原理，接下来我会给大家详细介绍 SOFAActs 的接入和使用。\n2 SOFAActs 接入 SOFAActs 分为两部分，其一是可视化编辑器，在 [SOFAStack 官网上 1 我们可以获取该编辑器的安装包，并通过 IDEA 的插件管理进行安装。其二是 SOFAActs 的基础 jar，它提供了 SOFAActs 用例运行的环境支持，在 test 模块 pom 中添加下列依赖即可，有关 test 模块或者多模块详细内容大家可以参考 [SOFAActs 的快速开始文档 1 。\n3 功能介绍和使用 下面，我们进入 SOFAActs 的功能介绍和使用章节，这部分我将分为三小节展开：一站式构建、SOFAActs 核心的模型驱动以及 SOFAActs 提供的精准校验。\n3.1 一站式构建 一站式构建中，SOFAActs 通过可视化编辑器为我们提供了便捷操作，以帮助一键配置初始化、构建测试脚本与模型，可视化管理用例数据等等。借助可视化编辑器，在整个过程中我们可以替换大部分手工编写代码的工作，进行一站式操作。\n一键初始化\n这里我们示例看下，如何操作一键初始化以及一键初始化做哪些内容。首先一键初始化框架只需要 3 个鼠标点击步骤。在 Package 视图下选中测试模块并右键选择 SOFAActs 功能，一键初始化，输入该应用的应用名称和工程编码格式。在一键初始化完成后，SOFAActs 将会在 test 模块写入 SOFAActs 配置文件，DB 连接配置文件，测试套件配置文件以及创建模型存储目录等。\n acts-config 配置文件是 SOFAActs 的核心配置，提供了测试环境切换、数据库连接切换、冒烟测试以及预跑反填等配置，来开关 SOFAActs 的相关功能；model 目录用于存放对象模型、数据模型，以便对模型进行统一管理；DB 配置文件指明了数据库连接信息，用于生成数据模型时自动填充表结构和模版数据。\n一键生成测试脚本\n在完成配置初始化操作后，我们可以开始第一个用例的编写，SOFAActs 提供了一键测试脚本生成功能。以待测的 getMessage 接口为例，在其方法定义上右键选择 SOFAActs 功能，生成测试用例，在弹出框中检查用例信息，修正无误后点击确定可以生成该 …","date":1556089200,"description":"本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。","dir":"blog/sofa-channel-5-retrospect/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1f088b226caf9430dc6aafb3f248316d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-5-retrospect/","publishdate":"2019-04-24T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-5-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAAc","tags":["SOFAActs","SOFAChannel"],"title":"给研发工程师的代码质量利器 | SOFAChannel#5 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-5-retrospect/","wordcount":5492},{"author":"SOFAStack","categories":"SOFAStack","content":"Hey, SOFAer！有些话想对你说：\n“开源”二字代表的不仅仅是一个项目，更是代表了整个技术社区，代表了隐藏在背后的工程师们。\n很幸运，这一年遇到你们。\n生于蚂蚁金服，经历 12 年的业务锤炼，这是金融级分布式架构 SOFAStack。SOFAStack 的发展受益于开源社区的优秀产品，我们也决定结合我们的实践积累，把这些技术反馈给开源社区。\n于是，2018 年 4 月，SOFAStack 宣布开源，项目地址：https://github.com/alipay 。\n这一年，SOFAStack 逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFABolt、SOFAMosn、SOFAMesh、SOFAJRaft、SOFAActs、SOFARegistry 等组件。2019 年 3 月，蚂蚁金服加入分布式事务 Seata 的社区共建中，并贡献其 TCC 模式。\n这一年，我们获得了 14,000+ Star，超过 100 位贡献者参与，并有超过 30 家企业用户将 SOFAStack 应用在了生产环境上。\n这一年，SOFAStack 团队从电脑屏幕前，走到了开源社区里，与大家讨论并吸纳社区的建议。\n这一年，尝试了很多的“第一次”：第一次与大家编写 SOFALab 源码解析系列文章，第一次做 SOFAChannel 技术直播，第一次组织 SOFAMeetup，第一次在开源技术大会演讲。\n嘿，或许你见过我们紧张的样子。\n这一年，我们得到了太多来自社区的帮助，因为你们，SOFAStack 团队能一直享受“Make something people want”的乐趣。\n这一年，感谢有你。Hey, SOFAer~有些话想对你说：\n戳这里\n","date":1555333200,"description":"这一年，感谢有你。","dir":"blog/sofastack-anniversary-1/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"82d2afd98352ab185691773fcd616233","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-anniversary-1/","publishdate":"2019-04-15T21:00:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/blog/sofastack-anniversary-1/","summary":"Hey, SOFAer！有些话想对你说： “开源”二字代表的不仅仅是一个项目，更是代表了整个技术社区，代表了隐藏在背后的工程师们。 很幸运，这一年遇到你","tags":["SOFAStack"],"title":"Hey, SOFAer！有些话想对你说：","type":"blog","url":"/sofastack.tech/blog/sofastack-anniversary-1/","wordcount":639},{"author":"李钊","categories":"Seata","content":" 本文作者李钊，公众号「咖啡拿铁」作者，分布式事务 Seata 社区 Contributor。\n1.关于 Seata 在前不久，我写了一篇关于分布式事务中间件 Fescar 的解析，没过几天 Fescar 团队对其进行了品牌升级，取名为 Seata(Simpe Extensible Autonomous Transcaction Architecture)，而以前的 Fescar 的英文全称为 Fast \u0026amp;amp; EaSy Commit And Rollback。可以看见 Fescar 从名字上来看更加局限于 Commit 和 Rollback，而新的品牌名字 Seata 旨在打造一套一站式分布式事务解决方案。更换名字之后，我对其未来的发展更有信心。\n这里先大概回忆一下 Seata 的整个过程模型：\n TM：事务的发起者。用来告诉 TC，全局事务的开始，提交，回滚。 RM：具体的事务资源，每一个 RM 都会作为一个分支事务注册在 TC。 TC 事务的协调者。也可以看做是 Fescar-server，用于接收我们的事务的注册，提交和回滚。 在之前的文章中对整个角色有个大体的介绍，在这篇文章中我将重点介绍其中的核心角色 TC，也就是事务协调器。\n2.Transaction Coordinator 为什么之前一直强调 TC 是核心呢？那因为 TC 这个角色就好像上帝一样，管控着芸芸众生的 RM 和 TM。如果 TC 一旦不好使，那么 RM 和 TM 一旦出现小问题，那必定会乱的一塌糊涂。所以要想了解 Seata，那么必须要了解他的 TC。\n那么一个优秀的事务协调者应该具备哪些能力呢？我觉得应该有以下几个：\n 正确的协调：能正确的协调 RM 和 TM 接下来应该做什么，做错了应该怎么办，做对了应该怎么办。 高可用：事务协调器在分布式事务中很重要，如果不能保证高可用，那么他也没有存在的必要了。 高性能：事务协调器的性能一定要高，如果事务协调器性能有瓶颈，那么他所管理的 RM 和 TM 会经常遇到超时，从而引起回滚频繁。 高扩展性：这个特点是属于代码层面的，如果是一个优秀的框架，那么需要给使用方很多自定义扩展，比如服务注册/发现，读取配置等等。 下面我也将逐步阐述 Seata 是如何做到上面四点。\n2.1 Seata-Server 的设计 Seata-Server 整体的模块图如上所示：\n Coordinator Core：最下面的模块是事务协调器核心代码，主要用来处理事务协调的逻辑，如是否 Commit、Rollback 等协调活动。 Store：存储模块，用来将我们的数据持久化，防止重启或者宕机数据丢失。 Discover：服务注册/发现模块，用于将 Server 地址暴露给 Client。 Config：用来存储和查找服务端的配置。 Lock：锁模块，用于给 Seata 提供全局锁的功能。 Rpc：用于和其他端通信。 HA-Cluster：高可用集群，目前还没开源。为 Seata 提供可靠的高可用功能。 2.2 Discover 首先来讲讲比较基础的 Discover 模块，又称服务注册/发现模块。我们将 Seata-Server 启动之后，需要将自己的地址暴露给其他使用者，那么就需要这个模块帮忙。\n这个模块有个核心接口 RegistryService，如上图所示：\n register：服务端使用，进行服务注册。 unregister：服务端使用，一般在 JVM 关闭钩子，ShutdownHook 中调用。 subscribe：客户端使用，注册监听事件，用来监听地址的变化。 unsubscribe：客户端使用，取消注册监听事件。 lookup：客户端使用，根据 Key 查找服务地址列表。 close：都可以使用，用于关闭 Register 资源。 如果需要添加自己定义的服务注册/发现，那么实现这个接口即可。截止目前在社区的不断开发推动下，已经有四种服务注册/发现，分别是 redis、zk、nacos、eruka。下面简单介绍下 Nacos 的实现：\n2.2.1 register 接口 step1：校验地址是否合法；\nstep2：获取 Nacos 的 Name 实例，然后将地址注册到当前 Cluster 名称上面。\nunregister 接口类似，这里不做详解。\n2.2.2 lookup 接口 step1：获取当前 clusterName 名字；\nstep2：判断当前 Cluster 是否已经获取过了，如果获取过就从 Map 中取；\nstep3：从 Nacos 拿到地址数据，将其转换成我们所需要的；\nstep4：将我们事件变动的 Listener 注册到 Nacos。\n2.2.3 subscribe 接口 这个接口比较简单，具体分两步：\nstep1：将 Clstuer 和 Listener 添加进 Map 中；\nstep2：向 Nacos 注册。\n2.3 Config 配置模块也是一个比较基础，比较简单的模块。我们需要配置一些常用的参数比如：Netty 的 Select 线程数量，Work 线程数量，Session 允许最大为多少等等，当然这些参数在 Seata 中都有自己的默认设置。\n同样的在 Seata 中也提供了一个接口 Configuration，用来自定义我们需要的获取配置的地方：\n getInt/Long/Boolean/Config()：通过 DataId 来获取对应的值。 putConfig：用于添加配置。 removeConfig：删除一个配置。 add/remove/get ConfigListener：添加/删除/获取 配置监听器，一般用来监听配置的变更。 目前为止有四种方式获取 Config：File（文件获取）、Nacos、Apollo、ZK。在 Seata 中首先需要配置 registry.conf，来配置 conf 的类型。实现 conf 比较简单这里就不深入分析。\n2.4 Store 存储层的实现对于 Seata 是否高性能，是否可靠非常关键。\n如果存储层没有实现好，那么如果发生宕机，在 TC 中正在进行分布式事务处理的数据将会被丢失。既然使用了分布式事务，那么其肯定不能容忍丢失。如果存储层实现好了，但是其性能有很大问题，RM 可能会发生频繁回滚那么其完全无法应对高并发的场景。\n在 Seata 中默认提供了文件方式的存储，下面定义存储的数据为 Session，而 TM 创造的全局事务数据叫 GloabSession，RM 创造的分支事务叫 BranchSession，一个 GloabSession 可以拥有多个 BranchSession。我们的目的就是要将这么多 Session 存储下来。\n在 FileTransactionStoreManager#writeSession 代码中：\n上面的代码主要分为下面几步：\nstep1：生成一个 TransactionWriteFuture。\nstep2：将这个 futureRequest 丢进一个 LinkedBlockingQueue 中。为什么需要将所有数据都丢进队列中呢？当然这里其实也可以用锁来实现，在 …","date":1554793200,"description":"在这篇文章，将重点介绍 Seata 其中的核心角色 TC，也就是事务协调器。","dir":"blog/seata-server-deep-analysis/","fuzzywordcount":6900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3354370f3ca29297c819c279994e0a0d","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-server-deep-analysis/","publishdate":"2019-04-09T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/seata-server-deep-analysis/","summary":"本文作者李钊，公众号「咖啡拿铁」作者，分布式事务 Seata 社区 Contributor。 1.关于 Seata 在前不久，我写了一篇关于分布式事务中间件 Fescar 的解析，没","tags":["Seata"],"title":"深度剖析一站式分布式事务方案 Seata-Server","type":"blog","url":"/sofastack.tech/blog/seata-server-deep-analysis/","wordcount":6831},{"author":"潘潘","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 活动时间：4 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 | SOFAChannel \u0026amp;lt;SOFA:Channel/\u0026amp;gt; 有趣实用的分布式架构频道：前沿技术、直播 Coding、观点“抬杠”，多种形式。\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n| SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 4月初，分布式事务 Fescar 宣布进行品牌升级为 Seata，Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n本期为 SOFAChannel 线上直播第 4 期，将邀请 蚂蚁金服 技术专家 \u0026amp;amp; Seata Committer 觉生 和大家一起探讨 《分布式事务 Seata TCC 模式深度解析》。\n本期分享大纲：\n TCC 模式基本原理解析 分布式事务并发控制解析 分布式事务空回滚与幂等解析 分布式事务防悬挂解析 分布式事务异步化解析 | 加入 SOFA 钉钉互动群 欢迎加入直播互动钉钉群：23195297（搜索群号加入即可）\n| 点击即可报名 https://tech.antfin.com/community/live/462\n议程 19:00-19:05 主持人开场 SOFAGirl 主持人\n19:05-20:00 分布式事务 Seata TCC 模式深度解析 觉生 蚂蚁金服 技术专家 / Seata Committer\n本期分享大纲： TCC 模式基本原理解析 分布式事务并发控制解析 分布式事务空回滚与幂等解析 分布式事务防悬挂解析 分布式事务异步化解析 嘉宾 SOFAGirl 主持人 觉生 蚂蚁金服 技术专家 / Seata Committer ","date":1554783000,"description":"4 月 18 日周四晚 7 点，线上直播第 4 期。","dir":"activities/sofa-channel-4/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0e0d4d4a75723cc408567a65aab0c3df","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-4/","publishdate":"2019-04-09T12:10:00+08:00","readingtime":2,"relpermalink":"/sofastack.tech/activities/sofa-channel-4/","summary":"概要 活动主题：SOFAChannel#4：分布式事务 Seata TCC 模式深度解析 活动时间：4 月 18 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介","tags":["SOFAChannel","Seata"],"title":"SOFAChannel#4：分布式事务 Seata TCC 模式深度解析","type":"activities","url":"/sofastack.tech/activities/sofa-channel-4/","wordcount":551},{"author":"绍辉","categories":"Seata","content":" 上周，分布式事务 Fescar 宣布进行品牌升级：\nThanks, Fescar ❤️，\nHello, Seata 🚀。\nSeata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。\n项目地址：https://github.com/seata/seata\n蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n为了帮助大家理解，分布式事务开源负责人绍辉进行了一次线下分享，详细讲述了分布式事务在蚂蚁金服的发展，希望可以帮助大家理解分布式事务，以下为分享的文字整理版本。\n前言 今天的分享将从以下三个部分展开：分布式事务问题产生的背景、蚂蚁金服分布式事务以及分布式事务 Seata 的 Roadmap。\n分享嘉宾：绍辉 蚂蚁金服 分布式事务开源负责人\n1、分布式事务问题产生的背景 1.1、数据库的水平拆分 蚂蚁金服早期，业务量比较小，单库单表便能满足业务需求；但是随着业务的发展，单库单表数据库逐渐成为瓶颈。为了解决数据库的瓶颈问题，我们对数据库进行了水平拆分。拆分所带来的一个问题就是以前一个数据库上便能完成的写操作现在要跨多个数据库，由此带来了跨库事务问题。\n1.2、业务的服务化拆分 蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个 APP 中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，由此产生了跨服务事务问题。\n1.3、转账案例说明数据一致性问题 数据库的水分拆分以及服务的垂直拆分，所带来的问题是一个业务活动通常要调用多个服务、访问多个数据库才能完成。\n以金融业务场景下的转账场景为例，转账服务要完成以下操作：\n 调用交易系统服务创建交易订单； 调用支付系统记录支付明细； 调用账务系统执行 A 扣钱； 调用账务系统执行 B 加钱。 以上 4 个操作要跨 3 个系统，访问 4 个数据库。而网络、数据库、机器等都具有不可靠性，我们很难保证以上 4 个操作能 100% 全部成功。\n在金融属性的业务中，不允许 A 账户的钱扣了，而 B 账户的钱没有加上的现象出现，所以我们必须想办法保证 1 ~ 4 这四个操作要么全部成功，要么全部失败；所以蚂蚁金服自主研发了分布式事务中间件，解决跨服务、跨数据库的数据一致性问题。\n2、蚂蚁金服分布式事务 2.1、分布式事务理论基础 在介绍蚂蚁金服的分布式事务中间件之前，先介绍一些分布式事务的理论背景。\n 2PC 两阶段提交协议（Two Phase Commitment Protocol）是分布式事务最基本的协议。在两阶段提交协议中，有一个事务管理器和多个资源管理器，事务管理器分两阶段协调资源管理器。在第一阶段，事务管理器询问所有资源管理器准备是否成功。如果所有资源均准备成功，那么在第二阶段事务管理器会要求所有资源管理器执行提交操作；如果任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求所有资源管理器在第二阶段执行回滚操作。通过事务管理器的两阶段协调，最终所有资源管理器要么全部提交，要么全部回滚，最终状态都是一致的。\n TCC 资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现。TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题。TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中。事务管理器分两个阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法，最终所有 TCC 服务要么全部都是提交的、要么全部都是回滚的。\n2.2、蚂蚁金服分布式产品介绍 蚂蚁金服从 2007 年开始做分布式事务，至今已经有 12 年历史。蚂蚁金服的分布式事务最初是采用 TCC 实现的，TCC 模式帮蚂蚁业务解决了各类金融核心场景下的数据一致性问题。\n2007 年我们开始支持双十一，为了满足双十一的高性能需求，我们对分布式事务做了一系列的性能优化。\n2013年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014年，蚂蚁金服分布式事务中间件开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户；在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。\n所以在 2015年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务中间件经过长期演进，目前积累了 TCC、FMT 和 XA 三种模式，具有丰富的应用场景。下面分别介绍这三种模式。\n2.3、TCC 模式 蚂蚁金服的 TCC 模式和前面介绍 TCC 理论中提的 TCC 原理是一致的。不同的是，我们在整个分布式事务执行过程中，会去记录事务日志，一个分布式事务会产生一条主事务记录（对应发起方）和若干分支事务记录（对应 TCC 参与者）。记录事务日志的目的是，当分布式事务执行过程中出现异常中断时，事务恢复服务通过轮询事务日志，找出这个异常中断的事务，补偿执行该异常事务剩余未完成的动作，整个分布式事务的最终状态要么全部提交，要么全部回滚。\nTCC 设计规范和注意事项：\n用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。经过蚂蚁金服多年的 TCC 应用实践，总结如下在 TCC 设计和实现过程中的注意事项：\n1、业务操作分两阶段完成： 接入 TCC 前，业务操作只需要一步就能完成。但是在接入 TCC 之后，需要考虑如何将其分成两个阶段完成：把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户 A 的余额中有 100 元，需要扣除其中 30 元”。\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成两步完成：\n Try 操作：资源的检查和预留。 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交。 在扣款场景下，Confirm 阶段 …","date":1554706800,"description":"本文根据 SOFAMeetup#1 分享整理，详细讲述了分布式事务在蚂蚁金服的发展。","dir":"blog/sofa-meetup-1-seata/","fuzzywordcount":5000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fd2c8c1c6ee4231c6987a1d556ce4089","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-seata/","publishdate":"2019-04-08T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-seata/","summary":"上周，分布式事务 Fescar 宣布进行品牌升级： Thanks, Fescar ❤️， Hello, Seata 🚀。 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。 项","tags":["Seata","SOFAMeetup"],"title":"蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-seata/","wordcount":4909},{"author":"力鲲","categories":"SOFAJRaft","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享视频回顾获取方式见文章底部。\n 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nGitHub 地址：https://github.com/alipay/sofa-jraft\n之前，我们有一篇介绍 SOFAJRaft 的文章，可在文末获得链接，延续这个内容，今天的演讲分为三部分，先简要介绍 Raft 算法，然后介绍 SOFAJRaft 的设计，最后说说它的优化。\n分享嘉宾：力鲲 蚂蚁金服 SOFAJRaft 核心成员\nRaft 共识算法 Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。同时对已达成一致的结论，是不可推翻的。可以举一个银行账户的例子来解释共识算法：假如由一批服务器组成一个集群来维护银行账户系统，如果有一个 Client 向集群发出“存 100 元”的指令，那么当集群返回成功应答之后，Client 再向集群发起查询时，一定能够查到被存储成功的这 100 元钱，就算有机器出现不可用情况，这 100 元的账也不可篡改。这就是共识算法要达到的效果。\nRaft 算法和其他的共识算法相比，又有了如下几个不同的特性：\n Strong leader：Raft 集群中最多只能有一个 Leader，日志只能从 Leader 复制到 Follower 上； Leader election：Raft 算法采用随机选举超时时间触发选举来避免选票被瓜分的情况，保证选举的顺利完成； Membership changes：通过两阶段的方式应对集群内成员的加入或者退出情况，在此期间并不影响集群对外的服务。 共识算法有一个很典型的应用场景就是复制状态机。Client 向复制状态机发送一系列能够在状态机上执行的命令，共识算法负责将这些命令以 Log 的形式复制给其他的状态机，这样不同的状态机只要按照完全一样的顺序来执行这些命令，就能得到一样的输出结果。所以这就需要利用共识算法保证被复制日志的内容和顺序一致。\nLeader 选举 复制状态机集群在利用 Raft 算法保证一致性时，要做的第一件事情就是 Leader 选举。在讲 Leader 选举之前我们先要说一个重要的概念：Term。Term 用来将一个连续的时间轴在逻辑上切割成一个个区间，它的含义类似于“美国第 26 届总统”这个表述中的“26”。\n每一个 Term 期间集群要做的第一件事情就是选举 Leader。起初所有的 Server 都是 Follower 角色，如果 Follower 经过一段时间( election timeout )的等待却依然没有收到其他 Server 发来的消息时，Follower 就可以认为集群中没有可用的 Leader，遂开始准备发起选举。在发起选举的时候 Server 会从 Follower 角色转变成 Candidate，然后开始尝试竞选 Term + 1 届的 Leader，此时他会向其他的 Server 发送投票请求，当收到集群内多数机器同意其当选的应答之后，Candidate 成功当选 Leader。但是如下两种情况会让 Candidate 退回 (step down) 到 Follower，放弃竞选本届 Leader：\n 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的投票请求； 如果在 Candidate 等待 Servers 的投票结果期间收到了其他拥有更高 Term 的 Server 发来的心跳； 当然了，当一个 Leader 发现有 Term 更高的 Leader 时也会退回到 Follower 状态。\n当选举 Leader 成功之后，整个集群就可以向外提供正常读写服务了，如图所示，集群由一个 Leader 两个 Follower 组成，Leader 负责处理 Client 发起的读写请求，同时还要跟 Follower 保持心跳或者把 Log 复制给 Follower。\nLog 复制 下面我们就详细说一下 Log 复制。我们之前已经说了 Log 就是 Client 发送给复制状态机的一系列命令。这里我们再举例解释一下 Log，比如我们的复制状态机要实现的是一个银行账户系统，那么这个 Log 就可以是 Client 发给账户系统的一条存钱的命令，比如“存 100 元钱”。\nLeader 与 Follower 之间的日志复制是共识算法运用于复制状态机的重要目的，在 Raft 算法中 Log 由 TermId、LogIndex、LogValue 这三要素构成，在这张图上每一个小格代表一个 Log。当 Leader 在向 Follower 复制 Log 的时候，Follower 还需要对收到的 Log 做检查，以确保这些 Log 能和本地已有的 Log 保持连续。我们之前说了，Raft 算法是要严格保证 Log 的连续性的，所以 Follower 会拒绝无法和本地已有 Log 保持连续的复制请求，那么这种情况下就需要走 Log 恢复的流程。总之，Log 复制的目的就是要让所有的 Server 上的 Log 无论在内容上还是在顺序上都要保持完全一致，这样才能保证所有状态机执行结果一致。\n目前已经有一些很优秀的对 Raft 的实现，比如 C++ 写的 braft，Go 写的 etcd，Rust 写的 TiKV。当然了，SOFAJRaft 并不是 Raft 算法的第一个 Java 实现，在我们之前已经有了很多项目。但是经过我们的评估，觉得目前还是没有一个 Raft 的 Java 实现库类能够满足蚂蚁生产环境的要求，这也是我们去写 SOFAJRaft 的主要原因。\nSOFAJRaft 介绍 接下来我们介绍 SOFAJRaft。\nSOFAJRaft 是基于 Raft 算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP。从去年 3 月开发到今年 2 月完成，并在今年 3 月开源。应用场景有 Leader 选举、分布式锁服务、高可靠的元信息管理、分布式存储系统，目前使用案例有 RheaKV，这是 SOFAJRaft 中自带的一个分布式 KV 存储，还有今天开源的 SOFA 服务注册中心中的元信息管理模块也是用到了 SOFAJRaft，除此之外还有一些内部的项目也有使用，但是因为没有开源，所以就不再详述了。\n这张图就是 SOFAJRaft 的设计图，Node 代表了一个 SOFAJRaft Server 节点，这些方框代表他内部的各个模块，我们依然用之前的银 …","date":1554188400,"description":"本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享视频回顾获取方式见文章底部。","dir":"blog/sofa-meetup-1-jraft/","fuzzywordcount":5600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"614c6031770d98ed7d0c23c3276d72ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-jraft/","publishdate":"2019-04-02T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-jraft/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFAJRaft","SOFAMeetup"],"title":"详解蚂蚁金服 SOFAJRaft | 生产级高性能 Java 实现","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-jraft/","wordcount":5507},{"author":"张磊、心贵、临石、徙远、衷源、浔鸣","categories":"Kubernetes","content":" 本文由张磊、心贵、临石、徙远、衷源、浔鸣等同学联合撰写。\nKubernetes 1.14.0 Release 已经于 3 月 25 日正式发布。相信你也已经注意到，相比于1.13 和 1.12 版本，这次发布包含的重要变非常多，其对应的 Release Note 的篇幅长度也创下了“新高”。\n面对这样一份“海量信息”的 Release Note，我们该如何从这份文档里进行高效的信息过滤和挖掘，帮助团队更精准、快速的梳理出这次发布最主要的技术脉络呢？\n在本篇文章中，我们将 1.14 的 Release Note 按照主题进行了重新归纳和梳理，按照类别对重要变更进行了技术剖析和讨论。希望这种“分类解读”的方式，能够帮助大家更好的理解 1.14 这个发布的核心内容。\nWindows Node 正式生产可用 随着1.14的发布，Kubernetes 对windows节点的生产级支持无疑是一个重要的里程碑。具体来说，1.14 版本针对 Windows 做了大量增强；\n Pod：Pod内支持 readiness 和 liveness 探针；支持进程隔离和 volume 共享的多容器 Pod；Pod 支持原生configmap 和 sercret；Pod 支持emptyDir；支持对 Pod 进行资源配额等；但是像优雅删除、Termination message、Privileged Containers、HugePages、Pod 驱逐策略等部分特性还未在 1.14 版本提供； Service：支持服务环境变量提供 DNS 解析；支持 NodePort、ClusterIP、LoadBalancer、Headless service；暂不支持 Pod 的 hostnetwork 模式； 常规 Workload controller：RS、deployment、statefulset、daemonset、job、cronjob 均支持 windows 容器； 除此之外，支持 Pod 和 container 维度的metrics、HPA、“kubectl exec”、调度抢占、resource quotas、CNI 网络支持等多种特性让 windows workload 更加云原生；由于 windows 的特殊兼容性，目前 host OS 的版本必须和容器镜像 OS 版本一致，1.14 版本支持 win server 2019；未来版本中会考虑使用 Hyper-V 隔离机制来解决版本兼容性问题。 而伴随着 Windows 容器的生态正在慢慢壮大，能够在生产级别支持 Windows 节点的容器服务开始见诸各大云厂商。阿里云容器服务（ACK）近期已经推出了 Windows Container 的支持，提供了 linux/windows 应用混合部署的统一管理能力。\n参见：Support for Windows Nodes is Graduating to Stable (#116 )\n本地持久化数据卷（Local PV） 正式可用 长期以来，能够让 Kubernetes 直接用宿主机的本地存储设备（比如：本地 SSD 硬盘）来提供持久化数据卷（即：Local PV 功能），一直是社区里非常强烈的一个诉求。这个原因很容易理解：相对于远程存储（网络存储），Local PV 在时延性、易用性、稳定性和费用上具有独特的优势，尤其是对于相关特性比较敏感的应用，如数据库应用和搜索引擎应用来说，有着重要的意义。\n而在 1.14 中，Local PV 终于正式宣布 GA，为云上的持久化存储选择增加了一种重要的的可能。\n不过，必须要明确的是， 选择使用 Local PV，也意味着用户必须自己承担一些潜在的风险，这包括：\n 目前社区的开源方案无法动态创建卷 调度器需要由额外的调度逻辑工作，以确保调度的节点可以分配出足够的磁盘容量 容错性差，如果 Pod 正在运行的宿主机宕机或者磁盘发生异常，那么它的持久化卷里的信息可能丢失 第一个问题，可以通过比如阿里云的 local-volume-provisioner 实现本地 SSD Nvme 实例自动创建数据卷来解决，但对于容错性和健壮性的问题，就是比较棘手的了。\n参见：Durable Local Storage Management is Now GA (#121)\nPod 优先级与抢占机制稳定可用 Kubernetes 里的任务优先级（priority）和抢占机制（preemption）的目的十分明确：保证高优先级的任务可以在需要的时候通过抢占低优先级任务的方式得到运行。\n这其中，优先级定义了一个 Pod 在集群中的重要程度，这个重要程度体现且仅体现在两个地方： 1. 高优先级的Pod 在调度阶段更容易被优先调度（K8s 采用队列调度模型），注意这里并不保证高优先级 Pod 永远被优先调度，实际影响调度顺序的因素有很多； 2. 在集群整体负载较高时，如果出现高优先级 Pod 无法被调度的情况（集群中没有满足条件的 Node 供 Pod 运行），K8s 会启动抢占机制，通过抢占已经运行的低优先级的 Pod 的方式，让高优先级的 Pod 可以运行起来。抢占机制便是在这里引入的。\n抢占机制指当调度器发现某个Pod（如 Pod-A）无法在集群中找到合适的节点部署时（所有节点 Predicates 全部失败），会试图通过删除一些优先级低于 Pod-A 的 Pod 来“腾出空间”部署 Pod-A，这样 Pod-A 就可以被调度了。这样一个“看似简单”的需求在分布式环境中实施起来有很多细节，例如：如何决定删除哪个节点的哪些 Pod、如何保证为 Pod-A 腾出的空间不被其它 Pod 占用、如何保证 Pod-A 不被饿死（Starvation）、如何处理有亲和性需求的 Pod 调度约束、是否需要支持跨节点 Preemption 以支持某些特定的约束（例如某 Failure Domain 的反亲和约束）等等。\n参见：Pod Priority and Preemption in Kubernetes (#564) 你一定要知道什么是 Pod Ready++ 在 1.14 版本之前，Kubernetes 判断一个 Pod 是否 Ready，就是检查这个 Pod 的容器是否全部正常运行。但是这里有个问题，那就是容器或者说里面的主进程 Ready，并不一定意味着这个应用副本就一定是就绪的。为了确认 Pod 确实可以正常可用，我们希望给它增加一些外部指标（比如，该 Pod 需要的 Service，DNS，存储等服务全部就绪），来反应这个Pod是否“真正”Ready。\n这个特性，就是1.14 里一个叫做“Pod Readiness Gates”、也叫做 Pod Ready ++ 的特性。它为pod的“Ready 状态” 提供了一个非常强大的扩展点。需要注意的是，用户需要编写一个外部控制器（Controller）来为这个Pod Readiness Gates 字段对应的指标设置值。\n参见：Pod Ready++ (#580) Kubernetes 原生应用管理能力 1.14之后，Kubernetes 项目本身 …","date":1553756400,"description":"在本篇文章中，我们将 1.14 的 Release Note 按照主题进行了重新归纳和梳理，按照类别对重要变更进行了技术剖析和讨论。希望这种“分类解读”的方式，能够帮助大家更好的理解 1.14 这个发布的核心内容。","dir":"blog/k8s-1.14-release-note/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8dddcb73179e656ccebedbba2d4e9131","permalink":"https://sofastack.github.io/sofastack.tech/blog/k8s-1.14-release-note/","publishdate":"2019-03-28T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/k8s-1.14-release-note/","summary":"本文由张磊、心贵、临石、徙远、衷源、浔鸣等同学联合撰写。 Kubernetes 1.14.0 Release 已经于 3 月 25 日正式发布。相信你也已经注意到，相比于1.13 和 1.12 版本，这次发布包","tags":["Kubernetes"],"title":"Kubernetes 1.14 发布了，Release Note 该怎么读？","type":"blog","url":"/sofastack.tech/blog/k8s-1.14-release-note/","wordcount":4012},{"author":"Yu Shuqiang","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》最后一篇，本篇作者yushuqiang，来自小象生鲜。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：[SOFA:TracerLab/]，目前领取已经完成，感谢大家的参与。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n 前言 自 Google《Dapper，大规模分布式系统的跟踪系统》论文发表以来，开源 Tracer 系统如雨后春笋般相继面市，各显神通，但都是用于分布式系统调用跟踪的组件，通过统一的 traceId 将调用链路中的各种网络调用情况记录下来，以达到透视化网络调用的目的。本文介绍的 SOFATracer 是以日志的形式来记录的，这些日志可用于故障的快速定位，服务治理等。目前来看 SOFATracer 团队已经为我们搭建了一个完整的 Tracer 框架内核，包括数据模型、编码器、跨进程透传 traceId、采样、日志落盘与上报等核心机制，并提供了扩展 API 及基于开源组件实现的部分插件，为我们基于该框架打造自己的 Tracer 平台提供了极大便利。\n作为一个开源实现，SOFATracer 也尽可能提供大而全的插件实现，但由于多数公司都有自己配套的技术体系，完全依赖官方提供的插件可能无法满足自身的需要，因此如何基于 SOFATracer 自身 API 的组件埋点机制进行扩展，实现自己的插件是必须掌握的一项本领。\n本文将根据 SOFATracer 自身 AP I的扩展点及已提供的插件源码来分析下 SOFATracer 插件的埋点机制。\nSOFATracer 的插件埋点机制 对一个应用的跟踪要关注的无非就是 客户端-\u0026amp;gt;web 层-\u0026amp;gt;rpc 服务-\u0026amp;gt;dao 后端存储、cache 缓存、消息队列 mq 等这些基础组件。SOFATracer 插件的作用实际上也就是对不同组件进行埋点，以便基于这些组件采集应用的链路数据。\n不同组件有不同的应用场景和扩展点，因此对插件的实现也要因地制宜，SOFATracer 埋点方式一般是通过 Filter、Interceptor 机制实现的。\n组件扩展入口之 Filter or Interceptor SOFATracer 目前已实现的插件中，像 SpringMVC 插件是基于 Filter 进行埋点的，httpclient、resttemplate 等是基于 Interceptor 机制进行埋点的。在实现插件时，要根据不同插件的特性和扩展点来选择具体的埋点方式。正所谓条条大路通罗马，不管怎么实现埋点，都是依赖 SOFATracer 自身 API 的扩展机制来实现。\nAPI 扩展点之 AbstractTracer API SOFATracer 中所有的插件均需要实现自己的 Tracer 实例，如 SpringMVC 的 SpringMvcTracer 、HttpClient 的 HttpClientTracer 等。\n 基于 SOFATracer API 埋点方式插件扩展如下： AbstractTracer 是 SOFATracer 用于插件扩展使用的一个抽象类，根据插件类型不同，又可以分为 clientTracer 和 serverTracer，分别对应于 AbstractClientTracer 和 AbstractServerTracer；再通过 AbstractClientTracer 和 AbstractServerTracer 衍生出具体的组件 Tracer 实现，比如上图中提到的 HttpClientTracer 、RestTemplateTracer 、SpringMvcTracer 等插件 Tracer 实现。\nAbstractTracer 这里先来看下 AbstractTracer 这个抽象类中具体提供了哪些抽象方法，也就是对于 AbstractClientTracer 和 AbstractServerTracer 需要分别扩展哪些能力。\n从上图 AbstractTracer 类提供的抽象方法来看，不管是 client 还是 server，在具体的 Tracer 插件实现中，都必须提供以下实现：\n DigestReporterLogName ：当前组件摘要日志的日志名称 DigestReporterRollingKey : 当前组件摘要日志的滚动策略 SpanEncoder：对摘要日志进行编码的编码器实现 AbstractSofaTracerStatisticReporter : 统计日志 reporter 类的实现类 基于 SOFATracer 自身 API 埋点最大的优势在于可以通过上面的这些参数来实现不同组件日志之间的隔离，上述需要实现的这些点是实现一个组件埋点常规的扩展点，是不可缺少的。\n上面分析了 SOFATracer API 的埋点机制，并且对于一些需要扩展的核心点进行了说明。SOFATracer 自身提供的内核非常简单，其基于自身 API 的埋点扩展机制为外部用户定制组件埋点提供了极大的便利。下面以 Thrift 扩展，具体分析如何实现一个组件埋点。\n PS : Thrift 是外部用户基于 SOFATracer API 扩展实现的，目前仅用于其公司内部使用，SOFATracer 官方组件中暂不支持，请知悉；后续会沟通作者提供 PR ，在此先表示感谢。\n Thrift 插件埋点分析 这里我们以 Thrift RPC 插件实现为例，分析如何实现一个埋点插件。\n1、实例工程的分包结构\n从上图插件的工程的包结构可以看出，整个插件实现比较简单，代码量不多，但从类的定义来看，直观的体现了SOFATracer 插件埋点机制所介绍的套路。下面将进行详细的分析与介绍。\n2、实现 Tracer 实例\nRpcThriftTracer 继承了 AbstractTracer 类，是对 clientTracer、serverTracer 的扩展。\n AbstractTracer RpcThriftTracer PS：如何确定一个组件是 client 端还是 server 端呢？就是看当前组件是请求的发起方还是请求的接受方，如果是请求发起方则一般是 client 端，如果是请求接收方则是 server 端。那么对于 RPC 来说，即是请求的发起方也是请求的接受方，因此这里实现了 AbstractTracer 类。\n 3、扩展点类实现\n DigestReporterLogName RpcTracerLogEnum …","date":1553697000,"description":"本文为《剖析 | SOFATracer 框架》最后一篇，本篇作者 Yu Shuqiang，来自小象生鲜。","dir":"blog/sofa-tracer-event-tracing-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"35dc2221b95ec62fd2aa03fca6367554","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","publishdate":"2019-03-27T14:30:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 埋点机制剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/","wordcount":4338},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack\nScalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n SOFAStack 开源一周年，继续补充开源大图 2018 年 4 月， 蚂蚁金服宣布开源 SOFAStack 金融级分布式架构。这一年的时间，感谢社区的信任和支持，目前已经累积超过一万的 Star 数目，超过 30 家企业用户。 2019 年 3 月 24 日，SOFA 在北京举办了首场 Meetup，我们有幸见到了关心SOFA 的朋友们。 此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。 SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nGitHub 地址：https://github.com/sofastack/sofa-registry\n概念 注册中心在微服务架构中位置 服务发现，并非新鲜名词，在早期的 SOA 框架和现在主流的微服务框架中，每个服务实例都需要对外提供服务，同时也需要依赖外部服务。如何找到依赖的服务（即服务定位），最初我们思考了很多方式，比如直接在 Consumer 上配置所依赖的具体的服务地址列表，或者使用 LVS、F5 以及 DNS（域名指向所有后端服务的 IP）等负载均衡。\n但是以上方式都有明显的缺点，比如无法动态感知服务提供方节点变更的情况，另外基于负载均衡的话还需要考虑它的瓶颈问题。所以需要借助第三方的组件，即服务注册中心来提供服务注册和订阅服务，在服务提供方服务信息发生变化、或者节点上下线时，可以动态更新消费方的服务地址列表信息，最终解耦服务调用方和服务提供方。\n能力 服务注册中心的主要能力：\n 服务注册 服务订阅 演进 蚂蚁金服的服务注册中心，经历了 5 代技术架构演进，才最终形成了如今足以支撑蚂蚁海量服务注册订阅的，具有高可用、高扩展性和高时效性的架构。\n数据结构 SOFARegistry 的存储模型比较简单，主要基于 KV 存储两类数据，一类是订阅关系，体现为多个订阅方关心的 Topic（或服务键值）和他们的监听器列表，另一类是同一个 Topic（或服务键值）的发布者列表。基于观察者模式，在服务提供方发生变化时（比如服务提供方的节点上下线），会从订阅关系中寻找相应的订阅者，最终推送最新的服务列表给订阅者。\n存储扩展 主备模式 既然服务注册中心最主要能力之一是存储，那么就要思考：怎么存？存哪儿？存了会不会丢？ 怎么存，主要是由存什么数据来决定的，由于 SOFARegistry 所存储的数据结构比较简单( KV），因为并没有基于关系数据库；另外由于服务发现对变更推送的时效性要求高，但并没有很高的持久化要求(数据可以从服务提供方恢复)，所以最终我们决定自己实现存储能力。 SOFARegistry 的存储节点，最初是主备模式。 强一致集群 随着蚂蚁的服务数据量不断增长，我们将存储改为集群方式，每个存储节点的数据是一样的，每一次写入都保证所有节点写入成功后才算成功。这种模式的特点是每台服务器都存储了全量的服务数据，在当时数据规模比较小的情况下，尚可接受。\n这样的部署结构有两个问题：\n 首先，根据 CAP 原理，在分区容忍性（P）的前提下，为了保持强一致（C），必然牺牲高可用（A）为代价，比如 Zookeeper 是 CP 系统，它在内部选举期间是无法对外提供服务的，另外由于需要保证 C（顺序一致性），写的效率会有所牺牲。 其次，每个节点都存储全量的服务数据，随着业务的发展就有很大的瓶颈问题。 数据分片 如果要实现容量可无限扩展，需要把所有数据按照一定维度进行拆分，并存储到不同节点，当然还需要尽可能地保证数据存储的均匀分布。我们很自然地想到可以进行 Hash 取余，但简单的取余算法在节点数增减时会影响全局数据的分布，所以最终采用了一致性 Hash 算法（这个算法在业界很多场景已经被大量使用，具体不再进行介绍）。\n每个服务数据，经过一致性 Hash 算法计算后会存储到某个具体的 Data 上，整体形成环形的结构。理论上基于一致性 Hash 对数据进行分片，集群可以根据数据量进行无限地扩展。\n内部分层 连接承载 我们知道单机的 TCP 连接数是有限制的，业务应用不断的增多，为了避免单机连接数过多，我们需要将存储节点与业务应用数量成正比地扩容，而我们实际上希望存储节点的数量只跟数据量成正比。所以我们选择从存储节点上把承载连接职责的能力独立抽离出来成为新的一个角色，称之为 Session 节点，Session 节点负责承载来自业务应用的连接。这么一来，SOFARegistry 就由单个存储角色被分为了 Session 和 Data 两个角色，Session 承载连接，Data 承载数据，并且理论上 Session 和 Data 都支持无限扩展。\n如图，客户端直接和 Session 层建立连接，每个客户端只选择连接其中一个 Session 节点，所有原本直接到达 Data层的连接被收敛到 Session 层。Session 层只进行数据透传，不存储数据。客户端随机连接一台 Session 节点，当遇到 Session 不可用时重新选择新的 Session 节点进行重连即可。\n读写分离 分离出 Session 这一层负责承载连接，引起一个新的问题：数据到最终存储节点 Data 的路径变长了，整个集群结构也变的复杂了，怎么办呢？\n我们知道，服务注册中心的一个主要职责是将服务数据推送到客户端，推送需要依赖订阅关系，而这个订阅关系目前是存储到 Data 节点上。在 Data 上存储订阅关系，但是 Client 并没有直接和 Data 连接，那必须要在 Session 上保存映射后才确定推送目标，这样的映射关系占据了大量存储，并且还会随 Session 节点变化进行大量变更，会引起很多不一致问题。\n因此，我们后来决定，把订阅关系信息（Sub）直接存储在 Session 上，并且通过这个关系 Session 直接承担把数据变化推送给客户端的职责。而对于服务的发布信息（Pub）还是通过 Session 直接透传最终在 Data 存储节点上进行汇聚，即同一个服务 ID 的数据来自于不同的客户端和不同的 Session 最终在 Data 的一个节点存储。\n这样划分了 Sub 和 Pub 数据之后，通过订阅关系（Sub）进行推送的过程就有点类似于对服务数据读取的过程，服务发布进行存储的过程有点类似数据写的过程。数据读取的过程，如果有订阅关系就可以确定推送目标，迁移订阅关系数据到 Session，不会影响整个集群服务数据的状态，并且 Client 节点连接新的 Session 时，也会回放所有订阅关系，Session 就可以无状态的 …","date":1553697000,"description":"此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。","dir":"blog/sofa-registry-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"86b3010d0f85f6711d60de29a244ed7e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-registry-deep-dive/","publishdate":"2019-03-27T14:30:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-registry-deep-dive/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFARegistry","SOFAMeetup"],"title":"蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-registry-deep-dive/","wordcount":4313},{"author":"尚彧","categories":"SOFARegistry","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。\n SOFAStack 开源一周年，继续补充开源大图 2018 年 4 月， 蚂蚁金服宣布开源 SOFAStack 金融级分布式架构。这一年的时间，感谢社区的信任和支持，目前已经累积超过一万的 Star 数目，超过 30 家企业用户。\n2019 年 3 月 24 日，SOFA 在北京举办了首场 Meetup，我们有幸见到了关心 SOFA 的朋友们。\n此次，我们宣布开源蚂蚁金服注册中心 SOFARegistry 作为一周年的礼物之一，本文为根据现场分享整理的详细介绍。\nSOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。\nGitHub 地址：https://github.com/alipay/sofa-registry 概念 注册中心在微服务架构中位置 服务发现，并非新鲜名词，在早期的 SOA 框架和现在主流的微服务框架中，每个服务实例都需要对外提供服务，同时也需要依赖外部服务。如何找到依赖的服务（即服务定位），最初我们思考了很多方式，比如直接在 Consumer 上配置所依赖的具体的服务地址列表，或者使用 LVS、F5 以及 DNS（域名指向所有后端服务的 IP）等负载均衡。\n但是以上方式都有明显的缺点，比如无法动态感知服务提供方节点变更的情况，另外基于负载均衡的话还需要考虑它的瓶颈问题。所以需要借助第三方的组件，即服务注册中心来提供服务注册和订阅服务，在服务提供方服务信息发生变化、或者节点上下线时，可以动态更新消费方的服务地址列表信息，最终解耦服务调用方和服务提供方。\n能力 服务注册中心的主要能力：\n 服务注册 服务订阅 演进 蚂蚁金服的服务注册中心，经历了 5 代技术架构演进，才最终形成了如今足以支撑蚂蚁海量服务注册订阅的，具有高可用、高扩展性和高时效性的架构。\n数据结构 SOFARegistry 的存储模型比较简单，主要基于 KV 存储两类数据，一类是订阅关系，体现为多个订阅方关心的 Topic（或服务键值）和他们的监听器列表，另一类是同一个 Topic（或服务键值）的发布者列表。基于观察者模式，在服务提供方发生变化时（比如服务提供方的节点上下线），会从订阅关系中寻找相应的订阅者，最终推送最新的服务列表给订阅者。\n存储扩展 主备模式 既然服务注册中心最主要能力之一是存储，那么就要思考：怎么存？存哪儿？存了会不会丢？ 怎么存，主要是由存什么数据来决定的，由于 SOFARegistry 所存储的数据结构比较简单( KV），因为并没有基于关系数据库；另外由于服务发现对变更推送的时效性要求高，但并没有很高的持久化要求(数据可以从服务提供方恢复)，所以最终我们决定自己实现存储能力。 SOFARegistry 的存储节点，最初是主备模式。 强一致集群 随着蚂蚁金服的服务数据量不断增长，我们将存储改为集群方式，每个存储节点的数据是一样的，每一次写入都保证所有节点写入成功后才算成功。这种模式的特点是每台服务器都存储了全量的服务数据，在当时数据规模比较小的情况下，尚可接受。\n这样的部署结构有两个问题：\n 首先，根据 CAP 原理，在分区容忍性（P）的前提下，为了保持强一致（C），必然牺牲高可用（A）为代价，比如 Zookeeper 是 CP 系统，它在内部选举期间是无法对外提供服务的，另外由于需要保证 C（顺序一致性），写的效率会有所牺牲。 其次，每个节点都存储全量的服务数据，随着业务的发展就有很大的瓶颈问题。 数据分片 如果要实现容量可无限扩展，需要把所有数据按照一定维度进行拆分，并存储到不同节点，当然还需要尽可能地保证数据存储的均匀分布。我们很自然地想到可以进行 Hash 取余，但简单的取余算法在节点数增减时会影响全局数据的分布，所以最终采用了一致性 Hash 算法（这个算法在业界很多场景已经被大量使用，具体不再进行介绍）。\n每个服务数据，经过一致性 Hash 算法计算后会存储到某个具体的 Data 上，整体形成环形的结构。理论上基于一致性 Hash 对数据进行分片，集群可以根据数据量进行无限地扩展。\n内部分层 连接承载 我们知道单机的 TCP 连接数是有限制的，业务应用不断的增多，为了避免单机连接数过多，我们需要将存储节点与业务应用数量成正比地扩容，而我们实际上希望存储节点的数量只跟数据量成正比。所以我们选择从存储节点上把承载连接职责的能力独立抽离出来成为新的一个角色，称之为 Session 节点，Session 节点负责承载来自业务应用的连接。这么一来，SOFARegistry 就由单个存储角色被分为了 Session 和 Data 两个角色，Session 承载连接，Data 承载数据，并且理论上 Session 和 Data 都支持无限扩展。\n如图，客户端直接和 Session 层建立连接，每个客户端只选择连接其中一个 Session 节点，所有原本直接到达 Data层的连接被收敛到 Session 层。Session 层只进行数据透传，不存储数据。客户端随机连接一台 Session 节点，当遇到 Session 不可用时重新选择新的 Session 节点进行重连即可。\n读写分离 分离出 Session 这一层负责承载连接，引起一个新的问题：数据到最终存储节点 Data 的路径变长了，整个集群结构也变的复杂了，怎么办呢？\n我们知道，服务注册中心的一个主要职责是将服务数据推送到客户端，推送需要依赖订阅关系，而这个订阅关系目前是存储到 Data 节点上。在 Data 上存储订阅关系，但是 Client 并没有直接和 Data 连接，那必须要在 Session 上保存映射后才确定推送目标，这样的映射关系占据了大量存储，并且还会随 Session 节点变化进行大量变更，会引起很多不一致问题。\n因此，我们后来决定，把订阅关系信息（Sub）直接存储在 Session 上，并且通过这个关系 Session 直接承担把数据变化推送给客户端的职责。而对于服务的发布信息（Pub）还是通过 Session 直接透传最终在 Data 存储节点上进行汇聚，即同一个服务 ID 的数据来自于不同的客户端和不同的 Session 最终在 Data 的一个节点存储。\n这样划分了 Sub 和 Pub 数据之后，通过订阅关系（Sub）进行推送的过程就有点类似于对服务数据读取的过程，服务发布进行存储的过程有点类似数据写的过程。数据读取的过程，如果有订阅关系就可以确定推送目标，迁移订阅关系数据到 Session，不会影响整个集群服务数据的状态，并且 Client 节点连接新的 Session 时，也会回放所有订阅关系，Session 就可以无状态的 …","date":1553670000,"description":"本文根据 SOFA Meetup#1 北京站 现场分享整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/sofa-meetup-1-registry/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0e3d1f0cf167e7afea39c2435ceefcfd","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-registry/","publishdate":"2019-03-27T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-meetup-1-registry/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文根据 SOFA Meetup#1 北","tags":["SOFARegistry","SOFAMeetup"],"title":"蚂蚁金服开源服务注册中心 SOFARegistry | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/sofa-meetup-1-registry/","wordcount":4318},{"author":"蚂蚁金服团队","categories":"seata","content":" Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。\nSample 地址：https://github.com/fescar-group/fescar-samples/tree/master/tcc\n文末也提供了项目后续的 Roadmap，欢迎关注。\n一、TCC 简介 在两阶段提交协议（2PC，Two Phase Commitment Protocol）中，资源管理器（RM, resource manager）需要提供“准备”、“提交”和“回滚” 3 个操作；而事务管理器（TM, transaction manager）分 2 阶段协调所有资源管理器，在第一阶段询问所有资源管理器“准备”是否成功，如果所有资源均“准备”成功则在第二阶段执行所有资源的“提交”操作，否则在第二阶段执行所有资源的“回滚”操作，保证所有资源的最终状态是一致的，要么全部提交要么全部回滚。\n资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现；TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题；TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中；事务管理器分 2 阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法；最终所有 TCC 服务要么全部都是提交的，要么全部都是回滚的。\n二、TCC 设计 用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上，进过蚂蚁金服多年的 TCC 应用，总结如下主要的TCC 设计和实现主要事项：\n1、业务操作分两阶段完成 接入 TCC 前，业务操作只需要一步就能完成，但是在接入 TCC 之后，需要考虑如何将其分成 2 阶段完成，把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户A的余额中有 100 元，需要扣除其中 30 元”；\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成 2 步完成：\n Try 操作：资源的检查和预留； 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交； 在扣款场景下，Confirm 阶段走的事情就是发生真正的扣款，把A账户中已经冻结的 30 元钱扣掉。\n Cancel 操作：预留资源的是否； 在扣款场景下，扣款取消，Cancel 操作执行的任务是释放 Try 操作冻结的 30 元钱，是 A 账户回到初始状态。\n2、并发控制 用户在实现 TCC 时，应当考虑并发性问题，将锁的粒度降到最低，以最大限度的提高分布式事务的并发性。\n以下还是以A账户扣款为例，“账户 A 上有 100 元，事务 T1 要扣除其中的 30 元，事务 T2 也要扣除 30 元，出现并发”。\n在一阶段 Try 操作中，分布式事务 T1 和分布式事务 T2 分别冻结资金的那一部分资金，相互之间无干扰；这样在分布式事务的二阶段，无论 T1 是提交还是回滚，都不会对 T2 产生影响，这样 T1 和 T2 在同一笔业务数据上并行执行。\n3、允许空回滚 如下图所示，事务协调器在调用 TCC 服务的一阶段 Try 操作时，可能会出现因为丢包而导致的网络超时，此时事务管理器会触发二阶段回滚，调用 TCC 服务的 Cancel 操作，而 Cancel 操作调用未出现超时。\nTCC 服务在未收到 Try 请求的情况下收到 Cancel 请求，这种场景被称为空回滚；空回滚在生产环境经常出现，用户在实现TCC服务时，应允许允许空回滚的执行，即收到空回滚时返回成功。\n4、防悬挂控制 如下图所示，事务协调器在调用 TCC 服务的一阶段 Try 操作时，可能会出现因网络拥堵而导致的超时，此时事务管理器会触发二阶段回滚，调用 TCC 服务的 Cancel 操作，Cancel 调用未超时；在此之后，拥堵在网络上的一阶段 Try 数据包被 TCC 服务收到，出现了二阶段 Cancel 请求比一阶段 Try 请求先执行的情况，此 TCC 服务在执行晚到的 Try 之后，将永远不会再收到二阶段的 Confirm 或者 Cancel ，造成 TCC 服务悬挂。\n用户在实现 TCC 服务时，要允许空回滚，但是要拒绝执行空回滚之后 Try 请求，要避免出现悬挂。\n5、幂等控制 无论是网络数据包重传，还是异常事务的补偿执行，都会导致 TCC 服务的 Try、Confirm 或者 Cancel 操作被重复执行；用户在实现 TCC 服务时，需要考虑幂等控制，即 Try、Confirm、Cancel 执行一次和执行多次的业务结果是一样的。\nRoadmap 当前已经发布到 0.4.0 版本，后续我们会发布 0.5 ~ 1.0 版本，继续对 AT、TCC 模式进行功能完善和和丰富，并解决服务端高可用问题，在 1.0 版本之后，本开源产品将达到生产环境使用的标准。\n","date":1553583600,"description":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。","dir":"blog/seata-tcc-theory-design-realization/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"45ef8a72beefcd26f4f62e7bdb34671c","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-tcc-theory-design-realization/","publishdate":"2019-03-26T15:00:00+08:00","readingtime":4,"relpermalink":"/sofastack.tech/blog/seata-tcc-theory-design-realization/","summary":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。 Sample 地址：https://github.com/fescar-group/fescar","tags":["seata"],"title":"TCC 理论及设计实现指南介绍","type":"blog","url":"/sofastack.tech/blog/seata-tcc-theory-design-realization/","wordcount":1971},{"author":"蚂蚁金服团队","categories":"seata","content":" Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用，文末也提供了项目后续的 Roadmap，欢迎关注。\n前言：基于 TCC 模型的应用场景 TCC 分布式事务模型直接作用于服务层。不与具体的服务框架耦合，与底层 RPC 协议无关，与底层存储介质无关，可以灵活选择业务资源的锁定粒度，减少资源锁持有时间，可扩展性好，可以说是为独立部署的 SOA 服务而设计的。\n一、TCC 模型优势 对于 TCC 分布式事务模型，笔者认为其在业务场景应用上，有两方面的意义。\n1.1 跨服务的分布式事务 服务的拆分，也可以认为是资源的横向扩展，只不过方向不同而已。\n横向扩展可能沿着两个方向发展：\n 功能扩展，根据功能对数据进行分组，并将不同的功能组分布在多个不同的数据库上，这实际上就是 SOA 架构下的服务化。 数据分片，在功能组内部将数据拆分到多个数据库上，为横向扩展增加一个新的维度。 下图简要阐释了横向数据扩展策略：\n横向扩展的两种方法可以同时进行运用：用户信息（Users）、产品信息（Products）与交易信息（Trans）三个不同功能组可以存储在不同的数据库中。另外，每个功能组内根据其业务量可以再拆分到多个数据库中，各功能组可以相互独立地进行扩展。\n因此，TCC 的其中一个作用就是在按照功能横向扩展资源时，保证多资源访问的事务属性。\n1.2 两阶段拆分 TCC 另一个作用就是把两阶段拆分成了两个独立的阶段，通过资源业务锁定的方式进行关联。资源业务锁定方式的好处在于，既不会阻塞其他事务在第一阶段对于相同资源的继续使用，也不会影响本事务第二阶段的正确执行。\n传统模型的并发事务：\nTCC 模型的并发事务：\n可以发现 TCC 模型进一步减少了资源锁的持有时间。同时，从理论上来说，只要业务允许，事务的第二阶段什么时候执行都可以，反正资源已经业务锁定，不会有其他事务动用该事务锁定的资源。\n这对业务有什么好处呢？拿支付宝的担保交易场景来说，简化情况下，只需要涉及两个服务，交易服务和账务服务。交易作为主业务服务，账务作为从业务服务，提供 Try、Commit、Cancel 接口：\n Try 接口扣除用户可用资金，转移到预冻结资金。预冻结资金就是业务锁定方案，每个事务第二阶段只能使用本事务的预冻结资金，在第一阶段执行结束后，其他并发事务也可以继续处理用户的可用资金。 Commit 接口扣除预冻结资金，增加中间账户可用资金（担保交易不能立即把钱打给商户，需要有一个中间账户来暂存）。 假设只有一个中间账户的情况下，每次调用支付服务的 Commit 接口，都会锁定中间账户，中间账户存在热点性能问题。 但是，在担保交易场景中，七天以后才需要将资金从中间账户划拨给商户，中间账户并不需要对外展示。因此，在执行完支付服务的第一阶段后，就可以认为本次交易的支付环节已经完成，并向用户和商户返回支付成功的结果，并不需要马上执行支付服务二阶段的 Commit 接口，等到低锋期时，再慢慢消化，异步地执行。\n可能部分读者认为担保交易比较特殊，其实直付交易（直接把钱打到商户账户的交易模式，Commit 接口扣除预冻结资金以后，不是转移到中间账务，而是直接转移到商户账户）也可以这样使用，只要提前告知商户，高峰期交易资金不是实时到账，但保证在一定时间之内结算完成，商户应该也是可以理解的。\n这就是 TCC 分布式事务模型的二阶段异步化功能，从业务服务的第一阶段执行成功，主业务服务就可以提交完成，然后再由框架异步的执行各从业务服务的第二阶段。\n二、通用型 TCC 解决方案 通用型 TCC 解决方案就是最典型的 TCC 分布式事务模型实现，所有从业务服务都需要参与到主业务服务的决策当中。\n适用场景 由于从业务服务是同步调用，其结果会影响到主业务服务的决策，因此通用型 TCC 分布式事务解决方案适用于执行时间确定且较短的业务，比如互联网金融企业最核心的三个服务：交易、支付、账务：\n当用户发起一笔交易时，首先访问交易服务，创建交易订单；然后交易服务调用支付服务为该交易创建支付订单，执行收款动作，最后支付服务调用账务服务记录账户流水和记账。\n为了保证三个服务一起完成一笔交易，要么同时成功，要么同时失败，可以使用通用型 TCC 解决方案，将这三个服务放在一个分布式事务中，交易作为主业务服务，支付作为从业务服务，账务作为支付服务的嵌套从业务服务，由 TCC 模型保证事务的原子性。\n支付服务的 Try 接口创建支付订单，开启嵌套分布式事务，并调用账务服务的 Try 接口；账务服务在 Try 接口中冻结买家资金。一阶段调用完成后，交易完成，提交本地事务，由 TCC 框架完成分布式事务各从业务服务二阶段的调用。\n支付服务二阶段先调用账务服务的 Confirm 接口，扣除买家冻结资金；增加卖家可用资金。调用成功后，支付服务修改支付订单为完成状态，完成支付。\n当支付和账务服务二阶段都调用完成后，整个分布式事务结束。\n三、异步确保型 TCC 解决方案 异步确保型 TCC 解决方案的直接从业务服务是可靠消息服务，而真正的从业务服务则通过消息服务解耦，作为消息服务的消费端，异步地执行。\n可靠消息服务需要提供 Try，Confirm，Cancel 三个接口。Try 接口预发送，只负责持久化存储消息数据；Confirm 接口确认发送，这时才开始真正的投递消息；Cancel 接口取消发送，删除消息数据。\n消息服务的消息数据独立存储，独立伸缩，降低从业务服务与消息系统间的耦合，在消息服务可靠的前提下，实现分布式事务的最终一致性。\n此解决方案虽然增加了消息服务的维护成本，但由于消息服务代替从业务服务实现了 TCC 接口，从业务服务不需要任何改造，接入成本非常低。\n适用场景 由于从业务服务消费消息是一个异步的过程，执行时间不确定，可能会导致不一致时间窗口增加。因此，异步确保性 TCC 分布式事务解决方案只适用于对最终一致性时间敏感度较低的一些被动型业务（从业务服务的处理结果不影响主业务服务的决策，只被动的接收主业务服务的决策结果）。比如会员注册服务和邮件发送服务：\n当用户注册会员成功，需要给用户发送一封邮件，告诉用户注册成功，并提示用户激活该会员。但要注意两点：\n 如果用户注册成功，一定要给用户发送一封邮件； 如果用户注册失败，一定不能给用户发送邮件。 因此，这同样需要会员服务和邮件服务保证原子性，要么都执行，要么都不执行。不一样的是，邮件服务只是一种被动型的业务，并不影响用户是否能够注册成功，它只需要在用户注册成功以后发送邮件给用户即可，邮件服务不需要参与到会员服务的活动决策中。\n对于此种业务场景，可以使用异步确保型TCC分布式事务解决方案，如下：\n由可靠消息服务来解耦会员和邮件服务，会员服务与消息服务组成 TCC 事务模型，保证事务原子性。然后通过消息服务的可靠特性，确保消息一定能够被邮件服务消费，从而使得会员与邮件服务在同一个分布式事务中。同时，邮件服务也不会影响会员服务的执行过程，只在会员服务执行成功后被动接收发送邮件的请求。\n四、补偿型 TCC 解决方案 补偿型 TCC 解决方案与通用型 TCC 解决方案的结构相似，其从业务服务也需要参与到主 …","date":1553410800,"description":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用。","dir":"blog/seata-tcc-applicable-models-scenarios/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa8436ce2760fafb880427799a763f32","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","publishdate":"2019-03-24T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","summary":"Fescar 0.4.0 版本发布了 TCC 模式，由蚂蚁金服团队贡献，欢迎大家试用，文末也提供了项目后续的 Roadmap，欢迎关注。 前言：基于 TCC 模型的应用场景 TCC 分布式事","tags":["seata"],"title":"TCC 适用模型与适用场景分析","type":"blog","url":"/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/","wordcount":3912},{"author":"善逝","categories":"SOFAArk","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服在 SOFAStack 体系内研发了一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力\u0026amp;ndash;SOFAArk。本篇文章为 SOFAArk 0.6.0 的新特性介绍。 GitHub 地址：https://github.com/alipay/sofa-ark\n 简介 在大型软件开发过程中，通常会推荐底层功能插件化、业务功能模块化的开发模式，以其达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化开发方案，产品能力主要包括：\n 定义插件开发规范，提供 Maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin）， 适用于将底层组件插件化输出，例如 RPC、富客户端等； 定义模块开发规范，提供 Maven 打包工具，简单快速将应用（Spring Boot/SOFABoot/普通 Java 应用）打包成模块 (Ark Biz，以下简称 Biz)，适用于将业务组件模块化输出，提升业务能力复用； 定义类加载模型，运行时 Plugin、Biz 之间均相互隔离，运行时由不同的 ClassLoader 加载，有效避免相互之间的包冲突，降低 Plugin 和 Biz 对运行环境的要求； 定义标准的编程界面，包括服务、事件、扩展点等机制，方便 Plugin、Biz 交互和扩展； 定义业务模块 (Biz) 生命周期，支持多 Biz 合并部署。开发阶段将多个 Biz 打包成 Executable Ark Jar 包(以下简称 Ark 包)，或者运行时使用 API 或配置中心(Zookeeper)动态地管理 Biz 安装和卸载，满足多应用合并部署及动态升级的需求。 基于以上能力，SOFAArk 可以帮助解决多应用(模块)合并部署、动态升级、依赖包冲突等场景问题。\n场景 场景一：合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件。协调跨团队合作开发会遇到不少问题：比如各自技术栈不统一导致的依赖冲突、往同一个 Git 仓库提交代码常常导致 merge 冲突、组件功能相互依赖影响测试进度。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发和测试，运行时合并部署，那么将有助于提升开发效率及应用可扩展性。\nSOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互，如下：\nBiz 对应用类型没有限制，可以是 Spring Boot/SOFABoot/Java 普通应用类型，Biz 之间采用统一的编程界面-SOFA JVM服务进行交互。发布和引用服务也非常简单，使用 API 或者 Spring 注解/XML 方式：\n合并部署的形式，分为两种 \u0026amp;ndash; 静态合并部署和动态合并部署。\n静态合并部署 在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成 Ark 包时，会将引入的其他 Biz 包一并打入。通过 java -jar 启动 Ark 包时，则会根据优先级依次启动各 Biz，单个 Biz 使用独立的 BizClassLoader 加载，不需要考虑依赖包冲突问题，Biz 之间则通过 SOFA JVM 服务交互。\n动态合并部署 动态合并部署区别于静态合并部署最大的一点是，在运行时可以通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态合并部署的设计理念图如下：\n无论是静态抑或动态合并部署都有存在宿主应用 (master biz) 的概念，如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主 Biz 和其他 Biz 唯一不同在于，宿主 Biz 不允许被卸载。\n一般而言，宿主应用会作为流量入口的中台系统，具体的服务实现会放在不同的动态 Biz 中，供宿主应用调用。宿主应用可以使用 SOFAArk 提供的客户端 API 实现动态应用的部署和卸载。除了 API， SOFAArk 提供了 Config Plugin，用于对接配置中心（目前支持 Zookeeper），运行时接受动态配置；Config Plugin 会解析下发的配置，控制动态应用的部署和卸载。\n场景二：动态升级 SOFAArk 在蚂蚁内部也被用来解决动态升级的场景问题。有时候，因为业务迭代较快，应用依赖的某二方包需要频繁的变更，这将导致应用每次都因为升级二方包版本做变更发布，影响开发效率；而作为二方包的开发者，常常因为推动依赖方应用升级阻力较大，导致新特性无法按时上线，影响业务发展。\n为了加快创新业务的迭代速度，会将需要频繁变更的二方包打包成 Biz 包，供其他应用依赖。作为依赖方，不会直接在 Pom 文件（假设是使用 Maven 构建）定义 Biz 包版本，而是通过配置中心（例如 Zookeeper）下发配置。如此，当应用启动时，会拉取 Biz 版本配置信息，进而拉取正确版本的 Biz 包并启动。如此，当需要依赖方升级 Biz 版本时，只需要在配置中心重新推送配置即可。\n场景三：依赖隔离 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError, NoSuchMethodError 等。实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法：统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突。这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题。如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题。 OSGi 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGi 框架门槛较高，功能繁杂。为了解决包冲突问题，引入 OSGi 框架，有牛刀杀鸡之嫌，反而使工程变得更加复杂，不利于开发。\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如 …","date":1553065200,"description":"本篇文章为 SOFAArk 0.6.0 的新特性介绍。","dir":"blog/sofa-ark-0.6.0/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7a25cfa30d66586c83abafd947447de3","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-ark-0.6.0/","publishdate":"2019-03-20T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-ark-0.6.0/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 蚂蚁金服在 SOFAStack 体","tags":["SOFAArk"],"title":"蚂蚁金服 SOFAArk 0.6.0 新特性介绍 | 模块化开发容器","type":"blog","url":"/sofastack.tech/blog/sofa-ark-0.6.0/","wordcount":3490},{"author":"炎竹","categories":"SOFAActs","content":" SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服在 SOFAStack 体系内研发了基于模型驱动的自动化接口测试框架 SOFAACTS。 GitHub 地址：https://github.com/alipay/sofa-acts\n 背景 伴随着业务需求的爆发，蚂蚁金服金融级分布式架构质量测试活动变得复杂起来，表现在测试的业务场景复杂，诸如分布式事务处理流程场景、并发性、账户状态多样性、幂等性和兼容性等等。在原有的自动化测试框架下，测试流程编排极易出现测试数据冗余分散、可维护性差、人工编码成本高和测试验证点易遗漏的问题。\n如何解决上面的问题呢？\n蚂蚁金服在 SOFAStack 体系内研发了基于模型驱动的自动化接口测试框架 SOFAACTS。\nSOFAACTS 介绍 SOFAACTS 由 IDE 和测试引擎组成，下图为产品架构图：\n框架适配 TestNg+Spring 的测试上下文环境，以 YAML 为数据载体并在此上构建数据模型驱动，具有契合快速互联网发展和复杂分布式金融系统特点的优良特性：\n 模型驱动和标准执行引擎； 精细化校验和数据的自动回写； 具有灵活的可扩展性； 用例可视化维护。 1.模型驱动和标准化 在测试用例数据与测试代码分离的探索上，很多测试框架采用数据驱动的方式，但这也无法从容应对金融级的复杂业务场景。框架对用例数据进行了深度抽象，提出模型驱动理念，研发出基于模型的数据驱动和标准化执行引擎，实现了数据和代码的分离管理，同时对测试过程中的数据清理、数据准备、用例执行、结果校验阶段进行标准化，做到测试数据维护和测试代码的简洁优雅。用例执行时用户无需关注数据如何加载，结果和期望数据如何比对，只需要关注测试数据和执行结果。\n接下来，我们介绍如何使用 SOFAACTS 来高效率地完成一键生成数据模型生成和一键生成测试脚本。\n数据模型生成 首先进行数据模型的准备，以方便之后模版化地快速创建对象和表，按照如下方式来准备 DB 数据、接口请求参数和返回结果对象模型。\nDB 数据模型生成 任意测试代码中右击-\u0026amp;gt; SOFAACTS 功能-\u0026amp;gt;生成 DB 表结构模板； 选择生成的目标测试工程； 点击确认后选择并添加需要生成模型的表即可生成。 类对象模型生成 待构建模型的类定义的任意方法上右击-\u0026amp;gt; SOFAACTS 功能-\u0026amp;gt;模板生成，生成当前对象的模型； 生成完成后，我们可以在下图位置找到生成的数据对象模型； 按照上述步骤，这样我们就生成了接口对象模板。 现在，我们开始进行脚本一键生成：\n测试脚本生成 SOFAACTS IDE 提供测试脚本自动生成功能，无需手动编码。操作方式如下：\n 被测接口方法上点击，选择 SOFAACTS 功能\u0026amp;ndash;\u0026amp;gt;生成测试用例； 这时会弹出一个文本框，填写脚本生成的位置和编码格式，如下： 填写完成后，点击 OK 即可自动生成如下测试脚本，可以看出模型驱动生成的脚本精简而优雅。 原来数据驱动下的脚本是如下面图这样的，测试数据冗余分散，人工编码成本高维护性差。\n实践证明 SOFAACTS 用例的测试代码构建效率提高 80% ，测试数据精简到 1/case 数。\n2.精细化校验 在解决复杂业务场景下测试验证难、易遗漏等问题时，SOFAACTS 基于代码行为跟踪和分析理念，通过反射机制和日志解析实现结果数据的自动采集，以此做为场景用例校验的数据基线，并在持续集成时进行基线全量因子匹配来达到精细化验证。如下图：\n同时，为了提高自动采集后数据回填的效率，框架支持预校验数据的自动写入能力，进一步实现了数据的自动化精细校验。如下图：一键点击即可采集到校验数据基线，在蚂蚁内部实践中 ACTS 做到了结果校验效率提升至少 80%，场景验证 0 遗漏。\n3.灵活可扩展 框架为了应对各种特殊业务测试情况而不需要过多改动，设计上应用高内聚与低耦合原则，支持既可以复用框架底层代码又可以针对业务个性化情况做扩展的能力。整个框架提供了丰富的 API，测试执行过程每个方法、每个类以便测试执行过程的每个阶段（如下图）都能够在测试脚本里面被重新为其他方法或者被其他多态的子类替换，这样让框架变得更通用，既赋予了框架轻量性又增加了灵活性。\n自定义的 API 如下：\nAPI 的具体使用请详细学习产品使用手册。\n4.用例可视化维护 框架支持研发集成环境的一站式编辑，高效的用例脚本和数据维护，有效减少重复性的数据准备代码。如下图：\n总结 以上便是对 SOFAACTS 测试框架的基本介绍，还有诸多能力各位可以查阅我们详细的使用手册。\n目前，SOFAACTS 已经在蚂蚁金服大范围使用，分钟级用例编写 10 倍效能提升，累计用例个数 10w 以上，高频功能使用可达近 2000 次/日，并持续保持着旺盛的生命力。\n当前，代码已开源托管在 GitHub 上，欢迎关注，同时也欢迎业界爱好者共同创造更好的 SOFAACTS。\nGitHub 项目地址：https://github.com/alipay/sofa-acts\n相关链接 SOFAACTS ：https://github.com/alipay/sofa-acts API 产品使用手册：https://www.sofastack.tech/sofa-acts/docs/Usage-API SOFAACTS 详细使用手册：https://www.sofastack.tech/sofa-acts/docs/Home 招聘 蚂蚁金服金融核心测试技术团队持续寻找对测试自动化、智能风险管控等方向充满热情的小伙伴加入，有意者请联系 zhiqiang.li@antfin.com\n","date":1552546800,"description":"SOFAStack 体系，基于模型驱动的自动化接口测试框架 SOFAACTS。","dir":"blog/sofa-acts-automated-testing-framework/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b76c650b1a69560fe38c8e4f237f6207","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-acts-automated-testing-framework/","publishdate":"2019-03-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-acts-automated-testing-framework/","summary":"SOFAStack Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 蚂蚁金服在 SOFAStack 体","tags":["SOFAActs"],"title":"SOFAStack 开源自动化测试框架 SOFAACTS","type":"blog","url":"/sofastack.tech/blog/sofa-acts-automated-testing-framework/","wordcount":2096},{"author":"家纯","categories":"SOFAJRaft","content":" 什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 Raft 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。 SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\n 基础知识：分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 Paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 Paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等）。 Zab：被应用在 Zookeeper 中，业界使用广泛，但没有抽象成通用的 library。 Raft：以容易理解著称，业界也涌现出很多 Raft 实现，比如大名鼎鼎的 etcd, braft, tikv 等。 什么是 Raft？ Raft 是一种更易于理解的分布式共识算法，核心协议本质上还是师承 Paxos 的精髓，不同的是依靠 Raft 模块化的拆分以及更加简化的设计，Raft 协议相对更容易实现。\n模块化的拆分主要体现在：Raft 把一致性协议划分为 Leader 选举、MemberShip 变更、日志复制、Snapshot 等几个几乎完全解耦的模块。\n更加简化的设计则体现在：Raft 不允许类似 Paxos 中的乱序提交、简化系统中的角色状态（只有 Leader、Follower、Candidate 三种角色）、限制仅 Leader 可写入、使用随机化的超时时间来设计 Leader Election 等等。\n特点：Strong Leader 系统中必须存在且同一时刻只能有一个 Leader，只有 Leader 可以接受 Clients 发过来的请求； Leader 负责主动与所有 Followers 通信，负责将“提案”发送给所有 Followers，同时收集多数派的 Followers 应答； Leader 还需向所有 Followers 主动发送心跳维持领导地位(保持存在感)。 一句话总结 Strong Leader: \u0026amp;ldquo;你们不要 BB! 按我说的做，做完了向我汇报!\u0026amp;rdquo;。另外，身为 Leader 必须保持一直 BB(heartbeat) 的状态，否则就会有别人跳出来想要 BB 。\nRaft 中的基本概念 篇幅有限，这里只对 Raft 中的几个概念做一个简单介绍，详细请参考 Raft paper。\nRaft-node 的 3 种角色/状态 Follower：完全被动，不能发送任何请求，只接受并响应来自 Leader 和 Candidate 的 Message，每个节点启动后的初始状态一定是 Follower； Leader：处理所有来自客户端的请求，以及复制 Log 到所有 Followers； Candidate：用来竞选一个新 Leader （Candidate 由 Follower 触发超时而来）。 Message 的 3 种类型 RequestVote RPC：由 Candidate 发出，用于发送投票请求； AppendEntries (Heartbeat) RPC：由 Leader 发出，用于 Leader 向 Followers 复制日志条目，也会用作 Heartbeat （日志条目为空即为 Heartbeat）； InstallSnapshot RPC：由 Leader 发出，用于快照传输，虽然多数情况都是每个服务器独立创建快照，但是Leader 有时候必须发送快照给一些落后太多的 Follower，这通常发生在 Leader 已经丢弃了下一条要发给该Follower 的日志条目(Log Compaction 时清除掉了) 的情况下。 任期逻辑时钟 时间被划分为一个个任期 (term)，term id 按时间轴单调递增； 每一个任期的开始都是 Leader 选举，选举成功之后，Leader 在任期内管理整个集群，也就是 “选举 + 常规操作”； 每个任期最多一个 Leader，可能没有 Leader (spilt-vote 导致)。 本图出自《Raft: A Consensus Algorithm for Replicated Logs》\n什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 Raft 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。\nSOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。\nSOFAJRaft 整体功能\u0026amp;amp;性能优化 功能支持 Leader election：Leader 选举，这个不多说，上面已介绍过 Raft 中的 Leader 机制。\n Log replication and recovery：日志复制和日志恢复。\n Log replication 就是要保证已经被 commit 的数据一定不会丢失，即一定要成功复制到多数派。 Log recovery 包含两个方面： Current term 日志恢复：主要针对一些 Follower 节点重启加入集群或者是新增 Follower 节点后如何追日志； Prev term 日志恢复：主要针对 Leader 切换前后的日志一致性。 Snapshot and log compaction：定时生成 snapshot，实现 log compaction 加速启动和恢复，以及 InstallSnapshot 给 Followers 拷贝数据，如下图：\n 本图出自《In Search of an Understandable Consensus Algorithm》\n Membership change：用于集群线上配置变更，比如增加节点、删除节点、替换节点等。\n Transfer leader：主动变更 leader，用于重启维护，leader 负载平衡等。\n Symmetric network partition tolerance：对称网络分区容忍性。\n 如上图 S1 为当前 leader，网络分区造成 S2 不断增加本地 term，为了避免网络恢复后 S2 …","date":1552374000,"description":"本文为 SOFAJRaft 的基础解析，欢迎阅读~","dir":"blog/sofa-jraft-production-level-algorithm-library/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a2e98969240f05af10554781f4ab81ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","publishdate":"2019-03-12T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","summary":"什么是 SOFAJRaft？ SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 使用","tags":["SOFAJRaft","SOFALab"],"title":"SOFAStack 开源 SOFAJRaft：生产级 Java Raft 算法库","type":"blog","url":"/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/","wordcount":6481},{"author":"Linux 中国 老王","categories":"SOFAStack","content":" 我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\u0026amp;ndash; 蚂蚁金服总监杨冰\n引言 最近，我听到了一个消息，蚂蚁金服将会开源 SOFA最核心的两个组件——分布式事务框架和服务注册中心。\n熟悉中间件的朋友们都知道，这两个组件都是针对当前最火的微服务架构。其中，分布式事物框架是解决数据一致性问题的关键。服务注册中心则是服务治理的基础。在这两块开源后，SOFA 将成为一套真正完备的分布式解决方案。\n作为开源人士，我对此消息深感兴趣，因此联系到了蚂蚁金服中间件团队的杨冰总监，就此消息向他求证。机缘凑巧之下，杨冰花费了宝贵的时间，和我深入讲述了 SOFA 开源的思考，以及近期的规划。\n通过这次交谈，也让我看到了一个成功的商业公司是如何拥抱开源、并将开源作为其根本战略来撬动技术红利，支持其急速发展的业务需求的。\n以下是正文，我将它分享出来以飨读者。\n如今，开源已经成为主流，可以说，整个信息产业已经从过去的闭源模式转换为现今的开源模式。各种开源公司纷纷创新不同的开源模式，其中以 RedHat、Google、Facebook 等公司所取得的成绩最为耀眼。\n2018 年的时候，我曾经参与“开源社”主持的《2018 中国开源年度报告》的撰写工作，并建立了一个数学分析模型，以此来对中国的互联网公司的开源项目分析其活跃度和健康度。让我既感意外，也不意外的是，阿里系的开源项目占据了活跃度排行榜前五的第一、第二和第四；甚至在前五十个项目中，阿里系的开源项目占据了超过一半的份额！我不意外的是，业界一直对阿里在开源方面的动作和力度颇有感受；意外的是，这种力度还是超乎了我的想象。这其中包括阿里巴巴集团和蚂蚁金服等都贡献了相当可观的开源项目。\n因此，这次遇到杨冰时，我就开源方面和他深入聊了几句，想了解一下蚂蚁金服是如何思考开源和践行开源的，是如何将开源与公司的商业价值有机地结合起来的。\n缘何开源 作为一家商业公司，宣称自己开源，甚至也形式上开源一些代码，其实已经是很常见的事情了。但是，真正能将开源与公司的技术演进相融合，并能有效地助推公司业务发展的，却并不太多。这件事其实并没有那么简单——远非只是上传到 GitHub 那么简单。\n根据业界的经验，在公司的技术产品开源方面，要将现有场景的代码开源，至少需要在已经运行稳定、结构清晰的现有代码基础上多付出 30% 的技术投入，对代码进行梳理、完善和通用化，才能做到初步的代码开源；而进一步要将这些开源代码维护下去，乃至于和公司业务线上的产品代码保持同步发展，多付出的技术成本还远远不止这些。作为一个互联网技术老兵，我对此深以为然。\n那么，蚂蚁金服是如何说服公司决策层在尚未看到开源回报的前景下，同意付出这么多的额外代价来支持开源的呢？推动开源的力量是因何而来的？\n“首先，开源是个共赢的模式，对于蚂蚁金服来说，开源可以扩大技术服务场景，为支付、金融等更多的客户提供服务，提升合作伙伴的效率。”杨冰说，“虽然，蚂蚁金服已经有很多的业务场景，也在很多场景下取得了超大规模的实践经验，但是，依然存在没有覆盖到的金融服务场景。而将技术开源出来，可以供更多的客户应用到其自身的场景下——这些场景有效的补充了蚂蚁金服的技术应用面，也为更完善的技术框架奠定了基础。因此，我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。”\n“其次，对金融服务来说，监管和自主可控的要求更多，”杨冰接着谈到，“客户也希望可以对其所采用的技术有更多的掌控。”开源是一种可以使客户和上下游产业共同参与和发展的可行模式。\n“所以，其实并不是技术部门去说服公司决策层去开源，而是业务发展的自然选择，这也是一种合理的发展方向。”他总结道。这样的结果，其实是和当前流行的开源商业模式所暗合的。\n“另外，如你所说，确实在开源时，我们做了很大的改造。以可扩展化的方式来层层构建 SOFA 框架的能力，保证 SOFA 的内部版本和开源的版本采用的是同一个内核。在开源时，剥离了特定业务的逻辑，而保持了公司内部的业务线上的代码和开源代码的核心是一致的。这样，只要公司的业务在持续发展，开源的代码就会一直维护和演进下去。所以 SOFA 的内部版本就是在开源版本之上扩展了内部逻辑和历史版本的兼容逻辑。开源版本的核心逻辑，内外是一致的，并在蚂蚁金服的生产环境中被广泛使用，同时会随着蚂蚁金服自身业务诉求的驱动不断的演进。”杨冰补充道，“但这是值得的，在为开源代码做改进时，也是为公司自己的业务做改进，这是双赢且可持续发展的。”\n很多公司在初涉开源时，常常有疑虑，将核心技术开放出去，会不会导致竞争对手的技术提升，会不会造成更大的技术竞争压力？\n“事实上，我们在最初准备开源时，也有讨论过这个方面。技术要被更多人用、更多场景用，才会有发展。而开放的技术才能带来团队的发展，因为技术是动态发展的，作为开源的一方，事实上在技术上是相对领先的。开源和掌握是两码事，掌握和用好又是两码事，所以，因开源而带来的竞争，其实是助推整个开源体系的发展的，是良性的、有益的。”杨冰说，“而从社区和行业现状看，大家都在开放，封闭的技术体系会逐渐落后。只有开放才能求同存异，共同发展。”\n 花絮\n我问蚂蚁金服的朋友，在你们开源中有什么有趣的“段子”吗？可以讲来听听。\n我朋友过了几天后，给我发来了这样一段文字：\n“参与双十一的中间件团队的常态是什么呢？\n当晚，团队的常态大概就是喝着茶等零点高峰，高峰期过了之后，当然就是参与买买买啦。 我们很多的一些事情的初始想法都是来自于双十一当天的夜聊，似乎在经历了紧张的零点高峰之后，脑细胞特别活跃。\n对于基础设施团队来说，双十一算是一次大考的结束，考完成绩出来了，我们就想琢磨一些有挑战的事情，于是我们会天马行空地聊一聊对于下一年在技术上需要去做的事情。而在 2017 年的双十一当天，SOFA 的几个同学就围在一起聊了 SOFA 能不能开源？为什么要开源？开源和商业化之间的关系？开源后要做哪些事情等等，这个算是 SOFA 开源的第一次内部讨论。\n从这次内部讨论之后，经过了大约半年的准备时间，我们在 2018 年 4 月份正式宣布开源并一直在逐步开源的进程中。”\n他说，这就是他们憋了半天想出来的“段子”，哈哈哈，这群可爱的技术人啊。\n SOFA 的演进和开源之路 SOFA 中间件框架是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\nSOFA 开源全景图，涵盖了微服务领域的各个方面，同时也积极和业界流行的开源组件结合，包括阿里巴巴集团开源的Nacos、Sentinel等，为用户提供更加广泛地选择。\nSOFA 作为一个演进了几年的框架，也一定程度上代表了蚂蚁金服的技术体系的演变，并且现在形成了开源核心、开放式（组件式）开源的模式。SOFA 从 2018 年开始开源，但是我比较好奇 SOFA 开源之前的发展旅程是怎样的。\n杨冰说，“最早的时候，在蚂蚁金服还没有从淘宝分拆出来时，公司内使用过一个 …","date":1552287600,"description":"我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。","dir":"blog/financial-technology-meet-open-source/","fuzzywordcount":6200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"620bf66a94dd1d8b872cb4cb90ca3028","permalink":"https://sofastack.github.io/sofastack.tech/blog/financial-technology-meet-open-source/","publishdate":"2019-03-11T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/financial-technology-meet-open-source/","summary":"我们选择将 SOFA 中间件框架逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\u0026ndas","tags":["SOFAStack"],"title":"蚂蚁金服总监杨冰：金融科技公司为什么要拥抱开源？ | 穿山甲专访","type":"blog","url":"/sofastack.tech/blog/financial-technology-meet-open-source/","wordcount":6192},{"author":"潘潘","categories":"SOFAMeetup","content":" 概要 活动主题：SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布 活动时间：3 月 24 日周日下午 13 点 活动地点：北京中关村创业大街 氪空间 活动形式：线下活动 活动视频回顾：https://tech.antfin.com/community/activities/382 活动介绍 蚂蚁金服 SOFAStack SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，历经蚂蚁金服超过十年的业务历练。SOFAStack 于 2018 年 4 月宣布开源，并逐步开源 SOFABoot、SOFARPC、SOFALookout、SOFATracer、SOFAMosn、SOFAMesh 等组件。 欢迎 Star 我：https://github.com/alipay\nSOFA Meetup#1 北京站-服务注册中心、分布式事务重磅发布 这次的 Meetup 是 SOFAStack 第一场线下活动，也是 SOFA 开源一周年的线下庆祝会。\n我们将带来重磅发布，继续补充 SOFAStack 的开源大图，届时除了 SOFA 团队的见面交流之外，也安排了周年的庆祝环节，期待与朋友们的见面。\n重磅发布：开源蚂蚁金服分布式事务 蚂蚁金服内部的分布式事务框架已经发展十多年，广泛用于解决各类复杂业务场景的数据一致性问题，同时经受大规模业务挑战，在高性能、高可用等方面也积累了丰富的实践经验。\n这次，将带来蚂蚁金服分布式事务十多年的技术总结分享，同时也会宣布开源版本。\n重磅发布：开源蚂蚁金服注册中心 SOFARegistry SOFARegistry 是蚂蚁金服开源的服务注册中心。\nSOFARegistry： https://github.com/alipay/sofa-registry\nSOFARegistry 最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。目前 SOFARegistry 不仅全面应用于蚂蚁金服的自有业务，还随着蚂蚁金融科技输出，助力广大合作伙伴，同时也兼容开源生态。SOFARegistry 最新一代内部版与商业版，均以开源版为基础内核，在其上开发内部特性插件。\n更多内容，到现场来看\n加入 SOFA 钉钉互动群 群号：23127468，使用钉钉搜索群号即可加入，获取一手开源技术干货。\n议程 时间 环节 嘉宾介绍 13:00 - 13:30  签到 13:40 - 14:20  《SOFAStack 开源这一年》 蚂蚁金服技术总监 杨冰 14:20 - 15:00 《SOFARegistry \u0026amp;ndash; 蚂蚁金服高性能服务注册中心开源》 蚂蚁金服服务注册中心开源负责人 尚彧 15:00 - 15:20 庆祝一周年环节 15:20 - 16:00  《SOFAFescar \u0026amp;ndash; 蚂蚁金服分布式事务开源以及实践》 蚂蚁金服分布式事务开源负责人 绍辉 16:00 - 16:40 《SOFAJRaft \u0026amp;ndash; 蚂蚁金服基于 RAFT 一致性算法的生产级高性能 Java 实现》 蚂蚁金服 SOFAJRaft 核心成员 力鲲 16:40 - 17:00  互动交流 ","date":1552277400,"description":"SOFA Meetup#1 北京站，3 月 24 日周日下午 13 点，北京中关村创业大街氪空间。","dir":"activities/sofa-meetup-1/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dd713adb17a610bef8a0f6ed06cace55","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-1/","publishdate":"2019-03-11T12:10:00+08:00","readingtime":3,"relpermalink":"/sofastack.tech/activities/sofa-meetup-1/","summary":"概要 活动主题：SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布 活动时间：3 月 24 日周日下午 13 点 活动地点：北京中关村创业大街 氪空间 活动形式：","tags":["SOFAMeetup","SOFAStack"],"title":"SOFA Meetup#1 北京站——服务注册中心、分布式事务重磅发布","type":"activities","url":"/sofastack.tech/activities/sofa-meetup-1/","wordcount":1037},{"author":"SOFA 团队","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFA 文档: http://www.sofastack.tech/ SOFA: https://github.com/alipay\n 最新的 SOFARPC 5.5.1 已经发布啦，本文给大家介绍下 SOFARPC v5.5.x 系列主要提供的特性以及使用方式。\nSOFARPC 作为成熟的 RPC 框架，一直致力于给用户提供稳定可靠的 RPC 框架 以及最自主的选择权。SOFARPC 的插件扩展机制可以支持各类实现的可插拔实现。\nSOFARPC 5.5 主要给开发者们带来了服务发现的新选择：Nacos 的集成 与 服务容错对 Hystrix 的集成。\n服务注册 Nacos 新选择 Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。根据 Nacos 的 Roadmap，0.8.0 已具备生产使用的能力，截止笔者撰稿时间，Nacos 已发布 0.9.0，距离 1.0.0 越来越近了。\nSOFARPC 5.5.0 开始提供对 Nacos 的集成，以下介绍两种使用方式：\n1、SOFABoot 集成 Nacos SOFABoot 从 2.5.3 开始已集成 SOFARPC 对 Nacos 的配置支持，假如开发者本机已经根据 Nacos 快速开始安装并启动 Nacos Server。\n根据 RPC 的示例工程创建一个 SOFABoot 工程，SOFABoot 工程使用 2.5.3。\n$ git clone git@github.com:alipay/sofa-rpc-boot-projects.git $ git checkout 5.x 在 application.properties 中配置服务注册中心地址信息，就能够使用 Nacos 作为注册中心。\n$ vi sofa-boot-samples/src/main/resources/application.properties com.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 启动 RPC 服务端实例工程：\nrun com.alipay.sofa.rpc.samples.invoke.InvokeServerApplication 启动成功后即可在 Nacos 服务端看到服务注册信息：Nacos 服务列表 （注：如果用户自己部署了nacos 的服务端，可以通过这个地址访问）\n启动 RPC 客户端调用工程：\nrun com.alipay.sofa.rpc.samples.invoke.InvokeClientApplication 可以看到调用成功结果，分别代表同步、异步、回调调用成功：\nsync future callback client process:callback 2、SOFARPC 独立集成 Nacos SOFARPC 独立使用集成 Nacos 也很简单，只需要将注册中心地址设置为 Nacos 服务地址即可。\n引入 SOFARPC：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; API 方式发布服务：\n# 构造服务注册中心配置 RegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;nacos\u0026amp;quot;) .setSubscribe(true) .setAddress(\u0026amp;quot;127.0.0.1:8848\u0026amp;quot;) .setRegister(true); # 构造服务端口配置 ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setHost(\u0026amp;quot;0.0.0.0\u0026amp;quot;) .setPort(12200); # 构造服务发布者 ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRef(new HelloServiceImpl()) .setServer(serverConfig) .setRegister(true) .setRegistry(Lists.newArrayList(registryConfig)); providerConfig.export(); 即可发布服务至 Nacos Server。\n服务容错支持 Hystrix 在大规模的分布式系统中，一个完整的请求链路会跨越多个服务，其中每一个节点出现故障都将放大到全局，轻则造成执行逻辑崩溃，重则消耗掉所有资源拖垮整个系统。\nHystrix 是 Netflix 开源的容错组件，提供以下功能以解决该问题：\n 通过线程池或是信号量对资源进行隔离，避免依赖服务在故障时使用大量资源拖垮整个应用 使用熔断器模式（Circuit Breaker pattern）实现请求故障服务的快速失败（fail-fast），避免故障服务所造成的延时影响整体请求的延时 提供故障降级（Fallback）使用户可以编写优雅降级的策略，防止故障传递到上层 提供准实时的监控指标，使每一个依赖服务的请求结果和延时可观测 在 SOFARPC 中使用 Hystrix Hystrix 本身使用命令模式（Command pattern）实现了 API，我们在 SOFARPC 中对其进行了封装，只需要简单配置即可开启相关功能。\nHystrix 作为 SOFARPC 的可选模块默认不会进行加载，所以首先需要显式在项目中添加 Hystrix 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后通过开关选择开启全局的 Hystrix 支持，或是只对一部分 Consumer 开启：\n// 全局开启 RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // …","date":1551769200,"description":"最新的 SOFARPC 5.5.1 已经发布啦，本文给大家介绍下 SOFARPC v5.5.x 系列主要提供的特性以及使用方式。","dir":"blog/sofarpc-5.5.x-nacos-hystrix/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c712254801354ae1b1bd22cd39b80ec2","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","publishdate":"2019-03-05T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFA 文档: http://www.sofastack.tech/ SOFA: https://github.com/alipay","tags":["SOFARPC"],"title":"SOFARPC 5.5.X 新版发布 | 集成 Nacos 与 Hystrix","type":"blog","url":"/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/","wordcount":2473},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo） 活动时间：2 月 28 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 SOFA:Channel/，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\nSOFA:Channel/ 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n本期 SOFAChannel 为 SOFARPC 专场，分为上下两篇，将采用内容分享与 Demo 实际操作结合的形式进行。\n本期为上篇，下篇将在 2 月 28 日开展，记得关注哟~\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 时间：2019-02-21 19:00-20:00 《SOFARPC 性能优化（上）—— 详解优化设计点》 蚂蚁金服 SOFA 团队 碧远 在业务规模大并发极高的情况下，RPC 对性能的追求就变得极为重要，任何一点小的优化都会累积提高业务整体性能。 本期手把手带你解读： 自定义通信协议使用有哪些注意细节？ SOFARPC 如何进行连接保持？ 在 IO 线程池中批量解包带来的性能提升有哪些？\n嘉宾 蚂蚁金服 SOFA 团队 碧远\n","date":1551349200,"description":"本次为下半场，2 月 28 日晚 7 点，线上直播。","dir":"activities/sofa-channel-3/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"202f32cfe0c8a1c3aacbf435389a956f","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-3/","publishdate":"2019-02-28T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-3/","summary":"概要 活动主题：SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo） 活动时间：2 月 28 日周四晚 7 点 活动形","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#3：SOFARPC 性能优化（下）—— 手把手带你性能调优（含 Demo）","type":"activities","url":"/sofastack.tech/activities/sofa-channel-3/","wordcount":477},{"author":"碧远","categories":"SOFARPC","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第三期，SOFARPC 性能优化（下），进一步分享 SOFARPC 在性能上做的一些优化。 本期你将收获：\n 如何控制序列化和反序列化的时机； 如何通过线程池隔离，避免部分接口对整体性能的影响； 如何进行客户端权重调节，优化启动期和故障时的性能； 服务端 Server Fail Fast 支持，减少无效操作； 在 Netty 内存操作中，如何优化内存使用。 欢迎加入直播互动钉钉群：23127468，不错过每场直播。\n 大家好，今天是 SOFAChannel 第三期，欢迎大家观看。\n我是来自蚂蚁金服中间件的雷志远，花名碧远，目前负责 SOFARPC 框架的相关工作。在上一期直播中，给大家介绍了 SOFARPC 性能优化方面的关于自定义协议、Netty 参数优化、动态代理等的优化。\n 往期的直播回顾，可以在文末获取。\n本期互动中奖名单： @司马懿 @邓从宝 @雾渊，请文章下方回复进行礼品领取\n 今天我们会从序列化控制、内存操作优化、线程池隔离等方面来介绍剩余的部分。\n序列化优化 上次介绍了序列化方式的选择，这次主要介绍序列化和反序列化的时机、处理的位置以及这样的好处，如避免占用 IO 线程，影响 IO 性能等。\n上一节，我们介绍的 BOLT 协议的设计，回顾一下：\n可以看到有这三个地方不是通过原生类型直接写的：ClassName，Header，Content 。其余的，例如 RequestId 是直接写的，或者说跟具体请求对象无关的。所以在选择序列化和反序列化时机的时候，我们根据自己的需求，也精确的控制了协议以上三个部分的时机。\n对于序列化 serializeClazz 是最简单的：\nbyte[] clz = this.requestClass.getBytes(Configs.DEFAULT_CHARSET); 直接将字符串转换成 Byte 数组即可，跟具体的任何序列化方式，比如跟采用 Hessian 还是 Pb 都是无关的。\nserializeHeader 则是序列化 HeaderMap。这时候因为有了前面的 requestClass，就可以根据这个名字拿到SOFARPC 层或者用户自己注册的序列化器。然后进行序列化 Header，这个对应 SOFARPC 框架中的 SofaRpcSerialization 类。在这个类里，我们可以自由使用本次传输的对象，将一些必要信息提取到Header 中，并进行对应的编码。这里也不跟具体的序列化方式有关，是一个简单 Map 的序列化，写 key、写 value、写分隔符。有兴趣的同学可以直接看源码。\n源码链接：https://github.com/alipay/sofa-bolt/blob/531d1c0d872553d92fc55775565b3f7be8661afa/src/main/java/com/alipay/remoting/rpc/protocol/RpcRequestCommand.java#L66\nserializeContent 序列化业务对象的信息，这里 RPC 框架会根据本次用户配置的信息决定如何操作序列化对象，是调用 Hessian 还是调用 Pb 来序列化。\n至此，完成了序列化过程。可以看到，这些操作实际上都是在业务发起的线程里面的，在请求发送阶段，也就是在调用 Netty 的写接口之前，跟 IO 线程池还没什么关系，所以都会在业务线程里先做好序列化。\n对于反序列化 介绍完序列化，反序列化的时机就有一些差异，需要重点考虑。在服务端的请求接收阶段，我们有 IO 线程、业务线程两种线程池。为了最大程度的配合业务特性、保证整体吞吐，SOFABolt 设计了精细的开关来控制反序列化时机。\n具体选择逻辑如下：\n体现在代码的这个类中。\ncom.alipay.remoting.rpc.protocol.RpcRequestProcessor#process 从上图可以看到 反序列化 大致分成以下三种情况，适用于不同的场景。\n IO 线程池动作 业务线程池 使用场景 反序列化 ClassName 反序列化 Header 和 Content 处理业务 一般 RPC 默认场景。IO 线程池识别出来当前是哪个类，调用用户注册的对应处理器 反序列化 ClassName 和 Header 仅反序列化 Content 和业务处理 希望根据 Header 中的信息，选择线程池，而不是直接注册的线程池 一次性反序列化 ClassName、Header 和 Content，并直接处理 没有逻辑 IO 密集型的业务 线程池隔离 经过前面的介绍，可以了解到，由于业务逻辑通常情况下在 SOFARPC 设置的一个默认线程池里面处理，这个线程池是公用的。也就是说， 对于一个应用，当他作为服务端时，所有的调用请求都会在这个线程池中处理。\n举个例子：如果应用 A 对外提供两个接口，S1 和 S2，由于 S2 接口的性能不足，可能是下游系统的拖累，会导致这个默认线程池一直被占用，无法空闲出来被其他请求使用。这会导致 S1 的处理能力受到影响，对外报错，线程池已满，导致整个业务链路不稳定，有时候 S1 的重要性可能比 S2 更高。\n因此，基于上面的设计，SOFARPC 框架允许在序列化的时候，根据用户对当前接口的线程池配置将接口和服务信息放到 Header 中，反序列化的时候，根据这个 Header 信息选择到用户自定义的线程池。这样，用户可以针对不同的服务接口配置不同的业务线程池，可以避免部分接口对整个性能的影响。在系统接口较多的时候，可以有效的提高整体的性能。\n内存操作优化 介绍完线程池隔离之后，我们介绍一下 Netty 内存操作的一些注意事项。在 Netty 内存操作中，如何尽量少的使用内存和避免垃圾回收，来优化性能。先看一些基础概念。\n内存基础 在 JVM 中内存可分为两大块，一个是堆内存，一个是直接内存。\n堆内存是 JVM 所管理的内存。所有的对象实例都要在堆上分配，垃圾收集器可以在堆上回收垃圾，有不同的运行条件和回收区域。\nJVM 使用 Native 函数在堆外分配内存。为什么要在堆外分配内存？主要因为在堆上的话， IO 操作会涉及到频繁的内存分配和销毁，这会导致 GC 频繁，对性能会有比较大的影响。\n注意：直接分配本身也并不见得性能有多好，所以还要有池的概念，减少频繁的分配。\n因此 JVM 中的直接内存，存在堆内存中的其实就是 DirectByteBuffer 类，它本身其实很小，真的内存是在堆外，通过 JVM 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。直接内存不会受到 Java 堆的限制，只受本机内存影响。当然可以设置最大大小。也并不是 Direct 就完全跟 Heap 没什么关系了，因为堆中的这个对象持有了堆外的地址，只有这个对象被回收了，直接内存才能释放。\n其中 DirectByteBuffer 经过几次 young gc 之后，会进入老年代。当老年代满了之后，会触发 Full GC。\n因为本身很小， …","date":1551337200,"description":"本文根据 SOFAChannel#3 直播分享整理，进一步分享 SOFARPC 在性能上做的一些优化。","dir":"blog/sofa-channel-3-retrospect/","fuzzywordcount":5800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7a816fa5f942ce857c10ebb1c416482d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-3-retrospect/","publishdate":"2019-02-28T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-channel-3-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第三期，SOFARPC 性能优化（下），进一步分享 SOFARPC 在性能上做的一些优化。 本期你","tags":["SOFARPC","SOFAChannel"],"title":"SOFARPC 性能优化实践（下）| SOFAChannel#3 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-3-retrospect/","wordcount":5775},{"author":"心贵","categories":"Kubernetes","content":" 此文章适合没有任何 Kubernetes/容器/Docker 经验的同学 — 在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。此文章阅读耗时大概 15 分钟。\n 蚂蚁金服资源调度组致力于将 Kubernetes 落地到世界上最有价值的金融科技独角兽公司，欢迎联系作者微信： answer1991chen 咨询招聘事宜。\n文章 Markdown 源码位于 https://github.com/answer1991/articles/blob/master/Kubernetes-is-the-next-generation-os.md ，遵从 Apache License 2.0 开源协议。\n导言 此文章着重介绍如何在入门阶段使用 Kubernetes，以及要面向 Kubernetes 编程带来的优势，不会介绍复杂的 Kubernetes 架构、实现。因此此文章适合没有任何 Kubernetes/容器/Docker 经验的同学，对 Kubernetes 有了解的同学也可以从此文章里面获取一些灵感，可以更加酷炫的玩转 Kubernetes。\n希望在阅读完此文章之后，你可以从 “我需要一个 Linux VM 做开发、测试和部署”，变成 “我需要一个 Kubernetes 做开发、测试和部署”。\nKubernetes 是下一代操作系统 Kubernetes 是这几年非常热门的一个词汇，大概所有的软件工程师都已经听说过这个词。\n那么 Kubernetes 到底是什么呢？可能 Google 会告诉你很多，但是我想告诉你的是：Kubernetes 是下一代操作系统；一个 Kubernetes 集群是一个资源无限大(可扩容)的虚拟机。而且，Kubernetes 的接口是是声明式的，是天然面向分布式系统而设计的（下面会详细介绍）。\n说到这里，大家估计立刻就有疑问了。我想大概是这些：\nQ: 那么，Linux、Windows 要被淘汰了？\nA: 不会被淘汰，只是 Linux、Windows 是一个底层的单机操作系统。而我们这些普通的应用软件工程师将来都不会跟Linux 打交道了，都会使用 Kubernetes 这个更上层、同时功能也更强大的操作系统。\nQ: 那么，我不学 Kubernetes 可以吗？\nA: 不行！在未来不久的某一天，也许云厂商只卖 Kubernetes “虚拟机”了：阿里云不单独卖 ecs 了，亚马逊AWS，微软云，Google 云等各种云厂商都不卖 Linux 虚拟机了。如果你想买单机版的 Linux 虚拟机，他们都会一脸惊讶的问你，你买那么底层的、功能那么薄弱的计算机干什么？就像你现在从云厂商那里买不到一个还没有安装 Linux 的虚拟机一样。以后，云厂商交付的 “虚拟机” 必定是 “集群级别的虚拟机” ，而 “集群级别的虚拟机” 的操作系统就是 Kubernetes。\n在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。\nQ: 那这样的话，我买不到 Linux 虚拟机，我连学习 Linux 的机会都没有了？\nA: 当然不是，有了 Kubernetes，你可以在 1秒内自己搞一个任何 Linux 发行版本的 “单机虚拟机” 出来。\nQ: Kubernetes 真的是一个操作系统？ Show me\u0026amp;hellip;.\nA:\n 功能/名词 单机 Linux Kubernetes 说明 Shell, CMD sh, bash kubectl kubectl 是 Kubernetes 的 shell 工具，有了 kubectl 你就可以连接并管理 Kubernetes 这个超级虚拟机了。 用户，登录 Linux User, Group, ssh 登录 kubeconfig 文件类似 Linux ssh 的 .key 文件，用户使用 kubeconfig 访问 Kubernetes 就自带了用户信息。Kubernetes 能根据用户限制权限，也能限制用户能使用的资源。kubectl 使用 kubeconfig 访问 Kubernetes 就好比使用 .ssh key 访问 Linux Kubernetes 集群管理员(或者自动化的申请系统)为用户颁发 kubeconfig 文件。 进程 进程 Pod Pod 就是 Kubernetes 这个 “超级虚拟机” 的进程。 管理进程 ps, kill kubectl get po, kubectl delete pod 发布、升级、管理 “进程”(或者说应用) 配置管理 登录各个 Linux VM，替换机器上的文件。 kubectl apply -f ./cm.yaml 使用 ConfigMap 管理应用的配置文件，一次提交，进程的每个实例自动生效新的配置。由于篇幅管理，使用 ConfigMap 配置应用（“进程”）启动参数不在此文章里面举例。 发布、管理、升级应用 在 Linux 上面发布一个应用，需要一顿疯狂的操作：先阅读如何发布、参数有什么、下载二进制包、搞定一些配置文件，然后运行应用。 kubectl apply -f ./my-app.yaml my-app.yaml 可能是应用提供商提供的、面向 Kubernetes 发布应用的“菜单”文件(为什么叫“菜单”我后面会介绍)。只要提交这个“菜单”，应用就部署好了。Kubernetes 让一切简单，而且，它是分布式，是天然容灾的。只要向 Kubernetes 提交 Deployment 这样的“资源”即可，下文有介绍。 限制应用资源 一顿疯狂的操作，把应用进程的 Cgroup 限制好。 发布应用时已经做了 Kubernetes 让一切简单。 分布式应用发布 在各个 Linux 虚拟机上面发布好应用，然后把他们组网。 发布应用时已经做了 还是那句话，Kubernetes 让一切简单。 分布式应用容灾 搞个监控，监控我们各个 Linux 虚拟机上面的应用是不是不健康了。不健康了的话，我们起床，来一次“一顿操作猛如虎”的故障恢复操作。 / 天然容灾，安心睡你的觉。 数据持久化，故障时数据迁移 “一顿操作猛如虎” 用 PV（持久化存储卷），容灾把应用的一个应用实例从 “节点一” 切换到了 “节点二”，都不用做任何数据迁移。新的应用实例起来就能使用老数据。 还是那句话，Kubernetes 让一切简单。我都不用关心这个事情。（由于篇幅管理，下文的例子中也不会涉及 PV 的例子） “一顿操作猛如虎” 听起来很酷，但是你在做一些没必要的事情，同时你做了这些事情并不讨好你的老板，可能在因为你的失误操作引起更大的故障和问题。\n面向 Kubernetes 做最简单的操作，达到最佳的效果，才是更酷的事情。\nA: 行了行了，别说那么多了，我还是需要一个 Linux VM。\nQ: 好的，我给您一个 Kubernetes，然后给你一个 基础 OS Pod “菜单”文件，然后您自己就可以创建任何一个 Linux 发行版、任何一个 Linux 版本的的 Linux VM …","date":1551078000,"description":"希望在阅读完此文章之后，你可以从 “我需要一个 Linux VM 做开发、测试和部署”，变成 “我需要一个 Kubernetes 做开发、测试和部署”。","dir":"blog/kubernetes-the-next-gen-os/","fuzzywordcount":8600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"09e6dbd10bffdeea13865fc45e3b3ee5","permalink":"https://sofastack.github.io/sofastack.tech/blog/kubernetes-the-next-gen-os/","publishdate":"2019-02-25T15:00:00+08:00","readingtime":18,"relpermalink":"/sofastack.tech/blog/kubernetes-the-next-gen-os/","summary":"此文章适合没有任何 Kubernetes/容器/Docker 经验的同学 — 在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。","tags":["Kubernetes"],"title":"Kubernetes 是下一代操作系统 | 面向 Kubernetes 编程","type":"blog","url":"/sofastack.tech/blog/kubernetes-the-next-gen-os/","wordcount":8595},{"author":"碧远","categories":"SOFARPC","content":" SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第二期，主要分享 SOFARPC 在性能上做的一些优化，这个系列会分成上下两部分进行分享，今天是 SOFARPC 性能优化（上），也会对本次分享中的一些结论，提供部分代码 Demo，供大家了解验证。 欢迎加入直播互动钉钉群：23127468，不错过我们每场直播。\n 大家好，今天是我们 SOFAChannel 第二期。欢迎大家观看。\n我是来自蚂蚁金服中间件的雷志远，花名碧远，目前在负责 SOFARPC 框架相关工作。\n去年的时候，我们和外部的爱好者们一起，做了一个基于 SOFARPC 的源码解析系列，我同事已经发到群里了，大家可以保存，直播之后查看。\nSOFARPC 源码解析系列：（点击【剖析 | SOFARPC 框架】即可查看）\nhttps://www.sofastack.tech/blog/ 今年，基于源码解析的基础，我们来多讲讲实践，如何应用到大家的业务，来帮助大家解决实际问题。在直播过程中有相关的问题想提问，可以在钉钉群互动。\n前言 在上一期中，余淮分享了《从蚂蚁金服微服务实践谈起》。介绍了蚂蚁微服务的起源，以及之后服务化，单元化的情况。同时介绍了 SOFAStack 目前开源的情况。最后也分享了一下整个微服务中 SOFARPC 的设计与实现。\n本期，我们主要分享 SOFARPC 在性能上做的一些优化。这个系列会分成上下两部分进行分享，今天是 SOFARPC 性能优化（上），也会对本次分享中的一些结论，提供部分代码 Demo，供大家了解验证。\n我们先简要介绍一下 SOFARPC 的框架分层。这个在上次的分享中已经进行了介绍。\n下层是网络传输层，依次是协议，序列化，服务发现和 Filter 等。\nTransport 主要负责数据传输，可以是 Http2Transport，也可以是 BoltTransport，还有可能是其他。\nProtocol 层是协议，是 Rest 还是 Bolt ，或者是 Dubbo 。\nSerialization 是序列化，对于每种协议，可以是用不同的序列化方式，比如 hessian，pb，json 等。\nFilter 是通用的过滤器层，主要是为了留出一些扩展，完成一些其他扩展功能，比如 Tracer 的埋点等。\nRouter 是路由层，主要是做寻址，这里可能是 Zk，也可能是 LVS，也可能是直连。Cluster 是客户端集群方式的表示。\n自定义通讯协议使用 首先我想介绍一下自定义通讯协议。\n在说明自定义通讯协议之前，我先简单介绍一下通讯协议。在TCP之上，RPC框架通常还需要将请求和响应数据进行一定的封装，组装成 Packet，然后发送出去。这样，服务端收到之后，才能正确识别整个 TCP 发过来的字节流中，哪一部分是我们可以进行处理的一个完整单位。反之，客户端收到服务端的TCP 数据流也是如此。\n有了上面的共识之后，我们要回答下面两个问题：\n 为什么要自定义，不使用 Http2/Dubbo/Rest/Grpc？ 自定义之后，带来了什么好处呢？ Http2 虽然更为通用，但是一方面，出现较晚，迁移转换成本高，并且通用则意味着传输的辅助数据会变多，会有一些额外的信息需要传递或者判断。对于序列化反序列化的控制上，也不是很好扩展操作。\n而 Dubbo，协议简单强大。但是一些元信息需要解析，Header 中传输的数据太少，很多都需要依赖 body 中的数据反序列化完成后才能使用，头部的信息太少。\n而使用了自研的协议之后，Header 中可自定义传输更多的元信息，序列化方式，Server Fail Fast，服务端线程隔离等也都成为可能。甚至蚂蚁在 ServiceMesh 的场景下，Mesh 本身也能利用 Bolt 的协议，进行部分数据的读取，而不依赖具体的序列化实现。\n经过我们的实践，大致来看，目前给我们带来的好处主要有以下的能力：\n Server Fast 的支持 Header 和 Body 的分开序列化 Crc 校验的支持 版本的支持，预防未来可能出现的更好的设计方案 多种序列化方式的支持 安全认证，Mesh 路由 如果你要自己设计一个通讯协议。可以考虑使用 BOLT 协议，或者参考进行更好的设计和优化。\n关于 SOFABolt 相关的源码解析，也可以通过这个系列来了解。\nSOFABolt 源码解析系列：点击【剖析 | SOFABOLT 框架】即可查看） https://www.sofastack.tech/blog Netty 性能参数优化 在介绍了自定义通讯协议之后，也就是确定好了怎么封包解包之后，还需要确定传输层的开发。一个 RPC 框架从现在的情况来看，一般不太可能完全基于 JAVA 的 NIO 或者其他 IO 进行直接的开发，主要是一些 NIO 原生的问题和使用难度，而成熟的，目前可选的不多。基本上，大家都会基于 Netty 进行开发，HSF/Dubbo/Motan 等都是这样。\n直接使用是比较简单的。在 Netty 的 Bootstrap 的设置中，有一些可选的优化项，有必要跟大家分享一下。\n1. SO_REUSEPORT/SO_REUSEADDR - 端口复用(允许多个 socket 监听同一个IP+端口)\nSO_REUSEPORT 支持多个进程或者线程绑定到同一端口，提高服务器的接收链接的并发能力，由内核层面实现对端口数据的分发的负载均衡，在服务器 socket 上没有了锁的竞争。\n同时 SO_REUSEADDR也要打开，这样针对 time-wait 链接 ，可以确保 server 重启成功。在一些服务端启动很快的情况下，可以防止启动失败。\n2. TCP_FASTOPEN - 3次握手时也用来交换数据\n三次握手的过程中，当用户首次访问服务端时，发送 syn 包，server 根据客户端 IP 生成 cookie ，并与 syn+ack 一同发回客户端；客户端再次访问服务端时，在 syn 包携带 TCP cookie；如果服务端校验合法，则在用户回复 ack 前就可以直接发送数据；否则按照正常三次握手进行。也就是说，如果客户端中途断开，再建联的时候，会同时发送数据，会有一定的性能提升。\nTFO 提高性能的关键是省去了热请求的三次握手，这在小对象传输较多的移动应用场景中，能够极大提升性能。\nNetty 中仅在 Epoll 的时候可用 Linux特性，不能在 Mac/Windows 上使用，SOFARPC 未开启。\n3. TCP_NODELAY-关闭 (纳格) Nagle 算法，再小的包也发送，而不是等待\nTCP/IP 协议中针对 TCP 默认开启了 Nagle 算法。Nagle 算法通过减少需要传输的数据包个数，来优化网络。但是现在的环境下，网络带宽足够，需要进行关闭。这样，对于传输数据量小的场景，能很好的提高性能，不至于出现数据包等待。\n4. SO_KEEPALIVE –开启 TCP 层面的 Keep Alive 能力\n这个不多说，开启一下 TCP 层面的 Keep Alive 的能力。\n5. WRITE_BUFFER_WATER_MARK …","date":1551078000,"description":"本文根据 SOFAChannel#2 直播分享整理，主要分享 SOFARPC 在性能上做的一些优化。","dir":"blog/sofa-channel-2-retrospect/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6751c882f7879a7dd9c9f49823410ffc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-2-retrospect/","publishdate":"2019-02-25T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-channel-2-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 本次是 SOFAChannel 第二期，主要分享 SOFARPC 在性能上做的一些优化，这个系列会分成上下两部分进行分享，今天","tags":["SOFARPC","SOFAChannel"],"title":"SOFARPC 性能优化实践（上）| SOFAChannel#2 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-2-retrospect/","wordcount":5077},{"author":"花肉","categories":"SOFAChannel","content":" 概要 活动主题：SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 活动时间：2 月 21 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 SOFA:Channel/，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\nSOFA:Channel/ 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n本期 SOFAChannel 为 SOFARPC 专场，分为上下两篇，将采用内容分享与 Demo 实际操作结合的形式进行。\n本期为上篇，下篇将在 2 月 28 日开展，记得关注哟~\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 时间：2019-02-21 19:00-20:00 《SOFARPC 性能优化（上）—— 详解优化设计点》 蚂蚁金服 SOFA 团队 碧远 在业务规模大并发极高的情况下，RPC 对性能的追求就变得极为重要，任何一点小的优化都会累积提高业务整体性能。 本期手把手带你解读： 自定义通信协议使用有哪些注意细节？ SOFARPC 如何进行连接保持？ 在 IO 线程池中批量解包带来的性能提升有哪些？\n嘉宾 蚂蚁金服 SOFA 团队 碧远\n","date":1550744400,"description":"本次为上半场，2 月 21 日晚 7 点，线上直播。","dir":"activities/sofa-channel-2/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3140990819c0601c041bf5091405220b","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-2/","publishdate":"2019-02-21T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-2/","summary":"概要 活动主题：SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点 活动时间：2 月 21 日周四晚 7 点 活动形式：线上直播 直播视","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#2：SOFARPC 性能优化（上）—— 详解优化设计点","type":"activities","url":"/sofastack.tech/activities/sofa-channel-2/","wordcount":468},{"author":"卫恒","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n本文为《剖析 | SOFATracer 框架》第一篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\n 0、前言 在单体应用时代，我们不需要花费时间去关心调用链路这个东西。但是链路跟踪不仅仅是在分布式场景下才会有，即使是单体应用，同样也会存在调用链路。例如，我们把应用中的每个服务接口作为一个链路节点，那么从请求进来到返回响应，把这个过程中多历经的所有的方法接口串联起来，就能组成一条完整的链路，如下图所示：\n对于单体应用而言，如果访问一个资源没有成功，那么我们可以很快的锁定是哪一台机器，然后通过查询这台机器上的日志就能定位问题。\n但是在微服务体系架构下，这种方式会显得非常无力。对于一个稍具规模的应用来说，一次请求可能会跨越相当多的服务节点，在这种情况下，如果一个请求没有得到成功的响应，就不能确定到底是哪个节点出了问题。\n因此在面对这种复杂的大规模分布式集群来实现的服务体系来说，就需要一些可以帮助理解各个应用的线上调用行为、并可以分析远程调用的组件。\n基于上述背景，蚂蚁金服开源了基于 OpenTracing 规范实现的 SOFATracer 分布式链路跟踪组件，为实施大规模服务化体系架构场景下提供了链路跟踪的解决方案。\n在介绍 SOFATracer 之前，先来了解一下 Opentracing 规范。\n1、Opentracing 简介 首先来解释下 OpenTracing 是什么OpenTracing 致力于为分布式跟踪创建更标准化的API和工具，它由完整的API规范、实现该规范的框架、库以及项目文档组成。\nOpenTracing 提供了一套平台无关、厂商无关的 API，这样不同的组织或者开发人员就能够更加方便的添加或更换追踪系统的实现。 OpenTracing API 中的一些概念和术语，在不同的语言环境下都是共享的。\n1.1、数据模型 Opentracing 规范中，一条 trace 链路是由多个与之关联的 span 组成，一条链路整体可以看做是一张有向无环图，各个span之间的边缘关系被称之为“References”。下面是官方提供的示例：\n如果已时间轴维度来看的话，也可以表现为下面的形式(官方示例)：\n root span : 当前链路中的第一个 span ChildOf 和 FollowFrom 是目前被定义的两种 References 类型 ChildOf : 父级 span某种程度上取决于子span （子span的结果可能会对父span产生影响） FollowFrom : 父 Span不以任何方式依赖子 Span 但是为了简化 span 之间的这种依赖关系，在具体实现时通常会将具有嵌套关系的作为 ChildOf，平行执行的作为FollowFrom，比如：\na、ChildOf 示例\n在 methodA 中调用了 method B :\nmethodA(){ // spanA start methodB(); } // spanA finish methodB(){ // spanB start } // spanB finish 产生的 span在时间维度上展现的视角如下：\n这种关系一般会 表示为 SpanB ChildOf SpanA 。\nb、FollowFrom 示例\nmethod 方法中，methodA执行之后 methodB 执行 :\nmethod(){ methodA(); methodB(); } 产生的 span在时间维度上展现的视角如下：\n这种关系一般会 表示为 SpanB FollowFrom SpanA 。\n1.2、API Opentracing API 是对分布式链路中涉及到的一些列操作的高度抽象集合。Opentracing 中将所有核心的组件都声明为接口，例如 Tracer、Span、SpanContext、Format（高版本中还包括 Scope 和 ScopeManager）等。SOFATracer 使用的版本是 0.22.0 ，主要是对 Tracer、Span、SpanContext 三个概念模型的实现。下面就针对这三个组件结合 SOFATracer 来分析。\n1.3、SOFATracer 标准实现 下图为 SOFATracer 中对于这三个核心接口实现的类图结构：\n 由于篇幅原因，下面的介绍过程中一些点不会展开说明，有兴趣的同学可以自行官网查看完整的 OpenTracing-api 规范 （https://opentracing.io/specification/）。\n a、Tracer \u0026amp;amp; SofaTracer\nTracer 是一个简单、广义的接口，它的作用就是构建 span 和传输 span 。核心接口列表如下：\n 接口 描述 SpanBuilder buildSpan(String operationName) 根据指定的operationName构建一个新的span void inject(SpanContext spanContext, Format format, C carrier); 将 spanContext 以 format 的格式注入到 carrier 中 SpanContext extract(Format format, C carrier); 以 format 的格式从carrier中解析出 SpanContext SofaTracer 实现了 Tracer 接口，并扩展了采样、数据上报等能力。\nb、Span \u0026amp;amp; SofaTracerSpan\nSpan 是一个跨度单元，在实际的应用过程中，Span 就是一个完整的数据包，其包含的就是当前节点所需要上报的数据。核心接口列表如下：\n 接口 描述 SpanContext context() 从 span 中获取 SpanContext void finish()/void finish(long finishMicros) 结束一个 span void close() 关闭 span Span setTag(String key, value) 设置 tags Span log(long timestampMicroseconds, String event) 设置 log 事件 Span setOperationName(String operationName) 设 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第一篇。","dir":"blog/sofa-tracer-overview/","fuzzywordcount":4200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ff58d686746c53b81af210eaf17bb154","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-overview/","publishdate":"2019-02-21T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-overview/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-overview/","wordcount":4138},{"author":"卫恒","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第二篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\nSOFATracer：https://github.com/sofastack/sofa-tracer\n 0、前言 在《蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析》一文中已经对 SOFATracer 进行了概要性的介绍。从对 SOFATracer 的定义可以了解到，SOFATracer 作为一个分布式系统调用跟踪的组件，是通过统一的 TraceId 将调用链路中的各种网络调用情况以数据上报的方式记录下来，以达到透视化网络调用的目的。\n本篇将针对SOFATracer的数据上报方式进行详细分析，以帮助大家更好的理解 SOFATracer 在数据上报方面的扩展。\n1、Reporter 整体模型 本节将对 SOFATracer 的 Report 模型进行整体介绍，主要包括两个部分：\n Reporter 的接口设计及实现； 数据上报流程。 1.1、Reporter 的接口设计及实现 数据上报是 SofaTracer 基于 OpenTracing Tracer 接口扩展实现出来的功能；Reporter 实例作为 SofaTracer 的属性存在，在构造 SofaTracer 实例时，会初始化 Reporter 实例。\n1.1.1、Reporter 接口设计 Reporter 接口是 SOFATracer 中对于数据上报的顶层抽象，核心接口方法定义如下：\n//获取 Reporter 实例类型 String getReporterType(); //输出 span void report(SofaTracerSpan span); //关闭输出 span 的能力 void close(); Reporter 接口的设计中除了核心的上报功能外，还提供了获取 Reporter 类型的能力，这个是因为 SOFATracer 目前提供的埋点机制方案需要依赖这个实现。\n1.1.2、Reporter 接口实现 Reporter 的类体系结构如下：\nReporter 的实现类有两个，SofaTracerCompositeDigestReporterImpl 和 DiskReporterImpl ：\n SofaTracerCompositeDigestReporterImpl：组合摘要日志上报实现，上报时会遍历当前 SofaTracerCompositeDigestReporterImpl 中所有的 Reporter ，逐一执行 report 操作；可供外部用户扩展使用。 DiskReporterImpl：数据落磁盘的核心实现类，也是目前 SOFATracer 中默认使用的上报器。 1.2、数据上报流程分析 数据上报实际都是由不同的链路组件发起，关于插件扩展机制及埋点方式不是本篇范畴，就不展开了。这里直接来看数据上报的入口。\n在 Opentracing 规范中提到，Span#finish 方法是 span 生命周期的最后一个执行方法，也就意味着一个 span 跨度即将结束。那么当一个 span 即将结束时，也是当前 span 具有最完整状态的时候。所以在 SOFATracer 中，数据上报的入口就是 Span#finish 方法，这里贴一小段代码：\n//SofaTracerSpan#finish @Override public void finish(long endTime) { this.setEndTime(endTime); //关键记录:report span this.sofaTracer.reportSpan(this); SpanExtensionFactory.logStoppedSpan(this); } 在 finish 方法中，通过 SofaTracer#reportSpan 将当前 span 进行了上报处理。以这个为入口，整个数据上报的调用链路如下图所示：\n整个上报调用流程其实并不是很难，这里留两个问题：\n 如何构造 clientRportor 和 serverReporter 的，依据是什么？ 摘要日志和统计日志是怎么落盘的？ 第一个问题会在插件埋点解析篇中给出答案；第二个问题下面来看。\n2、日志落盘 前面已经提到，SOFATracer 本身提供了两种上报模式，一种是落到磁盘，另外一种是上报到zipkin。在实现细节上，SOFATracer 没有将这两种策略分开以提供独立的功能支持，而是将两种上报方式组合在了一起，然后再通过配置参数来控制是否进行具体的上报逻辑，具体参考下图：\n本节将来剖析下日志落盘的实现细节。日志落盘又分为摘要日志落盘 和 统计日志落盘；摘要日志是每一次调用均会落地磁盘的日志；统计日志是每隔一定时间间隔进行统计输出的日志。\n2.1、摘要日志落盘 摘要日志落盘是基于 Disruptor 高性能无锁循环队列实现的。SOFATracer 中，AsyncCommonDigestAppenderManager 类对 disruptor 进行了封装，用于处理外部组件的 Tracer 摘要日志打印。\n 关于 Disruptor 的原理及其自身的事件模型此处不展开分析，有兴趣的同学可以自行查阅相关资料。这里直接看下 SOFATracer 中是如何使用 Disruptor 的。\n 2.1.1、消息事件模型 SOFATracer 使用了两种不同的事件模型，一种是 SOFATracer 内部使用的 StringEvent，一种是外部扩展使用的SofaTacerSpanEvent。详见：SofaTracerSpanEvent \u0026amp;amp; StringEvent 。\n2.1.2、Consumer 消费者 Consumer 是 AsyncCommonDigestAppenderManager 的内部类；实现了 EventHandler 接口，这个 Consumer 作为消费者存在，监听事件，然后通过 TraceAppender 将 span 数据 flush 到磁盘。详见：AsyncCommonDigestAppenderManager\n2.1.3、Disruptor 的初始化 Disruptor 的构建：在 AsyncCommonDigestAppenderManager 的构造函数中完成的。 //构建disruptor，使用的是 ProducerType.MULTI //等待策略是 BlockingWaitStrategy，考虑到的是CPU的 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第二篇。","dir":"blog/sofa-tracer-response-mechanism/","fuzzywordcount":5100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"350b5d9eacee1bc4b3b604236b247a3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-response-mechanism/","publishdate":"2019-02-21T10:20:00Z","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-tracer-response-mechanism/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服分布式链路跟踪组件 SOFATracer 数据上报机制和源码剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-response-mechanism/","wordcount":5014},{"author":"米麒麟","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第四篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。\nSOFATracer： https://github.com/sofastack/sofa-tracer\n 前言 由于分布式链路追踪涉及到调用的每个环节，而每个环节都会产生大量的数据，为了存储这种数据，可能需要大量的成本，另外在实际的生产过程中并非所有数据都是值得关注的，基于这些原因，SOFATracer 提供链路数据采样功能特性，一方面可以节约 I/O 磁盘空间，另一方面需要把无关数据直接过滤筛选。目前 SOFATracer 内置两种采样策略，一种是基于固定比率的采样，另一种是基于用户扩展实现的自定义采样。自定义采样模式将 SofaTracerSpan 实例作为采样计算的条件，用户可以基于此实现自行扩展自定义的采样规则。\n本篇文章主要介绍 SOFATracer 数据采样策略原理，通过剖析源码实现详细讲述采样规则算法。\nDapper 论文中的采样模型与策略 跟踪采样模型 每个请求都会利用到大量服务器高吞吐量的线上服务，这是对有效跟踪最主要的需求之一。这种情况需要生成大量的跟踪数据，并且他们对性能的影响是最敏感的。延迟和吞吐量带来的损失在把采样率调整到小于1/16之后就能全部在实验误差范围内。\n在实践中，我们发现即便采样率调整到 1\u0026amp;frasl;1024 仍然是有足够量的跟踪数据用来跟踪大量的服务。保持链路跟踪系统的性能损耗基线在一个非常低的水平是很重要的，因为它为那些应用提供了一个宽松的环境使用完整的 Annotation API 而无惧性能损失。使用较低的采样率还有额外好处，可以让持久化到硬盘中的跟踪数据在垃圾回收机制处理之前保留更长时间，这样为链路跟踪系统的收集组件提供更多灵活性。\n分布式链路跟踪系统中任何给定进程的消耗和每个进程单位时间的跟踪采样率成正比。然而，在较低的采样率和较低的传输负载下可能会导致错过重要事件，而想用较高的采样率就需要能接受的相应的性能损耗。我们在部署可变采样的过程中，参数化配置采样率时，不是使用一个统一的采样方案，而是使用一个采样期望率来标识单位时间内采样的追踪。这样一来，低流量低负载会自动提高采样率，而在高流量高负载的情况下会降低采样率，使损耗一直保持在控制之内。实际使用的采样率会随着跟踪本身记录下来，这有利于从跟踪数据里准确分析排查。\n跟踪采样策略 要真正做到应用级别的透明，我们需要把核心跟踪代码做的很轻巧，然后把它植入到那些无所不在的公共组件中，比如线程调用、控制流以及 RPC 库。使用自适应的采样率可以使链路跟踪系统变得可伸缩，并且降低性能损耗。链路跟踪系统的实现要求性能低损耗，尤其在生产环境中不能影响到核心业务的性能，也不可能每次请求都跟踪，所以要进行采样，每个应用和服务可以自己设置采样率。采样率应该是在每个应用自己的配置里设置的，这样每个应用可以动态调整，特别是应用刚上线时可以适当调高采样率。一般在系统峰值流量很大的情况下，只需要采样其中很小一部分请求，例如 1\u0026amp;frasl;1000 的采样率，即分布式跟踪系统只会在 1000 次请求中采样其中的某一次。\n在 Dapper 论文中强调了数据采样的重要性，如果将每条埋点数据都刷新到磁盘上会增大链路追踪框架对原有业务性能的影响。如果采样率太低，可能会导致一些重要数据的丢失。 论文中提到如果在高并发情况下 1\u0026amp;frasl;1024 的采样率是足够的，也不必担心重要事件数据的丢失。因为在高并发环境下，一个异常数据出现一次，那么就会出现1000次。 然而在并发量不是很多的系统，并且对数据极为敏感时需要让业务开发人员手动设置采样率。\n对于高吞吐量服务，积极采样并不妨碍最重要的分析。如果一个显著的操作在系统中出现一次，他就会出现上千次。低吞吐量服务可以负担得起跟踪每一个请求。这是促使我们下决心使用自适应采样率的原因。为了维持物质资源的需求和渐增的吞吐要求之间的灵活性，我们在收集系统自身上增加了额外的采样率支持。\n如果整个跟踪过程和收集系统只使用一个采样率参数确实会简单一些，但是这就不能应对快速调整在所有部署节点上的运行期采样率配置的这个要求。我们选择了运行期采样率，这样就可以优雅的去掉我们无法写入到仓库中的多余数据。我们还可以通过调节收集系统中的二级采样率系数来调整这个运行期采样率。Dapper 的管道维护变得更容易，因为我们可以通过修改二级采样率的配置，直接增加或减少全局覆盖率和写入速度。\nSOFATracer 的采样源码剖析 SOFATracer 提供链路数据采样功能特性，支持两种采样策略：基于固定采样率的采样模式和基于用户扩展实现的自定义采样模式。\n采样接口模型 SOFATracer 提供定义链路追踪数据采样模式接口 com.alipay.common.tracer.core.samplers.Sampler，此接口 sample 方法通过 SofaTracerSpan 实例参数作为采样计算基础条件决定链路是否采样，实现丰富的数据采样规则。SOFATracer 基于 com.alipay.common.tracer.core.samplers.SamplerFactory 生成的采样器执行链路数据采样基本流程：\n 构建链路追踪器，通过采样器工厂 SamplerFactory 根据自定义采样规则实现类全限定名配置生成指定策略采样器 Sampler，其中基于用户扩展实现的采样模式优先级高，默认采样策略为基于固定采样率的采样计算规则； Reporter 数据上报 reportSpan 或者链路跨度 SofaTracerSpan 启动调用采样器 sample 方法检查链路是否需要采样，获取采样状态 SamplingStatus 是否采样标识 isSampled。 采样器的初始化 上面分析到，采样策略实例是通过 SamplerFactory 来创建的，SamplerFactory 中提供了一个 getSampler 方法用于获取采样器： 从代码片段来看，用户自定义的采样策略将会优先被加载，如果在配置文件中没有找到自定义的 ruleClassName ，则构建默认的基于固定采样率的采样器。SamplerProperties 是采样相关的配置属性，默认提供的基于固定比率的采样率是 100%，即默认情况下，所有的 Span 数据都会被记录到日志文件中。关于具体配置，在下文案例中会有详细介绍。\n采样计算 采样是对于整条链路来说的，也就是说从 RootSpan 被创建开始， …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第四篇，本篇作者米麒麟，来自陆金所。","dir":"blog/sofa-tracer-sampling-tracking-deep-dive/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"552e5d7feb431d3ff658a0194ead7b8f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","publishdate":"2019-02-21T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 采样策略和源码剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/","wordcount":4224},{"author":"J. Queue","categories":"SOFATracer","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\nSOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。\n本文为《剖析 | SOFATracer 框架》第三篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:TracerLab/，目前领取已经完成，感谢大家的参与。 SOFATracer：https://github.com/sofastack/sofa-tracer\n SOFATracer 是一个用于分布式系统调用跟踪的组件，其核心作用就是能够在分布式场景下将请求经过的各个的链路环节的相关数据记录下来，通过这些数据将各个调用链路相关的组件串联起来。\n在日常的开发中，我们除了跟踪链路外，可能还会遇到一些场景：\n例如在线压测，我们在已有的系统中，模拟一些请求（压测流量）对我们的系统进行压力测试，那么在整个链路中我们是如何让所有的系统都识别出当前的请求是压测流量而不是正式流量的呢？压测流量的标记又是如何在整个链路传递的呢？\n又例如我们已经有了链路数据分析能力，能够快速定位到某个请求是在 A 系统里出的问题，那么我们怎么从 A 系统的业务日志里找到当前请求对应的业务日志呢？\n带着这些问题，让我们先来看看 SOFATracer 的链路透传以及支持 SLF4J MDC 扩展能力。\nSOFATracer 链路透传原理 SOFATracer 的链路透传具体包括两个点：\n 跨进程的透传，即如何将链路数据从一个进程传递到下游进程中 线程中的透传 当前请求跨进程调用结束之后，当前如何恢复 tracer 上下文信息 如何实现跨线程的透传，如在当前线程中起一个异步线程的场景 跨进程链路透传原理 跨进程透传就是将上游系统的链路数据透传到下游系统中，以便于提取出全局的链路标记，如 TracerId 、采样标记等，来实现将服务串联起来并且保持传输过程中某些属性的一致性。SOFATracer 基于 Opentracing 规范实现，因此在链路透传部分，也是基于此规范；下面就先从 Opentracing 规范中的透传开始说起。\nOpentracing 中的定义 在 OT 原文有这么一段描述 传送门\n Programmers adding tracing support across process boundaries must understand the Tracer.Inject(...)and Tracer.Extract(...) capabilities of the OpenTracing specification. They are conceptually powerful, allowing the programmer to write correct_general cross-process propagation code without being bound to a particular OpenTracing implementation; that said, with great power comes great opportunity for confusion.\n 大概意思就是：如果开发者要给应用添加跨进程的追踪能力, 首先要理解 OpenTracing 规范中的 Tracer.Inject(...)和 Tracer.Extract(…)的功能。它们在概念抽象上非常强大，而且允许开发者编写正确的、通用的跨进程传输的代码，而不需要绑定到特定的 OpenTracing 实现上去。\n总的来说就是 Opentracing 的 Tracer 接口定义了跨进程的能力，但是就是没具体实现，不同的基于此规范实现的组件，需要遵循此规范来实现具体的透传逻辑，下面是 Tracer 接口定义的用于透传的两个方法：\n 接口 描述 void inject(SpanContext spanContext, Formatformat, C carrier); 把 spanContext 以指定的 format 的格式注入到 carrier 中 SpanContext extract(Format format, C carrier); 以指定的 format 的格式从 carrier 中解析出 SpanContext 进程透传实现分析 SOFATracer 的 Tracer 的实现类是 SofaTracer， UML 图如下：\n从图中可以看出 SofaTracer 除了有跨进程传输的能力，还扩展了数据上报的能力( Reporter )和采样能力( Sampler )。数据上报能力可以参考《SOFATracer 数据上报机制和源码分析|剖析》这篇文章；采样将在下一篇文章中进行剖析。\n跨进程透传的就是 SpanContext 的内容， carrier 为传输的载体， SpanContext 的实现类为 SofaTracerSpanContext， UML 图：\n跨进程透传处理流程 SOFATracer 中跨进程传输的总体流程如下图所示：\n透传原理的实质就是：调用方编码将指定内容传输到被调方， 被调方解码获取内容的过程。\n跨进程透传的方式有很多， 在这里以客户端向服务端发起 HTTP 请求的方式来演示跨进程传输， fork 代码， 打开 sample/tracer-sample-with-httpclient 示例工程运行 HttpClientDemoApplication ，打开 logs/tracelog/spring-mvc-stat.log 即可看到链路日志， 运行结果 ：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-01-07 19:42:50.134\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:1563,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-01-07 …","date":1550744400,"description":"本文为《剖析 | SOFATracer 框架》第三篇。","dir":"blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"82a08996dd671b01595748aa2d2fa748","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","publishdate":"2019-02-21T10:20:00Z","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分","tags":["SOFATracer","SOFALab","剖析 | SOFATracer 框架"],"title":"蚂蚁金服开源分布式链路跟踪组件 SOFATracer 链路透传原理与SLF4J MDC 的扩展能力剖析","type":"blog","url":"/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/","wordcount":6294},{"author":"卫恒","categories":"SOFABoot","content":" SOFABoot 是基于 Spring Boot 的一套研发框架。 在完全兼容 Spring Boot 的基础上，SOFABoot 还提供了启动期监控检查，上下文隔离，模块化开发，类隔离，日志空间隔离等等能力 SOFABoot 地址：https://github.com/alipay/sofa-boot 本文工程案例：https://github.com/glmapper/glmapper-sofa-extension\n 春节小长假还没感觉就过去了，对于“热爱工作”的我，也早早的回到了工作岗位；感受下假期中的我和上班时的我。\n 后面拿枪的就是\u0026amp;rdquo;逼着\u0026amp;rdquo;我写文章的五花肉，上次 SOFATracer 采样用的是刀，这次用了枪！\n 模块化与扩展点 言归正传，节前 SOFABoot 发布了 2.6.x 系列版本，新特性也是相当给力，这里简单罗列下新特性：\n 支持扩展和扩展点 在刷新上下文期间支持 spring bean 的并行初始化 支持使用注解方式发布 JVM 服务 之前的文章中有 @玄北 写过的模块化的文章( 传送门 : 剖析 | 详谈 SOFABoot 模块化原理 \u0026amp;amp; 基于 SOFABoot 进行模块化开发 )，这两篇文章中介绍了模块化的几种实现方案（PS：当然主要还是为了宣传一下 SOFABoot 提供的基于 Spring 上下文隔离的模块化能力）。SOFABoot 的模块隔离方案是为了解决传统的模块化方案模块化不彻底的问题，从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化能力，每个 SOFABoot 模块使用独立的 Spring 上下文，每个模块自包含，模块与模块之间通过 JVM Service 进行通信，从而避免模块间的紧耦合。\n在 Spring 上下文隔离的情况下，各个上下文之间的 bean 是互不可见；SOFABoot 中通过发布 JVM 服务的方式使得不同模块 bean 之间的访问得以实现。但是同时又带来了另外一个问题，如果一个模块以独立 jar 的方式对外提供 api ，那么对于其他依赖此模块的模块来说，就无法去改变这个模块中的 bean 实例行为。\n在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项目，并在上面扩展，与 Spring 融合，提供了扩展点的能力。\n本篇将针对 SOFABoot 2.6.x 版本中提供的扩展点进行简单尝试，结合官方文档提供的示例，一步一步实现我们自定义的一个扩展点功能（本文过于简单，可能会引起极度舒适，请备好被子和热水袋）。\n案例背景 这里先抛出一个例子，现在有一个三方 jar ，它定义了获取数据源接口的顶层抽象；不同的业务方如果依赖这个 jar，则需要自己提供一个数据源的实现，当然其本身提供了默认实现（假设是 mysql）。基于此我们大概能够想到的方式就是基于 SPI 来提供这种扩展能力，但是对于在 Spring 上下文隔离的情况下，业务方的 Spring 上下文是无法与引入 jar 的上下文共享 bean 的，这样自然也就无法实现对原有数据源实现的扩展。\n那么这里我们就可以选择使用 SOFABoot 扩展点来实现，这里有两个比较重要的概念，也是扩展点区别于 SPI 的主要特性：\n 可以在基于 Spring 上下文隔离的情况下实现扩展 扩展的是 Spring Bean  下面基于这两个点，来完成自定义扩展点的一个案例。在实现上述案例之前我们需要先构建一个基于 Spring 上下文隔离的模块化工程，然后再简单介绍下扩展点的基本使用方式。\n构建模块化工程 SOFABoot 开源版本中并没有给出扩展点相关的案例工程，只是在测试用例中进行了详细的测试，有兴趣的同学可以看下相关测试用例代码。实际上测试用例中也没有涉及到在模块化的场景下使用扩展点，测试用例都是基于同一个Spring 上下文来完成的。本篇文章将先搭建一个简单的模块化工程，然后基于此工程来实现扩展点的能力。\n本工程主要包括 4 个模块：\n glmapper-sofa-facade // JVM 服务发布与引用的 API 包 glmapper-sofa-provider // Annotation 方式发布 JVM 服务 glmapper-sofa-consumer // Annotation 方式引用 JVM 服务 glmapper-sofa-web // 启动包含 SOFABoot 模块的 SOFA Boot 应用 官方文档及案例 中给的比较复杂，包含了多种使用服务发布和引用的方式，这里我使用了最新提供的基于注解的方式来实现；获取本文工程案例。\n扩展点基本使用 在 SOFABoot 中使用扩展点能力，需要以下三个步骤：\n 定义提供扩展能力的 bean 定义扩展点 定义扩展并使用 这三步中前两步都是由服务提供方来完成，最后一步由具体的业务使用方式来定义。\n定义提供扩展能力的 bean 本案例工程中，是将 glmapper-sofa-provider 作为服务提供方，因此也在此模块下定义一个具有扩展能力的 bean 。\n定义这个接口的实现：\n在模块的 Spring 配置文件 resources/META-INF/service-provider.xml 中，我们把这个 bean 给配置起来：\n定义扩展点 在上面的 bean 中有一个字段 word ，在实际中，我们希望这个字段能够被其他的模块自定义进行覆盖，这里我们将其以扩展点的形式暴露出来。这里先定义一个类去描述这个扩展点：\n然后在模块的 Spring 配置文件 resources/META-INF/service-provider.xml 中定义扩展点：\n name：为扩展点的名字 ref：为扩展点所作用在的 bean object：为扩展点的贡献点具体的描述，这个描述是通过 XMap 的方式来进行的（XMap 的作用是将 Java 对象和 XML 文件进行映射，这里建议通过在网上搜索下 XMap 的文档来了解 XMap） 至此服务提供端已经暴露出了扩展点，那么在服务使用端，也就是需要扩展这个 bean 的使用方就可以扩展这个bean 了。\n定义扩展 上述已经将扩展点定义好了，此时我们就可以对这个 bean 进行扩展了。扩展是具体业务使用方来做的事，在本案例中，glmapper-sofa-web 模块作为使用服务使用方，因此在 resources/META-INF/spring/web-home.xml 下进行扩展定义：\n bean：为扩展所作用在的 bean point：为扩展点的名字 content 里面的内容为扩展的定义，会通过 XMap 将内容解析为：扩展点的贡献点具体的描述对象，在这里即为 com.glmapper.bridge.extension.ExtensionDescriptor 对象 需要注意一点，glmapper-sofa-web 模块不是一个 SOFABoot 模块，这里留坑。\n 编写一个 TestController 类，这里最先 …","date":1550127600,"description":"本文根据 SOFAChannel#5 直播分享整理，主题：给研发工程师的代码质量利器 —— 自动化测试框架 SOFAActs。","dir":"blog/sofa-boot-extension-practice/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4f05313f7adf5401f3b5f499b43bb928","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-extension-practice/","publishdate":"2019-02-14T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-boot-extension-practice/","summary":"SOFABoot 是基于 Spring Boot 的一套研发框架。 在完全兼容 Spring Boot 的基础上，SOFABoot 还提供了启动期监控检查，上下文隔离，模块化开发，类隔离，日志空间隔离等等","tags":["SOFABoot"],"title":"SOFABoot 扩展点初体验 | SOFALab 实践系列","type":"blog","url":"/sofastack.tech/blog/sofa-boot-extension-practice/","wordcount":3773},{"author":"余淮","categories":"SOFAStack","content":" SOFA:Channel/，有趣实用的分布式架构频道。 SOFA:Channel/ 作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）。\n 大家晚上好，今天是 SOFAChannel 第一次线上直播，感谢大家的收看。\n先自我介绍下，我是来自蚂蚁金服中间件的章耿，花名余淮，目前在负责应用框架与 SOFAStack 开源相关的工作。\n今天给大家的分享主要分为三部分，第一部分是蚂蚁金服服务化演进的简介，第二部分是SOFAStack开源的情况。这两部分之前的分享也提到过，我们讲快一点，第三部分会详细介绍下 SOFARPC 的一些设计和实现细节。\n分享过程中如果大家对技术点比较感兴趣，或者其他组件感兴趣，也欢迎留言，后面的直播会安排更多的相关分享。\n蚂蚁服务化架构演进简介 大家现在对蚂蚁金服技术的概念，听得比较多的应该是“余额宝”、“相互宝”、“蚂蚁森林”、“刷脸支付”，“扫描工具地铁”、“双十一”等等这些耳耳熟能详的产品和场景。\n这些产品的背后，是蚂蚁金融科技的一套核心技术，包括 “三地五中心异地多活架构”，“金融级分布式架构”、“国产金融级分布式数据库 OceanBase”，“智能风控”，“区块链” 等诸多黑科技。\n当然，蚂蚁金服的微服务架构体系像其它传统的企业一样，也不是一开始就这么高大上，也是随着业务的发展慢慢演进而来的。下面给大家简单介绍下演进的过程。\n这个支付宝最早的架构示意图，可以看到当时支付宝只是电商后台的一个支付系统，是一个单体应用，里面简单的分了几个业务模块，连的也是一个数据库。但随着业务规模的不断扩展，单系统架构已经无法满足业务需求。\n所以支付宝就对大系统进行了拆分，将原来的一个单体应用内部的多个模块变成了多个独立的子系统，这算是典型的 SOA 化的架构。\n最开始系统之间是使用 F5 的硬件负载设备来做系统间的负载均衡，但由于 F5 设备存在单点的问题，所以后面就在中间引入一个注册中心的组件。服务提供者去注册中心注册服务，服务消费者去注册中心订阅服务列表，服务消费者通过软负载方式通过 RPC 框架直接调用服务提供者。这在现在看来是一种非常显而易见的服务化架构，但当时 07 年就采用这样的架构还是算比较超前的。\n支付宝在做系统拆分的同时，对数据库也按子系统进行了垂直拆分。数据库的拆分就会引入分布式事务的问题，蚂蚁金服中间件就提供了基于 TCC 思想的分布式事务组件 DTX。\n业务还是不断扩展，系统也越来越多，当系统节点到一定数量的时候，单个物理机房已经无法承受。另外考虑到同城容灾的问题，支付宝就在同城再扩建另外一个机房，通过专线部署为一个内部网络，然后将应用部署上去。\n同城多机房会引入一个跨机房远程访问的问题，相比同机房调用，这个延迟损耗一定是更高的。远程访问主要包括两种：RPC 调用和数据库访问。为了解决 RPC 跨机房调用的问题，支付宝的工程师选择的方案是在每个机房都部署注册中心，同机房优先调用本机房服务的方式，也就变成图中的部署模式。但是数据库跨机房访问的问题，在这个阶段并没有解决。\n另外还存在的一个问题就是调用链路混乱以及数据库连接瓶颈的调用。例如这个图里，我们对数据进行了分片，然后图中的 user0 的请求进来后，随机转到 S2，再随机转到B0，在随机到C1，最终跟进数据分配落到了数据库 D0。可以看到这里的调用链路是随机的，而每一个核心层也需要跟所有的分库都建立长连接。\n为了解决上面的跨机房数据访问、数据库连接数瓶颈以及未来数据水平扩展的问题，蚂蚁的工程师们设计了一套单元化的架构，这是单元化的一个示意图。\n在没有单元化的时候，用户请求进入内部后，所有请求链路都是随机走的，例如图里的 S0 到 B1 到 C2 到 D0。首先蚂蚁的请求都是跟用户相关的，所以我们将数据按用户的维度进行水平分片，例如这张示意图我们将所有用户分为三组。然后我们将我们的应用也部署成三组独立的逻辑单元，每个逻辑单元的应用和数据都是独立的，相当于每个逻辑单元都处理1/3总量用户的数据。\n这个时候我们的三个不同终端的用户，不管是在PC端或者手机端或者扫二维码，当请求进入统一接入层的时候，接入层会按上面逻辑单元的分组规则，将用户请求转发到对应的逻辑单元，例如 user0 的请求转到 S0，后面的应用之间的调用、数据都只在逻辑单元 0 内。统一的 user1 只在逻辑单元 1，user2 也只到逻辑单元 2。\n我们把这种逻辑单元称之为 RegionZone。在实际的部署过程中，物理数据中心 IDC 和 逻辑单元的数量没有完全的对等关系。例如图中我们物理机房可以是两地三中心，而 RegionZone 则是分为五个。\n两地三中心是国家对金融机构的一个容灾指导方案，要求在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同时在异地（＞ 200KM ) 建立异地容灾中心。\n有了这套单元化的架构做指导思想，蚂蚁进行大规模的改造，包括应用改造、基础框架改造、数据中心的建设。\n机房建设完成后，同时蚂蚁金服将自己的用户分成了若干份，划了几个逻辑单元，分别部署进了不同的物理机房，同时完成大规模的数据迁移。\n从两地三中心到容灾能力更强大的三地五中心，我们只需要先进行第三个城市的机房建设，然后将部分 RegionZone 部署到第三个城市，最后再完成数据迁移和引流即可。\n每一个 RegionZone 在异地都有备份，当发生城市级的故障时，我们通过统一的管控中心将新的逻辑规则推送到统一接入层以及异地的备 RegionZone 时，就可以做到城市级的整体容灾切换。\n再后面基于单元化思想，蚂蚁工程师还建设了弹性 LDC 的能力，例如大型活动开始的时候，我们将动态的将大促相关应用调度到其它的临时机房（例如是云上的机房）去，然后将流量引入。例如图中实例将 10% 的流量引入了 ZoneX 中。等到活动结束，我们再将流量引回。\nSOFAStack 开源情况 从前面的服务化演进可以看到，蚂蚁的微服务架构面临的场景已经慢慢从简单的远程调用发展到要面临复杂的三地五中心异地多活场景，为了支持这些场景，蚂蚁中间件自研了一套中间件 SOFAStack。\nSOFAStack 中的 SOFA 其实是 Scalable Open Financial Architecture 的首字母缩写，它是用于快速构建金融级分布式架构的一套中间件，也是在金融场景里锤炼出来的最佳实践。\n这是我们内部的技术栈，可以看到微服务领域各个功能点我们都有对应的内部系统或者组件。包括有RPC框架、服务发现、动态配置、熔断限流，还有分布式事务，分库分表等一整套中间件。\n目前 SOFAStack 也在蚂蚁金融科技上进行了技术输出。我们对中间件产品进行了产品化，并在蚂蚁金融云上变成了云上的产品，并提供了诸多例如同城双活之类的解决方案。这个是商业的产品，大家有空可以看下。\n在去年的 4.19 号，SOFAStack 正式宣布开源，我们第一批主要开了SOFABoot …","date":1548680400,"description":"本文根据 SOFAChannel#1 直播分享整理，主题：从蚂蚁金服微服务实践谈起。","dir":"blog/sofa-channel-1-retrospect/","fuzzywordcount":6300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c7997723a3859feb5f4f8fa454b6e00e","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-channel-1-retrospect/","publishdate":"2019-01-28T21:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-channel-1-retrospect/","summary":"SOFA:Channel/，有趣实用的分布式架构频道。 SOFA:Channel/ 作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。欢迎加入直播","tags":["SOFAStack","SOFAChannel"],"title":"从蚂蚁金服微服务实践谈起 | SOFAChannel#1 直播整理","type":"blog","url":"/sofastack.tech/blog/sofa-channel-1-retrospect/","wordcount":6269},{"author":"花肉","categories":"SOFAChannel","content":" 活动主题：SOFAChannel#1——从蚂蚁金服微服务实践谈起 活动时间：1 月 17 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 \u0026amp;lt;SOFA:Channel/\u0026amp;gt;，有趣实用的分布式架构频道\n前沿技术、直播 Coding、观点“抬杠”，多种形式\n\u0026amp;lt;SOFA:Channel/\u0026amp;gt; 将作为 SOFA 所有在线内容的承载，包含直播/音视频教程，集中体现 SOFAStack 的能力全景图。\n欢迎加入直播互动钉钉群：23127468（搜索群号加入即可）\n议程 SOFAChannel#1 《从蚂蚁金服微服务实践谈起》\n时间：2019-01-17 地点：浙江省杭州市西湖区线上直播 19:00-20:00 《从蚂蚁金服微服务实践谈起》 章耿 花名余淮（蚂蚁金服高级技术专家。目前在蚂蚁金服中间件服务与框架组负责应用框架及 SOFAStack 相关的工作） 嘉宾 蚂蚁金服 SOFA 团队 余淮\n视频回顾地址 https://tech.antfin.com/community/live/148\n","date":1547720400,"description":"首次 SOFAChannel 线上直播，1 月 17 日晚 7 点等你。","dir":"activities/sofa-channel-1/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5c79d2fac126784ef412f107470b2924","permalink":"https://sofastack.github.io/sofastack.tech/activities/sofa-channel-1/","publishdate":"2019-01-17T10:20:00Z","readingtime":1,"relpermalink":"/sofastack.tech/activities/sofa-channel-1/","summary":"活动主题：SOFAChannel#1——从蚂蚁金服微服务实践谈起 活动时间：1 月 17 日周四晚 7 点 活动形式：线上直播 直播视频回顾 直播回顾文章 介绍 \u0026","tags":["SOFAChannel","SOFARPC"],"title":"SOFAChannel#1——从蚂蚁金服微服务实践谈起","type":"activities","url":"/sofastack.tech/activities/sofa-channel-1/","wordcount":323},{"author":"许文奇","categories":"SOFAStack","content":" 许文奇 蚂蚁金服高级技术专家，SOFAStack 商业化产品技术 Leader，多年分布式架构及中间件研发经验，负责过蚂蚁金服分布式架构在多家金融机构的咨询和落地 本文根据他在 2019 蚂蚁金服 ATEC（Ant Technology Exploration Conference）科技大会上海站的分享整理。\n 本次分享主要会从单体架构和微服务架构的对比开始，后面重点谈一下实施金融级分布式架构的常见三个问题。\n常用架构：单体式架构 目前很多金融机构的架构是典型的单体式架构，一般由反向代理服务器，数据库和应用组成，所有业务模块都打包在一个应用里面运行，一般为了高可用考虑，应用至少会部署两个节点。单体式架构在业务简单的时候有很多它自身的优点：\n 开发，测试简单 部署简单 扩容简单，只要给应用加机器就行 但同样，单体式架构也有很多缺点，尤其是业务规模变得复杂以后，缺点会非常突出：\n 编译慢，启动慢，代码冲突等各种问题，严重影响开发效率 性能扩展有局限性，一定规模后，单纯堆机器已经很难扩展性能了。 蚂蚁金服的架构：分布式架构 微服务架构是目前大家最关注的一种分布式架构。微服务架构除了在性能可扩展性上对比单体式架构有巨大优势，还有一个重要优势体现在复杂业务下的生产效率优势。\n只有在业务复杂度较低的时候，单体式架构的生产效率才能超过微服务架构，但随着业务复杂度上升，尤其过了临界点，单体架构下的生产效率是非常恐怖的急速下坠，而微服务架构生产效率有所下降，但下降趋势非常缓慢，且不会偏离原有生产效率太多，能很好的应对业务复杂性的增长。\n所以实施微服务架构最重要的一个意义是在业务复杂度较高的情况下提升生产效率，更快速的进行业务创新。\n实施金融级分布式架构最常见的三个挑战 基于微服务架构的巨大优势，很多金融机构、企业开始逐渐转型微服务架构，转型总是伴随着挑战，这里选了三个最常见的，最多用户关心的问题，聊聊蚂蚁金服的一些实践心得：\n 如何进行微服务架构拆分及治理？ 新的分布式架构如何兼容老系统？ 如何一步一步构建金融级容灾架构？ 1、微服务架构拆分及治理 微服务拆分模式可以从微服务架构的扩展立方开始讲起，分为X轴，Y轴，Z轴三类拆分。\nX轴代表横向扩展模式。主要通过部署多份应用，负载均衡的方式来扩展性能，这个单体架构也可以做。当然，在微服务架构下，横向扩展模式的实现方式有别于单体架构。\n微服务架构做服务负载均衡不需要通过F5或者LVS集群这样的硬件设备，只需要通过注册中心就可以实现，这样带来的好处是降低了成本，不需要购买大量的硬件设备了；提高了性能，业务干路上少了一个单点风险；降低了维护成本。\n当然支持横向扩展模式还需要应用是无状态的，这个是微服务架构的基本要求，任何涉及状态的数据都应该保存在数据库，缓存或者其他一些存储介质中。更高的要求的话，应用应该要满足著名的12要素的要求。\nY轴代表功能分解模式。我们提倡业务系统在开发的时候就应该按照模块化进行开发，满足高内聚，低耦合的架构要求。为了更好支持模块化开发，以SOFAStack中间件的SOFABoot框架为例，框架支持模块隔离能力，不同的模块使用不同的Spring上下文，这样不同的模块之间就不能直接引用了，如果需要调用别的模块的接口，那么需要走SOFABoot框架规定的特别声明才可以办到。这样极大的规范了模块化开发，使得这些系统将来在进行拆分的时候，成本非常的低。\n关于功能分解，服务拆分，虽然没有一个标准答案告诉我们就该怎么做，但其实也有一些基本指导原则和实践：\n 按照业务领域进行拆解，而不是组织。所有拆分必须按照业务领域模型进行合理划分，因为实体组织不一定能和业务领域完全对应，且组织一般粒度较大，不能作为拆分细粒度微服务的参考。 从数据核心模型拆分开始先拆，而后再往上进行服务拆分。这个主要是进行拆分的一个重要次序问题。一般梳理数据核心模型比较容易，比如很容易梳理出哪些表，哪些数据属于交易，哪些表，哪些数据属于账务，然后按照业务垂直进行拆分。有些业务归属不那么明确的可以按照数据亲和性进行拆分。然后数据核心模型拆分好以后，再往上按照功能模块，所对应的场景，进行服务拆分。 单一职责。这个是微服务架构的一条金科玉律，要求微服务架构必须遵守。一个很主要的原因是为了避免微服务架构重新掉进单体架构的老问题里面。原来单体架构最大的问题就是任何的改动，都要导致整个应用重新的编译打包部署，还包括全量回归测试。试想一个微服务里面有太多的功能、职责，如果任意一个业务模块有需求，需要改动，必然导致该微服务的应用重新编译，打包部署和全量回归测试，频繁变动成本很高，研发效率也会降低。 注意拆分粒度，避免一开始拆得过细，循序渐进。关于拆分粒度，这个也是一个没有标准答案的问题。总的一个原则就是适用最好。任何一家公司的业务都是独一无二的，不存在一模一样业务的两家公司，所以别人的拆分，可以借鉴，但往往很难照抄。所以推荐拆分的时候，一开始不要拆得过细，按照业务发展的规律，循序渐进。举个例子，比如说红包业务，原来可能只是营销系统的一个模块，但如果公司的业务在红包这块发展得足够复杂，是可以考虑拆为单独的微服务，这一切取决于业务发展。 注意服务分级和分层，避免循环依赖。这个要求服务拆分的时候，充分注意到哪些是核心服务，哪些是非核心服务，不能出现核心服务强依赖非核心服务的情况，更不能出现循环依赖的情况。 考虑团队结构。最后微服务拆出来，肯定是要有对应团队去维护的，所以整个拆分的粒度，拆分的逻辑也要考虑团队结构的情况。 Z 轴代表数据分区模式。一般在数据库遇到性能瓶颈的时候，需要进行数据拆分，一般分为垂直拆分和水平拆分。垂直拆分一般就是按照业务划分来进行，比如以前账务和交易放在一个数据库，现在数据库有瓶颈了，那么就可以拆成账务和交易两个数据库，缓解数据库的性能瓶颈。当然，如果按照垂直拆分完毕以后，还是不能满足性能要求，这个时候就需要进行水平拆分了。\n关于水平拆分，也有一些重要的实践原则。在做数据库水平拆分的时候，最好一次性考虑未来十年，甚至二十年的业务的要求，要避免今天做了一个拆5张表的决定，过了两年，发现不行，还要继续拆成10张表，甚至20张表的情况。\n重新分片是个非常复杂的工作，尤其是线上还不允许停机的情况。另外关于确定如何拆多少库，多少表，也有一些实践。一般拆的数据库数量等于未来业务的峰值（TPS）除以单数据库的容量（TPS）。这里并不代表要一步到位，拆那么多实际物理库，一开始可借助SOFAStack分库分表中间件虚拟成逻辑库，只需要少量物理库，等到访问量上来后，再扩容物理库。拆的表的数量等于单表时间业务量乘以存储时长除以单标容量上限。记住表的数量一定要一步拆到位，避免过一两年还要折腾。\n做了数据拆分后，就会遇到分布式事务的问题，需要解决分布式事务的问题，这个也是金融行业区分与别的行业的最大不同。SOFAStack分布式事务中间件目前支持TCC和FMT两种模式（这里主要讨论实践，对于TCC和FMT两种模式的原理，这里不再赘述，有兴趣的可以参考之前的文章）。TCC模式虽然编码复杂，业务有侵入，难度较高，但胜在性能好，所以像核心系统里面的分布式事务都是用该方案。当然，因为复杂，所以实现中有些地 …","date":1547535600,"description":"本次分享主要会从单体架构和微服务架构的对比开始，后面重点谈一下实施金融级分布式架构的常见三个问题。","dir":"blog/distributed-arch-in-the-enterprise/","fuzzywordcount":5500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e2f9f404c5e859e21c65fb3c2f2f0324","permalink":"https://sofastack.github.io/sofastack.tech/blog/distributed-arch-in-the-enterprise/","publishdate":"2019-01-15T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/distributed-arch-in-the-enterprise/","summary":"许文奇 蚂蚁金服高级技术专家，SOFAStack 商业化产品技术 Leader，多年分布式架构及中间件研发经验，负责过蚂蚁金服分布式架构在多家金融","tags":["SOFAStack"],"title":"企业实施分布式架构的挑战以及应对建议 | 上海 ATEC 科技大会实录","type":"blog","url":"/sofastack.tech/blog/distributed-arch-in-the-enterprise/","wordcount":5455},{"author":"崔秀龙","categories":"Service Mesh","content":" 崔秀龙，HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员。\n本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整理，完整的分享 PPT 获取方式见文章底部。\n本文内容收录在崔秀龙的新书：《深入浅出 Istio - Service Mesh 快速入门与实践》的第十章，该书将于近期由博文视点出版发行，敬请关注。\n Service Mesh 概念在 Linkerd 落地之后，让一直漂浮在空中的微服务治理方案有了一个明确的落地点，给微服务架构的具体实现指出了一个清晰的方向，围绕这一概念逐步开始形成新的技术生态，在业界造成不少震动。这种震动对于企业 IT 转型工作带来的影响，甚至比容器化的影响更加深远。对于承担企业 IT 转型工作的企业服务行业来说，也自然首当其冲感觉到新概念带来的压力。\n企业服务行业和互联网行业相比，业务形态、技术积累和人员结构等方面都大相径庭，举几个常见的差异：\n 开发、运维、基础设施所属 人员结构、水平和年龄 资源使用率差别 架构和平台一致性 负载能力 \u0026amp;hellip; 目前进行 Service Mesh 布道的主力还是互联网行业的旗手们，一味追求跟进互联网同行们的进度和做法，颇有邯郸学步的风险。\n本文中将会针对目前 Service Mesh 方面的一些普遍问题和关注热点发表一些个人意见。并尝试提供一种 Istio 的试用思路，给乙方同行们提供参考。\nIstio 的功能 无需赘述，多数用户都很清楚，Istio 使用和应用共享网络栈的方式，利用 Iptables 劫持应用的网络流量，从而在不修改业务源码的情况下，完成一系列的功能：\n 监控服务质量 控制服务间的访问路由 应对服务故障 在服务间通信之间进行加密 访问控制和频率限制 分布式跟踪和业务紧密相关，无法做到无侵入。\n 这其中最大的优势就是无侵入，这意味着给试用流程留下了全身而退的机会，如果没有回滚的能力，上述种种能力都是空中楼阁。\nIstio 的问题 API 稳定性可能是最严重的一个问题。目前最成熟的功能组别应该是流量控制，其版本号也仅是 v1alpha3，一般来说，alpha 阶段的产品，代表着不提供向后兼容的承诺，流量控制 API 在从 v1alpha2 升级为 v1alpha3 的过程中，API 几乎全部改写，使得很多早期用户的精力投入付诸东流。核心功能尚且如此，遑论相对比较边缘的 Mixer、Citadel 以及 Galley 组件的相关内容。 发布节奏和发布质量的问题也相当严重。Istio并不算长的历史中，出现了多次版本撤回、大版本严重延期、发布质量低下无法使用以及 Bug 反复等状况，这无疑会让每次升级尝试都充满了不确定性，会很大的影响生产过程的连续性。 Mixer 是一个问题焦点，其数据模型较为复杂，并且集中了所有应用的流量于一点，虽然其中加入了各种缓存等技术来降低延迟，但是其独特地位决定了 Mixer 始终处于一个高风险的位置。同时其 API 结构稍显混乱，重构风险较大。 Pilot的性能方面也经常为人诟病，虽然经过几次升级，但是即使是 1.0 之后，还是出现了两次 Pilot 在集群中服务/Pod 过多的情况下会超量消耗资源的问题。 安全、物理机和虚拟机的支持以及网格边缘通信这三组功能，目前用户较少，质量尚不明确。 最后就是 Istio 的 Sidecar 注入模式，这种模式一定会增加服务间调用的网络延迟，在目前阶段这是一个痼疾，Sidecar 的固定延迟和 Mixer 的不确定行为相结合，有可能会产生严重后果。 这里提出的只是被反复提及，或者经常出现在 Issue 列表中的问题，由发布问题来看，面临的风险可能远不止这些。\nIstio 试用工作的理由和规划 试用 Istio，首先应该确定，该技术的采用，是否能够在可控的风险和投入下，得到有效的产出。\n 微服务模式的推进，必须要有相应的管理能力，Service Mesh 目前看来，是一个确定有效的方案，如果不是 Istio，也会有其它替代产品出现。 目前看来，Istio 是 Service Mesh 的标志性产品，有一定可能性成为事实标准。 提供了众多开箱即用的丰富特性，能够迅速进入 Service mesh。 最后是无侵入的优势：如果试用失败，可以退回，控制损失范围。 Istio 的多数功能，在无需对程序进行修改（分布式跟踪除外）的情况下，能对应用提供如此之多的功能支持，无疑是非常有吸引力的。Istio 的功能集，完全可以说是服务网格技术的典范。一旦确认现有环境有可能支持 Istio 的运行，并且在合理的投入下能够获得有效益的产出，那么这个试用就是有价值的。\n结合 Istio 的现状，以及多数企业的运行状态，个人浅见，Istio 的应用在现阶段只能小范围试探性地进行，在进行过程中要严格定义试用范围，严控各个流程。 按照个人经验，笔者将试用过程分为如下 4 个阶段。\n 范围定义：选择进入试用的服务，确定受影响的范围，并根据 Istio 项目现 状决定预备使用的 Istio 相关功能。围绕这些需要，制定试用需求。 方案部署：根据范围定义的决策，制定和执行相关的部署工作。其中包含 Istio 自身的部署和业务服务、后备服务的部署工作。 测试验证：根据既有业务目标对部署结果进行测试。 切换演练：防御措施，用于在业务失败时切回到原有的稳定环境。 Istio 的试用步骤 确定功能范围 在 Istio 中包含了非常多的功能点，从原则上来说，各种功能都是有其实际作用的。然而，Istio 作为一个新产品，本身也有很多不足，我们在 10.1 节中也提到了这些不足。\nIstio 提供的众多功能对每个公司或者项目，都会有不同价值。我们在采用一个新系统时，首先要考虑的就是性价比问题，这里的“价”代表着 Istio 带来的风险、对业务应用的影响，还包括可能出现的服务停机等问题。\n可以根据性价比，做出一个优先级别列表。在制定了优先级列表之后，就可以根据这一列表，结合项目的实际需求，按照效果明显、功能稳定、部署成本低、少改造或者不改造的标准来进行选择，最终确定待测试的功能点。\n在选定功能点之后，应该遵循目前已有的 Istio 文档，对各个功能点进行单项测试和验证，以确保其有效性。并通过官方 GitHub 的 Issue 列表及讨论组内容，了解现有功能是否存在待解决的问题，以及相关的注意事项等。\n选择试用业务 在试用功能点确定之后，就要选择用于试用的业务应用了。Istio 作为一个相对底层的系统，其部署和调试过程必然会对业务产生一定的影响，在运行阶段又有 Sidecar 和各个组件造成的损耗，如下所述：\n 所有网格之间的通信都要经过 Sidecar 的中转，会造成大约 10 毫秒的延迟。 Pilot 对集群规模敏感，集群中的服务数量、Pod 数量都可能对 Pilot 造成较大影响，也会影响到 Istio 各种规则向 Pod 的传输过程。 所有流量都会经由 Mixer 处理，也有造成瓶颈的可能。 安全功能设置不当同样会造成服务中断。 如上所述还只是个概要，对业务来说，对这些风险都是必须正 …","date":1547103600,"description":"本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-meetup-5-istio-retrospect/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"88553acdb286a68c44cc9bf390855f26","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","publishdate":"2019-01-10T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","summary":"崔秀龙，HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员。 本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整","tags":["Service Mesh"],"title":"企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/","wordcount":4050},{"author":"敖小剑","categories":"Serverless","content":" Knative 是Google 发起的 Serverless 项目，希望通过提供一套简单易用的 Serverless 开源方案，将 Serverless 标准化。 本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，PPT 获取地址：下载地址\n 前言 大家好，今天给大家来的演讲专题是“Knative：重新定义Serverless”, 我是来自蚂蚁金服中间件的敖小剑。\n这是我的个人资料，有兴趣的同学可以关注的我的个人技术博客网站 https://skyao.io\n这次演讲的内容将会有这些，首先给大家介绍一下 Knative 是什么，然后是 Knative 的主要组件，让大家对 Knative 有一个基本的了解。之后我会简单的对 Knative 做一些分析和探讨，以及介绍一下 Knative 后续的发展。希望本次的内容让大家能够对Knative有一个基本的认知。\n什么是 Knative？ Knative 是 Google 牵头发起的 Serverless 项目。\n这是Knative的项目定义，注意这句话里面几个关键字：Kubernetes，Serverless，Workload。\n这是最近几年 Google 做大型项目的常态：产品刚出来，阵营就已经很强大了，所谓先声夺人。\n是目前Knative项目的进展，可以看到这是一个非常新的项目，刚刚起步。\n 备注：这是截至2018-11-24演讲当天的情况，到2018年12月底，Knative已经发布了v0.2.2和v0.2.3两个bugfix版本。但也还只是 0.2 ……\n 我们来看一下，在Knative出来前， Serverless 领域已有的实现，包括云端提供的产品和各种开源项目。\n这幅图片摘自 The New Stack 的一个 Serverless 调查，我们忽略调查内容，仅仅看看这里列出来的 Serverless 产品的数量——感受是什么？好多Serverless项目，好多选择！\n那问题来了：到底该怎么选？\n这就是目前 Serverless 的问题：由于缺乏标准，市场呈现碎片化。不同厂商，不同项目，各不相同，因此无论怎么选择，都面临一个风险：供应商绑定！\n这段话来自 Knative 的官方介绍，Google 推出 Knative 的理由和动机。其中第一条和第二条针对的是当前 Serverless 市场碎片的现状。而第四条多云战略，则是针对供应商绑定的风险。\nGoogle 描述 Knative 的动机之一，是将云原生中三个领域的最佳实践结合起来。\n小结：\n当前 Serverless 市场产品众多导致碎片化严重，存在厂商绑定风险，而 Google 推出 Knative，希望能提供一套简单易用的 Serverless 方案，实现 Serverless 的标准化和规范化。\nKnative 的主要组件 第二部分，来介绍一下Knative的主要组件。\n前面提到，Google 推出 Knative ，试图将云原生中三个领域的最佳实践结合起来。反应到 Knative 产品中，就是这三大主要组件：Build，Serving，Eventing。\nKnative Build 组件，实现从代码到容器的目标。为什么不直接使用 dockfile 来完成这个事情？\nKnative Build 在实现时，是表现为 Kubernetes 的 CRD，通过 yaml 文件来定义构建过程。这里引入了很多概念如：Build，Builder，Step，Template，Source等。另外支持用 Service Account 做身份验证。\nKnative Serving 组件的职责是运行应用以对外提供服务，即提供服务、函数的运行时支撑。\n注意定义中的三个关键：\n Kubernetes-based：基于 k8s，也仅支持 k8s，好处是可以充分利用k8s平台的能力 scale-to-zero：serverless 最重要的卖点之一，当然要强调 request-driven compute：请求驱动的计算 值得注意的是，除了k8s之外，还有另外一个重要基础：istio！后面会详细聊这个。\nKnative Serving项目同样也提供了自己的中间件原语，以支持如图所示的几个重要特性。\nKnative中有大量的概念抽象，而在这之后的背景，说起来有些意思：Knative 觉得 kubernetes 和 istio 本身的概念非常多，多到难于理解和管理，因此 Knative 决定要自己提供更高一层的抽象。至于这个做法，会是釜底抽薪解决问题，还是雪上加霜让问题更麻烦……\nKnative的这些抽象都是基于 kubernetes 的 CRD 来实现，具体抽象概念有：Service、Route、Configuration 和 Revision。特别提醒的是，右边图中的 Service 是 Knative 中的 Service 概念，service.serving.knative.dev，而不是大家通常最熟悉的 k8s 的 service。\n对于 Knative Serving 组件，最重要的特性就是自动伸缩的能力。目前伸缩边界支持从0到无限，容许通过配置设置。\nKnative 目前是自己实现的 Autoscaler ，原来比较简单：Revision 对应的pod由 k8s deployment 管理，pod上的工作负载上报 metrics，汇总到 Autoscaler 分析判断做决策，在需要时修改 replicas 数量来实现自动伸缩（后面会再讲这块存在的问题）。\n当收缩到0，或者从0扩展到1时，情况会特别一些。Knative在这里提供了名为 Activator 的设计，如图所示：\n Istio Route 控制流量走向，正常情况下规则设置为将流量切到工作负载所在的pod 当没有流量，需要收缩到0时，规则修改为将流量切到 Activator ，如果一直没有流量，则什么都不发生。此时Autoscaler 通过 deployment 将 replicas 设置为0。 当新的流量到来时，流量被 Activator 接收，Activator 随即拉起 pod，在 pod 和工作负载准备好之后，再将流量转发过去 Knative Eventing 组件负责事件绑定和发送，同样提供多个抽象概念：Flow，Source，Bus，以帮助开发人员摆脱概念太多的负担（关于这一点，我保留意见）。\nBus 是对消息总线的抽象。\nSource 是事件数据源的抽象。\nKnative 在事件定义方面遵循了 Cloudevents 规范。\n小结：\n简单介绍了一下 Knative 中的三大组件，让大家对 Knative 的大体架构和功能有个基本的认知。这次就不再继续深入 Knative 的实现细节，以后有机会再展开。\nKnative分析和探讨 在第三部分，我们来分析探讨一下 Knative 的产品定位，顺便也聊一下为什么我们会看好 Knative。\n首先，最重要的一点是：Knative 不是一个 Serverless 实现，而是一个 Serviceless 平台。\n也就是说，Knative 不是在现有市场上的20 …","date":1546498800,"description":"本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，文中有 PPT 获取地址。","dir":"blog/serverless-knative-giac/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"21d3b124a0863acf6481463647b92095","permalink":"https://sofastack.github.io/sofastack.tech/blog/serverless-knative-giac/","publishdate":"2019-01-03T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/serverless-knative-giac/","summary":"Knative 是Google 发起的 Serverless 项目，希望通过提供一套简单易用的 Serverless 开源方案，将 Serverless 标准化。 本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，PPT 获取地址：下载","tags":["Serverless","Knative"],"title":"Knative：重新定义 Serverless | GIAC 实录","type":"blog","url":"/sofastack.tech/blog/serverless-knative-giac/","wordcount":3746},{"author":"余淮","categories":"SOFAStack","content":" 章耿，花名余淮，蚂蚁金服高级技术专家。 2007 年毕业后一直从事服务化相关的工作，最早在国家电网做电子商务平台 SOA 化的工作，之后在京东负责京东的服务化框架 JSF，目前在蚂蚁金服中间件服务与框架组负责应用框架及 SOFAStack 相关的工作。\n本文根据余淮在 2018 开源中国年终盛典的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 本次分享主要分为三部分： 蚂蚁金服服务化架构演进 蚂蚁金服微服务体系 蚂蚁金服 SOFAStack 的开源情况 1、蚂蚁金服服务化架构演进 在开始讲架构演进之前，我们先来看一组数据。 这是历年来的双十一数据图，柱状是双十一的交易额，从最初到20亿到去年的1682亿，今年是2135亿。而这个橙色的折线则是支付宝双十一 0 点的交易峰值，去年是 26.5w笔每秒，今年更高。从这两组数据可以看出蚂蚁的业务每年都是在高速增长，那技术面临的压力更是在不断的增长。但是最近几年，峰值虽然越来越大，但是大家有个体感，就是大促的购物体验更好了，再也不像以前系统会被大促搞挂，系统反而越来越稳了。\n而支撑这些数字的背后，是蚂蚁金融科技的一些核心技术，我们可以看到有三地五中心多活架构，分布式数据库 OceanBase，金融级分布式架构 SOFAStack，还有更多的一些黑科技，例如 Zoloz 生物识别，蚂蚁区块链，第五代智能风控引擎。\n相信大家都听过一句话 “罗马不是一天建成的”。蚂蚁金服科技的技术也不是最早就设计成这样，和所有的大公司发展一样，目前这些技术架构也是随着业务发展、系统的壮大，一步一步演进而来的。\n下面给大家介绍下蚂蚁金服的演进。\n这个是支付宝最早的架构示意图，可以看到当时支付宝只是电商后台的一个支付系统，是一个单体应用，里面简单的分了几个业务模块，连的也是一个数据库。但随着业务规模的不断扩展，单系统架构已经无法满足业务需求。\n所以支付宝就对大系统进行了拆分，将原来的一个单体应用内部的多个模块变成了多个独立的子系统，这算是典型的 SOA 化的架构。最开始系统之间是使用 F5 的硬件负载设备来做系统间的负载均衡，但由于 F5 设备存在单点的问题，所以后面就在中间引入一个注册中心的组件。服务提供者去注册中心注册服务，服务消费者去注册中心订阅服务列表，服务消费者通过软负载方式通过 RPC 框架直接调用服务提供者。这在现在看来是一种非常显而易见的服务化架构，但当时 07 年就采用这样的架构还是算比较超前的。 支付宝在做系统拆分的同时，对数据库也按子系统进行了垂直拆分。数据库的拆分就会引入分布式事务的问题，蚂蚁金服中间件就提供了基于 TCC 思想的 分布式事务组件 DTX。\n业务还是不断扩展，系统也越来越多，当系统节点到一定数量的时候，单个物理机房已经无法承受。另外考虑到同城容灾的问题，支付宝就在同城再扩建另外一个机房，通过专线部署为一个内部网络，然后将应用部署上去。同城多机房会引入一个跨机房远程访问的问题，相比同机房调用，这个延迟损耗一定是更高的。远程访问主要包括两种：RPC 调用和数据库访问。为了解决 RPC 跨机房调用的问题，支付宝的工程师选择的方案是在每个机房都部署注册中心，同机房优先调用本机房服务的方式，也就变成图中的部署模式。但是数据库跨机房访问的问题，在这个阶段并没有解决。\n为了解决上面的跨机房数据访问、数据库连接数瓶颈以及未来数据水平扩展的问题，蚂蚁的工程师们设计了一套单元化的架构，这是单元化的一个示意图。在没有单元化的时候，用户请求进入内部后，所有请求链路都是随机走的，例如图里的 S0 到 B1 到 C2 到 D0。首先蚂蚁的请求都是跟用户相关的，所以我们将数据按用户的维度进行水平分片，例如这张示意图我们将所有用户分为三组。然后我们将我们的应用也部署成三组独立的逻辑单元，每个逻辑单元的应用和数据都是独立的，相当于每个逻辑单元都处理1/3总量用户的数据。\n这个时候我们的三个不同终端的用户，不管是在PC端或者手机端或者扫二维码，当请求进入统一接入层的时候，接入层会按上面逻辑单元的分组规则，将用户请求转发到对应的逻辑单元，例如 user0 的请求转到 S0，后面的应用之间的调用、数据都只在逻辑单元 0 内。统一的 user1 只在逻辑单元 1，user2 也只到逻辑单元 2。\n我们把这种逻辑单元称之为 RegionZone。在实际的部署过程中，物理数据中心 IDC 和 逻辑单元的数量没有完全的对等关系。例如图中我们物理机房可以是两地三中心，而 RegionZone 则是分为五个。\n两地三中心是国家对金融机构的一个容灾指导方案，要求在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同时在异地（＞ 200KM ) 建立异地容灾中心。\n有了这套单元化的架构做指导思想，蚂蚁进行大规模的改造，包括应用改造、基础框架改造、数据中心的建设。\n机房建设完成后，同时蚂蚁金服将自己的用户分成了若干份，划了几个逻辑单元，分别部署进了不同的物理机房，同时完成大规模的数据迁移。\n从两地三中心到容灾能力更强大的三地五中心，我们只需要先进行第三个城市的机房建设，然后将部分 RegionZone 部署到第三个城市，最后再完成数据迁移和引流即可。\n每一个 RegionZone 在异地都有备份，当发生城市级的故障时，我们通过统一的管控中心将新的逻辑规则推送到统一接入层以及异地的备 RegionZone 时，就可以做到城市级的整体容灾切换。\n再后面我们基于单元化的思想做了更多弹性调度等能力，这里就不展开了。\n2015 年 9 月蚂蚁金融云对外正式发布，在今年 9 月的云栖大会，蚂蚁金融云正式升级为蚂蚁金融科技，并宣布技术全面对外开放，其中就包括金融级分布式架构 SOFAStack，左上角就是网址，感兴趣的朋友可以看下：https://tech.antfin.com/sofa\n云上的 SOFAStack 继承了蚂蚁金服内部的能力，有三大特点，分别是开放（全栈开放、开源共建）、云原生（异地多活、无限扩展）、金融级（资金安全、无损容灾），下面是一些核心能力大家可以看下。这一切就使得蚂蚁金服的微服务体系不仅仅在蚂蚁内部玩得转，也需要适应云上例如云原生、多租户等更复杂的场景。\n2、蚂蚁微服务体系 讲到微服务，大家就会看到或者脑子就跳出各种各样的词，例如 RPC 框架、服务安全、路由寻址等等。 除了这些以外，其实还有更多的服务归属、服务测试、服务编排等更多概念。\n那蚂蚁内部围绕微服务体系，也建设了很多的组件和框架对应这些微服务的概念点。\n这是一张蚂蚁内部微服务体系的一张简图，只列了部分主要组件，这些组件都是自研的，部分已经开源。可以看到有配置中心 DRM、注册中心 SOFARegistry，应用开发框架 SOFABoot，应用里的 RPC 框架、分布式链路跟踪组件 Tracer、监控度量组件 Lookout 等微服务组件，应用旁边是我们的 SOFAMosn，也就是 ServiceMesh 里的数据平面 SideCar，会将 RPC 里的路由、限流、鉴权等一些能力集成到这个组件里， …","date":1545030000,"description":"本文根据余淮在 2018 开源中国年终盛典的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/sofastack-oschina-2018/","fuzzywordcount":6600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e636d50f3f49170801c38118bf711adc","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-oschina-2018/","publishdate":"2018-12-17T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofastack-oschina-2018/","summary":"章耿，花名余淮，蚂蚁金服高级技术专家。 2007 年毕业后一直从事服务化相关的工作，最早在国家电网做电子商务平台 SOA 化的工作，之后在京东负责京东的服务化","tags":["微服务","开源","实践"],"title":"蚂蚁金服微服务实践- 2018 开源中国年终盛典分享实录","type":"blog","url":"/sofastack.tech/blog/sofastack-oschina-2018/","wordcount":6551},{"author":"颜洄、丞一","categories":"SOFABolt","content":" 1. 前言 为了让中间件开发者们将更多的精力投入到产品的功能特性上，而不是重复的写通信层框架，蚂蚁中间件团队设计并实现了SOFABolt。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。蚂蚁中间件的同学这些年在微服务和消息中间件上解决了很多网络通信的问题，积累了很多经验，并将这些经验、解决方案沉淀到了SOFABolt这个项目中，希望能让更多需要使用网络通信的团队、开发者受益。目前SOFABolt已经运行在蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n2. 主要特性 SOFABolt核心功能包括三大块：\n 网络通信能力 协议框架 私有协议实现 网络通信能力 网络通信能力（remoting-core）可以理解为Netty的最佳实践，并额外进行了一些优化工作，包含：\n 基于Netty的高效的网络IO于线程模型的应用 链接管理（无锁建连、定时断连、自动重连） 通信模型（oneway、sync、callback、future） 超时控制 批量解包和批量提交处理 心跳于IDLE机制 协议框架 协议框架（protocol-skeleton）包含命令处理器、编解码器等，是底层通信能力之上，具体私有协议之下，连接通信能力和私有协议的中间层。网络通信层是SOFABolt对Netty的封装和功能增强，协议框架则是SOFABolt对网络请求处理流程的抽象，是用户可以不关心底层细节快速实现自己的处理器来完成网络请求的处理逻辑，是用户可以进行拓展来实现自定义的私有协议的基础，也是本篇文章分析的内容。\n私有协议实现 由于性能、安全性等等的原因，很多中间件都会采用私有协议进行通信。SOFABolt除了提供基础的通信能力、协议框架之外，还提供了默认的RPC协议的实现，这样它就是一个完整的通信框架，用户可以不关心协议而直接上手使用。本篇文章主要分析SOFABolt的协议框架的设计和实现，不展开对SOFABolt中的RPC协议实现做介绍。\n3. 协议框架 协议框架整体如下：\n Command：协议命令，通讯数据的顶层抽象。从交互的角度可以分为Request（请求）于Response（响应），从功能的角度，分为负载命令（交换业务数据）和控制命令（进行系统的管理、协调等）。 CommandEncoder/CommandDecoder：协议命令的编解码器，自定义协议实现的基础，编解码器完成对象和字节数组之间的相互转换。 CommandHandler：协议命令的处理器，命令处理入口，负责分发、处理命令。 CommandFactory：协议命令工厂类，负责创建协议命令对象。 HeartbeatTrigger：心跳的处理器，用户用户拓展特定的心跳机制的处理。 下面以SOFABolt中默认实现的RPC协议为例来介绍SOFABolt协议框架的实现。 3.1 请求的处理流程 一个请求处理流程大致如下：\n 通过CommandFactory构建请求对象 通过CommandEncoder对请求对象进行编码，写入到网络连接 服务端从连接中读取数据，通过CommandDecoder解析成请求对象 CommandHandler接收请求对象，进行分发和处理 CommandFactory是一个工厂类，比较简单，不展开介绍。编解码相关内容见《SOFABolt编解码机制》。下面介绍一下CommandHandler对请求的分发和处理。\n上面是SOFABolt中RpcHandler的代码片段，这段代码是命令处理的入口：\n 首先从连接的上下文中获取使用的协议的版本ProtocolCode 再根据ProtocolCode从ProtocolManager中获取具体的协议 之后从协议中获取CommandHandler，并构造请求的上下文信息和请求的对象（代码片段中的msg）提交处理 上面的处理逻辑中透露出一个信息：SOFABolt支持同时运行多个版本的协议，通过ProtocolCode来区分协议。这一点可以使得系统在做升级或重构时，需要同时支持新老系统不同协议时变得简单。\n上面是CommandHandler的代码片段，透露出的信息是SOFABolt支持批量提交请求，这在《SOFABolt编解码机制》一文中也有部分介绍。而具体的process流程如下：\n通过Command对象获取CommandCode，根据CommandCode获取对应的RemotingProcessor进行处理。 CommandCode是一个接口，只有一个返回short的value()方法，表示Command的具体类型，每个请求都需要有自己的CommandCode来标识自己的类型。框架通过一个Map来维护CommandCode和RemotingProcessor的关系，每个CommandCode需要有对应的RemotingProcessor进行处理，一个RemotingProcessor可以处理多个CommandCode的请求。\n再往下看一层，请求会被提交到RemotingProcessor中处理。上面是RpcRequestProcessor处理请求的代码片段，处理流程中会通过cmd.getRequestClass()来获取请求的对象的Class名称，再获取对应的UserProcess进行处理（具体处理不再上面的代码片段中）。 对用户来说，只需要实现自己的Command对象、实现自己的UserProcessor并注册到ProcessorManager中，就可以完成自己的网络通信。 以上是一个请求在SOFABolt的协议框架下的处理流程和核心代码的分析。\n3.2 协议框架的拓展机制 通过对请求处理流程的分析可以感受到SOFABolt的协议框架是支持多协议版本运行，能直接使用，也支持进行拓展来实现更丰富和定制化的功能。下面具体介绍SOFABolt的拓展机制。\n上图是RemotingCommand在处理过程中的路由示意图。第一层路由根据ProtocolCode进行，第二层路由根据CmdCode进行，第三层路由则根据RequestClass进行。用户可以在每一层进行扩展来实现自己的处理。 这种设计具有很好的拓展性和灵活性，ProtocolCode用于区分“大版本”的协议，适用于协议发生较大的变化的场景。CmdCode则标识请求类型，比如在RPC场景中CmdCode可能就两个：RPC_REQUEST、RPC_RESPONSE，而在消息场景中CmdCode可能会更丰富一些，比如有发送消息、批量发送消息、投递消息等等。RequestClass是Command上承载的数据的类型，用户根据不同的类名进行不同的业务逻辑的实行。\n实际应用中，以RPC的场景为例，用户更多的是去实现UserProcessor来完成不同的业务逻辑的处理。而在消息的场景中，因为消息承载的是二进制的数据，所以请求的数据类型是固定的，系统更多的是拓展CmdCode来执行不同类型的请求的处理，比如心跳请求的处理、写入消息的处理、批量写入消息的处理等等。SOFABolt协议框架的设计和实现，具备较好的可拓展性，使其能应用于蚂蚁 …","date":1544091600,"description":"本文是对蚂蚁金服开源通信框架 SOFABolt 的协议框架解析。","dir":"blog/sofa-bolt-framework-deep-dive/","fuzzywordcount":3900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"67335ca275995497a5f28340cb13f45b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","summary":"1. 前言 为了让中间件开发者们将更多的精力投入到产品的功能特性上，而不是重复的写通信层框架，蚂蚁中间件团队设计并实现了SOFABolt。 Bolt 名字取","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架 SOFABolt 协议框架解析","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-framework-deep-dive/","wordcount":3889},{"author":"鲁道","categories":"SOFABolt","content":" 前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将重点分析 SOFABolt 的序列化机制。\n我们知道，但凡在网络中传输数据，都涉及到序列化以及反序列化。即将数据编码成字节，再把字节解码成数据的过程。\n例如在 RPC 框架中，一个重要的性能优化点是序列化机制的设计。即如何为服务消费者和和服务提供者提供灵活的，高性能的序列化器。\n这里说的序列化器，不仅仅是指“对象”的序列化器，例如 Hessian，Protostuff，JDK 原生这种“对象”级别的序列化器，而是指“协议”级别的序列化器，“对象”的序列化只是其中一部分。通常“协议”级别的序列化器包含更多的信息。\n下面我们将先从 SOFABolt 的设计及实现入手，进而分析 SOFABolt 详细的序列化与分序列化流程，最后介绍 SOFABolt 序列化扩展。\n设计及实现 一个优秀的网络通信框架，必然要有一个灵活的，高性能的序列化机制。那么，SOFABolt 序列化机制的设计目标是什么呢？具体又是如何设计的呢？\n首先说灵活，灵活指的是，框架的使用方（这里指的是网络通信框架的使用方，例如 RPC，消息中心等中间件）能够自定义自己的实现，即用户决定使用什么类型的序列化以及怎么序列化。\n再说高效，序列化和反序列化事实上是一个重量级的操作，阿里 HSF 作者毕玄在著名的 NFS-RPC框架优化过程（从37k到168k） 文章中提到，其优化 RPC 传输性能的第一步就是调整反序列化操作，从而将 TPS 从 37k 提升到 56k。之后又通过更换对象序列化器，又将 TPS 提升了将近 10k。由此可见，合理地设计序列化机制对性能的影响十分巨大。\n而 SOFABolt 和 HSF 有着亲密的血缘关系，不但有着 HSF 的高性能，甚至在某些地方，优化的更为彻底。\n我们现在可以看看 SOFABolt 序列化设计。\n接口设计 SOFABolt 设计了两个接口：\n Serializer 该接口定义 serialize 方法和 deserialize 方法，用于对象的序列化和反序列化。 CustomSerializer 该接口定义了很多方法，主要针对自定义协议中的 header 和 content 进行序列化和反序列化。同时提供上下文，以精细的控制时机。 同时，从框架设计的角度说，他们可以称之为 “核心域”， 他们也被对应的 “服务域” 进行管理。\n这里解释一下服务域和核心域，在框架设计里，通常会有“核心域”，“服务域”， “会话域” 这三部分组成。\n例如在 Spring 中，Bean 就是核心域，是核心领域模型，所有其他模型都向其靠拢；而 BeanFactory 是服务域，即服务“核心域”的模型，通常长期存在于系统中，且是单例；“会话域” 指的是一次会话产生的对象，会话结束则对象销毁，例如 Request，Response。\n在 SOFABolt 序列化机制中，Serializer 和 CustomSerializer 可以认为是核心域，同时，也有服务于他们的 “服务域”，即 SerializerManager 和 CustomSerializerManager。“会话域” RpcCommand 依赖 “服务域” 获取 “核心域” 实例。\nUML 设计图如下：\n其中红色部分就是 SOFABolt 序列化机制的核心接口，同时也是用户的扩展接口，他们被各自的 Manager 服务域进行管理，最后，会话域 RpcCommand 依赖着 Manager 以获取序列化组件。\n这两个接口的使用场景通常在数据被 协议编解码器 编码之前或解码之后，进行处理。\n例如在发送数据之前，协议编码器 根据通信协议（如 bolt 协议）进行编码，编码之前，用户需要将数据的具体内容进行序列化，协议编解码器 再进行更详细的编码。\n同样，协议解码器 在接收到 Socket 发送来的字节后，根据协议将字节解码成对象，但是，对象的内容还是字节，需要用户进行反序列化。\n一个比较简单的流程图就是这样的:\n上图中，假设场景是 Client 发送数据给 Server，那么，编解码器负责将字节流解码成 Command 对象，序列化器负责将 Command 对象里的内容反序列化成业务对象，从设计模式的角度看，这里是 GOF 中 “命令模式”和“职责链模式”的组合设计。\n看完了设计，再看看实现。\n接口实现 我们可以看看这两个接口的实现。\n Serializer Serializer 接口在 SOFABolt 中已有默认实现，即 HessianSerializer，目前使用的是 hessian-3.3.0 版本。通过一个 SerializerManager 管理器进行管理。注意，这个管理器内部使用的是数组，而不是 Map，这在上文毕玄的文章也曾提到：通过使用数组替换成 Map，NFS-RPC 框架的 TPS 从 153k 提升到 160k。事实上，任何对性能非常敏感的框架，能用数组就绝不用 Map，例如 Netty 的 FastThreadLocal，也是如此。\n当然，Serializer 接口用户也是可以扩展的，例如使用 protostuff，FastJson，kryo 等，扩展后，通过 SerializerManager 可以将自己的序列化器添加到 SOFABolt 中。注意：这里的序列化 type 实际就是上面提到的数组的下标，所以不能和其他序列化器的下标有冲突。\n CustomSerializer 再说 CustomSerializer，这个接口也是有默认实现的，用户也可以选择自己实现，我们这里以 SOFARPC 为例。\nSOFARPC 在其扩展模块 sofa-rpc-remoting-bolt 中，通过实现 CustomSerializer 接口，自己实现了序列化 header，content。\n这里稍微扩展讲一下 header 和 content。实际上，header 和 content 类似 http 协议的消息头和消息体，header 和 content 中到底存放什么内容，取决于协议设计者。\n例如在 SOFARPC 的协议中，header 里存放的是一些扩展属性和元信息上下文。而 content 中存放的则是主要的一些信息，比如 request 对象，request 对象里就存放了 RPC 调用中常用信息了，例如参数，类型，方法名称。\n同时，CustomSerializer 接口定义的方法中，提供了 InvokeContext 上下文，例如是否泛化调用等信息，当进行序列化时，将是否泛型的信息放入上下文，反序列化时，再从上下文中取出该属性，即可正确处理泛化调用。\n注意，如果用户已经自己实现了 CustomSerializer 接口，那么 SOFABolt 的 SerializerManager 中设置的序列化器将不起作用！因为 SOFABolt 优先使用用户的序列化器。\n具体代码如下：\n行文至此，讨论的都是“灵活”这个设计，即用户既可以使用 SOFABolt …","date":1544091600,"description":"SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架，本文将重点分析 SOFABolt 的序列化机制。","dir":"blog/sofa-bolt-serialization-deep-dive/","fuzzywordcount":4700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2145bb681760cdf3d1953bf4ed75fa60","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":10,"relpermalink":"/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","summary":"前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之序列化机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/","wordcount":4630},{"author":"水寒","categories":"SOFABolt","content":" 基础介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生。 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，积累了很多经验，并持续的进行着优化和完善，我们希望能把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。 目前该产品已经运用在了蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n前言 SOFABolt 提供了设计良好、使用便捷的编解码功能。本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。欢迎大家与我们讨论交流。\n编解码介绍 每个网络应用程序都必须定义如何解析在两个节点之间来回传输的原始字节，以及如何将其和目标应用程序的数据格式做相互转换。在一个成熟的通信框架中，我们通常都会通过私有通信协议来描述这种定义，通过编解码技术将理论上的私有通信协议转化为实践。\n通过编解码技术，我们可以方便的做一些逻辑，例如双方可以方便的统一序列化与反序列化方式、解决 TCP 拆包粘包问题等。\n下面，我们先来看一下 TCP 粘包拆包问题的产生，然后分析 Netty 是如何解决粘包拆包问题的，最后分析 SOFABolt 是如何解决粘包拆包问题的。\nTCP 粘包拆包问题 如上图所示，三种拆包原因见黄色标签说明；两种粘包原因见蓝色标签说明。TCP 本身是面向流的，它无法从源源不断涌来的数据流中拆分出或者合并出有意义的信息，通常可以通过以下几种方式来解决：\n 基于分隔符协议：使用定义的字符来标记一个消息的结尾，在编码的时候我们在消息尾部添加指定的分隔符，在解码的时候根据分隔符来拆分或者合并消息。Netty 提供了两种基于分隔符协议的解码器 LineBasedFrameDecoder 和 DelimiterBasedFrameDecoder。LineBasedFrameDecoder 指定以 \\n 或者 \\r\\n 作为消息的分隔符；DelimiterBasedFrameDecoder 使用用户自定义的分隔符来标记消息的结尾。 基于定长消息协议：每一个消息在编码的时候都使用固定的长度，在解码的时候根据这个长度进行消息的拆分和合并。Netty 提供了 FixedLengthFrameDecoder 解码器来实现定长消息解码。 基于变长消息协议：每一个消息分为消息头和消息体两部分，在编码时，将消息体的长度设置到消息头部，在解码的时候，首先解析出消息头部的长度信息，之后拆分或合并出该长度的消息体。Netty 提供了 LengthFieldBasedFrameDecoder 来实现变长消息协议解码。 基于私有通信协议：Netty 提供了 MessageToByteEncoder 和 ByteToMessageDecoder 两个抽象类，这两个抽象类提供了基本的编解码模板。用户可以通过继承这两个类来实现自定义的编解码器。SOFABolt 通过继承 MessageToByteEncoder 实现了自定义的编码器，通过继承修改版的 ByteToMessageDecoder 来实现了解码器。对于处理 TCP 粘包拆包问题，SOFABolt 实际上也是使用变长消息协议，SOFABolt 的私有通信协议将消息体分为三部分 className、header、body，在消息头对应的提供了 classLen、headerLen、bodyContent 分别标识三部分的长度，之后就可以基于这三个长度信息进行消息的拆分和合并。 对于一个成熟的 rpc 框架或者通信框架来讲，编解码器不仅仅是要处理粘包拆包问题，还要实现一些特有的需求，所以必须制定一些私有通信协议，下面来看一下 SOFABolt 的私有通信协议的设计。\nSOFABolt 私有通信协议的设计 以下分析以 SOFABolt 1.5.1 版本为例。SOFABolt 定义了两种协议 RpcProtocol 和 RpcProtocolV2。针对这两种协议，提供了两组不同的编解码器。\n RpcProtocol 协议定义 请求命令（协议头长度：22 byte） ProtocolCode ：这个字段是必须的。因为需要根据 ProtocolCode 来进入不同的核心编解码器。该字段可以在想换协议的时候，方便的进行更换。 RequestType ：请求类型，request / response / oneway 三者之一。oneway 之所以需要单独设置，是因为在处理响应时，需要做特殊判断，来控制响应是否回传。 CommandCode ：请求命令类型，request / response / heartbeat 三者之一。 CommandVersion ：请求命令版本号。该字段用来区分请求命令的不同版本。如果修改 Command 版本，不修改协议，那么就是纯粹代码重构的需求；除此情况，Command 的版本升级，往往会同步做协议的升级。 RequestId ：请求 ID，该字段主要用于异步请求时，保留请求存根使用，便于响应回来时触发回调。另外，在日志打印与问题调试时，也需要该字段。 Codec ：序列化器。该字段用于保存在做业务的序列化时，使用的是哪种序列化器。通信框架不限定序列化方式，可以方便的扩展。 Timeout ：超时字段，客户端发起请求时，所设置的超时时间。 ClassLen ：业务请求类名长度 HeaderLen ：业务请求头长度 ContentLen ：业务请求体长度 ClassName ：业务请求类名。需要注意类名传输的时候，务必指定字符集，不要依赖系统的默认字符集。曾经线上的机器，因为运维误操作，默认的字符集被修改，导致字符的传输出现编解码问题。而我们的通信框架指定了默认字符集，因此躲过一劫。 HeaderContent ：业务请求头 BodyContent ：业务请求体 响应命令（协议头长度：20 byte） ResponseStatus ：响应码。从字段精简的角度，我们不可能每次响应都带上完整的异常栈给客户端排查问题，因此，我们会定义一些响应码，通过编号进行网络传输，方便客户端定位问题。 RpcProtocolV2 协议定义 请求命令（协议头长度：24 byte） ProtocolVersion ：确定了某一种通信协议后，我们还需要考虑协议的微小调整需求，因此需要增加一个 version 的字段，方便在协议上追加新的字段 Switch ：协议开关，用于一些协议级别的开关控制，比如 CRC 校验， …","date":1544091600,"description":"本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。","dir":"blog/sofa-bolt-codec-deep-dive/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9383bfa0b8c9975e3d4b2ed4bc01a593","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","summary":"基础介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之编解码机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-codec-deep-dive/","wordcount":3909},{"author":"胡萝卜、丞一","categories":"SOFABolt","content":" 前言 SOFABolt 是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将分析SOFABolt的超时控制和心跳机制。\n超时 在程序中，超时一般指的是程序在特定的等待时间内没有得到响应，网络通信问题、程序BUG等等都会引起超时。系统引入超时机制往往是为了解决资源的问题，比如一个同步RPC请求，在网络不稳定的情况下可能一直无法得到响应，那么请求线程将一直等待结果而无法执行其它任务，最终导致所有线程资源耗尽。超时机制正是为了解决这样的问题，在特定的等待时间之后触发一个“超时事件”来释放资源。\n在一个网络通信框架中，超时问题无处不在，连接的建立、数据的读写都可能遇到超时问题。并且网络通信框架作为分布式系统的底层组件，需要管理大量的连接，如何建立一个高效的超时处理机制就成为了一个问题。\n时间轮（TimeWheel） 在网络通信框架中动辄管理上万的连接，每个连接上都有很多的超时任务，如果每个超时任务都启动一个java.util.Timer，不仅低效而且会占用大量的资源。George Varghese 和 Tony Lauck在1996年发表了一篇论文：《Hashed and Hierarchical Timing Wheels: EfficientData Structures for Implementing a Timer Facility》来高效的管理和维护大量的定时任务。\n时间轮其实就是一种环形的数据结构，可以理解为时钟，每个格子代表一段时间，每次指针跳动一格就表示一段时间的流逝（就像时钟分为60格，秒针没跳动一格代表一秒钟）。时间轮每一格上都是一个链表，表示对应时间对应的超时任务，每次指针跳动到对应的格子上则执行链表中的超时任务。时间轮只需要一个线程执行指针的“跳动”来触发超时任务，且超时任务的插入和取消都是O(1)的操作，显然比java.util.Timer的方式要高效的多。\nSOFABolt的超时控制机制 如上图所示，SOFABolt中支持四中调用方式：\n oneway：不关心调用结果，所以不需要等待响应，那么就没有超时 sync：同步调用，在调用线程中等待响应 future：异步调用，返回future，由用户从future中获取结果 callback：异步调用，异步执行用户的callback 在oneway调用中，因为并不关心响应结果，所以没有超时的概念。下面具体介绍SOFABolt中同步调用（sync）和异步调用（future\\callback）的超时机制实现。 同步调用的超时控制实现 同步调用中，每一次调用都会阻塞调用线程等待服务端的响应，这种场景下同一时刻产生最大的超时任务取决于调用线程的数量。线程资源是非常昂贵的，用户的线程数是相对可控的，所以这种场景下，SOFABolt使用简单的java.util.concurrent.CountDownLatch来实现超时任务的触发。\nSOFABolt同步调用的代码如上，核心逻辑是：\n 创建InvokeFuture 在Netty的ChannelFuture中添加Listener，在写入操作失败的情况下通过future.putResponse方法修改Future状态（正常服务端响应也是通过future.putResponse来改变InvokeFuture的状态的，这个流程不展开说明） 写入出现异常的情况下也是通过future.putResponse方法修改Future状态 通过future.waitResponse来执行等待响应 其中和超时相关的是future.waitResponse的调用，InvokeFuture内部通过java.util.concurrent.CountDownLatch来实现超时触发。 java.util.concurrent.CountDownLatch#await(timeout, timeoutUnit) 方法实现了等待一段时间的逻辑，并且通过countDown方法来提前中断等待，SOFABolt中InvokeFuture通过构建new CountDownLatch(1)的实例，并将await和countDown方法包装为awaitResponse和putResponse来实现同步调用的超时控制。\n异步调用的超时控制实现 相对于同步调用，异步调用并不会阻塞调用线程，那么超时任务的数量并不受限于线程对的数量，用户可能通过一个线程来触发量大的请求，从而产生大量的定时任务。那么我们需要一个机制来管理大量的定时任务，并且作为系统底层的通信框架，需要保证这个机制尽量少的占用资源。上文已经提到TimeWheel是一个非常适合于这种场景的数据结构。\nNetty中实现了TimeWheel数据结构：io.netty.util.HashedWheelTimer，SOFABolt异步调用的超时控制直接依赖于Netty的io.netty.util.HashedWheelTimer实现。\nFuture模式和Callback模式在超时控制机制上一致的，下面以Callback为例分析异步调用的超时控制机制。\nSOFABolt异步调用的代码如上，核心逻辑是：\n 创建InvokeFuture 创建Timeout实例，Timeout实例的run方法中通过future.putResponse来修改InvokeFuture的状态 在Netty的ChannelFuture中添加Listener，在写入操作失败的情况下通过future.cancelTimeout来取消超时任务，通过future.putResponse来修改InvokeFuture的状态 在写入异常的情况下同样通过future.cancelTimeout来取消超时任务，通过future.putResponse来修改InvokeFuture的状态 在异步调用的实现中，通过Timeout来触发超时任务，相当于同步调用中的java.util.concurrent.CountDownLatch#await(timeout, timeoutUnit)。Future#cancelTimeout()方法则是调用了Timeout的cancel来取消超时任务，相当于同步调用中通过 java.util.concurrent.CountDownLatch#countDown() 来提前结束超时任务。具体超时任务的管理则全部委托给了Netty的Timer实现。 另外值得注意的一点是SOFABolt在使用Netty的Timer时采用了单例的模式，因为一般情况下使用一个Timer管理所有的超时任务即可，这样可以节省系统的开销。 Fail-Fast机制 以上关于SOFABolt的超时机制介绍都是关于SOFABolt客户端如何完成高效的超时任务管理的，其实在SOFABolt的服务端同样针对超时的场景做了优化。\n客户端为了应对没有响应的情况，增加了超时机制，那么就可能存在服务端返回一个响应但是客户端在收到这个响应之前已经认为请求超时了，移除了相关的请求上下文，那么这个响应对客户端来说就没有意义 …","date":1544091600,"description":"本篇我们会依次介绍编解码的概念， TCP 粘包拆包问题，SOFABolt 私有通信协议的设计，以及SOFABolt 编解码原理，最后还会介绍一下相较于 Netty，我们做出的优化。","dir":"blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8f3ab1ecc952a0fc5ea40576e8b57471","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","summary":"前言 SOFABolt 是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之超时控制机制及心跳机制","type":"blog","url":"/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/","wordcount":4303},{"author":"任展","categories":"SOFABolt","content":" 前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多产品上。\n本文将重点分析 SOFABolt 的连接管理功能。\n我们知道，一次 tcp 请求大致分为三个步骤：建立连接、通信、关闭连接。每次建立新连接都会经历三次握手，中间包含三次网络传输，对于高并发的系统，这是一笔不小的负担；关闭连接同样如此。为了减少每次网络调用请求的开销，对连接进行管理、复用，可以极大的提高系统的性能。\n下面我们将介绍 SOFABolt 在连接管理的实现，包括连接生命周期管理、定时断连及自动重连等。\n设计抽象 首先我们将会介绍 SOFABolt 对连接的封装抽象。\n连接封装 SOFABolt 中定义了一个基础的连接类 \u0026amp;ndash; Connection:\n省去 AtributeKey 类型定义以及 Log 配置，以上是Connection中所有的成员变量。包括几个方面:\n 连接：Channel、Url 版本：protocolCode、version 调用：invokeFutureMap 附着：attributes 引用：referenceCount、id2PoolKey、poolKeys 这里提一下 protocolCode 和 version，版本信息会被携带至对端，用于连接的协商。总的来说，通过对于 Channel 的包装，Connection 提供了丰富的上下文及引用信息，是 SOFABolt 连接管理的直接对象。\n连接事件 SOFABolt 定义了连接事件和事件监听器用于处理连接对象。ConnectionEventType 定义了三种事件类型：CONNECT, CLOSE 和 EXCEPTION. 针对不同的连接事件类型，我们可以通过事件监听器 \u0026amp;ndash; ConnectionEventListener 来进行处理，下面来看一下 ConnectionEventListener 类：\n监听器定义了两个方法 onEvent 和 addConnectionEventProcessor, 分别是触发事件和添加事件处理器。整个监听器采用一个 HashMap 来存储事件类型及其对应的处理器集合。在触发相关连接事件后，会遍历处理器集合并调用处理器执行。\nSOFABolt 的连接管理集中在 ConnectionEventHandler 中处理，他继承了 ChannelDuplexHandler，是标准的用来处理Connection连接对象并进行日志打印的一个处理器。先来看一下成员组成：\n其中连接事件监听器上文已经提及，剩下的几个成员从名称上也通俗易懂，先简单介绍一下，后续会详细地展开：\n 连接管理器：管理连接对象，包括创建、添加、删除、检查是否可用等等 连接事件监听器：监听连接事件的触发，然后执行对应的逻辑 连接事件执行器：包装后的线程池，用于异步触发连接事件监听器来处理对应的连接事件，值得一提的是，这个线程池只有一个线程。 重连管理器：顾名思义，管理重连的Url对象以及执行重连任务 全局开关：全局的设置，比如是否需要管理连接对象、是否需要执行重连任务等等 代码中方法都比较简单，大部分的处理逻辑围绕 Connection 对象展开，主要是维护有关本 Channel 对象的 Connection 对象的生命周期(包括connect、close等事件)。下面着重分析两个方法：\nhannelInactive 方法是在连接断开前触发的方法，在 SOFABolt 里的处理逻辑中，会根据globalSwitch 中 CONN_RECONNECT_SWITCH 的开关状态来判定是否开启重连的任务。除此之外，会在最后触发该 Connection 对象的 CLOSE 事件。这个触发事件是在异步线程中执行的，也就是上文提到的连接事件执行器。\n另一个是 userEventTriggered 方法， 用来触发自定义的用户事件，通过查看本方法的调用位置，可以得知，该方法是在连接建立的最初被触发的，一个简单的例子可以在RpcServer类中找到：\n在连接建立触发 fireUserEventTriggered 方法后，我们就开始执行对应此方法中的逻辑，也可以看到，在判定是 CONNECT 事件后，通过attr得到绑定在Channel的Connection对象，然后就同 channelInactive 方法一样，触发 CONNECT 事件异步执行对应的处理器逻辑。\n连接管理 下面来介绍 ConnectionManager，SOFABolt 提供了默认的实现类 DefaultConnectionManager类。顾名思义，主要负责连接对象的管理：\n 通过工厂创建 Connection 连接对象 通过注入的选择策略进行 Connection 连接的选择 管理创建和添加的 Connection 对象和 ConnectionPool 连接池对象（包括检查 Connection 对象、维护 ConnectionPool 的健壮性） 控制 Connection 对象的心跳打开与关闭 创建连接 ConnectionFactory 用于创建连接对象，SOFABolt 提供了两个实现类： DefaultConnectionFactory 和 RpcConnectionFactory。这个工厂类执行了客户端所有 Connection 对象的创建工作，代码也比较简单：\n注意到了吗，在创建完毕 Connection 对象后，执行了 fireUserEventTriggered 方法，这样就保证了每一个 Connection 对象在创建之后都会去触发 CONNECT 事件。\n选择连接 ConnectionSelectStrategy 选择策略的默认实现是随机策略 RandomSelectStrategy, 在执行选择连接时大致分为两步：\n 在开启CONN_MONITOR_SWITCH监控时，会从该连接池所有的连接中做一个简单的filter操作，把CONN_SERVICE_STATUS为ON的连接挑选出来，作为选择池。如果没有开启监控，那么选择池就是连接池。 执行挑选策略，获取选择池中的一个连接。 管理连接和连接池 管理连接和连接池是 ConnectionManager 最主要的作用，用来进行连接和连接池的生命周期管理，包括添加、删除、检查健康、恢复连接数等功能。下面先看一个在添加中常见的方法，用来获取一个连接池对象或者创建一个，限于篇幅，这里不贴代码，有兴趣的同学可以在 GitHub 上查看源码。在执行创建连接池对象时，会有两种逻辑:\n 返回空的连接池 返回一个初始化过的连接池(有一定的连接数) 这两种逻辑其实对应的是两种需求，第一个对应连接已经创建好然后放入连接池的流程，第二个则是对应通过 Url 来创建一个连接池并且在连接池中做新建连接的流程。那么对于第二种情况，由于建立连接需要耗时且有可能抛出异常，所以 ConnectionManager 允许重试两次。\n下面来说说对于连接和连接池的维护方面的功能， …","date":1544091600,"description":"本文将重点分析 SOFABolt 的连接管理功能。","dir":"blog/sofa-blot-connection-management-deep-dive/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"99733a6333604b8aeb8ada37d5705d36","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","publishdate":"2018-12-06T10:20:00Z","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","summary":"前言 SOFABolt 是一款基于 Netty 最佳实践，通用、高效、稳定的通信框架。目前已经运用在了蚂蚁中间件的微服务，消息中心，分布式事务，分布式开关，配置中心等众多","tags":["SOFABolt","SOFALab","剖析 | SOFABolt 框架"],"title":"蚂蚁金服开源通信框架SOFABolt解析之连接管理剖析","type":"blog","url":"/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/","wordcount":3490},{"author":"奕杉","categories":"Service Mesh","content":" 朵晓东，花名奕杉，蚂蚁金服高级技术专家。专注企业云计算技术及产品，蚂蚁金融云 PaaS 创始团队核心成员，Antstack 网络产品负责人。开源爱好者，Apache Kylin 创始团队核心成员；SOFAMesh 创始团队核心成员，SOFAMosn 项目负责人。 本文根据晓东在 GIAC 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，我是蚂蚁金服系统部的高级技术专家奕杉，今天分享的内容是: 《蚂蚁金服在 ServiceMesh 推进落地过程中对新型网络代理的思考和实践》\n内容结构： 主要的分享顺序：\n 背景概述 架构设计及功能特性 技术案例 总结展望 1、背景、概览 ServiceMesh 作为云原生之上的服务网格技术在今年引起了业界的广泛关注，首先我们来看一下目前 ServiceMesh 数据平面的一些方案。\n最为大家熟知的是老牌七层代理 Nginx 和 ISTIO 原生的数据平面 Envoy。Nginx 早已在国内外广泛使用，近两年积极探索 K8S、ServiceMesh 微服务场景，并推出了与 ISTIO 集成的微服务解决方案，试图扩展其场景边界，拿下新的领域，从单纯的7层流量代理到云原生时代的智能数据平面转型。但目前看 “NgMesh”研发不够活跃，已知的使用方也不多。Envoy 作为 Google 和 Lyft联合开发的 ISTIO 原生数据平面产品，近两年借助 ServiceMesh 微服务场景快速打开了市场，并在一些互联网公司推广使用，同时引入了一批开发者进行 API 网关等功能网关的开发，发展势头非常好。\n其次 LINKERD 是基于 Rust 的一种高性能数据平面，但其发展空间受到了 Envoy 挤压，业界使用的公司也比较有限。\n蚂蚁金服基于自身诉求自研了基于 Golang 的数据平面 SOFAMosn（后简称MOSN），并在蚂蚁、UC 等公司落地使用。 同时对业界开源，提供了一种新的数据平面产品选择。\n此外国内的华为、新浪等公司都基于自身场景提出了数据平面方案并先后进行了开源，数据平面竞争已经从独霸业界的基于 Nginx 二开方案逐步转变为目前的多样化产品同场竞技的局面。\n为什么众多大厂纷纷投入研发数据平面呢？\n我个人认为新生技术栈、云原生、微服务快速发展等契机对数据平面提出了场景多样化、功能服务化、云原生亲和等多重挑战。\n以往从未像现在这样对数据平面提出过如此多的要求：\n 数据平面需要执行部署运维中的流量切换； 需要提供云亲和的细粒度流量调度功能； 需要提供微服务亲和的服务发现、路由组网特性； 需要以云原生的方式感知资源； 需要支撑服务粒度、高度自定义的压测、故障测试、线上灰度流量管理； 需要提供链路级、服务级的安全隔离保护，需要支持多种语言、多种协议的转换分发能力； 需要能享受系统层面、硬件层面的红利； 需要为复杂的运维架构（如蚂蚁的 LDC 等）提供可扩展的流量调拨能力等等； 当然根据每个公司的业务场景可能还有其他的因素。 最后，如何要将这些能力都汇聚在统一的数据平面产品上，弥合南北向、东西向数据平面由于技术栈、团队等差异带来的鸿沟，变成了另一个更为复杂的问题。这里所提到的问题中任何一点扩展开来都可以是一个丰富独立的 Topic，受限于篇幅本次分享只能介绍我们在解决这些问题中的一小部分思考和实践。\n2、SOFAMesh 架构 \u0026amp;amp; 重点特性 首先，蚂蚁已经将基于 ISTIO 的 ServiceMesh 方案 \u0026amp;ldquo;SOFAMesh\u0026amp;rdquo; 开源，在控制面我们选择克隆 ISTIO 官方版本并研发符合蚂蚁需求的控制面，在数据面我们选择使用 Golang 研发数据平面 MOSN，目前已经支持了微服务场景所需的大量常用功能。\n这里我根据 ISTIO 的 Task 文档总结了目前 SOFAMesh 支持的一些能力，如：透明拦截适配，细粒度的流控，故障注入，双向链路加密等。对于一些暂时存疑的功能，如 Mixer Check 等，暂时没有支持。目前 SOFAMesh 已在 UC 生产环境落地使用，满足了 Sidecar、Ingress、Egress 多种场景的使用需求。在这里附上 SOFAMesh，SOFAMosn 的 Github 地址，也欢迎大家使用交流。\nSOFAMesh: https://github.com/alipay/sofa-mesh SOFAMosn: https://github.com/alipay/sofa-mosn\n再来看看蚂蚁内部，由于目前蚂蚁生产环境尚未大量铺开K8S，并且已经存在一套完善的管控技术体系，加上目前ISTIO 的性能和稳定性还不满足大规模微服务场景等原因，我们暂时没有选择直接升级到 ISTIO，而是通过优先落地Sidecar 的方式来赢得 ServiceMesh 解决方案带来的红利。在蚂蚁内部，MOSN 接管了SOFABoot 应用，代理了服务发现、路由/负载均衡、通信等工作，构成了微服务网格，通过自有的中间件及管控平面进行微服务的管理、治理。同时，我们积极的推进 MOSN 与 SOFA中间件，网络接入层，安全防护及监控体系的整合，以提供更统一更强大的数据平面。\n接下来我将介绍 MOSN 支持多协议的方案。\n为了在内部快速落地试错，我们首先支持了内部使用最广泛的 SOFARPC 协议，并对其进行了深度优化。随后我们根据 UC Mesh 化推进遇到的普遍问题提出了 XProtocol 方案，以在不解包的场景下提供路由能力。最后我们深度改造了三方 HTTP/1.1 实现及官方 HTTP/2.0 实现。到目前为止，MOSN 已提供了多种协议的支持。同时 MOSN 提供了两种自定义协议的能力支持使用者通过扩展的方式自定义协议实现，满足需要解包、不需要解包的协议扩展需求。\n除协议之外，性能是大家比较关心的另一个问题。为了提供满足生产要求的7层转发性能，我们在 IO、协议、内存、协程、网络处理等方面进行了优化，从目前通过 SOFARPC 通信应用的上线情况来看可以满足生产使用要求，在案例分析中我将展示一些性能数据，后续我们也将继续推进性能优化，以达到更好的性能。\n在安全能力上，SOFAMesh 支持 mTLS，并在蚂蚁内部集成蚂蚁内部的 KMS 完成了 mTLS 落地，同时 RBAC 功能在研发中，此外WAF、流量镜像能功能也在规划中。\n在蚂蚁内部基于 MOSN 的网关产品正在研发中，将会在稳定验证后开源。网关场景相对于 Sidecar 场景有一些特性需求，比如说一般会 Hold 住大量长链接，比如说会根据请求内容动态选择后端应用，由于网关可能代理了不同的后端应用，就会需要动态选择后端协议。此外还有一些网关类的通用能力需求，如签名，授权，限流等。\n为了能基于开源版建设蚂蚁内部的 Sidecar 及网关产品，我们充分考虑了开源版 MOSN 的扩展性，在路由、后端管理、TLS、网络、流处理等各方面提供了扩展性支持。对于其他使用 MOSN 的场景，也可以通过类似的方式来满足自身业务定制需求。\n为了更清晰的展示 MOSN 功能特性，这里将 MOSN 0.4.0 的功能特性通过表格的方式展示出来。可 …","date":1543906800,"description":"本文根据晓东在 GIAC 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-giac-2018/","fuzzywordcount":7200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"71d6ede37fa4f1d1e6c99fbd37ff2f52","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-giac-2018/","publishdate":"2018-12-04T15:00:00+08:00","readingtime":15,"relpermalink":"/sofastack.tech/blog/service-mesh-giac-2018/","summary":"朵晓东，花名奕杉，蚂蚁金服高级技术专家。专注企业云计算技术及产品，蚂蚁金融云 PaaS 创始团队核心成员，Antstack 网络产品负责人。开源爱好者，","tags":["Service Mesh"],"title":"蚂蚁金服 Service Mesh 新型网络代理的思考与实践","type":"blog","url":"/sofastack.tech/blog/service-mesh-giac-2018/","wordcount":7130},{"author":"敖小剑","categories":"Service Mesh","content":" 敖小剑，蚂蚁金服高级技术专家，十六年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher 社区联合创始人。 龙轼，阿里巴巴技术专家、前京东 Hadoop 负责人、Hadoop 代码贡献者、现负责UC 基于 Kubernetes 自研的 PaaS 平台整体的稳定性。 本文根据他们在 Service Mesher Meetup 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，今天给大家带来的演讲主题是《蚂蚁金服 Service Mesh 渐进式迁移方案》，给大家介绍一下我们蚂蚁金服主站的 Service Mesh 迁移方案，在稍后的内容中我会给大家解释什么是“渐进式”。今天的演讲方式有些特殊，将会是两位讲师合作。我是敖小剑，来自蚂蚁金服中间件团队，另外一位讲师 龙轼 ，来自 UC 基础研发部。\nService Mesh 演进路线 今天的内容将会有四块主要内容：\n Service Mesh演进路线：介绍蚂蚁金服计划在主站落地Service Mesh的方案，由于涉及到大量的存量应用和超大规模，又要保证迁移过程的平滑，因此我们的落地方案相比社区方案要复杂的多。 实现平滑迁移的关键：介绍在整个迁移方案中，为了实现平滑迁移的几个关键做法，然后今天我们将详细展开其他的一个关键点：DNS寻址方案。 DNS寻址方案的演进：详细介绍Kubernetes/Istio/SOFAMesh一路演进过来的DNS寻址方式 DNS寻址方案的后续规划：介绍我们在DNS寻址方案上的后续规划。 前两块内容将由我来为大家介绍，后两块内容将由我的同事 龙轼 为大家介绍。\n在展开内容之前，先看一下背景，Service Mesh在蚂蚁金服主站落地的背景：\n 目标：需要满足我们对长期目标的认可，具体指服务间通讯走Service Mesh，而且是Istio这种带完整的控制平面的Service Mesh形态，基础设施要构建在k8s之上，而应用的形态要向微服务靠拢。 现状：而现实是存在很多挑战，首先还有很多应用没有实现微服务化，而且我们的k8s普及程度也不够，还有非常多的应用没有运行在kubernets之上。Istio的成熟程度也稍显不足，不够稳定，更大的挑战的是Istio目前无法原生支持我们蚂蚁金服的规模，我们还在试图对Istio进行改进和扩展。最后，在落地时必须考虑的非常现实的一点：现有系统中为数众多的应用不可能一夜之间全部迁移。 关键需求：因此在落地实施时，非常重要的需求是：要实现平滑迁移。简单说，微服务 + Service Mesh + kubernetes 是我们的目标，但是如何从现有体系出发，向目标平稳和坚实的迈进，必须给出可行的实践指导。 今天演讲的内容，要给大家介绍的就是，在这样的背景下，我们蚂蚁金服选择的Service Mesh主站落地演进方案。这个方案预期会在2019年初全面铺开。\n主站落地方案的实施原则，这是我们在过去半年的实践中，总结归纳出来的行为指导：\n 符合远期规划：一定要有清晰的长期目标，明确的知道未来的大方向。避免走弯路，避免浪费投资，理想状态是计划中的每一步都可以为下一步奠定坚实的基础。即使因为某些原因不得已妥协或绕行，也应该清晰的知道后面应该如何回归，谢绝中途推倒重来——代价太高，无法承受。 循序渐进：认清现实，如此之大的变革，一定是需要分步进行，不要心存一步登天的幻想，现实可行的方式是小步快跑。将整个过程拆解为若干个大步骤，每一步的工作量和复杂度都控制在一个可以接受的范围内，以保证每一步都简单方便，切实可行。 有可操作性：在操作层面上，要有足够的弹性，即每个步骤中的工作内容，都应该是可以分批进行。以步步为营的方式，逐步扩大战果，杜绝一刀切。 在接下来的演进路线中，大家将会体会到这三个原则在实际落地时的指导作用。\n这个图的信息量有点大，描述的是 Service Mesh 和 k8s 落地可能的多种演进路线。\n我们先从最下面开始看，这是当前蚂蚁金服主站大多数应用的现状：即应用\u0026amp;rdquo;部署在非k8s上\u0026amp;rdquo;，应用也\u0026amp;rdquo;不是Service Mesh形态\u0026amp;rdquo;。 然后看最上面，这是我们期望的蚂蚁金服主站未来的应用终极形态：应用\u0026amp;rdquo;部署在k8s上\u0026amp;rdquo;，应用也迁移到了\u0026amp;rdquo;Service Mesh形态\u0026amp;rdquo;。\n这里有个特别的地方，我们将Service Mesh形态细分为两种模式：\n Sidecar模式：只有Sidecar，没有控制平面，和外部系统的各种集成都是在Sidecar中直接进行。这是第一代的Service Mesh，Linkerd/Envoy都是如此，华为基于ServiceComb演进而来的mesher，新浪微博的Mesh，包括我们蚂蚁金服基于MOSN开发的用于取代多语言客户端的Mesh方案。 Istio模式：有完善的控制平面，可以提供强大的控制能力，而且从数据平面分离，这是第二代的Service Mesh，典型如Istio和Conkduit/Linkerd 2.0。 之所以将Service Mesh形态细分，是因为我们有着这样一个特殊背景：目前的原生Istio无法支撑我们蚂蚁金服的规模，因此在改进完善Istio之前，我们不得不暂时在Sidecar模式下短暂停留。另外一个原因就是考虑到存量应用的迁移，多一个Sidecar模式作为中间缓冲，会让整个迁移过程平滑很多。\n现在我们来介绍图中展示的四条演进路线：\n 左边的路线1，思路是先将应用迁移k8s部署，再迁移到Service Mesh形态。这条路线的最大好处，是过程中每个阶段的绝大多数投资都将最终得以保留，因为符合k8s+service mesh的远期目标。 右边的路线2，思路是跳过k8s，先迁移到Service Mesh形态，一路演进到Istio模式，然后最后迁移到k8s。 中间的路线3，直接一步到位，这个路线是Istio默认的方式，或者说Istio根本没有考虑过迁移的问题，默认客户已经有完善的k8s，然后将改造好的应用直接部署在Istio上。这个路线对于蚂蚁金服主站的复杂场景，当然是不现实的。（补充：只是对蚂蚁金服主站不合适，对于大多数公司，规模不是那么巨大，也没有历史负担，也有k8s基础，完全可行。） 还有一条特别的路线4，走位飘忽，先和路线2一样迁移到Sidecar模式，然后走回路线1，上k8s，再在有k8s支持的情况下继续演进到Istio模式。 下面我们来详细分析各条演进路线的优劣和实施条件。\n演进路线2，和路线1的核心差别，在于：是先上k8s，还是先上Service Mesh。而且路线2是在非k8s条件下一路演进Service Mesh到我们期望的终极形态Istio模式，这意味着过程中和最终目标有非常大的偏移。\n演进路线2的好处，在于第一步非常的自然：\n 没有k8s的限制，因此不依赖基础设施，实施方便。毕竟，k8s普及度是个大问题； 在原有的侵入式框架的客户端SDK基础上，通过包裹一个proxy，重用原有SDK的能力，可以非常快速的得到一个基本可用的Sidecar； 除了多一个proxy外，没有引入太多的新概念和新 …","date":1543474800,"description":"本文根据敖小剑、龙轼在 Service Mesher Meetup 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","dir":"blog/service-mesh-meetup-5-retrospect/","fuzzywordcount":10300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5031be4287bf1a7d7921bf5133ea414c","permalink":"https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","publishdate":"2018-11-29T15:00:00+08:00","readingtime":21,"relpermalink":"/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","summary":"敖小剑，蚂蚁金服高级技术专家，十六年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher 社区联合创始人。 龙轼，阿里巴","tags":["Service Mesh"],"title":"Service Mesh 渐进式迁移方案 | Service Mesh Meetup 实录","type":"blog","url":"/sofastack.tech/blog/service-mesh-meetup-5-retrospect/","wordcount":10259},{"author":"鲁直","categories":"SOFAMesh","content":" 本文作者：黄挺，蚂蚁金服高级技术专家，蚂蚁金服分布式架构 SOFA 的开源负责人。目前在蚂蚁金服中间件团队负责应用框架与服务化相关的工作。 本文根据黄挺在 CNUTCon 全球运维大会的主题分享整理，完整的分享 PPT 获取方式见文章底部。\n 大家好，我是来自于蚂蚁金服的黄挺，花名鲁直，目前在蚂蚁金服负责微服务团队，也是 SOFA 开源的负责人。来到这个场子的朋友们肯定都知道，Service Mesh 在过去一两年之中迅速成长为社区中非常热门的话题，几乎所有的大会中，都多多少少有一些关于 Service Mesh 的话题。在一个月之前，我的同事敖小剑老师在上海的 QCon 中也分享了蚂蚁金服在 Service Mesh 上的探索，包括在前面的场次中，来自华为的巨震老师也分享了华为在 Service Mesh 上的一些思考。在今天的分享中，我不会去花太多时间介绍什么是 Service Mesh，更多地聚焦在蚂蚁金服将 Service Mesh 用在解决多语言的问题上的一些实践，希望在场的各位可以从这些实践中有所收获。\n这个是我今天介绍的主要的内容，首先，我会大家简单介绍一下多语言在蚂蚁金服发展的一些情况，铺垫一下背景，交代各个语言在蚂蚁金服的使用情况，并且之前在多语言通信上面遇到了哪些问题。\n然后，我会给大家简单介绍下 SOFAMesh，SOFAMesh 是蚂蚁金服产出的 Service Mesh 的解决方案。\n接着我会介绍我们在 SOFAMesh 之上架构的多语言通信的方案以及在这个方案的实施过程中遇到的一些技术要点。\n蚂蚁金服多语言发展 不知道在场的同学有没有听说过 SOFA，SOFA 是蚂蚁金服大约 10 年前开始研发的一套分布式中间件，包括了微服务体系，分布式事务，消息中间件，数据访问代理等等组件，这套组件一直以来都是完全用 Java 来构建的，因此基于 SOFA 构建的 SOFA 应用也都是用 Java 写的，在蚂蚁金服，目前大概有接近 2000 个 SOFA 应用，顺带提一下，这套 SOFA 中间件目前已经部分开源在 Github 上面。从这个数据我们也可以显而易见地得出以下的结论，Java 在蚂蚁金服，至少在在线的应用上，占据了绝对主导的地位。\n随着无线技术的发展以及 NodeJS 技术的兴起，在 2013 年，蚂蚁金服开始引入了 NodeJS，研发了 EggJS，目前也已经在 Github 上开源，在蚂蚁金服，我们主要将 EggJS 作为服务于无线以及 PC 的 BFF 层来使用，后端的所有的微服务还都是用基于 Java 的 SOFA 来研发，EggJS 要调用后端的 SOFA 服务，并且对 PC 和无线端提供接口，必然就要遵守 Java 世界的 SOFA 之前定下的种种“规矩”，事实上，蚂蚁金服的 NodeJS 团队完全用 EggJS 适配了所有的 SOFA 中间件的客户端，保证在 EggJS 上，也可以使用所有的 SOFA 中间件，可以和之前基于 Java 研发的 SOFA 应用进行通信。但是，由于 Java 在蚂蚁中间件上的主导地位，导致 SOFA 中间件的某些特性的实现，完全依赖于 Java 特有的语言特性，因此，NodeJS 团队在追赶 SOFA 中间件的过程中，也非常的痛苦，在后面的例子中，我会有一些具体的例子，大家看了之后肯定会感同身受。\n再到最近几年，随着 AI 的兴起，在蚂蚁金服也越来越多地出现 CPP，Python 等系统，而由于 CPP 和 Python 等等语言，在蚂蚁金服并没有一个独立的基础设施团队去研发对应的中间件，因此，他们和基于 Java 的 SOFA 应用的互通就降级成了直接采用 HTTP 来通信，这种方式虽然也可以 Work，但是在通信基础之上的服务调用的能力却完全没有，和原本的 SOFA 的基础设施也完全没法连接在一起。\n基于以上的一些现状，可以看到我们在发展过程中的主要的两个问题，一个是基础设施上的重复投入的消耗，很多 SOFA 中间件的特性，除了用 Java 写了一遍之外，还得用 NodeJS 再写一遍。另一个是以 Java 为中心，以 Java 为中心其实在只有 Java 作为开发语言的时候并没有什么问题，但是当其他的语言需要和你进行通信的时候，就会出现巨大的问题，事实上，很多框架上的特性的研发同学在不经意之间，就直接就用了 Java 的语言特有的特性去进行研发，这种惯性和隐性的思维会对其他语言造成巨大的壁垒。\n基于以上的问题，我们希望能够产出一个方案，一方面，可以尽量做到一次实现，到处可用。另一方面，需要能够保证语言的中立性，最好是能够天然地就可以让框架或者中间件的研发的同学去在做架构设计以及编码的时候，考虑到需要支持多语言。\nSOFAMesh 其实在这之前，我们已经尝试在数据访问层去解决类似的多语言适配的问题，蚂蚁金服有一个 OceanBase 的数据库，当各个语言需要访问 OceanBase 数据库的时候，采用的就是一个本地的 Proxy，这个 Proxy 会负责 Fail Over，容灾等等场景，而对各个语言只要保证 SQL 上的兼容就可以了，这让我们意识到，Proxy 的模式可能是解决多语言的一个方式，然后，在业界就出现了 Service Mesh，如果只是从技术上讲，Service Mesh 的 Sidecar 本质上也就是一个 Proxy，只是每一个服务实例都加上一个 Sidecar，这些 Sidecar 组成了一个网络，在加上一个控制平面，大家把他叫做 Service Mesh。通过 Service Mesh，我们可以将大量原来需要在语言库中实现的特性下沉到 Sidecar 中，从而达到一次实现，到处可用的效果；另外，因为 Sidecar 本身不以 Library 的形式集成到特定语言实现的服务中，因此也就不会说某些关键特性采用特定语言的特性来实现，可以保证良好的中立性。\n看起来 Service Mesh 似乎是一个非常完美的解决方案，但是如果我们探寻一下 Service Mesh 的本质的话，就会发现 Service Mesh 并非完美解决方案，这种不完美主要是体现在 Service Mesh 本质上是一种抽象，它抽象了什么东西，它把原来的服务调用中的一些高可用的能力全部抽象到了基础设施层。在这张 PPT 中，我放了三张图片，都是一棵树，从左到右，越来越抽象，从图中也可以非常直观地看出来，从右到左，细节越来越丰富。不管是什么东西，抽象就意味着细节的丢失，丢失了细节，就意味着在能力上会有所欠缺，所以，在 Service Mesh 的方案下，虽然看起来我们可以通过将能力下层到基础设施层，但是一旦下层下去，某些方面的能力就会受损。\n因此，我们希望能够演化出这样一套多语言通信的方案，它能够以 Service Mesh 为基础，但是我们也会做适当地妥协去弥补因为上了 Service Mesh 之后的一些能力的缺失。首先我们希望有一个语言中立的高效的通信协议，每个语言都能够非常简单地理解这个协议，这个是在一个跨语言的 RPC 通信中避免不了的，无论是否采用 Service Mesh。然后， …","date":1542870000,"description":"本文根据黄挺在 CNUTCon 全球运维大会的主题分享整理，完整的分享 PPT 获取方式见文章底部。。","dir":"blog/sofa-mesh-cnutcon-2018/","fuzzywordcount":7000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5a750edaa8c6a9759fd5e3533dd3fa4d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","publishdate":"2018-11-22T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","summary":"本文作者：黄挺，蚂蚁金服高级技术专家，蚂蚁金服分布式架构 SOFA 的开源负责人。目前在蚂蚁金服中间件团队负责应用框架与服务化相关的工作。 本文根据黄挺","tags":["SOFAMesh"],"title":"蚂蚁金服 SOFAMesh 在多语言上的探索实践","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-cnutcon-2018/","wordcount":6910},{"author":"明不二","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》最后一篇，作者明不二，就职于华为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部完成，感谢所有参与的源码爱好者！\n 前言 在应用服务化架构中，RPC 框架是非常重要的基础组件。而在 RPC 框架当中，序列化（以及反序列化）又是必不可少的一环。因为序列化的性能对整体框架性能有比较大的影响，之前的文章中，我们已经详细剖析了 SOFARPC 各个核心功能模块的实现原理，想必大家已经很清楚 RPC 的调用流程。\n在整个 RPC 调用流程当中，序列化及反序列化起到了承上启下的作用。序列化时，RPC客户端把待调用的方法和参数对象转换为网络上可传输的字节序列，为进一步的编解码提供原料。反序列化时，把从网络上接收到且已经解码了的字节序列转换成对象，便于 RPC 服务端调用。\n本文将从序列化概述、序列化协议特性、序列化使用方法分类、SOFARPC 序列化的设计及实现、几种序列化协议对比等方面介绍及对比序列化及其在 SOFARPC 中的应用。\n序列化概述 RPC 调用通过网络传输相关的调用方法及参数，在这个网络传输过程中，内存中的对象是无法直接传输的，只有二进制字节才能在网络上传输。而为了实现调用对象在网络上的传输，必须通过序列化实现对象 -\u0026amp;gt; 字节的过程，以及反序列化实现字节 -\u0026amp;gt; 对象的过程。在网络协议模型中，序列化属于应用层协议的一部分。\n如下列定义：\n序列化：将数据结构或者对象转换成二进制串的过程。\n反序列化：将序列化过程中生成的二进制串转换成数据结构或者对象的过程。\n在上述定义中，二进制字节数组专指 Java 语言中的 byte[]。\n序列化协议特性 每种序列化协议都有其优点和缺点，在对一个序列化协议进行衡量评判时，通常由如下一些指标可以参考：\n 指标 说明 重要性 通用性 是否跨平台，社区如何 中高 可读 序列化格式是否可读 中低 易用性 是否简单易用 中高 性能 序列化后的大小和压缩 CPU消耗 中高 可扩展性 是在允许字段修改 高 安全性 是否存在一些无法修复的漏洞 高 以下逐个来详细说明：\n通用性 在通用性上，主要考察该序列化协议是否支持跨平台、跨语言的使用，同时兼顾考察业界的流行度及社区的活跃性。\n可读/易用性 在可读、易用性上面，主要考察该序列化协议序列化之后是否人眼可读，如 XML 和 JSON 就是人眼可读的序列化框架，这会大大提高调试的效率。同时，需要考察序列化框架所提供的 API 是否容易学习、调用。当然，在远程调用 的场景下，可读性不是一个重要因素。或者说，我们更多希望不可读。来保证一定的安全性。\n性能 性能指标，主要考虑序列化框架的时间复杂度和空间复杂度。\n序列化之后的数据一般都是用于存储或者网络传输，空间占用大小决定了传输的效率。序列化通常情况下要在原有的数据上加上描述字段，如果这个过程中引入的额外开销过大，则在大规模分布式系统中，很可能会造成巨大的额外空间开销。\n同时，为了提高系统的性能，是否耗费 CPU，解析和反解析二进制串的时间也是一个非常重要的指标。\n可扩展性 主要考虑当系统准备升级，需要对实体的属性进行变更，此时序列化协议能否快速支持，并且不会对原有的系统造成影响。如作为服务提供方的 API 接口入参中，增加了一个字段，是否一定要强制所有的客户端进行升级。这个会涉及到线上兼容性的问题。一般我们要求新增字段，在客户端尚未使用的情况下，不应该有序列化问题。\n安全性 需要考察序列化协议是否支持跨局域网之间的安全访问。是否存在一些安全漏洞。可以通过构造一些字节数组，使得服务端反序列化的时候，触发某些安全漏洞，执行一些系统调用，或者越权操作。\n序列化使用方式分类 按照序列化的使用方式，可以分为自描述型序列化以及基于中间格式型序列化。\n自描述型 所谓的自描述型，即在序列化的字节流里有着完整的对象类型信息和属性信息，可以在不依赖任何外界描述信息的前提下，只要拿到这个二进制流，就可以直接还原出原始对象。\n类似的系列化产品有：hessian、JSON、XML 等。\n例如，有如下一个对象 Person，Java 语言定义如下：\npackage com.sofa.test.Person; public class Person { private int age = 15; private String name = “sofa”; } 则使用 hessian 序列化后的字节流如下：\nM**com.sofa.test.PersonS**nameS**sofaS**ageI**b3 b2 b1 b0 z\n上面的*和b3 b2 b1 b0都表示不可打印的二进制。从上面内容可以看出，按照相应规定就能从二进制串中反序列化出对象来。因为这里面已经描述了类型，类型的字段名，以及对应的值，这样就可以直接反序列化了。\n基于中间描述型 一般这种类型的序列化主要用于跨语言当中，比如 Protobuf以及 thrift等等。在使用时都需要事先定义一个中间格式的文件（IDL 文件），然后根据不同语言的生成工具生成一个相应语言的可序列化类。以下是一个简单的 Proto的描述文件\nmessage SofaApp{ string appName = 1; repeated string authList = 2; repeated string serviceList = 3; } 然后当需要反序列化时，根据 IDL 文件及逆行相应的反序列化即可。格式是这样\n其中，图中的用户定义编号就是前面 proto中对每个字段定义的编号。\nSOFARPC 序列化的设计与实现 SOFARPC 支持及将要支持的序列化协议有：hessian、Protobuf、Json。\n序列化接口定义 在目前的 SOFARPC 5.4 分支中，已经支持的序列化协议有 hessian 和 Protobuf。两个序列化实现类继承了 AbstractSerializer抽象类，该抽象类又实现了如下的 Serializer接口：\n/** * 序列化器接口 * * @author \u0026amp;lt;a href=mailto:zhanggeng.zg@antfin.com\u0026amp;gt;GengZhang\u0026amp;lt;/a\u0026amp;gt; */ @Extensible(coded = true) @Unstable public interface Serializer { /** * 序列化 * * @param object 对象 * @param context 上下文 * @return 序列化后的对象 * @throws SofaRpcException 序列化异常 */ public AbstractByteBuf encode(Object object, Map\u0026amp;lt;String, …","date":1541055600,"description":"本文为《剖析 | SOFARPC 框架》最后一篇，作者明不二，就职于华为。","dir":"blog/sofa-rpc-serialization-comparison/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f0a5fd044fa69071a7251518ea7d69f6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-serialization-comparison/","publishdate":"2018-11-01T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-serialization-comparison/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 序列化比较","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-serialization-comparison/","wordcount":3267},{"author":"鸥波","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十二篇，作者鸥波。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 随着 TIOBE 10月份的编程语言排行 的发布，C++重回第三的位置，新兴的 Swift 和 Go 表现出强劲的上升趋势。与此同时，虽然目前 Java 的领头位置尚未出现有力挑战，我们希望能够在基础设施的建设上预留跨语言的可扩展设计。同时，跨语言的挑战也是工程实际面临的现状，蚂蚁内部如 AI、IoT，算法等缺少 JVM 原生支持的领域，往往不可避免地需要涉及到跨语言调用的问题。\n本文将为大家介绍 基于 SOFARPC 的微服务应用在面临跨语言调用时的方案和实现。\n总体设计 经过前面几篇对 SOFARPC 的 BOLT 协议和序列化这些的介绍，相信大家已经对 RPC 有了一些自己的理解，提到跨语言，我们会首先想到其他语言调用 Java，Java 调用其他语言，那么这里的跨，体现在代码上，到底跨在哪里？\n从跨语言的实现上来说，主要解决两个方面的问题：\n 跨语言的通讯协议和序列化协议\n 跨语言服务发现\n 另外从跨语言的落地来说，还得解决一个平滑兼容的问题。\n业界常见的做法是一般是通过 DNS 和 HTTP 来解决跨语言的问题，但是在内部已经有完善技术栈体系的情况下，直接切换一个新的方案显然是不合适的，所以蚂蚁内部是在已有的技术体系基础上进行改进。\n蚂蚁内部使用的通讯协议是Bolt，序列化协议是Hessian。我们知道，服务端和客户端在请求和返回之间携带的结构化的业务数据，需要在传输到达对端后，被本地的语言能够易于解析消费。由于语言本身特性的差异，同一对象的在序列化和反序列化的转换后，结构可能有差异，但是需要保证其转换操作是可逆的。以上这点Hessian做的不是很好，其跨语言的兼容性不能满足跨语言的需求，所以另外一个可行的方案就是就是选择其它基于 IDL 的序列化协议，例如Protobuf。\n现成的服务注册中心一般都有一些多语言解决方案，像Zookeeper、SOFARegistry、Consul、etcd等都有多语言客户端，所以服务发现这块问题不算太大。\n例如下面就是一个基于注册中心 + Bolt 协议 + Protobuf 序列化的设计图。\n通讯协议和序列化协议 通讯协议只要跨语言各方约定清楚，大家安装约定实现即可，而序列化协议则需要较多的考量。\n序列化的协议选择列出一些考虑要点：\n 是否采用具备自我描述能力的序列化方案，如不需要借助一些 schema 或者接口描述文件。\n 是否为语言无关的，包括脚本语言在内。\n 是否压缩比例足够小，满足网络传输场景的要求。\n 是否序列化和反序列化的性能均足够优秀。\n 是否向前/向后兼容，能够处理传输对象的新增属性在服务端和客户端版本不一致的情况。\n 是否支持加密、签名、压缩以及扩展的上下文。\n JSON Over HTTP 首先，说到跨语言，序列化支持，肯定有同学会问，为什么不直接通过 Http的Json来搞定呢？\n虽然得益于JSON和HTTP在各个语言的广泛支持，在多语言场景下改造支持非常便捷，能够低成本的解决网络通讯和序列化的问题。服务发现的过程则可以使用最简单的固定URL（协议+域名+端口+路径）的形式，负载均衡依赖于F5或者LVS等实现。\n但是这个方案的有明显的局限性：\n HTTP 作为无状态的应用层协议，在性能上相比基于传输层协议（TCP）的方案处于劣势。HTTP/1.1后可以通过设置keep-alive使用长连接，可以一定程度上规避建立连接的时间损耗；然而最大的问题是，客户端线程采用了 request-response 的模式，在发送了 request 之后被阻塞，直到拿到 response 之后才能继续发送。这一问题直到 HTTP/2.0 才被解决。\n JSON 是基于明文的序列化，较二进制的序列化方案，其序列化的结果可读性强，但是压缩率和性能仍有差距，这种对于互联网高并发业务场景下，意味着硬件成本的提升。\n 对于网络变化的响应。订阅端处理不够强大。\n Hessian Over BOLT 在否决了上一个方案后，我们继续看，蚂蚁内部，最开始的时候，SOFARPC 还没有支持 Protobuf 作为序列化方式，当时为了跨语言，NodeJs的同学已经在此基础上，用 js 重写了一个 hessian 的版本，完成了序列化。也已经在线上平稳运行。但是当我们要扩展给其他语言的时候，重写 hessian 的成本太高。而且 Java语言提供的接口和参数信息，其他语言也需要自己理解一遍，对应地转换成自己的语言对象。因此该方案在特定场景下是可行的。但不具备推广至其他语言的优势。\nNode的实现版本可以参考：https://github.com/alipay/sofa-rpc-node\nProtobuf Over BOLT Protobuf 基于IDL，本身具备平台无关、跨语言的特性，是一个理想的序列化方案。但是需要先编写proto文件，结构化地描述传输的业务对象，并生成中间代码。\n由于要重点介绍一下这种方案，因此再次回顾一下SOFABolt的协议规范部分，便于后面的解释。\nRequest command protocol for v1 0 1 2 4 6 8 10 12 14 16 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ |proto| type| cmdcode |ver2 | requestId |codec| timeout | classLen | +-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+ |headerLen | contentLen | ... ... | +-----------+-----------+-----------+ + | className + header + content bytes | + + | ... ... | +-----------------------------------------------------------------------------------------------+ codec: code for codec 序列化,hessian 是1,pb 是11,java 是2 Response command protocol for v1 0 1 2 3 4 6 8 10 12 14 16 …","date":1540969200,"description":"本文为《剖析 | SOFARPC 框架》第十二篇，作者鸥波。","dir":"blog/sofa-rpc-cross-language-support/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"28621f1b90e6ce8edf1b3e446fa5be23","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-cross-language-support/","publishdate":"2018-10-31T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-cross-language-support/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之SOFARPC 跨语言支持剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-cross-language-support/","wordcount":3741},{"author":"敏古","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十一篇，作者敏古。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。 SOFARPC：https://github.com/sofastack/sofa-rpc\n 1、前言 在 SOFABoot 环境下，SOFARPC 提供三种方式给开发人员发布和引用 RPC 服务：\n XML 方式（配置）\n Annotation 方式（注解）\n 编程 API 方式（动态）\n 编程 API 方式与Spring 的 ApplicationContextAware 类似。XML的方式依赖于在xml中引入 SOFA 命名空间，利用 Bean 的生命周期管理，进行 Bean 的注入。相比这两种方式，通过 Annotation 方式发布 JVM 服务更加灵活方便，只需要在实现类上加 @SofaService、@SofaRefernce 注解即可进行服务的发布和引用。本文针对 SOFARPC 在注解的支持和使用分原理、源码两部分进行一一介绍。\n2、原理介绍 2.1、注解是什么 注解又称为元数据，可以对代码中添加信息，这是一种形式化的方法，可以在稍后的某个时刻非常方便地使用这些数据。这个时刻可能是编译时，也可能是运行时。\n注解是JDK1.5版本开始引入的一个特性，用于对代码进行说明，可以对包、类、接口、字段、方法参数、局部变量等进行注解。注解的本质就是一个继承了 Annotation 接口的接口。一个注解准确意义上来说，只不过是一种特殊的注释而已，如果没有解析它的代码，它可能连注释都不如。\n一般常用的注解可以分为三类：\n Java自带的标准注解，包括@Override（标明重写某个方法）、@Deprecated（标明某个类或方法过时）和@SuppressWarnings（标明要忽略的警告）。\n 元注解，元注解是用于定义注解的注解。\n 自定义注解，可以根据自己的需求定义注解。\n 2.2、元注解 元注解是用于修饰注解的注解，通常用在注解的定义上。JAVA 中有以下几个元注解：\n @Target：注解的作用目标，也就是指明，你的注解到底是用来修饰方法的？修饰类的？还是用来修饰字段属性的，有以下几种类型： ElementType.TYPE：允许被修饰的注解作用在类、接口和枚举上 ElementType.FIELD：允许作用在属性字段上 ElementType.METHOD：允许作用在方法上 ElementType.PARAMETER：允许作用在方法参数上 ElementType.CONSTRUCTOR：允许作用在构造器上 ElementType.LOCAL_VARIABLE：允许作用在本地局部变量上 ElementType.ANNOTATION_TYPE：允许作用在注解上 ElementType.PACKAGE：允许作用在包上 @Retention：指定了被修饰的注解的生命周期，分以下三种类型： RetentionPolicy.SOURCE：该注解只保留在一个源文件当中，当编译器将源文件编译成class文件时，它不会将源文件中定义的注解保留在class文件中。 RetentionPolicy.CLASS：该注解只保留在一个class文件当中，当加载class文件到内存时，虚拟机会将注解去掉，从而在程序中不能访问。 RetentionPolicy.RUNTIME：该注解在程序运行期间都会存在内存当中。此时，我们可以通过反射来获得定义在某个类上的所有注解。 @Documented：当我们执行 JavaDoc 文档打包时会被保存进 doc 文档，反之将在打包时丢弃。\n @Inherited：解修饰的注解是具有可继承性的，也就说我们的注解修饰了一个类，而该类的子类将自动继承父类的该注解。\n 以 @Override 为例子：\n当编译器检测到某个方法被修饰了 @Override 注解，编译器就会检查当前方法的方法签名是否真正重写了父类的某个方法，也就是比较父类中是否具有一个同样的方法签名。\n@Override 仅被编译器可知，编译器在对 java 文件进行编译成字节码的过程中，一旦检测到某个方法上被修饰了该注解，就会去匹对父类中是否具有一个同样方法签名的函数，否则不能通过编译。\n2.3、注解解析方式 解析一个类或者方法的注解通常有两种形式，一种是编译期直接的扫描，一种是运行期反射。\n2.3.1、编译器的扫描 指的是编译器在对 java 代码编译字节码的过程中会检测到某个类或者方法被一些注解修饰，这时它就会对于这些注解进行某些处理。典型的就是注解 @Override，一旦编译器检测到某个方法被修饰了 @Override 注解，编译器就会检查当前方法的方法签名是否真正重写了父类的某个方法，也就是比较父类中是否具有一个同样的方法签名。\n这一种情况只适用于那些编译器已经熟知的注解类，比如 JDK 内置的几个注解，而你自定义的注解，编译器是不知道你这个注解的作用的，\n2.3.1、运行期反射 首先对虚拟机的几个注解相关的属性表进行介绍，先大体了解注解在字节码文件中是如何存储的。虚拟机规范定义了一系列和注解相关的属性表，也就是说，无论是字段、方法或是类本身，如果被注解修饰了，就可以被写进字节码文件。属性表有以下几种：\n RuntimeVisibleAnnotations：运行时可见的注解 RuntimeInVisibleAnnotations：运行时不可见的注解 RuntimeVisibleParameterAnnotations：运行时可见的方法参数注解 RuntimeInVisibleParameterAnnotations：运行时不可见的方法参数注解 AnnotationDefault：注解类元素的默认值 java.lang.reflect.AnnotatedElement 接口是所有程序元素（Class、Method和Constructor）的父接口，程序通过反射获取了某个类的 AnnotatedElemen t对象之后，利用 Java 的反射机获取程序代码中的注解，然后根据预先设定的处理规则解析处理相关注解以达到主机本身设定的功能目标。\n本质上来说，反射机制就是注解使用的核心，程序可以调用该对象的以下方法来访问 Annotation信息：\n getAnnotation：返回指定的注解 isAnnotationPresent：判定当前元素是否被指定注解修饰 getAnnotations：返回所有的注解 getDeclaredAnnotation：返回本元素的指定注解 getDeclaredAnnotations：返回本元素的所有注解，不包含父类继承而来的 3、源码解析 3.1、 …","date":1540450800,"description":"本文为《剖析 | SOFARPC 框架》第十一篇，作者敏古。","dir":"blog/sofa-rpc-annotation-support/","fuzzywordcount":4400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e68884b2feaf90e26f191de0ef49e945","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-annotation-support/","publishdate":"2018-10-25T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-rpc-annotation-support/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】系列之 SOFARPC 注解支持剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-annotation-support/","wordcount":4359},{"author":"敖小剑","categories":"SOFAMesh","content":" 背景 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，这两个是Istio/Envoy中的一等公民。而基于HTTP/1.1的REST和基于HTTP/2的gRPC，一个是目前社区最主流的通讯协议，一个是未来的主流，google的宠儿，CNCF御用的RPC方案，这两个组成了目前Istio和Envoy（乃至CNCF所有项目）的黄金组合。\n而我们SOFAMesh，在第一时间就遇到和Istio/Envoy不同的情况，我们需要支持REST和gRPC之外的众多协议：\n SOFARPC：这是蚂蚁金服大量使用的RPC协议(已开源) HSF RPC：这是阿里集团内部大量使用的RPC协议(未开源) Dubbo RPC: 这是社区广泛使用的RPC协议(已开源) 其他私有协议：在过去几个月间，我们收到需求，期望在SOFAMesh上运行其他TCP协议，部分是私有协议 为此，我们需要考虑在SOFAMesh和SOFAMosn中增加这些通讯协议的支持，尤其是要可以让我们的客户非常方便的扩展支持各种私有TCP协议：\n实现分析 我们来大体看一下，在SOFAMesh/Istio中要新增一个通讯协议需要有哪些工作：\n protocol decoder：负责解析协议，读取协议字段 protocol encoder：负责生成请求报文，注意通常会有改动，比如修改某些header 在pilot中需要为新协议生成 Virtual Host 等配置，有 inbound 和 outbound 两份，分别下发到Sidecar 在Sidecar中，根据下发的 Virtual Host 等配置，进行请求匹配，以决定请求该转发到何处 备注：实际下发的配置不止 Virtual Host 配置，为了简单起见，我们仅以 Virtual Host 为例做讲解。\n 其中，protocol encoder和protocol decoder是容易理解的，对于新的通讯协议肯定需要有协议编解码层面的工作必须要完成，这块有工作量是很自然的。\n我们来看看第三块的工作量是什么，inbound 和 outbound 的Virtual Host配置示例如下：\noutbound 配置中，注意 domains 字段是各种域名和ClusterIP，而 routes 中，match是通过prefix来匹配。我们结合HTTP/1.1，domains字段是用来和请求的Host header进行域名匹配的，比如 Host: istio-telemetry，这决定了哪些请求是要转发到 istio-telemetry 这个服务的。routes的match用来进行路由匹配的，通过HTTP请求的path进行匹配。\ninbound 配置类似，只是inbound更简单，domains匹配*就可以。\n从上面的例子中可以看到，Istio和Envoy的设计有非常浓重的HTTP协议的味道，各种语义都是和HTTP直接相关。而当我们进行TCP协议的转发时，就需要将请求的协议字段进行映射，映射到HTTP的相应语义。\n比如，最基本的Destination，原始语义是请求的目的地，在前面的文章中我们指出过这是请求转发最关键的字段。在HTTP协议中，通常是通过Host header和Path表示，对于REST而言还有重要的Method字段。\n下面的格式是其他各种协议对这个Destination原始语义的实际实现方式：\n 协议 实现 原始语义 请求的目的地(Destination) HTTP/1.1 Host header，Method，Path HTTP/2 Header帧中的伪header :authority，:path和:method Bolt协议 header map中key为”service”的字段 HSF协议 协议头中的服务接口名和服务方法名 Dubbo协议 data字段（payload）中的path/method 这些通讯协议在下发规则和进行请求匹配时，就需要进行协调：\n 定义好 Virtual Host 配置中的 domains 字段和 route 中的 match 用到的字段在当前通讯协议中的实际语义 在 protocol encoder 中读取请求的协议字段，和上面的字段对应 然后进行请求路由规则匹配（参照HTTP/1.1中的domain和route match的匹配） 而这些都是需要以代码的方式进行实现，以满足新通讯协议的要求。正规的做法，是每次新增一个通讯协议就将上述的工作内容重复一遍。这会直接导致大量的高度类似的重复代码。\nx-protocol的实现 在上述需要在协议扩展时修改的四个内容中，有一块是特别的：生成 Virtual Host 配置的工作是在Pilot中实现的，而其他三个是在Sidecar （Envoy或MOSN）中。考虑到 protocol encoder 和 protocol decoder 的工作是必不可少的，必然会修改Sidecar来增加实现代码，因此简化开发的第一个想法就是：能不能做到不修改Pilot？\n基本思路就是固定好原始语义，避免每个通讯协议都映射一遍。从前面我们列出来的各个协议的映射情况看，对于RPC协议而言，一般目的地信息都是服务名(有些是接口名)+方法名居多，因此可以考虑直接将服务名和方法名固定下来：\n RPC协议在 Virtual Host 配置中就固定为服务名对应 domains 字段，方法名对应 route 中的 match 用到的字段，这样只要修改一次然后各个RPC协议公用此配置，以后就不用再重复修改Pilot。 protocol encoder 在解析通讯协议完成之后，就直接将协议中对应服务名和方法名的字段提取出来，后面的匹配处理过程就可以公用一套通用实现，这样路由匹配这块也可以不用在重复开发。 因此，在x-protocol中，如果需要引入一个新的通讯协议，需要的工作内容只有必不可少的protocol encoder 和 protocol decoder，和实现以下几个接口：\n总结 X-protocol 在支持新通讯协议上的做法并无新奇之处，只是由于需求特殊有众多通讯协议需要支持，在开发时发现大量重复工作，因此我们选择了一条可以让后面更舒服一点的道路。\n目前这个方案在SOFAMesh中采用，我们将进一步检验实际效果，也会和合作的小伙伴时验证，看他们在自行扩展新协议时是否足够理想。这个方案理论上应该可以同样适用于Istio、Envoy体系，随着社区对Istio的接受程度的提高，在Istio上支持各种TCP通讯协议的需求会越来越多，有理由相信Istio后续可能也会出现类似的方案。毕竟，每次都改一大堆类似的东西，不是一个好做法。\n系列文章 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发 ","date":1539500400,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，本文介绍的是TCP协议扩展。","dir":"blog/sofa-mesh-x-protocol-tcp-protocol-extension/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2c2876e9ae6a7a2b374b0d04cc42e6a4","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","publishdate":"2018-10-14T15:00:00+08:00","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","summary":"背景 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，这两个是Istio/Envoy中的一等公民。而","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（3）——TCP协议扩展","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/","wordcount":2488},{"author":"敖小剑","categories":"SOFAMesh","content":" 前言 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，而我们SOFAMesh，则需要支持以下几个RPC协议：\n SOFARPC：这是蚂蚁金服大量使用的RPC协议（已开源） HSF RPC：这是阿里集团内部大量使用的RPC协议（未开源） Dubbo RPC: 这是社区广泛使用的RPC协议（已开源） 更适合的平衡点：性能和功能 对于服务间通讯解决方案，性能永远是一个值得关注的点。而SOFAMesh在项目启动时就明确要求在性能上要有更高的追求，为此，我们不得不在Istio标准实现之外寻求可以获取更高性能的方式，比如支持各种RPC协议。\n期间有两个发现：\n Istio在处理所有的请求转发如REST/gRPC时，会解码整个请求的header信息，拿到各种数据，提取为Attribute，然后以此为基础，提供各种丰富的功能，典型如Content Based Routing。 而在测试中，我们发现：解码请求协议的header部分，对CPU消耗较大，直接影响性能。 因此，我们有了一个很简单的想法：是不是可以在转发时，不开启部分功能，以此换取转发过程中的更少更快的解码消耗？毕竟，不是每个服务都需要用到Content Based Routing这样的高级特性，大部分服务只使用 Version Based Routing，尤其是使用RPC通讯协议的服务，没有HTTP那么表现力丰富的header，对Content Based Routing的需求要低很多。\n此外，对于部分对性能有极高追求的服务，不开启高级特性而换取更高的性能，也是一种满足性能要求的折中方案。考虑到系统中总存在个别服务对性能非常敏感，我们觉得Service Mesh提供一种性能可以接近直连的方案会是一个有益的补充。为了满足这些特例而不至于因此整体否决Service Mesh方案，我们需要在Service Mesh的大框架下提供一个折中方案。\n请求转发 在我们进一步深入前，我们先来探讨一下实现请求转发的技术细节。\n有一个关键问题：当Envoy/SOFA MOSN这样的代理程序，接收到来自客户端的TCP请求时，需要获得哪些信息，才可以正确的转发请求到上游的服务器端？\n最关键的信息：destination 首先，毫无疑问的，必须拿到destination/目的地，也就是客户端请求必须通过某种方式明确的告之代理该请求的destination，这样代理程序才能根据这个destionation去找到正确的目标服务器，然后才有后续的连接目标服务器和转发请求等操作。\nDestination信息的表述形式可能有：\n1. IP地址\n可能是服务器端实例实际工作的IP地址和端口，也可能是某种转发机制，如Nginx/HAProxy等反向代理的地址或者Kubernetes中的ClusterIP。\n举例：“192.168.1.1:8080”是实际IP地址和端口，“10.2.0.100:80”是ngxin反向代理地址，“172.168.1.105:80”是Kubernetes的ClusterIP。\n2. 目标服务的标识符\n可用于名字查找，如服务名，可能带有各种前缀后缀。然后通过名字查找/服务发现等方式，得到地址列表（通常是IP地址+端口形式）。\n举例：“userservice”是标准服务名， “com.alipay/userservice”是加了域名前缀的服务名， “service.default.svc.cluster.local”是k8s下完整的全限定名。\nDestination信息在请求报文中的携带方式有：\n1. 通过通讯协议传递\n这是最常见的形式，标准做法是通过header头，典型如HTTP/1.1下一般使用 host header，举例如“Host: userservice”。HTTP/2下，类似的使用“:authority” header。\n对于非HTTP协议，通常也会有类似的设计，通过协议中某些字段来承载目标地址信息，只是不同协议中这个字段的名字各有不同。如SOFARPC，HSF等。\n有些通讯协议，可能会将这个信息存放在payload中，比如后面我们会介绍到的dubbo协议，导致需要反序列化payload之后才能拿到这个重要信息。\n2. 通过TCP协议传递\n这是一种非常特殊的方式，通过在TCP option传递，上一节中我们介绍Istio DNS寻址时已经详细介绍过了。\nTCP拆包 如何从请求的通讯协议中获取destination？这涉及到具体通讯协议的解码，其中第一个要解决的问题就是如何在连续的TCP报文中将每个请求内容拆分开，这里就涉及到经典的TCP沾包、拆包问题。\n转发请求时，由于涉及到负载均衡，我们需要将请求发送给多个服务器端实例。因此，有一个非常明确的要求：就是必须以单个请求为单位进行转发。即单个请求必须完整的转发给某台服务器端实例，负载均衡需要以请求为单位，不能将一个请求的多个报文包分别转发到不同的服务器端实例。所以，拆包是请求转发的必备基础。\n由于篇幅和主题限制，我们不在这里展开TCP沾包、拆包的原理。后面针对每个具体的通讯协议进行分析时再具体看各个协议的解决方案。\n多路复用的关键参数：RequestId RequestId用来关联request和对应的response，请求报文中携带一个唯一的id值，应答报文中原值返回，以便在处理response时可以找到对应的request。当然在不同协议中，这个参数的名字可能不同（如streamid等）。\n严格说，RequestId对于请求转发是可选的，也有很多通讯协议不提供支持，比如经典的HTTP1.1就没有支持。但是如果有这个参数，则可以实现多路复用，从而可以大幅度提高TCP连接的使用效率，避免出现大量连接。稍微新一点的通讯协议，基本都会原生支持这个特性，比如SOFARPC、Dubbo、HSF，还有HTTP/2就直接內建了多路复用的支持。\nHTTP/1.1不支持多路复用（http1.1有提过支持幂等方法的pipeline机制但是未能普及），用的是经典的ping-pong模式：在请求发送之后，必须独占当前连接，等待服务器端给出这个请求的应答，然后才能释放连接。因此HTTP/1.1下，并发多个请求就必须采用多连接，为了提升性能通常会使用长连接+连接池的设计。而如果有了requestid和多路复用的支持，客户端和Mesh之间理论上就可以只用一条连接（实践中可能会选择建立多条）来支持并发请求：\n而Mesh与服务器（也可能是对端的Mesh）之间，也同样可以受益于多路复用技术，来自不同客户端而去往同一个目的地的请求可以混杂在同一条连接上发送。通过RequestId的关联，Mesh可以正确将reponse发送到请求来自的客户端。\n由于篇幅和主题限制，我们不在这里展开多路复用的原理。后面针对每个具体的通讯协议进行分析时再具体看各个协议的支持情况。\n请求转发参数总结 上面的分析中，我们可以总结到，对于Sidecar，要正确转发请求：\n 必须获取到destination信息，得到转发的目的地，才能进行服务发现类的寻址 必须要能够正确的拆包，然后以请求为单位进行转发，这是负载均衡的基 …","date":1539154800,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，本文介绍的是快速解码转发方案。","dir":"blog/sofa-mesh-x-protocol-rapid-decode-forward/","fuzzywordcount":6900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"37ad5c3f997c173a4ceb60cc9dfd0532","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":14,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","summary":"前言 在Istio和Envoy中，对通讯协议的支持，主要体现在HTTP/1.1和HTTP/2上，而我们SOFAMesh，则需要支持以下几个RP","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/","wordcount":6856},{"author":"米麒麟","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第九篇，作者米麒麟，目前就职于陆金所。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕，文末提供了已完成的文章目录。\n 前言 众所周知，在微服务架构下面，当应用需要进行新功能升级发布，或者异常关闭重启的时候，我们会对应用的进程进行关闭，而在关闭之前，我们希望做一些诸如关闭数据库连接，等待处理任务完成等操作，这个就涉及到我们本文中的优雅关闭功能。假如应用没有支持优雅停机，则会带来譬如数据丢失，交易中断、文件损坏以及服务未下线等情况。\n微服务的优雅停机需要遵循\u0026amp;rdquo;注销发布服务 → 通知注销服务 → 更新服务清单 → 开启请求屏蔽 → 调用销毁业务服务 → 检查所有请求是否完成 → 超时强制停机\u0026amp;rdquo;应用服务停机流程。\nSOFARPC 提供服务端/客户端优雅关闭功能特性，用来解决 kill PID，应用意外自动退出譬如 System.exit() 退出 JVM，使用脚本或命令方式停止应用等使用场景，避免服务版本迭代上线人工干预的工作量，提高微服务架构的服务高可靠性。\n本文将从进程的优雅关闭，SOFARPC 应用服务优雅关闭流程，Netty 的优雅停机等方面出发详细剖析 。\n进程优雅关闭 Kill 结束进程 在 Linux上，kill 命令发送指定的信号到相应进程，不指定信号则默认发送 SIGTERM(15) 终止指定进程。如果无法终止，可以发送 SIGKILL(9) 来强制结束进程。kill 命令信号共有64个信号值，其中常用的是：\n2(SIGINT：中断，Ctrl+C)。\n15(SIGTERM：终止，默认值)。\n9(SIGKILL：强制终止)。\n这里我们重点说一下15和9的情况。\nkill PID/kill -15 PID 命令系统发送 SIGTERM 进程信号给响应的应用程序，当应用程序接收到 SIGTERM 信号，可以进行释放相应资源后再停止，此时程序可能仍然继续运行。\n而kill -9 PID 命令没有给进程遗留善后处理的条件。应用程序将会被直接终止。\n对微服务应用而言其效果等同于突然断电，强行终止可能会导致如下几方面问题：\n 缓存数据尚未持久化到磁盘，导致数据丢失；\n 文件写操作正在进行未更新完成，突然退出进程导致文件损坏；\n 线程消息队列尚有接收到的请求消息，未能及时处理，导致请求消息丢失；\n 数据库事务提交，服务端提供给客户端请求响应，消息尚在通信线程发送队列，进程强制退出导致客户端无法接收到响应，此时发起超时重试带来重复更新。\n 所以支持优雅关闭的前提是关闭的时候，不能被直接 通过发送信号为9的 Kill 来强制结束。当然，其实我们也可以对外统一暴露应用程序管理的 API 来进行控制。本文暂时不做讨论。\nJava 优雅关闭 当应用程序收到信号为15的关闭命令时，可以进行相应的响应，Java 程序的优雅停机通常通过注册 JDK 的 ShutdownHook 来实现，当应用系统接收到退出指令，首先 JVM 标记系统当前处于退出状态，不再接收新的消息，然后逐步处理推积的消息，接着调用资源回收接口进行资源销毁，例如内存清理、对象销毁等，最后各线程退出业务逻辑执行。\n优雅停机需要超时控制机制，即到达超时时间仍然尚未完成退出前资源回收等操作，则通过停机脚本调用kill-9 PID命令强制退出进程。\n其中 JVM 优雅关闭的流程主要的阶段如下图所示：\n如图所示，Java进程优雅退出流程包括如下五个步骤：\n 应用进程启动，初始化 Signal 实例；\n 根据操作系统类型，获取指定进程信号；\n 实现 SignalHandler 接口，实例化并注册到 Signal，当 Java 进程接收到譬如 kill -12 或者 Ctrl+C 命令信号回调其 handle() 方法；\n SignalHandler 的 handle 回调接口初始化 ShutdownHook 线程，并将其注册到 Runtime 的 ShutdownHook。\n Java 进程接收到终止进程信号，调用 Runtime 的exit() 方法退出 JVM 虚拟机，自动检测用户是否注册ShutdownHook 任务，如果有则触发 ShutdownHook 线程执行自定义资源释放等操作。\n SOFARPC 优雅关闭 在进程可以进行优雅关闭后，SOFARPC 如何实现优雅关闭呢？首先 SOFARPC 对于所有可以被优雅关闭的资源设计com.alipay.sofa.rpc.base.Destroyable接口，通过向 JVM 的 ShutdownHook 注册来对这些可被销毁的资源进行优雅关闭，支持销毁前和销毁后操作。\n这里包括两部分：\n 作为服务端注册 JDK 的 ShutdownHook 执行取消服务注册、关闭服务端口等动作实现；\n 作为客户端通过实现 DestroyHook 接口逐步处理正在调用的请求关闭服务调用。\n 总体设计 运行时上下文注册 JDK 的 ShutdownHook 执行销毁 SOFARPC 运行相关环境实现类似发布平台/用户执行kill PID 优雅停机。运行时上下文 RpcRuntimeContext 静态初始化块注册 ShutdownHook 函数：\nstatic { ... // 增加jvm关闭事件 if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } } 注册本身很简单，重要的是 destroy 方法实际上做的事情非常多。按照先后顺序，大致包含如下几个部分。\nRpcRuntimeContext 销毁服务优雅关闭完整流程：\n 设置 RPC 框架运行状态修改为正在关闭，表示当前线程不再处理 RPC 服务请求；\n 遍历运行时上下文关闭资源的销毁钩子，进行注册销毁器清理资源前期准备工作；\n 获取发布的服务配置反注册服务提供者，向指定注册中心批量执行取消服务注册；\n 检查当前服务端连接和队列任务，先把队列任务处理完毕，再缓慢关闭启动端口；\n 关闭发布的服务，到注册中心取消服务发布，取消将处理器注册到服务端，清除服务发布配 …","date":1539154800,"description":"本文为《剖析 | SOFARPC 框架》第九篇，作者米麒麟，目前就职于陆金所。","dir":"blog/sofa-rpc-graceful-exit/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6a1f6847a5ecf97e90a3a06c36f39246","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-graceful-exit/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-graceful-exit/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 优雅关闭剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-graceful-exit/","wordcount":3972},{"author":"明不二","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第十篇，作者明不二，就职于华为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 RPC 框架需要创造一种调用远程服务如同调用本地般的体验，因此在实现一个基于 RPC 框架的微服务架构的系统时，服务消费者（客户端）往往只需要知道服务端提供了哪些接口和方法，并不需要知道服务具体由哪些 IP 在提供。RPC 框架本身的服务发现和路由寻址功能解决了如何知道目标地址的问题，该过程对于 RPC 客户端调用方来说应该是完全透明的。\n在这个过程中，RPC 框架需要接入注册中心来完成服务发现和路由寻址的功能。同时，在应用大规模请求时，微服务系统还需要对请求服务集群化，同时通过负载均衡来达到降低访问压力的效果。\n本文我们会先介绍一下注册中心，然后介绍一下 SOFRPC 中的几种路由，最后会介绍一下负载均衡的几种比较。\n注册中心支持 首先我们简要介绍一下注册中心的原理。\n服务端推送地址给注册中心，注册中心将地址进行合并后，推送给客户端。\n其中，注册中心的场景依赖于各类注册中心的实现。在这里，SOFARPC 提供了注册中心的抽象类 Registry，该抽象类提供了注册中心的配置、启动、注册、反注册、订阅等方法。客户端在接入过程中，可以通过配置来激活 Zookeeper、Consul、local 等注册中心注册进启动类中，当请求到来时，可以通过注册中心进行相应的路由。\n注册中心的抽象类如下：\n在这个接口的基础上，目前内置实现了几种注册中心，包括即将合并的。\nLocal注册中心(Local) Local 注册中心是 SOFARPC 自己实现的一个本地注册中心，该注册中心的实现主要由类 LocalRegistry提供，可以调用其 register(ProviderConfig config) 方法实现服务的注册，主要是文件的读写。\n实现原理很简单，通过在本地注册文件来保存服务的发布和订阅信息。\nZookeeper注册中心(Zookeeper) Zookeeper 接入 SOFARPC 的实现类为 ZookeeperRegistry。目前是 SOFARPC 中默认的注册中心实现。也是大多数情况下，可以方便使用的。\nZookeeper 是一个分布式协调服务，用于维护配置信息、命名、提供分布式同步功能以及提供组服务等。Zookeeper 提供了服务注册与发现的解决方案，提供了简单的 API，可以让集成者简洁调用。\n当要发布一个 SOFARPC 服务时，首先需要在 zookeeper 中注册服务提供者的相关信息，包括：该服务接口隶属于哪个系统、服务的 IP 以及端口号、服务的请求 URL 和服务的权重等等。zookeeper 在这个过程中，注意负责对 SOFARPC 中的服务信息进行中心存储，同时负责把服务注册信息的更新及时通知到服务消费者。\n作为服务调用者，SOFARPC 调用端在调用时，若走的路由链路中有注册中心，则会从注册中心中获取到服务注册的相关信息，然后在调用时会根据负载均衡策略来发送请求。\nConsul注册中心(Consul) Consul 注册中心与 SOFARPC 之间的对接主要依赖于 ConsulRegistry类。\n该注册中心在功能表现上与 zookeeper 看起来一致。对比起 Zookeeper 来，Consul 支持多数据中心，同时支持 http 和 dns 等接口，有着多语言的能力。\n其他注册中心 目前已经在开发中的有 Nacos，SOFAMesh 等。也可以根据自己的场景，进行方便的扩展。\n路由设计 路由原理和设计 在阅读本部分之前，请大家注意：路由是为了选中一组地址。\nSOFARPC 通过对各类注册中心的支持，实现了服务发现、路由寻址的功能。访问客户端时，请求的路由可以由以下一些实现类实现：DirectUrlRouter、RegistryRouter、CustomRouter，上述三个路由实现类分别对应了直接地址路由（不需要经过注册中心直接路由直连到某个地址）、注册中心路由、以及客户自定义路由等。路由从 AddressHolder 获取到地址，同时通过各种负载均衡算法进行负载均衡，请求到相应的系统接口。\n首先我们看一下整个路由寻址过程的阶段。\n这 SOFARPC 中，路由可以分为地址直连路由、注册中心路由以及客户定制化路由。这以上三个路由均扩展了 Router 抽象类。服务路由的抽象类代码如下：\n这里的核心代码是 route 这个方法，将本次请求的信息，和服务列表进行计算。当客户端请求到达 Router 时，会根据请求的参数信息从 Router 和连接管理器中获取请求地址，通过调用 route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) 方法达到路由寻址的目的。\n其中，路由并不是一个非此即彼的过程，这些可选的路由是由用户和系统的配置，被构造成一个路由链来执行的。这样。就可以有一些兜底的逻辑，如指定了 IP 地址，那我们就直接路由到这个地址，如果没有，就进行注册中心的路由等等。\n直连(DirectUrlRouter) 直接路由是比较简单的，因为有专门的配置，所以地址列表这些都是可以很方便地进行识别，在客户端配置时，可通过如下方式配置：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); 直接地址路由扩展了 Router 抽象类的实现，在重写的 route 方法中，直接获取配置好的直接路由地址。当请求到来时，直接从地址管理列表中，拿到对应的地址，就实现了直接地址路由的功能。\n注册中心(RegistryRouter) 注册中心路由同样扩展了 Router 抽象方法，这个 Router是大多数情况下使用最多的路由，主要是从本应用使用的注册中心中获取对应的地址，并进行路由寻址等。后面我们会介绍目前注册中心的几个内置实现。\n自定义(CustomRouter) 客户定制化路由可以配置客户自己所定制的路由实现，可以参考直接地址路由或者注册中心路由的实现，扩展 Router 类即可。\n这里的使用场景：\n一种是对于某些用户来说，在注册中心的场景下，用户认为所有的地址并不是等价的。会对地址进行人为拆分，使用方保存了自己的的所有服务提供方地址（或者是通过某种方法查询），然后重写路由定制逻辑，通过方法级别进行地址的选择。\n另一 …","date":1539154800,"description":"本文为《剖析 | SOFARPC 框架》第十篇，作者明不二，就职于华为。","dir":"blog/sofa-rpc-routing-implementation/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dc2f04fd097731619e17f7da6a24ae6a","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-routing-implementation/","publishdate":"2018-10-10T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-routing-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 路由实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-routing-implementation/","wordcount":3769},{"author":"敖小剑","categories":"SOFAMesh","content":" 本文是SOFAMesh中的多协议通用解决方案x-protocol介绍系列文章之一。\n 前言 在2018年上半年，蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决方案，在6月底对外公布了 SOFAMesh，详情请见之前的文章: 大规模微服务架构下的Service Mesh探索之路 。\n在 SOFAMesh 的开发过程中，针对遇到的实际问题，我们给出了一套名为 x-protocol 的解决方案，定位是云原生、高性能、低侵入性的通用 Service Mesh 落地方案，依托 Kubernetes 基座，利用其原生的服务注册和服务发现机制，支持各种私有 RPC 协议低成本、易扩展的接入，快速享受 Service Mesh 所带来的红利。\n具体解决的问题包括：\n 多通讯协议支持问题，减少开发工作量，简单快捷的接入新协议 尽量提升性能，提供更灵活的性能与功能的平衡点选择，满足特定高性能场景 兼容现有SOA体系，提供通过接口进行访问的方式，实现不修改业务代码也能顺利接入 Service Mesh 支持单进程多服务的传统SOA程序，可以在微服务改造之前，先受益于 Service Mesh 带来的强大功能 在本系列文章中，我们将对此进行详细的讲解，首先是“DNS通用寻址方案”。\n背景和需求 SOA的服务模型 在SOFAMesh计划支持的RPC框架中，SOFARPC、HSF、Dubbo都是一脉相承的SOA体系，也都支持经典的SOA服务模型，通常称为”单进程多服务”，或者叫做”单进程多接口”。（备注：由于服务一词使用过于频繁，下文都统一称为接口以便区分）\nSOA标准的服务注册，服务发现和调用流程如下：\n 在单个SOA应用进程内，存在多个接口 服务注册时，以接口为单位进行多次独立的服务注册 当客户端进行调用时，按照接口进行服务发现，然后发起调用 当我们试图将这些SOA架构的应用搬迁到ServiceMesh时，就会遇到服务模型的问题：微服务是单服务模型，也就是一个进程里面只承载一个服务。以Kubernetes的服务注册为例，在单进程单服务的模型下，服务名和应用名可以视为一体，Kubernetes的自动服务注册会将应用名作为服务注册的标示。\n这就直接导致了SOA模型和微服务模型的不匹配问题：\n SOA以接口为单位做服务注册和服务发现，而微服务下是服务名 SOA是”单进程多接口”，而微服务是”单进程单服务” 一步接一步的需求 先上车后补票 最理想的做法当然是先进行微服务改造，实现微服务拆分。但是考虑到现有应用数量众多，我们可能更愿意在大规模微服务改造之前，先想办法让这些应用可以运行在ServiceMesh下，提前受益于Service Mesh带来的强大功能。因此，我们需要找到一个合适的方案，让ServiceMesh支持没有做微服务改造依然是”单进程多接口”形式的传统SOA应用，所谓”先上车后补票”。\n 不修改代码 考虑到原有的SOA应用，相互之间错综复杂的调用关系，最好不要修改代码，即保持客户端依然通过接口名来访问的方式。当然，SOA架构的客户端SDK可能要进行改动，将原有的通过接口名进行服务发现再自行负载均衡进行远程调用的方式，精简为标准的Servicemesh调用（即走Sidecar），因此修改SDK依赖包和重新打包应用是不可避免。\n 支持带特殊字符的接口名 Kubernetes的服务注册，Service名是不能携带”.“号的。而SOA架构下，接口名有时出于管理方便，有可能是加了域名前缀，如”com.alipay.demo.interface-2”。为了实现不修改原有代码，就只能想办法支持这种带特殊字符的接口名。\n参考Kubernetes和Istio 在进一步讨论解决方案之前，我们先来看一下kubernetes和Istio中的标准请求寻址方式。\n 备注：过程稍显复杂，涉及到Kubernetes/Istio的一些底层细节。但是了解这个过程对后续的理解非常重要，也可以帮助大家了解Kubernetes和Kubernetes的工作原理，强烈推荐阅读。\n Kubernetes下的DNS寻址方式 在Kubernetes下，如图所示，假定我们部署了一个名为userservice的应用，有三个实例，分别在三个pod中。则应用部署之后，Kubernetes会为这个应用分配ClusterIP和域名，并在DNS中生成一条DNS记录，将域名映射到ClusterIP：\n当部署在Kubernetes下的某个充当客户端的应用发起请求时，如图中的HTTP GET请求，目标URL地址为 http://userservice/id/1000221。请求的寻址方式和过程如下：\n 首先进行域名解析，分别尝试解析”userservice”/“userservie.default.svc.cluster.local”等域名，得到ClusterIP 然后客户端发出请求的报文，目标地址为ClusterIP，源地址为当前客户端所在的pod IP（简单起见，端口先忽略） 请求报文随即被kube-proxy拦截，kube-proxy根据ClusterIP，拿到ClusterIP对应的多个实际服务实例所在的pod ip，取其中一个，修改目标地址为这个pod IP 请求报文最终就被发送到服务实例所在的pod IP 应答回来的方式类似，userservice发出的应答报文会被kube-proxy拦截并修改为发送到客户端所在的pod IP。\n我们详细看一下请求和应答全称的四个请求包的具体内容（简单起见继续忽略端口）：\n重点关注请求和应答报文的源地址和目标地址：\n 客户端发出的请求，为”客户端到ClusterIP” kube-proxy拦截到请求后，将请求修改为”客户端到服务器端” 服务器端收到请求时，表现为”客户端到服务器端”，ClusterIP被kube-proxy屏蔽 服务器端发送应答，因为收到的请求看似来自客户端，因此应答报文为”服务器端到客户端” 应答报文被kube-proxy拦截，将应答修改为”ClusterIP到服务器端” 客户端收到应答，表现为”ClusterIP到服务器端”，服务器端IP被kube-proxy屏蔽 kube-proxy在客户端和服务器端之间拦截并修改请求和应答的报文，联通两者，但各自屏蔽了一些信息：\n 在客户端看来它是在和ClusterIP交互，userservice的具体服务器端实例对客户端是无感知的 在服务器端看来，客户端是直接在和它交互，ClusterIP的存在对服务器端是无感知的 更深入一步，看kube-proxy在两个拦截和修改报文中的逻辑处理关系，即kube-proxy是如何在收到应答时正确的找回原有的ClusterIP：\n 在拦截并修改请求报文之后，kube-proxy会保存报文修改的5元组对应关系（5元组指源IP地址，源端口，协议，目的地IP地址，目的地端口） 在收到应答报文后，根据应答报文中的5元组，在保存的5元组对应关系中，找到对应信息，得到原有的ClusterIP和端口，然后修改应答报文 总结，通过上述Kubernetes下的寻址方式，客户端只需发送带简单寻址信息的请求（ …","date":1538982000,"description":"在本系列文章中，我们将详解Service Mesh中的多协议解决方案x-protocol，首先介绍的是DNS通用寻址方案。","dir":"blog/sofa-mesh-x-protocol-common-address-solution/","fuzzywordcount":5900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6429061afc56c5832c17b541943498e6","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","publishdate":"2018-10-08T15:00:00+08:00","readingtime":12,"relpermalink":"/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","summary":"本文是SOFAMesh中的多协议通用解决方案x-protocol介绍系列文章之一。 前言 在2018年上半年，蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决","tags":["SOFAMesh"],"title":"SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案","type":"blog","url":"/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/","wordcount":5813},{"author":"水寒","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第八篇，作者水寒，目前就职于网易。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕，文末提供了已完成的文章目录。\n 前言 在本系列之前的文章中，我们已经介绍了同步，异步，泛化调用等，也介绍了链路追踪的能力，本篇，我们将介绍一下 SOFARPC 中另一种内置的数据透传的能力。会依次介绍，数据透传的概念， SOFARPC 的设计原理，以及各种不同调用方式下的透传使用和详细说明，最后， 还会比较一下和 SOFATracer 的区别。欢迎大家与我们讨论交流。\n数据透传介绍 首先，我们介绍一下数据透传的概念，我们知道，在 RPC调用中，数据的传递，是通过接口方法参数来传递的，需要接口方定义好一些参数允许传递才可以，在一些场景下，我们希望，能够更通用的传递一些参数，比如一些标识性的信息。业务方可能希望，在每一次调用请求中都能够传递一些自定义的信息到下游。甚至也希望下游能够将一些数据传递回来。\n而数据透传功能，就是指数据不需要以作为方法参数的形式在调用链路中进行传递，而是直接存储到调用上下文中，之后通过 RPC 的内置对象，进行传递，调用双端可从上下文中获取数据而不需要去关注数据的传输过程。\nSOFARPC 提供的数据透传支持请求数据透传（客户端向服务端）和响应数据透传（服务端向客户端）。\nSOFARPC 设计原理 这里主要是介绍一下，实现的核心原理，更加具体的每种调用方式的透传，在后文中都会详细介绍。\n 用户通过 SOFARPC 提供的 API 进行数据传递设置\n SOFARPC 在调用传输前，将透传的数据进行打包获取\n 进行正常的序列化和反序列化\n SOFARPC 在反序列化时将用户设置的透传数据写回 Context\n 服务端用户即可进行获取使用\n 不同调用方式的透传 我们知道，SOFARPC 目前支持四种调用模式，如果没有阅读过之前文章的同学，可以阅读一下 SOFARPC 同步异步实现剖析，请求透传数据的原理都是一样的，服务端设置响应透传数据的原理也是一样的，只是客户端获取响应透传数据的方式有所不同（后三种模式只介绍客户端获取响应透传数据的原理）。因此我们会介绍下不同调用方式的透传细节，并介绍其使用方式，方便大家理解。以下为了方便说明，我们会使用如下的接口示例：\n接口服务 public interface HelloService { String sayHello(String string); } 服务实现 public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string) { // 获取请求透传数据并打印 System.out.println(\u0026amp;quot;service receive reqBag -\u0026amp;gt; \u0026amp;quot; + RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;req_bag\u0026amp;quot;)); // 设置响应透传数据到当前线程的上下文中 RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;resp_bag\u0026amp;quot;, \u0026amp;quot;s2c\u0026amp;quot;); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; ！\u0026amp;quot;; } } 后续的所有调用模式都使用HelloServiceImpl这个服务实现。(示例代码在 SOFARPC 的 测试 case 中都要对应的示例，大家可以对应阅读。)\n对用户可见的操作 API 只有一个就是 RpcInvokeContext，在 SOFABoot 和 SOFARPC 下都适用，当然如果你了解 SOFARPC 的 Filter 机制，也可以通过扩展这个来实现。\nsync 调用下的透传 使用示例 原理剖析 请求透传数据 客户端首先在 main 线程（图中的user thread）中设置请求透传数据到其调用上下文RpcInvokeContext.requestBaggage属性中，之后在调用过程中从requestBaggage中取出请求透传数据并设置到SofaRequest.requestProps属性中； 服务端接收到请求SofaRequest对象后，在其调用链中的 ProviderBaggageFilter#invoke 方法中会先从SofaRequest.requestProps中取出请求透传数据并设置到当前服务端线程的调用上下文RpcInvokeContext.requestBaggage属性中，最后业务代码就可以从调用上下文中获取请求透传数据了。 响应透传数据 服务端设置响应透传数据到其调用上下文RpcInvokeContext.responseBaggage属性中，之后在ProviderBaggageFilter#invoke 方法中先从responseBaggage中取出响应透传数据并设置到SofaResponse.responseProps属性中； 客户端main线程被唤醒后，先从SofaResponse.responseProps中获取响应透传数据，之后将响应透传数据设置到其调用上下文RpcInvokeContext.responseBaggage中，最后业务代码就可以从调用上下文中获取响应透传数据了。 oneway 调用下的透传 使用示例 原理剖析 在 oneway 模式下，客户端不接受服务端响应，也不会获取响应透传数据。\nfuture 调用下的透传 使用示例 原理剖析 客户端获取响应透传数据 future 模式在 SOFARPC 内部会被转化为 callback 的方式进行调用，在 callback 对象中会存储main线程的调用上下文；当客户端接收到响应时，会执行该 callback 对象的回调函数，在其回调函数中，对于响应透传数据，会做如下操作：\n 从SofaResponse.responseProps中获取响应透传数据\n 从 callback 对象中获取 main 线程的调用上下文\n 设置响应透传数据到 main 线程的调用上下文\n 将 main 线程上下文拷贝到当前的回调线程中\n 实际上，第三步与第四步在 SOFARPC 源码中顺序相反，本文这样解读是为了更容易理解。这样无论是 future 模式（从 main 线程的调用上下文获取响应透传数据）还是 callback 模式（从回调线程的调用上下文获取响应透传数据），都可以顺利的获取到响应透传数据。\ncallback 调用下的透传 使用示例 原理剖析 与 future 模式原理一样，只是最终业务代码中是从回调线程而不是main …","date":1538550000,"description":"本文为《剖析 | SOFARPC 框架》第八篇，作者水寒，目前就职于网易。","dir":"blog/sofa-rpc-data-transmission/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a26f5f1db99edadf48c406492ccdcaf8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-data-transmission/","publishdate":"2018-10-03T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-rpc-data-transmission/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 数据透传剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-data-transmission/","wordcount":2528},{"author":"莫那·鲁道","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第七篇，作者莫那·鲁道 ，来自 E签宝。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 前言 我们知道，在 RPC 调用中，客户端需要加载服务端提供的接口定义类，但是，很多情况下，这个并不总是可行的，于是，衍生了泛化调用的需求，一个成熟的，功能完善的 RPC 框架一般都会支持泛化调用，那么什么是泛化调用呢？SOFA RPC 又是如何支持泛化调用的？同时又是如何实现的？ 和其他的 RPC 泛化调用又有何不同？有何优势？我们将在本文一一解答这些问题。\n泛化调用介绍 当客户端因为某种原因无法得到服务提供方的接口 jar 包时，或者是客户端是一个比较通用的系统，并不想依赖每个服务提供方提供的 facade接口，但是又需要进行调用，那么此时就需要进行泛化调用。\n例如： 1. 当分布式系统由多个语言开发，假设是 Node Js ，同时 Node Js 需要调用 Java 语言的 RPC 服务，那么，我们就需要在两者之间架设适配层，让适配层处理 Node Js 的请求后再转发给 Java 的 RPC 服务。 2. 一些中间系统的功能，比如某些内部网关，需要以一个统一的方式实现对其他下游系统的调用（非 SPI的情况），逐个依赖下游的包显然是不可能的。 3. 一些流量回放类的线上系统，可以将数据采集拦截，之后，通过泛化调用回放，而不需要依赖全站的应用。\n那么这种情况下，肯定不能包含所有接口的 jar 文件，否则就太臃肿了。实际上也是不现实的，总不能每增加一个服务端，就增加一个 jar 包依赖，然后应用进行发布重启。\n这个时候就可以使用泛化调用，将相应的请求包装成泛化调用，就能够实现不依赖接口 jar 包，多语言调用 RPC 服务，避免重复开发。\nSOFA RPC 的泛化调用使用 SOFA RPC 的官方文档十分详细，在官方 wiki 泛化调用 中，已有详细介绍。同时，在源码中的 example 模块中，也有现成的 demo 可以跑起来，读者可以自己 clone 源码阅读，这里我们简要说明一下使用方式，以便大家有一个直观的了解。\n接口定义 总的来说，泛化调用有 2 个 API，包含 5 个方法，其中， 2 个方法已经废弃，也就是说，有 3 个主要方法。分别是：\n/** * 泛化调用 * @return 正常类型（不能是GenericObject类型） */ Object $invoke(String methodName, String[] argTypes, Object[] args); /** * 支持参数类型无法在类加载器加载情况的泛化调用 * @return 除了JDK等内置类型，其它对象是GenericObject类型 */ Object $genericInvoke(String methodName, String[] argTypes, Object[] args); /** * 支持参数类型无法在类加载器加载情况的泛化调用 * @return 返回指定的T类型返回对象 */ \u0026amp;lt;T\u0026amp;gt; T $genericInvoke(String methodName, String[] argTypes, Object[] args, Class\u0026amp;lt;T\u0026amp;gt; clazz); \\$invoke 该方法使用场景：用户知道参数类型和返回值类型，那么就可以使用该方法。 \\$genericInvoke 该方法是个重载方法，重载一的使用场景是：如果你的应用不知道接口的参数类型和返回值类型，这个时候，你就需要使用 GenericObject 类，来包装返回值和参数。 \\$genericInvoke 重载二的使用场景是：如果应用不知道接口参数类型，但是知道接口返回值的类型，那么就不需要使用 GenericObject 作为返回值了。 基本上，已经覆盖了常用的集中场景，可以说功能相当全面。\n泛化使用 由于篇幅有限，这里就不贴使用 demo 了，感兴趣的可以通过链接查看官方的 demo 或者源码，包含 SOFARPC 的 API 使用方式和 SOFABoot 的使用方式：\n demo wiki 地址：用户手册-\u0026amp;gt;基本特性-\u0026amp;gt;泛化调用 源码地址：示例源码 SOFARPC 泛化调用的设计与实现 接下来我们重点来介绍 SOFARPC 是如何实现泛化调用的。\n框架调用设计 简单来说，泛化调用的关键就是对象表示和序列化，SOFARPC 提供了 GenericObject 等对象来表示参数对象或者返回值对象，而将 GenericObject 对象序列化成目标对象，或者将返回值反序列化成 GenericObject 对象，是 SOFARPC 实现泛化的关键。\n这里我们先来看一下 SOFARPC 泛化调用的流程图，有助于后面理解泛化实现。\n我们来说一下这个图： 1. 泛化 API 调用时，会加载泛化过滤器，作用是做一些参数转换，同时设置序列化工厂类型。 2. SOFARPC 在使用 SOFABolt 进行网络调用前，会创建 context 上下文并传递给 SOFABolt，上下文中包含着序列化工厂类型信息，这个信息将决定使用何种序列化器，同时这个上下文将流转于整个调用期间。 3. 在 SOFABolt 正式发送数据之前，会将 GenericObject 对象序列化成普通对象的字节流，这样，服务提供方就不必关心是否为泛化调用，从图中可见，提供方不用对泛化调用做任何改变 —— 这是 SOFARPC 泛化区别于其他 RPC 泛化的关键。 4. 当提供方成功接收请求后，使用普通序列化器即可反序列化数据，只需要正常调用并返回即可。 5. 当消费者的 SOFABolt 接收到响应数据后，便根据 context 的序列化类型，对返回值做反序列化，即将普通的字节流反序列化成 GenericObject 对象 —— 因为客户端有可能不知道返回值的 Class 类型。 6. 最终，泛化 API 即可得到 GenericObject 类型的返回值。\n从上面的流程可以看出，序列化器在泛化调用中，占了极大的篇幅和作用。而 SOFARPC 针对泛化调用，对 hessian3 进行了改造，使其支持泛化调用所需要的序列化功能。SOFA-Hessian的改动可以参考这里。\nHessian 泛化实现 SOFA-Hessian 在 hessian 的包中加入了 com.alipay.hessian.generic 包，此包的作用就是处理泛化调用，重写的关键是实现或继承 SerializerFactory 类和 Serializer、Deserializer 等接口。在这里，设计了一下几个类，来描述对应的类型信息，同时实现这几个类的序列化和反序列化。对应关系如下： …","date":1537945200,"description":" 本文为《剖析 | SOFARPC 框架》第七篇，作者莫那·鲁道 ，来自 E签宝。","dir":"blog/sofa-rpc-generalized-call-implementation/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"de327dfe502c28ef0f926f17b29a6c80","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","publishdate":"2018-09-26T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 泛化调用实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/","wordcount":3226},{"author":"畅为","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第六篇，作者畅为。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品， 项目代号：SOFA:RPCLab/，官方目录目前已经全部认领完毕。\n 一. 前言 对于金融业务而言每个环节都涉及到大量的资金操作，若因为网络、硬件等原因导致系统不稳定性，不仅影响用户体验，更重要的是可能会引起资损问题，因此系统可用性至关重要。在微服务分布式架构中提高系统可用性的常见方案是 集群（冗余）。 集群方式将一个服务部署在多个机器上，通过硬负载或软负载实现服务的均衡负载，虽然可以有效避免单点问题，但是仍然避免不了某些场景单机故障引起服务调用失败的问题。\nSOFARPC 提供了自动单机故障剔除能力，能够自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复，提高系统可用性。本文将从以下几个方面进行剖析：\n 单机故障和服务降级介绍\n SOFARPC 单机故障剔除原理\n 二. 单机故障和服务降级 在分布式架构中常见可用性方案的是 集群（冗余），即将一个服务部署在多个机器上，通过硬负载或软负载实现服务的均衡负载。硬件负载因每次请求都需要经过硬件负载，承担所有的访问压力，当集群规模增加、流量增多，硬件负载可能因无法支撑所有流量而导致系统不可用。\n软负载则提供注册中心，并将负载能力转移到服务调用方( Consumer )，注册中心只有在 Consumer 首次订阅或服务发生变化时才会发生交互，避免了并发访问下的单点问题。下图是基于软负载的服务调用：\n虽然软负载可以避免单点问题，但可能存在以下场景导致服务不可用：\n Provider 出现单点故障或宕机，与 Consumer 的长连接已断开，但注册中心尚未摘除或未及时通知Consumer。\n Consumer 和 Provider的长连接还在，注册中心未下发摘除，但服务器端由于某些原因，例如长时间的 Full GC, 硬件故障（后文中为避免重复，统一描述为机器假死）等场景，处于假死状态。\n 这两种场景都是服务端出现故障，但由于长连接还保留等原因注册中心未摘除服务，导致服务调用失败。针对第一种情况 Consumer 不应调用出现故障的 Provider，否则会引起部分服务不可用；针对第二种情况，这个 Consumer 应该不调用或少调用该 Provider，可以通过权重的方式来进行控制。目前 SOFARPC 5.3.0 以上的版本支持 RPC 单机故障剔除能力。SOFARPC 通过服务权重控制方式来减少异常服务的调用，将更多流量打到正常服务机器上，提高服务可用性。\n2.1 SOFARPC故障剔除 vs 注册中心故障剔除 SOFARPC 的故障剔除与注册中心故障服务剔除不同，它们从不同的维度来完成故障剔除提高服务可用性。主要两方面的区别：\n 故障剔除的时机\n 故障剔除的细粒度\n 故障剔除的时机 SOFARPC 的故障剔除与注册中心故障服务剔除不同，它们从不同的维度来完成故障剔除提高服务可用性。注册中心服务管理关注 Provider 与注册中心的心跳或长连接。如果 Provider 出现心跳异常或长连接不存在，则及时将服务从注册中心剔除，并告知 Consumer 移除本地缓存的故障 Provider 信息。Comsumer 在负载均衡选择时则不考虑被剔除的 Provider，如图所示：\n而 SOFARPC 单机故障剔除针对的场景不同，针对的是注册中心还未剔除的服务，这些服务与 Consumer 仍然保持长连接，但由于机器假死，不能提供正常服务。 如下图所示：\n故障剔除的细粒度 注册中心剔除的是粒度是针对单机上的某个服务进程，属于进程级别。一旦这个进程和注册中心断开连接或心跳无感应，则将其从注册中心剔除。\nSOFARPC 故障剔除并控制精度会更精细一些，会细致到进程对外暴露的服务，如部署在某个机器上的交易系统对外提供的交易查询服务 TransQueryService. 管理的维度是 IP + 服务， 这里的服务特指进程中的服务接口。\n2.2 服务权重降级 vs 服务降级 服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。这里的降级级别是整个系统服务，而不是针对接口级别。\nSOFARPC 的服务降级，是指当某些个别机器因为存在机器假死，导致处于假死状态，导致一些服务接口响应异常，通过 SOFARPC 的故障剔除和服务权重降级来减少对这些异常机器接口的访问，而将更多的流量打到正常的机器上。 这里针对的维度主要还是 IP + 服务维度，如部署在 xxx 机器上交易系统对外提供的 TransQueryService 服务。\n三. 原理解析 通常一个服务有多个服务提供者，其中部分提供者可能由于机器假死等导致长连接还存活但是程序已经无法正常响应 。 故障剔除功能会将这部分异常的服务提供者进行降级，使得客户端的请求更多地指向健康节点。当异常节点的表现正常后，故障剔除功能会对该节点进行恢复，使得客户端请求逐渐将流量分发到该节点。\nSOFARPC 5.3.0 以上支持故障剔除的功能，故障剔除功能采用自动化监控和降级，因此可以减少人工干预，提供系统可用率。SOFARPC 剔除的维度是服务 + Ip 级别。为了支持单机故障剔除能力，SOFARPC 提供了以下几个方面的设计：\n 入口设计: 进行RPC调用的时候，增加一个信息统计的传递入口。SOFARPC 采用无缝插入设计，在不破坏开放封闭原则前提下引入单机故障剔除能力。\n 信息收集器 : 维护和管理从入口传进来的统计信息。\n 计算策略 : 主要是根据度量结果，判断是否需要执行降级或者恢复服务。如果命中降级规则，则触发降级行为。如果命中恢复规则，则触发恢复行为。\n 度量策略 : 负责按一定维度对调用信息做度量，判断服务正常或异常。\n 降级策略 : 如果服务异常，需要进行降级处理，降级策略指定了处理逻辑，比如按打印日志或降低服务权重。\n 恢复策略 ：当一个异常服务恢复正常时，如何恢复该服务，例如提高服务权重等。\n 3.1 整体结构和入口 《SOFARPC 链路追踪剖析》中已介绍 SOFARPC 的 内核设计和总线设计，和链路追踪功能一样，SOFARPC 单机故障剔除能力也是基于内核设计和总线设计，做到可插拔、零侵入。\nSOFARPC 单机故障剔除模块是 FaultToleranceModule， 通过 SOFARPC 的 SPI 机制完成模块的自动化加载，以完成该功能的插入。 FaultToleranceModule 模块包含了两个重要部分：\n subscriber 事件订阅器 。 通过订阅事件总线 EventBus 的事件，以零侵入方式完成 RPC 调用的统计和信息收集。\n regulator 调节器 。 根据收集的 RPC 调用信息，完成服务调用或服务权重的调节，达到服务 …","date":1537167600,"description":"本文为《剖析 | SOFARPC 框架》第六篇，作者畅为。","dir":"blog/sofa-rpc-single-machine-fault-culling/","fuzzywordcount":5300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3171526788b6f17e3ffa37512918729f","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","publishdate":"2018-09-17T15:00:00+08:00","readingtime":11,"relpermalink":"/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 单机故障剔除剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/","wordcount":5281},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第五篇。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 上一篇，我们介绍了 SOFARPC 同步异步的实现，本文我们将会介绍 SOFARPC 中的线程模型。\n本文会从同步异步，阻塞非阻塞开始讲起，进而探讨常见的线程模型设计，之后，我们会介绍下 SOFABolt 中对 Netty 的模型使用，最后 SOFARPC 在一次调用过程中各个步骤执行的线程。\n几种常见的 IO 模型 首先介绍一下 Linux 的几种 IO 模型，以进程从 Socket 中读取数据为例。实际上，进程最终是通过 recvfrom 系统调用来读取数据。这个时候，系统内核在收到之后，根据 IO 模型的不同，处理是不同的。\n注意，图下的红色部分表示阻塞时间。\n阻塞 I/O 阻塞 I/O(blocking I/O) 模型是最流行，最简单易用的 I/O 模型，默认情况下，所有套接字和文件描述符就是阻塞的。阻塞 I/O 将使请求进程阻塞，直到请求完成或出错。\n非阻塞 I/O 非阻塞 I/O(nonblocking I/O)的含义：如果 I/O 操作会导致请求进程休眠，则不要把它挂起，也就是不会让出 CPU，而是返回一个错误告诉它（可能是 EWOULDBLOCK 或者 EAGAIN）。\nI/O 复用 I/O 多路复用(I/O multiplexing)会用到 select 或者 poll 或者 epoll 函数，这几个函数也会使进程阻塞，但是和阻塞 I/O 所不同的的，函数可以同时阻塞多个 I/O 操作。而且可以同时对多个读操作，多个写操作的 I/O 函数进行检测，直到有数据可读或可写时，才真正调用 I/O 操作函数。\n信号驱动式 I/O 信号驱动 I/O(signal-driver I/O)使用信号，让内核在描述符就绪时发送 SIGIO 信号通知我们进行处理，这时候我们就可以开始真正的读了。\n异步 I/O 异步 I/O(asynchronous I/O)由 POSIX 规范定义，包含一系列以 aio 开头的接口。一般地说，这些函数的工作机制是：告知内核启动某个操作，并让内核在整个操作（包括将数据从内核空间拷贝到用户空间）完成后通知我们。\n这种模型与信号驱动模型的主要区别是：信号驱动 I/O 是由内核通知我们何时可以启动一个 I/O 操作，而异步 I/O 模型是由内核通知我们 I/O 操作何时完成。\n汇总 综上，我们给出一个大家比较熟知的比较图。方便理解。\nJAVA BIO \u0026amp;amp; NIO 在了解了内核层面上这几个线程模型之后，我们要给大家介绍下 JAVA BIO 和 JAVA NIO。\nJAVA BIO 首先我们给大家看一个直接使用 JAVA BIO 写得一个服务端。\n传统的BIO里面socket.read()，如果TCP RecvBuffer里没有数据，调用会一直阻塞，直到收到数据，返回读到的数据。\nJAVA NIO 对于 NIO，如果 TCP 的 buffer 中有数据，就把数据从网卡读到内存，并且返回给用户；反之则直接返回0，永远不会阻塞。下面是一段比较典型的 NIO 的处理代码。\n在我们可以将 JAVA NIO 和多路复用结合起来。这里也是最简单的 Reactor 模式：注册所有感兴趣的事件处理器，单线程轮询选择就绪事件，执行事件处理器。\n这里简单比较了一下以前的 BIO 和现在的 NIO，新的 NIO 给我们带来了如下的好处。\n 事件驱动模型\n 单线程处理多任务\n 非阻塞 I/O，I/O 读写不再阻塞，而是返回 0\n 基于快的传输，比基于流的传输更高效\n 更高级的 IO 函数，零拷贝\n 允许 IO 多路复用\n Reactor 线程模型 前面说了，我们有了 JAVA NIO ，可以用多路复用。有些同学可能会问，不能直接使用吗？答案是可以直接使用，\n但是技术层面上的问题虽然解决了，在工程层面，实现一个高效没有问题的架构依然很难，而且这种多路复用，对编程思维有比较大的挑战，所以，工程层面还不够。因此，有了 Reactor 编程模型\n一般情况下，I/O 复用机制需要事件分发器，以上这个分发事件的模型太简单了。实际使用起来会有一些性能问题。目前比较流行的是 Reactor 和 Proactor，本文不介绍 Proactor 模型，有兴趣的同学可以自己学习。\n标准/典型的 Reactor 中定义了三个角色：\n而一个标准的操作流程则是：\n 步骤1：等待事件到来（Reactor 负责）。\n 步骤2：将读就绪事件分发给用户定义的处理器（Reactor 负责）。\n 步骤3：读数据（用户处理器负责）。\n 步骤4：处理数据（用户处理器负责）。\n 在这个标准之下，Reactor 有几种演进模式可以选择。注意 Reactor 重点描述的是 IO 部分的操作，包括两部分，连接建立和 IO 读写。\n单线程模型 Reactor 单线程模型指的是所有的 IO 操作都在同一个NIO 线程上面完成，NIO 线程的职责如下：\n 作为 NIO 服务端，接收客户端的 TCP 连接；\n 作为 NIO 客户端，向服务端发起 TCP 连接；\n 读取通信对端的请求或者应答消息；\n 向通信对端发送消息请求或者应答消息。\n 这是最基本的单 Reactor 单线程模型。其中 Reactor 线程，负责多路分离套接字，有新连接到来触发 connect 事件之后，交由 Acceptor 进行处理，有 IO 读写事件之后交给 hanlder 处理。\nAcceptor 主要任务就是构建 handler，在获取到和 client 相关的 SocketChannel 之后 ，绑定到相应的 handler上，对应的 SocketChannel 有读写事件之后，基于 reactor 分发，hanlder 就可以处理了（所有的 IO 事件都绑定到 selector 上，由 Reactor 分发）。\n该模型 适用于处理器链中业务处理组件能快速完成的场景。不过，这种单线程模型不能充分利用多核资源，所以实际使用的不多。\n多线程模型 Reactor 多线程模型与单线程模型最大的区别就是将 IO 操作和非 IO 操作做了分离。效率提高。\nReactor 多线程模型的特点：\n 有专门一个 NIO 线程-Acceptor 线程用于监听服务端，主要接收客户端的 TCP 连接请求；\n 网络 IO 操作-读、写等由一个单独的 NIO 线程池负责，线程池可以采用标准的 JDK 线程池实现，它包含一个任务队列和 N 个可用的线程，由这些 NIO 线程负责消息的解码、处理和编码；\n 主从多线程模型 这个也是目前大部分 RPC 框架，或者服务端处理的主要选择。\nReactor 主从多线程模型的特点：\n服务端用于接收客户端连接的不再是个1个单独的 NIO 线程，而是一个独立的 NIO 线程池。\n主要的工作流程： …","date":1536735600,"description":"本文为《剖析 | SOFARPC 框架》第五篇。","dir":"blog/sofa-rpc-threading-model/","fuzzywordcount":3500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fbde29dd299a8163dafa9d571d1714e8","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-threading-model/","publishdate":"2018-09-12T15:00:00+08:00","readingtime":7,"relpermalink":"/sofastack.tech/blog/sofa-rpc-threading-model/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 线程模型剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-threading-model/","wordcount":3410},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第四篇。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 这一篇，我们为大家带来了开发过程中，最常接触到的同步异步调用解析。本文会介绍下同步异步的使用场景，以及 SOFARPC 中的代码实现机制，为了方便大家理解和阅读代码。不会过多的设计代码实现细节，更多的还是希望大家从中有所收获，并能够独立阅读核心代码。\n原理剖析 SOFARPC 以基于 Netty 实现的网络通信框架 SOFABolt 用作远程通信框架，使用者不用关心如何实现私有协议的细节，直接使用内置 RPC 通信协议，启动客户端与服务端，同时注册用户请求处理器即可完成远程调用：\nSOFARPC 服务调用提供同步 Sync、异步 Future、回调 Callback 以及单向 Oneway 四种调用类型。\n这里我们先提供一张整体的图，后面每个方式原理介绍的时候，我会进行更加详细的解释。读者可以重点阅读以下部分的图示，根据阻塞时间的长短，会有不同的标识。\nSync 同步调用 同步调用是指的客户端发起调用后，当前线程会被阻塞，直到等待服务端返回结果或者出现了超时异常，再进行后续的操作，是绝大多数 RPC 的默认调用方式，无需进行任何设置即可。\n这种调用方式，当前线程发起调用后阻塞请求线程,需要在指定的超时时间内等到响应结果才能完成本次调用。如果超时时间内没有得到响应结果，那么抛出超时异常。Sync 同步调用模式最常用，注意要根据对端的处理能力合理设置超时时间。\n如上图所示，这里主要是描述了客户端的处理逻辑，其中客户端线程和 RPC 内部部分处理并不在一个线程里。所以这里客户端线程包含其中一部分操作，后文的图中也是类似。其中红色的树状框表示客户端的线程阻塞。\n可以看到，客户端在代码片段2中，发起 RPC 调用，那么除非本次 RPC 彻底完成，或者 RPC 在指定时间内抛出超时异常，否则红框一直阻塞，代码片段3没有机会执行。\nFuture 异步调用 客户端发起调用后不会同步等待服务端的结果，而是获取到 RPC框架给到的一个 Future 对象，调用过程不会阻塞线程，然后继续执行后面的业务逻辑。服务端返回响应结果被 RPC 缓存，当客户端需要响应结果的时候需要主动获取结果，获取结果的过程阻塞线程。\n如上图所示，代码片段2发起 RPC 调用后，RPC 框架会立刻返回一个 Future 对象。给到代码片段2，代码片段2可以选择等待结果，或者也可以继续执行代码片段3，等代码片段3执行完成后，再获取 Future 中的值。\nCallback 回调调用 客户端提前设置回调实现类，在发起调用后不会等待结果，但是注意此时是通过上下文或者其他方式向 RPC 框架注册了一个 Callback 对象，结果处理是在新的线程里执行。RPC在获取到服务端的结果后会自动执行该回调实现。\n如图所示，客户端代码段2发起 RPC 调用后，并不关心结果，此时也不会有结果。只是将自己的一个 Callback 对象传递给 RPC 框架，RPC 框架发起调用后，立即返回。之后自己等待调用结果，在有了调用结果，或者超过业务配置的超时时间后，将响应结果或者超时的异常，进行 callback 的回调。一般的，一个 callback 的结果需要包含两个部分\npublic interface InvokeCallback { /** * Response received. * * @param result */ public void onResponse(final Object result); /** * Exception caught. * * @param e */ public void onException(final Throwable e); } 如果是正常返回，则 RPC 框架回调用户传入 callback 对象的 onResponse 方法，如果是框架层的异常，比如超时，那么会调用 onException 方法。\nOneway 单向调用 客户端发送请求后不会等待服务端返回的结果，并且会忽略服务端的处理结果，\n当前线程发起调用后，用户并不关心调用结果，只要请求已经发出就完成本次调用。单向调用不关心响应结果，请求线程不会被阻塞，使用 Oneway 调用需要注意控制调用节奏防止压垮接收方。注意 Oneway 调用不保证成功，而且发起方无法知道调用结果。因此通常用于可以重试，或者定时通知类的场景，调用过程是有可能因为网络问题、机器故障等原因导致请求失败，业务场景需要能接受这样的异常场景才能够使用。\n调用方式比较 调用方式 优点 不足 使用场景 Sync 简单 同步阻塞 大部分场景 Oneway 简单，不阻塞 无结果 不需要结果，业务不需要保证调用成功的场景 Future 异步，可获取结果 需要再次调用 get 方法获取结果 同线程内多次 RPC 调用。且没有先后关系 Callback 异步，不需要手动获取结果 使用稍微复杂。且不能在当前代码段直接操作结果 当前不关心结果。但是最终依赖结果做一些其他事情的场景 源码剖析 下面我们以 SOFARPC 中的 BOLT 协议为基础，介绍一些 RPC 框架下面的代码层面的设计。主要介绍代码结构和相互的调用关系。\n对 BOLT 的包装主要在\ncom.alipay.sofa.rpc.transport.bolt.BoltClientTransport 业务方并不直接使用 BOLT 定义的一些类型，而是使用 RPC 定义的一些类型。这些类型被适配到 BOLT 的类型上，使得 RPC 框架对用户提供了统一的 API，和底层是否采用 BOLT 不强相关。\nSync 同步调用 SOFARPC 中的的同步调用是由 Bolt 通信框架来实现的。核心代码实现在\ncom.alipay.remoting.BaseRemoting#invokeSync com.alipay.remoting.rpc.protocol.RpcResponseProcessor#doProcess 使用时无需特殊配置。\nFuture 异步调用 使用 Future 异步调用 SOFABoot 配置服务引用需要设置\n\u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; 元素的 type 属性声明调用方式为 future：\n如上设置为 Future 调用的方式。客户端获取响应结果有两种方式：\n1.通过 SofaResponseFuture 直接获取结果。第一个参数是获取结果的超时时间，第二个参数表示是否清除线程上下文中的结果。\nString result =(String)SofaResponseFuture.getResponse(timeout,true); 2.获取原生 Futrue，该种方式获取JDK原生 …","date":1536130800,"description":"本文为《剖析 | SOFARPC 框架》第四篇。","dir":"blog/sofa-rpc-synchronous-asynchronous-implementation/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d7ab7dabc882ef32b491dc6ce551fc39","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","publishdate":"2018-09-05T15:00:00+08:00","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 同步异步实现剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/","wordcount":3596},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第三篇，本篇由米麒麟/碧远共同出品。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 前言 在 RPC 调用过程中，我们经常会和多个服务端进行远程调用，如果在每次调用的时候，都进行 TCP 连接，会对 RPC 的性能有比较大的影响，因此，实际的场景中，我们经常要对连接进行管理和保持。\nSOFARPC 应用心跳包以及断线重连实现,结合系统 tcp-keepalive 机制，来实现对 RPC 连接的管理和保持。\n连接管理 首先我们将会介绍连接管理相关的一些背景知识。\n长连接和短连接 短连接，一般是指客户端向服务端发起连接请求。连接建立后，发送数据，接收服务端数据返回，然后触发连接断开，下次再重新重复以上过程。\n长连接，则是在建立连接后，发送数据，接收数据，但是不主动断开，并且主动通过心跳等机制来维持这个连接可用，当再次有数据发送请求时，不需要进行建立连接的过程。\n一般的，长连接多用于数据发送频繁，点对点的通讯，因为每个 TCP 连接都需要进行握手，这是需要时间的，在一些跨城，或者长距离的情况下，如果每个操作都是先连接，再发送数据的话，那么业务处理速度会降低很多，所以每个操作完后都不断开，再次处理时直接发送数据包即可，节省再次建立连接的过程。\n但是，客户端不主动断开，并不是说连接就不会断。因为系统设置原因，网络原因，网络设备防火墙，都可能导致连接断开。因此我们需要实现对长连接的管理。\nTCP 层 keep-alive tcp 的 keep-alive 是什么 tcp-keepalive，顾名思义，它可以尽量让 TCP 连接“活着”，或者让一些对方无响应的 TCP 连接断开，\n使用场景主要是：\n 一些特定环境，比如两个机器之间有防火墙，防火墙能维持的连接有限，可能会自动断开长期无活动的 TCP 连接。\n 还有就是客户端，断电重启，卡死等等，都会导致 TCP 连接无法释放。\n 这会导致：\n一旦有热数据需要传递，若此时连接已经被中介设备断开，应用程序没有及时感知的话，那么就会导致在一个无效的数据链路层面发送业务数据，结果就是发送失败。\n无论是因为客户端意外断电、死机、崩溃、重启，还是中间路由网络无故断开、NAT 超时等，服务器端要做到快速感知失败，减少无效链接操作。\n而 tcp-keepalive 机制可以在连接无活动一段时间后，发送一个空 ack，使 TCP 连接不会被防火墙关闭。\n默认值 tcp-keepalive，操作系统内核支持，但是不默认开启,应用需要自行开启，开启之后有三个参数会生效，来决定一个 keepalive 的行为。\nnet.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 75 可以通过如下命令查看系统 tcp-keepalive 参数配置。\nsysctl -a | grep keepalive cat /proc/sys/net/ipv4/tcp_keepalive_time sysctl net.ipv4.tcp_keepalive_time 系统默认值可以通过这个查看。\ntcp_keepalive_time，在 TCP 保活打开的情况下，最后一次数据交换到 TCP 发送第一个保活探测包的间隔，即允许的持续空闲时长，或者说每次正常发送心跳的周期，默认值为 7200s（2h）。 tcp_keepalive_probes 在 tcp_keepalive_time 之后，没有接收到对方确认，继续发送保活探测包次数，默认值为 9（次）。 tcp_keepalive_intvl，在 tcp_keepalive_time 之后，没有接收到对方确认，继续发送保活探测包的发送频率，默认值为 75s。\n这个不够直观，直接看下面这个图的说明：\n如何使用 应用层，以 Java 的 Netty 为例，服务端和客户端设置即可。\nServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 100) .childOption(ChannelOption.SO_KEEPALIVE, true) .handler(new LoggingHandler(LogLevel.INFO)) .childHandler(new ChannelInitializer\u0026amp;lt;SocketChannel\u0026amp;gt;() { @Override public void initChannel(SocketChannel ch) throws Exception { ch.pipeline().addLast( new EchoServerHandler()); } }); // Start the server. ChannelFuture f = b.bind(port).sync(); // Wait until the server socket is closed. f.channel().closeFuture().sync(); 就是这里面的ChannelOption.SO_KEEPALIVE, true 对应即可打开.\n目前 bolt 中也是默认打开的.\n.childOption(ChannelOption.SO_KEEPALIVE, Boolean.parseBoolean(System.getProperty(Configs.TCP_SO_KEEPALIVE, \u0026amp;quot;true\u0026amp;quot;))); Java 程序只能做到设置 SO_KEEPALIVE 选项，至于 TCP_KEEPCNT，TCP_KEEPIDLE，TCP_KEEPINTVL 等参数配置，只能依赖于 sysctl 配置，系统进行读取。\n检查 查看 tcp 连接 tcp_keepalive 状态\n我们可以用 netstat -no|grep keepalive 命令来查看当前哪些 tcp 连接开启了 tcp keepalive. 应用层 keep-alive 应用层 keep-alive 方案，一般叫做心跳包，跟 tcp-keepalive 类似，心跳包就是用来及时监测是否断线的一种机制，通过每间隔一定时间发送心跳数据，来检测对方是否连接，是属于应用程序协议的一部分。\n心跳是什么 心跳想要实现的和 tcp keep-alive 是一样的。\n由于连接丢失时，TCP 不会立即通知应用程序。比如说，客户端程序断线了，服务端的 TCP 连接不会检测到断线，而是一直处于连接状态。这就带来了很大的麻烦， …","date":1535526000,"description":"本文为《剖析 | SOFARPC 框架》第三篇，本篇由米麒麟/碧远共同出品。","dir":"blog/sofa-rpc-connection-management-heartbeat-analysis/","fuzzywordcount":4300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2f911034e6bec76b8b0496b7f06e10b7","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","publishdate":"2018-08-29T15:00:00+08:00","readingtime":9,"relpermalink":"/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之SOFARPC 连接管理与心跳剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/","wordcount":4225},{"author":"SOFARPCLab","categories":"SOFARPC","content":" SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 | SOFARPC 框架》第二篇，本篇由畅为/碧远/卓与共同出品。 《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品。\n 一. 前言 微服务已经被广泛应用在工业界，微服务带来易于团队并行开发、独立部署、模块化管理等诸多优点。然而微服务将原单体拆分多个模块独立部署，各模块之间链接变得错综复杂，在大规模分布式系统中这种复杂链路给维护带来了诸多困难。 如果对整个微服务架构不能了然于胸，便很难理清各模块之间的调用关系。 例如修改一个服务接口，对哪些服务造成影响不能快速定位。\nSOFARPC 在5.4.0 以后提供了链路追踪技术，可以有效协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。\n如思维导图所示，本文将从以下几个方面介绍目前已经开源的 SOFARPC 的链路追踪技术：\n二. 什么是链路追踪技术 链路追踪技术主要是收集、存储、分析分布式系统中的调用事件数据，协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。 链路追踪技术包含了数据埋点、收集、存储、分析等相关技术，是一套技术体系。 大部分的链路追踪框架都是参考 google链路追踪系统Dapper 的一篇设计论文（《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 ），SOFARPC 的SOFATracer 的设计灵感也是来自这篇著名论文。\n以大规模分布式电商系统为例，用户下单购买某款产品时后端需要调用各系统或子模块进行协作，共同完成一个用户请求。 如下图所示，用户的下单行为涉及到了A、B、C、D、E、F 6个系统的协同工作，这些系统都是以集群形式部署。整个链路中最长的链路调用是3层，如 A-\u0026amp;gt; C -\u0026amp;gt; E 或 A -\u0026amp;gt; C -\u0026amp;gt; F。\n模块的增多加大了系统出错的概率，一旦因某系统/模块出错导致整个请求调用出错，在缺乏链路追踪的条件下很难定位具体出错的模块，只能通过日志搜索定位。 在实际生产环境下比较关注一个请求中的各个模块的耗时情况、连续调用情况、出错的节点等信息。 为了解决上述问题，Dapper提供了一套解决方案。整个方案分为数据收集、存储和分析几个部分。分布式追踪技术会记录一个请求中各模块的调用信息；并通过一个处理集群把所有机器上的日志增量地收集到集群当中进行处理，将同一个请求的日志串联；最后可视化显示调用情况。\n常用的数据收集方式为埋点，通过在公共组件如RPC等注入代码，收集服务调用的相关信息。目前大部分链路调用系统如Dapper、鹰眼、Spring Cloud Sleuth 都在用这种模式。同样SOFARPC 作为一个公共的通讯框架，在金融业务领域被广泛应用，因此适合作为埋点，这样无需业务端自行埋点，可做到对业务代码的无侵入性。\nDapper 将一个调用过程构建成一棵调用树(称为Tracer)，Tracer树中的每个节点表示链路调用中的一个模块或系统。 通过一个全局唯一的 traceId 来标识一个请求调用链。 并定义了span，span表示一个系统的调用，一个span 包含以下阶段：\n Start: 发起调用\n cleint send(cs): 客户端发送请求\n Server Recv(sr)：服务端收到请求\n Server Send(ss): 服务端发送响应\n Client Recv(cr) : 客户端收到服务端响应\n End： 整个链路完成\n 每个span 包含两个重要的信息 span id(当前模块的span id) 和 span parent ID(上一个调用模块的span id)，通过这两个信息可以定位一个span 在调用链的位置。 通过以上信息我们可以定义用户下单过程的调用链：\nSOFARPC中的链路追踪技术主要是作为埋点部分，因此对于链路追踪系统的收集和分析部分本文不做详述，想要深入了解的可参看参考资料内容。链路追踪可以提供我们以下功能:\n 服务耗时、瓶颈分析 ：分析每个服务的耗时情况，可以针对耗时长的服务进行优化，提高服务性能。\n 可视化错误：快速定位服务链路中出错的环境，便于排查和定位问题。一般链路追踪中间件都提供了ZipKin 页面支持。\n 链路优化: 对于调用比较频繁的服务，可以针对这些服务实施一些优化措施。\n 调用链路梳理：通过可视化界面，对整个调用链路有个清晰的认识。\n 在设计分布式链路框架时需要考虑一下几个问题：\n 低损耗、高性能: 追踪系统对在线服务的影响应该做到足够小，不影响线上服务性能。\n 应用透明: 对于业务开发人员来说，应不需要知道有跟踪系统这回事的。\n 可扩展性：虽则业务规则增大、集群增多，监控系统都应该能完全把控住这种快速变化。\n 数据采样设计：如果每条日志都记录，在高并发情况下对系统有一定的损耗。但收集数据太少可能对统计结果有所影响，所以应合理设计采样比例。\n 三. SOFARPC 链路追踪设计原理 SOFARPC 作为一个基础的通讯中间件，对服务调用有很强的感知能力，容易获取链路追踪所需的服务调用信息。因此很多链路追踪系统都会选择RPC 作为埋点对象，通过对RPC中间件的埋点可以轻松做到对用户的无感知、透明化。 SOFARPC在5.4.0 以后开始支持分布式链路追踪，其技术实现主要依赖于所集成的SOFATracer。\nSOFARPC 不仅提供了埋点信息采集的能力, 还支持数据上报zipkin。 通过SOFARPC + SOFATracer + zipKin 可以快速搭建一套完整的链路追踪系统，包括埋点、收集、分析展示等。 收集和分析主要是借用zipKin的能力，本文重点讲SOFARPC中的数据埋点设计。SOFARPC自身具备的微内核设计和可拓展性，使得在SOFARPC在不破坏开放封闭原则的前提下，比较轻松地集合SOFATracer。该部分主要从以下几个方面讨论SOFARPC的链路追踪设计思路：\n 可插拔设计。 SOFARPC采用了微内核设计，使得很容易扩展，增加新功能。\n 总线设计。为数据埋点做提供一种无侵入的扩展方式。\n 调用trace和span\n 数据采样设计\n 异步刷新机制\n 耗时计算：链路调用的耗时统计等信息获取。\n 埋点数据透传，各模块之间的链路调用数据的透传机制。\n 异步线程的链路调用。在异步多线程环境下如何保证traceId和spanId的有序性。\n 链路调用日志数据的文件存储结构\n 3.1 可插拔设计 SOFARPC自身具备的微内核设计和可拓展性，使得在SOFARPC在不破坏开放封闭原则的前提下，比较轻松地集合SOFATracer。SOFARPC 采用了自己实现的一套SPI机制， 通过该SPI机制动态去加载其他模块、过滤器、协议等，实现灵活拓展。SOFARPC 为了集成SOFATracer也采用了这套机制，做到可插拔。\nSofaTracerModule 类实现了Module …","date":1534921200,"description":"本文为《剖析 | SOFARPC 框架》第二篇，本篇由畅为/碧远/卓与共同出品。","dir":"blog/sofa-rpc-link-tracking/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"09e24cfad0d59d40a509e893f26c59ef","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-link-tracking/","publishdate":"2018-08-22T15:00:00+08:00","readingtime":13,"relpermalink":"/sofastack.tech/blog/sofa-rpc-link-tracking/","summary":"SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 本文为《剖析 |","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之 SOFARPC 链路追踪剖析","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-link-tracking/","wordcount":6480},{"author":"碧远","categories":"SOFARPC","content":" 前言 RPC 框架作为分布式技术的基石，在分布式和微服务环境下，扮演着非常重要的角色。\n在蚂蚁金服的分布式技术体系下，我们大量的技术产品（非网关类产品），都需要在内网，进行节点间通信。底层通信框架，已经在蚂蚁自研的 BOLT中的进行了实践，BOLT 提供了优秀的通信协议与通信框架，在 BOLT 的基础上，我们研发了自己的 RPC 框架，提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等基础能力，本文将从以下几个方面介绍目前已经开源的 SOFARPC 框架。\n RPC 是什么 通用 RPC 框架原理 SOFARPC 框架设计 RPC是什么 RPC 这个概念术语在上世纪 80 年代由 Bruce Jay Nelson 提出，在 Nelson 的论文 \u0026amp;ldquo;Implementing Remote Procedure Calls\u0026amp;rdquo; 中他提到了几点：\n 简单：RPC 概念的语义清晰,简单，方便建立分布式计算。 高效：在使用方看来,十分简单而且高效。 通用：通用,适用于各种不同的远程通信调用。 这里面Nelson提出了一个 RPC框架应该包含的几个部分。\n User User-stub RPC-Runtime Server-stub Server 如下图示，为了和现在我们通用的术语一致，我将 User 改成 Client 了。\n当 Client 想发起一个远程调用时，实际是通过本地调用 Client-stub，而 Client-stub 负责将调用的接口、方法和参数通过约定的协议规范进行编码并通过本地的 RPC-Runtime 实例传输到远端的实例。远端 RPC-Runtime 实例收到请求后交给 Server-stub 进行解码后发起本地端调用，在 Java中可以认为就是反射调用,调用结果再返回给 Client 端。\n从上文可以看到，一个典型的 RPC 调用过程还是相对简单的。但是实际上，一个真正的 RPC 框架要做的远不止这些。\n通用 RPC 框架原理 相信对 RPC 框架有过一定了解，或者使用过 RPC 产品的同学，在看到了图上之后，会产生几个疑问：\n1.Stub 怎么出现？\n2.怎么打包参数？\n3.怎么传输?\n4.怎么知道目标地址?\n5.怎么发布一个 RPC 服务?\n在解释这些问题之前，这里我画了一张目前通用的 RPC 框架的一个流程图：\n其中：\n1.创建代理解决了 Stub 的问题。\n2.序列化和网络协议编码解决了打包的问题。\n3.服务发现与路由寻址解决了如何知道目标地址的问题。\n4.如何发布一个服务，Registry 来解决。\n Bolt，Netty 等解决了网络传输的问题。 当然 SOFARPC 的功能不止这些,在解决了这些问题之后，根据业务的需求和实际的线上情况，我们也开发了熔断,限流,故障剔除,数据透传等能力，下面我会来介绍 SOFARPC 的框架设计。\nSOFARPC框架设计 SOFARPC RoadMap 首先介绍下目前 SOFARPC 的现状和一些正在做的事情。\n欢迎对相关功能和 feature 有兴趣的同学，一起参与开发~\nSOFARPC 结构设计 原理大家清楚之后，为了方便大家尽快上手开发使用，我先从目前的 RPC 框架结构来简单介绍。\n其中 core和 core-impl 是核心的功能，包含 API 和一些扩展机制，extension-impl 中，则包含了不同的实现和扩展，比如对 http，rest，对 metrics，以及其他注册中心的集成和扩展。\n如 bootstrap 中对协议的支持，remoting 中对网络传输的支持，registry 中对注册中心的支持等。\n在此基础上，由于 RPC 框架涉及服务端和客户端，我会结合 SOFARPC 的处理流程，详细介绍下客户端和服务端的处理。\n客户端调用流程 当使用方对服务进行了引用配置之后：\n1.RPC 生成 Proxy，作为用户可以操作的入口。\n2.向服务中心订阅这个 RPC 的地址信息。\n3.使用方发起调用，经过路由，负载均衡，各类 Filter 发起调用。\n服务端处理流程 在服务端看来,通过 TCP 监听端口后：\n1.接到 RPC 请求后，进行解码和反序列化。\n2.选择线程池，进行分发。\n3.经过 Filter，进行反射调用。\n4.将结果序列化，编码,进行写回。\n可扩展的机制 从上面的流程中，可以看到，每个部分基本都有多种实现可选，这得益于RPC的扩展机制。\n为了对 RPC 各个环节的都有充足的可扩展性，提供 SPI 的能力，所以内部的实现和第三方实现都是绝对平等的。\n相比原生 SPI，我们实现了更强大的功能\n 按需加载\n 可以有别名\n 可以有优先级进行排序和覆盖\n 可以控制是否单例\n 可以在某些场景下使用编码\n 可以指定扩展配置位置\n 可以排斥其他扩展点\n 我们实现了一套自己的 SPI 机制。整个流程如下：\n在启动加载阶段，RPC 会根据对应的配置，加载需要调用方法ExtensionLoader(Class\u0026amp;lt;T\u0026amp;gt; interfaceClass, ExtensionLoaderListener\u0026amp;lt;T\u0026amp;gt; listener) 逻辑如下：\n 首先读取rpc-config-default.json和rpc-config.json，找到扩展描述文件存放的文件夹：extension.load.path属性。\n 找到接口类对应的扩展描述文件的文件名（默认就是接口名，也可以自己指定）。\n 循环加载这个文件下的扩展描述文件，按行读取。（同一个接口的同一个别名对应唯一的一个实现类，可以重复，允许覆盖。）\n 保存扩展实现类的alias和实现类的对应关系。\n 如果 ExtensionLoaderListener 不为空，则通知 Listener。\n 最终，将会构造出各个不同的 Filter，Invoker 等等。\n其中我们首先设计了一个扩展，代表这个类或者接口是可扩展的，默认单例、不需要编码。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * 指定自定义扩展文件名称，默认就是全类名 * * @return 自定义扩展文件名称 */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * 扩展类是否使用单例，默认使用 * * @return 是否使用单例 */ boolean singleton() default true; /** * 扩展类是否需要编码，默认不需要 * * @return 是否需要编码 */ boolean coded() default false; } 同时，针对具体的扩展实现，定义一个扩展注解\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * 扩展点名字 * * …","date":1533193200,"description":"本文为 剖析 SOFARPC 框架第一篇。","dir":"blog/sofa-rpc-framework-overall-extension/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d83b816009377f7f93fcd1edf63c534d","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","publishdate":"2018-08-02T15:00:00+08:00","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","summary":"前言 RPC 框架作为分布式技术的基石，在分布式和微服务环境下，扮演着非常重要的角色。 在蚂蚁金服的分布式技术体系下，我们大量的技术产品（非网关类产品","tags":["SOFARPC","剖析 | SOFARPC 框架","SOFALab"],"title":"【剖析 | SOFARPC 框架】之总体设计与扩展机制","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-framework-overall-extension/","wordcount":2629},{"author":"鲁直","categories":"SOFABoot","content":" 无论是什么样的业务系统，多多少少都会去做一些模块化的划分，或横或纵，各种姿势，但是这些姿势真地能帮你划分出良好的模块吗？帮你在模块之间做到高内聚，低耦合吗？模块化对于服务化又有什么样的影响？本来将分析常见的几种模块化方案的利弊，并且介绍蚂蚁金服开源的框架 SOFA 在模块化中发挥的作用。\n传统模块化的陷阱 在一个简单的 Spring/SpringBoot 的系统中，我们常常见到一个系统中的模块会按照如下的方式进行分层，如下图中的左边部分所示，一个系统就简单地分为 Web 层、Service 层、DAL 层。\n当这个系统承载的业务变多了之后，系统可能演化成上图中右边的这种方式。在上图的右边的部分中，一个系统承载了两个业务，一个是 Cashier（收银台），另一个是 Pay（支付），这两个业务可能会有一些依赖的关系，Cashier 需要调用 Pay 提供的能力去做支付。\n但是在这种模块化的方案里面，Spring 的上下文依然是同一个，类也没有任何做隔离，这就意味着，Pay Service 这个模块里面的任何的一个 Bean，都可以被 Cashier Service 这个模块所依赖。极端的情况下，可能会出现下面这种情况：\nCashier Service 错误地调用了 Pay Service 中的一个内部的 Bean，造成了两个模块之间的紧耦合。\n这种传统的模块化的问题在于模块化地不彻底。虽然在研发的时候，通过划分模块，把特定职责的类放到特定的模块里面去，达到了类的「物理位置」的内聚。但是在运行时，由于没有做任何隔离的手段，作为一个模块的开发者，并没有办法清楚地知道对方模块提供的对外的接口到底是什么，哪些 Bean 我是可以直接注入来用的，哪些 Bean 是你的内部的 Bean，我是不能用的。长此以往，模块和模块之间的耦合就会越来越严重，原来的模块的划分形同虚设。当系统越来越大，最后需要做服务化拆分的时候，就需要花费非常大的精力去梳理模块和模块之间的关系。\nOSGi 模块化 提到模块化，不得不提 OSGi，虽然 OSGi 没有成为 Java 官方的模块化的标准，但是由于 Java 在 Java 9 之前，一直没有官方的模块化的标准，所以 OSGi 已经是事实上的标准。\nOSGi 为模块化主要做了两个事情：\n OSGi 的类隔离 OSGi 的声明式服务 下面就给读者们简单地解释一下 OSGi 的这两个方面。\nOSGi 的类隔离 OSGi 通过扩展 Java 的 ClassLoader 机制，将模块和模块之间的类完全隔离开来，当一个模块需要引用另一个模块的类的时候，通过在模块中的 MANIFEST.MF 文件中声明类的导出和导入来解决，如下图所示：\n通过这种方式，可以控制一个模块特定的类才可以被另一个模块所访问，达到了一定程度地模块的隔离。\n但是，光光通过类的导出导入来解决类的引用问题还不够，还需要去解决实例的引用的问题，我们往往希望能够直接使用对方模块提供的某一个类的实例，而不是自己去 new 一个实例出来，所以 OSGi 还提供了声明式服务的方式，让一个模块可以引用到另一个模块提供的服务。\nOSGi 的声明式服务 OSGi 的声明式服务正是为了解决这个实例引用的问题，我们可以在一个 OSGi 的模块（Bundle）中去添加一个 XML 配置文件去声明一个服务，如下面的代码所示：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;scr:component xmlns:scr=\u0026amp;quot;http://www.osgi.org/xmlns/scr/v1.1.0\u0026amp;quot; name=\u0026amp;quot;ITodoService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;implementation class=\u0026amp;quot;com.example.e4.rcp.todo.service.internal.MyTodoServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;service\u0026amp;gt; \u0026amp;lt;provide interface=\u0026amp;quot;com.example.e4.rcp.todo.model.ITodoService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/service\u0026amp;gt; \u0026amp;lt;/scr:component\u0026amp;gt; 也可以同样的通过 XML 配置文件去引用一个其他的模块声明的服务：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;scr:component xmlns:scr=\u0026amp;quot;http://www.osgi.org/xmlns/scr/v1.1.0\u0026amp;quot; name=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;reference name=\u0026amp;quot;ITodoService\u0026amp;quot; interface=\u0026amp;quot;com.example.e4.rcp.todo.model.ITodoService\u0026amp;quot; bind=\u0026amp;quot;setITodoService\u0026amp;quot; cardinality=\u0026amp;quot;0..1\u0026amp;quot; unbind=\u0026amp;quot;unsetITodoService\u0026amp;quot; policy=\u0026amp;quot;dynamic\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;implementation class=\u0026amp;quot;com.example.e4.rcp.todo.service.internal.XXXServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/scr:component\u0026amp;gt; 通过声明式服务的方式，我们就可以直接在一个 OSGi 的 Bundle 中使用另一个 Bundle 中提供的服务实例了。\nOSGi 的模块化的问题 OSGi 通过类隔离的机制解决了模块之间的类隔离的问题，然后通过声明式服务的方式解决了模块之间的服务调用的问题，看起来已经完美的解决了我们在传统的模块化中遇到的问题，通过这两个机制，模块和模块之间的边界变得清晰了起来。\n但是在实践的过程中，OSGi 的模块化却面临着一个非常严峻的问题，这个就是就是 OSGi 的类隔离带来的复杂性，OSGi 把每一个模块都通过独立的 ClassLoader 去加载，这样在开发模块的时候，研发的同学就必须非常清楚地去定义哪些类应该导出，哪些类应该导入，一旦少导出，或者导出错误，就会出现各种各样的错误，比如 LinkageError，NoSuchMethodError 等等，而要解决这些错误，要求研发同学清楚地理解 OSGi 的整个类加载体系，以及 Java 的整个类加载体系，这对普通的研发同学来说实在是一个太高的要求。所以这种方式在实施成本非常高，OSGi 并不是非常适合于业务研发。\nSOFA 模块化 为了解决传统的模块化方案模块化不彻底的问题，以及 OSGi 的彻底的模块化带来的复杂性的问题，SOFA 在早期就开始引入了一种折衷的模块化的方案。\nSOFA 模块化的整体的示意图如下：\nSOFA 模块化的方 …","date":1532520754,"description":"本来将分析常见的几种模块化方案的利弊，并且介绍蚂蚁金服开源的框架 SOFA 在模块化中发挥的作用。","dir":"blog/sofastack-modular-isolation/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"796c3ab365dd1191a7777c4dbf9d0a1b","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-modular-isolation/","publishdate":"2018-07-25T12:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-modular-isolation/","summary":"无论是什么样的业务系统，多多少少都会去做一些模块化的划分，或横或纵，各种姿势，但是这些姿势真地能帮你划分出良好的模块吗？帮你在模块之间做到高","tags":["SOFABoot"],"title":"蚂蚁金服的业务系统模块化之模块化隔离方案","type":"blog","url":"/sofastack.tech/blog/sofastack-modular-isolation/","wordcount":2688},{"author":"玄北","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力，SOFABoot 模块除了包括 Java 代码外，还会包含 Spring 配置文件，每个 SOFABoot 模块都是独立的 Spring 上下文。\n1. 背景 为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式：\n 基于代码组织上的模块化：这是最常见的形式，在开发期，将不同功能的代码放在不同 Java 工程下，在编译期被打进不同 jar 包，在运行期，所有 Java 类都在一个 classpath 下且使用同一个 Spring 上下文，没做任何隔离； 基于 Spring 上下文隔离的模块化：使用 Spring 上下文来做不同功能模块的隔离，在开发期和编译期，代码和配置也会分在不同 Java 工程中，但在运行期，不同的 Spring Bean 相互不可见，IoC 只在同一个上下文内部发生，但是所有的 Java 类还是在一个 ClassLoader 下； 基于 ClassLoader 隔离的模块化：借用 ClassLoader 来做隔离，每个模块都有独立的 ClassLoader，模块与模块之间的 classpath 不同，SOFAArk 就是这种模块化的实践方式。 以上三种模块化形式的隔离化程度逐次递进，但模块化就像一把双刃剑，在降低模块间耦合的同时也给模块间交互增加了成本，本文介绍第二种模块化形式 —— 基于 Spring 上下文隔离的模块化。\n与基于代码组织上的模块化相比，每个 SOFABoot 模块不仅仅包括 Java 代码，还会包含 Spring 配置文件，这种全新的包组织方式大大降低了用户接入成本，用户只需要简单的引入 Jar 包即可，由 SOFABoot 框架负责刷新模块上下文，无需在原来 Spring 配置文件中新增任何 Bean 定义，简化了接入流程，降低了出错几率。\n每个 SOFABoot 模块的 Spring 上下文都是隔离的。在 Spring 开发中，保证 Spring BeanId 不冲突是 Spring 运行的基础，这个限制在应用规模较小时很容易解决，只需用户在定义 BeanId 时稍加注意即可。但是随着系统规模越来越大，一个系统的开发往往涉及多个团队，保证每个业务定义 BeanId 不重复的成本也越来越高。在 SOFABoot 中，每个 SOFABoot 模块使用独立的 Spring 上下文，避免了不同 SOFABoot 模块间 BeanId 冲突，有效降低企业级多模块开发时团队间的沟通成本。\n2. 基本原理 在介绍 SOFABoot 模块化开发使用之前，我们简单了解下其背后的实现原理。下图是应用运行时的逻辑视图：\nSOFABoot 模块是模块化开发的最小单元，每个 SOFABoot 模块是一个独立的 Spring 上下文，在 SOFABoot 模块中我们可以定义Bean、发布 RPC 服务、连接数据库等等。\n由于上下文隔离，模块与模块之间的 Bean 无法通过 @Autowired 依赖注入，我们提供了 JVM Service/Reference 的方式进行模块间通信。SOFABoot 提供了两种形式的服务发布和引用，用于解决不同级别的模块间调用问题：\n JVM 服务发布和引用：解决一个 SOFABoot 应用内部各个 SOFABoot 模块之间的调用问题 RPC 服务发布和引用：解决多个 SOFABoot 应用之间的远程调用问题 Spring Boot 应用在调用 SpringApplication.run 时会创建一个 Spring Context，我们把它叫做 Root Application Context，它是每个 SOFABoot 模块创建的 Spring Context 的 Parent。这样设计的目的是为了保证每个 SOFABoot 模块的 Spring Context 都能发现 Root Application Context 中创建的 Bean，这样当应用新增 Starter 时，不仅 Root Application Context 能够使用 Starter 中新增的 Bean，每个 SOFABoot 模块的 Spring Context 也能使用这些 Bean。\n下面我们来演示如何开发一个简单的 SOFABoot 模块。\n3. 编写 SOFABoot 模块 3.1 新建工程 DEMO 工程地址\n运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，并创建两个普通的 Maven 模块：\n service-facade: 定义服务接口 service-provide: 演示新建 SOFABoot 模块并发布 JVM 服务 3.2 定义服务接口 service-facade 模块包含用于演示 SOFABoot 模块发布与引用服务接口:\npublic interface SampleService { String message(); } 3.3 定义 SOFABoot 模块 service-provider 是一个 SOFABoot 模块，它会发布一个 JVM 服务供其他模块使用。首先需要为 service-provider 模块增加 sofa-module.properties 文件，将其定义为 SOFABoot 模块，sofa-module.properties 文件放置在 resources 目录:\nModule-Name=com.alipay.sofa.service-provider 3.4 发布服务 SOFABoot 支持三种形式的服务发布，分别是： XML 方式、Annotation 方式以及 API 编码方式，这里演示的是 XML 方式发布服务。\n首先增加 SampleServiceImpl 类，实现 SampleService 接口：\npublic class SampleServiceImpl implements SampleService { private String message; public String message() { return message; } public String getMessage() { return message; } public void setMessage(String message) { this.message = message; } } 增加 META-INF/spring/service-provide.xml 文件，将 SampleServiceImpl 发布为 JVM 服务:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; …","date":1532175154,"description":"本文是对蚂蚁金服开源的 SOFABoot 模块化开发的介绍。","dir":"blog/sofa-boot-modular-development/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"12a378e9b4d93d3dd89e79964b63d186","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-modular-development/","publishdate":"2018-07-21T12:12:34Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-boot-modular-development/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力，SOFABoot 模块除","tags":["SOFABoot"],"title":"基于 SOFABoot 进行模块化开发","type":"blog","url":"/sofastack.tech/blog/sofa-boot-modular-development/","wordcount":2209},{"author":"善逝","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力，以更好地解决随着工程应用变得臃肿庞大后带来的包冲突问题。类隔离能力天生带来模块化能力，同样给协作开发带来便利。\nSOFABoot 的类隔离能力借助单独的组件 SOFAArk 实现，遵循 Spring Boot 依赖即服务的思想，只要工程中引入了 SOFAArk 组件依赖，类隔离能力即生效。\n在上一篇文章 《在 Spring Boot 中集成 SOFABoot 类隔离能力》中，我们详细介绍了 SOFABoot 类隔离能力的使用背景及其使用方式。本文将介绍 SOFABoot 类隔离组件 SOFAArk 的实现原理。\n理解 SOFAArk 三要素 SOFAArk 类隔离框架定义了三个概念，Ark Container，Ark Plugin，Ark Biz。\n在介绍这三个主角之前，我们先来介绍另一个管家：Ark 包。我们都知道一个标准的 Spring Boot 应用可以借助 Spring 官方提供的打包插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 将应用打包成一个可执行 FatJar。相对应的，Ark 包则是 SOFABoot 官方提供的打包插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 将应用打包成一个具有类隔离能力的可执行 FatJar，称之为 Ark 包。下图是粗略地对比两者的目录结构差别：\n可以看到 Ark 包作为应用部署包的分发格式，它包含有 Ark Container，Ark Plugin 和 Ark Biz 三种格式模块。这里我们不对 Ark 包或者其他格式模块的目录结构作分析，感兴趣的同学可以点开文末附上的相关链接。我们重点介绍这三个角色的功能。\n Ark Container: Ark 容器，是组件 SOFAArk 的核心，运行 Ark 包时，Ark 容器会最先启动，负责应用运行时的管理，主要包括构建 Ark Plugin 和 Ark Biz 的类导入导出关系表、启动并初始化 Ark Plugin 和 Ark Biz、管理 Ark Plugin 服务的发布和引用等等。 Ark Plugin: SOFAArk 定义的一种模块格式，由若干个 Jar 包组成的一个 FatJar，开发人员可以借助官方提供的 maven 打包插件将若干 Jar 包打包成一个 Ark Plugin 供应用依赖。运行时，由独立的类加载器加载，因此有隔离需求的 Jar 包建议打包成 Ark Plugin 供应用依赖。 Ark Biz: SOFAArk 定义的一种模块格式，是应用及其依赖的所有三方包组成的一个 FatJar，需要注意的是，Ark Biz 不会包含应用依赖的 Ark Plugin。运行时，Ark Biz由独立的类加载器加载，借助类导入导出关系表，Ark Biz 可以使用 Ark Plugin 的导出类和资源。 SOFAArk 运行时隔离 根据上一节的描述可以知道 SOFABoot 类隔离关键是理解 SOFAArk 定义的三个概念，Ark Container，Ark Plugin 和 Ark Biz。下图表示的是应用启动后，运行时 Ark Container，Ark Plugin，Ark Biz 的逻辑分层图：\n我们将先以 Ark Plugin 入手来介绍 SOFABoot 类隔离的实现原理。\nArk Plugin 隔离 开发者借助 SOFABoot 官方提供的插件：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 可以将 Java 模块打包成一个 Ark Plugin，这里我们不讨论该打包插件的配置参数和使用方式，感兴趣的同学可以点开文末附上的相关链接以及学习 SOFABoot 类隔离能力使用篇。只需要知道，Ark Plugin 主要包含元信息有：插件启动器、导出类、导入类、导出资源、导入资源、优先级等，这些元信息保存在 Ark Plugin 中的 META-INF/MANIFEST.MF 中，一份典型的 MANIFEST.MF 文件样式如下：\nManifest-Version: 1.0 groupId: com.alipay.sofa artifactId: sample-ark-plugin version: 0.3.0-SNAPSHOT priority: 1000 pluginName: sample-ark-plugin activator: com.alipay.sofa.ark.sample.activator.SamplePluginActivator import-packages: import-classes: import-resources: export-packages: com.alipay.sofa.ark.sample.common.*,com.alipay.sofa.ark.sample export-classes: com.alipay.sofa.ark.sample.facade.SamplePluginService export-resources: Sample_Resource_Exported 在上面我们提到，运行 Ark 包时，类隔离容器 Ark Container 会最先启动，然后 Ark Container 会接管整个应用的启动过程。针对 Ark Plugin 处理逻辑如下：\n 首先解析 Ark 包中引入的所有 Ark Plugin，读取插件元信息，构建类/资源导入导出关系索引表。 提前生成所有插件类加载器，每个 Ark Plugin 都使用独立的类加载器，管理插件类加载逻辑，借助第一步生成的类导入导出关系表，突破 Java 原生的双亲委派模型，可以委托其他插件加载所需类，构建一个类 OSGi 的网状类加载模型。 根据插件优先级，依次调用插件启动器。在插件启动器中，插件开发者可以向容器注册服务以方便其他插件引用，也可以引用其他插件发布的服务，及插件启动所需的初始化操作。 需要明确一点，为了让类加载模型足够简单，Ark 容器在启动任何插件前，会把所有的插件类加载器提前构建完毕。Ark Plugin 可以相互委托加载，插件优先级只是影响插件的启动顺序，而且也不强制 …","date":1528107154,"description":"本文将介绍 SOFABoot 类隔离组件 SOFAArk 的实现原理。","dir":"blog/sofa-boot-class-isolation-deep-dive/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"84c324f1230d57a0c4009566de91bb3c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","publishdate":"2018-06-04T10:12:34Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力，以更好地解决随着工程应用变得臃肿庞大后带来的包冲","tags":["SOFAArk","SOFABoot"],"title":"SOFABoot 类隔离原理剖析","type":"blog","url":"/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/","wordcount":3540},{"author":"余淮","categories":"SOFAStack","content":" 蚂蚁金服自主研发的分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件），包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\n一个多月前，蚂蚁金服开源了 SOFABoot 和 SOFARPC 两个组件，受到了社区的热烈欢迎，也收到了很多社区的反馈，其中就有提到目前开源的组件太少。\n本次 SOFA 中间件将继续开源微服务体系下的几个组件：包括分布式链路追踪（SOFATracer）客户端、Metrics监控度量（SOFALookout）客户端、SOFARPC 的 Nodejs 版实现。同时还开源了 SOFABoot 下的模块化开发框架，以及 SOFARPC 的 HTTP/2 能力等。\n下面将逐一进行简单介绍。\nSOFATracer SOFATracer 是一个用于分布式系统调用跟踪的中间件，通过统一的 traceId 将调用链路中的各种网络调用信息以日志或者上报的方式记录下来，以达到透视化网络调用的目的。这些日志可用于故障的快速发现，数据统计，服务治理等。为了解决在实施大规模微服务架构时的链路跟踪问题，SOFATracer 基于 OpenTracing（http://opentracing.io） 规范并扩展其能力，包括基于 Disruptor 高性能无锁循环队列的异步落地磁盘的日志打印能力，自定义日志格式，日志自清除和滚动能力，基于 SLF4J MDC 的扩展能力，统一的配置能力等。同时 SOFATracer 也对接了开源生态，可以选择将 Tracer 数据对接到 Zipkin 等开源产品。\nSOFATracer 的 Github 的地址是：https://github.com/sofastack/sofa-tracer ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFALookout SOFALookout 是一个利用多维度的 Metrics 对目标系统进行度量和监控的中间件。Lookout 的多维度 Metrics 参考 Metrics 2.0（http://metrics20.org/spec） 标准，提供一整套 Metrics 的处理，包括数据埋点、收集、加工、存储与查询等。SOFALookout 包括客户端与服务器端服务两部分，本次先开源客户端部分，服务端部分代码在整理中。 SOFALookout 客户端提供了一套 Metrics API 标准，通过它可以方便地对 Java 应用的 Metrics 进行埋点统计。为了方便使用，SOFALookout 客户端默认提供一些扩展模块，它们提供 JVM，OS 等基本 Metrics 信息的统计，遵循该扩展机制，我们可以自定义或集成更多的 Metrics 数据。另外，SOFALookout 客户端除了支持向 SOFALookout 服务端上报数据外，还支持与社区主流的相关产品，包括 Dropwizard,（SpringBoot）Actuator 以及 Prometheus 等进行集成和数据适配。\nSOFALookout 的 Github 的地址是：https://github.com/sofastack/sofa-lookout ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nEggjs 集成 每种语言都有自己最擅长的领域，跨语言友好性对于分布式架构也是非常重要的。在蚂蚁内部还有一套 Nodejs 版本的 SOFA 中间件的实现，包含了绝大部分 Java 版本的功能，并将它们集成到已经开源的企业级 Nodejs 框架 Eggjs（https://eggjs.org） 中，形成了一套完整的 Web MVC 和 BFF (Backend For Frontend) 解决方案。这套架构目前广泛应用于蚂蚁的 Web 开发和多端适配等场景，让各岗位有了更清晰的职责划分，服务端（一般是 Java）提供基于领域模型的 RPC 接口，前端调用接口拿到数据后进行剪裁和格式化，并实现人机交互。领域模型与页面数据是两种思维模式，通过分层可以很好地解耦，让彼此更专业高效。后面我们也会陆续开源 SOFA 中间件的 Nodejs 版本实现，本期会先放出 SOFARPC 相关的两个模块：\nSOFARPC Node 的 Github 的地址是：https://github.com/sofastack/sofa-rpc-node ， SOFABolt Node 的 Github 的地址是：https://github.com/sofastack/sofa-bolt-node ， 欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFABoot 在最新的 SOFABoot 2.4.0 版本中，SOFABoot 新增加了基于 Spring 上下文隔离的模块化开发能力。在企业级应用场景，随着应用系统模块的增多，每个业务模块之间的耦合也会越来越严重，业务模块的自测更加复杂，团队之间的沟通成本增加。模块化开发是该问题的有效解决方案，但是 Spring Boot 默认不支持模块化开发，所有 Bean 共用一个 Spring 上下文。为此，SOFABoot 提出 SOFABoot 模块的概念，每个业务团队专注于开发自己的 SOFABoot 应用模块，模块自包含模块的代码和配置，拥有独立的 Spring 上下文，便于开发及自测，减少团队间的沟通成本。SOFABoot 模块间通信使用 JVM 服务进行通信，避免模块之间的耦合；如果远程服务在本地其它本地模块中存在，可优先调本地提高性能。同时 SOFABoot 提供了模块并行启动及 Bean 异步初始化能力，大幅提高应用启动速度。\nSOFABoot 的 Github 的地址是：https://github.com/sofastack/sofa-boot ，欢迎大家使用反馈、贡献代码。（请将网址复制至浏览器中打开即可查看，下同。）\nSOFARPC 在最新的 SOFARPC 5.4.0 版本中，SOFARPC 基于事件扩展机制，集成了 SOFATracer 和 SOFALookout 两个微服务体系产品，完善了自身的服务监控度量以及分布式跟踪功能。用户可以通过 SOFATracer 对接到 Zipkin 查看服务调用跟踪信息，也可以通过 SOFALookout 对接到 Prometheus 查看服务度量信息。新版本的 SOFARPC 中还增加了 HTTP/1.1 和 HTTP/2 协议的支持，在跨语言等场景下可以快速通过标准的 HTTP 协议进行通信。SOFARPC 也与 Eggjs 进行了打通了 Bolt 协议，方面用户在 Java 和 Nodejs 之间高效通信。\nSOFARPC 的 Github 的地址 …","date":1527761554,"description":"本次 SOFA 中间件将继续开源微服务体系下的几个组件：包括分布式链路追踪（SOFATracer）客户端、Metrics监控度量（SOFALookout）客户端、SOFARPC 的 Nodejs 版实现。同时还开源了 SOFABoot 下的模块化开发框架，以及 SOFARPC 的 HTTP/2 能力等。","dir":"blog/sofastack-open-source-doubles/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"00f2a1c85bfe83bf9f25ef1af9c44366","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofastack-open-source-doubles/","publishdate":"2018-05-31T10:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofastack-open-source-doubles/","summary":"蚂蚁金服自主研发的分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件），包含了构建金融级云原生架构所需的各个组件，","tags":["SOFAStack"],"title":"蚂蚁金服分布式中间件开源第二弹：丰富微服务架构体系","type":"blog","url":"/sofastack.tech/blog/sofastack-open-source-doubles/","wordcount":2957},{"author":"善逝","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力。蚂蚁金服内部丰富的实践场景表明，类隔离能力对解决类冲突、版本管控有其特殊的优势。\nSOFABoot 的类隔离能力由单独的组件 SOFAArk 实现，相比业界遵循 OSGi（https://www.osgi.org/） 规范的 Equinox 或者 Felix，SOFAArk 专注于类隔离，简化了类加载模型，是一款更加轻量的类隔离框架。\n本文将介绍 SOFABoot 类隔离能力的背景及其使用方式。\n1. 背景 在 Java 世界中，依赖的 JAR 包之间相互冲突永远是一个痛，Spring Boot 采用统一的依赖管理机制规避了大部分依赖冲突问题。理想很美好，现实却很骨感，作为蚂蚁金服这类大体量的公司，各业务线纷繁复杂、基础服务组件繁多，很难做到对所有 JAR 包做统一管控，尤其涉及到多个跨团队模块组件相互依赖时，因为各自技术栈历史包袱的存在，难以有效统一冲突包版本。\n假设如下场景，工程需要引入两个三方组件：A 和 B，组件 A 需要依赖 Hessian 3，组件 B 需要依赖 Hessian 4，因为 Hessian 3 和 Hessian 4 是不兼容的。作为开发者，遇到这种包冲突问题，如果不借助类隔离框架，只能耗费精力升级到统一版本。\n为了彻底解决类似的包冲突问题，我们需要借助类隔离机制，使用不同的类加载器加载冲突的三方依赖包，进而做到在同一个应用运行时共存。\n基于此背景，SOFABoot 提供了一个轻量级的类隔离框架，也是本文的主角，SOFAArk。\n2. 基本原理 在介绍 SOFAArk 类隔离框架使用之前，我们简单了解下其背后的实现原理。正如前文中描述，SOFAArk 是通过独立的类加载器加载相互冲突的三方依赖包，从而做到隔离包冲突。那么我们不禁要问，SOFAArk 是如何区分应用中哪些依赖包是需要单独的类加载器加载呢？原因是 Ark Plugin，它是 SOFAArk 框架定义的一种特殊的 JAR 包文件格式，SOFAArk 框架会自动识别 Ark Plugin 这种特殊依赖。\n何为 Ark Plugin ? Ark Plugin 本质上是一个 FatJar，借助 SOFABoot 官方提供的 maven 打包插件，开发者可以把若干普通的 JAR 包打包成 Ark Plugin 供应用依赖或者把普通的 Java 模块改造成 Ark Plugin。通常来说，如果把一个普通 JAR 打包成 Ark Plugin，那么该 JAR 包依赖的其他三方包也会被打入同一个 Ark Plugin，默认情况下 SOFABoot 官方打包插件会自动把间接依赖也打入到 Ark Plugin。\n应用使用添加 maven 依赖的方式引入 Ark Plugin，运行时，SOFAArk 框架会自动识别应用的三方依赖包中是否含有 Ark Plugin，进而使用单独的类加载器加载。为了更加直观，下图是应用运行时逻辑分层图：\n可以看到，在应用运行时，SOFAArk 容器处于最底层，负责启动应用。应用依赖的所有 Ark Plugin 处于中间层，每个 Ark Plugin 都由 SOFAArk 容器使用独立的类加载器加载，相互隔离。应用业务代码及其他非 Ark Plugin 的普通三方依赖包，为了描述简单，统称为 Ark Biz，它运行在最上层，需要依赖中间层的 Ark Plugin。\n一个标准 Ark Plugin 会包含一些配置文件，主要包含导出类和导入类配置。导出类即把 Ark Plugin 中的类导出给 Ark Biz 和其他 Ark Plugin 可见。默认情况下，所有 Ark Plugin 的导出类对于 Ark Biz 来说都是可见的，即 Ark Biz 可以使用 Ark Plugin 的导出类。对于 Ark Plugin 来说，如果需要使用其他 Ark Plugin 的导出类，必须声明为自身的导入类。关于 Ark Plugin 详细说明可以参考文末相关链接。\n下面我们来演示如何开发一个简单的 Ark Plugin。\n3. Java 模块改造成 Ark Plugin 3.1 新建工程 Demo 工程参见：https://github.com/QilongZhang/ark-plugin-demo\n运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，并创建三个普通的 Java 模块。以前文描述的 Hessian 冲突为例，在演示工程中定义了三个模快：\n pojo-module: 定义了一个简单的 PoJo 类 SamplePoJo，并设置为导出类，打包成 pojo-ark-plugin 。 hessian3-module：定义了一个服务类 Hessian3Service，实现了简单的序列化和反序列逻辑，使用的版本是 Hessian 3，并导入了 SamplePoJo，打包成 hessian3-ark-plugin 。 hessian4-module：定义了一个服务类 Hessian4Service，和 Hessian3Service 功能类似，使用的版本是 Hessian 4，并导入了 SamplePoJo，打包成 hessian4-ark-plugin 。 该用例是为了演示如何将普通的 Java 模块及其三方依赖包打包成 Ark Plugin，以 hessian3-module 模块为例来讲解打包流程。\n3.2 编写服务类 在 hessian3-module 中，提供了一个简单的序列化和反序列化功能类 Hessian3Service：\npackage com.alipay.sofa.demo.hessian3; import com.caucho.hessian.io.HessianInput; import com.caucho.hessian.io.HessianOutput; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; /** * @author qilong.zql */ public class Hessian3Service { public byte[] serialize(Object obj) throws IOException { if(obj==null) throw new NullPointerException(); ByteArrayOutputStream os = new ByteArrayOutputStream(); HessianOutput ho = new HessianOutput(os); ho.writeObject(obj); return os.toByteArray(); } public Object deserialize(byte[] by) throws …","date":1526465554,"description":"本文将介绍 SOFABoot 类隔离能力的背景及其使用方式。","dir":"blog/spring-boot-sofa-boot-class-isolation-integration/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c22dd2791732b32177419ff678b34546","permalink":"https://sofastack.github.io/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","publishdate":"2018-05-16T10:12:34Z","readingtime":8,"relpermalink":"/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 基础能力之上，增加了类隔离能力。蚂蚁金服内部丰富的实践场景表明，类隔离能力对解决","tags":["SOFABoot","SpringBoot","SOFAArk"],"title":"在 Spring Boot 中集成 SOFABoot 类隔离能力","type":"blog","url":"/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/","wordcount":3524},{"author":"绍辉","categories":"Seata","content":" 上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。\nSeata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。项目地址：https://github.com/seata/seata\n蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。\n为了帮助大家理解，分布式事务开源负责人绍辉进行了一次线下分享，详细讲述了分布式事务在蚂蚁金服的发展，希望可以帮助大家理解分布式事务，以下为分享的文字整理版本。\n前言 今天的分享将从以下三个部分展开：分布式事务问题产生的背景、蚂蚁金服分布式事务以及分布式事务 Seata 的 Roadmap。\n分享嘉宾：绍辉 蚂蚁金服 分布式事务开源负责人\n1、分布式事务问题产生的背景 1.1、数据库的水平拆分 蚂蚁金服早期，业务量比较小，单库单表便能满足业务需求；但是随着业务的发展，单库单表数据库逐渐成为瓶颈。为了解决数据库的瓶颈问题，我们对数据库进行了水平拆分。拆分所带来的一个问题就是以前一个数据库上便能完成的写操作现在要跨多个数据库，由此带来了跨库事务问题。\n1.2、业务的服务化拆分 蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个 APP 中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，由此产生了跨服务事务问题。\n1.3、转账案例说明数据一致性问题 数据库的水分拆分以及服务的垂直拆分，所带来的问题是一个业务活动通常要调用多个服务、访问多个数据库才能完成。\n以金融业务场景下的转账场景为例，转账服务要完成以下操作：\n 调用交易系统服务创建交易订单； 调用支付系统记录支付明细； 调用账务系统执行 A 扣钱； 调用账务系统执行 B 加钱。 以上 4 个操作要跨 3 个系统，访问 4 个数据库。而网络、数据库、机器等都具有不可靠性，我们很难保证以上 4 个操作能 100% 全部成功。\n在金融属性的业务中，不允许 A 账户的钱扣了，而 B 账户的钱没有加上的现象出现，所以我们必须想办法保证 1 ~ 4 这四个操作要么全部成功，要么全部失败；所以蚂蚁金服自主研发了分布式事务中间件，解决跨服务、跨数据库的数据一致性问题。\n2、蚂蚁金服分布式事务 2.1、分布式事务理论基础 在介绍蚂蚁金服的分布式事务中间件之前，先介绍一些分布式事务的理论背景。\n 2PC 两阶段提交协议（Two Phase Commitment Protocol）是分布式事务最基本的协议。在两阶段提交协议中，有一个事务管理器和多个资源管理器，事务管理器分两阶段协调资源管理器。在第一阶段，事务管理器询问所有资源管理器准备是否成功。如果所有资源均准备成功，那么在第二阶段事务管理器会要求所有资源管理器执行提交操作；如果任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求所有资源管理器在第二阶段执行回滚操作。通过事务管理器的两阶段协调，最终所有资源管理器要么全部提交，要么全部回滚，最终状态都是一致的。\n TCC 资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现。TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题。TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。\nTCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。\n如下图所示，用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中。事务管理器分两个阶段协调 TCC 服务，在第一阶段调用所有 TCC 服务的 Try 方法，在第二阶段执行所有 TCC 服务的 Confirm 或者 Cancel 方法，最终所有 TCC 服务要么全部都是提交的、要么全部都是回滚的。\n2.2、蚂蚁金服分布式产品介绍 蚂蚁金服从 2007 年开始做分布式事务，至今已经有 12 年历史。蚂蚁金服的分布式事务最初是采用 TCC 实现的，TCC 模式帮蚂蚁业务解决了各类金融核心场景下的数据一致性问题。\n2007 年我们开始支持双十一，为了满足双十一的高性能需求，我们对分布式事务做了一系列的性能优化。\n2013年，蚂蚁金服开始做单元化改造，分布式事务也开始支持 LDC、异地多活和高可用容灾，解决了机房故障情况下服务快速恢复的问题。\n2014年，蚂蚁金服分布式事务中间件开始通过蚂蚁金融云对外输出，我们发展了一大批的外部用户；在发展外部客户的过程中，外部客户表示愿意牺牲一部分性能（无蚂蚁的业务规模）以换取接入便利性和无侵入性。\n所以在 2015年，我们开始做无侵入的事务解决方案：FMT 模式和 XA 模式。\n蚂蚁金服分布式事务中间件经过长期演进，目前积累了 TCC、FMT 和 XA 三种模式，具有丰富的应用场景。下面分别介绍这三种模式。\n2.3、TCC 模式 蚂蚁金服的 TCC 模式和前面介绍 TCC 理论中提的 TCC 原理是一致的。不同的是，我们在整个分布式事务执行过程中，会去记录事务日志，一个分布式事务会产生一条主事务记录（对应发起方）和若干分支事务记录（对应 TCC 参与者）。记录事务日志的目的是，当分布式事务执行过程中出现异常中断时，事务恢复服务通过轮询事务日志，找出这个异常中断的事务，补偿执行该异常事务剩余未完成的动作，整个分布式事务的最终状态要么全部提交，要么全部回滚。\nTCC 设计规范和注意事项：\n用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。经过蚂蚁金服多年的 TCC 应用实践，总结如下在 TCC 设计和实现过程中的注意事项：\n1、业务操作分两阶段完成： 接入 TCC 前，业务操作只需要一步就能完成。但是在接入 TCC 之后，需要考虑如何将其分成两个阶段完成：把资源的检查和预留放在一阶段的 Try 操作中进行，把真正的业务操作的执行放在二阶段的 Confirm 操作中进行。\n以下举例说明业务模式如何分成两阶段进行设计，举例场景：“账户 A 的余额中有 100 元，需要扣除其中 30 元”。\n在接入 TCC 之前，用户编写 SQL：“update 账户表 set 余额 = 余额 -20 where 账户 = A”，便能一步完成扣款操作。\n在接入 TCC 之后，就需要考虑如何将扣款操作分成两步完成：\n Try 操作：资源的检查和预留。 在扣款场景，Try 操作要做的事情就是先检查 A 账户余额是否足够，再冻结要扣款的 30 元（预留资源）；此阶段不会发生真正的扣款。\n Confirm 操作：执行真正业务的提交。 在扣款场景下，Confirm 阶段做的事 …","date":1526465554,"description":"上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。","dir":"blog/seata-distributed-transaction-open-source/","fuzzywordcount":5000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"acb90bbbf0e7ec7dfb8c797bbd94efee","permalink":"https://sofastack.github.io/sofastack.tech/blog/seata-distributed-transaction-open-source/","publishdate":"2018-05-16T10:12:34Z","readingtime":10,"relpermalink":"/sofastack.tech/blog/seata-distributed-transaction-open-source/","summary":"上周，分布式事务 Fescar 宣布进行品牌升级：Thanks, Fescar ❤️，Hello, Seata 🚀。 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式","tags":["Seata"],"title":"蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼","type":"blog","url":"/sofastack.tech/blog/seata-distributed-transaction-open-source/","wordcount":4977},{"author":"鲁直","categories":"SOFABoot","content":" SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 的健康检查的基础上，加上了 Readiness Check 的能力，以更好地适应大规模金融级的服务化场景，防止在应用启动有问题的情况下让外部流量进入应用。在本文中，我们将通过 Kubernetes 来演示 SOFABoot 的 Readiness Check 的能力，主要涉及到两个部分的能力的演示：\n SOFABoot 的 Readiness Check 失败之后，SOFABoot 不会将发布的 RPC 服务的地址注册到 ZooKeeper 上面，防止 RPC 的流量进入。 Kubernetes 通过 http://localhost:8080/health/readiness 访问到 SOFABoot 的 Readiness 检查的结果之后，不会将 Pod 挂到对应的 Service 之上，防止 Kubernetes 上的流量进入。 准备一个 Kubernetes 的环境 为了演示在 Kubernetes 中使用 SOFABoot 的 Readiness Check 的能力，首先需要准备好一个 Kubernetes 的环境，在这个例子中，我们直接选择在本机安装一个 minikube，minikube 是 Kubernetes 为了方便研发人员在自己的研发机器上尝试 Kubernetes 而准备的一个工具，对于学习 Kubernetes 的使用非常方便。关于如何在本机安装 minikube，大家参考这个官方的安装教程即可。\n安装完成以后，大家可以直接终端中使用 minikube start来启动 minikube。\n需要注意的是，由于国内网络环境的问题，直接用 minikube start 可能会无法启动 minikube，如果遇到无法启动 minikube 的问题，可以尝试加上代理的设置，大家可以参考以下的命令来设置代理服务器的地址：\nminikube start --docker-env HTTP_PROXY=http://xxx.xxx.xxx.xxx:6152 --docker-env HTTPS_PROXY=http://xxx.xxx.xxx.xxx:6152 在 Kubernetes 上安装一个 ZooKeeper 在准备好了 Kubernetes 的环境之后，我们接下来需要在 Kubernetes 上安装一个 ZooKeeper 作为 SOFARPC 的服务自动发现的组件。首先我们需要有一个 ZooKeeper 的 Deployment：\napiVersion: apps/v1beta1 kind: Deployment metadata: name: zookeeper-deployment labels: app: zookeeper spec: replicas: 1 selector: matchLabels: app: zookeeper template: metadata: labels: app: zookeeper spec: containers: - name: zookeeper image: zookeeper imagePullPolicy: IfNotPresent ports: - containerPort: 2181 这个 Deployment 会部署一个 ZooKeeper 的实例，并且将 2181 端口暴露出来。\n有了这个 YAML 文件之后，我们再部署一个 Service 来作为 ZooKeeper 的负载均衡，这样我们在应用中就可以直接通过域名来访问，而不用 IP 来访问 ZooKeeper 了。这个 Service 的 Yaml 文件如下：\napiVersion: v1 kind: Service metadata: name: zookeeper-service spec: selector: app: zookeeper ports: - protocol: TCP port: 2181 targetPort: 2181 这个 Service 直接将 2181 端口映射到 ZooKeeper 的 2181 端口上，这样，我们就可以在应用中直接通过 zookeeper-service:2181 来访问了。\n准备一个 SOFABoot 的应用 在前面的两步都 OK 之后，我们需要准备好一个 SOFABoot 的应用，并且在这个应用中发布一个 SOFARPC 的服务。首先，我们需要从 start.spring.io 上生成一个工程，例如 GroupId 设置为 com.alipay.sofa，ArtifactId 设置为 rpcserver。\n生成好了之后，接下来，我们需要把 SOFABoot 的依赖加上，将 pom.xml 中的 parent 修改成：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 然后，增加一个 SOFARPC 的 Starter 的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 接着，在 application.properties 里面加上我们的配置，包括应用名和 ZooKeeper 的地址：\n# Application Name spring.application.name=SOFABoot Demo # ZooKeeper 的地址 com.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 上面的事情准备好之后，我们可以在应用中发布一个服务，首先，我们需要分别声明好一个接口和一个实现：\npackage com.alipay.sofa.rpcserver; public interface SampleService { String hello(); } package com.alipay.sofa.rpcserver; public class SampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } 接下来，将这个接口和实现发布成一个 SOFARPC 的服务，我们可以新建一个 src/main/resources/spring/rpc-server.xml 的文件：\n\u0026amp;lt;?xml …","date":1525428754,"description":"在本文中，我们将通过 Kubernetes 来演示 SOFABoot 的 Readiness Check 的能力。","dir":"blog/sofa-boot-readiness-check-in-kubernetes/","fuzzywordcount":2800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4018d6494df0e7ecde1c4911610fc89c","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","publishdate":"2018-05-04T10:12:34Z","readingtime":6,"relpermalink":"/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","summary":"SOFABoot 是蚂蚁金服中间件团队开源的基于 Spring Boot 的一个开发框架，其在 Spring Boot 的健康检查的基础上，加上了 Readiness Check 的能力，以更好地适应大规模金融级的服务化场景，防止","tags":["SOFABoot","Kubernetes"],"title":"在 Kubernetes 中使用 SOFABoot 的 Readiness Check 能力","type":"blog","url":"/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/","wordcount":2732},{"author":"余淮","categories":"SOFARPC","content":" SOFARPC 是近期蚂蚁金服开源的一个高可扩展性、高性能、生产级的 Java RPC 框架。在蚂蚁金服 SOFARPC 已经经历了十多年及五代版本的发展。SOFARPC 致力于简化应用之间的 RPC 调用，为应用提供方便透明、稳定高效的点对点远程服务调用方案。为了用户和开发者方便的进行功能扩展，SOFARPC 提供了丰富的模型抽象和可扩展接口，包括过滤器、路由、负载均衡等等。\nSOFARPC 可以集成多种注册中心实现，其中一种就是常用的 ZooKeeper。\nZooKeeper 作为一个开源的分布式应用协调系统，已经用到了许多分布式项目中，用来完成统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等工作。\n本文将介绍 SOFARPC 是使用 ZooKeeper 作为注册中心的用法。\n1. ZooKeeper 注册中心安装 这里介绍下 Zookeeper 单机模式两种安装方式，集群模式请参考下其他文档。\n1.1 基于压缩包安装 第一步：去官网下载 http://zookeeper.apache.org/releases.html#download 例如目前最新版是 v3.4.11，我们下载压缩包zookeeper-3.4.11.tar.gz，然后解压到文件夹下，例如 /home/admin/zookeeper-3.4.11。\n第二步：设置配置文件，可以直接从样例复制一份。\n$ cd /home/admin/zookeeper-3.4.11 $ cp conf/zoo_sample.cfg conf/zoo.cfg 第三步：到 Zookeeper 安装目录下直接启动Zookeeper。\n$ cd /home/admin/zookeeper-3.4.11 $ sh bin/zkServer.sh start ZooKeeper JMX enabled by default Using config: /Users/zhanggeng/dev/zookeeper/bin/../conf/zoo.cfg -n Starting zookeeper ... STARTED 第四步：我们使用四字命令检查下。\n$ echo stat | nc 127.0.0.1 2181 Zookeeper version: 3.4.11-37e277162d567b55a07d1755f0b31c32e93c01a0, built on 11/01/2017 18:06 GMT ... 第五步：如果需要查看数据，直接运行 zkCli.sh，连接后执行 ls /即可。\n$ sh bin/zkCli.sh Connecting to localhost:2181 ...... WatchedEvent state:SyncConnected type:None path:null [zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] 1.2 基于 Docker 安装 如果您已安装了 Docker，那么可以选择使用镜像启动 Zookeeper。\n$ docker image pull zookeeper:3.4.11 $ docker run -i -t --name my_zookeeper -p2181:2181 -d zookeeper:3.4.11 我们查看下启动日志：\n$ docker logs -f my_zookeeper ZooKeeper JMX enabled by default Using config: /conf/zoo.cfg 2018-04-16 07:38:59,373 [myid:] - INFO [main:QuorumPeerConfig@136] - Reading configuration from: /conf/zoo.cfg ...... 2018-04-16 07:23:41,187 [myid:] - INFO [main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:2181 可以看到端口已经启动并发布，我们使用四字命令检查下。\n$ echo stat | nc 127.0.0.1 2181 Zookeeper version: 3.4.11-37e277162d567b55a07d1755f0b31c32e93c01a0, built on 11/01/2017 18:06 GMT ... 我们可以查看启动的容器运行状态、关闭、重启，参考命令如下：\n$ docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 30b13a744254 zookeeper:3.4.11 \u0026amp;quot;/docker-entrypoin...\u0026amp;quot; 23 hours ago Up 42 seconds 2888/tcp, 0.0.0.0:2181-\u0026amp;gt;2181/tcp, 3888/tcp my_zookeeper ## 关闭重启的话 $ docker container stop 30b13a744254 $ docker container start 30b13a744254 如果需要使用 ZooKeeper 客户端查看查看数据，参考命令如下：\n$ docker exec -it 30b13a744254 zkCli.sh Connecting to localhost:2181 ...... WatchedEvent state:SyncConnected type:None path:null [zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] 2. SOFARPC 集成 Zookeeper 注册中心 Demo 工程参见: sofa-rpc-zookeeper-demo\n2.1 新建工程 运行需要 JDK 6 及以上、 Maven 3.2.5 以上。\n首先我们在 IDE 里新建一个普通 Maven 工程，然后在 pom.xml 中引入如下 RPC 和 Zookeeper 相关依赖：\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.3.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.curator\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;curator-recipes\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.9.1\u0026amp;lt;/version\u0026amp;gt; …","date":1524737554,"description":"本文是 SOFARPC 集成 Zookeeper 的介绍。","dir":"blog/sofa-rpc-zookeeper-integriation/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"34d9ac266c4b2a95cc924705212d2eb0","permalink":"https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","publishdate":"2018-04-26T10:12:34Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","summary":"SOFARPC 是近期蚂蚁金服开源的一个高可扩展性、高性能、生产级的 Java RPC 框架。在蚂蚁金服 SOFARPC 已经经历了十多年及五代版本的发展。SOFARPC 致力于简化应用之","tags":["SOFARPC"],"title":"SOFARPC 集成 Zookeeper 注册中心","type":"blog","url":"/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/","wordcount":2367},{"author":"蚂蚁中间件","categories":"SOFAStack","content":" 我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！\nSOFA 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。\n蚂蚁金服期望通过逐步向社区开源 SOFA 中各个组件，来帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，也期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固，并具备更多金融级的属性。所以我们也非常欢迎社区的伙伴和各行业的伙伴能够参与共同探讨、交流和共建。\nWhy（为什么要做） SOFA 中间件在蚂蚁内部经历了十年的发展和四代架构的演进，被广泛应用在包括支付，借贷，信用，基金，保险等全金融场景，支撑着蚂蚁平稳度过历次双十一，双十二，新春红包等大考，创造了25.6 w/s 的交易记录，并还在不断刷新这个记录。\n从 2015 年开始，蚂蚁金服开启了金融科技对外输出的战略，SOFA 也走出了蚂蚁，甚至跨越了国界，被更多金融机构与合作伙伴所使用，如天弘基金，信美互信，南京银行，PayTM、DANA钱包等。\n在与合作伙伴以及客户的沟通、合作过程中，我们发现了 SOFA 的理念和能力也正是很多金融行业的企业所需要的，大家或多或少正在规划或者已经在做类似的东西，但缺乏像蚂蚁金服这么大的流量来提供考验，也缺乏专业团队的长期投入，更缺乏丰富的金融场景和严苛的业务压力来驱动技术持续发展。\n随着近几年蚂蚁金服在生态构建上不断完善，以及不断地有更多的公司加入到蚂蚁金服的金融生态中，我们也发现了整个金融生态地复杂性和多样性，SOFA 中间件也需要在更多地场景下被打磨、被完善、被增强。因此，我们选择将 SOFA 逐步开源出来，在贡献给社区的同时，也期待社区、合作伙伴甚至客户，都能够一起参与共建，形成行业标准和最佳实践。\nHow（怎么做） 为了让 SOFA 能够开源出来，我们投入了大量的重构工作，以可扩展化的方式来层层构建 SOFA 的能力，保证 SOFA 的内部版本和开源的版本采用的是同一个内核。所以 SOFA 的内部版本就是在开源版本之上扩展了内部逻辑和历史版本的兼容逻辑。开源版本的核心逻辑，内外是一致的，并在蚂蚁金服的生产环境中被广泛使用的，同时会随着蚂蚁自身业务诉求的驱动，不断的演进。\n开源社区有非常多优秀的技术和丰富的生态，为了更好的能融入和对接现有技术体系，尊重并遵守一些社区标准，SOFA 在设计过程中就充分考虑了兼容性和架构分层，充分兼容适配社区标准，实现组件化、可扩展、可替换。\n所有的 SOFA 中间件中的组件组合起来可以发挥更大的能力，但是每一个组件都是可以被替换的，比如用户可以选择用 Dubbo 来替换 SOFARPC，或者跟 SOFARPC 对接互通；可以选择 Zookeeper 来作为服务注册发现，也可以选择 SOFA 的服务注册中心来做服务发现；分布式链路追踪组件遵守 OpenTracing 的规范，可以直接和 Zipkin 进行对接等等；Metrics组件会遵循 Metrics2.0 标准，适配 Prometheus 体系等等。\nWhat（要做什么） 本次 SOFA 中间件开源的内容包含了 SOFABoot 和 SOFARPC 两个组件。\nSOFABoot 是蚂蚁金服基于 Spring Boot 构建一个研发框架，整体架构上类似于蚂蚁金服之前开源的Egg框架，遵守微内核，可插拔的理念，我们以标准 Spring Boot Starter的方式，扩展了很多企业级特性，以解决大规模团队开发云原生微服务系统中会遇到的问题，如类隔离，ReadinessCheck，日志隔离等等能力，后续会开放更多内部实践过的特性，如 Spring 上下文隔离，合并部署，动态模块，Tracing、Metrics、Streaming、测试框架等。\n同时，蚂蚁的很多技术团队和阿里的技术团队也开放了很多类库和组件，我们都会提供原生的集成能力和 Demo，方便大家更好的整合使用。SOFABoot 100% 兼容 Spring Boot，和 Spring Boot 并非是替代的关系，所有 Spring Boot 中的能力也都可以在 SOFABoot 中使用。\nSOFABoot 的 Github 的地址是：https://github.com/sofastack/sofa-boot ，欢迎大家使用反馈、贡献代码。\nSOFARPC 是一个高效，可靠，可扩展的 RPC 的框架，是蚂蚁金服服务化架构的基石。SOFARPC 最早源于阿里内部的 HSF，经过了蚂蚁金服内部多年的发展，在协议，网络，路由，可扩展性等层面都进行了大量的改造和优化的工作，适配了更多金融级的场景。\nSOFARPC 在蚂蚁金服内部是被所有在线应用的使用的服务调用框架，截止 2017 年双十一，SOFARPC 已经被蚂蚁 2000 多个系统所使用，生产环境发布的服务数量超过了 23000 个。\nSOFARPC 提供了多协议的支持，包括在蚂蚁金服内部被广泛采用，并且高度优化的 Bolt 协议，以及 REST，Dubbo，gRPC 等等主流的协议；也针对内部网关，测试等等场景提供了泛化调用能力；为了解决超大规模流量的预热的问题，提供了服务预热的能力；用户也可以根据 SOFARPC 的扩展机制扩展自己需要的能力。\n在后续的版本中，SOFARPC 将会加上分布式链路追踪，Metrics，更多的服务注册中心的支持，CRC 校验等等能力。\nSOFARPC 的 Github 的地址是：https://github.com/sofastack/sofa-rpc ，欢迎大家使用反馈、贡献代码。\n除了以上的两个 SOFA 中间件中的组件，在接下来，我们将会陆续开源 SOFA 中间件中的其他的组件，目前这些组件正在进行一定程度地重构中，为开源做准备，敬请大家期待~\n附本文中提到的链接：\n Egg：http://eggjs.org SOFABoot：https://github.com/sofastack/sofa-boot SOFARPC：https://github.com/sofastack/sofa-rpc SOFABolt：https://github.com/sofastack/sofa-bolt 彩蛋 最后，我们也为对 SOFA 中间件感兴趣的小伙伴们准备了一个微信交流群，欢迎感兴趣的同学扫描下方二维码联系加群小助手加入我们 SOFA 交流群哦。👇\n","date":1524147739,"description":"我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！","dir":"blog/announcing-sofastack-open-source/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6019b0e0f6e4c9569640bcdb51b5a157","permalink":"https://sofastack.github.io/sofastack.tech/blog/announcing-sofastack-open-source/","publishdate":"2018-04-19T14:22:19Z","readingtime":5,"relpermalink":"/sofastack.tech/blog/announcing-sofastack-open-source/","summary":"我们很高兴地宣布，今天蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！ SOFA 是蚂蚁金服自主","tags":["开源"],"title":"蚂蚁金服启动分布式中间件开源计划，用于快速构建金融级云原生架构","type":"blog","url":"/sofastack.tech/blog/announcing-sofastack-open-source/","wordcount":2479},{"author":"程立","categories":"SOFAStack","content":" 声明：本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创，经谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。\n移动互联网、大数据与云计算作为新的基础设施，催生了新的互联网经济，也正在推动各行各业的升级。在过去十多年中，金融服务飞速发展，移动支付支撑了零售业线上线下的变革，基于大数据的信贷服务支持了无数小微企业的创业创新，老百姓可以随时随地享受曾经高门槛的理财、保险等金融服务。以普惠服务为目标、数据与技术驱动、新型信用体系为基础的新金融已经成为新经济的基石。\n伴随着蚂蚁金服在新金融领域的探索，蚂蚁金服技术团队也在金融技术与架构领域不断开拓。从 2005 年每秒处理 1 笔交易到 2015 年双十一每秒处理 8.59 万笔交易，从单一的支付到覆盖微贷、理财、保险、信用、银行等，通过十多年的探索与实践，我们形成了一套包含金融级分布式交易、分布式大数据分析与决策等在内的完整架构与技术体系。\n在本文中，我们将与大家交流金融级分布式交易相关的实践与体会。\n金融级系统的关键目标 如果将建造系统比作盖楼的话，建一个常规的系统要先立稳四根柱子：高可用、安全、性能、成本。但要建一个移动互联网时代的金融级大厦，除了上述四根柱子需要更加牢固，还需要加上两根柱子：资金安全与数据质量。这六根柱子，是我们在架构蚂蚁金服的每一个系统时的首要目标。\n具体来说，我们对一个金融级系统有以下关键目标：\n高可用：具备 99.99% 以上的高可用性。系统能够容忍各种软硬件设施的故障，可以在服务不中断的情况下进行升级，在严苛的应用场景下保证承诺的服务质量，容忍各种人为失误。对于关键系统，还需要具备异地容灾能力。\n安全：具备多层次检测、感知与防御各类安全攻击的能力。系统有能力实时、精细地分析系统行为与数据流发现异常，必要时可以快速调集资源阻断大规模、有组织的攻击。\n性能：对于实时交易业务，要求极快的响应时间与极高并发能力。对于批量业务，要求极大的吞吐量。尤其重要的是，系统必须具备很强的可伸缩性与弹性，在需要时可以快速调集资源应对突发的业务量。\n成本：在满足高可用、安全与性能的前提下，成本是一个重要约束。我们将单笔交易的平均处理成本（月交易总笔数/月成本）、以及峰值交易的处理成本（每提升 1000 交易 TPS 需要追加的成本）作为两个关键指标去持续优化。除了必须在基础软硬件与系统关键链路上做极致的优化外，灵活的资源调度与按需伸缩能力是优化成本的关键。\n资金安全：这是金融级系统与常规系统的一个关键差异。要做到资金处理绝对不出差错，需要交易与数据具备强一致性，需要在任何故障场景数据不丢不错，需要具备准实时的交易资金核对能力，需要在异常场景下有精细化熔断与快速恢复能力。\n数据质量：数据质量是金融服务质量的基础。数据从采集、生成、流转、存储、计算、使用需要经历很多环节，要确保经过这么多环节后，数据依然是准确、完整和及时的，需要系统具备全链路的数据质量管控与治理能力。\n金融交易系统是否可以走分布式路线？如何基于分布式的思想与技术达到以上 6 个关键目标？接下来，我们就以蚂蚁金服的实践为基础，分享对这个问题的观点。\n分布式金融交易架构与技术 1 强一致的微服务：微交易架构 微服务是一种广泛应用的分布式架构。通过将系统分解为单一职责、高内聚、松耦合、独立部署、自主运行的“微“服务，可以极大提升系统的灵活性与扩展能力。但由于每一个微服务是自包含的数据与计算单元，当一个有严格一致性要求的交易，被分布在很多节点上执行时，如何保证数据与服务处理达到金融级的强一致性，成为一个难题。尽管可以用支持分布式事务的数据库或数据中间件来保证数据分布时的一致性，但解决不了当服务分布时的一致性问题。由于分布式事务对资源加锁的时间长、粒度大，也制约了系统的可伸缩性与高可用性。\n为了解决这个难题，我们提出一种使微服务具备强一致性的微交易架构。在这种架构中，涉及到交易操作的微服务具备事务属性。一个微交易提供三种操作TCC（Try-Confirm-Cancel），其中 Try 操作负责业务检查与资源预留，Confirm 操作负责实际操作，Cancel 操作负责释放预留的资源。一次完整的交易由一系列微交易的 Try 操作组成，如果所有的 Try 操作都成功，最终由微交易框架来统一Confirm，否则统一 Cancel，从而实现了类似经典两阶段提交协议（2PC）的强一致性。但不同于 2PC，微交易架构力求高效与可伸缩。TCC 三个操作都是基于本地事务的短事务，Try 操作只预留必须的业务资源，比如一笔交易涉及10元钱，仅预留账户中的 10 元钱，而不是锁定整个账户，TCC 协议在提交时，也没有单独的 Prepare 阶段，将提交协议的成本降到最低。\n从 2008 年初上线至今，微交易架构已经应用到蚂蚁金服的各种金融业务场景，经历过历次大促高峰考验，证明这套架构与技术的可行性。\n2 金融级分布式数据库: OceanBase 目前，主要商业数据库本质上是单机系统，其容量、性能和可靠性均依赖于单个或少量高性能服务器与高可靠存储的组合，成本高昂且扩展困难。尽管通过运用微交易架构，可以将对数据操作的压力分拆多个数据库，解决了水平可扩展的问题，但数据库本身的性能、成本与可靠性依然是一个难点。因此，阿里巴巴与蚂蚁金服从 2010 年起，开始研发专门的金融级分布式数据库 OceanBase。\nOceanBase 在以下几个方面，对传统数据库架构进行了突破：\n高性能：数据库的一个显著特征是总数量比较大，但每天变化(增删改)的数据只是总数据量的很小一部分。因此 OceanBase 将数据划分为基线数据和修改增量。基线数据即数据库在某个时间点的一个快照，存放在每台 OceanBase 服务器的硬盘中，修改增量即快照点之后的增删改数据，相对比较小，通常存放在每台 OceanBase 服务器的内存中。通过这种方式，使得增删改操作基本都在内存中进行，从而获得接近内存数据库的事务处理性能；\n强一致：经典的主库+备库方式的数据库，很难兼具高可用与强一致能力。为了解决这个问题，OceanBase 使用多数据副本（\u0026amp;gt;=3）投票协议，对于每个写事务，OceanBase 只有在事务日志（redo log）到达超过半数服务器后，才应答客户。这样当少数服务器（例如 3 台中的 1 台，或者 5 台中的 2 台）异常时，剩下的服务器至少有一台有事务日志，保证了数据库不因为少数服务器故障而导致数据丢失；\n高可用：关键业务的数据库必须达到 99.999% 的可用性，服务器故障、机房或网络故障都不能导致数据库不可用。OceanBase 通常由分布于多个机房（3 个或以上）的机群组成，每个机群有完整数据，其中一个机群作为主库对外提供读写服务，其余机群作为备库，接收主库的事务日志和回放日志。当主库故障时，剩下的机群会立刻自动发起投票选举，选出新的主库，新主库从其他机群获得可能存在的最新事务日志并回放，完成后对外提供服务。\n目前 OceanBase 已经稳定支撑了支付宝的核心交易、支付与账务，支撑了网商银行的核心系统，经历了多次“双十一”的考验，形成了跨机房、跨区域部署的高可用架构，并在日常运行、应急 …","date":1520578800,"description":"本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创。","dir":"blog/technical-financial-distributed-trading/","fuzzywordcount":4900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e6da780e4d5f611c48ac55795531fb2c","permalink":"https://sofastack.github.io/sofastack.tech/blog/technical-financial-distributed-trading/","publishdate":"2018-03-09T15:00:00+08:00","readingtime":10,"relpermalink":"/sofastack.tech/blog/technical-financial-distributed-trading/","summary":"声明：本文发表于《金融电子化杂志》2016年12期，经授权转发，系作者原创，经谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。","tags":["SOFAStack"],"title":"金融级分布式交易的技术路径","type":"blog","url":"/sofastack.tech/blog/technical-financial-distributed-trading/","wordcount":4822},{"author":null,"categories":null,"content":" 文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。 本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同； - 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。\n平台工程旨在帮助企业构建面向应用研发者的自服务运维体系，尝试通过工程化的技术手段和工作流程解决以下关键问题：\n- 设计合理的抽象层次，帮助应用研发者降低对 Infra 、platform 等技术以及运维、稳定性工作的认知负担；\n- 为应用研发者提供统一的工作界面和空间，避免用户陷入割裂的平台产品界面、复杂的工作流中；\n- 帮助研发者通过有效的工作流程和推荐路径基于 内部工程平台[4] 快速开展工作；\n- 帮助研发者通过配套的 CI 、CD 、CDRA 等产品自服务管理应用生命周期；\n- 帮助平台产品研发团队简单、高效、一致的开放其平台基础能力；\n- 通过培训、布道、运营等手段营造协同工作和分享的文化。\n事实上，不是所有人都应该或者能够成为这个领域的专家，这非常困难！\n实际上平台技术团队的专家通常也仅擅长自己的专业领域而已，特别是在云原生理念和技术广泛应用的今天，面向大量高度开放、可配置的平台技术带来的成百上千的应用配置，PaaS 领域的业务复杂性，以及高稳定性和统一治理的要求，而平台工程的目的正是为了让应用研发者尽可能简单无痛的参与到这样规模化的 DevOps 工作中。\n在蚂蚁的实践中，我们更趋向于以下这种合作状态，在团队架构和工作模式上更靠近 Google 的最佳实践。平台研发者及 SRE 成为 “ Enabler ” 支持应用研发者自服务的完成研发及交付运维，同时应用研发者使其应用可交付运维的工作结果也成为运维人员可以接手应用运维工作的基础。最终 SRE 、应用研发及运维人员把工作过程中的问题和痛点反馈给平台研发者形成正向循环。\n三、专用语言：工程化方式的一极 有什么比一种专用语言更适合开放的、自服务的、面向领域业务的问题定义，同时需要满足自动化、低安全风险、低噪音、易治理的企业内部要求吗？正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在平台工程的特定问题域内，一批配置和策略语言用于编写和管理规模化复杂配置及策略。\n不同于混合编写范式、混合工程能力的高级通用语言，这类专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将规模化复杂配置和策略编写思路和方式沉淀到语言特性中。\n在蚂蚁的平台工程实践中，我们强化了客户端的工作方式，将围绕应用运维生命周期的模型、编排、约束和策略稳定、可扩展的通过专用语言 KCL[5] 编写维护在共享仓库 Konfig[6] 中。\nKCL 是一种面向有编程能力的应用研发者的静态强类型语言，提供现代高级语言的编写体验和围绕领域目的有限功能。在平台工程实践中 KCL 不是一种仅用于编写 K-V 对的语言，而是一种面向平台工程领域的专用语言。应用研发者、 SRE 、平台研发者面向 Konfig 协同研发，通过 KCL 原生功能编写应用配置，以及在 PaaS 领域更为高频和复杂的 模型抽象[7] 、 功能函数[8] 和 约束规则[9] ，即编写稳定、可扩展的业务模型、业务逻辑、防错约束和环境规则。\nKonfig 仓库则成为统一的编程界面，工作空间和业务层载体，而基于 KCL 的安全、低噪音、低副作用、一致的编写范式更有利于长期管理和治理。\n四、分治：解构规模化问题 分治思路是解决规模化问题的钥匙，从 MapReduce 到 Kubernetes 无不体现其功效。在规模化交付运维领域，经典运维平台试图在统一的黑盒平台产品中，以内置的统一模型、编排、 provision 技术来应对全量业务场景。这样的实践可以快速启动，在小范围内奏效，但随着不同业务主体采用率提升引入差异化需求，同时随着持续变化的平台技术逐渐进入疲态。\n在蚂蚁的实践中，Konfig monorepo 是内部工程平台向研发者开放的编程界面和工作空间，帮助应用研发者以统一的编程界面编写围绕应用运维生命周期的配置和策略，从而编排和使用存量和新增的平台基础设施，按需创建管理云原生环境以及基于 RBAC 的权限，并通过 GitOps 方式管理交付过程。\nKonfig monorepo 为不同场景、项目、应用提供了独立的白盒的编程空间，其内生的扩展性来源于：\n- 灵活、可扩展、独立的客户端的 工程结构设计[10] ；\n- 独立配置块自动合并技术[11] 支持任意分块、可扩展的配置块组织；\n- 静态类型系统[12] 技术提供现代编程语言可复用、可扩展的类型化建模和约束功能；\n- 项目粒度的 GitOps CI 工作流程定义支持；\n- 基于 Kusion[13] 引擎的 provision 技术选择。\nKonfig monorepo 提供了分治的、可组合的工程结构设计、代码组织、建模方式、工作流程定义和 provision 技术选择支持，同时又以一致的研发模式和工作流承载了可扩展的业务需求。这样客户端的工作方式在保证灵活性、可扩展性、可移植性的同时也降低了对服务 …","date":-62135596800,"description":"","dir":"blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":-62135596800,"objectID":"025e2d84d60225a85a714bfd63e2c369","permalink":"https://sofastack.github.io/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","summary":"文｜朵晓东（花名：奕杉 )\nKusionStack 负责人、蚂蚁集团资深技术专家\n在基础设施技术领域深耕，专注云原生网络、运维及编程语言等技术工作\n一、摘要 本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队，一起让一些有意思的变化发生。 本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实践总结而成。\n二、平台工程：让企业级 DevOps 发生 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern ，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns ，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在 DevOps Anti-Types[2] 中可以找到更多更典型分类。\n企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：\n- 研发团队和运维团队由于部门墙、领导者缺少洞察等等原因各自为政，难以达成一致意见；\n- 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和快速变化，以朴素的 DevOps 理解强制应用研发者成为专家；\n- 领导者建立了专职的 DevOps 团队，但沦为中间的执行者，没能让 Dev 和 Ops 团队各自向前一步，紧密协同； - 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应对不足，无法对应用研发者提供有效的技术支撑；\n不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往需要根据自身团队架构和文化建立适当的 DevOps 体系。从成功案例看，无论是 Meta 公司由 Dev 完全承担 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3] ） 都扮演了非常重要的角色。","tags":null,"title":"","type":"blog","url":"/sofastack.tech/blog/what-have-we-learned-from-scale-platform-engineering-practices/20220927/","wordcount":422},{"author":null,"categories":null,"content":" Novel features: Strong leader Raft uses a stronger form of leadership than other consensus algorithms. For example, log entries only flow from the leader to other servers. This simplifies the management of replicated logs and makes Raft easier to understand. Leader election Raft uses randomized timers to elect leaders. This reduces election conflicts simply and rapidly. Membership change Raft uses a new joint consensus approach. Replicated state machines 1. Replicated state machines are implemented based on logs. Each server stores a log. Each log entry contains a command. The state machine executes commands in order. 2. Consensus algorithms for practical systems typically have the following properties: They ensure safety. They are highly available. They do not depend on the time sequence to ensure log consistency. A command can be completed as soon as a majority of the cluster has responded to a single round of remote procedure calls (RPCs). Drawbacks of Paxos Paxos is exceptionally difficult to understand. Paxos does not provide a good foundation for building practical implementations. Raft design principles Concept decomposition Leader election Log replication Membership changes Raft reduces the number of states to simplify the state space. Raft does not allow log holes and restricts the possibilities of log inconsistency. Raft uses randomized timers to simplify the leader election. Raft consistency algorithm State Persistent state on all servers (updated on stable storage before responding to RPCs):\n currentTerm The latest term that the server gets (initialized to 0 on initial boot, increasing monotonically) votedFor The candidateId that has received votes in the current term (or null if none). Log[] Log entries. Each entry contains a command for the state machine, and the term when the entry was received by the leader. Volatile state on all servers:\n commitIndex The index of the highest log entry known to be committed. lastApplied The index of the highest log entry applied to the state machine. Volatile state on leaders:\n nextIndex[] The index of the next log entry to be sent to each follower. matchIndex[] The index of the highest log entry known to have been replicated on each follower. AppendEntries RPC (log replication) Called by the leader to replicate log entries or used as heartbeats.\nArguments:\n term leader\u0026amp;rsquo;s term leaderId The leader\u0026amp;rsquo;s ID that can be used to redirect clients to the leader. prevLogIndex The index of the preceding log entry. prevLogTerm The term of the prevLogIndex entry. entries[] The log entries to be stored (empty for heartbeat, and the leader may send more than one for efficiency). leaderCommit The leader\u0026amp;rsquo;s commitIndex (for committed log entries). Results:\n term The currentTerm for the leader to update. success True if the follower contains log entries matching prevLogIndex and prevLogTerm. Receiver …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/raft-introduction/","fuzzywordcount":2600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b811e803d23b40da67657798801f8b51","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","publishdate":"0001-01-01T00:00:00Z","readingtime":13,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","summary":"Novel features: Strong leader Raft uses a stronger form of leadership than other consensus algorithms. For example, log entries only flow from the leader to other servers. This simplifies the management of replicated logs and makes Raft easier to understand. Leader election Raft uses randomized timers to elect leaders. This reduces election conflicts simply and rapidly. Membership change Raft uses a new joint consensus approach.","tags":null,"title":"'Introduction to the Raft algorithm'","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/raft-introduction/","wordcount":2562},{"author":null,"categories":null,"content":" Open ACTS IDE In the Packages view, right click the function name annotated by @Test, and choose ACTS Function \u0026amp;gt; Edit Test Case as shown in the following figure.\nWrite test data Prepare request parameters Prepare correct request parameter data for the request parameters (type, order, and quantity) of the tested method. The parameters are divided into simple and complex types. Simple parameters include parameter types String, Date, Integer, Float, Double, Long, Short, and Byte (including their corresponding basic types, such as int and float). Complex parameters include parameter types List, Map, Set, custom class, Java defined class, and their nested expressions.\nSimple request parameters Right click Request Parameters, choose Select Model, and click Simple Type in the pop-up to select simple parameters.\nAfter importing simple request parameters, enter their values directly in the field as shown in the preceding figure. Parameters listed top down are the first, second, and third parameters of the tested method. You can right click a parameter to adjust its order.\nComplex parameters As shown in Figure 27, you need to generate request parameter models for the AccountTransRequest class and the BusinessActionContext class. Generally, class models of the tested method\u0026amp;rsquo;s request parameters and responses are automatically generated along with the test script. You can open ACTS IDE to edit class models of request parameters as shown in Figure 28.\nFigure 28\nIf the models of the method\u0026#39;s request parameters and responses are not identified when you generate the test script, first generate models of complex request parameters and responses (for detailed operation steps, see [Generate object model](../usage-model/#generate-object-model)). Then open ACTS IDE, right click Request Parameters, choose Select Model, and click Complex Type in the pop-up to add complex objects. After this, you can view and edit complex objects under Request Parameters. ![Complex type](complex-type.png) ### List ![List example](list-example.png) ![Edit value](edit-value.png) ### Map See example 2 (the Set type is similar). In Figure 32, request parameters of the method shown in sample 2 is the `Map` type. Objects do not belong to a specific type. If you want to set an object as a complex one, edit the YAML file. For example, if you want to set an object as the AccountTransResult class, edit the YAML file as follows: ![Map examples](map-example.png) Figure 32\n![ Change type](change-type.png) ![Set property values](set-value.png) ### enum Example code: ![Example code](sample.png) 1. You can edit the values in ACTS IDE as follows: ![Edit value](change-value.png) 2. If an enum type class is nested in another class, set the value of the enum type to DEBIT in the CSV model of the class. 3. Figure 37 shows the test case data in the YAML file. ```yaml interestRecoverTypeEnum: !!com.alipay.fc.loancore.common.util.enums.InterestRecoverTypeEnum \u0026#39;ALL\u0026#39; ``` ![YAML data](yaml-data.png) …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ide/","fuzzywordcount":2000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"697e7e6d35a2e058f3ca8b0a72032690","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-ide/","publishdate":"0001-01-01T00:00:00Z","readingtime":10,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-ide/","summary":"Open ACTS IDE In the Packages view, right click the function name annotated by @Test, and choose ACTS Function \u0026gt; Edit Test Case as shown in the following figure.\nWrite test data Prepare request parameters Prepare correct request parameter data for the request parameters (type, order, and quantity) of the tested method. The parameters are divided into simple and complex types. Simple parameters include parameter types String, Date, Integer, Float, Double, Long, Short, and Byte (including their corresponding basic types, such as int and float).","tags":null,"title":"All-in-one editor","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-ide/","wordcount":1929},{"author":null,"categories":null,"content":" Introduction To understand the usage mode of Jarslink2.0, you need to have a certain understanding of the SOFAArk framework and the packaging of Ark packages and Ark Biz packages.\nTo ensure the consistency of reading, here is a rough description of the packaging logic of the application\u0026amp;rsquo;s use of Jarslink2.0. The official recommendation is to jump to the above-mentioned link to obtain the necessary background knowledge.\nJarslink2.0 requires an application type of Spring Boot or SOFABoot. Before introducing new modes of application packaging, let\u0026amp;rsquo;s see why it is necessary for Spring Boot/SOFABoot applications to introduce new packaging modes after using Jarslink2.0.\nBackground At runtime, Jarslink2.0 works as an Ark Plugin of the SOFAArk framework, which must be introduced for the use of Jarslink2.0. The Jarslink2.0 plugin will not be loaded and started until the SOFAArk container is started. As we know, when official Spring Boot projects use plugins:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; An executable FatJar will be packaged, which contains all the dependencies, configurations, and other resources required by the running application. The FatJar entry method is the main method of the Spring Boot application. The packaging logic of a SOFABoot project is the same as that of a Spring Boot project.\nAfter the application introduces Jarslink2.0, which needs to depend on the SOFAArk framework, the FatJar that is packaged by a new packaging mode needs to contain a SOFAArk container. The FatJar entry method also needs to be replaced by the SOFAArk container startup method, because the startup of SOFAArk takes precedence over the execution of the FatJar. The SOFAArk container starts all the Ark Plugins in turn before finally starting the application. Therefore, a new packaging mode is needed, and SOFAArk provides a packaging plugin.\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; responsible for packaging Spring Boot/SOFABoot applications into an executable FatJar called Ark package.\nPackaging Type In the previous section, we have described why the use of Jarslink 2.0 needs to introduce a packaging mode that is different from the official Spring Boot packaging mode, and brought out the first packaging type—Ark package. Now let\u0026amp;rsquo;s summarize the features of Ark package:\n Ark package is an executable FatJar package format customized by the SOFAArk framework, the details of which are available in Reference Documents. The Ark package contains all the configurations, dependencies, and other resources required by the running application. Its packaging logic is similar to that of Spring Boot, and it also contains the Ark Plugin and the SOFAArk framework on which the application depends. The SOFAArk framework does not need to be introduced into the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-repackage/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a9cb3c5d3fa32c5f6c476d9ed80c80cb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","summary":"Introduction To understand the usage mode of Jarslink2.0, you need to have a certain understanding of the SOFAArk framework and the packaging of Ark packages and Ark Biz packages.\nTo ensure the consistency of reading, here is a rough description of the packaging logic of the application\u0026rsquo;s use of Jarslink2.0. The official recommendation is to jump to the above-mentioned link to obtain the necessary background knowledge.\nJarslink2.0 requires an application type of Spring Boot or SOFABoot.","tags":null,"title":"Application packaging","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/","wordcount":749},{"author":null,"categories":null,"content":" RheaKV: an embedded, distributed, highly available, and strongly consistent KV storage class library that is implemented based on JRaft and RocksDB. AntQ Streams QCoordinator: uses JRaft to implement elections and meta information storage in the Coordinator cluster. Metadata management module of SOFARegistry: an IP address registration. The data held by all nodes must be consistent, and the normal data storage must not be affected when a minority of nodes fail. AntQ NameServer leader election ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/user-stories/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b233be7d9eed33645945293e637e28ea","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/user-stories/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/user-stories/","summary":"RheaKV: an embedded, distributed, highly available, and strongly consistent KV storage class library that is implemented based on JRaft and RocksDB. AntQ Streams QCoordinator: uses JRaft to implement elections and meta information storage in the Coordinator cluster. Metadata management module of SOFARegistry: an IP address registration. The data held by all nodes must be consistent, and the normal data storage must not be affected when a minority of nodes fail.","tags":null,"title":"Application scenarios","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/user-stories/","wordcount":74},{"author":null,"categories":null,"content":" ## Architecture diagram Jarslink 2.0 is an Ark plugin and needs to depend on the SOFAArk container at runtime. Jarslink 2.0 is in the middle layer between the applications and the containers at runtime. Boundary interaction mode: + 1. Application boundaries: Jarslink 2.0 configures export classes that can be directly used by the applications. Such classes are loaded by Jarslink at runtime. + 2. Container boundaries: The Ark plugin can interact with the SOFAArk container by using the exposed extension points and services. Jarslink expanded the BizDeployer implementation and referenced BizManagerService and BizFactoryService container services.\nModule division The implementation classes of each module appear only in their own modules and are generally not cross-dependent. Required cross-dependencies will be moved into the core module. Detailed module descriptions can be found in the following table:\n Module name Sub-module name Description Dependency relationship bom Dependent on version control None core common Common module with log classes None core spi SPI module, defining basic interfaces and commands None core-impl runtime Jarslink runtime management, processing commands Core integration Ark plugin packaging module, implementing SOFAArk container service extension point and referencing container services All ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-structure/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fa09c01de689002edbd0bea7f68fe66e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","summary":"## Architecture diagram Jarslink 2.0 is an Ark plugin and needs to depend on the SOFAArk container at runtime. Jarslink 2.0 is in the middle layer between the applications and the containers at runtime. Boundary interaction mode: + 1. Application boundaries: Jarslink 2.0 configures export classes that can be directly used by the applications. Such classes are loaded by Jarslink at runtime. + 2. Container boundaries: The Ark plugin can interact with the SOFAArk container by using the exposed extension points and services.","tags":null,"title":"Architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/","wordcount":188},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-biz/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d7f80ce6a00d914546e642c887d23a01","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","summary":"","tags":null,"title":"Ark Biz","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/","wordcount":0},{"author":null,"categories":null,"content":" 简介 本小节将介绍 Ark Biz 目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark Biz。\nArk Biz 包和 Ark 包 都是使用 Maven 插件 sofa-ark-maven-plugin 打包生成；工程应用在配置该插件时，默认情况下只会打包发布 Ark 包， 只有在配置参数 attach 为 true 时，才会打包发布 Ark Biz：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;false\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 那 Ark Biz 和 Ark 包 有什么区别呢？ 简单来说，Ark Biz 是工程应用所有资源的组织单元，它包含了应用启动所需的所有资源，详细可参考下文描述的 Ark Biz 目录格式；而工程应用打出来的 Ark 包，是一个通过 java -jar 启动，运行在 SOFAArk 容器的 Fat Jar，不仅包含应用工程对应的 Ark Biz，也包含 Ark Container，以及应用依赖的 Ark Plugin；\n通常情况，只需要发布 Ark 包 即可，但是 SOFAArk 是支持运行多个 Ark Biz的，因此如果开发者希望自己应用的 Ark Biz 包能够被其他应用直接当成 Jar 包依赖，进而运行在同一个 SOFAArk 容器之上，那么就需要打包发布 Ark Biz 包；\nArk-Biz 典型目录结构 . ├── META-INF │ ├── MANIFEST.MF │ ├── maven │ │ └── me.qlong.tech │ │ └── sofa-boot-demo3-web │ │ ├── pom.properties │ │ └── pom.xml │ └── sofa-boot-demo3 │ └── sofa-boot-demo3-web.xml ├── com │ └── alipay │ └── sofa │ └── ark │ └── biz │ └── mark ├── config │ ├── application-dev.properties │ ├── application-test.properties │ └── application.properties ├── lib │ ├── spring-beans-4.3.4.RELEASE.jar │ ├── spring-boot-1.4.2.RELEASE.jar │ ├── spring-boot-autoconfigure-1.4.2.RELEASE.jar │ ├── spring-boot-devtools-1.4.2.RELEASE.jar │ ├── spring-boot-starter-1.4.2.RELEASE.jar │ ├── spring-boot-starter-logging-1.4.2.RELEASE.jar │ ├── spring-boot-starter-tomcat-1.4.2.RELEASE.jar │ ├── spring-boot-starter-web-1.4.2.RELEASE.jar │ ├── spring-context-4.3.4.RELEASE.jar │ ├── spring-core-4.3.4.RELEASE.jar │ ├── spring-expression-4.3.4.RELEASE.jar │ ├── spring-web-4.3.4.RELEASE.jar │ ├── ... │ ├── ... │ ├── ... │ └── velocity-1.7.jar ├── logback-spring.xml ├── me │ └── qlong │ └── tech │ └── SOFABootWebSpringApplication.class └── static └── index.html 上述目录结构相关文件和目录说明如下：\n普通的 Java 工程或者 Spring Boot Core/Web 工程都可以打包成 Ark Biz；Ark Biz 没有固定的目录格式，它只是在原来 Jar 包结构基础上新增两个目录文件：\n com/alipay/sofa/ark/biz/mark : 标记文件，标记该 Jar 包是 sofa-ark-maven-plugin 打包生成的 Ark Biz 文件；\n lib/ : lib 目录存放工程应用的三方依赖，\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-biz/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d7f80ce6a00d914546e642c887d23a01","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","summary":"简介 本小节将介绍 Ark Biz 目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark Biz。 Ark Biz 包和 Ark 包 都是使用 Maven 插件 sofa-ark-maven-plugin 打包生成；工程应用在配置该插件时，默认情","tags":null,"title":"Ark Biz","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/","wordcount":700},{"author":null,"categories":null,"content":" SOFAArk 合并部署时，除了宿主应用，其他 Biz 允许运行时动态部署和卸载。Biz 的状态如下:\n unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时 Biz 包还没有安装或者安装中 activated: Biz 包启动完成，且处于激活状态，可以对外提供服务 deactivated: Biz 包启动完成，但处于未激活状态，模块多个版本时，只有一个版本处于激活状态(注意这个状态只对 JVM 服务生效，对 RPC 等其他中间件无效) broken: Biz 包启动失败后状态 目前 SOFAArk 提供了三种方式操作 Biz:\n 编程 API Zookeeper 动态配置 Telnet 指令 本质上，后两种都是通过编程 API 操作 Biz，所以在这里详细描述通过编程 API 控制 Biz 的生命周期。SOFAArk 提供客户端 ArkClient 操作 Biz, 主要包含三条指令：\n install: 安装 Biz，虽然有多个重载方法，本质是接受 bizFile 文件作为入参 uninstall: 卸载 Biz，运行时 Biz 是由 bizName 和 bizVersion 唯一确定的，因此需要这两个入参 switch: 激活 Biz，SOFAArk 运行部署多个相同名称不同版本的 Biz，但是运行时只有一个 Biz 被激活（JVM 服务对外可用）；当使用 switch 指令激活其他版本时，当前处于激活状态的 Biz 将切换到钝化，同样也需要 bizName 和 bizVersion 作为入参 注意：部署相同名称不同版本 Biz 时，如果已有激活的版本，后续部署的其他版本 Biz 将自动处于钝化状态\n安装 Biz 以 Spring Boot/SOFABoot 为例，应用(模块)安装包含以下流程：\n 解析模块 \u0026amp;gt; SOFAArk 容器会解析文件流，读取 Biz 配置，创建 BizClassLoader 等，生成 Biz 运行时模型\n 注册模块 \u0026amp;gt; 注册解析后的 Biz 模型，设置状态为 resolved\n 启动模块 \u0026amp;gt; 执行 Biz 的入口方法，完成上下文的刷新，如果报错则对外抛出异常\n 健康检查 \u0026amp;gt; 启动完成，此时 Biz 还没有切换至下一个状态，将会执行应用健康检查，健康检查参考 SOFABoot 文档，健康检查失败则抛出异常，如果应用没有引入 SOFABoot 健康检查依赖，则跳过\n 切换状态 \u0026amp;gt; 健康检查成功，会切换 Biz 状态；如果不存在其他版本 Biz 处于激活状态，则切换状态至 Activated，否则切换状态至 DeActivated\n 注意：启动模块时抛出异常，均导致 Biz 启动失败，可以查看 sofa-ark/common-error.log 日志\n卸载 Biz 应用（模块）卸载包含以下流程：\n 切换 Biz 状态至少 deactivated \u0026amp;gt; 钝化 Biz, 防止流量进入正在卸载的 Biz\n 关闭 ApplicationContext \u0026amp;gt; 关闭 Biz 的 Spring 上下文，如果用户需要自定义卸载操作，可以监听 ContextClosedEvent 事件\n 注销 JVM 服务 \u0026amp;gt; SOFAArk 运行时注销 Biz 发布的 JVM 服务\n 发送卸载事件 \u0026amp;gt; 通知所有 Ark Plugin 和 Ark Biz，正在卸载某个 Biz\n 清楚缓存 \u0026amp;gt; SOFAArk 运行时注销所有和该 Biz 相关的缓存\n 切换 Biz 状态为 unresolved \u0026amp;gt; Biz 执行完所有卸载操作时，将状态置为 unresolved\n 卸载面临的挑战 卸载 Biz 最大的挑战在于 ClassLoader 的卸载，如果 ClassLoader 没有卸载干净，极有可能会导致 metaspace OOM. JDK 对 Class 的回收条件非常苛刻，包含：\n 该类所有实例都已经回收 加载该类的 ClassLoader 已经回收 该类对应的 java.lang.Class 对象已经没有在任何地方被引用，无法在任何地方通过反射访问该类的方法 每个 Biz 都由独立的 BizClassLoader 加载，只要该 Biz 的加载的类或对象或 ClassLoader 被其他 Biz 或 Plugin 引用，则会导致 Biz 无法卸载成功\n激活 Biz 激活指令用于设置 Biz 状态为 Activated，如果此时已有其他版本 Biz 处于激活状态，则先设置其为 Deactivated，再激活指定的 Biz 为 Activated. 激活状态是相对 JVM 服务而言，只有被激活的 Biz，其发布的 JVM 服务才能被其他 Biz 引用\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-biz-lifecycle/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"090ee6596c6808339fa3233139903040","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","summary":"SOFAArk 合并部署时，除了宿主应用，其他 Biz 允许运行时动态部署和卸载。Biz 的状态如下: unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时","tags":null,"title":"Ark Biz 生命周期","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/","wordcount":1195},{"author":null,"categories":null,"content":" This section will introduce the directory structure of standard Ark package and how to use the maven plugin of sofa-Ark-maven-plugin to package and release an Ark package.\nMaven plugin The officially provided Maven plugin sofa-Ark-maven-plugin can package common Java projects or Spring Boot projects into standard-format Ark packages. Based on Fat Jar technology, we can directly start an Ark package with the java -jar command. The Maven plugin coordinates are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals The sofa-Ark-maven-plugin plugin provides goal: repackage, which can package the project into an executable Ark package, it can be configured as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Configuration information --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Complete configuration template Complete sofa-Ark-maven-plugin configuration template is as follows:\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.1.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--The default packaging storage directory for Ark package and Ark biz is the project build directory--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;../target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--The name of the generated Ark package file is ${artifactId} by default--\u0026amp;gt; \u0026amp;lt;finalName\u0026amp;gt;demo-ark\u0026amp;lt;/finalName\u0026amp;gt; \u0026amp;lt;!--Whether to skip execution of goal:repackage (false by default)--\u0026amp;gt; \u0026amp;lt;skip\u0026amp;gt;false\u0026amp;lt;/skip\u0026amp;gt; \u0026amp;lt;!--Whether to package, install, and release Ark biz (false by default). Refer to the Ark Biz file for details --\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--Set the classifier of Ark package, which is null by default--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;ark-classifier\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- Set the classifier of Ark biz, which is Ark-biz by default --\u0026amp;gt; \u0026amp;lt;bizClassifier\u0026amp;gt;ark-biz-classifier\u0026amp;lt;/bizClassifier\u0026amp;gt; \u0026amp;lt;!--Exclude the specified package dependency when packaging the Ark biz. The format is: ${groupId:artifactId} or ${groupId:artifactId:classifier}--\u0026amp;gt; \u0026amp;lt;excludes\u0026amp;gt; \u0026amp;lt;exclude\u0026amp;gt;org.apache.commons:commons-lang3\u0026amp;lt;/exclude\u0026amp;gt; \u0026amp;lt;/excludes\u0026amp;gt; \u0026amp;lt;!--Exclude the package dependency that is the same as the specified groupId when packaging the Ark biz--\u0026amp;gt; \u0026amp;lt;excludeGroupIds\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jar/","fuzzywordcount":1400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c2a9b8ad142f15b9ee82d7d9d8237850","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","summary":"This section will introduce the directory structure of standard Ark package and how to use the maven plugin of sofa-Ark-maven-plugin to package and release an Ark package.\nMaven plugin The officially provided Maven plugin sofa-Ark-maven-plugin can package common Java projects or Spring Boot projects into standard-format Ark packages. Based on Fat Jar technology, we can directly start an Ark package with the java -jar command. The Maven plugin coordinates are:","tags":null,"title":"Ark JAR package","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/","wordcount":1317},{"author":null,"categories":null,"content":" This section will introduce the standard specifications and directory structure of Ark Plugin and how to use the maven plugin of sofa-ark-plugin-maven-plugin to package and release it.\nPlugin Specifications A standard Ark Plugin should meet the following specifications:\n The plugin should have a name (default is ${artifactId}). At runtime, duplicate names are not allowed. In other words, the name will be used as the unique ID of Ark Plugin;\n A plugin must be configured with a priority (default is 1,000): the lower the number, the higher the priority;\n A plugin should be configured with no more than one entry class activator, a portal for the container startup plugin used to implement the com.alipay.sofa.ark.spi.service.PluginActivator interface class in a uniform way. The plugin with higher priority will start up first;\n Import classes support both package and class levels. They are loaded first from other plugins;\n Export classes support package and class levels. Plugins with higher priority will be exported first;\n Support importing resources from the classpath (wildcard is not supported). Specified resources will be searched for from other plugins first;\n Support exporting resources from the classpath (wildcard is not supported); resources with higher priority will be exported first;\n Maven plugins The officially provided Maven plugin sofa-ark-plugin-maven-plugin can package projects into a standard-format Ark Plugin. The coordinates of Maven plugin are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals The sofa-ark-plugin-maven-plugin plugin provides goal: ark-plugin, which can be used to package the project into a standard-format Ark Plugin. Configurations are as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Configuration information --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Complete configuration template The complete configuration template of the sofa-ark-plugin-maven-plugin plugin is shown as follows:\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Specify the directory to package ${pluginName}.ark.plugin (${project. build. directory} is the default location) --\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin/","fuzzywordcount":1300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"684dc1caa0f834eec498905f95913f83","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","summary":"This section will introduce the standard specifications and directory structure of Ark Plugin and how to use the maven plugin of sofa-ark-plugin-maven-plugin to package and release it.\nPlugin Specifications A standard Ark Plugin should meet the following specifications:\n The plugin should have a name (default is ${artifactId}). At runtime, duplicate names are not allowed. In other words, the name will be used as the unique ID of Ark Plugin;","tags":null,"title":"Ark Plugin","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/","wordcount":1242},{"author":null,"categories":null,"content":" 本小节将介绍 Ark Plugin 的标准规范和目录结构，以及如何使用官方插件 sofa-ark-plugin-maven-plugin 打包发布 Ark Plugin。\n插件规范 标准的 Ark Plugin 需要满足以下规范：\n 插件必须配置插件名，默认为 ${artifactId} ；运行时，不允许存在同名的插件，可以认为它是 Ark Plugin 的唯一 ID;\n 插件必须配置优先级，默认为1000，数字越低表示优先级越高；\n 插件最多配置一个入口类 activator ，它是容器启动插件的入口，统一实现 com.alipay.sofa.ark.spi.service.PluginActivator 接口类；优先级高的插件优先启动；\n 导入类支持 package 和 class 两个级别；导入类优先从其他的插件加载；\n 导出类支持 package 和 class 两个级别；优先级高的插件优先导出；\n 支持导入 classpath 中资源，不支持通配符；优先从其他插件中查找指定资源；\n 支持导出 classpath 中资源，不支持通配符；优先级高的插件优先导出；\n Maven 插件 官方提供 Maven 插件 sofa-ark-plugin-maven-plugin 可以将工程打包成标准格式的 Ark Plugin ； Maven 插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${demo.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals sofa-ark-plugin-maven-plugin 插件提供 goal: ark-plugin，可以将工程打包成标准格式的 Ark Plugin, 如下配置：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 配置信息 --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 完整配置模板 完整的 sofa-ark-plugin-maven-plugin 插件配置模板如下：\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 指定打包的 ${pluginName}.ark.plugin 存放目录; 默认放在 ${project.build.directory} --\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!-- 是否把 ark plugin 安装、发布到仓库，默认为true --\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!-- ark plugin 最多仅能指定一个 com.alipay.sofa.ark.spi.service.PluginActivator 接口实现类 --\u0026amp;gt; \u0026amp;lt;activator\u0026amp;gt;com.alipay.sofa.ark.service.impl.SampleActivator\u0026amp;lt;/activator\u0026amp;gt; \u0026amp;lt;!-- 配置优先级，数字越小，优先级越高，优先启动，优先导出类，默认1000 --\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;2000\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!-- 配置插件的名字，务必配置对，运行时，是插件的唯一标识 ID。比如 sofa-rpc 插件，可以配置为 sofa-rpc; 默认为 ${artifactId} --\u0026amp;gt; \u0026amp;lt;pluginName\u0026amp;gt;${ark.plugin.name}\u0026amp;lt;/pluginName\u0026amp;gt; \u0026amp;lt;!--设置 ark plugin 的 classifier, 默认为空, 如非必要，建议不用设置--\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;!-- 配置导入类、资源 --\u0026amp;gt; \u0026amp;lt;imported\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的 package --\u0026amp;gt; \u0026amp;lt;packages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;javax.servlet\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework.*\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/packages\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的 class --\u0026amp;gt; \u0026amp;lt;classes\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.rpc.config.ProviderConfig\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/classes\u0026amp;gt; \u0026amp;lt;!-- 配置需要优先从其他 ark plugin 加载的资源 --\u0026amp;gt; \u0026amp;lt;resources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/bean.xml\u0026amp;lt;/resource\u0026amp;gt;\u0026amp;gt; \u0026amp;lt;/resources\u0026amp;gt; \u0026amp;lt;/imported\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"684dc1caa0f834eec498905f95913f83","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","summary":"本小节将介绍 Ark Plugin 的标准规范和目录结构，以及如何使用官方插件 sofa-ark-plugin-maven-plugin 打包发布 Ark Plugin。 插件规范 标准的 Ark Plugin 需要满足以下规范： 插件必须配置插件名，","tags":null,"title":"Ark Plugin","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/","wordcount":1937},{"author":null,"categories":null,"content":" Ark container class loading mechanism The plugins and business modules are managed in the Ark container. The following figure describes the class loading mechanism:\nClass loading mechanism of Ark container Each Ark plugin has a separate classloader which loads a class in the following order:\n If byte codes generated by reflection are loaded, the system will throw a ClassNotFoundException to terminate the loading process. This primarily comes from our engineering practice: to avoid long time searches for the classes that can never be found. Search for the already loaded classes Search for classes in the JDK, which mainly consists of two parts: 1) the classes to be loaded by ExtClassloader; 2) the classes that are provided by the JDK but fail to be loaded from the ExtClassloader. When running locally, however, these classes will be added to the SystemClassloader\u0026amp;rsquo;s classpath or they might be put into some third-party toolkits such as sun.tools.attach.BsdVirtualMachine in tool.jar at the same time. This part also comes from our engineering practice, avoiding errors caused by loading a class more than once. See if the class is an interface from Sofa Ark, such as com.alipay.sofa.Ark.spi.service.PluginActivator. If so, the class will be delegated to the classloader of the Ark container responsible for loading. See if it is located in the plugin import (including import-classes and import-package). If so, the loading will be delegated to the plugin classloader that will export it. Load in the plugin\u0026amp;rsquo;s own classpath If the above steps have failed, it will try to load the class in SymtemClassloader to deal with the situation that the agent is used. If the class fails to be loaded with all the above steps, the ClassNotFoundException will be thrown.\nArk business class loading mechanism Each Ark business has a separate classloader. Its class loading mechanism is basically consistent with that of Ark plugin, except for the step 5:\nFor Ark business, no import configuration is provided. Instead, it defaults to importing all classes exported by plug-ins. To deal with some particular business scenarios, however, we do provide the Deny-import configuration so that we can exclude the classes exported by some plugins.\nClass loading mechanism of Ark plugin resources The Ark plugin supports importing and exporting resources. To achieve this, we need to configure the corresponding import and export settings in sofa-Ark-plugin-maven-plugin. There are two ways to search for resources when using ClassLoader: ClassLoader.getResource(String) or ClassLoader.getResources(String);\n ClassLoader.getResource(String): When an Ark Plugin is searching for a single resource, it will delegate the Ark Plugin that will export the resource to load the class first. If multiple plugins export the resource at the same time, then the plugin with higher priority will export the resource first. If the loading fails or no other Ark Plugin has exported the resource, it will have a …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-classloader/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5803b870aae47885c37e4bbb02cb0a06","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","summary":"Ark container class loading mechanism The plugins and business modules are managed in the Ark container. The following figure describes the class loading mechanism:\nClass loading mechanism of Ark container Each Ark plugin has a separate classloader which loads a class in the following order:\n If byte codes generated by reflection are loaded, the system will throw a ClassNotFoundException to terminate the loading process. This primarily comes from our engineering practice: to avoid long time searches for the classes that can never be found.","tags":null,"title":"Ark container class loading mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/","wordcount":549},{"author":null,"categories":null,"content":" Starting an Ark plug-in Ark provides the interface for starting a plug-in com.alipay.sofa.ark.spi.service.PluginActivator. The definition of the interface is as follows:\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } Once a plug-in implements this interface, and the activator attribute is configured in MANIFEST.MF, the plug-in will use the start method when it starts and the stop method when it stops.\nArk plug-in communication Ark plug-ins communicate using services. The interfaces used by the publishing and reference services are provided in the input parameter type com.alipay.sofa.ark.spi.model.PluginContext of the preceding method of starting an interface.\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param pluginName the name of the plugin which publish the service * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String pluginName); /** * Get Service List publish by plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;ServiceReference\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; referenceServices(Class\u0026amp;lt;T\u0026amp;gt; ifClass); A plug-in service is interface-specific. For one interface, the following descriptions are true: * Only one service can be published for each plug-in. When more than one service is published, the reference of the previously published service will be returned. * If you use referenceService to reference a single service when multiple plug-ins have published services, which service is returned depends on whether pluginName is specified: * When not specified, the service with the highest priority is returned. * When specified, the service published by the plugin with the specified name is returned.\nThe returned service reference ServiceReference is defined as follows:\npublic interface ServiceReference\u0026amp;lt;T\u0026amp;gt; { /** * get Service Object * @return service */ T getService(); /** * get Service Metadata * @return */ ServiceMetadata getServiceMetadata(); } public interface ServiceMetadata { /** * get Service Unique Name * @return service name */ String getServiceName(); /** * get Service Interface Class * @return interface class */ Class\u0026amp;lt;?\u0026amp;gt; getInterfaceClass(); /** * get …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-plugin/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b552fc51eb84cc0fa4c26860bd316490","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","summary":"Starting an Ark plug-in Ark provides the interface for starting a plug-in com.alipay.sofa.ark.spi.service.PluginActivator. The definition of the interface is as follows:\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } Once a plug-in implements this interface, and the activator attribute is configured in MANIFEST.","tags":null,"title":"Ark container plugin mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/","wordcount":477},{"author":null,"categories":null,"content":" Ark container start process The startup process of the Ark container is illustrated as follows:\nArkService Ark Service is a service in the Ark container. The underlying layer uses Guice to manage the service. The service is provided with the lifecycle interface com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } After the service implements the preceding lifecycle interface, the Ark Service container invokes the interface when it starts and stops.\nPipeline service Pipeline is also a service registered in the Ark Service container. The service itself has no order or priority. The service is assembled in the Pipeline while the entire Ark container starts.\nArchive parsing At the very beginning of Pipeline, the running fatjar will be resolved into the models required for runtime, including the Ark plug-in model and the Ark business model, which are registered to the PluginManagerService and the BizManagerService in the Ark Service.\nDeploy the Ark plug-in Get all the Ark plug-ins from the PluginManagerService in the order of their priorities: * ClassloaderService prepares for the map mapping of plug-in export class * PluginDeployService starts com.alipay.sofa.Ark.spi.service.PluginActivator\nStart the Ark business Get all the Ark business from the BizManagerService, and execute the entry main function provided by the business configuration in the Main-Class attribute of MANIFEST.MF.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ad60e803febd20607686a1b4ea98efc3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","summary":"Ark container start process The startup process of the Ark container is illustrated as follows:\nArkService Ark Service is a service in the Ark container. The underlying layer uses Guice to manage the service. The service is provided with the lifecycle interface com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } After the service implements the preceding lifecycle interface, the Ark Service container invokes the interface when it starts and stops.","tags":null,"title":"Ark container startup process","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/","wordcount":233},{"author":null,"categories":null,"content":" 使用 Ark 事件处理机制 SOFAArk 从 1.1.0 版本开始提供了全新的事件模型，囊括了 SOFAArk 中 biz 和 plugin 的各个生命周期；该版本提供的事件模型参考了 Spring 中的生命周期事件模型。本篇文档将描述如何使用 SOFAArk 的事件机制。\n事件概览 biz 生命周期事件 事件名 描述 AfterBizStartupEvent biz 启动之后发送的事件 AfterBizStopEvent biz 停止之后发送的事件 AfterBizSwitchEvent biz 切换之后发送的事件 BeforeBizStartupEvent biz 启动之前发送的事件 BeforeBizStopEvent biz 停止之前发送的事件 BeforeBizSwitchEvent biz 切换之前发送的事件 plugin 生命周期事件 事件名 描述 AfterPluginStartupEvent plugin 启动之后发送的事件 AfterPluginStopEvent plugin 停止之后发送的事件 BeforePluginStartupEvent plugin 启动之前发送的事件 BeforePluginStopEvent plugin 停止之前发送的事件 容器级别生命周期事件 事件名 描述 AfterFinishDeployEvent 执行完 DeployStage 阶段之后发送的事件 AfterFinishStartupEvent 执行完 Ark 容器启动之后发送的事件 事件监听 监听指定类型的事件 上述提到的各个阶段的事件，我们可以通过编写 EventHandler 来处理，例如，希望监听类型为 BeforeBizStartupEvent 的事件，则可以通过以下方式实现监听：\n@Component public class EventHandlerSample implements EventHandler\u0026amp;lt;BeforeBizStartupEvent\u0026amp;gt; { private static final Logger LOGGER = LoggerFactory.getLogger(\u0026amp;quot;EVENT-HANDLER-LOGGER\u0026amp;quot;); @Override public int getPriority() { return 0; } @Override public void handleEvent(BeforeBizStartupEvent event) { Biz source = event.getSource(); LOGGER.info(\u0026amp;quot;begin to startup biz, current biz is: {}\u0026amp;quot;,source.getIdentity()); } } 日志目录：target/test/logs/host-app/event-handler.log 日志输出： 2019-11-28 15:18:33,248 INFO EVENT-HANDLER-LOGGER - begin to startup biz, current biz is: provider1:2.0.0, bizState: resolved\n 在此基础上，在提供其他几个 event 的处理器：\n AfterBizStartupEvent @Component public class AfterBizStartupEventHandler implements EventHandler\u0026amp;lt;AfterBizStartupEvent\u0026amp;gt; { private static final Logger LOGGER = LoggerFactory.getLogger(\u0026amp;quot;EVENT-HANDLER-LOGGER\u0026amp;quot;); @Override public void handleEvent(AfterBizStartupEvent event) { Biz source = event.getSource(); LOGGER.info(\u0026amp;quot;after startup biz, current biz is: {}, bizState: {}\u0026amp;quot;,source.getIdentity(),source.getBizState() ); } @Override public int getPriority() { return 0; } } 分别启动 基座 -\u0026amp;gt; 安装 ark-provider 模块 -\u0026amp;gt; 卸载 ark-provider 模块 ，然后看到日志输出如下：\n2019-11-28 15:31:42,325 INFO EVENT-HANDLER-LOGGER - after startup biz, current biz is: host-app:2.0.0, bizState: resolved 2019-11-28 15:36:23,956 INFO EVENT-HANDLER-LOGGER - begin to startup biz, current biz is: provider1:2.0.0, bizState: resolved 2019-11-28 15:36:27,216 INFO EVENT-HANDLER-LOGGER - after startup biz, current biz is: provider1:2.0.0, bizState: resolved 2019-11-28 15:53:38,225 INFO EVENT-HANDLER-LOGGER - before stop biz, current biz is: provider1:2.0.0, bizState: deactivated 2019-11-28 15:53:38,233 INFO EVENT-HANDLER-LOGGER - after biz stop, current biz is: provider1:2.0.0, bizState: unresolved 监听不指定类型的事件 某些情况下，如果期望监听所有 biz 或者 plugin 生命周期事件，可以使用以下方式：\n@Component public class AbstractArkEventHandler implements EventHandler\u0026amp;lt;AbstractArkEvent\u0026amp;gt; { @Override public int getPriority() { return 0; } @Override public void handleEvent(AbstractArkEvent event) { System.out.println(\u0026amp;quot;------------ current event topic: \u0026amp;quot; + event.getTopic()); } } 为了 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-event/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b0f233742572536edc8a517cf7547269","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","summary":"使用 Ark 事件处理机制 SOFAArk 从 1.1.0 版本开始提供了全新的事件模型，囊括了 SOFAArk 中 biz 和 plugin 的各个生命周期；该版本提供的事件模型参考了 Spring 中的生命周期事件模型。本篇","tags":null,"title":"Ark 事件机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/","wordcount":1254},{"author":null,"categories":null,"content":" 本小节将介绍标准 Ark 包 的目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark 包。\nMaven 插件 官方提供 Maven 插件 sofa-ark-maven-plugin 可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式 Ark 包 ；基于 Fat Jar 技术，使用 java -jar 命令可以直接启动 Ark 包 。 Maven 插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Goals sofa-ark-maven-plugin 插件提供 goal: repackage， 可以将工程打包成可执行的 Ark 包，如下配置：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/excution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- 配置信息 --\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 完整配置模板 完整的 sofa-ark-maven-plguin 插件配置模板如下：\n\u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--设置应用的根目录，用于读取 ${base.dir}/conf/ark/bootstrap.application 配置文件，默认为 ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;./\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;!--生成 ark 包文件名称，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;finalName\u0026amp;gt;demo-ark\u0026amp;lt;/finalName\u0026amp;gt; \u0026amp;lt;!--是否跳过执行 goal:repackage，默认为false--\u0026amp;gt; \u0026amp;lt;skip\u0026amp;gt;false\u0026amp;lt;/skip\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--设置 ark 包的 classifier，默认为空--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 classifier，默认为 ark-biz--\u0026amp;gt; \u0026amp;lt;bizClassifier\u0026amp;gt;ark-biz\u0026amp;lt;/bizClassifier\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 biz name，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;bizName\u0026amp;gt;demo-ark\u0026amp;lt;/bizName\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 biz version，默认为 ${artifactId}--\u0026amp;gt; \u0026amp;lt;bizVersion\u0026amp;gt;0.0.1\u0026amp;lt;/bizVersion\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的 启动优先级，值越小优先级越高，${artifactId}--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;100\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--设置 ark biz 的启动入口，默认会搜索被打 org.springframework.boot.autoconfigure.SpringBootApplication 注解且含有 main 方法的入口类--\u0026amp;gt; \u0026amp;lt;mainClass\u0026amp;gt;com.alipay.sofa.xx.xx.MainEntry\u0026amp;lt;/mainClass\u0026amp;gt; \u0026amp;lt;!--设置是否将 scope=provided 的依赖打包，默认为 false--\u0026amp;gt; \u0026amp;lt;packageProvided\u0026amp;gt;false\u0026amp;lt;/packageProvided\u0026amp;gt; \u0026amp;lt;!--设置是否生成 Biz 包，默认为true--\u0026amp;gt; \u0026amp;lt;keepArkBizJar\u0026amp;gt;true\u0026amp;lt;/keepArkBizJar\u0026amp;gt; \u0026amp;lt;!--针对 Web 应用，设置 context path，默认为 /--\u0026amp;gt; \u0026amp;lt;webContextPath\u0026amp;gt;/\u0026amp;lt;/webContextPath\u0026amp;gt; \u0026amp;lt;!--打包 ark biz 时，排除指定的包依赖；格式为: ${groupId:artifactId} 或者 ${groupId:artifactId:classifier}--\u0026amp;gt; \u0026amp;lt;excludes\u0026amp;gt; \u0026amp;lt;exclude\u0026amp;gt;org.apache.commons:commons-lang3\u0026amp;lt;/exclude\u0026amp;gt; \u0026amp;lt;/excludes\u0026amp;gt; \u0026amp;lt;!--打包 ark biz 时，排除和指定 groupId 相同的包依赖--\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jar/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c2a9b8ad142f15b9ee82d7d9d8237850","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","summary":"本小节将介绍标准 Ark 包 的目录结构，以及如何使用官方插件 sofa-ark-maven-plugin 打包并发布 Ark 包。 Maven 插件 官方提供 Maven 插件 sofa-ark-maven-plugin 可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式 Ark 包 ；","tags":null,"title":"Ark 包","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/","wordcount":1626},{"author":null,"categories":null,"content":" Ark 应用的整体启动流程如下图所述：\n当用 java -jar 启动 Ark 包 或者 在 IDE 中通过 SofaArkBootstrap.launch 启动 Ark 应用时，相应 Launcher 入口会负责启动应用，其中会反射调用 ArkContainer 的入口，初始化 ArkService ，然后依次执行 pipeline，来完成整个 Ark 应用的启动。\nArkService Ark Serivce 是 Ark 容器中的服务，底层使用 Guice 对服务进行管理。同时针对服务，提供了生命周期接口 com.alipay.sofa.ark.spi.service.ArkService\npublic interface ArkService { /** * Ark Service init * @throws ArkException */ void init() throws ArkException; /** * Ark Service dispose * @throws ArkException */ void dispose() throws ArkException; } 当服务实现了上述接口时，在 Ark Serivce 容器启动时和停止时会调用相应的生命周期接口\nPipeline 服务 Pipeline 也是注册在 Ark Service 容器中的一个服务，服务本身是没有顺序和优先级的，在 Pipeline 中会对服务进行一些组装，同时完成整个 Ark 容器的启动\nArchive 解析 在 Pipeline 的最开始，会将运行的 fatjar 进行解析，解析成运行时需要的模型，主要包括 Ark 插件模型和 Ark 业务模型，并将这些模型注册到 Ark Service 中的 PluginManagerService 以及 BizManagerService 中\n初始化环境 设置一些运行时需要的默认参数，比如设置 log4j.ignoreTCL 为 true 让 log4j/log4j2 初始化是日志不要从 ThreadContextClassloader 中寻找配置文件(背景)\n注册容器服务 在 Ark 容器中会发布一些服务供其它的插件来使用，比如 BizDeployer 来让 SOFAArk 官方插件 sofa-jarslink 来完成 biz 的动态加载/卸载等\n部署 Ark 插件 从 PluginManagerService 中获取到所有的 Ark 插件，并按照插件优先级顺序： * ClassloaderService 准备插件 export 类的 map 映射 * PluginDeployService 启动插件的 com.alipay.sofa.ark.spi.service.PluginActivator\n启动 Ark 业务 从 BizManagerService 中获取到所有的 Ark 业务，并执行业务配置在 MANIFEST.MF 属性 Main-Class 中提供的入口 main 函数\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ad60e803febd20607686a1b4ea98efc3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","summary":"Ark 应用的整体启动流程如下图所述： 当用 java -jar 启动 Ark 包 或者 在 IDE 中通过 SofaArkBootstrap.launch 启动 Ark 应用时，相应 Launcher 入口会负责启动应用，其中会反射调用 ArkContainer 的入口，初始化 ArkService ，然","tags":null,"title":"Ark 容器启动流程","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup/","wordcount":523},{"author":null,"categories":null,"content":" Ark 插件启动 Ark 中提供了插件启动的接口 com.alipay.sofa.ark.spi.service.PluginActivator ，其定义如下：\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } 插件只需要实现此接口，并在 MANIFEST.MF 中配置 activator 属性，就会在启动时执行 start 方法，停止时执行 stop 方法\nArk 插件通信 Ark 之间的通信是通过服务来完成的， 在上述启动接口方法的入参类型 com.alipay.sofa.ark.spi.model.PluginContext 中提供了发布服务和引用服务的接口\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param pluginName the name of the plugin which publish the service * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String pluginName); /** * Get Service List publish by plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;ServiceReference\u0026amp;lt;T\u0026amp;gt;\u0026amp;gt; referenceServices(Class\u0026amp;lt;T\u0026amp;gt; ifClass); 插件服务是以接口为粒度的，针对同一个接口： * 每一个插件只允许发布一个服务，重复发布则会直接返回已经发布服务的引用 * 当多有个插件发布服务时，若通过 referenceService 引用单个服务 * 当不指定 pluginName 时，则返回优先级最高的服务 * 当指定 pluginName 时，则返回该插件发布的服务\n返回的服务引用 ServiceReference 定义如下:\npublic interface ServiceReference\u0026amp;lt;T\u0026amp;gt; { /** * get Service Object * @return service */ T getService(); /** * get Service Metadata * @return */ ServiceMetadata getServiceMetadata(); } public interface ServiceMetadata { /** * get Service Unique Name * @return service name */ String getServiceName(); /** * get Service Interface Class * @return interface class */ Class\u0026amp;lt;?\u0026amp;gt; getInterfaceClass(); /** * get ServiceProvider * @return */ ServiceProvider getServiceProvider(); } 其中通过 * getService() 可以获取到服务的实体 (也即发布服务时的 implObject) * getServiceMetadata() 可以获取到服务的元数据信息，包括 * 服务名：即服务的接口名 * 服务接口 * 服务的提供方：包括提供方名字(插件名等)、提供方优先级(插件优先级)\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-plugin/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b552fc51eb84cc0fa4c26860bd316490","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","summary":"Ark 插件启动 Ark 中提供了插件启动的接口 com.alipay.sofa.ark.spi.service.PluginActivator ，其定义如下： public interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkException */ void start(PluginContext context) throws ArkException; /** * Stop Plugin * @param context * @throws ArkException */ void stop(PluginContext context) throws ArkException; } 插件只需要实","tags":null,"title":"Ark 容器插件机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/","wordcount":574},{"author":null,"categories":null,"content":" Ark 容器类加载机制 Ark 容器中会管理插件和业务，整体的类加载机制可见如下图描述：\nArk 插件类加载机制 每个 Ark 插件都拥有一个独立的类加载器，其类加载的顺序如下：\n 如果是加载反射生成的字节码，那么会直接抛出 ClassNotFoundException，终止类加载。这一部分主要是来源于我们的工程实践，避免一定找不到的类查找路径过长 查找已经被加载过的类 查找 JDK 中的类，这一块主要包含两部分：第一部分是 ExtClassloader 负责加载的类；第二部分是 JDK 提供的类但从 ExtClassloader 中加载不到，但在本地运行时会被加入到 SystemClassloader 的 classpath 中，同时这些类可能会被放到一些三方工具包中，典型的如 tool.jar 中 sun.tools.attach.BsdVirtualMachine,这一部分也主要来源于我们的工程实践，避免类被加载超过一次，从而引发报错 看类是否是由 Sofa Ark 提供的接口类，典型的如: com.alipay.sofa.ark.spi.service.PluginActivator, 如果是，则类会委托给 Ark 容器的类加载器加载 看是否在插件的 import 中(包括 import-classes 和 import-package)， 如果在，则会委托给导出该类的插件类加载器加载 在插件自身的 classpath 中加载 如果上述都失败了，则会尝试在 SymtemClassloader 中加载，这一步主要是为了解决使用 agent 时的情形 如果上述的步骤都加载失败了，则抛出 ClassNotFoundException\nArk 业务类加载机制 每个 Ark 业务都拥有一个独立的类加载器， Ark 业务类加载机制基本上与 Ark 插件保持一致，在上述的7步中，主要是第5步不一样：\n对于 Ark 业务而言，并没有提供 import 的配置，而是认为默认 import 所有插件 export 出来的类；但为了一些特殊的业务场景，我们提供了 Deny-import 的配置让业务可以排除掉某些插件导出的类\nArk 插件资源加载机制 Ark 插件支持导入导出资源，需要在 sofa-ark-plugin-maven-plugin 配置相关的导入导出配置；在使用 ClassLoader 加载资源时，存在两种方式查找资源，ClassLoader.getResource(String) 和 ClassLoader.getResources(String)；\n ClassLoader.getResource(String): Ark Plugin 在查找单个资源时，会优先委托导出该资源的 Ark Plugin 加载，如果有多个插件同时导出，则优先级高的插件优先导出；如果加载失败或者没有其他 Ark Plugin 导出，则尝试在本 Ark Plugin 查找加载；\n ClassLoader.getResources(String): Ark Plugin 在查找多个资源时，会从所有导出该资源的 Ark Plugin 加载，同时也会从本 Ark Plugin 加载资源；\n Ark 业务资源加载机制 默认情况下，Ark Biz 会优先加载 Ark Plugin 导出的资源；如果开发者希望只在工程应用内部查找，则可以通过 sofa-ark-maven-plugin 配置 denyImportResources；如此，Ark Biz 不会从 Ark Plugin 查找该资源，只会在 Ark Biz 内部查找。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-classloader/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5803b870aae47885c37e4bbb02cb0a06","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","summary":"Ark 容器类加载机制 Ark 容器中会管理插件和业务，整体的类加载机制可见如下图描述： Ark 插件类加载机制 每个 Ark 插件都拥有一个独立的类加载器，其类加载的顺序","tags":null,"title":"Ark 容器类加载机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/","wordcount":974},{"author":null,"categories":null,"content":" Ark 容器和 Ark Plugin 在运行时由不同的类加载器加载，不能使用常规的 ServiceLoader 提供 SPI 扩展，SOFAArk 自定义扩展点 SPI 机制， Ark Plugin 实现 SPI 机制，考虑到 Biz 卸载问题，Ark Biz 暂时不支持该 SPI 机制，只适用于 Ark Plugin 之间。\n声明扩展接口 使用注解 @Extensible 声明扩展接口，注解定义如下：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Extensible { /** * return specify extensible file name, default value is the * full name of interface. */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * return whether this a singleton, with a single, shared instance * returned on all calls, default value is true. */ boolean singleton() default true; } file 用于声明 SPI 扩展文件名，默认为接口全类名 singleton 用于声明加载扩展类是否为单例模式 声明扩展实现 使用注解 @Extension 声明扩展实现，注解定义如下：\n@Target({ ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Extension { /** * extension name */ String value(); /** * extension order, Higher values are interpreted as lower priority. * As a consequence, the object with the lowest value has the highest * priority. */ int order() default 100; } value 用于定义扩展实现名称，例如不同的插件扩展同一个接口，可能会取不同的名字。 order 用于决定具体扩展实现的生效顺序 运行时，对于同一个接口的扩展实现生效规则如下： + 规则一：名称相同的扩展实现，只会返回优先级高的扩展实现类，order 数字越小，优先级越高 + 规则二：名称不相同的扩展实现，则返回一个对应的 List 列表，每个名称返回优先级最高的扩展实现\n加载 SPI 实现类 正常情况下，我们使用 ServiceLoader 加载 SPI 接口实现；SOFAArk 提供了工具类 ArkServiceLoader 用于加载扩展实现，工具类定义了两个简单的方法：\npublic class ArkServiceLoader { private static ExtensionLoaderService extensionLoaderService; // 方法一 public static \u0026amp;lt;T\u0026amp;gt; T loadExtension(Class\u0026amp;lt;T\u0026amp;gt; interfaceType, String extensionName) { return extensionLoaderService.getExtensionContributor(interfaceType, extensionName); } // 方法二 public static \u0026amp;lt;T\u0026amp;gt; List\u0026amp;lt;T\u0026amp;gt; loadExtension(Class\u0026amp;lt;T\u0026amp;gt; interfaceType) { return extensionLoaderService.getExtensionContributor(interfaceType); } } 方法一：用于加载指定接口和名称的扩展实现，返回单个结果。参考上述规则一 方法二：用于加载指定接口的扩展实现，返回列表结果。参考上述规则二 需要注意下，定义 SPI 接口的插件需要导出该接口，负责实现 SPI 接口的插件需要导入该接口。另外 SOFAArk 容器本身也会定义部分用于插件扩展实现的 SPI 接口，例如 ClassLoaderHook\n为什么不支持 Biz 的 SPI 扩展实现加载 考虑到 Biz 会动态的安装和卸载，如果支持 Biz 的扩展实现加载，生命周期容易引起混乱，暂时不考虑支持。如果确实存在 Ark Plugin 需要主动触发 Ark Biz 的逻辑调用，可以通过 SOFAArk 内部事件机制。\nSOFAArk 默认扩展点 SOFAArk 容器目前提供了唯一一个扩展点 ClassLoaderHook，用于其他插件提供扩展实现，自定义类/资源加载逻辑。ClassLoaderHooker 接口定义如下，用于扩展 BizClassLoader 和 PluginClassLoader 类(资源）加载逻辑：\n@Extensible public interface ClassLoaderHook\u0026amp;lt;T\u0026amp;gt; { Class\u0026amp;lt;?\u0026amp;gt; preFindClass(String name, ClassLoaderService classLoaderService, T t) throws ClassNotFoundException; Class\u0026amp;lt;?\u0026amp;gt; postFindClass(String name, ClassLoaderService classLoaderService, T t) throws ClassNotFoundException; URL preFindResource(String name, ClassLoaderService classLoaderService, T t); URL postFindResource(String name, ClassLoaderService classLoaderService, T t); Enumeration\u0026amp;lt;URL\u0026amp;gt; preFindResources(String name, ClassLoaderService classLoaderService, T t) throws IOException; Enumeration\u0026amp;lt;URL\u0026amp;gt; postFindResources(String name, ClassLoaderService classLoaderService, T t) throws IOException; } 通过在插件中扩展该 SPI 接口实现，可以自定义 PluginClassLoader 和 BizClassLoader 的类/资源的加载逻辑。 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-extension/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"685e049f442cde4f3f51fefad5453dae","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","summary":"Ark 容器和 Ark Plugin 在运行时由不同的类加载器加载，不能使用常规的 ServiceLoader 提供 SPI 扩展，SOFAArk 自定义扩展点 SPI 机制， Ark Plugin 实现 SPI 机制，考虑到 Biz 卸载问题，A","tags":null,"title":"Ark 扩展机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/","wordcount":1961},{"author":null,"categories":null,"content":"SOFAArk 容器使用了 logback 日志实现，并集成了 sofa-common-tools，日志相关配置可以参考 配置文档, 这里介绍 SOFAArk 三个日志文件：\n sofa-ark/common-default.log \u0026amp;gt; sofa-ark 默认日志，打印 SOFAArk 启动日志等，大概内容如下： 2019-03-12 15:08:55,758 INFO main - Begin to start ArkServiceContainer 2019-03-12 15:08:56,290 INFO main - Init Service: com.alipay.sofa.ark.container.session.StandardTelnetServerImpl 2019-03-12 15:08:56,311 INFO main - Listening on port: 1234 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.plugin.PluginDeployServiceImpl 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.biz.BizDeployServiceImpl 2019-03-12 15:08:56,313 INFO main - Init Service: com.alipay.sofa.ark.container.service.classloader.ClassLoaderServiceImpl 2019-03-12 15:08:56,317 INFO main - Finish to start ArkServiceContainer 2019-03-12 15:08:56,338 INFO main - Start to process pipeline stage: com.alipay.sofa.ark.container.pipeline.HandleArchiveStage 2019-03-12 15:08:56,349 INFO main - Finish to process pipeline stage: com.alipay.sofa.ark.container.pipeline.HandleArchiveStage 2019-03-12 15:08:56,349 INFO main - Start to process pipeline stage: com.alipay.sofa.ark.container.pipeline.RegisterServiceStage 2019-03-12 15:08:56,354 INFO main - Service: com.alipay.sofa.ark.spi.service.biz.BizManagerService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,354 INFO main - Service: com.alipay.sofa.ark.spi.service.biz.BizFactoryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,355 INFO main - Service: com.alipay.sofa.ark.spi.service.plugin.PluginManagerService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,356 INFO main - Service: com.alipay.sofa.ark.spi.service.plugin.PluginFactoryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,356 INFO main - Service: com.alipay.sofa.ark.spi.service.event.EventAdminService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,357 INFO main - Service: com.alipay.sofa.ark.spi.service.registry.RegistryService publish by: ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=-2147483648} succeed 2019-03-12 15:08:56,360 INFO main - Inject {field= bizManagerService} of {service= ServiceMetadata{service=\u0026#39;com.alipay.sofa.ark.spi.service.biz.BizDeployer\u0026#39;, provider=\u0026#39;ServiceProvider{provider=\u0026#39;Ark Container\u0026#39;, order=100}\u0026#39;}} success! sofa-ark/common-error.log \u0026amp;gt; sofa-ark 错误日志，打印 SOFAArk 容器运行时错误日志，例如 biz 启动失败日志等： 2019-03-12 16:38:41,873 ERROR main - Start biz: Startup In IDE meet error java.lang.reflect.InvocationTargetException: null at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-log/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a514225510e53e9bf7173734c1f878e1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","summary":"SOFAArk 容器使用了 logback 日志实现，并集成了 sofa-common-tools，日志相关配置可以参考 配置文档, 这里介绍 SOFAArk 三个日志文件： sofa-ark/common-default.log \u0026gt; sofa-ark 默认日志，打","tags":null,"title":"Ark 日志","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/","wordcount":667},{"author":null,"categories":null,"content":" SOFAArk 定义了两种服务类型，用于解决应用和插件，应用和应用之间的通信问题，下面分别介绍这两种服务类型：\n插件服务 SOFAArk 允许在 Plugin 通过 PluginContext 发布和引用服务，也可以使用注解 @ArkInject 引用服务。为了方便开发高级特性，SOFAArk 容器默认将内部功能组件发布成了服务，包括 Biz 管理，Plugin 管理，事件管理，服务注册管理。目前不允许 Biz 发布服务，只能引用插件服务。下面介绍如何发布和引用插件服务，以及 SOFAArk 容器默认发布的服务。\n发布服务 每个 Plugin 都可以定义唯一的插件入口，需要实现 PluginActivator 接口并在打包插件配置中声明，先看下接口定义：\npublic interface PluginActivator { /** * Start Plugin * @param context plugin context * @throws ArkRuntimeException */ void start(PluginContext context); /** * Stop Plugin * @param context * @throws ArkRuntimeException */ void stop(PluginContext context); } SOFAArk 容器在启动插件时，会调用插件启动入口(如果有)，因此如果插件实现方需要发布插件服务供其他插件或者 Biz 调用，可以使用入参 PluginContext 发布服务，PluginContext 提供了两个方法发布服务：\n/** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject); /** * Publish Plugin Service * @param ifClass service interface * @param implObject service implement object * @param uniqueId service implementation id * @param \u0026amp;lt;T\u0026amp;gt; * @return */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; publishService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, T implObject, String uniqueId); 这两个方法的区别在于是否指定 uniqueId，因为同一个接口，可能会有多个服务实现，因此需要使用 uniqueId 区别，同样在引用端也需要指定 uniqueId. 默认 uniqueId 为空\n引用服务 SOFAArk 提供了两种方式引用插件服务，在插件内部，可以直接使用 PluginContext 引用服务，PluginContext 提供了两个简单的方法引用服务：\n/** * Get Service publish by plugin, when there are multiple services, return the highest priority plugin service * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass); /** * Get Service publish by one specific plugin * @param ifClass service interface * @param \u0026amp;lt;T\u0026amp;gt; * @param uniqueId service implementation * @return service reference */ \u0026amp;lt;T\u0026amp;gt; ServiceReference\u0026amp;lt;T\u0026amp;gt; referenceService(Class\u0026amp;lt;T\u0026amp;gt; ifClass, String uniqueId); 在 Biz 内部，如果是 Spring Boot/SOFABoot 应用，可以直接使用注解 @ArkInject 引用服务，注解声明如下：\n@java.lang.annotation.Target(ElementType.FIELD) @java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME) @java.lang.annotation.Documented public @interface ArkInject { /** * ark service interface * @return */ Class\u0026amp;lt;?\u0026amp;gt; interfaceType() default void.class; /** * ark service uniqueId * * @return return reference unique-id */ String uniqueId() default \u0026amp;quot;\u0026amp;quot;; } SOFAArk 提供集成 Spring Boot/SOFABoot 功能，在 Field 上打上 @ArkInject，指定接口类型和 uniqueId 即可完成自动注入。为了更加方便的使用，如果没有指定 interfacetType 类型，默认使用被打注解的 Field 类型。\n在插件内部，有时候也可以使用 @ArkInject 引用服务，即插件在发布某个服务时，服务内部可以直接使用 @ArkInject 引用服务；需要注意的是，被引用的服务如果是其他插件发布的，则必须满足其他插件优先当前插件启动。\n默认服务 前面提到，为了方便 Plugin 和 Biz 开发高级特性，SOFAArk 将内部功能组件发布成服务，包括：\n BizManageService \u0026amp;gt; Biz 管理器，管理、查询 Biz 信息\n BizFactoryService \u0026amp;gt; Biz 解析器，解析 Biz 文件\n PluginManagerService \u0026amp;gt; Plugin 管理器，管理、查询 Plugin 信息\n PluginFactoryService \u0026amp;gt; Plugin 解析器，解析 Plugin 文件\n EventAdminService \u0026amp;gt; SOFAArk 事件管理器， …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-service/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"81b7e697b890139c03831cdb648e094b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","summary":"SOFAArk 定义了两种服务类型，用于解决应用和插件，应用和应用之间的通信问题，下面分别介绍这两种服务类型： 插件服务 SOFAArk 允许在 Plugin 通过 PluginContext 发布和引用服务，也可","tags":null,"title":"Ark 服务机制","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/","wordcount":1188},{"author":null,"categories":null,"content":" 在 Ark 服务机制 中，我们详细介绍了如何引用和发布插件服务，主要是解决 Plugin 和 Biz 的通信问题；为了解决 Biz 之间的通信问题，SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference 编程界面；下面介绍其使用方法。\n引入依赖 引入 runtime-sofa-boot-plugin 依赖，如果应用基于 Spring Boot 1.x 开发，推荐使用 v2.6.1 版本；如果应用基于 Spring Boot 2.x 开发，推荐使用 v3.1.3 版本；\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 发布和引用 JVM 服务 SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference JVM 服务概念(参考文档)，为了方便文档统一，重复其介绍。\nSOFABoot 提供三种方式给开发人员发布和引用 JVM 服务\n XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上面的 Bean 发布成一个 SOFA JVM 服务。\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 上面的配置中的 interface 指的是需要发布成服务的接口，ref 指向的是需要发布成 JVM 服务的 Bean，至此，我们就已经完成了一个 JVM 服务的发布。\n服务引用 使用 SOFA 提供的 Spring 扩展标签引用服务:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上面的配置中的 interface 是服务的接口，需要和发布服务时配置的 interface 一致。id 属性的含义同 Spring BeanId。上面的配置会生成一个 id 为 sampleServiceRef 的 Spring Bean，你可以将 sampleServiceRef 这个 Bean 注入到当前 SOFABoot 模块 Spring 上下文的任意地方。\n service/reference 标签还支持 RPC 服务发布，相关文档: RPC 服务发布与引用\n Annotation 方式 警告\n如果一个服务已经被加上了 @SofaService 的注解，它就不能再用 XML 的方式去发布服务了，选择一种方式发布服务，而不是两种混用。\n 除了通过 XML 方式发布 JVM 服务和引用之外，SOFABoot 还提供了 Annotation 的方式来发布和引用 JVM 服务。通过 Annotation 方式发布 JVM 服务，只需要在实现类上加一个 @SofaService 注解即可，如下：\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } 提示\n@SofaService 的作用是将一个 Bean 发布成一个 JVM 服务，这意味着虽然你可以不用再写 \u0026amp;lt;sofa:service/\u0026amp;gt; 的配置，但是还是需要事先将 @SofaService 所注解的类配置成一个 Spring Bean。\n 在使用 XML 配置 \u0026amp;lt;sofa:service/\u0026amp;gt; 的时候，我们配置了一个 interface 属性，但是在使用 @SofaService 注解的时候，却没有看到有配置服务接口的地方。这是因为当被 @SofaService 注解的类只有一个接口的时候，框架会直接采用这个接口作为服务的接口。当被 @SofaService 注解的类实现了多个接口时，可以设置 @SofaService 的 interfaceType 字段来指定服务接口，比如下面这样：\n@SofaService(interfaceType = SampleInterface.class) public class SampleImpl implements SampleInterface, Serializable { public void test() { } } 和 @SofaService 对应，Sofa 提供了 @SofaReference 来引用一个 JVM 服务。假设我们需要在一个 Spring Bean 中使用 SampleJvmService 这个 JVM 服务，那么只需要在字段上加上一个 @SofaReference 的注解即可：\npublic class SampleServiceRef { @SofaReference private SampleService sampleService; } 和 @SofaService 类似，我们也没有在 @SofaReference 上指定服务接口，这是因为 @SofaReference 在不指定服务接口的时候，会采用被注解字段的类型作为服务接口，你也可以通过设定 @SofaReference 的 interfaceType 属性来指定：\npublic class SampleServiceRef { @SofaReference(interfaceType = SampleService.class) private SampleService sampleService; } 使用 @SofaService 注解发布服务时，需要在实现类上打上 @SofaService 注解；在 Spring Boot 使用 Bean Method 创建 Bean 时，会导致 @Bean 和 @SofaService 分散在两处，而且无法对同一个实现类使用不同的 unique id。 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-jvm/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1bf80b24428da0f91edc6af7b63f6047","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","summary":"在 Ark 服务机制 中，我们详细介绍了如何引用和发布插件服务，主要是解决 Plugin 和 Biz 的通信问题；为了解决 Biz 之间的通信问题，SOFAArk 引入了 SOFABoot 提供的 SofaService/SofaReference 编","tags":null,"title":"Ark 服务通信","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/","wordcount":2430},{"author":null,"categories":null,"content":" Use java.lang.Runnable in thread If you start a thread via java.lang.Runnable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerRunnable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.start(); Use java.util.concurrent.Callable in thread If you start a thread via java.util.concurrent.Callable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerCallable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nExecutorService executor = Executors.newCachedThreadPool(); SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt; sofaTracerSpanSofaTracerCallable = new SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt;(new Callable\u0026amp;lt;Object\u0026amp;gt;() { @Override public Object call() throws Exception { return new Object(); } }); Future\u0026amp;lt;Object\u0026amp;gt; futureResult = executor.submit(sofaTracerSpanSofaTracerCallable); //do something in current thread Thread.sleep(1000); //another thread execute success and get result Object objectReturn = futureResult.get(); This example assumes that the object type returned by java.util.concurrent.Callable is java.lang.Object. You can replace it with the expected type based on actual situation.\nSOFATracer support for thread pool and asynchronous call scenarios Asynchronous Asynchronous invocation, in RPC calls, for example,each time the rpc call request goes out, it will not wait until the result is returned before initiating the next call. There is a time difference here, before the callback of the previous rpc call comes back, another new one begin. At this time, the TracerContext in the current thread is not cleaned up, the spanId will be incremented, and the tracerId is the same.\n For the above situation, when the SOFATracer is processed for the asynchronous situation, it will not wait for the callback to execute, and then the cr phase will be cleaned up. Instead, the current thread\u0026amp;rsquo;s tracerContext context will be cleaned up in advance to ensure the correctness of the link.\nThread Pool For now, whether it\u0026amp;rsquo;s SOFARPC or Dubbo\u0026amp;rsquo;s trace implementation, the situation is the same when using single-thread or thread pools:\n Synchronous call. A thread in the thread pool is allocated to handle the RPC request. This does not cause the next RPC request to take the tracerContext data of the previous request by mistake Asynchronous calls, since the asynchronous callback is not in the callback to clean up the context, but in advance, there is no dirty data problem. callback, which is essentially an …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/async/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e755346c441115663c101638667fe4c0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/async/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/async/","summary":"Use java.lang.Runnable in thread If you start a thread via java.lang.Runnable in the code or use a thread pool to process some businesses asynchronously, SOFATracer log context needs to be passed from the parent thread to the child thread. com.alipay.common.tracer.core.async.SofaTracerRunnable provided by SOFATracer is reponsible for completing this operation by default. You can use it as follows:\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.","tags":null,"title":"Asynchronous thread processing","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/async/","wordcount":436},{"author":null,"categories":null,"content":" ## Model\nApplications Jarslink manages the life cycle of multiple applications. During runtime dynamic deployment, it usually converts a Jar file entity into an abstract model Biz. + Biz: abstract model of the application at runtime\nInstruction Currently, Jarslink supports the telnet protocol and accepts the entered instructions. In the future, it will also support instruction execution through APIs. Acceptable instruction types: + InstallCommand: install the application + UninstallCommand: uninstall the application + CheckCommand: check the application state + SwitchCommand: switch the application state\nService The Jarslink plugin has expanded the SOFAArk container\u0026amp;rsquo;s services of BizDeployer and CommandProvider and referenced the SOFAArk container\u0026amp;rsquo;s exposed services of BizManagerService and BizFactoryService. + BizDeployer is the application deployment extension point provided by the SOFAArk container, and it is used to control the Biz startup in the Ark package. Jarslink has registered its own implementation with the SOFAArk container. + CommandProvider is the command processing extension point provided by the SOFAArk container, and it is used to process the commands received by the SOFAArk container through a telnet link. + BizManagerService is the Biz manager exposed by the SOFAArk container, and it is used for registration, deregistration, and other operations. + BizFactoryService is the Biz generator exposed by the SOFAArk container, and it is used to abstract static Biz package files into runtime Biz models.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-model/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"991cb277d50874fa27095b920ac9b736","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","summary":"## Model\nApplications Jarslink manages the life cycle of multiple applications. During runtime dynamic deployment, it usually converts a Jar file entity into an abstract model Biz. + Biz: abstract model of the application at runtime\nInstruction Currently, Jarslink supports the telnet protocol and accepts the entered instructions. In the future, it will also support instruction execution through APIs. Acceptable instruction types: + InstallCommand: install the application + UninstallCommand: uninstall the application + CheckCommand: check the application state + SwitchCommand: switch the application state","tags":null,"title":"Basic model","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/","wordcount":221},{"author":null,"categories":null,"content":" Messages All messages are internally passed through SofaRequest and SofaResponse.\nTo convert to other protocols, you need to transform the messages to the objects that are to be actually transferred when calling and receiving requests.\nThe modules that can write SofaRequest and SofaResponse are as follows:\n Invoker Filter ServerHandler Serialization The modules that can only read message bodies are as follows:\n Cluster Router LoadBalance Logs The log initialization is based on the extension mechanism. Since the log loading should be done earliest, there is a separate key in rpc-config.json.\n{ / / Log implementation is done earlier than configuration loading, so it cannot adapt to the extension mechanism \u0026amp;quot;logger.impl\u0026amp;quot;: \u0026amp;quot;com.alipay.sofa.rpc.log.MiddlewareLoggerImpl\u0026amp;quot; } Configuration items RPC configuration for users The user configuration includes port configuration (although the fields for setting port in the objects have been opened, SOFA gets those fields from the configuration file by default), thread pool size configuration, and other configurations.\n Load the configuration via SofaConfigs and call ExternalConfigLoader to read external properties. Get the configuration through the API provided by SofaConfigs. All the internally configured keys are in the SofaOptions class. Priority: System.property \u0026amp;gt; sofa-config.properties (one for each application) \u0026amp;gt; rpc-config.properties. RPC framework configuration The configuration of the framework itself, such as default serialization and default timeout. In the future, SOFARPC may support the configuration for multiple ClassLoaders.\n Load the configuration file via RpcConfigs. Get and listen to data changes via the API provided by RpcConfigs All internally configured keys are in the RpcOptions class Priority: System.property \u0026amp;gt; custom rpc-config.json (There may be multiple custom configuration files which are sorted in certain order) \u0026amp;gt; rpc-config-default.json. Constants The global basic constants are in RpcConstants. For example: Calling method (sync/oneway) Protocol (bolt/grpc/rest); serialization (hessian/java/protobuf) Context key If the extension implements its own constants, you need to maintain the constants yourself. For example:\n The constants of BOLT protocol SERIALIZE_CODE_HESSIAN = 1 PROTOCOL_TR = 13 The constants related with DSR Configuration Center The keys specific for DSR Configuration Center, such as _WEIGHT and _CONNECTTIMEOUT Address The address information of provider is placed in the ProviderInfo class. The value of ProviderInfo is mainly divided into three parts: Fields, which are generally required items, such as IP, port and status. Static fields, such as application name. Dynamic fields, such as warm-up weight. Field enumerations are maintained in the ProviderInfoAttrs class. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/common-model/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b2cc3f7ed134408d6adc25e418e1978b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/common-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/common-model/","summary":"Messages All messages are internally passed through SofaRequest and SofaResponse.\nTo convert to other protocols, you need to transform the messages to the objects that are to be actually transferred when calling and receiving requests.\nThe modules that can write SofaRequest and SofaResponse are as follows:\n Invoker Filter ServerHandler Serialization The modules that can only read message bodies are as follows:\n Cluster Router LoadBalance Logs The log initialization is based on the extension mechanism.","tags":null,"title":"Basic model","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/common-model/","wordcount":386},{"author":null,"categories":null,"content":" Publish Service To use SOFARPC to publish a Bolt-protocol service, you only need to add a Binding named bolt. The ways to add Bolt Binding are as follows:\nXML To publish a Bolt service using XML, simply add the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag to the \u0026amp;lt;sofa:service\u0026amp;gt; tag:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation To publish a Bolt service using Annotation, you only need to set the bindingType of @SofaServiceBinding to bolt:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)}) Public class SampleServiceImpl implements SampleService { } API in Spring environment To publish a Bolt-protocol service in Spring or Spring Boot environment, just add BoltBindingParam to ServiceParam:\nServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(SampleService.class); // Set the service interface serviceParam.setInstance(new SampleServiceImpl()); // Set the implementation of the service interface List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); Params.add(serviceBindingParam); serviceParam.setBindingParams(params); API in non-Spring environment To provide the Bolt-protocol service using the bare API of SOFARPC in a non-Spring environment, just set the ServerConfig whose protocol is Bolt to the corresponding ProviderConfig:\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;); // Create a new ServerConfig with Bolt protocol ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRef(new SampleServiceImpl()) .setServer(serverConfig) // Set ServerConfig to ProviderConfig to indicate that the protocol published by this service is Bolt. .setRegistry(registryConfig); providerConfig.export(); Reference Service To reference a Bolt-protocol service using SOFARPC, just add a Binding named bolt. The ways to use Bolt Binding are as follows:\nXML To reference a Bolt-protocol service using XML, simply add the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag to the \u0026amp;lt;sofa:reference\u0026amp;gt; tag:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation To reference a Bolt-protocol service using Annotation, just set the bindingType of @SofaReferenceBinding to bolt:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) Private SampleService sampleService; API in Spring environment To reference a Bolt-protocol service in a Spring or Spring Boot environment, simply add a BoltBindingParam to ReferenceParam:\nReferenceClient …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-usage/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dd929c0a3cd2f4620ddf0d30d98ba85d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","summary":"Publish Service To use SOFARPC to publish a Bolt-protocol service, you only need to add a Binding named bolt. The ways to add Bolt Binding are as follows:\nXML To publish a Bolt service using XML, simply add the \u0026lt;sofa:binding.bolt\u0026gt; tag to the \u0026lt;sofa:service\u0026gt; tag:\n\u0026lt;sofa:service ref=\u0026quot;sampleService\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.sample.SampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt/\u0026gt; \u0026lt;/sofa:service\u0026gt; Annotation To publish a Bolt service using Annotation, you only need to set the bindingType of @SofaServiceBinding to bolt:","tags":null,"title":"Basic usage of Bolt protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt-usage/","wordcount":364},{"author":null,"categories":null,"content":" In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the Dubbo protocol, just set Binding to Dubbo. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish a Dubbo service, just set the bindingType of @SofaServiceBinding to dubbo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a Dubbo service, just set the bindingType of @SofaReferenceBinding to dubbo:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; Set the Group of Dubbo Service In the SOFARPC program model, there is no field called Group, but there is a model of uniqueId, which can be directly mapped to the Group in Dubbo model. For example, the following code is to publish a service whose Group is groupDemo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}, uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;) public class SampleServiceImpl implements SampleService { } The following code is to reference a service whose Group is groupDemo:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;, jvmFirst = false) private SampleService sampleService; Note that Dubbo protocol currently only supports Zookeeper as service registry center.\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo-usage/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1bf72c194a20a5dccea70423690191f4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","summary":"In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the Dubbo protocol, just set Binding to Dubbo. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish a Dubbo service, just set the bindingType of @SofaServiceBinding to dubbo:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026quot;dubbo\u0026quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a Dubbo service, just set the bindingType of @SofaReferenceBinding to dubbo:","tags":null,"title":"Basic usage of Dubbo protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/","wordcount":203},{"author":null,"categories":null,"content":" In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the H2C protocol, just set Binding to H2C. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish an H2C service, just set the bindingType of @SofaServiceBinding to h2c:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a H2C service, just set the bindingType of @SofaReferenceBinding to h2c:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c-usage/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fa75eff1e99b3acad5087160a1b44a09","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","summary":"In SOFARPC, to use different communication protocols, it is only required to use different Bindings. If you need to use the H2C protocol, just set Binding to H2C. The following shows an example using Annotation. For other usage methods, refer to Basic usage of Bolt protocol.\nPublish Service To publish an H2C service, just set the bindingType of @SofaServiceBinding to h2c:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026quot;h2c\u0026quot;)}) public class SampleServiceImpl implements SampleService { } Reference Service To reference a H2C service, just set the bindingType of @SofaReferenceBinding to h2c:","tags":null,"title":"Basic usage of H2C protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/h2c-usage/","wordcount":100},{"author":null,"categories":null,"content":" In SOFARPC (Not In SOFABoot/SpringBoot)，when use Http as a protocol of server，we can use Json as the way of serialization，for some basic test scenes.\nSOFARPC API Usage Service Publish ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026amp;quot;serverApp\u0026amp;quot;)) .setServer(serverConfig) .setUniqueId(\u0026amp;quot;uuu\u0026amp;quot;) .setRegister(false); providerConfig.export(); Service Consume Because of the Http+Json，So users can use HttpClient to start a normal call, this is a piece of code in test.\nprivate ObjectMapper mapper = new ObjectMapper(); HttpClient httpclient = HttpClientBuilder.create().build(); // POST normal request String url = \u0026amp;quot;http://127.0.0.1:12300/com.alipay.sofa.rpc.server.http.HttpService:uuu/object\u0026amp;quot;; HttpPost httpPost = new HttpPost(url); httpPost.setHeader(RemotingConstants.HEAD_SERIALIZE_TYPE, \u0026amp;quot;json\u0026amp;quot;); ExampleObj obj = new ExampleObj(); obj.setId(1); obj.setName(\u0026amp;quot;xxx\u0026amp;quot;); byte[] bytes = mapper.writeValueAsBytes(obj); ByteArrayEntity entity = new ByteArrayEntity(bytes, ContentType.create(\u0026amp;quot;application/json\u0026amp;quot;)); httpPost.setEntity(entity); HttpResponse httpResponse = httpclient.execute(httpPost); Assert.assertEquals(200, httpResponse.getStatusLine().getStatusCode()); byte[] data = EntityUtils.toByteArray(httpResponse.getEntity()); ExampleObj result = mapper.readValue(data, ExampleObj.class); Assert.assertEquals(\u0026amp;quot;xxxxx\u0026amp;quot;, result.getName()); You will get some result.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http-json/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"28abdf6369247346bad670c639a422b8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/http-json/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/http-json/","summary":"In SOFARPC (Not In SOFABoot/SpringBoot)，when use Http as a protocol of server，we can use Json as the way of serialization，for some basic test scenes.\nSOFARPC API Usage Service Publish ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); ProviderConfig\u0026lt;HttpService\u0026gt; providerConfig = new ProviderConfig\u0026lt;HttpService\u0026gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026quot;serverApp\u0026quot;)) .setServer(serverConfig) .setUniqueId(\u0026quot;uuu\u0026quot;) .setRegister(false); providerConfig.export(); Service Consume Because of the Http+Json，So users can use HttpClient to start a normal call, this is a piece of code in test.","tags":null,"title":"Basic usage of HTTP protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/http-json/","wordcount":140},{"author":null,"categories":null,"content":" In SOFARPC, using different communication protocols is equal to using different Bindings. If you need to use the RESTful protocol, just set Binding to REST.\nPublish Service When defining a RESTful service interface, you need to add meta information to the interface using the annotations in JAXRS standard, such as the following interface:\n@Path(\u0026amp;quot;sample\u0026amp;quot;) public interface SampleService { @GET @Path(\u0026amp;quot;hello\u0026amp;quot;) String hello(); } The annotations in JAXRS standard can be found in RESTEasy documentation.\n After the interface is defined, you can publish the implementation of the interface as a service, for example, by means of Annotation:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}) public class RestfulSampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } If you want to publish the service by other methods, please refer to Basic usage of Bolt protocol.\nAccess services through browser After the service is published, you can directly access the service through the browser. For the above service, the access address is as follows:\nhttp://localhost:8341/sample/hello The default port for SOFARPC RESTful service is 8341.\nReference Service In addition to accessing RESTful services published by SOFARPC through a browser, you can also reference services through the standard SOFARPC service reference methods, such as Annotation:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)) private SampleService sampleService; If you want to reference the service by other methods, please refer to Basic usage of Bolt protocol.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-basic/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d41f976864ba8f8221f5b5d26f354d1c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-basic/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-basic/","summary":"In SOFARPC, using different communication protocols is equal to using different Bindings. If you need to use the RESTful protocol, just set Binding to REST.\nPublish Service When defining a RESTful service interface, you need to add meta information to the interface using the annotations in JAXRS standard, such as the following interface:\n@Path(\u0026quot;sample\u0026quot;) public interface SampleService { @GET @Path(\u0026quot;hello\u0026quot;) String hello(); } The annotations in JAXRS standard can be found in RESTEasy documentation.","tags":null,"title":"Basic usage of RESTful protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-basic/","wordcount":228},{"author":null,"categories":null,"content":" Benchmark 源码解析任务还在进行中，敬请期待！\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-benchmark/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fdcbd9e5c563ad087756f0703f94db61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","summary":"Benchmark 源码解析任务还在进行中，敬请期待！","tags":null,"title":"Benchmark","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/","wordcount":18},{"author":null,"categories":null,"content":" Test code\nTest environment and conditions Three 16-core 20 GB memory Docker containers as the server nodes (3 replicas) Two to eight 8-core Docker containers as clients 24 Raft groups. Each server node has eight leaders responsible for processing read/right requests. Followers do not have the permission to read. The target of stress testing is the RheaKV module of JRaft. Only the put and get APIs are subject to stress testing. Linearizable reads are guaranteed for the get API. The key size and value size are both 16 bytes. The read percentage is 10% and the write percentage is 90%. Currently, the test scenarios are relatively simple. We will add more test scenarios in the future.\nTest scenario 1 Scenario 1: Test conditions Number of clients Client batching Storage type Read/write ratio Replicator pipeline Key size Value size 8 Enabled MemoryDB 1:9 Enabled 16 bytes 16 bytes Scenario 1: Result summary Eight clients achieved 400,000+ ops, and the p95 RT is within 8 ms. Three server nodes didn\u0026amp;rsquo;t reach their maximum load. The load is about 15, and the CPU usage is about 40%. Scenario 1: Load of three servers Scenario 1: Server 1 top - 20:11:14 up 10 days, 23:09, 1 user, load average: 12.29, 6.92, 4.00 Tasks: 36 total, 1 running, 35 sleeping, 0 stopped, 0 zombie %Cpu0 : 24.3 us, 17.7 sy, 0.0 ni, 50.0 id, 2.0 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu1 : 21.9 us, 18.5 sy, 0.0 ni, 49.5 id, 2.0 wa, 0.0 hi, 0.0 si, 8.1 st %Cpu2 : 20.6 us, 18.6 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 5.6 st %Cpu3 : 23.3 us, 20.0 sy, 0.0 ni, 50.3 id, 1.3 wa, 0.0 hi, 0.0 si, 5.0 st %Cpu4 : 24.1 us, 19.1 sy, 0.0 ni, 49.8 id, 2.3 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu5 : 21.3 us, 18.9 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu6 : 24.7 us, 18.4 sy, 0.0 ni, 50.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu7 : 24.8 us, 17.8 sy, 0.0 ni, 50.0 id, 1.7 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu8 : 26.0 us, 18.3 sy, 0.0 ni, 51.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu9 : 26.6 us, 16.9 sy, 0.0 ni, 52.2 id, 2.0 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu10 : 31.7 us, 17.7 sy, 0.0 ni, 46.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu11 : 23.2 us, 18.9 sy, 0.0 ni, 53.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu12 : 25.6 us, 18.3 sy, 0.0 ni, 51.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu13 : 22.6 us, 18.3 sy, 0.0 ni, 54.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu14 : 24.7 us, 17.3 sy, 0.0 ni, 54.0 id, 1.7 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu15 : 61.8 us, 8.3 sy, 0.0 ni, 28.2 id, 0.3 wa, 0.0 hi, 0.0 si, 1.3 st KiB Mem : 62914560 total, 6854596 free, 39128016 used, 16931948 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 6854596 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15682 root 20 0 12.853g 8.859g 24064 S 708.7 14.8 26:49.38 java Scenario 1: Server 2 top - 20:11:47 up 10 days, 23:03, 1 user, load average: 17.68, 8.50, 4.56 Tasks: 33 total, 1 running, 31 sleeping, 0 stopped, 1 zombie %Cpu0 : 22.7 us, 17.3 sy, 0.0 ni, 35.0 id, 8.3 wa, 0.0 hi, 0.0 si, 16.7 st %Cpu1 : 20.1 us, 19.4 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/benchmark-performance/","fuzzywordcount":8900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4530827525ca87732eaf76ae34f03603","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","publishdate":"0001-01-01T00:00:00Z","readingtime":42,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","summary":"Test code\nTest environment and conditions Three 16-core 20 GB memory Docker containers as the server nodes (3 replicas) Two to eight 8-core Docker containers as clients 24 Raft groups. Each server node has eight leaders responsible for processing read/right requests. Followers do not have the permission to read. The target of stress testing is the RheaKV module of JRaft. Only the put and get APIs are subject to stress testing.","tags":null,"title":"Benchmark data","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/","wordcount":8817},{"author":null,"categories":null,"content":" 测试代码\n测试环境\u0026amp;amp;条件 3 台 16C 20G 内存的 docker 容器作为 server node (3 副本) 2 ~ 8 台 8C docker 容器 作为 client 24 个 raft 复制组，平均每台 server node 上各自有 8 个 leader 负责读写请求，不开启 follower 读 压测目标为 JRaft 中的 RheaKV 模块，只压测 put、get 两个接口，其中 get 是保证线性一致读的，key 和 value 大小均为 16 字节 读比例 10%，写比例 90% 目前的测试场景比较简单，以后会增加更多测试场景\n测试场景1 场景1: 测试条件 Client 数量 Client-Batching Storage-Type 读写比例 Replicator-Pipeline key 大小 value 大小 8 开启 MemoryDB 1:9 开启 16 字节 16字节 场景1: 结果汇总： 8 个 client 一共达到 40w+ ops，p95 RT 在 8ms 以内 3 个 server 节点负载没达到极限 load 15 左右，cpu 40% 左右 场景1: 3 个 server 机器负载： 场景1: server1 top - 20:11:14 up 10 days, 23:09, 1 user, load average: 12.29, 6.92, 4.00 Tasks: 36 total, 1 running, 35 sleeping, 0 stopped, 0 zombie %Cpu0 : 24.3 us, 17.7 sy, 0.0 ni, 50.0 id, 2.0 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu1 : 21.9 us, 18.5 sy, 0.0 ni, 49.5 id, 2.0 wa, 0.0 hi, 0.0 si, 8.1 st %Cpu2 : 20.6 us, 18.6 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 5.6 st %Cpu3 : 23.3 us, 20.0 sy, 0.0 ni, 50.3 id, 1.3 wa, 0.0 hi, 0.0 si, 5.0 st %Cpu4 : 24.1 us, 19.1 sy, 0.0 ni, 49.8 id, 2.3 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu5 : 21.3 us, 18.9 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu6 : 24.7 us, 18.4 sy, 0.0 ni, 50.2 id, 2.0 wa, 0.0 hi, 0.0 si, 4.7 st %Cpu7 : 24.8 us, 17.8 sy, 0.0 ni, 50.0 id, 1.7 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu8 : 26.0 us, 18.3 sy, 0.0 ni, 51.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu9 : 26.6 us, 16.9 sy, 0.0 ni, 52.2 id, 2.0 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu10 : 31.7 us, 17.7 sy, 0.0 ni, 46.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.0 st %Cpu11 : 23.2 us, 18.9 sy, 0.0 ni, 53.3 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu12 : 25.6 us, 18.3 sy, 0.0 ni, 51.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu13 : 22.6 us, 18.3 sy, 0.0 ni, 54.5 id, 2.3 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu14 : 24.7 us, 17.3 sy, 0.0 ni, 54.0 id, 1.7 wa, 0.0 hi, 0.0 si, 2.3 st %Cpu15 : 61.8 us, 8.3 sy, 0.0 ni, 28.2 id, 0.3 wa, 0.0 hi, 0.0 si, 1.3 st KiB Mem : 62914560 total, 6854596 free, 39128016 used, 16931948 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 6854596 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15682 root 20 0 12.853g 8.859g 24064 S 708.7 14.8 26:49.38 java 场景1: server2 top - 20:11:47 up 10 days, 23:03, 1 user, load average: 17.68, 8.50, 4.56 Tasks: 33 total, 1 running, 31 sleeping, 0 stopped, 1 zombie %Cpu0 : 22.7 us, 17.3 sy, 0.0 ni, 35.0 id, 8.3 wa, 0.0 hi, 0.0 si, 16.7 st %Cpu1 : 20.1 us, 19.4 sy, 0.0 ni, 43.8 id, 9.4 wa, 0.0 hi, 0.0 si, 7.4 st %Cpu2 : 23.3 us, 20.0 sy, 0.0 ni, 39.7 id, 10.3 wa, 0.0 hi, 0.0 si, 6.7 st %Cpu3 : 24.1 us, 20.1 sy, 0.0 ni, 40.8 id, 9.4 wa, 0.0 hi, 0.0 si, 5.7 st %Cpu4 : 21.4 us, 17.7 sy, 0.0 ni, 37.1 id, 9.0 wa, 0.0 hi, 0.0 si, 14.7 st %Cpu5 : 22.6 us, 19.6 sy, 0.0 ni, 40.5 id, 10.6 wa, 0.0 hi, 0.0 si, 6.6 st %Cpu6 : 23.6 us, 19.9 sy, 0.0 ni, 40.2 id, 10.3 wa, 0.0 hi, 0.0 si, 6.0 st %Cpu7 : 20.5 us, 19.9 sy, 0.0 ni, 44.4 id, 9.9 wa, 0.0 hi, 0.0 si, 5.3 st %Cpu8 : 40.7 us, 13.3 sy, 0.0 ni, 34.3 id, 9.0 wa, 0.0 hi, 0.0 si, 2.7 st %Cpu9 : 39.9 us, 14.0 sy, 0.0 ni, 35.2 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/benchmark-performance/","fuzzywordcount":9300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4530827525ca87732eaf76ae34f03603","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/benchmark-performance/","publishdate":"0001-01-01T00:00:00Z","readingtime":19,"relpermalink":"/sofastack.tech/projects/sofa-jraft/benchmark-performance/","summary":"测试代码 测试环境\u0026amp;条件 3 台 16C 20G 内存的 docker 容器作为 server node (3 副本) 2 ~ 8 台 8C docker 容器 作为 client 24 个 raft 复制组，平均每台 server node 上各自有 8 个 leader 负责读写请求","tags":null,"title":"Benchmark 数据","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/benchmark-performance/","wordcount":9269},{"author":null,"categories":null,"content":"Bolt protocol is a TCP-based custom protocol that performs better than HTTP. Within Ant Financial, a large number of RPCs use the Bolt protocol to communicate: * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b812f6aadadf38b79140a711ff6aa6cd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt/","summary":"Bolt protocol is a TCP-based custom protocol that performs better than HTTP. Within Ant Financial, a large number of RPCs use the Bolt protocol to communicate: * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool","tags":null,"title":"Bolt protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt/","wordcount":45},{"author":null,"categories":null,"content":"Bolt 协议一个基于 TCP 的自定义的协议，相比 HTTP 来说，性能更好，在蚂蚁金服内部，大量的 RPC 都是采用 Bolt 协议来进行通信： * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化协议 * 自定义线程池\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b812f6aadadf38b79140a711ff6aa6cd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt/","summary":"Bolt 协议一个基于 TCP 的自定义的协议，相比 HTTP 来说，性能更好，在蚂蚁金服内部，大量的 RPC 都是采用 Bolt 协议来进行通信： * 基本使用 * 调用方式 * 超时控制 * 泛化","tags":null,"title":"Bolt 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt/","wordcount":85},{"author":null,"categories":null,"content":" Bolt 协议基本使用 发布服务 使用 SOFARPC 发布一个 Bolt 协议的服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下：\nXML 使用 XML 发布一个 Bolt 协议只需要在 \u0026amp;lt;sofa:service\u0026amp;gt; 标签下增加 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签即可：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation 使用 Annotation 发布一个 Bolt 协议的服务只需要设置 @SofaServiceBinding 的 bindingType 为 bolt 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Spring 环境下 API 方式 在 Spring 或者 Spring Boot 环境下发布一个 Bolt 协议的服务只需要往 ServiceParam 里面增加一个 BoltBindingParam 即可：\nServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(SampleService.class); // 设置服务接口 serviceParam.setInstance(new SampleServiceImpl()); // 设置服务接口的实现 List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); 非 Spring 环境下的 API 方式 在非 Spring 环境下使用 SOFARPC 的裸 API 提供 Bolt 协议的服务，只需要将 Protocol 为 Bolt 的 ServerConfig 设置给对应的 ProviderConfig：\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;); // 新建一个协议为 Bolt 的 ServerConfig ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRef(new SampleServiceImpl()) .setServer(serverConfig) // 将 ServerConfig 设置给 ProviderConfig，表示这个服务发布的协议为 Bolt。 .setRegistry(registryConfig); providerConfig.export(); 引用服务 使用 SOFARPC 引用一个 Bolt 服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下：\nXML 使用 XML 引用一个 Bolt 协议的服务只需要在 \u0026amp;lt;sofa:reference\u0026amp;gt; 标签下增加 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签即可：\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.sample.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 使用 Annotation 引用一个 Bolt 协议的服务只需要设置 @SofaReferenceBinding 的 bindingType 为 bolt 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private SampleService sampleService; Spring 环境下 API 方式 在 Spring 或者 Spring Boot 环境下引用一个 Bolt 协议的服务只需要往 ReferenceParam 里面增加一个 BoltBindingParam 即可：\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;SampleService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;SampleService\u0026amp;gt;(); referenceParam.setInterfaceType(SampleService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); 非 Spring 环境下的 API 方式 在非 Spring 环境下使用 SOFARPC 的裸 API 引用一个 Bolt 协议的服务，只需要设置 ConsumerConfig 的 Protocol 为 bolt 即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-usage/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dd929c0a3cd2f4620ddf0d30d98ba85d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt-usage/","summary":"Bolt 协议基本使用 发布服务 使用 SOFARPC 发布一个 Bolt 协议的服务，只需要增加名称为 Bolt 的 Binding 即可，不同的使用方式添加 Bolt Binding 的方式如下： XML 使用 XML 发布一个 Bolt 协议只需要","tags":null,"title":"Bolt 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt-usage/","wordcount":570},{"author":null,"categories":null,"content":" 泛化调用提供了让客户端在不需要依赖服务端的接口情况下就能够发起调用的能力。目前 SOFARPC 的泛化调用仅支持在 Bolt 通信协议下使用 Hessian2 作为序列化协议，其他的方式并不支持。\nSOFABoot 环境 发布服务 发布服务没有什么特殊的,正常发布服务即可.比如\n\u0026amp;lt;!-- generic --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 引用服务 \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.api.GenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs generic-interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 其中,jvm-first根据实际情况,默认可以不写,接口写泛化调用的通用接口,generic-interface中写上自己要调用的接口名称即可.\n发起调用 GenericService sampleGenericServiceReference = (GenericService) applicationContext .getBean(\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot;); GenericObject genericResult = (GenericObject) sampleGenericServiceReference.$genericInvoke(\u0026amp;quot;sayGeneric\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericParamModel\u0026amp;quot; }, new Object[] { genericObject }); RPC API ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt;() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); 如上通过 setGeneric 设置该服务为泛化服务，设置服务方的接口名。以 GenericService 作为泛化服务，通过 GenericService 就能够发起泛化调用了。发起调用时，需要传入方法名，方法类型，方法参数。\n如果参数或者返回结果在客户端也需要泛化表示。可以通过 GenericObject 来实现。\nGenericObject genericObject = new GenericObject(\u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot;); genericObject.putField(\u0026amp;quot;str\u0026amp;quot;, \u0026amp;quot;xxxx\u0026amp;quot;); genericObject.putField(\u0026amp;quot;num\u0026amp;quot;, 222); GenericObject result = (GenericObject) testService.$genericInvoke(\u0026amp;quot;echoObj\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot; }, new Object[] { genericObject }); String str = result.getField(\u0026amp;quot;str\u0026amp;quot;); String num = result.getField(\u0026amp;quot;num\u0026amp;quot;); 如上就能获得序列化结果。完整的泛化调用方式使用说明如下：\n/** * Java Bean */ public class People { private String name; private int age; // getters and setters } /** * 服务方提供的接口 */ interface SampleService { String hello(String arg); People hello(People people); String[] hello(String[] args); } /** * 客户端 */ public class ConsumerClass { GenericService genericService; public void do() { // 1. $invoke仅支持方法参数类型在当前应用的 ClassLoader 中存在的情况 genericService.$invoke(\u0026amp;quot;hello\u0026amp;quot;, new String[]{ String.class.getName() }, new Object[]{\u0026amp;quot;I\u0026#39;m an arg\u0026amp;quot;}); // 2. $genericInvoke支持方法参数类型在当前应用的 ClassLoader 中不存在的情况。 // 2.1 构造参数 GenericObject genericObject = new …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/generic-invoke/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"84ac624dc99a42a8f89489aa10304ef7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/generic-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/generic-invoke/","summary":"泛化调用提供了让客户端在不需要依赖服务端的接口情况下就能够发起调用的能力。目前 SOFARPC 的泛化调用仅支持在 Bolt 通信协议下使用 Hessian2 作为序列化协议，其他的方","tags":null,"title":"Bolt 协议泛化调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/generic-invoke/","wordcount":710},{"author":null,"categories":null,"content":" 调用方式 SOFARPC 在 Bolt 协议下提供了多种调用方式满足不同的场景。\n同步 在同步的调用方式下，客户端发起调用后会等待服务端返回结果再进行后续的操作。这是 SOFARPC 的默认调用方式，无需进行任何设置即可。\n异步 异步调用的方式下，客户端发起调用后不会等到服务端的结果，继续执行后面的业务逻辑。服务端返回的结果会被 SOFARPC 缓存，当客户端需要结果的时候，再主动调用 API 获取。如果需要将一个服务设置为异步的调用方式，在对应的使用方式下设置 type 属性即可：\nXML 方式 在 XML 方式下，设置 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 type 属性为 future 即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 在 Annotation 方式下，设置 @SofaReferenceBinding 的 invokeType 属性为 future 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, invokeType = \u0026amp;quot;future\u0026amp;quot;)) private SampleService sampleService; Spring 环境下 API 方式 在 Spring 环境下使用 API，设置 BoltBindingParam 的 type 属性即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setType(\u0026amp;quot;future\u0026amp;quot;); 在非 Spring 环境下 API 方式 在非 Spring 环境下使用 SOFARPC 裸 API，设置 ConsumerConfig 的 invokeType 属性即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setInvokeType(\u0026amp;quot;future\u0026amp;quot;); 获取调用结果 使用异步调用的方式，目前提供了两种方式来获取异步调用的结果：\n直接获取结果 用户可以通过以下的方式来直接获取异步调用的结果：\nString result = (String)SofaResponseFuture.getResponse(0, true); 其中第一个参数是获取结果的超时时间，第二个参数表示是否清除线程上下文中的结果。\n获取 JDK 原生 Future 用户可以通过以下的方式来获取 JDK 的原生的 Future 对象，再可以从任意地方去调用这个 Future 对象来获取结果：\nFuture future = SofaResponseFuture.getFuture(true); 其中的第一个参数表示是否清除线程上下文中的结果。\n回调 SOFARPC Bolt 协议的回调方式可以让 SOFARPC 在发起调用后不等待结果，在客户端收到服务端返回的结果后，自动回调用户实现的一个回调接口。\n使用 SOFARPC Bolt 协议的回调方式，首先需要实现一个回调接口，并且在对应的配置中设置回调接口，再将调用方式设置为 callback。\n实现回调接口 SOFARPC 提供了一个回调的接口 com.alipay.sofa.rpc.core.invoke.SofaResponseCallback，用户使用 SOFARPC Bolt 协议的回调方式，首先需要实现这个接口，该接口提供了三个方法：\n onAppResponse：当客户端接收到服务端的正常返回的时候，SOFARPC 会回调这个方法。 onAppException：当客户端接收到服务端的异常响应的时候，SOFARPC 会回调这个方法。 onSofaException：当 SOFARPC 本身出现一些错误，比如路由错误的时候，SOFARPC 会回调这个方法。 设置回调接口 实现回调接口之后，用户需要将实现类设置到对应的服务引用配置中，并且将调用方式设置为 callback。\nSOFARPC 为设置回调接口提供了两种方式，分别为 Callback Class 和 Callback Ref。Callback Class 的方式直接设置回调的类名，SOFARPC 会通过调用回调类的默认构造函数的方式生成回调类的实例。Callback Ref 的方式则为用户直接提供回调类的实例。\nXML 方式 如果通过 XML 的方式引用服务，将 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 type 属性设置为 callback，并且设置 callback-ref 或者 callback-class 属性即可：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleCallback\u0026amp;quot; class=\u0026amp;quot;com.example.demo.SampleCallback\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;callback\u0026amp;quot; callback-ref=\u0026amp;quot;sampleCallback\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 在 XML 的方式下，callback-ref 的值需要是回调类的 Bean 名称。\nAnnotation 方式 如果通过 Annotation 的方式引用服务，设置 @SofaReferenceBinding 注解的 invokeType 属性为 callback，并且设置 callbackClass 或者 callbackRef 属性即可：\n@SofaReference(binding = …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-type/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e296d9344b6aa9f550e6213b97da084b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/invoke-type/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/invoke-type/","summary":"调用方式 SOFARPC 在 Bolt 协议下提供了多种调用方式满足不同的场景。 同步 在同步的调用方式下，客户端发起调用后会等待服务端返回结果再进行后续的操作。这是 SOFARPC 的","tags":null,"title":"Bolt 协议调用方式","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/invoke-type/","wordcount":1619},{"author":null,"categories":null,"content":" 超时控制 使用 Bolt 协议进行通信的时候，SOFARPC 的超时时间默认为 3 秒，用户可以在引用服务的时候去设置超时时间，又分别可以在服务以及方法的维度设置超时时间，SOFARPC 的超时时间的设置的单位都为毫秒。\n服务维度 如果需要在发布服务的时候在服务维度设置超时时间，设置对应的 timeout 参数到对应的值即可。\nXML 方式 如果使用 XML 的方式引用服务，设置 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签下的 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 timeout 属性的值即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 如果使用 Annotation 引用服务，设置 @SofaReferenceBinding 的 timeout 属性的值即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, timeout = 2000)) private SampleService sampleService; Spring 环境 API 方式 如果在 Spring 或者 Spring Boot 的环境下引用服务，设置 BoltBindingParam 的 timeout 属性的值即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setTimeout(2000) 非 Spring 环境下 API 方式 如果在非 Spring 环境下直接使用 SOFARPC 的裸 API 引用服务，设置 ConsumerConfig 的 timeout 属性即可：\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setTimeout(2000); 方法维度 如果想要单独调整一个服务中某一个方法的超时时间，可以通过在方法维度上设置超时时间来实现。\n对于某一个方法来说，优先方法维度的超时时间，如果没有设置，则使用服务维度的超时时间。\nXML 方式 如果使用 XML 的方式引用一个服务，设置对应的 \u0026amp;lt;sofa:method\u0026amp;gt; 标签的 timeout 属性即可：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 目前暂未提供通过 Annotation 的方式来设置方法级别的超时时间。\nSpring 环境 API 方式 如果在 Spring 或者 Spring Boot 的环境下引用服务，设置 RpcBindingMethodInfo 的 timeout 属性的值即可：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); RpcBindingMethodInfo rpcBindingMethodInfo = new RpcBindingMethodInfo(); rpcBindingMethodInfo.setName(\u0026amp;quot;hello\u0026amp;quot;); rpcBindingMethodInfo.setTimeout(2000); List\u0026amp;lt;RpcBindingMethodInfo\u0026amp;gt; rpcBindingMethodInfos = new ArrayList\u0026amp;lt;\u0026amp;gt;(); rpcBindingMethodInfos.add(rpcBindingMethodInfo); boltBindingParam.setMethodInfos(rpcBindingMethodInfos); 非 Spring 环境 API 方式 如果在非 Spring 环境下使用 SOFARPC 的裸 API 引用服务，设置 MethodConfig 的 timeout 属性即可：\nMethodConfig methodConfig = new MethodConfig(); methodConfig.setName(\u0026amp;quot;hello\u0026amp;quot;); methodConfig.setTimeout(2000); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfig); ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setMethods(methodConfigs); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-timeout/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cf14f73dc0c4672a9255ef55b56de419","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt-timeout/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/bolt-timeout/","summary":"超时控制 使用 Bolt 协议进行通信的时候，SOFARPC 的超时时间默认为 3 秒，用户可以在引用服务的时候去设置超时时间，又分别可以在服务以及方法的维度","tags":null,"title":"Bolt 协议超时控制","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/bolt-timeout/","wordcount":584},{"author":null,"categories":null,"content":" As one of the developing directions of cloud native technology, Serverless architecture enables you to further improve resource utilization and focus on service development. With our workshop, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, and quick troubleshooting via log viewer.\nWorkshop procedure Flow diagram Preview Preparation Access to Serverless application service address Login with account and password Git clone this project to local Step 1-1: Publish backend Java application Select Create quickly Select Java Runtime Upload the code package balance-mng.jar The entry method can be automatically recognized Port: 8080 Copy and save the backend service address after creation View the number of computing instances of backend service: 0 Step 1-2: Publish frontend NodeJS application Select create an application Select the buildpack NodeJS Upload the code package stock-mng.zip The entry method can be automatically recognized Select nodejs-0.0.1.1-pre at runtime Port: 3000 Set the environment variable BALANCEMNG_URL as the backend service address Step 2: 0-1 cold boot capability Access frontend service View the changes in the number of the computing instances of backend service Step 3: Log and monitoring View application service logs via Log Shell View usage amount via monitoring Step 4: Configure time trigger Configure timing trigger to call application at fixed time View the triggering results via operation records Step 5: Create versions and control traffic Clone the frontend application and create a new version Upload the code package stock-mng-v2.zip Configure router to visit V1 and V2 at 1:1 ratio View the effect in the browser Step 6: Quick M-n capability for high-concurrency Simulate high concurrency situtation via scripts and access the frontend application service Check how the Serverless application perform quick M-N computing instance changes ","date":-62135596800,"description":"With this guide, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, quick troubleshooting via log viewer, and application startup at fixed time.","dir":"guides/kc-serverless-demo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f355d1b598fed47b730bd74ad25f3683","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-serverless-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/guides/kc-serverless-demo/","summary":"As one of the developing directions of cloud native technology, Serverless architecture enables you to further improve resource utilization and focus on service development. With our workshop, you can experience new features such as quick creation of Serveless applications, automatic second-level 0-1-N scaling based on service requests, and quick troubleshooting via log viewer.\nWorkshop procedure Flow diagram Preview Preparation Access to Serverless application service address Login with account and password Git clone this project to local Step 1-1: Publish backend Java application Select Create quickly Select Java Runtime Upload the code package balance-mng.","tags":null,"title":"Build applications on the cloud based on Serverless","type":"guides","url":"/sofastack.tech/en/guides/kc-serverless-demo/","wordcount":290},{"author":null,"categories":null,"content":" Procedure This guide introduces how to quickly build a microservice based on SOFAStack. It mainly includes the following steps.\n Publish service using SOFABoot and SOFARPC Call service using SOFABoot and SOFARPC View Tracer information reported by SOFATracer via ZipKin View Metrics information via SOFALookout Architecture Tasks 1. Preparation Clone the project demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git Import the project into IDEA or Eclipse. After import, the interface is as follows:\n balance-mng: account management system, providing deduction balance service stock-mng: account system, providing deduction inventory service 2. Introduce dependencies Add the following dependencies into the pom.xml files of balance-mng and stock-mng project modules.\n\u0026amp;lt;!--SOFARPC dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFATracer dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFARegistry dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--runtime dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFALookout dependency--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; For balance-mng project, you need to introduce the dependencies into the pom file of balance-mng-imp module.\nFor stock-mng project, you need to introduce the dependencies into the pom file of stock-mng module.\n3. Add configurations Copy the following configurations into the application.properties file of balance-mng and stock-mng project module.\n# 1、Add Service Registry address com.alipay.sofa.rpc.registry.address=sofa://118.31.43.62:9603 # 2、Add the zipkin address where tracer data is reported com.alipay.sofa.tracer.zipkin.base-url=http://139.224.123.199:9411 # 3、Add the server-side address where the metrics data is reported com.alipay.sofa.lookout.agent-host-address=139.224.123.35 For balance-mng project, you need to add configurations to the application.properties file in balance-mng-bootstrap module.\nFor stock-mng project, you need to add configurations to the application.properties file in stock-mng module.\n4. Modify unique id Since everyone shares a set of service discoveries, to differentiate the services published by different users, it is required to add a unique id to the service.\nKubeCon workshop will prepare a SOFAStack account for each user in the format ofuser0@sofastack.io to user99@sofastack.io. The first half of the account, namely …","date":-62135596800,"description":"This guide introduces how to quickly build a microservice based on SOFAStack. ","dir":"guides/sofastack-quick-start/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"78bfd4806a86dc15ac86eee16fb85c82","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/sofastack-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/guides/sofastack-quick-start/","summary":"Procedure This guide introduces how to quickly build a microservice based on SOFAStack. It mainly includes the following steps.\n Publish service using SOFABoot and SOFARPC Call service using SOFABoot and SOFARPC View Tracer information reported by SOFATracer via ZipKin View Metrics information via SOFALookout Architecture Tasks 1. Preparation Clone the project demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git Import the project into IDEA or Eclipse. After import, the interface is as follows:","tags":null,"title":"Build microservices with SOFAStack","type":"guides","url":"/sofastack.tech/en/guides/sofastack-quick-start/","wordcount":586},{"author":null,"categories":null,"content":" SOFARPC provides a variety of calling types under the Bolt protocol to meet different scenarios.\nSynchronous In the synchronous calling type, after the client initiates a call, it will wait for the server to return the result and then perform subsequent operations. This is the default calling type of SOFARPC.\nAsynchronous In the asynchronous calling type, after the client initiates a call, it will not wait for the result from the server but continue to execute the subsequent business logic. The result returned by the server will be cached by SOFARPC. When the client needs the result, it can call the API to get the result. To set a service to be asynchronous, you can configure the type attribute in the corresponding usage mode:\nXML In the XML mode, set the type attribute of the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag to future:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;future\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation In Annotation mode, set the invokeType attribute of @SofaReferenceBinding to future:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, invokeType = \u0026amp;quot;future\u0026amp;quot;)) private SampleService sampleService; API in Spring environment When using the API in Spring environment, you just need to set the type attribute of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setType(\u0026amp;quot;future\u0026amp;quot;); API in non-Spring environment When using the bare API of SOFARPC in a non-Spring environment, you just need to set the invokeType attribute of ConsumerConfig:\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setInvokeType(\u0026amp;quot;future\u0026amp;quot;); Get the calling result Currently, there are two ways to get the result of an asynchronous call:\nGet result directly You can directly get the result of an asynchronous call in the following way:\nString result = (String)SofaResponseFuture.getResponse(0, true); The first parameter is the timeout period for getting the result, and the second parameter indicates whether to clear the result in the thread context.\nGet JDK native Future You can get the JDK native Future object in the following way, and then call the Future object from anywhere to get the result:\nFuture future = SofaResponseFuture.getFuture(true); The first parameter indicates whether to clear the result in the thread context.\nCallback By using the callback type of the SOFARPC Bolt protocol, SOFARPC doesn\u0026amp;rsquo;t need to wait for the result after initiating a call. After the client receives the result returned from the server, it can automatically call back a callback interface implemented by the user.\nTo use the callback type of the SOFARPC Bolt protocol, you first need to …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-type/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e296d9344b6aa9f550e6213b97da084b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/invoke-type/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/invoke-type/","summary":"SOFARPC provides a variety of calling types under the Bolt protocol to meet different scenarios.\nSynchronous In the synchronous calling type, after the client initiates a call, it will wait for the server to return the result and then perform subsequent operations. This is the default calling type of SOFARPC.\nAsynchronous In the asynchronous calling type, after the client initiates a call, it will not wait for the result from the server but continue to execute the subsequent business logic.","tags":null,"title":"Calling type","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/invoke-type/","wordcount":908},{"author":null,"categories":null,"content":" Client built-in extension metrics The extension modules currently in effect by default are lookout-ext-jvm and lookout-ext-os (from v1.5.0).\nJVM thread metric name metric tags specification jvm.threads.totalStarted \u0026amp;mdash; jvm.threads.active \u0026amp;mdash; jvm.threads.peak \u0026amp;mdash; jvm.threads.daemon \u0026amp;mdash; JVM class loading metric name metric tags specification jvm.classes.unloaded \u0026amp;mdash; jvm.classes.loaded \u0026amp;mdash; jvm.classes.total \u0026amp;mdash; JVM memory metric name metric tags specification jvm.memory.heap.init \u0026amp;mdash; jvm.memory.heap.used \u0026amp;mdash; jvm.memory.heap.max \u0026amp;mdash; jvm.memory.heap.committed \u0026amp;mdash; JVM garbage recycling metric name metric tags specification jvm.gc.young.time \u0026amp;mdash; jvm.gc.young.count \u0026amp;mdash; jvm.gc.old.time \u0026amp;mdash; jvm.gc.old.count \u0026amp;mdash; Machine file system information metric name metric tags specification instance.file.system.free.space root（the available filesystem roots） \u0026amp;mdash; instance.file.system.total.space root \u0026amp;mdash; instance.file.system.usabe.space root \u0026amp;mdash; Machine information metric name metric tags specification instance.mem.free \u0026amp;mdash; instance.mem.total \u0026amp;mdash; instance.processors \u0026amp;mdash; instance.uptime \u0026amp;mdash; instance.systemload.average \u0026amp;mdash; Linux operating system information (enabled by default after version 1.5.0) metric name metric tags specification os.systemload.average.1min \u0026amp;mdash; os.systemload.average.5min \u0026amp;mdash; os.systemload.average.15min \u0026amp;mdash; os.cpu.idle \u0026amp;mdash; os.cpu.iowait \u0026amp;mdash; os.cpu.irq \u0026amp;mdash; os.cpu.nice \u0026amp;mdash; os.cpu.softirq \u0026amp;mdash; os.cpu.system \u0026amp;mdash; os.cpu.user \u0026amp;mdash; os.disk.usage.percent.used device,root,type \u0026amp;mdash; os.disk.usage.total.bytes device,root,type \u0026amp;mdash; os.disk.usage.used.bytes device,root,type \u0026amp;mdash; os.net.stats.in.bytes intfc \u0026amp;mdash; os.net.stats.in.compressed intfc \u0026amp;mdash; os.net.stats.in.dropped intfc \u0026amp;mdash; os.net.stats.in.errs intfc \u0026amp;mdash; os.net.stats.in.fifo.errs intfc \u0026amp;mdash; os.net.stats.in.frame.errs intfc \u0026amp;mdash; os.net.stats.in.multicast intfc \u0026amp;mdash; os.net.stats.in.packets intfc \u0026amp;mdash; os.net.stats.out.bytes intfc \u0026amp;mdash; os.net.stats.out.carrier.errs intfc \u0026amp;mdash; os.net.stats.out.collisions intfc \u0026amp;mdash; os.net.stats.out.compressed intfc \u0026amp;mdash; os.net.stats.out.dropped intfc \u0026amp;mdash; os.net.stats.out.errs intfc \u0026amp;mdash; os.net.stats.out.fifo.errs intfc \u0026amp;mdash; os.net.stats.out.packets intfc \u0026amp;mdash; os.memory.stats.buffers.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.cached.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.free.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.total.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-ext-metrics/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c8a4fb3d904e359e99db9d4e81e60812","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","summary":"Client built-in extension metrics The extension modules currently in effect by default are lookout-ext-jvm and lookout-ext-os (from v1.5.0).\nJVM thread metric name metric tags specification jvm.threads.totalStarted \u0026mdash; jvm.threads.active \u0026mdash; jvm.threads.peak \u0026mdash; jvm.threads.daemon \u0026mdash; JVM class loading metric name metric tags specification jvm.classes.unloaded \u0026mdash; jvm.","tags":null,"title":"Client built-in extension metrics","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/","wordcount":224},{"author":null,"categories":null,"content":"The client module is a complex module which contains cluster, router, address holder，connection holder, and load balancer, and interacts with proxy, registry center and other modules.\nSee the following flow chart:\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/client-invoke-flow/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"310d99d64b808a3b526563e92c699952","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","summary":"The client module is a complex module which contains cluster, router, address holder，connection holder, and load balancer, and interacts with proxy, registry center and other modules.\nSee the following flow chart:","tags":null,"title":"Client call flow","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/","wordcount":31},{"author":null,"categories":null,"content":" Client configuration example lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026amp;quot;127.0.0.1\u0026amp;quot;); Description of server configuration item Configuration item Corresponding SpringBoot configuration item Default value Description lookout.enable com.alipay.sofa.lookout.enable true Function switch, it defaults to true. If you change it to false (empty objects and empty methods), then all metrics comsume almost no memory and computing resource lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 Maximum number limit of metrics, over which will be automatically ignored lookout.prometheus.exporter.server.port com.alipay.sofa.lookout.prometheus-exporter-server-port 9494 The port got by Prometheus Lookout.exporter.enable com.alipay.sofa.lookout.exporter-enable false Whether or not to enable services that support passive collection Lookout.agent.host.address com.alipay.sofa.lookout.agent-host-address - Proactively report the annotation address of the Agent server. Multiple addresses are separated by commas Description of client log configuration Configuration item of system property Corresponding SpringBoot configuration item Default Value Description -Dlogging.level.com.alipay.lookout=? logging.level.com.alipay.lookout warn The log level of Lookout client. Debug to see the details of the report data -Dlogging.path=? logging.path Directory of the current user Modify SpringBoot V1 log directory, including \u0026amp;ldquo;lookout/\u0026amp;rdquo; log subdirectory Custom client configuration (suitable for SpringBoot technology stack mode) Use configuration custom extensions: MetricConfigCustomizerConfig\n@Configuration public class MetricConfigCustomizerConfig { @Bean public MetricConfigCustomizer metricConfigCustomizer() { return new MetricConfigCustomizer() { @Override public void customize(MetricConfig metricConfig) { metricConfig.addProperty(\u0026amp;quot;testaa\u0026amp;quot;, \u0026amp;quot;testbb\u0026amp;quot;); } }; } } ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-configuration/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5fd84950d4d565d3fb20781337792bf1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/client-configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/client-configuration/","summary":"Client configuration example lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026quot;127.0.0.1\u0026quot;); Description of server configuration item Configuration item Corresponding SpringBoot configuration item Default value Description lookout.enable com.alipay.sofa.lookout.enable true Function switch, it defaults to true. If you change it to false (empty objects and empty methods), then all metrics comsume almost no memory and computing resource lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 Maximum number limit of metrics, over which will be automatically ignored lookout.","tags":null,"title":"Client configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/client-configuration/","wordcount":192},{"author":null,"categories":null,"content":" 1. Create a Maven project After deploying the servers, we can create a new Maven project to use services provided by SOFARegistry. Create a new Maven project, and then import the following dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. Publish data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create a publisher registry. String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // Register the registry with the client and publish data. registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); Perform the following steps to publish data by using SOFARegistry:\n Create a client instance. Create a publisher registry. Register the registry with the client and publish data. 2.1 Create a client instance The key to creating a client instance is to create a RegistryClientConfig object. When creating a RegistryClientConfig object, you need to specify the RegistryEndpoint and RegistryEndpointPort.\n RegistryEndpoint: the endpoint of any session node of SOFARegistry RegistryEndpointPort: the session.server.httpServerPort port number configured for a session node 2.2 Create a publisher registry To create a publisher registry, you only need to create a PublisherRegistration object and specify the dataId, which is the unique identifier of the publisher service.\n2.3 Publish data You can call the register method of the RegistryClient to publish data. This method requires two parameters: the first is a publisher registry with the specified dataId of a service, and the second is a string type data value.\n3. Subscribe to the data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create SubscriberDataObserver. SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // Create a subscriber registry and specify the subscription level. ScopeEnum covers three subscription levels: zone, dataCenter, and global. String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setScopeEnum(ScopeEnum.global); // Register the registry with …","date":-62135596800,"description":"","dir":"projects/sofa-registry/client-quick-start/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"66e300d44b2f2a903d976bf83eb7c16e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/client-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/client-quick-start/","summary":"1. Create a Maven project After deploying the servers, we can create a new Maven project to use services provided by SOFARegistry. Create a new Maven project, and then import the following dependency:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. Publish data // Create a client instance. RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // Create a publisher registry. String dataId = \u0026quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // Register the registry with the client and publish data.","tags":null,"title":"Client usage","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/client-quick-start/","wordcount":558},{"author":null,"categories":null,"content":" Project address\n Introduction During merged deployment, Biz packages can communicate with each other by releasing and referencing JVM services apart from using the RPC framework. This sample project is intended to demonstrate how two Biz packages communicate by JVM services.\nWithin the biz-jvm-invocation-sample project, there are three sub-projects whose functions are as follows: + facade: A common Java module that defines the SampleJvmService interface.\npackage me.qlong.tech.service; public interface SampleJvmService { String service(); } app-one: A SOFABoot Web application that defines a simple rest request and use the @SofaReference annotation to reference the SampleJvmService. When a page request is triggered, an attempt is made to call the JVM service. The key code is: package me.qlong.controller; import com.alipay.sofa.runtime.api.annotation.SofaReference; import me.qlong.tech.service.SampleJvmService; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class HelloController { @SofaReference private SampleJvmService sampleJvmService; @RequestMapping(\u0026amp;quot;/hello\u0026amp;quot;) public String hello() { return sampleJvmService.service(); } } app-two: A non-web application in SOFABoot that uses the @SofaService annotation to publish the SampleJvmService. ```java package me.qlong.tech.service.impl; import com.alipay.sofa.runtime.api.annotation.SofaService; import me.qlong.tech.service.SampleJvmService; import org.springframework.stereotype.Component;\n@SofaService @Component public class AppTwoSampleService implements SampleJvmService{ public String service() { return \u0026amp;ldquo;App Two\u0026amp;rdquo;; } }\n ## Dependency To communicate between Biz packages through JVM services, you must add dependencies on the SOFARuntime package and the corresponding Ark Plugin as follows: ```xml \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; For detailed information about publishing and referencing JVM services, see the SOFABoot Documentation. You are advised to use annotations in Jarslink2.0.\nDemo cd biz-jvm-invocation-sample/facade \u0026amp;amp;\u0026amp;amp; mvn clean install Execute the mvn clean install command in the facade root directory, and install the facade package in the local Maven repository so that you can add a facade dependency in app-one and app-two: \u0026amp;lt;!--service facade--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;me.qlong.tech\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;facade\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; cd biz-jvm-invocation-sample/app-one \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-one root directory and …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"59778c5223dc6267bd537be6c79b658a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","summary":"Project address\n Introduction During merged deployment, Biz packages can communicate with each other by releasing and referencing JVM services apart from using the RPC framework. This sample project is intended to demonstrate how two Biz packages communicate by JVM services.\nWithin the biz-jvm-invocation-sample project, there are three sub-projects whose functions are as follows: + facade: A common Java module that defines the SampleJvmService interface.\npackage me.qlong.tech.service; public interface SampleJvmService { String service(); } app-one: A SOFABoot Web application that defines a simple rest request and use the @SofaReference annotation to reference the SampleJvmService.","tags":null,"title":"Communicate across applications","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/","wordcount":527},{"author":null,"categories":null,"content":"SOFARPC supports different communication protocols and currently supports Bolt, RESTful and Dubbo. For details, please refer to the corresponding document of each protocol: * Bolt Protocol * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool * RESTful * Basic usage * Custom filter * Integrate Swagger * Dubbo * Basic usage * H2C * Basic usage\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/protocol/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"18f51cb12f7a0384a71ab22349292a08","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/protocol/","summary":"SOFARPC supports different communication protocols and currently supports Bolt, RESTful and Dubbo. For details, please refer to the corresponding document of each protocol: * Bolt Protocol * Basic usage * Calling type * Timeout control * Generic call * Serialization protocol * Custom thread pool * RESTful * Basic usage * Custom filter * Integrate Swagger * Dubbo * Basic usage * H2C * Basic usage","tags":null,"title":"Communication protocols","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/protocol/","wordcount":66},{"author":null,"categories":null,"content":" How to compile Install JDK7 and above, and Maven 3.2.5 and above.\n Directly download the code and then execute the following command:\ncd sofa-jarslink mvn clean install Note: you cannot compile the code under a sub-directory (i.e., sub-module). Since there are many modules, the configuration is restricted to the root directory only to avoid repetitive configuration of some packaging plugins such as the formatting plugin and License plugin. There will be an error message if you execute the packaging command in a sub-module.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-compile/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"23c8cae6050d7a772f45d3ff2b4ce889","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","summary":"How to compile Install JDK7 and above, and Maven 3.2.5 and above.\n Directly download the code and then execute the following command:\ncd sofa-jarslink mvn clean install Note: you cannot compile the code under a sub-directory (i.e., sub-module). Since there are many modules, the configuration is restricted to the root directory only to avoid repetitive configuration of some packaging plugins such as the formatting plugin and License plugin.","tags":null,"title":"Compile Jarslink project","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/","wordcount":83},{"author":null,"categories":null,"content":" Install JDK7 or later and Maven 3.2.5 or later.\n Download the codes directly and execute the following commands:\ncd sofa-rpc mvn clean install Note: You can not build under a subdirectory (namely the submodule). Because there are too many SOFARPC modules, if every submodule needs to be installed and deployed, there will be much useless records in the repository. This issue is considered in the process of designing the SOFARPC project structure. The current structure saves you the trouble of installing and deploying all submodules, and you just have to install and deploy one module, namely the sofa-rpc-all (all) module.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/how-to-build/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"52ad3debb35be8743c97bb4b6b77f22b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/how-to-build/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/how-to-build/","summary":"Install JDK7 or later and Maven 3.2.5 or later.\n Download the codes directly and execute the following commands:\ncd sofa-rpc mvn clean install Note: You can not build under a subdirectory (namely the submodule). Because there are too many SOFARPC modules, if every submodule needs to be installed and deployed, there will be much useless records in the repository. This issue is considered in the process of designing the SOFARPC project structure.","tags":null,"title":"Compile SOFARPC project","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/how-to-build/","wordcount":100},{"author":null,"categories":null,"content":"Provide all the parameters that can be configured. * Service publishing and reference configuration * Warm-up forwarding configuration * Fault tolerance configuration\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b1a8a8c426beab292165716f1dff1ae4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration/","summary":"Provide all the parameters that can be configured. * Service publishing and reference configuration * Warm-up forwarding configuration * Fault tolerance configuration","tags":null,"title":"Configuration parameters","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration/","wordcount":22},{"author":null,"categories":null,"content":"To use Consul as service registry center, you need to add this dependency\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.ecwid.consul\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;consul-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; and need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 The value after consul: is the connection address of the consul. If you need to set some other parameters, you can also configure as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;amp;b=2 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-consul/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e6b0aa843ea0ad401c3184f6ce87649b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-consul/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-consul/","summary":"To use Consul as service registry center, you need to add this dependency\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.ecwid.consul\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;consul-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.4.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; and need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 The value after consul: is the connection address of the consul. If you need to set some other parameters, you can also configure as follows:\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;b=2 ","tags":null,"title":"Consul","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-consul/","wordcount":54},{"author":null,"categories":null,"content":" You can visit Development Route first to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n Refer to the Git official books for the Git tool usage. The first few chapters will help you get a quick start. Read Git collaboration process through GitHub Code Contribution Process Submitting an issue Whether you want to fix a bug of SOFAArk or add a new feature of SOFAArk, you have to submit an issue to describe your demand before you submit the code on GitHub address in SOFAArk. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The maintenance personnel of SOFAArk will discuss about the bug or new function you submitted, to determine if the modification is necessary, or if there is any room for improvement or any better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Getting the source code To modify or add a function, click the fork button in the upper left corner to copy a SOFAArk trunk code to your code repository, after submitting an issue.\nPulling a branch Perform all the SOFAArk modifications on the branch, and submit a pull request after the modifications, which will be merged to the trunk by the project maintenance personnel after Code Review.\nTherefore, after getting the introduction to source code steps, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/{your account}/sofa-ark.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\ngit branch -a If you want to switch back to the trunk, execute the following command:\ngit checkout -b master If you want to switch back to the branch, execute the following command:\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally. After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFAArk uses the Maven plug-in to keep the code style consistent. Before submitting the code, execute the following commands locally: mvn clean compile Supplement unit test code. New modifications should have passed existing unit tests. You should provide the new unit test to prove that the previous code has bugs and the new code has fixed such bugs. Execute the following command to run all tests:\nmvn clean test Other do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original style of the code you are editing, especially the spaces and line feeds in the code. Delete useless annotations. Annotate the places where the logic and functionality …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-contribution/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dbf77f98884a71c5c7a3fbb4dd189cfe","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","summary":"You can visit Development Route first to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n Refer to the Git official books for the Git tool usage. The first few chapters will help you get a quick start. Read Git collaboration process through GitHub Code Contribution Process Submitting an issue Whether you want to fix a bug of SOFAArk or add a new feature of SOFAArk, you have to submit an issue to describe your demand before you submit the code on GitHub address in SOFAArk.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/","wordcount":795},{"author":null,"categories":null,"content":" You can go into the development route to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n For the use of git tools, refer to official books on git and get familiarized by reading the first few chapters. For the git collaboration process, refer to the article named Git Collaboration Process. GitHub Code Contribution Process Submitting an issue No Matter whether you are fixing a Jarslink bug or adding a Jarslink feature, submit an issue on the Jarslink GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The Jarslink maintenance personnel will discuss the bug or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Getting the source code To modify or add a feature, click the fork button in the upper left corner to copy Jarslink trunk code to your code repository, after submitting an issue.\nPulling a branch Perform all the Jarslink modifications on the branch, and submit a pull request after the modifications, which will be merged into the trunk by the project maintenance personnel after the code review.\nTherefore, after getting the introduction to source code steps, you need to:\n Download the code locally. You may select the git/https mode in this step.\ngit clone https://github.com/your account name/sofa-jarslink.git Pull a branch to prepare for code modification.\ngit branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\n git branch -a If you want to switch back to the trunk, execute the following command:\n git checkout -b master If you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally. After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. Jarslink uses the Maven plugin to keep the code style consistent. Before submitting the code, be sure to execute the following commands locally\nmvn clean compile Supplement unit test code. New modifications should have passed existing unit tests. You should provide the new unit test to prove that the previous code has bugs and the new code has fixed such bugs. Execute the following command to run all tests:\n mvn clean test You can also use the IDE to help execute a command.\nOther do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-contribution/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d4c1185c6a691679f6dc9dba033550ce","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","summary":"You can go into the development route to learn more about development tasks and future planning.\n Preparations Before contributing any code, we need to know how to use the Git tool and the GitHub website.\n For the use of git tools, refer to official books on git and get familiarized by reading the first few chapters. For the git collaboration process, refer to the article named Git Collaboration Process.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/","wordcount":827},{"author":null,"categories":null,"content":" Before you read this document, you are suggested to read the SOFARPC development roadmap to learn about development tasks and future plans.\n Preparations Before you contribute code, you need to learn the basic use of Git tool and GitHub website.\n For how to use the Git tool, see Git official documenation and pay attention to the first few chapters. For Git collaboration process, see Git collaboration process. GitHub code contribution process Submit an issue No matter to fix SOFARPC bugs or add SOFARPC features, before submitting the codes, you must submit an issue on SOFARPC\u0026amp;rsquo;s GitHub to describe the bugs to be fixed and the functions you want to add.\nThere are several benefits of doing this:\n Avoid the conflict with other developers or their plans for this project, thus eliminating repetitive work. SOFARPC operations staff discuss your bugs or new features to determine if the changes are necessary and whether there is space for improvement or a better approach. Reduce communication cost between you and the SOFARPC operations staff, thus reducing the cases that pull request is rejected. Get source codes To modify or add features, after you submit the issue, you can click Fork in the upper left corner to copy the SOFARPC trunk code to your code repository.\nPull branches All SOFARPC modifications are made on the branch. After modification, submit the pull request. After the code review, the project operations staff merge the branches to the trunk.\nTherefore, you must complete the following steps after getting the source codes:\n Download the codes locally through Git or HTTPs.\n git clone https://github.com/your account name/sofa-rpc.git Pull branches for code modifications.\n \t git branch add_xxx_feature \nAfter executing the above command, your code repository switches to the corresponding branch. Execute the following command to see your current branch:\n\t git branch -a \nIf you want to switch back to the trunk, execute the following command:\n git checkout -b master \nIf you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; \nModify and submit codes locally Once the branch is pulled, you can modify the code.\nAttentions for modifying codes Keep a consistent code style.\nSOFARPC keeps the code format consistent through the Maven plugin. You must execute the following command locally before committing the code: mvn clean compile Supplemental unit test code. New modifications should have passed the existing unit tests. Provide new unit tests to prove that the previous code has bugs, and the new code has fixed these bugs.\nYou can run all tests with the following command:\nmvn clean test You can also use IDE to assist the test running.\n Other attentions Keep the original code style, especially the spacing and alignment. Delete the useless comments directly. Add comments for the logics and functions that cannot be easily understood. Update documentation timely. After modification, …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/contributing/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"448a7b9a949bd2d9e2e71ac6c237f9df","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/contributing/","summary":"Before you read this document, you are suggested to read the SOFARPC development roadmap to learn about development tasks and future plans.\n Preparations Before you contribute code, you need to learn the basic use of Git tool and GitHub website.\n For how to use the Git tool, see Git official documenation and pay attention to the first few chapters. For Git collaboration process, see Git collaboration process.","tags":null,"title":"Contribution","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/contributing/","wordcount":751},{"author":null,"categories":null,"content":"SOFARPC uses some third-party open-source components which include but not limited to:\n Major dependencies\n Netty under Apache License 2.0 SLF4j under MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 Extended dependencies\n protobuf under New BSD License Snappy under New BSD License dubbo under Apache License 2.0 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b6c87388d5c1462f13d92012639a08b2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/notice/","summary":"SOFARPC uses some third-party open-source components which include but not limited to:\n Major dependencies\n Netty under Apache License 2.0 SLF4j under MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 Extended dependencies\n protobuf under New BSD License Snappy under New BSD License dubbo under Apache License 2.0 ","tags":null,"title":"Copyright","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/notice/","wordcount":62},{"author":null,"categories":null,"content":" Copyright statement of dependent components SOFADashboard uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFABolt under Apache License 2.0 SOFABolt under Apache License 2.0 Curator under Apache License 2.0 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a9ebe38d245302f94ab7bfa793329926","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/notice/","summary":" Copyright statement of dependent components SOFADashboard uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFABolt under Apache License 2.0 SOFABolt under Apache License 2.0 Curator under Apache License 2.0 ","tags":null,"title":"Copyright statement","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/notice/","wordcount":47},{"author":null,"categories":null,"content":" Copyright statement of dependent components SOFARegistry uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1\n SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 If you find anything we have missed, please let us know.\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/notice/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c40263ffd56a2f1292756c9fafea55e2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/notice/","summary":"Copyright statement of dependent components SOFARegistry uses some third-party open-source components, including but not limited to:\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1\n SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 If you find anything we have missed, please let us know.","tags":null,"title":"Copyright statement","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/notice/","wordcount":68},{"author":null,"categories":null,"content":" 本文档主要介绍一个基于 jraft 的分布式计数器的例子。\n场景 在多个节点（机器）组成的一个 raft group 中保存一个分布式计数器，该计数器可以递增和获取，并且在所有节点之间保持一致，任何少数节点的挂掉都不会影响对外提供的两个服务：\n incrmentAndGet(delta) 递增 delta 数值并返回递增后的值。 get() 获取最新的值 RPC 请求 jraft 底层使用 bolt 作为通讯框架，定义两个请求\n IncrementAndGetRequest，用于递增 public class IncrementAndGetRequest implements Serializable { private static final long serialVersionUID = -5623664785560971849L; private long delta; public long getDelta() { return this.delta; } public void setDelta(long delta) { this.delta = delta; } } GetValueRequest，用于获取最新值： public class GetValueRequest implements Serializable { private static final long serialVersionUID = 9218253805003988802L; public GetValueRequest() { super(); } } 应答结果 ValueResponse，包括：\n success　是否成功 value 成功情况下返回的最新值 errorMsg 失败情况下的错误信息 redirect　发生了重新选举，需要跳转的新的leader节点。 public class ValueResponse implements Serializable { private static final long serialVersionUID = -4220017686727146773L; private long value; private boolean success; /** * redirect peer id */ private String redirect; private String errorMsg; public String getErrorMsg() { return this.errorMsg; } public void setErrorMsg(String errorMsg) { this.errorMsg = errorMsg; } ...... } IncrementAndGetRequest 用于 Leader 服务端接收 IncrementAndAddClosure 请求后的回调处理： public class IncrementAndAddClosure implements Closure { private CounterServer counterServer; private IncrementAndGetRequest request; private ValueResponse response; private Closure done; // 网络应答callback public IncrementAndAddClosure(CounterServer counterServer, IncrementAndGetRequest request, ValueResponse response, Closure done) { super(); this.counterServer = counterServer; this.request = request; this.response = response; this.done = done; } @Override public void run(Status status) { // 返回应答给客户端 if (this.done != null) { done.run(status); } } public IncrementAndGetRequest getRequest() { return this.request; } public void setRequest(IncrementAndGetRequest request) { this.request = request; } public ValueResponse getResponse() { return this.response; } } 服务端 状态机 CounterStateMachine 首先持有一个初始值：\npublic class CounterStateMachine extends StateMachineAdapter { /** * counter value */ private AtomicLong value = new AtomicLong(0); 实现核心的 onApply(iterator) 方法，应用用户提交的请求到状态机：\n@Override public void onApply(Iterator iter) { // 遍历日志 while (iter.hasNext()) { long delta = 0; IncrementAndAddClosure closure = null; // done 回调不为null，必须在应用日志后调用，如果不为 null，说明当前是leader。 if (iter.done() != null) { // 当前是leader，可以直接从 IncrementAndAddClosure 中获取 delta，避免反序列化 closure = (IncrementAndAddClosure) iter.done(); delta = closure.getRequest().getDelta(); } else { // 其他节点应用此日志，需要反序列化 IncrementAndGetRequest，获取 delta ByteBuffer data = iter.getData(); try { IncrementAndGetRequest request = Codecs.getSerializer(Codecs.Hessian2).decode(data.array(), IncrementAndGetRequest.class.getName()); delta = request.getDelta(); } catch (CodecException e) { LOG.error(\u0026amp;quot;Fail to decode IncrementAndGetRequest\u0026amp;quot;, e); } } long prev = this.value.get(); // 更新状态机 long …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/counter-example/","fuzzywordcount":2500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f9c54b9f7883ccb1d7c259b7101f4674","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/counter-example/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-jraft/counter-example/","summary":"本文档主要介绍一个基于 jraft 的分布式计数器的例子。 场景 在多个节点（机器）组成的一个 raft group 中保存一个分布式计数器，该计数器可以递增和获取，并且在所有","tags":null,"title":"Counter 例子详解","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/counter-example/","wordcount":2404},{"author":null,"categories":null,"content":" Project address\n Introduction Jarslink 2.0 is available for both Spring Boot and SOFABoot; we just need to add the specified dependencies. To be convenient, it is recommended to use Jarslink 2.0 in the form of SOFABoot projects. This sample project is intended to demonstrate how to quickly reform a Spring Boot project into a SOFABoot project.\nReform After creating a Spring Boot project in the official Spring Boot website, we only need to introduce the SOFABoot dependencies. First, modify the configuration file pom.xml of the Maven project.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace as\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.5.0-SNAPSHOT\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Note: Currently Jarslink 2.0.0 is still at its snapshot version, and the SOFABoot 2.5.0 that it depends on will be released in the near future, so for the moment, the SOFABoot 2.5.0-SNAPSHOT version has to be introduced as the dependency. The pull of the SNAPSHOT package requires special configuration, for which you can refer to FAQ: How do I configure for pulling a SNAPSHOT dependency package?\nThen, add a Spring Boot or SOFABoot official Starter, such as:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;!-- Jarslink2.0 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-jarslink-ark-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0-SNAPSHOT\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- Web --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; To package the application into an Ark package or Biz package, we need to configure the sofa-Ark-maven-plugin packaging plugin in the main pom.xml file, and delete the native packaging plugin the Spring Boot configuration.\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Finally, add a parameter that SOFABoot must use under the application.properties file for the project, including spring.application.name (used to mark the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"46cb9153d039f01a375a569c2a9a5535","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","summary":"Project address\n Introduction Jarslink 2.0 is available for both Spring Boot and SOFABoot; we just need to add the specified dependencies. To be convenient, it is recommended to use Jarslink 2.0 in the form of SOFABoot projects. This sample project is intended to demonstrate how to quickly reform a Spring Boot project into a SOFABoot project.\nReform After creating a Spring Boot project in the official Spring Boot website, we only need to introduce the SOFABoot dependencies.","tags":null,"title":"Create a SOFABoot application","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/","wordcount":419},{"author":null,"categories":null,"content":" SOFARPC provides a good extensibility mechanism, which provide SPI capabilities for each module. SOFARPC uses multiple filters to intercept requests and responses. These filters can be customized and extended by users. The execution order of custom filters is after the built-in filters. The procedure is as follows:\nBolt filter 1 Create a new custom filter.\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 2 The custom filter will be added into the interceptor chain. There are three specific ways to do this step.\n Method 1: In API. In this way, the custom filter can take effect in the specified provider or consumer. // Service provider providerConfig.setFilterRef(Arrays.asList(new CustomFilter())); // Service caller consumerConfig.setFilterRef(Arrays.asList(new CustomFilter())); Method 2: Add @Extension annotation + configuration extension file to the class. @Extension(\u0026amp;quot;customer\u0026amp;quot;) public class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } Create a new extension file META-INF/services/sofa-rpc/com.alipay.sofa.rpc.filter.Filter with the following content:\ncustomer=com.alipay.sofa.rpc.custom.CustomFilter Code injection.\n// Service provider providerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); // Service caller consumerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); Method 3: Add @Extension annotation + @AutoActive annotation + configuration extension file to the class. In this way, the code injection step in method 2 is replaced with the @AutoActive annotation. The custom filter can take effect in all providers or consumers. The providerSide parameter indicates whether it takes effect on the server, and the consumerSide parameter indicates whether it takes effect on the client. @Extension(\u0026amp;quot;customer\u0026amp;quot;) @AutoActive(providerSide = true, consumerSide = true) public class customerFilter extends Filter { // ... } ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-filter/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"30ff5937b52a7c2dd8028e878979a33d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-filter/","summary":"SOFARPC provides a good extensibility mechanism, which provide SPI capabilities for each module. SOFARPC uses multiple filters to intercept requests and responses. These filters can be customized and extended by users. The execution order of custom filters is after the built-in filters. The procedure is as follows:\nBolt filter 1 Create a new custom filter.\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.","tags":null,"title":"Custom filter","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-filter/","wordcount":285},{"author":null,"categories":null,"content":"The route service address in SOFARPC is abstracted into a processing chain, and is processed by each router. Like filter, SOFARPC provides the same extensibility for router.\n@Extension(value = \u0026amp;quot;customerRouter\u0026amp;quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026amp;lt;ProviderInfo\u0026amp;gt; route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) { return providerInfos; } Create a extension file META-INF/services/sofa-rpc/com.alipay.sofa.rpc.client.Router with the following content:\ncustomerRouter=com.alipay.sofa.rpc.custom.CustomRouter This file customized a CustomerRouter, which takes effect in all consumers. The parameter ConsumerBootstrap in init method is a wrapper class of the referenced service, and can get objects such as ConsumerConfig, proxy class, and service address pool. needToLoad indicates whether the Router is valid, and the route method is the method for filtering addresses.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-router/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"236e8d4bda3e856267a3575853aa900c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-router/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-router/","summary":"The route service address in SOFARPC is abstracted into a processing chain, and is processed by each router. Like filter, SOFARPC provides the same extensibility for router.\n@Extension(value = \u0026quot;customerRouter\u0026quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026lt;ProviderInfo\u0026gt; route(SofaRequest request, List\u0026lt;ProviderInfo\u0026gt; providerInfos) { return providerInfos; } Create a extension file META-INF/services/sofa-rpc/com.","tags":null,"title":"Custom router","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-router/","wordcount":131},{"author":null,"categories":null,"content":" SOFARPC supports custom business thread pools. A separate business thread pool can be set up for the specified service, isolated from SOFARPC\u0026amp;rsquo;s global business thread pool. Multiple services can share a single thread pool.\nSOFARPC requires that the type of custom thread pool must be com.alipay.sofa.rpc.server.UserThreadPool.\nUse XML If you publish the service using XML, you can first set the bean of the thread pool whose class is com.alipay.sofa.rpc.server.UserThreadPool, and then set the bean in the thread-pool-ref attribute of \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag.\n\u0026amp;lt;bean id=\u0026amp;quot;helloService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Customize a thread pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;customExecutor\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.server.UserThreadPool\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;corePoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;maximumPoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;queueSize\u0026amp;quot; value=\u0026amp;quot;0\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloService\u0026amp;quot; interface=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;!-- Set the thread pool to a Service --\u0026amp;gt; \u0026amp;lt;sofa:global-attrs thread-pool-ref=\u0026amp;quot;customExecutor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Use Annotation If you publish the service using Annotation, you can set the bean of the custom thread pool by setting the userThreadPool attribute of @SofaServiceBinding:\n@SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, userThreadPool = \u0026amp;quot;customThreadPool\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } Use API in Spring environment If you publish a service using the API in Spring environment, you can configure a custom thread pool by calling the setUserThreadPool method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setUserThreadPool(new UserThreadPool()); Use API in non-Spring environment If you publish service using the API in non-Spring environment, you can set a custom thread pool as follows:\nUserThreadPool threadPool = new UserThreadPool(); threadPool.setCorePoolSize(10); threadPool.setMaximumPoolSize(100); threadPool.setKeepAliveTime(200); threadPool.setPrestartAllCoreThreads(false); threadPool.setAllowCoreThreadTimeOut(false); threadPool.setQueueSize(200); UserThreadPoolManager.registerUserThread(ConfigUniqueNameGenerator.getUniqueName(providerConfig), threadPool); As above, a custom thread pool is set up for the HelloService service.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-thread-pool/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4d582a7894b2381248522f3a1fc400c9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","summary":"SOFARPC supports custom business thread pools. A separate business thread pool can be set up for the specified service, isolated from SOFARPC\u0026rsquo;s global business thread pool. Multiple services can share a single thread pool.\nSOFARPC requires that the type of custom thread pool must be com.alipay.sofa.rpc.server.UserThreadPool.\nUse XML If you publish the service using XML, you can first set the bean of the thread pool whose class is com.alipay.sofa.rpc.server.UserThreadPool, and then set the bean in the thread-pool-ref attribute of \u0026lt;sofa:global-attrs\u0026gt; tag.","tags":null,"title":"Custom thread pool","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/","wordcount":252},{"author":null,"categories":null,"content":" You can view basic information of your application on SOFADashboard, including the IP address, ports, and health check status. This feature is dependent on the SOFADashboard client. If you want to display the information about an application on the SOFADashboard control page, import the sofa-dashboard-client dependency.\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-dashboard-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; Function display ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/dashboard-client/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"60586c6dfee1f2afcdac88cbe7a36b83","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","summary":" You can view basic information of your application on SOFADashboard, including the IP address, ports, and health check status. This feature is dependent on the SOFADashboard client. If you want to display the information about an application on the SOFADashboard control page, import the sofa-dashboard-client dependency.\n\u0026lt;denpendency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofa-dashboard-client\u0026lt;/artifactId\u0026gt; \u0026lt;/denpendency\u0026gt; Function display ","tags":null,"title":"Dashboard client","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/","wordcount":52},{"author":null,"categories":null,"content":" In this document will demonstrate how to use SOFATracer to track of Datasource.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce SOFATracer Introduce SOFATracer dependency in the new Spring Boot project:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.2.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce h2database dependencies For convenience, we use the h2database memory database for test. So, we need to introduce the following dependencies:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.h2database\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;h2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;runtime\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;mysql\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mysql-connector-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce the required connection pool dependencies Introduce the required connection pool dependency packages, such as druid, c3p0, tomcat, dbcp, Hikari, and so on.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;druid\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;c3p0\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;c3p0\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.9.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.tomcat\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tomcat-jdbc\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;8.5.31\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-dbcp\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-dbcp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.zaxxer\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;HikariCP-java6\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.8\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configure data source Taking HikariCP as the example, we create a new Spring configuration file named datasource.xml, which defines the followings:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- dataSource pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;simpleDataSource\u0026amp;quot; class=\u0026amp;quot;com.zaxxer.hikari.HikariDataSource\u0026amp;quot; destroy-method=\u0026amp;quot;close\u0026amp;quot; primary=\u0026amp;quot;true\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;driverClassName\u0026amp;quot; value=\u0026amp;quot;org.h2.Driver\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;jdbcUrl\u0026amp;quot; value=\u0026amp;quot;jdbc:h2:~/test\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;username\u0026amp;quot; value=\u0026amp;quot;sofa\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;password\u0026amp;quot; value=\u0026amp;quot;123456\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; Application configuration Required configuration It should be noted that it is …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-datasource/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d9d8f6756a294104647067eaa7827f61","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","summary":"In this document will demonstrate how to use SOFATracer to track of Datasource.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce SOFATracer Introduce SOFATracer dependency in the new Spring Boot project:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.2.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Introduce h2database dependencies For convenience, we use the h2database memory database for test. So, we need to introduce the following dependencies:","tags":null,"title":"DataSource Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/","wordcount":642},{"author":null,"categories":null,"content":" Datasource Log Format SOFATracer tracks the standard JDBC data source and outputs the chain data of SQL statement execution, in the default JSON format.\nDataSource digest log (datasource-client-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Database.name Database name Sql SQL execution statement Result.code SQL execution status code Total.time SQL statement execution total time Connection.establish.span SQL execution connection establishment time Db.execute.cost SQL execution time Database.type Database type Database.endpoint Database url Current.thread.name Current thread name Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-28 01:11:56.715\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e1bcab91538068316462100111113\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1.2\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;success\u0026amp;quot;,\u0026amp;quot;total.time\u0026amp;quot;:\u0026amp;quot;228ms\u0026amp;quot;,\u0026amp;quot;connection.establish.span\u0026amp;quot;:\u0026amp;quot;220ms\u0026amp;quot;,\u0026amp;quot;db.execute.cost\u0026amp;quot;:\u0026amp;quot;3ms\u0026amp;quot;,\u0026amp;quot;database.type\u0026amp;quot;:\u0026amp;quot;h2\u0026amp;quot;,\u0026amp;quot;database.endpoint\u0026amp;quot;:\u0026amp;quot;jdbc:h2:~/test:-1\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} DataSource statistical Log (datasource-client-stat.log) stat.key is the set of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, database.name, and SQL field.\n Key Meaning time Log printing time stat.key local.app Current application name database.name Database name sql SQL execution statement count SQL execution count in this period total.cost.milliseconds Total duration (ms) for SQL execution in this period success Request result: Y for success; N for failure load.test Pressure mark: T for pressure test; F for non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-28 01:12:43.647\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;, \u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:228,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-datasource/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"647de768aff8ececc8276d247c5afee1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","summary":"Datasource Log Format SOFATracer tracks the standard JDBC data source and outputs the chain data of SQL statement execution, in the default JSON format.\nDataSource digest log (datasource-client-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Database.","tags":null,"title":"DataSource log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/","wordcount":202},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 DataSource 进行埋点。\n SOFATracer 2.2.0 基于标准的 JDBC 接口实现，支持对标准的数据库连接池（如 DBCP、Druid、c3p0、tomcat、HikariCP、BoneCP）埋点。下面演示如何接入 SOFATracer 埋点能力。\n 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 引入 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入 h2database 依赖 为了方便，我们使用 h2database 内存数据库测试，引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.h2database\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;h2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;runtime\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;mysql\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mysql-connector-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入所需的连接池依赖 用户引入所需的连接池依赖包，如 druid, c3p0, tomcat, dbcp, Hikari 等。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;druid\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;c3p0\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;c3p0\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.9.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.tomcat\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tomcat-jdbc\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;8.5.31\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-dbcp\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-dbcp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.zaxxer\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;HikariCP-java6\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.3.8\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置数据源 我们以 HikariCP 为例，新建一个名为datasource.xml Spring 配置文件，定义如下内容:\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- dataSource pool --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;simpleDataSource\u0026amp;quot; class=\u0026amp;quot;com.zaxxer.hikari.HikariDataSource\u0026amp;quot; destroy-method=\u0026amp;quot;close\u0026amp;quot; primary=\u0026amp;quot;true\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;driverClassName\u0026amp;quot; value=\u0026amp;quot;org.h2.Driver\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;jdbcUrl\u0026amp;quot; value=\u0026amp;quot;jdbc:h2:~/test\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;username\u0026amp;quot; value=\u0026amp;quot;sofa\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;password\u0026amp;quot; value=\u0026amp;quot;123456\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 应用配置 必要配置 需要注意一点，引入 SOFATracer 需要强制配置应用名，否则应用启动失败。这一属性和 SOFABoot 框架要求一致，配置如下：\nspring.application.name=SOFATracerDataSource 非必要配置 为了该演示工程正常运行，需要配置 h2database 属性；另为了方便查看日志，配置日志路径。如下：\n# logging path logging.path=./logs # h2 web consloe 路径 spring.h2.console.path=/h2-console # 开启 h2 web consloe，默认为 false spring.h2.console.enabled=true #允许远程访问 h2 web consloe spring.h2.console.settings.web-allow-others=true spring.datasource.username=sofa …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-datasource/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d9d8f6756a294104647067eaa7827f61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","summary":"在本文档将演示如何使用 SOFATracer 对 DataSource 进行埋点。 SOFATracer 2.2.0 基于标准的 JDBC 接口实现，支持对标准的数据库连接池（如 DBCP、Druid、c3p0、tomcat、H","tags":null,"title":"DataSource 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-datasource/","wordcount":1014},{"author":null,"categories":null,"content":" SOFATracer 对标准的 JDBC 数据源进行埋点，输出 SQL 语句执行链路数据，默认日志输出为 JSON 数据格式。\nDataSource 摘要日志（datasource-client-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 database.name 数据库名称 sql sql执行语句 connection.establish.span sql执行建连时间 db.execute.cost sql执行时间 database.type 数据库类型 database.endpoint 数据库url sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 21:31:31.566\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe91d156743109138810017302\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;15ms\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;DROP TABLE IF EXISTS TEST; CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;,\u0026amp;quot;connection.establish.span\u0026amp;quot;:\u0026amp;quot;128ms\u0026amp;quot;,\u0026amp;quot;db.execute.cost\u0026amp;quot;:\u0026amp;quot;15ms\u0026amp;quot;,\u0026amp;quot;database.type\u0026amp;quot;:\u0026amp;quot;h2\u0026amp;quot;,\u0026amp;quot;database.endpoint\u0026amp;quot;:\u0026amp;quot;jdbc:h2:~/test:-1\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} DataSource 统计日志（datasource-client-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、database.name、和 sql 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 database.name 数据库名称 sql sql执行语句 count 本段时间内sql执行次数 total.cost.milliseconds 本段时间内sql执行总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 21:31:50.435\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerDataSource\u0026amp;quot;,\u0026amp;quot;database.name\u0026amp;quot;:\u0026amp;quot;test\u0026amp;quot;,\u0026amp;quot;sql\u0026amp;quot;:\u0026amp;quot;DROP TABLE IF EXISTS TEST; CREATE TABLE TEST(ID INT PRIMARY KEY%2C NAME VARCHAR(255));\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:15,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-datasource/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"647de768aff8ececc8276d247c5afee1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-datasource/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-datasource/","summary":"SOFATracer 对标准的 JDBC 数据源进行埋点，输出 SQL 语句执行链路数据，默认日志输出为 JSON 数据格式。 DataSource 摘要日志（datasource-client-digest.","tags":null,"title":"DataSource 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-datasource/","wordcount":427},{"author":null,"categories":null,"content":" SOFABoot is based on Spring Boot. It means SOFABoot manages SOFA middleware dependencies and provides the Starter for Spring Boot, facilitating the use of SOFA middleware in Spring Boot.\nSOFABoot dependency management You must load SOFABoot\u0026amp;rsquo;s management dependencies before using SOFA middleware. In a way similar to use Spring Boot, add the configuration tag \u0026amp;lt;parent/\u0026amp;gt; in the project settings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Where ${sofa.boot.version} represents the SOFABoot version (refer to release history).\nUse Middleware of SOFAStack For SOFABoot, use -sofa-boot-starter suffixes to name middleware components. If you want to use middleware, simply add its dependencies; To use SOFARPC, for example, simply add the following Maven dependencies:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note that there is no version declaration in the above Maven dependencies as the version has already been declared in sofabook-dependencies. This allows for unified upgrade of all SOFA middleware versions, allaying concerns over dependency conflicts or incompatibility brought by upgrade of a single middleware version. The SOFABoot middleware under control is listed as follows:\n Middleware starter SOFARPC rpc-sofa-boot-starter SOFATracer tracer-sofa-boot-starter SOFALookout lookout-sofa-boot-starter Introducing SOFABoot Extension Based on Spring Boot, SOFABoot provides extended capabilities such as health check, module isolation, and class isolation. In accordance with Spring Boot\u0026amp;rsquo;s the dependency-as-a-service principle, the extension capability will be ready immediately after relevant dependencies are added. Currently, there are several extension modules available:\n Extension components starter Health check healthcheck-sofa-boot-starter Module isolation Isle-Sofa-boot-starter Class isolation sofa-Ark-springboot-starter Test extension test-Sofa-boot-starter Introducing the SOFA middleware: the Ark plug-in SOFABoot provides a class isolation component—SOFAArk, which enables users to package third-party packages with dependency conflicts into an Ark plug-in. At run time, the Ark plug-in is loaded with a separate classloader; it is isolated from other Ark plug-ins and business dependencies to address class conflicts. SOFABoot provides SOFARPC and SOFATracer\u0026amp;rsquo;s Ark plug-ins; the Ark plug-in SOFARPC, for example, is loaded into the application to replace SOFARPC starter, to isolate the application from SOFARPC and its indirect dependencies. The controlled Ark plug-ins are listed as follows:\n Ark plug-in plugin SOFARPC rpc-sofa-boot-plugin SOFATracer tracer-sofa-boot-plugin Introducing SOFABoot namespace Before using SOFA middleware, we need to add …","date":-62135596800,"description":"","dir":"projects/sofa-boot/dependency-management/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dabdbd425f20dee4d7ab580d43574456","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/dependency-management/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/dependency-management/","summary":"SOFABoot is based on Spring Boot. It means SOFABoot manages SOFA middleware dependencies and provides the Starter for Spring Boot, facilitating the use of SOFA middleware in Spring Boot.\nSOFABoot dependency management You must load SOFABoot\u0026rsquo;s management dependencies before using SOFA middleware. In a way similar to use Spring Boot, add the configuration tag \u0026lt;parent/\u0026gt; in the project settings:\n\u0026lt;parent\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofaboot-dependencies\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${sofa.boot.version}\u0026lt;/version\u0026gt; \u0026lt;/parent\u0026gt; Where ${sofa.boot.version} represents the SOFABoot version (refer to release history).","tags":null,"title":"Dependency management","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/dependency-management/","wordcount":391},{"author":null,"categories":null,"content":" 1. Environment preparation To use SOFARegistry, you need to prepare the basic environment first. SOFARegistry depends on the following environment:\n Linux, UNIX, Mac are supported. JDK8 Compile it with Apache Maven 3.2.5 or later versions. 2. Resource Quota -cpu: 4c -memory: 8G -disk: 50G\n3. Two deployment modes Integrated deployment Package and integrate the three roles of meta, data, and session into one jvm, which can be deployed on a standalone machine or a cluster. The deployment is simple. Independent deployment Deploy the meta, data, and session roles separately. You can deploy each of them on a standalone machine or a cluster. You can deploy different numbers of servers for each role as needed. We recommend that you use this deployment mode in the production environment. 4. Configuration parameters The deployment of SOFARegistry depends on some public parameters\n properties environment Default value Function nodes.localDataCenter x DefaultDataCenter Cluster name, multiple registry centers use the same database nodes.localRegion x DEFAULT_ZONE Logical region, create multiple groups of sessions jdbc.url JDBC_URL Required Database address jdbc.username JDBC_USERNAME required database user name jdbc.password JDBC_PASSWORD Required Database password Properties can be written in registry-all/conf/application.properties, deployment under kubernetes can also use configmap for file mounting\n5. Packaging jar release page Download the latest registry-all.tgz package\ntar -zxvf registry-all.tgz cd registry-all Or package from source\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all image image hosted at https://hub.docker.com/r/sofaregistry/sofaregistry\nOr build from source code: Modify the image repository in Makefile\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true make image_build make image_push 6. Integrated deployment mode The integrated deployment mode is to package and integrate the three roles of meta/data/session into a JVM to run. It can be deployed on a single machine or in a cluster. It is not recommended for large-scale use\n6.1 jar stand-alone deployment For the stand-alone deployment mode of integrated deployment, you can directly refer to the Quick Start-Server Deployment section.\n6.2 jar cluster deployment Unzip registry-all.tgz and modify the configuration file Cluster deployment, that is, to build a cluster of 2 or more, it is recommended to use at least 3 (note: currently does not support the deployment of multiple SOFARegistry on the same machine, so you must have 3 different machines). The deployment method on each machine is the same as above:\ncp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar …","date":-62135596800,"description":"","dir":"projects/sofa-registry/deployment/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7e28583bc38be66af8d704d7fbcd9dd4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/deployment/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/deployment/","summary":"1. Environment preparation To use SOFARegistry, you need to prepare the basic environment first. SOFARegistry depends on the following environment:\n Linux, UNIX, Mac are supported. JDK8 Compile it with Apache Maven 3.2.5 or later versions. 2. Resource Quota -cpu: 4c -memory: 8G -disk: 50G\n3. Two deployment modes Integrated deployment Package and integrate the three roles of meta, data, and session into one jvm, which can be deployed on a standalone machine or a cluster.","tags":null,"title":"Deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/deployment/","wordcount":1040},{"author":null,"categories":null,"content":" 1. How to compile Install JDK7 or later versions, and Maven 3.2.5 or later versions. Directly download the code, and execute the following command in the code directory:\n mvn clean install 2. Version release Version number ACTS uses a three-digit version number in the form of major, minor, and patch, for example, 1.0.1.\nFor more information, see https://semver.org/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Patch number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application is. Version maintenance At most two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 1.3.0, the BugFix branch of version 1.2.x will be maintained, but bugs in branch 1.1.x will no longer be fixed. Therefore, a version upgrade for 1.1.x is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 1.3.0-SNAPSHOT. Upon formal release, SNAPSHOT is replaced with a formal version number, for example 1.3.0. After the formal release, the next version is pulled, for example, 1.3.1-SNAPSHOT. 3. Testing Unit test Add the unit test case to the model that you have developed. The package name of the test class is identical to that of the tested class.\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/developer-guide/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fcacc7e89b979f3aec8dc3333a7a3c37","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/developer-guide/","summary":"1. How to compile Install JDK7 or later versions, and Maven 3.2.5 or later versions. Directly download the code, and execute the following command in the code directory:\n mvn clean install 2. Version release Version number ACTS uses a three-digit version number in the form of major, minor, and patch, for example, 1.0.1.\nFor more information, see https://semver.org/.\n Major version number: All versions within a major version number must be compatible with each other.","tags":null,"title":"Developer guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/developer-guide/","wordcount":249},{"author":null,"categories":null,"content":" Develope guide of code contribution First refer to the basic Notes for code contribution Note the test case coverage; Note the code format; Verify samples Import the sample Maven project separately; Modify the dependency version in the corresponding Pom file; Verify that samples can work correctly as well. ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/development-use-guide/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"423a54ec3f5fbfc9c0e150eb853738ae","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","summary":" Develope guide of code contribution First refer to the basic Notes for code contribution Note the test case coverage; Note the code format; Verify samples Import the sample Maven project separately; Modify the dependency version in the corresponding Pom file; Verify that samples can work correctly as well. ","tags":null,"title":"Development guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/development-use-guide/","wordcount":48},{"author":null,"categories":null,"content":"SOFARPC supports scenarios where a specified address is called.\nThe use of direct call in Java API is as follows, only set the direct connection address:\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); The use of direct call in XML is as follows:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sample.HelloService\u0026amp;quot; id=\u0026amp;quot;helloService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; The use of direct call in Annotation is as follows:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, directUrl = \u0026amp;quot;127.0.0.1:12220\u0026amp;quot;)) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/peer-to-peer/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b1815c322f5dc9528f6429d1d5e38369","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","summary":"SOFARPC supports scenarios where a specified address is called.\nThe use of direct call in Java API is as follows, only set the direct connection address:\nConsumerConfig\u0026lt;HelloService\u0026gt; consumer = new ConsumerConfig\u0026lt;HelloService\u0026gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026quot;bolt://127.0.0.1:12201\u0026quot;); The use of direct call in XML is as follows:\n\u0026lt;sofa:reference interface=\u0026quot;com.alipay.sample.HelloService\u0026quot; id=\u0026quot;helloService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:route target-url=\u0026quot;127.0.0.1:12200\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:reference\u0026gt; The use of direct call in Annotation is as follows:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026quot;bolt\u0026quot;, directUrl = \u0026quot;127.","tags":null,"title":"Direct call","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/","wordcount":73},{"author":null,"categories":null,"content":" Fault Recover Including Fault-Hystrix and Fault-Tolerance features.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e567dc5e291867e92c8dd1c4f953b768","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault/","summary":"Fault Recover Including Fault-Hystrix and Fault-Tolerance features.","tags":null,"title":"Disaster recovery","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault/","wordcount":7},{"author":null,"categories":null,"content":" Distributed consensus algorithm Understand distributed consensus Multiple participants reach a complete consensus on one thing: one conclusion for one thing. The conclusion cannot be overthrown. Typical distributed consensus algorithms Paxos: It is considered as the foundation of distributed consensus algorithms. Other algorithms are its variants. However, the Paxos paper only provides the process of a single proposal, without describing the details of multi-paxos that is required for state machine replication. Paxos implementation involves high engineering complexity, for example, multiple-point writes and log hole tolerance. Zab: It is applied in ZooKeeper and widely used in the industry. However, it is not available as a universal library. Raft: It is known for being easy to understand. There are many renowned Raft implementations in the industry, such as etcd, Braft, and TiKV. Introduction to Raft Raft is in nature a Paxos-based distributed consensus algorithm that is much easier to understand than Paxos. Unlike Paxos, Raft divides the protocols into independent modules, and uses a streamlined design, making the Raft protocol easier to implement.\nSpecifically, Raft divides consensus protocols into almost completely decoupled modules, such as leader election, membership change, log replication, and snapshot.\nRaft adopts a more streamlined design by preventing reordering commits, simplifying roles (it has only three roles: leader, follower, and candidate), allowing only the leader to write, and using randomized timeout values to design leader election.\nFeature: strong leader The system can have only one leader at the same time, and only the leader can accept requests sent by clients. The leader is responsible for communication with all followers, sending proposals to all followers, and receiving responses from the majority of followers. The leader also needs to send heartbeats to all followers to maintain its leadership. To summarize, a strong leader tells its followers: \u0026amp;ldquo;Do not say anything. Do what I said and let me know when you finish!\u0026amp;rdquo; In addition, a leader must always remain active by sending heartbeats to followers. Otherwise, a follower will take its place.\nReplicated state machine Assume we have an infinitely incrementing sequence (system) a[1, 2, 3…]. If for any integer i, the value of a[i] meets the distributed consensus requirement, the system meets the requirement of a consensus state machine. Basically, all real life systems are subject to continuous operations, and reaching consensus on a single value is definitely not enough. To make sure all replicas of a real life system are consistent, we usually convert the operations into entries of a write-ahead-log(WAL). Then, we make sure all replicas of the system reach a consensus on the WAL entries, so that each replica performs operations of the WAL entries in order. As a result, the replicas are in consistent states.\n A client sent a write (operation) request to …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/consistency-raft-jraft/","fuzzywordcount":4900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a0e98df1bec305cca7db6fc34fc97771","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":23,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","summary":"Distributed consensus algorithm Understand distributed consensus Multiple participants reach a complete consensus on one thing: one conclusion for one thing. The conclusion cannot be overthrown. Typical distributed consensus algorithms Paxos: It is considered as the foundation of distributed consensus algorithms. Other algorithms are its variants. However, the Paxos paper only provides the process of a single proposal, without describing the details of multi-paxos that is required for state machine replication.","tags":null,"title":"Distributed consensus - Raft and JRaft","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/","wordcount":4871},{"author":null,"categories":null,"content":"SOFARPC provides support for the Dubbo protocol, making it convenient for you to interface with existing Dubbo service. * Basic usage\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"87d78ed0c2d06fe7e1dbf9cb9d6c1c9d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/dubbo/","summary":"SOFARPC provides support for the Dubbo protocol, making it convenient for you to interface with existing Dubbo service. * Basic usage","tags":null,"title":"Dubbo","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/dubbo/","wordcount":21},{"author":null,"categories":null,"content":" Dubbo Integration In this document will demonstrate how to use SOFATracer to track of Dubbo, this example address.\nPrepare Environment The versions of the framework components used in this case are as follows:\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 This case includes three submodules:\n tracer-sample-with-dubbo-consumer service provider tracer-sample-with-dubbo-provider service consumer tracer-sample-with-dubbo-facade service interface define New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026amp;rsquo;s dependency. First, you need to unzip the generated zip package of Spring Boot project and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more information about SOFABoot versions, refer to Release notes.\nNew tracer-sample-with-dubbo-facade Module provider a service interface\npublic interface HelloService { String SayHello(String name); } New tracer-sample-with-dubbo-provider Module provider SOFATracer dependency\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer versions are controlled by SOFABoot versions. If the SOFABoot versions used do not match, you need to manually specify a tracer version that is higher than 2.4.0.\n application.properties Configuration # Spring boot application spring.application.name=dubbo-provider # Base packages to scan Dubbo Component: @org.apache.dubbo.config.annotation.Service dubbo.scan.base-packages=com.alipay.sofa.tracer.examples.dubbo.impl ## Filter dubbo.provider.filter=dubboSofaTracerFilter # Dubbo Protocol dubbo.protocol.name=dubbo ## Dubbo Registry dubbo.registry.address=zookeeper://localhost:2181 logging.path=./logs Publish the Dubbo service using annotations\n@Service public class HelloServiceImpl implements HelloService { @Override public String SayHello(String name) { return \u0026amp;quot;Hello , \u0026amp;quot;+name; } } New tracer-sample-with-dubbo-consumer Module provider SOFATracer dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; application.properties Configuration\nspring.application.name=dubbo-consumer dubbo.registry.address=zookeeper://localhost:2181 dubbo.consumer.filter=dubboSofaTracerFilter logging.path=./logs Service reference @Reference(async = false) public HelloService …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-dubbo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"03f845606b454a7224333238aeecd9ab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","summary":"Dubbo Integration In this document will demonstrate how to use SOFATracer to track of Dubbo, this example address.\nPrepare Environment The versions of the framework components used in this case are as follows:\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 This case includes three submodules:\n tracer-sample-with-dubbo-consumer service provider tracer-sample-with-dubbo-provider service consumer tracer-sample-with-dubbo-facade service interface define New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026rsquo;s dependency.","tags":null,"title":"Dubbo Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/","wordcount":297},{"author":null,"categories":null,"content":" Dubbo Log Format SOFATracer integrates Dubbo and outputs the requested link log data format. The default is JSON data format.\nDubbo service consumer digest log（dubbo-client-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app Current application name protocol protocol service service interface method service method invoke.type invoke type remote.host remote host remote.port remote port local.host local host client.serialize.time request serialize time client.deserialize.time response deserialize time req.size.bytes Request Body Size resp.size.bytes Response Body Size result.code result code current.thread.name Current thread name time.cost.milliseconds Request time (ms) baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-03 11:36:01.909\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8451554262561656100126684\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;dubbo-consumer\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;dubbo\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.dubbo.facade.HelloService\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;SayHello\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.232.69\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;20880\u0026amp;quot;,\u0026amp;quot;local.host\u0026amp;quot;:\u0026amp;quot;10.15.232.69\u0026amp;quot;,\u0026amp;quot;client.serialize.time\u0026amp;quot;:35,\u0026amp;quot;client.deserialize.time\u0026amp;quot;:0,\u0026amp;quot;req.size.bytes\u0026amp;quot;:323,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:323,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:252,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Dubbo service provider digest log（dubbo-server-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app current application name service service inteface method service method local.host local host local.host local port protocol protocol server.serialize.time response serialize time server.deserialize.time request deserialize time result.code result code current.thread.name current thread name time.cost.milliseconds Request time (ms) baggage Transparently transmitted baggage data Example\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-03 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-dubbo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"9bac8256ee1a74546b74799f9f1c0de9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","summary":"Dubbo Log Format SOFATracer integrates Dubbo and outputs the requested link log data format. The default is JSON data format.\nDubbo service consumer digest log（dubbo-client-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time traceId TraceId spanId SpanId span.kind span Type local.app Current application name protocol protocol service service interface method service method invoke.","tags":null,"title":"Dubbo log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/","wordcount":275},{"author":null,"categories":null,"content":"SOFARPC 提供了 Dubbo 协议的支持，可以让用户非常方便地和现有的 Dubbo 的系统做对接。 * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"87d78ed0c2d06fe7e1dbf9cb9d6c1c9d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/dubbo/","summary":"SOFARPC 提供了 Dubbo 协议的支持，可以让用户非常方便地和现有的 Dubbo 的系统做对接。 * 基本使用","tags":null,"title":"Dubbo 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/dubbo/","wordcount":38},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 Dubbo 协议，只要将 Binding 设置为 Dubbo 即可。下面使用以注解的方式来例举，其他的使用方式可以参考 Bolt 协议基本使用，这里不再重复说明。：\n发布服务 发布一个 Dubbo 的服务，只需要将 @SofaServiceBinding 的 bindingType 设置为 dubbo 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 引用服务 引用一个 Dubbo 的服务，只需要将 @SofaReferenceBinding 的 bindingType 设置为 dubbo 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; 设置 Dubbo 服务的 Group 在 SOFARPC 的模型中，没有直接的一个字段叫做 Group，但是 SOFARPC 有一个 uniqueId 的模型，可以直接映射到 Dubbo 的模型中的 Group，比如下面的代码，就是发布了一个 Group 为 groupDemo 的服务：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;)}, uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;) public class SampleServiceImpl implements SampleService { } 如下的代码，就是引用了一个 Group 为 groupDemo 的服务：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;dubbo\u0026amp;quot;), uniqueId = \u0026amp;quot;groupDemo\u0026amp;quot;, jvmFirst = false) private SampleService sampleService; 注意，目前 Dubbo 协议只支持 Zookeeper 作为服务注册中心。\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/dubbo-usage/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1bf72c194a20a5dccea70423690191f4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/dubbo-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/dubbo-usage/","summary":"在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 Dubbo 协议，只要将 Binding 设置为 Dubbo 即可。下面使用以注解的方式来例举，其他的使用方式可以","tags":null,"title":"Dubbo 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/dubbo-usage/","wordcount":322},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 Dubbo 进行埋点，本示例工程地址。\n基础环境 本案例使用的各框架组件的版本如下：\n SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 本案例包括三个子模块：\n tracer-sample-with-dubbo-consumer 服务调用方 tracer-sample-with-dubbo-provider 服务提供方 tracer-sample-with-dubbo-facade 接口 原理 SOFATracer 对象 Dubbo 的埋点实现依赖于 Dubbo 的 SPI 机制来实现，Tracer 中基于 调用拦截扩展 自定义了 DubboSofaTracerFilter 用于实现对 Dubbo 的调用埋点。由于 DubboSofaTracerFilter 并没有成为 Dubbo 的官方扩展，因此在使用 SOFATracer 时需要安装 调用拦截扩展 中 所提供的方式进行引用，即：\n\u0026amp;lt;!-- 消费方调用过程拦截 --\u0026amp;gt; \u0026amp;lt;dubbo:reference filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;!-- 消费方调用过程缺省拦截器，将拦截所有reference --\u0026amp;gt; \u0026amp;lt;dubbo:consumer filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- 提供方调用过程拦截 --\u0026amp;gt; \u0026amp;lt;dubbo:service filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;!-- 提供方调用过程缺省拦截器，将拦截所有service --\u0026amp;gt; \u0026amp;lt;dubbo:provider filter=\u0026amp;quot;dubboSofaTracerFilter\u0026amp;quot;/\u0026amp;gt; 新建 SOFABoot 工程作为父工程 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 Maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n新建 tracer-sample-with-dubbo-facade 提供一个接口\npublic interface HelloService { String SayHello(String name); } 新建 tracer-sample-with-dubbo-provider 在工程模块的 pom 文件中添加 SOFATracer 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer 版本受 SOFABoot 版本管控，如果使用的 SOFABoot 版本不匹配，则需要手动指定 tracer 版本，且版本需高于 2.4.0.\n 在工程的 application.properties 文件下添加相关参数， # Spring boot application spring.application.name=dubbo-provider # Base packages to scan Dubbo Component: @org.apache.dubbo.config.annotation.Service dubbo.scan.base-packages=com.alipay.sofa.tracer.examples.dubbo.impl ## Filter 必须配置 dubbo.provider.filter=dubboSofaTracerFilter # Dubbo Protocol dubbo.protocol.name=dubbo ## Dubbo Registry dubbo.registry.address=zookeeper://localhost:2181 logging.path=./logs 使用注解方式发布 Dubbo 服务\n@Service public class HelloServiceImpl implements HelloService { @Override public String SayHello(String name) { return \u0026amp;quot;Hello , \u0026amp;quot;+name; } } 新建 tracer-sample-with-dubbo-consumer 在工程模块的 pom 文件中添加 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 在工程的 application.properties 文件下添加相关参数\nspring.application.name=dubbo-consumer dubbo.registry.address=zookeeper://localhost:2181 # Filter 必须配置 dubbo.consumer.filter=dubboSofaTracerFilter logging.path=./logs 服务引用 @Reference(async = false) public HelloService helloService; @Bean …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-dubbo/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"03f845606b454a7224333238aeecd9ab","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","summary":"在本文档将演示如何使用 SOFATracer 对 Dubbo 进行埋点，本示例工程地址。 基础环境 本案例使用的各框架组件的版本如下： SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 2.4.0/3.0.4 JDK 8 本案例包括三个子模块： tracer-sample-with-dubbo-consumer 服务调","tags":null,"title":"Dubbo 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/","wordcount":760},{"author":null,"categories":null,"content":" SOFATracer 集成 Dubbo 后输出请求的链路数据格式，默认为 JSON 数据格式。\nDubbo 服务消费方摘要日志（dubbo-client-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 protocol 协议 service 服务接口 method 调用方法 invoke.type 调用类型 remote.host 目标主机 remote.port 目标端口 local.host 本地主机 client.serialize.time 请求序列化时间 client.deserialize.time 响应反序列化时间 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 error 错误信息 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:36:08.250\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;dubbo-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e27a79c156743856804410019644\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;205ms\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;dubbo\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.glmapper.bridge.boot.service.HelloService\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;SayHello\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;192.168.2.103\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;20880\u0026amp;quot;,\u0026amp;quot;local.host\u0026amp;quot;:\u0026amp;quot;192.168.2.103\u0026amp;quot;,\u0026amp;quot;client.serialize.time\u0026amp;quot;:35,\u0026amp;quot;client.deserialize.time\u0026amp;quot;:5,\u0026amp;quot;req.size.bytes\u0026amp;quot;:336,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:48,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Dubbo 服务提供方摘要日志（dubbo-server-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 protocol 协议 service 服务接口 method 调用方法 invoke.type 调用类型 local.host 本地主机 local.port 本地端口 server.serialize.time 响应序列化时间 server.deserialize.time 请求反序列化时间 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 error 错误信息 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-dubbo/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9bac8256ee1a74546b74799f9f1c0de9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","summary":"SOFATracer 集成 Dubbo 后输出请求的链路数据格式，默认为 JSON 数据格式。 Dubbo 服务消费方摘要日志（dubbo-client-digest.log） 以 JSON 格式输出的数据","tags":null,"title":"Dubbo 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-dubbo/","wordcount":550},{"author":null,"categories":null,"content":" The engine architecture is shown in the following diagram. Node A node in a Raft cluster connects and encapsulates all underlayer service modules, and main service interfaces that are visible to users. Specifically, the leader node of a raft group calls apply(task) to commit new tasks to the state machine replication cluster made up by the Raft group, which will then apply the task to the business state machine.\nStorage It stores Raft configuration changes and log entries converted from requests submitted by users, and replicates log entries from the leader\u0026amp;rsquo;s log to followers\u0026amp;rsquo; logs. LogStorage stores logs, while LogManager is responsible for calling the underlayer storage, caching and batch submitting storage calls, and conducting necessary checks and optimization. MetaStorage stores the metadata and records the internal states of the Raft implementation, for example, the current term of the node and the node to vote for. Optional. Snapshot storage is used to store users\u0026amp;rsquo; state-machine snapshots and meta information. SnapshotStorage stores snapshots, while SnapshotExecutor manages the actual storage, remote installation, and replication of snapshots. State machine StateMachine is an implementation of users\u0026amp;rsquo; core logic. It calls the onApply(Iterator) method to apply log entries that are submitted with Node#apply(task) to the business state machine. FSMCaller encapsulates state transition calls that are sent to the User StateMachine, writes log entries, implements a finite-state machine (FSM), conducts necessary checks, and merges requests for batch submission and concurrent processing. Replication Replicator is used by the leader to replicate log entries to followers. It does the same thing as an AppendEntries RPC of Raft. Without log entries, it is sent by the leader as heartbeats. ReplicatorGroup is used by a Raft group to manage all replicators, and to perform necessary permission checks and dispatches. RPC The RPC module is used for network communication between nodes.\n The RPC server is built in a node to receive requests from other nodes or clients, and to redirect such requests to the corresponding service modules. The RPC client is used to issue requests to other nodes, such as requests for votes, log replication requests, and heartbeats. ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/engine-architecture/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d2cc9de133aed20695229d0cde5b6ff9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","summary":"The engine architecture is shown in the following diagram. Node A node in a Raft cluster connects and encapsulates all underlayer service modules, and main service interfaces that are visible to users. Specifically, the leader node of a raft group calls apply(task) to commit new tasks to the state machine replication cluster made up by the Raft group, which will then apply the task to the business state machine.","tags":null,"title":"Engine architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/engine-architecture/","wordcount":347},{"author":null,"categories":null,"content":" ExtensionLoader To ensure that all steps of SOFARPC have sufficient scalability, SOFARPC defines a very flexible extension mechanism in which all extension implementations are equal.\nThis mechanism is very useful for both SOFARPC developers and users. SOFARPC abstracts itself into multiple modules which have no explicit dependencies on each other and interact via SPI.\nThis extension mechanism abstracts the interaction method of SPI. If you have read the documents about Filter and Router, you may have such experience.\nThe following sections introduce how to extend through the SPI interaction method.\nSOFARPC provides the capabilities of ExtensionLoader.\nDesign extension points SOFARPC defines an annotation @Extensible, which is on the interface or abstract class to identify that the class is an extension point. Namely, it informs SOFARPC that the class is extensible and SOFARPC needs to find the implementation of the extension point. In addition, the annotation defines the file name of the implementation class and whether the class is a singleton.\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * Specify the name of the custom extension file, which is the full class name by default * * @return Custom extension file name */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * Whether the extension class uses a singleton, yes by default * * @return Whether to use a singleton */ boolean singleton() default true; /** * Whether the extension class needs to be encoded, not by default * * @return Whether to encode */ boolean coded() default false; } SOFARPC also defines the @Extension annotation, which indicates an extension implementation class. It also defines the name that the extension point uses when looking for an extension implementation in the file.\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * Extension point name * * @return Extension point name */ String value(); /** * Extension point coding, not required by default; it is required when the interface needs to be encoded * * @return Extension point encoding * @see Extensible#coded() */ byte code() default -1; /** * Priority sorting, not required by default, the larger number, the higher priority * * @return Sort */ int order() default 0; /** * Whether to override other extensions with low {@link #order()} * * @return Whether to override other low-order extensions * @since 5.2.0 */ boolean override() default false; /** * Exclude other extensions, namely exclude other extensions with low {@link #order()} * * @return Excludes other extensions * @since 5.2.0 */ String[] rejection() default {}; } Add extension point Define extension points. @Extensible public interface Person { void getName(); } Define the extension implementation. @Extension(\u0026amp;quot;A\u0026amp;quot;) public class PersonA implements Person{ @Override public void getName() { System.out.println(\u0026amp;quot;li wei\u0026amp;quot;); } } …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/extension-loader/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"acc5628da3a7ea2df5eb68bd8ec17159","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/extension-loader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/extension-loader/","summary":"ExtensionLoader To ensure that all steps of SOFARPC have sufficient scalability, SOFARPC defines a very flexible extension mechanism in which all extension implementations are equal.\nThis mechanism is very useful for both SOFARPC developers and users. SOFARPC abstracts itself into multiple modules which have no explicit dependencies on each other and interact via SPI.\nThis extension mechanism abstracts the interaction method of SPI. If you have read the documents about Filter and Router, you may have such experience.","tags":null,"title":"Extension mechanism","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/extension-loader/","wordcount":603},{"author":null,"categories":null,"content":" Customize different engine stages You can rewrite APIs provided by ActsTestBase in the test script or in the base class.\n Rewrite the prepare, execute, check, and clear actions. For example, you can add some actions before or after super.prepare(). Rewrite the process method. You can add some actions before or after super.process() to reorchestrate the entire script. For example, you can add some personalized steps in the existing clear \u0026amp;gt; prepare \u0026amp;gt; execute \u0026amp;gt; check process. Rewrite beforeActsTest and afterActsTest to add some personalized actions before or after the running of each test case, such as preparing the context and refreshing the cache. Parameterization In response expectation and database expectation data, you can use $Variable name to define a value as a variable. You can set values of the variable in the test script. Supported scope: request parameters, responses, and database table fields. Supported types: Currently, only string parameterization is supported.\nUsage:\n(1) Add $ before a value to define it as a variable in the interface.\n(2) Assign values to the variables in the test script.\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { actsRuntimeContext.paramMap.put(\u0026amp;quot;roleId\u0026amp;quot;, \u0026amp;quot;123\u0026amp;quot;); actsRuntimeContext.refreshDataParam(); } When you write the database expectation, you can use the equal sign = to assign a value to the variable. This indicates that the value is a query result, and subsequent tables can use this variable as the value.\nAssume that the interface will insert data into two tables.\n id_A value_A 123 abc id_B value_B abc efg When you query these two tables, first query for value_A based on id_A in Table A that is returned by the interface. Then use value_A as a condition for the query in Table B. You can set the values as follows in the plug-in.\n Field Flag Value id_A C $param1 value_A Y =param2 Field Flag Value id_B C $param2 value_B Y efg Operation description:\n =param2 and $param2 indicate that the ACTS framework will first query for value_A in Table A, and then select from B where id_B = value_A to obtain the property value of id_B in Table B. $param1 indicates that you can assign a value to id_A in the code, for example: actsRuntimeContext.paramMap.put(\u0026amp;quot;param1\u0026amp;quot;,\u0026amp;quot;123\u0026amp;quot;); This snippet assigns the value 123 to the variable param1. You can write this snippet to beforeActsTest in the test script to make the ACTS framework query table A before assigning the value 123 to id_A.\nComponentization Currently, only string componentization is supported.\nIf a property is a dynamically generated string, for example, some IDs. You can use the at sign @ to call a component to generate this property. The component must be placed in the component package at the same level as the test module, namely: com.corpname.appname.acts.component (appname is the name of the system, and corpname is the name of the company, for …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-api/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ce7e264713a6f7a3f0672e2432489f59","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-api/","summary":"Customize different engine stages You can rewrite APIs provided by ActsTestBase in the test script or in the base class.\n Rewrite the prepare, execute, check, and clear actions. For example, you can add some actions before or after super.prepare(). Rewrite the process method. You can add some actions before or after super.process() to reorchestrate the entire script. For example, you can add some personalized steps in the existing clear \u0026gt; prepare \u0026gt; execute \u0026gt; check process.","tags":null,"title":"Extensions","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-api/","wordcount":1102},{"author":null,"categories":null,"content":" Q: What should I do if NoSuchMethodError is returned? Generally, this error is returned in the case of dependency conflicts. Commonly known dependency conflicts are listed as follows. Exclude the corresponding dependencies when you encounter relevant conflicts.\nLog conflict commons-logging conflict \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-logging\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; logback-classic conflict Rule out logback-classic by the location of the conflict. For example, application dependencies spring-boot-starter-logging and spring-test conflict with each other.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.3.4.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; snakeyaml conflict java.lang.NoSuchMethodError: org.yaml.snakeyaml.Yaml.\u0026amp;lt;init\u0026amp;gt;(Lorg/yaml/snakeyaml/constructor/BaseConstructor;)V org.yaml referenced in spring-boot-starter-test conflicts with org.yaml referenced in org.testing. In the following sample code, a conflict of org.yaml in spring-boot-starter-test is ruled out (it can also be ruled out at other conflict locations such as org.testing):\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.yaml\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;snakeyaml\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Q: What should I do if NoClassDefFoundError is returned? Generally, this error is returned in the case of missing dependencies or dependency conflicts.\nMockito returns a no class found error While using Mockito with SOFABoot, you do not have to import Mockito if the spring-boot-starter-test dependency already exists.\nQ: What should I do if \u0026amp;ldquo;No bean dataAccessConfigManager available\u0026amp;rdquo; is returned? This error is returned because the application starter class specified by the test script does not have the acts-core.xml file. You can add the acts-core.xml file according to the following figure.\nQ: What should I do if \u0026amp;ldquo;No runnable methods\u0026amp;rdquo; is returned? Generally, this error is caused when you run your Junit test with the ACTS test script. You can use the TestNG framework to run the ACTS test script.\nQ: What should I do in the case of a model …","date":-62135596800,"description":"","dir":"projects/sofa-acts/faq/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5f89d1f5695cbe6b669a8738741529bd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/faq/","summary":"Q: What should I do if NoSuchMethodError is returned? Generally, this error is returned in the case of dependency conflicts. Commonly known dependency conflicts are listed as follows. Exclude the corresponding dependencies when you encounter relevant conflicts.\nLog conflict commons-logging conflict \u0026lt;exclusion\u0026gt; \u0026lt;artifactId\u0026gt;commons-logging\u0026lt;/artifactId\u0026gt; \u0026lt;groupId\u0026gt;commons-logging\u0026lt;/groupId\u0026gt; \u0026lt;/exclusion\u0026gt; logback-classic conflict Rule out logback-classic by the location of the conflict. For example, application dependencies spring-boot-starter-logging and spring-test conflict with each other.\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.","tags":null,"title":"FAQ","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/faq/","wordcount":633},{"author":null,"categories":null,"content":" Common issues Q: Is SOFARPC the version used inside Ant Financial? Yes, SOFARPC has excellent extension interfaces, and the version for internal use just has some additional extension implementations based on the open source version. For example, the cloud-based commercial version integrates the Ant Financial Technology\u0026amp;rsquo;s shared registry center, Distributed System Tracing (DST) and other products. The version for internal use integrates Ant Financial\u0026amp;rsquo;s internal registry center, LDC router and other individual extensions.\nQ: Does SOFARPC use ZooKeeper as the registry center internally? Can it integrate other registry centers such as etcd? Ant Financial uses its self-developed registry products internally. SOFARPC\u0026amp;rsquo;s registry modules are extensible. All the registry modules use the same set of core interfaces for both internal and external use. Currently, the open-source version has integrated with ZooKeeper, and other registry implementation communities are being integrated.\nQ: What is the difference between SOFARPC and Dubbo? Dubbo, developed by Alibaba Group, is an excellent open-source RPC framework featuring high performance and good scalability. Dubbo is a comparatively mature open source framework, with a large number of users and rich open source ecology. Now, it has joined the Apache Foundation for incubation. Dubbo was first widely used in the Alibaba B2B department.\nOriginated from HSF in Alibaba Group, SOFARPC now has grown to an independent product. SOFARPC has carried out a lot of reconstruction and optimization on the aspects of protocol, network, routing, and scalability to meet the large-scale financial business scenarios of Ant Financial. In the Ant Financial\u0026amp;rsquo;s middleware (SOFAStack) ecosystem, SOFARPC is supported by a comprehensive microservices technology stack, including Microservices R\u0026amp;amp;D framework, RPC framework, service registry center, distributed scheduling task, throttling framework, Dynamic Configuration, DST, Metrics and others. By Dec. 11, 2017, SOFARPC has been used by thousands of systems in Ant Financial, and the production environment has released more than tens of thousands of interfaces.\nHowever, in the open source field, SOFARPC is still at the initial stage, and its open source ecosystem is still under construction. With the advancement of the open source plan, various related components will be available in the subsequent versions to improve the microservices stack. You are welcome to build SOFAStack together with us.\nIn terms of performance, the technical points of both products involved in protocols are similar. As for scalability, both products have good scalability. As for other functional differences, here are some features that have been opened source or will be open sourced in the near future for reference:\n SOFARPC supports HTTP/2 and GRPC protocols and provides such capabilities as service warm-up weight, automatic degradation upon fault, negotiation mechanism, and CRC data …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/faq/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a6ec77ce5a423c5345394f42c64a416b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/faq/","summary":"Common issues Q: Is SOFARPC the version used inside Ant Financial? Yes, SOFARPC has excellent extension interfaces, and the version for internal use just has some additional extension implementations based on the open source version. For example, the cloud-based commercial version integrates the Ant Financial Technology\u0026rsquo;s shared registry center, Distributed System Tracing (DST) and other products. The version for internal use integrates Ant Financial\u0026rsquo;s internal registry center, LDC router and other individual extensions.","tags":null,"title":"FAQ","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/faq/","wordcount":742},{"author":null,"categories":null,"content":"Usually, a service have multiple service providers in a cluster. Some of the service providers may have persistent connections still survived due to network, configuration, long-term fullgc, full thread pool, hardware failure and others, but the program cannot respond properly. The stand-alone fault tolerance function can degrade the exceptional service providers so that the client requests can be pointed to the healthy node. When the exceptional nodes become normal, the standalone fault tolerance function will restore the nodes, so that the client requests can gradually distribute traffic to the nodes. The standalone fault tolerance function solves the problem that service failures continue to affect the business, avoids the avalanche effect, reduces the long response time required for manual intervention and increases system availability.\nRunning mechanism:\n Standalone fault tolerance counts the number of calls and the number of exceptions in a time range, and calculates the abnormal rate of IP for each service and the average abnormal rate of the service. When the IP abnormal rate is greater than the service average abnormal rate to a certain ratio, the dimension of the service + ip is degraded. If the weight of the service + ip dimension is not degraded to 0, then when the call of the service + ip dimension is normal, the weight will be restored. The entire calculation and control process proceeds asynchronously, thus not blocking the call. The standalone fault tolerance is used as follows:\nFaultToleranceConfig faultToleranceConfig = new FaultToleranceConfig(); faultToleranceConfig.setRegulationEffective(true); faultToleranceConfig.setDegradeEffective(true); faultToleranceConfig.setTimeWindow(20); faultToleranceConfig.setWeightDegradeRate(0.5); FaultToleranceConfigManager.putAppConfig(\u0026amp;quot;appName\u0026amp;quot;, faultToleranceConfig); As above, after the standalone fault tolerance switch is turned on, the application will calculate the exceptions every 20s time window. If a service + IP calling dimension is determined to be a faulty node, the weight of the service + IP will be degraded to 0.5 times.\nFor more detailed parameters, please refer to Standalone troubleshooting\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-tolerance/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7501b0fac1d1d89c61de0d591e29e1d0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","summary":"Usually, a service have multiple service providers in a cluster. Some of the service providers may have persistent connections still survived due to network, configuration, long-term fullgc, full thread pool, hardware failure and others, but the program cannot respond properly. The stand-alone fault tolerance function can degrade the exceptional service providers so that the client requests can be pointed to the healthy node. When the exceptional nodes become normal, the standalone fault tolerance function will restore the nodes, so that the client requests can gradually distribute traffic to the nodes.","tags":null,"title":"Fault tolerance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/","wordcount":306},{"author":null,"categories":null,"content":"Fault tolerance automatically monitors the RPC calls, degrades the weight of the failed node, and recovers the weight when the node restored to normal. The bolt protocol is currently supported.\nIn SOFABoot, you only need to configure fault tolerance parameters to application.properties. You can select not to configure all parameters but only configure the parameters that you care about. Then, the remaining parameters will take the default values. Note that rpc.aft.regulation.effective is a global switch for this function. If it is off, the function will not work and other parameters will not take effect.\n Attribute Description Default value timeWindow Time window size: the period in which statistics are calculated. 10s leastWindowCount Minimum number of calls in the time window: Only data that has reached this minimum value in the time window will be added in calculation and control. 10 times leastWindowExceptionRateMultiple Degradation ratio of the exception rate in the time window to the average exception rate of the service: When calculating the statistical information, the average exception rate of all valid call IPs of the service is calculated. If the exception rate of an IP is greater than or equal to the lowest ratio, the IP will be degraded. 6 times weightDegradeRate Degradation ratio: The rate of degradation of an address when it is degraded. 1\u0026amp;frasl;20 weightRecoverRate Recovery ratio: The recovery ratio of the address when it is weighted. 2 times degradeEffective Degradation switch: If the application turns on this switch, it will degrade the address that matches the degradation criteria; otherwise, only the log will be printed. false (off) degradeLeastWeight Degradation minimum weight: If the address weight is degraded to the weight less than this minimum weight, the minimum weight will be used. 1 degradeMaxIpCount Maximum number of IPs for degradation: The number of IPs in the same service that have been degraded cannot exceed this value. 2 regulationEffective Global switch: If the switch is turned on by the application, the entire standalone fault tolerance function will be turned on; otherwise, this function will not be used at all. false (off) Example\nCom.alipay.sofa.rpc.aft.time.window=20 Com.alipay.sofa.rpc.aft.least.window.count=30 Com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple=6 Com.alipay.sofa.rpc.aft.weight.degrade.rate=0.5 Com.alipay.sofa.rpc.aft.weight.recover.rate=1.2 Com.alipay.sofa.rpc.aft.degrade.effective=ture Com.alipay.sofa.rpc.aft.degrade.least.weight=1 Com.alipay.sofa.rpc.aft.degrade.max.ip.count=2 Com.alipay.sofa.rpc.aft.regulation.effective=true As configured above, the fault tolerance function and degradation switch are enabled. When a node fails too many times, its weight is degraded, and during recovery, the weight will be restored. The node healthy is measured every 20s, and the nodes called for more than 30 times in 20s are recognized as calculation data. If the …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-fault-tolerance/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a132b54b2398534d1773489e2b0db166","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","summary":"Fault tolerance automatically monitors the RPC calls, degrades the weight of the failed node, and recovers the weight when the node restored to normal. The bolt protocol is currently supported.\nIn SOFABoot, you only need to configure fault tolerance parameters to application.properties. You can select not to configure all parameters but only configure the parameters that you care about. Then, the remaining parameters will take the default values. Note that rpc.","tags":null,"title":"Fault tolerance configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/","wordcount":487},{"author":null,"categories":null,"content":" Feature architecture SOFABolt provides the following basic features: Basic communication functions (remoting-core) Netty-based, highly-effective network I/O and thread model practice Connection management (lock-free connection establishment, timed disconnection, automatic reconnection) Basic communication models (oneway, sync, future, callback) Timeout control Batch unpacking and batch submission processor Heartbeat and IDLE event processing Protocol framework (protocol-skeleton) Commands and command processor Coding and decoding processor Heartbeat trigger Custom private protocol implementation - RPC communication protocol (protocol-implementation) RPC communication protocol design Flexible deserialization timing control Request processing timeout FailFast mechanism User request processor (UserProcessor) Duplex communication Usage 1 Use SOFABolt as a remote communication framework. You do not need to consider the details of how to implement a private protocol, just use our built-in RPC communication protocol. You can simply enable the client side and the server side, and simultaneously register a user request processor, thereby completing the remote calling. In addition, basic features such as connection management and heartbeat are available by default. Currently supported call types are shown in the figure below:\n For a sample demonstration, refer to our user guide. Usage 2 Use SOFABolt as a protocol framework. You can reuse the basic functions of the basic communication model, the interface definitions included in the protocols, etc. Then, according to the private protocol you designed, you can customize the command types, command processors, decoding processors, etc. The RPC and message command definition structure is as shown in the figure below:\n","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-functions/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fde29139cbd8b786326a6479e52814dd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","summary":"Feature architecture SOFABolt provides the following basic features: Basic communication functions (remoting-core) Netty-based, highly-effective network I/O and thread model practice Connection management (lock-free connection establishment, timed disconnection, automatic reconnection) Basic communication models (oneway, sync, future, callback) Timeout control Batch unpacking and batch submission processor Heartbeat and IDLE event processing Protocol framework (protocol-skeleton) Commands and command processor Coding and decoding processor Heartbeat trigger Custom private protocol implementation - RPC communication protocol (protocol-implementation) RPC communication protocol design Flexible deserialization timing control Request processing timeout FailFast mechanism User request processor (UserProcessor) Duplex communication Usage 1 Use SOFABolt as a remote communication framework.","tags":null,"title":"Features","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/","wordcount":237},{"author":null,"categories":null,"content":" Features Service publishing and reference Communication Protocol Bolt protocol Basic usage Calling type Timeout control Generic call Serialization protocol Custom thread pool RESTful protocol Basic usage Custom filter Integrated Swagger Dubbo Basic usage H2C Basic usage Registry center Direct call Load balancing Custom filter Custom router addressing Call retry Tracing SOFATracer Skywalking Custom thread pool Link data transparent transmission Warm-up weight Fault tolerance Node cross-language call Graceful shutdown ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/features/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0059809aed46360e8787e945ff098610","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/features/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/features/","summary":" Features Service publishing and reference Communication Protocol Bolt protocol Basic usage Calling type Timeout control Generic call Serialization protocol Custom thread pool RESTful protocol Basic usage Custom filter Integrated Swagger Dubbo Basic usage H2C Basic usage Registry center Direct call Load balancing Custom filter Custom router addressing Call retry Tracing SOFATracer Skywalking Custom thread pool Link data transparent transmission Warm-up weight Fault tolerance Node cross-language call Graceful shutdown ","tags":null,"title":"Features","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/features/","wordcount":68},{"author":null,"categories":null,"content":" 本文描述的是 MOSN 的 FilterChain 配置。\nFilterChain 是 MOSN Listener 配置中核心逻辑配置，不同的 FilterChain 配置描述了 Listener 会如何处理请求。\n目前 MOSN 一个 Listener 只支持一个 FilterChain。\nFilterChain 的配置结构如下所示。\n{ \u0026amp;quot;tls_context\u0026amp;quot;: {}, \u0026amp;quot;tls_context_set\u0026amp;quot;: [], \u0026amp;quot;filters\u0026amp;quot;: [] } tls_context_set 一组 tls_context 配置，MOSN 默认使用 tls_context_set 来描述 listener 的 TLS 的证书信息。 一个 listener 可同时支持配置多张 TLS 证书。 tls_context 单独配置 tls_context 而不是使用 tls_context_set 是兼容 MOSN 历史配置（只支持一张证书配置时）的场景，这种配置方式后面会逐步废弃。 tls_context 的详细配置说明，参考 tls_context。 filters 一组 network filter 配置。\nnetwork filter network filter 描述了 MOSN 在连接建立以后如何在 4 层处理连接数据。\n{ \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: {} } type 是一个字符串，描述了 filter 的类型。 config 可以是任意 json 配置，描述不同 filter 的配置。 network filter 可自定义扩展实现，默认支持的 type 包括 proxy、tcp proxy、connection_manager。 connection_manager 是一个特殊的 network filter，它需要和 proxy 一起使用，用于描述 proxy 中路由相关的配置，是一个兼容性质的配置，后续可能有修改。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/filter-chain/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d79979b85edad41aa6f0b3d8fe3295ee","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","summary":"本文描述的是 MOSN 的 FilterChain 配置。 FilterChain 是 MOSN Listener 配置中核心逻辑配置，不同的 FilterChain 配置描述了 Listener 会如何处理请求。 目前 MOSN 一个 Listener 只支持一个 FilterChain。 FilterChain 的配","tags":null,"title":"FilterChain 配置","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/filter-chain/","wordcount":389},{"author":null,"categories":null,"content":" Framework preparation Before reading, you can download and install ACTS IDE and import the ACTS framework by refering to Quick start.\nThis topic mainly describes the encoding, datasource configuration, and quick configuration to help you use the ACTS framework.\nEncoding Ensure that the encoding of ACTS and that of the system code are consistent, specifically, ensure that the encoding for script generation and the encoding of the IDEA workspace are consistent with the encoding of your application code. Otherwise, the code may get corrupted.\nThe encoding selected for test script generation is shown as follows.\nEncoding of the IDEA workspace:\nDatasource configuration The purpose of configuring data sources in ACTS is to ensure that you can use the system\u0026amp;rsquo;s data sources to properly perform database addition, deletion, and query operations during the preparation, clearance, and check stages.\nDatasource configuration Configure the mapping relationship between the ModuleName, datasource, and tables at the DAL layer in src/test/resource/config/acts-config.properties. The name of datasources starts with ds_ as follows:\ndatasource_bundle_name =com.alipay.testapp.common.dal ds_bean1=table1,table2 ds_bean2=table3,table4 #Configuration format #ds_datasource bean=logical table 1,logical table 2 Bean 1 and bean 2 are the names of the datasource beans at the DAL layer of the application code. Multiple datasources are supported. The table name supports regular expressions and sharding suffixes are not required. In the case of multiple datasources, a table must belong to only one datasource. See the following figure.\nDirect JDBC connection to the database The direct JDBC connection to the database is used to generate the DB data model. The configuration in devdb.conf or testdb.conf under src/test/resource/config/dbConf/ is as follows:\nxxx_url = jdbc:oracle:thin:@localhost:1521:cifdb xxx_username = myname xxx_password = mypswd Quick configuration description The quick test framework configuration mainly generates the basic Java classes and the necessary configuration files:\nJava classes AppNameActsBaseUtils.java The utility class that is commonly used in the test script writing process to get various data from the ACTS framework. The initial version provides only common methods. You can add desired methods by yourself.\n AppNameActsTestBase.java The encapsulated application test base class. If you have special business system requirements, you can encapsulate additional methods based on this class. If not, ignore this file.\nConfiguration files ","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ready/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c3a89cbf42d55c98206a08e94d05ffde","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-ready/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-ready/","summary":"Framework preparation Before reading, you can download and install ACTS IDE and import the ACTS framework by refering to Quick start.\nThis topic mainly describes the encoding, datasource configuration, and quick configuration to help you use the ACTS framework.\nEncoding Ensure that the encoding of ACTS and that of the system code are consistent, specifically, ensure that the encoding for script generation and the encoding of the IDEA workspace are consistent with the encoding of your application code.","tags":null,"title":"Framework preparation","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-ready/","wordcount":358},{"author":null,"categories":null,"content":"Since Java 8, Java has introduced various @FunctionalInterface interfaces to support functional programming. Generally, Java functions will be executed in a ForkJoinPool. If some thread variables of Tracer are not passed in, it will cause the loss of Trace information.\nTherefore, in SOFATracer XXX version, a series of wrapper classes for these @FunctionalInterface interfaces has been added to ensure that trace-related information can be transferred correctly and transparently. The following is an example of the Consumer interface, just need to change the construction of Consumer to SofaTracerConsumer, and pass the original Consumer as the parameter of the constructor of SofaTracerConsumer:\nConsumer\u0026amp;lt;String\u0026amp;gt; consumer = new SofaTracerConsumer\u0026amp;lt;\u0026amp;gt;(System.out::println); All wrapped classes are in the https://github.com/sofastack/sofa-tracer/tree/master/tracer-core/src/main/java/com/alipay/common/tracer/core/async directory.\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/functional-interface-support/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"45e4d21f290976f4206beac2f4712aec","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","summary":"Since Java 8, Java has introduced various @FunctionalInterface interfaces to support functional programming. Generally, Java functions will be executed in a ForkJoinPool. If some thread variables of Tracer are not passed in, it will cause the loss of Trace information.\nTherefore, in SOFATracer XXX version, a series of wrapper classes for these @FunctionalInterface interfaces has been added to ensure that trace-related information can be transferred correctly and transparently. The following is an example of the Consumer interface, just need to change the construction of Consumer to SofaTracerConsumer, and pass the original Consumer as the parameter of the constructor of SofaTracerConsumer:","tags":null,"title":"Functional interface support","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/","wordcount":113},{"author":null,"categories":null,"content":"从 Java 8 中，Java 开始引入了各种 @FunctionalInterface 接口，以更好地支持函数式编程，通常，Java 的函数会在一个 ForkJoinPool 中执行，如果这个时候没有把 Tracer 的一些线程变量传递进去的话，就会造成 Trace 信息的丢失。\n因此，在 SOFATracer XXX 版本中增加了对这些 @FunctionalInterface 接口的包装类，以确保 Trace 相关的信息能够正确地传递下面，下面以 Consumer 接口为例进行说明，只需要将原来构造 Consumer 的地方修改成构造 SofaTracerConsumer，并且将原来的 Consumer 传入作为 SofaTracerConsumer 的构造函数的参数即可：\nConsumer\u0026amp;lt;String\u0026amp;gt; consumer = new SofaTracerConsumer\u0026amp;lt;\u0026amp;gt;(System.out::println); 所有做了包装的类都在 https://github.com/sofastack/sofa-tracer/tree/master/tracer-core/src/main/java/com/alipay/common/tracer/core/async 目录下，文档中不一一列举。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/functional-interface-support/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"45e4d21f290976f4206beac2f4712aec","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/functional-interface-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/functional-interface-support/","summary":"从 Java 8 中，Java 开始引入了各种 @FunctionalInterface 接口，以更好地支持函数式编程，通常，Java 的函数会在一个 ForkJoinPool 中执行，如果这个时候没有把 Tracer 的一些线程变量传递","tags":null,"title":"Functional 接口支持","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/functional-interface-support/","wordcount":229},{"author":null,"categories":null,"content":" Generic calls provide the ability for clients to initiate calls without having to rely on the server`s interface. Currently, the generic call of SOFARPC only supports using Hessian2 as the serialization protocol under the Bolt communication protocol.\nSOFABoot environment Publish Service There is nothing special about publishing a service. Just publish the service normally, for example:\n\u0026amp;lt;!-- generic --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleGenericServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Reference Service \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.api.GenericService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs generic-interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; The jvm-first can be left empty according to the actual situation. The interface should be the general interface of generic call. As for the generic-interface, you can just write in the name of the interface to be called.\nInitiate a call GenericService sampleGenericServiceReference = (GenericService) applicationContext .getBean(\u0026amp;quot;sampleGenericServiceReference\u0026amp;quot;); GenericObject genericResult = (GenericObject) sampleGenericServiceReference.$genericInvoke(\u0026amp;quot;sayGeneric\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.samples.generic.SampleGenericParamModel\u0026amp;quot; }, new Object[] { genericObject }); RPC API ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;GenericService\u0026amp;gt;() .setInterfaceId(\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;) .setGeneric(true); GenericService testService = consumerConfig.refer(); String result = (String) testService.$invoke(\u0026amp;quot;sayHello\u0026amp;quot;, new String[] { \u0026amp;quot;java.lang.String\u0026amp;quot; },new Object[] { \u0026amp;quot;1111\u0026amp;quot; }); You can set the service as a generic service and set the interface name of the server by setGeneric as above. GenericService is used as a generic service, and GenericService can initiate generic calls. You need to pass in the method name, method type, and method parameters when invoking a call.\nIf the parameter or return result is also required to be generalized on the client side, you can achieve this with GenericObject.\nGenericObject genericObject = new GenericObject(\u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot;); genericObject.putField(\u0026amp;quot;str\u0026amp;quot;, \u0026amp;quot;xxxx\u0026amp;quot;); genericObject.putField(\u0026amp;quot;num\u0026amp;quot;, 222); GenericObject result = (GenericObject) testService.$genericInvoke(\u0026amp;quot;echoObj\u0026amp;quot;, new String[] { \u0026amp;quot;com.alipay.sofa.rpc.invoke.generic.TestObj\u0026amp;quot; }, new Object[] { genericObject }); String str = result.getField(\u0026amp;quot;str\u0026amp;quot;); String …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/generic-invoke/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"84ac624dc99a42a8f89489aa10304ef7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","summary":"Generic calls provide the ability for clients to initiate calls without having to rely on the server`s interface. Currently, the generic call of SOFARPC only supports using Hessian2 as the serialization protocol under the Bolt communication protocol.\nSOFABoot environment Publish Service There is nothing special about publishing a service. Just publish the service normally, for example:\n\u0026lt;!-- generic --\u0026gt; \u0026lt;bean id=\u0026quot;sampleGenericServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.generic.SampleGenericServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;sampleGenericServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.generic.SampleGenericService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt/\u0026gt; \u0026lt;/sofa:service\u0026gt; Reference Service \u0026lt;sofa:reference jvm-first=\u0026quot;false\u0026quot; id=\u0026quot;sampleGenericServiceReference\u0026quot; interface=\u0026quot;com.","tags":null,"title":"Generic call","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/generic-invoke/","wordcount":501},{"author":null,"categories":null,"content":" This document introduces how to use SOFARPC for service publishing and reference in SOFABoot.\nYou can get the code sample of this document by clicking here. Note that the code sample requires a local installation of the zookeeper environment. If not, you need to remove the com.alipay.sofa.rpc.registry.address configuration in application.properties to use the local file as a registry center.\nCreate a project Prepare environment: SOFABoot requires JDK7 or JDK8 and needs to be compiled with Apache Maven 2.2.5 or above. Build SOFABoot project: SOFABoot is based on Spring Boot. So you can use Spring Boot\u0026amp;rsquo;s project generation tool to generate a standard Spring Boot project. Add SOFABoot dependency: The generated standard Spring Boot project directly uses Spring parent dependency, which should be changed to the parent dependency provided by SOFABoot. The parent dependency provides and manages a variety of starters provided by SOFABoot. \u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa-boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Here, \u0026amp;lsquo;${sofa-boot.version}\u0026amp;rsquo; specifies the specific SOFABoot version. Refer to Release History.\n Configure application.properties: application.properties is the configuration file in SOFABoot project. Here you need to configure the application name. spring.application.name=AppName Introduce RPC starter: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Define service interface and implementation public interface AnnotationService { String sayAnnotation(String string); } Publish service on server Publish the service through \u0026amp;lsquo;@SofaService\u0026amp;rsquo; annotation, as shown in the following code: SOFABoot registers the service implementation on the server, communicates with the client by bolt protocol, and publishes metadata such as address to registry center (local file is used as registry center by default).\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } Reference service by client The reference service is annotated with \u0026amp;lsquo;@SofaReference\u0026amp;rsquo;, as shown in the following code: SOFABoot will generate a RPC proxy bean for \u0026amp;lsquo;AnnotationService\u0026amp;rsquo;, it also …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-sofa-boot/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0dd5e0e5116473aee630cba38679d493","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","summary":"This document introduces how to use SOFARPC for service publishing and reference in SOFABoot.\nYou can get the code sample of this document by clicking here. Note that the code sample requires a local installation of the zookeeper environment. If not, you need to remove the com.alipay.sofa.rpc.registry.address configuration in application.properties to use the local file as a registry center.\nCreate a project Prepare environment: SOFABoot requires JDK7 or JDK8 and needs to be compiled with Apache Maven 2.","tags":null,"title":"Get started with SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/","wordcount":501},{"author":null,"categories":null,"content":" This document introduces how to apply SOFARPC for service publishing and reference. This example will simulate a server locally to listen to a port and publish a service, and the client will reference the service for direct call.\nYou can get the code sample of this document by clicking here.\nCreate a project You need to install JDK 6 or above and Maven 3 or above.\nCreate a new Maven project and introduce SOFARPC dependency.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;latest version\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note: The latest version can be found at https://github.com/sofastack/sofa-rpc/releases.\nWrite a server implementation Step 1: Create interface\n/** * Quick Start demo interface */ public interface HelloService { String sayHello(String string); } Step 2: Create interface implementation\n/** * Quick Start demo implement */ public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string { System.out.println(\u0026amp;quot;Server receive: \u0026amp;quot; + string); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; !\u0026amp;quot;; } } Step 3: Write the server code\n/** * Quick Start Server */ public class QuickStartServer { public static void main(String[] args) { ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // Set a protocol, which is bolt by default .setPort(12200) // set a port, which is 12200 by default .setDaemon(false); // non-daemon thread ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // Specify the interface .setRef(new HelloServiceImpl()) // Specify the implementation .setServer(serverConfig); // Specify the server providerConfig.export (); // Publish service } } Write a client implementation Step 1: Get the server interface\nIn general, the server provides the interface class to the client in the form of jar. In this example, this step is skipped since the server and client are in the same project.\nStep 2: Write the client code\n/** * Quick Start client */ public class QuickStartClient { public static void main(String[] args) { ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // Specify the interface .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // Specify the protocol.setDirectUrl .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12200\u0026amp;quot;); // Specify the direct connection address // Generate the proxy class HelloService helloService = consumerConfig.refer(); while (true) { System.out.println(helloService.sayHello(\u0026amp;quot;world\u0026amp;quot;)); try { Thread.sleep(2000); } catch (Exception e) { } } } } Run Start the server and client separately.\nThe server outputs:\n Server receive: The world\n The client outputs:\n hello world !\n More For more examples, please refer to: example\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-rpc/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"192d252b0b36266622284b68d10e9fe4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","summary":"This document introduces how to apply SOFARPC for service publishing and reference. This example will simulate a server locally to listen to a port and publish a service, and the client will reference the service for direct call.\nYou can get the code sample of this document by clicking here.\nCreate a project You need to install JDK 6 or above and Maven 3 or above.\nCreate a new Maven project and introduce SOFARPC dependency.","tags":null,"title":"Get started with SOFARPC","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/","wordcount":371},{"author":null,"categories":null,"content":" Graceful shutdown includes two parts. One is the RPC framework as client, and the other is the RPC framework as server.\nAs server As the server, the RPC framework should not be violently shutdown.\ncom.alipay.sofa.rpc.context.RpcRuntimeContext Added a ShutdownHook to the static initialization snippet:\n// Add jvm shutdown event if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } The logic in ShutdownHook is executed first when the publishing platform or users run the following method kill pid. In the destroy operation, the RPC framework first performs actions such as canceling service registration to the registry center and closing the service port.\nprivate static void destroy(boolean active) { RpcRunningState.setShuttingDown (true); for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.preDestroy(); } List\u0026amp;lt;ProviderConfig\u0026amp;gt; providerConfigs = new ArrayList\u0026amp;lt;ProviderConfig\u0026amp;gt;(); for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { providerConfigs.add(bootstrap.getProviderConfig()); } // First, unregister the server List\u0026amp;lt;Registry\u0026amp;gt; registries = RegistryFactory.getRegistries(); if (CommonUtils.isNotEmpty(registries) \u0026amp;amp;\u0026amp;amp; CommonUtils.isNotEmpty(providerConfigs)) { for (Registry registry : registries) { registry.batchUnRegister(providerConfigs); } } / / Shut down the port that has been started ServerFactory.destroyAll(); // Close the published service for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { bootstrap.unExport(); } // Close the called service for (ConsumerBootstrap bootstrap : REFERRED_CONSUMER_CONFIGS) { ConsumerConfig config = bootstrap.getConsumerConfig(); If (!CommonUtils.isFalse(config.getParameter(RpcConstants.HIDDEN_KEY_DESTROY))) { // Unless you do not let the active unrefer bootstrap.unRefer(); } } // Shut down the registry center RegistryFactory.destroyAll(); / / Close some public resources of the client ClientTransportFactory.closeAll(); // Uninstall the module if (!RpcRunningState.isUnitTestMode()) { ModuleFactory.uninstallModules(); } // Uninstall the hook for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.postDestroy(); } // Clean up the cache RpcCacheManager.clearAll(); RpcRunningState.setShuttingDown (false); if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework has been release all resources {}...\u0026amp;quot;, active ? \u0026amp;quot;actively \u0026amp;quot; : \u0026amp;quot;\u0026amp;quot;); } } Taking bolt as an example, closing the port is not an immediate action.\n@Override public void destroy() { if (!started) { return; } int stopTimeout = serverConfig.getStopTimeout(); If (stopTimeout \u0026amp;gt; 0) { // need to wait for the end time AtomicInteger count = …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/graceful-shutdown/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"53af179e23ba184b01eb8234c055b15d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","summary":"Graceful shutdown includes two parts. One is the RPC framework as client, and the other is the RPC framework as server.\nAs server As the server, the RPC framework should not be violently shutdown.\ncom.alipay.sofa.rpc.context.RpcRuntimeContext Added a ShutdownHook to the static initialization snippet:\n// Add jvm shutdown event if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.","tags":null,"title":"Graceful shutdown","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/","wordcount":669},{"author":null,"categories":null,"content":" H2C protocol SOFARPC provides support for the H2C protocol, which can be used to publish and reference services.\n Basic usage ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"45b6d6ba0ca1ae7f6d415d79c184f766","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/h2c/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/h2c/","summary":" H2C protocol SOFARPC provides support for the H2C protocol, which can be used to publish and reference services.\n Basic usage ","tags":null,"title":"H2C","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/h2c/","wordcount":20},{"author":null,"categories":null,"content":"SOFARPC 提供了 H2C 协议的支持，可以可以采用 H2C 协议来进行服务的发布和引用 * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"45b6d6ba0ca1ae7f6d415d79c184f766","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/h2c/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/h2c/","summary":"SOFARPC 提供了 H2C 协议的支持，可以可以采用 H2C 协议来进行服务的发布和引用 * 基本使用","tags":null,"title":"H2C","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/h2c/","wordcount":36},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 H2C 协议，只要将 Binding 设置为 H2C 即可。下面使用以注解的方式来例举，其他的使用方式可以参考 Bolt 协议基本使用，这里不再重复说明。：\n发布服务 发布一个 H2C 的服务，只需要将 @SofaServiceBinding 的 bindingType 设置为 h2c 即可：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 引用服务 引用一个 H2C 的服务，只需要将 @SofaReferenceBinding 的 bindingType 设置为 h2c 即可：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;h2c\u0026amp;quot;), jvmFirst = false) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/h2c-usage/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa75eff1e99b3acad5087160a1b44a09","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/h2c-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/h2c-usage/","summary":"在 SOFARPC 中，使用不同的通信协议只要设置使用不同的 Binding 即可，如果需要使用 H2C 协议，只要将 Binding 设置为 H2C 即可。下面使用以注解的方式来例举，其他的使用方式可以","tags":null,"title":"H2C 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/h2c-usage/","wordcount":168},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0e92b5faec8584280cc296255f3a4541","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/http/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/http/","summary":"","tags":null,"title":"HTTP","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/http/","wordcount":0},{"author":null,"categories":null,"content":" SOFABoot provides Readiness Check to enhance Spring Boot\u0026amp;rsquo;s Health Check. If you need to use the SOFA middleware, you are advised to use the Health Check extension of SOFABoot to launch application examples in a more elegant way.\nEnable Health Check To enable the Health Check feature in SOFABoot, you only need to import the following starter:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Without the Health Check extension, users still can perform Liveness Check with native Spring Boot Actuator directly relying on the HealthIndicator interface.\nSecurity alert From SOFABoot 2.3.0 on, the Health Check depends on the Actuator component in SpringBoot 1.4.x, and the component opens a lot of EndPoint such as \u0026amp;lsquo;/dump \u0026amp;rsquo; and \u0026amp;lsquo;/trace\u0026amp;rsquo;. So there may be a security risk. Refer to the Security Recommendations in the official document for settings.\nSpringBoot 1.5.x and SpringBoot 2.x. have fixed some security issues. SOFABoot will be supported by upgrading the SpringBoot kernel.\nView Health Check results After adding the Health Check extension, you can directly browser http://localhost:8080/health/readiness to view the Readiness Check results. To view the Liveness Check results, access the URL of the Spring Boot Health Check results. http://localhost:8080/health。\nIn SOFABoot, you can also view Health Check results by checking the specific logs in the health-check directory. Generally, such logs contain the following content:\n2018-04-06 23:29:50,240 INFO main - Readiness check result: success At present, the SOFA middleware has controlled upstream traffic access through the Readiness Check offered by SOFABoot. But, apart from the middleware, traffic of an application may come from other sources such as the load balancer. To control such traffic, users are advised to view the Readiness Check results by PAAS and determine whether to launch corresponding nodes in the load balancer based on the results.\n** Note: Versions after SOFABoot 2.x no longer indirectly introduce spring-boot-starter-web dependencies. To view Health Check results in the browser, you need to introduce Web container dependencies in the project. **\n** Note: In SOFABoot 3.x, the endpoint path has been changed from health/readiness to actuator/readiness**\nReadiness Check extension SOFABoot allows extension in every phase of the Readiness Check. Applications can be extended according to their needs. In version 2.x, the extendable points are as follows:\n Callback interface Description org.springframework.context.ApplicationListener If you want to do something before the Readiness Check, you can monitor the SofaBootBeforeHealthCheckEvent event of this listener. org.springframework.boot.actuate.health.HealthIndicator If you want to add a check item to the Readiness Check in SOFABoot, you can directly extend this interface of Spring Boot. …","date":-62135596800,"description":"","dir":"projects/sofa-boot/health-check/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a366b25125fa4aedb08a9cef572db1c8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/health-check/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/health-check/","summary":"SOFABoot provides Readiness Check to enhance Spring Boot\u0026rsquo;s Health Check. If you need to use the SOFA middleware, you are advised to use the Health Check extension of SOFABoot to launch application examples in a more elegant way.\nEnable Health Check To enable the Health Check feature in SOFABoot, you only need to import the following starter:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;healthcheck-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Without the Health Check extension, users still can perform Liveness Check with native Spring Boot Actuator directly relying on the HealthIndicator interface.","tags":null,"title":"Health check","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/health-check/","wordcount":707},{"author":null,"categories":null,"content":" Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to the article Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing an ACTS bug or adding an ACTS feature, submit an issue on ACTS GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project to result in repetitive work. The ACTS maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All ACTS modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step.\nGit clone https://github.com/your account name/acts.git Pull a branch to prepare for code modification.\ngit branch add_xxx_feature After the preceding command is executed, your code repository will switch to the corresponding branch. To view the current branch, execute the following command:\n git branch -a If you want to switch back to the master branch, execute the following command:\n git checkout -b master If you want to switch back to the branch, execute the following command:\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\n After modifying the code, execute the following command to submit all modifications to your local repository:\ngit commit -am \u0026#39;Add xx feature\u0026#39; When modifying the code, note the following: Keep the code style consistent. ACTS uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Supplement unit test code.\n New modifications should have passed existing unit tests.\n Provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. Execute the following command to run all tests:\nmvn clean test You can also use the IDE to help run a test.\nOther do\u0026amp;rsquo;s and …","date":-62135596800,"description":"","dir":"projects/sofa-acts/contributing/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"cd68baede6258921f83665ef0a446f1f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/contributing/","summary":"Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to the article Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing an ACTS bug or adding an ACTS feature, submit an issue on ACTS GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/contributing/","wordcount":808},{"author":null,"categories":null,"content":" We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submitting an issue Regardless of whether you are fixing a SOFADashboard bug or adding a SOFADashboard feature, submit an issue on SOFADashboard GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.\nThere are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFADashboard maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All SOFADashboard modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-dashboard.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to the branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFADashboard uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Add the unit test code.\n Modifications should have passed existing unit tests.\n You should provide a new unit test to prove that the previous code has bugs and the bugs\nhave been fixed in the new code. You can execute the following code to run all tests:\n mvn clean test You can also use the IDE to help run a test. …","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/contribution/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"584584be9c13f2d36c85890dd192368a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/contribution/","summary":"We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/contribution/","wordcount":837},{"author":null,"categories":null,"content":" We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of git tools, refer to official books on gitand get familiarized by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFARegistry bug or adding a SOFARegistry feature, submit an issue on the SOFARegistry GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFARegistry maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch All SOFARegistry modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review.\nTherefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-registry.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command:\ngit branch -a If you want to switch back to the master branch, execute the following command:\ngit checkout -b master If you want to switch back to the branch, execute the following command:\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFARegistry uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally.\nmvn clean compile Add the unit test code. Modifications should have passed existing unit tests. You should provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. You can execute the following code to run all tests: mvn clean test You can also use the IDE to help run a test.\nOther do\u0026amp;rsquo;s …","date":-62135596800,"description":"","dir":"projects/sofa-registry/contributing/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c08b5945719137833634c111c43a8d9e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/contributing/","summary":"We recommend that you go to the Roadmap topic to learn about the development tasks and plans first.\n Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of git tools, refer to official books on gitand get familiarized by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFARegistry bug or adding a SOFARegistry feature, submit an issue on the SOFARegistry GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/contributing/","wordcount":839},{"author":null,"categories":null,"content":" How to contribute SOFABolt\u0026amp;rsquo;s code is open source. You can submit your contributions to the code after signing the required agreement.\nContributor License Agreement Alterations and modifications made to SOFABolt\u0026amp;rsquo;s code must comply with the Contributor License Agreement.\nPrerequisites Before contributing any code, you need to know how to use the Git tool and the GitHub website.\nFor the use of Git tools, refer to the official Pro Git book and get familiar with the tools by reading the first few chapters.\nFor the Git collaboration process, refer to Git Workflows.\nGitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a Bolt bug or adding a Bolt feature, submit an issue on the Bolt GitHub address to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The Bolt maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start developing and submitting code after agreement to reduce the cost of communication between both parties as well as the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the Bolt\u0026amp;rsquo;s master branch code to your code repository.\nPull a branch All Bolt modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with the getting source code step, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/sofastack/sofa-bolt.git Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to your branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; If you want to directly pull a branch from GitHub, execute the following command: git clone -b branchname https://xxx.git Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. Bolt uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally. mvn clean package Add the unit test code. Modifications should have passed existing unit …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-contribution/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c044ad534cf99e4d6d400113b490f816","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","summary":"How to contribute SOFABolt\u0026rsquo;s code is open source. You can submit your contributions to the code after signing the required agreement.\nContributor License Agreement Alterations and modifications made to SOFABolt\u0026rsquo;s code must comply with the Contributor License Agreement.\nPrerequisites Before contributing any code, you need to know how to use the Git tool and the GitHub website.\nFor the use of Git tools, refer to the official Pro Git book and get familiar with the tools by reading the first few chapters.","tags":null,"title":"How to contribute to SOFABolt","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/","wordcount":1140},{"author":null,"categories":null,"content":" Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFAJRaft bug or adding a SOFAJRaft feature, submit an issue on the SOFAJRaft GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code. There are several advantages of doing so:\n There will not be any conflict with other developers or their plans for this project. This avoids repetitive work. The SOFAJRaft maintenance personnel will discuss the issue or new feature you submitted to determine whether the modification is necessary, or if there is any room for improvement or a better solution. Start code development and submit the code after an agreement is reached. This reduces the cost of communication between both parties and the number of rejected pull requests. Get the source code To modify or add a feature after submitting an issue, click the fork button in the upper left corner to copy the master branch code to your code repository.\nPull a branch We recommend that you first read the SOFAJRaft Branch management policy.\nAll SOFAJRaft modifications are performed on branches. After the modification, submit a pull request. The modifications will then be merged into the master branch by the project maintenance personnel after the code review. Therefore, after getting familiar with how to get the source code, you need to:\n Download the code locally. You may select the git/https mode in this step. git clone https://github.com/your account name/sofa-jraft Pull a branch to prepare for code modification. git branch add_xxx_feature After the preceding command is executed, your code repository is switched to the corresponding branch. To view the current branch, execute the following command: git branch -a If you want to switch back to the master branch, execute the following command: git checkout -b master If you want to switch back to the branch, execute the following command: git checkout -b \u0026amp;quot;branchName\u0026amp;quot; Modify the code and submit it locally After a branch is pulled, you can modify the code.\nWhen modifying the code, note the following: Keep the code style consistent. SOFAJRaft uses the Maven plug-in to keep the code style consistent. Before submitting the code, be sure to execute the following command locally. mvn clean compile Add the unit test code.\n New modifications should have passed existing unit tests.\n Provide a new unit test to prove that the previous code has bugs and the bugs have been fixed in the new code. Execute the following command to run all tests:\n mvn clean test You can also use the IDE to help execute a command.\nOther do\u0026amp;rsquo;s and don\u0026amp;rsquo;ts Retain the original style of the …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"99034715298f73cd835672b872141609","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","summary":"Prerequisites Before contributing any code, you need to know how to use the Git tools and the GitHub website.\n For the use of Git tools, refer to the official Pro Git book and get familiar with it by reading the first few chapters. For the Git collaboration process, refer to Git Workflows. GitHub Code Contribution Process Submit an issue Regardless of whether you are fixing a SOFAJRaft bug or adding a SOFAJRaft feature, submit an issue on the SOFAJRaft GitHub to describe the bug you are going to fix or the feature you intend to add before you submit the code.","tags":null,"title":"How to contribute to SOFAJRaft","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","wordcount":841},{"author":null,"categories":null,"content":" Http 协议基本使用 在 SOFARPC (非SOFABoot 环境)中，当使用Http作为服务端协议的时候，支持Json作为序列化方式，作为一些基础的测试方式使用。\nSOFARPC API 使用 发布服务 // 只有1个线程 执行 ServerConfig serverConfig = new ServerConfig() .setStopTimeout(60000) .setPort(12300) .setProtocol(RpcConstants.PROTOCOL_TYPE_HTTP) .setDaemon(true); // 发布一个服务，每个请求要执行1秒 ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HttpService\u0026amp;gt;() .setInterfaceId(HttpService.class.getName()) .setRef(new HttpServiceImpl()) .setApplication(new ApplicationConfig().setAppName(\u0026amp;quot;serverApp\u0026amp;quot;)) .setServer(serverConfig) .setUniqueId(\u0026amp;quot;uuu\u0026amp;quot;) .setRegister(false); providerConfig.export(); 服务引用 因为是Http+Json，所以引用方可以直接通过HttpClient进行调用,以下为一段测试代码。\nprivate ObjectMapper mapper = new ObjectMapper(); HttpClient httpclient = HttpClientBuilder.create().build(); // POST 正常请求 String url = \u0026amp;quot;http://127.0.0.1:12300/com.alipay.sofa.rpc.server.http.HttpService:uuu/object\u0026amp;quot;; HttpPost httpPost = new HttpPost(url); httpPost.setHeader(RemotingConstants.HEAD_SERIALIZE_TYPE, \u0026amp;quot;json\u0026amp;quot;); ExampleObj obj = new ExampleObj(); obj.setId(1); obj.setName(\u0026amp;quot;xxx\u0026amp;quot;); byte[] bytes = mapper.writeValueAsBytes(obj); ByteArrayEntity entity = new ByteArrayEntity(bytes, ContentType.create(\u0026amp;quot;application/json\u0026amp;quot;)); httpPost.setEntity(entity); HttpResponse httpResponse = httpclient.execute(httpPost); Assert.assertEquals(200, httpResponse.getStatusLine().getStatusCode()); byte[] data = EntityUtils.toByteArray(httpResponse.getEntity()); ExampleObj result = mapper.readValue(data, ExampleObj.class); Assert.assertEquals(\u0026amp;quot;xxxxx\u0026amp;quot;, result.getName()); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/http-json/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"28abdf6369247346bad670c639a422b8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/http-json/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/http-json/","summary":"Http 协议基本使用 在 SOFARPC (非SOFABoot 环境)中，当使用Http作为服务端协议的时候，支持Json作为序列化方式，作为一些基础的测试方式使用。","tags":null,"title":"Http 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/http-json/","wordcount":242},{"author":null,"categories":null,"content":" HttpClient Integration In this document will demonstrate how to use SOFATracer to track of HttpClient, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;!-- SOFATracer dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- HttpClient dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 4.5.X --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpasyncclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 4.X --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.1.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer under the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the current application name and logging.path that specifies the log output directory.\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs Add a Controller that provides RESTful service @RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8080/httpclient?name= * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/httpclient\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;httpclient\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } Construct HttpClient to initiate a call to the RESTful service above The code example is as follows:\n Construct an HttpClient synchronous call instance: HttpClientBuilder httpClientBuilder = HttpClientBuilder.create(); // SOFATracer SofaTracerHttpClientBuilder.clientBuilder(httpClientBuilder); CloseableHttpClient httpClient = httpClientBuilder.setConnectionManager(connManager).disableAutomaticRetries() .build(); Construct an HttpClient asynchronous call instance: RequestConfig requestConfig = RequestConfig.custom().setSocketTimeout(6000).setConnectTimeout(6000).setConnectionRequestTimeout(6000).build(); HttpAsyncClientBuilder httpAsyncClientBuilder = HttpAsyncClientBuilder.create(); //tracer SofaTracerHttpClientBuilder.asyncClientBuilder(httpAsyncClientBuilder); CloseableHttpAsyncClient asyncHttpclient = httpAsyncClientBuilder.setDefaultRequestConfig(requestConfig).build(); When you construct the HttpClient via the SofaTracerHttpClientBuilder (clientBuilder method for synchronous call instance, and asyncClientBuilder method for asynchronous call instance) to initiate a call to the RESTful service above, the link data of …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-httpclient/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3efb3d0d5bd884665537aa974ec21359","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","summary":"HttpClient Integration In this document will demonstrate how to use SOFATracer to track of HttpClient, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;!-- SOFATracer dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- HttpClient dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.apache.httpcomponents\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;httpclient\u0026lt;/artifactId\u0026gt; \u0026lt;!-- 4.5.X --\u0026gt; \u0026lt;version\u0026gt;4.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.apache.httpcomponents\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;httpasyncclient\u0026lt;/artifactId\u0026gt; \u0026lt;!-- 4.X --\u0026gt; \u0026lt;version\u0026gt;4.1.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer under the project\u0026rsquo;s application.","tags":null,"title":"HttpClient Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/","wordcount":498},{"author":null,"categories":null,"content":" HttpClient Log Format After integrating tracer-httpclient-plugin, SOFATracer outputs the link data requested by HttpClient in JSON data by default.\nHttpClient digest log (httpclient-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.code HTTP call returns status code req.size.bytes Request body size resp.size.bytes Response body size Time.cost.milliseconds Request time (ms) Current.thread.name Thread name Remote.app Name of the called application Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-27 21:58:43.067\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8801538056723034100235072\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:33,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;I/O dispatcher 1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Note: The application name can be passed in as a parameter when constructing an HttpClient instance via SofaTracerHttpClientBuilder.\nHttpClient statistical Log (httpclient-stat.log) stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success (the result code starting with 1 and 2 indicates success, and 302 indicates that the redirection is successful, and others indicate failure); N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-09-27 21:59:42.233\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:562,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-httpclient/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7df3d68ba21f1b2a43c0265fdc4eae3e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","summary":"HttpClient Log Format After integrating tracer-httpclient-plugin, SOFATracer outputs the link data requested by HttpClient in JSON data by default.\nHttpClient digest log (httpclient-digest.log) The data is output in JSON format. Each key meaning is as follows:\n Key Meaning Time log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.","tags":null,"title":"HttpClient log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/","wordcount":220},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 HttpClient 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;!-- SOFATracer 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- HttpClient 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 版本 4.5.X 系列 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.apache.httpcomponents\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;httpasyncclient\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- 版本 4.X 系列 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.1.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8080/httpclient?name= * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/httpclient\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;httpclient\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } 构造 HttpClient 发起一次对上文的 RESTful 服务的调用 代码示例如下：\n 构造 HttpClient 同步调用实例： HttpClientBuilder httpClientBuilder = HttpClientBuilder.create(); //SOFATracer SofaTracerHttpClientBuilder.clientBuilder(httpClientBuilder); CloseableHttpClient httpClient = httpClientBuilder.setConnectionManager(connManager).disableAutomaticRetries() .build(); 构造 HttpClient 异步调用实例： RequestConfig requestConfig = RequestConfig.custom().setSocketTimeout(6000).setConnectTimeout(6000).setConnectionRequestTimeout(6000).build(); HttpAsyncClientBuilder httpAsyncClientBuilder = HttpAsyncClientBuilder.create(); //tracer SofaTracerHttpClientBuilder.asyncClientBuilder(httpAsyncClientBuilder); CloseableHttpAsyncClient asyncHttpclient = httpAsyncClientBuilder.setDefaultRequestConfig(requestConfig).build(); 通过 SofaTracerHttpClientBuilder(clientBuilder 方法构造同步，asyncClientBuilder 方法构造异步) 构造的 HttpClient 在发起对上文的 RESTful 服务调用的时候，就会埋点 SOFATracer 的链路的数据。\n运行 启动 SOFABoot 应用，在控制台中看到启动打印的日志如下：\n2018-09-27 20:31:21.465 INFO 33277 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-09-27 20:31:21.599 INFO 33277 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-09-27 20:31:21.608 INFO 33277 --- [ main] c.a.s.t.e.h.HttpClientDemoApplication : Started HttpClientDemoApplication in 5.949 seconds (JVM running for 6.573) 当有类似如下的日志时，说明 HttpClient 的调用成功：\n2018-09-27 20:31:22.336 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-httpclient/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3efb3d0d5bd884665537aa974ec21359","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","summary":"在本文档将演示如何使用 SOFATracer 对 HttpClient 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;!-- SOFATracer 依","tags":null,"title":"HttpClient 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/","wordcount":748},{"author":null,"categories":null,"content":" SOFATracer 集成 sofa-tracer-httpclient-plugin 插件后输出 HttpClient 请求的链路数据，默认为 JSON 数据格式。\nHttpClient 摘要日志（httpclient-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:43:13.191\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;1e27a79c1567438993170100210107\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;I/O dispatcher 1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;21ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} 备注：应用名称可以通过 SofaTracerHttpClientBuilder 构造 HttpClient 实例时以入参的形式传入。\nHttpClient 统计日志（httpclient-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功(1 开头和 2 开头的结果码算是成功的，302表示的重定向算成功，其他算是失败的)；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-02 23:44:11.785\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;HttpClientDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/httpclient\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:229,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-httpclient/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7df3d68ba21f1b2a43c0265fdc4eae3e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","summary":"SOFATracer 集成 sofa-tracer-httpclient-plugin 插件后输出 HttpClient 请求的链路数据，默认为 JSON 数据格式。 HttpClient 摘要日志（httpclient-digest.log） 以 JSON 格式输出的数据，相应 key 的含","tags":null,"title":"HttpClient 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-httpclient/","wordcount":407},{"author":null,"categories":null,"content":" SOFARPC is integrated Hystrix provides fuse capability and is currently available in the first preview version. More information about Hystrix can be found in Hystrix Official Documentation, Hystrix integration capabilities are provided primarily by ScienJus, thanks for contribution.\nNext, let\u0026amp;rsquo;s talk about how to experience the fuse capability of Hystrix. The following example uses the SOFARPC 5.5.0 version. More Hystrix configuration and SOFABoot integration usage will be provided in subsequent releases, so stay tuned.\nWork preparation The Hystrix module is not loaded directly as an optional module by default. If you need to use it, you need to actively add the Hystrix maven dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; By explicitly opening Hystrix by configuration, HystrixFilter will be loaded automatically:\n// Open globally RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // Open for a specific Consumer ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); FallbackFactory The FallbackFactory interface mainly provides the injection capability of the Fallback implementation, which is used to automatically perform the degraded logic when Hystrix executes an exception (throws an exception, timeout, thread pool rejection, and blown).\nDefine the interface Fallback implementation:\npublic class HelloServiceFallback implements HelloService { @Override public String sayHello(String name, int age) { return \u0026amp;quot;fallback \u0026amp;quot; + name + \u0026amp;quot; from server! age: \u0026amp;quot; + age; } } Inject Fallback implementation:\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); // You can directly inject Fallback implementation directly using the default FallbackFactory SofaHystrixConfig.registerFallback(consumerConfig, new HelloServiceFallback()); // You can also customize FallbackFactory to directly inject FallbackFactory SofaHystrixConfig.registerFallbackFactory(consumerConfig, new HelloServiceFallbackFactory()); When the server responds with a failure, the client automatically triggers the Fallback logic execution.\nSetterFactory SetterFactory provides Hystrix fine-grained configuration capabilities. SOFARPC has provided the default DefaultSetterFactory to generate the Setter for each caller. If there is a more customized description, it can also be provided for each ConsumerConfig. Customize SetterFactory.\nSofaHystrixConfig.registerSetterFactory(consumerConfig, new CustomSetterFactory()); In the implementation provided by default, GroupKey is InterfaceId, and CommandKey is the …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-hystrix/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7482dc341bf16dd5671634ffa689604a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","summary":"SOFARPC is integrated Hystrix provides fuse capability and is currently available in the first preview version. More information about Hystrix can be found in Hystrix Official Documentation, Hystrix integration capabilities are provided primarily by ScienJus, thanks for contribution.\nNext, let\u0026rsquo;s talk about how to experience the fuse capability of Hystrix. The following example uses the SOFARPC 5.5.0 version. More Hystrix configuration and SOFABoot integration usage will be provided in subsequent releases, so stay tuned.","tags":null,"title":"Hystrix fault tolerance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/","wordcount":335},{"author":null,"categories":null,"content":" SOFARPC 已集成 Hystrix 提供熔断能力，当前提供第一个预览版。关于 Hystrix 的更多介绍可以参考 Hystrix 官方文档，Hystrix 集成能力主要由 ScienJus 提供，感谢贡献。\n接下来介绍一下如何体验 Hystrix 带来的熔断能力，以下示例使用 SOFARPC 5.5.0 版本，更多 Hystrix 的配置及 SOFABoot 集成使用方式将在后续版本提供，敬请关注。\n准备工作 Hystrix 模块作为可选模块默认不会直接加载，如需要使用，需要先主动加入 Hystrix maven 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.netflix.hystrix\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hystrix-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 通过配置显式开启 Hystrix，将会自动加载 HystrixFilter：\n// 全局开启 RpcConfigs.putValue(HystrixConstants.SOFA_HYSTRIX_ENABLED, true); // 对特定 Consumer 开启 ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); FallbackFactory FallbackFactory 接口主要提供 Fallback 实现的注入能力，用于在 Hystrix 执行出现异常（抛出异常、超时、线程池拒绝和熔断等）时自动执行降级逻辑。\n定义接口 Fallback 实现：\npublic class HelloServiceFallback implements HelloService { @Override public String sayHello(String name, int age) { return \u0026amp;quot;fallback \u0026amp;quot; + name + \u0026amp;quot; from server! age: \u0026amp;quot; + age; } } 注入 Fallback 实现：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setParameter(HystrixConstants.SOFA_HYSTRIX_ENABLED, String.valueOf(true)); // 可以直接使用默认的 FallbackFactory 直接注入 Fallback 实现 SofaHystrixConfig.registerFallback(consumerConfig, new HelloServiceFallback()); // 也可以自定义 FallbackFactory 直接注入 FallbackFactory SofaHystrixConfig.registerFallbackFactory(consumerConfig, new HelloServiceFallbackFactory()); 当服务端响应失败时，客户端会自动触发 Fallback 逻辑执行。\nSetterFactory SetterFactory 提供 Hystrix 细粒度配置能力，SOFARPC 已提供默认的 DefaultSetterFactory 来生成每个调用方对应的 Setter，如有更定制化的述求，也可以针对每个 ConsumerConfig 提供自定义 SetterFactory。\nSofaHystrixConfig.registerSetterFactory(consumerConfig, new CustomSetterFactory()); 默认提供的实现中 GroupKey 为 InterfaceId，CommandKey 为方法的名称。\n支持 Hystrix 的版本信息 SOFARPC: 5.5.0, SOFABoot: 2.5.3。\nSOAF RPC 集成验证 Hystrix 版本：1.5.12。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-hystrix/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7482dc341bf16dd5671634ffa689604a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault-hystrix/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault-hystrix/","summary":"SOFARPC 已集成 Hystrix 提供熔断能力，当前提供第一个预览版。关于 Hystrix 的更多介绍可以参考 Hystrix 官方文档，Hystrix 集成能力主要由 ScienJus 提供，感谢贡献。 接下来介绍一","tags":null,"title":"Hystrix 客户端熔断","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault-hystrix/","wordcount":552},{"author":null,"categories":null,"content":" Installation guide To use Istio in a non-Kubernetes environment, you must complete the following critical tasks first:\n Configure the Istio API server for the Istio control plane. You can also use MemStore to launch Pilot for demonstration purpose. Manually add SOFAMosn to all microservice instances and start in SideCar mode. Make sure that all requests are routed through SOFAMosn. Set control plane The Istio control plane consists of four main services: Pilot, Mixter, Citadel, and API server.\nAPI server Istio\u0026amp;rsquo;s API server, which is based on Kubernetes API server, provides configuration management and role-based access control. The API server requires an etcd cluster as the underlying persistent storage.\nInstall locally Use the following Docker compose file to install an API server for POC:\nversion: \u0026#39;2\u0026#39; services: etcd: image: quay.io/coreos/etcd:latest networks: default: aliases: - etcd ports: - \u0026amp;quot;4001:4001\u0026amp;quot; - \u0026amp;quot;2380:2380\u0026amp;quot; - \u0026amp;quot;2379:2379\u0026amp;quot; environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;/usr/local/bin/etcd\u0026amp;quot;, \u0026amp;quot;-advertise-client-urls=http://0.0.0.0:2379\u0026amp;quot;, \u0026amp;quot;-listen-client-urls=http://0.0.0.0:2379\u0026amp;quot; ] istio-apiserver: image: gcr.io/google_containers/kube-apiserver-amd64:v1.7.3 networks: default: aliases: - apiserver ports: - \u0026amp;quot;8080:8080\u0026amp;quot; privileged: true environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;kube-apiserver\u0026amp;quot;, \u0026amp;quot;--etcd-servers\u0026amp;quot;, \u0026amp;quot;http://etcd:2379\u0026amp;quot;, \u0026amp;quot;--service-cluster-ip-range\u0026amp;quot;, \u0026amp;quot;10.99.0.0/16\u0026amp;quot;, \u0026amp;quot;--insecure-port\u0026amp;quot;, \u0026amp;quot;8080\u0026amp;quot;, \u0026amp;quot;-v\u0026amp;quot;, \u0026amp;quot;2\u0026amp;quot;, \u0026amp;quot;--insecure-bind-address\u0026amp;quot;, \u0026amp;quot;0.0.0.0\u0026amp;quot; ] Other control plane components Currently, SOFAMosn hasn\u0026amp;rsquo;t integrated with the components other than Pilot, so you don\u0026amp;rsquo;t need to install Mixer, Citadel and other components.\nAdd SOFAMosn Sidecar to microservice instances Every microservice application instance must have an associated SOFAMosn instance.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-installation/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4c0bd56673dc8aebef9011a22496392d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","summary":"Installation guide To use Istio in a non-Kubernetes environment, you must complete the following critical tasks first:\n Configure the Istio API server for the Istio control plane. You can also use MemStore to launch Pilot for demonstration purpose. Manually add SOFAMosn to all microservice instances and start in SideCar mode. Make sure that all requests are routed through SOFAMosn. Set control plane The Istio control plane consists of four main services: Pilot, Mixter, Citadel, and API server.","tags":null,"title":"Installation guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/","wordcount":221},{"author":null,"categories":null,"content":" Project address\n Introduction SOFABoot extends the Health Check of Spring Boot. For detailed information, see SOFABoot Documentation. This sample project is intended to demonstrate how to integrate the Health Check component of SOFABoot during merged deployment. Differences between the Health Check in merged deployment and that of a single SOFABoot application are as follows: + During static merged deployment, all Biz packages must pass the Health Check before the Ark package can be started normally. + When deploying the Biz packages dynamically in Jarslink2.0, all packages must pass the Health Check before successful deployment. + In merged deployment, a new check item named multiApplicationHealthChecker will be added when you access Spring Boot\u0026amp;rsquo;s default /health. The item is used to check the health of all Biz packages. Only after all Biz packages pass the Health Check can the merged package pass the Health Check.\nDependency To integrate the Health Check capability of SOFABoot in merged deployment, you need to add the following dependencies:\n\u0026amp;lt;!--health check--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Note that spring-boot-starter-web is excluded to avoid starting multiple web applications when you introduce the healthcheck-sofa-boot-starter dependency.\nDemo cd biz-health-check-sample/app-one \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-one root directory and package the application into an Ark or Biz package. The file will be exported to the biz-health-check-sample/app-one/target directory.\n cd biz-health-check-sample/app-two \u0026amp;amp;\u0026amp;amp; mvn clean package Execute the mvn clean package command in the app-two root directory and package the application into an Ark or Biz package. The file will be exported to the biz-health-check-sample/app-two/target directory.\n Use java -jar to start the Ark package for app-one.\n After the Ark package has started, visit http://localhost:8080/health in the browser. This is Spring Boot\u0026amp;rsquo;s default Health Check endpoint. A new check item named multiApplicationHealthChecker is added in the results and there is now only one Biz package. The page is displayed as follows: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"99832d969ec54b925c3dca1205b95165","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","summary":"Project address\n Introduction SOFABoot extends the Health Check of Spring Boot. For detailed information, see SOFABoot Documentation. This sample project is intended to demonstrate how to integrate the Health Check component of SOFABoot during merged deployment. Differences between the Health Check in merged deployment and that of a single SOFABoot application are as follows: + During static merged deployment, all Biz packages must pass the Health Check before the Ark package can be started normally.","tags":null,"title":"Integrate SOFABoot health check","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/","wordcount":389},{"author":null,"categories":null,"content":" Since rpc-sofa-boot-starter version 6.0.1, SOFARPC provide the ability to integrate RESTful service with Swagger easily.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment and you want to enable Swagger support, first, you need add Swagger dependencies in your pom.xml:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Then you need add a configuration com.alipay.sofa.rpc.restSwagger=true in application.properties.\nFinally, visit http://localhost:8341/swagger/openapi and you can get all the Swagger OpenAPI information about SOFARPC\u0026amp;rsquo;s RESTful services.\nIf you are not using rpc-sofa-boot-starter or the version of rpc-sofa-boot-starter you depends is smaller then 6.0.1, you can integration SOFARPC RESTful service with Swagger by using the following tutorial.\nCurrently, SOFARPC does not provide the ability to integrate RESTful service with Swagger via one click. The ability will be provided in future versions, but you can refer to this document to integrate RESTful service with Swagger in the existing versions of SOFARPC.\nFirst, you need to add Swagger related dependencies into your application. Since SOFARPC\u0026amp;rsquo;s RESTful protocol is based on the JAXRS, so you just need to add Swagger\u0026amp;rsquo;s JAXRS dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; The 20.0 version of Guava was added to resolve Guava version conflict.\nAdd a Swagger RESTful service To enable Swagger to expose SOFARPC\u0026amp;rsquo;s RESTful services through Swagger OpenAPI, we can provide Swagger\u0026amp;rsquo;s OpenAPI services through SOFARPC\u0026amp;rsquo;s RESTful services. First, you need to create a new interface:\n@Path(\u0026amp;quot;swagger\u0026amp;quot;) public interface OpenApiService { @GET @Path(\u0026amp;quot;openapi\u0026amp;quot;) @Produces(\u0026amp;quot;application/json\u0026amp;quot;) String openApi(); } Then provide an implementation class and publish it as a RESTful service of SOFARPC:\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}, interfaceType = OpenApiService.class) public class OpenApiServiceImpl implements OpenApiService, InitializingBean { private OpenAPI openAPI; @Override public String openApi() { return Json.pretty(openAPI); } @Override public void afterPropertiesSet() { List\u0026amp;lt;Package\u0026amp;gt; resources = new ArrayList\u0026amp;lt;\u0026amp;gt;(); Resources.add(this.getClass().getPackage()); // Scan the package of the current class, or scan the packages of other SOFARPC RESTful service …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-swagger/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d068767fe0dd2922eecef69736684be8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","summary":"Since rpc-sofa-boot-starter version 6.0.1, SOFARPC provide the ability to integrate RESTful service with Swagger easily.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment and you want to enable Swagger support, first, you need add Swagger dependencies in your pom.xml:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.swagger.core.v3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;swagger-jaxrs2\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.0.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.guava\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;guava\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;20.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Then you need add a configuration com.alipay.sofa.rpc.restSwagger=true in application.properties.\nFinally, visit http://localhost:8341/swagger/openapi and you can get all the Swagger OpenAPI information about SOFARPC\u0026rsquo;s RESTful services.","tags":null,"title":"Integrate with Swagger","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-swagger/","wordcount":462},{"author":null,"categories":null,"content":"Jarslink2.0 supports receiving dynamic commands at runtime to manage the Biz package lifecycle. Before starting an Ark package that has introduced the Jarslink2.0 plugin, you can send commands through the telnet connection protocol with port 1234. For example, execute telnet ip 1234 to enter the Jarslink2.0 command interface and type \u0026amp;ldquo;help\u0026amp;rdquo; in the interface to obtain all relevant command manuals. Next we will introduce the syntax of each Jarslink2.0 command.\n Install the Biz package: The installation command is used to dynamically deploy of applications. Its syntax is install -b $bizFile. You can replace -b with -biz. All Jarslink2.0 commands must contain either a –b or –biz. The \u0026amp;ldquo;install\u0026amp;rdquo; command has only one parameter, the Biz package URI, which can either be the path of a local file or the link to a remote file, for example, install -b file:///Users/qilong.zql/sample-ark-biz.jar.\n Uninstall the Biz package: The uninstall command is used to close the application. The services released by the application and the resources that it occupied will be destroyed. Command syntax: uninstall -b -n $bizName -v $bizVersion. The command must specify the name and version number of the Biz package by -n and -v, which can be replaced with -name and -version. The name and version number of a Biz package are determined at the time of packaging. For detailed information, see Application Packaging.\n Switch the Biz package: The switch command is used for the Biz package hot update to ensure service continuity. Jarslink2.0 allows loading different versions of Biz packages with the same name at runtime. However, only one Biz package can deliver services at one time. To upgrade the loaded Biz package that is delivering services at runtime, execute the installation command to install a later version of the Biz package. After installation, the newer version is inactive because the older version is providing services. Execute the switch command to switch to the newer version without suspending the services that the application is delivering. This is called a hot update. The command syntax is switch -b -n $bizName -v $bizVersion. Parameters are the same as the above.\n Query the Biz package: The query command is used to query the Biz packages installed in JVM and their status. The command syntax is check -b -n $bizName -v $bizVersion, where the Biz package\u0026amp;rsquo;s name and version number are optional parameters. If you do not specify the name and the version number, information for all Biz packages will be returned. If you only specify the name, information for all versions with the specified name will be returned.\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-instruction/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c7e69fe8035b59c0e191538c8ef3da18","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","summary":"Jarslink2.0 supports receiving dynamic commands at runtime to manage the Biz package lifecycle. Before starting an Ark package that has introduced the Jarslink2.0 plugin, you can send commands through the telnet connection protocol with port 1234. For example, execute telnet ip 1234 to enter the Jarslink2.0 command interface and type \u0026ldquo;help\u0026rdquo; in the interface to obtain all relevant command manuals. Next we will introduce the syntax of each Jarslink2.0 command.","tags":null,"title":"Interactive instruction","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/","wordcount":424},{"author":null,"categories":null,"content":" Introduction Jarslink2.0 is a functional SOFABoot plugin developed based on SOFAArk. It manages the merged deployment of multiple applications on top of the SOFAArk container, with the following features: + It supports runtime dynamic installation and uninstallation of applications. + It supports runtime application hot replacement capability to ensure service continuity. + For cross-application communication, it supports the JVM services publish and reference. Cross-application communication can base on RPC framework or internal JVM services. + It supports application Health Check.\nBackground At Ant Financial, it is common to deploy multiple applications on top of the same JVM. Main advantages of this approach are as follows:\n Merged deployment of unrelated applications: Some applications have no service dependencies on each other when they are deployed independently and their volume of business is small, so it would be a waste of resources to start the Java Virtual Machine just for them. Merged deployment of these applications can save resources.\n Merged deployment of related applications: Some applications have service dependencies between them. When deployed independently, RPC calls are used between applications. Despite the high stability of the distributed architecture, there are still delays caused by network jitter. By merged deployment of these applications, JVM internal calls will replace RPC calls, which reduces the call overhead.\n Not only is there merged deployment between applications, but the near-client package has the same appeal.\nThe near-client package is a three-party component that provides a series of public services, normally introduced by the application as a dependency. This development mode is likely to cause two problems:\n The three-party dependency that is introduced by the near-client package conflicts with the dependency of the application itself, so an isolated deployment is expected.\n Since the near-client package is introduced by the application as a dependency, any upgrade of the near-client package will require upgrade of the application as well. However, as a common functional component, many business applications rely on the near-client package as a dependency, which entails a huge amount of transformation. Consequently, a dynamic upgrade of the near-client package is expected.\n In addition to merged deployment, many Ant Financial business scenarios require hot deployment of modules, that is, when the application is running, a specific module needs to be dynamically replaced without affecting the normal running of other modules.\nJarslink2.0 is designed to solve such problems. It is an Ark Plugin developed based on SOFAArk and used to manage the merged deployment of multiple applications. Before getting to know Jarslink2.0, you need to understand the SOFAArk framework. For detailed information of SOFAArk, visit the link.\nPrinciple Jarslink2.0 is an Ark Plugin developed based on SOFAArk. Assuming that you …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-readme/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"48a4bc23f10f1ecca3960aecfd0a77d5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","summary":"Introduction Jarslink2.0 is a functional SOFABoot plugin developed based on SOFAArk. It manages the merged deployment of multiple applications on top of the SOFAArk container, with the following features: + It supports runtime dynamic installation and uninstallation of applications. + It supports runtime application hot replacement capability to ensure service continuity. + For cross-application communication, it supports the JVM services publish and reference. Cross-application communication can base on RPC framework or internal JVM services.","tags":null,"title":"Introduction to Jarslink","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/","wordcount":651},{"author":null,"categories":null,"content":" Pilot introduction The SOFAMesh project forked the Istio project to enhance Pilot\u0026amp;rsquo;s capabilities. Currently, the ongoing enhancements are focused on the following three areas:\n Support ZooKeeper as a registry center, and support SOFA, DUBBO and other microservice frameworks using ZooKeeper as a registry center. Support the common protocol framework. Use a common protocol, and support multiple protocols simultaneously based on Kubernetes DNS. Add register agent to support the container models of SOFA, Dubbo and HSF. Namely, a single application can register multiple service instances. ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-readme/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7b098e394986596d8fb01e1fe2120829","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","summary":"Pilot introduction The SOFAMesh project forked the Istio project to enhance Pilot\u0026rsquo;s capabilities. Currently, the ongoing enhancements are focused on the following three areas:\n Support ZooKeeper as a registry center, and support SOFA, DUBBO and other microservice frameworks using ZooKeeper as a registry center. Support the common protocol framework. Use a common protocol, and support multiple protocols simultaneously based on Kubernetes DNS. Add register agent to support the container models of SOFA, Dubbo and HSF.","tags":null,"title":"Introduction to Pilot","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-readme/","wordcount":84},{"author":null,"categories":null,"content":" ## Product description SOFAArk is a light-weight，java based classloader isolation framework open sourced by Ant Financial. Based on Fat Jar technology, the container can pack simple single-module Java applications or Spring Boot applications into a self-contained executable Fat Jar, known as an Ark package. When the java -jar command is used to start an Ark package embedded with the SOFAArk class isolation container, the SOFAArk container will start, and it then starts each Ark plugin and application. If you want to merge multi app into one jvm, please go and refer to koupleless which based on SOFAArk; if you want to just isolate class by classLoader then you can read docs in this site, and focus on sofaArk Plugin.\nBackground In Java world, dependency is always a problem, and can cause various errors, such as LinkageError, NoSuchMethodError etc. There are many ways to solve the dependency problems, the Spring Boot\u0026amp;rsquo;s way is using a dependency management to manage all the dependencies, make sure that all the dependencies in the dependency management will not conflict and can work pretty well. This is quite a simple and efficient way, it can cover most scenario, but there is some exceptions.\nFor example, there is a project that need protobuf version 2 and protobuf version 3, and because protobuf version 3 is not compatible with version 2, so the project can not simply upgrade the protobuf to version 3 to solve the problem. There is same problem for hessian version 3 and version 4.\nTo cover those exceptions, we need to introduce a classloader isolation way, make different version of a framework loaded by different classloader. There are many framework that can do classloader isolation, perhaps the most famous one is OSGi, but OSGi classloader schema is too complex, beside classloader isolation, it also has ability to do hot deploy and a lot of other functionalities that we actually don\u0026amp;rsquo;t want.\nSo this is the origin of SOFAArk, it\u0026amp;rsquo;s goal is to use a light-weight classloader isolation mechanism to solve the problem that Spring Boot did not solve. And just a remind that SOFAArk is not bind to Spring Boot, actually it is a more general classloader isolation framework that can be used with any other frameworks too.\nHow SOFAArk Works There are three concepts in SOFAArk: Ark Container, Ark-Plugin and Ark-Biz; they are organized as what the following graph shows:\n First of all, we explain what roles these concepts play;\n Ark Container: It\u0026amp;rsquo;s the runtime manager of total framework; it will startup in the first place, then it resolves Ark Plugin and Ark Biz in classpath and deploys them.\n Ark Plugin: A fat jar packaged by sofa-ark-plugin-maven-plugin, generally it would bring with a class-index configuration which describes what class would be exported and imported. Ark Plugin can resolve classes from each other.\n Ark Biz: A fat jar packaged by sofa-ark-maven-plugin, it mainly contains all staff what a project need in runtime. Ark Biz …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-readme/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"cdb6729fc7a63954b7559c8ea319f550","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","summary":"## Product description SOFAArk is a light-weight，java based classloader isolation framework open sourced by Ant Financial. Based on Fat Jar technology, the container can pack simple single-module Java applications or Spring Boot applications into a self-contained executable Fat Jar, known as an Ark package. When the java -jar command is used to start an Ark package embedded with the SOFAArk class isolation container, the SOFAArk container will start, and it then starts each Ark plugin and application.","tags":null,"title":"Introduction to SOFAArk","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/","wordcount":684},{"author":null,"categories":null,"content":" MOSN, the short name of Modular Observable Smart Network, is a powerful proxy acting as Service Mesh\u0026amp;rsquo;s data plane like Envoy but written in Go. MOSN supports Envoy and Istio\u0026amp;rsquo;s APIs and can be integrated with Istio, so we use MOSN instead of Envoy in SOFAMesh. The initial version of MOSN was jointly contributed by Ant Financial and UC Business Unit of Alibaba, and we look forward to the community to participate in the follow-up development and build an open source excellent project together.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/sofa-mosn-readme/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"11219bb3b9689ec5f328b8281bd62a95","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","summary":"MOSN, the short name of Modular Observable Smart Network, is a powerful proxy acting as Service Mesh\u0026rsquo;s data plane like Envoy but written in Go. MOSN supports Envoy and Istio\u0026rsquo;s APIs and can be integrated with Istio, so we use MOSN instead of Envoy in SOFAMesh. The initial version of MOSN was jointly contributed by Ant Financial and UC Business Unit of Alibaba, and we look forward to the community to participate in the follow-up development and build an open source excellent project together.","tags":null,"title":"Introduction to SOFAMosn","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/","wordcount":223},{"author":null,"categories":null,"content":" Introduction to RheaKV RheaKV is a lightweight, distributed, and embedded KV storage library, which is included in the JRaft project as a submodule.\nFeatures\n Embedded: RheaKV is embedded in applications in the form of Jar files. Strong consistency: RheaKV ensures data reliability and consistency based on the multi-raft distributed consensus protocol. Self-driven (not fully implemented at present): RheaKV supports automatic diagnosis, optimization, decision making, and recovery. Monitorable: RheaKV automatically reports meta information and state information by node to the PD. Basic APIs: get, put, and delete; cross-region APIs: scan, batch put, and distributed lock. Architecture design Terms and definitions PD: The global central master node that is responsible for scheduling the entire cluster. A PD server can manage multiple clusters, with each of them isolated by clusterId. The PD server requires separate deployment. Actually, many scenarios do not need automatic cluster management, and RheaKV does not support PD. Store: A physical storage node within a cluster. A store may contain one or more regions. Region: The minimal KV data unit. Each region can be understood as a database partition or database shard, and has a left closed and right open interval [startKey, endKey). Storage design The storage layer adopts a pluggable design and supports both MemoryDB and RocksDB currently: MemoryDB is implemented based on ConcurrentSkipListMap and provides better performance. However, its independent storage capacity is restricted by the memory. RocksDB is suitable for scenarios with large data volumes, because its storage capacity is only restricted by the disk. Strong data consistency is ensured. RheaKV synchronizes data to other replicas with the help of JRaft, and each data change is recorded as a Raft log entry. The log replication feature of Raft ensures all data is securely and reliably synchronized to all nodes within the same Raft group. Scenarios Lightweight state/meta information storage and cluster synchronization Distributed lock service API description Generally, RheaKV APIs are divided into two types: synchronous APIs and asynchronous APIs. Methods whose names start with letter b (block) are synchronous blocking APIs, and the rest are asynchronous APIs. All asynchronous APIs return the same CompletableFuture parameter. The read method may contain another important parameter, that is readOnlySafe. When this parameter is set to true, linearizable read is supported. Read methods that do not contain this parameter provide linearizable read by default.\nget CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key, final boolean readOnlySafe); byte[] bGet(final byte[] key); byte[] bGet(final String key); byte[] bGet(final byte[] key, final boolean …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-rheakv-user-guide/","fuzzywordcount":4100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e6fa7125455982961214dfe82245be4d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":20,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","summary":"Introduction to RheaKV RheaKV is a lightweight, distributed, and embedded KV storage library, which is included in the JRaft project as a submodule.\nFeatures\n Embedded: RheaKV is embedded in applications in the form of Jar files. Strong consistency: RheaKV ensures data reliability and consistency based on the multi-raft distributed consensus protocol. Self-driven (not fully implemented at present): RheaKV supports automatic diagnosis, optimization, decision making, and recovery. Monitorable: RheaKV automatically reports meta information and state information by node to the PD.","tags":null,"title":"JRaft RheaKV user guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/","wordcount":4086},{"author":null,"categories":null,"content":" RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 lib， rheaKV 包含在 jraft 项目中，是 jraft 的一个子模块。\n定位与特性\n 嵌入式: jar 包方式嵌入到应用中 强一致性: 基于 multi-raft 分布式一致性协议保证数据可靠性和一致性 自驱动 （目前未完全实现）: 自诊断, 自优化, 自决策, 自恢复 可监控: 基于节点自动上报到PD的元信息和状态信息 基本API: get/put/delete 和跨分区 scan/batch put, distributed lock 等等 架构设计 功能名词 PD: 全局的中心总控节点，负责整个集群的调度，一个 PD server 可以管理多个集群，集群之间基于 clusterId 隔离；PD server 需要单独部署，当然，很多场景其实并不需要自管理，rheaKV 也支持不启用 PD Store: 集群中的一个物理存储节点，一个 store 包含一个或多个 region Region: 最小的 KV 数据单元，可理解为一个数据分区或者分片，每个 region 都有一个左闭右开的区间 [startKey, endKey) 存储设计 存储层为可插拔设计， 目前支持 MemoryDB 和 RocksDB 两种实现： MemoryDB 基于 ConcurrentSkipListMap 实现，有更好的性能，但是单机存储容量受内存限制 RocksDB 在存储容量上只受磁盘限制，适合更大数据量的场景 数据强一致性， 依靠 jraft 来同步数据到其他副本, 每个数据变更都会落地为一条 raft 日志, 通过 raft 的日志复制功能, 将数据安全可靠地同步到同 group 的全部节点中 使用场景 轻量级的状态/元信息存储以及集群同步 分布式锁服务 API 说明 整体上 rheaKV apis 分为异步和同步两类， 其中以 b （block）开头的方法均为同步阻塞方法， 其他为异步方法，异步方法均返回一个 CompletableFuture，对于 read method， 还有一个重要参数 readOnlySafe，为 true 时表示提供线性一致读， 不包含该参数的 read method 均为默认提供线性一致读\nget CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final byte[] key, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;byte[]\u0026amp;gt; get(final String key, final boolean readOnlySafe); byte[] bGet(final byte[] key); byte[] bGet(final String key); byte[] bGet(final byte[] key, final boolean readOnlySafe); byte[] bGet(final String key, final boolean readOnlySafe); String 类型入参，rheaKV 内部提供了更高效的 Utf8String encoder/decoder， 业务 key 为 String 时， 推荐的做法是直接使用 String 参数的接口 不需要线性一致读语义的场景可以将 readOnlySafe 设置为 false， 负载均衡器会优先选择本地调用，本地不能提供服务则轮询选择一台远程机器发起读请求 multiGet CompletableFuture\u0026amp;lt;Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt;\u0026amp;gt; multiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys); CompletableFuture\u0026amp;lt;Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt;\u0026amp;gt; multiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys, final boolean readOnlySafe); Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt; bMultiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys); Map\u0026amp;lt;ByteArray, byte[]\u0026amp;gt; bMultiGet(final List\u0026amp;lt;byte[]\u0026amp;gt; keys, final boolean readOnlySafe); multiGet 支持跨分区查询，rheaKV 内部会自动计算每个 key 的所属分区（region）并行发起调用， 最后合并查询结果 为了可以将 byte[] 放进 HashMap，这里曲线救国，返回值中 Map 的 key 为 ByteArray 对象，是对 byte[] 的一层包装，实现了 byte[] 的 hashCode scan \u0026amp;amp; iterator CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final byte[] startKey, final byte[] endKey); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final String startKey, final String endKey); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final byte[] startKey, final byte[] endKey, final boolean readOnlySafe); CompletableFuture\u0026amp;lt;List\u0026amp;lt;KVEntry\u0026amp;gt;\u0026amp;gt; scan(final String startKey, final String endKey, final boolean readOnlySafe); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final byte[] startKey, final byte[] endKey); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final String startKey, final String endKey); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final byte[] startKey, final byte[] endKey, final boolean readOnlySafe); List\u0026amp;lt;KVEntry\u0026amp;gt; bScan(final String startKey, final String endKey, final boolean readOnlySafe); RheaIterator\u0026amp;lt;KVEntry\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-rheakv-user-guide/","fuzzywordcount":6500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e6fa7125455982961214dfe82245be4d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":13,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","summary":"RheaKV 是一个轻量级的分布式的嵌入式的 KV 存储 lib， rheaKV 包含在 jraft 项目中，是 jraft 的一个子模块。 定位与特性 嵌入式: jar 包方式嵌入到应用中 强一致性: 基于 multi-raft 分布","tags":null,"title":"JRaft RheaKV 用户指南","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/","wordcount":6408},{"author":null,"categories":null,"content":" 0. Basic concepts Every request submitted by log index to a Raft group is serialized into a log entry. Each log entry has an ID, which monotonically increases within the Raft group, and the log entries are replicated to every Raft node in the group. Term is a long-type number that monotonically increases within the Raft group. You can simply take it as the number of votes. The term of an elected leader is called the leader term. Before this leader steps down, log entries submitted during this period have the same term. 1. Configuration and supporting classes This topic mainly describes the configuration and utility methods and classes. The core objects are:\n Endpoint, which refers to a service address PeerId, which refers to ID of a Raft node Configuration, which refers to the configuration of a Raft group, or a node list in other words. 1.1 Endpoint Endpoint refers to a service address, including the IP address and the port number. Raft nodes must not be started on the IPv4 address 0.0.0.0. The startup IP address must be clearly specified Create a address, and bind it to port 8080 of the local host, as shown in the following example:\nEndpoint addr = new Endpoint(\u0026amp;quot;localhost\u0026amp;quot;, 8080); String s = addr.toString(); // The result is localhost:8080 PeerId peer = new PeerId(); boolean success = peer.parse(s); // Specifies whether parsing the endpoint from a string is supported. The result is true. 1.2 PeerId A PeerId indicates a participant (leader, follower, or candidate) of the Raft protocol. It comprises three elements in the format of ip:port:index, where ip is the IP address of the node, port is the port number, and index is the serial number of the same port. Currently, the index is not used, and is always set to 0. This field is reserved to allow starting different Raft nodes from the same port and to differentiate them by index.\nCreate a PeerId and set the index to 0, the IP to localhost, and the port to 8080:\nPeerId peer = new PeerId(\u0026amp;quot;localhost\u0026amp;quot;, 8080); EndPoint addr = peer.getEndpoint(); // Gets the endpoint of a node int index = peer.getIdx(); // Gets the index of a node, which is always set to 0 currently String s = peer.toString(); // The result is localhost:8080 boolean success = peer.parse(s); // Specifies whether PeerId parsing from a string is supported. The result is true. 1.3 Configuration It refers to the configuration of a Raft group, or a participant list in other words.\nPeerId peer1 = ... PeerId peer2 = ... PeerId peer3 = ... // A Raft group that consists of three nodes Configuration conf = new Configuration(); conf.addPeer(peer1); conf.addPeer(peer2); conf.addPeer(peer3); 1.4 JRaftUtils utility class To enable users conveniently create objects such as Endpoint, PeerId, and Configuration, Jraft provides the JRaftUtils class to help users quickly create the required objects from strings.\nEndpoint addr = JRaftUtils.getEndpoint(\u0026amp;quot;localhost:8080\u0026amp;quot;); PeerId peer = …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-user-guide/","fuzzywordcount":8400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"105dfa34c3b20df1f2c23c112730507d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":39,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","summary":"0. Basic concepts Every request submitted by log index to a Raft group is serialized into a log entry. Each log entry has an ID, which monotonically increases within the Raft group, and the log entries are replicated to every Raft node in the group. Term is a long-type number that monotonically increases within the Raft group. You can simply take it as the number of votes. The term of an elected leader is called the leader term.","tags":null,"title":"JRaft user guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/","wordcount":8306},{"author":null,"categories":null,"content":" 1. 基本概念说明 log index 提交到 raft group 中的任务都将序列化为一条日志存储下来，每条日志一个编号，在整个 raft group 内单调递增并复制到每个 raft 节点。 term 在整个 raft group 中单调递增的一个 long 数字，可以简单地认为表示一轮投票的编号，成功选举出来的 leader 对应的 term 称为 leader term，在这个 leader 没有发生变更的阶段内提交的日志都将拥有相同的 term 编号。 2. 配置和辅助类 本节主要介绍 jraft 的配置和辅助工具相关接口和类。核心包括：\n Endpoint 表示一个服务地址。 PeerId 表示一个 raft 参与节点。 Configuration 表示一个 raft group 配置，也就是节点列表。 2.1 地址 Endpoint Endpoint 表示一个服务地址，包括 IP 和端口， raft 节点不允许启动在 0.0.0.0 所有的 IPv4 上，需要明确指定启动的 IP 创建一个地址，绑定在 localhost 的 8080 端口上，如下例：\nEndpoint addr = new Endpoint(\u0026amp;quot;localhost\u0026amp;quot;, 8080); String s = addr.toString(); // 结果为 localhost:8080 PeerId peer = new PeerId(); boolean success = peer.parse(s); // 可以从字符串解析出地址，结果为 true 2.2 节点 PeerId PeerId 表示一个 raft 协议的参与者（leader/follower/candidate etc.)， 它由三元素组成： ip:port:index， IP 就是节点的 IP， port 就是端口， index 表示同一个端口的序列号，目前没有用到，总被认为是 0。预留此字段是为了支持同一个端口启动不同的 raft 节点，通过 index 区分。\n创建一个 PeerId, index 指定为 0， ip 和端口分别是 localhost 和 8080:\nPeerId peer = new PeerId(\u0026amp;quot;localhost\u0026amp;quot;, 8080); Endpoint addr = peer.getEndpoint(); // 获取节点地址 int index = peer.getIdx(); // 获取节点序号，目前一直为 0 String s = peer.toString(); // 结果为 localhost:8080 boolean success = peer.parse(s); // 可以从字符串解析出 PeerId，结果为 true 2.3 配置 Configuration Configuration 表示一个 raft group 的配置，也就是参与者列表：\nPeerId peer1 = ... PeerId peer2 = ... PeerId peer3 = ... // 由 3 个节点组成的 raft group Configuration conf = new Configuration(); conf.addPeer(peer1); conf.addPeer(peer2); conf.addPeer(peer3); 2.4 工具类 JRaftUtils 为了方便创建 Endpoint/PeerId/Configuration 等对象， jraft 提供了 JRaftUtils 来快捷地从字符串创建出所需要的对象：\nEndpoint addr = JRaftUtils.getEndpoint(\u0026amp;quot;localhost:8080\u0026amp;quot;); PeerId peer = JRaftUtils.getPeerId(\u0026amp;quot;localhost:8080\u0026amp;quot;); // 三个节点组成的 raft group 配置，注意节点之间用逗号隔开 Configuration conf = JRaftUtils.getConfiguration(\u0026amp;quot;localhost:8081,localhost:8082,localhost:8083\u0026amp;quot;); 2.5 回调 Closure 和状态 Status Closure 就是一个简单的 callback 接口， jraft 提供的大部分方法都是异步的回调模式，结果通过此接口通知：\npublic interface Closure { /** * Called when task is done. * * @param status the task status. */ void run(Status status); } 结果通过 Status 告知，Status#isOk() 告诉你成功还是失败，错误码和错误信息可以通过另外两个方法获取：\nboolean success= status.isOk(); RaftError error = status.getRaftError(); // 错误码，RaftError 是一个枚举类 String errMsg = status.getErrorMsg(); // 获取错误详情 Status 提供了一些方法来方便地创建：\n// 创建一个成功的状态 Status ok = Status.OK(); // 创建一个失败的错误，错误信息支持字符串模板 String filePath = \u0026amp;quot;/tmp/test\u0026amp;quot;; Status status = new Status(RaftError.EIO, \u0026amp;quot;Fail to read file from %s\u0026amp;quot;, filePath); 2.6 任务 Task Task 是用户使用 jraft 最核心的类之一，用于向一个 raft 复制分组提交一个任务，这个任务提交到 leader，并复制到其他 follower 节点， Task 包括：\n ByteBuffer data 任务的数据，用户应当将要复制的业务数据通过一定序列化方式（比如 java/hessian2) 序列化成一个 ByteBuffer，放到 task 里。 long expectedTerm = -1 任务提交时预期的 leader term，如果不提供(也就是默认值 -1 )，在任务应用到状态机之前不会检查 leader 是否发生了变更，如果提供了（从状态机回调中获取，参见下文），那么在将任务应用到状态机之前，会检查 term 是否匹配，如果不匹配将拒绝该任务。 Closure done 任务的回调，在任务完成的时候通知此对象，无论成功还是失败。这个 closure 将在 StateMachine#onApply(iterator) 方法应用到状态机的时候，可以拿到并调用，一般用于客户端应答的返回。 创建一个简单 Task 实例：\nClosure done = ...; Task task = new …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jraft-user-guide/","fuzzywordcount":13200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"105dfa34c3b20df1f2c23c112730507d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":27,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","summary":"1. 基本概念说明 log index 提交到 raft group 中的任务都将序列化为一条日志存储下来，每条日志一个编号，在整个 raft group 内单调递增并复制到每个 raft 节点。 term 在整个 raft group 中单","tags":null,"title":"JRaft 用户指南","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jraft-user-guide/","wordcount":13134},{"author":null,"categories":null,"content":" SOFABoot 提供三种方式给开发人员发布和引用 JVM 服务\n XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean：\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上面的 Bean 发布成一个 SOFA JVM 服务。\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 上面的配置中的 interface 指的是需要发布成服务的接口，ref 指向的是需要发布成 JVM 服务的 Bean，至此，我们就已经完成了一个 JVM 服务的发布。\n服务引用 使用 SOFA 提供的 Spring 扩展标签引用服务:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 上面的配置中的 interface 是服务的接口，需要和发布服务时配置的 interface 一致。id 属性的含义同 Spring BeanId。上面的配置会生成一个 id 为 sampleServiceRef 的 Spring Bean，你可以将 sampleServiceRef 这个 Bean 注入到当前 SOFABoot 模块 Spring 上下文的任意地方。\n service/reference 标签还支持 RPC 服务发布，相关文档: RPC 服务发布与引用\n Annotation 方式 警告\n如果一个服务已经被加上了 @SofaService 的注解，它就不能再用 XML 的方式去发布服务了，选择一种方式发布服务，而不是两种混用。\n 除了通过 XML 方式发布 JVM 服务和引用之外，SOFABoot 还提供了 Annotation 的方式来发布和引用 JVM 服务。通过 Annotation 方式发布 JVM 服务，只需要在实现类上加一个 @SofaService 注解即可，如下：\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } 提示\n@SofaService 的作用是将一个 Bean 发布成一个 JVM 服务，这意味着虽然你可以不用再写 \u0026amp;lt;sofa:service/\u0026amp;gt; 的配置，但是还是需要事先将 @SofaService 所注解的类配置成一个 Spring Bean。\n 在使用 XML 配置 \u0026amp;lt;sofa:service/\u0026amp;gt; 的时候，我们配置了一个 interface 属性，但是在使用 @SofaService 注解的时候，却没有看到有配置服务接口的地方。这是因为当被 @SofaService 注解的类只有一个接口的时候，框架会直接采用这个接口作为服务的接口。当被 @SofaService 注解的类实现了多个接口时，可以设置 @SofaService 的 interfaceType 字段来指定服务接口，比如下面这样：\n@SofaService(interfaceType=SampleInterface.class) public class SampleImpl implements SampleInterface, Serializable { public void test() { } } 和 @SofaService 对应，Sofa 提供了 @SofaReference 来引用一个 JVM 服务。假设我们需要在一个 Spring Bean 中使用 SampleJvmService 这个 JVM 服务，那么只需要在字段上加上一个 @SofaReference 的注解即可：\npublic class SampleServiceRef { @SofaReference private SampleService sampleService; } 和 @SofaService 类似，我们也没有在 @SofaReference 上指定服务接口，这是因为 @SofaReference 在不指定服务接口的时候，会采用被注解字段的类型作为服务接口，你也可以通过设定 @SofaReference 的 interfaceType 属性来指定：\npublic class SampleServiceRef { @SofaReference(interfaceType=SampleService.class) private SampleService sampleService; } 使用 @SofaService 注解发布服务时，需要在实现类上打上 @SofaService 注解；在 Spring Boot 使用 Bean Method 创建 Bean 时，会导致 @Bean 和 @SofaService 分散在两处，而且无法对同一个实现类使用不同的 unique id。因此自 SOFABoot v2.6.0 及 v3.1.0 版本起，支持 @SofaService 作用在 Bean Method 之上，例如：\n@Configuration public class SampleSofaServiceConfiguration { @Bean(\u0026amp;quot;sampleSofaService\u0026amp;quot;) @SofaService(uniqueId = \u0026amp;quot;service1\u0026amp;quot;) SampleService service() { return new SampleServiceImpl(\u0026amp;quot;\u0026amp;quot;); } } 同样为了方便在 Spring Boot Bean Method 使用注解 @SofaReference 引用服务，自 SOFABoot v2.6.0 及 v3.1.0 版本起，支持在 Bean Method 参数上使用 @SofaReference 注解引用 JVM 服务，例如：\n@Configuration public class MultiSofaReferenceConfiguration { @Bean(\u0026amp;quot;sampleReference\u0026amp;quot;) TestService …","date":-62135596800,"description":"","dir":"projects/sofa-boot/module-service/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"527472fbe57ce450e4e2b41d878704cb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/module-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/module-service/","summary":"SOFABoot 提供三种方式给开发人员发布和引用 JVM 服务 XML 方式 Annotation 方式 编程 API 方式 XML 方式 服务发布 首先需要定义一个 Bean： \u0026lt;bean id=\u0026quot;sampleService\u0026quot; class=\u0026quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026quot;\u0026gt; 然后通过 SOFA 提供的 Spring 扩展标签来将上","tags":null,"title":"JVM 服务发布与引用","type":"projects","url":"/sofastack.tech/projects/sofa-boot/module-service/","wordcount":1926},{"author":null,"categories":null,"content":" 1. Create a Maven project and import the dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. Create the SOFARegistry client instance The key code for creating the SOFARegistry client instance is as follows:\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); Properties related to SOFARegistry are specified by the DefaultRegistryClientConfigBuilder class, which provides the following key properties:\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } Property Type Description instanceId String The ID of the instance. Default value: DEFAULT_INSTANCE_ID. The same instance ID must be used for data publishing and subscription. The unique data identifier consists of dataId+group+instanceId. zone String The zone where the instance is located. Default value: DEFAULT_ZONE. registryEndpoint String The endpoint of any session node of the servers. registryEndpointPort Integer The session.server.httpServerPort configured for a session node. Default value: 9603. dataCenter String The data center of SOFARegistry. Default value: DefaultDataCenter. appName String The name of the app that accesses SOFARegistry. connectTimeout Integer Specifies the timeout for establishing a connection with a server. Default value: 3000 ms. socketTimeout Integer Specifies the timeout for accessing the servers\u0026amp;rsquo; REST API. Default value: 3000 ms. invokeTimeout Integer Specifies the timeout for calling services on the servers. Default value: 1000 ms. recheckInterval Integer Specifies the interval for checking the task queue. Default value: 500 ms. observerThreadCoreSize Integer Specifies the number of core threads in the thread pool that process data pushed from the servers. Default value: 5. observerThreadMaxSize Integer Specifies the maximum number of threads in the thread pool that process data pushed from the servers. Default value: 10. observerThreadQueueLength Integer Specifies the maximum thread queue length of the thread pool that processes data pushed from the servers. Default value: 1000. syncConfigRetryInterval Integer Specifies the retry interval to synchronize the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/java-sdk/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"32cff5cc5d89ffa85b12c207a1c0c6f3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/java-sdk/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/java-sdk/","summary":"1. Create a Maven project and import the dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. Create the SOFARegistry client instance The key code for creating the SOFARegistry client instance is as follows:\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); Properties related to SOFARegistry are specified by the DefaultRegistryClientConfigBuilder class, which provides the following key properties:\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } Property Type Description instanceId String The ID of the instance.","tags":null,"title":"Java SDK","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/java-sdk/","wordcount":890},{"author":null,"categories":null,"content":" 1. Maven 坐标 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. 创建 SOFARegistry 客户端实例 构建 SOFARegistry 客户端实例的关键代码如下：\nRegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); 其中注册中心相关的属性通过 DefaultRegistryClientConfigBuilder 构建指定，该类包含以下关键属性：\npublic class DefaultRegistryClientConfigBuilder { private String instanceId; private String zone = DEFAULT_ZONE; private String registryEndpoint; private int registryEndpointPort = 9603; private String dataCenter = DEFAULT_DATA_CENTER; private String appName; private int connectTimeout = 3000; private int socketTimeout = 3000; private int invokeTimeout = 1000; private int recheckInterval = 500; private int observerThreadCoreSize = 5; private int observerThreadMaxSize = 10; private int observerThreadQueueLength = 1000; private int syncConfigRetryInterval = 30000; } 属性名 属性类型 描述 instanceId String 实例ID，发布订阅时需要使用相同值，数据唯一标识由dataId+group+instanceId组成，默认值 DEFAULT_INSTANCE_ID。 zone String 单元化所属 zone，默认值 DEFAULT_ZONE。 registryEndpoint String 服务端任一 Session 节点地址。 registryEndpointPort int Session 节点配置的 session.server.httpServerPort 端口值，默认值 9603。 dataCenter String 数据中心，默认值 DefaultDataCenter。 appName String 应用名。 connectTimeout int 与服务端建立连接超时时间，默认值 3000ms。 socketTimeout int 访问服务端 REST 接口超时时间，默认值 3000ms。 invokeTimeout int 调用服务端服务超时时间，默认值 1000ms。 recheckInterval int 检测任务队列间隔时间，默认值 500ms。 observerThreadCoreSize int 处理服务端推送数据线程池核心线程大小，默认值 5。 observerThreadMaxSize int 处理服务端推送数据线程池最大线程大小，默认值 10。 observerThreadQueueLength int 处理服务端推送数据线程池队列大小，默认值 1000。 syncConfigRetryInterval int 同步服务端列表间隔时间，默认值 30000ms。 3. 发布数据 发布数据的关键代码如下：\n// 构造发布者注册表 PublisherRegistration registration = new PublisherRegistration(\u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;); registration.setGroup(\u0026amp;quot;TEST_GROUP\u0026amp;quot;); registration.setAppName(\u0026amp;quot;TEST_APP\u0026amp;quot;); // 将注册表注册进客户端并发布数据 Publisher publisher = registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); // 如需覆盖上次发布的数据可以使用发布者模型重新发布数据 publisher.republish(\u0026amp;quot;10.10.1.1:12200?xx=zz\u0026amp;quot;); 发布数据的关键是构造 PublisherRegistration，该类包含三个属性：\n 属性名 属性类型 描述 dataId String 数据ID，发布订阅时需要使用相同值，数据唯一标识由 dataId + group + instanceId 组成。 group String 数据分组，发布订阅时需要使用相同值，数据唯一标识由 dataId + group + instanceId 组成，默认值 DEFAULT_GROUP。 appName String 应用 appName。 4. 订阅数据 订阅数据的关键代码如下：\n// 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { @Override public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, …","date":-62135596800,"description":"","dir":"projects/sofa-registry/java-sdk/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"32cff5cc5d89ffa85b12c207a1c0c6f3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/java-sdk/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/java-sdk/","summary":"1. Maven 坐标 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. 创建 SOFARegistry 客户端实例 构建 SOFARegistry 客户端实例的关键代码如下： RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026quot;127.0.0.1\u0026quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); 其中注册中心相关的属性通过 DefaultRegistryClientConfigBuilder 构建指定，该类包含以下关","tags":null,"title":"Java SDK","type":"projects","url":"/sofastack.tech/projects/sofa-registry/java-sdk/","wordcount":1368},{"author":null,"categories":null,"content":"In addition to hundreds of unit tests and some chaos tests, SOFAJRaft also uses a distributed verification and fault injection testing framework Jepsen to simulate many cases, and has passed all these tests:\n Randomized partitioning with two partitions: a big one and a small one Randomly adding and removing nodes Randomly stopping and starting nodes Randomly kill -9 and starting nodes Randomly dividing a cluster into two groups, with one node connection the two to simulate network partitioning Randomly dividing a cluster into different majority groups sofa-jraft-jepsen project address\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jepson-test/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c60bc5083fdf888f6eef5b344b1ad157","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jepson-test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/jepson-test/","summary":"In addition to hundreds of unit tests and some chaos tests, SOFAJRaft also uses a distributed verification and fault injection testing framework Jepsen to simulate many cases, and has passed all these tests:\n Randomized partitioning with two partitions: a big one and a small one Randomly adding and removing nodes Randomly stopping and starting nodes Randomly kill -9 and starting nodes Randomly dividing a cluster into two groups, with one node connection the two to simulate network partitioning Randomly dividing a cluster into different majority groups sofa-jraft-jepsen project address","tags":null,"title":"Jepsen tests","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/jepson-test/","wordcount":89},{"author":null,"categories":null,"content":"除了几百个单元测试以及部分 chaos 测试之外, SOFAJRaft 还使用 jepsen 这个分布式验证和故障注入测试框架模拟了很多种情况，都已验证通过：\n 随机分区，一大一小两个网络分区 随机增加和移除节点 随机停止和启动节点 随机 kill -9 和启动节点 随机划分为两组，互通一个中间节点，模拟分区情况 随机划分为不同的 majority 分组 sofa-jraft-jepsen 项目地址\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/jepson-test/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c60bc5083fdf888f6eef5b344b1ad157","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jepson-test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/jepson-test/","summary":"除了几百个单元测试以及部分 chaos 测试之外, SOFAJRaft 还使用 jepsen 这个分布式验证和故障注入测试框架模拟了很多种情况，都已验证通过： 随机分区，一大一小两个网络分","tags":null,"title":"Jepsen 验证","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/jepson-test/","wordcount":137},{"author":null,"categories":null,"content":"In the Interactive Instructions section, we have described the set of instructions that Jarslink2.0 supports. In this section, we will focus on all the possible state transitions behind these instructions in the following diagram of a Biz package being loaded from a static file to the runtime and to being uninstalled.\nThe diagram above basically shows the complete life cycle of a Biz package. Now we will explain the direction of each state transition in the diagram:\n Label 1: Execute the install instruction, and Jarslink2.0 will resolve the file format. If the format is correct, it is the Biz package file, and the Biz package will be registered and installed.\n Label 2: When the Biz package is successfully installed, the Biz package\u0026amp;rsquo;s main function is executed, the Spring context is loaded successfully, and passes the health check. If Biz packages with the same name but different versions are detected to be activated, the Biz package state will be set to an inactive state. The JVM services that are published by an inactive Biz package will not be called.\n Label 3: When the Biz package is successfully installed, the Biz package\u0026amp;rsquo;s main function is executed, the Spring context is loaded successfully, and passes the health check. If Biz packages with the same name but different versions are detected to be activated, the Biz package state will be set as active and can provide services.\n Label 4: If there are any exceptions or a health check failure, the Biz package state will be set to broken. During the installation, the resources that the Biz package occupies will be quickly released and unregistered, at which point the Biz state will be set to unresolved.\n Label 5: When running, Jarslink2.0 can load Biz packages with the same name but different versions, but only one Biz package is in the active state and can provide services. Execute the switch instruction, and the two Biz packages\u0026amp;rsquo; states will be interchanged.\n Label 6: Execute the uninstallation instruction, the Biz package will be uninstalled, and its occupied resources and published services will be unregistered.\n ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0f166dd5388f3dc7d968bce31d0f6e4f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","summary":"In the Interactive Instructions section, we have described the set of instructions that Jarslink2.0 supports. In this section, we will focus on all the possible state transitions behind these instructions in the following diagram of a Biz package being loaded from a static file to the runtime and to being uninstalled.\nThe diagram above basically shows the complete life cycle of a Biz package. Now we will explain the direction of each state transition in the diagram:","tags":null,"title":"Lifecycle","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/","wordcount":346},{"author":null,"categories":null,"content":" The link data transparent transmission function allows the applications to store data in the calling context, and then any applications in the entire link can operate the data. This feature is used as follows. Data can be put into the request and response of the link for transparent transmission, and then the applications can get the corresponding data from the link.\nRpcInvokeContext.getContext().putRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;,\u0026amp;quot;value_request\u0026amp;quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;,\u0026amp;quot;value_response\u0026amp;quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;); Example For example, in the scenario of A -\u0026amp;gt; B -\u0026amp;gt; C, the request arguments set by A are transmitted to B and C. On return, response arguments of C and B are transmitted to A.\nRequester A is set as follows:\n// Set the value of the request transparently before calling RpcInvokeContext context = RpcInvokeContext.getContext(); context.putRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;, \u0026amp;quot;a2bbb\u0026amp;quot;); // Call service String result = service.hello(); // Get the result value context.getResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;); Business code for B is as follows:\npublic String hello() { / / Get the value of the request transparent transmission RpcInvokeContext context = RpcInvokeContext.getContext(); String reqBaggage = context.getRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;); // doSomthing(); // result passes a value transparently context.putResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;, \u0026amp;quot;b2aaa\u0026amp;quot;); return result; } If you start the child thread halfway, you need to set the context of the child thread:\nCountDownLatch latch = new CountDownLatch(1); final RpcInvokeContext parentContext = RpcInvokeContext.peekContext(); Thread thread = new Thread(new Runnable(){ public void run(){ Try { RpcInvokeContext.setContext(parentContext); / / Call a remote service xxxService.sayHello(); latch.countDown(); } finally { RpcInvokeContext.removeContext(); } } }, \u0026amp;quot;new-thread\u0026amp;quot;); thread.start(); // If failed to get the transparently transmitted data of the return value. latch.await(); //wait // Return ends, and you can get the value returned by transparent transmission. Compare with SOFATracer SOFATracer is an open-source distributed link tracing system of Ant Finanicial. RPC has been integrated with Tracer and is enabled by default.\nThe differences between data transparent transmission and data transfer by Tracer are as follows:\n RPC data transparent transmission is business-oriented. And it can implement two-way data transmission in the full link. The caller can transmit data to the service provider, and the service provider can also transmit data to the caller. SOFATracer is middleware-oriented and is more suitable for the data transfer without service itself perceving. It can only implement one-way data …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-chain-pass-data/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"96cfb41f07a6a2ad979b53093ff5eee9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","summary":"The link data transparent transmission function allows the applications to store data in the calling context, and then any applications in the entire link can operate the data. This feature is used as follows. Data can be put into the request and response of the link for transparent transmission, and then the applications can get the corresponding data from the link.\nRpcInvokeContext.getContext().putRequestBaggage(\u0026quot;key_request\u0026quot;,\u0026quot;value_request\u0026quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026quot;key_response\u0026quot;,\u0026quot;value_response\u0026quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026quot;key_request\u0026quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026quot;key_response\u0026quot;); Example For example, in the scenario of A -\u0026gt; B -\u0026gt; C, the request arguments set by A are transmitted to B and C.","tags":null,"title":"Link data transparent transmission","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/","wordcount":427},{"author":null,"categories":null,"content":" 本文描述的是 MOSN listener 配置。\n Listener 配置详细描述了 MOSN 启动时监听的端口，以及对应的端口对应不同逻辑的配置。 Listener 的配置可以通过Listener动态接口进行添加和修改。 { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;address\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;bind_port\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;use_original_dst\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;access_logs\u0026amp;quot;:[], \u0026amp;quot;filter_chains\u0026amp;quot;:[], \u0026amp;quot;stream_filters\u0026amp;quot;:[], \u0026amp;quot;inspector\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;connection_idle_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } name 用于唯一区分 Listener，如果配置为空，会默认生成一个 UUID 作为 name。在对 Listener 进行动态更新时，使用 name 作为索引，如果 name 不存在，则是新增一个 listener，如果 name 存在则是对 listener 进行更新。\ntype 标记 Listener 的类型，目前支持 ingress 和 egress 两种类型。不同 type 的 Listener 输出的 tracelog 不同。\naddress IP:Port 形式的字符串，Listener 监听的地址，唯一。\nbind_port bool 类型，表示 Listener 是否会占用 address 配置的地址，通常情况下都需要配置为true。\nuse_original_dst bool 类型，用于透明代理。\naccess_logs 一组 access_log 配置。\nfilter_chains 一组 FilterChain 配置，但是目前 MOSN 仅支持一个 filter_chain。\nstream_filters 一组 stream_filter 配置，目前只在 filter_chain 中配置了 filter 包含 proxy 时生效。\ninspector bool 类型，当此值为 true 时，表示即便 listener 在 filter_chain 中配置开启了 TLS 监听，listener 依然可以处理非 TLS 的请求。\nconnection_idle_timeout Duration String，空闲连接超时配置。当 listener 上建立的连接空闲超过配置的超时时间以后，MOSN 会将此连接关闭。\n","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"028e9053b21853890114c38d55d15390","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/overview/","summary":"本文描述的是 MOSN listener 配置。 Listener 配置详细描述了 MOSN 启动时监听的端口，以及对应的端口对应不同逻辑的配置。 Listener 的配置可以通过Listener动态接口进行添加","tags":null,"title":"Listener 配置","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/overview/","wordcount":447},{"author":null,"categories":null,"content":" SOFARPC provides a variety of load balancing algorithms and currently supports the following five types:\n Type Name Description random Random algorithm The default load balancing algorithm. localPref Local preference algorithm Firstly detect whether the service is published locally, if not, random algorithm is used. roundRobin Round Robin algorithm Method-level polling, the polling is carried out separately to each method, without affecting each other. consistentHash Consistent hash algorithm The same method-level request is routed to the same node. weightRoundRobin Weighted Round Robin algorithm Poll nodes by weight. Not recommended due to poor performance. To use a specific load balancing algorithm, you can configure as follows:\nIn XML If you reference the service using XML, you can configure it by setting the loadBalancer property of the sofa:global-attrs tag:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs loadBalancer=\u0026amp;quot;roundRobin\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; In Annotation It is currently not supported to configure a load balancing algorithm for a reference in Annotation. The function will be provided in subsequent releases.\nIn API under Spring environment If you use the API in a Spring or Spring Boot environment, you can configure it by calling the setLoadBalancer method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setLoadBalancer(\u0026amp;quot;roundRobin\u0026amp;quot;); In API under non-Spring environment If you directly use the bare API provided by SOFARPC in a non-Spring environment, you can configure it by calling the setLoadBalancer method of ConsumerConfig:\nConsumerConfig consumerConfig = new ConsumerConfig(); consumerConfig.setLoadbalancer(\u0026amp;quot;random\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/load-balance/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"739984ca9a414429304f85010fd73ad0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/load-balance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/load-balance/","summary":"SOFARPC provides a variety of load balancing algorithms and currently supports the following five types:\n Type Name Description random Random algorithm The default load balancing algorithm. localPref Local preference algorithm Firstly detect whether the service is published locally, if not, random algorithm is used. roundRobin Round Robin algorithm Method-level polling, the polling is carried out separately to each method, without affecting each other.","tags":null,"title":"Load balance","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/load-balance/","wordcount":230},{"author":null,"categories":null,"content":"To use local file as service registry center, you can configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg The /home/admin/registry/localRegistry.reg is the directory of the local files to be used.\nOn windows OS, the above path indicates the following directory:\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-local/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"33bc89393392e21b3917f090313c0df5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-local/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-local/","summary":"To use local file as service registry center, you can configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg The /home/admin/registry/localRegistry.reg is the directory of the local files to be used.\nOn windows OS, the above path indicates the following directory:\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","tags":null,"title":"Local","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-local/","wordcount":40},{"author":null,"categories":null,"content":" Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately. For single-core forwarding, in the case of specifying P=1, MOSN binds CPU with cores to improve the call execution efficiency of the system and the locality affinity of cache. For memory, in the case of binding single core, MOSN uses SLAB-style recycling mechanism to improve reuse and reduce memory copy. For IO, MOSN mainly implements optimization by controlling the read/write buffer size, read/write timing, read/write frequency and other parameters. The performance test data is as follows:\nTCP proxy performance data For the same deployment mode, this report compares MOSN 0.1.0 and envoy for the upper-layer protocol Bolt (SOFARPC related protocol) and HTTP1.1 respectively.\nDeployment mode The pressure test is deployed in a pure proxy mode. The client process accesses the server process through the MOSN process and serves as a forwarding proxy. The client process, MOSN process, and server process run on the machines which belong to different network segments. The network delay of the direct access from the client to server is about 2.5ms.\nClient Bolt protocol (send 1K string) The client that sends the Bolt protocol data uses the online pressure generators developed by Ant Financial and deploys the SOFARPC client.\nOn the pressure generator performance page, you can see the QPS, success/failure counts, RT and other parameters.\nHTTP1.1 protocol (send 1K string) Use ApacheBench/2.3. The test instructions are:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Mesh machine specifications The mesh runs in a container where the CPU is an exclusive logical core. The specifications are as follows:\n Category Information OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream machine specifications Category Information OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt protocol test result Performance data Indicators MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% Conclusion For single-core TCP forwarding, there is little difference between MOSN 0.1.0 and Envoy 1.7 in terms of performance in the condition with full load, such as QPS, RTT and success/failure counts. We will continue to optimize in the subsequent versions.\nHTTP/1.1 test result Since the HTTP/1.1 request response model is …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report010/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3cb22950b4be5a25b90f8aa1376786e9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/mosn/reference-performance-report010/","summary":"Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately.","tags":null,"title":"MOSN 0.1.0 performance report","type":"projects","url":"/sofastack.tech/en/projects/mosn/reference-performance-report010/","wordcount":730},{"author":null,"categories":null,"content":" Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately. For single-core forwarding, in the case of specifying P=1, MOSN binds CPU with cores to improve the call execution efficiency of the system and the locality affinity of cache. For memory, in the case of binding single core, MOSN uses SLAB-style recycling mechanism to improve reuse and reduce memory copy. For IO, MOSN mainly implements optimization by controlling the read/write buffer size, read/write timing, read/write frequency and other parameters. The performance test data is as follows:\nTCP proxy performance data For the same deployment mode, this report compares MOSN 0.1.0 and envoy for the upper-layer protocol Bolt (SOFARPC related protocol) and HTTP1.1 respectively.\nDeployment mode The pressure test is deployed in a pure proxy mode. The client process accesses the server process through the MOSN process and serves as a forwarding proxy. The client process, MOSN process, and server process run on the machines which belong to different network segments. The network delay of the direct access from the client to server is about 2.5ms.\nClient Bolt protocol (send 1K string) The client that sends the Bolt protocol data uses the online pressure generators developed by Ant Financial and deploys the SOFARPC client.\nOn the pressure generator performance page, you can see the QPS, success/failure counts, RT and other parameters.\nHTTP1.1 protocol (send 1K string) Use ApacheBench/2.3. The test instructions are:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Mesh machine specifications The mesh runs in a container where the CPU is an exclusive logical core. The specifications are as follows:\n Category Information OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream machine specifications Category Information OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt protocol test result Performance data Indicators MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% Conclusion For single-core TCP forwarding, there is little difference between MOSN 0.1.0 and Envoy 1.7 in terms of performance in the condition with full load, such as QPS, RTT and success/failure counts. We will continue to optimize in the subsequent versions.\nHTTP/1.1 test result Since the HTTP/1.1 request response model is …","date":-62135596800,"description":"","dir":"projects/occlum/reference-performance-report010/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"035dfbc7e310acf31561343432aea680","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/occlum/reference-performance-report010/","summary":"Instructions on performance report The following performance report presents the performance comparison data of MOSN 0.1.0 with envoy in terms of pure TCP forwarding for Bolt and HTTP1.x protocols, mainly including QPS, RTT, failure rate, success rate and other indicators.\nIt is significant to note the following optimizations in v0.1.0 which are intended to improve the forwarding performance of MOSN.\n For thread model, MOSN uses the worker goroutine pool to handle stream events, and uses two independent goroutines to handle read and write IO separately.","tags":null,"title":"MOSN 0.1.0 performance report","type":"projects","url":"/sofastack.tech/en/projects/occlum/reference-performance-report010/","wordcount":730},{"author":null,"categories":null,"content":" 以下的的性能报告为 MOSN 0.1.0 在做 Bolt 与 HTTP1.x 协议的纯 TCP 转发上与 envoy 的一些性能对比数据，主要表现在 QPS、RTT、失败率/成功率等。\n这里需要强调的是，为了提高 MOSN 的转发性能，在 0.1.0 版本中，我们做了如下的一些优化手段：\n 在线程模型优化上，使用 worker 协程池处理 stream 事件，使用两个独立的协程分别处理读写 IO 在单核转发优化上，在指定 P=1 的情况下，我们通过使用 CPU 绑核的形式来提高系统调用的执行效率以及 cache 的 locality affinity 在内存优化上，同样是在单核绑核的情况下，我们通过使用 SLAB-style 的回收机制来提高复用，减少内存 copy 在 IO 优化上，主要是通过读写 buffer 大小以及读写时机和频率等参数的控制上进行调优 以下为具体的性能测试数据。\nTCP 代理性能数据 这里，针对相同的部署模式，我们分别针对上层协议为 \u0026amp;quot;Bolt(SofaRpc相关协议)\u0026amp;quot; 与 \u0026amp;quot;HTTP1.1\u0026amp;quot; 来进行对比。\n部署模式 压测采用纯代理模式部署，client 进程通过 MOSN 进程作为转发代理访问server进程。其中，client 进程，MOSN 进程，server 进程分别运行在属于不同网段的机器中。client 直连访问 server 网络延时为 2.5ms 左右。\n客户端 Bolt 协议（发送 1K 字符串） 发送 Bolt 协议数据的客户端使用 \u0026amp;ldquo;蚂蚁金服\u0026amp;rdquo;内部开发的线上压力机，并部署 sofa rpc client。 通过压力机的性能页面，可反映压测过程中的QPS、成功/失败次数，以及RT等参数。\nHTTP1.1 协议（发送 1K 字符串） 使用 ApacheBench/2.3, 测试指令:\nab -n $RPC -c $CPC -p 1k.txt -T \u0026amp;quot;text/plain\u0026amp;quot; -k http://11.166.161.136:12200/tcp_bench \u0026amp;gt; ab.log.$CPU_IDX \u0026amp;amp; Service mesh 运行机器规格 Service mesh 运行在容器中，其中 CPU 为独占的一个逻辑核，具体规格如下：\n 类别 信息 OS 3.10.0-327.ali2008.alios7.x86_64 CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2650 v2 @ 2.60GHz X 1 Upstream 运行机器规格 类别 信息 OS 2.6.32-431.17.1.el6.FASTSOCKET CPU Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5620 @ 2.40GHz X 16 Bolt 协议测试结果 性能数据 指标 MOSN Envoy QPS 103500 104000 RT 16.23ms 15.88ms MEM 31m 18m CPU 100% 100% 结论 可以看到，在单核 TCP 转发场景下，MOSN 0.1.0 版本和 Envoy 1.7版本，在满负载情况下的 QPS、RTT、成功数/失败数等性能数据上相差不大，后续版本我们会继续优化。\nHTTP/1.1 测试结果 由于 HTTP/1.1 的请求响应模型为 PING-PONG，因此 QPS 与并发数会呈现正相关。下面分别进行不同并发数的测试。\n并发20 指标 MOSN Envoy QPS 5600 5600 RT(mean) 3.549ms 3.545ms RT(P99) 4ms 4ms RT(P98) 4ms 4ms RT(P95) 4ms 4ms MEM 24m 23m CPU 40% 20% 并发40 指标 MOSN Envoy QPS 11150 11200 RT(mean) 3.583ms 3.565ms RT(P99) 4ms 4ms RT(P98) 4ms 4ms RT(P95) 4ms 4ms MEM 34m 24m CPU 70% 40% 并发200 指标 MOSN Envoy QPS 29670 38800 RT(mean) 5.715ms 5.068ms RT(P99) 16ms 7ms RT(P98) 13ms 7ms RT(P95) 11ms 6ms MEM 96m 24m CPU 100% 95% 并发220 指标 MOSN Envoy QPS 30367 41070 RT(mean) 8.201ms 5.369ms RT(P99) 20ms 9ms RT(P98) 19ms 8ms RT(P95) 16ms 8ms MEM 100m 24m CPU 100% 100% 结论 可以看到，在上层协议为 HTTP/1.X 时，MOSN 的性能和 Envoy 的性能存在一定差距，对于这种现象我们的初步结论为：在 PING-PONG 的发包模型下，MOSN 无法进行 read/write 系统调用合并，相比 SOFARPC 可以合并的场景，syscall 数量大幅上升，因此导致相比 SOFARPC 的场景，HTTP 性能上相比 Envoy 会存在差距。针对这个问题，在 0.2.0 版本中，我们会进行相应的优化。\n附录 Envoy 版本信息 version：1.7 tag：1ef23d481a4701ad4a414d1ef98036bd2ed322e7 Envoy TCP 测试配置 static_resources: listeners: - address: socket_address: address: 0.0.0.0 port_value: 12200 filter_chains: - filters: - name: envoy.tcp_proxy config: stat_prefix: ingress_tcp cluster: sofa_server clusters: - name: sofa_server connect_timeout: 0.25s type: static lb_policy: round_robin hosts: - socket_address: address: 10.210.168.5 port_value: 12222 - socket_address: address: 10.210.168.5 port_value: 12223 - socket_address: address: 10.210.168.5 port_value: 12224 - socket_address: address: 10.210.168.5 port_value: 12225 admin: access_log_path: …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report010/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3cb22950b4be5a25b90f8aa1376786e9","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/reference-performance-report010/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/reference-performance-report010/","summary":"以下的的性能报告为 MOSN 0.1.0 在做 Bolt 与 HTTP1.x 协议的纯 TCP 转发上与 envoy 的一些性能对比数据，主要表现在 QPS、RTT、失败率/成功率等。 这里需要强调的是，为了提","tags":null,"title":"MOSN 0.1.0 性能报告","type":"projects","url":"/sofastack.tech/projects/mosn/reference-performance-report010/","wordcount":1229},{"author":null,"categories":null,"content":" 以下性能报告的基准版本为 MOSN 0.2.1。在 0.2.1 版本中，我们进行了如下一些优化手段： - 添加内存复用框架，涵盖 io/protocol/stream/proxy 层级，减少对象分配、内存使用和 GC 压力。 - 针对大量链接场景，新增 Raw Epoll 模式，该模式使用了事件回调机制 + IO 协程池，规避了海量协程带来的堆栈内存消耗以及调度开销。\n需要注意的是，由于目前 SOFARPC 和 H2 的压测工具还没有 pxx 指标的展示，我们在性能报告中选取的数据都为均值。后续需要我们自行进行相关压测环境工具的建设来完善相关指标（P99，P95……）\n总览 本次性能报告在0.1.0 性能报告的基础上，新增了若干场景的覆盖，总体包含以下几部分： - 单核性能（sidecar场景） - 7层代理 - Bolt（串联） - Http/1.1（串联） - Http/2（串联） - 多核性能（gateway场景） - 7层代理 - Bolt（直连） - Http/1.1（直连） - Http/2（直连） - 长连接网关 - Bolt（read/write loop with goroutine/raw epoll）\n单核性能（sidecar 场景） 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2430 0 @ 2.20GHz bolt client client 为压力平台，有 5 台压力机，共计与client MOSN 之间会建立 500 条链接 http1 client（10.210.168.5） ApacheBench/2.3 -n 2000000 -c 500 -k http2 client（10.210.168.5） nghttp.h2load -n1000000 -c5 -m100 -t4 部署结构 压测模式 部署结构 串联 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 请求内容 1K req/resp 7层代理 场景 QPS RT(ms) MEM(K) CPU(%) Bolt 16000 15.8 77184 98 Http/1.1 4610 67 47336 90 Http/2 5219 81 31244 74 多核性能（gateway 场景） 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel（R） Xeon（R） CPU E5-2430 0 @ 2.20GHz bolt client client为压力平台，有5台压力机，共计与client MOSN之间会建立500条链接 http1 client（10.210.168.5） ApacheBench/2.3 -n 2000000 -c 500 -k http2 client（10.210.168.5） nghttp.h2load -n1000000 -c5 -m100 -t4 部署结构 压测模式 部署结构 直连 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 请求内容 1K req/resp 7层代理 场景 QPS RT(ms) MEM(K) CPU(%) Bolt 45000 23.4 544732 380 Http/1.1 21584 23 42768 380 Http/2 8180 51.7 173180 300 长连接网关 测试环境 机器信息 机器 OS CPU 11.166.190.224 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2640 v3 @ 2.60GHz 11.166.136.110 3.10.0-327.ali2010.rc7.alios7.x86_64 Intel\u0026amp;reg; Xeon\u0026amp;reg; CPU E5-2430 0 @ 2.20GHz 部署结构 压测模式 部署结构 直连 client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; server（11.166.136.110） 网络时延 节点 PING client \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.190.224） 1.356ms MOSN（11.166.190.224） \u0026amp;ndash;\u0026amp;gt; MOSN（11.166.136.110） 0.097 ms 请求模式 链接数 请求内容 2 台压力机，每台 5w 链接 + 500 QPS，共计10W链接 + 1000 QPS 1K req/resp 长连接网关 场景 QPS MEM(g) CPU(%) goroutine RWLoop + goroutine 1000 3.3 60 200028 Raw epoll 1000 2.5 18 28 总结 MOSN 0.2.1引入了内存复用框架，相比0.1.0，在 bolt 协议转发场景性能表现得到了大幅优化。在提升了20% 的 QPS 的同时，还优化了 30% 的内存占用。\n与此同时，我们对 HTTP/1.1 及 HTTP/2 的场景也进行 …","date":-62135596800,"description":"","dir":"projects/mosn/reference-performance-report021/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7b04a2e6cf1c4f9e732dc1dfdab74c57","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/reference-performance-report021/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/reference-performance-report021/","summary":"以下性能报告的基准版本为 MOSN 0.2.1。在 0.2.1 版本中，我们进行了如下一些优化手段： - 添加内存复用框架，涵盖 io/protocol/stream/proxy 层级，减少对象分配、内存使用和 GC 压力","tags":null,"title":"MOSN 0.2.1 性能报告","type":"projects","url":"/sofastack.tech/projects/mosn/reference-performance-report021/","wordcount":1616},{"author":null,"categories":null,"content":" MOSN 的官方网站 mosn.io 正在建设中，文档临时托管在这里。\nMOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称。MOSN 可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡，API Gateway，云原生 Ingress 等使用。\n快速开始 请参考快速开始。\n核心能力 Istio集成 集成 Istio 1.0 版本与 V4 API，可基于全动态资源配置运行 核心转发 自包含的网络服务器 支持 TCP 代理 支持 TProxy 模式 多协议 支持 HTTP/1.1，HTTP/2 支持 SOFARPC 支持 Dubbo 协议（开发中） 核心路由 支持 Virtual Host 路由 支持 Headers/URL/Prefix 路由 支持基于 Host Metadata 的 Subset 路由 支持重试 后端管理\u0026amp;amp;负载均衡 支持连接池 支持熔断 支持后端主动健康检查 支持 Random/RR 等负载策略 支持基于 Host Metadata 的 Subset 负载策略 可观察性 观察网络数据 观察协议数据 TLS 支持 HTTP/1.1 on TLS 支持 HTTP/2.0 on TLS 支持 SOFARPC on TLS 进程管理 支持平滑 reload 支持平滑升级 扩展能力 支持自定义私有协议 支持在 TCP IO 层，协议层面加入自定义扩展 社区 MOSN 仍处在初级阶段，有很多能力需要补全，所以我们欢迎所有人参与进来与我们一起共建。\n如有任何疑问欢迎提交 Issue。\n","date":-62135596800,"description":"","dir":"projects/mosn/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f25c59cbb758b4dae5de39e1f1c3a2f4","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/overview/","summary":"MOSN 的官方网站 mosn.io 正在建设中，文档临时托管在这里。 MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，","tags":null,"title":"MOSN 介绍","type":"projects","url":"/sofastack.tech/projects/mosn/overview/","wordcount":470},{"author":null,"categories":null,"content":" Service Mesh 中 Sidecar 运维一直是一个比较棘手的问题，数据平面的 Sidecar 升级是常有的事情，如何在升级 Sidecar（MOSN）的时候而不影响业务，对于存量的长连接如何迁移，本文将为你介绍 MOSN 的解决之道。\n背景 本文介绍 MOSN 支持平滑升级的原因和解决方案，对于平滑升级的一些基础概念，大家可以通过 Nginx vs Enovy vs Mosn 平滑升级原理解析了解。\n先简单介绍一下为什么 Nginx 和 Envoy 不需要具备 MOSN 这样的连接无损迁移方案，主要还是跟业务场景相关，Nginx 和 Envoy 主要支持的是 HTTP1 和 HTTP2 协议，HTTP1使用 connection: Close，HTTP2 使用 Goaway Frame 都可以让 Client 端主动断链接，然后新建链接到新的 New process，但是针对 Dubbo、SOFA PRC 等常见的多路复用协议，它们是没有控制帧，Old process 的链接如果断了就会影响请求的。\n一般的升级做法就是切走应用的流量，比如自己UnPub掉服务，等待一段时间没有请求之后，升级MOSN，升级好之后再Pub服务，整个过程比较耗时，并且会有一段时间是不提供服务的，还要考虑应用的水位，在大规模场景下，就很难兼顾评估。MOSN 为了满足自身业务场景，开发了长连接迁移方案，把这条链接迁移到 New process 上，整个过程对 Client 透明，不需要重新建链接，达到请求无损的平滑升级。\n正常流程 Client 发送请求 Request 到 MOSN MOSN 转发请求 Request 到 Server Server 回复响应 Response 到 MOSN MOSN 回复响应 Response 到 Client 上图简单介绍了一个请求的正常流程，我们后面需要迁移的是 TCP1 链接，也就是 Client 到 MOSN 的连接，MOSN 到 Server 的链接 TCP2 不需要迁移，因为 MOSN 访问 Server 是根据 LoadBalance 选择，我们可以主动控制断链建链。\n平滑升级流程 触发条件 有两个方式可以触发平滑升级流程：\n MOSN 对 SIGHUP 做了监听，发送 SIGHUP 信号给 MOSN 进程，通过 ForkExec 生成一个新的 MOSN 进程。 直接重新启动一个新 MOSN 进程。 为什么提供两种方式？最开始我们支持的是方法1，也就是 nginx 和 Envoy 使用的方式，这个在虚拟机或者容器内替换 MOSN 二级制来升级是可行的，但是我们的场景需要满足容器间的升级，所以需要新拉起一个容器，就需要重新启动一个新的 MOSN 进程来做平滑升级，所以后续又支持了方法2。容器间升级还需要 operator 的支持，本文不展开叙述。\n交互流程 首先，老的 MOSN 在启动最后阶段会启动一个协程运行 ReconfigureHandler() 函数监听一个 Domain Socket（reconfig.sock）, 该接口的作用是让新的 MOSN 来感知是否存在老的 MOSN。\nfunc ReconfigureHandler() { l, err := net.Listen(\u0026amp;quot;unix\u0026amp;quot;, types.ReconfigureDomainSocket) for { uc, err := ul.AcceptUnix() _, err = uc.Write([]byte{0}) reconfigure(false) } } 触发平滑升级流程的两种方式最终都是启动一个新的 MOSN 进程，然后调用GetInheritListeners()，通过 isReconfigure() 函数来判断本机是否存在一个老的 MOSN（就是判断是否存在 reconfig.sock 监听），如果存在一个老的 MOSN，就进入迁移流程，反之就是正常的启动流程。\n// 保留了核心流程 func GetInheritListeners() ([]net.Listener, net.Conn, error) { if !isReconfigure() { return nil, nil, nil } l, err := net.Listen(\u0026amp;quot;unix\u0026amp;quot;, types.TransferListenDomainSocket) uc, err := ul.AcceptUnix() _, oobn, _, _, err := uc.ReadMsgUnix(buf, oob) file := os.NewFile(fd, \u0026amp;quot;\u0026amp;quot;) fileListener, err := net.FileListener(file) return listeners, uc, nil } 如果进入迁移流程，新的 MOSN 将监听一个新的 Domain Socket（listen.sock），用于老的 MOSN 传递 listen FD 到新的 MOSN。FD 的传递使用了sendMsg 和 recvMsg。在收到 listen FD 之后，调用 net.FileListener() 函数生产一个 Listener。此时，新老 MOSN 都同时拥有了相同的 Listen 套接字。\n// FileListener returns a copy of the network listener corresponding // to the open file f. // It is the caller\u0026#39;s responsibility to close ln when finished. // Closing ln does not affect f, and closing f does not affect ln. func FileListener(f *os.File) (ln Listener, err error) { ln, err = fileListener(f) if err != nil { err = \u0026amp;amp;OpError{Op: \u0026amp;quot;file\u0026amp;quot;, Net: \u0026amp;quot;file+net\u0026amp;quot;, Source: nil, Addr: fileAddr(f.Name()), Err: err} } return } 这里的迁移和 Nginx 还是有一些区别，Nginx 是 fork 的方式，子进程自动就继承了 listen FD，MOSN 是新启动的进程，不存在父子关系，所以需要通过 sendMsg 的方式来传递。\n在进入迁移流程和 Listen 的迁移过程中，一共使用了两个 Domain Socket：\n reconfig.sock 是 Old MOSN 监听，用于 New MOSN 来判断是否存在 listen.sock 是 New MOSN 监听，用于 Old MOSN 传递 listen FD 两个 sock 其实是可以复用的，也可以用 reconfig.sock …","date":-62135596800,"description":"","dir":"projects/mosn/concept/smooth-upgrade/","fuzzywordcount":4000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2c09c045287c33c760368abe02bb8986","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/smooth-upgrade/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/mosn/concept/smooth-upgrade/","summary":"Service Mesh 中 Sidecar 运维一直是一个比较棘手的问题，数据平面的 Sidecar 升级是常有的事情，如何在升级 Sidecar（MOSN）的时候而不影响业务，对于存量的长连接","tags":null,"title":"MOSN 平滑升级原理解析","type":"projects","url":"/sofastack.tech/projects/mosn/concept/smooth-upgrade/","wordcount":3957},{"author":null,"categories":null,"content":" 1. registry-meta 1.1 Push switch When publishing new SOFARegistry versions, to minimize the impact on services, and avoid large amounts of push messages caused by large-scale service endpoint changes during the server restart process, we will temporarily turn off the push service at the management layer. After publishing the new SOFARegistry version, we can turn on the push service and restore the normal working conditions. Data subscription and service publication information generated for the period when the push service is turned off will be subject to global push for compensation.\nTurn on the push service:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/close\u0026amp;quot; Turn off the push service:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/open\u0026amp;quot; 1.2 Query the endpoint list View the endpoint list of the meta cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/META/node/query\u0026amp;quot; View the endpoint list of the data cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/DATA/node/query\u0026amp;quot; View the endpoint list of the session cluster:\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/SESSION/node/query\u0026amp;quot; 1.3 Scale up/down the meta cluster 1.3.1 Modify the cluster: changePeer You can call this operation to modify the Raft cluster list when you have scaled up/down the cluster. This allows you to correctly add nodes to or remove nodes from the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;ip1\u0026amp;gt;,\u0026amp;lt;ip2\u0026amp;gt;,\u0026amp;lt;ip3\u0026amp;gt;\u0026amp;quot; 1.3.2 Reset the cluster: resetPeer When a cluster is unavailable, for example, two of three servers are not functional, the cluster can not carry out leader election. Here, you can call this operation to reset the cluster list. For example, you can reset the cluster to a one-server cluster (with the only functional server) to resume election and restore service.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/manage/resetPeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;ip1\u0026amp;gt;,\u0026amp;lt;ip2\u0026amp;gt;,\u0026amp;lt;ip3\u0026amp;gt;\u0026amp;quot; 2. registry-data 2.1 Query data View the pub count:\ncurl \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/datum/count\u0026amp;quot; You can call this operation to view data published by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;\u0026amp;quot;:\u0026amp;quot;\u0026amp;lt;client port\u0026amp;gt;\u0026amp;quot;}\u0026#39; 3. registry-session 3.1 Query data You can call this operation to view data published by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/pub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client port\u0026amp;gt;\u0026amp;quot;]\u0026#39; You can call this operation to view data subscribed to by a client based on its IP address and port number.\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/sub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: …","date":-62135596800,"description":"","dir":"projects/sofa-registry/management-api/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2cf59ac422c84c279d73c1f7f1cd0902","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/management-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/management-api/","summary":"1. registry-meta 1.1 Push switch When publishing new SOFARegistry versions, to minimize the impact on services, and avoid large amounts of push messages caused by large-scale service endpoint changes during the server restart process, we will temporarily turn off the push service at the management layer. After publishing the new SOFARegistry version, we can turn on the push service and restore the normal working conditions. Data subscription and service publication information generated for the period when the push service is turned off will be subject to global push for compensation.","tags":null,"title":"Management commands","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/management-api/","wordcount":406},{"author":null,"categories":null,"content":" pom dependencies \u0026amp;lt;!-- jraft --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jraft-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- jsr305 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.code.findbugs\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jsr305\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- bolt --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hessian\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- log --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.7.21\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- disruptor --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.lmax\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;disruptor\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-io\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-io\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-lang\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-lang\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protobuf --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.protobuf\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protobuf-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protostuff --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-runtime\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- rocksdb --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.rocksdb\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rocksdbjni\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.14.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- java thread affinity --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;net.openhft\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;affinity\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.1.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- metrics --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.dropwizard.metrics\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;metrics-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/maven-dependency/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"abb08cef5ebf1a10a723597a65415313","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","summary":"pom dependencies \u0026lt;!-- jraft --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jraft-core\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- jsr305 --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.code.findbugs\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jsr305\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.0.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- bolt --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;hessian\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- log --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.slf4j\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;slf4j-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.7.21\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- disruptor --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.lmax\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;disruptor\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.7\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-io\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-io\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.4\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-lang\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-lang\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protobuf --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.protobuf\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;protobuf-java\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.5.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protostuff --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.","tags":null,"title":"Maven dependencies","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/maven-dependency/","wordcount":104},{"author":null,"categories":null,"content":" pom依赖 \u0026amp;lt;!-- jraft --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jraft-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- jsr305 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.code.findbugs\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;jsr305\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- bolt --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.5.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;hessian\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- log --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.7.21\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- disruptor --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.lmax\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;disruptor\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.3.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-io\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-io\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.4\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-lang\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-lang\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protobuf --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.protobuf\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protobuf-java\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.5.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- protostuff --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.protostuff\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;protostuff-runtime\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- rocksdb --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.rocksdb\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rocksdbjni\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.14.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- java thread affinity --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;net.openhft\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;affinity\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.1.7\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- metrics --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.dropwizard.metrics\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;metrics-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.0.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/maven-dependency/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"abb08cef5ebf1a10a723597a65415313","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/maven-dependency/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/maven-dependency/","summary":"pom依赖 \u0026lt;!-- jraft --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jraft-core\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- jsr305 --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.code.findbugs\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;jsr305\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.0.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- bolt --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.5.3\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;hessian\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- log --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.slf4j\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;slf4j-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.7.21\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- disruptor --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.lmax\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;disruptor\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.3.7\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-io\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-io\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.4\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;commons-lang\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;commons-lang\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;2.6\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protobuf --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.google.protobuf\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;protobuf-java\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.5.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- protostuff","tags":null,"title":"Maven 依赖说明","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/maven-dependency/","wordcount":107},{"author":null,"categories":null,"content":" In Jarslink 2.0, merged deployment refers to loading and running multiple Biz packages in the same JVM. In the section Application Packaging, we have described the relationship between the Spring Boot/SOFABoot application and the Biz package. We may think that merged deployment here refers to loading and running multiple Spring Boot/SOFABoot applications in the same JVM.\nIt is mentioned at the end of Application Packaging that a Biz package can be released to a remote repository through the mvn deploy command, similar to releasing common Jar packages. It comes naturally to mind that the advantage of doing so is that the Biz package generated by other applications can be introduced in the form of dependencies, just like introducing common Jar package dependencies. Then, what is the purpose of introducing the Biz package generated by other applications into your application? Also, how do we dynamically install and uninstall Biz packages in Jarslink 2.0?\nTo answer the two questions above is to understand the concepts of static merged deployment and dynamic merged deployment.\nStatic merged deployment To answer the first question: What is the purpose of introducing the Biz package generated by other applications into your application?\nIn the section Application Packaging, we have described how to package an application into an Ark package and offered a rough equation: Ark package = Biz package + SOFAArk framework + Ark Plugin. When a Biz package generated by other applications is introduced in the application, what kind of packaged Ark package will it be? The conclusion is that the packaging plugin will treat special dependency packages like the Biz package differently. The plugin will package all the non-Biz package dependencies into the application\u0026amp;rsquo;s Biz package, but will consider the introduced Biz package as equal to those of the current application. The final Ark package will contain multiple Biz packages. For details, refer to Ark Package Directory Structure. At this point, when you use java -jar to start this Ark package, you will find that all the contained Biz packages will be started as well.\nTo sum up, the application introduces the Biz packages generated by other applications in the form of dependencies, and the Ark package packaged by this application will contain multiple Biz packages. By executing this Ark package, all the Biz packages will be started, known as static merged deployment.\nStatic merged deployment does not depend on Jarslink 2.0 but is available directly with the SOFAArk packaging plugin.\nNote that the startup order of multiple Biz packages is controllable. When each Biz package is generated, you can use the packaging plugin to configure its priority, whose value is 100 by default. The higher the priority, the lower the value is. The priority determines the startup order of the Biz package.\nDynamic merged deployment To answer the second question: how do you dynamically install and uninstall Biz packages in Jarslink …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-deploy/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ce787203d9d834b7f796b3dbb40bf55d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","summary":"In Jarslink 2.0, merged deployment refers to loading and running multiple Biz packages in the same JVM. In the section Application Packaging, we have described the relationship between the Spring Boot/SOFABoot application and the Biz package. We may think that merged deployment here refers to loading and running multiple Spring Boot/SOFABoot applications in the same JVM.\nIt is mentioned at the end of Application Packaging that a Biz package can be released to a remote repository through the mvn deploy command, similar to releasing common Jar packages.","tags":null,"title":"Merged deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/","wordcount":749},{"author":null,"categories":null,"content":" Quickly understand of ACTS models When you write a test case, you need to prepare some database tables, request parameter data of methods, or data for validating database tables and responses. You can save such data in models, and import it to preparation data or validation data when you edit the test case. This allows you to conveniently reuse data. Currently, ACTS models can be divided into database models and class models.\nIn conventional test case compilation, data preparation of models, such as database models, request parameter models, and response models, is based on the test code. The complexity of models increases with the business complexity, especially in financial-level business applications, where a class or data table may have dozens of properties or fields, and where class nesting is common. In this case, constructing complex objects is extremely difficult and prone to omissions. Some of the most frequently occurring problems are listed as follows:\n Omissions may occur and troubleshooting takes a lot of time for a large number of tables. Field names of tables are difficult to remember, and spelling errors frequently occur. The large number and complex types of interface request parameters are frustrating. There are so many class properties that important properties are prone to omission. Object construction with nested structures requires continuous effort in creating and setting values. Important properties are easily omitted when the inheritance and implementation relationships are complex. ACTS models can effectively address the above problems by formatting classes and tables in CSV, which makes the structure of classes easier to understand. Class models and data table models can help you quickly create objects, and serialize them into the YAML file. ACTS models allow you to conveniently manage test case data.\nStorage location of models You can view existing models under the resource/model directory of the test module.\nFigure 4\nGenerate data table model Sample data table model Figure 5\n1. Validation flag description\nY: indicates that the data is to be inserted. N: indicates that the data is not to be inserted. C: indicates that ACTS will clean the inserted data by taking this value as the where condition. F: indicates that the value of this column is a database function. L: indicates that a large field data record requires line wrap. The preparation method for this data record is: A=B;C=D. 2. Quickly import data from models during test case editing\nWhen editing database table data (including preparing table data and expectation data) in ACTS IDE, you can right click to add a model of the specified table, to import all fields and values of the specified table directly from the CSV file of the table model for quick editing. For more information about the use of DB models, see Prepare database data.\nGenerate table model Figure 6\nFigure 7\nFigure 8\nClick OK to generate the model as shown in Figure 9.\nFigure 9\nACTS also supports …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-model/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"65aaf62462b3b0ea142ca75a5b61eb0d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-model/","summary":"Quickly understand of ACTS models When you write a test case, you need to prepare some database tables, request parameter data of methods, or data for validating database tables and responses. You can save such data in models, and import it to preparation data or validation data when you edit the test case. This allows you to conveniently reuse data. Currently, ACTS models can be divided into database models and class models.","tags":null,"title":"Models","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-model/","wordcount":752},{"author":null,"categories":null,"content":" Since version 2.4.0, SOFABoot has started to support modular development capability based on Spring context isolation. To better understand the concept of modular development of SOFABoot, let\u0026amp;rsquo;s distinguish several common forms of modularization:\n Modularization based on code organization: This is the most common form. Codes with different functions are placed under different Java projects at development time and into different jar packages at compile time. At runtime, all Java classes are under the same classpath without any isolation; Modularization based on Spring context isolation: Use the Spring context to perform isolation of different function modules. At development and compile time, the codes and configurations are also placed under different Java projects. At runtime, however, if Spring beans are in different Spring contexts, they are invisible to each other, so dependency injection occurs within the same context. But, all the Java classes are still under the same ClassLoader; Modularization based on ClassLoader isolation: Borrow the ClassLoader to perform isolation. Each module has an independent ClassLoader, and the classpath between modules differs. SOFAArk is the practice of such modularization. SOFABoot Modular Development belongs to the second modularization form\u0026amp;ndash;modularization based on Spring context isolation. Each SOFABoot module uses an independent Spring context to avoid BeanId conflicts between different SOFABoot modules and effectively reduces the cost of communication between teams during enterprise-level multi-module development.\nMore details about SOFABoot module is introduced in the article.\nFeature Description Import Dependency To use SOFABoot module, you should import the following dependency: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;isle-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFABoot Module SOFABoot framework has defined the concept of SOFABoot module: A SOFABoot module is a common Jar package including Java code, Spring configuration files, and SOFABoot module identifiers. A SOFABoot application can be comprised of multiple SOFABoot modules, each of which has independent Spring context.\nThe modular development with SOFABoot provides developers with the following features:\n At runtime, the Spring context of each SOFABoot module is isolated, so the defined Beans between modules will not affect each other; Each SOFABoot module is full-featured and self-contained, allowing for easy migration and reuse in different SOFABoot applications. Developers only need to copy the whole SOFABoot module to the application and adjust the Maven dependence before running it. For the format definition of SOFABoot module, see: Module Configuration.\nInvocation between SOFABoot Modules After isolation of context, the Bean between modules cannot be directly injected, so the SOFA service is required for invocation between the modules. Currently, SOFABoot offers …","date":-62135596800,"description":"","dir":"projects/sofa-boot/modular-development/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"95bc080787c3614bfa485d2f3cd0de4c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/modular-development/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/modular-development/","summary":"Since version 2.4.0, SOFABoot has started to support modular development capability based on Spring context isolation. To better understand the concept of modular development of SOFABoot, let\u0026rsquo;s distinguish several common forms of modularization:\n Modularization based on code organization: This is the most common form. Codes with different functions are placed under different Java projects at development time and into different jar packages at compile time. At runtime, all Java classes are under the same classpath without any isolation; Modularization based on Spring context isolation: Use the Spring context to perform isolation of different function modules.","tags":null,"title":"Modular development","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/modular-development/","wordcount":578},{"author":null,"categories":null,"content":" The SOFABoot module combines a regular JAR with some SOFABoot-specific configurations, which enables a JAR to be identified by SOFABoot and modularized.\nThere are two differences between a complete SOFABoot module and a regular JAR:\n A SOFABoot module contains a sofa-module.properties file, where the name and the dependencies of the module are defined. We can place one or more Spring configuration files in the SOFABoot module\u0026amp;rsquo;s META-INF/spring directory; and SOFABoot will automatically load them as Spring configurations for that module. Inside the sofa-module.properties file Let\u0026amp;rsquo;s look at a complete sofa-module.properties file:\nModule-Name=com.alipay.test.biz.service.impl Spring-Parent=com.alipay.test.common.dal Require-Module=com.alipay.test.biz.shared Module-Profile=dev Module-Name This is the name of a SOFABoot module, which is also the unique identifier of the module. In a SOFABoot application, the Module-Name of a SOFABoot module must be different from that of another SOFABoot module. Note that the SOFABoot modules of a SOFABoot application runtime do not only cover the modules of the current application but also the modules introduced by dependency from other applications. When determining whether a module is unique, you must take these SOFABoot modules into consideration.\nRequire-Module This defines the dependency order of different modules. The value contains a comma-separated list of SOFABoot module names. For example, in the preceding configuration, it indicates that the current module depends on the com.alipay.test.biz.shared module. The SOFABoot framework processes this dependency by starting the com.alipay.test.biz.shared module before the current module.\nIn most cases, you do not have to define the Require-Module for a module. It is required only when the startup of a module\u0026amp;rsquo;s Spring context depends on that of another module\u0026amp;rsquo;s. For example, you have published a JVM Service in module A. In the init method of a Bean in module B, you need to call the JVM Service with a SOFA Reference. Assume that module B is started before module A, the Bean of module B will fail because the JVM Service of module A is not published yet and the init method fails. In this case, you can use the Require-Module to force module A to start before module B.\nSpring-Parent In a SOFABoot application, each SOFABoot module has a separate Spring context, and these Spring contexts are isolated from each other. Although this modular approach has many benefits, it can still cause some inconveniences in certain scenarios. For these scenarios, you can use the Spring-Parent to connect the Spring contexts of two SOFABoot modules. The name of a module can be configured with the Spring-Parent property. For example, in the preceding configuration, the Spring context of com.alipay.test.common.dal is set to the parent of the current module\u0026amp;rsquo;s Spring context.\nDue to Spring\u0026amp;rsquo;s limitations, a module\u0026amp;rsquo;s Spring-Parent contains only one …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-module/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2dbb8a536237f21afbee1e3f320b8193","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","summary":"The SOFABoot module combines a regular JAR with some SOFABoot-specific configurations, which enables a JAR to be identified by SOFABoot and modularized.\nThere are two differences between a complete SOFABoot module and a regular JAR:\n A SOFABoot module contains a sofa-module.properties file, where the name and the dependencies of the module are defined. We can place one or more Spring configuration files in the SOFABoot module\u0026rsquo;s META-INF/spring directory; and SOFABoot will automatically load them as Spring configurations for that module.","tags":null,"title":"Module configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofaboot-module/","wordcount":565},{"author":null,"categories":null,"content":"SOFABoot will calculate the dependency tree based on the Require-Module. For example, the following dependency tree represents that Modules B and C depend on Module A, Module E depends on Module D, and Module F depends on Module E:\nThe dependency tree guarantees that Module A starts before Modules B and C, Module D before Module E, and Module E before Module F, but without defining the start orders between Modules B and C, or Modules B, C and Modules D, E and F, which can start either in serial or parallel.\nSOFABoot will start the modules in parallel by default. During use, if you want to disable parallel start, you can add the following parameter to application.properties:\ncom.alipay.sofa.boot.module-start-up-parallel=false ","date":-62135596800,"description":"","dir":"projects/sofa-boot/parallel-start/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a6ef51b78d2a4f9af0debbc25ea45e8a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/parallel-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/parallel-start/","summary":"SOFABoot will calculate the dependency tree based on the Require-Module. For example, the following dependency tree represents that Modules B and C depend on Module A, Module E depends on Module D, and Module F depends on Module E:\nThe dependency tree guarantees that Module A starts before Modules B and C, Module D before Module E, and Module E before Module F, but without defining the start orders between Modules B and C, or Modules B, C and Modules D, E and F, which can start either in serial or parallel.","tags":null,"title":"Module parallel startup","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/parallel-start/","wordcount":119},{"author":null,"categories":null,"content":"SOFARPC already supports using Nacos as a service registry. Suppose you have deployed Nacos Server locally according to Nacos\u0026amp;rsquo;s Quick Start, and the service discovery port is set to 8848 by default.\nTo use Nacos as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 If you use SOFARPC directly, not SOFABoot, you need to add dependency of nacos, notice that version is what you want to use in your project.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba.nacos\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;nacos-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; The current version of Nacos is supported:\nSOFARPC: 5.5.0, SOFABoot: 2.5.3。\nSOFARPC integration verification Nacos server version:0.6.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-nacos/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"cc161f22cd2145fe309e63087581adc1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","summary":"SOFARPC already supports using Nacos as a service registry. Suppose you have deployed Nacos Server locally according to Nacos\u0026rsquo;s Quick Start, and the service discovery port is set to 8848 by default.\nTo use Nacos as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 If you use SOFARPC directly, not SOFABoot, you need to add dependency of nacos, notice that version is what you want to use in your project.","tags":null,"title":"Nacos","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-nacos/","wordcount":100},{"author":null,"categories":null,"content":" 前言 本文是对 Nginx、Envoy 及 MOSN 的平滑升级原理区别的分析，适合对 Nginx 实现原理比较感兴趣的同学阅读，需要具备一定的网络编程知识。\n平滑升级的本质就是 listener fd 的迁移，虽然 Nginx、Envoy、MOSN 都提供了平滑升级支持，但是鉴于它们进程模型的差异，反映在实现上还是有些区别的。这里来探讨下它们其中的区别，并着重介绍 Nginx 的实现。\nNginx 相信有很多人认为 Nginx 的 reload 操作就能完成平滑升级，其实这是个典型的理解错误。实际上 reload 操作仅仅是平滑重启，并没有真正的升级新的二进制文件，也就是说其运行的依然是老的二进制文件。\nNginx 自身也并没有提供平滑升级的命令选项，其只能靠手动触发信号来完成。具体正确的操作步骤可以参考这里：Upgrading Executable on the Fly，这里只分析下其实现原理。\nNginx 的平滑升级是通过 fork + execve 这种经典的处理方式来实现的。准备升级时，Old Master 进程收到信号然后 fork 出一个子进程，注意此时这个子进程运行的依然是老的镜像文件。紧接着这个子进程会通过 execve 调用执行新的二进制文件来替换掉自己，成为 New Master。\n那么问题来了：New Master 启动时按理说会执行 bind + listen 等操作来初始化监听，而这时候 Old Master 还没有退出，端口未释放，执行 execve 时理论上应该会报：Address already in use 错误，但是实际上这里却没有任何问题，这是为什么？\n因为 Nginx 在 execve 的时候压根就没有重新 bind + listen，而是直接把 listener fd 添加到 epoll 的事件表。因为这个 New Master 本来就是从 Old Master 继承而来，自然就继承了 Old Master 的 listener fd，但是这里依然有一个问题：该怎么通知 New Master 呢？\n环境变量。execve 在执行的时候可以传入环境变量。实际上 Old Master 在 fork 之前会将所有 listener fd 添加到 NGINX 环境变量：\nngx_pid_t ngx_exec_new_binary(ngx_cycle_t *cycle, char *const *argv) { ... ctx.path = argv[0]; ctx.name = \u0026amp;quot;new binary process\u0026amp;quot;; ctx.argv = argv; n = 2; env = ngx_set_environment(cycle, \u0026amp;amp;n); ... env[n++] = var; env[n] = NULL; ... ctx.envp = (char *const *) env; ccf = (ngx_core_conf_t *) ngx_get_conf(cycle-\u0026amp;gt;conf_ctx, ngx_core_module); if (ngx_rename_file(ccf-\u0026amp;gt;pid.data, ccf-\u0026amp;gt;oldpid.data) == NGX_FILE_ERROR) { ... return NGX_INVALID_PID; } pid = ngx_execute(cycle, \u0026amp;amp;ctx); return pid; } Nginx 在启动的时候，会解析 NGINX 环境变量：\nstatic ngx_int_t ngx_add_inherited_sockets(ngx_cycle_t *cycle) { ... inherited = (u_char *) getenv(NGINX_VAR); if (inherited == NULL) { return NGX_OK; } if (ngx_array_init(\u0026amp;amp;cycle-\u0026amp;gt;listening, cycle-\u0026amp;gt;pool, 10, sizeof(ngx_listening_t)) != NGX_OK) { return NGX_ERROR; } for (p = inherited, v = p; *p; p++) { if (*p == \u0026#39;:\u0026#39; || *p == \u0026#39;;\u0026#39;) { s = ngx_atoi(v, p - v); ... v = p + 1; ls = ngx_array_push(\u0026amp;amp;cycle-\u0026amp;gt;listening); if (ls == NULL) { return NGX_ERROR; } ngx_memzero(ls, sizeof(ngx_listening_t)); ls-\u0026amp;gt;fd = (ngx_socket_t) s; } } ... ngx_inherited = 1; return ngx_set_inherited_sockets(cycle); } 一旦检测到是继承而来的 socket，那就说明已经打开了，不会再继续 bind + listen 了：\nngx_int_t ngx_open_listening_sockets(ngx_cycle_t *cycle) { ... /* TODO: configurable try number */ for (tries = 5; tries; tries--) { failed = 0; /* for each listening socket */ ls = cycle-\u0026amp;gt;listening.elts; for (i = 0; i \u0026amp;lt; cycle-\u0026amp;gt;listening.nelts; i++) { ... if (ls[i].inherited) { /* TODO: close on exit */ /* TODO: nonblocking */ /* TODO: deferred accept */ continue; } ... ngx_log_debug2(NGX_LOG_DEBUG_CORE, log, 0, \u0026amp;quot;bind() %V #%d \u0026amp;quot;, \u0026amp;amp;ls[i].addr_text, s); if (bind(s, ls[i].sockaddr, ls[i].socklen) == -1) { ... } ... } } if (failed) { ngx_log_error(NGX_LOG_EMERG, log, 0, \u0026amp;quot;still could not bind()\u0026amp;quot;); return NGX_ERROR; } return NGX_OK; } Envoy Envoy 使用的是单进程多线程模型，其局限就是无法通过环境变量来传递 listener fd。因此 Envoy 采用的是 UDS（unix domain sockets）方案。当 New Envoy 启动完成后，会通过 UDS 向 Old Envoy 请求 listener fd 副本， …","date":-62135596800,"description":"","dir":"projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"63ca389b7e6e0a585d0183ad71887f65","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","summary":"前言 本文是对 Nginx、Envoy 及 MOSN 的平滑升级原理区别的分析，适合对 Nginx 实现原理比较感兴趣的同学阅读，需要具备一定的网络编程知识。 平滑升级的","tags":null,"title":"Nginx vs Envoy vs MOSN 平滑升级原理解析","type":"projects","url":"/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/","wordcount":1525},{"author":null,"categories":null,"content":" If you need to call SOFARPC through NodeJs, you can start by following this document.\nInstall First install the SOFARPC Node.\nhttps://github.com/sofastack/sofa-rpc-node\nUse the following command:\n$ npm install sofa-rpc-node --save Code sample Expose an RPC service and publish it to registry center \u0026#39;use strict\u0026#39;; const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, Address: \u0026#39;127.0.0.1:2181\u0026#39;, // need to start a zkServer locally }); // 2. Create an RPC Server instance const server = new RpcServer({ logger, Registry, // incoming registry client port: 12200, }); // 3. Add service server.addService({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }, { async plus(a, b) { return a + b; }, }); // 4. Start the server and publish the service server.start() .then(() =\u0026amp;gt; { server.publish(); }); Call RPC service (Get service list from registry center) \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); async function invoke() { // 2. Create an RPC Client instance const client = new RpcClient({ logger, registry, }); // 3. Create a service consumer const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }); // 4. Wait for the consumer ready (subscribe to the service list from registry center...) await consumer.ready(); // 5. Execute generic call const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); Call RPC service (direct call) \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const logger = console; async function invoke() { // No need to pass in the registry instance const client = new RpcClient({ logger, }); const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, serverHost: \u0026#39;127.0.0.1:12200\u0026#39;, // directly specify the service address }); await consumer.ready(); const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); Expose and call the protobuf interface Define interface Define the interface with *.proto\nsyntax = \u0026amp;quot;proto3\u0026amp;quot;; package com.alipay.sofa.rpc.test; // optional option java_multiple_files = false; service ProtoService { rpc echoObj (EchoRequest) returns (EchoResponse) {} } message EchoRequest { string name = 1; Group group = 2; } message EchoResponse { int32 code = 1; string message = 2; } enum Group { A = 0; B = 1; } Server code \u0026#39;use strict\u0026#39;; const antpb = require(\u0026#39;antpb\u0026#39;); const protocol = require(\u0026#39;sofa-bolt-node\u0026#39;); const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/node-and-java-communicate/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3329852e9991868a3cdc473b861ca750","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","summary":"If you need to call SOFARPC through NodeJs, you can start by following this document.\nInstall First install the SOFARPC Node.\nhttps://github.com/sofastack/sofa-rpc-node\nUse the following command:\n$ npm install sofa-rpc-node --save Code sample Expose an RPC service and publish it to registry center 'use strict'; const { RpcServer } = require('sofa-rpc-node').server; const { ZookeeperRegistry } = require('sofa-rpc-node').registry; const logger = console; // 1. Create a Zookeeper registry client const registry = new ZookeeperRegistry({ logger, Address: '127.","tags":null,"title":"NodeJS support","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/","wordcount":635},{"author":null,"categories":null,"content":" 快速上手 如果你有通过 NodeJs 调用 SOFARPC 的需求.可以按照如下的文档来开始.\n安装 首先按照文档安装\nhttps://github.com/sofastack/sofa-rpc-node\n使用命令.\n$ npm install sofa-rpc-node --save 代码示例 暴露一个 RPC 服务，并发布到注册中心 \u0026#39;use strict\u0026#39;; const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. 创建 zk 注册中心客户端 const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, // 需要本地启动一个 zkServer }); // 2. 创建 RPC Server 实例 const server = new RpcServer({ logger, registry, // 传入注册中心客户端 port: 12200, }); // 3. 添加服务 server.addService({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }, { async plus(a, b) { return a + b; }, }); // 4. 启动 Server 并发布服务 server.start() .then(() =\u0026amp;gt; { server.publish(); }); 调用 RPC 服务（从注册中心获取服务列表） \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 1. 创建 zk 注册中心客户端 const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); async function invoke() { // 2. 创建 RPC Client 实例 const client = new RpcClient({ logger, registry, }); // 3. 创建服务的 consumer const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, }); // 4. 等待 consumer ready（从注册中心订阅服务列表...） await consumer.ready(); // 5. 执行泛化调用 const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); 调用 RPC 服务（直连模式） \u0026#39;use strict\u0026#39;; const { RpcClient } = require(\u0026#39;sofa-rpc-node\u0026#39;).client; const logger = console; async function invoke() { // 不需要传入 registry 实例了 const client = new RpcClient({ logger, }); const consumer = client.createConsumer({ interfaceName: \u0026#39;com.nodejs.test.TestService\u0026#39;, serverHost: \u0026#39;127.0.0.1:12200\u0026#39;, // 直接指定服务地址 }); await consumer.ready(); const result = await consumer.invoke(\u0026#39;plus\u0026#39;, [ 1, 2 ], { responseTimeout: 3000 }); console.log(\u0026#39;1 + 2 = \u0026#39; + result); } invoke().catch(console.error); 暴露和调用 protobuf 接口 接口定义 通过 *.proto 来定义接口\nsyntax = \u0026amp;quot;proto3\u0026amp;quot;; package com.alipay.sofa.rpc.test; // 可选 option java_multiple_files = false; service ProtoService { rpc echoObj (EchoRequest) returns (EchoResponse) {} } message EchoRequest { string name = 1; Group group = 2; } message EchoResponse { int32 code = 1; string message = 2; } enum Group { A = 0; B = 1; } 服务端代码 \u0026#39;use strict\u0026#39;; const antpb = require(\u0026#39;antpb\u0026#39;); const protocol = require(\u0026#39;sofa-bolt-node\u0026#39;); const { RpcServer } = require(\u0026#39;sofa-rpc-node\u0026#39;).server; const { ZookeeperRegistry } = require(\u0026#39;sofa-rpc-node\u0026#39;).registry; const logger = console; // 传入 *.proto 文件存放的目录，加载接口定义 const proto = antpb.loadAll(\u0026#39;/path/proto\u0026#39;); // 将 proto 设置到协议中 protocol.setOptions({ proto }); const registry = new ZookeeperRegistry({ logger, address: \u0026#39;127.0.0.1:2181\u0026#39;, }); const server = new RpcServer({ logger, protocol, // 覆盖协议 registry, codecType: \u0026#39;protobuf\u0026#39;, // 设置默认的序列化方式为 protobuf port: 12200, }); server.addService({ interfaceName: …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/node-and-java-communicate/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3329852e9991868a3cdc473b861ca750","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","summary":"快速上手 如果你有通过 NodeJs 调用 SOFARPC 的需求.可以按照如下的文档来开始. 安装 首先按照文档安装 https://github.com/sofastack/sofa-rpc-node 使用命令. $ npm install sofa-rpc-node --save 代码示例 暴露一个 RPC 服务，并发布到注册","tags":null,"title":"Node跨语言调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/","wordcount":757},{"author":null,"categories":null,"content":" OkHttp Integration In this document will demonstrate how to use SOFATracer to track of OkHttp, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nDependency introduction \u0026amp;lt;!-- SOFATracer dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- okhttp dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.squareup.okhttp3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;okhttp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.12.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=HttpClientDemo # logging path logging.path=./logs # port server.port=8081 Add a Controller that provides RESTful services In the project, provide a simple Controller, for example:\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8081/okhttp?name=sofa * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/okhttp\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;okhttp\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } Construct OkHttp to initiate a call to the RESTful service above The code example is as follows:\n Construct the OkHttp Client instance: OkHttpClientInstance httpClient = new OkHttpClientInstance(); String httpGetUrl = \u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;; String responseStr = httpClient.executeGet(httpGetUrl); Run Start the SOFABoot app and see the log in the console as follows:\n2019-04-12 13:38:09.896 INFO 51193 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2019-04-12 13:38:09.947 INFO 51193 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8081 (http) 2019-04-12 13:38:09.952 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Started OkHttpDemoApplication in 3.314 seconds (JVM running for 4.157) When there is a log similar to the following, the call to OkHttp is successful:\n2019-04-12 13:38:10.205 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;sofa\u0026amp;quot;} View log In the application.properties, the log printing directory we configured is ./logs, which is the root directory of the current application (we can configure it based on actual situation). In the root directory, you can see log files in the structure similar to …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-okhttp/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2b665b984dd33a4c04b5cd7b4de2410c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","summary":"OkHttp Integration In this document will demonstrate how to use SOFATracer to track of OkHttp, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nDependency introduction \u0026lt;!-- SOFATracer dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;!-- okhttp dependency --\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.squareup.okhttp3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;okhttp\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.12.1\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.","tags":null,"title":"OkHttp Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/","wordcount":374},{"author":null,"categories":null,"content":" OkHttp Log Format SOFATracer integrates OkHttp and outputs the requested link log data format. The default is JSON data format.\nOkHttp digest log（okhttp-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code req.size.bytes Request Body Size resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.app remote app baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-12 13:38:10.187\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe85a1555047489980100151193\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:207,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} OkHttp stat log（okhttp-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-04-12 13:39:09.720\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:207,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-okhttp/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dbc9555f43d0b2eda22f10ed45713fb9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","summary":"OkHttp Log Format SOFATracer integrates OkHttp and outputs the requested link log data format. The default is JSON data format.\nOkHttp digest log（okhttp-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.","tags":null,"title":"OkHttp log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/","wordcount":174},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 OkHttp 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;!-- SOFATracer 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- okhttp 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.squareup.okhttp3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;okhttp\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;3.12.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=OkHttpClientDemo # logging path logging.path=./logs # port server.port=8081 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private final AtomicLong counter = new AtomicLong(0); /** * Request http://localhost:8081/okhttp?name=sofa * @param name name * @return Map of Result */ @RequestMapping(\u0026amp;quot;/okhttp\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; greeting(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;okhttp\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); map.put(\u0026amp;quot;name\u0026amp;quot;, name); return map; } } 构造 OkHttp 发起一次对上文的 RESTful 服务的调用 代码示例如下：\n 构造 OkHttp Client 调用实例： OkHttpClientInstance httpClient = new OkHttpClientInstance(); String httpGetUrl = \u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;; String responseStr = httpClient.executeGet(httpGetUrl); 运行 启动 SOFABoot 应用，在控制台中看到启动打印的日志如下：\n2019-04-12 13:38:09.896 INFO 51193 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2019-04-12 13:38:09.947 INFO 51193 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8081 (http) 2019-04-12 13:38:09.952 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Started OkHttpDemoApplication in 3.314 seconds (JVM running for 4.157) 当有类似如下的日志时，说明 OkHttp 的调用成功：\n2019-04-12 13:38:10.205 INFO 51193 --- [ main] c.a.s.t.e.okhttp.OkHttpDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;sofa\u0026amp;quot;} 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要进行配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── okhttp-digest.log ├── okhttp-stat.log ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 示例中通过构造 OkHttp 对象发起 RESTful 服务的调用，调用完成后可以在 okhttp-digest.log 中看到类似如下的日志:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-okhttp/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2b665b984dd33a4c04b5cd7b4de2410c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","summary":"在本文档将演示如何使用 SOFATracer 对 OkHttp 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;!-- SOFATracer 依","tags":null,"title":"OkHttp 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/","wordcount":578},{"author":null,"categories":null,"content":" SOFATracer 集成 OkHttp 后输出请求的链路数据格式，默认为 JSON 数据格式。\nOkHttp 摘要日志（okhttp-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId request.url 请求 URL method 请求 HTTP 方法 result.code HTTP 返回状态码 req.size.bytes Request Body 大小 resp.size.bytes Response Body 大小 time.cost.milliseconds 请求耗时（ms） current.thread.name 当前线程名 remote.app 目标应用 baggage 透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 11:35:28.429\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567481728265100112783\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;164ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} OkHttp 统计日志（okhttp-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 11:43:06.975\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;OkHttpDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8081/okhttp?name=sofa\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:174,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-okhttp/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dbc9555f43d0b2eda22f10ed45713fb9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","summary":"SOFATracer 集成 OkHttp 后输出请求的链路数据格式，默认为 JSON 数据格式。 OkHttp 摘要日志（okhttp-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下","tags":null,"title":"OkHttp 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-okhttp/","wordcount":330},{"author":null,"categories":null,"content":" OpenFeign Integration In this document will demonstrate how to use SOFATracer to track of OpenFeign.\nPrepare Environment The versions of the framework components used in this case are as follows:\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 This case includes two submodules:\n tracer-sample-with-openfeign-provider service provider tracer-sample-with-openfeign-consumer service consumer New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026amp;rsquo;s dependency. First, you need to unzip the generated zip package of Spring Boot project and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more information about SOFABoot versions, refer to Release notes.\nNew tracer-sample-with-openfeign-provider Module Introducing dependence\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer versions are controlled by SOFABoot versions. If the SOFABoot versions used do not match, you need to manually specify a tracer version that is higher than 3.0.4.\n application.properties Configuration spring.application.name=tracer-provider server.port=8800 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-provider Simple resource class\n@RestController public class UserController { @RequestMapping(\u0026amp;quot;/feign\u0026amp;quot;) public String testFeign(HttpServletRequest request) { return \u0026amp;quot;hello tracer feign\u0026amp;quot;; } } New tracer-sample-with-openfeign-consumer Module Introducing dependence \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-openfeign/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"75d9940033ad3b4342eab9d5c7a191f1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","summary":"OpenFeign Integration In this document will demonstrate how to use SOFATracer to track of OpenFeign.\nPrepare Environment The versions of the framework components used in this case are as follows:\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 This case includes two submodules:\n tracer-sample-with-openfeign-provider service provider tracer-sample-with-openfeign-consumer service consumer New SOFABoot project as parent project After creating a Spring Boot project, you need to introduce the SOFABoot\u0026rsquo;s dependency.","tags":null,"title":"OpenFeign Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/","wordcount":368},{"author":null,"categories":null,"content":" OpenFeign Log Format SOFATracer integrates Spring Cloud OpenFeign and outputs the requested link log data format. The default is JSON data format.\nSpring Cloud OpenFeign digest log（feign-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code error error massage req.size.bytes Request Body Size resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.host remote host remote.port remote port component.client.impl component name baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-03-28 18:08:06.800\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe88f1553767685981100124403\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.232.143:8800/feign\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:18,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:206,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8082-exec-1\u0026amp;quot;,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.232.143\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;8800\u0026amp;quot;,\u0026amp;quot;component.client.impl\u0026amp;quot;:\u0026amp;quot;open-feign\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring Cloud OpenFeign stat log（feign-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success ; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-03-28 18:09:06.800\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.232.143:8800/feign\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:206,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;Y\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-openfeign/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"81864817e297a7bf019705c72f8ff0a8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","summary":"OpenFeign Log Format SOFATracer integrates Spring Cloud OpenFeign and outputs the requested link log data format. The default is JSON data format.\nSpring Cloud OpenFeign digest log（feign-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.","tags":null,"title":"OpenFeign log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/","wordcount":190},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 Spring Cloud OpenFeign 进行埋点。\n基础环境 本案例使用的各框架组件的版本如下：\n Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 本案例包括两个子工程：\n tracer-sample-with-openfeign-provider 服务提供方 tracer-sample-with-openfeign-consumer 服务调用方 新建 SOFABoot 工程作为父工程 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 Maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n新建 tracer-sample-with-openfeign-provider 在工程模块的 pom 文件中添加 SOFATracer 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFATracer 版本受 SOFABoot 版本管控，如果使用的 SOFABoot 版本不匹配，则需要手动指定 tracer 版本，且版本需高于 3.0.4.\n 在工程的 application.properties 文件下添加相关参数 spring.application.name=tracer-provider server.port=8800 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-provider 简单的资源类\n@RestController public class UserController { @RequestMapping(\u0026amp;quot;/feign\u0026amp;quot;) public String testFeign(HttpServletRequest request) { return \u0026amp;quot;hello tracer feign\u0026amp;quot;; } } 新建 tracer-sample-with-openfeign-consumer 在工程模块的 pom 文件中添加 SOFATracer 依赖 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-zookeeper-discovery\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.cloud\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-cloud-starter-openfeign\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 在工程的 application.properties 文件下添加相关参数\nspring.application.name=tracer-consumer server.port=8082 spring.cloud.zookeeper.connect-string=localhost:2181 spring.cloud.zookeeper.discovery.enabled=true spring.cloud.zookeeper.discovery.instance-id=tracer-consumer 定义 feign 资源 @FeignClient(value = \u0026amp;quot;tracer-provider\u0026amp;quot;,fallback = FeignServiceFallbackFactory.class) public interface FeignService { @RequestMapping(value = \u0026amp;quot;/feign\u0026amp;quot;, method = RequestMethod.GET) …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-openfeign/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"75d9940033ad3b4342eab9d5c7a191f1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","summary":"在本文档将演示如何使用 SOFATracer 对 Spring Cloud OpenFeign 进行埋点。 基础环境 本案例使用的各框架组件的版本如下： Spring Cloud Greenwich.RELEASE SOFABoot 3.1.1/SpringBoot 2.1.0.RELEASE SOFATracer 3.0.4 JDK 8 本案例包括两个子工程： tracer-sample-with-openfeign-provider 服务提供方 tracer-sample-with-openfeign-consumer","tags":null,"title":"OpenFeign 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/","wordcount":602},{"author":null,"categories":null,"content":" SOFATracer 集成 Spring Cloud OpenFeign 后输出请求的链路数据格式，默认为 JSON 数据格式。\nSpring Cloud OpenFeign 摘要日志（feign-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method error 错误信息 req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:28:52.363\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477731347100110969\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8082-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;219ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.233.39:8800/feign\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;error\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:18,\u0026amp;quot;remote.host\u0026amp;quot;:\u0026amp;quot;10.15.233.39\u0026amp;quot;,\u0026amp;quot;remote.port\u0026amp;quot;:\u0026amp;quot;8800\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring Cloud OpenFeign 统计日志（feign-stat.log）ls stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:29:34.528\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;tracer-consumer\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://10.15.233.39:8800/feign\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:2,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:378,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-openfeign/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"81864817e297a7bf019705c72f8ff0a8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","summary":"SOFATracer 集成 Spring Cloud OpenFeign 后输出请求的链路数据格式，默认为 JSON 数据格式。 Spring Cloud OpenFeign 摘要日志（feign-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解","tags":null,"title":"OpenFeign 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-openfeign/","wordcount":341},{"author":null,"categories":null,"content":" MOSN\u0026amp;rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer Acknowledgement MOSN builds on open source projects such as Envoy and Istio, thanks to the efforts of the open source community.\n","date":-62135596800,"description":"","dir":"projects/mosn/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f25c59cbb758b4dae5de39e1f1c3a2f4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/mosn/overview/","summary":"MOSN\u0026rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/mosn/overview/","wordcount":245},{"author":null,"categories":null,"content":" MOSN\u0026amp;rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.\nCore competence Integrated with Istio Integrated with Istio 1.0 and V4 APIs to run based on full dynamic resource configuration Core forwarding Self-contained Web server Support TCP proxy Support TProxy mode Multi-protocol Support HTTP/1.1 and HTTP/2 Support SOFARPC Support Dubbo protocol (under development) Core routing Support Virtual Host routing Support Headers/URL/Prefix routing Support Host Metadata-based Subset routing Support retry Backend Management and load balancing Support connection pool Support throttling Support active backend health check Support load balancing strategies, such as Random and RR Support Host Metadata-based Subset load balancing strategy Observability Observe network data Observing protocol data TLS Support HTTP/1.1 on TLS Support HTTP/2.0 on TLS Support SOFARPC on TLS Process management + Support smooth reload + Support smooth upgrade Extension capability + Support custom private protocols + Support adding custom extensions in protocol at the TCP IO layer Acknowledgement MOSN builds on open source projects such as Envoy and Istio, thanks to the efforts of the open source community.\n","date":-62135596800,"description":"","dir":"projects/occlum/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1d8851c81ed6dacf04ebbe841d1b2835","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/occlum/overview/","summary":"MOSN\u0026rsquo;s official website mosn.io is under construction. The documents are temporarily hosted here.\nMOSN is a network proxy written in Golang. It can be used as a cloud-native network data plane, providing services with the following proxy functions: multi-protocol, modular, intelligent, and secure. MOSN is the short name of Modular Open Smart Network-proxy. MOSN can be integrated with any Service Mesh wich support xDS API. It can also be used as an independent Layer 4 or Layer 7 load balancer, API Gateway, cloud-native Ingress, etc.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/occlum/overview/","wordcount":245},{"author":null,"categories":null,"content":" Introduction SOFALookout is a lightweight and open source middleware service of Ant Financial that solves the metrics and monitoring issues of the system. The services it provides include: Event logging, collecting, processing, storing, and querying of Metrics. The open source project consists of two separate parts, the client and server side services.\nClient-side service SOFALookout Client is a Java SDK that helps developers log events of metrics in project code. It also allows you to view real-time status information for the Java application.\n +------------------+ Reg: API: | dimension meters +--------+ +------------------+ | flatmap +---------------------------+ +-----------\u0026amp;gt; | Default/DropwizardMetrics| | +---------------------------+ | | http +--------------+ +-----------\u0026amp;gt; |Lookout server| | +--------------+ +----------------------+ | add common tags dimension EXTS: | JVM,OS,GC... +----+ +----------------------+ Server-side services SOFALookout Server helps you solve system state metrics in a distributed environment. Its data sources include, but not limited to the projects that use the lookout-client package. The server will be available in the next release, so stay tuned.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/overview/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"8a8a8ef02ca95d4d11e3e4b195bbae70","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/overview/","summary":"Introduction SOFALookout is a lightweight and open source middleware service of Ant Financial that solves the metrics and monitoring issues of the system. The services it provides include: Event logging, collecting, processing, storing, and querying of Metrics. The open source project consists of two separate parts, the client and server side services.\nClient-side service SOFALookout Client is a Java SDK that helps developers log events of metrics in project code.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/overview/","wordcount":160},{"author":null,"categories":null,"content":" SOFARPC is a Java-based RPC service framework open sourced by Ant Financial, which provides remote service call between applications, high scalability and fault tolerance features. Currently, all RPC calls of Ant Financial businesses use SOFARPC. SOFARPC provides users with functions such as load balancing, traffic forwarding, link tracing, link data transparent transmission, and fault removal.\nIn addition, SOFARPC supports different protocols, currently including bolt, RESTful, dubbo, and H2C. Bolt is a network communication framework based on Netty developed by Ant Financial Services Group.\nImplementation principle When an SOFARPC application is started, if the current application needs to publish RPC services, SOFARPC will register these services to the service registry center. As shown in the figure, the service points to the Registry. When the SOFARPC application that references this service is started, it subscribes to the metadata information of the corresponding service from the service registry. After receiving the subscription request, the service registry will push the publisher\u0026amp;rsquo;s metadata list to the service reference party in real time. As shown in the figure, Register points to Reference. When the service reference party gets the addresses, it can pick up the address and initiate the call. As shown in the figure, Reference points to Service. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"62f0806ad40fcaaeab6a82470b14a2e2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/overview/","summary":"SOFARPC is a Java-based RPC service framework open sourced by Ant Financial, which provides remote service call between applications, high scalability and fault tolerance features. Currently, all RPC calls of Ant Financial businesses use SOFARPC. SOFARPC provides users with functions such as load balancing, traffic forwarding, link tracing, link data transparent transmission, and fault removal.\nIn addition, SOFARPC supports different protocols, currently including bolt, RESTful, dubbo, and H2C. Bolt is a network communication framework based on Netty developed by Ant Financial Services Group.","tags":null,"title":"Overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/overview/","wordcount":203},{"author":null,"categories":null,"content":" Introduction This sample project shows how to build an executable-ark-jar based on a springboot project with the tool of sofa-ark-maven-plugin.\nPreparation As this project depends on the ark-plugin generated by the project of sample-ark-plugin, please ensure the sample sample-ark-plugin installed in your local maven repository before run this project.\nTools The Maven plugin of sofa-ark-maven-plugin is provided to build a standard executable-ark-jar, and just needs some simple configurations. Its maven coordinates is:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Refer to the document of plugin use for details\n Step By Step Based on the sample project, we will describe step by step how to package a Spring Boot Web project to an executable Ark package\nCreating Spring Boot Web Project Download a standard Spring Boot Web project from the official website https://start.spring.io/\nIntroducing sample-ark-plugin Configure items as follows under the main pom.xml of the project, and add the Ark Plugin dependency generated from another sample project, reference documents\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configuring Packaging Plugin Configure the Maven plugin (sofa-Ark-maven-plugin) as follows under the main pom.xml of the project:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; In this sample project, we have configured only a fraction of the items, but they are enough to generate an executable Ark package. The meaning of each configuration item is shown below: * outputDirectory: the directory for the output Ark package files after packaging of mvn package;\n arkClassifier: the value of classifier included in the Maven coordinates of the Ark specified for release, which is null by default; Note that arkClassifier is null by default. If you do not specify a classifier, the Jar package uploaded to the repository is actually an executable Ark package. If you need to distinguish it from common packaging, you need to configure a value for this …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-demo/","fuzzywordcount":800,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2c97c409788f41051c79836d277997be","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","summary":"Introduction This sample project shows how to build an executable-ark-jar based on a springboot project with the tool of sofa-ark-maven-plugin.\nPreparation As this project depends on the ark-plugin generated by the project of sample-ark-plugin, please ensure the sample sample-ark-plugin installed in your local maven repository before run this project.\nTools The Maven plugin of sofa-ark-maven-plugin is provided to build a standard executable-ark-jar, and just needs some simple configurations. Its maven coordinates is:","tags":null,"title":"Package into Ark JAR","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/","wordcount":757},{"author":null,"categories":null,"content":" Introduction This sample project demonstrates how to use Maven plugins to package a general Java project into an Ark plugin that meets the standard specifications.\nBackground In actual development, dependency conflicts often occur. Suppose we have developed a class library named sample-lib, and it might conflict with the existing dependencies when the business application is imported. At this point, we hope the library can be isolated from other business dependencies, without negotiating with each other over dependency package versions. Ark Plugin is exactly the result of our best practice under this demand background. It runs on top of the Ark Container, which is loaded by a container. Any Ark Plugin is loaded by a separate ClassLoader to be isolated from each other. There are four concepts of Ark Plugin: * Import class: When the plugin starts up, a plugin used to export the class is first delegated to load the class. If that fails, it will attempt to load from inside this plugin;\n Export class: If the class has been imported by other plugins, it will be first loaded from this plugin;\n Import resource: When the plugin is searching for resources, a plugin used to export the class is first delegated to load the class. If that fails, it will attempt to load from inside this plugin.\n Export resource: If the resource has been imported by other plugins, it will be first loaded from this plugin;\n Refer to the plugin specifications for more details\n Tools Upon simple configurations, the officially provided Maven plugin sofa-ark-plugin-maven-plugin can package common Java projects into a standard-format Ark Plugin. The coordinates of Maven plugin are:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; For more information, see the plugin configuration document\n Getting started Based on this sample project, we will describe how to build an Ark plugin step by step.\nCreate a Standard Maven Project This is a standard Maven project consisting of two modules: * The common module: contains the plugin export class\n The plugin module: contains com.alipay.sofa.ark.spi.service.PluginActivator interface implementation class and a plugin service class. The plugin packaging tool sofa-ark-plugin-maven-plugin can be configured in the module\u0026amp;rsquo;s pom.xml file; Configuring Packaging Plugin Package the plugin in the pom.xml file according to the following configurations:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${project.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--can only configure no more than one activator--\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin-demo/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d8125843ced13352dd228299f222c74d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","summary":"Introduction This sample project demonstrates how to use Maven plugins to package a general Java project into an Ark plugin that meets the standard specifications.\nBackground In actual development, dependency conflicts often occur. Suppose we have developed a class library named sample-lib, and it might conflict with the existing dependencies when the business application is imported. At this point, we hope the library can be isolated from other business dependencies, without negotiating with each other over dependency package versions.","tags":null,"title":"Package into Ark Plugin","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/","wordcount":664},{"author":null,"categories":null,"content":"SOFA Mesh 项目 fork 了 Istio 项目，对 Pilot 的能力进行增强，目前在进行中的增强主要集中在下面三个方面： - 支持 Zookeeper 作为注册中心，并在此基础上支持 SOFA、DUBBO 等使用 Zookeeper 作为注册中心的微服务框架。 - 支持通用协议框架，使用一个通用协议，在 Kubernetes DNS 的基础上同时支持多种协议。 - 新增 register agent，支持 SOFA、DUBBO 和 HSF 的容器模型，即支持单个应用注册多个服务实例。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-readme/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7b098e394986596d8fb01e1fe2120829","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-readme/","summary":"SOFA Mesh 项目 fork 了 Istio 项目，对 Pilot 的能力进行增强，目前在进行中的增强主要集中在下面三个方面： - 支持 Zookeeper 作为注册中心，并在此基础上支持 SOFA、DUBBO","tags":null,"title":"Pilot 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-readme/","wordcount":168},{"author":null,"categories":null,"content":" Print traceId And spanId To Application Log SLF4J provides MDC (Mapped Diagnostic Contexts), which supports you to define and modify log output formats and content. This document introduces the SLF4J MDC feature integrated in SOFATracer, which allows you to output the current SOFATracer context TraceId and SpanId with simply modifying the log configuration file.\nPrerequisites In order to properly print the TraceId and SpanId parameters in the logs of the application, the log programming interface needs to be programmed for SLF4J. That is, the programming interface for printing log does not rely on specific log implementation.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Introduce dependency For SOFABoot or Spring Boot application, you need to introduce the specific log implementation. It is recommended to introduce Logback and Log4j2 instead of Log4j. Also, it is suggested to use only one log implementation rather than multiple implementations.\n Logback implementation: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Log4j2 implementation: \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-log4j2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!--SOFABoot does not control log4j2 version --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Configuration method The corresponding TraceId and SpanId are printed based on SLF4J MDC. First, the log programming interface in application should be oriented to SLF4J, as follows:\n/ / Introduce interface import org.slf4j.Logger; import org.slf4j.LoggerFactory; / / Construct log printing instance private static final Logger logger = LoggerFactory.getLogger(XXX.class); Second, to correctly print the TraceId and SpanId parameters, we also need to configure the extra parameters of PatternLayout in the log configuration file. The two parameters are %X{SOFA-TraceId} and %X. {SOFA-SpanId}, whose values ​​can be obtained from MDC.\npattern parameter configured with Logback as an example:\n\u0026amp;lt;pattern\u0026amp;gt;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId}, %X{SOFA-SpanId}] ---- %m%n\u0026amp;lt;/pattern\u0026amp;gt; Key configuration items: As a part of the Logback pattern, [%X{SOFA-TraceId},%X{SOFA-SpanId}] replaces the placeholders in the pattern with the specific TraceId and SpanId in the current thread process when the corresponding appender is called. If there is no corresponding TraceId and SpanId in the current thread, the placeholder is replaced with \u0026amp;ldquo;null\u0026amp;rdquo;. Log4j2 PatternLayout configuration sample:\n\u0026amp;lt;PatternLayout pattern=\u0026amp;quot;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId},%X{SOFA-SpanId}] ---- %m%n \u0026amp;quot; /\u0026amp;gt; Log4j PatternLayout configuration sample:\n\u0026amp;lt;layout class=\u0026amp;quot;org.apache.log4j.PatternLayout\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;param …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/print-traceid-spanid/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0d8cc680f811d1db2cffddbba269571c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","summary":"Print traceId And spanId To Application Log SLF4J provides MDC (Mapped Diagnostic Contexts), which supports you to define and modify log output formats and content. This document introduces the SLF4J MDC feature integrated in SOFATracer, which allows you to output the current SOFATracer context TraceId and SpanId with simply modifying the log configuration file.\nPrerequisites In order to properly print the TraceId and SpanId parameters in the logs of the application, the log programming interface needs to be programmed for SLF4J.","tags":null,"title":"Print traceId and spanId in application log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/","wordcount":360},{"author":null,"categories":null,"content":"Describe several methods to use SOFARPC in different environments. * Use API in non-Spring environment * Use XML in SOFABoot environment * Use Annotation in SOFABoot environment * Use dynamic API in SOFABoot environment\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programming/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"9a947dae761c84aa4d95121c076ac552","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programming/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programming/","summary":"Describe several methods to use SOFARPC in different environments. * Use API in non-Spring environment * Use XML in SOFABoot environment * Use Annotation in SOFABoot environment * Use dynamic API in SOFABoot environment","tags":null,"title":"Programming","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programming/","wordcount":34},{"author":null,"categories":null,"content":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-samples/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"600c182fdee786a59e14899ba0fce8a1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-run-samples/","summary":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-run-samples/","wordcount":42},{"author":null,"categories":null,"content":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-run-samples/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"93784b2fca67986e00aa3bc5ea0dbb6b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-run-samples/","summary":" Configure HTTP protocol Mesher See the sample project that MOSN forwards HTTP http-sample. Configure SOFARPC protocol Mesher See the sample project that MOSN forwards SOFARPC sofarpc-sample. Configure TCP protocol Mesher See the sample project that MOSN serves as a TCP Proxy tcpproxy-sample. ","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-run-samples/","wordcount":42},{"author":null,"categories":null,"content":" Some sample projects are provided in the source project to assist in the use of the project. The readme file of the sample project has additional instructions for use, and you need to import these sample projects separately into IDE.\nClient-side sample project lookout-client-samples-java  This sample project demonstrates how to use and configure the client in code form in a normal Java project.\n lookout-client-samples-boot  This sample project demonstrates how to use and configure the client in a SpringBoot (or SofaBoot) project.\n lookout-client-samples-prometheus  The sample project demonstrates how to use and configure the client to use prometheus in a SpringBoot (or SofaBoot) project.\nServer-side sample project ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-samples/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a8a0fcd3f99ce2fb46e4d543e30797c9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","summary":"Some sample projects are provided in the source project to assist in the use of the project. The readme file of the sample project has additional instructions for use, and you need to import these sample projects separately into IDE.\nClient-side sample project lookout-client-samples-java  This sample project demonstrates how to use and configure the client in code form in a normal Java project.\n lookout-client-samples-boot  This sample project demonstrates how to use and configure the client in a SpringBoot (or SofaBoot) project.","tags":null,"title":"Project sample","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/","wordcount":105},{"author":null,"categories":null,"content":" SOFABoot provides developers with three ways to publish and reference JVM services\n XML Annotation Programming API XML Service Publish First, we need to define a Bean:\n\u0026amp;lt;bean id=\u0026amp;quot;sampleService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026amp;quot;\u0026amp;gt; Then, publish the Bean as a SOFA JVM service by using the Spring extension tag provided by SOFA.\n\u0026amp;lt;sofa:service interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; ref=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; In the preceding configuration, the interface parameter indicates the interface for releasing services, and the ref parameter indicates the Bean to be published as a JVM service.\nAt this point, we have published a JVM service success.\nService Reference We can also reference a JVM service by using the Spring extension tag provided by SOFA.\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofa.runtime.test.service.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.jvm/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; In the preceding configuration, the interface parameter indicates the service interface, which must be consistent with that configured during the service publish. The meaning of the ID attribute is the same as Spring BeanId. A Spring Bean with the ID sampleServiceRef will be generated from the above configuration. We can inject it anywhere in the Spring context of the current SOFABoot module.\n service/reference tag also supports RPC service publish, with related document: RPC Service Publish and Reference\n Annotation Warning\nIf a service has been annotated with @SofaService, it cannot be published in the mode of XML. Choose one mode to publish the service instead of a mixture of two modes.\n In addition to publishing JVM services and reference through XML, SOFABoot also provides Annotation for JVM services publish and reference. To publish JVM services through Annotation, we only need to add an annotation @SofaService to the implementation class, as follows:\n@SofaService public class SampleImpl implements SampleInterface { public void test() { } } Prompt\n@SofaService is used to publish a Spring Bean as a JVM service, which means that although you may not write the configuration of \u0026amp;lt;sofa:service/\u0026amp;gt;, you still need to configure the class annotated with @SofaService as a Spring Bean.\n When configuring \u0026amp;lt;sofa:service/\u0026amp;gt; in the XML mode, you have configured an interface for the service. However, when using the @SofaService annotation, you haven\u0026amp;rsquo;t configured the service interface. This is because when the class annotated with @SofaService has implemented only one interface, the framework directly uses the interface as the service interface. What if the class annotated with @SofaService has implemented multiple interfaces? In this case, you can set the interfaceType field of @SofaService to specify the service interface, as shown below: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/module-service/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"527472fbe57ce450e4e2b41d878704cb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/module-service/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/module-service/","summary":"SOFABoot provides developers with three ways to publish and reference JVM services\n XML Annotation Programming API XML Service Publish First, we need to define a Bean:\n\u0026lt;bean id=\u0026quot;sampleService\u0026quot; class=\u0026quot;com.alipay.sofa.runtime.test.service.SampleServiceImpl\u0026quot;\u0026gt; Then, publish the Bean as a SOFA JVM service by using the Spring extension tag provided by SOFA.\n\u0026lt;sofa:service interface=\u0026quot;com.alipay.sofa.runtime.test.service.SampleService\u0026quot; ref=\u0026quot;sampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.jvm/\u0026gt; \u0026lt;/sofa:service\u0026gt; In the preceding configuration, the interface parameter indicates the interface for releasing services, and the ref parameter indicates the Bean to be published as a JVM service.","tags":null,"title":"Publish and reference JVM services","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/module-service/","wordcount":1001},{"author":null,"categories":null,"content":" To run this demo, you should sign up an Ant Financial technology account. Please see Ant Finanical Official Site to see more details.\nDemo content Service Mesh applies the communication capabilities between services to the infrastructure, thus decoupling and lightweighting applications.\nHowever, Service Mesh itself is still complex. CloudMesh can easily implement Service Mesh technology by hosting Service Mesh on the cloud.\nWith our workshop, you can easily deploy applications developed in multiple programming languages ​​to CloudMesh, thereby experiencing the capabilities of Service Mesh. The capabilities include accessing services, monitoring traffic, experiencing service goverance, managing Sidecar, and gray release of new versions of services.\nThis demo focuses on the powerful traffic control capability of CloudMesh. In the process of gray release, you can precisely control the gray traffic ratio, and monitor the actual traffic trend in CloudMesh:\nThe general gray release function occupies twice capacity in the gray process.\nThe gray release function of CloudMesh does not need to occupy extra capacity in gray release process, and also allows pausing the release process to modify gray ratio multiple times.\nOperation guide For convenience, we have prepared a detailed operation guide for this demo.\nClick here to visit online version.\n","date":-62135596800,"description":"This guide introduces how to quickly deploy applications to CloudMesh, access services, monitor traffic, experience service governance, manage Sidecar, and perform gray release of new versions of services.","dir":"guides/kc-cloud-mesh-demo/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e389a65e6736e909718275cd76505525","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-cloud-mesh-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/guides/kc-cloud-mesh-demo/","summary":"To run this demo, you should sign up an Ant Financial technology account. Please see Ant Finanical Official Site to see more details.\nDemo content Service Mesh applies the communication capabilities between services to the infrastructure, thus decoupling and lightweighting applications.\nHowever, Service Mesh itself is still complex. CloudMesh can easily implement Service Mesh technology by hosting Service Mesh on the cloud.\nWith our workshop, you can easily deploy applications developed in multiple programming languages ​​to CloudMesh, thereby experiencing the capabilities of Service Mesh.","tags":null,"title":"Put Service Mesh into practice with CloudMesh","type":"guides","url":"/sofastack.tech/en/guides/kc-cloud-mesh-demo/","wordcount":199},{"author":null,"categories":null,"content":" This topic comprises four parts:\n Part 1: Install the ACTS IDE visual editor on Intellij IDEA. Part 2: Import the ACTS dependency to a multi-module project. Part 3: Establish the ACTS framework in the test module to manage ACTS test cases. Part 4: Generate the ACTS test script. 1. Install ACTS IDE We recommend that you use Intellij IDEA 2017. For the sake of your data security, please download the ACTS IDE installation package from the following source only: Click to download ACTS IDE.\nLocal installation: Choose Preferences \u0026amp;gt; Plugins. Install the plugin from disk and restart Intellij IDEA. 2. Import the ACTS dependency Before introducing the dependencies, make sure your application is a multi-module project (including the test module). After you import the dependency, ACTS places all test code under the test module for convenient ACTS test case management.\nYou can read the following information based on the actual situation of your application:\nIf your application is a complete multi-module project, you can refer to section 2.1 to import the ACTS dependency. If your application is a multi-module project without a test module, you can refer to section 2.2 to quickly create a test module. If your application is not a multi-module project, you can refer to section 2.3 to quickly create a multi-module project. If you have not created a project yet, you can use SOFABoot to quickly create an application.\n2.1 Multi-module application - with the test module You only need to import acts-bom to the pom.xml file of the test module.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2 Multi-module application - without the test module Here, Intellij IDEA is used to create the submodule.\nRight click the parent project, choose New \u0026amp;gt; Module, and enter the name for the test module, which follows the pattern of appname-test. The step-by-step procedure is illustrated in the following figures.\nStep 1: Create a test module Step 2: Manage the test module Manage the test module that you have created in the pom.xml file under the parent project.\nStep 3: Import the ACTS dependency Find the test module that you just created and import acts-bom to its pom.xml file.\n\u0026amp;lt;! -- Import the pom file that contains SOFABootApplication --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.example\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;example-service\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;! -- Import the ACTS dependency --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.3 Single-module application If you already have a sound single-module SOFABoot application, you can quickly create a multi-module project based on the existing project in the following …","date":-62135596800,"description":"","dir":"projects/sofa-acts/getting-started/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dfc5fb9b394ea14c280568dcb881a8b0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/getting-started/","summary":"This topic comprises four parts:\n Part 1: Install the ACTS IDE visual editor on Intellij IDEA. Part 2: Import the ACTS dependency to a multi-module project. Part 3: Establish the ACTS framework in the test module to manage ACTS test cases. Part 4: Generate the ACTS test script. 1. Install ACTS IDE We recommend that you use Intellij IDEA 2017. For the sake of your data security, please download the ACTS IDE installation package from the following source only: Click to download ACTS IDE.","tags":null,"title":"Quick start","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/getting-started/","wordcount":650},{"author":null,"categories":null,"content":" This topic helps you quickly download, install, and use SOFADashboard on your computer.\nPrepare the environment sofa-dashboard-backend needs to be run in a Java environment. Make sure that it can be used normally in the following runtime environments:\n JDK 1.8+: Download and Configure. Maven 3.2.5+: Download and Configure. sofa-dashboard-frontend uses the Ant Design Pro scaffold. For more information about the frontend environment, see Ant Design.\nInitialize the database MySQL version: 5.6+\n SOFAArk control uses MySQL for resource data storage. You can find the SofaDashboardDB.sql script under the project directory and run this script to initialize database tables.\nZooKeeper ZooKeeper 3.4.x and ZooKeeper 3.5.x\n Service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper, therefore you need to start the ZooKeeper service locally. For more information, see ZooKeeper Document.\nRun the backend project \u0026amp;gt; git clone https://github.com/sofastack/sofa-dashboard.git \u0026amp;gt; cd sofa-dashboard \u0026amp;gt; mvn clean package -DskipTests \u0026amp;gt; cd sofa-dashboard-backend/sofa-dashboard-web/target/ \u0026amp;gt; java -jar sofa-dashboard-web-1.0.0-SNAPSHOT.jar Run the frontend project sofa-dashboard-front is the frontend code-based project of SOFADashboard. It is developed based on the open-source frontend framework antd of Ant Financial.\n\u0026amp;gt; cd sofa-dashboard-front \u0026amp;gt; npm i \u0026amp;gt; npm start ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/quick-start/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fa4c5f48810727f71d675255f19617a3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/quick-start/","summary":"This topic helps you quickly download, install, and use SOFADashboard on your computer.\nPrepare the environment sofa-dashboard-backend needs to be run in a Java environment. Make sure that it can be used normally in the following runtime environments:\n JDK 1.8+: Download and Configure. Maven 3.2.5+: Download and Configure. sofa-dashboard-frontend uses the Ant Design Pro scaffold. For more information about the frontend environment, see Ant Design.\nInitialize the database MySQL version: 5.","tags":null,"title":"Quick start","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/quick-start/","wordcount":186},{"author":null,"categories":null,"content":" This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment. Install Go\u0026amp;rsquo;s build environment. Install dep. See the official installation documentation. Get codes The codes for the MOSN project are hosted in GitHub and can be obtained in the following way:\ngo get mosn.io/mosn If an error occurs when run \u0026amp;ldquo;go get\u0026amp;rdquo;, just create the project manually.\n# Enter src dirctory under GOPATH cd $GOPATH/src # Create mosn.io dirctory mkdir -p mosn.io cd mosn.io # clone MOSN codes git clone git@github.com:mosn/mosn.git cd sofa-mosn The final path of MOSN source codes is $GOPATH/src/mosn.io/mosn.\nImport by using IDE Use the Golang IDE to import the $GOPATH/src/mosn.io/mosn project. Goland is recommended.\nCompile codes In the project root directory, select the following command to compile the MOSN binary file according to your machine type and the environment where you want to execute binary:\nCompile with Docker image\nmake build // compile linux 64bit executable binary non-docker, local compilation\nCompile local executable binary files.\nmake build-local Non-Linux machine compiles Linux 64-bit executable binary files crosswise.\nmake build-linux64 Non-Linux machine compiles Linux 32-bit executable binary files crosswise.\nmake build-linux32 Once compiled, the compiled binary files can be found in the build/bundles/${version}/binary directory.\nCreate image Run the following command to create an image:\nmake image Run test In the project root directory, run the unit test:\nmake unit-test In the project root directory, run the integrate test(slow):\nmake integrate Start MOSN from configuration file ./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; Start MOSN forwarding sample program See the sample project in the examples directory.\nUse MOSN to build a Service Mesh platform See Integrate Istio.\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-setup/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d41615315adb522aa4b84762f113a574","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-setup/","summary":"This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-setup/","wordcount":325},{"author":null,"categories":null,"content":" This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment. Install Go\u0026amp;rsquo;s build environment. Install dep. See the official installation documentation. Get codes The codes for the MOSN project are hosted in GitHub and can be obtained in the following way:\ngo get mosn.io/mosn If an error occurs when run \u0026amp;ldquo;go get\u0026amp;rdquo;, just create the project manually.\n# Enter src dirctory under GOPATH cd $GOPATH/src # Create mosn.io dirctory mkdir -p mosn.io cd mosn.io # clone MOSN codes git clone git@github.com:mosn/mosn.git cd sofa-mosn The final path of MOSN source codes is $GOPATH/src/mosn.io/mosn.\nImport by using IDE Use the Golang IDE to import the $GOPATH/src/mosn.io/mosn project. Goland is recommended.\nCompile codes In the project root directory, select the following command to compile the MOSN binary file according to your machine type and the environment where you want to execute binary:\nCompile with Docker image\nmake build // compile linux 64bit executable binary non-docker, local compilation\nCompile local executable binary files.\nmake build-local Non-Linux machine compiles Linux 64-bit executable binary files crosswise.\nmake build-linux64 Non-Linux machine compiles Linux 32-bit executable binary files crosswise.\nmake build-linux32 Once compiled, the compiled binary files can be found in the build/bundles/${version}/binary directory.\nCreate image Run the following command to create an image:\nmake image Run test In the project root directory, run the unit test:\nmake unit-test In the project root directory, run the integrate test(slow):\nmake integrate Start MOSN from configuration file ./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; Start MOSN forwarding sample program See the sample project in the examples directory.\nUse MOSN to build a Service Mesh platform See Integrate Istio.\n","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-setup/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"cd757e2e2cca38a99b2de1c0be1f6807","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-setup/","summary":"This article is intended to help developers who are new to the MOSN project to quickly build a development environment, and compile, test, package, and run sample code.\nNote: MOSN is developed based on Go 1.12.7 and uses dep for dependency management.\nPrepare running environment If you use a container to run MOSN, you must install Docker first. If you use a local machine, you must use a Unix-like environment.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-setup/","wordcount":325},{"author":null,"categories":null,"content":" In this document, we will create a Spring Boot project and introduce the basic dependencies of SOFABoot as well as its Health Check expansion capability, to demonstrate how to get started quickly with SOFABoot.\nEnvironment Preparation To use SOFABoot, we need to prepare the basic environment first. SOFABoot depends on the following environment: - JDK7 or JDK8 - Needs to be compiled with Apache Maven 3.2.5 or above\nCreate Project SOFABoot is directly built on Spring Boot, so it can be generated by Spring Boot Generators. In this document, we need to add a web dependency for final view of its effect in the browser.\nAdd SOFABoot dependencies When creating a Spring Boot project, we need to import SOFABoot dependencies. First, extract the \u0026amp;lsquo;zip\u0026amp;rsquo; package of the project generated above and modify the \u0026amp;lsquo;pom.xml\u0026amp;rsquo; file, or the maven project configuration file. Replace\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; as:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Here, ${sofa.boot.version} denotes the SOFABoot version (please refer to release note). Then, add a SOFABoot dependency of Health Check extension and Spring Boot Web Starter.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Finally, configure parameters commonly used in the SOFABoot project in the application.properties file. The spring.application.name parameter is required to name the current application; the logging path specifies the output directory for logging information.\n# Application Name spring.application.name=SOFABoot Demo # logging path logging.path=./logs Advice to refer to the SOFABoot Module document before learn this demo.\nRun it We can import the project into IDE and run the \u0026amp;lsquo;main\u0026amp;rsquo; method in the generated project (generally in the XXXApplication class) to start the application, or we can execute the mvn spring-boot:run command under the project\u0026amp;rsquo;s root directory, which will print the startup logging in the console:\n2018-04-05 21:36:26.572 INFO ---- Initializing ProtocolHandler [\u0026amp;quot;http-nio-8080\u0026amp;quot;] 2018-04-05 21:36:26.587 INFO ---- Starting ProtocolHandler [http-nio-8080] 2018-04-05 21:36:26.608 INFO ---- Using a shared selector for servlet write/read 2018-04-05 21:36:26.659 INFO ---- Tomcat started on port(s): 8080 (http) We can browse http://localhost:8080/sofaboot/versions to view the version summary generated by Maven plugin in SOFABoot. The result is …","date":-62135596800,"description":"","dir":"projects/sofa-boot/quick-start/","fuzzywordcount":1400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7f582b905fde4a56791c03d4dd6b5a57","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/quick-start/","summary":"In this document, we will create a Spring Boot project and introduce the basic dependencies of SOFABoot as well as its Health Check expansion capability, to demonstrate how to get started quickly with SOFABoot.\nEnvironment Preparation To use SOFABoot, we need to prepare the basic environment first. SOFABoot depends on the following environment: - JDK7 or JDK8 - Needs to be compiled with Apache Maven 3.2.5 or above\nCreate Project SOFABoot is directly built on Spring Boot, so it can be generated by Spring Boot Generators.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/quick-start/","wordcount":1381},{"author":null,"categories":null,"content":" SOFATracer integration component list reference:Introduction To SOFATracer, Please pay attention to the SOFATracer version and JDK version of different components when using.\nPrepare Environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: - JDK7 or JDK8 - Apache Maven 3.2.5+ required for compilation\nSamples List The following Samples projects are all SOFABoot projects (also supported in the SpringBoot project). For information on how to create SOFABoot projects, please refer to SOFABoot quick start.\n Component Integration Spring MVC Integration HttpClient Integration DataSource Integration RestTemplate Integration OkHttp Integration SOFARPC Integration Dubbo Integration Spring Cloud OpenFeign Integration Sampling Report Data To Zipkin ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/componentaccess/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"42fbb0f6b6d459b7b04d45cad143d4ff","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/componentaccess/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/componentaccess/","summary":"SOFATracer integration component list reference:Introduction To SOFATracer, Please pay attention to the SOFATracer version and JDK version of different components when using.\nPrepare Environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: - JDK7 or JDK8 - Apache Maven 3.2.5+ required for compilation\nSamples List The following Samples projects are all SOFABoot projects (also supported in the SpringBoot project). For information on how to create SOFABoot projects, please refer to SOFABoot quick start.","tags":null,"title":"Quick start guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/componentaccess/","wordcount":108},{"author":null,"categories":null,"content":" This project demonstrates how to use SOFALookout in SOFABoot and connect to the Actuator of Spring Boot. If you want to connect to Prometheus or other Registry, see the Registry section.\nCreate a SpringBoot (or SofaBoot) project Create a new Spring Boot application (In case of SOFABoot project, import to SOFABoot as described in SOFABoot Documentation - Dependency Management.\nIntroduce Lookout\u0026amp;rsquo;s Starter dependency Introduce the following dependency in pom.xml:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; In case of Spring Boot project, it is required to specify a version.\nCreate a Metrics indicator After completing the introduction of dependencies, you can add the following methods to the startup class in Spring Boot:\n@Autowired private Registry registry; @PostConstruct public void init() { Counter counter = registry.counter(registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;).withTag(\u0026amp;quot;instant\u0026amp;quot;, NetworkUtil.getLocalAddress().getHostName())); counter.inc(); } The above code directly injects a Registry field through @Autowired. Through the Registry field, you can create the corresponding Counter, and then modify the Counter data to generate the Metrics of the SOFALookout.\nAdd configuration item In SOFABoot project, you need to add a configuration item for the application name: spring.application.name=xxx.\nConnect to Spring Boot Actuator After adding a new indicator, you can choose to connect to the Spring Boot Actuator. Then the following dependency is required:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; After adding the above dependency, you can launch the application locally, visit http://localhost:8080/metrics, and you can see the metrics added earlier, as follows:\n\u0026amp;quot;http_requests_total.instant-MacBook-Pro-4.local\u0026amp;quot;: 1, The above codes are at lookout-client-samples-boot, you can Download them as a reference.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-boot/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"27e057f8a8a4ac97f42ea66ca6a17fdd","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","summary":"This project demonstrates how to use SOFALookout in SOFABoot and connect to the Actuator of Spring Boot. If you want to connect to Prometheus or other Registry, see the Registry section.\nCreate a SpringBoot (or SofaBoot) project Create a new Spring Boot application (In case of SOFABoot project, import to SOFABoot as described in SOFABoot Documentation - Dependency Management.\nIntroduce Lookout\u0026rsquo;s Starter dependency Introduce the following dependency in pom.xml:","tags":null,"title":"Quick start guide for SOFABoot project","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/","wordcount":244},{"author":null,"categories":null,"content":" Quick start for client Common Java Project Add the Maven dependency of the client to the application:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Lookout-client relies on the lookout-reg-server module by default (supports reporting metrics data to the lookout server). If you want to use a different type of registry (such as lookout-reg-prometheus), then add the corresponding dependency.\nBefore starting to use the SOFALookout Client, you must firstly build a global client instance (com.alipay.lookout.client.DefaultLookoutClient).\nLookoutConfig lookoutConfig = new LookoutConfig(); DefaultLookoutClient client = new DefaultLookoutClient(\u0026amp;quot;appName\u0026amp;quot;); // Choose to build the Registry you need to use (if you need multiple registry types, it is recommended to use the same lookoutConfig instance for centralized management). LookoutRegistry lookoutRegistry = new LookoutRegistry(lookoutConfig); // Client can add a registry instance (at least one) after the client is created. client.addRegistry(lookoutRegistry); // (Optional) Uniformly register the metrics of extended modules for the registry instances that have been added or will be added to the client. client.registerExtendedMetrics(); Then get the Registry instance through the client and use it:\n// The registry is a \u0026amp;quot;combination\u0026amp;quot; registry Registry registry = client.getRegistry(); //demo Id id = registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;); Counter counter = registry.counter(id); counter.inc(); For the use of the client, see Project sample.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-java/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5dc476aa21ece4789859f1af598d4445","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","summary":"Quick start for client Common Java Project Add the Maven dependency of the client to the application:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa.lookout\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;lookout-client\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${lookout.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Lookout-client relies on the lookout-reg-server module by default (supports reporting metrics data to the lookout server). If you want to use a different type of registry (such as lookout-reg-prometheus), then add the corresponding dependency.\nBefore starting to use the SOFALookout Client, you must firstly build a global client instance (com.","tags":null,"title":"Quick start guide for common Java project","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/","wordcount":197},{"author":null,"categories":null,"content":" For REST，we provide a Filter to support cors now.\nSOFARPC API Usage For users who use SOFARPC API directly，they can add parameters in ServerConfig.\nMap\u0026amp;lt;String,String\u0026amp;gt; parameters=new HashMap\u0026amp;lt;String, String\u0026amp;gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026amp;quot;abc.com,cdf.com\u0026amp;quot;); serverConfig.setParameters(parameters); XML Usage You can add this configuration to application.properties\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-cors/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"549f73920842ebb121abf87566761c47","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-cors/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-cors/","summary":" For REST，we provide a Filter to support cors now.\nSOFARPC API Usage For users who use SOFARPC API directly，they can add parameters in ServerConfig.\nMap\u0026lt;String,String\u0026gt; parameters=new HashMap\u0026lt;String, String\u0026gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026quot;abc.com,cdf.com\u0026quot;); serverConfig.setParameters(parameters); XML Usage You can add this configuration to application.properties\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com ","tags":null,"title":"REST Cors","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-cors/","wordcount":40},{"author":null,"categories":null,"content":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。如果希望有一个通用的 异常处理类，用来处理REST的某中异常类型的信息。可以实现一个REST 的处理类。如下示例是一个拦截SofaRpcException 的通用处理器。\n@PreMatching public class CustomExceptionMapper implements ExceptionMapper\u0026amp;lt;SofaRpcException\u0026amp;gt; { @Override public Response toResponse(SofaRpcException exception) { return Response.status(500).entity(exception.getMessage()).build(); } } 并将该处理器注册到JAXRSProviderManager中，时机可以在Main方法中。具体说明可以参考RESTful-Filter。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-exception/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0ff4ef4139b228537d2ce4d52a213651","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-exception/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-exception/","summary":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。如果希望有一个通用的 异常处理类，用来处理REST的某中异常类型的","tags":null,"title":"REST Exception","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-exception/","wordcount":204},{"author":null,"categories":null,"content":"For REST, we designed a JAXRSProviderManager manager class. It takes effect on the server when the service starts.\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider For the user-defined Filter class, you can call it after the initialization is complete.\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance To register filter, since the custom Filter follows REST specification, you need to implement the following interface:\njavax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.container.ContainerRequestFilter After the REST server is started, if using bare SOFARPC, you need to register filter first before starting the service. In SOFABoot environment, it is similar. The specific encoding method is as follows:\ncom.alipay.sofa.rpc.server.rest.TraceRequestFilter com.alipay.sofa.rpc.server.rest.TraceResponseFilter ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-filter/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"53eb86b2504bf3beda2aca24437d6dab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful-filter/","summary":"For REST, we designed a JAXRSProviderManager manager class. It takes effect on the server when the service starts.\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider For the user-defined Filter class, you can call it after the initialization is complete.\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance To register filter, since the custom Filter follows REST specification, you need to implement the following interface:\njavax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.container.ContainerRequestFilter After the REST server is started, if using bare SOFARPC, you need to register filter first before starting the service.","tags":null,"title":"REST filter","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful-filter/","wordcount":89},{"author":null,"categories":null,"content":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。\ncom.alipay.sofa.rpc.server.rest.RestServer#registerProvider 对于用户自定义的 Filter 类，可以在初始化完成后，调用\ncom.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance 进行注册，其中自定义的 Filter 遵循 REST 的规范，需要实现如下接口：\njavax.ws.rs.container.ContainerResponseFilter 或者 javax.ws.rs.container.ContainerRequestFilter REST server 启动之后，对于裸 SOFARPC 的使用，需要先注册，再启动服务。对于 SOFABoot 环境下的使用，也是类似的过程，具体的写法可以参考：\ncom.alipay.sofa.rpc.server.rest.TraceRequestFilter com.alipay.sofa.rpc.server.rest.TraceResponseFilter ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-filter/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"53eb86b2504bf3beda2aca24437d6dab","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-filter/","summary":"对于 REST，我们设计了一个 JAXRSProviderManager 管理器类。在服务端生效，生效时间为服务启动时。 com.alipay.sofa.rpc.server.rest.RestServer#registerProvider 对于用户自定义的 Filter 类，可以在初始化完成后，调用 com.alipay.sofa.rpc.config.JAXRSProviderManager#registerCustomProviderInstance 进行注册，其中","tags":null,"title":"REST 自定义 Filter","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-filter/","wordcount":152},{"author":null,"categories":null,"content":" 对于 REST，我们内置了一个跨域 Filter 的支持。\nSOFARPC API 使用 对于使用 SOFARPC API 的用户，可以在 ServerConfig 中添加一个参数表明即可\nMap\u0026amp;lt;String,String\u0026amp;gt; parameters=new HashMap\u0026amp;lt;String, String\u0026amp;gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026amp;quot;abc.com,cdf.com\u0026amp;quot;); serverConfig.setParameters(parameters); XML 方式使用 直接通过配置\ncom.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com 即可\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-cors/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"549f73920842ebb121abf87566761c47","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-cors/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-cors/","summary":"对于 REST，我们内置了一个跨域 Filter 的支持。 SOFARPC API 使用 对于使用 SOFARPC API 的用户，可以在 ServerConfig 中添加一个参数表明即可 Map\u0026lt;String,String\u0026gt; parameters=new HashMap\u0026lt;String, String\u0026gt;() parameters.put(RpcConstants.ALLOWED_ORIGINS,\u0026quot;abc.com,cdf.com\u0026quot;); serverConfig.setParameters(parameters); XML 方式使用 直接通过配置 com.alipay.sofa.rpc.rest.allowed.origins=a.com,b.com 即可","tags":null,"title":"REST 跨域","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-cors/","wordcount":70},{"author":null,"categories":null,"content":"SOFARPC supports RESTful protocol, making it convenient for users to publish an interface in the manner of RESTful. * Basic usage * Custom Filter * Integrate Swagger\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f238d7f58de0c4a0e12d566ea9e09f52","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/restful/","summary":"SOFARPC supports RESTful protocol, making it convenient for users to publish an interface in the manner of RESTful. * Basic usage * Custom Filter * Integrate Swagger","tags":null,"title":"RESTful","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/restful/","wordcount":27},{"author":null,"categories":null,"content":"SOFARPC 提供了 RESTful 协议的支持，可以让用户非常方便地将一个接口通过 RESTful 的方式发布出去。 * 基本使用 * 自定义 Filter * 通用异常处理 * 集成 Swagger\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f238d7f58de0c4a0e12d566ea9e09f52","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful/","summary":"SOFARPC 提供了 RESTful 协议的支持，可以让用户非常方便地将一个接口通过 RESTful 的方式发布出去。 * 基本使用 * 自定义 Filter * 通用异常处理 * 集成 Swagger","tags":null,"title":"RESTful 协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful/","wordcount":58},{"author":null,"categories":null,"content":" 在 SOFARPC 中，使用不同的通信协议即使用不同的 Binding 即可，如果需要使用 RESTful 协议，只要将 Binding 设置为 REST 即可。\n发布服务 在定义 RESTful 的服务接口的时候，需要采用 JAXRS 标准的注解在接口上加上元信息，比如下面的接口：\n@Path(\u0026amp;quot;sample\u0026amp;quot;) public interface SampleService { @GET @Path(\u0026amp;quot;hello\u0026amp;quot;) String hello(); } JAXRS 的标准的注解的使用方式可以参考 RESTEasy 的文档。\n 在定义好了接口之后，将接口的实现发布成一个服务，比如，通过 Annotation 的方式：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}) public class RestfulSampleServiceImpl implements SampleService { @Override public String hello() { return \u0026amp;quot;Hello\u0026amp;quot;; } } 如果要通过其他的方式发布服务，请参考 Bolt 协议基本使用。\n通过浏览器访问服务 在发布服务之后，用户可以通过浏览器来直接访问服务，对于上面的服务，访问的地址如下：\nhttp://localhost:8341/sample/hello SOFARPC 的 RESTful 服务的默认端口为 8341。\n引用服务 除了通过浏览器访问 SOFARPC 发布的 RESTful 服务之外，用户也可以通过 SOFARPC 标准的服务引用的方式来引用服务，比如通过 Annotation 的方式：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)) private SampleService sampleService; 如果要使用其他的方式引用服务，请参考 Bolt 协议基本使用。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-basic/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d41f976864ba8f8221f5b5d26f354d1c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-basic/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-basic/","summary":"在 SOFARPC 中，使用不同的通信协议即使用不同的 Binding 即可，如果需要使用 RESTful 协议，只要将 Binding 设置为 REST 即可。 发布服务 在定义 RESTful 的服务接口的时候，需要采用 JAXRS 标准的注","tags":null,"title":"RESTful 协议基本使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-basic/","wordcount":358},{"author":null,"categories":null,"content":"In SOFABoot, the RPC framework provides some configuration parameters at the application level, and supports application-level parameter configuration, such as port and thread pool, which are bound by Spring Boot\u0026amp;rsquo;s @ConfigurationProperties. The binding attribute class is com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties, and the configuration prefix is as follows:\nstatic final String PREFIX = \u0026amp;quot;com.alipay.sofa.rpc\u0026amp;quot;; Then in the application.properties file, you can currently configure the following options. Also, you can write the codes based on your own coding habits as well as according to the Spring Boot specification, camel, underline and so on.\n#Standalone fault tolerance com.alipay.sofa.rpc.aft.regulation.effective # Whether to enable standalone fault tolerance com.alipay.sofa.rpc.aft.degrade.effective # Whether to enable degradation com.alipay.sofa.rpc.aft.time.window # Time window com.alipay.sofa.rpc.aft.least.window.count # Minimum number of calls com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple # minimum exception rate com.alipay.sofa.rpc.aft.weight.degrade.rate # Degradation rate com.alipay.sofa.rpc.aft.weight.recover.rate # Recovery rate com.alipay.sofa.rpc.aft.degrade.least.weight #Minimum degrading weight com.alipay.sofa.rpc.aft.degrade.max.ip.count # Maximum number of degraded IPs # bolt com.alipay.sofa.rpc.bolt.port # bolt port com.alipay.sofa.rpc.bolt.thread.pool.core.size # Number of bolt core threads com.alipay.sofa.rpc.bolt.thread.pool.max.size # Maximum number of bolt threads com.alipay.sofa.rpc.bolt.thread.pool.queue.size # bolt thread pool queue com.alipay.sofa.rpc.bolt.accepts.size # Number of connections that server allows client to establish # rest com.alipay.sofa.rpc.rest.hostname # rest hostname com.alipay.sofa.rpc.rest.port # rest port com.alipay.sofa.rpc.rest.io.thread.size # Number of rest io threads com.alipay.sofa.rpc.rest.context.path # rest context path com.alipay.sofa.rpc.rest.thread.pool.core.size # Number of rest core threads com.alipay.sofa.rpc.rest.thread.pool.max.size # Maximum number of rest threads com.alipay.sofa.rpc.rest.max.request.size # Maximum rest request size com.alipay.sofa.rpc.rest.telnet # Whether to allow rest telnet com.alipay.sofa.rpc.rest.daemon # Whether to hold the port. If true, exit with the main thread exit # dubbo com.alipay.sofa.rpc.dubbo.port # dubbo port com.alipay.sofa.rpc.dubbo.io.thread.size # dubbo io thread size com.alipay.sofa.rpc.dubbo.thread.pool.max.size # Maximum number of dubbo business threads com.alipay.sofa.rpc.dubbo.accepts.size # Number of connections that server allows client to establish com.alipay.sofa.rpc.dubbo.thread.pool.core.size #Number of dubbo core Threads com.alipay.sofa.rpc.dubbo.thread.pool.queue.size #Maximum number of dubbo threads # registry com.alipay.sofa.rpc.registry.address # Registry center address com.alipay.sofa.rpc.virtual.host # virtual host com.alipay.sofa.rpc.bound.host # bind host …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/application-rpc-config/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"bd19b2ced39a8deb802c13e525093fac","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","summary":"In SOFABoot, the RPC framework provides some configuration parameters at the application level, and supports application-level parameter configuration, such as port and thread pool, which are bound by Spring Boot\u0026rsquo;s @ConfigurationProperties. The binding attribute class is com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties, and the configuration prefix is as follows:\nstatic final String PREFIX = \u0026quot;com.alipay.sofa.rpc\u0026quot;; Then in the application.properties file, you can currently configure the following options. Also, you can write the codes based on your own coding habits as well as according to the Spring Boot specification, camel, underline and so on.","tags":null,"title":"RPC application parameter configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/","wordcount":381},{"author":null,"categories":null,"content":" ProviderConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (unique identifier) filterRef Filter configuration example List filter Filter configuration alias separated by commas registry Registry center on the server List methods Method-level configuration Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect. subscribe Whether to subscribe true It depends on the implementation and may not take effect. proxy Proxy type javassist As well as JDK dynamic proxy ref Service interface implementation class server server List, and it can be sent to multiple servers at once delay Time for delaying service publishing Service delay weight Service static weight include Included methods exclude Methods not included dynamic Whether to dynamically register priority Service priority bootstrap Service publishing starter bolt executor Custom thread pool timeout Execution timeout period for server concurrents Concurrent execution request Maximum number of parallel executable requests per method under interface. -1 indicates turning off the concurrent filter, and 0 means that filtering is enabled but not limited cacheRef Result cache implementation class mockRef Mock implementation class mock Whether to enable Mock validation Whether to enable parameter verification (jsr303) compress Whether to start compression false cache Whether to enable result caching false parameters Extra attributes Map\u0026amp;lt;String, String\u0026amp;gt; ConsumerConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (Unique identifier) filterRef Filter configuration example List filter Filter configuration alias List registry Registry center on the server List methods Method-level configuration Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect. subscribe Whether to subscribe true It depends on the implementation and may not take effect. proxy proxy type javassist As well as JDK dynamic proxy protocol Call protocol bolt Currently supports bolt, rest, dubbo directUrl Direct address Directly connected to register generic Whether to generalize calls false connectTimeout Timeout period for connection establishment 3000(cover 5000) disconnectTimeout Timeout period for disconnection 5000(cover …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-common/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2eb5963f4785f5f828f0e15759272971","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration-common/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/configuration-common/","summary":"ProviderConfig Attribute Name Default value Comment id ID Generated automatically application Application object Empty ApplicationConfig interfaceId Service interface (unique identifier) Use the actual interface class for both normal calls and return calls. uniqueId Service tag (unique identifier) filterRef Filter configuration example List filter Filter configuration alias separated by commas registry Registry center on the server List methods Method-level configuration Map\u0026lt;String, MethodConfig\u0026gt; serialization Serialization protocol hessian2 register Whether to register true It depends on the implementation and may not take effect.","tags":null,"title":"RPC publishing and reference configuration","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/configuration-common/","wordcount":1118},{"author":null,"categories":null,"content":" ProviderConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 uniqueId 服务标签（唯一标识元素） filterRef 过滤器配置实例 List filter 过滤器配置别名 多个用逗号隔开 registry 服务端注册中心 List methods 方法级配置 Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization 序列化协议 hessian2 register 是否注册 true 取决于实现，可能不生效。 subscribe 是否订阅 true 取决于实现，可能不生效。 proxy 代理类型 javassist 还有JDK动态代理 ref 服务接口实现类 server 服务端 List，可以一次发到多个服务端 delay 服务延迟发布时间 服务延迟 weight 服务静态权重 include 包含的方法 exclude 不包含的方法 dynamic 是否动态注册 priority 服务优先级 bootstrap 服务发布启动器 bolt executor 自定义线程池 timeout 服务端执行超时时间 concurrents 并发执行请求 接口下每方法的最大可并行执行请求数，配置-1关闭并发过滤器，等于0表示开启过滤但是不限制 cacheRef 结果缓存实现类 mockRef Mock实现类 mock 是否开启Mock validation 是否开启参数验证(jsr303) compress 是否启动压缩 false cache 是否启用结果缓存 false parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; ConsumerConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 uniqueId 服务标签（唯一标识元素） filterRef 过滤器配置实例 List filter 过滤器配置别名 List registry 服务端注册中心 List methods 方法级配置 Map\u0026amp;lt;String, MethodConfig\u0026amp;gt; serialization 序列化协议 hessian2 register 是否注册 true 取决于实现，可能不生效。 subscribe 是否订阅 true 取决于实现，可能不生效。 proxy 代理类型 javassist 还有JDK动态代理 protocol 调用的协议 bolt 目前支持bolt，rest，dubbo directUrl 直连地址 直连后register generic 是否泛化调用 false connectTimeout 建立连接超时时间 3000(cover 5000) disconnectTimeout 断开连接等等超时时间 5000(cover 10000) cluster 集群模式 failover connectionHolder 连接管理器实现 all loadBalancer 负载均衡算法 random lazy 是否延迟建立长连接 false sticky 是否使用粘性连接 false 跳过负载均衡算法使用上一个地址 inJVM 是否转为JVM调用 true JVM发现服务提供者，转为走本地 check 是否检查强依赖 false 无可用服务端启动失败 heartbeat 心跳间隔 30000 客户端给服务端发心跳间隔。取决于实现，可能不生效。 reconnect 重连间隔 10000 客户端重建端口长连接的间隔。取决于实现，可能不生效。 router 路由器配置别名 List routerRef 路由器配置实例 List bootstrap 服务引用启动器 bolt addressWait 等待地址获取时间 -1 取决于实现，可能不生效。 timeout 调用超时时间 3000(cover 5000) retries 失败后重试次数 0 跟集群模式有关，failover读取此参数。 invokeType 调用类型 sync onReturn 并发执行请求数 接口下每方法的最大可并行执行请求数，\n配置-1关闭并发过滤器，等于0表示开启过滤但是不限制 cacheRef 结果缓存实现类 mockRef Mock实现类 cache 是否启用结果缓存 false mock 是否开启Mock validation 是否开启参数验证 基于JSR303 compress 是否启动压缩 false parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; rejectedExecutionPolicy 回调线程池满拒绝策略 DISCARD DISCARD：默认丢弃，CALLER_RUNS：IO 线程继续执行任务，CALLER_HANDLE_EXCEPTION：IO 线程执行异常回调任务 @since 5.8.1 MethodConfig 属性 名称 默认值 备注 name 方法名 timeout 调用超时时间 null retries 失败后重试次数 null invokeType 调用类型 null validation 是否开启参数验证 null 基于JSR303 onReturn 返回时调用的SofaResponseCallback null 用于实现Callback等 concurrent 并发执行请求数 null 接口下每方法的最大可并行执行请求数，配置-1关闭并发过滤器，等于0表示开启过滤但是不限制。 validation 是否开启参数验证 null compress 是否启动压缩 null parameters 额外属性 Map\u0026amp;lt;String, String\u0026amp;gt; ServerConfig id Id 默认值 备注 protocol 协议 bolt 目前支持bolt，rest，dubbo host 主机 0.0.0.0 port 端口 12200 默认端口 bolt:12200, rest:8341, h2c:12300, dubbo:20880 contextPath …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-common/","fuzzywordcount":1900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2eb5963f4785f5f828f0e15759272971","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration-common/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration-common/","summary":"ProviderConfig 属性 名称 默认值 备注 id ID 自动生成 application 应用对象 空ApplicationConfig interfaceId 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置","tags":null,"title":"RPC 发布订阅配置","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration-common/","wordcount":1868},{"author":null,"categories":null,"content":"在 SOFABoot 的使用场景下，RPC 框架在应用层面，提供一些配置参数，支持的应用级别的参数配置，如端口，线程池等信息，都是通过 Spring Boot的@ConfigurationProperties 进行的绑定。绑定属性类是com.alipay.sofa.rpc.boot.config.SofaBootRpcProperties，配置前缀是\nstatic final String PREFIX = \u0026amp;quot;com.alipay.sofa.rpc\u0026amp;quot;; 那么在 application.properties 文件中，目前可以配置以下几个选项。其中使用者也可以根据自己的编码习惯，按照 Spring Boot的规范，按照驼峰，中划线等进行书写。\n单机故障剔除\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.aft.regulation.effective 是否开启单机故障剔除功能 Boolean false com.alipay.sofa.rpc.aft.degrade.effective 是否开启降级 Boolean false com.alipay.sofa.rpc.aft.time.window 时间窗口 Long 10 com.alipay.sofa.rpc.aft.least.window.count 最小调用次数 Long 10 com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple 最小异常率 Double 6.0 com.alipay.sofa.rpc.aft.weight.degrade.rate 降级速率 Double 0.05 com.alipay.sofa.rpc.aft.weight.recover.rate 恢复速率 Double 2.0 com.alipay.sofa.rpc.aft.degrade.least.weight 降级最小权重 Integer 1 com.alipay.sofa.rpc.aft.degrade.max.ip.count 最大降级 ip数量 Integer 2 Bolt\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.bolt.port bolt 端口 Integer 优先生效的是environment中是否设置rpc_tr_port，然后才是此处设置的值。默认12200 com.alipay.sofa.rpc.bolt.thread.pool.core.size bolt 核心线程数 Integer 20 com.alipay.sofa.rpc.bolt.thread.pool.max.size bolt 最大线程数 Integer 200 com.alipay.sofa.rpc.bolt.thread.pool.queue.size bolt 线程池队列 Integer 0 com.alipay.sofa.rpc.bolt.accepts.size bolt 服务端允许客户端建立的连接数 Integer 必须大于0，默认100000 com.alipay.sofa.rpc.bolt.process.in.io.thread bolt 服务端业务处理是否直接在worker中处理 Boolean false com.alipay.sofa.rpc.enable.swagger 是否开启针对bolt协议的swagger文档 Boolean false Rest\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.rest.hostname rest hostname String “” com.alipay.sofa.rpc.rest.port rest port Integer 8341 com.alipay.sofa.rpc.rest.io.thread.size rest io 线程数 Integer 机器cpu核数* 2 com.alipay.sofa.rpc.rest.context.path rest context path String “” com.alipay.sofa.rpc.rest.thread.pool.core.size rest 核心线程数 Integer 目前不可配置，默认20 com.alipay.sofa.rpc.rest.thread.pool.max.size rest 最大线程数 Integer 200 com.alipay.sofa.rpc.rest.max.request.size rest 最大请求大小 Integer 10485760 com.alipay.sofa.rpc.rest.telnet 是否允许 rest telnet Boolean true com.alipay.sofa.rpc.rest.daemon 是否hold住端口，true的话随主线程退出而退出 String true com.alipay.sofa.rpc.rest.allowed.origins 跨域设置 String “” com.alipay.sofa.rpc.rest.swagger 是否开启针对rest协议的swagger文档 boolean false Dubbo\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.dubbo.port dubbo port Integer 20880 com.alipay.sofa.rpc.dubbo.io.thread.size dubbo io 线程大小 Integer 0 com.alipay.sofa.rpc.dubbo.thread.pool.max.size dubbo 业务线程最大数 Integer 200 com.alipay.sofa.rpc.dubbo.accepts.size dubbo 服务端允许客户端建立的连接数 Integer 必须大于0，默认100000 com.alipay.sofa.rpc.dubbo.thread.pool.core.size dubbo 核心线程数 Integer 目前不可配置，默认20 com.alipay.sofa.rpc.dubbo.thread.pool.queue.size dubbo 线程池队列大小 Integer 目前不可配置，默认0 Http\n 配置项 说明 类型 默认值 com.alipay.sofa.rpc.http.port http port Integer 12400 com.alipay.sofa.rpc.http.thread.pool.core.size http 核心线程数 Integer 20 com.alipay.sofa.rpc.http.thread.pool.max.size http …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/application-rpc-config/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"bd19b2ced39a8deb802c13e525093fac","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/application-rpc-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/application-rpc-config/","summary":"在 SOFABoot 的使用场景下，RPC 框架在应用层面，提供一些配置参数，支持的应用级别的参数配置，如端口，线程池等信息，都是通过 Spring Boot的@Config","tags":null,"title":"RPC 应用参数配置","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/application-rpc-config/","wordcount":1496},{"author":null,"categories":null,"content":" Raft 新特性 Strong Leader 更强的领导形式 例如日志条目只会从领导者发送到其他服务器, 这很大程度上简化了对日志复制的管理 Leader Election 使用随机定时器来选举领导者 用最简单的方式减少了选举冲突的可能性 Membership Change 新的联合一致性 (joint consensus) 方法 复制状态机 1. 复制状态机通过日志实现 每台机器一份日志 每个日志条目包含一条命令 状态机按顺序执行命令 2.应用于实际系统的一致性算法一般有以下特性 确保安全性 高可用性 不依赖时序保证一致性 一条命令能够尽可能快的在大多数节点对一轮RPC调用响应时完成 Paxos 算法的不足 算法复杂度高, 较难理解 工程复杂度高, 难以在实际环境中实现 Raft 设计原则 概念分解 Leader election Log replication Membership changes 通过减少状态数量将状态空间简化 日志不允许出现空洞, 并且 raft 限制了日志不一致的可能性 使用随机化时钟简化了领导选举的算法 Raft 一致性算法 State (状态) 在所有服务器上持久存储的(响应RPC之前稳定存储的)\n currentTerm 服务器最后知道的任期号(从0开始递增) votedFor 在当前任期内收到选票的候选人Id(如果没有就为null) log[] 日志条目, 每个条目包含状态机要执行的命令以及从Leader收到日志时的任期号 在所有服务器上不稳定存在的\n commitIndex 已知被提交的最大日志条目索引 lastApplied 已被状态机执行的最大日志条目索引 在Leader服务器上不稳定存在的\n nextIndex[] 对于每一个follower, 记录需要发给他的下一条日志条目的索引 matchIndex[] 对于每一个follower, 记录已经复制完成的最大日志条目索引 AppendEntries RPC (日志复制) 由leader通过RPC向follower复制日志, 也会用作heartbeat\n入参\n term Leader任期号 leaderId Leader id, 为了能帮助客户端重定向到Leader服务器 prevLogIndex 前一个日志的索引 prevLogTerm 前一个日志所属的任期 entries[] 将要存储的日志条目列表(为空时代表heartbeat, 有时候为了效率会发送超过一条) leaderCommit Leader已提交的日志条目索引 返回值\n term 当前的任期号, 用于leader更新自己的任期号 success 如果其他follower包含能够匹配上prevLogIndex和prevLogTerm的日志, 那么为真 接收日志的follower需要实现的\n 如果term \u0026amp;lt; currentTerm, 不接受日志并返回false 如果索引prevLogIndex处的日志的任期号与prevLogTerm不匹配, 不接受日志并返回false 如果一条已存在的日志与新的冲突(index相同但是term不同), 则删除已经存在的日志条目和他之后所有的日志条目 添加任何在已有日志中不存在的条目 如果leaderCommit \u0026amp;gt; commitIndex, 则设置commitIndex = min(leaderCommit, index of last new entry) RequestVote RPC (投票请求) 入参\n term 候选人的任期号 candidateId 发起投票请求的候选人id lastLogIndex 候选人最新的日志条目索引 lastLogTerm 候选人最新日志条目对应的任期号 返回值\n term 目前的任期号, 用于候选人更新自己 voteGranted 如果候选人收到选票, 那么为true 接收日志的follower需要实现的\n 如果term \u0026amp;lt; currentTerm, 那么拒绝投票并返回false 如果votedFor为空或者与candidateId相同, 并且候选人的日志和自己一样新或者更新, 那么就给候选人投票并返回true 服务器要遵守的规则 所有服务器: 如果commitIndex \u0026amp;gt; lastApplied, 那么将lastApplied自增并把对应日志log[lastApplied]应用到状态机 如果RPC请求或响应包含一个term T大于currentTerm, 那么将currentTerm赋值为T并立即切换状态为follower Follower: 无条件响应来自candidate和leader的RPC 如果在选举超时之前没收到任何来自leader的AppendEntries RPC或RequestVote RPC, 那么自己转换状态为candidate Candidate: 转变为candidate之后开始发起选举 currentTerm自增 \u0026amp;ndash;\u0026amp;gt; 重置选举计时器 \u0026amp;ndash;\u0026amp;gt; 给自己投票 \u0026amp;ndash;\u0026amp;gt; 向其他服务器发起RequestVote RPC 如果收到了来自大多数服务器的投票, 转换状态成为leader 如果收到了来自新leader的AppendEntries RPC(Heartbeat), 转换状态为follower 如果选举超时, 开始新一轮的选举 Leader: 一旦成为leader, 向其他所有服务器发送空的AppendEntries RPC(Heartbeat), 并在空闲时间重复发送以防选举超时 如果收到来自客户端的请求, 向本地日志追加条目并向所有服务器发送AppendEntries RPC, 在收到大多数响应后将该条目应用到状态机并回复响应给客户端 如果leader上一次收到的日志索引大于一个follower的nextIndex, 那么通过AppendEntries RPC将nextIndex之后的所有日志发送出去; 如果发送成功, 将follower的nextIndex和matchIndex更新, 如果由于日志不一致导致失败, 那么将nextIndex递减并重新发送 如果存在一个N \u0026amp;gt; commitIndex和半数以上的matchIndex[i] \u0026amp;gt;= N并且log[N].term == currentTerm, 将commitIndex赋值为N 一致性算法总结 Election Safety 选举安全原则: 一个任期内最多允许有一个leader Leader Append-Only 只增加日志原则: Leader只会增加日志条目, 永远不会覆盖或删除自己的日志 Log Matching 日志匹配原则: 如果两个日志在相同的的索引位置上并且任期号相同, 那么就可以认为这个日志从头到这个索引位置之间的条目完 …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/raft-introduction/","fuzzywordcount":5200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b811e803d23b40da67657798801f8b51","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/raft-introduction/","publishdate":"0001-01-01T00:00:00Z","readingtime":11,"relpermalink":"/sofastack.tech/projects/sofa-jraft/raft-introduction/","summary":"Raft 新特性 Strong Leader 更强的领导形式 例如日志条目只会从领导者发送到其他服务器, 这很大程度上简化了对日志复制的管理 Leader Election 使用随机定时器来选举领导者 用最简单","tags":null,"title":"Raft 算法解读","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/raft-introduction/","wordcount":5182},{"author":null,"categories":null,"content":"TBD\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-register-agent/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"da6c96fadd94eedcf961d50ce7b00600","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","summary":"TBD","tags":null,"title":"Register Agent","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-register-agent/","wordcount":1},{"author":null,"categories":null,"content":" Register agent TBD\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-register-agent/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"da6c96fadd94eedcf961d50ce7b00600","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","summary":"Register agent TBD","tags":null,"title":"Register agent","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/","wordcount":3},{"author":null,"categories":null,"content":" Related articles ISSUES User manual Chinese introductory article: Ant communication framework practices ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/related-links/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"6844d2a639b69fa3128132b8631f33e3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/related-links/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/related-links/","summary":" Related articles ISSUES User manual Chinese introductory article: Ant communication framework practices ","tags":null,"title":"Related articles","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/related-links/","wordcount":12},{"author":null,"categories":null,"content":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.\n","date":-62135596800,"description":"","dir":"projects/mosn/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"62efb8e40401ab4612bcccaa6e942c97","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/mosn/release-notes/","summary":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/mosn/release-notes/","wordcount":5},{"author":null,"categories":null,"content":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.\n","date":-62135596800,"description":"","dir":"projects/occlum/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"6b9dec1dd8c196e43129ab36a046a84f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/occlum/release-notes/","summary":"To learn more, see https://github.com/mos/mosn/blob/master/CHANGELOG.md.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/occlum/release-notes/","wordcount":5},{"author":null,"categories":null,"content":" Release history For more information, refer to: https://github.com/sofastack/sofa-ark/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-release/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"994c3569ea416ee5b0dea253f08af6be","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","summary":"Release history For more information, refer to: https://github.com/sofastack/sofa-ark/releases","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/","wordcount":8},{"author":null,"categories":null,"content":"## Release history For more information, refer to: https://github.com/sofastack/sofa-jarslink/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-release/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4554e362f42cbc42b9408d9507cdf689","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","summary":"## Release history For more information, refer to: https://github.com/sofastack/sofa-jarslink/releases","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/","wordcount":9},{"author":null,"categories":null,"content":"For more information, see https://github.com/sofastack/sofa-dashboard/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/release-node/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3c8e6985123810c9692f47cc56b50081","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/release-node/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/release-node/","summary":"For more information, see https://github.com/sofastack/sofa-dashboard/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/release-node/","wordcount":5},{"author":null,"categories":null,"content":" 1.2.5 April 1, 2019\n Bugs fixed Fixed the conflict between jmh and the unit test code. Fixed the installation failure bug that would occur when the snapshot is too large. This bug may affect the addition of new nodes. Features Optimized part of the LogManagerImpl code to reduce CPU usage. Corrected some spelling errors. Breaking changes None We strongly recommend that you upgrade to this version.\n1.2.4 March 20, 2019\n Bugs fixed Fixed stale read of lease read in a circumstance. Modified part of timestamps to monotonic time. Fixed the problem of the replicator being blocked in one circumstance. Resolved directory creation failures for some unit tests on Windows. Resolved process crashes caused by improper rocksdb options settings on Windows. Features Made the RocksDB options available for users to set. Optimized the pre-vote process, and used the lease mechanism to avoid the current term\u0026amp;rsquo;s interruption on a disconnected node (caused by network partitioning or no writes in the cluster for a long time) to improve the system availability. Updated SOFABolt to 1.5.3. Modified ReadWriteLock of the BallotBox to StampedLock, and provided the OptimisticRead implementation. Fixed a few spelling errors. Breaking changes None Acknowledgements (in no particular order) @pifuant @huangyunbin @shiftyman @slievrly 1.2.3 March 5, 2019 Released the first open source version.\n1.2.2 February 21, 2019\n Bugs fixed Made PeerId and Endpoint immutable, to avoid concurrency problems on APIs such as getLeaderId. Upgraded sofa-common to 1.0.12. The earlier version 1.0.9 was not released to the public GitHub repository. Features The JRaft-RheaKV implemented auto range split. When placementDriver(pd) is enabled, the pd can calculate and issue the range split command based on state information reported by each node. When pd is disabled, RheaKVCliService is provided to allow users to manually trigger range split by using the CLI service. Provided LogExceptionHandler generic support. Added MetricThreadPoolExecutor (an updated version of LogThreadPoolExecutor) to print the uncaught exception log and record the time for task.run() and replaced all ThreadPoolExecutors in JRaft with MetricThreadPoolExecutor to record time-consumption metric statistics. This metric can be used as an important reference for adjusting the thread pool configuration in actual application. Breaking changes Removed the reset method of Endpoint/PeerId. V1.2.1 January 28, 2019\n Bugs fixed Fixed a bug that RaftGroupService may mistakenly disable the shared rpcServer. Fixed the bug of the apply-order change caused by batch write of the RheaKV state machine. Fixed the time usage API error. Features Merged the code of duplicate functions of Jraft and RheaKV. Reduced memory usage of the log replication request handling process on followers. Optimized the synchronized conf read/write of the RouteTable to the read/write lock. Implemented lock safe with fencing and the automatic lease …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/release-log/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"9e24fb74a3cda6a600252b01f8a85db9","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/release-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/release-log/","summary":"1.2.5 April 1, 2019\n Bugs fixed Fixed the conflict between jmh and the unit test code. Fixed the installation failure bug that would occur when the snapshot is too large. This bug may affect the addition of new nodes. Features Optimized part of the LogManagerImpl code to reduce CPU usage. Corrected some spelling errors. Breaking changes None We strongly recommend that you upgrade to this version.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/release-log/","wordcount":855},{"author":null,"categories":null,"content":"For more information, see https://github.com/sofastack/sofa-registry/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d92dddf77bbbd6078f3f96ba2224a53d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/release-notes/","summary":"For more information, see https://github.com/sofastack/sofa-registry/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/release-notes/","wordcount":5},{"author":null,"categories":null,"content":"To learn more, see https://github.com/sofastack/sofa-rpc/releases.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/release-notes/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ab7d46caa6906863103b77b742ec7e84","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/release-notes/","summary":"To learn more, see https://github.com/sofastack/sofa-rpc/releases.","tags":null,"title":"Release notes","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/release-notes/","wordcount":5},{"author":null,"categories":null,"content":" This example demonstrates how to remotely report link data to Zipkin by configuring SOFATracer in an application that integrates SOFATracer.\nThe following examples demonstrate how to use them in SOFABoot/SpringBoot projects and non-SOFABoot/SpringBoot projects, respectively.\nPrepare environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: + JDK7 or JDK8 + Apache Maven 3.2.5+ required for compilation\nIntroduce SOFABoot After creating a Spring Boot project, you need to introduce the SOFABoot dependency. First, you need to unzip the zip package of the Spring Boot project generated above and modify the Maven project configuration file pom.xml.\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; Replace the above with the followings:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; The ${sofa.boot.version} specifies the latest version of SOFABoot. For more about SOFABoot versions, see Release notes.\nAdd SOFATracer starter \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Application configuration Finally, add the properties to be used by SOFATracer under the project\u0026amp;rsquo;s application.properties file, including spring.application.name to indicate the name of the current application; logging.path to specify the output directory of the log.\n# Application Name spring.application.name=SOFATracerReportZipkin # logging path logging.path=./logs # open zipkin report com.alipay.sofa.tracer.zipkin.enabled=true # specify zipkin server address com.alipay.sofa.tracer.zipkin.baseUrl=http://localhost:9411 Configure Zipkin Dependencies Considering that Zipkin\u0026amp;rsquo;s data reporting capability is not the ability of SOFATracer to be enabled by default,it‘s desirable to add the following Zipkin data reporting dependencies when using SOFATracer for data reporting:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.zipkin2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.11.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.reporter2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin-reporter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.7.13\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt;\t Start the Zipkin server Start the Zipkin server to receive the link data reported by SOFATracer and display it. Zipkin Server can be configured with reference to this document.\nRunning You can import the project into IDE and run the main method in the project to start the application. In the console, you can see the log about startup as follows:\n2018-05-12 13:12:05.868 INFO 76572 --- …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/report-to-zipkin/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d28d192386829452262116de9c32b570","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","summary":"This example demonstrates how to remotely report link data to Zipkin by configuring SOFATracer in an application that integrates SOFATracer.\nThe following examples demonstrate how to use them in SOFABoot/SpringBoot projects and non-SOFABoot/SpringBoot projects, respectively.\nPrepare environment To use SOFABoot, you need to prepare the basic environment first. SOFABoot relies on the following environments: + JDK7 or JDK8 + Apache Maven 3.2.5+ required for compilation\nIntroduce SOFABoot After creating a Spring Boot project, you need to introduce the SOFABoot dependency.","tags":null,"title":"Report data to Zipkin","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/","wordcount":465},{"author":null,"categories":null,"content":" RestTemplate Integration In this document will demonstrate how to use SOFATracer to track of RestTemplate, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!-- SOFABoot version unified management --\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs Add a Controller that provides RESTFul services In the project, provide a simple Controller, for example:\n@RestController public class SampleController { private final AtomicLong counter = new AtomicLong(0); @RequestMapping(\u0026amp;quot;/rest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; rest() { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); return map; } @RequestMapping(\u0026amp;quot;/asyncrest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; asyncrest() throws InterruptedException { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); Thread.sleep(5000); return map; } } Construct the RestTemplate in API model to initiate a call to the RESTful service above Construct a RestTemplate synchronous call instance RestTemplate restTemplate = SofaTracerRestTemplateBuilder.buildRestTemplate(); ResponseEntity\u0026amp;lt;String\u0026amp;gt; responseEntity = restTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;, String.class); Construct a RestTemplate asynchronous call instance AsyncRestTemplate asyncRestTemplate = SofaTracerRestTemplateBuilder .buildAsyncRestTemplate(); ListenableFuture\u0026amp;lt;ResponseEntity\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; forEntity = asyncRestTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/asyncrest\u0026amp;quot;, String.class); Get the RestTemplate in an automatic injection @Autowired RestTemplate restTemplate; Run the project Start the SOFABoot app and see the log in the console as follows:\n2018-10-24 10:45:28.683 INFO 5081 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-10-24 10:45:28.733 INFO 5081 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-10-24 10:45:28.736 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Started RestTemplateDemoApplication in 2.163 seconds (JVM running for 3.603) Successful call：\n2018-10-24 10:45:28.989 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-resttemplate/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"8b66d6ad488bd59ecbf113b37825d58e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","summary":"RestTemplate Integration In this document will demonstrate how to use SOFATracer to track of RestTemplate, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;!-- SOFABoot version unified management --\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.properties file, including spring.","tags":null,"title":"RestTemplate Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/","wordcount":434},{"author":null,"categories":null,"content":" RestTemplate Log Format SOFATracer integrates RestTemplate and outputs the requested link log data format. The default is JSON data format.\nRestTemplate digest log（resttemplate-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.code HTTP return status code resp.size.bytes Response Body Size time.cost.milliseconds Request time (ms) current.thread.name Current thread name remote.app remote app name baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-10-24 10:45:28.977\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8b3154034912878910015081\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:188,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RestTemplate stat log（resttemplate-stat.log） stat.key is the collection of statistical keywords in this period, which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration (ms) for requests in this period success Request result: Y means success ; N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-10-24 10:46:28.769\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5009,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-resttemplate/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c52c919080b467801700a8a1f156c513","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","summary":"RestTemplate Log Format SOFATracer integrates RestTemplate and outputs the requested link log data format. The default is JSON data format.\nRestTemplate digest log（resttemplate-digest.log） The data is output in JSON format. Each key meaning is as follows:\n key Meaning time Log printing time local.app Current application name traceId TraceId spanId SpanId request.url Request URL method Request HTTP method result.","tags":null,"title":"RestTemplate log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/","wordcount":172},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 RestTemplate 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括 spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=TestTemplateDemo # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleController { private final AtomicLong counter = new AtomicLong(0); @RequestMapping(\u0026amp;quot;/rest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; rest() { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); return map; } @RequestMapping(\u0026amp;quot;/asyncrest\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; asyncrest() throws InterruptedException { Map\u0026amp;lt;String, Object\u0026amp;gt; map = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); map.put(\u0026amp;quot;count\u0026amp;quot;, counter.incrementAndGet()); Thread.sleep(5000); return map; } } 以 API 方式构造 RestTemplate 发起一次对上文的 RESTful 服务的调用 构造 RestTemplate 同步调用实例 RestTemplate restTemplate = SofaTracerRestTemplateBuilder.buildRestTemplate(); ResponseEntity\u0026amp;lt;String\u0026amp;gt; responseEntity = restTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/rest\u0026amp;quot;, String.class); 构造 RestTemplate 异步调用实例 AsyncRestTemplate asyncRestTemplate = SofaTracerRestTemplateBuilder .buildAsyncRestTemplate(); ListenableFuture\u0026amp;lt;ResponseEntity\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; forEntity = asyncRestTemplate.getForEntity( \u0026amp;quot;http://sac.alipay.net:8080/asyncrest\u0026amp;quot;, String.class); 以自动注入的方式获取 RestTemplate @Autowired RestTemplate restTemplate; 运行 启动 SOFABoot 应用，将会在控制台中看到启动打印的日志：\n2018-10-24 10:45:28.683 INFO 5081 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup 2018-10-24 10:45:28.733 INFO 5081 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-10-24 10:45:28.736 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Started RestTemplateDemoApplication in 2.163 seconds (JVM running for 3.603) 调用成功：\n2018-10-24 10:45:28.989 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Response is {\u0026amp;quot;count\u0026amp;quot;:1} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : Async Response is {\u0026amp;quot;count\u0026amp;quot;:2} 2018-10-24 10:45:34.014 INFO 5081 --- [ main] c.a.s.t.e.r.RestTemplateDemoApplication : test finish ....... 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要进行配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── resttemplate-digest.log ├── resttemplate-stat.log ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 示例中通过构造两个 RestTemplate（一个同步一个异步） 发起对同一个 RESTful 服务的调用，调用完成后可以在 restTemplate-digest.log 中看到类似如下的日志： …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-resttemplate/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8b66d6ad488bd59ecbf113b37825d58e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","summary":"在本文档将演示如何使用 SOFATracer 对 RestTemplate 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt;","tags":null,"title":"RestTemplate 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/","wordcount":610},{"author":null,"categories":null,"content":" SOFATracer 集成 RestTemplate 后输出请求的链路数据格式，默认为 JSON 数据格式。\nRestTemplate 摘要日志（resttemplate-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SimpleAsyncTaskExecutor-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5009ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RestTemplate 统计日志（resttemplate-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:34:04.130\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5009,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-resttemplate/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c52c919080b467801700a8a1f156c513","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","summary":"SOFATracer 集成 RestTemplate 后输出请求的链路数据格式，默认为 JSON 数据格式。 RestTemplate 摘要日志（resttemplate-digest.log） 以 JSON 格式输出的数据，相应 key 的","tags":null,"title":"RestTemplate 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/","wordcount":342},{"author":null,"categories":null,"content":" SOFARPC supports a framework-level retry strategy when the cluster mode is FailOver (SOFARPC uses FailOver mode by default). Retry is only initiated if there is a framework-level exception or a timeout exception on the server. If the business itself throws an exception, the service will not be called again. SOFARPC does not perform any retry by default.\n Note: Although the system will retry calling in case of timeout exception, the server still needs to guarantee the idempotency of the service. Otherwise there may be risks.\n Use XML If you subscribe to the service using XML, you can set the number of retries by setting the retries parameter of sofa:global-attrs:\n\u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;retriesServiceReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.retries.RetriesService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs retries=\u0026amp;quot;2\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation If you are using Annotation, you can set the retries attribute of @SofaReferenceBinding annotation:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, retries = 2)) private SampleService sampleService; Use API in Spring environment If you are using the API in Spring environment, you can call the setRetries method of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setRetries(2); Use API in non-Spring environment If you are using the bare API of SOFARPC directly in non-Spring environment, you can call the setRetries method of ConsumerConfig:\nConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt;(); consumerConfig.setRetries(2); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/retry-invoke/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d60b44aa8f1b49ab6c1bbc55593a91da","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","summary":"SOFARPC supports a framework-level retry strategy when the cluster mode is FailOver (SOFARPC uses FailOver mode by default). Retry is only initiated if there is a framework-level exception or a timeout exception on the server. If the business itself throws an exception, the service will not be called again. SOFARPC does not perform any retry by default.\n Note: Although the system will retry calling in case of timeout exception, the server still needs to guarantee the idempotency of the service.","tags":null,"title":"Retry strategy","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/retry-invoke/","wordcount":205},{"author":null,"categories":null,"content":" SOFAJRaft 2019 年 4-7 月开发计划 (p1) Telnet 服务（或其他，越简单越好），作为一种在线排查问题的手段，主要提供以下几个功能 Raft_stat: 以 node 节点为 root，能列出大部分甚至所有相关 stat Metrics: 展示当前节点最新的所有 metrics 指标度量(虽然日志里有相关数据但是相对分散) (p1) 扩展点：引入 SPI 机制，先列出几个扩展点 LogStorage LogEntry codec RaftMetaStorage Metric 指标度量 (p1) 对于 multi-raft-group 场景，提供一个 manual rebalance api 用于平衡各个节点的 leaders 数量 (p2) 文档国际化 (p2) 添加 Learner 角色，只用于同步数据不参与投票 (p3) RheaKV 完成 jepsen 验证\n ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/road-map/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d39cc6e615d623f8dfc320f32dcbdfa6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/road-map/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/road-map/","summary":"SOFAJRaft 2019 年 4-7 月开发计划 (p1) Telnet 服务（或其他，越简单越好），作为一种在线排查问题的手段，主要提供以下几个功能 Raft_stat: 以 node 节点为 root，能列出大部分甚至所有","tags":null,"title":"Road Map","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/road-map/","wordcount":194},{"author":null,"categories":null,"content":" Roadmap Version 1.5.1 Fixed code style problems in the project: https://github.com/alipay/sofa-bolt/issues/85 Fixed known bugs in the project: https://github.com/alipay/sofa-bolt/issues/82 The RPC layer supports message list dispatching from the I/O thread: https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 Overall goal Unify lifecycle APIs for all components Extract and incorporate network component APIs Converge configuration methods and enhance configuration scalability Unify lifecycle APIs for all components In the current Bolt version, APIs of lifecycle management components are named inconsistently, for example:\n ReconnectManager does not need startup or initialization, and the disabling method is stop. The initialization method for DefaultConnectionMonitor of is start, and the disabling method is destroy. The initialization method forRpcClient init, and the disabling method is shutdown. The initialization method forRpcTaskScanner is start, and the disabling method is shutdown. We plan to unify lifecycle APIs of all components in V1.6.0:\n For components that are subject to lifecycle management, which require initialization before use and must release resources after use, their startup/shutdown APIs are to be unified. Extract and incorporate network component APIs Network operations of Bolt are mainly performed by using the remoting class, which is provided as an abstract class. We plan to converge methods of this class, and provide them in the form of APIs in the future. There are a few advantages of doing so:\n Standardized usage Stable service Convenient internal code iteration Taking the ReconnectManager as an example. It provides the public addCancelUrl method, which is not called in the Bolt project. This may cause problems:\n IDE will give a warning. Users may get confused on whether they should delete this method. We plan to solve the these problems in V1.6.0 by extracting a set of stable APIs, which are convenient for users to use, helpful to improve code readability, and can lay a solid foundation for future iterations.\nConverge configuration methods and enhance configuration scalability Currently, Bolt supports the following configuration methods:\n ProtocolSwitch: supports protocol configuration (enabling or disabling CRC validation), and creates configuration objects by static means. GlobalSwitch: offers instance-level configuration, and offers GlobalSwitch configuration items to every AbstractConfigurableInstance. The default value is taken from the SystemProperty, and the configuration can be adjusted through an API. ConfigItem: enumerates Netty-related configuration items that cannot be inherited or extended before you modify the source code. ConfigManager: reads SystemProperty configurations by static means. Configs: defines the configuration item names and specifies their default values. Generally, Bolt\u0026amp;rsquo;s configuration items look to be loose and scattered and are hard for users to extend their usage. …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-roadmap/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3d4eac90b5c8e657d14eb885ab1f9a92","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","summary":"Roadmap Version 1.5.1 Fixed code style problems in the project: https://github.com/alipay/sofa-bolt/issues/85 Fixed known bugs in the project: https://github.com/alipay/sofa-bolt/issues/82 The RPC layer supports message list dispatching from the I/O thread: https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 Overall goal Unify lifecycle APIs for all components Extract and incorporate network component APIs Converge configuration methods and enhance configuration scalability Unify lifecycle APIs for all components In the current Bolt version, APIs of lifecycle management components are named inconsistently, for example:","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/","wordcount":539},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c4532d11cef15d8fe3ff5e04c7b08f90","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","summary":"","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/","wordcount":0},{"author":null,"categories":null,"content":"","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f1d0bf15efba08535f9574e1c8344cab","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":0,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","summary":"","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/","wordcount":0},{"author":null,"categories":null,"content":" Development plans of SOFAJRaft from April to July 2019 (p1) Implement the Telnet service (or similar equivalents, the simpler the better) as an online troubleshooting means. It should be able to provide the following functions: Raft_stat: List most or all stats of a Raft node. Metrics: Uniformly display the latest values of all metrics for the current node (the related data is scattered in the log). (p1) Extension points: introduce the SPI mechanism. Some of the extension points are listed as follows: LogStorage LogEntry codec RaftMetaStorage Metrics (p1) Provide a manual rebalance API for the multi-raft-group scenario to balance the number of leaders on each node. (p2) Translate the document into multiple languages. (p2) Add a learner role that only replicates data and does not vote. (p3) Complete jepsen tests for RheaKV. ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/road-map/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d39cc6e615d623f8dfc320f32dcbdfa6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/road-map/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/road-map/","summary":"Development plans of SOFAJRaft from April to July 2019 (p1) Implement the Telnet service (or similar equivalents, the simpler the better) as an online troubleshooting means. It should be able to provide the following functions: Raft_stat: List most or all stats of a Raft node. Metrics: Uniformly display the latest values of all metrics for the current node (the related data is scattered in the log). (p1) Extension points: introduce the SPI mechanism.","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/road-map/","wordcount":132},{"author":null,"categories":null,"content":" Task list Some of the existing internal features will be available in subsequent iterations.\nThe features that have been implemented are listed in the following table. You are welcome to claim the tasks and make contributions.\n Task type Task Degree of difficulty Claimant and time Planned completion time Progress Related issues Documentation Document translation Low Code Flexible persistent connection management Low #56 Code etcd registry center implementation Medium @wynn5a\n2018-6 #153 Code eureka registry center implementation Medium @liufeiit\n2018-4 #52 Code gRPC support High #57 Code CXF protocol High #58 Code TLS support High Version iteration Plan v5.5.0 Support JSON serialization Support H2 TLS Implement flexible connection pool Integrate Hystrix Support Consul registry center v5.6.0 Support GRPC communication layer Support etcd registry center Support SOFAMesh Implement BOLT version negotiation and CRC verification v5.7.0 Support Telnet built-in instructions Support SpringBoot 2.0 Support Mock function Support encryption v5.8.0 Support authorization Support SofaRegistry Support Reactive ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/roadmap/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"6064fc180911f520f6d1590b88595693","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/roadmap/","summary":"Task list Some of the existing internal features will be available in subsequent iterations.\nThe features that have been implemented are listed in the following table. You are welcome to claim the tasks and make contributions.\n Task type Task Degree of difficulty Claimant and time Planned completion time Progress Related issues Documentation Document translation Low Code Flexible persistent connection management Low #56 Code etcd registry center implementation Medium @wynn5a","tags":null,"title":"Roadmap","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/roadmap/","wordcount":152},{"author":null,"categories":null,"content":" Tasks The following table lists the features that have not yet been implemented. We encourage you to claim the tasks and make a contribution.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document SOFADashboard Parameter Configuration Guide Simple Code Support for SOFARegistry Medium Code Support for Docker Medium Code Support for Kubernetes Medium Code Support for Apollo Medium Code Frontend optimization Medium ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/roadmap/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a740c874742b504de9011b07f3a4ddb5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/roadmap/","summary":" Tasks The following table lists the features that have not yet been implemented. We encourage you to claim the tasks and make a contribution.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document SOFADashboard Parameter Configuration Guide Simple Code Support for SOFARegistry Medium Code Support for Docker Medium Code Support for Kubernetes Medium Code Support for Apollo Medium Code Frontend optimization Medium ","tags":null,"title":"Roadmap and task claim","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/roadmap/","wordcount":67},{"author":null,"categories":null,"content":" Roadmap Tasks We have some internal implementations of some new features, which will be released along with the iterations when sorted out.\nFeatures that are not implemented yet are listed in the following table. We encourage you to claim the tasks and contribute to SOFARegistry.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document Document Translation Low Code Support for Spring Cloud Medium Code Data self-check High Code Blacklist filtering Medium Code SOFARegistry Dashboard High Code Support for other microservice frameworks Medium Code Support for Docker \u0026amp;amp; Kubernetes High Code Multi-language client support High Version iteration plan v5.3.0 Support for Spring Cloud Data self-check Blacklist filtering v5.4.0 SOFARegistry Dashboard Support for other microservice frameworks v5.5.0 Support for Docker \u0026amp;amp; Kubernetes Multi-language client support ","date":-62135596800,"description":"","dir":"projects/sofa-registry/roadmap/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b0ab45d52ba3eb7db590a4f5e4197c9e","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/roadmap/","summary":"Roadmap Tasks We have some internal implementations of some new features, which will be released along with the iterations when sorted out.\nFeatures that are not implemented yet are listed in the following table. We encourage you to claim the tasks and contribute to SOFARegistry.\n Type Task Difficulty Claimed by and on Planned completion time Progress Related issues Document Document Translation Low Code Support for Spring Cloud Medium Code Data self-check High Code Blacklist filtering Medium Code SOFARegistry Dashboard High Code Support for other microservice frameworks Medium Code Support for Docker \u0026amp; Kubernetes High Code Multi-language client support High Version iteration plan v5.","tags":null,"title":"Roadmap and task claims","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/roadmap/","wordcount":128},{"author":null,"categories":null,"content":" AntCoreTest (ACTS) is a white-box test framework developed by Ant Financial based on years\u0026amp;rsquo; testing knowledge and experience with the financial-level distributed architecture for the purpose of providing enterprises with a highly efficient, precise, and automated interface testing services. In addition to general testing capabilities such as data-driven testing provided by conventional open source frameworks like TestNG, ACTS offers new features such as model-driven testing, visualized editing, and a standard process engine to assist engineers with efficient and high quality test case compilation as well as standard and precise test validation for interface testing.\nACTS is a next generation testing framework based on the data model-driven testing engine. ACTS is applicable to context environments that require the integration of TestNg and Spring. ACTS uses the YAML file as the data carrier and builds data model drivers upon it, providing features such as the all-in-one editor, precise validation, and efficient test case management to significantly improve testing efficiency.\nOperating principle Upon the start of the test script, ActsDataProvider starts the tested method (the method annotated by @Test), loads the corresponding test case data file (YAML file), and converts the data into corresponding PrepareData objects.\n When runTest starts running, it passes PrepareData and test case names to ACTS. ACTS then assembles such information into the ActsRuntimeContext class, transmits it in the entire process, and initializes the TestUnitHandler. The running period of the runTest process method consists of the following stages:\n | Action | Method | | :\u0026amp;mdash; | :\u0026amp;mdash; | | Clear | clear(actsRuntimeContext) | | Prepare | prepare(actsRuntimeContext) | | Execute | execute(actsRuntimeContext) | | Check | check(actsRuntimeContext) |\nDescription:\n Clear: Clean up the preparation data and validation data to avoid the negative impact of dirty data on the test script. Prepare: Prepare data such as DB data. Execute: Call the tested method, and capture the corresponding information, such as responses and exception messages. Check: Validate the corresponding information such as the responses, DB data, and exception messages based on the test data. Features ACTS provides the following features:\n2.1 All-in-one editor The ACTS framework separates the test data from the test code, and provides the visual editor ACTS IDE. ACTS IDE can help you quickly enter, view, and manage the test case data, which significantly reduces repetitive coding.\n2.2 Precise validation To improve data fill-in efficiency and reduce omission of check points among the expectation data, such as response expectations and database expectations, the ACTS framework provides a run and backfill function. In addition, ACTS uses validation rule flags to implement precise validation of the expectation data.\n2.3 Flexible scalability ACTS provides a rich variety of APIs, which are encapsulated …","date":-62135596800,"description":"","dir":"projects/sofa-acts/overview/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ac57071cd0d40a63359d476d05344c61","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/overview/","summary":"AntCoreTest (ACTS) is a white-box test framework developed by Ant Financial based on years\u0026rsquo; testing knowledge and experience with the financial-level distributed architecture for the purpose of providing enterprises with a highly efficient, precise, and automated interface testing services. In addition to general testing capabilities such as data-driven testing provided by conventional open source frameworks like TestNG, ACTS offers new features such as model-driven testing, visualized editing, and a standard process engine to assist engineers with efficient and high quality test case compilation as well as standard and precise test validation for interface testing.","tags":null,"title":"SOFAActs overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/overview/","wordcount":556},{"author":null,"categories":null,"content":" ACTS（AntCoreTest）源于蚂蚁金服多年金融级分布式架构工程的测试实践的积累与沉淀，是一款白盒测试框架，旨在为企业提供高效、精细化的接口自动化测试。 与现有的诸如 TestNG 等开源框架相比，ACTS 除了具备通用的数据自动化驱动等测试能力外，还具有契合快速的互联网发展和复杂的分布式金融系统特点的模型驱动、可视化编辑和标准流程引擎等新特性，可辅助工程师高效、高质量地完成接口测试用例编写以及标准化精准化测试验证。\nACTS 是基于数据模型驱动测试引擎执行的的新一代测试框架（如图1所示），适配 TestNg+Spring 的测试上下文环境，以 YAML 为数据载体并在此上构建数据模型驱动，实现了一站式编辑、精细化校验和高效用例管理等，可以有效提高测试效率。\n运行原理 测试脚本启动的时，ActsDataProvider 会启动被测方法（被 @Test 注解的方法），加载对应的用例数据文件(以 YAML 文件承载)，然后转换成对应的 PrepareData 对象； runTest 开始执行时会传入 PrepareData 和用例名称，ACTS 根据这些信息组装出 ActsRuntimeContext 上下文并在整个过程中传递，同时初始化 TestUnitHandler 测试处理器。runTest -\u0026amp;gt; process 方法执行期包含如下四个子流程：\n 说明 方法 清理 clear(actsRuntimeContext) 准备 prepare(actsRuntimeContext) 执行 execute(actsRuntimeContext) 检查 check(actsRuntimeContext) 方法功能说明： + 清理阶段：清理准备数据、校验数据，防止脏数据对测试脚本产生影响； + 准备阶段：准备 DB 数据等； + 执行阶段：调用被测方法，捕获返回结果和异常等信息； + 检查阶段：根据测试数据，校验返回结果、DB 数据和异常信息等内容。\n功能描述 ACTS 提供了以下能力：\n2.1 一站式编辑 框架实现了测试数据与测试代码的分离，同时配套提供可视化编辑器 ACTS IDE，通过 ACTS IDE 可以快速地录入、查看和管理用例数据，有效减少重复性编码。\n2.2 精细化校验 为了提高返回结果、DB 数据等期望数据的填写效率和减少检验点遗漏，框架提供了预跑返填功能；同时在 ACTS 校验规则标签的标记下，实现期望 DB 数据、期望结果等数据的精细化校验。\n2.3 灵活可扩展 ACTS 提供了丰富的 API ，其封装于 ActsRuntimeContext 类中，借助 API 可快速获取和设置自定义参数、用例入参、期望结果等，满足用户对用例数据的自定义操作；\n同时，框架的 ActsTestBase 测试基类对外暴露各个执行阶段方法，包括 prepare，execute，check，clear 等，例如在测试类中通过重写 process 方法可将整个测试脚本重新编排。\n2.4 统一配置能力 配置文件中提供丰富的配置能力以定制化框架的个性需求。\n应用场景 基于 SOFABoot 搭建的应用，在 Intellij IDEA 开发环境下快速编写和执行接口测试用例。推荐使用 Intellij IDEA 2017 以便能更好地兼容 ACTS IDE。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/overview/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ac57071cd0d40a63359d476d05344c61","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/overview/","summary":"ACTS（AntCoreTest）源于蚂蚁金服多年金融级分布式架构工程的测试实践的积累与沉淀，是一款白盒测试框架，旨在为企业提供高效、精细化","tags":null,"title":"SOFAActs 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-acts/overview/","wordcount":998},{"author":null,"categories":null,"content":" SOFAArk offers a variety of methods to support multi-application (module) consolidation and deployment, including command line-based control and API-based control. SOFAArk control is an implementation of SOFADashboard\u0026amp;rsquo;s control over APIs. SOFAArk control is implemented by pushing commands to and parsing commands in ZooKeeper.\nSOFAArk control mainly provides the following functions:\n Plug-in registration: registers the ark-biz package with SOFADashboard as basic data processors. Application association: binds the ark-biz package with host applications. Plug-in details: On the plug-in details page, you can view the information about all host applications that are associated with the current ark-biz package, as well as the status information of the ark-biz package in these host applications. Command push: On the plug-in details page, you can push some commands for specific applications and IP addresses, such as install and uninstall. When these commands are written to a ZooKeeper node, all host applications that listen to this node will parse the commands and perform related operations. Plug-in registration Register the ark-biz package with SOFADashboard:\nEnter basic information of the plug-in\nAfter successful registration, the plug-in is displayed on the module list as follows.\nApplication association Click Associate application in the Actions column of a plug-in on the module list to associate it with an application.\nClick Associate application in the Actions column of the plug-in to associate it with an application.\nPlug-in details Click Details in the Actions column of a plug-in to view all apps and app instances associated with the current plug-in.\n Version switch After switching the plug-in to V2.0.0, the status information is empty, because the plug-in V2.0.0 has not been installed in the host application.\nCommand push SOFADashboard supports command push in two dimensions:\n Application-based command push, where all instances of the specified application listen to this command IP-based and group-based command push for single-IP address scenarios IP-based command push Click Install. The page is refreshed after about 1s to 1.5s.\n Application-based command push is similar.\n ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/ark-console/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b42cffbb8e55a4c47412e49de0e9b228","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/ark-console/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/ark-console/","summary":"SOFAArk offers a variety of methods to support multi-application (module) consolidation and deployment, including command line-based control and API-based control. SOFAArk control is an implementation of SOFADashboard\u0026rsquo;s control over APIs. SOFAArk control is implemented by pushing commands to and parsing commands in ZooKeeper.\nSOFAArk control mainly provides the following functions:\n Plug-in registration: registers the ark-biz package with SOFADashboard as basic data processors. Application association: binds the ark-biz package with host applications.","tags":null,"title":"SOFAArk control","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/ark-console/","wordcount":321},{"author":null,"categories":null,"content":" SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献，目前已经基于 SOFAArk 提供了模块化合并部署的完整解决方案 koupleless, 如果想要使用合并部署能力，建议查看 Koupleless 使用文档，如果只是想要使用的类隔离能力可以查看 SOFAArk Plugin 能力，继续查看本站点相关文档；\n在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，产品能力主要包括：\n 定义类加载模型，运行时底层插件、业务应用(模块)之间均相互隔离，单一插件和应用(模块)由不同的 ClassLoader 加载，可以有效避免相互之间的包冲突，提升插件和模块功能复用能力； 定义插件开发规范，提供 maven 打包工具，简单快速将多个二方包打包成插件（Ark Plugin，以下简称 Plugin） 定义模块开发规范，提供 maven 打包工具，简单快速将应用打包成模块 (Ark Biz，以下简称 Biz) 针对 Plugin、Biz 提供标准的编程界面，包括服务、事件、扩展点等机制 支持多 Biz 的合并部署，开发阶段将多个 Biz 打包成可执行 Fat Jar，或者运行时使用 API 或配置中心(Zookeeper)动态地安装卸载 Biz 基于以上能力，SOFAArk 可以帮助解决依赖包冲突、多应用(模块)合并部署等场景问题。\n场景 包冲突 日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError, NoSuchMethodError 等；实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法，统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突；这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题；如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。\n为了彻底解决包冲突的问题，需要借助类隔离机制，使用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离包冲突问题； OSGI 作为业内最出名的类隔离框架，自然是可以被用于解决上述包冲突问题，但是 OSGI 框架太过臃肿，功能繁杂；为了解决包冲突问题，引入 OSGI 框架，有牛刀杀鸡之嫌，且反而使工程变得更加复杂，不利于开发；\nSOFAArk 采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题，在蚂蚁金服内部服务于整个 SOFABoot 技术体系，弥补 Spring Boot 没有的类隔离能力。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Plugin，在遇到包冲突时，用户可以使用 Maven 插件将若干冲突包打包成 Plugin，运行时由独立的 PluginClassLoader 加载，从而解决包冲突。\n假设如下场景，如果工程需要引入两个三方包：A 和 B，但是 A 需要依赖版本号为 0.1 的 C 包，而恰好 B 需要依赖版本号为 0.2 的 C 包，且 C 包的这两个版本无法兼容：\n此时，即可使用 SOFAArk 解决该依赖冲突问题；只需要把 A 和版本为 0.1 的 C 包一起打包成一个 Ark 插件，然后让应用工程引入该插件依赖即可；\n合并部署 复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 \u0026amp;ndash; Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。\n静态合并部署 SOFAArk 提供了静态合并部署能力，在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成可执行 Fat Jar 时，可以将其他应用 Biz 包一并打入，启动时，则会根据优先级依次启动各应用。每个 Biz 使用独立的 BizClassLoader 加载，不需要考虑相互依赖冲突问题，Biz 之间则通过 SofaService/SofaReference JVM 服务进行交互。\n动态合并部署 动态合并部署区别于静态合并部署最大的一点是，运行时通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态合并部署的设计理念图如下：\n无论是静态还是动态合并部署都会有宿主应用（master biz）的概念, 如果 Ark 包只打包了一个 Biz，则该 Biz 默认成为宿主应用；如果 Ark 包打包了多个 Biz 包，需要配置指定宿主应用。宿主应用不允许被卸载，一般而言，宿主应用会作为流量入口的中台系统，具体的服务实现会放在不同的动态 Biz 中，供宿主应用调用。宿主应用可以使用 SOFAArk 提供的客户端 API 实现动态应用的部署和卸载。除了 API, SOFAArk 提供了 Config Plugin，用于对接配置中心（目前支持 Zookeeper），运行时接受动态配置；Config Plugin 会解析下发的配置，控制动态应用的部署和卸载。\n原理 SOFAArk 包含三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下:\n 在介绍这三个概念之前，先介绍上述 Ark 包概念；Ark 包是满足特定目录格式要求的可运行 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将单个或多个应用打包成标准格式的 Ark 包；使用 java -jar 命令即可在 SOFAArk 容器之上启动所有应用；Ark 包通常包含 Ark Container、Ark Plugin 和 Ark Biz；以下我们针对这三个概念简单做下名词解释：\n Ark Container: SOFAArk 容器，负责 Ark 包启动运行时的管理；Ark Plugin 和 Ark Biz 运行在 SOFAArk 容器之上；容器具备管理插件和应用的功能；容器启动成功后，会自动解析 classpath 包含的 Ark Plugin 和 Ark Biz 依赖，完成隔离加载并按优先级依次启动之；\n Ark Plugin: Ark 插件，满足特定目录格式要求的 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-plugin-maven-plugin 可以将一个或多个普通的 Java jar 打包成一个标准格式的 Ark …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-readme/","fuzzywordcount":2700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cdb6729fc7a63954b7559c8ea319f550","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","summary":"SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献，目前已经基于 SOFAArk 提供了模块化合并部署的","tags":null,"title":"SOFAArk 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-readme/","wordcount":2660},{"author":null,"categories":null,"content":" 【SOFAChannel 分享】SOFAArk 类隔离框架设计原理 https://www.bilibili.com/video/BV1gS4y1i7Fg/?spm_id_from=333.999.0.0\n\n【SOFA 开源四周年分享】Serverless 技术简介 https://www.bilibili.com/video/BV1nU4y1B7u3/?spm_id_from=333.999.0.0\n\n【SOFA Meetup 云原生技术沙龙】SOFAServerless 体系助力业务极速研发 https://www.bilibili.com/video/BV1Ld4y1P7VK/?spm_id_from=333.999.0.0\n\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-public-presentation/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c460ccc2d706f49e26eb4f74d5468d63","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","summary":"【SOFAChannel 分享】SOFAArk 类隔离框架设计原理 https://www.bilibili.com/video/BV1gS4y1i7Fg/?spm_id_from=333.999.0.0 【SOFA 开源四周年分享】Serverless 技术简介 https://www.bilibili.com/video/BV1nU4y1B7u3/?spm_id_from=333.999.0.0 【SOFA Meetup 云原生技","tags":null,"title":"SOFAArk 相关公开分享材料","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/","wordcount":99},{"author":null,"categories":null,"content":" SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAARK 管控是 SOFADashboard 针对 API 的管控的一种实现。通过面向 Zookeeper 进行命令的推送和命令的解析执行。\nSOFAArk 管控主要包括以下功能：\n 插件注册：将 ark-biz 插件注册到 SOFADashboard，作为基础数据 关联应用：将 ark-biz 插件与宿主应用进行绑定 插件详情：通过插件详情页，可以看下当前 ark-biz 插件下所有关联的宿主应用信息，以及宿主应用中的ark-biz 状态信息 命令推送：插件详情页，可以针对应用维度、分组维度、IP 维度 推送一些指令，比如 install、uninstall 等等，当这些命令被写入到 Zookeeper 的某个节点上时，所有监听此节点的 宿主应用均会解析此指令，并进行相关的操作 插件管理 插件注册 将 ark-biz 插件注册到 SOFADashboard：\n插件删除 添加插件版本 插件版本 biz 包路径 删除版本 关联应用 点击模块列表操作菜单栏中的关联应用，可以将一个应用与插件进行绑定：\n动态管控 点击插件列表后面的 详情 按钮，可以查看当前插件下所有应用信息和应用实例信息。\n命令推送 SOFADashboard 提供三种维度的命令推送\n 基于应用维度，当前应用所有的实例都会监听到此命令变更 基于IP 维度，分组维度的单 ip 场景 动态模块详情 点击 状态详细按钮，左侧栏将会展开 \u0026amp;ldquo;抽屉\u0026amp;rdquo; 展示详情状态数据\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/ark-console/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b42cffbb8e55a4c47412e49de0e9b228","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/ark-console/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/ark-console/","summary":"SOFAArk 本身提供了多种方式来支持多应用(模块)合并部署 ，包括基于命令行的管控，基于 API 的管控等；SOFAARK 管控是 SOFADashboard 针对 API 的管控的一种实现。通过面","tags":null,"title":"SOFAArk 管控","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/ark-console/","wordcount":541},{"author":null,"categories":null,"content":" SOFAArk 的配置目录不是必须存在，如果需要，统一放在工程根目录 ${baseDir}/conf/ark 下，执行 sofa-ark-maven-plugin 打包，将会自动将该目录下的配置打包至 Ark 包，例如 Ark 包目录为：\n. ├── META-INF │ └── MANIFEST.MF ├── SOFA-ARK │ ├── biz │ │ └── demo-0.0.1-SNAPSHOT-ark-biz.jar │ └── container │ └── sofa-ark-all-0.6.0-SNAPSHOT.jar ├── com │ └── alipay │ └── sofa │ └── ark │ ├── ... │ └── conf └── ark ├── bootstrap-dev.properties ├── bootstrap.properties └── log └── logback-conf.xml 注意事项：如果应用中包含 SOFAArk 配置，打包时需要注意 baseDir 配置，用于指定工程根目录，具体参考文档\n上述 conf/ark 目录中可以配置 SOFAArk 容器启动配置以及日志配置，下面介绍配置的使用.\nconf/ark/bootstrap.properties 是 SOFAArk 容器默认启动配置文件，配置内容包括：日志配置、plugin 激活和钝化配置、biz 激活和钝化配置.\n日志配置 SOFAArk 容器日志内部实现使用 logback, 日志配置参数包括： + logging.path \u0026amp;gt; 容器日志目录根路径，这里只影响 SOFAArk 容器日志路径，不影响应用日志，应用自身日志由自身配置决定，默认打印在 ${user.admin}/logs 目录\n logging.level.com.alipay.sofa.ark \u0026amp;gt; 设置 SOFAArk 容器日志级别，默认为 INFO\n logging.config.com.alipay.sofa.ark \u0026amp;gt; 指定自定义日志配置文件名，用于覆盖 SOFAArk 容器自带的日志配置文件。建议自定义配置文件放在 conf/ark/log 目录中\n sofa.middleware.log.com.alipay.sofa.ark.console \u0026amp;gt; 配置容器日志是否打印在 console，默认为 false.\n sofa.middleware.log.com.alipay.sofa.ark.console.level \u0026amp;gt; 配合上述配置项使用，如果打印在 console ，该配置项用于配置 SOFAArk 容器打印在 console 的日志级别\n 插件配置 ark.plugin.active.include \u0026amp;gt; 指定激活哪些插件，多个插件使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认激活 Ark 包中所有的插件。\n ark.plugin.active.exclude \u0026amp;gt; 指定排除哪些插件，多个插件使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认为空\n 注：如果同时配置了这两个属性，以 ark.plugin.active.include 为准\nbiz配置 ark.biz.active.include \u0026amp;gt; 指定激活哪些 Biz，多个 Biz 使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认激活 Ark 包中所有的 Biz.\n ark.biz.active.exclude \u0026amp;gt; 指定排除哪些 Biz，多个 Biz 使用 \u0026amp;lsquo;,\u0026amp;rsquo; 分隔；默认为空\n com.alipay.sofa.ark.master.biz \u0026amp;gt; 指定宿主 Biz 名，如果 Ark 包中只有一个 Biz，则不用设置，默认设置为宿主 Biz; 否则需要显示设置\n 注：如果同时配置了前两个属性，以 ark.biz.active.include 为准\n动态配置 SOFAArk 提供了对接 Zookeeper 的插件，目前用于动态接收 Biz 指令，目前只支持 Zookeeper，配置格式如下：\ncom.alipay.sofa.ark.config.address=zookeeper://ip:port?key1=value1\u0026amp;amp;key2=value2 特别注意，SOFAArk 有一个默认的逻辑，如果用户配置了 com.alipay.sofa.ark.config.address，且 Ark 包中打入了多个 Biz，则只会启动宿主应用(master biz)；这样做的原因是如果配置了动态配置，SOFAArk 会优先根据动态配置控制 Biz 的部署。\nProfile 机制 默认 SOFAArk 容器使用 bootstrap.properties 配置，实际开发中，可能根据运行环境加载不同的配置，SOFAArk 提供了 profile 机制. 指定 profile 值，SOFAArk 容器会加载 bootstrap-${profile}.properties 配置文件。指定 profile 的配置有两种方式： + 通过 -D VM 参数传入，例如：-Dark.profile=dev,dev2 多个值使用 \u0026amp;lsquo;,\u0026amp;rsquo; 隔开。 + 通过应用启动参数传入，例如：java -jar demo-executable-ark.jar -Aprofile=dev,dev2 多个值使用 \u0026amp;lsquo;,\u0026amp;rsquo; 隔开。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-config/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"70dd9c389e65ee3f89573cf93bd466ec","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","summary":"SOFAArk 的配置目录不是必须存在，如果需要，统一放在工程根目录 ${baseDir}/conf/ark 下，执行 sofa-ark-maven-plugin 打包，将会自动将该目录下的配置打包至 Ark 包，例如 Ark 包目录为： . ├── META-INF │ └─","tags":null,"title":"SOFAArk 配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/","wordcount":1036},{"author":null,"categories":null,"content":" 背景 SOFAArk 框架包含有三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下：\n 每次应用启动时，首先运行 Ark 包，Ark Container 优先启动，容器自动解析 Ark 包中含有的 Ark Plugin 和 Ark Biz，并读取他们的配置信息，构建类和资源的加载索引表；然后使用独立的 ClassLoader 加载并按优先级配置依次启动；需要指出的是，Ark Plugin 优先 Ark Biz 被加载启动。 详细介绍可阅读： SOFAArk 介绍\n在三层概念的基础上，衍生出复杂的类加载机制，如图：\n详细介绍可阅读：Ark 容器类加载机制\n问题一 由于Ark Plugin的存在，插件在依赖层面的强管控，造成了一些问题 - 业务使用的依赖是被插件管控导出的，但是插件管控导出的版本与业务实际期望的版本不符（比如插件管控的版本是 1.0，而业务需要的是 2.0）。 - 插件对于依赖的强管控，直接堵住了业务扩展插件能力的路；也存在部分依赖，当业务引入时会直接报错（其package 被导出了，但是依赖不在插件中），那么对于业务来说就只能等框架发版解决。 - 业务接入成本，学习成本较高，问题排查困难，需要非常熟悉Ark类加载机制。 - 由于管控依赖的增长，Ark Plugin难以持续维护\n问题二 另外，由于Ark Container先于master biz启动，master biz的启动入口和springboot/sofaboot不一致，导致Ark master biz的的启动在研发运维中需要定制镜像，定制启动入口，造成研发运维困难。\nSOFAArk2.0 针对这些问题，我们尝试从框架层面去优化三层结构，沉淀出了SOFAArk2.0方案，整体优化思路和原则是 Ark Master Biz保持和原生springboot/sofaboot保持一致，弱化复杂的Ark Plugin类管控机制，将Ark Plugin与master biz合并。\nSOFAArk2.0方案整体优化点： - 弱化Ark Plugin层，改为普通pom依赖； - Ark master biz和原生的springboot/sofaboot应用启动方式，类加载方式保持一致； - 优化Ark Biz启动速度；\n升级方式 版本升级 SOFAArk版本号第一位为大版本号，当为1.x.x时为SOFAArk1.0版，当为2.x.x时是SOFAArk2.0版，当前2.0版本已正式release，Release-Notes\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;sofa.ark.version\u0026amp;gt;1.1.6\u0026amp;lt;/sofa.ark.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; 改为\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;sofa.ark.version\u0026amp;gt;2.0.0\u0026amp;lt;/sofa.ark.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; 打包插件 对于基座来说，在SOFAArk1.0中使用sofa-ark-maven-plugin打包，在SOFAArk2.0中采用spring-boot原生打包插件spring-boot-maven-plugin打包对于模块来说，则继续使用 sofa-ark-maven-plugin 来打包。\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 替换为：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.6.6\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 运行启动 方式一：IDEA启动 本地启动需要加上启动参数\n -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二：命令行启动 Ark包是可执行Jar，可直接使用Java -jar的方式启动，先使用 mvn clean package 进行打包，打包得到 ${bizName}-${bizVersion}-ark-biz.jar， …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-migration-guide/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b924edd10ef0e13f7220cff7c019d137","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","summary":"背景 SOFAArk 框架包含有三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下： 每次应用启动时，首先运行 Ark 包，Ark Container 优先启动，容器自动解析 Ark 包中含有的 Ark","tags":null,"title":"SOFAArk2.0 升级","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/","wordcount":1286},{"author":null,"categories":null,"content":" Introduction SOFABolt is a network communication framework implemented based on Netty and developed by Ant Finance.\n Netty was developed to let Java programmers focus more on the implementation of network communication-based business logic, and not worry excessively about network low-level NIO implementation or network problems that are difficult to debug. SOFABolt was developed to let middleware developers focus more on the implementation of products\u0026amp;rsquo; functional performance, and not on making the communication framework\u0026amp;rsquo;s wheels over and over again. Bolt takes its name from a Disney movie character. Bolt is a light, easy-to-use, high-performance, and flexibly scalable communication framework based on the Netty best practices. In the past few years, we have solved a lot of problems in terms of network communication for microservices and message oriented middleware. We have accumulated a lot of experience and have been constantly optimizing and improving our solutions. We hope that our solutions can be incorporated into the SOFABolt base component to serve more network communication scenarios. At present, SOFABolt has already been put to use in many Ant Middleware products, such as microservice products (SOFARPC), message queue, distributed transactions, distributed switches, and configuration centers.\nMultiple languages supported node Python cpp ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/overview/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5ee08df7c4bbd2c3be846e16f3bc81b1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/overview/","summary":"Introduction SOFABolt is a network communication framework implemented based on Netty and developed by Ant Finance.\n Netty was developed to let Java programmers focus more on the implementation of network communication-based business logic, and not worry excessively about network low-level NIO implementation or network problems that are difficult to debug. SOFABolt was developed to let middleware developers focus more on the implementation of products\u0026rsquo; functional performance, and not on making the communication framework\u0026rsquo;s wheels over and over again.","tags":null,"title":"SOFABolt overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/overview/","wordcount":196},{"author":null,"categories":null,"content":" 功能架构 SOFABolt　的基础功能： 基础通信功能 ( remoting-core ) 基于 Netty 高效的网络 IO 与线程模型运用 连接管理 (无锁建连，定时断链，自动重连) 基础通信模型 ( oneway，sync，future，callback ) 超时控制 批量解包与批量提交处理器 心跳与 IDLE 事件处理 协议框架 ( protocol-skeleton ) 命令与命令处理器 编解码处理器 心跳触发器 私有协议定制实现 - RPC 通信协议 ( protocol-implementation ) RPC 通信协议的设计 灵活的反序列化时机控制 请求处理超时 FailFast 机制 用户请求处理器 ( UserProcessor ) 双工通信 用法1 将 SOFABolt 用作一个远程通信框架，使用者可以不用关心如何实现一个私有协议的细节，直接使用我们内置的 RPC 通信协议。可以非常简单的启动客户端与服务端，同时注册一个用户请求处理器，即可完成远程调用。同时，像连接管理、心跳等基础功能特性都默认可以使用。 当前支持的调用类型如下图所示：\n 示例 Demo 请参考我们的 用户手册 用法2 将 SOFABolt 用作一个协议框架，使用者可以复用基础的通信模型、协议包含的接口定义等基础功能。然后根据自己设计的私有协议自定义 Command 类型、Command 处理器、编解码处理器等。如下图所示，RPC 和消息的 Command 定义结构：\n","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-functions/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fde29139cbd8b786326a6479e52814dd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","summary":"功能架构 SOFABolt 的基础功能： 基础通信功能 ( remoting-core ) 基于 Netty 高效的网络 IO 与线程模型运用 连接管理 (无锁建连，定时断链，自动重连) 基础通信模型 ( oneway，","tags":null,"title":"SOFABolt 功能介绍","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/","wordcount":450},{"author":null,"categories":null,"content":" 参与贡献 开放代码允许在签署协议之后,提交贡献代码.\n版权协议 对 SOFABolt 代码的修改和变更，需要遵守版权协议。\n准备工作 贡献代码前需要先了解git工具的使用和GitHub网站的使用。 git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git协作流程 GitHub 贡献代码流程 提issue 不论你是修复 Bolt 的bug还是新增 Bolt 的功能，在你提交代码之前，在 Bolt 的GitHub上提交一个 issue, 描述你要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突,产生重复工作。Bolt 的维护人员会对你提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提issue后，点击左上角的fork按钮，复制一份 Bolt 主干代码到你的代码仓库。\n拉分支 Bolt 所有修改都在分支上进行，修改完后提交 pull request ， 在code review 后由项目维护人员 merge 到主干。 因此，在获取源码步骤介绍后，你需要：\n 下载代码到本地,这一步你可以选择git/https方式. git clone https://github.com/sofastack/sofa-bolt.git 拉分支准备修改代码 git branch add_xxx_feature 执行完上述命令后，你的代码仓库就切换到相应分支了。执行如下命令可以看到你当前分支： git branch -a 如果你想切换回主干，执行下面命令: git checkout -b master 如果你想切换回分支，执行下面命令： git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 想直接从github上拉取分支到本地 git clone -b branchname https://xxx.git 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 Bolt 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行 mvn clean package 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在bugs，而新的代码已经解决了这些bugs. 你可以用如下命令运行所有测试\nmvn clean test 也可以通过IDE来辅助运行.\n其它注意事项 请保持你编辑的代码的原有风格,尤其是空格换行等. 对于无用的注释, 请直接删除 对逻辑和功能不容易被理解的地方添加注释. 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地: git commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到github上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面你是通过fork来做的,那么那么这里的 origin 是push到你的代码仓库，而不是 Bolt 的代码仓库.\n提交合并代码到主干的请求 在你的代码提交到GitHub后，你就可以发送请求来把你改好的代码合入 Bolt 主干代码了。此时你需要进入你的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是主干master, 系统会通知 Bolt 的人员，Bolt 人员会 review 你的代码，符合要求后就会合入主干，成为 Bolt 主干代码的一部分。\n代码review 在你提交代码后，你的代码会被指派给维护人员review,请保持耐心。如果在数天后，仍然没有人对你的提交给予任何回复，可以在pull request下面留言,并@对应的人员. 对于代码review的意见会提交到对应issue。如果觉得建议是合理的，也请你把这些建议更新到你的补丁中。\n合并代码到主干 在代码 Bolt 通过后，就由 Bolt 维护人员操作合入主干了。这一步不用参与,review合并之后,你会收到合并成功的提示.\nContributing to SOFABolt SOFABolt is released under the Apache 2.0 license, and follows a very standard Github development process, using Github tracker for issues and merging pull requests into master . If you would like to contribute something, or simply want to hack on the code this document should help you get started.\nSign the Contributor License Agreement Before we accept a non-trivial patch or pull request we will need you to sign the Contributor License Agreement. Signing the contributor’s agreement does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do. Active contributors might be asked to join the core team, and given the ability to merge pull requests.\nCode Conventions None of these is essential for a pull request, but they will all help.\n we provided a code formatter file, it will formatting automatically your project when during process of building.\n Make sure all new .java files to have a simple Javadoc class comment with at least an @author tag identifying you, and preferably at least a paragraph on what the class is for.\n Add the …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-contribution/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c044ad534cf99e4d6d400113b490f816","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","summary":"参与贡献 开放代码允许在签署协议之后,提交贡献代码. 版权协议 对 SOFABolt 代码的修改和变更，需要遵守版权协议。 准备工作 贡献代码前需要先了解git工具的使","tags":null,"title":"SOFABolt 参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/","wordcount":1650},{"author":null,"categories":null,"content":" 发展路线 Version 1.5.1 修复项目中代码风格的问题：https://github.com/alipay/sofa-bolt/issues/85 修复项目中已知的BUG：https://github.com/alipay/sofa-bolt/issues/82 RPC 层支持从 IO 线程派发 message list：https://github.com/alipay/sofa-bolt/pull/84 Version 1.6.0 整体目标 统一生命周期组件 抽象并沉淀网络组件的API 收敛配置入口\u0026amp;amp;增强配置的可扩展性 统一生命周期组件 在1.5.x的Bolt版本中，管理组件的生命周期相关的API命名并不统一，比如：\n ReconnectManager不需要启动或者初始化，关闭方法为stop DefaultConnectionMonitor初始化方法为start，关闭的方法为destroy RpcClient初始化方法为init，关闭的方法为shutdown RpcTaskScanner初始化的方法为start，关闭方法为shutdown 在1.6.0版本里，统一了所有组件的生命周期接口：\n 对于有生命周期的组件，即使用前需要进行初始化，使用完毕需要释放资源的，统一提供startup/shutdown接口 抽象并沉淀网络组件的API Bolt中remoting类是网络操作的主要入口，目前以抽象类的形式提供，后续希望对方法进行收敛，暴露对应的接口：\n 标准化，规范使用 沉淀接口，保持稳定 收敛入口，便于内部的代码迭代 在1.5.x的版本中，ReconnectManager类尽管提供了public的addCancelUrl方法，但是这个方法在Bolt项目中没有调用：\n IDE会给出警告 给用户造成困惑：这个方法可否删除？ 在1.6.0版本中解决了以上的问题，抽象出一套稳定的API，便于用户使用、提升代码可读性，同时也为后续的迭代打下基础。\n收敛配置入口\u0026amp;amp;增强配置的可扩展性 1.5.x版本的Bolt配置入口有以下几个：\n ProtocolSwitch：协议配置（是否开启CRC校验），通过静态的方法创建配置对象 GlobalSwitch：实例级配置，每个AbstractConfigurableInstance拥有自己的GlobalSwitch配置，默认值取自SystemProperty，可以通过API调整配置 ConfigItem：Netty相关的配置项的枚举，不可以继承拓展（用户需要修改源码） ConfigManager：配置读取入口，通过静态方法读取SystemProperty的配置 Configs：配置项名称的定义和配置项的默认值 整体上看Bolt的配置项比较零散，且对用户来说难以拓展使用，有以接口暴露的配置项、有以静态方法暴露的配置项，配置项可以通过系统参数配置也可以通过API执行配置。\n且Bolt配置项存在相互影响的问题，比如一个产品同时使用了RPC和消息，而RPC和消息底层都依赖于Bolt，那么基于SystemProperty的配置将无法做到RPC和消息的配置隔离。\n在1.6.0版本中对配置模块进行了调整，在兼容当前版本配置的情况下：\n 收敛配置入口，提供统一的配置的编程界面（以类似Netty的Option的方式进行配置） 支持配置隔离，不同的Bolt实例使用不同的配置项 提升配置的可扩展性 ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-roadmap/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3d4eac90b5c8e657d14eb885ab1f9a92","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","summary":"发展路线 Version 1.5.1 修复项目中代码风格的问题：https://github.com/alipay/sofa-bolt/issues/85 修复项目中已","tags":null,"title":"SOFABolt 发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/","wordcount":1356},{"author":null,"categories":null,"content":" 介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。\n 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生。 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生。 Bolt 名字取自迪士尼动画-闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。 这些年我们在微服务与消息中间件在网络通信上解决过很多问题，积累了很多经验，并持续的进行着优化和完善，我们希望能把总结出的解决方案沉淀到 SOFABolt 这个基础组件里，让更多的使用网络通信的场景能够统一受益。 目前该产品已经运用在了蚂蚁中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。\n多语言 node python cpp ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/overview/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5ee08df7c4bbd2c3be846e16f3bc81b1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/overview/","summary":"介绍 SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于","tags":null,"title":"SOFABolt 概述","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/overview/","wordcount":369},{"author":null,"categories":null,"content":" 用户指南 maven coordinator \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; check release note for version\n 1. 基础功能 1.1 实现用户请求处理器 (UserProcessor) 我们提供了两种用户请求处理器，SyncUserProcessor 与 AsyncUserProcessor。 二者的区别在于，前者需要在当前处理线程以return返回值的形式返回处理结果；而后者，有一个 AsyncContext 存根，可以在当前线程，也可以在异步线程，调用 sendResponse 方法返回处理结果。示例可参考如下两个类：\n 同步请求处理器 异步请求处理器 1.2 实现连接事件处理器 (ConnectionEventProcessor) 我们提供了两种事件监听，建连事件（ConnectionEventType.CONNECT）与断连事件（ConnectionEventType.CLOSE），用户可以创建自己的事件处理器，并注册到客户端或者服务端。客户端与服务端，都可以监听到各自的建连与断连事件。\n 处理连接建立事件 处理连接断开事件 1.3 客户端与服务端初始化 (RpcClient，RpcServer) 我们提供了一个 RpcClient 与 RpcServer，经过简单的必要功能初始化，或者功能开关，即可使用。一个最简单的例子如下：\n 客户端初始化示例 服务端初始化示例 1.4 基础通信模型 我们提供了四种通信模型：\n1.Oneway 调用\n当前线程发起调用后，不关心调用结果，不做超时控制，只要请求已经发出，就完成本次调用。注意 Oneway 调用不保证成功，而且发起方无法知道调用结果。因此通常用于可以重试，或者定时通知类的场景，调用过程是有可能因为网络问题，机器故障等原因，导致请求失败。业务场景需要能接受这样的异常场景，才可以使用。请参考示例。\n2. Sync 同步调用\n当前线程发起调用后，需要在指定的超时时间内，等到响应结果，才能完成本次调用。如果超时时间内没有得到结果，那么会抛出超时异常。这种调用模式最常用。注意要根据对端的处理能力，合理设置超时时间。请参考示例。\n3. Future调用\n当前线程发起调用，得到一个 RpcResponseFuture 对象，当前线程可以继续执行下一次调用。可以在任意时刻，使用 RpcResponseFuture 对象的 get() 方法来获取结果，如果响应已经回来，此时就马上得到结果；如果响应没有回来，则会阻塞住当前线程，直到响应回来，或者超时时间到。请参考示例。\n4. Callback异步调用\n当前线程发起调用，则本次调用马上结束，可以马上执行下一次调用。发起调用时需要注册一个回调，该回调需要分配一个异步线程池。待响应回来后，会在回调的异步线程池，来执行回调逻辑。请参考示例。\n1.5 日志打印 SOFABolt 只依赖 SLF4J 作为日志门面。同时提供了 log4j、log4j2、logback 三种日志模板，使用者只需要在运行时依赖某一种日志实现，我们依赖的 sofa-common-tools 组件，会在运行时动态感知是哪一种日志实现，同时加载正确的日志模板，进行打印。日志会打印在 ~/logs/bolt/ 目录下面，包括如下几种日志：\n common-default.log：默认日志，打印一些客户端、服务器启动、关闭等通信过程的普通日志 common-error.log：异常日志，框架运行过程中出现的异常 connection-event.log：连接事件日志 remoting-rpc.log：RPC 协议相关的日志 关于日志依赖，可以参考日志实现依赖参考\n2. 进阶功能 2.1 请求上下文 在调用过程中，我们还提供了带 InvokeContext 的接口，并一路传递下去，可以在自定义序列化器，用户请求处理器中获得。我们分为两种场景来使用请求上下文：\n 客户端：用户可以设置一些针对本次请求生效的参数，比如序列化类型，是否开启crc等机制。同时可以从上下文中获取建连耗时，连接信息等。 服务端：用户可以从用户请求处理器中获得请求到达后的排队耗时，连接信息等 注意：客户端与服务端的上下文是独立的，即客户端设置的上下文只在客户端可见，对服务端不可见；反之同理。 使用示例 2.2 双工通信 除了服务端可以注册用户请求处理器，我们的客户端也可以注册用户请求处理器。此时，服务端就可以发起对客户端的调用，也可以使用 1.4 提到了任何一种通信模型。\n 示例1：使用 Connection 对象的双工通信，注意使用 Connection 对象的双工通信，服务端需要通过事件监听处理器或者用户请求处理器，自己保存好 Connection 对象。 示例2：使用 Address 的双工通信，注意使用 Address 方式的双工通信，需要在初始化 RpcServer 时，打开 manageConnection 开关，表示服务端会根据客户端发起的建连，维护一份地址与连接的映射关系。默认不需要双工通信的时候，这个功能是关闭的。 2.3 建立多连接与连接预热 通常来说，点对点的直连通信，客户端和服务端，一个 IP 一个连接对象就够用了。不管是吞吐能力还是并发度，都能满足一般业务的通信需求。而有一些场景，比如不是点对点直连通信，而是经过了 LVS VIP，或者 F5 设备的连接，此时，为了负载均衡和容错，会针对一个 URL 地址建立多个连接。我们提供如下方式来建立多连接，即发起调用时传入的 URL 增加如下参数 127.0.0.1:12200?_CONNECTIONNUM=30\u0026amp;amp;_CONNECTIONWARMUP=true，表示针对这个 IP 地址，需要建立30个连接，同时需要预热连接。其中预热与不预热的区别是：\n 预热：即第一次调用（比如 Sync 同步调用），就建立30个连接 不预热：每一次调用，创建一个连接，直到创建满30个连接 使用示例 2.4 自动断连与重连 通常 RPC 调用过程，是不需要断链与重连的。因为每次 RPC 调用过程，都会校验是否有可用连接，如果没有则新建一个。但有一些场景，是需要断链和保持长连接的：\n 自动断连：比如通过 LVS VIP 或者 F5 建立多个连接的场景，因为网络设备的负载均衡机制，有可能某一些连接固定映射到了某几台后端的 RS 上面，此时需要自动断连，然后重连，靠建连过程的随机性来实现最终负载均衡。注意，开启了自动断连的场景，通常需要配合重连使用。 重连：比如客户端发起建连后，由服务端来通过双工通信，发起请求到客户端。此时如果没有重连机制，则无法实现。 使用示例，注意考虑一个进程可能会有多个 SOFABolt 的通信实例，我们提供了全局开关以及用户开关两种开关方式： …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-handbook/","fuzzywordcount":3600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2a0a2e3c7749dbcdceea064f6f850e33","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","summary":"用户指南 maven coordinator \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; check release note for version 1. 基础功能 1.1 实现用户请求处理器 (UserProcessor) 我们提供了两种用户请求处理器，SyncUserProcessor 与 Async","tags":null,"title":"SOFABolt 用户手册","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/","wordcount":3516},{"author":null,"categories":null,"content":" 相关链接 ISSUES 用户手册 中文介绍文章: 蚂蚁通信框架实践 ","date":-62135596800,"description":"","dir":"projects/sofa-bolt/related-links/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6844d2a639b69fa3128132b8631f33e3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/related-links/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-bolt/related-links/","summary":"相关链接 ISSUES 用户手册 中文介绍文章: 蚂蚁通信框架实践","tags":null,"title":"SOFABolt 相关链接","type":"projects","url":"/sofastack.tech/projects/sofa-bolt/related-links/","wordcount":24},{"author":null,"categories":null,"content":" # Upgrade SOFABoot from 2.3.x/2.4.x to 2.5.x SOFABoot 2.3.x/2.4.x is developed based on Spring Boot 1.4.2.RELEASE, SOFABoot 2.5.x is developed based on Spring Boot 1.5.x. When upgrading SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x, we should pay special attention to the differences between the Spring Boot 1.5.x upgrade and the Spring Boot 1.4.x upgrade.\nRenamed Spring Boot Starters spring-boot-starter-ws \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-data-redis Endpoint Security Control Spring Boot 1.5.x has security control over all sensitive endpoints by default, that is, endpoints such as /beans and /dump, which were previously accessible by default in version 1.4.x, are not accessible in version 1.5.x. To access such endpoints, we need to configure Spring Boot as follows: \u0026amp;gt; management.security.enabled=false\nOnly /health, /info, and /docs are accessible by default in version 1.5.x. Please refer to official description for details: + endpoints + Accessing sensitive endpoints\nApplicationEvent Change ApplicationStartedEvent in 1.4.x has been renamed ApplicationStartingEvent in Spring Boot 1.5.x. The version 1.5.x remains forward compatible. Note that the ApplicationStartedEvent event has a completely different meaning in version 2.x.\n** Users who have upgraded the SOFABoot to the version 2.5.x are strongly advised to change ApplicationStartedEvent to ApplicationStartingEvent to avoid compatibility issues when upgrading SOFABoot to the version 3.0.x in the future.**\nProperty renaming server.max-http-post-size \u0026amp;ndash;\u0026amp;gt; server.tomcat.max-http-post-size spring.data.neo4j.session.scope is removed Refer to the configuration of Spring Boot 1.5.x changelog\nSummary The above are the major points worthy of notice when we upgrade SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x. For detailed information, refer to the Release Report of Spring Boot 1.5.x.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_2_5_x/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4b7dd4287b00106684831d2a8524a6f7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","summary":"# Upgrade SOFABoot from 2.3.x/2.4.x to 2.5.x SOFABoot 2.3.x/2.4.x is developed based on Spring Boot 1.4.2.RELEASE, SOFABoot 2.5.x is developed based on Spring Boot 1.5.x. When upgrading SOFABoot 2.3.x/2.4.x to SOFABoot 2.5.x, we should pay special attention to the differences between the Spring Boot 1.5.x upgrade and the Spring Boot 1.4.x upgrade.\nRenamed Spring Boot Starters spring-boot-starter-ws \u0026ndash;\u0026gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026ndash;\u0026gt; spring-boot-starter-data-redis Endpoint Security Control Spring Boot 1.","tags":null,"title":"SOFABoot 2.5.x upgrade","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/","wordcount":251},{"author":null,"categories":null,"content":" SOFABoot 2.3.x/2.4.x 升级到 2.5.x SOFABoot 2.3.x/2.4.x 基于 Spring Boot 1.4.2.RELEASE 版本开发，SOFABoot 2.5.x 则是基于 Spring Boot 1.5.x 版本开发。 从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 需要重点考虑 Spring Boot 1.5.x 相较 Spring Boot 1.4.x 的升级注意点。\n重命名的 spring boot starters spring-boot-starter-ws \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-web-services spring-boot-starter-redis \u0026amp;ndash;\u0026amp;gt; spring-boot-starter-data-redis endpoint 安全性控制 Spring Boot 1.5.x 对所有 Sensitive Endpoint 默认进行了安全管控，即之前在 1.4.x 默认能访问的诸如 /beans, /dump 等 endpoints 在 1.5.x 版本均不能访问。如果需要访问，需要配置： \u0026amp;gt; management.security.enabled=false\n默认情况下，在 1.5.x 只有 /health, /info, /docs 能够访问。详细请参考官方描述： + endpoints + Accessing sensitive endpoints\nApplicationEvent 变更 Spring Boot 1.5.x 将 1.4.x 中的 ApplicationStartedEvent 重命名为 ApplicationStartingEvent，在 1.5.x 仍然保持向前兼容。需要格外注意的是，在 2.x 版本中，ApplicationStartedEvent 事件意义完全不一样。\n强烈建议升级到 SOFABoot 2.5.x 的用户，将应用中使用的 ApplicationStartedEvent 变更为 ApplicationStartingEvent；避免今后升级至 SOFABoot 3.0.x 出现兼容性问题\nProperty 重命名 server.max-http-post-size \u0026amp;ndash;\u0026amp;gt; server.tomcat.max-http-post-size spring.data.neo4j.session.scope 被移除 具体参考 Spring Boot 1.5.x 配置的 changelog\n总结 以上总结了从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 的几个主要注意点，详细可以参考 Spring Boot 1.5.x 的发布报告\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_2_5_x/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4b7dd4287b00106684831d2a8524a6f7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","summary":"SOFABoot 2.3.x/2.4.x 升级到 2.5.x SOFABoot 2.3.x/2.4.x 基于 Spring Boot 1.4.2.RELEASE 版本开发，SOFABoot 2.5.x 则是基于 Spring Boot 1.5.x 版本开发。 从 SOFABoot 2.3.x/2.4.x 升级到 SOFABoot 2.5.x 需要重点考虑 Spring Boot 1.5.x 相较 Spring Boot 1.4.x 的升级注意点。 重命","tags":null,"title":"SOFABoot 2.5.x 升级注意事项","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/","wordcount":404},{"author":null,"categories":null,"content":" ## Preface As a Spring Boot-based development framework open sourced by Ant Financial, SOFABoot provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nWe have received a lot of feedback from community users since SOFABoot was open sourced in April 2018. We are also very pleased to see many community users take an active part in building the SOFAStack open source, which greatly increases our determination to prosper SOFAStack community and ecosystem. Here, we announce the release of the SOFABoot 3.0, which is developed based on Spring Boot 2.0. SOFABoot 3.0 allows us to seamlessly integrate the extension capability of SOFABoot with official components of Spring Boot 2.x. In addition, SOFABoot 3.0 is compatible with Spring Cloud components, which allows us to easily integrate Spring Cloud components like Zuul and Config in the SOFABoot framework.\nBelow are the major changes of SOFABoot 3.0 compared with SOFABoot 2.x.\nUpgrade Spring Boot to version 2.x Upgrade Spring Boot in SOFABoot 3.0 to version 2.0. As the Spring Boot community recently announced that the maintenance for version 1.x will end in August 2019, we will focus on SOFABoot 3.x in the future and will release SOFABoot 3.1 with Spring Boot upgraded to version 2.1 soon.\nSpring Cloud compatible Some components are not compatible with SOFABoot in SOFABoot 2.x. In SOFABoot 3.x, we have run thorough compatibility tests on Spring Cloud components and fixed all problems found to ensure good compatibility between SOFABoot 3.x and Spring Cloud.\nWebFlux framework compatible Spring Boot 2.x introduces the WebFlux framework. SOFABoot 3.x is compatible with WebFlux in two major aspects; + Health Check is compatible with the ReactiveHealthIndicator extension interface. The Readiness Check will include the implementation of the interface extension; + Compatible with buried points of WebFlux web requests. Point burying logs and files are compatible with common MVC requests. For detailed information, refer to MVC point burying request.\nJDK version support SOFABoot 3.x must run on JDK 8 or higher versions and does not support JDK 6 and JDK 7.\nHealth Check SOFABoot adds Readiness Check capability to Spring Boot\u0026amp;rsquo;s Health Check capability, to ensure that all components and operations are in a healthy state before the application goes into services. Compared with SOFABoot 2.x, SOFABoot 3.0 features great adjustments to the Health Check. It abandons some internal compatibility logic of Ant Financial and uses a friendlier coding scheme. Besides, the Health Check of SOFABoot 3.0 offers extensions in various scenarios, supports the \u0026amp;lsquo;ReactiveHealthIndicator\u0026amp;rsquo; extension interface introduced in Spring Boot 2.x, and provides more Health Check extension features.\nAdjust the Readiness Check Endpoint path The Endpoint for checking the …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_3_x/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"91ba09adf6bc42aaf70645b9a19b409b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","summary":"## Preface As a Spring Boot-based development framework open sourced by Ant Financial, SOFABoot provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nWe have received a lot of feedback from community users since SOFABoot was open sourced in April 2018. We are also very pleased to see many community users take an active part in building the SOFAStack open source, which greatly increases our determination to prosper SOFAStack community and ecosystem.","tags":null,"title":"SOFABoot 3.0 upgrade","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/","wordcount":910},{"author":null,"categories":null,"content":" 前言 SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n自今年 4 月份 SOFABoot 开源至今，我们收到了非常多来自社区同学的反馈，也非常高兴的看到很多社区同学积极的参与到 SOFAStack 开源共建，这极大了鼓舞了我们建设 SOFAStack 开源社区的决心，力图把 SOFAStack 社区和生态建设更加繁荣。在此，我们宣布推出 SOFABoot 3.0 版本，SOFABoot 3.0 是基于 Spring Boot 2.0 版本开发。在 SOFABoot 3.0 中，可以将 SOFABoot 扩展能力和 Spring Boot 2.x 官方组件无缝集成。此外，我们在 SOFABoot 3.0 中兼容了 Spring Cloud 组件集成，可以很方便地在 SOFABoot 框架中集成 Spring Cloud 组件，如 Zuul, Config 等。\n以下，本文将详细介绍 SOFABoot 3.0 相较 SOFABoot 2.x 的变更。\nSpring Boot 升级 2.x SOFABoot 3.0 版本升级 Spring Boot 版本至 2.0。鉴于Spring Boot 社区最近刚公告 1.x 版本将维护至明年 8 月份为止，未来，我们也将主力维护 SOFABoot 3.x 版本，近期也将发布 SOFABoot 3.1 升级 Spring Boot 版本至 2.1。\nSpring Cloud 兼容 在 SOFABoot 2.x 中，存在部分组件和 SOFABoot 兼容性问题。在 SOFABoot 3.x 中，对 Spring Cloud 各组件进行了比较完备的兼容性测试和问题修复，保证了 SOFABoot 3.x 与 Spring Cloud 良好的兼容性。\nWebFlux 框架兼容 Spring Boot 2.x 引入了 WebFlux 框架，SOFABoot 3.x 主要在两个方面兼容了 WebFlux 框架； + 健康检查兼容了 ReactiveHealthIndicator 扩展接口，业务对这个接口的扩展实现将会纳入到 Readiness Check； + 兼容对 WebFlux 网络请求进行埋点，埋点日志格式和文件保持对普通 MVC 请求兼容，详细参考MVC 埋点请求\nJDK 版本支持 SOFABoot 3.x 最低要求运行在 JDK 8 及其以上版本，不支持 JDK 6，7。\n健康检查 SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 能力，以确保应用在正常对外服务前，所有组件及业务本身处于健康状态。相较于与 SOFABoot 2.x, SOFABoot 3.0 在健康检查做了很大的重构，主要是剥离了部分蚂蚁金服内部兼容逻辑，采用更加友好的编码方案；其次，SOFABoot 3.0 健康检查提供了多种不同场景下的健康检查扩展形式，支持 Spring Boot 2.x 引入的 ReactiveHealthIndicator 扩展接口，丰富了健康检查扩展特性。\n调整 Readiness Check Endpoint 路径 在 SOFABoot 2.x 中，查看健康检查结果的 Endpoint 为 /health/readiness，而在 SOFABoot 3.0 中，变更为 /actuator/readiness。\n扩展接口变更 在 SOFABoot 3.x 中，提供四种方式扩展健康检查，分别是 + HealthChecker + HealthIndicator(Spring Boot 原生) + ReactiveHealthIndicator(Spring Boot 原生) + ReadinessCheckCallback\n这四个接口的扩展实现执行顺序是 HealthChecker \u0026amp;gt; HealthIndicator, ReactiveHealthIndicator \u0026amp;gt; ReadinessCheckCallback，相同接口的扩展实现执行顺序则遵循 Spring Boot 标准的方案。即扩展类可以额外实现两个标准的 Order 接口：\n org.springframework.core.Ordered org.springframework.core.PriorityOrdered 或者使用注解\n org.springframework.core.annotation.Order 这些接口的扩展实现处理结果将会在健康检查结果查中展现。\n删除 SofaBootBeforeHealthCheckEvent 事件 在 SOFABoot 2.x 中，我们没有提供支持对健康检查扩展实现进行排序，导致用户无法预期自身扩展执行时机。如上述，SOFABoot 3.x 支持各组件扩展实现的排序，因此该事件可以统一使用 HealthChecker 接口和高优先级顺序实现替代。其次，在 SOFABoot 2.x 中，SofaBootBeforeHealthCheckEvent 事件的处理逻辑结果并不会反应在健康检查结果中，使用 HealthChecker 替代之后，这部分逻辑处理自然变成健康检查的一部分，可供查看。\n删除 DefaultHealthChecker 接口 使用 JDK8 默认方法特性，删除 DefaultHealthChecker 接口，用户可以直接使用 HealthChecker 接口替代 DefaultHealthChecker.\n删除 SofaBootMiddlewareAfterReadinessCheckCallback 和 SofaBootAfterReadinessCheckCallback 接口 在 SOFABoot 2.x 中，这两个接口是两种场景下的健康检查回调；推荐 SOFABoot 官方 Starter 使用 SofaBootMiddlewareAfterReadinessCheckCallback，而业务应用推荐使用SofaBootAfterReadinessCheckCallback，框架将优先执行 SofaBootMiddlewareAfterReadinessCheckCallback 的扩展实现，然后执行 SofaBootAfterReadinessCheckCallback 的扩展实现。这样的设计有两个缺陷： + 两个接口本质没有区别，但是隐藏了先后顺序逻辑，给用户引入了额外的学习成本； + 只考虑了 SofaBootMiddlewareAfterReadinessCheckCallback 和 SofaBootAfterReadinessCheckCallback 两个接口的顺序，但无法保证相同接口实现的执行顺序。\nSOFABoot 3.x …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_3_x/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"91ba09adf6bc42aaf70645b9a19b409b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_3_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_3_x/","summary":"前言 SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFA","tags":null,"title":"SOFABoot 3.0 升级注意事项","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_3_x/","wordcount":1687},{"author":null,"categories":null,"content":" Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开发。\n二方库升级 SOFABoot 4.0 基于 Spring Boot 3.0 与 Spring Framework 6 构建。在 Spring Boot 3.0 与 Spring Framework 6 引入的二方库升级列表可参考文档👉 Spring Boot 3.0 Release Notes\n在 SOFABoot 4.0 引入的二方库升级列表如下：\n Spring Boot 3.0.7 Spring Cloud 4.0.0 Spring Cloud Stream 3.2.6 SOFA Common tools 2.0.0 SOFATracer 4.0.0 SOFARPC 5.10.0 FastJson 1.2.83 Guava 31.1-jre Grpc 1.51.1 Grpc common protos 2.11.0 Druid 1.2.16 ASM 9.4 Javassist 3.29.2-GA Curator 4.3.0 Dubbo 3.1.8 Nacos 2.0.3 Swagger 1.6.7 Swagger2 2.2.8 基于 Jakarta EE Spring Boot 3.0 中依赖 Jakarta EE 规范的部分已经升级到了 Jakarta EE 10 版本。例如，使用 Servlet 6.0 和 JPA 3.1 规范。因此，部分包的命名空间也进行了替换，例如你应该使用：\n✅jakarta.servlet.Filter\n而不是 javax.servlet.Filter。\n同时，如果你使用了自己的依赖提供 Jakarta EE 规范的 API，需注意进行对应的依赖升级，例如你应该使用：\n✅jakarta.servlet:jakarta.servlet-api\n而不是 javax.servlet:javax.servlet-api。\n可参考文档：Migrate to Jakarta EE 9 来修改 Jakarta 相关的包名以及依赖。\n支持 SOFAArk 2.0 SOFAArk 2.0 模式是 SOFAArk 框架的整体优化版本，相较于 SOFAArk 1.0 模式，它的整体优化思路和原则是 Ark Master Biz 保持和原生 SOFABoot 保持一致，弱化复杂的 Ark Plugin 类管控机制，将 Ark Plugin 与 Master Biz 合并。使得 Ark Master Biz 和原生 SOFABoot 应用的启动方式、类加载方式保持一致，大大降低了 Master Biz 应用的编程难度。\nSOFABoot 4.0 版本不再支持 SOFAArk 1.0 模式，如果你想要在 SOFABoot 应用中使用 SOFAArk 2.0 模式，可以按照以下步骤进行操作：\n1、在项目中引入 SOFAArk 组件依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;ark-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2、添加 Spring Boot 的 Package 插件\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;package\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 3、启动应用\n 方式一： IDEA 启动，注意需要添加启动参数：-Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}\n 方式二： 命令行启动，先运行 mvn clean package 命令进行打包，生成 ${bizName}-${bizVersion}-ark-biz.jar 的可执行文件，然后在终端运行以下启动参数：\njava -jar -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName} ${bizName}-${bizVersion}-ark-biz.jar\n支持场景化的按配置加载能力 通常情况下，应用在不同的场景下可能需要开启或者关闭不同的功能，Spring Boot 提供了丰富的 Configuration 动态配置能力[4] 能力以支持应用在不同的场景下加载不同的 Bean。\nSOFABoot 在此基础上，对 org.springframework.context.ApplicationContextInitializer 等扩展点进行了增强，支持通过统一风格的配置定制各类 Bean 以及扩展点的开启与关闭，并提供了定制模版配置的开启方式以降低应用配置项的复杂度。\n 通过： com.alipay.sofa.boot.autoconfigure.condition.ConditionalOnSwitch 注解为 Bean 添加按配置开启能力：\n@Configuration(proxyBeanMethods = false) @ConditionalOnSwitch(id=\u0026amp;quot;sample\u0026amp;quot;) public class SampleConfiguration { @Bean public SampleBean sampleBean() { return new SampleBean(); } } 添加：\nsofa.boot.switch.bean.sample.enabled=false 配置后，SampleConfiguration 配置类将不再加载。\n 通过继承： …","date":-62135596800,"description":"","dir":"projects/sofa-boot/upgrade_4_x/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5c33e340d1a0200b2dac6aa548142849","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_4_x/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/upgrade_4_x/","summary":"Part.1 「亿点点」新特性 基于 Java 17 SOFABoot 4.0 依赖 Java 17 作为最小支持的 JDK 版本。如果你的应用目前使用 Java 8 或 11，你需要先将自己的 JDK 版本升级到 17 才能基于 SOFABoot 4.0 进行开","tags":null,"title":"SOFABoot 4.0 正式发布，多项新特性等你来体验！","type":"projects","url":"/sofastack.tech/projects/sofa-boot/upgrade_4_x/","wordcount":3757},{"author":null,"categories":null,"content":" SOFABoot supports modular isolation. But in actual usage scenarios, There is one case that beans in one module sometimes need to open some entries for another module to expand. SOFABoot draws on and uses the Nuxeo Runtime project and the nuxeo project and expands on it, provides the ability to extend points with Spring, We call it Extension Point.\nUsage Using extension point capabilities in SOFABoot requires the following three steps:\nDefine a bean that provides extension capabilities When using the SOFABoot extension point capability, you first need to define an interface that needs to be extended, like:\npackage com.alipay.sofa.boot.test; public interface IExtension { String say(); } Define the implementation of this interface:\npackage com.alipay.sofa.boot.test.impl; public class ExtensionImpl implements IExtension { private String word; @Override public String say() { return word; } public void setWord(String word) { this.word = word; } public void registerExtension(Extension extension) throws Exception { Object[] contributions = extension.getContributions(); String extensionPoint = extension.getExtensionPoint(); if (contributions == null) { return; } for (Object contribution : contributions) { if (\u0026amp;quot;word\u0026amp;quot;.equals(extensionPoint)) { setWord(((ExtensionDescriptor) contribution).getValue()); } } } } Here you can see that there is a method: registerExtension, you can temporarily ignore this method, and later will introduce its specific role.\nIn the module\u0026amp;rsquo;s Spring configuration file, we add configuration of this bean:\n\u0026amp;lt;bean id=\u0026amp;quot;extension\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.test.impl.ExtensionImpl\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;word\u0026amp;quot; value=\u0026amp;quot;Hello, world\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; Defining extension points There is a field word in the above bean. In practice, we want this field to be overridden by other module customizations. Here we expose it as an extension point.\nFirst, you need a class to describe this extension point:\n@XObject(\u0026amp;quot;word\u0026amp;quot;) public class ExtensionDescriptor { @XNode(\u0026amp;quot;value\u0026amp;quot;) private String value; public String getValue() { return value; } } Then define the extension point in xml:\n\u0026amp;lt;sofa:extension-point name=\u0026amp;quot;word\u0026amp;quot; ref=\u0026amp;quot;extension\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:object class=\u0026amp;quot;com.alipay.sofa.boot.test.extension.ExtensionDescriptor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:extension-point\u0026amp;gt; among them: - name is the name of the extension point - ref is the bean to which the extension point is applied - object is a concrete description of the contribution point of the extension point. This description is done by XMap (XMap is used to map Java objects and XML files. It is recommended to search XMap documents on the Internet to understand XMap)\nDefining extension implements The above has defined the extension point, and we can extend this bean at this point:\n\u0026amp;lt;sofa:extension bean=\u0026amp;quot;extension\u0026amp;quot; point=\u0026amp;quot;word\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:content\u0026amp;gt; \u0026amp;lt;word\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/extension/","fuzzywordcount":1300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"93225b6c1f2b68f2047a7cf49b76650b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/extension/","summary":"SOFABoot supports modular isolation. But in actual usage scenarios, There is one case that beans in one module sometimes need to open some entries for another module to expand. SOFABoot draws on and uses the Nuxeo Runtime project and the nuxeo project and expands on it, provides the ability to extend points with Spring, We call it Extension Point. Usage Using extension point capabilities in SOFABoot requires the following three","tags":null,"title":"SOFABoot Extension Point","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/extension/","wordcount":1279},{"author":null,"categories":null,"content":" Spring 框架从 3.1.X 版本开始提供了 profile 功能: Bean Definition Profiles，SOFABoot 支持模块级 profile 能力，即在各个模块启动的时候决定模块是否能够启动。\n使用 Module-Profile 激活 module 使用 SOFABoot 的 profile 功能，需要在 application.properties 文件增加 com.alipay.sofa.boot.active-profiles 字段，该字段的值为逗号分隔的字符串，表示允许激活的 profile 列表，指定该字段后，SOFABoot 会为每个可以激活的模块指定此字段表示的 profile 列表。\nSOFABoot 模块的 sofa-module.properties 文件支持 Module-Profile 字段，该字段的值为逗号分隔的字符串，表示当前模块允许在哪些 profile 激活。Module-Profile 支持取反操作， !dev 表示 com.alipay.sofa.boot.active-profiles 不包含 dev 时被激活。\n当应用未指定 com.alipay.sofa.boot.active-profiles 参数时，表示应用所有模块均可启动。SOFABoot 模块未指定 Module-Profile 时，表示当前 SOFABoot 模块可以在任何 profile 启动。\n使用例子 激活 dev SOFABoot 模块 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev 该配置表示激活 profile 为 dev 的模块。\n在每个需要限定为 dev profile 被激活模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=dev 配置多个激活 profile application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev,test 该配置表示激活 profile 为 dev 或者 test 的模块。\n在 SOFABoot 模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=test,product 该配置表示当 com.alipay.sofa.boot.active-profiles 包含 test 或者 product 时激活模块，由于当前指定的 com.alipay.sofa.boot.active-profiles 为 dev,test ，此模块将被激活。\nModule-Profile 取反 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev 该配置表示激活 profile 为 dev 的模块。\n在 SOFABoot 模块的 sofa-module.properties 文件中增加如下配置：\nModule-Profile=!product 该配置表示当 com.alipay.sofa.boot.active-profiles 不包含 product 时激活模块，由于当前指定的 com.alipay.sofa.boot.active-profiles 为 dev ，此模块将被激活。\n设置激活模块 Spring 上下文的 spring.profiles.active 属性 application.properties 中增加配置如下：\ncom.alipay.sofa.boot.active-profiles=dev,test 该配置表示激活 profile 为 dev 或者 test 的模块，当一个模块满足上面的激活条件时，这个模块就会被启动，同时 Spring 上下文的环境信息 spring.profiles.active 也被设置为了 dev,test ，这样如下的配置 beanId 为 devBeanId 和 testBeanId 的bean都会被激活。\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:jdbc=\u0026amp;quot;http://www.springframework.org/schema/jdbc\u0026amp;quot; xmlns:jee=\u0026amp;quot;http://www.springframework.org/schema/jee\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.2.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;beans profile=\u0026amp;quot;dev\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;devBeanId\u0026amp;quot; class=\u0026amp;quot;com.alipay.cloudenginetest.sofaprofilesenv.DemoBean\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;name\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;demoBeanDev\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/property\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; \u0026amp;lt;beans profile=\u0026amp;quot;test\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBeanId\u0026amp;quot; class=\u0026amp;quot;com.alipay.cloudenginetest.sofaprofilesenv.DemoBean\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;name\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;demoBeanTest\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/property\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-profile/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b29d568fa057cad0b440790d5cc65d07","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-profile/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-profile/","summary":"Spring 框架从 3.1.X 版本开始提供了 profile 功能: Bean Definition Profiles，SOFABoot 支持模块级 profile 能力，即在各个模块启动的时候决定模块是否能够启动。 使用 Module-Profile 激","tags":null,"title":"SOFABoot Profile","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-profile/","wordcount":666},{"author":null,"categories":null,"content":" Background kc-sofastack-demo has introduced how to quickly build an e-commerce microservice application and has implemented the service calling link tracking and application status monitoring.\nIn e-commerce system, the platforms often are not satisfied with the default product listing order, and always want to arrange some products in the conspicuous places. Also, there are some cases where the platforms would like to show different products to different users based on the collected user behaviors.\nBased on the background of kc-sofastack-demo, this guide will implement sorting the products dynamically based on the total amount of products of each onsite attendee.\nDemo content Implement the dynamic change of product sorting via the dynamic module capability provided by SOFABoot and the dynamic module control capability of SOFADashboard.\nImplement the change of application behavior without restarting the host and without changing the application configuration.\nThe project architecture is as follows:\nTasks 1. Preparation Clone the demo from GitHub to local\ngit clone https://github.com/sofastack-guides/kc-sofastack-dynamic-demo.git Then, import the project into IDEA or Eclipse.\n2. Package SOFABoot project as Ark JAR As shown in the following screenshot, add the Ark package plugin in the POM file and configure it:\nStep 1: Copy the Ark plugin and configuration to the specified positions in the above screenshot \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!-- package configuration of ark-biz JAR --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!-- Whether to package, install and publish ark biz. The default value is false. For details, see Ark Biz documentation.--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!-- The directory for ark package and ark biz package, defaulting to the build directory of project--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- The priority of starting ark-biz package. The smaller the value, the higher the priority.--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;200\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--Set the root directory of application, used to read ${base.dir}/conf/ark/bootstrap.application configuration file and defaulting to ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;../\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; Step 2: Run mvn clean package to package the project. The successfully packaged JAR file is as shown in the following screenshot:\n3. Build host application In the downloaded project, dynamic-stock-mng is the host application model. In this task, we will build dynamic-stock-mng as the host application of dynamic module.\nStep 1: Introduce Ark …","date":-62135596800,"description":"This guide introduce how to implement the merged deployment and dynmaic module push provided by SOFAArck based on the Ark control function of SOFADashboard.","dir":"guides/kc-sofastack-dynamic-demo/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"8bfd4a50e21ce9fc867b1cf18a8c9af3","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","summary":"Background kc-sofastack-demo has introduced how to quickly build an e-commerce microservice application and has implemented the service calling link tracking and application status monitoring.\nIn e-commerce system, the platforms often are not satisfied with the default product listing order, and always want to arrange some products in the conspicuous places. Also, there are some cases where the platforms would like to show different products to different users based on the collected user behaviors.","tags":null,"title":"SOFABoot dynamic module practice","type":"guides","url":"/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/","wordcount":630},{"author":null,"categories":null,"content":" SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nYou can view all the release notes in Release History. The correspondence between SOFABoot version and Spring Boot version is as follows:\n SOFABoot version Spring Boot version 2.3.x 1.4.2.RELEASE 2.4.x 1.4.2.RELEASE 2.5.x 1.5.16.RELEASE 3.0.x 2.0.3.RELEASE 3.1.0 2.1.0.RELEASE That is, the SOFABoot 2.3.x and 2.4.x series are based on Spring Boot 1.4.2.RELEASE; SOFABoot 2.5.x series are based on Spring Boot 1.5.x; SOFABoot 3.x series are based on Spring Boot 2.x. You can view and get the codes of all revisions in Release History. In addition, to facilitate users in the community to learn the latest development version of SOFABoot, we will release the SNAPSHOT version, which is a branch of the current development. To successfully pull the SNAPSHOT package from the central repository, it\u0026amp;rsquo;s necessary to add the following profile configuration to the local maven setting.xml file:\n\u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; Feature Description Based on Spring Boot, SOFABoot provides the following capabilities:\n Capability of expanding the Health Check of Spring Boot: Provide the Readiness Check based on the Health Check of Spring Boot, to ensure a secure launch of application examples. Capability of log space isolation: The middleware framework automatically finds the application\u0026amp;rsquo;s logs and realizes dependence on the logs and independent log printing, avoiding binding the middleware and the application logs. The capability is achieved through sofa-common-tools. Capability of providing class isolation: Provide class isolation based on the SOFAArk framework, making it easy for users to solve various class conflicts. Capability of providing modular development: Based on the Spring context isolation, provide modular development capability, with a separate Spring context for each SOFABoot module, to avoid BeanId conflicts between different SOFABoot modules. Integrated management of middleware: manage in a unified manner, provide a unified and easy-to-use …","date":-62135596800,"description":"","dir":"projects/sofa-boot/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"fe6aed461c61b86dfed846a2dc0b7dcb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/overview/","summary":"SOFABoot is a development framework open sourced by Ant Financial which is based on Spring Boot, provides capabilities such as Readiness Check, class isolation, and log space isolation. In addition to enhancing the Spring Boot, SOFABoot provides users with the capability to easily use SOFA middleware in Spring Boot.\nYou can view all the release notes in Release History. The correspondence between SOFABoot version and Spring Boot version is as follows:","tags":null,"title":"SOFABoot overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/overview/","wordcount":461},{"author":null,"categories":null,"content":" Since 3.1.X Spring framework has started to support the profile function: Bean Definition Profiles, SOFABoot support modular-level profiling, it will determine whether a module can be started when each module is getting started.\nActivating Module Using Module-Profile To enable the SOFABoot profiling, we need to add the com.alipay.sofa.boot.active-profiles field in the application.properties file. The value of this field is a comma-separated string denoting a list of profiles allowed to be activated. After specifying it, SOFABoot will specify a profile list represented by the field for each module that can be activated.\nThe sofa-module.properties file of the SOFABoot module supports the Module-Profile field, which points to a comma-separated string of values representing which profiles are allowed to be activated. Module-Profile supports the inversion operation, !dev indicates that com.alipay.sofa.boot.active-profiles is activated when it does not contain dev.\nIf the value of the com.alipay.sofa.boot.active-profiles field is not specified in the application, all modules are allowed to be started. If the Module-Profile is not specified in the SOFABoot module, the current SOFABoot module can be started with any profile.\nExample Activating the dev SOFABoot Module Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev With this configuration, the module with dev profile will be activated.\nAdd the following configuration to each sofa-module.properties file where modules with dev profile need to be activated.\nModule-Profile=dev Configuring Multiple Activation Profiles Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev,test With this configuration, the modules with dev or test profile will be activated.\nAdd the following configuration to the SOFABoot\u0026amp;rsquo;s sofa-module.properties file:\nModule-Profile=test,product With this configuration, the module will be activated when the com.alipay.sofa.boot.active-profiles contains test or product. Since the com.alipay.sofa.boot.active-profiles is specified as dev and test, this module will be activated.\nThe Inverted Module-Profile Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev With this configuration, the module with dev profile will be activated.\nAdd the following configuration to the SOFABoot\u0026amp;rsquo;s sofa-module.properties file:\nModule-Profile=!product This will activate the module when the com.alipay.sofa.boot.active-profiles does not contain product. Since it is specified as dev, this module will be activated.\nSet the spring.profiles.active property that is used to activate the Spring context of the module. Add the following configurations to the application.properties file:\ncom.alipay.sofa.boot.active-profiles=dev,test With this configuration, the modules with dev or test profile will be activated. If a module meets those …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-profile/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b29d568fa057cad0b440790d5cc65d07","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","summary":"Since 3.1.X Spring framework has started to support the profile function: Bean Definition Profiles, SOFABoot support modular-level profiling, it will determine whether a module can be started when each module is getting started.\nActivating Module Using Module-Profile To enable the SOFABoot profiling, we need to add the com.alipay.sofa.boot.active-profiles field in the application.properties file. The value of this field is a comma-separated string denoting a list of profiles allowed to be activated.","tags":null,"title":"SOFABoot profile","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/","wordcount":450},{"author":null,"categories":null,"content":" SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFA 中间件的能力。\n你可以在发布历史中查看所有的发布报告，SOFABoot 版本和 Spring Boot 版本对应关系如下：\n SOFABoot 版本 Spring Boot 版本 3.3.0～3.3.1 2.1.11.RELEASE 3.3.2～3.6.0 2.1.13.RELEASE 3.7.0～3.10.0 2.3.9.RELEASE 3.11.0～3.11.1 2.3.12.RELEASE 3.12.0～3.13.0 2.4.13 3.14.0～3.14.1 2.6.9 3.15.0～3.16.3 2.7.3 3.17.0 2.7.8 3.18.0～3.19.1 2.7.10 4.0.0 ～ 4.0.2 3.0.7 4.1.0 3.1.5 4.2.0 3.2.2 4.3.0 3.2.6 SOFABoot 3.x 系列版本将构建在 Spring Boot 2.x 基础之上，SOFABoot 4.x 系列版本将构建在 Spring Boot 3.x 基础之上 。你可以在发布历史中查看获取所有的历史版本代码。另外为了方便社区同学能够基于最新开发版本的 SOFABoot 进行开发学习，我们会发布当前开发分支的 SNAPSHOT 版本。为顺利从中央仓库拉取 SNAPSHOT 包，需要在本地 maven setting.xml 文件增加如下 profile 配置:\n\u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; 目前 SOFABoot 最新版本为 4.0.0，基于 Spring Boot 3.0.7, 支持 JDK17。\n功能描述 SOFABoot 在 Spring Boot 基础上，提供了以下能力：\n 扩展 Spring Boot 健康检查的能力：在 Spring Boot 健康检查能力基础上，提供了 Readiness Check 的能力，保证应用实例安全上线。 提供模块化开发的能力：基于 Spring 上下文隔离提供模块化开发能力，每个 SOFABoot 模块使用独立的 Spring 上下文，避免不同 SOFABoot 模块间的 BeanId 冲突。 增加模块并行加载和 Spring Bean 异步初始化能力，加速应用启动； 增加日志空间隔离的能力：中间件框架自动发现应用的日志实现依赖并独立打印日志，避免中间件和应用日志实现绑定，通过 sofa-common-tools 实现。 增加类隔离的能力：基于 SOFAArk 框架提供类隔离能力，方便使用者解决各种类冲突问题。 增加中间件集成管理的能力：统一管控、提供中间件统一易用的编程接口、每一个 SOFA 中间件都是独立可插拔的组件。 提供完全兼容 Spring Boot的能力：SOFABoot 基于 Spring Boot 的基础上进行构建，并且完全兼容 Spring Boot。 应用场景 SOFABoot 本身就脱胎于蚂蚁金服内部对于 Spring Boot 的实践，补充了 Spring Boot 在大规模金融级生产场景下一些不足的地方，所以 SOFABoot 特别适合于这样的场景。\n当然，SOFABoot 的每个组件都是可选的，用户可以灵活选择其中的功能来使用，比如如果仅仅想在 Spring Boot 下面引入 SOFA 中间件，可以不需引入 SOFABoot 中的类隔离能力。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/overview/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fe6aed461c61b86dfed846a2dc0b7dcb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/overview/","summary":"SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在增强了 Spring Boot 的同时，SOFABo","tags":null,"title":"SOFABoot 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-boot/overview/","wordcount":938},{"author":null,"categories":null,"content":" SOFABoot 提供了类隔离框架 SOFAArk, 弥补了 Spring Boot 在类隔离能力上的缺失，用以解决在实际开发中常见的类冲突、包冲突问题，详细请参考 SOFAArk。\n在 SOFABoot 工程中使用类隔离能力，只需两步操作；配置 sofa-ark-maven-plugin 打包插件以及引入 sofa-ark-springboot-starter 类隔离框架依赖；\n配置 Maven 打包插件 官方提供了 Maven 插件 - sofa-ark-maven-plugin ，只需要简单的配置项，即可将 SpringBoot 工程打包成标准格式规范的可执行 Ark 包，插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 配置模板如下：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- all class exported by ark plugin would be resolved by ark biz in default, if configure denyImportClasses, then it would prefer to load them by ark biz itself --\u0026amp;gt; \u0026amp;lt;denyImportClasses\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass1\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass2\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/denyImportClasses\u0026amp;gt; \u0026amp;lt;!-- Corresponding to denyImportClasses, denyImportPackages is package-level --\u0026amp;gt; \u0026amp;lt;denyImportPackages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/denyImportPackages\u0026amp;gt; \u0026amp;lt;!-- denyImportResources can prevent resource exported by ark plugin with accurate name to be resolved --\u0026amp;gt; \u0026amp;lt;denyImportResources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test1.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test2.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;/denyImportResources\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 插件配置项解释：\n outputDirectory: 执行 mvn package 命令后，指定打出来的 ark 包存放目录，默认存放至 ${project.build.directory} arkClassifier: 执行 mvn depleoy 命令后，指定发布到仓库的 ark 包的maven坐标的 classifer 值, 默认为空；我们推荐配置此配置项用于和普通的 Fat Jar 加以名字上区别； denyImportClasses: 默认情况下，应用会优先加载 ark plugin 导出的类，使用该配置项，可以禁止应用从 ark plugin 加载其导出类； denyImportPackages: 对应上述的 denyImportClasses, 提供包级别的禁止导入； denyImportResources: 默认情况下，应用会优先加载 ark plugin 导出的资源，使用该配置项，可以禁止应用从 ark plugin 加载其导出资源； 添加类隔离框架依赖 在实际开发中，为了在跑测试用例时使用 SOFABoot 类隔离能力，需要在 SOFABoot 工程中添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 根据 SpringBoot 依赖即服务的原则，添加该依赖之后，应用启动之前，会优先启动 SOFABoot 类隔离容器；\nSOFABoot 的类隔离框架会自动检测应用中是否有引入 Ark Plugin（即需要被隔离的jar包，详情请参考 SOFAArk）, 并隔离加载；例如为了避免 SOFABoot 官方提供的 SOFARPC 组件和应用产生依赖冲突，SOFABoot提供了 SOFARPC 组件对应的 ark plugin 版，用户如果需要隔离 SOFARPC，只需要添加如下组件：\n\u0026amp;lt;dependency\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/classloader-isolation/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e007416ab008c1dd4b886433dbf8af01","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/classloader-isolation/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/classloader-isolation/","summary":"SOFABoot 提供了类隔离框架 SOFAArk, 弥补了 Spring Boot 在类隔离能力上的缺失，用以解决在实际开发中常见的类冲突、包冲突问题，详细请参考 SOFAArk。 在 SOFABoot 工程中使用类","tags":null,"title":"SOFABoot 使用类隔离","type":"projects","url":"/sofastack.tech/projects/sofa-boot/classloader-isolation/","wordcount":1667},{"author":null,"categories":null,"content":" SOFABoot 动态模块实践 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n 实验背景 实验内容 任务 任务准备 将 SOFABoot 应用打包成 ark 包 修改动态模块名称 配置动态模块的打包插件 构建宿主应用 引入动态模块依赖 宿主应用配置 打包 \u0026amp;amp; 启动宿主应用 SOFADashboard 添加版本\u0026amp;amp;管理应用 查看详情 \u0026amp;amp; 推送安装命令 实验背景 kc-sofastack-demo 分享中已经通过 SOFAStack 快速构建了一个电商微服务应用， 并且完成了对应用服务调用链路的跟踪及应用状态的监控。\n在电商系统中，平台方往往不会满足商品的自然排序展示，必定会根据某种规则来将部分商品放置在列表最瞩目的地方， 当然也可能是平台方通过收集用户行为动态的为每个不同的用户推荐不同的商品展示列表。\n本实验背景就是基于kc-sofastack-demo的基础上， 根据现场同学对每个商品的购买总数（通过订单统计）来对商品列表进行动态排序。\n实验内容 通过 SOFABoot 提供的动态模块能力及 SOFADashboard 的动态模块管控能力，实现商品列表排序策略的动态变更。通过在不重启宿主机，不更改应用配置的情况下实现 应用行为的改变。\n 项目工程架构图如下 任务 1、任务准备 从 github 上将 demo 工程克隆到本地\ngit clone https://github.com/sofastack-guides/kc-sofastack-dynamic-demo.git 然后将工程导入到 IDEA 或者 eclipse。\n2、将 SOFABoot 应用打包成 ark 包 step1 : 修改动态模块名称 在实际的应用场景中，不需要对其进行任何修改\n 如下图所示，对 dynamic-module/pom.xml 中的 artifactId 进行修改，将 {your-number} 修改为当前座位上的编号\nstep2 : 配置动态模块的打包插件 在 dynamic-provider/pom.xml 中，增加 ark 打包插件，并进行配置：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;!--ark-biz 包的打包配置 --\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--是否打包、安装和发布 ark biz，详细参考 Ark Biz 文档，默认为false--\u0026amp;gt; \u0026amp;lt;attach\u0026amp;gt;true\u0026amp;lt;/attach\u0026amp;gt; \u0026amp;lt;!--ark 包和 ark biz 的打包存放目录，默认为工程 build 目录--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- ark-biz 包的启动优先级，值越小，优先级越高--\u0026amp;gt; \u0026amp;lt;priority\u0026amp;gt;200\u0026amp;lt;/priority\u0026amp;gt; \u0026amp;lt;!--设置应用的根目录，用于读取 ${base.dir}/conf/ark/bootstrap.application 配置文件，默认为 ${project.basedir}--\u0026amp;gt; \u0026amp;lt;baseDir\u0026amp;gt;../\u0026amp;lt;/baseDir\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 3、构建宿主应用 在已下载下来的工程中，dynamic-stock-mng 作为实验的宿主应用工程模型。通过此任务，将 dynamic-stock-mng 构建成为动态模块的宿主应用。\nstep1 : 引入动态模块依赖 动态模块是通过 SOFAArk 组件来实现的，因此次数需要引入 SOFAArk 相关的依赖即可。关于 SOFAArk 可以参考SOFABoot 类隔离 一节进行了解。\n SOFAArk 相关依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;web-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;config-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.sofastack\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dynamic-provider-{your-number}\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-biz\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 将此配置文件中的 {your-number} 替换为当前座位编号\n 宿主应用打包插件 \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;0.6.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; …","date":-62135596800,"description":"本指南将基于 SOFADashboard 的 ARK 管控能力来实现 SOFAArk 提供的合并部署和动态模块推送的功能。","dir":"guides/kc-sofastack-dynamic-demo/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8bfd4a50e21ce9fc867b1cf18a8c9af3","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-sofastack-dynamic-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/guides/kc-sofastack-dynamic-demo/","summary":"SOFABoot 动态模块实践 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 实验背景 实验内容 任务 任务准备 将 SOFABoot 应用打包成 ark 包 修改动态模","tags":null,"title":"SOFABoot 动态模块实践","type":"guides","url":"/sofastack.tech/guides/kc-sofastack-dynamic-demo/","wordcount":2025},{"author":null,"categories":null,"content":" SOFABoot 支持模块化隔离，在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项目，并在上面扩展，与 Spring 融合，提供扩展点的能力。\n使用 在 SOFABoot 中使用扩展点能力，需要以下三个步骤：\n定义提供扩展能力的 bean 在使用 SOFABoot 扩展点能力时，首先需要定一个需要被扩展的 bean，先定一个接口：\npackage com.alipay.sofa.boot.test; public interface IExtension { String say(); } 定义这个接口的实现：\npackage com.alipay.sofa.boot.test.impl; public class ExtensionImpl implements IExtension { private String word; @Override public String say() { return word; } public void setWord(String word) { this.word = word; } public void registerExtension(Extension extension) throws Exception { Object[] contributions = extension.getContributions(); String extensionPoint = extension.getExtensionPoint(); if (contributions == null) { return; } for (Object contribution : contributions) { if (\u0026amp;quot;word\u0026amp;quot;.equals(extensionPoint)) { setWord(((ExtensionDescriptor) contribution).getValue()); } } } } 在这里可以看到有一个方法：registerExtension ，暂时可以先不用管这个方法，后续会介绍其具体的作用。\n在模块的 Spring 配置文件中，我们把这个 bean 给配置起来：\n\u0026amp;lt;bean id=\u0026amp;quot;extension\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.test.impl.ExtensionImpl\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;word\u0026amp;quot; value=\u0026amp;quot;Hello, world\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; 定义扩展点 在上面的 bean 中有一个字段 word ，在实际中，我们希望这个字段能够被其他的模块自定义进行覆盖，这里我们将其以扩展点的形式暴露出来。\n首先需要一个类去描述这个扩展点：\n@XObject(\u0026amp;quot;word\u0026amp;quot;) public class ExtensionDescriptor { @XNode(\u0026amp;quot;value\u0026amp;quot;) private String value; public String getValue() { return value; } } 然后在 xml 中定义扩展点：\n\u0026amp;lt;sofa:extension-point name=\u0026amp;quot;word\u0026amp;quot; ref=\u0026amp;quot;extension\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:object class=\u0026amp;quot;com.alipay.sofa.boot.test.extension.ExtensionDescriptor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:extension-point\u0026amp;gt; 其中： - name 为扩展点的名字 - ref 为扩展点所作用在的 bean - object 为扩展点的贡献点具体的描述，这个描述是通过 XMap 的方式来进行的(XMap 的作用是将 Java 对象和 XML 文件进行映射，这里建议通过在网上搜索下 XMap 的文档来了解 XMap)\n定义扩展 上述已经将扩展点定义好了，此时我们就可以对这个 bean 进行扩展了:\n\u0026amp;lt;sofa:extension bean=\u0026amp;quot;extension\u0026amp;quot; point=\u0026amp;quot;word\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:content\u0026amp;gt; \u0026amp;lt;word\u0026amp;gt; \u0026amp;lt;value\u0026amp;gt;newValue\u0026amp;lt;/value\u0026amp;gt; \u0026amp;lt;/word\u0026amp;gt; \u0026amp;lt;/sofa:content\u0026amp;gt; \u0026amp;lt;/sofa:extension\u0026amp;gt; 其中： - bean 为扩展所作用在的 bean - point 为扩展点的名字 - content 里面的内容为扩展的定义，其会通过 XMap 将内容解析为：扩展点的贡献点具体的描述对象，在这里即为 com.alipay.sofa.boot.test.extension.ExtensionDescriptor 对象\n到这里，我们可以回头看一开始在 com.alipay.sofa.boot.test.impl.ExtensionImpl 中定义的 registerExtension 方法了，SOFABoot 在解析到贡献点时，会调用被扩展 bean 的 registerExtension 方法，其中包含了用户定义的贡献点处理逻辑，在上述的例子中，获取用户定义的 value 值，并将其设置到 word 字段中覆盖 bean 中原始定义的值。\n此时，调用 extension bean 的 say() 方法，可以看到返回扩展中定义的值: newValue 。\nXMap 支持和扩展 上述的例子中只是一个很简单的扩展，其实 XMap 包含了非常丰富的描述能力，包括 List, Map 等，这些可以通过查看 XMap 的文档来了解。\n在 SOFABoot 中，除了 XMap 原生的支持以外，还扩展了跟 Spring 集成的能力： - 通过 XNode 扩展出了 XNodeSpring - 通过 XNodeList 扩展出了 XNodeListSpring - 通过 XNodeMap 扩展出了 XNodeMapSpring\n这部分的扩展能力，让扩展点的能力更加丰富，描述对象中可以直接指向一个 SpringBean(用户配置 bean 的名字，SOFABoot 会根据名字从 spring 上下文中获取到 bean)，这里举一个使用 XNodeListSpring 的例子，依然是上述描述的三个步骤：\n定义提供扩展能力的 bean 接口定义：\n在这个接口里，返回一个 list，目标是这个 list 能够被通过扩展的方式填充\npackage com.alipay.sofa.boot.test; public interface IExtension { …","date":-62135596800,"description":"","dir":"projects/sofa-boot/extension/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"93225b6c1f2b68f2047a7cf49b76650b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/extension/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-boot/extension/","summary":"SOFABoot 支持模块化隔离，在实际的使用场景中，一个模块中的 bean 有时候需要开放一些入口，供另外一个模块扩展。SOFABoot 借鉴和使用了 Nuxeo Runtime 项目 以及 nuxeo 项","tags":null,"title":"SOFABoot 拓展点","type":"projects","url":"/sofastack.tech/projects/sofa-boot/extension/","wordcount":1959},{"author":null,"categories":null,"content":" 本文档将演示了如何在 SOFABoot 环境下应用 SOFARPC 进行服务的发布和引用。 您可以直接在工程下找到本文档的示例代码。注意，示例代码中需要本地安装 zookeeper 环境，如果没有安装。需要将application.properties中的com.alipay.sofa.rpc.registry.address 配置注释掉，走本地文件注册中心的方式。\n创建工程 环境准备：SOFABoot 需要 JDK7 或者 JDK8 ，需要采用 Apache Maven 2.2.5 或者以上的版本来编译。 工程构建：SOFABoot 构建在 Spring Boot 之上。因此可以使用 Spring\u0026amp;nbsp;Boot\u0026amp;nbsp;的工程生成工具来生成一个标准的Spring Boot 工程。 引入 SOFABoot 环境：生成的 Spring Boot 标准工程直接使用的 Spring Boot 的 parent 依赖，改为 SOFABoot 提供的 parent 依赖，该parent 提供并管控了多种 SOFABoot 提供的 starter。 \u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa-boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa-boot.version} 指定具体的 SOFABoot 版本，参考发布历史。\n 配置 application.properties ：application.properties 是 SOFABoot 工程中的配置文件。这里需要配置一个必不可少的配置项，即应用名。 spring.application.name=AppName 引入 RPC Starter： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 定义服务接口 public interface AnnotationService { String sayAnnotation(String string); } 服务端发布服务 通过 @SofaService注解发布服务，如下代码所示：\nSOFABoot 扫描到该注解，就会将该服务实现发布到服务器，同时指定了 bolt 协议与客户端进行通信地址，并将地址等元数据发布到了注册中心（这里默认使用的本地文件作为注册中心）。\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } 客户端引用服务 通过@SofaReference注解引用服务，如下代码所示： SOFABoot 会生成一个 AnnotationService RPC 的代理 bean，同时指定了 bolt 协议与服务端通信。这样就可以直接在代码中使用该 bean 进行远程服务的调用了。\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } 运行 在 SpringBoot 的启动类中编码如下： 启动服务端\n@SpringBootApplication public class AnnotationServerApplication { public static void main(String[] args) { SpringApplication springApplication = new SpringApplication( AnnotationServerApplication.class); ApplicationContext applicationContext = springApplication.run(args); } } 启动客户端，获取AnnotationClientImpl的实现 bean，并调用 sayClientAnnotation，间接通过@SofaReference生成的代理类调用远程服务 AnnotationServiceImpl。\npublic class …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-sofa-boot/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0dd5e0e5116473aee630cba38679d493","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","summary":"本文档将演示了如何在 SOFABoot 环境下应用 SOFARPC 进行服务的发布和引用。 您可以直接在工程下找到本文档的示例代码。注意，示例代码中需要本地安装 zookeeper 环境，如果没有","tags":null,"title":"SOFABoot 方式快速入门","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/","wordcount":990},{"author":null,"categories":null,"content":"声明 SOFABoot 的 xsd 文件：在要使用的 XML 配置文件中将头部 xsd 文件的声明设置为如下。这样就能够使用 SOFABoot 定义的 XML 元素进行开发。\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xmlns:context=\u0026amp;quot;http://www.springframework.org/schema/context\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; 在xml方式中发布和引用服务的方式如下。 sofa:service 元素表示发布服务， sofa:reference 元素表示引用服务。 sofa:binding 表示服务发布或引用的协议。\n\u0026amp;lt;bean id=\u0026amp;quot;personServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 一个服务也可以通过多种协议进行发布，如下：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 服务引用\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 也可以是其他的协议\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceRest\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-xml/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9192a93415bee3070a9be62c0f693949","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","summary":"声明 SOFABoot 的 xsd 文件：在要使用的 XML 配置文件中将头部 xsd 文件的声明设置为如下。这样就能够使用 SOFABoot 定义的 XML 元素进行开发。 \u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;beans xmlns=\u0026quot;http://www.springframework.org/schema/beans\u0026quot; xmlns:xsi=\u0026quot;http://www.w3.org/2001/XMLSchema-instance\u0026quot; xmlns:sofa=\u0026quot;http://sofastack.io/schema/sofaboot\u0026quot; xmlns:context=\u0026quot;http://www.springframework.org/schema/context\u0026quot; xsi:schemaLocation=\u0026quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026quot; default-autowire=\u0026quot;byName\u0026quot;\u0026gt; 在xml","tags":null,"title":"SOFABoot 环境 XML 配置使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/","wordcount":179},{"author":null,"categories":null,"content":"SOFABoot 为 RPC 服务的发布和引用提供了一套编程 API 方式，方便直接在代码中发布和引用 RPC 服务，与 Spring 的 ApplicationContextAware 类似，为使用编程 API 方式，首先需要实现 ClientFactoryAware 接口获取编程组件 API：\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } 以 DirectService 为例，看下如何使用 clientFactory 通过编程 API 方式发布 RPC 服务：\nServiceClient serviceClient = clientFactory.getClient(ServiceClient.class); ServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(DirectService.class); serviceParam.setInstance(new DirectServiceImpl()); List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); serviceClient.service(serviceParam); 上面的代码中\n 首先通过 clientFactory 获得 ServiceClient 对象 然后构造 ServiceParam 对象，ServiceParam 对象包含发布服务所需参数，通过 setInstance 方法来设置需要被发布成 RPC 服务的对象，setInterfaceType 来设置服务的接口 最后，调用 ServiceClient 的 service 方法，发布一个 RPC 服务 通过编程 API 方式引用 RPC 服务的代码也是类似的：\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt;(); referenceParam.setInterfaceType(DirectService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); DirectService proxy = referenceClient.reference(referenceParam); proxy.sayDirect(\u0026amp;quot;hello\u0026amp;quot;); 同样，引用一个 RPC 服务只需从 ClientFactory 中获取一个 ReferenceClient ，然后和发布一个服务类似，构造出一个 ReferenceParam，然后设置好服务的接口，最后调用 ReferenceClient 的 reference 方法即可。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-api/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2679388dc3459714f869d8f8a71739d7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","summary":"SOFABoot 为 RPC 服务的发布和引用提供了一套编程 API 方式，方便直接在代码中发布和引用 RPC 服务，与 Spring 的 ApplicationContextAware 类似，为使用编程 API 方式，首先需要实现 ClientFactoryAware 接口获取编程组件","tags":null,"title":"SOFABoot 环境动态 API 使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/","wordcount":374},{"author":null,"categories":null,"content":" 这部分介绍在 SOFABoot 环境下,完整的 SOFARPC 服务发布与引用说明\n发布服务 \u0026amp;lt;bean id=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; thread-pool-ref=\u0026amp;quot;\u0026amp;quot; warm-up-time=\u0026amp;quot;60000\u0026amp;quot; warm-up-weight=\u0026amp;quot;10\u0026amp;quot; weight=\u0026amp;quot;100\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 属性 名称 默认值 备注 id ID bean名 class 类 无 ref 服务接口实现类 interface 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 unique-id 服务标签（唯一标识元素） filter 过滤器配置别名 多个用逗号隔开 registry 服务端注册中心 逗号分隔 timeout 服务端执行超时时间 serialize-type 序列化协议 hessian2,protobuf thread-pool-ref 服务端当前接口使用的线程池 无 weight 服务静态权重 warm-up-weight 服务预热权重 warm-up-time 服务预热时间 单位毫秒 引用服务 \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;helloSyncServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;sync\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; address-wait-time=\u0026amp;quot;1000\u0026amp;quot; connect.num=\u0026amp;quot;1\u0026amp;quot; check=\u0026amp;quot;false\u0026amp;quot; connect.timeout=\u0026amp;quot;1000\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; generic-interface=\u0026amp;quot;\u0026amp;quot; idle.timeout=\u0026amp;quot;1000\u0026amp;quot; idle.timeout.read=\u0026amp;quot;1000\u0026amp;quot; lazy=\u0026amp;quot;false\u0026amp;quot; loadBalancer=\u0026amp;quot;\u0026amp;quot; registry=\u0026amp;quot;\u0026amp;quot; retries=\u0026amp;quot;1\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;xxx:12200\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; type=\u0026amp;quot;sync\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 属性 名称 默认值 备注 id ID 自动生成 jvm-first 是否优先本地 true interface 服务接口（唯一标识元素） 不管是普通调用和返回调用，这里都设置实际的接口类 unique-id 服务标签（唯一标识元素） type 调用方式 sync callback,sync,future,oneway filter 过滤器配置别名 List registry 服务端注册中心 List method 方法级配置 说明同上 serialize-type 序列化协议 hessian2 target-url 直连地址 直连后register generic-interface 泛化接口 connect.timeout 建立连接超时时间 3000(cover 5000) connect.num 连接数 1 idle.timeout 空闲超时时间 idle.timeout.read 读空闲超时时间 loadBalancer 负载均衡算法 random lazy 是否延迟建立长连接 false address-wait-time 等待地址获取时间 -1 取决于实现，可能不生效。 timeout 调用超时时间 3000(cover 5000) retries 失败后重试次数 0 跟集群模式有关，failover读取此参数。 callback-class callback 回调类 无 callback 才可用 callback-ref callback 回调类 无 callback 才可用 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/rpc-config-xml-explain/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4b5110e9eb6cf6c6f287aef0fd210047","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","summary":"这部分介绍在 SOFABoot 环境下,完整的 SOFARPC 服务发布与引用说明 发布服务 \u0026lt;bean id=\u0026quot;helloSyncServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;helloSyncServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026quot; unique-id=\u0026quot;\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs registry=\u0026quot;\u0026quot; serialize-type=\u0026quot;\u0026quot; filter=\u0026quot;\u0026quot; timeout=\u0026quot;3000\u0026quot; thread-pool-ref=\u0026quot;\u0026quot; warm-up-time=\u0026quot;60000\u0026quot; warm-up-weight=\u0026quot;10\u0026quot; weight=\u0026quot;100\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;sofa:binding.rest\u0026gt; \u0026lt;/sofa:binding.rest\u0026gt; \u0026lt;/sofa:service\u0026gt; 属性 名称 默认值 备注 id ID bean名 class 类 无 ref 服","tags":null,"title":"SOFABoot 环境发布订阅说明","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/","wordcount":518},{"author":null,"categories":null,"content":" 注解服务发布与服务引用 除了常规的 xml 方式发布服务外，我们也支持在SOFABoot 环境下，注解方式的发布与引用，同 xml 类似，我们有 @SofaService 和 @SofaReference，同时对于多协议，存在@SofaServiceBinding 和 @SofaReferenceBinding 注解。\n服务发布 如果要发布一个 RPC 服务。我们只需要在 Bean 上面打上@SofaService注解。指定接口和协议类型即可。\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } 服务引用 对于需要引用远程服务的 bean, 只需要在属性，或者方法上，打上@SofaReference的注解即可，支持 bolt, dubbo, rest 协议。\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } 使用演示 可以在 sample 工程目录的 annotation 子项目中进行验证测试。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-annotation/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2c3afd33cbce4f5aa2473716b3afe5a6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","summary":"注解服务发布与服务引用 除了常规的 xml 方式发布服务外，我们也支持在SOFABoot 环境下，注解方式的发布与引用，同 xml 类似，我们有 @SofaService 和 @SofaR","tags":null,"title":"SOFABoot 环境注解使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/","wordcount":317},{"author":null,"categories":null,"content":" SOFADashboard is designed to implement unified management over SOFA framework components, including service governance and SOFAArk control. All technology stacks used by SOFADashboard are developed and constructed based on open-source community products, such as Ant Design Pro, SOFABoot, Spring, and MyBatis.\nCurrently, service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper. Therefore, you need to ensure the ZooKeeper service is available when you decide to use SOFADashboard. You also need to ensure that MySQL is available, because SOFAArk control and deployment uses MySQL for resource data storage.\nArchitecture Currently, service governance and SOFAArk control of SOFADashboard are implemented upon ZooKeeper-based programming.\n SOFADashboard backend corresponds to the sofa-dashboard-backend project. It is the server end project of SOFADashboard, responsible for data interaction between ZooKeeper and MySQL and for providing the rest API to the SOFADashboard frontend. SOFADashboard frontend corresponds to the sofa-dashboard-frontend project. It is the frontend project of SOFADashboard. It provides UIs for interaction with users. Application rpc provider: service provider of SOFARPC, which registers services with ZooKeeper. rpc consumer: service consumer of SOFARPC, which subscribes to services on ZooKeeper. client: SOFADashboard client, which is available upon the installation of the sofa-dashboard-client package. Currently, the SOFADashboard client only supports registration of health-check status and port information of applications with ZooKeeper. Later on, it will evolve into SOFABoot client, and report more diversified application data. ark-biz host app: see SOFAArk. ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f0664d0ca7fc1fa87e67847525081993","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/overview/","summary":"SOFADashboard is designed to implement unified management over SOFA framework components, including service governance and SOFAArk control. All technology stacks used by SOFADashboard are developed and constructed based on open-source community products, such as Ant Design Pro, SOFABoot, Spring, and MyBatis.\nCurrently, service governance and SOFAArk control of SOFADashboard are dependent on ZooKeeper. Therefore, you need to ensure the ZooKeeper service is available when you decide to use SOFADashboard. You also need to ensure that MySQL is available, because SOFAArk control and deployment uses MySQL for resource data storage.","tags":null,"title":"SOFADashboard overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/overview/","wordcount":230},{"author":null,"categories":null,"content":" SOFADashboard 致力于对 SOFA 框架中组件进行统一管理，包括服务治理、SOFAArk 管控等。SOFADashboard 本身所用技术栈均基于开源社区产品来开发构建，包括：Ant Design Pro、SOFABoot、Spring、MyBatis 等。\n目前，SOFADashboard 中的服务治理、SOFAArk 管控等需要依赖于 Zookeeper，因此如果您需要使用 SOFADashboard 那么请确保 Zookeeper 服务可用；另外 SOFAArk 管控部署需要依赖 MySQL 进行资源数据存储，因此也需要保证 MySQL 可以正常使用。\n架构简图 SOFADashboard 目前服务治理与 SOFAArk 管控都是面向 Zookeeper 来编程实现的。\n SOFADashboard backend : 对应 sofa-dashboard-backend 工程，是 SOFADashboard 的服务端工程，负责与 Zookeeper 和 MySQL 进行数据交互，并且为 SOFADashboard frontend 提供 rest 接口。 SOFADashboard frontend : 对应 sofa-dashboard-frontend 工程，是 SOFADashboard 的前端工程，用于提供与用户交互的 UI 界面。 app 应用 rpc provider : SOFARPC 的服务提供方，会将服务注册到 Zookeeper 上。 rpc consumer : SOFARPC 的服务消费方，会从 Zookeeper 上订阅服务。 client : SOFADashboard 客户端，引入 sofa-dashboard-client 包即可。目前仅提供将应用的健康检查状态及端口信息注册到 Zookeeper ，后面将会演化成 SOFABoot client，上报更丰富的应用数据。 ark-biz 宿主应用: 参考 SOFAArk 。 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f0664d0ca7fc1fa87e67847525081993","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/overview/","summary":"SOFADashboard 致力于对 SOFA 框架中组件进行统一管理，包括服务治理、SOFAArk 管控等。SOFADashboard 本身所用技术栈均基于开源社区产品来开发构建","tags":null,"title":"SOFADashboard 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/overview/","wordcount":431},{"author":null,"categories":null,"content":" This topic is a part of the Braft document. To read the Braft document, click here. The Raft algorithm and its application are comprehensively described in the Braft document. As JRaft is designed on the basis of Braft, we strongly recommend that you read the Braft document first to understand the basic principles and application of the Raft algorithm.\nDistributed consensus Distributed consensus is a very fundamental problem in a distributed system. Simply put, it is about how to reach a consensus on a specific value among multiple servers, and ensure that the decision is not overthrown regardless of what failures may occur on these servers. Assume that, all processes of a distributed system needs to determine a value V. If the system has the following properties, we consider it solves the problem of distributed consensus:\n Termination: All normal processes will determine the specific value of V, and there is no process that keeps running in a loop. Validity: A value V\u0026amp;rsquo; determined by normal processes must have been proposed by one of them. For example, a random number generator does not have this property. Agreement: All normal processes choose the same value. Consensus state machine Assume we have an infinitely incrementing sequence (system) a[1, 2, 3…]. If for any integer i, the value of a[i] meets the distributed consensus requirement, the system meets the requirement of a consensus state machine. Basically, all systems are subject to continuous operations, and reaching consensus on a single value is definitely not enough. To make sure all replicas of a real-life system are consistent, we usually convert the operations into entries of a write-ahead-log(WAL). Then, we make sure all replicas of the system reach a consensus on the WAL entries, so that each process will perform operations corresponding to the WAL entries in order. As a result, the replicas are in consistent states.\nRAFT RAFT is a new and easy-to-understand distributed consensus replication protocol proposed by Diego Ongaro and John Ousterhout of Stanford University as a central coordination component of the RAMCloudproject. Raft is a leader-based multi-Paxos variant that provides a more complete and straightforward protocol description than existing protocols such as Paxos, Zab, and Viewstamped Replication. It also provides a clear description for adding and deleting nodes. In Raft, replicated state machines are the most important and fundamental to distributed systems. Raft allows commands to be replicated and executed in order, and ensures that the states of nodes remain consistent when their initial states are the same. A system is fully functional (available) as long as a majority of nodes function properly. It allows non-Byzantine conditions, including network delays, packet loss, and reordering, but does not allow tampering with any messages.\nRaft can solve the distributed consensus and partitioning problems, but cannot solve the availability problem. Raft covers …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/overview/","fuzzywordcount":700,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"eff7088d010aefabdffa2858e88d76c0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/overview/","summary":"This topic is a part of the Braft document. To read the Braft document, click here. The Raft algorithm and its application are comprehensively described in the Braft document. As JRaft is designed on the basis of Braft, we strongly recommend that you read the Braft document first to understand the basic principles and application of the Raft algorithm.\nDistributed consensus Distributed consensus is a very fundamental problem in a distributed system.","tags":null,"title":"SOFAJRaft overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/overview/","wordcount":645},{"author":null,"categories":null,"content":" 本介绍内容来自 braft 文档，原文链接请参见这里。braft 的关于算法和应用本身的文档非常优秀，由于 jraft 脱胎自 braft，我们强烈推荐阅读上述文档以了解 raft 算法的基本原理和应用。\n分布式一致性 分布式一致性 (distributed consensus) 是分布式系统中最基本的问题，用来保证一个分布式系统的可靠性以及容灾能力。简单的来讲，就是如何在多个机器间对某一个值达成一致, 并且当达成一致之后，无论之后这些机器间发生怎样的故障，这个值能保持不变。 抽象定义上， 一个分布式系统里的所有进程要确定一个值 v，如果这个系统满足如下几个性质， 就可以认为它解决了分布式一致性问题, 分别是:\n Termination: 所有正常的进程都会决定 v 具体的值，不会出现一直在循环的进程。 Validity: 任何正常的进程确定的值 v\u0026amp;rsquo;, 那么 v\u0026amp;rsquo; 肯定是某个进程提交的。比如随机数生成器就不满足这个性质。 Agreement: 所有正常的进程选择的值都是一样的。 一致性状态机 对于一个无限增长的序列 a[1, 2, 3…], 如果对于任意整数 i, a[i] 的值满足分布式一致性，这个系统就满足一致性状态机的要求。 基本上所有的系统都会有源源不断的操作, 这时候单独对某个特定的值达成一致是不够的。为了真实系统保证所有的副本的一致性，通常会把操作转化为 write-ahead-log(简称WAL)。然后让系统的所有副本对WAL保持一致，这样每个进程按照顺序执行WAL里的操作，就能保证最终的状态是一致的。\nRAFT RAFT 是一种新型易于理解的分布式一致性复制协议，由斯坦福大学的 Diego Ongaro 和 John Ousterhout 提出，作为 RAMCloud 项目中的中心协调组件。Raft 是一种 Leader-Based 的 Multi-Paxos 变种，相比 Paxos、Zab、View Stamped Replication 等协议提供了更完整更清晰的协议描述，并提供了清晰的节点增删描述。 Raft 作为复制状态机，是分布式系统中最核心最基础的组件，提供命令在多个节点之间有序复制和执行，当多个节点初始状态一致的时候，保证节点之间状态一致。系统只要多数节点存活就可以正常处理，它允许消息的延迟、丢弃和乱序，但是不允许消息的篡改（非拜占庭场景）。\nRaft 可以解决分布式理论中的 CP，即一致性和分区容忍性，并不能解决 Available 的问题。其中包含分布式系统中一些通常的功能：\n Leader Election Log Replication Membership Change Log Compaction RAFT 可以做什么 通过 RAFT 提供的一致性状态机，可以解决复制、修复、节点管理等问题，极大的简化当前分布式系统的设计与实现，让开发者只关注于业务逻辑，将其抽象实现成对应的状态机即可。基于这套框架，可以构建很多分布式应用：\n 分布式锁服务，比如 Zookeeper 分布式存储系统，比如分布式消息队列、分布式块系统、分布式文件系统、分布式表格系统等 高可靠元信息管理，比如各类 Master 模块的 HA JRAFT 一个纯 Java 的 Raft 算法实现库, 基于百度 braft 实现而来, 使用 Java 重写了所有功能, 支持:\n Leader election and priority-based semi-deterministic leader election. Replication and recovery. Snapshot and log compaction. Read-only member (learner). Membership management. Fully concurrent replication. Fault tolerance. Asymmetric network partition tolerance. Workaround when quorate peers are dead. Replication pipeline optimistic Linearizable read, ReadIndex/LeaseRead. 联系我们 更多讨论欢迎加入钉钉讨论群：44858463\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/overview/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"eff7088d010aefabdffa2858e88d76c0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-jraft/overview/","summary":"本介绍内容来自 braft 文档，原文链接请参见这里。braft 的关于算法和应用本身的文档非常优秀，由于 jraft 脱胎自 braft，我们强烈推荐阅读上述文档以了","tags":null,"title":"SOFAJRaft 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/overview/","wordcount":1132},{"author":null,"categories":null,"content":" SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。\n1.客户端部分 SOFALookout Client 是一个 Java 的 SDK，可以帮助开发者在项目代码中进行 metrics 埋点。通过它也可以查看该 JAVA 应用的实时的状态信息。\n +------------------+ Reg: API: | dimension meters +--------+ +------------------+ | flatmap +---------------------------+ +-----------\u0026amp;gt; | Default/DropwizardMetrics| | +---------------------------+ | | http +--------------+ +-----------\u0026amp;gt; |Lookout server| | +--------------+ +----------------------+ | add common tags dimension EXTS: | JVM,OS,GC... +----+ +----------------------+ 2.服务器端服务 SOFALookout Server 可以帮助我们解决分布式环境下系统状态度量的问题，它提供丰富的协议接入支持，包括自有SDK（SOFALookout Client）上报协议，还支持 Prometheus 的数据协议（推模式和拉模式），Metricbeat 协议（版本是6），Opentsdb写入协议。 Lookout Server 兼容和增强了 Prometheus 的数据及元数据查询的 RESTful API。同样对应 PromQL 我们也基本实现了兼容和增强（不包括 Alert 相关语法）。\n2.1.Metrics 服务器端主要特性: 适配社区主要 Metrics 数据源协议写入（比如: Prometheus，Metricbeat等）； 数据的存储支持扩展，暂时开源版默认支持 Elasticsearch,并且透明和自动化了相关运维操作； 遵循 Prometheus 查询 API 的标准以及支持 PromQL，并进行了适当改进； 自带数据查询的控制台，并支持 Grafana 进行数据可视化； 使用简单，支持单一进程运行整个服务器端模块。 2.2.Metrics 服务器端工作机制: +----------------+ | Lookout Client +-----+ +----------------+ | +----------------+ | | Prometheus SDK +-----+ +-------------------+ +----------------------+ +------------------+ +-----------+ +----------------+ +--\u0026amp;gt; Lookout Gateway +---\u0026amp;gt; DB(ES/InfluxDB...) \u0026amp;lt;-----+ Lookout Server \u0026amp;lt;----+ Grafana | +----------------+ | +-------------------+ +----------------------+ +------------------+ +-----------+ | Metricbeat +-----+ +----------------+ | +----------------+ | | ... +-----+ +----------------+ ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/overview/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8a8a8ef02ca95d4d11e3e4b195bbae70","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/overview/","summary":"SOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项","tags":null,"title":"SOFALookout 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/overview/","wordcount":602},{"author":null,"categories":null,"content":" 1.使用本机 ES 服务 1)本地启动 ES docker run -d --name es -p 9200:9200 -p 9300:9300 -e \u0026amp;quot;discovery.type=single-node\u0026amp;quot; elasticsearch:5.6 版本：V5，V6\n 2)检查 ES 是否健康 http://localhost:9200/_cat/health?v 3)启动 Lookout 服务 执行 all-in-one-bootstrap 编译后的 fat-jar 包，如何获得，见文末备注部分：\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -jar lookout-all-in-one-bootstrap-1.6.0-executable-ark.jar 注意 -Dcom.alipay.sofa.ark.master.biz=lookoutall 是必须的, 用于设置 sofa-ark 的 master biz。\n 4)最后进行功能验证\n 查询 （Gateway）的 metrics 作为功能验证，访问“localhost:9090”，在查询框输入：\njvm.memory.heap.used{app=\u0026amp;quot;gateway\u0026amp;quot;} 最后，也可以使用 grafana\n2.使用远程 ES 服务 总体步骤和“使用本机 ES 服务”类似，唯一不同的是，需要指定配置文件。\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -Dlookoutall.config-file=abc.properties \\ -jar lookout-all-in-one-bootstrap-1.6.0-executable-ark.jar -Dlookoutall.config-file（如果你本地启动 ES 测试的话则该配置项可以忽略！），该配置项制定的文件暂时只能引用文件系统上的 properties 文件(没有像 spring-boot 支持那么丰富），配置项必须以应用名开头，从而提供隔离能力。\n例如：在fat-jar同目录下创建一个abc.properties配置文件, 用于存放存放配置文件(下面列出了必须的配置项,用于指向使用的 ES 服务地址）：\ngateway.metrics.exporter.es.host=localhost gateway.metrics.exporter.es.port=9200 metrics-server.spring.data.jest.uri=http://localhost:9200 备注 如何获得 all-in-one-bootstrap 编译后的 fat-jar。\n方式1：本地编译\n./boot/all-in-one-bootstrap/build.sh 打包结果在boot/all-in-one-bootstrap/target/allinone-executable.jar\n 方式2：发布报告中附件获取\n临时方式（针对 1.6.0）暂时提供一个 v1.6.0的snapshot包，下载后（保证ES服务已经单独启动）运行：\njava -Dcom.alipay.sofa.ark.master.biz=lookoutall -jar lookout-all-1.6.0.snapshot.jar 方式3：使用docker镜像\n服务端默认会连接到 localhost:9200 的ES实例, 而我所用的开发机器是MacOS，无法使用 --net=host 模式启动容器，因此在容器内无法通过 localhost:9200 连接ES，需要使用如下方式绕过去：\n编辑一个配置文件，比如 foo.properties：\ngateway.metrics.exporter.es.host=es metrics-server.spring.data.jest.uri=http://es:9200 在 foo.properties 所在的目录下运行 all-in-one 镜像：\ndocker run -it \\ --name allinone \\ --link es:es \\ -p 7200:7200 \\ -p 9090:9090 \\ -v $PWD/foo.properties:/home/admin/deploy/foo.properties \\ -e JAVA_OPTS=\u0026amp;quot;-Dlookoutall.config-file=/home/admin/deploy/foo.properties\u0026amp;quot; \\ -e JAVA_OPTS=\u0026amp;quot;...定制JVM系统属性...\u0026amp;quot; \\ xzchaoo/lookout-allinone:1.6.0-SNAPSHOT 这里利用了docker的\u0026amp;ndash;link参数使得应用可以访问到ES实例 这里做测试用，所以不用-d参数在后台运行\n ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-metrics-server/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7c12565c66342c2f8e963cf1c1e26db5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","summary":"1.使用本机 ES 服务 1)本地启动 ES docker run -d --name es -p 9200:9200 -p 9300:9300 -e \u0026quot;discovery.type=single-node\u0026quot; elasticsearch:5.6 版本：V5，V6 2)检查 ES 是否健康 http://localhost:9200/_cat/health?v 3)启动 Lookout 服务 执行 all-in-one-bootstrap 编译后的 fat-jar 包，如何获得，见文","tags":null,"title":"SOFALookout 服务端快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/","wordcount":808},{"author":null,"categories":null,"content":" This repository is deprecated. It will contribute to istio directly instead of developing in a forked repo. Please go to see Istio’s doc.\nSOFAMesh is a large-scale implementation scheme of Service Mesh based on Istio. On the basis of inheriting the powerful functions and rich features of Istio, in order to meet the performance requirements in large-scale deployments and to respond to the actual situation in the implementation, the following improvements are made:\n MOSN written in Golang instead of Envoy Merge Mixer to data plane to resolve performance bottlenecks Enhance Pilot for more flexible service discovery mechanism Added support for SOFA RPC, Dubbo The initial version was contributed by Ant Financial and Alibaba UC Business Unit.\nThe following figure shows the architectural differences between SOFAMesh and Istio:\nMain components MOSN In SOFAMesh, the data pane adopts Golang to write a module called MOSN (Modular Open Smart Network), and replaces Envoy with MOSN to integrate with Istio to implement the functions of Sidecar. MOSN is fully compatible with Envoy\u0026amp;rsquo;s APIs.\nSOFAMesh Pilot SOFAMesh greatly expands and enhances the Pilot module in Istio:\n Add an Adapter for SOFA Registry to provide solutions for super large-scale service registration and discovery; Add data synchronization modules to enable data exchange between multiple service registry centers; Add Open Service Registry API to provide standardized service registration. Together with Pilot and MOSN, SOFAMesh provides the ability to enable traditional intrusive frameworks (such as Spring Cloud, Dubbo and SOFARPC) and Service Mesh products to communicate with each other, thus it can smoothly evolve and transit to Service Mesh.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/overview/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e44a7cb73f7b68217663bd75655f43d7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/overview/","summary":"This repository is deprecated. It will contribute to istio directly instead of developing in a forked repo. Please go to see Istio’s doc.\nSOFAMesh is a large-scale implementation scheme of Service Mesh based on Istio. On the basis of inheriting the powerful functions and rich features of Istio, in order to meet the performance requirements in large-scale deployments and to respond to the actual situation in the implementation, the following improvements are made:","tags":null,"title":"SOFAMesh overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/overview/","wordcount":260},{"author":null,"categories":null,"content":" 该项目仓库已弃用。该项目将直接向 Istio 贡献，不会继续在 fork 的仓库中开发，请转至 Istio 官网。\nSOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强大功能和丰富特性的基础上，为满足大规模部署下的性能要求以及应对落地实践中的实际情况，有如下改进：\n 采用 Golang 编写的 MOSN 取代 Envoy 合并 Mixer 到数据平面以解决性能瓶颈 增强 Pilot 以实现更灵活的服务发现机制 增加对 SOFA RPC、Dubbo 的支持 初始版本由蚂蚁金服和阿里大文娱UC事业部携手贡献。\n下图展示了SOFAMesh 和 Istio 在架构上的不同：\n主要组件 MOSN 在 SOFAMesh 中，数据面我们采用 Golang 语言编写了名为 MOSN（Modular Open Smart Network）的模块来替代 Envoy 与 Istio 集成以实现 Sidecar 的功能，同时 MOSN 完全兼容 Envoy 的 API。\nSOFA Pilot SOFAMesh 中大幅扩展和增强 Istio 中的 Pilot 模块：\n 增加 SOFA Registry 的 Adapter，提供超大规模服务注册和发现的解决方案 增加数据同步模块，以实现多个服务注册中心之间的数据交换 增加 Open Service Registry API，提供标准化的服务注册功能 MOSN 和 Pilot 配合，将可以提供让传统侵入式框架（如 Spring Cloud、Dubbo、SOFARPC 等）和 Service Mesh 产品可以相互通讯的功能，以便可以平滑的向 Service Mesh 产品演进和过渡。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e44a7cb73f7b68217663bd75655f43d7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/overview/","summary":"该项目仓库已弃用。该项目将直接向 Istio 贡献，不会继续在 fork 的仓库中开发，请转至 Istio 官网。 SOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。在继承 Istio 强","tags":null,"title":"SOFAMesh 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/overview/","wordcount":474},{"author":null,"categories":null,"content":" SOFARPC Metrics SOFARPC currently measures two metrics.\nServer thread pool metric name metric tags specification rpc.bolt.threadpool.config bolt thread pool configuration Mainly includes thread pool configuration information for RPC server rpc.bolt.threadpool.active.count Running thread of the current thread pool rpc.bolt.threadpool.idle.count Idle thread of the current thread pool rpc.bolt.threadpool.queue.size Tasks in the queue of the current thread pool Client call information metric name metric tags specification rpc.consumer.service.stats.fail_count.count app,service,method,protocol,invoke_type,target_app Failure count of a certain interface rpc.consumer.service.stats.fail_count.rate app,service,method,protocol,invoke_type,target_app Number of failures per second of a certain interface rpc.consumer.service.stats.fail_time.elapPerExec app,service,method,protocol,invoke_type,target_app Average time per failed execution of a certain interface rpc.consumer.service.stats.fail_time.max app,service,method,protocol,invoke_type,target_app Maximum failure time of a certain interface rpc.consumer.service.stats.fail_time.totalTime app,service,method,protocol,invoke_type,target_app Total failure time of a certain interface rpc.consumer.service.stats.request_size.max app,service,method,protocol,invoke_type,target_app Maximum request size of a certain interface rpc.consumer.service.stats.request_size.rate app,service,method,protocol,invoke_type,target_app Average request size per second of a certain interface rpc.consumer.service.stats.request_size.totalAmount app,service,method,protocol,invoke_type,target_app Total request amount of a certain interface rpc.consumer.service.stats.response_size.max app,service,method,protocol,invoke_type,target_app Maximum response size of a certain interface rpc.consumer.service.stats.response_size.rate app,service,method,protocol,invoke_type,target_app Average response size per second of a certain interface rpc.consumer.service.stats.response_size.totalAmount app,service,method,protocol,invoke_type,target_app Total response amount of a certain interface rpc.consumer.service.stats.total_count.count app,service,method,protocol,invoke_type,target_app Total number of calls of a certain interface rpc.consumer.service.stats.total_count.count_service_sum_30000 app,service,method,protocol,invoke_type,target_app Total call information of a certain interface rpc.consumer.service.stats.total_count.rate app,service,method,protocol,invoke_type,target_app Number of calls per second of a certain interface rpc.consumer.service.stats.total_time.elapPerExec app,service,method,protocol,invoke_type,target_app Average time per execution of a certain interface rpc.consumer.service.stats.total_time.max app,service,method,protocol,invoke_type,target_app Maximum total time of a certain interface rpc.consumer.service.stats.total_time.totalTime …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/sofarpc-metrics/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1f444349855508f4b111d8f2d2b5e43d","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","summary":"SOFARPC Metrics SOFARPC currently measures two metrics.\nServer thread pool metric name metric tags specification rpc.bolt.threadpool.config bolt thread pool configuration Mainly includes thread pool configuration information for RPC server rpc.bolt.threadpool.active.count Running thread of the current thread pool rpc.bolt.threadpool.idle.count Idle thread of the current thread pool rpc.bolt.threadpool.queue.size Tasks in the queue of the current thread pool Client call information metric name metric tags specification rpc.","tags":null,"title":"SOFARPC Metrics","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/","wordcount":332},{"author":null,"categories":null,"content":" SOFARPC 目前度量了两个指标。\n 服务端线程池 metric name metric tags specification rpc.bolt.threadpool.config bolt 线程池配置 主要包括 rpc 服务端的线程池配置信息 rpc.bolt.threadpool.active.count 当前线程池的运行线程 rpc.bolt.threadpool.idle.count 当前线程池的空闲线程 rpc.bolt.threadpool.queue.size 当前线程池的队列中的任务 客户端调用信息 metric name metric tags specification rpc.consumer.service.stats.fail_count.count app,service,method,protocol,invoke_type,target_app 某个具体接口失败次数 rpc.consumer.service.stats.fail_count.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒失败 rpc.consumer.service.stats.fail_time.elapPerExec app,service,method,protocol,invoke_type,target_app 某个具体接口每秒执行时间 rpc.consumer.service.stats.fail_time.max app,service,method,protocol,invoke_type,target_app 某个具体接口失败时间最大值 rpc.consumer.service.stats.fail_time.totalTime app,service,method,protocol,invoke_type,target_app 某个具体接口失败时间总值 rpc.consumer.service.stats.request_size.max app,service,method,protocol,invoke_type,target_app 某个具体接口请求大小最大值 rpc.consumer.service.stats.request_size.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒平均请求大小 rpc.consumer.service.stats.request_size.totalAmount app,service,method,protocol,invoke_type,target_app 某个具体接口请求大小总金额 rpc.consumer.service.stats.response_size.max app,service,method,protocol,invoke_type,target_app 某个具体接口响应大小最大值 rpc.consumer.service.stats.response_size.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒平均响应大小 rpc.consumer.service.stats.response_size.totalAmount app,service,method,protocol,invoke_type,target_app 某个具体接口响应大小总金额 rpc.consumer.service.stats.total_count.count app,service,method,protocol,invoke_type,target_app 某个具体接口总的调用数目 rpc.consumer.service.stats.total_count.count_service_sum_30000 app,service,method,protocol,invoke_type,target_app 某个具体接口总的调用信息 rpc.consumer.service.stats.total_count.rate app,service,method,protocol,invoke_type,target_app 某个具体接口每秒调用次数 rpc.consumer.service.stats.total_time.elapPerExec app,service,method,protocol,invoke_type,target_app 某个具体接口平均每次指定时间 rpc.consumer.service.stats.total_time.max app,service,method,protocol,invoke_type,target_app 某个具体接口总时间最大值 rpc.consumer.service.stats.total_time.totalTime app,service,method,protocol,invoke_type,target_app 某个具体接口总时间 服务端被调用信息 metric name metric tags specification rpc.provider.service.stats.fail_count.count app,service,method,protocol,caller_app 某个具体接口总的被调用失败次数 rpc.provider.service.stats.fail_count.rate app,service,method,protocol,caller_app 某个具体接口每秒失败次数 rpc.provider.service.stats.fail_time.elapPerExec app,service,method,protocol,caller_app 某个具体接口每次失败失败 rpc.provider.service.stats.fail_time.max app,service,method,protocol,caller_app 某个具体接口失败次数最大值 rpc.provider.service.stats.fail_time.totalTime app,service,method,protocol,caller_app 某个具体接口失败总时间 rpc.provider.service.stats.total_count.count app,service,method,protocol,caller_app 某个具体接口总的调用次数 rpc.provider.service.stats.total_count.rate app,service,method,protocol,caller_app 某个具体接口每秒调用次 …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/sofarpc-metrics/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1f444349855508f4b111d8f2d2b5e43d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","summary":"SOFARPC 目前度量了两个指标。 服务端线程池 metric name metric tags specification rpc.bolt.threadpool.config bolt 线程池配置 主要包括 rpc 服务端的线程池配置信息 rpc.bolt.threadpool.active.count 当前线程池的运行线程 rpc.bolt.threadpool.idle.count 当前线程池的空闲线程 rpc.bolt.threadpool.queue.size 当前","tags":null,"title":"SOFARPC Metrics 指标","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/","wordcount":487},{"author":null,"categories":null,"content":" SOFARPC is divided into two layers from bottom to top:\n Core layer: It contains the core components of RPC (such as various interfaces, APIs and common packages) and some common implementations (such as random load balancing algorithms). Function implementation layer: All users of the function implementation layer are equal, and all functions are implemented based on the extension mechanism. The internal version specific for Ant Financial just has some internal extension based on the open source version.\nOf course, you can add your own third-party extension. See Extension mechanism for more information.\nModule division The implementation classes of each module only appear in the modules. Generally, the modules don\u0026amp;rsquo;t depend on each other. The modules that require cross dependency have been abstracted into the core or common modules.\nCurrently, SOFARPC is divided into the following modules:\nThe main modules and their corresponding dependencies are as follows:\n Module Submodule Definition Description Dependency all Publish and packing module All modules that need to be packaged bom Dependency control module Control dependency version None example Sample module all test Test module Include integration test all core api API module Include various basic process interfaces, messages, contexts, extension interfaces and others Common core common Public module Include utils and data structure exception core exception Exception module Include various exception interfaces and others common bootstrap Startup implementation module Include start class, service publish or reference logic, and registry operations core proxy Proxy implementation module Generate interface implementation proxy core Client Client implementation module Send request, receive response, maintain connections, routing, and implement load balancing, synchronization, asynchronization and other operations server Server implementation module Start listening, receive requests, send responses, distribute business threads, and implement other operations filter Interceptor implementation module Implement various interceptors for server and client core codec Coding and encoding implementation module Implement compression, serialization and other operations core protocol Protocol implementation module Package and process protocol and conduct negotiation core transport Network transmission implementation module Establish TCP connection, process sticky data packets, and distribute requested response objects registry Registry center implementation module Implement registration centers, such as ZooKeeper core ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/structure-intro/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1902232a50d57df7ab5b2c7eea1f8caa","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/structure-intro/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/structure-intro/","summary":"SOFARPC is divided into two layers from bottom to top:\n Core layer: It contains the core components of RPC (such as various interfaces, APIs and common packages) and some common implementations (such as random load balancing algorithms). Function implementation layer: All users of the function implementation layer are equal, and all functions are implemented based on the extension mechanism. The internal version specific for Ant Financial just has some internal extension based on the open source version.","tags":null,"title":"SOFARPC architecture","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/structure-intro/","wordcount":347},{"author":null,"categories":null,"content":" SOFARPC Log Format After SOFARPC (v5.4.0 and above) is integrated in SOFATracer, the link data is output in JSON format by default. Each field meaning is as follows:\nRPC client digest log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type (bolt, rest) Service interface information Method name Current thread name Calling type (sync, callback, oneway, future) Routing record (DIRECT, REGISTRY) Target IP Target appName Local machine IP Return code (00=success; 01=business exception; 02=RPC logic error; 03=timeout failure;04=routing failure) Request serialization time (in ms) Response deserialization time (in ms) Response size (in Byte) Request size (in Byte) Client connection duration (in ms) Total call duration (in ms) Local client port Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;samples\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC server digest log (rpc-server-digest.log) Log printing time TraceId SpanId Span type Service interface information Method name Source IP Source appName Protocol (bolt, rest) Current appName Current thread name Return code (00=success; 01=business exception; 02=RPC logic error) Server thread pool waiting time (in ms) Business processing duration (in ms) Response serialization time (in ms) Request deserialization time (in ms) Response size (in Byte) Request size (in Byte) Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-sofarpc/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ad45177e2719b9a22f4bfb07a0481905","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","summary":"SOFARPC Log Format After SOFARPC (v5.4.0 and above) is integrated in SOFATracer, the link data is output in JSON format by default. Each field meaning is as follows:\nRPC client digest log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type (bolt, rest) Service interface information Method name Current thread name Calling type (sync, callback, oneway, future) Routing record (DIRECT, REGISTRY) Target IP Target appName Local machine IP Return code (00=success; 01=business exception; 02=RPC logic error; 03=timeout failure;04=routing failure) Request serialization time (in ms) Response deserialization time (in ms) Response size (in Byte) Request size (in Byte) Client connection duration (in ms) Total call duration (in ms) Local client port Transparently transmitted baggage data (kv format) Example:","tags":null,"title":"SOFARPC log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/","wordcount":259},{"author":null,"categories":null,"content":" 项目简介 SOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有的业务的相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。\nSOFARPC 还支持不同的协议，目前包括 bolt，RESTful，dubbo，H2C 协议进行通信。其中 bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。\n基本原理 当一个 SOFARPC 的应用启动的时候，如果发现当前应用需要发布 RPC 服务的话，那么 SOFARPC 会将这些服务注册到服务注册中心上。如图中 Service 指向 Registry。 当引用这个服务的 SOFARPC 应用启动时，会从服务注册中心订阅到相应服务的元数据信息。服务注册中心收到订阅请求后，会将发布方的元数据列表实时推送给服务引用方。如图中 Registry 指向 Reference。 当服务引用方拿到地址以后，就可以从中选取地址发起调用了。如图中 Reference 指向 Service。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/overview/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"62f0806ad40fcaaeab6a82470b14a2e2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/overview/","summary":"项目简介 SOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有的业务的相互","tags":null,"title":"SOFARPC 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/overview/","wordcount":402},{"author":null,"categories":null,"content":" 架构图 SOFARPC 从下到上分为两层：\n 核心层：包含了我们的 RPC 的核心组件（例如我们的各种接口、API、公共包）以及一些通用的实现（例如随机等负载均衡算法）。 功能实现层：所有的功能实现层的用户都是平等的，都是基于扩展机制实现的。 蚂蚁内部使用的版本也只是开源版本上增加一些内部扩展而已。\n当然你也可以增加自己三方扩展，参见：扩展机制\n模块划分 各个模块的实现类都只在自己模块中出现，一般不交叉依赖。需要交叉依赖的全部已经抽象到core或者common模块中。\n目前模块划分如下:\n主要模块及其依赖如下：\n 模块名 子模块名 中文名 说明 依赖 all 发布打包模块 需要打包的全部模块 bom 依赖管控模块 依赖版本管控 无 example 示例模块 all test 测试模块 包含集成测试 all core api API模块 各种基本流程接口、消息、上下文、扩展接口等 common core common 公共模块 utils、数据结构 exception core exception 异常模块 各种异常接口等 common bootstrap 启动实现模块 启动类，发布或者引用服务逻辑、以及registry的操作 core proxy 代理实现模块 接口实现代理生成 core client 客户端实现模块 发送请求、接收响应、连接维护、路由、负载均衡、同步异步等 core server 服务端实现模块 启动监听、接收请求，发送响应、业务线程分发等 core filter 拦截器实现模块 服务端和客户端的各种拦截器实现 core codec 编解码实现模块 例如压缩，序列化等 core protocol 协议实现模块 协议的包装处理、协商 core transport 网络传输实现模块 TCP连接的建立，数据分包粘包处理，请求响应对象分发等 core registry 注册中心实现模块 实现注册中心，例如zk等 core ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/structure-intro/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1902232a50d57df7ab5b2c7eea1f8caa","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/structure-intro/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/structure-intro/","summary":"架构图 SOFARPC 从下到上分为两层： 核心层：包含了我们的 RPC 的核心组件（例如我们的各种接口、API、公共包）以及一些通用的实现（例如随机等负载均衡算法）","tags":null,"title":"SOFARPC 工程架构介绍","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/structure-intro/","wordcount":598},{"author":null,"categories":null,"content":" 本文档将演示了如何应用 SOFARPC 进行服务的发布和引用。 本例将在本地模拟服务端启动监听一个端口并发布一个服务，客户端引用该服务进行直连调用。\n您可以直接在工程下找到本文档的示例代码。\n创建工程 需要安装 JDK 6 及以上 和 Maven 3 以上.\n我们新建一个 Maven 工程，并引入 SOFARPC 的依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-rpc-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;最新版本\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 注：最新版本可以从 https://github.com/sofastack/sofa-rpc/releases 里找到。\n编写服务端实现 第一步：创建接口\n/** * Quick Start demo interface */ public interface HelloService { String sayHello(String string); } 第二步：创建接口实现\n/** * Quick Start demo implement */ public class HelloServiceImpl implements HelloService { @Override public String sayHello(String string) { System.out.println(\u0026amp;quot;Server receive: \u0026amp;quot; + string); return \u0026amp;quot;hello \u0026amp;quot; + string + \u0026amp;quot; ！\u0026amp;quot;; } } 第三步：编写服务端代码\n/** * Quick Start Server */ public class QuickStartServer { public static void main(String[] args) { ServerConfig serverConfig = new ServerConfig() .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // 设置一个协议，默认bolt .setPort(12200) // 设置一个端口，默认12200 .setDaemon(false); // 非守护线程 ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // 指定接口 .setRef(new HelloServiceImpl()) // 指定实现 .setServer(serverConfig); // 指定服务端 providerConfig.export(); // 发布服务 } } 编写客户端实现 第一步：拿到服务端接口\n一般服务端会通过jar的形式将接口类提供给客户端。而在本例中，由于服务端和客户端在一个工程所以跳过。\n第二步：编程客户端代码\n/** * Quick Start client */ public class QuickStartClient { public static void main(String[] args) { ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) // 指定接口 .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) // 指定协议 .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12200\u0026amp;quot;); // 指定直连地址 // 生成代理类 HelloService helloService = consumerConfig.refer(); while (true) { System.out.println(helloService.sayHello(\u0026amp;quot;world\u0026amp;quot;)); try { Thread.sleep(2000); } catch (Exception e) { } } } } 运行 分别启动服务端和客户端，观察运行效果。\n服务端将打印：\n Server receive: world\n 客户端将打印：\n hello world ！\n 更多 更多示例请参考：example\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started-with-rpc/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"192d252b0b36266622284b68d10e9fe4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","summary":"本文档将演示了如何应用 SOFARPC 进行服务的发布和引用。 本例将在本地模拟服务端启动监听一个端口并发布一个服务，客户端引用该服务进行直连调用。 您可以直接","tags":null,"title":"SOFARPC 方式快速入门","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/","wordcount":563},{"author":null,"categories":null,"content":" SOFATracer 集成在 SOFARPC(5.4.0及之后的版本) 后输出链路数据的格式，默认为 JSON 数据格式，具体的字段含义解释如下：\nRPC 客户端 摘要日志（ rpc-client-digest.log） 日志打印时间 TraceId SpanId Span 类型 当前 appName 协议类型(bolt,rest) 服务接口信息 方法名 当前线程名 调用类型(sync,callback,oneway,future) 路由记录(DIRECT,REGISTRY) 目标ip 目标 appName 本机ip 返回码(00=成功/01=业务异常/02=RPC逻辑错误/03=超时失败/04=路由失败) 请求序列化时间(单位ms) 响应反序列化时间(单位ms) 响应大小(单位Byte) 请求大小(单位Byte) 客户端连接耗时(单位ms) 调用总耗时(单位ms) 本地客户端端口 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;samples\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 服务端 摘要日志（ rpc-server-digest.log） 日志打印时间 TraceId SpanId Span 类型 服务接口信息 方法名 来源ip 来源 appName 协议(bolt,rest) 当前 appName 当前线程名 返回码(00=成功/01=业务异常/02=RPC逻辑错误) 服务端线程池等待时间(单位ms) 业务处理耗时(单位ms) 响应序列化时间(单位ms) 请求反序列化时间(单位ms) 响应大小(单位Byte) 请求大小(单位Byte) 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:00:53.312\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526806853032100185011\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SOFA-BOLT-BIZ-12200-5-T1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;server.pool.wait.time\u0026amp;quot;:\u0026amp;quot;3\u0026amp;quot;,\u0026amp;quot;biz.impl.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;resp.serialize.time\u0026amp;quot;:\u0026amp;quot;4\u0026amp;quot;,\u0026amp;quot;req.deserialize.time\u0026amp;quot;:\u0026amp;quot;38\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 客户端 统计日志（ rpc-client-stat.log） 日志打印时间 日志关键key 方法信息 客户端 appName 服务接口信息 调用次数 总耗时(单位ms) 调用结果(Y/N) 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-05-18 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-sofarpc/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ad45177e2719b9a22f4bfb07a0481905","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","summary":"SOFATracer 集成在 SOFARPC(5.4.0及之后的版本) 后输出链路数据的格式，默认为 JSON 数据格式，具体的字段含义解释如下： RPC 客户端 摘要日志（ rpc-c","tags":null,"title":"SOFARPC 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/","wordcount":705},{"author":null,"categories":null,"content":"SOFARPC already supports using SOFARegistry as a service registry. Suppose you have deployed SOFARegistry Server locally according to SOFARegistry\u0026amp;rsquo;s Quick Start, and the service discovery port is set to 9603 by default.\nTo use SOFARegistry as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 The current version of SOFARegistry is supported:\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\nBecause of the time of SOFABoot, users need to specify the version of rpc starter.\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFARPC integration verification SOFARegistry server version: 5.2.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-sofa/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"65085018ce2b2b2ef452993bb79a69de","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","summary":"SOFARPC already supports using SOFARegistry as a service registry. Suppose you have deployed SOFARegistry Server locally according to SOFARegistry\u0026rsquo;s Quick Start, and the service discovery port is set to 9603 by default.\nTo use SOFARegistry as a service registry in SOFARPC, you only need to add the following configuration to application.properties:\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 The current version of SOFARegistry is supported:\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\nBecause of the time of SOFABoot, users need to specify the version of rpc starter.","tags":null,"title":"SOFARegistry","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-sofa/","wordcount":90},{"author":null,"categories":null,"content":" Product introduction SOFARegistry is a production-level, low-latency, and highly available service registry powered by Ant Financial. SOFARegistry was developed on the basis ConfigServer of Taobao. After more than ten years of business development of Ant Financial, SOFARegistry has evolved into the fifth generation architecture. Currently, SOFARegistry not only provides full support to Ant Financial and its numerous partners, but also embraces the open source community. Built on an AP architecture, SOFARegistry support s message push in seconds. It also adopts a layered architecture to support infinite horizontal scaling.\nFeatures High scalability SOFARegistry adopts a layered architecture and partition-based data storage to break the single machine performance and capacity bottleneck, and to support the theoretical \u0026amp;ldquo;infinite horizontal scaling\u0026amp;rdquo;. It has been providing reliable services to the Ant Financial production environment which has a massive number of nodes and services.\nLow latency By virtue of the SOFABolt communication framework, SOFARegistry implements TCP long connection-based heartbeat detection among nodes, and the customized push mode to send service messages between upstream and downstream nodes in seconds.\nHighly available Unlike CP-architecture based registry products such as ZooKeeper, Consul, and Etcd, SOFARegistry adopts the AP architecture based on the service characteristics of service discovery, which significantly improves the availability of the registry in the case of failures caused by network partitioning. SOFARegistry takes many measures, such as multi-replica clusters, to prevent service unavailability arising from node failures.\nArchitecture SOFARegistry has four roles: Client, SessionServer, DataServer, and MetaServer, each with unique capabilities and responsibilities. They are combined to provide external services. The relationships and structures of them are explained as follows.\nClient A client provides basic APIs to allow applications to access SOFARegistry. The client provides JAR packages to application systems, so that they can call the service subscription and publishing features of SOFARegistry.\nSessionServer The SessionServer grants clients access to SessionServer, and accepts service publishing and subscription requests from clients. It also serves as an intermediate layer to forward the published data to DataServer for storage. The SessionServer can be infinitely scaled up to support connection with large amounts of clients.\nDataServer The DataServer is responsible for storing data published by clients. The data is stored by dataId through consistent hashing. DataServer supports multi-replica backup to ensure high availability of the data. The Data can also be infinitely scaled up to support large amounts of data.\nMetaServer The MetaServer is responsible for maintaining the consistency lists of the SessionServer and DataServer within the cluster, and immediately notify other nodes in the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d444761f1ad8b0c52e3505926176b13f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/overview/","summary":"Product introduction SOFARegistry is a production-level, low-latency, and highly available service registry powered by Ant Financial. SOFARegistry was developed on the basis ConfigServer of Taobao. After more than ten years of business development of Ant Financial, SOFARegistry has evolved into the fifth generation architecture. Currently, SOFARegistry not only provides full support to Ant Financial and its numerous partners, but also embraces the open source community. Built on an AP architecture, SOFARegistry support s message push in seconds.","tags":null,"title":"SOFARegistry overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/overview/","wordcount":429},{"author":null,"categories":null,"content":" 项目简介 SOFARegistry 是蚂蚁集团开源的一个生产级、高时效、高可用的服务注册中心。SOFARegistry 最早源自于淘宝的 ConfigServer，十年来，随着蚂蚁金服的业务发展，注册中心架构已经演进至第六代。目前 SOFARegistry 不仅全面服务于蚂蚁集团的自有业务，还随着蚂蚁金融科技服务众多合作伙伴，同时也兼容开源生态。SOFARegistry 采用 AP 架构，支持秒级时效性推送，同时采用分层架构支持无限水平扩展。\n产品特点 高可扩展性 采用分层架构、数据分片存储等方式，突破单机性能与容量瓶颈，接近理论上的“无限水平扩展”。经受过蚂蚁集团生产环境海量节点数与服务数的考验。\n高时效性 借助 SOFABolt 通信框架，实现基于 TCP 长连接的节点判活与推模式的变更推送，服务上下线通知时效性在秒级以内。\n高可用性 不同于 Zookeeper、Consul、Etcd 等 CP 架构注册中心产品，SOFARegistry 针对服务发现的业务特点，采用 AP 架构，最大限度地保证网络分区故障下注册中心的可用性。通过集群多副本等方式，应对自身节点故障。\n架构 服务注册中心分为四个角色，客户端（Client）、会话服务器（SessionServer）、数据服务器（DataServer）、元数据服务器（MetaServer），每个角色司职不同能力组合后共同提供对外服务能力，各部分关系和结构如下：\nClient 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。\nSessionServer 会话服务器，提供客户端接入能力，接受客户端的服务发布及服务订阅请求，并作为一个中间层将发布数据转发 DataServer 存储。SessionServer 可无限扩展以支持海量客户端连接。\nDataServer 数据服务器，负责存储客户端发布数据，数据存储按照数据 ID 进行一致性 hash 分片存储，支持多副本备份，保证数据高可用。DataServer 可无限扩展以支持海量数据量。\nMetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，在节点变更时及时通知集群内其他节点。MetaServer 通过 SOFAJRaft 保证高可用和一致性。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/overview/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d444761f1ad8b0c52e3505926176b13f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/overview/","summary":"项目简介 SOFARegistry 是蚂蚁集团开源的一个生产级、高时效、高可用的服务注册中心。SOFARegistry 最早源自于淘宝的 ConfigServer，十年来","tags":null,"title":"SOFARegistry 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-registry/overview/","wordcount":838},{"author":null,"categories":null,"content":" SOFAStack-Demos 分布式链路组件 SOFATracer 埋点机制 Demo Demo 地址：https://github.com/glmapper/tracers-guides 相关文章：https://www.sofastack.tech/blog/sofa-channel-15-retrospect/ 云原生网络代理 MOSN 扩展机制：MOSN Stream Filter 操作 Demo Demo：https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions Demo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions 操作视频：https://www.bilibili.com/video/BV1SQ4y1K7iw 相关文章：https://www.sofastack.tech/blog/sofa-channel-14-retrospect/ 云原生网络代理 MOSN 多协议机制：接入 SOFABolt 操作 Demo Demo 地址：https://github.com/mosn/mosn/tree/master/examples/codes/sofarpc-with-xprotocol-sample 操作视频：https://www.bilibili.com/video/BV1UZ4y1x7Sj 相关文章：https://www.sofastack.tech/blog/sofa-channel-13-retrospect/ 轻量级类隔离容器 SOFAArk 动态模块操作 Demo Demo：https://github.com/caojie09/sofachannel-demo 操作视频：https://www.bilibili.com/video/BV1wQ4y1T7rt 相关文章：https://www.sofastack.tech/blog/sofa-channel-11-retrospect/ 分布式事务 Seata 长事务解决方案 Saga 模式可视化状态机 Seata Saga 可视化状态机设计器演示地址： http://seata.io/saga_designer/index.html Seata Saga 可视化状态机设计器代码以及运行指南： https://github.com/seata/seata/tree/develop/saga/seata-saga-statemachine-designer 相关文章：https://www.sofastack.tech/blog/sofa-channel-10-retrospect/ SOFAJRaft 的 Counter 例子 Demo Demo 地址：https://www.sofastack.tech/projects/sofa-jraft/counter-example/ 相关文章：https://www.sofastack.tech/blog/sofa-channel-8-retrospect/ 轻量级监控分析系统 SOFALookout 客户端的相关演示操作 Demo Demo 地址：https://github.com/sofastack/sofa-lookout/tree/master/samples/metrics/client 相关文章https://www.sofastack.tech/blog/sofa-channel-6-retrospect/ SOFARPC 内存优化操作 Demo Demo 地址：https://github.com/leizhiyuan/rpcchannel 相关文章：https://www.sofastack.tech/blog/sofa-channel-3-retrospect/ ","date":-62135596800,"description":"本指南为 SOFAStack 多个组件的 Demo 合集。","dir":"guides/sofastack-demos/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6a1fada81ea88116efa0e30539da60a1","permalink":"https://sofastack.github.io/sofastack.tech/guides/sofastack-demos/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/sofastack-demos/","summary":"SOFAStack-Demos 分布式链路组件 SOFATracer 埋点机制 Demo Demo 地址：https://github.com/glmapper/tracers-guides 相关文章：https","tags":null,"title":"SOFAStack Demos","type":"guides","url":"/sofastack.tech/guides/sofastack-demos/","wordcount":1353},{"author":null,"categories":null,"content":" Since SOFARPC 5.4.0, the SOFATracer function is integrated, which is enabled by default. It can output the data information in the link.\nBy default, the output data is in JSON format. The involved fields are as follows:\nRPC client digest Log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type Service interface information Method name Current thread name Calling type Routing record Target IP Local machine IP Return code Request serialization duration Response deserialization duration Response size (in Byte) Request size (in Byte) Client connection duration Total duration for call Local client port Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC server digest log (rpc-server-digest.log) Log printing time TraceId SpanId Span type Service interface information Method name Source IP Source appName Protocol Local appName Current thread name Return code Server thread pool waiting time Business processing duration Response serialization duration Request deserialization duration Response size (in Byte) Request size (in Byte) Transparently transmitted baggage data (kv format) Example:\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/sofatracer-usage/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"dde9dc7a759b7c0c272d67bac1b315d4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","summary":"Since SOFARPC 5.4.0, the SOFATracer function is integrated, which is enabled by default. It can output the data information in the link.\nBy default, the output data is in JSON format. The involved fields are as follows:\nRPC client digest Log (rpc-client-digest.log) Log printing time TraceId SpanId Span type Current appName Protocol type Service interface information Method name Current thread name Calling type Routing record Target IP Local machine IP Return code Request serialization duration Response deserialization duration Response size (in Byte) Request size (in Byte) Client connection duration Total duration for call Local client port Transparently transmitted baggage data (kv format) Example:","tags":null,"title":"SOFATracer","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/","wordcount":222},{"author":null,"categories":null,"content":" SOFATracer Tools Get Span through SOFATracer context In the process of a distributed link call, the component that integrates SOFATracer generates a Span and caches it in the SOFATracer context. And the context is cached in ThreadLocal. You can get the current SOFATracer context in the following way:\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); Through the SOFATracer context SofaTraceContext, you can add, delete, modify, check, and empty the cached Spans. As the developers responsible for integrating components, we will add, delete, modify and check the SOFATracer context to integrate distributed link tracking. However, as the application developer to directly use SOFATracer, you only need to get the corresponding Span. That is to say, you only need to use the following method after getting the context:\nSofaTracerSpan sofaTracerSpan = sofaTraceContext.getCurrentSpan(); Get information through Span When using the SOFATracer plugin component, such as Spring MVC, the component integrates the capabilities of SOFATracer. So it can get all the information in the Span after getting Span. The specific acquisition method example (it demands that Span is not empty, namely that the corresponding component has integrated SOFATracer) is as follow:\nGet TraceId and SpanId: SofaTracerSpanContext sofaTracerSpanContext = currentSpan.getSofaTracerSpanContext(); String traceId = sofaTracerSpanContext.getTraceId(); String spanId = sofaTracerSpanContext.getSpanId(); Get Tags and Logs in OpenTracing specification Get Tags:\nMap\u0026amp;lt;String, String\u0026amp;gt; tagsStr = sofaTracerSpan.getTagsWithStr(); Map\u0026amp;lt;String, Boolean\u0026amp;gt; tagsBool = sofaTracerSpan.getTagsWithBool(); Map\u0026amp;lt;String, Number\u0026amp;gt; tagsNumber = sofaTracerSpan.getTagsWithNumber(); Get Logs:\nList \u0026amp;lt;LogData\u0026amp;gt; logDataList = sofaTracerSpan.getLogs (); Process transparently transmitted data Baggage element is a collection of key-value pairs that carries data to be transparently transmitted. In SOFATracer, Baggage data is divided into sysBaggage and bizBaggage; sysBaggage mainly refers to transparently transmitted system data, and bizBaggage mainly refers to transparently transmitted business data.\nConfigure and get BaggageItem BaggageItem is a data element in the Baggage collection.\n Configure the corresponding BaggageItem data through the standard interface: String baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageVal = \u0026amp;quot;val\u0026amp;quot;; sofaTracerSpan.setBaggageItem(baggageKey,baggageVal); Get the corresponding BaggageItem data through the standard interface: String baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageValue = sofaTracerSpan.getBaggageItem(baggageKey); Note: Configuring and getting Baggage data through the standard interface is actually operated on bizBaggage.\nConfigure and get \u0026amp;lsquo;Baggage\u0026amp;rsquo; data 1, Configure \u0026amp;lsquo;Baggage\u0026amp;rsquo; data\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggage …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/utils/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"d40318a5bd3ee5e1573f8770ea649dba","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/utils/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/utils/","summary":"SOFATracer Tools Get Span through SOFATracer context In the process of a distributed link call, the component that integrates SOFATracer generates a Span and caches it in the SOFATracer context. And the context is cached in ThreadLocal. You can get the current SOFATracer context in the following way:\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); Through the SOFATracer context SofaTraceContext, you can add, delete, modify, check, and empty the cached Spans. As the developers responsible for integrating components, we will add, delete, modify and check the SOFATracer context to integrate distributed link tracking.","tags":null,"title":"SOFATracer Tools","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/utils/","wordcount":443},{"author":null,"categories":null,"content":" SOFATracer configuration item After introducing SOFATracer, you can add related configuration items in Spring Boot configuration file application.properties to customize the behaviors of SOFATracer.\nFor SOFATracer log output directory, you can configure logging.path in application.properties, then the log output path is ${logging.path}/tracelog; if logging.path is not configured, the default output path is ${user.home}/logs/tracelog.\n Configuration item Description Default value logging.path log output directory SOFATracer output logs to logging.path directory in priority; If the directory is not configured, log will be output to ${user.home} by default. com.alipay.sofa.tracer.disableDigestLog Disable all integrated SOFATracer summary log printing false com.alipay.sofa.tracer.disableConfiguration[${logType}] Disable specific SOFATracer summary log printing of ${logType}. ${logType} indicates the log type, such as spring-mvc-digest.log false com.alipay.sofa.tracer.tracerGlobalRollingPolicy SOFATracer log rolling policy yyyy-MM-dd：roll by day；yyyy-MM-dd_HH：roll by hour;Logs are not rolled by day by default. com.alipay.sofa.tracer.tracerGlobalLogReserveDay Retention days of SOFATracer logs Retained for 7 days by default. com.alipay.sofa.tracer.statLogInterval Time interval of statistical logs, unit: second Output statistical logs once every 60 seconds by default com.alipay.sofa.tracer.baggageMaxLength Maximum length for retaining penetration data Default: 1024 com.alipay.sofa.tracer.zipkin.enabled Whether to enable SOFATracer remote data reporting to Zipkin true: enable; false: disable. Disabled by default. com.alipay.sofa.tracer.zipkin.baseUrl The address Zipkin address to which SOFATracer remotely reports data, which works only in the case of com.alipay.sofa.tracer.zipkin.enabled=true Format: http: //${host}:${port} com.alipay.sofa.tracer.springmvc.filterOrder Order validated by SOFATrace Filter intergrated in SpringMVC -2147483647(org.springframework.core.Ordered#HIGHEST_PRECEDENCE + 1) com.alipay.sofa.tracer.springmvc.urlPatterns URL Pattern paths validated by SOFATrace Filter intergrated in SpringMVC /*: All validated ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/configuration/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1a6bf2b7aa168440544f8d0d69358869","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/configuration/","summary":"SOFATracer configuration item After introducing SOFATracer, you can add related configuration items in Spring Boot configuration file application.properties to customize the behaviors of SOFATracer.\nFor SOFATracer log output directory, you can configure logging.path in application.properties, then the log output path is ${logging.path}/tracelog; if logging.path is not configured, the default output path is ${user.home}/logs/tracelog.\n Configuration item Description Default value logging.path log output directory SOFATracer output logs to logging.","tags":null,"title":"SOFATracer configuration items","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/configuration/","wordcount":231},{"author":null,"categories":null,"content":" SOFATracer is a distributed link tracing system based on OpenTracing specification developed by Ant Financial. Its core concept is to concatenate the same request distributed on each service node with a global TraceId. By the unified TraceId, it can record the various network call information in the call link in logs, and can remotely report the call records to Zipkin for presentation, thus implementing perspective network call.\nFeatures Distributed link tracing solution based on OpenTracing specification SOFATracer is a solution that provides link tracing based on and improved from the OpenTracing specification. Based on this implementation, each framework or component can provide the ability to link tracking by burying points.\nProvide asynchronous log printing to disks Based on high-performance lock-free loop queue of Disruptor, SOFATracer provides the ability to print logs asynchronously to local disk. The introduced framework or component can customize the output format of the log file under the premise of asynchronous log printing. SOFATracer provides two types of logs, digest log and statistical log. Digest log: logs that are printed to disk upon each call. Statistical log: logs that are printed at regular intervals.\nSupport automatic log cleanup and scrolling Asynchronous SOFATracer log supports automatic cleanup and scrolling, and supports cleaning by day and scrolling by hour or day.\nExtended based on SLF4J MDC SLF4J provides MDC (Mapped Diagnostic Contexts), which supports user to define and modify the output log format and content. SOFATracer integrates the SLF4J MDC function, which allows user to output the TraceId and SpanId of the current Tracer context by simply modifying the log configuration file.\nInterface presentation SOFATracer can remotely report link tracing data to the open-source product Zipkin for distributed link tracing presentation.\nUnified configuration The profile file provides various configuration options for you to customize the individual requirements of the application.\nScenario SOFATracer solves the problem of link tracing when implementing large-scale microservice architecture, achieves perspective network call, and can be used to rapidly Failures Discovery, Service Governance, and so on.\nComponent event tracking At present, SOFATracer supports Spring MVC, database connection pool (DBCP, Druid, c3p0, tomcat, HikariCP, BoneCP) acheived by standard JDBC interface, HttpClient and other open-source components. Event tracking for other open-source components (such as MQ, Redis) is still in development.\n Component Document Version Spring MVC doc link 2.1.0 DBCP doc link 2.2.0 Druid doc link 2.2.0 C3p0 doc link 2.2.0 HikariCP doc link 2.2.0 HttpClient doc link 2.2.0 RestTemplate doc link 2.3.0 OkHttp doc link 2.3.2 Dubbo doc link 2.4.0 OpenFeign doc link 3.0.4 Redis TODO MQ TODO ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/overview/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e8d6bf5eec6c5ce1e41d461743f2c4f1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/overview/","summary":"SOFATracer is a distributed link tracing system based on OpenTracing specification developed by Ant Financial. Its core concept is to concatenate the same request distributed on each service node with a global TraceId. By the unified TraceId, it can record the various network call information in the call link in logs, and can remotely report the call records to Zipkin for presentation, thus implementing perspective network call.\nFeatures Distributed link tracing solution based on OpenTracing specification SOFATracer is a solution that provides link tracing based on and improved from the OpenTracing specification.","tags":null,"title":"SOFATracer overview","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/overview/","wordcount":421},{"author":null,"categories":null,"content":" SOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin 进行展示的能力，以此达到透视化网络调用的目的。\n功能描述 基于 OpenTracing 规范提供分布式链路跟踪解决方案 基于 OpenTracing 规范 并扩展其能力提供链路跟踪的解决方案。各个框架或者组件可以基于此实现，通过在各个组件中埋点的方式来提供链路跟踪的能力。\n提供异步落地磁盘的日志打印能力 基于 Disruptor 高性能无锁循环队列，提供异步打印日志到本地磁盘的能力。框架或者组件能够在接入时，在异步日志打印的前提下可以自定义日志文件的输出格式。SOFATracer 提供两种类似的日志打印类型即摘要日志和统计日志，摘要日志：每一次调用均会落地磁盘的日志；统计日志：每隔一定时间间隔进行统计输出的日志。\n支持日志自清除和滚动能力 异步落地磁盘的 SOFATracer 日志支持自清除和滚动能力，支持按照按照天清除和按照小时或者天滚动的能力\n基于 SLF4J MDC 的扩展能力 SLF4J 提供了 MDC（Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。SOFATracer 集成了 SLF4J MDC 功能，方便用户在只简单修改日志配置文件即可输出当前 Tracer 上下文的 TraceId 和 SpanId。\n界面展示能力 SOFATracer 可以将链路跟踪数据远程上报到开源产品 Zipkin 做分布式链路跟踪的展示。\n统一配置能力 配置文件中提供丰富的配置能力以定制化应用的个性需求。\n应用场景 解决在实施大规模微服务架构时的链路跟踪问题，达到透视化网络调用的目的，并可用于故障的快速发现，服务治理等。\n组件埋点 目前 SOFATracer 支持 Spring MVC、标准 JDBC 接口实现的数据库连接池(DBCP、Druid、c3p0、tomcat、HikariCP、BoneCP)、HttpClient、Dubbo、Spring Cloud OpenFeign 等开源组件，其他开源组件（如 MQ、Redis）埋点支持在开发中。\n 支持组件 接入文档 支持版本 Spring MVC doc link 2.1.0 DBCP doc link 2.2.0 Druid doc link 2.2.0 c3p0 doc link 2.2.0 HikariCP doc link 2.2.0 HttpClient doc link 2.2.0 OkHttp doc link 2.3.2 Dubbo doc link 2.4.0 Redis TODO MQ TODO ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/overview/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e8d6bf5eec6c5ce1e41d461743f2c4f1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/overview/","summary":"SOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范 的分布式链路跟踪系统，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调","tags":null,"title":"SOFATracer 介绍","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/overview/","wordcount":843},{"author":null,"categories":null,"content":" 通过 SOFATracer 上下文获取 Span 在一次分布式链路调用过程中，在集成了 SOFATracer 的组件会产生一个 Span 并会缓存到 SOFATracer 的上下文中，这个上下文是缓存在 ThreadLocal 中的，作为使用者可以通过如下的方式随时获取到当前 SOFATracer 的上下文：\nSofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext(); SOFATracer 上下文 SofaTraceContext 通过这个实例，可以对其缓存的 Span 执行增、删、改、查和清空操作。作为组件集成的同学在集成过程中我们会对 SOFATracer 上下文做增、删、改和查等操作来集成分布式链路跟踪的能力；但是作为直接使用 SOFATracer 的应用开发者，我们只需要能够获取相应的 Span 即可，即只需要在获取上下文后使用如下的方法：\nSofaTracerSpan sofaTracerSpan = sofaTraceContext.getCurrentSpan(); 通过 Span 获取信息 在使用相应的组件如 Spring MVC 时，该组件集成了 SOFATracer 的能力后可以在获取到 Span 后获取到 Span 中的所有信息，具体获取方式示例（前提 Span 不为空即相应组件已经集成 SOFATracer）：\n获取 TraceId 和 SpanId ： SofaTracerSpanContext sofaTracerSpanContext = currentSpan.getSofaTracerSpanContext(); String traceId = sofaTracerSpanContext.getTraceId(); String spanId = sofaTracerSpanContext.getSpanId(); 获取 OpenTracing 规范中的 Tags 和 Logs 获取 Tags:\nMap\u0026amp;lt;String, String\u0026amp;gt; tagsStr = sofaTracerSpan.getTagsWithStr(); Map\u0026amp;lt;String, Boolean\u0026amp;gt; tagsBool = sofaTracerSpan.getTagsWithBool(); Map\u0026amp;lt;String, Number\u0026amp;gt; tagsNumber = sofaTracerSpan.getTagsWithNumber(); 获取 Logs:\nList\u0026amp;lt;LogData\u0026amp;gt; logDataList = sofaTracerSpan.getLogs(); 透传数据处理 Baggage 元素是一个键值对集合，其携带的是需要透传的数据。SOFATracer 中将 Baggage 数据分为 sysBaggage 和 bizBaggage；sysBaggage 主要是指系统维度的透传数据，bizBaggage 主要是指业务的透传数据。\n设置和获取 BaggageItem BaggageItem 是 Baggage集合中的数据元素。\n1、通过标准接口设置相应的 BaggageItem 数据：\nString baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageVal = \u0026amp;quot;val\u0026amp;quot;; sofaTracerSpan.setBaggageItem(baggageKey,baggageVal); 2、通过标准接口获取相应的 BaggageItem 数据：\nString baggageKey = \u0026amp;quot;key\u0026amp;quot;; String baggageValue = sofaTracerSpan.getBaggageItem(baggageKey); 注：当通过标准接口进行设置和获取 Baggage 数据时，实际上操作的对象均为 bizBaggage\n设置和获取 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据 1、设置 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggage = new HashMap\u0026amp;lt;String, String\u0026amp;gt;(); bizBaggage.put(\u0026amp;quot;bizKey\u0026amp;quot;,\u0026amp;quot;bizVal\u0026amp;quot;); sofaTracerSpanContext.addBizBaggage(bizBaggage); Map\u0026amp;lt;String, String\u0026amp;gt; sysBaggage = new HashMap\u0026amp;lt;String, String\u0026amp;gt;(); sysBaggage.put(\u0026amp;quot;sysKey\u0026amp;quot;,\u0026amp;quot;sysVal\u0026amp;quot;); sofaTracerSpanContext.addSysBaggage(sysBaggage); 2、获取 \u0026amp;lsquo;Baggage\u0026amp;rsquo; 数据\nSofaTracerSpanContext sofaTracerSpanContext = sofaTracerSpan.getSofaTracerSpanContext(); //获取 bizBaggage Map\u0026amp;lt;String, String\u0026amp;gt; bizBaggages = sofaTracerSpanContext.getBizBaggage(); //获取 sysBaggage Map\u0026amp;lt;String, String\u0026amp;gt; sysBaggages = sofaTracerSpanContext.getSysBaggage(); 遍历 Baggage 数据 OpenTracing 规范中 SpanContext 接口提供了 baggageItems() 方法，可以通过这个方法来遍历所有的 baggage 元素。SOFATracer 在 SofaTracerSpanContext 类中对 baggageItems() 方法进行了具体实现。\nIterable\u0026amp;lt;Map.Entry\u0026amp;lt;String, String\u0026amp;gt;\u0026amp;gt; entrySet = sofaTracerSpanContext.baggageItems(); 注：遍历 Baggage 数据返回的是 sysBaggage 和 bizBaggage 的合集。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/utils/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d40318a5bd3ee5e1573f8770ea649dba","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/utils/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/utils/","summary":"通过 SOFATracer 上下文获取 Span 在一次分布式链路调用过程中，在集成了 SOFATracer 的组件会产生一个 Span 并会缓存到 SOFATracer 的上下文中，这个上下文是缓存在 ThreadLocal 中的，作为使用者可以通","tags":null,"title":"SOFATracer 工具类","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/utils/","wordcount":738},{"author":null,"categories":null,"content":" 应用在引入 SOFATracer 后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 SOFATracer 的相关行为。\nSOFATracer 的日志输出目录，可以在 application.properties 中配置 logging.path 的路径，那么其日志输出路径为 ${logging.path}/tracelog；如果没有配置 logging.path，那么 SOFATracer 的默认输出路径为 ${user.home}/logs/tracelog。\nSpringBoot 工程配置 SOFATracer 配置项 说明 默认值 logging.path 日志输出目录 SOFATracer 会优先输出到 logging.path 目录下；如果没有配置日志输出目录，那默认输出到 ${user.home} com.alipay.sofa.tracer.disableDigestLog 是否关闭所有集成 SOFATracer 组件摘要日志打印 false com.alipay.sofa.tracer.disableConfiguration[${logType}] 关闭指定 ${logType} 的 SOFATracer 组件摘要日志打印。${logType}是指具体的日志类型，如：spring-mvc-digest.log false com.alipay.sofa.tracer.tracerGlobalRollingPolicy SOFATracer 日志的滚动策略 .yyyy-MM-dd：按照天滚动；.yyyy-MM-dd_HH：按照小时滚动。默认不配置按照天滚动 com.alipay.sofa.tracer.tracerGlobalLogReserveDay SOFATracer 日志的保留天数 默认保留 7 天 com.alipay.sofa.tracer.statLogInterval 统计日志的时间间隔，单位：秒 默认 60 秒统计日志输出一次 com.alipay.sofa.tracer.baggageMaxLength 透传数据能够允许存放的最大长度 默认值 1024 com.alipay.sofa.tracer.zipkin.enabled 是否开启 SOFATracer 远程上报数据到 Zipkin true：开启上报；false：关闭上报。默认不上报 com.alipay.sofa.tracer.zipkin.baseUrl SOFATracer 远程上报数据到 Zipkin 的地址，com.alipay.sofa.tracer.zipkin.enabled=true时配置此地址才有意义 格式：http://${host}:${port} com.alipay.sofa.tracer.springmvc.filterOrder SOFATracer 集成在 SpringMVC 的 Filter 生效的 Order -2147483647（org.springframework.core.Ordered#HIGHEST_PRECEDENCE + 1） com.alipay.sofa.tracer.springmvc.urlPatterns SOFATracer 集成在 SpringMVC 的 Filter 生效的 URL Pattern 路径 /* 全部生效 com.alipay.sofa.tracer.jsonOutput 是否以json格式输出日志 true，如果期望较少日志空间占用，可以使用非 json 格式输出（日志顺序与JSON 格式顺序一致） 非SpringBoot 工程配置 在非 SpringBoot 工程中，可以通过在 classpath 下新建一个 sofa.tracer.properties 配置文件，配置项如下：\n SOFATracer 配置项 说明 默认值 disable_middleware_digest_log 是否关闭中间件组件摘要日志打印 false disable_digest_log 关闭摘要日志打印。 false tracer_global_rolling_policy SOFATracer 日志的滚动策略 .yyyy-MM-dd：按照天滚动；.yyyy-MM-dd_HH：按照小时滚动。默认不配置按照天滚动 tracer_global_log_reserve_day SOFATracer 日志的保留天数 默认保留 7 天 stat_log_interval 统计日志的时间间隔，单位：秒 默认 60 秒统计日志输出一次 tracer_penetrate_attribute_max_length 透传数据能够允许存放的最大长度 默认值 1024 tracer_async_appender_allow_discard 是否允许丢失日志 false tracer_async_appender_is_out_discard_number 丢失日志数 0 spring.application.name 应用名 `` tracer_sampler_strategy_name_key 采样策略名 `` tracer_sampler_strategy_custom_rule_class_name 采样规则 spi 实现的类的全限定名 `` tracer_sampler_strategy_percentage_key 采样比率 com.alipay.sofa.tracer.jsonOutput 是否以json格式输出日志 true，如果期望较少日志空间占用，可以使用非 json 格式输出（日志顺序与JSON 格式顺序一致） ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/configuration/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1a6bf2b7aa168440544f8d0d69358869","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-tracer/configuration/","summary":"应用在引入 SOFATracer 后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 SOFATracer 的相关行为。 SOFATracer 的日志输出目录，可以在 application.properties 中配置 logging.path 的路径，那么其日志输出路径为 ${","tags":null,"title":"SOFATracer 配置项","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/configuration/","wordcount":1004},{"author":null,"categories":null,"content":" 在SOFARPC(5.4.0及之后的版本) 后的版本中，我们集成了SOFATracer的功能，默认开启，可以输出链路中的数据信息。\n默认为 JSON 数据格式，具体的字段含义解释如下：\nRPC 客户端 摘要日志（ rpc-client-digest.log） 日志打印时间 TraceId SpanId Span 类型 当前 appName 协议类型 服务接口信息 方法名 当前线程名 调用类型 路由记录 目标ip 本机ip 返回码 请求序列化时间 响应反序列化时间 响应大小(单位Byte) 请求大小(单位Byte) 客户端连接耗时 调用总耗时 本地客户端端口 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:03:20.708\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526807000498100185597\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;main\u0026amp;quot;,\u0026amp;quot;invoke.type\u0026amp;quot;:\u0026amp;quot;sync\u0026amp;quot;,\u0026amp;quot;router.record\u0026amp;quot;:\u0026amp;quot;DIRECT\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;,\u0026amp;quot;local.client.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;req.serialize.time\u0026amp;quot;:\u0026amp;quot;33\u0026amp;quot;,\u0026amp;quot;resp.deserialize.time\u0026amp;quot;:\u0026amp;quot;39\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;client.conn.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;client.elapse.time\u0026amp;quot;:\u0026amp;quot;155\u0026amp;quot;,\u0026amp;quot;local.client.port\u0026amp;quot;:\u0026amp;quot;59774\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} RPC 服务端 摘要日志（ rpc-server-digest.log） 日志打印时间 TraceId SpanId Span 类型 服务接口信息 方法名 来源ip 来源 appName 协议 本应用 appName 当前线程名 返回码 服务端线程池等待时间 业务处理耗时 响应序列化时间 请求反序列化时间 响应大小(单位Byte) 请求大小(单位Byte) 透传的 baggage 数据 (kv 格式) 样例：\n{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 17:00:53.312\u0026amp;quot;,\u0026amp;quot;tracerId\u0026amp;quot;:\u0026amp;quot;1e27326d1526806853032100185011\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;service\u0026amp;quot;:\u0026amp;quot;com.alipay.sofa.tracer.examples.sofarpc.direct.DirectService:1.0\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;sayDirect\u0026amp;quot;,\u0026amp;quot;remote.ip\u0026amp;quot;:\u0026amp;quot;127.0.0.1\u0026amp;quot;,\u0026amp;quot;remote.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;protocol\u0026amp;quot;:\u0026amp;quot;bolt\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerRPC\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;SOFA-BOLT-BIZ-12200-5-T1\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;00\u0026amp;quot;,\u0026amp;quot;server.pool.wait.time\u0026amp;quot;:\u0026amp;quot;3\u0026amp;quot;,\u0026amp;quot;biz.impl.time\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;resp.serialize.time\u0026amp;quot;:\u0026amp;quot;4\u0026amp;quot;,\u0026amp;quot;req.deserialize.time\u0026amp;quot;:\u0026amp;quot;38\u0026amp;quot;,\u0026amp;quot;resp.size\u0026amp;quot;:\u0026amp;quot;170\u0026amp;quot;,\u0026amp;quot;req.size\u0026amp;quot;:\u0026amp;quot;582\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,{\u0026amp;quot;timestamp\u0026amp;quot;:\u0026amp;quot;2018-05-20 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/sofatracer-usage/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dde9dc7a759b7c0c272d67bac1b315d4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","summary":"在SOFARPC(5.4.0及之后的版本) 后的版本中，我们集成了SOFATracer的功能，默认开启，可以输出链路中的数据信息。 默认为 JSON 数据","tags":null,"title":"SOFATracer 链路追踪","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/sofatracer-usage/","wordcount":529},{"author":null,"categories":null,"content":" Sampling Currently,SOFATracer provides two sampling modes. One is the fixed sampling rate based on BitSet. The other is the sampling provided to the user to customize the implementation sampling.The following example shows how to use it.\nThis example is based on the tracer-sampled-with-springmvc project,Except for application.properties, everything else is the same.\nSampling mode based on fixed sampling rate Add sampling related configuration items in application.properties #Sampling rate 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #Sampling type name com.alipay.sofa.tracer.samplerName=PercentageBasedSampler Verification When the sample rate is set to 100, the digest log is printed each time. When the sample rate is set to 0, the digest log is not printed. Print by probability when the sampling rate is set between 0 and 100. The result is verified by requesting 10 times.\n1、When the sample rate is set to 100, the digest log is printed each time.\nStart the project and enter in the browser:http://localhost:8080/springmvc ,And refresh the address 10 times, check the log as follows:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:47.643\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173568757510019269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:68,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:50.980\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569097710029269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:51.542\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569153910049269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-4\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/sampler/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"48856a040da01abc84213934c1c5fce4","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/sampler/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/sampler/","summary":"Sampling Currently,SOFATracer provides two sampling modes. One is the fixed sampling rate based on BitSet. The other is the sampling provided to the user to customize the implementation sampling.The following example shows how to use it.\nThis example is based on the tracer-sampled-with-springmvc project,Except for application.properties, everything else is the same.\nSampling mode based on fixed sampling rate Add sampling related configuration items in application.properties #Sampling rate 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #Sampling type name com.","tags":null,"title":"Sampling modes","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/sampler/","wordcount":426},{"author":null,"categories":null,"content":" 1. Integrated deployment 1.1 Scale up registry-integration Assume that three registry-integration servers have been deployed currently, which are namely node1, node2, and node 3. The new node to be added to the cluster is node 4.\nOperation steps:\nStep 1. Deploy the new registry-integration node\nFirst, deploy registry-integration.tgz on node4 by referencing the Deployment topic. Note that you need to set the nodes.metaNode configuration item on node4 to a 4-server endpoint list:\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt; In this step, after node4 is started, visit curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check. The status will be unhealthy, because node4 has not been added to the cluster yet. To add it to the cluster, perform the next step.\nStep 2. Call the changePeer operation to add a new node to a cluster\nRun the changePeer command on one of the existing servers (node1, node2, and node3), to modify the current cluster from a three-node cluster (node1, node2, and node3) to a four-node cluster (node1, node2, node3, and node4):\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt;\u0026amp;quot; After completing this step, visit curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check. The status will be healthy.\n1.2 Scale down registry-integration Assume that you have three servers in one cluster, which are respectively node1, node2, and node3, and you want to scale down node3.\n1.2.1 Smooth scale-down Operation steps:\nStep 1. Call the changePeer operation to remove a node\nRun the changePeer command on either node1 or node2 to change the cluster list from \u0026amp;ldquo;node1, node2, node3\u0026amp;rdquo; to \u0026amp;ldquo;node1,node2\u0026amp;rdquo;. This removes node3 from the endpoint list of the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; After completing this step, visit curl http://\u0026amp;lt;node3\u0026amp;gt;:9615/health/check. The status will be unhealthy, because node3 has already been removed from the cluster.\nStep 2. Close node3\nThis step is optional, because node3 has already been removed from the cluster, and it does not affect the cluster even if it is still running.\n1.2.2 Handling of node failure If node3 is no longer functional, you need to remove it from the cluster.\nOperation steps:\nStep 1. Call the changePeer operation to remove a node\nRun the changePeer command on either node1 or node2 to change the cluster list from \u0026amp;ldquo;node1, node2, node3\u0026amp;rdquo; to \u0026amp;ldquo;node1,node2\u0026amp;rdquo;. This removes node3 from the endpoint list of the cluster:\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 2. Independent deployment 2.1 Scale up registry-meta Assume that you have already deployed three registry-meta servers, which are respectively metaNode1, metaNode2, and metaNode3. The new node to be added to the …","date":-62135596800,"description":"","dir":"projects/sofa-registry/scale/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"57de6dc4da1292063ff25ecea9ffbd08","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/scale/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/scale/","summary":"1. Integrated deployment 1.1 Scale up registry-integration Assume that three registry-integration servers have been deployed currently, which are namely node1, node2, and node 3. The new node to be added to the cluster is node 4.\nOperation steps:\nStep 1. Deploy the new registry-integration node\nFirst, deploy registry-integration.tgz on node4 by referencing the Deployment topic. Note that you need to set the nodes.metaNode configuration item on node4 to a 4-server endpoint list:","tags":null,"title":"Scaling","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/scale/","wordcount":954},{"author":null,"categories":null,"content":" Quickly understand ACTS scripts Do you have to frequently compile test cases? Are you frustrated by the following problems?\n You have to repeat assertEquals, which is definitely not creative. Missing an assert may lead to false success, while mistaking one may ruin your mood. If the scenario is complex, the test code may be longer than the service code, which is painful. You have to migrate utility classes every time you start writing test cases for a new application. A TestNG test case is shown on the left side, and an ACTS test case on the right. Repeated coding is gone, and the code size is significantly reduced. Unlike ordinary test scripts, ACTS scripts inherit from the ActsTestBase class, which is encapsulated with data loading methods, driving methods, execution engines, and validation rules. Users do not have to clean or prepare data, run test cases, or validate results. ACTS implements zero coding for simple services, which greatly reduces the coding and maintenance costs.\nGenerate test scripts Prerequisites: Be sure to use Maven to compile your project and generate the object model. Otherwise, ACTS IDE may encounter unexpected errors, such as edit failures and incorrect data.\nRight click a the method defined in the interface and select ACTS Function \u0026amp;gt; Generate Test Case.\nRun test script Method: Right click the tested method in ACTS script, and select TestNG to run the test script as shown in the following figure.\nSpecify a test script to run Set test_only＝^T in src/test/resource/config/acts-config.properties to run only the test case whose name starts with T. You can also replace ^T with other regular expressions.\n In this case, you can modify the name of the test case that you want to run by adding T in front of its name. ACTS only runs a test case whose name starts with T.\n Split test cases of the test script ACTS stores all test case data of a test script in the same YAML file by default. You can determine whether to store test case data by test script or by test case by configuring the option spilt_yaml_by_case. It is set to false by default, which means all test case data of the same test script is stored in one YAML file.\nYou can set spilt_yaml_by_case=true in acts-config.properties to store each test case of a new test script in a separate YAML file that is named after the case ID. This reduces the chances of file conflicts in the case where multiple developers work on the same interface.\nIn addition, ACTS provides a utility class that allows you split a legacy YAML file of a specified test script under a specified path by test case. See the following.\nBaseDataUtil.saveYamlDataToCaseByCase\n Note: Before the split, we recommend that you rename the original YAML file for backup, and then use the test case editor to check whether the content of the split files is correct. The original YAML file must be deleted if the split files are correct, because they cannot coexist. Coding for data preparation ACTS provides context APIs …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-script/","fuzzywordcount":900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"0d20739dedad1f11277bd02ed65329c3","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-script/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/en/projects/sofa-acts/usage-script/","summary":"Quickly understand ACTS scripts Do you have to frequently compile test cases? Are you frustrated by the following problems?\n You have to repeat assertEquals, which is definitely not creative. Missing an assert may lead to false success, while mistaking one may ruin your mood. If the scenario is complex, the test code may be longer than the service code, which is painful. You have to migrate utility classes every time you start writing test cases for a new application.","tags":null,"title":"Scripts","type":"projects","url":"/sofastack.tech/en/projects/sofa-acts/usage-script/","wordcount":825},{"author":null,"categories":null,"content":" SEATA Demo for SOFAStack Cloud Native Workshop on KubeCon China 2019\nAT mode 1.Introduce maven dependencies Introduce the following dependencies into the POM file of the parent project (seata-demo-at/pom.xml):\n... \u0026amp;lt;properties\u0026amp;gt; ... \u0026amp;lt;seata.version\u0026amp;gt;0.6.1\u0026amp;lt;/seata.version\u0026amp;gt; \u0026amp;lt;netty4.version\u0026amp;gt;4.1.24.Final\u0026amp;lt;/netty4.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; ... \u0026amp;lt;dependencyManagement\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; ... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;javax.servlet\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;servlet-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${netty4.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; \u0026amp;lt;/dependencyManagement\u0026amp;gt; Introduce the following dependencies into the POM file of the stock-mng project (seata-demo-at/stock-mng/pom.xml):\n\u0026amp;lt;dependencies\u0026amp;gt; .... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; Introduce the following dependencies into the POM file of the balance-mng-impl project (seata-demo-at/balance-mng/balance-mng-impl/pom.xml):\n\u0026amp;lt;dependencies\u0026amp;gt; .... \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 2. Use Seata\u0026amp;rsquo;s DataSourceProxy to proxy actual data source and configure GlobalTransactionScanner to scan @GlobalTransaction annotation Add the following java snippet to the main methods in BalanceMngApplication and StockMngApplication classes:\n... import io.seata.rm.datasource.DataSourceProxy; import io.seata.spring.annotation.GlobalTransactionScanner; ... @Configuration public static class DataSourceConfig { @Bean @Primary @ConfigurationProperties(prefix = \u0026amp;quot;spring.datasource.hikari\u0026amp;quot;) public DataSource dataSource(DataSourceProperties properties) { HikariDataSource dataSource = createDataSource(properties, HikariDataSource.class); if (StringUtils.hasText(properties.getName())) { dataSource.setPoolName(properties.getName()); } return new DataSourceProxy(dataSource); } @SuppressWarnings(\u0026amp;quot;unchecked\u0026amp;quot;) …","date":-62135596800,"description":"This guide introduces how to use the AT mode and TCC mode of the open-source distributed transaction framework Seata to solve the final consistency of service data.","dir":"guides/kc-seata-demo/","fuzzywordcount":1500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"60071a0eb44bf0901fb187eefd63ccdb","permalink":"https://sofastack.github.io/sofastack.tech/en/guides/kc-seata-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/en/guides/kc-seata-demo/","summary":"SEATA Demo for SOFAStack Cloud Native Workshop on KubeCon China 2019\nAT mode 1.Introduce maven dependencies Introduce the following dependencies into the POM file of the parent project (seata-demo-at/pom.xml):\n... \u0026lt;properties\u0026gt; ... \u0026lt;seata.version\u0026gt;0.6.1\u0026lt;/seata.version\u0026gt; \u0026lt;netty4.version\u0026gt;4.1.24.Final\u0026lt;/netty4.version\u0026gt; \u0026lt;/properties\u0026gt; ... \u0026lt;dependencyManagement\u0026gt; \u0026lt;dependencies\u0026gt; ... \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.seata\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;seata-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${seata.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.seata\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;seata-server\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${seata.version}\u0026lt;/version\u0026gt; \u0026lt;exclusions\u0026gt; \u0026lt;exclusion\u0026gt; \u0026lt;groupId\u0026gt;javax.servlet\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;servlet-api\u0026lt;/artifactId\u0026gt; \u0026lt;/exclusion\u0026gt; \u0026lt;/exclusions\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.netty\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;netty-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${netty4.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;/dependencies\u0026gt; \u0026lt;/dependencyManagement\u0026gt; Introduce the following dependencies into the POM file of the stock-mng project (seata-demo-at/stock-mng/pom.","tags":null,"title":"Seata distributed transaction practice","type":"guides","url":"/sofastack.tech/en/guides/kc-seata-demo/","wordcount":1464},{"author":null,"categories":null,"content":"SOFABoot RPC Starter provides a variety of registry center options as well as convenient configurations.\nCurrently, bolt, rest, and dubbo all support Zookeeper as registry center. In addition, bolt and rest support the local file system as registry center, which is generally used for testing.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-usage/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5a1a4619c8ac4a9fc27b8576472aed9f","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-usage/","summary":"SOFABoot RPC Starter provides a variety of registry center options as well as convenient configurations.\nCurrently, bolt, rest, and dubbo all support Zookeeper as registry center. In addition, bolt and rest support the local file system as registry center, which is generally used for testing.","tags":null,"title":"Select Service Registry","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-usage/","wordcount":45},{"author":null,"categories":null,"content":"When using the Bolt communication protocol, SOFARPC can choose different serialization protocols, which can be hessian2 or protobuf currently.\nBy default, SOFARPC uses hessian2 as the serialization protocol. If you need to set the serialization protocol to protobuf, you need to configure the following settings when publishing the service:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; That is to add the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag to the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag and set the serialize-type attribute to protobuf.\nCorrespondingly, when referencing the service, you also need to change the serialization protocol to protobuf. The setting method is similar to publishing the service:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot; jvm-first=\u0026amp;quot;false\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Currently, when you use Annotation for service reference, it is not yet supported to set serialization protocol. But this will be supported in future versions. For details, see ISSUE: https://github.com/sofastack/sofa-boot/issues/278\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/serialization/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"87e2faa84c2c7a7605243dc096bc4e17","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/serialization/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/serialization/","summary":"When using the Bolt communication protocol, SOFARPC can choose different serialization protocols, which can be hessian2 or protobuf currently.\nBy default, SOFARPC uses hessian2 as the serialization protocol. If you need to set the serialization protocol to protobuf, you need to configure the following settings when publishing the service:\n\u0026lt;sofa:service ref=\u0026quot;sampleService\u0026quot; interface=\u0026quot;com.alipay.sofarpc.demo.SampleService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs serialize-type=\u0026quot;protobuf\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:service\u0026gt; That is to add the \u0026lt;sofa:global-attrs\u0026gt; tag to the \u0026lt;sofa:binding.bolt\u0026gt; tag and set the serialize-type attribute to protobuf.","tags":null,"title":"Serialization protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/serialization/","wordcount":138},{"author":null,"categories":null,"content":" Local development Starting SOFARegistry locally is to use the H2 database as the configuration database used by the registry, which can be started directly com.alipay.sofa.registry.server.integration.RegistryApplication#main\nBy default, application-dev.properties will be used as the configuration file\nDeployment The deployment of SOFARegistry relies on mysql, which uses mysql as the metadata storage of the registry itself SOFARegistry supports two types of deployment modes, which are integrated deployment and independent deployment. This topic describes the simplest integrated single-node deployment. For more information about deployment modes, see the Deployment topic.\nDeployment steps 1. Download the source code or installation package Download the source code git clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all Download the installation package You can download the latest registry-all.tgz package from Releases.\nrecommended to download v6 or above\ntar -zxvf registry-all.tgz cd registry-all 2. Start registry-integration 2.1 If you start the development registry locally, you can use h2 as the database\nIDEA source code startup: run com.alipay.sofa.registry.server.integration.RegistryApplication#main\nFat jar script start command: sh bin/start_dev.sh\n2.2 MySQL is recommended for the official environment Create database and table\necho \u0026amp;quot;create database registrymetadb \u0026amp;quot; | mysql -u username -p mysql -u username -p registrymetadb \u0026amp;lt; create_table.sql Modify the configuration in conf/application.properties, the database password can also be passed in through the JDBC_PASSWORD environment variable\nStart command: sh bin/integration/start.sh\n3. Check the running status You can access the healthcheck API provided by these three roles, or view logs/registry-startup.log to check the running status.\n# View the healthcheck API of the meta role: $ curl http://localhost:9615/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... raftStatus:Leader\u0026amp;quot;} # View the healthcheck API of the data role: $ curl http://localhost:9622/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... status:WORKING\u0026amp;quot;} # View the healthcheck API of the session role: $ curl http://localhost:9603/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-registry/server-quick-start/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b620900b56ba04f4668838846a97698a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/server-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/server-quick-start/","summary":"Local development Starting SOFARegistry locally is to use the H2 database as the configuration database used by the registry, which can be started directly com.alipay.sofa.registry.server.integration.RegistryApplication#main\nBy default, application-dev.properties will be used as the configuration file\nDeployment The deployment of SOFARegistry relies on mysql, which uses mysql as the metadata storage of the registry itself SOFARegistry supports two types of deployment modes, which are integrated deployment and independent deployment. This topic describes the simplest integrated single-node deployment.","tags":null,"title":"Server deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/server-quick-start/","wordcount":290},{"author":null,"categories":null,"content":" 本文是关于 MOSN server 配置的说明。\n虽然 MOSN 的配置结构里 servers 是一个 server 数组，但是目前最多只支持配置一个server。\nserver 描述的 MOSN 的基本的全局参数如下所示。\n{ \u0026amp;quot;default_log_path\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;default_log_level\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;global_log_roller\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;graceful_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;processor\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;listeners\u0026amp;quot;:[] } default_log_path 默认的错误日志文件路径，支持配置完整的日志路径，以及标准输出（stdout）和标准错误（stderr）。\n 如果配置为空，则默认输出到标准错误（stderr）。 default_log_level 默认的错误日志级别，支持DEBUG、INFO、WARN、ERROR、FATAL。\n 如果配置为空，则默认为 INFO。 global_log_roller 日志轮转配置，会对所有的日志生效，如 tracelog、accesslog、defaultlog。 字符串配置，支持两种模式的配置，一种是按时间轮转，一种是按日志大小轮转。同时只能有一种模式生效。 按照日志大小轮转\n size， 表示日志达到多少 M 进行轮转。 age，表示最多保存多少天的日志。 keep，表示最多保存多少个日志。 compress，表示日志是否压缩，on 为压缩，off 为不压缩。\n\u0026amp;quot;global_log_roller\u0026amp;quot;: \u0026amp;quot;size=100 age=10 keep=10 compress=off\u0026amp;quot; 按照时间轮转\n time，表示每个多少个小时轮转一次。\n\u0026amp;quot;global_log_roller\u0026amp;quot;:\u0026amp;quot;time=1\u0026amp;quot; graceful_timeout Duration String 的字符串配置，表示 MOSN 在进行平滑升级时，等待连接关闭的最大时间。 如果没有配置，默认为 30s。 processor MOSN 使用的 GOMAXPROCS 数量 - 如果没有配置，默认为 CPU 数量。 - 如果配置为 0，等价于没有配置。\nListeners 一组 Listener 的配置。\n","date":-62135596800,"description":"","dir":"projects/mosn/configuration/server/overview/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3b43981b2aebeca5879d566d8264f6b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/server/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/configuration/server/overview/","summary":"本文是关于 MOSN server 配置的说明。 虽然 MOSN 的配置结构里 servers 是一个 server 数组，但是目前最多只支持配置一个server。 server 描述的 MOSN 的基本的全局参数如下所示。 { \u0026quot;default_log_path\u0026quot;:\u0026quot;\u0026quot;,","tags":null,"title":"Server 配置说明","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/server/overview/","wordcount":528},{"author":null,"categories":null,"content":"If you want to extend a registry center, you should take a look at the abstract classes of the registry center.\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026amp;lt;ProviderConfig\u0026amp;gt; configs); public abstract List\u0026amp;lt;ProviderGroup\u0026amp;gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026amp;lt;ConsumerConfig\u0026amp;gt; configs); } You can see the main necessary interfaces.\nStart the registry client and maintain the connection; Destroy the registry client and release resources; Publish service and cache publish information; Unpublish service and delete cache; Subscribe to service list, return data synchronously or asynchronously, and receive notifications upon changes Unsubscribe service list and delete cache Other interfaces:\nWhen the registry center node is disconnected, the local call is not affected. Switch from one disconnected registry center node to another one by itself. After switching to another registry center node, the system resumes the registration and subscription information automatically. The registry data is cached to the local file. Even if no registry center node is connected, the service provider and caller can restart and call normally. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-extension-guide/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c952ecbea16f7ae68ad095ab8baf0583","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","summary":"If you want to extend a registry center, you should take a look at the abstract classes of the registry center.\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026lt;ProviderConfig\u0026gt; configs); public abstract List\u0026lt;ProviderGroup\u0026gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026lt;ConsumerConfig\u0026gt; configs); } You can see the main necessary interfaces.","tags":null,"title":"Service Registry extension guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/","wordcount":192},{"author":null,"categories":null,"content":" SOFADashboard\u0026amp;rsquo;s service governance mainly manages SOFARPC services.\nConsole The service governance console mainly provides two basic functions: service name query and service information display. When you click the hyperlink of a service ID, you are redirected to the details page of the service.\nService provider details page Service consumer details page ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/governance/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e547baf489fd5d125be9e67a366854b6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/governance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/governance/","summary":" SOFADashboard\u0026rsquo;s service governance mainly manages SOFARPC services.\nConsole The service governance console mainly provides two basic functions: service name query and service information display. When you click the hyperlink of a service ID, you are redirected to the details page of the service.\nService provider details page Service consumer details page ","tags":null,"title":"Service governance","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/governance/","wordcount":51},{"author":null,"categories":null,"content":" The basic configuration for SOFARPC service publishing and reference is described in the \u0026amp;ldquo;Programming Interface\u0026amp;rdquo; chapter. Here are some of the features of service publishing and referencing.\nOne service publishes multiple protocols In SOFARPC, a service can be published as multiple protocols, which allows the callers to call the service provider using different protocols.\nIf you use the Java API, you can build multiple ServerConfigs as follows to set different protocols for different ServerConfigs and then assign these ServerConfigs to ProviderConfig:\nList\u0026amp;lt;ServerConfig\u0026amp;gt; serverConfigs = new ArrayList\u0026amp;lt;ServerConfig\u0026amp;gt;(); serverConfigs.add(serverConfigA); serverConfigs.add(serverConfigB); providerConfig.setServer(serverConfigs); If you use XML, add multiple bindings directly in the \u0026amp;lt;sofa:service\u0026amp;gt; tag:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; If you use annotation, add multiple bindings in @SofaService:\n@SofaService ( interfaceType = SampleService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;), @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) } ) public class SampleServiceImpl implements SampleService { // ... } One service registers multiple registry centers If you use the API, build multiple RegistryConfigs and assign them to ProviderConfig:\nList\u0026amp;lt;RegistryConfig\u0026amp;gt; registryConfigs = new ArrayList\u0026amp;lt;RegistryConfig\u0026amp;gt;(); registryConfigs.add(registryA); registryConfigs.add(registryB); providerConfig.setRegistry(registryConfigs); Method-level parameter settings In the Java API mode, you can set the corresponding parameters by calling the set method of the MethodConfig object, as shown below:\nMethodConfig methodConfigA = new MethodConfig(); MethodConfig methodConfigB = new MethodConfig(); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfigA); methodConfigs.add(methodConfigB); providerConfig.setMethods(methodConfigs); //server settings consumerConfig.setMethods(methodConfigs); //Client settings In the XML mode, you can use the \u0026amp;lt;sofa:method\u0026amp;gt; tag in the corresponding binding to set the corresponding parameters:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;3000\u0026amp;quot; address-wait-time=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Call timeout; address wait time. --\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:22000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Directly connected address --\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;sayName\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- Method level configuration --\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/publish-and-reference/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"6a78b8b84b226eaf1e6d2b1ff1d15fee","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","summary":"The basic configuration for SOFARPC service publishing and reference is described in the \u0026ldquo;Programming Interface\u0026rdquo; chapter. Here are some of the features of service publishing and referencing.\nOne service publishes multiple protocols In SOFARPC, a service can be published as multiple protocols, which allows the callers to call the service provider using different protocols.\nIf you use the Java API, you can build multiple ServerConfigs as follows to set different protocols for different ServerConfigs and then assign these ServerConfigs to ProviderConfig:","tags":null,"title":"Service publishing and reference","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/","wordcount":348},{"author":null,"categories":null,"content":" This document describes the complete SOFARPC service publishing and reference in the SOFABoot environment.\nPublish service \u0026amp;lt;bean id=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloSyncServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; thread-pool-ref=\u0026amp;quot;\u0026amp;quot; warm-up-time=\u0026amp;quot;60000\u0026amp;quot; warm-up-weight=\u0026amp;quot;10\u0026amp;quot; weight=\u0026amp;quot;100\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:binding.rest\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Attribute Name Default value Comment id ID bean名 class Class None ref Service interface implementation class interface Service interface (unique identifier) Use actual interface class for both normal calls and return calls unique-id Service tag (unique identifier) filter Filter configuration alias Separated by commas registry Server registry center Separated by commas timeout Execution timeout period on the server serialize-type Serialization protocol hessian2,protobuf thread-pool-ref Thread pool used by the current interface of the server None weight Service static weight warm-up-weight Service warm-up weight warm-up-time Service warm-up time Unit: millisecond Reference service \u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;helloSyncServiceReference\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026amp;quot; unique-id=\u0026amp;quot;\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs type=\u0026amp;quot;sync\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; address-wait-time=\u0026amp;quot;1000\u0026amp;quot; connect.num=\u0026amp;quot;1\u0026amp;quot; check=\u0026amp;quot;false\u0026amp;quot; connect.timeout=\u0026amp;quot;1000\u0026amp;quot; filter=\u0026amp;quot;\u0026amp;quot; generic-interface=\u0026amp;quot;\u0026amp;quot; idle.timeout=\u0026amp;quot;1000\u0026amp;quot; idle.timeout.read=\u0026amp;quot;1000\u0026amp;quot; lazy=\u0026amp;quot;false\u0026amp;quot; loadBalancer=\u0026amp;quot;\u0026amp;quot; registry=\u0026amp;quot;\u0026amp;quot; retries=\u0026amp;quot;1\u0026amp;quot; serialize-type=\u0026amp;quot;\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;xxx:12200\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; callback-class=\u0026amp;quot;\u0026amp;quot; callback-ref=\u0026amp;quot;\u0026amp;quot; timeout=\u0026amp;quot;3000\u0026amp;quot; type=\u0026amp;quot;sync\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Attribute Name Default value Comment id ID Generated automatically jvm-first Whether to call the service of local machine first true interface Service interface (unique identifier) Use actual interface class for both normal calls and return calls unique-id Service tag (unique identifier) local-first whether refer to the service via jvm call true set it to false if this is to call a remote service via rpc type Calling type sync callback,sync,future,oneway filter Filter configuration alias List registry Server …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/rpc-config-xml-explain/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"4b5110e9eb6cf6c6f287aef0fd210047","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","summary":"This document describes the complete SOFARPC service publishing and reference in the SOFABoot environment. Publish service \u0026lt;bean id=\u0026quot;helloSyncServiceImpl\u0026quot; class=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncServiceImpl\u0026quot;/\u0026gt; \u0026lt;sofa:service ref=\u0026quot;helloSyncServiceImpl\u0026quot; interface=\u0026quot;com.alipay.sofa.rpc.samples.invoke.HelloSyncService\u0026quot; unique-id=\u0026quot;\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:global-attrs registry=\u0026quot;\u0026quot; serialize-type=\u0026quot;\u0026quot; filter=\u0026quot;\u0026quot; timeout=\u0026quot;3000\u0026quot; thread-pool-ref=\u0026quot;\u0026quot; warm-up-time=\u0026quot;60000\u0026quot; warm-up-weight=\u0026quot;10\u0026quot; weight=\u0026quot;100\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;sofa:binding.rest\u0026gt; \u0026lt;/sofa:binding.rest\u0026gt; \u0026lt;/sofa:service\u0026gt; Attribute Name Default value Comment id ID bean名 class Class None ref Service interface implementation class interface Service interface (unique identifier) Use actual interface class for both normal calls","tags":null,"title":"Service publishing and reference in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/","wordcount":356},{"author":null,"categories":null,"content":" Sidecar 模式是 Service Mesh 中习惯采用的模式，是容器设计模式的一种，在 Service Mesh 出现之前该模式就一直存在，本文将为您讲解 Sidecar 模式。\n什么是 Sidecar 模式 将应用程序的功能划分为单独的进程可以被视为 Sidecar 模式。如图所示，Sidecar 模式允许您在应用程序旁边添加更多功能，而无需额外第三方组件配置或修改应用程序代码。\n就像连接了 Sidecar 的三轮摩托车一样，在软件架构中， Sidecar 连接到父应用并且为其添加扩展或者增强功能。Sidecar 应用与主应用程序松散耦合。它可以屏蔽不同编程语言的差异，统一实现微服务的可观察性、监控、日志记录、配置、断路器等功能。\n使用 Sidecar 模式的优势 Sidecar 模式具有以下优势：\n 将与应用业务逻辑无关的功能抽象到共同基础设施降低了微服务代码的复杂度。\n 因为不再需要编写相同的第三方组件配置文件和代码，所以能够降低微服务架构中的代码重复度。\n 降低应用程序代码和底层平台的耦合度。\n Sidecar 模式如何工作 Sidecar 是容器应用模式的一种，也是在 Service Mesh 中发扬光大的一种模式，详见 Service Mesh 架构解析，其中详细描述使用了节点代理和 Sidecar 模式的 Service Mesh 架构。\n使用 Sidecar 模式部署服务网格时，无需在节点上运行代理，但是集群中将运行多个相同的 Sidecar 副本。在 Sidecar 部署方式中，每个应用的容器旁都会部署一个伴生容器，这个容器称之为 Sidecar 容器。Sidecar 接管进出应用容器的所有流量。在 Kubernetes 的 Pod 中，在原有的应用容器旁边注入一个 Sidecar 容器，两个容器共享存储、网络等资源，可以广义的将这个包含了 Sidecar 容器的 Pod 理解为一台主机，两个容器共享主机资源。\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/sidecar-pattern/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"38b45799d69d52f24f26008cd2ad7da5","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/sidecar-pattern/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/concept/sidecar-pattern/","summary":"Sidecar 模式是 Service Mesh 中习惯采用的模式，是容器设计模式的一种，在 Service Mesh 出现之前该模式就一直存在，本文将为您讲解 Sidecar 模式。 什么是 Sidecar 模式 将应用程序的功能划分为","tags":null,"title":"Sidecar 模式","type":"projects","url":"/sofastack.tech/projects/mosn/concept/sidecar-pattern/","wordcount":602},{"author":null,"categories":null,"content":" Since SOFARPC 5.4.0, the link analysis feature of Skywalking is supported. You can use it as needed. The Skywalking must be 6.0.0-alpha and above.\nThis document does not cover the backend deployment. If you need it, please refer to the official Skywalking documentation.\nInstall Java agent Locate the agent directory in the downloaded Skywalking release package.\n Set agent.service_name in config/agent.config, which can be any English character. Generally, it can be your own system name.\n Set the collector.backend_service Skywalking backend address in config/agent.config, which defaults to 127.0.0.1:11800. It is used for local verification.\n Add -javaagent:/path/to/skywalking-package/agenxt/skywalking-agent.jar to the application, which must be placed before the -jar parameter. The skywalking-agent can be gotten in official release package. The new directory structure is as follows:\n+-- agent +-- activations apm-toolkit-log4j-1.x-activation.jar apm-toolkit-log4j-2.x-activation.jar apm-toolkit-logback-1.x-activation.jar ... +-- config agent.config +-- plugins sofa-rpc-plugin-6.0.0-alpha.jar apm-feign-default-http-9.x.jar apm-httpClient-4.x-plugin.jar ..... skywalking-agent.jar Note: Ensure that the plugins/sofa-rpc-plugin-**.jar file exists.\n Start the application. After a period of RPC calls, you can view the UI to observe the calling link.\n More For more relevant documents, please refer to\nSkywalking Agent installation documentation Skywalking Backend deployment documentation\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/skywalking-usage/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3cd5fb45f1b981d0a8c54c8ce43b190b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","summary":"Since SOFARPC 5.4.0, the link analysis feature of Skywalking is supported. You can use it as needed. The Skywalking must be 6.0.0-alpha and above.\nThis document does not cover the backend deployment. If you need it, please refer to the official Skywalking documentation.\nInstall Java agent Locate the agent directory in the downloaded Skywalking release package.\n Set agent.service_name in config/agent.config, which can be any English character. Generally, it can be your own system name.","tags":null,"title":"Skywalking","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/","wordcount":181},{"author":null,"categories":null,"content":" SOFARPC 在5.4.0 及之后的版本中，已经支持 Skywalking 的链路分析的功能，用户可以根据需要进行使用，其中Skywalking 的版本 要求6.0.0-alpha及以上。本文档，不涉及后端的部署，如有需要，可查看 Skywalking 官方文档。\n安装 Java agent 1.在下载的 Skywalking 的release 包中找到 agent 目录。\n2.在config/agent.config 中设置 agent.service_name，可以是任何英文字符，一般可以设置为自己的系统名。\n3.在config/agent.config 中设置 collector.backend_service Skywalking 的后端地址，默认指向 127.0.0.1:11800,这个是为了本地验证的。\n4.给应用程序添加 -javaagent:/path/to/skywalking-package/agenxt/skywalking-agent.jar，其中注意，一定要放在 -jar 参数之前。 Agent 在 kywalking 的 官方 release 包. 新的目录结构如下.\n+-- agent +-- activations apm-toolkit-log4j-1.x-activation.jar apm-toolkit-log4j-2.x-activation.jar apm-toolkit-logback-1.x-activation.jar ... +-- config agent.config +-- plugins sofa-rpc-plugin-6.0.0-alpha.jar apm-feign-default-http-9.x.jar apm-httpClient-4.x-plugin.jar ..... skywalking-agent.jar 注意，确保plugins/sofa-rpc-plugin-**.jar 文件存在。\n5.启动应用程序，经过一段时间RPC调用后，可以查看 UI 来观察链路。\n更多 更多文档请参考\n Skywalking Agent 安装文档 Skywalking Backend 部署文档 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/skywalking-usage/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3cd5fb45f1b981d0a8c54c8ce43b190b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/skywalking-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/skywalking-usage/","summary":"SOFARPC 在5.4.0 及之后的版本中，已经支持 Skywalking 的链路分析的功能，用户可以根据需要进行使用，其中Skywalking 的版本 要求6.0.0-alpha","tags":null,"title":"Skywalking 链路分析","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/skywalking-usage/","wordcount":482},{"author":null,"categories":null,"content":" SOFABoot 提供了模块并行启动以及 Spring Bean 异步初始化能力，用于加快应用启动速度。本文介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力以提高应用启动速度。\n使用场景 在实际使用 Spring/Spring Boot 开发中，一些 Bean 在初始化过程中执行准备操作，如拉取远程配置、初始化数据源等等。在应用启动期间，这些 Bean 会增加 Spring 上下文刷新时间，导致应用启动耗时变长。\n为了加速应用启动，SOFABoot 通过配置可选项，将 Bean 的初始化方法（init-method）使用单独线程异步执行，加快 Spring 上下文加载过程，提高应用启动速度。\n引入依赖 在工程的 pom.xml 文件中，引入如下 starter：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 使用方法 异步初始化 Bean 的原理是开启单独线程负责执行 Bean 的初始化方法（init-method）。因此，除了引入上述依赖，还需要在 Bean 的 XML 定义中配置 async-init=\u0026amp;ldquo;true\u0026amp;rdquo; 属性，用于指定是否异步执行该 Bean 的初始化方法，例如：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- async init test --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBean\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.beans.TimeWasteBean\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot; async-init=\u0026amp;quot;true\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 属性配置 SOFABoot 异步初始化能力提供两个属性配置，用于指定负责异步执行 Bean 初始化方法（init-method）的线程池大小：\n com.alipay.sofa.boot.asyncInitBeanCoreSize：线程池基本大小，默认值为 CPU 核数加一。 com.alipay.sofa.boot.asyncInitBeanMaxSize：线程池中允许的最大线程数大小，默认值为 CPU 核数加一。 此配置可以通过 VM -D 参数或者 Spring Boot 配置文件 application.yml 设置。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/bean-async-init/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1b7c2d94076ffb7ac96f64a557067917","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/bean-async-init/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/bean-async-init/","summary":"SOFABoot 提供了模块并行启动以及 Spring Bean 异步初始化能力，用于加快应用启动速度。本文介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力以提高应用启动速度。 使用场景 在实际使用","tags":null,"title":"Spring Bean 异步初始化","type":"projects","url":"/sofastack.tech/projects/sofa-boot/bean-async-init/","wordcount":578},{"author":null,"categories":null,"content":" 借助 SofaArk 框架，一个普通的 Java 应用可拆分为一个宿主应用（master biz，又称“基座”）与多个业务应用（普通 biz，又称“模块”）的模式，细化研发粒度，以此实现更快速的研发运维。本文将介绍 Spring Boot 应用如何结合 SofaArk 框架，以此构建宿主应用与业务应用。文章由以下七点展开：\n 简介 如何构建 Spring Boot 业务应用 如何构建 Spring Boot 宿主应用 如何执行 Spring Boot 宿主应用 如何执行 Spring Boot 业务应用 多 Host 与单 Host 模式 如何动态卸载 Spring Boot 业务应用 1. 简介 宿主应用（master biz）负责沉淀通用的逻辑，为业务应用提供计算和环境，为业务应用的开发者屏蔽基础设施，更新迭代较慢。各个业务应用（普通 biz）是独立的代码仓库，可以进行独立的研发运维，粒度小，更新迭代较快。业务应用将通用的依赖下沉至宿主应用，依赖宿主应用的环境运行，不是一个 可执行 Jar，因此业务应用自身的 jar 包可以不包含该通用依赖，以此得到轻量化的业务应用 jar 包。\n宿主应用与业务应用的运行关系是：宿主应用首先启动，拥有与普通应用相同的类加载器；业务应用 jar 包以热拔插的模式在宿主应用中动态部署，通用依赖通过宿主应用的类加载器加载，其它依赖使用业务自己的BizClassLoader进行加载。\n本文中宿主应用和业务应用均为 Web 应用，采用了单 host 模式，其样例代码地址如下：\n Spring Boot 宿主应用：Spring Boot 宿主应用 Spring Boot 业务应用：Spring Boot 业务应用 2. 如何构建 Spring Boot 业务应用 业务应用是一种普通 Biz，换而言之，“如何构建业务应用”即为“如何构建普通 Ark Biz”，Ark Biz的介绍请详见Ark Biz。\n2.1 依赖配置 首先，我们需要把业务应用构建成一种 SofaArk 框架可识别的Ark Biz，即：使用Ark Biz打包构建的依赖，配置如下：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;{sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;!-- 建议使用最新版本--\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;skipArkExecutable\u0026amp;gt;true\u0026amp;lt;/skipArkExecutable\u0026amp;gt; \u0026amp;lt;!-- 不生成可执行 fat jar--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!-- 生成的 Ark Biz 所在目录--\u0026amp;gt; \u0026amp;lt;bizName\u0026amp;gt;spring-boot-ark-biz\u0026amp;lt;/bizName\u0026amp;gt; \u0026amp;lt;!-- Ark Biz 名字--\u0026amp;gt; \u0026amp;lt;!-- webContextPath 是单 host 模式下的必要配置，详细配置见 5. 多 host 模式与单 host 模式 --\u0026amp;gt; \u0026amp;lt;webContextPath\u0026amp;gt;biz\u0026amp;lt;/webContextPath\u0026amp;gt; \u0026amp;lt;!-- 同一个host中设置不同的webContextPath--\u0026amp;gt; \u0026amp;lt;!-- declaredMode 开启后，业务应用可以使用自己声明过的、且宿主应用拥有的通用依赖--\u0026amp;gt; \u0026amp;lt;declaredMode\u0026amp;gt;true\u0026amp;lt;/declaredMode\u0026amp;gt; \u0026amp;lt;!-- 使用宿主应用的通用依赖--\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;!-- 此处不使用 spring boot 应用的原有构建依赖--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;plugin\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;!-- \u0026amp;lt;/plugin\u0026amp;gt;--\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 其次，由于业务应用运行时使用宿主应用的通用依赖，因此业务应用需要“排除”通用依赖，即：把 scope 设置成 provided。本样例代码中，业务应用直接使用宿主应用的 spring boot 各项依赖，配置如下：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;provided\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2 打包 首先，使用 maven 打包业务应用，如下：\nmvn clean package -Dmaven.test.skip=true 在之前设定的 outputDirectory 目录下，后缀为ark-biz.jar的包是业务应用的 Ark …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-spring-boot-demo/","fuzzywordcount":3300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa8f11f9f806997290dac0ff5c105ab6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":7,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","summary":"借助 SofaArk 框架，一个普通的 Java 应用可拆分为一个宿主应用（master biz，又称“基座”）与多个业务应用（普通 biz，又称“模块”）的模式，细化研","tags":null,"title":"Spring Boot 应用如何结合 SofaArk","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/","wordcount":3263},{"author":null,"categories":null,"content":" In this document will demonstrate how to use SOFATracer to track of SpringMVC, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026amp;rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.path that specifies the log output directory.\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs Add a simple Controller In the project code, add a simple Controller, for example:\n@RestController public class SampleRestController { private static final String TEMPLATE = \u0026amp;quot;Hello, %s!\u0026amp;quot;; private final AtomicLong counter = new AtomicLong(); /** * http://localhost:8080/springmvc * @param name name * @return map */ @RequestMapping(\u0026amp;quot;/springmvc\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; springmvc(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;SOFATracer SpringMVC DEMO\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; resultMap = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); resultMap.put(\u0026amp;quot;success\u0026amp;quot;, true); resultMap.put(\u0026amp;quot;id\u0026amp;quot;, counter.incrementAndGet()); resultMap.put(\u0026amp;quot;content\u0026amp;quot;, String.format(TEMPLATE, name)); return resultMap; } } Run the project Start Current SOFABoot Application. You will see the log about startup in the console:\n2018-05-11 11:55:11.932 INFO 66490 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcOpenTracingFilter\u0026#39; to urls: [/*] 2018-05-11 11:55:13.961 INFO 66490 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-05-11 11:55:13.970 INFO 66490 --- [ main] c.a.s.t.e.springmvc.DemoApplication : Started DemoApplication in 8.361 seconds (JVM running for 9.34) You can access the REST service by visiting http://localhost:8080/springmvc in your browser. You can see the result similar to the followings:\n{ content: \u0026amp;quot;Hello, SOFATracer SpringMVC DEMO!\u0026amp;quot;, id: 1, success: true } View log In the application.properties, the log printing directory we configured is ./logs, which is the root directory of the current application (we can configure it based on actual situation). In the root directory, you can see log files in the structure similar to the followings:\n./logs ├── spring.log └── tracelog ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log Every time you visit http://localhost:8080/springmvc, SOFATracer will log the digest log. You can open the spring-mvc-digest.log file to see the specific log content. As for the meaning of each output field, you can refer to here.\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-05-17 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-mvc/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"6c6389a6f994f43f08cbdf4a49d1755a","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","summary":"In this document will demonstrate how to use SOFATracer to track of SpringMVC, this example address.\nAssuming you have built a simple Spring Web project based on SOFABoot, Then you can be operated by the following steps:\nIntroduce dependency \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Project Configuration Then, add the parameters to be used by SOFATracer in the project\u0026rsquo;s application.properties file, including spring.application.name that indicates the name of the current application and logging.","tags":null,"title":"Spring MVC Integration","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/","wordcount":356},{"author":null,"categories":null,"content":" SpringMVC Log Format After integrating SpringMVC, SOFATracer will output the link data format of the MVC requests, which is JSON by default.\nSpring MVC digest log (spring-mvc-digest.log) Data is ouput in JSON format. The meaning of each key is as follows:\n Key Meaning Time Log printing time Local.app Current application name traceId TraceId spanId SpanId Request.url Request URL Method Request HTTP method Result.code HTTP return status code req.size.bytes Request body size resp.size.bytes Response body size Time.cost.milliseconds Request time (ms) Current.thread.name Current thread name Baggage Transparently transmitted baggage data Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-06-03 16:44:05.829\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SpringMvcJsonOutput\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;c0a80d9e1528015445828101064625\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:63933/greeting\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:0,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:50,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:1,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-auto-1-exec-10\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring MVC statistical log (spring-mvc-stat.log) stat.key is a collection of statistical keywords in this period., which uniquely determines a set of statistical data, including local.app, request.url, and method field.\n Key Meaning time Log printing time stat.key local.app Current application name request.url Request URL method Request HTTP method count Number of requests in this period total.cost.milliseconds Total duration for (ms) requests in this period success Request result: Y means success (the result code starting with 1 and 2 indicates success, and 302 indicates that the redirection is successful, and others indicate failure); N indicates failure load.test Pressure test mark: T indicates pressure test; F indicates non-pressure test Example:\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-06-03 16:44:02.473\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:63933/greeting\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SpringMvcJsonOutput\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:5,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:149,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;Y\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-springmvc/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"af13acf5aee90a32f0fa143996063a91","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","summary":"SpringMVC Log Format After integrating SpringMVC, SOFATracer will output the link data format of the MVC requests, which is JSON by default.\nSpring MVC digest log (spring-mvc-digest.log) Data is ouput in JSON format. The meaning of each key is as follows:\n Key Meaning Time Log printing time Local.app Current application name traceId TraceId spanId SpanId Request.","tags":null,"title":"Spring MVC log","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/","wordcount":200},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 对 SpringMVC 进行埋点，本示例工程地址。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 工程配置 在工程的 application.properties 文件下添加 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFATracerSpringMVC # logging path logging.path=./logs 添加一个提供 RESTful 服务的 Controller 在工程代码中，添加一个简单的 Controller，例如：\n@RestController public class SampleRestController { private static final String TEMPLATE = \u0026amp;quot;Hello, %s!\u0026amp;quot;; private final AtomicLong counter = new AtomicLong(); /** * http://localhost:8080/springmvc * @param name name * @return map */ @RequestMapping(\u0026amp;quot;/springmvc\u0026amp;quot;) public Map\u0026amp;lt;String, Object\u0026amp;gt; springmvc(@RequestParam(value = \u0026amp;quot;name\u0026amp;quot;, defaultValue = \u0026amp;quot;SOFATracer SpringMVC DEMO\u0026amp;quot;) String name) { Map\u0026amp;lt;String, Object\u0026amp;gt; resultMap = new HashMap\u0026amp;lt;String, Object\u0026amp;gt;(); resultMap.put(\u0026amp;quot;success\u0026amp;quot;, true); resultMap.put(\u0026amp;quot;id\u0026amp;quot;, counter.incrementAndGet()); resultMap.put(\u0026amp;quot;content\u0026amp;quot;, String.format(TEMPLATE, name)); return resultMap; } } 运行 启动 SOFABoot 应用，将会在控制台中看到启动打印的日志：\n2018-05-11 11:55:11.932 INFO 66490 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcOpenTracingFilter\u0026#39; to urls: [/*] 2018-05-11 11:55:13.961 INFO 66490 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 2018-05-11 11:55:13.970 INFO 66490 --- [ main] c.a.s.t.e.springmvc.DemoApplication : Started DemoApplication in 8.361 seconds (JVM running for 9.34) 可以通过在浏览器中输入 http://localhost:8080/springmvc 来访问 REST 服务，结果类似如下：\n{ content: \u0026amp;quot;Hello, SOFATracer SpringMVC DEMO!\u0026amp;quot;, id: 1, success: true } 查看日志 在上面的 application.properties 里面，我们配置的日志打印目录是 ./logs 即当前应用的根目录（我们可以根据自己的实践需要配置），在当前工程的根目录下可以看到类似如下结构的日志文件：\n./logs ├── spring.log └── tracelog ├── spring-mvc-digest.log ├── spring-mvc-stat.log ├── static-info.log └── tracer-self.log 通过访问 http://localhost:8080/springmvc SOFATracer 会记录每一次访问的摘要日志，可以打开 spring-mvc-digest.log 看到具体的输出内容。\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8801-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5006ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/usage-of-mvc/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6c6389a6f994f43f08cbdf4a49d1755a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","summary":"在本文档将演示如何使用 SOFATracer 对 SpringMVC 进行埋点，本示例工程地址。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 依赖引入 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;tracer-sofa-boot-starter\u0026lt;/artifactId\u0026gt;","tags":null,"title":"Spring MVC 埋点接入","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/usage-of-mvc/","wordcount":514},{"author":null,"categories":null,"content":" SOFATracer 集成 SpringMVC 后输出 MVC 请求的链路数据格式，默认为 JSON 数据格式。\nSpring MVC 摘要日志（spring-mvc-digest.log） 以 JSON 格式输出的数据，相应 key 的含义解释如下：\n key 表达含义 time 日志打印时间 local.app 当前应用名 traceId TraceId spanId SpanId span.kind Span 类型 result.code 状态码 current.thread.name 当前线程名 time.cost.milliseconds span 耗时 request.url 请求地址 method http method req.size.bytes 请求大小 resp.size.bytes 响应大小 sys.baggage 系统透传的 baggage 数据 biz.baggage 业务透传的 baggage 数据 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:33:10.336\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9271567477985327100211176\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;server\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8801-exec-2\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;5006ms\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} Spring MVC 统计日志（spring-mvc-stat.log） stat.key 即本段时间内的统计关键字集合，统一关键字集合唯一确定一组统计数据，包含local.app、request.url、和 method 字段.\n key 表达含义 time 日志打印时间 stat.key local.app 当前应用名 request.url 请求 URL method 请求 HTTP 方法 count 本段时间内请求次数 total.cost.milliseconds 本段时间内的请求总耗时（ms） success 请求结果：Y 表示成功(1 开头和 2 开头的结果码算是成功的，302表示的重定向算成功，其他算是失败的)；N 表示失败 load.test 压测标记：T 是压测；F 不是压测 样例：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-03 10:34:04.129\u0026amp;quot;,\u0026amp;quot;stat.key\u0026amp;quot;:{\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;RestTemplateDemo\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8801/asyncrest\u0026amp;quot;},\u0026amp;quot;count\u0026amp;quot;:1,\u0026amp;quot;total.cost.milliseconds\u0026amp;quot;:5006,\u0026amp;quot;success\u0026amp;quot;:\u0026amp;quot;true\u0026amp;quot;,\u0026amp;quot;load.test\u0026amp;quot;:\u0026amp;quot;F\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/log-format-springmvc/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"af13acf5aee90a32f0fa143996063a91","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","summary":"SOFATracer 集成 SpringMVC 后输出 MVC 请求的链路数据格式，默认为 JSON 数据格式。 Spring MVC 摘要日志（spring-mvc-digest.log） 以 JSON 格式输出的数据，相应 key 的","tags":null,"title":"Spring MVC 日志","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/log-format-springmvc/","wordcount":380},{"author":null,"categories":null,"content":" 本文将向您展示 MOSN 的 TLS 安全能力。\n证书方案 MOSN 支持通过 Istio Citadel 的证书签发方案，基于 Istio 社区的 SDS （Secret Discovery Service）方案为 Sidecar 配置证书，支持证书动态发现和热更新能力。为了支持更高级的安全能力，MOSN 没有使用 Citadel 的证书自签发能力，而是通过对接内部 KMS 系统获取证书。同时提供证书缓存和证书推送更新能力。\n我们先来看看 MOSN 证书方案的架构图，如下图所示：\n各组件职能如下：\n Pilot：负责 Policy、SDS 配置下发，为简化复杂度，图中未标出 Citadel：Citadel 作为 Certificate Provider ，同时作为 MCP Server 为 Citadel Agent 提供 Pod、CR等资源 Citadel Agent：提供 SDS Server 服务，为MOSN、DB Sidecar、Security Sidecar 提供Certificate和CR下发能力 KMS：密钥管理系统负责证书签发 证书获取流程 对整体架构有个大致理解后，我们分解下 Sidecar 获取证书的流程，如下图所示：\n补充说明下图中的每一步环节：\n Citadel 与 Citadel agent（nodeagent）组件通过MCP协议（Mesh Configuration Protocol）同步Pod 和 CR 信息，避免 citadel agent 直接请求 API Server 导致 API Server 负载过高 MOSN 通过Unix Domain Socket 方式向 Citadel Agent 发起 SDS 请求 Citadel Agent 会进行防篡改校验，并提取appkey Citadel Agent 携带 appkey 请求 Citadel 签发证书 Citadel 检查证书是否已缓存，如果缓存证书未过期，Citadel 将直接响应缓存证书 证书不在缓存中，Citadel 会基于 appkey 构造证书签发请求，向 KMS 申请签发证书 KMS 会将签发的证书响应回Citadel，另外 KMS 也支持证书过期轮换通知 Citadel 收到证书后，会将证书传递给到对应的 Citadel Agent Citadel Agent 收到证书后，会在内存中缓存证书，并将证书下发给到 MOSN ","date":-62135596800,"description":"","dir":"projects/mosn/concept/tls/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"47ccccf9690bc65fa437463a8f5e55b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/tls/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/concept/tls/","summary":"本文将向您展示 MOSN 的 TLS 安全能力。 证书方案 MOSN 支持通过 Istio Citadel 的证书签发方案，基于 Istio 社区的 SDS （Secret Discovery Service）方案为 Sidecar 配置证书，支持证书","tags":null,"title":"TLS 安全链路","type":"projects","url":"/sofastack.tech/projects/mosn/concept/tls/","wordcount":654},{"author":null,"categories":null,"content":" SOFAArk 容器提供了一个简单的 telnet 服务端小工具，用于运行时查看容器状态，目前支持查看 Plugin 和 Biz 相关信息。\n使用方式 使用 telnet 连接服务端，端口号为 1234， 例如：\n telnet localhost 1234\n 进入交互界面:\n➜ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is \u0026#39;^]\u0026#39;. sofa-ark\u0026amp;gt; sofa-ark\u0026amp;gt; sofa-ark\u0026amp;gt; 目前支持查看 Plugin 和 Biz 相关信息，相关命令可参考提示信息：\nsofa-ark\u0026amp;gt;h Plugin Command Tips: USAGE: plugin [option...] [pluginName...] SAMPLE: plugin -m plugin-A plugin-B -h Shows the help message. -a Shows all plugin name. -m Shows the meta info of specified pluginName. -s Shows the service info of specified pluginName. -d Shows the detail info of specified pluginName. Biz Command Tips: USAGE: biz [option...] [arguments...] SAMPLE: biz -m bizIdentityA bizIdentityB. -h Shows the help message. -a Shows all biz. -m Shows the meta info of specified bizIdentity. -s Shows the service info of specified bizIdentity. -d Shows the detail info of specified bizIdentity. -i Install biz of specified bizIdentity or bizUrl. -u Uninstall biz of specified bizIdentity. -o Switch biz of specified bizIdentity. sofa-ark\u0026amp;gt; Plugin 命令 如提示信息所说，plugin 支持查看插件相关信息，包括类(资源)导入导出配置、插件打包配置等。例如：\nsofa-ark\u0026amp;gt;plugin -md runtime-sofa-boot-plugin PluginName: runtime-sofa-boot-plugin Version: 3.1.3 Priority: 1500 Activator: com.alipay.sofa.runtime.integration.activator.SofaRuntimeActivator Export Packages: com.alipay.sofa.runtime.api.*,com.alipay.sofa.runtime.client.*,com.alipay.sofa.runtime.component.*,com.alipay.sofa.runtime.constants.*,com.alipay.sofa.runtime.integration.*,com.alipay.sofa.runtime.model.*,com.alipay.sofa.runtime.service.component,com.alipay.sofa.runtime.service.helper,com.alipay.sofa.runtime.spi.client,com.alipay.sofa.runtime.spi.component,com.alipay.sofa.runtime.spi.health,com.alipay.sofa.runtime.spi.log,com.alipay.sofa.runtime.spi.binding,com.alipay.sofa.runtime.spi.util,org.aopalliance.aop,org.aopalliance.intercept Import Packages: \\ Export Classes: com.alipay.sofa.runtime.service.binding.JvmBinding,com.alipay.sofa.runtime.SofaFramework,com.alipay.sofa.runtime.SofaRuntimeProperties,com.alipay.sofa.runtime.service.binding.JvmBindingParam,com.alipay.sofa.runtime.spi.service.ServiceProxy Import Classes: \\ Export Resources: \\ Import Resources: \\ GroupId: com.alipay.sofa ArtifactId: runtime-sofa-boot-plugin Version: 3.1.3 URL: jar:file:/Users/qilong.zql/.m2/repository/com/alipay/sofa/runtime-sofa-boot-plugin/3.1.3/runtime-sofa-boot-plugin-3.1.3.jar!/ ClassLoader: com.alipay.sofa.ark.container.service.classloader.PluginClassLoader@420a63fb ClassPath: …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-telnet/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f23d585e5439569b47ed83f7bc955b22","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","summary":"SOFAArk 容器提供了一个简单的 telnet 服务端小工具，用于运行时查看容器状态，目前支持查看 Plugin 和 Biz 相关信息。 使用方式 使用 telnet 连接服务端，端口号为 1234， 例如：","tags":null,"title":"Telnet 指令","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/","wordcount":513},{"author":null,"categories":null,"content":" Ark package The Executed Fat Jar that meets the specific directory format requirements can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package the engineering application into a standard-format Ark package. Start the application on top of the SOFAArk container with the java -jar command. The Ark package usually contains the Ark Container, Ark Plugin dependency (if any), merged deployed Ark Biz (if any), and the Ark Biz of the application itself. For details, refer to the Ark package；\nArk Container The Ark container (Ark Plugin and Ark Biz) runs on top of the SOFAArk container. The container has the ability to manage multiple plug-ins and applications. After successful start, the container will resolve the configuration of Ark Plugin and Ark Biz, complete loading of the isolation and start them in turn based on their priorities. For details, refer to SOFAArk container startup；\nArk Plugin The Ark plug-in, which meets the specific fat jar directory format requirements, can use the officially provided Maven plug-in (sofa-Ark-plugin-maven-plugin) to package one or multiple common Java Jar packages into a standard-format Ark Plugin. Ark Plugin will contain a configuration file that usually contains the import and export configuration of plug-in classes and resources and the priority of plug-in startup. When running, the Ark container will use an independent PluginClassLoader to load the plug-ins, and build the index table for class loading according to the plug-in configuration, so that the plug-ins are isolated from each other and from the applications. For details, refer to Ark Plugin；\nArk Biz The Ark module, which meets the specific fat jar directory format requirements, can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package an engineering application into a standard-format Ark Biz package. The Ark Biz package has two roles: one is to be the organizational unit of the engineering application module and its dependent packages, and the other is to be used as a common jar package dependency by other applications to start multiple Ark Biz packages in the same SOFAArk container. Multiple Ark Biz packages share the Ark Container and Ark Plugin. For details, refer to Ark Biz；\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-terminology/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b6d0ed10afe9d04bc00307017ffba7c5","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","summary":"Ark package The Executed Fat Jar that meets the specific directory format requirements can use the officially provided Maven plug-in (sofa-Ark-maven-plugin) to package the engineering application into a standard-format Ark package. Start the application on top of the SOFAArk container with the java -jar command. The Ark package usually contains the Ark Container, Ark Plugin dependency (if any), merged deployed Ark Biz (if any), and the Ark Biz of the application itself.","tags":null,"title":"Terminologies","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/","wordcount":351},{"author":null,"categories":null,"content":" Explanation of Terms Terminology Description TraceId TraceId refers to the ID that represents the unique request in SOFATracer. This ID is generally generated by the first system in the cluster that processes the request and is passed over the network to the next requested system in distributed calls. SpanId SpanId represents the location or level of the request in the entire call link. For example, the system A calls system B, C, and D in sequence when processing a request. Then the SpanId of the three calls are respectively: 0.1, 0.2, 0.3. If system B continues to call system E and F, the SpanIds of the two calls are: 0.1.1, 0.1.2. For other related terminologies, see OpenTracing specification.\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/explanation/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"8ba307b0679e918f7ac68c7efb7e53f7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/explanation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/explanation/","summary":"Explanation of Terms Terminology Description TraceId TraceId refers to the ID that represents the unique request in SOFATracer. This ID is generally generated by the first system in the cluster that processes the request and is passed over the network to the next requested system in distributed calls. SpanId SpanId represents the location or level of the request in the entire call link.","tags":null,"title":"Terminologies","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/explanation/","wordcount":118},{"author":null,"categories":null,"content":" General terminology Term Description Service A software function provided over the network with specific business logic processing capabilities. Service provider A computer node that provides services over the network. Service consumer A computer node that receives services through the network. The same computer node can both be the service provider of some services and the service consumer of others. Service discovery The process in which the service consumer obtains the network address of the service provider. Service registry A software system that provides service discovery functions to help service consumers obtain network addresses of service providers. Data center An independent physical area with a fixed physical location, stable power supply, and reliable network. A data center is usually an important factor that you want to consider in high availability design. Generally, deployment in the same data center features higher network quality, lower latency, but limited disaster recovery capability. However, deployment across different data centers features lower network quality, higher latency, but better disaster recovery capability. SOFARegistry terminology Terminology Description SOFARegistry A registry product open sourced by Ant Financial to provide service discovery based on the \u0026amp;ldquo;publishing-subscription\u0026amp;rdquo; mode. In addition to service discovery, SOFARegistry is applicable to more general \u0026amp;ldquo;publishing-subscription\u0026amp;rdquo; scenarios. Data In the context of service discovery, data specifically refers to the network address and some additional information of the service provider. In other circumstances, it also refers to information published to SOFARegistry. Zone The key concept of the zone-based architecture. In the context of service discovery, a zone is a collection of publishing and subscription requests. When you publish or subscribe to a service, you need to specify the zone name. For more information, see Active geo-redundant zone-based architecture solution. Publisher A node that publishes data to SOFARegistry. In the context of service discovery, the service provider is the publisher of the \u0026amp;ldquo;service provider\u0026amp;rsquo;s network address and additional information\u0026amp;rdquo;. Subscriber A node that subscribes to data from SOFARegistry. In the context of service discovery, the service consumer is the subscriber of the \u0026amp;ldquo;service provider\u0026amp;rsquo;s network address and additional information\u0026amp;rdquo;. Data ID A string that is used to identify the data. In the context of service discovery, DataId usually consists of the service port name, protocol, and version number. It is used as an identifier of the service. Group ID A string that is used for grouping data. It can be used in conjunction with DataId and InstanceId as a namespace identifier of data. Two services may be considered one same service only when their DataIds, GroupIds, and InstanceIds are identical. Instance ID A …","date":-62135596800,"description":"","dir":"projects/sofa-registry/terminology/","fuzzywordcount":600,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b678a49547c55f2a70e2d94dbce5b4a2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/terminology/","summary":"General terminology Term Description Service A software function provided over the network with specific business logic processing capabilities. Service provider A computer node that provides services over the network. Service consumer A computer node that receives services through the network. The same computer node can both be the service provider of some services and the service consumer of others.","tags":null,"title":"Terminology","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/terminology/","wordcount":508},{"author":null,"categories":null,"content":" Unit test Place the unit test cases in the modules developed by yourself.\nIf the cases rely on a third-party server (such as ZooKeeper), you must manually add the profile. See the registry-zookeeper module code.\nIf the cases rely on other modules and integration test is required, place them in the test/test-intergrated module.\nIf the cases also rely on a third-party server (such as ZooKeeper), place them in the test-intergrated-3rd module.\nPerformance test Close the following projects that are closed by default:\n-Dcontext.attachment.enable=false -Dserialize.blacklist.enable=false -Ddefault.tracer= -Dlogger.impl=com.alipay.sofa.rpc.log.SLF4JLoggerImpl -Dmultiple.classloader.enable=false -Devent.bus .enable=false\nA pressure test on BOLT+hessian has been done.\n Server: 4C8G virtual machine; gigabit network; jdk1.8.0_111;\n Client: 50 concurrent requests\n Protocol Request Response Server TPS Average RT (ms) bolt+hessian 1KB string 1KB string Directly return 10000 1.93 bolt+hessian 1KB string 1KB string Directly return 20000 4.13 bolt+hessian 1KB string 1KB string Directly return 30000 7.32 bolt+hessian 1KB string 1KB string Directly return 40000 15.78 bolt+hessian 1KB string 1KB string Directly return 50000 (Close to the utmost limit, error rate: 0.3%) 26.51 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/test/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ccda7c2372a7f55d61f682b72d3b1dc2","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/test/","summary":"Unit test Place the unit test cases in the modules developed by yourself.\nIf the cases rely on a third-party server (such as ZooKeeper), you must manually add the profile. See the registry-zookeeper module code.\nIf the cases rely on other modules and integration test is required, place them in the test/test-intergrated module.\nIf the cases also rely on a third-party server (such as ZooKeeper), place them in the test-intergrated-3rd module.","tags":null,"title":"Test","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/test/","wordcount":169},{"author":null,"categories":null,"content":" When using the Bolt protocol for communication, invoke timeout defaults is 3 seconds. You can configure the timeout when referencing the service, and can also configure the timeout period from the dimension of service or method respectively. SOFARPC timeout can be set in milliseconds.\nService If you need to set the timeout from the dimension of service when publishing a service, just configure the timeout parameter to the corresponding value.\nUse XML If you reference the service using XML, set the value of the timeout attribute of the \u0026amp;lt;sofa:global-attrs\u0026amp;gt; tag under the \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; tag:\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation If you reference the service using Annotation, set the value of the timeout attribute of @SofaReferenceBinding:\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, timeout = 2000)) private SampleService sampleService; Use API in Spring environment If you reference the service in Spring or Spring Boot environment, just set the value of timeout attribute of BoltBindingParam:\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setTimeout(2000) Use API in non-Spring environment If you reference service using the bare API of SOFARPC directly in non-Spring environment, just set the timeout attribute of ConsumerConfig:\nConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;SampleService\u0026amp;gt;() .setInterfaceId(SampleService.class.getName()) .setRegistry(registryConfig) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;) .setTimeout(2000); Method If you want to adjust the timeout for a certain method in a service individually, you can set the timeout period from the dimension of method.\nFor a method, the timeout period of the method is prioritized. If not set, the timeout period of the service will be used.\nUse XML If you reference service using XML, just set the timeout attribute of the corresponding \u0026amp;lt;sofa: method\u0026amp;gt;:\n\u0026amp;lt;Sofa: Reference interface = \u0026amp;quot;com.example.demo .SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:method name=\u0026amp;quot;hello\u0026amp;quot; timeout=\u0026amp;quot;2000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Use Annotation No method is available for setting the method-level timeout with Annotation currenty.\nUse API in Spring environment To reference a service in Spring or Spring Boot environment, you can just set the value of timeout attribute of RpcBindingMethodInfo\nBoltBindingParam boltBindingParam = new BoltBindingParam(); RpcBindingMethodInfo rpcBindingMethodInfo = new RpcBindingMethodInfo(); rpcBindingMethodInfo.setName(\u0026amp;quot;hello\u0026amp;quot;); rpcBindingMethodInfo.setTimeout(2000); List\u0026amp;lt;RpcBindingMethodInfo\u0026amp;gt; rpcBindingMethodInfos = new ArrayList\u0026amp;lt;\u0026amp;gt;(); …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/bolt-timeout/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"cf14f73dc0c4672a9255ef55b56de419","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","summary":"When using the Bolt protocol for communication, invoke timeout defaults is 3 seconds. You can configure the timeout when referencing the service, and can also configure the timeout period from the dimension of service or method respectively. SOFARPC timeout can be set in milliseconds.\nService If you need to set the timeout from the dimension of service when publishing a service, just configure the timeout parameter to the corresponding value.","tags":null,"title":"Timeout control","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/","wordcount":388},{"author":null,"categories":null,"content":" TraceId generation rule SOFATracer uses TraceId to concatenate the call logs of a request on each server. The TraceId is typically generated by the first server that receives the request. The generation rule is: server IP + generated time + incremental sequence + current process ID, such as:\n0ad1348f1403169275002100356696 The first 8 digits 0ad1348f is the IP of the machine that generates TraceId. This is a hexadecimal number, in which every two digits represents a part of IP. Based on the number, we can get a common IP address like 10.209.52.143 by converting every two digits into a decimal number. According to this rule, you can also figure out the first server that the request goes through. The next 13 digits 1403169275002 is the time to generate the TraceId. The next 4 digits 1003 is an auto-incrementing sequence that increases from 1000 to 9000. After reaching 9000, it returns to 1000 and then restarts to increase. The last 5 digits 56696 is the current process ID. Its role in tracerId is to prevent the TraceId conflicts caused by multiple processes in a single machine. Currently, TraceId\u0026amp;rsquo;s generated rules refer to Taobao\u0026amp;rsquo;s Hawkeye components.\n SpanId generation rule The SpanId in SOFATracer represents where the current call is in the entire calling link. If a Web system A receives a user request, then in the SOFATracer MVC log of this system, the recorded SpanId is 0, which means the root node of the entire call. If the system A processes this request and needs to call system B, C, and D through RPC, then the SpanIds in the SOFATracer RPC client log of system A are 0.1, 0.2, and 0.3 respectively. And in the SOFATracer RPC server logs of the system B, C, and D, the SpanIds are also 0.1, 0.2 and 0.3 respectively. If system C calls system E and F when processing the request, then in the corresponding SOFATracer RPC client log of system C, the SpanIds are 0.2.1 and 0.2.2. And the SpanIds in the SOFATracer RPC server logs of system E and F are also 0.2.1 and 0.2.2. As we can known from above, if all SpanIds in a call can be collected to compose a complete link tree.\nWe assume that the TraceId generated in a distributed call is 0a1234 (much longer in practice). Then, according to the generation process of SpanId, the call link tree is as shown in the following figure:\n Currently, SpanId\u0026amp;rsquo;s generated rules refer to Taobao\u0026amp;rsquo;s Hawkeye components.\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/traceid-generated-rule/","fuzzywordcount":500,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"8f0ef8df65deec2a4fa6591a316aa5e8","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","summary":"TraceId generation rule SOFATracer uses TraceId to concatenate the call logs of a request on each server. The TraceId is typically generated by the first server that receives the request. The generation rule is: server IP + generated time + incremental sequence + current process ID, such as:\n0ad1348f1403169275002100356696 The first 8 digits 0ad1348f is the IP of the machine that generates TraceId. This is a hexadecimal number, in which every two digits represents a part of IP.","tags":null,"title":"TraceId and spanId generation rule","type":"projects","url":"/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/","wordcount":415},{"author":null,"categories":null,"content":" TraceId 生成规则 SOFATracer 通过 TraceId 来将一个请求在各个服务器上的调用日志串联起来，TraceId 一般由接收请求经过的第一个服务器产生，产生规则是： 服务器 IP + 产生 ID 时候的时间 + 自增序列 + 当前进程号 ，比如：\n0ad1348f1403169275002100356696 前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，大家也可以根据这个规律来查找到请求经过的第一个服务器。 后面的 13 位 1403169275002 是产生 TraceId 的时间。 之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。 最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。\n TraceId 目前的生成的规则参考了阿里的鹰眼组件。\n SpanId 生成规则 SOFATracer 中的 SpanId 代表本次调用在整个调用链路树中的位置，假设一个 Web 系统 A 接收了一次用户请求，那么在这个系统的 SOFATracer MVC 日志中，记录下的 SpanId 是 0，代表是整个调用的根节点，如果 A 系统处理这次请求，需要通过 RPC 依次调用 B，C，D 三个系统，那么在 A 系统的 SOFATracer RPC 客户端日志中，SpanId 分别是 0.1，0.2 和 0.3，在 B，C，D 三个系统的 SOFATracer RPC 服务端日志中，SpanId 也分别是 0.1，0.2 和 0.3；如果 C 系统在处理请求的时候又调用了 E，F 两个系统，那么 C 系统中对应的 SOFATracer RPC 客户端日志是 0.2.1 和 0.2.2，E，F 两个系统对应的 SOFATracer RPC 服务端日志也是 0.2.1 和 0.2.2。根据上面的描述，我们可以知道，如果把一次调用中所有的 SpanId 收集起来，可以组成一棵完整的链路树。\n我们假设一次分布式调用中产生的 TraceId 是 0a1234（实际不会这么短），那么根据上文 SpanId 的产生过程，有下图：\n SpanId 目前的生成的规则参考了阿里的鹰眼组件。\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/traceid-generated-rule/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8f0ef8df65deec2a4fa6591a316aa5e8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","summary":"TraceId 生成规则 SOFATracer 通过 TraceId 来将一个请求在各个服务器上的调用日志串联起来，TraceId 一般由接收请求经过的第一个服务器产生，产生规则是： 服务器 IP + 产","tags":null,"title":"TraceId 和 SpanId 生成规则","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/","wordcount":707},{"author":null,"categories":null,"content":"By default, SOFARPC has integrated SOFATracer. Also, you can use other APM products, such as Skywalking, to achieve the corresponding functions. For details, see the relevant documents:\n SOFATracer Skywalking If you want to disable the tracing ability of SOFARPC, you can do it in two ways.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment, you can add a configuration com.alipay.sofa.rpc.defaultTracer= in application.properties.\nIf you are using sofa-rpc-all directly, you can add the following code in the main method of your application before publish any SOFARPC service or create any SOFARPC reference.\nRpcConfigs.putValue(RpcOptions.DEFAULT_TRACER, \u0026amp;quot;\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/tracing-usage/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"5f944f87d827ae060fb0528f6715af97","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","summary":"By default, SOFARPC has integrated SOFATracer. Also, you can use other APM products, such as Skywalking, to achieve the corresponding functions. For details, see the relevant documents:\n SOFATracer Skywalking If you want to disable the tracing ability of SOFARPC, you can do it in two ways.\nIf you are using rpc-sofa-boot-starter in SOFABoot or Spring Boot environment, you can add a configuration com.alipay.sofa.rpc.defaultTracer= in application.properties.\nIf you are using sofa-rpc-all directly, you can add the following code in the main method of your application before publish any SOFARPC service or create any SOFARPC reference.","tags":null,"title":"Tracing","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/tracing-usage/","wordcount":96},{"author":null,"categories":null,"content":" Use client API In the design of SOFALookout client, API is decoupled from the implementation. If you need to log the events based on the SOFALookout API, you only need to add the lookout-api Maven dependency to the pom.xml file in your application/project. If the dependencies (such as client dependencies or SOFABoot (Spring Boot) Starter) do not exist, the API package uses NoopRegistry automatically, to replace all the locations of which the events are logged.\n1.Introduce API dependency \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.About ID Compared to the traditional metrics library\u0026amp;rsquo;s single-dimensional information description, Lookout metrics provides tag capability that supports multi-dimensional descriptions. ID class, the unique identification of Lookout metrics, consists of name and tags.\nId basicId = registry.createId(\u0026amp;quot;rpc.provider.service.stats\u0026amp;quot;); id = basicId.withTag(\u0026amp;quot;service\u0026amp;quot;, \u0026amp;quot;com.alipay.demo.demoService\u0026amp;quot;) .withTag(\u0026amp;quot;method\u0026amp;quot;, \u0026amp;quot;sayHi\u0026amp;quot;) .withTag(\u0026amp;quot;protocol\u0026amp;quot;, \u0026amp;quot;tr\u0026amp;quot;) .withTag(\u0026amp;quot;alias\u0026amp;quot;, \u0026amp;quot;group1\u0026amp;quot;); The above is a simple example of ID introducing how to create ID and how to tag. Note that every time you tag, a new ID object is generated and returned.\n Do not proactively cache Id or the specific Metric object, since Lookout\u0026amp;rsquo;s Registry has already recorded. When using a same Id (with the same name and tags), the existing Id and its corresponding Metric object will be reused.\n 2.1 Priority tag (optional) PRIORITY enumeration level: HIGH, NORMAL, LOW.\nid.withTag(LookoutConstants.LOW_PRIORITY_TAG); It is recommended that you do not add this tag, the default level will be NORMAL. The level represents the collection interval (HIGH: 2s, NORMAL: 30s, LOW: 1min).\n2.2 About tags General tags, such as local IP, data center, and other details, will be attached and no need to be specified separately. In a non-SOFABoot project, you must manually add tags to the client, especially the app tag which specifies the app name: app=appName. key contains only lowercase letters, numbers, and underscores. (especially the metrics at runtime, such as Counter, Timer, and DistributeSummary) The values ​​of a tag shall be within a stable finite set. Try to use as few tags as possible to prevent the number of metrics from exceeding the maximum limit. For example: In RPC service, the value of method\u0026amp;rsquo;s two tags shall be as few as possible. The counterexample is that each RPC call has a separate tag-value. Therefore, the overall principle is that there should be as few custom tags as possible, and the number of sets of the values ​​should be as small as possible. Specialized TAG name \u0026amp;ldquo;priority\u0026amp;rdquo; indicates priority. The tag key reserved by the system is _*_. Starting with an underscore and ending with an …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-api/","fuzzywordcount":1000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"76574f2435a3565fe1fc50831ff9ab0c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","summary":"Use client API In the design of SOFALookout client, API is decoupled from the implementation. If you need to log the events based on the SOFALookout API, you only need to add the lookout-api Maven dependency to the pom.xml file in your application/project. If the dependencies (such as client dependencies or SOFABoot (Spring Boot) Starter) do not exist, the API package uses NoopRegistry automatically, to replace all the locations of which the events are logged.","tags":null,"title":"Use API","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-api/","wordcount":911},{"author":null,"categories":null,"content":" SOFARPC Service publishing The process of service publishing involves three classes RegistryConfig, ServerConfig, ProviderConfig.\n RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;) RegistryConfig represents the registry center. As above, the address and port of the service registry center is 127.0.0.1:2181, and the protocol is Zookeeper.\n ServerConfig java ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ServerConfig represents the container where service runs. The above declares a server using the 8803 port and the bolt protocol.\n ProviderConfig\nProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt;() .setInterfaceId(HelloWorldService.class.getName()) .setRef(new HelloWorldServiceImpl()) .setServer(serverConfig) .setRegistry(registryConfig); providerConfig.export(); ProviderConfig represents service publishing. The above declares the interface of the service, implements the server running the service, and eventually publishes the service by the export method.\nService reference Service reference involves two classes, namely RegistryConfig and ConsumerConfig.\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig); HelloService helloService = consumerConfig.refer(); ConsumerConfig represents service reference. The above declares the interface and service registry center of the referenced service interface, and finally references the service by the refer method to get the proxy for the remote call of the service.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-rpc/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"ee6f74a4974c7abf72322cef108d5ef0","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","summary":"SOFARPC Service publishing The process of service publishing involves three classes RegistryConfig, ServerConfig, ProviderConfig.\n RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026quot;zookeeper\u0026quot;) .setAddress(\u0026quot;127.0.0.1:2181\u0026quot;) RegistryConfig represents the registry center. As above, the address and port of the service registry center is 127.0.0.1:2181, and the protocol is Zookeeper.\n ServerConfig java ServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026quot;bolt\u0026quot;); ServerConfig represents the container where service runs. The above declares a server using the 8803 port and the bolt protocol.","tags":null,"title":"Use API in non-Spring environment","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-rpc/","wordcount":173},{"author":null,"categories":null,"content":" This article describes how to quickly start installing and configuring Istio by using Docker Compose.\nSOFAMosn can not only support the standard Istio deployment mode, but also support the unilateral Inbound Sidecar or Outbound Sidecar deployment mode to meet the various requirements of users.\nPrerequisites Docker Docker Compose Install Istio Download the latest release package. Unzip the installation file and go to the decompressed path. The installation path contains: Sample application path samples/. The istioctl client executable file which is in the /bin path. The istioctl can be used to create routing rules and policies. Configuration file istion.VERSION. Add the Istio\u0026amp;rsquo;s bin path to your system\u0026amp;rsquo;s PATH. For example, execute the following command in the MacOS or Linux operating system:\nexport PATH=$PWD/bin;$PATH Pull up the Istio control plane container: SHELL docker-compose -f install/zookeeper/istio.yaml up -d Ensure that all Docker containers are running:\ndocker ps -a If the Istio pilot container terminates unexpectedly, you can run the istioctl context-create command and re-execute the previous command. 6. Configure istioctl to use the Istio API server:\nistioctl context-create -context istio-local --api-server Deploy application Now, you can start deploying the SOFABoot demo program. The demo program includes a client and a server, which communicate with each other through Bolt protocol.\ndocker-compose up -f sofa-sample-spec.yaml up -d Uninstall Istio docker-compose up -f install/zookeeper/istio.yaml down ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"1de4868fa0e9c73d932343847864d7fb","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","summary":"This article describes how to quickly start installing and configuring Istio by using Docker Compose.\nSOFAMosn can not only support the standard Istio deployment mode, but also support the unilateral Inbound Sidecar or Outbound Sidecar deployment mode to meet the various requirements of users.\nPrerequisites Docker Docker Compose Install Istio Download the latest release package. Unzip the installation file and go to the decompressed path. The installation path contains: Sample application path samples/.","tags":null,"title":"Use Docker to get started with Istio","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","wordcount":219},{"author":null,"categories":null,"content":" Introduction This section is intended to demonstrate how to use Jarslink 2.0 to dynamically control the life cycle of the Biz package and to complete its installation, uninstallation, and query.\nDemo With reference to How to reform common Spring Boot applications, the reformed spring-boot-transform-sample project has integrated the Jarslink 2.0 component. By executing the Ark package that the application packaged and generated, you can dynamically install or uninstall the application during its running.\n java -jar starts the spring-boot-transform-sample application Ark package. telnet localhost 1234 enters the Jarslink 2.0 command interface, as follows:\n\u0026amp;gt; telnet localhost 1234 s \u0026amp;gt; Trying 127.0.0.1\u0026amp;hellip;\n\u0026amp;gt; Connected to localhost.\n\u0026amp;gt; Escape character is \u0026amp;lsquo;^]\u0026amp;rsquo;.\n\u0026amp;gt; sofa-ark\u0026amp;gt; Execute the check -b query command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=1\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt; With reference to How to reform a common Spring Boot application, create any SOFABoot application of non-Web type, package it into a Biz package, and execute the install -b installation command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;install -b file:///Users/qilong.zql/Desktop/test-ark-biz.jar\n\u0026amp;gt; Biz:\u0026amp;lsquo;test-biz:1.0.0\u0026amp;rsquo; is installing. \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the check -b query command again, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=2\n\u0026amp;gt; bizName=\u0026amp;lsquo;test-biz\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo;\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the uninstall -b -n -v uninstallation command, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;uninstall -b -n test-biz -v 1.0.0\n\u0026amp;gt; Uninstall biz:\u0026amp;lsquo;test-biz:1.0.0\u0026amp;rsquo; success. \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n Execute the check -b query command again, and the result is as follows: \u0026amp;gt; sofa-ark\u0026amp;gt;check -b\n\u0026amp;gt; Biz count=1\n\u0026amp;gt; bizName=\u0026amp;lsquo;spring-boot-transform-sample\u0026amp;rsquo;, bizVersion=\u0026amp;lsquo;1.0.0\u0026amp;rsquo;, bizState=\u0026amp;lsquo;activated\u0026amp;rsquo; \u0026amp;gt; \u0026amp;gt; sofa-ark\u0026amp;gt;\n For use of more commands, refer to Interactive Commands.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"749f6debe73b73b4882477779008bb99","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","summary":"Introduction This section is intended to demonstrate how to use Jarslink 2.0 to dynamically control the life cycle of the Biz package and to complete its installation, uninstallation, and query.\nDemo With reference to How to reform common Spring Boot applications, the reformed spring-boot-transform-sample project has integrated the Jarslink 2.0 component. By executing the Ark package that the application packaged and generated, you can dynamically install or uninstall the application during its running.","tags":null,"title":"Use Jarslink for multi-application dynamic deployment","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/","wordcount":277},{"author":null,"categories":null,"content":" This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio. Serving as a critical component of SOFAMesh, MOSN is used to complete data plane forwarding.\nThe following figure shows the workflow chart of MOSN based on the overall SOFAMesh framework.\nNote: Currently, MOSN cannot be directly used in the native Istio.\nPreparations This guide supposes you are using macOS. For other operating systems, you can install the corresponding software.\n1. Install HyperKit Install docker-for-mac, and then install driver.\n1.1 Install Docker Download the Docker software package to install it or run the following command to install it:\n$ brew cask install docker 1.2 Install driver $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. Install Minikube (or purchase the commercial version of k8s cluster) It is recommended to use Minikube V0.28 or later, see https://github.com/kubernetes/minikube.\n$ brew cask install minikube 3. Start Minikube Note that Pilot requires at least 2G memory, so you can add resources to Minikube by adding parameters at startup. If your machine has insufficient resources, it is recommended to use the commercial version of the k8s cluster.\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit Create Istio namespace\n$ kubectl create namespace istio-system 4. Install kubectl command line tool kubectl is a command line interface used to run commands for k8s cluster. For how to install it, see https://kubernetes.io/docs/tasks/tools/install-kubectl.\n$ brew install kubernetes-cli 5. Install Helm Helm is a package management tool for k8s. For how to install it, see https://docs.helm.sh/using_helm/#installing-helm.\n$ brew install kubernetes-helm Deploy SOFAMesh with source codes 1. Download SOFAMesh source codes $ git clone git@github.com:sofastack/sofa-mesh.git 2. Use Helm to install SOFAMesh You should change directory to sofa-mesh source code, and then use helm template to install isito crd and istio\n``` $ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template …","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-with-sofamesh/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"9c6461e92180417d3a8ec4f3f2c723fe","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","summary":"This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio.","tags":null,"title":"Use MOSN to build Service Mesh platform","type":"projects","url":"/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/","wordcount":1078},{"author":null,"categories":null,"content":" This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio. Serving as a critical component of SOFAMesh, MOSN is used to complete data plane forwarding.\nThe following figure shows the workflow chart of MOSN based on the overall SOFAMesh framework.\nNote: Currently, MOSN cannot be directly used in the native Istio.\nPreparations This guide supposes you are using macOS. For other operating systems, you can install the corresponding software.\n1. Install HyperKit Install docker-for-mac, and then install driver.\n1.1 Install Docker Download the Docker software package to install it or run the following command to install it:\n$ brew cask install docker 1.2 Install driver $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. Install Minikube (or purchase the commercial version of k8s cluster) It is recommended to use Minikube V0.28 or later, see https://github.com/kubernetes/minikube.\n$ brew cask install minikube 3. Start Minikube Note that Pilot requires at least 2G memory, so you can add resources to Minikube by adding parameters at startup. If your machine has insufficient resources, it is recommended to use the commercial version of the k8s cluster.\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit Create Istio namespace\n$ kubectl create namespace istio-system 4. Install kubectl command line tool kubectl is a command line interface used to run commands for k8s cluster. For how to install it, see https://kubernetes.io/docs/tasks/tools/install-kubectl.\n$ brew install kubernetes-cli 5. Install Helm Helm is a package management tool for k8s. For how to install it, see https://docs.helm.sh/using_helm/#installing-helm.\n$ brew install kubernetes-helm Deploy SOFAMesh with source codes 1. Download SOFAMesh source codes $ git clone git@github.com:sofastack/sofa-mesh.git 2. Use Helm to install SOFAMesh You should change directory to sofa-mesh source code, and then use helm template to install isito crd and istio\n``` $ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template …","date":-62135596800,"description":"","dir":"projects/occlum/quick-start-run-with-sofamesh/","fuzzywordcount":1100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"7353dfd1d668eb3e2a1c8cd26acca372","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","summary":"This article introduces how to use MOSN to build the Service Mesh development environment based on SOFAMesh framework, and verify some basic capabilities of MOSN, such as routing and load balancing. This article includes the following content:\n Relationship between MOSN and SOFAMesh Preparations Deploy SOFAMesh with source codes Bookinfo experiment Relationship between MOSN and SOFAMesh As mentioned in MOSN introduction, MOSN is a Service Mesh data plane agent developed with Golang, and SOFAMesh is a large-scale implementation solution for Service Mesh, which is improved and extended based on Istio.","tags":null,"title":"Use MOSN to build Service Mesh platform","type":"projects","url":"/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/","wordcount":1078},{"author":null,"categories":null,"content":" Use Registry Different Registry integrations provide different ways to access Metrics.\n1. LookoutRegistry Provides the ability to count metrics by a time window. It is divided into two modes: “active” and “passive”. The passive mode is off currently.\n(1) Active mode\n You can specify the IP address of the remote agent through [Client Configuration], that is, check when start reporting, and regularly report data.\n(2) Passive mode\n This mode can be activated through [Client Configuration], and HTTP service is provided on port 19399.\n2. Connect to Prometheus The data of SOFALookout can be shared with Prometheus. In order to connect to Prometheus, you first need to add dependencies to your project:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-reg-prometheus\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; After adding the dependencies, launch the application, and you can see the data by visiting http://localhost:9494, where 9494 is the default port, you can configure com.alipay.sofa.lookout.prometheus-exporter-server-port in application.properties to change the port.\nOnce you have the URL to access the data, you can edit a prometheus.yml to grab the project information. Assuming that the local IP address is 10.15.232.20, you can configure prometheus.yml as follows:\nscrape_configs: - job_name: \u0026#39;lookout-client\u0026#39; scrape_interval: 5s static_configs: - targets: [\u0026#39;10.15.232.20:9494\u0026#39;] With the above configuration file, you can start Prometheus locally via Docker:\ndocker run -d -p 9090:9090 -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml --name prom prom/prometheus:master Then visit http://localhost:9090 through the browser, and you can query the corresponding Metrics through PromQL.\nAn example of connecting to Prometheus is also available in SOFALookout, so you can go and see it as a reference.\n3. Connect to SpringBoot actuator In addition to Prometheus, SOFALookout can be integrated with the Actuator of SpringBoot 1.x by adding the following dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Then, start and visit http://localhost:8080/metrics to see the data of events logged by the SOFALookout API.\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-registry/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"3c51ba6519cee542b459a170dabcf32b","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","summary":"Use Registry Different Registry integrations provide different ways to access Metrics.\n1. LookoutRegistry Provides the ability to count metrics by a time window. It is divided into two modes: “active” and “passive”. The passive mode is off currently.\n(1) Active mode\n You can specify the IP address of the remote agent through [Client Configuration], that is, check when start reporting, and regularly report data.\n(2) Passive mode\n This mode can be activated through [Client Configuration], and HTTP service is provided on port 19399.","tags":null,"title":"Use Registry","type":"projects","url":"/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/","wordcount":297},{"author":null,"categories":null,"content":" XML mode Declare the xsd file of SOFABoot: In the XML configuration file to be used, configure the declaration of the header xsd file to the followings. This enables development using the XML elements defined by SOFABoot.\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www .w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xmlns:context=\u0026amp;quot;http://www.springframework.org/schema/context\u0026amp;quot; xsi:schemaLocation =\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack .io/schema/sofaboot.xsd\u0026amp;quot; The way to publish and reference services in xml mode is as follows. sofa:service represents publishing service, and sofa:reference represents referencing service. sofa:binding indicates the protocol for service publishing or reference.\n\u0026amp;lt;bean id=\u0026amp;quot;personServiceImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonServiceImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; A service can also be published through multiple protocols, as follows:\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;personServiceImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Service reference\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; A service can also be referenced through other protocols:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceRest\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-xml/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"9192a93415bee3070a9be62c0f693949","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","summary":"XML mode Declare the xsd file of SOFABoot: In the XML configuration file to be used, configure the declaration of the header xsd file to the followings. This enables development using the XML elements defined by SOFABoot.\n\u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;beans xmlns=\u0026quot;http://www.springframework.org/schema/beans\u0026quot; xmlns:xsi=\u0026quot;http://www .w3.org/2001/XMLSchema-instance\u0026quot; xmlns:sofa=\u0026quot;http://sofastack.io/schema/sofaboot\u0026quot; xmlns:context=\u0026quot;http://www.springframework.org/schema/context\u0026quot; xsi:schemaLocation =\u0026quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack .io/schema/sofaboot.xsd\u0026quot; The way to publish and reference services in xml mode is as follows. sofa:service represents publishing service, and sofa:reference represents referencing service.","tags":null,"title":"Use XML in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/","wordcount":130},{"author":null,"categories":null,"content":" Use annotation for service publishing/reference In addition to the regular xml mode, it is also supported to publish and reference services with annotation in the SOFABoot environment. Similar to xml, we provide @SofaService and @SofaReference as well as @SofaServiceBinding and @SofaReferenceBinding annotation for multi-protocol.\nService publishing To publish an RPC service, you only need to add a @SofaService annotation on the bean to specify the interface and protocol type.\nimport com.alipay.sofa.runtime.api.annotation.SofaService; import com.alipay.sofa.runtime.api.annotation.SofaServiceBinding; import org.springframework.stereotype.Service; @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) }) @Service public class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String string) { return string; } } Service reference For a bean that needs to reference a remote service, you only need to add the @SofaReference annotation on the attribute or method. This supports the bolt, dubbo, rest protocol.\nimport com.alipay.sofa.runtime.api.annotation.SofaReference; import com.alipay.sofa.runtime.api.annotation.SofaReferenceBinding; import org.springframework.stereotype.Service; @Service public class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, jvmFirst = false, binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;)) private AnnotationService annotationService; public String sayClientAnnotation(String str) { return annotationService.sayAnnotation(str); } } Use the demo You can test in the annotation subproject of the sample project.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-annotation/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2c3afd33cbce4f5aa2473716b3afe5a6","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","summary":"Use annotation for service publishing/reference In addition to the regular xml mode, it is also supported to publish and reference services with annotation in the SOFABoot environment. Similar to xml, we provide @SofaService and @SofaReference as well as @SofaServiceBinding and @SofaReferenceBinding annotation for multi-protocol.\nService publishing To publish an RPC service, you only need to add a @SofaService annotation on the bean to specify the interface and protocol type.","tags":null,"title":"Use annotation in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/","wordcount":182},{"author":null,"categories":null,"content":" This topic mainly describes a JRaft-based distributed counter.\nScenario Save a distributed counter in a raft group of multiple nodes (servers). The counter can increment and be called while remaining consistent among all nodes. The counter can normally provide two external services when a minority of nodes fail:\n incrmentAndGet(delta): increments the value of delta and returns the incremented value. get(): gets the latest value. Remote procedure calls (RPCs) JRaft adopts the Bolt communication framework at the underlayer, and defines two requests:\n IncrementAndGetRequest: used for incrementing the value public class IncrementAndGetRequest implements Serializable { private static final long serialVersionUID = -5623664785560971849L; private long delta; public long getDelta() { return this.delta; } public void setDelta(long delta) { this.delta = delta; } } GetValueRequest: used for getting the latest value public class GetValueRequest implements Serializable { private static final long serialVersionUID = 9218253805003988802L; public GetValueRequest() { super(); } } ValueResponse responses include:\n success: indicates that the request was successful value: the latest value returned by a successful request errorMsg: the error message of a failed request redirect: indicates that a leader election occurred and the request needs to be sent to the new leader node public class ValueResponse implements Serializable { private static final long serialVersionUID = -4220017686727146773L; private long value; private boolean success; /** * redirect peer id */ private String redirect; private String errorMsg; public String getErrorMsg() { return this.errorMsg; } public void setErrorMsg(String errorMsg) { this.errorMsg = errorMsg; } ...... } IncrementAndAddClosure: used for receiving requests at the leader node IncrementAndGetRequest: used for handling callbacks of the request public class IncrementAndAddClosure implements Closure { private CounterServer counterServer; private IncrementAndGetRequest request; private ValueResponse response; private Closure done; // The network response callback public IncrementAndAddClosure(CounterServer counterServer, IncrementAndGetRequest request, ValueResponse response, Closure done) { super(); this.counterServer = counterServer; this.request = request; this.response = response; this.done = done; } @Override public void run(Status status) { // Return the response to the client if (this.done != null) { done.run(status); } } public IncrementAndGetRequest getRequest() { return this.request; } public void setRequest(IncrementAndGetRequest request) { this.request = request; } public ValueResponse getResponse() { return this.response; } } Server CounterStateMachine First hold an initial value:\npublic class CounterStateMachine extends StateMachineAdapter { /** * counter value */ private AtomicLong value = new AtomicLong(0); Implement the core onApply(iterator) method, and apply the user request to the state machine: …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/counter-example/","fuzzywordcount":1900,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"f9c54b9f7883ccb1d7c259b7101f4674","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/counter-example/","publishdate":"0001-01-01T00:00:00Z","readingtime":9,"relpermalink":"/sofastack.tech/en/projects/sofa-jraft/counter-example/","summary":"This topic mainly describes a JRaft-based distributed counter.\nScenario Save a distributed counter in a raft group of multiple nodes (servers). The counter can increment and be called while remaining consistent among all nodes. The counter can normally provide two external services when a minority of nodes fail:\n incrmentAndGet(delta): increments the value of delta and returns the incremented value. get(): gets the latest value. Remote procedure calls (RPCs) JRaft adopts the Bolt communication framework at the underlayer, and defines two requests:","tags":null,"title":"Use case of a counter","type":"projects","url":"/sofastack.tech/en/projects/sofa-jraft/counter-example/","wordcount":1859},{"author":null,"categories":null,"content":" SOFABoot provides a class isolation framework SOFAArk, giving Spring Boot a class isolation ability to resolve class or package conflicts in the development. For detailed information, please refer to:SOFAArk\nTo use this feature in SOFABoot projects, we need only two steps: configure the sofa-ark-maven-plugin plugins for packaging and add sofa-ark-springboot-starter dependencies of the class isolation framework.\nConfigure Maven packaging plugins The Maven plugins - sofa-ark-maven-plugin are available on the Central Repository. Through simple configurations, a SpringBoot project can be wrapped into an executable Ark package in the standard format. The coordinate of sofa-ark-maven-plugin is:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; The configuration template is described as follows:\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- all class exported by ark plugin would be resolved by ark biz in default, if configure denyImportClasses, then it would prefer to load them by ark biz itself --\u0026amp;gt; \u0026amp;lt;denyImportClasses\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass1\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.SampleClass2\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/denyImportClasses\u0026amp;gt; \u0026amp;lt;!-- Corresponding to denyImportClasses, denyImportPackages is package-level --\u0026amp;gt; \u0026amp;lt;denyImportPackages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;org.springframework\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/denyImportPackages\u0026amp;gt; \u0026amp;lt;!-- denyImportResources can prevent resource exported by ark plugin with accurate name to be resolved --\u0026amp;gt; \u0026amp;lt;denyImportResources\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test1.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;resource\u0026amp;gt;META-INF/spring/test2.xml\u0026amp;lt;/resource\u0026amp;gt; \u0026amp;lt;/denyImportResources\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; Description of plugin configuration:\n outputDirectory: Execute mvn package and then specify a directory to store the Ark package. The default directory is ${project. Build. Directory}. arkClassifier: Execute mvn docleoy, and then specify the coordinates of Maven repositories to locate the Ark package by setting the classfaulter value (the default is empty). We recommend that you configure this to give a different name from the ordinary Fat jar; denyImportClasses: By default, the application will first load …","date":-62135596800,"description":"","dir":"projects/sofa-boot/classloader-isolation/","fuzzywordcount":1200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"e007416ab008c1dd4b886433dbf8af01","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","summary":"SOFABoot provides a class isolation framework SOFAArk, giving Spring Boot a class isolation ability to resolve class or package conflicts in the development. For detailed information, please refer to:SOFAArk\nTo use this feature in SOFABoot projects, we need only two steps: configure the sofa-ark-maven-plugin plugins for packaging and add sofa-ark-springboot-starter dependencies of the class isolation framework.\nConfigure Maven packaging plugins The Maven plugins - sofa-ark-maven-plugin are available on the Central Repository.","tags":null,"title":"Use class isolation in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/classloader-isolation/","wordcount":1129},{"author":null,"categories":null,"content":" Use API SOFABoot provides a set of programming APIs for RPC service publishing and reference. It is convenient to publish and reference RPC services directly in the code. Similar to Spring\u0026amp;rsquo;s ApplicationContextAware, in order to use the programming API, you first need to implement the ClientFactoryAware interface to get the programming component API:\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } With DirectService as an example, see how to use the clientFactory to publish an RPC service through the programming API:\nServiceClient serviceClient = clientFactory.getClient(ServiceClient.class); ServiceParam serviceParam = new ServiceParam(); serviceParam.setInterfaceType(DirectService.class); serviceParam.setInstance(new DirectServiceImpl()); List\u0026amp;lt;BindingParam\u0026amp;gt; params = new ArrayList\u0026amp;lt;BindingParam\u0026amp;gt;(); BindingParam serviceBindingParam = new BoltBindingParam(); params.add(serviceBindingParam); serviceParam.setBindingParams(params); serviceClient.service (serviceParam); In the code above:\n First, get the ServiceClient object through the clientFactory. Then, construct the ServiceParam object, which contains the parameters required to publish the service, and use the setInstance method to set the object to be published as an RPC service, setInterfaceType to set the interface of the service. Finally, call the service method of ServiceClient to publish an RPC service. The code that references the RPC service through the programming API is similar:\nReferenceClient referenceClient = clientFactory.getClient(ReferenceClient.class); ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt; referenceParam = new ReferenceParam\u0026amp;lt;DirectService\u0026amp;gt;(); referenceParam.setInterfaceType(DirectService.class); BindingParam refBindingParam = new BoltBindingParam(); referenceParam.setBindingParam(refBindingParam); DirectService proxy = referenceClient.reference(referenceParam); proxy.sayDirect(\u0026amp;quot;hello\u0026amp;quot;); Likewise, to reference an RPC service, the code simply needs to get a ReferenceClient from the ClientFactory and then construct a ReferenceParam similar to publishing a service, next set up the service interface, and finally call the ReferenceClient\u0026amp;rsquo;s reference method.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-sofa-boot-api/","fuzzywordcount":300,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2679388dc3459714f869d8f8a71739d7","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","summary":"Use API SOFABoot provides a set of programming APIs for RPC service publishing and reference. It is convenient to publish and reference RPC services directly in the code. Similar to Spring\u0026rsquo;s ApplicationContextAware, in order to use the programming API, you first need to implement the ClientFactoryAware interface to get the programming component API:\npublic class ClientFactoryBean implements ClientFactoryAware { private ClientFactory clientFactory; @Override public void setClientFactory(ClientFactory clientFactory) { this.clientFactory = clientFactory; } } With DirectService as an example, see how to use the clientFactory to publish an RPC service through the programming API:","tags":null,"title":"Use dynamic API in SOFABoot","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/","wordcount":255},{"author":null,"categories":null,"content":" User guide Maven coordinator \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;bolt\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Check release notes for the version information.\n 1. Basic functions 1.1. Implement user request processor (UserProcessor) We provide two types of user request processors: SyncUserProcessor and AsyncUserProcessor. The difference between them is that the former returns the processing result in the form of a return value in the current processor thread, while the latter has an AsyncContext stub and can call the sendResponsemethod in the current thread or an asynchronous thread to return the processing result. For examples, refer to the following two types:\n Synchronous request processor Asynchronous request processor 1.2 Implement connection event processor (ConnectionEventProcessor) We provide two connection event processors: ConnectionEventType.CONNECT and ConnectionEventType.CLOSE. You can create your own event processors and register them with the client or the server. The client side and server side can each monitor both of their connection and disconnection events.\n Process connection event Process disconnection event 1.3 Client side and server side initialization (RpcClient, RpcServer) We have provided an RpcClient and RpcServer. They can be used after going through a simple initialization of necessary functions, or after switching on the functions. The most simple example is as follows:\n Client side initialization example Server side initialization example 1.4 Basic communication model We have provided four types of communication models:\n1. Oneway calls\nThe current thread initiates a call that is not interested in the call result and is not subject to timeout control. As long as the request is sent out, the call is completed. Note: Oneway calls are not guaranteed to succeed, and the initiator of the call has no way of knowing its result. For that reason, these calls are usually used in scenarios that can be retried or that have fixed-time notifications. Network problems or machine malfunctions during the call process may result in failure. This kind of call should only be used in business scenarios that accept such exceptions. For more information, see Example.\n2. Sync calls\nThe current thread initiates a call that only completes if it receives a result within the set timeout time. If a result is not received within the timeout time, it will generate a timeout error. This is the most commonly used call type. Ensure that the timeout time is set reasonably in accordance with the opposing terminal\u0026amp;rsquo;s processing capacity. For more information, see Example.\n3. Future calls\nThe current thread initiates a call and can then move onto executing the next call after getting an RpcResponseFuture object. The get() method of the RpcResponseFuture object can be used at any time to get the result. If the response has already been returned, the result …","date":-62135596800,"description":"","dir":"projects/sofa-bolt/sofa-bolt-handbook/","fuzzywordcount":2000,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"2a0a2e3c7749dbcdceea064f6f850e33","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","publishdate":"0001-01-01T00:00:00Z","readingtime":10,"relpermalink":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","summary":"User guide Maven coordinator \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;bolt\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; Check release notes for the version information.\n 1. Basic functions 1.1. Implement user request processor (UserProcessor) We provide two types of user request processors: SyncUserProcessor and AsyncUserProcessor. The difference between them is that the former returns the processing result in the form of a return value in the current processor thread, while the latter has an AsyncContext stub and can call the sendResponsemethod in the current thread or an asynchronous thread to return the processing result.","tags":null,"title":"User guide","type":"projects","url":"/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/","wordcount":1988},{"author":null,"categories":null,"content":" ## Version release\nVersion No. Major, minor, and revision version numbers are used. For example 2.0.0.\nRefer to: http://semver.org/lang/zh-CN/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Revision version number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance At most two versions can be maintained simultaneously.\nFor example, if the current major version is 2.2.0, the BugFix version 2.1.x will be maintained and bugs in version 2.0.x will no longer be fixed and a version upgrade is recommended.\nRelease process Daily development uses the SNAPSHOT version, such as 2.0.0-SNAPSHOT. When the modified version is officially released, the version number is revised to a formal version, such as 2.0.0. After release, the next version is pulled up, for example, 2.1.0-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-jarslink-version/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b82f2d74eff3937e10f15b13cb503751","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","summary":"## Version release\nVersion No. Major, minor, and revision version numbers are used. For example 2.0.0.\nRefer to: http://semver.org/lang/zh-CN/.\n Major version number: All versions within a major version number must be compatible with each other. They are not necessarily compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, more features it has. Revision version number: represents the BugFix version.","tags":null,"title":"Version release","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/","wordcount":175},{"author":null,"categories":null,"content":" Version number The system adopts a three-digit versioning scheme. The three digits respectively are major version number, minor version number, and revision number, for example: 5.1.2.\nFor more information, see the http://semver.org/lang/zh-CN/.\n Major version number: All versions in the major version number must be compatible with each other. It is not necessary to be fully compatible with other major version numbers, but it is best to have backward compatibility. Minor version number: Represents new feature enhancements. The larger the version number, the richer the feature. Revision number: Represents the BugFix version. The revision number is only for bug fixes. The larger the version number, the more stable it is. Version maintenance You can maintain up to two versions at the same time.\nFor example, the current trunk is 5.3.0, then the bugfix branch of 5.2.x will be maintained. When any bugs arise in 5.1.x, users are prompted to upgrade the system.\nRelease process The daily development branch uses the SNAPSHOT version, for example: 5.3.0-SNAPSHOT. When it comes to official release, you can modify the version to official version, for example: 5.3.0. Pull up the next version after release, for example: 5.3.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/version-release/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"604f113607e6815757f4d1907190c13c","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/version-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/version-release/","summary":"Version number The system adopts a three-digit versioning scheme. The three digits respectively are major version number, minor version number, and revision number, for example: 5.1.2.\nFor more information, see the http://semver.org/lang/zh-CN/.\n Major version number: All versions in the major version number must be compatible with each other. It is not necessary to be fully compatible with other major version numbers, but it is best to have backward compatibility.","tags":null,"title":"Version release","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/version-release/","wordcount":191},{"author":null,"categories":null,"content":" Version number Major, minor, and revision version numbers are used. For example, 1.0.0.\nFor more information, see https://semver.org/\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has. Revision version number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance Up to two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 1.2.0, the BugFix branch 1.1.x will be maintained, but bugs in branch 1.0.x will no longer be fixed. In this case, a version upgrade is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 1.0.0-SNAPSHOT. Upon formal release, the snapshot version is modified to the formal version, for example 1.0.0. After the formal release, the next version is pulled, for example, 1.0.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/version-rule/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a2093bdf478bdff0e15a2de70e522d03","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/version-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-dashboard/version-rule/","summary":"Version number Major, minor, and revision version numbers are used. For example, 1.0.0.\nFor more information, see https://semver.org/\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has.","tags":null,"title":"Version rules","type":"projects","url":"/sofastack.tech/en/projects/sofa-dashboard/version-rule/","wordcount":180},{"author":null,"categories":null,"content":" Version number SOFARegistry uses a three-digit version number in the form of major, minor, and patch. For example, 5.2.0.\nFor more information, see https://semver.org/.\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has. Patch number: represents the BugFix version. Such versions are only used for bug fixing. The larger the version number, the more stable the application. Version maintenance Up to two versions can be maintained simultaneously.\nFor example, if the current version of the master branch code is 5.4.0, the BugFix branch of version 5.3.x will be maintained, but bugs in branch 5.2.x will no longer be fixed. Therefore, a version upgrade for 5.2.x is recommended.\nRelease process The develop branches use SNAPSHOT versions, for example, 5.3.0-SNAPSHOT. Upon formal release, SNAPSHOT is replaced with a formal version number, for example 5.3.0. After the formal release, the next version is pulled, for example, 5.3.1-SNAPSHOT. ","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-standard/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"71aad9cbc42aba3d9f875ae9169cf005","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/release-standard/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-registry/release-standard/","summary":"Version number SOFARegistry uses a three-digit version number in the form of major, minor, and patch. For example, 5.2.0.\nFor more information, see https://semver.org/.\n Major version number: All versions with the same major version number must be compatible with each other. They are not necessarily fully compatible with other major versions. However, it is best to be downward compatible. Minor version number: represents feature enhancement. The larger the version number, the more features it has.","tags":null,"title":"Version rules","type":"projects","url":"/sofastack.tech/en/projects/sofa-registry/release-standard/","wordcount":186},{"author":null,"categories":null,"content":" With SOFABoot, we can directly view the version of SOFA middleware and other detailed information in the browser.\nIntroducing SOFABoot Infra Dependency To view the version information of the SOFA middleware directly in the browser in SOFABoot, all you need to do is add the following to the Maven dependency:\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;infra-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Version Information Viewing After an application started successfully, you can visit http://localhost:8080/sofaboot/versions in the browser to view the version information of the SOFA middleware, the response such as:\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Build-Time: \u0026amp;quot;2018-04-05T20:55:22+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.0\u0026amp;quot; } ] ** Note: In SOFABoot 3.x, the endpoint path has been changed from sofaboot/versions to actuator/versions**.\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/view-versions/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"c6b6d22e9038aa1f5e4ce74449ba1cda","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/view-versions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-boot/view-versions/","summary":"With SOFABoot, we can directly view the version of SOFA middleware and other detailed information in the browser.\nIntroducing SOFABoot Infra Dependency To view the version information of the SOFA middleware directly in the browser in SOFABoot, all you need to do is add the following to the Maven dependency:\n\u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;infra-sofa-boot-starter\u0026lt;/artifactId\u0026gt; \u0026lt;/dependency\u0026gt; Version Information Viewing After an application started successfully, you can visit http://localhost:8080/sofaboot/versions in the browser to view the version information of the SOFA middleware, the response such as:","tags":null,"title":"View version","type":"projects","url":"/sofastack.tech/en/projects/sofa-boot/view-versions/","wordcount":115},{"author":null,"categories":null,"content":"The warm-up weight feature allows the client machine to distribute traffic based on the corresponding weight of the server. This feature is also often used in the scenario where a few machines within a cluster are being started. The server machines can be warmed up in a short time with the traffic weight function, and then continue to receive the normal traffic.\nThe operating mechanism is as follows: When the server service starts, it pushes its own warm-up duration, weight during warm-up, and normal weight after warm-up to the Service Registry. As shown above, Service B points to Service Registry.\n When referencing service, the client obtains the warm-up weight information of each service instance. As shown above, Service Registry points to client.\n When calling service, the client distributes the traffic according to the warm-up weight of the address where the service is located. As shown above, the client points to Service A and Service B. Service A has completed warm-up, and its weight is 100 by default. Service B is in the warm-up period, and its weight is 10. Therefore, their traffic is 100%110 and 10%110 respectively.\n This feature is used as follows:\nProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt;() .setWeight(100) .setParameter(ProviderInfoAttrs.ATTR_WARMUP_WEIGHT,\u0026amp;quot;10\u0026amp;quot;) .setParameter(ProviderInfoAttrs.ATTR_WARM_UP_END_TIME, \u0026amp;quot;12000\u0026amp;quot;); As above, the warm-up duration of the service is 12s, the weight is 10 during warm-up, and the normal weight after warm-up is 100. If the service is published on two machines, such as machine A and B, and the machine A is in the warm-up period with the above configuration, while B has already completed warm-up, and the normal weight is 200, then when the client calls the service, the proportion of traffic distribution is 10:200. After the machine A is warmed up, the traffic distribution ratio is 100:200.\nIn SOFABoot, the warm-up duration and the weight during and after warm-up can be configured as follows:\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleRestFacadeReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.endpoint.facade.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs weight=\u0026amp;quot;100\u0026amp;quot; warm-up-time=\u0026amp;quot;10000\u0026amp;quot; warm-up-weight=\u0026amp;quot;1000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/provider-warmup-weight/","fuzzywordcount":400,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"b9e320dfaa4f9700ecdca67d76e07d54","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","summary":"The warm-up weight feature allows the client machine to distribute traffic based on the corresponding weight of the server. This feature is also often used in the scenario where a few machines within a cluster are being started. The server machines can be warmed up in a short time with the traffic weight function, and then continue to receive the normal traffic.\nThe operating mechanism is as follows: When the server service starts, it pushes its own warm-up duration, weight during warm-up, and normal weight after warm-up to the Service Registry.","tags":null,"title":"Warm-up weight","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/","wordcount":319},{"author":null,"categories":null,"content":" X-Protocol X-Protocol is a special common protocol supported by SOFAMesh. It can access different RPC protocols in a unified manner. Because it doesn\u0026amp;rsquo;t require to parse protocols, it can not only provide higher performance, but also reduce the development cost of accessing new protocols.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-x-protocol/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"220f4a76b277463bb1f7201519950450","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","summary":"X-Protocol X-Protocol is a special common protocol supported by SOFAMesh. It can access different RPC protocols in a unified manner. Because it doesn\u0026rsquo;t require to parse protocols, it can not only provide higher performance, but also reduce the development cost of accessing new protocols.","tags":null,"title":"X-Protocol","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/","wordcount":44},{"author":null,"categories":null,"content":"X-Protocol 协议是 SOFAMesh 支持的特殊通用协议，能够以统一的方式接入不同的 RPC 协议，因为无需进行协议解析，不仅能够提供更高的性能, 更能降低接入新协议的开发成本。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-x-protocol/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"220f4a76b277463bb1f7201519950450","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","summary":"X-Protocol 协议是 SOFAMesh 支持的特殊通用协议，能够以统一的方式接入不同的 RPC 协议，因为无需进行协议解析，不仅能够提供更高的性能, 更能降低接入新协议的开发成本。","tags":null,"title":"X-Protocol","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/","wordcount":70},{"author":null,"categories":null,"content":" ZooKeeper Adapter ZooKeeper Adapter is an Adapter plug-in developed in accordance with the Istio registry center extension mechanism. It is used for docking all microservices frameworks that use ZooKeeper as a registry center. Currently, ZooKeeper Adapter supports SOFARPC and will be available for Dubbo soon.\nZooKeeper Adapter uses ZooKeeper\u0026amp;rsquo;s watch mechanism to listen to the change events of service registration information, providing better real-time performance than polling.\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-zookeeper-adapter/","fuzzywordcount":100,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"a174a0de8dd47df7c3043f6d49fa1b07","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","summary":"ZooKeeper Adapter ZooKeeper Adapter is an Adapter plug-in developed in accordance with the Istio registry center extension mechanism. It is used for docking all microservices frameworks that use ZooKeeper as a registry center. Currently, ZooKeeper Adapter supports SOFARPC and will be available for Dubbo soon.\nZooKeeper Adapter uses ZooKeeper\u0026rsquo;s watch mechanism to listen to the change events of service registration information, providing better real-time performance than polling.","tags":null,"title":"ZooKeeper Adapter","type":"projects","url":"/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/","wordcount":67},{"author":null,"categories":null,"content":" To use Zookeeper as service registry center, you only need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 Note: Considering the real-time nature of the service, the following features are not supported currently.\nSOFABoot RPC also provides a cache file (not supported currently), which is used for service discovery when ZooKeeper is not available. The way to configure this cache file is as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth When users need to auth the providers and consumers, they can use a auth key to write or read the dictionary normally, only when they use the same key, zookeeper server will process these requests.\nSOFARPC API Usage If you use SOFARPC API directly, you can add two parameters to registry config.\nparameters.put(\u0026amp;quot;scheme\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;); //if there was multi auth infos, you need to set the value as user1:passwd1,user2:passwd2 parameters.put(\u0026amp;quot;addAuth\u0026amp;quot;, \u0026amp;quot;sofazk:rpc1\u0026amp;quot;); registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181/authtest\u0026amp;quot;) .setParameters(parameters); then if another provider or consumer use a different auth info, they will not access these providers or consumers.\nXML Usage You only need to set it in application.properties\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry\u0026amp;amp;scheme=digest\u0026amp;amp;addAuth=sofazk:rpc1 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-zookeeper/","fuzzywordcount":200,"kind":"page","lang":"en","lastmod":1728877684,"objectID":"71d6486c5577cc85d84c56688cdf2af1","permalink":"https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","summary":"To use Zookeeper as service registry center, you only need to configure it in application.properties as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 Note: Considering the real-time nature of the service, the following features are not supported currently.\nSOFABoot RPC also provides a cache file (not supported currently), which is used for service discovery when ZooKeeper is not available. The way to configure this cache file is as follows:\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth When users need to auth the providers and consumers, they can use a auth key to write or read the dictionary normally, only when they use the same key, zookeeper server will process these requests.","tags":null,"title":"Zookeeper","type":"projects","url":"/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/","wordcount":174},{"author":null,"categories":null,"content":"Zookeeper Adapter 是按照 Istio 注册中心扩展机制开发的一个 Adapter 插件，用于对接所有使用 Zookeeper 作为注册中心的微服务框架。目前已经支持了 SOFARPC，很快将提供对于 Dubbo 的支持。\nZookeeper Adapter 使用 zk 的 watch 机制监听服务注册信息的变化事件，提供了比轮询机制更好的实时性。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-zookeeper-adapter/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a174a0de8dd47df7c3043f6d49fa1b07","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","summary":"Zookeeper Adapter 是按照 Istio 注册中心扩展机制开发的一个 Adapter 插件，用于对接所有使用 Zookeeper 作为注册中心的微服务框架。目前已经支持了 SOFARPC，很快将提供对于 Dubbo 的支","tags":null,"title":"Zookeeper Adpater","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/","wordcount":110},{"author":null,"categories":null,"content":" 在介绍 Biz 生命周期 时，我们提到了有三种方式控制 Biz 的生命周期，并且介绍了使用客户端 API 实现 Biz 的安装、卸载、激活。在这一章节我们介绍如何使用 SOFAArk 提供的动态配置插件，通过 Zookeeper 下发指令，控制 Biz 的生命周期。\n引入依赖 SOFAArk 提供了 config-ark-plugin 对接 Zookeeper 配置中心，用于运行时接受配置，达到控制 Biz 生命周期，引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;config-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置 ZK 地址 参考 SOFAArk 配置，在 SOFAArk 配置文件 conf/ark/bootstrap.properties 增加如下配置：\ncom.alipay.sofa.ark.config.address=zookeeper://ip:port 配置维度 SOFAArk 启动后，会在 ZK 注册两个节点配置，分别是宿主应用维度和 IP 维度：\n sofa-ark/${com.alipay.sofa.ark.master.biz}/ \u0026amp;gt; 宿主应用维度配置，应用启动时，会拉取该维度配置，控制相关 Biz 的部署；应用重启后，配置不会丢失\n sofa-ark/${com.alipay.sofa.ark.master.biz}/ip/ \u0026amp;gt; IP 维度配置，应用重启后丢失，通常用于运行时控制单台机器的 Biz 行为\n 通过写这两个节点的配置，可以控制相关机器和应用的 Biz 运行时状态。\n配置形式 下面介绍配置的形式，动态配置采用状态声明指令，SOFAArk 收到配置后，会根据状态描述解析出具体的指令（包括 install，uninstall, switch），指令格式如下：\nbizName:bizVersion:bizState?k1=v1\u0026amp;amp;k2=v2\n多条指令使用 ; 隔开，单条指令主要由 biz 名称，biz 版本，biz 预期状态及参数组成。简单记住一点，状态配置是描述指令推送之后，所有非宿主 Biz 的状态；\n例如当前 SOFAArk 容器部署了两个应用 A，B，版本均为 1.0，其中 A 应用为宿主应用，因为宿主应用不可卸载，因此不需要考虑宿主应用，可以简单认为当前容器的 Biz 状态声明为：\n B:1.0:Activated\n 如果此时你希望安装 C 应用，版本为 1.0，文件流地址为 urlC，那么推送指令应为：\n B:1.0:Activated;C:1.0:Activated?bizUrl=urlC\n 操作继续，如果你又希望安装安装 B 应用，版本为 2.0，文件流地址为 urlB，且希望 2.0 版本处于激活状态，那么你推送的指令应为：\n B:1.0:Deactivated;B:2.0:Actaivated?bizUrl=urlB;C:1.0:Activated\n解释下为什么是这样配置指令，因为 SOFAArk 只允许应用一个版本处于激活状态，如果存在其他版本，则应处于非激活状态；所以当希望激活 B 应用 2.0 版本时，B 应用 1.0 版本应该声明为非激活状态。另外你可能注意到了 C 应用参数 urlC 不用声明了，原因是目前只有当安装新 Biz 时，才有可能需要配置参数 bizUrl，用于指定 biz 文件流地址，其他场景下，参数的解析没有意义。\n 操作继续，如果你希望卸载 B 应用 2.0 版本，激活 B 应用 1.0 版本，卸载 C 应用，那么推送的指令声明为：\n B:1.0:Activated\n 从上面的操作描述看，在推送动态配置时，只需要声明期望的 Biz 状态即可，SOFAArk 会根据状态声明推断具体的执行指令，并尽可能保持服务的连续性，以上面最后一步操作为例，SOFAArk 推断的执行指令顺序如下： + 执行 switch 指令，激活 B 应用 1.0 版本，钝化 B 应用 2.0 版本，保证服务连续性 + 执行 uninstall 指令，卸载 B 应用 2.0 版本 + 执行 uninstall 指令，卸载 C 应用 1.0 版本\n注意事项 目前只有在安装新 Biz 时才可能使用指令参数 bizUrl，用于指定 Biz 文件流地址。文件流地址字符串是能够直接构建 URL 对象，例如 file://xxx 或者 http://xxx. 安装新 Biz 时，参数 bizUrl 不是必须的，SOFAArk 提供了扩展点：\n@Extensible public interface BizFileGenerator { File createBizFile(String bizName, String bizVersion); } 用于扩展实现，根据 biz 名称和 biz 版本返回 biz 文件。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-zk-config/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c675734b1cb5fa546f96a31d8b9e3533","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","summary":"在介绍 Biz 生命周期 时，我们提到了有三种方式控制 Biz 的生命周期，并且介绍了使用客户端 API 实现 Biz 的安装、卸载、激活。在这一章节我们介绍如何使用 SOFAArk 提供的","tags":null,"title":"Zookeeper 配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/","wordcount":1160},{"author":null,"categories":null,"content":" connection_manager 用于描述 MOSN 的路由配置，通常与 proxy 配合使用。\n{ \u0026amp;quot;router_config_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;virtual_hosts\u0026amp;quot;: [ ] } router_config_name，唯一的路由配置标识，与 proxy 中配置的字段对应。 virtual_hosts，描述具体的路由规则细节。 VirtualHost { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;domains\u0026amp;quot;:[], \u0026amp;quot;routers\u0026amp;quot;:[] } name，字符串。用作 virtual host 的唯一标识。 domains，字符串数组。表示一组可以匹配到该 virtual host 的 domain，支持配置通配符。domain 的匹配优先级如下： 首先匹配精确的，如 www.foo.com。 其次匹配最长后缀的通配符，如 *.foo.com、*-bar.foo.com，其中如果一个 domain 是 foo-bar.foo.com，那么会优先匹配 *-bar.foo.com。 最后匹配任意domain的通配符 * 。 routers，一组具体的路由匹配规则。 Router { \u0026amp;quot;match\u0026amp;quot;:{}, \u0026amp;quot;route\u0026amp;quot;:{}, \u0026amp;quot;per_filter_config\u0026amp;quot;:{} } match，路由的匹配参数。 route，路由行为，描述请求将被路由的 upstream 信息。 per_filter_config，是一个 key: json 格式的 json。 其中 key 需要匹配一个 stream filter 的 type，key 对应的 json 是该 stream filter 的 config。 当配置了该字段时，对于某些 stream filter（依赖具体 filter 的实现），可以使用该字段表示的配置覆盖原有 stream filter 的配置，以此做到路由匹配级别的 stream filter 配置。 match { \u0026amp;quot;prefix\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;path\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;regex\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;headers\u0026amp;quot;: [] } 路径（path）匹配 prefix，表示路由会匹配 path 的前缀，该配置的优先级高于 path 和 regex。 如果 prefix 被配置，那么请求首先要满足 path 的前缀与 prefix 配置相符合。 path，表示路由会匹配精确的 path，该配置的优先级高于 regex。如果 path被配置，那么请求首先要满足 path 与 path 配置相符合。 regex，表示路由会按照正则匹配的方式匹配 path。如果 regex 被配置，那么请求首先要满足 path 与 regex 配置相符合。 路径匹配配置同时存在时，只有高优先级的配置会生效。 Heaer 匹配 headers，表示一组请求需要匹配的 header。请求需要满足配置中所有的 Header 配置条件才算匹配成功。 header { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;value\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;regex\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } name，表示 header 的 key。 value，表示 header 对应 key 的 value。 regex，bool 类型，如果为 true，表示 value 支持按照正则表达式的方式进行匹配。 route { \u0026amp;quot;cluster_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;metadata_match\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;retry_policy\u0026amp;quot;:{} } cluster_name，表示请求将路由到的 upstream cluster。 metadata_match，metadata，如果配置了该字段，表示该路由会基于该 metadata 去匹配 upstream cluster 的 subset 。 timeout，Duration String，表示默认情况下请求转发的超时时间。如果请求中明确指定了超时时间，那么这个配置会被忽略。 retry_policy，重试配置，表示如果请求在遇到了特定的错误时采取的重试策略，默认没有配置的情况下，表示没有重试。 retry_policy { \u0026amp;quot;retry_on\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;retry_timeout\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;num_retries\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot; } retry_on，bool 类型，表示是否开启重试。 retry_timeout，Duration String，表示每次重试的超时时间。当 retry_timeout 大于 route 配置的 timeout 或者请求明确指定的 timeout 时，属于无效配置。 num_retries，表示最大的重试次数。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/network-filter/connection-manager/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"88e2d06bd6137225eeebf9015b2192a2","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","summary":"connection_manager 用于描述 MOSN 的路由配置，通常与 proxy 配合使用。 { \u0026quot;router_config_name\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;virtual_hosts\u0026quot;: [ ] } router_config_name，唯一的路由配置标识，与 proxy 中配置的字段对应。 vir","tags":null,"title":"connection_manager","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/","wordcount":1188},{"author":null,"categories":null,"content":"proxy 是 MOSN 最常用的 network filter，其配置格式如下。\n{ \u0026amp;quot;downstream_protocol\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;upstream_protocol\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;router_config_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;extend_config\u0026amp;quot;:{} } downstream_protocol 描述 proxy 期望收到的请求协议，在连接收到数据时，会使用此协议去解析数据包并完成转发，如果收到的数据包协议和配置不符，MOSN 会将连接断开。 upstream_protocol 描述 proxy 将以何种协议转发数据，通常情况下应该和downstream_protocol 保持一致，只有特殊的场景会进行对应协议的转换。 router_config_name 描述 proxy 的路由配置的索引，通常情况下，这个配置会和同 listener 下的 connection_manager 中配置的 router_config_name 保持一致。 extend_config 扩展配置，目前仅在 MOSN 的 XProtocol 协议中使用。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/listener/network-filter/proxy/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b04f78179a47a64d7e209b6660bfa80f","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","summary":"proxy 是 MOSN 最常用的 network filter，其配置格式如下。 { \u0026quot;downstream_protocol\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;upstream_protocol\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;router_config_name\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;extend_config\u0026quot;:{} } downstream_protocol 描述 proxy 期望收到的请求协议，在连接收到数据时，会使用此协议去解析数据包并完成转发，","tags":null,"title":"proxy","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/","wordcount":221},{"author":null,"categories":null,"content":" 打开 ACTS IDE 在 Package 视图下，右键含 @Test 注解的函数名，ACTS 功能 -\u0026amp;gt; 修改测试用例，如下图：\n编写测试数据 准备入参 根据被测的接口方法的入参（类型、顺序、数量）正确准备入参数据，简单类型包括 String、Date、Integer、Float、Double、Long、Short、Byte（包含其对应的基本类型，即 int、float 等）；复杂类型为 List、Map、Set、自定义类、Java 定义的类以及前面五者的嵌套等。\n简单入参 入参设置上右键 -\u0026amp;gt; 模版选择 -\u0026amp;gt; 简单入参选择：\n导入简单入参后，值直接在这里填写； 自上而下表示被测接口方法的第1个、第2个和第3个参数，右键可以调节顺序。\n复杂入参 如图27所示，AccountTransRequest 和 BusinessActionContext 类需要生成入参模板，一般情况下，在一键生成测试脚本时会自动生成方法的入参和返回结果的类模板，打开 ACTS IDE 可对其进行编辑，如图28。\n图28\n如果生成测试脚本时没有识别出方法的入参和返回结果模版，可先生成复杂入参和结果模版（具体操作参考 对象模型生成），然后打开 ACTS IDE 编辑器，在入参设置上右键 -\u0026amp;gt; 模版选择 -\u0026amp;gt; 复杂类型，添加后可以看到复杂对象，直接进行编辑。\nlist map 以示例2为例（Set 与此类似） 图32中，演示示例2的方法入参为 Map\u0026amp;lt;String,Object\u0026amp;gt; 类型。由于 Object 不是具体类型，如果要设置 Object 为复杂对象，则需要去编辑 YAML。例如设置 Object 为 AccountTransResult 类型，则按照如下编辑：\n图32\nenum 代码样例：\n 在 ACTS IDE 中编辑如下： 如果枚举嵌套在其他类中，则在该类的 CSV 模版中设置枚举的值为 DEBIT；\n 用例数据 YAML 中，如图37：\n interestRecoverTypeEnum: !!com.alipay.fc.loancore.common.util.enums.InterestRecoverTypeEnum \u0026#39;ALL\u0026#39; 图37\n编码方式准备入参 覆盖 prepare 方法，通过 ActsRuntimeContext 的方法，快速获取和设置用例入参，如图38所示：\n 获取所有入参：List getInputParams() 按位置获取：Object getInputParamByPos(int i) 新增用例参数：void addInputParam(Object obj) 图 38\n准备 DB 数据 准备 DB 数据-单列场景 如图39，在数据库准备设置位置右键，选择好要插入的 DB 模板（请先确保该DB模板已经生成），图中1、2、3步骤之后点击 OK 即插入 DB 准备模板，如图41，可对要插入 DB 的数据进行编辑：\n图39\n图40\n图41\n准备 DB 数据-多列场景 选中一列数据，点击复制，按此方法可复制多列数据，然后进行编辑即可：\n图42\n准备 DB 数据-flag说明 数据依赖标记：\nY: 插入 N：不插入 C：以此为where条件对插入后的数据进行清理 F：数据库函数 L: 大字段换行准备，准备方式为A=B;C=D 图43\n准备期望结果数据 生成期望结果的对象模型后，在 ACTS IDE 界面中，期望结果设置右键 -\u0026amp;gt; 模版选择，见下图。\n图44\n期望结果的 flag 说明 Y: 校验 N：不校验 D：时间偏移值比较，如 D200 ME：map 默认全 key 校验，ME则以期望 key 为准，实际值多余期望值的 key 不予校验 对于返回结果的时间 Date 类型字段校验说明： 1. Y | null -\u0026amp;gt; 代表期望为 null 2. Y | 2015-01-01 00:00:00 -\u0026amp;gt; 代表期望为 2015-01-01 00:00:00 3. N | null -\u0026amp;gt; 代表不校验 4. D200 | 2015-01-01 00:00:00/null -\u0026amp;gt; 代表与 2015-01-01 00:00:00/new Date() 相差 200 秒\n编码方式准备期望结果 覆盖 prepare 方法，通过 ActsRuntimeContext 的如下方法，快速获取和设置期望结果。 1. 获取期望结果：Object getExpectResult() 2. 设置期望结果：Boolean setExpectResult(Object objToSet)\n准备期望 DB 数据 准备期望 DB 数据-单列场景 在数据库期望设置里配置，操作参考准备 DB 数据-单列场景\n准备期望 DB 数据-多列场景 在数据库期望设置里配置，操作参考准备 DB 数据-多列场景\n期望 DB 数据的 flag 说明 数据校验标记：\nY: 校验 N：不校验 C：以此为条件 select 然后比较，如果结果有多个，则返回的结果所有记录都要和当前需要校验的数据进行校验 CN： 这个 flag 表示当前这张表中以 C 和 CN 为条件查询出的结果为空 D200：表示对比时间的时候误差 200s 之内都算通过，日期类型的格式为：today L： 数据库大字段换行数据校验，准备方式为 A=B;C=D P：DB 大字段校验，以期望结果的 kv 为基准，对 DB 大字段里的 kv 进行校验，要求 DB 里的 kv 之间是换行分隔 R：正则匹配校验 准备期望异常数据 编码方式准备期望异常数据 部分系统封装的异常类没有默认构造函数，这样通过模版添加的异常结果在加载 YAML 时会有问题（无默认构造函数无法构造当前类），需要通过代码方式，结合自定义参数编写异常脚本，如下图：\n图45\n准备自定义数据 自定义数据-用途 用户自定义的各类型数据，用于测试过程中自由使用。\n自定义数据-数据类型 数据类型可参考 入参 部分\n编码方式准备自定义数据 快速获取和设置自定义参数：\n 获取全部自定义参数：getParamMap getParamMap() 按 key 获取：Object getParamByName(String paraName) 新增自定义参数：void addOneParam(String paraName, Object paraObj) 替换自定义参数：void setParamMap(Map\u0026amp;lt;String,Object\u0026amp;gt; paramMap) 以范型方式获取自定义参数：T getParamByNameWithGeneric(String paraName) 不同数据类型编辑方式 简单类型编辑 以自定义参数设置添加简单类型数据为例。如图46，自定义参数设置右键 -\u0026amp;gt; 模板选择，弹框填写入参名字：\n图46\n图47\n选择 String 类型，在下方编辑框填写值即可，生成后也可自行编辑： ![填写值](enter-value.png) 图48\n图49\n复杂对象编辑 以自定义参数设置添加复杂对象数据为例\n参照 简单类型编辑，在弹框填 …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ide/","fuzzywordcount":2600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"697e7e6d35a2e058f3ca8b0a72032690","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-ide/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-ide/","summary":"打开 ACTS IDE 在 Package 视图下，右键含 @Test 注解的函数名，ACTS 功能 -\u0026gt; 修改测试用例，如下图： 编写测试数据 准备入参 根据被测的接口方法的入参（类型、顺序、数量","tags":null,"title":"一站式编辑","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-ide/","wordcount":2588},{"author":null,"categories":null,"content":" 快速理解 ACTS 的模型 在写测试用例的过程中，需要预先准备一些 DB 表、方法入参的数据，或者需要校验一些 DB 表、返回结果的数据，这些数据可以以模版的形式保存下来，在编辑用例时，可以方便的导入这些数据到准备数据或者校验数据，实现数据复用。目前 ACTS 模型可以分为 DB 模型和类模型。\n常规的测试用例编写，DB 、方法入参、返回结果等领域模型的数据准备是通过测试代码组织的，随着业务复杂度，领域模型复杂度也在不断增加，尤其在金融级业务用，往往一个类或者数据表有数十个属性或者字段，类与类的嵌套也是随处可见，代码构造复杂对象变得十分困难且容易疏漏，问题频现： * 表太多容易遗漏，排查时间太长； * 表的字段名记不住，时不时写错； * 接口入参数量多类型复杂，看见就头疼； * 类的属性太多，容易遗漏重要属性； * 嵌套构造对象，不断的 new 和 set 赋值； * 继承和实现关系复杂，遗漏重要属性；\nACTS 的模版有可以有效应对上述问题，通过将类和表固化为 CSV，类的结构一目了然，通过类、数据表的模版可以快速的模版化地创建对象，并序列化到 YAML 文件中，使用 ACTS IDE 可以方便的管理用例数据。\n模型存储位置 在 test 模块的 resource/model 目录可以查看已经存在的模型。\n图4\n数据表模型生成 数据表模型样例 图5\n1. 校验 flag 说明\n```plain Y: 插入 N：不插入 C：以此为 where 条件对插入后的数据进行清理 F：数据库函数 L: 大字段换行准备，准备方式为 A=B;C=D ``` 2. 用例编辑使用模型快速导入数据\n使用 ACTS IDE 编辑 DB 表数据（包括准备表数据、期望表数据）时，可右键新增指定表的模型，用于直接从表模型的 CSV 中导入表的全部字段和值，以便快速编辑。 DB 模版的使用可参考准备 DB 数据。\n生成表模型 图6\n图7\n图8\n点击 OK 后生成模板，如图9：\n图9\n同时支持不配置直连获取表结构的方式生成表模型，即在 DO 类上右键根据类生成表模型： DO 类上右击 -\u0026amp;gt; ACTS 功能 -\u0026amp;gt; 生成 DO 模型：\n图10\n![生产的模型](generated-do-model.png) 图11\n对象模型生成 对象模型样例 图12\n图13\n一个复杂对象是一个闭包，不但包含其自身模型还包含其嵌套对象的模型。\nACTS 使用模型快速导入数据、编辑复杂对象（包括入参、返回结果和异常等），在 ACTS IDE 中可右键选择类模型，用于构建该类的对象并赋值以便快速编辑。\n生成方法 有两种方式： 1.待构建模型的类定义的任意方法上点击； 1.接口定义的方法上点击，详细操作看下图示例。\n使用 IDEA 的同学请注意：请先确保代码已编译，IDEA 不会自动编译而需要手动 mvn clean install 或者打开自动编译 File -\u0026amp;gt; Settings -\u0026amp;gt; Build,Execution,Deployment -\u0026amp;gt; Compiler -\u0026amp;gt; Make project automatically。\nACTS IDE 生成对象模型 （1）待构建模型的类定义的任意方法上点击，生成当前类的模型\n图14\n（2）接口定义任意方法上点击，生成当前接口中，所有方法的复杂入参、复杂返回结果的模型\n图15\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-model/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"65aaf62462b3b0ea142ca75a5b61eb0d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-model/","summary":"快速理解 ACTS 的模型 在写测试用例的过程中，需要预先准备一些 DB 表、方法入参的数据，或者需要校验一些 DB 表、返回结果的数据，这些数据可以以模版的形式保","tags":null,"title":"一键模型化","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-model/","wordcount":1096},{"author":null,"categories":null,"content":" 快速理解 ACTS 中的脚本 如果你是一个经常编写测试用例的同学，是不是经常苦于这样的问题： * 不断的 assertEquals 写得快吐了，重复性编码毫无创意； * 少一个 assert 容易假绿，错一个败坏心情； * 场景一旦复杂，测试代码比业务代码还要长，写起来痛不欲生； * 每换一个应用，之前写的工具类就要搬一次；\n左图为 TestNG 用例，右图为 ACTS 用例，重复性代码一去不回，代码体积明显缩小。区别于普通测试脚本，ACTS 脚本继承自 ActsTestBase 类，封装了数据加载、驱动、执行引擎和校验规则，无需用户来组织清理数据、准备数据、执行用例和校验结果，对于简单业务可以做到零编码，极大释放代码编写和后期维护成本。\n测试脚本生成 前提条件：务必 mvn 编译工程和生成对象模型，否则会造成 ACTS IDE 不可预料的错误，如无法编辑、数据不正确等。\n接口定义的方法上点击，选择 ACTS 功能 -\u0026amp;gt; 生成测试用例。\n测试脚本运行 方法：右键 ACTS 脚本中的被测方法，选择 TestNG 来执行测试脚本，如下图：\n指定测试脚本运行 在 src/test/resource/config/acts-config.properties 中配置 test_only＝^T，表示只跑用例名称以 T 开头的用例，^T 也可以换成其他正则表达式；\n 修改要测试的用例名称，在用例名前面加 T，ACTS 运行时时仅执行用例名称以 T 开头的用例。\n 脚本用例拆分功能 默认每个测试脚本的所有用例数据保存在同一个 YAML 中，ACTS 支持用例数据根据开关 spilt_yaml_by_case 来决定同一测试脚本的所有用例数据存储在一个 YAML 中还是每个用例存储为一个 YAML。 开关默认为关闭，即同一测试脚本的所有测试数据存储在一个 YAML 文件中。\n在 acts-config.properities 中设置 spilt_yaml_by_case=true 即可打开开关，之后新生成测试脚本时每个用例对应一个单独的以 caseId 命名的 YAML文件，拆分的方式可以降低多人研发同一接口带来的文件冲突问题。\n此外，为了支持将老的 YAML 文件按用例拆分，ACTS 提供了工具类，如下，支持将指定脚本下，指定路径的 YAML 文件按用例拆分。\n BaseDataUtil.saveYamlDataToCaseByCase\n 注意：拆分后，建议先给原有 YAML 重命名做备份，然后打开用例编辑器检查拆分后的文件内容是否正确，确认无误后可删除原有 YAML 文件，两者不能并存。 编码方式准备数据 ACTS 提供了数据自定义 API 接口，封装于 ActsRuntimeContext 类中，如下： + 快速获取和设置自定义参数\n获取全部自定义参数：`getParamMap getParamMap()` 按 key 获取：`Object getParamByName(String paraName)` 新增自定义参数：`void addOneParam(String paraName, Object paraObj)` 替换自定义参数：`void setParamMap(Map\u0026amp;lt;String, Object\u0026amp;gt; paramMap)` 泛型方式获取自定义参数：`T getParamByNameWithGeneric(String paraName)` 快速获取和设置用例入参\n获取所有入参：List getInputParams() 按位置获取：Object getInputParamByPos(int i) 新增用例参数：void addInputParam(Object obj)\n 快速获取和设置期望结果\n获取期望结果：Object getExpectResult() 设置期望结果：Boolean setExpectResult(Object objToSet)\n Mock 功能使用 Mock 功能目前是采用 Mockito 的方案，具体资料见 Mockito 英文文档和 Mockito 中文文档\n增加依赖 在 test 模块增加如下依赖（如果已经引入 SOFABoot 的测试 starter 则无需重复引入）\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 默认 spring test 依赖的 mockito 版本是 1.x，想要升级的可以排除后再引入相应的版本\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.mockito\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;mockito-core\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.18.3\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Mockito 用于测试时进行打桩处理，通过它可以指定某个类的某个方法在什么情况下返回什么样的值。Mockito 库能够 Mock 对象、验证结果以及打桩，示例如下：\n@SpringBootTest(classes = SOFABootApplication.class) @TestExecutionListeners(listeners = MockitoTestExecutionListener.class) public class RegisterUserActsTest extends ActsTestBase { @TestBean @Autowired // 这是测试类 public UserService userService; @MockBean // 这是要mock的bean public AccountManageFacadeClient accountManageFacadeClient; @Test(dataProvider = \u0026amp;quot;ActsDataProvider\u0026amp;quot;) public void registerUser (String caseId, String desc, PrepareData prepareData) { runTest(caseId, prepareData); } @Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { super.beforeActsTest(actsRuntimeContext); AccountManageResult accountManageResult = new AccountManageResult(); …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-script/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0d20739dedad1f11277bd02ed65329c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-script/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-script/","summary":"快速理解 ACTS 中的脚本 如果你是一个经常编写测试用例的同学，是不是经常苦于这样的问题： * 不断的 assertEquals 写得快吐了，重复性编码毫无创意； * 少一个 assert 容易假绿","tags":null,"title":"一键脚本化","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-script/","wordcount":1276},{"author":null,"categories":null,"content":" 在本文档将演示如何使用 SOFATracer 集成 Zipkin 进行数据上报展示。\n假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作：\n 下面的示例中将分别演示在 SOFABoot/SpringBoot 工程中 以及 非 SOFABoot/SpringBoot 工程中如何使用。\n 依赖引入 添加 SOFATracer 依赖 工程中添加 SOFATracer 依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置 Zipkin 依赖 考虑到 Zipkin 的数据上报能力不是 SOFATracer 默认开启的能力，所以期望使用 SOFATracer 做数据上报时，需要添加如下的 Zipkin 数据汇报的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.zipkin2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.11.12\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.zipkin.reporter2\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;zipkin-reporter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.7.13\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置文件 在工程的 application.properties 文件下添加一个 SOFATracer 要使用的参数，包括spring.application.name 用于标示当前应用的名称；logging.path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFATracerReportZipkin # logging path logging.path=./logs com.alipay.sofa.tracer.zipkin.enabled=true com.alipay.sofa.tracer.zipkin.baseUrl=http://localhost:9411 启动 Zipkin 服务端 启动 Zipkin 服务端用于接收 SOFATracer 汇报的链路数据，并做展示。Zipkin Server 的搭建可以参考此文档进行配置和服务端的搭建。\n运行 可以将工程导入到 IDE 中运行生成的工程里面中的 main 方法启动应用，也可以直接在该工程的根目录下运行 mvn spring-boot:run，将会在控制台中看到启动日志：\n2018-05-12 13:12:05.868 INFO 76572 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: \u0026#39;SpringMvcSofaTracerFilter\u0026#39; to urls: [/*] 2018-05-12 13:12:06.543 INFO 76572 --- [ main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped \u0026amp;quot;{[/helloZipkin]}\u0026amp;quot; onto public java.util.Map\u0026amp;lt;java.lang.String, java.lang.Object\u0026amp;gt; com.alipay.sofa.tracer.examples.zipkin.controller.SampleRestController.helloZipkin(java.lang.String) 2018-05-12 13:12:07.164 INFO 76572 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http) 可以通过在浏览器中输入 http://localhost:8080/helloZipkin 来访问 REST 服务，结果类似如下：\n{ content: \u0026amp;quot;Hello, SOFATracer Zipkin Remote Report!\u0026amp;quot;, id: 1, success: true } 查看 Zipkin 服务端展示 打开 Zipkin 服务端界面，假设我们部署的 Zipkin 服务端的地址是 http://localhost:9411，打开 URL 并搜索 helloZipkin(由于我们本地访问的地址是 localhost:8080/helloZipkin)，可以看到展示的链路图。\nSpring 工程运行 对于一般的 Spring 工程，我们通常使用 tomcat/jetty 作为 servlet 容器来启动应用。具体工程参考 在 Spring 工程中使用 SOFATracer\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/report-to-zipkin/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d28d192386829452262116de9c32b570","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","summary":"在本文档将演示如何使用 SOFATracer 集成 Zipkin 进行数据上报展示。 假设你已经基于 SOFABoot 构建了一个简单的 Spring Web 工程，那么可以通过如下步骤进行操作： 下面的示例中将分别演","tags":null,"title":"上报数据至 Zipkin","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/report-to-zipkin/","wordcount":661},{"author":null,"categories":null,"content":" 优雅关闭，包括两部分，一个是 RPC 框架作为客户端，一个是 RPC 框架作为服务端。\n作为服务端 作为服务端的时候，RPC 框架在关闭时，不应该直接暴力关闭。在 RPC 框架中\ncom.alipay.sofa.rpc.context.RpcRuntimeContext 在静态初始化块中，添加了一个 ShutdownHook\n// 增加jvm关闭事件 if (RpcConfigs.getOrDefaultValue(RpcOptions.JVM_SHUTDOWN_HOOK, true)) { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run() { if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework catch JVM shutdown event, Run shutdown hook now.\u0026amp;quot;); } destroy(false); } }, \u0026amp;quot;SOFA-RPC-ShutdownHook\u0026amp;quot;)); } 这个 ShutdownHook 的作用是当发布平台/用户执行 kill pid 的时候，会先执行 ShutdownHook 中的逻辑。在销毁操作中，RPC 框架会先执行向注册中心取消服务注册、关闭服务端口等动作。\nprivate static void destroy(boolean active) { RpcRunningState.setShuttingDown(true); for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.preDestroy(); } List\u0026amp;lt;ProviderConfig\u0026amp;gt; providerConfigs = new ArrayList\u0026amp;lt;ProviderConfig\u0026amp;gt;(); for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { providerConfigs.add(bootstrap.getProviderConfig()); } // 先反注册服务端 List\u0026amp;lt;Registry\u0026amp;gt; registries = RegistryFactory.getRegistries(); if (CommonUtils.isNotEmpty(registries) \u0026amp;amp;\u0026amp;amp; CommonUtils.isNotEmpty(providerConfigs)) { for (Registry registry : registries) { registry.batchUnRegister(providerConfigs); } } // 关闭启动的端口 ServerFactory.destroyAll(); // 关闭发布的服务 for (ProviderBootstrap bootstrap : EXPORTED_PROVIDER_CONFIGS) { bootstrap.unExport(); } // 关闭调用的服务 for (ConsumerBootstrap bootstrap : REFERRED_CONSUMER_CONFIGS) { ConsumerConfig config = bootstrap.getConsumerConfig(); if (!CommonUtils.isFalse(config.getParameter(RpcConstants.HIDDEN_KEY_DESTROY))) { // 除非不让主动unrefer bootstrap.unRefer(); } } // 关闭注册中心 RegistryFactory.destroyAll(); // 关闭客户端的一些公共资源 ClientTransportFactory.closeAll(); // 卸载模块 if (!RpcRunningState.isUnitTestMode()) { ModuleFactory.uninstallModules(); } // 卸载钩子 for (Destroyable.DestroyHook destroyHook : DESTROY_HOOKS) { destroyHook.postDestroy(); } // 清理缓存 RpcCacheManager.clearAll(); RpcRunningState.setShuttingDown(false); if (LOGGER.isWarnEnabled()) { LOGGER.warn(\u0026amp;quot;SOFA RPC Framework has been release all resources {}...\u0026amp;quot;, active ? \u0026amp;quot;actively \u0026amp;quot; : \u0026amp;quot;\u0026amp;quot;); } } 其中以 bolt 为例，关闭端口并不是一个立刻执行的动作\n@Override public void destroy() { if (!started) { return; } int stopTimeout = serverConfig.getStopTimeout(); if (stopTimeout \u0026amp;gt; 0) { // 需要等待结束时间 AtomicInteger count = boltServerProcessor.processingCount; // 有正在执行的请求 或者 队列里有请求 if (count.get() \u0026amp;gt; 0 || bizThreadPool.getQueue().size() \u0026amp;gt; 0) { long start = RpcRuntimeContext.now(); if (LOGGER.isInfoEnabled()) { LOGGER.info(\u0026amp;quot;There are {} call in processing and {} call in queue, wait {} ms to end\u0026amp;quot;, count, bizThreadPool.getQueue().size(), stopTimeout); } while ((count.get() \u0026amp;gt; 0 || bizThreadPool.getQueue().size() \u0026amp;gt; 0) \u0026amp;amp;\u0026amp;amp; RpcRuntimeContext.now() - start \u0026amp;lt; stopTimeout) { // 等待返回结果 try { Thread.sleep(10); } catch (InterruptedException ignore) { } } } // 关闭前检查已有请求？ } // 关闭线程池 bizThreadPool.shutdown(); stop(); } 而是 …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/graceful-shutdown/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"53af179e23ba184b01eb8234c055b15d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","summary":"优雅关闭，包括两部分，一个是 RPC 框架作为客户端，一个是 RPC 框架作为服务端。 作为服务端 作为服务端的时候，RPC 框架在关闭时，不应该直接暴力关闭。在","tags":null,"title":"优雅关闭","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/graceful-shutdown/","wordcount":866},{"author":null,"categories":null,"content":" 使用 CloudMesh 轻松实践 Service Mesh Demo 内容介绍 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。\nDemo内容介绍 Service Mesh 将服务间通信能力下沉到基础设施，让应用解耦并轻量化。\n但 Service Mesh 本身的复杂度依然存在，CloudMesh 通过将 Service Mesh 托管在云上，使得您可以轻松的实践 Service Mesh 技术。\n通过我们的 workshop，您可以将以多种编程语言开发的应用，简单部署到 CloudMesh 上，即可获得服务网格提供的强大能力。包括对服务进行访问，通过监控查看流量，体验服务治理、Sidecar 管理和对服务的新版本进行灰度发布等实用功能。\n本次 demo 中，我们将重点体验 CloudMesh 强大的流量控制能力。在灰度发布过程中，可以对灰度流量占比进行精准控制，并通过实时流量监控了解服务网格中流量的实际走向：\n常规的灰度发布，在灰度过程中需要占用两倍容量：\nCloud Mesh 提供的灰度发布功能，可以实现在灰度发布过程中不必占有额外的容量，而且容许在发布期间多次暂停以便修改灰度占比：\nDemo 操作指南 为了方便参加本次 demo 的同学，我们准备了整个 demo 流程的详尽的操作指南。\n更多 请 点击此处访问 在线版本。 下载本地 Demo 幻灯片。 ","date":-62135596800,"description":"使用该指南您可以快速部署应用到 CloudMesh ，对服务进行访问，通过监控查看流量，体验服务治理、Sidecar管理和对服务的新版本进行灰度发布等实用功能。","dir":"guides/kc-cloud-mesh-demo/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e389a65e6736e909718275cd76505525","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-cloud-mesh-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/guides/kc-cloud-mesh-demo/","summary":"使用 CloudMesh 轻松实践 Service Mesh Demo 内容介绍 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。 Demo内容介绍 Service Mesh 将服务间通信能力下沉到基础","tags":null,"title":"使用 CloudMesh 轻松实践 Service Mesh","type":"guides","url":"/sofastack.tech/guides/kc-cloud-mesh-demo/","wordcount":453},{"author":null,"categories":null,"content":"使用 Consul 作为服务注册中心需要添加如下依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.ecwid.consul\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;consul-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 中如下配置：\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 其中后面的值为 consul 的连接地址，如果需要设置一些其他参数，也可以通过\ncom.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;amp;b=2 进行设置\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-consul/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e6b0aa843ea0ad401c3184f6ce87649b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-consul/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-consul/","summary":"使用 Consul 作为服务注册中心需要添加如下依赖 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.ecwid.consul\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;consul-api\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;1.4.2\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 然后在 application.properties 中如下配置： com.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500 其中后面的值为 consul 的连接地址，如果需要设置一些其他参数，也可以通过 com.alipay.sofa.rpc.registry.address=consul://127.0.0.1:8500?a=1\u0026amp;b=2 进行","tags":null,"title":"使用 Consul 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-consul/","wordcount":72},{"author":null,"categories":null,"content":" 本文将介绍如何使用 MOSN 在 SOFAMesh 框架下搭建 Service Mesh 的开发环境，并验证 MOSN 的一些基础路由能力、负载均衡能力等。本文介绍的内容将包括 :\n MOSN 与 SOFAMesh 的关系 准备工作 源码方式部署 SOFAMesh Bookinfo 实验 MOSN 与 SOFAMesh 的关系 我们曾在 MOSN 介绍中介绍过，MOSN 是一款采用 Go 语言开发的 Service Mesh 数据平面代理。而 SOFAMesh 则是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案，MOSN 作为 SOFAMesh 的关键组件用来完成数据面的转发。\n下图是 SOFAMesh 整体框架下，MOSN 的工作示意图。\n注意：当前 MOSN 不支持在原生的 Istio 中直接使用。\n 准备工作 本文以 macOS 为例 ，其他环境可以安装对应版本的软件。\n1. 安装 hyperkit 先安装 docker-for-mac，之后安装驱动\n1.1 安装 docker 下载软件包安装，或者使用如下的命令安装。\n$ brew cask install docker 1.2 安装驱动 $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; chmod +x docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \\ \u0026amp;amp;\u0026amp;amp; sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \\ \u0026amp;amp;\u0026amp;amp; sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 2. 安装 Minikube(也可以购买商业 k8s 集群) 推荐使用 Minikube v0.28 以上来体验，请参考 https://github.com/kubernetes/minikube\n$ brew cask install minikube 3. 启动 Minikube 注意，pilot 至少需要 2G 内存，所以在启动的时候，可以通过加参数的方法给 minikube 添加分配的资源，如果你机器的资源不够，推荐使用商业版本的 k8s 集群。\n$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.15.0 --vm-driver=hyperkit 创建istio 命名空间\n$ kubectl create namespace istio-system 4. 安装 kubectl 命令行工具 kubectl 是用于针对 k8s 集群运行命令的命令行接口，安装参考 https://kubernetes.io/docs/tasks/tools/install-kubectl。\n$ brew install kubernetes-cli 5. 安装 Helm Helm 是一个 k8s 的包管理工具，安装参考 https://docs.helm.sh/using_helm/#installing-helm\n$ brew install kubernetes-helm 源码方式部署 SOFAMesh 1. 下载 SOFAMesh 源码 $ git clone https://github.com/sofastack/sofa-mesh.git 2. 通过 Helm 安装 SOFAMesh 使用 helm template 安装\n首先需要切换到SOFAMesh源码所在目录，然后使用Helm安装istio CRD以及各个组件\n$ cd sofa-mesh $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - $ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - 3. 验证安装 istio-system 命名空间下的 pod 状态都是 Running 时，说明已经部署成功。 如果仅仅是为了运行bookinfo，只需要pilot,injector,citadel这三个pods运行成功就可以满足最低要求\n$ kubectl get pods -n istio-system NAME READY STATUS RESTARTS AGE istio-citadel-6579c78cd9-w57lr 1/1 Running 0 5m istio-egressgateway-7649f76df4-zs8kw 1/1 Running 0 5m istio-galley-c77876cb6-nhczq 1/1 Running 0 5m istio-ingressgateway-5c9c8565d9-d972t 1/1 Running 0 5m istio-pilot-7485f9fb4b-xsvtm 1/1 Running 0 5m istio-policy-5766bc84b9-p2wfj 1/1 Running 0 5m istio-sidecar-injector-7f5f586bc7-2sdx6 1/1 Running 0 5m istio-statsd-prom-bridge-7f44bb5ddb-stcf6 1/1 Running 0 5m istio-telemetry-55ff8c77f4-q8d8q 1/1 Running 0 5m prometheus-84bd4b9796-nq8lg 1/1 Running 0 5m 4. 卸载安装 卸载SOFAMesh\n$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - $ kubectl delete namespace istio-system BookInfo 实验 BookInfo 是一个类似豆瓣的图书应用，它包含四个基础服务：\n Product Page：主页，由 python 开发，展示所有图书信息，它会调用 Reviews 和 Details 服务 Reviews：评论，由 java 开发，展示图书评论，会调用 Ratings 服务 Ratings：评分服务，由 nodejs …","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-with-sofamesh/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9c6461e92180417d3a8ec4f3f2c723fe","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","summary":"本文将介绍如何使用 MOSN 在 SOFAMesh 框架下搭建 Service Mesh 的开发环境，并验证 MOSN 的一些基础路由能力、负载均衡能力等。本文介绍的内容将包括 : MOSN 与 SOFAMesh 的关系 准备工作 源码","tags":null,"title":"使用 MOSN 搭建 Service Mesh 平台","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/","wordcount":1654},{"author":null,"categories":null,"content":"SOFARPC 已支持使用 Nacos 作为服务注册中心。假设你已经根据 Nacos 的快速开始在本地部署好 Nacos Server，服务发现的端口默认设置在 8848。\n在 SOFARPC 中使用 Nacos 作为服务注册中心只需要在 application.properties 中加入如下配置即可：\ncom.alipay.sofa.rpc.registry.address=nacos://127.0.0.1:8848 如果你直接使用了 SOFARPC，而不是 SOFABoot，需要手动添加 nacos 的依赖，其中 version 为用户想使用的 version。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alibaba.nacos\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;nacos-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 当前支持 Nacos 的版本： - SOFARPC：5.5.0 支持 Nacos 服务端版本 0.6.0，SOFABoot: 2.5.3。 - SOFARPC：5.6.0 支持 Nacos 服务端版本 1.0.0。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-nacos/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cc161f22cd2145fe309e63087581adc1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-nacos/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-nacos/","summary":"SOFARPC 已支持使用 Nacos 作为服务注册中心。假设你已经根据 Nacos 的快速开始在本地部署好 Nacos Server，服务发现的端口默认设置在 8848。 在 SOFARPC 中使用 Nacos 作为服务","tags":null,"title":"使用 Nacos 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-nacos/","wordcount":232},{"author":null,"categories":null,"content":"SOFARPC 已支持使用 SOFARegistry 作为服务注册中心。假设你已经根据 SOFARegistry 的快速开始在本地部署好 SOFARegistry Server，服务发现的端口默认设置在 9603。\n在 SOFARPC 中使用 SOFARegistry 作为服务注册中心首先要添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.2.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 中加入如下配置即可：\ncom.alipay.sofa.rpc.registry.address=sofa://127.0.0.1:9603 当前支持 SOFARegistry 的版本：\nSOFARPC: 5.5.2, SOFABoot: 2.6.3。\n由于本次发布的时间问题，暂时需要用户指定SOFARPC Starter的版本\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;5.5.2\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFARPC 集成验证 SOFARegistry 服务端版本：5.2.0\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-sofa/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"65085018ce2b2b2ef452993bb79a69de","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-sofa/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-sofa/","summary":"SOFARPC 已支持使用 SOFARegistry 作为服务注册中心。假设你已经根据 SOFARegistry 的快速开始在本地部署好 SOFARegistry Server，服务发现的端口默认设置在 9603。 在 SOFARPC 中使用 SOFARegistry 作为服务","tags":null,"title":"使用 SOFARegistry 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-sofa/","wordcount":182},{"author":null,"categories":null,"content":" 使用 SOFAStack 快速构建微服务 前置条件 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n [必选]部署注册中心：https://www.sofastack.tech/projects/sofa-registry/server-quick-start/ [必须]部署数据库：本地自行搭建数据库，然后导入 DDL.sql [可选]部署 LookoutServer：https://www.sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/ [可选]部署 Zipkin：https://zipkin.io/pages/quickstart.html 实验内容 本实验基于 SOFAStack 快速构建一个微服务，主要包括以下几个部分：\n 使用 SOFABoot + SOFARPC 发布服务 使用 SOFABoot + SOFARPC 调用服务 通过 ZipKin 查看 SOFATracer 上报的 Tracer 信息 通过 SOFALookout 查看上报的 Metrics 信息 架构图 任务 1、任务准备 从 github 上将 demo 工程克隆到本地\ngit clone https://github.com/sofastack-guides/kc-sofastack-demo.git 然后将工程导入到 IDEA 或者 eclipse。导入之后界面如下：\n balance-mng：余额管理系统，提供扣减余额服务 stock-mng：库存管理系统，提供扣减库存服务 2、引入依赖 将下面的依赖引入到 balance-mng 和 stock-mng 工程模块的 pom.xml 文件中。\n\u0026amp;lt;!--SOFARPC 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFATracer 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;tracer-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFARegistry 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--runtime 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!--SOFALookout 依赖--\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; balance-mng 工程需要将依赖引入 balance-mng/balance-mng-impl/pom.xml 文件：\nstock-mng 工程直接将依赖引入 stock-mng/pom.xml 文件：\n3、添加配置 将如下配置复制到 balance-mng 和 stock-mng 工程模块的 application.properties 中。\n# 1、添加服务注册中心地址 com.alipay.sofa.rpc.registry.address=sofa://localhost:9603 # 2、添加 tracer 数据上报的服务端 zipkin 地址 # 如果上面前置条件未搭建 tracer，可以不配置 com.alipay.sofa.tracer.zipkin.base-url=http://localhost:9411 # 3、添加 metrics 数据上报的服务端地址 # 如果上面前置条件未搭建 lookout-server，可以不配置 com.alipay.sofa.lookout.agent-host-address=localhost balance-mng 工程需要将配置添加至 balance-mng/balance-mng-bootstrap/src/main/resources/application.properties 文件：\n另外数据库配置修改为自己的数据库信息：\n# database config spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://localhost:3306/stock_db spring.datasource.username=root spring.datasource.password=root stock-mng 工程需要将配置添加至 stock-mng/src/main/resources/application.properties 文件：\n另外数据库配置修改为自己的数据库信息：\n# database config spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://localhost:3306/stock_db spring.datasource.username=root spring.datasource.password=root 4、修改 unique id 由于所有人共用一套服务发现，为区分不同用户发布的服务，需要为服务增加 unique id。\nKubeCon workshop 会给每个用户准备一个 SOFAStack 账号，格式为 user0@sofastack.io 到 user99@sofastack.io，去掉 @sofastack.io 部分，账户前半部分的 user0 至 user99 即可作为 unique id。\n 注意：balance-mng 和 stock-mng 里的 unique id 需要一致。 …","date":-62135596800,"description":"本指南将基于 SOFAStack 快速构建一个微服务。","dir":"guides/sofastack-quick-start/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"78bfd4806a86dc15ac86eee16fb85c82","permalink":"https://sofastack.github.io/sofastack.tech/guides/sofastack-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/sofastack-quick-start/","summary":"使用 SOFAStack 快速构建微服务 前置条件 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 [必选]部署注册中心：https://ww","tags":null,"title":"使用 SOFAStack 快速构建微服务","type":"guides","url":"/sofastack.tech/guides/sofastack-quick-start/","wordcount":1486},{"author":null,"categories":null,"content":" 使用 Seata 保障支付一致性 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。\n在开始该 demo 之前先完成《使用 SOFAStack 快速构建微服务》，如果没有完成，可以基于仓库里的 kc-sofastack-demo 工程为基线完成下面的 demo，该 demo 是在它基础上加上 Seata 分布式事务。但该 demo 不是只能应用于 SOFA，可以适用于任何 java 技术栈应用。\nAT 模式 1、引入 maven 依赖 将下面的依赖引入到父工程的 pom 文件中（kc-sofastack-demo/pom.xml）:\n\u0026amp;lt;properties\u0026amp;gt; \u0026amp;lt;seata.version\u0026amp;gt;0.6.1\u0026amp;lt;/seata.version\u0026amp;gt; \u0026amp;lt;netty4.version\u0026amp;gt;4.1.24.Final\u0026amp;lt;/netty4.version\u0026amp;gt; \u0026amp;lt;/properties\u0026amp;gt; \u0026amp;lt;dependencyManagement\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${seata.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;javax.servlet\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;servlet-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${netty4.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;/dependencies\u0026amp;gt; \u0026amp;lt;/dependencyManagement\u0026amp;gt; 将下面的依赖引入到 stock-mng 工程的 pom 文件中（kc-sofastack-demo/stock-mng/pom.xml）:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 将下面的依赖引入到 balance-mng-impl 工程的 pom 文件中（kc-sofastack-demo/balance-mng/balance-mng-impl/pom.xml）:\n\u0026amp;lt;dependencies\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.seata\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;seata-server\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.netty\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;netty-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependencies\u0026amp;gt; 2、使用 Seata 的 DataSourceProxy 代理实际的数据源，并配置 GlobalTransactionScanner 扫描@GlobalTransaction 注解 将下面的 java 代码段加到 BalanceMngApplication 和 StockMngApplication 类的 main 方法下面:\nimport io.seata.rm.datasource.DataSourceProxy; import io.seata.spring.annotation.GlobalTransactionScanner; public static void main(String[] args) { SpringApplication.run(BalanceMngApplication.class, args); } @Configuration public static class DataSourceConfig { @Bean @Primary @ConfigurationProperties(prefix = \u0026amp;quot;spring.datasource.hikari\u0026amp;quot;) public DataSource dataSource(DataSourceProperties properties) { HikariDataSource dataSource = createDataSource(properties, HikariDataSource.class); if (properties.getName()!=null \u0026amp;amp;\u0026amp;amp; properties.getName().length() \u0026amp;gt; 0) { dataSource.setPoolName(properties.getName()); } return new DataSourceProxy(dataSource); } @SuppressWarnings(\u0026amp;quot;unchecked\u0026amp;quot;) protected …","date":-62135596800,"description":"该指南将向您展示如何使用开源分布式事务框架 Seata 的 AT 模式、TCC 模式解决业务数据的最终一致性问题。 ","dir":"guides/kc-seata-demo/","fuzzywordcount":2400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"60071a0eb44bf0901fb187eefd63ccdb","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-seata-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/guides/kc-seata-demo/","summary":"使用 Seata 保障支付一致性 注意：您需要自行部署后端环境依赖，并修改示例中的服务依赖地址即可使用。 在开始该 demo 之前先完成《使用 SOFAStack 快速构建微服务》，如果","tags":null,"title":"使用 Seata 保障支付一致性","type":"guides","url":"/sofastack.tech/guides/kc-seata-demo/","wordcount":2320},{"author":null,"categories":null,"content":" 使用 Zookeeper 作为服务注册中心只需要在 application.properties 中如下配置即可：\ncom.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 注意：考虑掉服务的实时性，以下特性暂不支持\nSOFABoot RPC 也提供一个缓存文件(目前暂不支持)，当 Zookeeper 不可用时，使用该缓存文件进行服务发现。配置该缓存文件的方式如下：\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry Zookeeper Auth 支持 当用户需要对发布和消费服务，进行权限认证的时候，可以通过在操作 zookeeper 时，指定对应的目录和账号密码来进行读写。这样只有使用了相同密码的 服务方或者消费方才能进行读写。\nSOFARPC API 支持 在构造注册中心的时候，将Auth添加上\nparameters.put(\u0026amp;quot;scheme\u0026amp;quot;, \u0026amp;quot;digest\u0026amp;quot;); //如果存在多个认证信息，则在参数形式为为user1:passwd1,user2:passwd2 parameters.put(\u0026amp;quot;addAuth\u0026amp;quot;, \u0026amp;quot;sofazk:rpc1\u0026amp;quot;); registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181/authtest\u0026amp;quot;) .setParameters(parameters); 之后其他没有使用正确auth的，将无法访问authtest目录\nXML 方式支持 如下使用即可\ncom.alipay.sofa.rpc.registry.address=zookeeper://xxx:2181?file=/home/admin/registry\u0026amp;amp;scheme=digest\u0026amp;amp;addAuth=sofazk:rpc1 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-zookeeper/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"71d6486c5577cc85d84c56688cdf2af1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","summary":"使用 Zookeeper 作为服务注册中心只需要在 application.properties 中如下配置即可： com.alipay.sofa.rpc.registry.address=zookeeper://127.0.0.1:2181 注意：考虑掉服务的实时性，以下特性暂不支持 SOFABoot RPC 也提供一个缓存文件(目前暂不支持)，当 Zookeeper 不可","tags":null,"title":"使用 Zookeeper 作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-zookeeper/","wordcount":309},{"author":null,"categories":null,"content":"使用本地文件作为服务注册中心在 application.properties 中如下配置即可：\ncom.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg 其中 /home/admin/registry/localRegistry.reg 就是使用的本地文件的目录。\n对于 windows 用户，则以上地址类似：\ncom.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-local/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"33bc89393392e21b3917f090313c0df5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-local/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-local/","summary":"使用本地文件作为服务注册中心在 application.properties 中如下配置即可： com.alipay.sofa.rpc.registry.address=local:///home/admin/registry/localRegistry.reg 其中 /home/admin/registry/localRegistry.reg 就是使用的本地文件的目录。 对于 windows 用户，则以上地址类似： com.alipay.sofa.rpc.registry.address=local://c://users/localRegistry.reg","tags":null,"title":"使用本地文件作为注册中心","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-local/","wordcount":56},{"author":null,"categories":null,"content":" SOFABoot 是在 Spring Boot 的基础上提供的功能扩展。基于 Spring Boot 的机制，SOFABoot 管理了 SOFA 中间件的依赖，并且提供了 Spring Boot 的 Starter，方便用户在 Spring Boot 中使用 SOFA 中间件。\nSOFABoot 依赖管理 \u0026amp;ndash; Maven 在使用 SOFA 中间件之前，需要引入 SOFABoot 依赖管理。类似 Spring Boot 引入方式，在工程中增加如下 \u0026amp;lt;parent/\u0026amp;gt; 标签配置的方式:\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 其中 ${sofa.boot.version} 为具体的 SOFABoot 版本，参考发布历史。\nSOFABoot 依赖管理 \u0026amp;ndash; Gradle 从 SOFABoot 3.1.1 版本开始，SOFABoot 开始支持使用 Gradle 来进行依赖管理，如果要使用 Gradle 来进行依赖管理，需要按照如下的形式来配置 build.gradle：\nbuildscript { ext { sofaBootVersion = \u0026#39;3.1.1\u0026#39; } repositories { mavenLocal() mavenCentral() } dependencies { classpath(\u0026amp;quot;com.alipay.sofa:sofa-boot-gradle-plugin:${sofaBootVersion}\u0026amp;quot;) } } apply plugin: \u0026#39;java\u0026#39; apply plugin: \u0026#39;eclipse\u0026#39; apply plugin: \u0026#39;com.alipay.sofa.boot\u0026#39; apply plugin: \u0026#39;io.spring.dependency-management\u0026#39; group = \u0026#39;com.example\u0026#39; version = \u0026#39;0.0.1-SNAPSHOT\u0026#39; sourceCompatibility = 1.8 repositories { mavenLocal() mavenCentral() } dependencies { implementation(\u0026#39;com.alipay.sofa:rpc-sofa-boot-starter\u0026#39;) implementation(\u0026#39;org.springframework.boot:spring-boot-starter\u0026#39;) testImplementation(\u0026#39;org.springframework.boot:spring-boot-starter-test\u0026#39;) } 主要有几个步骤：\n 添加 buildScript，增加 sofa-boot-gradle-plugin 的依赖，其中版本号为你使用的 SOFABoot 的版本。 添加两个 plugin，分别是 com.alipay.sofa.boot 和 io.spring.dependency-management。 这样，在 dependencies 里面，就可以直接添加 SOFABoot 管理的各种中间件和依赖了，而不用声明版本号。\n引入 SOFA 中间件 SOFABoot 使用一系列后缀为 -sofa-boot-starter 来标示一个中间件组件，如果想要使用某个中间件，直接添加对应的依赖即可。例如，如果期望使用 SOFARPC，只需增加下面的 Maven 依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;rpc-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 注意上面的 Maven 依赖中并没有声明版本，这个是因为版本已经在 sofaboot-dependencies 里面声明好。这样做的好处是对于 SOFA 中间件，用户统一进行升级即可，不需要单独升级一个中间件的版本，防止出现依赖冲突以及兼容性的问题。目前管控的 SOFABoot 中间件列表如下:\n 中间件 starter SOFARPC rpc-sofa-boot-starter SOFATracer tracer-sofa-boot-starter SOFALookout lookout-sofa-boot-starter 引入 SOFABoot 扩展组件 SOFABoot 基于 Spring Boot 提供了健康检查，模块隔离，类隔离等扩展能力。遵循 Spring Boot 依赖即服务的理念，添加相关组件依赖之后，扩展能力即可生效。目前提供的扩展组件如下：\n 扩展组件 starter 健康检查 actuator-sofa-boot-starter 模块化隔离 isle-sofa-boot-starter 类隔离 sofa-ark-springboot-starter 测试扩展 test-sofa-boot-starter 引入 SOFA 中间件 ark 插件 SOFABoot 提供了类隔离组件 SOFAArk，借助 SOFAArk 容器，用户可以将依赖冲突的三方包打包成 ark 插件。运行时，ark 插件使用单独的类加载器加载，可以和其他 ark 插件以及业务依赖隔离，解决类冲突问题。SOFABoot 官方提供了 SOFARPC 和 SOFATracer 的 ark 插件，例如在应用中引入 SOFARPC ark 插件依赖替代 SOFARPC starter，从而隔离应用和 SOFARPC 及其间接依赖。目前管控的 ark 插件列表如下:\n Ark插件 plugin SOFARPC rpc-sofa-boot-plugin SOFATracer tracer-sofa-boot-plugin 引入 SOFABoot 命名空间 使用 SOFA 中间件时，需要在 XML 中根据中间件的具体使用方式添加相应的配置，这个时候需要引入 SOFABoot 的命名空间 xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; 以能够正确解析相应的配置标签，示例：\n\u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/dependency-management/","fuzzywordcount":1000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dabdbd425f20dee4d7ab580d43574456","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/dependency-management/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/dependency-management/","summary":"SOFABoot 是在 Spring Boot 的基础上提供的功能扩展。基于 Spring Boot 的机制，SOFABoot 管理了 SOFA 中间件的依赖，并且提供了 Spring Boot 的 Starter，方便用户在 Spring Boot 中使用","tags":null,"title":"依赖管理","type":"projects","url":"/sofastack.tech/projects/sofa-boot/dependency-management/","wordcount":981},{"author":null,"categories":null,"content":"SOFARPC 使用了一些三方开源组件，他们分别是：\n一些主要依赖：\n Netty under Apache License 2.0 SLF4j under the MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 一些扩展依赖：\n protobuf under New BSD License Snappy under Apache License 2.0 dubbo under Apache License 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b6c87388d5c1462f13d92012639a08b2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/notice/","summary":"SOFARPC 使用了一些三方开源组件，他们分别是： 一些主要依赖： Netty under Apache License 2.0 SLF4j under the MIT License SOFA Bolt under Apache License 2.0 Javassist under Apache License 2.0 Resteasy under Apache License 2.0 SOFA Hessian under Apache License 2.0 一些扩展依赖： protobuf under New BSD License","tags":null,"title":"依赖组件版权说明","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/notice/","wordcount":87},{"author":null,"categories":null,"content":" SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 的能力。如果你需要使用 SOFA 中间件，那么建议使用 SOFABoot 的健康检查能力的扩展，来更优雅的上线应用实例\n引入健康检查扩展 要引入 SOFABoot 的健康检查能力的扩展，只需要引入以下的 Starter 即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 如果不引入 SOFABoot 的健康检查扩展，用户依然可以直接依赖 HealthIndicator 接口进行原生的 Spring Boot Actuator 的 Liveness Check。\n安全提醒 从 SOFABoot 2.3.0 开始，由于健康检查能力依赖于 SpringBoot 1.4.x 里的 Actuator 组件，而 Actuator 会默认开启很多 EndPoint，例如 /dump，/trace 等等，可能存在安全风险，可以参照官方文档里的安全建议进行设置。\n SpringBoot 1.5.x 和 SpringBoot 2.x 已修复了部分安全行为，SOFABoot 将通过升级 SpringBoot 内核进行支持。\n 查看健康检查结果 加入健康检查扩展之后，我们可以直接在浏览器中输入 http://localhost:8080/health/readiness 来查看 Readiness Check 的结果。如果要查看 Liveness Check 的结果，可以直接查看 Spring Boot 的健康检查的 URL http://localhost:8080/health。\n除了通过 URL 来查看健康检查的结果之外，在 SOFABoot 中，还可以通过查看具体的日志来确定健康检查的结果，日志的目录位于 health-check 目录下，日志的内容大概如下：\n2018-04-06 23:29:50,240 INFO main - Readiness check result: success 目前 SOFA 中间件已经通过 SOFABoot 的 Readiness Check 的能力来控制了上游流量的进入，但是一个应用的流量可能并不是全部都是从中间件进入的，比较常见的还有从负载均衡器进入的，为了控制从负载均衡器进入的流量，建议使用者通过 PAAS 来访问 Readiness Check 的结果，根据结果来控制是否要在负载均衡器中上线对应的节点。\n注: 自 SOFABoot 2.x 之后，不再间接引入 spring-boot-starter-web 依赖，如果需要在浏览器中查看健康检查结果，需要额外在工程中引入 web 容器依赖。\n注: 在 SOFABoot 3.x 中调整了 endpoint 路径，health/readiness 更改为 actuator/readiness\n扩展 Readiness Check 能力 在 Readiness Check 的各个阶段，SOFABoot 都提供了扩展的能力，应用可以根据自己的需要进行扩展，在 2.x 版本中，可供扩展的点如下：\n 回调接口 说明 org.springframework.context.ApplicationListener 如果想要在 Readiness Check 之前做一些事情，那么监听这个 Listener 的 SofaBootBeforeHealthCheckEvent 事件。 org.springframework.boot.actuate.health.HealthIndicator 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 com.alipay.sofa.healthcheck.startup.SofaBootAfterReadinessCheckCallback 如果想要在 Readiness Check 之后做一些事情，那么可以扩展 SOFABoot 的这个接口。 在 3.x 版本中，可供扩展点如下：\n 回调接口 说明 com.alipay.sofa.healthcheck.core.HealthChecker 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，可以直接扩展该接口。相较于 Spring Boot 本身的 HealthIndicator 接口，该接口提供了一些额外的参数配置，比如检查失败重试次数等。 org.springframework.boot.actuate.health.HealthIndicator 如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 org.springframework.boot.actuate.health.ReactiveHealthIndicator 在 WebFlux 中，如果想要在 SOFABoot 的 Readiness Check 里面增加一个检查项，那么可以直接扩展 Spring Boot 的这个接口。 com.alipay.sofa.healthcheck.startup.ReadinessCheckCallback 如果想要在 Readiness Check 之后做一些事情，那么可以扩展 SOFABoot 的这个接口。 需要指出的是，上述四个扩展接口均可以通过 Spring Boot 标准的 Ordered, PriorityOrdered 和注解 @Order 实现执行顺序的设置。\nReadiness Check 配置项 应用在引入 SOFABoot 的健康检查扩展之后，可以在 Spring Boot 的配置文件 application.properties 中添加相关配置项来定制 Readiness Check 的相关行为。\n Readiness Check 配置项 说明 默认值 开始支持版本 com.alipay.sofa.healthcheck.skip.all 是否跳过整个 Readiness Check 阶段 false 2.4.0 com.alipay.sofa.healthcheck.skip.component 是否跳过 SOFA 中间件的 Readiness Check false 2.4.0 com.alipay.sofa.healthcheck.skip.indicator 是否跳过 HealthIndicator 的 Readiness Check false 2.4.0 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/health-check/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a366b25125fa4aedb08a9cef572db1c8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/health-check/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/health-check/","summary":"SOFABoot 为 Spring Boot 的健康检查能力增加了 Readiness Check 的能力。如果你需要使用 SOFA 中间件，那么建议使用 SOFABoot 的健康检查能力的扩展，来更优雅的上线应用实例 引入健康检查扩展 要","tags":null,"title":"健康检查","type":"projects","url":"/sofastack.tech/projects/sofa-boot/health-check/","wordcount":1269},{"author":null,"categories":null,"content":" 目前默认生效的的扩展模块是：lookout-ext-jvm，lookout-ext-os(from v1.5.0)。\n JVM 线程 metric name metric tags specification jvm.threads.totalStarted \u0026amp;mdash; jvm.threads.active \u0026amp;mdash; jvm.threads.peak \u0026amp;mdash; jvm.threads.daemon \u0026amp;mdash; JVM 类加载 metric name metric tags specification jvm.classes.unloaded \u0026amp;mdash; jvm.classes.loaded \u0026amp;mdash; jvm.classes.total \u0026amp;mdash; JVM 内存 metric name metric tags specification jvm.memory.heap.init \u0026amp;mdash; jvm.memory.heap.used \u0026amp;mdash; jvm.memory.heap.max \u0026amp;mdash; jvm.memory.heap.committed \u0026amp;mdash; JVM 垃圾回收 metric name metric tags specification jvm.gc.young.time \u0026amp;mdash; jvm.gc.young.count \u0026amp;mdash; jvm.gc.old.time \u0026amp;mdash; jvm.gc.old.count \u0026amp;mdash; 机器文件系统信息 metric name metric tags specification instance.file.system.free.space root（文件系统根目录名） \u0026amp;mdash; instance.file.system.total.space root \u0026amp;mdash; instance.file.system.usabe.space root \u0026amp;mdash; 机器信息 metric name metric tags specification instance.mem.free \u0026amp;mdash; instance.mem.total \u0026amp;mdash; instance.processors \u0026amp;mdash; instance.uptime \u0026amp;mdash; instance.systemload.average \u0026amp;mdash; Linux 操作系统信息 （1.5.0版本之后默认启用） metric name metric tags specification os.systemload.average.1min \u0026amp;mdash; os.systemload.average.5min \u0026amp;mdash; os.systemload.average.15min \u0026amp;mdash; os.cpu.idle \u0026amp;mdash; os.cpu.iowait \u0026amp;mdash; os.cpu.irq \u0026amp;mdash; os.cpu.nice \u0026amp;mdash; os.cpu.softirq \u0026amp;mdash; os.cpu.system \u0026amp;mdash; os.cpu.user \u0026amp;mdash; os.disk.usage.percent.used device,root,type \u0026amp;mdash; os.disk.usage.total.bytes device,root,type \u0026amp;mdash; os.disk.usage.used.bytes device,root,type \u0026amp;mdash; os.net.stats.in.bytes intfc \u0026amp;mdash; os.net.stats.in.compressed intfc \u0026amp;mdash; os.net.stats.in.dropped intfc \u0026amp;mdash; os.net.stats.in.errs intfc \u0026amp;mdash; os.net.stats.in.fifo.errs intfc \u0026amp;mdash; os.net.stats.in.frame.errs intfc \u0026amp;mdash; os.net.stats.in.multicast intfc \u0026amp;mdash; os.net.stats.in.packets intfc \u0026amp;mdash; os.net.stats.out.bytes intfc \u0026amp;mdash; os.net.stats.out.carrier.errs intfc \u0026amp;mdash; os.net.stats.out.collisions intfc \u0026amp;mdash; os.net.stats.out.compressed intfc \u0026amp;mdash; os.net.stats.out.dropped intfc \u0026amp;mdash; os.net.stats.out.errs intfc \u0026amp;mdash; os.net.stats.out.fifo.errs intfc \u0026amp;mdash; os.net.stats.out.packets intfc \u0026amp;mdash; os.memory.stats.buffers.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.cached.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.free.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 os.memory.stats.total.bytes \u0026amp;mdash; \u0026amp;gt;= 1.5.3 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-ext-metrics/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c8a4fb3d904e359e99db9d4e81e60812","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","summary":"目前默认生效的的扩展模块是：lookout-ext-jvm，lookout-ext-os(from v1.5.0)。 JVM 线程 metric name metric tags specification jvm.threads.totalStarted \u0026mdash; jvm.threads.active \u0026mdash; jvm.threads.peak","tags":null,"title":"内置扩展 Metrics 指标","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/client-ext-metrics/","wordcount":296},{"author":null,"categories":null,"content":" 分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等） Zab：被应用在 zookeeper 中，业界使用广泛，但没有抽象成通用的 library Raft：以容易理解著称，业界也涌现出很多 raft 实现，比如大名鼎鼎的 etcd, braft, tikv 等 什么是 Raft？ Raft 是一种更易于理解的分布式共识算法，核心协议本质上还是师承 paxos 的精髓，不同的是依靠 raft 模块化的拆分以及更加简化的设计，raft 协议相对更容易实现。\n模块化的拆分主要体现在：Raft 把一致性协议划分为 Leader 选举、MemberShip 变更、日志复制、Snapshot 等几个几乎完全解耦的模块\n更加简化的设计则体现在：Raft 不允许类似 paxos 中的乱序提交、简化系统中的角色状态（只有 Leader、Follower、Candidate三种角色）、限制仅 Leader 可写入、使用随机化的超时时间来设计 Leader Election 等等\n特点：Strong Leader 系统中必须存在且同一时刻只能有一个 leader，只有 leader 可以接受 clients 发过来的请求 Leader 负责主动与所有 followers 通信，负责将\u0026amp;rsquo;提案\u0026amp;rsquo;发送给所有 followers，同时收集多数派的 followers 应答 Leader 还需向所有 followers 主动发送心跳维持领导地位(保持存在感) 一句话总结 Strong Leader: \u0026amp;ldquo;你们不要 BB! 按我说的做，做完了向我汇报!\u0026amp;rdquo; 另外，身为 leader 必须保持一直 BB(heartbeat) 的状态，否则就会有别人跳出来想要 BB\n复制状态机 对于一个无限增长的序列 a[1, 2, 3…]，如果对于任意整数 i，a[i] 的值满足分布式一致性，这个系统就满足一致性状态机的要求 基本上所有的真实系统都会有源源不断的操作，这时候单独对某个特定的值达成一致显然是不够的。为了让真实系统保证所有的副本的一致性，通常会把操作转化为 write-ahead-log(WAL)。然后让系统中所有副本对 WAL 保持一致，这样每个副本按照顺序执行 WAL 里的操作，就能保证最终的状态是一致的\n Client 向 leader 发送写请求 Leader 把\u0026amp;rsquo;操作\u0026amp;rsquo;转化为 WAL 写本地 log 的同时也将 log 复制到所有 followers Leader 收到多数派应答, 将 log 对应的\u0026amp;rsquo;操作\u0026amp;rsquo; 应用到状态机 回复 client 处理结果 Raft 中的基本概念 Raft-node 的 3 种角色/状态 Follower：完全被动，不能发送任何请求，只接受并响应来自 leader 和 candidate 的 message，每个节点启动后的初始状态一定是 follower Leader：处理所有来自客户端的请求，以及复制 log 到所有 followers Candidate：用来竞选一个新 leader （candidate 由 follower 触发超时而来） Message 的 3 种类型 RequestVote RPC：由 candidate 发出，用于发送投票请求 AppendEntries (Heartbeat) RPC：由 leader 发出，用于 leader 向 followers 复制日志条目，也会用作 Heartbeat （日志条目为空即为 Heartbeat） InstallSnapshot RPC：由 leader 发出，用于快照传输，虽然多数情况都是每个服务器独立创建快照，但是leader 有时候必须发送快照给一些落后太多的 follower，这通常发生在 leader 已经丢弃了下一条要发给该follower 的日志条目(Log Compaction 时清除掉了) 的情况下 任期逻辑时钟 时间被划分为一个个任期 (term)，term id 按时间轴单调递增 每一个任期的开始都是 leader 选举，选举成功之后，leader 在任期内管理整个集群，也就是 \u0026amp;lsquo;选举 + 常规操作\u0026amp;rsquo; 每个任期最多一个 leader，可能没有 leader (spilt-vote 导致) Raft 功能分解 Leader 选举 超时驱动：Heartbeat/Election timeout 随机的超时时间：降低选举碰撞导致选票被瓜分的概率 选举流程： Follower \u0026amp;ndash;\u0026amp;gt; Candidate (选举超时触发) 赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Leader 另一个节点赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Follower 一段时间内没有任何节点器赢得选举：Candidate \u0026amp;ndash;\u0026amp;gt; Candidate 选举动作： Current term++ 发送 RequestVote RPC New Leader 选取原则 (最大提交原则) Candidates include log info in RequestVote RPCs(index \u0026amp;amp; term of last log entry) During elections, choose candidate with log most likely to contain all committed entries Voting server V denies vote if its log is “more complete”: (lastTermV \u0026amp;gt; lastTermC) || ((lastTermV == lastTermC) \u0026amp;amp;\u0026amp;amp; (lastIndexV \u0026amp;gt; lastIndexC)) Leader will have “most complete” log among electing majority 安全性：一个 term，最多选出一个 leader，可以没 leader，下一个 term 再选 影响 raft 选举成功率的几个时间参数： RTT(Round Trip Time)：网络延时 Heartbeat timeout：心跳间隔，通常应该比 election timeout 小一个数量级，目的是让 leader 能够持续发送心跳来阻止 followers 触发选举 Election timeout：Leader 与 followers …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/consistency-raft-jraft/","fuzzywordcount":8000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a0e98df1bec305cca7db6fc34fc97771","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":16,"relpermalink":"/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","summary":"分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? P","tags":null,"title":"分布式一致性 Raft 与 JRaft","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/","wordcount":7950},{"author":"林楠","categories":"SOFAStack","content":" 前言 在实践中，我们通常会使用业务功能模块化的开发模式，部署时将不同模块合并部署，由于团队间技术栈不统一，此时就有可能出现依赖冲突等问题。SOFAArk 定义了一种开发规范，将不同的应用模块打包成 Ark Biz，由一个基座 Biz 和多个 Biz 模块组成部署包，支持两种合并部署的方式，一种是静态合并部署，Ark Biz 以 Maven 依赖的方式引入项目；另一种是在运行时使用 API 或者 配置中心（Zookeeper）动态地安装或卸载 Biz，本文将重点讨论此方式。\nArk Biz 的生命周期 Ark Biz 的生命周期主要包含三条指令：\n install: 安装 Biz uninstall: 卸载 Biz switch: 激活 Biz 在动态的安装和卸载时，Ark Biz 会流转于生命周期的五个阶段，Biz 在不同阶段时的状态如下：\n unresolved: 未注册，此时 Biz 包未被运行时解析 resolved: Biz 包解析完成，且已注册，此时 Biz 包还没有安装或者安装中 activated: Biz 包启动完成，且处于激活状态，可以对外提供服务 broken: Biz 包启动失败后状态 deactivated: Biz 包启动完成，但处于未激活状态(注意这个状态只对 JVM 服务生效，对 RPC 等其他中间件无效) 这里我们可以看一下 Ark Biz 的数据模型 BizModel 类：\npublic class BizModel implements Biz { ... private String bizName; private String bizVersion; private BizState bizState; ... } 在 Ark Biz 的数据模型中 bizState 表示的就是当前状态，可以看到数据模型中定义了 Biz 包的名称和版本号，在运行时 SOFAArk 允许部署相同名称不同版本的 Biz，但只能有一个版本处于 activated 激活状态，其他版本的 Biz 状态将自动处于 deactivated 未激活状态。\ninstall 在入口方法 ArkClient#installOperation 中，下载 Biz 包到本地临时文件，临时文件命名规则：${bizName}-${bizVersion}-${时间戳}。准备好 Biz 包后，调用 installBiz 方法，进入安装主流程。\npublic static ClientResponse installOperation(BizOperation bizOperation) throws Throwable { return installOperation(bizOperation, arguments); } public static ClientResponse installOperation(BizOperation bizOperation, String[] args) throws Throwable { ... if (bizOperation.getParameters().get(Constants.CONFIG_BIZ_URL) != null) { URL url = new URL(bizOperation.getParameters().get(Constants.CONFIG_BIZ_URL)); bizFile = ArkClient.createBizSaveFile(bizOperation.getBizName(), bizOperation.getBizVersion()); FileUtils.copyInputStreamToFile(url.openStream(), bizFile); } return installBiz(bizFile, args); } 安装 Ark Biz 的主流程：\n 解析 Biz 包，创建 BizModel 将 Ark Biz 注册到 Biz Manager 中（如果已经注册过，安装流程将直接结束，并返回提示信息） 启动 Ark Biz 如果启动失败，则关停并卸载 Ark Biz public static ClientResponse installBiz(File bizFile, String[] args) throws Throwable { ... Biz biz = bizFactoryService.createBiz(bizFile); // 1 ClientResponse response = new ClientResponse(); if (bizManagerService.getBizByIdentity(biz.getIdentity()) != null || !bizManagerService.registerBiz(biz)) { // 2 return response.setCode(ResponseCode.REPEAT_BIZ).setMessage( String.format(\u0026amp;quot;Biz: %s has been installed or registered.\u0026amp;quot;, biz.getIdentity())); } try { biz.start(args); // 3 ... response .setCode(ResponseCode.SUCCESS) .setMessage( String.format(\u0026amp;quot;Install Biz: %s success, cost: %s ms, started at: %s\u0026amp;quot;, biz.getIdentity(), end - start, startDate)) .setBizInfos(Collections.\u0026amp;lt;BizInfo\u0026amp;gt; singleton(biz)); return response; } catch (Throwable throwable) { ... response.setCode(ResponseCode.FAILED).setMessage( String.format(\u0026amp;quot;Install Biz: %s fail,cost: %s ms, started at: %s\u0026amp;quot;, biz.getIdentity(), end - start, startDate)); ... try { biz.stop(); // 4 } catch (Throwable e) { ... throw e; } finally { bizManagerService.unRegisterBizStrictly(biz.getBizName(), biz.getBizVersion()); } return response; } } 解析 Ark Biz 当开启内嵌模式时，将 Biz 包解压到 ${Biz}-unpack 目录下，生成展开型的 Biz 包；当未开启内嵌模式时，直接使用原始的 Biz Jar 包，生成压缩型的 Biz …","date":-62135596800,"description":"源码解析 | 动态部署","dir":"projects/sofa-boot/sofa-ark-dynamic-deploy/","fuzzywordcount":3800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"49b198c473b8ee5d8de18d8260661df6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","publishdate":"0001-01-01T00:00:00Z","readingtime":8,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","summary":"前言 在实践中，我们通常会使用业务功能模块化的开发模式，部署时将不同模块合并部署，由于团队间技术栈不统一，此时就有可能出现依赖冲突等问题。SO","tags":["源码解析"],"title":"动态部署","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/","wordcount":3759},{"author":null,"categories":null,"content":" 单元测试 单元测试例子放到自己开发的模块下。\n如果依赖了第三方服务端（例如Zookeeper），请手动加入 profile。参考 registry-zookeeper 模块代码。\n如果依赖了其它模块要集成测试，请放到 test/test-intergrated 模块中。\n如果还依赖了第三方服务端（例如Zookeeper），请放到 test-intergrated-3rd 模块中。\n性能测试 关闭了以下默认开启项目：\n-Dcontext.attachment.enable=false -Dserialize.blacklist.enable=false -Ddefault.tracer= -Dlogger.impl=com.alipay.sofa.rpc.log.SLF4JLoggerImpl -Dmultiple.classloader.enable=false -Devent.bus.enable=false\n我们对 BOLT+hessian 进行了压测。\n服务端：4C8G 虚拟机，千M网络，jdk1.8.0_111；\n客户端：50个客户端并发请求。\n 协议 请求 响应 服务端 TPS 平均RT(ms) bolt+hessian 1K String 1K String 直接返回 10000 1.93 bolt+hessian 1K String 1K String 直接返回 20000 4.13 bolt+hessian 1K String 1K String 直接返回 30000 7.32 bolt+hessian 1K String 1K String 直接返回 40000 15.78 bolt+hessian 1K String 1K String 直接返回 50000(接近极限,错误率0.3%） 26.51 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/test/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ccda7c2372a7f55d61f682b72d3b1dc2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/test/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/test/","summary":"单元测试 单元测试例子放到自己开发的模块下。 如果依赖了第三方服务端（例如Zookeeper），请手动加入 profile。参考 registry-zookeeper 模块代码。 如果依","tags":null,"title":"单元测试与性能测试","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/test/","wordcount":292},{"author":null,"categories":null,"content":" 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git 官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git 协作流程 GitHub 贡献代码流程 提交 issue 不论您是修复 ACTS 的 bug 还是新增 ACTS 的功能，在您提交代码之前，在 ACTS 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. ACTS 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 ACTS 主干代码到您的代码仓库。\n拉分支 ACTS 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式.\ngit clone https://github.com/您的账号名/acts.git 拉分支准备修改代码\ngit branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n 修改完代码后，执行如下命令提交所有修改到本地\ngit commit -am \u0026#39;添加xx功能\u0026#39; 修改代码注意事项 代码风格保持一致 ACTS 通过 Maven 插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码\n 新有修改应该通过已有的单元测试.\n 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\nmvn clean test 也可以通过 IDE 来辅助运行。\n 其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。 * 执行如下命令提交本地修改到 github 上\n``` git push origin \u0026amp;quot;branchname\u0026amp;quot; ``` 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 ACTS 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 ACTS 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 ACTS 的人员， ACTS 人员会 Review 您的代码，符合要求后就会合入主干，成为 ACTS 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 ACTS 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/contributing/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cd68baede6258921f83665ef0a446f1f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/contributing/","summary":"准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git 官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章G","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-acts/contributing/","wordcount":1224},{"author":null,"categories":null,"content":" 可以先去 发展路线 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看 git官方书籍，需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程。 GitHub 贡献代码流程 提交issue 不论您是修复 SOFAArk 的 bug 还是新增 SOFAArk 的功能，在您提交代码之前，在 SOFAArk 的 GitHub 地址上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFAArk 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的fork按钮，复制一份 SOFAArk 主干代码到您的代码仓库。\n拉分支 SOFAArk 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择git/https方式.\ngit clone https://github.com/您的账号名/sofa-ark.git 拉分支准备修改代码\ngit branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\n git branch -a 如果您想切换回主干，执行下面命令:\n git checkout -b master 如果您想切换回分支，执行下面命令：\n git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFAArk 通过 Maven 插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\n mvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\n git commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFAArk 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFAArk 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFAArk 的人员， SOFAArk 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFAArk 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFAArk 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-contribution/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dbf77f98884a71c5c7a3fbb4dd189cfe","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","summary":"可以先去 发展路线 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看 git官方书籍，需要阅","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/","wordcount":1278},{"author":null,"categories":null,"content":" 可以先去 RoadMap 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看 git官方书籍，需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFADashboard 的 bug 还是新增 SOFADashboard 的功能，在您提交代码之前，在 SOFADashboard 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。\n这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFADashboard 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFADashboard 主干代码到您的代码仓库。\n拉分支 SOFADashboard 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式.\ngit clone https://github.com/您的账号名/sofa-dashboard.git 拉分支准备修改代码 bash git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令: bash git checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFADashboard 通过 Maven插件来保持代码格式一致。在提交代码前，务必本地执行\nmvn clean compile 补充单元测试代码\n 新有修改应该通过已有的单元测试.\n 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug\n您可以用如下命令运行所有测试\nmvn clean test 也可以通过 IDE 来辅助运行。 其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地：\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFADashboard 的代码仓库。\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFADashboard 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFADashboard 的人员， SOFADashboard 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFADashboard 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。 对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFADashboard 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/contribution/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"584584be9c13f2d36c85890dd192368a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/contribution/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/contribution/","summary":"可以先去 RoadMap 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看 git官方书籍，需要阅读前几","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/contribution/","wordcount":1262},{"author":null,"categories":null,"content":" 可以先去 发展路线 \u0026amp;amp; 任务认领 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章 Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFARegistry 的 bug 还是新增 SOFARegistry 的功能，在您提交代码之前，在 SOFARegistry 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFARegistry 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFARegistry 主干代码到您的代码仓库。\n拉分支 SOFARegistry 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择 git/https 方式. git clone https://github.com/您的账号名/sofa-registry.git 拉分支准备修改代码 git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFARegistry 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug您可以用如下命令运行所有测试 mvn clean test 也可以通过 IDE 来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFARegistry 的代码仓库.\n提交合并代码到主干的请求 在您的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFARegistry 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request 按钮。选择目标分支,一般就是 master，系统会通知 SOFARegistry 的人员， SOFARegistry 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFARegistry 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFARegistry 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/contributing/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c08b5945719137833634c111c43a8d9e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/contributing/","summary":"可以先去 发展路线 \u0026amp; 任务认领 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git官方书","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-registry/contributing/","wordcount":1264},{"author":null,"categories":null,"content":" 可以先去 发展路线 内了解下开发任务及未来规划。\n 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。\n git 工具用法可以查看git官方书籍,需要阅读前几章来熟悉。 git 协作流程可以查看这篇文章Git协作流程 GitHub 贡献代码流程 提交issue 不论您是修复 SOFARPC 的 bug 还是新增 SOFARPC 的功能，在您提交代码之前，在 SOFARPC 的GitHub上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处:\n 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作. SOFARPC 的维护人员会对您提的bug或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 在达成一致后再开发,并提交代码，减少双方沟通成本，也减少pull request被拒绝的情况。 获取源码 要修改或新增功能，在提 issue 后，点击左上角的fork按钮，复制一份 SOFARPC 主干代码到您的代码仓库。\n拉分支 SOFARPC 所有修改都在分支上进行，修改完后提交 pull request， 在 Code Review 后由项目维护人员 Merge 到主干。\n因此，在获取源码步骤介绍后，您需要：\n 下载代码到本地,这一步您可以选择git/https方式. git clone https://github.com/您的账号名/sofa-rpc.git 在提交pull request请求前, 请将您克隆的代码和远程代码库同步，这样您的pull request会简单清晰 git remote add upstream git@github.com:sofastack/sofa-rpc.git git fetch upstream git rebase upstream/master 拉分支准备修改代码 git checkout -b add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支：\ngit branch -a 如果您想切换回主干，执行下面命令:\ngit checkout -b master 如果您想切换回分支，执行下面命令：\ngit checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFARPC 通过 Maven插件来保持代码格式一致.在提交代码前,务必本地执行\nmvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试. 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试\nmvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等. 对于无用的注释，请直接删除 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档 修改完代码后，执行如下命令提交所有修改到本地:\ngit commit -am \u0026#39;添加xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，就是与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的,那么这里的 origin 是 push 到您的代码仓库，而不是 SOFARPC 的代码仓库.\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFARPC 主干代码了。此时您需要进入您的 GitHub 上的对应仓库，按右上角的 pull request按钮。选择目标分支,一般就是 master，系统会通知 SOFARPC 的人员， SOFARPC 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFARPC 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员.\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFARPC 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/contributing/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"448a7b9a949bd2d9e2e71ac6c237f9df","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/contributing/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/contributing/","summary":"可以先去 发展路线 内了解下开发任务及未来规划。 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 git 工具用法可以查看git官方书籍,需要阅","tags":null,"title":"参与贡献","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/contributing/","wordcount":1351},{"author":null,"categories":null,"content":" 客户端发展规划 v2.0 ，在基于 Java 8 进行重构，v1.0 为支持 Java 6 做了些设计与性能妥协； 集成更多的开源产品； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/plan/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6153fc1f5e000f195d96dfdb03c5b381","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/plan/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/plan/","summary":"客户端发展规划 v2.0 ，在基于 Java 8 进行重构，v1.0 为支持 Java 6 做了些设计与性能妥协； 集成更多的开源产品；","tags":null,"title":"发展规划","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/plan/","wordcount":49},{"author":null,"categories":null,"content":" 任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 代码 支持多个 Web 应用合并部署，采用多 Host/单 Host 两种模式 难 代码 支持 telnet 指令查看 ark plugin 简单 代码 支持 telnet 指令查看 jvm/rpc 服务 中 版本迭代计划 v0.5.0 支持多个 Web 应用合并部署，采用多 Host/单 Host 两种模式 v0.6.0 支持 telnet 指令查看 ark plugin； 支持 telnet 指令查看 jvm/rpc 服务； ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-roadmap/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c4532d11cef15d8fe3ff5e04c7b08f90","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","summary":"任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 代码 支持多个 Web 应用合","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/","wordcount":175},{"author":null,"categories":null,"content":" 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。\n如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关Issue 文档 文档翻译 低 代码 弹性长连接管理方式 低 #56 代码 etcd注册中心实现 中 @wynn5a\n2018-6 #153 代码 eureka注册中心实现 中 @liufeiit\n2018-4 #52 代码 gRPC 支持 高 #57 代码 CXF 协议 高 #58 代码 TLS 支持 高 版本迭代计划 v5.5.0 JSON 序列化支持 H2的TLS安全支持 弹性连接池 hystrix集成 Consul注册中心支持 v5.6.0 grpc 通讯层支持 etcd注册中心支持 SofaMesh支持 BOLT 版本协商与 CRC 校验 v5.7.0 Telnet 内置指令支持 SpringBoot 2.0 支持 Mock功能支持 加密功能支持 v5.8.0 授权支持 SofaRegistry 支持 Reactive 支持 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/roadmap/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6064fc180911f520f6d1590b88595693","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/roadmap/","summary":"任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。 如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。 类型","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/roadmap/","wordcount":292},{"author":null,"categories":null,"content":" 任务列表 欢迎大家领取任务参与贡献。\n 类型 任务 困难度 认领人及时间 计划发布时间 计划完成时间 进度 相关 issue 代码 SOFATracer 性能优化专题 高 issue 18和 issue 11 代码 SOFATracer 支持 HttpClient 中 已经完成，见 HttpClient 接入文档 代码 SOFATracer 数据汇报能力提供在非 SOFABoot 框架下的运行和配置能力 中 已经完成，见 Spring 工程中使用 SOFATracer issue 32 代码 SOFATracer 提供采样能力 中 已经完成，见使用 SOFATracer 的采样能力 issue 10 代码 SOFATracer 支持 Zipkin 2.X.X 版本 中 已经完成，见使用 SOFATracer 远程汇报数据到 Zipkin issue 23 代码 SOFATracer 支持 Druid 中 已经完成，见 DataSource 接入文档 代码 SOFATracer 支持 c3p0 中 已经完成 代码 SOFATracer 支持 Tomcat-JDBC 中 已经完成 代码 SOFATracer 支持 HikariCP 中 已经完成 代码 SOFATracer 支持 dbcp 中 已经完成，见 DataSource 接入文档 代码 SOFATracer 支持 dbcp2 中 已经完成 代码 SOFATracer 支持 Sharding-JDBC 中 代码 SOFATracer 支持 Mysql JDBC Driver 中 代码 SOFATracer 支持 Oracle JDBC Driver 中 代码 SOFATracer 支持 Dubbo 中 代码 SOFATracer 支持 RestTemplate 和 AsyncRestTemplate 中 已经完成 代码 SOFATracer 支持标准Servlet 中 已经完成，见对于标准 servlet 容器的支持（ tomcat/jetty 等） 代码 SOFATracer 支持单机版链路分析并给用户通过注解使用的埋点方式，数据汇报到 Zipkin 中 代码 SOFATracer 支持 Kafka 中 代码 SOFATracer 支持 Redis 中 代码 SOFATracer 支持 hystrix 中 文档 文档翻译 中 版本迭代计划 2.2.0 SOFATracer 支持 JDBC 数据源 SOFATracer 支持 Mysql Driver SOFATracer 支持 Sharding-JDBC SOFATracer 支持 Mysql-JDBC SOFATracer 支持 Druid SOFATracer 支持 c3p0 SOFATracer 支持 Tomcat-JDBC SOFATracer 支持 HikariCP SOFATracer 支持 HttpClient SOFATracer 支持 Zipkin 2.X.X 版本，开发验证并测试 2.3.0 SOFATracer 支持RestTemplate 和 AsyncRestTemplate SOFATracer 支持提供采样能力 SOFATracer 支持标准 servlet 容器 SOFATracer 支持 Zipkin UI 中文界面 SOFATracer 支持数据汇报能力提供在非 SOFABoot 框架下的运行和配置能力 2.4.0 SOFATracer 支持 Dubbo SOFATracer 支持 Kafka SOFATracer 性能优化专题 2.5.0 SOFATracer 支持单机版链路分析并给用户通过注解使用的埋点方式，数据汇报到 Zipkin 展示 SOFATracer 支持 manual report SOFATracer 支持 基于 Opentracing API 埋点方式 SOFATracer 支持 Opentracing 0.30.0+ 版本 ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/roadmap/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8b0a6fbe5f6ea5ae789f5186271073c3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/roadmap/","summary":"任务列表 欢迎大家领取任务参与贡献。 类型 任务 困难度 认领人及时间 计划发布时间 计划完成时间 进度 相关 issue 代码 SOFATracer 性能优化专题 高 issue 18和 issue 11 代码 SOFATracer 支持 HttpClient 中","tags":null,"title":"发展路线","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/roadmap/","wordcount":605},{"author":null,"categories":null,"content":" 发展路线 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。\n如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关issue 文档 文档翻译 低 代码 支持Spring Cloud 中 代码 数据自检 高 代码 黑名单过滤 中 代码 SOFARegistry Dashboard 高 代码 支持其他微服务框架 中 代码 支持 Docker \u0026amp;amp; Kubernetes 高 代码 多语言客户端支持 高 版本迭代计划 v5.3.0 支持 Spring Cloud 数据自检 黑名单过滤 v5.4.0 SOFARegistry Dashboard 支持其他微服务框架 v5.5.0 支持 Docker \u0026amp;amp; Kubernetes 多语言客户端支持 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/roadmap/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b0ab45d52ba3eb7db590a4f5e4197c9e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/roadmap/","summary":"发展路线 任务列表 部分内部已有的功能特性，待内部整理完毕后随各个迭代放出。 如果还没有实现的功能特性会列在下面的表格中，欢迎大家认领任务，参与贡","tags":null,"title":"发展路线 \u0026 任务认领","type":"projects","url":"/sofastack.tech/projects/sofa-registry/roadmap/","wordcount":216},{"author":null,"categories":null,"content":"更多参见：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md\n","date":-62135596800,"description":"","dir":"projects/mosn/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"62efb8e40401ab4612bcccaa6e942c97","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/release-notes/","summary":"更多参见：https://github.com/mosn/mosn/blob/master/CHANGELOG_ZH.md","tags":null,"title":"发布历史","type":"projects","url":"/sofastack.tech/projects/mosn/release-notes/","wordcount":61},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-rpc/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ab7d46caa6906863103b77b742ec7e84","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/release-notes/","summary":"更多参见：https://github.com/sofastack/sofa-rpc/releases","tags":null,"title":"发布历史","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/release-notes/","wordcount":51},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-ark/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-release/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"994c3569ea416ee5b0dea253f08af6be","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-release/","summary":"更多参见：https://github.com/sofastack/sofa-ark/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-release/","wordcount":51},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-dashboard/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/release-node/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3c8e6985123810c9692f47cc56b50081","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/release-node/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/release-node/","summary":"更多参见：https://github.com/sofastack/sofa-dashboard/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/release-node/","wordcount":57},{"author":null,"categories":null,"content":"更多参见：https://github.com/sofastack/sofa-registry/releases\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-notes/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d92dddf77bbbd6078f3f96ba2224a53d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/release-notes/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/release-notes/","summary":"更多参见：https://github.com/sofastack/sofa-registry/releases","tags":null,"title":"发布说明","type":"projects","url":"/sofastack.tech/projects/sofa-registry/release-notes/","wordcount":56},{"author":null,"categories":null,"content":" SOFABoot 提供了模块并行加载以及 Spring Bean 异步初始化能力，用于加快应用启动速度。模块并行加载参考相应文档，下面介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力来提高应用启动速度。\n引入依赖 SOFABoot 在 v2.6.0 开始提供异步初始化 Spring Bean 能力，引入如下 Starter 即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;runtime-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 使用场景 在实际使用 Spring/Spring Boot 开发中，会有一些 Bean 在初始化过程中执行准备操作，如拉取远程配置、初始化数据源等等；在应用启动期间，这类 Bean 会增加 Spring 上下文刷新时间，导致应用启动耗时变长。为了加速应用启动，SOFABoot 通过配置可选项，将 Bean 的初始化方法(init-method) 使用单独线程异步执行，加快 Spring 上下文加载过程，提高应用启动速度。\n使用方法 异步初始化 Bean 的原理是开启单独线程负责执行 Bean 的初始化方法(init-method)，因此在使用过程中，除了引入上述依赖管理，还需要在 Bean 的 xml 定义中配置 sofa:async-init=\u0026amp;quot;true\u0026amp;quot; 属性，用于指定是否异步执行该 Bean 的初始化方法，例如：\n\u0026amp;lt;?xml version=\u0026amp;quot;1.0\u0026amp;quot; encoding=\u0026amp;quot;UTF-8\u0026amp;quot;?\u0026amp;gt; \u0026amp;lt;beans xmlns=\u0026amp;quot;http://www.springframework.org/schema/beans\u0026amp;quot; xmlns:xsi=\u0026amp;quot;http://www.w3.org/2001/XMLSchema-instance\u0026amp;quot; xmlns:sofa=\u0026amp;quot;http://sofastack.io/schema/sofaboot\u0026amp;quot; xsi:schemaLocation=\u0026amp;quot;http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://sofastack.io/schema/sofaboot http://sofastack.io/schema/sofaboot.xsd\u0026amp;quot; default-autowire=\u0026amp;quot;byName\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;!-- async init test --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;testBean\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.runtime.beans.TimeWasteBean\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot; sofa:async-init=\u0026amp;quot;true\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/beans\u0026amp;gt; 配置 SOFABoot 异步初始化能力提供两个属性配置，用于指定负责异步执行 Bean 初始化方法(init-method)的线程池大小： + com.alipay.sofa.boot.asyncInitBeanCoreSize \u0026amp;gt; 线程池基本大小，默认值为 CPU 核数加一 + com.alipay.sofa.boot.asyncInitBeanMaxSize \u0026amp;gt; 线程池中允许的最大线程数大小，默认值为 CPU 核数加一\n配置可以通过 VM -D 参数或者 Spring Boot 配置文件 application.yml 设置。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/speed-up-startup/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ebd933894c7828948b87610d1d0ca020","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/speed-up-startup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-boot/speed-up-startup/","summary":"SOFABoot 提供了模块并行加载以及 Spring Bean 异步初始化能力，用于加快应用启动速度。模块并行加载参考相应文档，下面介绍如何使用 SOFABoot 异步初始化 Spring Bean 能力来提高应用启","tags":null,"title":"启动加速","type":"projects","url":"/sofastack.tech/projects/sofa-boot/speed-up-startup/","wordcount":519},{"author":null,"categories":null,"content":" 启动过程 Ark 1.0 非内嵌模式 打包方式 在 SOFAArk 1.0 中使用 sofa-ark-maven-plugin 打包\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 启动流程图 Ark 1.0 应用的整体启动流程如下图所述： 启动方式 方式一、IDEA 启动 使用 idea 启动 SpringBoot Application 即可\n方式二、命令行启动 Ark 包是可执行 Jar，可直接使用 java -jar 的方式启动，先使用 mvn clean package 进行打包，打包得到 ${bizName}-${bizVersion}-executable-ark.jar，命令行启动\njava -jar ${bizName}-${bizVersion}-executable-ark.jar 启动原理分析 Springboot 应用，ArkApplicationStartListener 实现了 ApplicationListener 接口，监听 Spring 的启动事件，调用SofaArkBootstrap.launch(args)启动 Ark。\npublic class ArkApplicationStartListener implements ApplicationListener\u0026amp;lt;SpringApplicationEvent\u0026amp;gt; { @Override public void onApplicationEvent(SpringApplicationEvent event) { try { if (isSpringBoot2() \u0026amp;amp;\u0026amp;amp; APPLICATION_STARTING_EVENT.equals(event.getClass().getCanonicalName())) { startUpArk(event); } if (isSpringBoot1() \u0026amp;amp;\u0026amp;amp; APPLICATION_STARTED_EVENT.equals(event.getClass().getCanonicalName())) { startUpArk(event); } } catch (Throwable e) { throw new RuntimeException(\u0026amp;quot;Meet exception when determine whether to start SOFAArk!\u0026amp;quot;, e); } } public void startUpArk(SpringApplicationEvent event) { if (LAUNCH_CLASSLOADER_NAME.equals(this.getClass().getClassLoader().getClass().getName())) { // Ark 启动入口，非 Springboot 应用需要手动调用该方法 SofaArkBootstrap.launch(event.getArgs()); } } public boolean isSpringBoot1() { return SpringBootVersion.getVersion().startsWith(\u0026amp;quot;1\u0026amp;quot;); } public boolean isSpringBoot2() { return SpringBootVersion.getVersion().startsWith(\u0026amp;quot;2\u0026amp;quot;); } } SofaArkBootstrap launch 方法里面启了一个线程执行SofaArkBootstrap.remain方法，remain 里面调ClasspathLauncher.launch方法。\npublic class SofaArkBootstrap { private static final String BIZ_CLASSLOADER = \u0026amp;quot;com.alipay.sofa.ark.container.service.classloader.BizClassLoader\u0026amp;quot;; private static final String MAIN_ENTRY_NAME = \u0026amp;quot;remain\u0026amp;quot;; private static EntryMethod entryMethod; public static void launch(String[] args) { try { if (!isSofaArkStarted()) { entryMethod = new EntryMethod(Thread.currentThread()); IsolatedThreadGroup threadGroup = new IsolatedThreadGroup( entryMethod.getDeclaringClassName()); // 参数中指定当前类的remain方法，LaunchRunner.run 里面会用反射调用remain方法 LaunchRunner launchRunner = new LaunchRunner(SofaArkBootstrap.class.getName(), MAIN_ENTRY_NAME, args); Thread launchThread = new Thread(threadGroup, launchRunner, entryMethod.getMethodName()); launchThread.start(); // 等待前面的线程 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-startup-process/","fuzzywordcount":4100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c89b63bd70a937cf29bbf165fda00444","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","publishdate":"0001-01-01T00:00:00Z","readingtime":9,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","summary":"启动过程 Ark 1.0 非内嵌模式 打包方式 在 SOFAArk 1.0 中使用 sofa-ark-maven-plugin 打包 \u0026lt;build\u0026gt; \u0026lt;plugins\u0026gt; \u0026lt;plugin\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;sofa-ark-maven-plugin\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${sofa.ark.version}\u0026lt;/version\u0026gt; \u0026lt;executions\u0026gt; \u0026lt;execution\u0026gt; \u0026lt;id\u0026gt;default-cli\u0026lt;/id\u0026gt; \u0026lt;!--goal executed to generate executable-ark-jar --\u0026gt; \u0026lt;goals\u0026gt; \u0026lt;goal\u0026gt;repackage\u0026lt;/goal\u0026gt; \u0026lt;/goals\u0026gt; \u0026lt;configuration\u0026gt; \u0026lt;outputDirectory\u0026gt;./target\u0026lt;/outputDirectory\u0026gt; \u0026lt;!--default none--\u0026gt; \u0026lt;arkClassifier\u0026gt;executable-ark\u0026lt;/arkClassifier\u0026gt; \u0026lt;/configuration\u0026gt; \u0026lt;/execution\u0026gt; \u0026lt;/executions\u0026gt; \u0026lt;/plugin\u0026gt; \u0026lt;/plugins\u0026gt; \u0026lt;/build\u0026gt; 启动流程图 Ark 1.0 应用的整体启动流程如","tags":null,"title":"启动过程","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/","wordcount":4023},{"author":null,"categories":null,"content":" 本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sidecar的部署模式，满足用户的各种需求。\n前置要求 Docker Docker Compose 安装步骤 下载最新的 release 包 解压安装文件，并且进入解压后的路径，安装路径包含： 示例应用路径 samples/ /bin 路径下应该能找到 istioctl 客户端可执行文件，istioctl 可用于创建路由规则和策略 配置文件 istion.VERSION 把 Istio 的 bin 路径添加到系统的 PATH。比如，在 MacOS 或者 Linux 系统下执行如下命令：\nexport PATH=$PWD/bin;$PATH 安装helm 创建命名空间 SHELL kubectl create namespace istio-system 使用helm安装istio CRD\nhelm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - 使用helm安装各个组件 SHELL helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - 确认所有 pod 都在运行中：\nkubectl get pod -n istio-system 如果 Istio pilot 容器意外终止，确保运行 istioctl context-create 命令，并且重新执行上一个命令。\n部署应用程序 现在开始部署 Bookinfo 示例程序 为 default 命名空间打上标签 istio-injection=enabled，实现 Sidecar 自动注入\nkubectl label namespace default istio-injection=enabled 使用 kubectl 部署Bookinfo的服务\nkubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml 确认所有的服务和 Pod 都已经正确的定义和启动\nkubectl get services kubectl get pods 卸载 Istio helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - kubectl delete namespace istio-system ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"1de4868fa0e9c73d932343847864d7fb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","summary":"本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sid","tags":null,"title":"在 Kubernetes 中快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/","wordcount":465},{"author":null,"categories":null,"content":" 本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。\nSOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sidecar的部署模式，满足用户的各种需求。\n前置要求 Kubernetes 安装 Helm 安装步骤 Step 1. 下载最新的 release 包 Step 2. 把 Istio 的 bin 路径添加到系统的 PATH。比如，在 Linux 系统下执行如下命令：\nexport PATH=$PWD/bin;$PATH Step 3. 创建命名空间\nkubectl create namespace istio-system Step 4. 使用helm安装istio CRD\nhelm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f - Step 5. 使用helm安装各个组件\nhelm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f - Step 6. 确认所有 pod 都在运行中\nkubectl get pod -n istio-system 部署应用程序 现在开始部署 Bookinfo 示例程序。\n为 default 命名空间打上标签 istio-injection=enabled，实现 Sidecar 自动注入：\nkubectl label namespace default istio-injection=enabled 使用 kubectl 部署Bookinfo的服务：\nkubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml 确认所有的服务和 Pod 都已经正确的定义和启动：\nkubectl get services kubectl get pods 卸载 Istio helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f - kubectl delete namespace istio-system ","date":-62135596800,"description":"","dir":"projects/sofa-mesh/sofa-mesh-setup/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"940d012b4883e5c91bf777916cd3c6b3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","summary":"本文旨在描述如何在 Kubernetes 快速开始安装和配置 Istio。 SOFA Mosn 不仅可以支持 Istio 标准的部署模式，也能支持单方面的 Inbound Sidecar，Outbound Sid","tags":null,"title":"在 Kubernetes 中快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/","wordcount":362},{"author":null,"categories":null,"content":" 基于 Serverless 轻松构建云上应用 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。\n作为云原生技术前进方向之一，Serverless 架构让您进一步提高资源利用率，更专注于业务研发。通过我们的 workshop，您 可以体验到快速创建 Serverless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错等产品新功能。\nWorkshop 操作内容 流程图 应用架构图 效果预览 \nStep 0: 前期准备 应用 clone：https://github.com/sofastack-guides/kc-serverless-demo \n讲师演示 \n快速发布后端 Java 应用 选择快速创建 选择 Java Runtime 上传代码包 balance-mng.jar 入口方法可自动识别 端口：8080 创建完成后，复制保存后端服务的地址 查看后端服务计算实例数量：0 快速发布前端 Node JS 应用 选择创建应用服务 创建应用，选择技术栈为 Node JS 上传代码包 prod-stockmng-v1.zip 运行时选择 nodejs-0.0.1.1-pre 入口方法可自动识别 端口： 3000 环境变量设置 BALANCEMNG_URL 为后端服务的地址 \nStep 1: 查看 Serverless 应用服务 访问 Serverless 应用服务地址 https://sas.shared.cloud.alipay.com/ 使用账号，密码登陆 选择 workspace： workspace0【user00-09】 workspace1【user10-19】 \u0026amp;hellip; workspace9【user90-99】 查看前端应用服务：kubectl frontend demo xx【00-99】 查看后端应用服务：kubectl backend demo xx【00-99】 查看目前后端应用的计算实例数量：0 \nStep 2: 查看 0-1 冷启能力 使用 Chrome 浏览器访问前端服务，域名为：*.kevinwang.cc 查看后端服务的计算实例数量的变化 \n讲师演示2 \n创建版本和流量控制 克隆前端应用，并创建新版本 上传代码包 prod-stockmng-v2.zip 配置权重，路由 1:1 访问 V1 和 V2 版本 通过浏览器查看效果 \nStep 3: 查看版本和流量控制 打开前端应用服务 查看当前应用服务的 V1 和 V2 版本，和路由 通过浏览器访问应用查看流控效果 \nStep 4: 时间触发器 创建时间触发器，定时 2 分钟后触发一次 为前端应用配置触发器 在指定时间，通过执行记录查看触发效果 [](https://github.com/sofastack-guides/kc-serverless-demo#step-2-%E6%9F%A5%E7%9C%8B-0-1-%E5%86%B7%E5%90%AF%E8%83%BD%E5%8A%9B) \nStep 5: Log Shell 和计量 打开 Log Shell 选择相应的应用服务，并输入日志地址/关键词 搜索查看应用服务日志，可全屏 打开计量信息 通过计量监控查看实例运行情况 \n讲师演示3 \nM-N 快速伸缩 打开应用服务 查看当前版本的计算实例限额 1-5 / 计算实例数量：目前为 1 开始压测模拟高并发，并同步查看计算示例数变化 快速从 1 变化为 4，演示结束 Step 6:【可选步骤】快速开始+测试执行 按照前文步骤，尝试自己创建一个新的前端应用 测试执行应用服务 快速发布前端 Node JS应用 选择创建应用服务 创建应用，选择技术栈为 Node JS 上传代码包 prod-stockmng-v1.zip 运行时选择 nodejs-0.0.1.1-pre 入口方法可自动识别 端口： 3000 环境变量设置 BALANCEMNG_URL 为后端服务的地址 测试执行应用服务 选择测试执行 触发查看效果 更多 下载本次 Demo 幻灯片 ","date":-62135596800,"description":"使用该指南您可以体验到快速创建 Serveless 应用、根据业务请求秒级 0-1-N 自动伸缩、通过日志查看器快速排错、按时间触发应用等产品新功能。","dir":"guides/kc-serverless-demo/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f355d1b598fed47b730bd74ad25f3683","permalink":"https://sofastack.github.io/sofastack.tech/guides/kc-serverless-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/guides/kc-serverless-demo/","summary":"基于 Serverless 轻松构建云上应用 注意：使用该指南需要开通蚂蚁金融科技账号，请访问 蚂蚁金服科技官网。 作为云原生技术前进方向之一，Serverless 架构","tags":null,"title":"基于 Serverless 轻松构建云上应用","type":"guides","url":"/sofastack.tech/guides/kc-serverless-demo/","wordcount":1070},{"author":null,"categories":null,"content":" Ark 包 SOFAArk 定义特殊格式的可执行 Jar 包，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark 包；使用命令 java -jar 即可在 SOFAArk 容器之上启动应用；Ark 包 通常包含 Ark Container 、Ark Plugin 依赖（如果有）、合并部署的 Ark Biz （如果有）以及应用自身的 Ark Biz；详情可参考 Ark 包；\nArk Container Ark 容器，Ark Plugin 和 Ark Biz 运行在 SOFAArk 容器之上；容器具备管理多插件、多应用的功能；容器启动成功后，会解析 Ark Plugin 和 Ark Biz 配置，完成隔离加载并按优先级依次启动之；Ark Container 一般不会被用户直接感知，由打包插件 sofa-ark-maven-plugin 自动打入。详情可参考 SOFAArk 容器启动；\nArk Plugin Ark 插件，SOFAArk 定义特殊格式的 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-plugin-maven-plugin 可以将一个或多个普通的 Java Jar 包打包成一个标准格式的 Ark Plugin； Ark Plugin 会包含一份配置文件，通常包括插件类和资源的导入导出配置、插件启动优先级等；运行时，Ark 容器会使用独立的 PluginClassLoader 加载插件，并根据插件配置构建类加载索引表，从而使插件与插件、插件与应用之间相互隔离；详情可参考 Ark Plugin；\nArk Biz Ark 模块，SOFAArk 定义特殊格式的 Fat Jar ，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark Biz 包；作用有二点，一、在 Ark 包 中，作为工程应用模块及其依赖包的组织单元；二、可以被其他应用当成普通 Jar 包依赖，用于在同一个 SOFAArk 容器启动多个 Ark Biz；多个 Ark Biz 共享 Ark Container 和 Ark Plugin ；详情可参考 Ark Biz；\n合并部署 SOFAArk 允许将多个应用（Biz 包）合并打入到 Ark 包中，当启动 Ark 包时，会启动所有应用；也支持在运行时通过 API 或者配置中心（例如 Zookeeper）动态的部署和卸载应用，这些应用同时运行在同一个 JVM 中，由独立的 BizClassLoader 加载，各应用之间通过 SofaService/SofaReference 实现交互，称之为多应用的合并部署。\n宿主应用 宿主应用是相对合并部署而言，在打包 Ark 包时，至少有一个 Biz 包被打入，如果应用引入了其他 Biz 包，则 Ark 包中会存在多个 Biz 包。当只有一个 Biz 包时，默认将其设置为宿主应用；如果存在多个 Biz 包，则需要配置指定宿主应用。宿主应用相对其他 Biz 包最大的不同，即不允许被卸载。\n简单总结下，在 SOFAArk 框架中，应用(配置、源码、依赖)被打包成 Biz 包组织在一起，但是特殊的依赖（Ark Plugin 和其他应用 Biz 包）不会被打入 Biz 包中，Biz 包是不可执行的 Fat Jar; Ark Plugin 是特殊的二方包，可以将多个二方依赖打包成 Plugin，运行时由独立的 PluginClassLoader 加载，根据打包时配置的导出导入资源、类，构建运行时类加载模型；Ark 包是可执行 Fat Jar，一般由 Ark Container、Ark Plugin(0个或多个)、Ark Biz(至少一个)。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-terminology/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b6d0ed10afe9d04bc00307017ffba7c5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","summary":"Ark 包 SOFAArk 定义特殊格式的可执行 Jar 包，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark 包；使用命令 java -jar 即可在 SOFAArk 容器之上启动应用；Ark 包","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/","wordcount":1015},{"author":null,"categories":null,"content":" 业界通用术语 术语 说明 服务（Service） 通过网络提供的、具有特定业务逻辑处理能力的软件功能。 服务提供者（Service Provider） 通过网络提供服务的计算机节点。 服务消费者（Service Consumer） 通过网络调用服务的计算机节点。一个计算机节点可以既作为一些服务的提供者，又作为一些服务的消费者。 服务发现（Service Discovery） 服务消费者获取服务提供者的网络地址的过程。 服务注册中心（Service Registry） 一种提供服务发现功能的软件系统，帮助服务消费者获取服务提供者的网络地址。 数据中心（Data Center） 物理位置、供电、网络具备一定独立性的物理区域，通常作为高可用设计的重要考量粒度。一般可认为：同一数据中心内，网络质量较高、网络传输延时较低、同时遇到灾难的概率较大；不同数据中心间，网络质量较低、网络延时较高、同时遇到灾难的概率较小。 SOFARegistry 约定术语 术语 说明 SOFARegistry 蚂蚁金服开源的一款服务注册中心产品，基于“发布-订阅”模式实现服务发现功能。同时它并不假定总是用于服务发现，也可用于其他更一般的“发布-订阅”场景。 数据（Data） 在服务发现场景下，特指服务提供者的网络地址及其它附加信息。其他场景下，也可以表示任意发布到 SOFARegistry 的信息。 单元（Zone） 单元化架构关键概念，在服务发现场景下，单元是一组发布与订阅的集合，发布及订阅服务时需指定单元名，更多内容可参考异地多活单元化架构解决方案。 发布者（Publisher） 发布数据到 SOFARegistry 的节点。在服务发现场景下，服务提供者就是“服务提供者的网络地址及其它附加信息”的发布者。 订阅者（Subscriber） 从 SOFARegistry 订阅数据的节点。在服务发现场景下，服务消费者就是“服务提供者的网络地址及其它附加信息”的订阅者。 数据标识（DataId） 用来标识数据的字符串。在服务发现场景下，通常由服务接口名、协议、版本号等信息组成，作为服务的标识。 分组标识（GroupId） 用于为数据归类的字符串，可以作为数据标识的命名空间，即只有 DataId、GroupId、InstanceId 都相同的服务，才属于同一服务。 实例 ID（InstanceId） 实例 ID，可以作为数据标识的命名空间，即只有DataId、GroupId、InstanceId都相同的服务，才属于同一服务。 会话服务器（SessionServer） SOFARegistry 内部负责跟客户端建立 TCP 长连接、进行数据交互的一种服务器角色。 数据服务器（DataServer） SOFARegistry 内部负责数据存储的一种服务器角色。 元信息服务器（MetaServer） SOFARegistry 内部基于 Raft 协议，负责集群内一致性协调的一种服务器角色。 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/terminology/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b678a49547c55f2a70e2d94dbce5b4a2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/terminology/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-registry/terminology/","summary":"业界通用术语 术语 说明 服务（Service） 通过网络提供的、具有特定业务逻辑处理能力的软件功能。 服务提供者（Service Provider） 通","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-registry/terminology/","wordcount":1089},{"author":null,"categories":null,"content":" 名词 说明 TraceId TraceId 指的是 SOFATracer 中代表唯一一次请求的 ID，此 ID 一般由集群中第一个处理请求的系统产生，并在分布式调用下通过网络传递到下一个被请求系统。 SpanId SpanId 代表了本次请求在整个调用链路中的位置或者说层次，比如 A 系统在处理一个请求的过程中依次调用了 B，C，D 三个系统，那么这三次调用的的 SpanId 分别是：0.1，0.2，0.3。如果 B 系统继续调用了 E，F 两个系统，那么这两次调用的 SpanId 分别是：0.1.1，0.1.2。 其他相关的名词解释可以参考 OpenTracing 规范。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/explanation/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"8ba307b0679e918f7ac68c7efb7e53f7","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/explanation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/explanation/","summary":"名词 说明 TraceId TraceId 指的是 SOFATracer 中代表唯一一次请求的 ID，此 ID 一般由集群中第一个处理请求的系统产生，并在分布式调用下通过网络传递到下一个被请求系统。 SpanId SpanId","tags":null,"title":"基础术语","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/explanation/","wordcount":211},{"author":null,"categories":null,"content":" 消息 内部全部使用 SofaRequest 和 SofaResponse 进行传递。\n如果需要转换为其它协议，那么在真正调用和收到请求的时候，转换为实际要传输的对象。\n可以对 SofaRequest 和 SofaResponse 进行写操作的模块： - Invoker - Filter - ServerHandler - Serialization\n对消息体是只读的模块： - Cluster - Router - LoadBalance\n日志 日志的初始化也是基于扩展机制。虽然是扩展，但是由于日志的加载应该是最早的，所以在 rpc-config.json 里有一个单独的 Key。\n{ // 日志实现，日志早于配置加载，所以不能适应Extension机制 \u0026amp;quot;logger.impl\u0026amp;quot;: \u0026amp;quot;com.alipay.sofa.rpc.log.MiddlewareLoggerImpl\u0026amp;quot; } 配置项 使用者的 RPC 配置 用户的配置，例如端口配置（虽然已经开放对象中设置端口的字段，但是sofa默认是从配置文件里取的），线程池大小配置等。 - 通过 SofaConfigs 加载配置，调用 ExternalConfigLoader 读取外部属性。 - 通过 SofaConfigs 提供的 API 进行获取。 - 所有内部配置的Key都在 SofaOptions 类 - 优先级： System.property \u0026amp;gt; sofa-config.properties(每个应用一个) \u0026amp;gt; rpc-config.properties\nRPC 框架配置 框架自身的配置，例如默认序列化，默认超时等。 未来要一个ClassLoader一个。 - 通过 RpcConfigs 加载配置文件。 - 通过 RpcConfigs 其提供的API进行获取和监听数据变化 - 所有内部配置的Key都在 RpcOptions 类 - 优先级： System.property \u0026amp;gt; custom rpc-config.json（可能存在多个自定义，会排序） \u0026amp;gt; rpc-config-default.json\n常量 全局的基本常量在 RpcConstants 中。例如： 调用方式 sync oneway 协议 bolt/grpc、 序列化 hessian/java/protobuf\n 上下文的key 等等。 如果扩展实现自身的常量，请自行维护。 例如 BOLT 协议的常量。 SERIALIZE_CODE_HESSIAN = 1 PROTOCOL_TR = 13 例如 DSR 配置中心相关的常量。 _WEIGHT、_CONNECTTIMEOUT 这种 配置中心特有的key 地址 地址信息放到 ProviderInfo 类中 ProviderInfo 的值主要分为三部分 字段，一般是一些必须项目。 例如IP，端口，状态等； 静态字段：例如应用名； 动态字段：例如预热权重等； 字段枚举维护在 ProviderInfoAttrs 类中。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/common-model/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b2cc3f7ed134408d6adc25e418e1978b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/common-model/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/common-model/","summary":"消息 内部全部使用 SofaRequest 和 SofaResponse 进行传递。 如果需要转换为其它协议，那么在真正调用和收到请求的时候，转换为实际要传输的对象。 可以对 SofaRequest 和 SofaResponse 进行写操作的模块","tags":null,"title":"基础模型","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/common-model/","wordcount":684},{"author":null,"categories":null,"content":" 准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 - git 工具用法可以查看 git 官方书籍,需要阅读前几章来熟悉。 - git 协作流程可以查看这篇文章 git 协作流程。\nGitHub 贡献代码流程 提交issue 不论您是修复 SOFAJRaft 的 bug 还是新增 SOFAJRaft 的功能，在您提交代码之前，在 SOFAJRaft 的 GitHub 上提交一个 issue，描述您要修复的问题或者要增加的功能。这么做有几个好处: - 不会与其它开发者或是他们对这个项目的计划发生冲突，产生重复工作。 - SOFAJRaft 的维护人员会对您提的 bug 或者新增功能进行相关讨论，确定该修改是不是必要，有没有提升的空间或更好的办法。 - 在达成一致后再开发，并提交代码，减少双方沟通成本，也减少 pull request 被拒绝的情况。\n获取源码 要修改或新增功能，在提 issue 后，点击左上角的 fork 按钮，复制一份 SOFAJRaft 主干代码到您的代码仓库。\n拉分支 在这之前，可以先看看 SOFAJRaft 的 分支管理策略\nSOFAJRaft 所有修改都在分支上进行，修改完后提交 pull request，在 Code Review 后由项目维护人员 Merge 到主干。 因此，在获取源码步骤介绍后，您需要： - 下载代码到本地，这一步您可以选择git/https方式。\ngit clone https://github.com/您的账号名/sofa-jraft 拉分支准备修改代码: git branch add_xxx_feature 执行完上述命令后，您的代码仓库就切换到相应分支了。执行如下命令可以看到您当前分支： git branch -a 如果您想切换回主干，执行下面命令： git checkout -b master 如果您想切换回分支，执行下面命令： git checkout -b \u0026amp;quot;branchName\u0026amp;quot; 修改代码提交到本地 拉完分支后，就可以修改代码了。\n修改代码注意事项 代码风格保持一致 SOFAJRaft 通过 Maven 插件来保持代码格式一致。在提交代码前，务必本地执行 mvn clean compile 补充单元测试代码 新有修改应该通过已有的单元测试 应该提供新的单元测试来证明以前的代码存在 bug，而新的代码已经解决了这些 bug 您可以用如下命令运行所有测试： mvn clean test 也可以通过IDE来辅助运行。\n其它注意事项 请保持您编辑的代码的原有风格，尤其是空格换行等。 对于无用的注释，请直接删除。 对逻辑和功能不容易被理解的地方添加注释。 及时更新文档。 修改完代码后，请按照如下格式执行命令提交所有的修改到本地:\ngit commit -am \u0026#39;(feat) 添加xx功能\u0026#39; git commit -am \u0026#39;(fix) 修复xx功能\u0026#39; 提交代码到远程仓库 在代码提交到本地后，接下来就可以与远程仓库同步代码了。执行如下命令提交本地修改到 github 上：\ngit push origin \u0026amp;quot;branchname\u0026amp;quot; 如果前面您是通过 fork 来做的，那么这里的 origin 是 push 到您的代码仓库，而不是 SOFAJRaft 的代码仓库。\n提交合并代码到主干的请求 在的代码提交到 GitHub 后，您就可以发送请求来把您改好的代码合入 SOFAJRaft 主干代码了。此时您需要进入您在 GitHub 上的对应仓库，按右上角的 pull request 按钮。选择目标分支，一般就是 master，系统会通知 SOFAJRaft 的人员， SOFAJRaft 人员会 Review 您的代码，符合要求后就会合入主干，成为 SOFAJRaft 的一部分。\n代码 Review 在您提交代码后，您的代码会被指派给维护人员 Review，请耐心等待。如果在数天后，仍然没有人对您的提交给予任何回复，可以在 PR 下面留言，并 @ 对应的人员。\n对于代码 Review 的意见会直接备注到到对应 PR 或者 Issue。如果觉得建议是合理的，也请您把这些建议更新到您的补丁中。\n合并代码到主干 在代码 Review 通过后，就由 SOFAJRaft 维护人员操作合入主干了。这一步不用参与，代码合并之后，您会收到合并成功的提示。\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"99034715298f73cd835672b872141609","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","summary":"准备工作 贡献代码前需要先了解 git 工具的使用和 GitHub 网站的使用。 - git 工具用法可以查看 git 官方书籍,需要阅读前几章来熟悉。 - git 协作流程可以查看这篇文章 git","tags":null,"title":"如何参与 SOFAJRaft 代码贡献","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/","wordcount":1276},{"author":null,"categories":null,"content":" 简介 该样例工程演示了如何借助 maven 插件将一个普通的 Java 工程打包成标准格式规范的 Ark Plugin\n背景 现实开发中，常常会遇到依赖包冲突的情况；假设我们开发了一个类库 sample-lib , 业务应用在引入使用时，可能存在跟已有的依赖发生冲突的情况；通常这个时候，我们会希望自己的类库能够和业务其他依赖进行隔离，互不协商双方依赖包版本。 Ark Plugin 正是基于这种需求背景下的实践产物； Ark Plugin 运行在 Ark Container 之上，由容器负责加载启动，任何一个 Ark Plugin 由独立的 ClassLoader 加载，从而做到相互隔离。Ark Plugin 存在四个概念：\n 导入类：插件启动时，优先委托给导出该类的插件负责加载，如果加载不到，才会尝试从本插件内部加载；\n 导出类：其他插件如果导入了该类，优先从本插件加载；\n 导入资源：插件在查找资源时，优先委托给导出该资源的插件负责加载，如果加载不到，才会尝试从本插件内部加载；\n 导出资源：其他插件如果导入了该资源，优先从本插件加载；\n 详细请参考插件规范\n 工具 官方提供了 Maven 插件 - sofa-ark-plugin-maven-plugin ，只需要简单的配置项，即可将普通的 Java 工程打包成标准格式规范的 Ark Plugin ，插件坐标为:\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 详细请参考插件配置文档\n 入门 基于该用例工程，我们一步步描述如何构建一个 Ark Plugin\n创建标准 Maven 工程 该用例工程是一个标准的 Maven 工程，一共包含两个模块： * common 模块：包含了插件导出类\n plugin 模块：包含了 com.alipay.sofa.ark.spi.service.PluginActivator 接口实现类和一个插件服务类，插件打包工具 sofa-ark-plugin-maven-plugin 即配置在该模块的 pom.xml 中； 配置打包插件 在 plugin 模块的 pom.xml 中按如下配置打包插件：\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-plugin-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${project.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;ark-plugin\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--can only configure no more than one activator--\u0026amp;gt; \u0026amp;lt;activator\u0026amp;gt;com.alipay.sofa.ark.sample.activator.SamplePluginActivator\u0026amp;lt;/activator\u0026amp;gt; \u0026amp;lt;!-- configure exported class --\u0026amp;gt; \u0026amp;lt;exported\u0026amp;gt; \u0026amp;lt;!-- configure package-level exported class--\u0026amp;gt; \u0026amp;lt;packages\u0026amp;gt; \u0026amp;lt;package\u0026amp;gt;com.alipay.sofa.ark.sample.common\u0026amp;lt;/package\u0026amp;gt; \u0026amp;lt;/packages\u0026amp;gt; \u0026amp;lt;!-- configure class-level exported class --\u0026amp;gt; \u0026amp;lt;classes\u0026amp;gt; \u0026amp;lt;class\u0026amp;gt;com.alipay.sofa.ark.sample.facade.SamplePluginService\u0026amp;lt;/class\u0026amp;gt; \u0026amp;lt;/classes\u0026amp;gt; \u0026amp;lt;/exported\u0026amp;gt; \u0026amp;lt;!--specify destination where ark-plugin will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;../target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 在用例工程中，我们只配置了一部分配置项，这已经足够生成一个可用的 Ark Plugin，各配置项含义如下： * activator: Ark 容器启动插件的入口类，最多只能配置一个；通常来说，在插件的 activator 会执行一些初始化操作，比如发布插件服务；在本样例工程中，即发布了插件服务。\n 导出包：包级别的导出类配置，插件中所有以导出包名为前缀的类，包括插件的三方依赖包，都会被导出；\n 导出类：精确类名的导出类配置，导出具体的类；\n outputDirectory： mvn package 打包后，输出的 ark plugin 文件存放目录；\n 需要指出的是，在用例工程中，我们只导出了工程创建的类；实际在使用时，也可以把工程依赖的三方包也导出去。\n打包、安装、发布、引入 和普通的工程操作类似，使用 mvn package , mvn install , mvn deploy 即可完成插件包的安装和发布；需要注意的是，默认发布的 Ark Plugin 其 Maven 坐标会增加 classifier=ark-plugin ；例如在该样例工程中，如果需要使用该 ark plugin，必须如下配置依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-plugin-demo/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d8125843ced13352dd228299f222c74d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","summary":"简介 该样例工程演示了如何借助 maven 插件将一个普通的 Java 工程打包成标准格式规范的 Ark Plugin 背景 现实开发中，常常会遇到依赖包冲突的情况；假设我们开发了一个类","tags":null,"title":"如何打包 Ark Plugin","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/","wordcount":1171},{"author":null,"categories":null,"content":" 简介 该样例工程演示了如何借助 Maven 插件将一个 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包；\n准备 因该样例工程依赖 sample-ark-plugin，因此需要提前在本地安装该 Ark Plugin\n工具 官方提供了 Maven 插件 - sofa-ark-maven-plugin ，只需要简单的配置项，即可将 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包，插件坐标为：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; 详细请参考插件使用文档\n 入门 基于该样例工程，我们一步步描述如何将一个 Spring Boot Web 工程打包成可运行 Ark 包\n创建 SpringBoot Web 工程 在官网 https://start.spring.io/ 下载一个标准的 Spring Boot Web 工程\n引入 sample-ark-plugin 在工程主 pom.xml 中如下配置，添加另一个样例工程打包生成的 Ark Plugin 依赖，参考文档\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sample-ark-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;classifier\u0026amp;gt;ark-plugin\u0026amp;lt;/classifier\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置打包插件 在工程主 pom.xml 中如下配置 Maven 插件 sofa-ark-maven-plugin :\n\u0026amp;lt;build\u0026amp;gt; \u0026amp;lt;plugins\u0026amp;gt; \u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default-cli\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;!--goal executed to generate executable-ark-jar --\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;configuration\u0026amp;gt; \u0026amp;lt;!--specify destination where executable-ark-jar will be saved, default saved to ${project.build.directory}--\u0026amp;gt; \u0026amp;lt;outputDirectory\u0026amp;gt;./target\u0026amp;lt;/outputDirectory\u0026amp;gt; \u0026amp;lt;!--default none--\u0026amp;gt; \u0026amp;lt;arkClassifier\u0026amp;gt;executable-ark\u0026amp;lt;/arkClassifier\u0026amp;gt; \u0026amp;lt;!-- 让模块只能使用基座里模块声明过的依赖，详细查看 https://www.sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/ --\u0026amp;gt; \u0026amp;lt;declaredMode\u0026amp;gt;true\u0026amp;lt;/declaredMode\u0026amp;gt; \u0026amp;lt;/configuration\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \u0026amp;lt;/plugins\u0026amp;gt; \u0026amp;lt;/build\u0026amp;gt; 在该样例工程中，我们只配置了一部分配置项，这已经足够生成一个可用的可执行 Ark 包，各配置项含义如下： * outputDirectory: mvn package 打包后，输出的 Ark 包文件存放目录；\n arkClassifier: 指定发布的 Ark 包其 Maven 坐标包含的 classifier 值，默认为空； 关于 arkClassifier 配置项需要特别注意下，默认值为空；如果不指定 classifier ，上传到仓库的 Jar 包其实是一个可运行的 Ark 包；如果需要和普通的打包加以区分，需要配置该项值。\n打包、安装、发布 和普通的工程操作类似，使用 mvn package , mvn install , mvn deploy 即可完成插件包的安装和发布；\n运行 我们提供了两种方式在 Ark 容器上启动工程应用，通过命令行启动或者在 IDE 启动；在 IDE 启动时，需要额外添加依赖；使用命令行启动非常简便，直接使用 java -jar 即可启动应用；下面我们说下如何在 IDE 启动 Ark 应用；\n Spring Boot 工程：Spring Boot 工程需要添加如下依赖即可： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-springboot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 普通 Java 工程： 相较于 SpringBoot 工程，普通的 Java 工程需要添加另一个依赖： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-support-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.ark.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 除此之外，还需要在工程 main 方法最开始处，执行容器启动，如下：\npublic class Application{ public static void main(String[] args) { SofaArkBootstrap.launch(args); ... } } 运行测试用例 SOFAArk 提供了 org.junit.runner.Runner 的两个实现 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-ark-demo/","fuzzywordcount":1300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2c97c409788f41051c79836d277997be","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","summary":"简介 该样例工程演示了如何借助 Maven 插件将一个 Spring Boot Web 工程打包成标准格式规范的可执行 Ark 包； 准备 因该样例工程依赖 sample-ark-plugin，因","tags":null,"title":"如何打包 Ark 包","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/","wordcount":1293},{"author":null,"categories":null,"content":" 如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。\n 直接下载代码，然后执行如下命令：\ncd sofa-rpc mvn clean install 注意：不能在子目录（即子模块）下进行编译。因为 SOFARPC 模块太多，如果每个子模块都会install 和 deploy，仓库内会有较多无用记录。 所以在设计 SOFARPC 工程结构的时候，我们决定各个子模块组件是不需要 install 和 deploy 到仓库里的，我们只会install 和 deploy 一个sofa-rpc-all(all) 模块。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/how-to-build/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"52ad3debb35be8743c97bb4b6b77f22b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/how-to-build/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/how-to-build/","summary":"如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后执行如下命令： cd sofa-rpc mvn clean install 注意：不能在子目录（即子模块）下进行编译。因为 SOFARPC 模块太多","tags":null,"title":"如何编译 SOFARPC 工程","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/how-to-build/","wordcount":180},{"author":null,"categories":null,"content":" 在非 Kubernetes 环境下使用 Istio 需要达成以下的关键任务：\n 为 Istio 控制平面配置 Istio API server，也可以通过 memostore 的方式启动 Pilot 用作演示用途。 给所有微服务实例手工添加 SOFA MOSN，并以 Sidecar 模式启动。 确保请求都通过 SOFA MOSN 进行路由。 设定控制平面 Istio 控制平面由四个主要的服务组成：Pilot、Mixter、Citadel 以及 API server。\nAPI server Istio\u0026amp;rsquo;s API server (基于 kubernetes API server) 提供了配置管理和基于角色的访问控制。API server 需要 etcd 集群作为底层的持久化存储。\n本地安装 使用如下的 docker compose file 安装一个用于 POC 目的的 API server：\nversion: \u0026#39;2\u0026#39; services: etcd: image: quay.io/coreos/etcd:latest networks: default: aliases: - etcd ports: - \u0026amp;quot;4001:4001\u0026amp;quot; - \u0026amp;quot;2380:2380\u0026amp;quot; - \u0026amp;quot;2379:2379\u0026amp;quot; environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;/usr/local/bin/etcd\u0026amp;quot;, \u0026amp;quot;-advertise-client-urls=http://0.0.0.0:2379\u0026amp;quot;, \u0026amp;quot;-listen-client-urls=http://0.0.0.0:2379\u0026amp;quot; ] istio-apiserver: image: gcr.io/google_containers/kube-apiserver-amd64:v1.7.3 networks: default: aliases: - apiserver ports: - \u0026amp;quot;8080:8080\u0026amp;quot; privileged: true environment: - SERVICE_IGNORE=1 command: [ \u0026amp;quot;kube-apiserver\u0026amp;quot;, \u0026amp;quot;--etcd-servers\u0026amp;quot;, \u0026amp;quot;http://etcd:2379\u0026amp;quot;, \u0026amp;quot;--service-cluster-ip-range\u0026amp;quot;, \u0026amp;quot;10.99.0.0/16\u0026amp;quot;, \u0026amp;quot;--insecure-port\u0026amp;quot;, \u0026amp;quot;8080\u0026amp;quot;, \u0026amp;quot;-v\u0026amp;quot;, \u0026amp;quot;2\u0026amp;quot;, \u0026amp;quot;--insecure-bind-address\u0026amp;quot;, \u0026amp;quot;0.0.0.0\u0026amp;quot; ] 其他控制平面组件 目前 SOFA MOSN 还没有集成 Pilot 之外的其他组件，因此我们暂时无需安装 Mixer、Citadel 等组件。\n为微服务实例添加 SOFA MOSN Sidecar 微服务应用的每个实例都必须有个伴生的 SOFA MOSN 实例。\n","date":-62135596800,"description":"","dir":"projects/sofa-mesh/pilot-setup-zookeeper-installation/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"4c0bd56673dc8aebef9011a22496392d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","summary":"在非 Kubernetes 环境下使用 Istio 需要达成以下的关键任务： 为 Istio 控制平面配置 Istio API server，也可以通过 memostore 的方式启动 Pilot 用作演示用途。 给所有微服务实例手工添加 SOFA","tags":null,"title":"安装指南","type":"projects","url":"/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/","wordcount":372},{"author":null,"categories":null,"content":"提供可以允许配置的所有参数。 * 发布订阅配置 * 预热转发配置 * 自动故障剔除配置\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b1a8a8c426beab292165716f1dff1ae4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration/","summary":"提供可以允许配置的所有参数。 * 发布订阅配置 * 预热转发配置 * 自动故障剔除配置","tags":null,"title":"完整配置参数","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration/","wordcount":37},{"author":null,"categories":null,"content":" 客户端 API 使用说明 SOFALookout 客户端设计上保持了 API 与实现解耦。如果我们只需要基于 SOFALookout API 进行埋点，那么只需要依赖 API 包即可。在没有依赖具体实现模块依赖时（比如 client 依赖 或 SOFABoot（Spring Boot）Start 依赖），API 包会自动使用 NoopRegistry，使得所有埋点的地方都已空实现替代。\n1.API 依赖引入 \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.关于 ID Lookout metrics 相比传统的 metrics 库单一维度的信息描述，提供了支持多维度描述的 tags 能力。 Lookout metrics 的唯一标识 Id 类，由 name 和 tags 构成。\nId basicId = registry.createId(\u0026amp;quot;rpc.provider.service.stats\u0026amp;quot;); id = basicId.withTag(\u0026amp;quot;service\u0026amp;quot;, \u0026amp;quot;com.alipay.demo.demoService\u0026amp;quot;) .withTag(\u0026amp;quot;method\u0026amp;quot;, \u0026amp;quot;sayHi\u0026amp;quot;) .withTag(\u0026amp;quot;protocol\u0026amp;quot;, \u0026amp;quot;tr\u0026amp;quot;) .withTag(\u0026amp;quot;alias\u0026amp;quot;, \u0026amp;quot;group1\u0026amp;quot;); 上面是 Id 的简单示例了，如何创建 Id，如何打 tag，（每打一次 tag，都会生成并返回一个新的 Id 对象引用）切记！使用返回新的 Id 对象了哦。\n 不要主动缓存 Id 或具体的 Metric 对象,Lookout 的 Registry 已经登记记录了。相等的 Id （ name 和 tags 一样）会复用已有的Id 对应 Metric 对象。 2.1 Priority tag (不是必须) PRIORITY 枚举级别: HIGH, NORMAL, LOW;\nid.withTag(LookoutConstants.LOW_PRIORITY_TAG); 如果不打该 Tag (建议)，默认是 NORMAL 级别。级别代表了采集间隔周期（HIGH：2s, NORMAL: 30s, LOW: 1min）\n2.2 关于 tags 通用的 tags，比如：本机 ip，机房等详细会统一附上，不需要单独指定。 普通 Java 项目直接 lookout-client 时，tags 需要自己指定，特别记住：appName 别忘啦！tag:app=xx key 必须小写，尽量是字母，数字，下划线； （尤其是运行期的 Counter, Timer, DistributeSummary 这些 metrics）某个类型的 tag 的 values 尽量是稳定不变有限集合，而且 tags 尽量少，防止 metrics 数量超过最大限制！ 比如：rpc 场合 service, method 两个 tag 对应的值是有限较小的； 反例是每次 rpc 调用都有是个独立的 tag-value。 因此，总体原则自定义打 tags 时要尽量少，对应 values 的集合数量尽量小； 专门用途的 TAG 名称: \u0026amp;ldquo;priority\u0026amp;rdquo;: 表示优先级。 系统保留的 tag key 统配格式_*_,以下划线开始，以下划线结束（比如: \u0026amp;ldquo;type\u0026amp;rdquo; ）。 请不要使用这种格式的 key，可能会被系统覆盖或丢弃 3.可接入的统计( Metric )类型API Counter 「计数器」 场景：方法调用次数； 主动汇报的数据包括： count, rate (也就是 qps)； 使用方式 Counter counter=registry.counter(id); counter.inc(); Timer 「耗时统计器」 场景:统计任务，方法耗时，支持分桶统计 主动汇报的数据包括：elapPerExec (单次执行耗时), total 耗时，Max 耗时,（上报单位：秒）； 使用方式 Timer timer=registry.timer(id); timer.record(2, TimeUnit.SECONDS); DistributionSummary 「值分布情况统计器」 场景：比如 io 流量，支持分桶统计 主动汇报的数据包括: count, total(size), max(size)； 使用方式: DistributionSummary distributionSummary=registry.distributionSummary(id); distributionSummary.record(1024); Gauge 「即时数据观察」 场景：比如线程池，内存值等即时值； 主动汇报的数据包括: value； 往注册表中登记新 gauge 时，ID 值相等，注册表继续使用已有的(忽略新的)； 注意，推荐 gauge 观察的对象尽量是单例的（复用），并且建议在运行时一直活着（而不是作为一个临时的统计）！，如果不是单例或者只存活一段时间，那么一定要从 Registry 中 remove 掉，否则影响 GC（主要是它持有的外部对象引用无法释放，浪费空间）!!\n 使用方式: registry.gauge(id,new Gauge\u0026amp;lt;Double\u0026amp;gt;() { @Override public Double value() { return 0.1; } }); MixinMetric 「上述基本统计 metrics 的混合管理体」 MixinMetric 是 Lookout 特有的，表示多个基本 metrics 的混合体。引入该 Mixin 目的是优化对「同一度量目标」（即测量目标一致，tags 一致）的多测量指标传输和存储效率，比如：同一线程池的各种指标(线程总数，活跃总数，等待队列大小\u0026amp;hellip;)。\n 使用方式（比如，对一次服务调用，加入多个测量指标：调用耗时，输入字节，调用次数，输出字节等等） //1. getOrAdd MixinMetric MixinMetric rpcServiceMetric=registry.minxinMetric(id); //2. getOrAdd basic component metric to use Timer rpcTimer = rpcServiceMetric.timer(\u0026amp;quot;perf\u0026amp;quot;); DistributionSummary …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-api/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"76574f2435a3565fe1fc50831ff9ab0c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-api/","summary":"客户端 API 使用说明 SOFALookout 客户端设计上保持了 API 与实现解耦。如果我们只需要基于 SOFALookout API 进行埋点，那么只需要依赖 API 包即可。在没有依赖具体实现模块依赖时（比如","tags":null,"title":"客户端 API 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-api/","wordcount":1562},{"author":null,"categories":null,"content":" Registry 的使用 不同的 Registry 的集成提供了不同的访问 Metrics 的方式。\n1. LookoutRegistry 提供按照一定时间窗口统计 metrics 的能力。它又分为“主动推”和“被动拉”两种模式，暂时被动拉取模式处于关闭状态。\n（1）主动推模式\n可以通过【客户端配置】指定远程 Agent 的IP地址，即开始上报检查，和定时上报数据。 （2）被动拉模式\n可以通过【客户端配置】启动该模式，则在 19399 端口提供 HTTP 服务。更多交互细节请参考（待补充） 2. 对接到 Prometheus SOFALookout 的数据可以对接到 Prometheus 上面。为了将数据对接到 Prometheus 上面，首先需要在工程中加入依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-reg-prometheus\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 添加好依赖之后，启动应用，既可以访问 http://localhost:9494 来看到数据，其中 9494 为默认的端口，可以通过在 application.properties 里面配置 com.alipay.sofa.lookout.prometheus-exporter-server-port 来改变端口。\n有了访问数据的 URL 之后，可以编辑一个 prometheus.yml 来抓取该项目信息，假设本机 IP 地址为 10.15.232.20，那么可以配置如下的 prometheus.yml：\nscrape_configs: - job_name: \u0026#39;lookout-client\u0026#39; scrape_interval: 5s static_configs: - targets: [\u0026#39;10.15.232.20:9494\u0026#39;] 有了上面的配置文件之后，可以再到本地通过 Docker 来启动 Prometheus：\ndocker run -d -p 9090:9090 -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml --name prom prom/prometheus:master 然后通过浏览器访问: http://localhost:9090，再通过 PromQL 查询即可查询到对应的 Metrics。\nSOFALookout 中也提供了一个对接 Prometheus 的样例，大家可以前往自行查看。\n3. 对接 SpringBoot actuator 除了 Prometheus 之外，SOFALookout 可以与 SpringBoot 1.x 的 Actuator 的相集成，只需依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后启动后访问 http://localhost:8080/metrics 既可以看到通过 SOFALookout API 埋点的数据。\nSOFALookout 也提供了集成的样例工程，大家可以前往自行查看。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-registry/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3c51ba6519cee542b459a170dabcf32b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-registry/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-registry/","summary":"Registry 的使用 不同的 Registry 的集成提供了不同的访问 Metrics 的方式。 1. LookoutRegistry 提供按照一定时间窗口统计 metrics 的能力。它又分为“主动推”和“被动拉”两种模式，暂时被动拉取模","tags":null,"title":"客户端 Registry 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-registry/","wordcount":575},{"author":null,"categories":null,"content":" 1. 创建 Maven 工程 服务端部署完毕后，我们可以新建一个 Maven 工程使用 SOFARegistry 提供的服务。首先新建一个 Maven 工程，然后引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;registry-client-all\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${registry.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2. 发布数据 // 构建客户端实例 RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // 构造发布者注册表 String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; PublisherRegistration registration = new PublisherRegistration(dataId); // 将注册表注册进客户端并发布数据 registryClient.register(registration, \u0026amp;quot;10.10.1.1:12200?xx=yy\u0026amp;quot;); 使用 SOFARegistry 发布数据一共包含三个步骤：\n 构建客户端实例; 构造发布者注册表; 将注册表注册进客户端并发布数据。 2.1 构建客户端实例 构建客户端实例的关键是创建 RegistryClientConfig 对象，创建 RegistryClientConfig 对象时需要指定 RegistryEndpoint 和 RegistryEndpointPort:\n RegistryEndpoint：注册中心任一 Session 节点地址； RegistryEndpointPort: Session 节点配置的 session.server.httpServerPort 端口值。 2.2 构造发布者注册表 构造发布注册表只需要创建 PublisherRegistration 并指定 dataId，dataId 是发布服务的唯一标识。\n2.3 发布数据 调用 RegistryClient 的 register 方法可以进行数据发布，该方法需要两个参数，第一个参数是发布注册表，指定了服务的 dataId，第二个参数是数据值，一般是一个字符串类型。\n3. 订阅数据 // 构建客户端实例 RegistryClientConfig config = DefaultRegistryClientConfigBuilder.start().setRegistryEndpoint(\u0026amp;quot;127.0.0.1\u0026amp;quot;).setRegistryEndpointPort(9603).build(); DefaultRegistryClient registryClient = new DefaultRegistryClient(config); registryClient.init(); // 创建 SubscriberDataObserver SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() { public void handleData(String dataId, UserData userData) { System.out.println(\u0026amp;quot;receive data success, dataId: \u0026amp;quot; + dataId + \u0026amp;quot;, data: \u0026amp;quot; + userData); } }; // 构造订阅者注册表，设置订阅维度，ScopeEnum 共有三种级别 zone, dataCenter, global String dataId = \u0026amp;quot;com.alipay.test.demo.service:1.0@DEFAULT\u0026amp;quot;; SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver); registration.setScopeEnum(ScopeEnum.global); // 将注册表注册进客户端并订阅数据，订阅到的数据会以回调的方式通知 SubscriberDataObserver registryClient.register(registration); 使用 SOFARegistry 订阅数据一共包含四个步骤：\n 构建客户端实例; 创建 SubscriberDataObserver； 构造订阅者注册表； 将注册表注册进客户端并订阅数据。 其中创建客户端实例方式与上文发布数据时创建客户端实例的方法一致。\n3.1 创建 SubscriberDataObserver SubscriberDataObserver 是一个回调接口，该接口定义了 handleData 方法，该方法包含两个参数，分别是 dataId 及最终数据，当客户端收到服务端订阅的数据时会调用该方法。在 SOFARegistry 中，服务端返回数据用 UserData 表示，该类包含以下两个方法：\npublic interface UserData { Map\u0026amp;lt;String, List\u0026amp;lt;String\u0026amp;gt;\u0026amp;gt; getZoneData(); String getLocalZone(); } getLocalZone: 返回当前zone； getZoneData: 返回以 zone 为 key，每个 zone 的数据为 value 的数据。 3.2 构造订阅者注册表 构造订阅者注册表需要创建 SubscriberRegistration 对象，创建该对象需要指定 dataId 及 SubscriberDataObserver。\n3.3 订阅数据 调用 RegistryClient 的 register 方法可以进行数据订阅，该方法包含一个参数，只需传入 SubscriberRegistration 对象即可。\n如果先运行发布数据的程序，然后再运行订阅数据的程序，那么我们将在控制端看到如下输出：\nreceive data success, dataId: …","date":-62135596800,"description":"","dir":"projects/sofa-registry/client-quick-start/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"66e300d44b2f2a903d976bf83eb7c16e","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/client-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/client-quick-start/","summary":"1. 创建 Maven 工程 服务端部署完毕后，我们可以新建一个 Maven 工程使用 SOFARegistry 提供的服务。首先新建一个 Maven 工程，然后引入如下依赖： \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;registry-client-all\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${registry.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; 2. 发布数据 // 构建客户端","tags":null,"title":"客户端使用","type":"projects","url":"/sofastack.tech/projects/sofa-registry/client-quick-start/","wordcount":897},{"author":null,"categories":null,"content":" 该项目演示了如何在 SOFABoot 中使用 SOFALookout 并且对接到 Spring Boot 的 Actuator 中。如果想要对接到 Prometheus 上或者其他的 Registry 中，请参考 Registry 一节。\n新建 SpringBoot（或 SofaBoot ）项目 新建一个 Spring Boot 的应用（如果是 SOFABoot 工程按照 SOFABoot 文档 - 依赖管理中的方式引入 SOFABoot 即可）。\n引入 Lookout 的 Starter 依赖 在 pom.xml 中引入以下依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 如果 Spring Boot 项目需指定版本。\n新建一个 Metrics 指标 在完成依赖的引入之后，然后可以在 Spring Boot 中的启动类中，加入如下的方法：\n@Autowired private Registry registry; @PostConstruct public void init() { Counter counter = registry.counter(registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;).withTag(\u0026amp;quot;instant\u0026amp;quot;, NetworkUtil.getLocalAddress().getHostName())); counter.inc(); } 上面的代码中直接通过 @Autowired 注入了一个 Registry 的字段，通过这个 Registry 的字段，我们就可以创建对应的 Counter，然后通过修改这个 Counter 的数据来生成 SOFALookout 的 Metrics 的指标。\n添加配置项 在 SOFABoot 项目中，需要增加一个应用名的配置项：spring.application.name=xxx。\n与 Spring Boot Actuator 对接 新增了一个指标之后，我们可以选择对接到 Spring Boot Actuator 上，要对接到 Spring Boot Actuator 上面，需要添加如下的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-actuator\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 添加如上的依赖之后，我们在本地启动应用，访问 http://localhost:8080/metrics，就可以看到前面添加的指标，如下：\n\u0026amp;quot;http_requests_total.instant-MacBook-Pro-4.local\u0026amp;quot;: 1, 以上的 QuickStart 的代码在: lookout-client-samples-boot，大家可以下载作为参考。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-boot/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"27e057f8a8a4ac97f42ea66ca6a17fdd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","summary":"该项目演示了如何在 SOFABoot 中使用 SOFALookout 并且对接到 Spring Boot 的 Actuator 中。如果想要对接到 Prometheus 上或者其他的 Registry 中，请参考 Registry 一节。 新建 SpringBoot（或 SofaBoot ）项目 新建一","tags":null,"title":"客户端快速开始 - SOFABoot 项目","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/","wordcount":490},{"author":null,"categories":null,"content":" 普通 Java 项目 在应用中加入 client 的 Maven 依赖\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.lookout\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;lookout-client\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${lookout.client.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; lookout-client 默认依赖了 lookout-reg-server 模块（支持向 lookout server 上报 metrics 数据），如果希望使用其他类型注册表(比如 lookout-reg-prometheus)，那么再加上对应依赖即可。\n开始使用 SOFALookout 的 Client 之前，首先需要构建一个全局的客户端实例（ com.alipay.lookout.client.DefaultLookoutClient ）\nLookoutConfig lookoutConfig = new LookoutConfig(); DefaultLookoutClient client = new DefaultLookoutClient(\u0026amp;quot;appName\u0026amp;quot;); //选择构建需要使用的 Registry(如果多个注册表类型，建议使用同一 lookoutConfig 实例，便于集中管理) LookoutRegistry lookoutRegistry = new LookoutRegistry(lookoutConfig); //客户端可以后置添加 registry 实例(至少要加一个) client.addRegistry(lookoutRegistry); //(可选)对已加入或后续加入的客户端的 registry 实例，统一注册扩展模块的 metrics client.registerExtendedMetrics(); 然后通过客户端拿取 Registry 实例，进行使用：\n//该注册表是个“组合”型的注册表 Registry registry = client.getRegistry(); //demo Id id = registry.createId(\u0026amp;quot;http_requests_total\u0026amp;quot;); Counter counter = registry.counter(id); counter.inc(); 客户端的使用，可以详细参考样例工程。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/quick-start-client-java/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5dc476aa21ece4789859f1af598d4445","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","summary":"普通 Java 项目 在应用中加入 client 的 Maven 依赖 \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;com.alipay.sofa.lookout\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;lookout-client\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;${lookout.client.version}\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; lookout-client 默认依赖了 lookout-reg-server 模块（支持向 lookout server 上报 metrics 数据），如果希望使用其他类型注册表(比如 lookout-reg","tags":null,"title":"客户端快速开始 - 普通 Java 项目","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/quick-start-client-java/","wordcount":311},{"author":null,"categories":null,"content":"客户端模块是一个较复杂的模块，这里包含了集群管理、路由、地址管理器、连接管理器、负载均衡器，还与代理、注册中心等模块交互。\n参见：\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/client-invoke-flow/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"310d99d64b808a3b526563e92c699952","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","summary":"客户端模块是一个较复杂的模块，这里包含了集群管理、路由、地址管理器、连接管理器、负载均衡器，还与代理、注册中心等模块交互。 参见：","tags":null,"title":"客户端调用流程","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/client-invoke-flow/","wordcount":64},{"author":null,"categories":null,"content":" 客户端配置项设置示例 lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026amp;quot;127.0.0.1\u0026amp;quot;); 客户端配置项说明 配置项 对应 SpringBoot 配置项 默认配置值 说明 lookout.enable com.alipay.sofa.lookout.enable true 功能开关，默认是 true。如果改为 false，那么所有 metrics 就几乎没有内存与计算消耗(空对象与空方法) lookout.max.metrics.num com.alipay.sofa.lookout.max-metrics-num 5000 metrics 最大数目限制，超过会自动忽略 lookout.prometheus.exporter.server.port com.alipay.sofa.lookout.prometheus-exporter-server-port 9494 prometheus 抓取的端口 lookout.exporter.enable com.alipay.sofa.lookout.exporter-enable false 是否开启支持被动采集的服务 lookout.agent.host.address com.alipay.sofa.lookout.agent-host-address - 主动上报 Agent 服务器的注解地址，支持多个地址以逗号分隔 客户端日志配置说明 系统属性配置项 对应 SpringBoot 配置项 默认配置值 说明 -Dlogging.level.com.alipay.lookout=? logging.level.com.alipay.lookout warn lookout 客户端的日志级别，debug 可以看见汇报数据的详情 -Dlogging.path=? logging.path 当前用户目录 SpringBoot V1的日志目录调整，包括 \u0026amp;ldquo;lookout/\u0026amp;rdquo; 日志子目录 客户端配置自定义(适用于 SpringBoot 技术栈模式) 使用配置定制扩展: MetricConfigCustomizerConfig\n@Configuration public class MetricConfigCustomizerConfig { @Bean public MetricConfigCustomizer metricConfigCustomizer() { return new MetricConfigCustomizer() { @Override public void customize(MetricConfig metricConfig) { metricConfig.addProperty(\u0026amp;quot;testaa\u0026amp;quot;, \u0026amp;quot;testbb\u0026amp;quot;); } }; } } ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/client-configuration/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5fd84950d4d565d3fb20781337792bf1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/client-configuration/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/client-configuration/","summary":"客户端配置项设置示例 lookoutConfig.setProperty(LookoutConfig.LOOKOUT_AGENT_HOST_ADDRESS,\u0026quot;127.0.0.1\u0026quot;); 客户端配置项说明 配置项 对应 SpringBoot 配置项 默认配置值 说明 lookout.enable com.alipay.sofa.lookout.enable true 功能开关，默认是 true。如果改为 false，那么所有 metrics 就几乎没","tags":null,"title":"客户端配置","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/client-configuration/","wordcount":298},{"author":null,"categories":null,"content":"包含单机故障剔除和 Hystrix 熔断。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e567dc5e291867e92c8dd1c4f953b768","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault/","summary":"包含单机故障剔除和 Hystrix 熔断。","tags":null,"title":"容灾恢复","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault/","wordcount":13},{"author":null,"categories":null,"content":" 本文档中提供了 MOSN 的示例工程。\n使用 MOSN 作为 HTTP 代理 请参考 MOSN 转发 HTTP 的示例工程 http-sample。\n使用 MOSN 作为 SOFARPC 代理 请参考 MOSN 转发 SOFARPC 的示例工程 sofarpc-sample。\n使用 MOSN 作为TCP 代理 请参考 MOSN 作为 TCP Proxy 的示例工程 tcpproxy-sample 。\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-run-samples/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"600c182fdee786a59e14899ba0fce8a1","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-run-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-run-samples/","summary":"本文档中提供了 MOSN 的示例工程。 使用 MOSN 作为 HTTP 代理 请参考 MOSN 转发 HTTP 的示例工程 http-sample。 使用 MOSN 作为 SOFARPC 代理 请参考 MOSN 转发 SOFARPC 的示例工程 sofa","tags":null,"title":"工程示例","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-run-samples/","wordcount":106},{"author":null,"categories":null,"content":" 源码工程中提供了一些样例工程，辅助说明项目的使用。样例工程的 readme 有使用补充说明，另外需要将这些 sample 工程单独的导入 IDE。\n客户端样例工程 lookout-client-samples-java 该样例工程展示了，在普通 Java 项目中,如何以代码形式使用和配置客户端。\n lookout-client-samples-boot 该样例工程展示了，在 SpringBoot(或SofaBoot) 项目中,如何使用和配置客户端。\n lookout-client-samples-prometheus 该样例工程展示了，在 SpringBoot(或SofaBoot) 项目中,如何使用和配置客户端使用 prometheus。\n lookout-samples-prom-push 该样例工程展示了，在 Java 项目中,使用 prometheus 客户端并以push方式（PushGateway）上报数据。\n服务器端样例工程 ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-samples/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a8a0fcd3f99ce2fb46e4d543e30797c9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-samples/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-samples/","summary":"源码工程中提供了一些样例工程，辅助说明项目的使用。样例工程的 readme 有使用补充说明，另外需要将这些 sample 工程单独的导入 IDE。 客户端样例工程 lookout-client-samples-java 该样例工","tags":null,"title":"工程示例","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-samples/","wordcount":261},{"author":null,"categories":null,"content":" Q：报错误 NoSuchMethodError 一般情况下该类错误由依赖冲突导致。已知的依赖冲突列举如下，遇到时选择性排除它们。\n日志冲突 commons-logging 冲突 \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;commons-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;commons-logging\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; logback-classic 冲突 在冲突位置将 logback-classic 排除，如 spring-boot-starter-logging 和 spring-test 为存在冲突的应用依赖。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;4.3.4.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;ch.qos.logback\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;logback-classic\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; snakeyaml 冲突 java.lang.NoSuchMethodError: org.yaml.snakeyaml.Yaml.\u0026amp;lt;init\u0026amp;gt;(Lorg/yaml/snakeyaml/constructor/BaseConstructor;)V spring-boot-starter-test 与 org.testng 中引用的 org.yaml 存在冲突。这里以排除 spring-boot-starter-test 中的 org.yaml 为例（也可在 org.testng 等冲突位置排除）\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-test\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;scope\u0026amp;gt;test\u0026amp;lt;/scope\u0026amp;gt; \u0026amp;lt;exclusions\u0026amp;gt; \u0026amp;lt;exclusion\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.yaml\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;snakeyaml\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/exclusion\u0026amp;gt; \u0026amp;lt;/exclusions\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Q：报错 NoClassDefFoundError 一般情况下依赖缺失或者依赖冲突会导致该类问题。\nMockito 报错找不到类 SOFABoot 使用 Mockito 时，如果已经存在 spring-boot-starter-test 则无需重复引入 Mockito。\nQ：报错 No bean dataAccessConfigManager available ACTS 测试脚本指定的 Application 启动类中缺少 acts-core.xml，如图添加即可。\nQ：No runnable methods 一般是由于选择 Junit 运行 ACTS 测试脚本导致的，ACTS 测试脚本可使用 TestNG 方式运行。\nQ：生成模版异常 有较多情况会导致这一现象，常见的是新编写的类或者对类进行变更后，没有进行 mvn 编译。先执行 mvn clean install -Dmaven.test.skip=true，再进行模版生成。\nQ：编辑器设置入参错误 使用 ACTS IDE 操作入参时，出现无法选中或者设置数值出错等情况，一般是生成测试脚本操作有误，没有生成入参模版而直接生成测试脚本，导致初始生成的 YAML 中入参不正确。\n 解法一：删除测试脚本对应的 YAML 文件，然后打开 ACTS IDE 并右键入参设置 -\u0026amp;gt; 模版选择，编辑后保存则 YAML 文件会自动重建。 解法二：删除生成的测试脚本和 YAML 文件，首先生成入参的模版，再重新生成测试脚本即可，YAML 中会默认带入参设置； Q：报错 argument type mismatch 该问题一般是被测接口有多个同名重载方法导致的，从而引发反射时参数不匹配错误。\n解决方法 可以在脚本中重写 ACTS 测试基类的 findMethod 方法，返回真正被测的方法对象。下面的方法也适用于获取被测方法失败的情况。\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { Method method =null; try { method = VirtualAssetQueryService.class.getDeclaredMethod (\u0026amp;quot;query\u0026amp;quot;, QueryVirtualAssetListParam.class); } catch (NoSuchMethodException e) { e.printStackTrace(); } catch (SecurityException e) { e.printStackTrace(); } actsRuntimeContext.setTestedMethod(method); } 使用 ACTS IDE 编辑类的属性后保存取值失效 ACTS IDE 默认类是标准的 JavaBean 形式，会调用属性的 set 方法为其赋值，如果不存在 set 方法则无法保存取值。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/faq/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5f89d1f5695cbe6b669a8738741529bd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/faq/","summary":"Q：报错误 NoSuchMethodError 一般情况下该类错误由依赖冲突导致。已知的依赖冲突列举如下，遇到时选择性排除它们。 日志冲突 commons-logging 冲突 \u0026lt;exclusion\u0026gt; \u0026lt;artifactId\u0026gt;commons-logging\u0026lt;/artifactId\u0026gt; \u0026lt;groupId\u0026gt;commons-logging\u0026lt;/groupId\u0026gt; \u0026lt;/exclusion\u0026gt; logback-classic 冲突 在冲突位置将 logback-classic 排除，","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-acts/faq/","wordcount":776},{"author":null,"categories":null,"content":" Q: Readiness Check 有啥应用场景？ Liveness Check 和 Readiness Check 概念来自于 Kuberentes，分别代表运行时检查和启动时检查。Spring Boot 提供了 Liveness Check，但是没有提供 Readiness Check。利用 Readiness Check 的能力，SOFA 中间件中的各个组件只有在 Readiness Check 通过之后，才将流量引入到应用的实例中，比如 RPC，只有在 Readiness Check 通过之后，才会向服务注册中心注册，后面来自上游应用的流量才会进入。除了中间件可以利用 Readiness Check 的事件来控制流量，PAAS 系统也可以通过访问 http://localhost:8080/health/readiness 来获取应用的 Readiness Check 的状况，从而控制例如负载均衡设备等等的流量。\nQ: 是否可以在 SOFABoot 模块中定义 Controller 组件？ SOFABoot 模块一般用于封装对外发布服务接口的具体实现，属于业务层，Controller 属于展现层内容，我们不建议也不支持在 SOFABoot 模块中定义 Controller 组件，Controller 组件相关定义建议直接放在 Root Application Context。\nQ: 类隔离在蚂蚁内部使用是否广泛？ 类隔离在蚂蚁内部使用非常广泛，绝大部分业务应用都是运行在蚂蚁中间件自研的类隔离框架之上。主要是为了解决依赖冲突的问题，像蚂蚁金服这种体量的公司，业务线繁杂、基础服务组件众多，很难做到对所有 JAR 包做统一管控。特别涉及到跨团队模块组件相互依赖时，因为各自技术栈历史包袱的存在，难以有效统一冲突包版本。使用类隔离技术解决了实际开发中的很多痛点，业务开发者不需要担心自身依赖冲突的问题，在多团队协作开发中，也有很大的优势。\nQ: SOFABoot类隔离框架（SOFAArk）和 OSGI 容器有哪些差异？ 作为开源界早负盛名的动态模块系统，基于 OSGi 规范的 Equinox、Felix 等同样具备类隔离能力，然而他们更多强调的是一种编程模型，面向模块化开发，有一整套模块生命周期的管理，定义模块通信机制以及复杂的类加载模型。作为专注于解决依赖冲突的隔离框架，SOFAArk 专注于类隔离，简化了类加载模型，因此显得更加轻量。其次在 OSGi 规范中，所有的模块定义成 Bundle 形式，作为应用开发者，他需要了解 OSGi 背后的工作原理，对开发者要求比较高。在 SOFAArk 中，定义了两层模块类型，Ark Plugin 和 Ark Biz，应用开发者只需要添加隔离的 Ark Plugin 依赖，底层的类加载模型对应用开发者俩说是透明的，基本不会带来额外的学习成本。\nQ: SOFAArk 和 Java9 模块化有哪些差异？ Jigsaw 作为 Java9 模块化方案，抛开内部实现细节，在使用规范上和 OSGi 特别相似：模块的依赖、包导入导出、动态导出、可读性传递、模块服务注册与消费、开放模块、可选模块等等若干概念，相对于 SOFAArk 简单的包导入导出显然过于复杂。在实现细节上，考虑到 JDK 代码的兼容性，Jigsaw 没有采用类加载器隔离的方式，不同模块之间仍然可能是同一个类加载器加载。严格上来讲，Jigsaw 并没有解决同一个类多版本的问题，但是因为模块显示的依赖声明，使用纯 Jigsaw 模块化编程，不同版本类冲突的问题在编译期就能被检查或者启动失败，因为不允许不同模块含有相同类名的包。对于在实际开发中遇到的一类情况，例如两个组件依赖不同版本 hessian 包，即使这两个组件定义成了两个模块，运行时也只有一个hessian版本被加载，依然解决不了不同版本类共存的问题。另外，Jigsaw 相对 Ark 或者 OSGi 有一个明显的缺点，Jigsaw 不允许运行时动态发布模块服务，模块间的通信依赖在 module-info.java 中使用 provides 和 uses 静态注册和引用模块服务。当然，Jigsaw 有很多自己的优点，通过引入module-path，在 module 中显示声明模块依赖关系，避免了传统 maven/gradle 中因为间接依赖导致运行时加载类不确定的缺点；其次通过设置模块包的导入导出配置，可以完全做到接口和实现的分离，提升安全性；另外 Java9 本身借助模块化改造，使用jlink工具，开发者可以将自身应用必须的模块聚合，打包一个自定义的jre镜像。\nQ: 为什么使用 SNAPSHOT 版本拉取不到依赖？ 如果需要使用处于研发状态的 SNAPSHOT 版本，有两种方式：\n 拉取 sofa-ark 仓库代码，本地执行 mvn install。 在本地 maven setting.xml 文件增加如下 profile 配置: \u0026amp;lt;profile\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;default\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;activation\u0026amp;gt; \u0026amp;lt;activeByDefault\u0026amp;gt;true\u0026amp;lt;/activeByDefault\u0026amp;gt; \u0026amp;lt;/activation\u0026amp;gt; \u0026amp;lt;repositories\u0026amp;gt; \u0026amp;lt;repository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/repository\u0026amp;gt; \u0026amp;lt;/repositories\u0026amp;gt; \u0026amp;lt;pluginRepositories\u0026amp;gt; \u0026amp;lt;pluginRepository\u0026amp;gt; \u0026amp;lt;snapshots\u0026amp;gt; \u0026amp;lt;enabled\u0026amp;gt;true\u0026amp;lt;/enabled\u0026amp;gt; \u0026amp;lt;/snapshots\u0026amp;gt; \u0026amp;lt;id\u0026amp;gt;maven-snapshot\u0026amp;lt;/id\u0026amp;gt; \u0026amp;lt;url\u0026amp;gt;https://oss.sonatype.org/content/repositories/snapshots\u0026amp;lt;/url\u0026amp;gt; \u0026amp;lt;/pluginRepository\u0026amp;gt; \u0026amp;lt;/pluginRepositories\u0026amp;gt; \u0026amp;lt;/profile\u0026amp;gt; Q: 为什么使用 java -jar 启动 Spring Boot/SOFABoot 应用 Ark 包时，应用自动退出？ 因为 SOFAArk 容器不会开启任何非 Daemon 线程，如果是非 Web 应用或者应用启动时不会创建非 Daemon 线程，则应用在执行完 main 方法时，会正常退出。判断 Ark 包是否正常启动，可以观察是否有如下日志出现：\nArk container started in …","date":-62135596800,"description":"","dir":"projects/sofa-boot/faq/","fuzzywordcount":2100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"56f06d32d37d8a5947d7c7ee43d6d955","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/faq/","summary":"Q: Readiness Check 有啥应用场景？ Liveness Check 和 Readiness Check 概念来自于 Kuberentes，分别代表运行时检查和启动时检查。Spring Boot 提供了 Liveness Check，但是没有提供","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-boot/faq/","wordcount":2071},{"author":null,"categories":null,"content":" 与 Prometheus的差异 答：主要包括:（1）Lookout metrics server 支持适配更多的协议接入；（2）聚焦在围绕 ES 生态提供易使用和运维的最佳实践；（3）支持计算能力下推；（4）除了 Metrics 后期会有 tracing，eventing等方案； （5）对聚合函数和 REST API 都做了兼容性的扩展和增强；（6）支持分布式集群部署具备高可用能力。\nLookout客户端会提供多语言(c,go,python\u0026amp;hellip;)支持吗 答：暂时不会。因为 Lookout Gateway已经支持很多主流协议的数据上报，同时也支持自定义扩展。 如果非Java技术栈，我们推荐大家使用其他开源主流的sdk库，比如: Prometheus sdk，Metricbeat等\n\u0026amp;ldquo;In order to improve query performance, you need to add tag filtering! realQuery:jvm.classes.loaded\u0026amp;rdquo; 答：只输入metric name查询会影响查询性能，所以我们强制每个查询至少有一个 tag（label）的筛选能力，比如:\u0026amp;ldquo;jvm.classes.loaded{app=\u0026amp;ldquo;lookout-gateway\u0026amp;rdquo;}\u0026amp;ldquo;。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/faq/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"f05d40c9d503ad466634f0473a5fac40","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/faq/","summary":"与 Prometheus的差异 答：主要包括:（1）Lookout metrics server 支持适配更多的协议接入；（2）聚焦在围绕 ES 生态提供易使用和运维的最佳实践；","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/faq/","wordcount":430},{"author":null,"categories":null,"content":" 咨询 Q: SOFARPC 是蚂蚁金服内部使用的版本吗？ 是的，SOFARPC 有良好的扩展接口，内部使用的版本就是在开源的版本多一些扩展实现。例如我们云上的商业版本集成了蚂蚁金融云的共享版注册中心、链路跟踪等产品；蚂蚁内部的版本集成了蚂蚁内部的注册中心、LDC路由等特性扩展。\nQ: SOFARPC 内部是用 Zookeeper 作为注册中心的吗？可以集成其它 etcd 等注册中心吗？ 在蚂蚁内部使用的是蚂蚁自研的注册中心产品。SOFARPC 的注册中心模块是可扩展的，对内对外使用的都是一套核心接口。目前开源的版本中集成了 Zookeeper，其它的注册中心实现社区已经在集成中。\nQ: 与Dubbo对比？ Dubbo 是阿里集团开源的一款非常优秀的RPC框架，高性能，具有良好的扩展性。Dubbo在国内开源界起步较早，使用者较多，开源生态更加丰富，目前已进入Apache基金会进行孵化。Dubbo最早在阿里巴巴B2B部门广泛使用。更多信息这里就不多介绍了。\nSOFARPC 最早起源于阿里集团内部的 HSF，但是经过了蚂蚁金服集团内部多年的独立发展，目前脱离为一个独立的产品。SOFARPC 在协议，网络，路由，可扩展性等层面都进行了大量的改造和优化的工作，以满足蚂蚁金服大规模金融级的业务场景。在蚂蚁金服内部，SOFARPC 在蚂蚁中间件（SOFAStack）的生态下，有完善的微服务技术栈支持，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量等等。截止 2019 年双十一，SOFARPC 已经被蚂蚁几千个系统所使用，生产环境发布的接口数量超过了十几万。\n但是在开源领域，SOFARPC 目前还是一个起步阶段，开源生态还在建设当中，随着开源计划的推进，我们会在后续的版本里增加各个周边组件，完善微服务技术栈。同时也欢迎大家来贡献，共同打造 SOFAStack。\n对于性能的对比，类似协议下使用的技术点都是差不多的，所以基本上可比性不高。 对于扩展性的对比，两者都具有良好的扩展性。 对于其它功能差异点的话，这里列一些已经开源或者即将开源的功能点供参考：SOFARPC 协议上将支持 HTTP/2、GRPC，能力上如服务预热权重、自动故障降级、协商机制、CRC数据校验等，结合 SOFABoot 可以实现 RPC 框架与业务的类隔离防止类冲突等等，另外 SOFARPC 在跨单元机房的路由，包括配合服务注册体系实现的对异地多活的支撑也是非常有特色的，期望后面能逐步跟大家分享讨论，甚至形成行业标准。而 SOFARPC 结合内部微服务下做一致性的框架实现的「微交易」架构也是蚂蚁在金融领域非常有价值的沉淀，也是跟 dubbo 体系不一样的地方。\nQ: 对比其他 RPC 框架有何优势？ 作为RPC框架，最基本的能力就是 RPC 调用，其它都是些性能、扩展性、功能性的差异，可能各家的侧重点不一样。\nSOFARPC 在蚂蚁金服内部大规模应用足以证明 SOFARPC 是一款可靠的生产级的 RPC 框架。而蚂蚁金服的金融的属性决定了 SOFARPC 在金融场景下的功能侧重点。\nQ: 和Spring Cloud 的对比？ SOFARPC 定位在 RPC 框架，和 Spring Cloud 的比较不在一个对比维度上面。 Spring Cloud 可对比的是 SOFAStack，SOFAStack 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，以及分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，是一套分布式架构的完整的解决方案。SOFAStack 的各个组件会在未来逐渐开源。\n另外，SOFARPC 的 Starter 是基于 Spring Boot 开发的，Spring Cloud 的各个组件也是基于 Spring Boot 开发的，所以两者并不冲突。\n研发类 Q: 为什么不使用 JDK8 SOFARPC 在蚂蚁金服内部还有JDK6的使用场景，所以编译选择JDK7，而编译级别选择JDK6。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/faq/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a6ec77ce5a423c5345394f42c64a416b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/faq/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-rpc/faq/","summary":"咨询 Q: SOFARPC 是蚂蚁金服内部使用的版本吗？ 是的，SOFARPC 有良好的扩展接口，内部使用的版本就是在开源的版本多一些扩展实现。例如我们云上的商业版","tags":null,"title":"常见问题","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/faq/","wordcount":1533},{"author":null,"categories":null,"content":"SOFARPC 可以在使用 Bolt 通信协议的情况下，可以选择不同的序列化协议，目前支持 hessian2 和 protobuf。\n默认的情况下，SOFARPC 使用 hessian2 作为序列化协议，如果需要将序列化协议设置成 protobuf，在发布服务的时候，需要做如下的设置：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleService\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 即在 \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; 标签内增加 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签，并且设置 serialize-type 属性为 protobuf。\n对应的，在引用服务的时候，也需要将序列化协议改成 protobuf，设置方式和发布服务的时候类似：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sofarpc.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleServiceRef\u0026amp;quot; jvm-first=\u0026amp;quot;false\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs serialize-type=\u0026amp;quot;protobuf\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 目前，使用注解的方式尚不能支持设置序列化协议，这个将在后续的版本中支持，详见 ISSUE：https://github.com/sofastack/sofa-boot/issues/278\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/serialization/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"87e2faa84c2c7a7605243dc096bc4e17","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/serialization/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/serialization/","summary":"SOFARPC 可以在使用 Bolt 通信协议的情况下，可以选择不同的序列化协议，目前支持 hessian2 和 protobuf。 默认的情况下，SOFARPC 使用 hessian2 作为序列化协议，如","tags":null,"title":"序列化协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/serialization/","wordcount":296},{"author":null,"categories":null,"content":" SLF4J 提供了 MDC （Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。本文将介绍 SOFATracer 集成的 SLF4J MDC功能，方便用户在只简单修改日志配置文件的前提下输出当前 SOFATracer 上下文 TraceId 以及 SpanId 。\n使用前提 为了在应用中的日志正确打印 TraceId 和 SpanId 参数，我们的日志编程接口需要面向 SLF4J 进行编程，即打印日志的编程接口不要依赖具体的日志实现。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.slf4j\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;slf4j-api\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 引入依赖 如果是 SOFABoot 或者 Spring Boot 的应用具体的日志实现需要大家去引入，我们推荐的日志打印实现是 Logback 和 Log4j2，不推荐 Log4j，同时日志实现建议只使用一个而不要使用多个实现。\n Logback 实现引入： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-logging\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; Log4j2 实现引入： \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-log4j2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;!--SOFABoot 没有管控 log4j2 版本 --\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.4.2.RELEASE\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 配置方法 我们基于 SLF4J MDC 的原理打印对应的 TraceId 和 SpanId，首先我们的应用中的日志编程接口应该面向 SLF4J，如通过如下的方式：\n//引入接口 import org.slf4j.Logger; import org.slf4j.LoggerFactory; //构造日志打印实例 private static final Logger logger = LoggerFactory.getLogger(XXX.class); 其次，我们为了正确打印 TraceId 和 SpanId 参数，我们还需要在日志的配置文件中配置 PatternLayout 的额外参数，这两个参数是 %X{SOFA-TraceId} 和 %X{SOFA-SpanId}，参数值我们均是从 MDC 中获取的值。\n以 Logback 为例配置的 pattern 参数：\n\u0026amp;lt;pattern\u0026amp;gt;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId}, %X{SOFA-SpanId}] ---- %m%n\u0026amp;lt;/pattern\u0026amp;gt; 关键配置项目：[%X{SOFA-TraceId},%X{SOFA-SpanId}] 作为 Logback pattern 的一部分，在对应的 appender 被调用的时候，会根据 pattern 中的占位符替换为当前线程上下文中 TraceId 和 SpanId 的具体值，当前线程中没有对应的 TraceId 和 SpanId 值时，会用“空字符串”替代。 Log4j2 配置 PatternLayout 样例：\n\u0026amp;lt;PatternLayout pattern=\u0026amp;quot;%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%X{SOFA-TraceId},%X{SOFA-SpanId}] ---- %m%n \u0026amp;quot; /\u0026amp;gt; Log4j 配置 PatternLayout 样例：\n\u0026amp;lt;layout class=\u0026amp;quot;org.apache.log4j.PatternLayout\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;param name=\u0026amp;quot;ConversionPattern\u0026amp;quot; value=\u0026amp;quot;%d %-5p %-32t [%X{SOFA-TraceId},%X{SOFA-SpanId}] - %m%n\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/layout\u0026amp;gt; 需要注意的是：[%X{SOFA-TraceId},%X{SOFA-SpanId}] 使我们推荐的打印格式，用户可以根据自己的实际需求场景进行定制\n 附:基于 Log4j2 示例工程的源代码地址。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/print-traceid-spanid/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0d8cc680f811d1db2cffddbba269571c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","summary":"SLF4J 提供了 MDC （Mapped Diagnostic Contexts）功能，可以支持用户定义和修改日志的输出格式以及内容。本文将介绍 SOFATracer 集成的 SLF4J MDC功能，方便用户在只","tags":null,"title":"应用日志打印 traceId 和 spanId","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/","wordcount":701},{"author":null,"categories":null,"content":" SOFADashboard 支持查看应用的IP、端口、健康检查状态等基本信息。此功能依赖 SOFADashboard client ，如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可：\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dashboard-client-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; 除此之外，SOFADashboard 解耦了类似于 SpringBoot Admin 客户端和服务端直连的模式，引入了第三方的储存，目前默认是 redis，因此如果希望能够监控 更多 actuator 信息，可以添加如下依赖：\n\u0026amp;lt;denpendency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;dashboard-ext-redis-store\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/denpendency\u0026amp;gt; 功能展示 相关数据的展示采用了 react-json-view 组件，是的可以直观的看到原始数据集。\n应用维度展示 应用实例 基础信息 健康检查详细数据 环境变量 loggins mappings 配置 client , prefix : com.alipay.sofa.dashboard.client\n 属性 名称 默认值 备注 enable 是否可用 true 当开启时，dashboard client 的相应功能才会作用 instanceIp 指定当前实例的IP 地址 \u0026amp;rdquo;\u0026amp;rdquo; 一般用于测试或者需要指定 IP 的场景 storeInitDelayExp 初始上报延迟 30s Dashboard度量数据存储上报延迟期望(s) storeUploadPeriodExp 上报周期 60s Dashboard度量数据存储上报周期(s) virtualHost 虚拟地址 \u0026amp;rdquo;\u0026amp;rdquo; 服务发布虚拟host（同SofaRpc中相同定义），可使用-Dcom.alipay.sofa.rpc.virtual.host引入 virutalPort 虚拟端口 \u0026amp;rdquo;\u0026amp;rdquo; 服务发布虚拟port（同SofaRpc中相同定义），可使用-Dcom.alipay.sofa.rpc.virtual.port引入 internalHost 内部地址 \u0026amp;rdquo;\u0026amp;rdquo; 容器内部地址（例如podIp等)，可使用-Dcom.alipay.sofa.rpc.virtual.internal.host引入 arkEnable 是否启用ark管理 true 当开启时，dashboard client的相应功能才会作用 注：virtualHost，virutalPort 如果通过com.alipay.sofa.rpc指定了相应参数，则不需要通过dashborad再次指定\nzookeeper , prefix : com.alipay.sofa.dashboard.zookeeper\n 属性 名称 默认值 备注 address 地址 true baseSleepTimeMs 客户端错误重试间隔(ms). 1000 maxRetries 客户端最大重试次数 3 sessionTimeoutMs 客户端会话超时时间(ms) 6000 connectionTimeoutMs 客户端超时时间(ms) 6000 redis , prefix : com.alipay.sofa.dashboard.redis\n 属性 名称 默认值 备注 enble 是否可用 true 当开启时，dashboard会使用redis作为存储 recordTtl 上报周期(ms). 3600 url redis对应url 例如：redis://user:password@example.com:6379 host redis对应host（单实例模式） port redis对应port（单实例模式） password redis密码 Sentinel.master Sentinel模式master master节点名，需参阅集群搭建设置 Sentinel.nodes Sentinel模式节点地址 例如host1:port1;host2:port2;host3:port3 Cluster.nodes Cluster模式节点地址 例如host1:port1;host2:port2;host3:port3 Cluster.maxRedirects Cluster模式重定向次数 0 建议给值，例如10 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/dashboard-client/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"60586c6dfee1f2afcdac88cbe7a36b83","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/dashboard-client/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/dashboard-client/","summary":"SOFADashboard 支持查看应用的IP、端口、健康检查状态等基本信息。此功能依赖 SOFADashboard client ，如果一个应用需要将应用信息展示到 SOFADashboard 管控端，可以通过引入客户端依赖即可： \u0026lt;denpendency\u0026gt;","tags":null,"title":"应用面板","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/dashboard-client/","wordcount":1078},{"author":null,"categories":null,"content":" 首先参考基本代码贡献需知 注意测试用例覆盖率； 代码格式； 验证 Samples 单独导入 Samples 的 Maven 项目； 修改对应 Pom 文件中依赖版本； 验证 Samples 也能正确工作； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/development-use-guide/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"423a54ec3f5fbfc9c0e150eb853738ae","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/development-use-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/development-use-guide/","summary":"首先参考基本代码贡献需知 注意测试用例覆盖率； 代码格式； 验证 Samples 单独导入 Samples 的 Maven 项目； 修改对应 Pom 文件中依赖版本； 验证 Samples 也能正确工作；","tags":null,"title":"开发指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/development-use-guide/","wordcount":63},{"author":null,"categories":null,"content":" 1.如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后在代码目录下执行如下命令：\n mvn clean install 2.版本发布 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号，例如 1.0.1。\n参见: http://semver.org/lang/zh-CN/。\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表 BugFix 版本。只做 bug 修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 1.3.0，那么将会维护 1.2.x 的 bugfix 分支，而 1.1.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 1.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 1.3.0。 发布后拉起下一个版本，例如 1.3.1-SNAPSHOT。 3.测试 单元测试 单元测试例子放到自己开发的模块下，测试类的包名与被测试类所在包相同。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/developer-guide/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fcacc7e89b979f3aec8dc3333a7a3c37","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-acts/developer-guide/","summary":"1.如何编译 安装 JDK7 及以上，Maven 3.2.5 及以上。 直接下载代码，然后在代码目录下执行如下命令： mvn clean install 2.版本发布 版本号 采用三位版本号，分别是主版","tags":null,"title":"开发者手册","type":"projects","url":"/sofastack.tech/projects/sofa-acts/developer-guide/","wordcount":404},{"author":null,"categories":null,"content":"介绍实现架构和相关的细节介绍： * 如何编译 * 架构介绍 * 调用流程 * 基础模型 * 扩展点设计 * 版本发布 * 测试\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/developer-guide/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"903b9f3a5372a75d654f8eeaaf750eeb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/developer-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/developer-guide/","summary":"介绍实现架构和相关的细节介绍： * 如何编译 * 架构介绍 * 调用流程 * 基础模型 * 扩展点设计 * 版本发布 * 测试","tags":null,"title":"开发者手册","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/developer-guide/","wordcount":49},{"author":null,"categories":null,"content":" 线程中使用 java.lang.Runnable 如果用户在代码中通过 java.lang.Runnable 新启动了线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFATracer 提供的 com.alipay.common.tracer.core.async.SofaTracerRunnable 默认完成了此操作，大家可以按照如下的方式使用：\nThread thread = new Thread(new SofaTracerRunnable(new Runnable() { @Override public void run() { //do something your business code } })); thread.start(); 线程中使用 java.util.concurrent.Callable 如果用户在代码中通过 java.util.concurrent.Callable 新启动线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFATracer 提供的 com.alipay.common.tracer.core.async.SofaTracerCallable 默认完成了此操作，大家可以按照如下的方式使用：\nExecutorService executor = Executors.newCachedThreadPool(); SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt; sofaTracerSpanSofaTracerCallable = new SofaTracerCallable\u0026amp;lt;Object\u0026amp;gt;(new Callable\u0026amp;lt;Object\u0026amp;gt;() { @Override public Object call() throws Exception { return new Object(); } }); Future\u0026amp;lt;Object\u0026amp;gt; futureResult = executor.submit(sofaTracerSpanSofaTracerCallable); //do something in current thread Thread.sleep(1000); //another thread execute success and get result Object objectReturn = futureResult.get(); 这个实例中，假设 java.util.concurrent.Callable 返回结果的对象类型是 java.lang.Object，实际使用时可以根据情况替换为期望的类型。\nSOFATracer 对线程池、异步调用场景下的支持 异步场景 异步调用，以 rpc 调用为例，每次 rpc 调用请求出去之后不会等待到结果返回之后才去发起下一次处理，这里有个时间差，在前一个 rpc 调用的 callback 回来之前，又一个新的 rpc 请求发起，此时当前线程中的 TracerContext 没有被清理，则 spanId 会自增，tracerId 相同。\n 对于上面这种情况，SOFATracer 在对于异步情况处理时，不会等到 callback 回来之后，调用 cr 阶段才会清理，而是提前就会清理当前线程的 tracerContext 上下文，从而来保证链路的正确性。\n线程池 目前来说，不管是 SOFARPC 还是 Dubbo 的埋点实现，在使用单线程或者线程池时，情况是一样的：\n 同步调用，线程池中分配一个线程用于处理 rpc 请求，在请求结束之前会一直占用线程；此种情况下不会造成下一个 rpc 请求错拿上一个请求的 tracerContext 数据问题 异步调用，由于异步回调并非是在 callback 中来清理上下文，而是提前清理的，所以也不会存在数据串用问题。 callback 异步回调，这个本质上就是异步调用，所以处理情况和异步调用相同。 附：案例工程\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/async/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e755346c441115663c101638667fe4c0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/async/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/async/","summary":"线程中使用 java.lang.Runnable 如果用户在代码中通过 java.lang.Runnable 新启动了线程或者采用了线程池去异步地处理一些业务，那么需要将 SOFATracer 日志上下文从父线程传递到子线程中去，SOFA","tags":null,"title":"异步线程处理","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/async/","wordcount":726},{"author":null,"categories":null,"content":" 本文用于帮助初次接触 MOSN 项目的开发人员，快速搭建开发环境，完成构建，测试，打包和示例代码的运行。\n注：MOSN 基于 Go 1.12.7 开发，使用 dep 进行依赖管理。\n准备运行环境 如果您使用容器运行 MOSN，请先 安装 docker 如果您使用本地机器，请使用类 Unix 环境 安装 Go 的编译环境 安装 dep : 参考官方安装文档 获取代码 MOSN 项目的代码托管在 Github，获取方式如下：\ngo get -u mosn.io/mosn 如果您的 go get 下载存在问题，请手动创建项目工程\n# 进入 GOPATH 下的 src 目录 cd $GOPATH/src # 创建 mosn.io 目录 mkdir -p mosn.io cd mosn.io # 克隆 MOSN 代码 git clone git@github.com:mosn/mosn.git cd mosn 最终 MOSN 的源代码代码路径为 $GOPATH/src/mosn.io/mosn\n导入IDE 使用您喜爱的 Go IDE 导入 $GOPATH/src/mosn.io/mosn 项目，推荐 Goland。\n编译代码 在项目根目录下，根据自己机器的类型以及欲执行二进制的环境，选择以下命令编译 MOSN 的二进制文件。\n使用 docker 镜像编译 make build // 编译出 linux 64bit 可运行二进制文件 本地编译 使用下面的命令编译本地可运行二进制文件。\nmake build-local 在非 Linux 机器交叉编译 Linux 64bit 可运行二进制文件。\nmake build-linux64 在非 Linux 机器交叉编译 Linux 32bit 可运行二进制文件。\nmake build-linux32 完成后可以在 build/bundles/${version}/binary 目录下找到编译好的二进制文件。\n打包 在项目根目录下执行如下命令进行打包。\nmake rpm 完成后可以在 build/bundles/${version}/rpm 目录下找到打包好的文件。\n创建镜像 执行如下命令进行镜像创建。\nmake image 运行测试 在项目根目录下执行如下命令运行单元测试：\nmake unit-test 在项目根目录下执行如下命令运行集成测试（较慢）。\nmake integrate 从配置文件启动 MOSN 运行下面的命令使用配置文件启动 MOSN。\n./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; 开启 MOSN 转发示例程序 参考 examples 目录下的示例工程运行 Samples。\n使用 MOSN 搭建 Service Mesh 平台 请参考与 Istio 集成。\n","date":-62135596800,"description":"","dir":"projects/mosn/quick-start-setup/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d41615315adb522aa4b84762f113a574","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-setup/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/quick-start-setup/","summary":"本文用于帮助初次接触 MOSN 项目的开发人员，快速搭建开发环境，完成构建，测试，打包和示例代码的运行。 注：MOSN 基于 Go 1.12.7 开发，使用 dep 进行依赖管理。","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/mosn/quick-start-setup/","wordcount":614},{"author":null,"categories":null,"content":" 本文档共分为四部分：\n 第一部分：在 Intellij IDEA 上安装 ACTS IDE 可视化编辑器； 第二部分：向您介绍如何在多模块工程中引入 ACTS 依赖； 第三部分：测试模块下一键搭建 ACTS 框架以管理后续 ACTS 用例； 第四部分：一键生成 ACTS 测试脚本； 1.安装 ACTS IDE 推荐使用 Intellij IDEA 2017，为了您的安全，请仅从该下载源获取 ACTS IDE 安装包： 点击下载 ACTS IDE，\n本地磁盘安装：Preference -\u0026amp;gt; Plugins -\u0026amp;gt; Install plugin from disk -\u0026amp;gt; Restart IDEA 即可。 2.引入 ACTS 依赖 在引入依赖之前，需要您的应用是一个多模块工程（包含 test 模块），后续 ACTS 会将全部的测试代码放置在 test 模块下以便管理 ACTS 用例。\n您可以依据应用的具体情况，选择性阅读以下内容：\n应用已经是完整的多模块工程，可参考文档 2.1 部分，帮助您引入 ACTS 依赖； 应用是多模块工程但无 test 模块，可参考文档 2.2 部分，帮助您快速添加 test 模块； 应用不是一个多模块工程，可参考文档 2.3 部分，帮助您快速构建多模块工程。 如果还没有创建工程，可参考 SOFABoot 快速开始搭建应用。\n2.1多模块应用-包含 test 模块 只需在 test 模块的 pom.xml 中引入 acts-bom 即可。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.2多模块应用-无 test 模块 这里是使用 Intellij IDEA 来创建子模块。\n对着父工程右键 -\u0026amp;gt; New -\u0026amp;gt; Module -\u0026amp;gt; 输入 test 模块名字（一般是 appname-test），分步示例图如下：\n第一步：新建 test 模块 第二步：管理 test 模块 在父工程的 pom.xml 中管理刚刚新建的 test 模块。\n第三步：依赖 ACTS 引入 最后，找到刚刚新建的 test 模块，并在其 pom.xml 中引入 acts-bom 即可。\n\u0026amp;lt;!-- 引入包含 SOFABootApplication 的 pom --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.example\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;example-service\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;!-- 引入 ACTS 依赖 --\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 2.3非多模块应用 如果你已经有了一个不错的 SOFABoot 应用，但它不是一个多模块应用，下面的内容将帮助你快速地将现有工程构建为多模块工程。\n第一步：新建父工程 创建好一个 SOFABoot 工程，然后删除无关的文件，只需保留 pom.xml 文件。\n第二步：新建子模块 新建子工程模块，将原有应用作为子工程并入父工程下，相关依赖管理提到父工程中。以新建 service 模块和 test 模块为例。\n第三步：管理子模块 第四步：依赖引入 最后，在 test 模块的 pom.xml 文件中引入 acts-bom 即可。\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa.acts\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;acts-bom\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${acts.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;type\u0026amp;gt;pom\u0026amp;lt;/type\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 3.一键初始化 ACTS 测试框架 下面只需要你轻轻动动手指即可完成初始化工作。在图3.2中，您需要正确填写应用名称并选择适合应用的编码格式。\n有关一键初始化生成的文件有何作用，可以参考 ACTS 使用手册的框架准备部分。\n4.一键生成测试脚本 4.1启动类 将 service 模块中的启动类，如 SOFABootApplication 拷贝到 test 模块，并增加需要加载的配置文件：classpath*:META-INF/spring/acts-core.xml\n4.2测试脚本 前提条件：务必 mvn 编译工程和生成对象模型，否则会造成 ACTS IDE 不可预料的错误，如无法编辑、数据不正确等。\n接口定义的方法上点击，选择 ACTS 功能 -\u0026amp;gt; 生成测试用例，并在刚生成的测试脚本中矫正 SOFABoot 启动类的 import 位置。\n","date":-62135596800,"description":"","dir":"projects/sofa-acts/getting-started/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"dfc5fb9b394ea14c280568dcb881a8b0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-acts/getting-started/","summary":"本文档共分为四部分： 第一部分：在 Intellij IDEA 上安装 ACTS IDE 可视化编辑器； 第二部分：向您介绍如何在多模块工程中引入 ACTS 依赖； 第三部分：测试模块下一键搭建 ACTS 框","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-acts/getting-started/","wordcount":1074},{"author":null,"categories":null,"content":" 在本文档中，将创建一个 Spring Boot 的工程，引入 SOFABoot 基础依赖，并且引入 SOFABoot 的健康检查扩展能力，演示如何快速上手 SOFABoot。\n环境准备 要使用 SOFABoot，需要先准备好基础环境，SOFABoot 依赖以下环境： - JDK7 或 JDK8 - 需要采用 Apache Maven 3.2.5 或者以上的版本来编译\n创建工程 SOFABoot 是直接构建在 Spring Boot 之上，因此可以使用 Spring Boot 的工程生成工具 来生成，在本文档中，我们需要添加一个 Web 的依赖，以便最后在浏览器中查看效果。\n引入 SOFABoot 在创建好一个 Spring Boot 的工程之后，接下来就需要引入 SOFABoot 的依赖，首先，需要将上文中生成的 Spring Boot 工程的 zip 包解压后，修改 maven 项目的配置文件 pom.xml，将\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-parent\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${spring.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;relativePath/\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 替换为：\n\u0026amp;lt;parent\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofaboot-dependencies\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;${sofa.boot.version}\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/parent\u0026amp;gt; 这里的 ${sofa.boot.version} 指定具体的 SOFABoot 版本，参考发布历史。 然后，添加 SOFABoot 健康检查扩展能力的依赖及 Web 依赖(方便查看健康检查结果)：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;healthcheck-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;org.springframework.boot\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;spring-boot-starter-web\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 最后，在工程的 application.properties 文件下添加 SOFABoot 工程常用的参数配置，其中 spring.application.name 是必需的参数，用于标示当前应用的名称；logging path 用于指定日志的输出目录。\n# Application Name spring.application.name=SOFABoot Demo # logging path logging.path=./logs 运行 可以将工程导入到 IDE 中运行生成的工程里面中的 main 方法（一般上在 XXXApplication 这个类中）启动应用，也可以直接在该工程的根目录下运行 mvn spring-boot:run，将会在控制台中看到启动打印的日志：\n2018-04-05 21:36:26.572 INFO ---- Initializing ProtocolHandler [\u0026amp;quot;http-nio-8080\u0026amp;quot;] 2018-04-05 21:36:26.587 INFO ---- Starting ProtocolHandler [http-nio-8080] 2018-04-05 21:36:26.608 INFO ---- Using a shared selector for servlet write/read 2018-04-05 21:36:26.659 INFO ---- Tomcat started on port(s): 8080 (http) 可以通过在浏览器中输入 http://localhost:8080/sofaboot/versions 来查看当前 SOFABoot 中使用 Maven 插件生成的版本信息汇总，结果类似如下：\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Built-Time: \u0026amp;quot;2018-04-05T20:55:26+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.4\u0026amp;quot; } ] 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，sofaboot/versions 更改为 actuator/versions\n可以通过在浏览器中输入 http://localhost:8080/health/readiness 查看应用 Readiness Check 的状况，类似如下：\n{ status: \u0026amp;quot;UP\u0026amp;quot;, sofaBootComponentHealthCheckInfo: { status: \u0026amp;quot;UP\u0026amp;quot; }, springContextHealthCheckInfo: { status: \u0026amp;quot;UP\u0026amp;quot; }, DiskSpace: { status: \u0026amp;quot;UP\u0026amp;quot;, total: 250140434432, free: 22845308928, threshold: 10485760 } } 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，health/readiness 更改为 actuator/readiness\nstatus: \u0026amp;quot;UP\u0026amp;quot; 表示应用 Readiness Check 健康的。可以通过在浏览器中输入 http://localhost:8080/health 来查看应用的运行时健康状态（可能会随着时间发生变化）。\n注: 在 SOFABOOT 3.X 中调整了 endpoint 路径，/health 更改 …","date":-62135596800,"description":"","dir":"projects/sofa-boot/quick-start/","fuzzywordcount":2200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7f582b905fde4a56791c03d4dd6b5a57","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-boot/quick-start/","summary":"在本文档中，将创建一个 Spring Boot 的工程，引入 SOFABoot 基础依赖，并且引入 SOFABoot 的健康检查扩展能力，演示如何快速上手 SOFABoot。 环境准备 要使用 SOFABo","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-boot/quick-start/","wordcount":2154},{"author":null,"categories":null,"content":" 这个快速开始可以帮您快速在您的电脑上，下载、安装并使用 SOFADashboard。\n环境准备 sofa-dashboard-backend 依赖 Java 环境来运行。请确保是在以下运行环境可以正常使用:\n JDK 1.8+；下载 \u0026amp;amp; 配置。 Maven 3.2.5+；下载 \u0026amp;amp; 配置。 sofa-dashboard-frontend 使用了 Ant Design Pro 脚手架，前端环境请参考 Ant Design\n数据库初始化 Mysql 版本：5.6+\n SOFAArk 管控需要依赖 MySQL 进行资源数据存储，工程目录下有一个 SofaDashboardDB.sql 脚本文件，可以通过执行这个脚本文件进行数据库表的初始化。\nZookeeper  ZooKeeper 3.4.x and ZooKeeper 3.5.x\n SOFADashboard 中的服务治理、SOFAArk 管控依赖于 Zookeeper，需要本地启动 Zookeeper 服务： ZooKeeper Document。\n后端运行 \u0026amp;gt; git clone https://github.com/sofastack/sofa-dashboard.git \u0026amp;gt; cd sofa-dashboard \u0026amp;gt; mvn clean package -DskipTests \u0026amp;gt; cd sofa-dashboard-backend/sofa-dashboard-web/target/ \u0026amp;gt; java -jar sofa-dashboard-web-1.0.0-SNAPSHOT.jar 前端运行 sofa-dashboard-front 是 SOFADashboard 的前端代码工程，基于蚂蚁金服开源的前端框架 antd 开发。\n\u0026amp;gt; cd sofa-dashboard-front \u0026amp;gt; npm i \u0026amp;gt; npm run dev 案例工程 sofastack-dashboard-guides ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/quick-start/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"fa4c5f48810727f71d675255f19617a3","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/quick-start/","summary":"这个快速开始可以帮您快速在您的电脑上，下载、安装并使用 SOFADashboard。 环境准备 sofa-dashboard-backend 依赖 Java 环境来运行。请确保是在以下运行环境可以正常","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/quick-start/","wordcount":313},{"author":null,"categories":null,"content":"SOFARPC 有多种编程界面，下面会对各种界面进行举例： - SOFARPC 方式 - SOFABoot 方式\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/getting-started/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"990bb2211b02b04c3ab6e03f3ba1f74b","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/getting-started/","summary":"SOFARPC 有多种编程界面，下面会对各种界面进行举例： - SOFARPC 方式 - SOFABoot 方式","tags":null,"title":"快速开始","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/getting-started/","wordcount":30},{"author":null,"categories":null,"content":" SOFATracer 接入的组件列表参考：SOFATracer 介绍，在使用时请注意不同组件对应的SOFATracer 版本和 JDK 版本。\n环境准备 要使用 SOFABoot，需要先准备好基础环境，SOFABoot 依赖以下环境： - JDK7 或 JDK8 - 需要采用 Apache Maven 3.2.5 或者以上的版本来编译\n示例列表 下面所有 Samples 工程均为 SOFABoot 工程(同时支持 SpringBoot 工程中使用)，关于如何创建 SOFABoot 工程请参考 SOFABoot 快速开始。\n 组件接入 Spring MVC 埋点接入 HttpClient 埋点接入 DataSource 埋点接入 RestTemplate 埋点接入 OkHttp 埋点接入 Dubbo 埋点接入 采样 上报数据到 Zipkin ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/component-access/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"143f2b9022161ae5a7b10d261752ae5f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/component-access/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/component-access/","summary":"SOFATracer 接入的组件列表参考：SOFATracer 介绍，在使用时请注意不同组件对应的SOFATracer 版本和 JDK 版本。 环境准备 要使用 SOFABoot","tags":null,"title":"快速开始指南","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/component-access/","wordcount":209},{"author":"向旭","categories":null,"content":"TODO\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/code-analyze/summary/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d6fe0ca21825accb191a9eedccf17358","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/summary/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/code-analyze/summary/","summary":"TODO","tags":null,"title":"总览","type":"projects","url":"/sofastack.tech/projects/sofa-registry/code-analyze/summary/","wordcount":1},{"author":null,"categories":null,"content":" SOFATracer 此前的埋点均是基于组件维度的埋点，用户很难在自己业务代码中进行埋点操作，或者增加自定义 tag 值来监控一些链路信息。基于此，SOFATracer 从 2.4.1\u0026amp;frasl;3.0.6 版本开始支持手动埋点和基于注解的埋点方式，帮助用户解决自定义埋点问题。\n使用方式 自定义埋点提供了两种方式，一种是手动埋点，一种是基于注解方式埋点。\n手动埋点 手动埋点的方式遵循 opentracing 规范，SOFATracer 中通过 beforeInvoke 和 afterInvoke 两个函数封装了 span 的周期，如下：\n// 注入 tracer @Autowired Tracer tracer; private void testManual(){ try { // beforeInvoke 开始 SofaTracerSpan sofaTracerSpan = ((FlexibleTracer) tracer).beforeInvoke(\u0026amp;quot;testManual\u0026amp;quot;); sofaTracerSpan.setTag(\u0026amp;quot;manualKey\u0026amp;quot;,\u0026amp;quot;glmapper\u0026amp;quot;); // do your biz } catch (Throwable t){ // 异常结束 ((FlexibleTracer) tracer).afterInvoke(t.getMessage()); } finally { // 正常结束 ((FlexibleTracer) tracer).afterInvoke(); } } 这种方式在使用上没有直接使用注解方便，但是可以直观的了解到 span 的生命周期，另外手动埋点也是对基于注解方式埋点的一种补充，下面介绍。\n基于注解方式 SOFATracer 中提供了 @Tracer 注解，其作用域是 method 级别。\n// 在 hello 方法上使用 @Tracer 注解进行埋点 @Tracer public String hello(String word){ // 自定义 tag 数据 SpanTags.putTags(\u0026amp;quot;author\u0026amp;quot;,\u0026amp;quot;glmapper\u0026amp;quot;); // 失效 helloInner(word); return \u0026amp;quot;glmapper : hello \u0026amp;quot; + word; } // 在 hello 方法上使用 @Tracer 注解进行埋点 @Tracer private String helloInner(String word){ return \u0026amp;quot;glmapper : hello \u0026amp;quot; + word; } @Tracer 是基于 Spring Aop 实现，因此一定程度上依赖 Spring 中的代理机制。如代码片段中所示，helloInner 方法由于执行过程中不会使用代理对象，而是 this，所以会导致 helloInner 的注解埋点失效。那么对于此种情况，就可以使用手动埋点的方式来弥补。\nSpanTags 是 SOFATracer 中提供的工具类，在使用注解或者手动埋点的情况下，可以通过此类提供的静态方法来设置 tag 。\n日志格式 json 格式 {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2019-09-05 10:23:53.549\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;flexible-sample\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe9291567650233504100130712\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.2\u0026amp;quot;,\u0026amp;quot;span.kind\u0026amp;quot;:\u0026amp;quot;client\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:\u0026amp;quot;4ms\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;hello\u0026amp;quot;,\u0026amp;quot;param.types\u0026amp;quot;:\u0026amp;quot;java.lang.String\u0026amp;quot;,\u0026amp;quot;author\u0026amp;quot;:\u0026amp;quot;glmapper\u0026amp;quot;,\u0026amp;quot;sys.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;,\u0026amp;quot;biz.baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} 非 json 格式 2019-09-05 10:25:50.992,flexible-sample,0a0fe9291567650350953100130778,0.2,client,,http-nio-8080-exec-1,4ms,hello,param.types=java.lang.String\u0026amp;amp;author=glmapper\u0026amp;amp;,,\n ","date":-62135596800,"description":"","dir":"projects/sofa-tracer/flexible/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5aaadb77e734e58428a0852d14888e92","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/flexible/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/flexible/","summary":"SOFATracer 此前的埋点均是基于组件维度的埋点，用户很难在自己业务代码中进行埋点操作，或者增加自定义 tag 值来监控一些链路信息。基于此，SOFATracer","tags":null,"title":"手动埋点","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/flexible/","wordcount":566},{"author":null,"categories":null,"content":" SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。\n 本文为《剖析 | SOFAArk 实现原理》第二篇，本篇作者盲僧，来自 OYO。《剖析 | SOFAArk 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:ArkLab/，文末附系列共建列表，目前已完成领取。\n前言 SOFAArk 是 SOFA 团队开源的又一款扛鼎力作，它是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用（模块）合并部署的能力。\n从 2016 年底开始，蚂蚁金服内部开始拥抱新的轻量级类隔离容器框架-SOFAArk。截止 2021 年底，SOFAArk 已经在蚂蚁金服内部 Serverless 场景下落地实践，并已经有数家企业在生产环境使用 SOFAArk ，包括网易云音乐、挖财、溢米教育等。\n本文主要介绍下 SOFAArk Biz 包的打包插件，帮助大家更好的去理解 Biz 包的结构，也是为系列文章做好铺垫。\nSOFAArk Biz 的打包插件是 sofa-ark-maven-plugin ，它可以将普通 Java 工程或者 Spring Boot 工程打包成标准格式的 Ark 包或者 Ark Biz 包，关于 Ark 包和 Ark Biz 包可以参考这里：\n Ark 包：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/ Ark Biz：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/ 本文将从如下三个方面进行介绍：先对插件的使用和打包出来的产物做一个简单介绍，然后告诉大家调试插件的方法，最后对整个插件的原理做一个流程图和阐述。\nSOFAArk ：https://github.com/sofastack/sofa-ark\nSOFAArk 插件使用 文中的示例代码可以参考 我的 github。\n 插件使用 先将 Spring Boot 的打包插件 spring-boot-maven-plugin 删除或者注释，然后再引入如下插件即可：\n\u0026amp;lt;plugin\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;sofa-ark-maven-plugin\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;1.1.1\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;executions\u0026amp;gt; \u0026amp;lt;execution\u0026amp;gt; \u0026amp;lt;goals\u0026amp;gt; \u0026amp;lt;goal\u0026amp;gt;repackage\u0026amp;lt;/goal\u0026amp;gt; \u0026amp;lt;/goals\u0026amp;gt; \u0026amp;lt;/execution\u0026amp;gt; \u0026amp;lt;/executions\u0026amp;gt; \u0026amp;lt;/plugin\u0026amp;gt; \n执行 mvn package 命令后，将会打出如下结构的 3 个 jar 包，大家可以自行解压这三个 jar 包，看一看里面的具体内容，下面我们简单分析一下：\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT.jar ：它是 maven 插件打出来的原生 jar 包，只包含我们写的代码和 manifest 文件，无特殊意义。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-biz.jar ：这个 jar 包称之为 Ark Biz 包，因为 SOFAArk 容器是支持运行多个 Ark Biz 的，所以打成这种包是为了和别的项目一起合并部署使用，另外 Ark 包里也包含了这个。\ntutorial-sofa-ark-maven-plugin-1.0.0-SNAPSHOT-ark-executable.jar ：这个 jar 包称之为 Ark 包，从字面上来看它是一个可执行的 jar 包，即意味着它是一个可以用 java -jar 命令来单独运行的 Fat Jar，类似于我们用 Spring Boot 插件打出来的包。\n后面的分析主要是围绕 Ark 包来做讲解，因为它包含了 Ark Biz 包，所以只要搞明白它是如何生成的，那么对整个插件的原理也就基本了解了。\n与 Spring Boot 插件对比 要想分析出 sofa-ark-maven-plugin 插件的作用，我们需要先和 Spring Boot 的插件进行对比，从打包产物上直观的感受一下两者的区别。\nspring-boot-maven-plugin 插件 spring-boot-maven-plugin 是 SpringBoot 默认提供的打包插件，其功能就是将工程打包成一个可执行的 FATJAR。spring-boot-maven-plugin 打包产物的目录结构如下：\n. ├── BOOT-INF │ ├── classes # 应用的字节码目录 │ └── lib # 应用所依赖的 jar 包 ├── META-INF │ ├── MANIFEST.MF # manifest 文件信息 │ └── maven # 应用的坐标信息 └── org └── springframework └── boot └── loader # 存放的是 Spring Boot Loader 的 class 文件 ├── JarLauncher.class # Spring Boot 启动类 ├── archive ├── data ├── jar └── util MANIFEST.MF 文件内容：\nManifest-Version: 1.0 Archiver-Version: Plexus Archiver Built-By: rrz Start-Class: pers.masteryourself.tutorial.sofa.ark.maven.plugin.MavenP luginApplication Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Spring-Boot-Version: 2.1.4.RELEASE Created-By: Apache Maven 3.5.3 Build-Jdk: 1.8.0_101 Main-Class: org.springframework.boot.loader.JarLauncher MANIFEST.MF 文件中可以看到，描述了当前 jar 的一些核心元素，包括启动类、class 文件路径、lib 依赖路径、jdk 版本等等，这里需要关注的是 Main-Class，SpringBoot 就是通过该类来引导启动的。SOFAArk 应用也提供了类似的引导类及其自身特殊的结构， …","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-build-package-plugin/","fuzzywordcount":3000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5ebfd73573e2f2d529f0303da2fe026c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","publishdate":"0001-01-01T00:00:00Z","readingtime":6,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","summary":"SOFAStack（Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金","tags":null,"title":"打包插件","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/","wordcount":2994},{"author":null,"categories":null,"content":" 1. 集成部署模式 1.1 扩容 registry-integration 假设目前已经部署了 3 台 registry-integration，分别是 node1/node2/node3，扩容的新节点是 node4。\n操作步骤：\n第一步. 部署新的 registry-integration 节点\n首先参考部署文档，将 registry-integration.tgz 在新节点 node4 上部署起来，值得注意的是，node4 需要将 nodes.metaNode 配置项指定为4台机器的地址列表：\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt; 在这一步中，node4启动完成后，访问 curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check 状态显示是不健康，因为 node4 尚未加入集群，要加入集群，需要做第二步。\n第二步. 调用 changePeer 使新节点加入集群\n对已经存在的 node1/node2/node3 的任意一台，执行“修改节点列表”的运维命令，将原有由 node1/node2/node3 构成的集群，改为 node1/node2/node3/node4 集群：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;,\u0026amp;lt;node3\u0026amp;gt;,\u0026amp;lt;node4\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;node4\u0026amp;gt;:9615/health/check 状态显示应当是健康。\n1.2 缩容 registry-integration 假设集群目前有3台机器 node1/node2/node3，需要缩容 node3。\n1.2.1 平滑缩容 操作步骤：\n第一步. 调用 changePeer 移除节点\n对 node1/node2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“node1/node2/node3”改为“node1/node2”，即把node3移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;node3\u0026amp;gt;:9615/health/check 状态显示应当是不健康的，因为 node3 已经被踢出了集群。\n**第二步.关闭 node3 **\n这一步可选，因为 node3 已经被移除集群了，所以即便 node3 还在运行，也对原集群不影响。\n1.2.2 宕机处理 假设 node3 已经宕机，也需要将 node3 移除出集群\n操作步骤：\n第一步. 调用 changePeer 移除节点\n对 node1/node2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“node1/node2/node3”改为“node1/node2”，即把 node3 移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;node1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;node1\u0026amp;gt;,\u0026amp;lt;node2\u0026amp;gt;\u0026amp;quot; 2. 独立部署模式 2.1 扩容 registry-meta 假设目前已经部署了3台 registry-meta ，分别是 metaNode1/metaNode2/metaNode3，扩容的新节点是 metaNode4.\n操作步骤：\n第一步. 部署新的 registry-meta 节点\n首先参考部署文档，将 registry-meta.tgz 在新节点 metaNode4 上部署起来，值得注意的是，metaNode4 需要将 nodes.metaNode 配置项指定为4台机器的地址列表：\nnodes.metaNode=DefaultDataCenter:\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;,\u0026amp;lt;metaNode3\u0026amp;gt;,\u0026amp;lt;metaNode4\u0026amp;gt; 在这一步中，metaNode4 启动完成后，访问 curl http://localhost:9615/health/check 状态显示是不健康，因为 metaNode4 尚未加入集群，要加入集群，需要做第二步。\n第二步. 调用 changePeer 使新节点加入集群\n对已经存在的 metaNode1/metaNode2/metaNode3 的任意一台，执行“修改节点列表”的运维命令，将原有由 metaNode1/metaNode2/metaNode3 构成的集群，改为 metaNode1/metaNode2/metaNode3/metaNode4 集群：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;metaNode1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;,\u0026amp;lt;metaNode3\u0026amp;gt;,\u0026amp;lt;metaNode4\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://localhost:9615/health/check 状态显示应当是健康。\n2.2 缩容 registry-meta 假设集群目前有3台机器 metaNode1/metaNode2/metaNode3，需要缩容 metaNode3。\n2.2.1 平滑缩容 操作步骤：\n第一步. 调用 changePeer 移除节点\n对 metaNode1/metaNode2 的任意一台，执行“修改节点列表”的运维命令，将集群列表由“metaNode1/metaNode2/metaNode3”改为“metaNode1/metaNode2”，即把 metaNode3 移除出地址列表：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;metaNode1\u0026amp;gt;:9615/manage/changePeer\u0026amp;quot; -d \u0026amp;quot;ipAddressList=\u0026amp;lt;metaNode1\u0026amp;gt;,\u0026amp;lt;metaNode2\u0026amp;gt;\u0026amp;quot; 做完这一步之后，访问 curl http://\u0026amp;lt;metaNode3\u0026amp;gt;:9615/health/check 状态显示应当是不健康的，因为metaNode3已经被踢出了集群。\n第二步. 关闭 metaNode3\n这一步可选，因为 metaNode3 已经被移除集群了，所以即便 metaNode3 还在运行，也对 …","date":-62135596800,"description":"","dir":"projects/sofa-registry/scale/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"57de6dc4da1292063ff25ecea9ffbd08","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/scale/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/scale/","summary":"1. 集成部署模式 1.1 扩容 registry-integration 假设目前已经部署了 3 台 registry-integration，分别是 node1/node2/node3，扩容的新节点","tags":null,"title":"扩容与缩容","type":"projects","url":"/sofastack.tech/projects/sofa-registry/scale/","wordcount":1695},{"author":null,"categories":null,"content":" 自定义引擎各个阶段 可以在测试脚本中或者基类中重写 ActsTestBase 提供的 API。\n 重写 prepare，execute，check，clear 等。可以通过在 super.prepare() 之前或者之后进行某些操作。 重写 process 方法，在 super.process() 之前或之后进行操作。可将整个脚本重新编排，例如在现有的清理 -\u0026amp;gt; 准备 -\u0026amp;gt; 执行 -\u0026amp;gt; 校验流程中增加一些个性化的步骤。 重写 beforeActsTest、afterActsTest，可以在每一个用例运行前后做一些个性化的操作，如准备上下文、缓存刷新等。 参数化 在结果期望和数据库期望中可以使用 $变量名 来标识某个值是变量，测试脚本中可以把值设置进去； 支持范围：入参、返回结果、数据库表字段，支持类型：目前仅支持 String 的参数化。\n使用方法：\n（1）界面以 $ 开头定义变量\n（2）代码中给变量赋值\n@Override public void beforeActsTest(ActsRuntimeContext actsRuntimeContext) { actsRuntimeContext.paramMap.put(\u0026amp;quot;roleId\u0026amp;quot;, \u0026amp;quot;123\u0026amp;quot;); actsRuntimeContext.refreshDataParam(); } 在写 DB 数据期望的时候，也可以通过 = 符号来进行赋值，表示这个值来自于查询结果，后面的表就可以使用这个变量作为值。\n假设接口会向 2 张表插入数据。\n id_A value_A 123 abc id_B value_B abc efg 查询的时候要先通过接口返回的 A 表的 id_A 查到 value_A, 然后把 value_A 作为 B 表的查询条件，在插件上面可以这样写：\n 字段 flag 值 id_A C $param1 value_A Y =param2 字段 flag 值 id_B C $param2 value_B Y efg 上面操作说明：\n =param2 和 $param2 的操作，表示框架会先从 A 表查出 value_A 然后 select from B where id_B = value_A，进而得到全部 B 表的属性值； $param1 表示可以在代码中对 id_A 赋值，代码形如： actsRuntimeContext.paramMap.put(\u0026amp;quot;param1\u0026amp;quot;,\u0026amp;quot;123\u0026amp;quot;); 表示对变量 param1 赋值 123，上述代码可以写到脚本的 beforeActsTest 里面，这样在查询 A 表之前，框架就会将 123 赋值给 id_A。\n参数组件化 目前仅支持 String 的组件化\n如果属性是需要动态生成的字符串，例如某些 ID，可以通过 @ 符号来调用一个组件生成这个属性，组件要放在跟 test 同级的 component 包下，即：com.corpname.appname.acts.component (这里appname是系统名，corpname是公司名，如alipay)。\npublic class MyComponent { @TestComponent(id = \u0026amp;quot;test\u0026amp;quot;) public String test(String param) { return param+\u0026amp;quot;123\u0026amp;quot;; } } 并通过 acts-config.properties 配置指明参数化组件使其生效，多个组件使用英文逗号 , 分隔，末尾注意不必要的空格。\nparam_components=IdGenerateComponent,NoGenerateComponent 如上图 alis_value 值为 @test?param=123 则在用例运行时会自动替换 alis_value 的取值。\n组件的 ID 要保证唯一，否则默认调用第一个，如果声明了一个无参组件方法，调用方式为 @test 即可，同时支持组件化参数通过变量传入：@test?param=$id，实际执行时会替换 $id 的值为实际值。\n脚本中也可以通过代码调用：\nActsComponentUtil.run(\u0026amp;quot;@test?param=123\u0026amp;quot;); 自定义组件多个参数的场景使用 \u0026amp;amp; 分割参数，如 @test?param1=xxx\u0026amp;amp;param2=yyy\nDB 工具类 1. 指定数据源进行 DB 表访问 框架 ActsDBUtils 中提供了 DB 的指定数据源访问，用于个性化 DB 操作。例如某张表的某条纪录不是准备数据也不是校验数据，但是需要在运行后删掉或更新，此时就需要用到该工具操作 DB 数据。\n使用前配置\n使用指定数据源方式需要在 acts-config.properties 文件中首先将要指定的数据源进行配置，配置例子如下：\ndatasource_bean_name_exampleDataSource=com.alipay.example.dal;exampleDataSource #整体配置的格式为：datasource_bean_name_xxx(数据源名字)=yyy(数据源所在 Module);xxx(数据源名字) 指定数据源方法\nActsDBUtils 工具类中指定数据源方法说明：\npublic static int getUpdateResultMap(String sql,String tableName,String dbConfigKey); 该方法用于指定数据源进行表的增、删和改的操作。sql 为标准 sql 语句，tableName 为逻辑表名，dbConfigKey 为该 表所在的逻辑数据源配置，与 acts-config.properties 配置的 xxx（数据源名字）相同。\npublic static List\u0026amp;lt;Map\u0026amp;lt;String, Object\u0026amp;gt;\u0026amp;gt; getQueryResultMap(String sql, String tableName,String dbConfigKey); 该方法用于指定数据源进行表的查询操作，以上两个方法都是原子化的 DB 表的操作，如果有其他的 DB 需求可以在上面进行 封装。\n2. 不指定数据源进行 DB 表访问 该方式下 ACTS 框架默认根据表名搜索数据源，工具方法的使用步骤如下：\n使用前配置\ndatasource_bundle_name=com.alipay.example.common.dal ds_exampleDataSource=table1,tabal2 #整体配置的格式为 #datasource_bundle_name=数据源所在模块名 #ds_数据源名字=该数据源下的逻辑表名 不指定数据源方法\npublic static int getUpdateResultMap(String …","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-api/","fuzzywordcount":2000,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ce7e264713a6f7a3f0672e2432489f59","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-api/","summary":"自定义引擎各个阶段 可以在测试脚本中或者基类中重写 ActsTestBase 提供的 API。 重写 prepare，execute，check，clear 等。可以通过在 super.prepare() 之","tags":null,"title":"扩展功能","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-api/","wordcount":1955},{"author":null,"categories":null,"content":" ExtensionLoader 为了对 SOFARPC 各个环节的都有充足的可扩展性，SOFA-RPC定义了一套十分灵活的扩展机制，所有扩展实现都是平等的。\n这套机制不管是对SOFA-RPC本身的开发者其使用者而言都是非常有用的。SOFA-RPC将其自身抽象为了多个模块，各个模块之间无显示依赖，通过SPI的方式进行交互。\n这套扩展机制抽象了这一SPI的交互方式。如果你读了上面文档讲到的 Filter 和 Router，应该已经有所体会。\n这里讲一下如何使方式进行扩展的。\nSOFARPC 提供了 ExtensionLoader 的能力。\n扩展点设计 SOFARPC 定义了一个注解 @Extensible，该注解标识在接口或者抽象类上，标识该类是一个扩展点。即告诉 SOFARPC 该类是可扩展的，需要寻找该扩展点的实现，同时也定义了寻找实现类的文件名称，是否单例。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extensible { /** * 指定自定义扩展文件名称，默认就是全类名 * * @return 自定义扩展文件名称 */ String file() default \u0026amp;quot;\u0026amp;quot;; /** * 扩展类是否使用单例，默认使用 * * @return 是否使用单例 */ boolean singleton() default true; /** * 扩展类是否需要编码，默认不需要 * * @return 是否需要编码 */ boolean coded() default false; } SOFARPC 同时定义了 @Extension 注解，标识该类是一个扩展实现类。也定义了扩展点在文件中寻找扩展实现时使用的名字。\n@Documented @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.TYPE }) public @interface Extension { /** * 扩展点名字 * * @return 扩展点名字 */ String value(); /** * 扩展点编码，默认不需要，当接口需要编码的时候需要 * * @return 扩展点编码 * @see Extensible#coded() */ byte code() default -1; /** * 优先级排序，默认不需要，大的优先级高 * * @return 排序 */ int order() default 0; /** * 是否覆盖其它低{@link #order()}的同名扩展 * * @return 是否覆盖其它低排序的同名扩展 * @since 5.2.0 */ boolean override() default false; /** * 排斥其它扩展，可以排斥掉其它低{@link #order()}的扩展 * * @return 排斥其它扩展 * @since 5.2.0 */ String[] rejection() default {}; } 新增扩展点 1.定义扩展点。\n@Extensible public interface Person { void getName(); } 2.定义扩展实现\n@Extension(\u0026amp;quot;A\u0026amp;quot;) public class PersonA implements Person{ @Override public void getName() { System.out.println(\u0026amp;quot;li wei\u0026amp;quot;); } } 3.编写扩展描述文件：META-INF/services/sofa-rpc/com.alipay.sofa.rpc.extension.Person。文件内容如下：\nA=com.alipay.sofa.rpc.extension.PersonA 4.加载扩展点，获取到扩展实现类使用。\nPerson person = ExtensionLoaderFactory.getExtensionLoader(Person.class).getExtension(\u0026amp;quot;A\u0026amp;quot;); 已有扩展点 如果想对 SOFARPC 的各个内置扩展点进行功能扩展，可直接实现已有扩展，配置扩展模式文件即可。\n目前已有的扩展点如下：\n 接口名 中文名 备注 内置实现 com.alipay.sofa.rpc.client.Client 客户端 Failover、Failfast com.alipay.sofa.rpc.client.ConnectionHolder 连接管理器 AllConnect（全部连接） com.alipay.sofa.rpc.client.AddressHolder 地址管理器 单组、多组 com.alipay.sofa.rpc.client.LoadBalancer 负载均衡 随机、轮询、最少并发、一致性hash、本机优先 com.alipay.sofa.rpc.client.Router 路由器 com.alipay.sofa.rpc.codec.Compressor 压缩 snappy、quicklz com.alipay.sofa.rpc.codec.Serializer 序列化器 java、hessian、pb com.alipay.sofa.rpc.filter.Filter 拦截器 com.alipay.sofa.rpc.protocol.Protocol 协议 bolt、dubbo、rest com.alipay.sofa.rpc.protocol.ProtocolDecoder 协议解码 bolt com.alipay.sofa.rpc.protocol.ProtocolEncoder 协议编码 bolt com.alipay.sofa.rpc.protocol.TelnetHandler telnet的响应 version、help、ls com.alipay.sofa.rpc.proxy.Proxy 代理类 java、javassist com.alipay.sofa.rpc.registry.Registry 注册中心 zookeeper com.alipay.sofa.rpc.server.Server 服务端实现 bolt、rest com.alipay.sofa.rpc.transport.ClientTransport 客户端长连接实现 netty com.alipay.sofa.rpc.transport.ServerTransport 服务端长连接实现 netty ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/extension-loader/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"acc5628da3a7ea2df5eb68bd8ec17159","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/extension-loader/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-rpc/extension-loader/","summary":"ExtensionLoader 为了对 SOFARPC 各个环节的都有充足的可扩展性，SOFA-RPC定义了一套十分灵活的扩展机制，所有扩展实现都是平等的。 这套机制不管是对SOFA-RP","tags":null,"title":"扩展点设计","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/extension-loader/","wordcount":1131},{"author":null,"categories":null,"content":" SOFARPC 的服务发布和引用的基本配置已经在「编程界面」章节中说明，这里主要介绍服务发布和引用的一些特性。\n同一服务发布多种协议 在 SOFARPC 中，可以将同一个服务发布成多个协议，让调用端可以使用不同的协议调用服务提供方。\n如果使用 Java API，可以按照如下的代码构建多个 ServerConfig，不同的 ServerConfig 设置不同的协议，然后将这些 ServerConfig 设置给 ProviderConfig：\nServerConfig serverConfigA = new ServerConfig(); ServerConfig serverConfigB = new ServerConfig(); List\u0026amp;lt;ServerConfig\u0026amp;gt; serverConfigs = new ArrayList\u0026amp;lt;ServerConfig\u0026amp;gt;(); serverConfigs.add(serverConfigA); serverConfigs.add(serverConfigB); providerConfig.setServer(serverConfigs); 如果使用 XML 的方式，直接在 \u0026amp;lt;sofa:service\u0026amp;gt; 标签中增加多个 binding 即可：\n\u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt/\u0026amp;gt; \u0026amp;lt;sofa:binding.rest/\u0026amp;gt; \u0026amp;lt;sofa:binding.dubbo/\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 如果使用 Annotation 的方式，在 @SofaService 中增加多个 binding 即可：\n@SofaService( interfaceType = SampleService.class, bindings = { @SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;), @SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;) } ) public class SampleServiceImpl implements SampleService { // ... } 同一服务注册多个注册中心 如果使用 API 的方式，构建多个 RegistryConfig 设置给 ProviderConfig 即可：\nRegistryConfig registryA = new RegistryConfig(); RegistryConfig registryB = new RegistryConfig(); List\u0026amp;lt;RegistryConfig\u0026amp;gt; registryConfigs = new ArrayList\u0026amp;lt;RegistryConfig\u0026amp;gt;(); registryConfigs.add(registryA); registryConfigs.add(registryB); providerConfig.setRegistry(registryConfigs); 如果是使用 XML 的方式\n需要在properties里配置注册中心\ncom.alipay.sofa.rpc.registries.zookeeper=zookeeper://127.0.0.1:2181 com.alipay.sofa.rpc.registries.nacos=nacos://127.0.0.1:8848 \u0026amp;lt;bean id=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacadeImpl\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;sampleFacadeImpl\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.bean.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs registry=\u0026amp;quot;nacos,zookeeper\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; 如果使用 Annotation 的方式\n需要在properties里配置注册中心\ncom.alipay.sofa.rpc.registries.zookeeper=zookeeper://127.0.0.1:2181 com.alipay.sofa.rpc.registries.nacos=nacos://127.0.0.1:8848 @SofaService(bindings = {@SofaServiceBinding(registry = \u0026amp;quot;nacos\u0026amp;quot;), @SofaServiceBinding(registry = \u0026amp;quot;zookeeper\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { // ... } 方法级参数设置 在 Java API 方式中，调用 MethodConfig 对象相应的 set 方法即可设置对应的参数，如下所示：\nMethodConfig methodConfigA = new MethodConfig(); MethodConfig methodConfigB = new MethodConfig(); List\u0026amp;lt;MethodConfig\u0026amp;gt; methodConfigs = new ArrayList\u0026amp;lt;MethodConfig\u0026amp;gt;(); methodConfigs.add(methodConfigA); methodConfigs.add(methodConfigB); providerConfig.setMethods(methodConfigs); //服务端设置 consumerConfig.setMethods(methodConfigs); //客户端设置 使用 XML 的方式，在对应的 binding 里面使用 \u0026amp;lt;sofa:method\u0026amp;gt; 标签即可设置对应的参数：\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;personReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.boot.examples.demo.rpc.bean.PersonService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/publish-and-reference/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"6a78b8b84b226eaf1e6d2b1ff1d15fee","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/publish-and-reference/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/publish-and-reference/","summary":"SOFARPC 的服务发布和引用的基本配置已经在「编程界面」章节中说明，这里主要介绍服务发布和引用的一些特性。 同一服务发布多种协议 在 SOFARPC 中，可以将同一个服务","tags":null,"title":"服务发布与引用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/publish-and-reference/","wordcount":699},{"author":null,"categories":null,"content":" 自动化 推荐版本: ES 5\n自动初始化库 Lookout 服务器端启动时，会自动检查（默认开启，可关闭）所连接的ES机器(或集群)，检查 Metrics 数据存储的 Index和 Mapping 是否已经建立， 如果未初始化则进行初始化工作。默认初始化并产生索引alias: \u0026amp;ldquo;lookout-active-metrics，lookout-search-metrics\u0026amp;rdquo;。\n 看下 Alias 和 Indices\nhttp://localhost:9200/_cat/aliases lookout-active-metrics metrics-2019.05.30-1 - - - lookout-search-metrics metrics-2019.05.30-1 - - - 看下存储 Mapping：\nhttp://localhost:9200/lookout-active-metrics/_mapping { \u0026amp;quot;metrics-2019.05.30-1\u0026amp;quot;: { \u0026amp;quot;mappings\u0026amp;quot;: { \u0026amp;quot;metrics\u0026amp;quot;: { \u0026amp;quot;properties\u0026amp;quot;: { \u0026amp;quot;id\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;keyword\u0026amp;quot; }, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;keyword\u0026amp;quot; }, \u0026amp;quot;time\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;date\u0026amp;quot; }, \u0026amp;quot;value\u0026amp;quot;: { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;float\u0026amp;quot; } } } } } } 自动运维 自动 Indices Rollover\n 如果超过1天，则切换新索引 如果单个索引的 docs 数目超过: 100000000，则切换新索引； 自动删除过期 Indices\n 默认最多只保留 7 天的数据，过期的 Index 会自动检查并被删除；\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-es/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"016a397aa24e885b5aaa32cf1cac3f35","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-es/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-es/","summary":"自动化 推荐版本: ES 5 自动初始化库 Lookout 服务器端启动时，会自动检查（默认开启，可关闭）所连接的ES机器(或集群)，检查 Metrics 数据存储的 Index和 Mapping 是","tags":null,"title":"服务器端 ES 存储使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-es/","wordcount":315},{"author":null,"categories":null,"content":"由于 SOFALookout Metrics Server 兼容 Prometheus API,所以 Grafana 集成 Lookout 很简单，只需要选择 Prometheus 作为数据源协议即可 （注意 Lookout Server 的默认查询端口也是: 9090）。\n下图展示 Grafana 新增数据源配置:\n使用 PromQL 查询展示数据:\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-grafana/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"45b8a5084ac2a151af28ff11413b13cb","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","summary":"由于 SOFALookout Metrics Server 兼容 Prometheus API,所以 Grafana 集成 Lookout 很简单，只需要选择 Prometheus 作为数据源协议即可 （注意 Lookout Server 的默认查询端口也是: 9090）。 下图展示 Grafana 新增数据源配置","tags":null,"title":"服务器端 Grafana 使用指南","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-grafana/","wordcount":81},{"author":null,"categories":null,"content":" 如果需要扩展支持适配一个新的数据存储，可能需要下面的步骤:\n1.写入适配 需要在 gateway/metrics/exporter/ 下面添加新的 exporter; 参考已有的 \u0026amp;ldquo;gateway/metrics/exporter/elasticsearch\u0026amp;rdquo; 模块；\n 提供个新存储的 MetricExporter 功能是写入数据到存储中，参考\u0026amp;rdquo;com.alipay.sofa.lookout.gateway.metrics.exporter.es.ESMetricExporter\u0026amp;rdquo;，提供个新存储的 MetricExporter；\n 提供个该模块的spring配置类 参考 \u0026amp;ldquo;com.alipay.sofa.lookout.gateway.metrics.exporter.es.spring.bean.config.EsExporterConfiguration\u0026amp;rdquo;，它包括 ESProperties 的配置描述映射。尤其重要的是带有注解 @ConditionalOnExporterComponent方便该功能开关；\n 在 \u0026amp;ldquo;com.alipay.sofa.lookout.gateway.metrics.starter.MetricPipelineConfiguration\u0026amp;rdquo; 中 @import 上述存储spring配置类； 2.查询数据适配 需要在 server/metrics 目录下，添加新 storage 扩展； 参考 “server/metrics/storage-ext-es” 模块，比如新增“storage-ext-**”\n 提供个新的存储 Storage 实现； 参考已有 “com.alipay.sofa.lookout.server.storage.ext.es.ElasticSearchStorage”，实现Storage接口。这里也需要ES实现对应的 “QueryStmt”，”LabelValuesStmt“，”LabelNamesStmt“.\n 提供个该模块的spring配置类 参考\u0026amp;rdquo;com.alipay.sofa.lookout.server.storage.ext.es.spring.bean.config.ElasticSearchServerConfig\u0026amp;rdquo;,提供 Storage的实例。 另外参考支持”@ConditionalOnProperty“的功能开关配置；\n 在 \u0026amp;ldquo;com.alipay.sofa.lookout.server.starter.ServerAutoConfiguration\u0026amp;rdquo; 中 @import 上述存储spring配置类； 3.最后贡献建议 提issue说明需求，并可以介绍下方案； 保证测试覆盖； fork 代码，编译通过后，提交 PR； ","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-storage-ext/","fuzzywordcount":900,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b990dad82668bc22c24d4ad0468f0535","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","summary":"如果需要扩展支持适配一个新的数据存储，可能需要下面的步骤: 1.写入适配 需要在 gateway/metrics/exporter/ 下面添加新的 exporter; 参考已有的 \u0026ldquo;gateway/metrics/exporter/elasticsearch\u0026rdquo; 模块； 提供个新存储的 MetricExporter 功能是写入数据","tags":null,"title":"服务器端 Metrics 存储扩展机制","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/","wordcount":864},{"author":null,"categories":null,"content":" 1. Tag选择器的“in”筛选 =~| 将tag符合表达式的提供的值选择出来，类似于SQL中的in语义\n示例\n将app为 foo 或 foo2的应用时序数据查询出来\njvm.memory.heap.used{app=~|\u0026amp;quot;foo|foo2\u0026amp;quot;,instance_id=\u0026amp;quot;xxx\u0026amp;quot;} 2. Tag选择器的\u0026amp;rdquo;not in\u0026amp;rdquo;筛选 !~| 将tag不符合表达式提供的值选择出来,类似SQL中的not in语义\n示例\njvm.memory.heap.used{app!~|\u0026amp;quot;foo|foo2\u0026amp;quot;,instance_id=\u0026amp;quot;xxx\u0026amp;quot;} 3. Increase2函数 （类似Increase），适用于Promethues的Counter型指标 increase 会根据根据查询步长，做个时间点上的函数估值（根据既有增长斜率）。所以可能是非整型。 如果你就想返回真实时间点的整数差值，不愿估算目标时刻的近视值。那么推荐使用 Increase2。\n需要组合聚合函数时，记住“Rate then sum, never sum then rate”（这里说的rate 与 increase 函数类似）\nsum by (job)(Increase2(http_requests_total{job=\u0026amp;quot;node\u0026amp;quot;}[5m])) # This is okay 4. \u0026amp;ldquo;histogram_quantile\u0026amp;rdquo; 与(Lookout)自定义 \u0026amp;ldquo;zhistogram_quantile\u0026amp;rdquo; histogram_quantile ，是对使用prometheus client得到的 metrics buckets进行分析；\nzhistogram_quantile，是对使用 lookout sdk的得到的 metrics buckets 进行分析;\n5. Promethues 一些最佳实践总结 rate，increase 函数用于计算指标的速率，在使用时要根据指标数据的采集或上报时间间隔来进行over_time时间的控制。比如metrics数据是1分钟上报一次,如果想获取某个metric指标的1分钟的速率，应该按如下方式写promql语句\nrate(http_requestl{token=\u0026amp;quot;mobile\u0026amp;quot;}[2m] step 表示最终显示的采样（步长），如果和range （比如2m）保持一致，表示原样输出，不采样。 如果想进行采样，step \u0026amp;gt; range 就行了！ 所以总的来说，step \u0026amp;gt;= range.\nrange, 从实际使角度，推荐 range 值要尽量明显大于数据实际的上报时间间隔才有意义，比如上报单位是30秒，那range尽量\u0026amp;gt;= 1分钟。\n","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-promql-feature-enhancement/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3bd5cd1f9d3ce3f9ba5b503ef0ba9da1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","summary":"1. Tag选择器的“in”筛选 =~| 将tag符合表达式的提供的值选择出来，类似于SQL中的in语义 示例 将app为 foo 或 foo2的应用时序数据查询出来","tags":null,"title":"服务器端 PromQL 语法特性增强","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/","wordcount":691},{"author":null,"categories":null,"content":" 使用 Lookout sdk是推荐方式，当然 Lookout gateway 还支持其他协议上报。（但由于属于非标接入，细节可联系我们）\n注意如果使用 非lookout sdk ，自己一定注意控制客户端metrics数量！ [Don\u0026amp;rsquo;t over use labels(tags)]\n1.Promethues Push协议写入支持 Lookout-gateway这里扮演的是一个 prometheus-pushgateway 角色：\necho \u0026amp;quot;some_metric{k1=\u0026amp;quot;v1\u0026amp;quot;} 3.14\u0026amp;quot; | curl --data-binary \\ @- http://localhost:7200/prom/metrics/job/{job}/app/{app}/step/{step} 区别在于：\u0026amp;rdquo;http://localhost:7200/prom/\u0026amp;ldquo;，端口为7200，加了级主路径为/prom.\n 【必选】URL路径变量 {app} {job} 和{step}，必须要指定哦。step 单位秒，表示您定时上报的时间间隔（假如10s 上报一次数据，那么 step=10）\n 【可选】如果和lookout gateway间有网络代理，建议URL 里也附带上客户端真实 ip （如 \u0026amp;ldquo;/ip/{ip}\u0026amp;ldquo;）。\n 上报格式样式: 【 http_requests_total{method=\u0026amp;ldquo;post\u0026amp;rdquo;,code=\u0026amp;ldquo;200\u0026amp;rdquo;} 1027 】，多个以换行符【\u0026amp;rsquo;\\n\u0026amp;rsquo;】分割；\n 更多细节可以参考：prometheus-pushgateway ，你可以选择官方对应编程语言的SDKs\n 2. Lookout 自有协议写入支持 默认的收集服务和数据协议标准(即Lookout自有的协议支持标准)\n localhost:7200/lookout/metrics/app/{app}/step/{step}\ncurl -H \u0026amp;quot;Content-type:text/plain\u0026amp;quot; -X POST -d \u0026#39;xx\u0026#39; \\ localhost:7200/lookout/metrics/app/{app}/step/{step} 请求体是一种批量复合形式。内容是多条 metrics 数据以 \u0026amp;ldquo;\\t\u0026amp;rdquo; 进行连接；\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;count\u0026amp;quot;:0,\u0026amp;quot;rate\u0026amp;quot;:0.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;value\u0026amp;quot;:99.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;elapPerExec\u0026amp;quot;:0.0,\u0026amp;quot;totalTime\u0026amp;quot;:0.0,\u0026amp;quot;max\u0026amp;quot;:0.0}} \\t{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;,\u0026amp;quot;tags\u0026amp;quot;:{\u0026amp;quot;k1\u0026amp;quot;:\u0026amp;quot;v1\u0026amp;quot;},\u0026amp;quot;m_name\u0026amp;quot;:{\u0026amp;quot;totalAmount\u0026amp;quot;:0.0,\u0026amp;quot;rate\u0026amp;quot;:0.0,\u0026amp;quot;max\u0026amp;quot;:0}} 上面内容中组成部分分别是：counter型,gauge型,Timer型\n 其中单条数据结构\n{ \u0026amp;quot;time\u0026amp;quot;: \u0026amp;quot;1970-01-01T08:00:00+08:00\u0026amp;quot;, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;k1\u0026amp;quot;: \u0026amp;quot;v1\u0026amp;quot; }, \u0026amp;quot;m_name\u0026amp;quot;: { \u0026amp;quot;count\u0026amp;quot;: 0, \u0026amp;quot;rate\u0026amp;quot;: 0 } } tag 的 value 需要转义;\n 如果内容由进行了 snappy 压缩，需添加请求头 \u0026amp;ldquo;Content-Encoding:snappy\u0026amp;rdquo;,且\u0026amp;rdquo;Content-type: application/octet-stream\u0026amp;rdquo;;\n 3.OPEN TSDB 协议写入支持 请求demo\ncurl -X POST \\ http://localhost:7200/opentsdb/api/put \\ -H \u0026#39;Content-Type: application/json\u0026#39; \\ -H \u0026#39;step: 10000\u0026#39; \\ -H \u0026#39;app: xx\u0026#39; \\ -H \u0026#39;X-Lookout-Token: xx\u0026#39; \\ -d \u0026#39;[{ \u0026amp;quot;metric\u0026amp;quot;: \u0026amp;quot;xzc.cpu\u0026amp;quot;, \u0026amp;quot;timestamp\u0026amp;quot;: 1530624430, \u0026amp;quot;value\u0026amp;quot;: 30, \u0026amp;quot;tags\u0026amp;quot;: { \u0026amp;quot;host\u0026amp;quot;: \u0026amp;quot;web02\u0026amp;quot;, \u0026amp;quot;dc\u0026amp;quot;: \u0026amp;quot;lga\u0026amp;quot; } }]\u0026#39; 注意timestamp的单位是秒(而且尽量是当前时间附近哦，否则不太好查询)\n post的内容可以是一个json对象或json数组(批量模式)\n 更多细节可以参考 OpenTSDB的 /api/put 接口 http://opentsdb.net/docs/build/html/api_http/put.html\n 4.Metricbeat 写入协议支持 （1）.metricbeat的配置 配置文件 metricbeat.yml\noutput.elasticsearch: hosts: [\u0026#39;10.15.232.67:7200\u0026#39;] path: /beat host 是 lookout-gateway 的地址,端口是7200. 另外加了级主路径/beat;\n(2).为了符合metrics2.0标准，gateway会对数据进行转换 这块后续去时序库查询，你需要关注：\n FROM:\n{ \u0026amp;quot;@timestamp\u0026amp;quot;: \u0026amp;quot;2018-03-29T08:27:21.200Z\u0026amp;quot;, …","date":-62135596800,"description":"","dir":"projects/sofa-lookout/use-guide-other-metrics-protocol-support/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"df745d82f3f681cfd94b8187934a8477","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","summary":"使用 Lookout sdk是推荐方式，当然 Lookout gateway 还支持其他协议上报。（但由于属于非标接入，细节可联系我们） 注意如果使用 非lookout sdk ，自己一定注意控制客","tags":null,"title":"服务器端常见数据采集协议支持","type":"projects","url":"/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/","wordcount":1013},{"author":null,"categories":null,"content":" SOFADashboard 服务治理主要是对 SOFARpc 的服务进行管理。 目前已经支持基于 ZK 和 SofaRegistry 两个注册中心。\n功能展示 1、基于服务维度 服务列表 服务提供者详情： 2、基于应用维度 应用列表 应用服务详情 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/governance/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"e547baf489fd5d125be9e67a366854b6","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/governance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/governance/","summary":"SOFADashboard 服务治理主要是对 SOFARpc 的服务进行管理。 目前已经支持基于 ZK 和 SofaRegistry 两个注册中心。 功能展示 1、基于服务维度 服务列表 服务提供者详情： 2、基于应用维度 应用","tags":null,"title":"服务治理","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/governance/","wordcount":78},{"author":null,"categories":null,"content":" 本地开发 在本地启动 SOFARegistry 是使用的H2 database 作为注册中心使用的配置数据库, 可以直接启动\ncom.alipay.sofa.registry.server.integration.RegistryApplication#main\n默认会使用 application-dev.properties 作为配置文件\n部署模式 SOFARegistry 部署依赖 mysql, 使用 mysql 作为注册中心自身的元数据存储。\n支持两种部署模式，分别是集成部署模式及独立部署模式，本文将介绍最简单的单节点集成部署模式，更多更详细的部署模式介绍可以查看 部署文档。\n部署步骤 1.下载源码或者安装包 下载源码方式 git clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Pserver-release -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all 下载安装包方式 您可以从 release 页面 下载最新的 registry-all.tgz 包 。\n建议下载 v6 以上版本\ntar -zxvf registry-all.tgz cd registry-all 2.启动 registry-integration 2.1 如果是本地启动开发注册中心, 可以使用 h2 作为数据库\nIDEA 源码启动: 运行 com.alipay.sofa.registry.server.integration.RegistryApplication#main\nfat jar 脚本启动命令: sh bin/integration/start_dev.sh\n2.2 正式环境建议使用 mysql\n创建 database 和 table\necho \u0026amp;quot;create database registrymetadb \u0026amp;quot; | mysql -u username -p mysql -u username -p registrymetadb \u0026amp;lt; create_table.sql 修改 conf/application.properties 中的配置，数据库密码也可以通过 JDBC_PASSWORD 环境变量传入\n启动命令: sh bin/integration/start.sh\n3.确认运行状态 可访问三个角色提供的健康监测 API，或查看日志 logs/registry-startup.log：\n# 查看meta角色的健康检测接口： $ curl http://localhost:9615/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} # 查看data角色的健康检测接口： $ curl http://localhost:9622/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;... status:WORKING\u0026amp;quot;} # 查看session角色的健康检测接口： $ curl http://localhost:9603/health/check {\u0026amp;quot;success\u0026amp;quot;:true,\u0026amp;quot;message\u0026amp;quot;:\u0026amp;quot;...\u0026amp;quot;} ","date":-62135596800,"description":"","dir":"projects/sofa-registry/server-quick-start/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b620900b56ba04f4668838846a97698a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/server-quick-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/server-quick-start/","summary":"本地开发 在本地启动 SOFARegistry 是使用的H2 database 作为注册中心使用的配置数据库, 可以直接启动 com.alipay.sofa.registry.server.integration.RegistryApplication#main 默认会使用 application-dev.properties 作为配置文件 部署模式 SOFARegistry 部署依赖 mysql, 使用 mysql 作为注册中心","tags":null,"title":"服务端部署","type":"projects","url":"/sofastack.tech/projects/sofa-registry/server-quick-start/","wordcount":460},{"author":null,"categories":null,"content":" 如图: Node Raft 分组中的一个节点，连接封装底层的所有服务，用户看到的主要服务接口，特别是 apply(task) 用于向 raft group 组成的复制状态机集群提交新任务应用到业务状态机。\n存储 Log 存储，记录 raft 配置变更和用户提交任务的日志，将从 Leader 复制到其他节点上。LogStorage 是存储实现， LogManager 负责对底层存储的调用，对调用做缓存、批量提交、必要的检查和优化。 Meta 存储，元信息存储,记录 raft 实现的内部状态，比如当前 term,、投票给哪个节点等信息。 Snapshot 存储,，用于存放用户的状态机 snapshot 及元信息，可选。 SnapshotStorage 用于 snapshot 存储实现， SnapshotExecutor 用于 snapshot 实际存储、远程安装、复制的管理。 状态机 StateMachine： 用户核心逻辑的实现,核心是 onApply(Iterator) 方法，应用通过 Node#apply(task) 提交的日志到业务状态机。 FSMCaller： 封装对业务 StateMachine 的状态转换的调用以及日志的写入等，一个有限状态机的实现，做必要的检查、请求合并提交和并发处理等。 复制 Replicator： 用于 leader 向 follower 复制日志，也就是 raft 中的 appendEntries 调用，包括心跳存活检查等。 ReplicatorGroup: 用于单个 RAFT Group 管理所有的 replicator，必要的权限检查和派发。 RPC RPC 模块用于节点之间的网络通讯: 1. RPC Server: 内置于 Node 内的 RPC 服务器，接收其他节点或者客户端发过来的请求，转交给对应服务处理。 2. RPC Client: 用于向其他节点发起请求，例如投票、复制日志、心跳等。\n","date":-62135596800,"description":"","dir":"projects/sofa-jraft/engine-architecture/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d2cc9de133aed20695229d0cde5b6ff9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/engine-architecture/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-jraft/engine-architecture/","summary":"如图: Node Raft 分组中的一个节点，连接封装底层的所有服务，用户看到的主要服务接口，特别是 apply(task) 用于向 raft group 组成的复制状态机集群提交新任务应用到业务状态机","tags":null,"title":"核心引擎设计","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/engine-architecture/","wordcount":529},{"author":null,"categories":null,"content":" MOSN 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 xDS 等云原生能力。\nxDS（UDPA）支持 MOSN 支持云原生统一数据面 API（UDPA），支持全动态配置更新。\nxDS 是 Envoy 创建的一个关键概念，它是一类发现服务的统称，其包括如下几类：\n CDS：Cluster Discovery Service EDS：Endpoint Discovery Service SDS：Secret Discovery Service RDS：Route Discovery Service LDS：Listener Discovery Service 正是通过对 xDS 的请求来动态更新 Envoy 配置，另外还有个 ADS（Aggregated Discovery Service）通过聚合的方式解决以上 xDS 的更新顺序问题。\n业务支持 MOSN 作为底层的高性能安全网络代理，支撑了 RPC、消息（Messaging）、网关（Gateway）等业务场景。\nIO 模型 MOSN 支持以下两种 IO 模型：\n Golang 经典 netpoll 模型：goroutine-per-connection，适用于在连接数不是瓶颈的情况。\n RawEpoll 模型：也就是 Reactor 模式，I/O 多路复用（I/O multiplexing）+ 非阻塞 I/O（non-blocking I/O）的模式。对于接入层和网关有大量长链接的场景，更加适合于 RawEpoll 模型。\n netpoll 模型 MOSN 的 netpoll 模型如上图所示，协程数量与链接数量成正比，大量链接场景下，协程数量过多，存在以下开销：\n Stack 内存开销 Read buffer 开销 Runtime 调度开销 RawEpoll 模型 RawEpoll 模型如上图所示，使用 epoll 感知到可读事件之后，再从协程池中为其分配协程进行处理，步骤如下：\n 链接建立后，向 Epoll 注册 oneshot 可读事件监听；并且此时不允许有协程调用 conn.read，避免与 runtime netpoll 冲突。 可读事件到达，从 goroutine pool 挑选一个协程进行读事件处理；由于使用的是 oneshot 模式，该 fd 后续可读事件不会再触发。 请求处理过程中，协程调度与经典 netpoll 模式一致。 请求处理完成，将协程归还给协程池；同时将 fd 重现添加到 RawEpoll 中。 协程模型 MOSN 的协程模型如下图所示。\n 一条 TCP 连接对应一个 Read 协程，执行收包、协议解析； 一个请求对应一个 worker 协程，执行业务处理，proxy 和 Write 逻辑； 常规模型一个 TCP 连接将有 Read/Write 两个协程，我们取消了单独的 Write 协程，让 workerpool 工作协程代替，减少了调度延迟和内存占用。\n能力扩展 协议扩展 MOSN 通过使用统一的编解码引擎以及编/解码器核心接口，提供协议的 plugin 机制，包括支持：\n SOFARPC HTTP1.x/HTTP2.0 Dubbo NetworkFilter 扩展 MOSN 通过提供 network filter 注册机制以及统一的 packet read/write filter 接口，实现了 Network filter 扩展机制，当前支持：\n TCP proxy Fault injection StreamFilter 扩展 MOSN 通过提供 stream filter 注册机制以及统一的 stream send/receive filter 接口，实现了 Stream filter 扩展机制，包括支持：\n 流量镜像 RBAC 鉴权 TLS 安全链路 通过测试，原生的 Go 的 TLS 经过了大量的汇编优化，在性能上是 Nginx（OpenSSL）的80%，Boring 版本的 Go（使用 cgo 调用 BoringSSL）因为 cgo 的性能问题， 并不占优势，所以我们最后选择使用原生 Go 的 TLS，相信 Go Runtime 团队后续会有更多的优化，我们也会有一些优化计划。\nGo vs Nginx 测试结果如下图所示：\n Go 在 RSA 上没有太多优化，go-boring（CGO）的能力是 Go 的两倍。 p256 在 Go 上有汇编优化，ECDSA 优于go-boring。 在 AES-GCM 对称加密上，Go 的能力是 go-boring 的 20 倍。 在 SHA、MD 等 HASH 算法也有对应的汇编优化。 为了满足金融场景的安全合规，我们同时也对国产密码进行了开发支持，这个是 Go Runtime 所没有的。虽然目前的性能相比国际标准 AES-GCM 还是有一些差距，大概是 50%，但是我们已经有了后续的一些优化计划，敬请期待。\n支持国密的性能测试结果如下图所示：\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/core-concept/","fuzzywordcount":1400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5fd84bf5ceb2a4ab800cd0e2db774731","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/core-concept/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/concept/core-concept/","summary":"MOSN 主要划分为如下模块，包括了网络代理具备的基础能力，也包含了 xDS 等云原生能力。 xDS（UDPA）支持 MOSN 支持云原生统一数据面 API（UDPA），","tags":null,"title":"核心概念","type":"projects","url":"/sofastack.tech/projects/mosn/concept/core-concept/","wordcount":1332},{"author":null,"categories":null,"content":" 框架准备 在阅读前，您可以参考快速开始下载并安装 ACTS IDE 和引入 ACTS 框架.\n本部分主要包含编码说明、数据源配置和一键配置说明，以帮助您使用 ACTS 框架。\n编码说明 请确保 ACTS 的编码与系统代码的编码一致，即确定以下的编码保持一致：生成脚本选择的编码、workspace 的编码应该都与应用代码编码保持一致，不一致时会出现乱码问题。\n生成脚本选择的编码，如下图设置：\nIDEA workspace 的编码：\n数据源配置 ACTS 配置数据源的目的，是为了在数据准备、数据清理、数据校验阶段，能够使用系统的数据源正确的进行 DB 增删改查。\n数据源配置 在 src/test/resource/config/acts-config.properties 中配置 dal 层的 ModuleName、数据源以及表的对应关系，以 ds_ 开头，如下：\ndatasource_bundle_name =com.alipay.testapp.common.dal ds_bean1=table1,table2 ds_bean2=table3,table4 #配置格式 #ds_数据源bean=逻辑表名1,逻辑表名2 其中数据源 bean1、数据源 bean2 是应用代码中 dal 层的数据源 bean 的名称，支持多个数据源。表名支持正则表达式，无需带分库分表后缀，若有多个数据源时请注意，某张表只能属于一个数据源，如下图：\n数据库直连 数据库直连，用于 DB 数据模型的生成。在 src/test/resource/config/dbConf/ 下的 devdb.conf 或 testdb.conf 中配置如下：\nxxx_url = jdbc:oracle:thin:@localhost:1521:cifdb xxx_username = myname xxx_password = mypswd 一键配置的说明 一键配置测试框架主要生成包含两部分，一部分是基础 Java 类，另一类是必须的配置文件，具体生成内容如下：\nJava 类 AppNameActsBaseUtils.java\n测试脚本编写过程中常用的从框架中获取各种数据的工具类，初始化搭建只提供了常用的方法，可自行添加。\n AppNameActsTestBase.java\n封装后的应用测试基类，业务系统如有特殊需求可在其上自行封装，如果没有则可以忽略此文件。\n 配置文件 ","date":-62135596800,"description":"","dir":"projects/sofa-acts/usage-ready/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c3a89cbf42d55c98206a08e94d05ffde","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-ready/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-acts/usage-ready/","summary":"框架准备 在阅读前，您可以参考快速开始下载并安装 ACTS IDE 和引入 ACTS 框架. 本部分主要包含编码说明、数据源配置和一键配置说明，以帮助您使用 ACTS 框架。 编码说","tags":null,"title":"框架准备","type":"projects","url":"/sofastack.tech/projects/sofa-acts/usage-ready/","wordcount":593},{"author":null,"categories":null,"content":" SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力。为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式：\n 基于代码组织上的模块化：这是最常见的形式，在开发期，将不同功能的代码放在不同 Java 工程下，在编译期被打进不同 jar 包，在运行期，所有 Java 类都在一个 classpath 下，没做任何隔离； 基于 Spring 上下文隔离的模块化：借用 Spring 上下文来做不同功能模块的隔离，在开发期和编译期，代码和配置也会分在不同 Java 工程中，但在运行期，不同模块间的 Spring Bean 相互不可见，DI 只在同一个上下文内部发生，但是所有的 Java 类还是在同一个 ClassLoader 下； 基于 ClassLoader 隔离的模块化：借用 ClassLoader 来做隔离，每个模块都有独立的 ClassLoader，模块与模块之间的 classpath 不同，SOFAArk 就是这种模块化的实践方式。 SOFABoot 模块化开发属于第二种模块化形式 —— 基于 Spring 上下文隔离的模块化。每个 SOFABoot 模块使用独立的 Spring 上下文，避免不同 SOFABoot 模块间的 BeanId 冲突，有效降低企业级多模块开发时团队间的沟通成本。\n关于 SOFABoot 模块化产生的背景，可参考文章《蚂蚁金服的业务系统模块化 \u0026amp;mdash;- 模块化隔离方案》\n功能简介 依赖引入 使用 SOFABoot 模块化开发方案，需要引入如下依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;isle-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; SOFABoot 模块 SOFABoot 框架定义了 SOFABoot 模块的概念，一个 SOFABoot 模块是一个包括 Java 代码、Spring 配置文件、SOFABoot 模块标识等信息的普通 Jar 包，一个 SOFABoot 应用可以包含多个 SOFABoot 模块，每个 SOFABoot 模块都含有独立的 Spring 上下文。\n以 SOFABoot 模块为单元的模块化方式为开发者提供了以下功能：\n 运行时，每个 SOFABoot 模块的 Spring 上下文是隔离的，模块间定义的 Bean 不会相互影响； 每个 SOFABoot 模块是功能完备且自包含的，可以很容易在不同的 SOFABoot 应用中进行模块迁移和复用，只需将 SOFABoot 模块整个拷贝过去，调整 Maven 依赖，即可运行。 SOFABoot 模块的格式定义见: 模块配置。\nSOFABoot 模块间通信 上下文隔离后，模块与模块间的 Bean 无法直接注入，模块间需要通过 SOFA 服务进行通信，目前SOFABoot 提供了两种形式的服务发布和引用，用于解决不同级别的模块间调用的问题：\n JVM 服务发布和引用：解决一个 SOFABoot 应用内部各个 SOFABoot 模块之间的调用问题， JVM 服务发布与引用 RPC 服务发布和引用：解决多个 SOFABoot 应用之间的远程调用问题，RPC 服务发布与引用。 模块并行化启动 每个 SOFABoot 模块都是独立的 Spring 上下文，多个 SOFABoot 模块支持并行化启动，与 Spring Boot 的单 Spring 上下文模式相比，模块并行化启动能够加快应用的启动速度。\nRoot Application Context SOFABoot 应用运行时，本身会产生一个 Spring Context，我们把它叫做 Root Application Context，它是每个 SOFABoot 模块创建的 Spring Context 的 Parent。这样设计的目的是为了保证每个 SOFABoot 模块的 Spring Context 都能发现 Root Application Context 中创建的 Bean，这样当应用新增 Starter 时，不仅 Root Application Context 能够使用 Starter 中新增的 Bean，每个 SOFABoot 模块的 Spring Context 也能使用这些 Bean。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/modular-development/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"95bc080787c3614bfa485d2f3cd0de4c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/modular-development/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/modular-development/","summary":"SOFABoot 从 2.4.0 版本开始支持基于 Spring 上下文隔离的模块化开发能力。为了更好的理解 SOFABoot 模块化开发的概念，我们来区分几个常见的模块化形式： 基于代码组织上的模块化","tags":null,"title":"模块化开发概述","type":"projects","url":"/sofastack.tech/projects/sofa-boot/modular-development/","wordcount":1073},{"author":null,"categories":null,"content":"SOFABoot 会根据 Require-Module 计算模块依赖树，例如以下依赖树表示模块B 和模块C 依赖模块A，模块E 依赖模块D，模块F 依赖模块E：\n该依赖树会保证模块A 必定在模块B 和模块C 之前启动，模块D 在模块E 之前启动，模块E 在模块F 之前启动，但是依赖树没有定义模块B 与模块C，模块B、C与模块D、E、F之间的启动顺序，这几个模块之间可以串行启动，也可以并行启动。\nSOFABoot 默认会并行启动模块，在使用过程中，如果希望关闭并行启动，可以在 application.properties 中增加以下参数:\ncom.alipay.sofa.boot.module-start-up-parallel=false ","date":-62135596800,"description":"","dir":"projects/sofa-boot/parallel-start/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a6ef51b78d2a4f9af0debbc25ea45e8a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/parallel-start/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/parallel-start/","summary":"SOFABoot 会根据 Require-Module 计算模块依赖树，例如以下依赖树表示模块B 和模块C 依赖模块A，模块E 依赖模块D，模块F 依赖模块E： 该依赖树会保证模块A 必定在模块B 和","tags":null,"title":"模块并行化启动","type":"projects","url":"/sofastack.tech/projects/sofa-boot/parallel-start/","wordcount":204},{"author":null,"categories":null,"content":" SOFABoot 模块是一个普通的 Jar 包加上一些 SOFABoot 特有的配置，这些 SOFABoot 特有的配置，让一个 Jar 包能够被 SOFABoot 识别，使之具备模块化的能力。\n一个完整的 SOFABoot 模块和一个普通的 Jar 包有两点区别:\n SOFABoot 模块包含一份 sofa-module.properties 文件，这份文件里面定义了 SOFABoot 模块的名称以及模块之间的依赖关系。 SOFABoot 模块的 META-INF/spring 目录下，可以放置任意多的 Spring 配置文件，SOFABoot 会自动把它们作为本模块的 Spring 配置加载起来。 sofa-module.properties 文件详解 先来看一份完整的 sofa-module.properties 文件（src/main/resources 目录下）：\nModule-Name=com.alipay.test.biz.service.impl Spring-Parent=com.alipay.test.common.dal Require-Module=com.alipay.test.biz.shared Module-Profile=dev Module-Name Module-Name 是 SOFABoot 模块的名称，也是 SOFABoot 模块的唯一标示符。在一个 SOFABoot 应用中，一个 SOFABoot 模块的 Module-Name 必须和其他的 SOFABoot 模块的 Module-Name 不一样。需要注意的一点是，一个 SOFABoot 应用运行时的 SOFABoot 模块，不仅仅只包含本应用的模块，还包括依赖了其他应用的 SOFABoot 模块，确定是否唯一的时候需要把这些 SOFABoot 模块也考虑进去。\nRequire-Module Require-Module 用于定义模块之间的依赖顺序，值是以逗号分隔的 SOFABoot 模块名列表，比如上面的配置中，就表示本模块依赖于 com.alipay.test.biz.shared 模块。对于这种依赖关系的处理，SOFABoot 会将 com.alipay.test.biz.shared 模块在本模块之前启动，即com.alipay.test.biz.shared 模块将先启动 Spring 上下文。\n一般情况下，是不需要为模块定义 Require-Module 的，只有当模块的 Spring 上下文的启动依赖于另一个模块的 Spring 上下文的启动时，才需要定义 Require-Module。举一个例子，如果你在 A 模块中发布了一个 SOFA JVM Service。在 B 模块的某一个 Bean 的 init 方法里面，需要使用 SOFA Reference 调用这个 JVM Service。假设 B 模块在 A 模块之前启动了，那么 B 模块的 Bean 就会因为 A 模块的 JVM Service 没有发布而 init 失败，导致 Spring 上下文启动失败。这个时候，我们就可以使用 Require-Module 来强制 A 模块在 B 模块之前启动。\nSpring-Parent 在 SOFABoot 应用中，每一个 SOFABoot 模块都是一个独立的 Spring 上下文，并且这些 Spring 上下文之间是相互隔离的。虽然这样的模块化方式可以带来诸多好处，但是，在某些场景下还是会有一些不便，这个时候，你可以通过 Spring-Parent 来打通两个 SOFABoot 模块的 Spring 上下文。Spring-Parent 属性可以配置一个模块的名称，比如上面的配置中，就将 com.alipay.test.common.dal 的 Spring 上下文设置为当前模块的 Spring 上下文的父 Spring 上下文。\n由于 Spring 的限制，一个模块的 Spring-Parent 只能有一个模块\n关于 Spring 的父上下文的作用可以看 Spring 的 BeanFactory 的说明：http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/beans/factory/BeanFactory.html\nModule-Profile 支持 SOFABoot Profile 能力： SOFABoot Profile\nSpring 配置文件 SOFABoot 模块可以包含 Spring 配置文件，配置文件需要放置在 META-INF/spring 目录下，SOFABoot 启动时会自动扫描该目录，并把目录下所有 XML 文件作为本模块的 Spring 配置加载起来。在 Spring 配置文件中，我们可以定义 Bean、发布服务等等。\nSOFABoot 模块一般用于封装对外发布服务接口的具体实现，属于业务层，Controller 属于展现层内容，我们不建议也不支持在 SOFABoot 模块中定义 Controller 组件，Controller 组件相关定义请直接放在 Root Application Context。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofaboot-module/","fuzzywordcount":1200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2dbb8a536237f21afbee1e3f320b8193","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-module/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofaboot-module/","summary":"SOFABoot 模块是一个普通的 Jar 包加上一些 SOFABoot 特有的配置，这些 SOFABoot 特有的配置，让一个 Jar 包能够被 SOFABoot 识别，使之具备模块化的能力。 一个完整的 SOFABoot 模块和一个普通的 Jar 包","tags":null,"title":"模块配置","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofaboot-module/","wordcount":1194},{"author":null,"categories":null,"content":"如果你要扩展一个注册中心，我们先看下注册中心的抽象类。\npackage com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026amp;lt;ProviderConfig\u0026amp;gt; configs); public abstract List\u0026amp;lt;ProviderGroup\u0026amp;gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public abstract void batchUnSubscribe(List\u0026amp;lt;ConsumerConfig\u0026amp;gt; configs); } 可以看到我们需要的主要接口。\n 启动注册中心客户端、维持连接 销毁注册中心客户端、释放资源 发布服务、缓存发布信息 取消发布服务、删除缓存 订阅服务列表、同步或者异步返回数据，有变化接收通知 取消订阅服务列表、删除缓存 其它\n 注册中心节点断连后，不影响本地调用 和一个注册中心节点断连后，可自己切换到其它注册中心节点 注册中心节点切换后，自动恢复注册和订阅信息 注册中心数据缓存到本地文件，就算连不上任何注册中心，服务提供者和服务调用者也能重启并正常调用 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-extension-guide/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c952ecbea16f7ae68ad095ab8baf0583","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","summary":"如果你要扩展一个注册中心，我们先看下注册中心的抽象类。 package com.alipay.sofa.rpc.registry; @Extensible(singleton = false) public abstract class Registry implements Initializable, Destroyable { public abstract boolean start(); public abstract void register(ProviderConfig config); public abstract void unRegister(ProviderConfig config); public abstract void batchUnRegister(List\u0026lt;ProviderConfig\u0026gt; configs); public abstract List\u0026lt;ProviderGroup\u0026gt; subscribe(ConsumerConfig config); public abstract void unSubscribe(ConsumerConfig config); public","tags":null,"title":"注册中心扩展指南","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-extension-guide/","wordcount":290},{"author":null,"categories":null,"content":"SOFABoot RPC Starter 为用户提供多种注册中心选择和方便的配置。 目前 bolt ， rest ， dubbo 都支持 Zookeeper 作为注册中心。另外 bolt ， rest 支持本地文件系统作为注册中心，该种模式一般用于测试。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/registry-usage/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5a1a4619c8ac4a9fc27b8576472aed9f","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/registry-usage/","summary":"SOFABoot RPC Starter 为用户提供多种注册中心选择和方便的配置。 目前 bolt ， rest ， dubbo 都支持 Zookeeper 作为注册中心。另外 bolt ， rest 支持本地文件系统作为注册中心，该种模式一般用于测","tags":null,"title":"注册中心选择","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/registry-usage/","wordcount":72},{"author":null,"categories":null,"content":" 本文描述的是 MOSN 作为 Sidecar 使用时的流量劫持方案。\nMOSN 作为 Sidecar 和业务容器部署在同一个 Pod 中时，需要使得业务应用的 Inbound 和 Outbound 服务请求都能够经过 Sidecar 处理。区别于 Istio 社区使用 iptables 做流量透明劫持，MOSN 目前使用的是流量接管方案，并在积极探索适用于大规模流量下的透明劫持方案。\n流量接管 区别于 Istio 社区的 iptables 流量劫持方案，MOSN 使用的流量接管的方案如下：\n 假设服务端运行在 1.2.3.4 这台机器上，监听 20880 端口，首先服务端会向自己的 Sidecar 发起服务注册请求，告知 Sidecar 需要注册的服务以及 IP + 端口（1.2.3.4:20880） 服务端的 Sidecar 会向服务注册中心（如 SOFA Registry）发起服务注册请求，告知需要注册的服务以及 IP + 端口，不过这里需要注意的是注册上去的并不是业务应用的端口（20880），而是 Sidecar 自己监听的一个端口（例如：20881） 调用端向自己的 Sidecar 发起服务订阅请求，告知需要订阅的服务信息 调用端的 Sidecar 向调用端推送服务地址，这里需要注意的是推送的 IP 是本机，端口是调用端的 Sidecar 监听的端口（例如 20882） 调用端的 Sidecar 会向服务注册中心（如 SOFA Registry）发起服务订阅请求，告知需要订阅的服务信息； 服务注册中心（如 SOFA Registry）向调用端的 Sidecar 推送服务地址（1.2.3.4:20881） 服务调用过程 经过上述的服务发现过程，流量转发过程就显得非常自然了：\n 调用端拿到的服务端地址是 127.0.0.1:20882，所以就会向这个地址发起服务调用 调用端的 Sidecar 接收到请求后，通过解析请求头，可以得知具体要调用的服务信息，然后获取之前从服务注册中心返回的地址后就可以发起真实的调用（1.2.3.4:20881） 服务端的 Sidecar 接收到请求后，经过一系列处理，最终会把请求发送给服务端（127.0.0.1:20880） 透明劫持 上文通过在服务注册过程中把服务端地址替换成本机监听端口实现了轻量级的“流量劫持”，在存在注册中心，且调用端和服务端同时使用特定SDK的场景中可以很好的工作，如果不满足这两个条件，则无法流量劫持。为了降低对于应用程序的要求，需要引入透明劫持。\n使用 iptables 做流量劫持 iptables 通过 NAT 表的 redirect 动作执行流量重定向，通过 syn 包触发新建 nefilter 层的连接，后续报文到来时查找连接转换目的地址与端口。新建连接时同时会记录下原始目的地址，应用程序可以通过(SOL_IP、SO_ORIGINAL_DST)获取到真实的目的地址。\niptables 劫持原理如下图所示：\n使用 iptables 做流量劫持时存在的问题 目前 Istio 使用 iptables 实现透明劫持，主要存在以下三个问题： 1. 需要借助于 conntrack 模块实现连接跟踪，在连接数较多的情况下，会造成较大的消耗，同时可能会造成 track 表满的情况，为了避免这个问题，业内有关闭 conntrack 的做法，比如阿里巴巴就关闭了这个模块。 1. iptables 属于常用模块，全局生效，不能显式的禁止相关联的修改，可管控性比较差。 1. iptables 重定向流量本质上是通过 loopback 交换数据，outbond 流量将两次穿越协议栈，在大并发场景下会损失转发性能。\n上述几个问题并非在所有场景中都存在，比方说某些场景下，连接数并不多，且 NAT 表未被使用到的情况下，iptables 是一个满足要求的简单方案。为了适配更加广泛的场景，透明劫持需要解决上述三个问题。\n透明劫持方案优化 使用 tproxy 处理 inbound 流量\ntproxy 可以用于 inbound 流量的重定向，且无需改变报文中的目的 IP/端口，不需要执行连接跟踪，不会出现 conntrack 模块创建大量连接的问题。受限于内核版本，tproxy 应用于 outbound 存在一定缺陷。目前 Istio 支持通过 tproxy 处理 inbound 流量。\n使用 hook connect 处理 outbound 流量\n为了适配更多应用场景，outbound 方向通过 hook connect 来实现，实现原理如下：\n无论采用哪种透明劫持方案，均需要解决获取真实目的 IP/端口的问题，使用 iptables 方案通过 getsockopt 方式获取，tproxy 可以直接读取目的地址，通过修改调用接口，hook connect 方案读取方式类似于tproxy。\n实现透明劫持后，在内核版本满足要求（4.16以上）的前提下，通过 sockmap 可以缩短报文穿越路径，进而改善 outbound 方向的转发性能。\n总结 总结来看，如果应用程序通过注册中心发布/订阅服务时，可以结合注册中心劫持流量；在需要用到透明劫持的场景，如果性能压力不大，使用 iptables redirect 即可，大并发压力下使用 tproxy 与hook connect 结合的方案。\n","date":-62135596800,"description":"","dir":"projects/mosn/concept/traffic-hijack/","fuzzywordcount":1700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5845d8478a48fcddc74f0b9d28ede2c2","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/concept/traffic-hijack/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/mosn/concept/traffic-hijack/","summary":"本文描述的是 MOSN 作为 Sidecar 使用时的流量劫持方案。 MOSN 作为 Sidecar 和业务容器部署在同一个 Pod 中时，需要使得业务应用的 Inbound 和 Outbound 服务请求都能够经过 Sidecar 处理。区别于 Istio 社","tags":null,"title":"流量劫持","type":"projects","url":"/sofastack.tech/projects/mosn/concept/traffic-hijack/","wordcount":1671},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.1.2。\n参见: http://semver.org/lang/zh-CN/。\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 5.3.0，那么将会维护 5.2.x 的 bugfix 分支，而 5.1.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 5.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 5.3.0。 发布后拉起下一个版本，例如 5.3.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/version-release/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"604f113607e6815757f4d1907190c13c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/version-release/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/version-release/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.1.2。 参见: http://semver.org/lang/zh-CN/","tags":null,"title":"版本发布","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/version-release/","wordcount":315},{"author":null,"categories":null,"content":" 1.3.2 2020-06-19\n Bug Fixes 移除对 bolt address parser 的扩展，避免 check connection 返回结果不符合预期 SPI 组件 JRaftServiceLoader 改为延迟加载策略规避多余对象的创建 几个 corner case 修复，比如 replicate logs 如果比 appliedIndex（follower）更小，那么可以认为是成功的 关闭 Recyclers 时的 IndexOutOfBoundsException 问题修复 Features 抽象出网络通信层，增加 GRPC 实现并支持 Replication Pipeline，用户亦可自行对通信层进行其他实现的扩展 RheaKV 增加 reverseScan API 提供 Replicator 与 RPC 的线程池隔离，避免相互影响 read-index 线性一致读请求提供请求超时（timeout）配置 Breaking Changes 无 致谢（排名不分先后） @shibd @SteNicholas @killme2008 @zongtanghu 1.3.1 2020-04-17\n Bug Fixes 修复 bolt rpc callback 默认的任务饱和丢弃策略，改为抛出异常 修复 learner 启动晚于 leader 选举成功时无法复制日志的 bug Features multi raft group 之间共享 timer 和 scheduler 等较重的线程资源，优化 multi group 场景中的多余资源占用 提供 RPC adapter，用户可基于 SPI 扩展不同的 RPC 实现 正式提供稳定的 RocksDBSegmentLogStorage，适合 value 较大的数据存储 sofa-bolt 升级到 1.6.1，支持 SSL 以及具有更好的小数据包传输能力 引入一个新的数据结构 segment list 来解决 LogManager 中过多的 log memory copy 采纳 nacos 的建议，对 raft Task 增加 join API Breaking Changes 无 致谢（排名不分先后） @jovany-wang @SteNicholas @zongtanghu @OpenOpened 1.3.0 2019-11-29\n Bug Fixes 删除数据并重启且期间没有新的 task 提交的情况下 prev log index 紊乱的修复 修复一些选举和线性一致读相关的 corner case Recyclers 多个线程 recycle 资源时的 NPE 修复 Features 新增 Read-only member(learner) 角色，支持 learner 节点上的线性一致读 实现优先级选举 在 multi raft group 的场景中，随机打散每个 group 的第一次 snapshot timeout 时间，避免一个进程内多个 group 同时 snapshot RheaKV 新增 containsKey API RheaKV 实现 snapshot checksum 以及异步 snapshot 新增 replicator 的 state 监听器： ReplicatorStateListener RepeatedTimer 的默认实现替换为 HashedWheelTimer 修复 windows 上定时器 CPU 消耗偏高的问题 kill -s SIGUSR2 pid 中增加打印 rocksdb stats 和所有 ThreadPool 指标统计信息 升级 rocksdb 版本到 5.18.3 新增实验性质的 RocksDBSegmentLogStorage，适合 value 较大的数据存储 Counter 例子改进，演示 ReadIndex 线性一致读 当优化 checksum 中多余的 mem copy Breaking Changes 无 致谢（排名不分先后） @zongtanghu @devYun @masaimu @SteNicholas @yetingsky 1.2.6 2019-08-15\n Bug Fixes 修复 ReadIndex 并发情况下可能出现的读超时 保存 raft meta 失败后终止状态机 修复 windows 环境中无法原子 move 文件的问题 当 RheaKV apply 失败时终止状态机避免出现数据不一致情况 Features 增加 LogEntry checksum validation 优化 log replication 线程模型减少锁竞争 优化 RheaKV multi group snapshot 对于 multi-raft-group 场景，提供 manual rebalance API 在无 PD 模式手动平衡各节点 leader 数量 CliService 提供获取存活 follower 节点的 API 引入 SPI 扩展机制，LogStorage、SnapshotStorage、RaftMetaStorage、LogEntryCodec 均可基于 SPI 扩展 Linux 平台 SIGUSR2 信号输出节点状态以及 metric 信息 RheaKV 增加 CompareAndPut 原子更新 API 新增 pooled buf allocator 解决 log replication 时大量分配 byte[] 频繁触发 fullgc 默认关闭 RheaKV rocksdb 的 fsync 和 WAL，依靠 raft log 和 snapshot 确保数据一致性 当 raft node 过载时拒绝新的请求 Breaking Changes 无 致谢（排名不分先后） @SteNicholas @zongtanghu 1.2.5 2019-04-01\n Bug Fixes 修复 jmh 与 unit test 代码冲突问题 修复 snapshot 过大引起的安装失败 bug，会影响新增节点的加入 Features LogManagerImpl 中耗费 cpu 部分的代码优化 修正一些单词拼写错误 Breaking Changes 无 此版本强烈推荐升级\n1.2.4 2019-03-20\n Bug Fixes 修复一种情况下 lease read 的 stale read 部分 timestamp 修改为 monotonic time 修复一种情况下 replicator 被 block 住的问题 解决 windows 平台下某些单测无法创建目录 解决 windows 平台下某些 rocksdb options 设置不当导致进程 crash Features 开放 RocksDB options 的设置给用户层 Pre-vote 优化，启用 lease 机制来规避网络分区+集群长时间无写入的情况下，游离节点回归后打断当前 term，提升系统可用性 升级 bolt …","date":-62135596800,"description":"","dir":"projects/sofa-jraft/release-log/","fuzzywordcount":2300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9e24fb74a3cda6a600252b01f8a85db9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/release-log/","publishdate":"0001-01-01T00:00:00Z","readingtime":5,"relpermalink":"/sofastack.tech/projects/sofa-jraft/release-log/","summary":"1.3.2 2020-06-19 Bug Fixes 移除对 bolt address parser 的扩展，避免 check connection 返回结果不符合预期 SPI 组件 JRaftServiceLoader 改为延迟加载策略规避多余对象的创建 几个 corner case 修复，比如 replicate logs 如果比 appliedI","tags":null,"title":"版本发行日志","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/release-log/","wordcount":2298},{"author":null,"categories":null,"content":" 通过 SOFABoot，我们可以直接在浏览器中就可以查看 SOFA 中间件的版本等详细信息。\n引入 SOFABoot Infra 依赖 要在 SOFABoot 中直接通过浏览器查看 SOFA 中间件的版本信息，只需要在 Maven 依赖中增加如下的内容即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.alipay.sofa\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;infra-sofa-boot-starter\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 版本信息查看 在应用启动成功后，可以在浏览器中输入 http://localhost:8080/sofaboot/versions 查看 SOFA 中间件的版本信息，如：\n[ { GroupId: \u0026amp;quot;com.alipay.sofa\u0026amp;quot;, Doc-Url: \u0026amp;quot;https://github.com/sofastack/sofa-boot\u0026amp;quot;, ArtifactId: \u0026amp;quot;infra-sofa-boot-starter\u0026amp;quot;, Built-Time: \u0026amp;quot;2018-04-05T20:55:22+0800\u0026amp;quot;, Commit-Time: \u0026amp;quot;2018-04-05T20:54:26+0800\u0026amp;quot;, Commit-Id: \u0026amp;quot;049bf890bb468aafe6a3e07b77df45c831076996\u0026amp;quot;, Version: \u0026amp;quot;2.4.0\u0026amp;quot; } ] 注: 在 SOFABoot 3.x 中调整了 endpoint 路径，sofaboot/versions 更改为 actuator/versions\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/view-versions/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c6b6d22e9038aa1f5e4ce74449ba1cda","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/view-versions/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/view-versions/","summary":"通过 SOFABoot，我们可以直接在浏览器中就可以查看 SOFA 中间件的版本等详细信息。 引入 SOFABoot Infra 依赖 要在 SOFABoot 中直接通过浏览器查看 SOFA 中间件的版本信息，只","tags":null,"title":"版本查看","type":"projects","url":"/sofastack.tech/projects/sofa-boot/view-versions/","wordcount":182},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 1.0.0。\n参见: http://semver.org/lang/zh-CN/\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 1.2.0，那么将会维护 1.1.x 的 bugfix 分支，而 1.0.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 1.0.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 1.0.0。 发布后拉起下一个版本，例如 1.0.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/version-rule/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a2093bdf478bdff0e15a2de70e522d03","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/version-rule/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/version-rule/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 1.0.0。 参见: http://semver.org/lang/zh-CN/ 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本","tags":null,"title":"版本规范","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/version-rule/","wordcount":286},{"author":null,"categories":null,"content":" 版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.2.0。\n参见: http://semver.org/lang/zh-CN/\n 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本号不一定完全兼容，尽量向下兼容。 次版本号：代表新特性增强。版本号越大特性越丰富。 修订版本号：代表BugFix版本。只做bug修复使用，版本号越大越稳定。 版本维护 最多同时维护两个版本。\n例如当前主干为 5.4.0，那么将会维护 5.3.x 的 bugfix 分支，而 5.2.x 遇到 bug 将不再修复，建议升级。\n发布流程 日常开发分支采用 SNAPSHOT 版本，例如 5.3.0-SNAPSHOT。 正式发布时修改版本为正式版本，例如 5.3.0。 发布后拉起下一个版本，例如 5.3.1-SNAPSHOT。 ","date":-62135596800,"description":"","dir":"projects/sofa-registry/release-standard/","fuzzywordcount":300,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"71aad9cbc42aba3d9f875ae9169cf005","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/release-standard/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/release-standard/","summary":"版本号 采用三位版本号，分别是主版本号、次版本号、修订版本号。例如 5.2.0。 参见: http://semver.org/lang/zh-CN/ 主版本号：主版本号内的所有版本必须相互兼容；与其它主版本","tags":null,"title":"版本规范","type":"projects","url":"/sofastack.tech/projects/sofa-registry/release-standard/","wordcount":286},{"author":null,"categories":null,"content":"SOFABoot 使用了一些三方开源组件，他们分别是：\n一些主要依赖：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License sofa-common-tools under Apache 2.0 license 一些扩展依赖：\n nuxeo under Apache License, Version 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-boot/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"11f073a7a9965ab5690ed166fe319bbd","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-boot/notice/","summary":"SOFABoot 使用了一些三方开源组件，他们分别是： 一些主要依赖： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License sofa-common-tools under Apache 2.0 license 一些扩展依赖： nuxeo under Apache License, Version 2.0 \u0026hellip; 其它整理中。","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-boot/notice/","wordcount":67},{"author":null,"categories":null,"content":" 依赖组件版权说明 SOFADashboard 使用了一些三方开源组件，他们分别是：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFA Bolt under Apache License 2.0 SOFA Bolt under Apache License 2.0 Curator under Apache License 2.0 \u0026amp;hellip; 其它整理中。\n","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a9ebe38d245302f94ab7bfa793329926","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/notice/","summary":"依赖组件版权说明 SOFADashboard 使用了一些三方开源组件，他们分别是： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license SLF4j under the MIT License SOFA Bolt under Apache License 2.0 SOFA Bolt under Apache License 2.0 Curator under Apache License 2.0 \u0026hellip; 其它整理中。","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/notice/","wordcount":67},{"author":null,"categories":null,"content":" 依赖组件版权说明 SOFARegistry 使用了一些三方开源组件，他们分别是：\n Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1  SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 \u0026amp;hellip; 其它整理中，如若发现遗漏，还请主动告知。\n","date":-62135596800,"description":"","dir":"projects/sofa-registry/notice/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"c40263ffd56a2f1292756c9fafea55e2","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/notice/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-registry/notice/","summary":"依赖组件版权说明 SOFARegistry 使用了一些三方开源组件，他们分别是： Spring under Apache 2.0 license Spring Boot under Apache 2.0 license Netty under Apache License 2.0 SLF4j under the MIT License jersey under CDDL Version 1.1 SOFAJRaft under Apache License 2.0 SOFABolt under Apache License 2.0 SOFAHessian under Apache License 2.0 \u0026hellip; 其","tags":null,"title":"版权声明","type":"projects","url":"/sofastack.tech/projects/sofa-registry/notice/","wordcount":89},{"author":null,"categories":null,"content":" RheaKV：基于 JRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库。 AntQ Streams QCoordinator： 使用 JRaft 在 coordinator 集群内做选举、元信息存储等功能。 SOFA 服务注册中心元信息管理模块：IP 数据信息注册，要求写数据达到各个节点一致，并且在不小于一半节点挂掉，保证不影响数据正常存储。 AntQ NameServer 选主 ","date":-62135596800,"description":"","dir":"projects/sofa-jraft/user-stories/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b233be7d9eed33645945293e637e28ea","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/user-stories/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-jraft/user-stories/","summary":"RheaKV：基于 JRaft 和 RocksDB 实现的嵌入式、分布式、高可用、强一致的 KV 存储类库。 AntQ Streams QCoordinator： 使用 JRaft 在 coordinator 集群内做选举、元信息存储等","tags":null,"title":"用户案例","type":"projects","url":"/sofastack.tech/projects/sofa-jraft/user-stories/","wordcount":140},{"author":null,"categories":null,"content":"SOFARPC 支持指定地址进行调用的场景。用 Java API 的使用方式如下，设置直连地址即可：\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumer = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026amp;quot;bolt://127.0.0.1:12201\u0026amp;quot;); 用 XML 的使用方式如下：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.alipay.sample.HelloService\u0026amp;quot; id=\u0026amp;quot;helloService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:route target-url=\u0026amp;quot;127.0.0.1:12200\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; 用 Annotation 的使用方式如下：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, directUrl = \u0026amp;quot;127.0.0.1:12220\u0026amp;quot;)) private SampleService sampleService; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/peer-to-peer/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b1815c322f5dc9528f6429d1d5e38369","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/peer-to-peer/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/peer-to-peer/","summary":"SOFARPC 支持指定地址进行调用的场景。用 Java API 的使用方式如下，设置直连地址即可： ConsumerConfig\u0026lt;HelloService\u0026gt; consumer = new ConsumerConfig\u0026lt;HelloService\u0026gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig) .setDirectUrl(\u0026quot;bolt://127.0.0.1:12201\u0026quot;); 用 XML 的使用方式如下： \u0026lt;sofa:reference interface=\u0026quot;com.alipay.sample.HelloService\u0026quot; id=\u0026quot;helloService\u0026quot;\u0026gt; \u0026lt;sofa:binding.bolt\u0026gt; \u0026lt;sofa:route target-url=\u0026quot;127.0.0.1:12200\u0026quot;/\u0026gt; \u0026lt;/sofa:binding.bolt\u0026gt; \u0026lt;/sofa:reference\u0026gt; 用 Annotation 的使用方式如下","tags":null,"title":"直连调用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/peer-to-peer/","wordcount":82},{"author":null,"categories":null,"content":" 类委托加载 注：这里委托加载不止包含类委托，还包含资源委托加载。\nSOFAArk 通过多 ClassLoader 的方式提供类隔离的能力，并在此基础上具备多版本隔离和热部署的能力。当然类如果纯粹隔离还不够，还需要考虑ClassLoader之间的类共享。SOFAArk 通过类委托机制，提供了一套丰富的委托加载能力。定义了PluginClassLoader 和 BizClassLoader，不同类型具备不同的类查找逻辑，同时提供ClassLoaderHook能力，允许自定义模块间的类委托加载。SOFAArk 框架本身的类委托加载是非常灵活的，但是在实际落地时，需要有一套类委托加载的最佳实践。\nSOFAArk 支持的场景主要分为两类： 1. 多Plugin的类隔离：考虑如何相同类不同版本不会相互冲突 2. 合并部署/热部署：原应用如何拆分，或多个应用如何合并\n这里我们主要考虑第2种，多 ClassLoader 如何布局，在内部探索出的最佳实践多 ClassLoader 布局为 模块里的类和资源查找优先从模块里查找列，查找不到从再基座里查找。\n最佳实践 类委托加载的准则是中间件相关的依赖需要放在同一个的 ClassLoader 里进行加载执行，达到这种方式的最佳实践有两种：\n强制委托加载 由于中间件相关的依赖一般需要在同一个ClassLoader里加载运行，所以可以制定一个中间件依赖的白名单，强制这些依赖委托给基座加载。SOFAArk 已经提供白名单能力，详细查看与 sofa.ark.plugin.export.class.enable 有关源码。\n强制加载优缺点 优点 模块开发者不需要感知哪些依赖属于需要强制加载由同一个 ClassLoader 加载的依赖\n 缺点 白名单里要强制加载的依赖列表需要维护，列表的缺失需要更新基座，较为重要的升级需要推所有的基座升级。\n自定义委托加载 模块里pom通过设置依赖的 scope 为 provided主动指定哪些要委托给基座加载。通过模块瘦身工具自动把与基座重复的依赖委托给基座加载，基座通过预置中间件的依赖（可选，虽然模块暂时不会用到，但可以提前引入，以备后续模块需要引入的时候不需再发布基座即可引入）\n1. 基座预置依赖 基座可以提前预置一些依赖\n2. 通过两种方式委托给基座加载 模块pom里依赖 scope 设置为 provided biz 打包插件sofa-ark-maven-plugin里设置 excludeGroupIds 或 excludeArtifactIds 3. 只有模块声明过的依赖才可以委托给基座加载 模块启动的时候，框架会有一些扫描逻辑，这些扫描如果不做限制会查找到模块和基座的所有类、资源，导致一些模块明明不需要的功能尝试去初始化，从而报错。SOFAArk 2.0.3之后新增了模块的 declaredMode, 来限制只有模块里声明过的依赖才可以委托给基座加载。只需在模块的 sofa-ark-maven-plugin 打包插件的 Configurations 里增加 true即可。\n自定义委托加载优缺点 优点 不需要维护强制加载列表，当部分需要由同一 ClassLoader 加载的依赖没有设置为统一加载时，可以修改模块就可以修复，不需要发布基座（除非基座确实依赖）。\n 缺点 对模块自动瘦身的依赖较强\n对比与总结 委托加载类型 依赖缺失排查成本 修复成本 模块改造成本 维护成本 强制加载 类转换失败或类查找失败，成本中 更新 plugin，发布基座，高 低 高 自定义委托加载 类转换失败或类查找失败，成本中 更新模块依赖，如果基座依赖不足，需要更新基座并发布，中 高 低 自定义委托加载 + 基座预置依赖 + 模块自动瘦身 类转换失败或类查找失败，成本中 更新模块依赖，设置为provided，低 低 低 推荐自定义委托加载方式 模块自定义委托加载 + 模块自动瘦身 模块开启 declaredMode 基座预置依赖 开启后的副作用 由于基座提前启动，模块再次启动的时候，如果依赖了基座的依赖里有发布服务，那么模块在启动的时候还会再次发布，如果该问题有一定影响可以模块pom里exclude掉对应的依赖。 ","date":-62135596800,"description":"","dir":"projects/sofa-boot/sofa-ark-class-loader-delegation/","fuzzywordcount":1500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d3ea2dc9104433356ad82b6a772a971a","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","summary":"类委托加载 注：这里委托加载不止包含类委托，还包含资源委托加载。 SOFAArk 通过多 ClassLoader 的方式提供类隔离的能力，并在此基础上具备多版本隔离和热部署的能力。当","tags":null,"title":"类委托加载","type":"projects","url":"/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/","wordcount":1428},{"author":null,"categories":null,"content":"介绍几种 SOFARPC 在不同环境下的使用方式 * 非 Spring 环境 API 使用 * SOFABoot 环境 XML 配置使用 * SOFABoot 环境注解使用 * SOFABoot 环境动态 API 使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programming/","fuzzywordcount":100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"9a947dae761c84aa4d95121c076ac552","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programming/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programming/","summary":"介绍几种 SOFARPC 在不同环境下的使用方式 * 非 Spring 环境 API 使用 * SOFABoot 环境 XML 配置使用 * SOFABoot 环境注解使用 * SOFABoot 环境动态 API 使用","tags":null,"title":"编程界面","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programming/","wordcount":50},{"author":null,"categories":null,"content":"自动故障剔除会自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复。目前支持 bolt 协议。\n在 SOFABoot 中，只需要配置自动故障剔除的参数到 application.properties 即可。可以不完全配置，只配置自己关心的参数，其余参数会取默认值。需要注意的是 com.alipay.sofa.rpc.aft.regulation.effective 是该功能的全局开关，如果关闭则该功能不会运行，其他参数也都不生效。\n 属性 描述 默认值 timeWindow 时间窗口大小：对统计信息计算的周期。 10s leastWindowCount 时间窗口内最少调用数：只有在时间窗口内达到了该最低值的数据才会被加入到计算和调控中。 10次 leastWindowExceptionRateMultiple 时间窗口内异常率与服务平均异常率的降级比值：在对统计信息进行计算的时候，会计算出该服务所有有效调用ip的平均异常率，如果某个ip的异常率大于等于了这个最低比值，则会被降级。 6倍 weightDegradeRate 降级比率：地址在进行权重降级时的降级比率。 1\u0026amp;frasl;20 weightRecoverRate 恢复比率：地址在进行权重恢复时的恢复比率。 2倍 degradeEffective 降级开关：如果应用打开了这个开关，则会对符合降级的地址进行降级，否则只会进行日志打印。 false(关闭) degradeLeastWeight 降级最小权重：地址权重被降级后的值如果小于这个最小权重，则会以该最小权重作为降级后的值。 1 degradeMaxIpCount 降级的最大ip数：同一个服务被降级的ip数不能超过该值。 2 regulationEffective 全局开关：如果应用打开了这个开关，则会开启整个单点故障自动剔除摘除功能，否则完全不进入该功能的逻辑。 false(关闭) 示例\ncom.alipay.sofa.rpc.aft.time.window=20 com.alipay.sofa.rpc.aft.least.window.count=30 com.alipay.sofa.rpc.aft.least.window.exception.rate.multiple=1.4 com.alipay.sofa.rpc.aft.weight.degrade.rate=0.5 com.alipay.sofa.rpc.aft.weight.recover.rate=1.2 com.alipay.sofa.rpc.aft.degrade.effective=true com.alipay.sofa.rpc.aft.degrade.least.weight=1 com.alipay.sofa.rpc.aft.degrade.max.ip.count=2 com.alipay.sofa.rpc.aft.regulation.effective=true 如上配置，打开了自动故障剔除功能和降级开关，当节点出现故障时会被进行权重降级，在恢复时会被进行权重恢复。每隔 20s 进行一次节点健康状态的度量，20s 内调用次数超过 30 次的节点才被作为计算数据，如果单个节点的异常率超过了所有节点的平均异常率的 1.4 倍则对该节点进行权重降级，降级的比率为 0.5 。权重最小降级到 1 。如果单个节点的异常率低于了平均异常率的 1.4 倍则对该节点进行权重恢复，恢复的比率为1.2 。单个服务最多降级 2 个ip。\n ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/configuration-fault-tolerance/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a132b54b2398534d1773489e2b0db166","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","summary":"自动故障剔除会自动监控 RPC 调用的情况，对故障节点进行权重降级，并在节点恢复健康时进行权重恢复。目前支持 bolt 协议。 在 SOFABoot 中，只需要配置自动故障剔除的","tags":null,"title":"自动故障剔除","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/","wordcount":759},{"author":null,"categories":null,"content":"集群中通常一个服务有多个服务提供者。其中部分服务提供者可能由于网络，配置，长时间 fullgc ，线程池满，硬件故障等导致长连接还存活但是程序已经无法正常响应。单机故障剔除功能会将这部分异常的服务提供者进行降级，使得客户端的请求更多地指向健康节点。当异常节点的表现正常后，单机故障剔除功能会对该节点进行恢复，使得客户端请求逐渐将流量分发到该节点。单机故障剔除功能解决了服务故障持续影响业务的问题，避免了雪崩效应。可以减少人工干预需要的较长的响应时间，提高系统可用率。\n运行机制：\n 单机故障剔除会统计一个时间窗口内的调用次数和异常次数，并计算每个服务对应ip的异常率和该服务的平均异常率。 当达到ip异常率大于服务平均异常率到一定比例时，会对该服务+ip的维度进行权重降级。 如果该服务+ip维度的权重并没有降为0，那么当该服务+ip维度的调用情况正常时，则会对其进行权重恢复。 整个计算和调控过程异步进行，不会阻塞调用。 单机故障剔除的使用方式如下：\nFaultToleranceConfig faultToleranceConfig = new FaultToleranceConfig(); faultToleranceConfig.setRegulationEffective(true); faultToleranceConfig.setDegradeEffective(true); faultToleranceConfig.setTimeWindow(20); faultToleranceConfig.setWeightDegradeRate(0.5); FaultToleranceConfigManager.putAppConfig(\u0026amp;quot;appName\u0026amp;quot;, faultToleranceConfig); 如上，该应用会在打开了单机故障剔除开关，每20s的时间窗口进行一次异常情况的计算，如果某个服务+ip的调用维度被判定为故障节点，则会进行将该服务+ip的权重降级为0.5倍。\n更加详细的参数请参考单机故障剔除参数。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/fault-tolerance/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7501b0fac1d1d89c61de0d591e29e1d0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault-tolerance/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/fault-tolerance/","summary":"集群中通常一个服务有多个服务提供者。其中部分服务提供者可能由于网络，配置，长时间 fullgc ，线程池满，硬件故障等导致长连接还存活但是程序已经无法正常","tags":null,"title":"自动故障剔除","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/fault-tolerance/","wordcount":528},{"author":null,"categories":null,"content":" 在使用自定义埋点组件的情况下，用户可以选择自定义 Reporter。\n自定义 Reporter 实现 public class MyReporter implements Reporter { @Override public String getReporterType() { return \u0026amp;quot;myReporter\u0026amp;quot;; } @Override public void report(SofaTracerSpan sofaTracerSpan) { // System.out 输出 System.out.println(\u0026amp;quot;this is my custom reporter\u0026amp;quot;); } @Override public void close() { // ignore } } 配置 com.alipay.sofa.tracer.reporter-name=com.glmapper.bridge.boot.flexible.MyReporter 自定义实现 Reporter 可以将业务埋点的日志输出到任何期望的地方。\n","date":-62135596800,"description":"","dir":"projects/sofa-tracer/reporter-custom/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"521206c7f4051c1cc8ec8232c20bab6d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/reporter-custom/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-tracer/reporter-custom/","summary":"在使用自定义埋点组件的情况下，用户可以选择自定义 Reporter。 自定义 Reporter 实现 public class MyReporter implements Reporter { @Override public String getReporterType() { return \u0026quot;myReporter\u0026quot;; } @Override public void report(SofaTracerSpan sofaTracerSpan) { // System.out 输出 System.out.println(\u0026quot;this is my custom reporter\u0026quot;); } @Override","tags":null,"title":"自定义 Reporter","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/reporter-custom/","wordcount":108},{"author":null,"categories":null,"content":" SOFARPC 支持自定义业务线程池。可以为指定服务设置一个独立的业务线程池，和 SOFARPC 自身的业务线程池是隔离的。多个服务可以共用一个独立的线程池。\nSOFARPC 要求自定义线程池的类型必须是 com.alipay.sofa.rpc.server.UserThreadPool。\nXML 方式 如果采用 XML 的方式发布服务，可以先设定一个 class 为 com.alipay.sofa.rpc.server.UserThreadPool 的线程池的 Bean，然后设置到 \u0026amp;lt;sofa:global-attrs\u0026amp;gt; 标签的 thread-pool-ref 属性中：\n\u0026amp;lt;bean id=\u0026amp;quot;helloService\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.quickstart.HelloService\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;!-- 自定义一个线程池 --\u0026amp;gt; \u0026amp;lt;bean id=\u0026amp;quot;customExecutor\u0026amp;quot; class=\u0026amp;quot;com.alipay.sofa.rpc.server.UserThreadPool\u0026amp;quot; init-method=\u0026amp;quot;init\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;corePoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;maximumPoolSize\u0026amp;quot; value=\u0026amp;quot;10\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;property name=\u0026amp;quot;queueSize\u0026amp;quot; value=\u0026amp;quot;0\u0026amp;quot; /\u0026amp;gt; \u0026amp;lt;/bean\u0026amp;gt; \u0026amp;lt;sofa:service ref=\u0026amp;quot;helloService\u0026amp;quot; interface=\u0026amp;quot;XXXService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;!-- 将线程池设置给一个 Service --\u0026amp;gt; \u0026amp;lt;sofa:global-attrs thread-pool-ref=\u0026amp;quot;customExecutor\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:service\u0026amp;gt; Annotation 方式 如果是采用 Annotation 的方式发布服务，可以通过设置 @SofaServiceBinding 的 userThreadPool 属性来设置自定义线程池的 Bean：\n@SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, userThreadPool = \u0026amp;quot;customThreadPool\u0026amp;quot;)}) public class SampleServiceImpl implements SampleService { } 在 Spring 环境使用 API 方式 如果是在 Spring 环境下使用 API 的方式发布服务，可以通过调用 BoltBindingParam 的 setUserThreadPool 方法来设置自定义线程池：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setUserThreadPool(new UserThreadPool()); 在非 Spring 环境下使用 API 方式 如果是在非 Spring 环境下使用 API 的方式，可以通过如下的方式来设置自定义线程池：\nUserThreadPool threadPool = new UserThreadPool(); threadPool.setCorePoolSize(10); threadPool.setMaximumPoolSize(100); threadPool.setKeepAliveTime(200); threadPool.setPrestartAllCoreThreads(false); threadPool.setAllowCoreThreadTimeOut(false); threadPool.setQueueSize(200); UserThreadPoolManager.registerUserThread(ConfigUniqueNameGenerator.getUniqueName(providerConfig), threadPool); 如上为 HelloService 服务设置了一个自定义线程池。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-threadpool/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"3f05f154bcb2b653ebeebb35b84d5ae1","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-threadpool/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-threadpool/","summary":"SOFARPC 支持自定义业务线程池。可以为指定服务设置一个独立的业务线程池，和 SOFARPC 自身的业务线程池是隔离的。多个服务可以共用一个独立的线程池。 SOFARPC 要求自定义","tags":null,"title":"自定义线程池","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-threadpool/","wordcount":412},{"author":null,"categories":null,"content":"SOFARPC 中对服务地址的选择也抽象为了一条处理链，由每一个 Router 进行处理。同 Filter 一样， SOFARPC 对 Router 提供了同样的扩展能力。\n@Extension(value = \u0026amp;quot;customerRouter\u0026amp;quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override public boolean needToLoad(ConsumerBootstrap consumerBootstrap) { return true; } @Override public List\u0026amp;lt;ProviderInfo\u0026amp;gt; route(SofaRequest request, List\u0026amp;lt;ProviderInfo\u0026amp;gt; providerInfos) { return providerInfos; } 新建扩展文件 META-INF/services/sofa-rpc/com.alipay.sofa.rpc.client.Router 。内容如下：\ncustomerRouter=com.alipay.sofa.rpc.custom.CustomRouter 如上自定义了一个 CustomerRouter ，生效于所有消费者。其中 init 参数 ConsumerBootstrap 是引用服务的包装类，能够拿到 ConsumerConfig ，代理类，服务地址池等对象。 needToLoad 表示是否生效该 Router ， route 方法即筛选地址的方法。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-router/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"236e8d4bda3e856267a3575853aa900c","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-router/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-router/","summary":"SOFARPC 中对服务地址的选择也抽象为了一条处理链，由每一个 Router 进行处理。同 Filter 一样， SOFARPC 对 Router 提供了同样的扩展能力。 @Extension(value = \u0026quot;customerRouter\u0026quot;) @AutoActive(consumerSide = true) public class CustomerRouter extends Router { @Override public void init(ConsumerBootstrap consumerBootstrap) { } @Override","tags":null,"title":"自定义路由寻址","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-router/","wordcount":179},{"author":null,"categories":null,"content":" SOFARPC 提供了一套良好的可扩展性机制，为各个模块提供 SPI 的能力。 SOFARPC 对请求与响应的过滤链处理方式是通过多个过滤器 Filter 来进行具体的拦截处理，该部分可由用户自定义 Filter 扩展，自定义 Filter 的执行顺序在内置 Filter 之后。具体方式如下：\nBolt Filter 新建自定义 Filter 。\npublic class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 生效该自定义 Filter 到拦截器链中。这一步具体方式有三种。 方式1：API方式。该种方式能够生效到指定的 provider 或 consumer 。\n// 服务提供者 providerConfig.setFilterRef(Arrays.asList(new CustomFilter())); // 服务调用者 consumerConfig.setFilterRef(Arrays.asList(new CustomFilter())); 方式2：在类上加上 @Extension 注解+配置扩展文件方式。\n@Extension(\u0026amp;quot;customer\u0026amp;quot;) public class CustomFilter extends Filter { @Override public boolean needToLoad(FilterInvoker invoker) { return true; } @Override public SofaResponse invoke(FilterInvoker invoker, SofaRequest request) throws SofaRpcException { SofaResponse response = invoker.invoke(request); return response; } } 新建扩展文件 META-INF/services/sofa-rpc/com.alipay.sofa.rpc.filter.Filter 。内容如下：\ncustomer=com.alipay.sofa.rpc.custom.CustomFilter 编码注入。\n// 服务提供者 providerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); // 服务调用者 consumerConfig.setFilter(Arrays.asList(\u0026amp;quot;customer\u0026amp;quot;)); 方式三：在类上加上 @Extension 注解+ @AutoActive 注解方式+配扩展文件方式。该种方式利用 @AutoActive 注解代替了上述第二中方式的编码注入步骤，能够生效于所有 provider 或 consumer 。其中 providerSide 参数表示是否生效于服务端， consumerSide 参数表示是否生效于客户端。\n@Extension(\u0026amp;quot;customer\u0026amp;quot;) @AutoActive(providerSide = true, consumerSide = true) public class customerFilter extends Filter { // ... } ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/custom-filter/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"30ff5937b52a7c2dd8028e878979a33d","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-filter/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/custom-filter/","summary":"SOFARPC 提供了一套良好的可扩展性机制，为各个模块提供 SPI 的能力。 SOFARPC 对请求与响应的过滤链处理方式是通过多个过滤器 Filter 来进行具体的拦截处理，该部分可由用户","tags":null,"title":"自定义过滤器","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/custom-filter/","wordcount":409},{"author":null,"categories":null,"content":" 本文是对 MOSN 自定义配置的说明。\nDuration String 字符串，由一个十进制数字和一个时间单位后缀组成，有效的时间单位为 ns、us（或µs）、ms、s、m、h，例如 1h、3s、500ms。 metadata metadata 用于 MOSN 路由和 Cluster Host 之间的匹配。\n{ \u0026amp;quot;filter_metadata\u0026amp;quot;:{ \u0026amp;quot;mosn.lb\u0026amp;quot;:{} } } mosn.lb 可对应任意的 string-string 的内容。\ntls_context { \u0026amp;quot;status\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;server_name\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;ca_cert\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;cert_chain\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;private_key\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;verify_client\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;require_client_cert\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;insecure_skip\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;cipher_suites\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;ecdh_curves\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;min_version\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;max_version\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;alpn\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;fall_back\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;extend_verify\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;, \u0026amp;quot;sds_source\u0026amp;quot;:{} } status，bool类型，表示是否开启 TLS，默认是 false。 type，字符串类型，描述 tls_context 的类型。tls_context 支持扩展实现，不同的 type 对应不同的实现方式，默认实现方式对应的 type 是空字符串。 server_name，当没有配置 insecure_skip 时，用于校验服务端返回证书的 hostname。作为Cluster配置时有效。 ca_cert，证书签发的根 CA 证书。 cert_chain，TLS 证书链配置。 private_key，证书私钥配置。 verify_client，bool 类型，作为 Listener 配置时有效，表示是否要校验 Client 端证书 require_client_cert，bool 类型，表示是否强制 Client 端必须携带证书。 insecure_skip，bool 类型，作为 Cluster 配置时有效，表示是否要忽略 Server 端的证书校验。 cipher_suites，如果配置了该配置，那么 TLS 连接将只支持配置了的密码套件，并且会按照配置的顺序作为优先级使用，支持的套件类型如下：\nECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-AES256-CBC-SHA ECDHE-RSA-AES128-CBC-SHA ECDHE-ECDSA-AES256-CBC-SHA ECDHE-ECDSA-AES128-CBC-SHA RSA-AES256-CBC-SHA RSA-AES128-CBC-SHA ECDHE-RSA-3DES-EDE-CBC-SHA RSA-3DES-EDE-CBC-SHA ECDHE-RSA-SM4-SM3 ECDHE-ECDSA-SM4-SM3 ecdh_curves，如果配置了该配置，那么 TLS 连接将只支持配置了的曲线。\n 支持 x25519、p256、p384、p521。 min_version，最低的 TLS 协议版本，默认是 TLS1.0。\n 支持 TLS1.0、TLS1.1、TLS1.2。 默认会自动识别可用的 TLS 协议版本。 max_version，最高的 TLS 协议版本，默认是 TLS1.2。\n 支持 TLS1.0、TLS1.1、TLS1.2。 默认会自动识别可用的 TLS 协议版本。 alpn，TLS 的 ALPN 配置。\n 支持 h2、http/1.1、 sofa。 fall_back，bool类型，当配置为 true 时，如果证书解析失败，不会报错而是相当于没有开启 TLS。\n extend_verify，任意 json 类型，当 type 为非空时，作为扩展的配置参数。\n sds_source，访问 SDS API 的配置，如果配置了这个配置，ca_cert、cert_chain 和 private_key 都会被忽略，但是其余的配置依然有效。\n sds_source { \u0026amp;quot;CertificateConfig\u0026amp;quot;:{}, \u0026amp;quot;ValidationConfig\u0026amp;quot;:{} } CertificateConfig 描述了如何获取 cert_chain 和 private_key 的配置。 ValidationConfig 描述了如何获取 ca_cert 的配置。 详细的 Config 内容参考 envoy: sdssecretconfig。 ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/custom/","fuzzywordcount":1100,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"cdad467fd3551e47a7585511278767cd","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/custom/","publishdate":"0001-01-01T00:00:00Z","readingtime":3,"relpermalink":"/sofastack.tech/projects/mosn/configuration/custom/","summary":"本文是对 MOSN 自定义配置的说明。 Duration String 字符串，由一个十进制数字和一个时间单位后缀组成，有效的时间单位为 ns、us（或µs）、ms、s、m、h，例如","tags":null,"title":"自定义配置说明","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/custom/","wordcount":1005},{"author":null,"categories":null,"content":" SOFARPC 支持进行框架层面的重试策略，前提是集群模式为 FailOver（SOFARPC 默认即为 FailOver 模式）。重试只有在发生服务端的框架层面异常或者是超时异常才会发起。如果是业务抛出异常，是不会重试的。默认情况下 SOFARPC 不进行任何重试。\n 请注意：超时异常虽然可以重试，但是需要服务端保证业务的幂等性，否则可能会有风险\n XML 方式 如果使用 XML 方式订阅服务，可以设置 sofa:global-attrs 的 retries 参数来设置重试次数：\n\u0026amp;lt;sofa:reference jvm-first=\u0026amp;quot;false\u0026amp;quot; id=\u0026amp;quot;retriesServiceReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.rpc.samples.retries.RetriesService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs retries=\u0026amp;quot;2\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 如果是使用 Annotation 的方式，可以通过设置 @SofaReferenceBinding 注解的 retries 属性来设置：\n@SofaReference(binding = @SofaReferenceBinding(bindingType = \u0026amp;quot;bolt\u0026amp;quot;, retries = 2)) private SampleService sampleService; Spring 环境下 API 方式 如果是在 Spring 环境下用 API 的方式，可以调用 BoltBindingParam 的 setRetries 方法来设置：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setRetries(2); 非 Spring 环境下 API 方式 如果是在非 Spring 环境下直接使用 SOFARPC 的裸 API 的方式，可以通过调用 ConsumerConfig 的 setRetries 方法来设置：\nConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;RetriesService\u0026amp;gt;(); consumerConfig.setRetries(2); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/retry-invoke/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d60b44aa8f1b49ab6c1bbc55593a91da","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/retry-invoke/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/retry-invoke/","summary":"SOFARPC 支持进行框架层面的重试策略，前提是集群模式为 FailOver（SOFARPC 默认即为 FailOver 模式）。重试只有在发生服务端的框架层面异常或者是超时","tags":null,"title":"调用重试","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/retry-invoke/","wordcount":319},{"author":null,"categories":null,"content":" SOFARPC 提供多种负载均衡算法，目前支持以下五种：\n 类型 名称 描述 random 随机算法 默认负载均衡算法。 localPref 本地优先算法 优先发现是否本机发布了该服务，如果没有再采用随机算法。 roundRobin 轮询算法 方法级别的轮询，各个方法间各自轮询，互不影响。 consistentHash 一致性hash算法 同样的方法级别的请求会路由到同样的节点。 weightRoundRobin 按权重负载均衡轮询算法 按照权重对节点进行轮询。性能较差，不推荐使用。 要使用某种特定的负载均衡算法，可以按照以下的方式进行设置：\nXML 方式 如果使用 XML 的方式引用服务，可以通过设置 sofa:global-attrs 标签的 loadBalancer 属性来设置：\n\u0026amp;lt;sofa:reference interface=\u0026amp;quot;com.example.demo.SampleService\u0026amp;quot; id=\u0026amp;quot;sampleService\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs loadBalancer=\u0026amp;quot;roundRobin\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; Annotation 方式 Annotation 方式目前暂未提供设置某一个 Reference 的负载均衡算法的方式。将在后续的版本中提供。\n在 Spring 环境下 API 方式 如果在 Spring 或者 Spring Boot 的环境下使用 API，可以通过调用 BoltBindingParam 的 setLoadBalancer 方法来设置：\nBoltBindingParam boltBindingParam = new BoltBindingParam(); boltBindingParam.setLoadBalancer(\u0026amp;quot;roundRobin\u0026amp;quot;); 非 Spring 环境下 API 方式 如果在非 Spring 环境下直接使用 SOFARPC 提供的裸 API，可以通过调用 ConsumerConfig 的 setLoadBalancer 方法来设置：\nConsumerConfig consumerConfig = new ConsumerConfig(); consumerConfig.setLoadbalancer(\u0026amp;quot;random\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/load-balance/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"739984ca9a414429304f85010fd73ad0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/load-balance/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/load-balance/","summary":"SOFARPC 提供多种负载均衡算法，目前支持以下五种： 类型 名称 描述 random 随机算法 默认负载均衡算法。 localPref 本地优先算法 优先发现是否本机发布了该服务，如果没有再采用","tags":null,"title":"负载均衡","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/load-balance/","wordcount":375},{"author":null,"categories":null,"content":" 任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。\n 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 文档 SOFADashboard 配置参数文档 简单 代码 支持 SOFARegistry 中 代码 支持 Docker 中 代码 支持 Kubernetes 中 代码 支持 Apollo 中 代码 优化前端 中 ","date":-62135596800,"description":"","dir":"projects/sofa-dashboard/roadmap/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"a740c874742b504de9011b07f3a4ddb5","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/roadmap/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-dashboard/roadmap/","summary":"任务列表 下面表格记录了还没有实现的功能特性，欢迎大家认领任务，参与贡献。 类型 任务 困难度 认领人及时间 计划完成时间 进度 相关 Issue 文档 SOFADashboard 配置参数文档 简","tags":null,"title":"路线图及任务认领","type":"projects","url":"/sofastack.tech/projects/sofa-dashboard/roadmap/","wordcount":102},{"author":null,"categories":null,"content":" 1. registry-meta 1.1 推送开关 在注册中心新版本发布的过程中为了把对业务的影响减少到最小，避免服务端重启动引发大规模服务地址信息变更产生大量推送，我们提供运维层面暂时关闭推送的能力。在服务端完成发布后，可以打开推送恢复正常工作状态，在关闭期间的数据订阅和服务发布信息会再次进行全局推送进行补偿。\n打开推送：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/close\u0026amp;quot; 关闭推送：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/stopPushDataSwitch/open\u0026amp;quot; 1.2 查询地址列表 查看 meta 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/META/node/query\u0026amp;quot; 查看 data 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/DATA/node/query\u0026amp;quot; 查看 session 集群的地址列表：\ncurl \u0026amp;quot;http://\u0026amp;lt;meta_ip\u0026amp;gt;:9615/digest/SESSION/node/query\u0026amp;quot; 2. registry-data 2.1 查询数据 查看 pub 数量：\ncurl \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/datum/count\u0026amp;quot; 根据客户端的 ip\u0026amp;amp;port 查询其发布的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;data_ip\u0026amp;gt;:9622/digest/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;\u0026amp;quot;:\u0026amp;quot;\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;}\u0026#39; 3. registry-session 3.1 查询数据 根据客户端的 ip\u0026amp;amp;port 查询其发布的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/pub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]\u0026#39; 根据客户端的 ip\u0026amp;amp;port 查询其订阅的数据：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/digest/sub/connect/query\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;[\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]\u0026#39; 3.2 断开客户端链接：clientOff 根据客户端的 ip\u0026amp;amp;port 强制删除其所有 sub\u0026amp;amp;pub 数据（但不会断开连接）：\ncurl -X POST \u0026amp;quot;http://\u0026amp;lt;session_ip\u0026amp;gt;:9603/api/clients/off\u0026amp;quot; -H \u0026amp;quot;Content-Type: application/json\u0026amp;quot; -d \u0026#39;{\u0026amp;quot;connectIds\u0026amp;quot;: [\u0026amp;quot;\u0026amp;lt;clientIP\u0026amp;gt;:\u0026amp;lt;client端口\u0026amp;gt;\u0026amp;quot;]}\u0026#39; ","date":-62135596800,"description":"","dir":"projects/sofa-registry/management-api/","fuzzywordcount":600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"2cf59ac422c84c279d73c1f7f1cd0902","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/management-api/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-registry/management-api/","summary":"1. registry-meta 1.1 推送开关 在注册中心新版本发布的过程中为了把对业务的影响减少到最小，避免服务端重启动引发大规模服务地址信息变更产生大量推送，我们提供运维","tags":null,"title":"运维命令","type":"projects","url":"/sofastack.tech/projects/sofa-registry/management-api/","wordcount":554},{"author":null,"categories":null,"content":"SOFARPC 支持不同的通信协议，目前支持 Bolt, RESTful 和 Dubbo，详细的事情请参考各个协议对应的文档： * Bolt 协议 * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化协议 * 自定义线程池 * RESTful * 基本使用 * 自定义 Filter * 集成 Swagger * Dubbo * 基本使用 * H2C * 基本使用\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/protocol/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"18f51cb12f7a0384a71ab22349292a08","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/protocol/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/protocol/","summary":"SOFARPC 支持不同的通信协议，目前支持 Bolt, RESTful 和 Dubbo，详细的事情请参考各个协议对应的文档： * Bolt 协议 * 基本使用 * 调用方式 * 超时控制 * 泛化调用 * 序列化","tags":null,"title":"通信协议","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/protocol/","wordcount":109},{"author":null,"categories":null,"content":" 1. 环境准备 要使用 SOFARegistry，需要先准备好基础环境，SOFARegistry 依赖以下环境：\n Linux/Unix/Mac JDK8 需要采用 Apache Maven 3.2.5 或者以上的版本来编译 2. 资源配额 cpu: 4c memory: 8G disk: 50G 3. 两种部署模式 集成部署模式 将 meta/data/session 三个角色打包集成在一个 jvm 里运行，可单机或集群部署，部署简单。 独立部署模式 将 meta/data/session 三个角色分开部署，每个角色都可以单机或集群部署，可根据实际情况为每个角色部署不同的数量。 生产环境建议使用这种部署模式。 4. 配置参数 SOFARegistry 的部署，依赖于一些公共参数\n properties environment 默认值 作用 nodes.localDataCenter x DefaultDataCenter 集群名，多个注册中心公用同一个数据库用到 nodes.localRegion x DEFAULT_ZONE 逻辑 region, 创建多组 session jdbc.url JDBC_URL 必填 数据库地址 jdbc.username JDBC_USERNAME 必填 数据库用户名 jdbc.password JDBC_PASSWORD 必填 数据库密码 properties 可以写在 registry-all/conf/application.properties 中， kubernetes 下部署也可以使用 configmap 进行文件挂载\n5. 打包 jar release 页面 下载最新的 registry-all.tgz 包\ntar -zxvf registry-all.tgz cd registry-all 或者从源码打包\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Pserver-release -Dmaven.test.skip=true cp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all image image 托管于 https://hub.docker.com/r/sofaregistry/sofaregistry\n或者从源码 build: 修改 Makefile 中 image 的 repository\ngit clone https://github.com/sofastack/sofa-registry.git cd sofa-registry mvn clean package -Dmaven.test.skip=true make image_build make image_push 6. 集成部署模式 集成部署模式，是将 meta/data/session 三个角色打包集成在一个 JVM 里运行，可单机或集群部署, 不建议大规模使用\n6.1 jar 单机部署 集成部署的单机部署模式可以直接参考快速开始-服务端部署部分。\n6.2 jar 集群部署 解压 registry-all.tgz，并修改配置文件 集群部署，即搭建 2 台以上的集群，建议至少使用 3 台（注意：目前不支持在同一台机器部署多个 SOFARegistry，因此您必须有 3 台不同的机器）。在每一台机器上的部署方法同上：\ncp ./server/distribution/all/target/registry-all.tgz \u0026amp;lt;somewhere\u0026amp;gt; cd \u0026amp;lt;somewhere\u0026amp;gt; tar -zxvf registry-all.tgz cd registry-all 区别是每台机器在部署时需要修改 registry-all/conf/application.properties 配置, 组成同一个注册中心的多台机器需要配置相同的数据库和nodes.localDataCenter\nnodes.localDataCenter=DefaultDataCenter nodes.localRegion=DEFAULT_ZONE jdbc.url = jdbc:mysql://127.0.0.1:3306/registrymetadb?useUnicode=true\u0026amp;amp;characterEncoding=utf8 jdbc.username = root jdbc.password = root 启动 registry-integration 每台机器都修改以上配置文件后，按照“单机部署”的步骤去启动 registry-integration 即可。 sh bin/integration/start.sh\n6.3 docker 集群部署 客户端和 SOFARegistry 需要同一个三层网络内，因此利用 docker 部署需要使用 host network 可以通过配置文件挂载的方式进行部署，也可以通过环境变量传递的方式 同时需要添加 REGISTRY_APP_NAME=integration 进入集成模式，在一个 jvm 里启动 3 个角色\nimage 中， registry-all.tgz 的解压地址在 registry-distribution/registry-all, 配置需要挂载到正确的目录\ndocker run -e REGISTRY_APP_NAME=integration \\ --name=sofa-registry --rm --net=host \\ -v $PWD/conf/:/registry-distribution/registry-all/conf/ \\ -e JDBC_URL=jdbc:mysql://172.17.0.1:3306/registrymetadb -e JDBC_USERNAME=root -e JDBC_PASSWORD=root sofaregistry/sofaregistry:6.1.4 7. 独立部署模式 独立部署模式，是将 meta/data/session 三个角色分开部署，每个角色都可以单机或集群部署，可根据实际情况为每个角色部署不同的数量，生产环境推荐使用这种部署模式。\n以下介绍 332 模式（即 3 台 meta + 3 台 data + 2 台 session）的部署步骤。\n7.1 jar 集群部署 解压 registry-all.tgz，并修改配置文件 集群部署，即搭建 2 台以上的集群，建议至少使用 3 台（注意：目前不支持在同一台机器部署多个 SOFARegistry，因此您必须有 3 台不同的机器）。在每一台机器上的部署方法同上： cp …","date":-62135596800,"description":"","dir":"projects/sofa-registry/deployment/","fuzzywordcount":1600,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"7e28583bc38be66af8d704d7fbcd9dd4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-registry/deployment/","publishdate":"0001-01-01T00:00:00Z","readingtime":4,"relpermalink":"/sofastack.tech/projects/sofa-registry/deployment/","summary":"1. 环境准备 要使用 SOFARegistry，需要先准备好基础环境，SOFARegistry 依赖以下环境： Linux/Unix/Mac JDK8 需要采用 Apache Maven 3.2.5 或者以上的版本来编译","tags":null,"title":"部署","type":"projects","url":"/sofastack.tech/projects/sofa-registry/deployment/","wordcount":1558},{"author":null,"categories":null,"content":" MOSN 的配置文件可以分为以下四大部分：\n Servers 配置，目前仅支持最多 1 个 Server 的配置，Server 中包含一些基础配置以及对应的 Listener 配置 ClusterManager 配置，包含 MOSN 的 Upstream 详细信息 对接控制平面（Pilot）的 xDS 相关配置 其他配置 Trace、Metrics、Debug、Admin API 相关配置 扩展配置，提供自定义配置扩展需求 配置文件概览\nMOSN 的基本配置部分如下所示：\n{ \u0026amp;quot;servers\u0026amp;quot;: [], \u0026amp;quot;cluster_manager\u0026amp;quot;: {}, \u0026amp;quot;dynamic_resources\u0026amp;quot;: {}, \u0026amp;quot;static_resources\u0026amp;quot;: {}, \u0026amp;quot;admin\u0026amp;quot;:{}, \u0026amp;quot;pprof\u0026amp;quot;:{}, \u0026amp;quot;tracing\u0026amp;quot;:{}, \u0026amp;quot;metrics\u0026amp;quot;:{} } 配置类型 MOSN 的配置包括以下几种类型：\n 静态配置 动态配置 混合模式 静态配置 静态配置是指 MOSN 启动时，不对接控制平面 Pilot 的配置，用于一些相对固定的简单场景（如 MOSN 的示例）。 使用静态配置启动的 MOSN，也可以通过扩展代码，调用动态更新配置的接口实现动态修改。 静态配置启动时必须包含一个 Server 以及至少一个 Cluster。 动态配置 动态配置是指 MOSN 启动时，只有访问控制平面相关的配置，没有 MOSN 运行时所需要的配置。\n 使用动态配置启动的 MOSN，会向管控面请求获取运行时所需要的配置，管控面也可能在运行时推送更新 MOSN 运行配置。\n 动态配置启动时必须包含 DynamicResources 和 StaticResources 配置。\n 混合模式 MOSN 启动时的配置可以同时包含静态模式与动态模式，以混合模式启动的 MOSN 会先以静态配置完成初始化，随后可能由控制平面获取配置更新。\n配置示例 静态配置示例 动态配置的示例如下所示。\n{ \u0026amp;quot;servers\u0026amp;quot;: [ { \u0026amp;quot;default_log_path\u0026amp;quot;: \u0026amp;quot;/home/admin/logs/mosn/default.log\u0026amp;quot;, \u0026amp;quot;default_log_level\u0026amp;quot;: \u0026amp;quot;DEBUG\u0026amp;quot;, \u0026amp;quot;processor\u0026amp;quot;: 4, \u0026amp;quot;listeners\u0026amp;quot;: [ { \u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;0.0.0.0:12220\u0026amp;quot;, \u0026amp;quot;bind_port\u0026amp;quot;: true, \u0026amp;quot;filter_chains\u0026amp;quot;: [ { \u0026amp;quot;filters\u0026amp;quot;: [ { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;proxy\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;downstream_protocol\u0026amp;quot;: \u0026amp;quot;SofaRpc\u0026amp;quot;, \u0026amp;quot;upstream_protocol\u0026amp;quot;: \u0026amp;quot;SofaRpc\u0026amp;quot;, \u0026amp;quot;router_config_name\u0026amp;quot;: \u0026amp;quot;test_router\u0026amp;quot; } }, { \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;connection_manager\u0026amp;quot;, \u0026amp;quot;config\u0026amp;quot;: { \u0026amp;quot;router_config_name\u0026amp;quot;: \u0026amp;quot;test_router\u0026amp;quot;, \u0026amp;quot;virtual_hosts\u0026amp;quot;: [] } } ] } ] } ] } ], \u0026amp;quot;cluster_manager\u0026amp;quot;: { \u0026amp;quot;clusters\u0026amp;quot;: [ { \u0026amp;quot;name\u0026amp;quot;:\u0026amp;quot;example\u0026amp;quot;, \u0026amp;quot;lb_type\u0026amp;quot;: \u0026amp;quot;LB_ROUNDROBIN\u0026amp;quot;, \u0026amp;quot;hosts\u0026amp;quot;: [ {\u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;127.0.0.1:12200\u0026amp;quot;} ] } ] } } 动态配置示例 静态配置的示例如下所示。\n{ \u0026amp;quot;dynamic_resources\u0026amp;quot;: { \u0026amp;quot;ads_config\u0026amp;quot;: { \u0026amp;quot;api_type\u0026amp;quot;: \u0026amp;quot;GRPC\u0026amp;quot;, \u0026amp;quot;grpc_services\u0026amp;quot;: [ { \u0026amp;quot;envoy_grpc\u0026amp;quot;: {\u0026amp;quot;cluster_name\u0026amp;quot;: \u0026amp;quot;xds-grpc\u0026amp;quot;} } ] } } }, \u0026amp;quot;static_resources\u0026amp;quot;: { \u0026amp;quot;clusters\u0026amp;quot;: [ { \u0026amp;quot;name\u0026amp;quot;: \u0026amp;quot;xds-grpc\u0026amp;quot;, \u0026amp;quot;type\u0026amp;quot;: \u0026amp;quot;STRICT_DNS\u0026amp;quot;, \u0026amp;quot;connect_timeout\u0026amp;quot;: \u0026amp;quot;10s\u0026amp;quot;, \u0026amp;quot;lb_policy\u0026amp;quot;: \u0026amp;quot;ROUND_ROBIN\u0026amp;quot;, \u0026amp;quot;hosts\u0026amp;quot;: [ { \u0026amp;quot;socket_address\u0026amp;quot;: {\u0026amp;quot;address\u0026amp;quot;: \u0026amp;quot;pilot\u0026amp;quot;, \u0026amp;quot;port_value\u0026amp;quot;: 15010} } ], \u0026amp;quot;upstream_connection_options\u0026amp;quot;: { \u0026amp;quot;tcp_keepalive\u0026amp;quot;: { \u0026amp;quot;keepalive_time\u0026amp;quot;: 300 } }, \u0026amp;quot;http2_protocol_options\u0026amp;quot;: { } } ] } } ","date":-62135596800,"description":"","dir":"projects/mosn/configuration/overview/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"0aa65950d2c24e8ce86d265bea275e2a","permalink":"https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/overview/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/mosn/configuration/overview/","summary":"MOSN 的配置文件可以分为以下四大部分： Servers 配置，目前仅支持最多 1 个 Server 的配置，Server 中包含一些基础配置以及对应的 Listener 配置 ClusterManager 配置，包含 MOSN 的 Upstream 详细信","tags":null,"title":"配置概览","type":"projects","url":"/sofastack.tech/projects/mosn/configuration/overview/","wordcount":663},{"author":null,"categories":null,"content":" 目前 SOFATracer 提供了两种采样模式，一种是基于 BitSet 实现的基于固定采样率的采样模式；另外一种是提供给用户自定义实现采样的采样模式。下面通过案例来演示如何使用。\n本示例基于 tracer-sample-with-springmvc 工程；除 application.properties 之外，其他均相同。\n基于固定采样率的采样模式 在 application.properties 中增加采样相关配置项 #采样率 0~100 com.alipay.sofa.tracer.samplerPercentage=100 #采样模式类型名称 com.alipay.sofa.tracer.samplerName=PercentageBasedSampler 验证方式 当采样率设置为100时，每次都会打印摘要日志。 当采样率设置为0时，不打印 当采样率设置为0~100之间时，按概率打印 以请求 10 次来验证下结果。\n1、当采样率设置为100时，每次都会打印摘要日志\n启动工程，浏览器中输入：http://localhost:8080/springmvc ；并且刷新地址10次，查看日志如下：\n{\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:47.643\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173568757510019269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:68,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-1\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:50.980\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569097710029269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-2\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:51.542\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569153910049269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:3,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-4\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 11:54:52.061\u0026amp;quot;,\u0026amp;quot;local.app\u0026amp;quot;:\u0026amp;quot;SOFATracerSpringMVC\u0026amp;quot;,\u0026amp;quot;traceId\u0026amp;quot;:\u0026amp;quot;0a0fe8ec154173569205910069269\u0026amp;quot;,\u0026amp;quot;spanId\u0026amp;quot;:\u0026amp;quot;0.1\u0026amp;quot;,\u0026amp;quot;request.url\u0026amp;quot;:\u0026amp;quot;http://localhost:8080/springmvc\u0026amp;quot;,\u0026amp;quot;method\u0026amp;quot;:\u0026amp;quot;GET\u0026amp;quot;,\u0026amp;quot;result.code\u0026amp;quot;:\u0026amp;quot;200\u0026amp;quot;,\u0026amp;quot;req.size.bytes\u0026amp;quot;:-1,\u0026amp;quot;resp.size.bytes\u0026amp;quot;:0,\u0026amp;quot;time.cost.milliseconds\u0026amp;quot;:2,\u0026amp;quot;current.thread.name\u0026amp;quot;:\u0026amp;quot;http-nio-8080-exec-6\u0026amp;quot;,\u0026amp;quot;baggage\u0026amp;quot;:\u0026amp;quot;\u0026amp;quot;} {\u0026amp;quot;time\u0026amp;quot;:\u0026amp;quot;2018-11-09 …","date":-62135596800,"description":"","dir":"projects/sofa-tracer/sampler/","fuzzywordcount":800,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"48856a040da01abc84213934c1c5fce4","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/sampler/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-tracer/sampler/","summary":"目前 SOFATracer 提供了两种采样模式，一种是基于 BitSet 实现的基于固定采样率的采样模式；另外一种是提供给用户自定义实现采样的采样模式。下面通过案例来演示如何使","tags":null,"title":"采样模式","type":"projects","url":"/sofastack.tech/projects/sofa-tracer/sampler/","wordcount":719},{"author":null,"categories":null,"content":" 链路数据透传 链路数据透传功能支持应用向调用上下文中存放数据，达到整个链路上的应用都可以操作该数据。 使用方式如下，可分别向链路的 request 和 response 中放入数据进行透传，并可获取到链路中相应的数据。\nRpcInvokeContext.getContext().putRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;,\u0026amp;quot;value_request\u0026amp;quot;); RpcInvokeContext.getContext().putResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;,\u0026amp;quot;value_response\u0026amp;quot;); String requestValue=RpcInvokeContext.getContext().getRequestBaggage(\u0026amp;quot;key_request\u0026amp;quot;); String responseValue=RpcInvokeContext.getContext().getResponseBaggage(\u0026amp;quot;key_response\u0026amp;quot;); 使用示例 例如 A -\u0026amp;gt; B -\u0026amp;gt; C 的场景中，将 A 设置的请求隐式传参数据传递给 B 和 C。在返回的时候，将 C 和 B 的响应隐式传参数据传递给 A。\nA 请求方设置的时候：\n// 调用前设置请求透传的值 RpcInvokeContext context = RpcInvokeContext.getContext(); context.putRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;, \u0026amp;quot;a2bbb\u0026amp;quot;); // 调用 String result = service.hello(); // 拿到结果透传的值 context.getResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;); B 业务代码中：\npublic String hello() { // 拿到请求透传的值 RpcInvokeContext context = RpcInvokeContext.getContext(); String reqBaggage = context.getRequestBaggage(\u0026amp;quot;reqBaggageB\u0026amp;quot;); // doSomthing(); // 结果透传一个值 context.putResponseBaggage(\u0026amp;quot;respBaggageB\u0026amp;quot;, \u0026amp;quot;b2aaa\u0026amp;quot;); return result; } 如果中途自己启动了子线程，则需要设置子线程的上下文：\nCountDownLatch latch = new CountDownLatch(1); final RpcInvokeContext parentContext = RpcInvokeContext.peekContext(); Thread thread = new Thread(new Runnable(){ public void run(){ try { RpcInvokeContext.setContext(parentContext); // 调一个远程服务 xxxService.sayHello(); latch.countDown(); } finally { RpcInvokeContext.removeContext(); } } }, \u0026amp;quot;new-thread\u0026amp;quot;); thread.start(); // 此时拿不到返回值透传的数据的 latch.await(); //等待 // 此时返回结束，能拿到返回透传的值 和 SOFATracer 的比较 SOFATracer 是蚂蚁开源的一个分布式链路追踪系统,RPC 目前已经和 Tracer 做了集成,默认开启. 和 Tracer 进行数据传递不同的是\n RPC的数据透传更偏向业务使用,而且可以在全链路中进行双向传递,调用方可以传给服务方,服务方也可以传递信息给调用方,SOFATracer 更加偏向于中间件和业务无感知的数据的传递,只能进行单向传递. RPC的透传可以选择性地不在全链路中透传,而Tracer 中如果传递大量信息,会在整个链路中传递.可能对下游业务会有影响. 所以整体来看,两个信息各有利弊,在有一些和业务相关的透传数据的情况下,可以选择 RPC 的透传.\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/invoke-chain-pass-data/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"96cfb41f07a6a2ad979b53093ff5eee9","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","summary":"链路数据透传 链路数据透传功能支持应用向调用上下文中存放数据，达到整个链路上的应用都可以操作该数据。 使用方式如下，可分别向链路的 request 和 response 中放入数","tags":null,"title":"链路数据透传","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/","wordcount":606},{"author":null,"categories":null,"content":"默认 SOFARPC 已经集成了 SOFATracer，用户也可以使用其他的 APM 产品，如 Skywalking来实现相应的功能。详见文档：\n SOFATracer Skywalking 如果想要关闭 SOFARPC 的链路追踪能力的话，在使用了 rpc-sofa-boot-starter 的情况下，可以在 application.properties 配置文件中配置 com.alipay.sofa.rpc.defaultTracer=。\n在直接使用 sofa-rpc-all 的情况下，可以在 main 函数里面加上如下的代码来关闭 SOFARPC 的链路追踪的能力（在发布任何 SOFARPC 的服务或者引用任何 SOFARPC 的服务之前）：\nRpcConfigs.putValue(RpcOptions.DEFAULT_TRACER, \u0026amp;quot;\u0026amp;quot;); ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/tracing-usage/","fuzzywordcount":200,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"5f944f87d827ae060fb0528f6715af97","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/tracing-usage/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/tracing-usage/","summary":"默认 SOFARPC 已经集成了 SOFATracer，用户也可以使用其他的 APM 产品，如 Skywalking来实现相应的功能。详见文档： SOFATracer Skywalking 如果想要关闭 SOFARPC 的链路","tags":null,"title":"链路追踪","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/tracing-usage/","wordcount":197},{"author":null,"categories":null,"content":" 从 rpc-sofa-boot-starter 6.0.1 版本开始，SOFARPC 提供了 RESTful 服务和 Swagger 的一键集成的能力。\n在使用了 rpc-sofa-boot-starter 的情况下，如果想要开启 swagger 的能力，首先需要在 pom.xml 中增加 Swagger 的依赖：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 然后在 application.properties 里面增加 com.alipay.sofa.rpc.restSwagger=true。\n最后，访问 http://localhost:8341/swagger/openapi 就可以拿到 SOFARPC 的 RESTful 的 Swagger OpenAPI 内容。\n如果没有使用 rpc-sofa-boot-starter 或者在 rpc-sofa-boot-starter 的版本低于 6.0.1，可以采用如下的方式集成 Swagger。\n首先，需要在应用中引入 Swagger 相关的依赖，由于 SOFARPC 的 RESTful 协议走的是 JAXRS 标准，因此我们引入 Swagger 的 JAXRS 依赖即可：\n\u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;io.swagger.core.v3\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;swagger-jaxrs2\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;2.0.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; \u0026amp;lt;dependency\u0026amp;gt; \u0026amp;lt;groupId\u0026amp;gt;com.google.guava\u0026amp;lt;/groupId\u0026amp;gt; \u0026amp;lt;artifactId\u0026amp;gt;guava\u0026amp;lt;/artifactId\u0026amp;gt; \u0026amp;lt;version\u0026amp;gt;20.0\u0026amp;lt;/version\u0026amp;gt; \u0026amp;lt;/dependency\u0026amp;gt; 上面引入 Guava 的 20.0 的版本是为了解决 Guava 的版本冲突。\n增加一个 Swagger 的 RESTful 服务 为了能够让 Swagger 将 SOFARPC 的 RESTful 的服务通过 Swagger OpenAPI 暴露出去，我们可以反过来用 SOFARPC 的 RESTful 的服务提供 Swagger 的 OpenAPI 服务。首先，需要新建一个接口：\n@Path(\u0026amp;quot;swagger\u0026amp;quot;) public interface OpenApiService { @GET @Path(\u0026amp;quot;openapi\u0026amp;quot;) @Produces(\u0026amp;quot;application/json\u0026amp;quot;) String openApi(); } 然后提供一个实现类，并且发布成 SOFARPC 的 RESTful 的服务：\n@Service @SofaService(bindings = {@SofaServiceBinding(bindingType = \u0026amp;quot;rest\u0026amp;quot;)}, interfaceType = OpenApiService.class) public class OpenApiServiceImpl implements OpenApiService, InitializingBean { private OpenAPI openAPI; @Override public String openApi() { return Json.pretty(openAPI); } @Override public void afterPropertiesSet() { List\u0026amp;lt;Package\u0026amp;gt; resources = new ArrayList\u0026amp;lt;\u0026amp;gt;(); resources.add(this.getClass().getPackage()); // 扫描当前类所在的 Package，也可以扫描其他的 SOFARPC RESTful 服务接口所在的 Package if (!resources.isEmpty()) { // init context try { SwaggerConfiguration oasConfig = new SwaggerConfiguration() .resourcePackages(resources.stream().map(Package::getName).collect(Collectors.toSet())); OpenApiContext oac = new JaxrsOpenApiContextBuilder() .openApiConfiguration(oasConfig) .buildContext(true); openAPI = oac.read(); } catch (OpenApiConfigurationException e) { throw new RuntimeException(e.getMessage(), e); } } } } 这样，应用启动后，访问 http://localhost:8341/swagger/openapi 即可得到当前的应用发布的所有的 RESTful 的服务的信息。\n解决跨域问题 如果用户在另外一个端口中启动了一个 Swagger UI，并且希望通过 Swagger UI 来访问 http://localhost:8341/swagger/openapi 查看 API 定义，发起调用，那么可能需要解决访问跨域的问题，要解决 SOFARPC RESTful 服务访问跨域的问题，可以在应用启动前增加如下的代码：\nimport org.jboss.resteasy.plugins.interceptors.CorsFilter; public static void main(String[] args) { CorsFilter corsFilter = new CorsFilter(); corsFilter.getAllowedOrigins().add(\u0026amp;quot;*\u0026amp;quot;); …","date":-62135596800,"description":"","dir":"projects/sofa-rpc/restful-swagger/","fuzzywordcount":700,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"d068767fe0dd2922eecef69736684be8","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-swagger/","publishdate":"0001-01-01T00:00:00Z","readingtime":2,"relpermalink":"/sofastack.tech/projects/sofa-rpc/restful-swagger/","summary":"从 rpc-sofa-boot-starter 6.0.1 版本开始，SOFARPC 提供了 RESTful 服务和 Swagger 的一键集成的能力。 在使用了 rpc-sofa-boot-starter 的情况下，如果想要开启 swagger 的能力，首先需要在 pom.xml 中增加 Swagger 的依赖： \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;io.swagger.core.v3\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;swagger-jaxrs2\u0026lt;/artifactId\u0026gt;","tags":null,"title":"集成 SOFARPC RESTful 服务和 Swagger","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/restful-swagger/","wordcount":646},{"author":null,"categories":null,"content":" 服务发布 服务发布过程涉及到三个类 RegistryConfig ，ServerConfig ，ProviderConfig 。\n1. RegistryConfig\nRegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026amp;quot;zookeeper\u0026amp;quot;) .setAddress(\u0026amp;quot;127.0.0.1:2181\u0026amp;quot;) RegistryConfig 表示注册中心。如上声明了服务注册中心的地址和端口是127.0.0.1:2181，协议是 Zookeeper。\n2. ServerConfig\nServerConfig serverConfig = new ServerConfig() .setPort(8803) .setProtocol(\u0026amp;quot;bolt\u0026amp;quot;); ServerConfig 表示服务运行容器。如上声明了一个使用8803端口和 bolt 协议的 server 。\n3. ProviderConfig\nProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWorldService\u0026amp;gt;() .setInterfaceId(HelloWorldService.class.getName()) .setRef(new HelloWorldServiceImpl()) .setServer(serverConfig) .setRegistry(registryConfig); providerConfig.export(); ProviderConfig 表示服务发布。如上声明了服务的接口，实现和该服务运行的 server 。 最终通过 export 方法将这个服务发布出去了。\n服务引用 服务引用涉及到两个类， RegistryConfig 和 ConsumerConfig 。\nConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt; consumerConfig = new ConsumerConfig\u0026amp;lt;HelloService\u0026amp;gt;() .setInterfaceId(HelloService.class.getName()) .setRegistry(registryConfig); HelloService helloService = consumerConfig.refer(); ConsumerConfig 表示服务引用，如上声明了所引用服务的接口和服务注册中心。 最终通过 refer 方法将这个服务引用，获取到该服务的远程调用的代理。\n","date":-62135596800,"description":"","dir":"projects/sofa-rpc/programing-rpc/","fuzzywordcount":400,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"ee6f74a4974c7abf72322cef108d5ef0","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-rpc/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/programing-rpc/","summary":"服务发布 服务发布过程涉及到三个类 RegistryConfig ，ServerConfig ，ProviderConfig 。 1. RegistryConfig RegistryConfig registryConfig = new RegistryConfig() .setProtocol(\u0026quot;zookeeper\u0026quot;) .setAddress(\u0026quot;127.0.0.1:2181\u0026quot;) RegistryConfig 表示注册中心。如上声明了服务","tags":null,"title":"非 Spring 环境 API 使用","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/programing-rpc/","wordcount":300},{"author":null,"categories":null,"content":"预热权重功能让客户端机器能够根据服务端的相应权重进行流量的分发。该功能也常被用于集群内少数机器的启动场景。利用流量权重功能在短时间内对服务端机器进行预热，然后再接收正常的流量比重。 运行机制如下： 1.服务端服务在启动时会将自身的预热时间，预热期内权重，预热完成后的正常权重推送给服务注册中心。如上图 ServiceB 指向 Service Registry 。\n2.客户端在引用服务的时候会获得每个服务实例的预热权重信息。如上图 Service Registry 指向 client 。\n3.客户端在进行调用的时候会根据服务所在地址的预热时期所对应的权重进行流量分发。如上图 client 指向 ServiceA 和 ServiceB 。 ServiceA 预热完毕，权重默认 100 ， ServiceB 处于预热期，权重为 10，因此所承受流量分别为 100%110 和 10%110 。\n该功能使用方式如下。\nProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt; providerConfig = new ProviderConfig\u0026amp;lt;HelloWordService\u0026amp;gt;() .setWeight(100) .setParameter(ProviderInfoAttrs.ATTR_WARMUP_WEIGHT,\u0026amp;quot;10\u0026amp;quot;) .setParameter(ProviderInfoAttrs.ATTR_WARM_UP_END_TIME,\u0026amp;quot;12000\u0026amp;quot;); 如上，该服务的预热期为12s，在预热期内权重为10，预热期结束后的正常权重为100。如果该服务一共发布在两个机器A,B上，A机器正处于预热期内，并使用上述配置，B已经完成预热，正常权重为200。那么客户端在调用的时候，此时流量分发的比重为10：200，A机器预热结束后，流量分发比重为100：200。 在SOFABoot中，如下配置预热时间，预热期间权重和预热完后的权重即可。\n\u0026amp;lt;sofa:reference id=\u0026amp;quot;sampleRestFacadeReferenceBolt\u0026amp;quot; interface=\u0026amp;quot;com.alipay.sofa.endpoint.facade.SampleFacade\u0026amp;quot;\u0026amp;gt; \u0026amp;lt;sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;sofa:global-attrs weight=\u0026amp;quot;100\u0026amp;quot; warm-up-time=\u0026amp;quot;10000\u0026amp;quot; warm-up-weight=\u0026amp;quot;1000\u0026amp;quot;/\u0026amp;gt; \u0026amp;lt;/sofa:binding.bolt\u0026amp;gt; \u0026amp;lt;/sofa:reference\u0026amp;gt; ","date":-62135596800,"description":"","dir":"projects/sofa-rpc/provider-warmup-weight/","fuzzywordcount":500,"kind":"page","lang":"zh","lastmod":1728877684,"objectID":"b9e320dfaa4f9700ecdca67d76e07d54","permalink":"https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","publishdate":"0001-01-01T00:00:00Z","readingtime":1,"relpermalink":"/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","summary":"预热权重功能让客户端机器能够根据服务端的相应权重进行流量的分发。该功能也常被用于集群内少数机器的启动场景。利用流量权重功能在短时间内对服务端","tags":null,"title":"预热权重","type":"projects","url":"/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/","wordcount":497}] \ No newline at end of file diff --git a/en/projects/sofa-boot/sofa-ark-readme/index.html b/en/projects/sofa-boot/sofa-ark-readme/index.html index 2cf76a1e..68e0df7c 100644 --- a/en/projects/sofa-boot/sofa-ark-readme/index.html +++ b/en/projects/sofa-boot/sofa-ark-readme/index.html @@ -1668,7 +1668,8 @@

    ## Product description SOFAArk is a light-weight，java based classloader isolation framework -open sourced by Ant Financial. Based on Fat Jar technology, the container can pack simple single-module Java applications or Spring Boot applications into a self-contained executable Fat Jar, known as an Ark package. When the java -jar command is used to start an Ark package embedded with the SOFAArk class isolation container, the SOFAArk container will start, and it then starts each Ark plugin and application.

    +open sourced by Ant Financial. Based on Fat Jar technology, the container can pack simple single-module Java applications or Spring Boot applications into a self-contained executable Fat Jar, known as an Ark package. When the java -jar command is used to start an Ark package embedded with the SOFAArk class isolation container, the SOFAArk container will start, and it then starts each Ark plugin and application. +If you want to merge multi app into one jvm, please go and refer to koupleless which based on SOFAArk; if you want to just isolate class by classLoader then you can read docs in this site, and focus on sofaArk Plugin.

    Background

    @@ -1684,7 +1685,9 @@

    How SOFAArk Works

    There are three concepts in SOFAArk: Ark Container, Ark-Plugin and Ark-Biz; they are organized as what the following graph shows:

    -

    image.png | center | 1310x1178

    +
    + +

    First of all, we explain what roles these concepts play;

    diff --git a/en/sitemap.xml b/en/sitemap.xml index de732305..35e8f159 100644 --- a/en/sitemap.xml +++ b/en/sitemap.xml @@ -4,14 +4,14 @@ https://sofastack.github.io/sofastack.tech/en/blog/hello-sofastack/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/mosn/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/occlum/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/seata/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/layotto/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/koupleless/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-ark/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/tags/cloud-native/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/en/tags/kubecon/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/en/activities/sofastack-cloud-native-workshop/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/tags/workshop/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/en/blog/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/en/categories/sofastack/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/en/tags/sofastack/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/en/guides/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/search/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/raft-introduction/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/activities/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-ide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-repackage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/user-stories/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-structure/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-biz/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-jar/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-classloader/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-plugin/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-startup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/async/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-model/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/common-model/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/dubbo-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/h2c-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/http-json/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-basic/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/benchmark-performance/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/guides/kc-serverless-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/guides/sofastack-quick-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/invoke-type/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/client-ext-metrics/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/client-invoke-flow/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/client-configuration/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/client-quick-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-invocation-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/protocol/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-compile/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/how-to-build/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-consul/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-contribution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-contribution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/contributing/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/notice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/notice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/notice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-app-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-filter/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-router/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/custom-thread-pool/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/dashboard-client/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-datasource/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-datasource/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/dependency-management/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/deployment/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/developer-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/development-use-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/peer-to-peer/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/consistency-raft-jraft/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/dubbo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-dubbo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-dubbo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/engine-architecture/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/extension-loader/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-api/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/faq/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/faq/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault-tolerance/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration-fault-tolerance/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-functions/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/features/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-ready/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/functional-interface-support/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/generic-invoke/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/getting-started-with-sofa-boot/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/getting-started-with-rpc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/graceful-shutdown/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/h2c/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/http/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/health-check/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/contributing/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/contribution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/contributing/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-contribution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-httpclient/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-httpclient/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/fault-hystrix/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-installation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-health-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-swagger/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-instruction/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-readme/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-readme/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-readme/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/sofa-mosn-readme/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jraft-rheakv-user-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jraft-user-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/java-sdk/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/jepson-test/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-lifecycle/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/invoke-chain-pass-data/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/load-balance/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-local/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/mosn/reference-performance-report010/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/occlum/reference-performance-report010/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/management-api/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/maven-dependency/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-model/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/modular-development/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofaboot-module/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/parallel-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-nacos/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/node-and-java-communicate/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-okhttp/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-okhttp/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-openfeign/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-openfeign/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/mosn/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/occlum/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-ark-plugin-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/print-traceid-spanid/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programming/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-run-samples/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-run-samples/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-samples/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/module-service/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/guides/kc-cloud-mesh-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/getting-started/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/quick-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-setup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-setup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/quick-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/componentaccess/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/quick-start-client-boot/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/quick-start-client-java/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-cors/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful-filter/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/restful/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/application-rpc-config/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/configuration-common/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-register-agent/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/related-links/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/mosn/release-notes/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/occlum/release-notes/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-release/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-release/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/release-node/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/release-log/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/release-notes/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/release-notes/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/report-to-zipkin/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-resttemplate/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-resttemplate/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/retry-invoke/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/road-map/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/ark-console/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/upgrade_2_5_x/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/upgrade_3_x/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/extension/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/guides/kc-sofastack-dynamic-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofaboot-profile/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/sofarpc-metrics/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/structure-intro/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-sofarpc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-sofa/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/sofatracer-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/utils/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/configuration/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/sampler/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/scale/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-acts/usage-script/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/guides/kc-seata-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/serialization/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/server-quick-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-extension-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/governance/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/publish-and-reference/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/rpc-config-xml-explain/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/skywalking-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/usage-of-mvc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/log-format-springmvc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-ark-terminology/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/explanation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/terminology/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/test/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/bolt-timeout/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-tracer/traceid-generated-rule/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/tracing-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-api/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-rpc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-jarslink-deploy-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/mosn/quick-start-run-with-sofamesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/occlum/quick-start-run-with-sofamesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-lookout/use-guide-registry/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-xml/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-annotation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-jraft/counter-example/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/classloader-isolation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/programing-sofa-boot-api/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-bolt/sofa-bolt-handbook/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/sofa-jarslink-version/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/version-release/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-dashboard/version-rule/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-registry/release-standard/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-boot/view-versions/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/provider-warmup-weight/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-x-protocol/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-mesh/pilot-zookeeper-adapter/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/en/projects/sofa-rpc/registry-zookeeper/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 Mon, 01 Jan 0001 00:00:00 +0000 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-readme/ - SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献； 在大型软件开发过程中，通常会推荐底层 + SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献，目前已经基于 SOFAArk 提供了模块化合并部署的 diff --git a/projects/sofa-boot/index.xml b/projects/sofa-boot/index.xml index 4782bbb7..a830e579 100644 --- a/projects/sofa-boot/index.xml +++ b/projects/sofa-boot/index.xml @@ -178,7 +178,7 @@ Mon, 01 Jan 0001 00:00:00 +0000 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-readme/ - SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献； 在大型软件开发过程中，通常会推荐底层 + SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献，目前已经基于 SOFAArk 提供了模块化合并部署的 diff --git a/projects/sofa-boot/sofa-ark-class-loader-delegation/index.html b/projects/sofa-boot/sofa-ark-class-loader-delegation/index.html index 397fb564..256a5b5d 100644 --- a/projects/sofa-boot/sofa-ark-class-loader-delegation/index.html +++ b/projects/sofa-boot/sofa-ark-class-loader-delegation/index.html @@ -1908,11 +1908,43 @@

    自定义委托加载优缺点

    对比与总结

    -

    ||依赖缺失排查成本|修复成本|模块改造成本|维护成本| -|-|-|-|-|-| -|强制加载|类转换失败或类查找失败，成本中|更新 plugin，发布基座，高|低|高| -|自定义委托加载 |类转换失败或类查找失败，成本中|更新模块依赖，如果基座依赖不足，需要更新基座并发布，中|高|低| -|自定义委托加载 + 基座预置依赖 + 模块自动瘦身|类转换失败或类查找失败，成本中|更新模块依赖，设置为provided，低|低|低|

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    委托加载类型依赖缺失排查成本修复成本模块改造成本维护成本
    强制加载类转换失败或类查找失败，成本中更新 plugin，发布基座，高低高
    自定义委托加载类转换失败或类查找失败，成本中更新模块依赖，如果基座依赖不足，需要更新基座并发布，中高低
    自定义委托加载 + 基座预置依赖 + 模块自动瘦身类转换失败或类查找失败，成本中更新模块依赖，设置为provided，低低低

    推荐自定义委托加载方式

    diff --git a/projects/sofa-boot/sofa-ark-migration-guide/index.html b/projects/sofa-boot/sofa-ark-migration-guide/index.html index d5478762..1971f03b 100644 --- a/projects/sofa-boot/sofa-ark-migration-guide/index.html +++ b/projects/sofa-boot/sofa-ark-migration-guide/index.html @@ -1837,11 +1837,13 @@

    -

    背景

    +

    背景

    SOFAArk 框架包含有三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下：

    -

    image.png | center | 1310x1178

    +
    + +

    每次应用启动时，首先运行 Ark 包，Ark Container 优先启动，容器自动解析 Ark 包中含有的 Ark Plugin 和 Ark Biz，并读取他们的配置信息，构建类和资源的加载索引表；然后使用独立的 ClassLoader 加载并按优先级配置依次启动；需要指出的是，Ark Plugin 优先 Ark Biz 被加载启动。 详细介绍可阅读： SOFAArk 介绍

    @@ -1852,7 +1854,7 @@

    背景

    详细介绍可阅读：Ark 容器类加载机制

    -

    问题一

    +

    问题一

    由于Ark Plugin的存在，插件在依赖层面的强管控，造成了一些问题 - 业务使用的依赖是被插件管控导出的，但是插件管控导出的版本与业务实际期望的版本不符（比如插件管控的版本是 1.0，而业务需要的是 2.0）。 @@ -1860,11 +1862,11 @@

    问题一

    - 业务接入成本，学习成本较高，问题排查困难，需要非常熟悉Ark类加载机制。 - 由于管控依赖的增长，Ark Plugin难以持续维护

    -

    问题二

    +

    问题二

    另外，由于Ark Container先于master biz启动，master biz的启动入口和springboot/sofaboot不一致，导致Ark master biz的的启动在研发运维中需要定制镜像，定制启动入口，造成研发运维困难。

    -

    SOFAArk2.0

    +

    SOFAArk2.0

    针对这些问题，我们尝试从框架层面去优化三层结构，沉淀出了SOFAArk2.0方案，整体优化思路和原则是 Ark Master Biz保持和原生springboot/sofaboot保持一致，弱化复杂的Ark Plugin类管控机制，将Ark Plugin与master biz合并。

    @@ -1873,9 +1875,9 @@

    SOFAArk2.0

    - Ark master biz和原生的springboot/sofaboot应用启动方式，类加载方式保持一致； - 优化Ark Biz启动速度；

    -

    升级方式

    +

    升级方式

    -

    版本升级

    +

    版本升级

    SOFAArk版本号第一位为大版本号，当为1.x.x时为SOFAArk1.0版，当为2.x.x时是SOFAArk2.0版，当前2.0版本已正式release，Release-Notes

    @@ -1891,9 +1893,9 @@

    版本升级

    </properties> -

    打包插件

    +

    打包插件

    -

    在SOFAArk1.0中使用sofa-ark-maven-plugin打包，在SOFAArk2.0中采用spring-boot原生打包插件spring-boot-maven-plugin打包

    +

    对于基座来说，在SOFAArk1.0中使用sofa-ark-maven-plugin打包，在SOFAArk2.0中采用spring-boot原生打包插件spring-boot-maven-plugin打包对于模块来说，则继续使用 sofa-ark-maven-plugin 来打包。

    <build>
     <plugins>
@@ -1950,9 +1952,9 @@ 
    打包插件
    
 </build>
    -

    运行启动

    +

    运行启动

    -

    方式一：IDEA启动

    +

    方式一：IDEA启动

    本地启动需要加上启动参数

    @@ -1960,7 +1962,7 @@

    方式一：IDEA启动

    -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName}

    -

    方式二：命令行启动

    +

    方式二：命令行启动

    Ark包是可执行Jar，可直接使用Java -jar的方式启动，先使用 mvn clean package 进行打包，打包得到 ${bizName}-${bizVersion}-ark-biz.jar，命令行启动

    @@ -1968,11 +1970,9 @@

    方式二：命令行启动

    java -jar -Dsofa.ark.embed.enable=true -Dcom.alipay.sofa.ark.master.biz=${bizName} ${bizName}-${bizVersion}-ark-biz.jar

    -

    示例工程

    - -

    SOFAArk1.0示例工程 ：SOFAArk1.0接入方式

    +

    示例工程

    -

    SOFAArk2.0示例工程 ：SOFAArk2.0接入方式

    +

    SOFAArk2.0示例工程 ：SOFAArk2.0接入方式。另外 SOFAArk 作为 Koupleless 类隔离组件，也可以查看 Koupleless 合并部署的 samples

    diff --git a/projects/sofa-boot/sofa-ark-readme/index.html b/projects/sofa-boot/sofa-ark-readme/index.html index 32ab7984..0aa87128 100644 --- a/projects/sofa-boot/sofa-ark-readme/index.html +++ b/projects/sofa-boot/sofa-ark-readme/index.html @@ -1848,7 +1848,7 @@

    -

    SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献；

    +

    SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服公司开源贡献，目前已经基于 SOFAArk 提供了模块化合并部署的完整解决方案 koupleless, 如果想要使用合并部署能力，建议查看 Koupleless 使用文档，如果只是想要使用的类隔离能力可以查看 SOFAArk Plugin 能力，继续查看本站点相关文档；

    在大型软件开发过程中，通常会推荐底层功能插件化，业务功能模块化的开发模式，以期达到低耦合、高内聚、功能复用的优点。基于此，SOFAArk 提供了一套较为规范化的插件化、模块化的开发方案，产品能力主要包括：

    @@ -1864,7 +1864,7 @@

    场景

    -

    包冲突

    +

    包冲突

    日常使用 Java 开发，常常会遇到包依赖冲突的问题，尤其当应用变得臃肿庞大，包冲突的问题也会变得更加棘手，导致各种各样的报错，例如 LinkageError, NoSuchMethodError 等；实际开发中，可以采用多种方法来解决包冲突问题，比较常见的是类似 Spring Boot 的做法，统一管理应用所有依赖包的版本，保证这些三方包不存在依赖冲突；这种做法只能有效避免包冲突问题，不能根本上解决包冲突的问题；如果某个应用的确需要在运行时使用两个相互冲突的包，例如 protobuf2 和 protobuf3，那么类似 Spring Boot 的做法依然解决不了问题。

    @@ -1878,15 +1878,15 @@

    包冲突

    此时，即可使用 SOFAArk 解决该依赖冲突问题；只需要把 A 和版本为 0.1 的 C 包一起打包成一个 Ark 插件，然后让应用工程引入该插件依赖即可；

    -

    合并部署

    +

    合并部署

    复杂项目通常需要跨团队协作开发，各自负责不同的组件，而众所周知，协调跨团队合作开发会遇到不少问题；比如各自技术栈不统一导致的依赖冲突，又比如往同一个 Git 仓库提交代码常常导致 merge 冲突。因此，如果能让每个团队将负责的功能组件当成一个个单独的应用开发，运行时合并部署，通过统一的编程界面交互，那么将极大的提升开发效率及应用可扩展性。SOFAArk 提出了一种特殊的包结构 – Ark Biz，用户可以使用 Maven 插件将应用打包成 Biz，允许多 Biz 在 SOFAArk 容器之上合并部署，并通过统一的编程界面交互。

    -
    静态合并部署
    +

    静态合并部署

    SOFAArk 提供了静态合并部署能力，在开发阶段，应用可以将其他应用打成的 Biz 包通过 Maven 依赖的方式引入，而当自身被打成可执行 Fat Jar 时，可以将其他应用 Biz 包一并打入，启动时，则会根据优先级依次启动各应用。每个 Biz 使用独立的 BizClassLoader 加载，不需要考虑相互依赖冲突问题，Biz 之间则通过 SofaService/SofaReference JVM 服务进行交互。

    -
    动态合并部署
    +

    动态合并部署

    动态合并部署区别于静态合并部署最大的一点是，运行时通过 API 或者配置中心（Zookeeper）来控制 Biz 的部署和卸载。动态合并部署的设计理念图如下：

    @@ -1898,7 +1898,9 @@

    原理

    SOFAArk 包含三个概念，Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下:

    -

    image.png | center | 1310x1178

    +
    + +

    在介绍这三个概念之前，先介绍上述 Ark 包概念；Ark 包是满足特定目录格式要求的可运行 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将单个或多个应用打包成标准格式的 Ark 包；使用 java -jar 命令即可在 SOFAArk 容器之上启动所有应用；Ark 包通常包含 Ark Container、Ark Plugin 和 Ark Biz；以下我们针对这三个概念简单做下名词解释：

    diff --git a/sitemap.xml b/sitemap.xml index f693a3b7..aad75a58 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -4,14 +4,14 @@ https://sofastack.github.io/sofastack.tech/en/sitemap.xml - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 https://sofastack.github.io/sofastack.tech/zh/sitemap.xml - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 diff --git a/tags/1024/index.html b/tags/1024/index.html index 5abf577c..94acc62d 100644 --- a/tags/1024/index.html +++ b/tags/1024/index.html @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/api-gateway/index.html b/tags/api-gateway/index.html index 99264ba8..d857641a 100644 --- a/tags/api-gateway/index.html +++ b/tags/api-gateway/index.html @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/cafedeployment/index.html b/tags/cafedeployment/index.html index a60dadcd..aa87c059 100644 --- a/tags/cafedeployment/index.html +++ b/tags/cafedeployment/index.html @@ -278,7 +278,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -314,7 +314,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -400,7 +400,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -438,7 +438,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/cafedeployment/index.xml b/tags/cafedeployment/index.xml index 2990cb7e..f54516d1 100644 --- a/tags/cafedeployment/index.xml +++ b/tags/cafedeployment/index.xml @@ -1,9 +1,9 @@ - CAFEDeployment on SOFAStack + CafeDeployment on SOFAStack https://sofastack.github.io/sofastack.tech/tags/cafedeployment/ - Recent content in CAFEDeployment on SOFAStack + Recent content in CafeDeployment on SOFAStack Hugo -- gohugo.io zh-CN Thu, 18 Jul 2019 21:00:00 +0800 diff --git a/tags/cloud-native/index.html b/tags/cloud-native/index.html index 6929a662..506b6deb 100644 --- a/tags/cloud-native/index.html +++ b/tags/cloud-native/index.html @@ -262,7 +262,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -298,7 +298,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -384,7 +384,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -422,7 +422,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/cncf/index.html b/tags/cncf/index.html index 399379b9..c48279a1 100644 --- a/tags/cncf/index.html +++ b/tags/cncf/index.html @@ -249,7 +249,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -285,7 +285,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -371,7 +371,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -409,7 +409,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/db-mesh/index.html b/tags/db-mesh/index.html index fbcce2ee..5dd2be75 100644 --- a/tags/db-mesh/index.html +++ b/tags/db-mesh/index.html @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/dragonfly/index.html b/tags/dragonfly/index.html index 4a76e544..de10f207 100644 --- a/tags/dragonfly/index.html +++ b/tags/dragonfly/index.html @@ -249,7 +249,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -285,7 +285,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -371,7 +371,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -409,7 +409,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/elasticdl/index.html b/tags/elasticdl/index.html index ebe60b80..e53326e5 100644 --- a/tags/elasticdl/index.html +++ b/tags/elasticdl/index.html @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/http/3/index.html b/tags/http/3/index.html index 9321cd32..07b412d3 100644 --- a/tags/http/3/index.html +++ b/tags/http/3/index.html @@ -278,7 +278,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -314,7 +314,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -400,7 +400,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -438,7 +438,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/http/quic/index.html b/tags/http/quic/index.html index 697941fe..3ec4e9fb 100644 --- a/tags/http/quic/index.html +++ b/tags/http/quic/index.html @@ -371,7 +371,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -407,7 +407,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -493,7 +493,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -531,7 +531,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/kata-container/index.html b/tags/kata-container/index.html index 2d0a88fa..161bcddb 100644 --- a/tags/kata-container/index.html +++ b/tags/kata-container/index.html @@ -276,7 +276,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -312,7 +312,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -398,7 +398,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -436,7 +436,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/kata-containers/index.html b/tags/kata-containers/index.html index d57f180a..9aeaee39 100644 --- a/tags/kata-containers/index.html +++ b/tags/kata-containers/index.html @@ -342,7 +342,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -378,7 +378,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -464,7 +464,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -502,7 +502,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/knative/index.html b/tags/knative/index.html index 4a558fe6..bcf03f1a 100644 --- a/tags/knative/index.html +++ b/tags/knative/index.html @@ -278,7 +278,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -314,7 +314,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -400,7 +400,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -438,7 +438,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/kubecon/index.html b/tags/kubecon/index.html index d2c59663..90bc6af1 100644 --- a/tags/kubecon/index.html +++ b/tags/kubecon/index.html @@ -262,7 +262,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -298,7 +298,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -384,7 +384,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -422,7 +422,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/kubernetes/index.html b/tags/kubernetes/index.html index bbd802e7..0df41132 100644 --- a/tags/kubernetes/index.html +++ b/tags/kubernetes/index.html @@ -516,7 +516,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -552,7 +552,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -638,7 +638,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -676,7 +676,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/meetup/index.html b/tags/meetup/index.html index 3cb3db23..2c135b28 100644 --- a/tags/meetup/index.html +++ b/tags/meetup/index.html @@ -280,7 +280,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -316,7 +316,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -402,7 +402,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -440,7 +440,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/mosn/index.html b/tags/mosn/index.html index 99ca97a7..567e7a50 100644 --- a/tags/mosn/index.html +++ b/tags/mosn/index.html @@ -533,7 +533,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -569,7 +569,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -655,7 +655,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -693,7 +693,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/mosn/page/2/index.html b/tags/mosn/page/2/index.html index 5b71d6c1..ab759370 100644 --- a/tags/mosn/page/2/index.html +++ b/tags/mosn/page/2/index.html @@ -287,7 +287,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -323,7 +323,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -409,7 +409,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -447,7 +447,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/nydus/index.html b/tags/nydus/index.html index 8faeb8ee..b6eb3ab2 100644 --- a/tags/nydus/index.html +++ b/tags/nydus/index.html @@ -249,7 +249,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -285,7 +285,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -371,7 +371,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -409,7 +409,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/occlum/index.html b/tags/occlum/index.html index d00989ee..dc5ef0af 100644 --- a/tags/occlum/index.html +++ b/tags/occlum/index.html @@ -278,7 +278,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -314,7 +314,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -400,7 +400,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -438,7 +438,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/rpc-\346\241\206\346\236\266\350\256\276\350\256\241\347\232\204\350\200\203\345\222\214\351\207\217/index.html" "b/tags/rpc-\346\241\206\346\236\266\350\256\276\350\256\241\347\232\204\350\200\203\345\222\214\351\207\217/index.html" index fe3624b2..9b652ad7 100644 --- "a/tags/rpc-\346\241\206\346\236\266\350\256\276\350\256\241\347\232\204\350\200\203\345\222\214\351\207\217/index.html" +++ "b/tags/rpc-\346\241\206\346\236\266\350\256\276\350\256\241\347\232\204\350\200\203\345\222\214\351\207\217/index.html" @@ -249,7 +249,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -285,7 +285,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -371,7 +371,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -409,7 +409,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/seata/index.html b/tags/seata/index.html index 6be88e5f..139db8b0 100644 --- a/tags/seata/index.html +++ b/tags/seata/index.html @@ -539,7 +539,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -575,7 +575,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -661,7 +661,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -699,7 +699,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/seata/index.xml b/tags/seata/index.xml index f139aa8e..cd434cd1 100644 --- a/tags/seata/index.xml +++ b/tags/seata/index.xml @@ -1,9 +1,9 @@ - Seata on SOFAStack + seata on SOFAStack https://sofastack.github.io/sofastack.tech/tags/seata/ - Recent content in Seata on SOFAStack + Recent content in seata on SOFAStack Hugo -- gohugo.io zh-CN Thu, 09 Jan 2020 21:00:00 +0800 diff --git a/tags/seata/page/2/index.html b/tags/seata/page/2/index.html index 22f56e52..03928b20 100644 --- a/tags/seata/page/2/index.html +++ b/tags/seata/page/2/index.html @@ -314,7 +314,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -350,7 +350,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -436,7 +436,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -474,7 +474,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/serverless/index.html b/tags/serverless/index.html index 611f5de2..13627f27 100644 --- a/tags/serverless/index.html +++ b/tags/serverless/index.html @@ -346,7 +346,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -382,7 +382,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -468,7 +468,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -506,7 +506,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/serverlesstask/index.html b/tags/serverlesstask/index.html index 0b49ef93..e383ee52 100644 --- a/tags/serverlesstask/index.html +++ b/tags/serverlesstask/index.html @@ -253,7 +253,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -289,7 +289,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -375,7 +375,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -413,7 +413,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/service-mesh-meetup/index.html b/tags/service-mesh-meetup/index.html index 31e50e43..1f299266 100644 --- a/tags/service-mesh-meetup/index.html +++ b/tags/service-mesh-meetup/index.html @@ -280,7 +280,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -316,7 +316,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -402,7 +402,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -440,7 +440,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/service-mesh-virtual-meetup/index.html b/tags/service-mesh-virtual-meetup/index.html index 0b309814..38d01f7f 100644 --- a/tags/service-mesh-virtual-meetup/index.html +++ b/tags/service-mesh-virtual-meetup/index.html @@ -309,7 +309,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -345,7 +345,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -431,7 +431,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -469,7 +469,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/service-mesh-webinar/index.html b/tags/service-mesh-webinar/index.html index 2e737ed3..1b9961af 100644 --- a/tags/service-mesh-webinar/index.html +++ b/tags/service-mesh-webinar/index.html @@ -309,7 +309,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -345,7 +345,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -431,7 +431,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -469,7 +469,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/service-mesh-\350\220\275\345\234\260\345\256\236\350\267\265/index.html" "b/tags/service-mesh-\350\220\275\345\234\260\345\256\236\350\267\265/index.html" index 7df27c0e..160ef91b 100644 --- "a/tags/service-mesh-\350\220\275\345\234\260\345\256\236\350\267\265/index.html" +++ "b/tags/service-mesh-\350\220\275\345\234\260\345\256\236\350\267\265/index.html" @@ -533,7 +533,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -569,7 +569,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -655,7 +655,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -693,7 +693,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/service-mesh-\350\220\275\345\234\260\345\256\236\350\267\265/page/2/index.html" "b/tags/service-mesh-\350\220\275\345\234\260\345\256\236\350\267\265/page/2/index.html" index e81108de..ab3c2053 100644 --- "a/tags/service-mesh-\350\220\275\345\234\260\345\256\236\350\267\265/page/2/index.html" +++ "b/tags/service-mesh-\350\220\275\345\234\260\345\256\236\350\267\265/page/2/index.html" @@ -285,7 +285,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -321,7 +321,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -407,7 +407,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -445,7 +445,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/service-mesh/index.html b/tags/service-mesh/index.html index b1707375..23133241 100644 --- a/tags/service-mesh/index.html +++ b/tags/service-mesh/index.html @@ -537,7 +537,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -573,7 +573,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -659,7 +659,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -697,7 +697,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/service-mesh/page/2/index.html b/tags/service-mesh/page/2/index.html index abbd834f..abcb2ebb 100644 --- a/tags/service-mesh/page/2/index.html +++ b/tags/service-mesh/page/2/index.html @@ -531,7 +531,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -567,7 +567,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -653,7 +653,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -691,7 +691,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/service-mesh/page/3/index.html b/tags/service-mesh/page/3/index.html index 765e7e27..76bcdb14 100644 --- a/tags/service-mesh/page/3/index.html +++ b/tags/service-mesh/page/3/index.html @@ -533,7 +533,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -569,7 +569,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -655,7 +655,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -693,7 +693,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/service-mesh/page/4/index.html b/tags/service-mesh/page/4/index.html index 333e89a7..1d1bef3b 100644 --- a/tags/service-mesh/page/4/index.html +++ b/tags/service-mesh/page/4/index.html @@ -529,7 +529,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -565,7 +565,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -651,7 +651,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -689,7 +689,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/service-mesh/page/5/index.html b/tags/service-mesh/page/5/index.html index e5ccf195..36776dac 100644 --- a/tags/service-mesh/page/5/index.html +++ b/tags/service-mesh/page/5/index.html @@ -407,7 +407,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -443,7 +443,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -529,7 +529,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -567,7 +567,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/sidecar-\345\256\271\345\231\250/index.html" "b/tags/sidecar-\345\256\271\345\231\250/index.html" index 581d5887..8d486224 100644 --- "a/tags/sidecar-\345\256\271\345\231\250/index.html" +++ "b/tags/sidecar-\345\256\271\345\231\250/index.html" @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/index.html b/tags/sofa-weekly/index.html index afd073c8..a7968d0c 100644 --- a/tags/sofa-weekly/index.html +++ b/tags/sofa-weekly/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/10/index.html b/tags/sofa-weekly/page/10/index.html index 725a72a1..a8c469ae 100644 --- a/tags/sofa-weekly/page/10/index.html +++ b/tags/sofa-weekly/page/10/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/11/index.html b/tags/sofa-weekly/page/11/index.html index 35a1f8cb..979773f2 100644 --- a/tags/sofa-weekly/page/11/index.html +++ b/tags/sofa-weekly/page/11/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/12/index.html b/tags/sofa-weekly/page/12/index.html index 91ccf1dc..668736cb 100644 --- a/tags/sofa-weekly/page/12/index.html +++ b/tags/sofa-weekly/page/12/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/13/index.html b/tags/sofa-weekly/page/13/index.html index ab5c1835..cde67952 100644 --- a/tags/sofa-weekly/page/13/index.html +++ b/tags/sofa-weekly/page/13/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/14/index.html b/tags/sofa-weekly/page/14/index.html index ed2cc066..8beb5535 100644 --- a/tags/sofa-weekly/page/14/index.html +++ b/tags/sofa-weekly/page/14/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/15/index.html b/tags/sofa-weekly/page/15/index.html index cb33545a..28664ebe 100644 --- a/tags/sofa-weekly/page/15/index.html +++ b/tags/sofa-weekly/page/15/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/16/index.html b/tags/sofa-weekly/page/16/index.html index 5ba44955..253e05ae 100644 --- a/tags/sofa-weekly/page/16/index.html +++ b/tags/sofa-weekly/page/16/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/17/index.html b/tags/sofa-weekly/page/17/index.html index c03c7bd8..4f475d28 100644 --- a/tags/sofa-weekly/page/17/index.html +++ b/tags/sofa-weekly/page/17/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/18/index.html b/tags/sofa-weekly/page/18/index.html index 3a1dfa4c..c8442cdc 100644 --- a/tags/sofa-weekly/page/18/index.html +++ b/tags/sofa-weekly/page/18/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/19/index.html b/tags/sofa-weekly/page/19/index.html index 235a644d..2339f7bb 100644 --- a/tags/sofa-weekly/page/19/index.html +++ b/tags/sofa-weekly/page/19/index.html @@ -484,7 +484,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -520,7 +520,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -606,7 +606,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -644,7 +644,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/2/index.html b/tags/sofa-weekly/page/2/index.html index 6c04c220..5cb3a063 100644 --- a/tags/sofa-weekly/page/2/index.html +++ b/tags/sofa-weekly/page/2/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/3/index.html b/tags/sofa-weekly/page/3/index.html index cee5cf95..2e71db05 100644 --- a/tags/sofa-weekly/page/3/index.html +++ b/tags/sofa-weekly/page/3/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/4/index.html b/tags/sofa-weekly/page/4/index.html index 3a8f926d..dfe2143a 100644 --- a/tags/sofa-weekly/page/4/index.html +++ b/tags/sofa-weekly/page/4/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/5/index.html b/tags/sofa-weekly/page/5/index.html index 8555c3f2..dd363038 100644 --- a/tags/sofa-weekly/page/5/index.html +++ b/tags/sofa-weekly/page/5/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/6/index.html b/tags/sofa-weekly/page/6/index.html index 21c67739..18815de0 100644 --- a/tags/sofa-weekly/page/6/index.html +++ b/tags/sofa-weekly/page/6/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/7/index.html b/tags/sofa-weekly/page/7/index.html index 1f36ef1f..82f96c08 100644 --- a/tags/sofa-weekly/page/7/index.html +++ b/tags/sofa-weekly/page/7/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/8/index.html b/tags/sofa-weekly/page/8/index.html index c0d67673..5bea4ea6 100644 --- a/tags/sofa-weekly/page/8/index.html +++ b/tags/sofa-weekly/page/8/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa-weekly/page/9/index.html b/tags/sofa-weekly/page/9/index.html index 9699c568..de020f52 100644 --- a/tags/sofa-weekly/page/9/index.html +++ b/tags/sofa-weekly/page/9/index.html @@ -513,7 +513,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -549,7 +549,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -635,7 +635,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -673,7 +673,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofa/index.html b/tags/sofa/index.html index 563115ce..ac23a9e1 100644 --- a/tags/sofa/index.html +++ b/tags/sofa/index.html @@ -303,7 +303,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -339,7 +339,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -425,7 +425,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -463,7 +463,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofaacts/index.html b/tags/sofaacts/index.html index 81987634..1bfaacd2 100644 --- a/tags/sofaacts/index.html +++ b/tags/sofaacts/index.html @@ -311,7 +311,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -347,7 +347,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -433,7 +433,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -471,7 +471,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofaark/index.html b/tags/sofaark/index.html index 2a8e54c4..9a468909 100644 --- a/tags/sofaark/index.html +++ b/tags/sofaark/index.html @@ -541,7 +541,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -577,7 +577,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -663,7 +663,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -701,7 +701,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofaark/page/2/index.html b/tags/sofaark/page/2/index.html index da263c10..49e8abff 100644 --- a/tags/sofaark/page/2/index.html +++ b/tags/sofaark/page/2/index.html @@ -260,7 +260,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -296,7 +296,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -382,7 +382,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -420,7 +420,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofaarklab/index.html b/tags/sofaarklab/index.html index 91b5a16d..1e310be6 100644 --- a/tags/sofaarklab/index.html +++ b/tags/sofaarklab/index.html @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofabolt/index.html b/tags/sofabolt/index.html index 9e6ba79b..031c4489 100644 --- a/tags/sofabolt/index.html +++ b/tags/sofabolt/index.html @@ -463,7 +463,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -499,7 +499,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -585,7 +585,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -623,7 +623,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofaboot/index.html b/tags/sofaboot/index.html index 7d38ecfb..a9e96872 100644 --- a/tags/sofaboot/index.html +++ b/tags/sofaboot/index.html @@ -552,7 +552,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -588,7 +588,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -674,7 +674,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -712,7 +712,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofachannel/index.html b/tags/sofachannel/index.html index db9da536..4500897b 100644 --- a/tags/sofachannel/index.html +++ b/tags/sofachannel/index.html @@ -543,7 +543,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -579,7 +579,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -665,7 +665,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -703,7 +703,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofachannel/page/2/index.html b/tags/sofachannel/page/2/index.html index d0ccbb3d..85d657db 100644 --- a/tags/sofachannel/page/2/index.html +++ b/tags/sofachannel/page/2/index.html @@ -533,7 +533,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -569,7 +569,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -655,7 +655,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -693,7 +693,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofachannel/page/3/index.html b/tags/sofachannel/page/3/index.html index 29802284..8ae40323 100644 --- a/tags/sofachannel/page/3/index.html +++ b/tags/sofachannel/page/3/index.html @@ -537,7 +537,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -573,7 +573,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -659,7 +659,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -697,7 +697,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofachannel/page/4/index.html b/tags/sofachannel/page/4/index.html index e657d27a..73cecbb9 100644 --- a/tags/sofachannel/page/4/index.html +++ b/tags/sofachannel/page/4/index.html @@ -533,7 +533,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -569,7 +569,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -655,7 +655,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -693,7 +693,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofachannel/page/5/index.html b/tags/sofachannel/page/5/index.html index cc70bd78..4f03c366 100644 --- a/tags/sofachannel/page/5/index.html +++ b/tags/sofachannel/page/5/index.html @@ -549,7 +549,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -585,7 +585,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -671,7 +671,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -709,7 +709,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofadashboard/index.html b/tags/sofadashboard/index.html index 08aff9e2..94c1d85c 100644 --- a/tags/sofadashboard/index.html +++ b/tags/sofadashboard/index.html @@ -278,7 +278,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -314,7 +314,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -400,7 +400,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -438,7 +438,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofaenclave/index.html b/tags/sofaenclave/index.html index 09edd0e4..6a56fd65 100644 --- a/tags/sofaenclave/index.html +++ b/tags/sofaenclave/index.html @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/sofajraft-\347\211\271\346\200\247\350\247\243\346\236\220/index.html" "b/tags/sofajraft-\347\211\271\346\200\247\350\247\243\346\236\220/index.html" index 3e88e135..d97942db 100644 --- "a/tags/sofajraft-\347\211\271\346\200\247\350\247\243\346\236\220/index.html" +++ "b/tags/sofajraft-\347\211\271\346\200\247\350\247\243\346\236\220/index.html" @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofajraft/index.html b/tags/sofajraft/index.html index 45a75126..348abfb9 100644 --- a/tags/sofajraft/index.html +++ b/tags/sofajraft/index.html @@ -543,7 +543,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -579,7 +579,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -665,7 +665,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -703,7 +703,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofajraft/page/2/index.html b/tags/sofajraft/page/2/index.html index 1a6c2693..8a65fc71 100644 --- a/tags/sofajraft/page/2/index.html +++ b/tags/sofajraft/page/2/index.html @@ -388,7 +388,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -424,7 +424,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -510,7 +510,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -548,7 +548,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofalab/index.html b/tags/sofalab/index.html index bf675f44..78a3aa6a 100644 --- a/tags/sofalab/index.html +++ b/tags/sofalab/index.html @@ -551,7 +551,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -587,7 +587,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -673,7 +673,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -711,7 +711,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofalab/page/2/index.html b/tags/sofalab/page/2/index.html index 7cc986db..efafaed8 100644 --- a/tags/sofalab/page/2/index.html +++ b/tags/sofalab/page/2/index.html @@ -549,7 +549,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -585,7 +585,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -671,7 +671,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -709,7 +709,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofalab/page/3/index.html b/tags/sofalab/page/3/index.html index 46991d7d..bda2c9da 100644 --- a/tags/sofalab/page/3/index.html +++ b/tags/sofalab/page/3/index.html @@ -579,7 +579,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -615,7 +615,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -701,7 +701,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -739,7 +739,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofalab/page/4/index.html b/tags/sofalab/page/4/index.html index 97b393d6..d96edea6 100644 --- a/tags/sofalab/page/4/index.html +++ b/tags/sofalab/page/4/index.html @@ -569,7 +569,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -605,7 +605,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -691,7 +691,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -729,7 +729,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofalab/page/5/index.html b/tags/sofalab/page/5/index.html index 71bad520..85c4aae5 100644 --- a/tags/sofalab/page/5/index.html +++ b/tags/sofalab/page/5/index.html @@ -454,7 +454,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -490,7 +490,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -576,7 +576,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -614,7 +614,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofalookout/index.html b/tags/sofalookout/index.html index e960641b..e86dab59 100644 --- a/tags/sofalookout/index.html +++ b/tags/sofalookout/index.html @@ -307,7 +307,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -343,7 +343,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -429,7 +429,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -467,7 +467,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofameetup/index.html b/tags/sofameetup/index.html index d14ceeab..2279220b 100644 --- a/tags/sofameetup/index.html +++ b/tags/sofameetup/index.html @@ -515,7 +515,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -551,7 +551,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -637,7 +637,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -675,7 +675,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofameetup/page/2/index.html b/tags/sofameetup/page/2/index.html index fb784fcb..23ead1fa 100644 --- a/tags/sofameetup/page/2/index.html +++ b/tags/sofameetup/page/2/index.html @@ -512,7 +512,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -548,7 +548,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -634,7 +634,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -672,7 +672,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofamesh/index.html b/tags/sofamesh/index.html index 5db9cb5b..66190d24 100644 --- a/tags/sofamesh/index.html +++ b/tags/sofamesh/index.html @@ -332,7 +332,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -368,7 +368,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -454,7 +454,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -492,7 +492,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofaregistry/index.html b/tags/sofaregistry/index.html index a5a98419..9b4f2d15 100644 --- a/tags/sofaregistry/index.html +++ b/tags/sofaregistry/index.html @@ -535,7 +535,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -571,7 +571,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -657,7 +657,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -695,7 +695,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofaregistry/page/2/index.html b/tags/sofaregistry/page/2/index.html index 317c8d7f..62b34679 100644 --- a/tags/sofaregistry/page/2/index.html +++ b/tags/sofaregistry/page/2/index.html @@ -417,7 +417,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -453,7 +453,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -539,7 +539,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -577,7 +577,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofarpc/index.html b/tags/sofarpc/index.html index f1860395..5f0f26b5 100644 --- a/tags/sofarpc/index.html +++ b/tags/sofarpc/index.html @@ -551,7 +551,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -587,7 +587,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -673,7 +673,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -711,7 +711,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofarpc/page/2/index.html b/tags/sofarpc/page/2/index.html index 6a884997..7f23b043 100644 --- a/tags/sofarpc/page/2/index.html +++ b/tags/sofarpc/page/2/index.html @@ -553,7 +553,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -589,7 +589,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -675,7 +675,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -713,7 +713,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofarpc/page/3/index.html b/tags/sofarpc/page/3/index.html index dcba27bc..9143e979 100644 --- a/tags/sofarpc/page/3/index.html +++ b/tags/sofarpc/page/3/index.html @@ -256,7 +256,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -292,7 +292,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -378,7 +378,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -416,7 +416,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/sofastack-\345\274\200\346\272\220\344\271\213\345\244\217/index.html" "b/tags/sofastack-\345\274\200\346\272\220\344\271\213\345\244\217/index.html" index 78ac2fec..ceb46884 100644 --- "a/tags/sofastack-\345\274\200\346\272\220\344\271\213\345\244\217/index.html" +++ "b/tags/sofastack-\345\274\200\346\272\220\344\271\213\345\244\217/index.html" @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/index.html b/tags/sofastack/index.html index a98b1f64..0ac3ed97 100644 --- a/tags/sofastack/index.html +++ b/tags/sofastack/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/10/index.html b/tags/sofastack/page/10/index.html index 4ac2330f..6b52511b 100644 --- a/tags/sofastack/page/10/index.html +++ b/tags/sofastack/page/10/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/11/index.html b/tags/sofastack/page/11/index.html index 82ffc425..92cab09d 100644 --- a/tags/sofastack/page/11/index.html +++ b/tags/sofastack/page/11/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/12/index.html b/tags/sofastack/page/12/index.html index 314be6a9..b31cd35f 100644 --- a/tags/sofastack/page/12/index.html +++ b/tags/sofastack/page/12/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/13/index.html b/tags/sofastack/page/13/index.html index 43536958..d8511088 100644 --- a/tags/sofastack/page/13/index.html +++ b/tags/sofastack/page/13/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/14/index.html b/tags/sofastack/page/14/index.html index c1db223a..5bb7b83b 100644 --- a/tags/sofastack/page/14/index.html +++ b/tags/sofastack/page/14/index.html @@ -538,7 +538,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -574,7 +574,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -660,7 +660,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -698,7 +698,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/15/index.html b/tags/sofastack/page/15/index.html index 5f2500dc..ac38b79b 100644 --- a/tags/sofastack/page/15/index.html +++ b/tags/sofastack/page/15/index.html @@ -538,7 +538,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -574,7 +574,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -660,7 +660,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -698,7 +698,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/16/index.html b/tags/sofastack/page/16/index.html index a19cfc8b..f16d9076 100644 --- a/tags/sofastack/page/16/index.html +++ b/tags/sofastack/page/16/index.html @@ -263,7 +263,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -299,7 +299,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -385,7 +385,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -423,7 +423,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/2/index.html b/tags/sofastack/page/2/index.html index 1ae0e33a..7880467d 100644 --- a/tags/sofastack/page/2/index.html +++ b/tags/sofastack/page/2/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/3/index.html b/tags/sofastack/page/3/index.html index 5fa0e1eb..f2222b52 100644 --- a/tags/sofastack/page/3/index.html +++ b/tags/sofastack/page/3/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/4/index.html b/tags/sofastack/page/4/index.html index 027ba195..0cfbac60 100644 --- a/tags/sofastack/page/4/index.html +++ b/tags/sofastack/page/4/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/5/index.html b/tags/sofastack/page/5/index.html index 6688e22b..2bb6cfa5 100644 --- a/tags/sofastack/page/5/index.html +++ b/tags/sofastack/page/5/index.html @@ -522,7 +522,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -558,7 +558,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -644,7 +644,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -682,7 +682,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/6/index.html b/tags/sofastack/page/6/index.html index 28b3ba8d..93c7ae72 100644 --- a/tags/sofastack/page/6/index.html +++ b/tags/sofastack/page/6/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/7/index.html b/tags/sofastack/page/7/index.html index 02368b04..a75eba4b 100644 --- a/tags/sofastack/page/7/index.html +++ b/tags/sofastack/page/7/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/8/index.html b/tags/sofastack/page/8/index.html index d0605d8e..c625c8c5 100644 --- a/tags/sofastack/page/8/index.html +++ b/tags/sofastack/page/8/index.html @@ -526,7 +526,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -562,7 +562,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -648,7 +648,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -686,7 +686,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastack/page/9/index.html b/tags/sofastack/page/9/index.html index f0e3fad3..8bc213e6 100644 --- a/tags/sofastack/page/9/index.html +++ b/tags/sofastack/page/9/index.html @@ -524,7 +524,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -560,7 +560,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -646,7 +646,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -684,7 +684,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofastak/index.html b/tags/sofastak/index.html index 834bdb84..9d462581 100644 --- a/tags/sofastak/index.html +++ b/tags/sofastak/index.html @@ -274,7 +274,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -310,7 +310,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -396,7 +396,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -434,7 +434,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofatalk/index.html b/tags/sofatalk/index.html index 49478898..a8569d82 100644 --- a/tags/sofatalk/index.html +++ b/tags/sofatalk/index.html @@ -249,7 +249,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -285,7 +285,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -371,7 +371,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -409,7 +409,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sofatracer/index.html b/tags/sofatracer/index.html index ab9bdfe2..a7986fb3 100644 --- a/tags/sofatracer/index.html +++ b/tags/sofatracer/index.html @@ -492,7 +492,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -528,7 +528,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -614,7 +614,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -652,7 +652,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/springboot/index.html b/tags/springboot/index.html index 0b68d8ff..3c6ac272 100644 --- a/tags/springboot/index.html +++ b/tags/springboot/index.html @@ -253,7 +253,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -289,7 +289,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -375,7 +375,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -413,7 +413,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/sqlflow/index.html b/tags/sqlflow/index.html index aa635297..361edfdd 100644 --- a/tags/sqlflow/index.html +++ b/tags/sqlflow/index.html @@ -303,7 +303,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -339,7 +339,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -425,7 +425,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -463,7 +463,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/summer-2021/index.html b/tags/summer-2021/index.html index bfd52d55..f04831b1 100644 --- a/tags/summer-2021/index.html +++ b/tags/summer-2021/index.html @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/workshop/index.html b/tags/workshop/index.html index b81e4b0c..76f4d77a 100644 --- a/tags/workshop/index.html +++ b/tags/workshop/index.html @@ -262,7 +262,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -298,7 +298,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -384,7 +384,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -422,7 +422,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/tags/zsearch/index.html b/tags/zsearch/index.html index 73559c0b..c04ca831 100644 --- a/tags/zsearch/index.html +++ b/tags/zsearch/index.html @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\344\272\221\345\216\237\347\224\237/index.html" "b/tags/\344\272\221\345\216\237\347\224\237/index.html" index 57929e80..20cf1d04 100644 --- "a/tags/\344\272\221\345\216\237\347\224\237/index.html" +++ "b/tags/\344\272\221\345\216\237\347\224\237/index.html" @@ -363,7 +363,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -399,7 +399,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -485,7 +485,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -523,7 +523,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\344\273\273\345\212\241\350\260\203\345\272\246/index.html" "b/tags/\344\273\273\345\212\241\350\260\203\345\272\246/index.html" index 0b49ef93..e383ee52 100644 --- "a/tags/\344\273\273\345\212\241\350\260\203\345\272\246/index.html" +++ "b/tags/\344\273\273\345\212\241\350\260\203\345\272\246/index.html" @@ -253,7 +253,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -289,7 +289,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -375,7 +375,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -413,7 +413,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\344\275\240\347\232\204\345\274\200\346\272\220\345\205\245\351\227\250\346\214\207\345\215\227/index.html" "b/tags/\344\275\240\347\232\204\345\274\200\346\272\220\345\205\245\351\227\250\346\214\207\345\215\227/index.html" index 1f30502f..c85b4fdd 100644 --- "a/tags/\344\275\240\347\232\204\345\274\200\346\272\220\345\205\245\351\227\250\346\214\207\345\215\227/index.html" +++ "b/tags/\344\275\240\347\232\204\345\274\200\346\272\220\345\205\245\351\227\250\346\214\207\345\215\227/index.html" @@ -282,7 +282,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -318,7 +318,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -404,7 +404,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -442,7 +442,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\210\206\345\270\203\345\274\217/index.html" "b/tags/\345\210\206\345\270\203\345\274\217/index.html" index 437cc3cb..ecb9ea0a 100644 --- "a/tags/\345\210\206\345\270\203\345\274\217/index.html" +++ "b/tags/\345\210\206\345\270\203\345\274\217/index.html" @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\210\206\345\270\203\345\274\217\344\272\213\345\212\241/index.html" "b/tags/\345\210\206\345\270\203\345\274\217\344\272\213\345\212\241/index.html" index 5e128ea0..2310c048 100644 --- "a/tags/\345\210\206\345\270\203\345\274\217\344\272\213\345\212\241/index.html" +++ "b/tags/\345\210\206\345\270\203\345\274\217\344\272\213\345\212\241/index.html" @@ -350,7 +350,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -386,7 +386,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -472,7 +472,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -510,7 +510,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\210\206\345\270\203\345\274\217\346\236\266\346\236\204/index.html" "b/tags/\345\210\206\345\270\203\345\274\217\346\236\266\346\236\204/index.html" index ec0b298a..4aeb8740 100644 --- "a/tags/\345\210\206\345\270\203\345\274\217\346\236\266\346\236\204/index.html" +++ "b/tags/\345\210\206\345\270\203\345\274\217\346\236\266\346\236\204/index.html" @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\211\226\346\236\220-sofaark-\346\272\220\347\240\201/index.html" "b/tags/\345\211\226\346\236\220-sofaark-\346\272\220\347\240\201/index.html" index 78379963..8f150898 100644 --- "a/tags/\345\211\226\346\236\220-sofaark-\346\272\220\347\240\201/index.html" +++ "b/tags/\345\211\226\346\236\220-sofaark-\346\272\220\347\240\201/index.html" @@ -282,7 +282,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -318,7 +318,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -404,7 +404,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -442,7 +442,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\211\226\346\236\220-sofaark-\346\272\220\347\240\201/index.xml" "b/tags/\345\211\226\346\236\220-sofaark-\346\272\220\347\240\201/index.xml" index c5ad4e93..9b8578b3 100644 --- "a/tags/\345\211\226\346\236\220-sofaark-\346\272\220\347\240\201/index.xml" +++ "b/tags/\345\211\226\346\236\220-sofaark-\346\272\220\347\240\201/index.xml" @@ -1,9 +1,9 @@ - 剖析 | SOFAArk 源码 on SOFAStack + 剖析 | SOFAArk 源码 on SOFAStack https://sofastack.github.io/sofastack.tech/tags/%E5%89%96%E6%9E%90-sofaark-%E6%BA%90%E7%A0%81/ - Recent content in 剖析 | SOFAArk 源码 on SOFAStack + Recent content in 剖析 | SOFAArk 源码 on SOFAStack Hugo -- gohugo.io zh-CN Tue, 07 Jan 2020 20:00:00 +0800 diff --git "a/tags/\345\211\226\346\236\220-sofabolt-\346\241\206\346\236\266/index.html" "b/tags/\345\211\226\346\236\220-sofabolt-\346\241\206\346\236\266/index.html" index 9d3d99f9..ea5b4538 100644 --- "a/tags/\345\211\226\346\236\220-sofabolt-\346\241\206\346\236\266/index.html" +++ "b/tags/\345\211\226\346\236\220-sofabolt-\346\241\206\346\236\266/index.html" @@ -401,7 +401,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -437,7 +437,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -523,7 +523,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -561,7 +561,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\211\226\346\236\220-sofaboot-\346\241\206\346\236\266/index.html" "b/tags/\345\211\226\346\236\220-sofaboot-\346\241\206\346\236\266/index.html" index 8978af78..84a76448 100644 --- "a/tags/\345\211\226\346\236\220-sofaboot-\346\241\206\346\236\266/index.html" +++ "b/tags/\345\211\226\346\236\220-sofaboot-\346\241\206\346\236\266/index.html" @@ -313,7 +313,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -349,7 +349,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -435,7 +435,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -473,7 +473,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\211\226\346\236\220-sofajraft-\345\256\236\347\216\260\345\216\237\347\220\206/index.html" "b/tags/\345\211\226\346\236\220-sofajraft-\345\256\236\347\216\260\345\216\237\347\220\206/index.html" index 926a7ed3..1192de63 100644 --- "a/tags/\345\211\226\346\236\220-sofajraft-\345\256\236\347\216\260\345\216\237\347\220\206/index.html" +++ "b/tags/\345\211\226\346\236\220-sofajraft-\345\256\236\347\216\260\345\216\237\347\220\206/index.html" @@ -517,7 +517,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -553,7 +553,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -639,7 +639,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -677,7 +677,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\211\226\346\236\220-sofaregistry-\346\241\206\346\236\266/index.html" "b/tags/\345\211\226\346\236\220-sofaregistry-\346\241\206\346\236\266/index.html" index 5bfd255e..3a92f79d 100644 --- "a/tags/\345\211\226\346\236\220-sofaregistry-\346\241\206\346\236\266/index.html" +++ "b/tags/\345\211\226\346\236\220-sofaregistry-\346\241\206\346\236\266/index.html" @@ -480,7 +480,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -516,7 +516,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -602,7 +602,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -640,7 +640,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\211\226\346\236\220-sofarpc-\346\241\206\346\236\266/index.html" "b/tags/\345\211\226\346\236\220-sofarpc-\346\241\206\346\236\266/index.html" index 299a6b65..e09f225f 100644 --- "a/tags/\345\211\226\346\236\220-sofarpc-\346\241\206\346\236\266/index.html" +++ "b/tags/\345\211\226\346\236\220-sofarpc-\346\241\206\346\236\266/index.html" @@ -553,7 +553,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -589,7 +589,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -675,7 +675,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -713,7 +713,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\211\226\346\236\220-sofarpc-\346\241\206\346\236\266/page/2/index.html" "b/tags/\345\211\226\346\236\220-sofarpc-\346\241\206\346\236\266/page/2/index.html" index cb6d391b..17986933 100644 --- "a/tags/\345\211\226\346\236\220-sofarpc-\346\241\206\346\236\266/page/2/index.html" +++ "b/tags/\345\211\226\346\236\220-sofarpc-\346\241\206\346\236\266/page/2/index.html" @@ -322,7 +322,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -358,7 +358,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -444,7 +444,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -482,7 +482,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\211\226\346\236\220-sofatracer-\346\241\206\346\236\266/index.html" "b/tags/\345\211\226\346\236\220-sofatracer-\346\241\206\346\236\266/index.html" index 683341fc..acd098cf 100644 --- "a/tags/\345\211\226\346\236\220-sofatracer-\346\241\206\346\236\266/index.html" +++ "b/tags/\345\211\226\346\236\220-sofatracer-\346\241\206\346\236\266/index.html" @@ -401,7 +401,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -437,7 +437,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -523,7 +523,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -561,7 +561,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\256\236\350\267\265/index.html" "b/tags/\345\256\236\350\267\265/index.html" index 82336fc1..c059f2c5 100644 --- "a/tags/\345\256\236\350\267\265/index.html" +++ "b/tags/\345\256\236\350\267\265/index.html" @@ -284,7 +284,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -320,7 +320,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -406,7 +406,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -444,7 +444,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\274\200\346\272\220/index.html" "b/tags/\345\274\200\346\272\220/index.html" index 40b7e925..b95e45ce 100644 --- "a/tags/\345\274\200\346\272\220/index.html" +++ "b/tags/\345\274\200\346\272\220/index.html" @@ -387,7 +387,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -423,7 +423,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -509,7 +509,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -547,7 +547,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\274\200\346\272\220\344\271\213\345\244\217/index.html" "b/tags/\345\274\200\346\272\220\344\271\213\345\244\217/index.html" index 368112b4..103541cd 100644 --- "a/tags/\345\274\200\346\272\220\344\271\213\345\244\217/index.html" +++ "b/tags/\345\274\200\346\272\220\344\271\213\345\244\217/index.html" @@ -274,7 +274,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -310,7 +310,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -396,7 +396,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -434,7 +434,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\274\200\346\272\220\344\272\224\345\221\250\345\271\264/index.html" "b/tags/\345\274\200\346\272\220\344\272\224\345\221\250\345\271\264/index.html" index ac0b8874..b244454d 100644 --- "a/tags/\345\274\200\346\272\220\344\272\224\345\221\250\345\271\264/index.html" +++ "b/tags/\345\274\200\346\272\220\344\272\224\345\221\250\345\271\264/index.html" @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\274\200\346\272\220\345\205\255\345\221\250\345\271\264/index.html" "b/tags/\345\274\200\346\272\220\345\205\255\345\221\250\345\271\264/index.html" index a9ebd4e2..05ddf59f 100644 --- "a/tags/\345\274\200\346\272\220\345\205\255\345\221\250\345\271\264/index.html" +++ "b/tags/\345\274\200\346\272\220\345\205\255\345\221\250\345\271\264/index.html" @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\274\200\346\272\220\345\256\271\345\231\250\351\225\234\345\203\217\345\212\240\351\200\237\346\234\215\345\212\241\347\232\204\346\274\224\350\277\233\344\270\216\346\234\252\346\235\245/index.html" "b/tags/\345\274\200\346\272\220\345\256\271\345\231\250\351\225\234\345\203\217\345\212\240\351\200\237\346\234\215\345\212\241\347\232\204\346\274\224\350\277\233\344\270\216\346\234\252\346\235\245/index.html" index 8faeb8ee..b6eb3ab2 100644 --- "a/tags/\345\274\200\346\272\220\345\256\271\345\231\250\351\225\234\345\203\217\345\212\240\351\200\237\346\234\215\345\212\241\347\232\204\346\274\224\350\277\233\344\270\216\346\234\252\346\235\245/index.html" +++ "b/tags/\345\274\200\346\272\220\345\256\271\345\231\250\351\225\234\345\203\217\345\212\240\351\200\237\346\234\215\345\212\241\347\232\204\346\274\224\350\277\233\344\270\216\346\234\252\346\235\245/index.html" @@ -249,7 +249,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -285,7 +285,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -371,7 +371,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -409,7 +409,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\274\271\346\200\247\344\274\270\347\274\251/index.html" "b/tags/\345\274\271\346\200\247\344\274\270\347\274\251/index.html" index 0b49ef93..e383ee52 100644 --- "a/tags/\345\274\271\346\200\247\344\274\270\347\274\251/index.html" +++ "b/tags/\345\274\271\346\200\247\344\274\270\347\274\251/index.html" @@ -253,7 +253,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -289,7 +289,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -375,7 +375,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -413,7 +413,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\345\276\256\346\234\215\345\212\241/index.html" "b/tags/\345\276\256\346\234\215\345\212\241/index.html" index a891583b..ae7cb61a 100644 --- "a/tags/\345\276\256\346\234\215\345\212\241/index.html" +++ "b/tags/\345\276\256\346\234\215\345\212\241/index.html" @@ -280,7 +280,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -316,7 +316,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -402,7 +402,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -440,7 +440,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\346\226\207\344\273\266\345\222\214\351\225\234\345\203\217\345\212\240\351\200\237\347\263\273\347\273\237/index.html" "b/tags/\346\226\207\344\273\266\345\222\214\351\225\234\345\203\217\345\212\240\351\200\237\347\263\273\347\273\237/index.html" index 4a76e544..de10f207 100644 --- "a/tags/\346\226\207\344\273\266\345\222\214\351\225\234\345\203\217\345\212\240\351\200\237\347\263\273\347\273\237/index.html" +++ "b/tags/\346\226\207\344\273\266\345\222\214\351\225\234\345\203\217\345\212\240\351\200\237\347\263\273\347\273\237/index.html" @@ -249,7 +249,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -285,7 +285,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -371,7 +371,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -409,7 +409,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\346\231\272\350\203\275\347\233\221\346\216\247/index.html" "b/tags/\346\231\272\350\203\275\347\233\221\346\216\247/index.html" index 55c72a41..0fb24c3b 100644 --- "a/tags/\346\231\272\350\203\275\347\233\221\346\216\247/index.html" +++ "b/tags/\346\231\272\350\203\275\347\233\221\346\216\247/index.html" @@ -274,7 +274,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -310,7 +310,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -396,7 +396,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -434,7 +434,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\346\231\272\350\203\275\350\277\220\347\273\264/index.html" "b/tags/\346\231\272\350\203\275\350\277\220\347\273\264/index.html" index 7e05a213..a9c96058 100644 --- "a/tags/\346\231\272\350\203\275\350\277\220\347\273\264/index.html" +++ "b/tags/\346\231\272\350\203\275\350\277\220\347\273\264/index.html" @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\346\272\220\345\210\233\344\274\232/index.html" "b/tags/\346\272\220\345\210\233\344\274\232/index.html" index da64b986..1f460c2f 100644 --- "a/tags/\346\272\220\345\210\233\344\274\232/index.html" +++ "b/tags/\346\272\220\345\210\233\344\274\232/index.html" @@ -247,7 +247,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -283,7 +283,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -369,7 +369,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -407,7 +407,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\346\272\220\347\240\201\350\247\243\346\236\220/index.html" "b/tags/\346\272\220\347\240\201\350\247\243\346\236\220/index.html" index 0a3619fd..6297c65d 100644 --- "a/tags/\346\272\220\347\240\201\350\247\243\346\236\220/index.html" +++ "b/tags/\346\272\220\347\240\201\350\247\243\346\236\220/index.html" @@ -481,7 +481,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -517,7 +517,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -603,7 +603,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -641,7 +641,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\346\272\220\347\240\201\350\247\243\346\236\220/index.xml" "b/tags/\346\272\220\347\240\201\350\247\243\346\236\220/index.xml" index 7e358797..d59d371a 100644 --- "a/tags/\346\272\220\347\240\201\350\247\243\346\236\220/index.xml" +++ "b/tags/\346\272\220\347\240\201\350\247\243\346\236\220/index.xml" @@ -1,9 +1,9 @@ - “源码解析” on SOFAStack + 源码解析 on SOFAStack https://sofastack.github.io/sofastack.tech/tags/%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/ - Recent content in “源码解析” on SOFAStack + Recent content in 源码解析 on SOFAStack Hugo -- gohugo.io zh-CN Wed, 14 Sep 2022 15:00:00 +0800 diff --git "a/tags/\346\272\220\347\240\201\350\247\243\346\236\220/page/2/index.html" "b/tags/\346\272\220\347\240\201\350\247\243\346\236\220/page/2/index.html" index 5fa6ac78..8acae5ec 100644 --- "a/tags/\346\272\220\347\240\201\350\247\243\346\236\220/page/2/index.html" +++ "b/tags/\346\272\220\347\240\201\350\247\243\346\236\220/page/2/index.html" @@ -373,7 +373,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -409,7 +409,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -495,7 +495,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -533,7 +533,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\347\261\273\351\232\224\347\246\273\346\241\206\346\236\266/index.html" "b/tags/\347\261\273\351\232\224\347\246\273\346\241\206\346\236\266/index.html" index bcb4efb4..cd8fbc9c 100644 --- "a/tags/\347\261\273\351\232\224\347\246\273\346\241\206\346\236\266/index.html" +++ "b/tags/\347\261\273\351\232\224\347\246\273\346\241\206\346\236\266/index.html" @@ -249,7 +249,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -285,7 +285,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -371,7 +371,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -409,7 +409,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git "a/tags/\351\225\234\345\203\217/index.html" "b/tags/\351\225\234\345\203\217/index.html" index ad21e2f9..7af9226b 100644 --- "a/tags/\351\225\234\345\203\217/index.html" +++ "b/tags/\351\225\234\345\203\217/index.html" @@ -245,7 +245,7 @@

  • API Gateway
    • -
  • CAFEDeployment
    • +
  • CafeDeployment
  • Cloud Native
    • @@ -281,7 +281,7 @@

  • RPC 框架设计的考和量
    • -
  • Seata
    • +
  • seata
  • Serverless
    • @@ -367,7 +367,7 @@

  • 分布式架构
    • -
  • 剖析 | SOFAArk 源码
    • +
  • 剖析 | SOFAArk 源码
  • 剖析 | SOFABolt 框架
    • @@ -405,7 +405,7 @@

  • 源创会
    • -
  • “源码解析”
    • +
  • 源码解析
  • 类隔离框架
    • diff --git a/zh/sitemap.xml b/zh/sitemap.xml index e365aa9d..ad7ac4b4 100644 --- a/zh/sitemap.xml +++ b/zh/sitemap.xml @@ -4,7 +4,7 @@ https://sofastack.github.io/sofastack.tech/projects/mosn/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/occlum/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-acts/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/seata/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/layotto/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/koupleless/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-ark/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-6th-anniversary/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofastack/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofastack/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E5%BC%80%E6%BA%90%E5%85%AD%E5%91%A8%E5%B9%B4/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/explore-the-workflow-of-mosn-from-an-rpc-request/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/koupleless-brings-split-plugin-to-help-you-to-improve-the-efficiency-of-collaborative-development/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/efficient-cost-reduction-case-study-of-koupleless-practical-application-in-nanjing-f6/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/economical-and-efficient-enhance-the-competitiveness-of-enterprises-sofaserverless-brand-upgraded-to-koupleless-release-version-1.0/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ospp-exprience-sharing-keep-enthusiastic-and-all-in/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/open-source-together-seata-enters-apache-incubator/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/say-goodbye-to-complexity-easily-tackle-k8s-management-challenges-with-the-right-tools/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ospp-experience-sharing-community-contribution-is-a-kind-of-influence/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/lunettes-makes-kubernetes-service-operations-easier/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofa-weekly/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofa-weekly/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-1006/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/vldb2023-fanglue-an-interactive-rule-development-system/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230929/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/cncf-foundation-announced-kcl-as-a-sandbox-project/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/dragonfly-based-kubernetes-multi-cluster-image-distribution-for-docker-environments/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230915/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/dlrovers-stability-guarantee-for-large-model-training-on-k8s-with-thousands-of-cardinalities/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/elephant-turn-summary-of-alipay-funding-technology-serverless-efficiency-improvements/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230901/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofachannel/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofachannel/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-35/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230825/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230818/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/dragonfly-v-2-1-0-release/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-34/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/moe-series-7-envoy-go-extension-sandbox-security/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 @@ -534,14 +534,14 @@ https://sofastack.github.io/sofastack.tech/blog/sofaboot-4.0-is-officially-released-with-many-new-features-for-you-to-experience/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/sofastak/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 @@ -554,49 +554,49 @@ https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230623/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/the-next-five-years-of-sofastack/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230616/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-saga-model-quick-start-and-best-practices/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230609/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-go-1.2.0-available-for-production-environments-is-here/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-33/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 @@ -610,81 +610,81 @@ https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230526/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/mosn-delay-based-load-balancing-algorithm-go-faster-expect-to-go-steadier/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230519/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/moe-series-4-go-extended-asynchronous-mode/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230512/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/summer-2023-of-open-source-promotion-planwelcome-to-register-for-dragonflykata-containersand-nydus-community-projects/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/%E5%BC%80%E6%BA%90%E4%B9%8B%E5%A4%8F/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E5%BC%80%E6%BA%90%E4%B9%8B%E5%A4%8F/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-mosn-community-project/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0505/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/sofastack-%E5%BC%80%E6%BA%90%E4%B9%8B%E5%A4%8F/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/open-source-promotion-plan-2023-welcome-to-the-sofastack-community-project/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 @@ -698,21 +698,21 @@ https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230428/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ant-security-technology-nydus-mirror-acceleration-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0421/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 @@ -726,33 +726,33 @@ https://sofastack.github.io/sofastack.tech/activities/sofa-anniversary-5/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E5%BC%80%E6%BA%90%E4%BA%94%E5%91%A8%E5%B9%B4/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230414/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofaregistry/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofaregistry/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 @@ -765,3664 +765,3664 @@ https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/origins-ant-s-practical-path-to-application-level-service-discovery/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230407/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230331/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/moe-series-1how-to-extend-envoy-with-golang/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230324/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/volcano-engine-based-on-dragonfly-acceleration-practices/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-230317/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-go-1-1-0-released-completes-at-mode-support/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230310/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/dlrover-ant-open-source-large-scale-intelligent-distributed-training-system/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230303/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/nydus-container-image-acceleration-practices-on-the-yosemite-platform/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230217/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/kata-containers/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-32/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E4%BD%A0%E7%9A%84%E5%BC%80%E6%BA%90%E5%85%A5%E9%97%A8%E6%8C%87%E5%8D%97/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofachannel-32/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/go-language-how-to-do-inverse-type-derivation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/mosn/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230210/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230203/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/nudus-20230131/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20230127/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-special-weekly/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/go-sql-driver-amazing-bug/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220113/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/nerdctl-natively-supports-nydus-accelerated-mirroring/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofaweekly-20230106/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofaregistry-talk-about-the-data-consistency-of-service-discovery/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/sofaregistry-talk-about-the-data-consistency-of-service-discovery/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221230/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/nydus-mirror-scan-acceleration/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-202211223/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/dragonfly-and-nydus-mirror-mode-integration-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221216/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/we-have-come-to-the-post-cloud-native-era-how-can-we-operate-and-maintain-on-a-large-scale/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/rpc-%E6%A1%86%E6%9E%B6%E8%AE%BE%E8%AE%A1%E7%9A%84%E8%80%83%E5%92%8C%E9%87%8F/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofachannel-31/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/sofarpc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/cost-reduction-and-efficiency-increase-ants-exploration-and-practice-in-sidecarless/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221209/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/is-sidecarless-the-next-stop-for-servicemesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/tongsuo-supports-the-semi-homomorphic-encryption-algorithm-paillier/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221122/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/p2p-transfer-protocol-optimization-in-dragonfly/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221111/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/container-image-basics/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221104/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/nydus/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-30/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofaregistry-large-scale-cluster-optimization-practice/20221103/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E5%BC%80%E6%BA%90%E5%AE%B9%E5%99%A8%E9%95%9C%E5%83%8F%E5%8A%A0%E9%80%9F%E6%9C%8D%E5%8A%A1%E7%9A%84%E6%BC%94%E8%BF%9B%E4%B8%8E%E6%9C%AA%E6%9D%A5/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly/20221028/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/c-go-mechanism-calling-go-from-c/20221008/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20221007/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/20220929/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofastack20220927/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly/20220923/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/20220920/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220916/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofatalk/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofatalk/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofa-talk-1/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/is-pprof-enough-for-go-memory-leak/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220909/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/go-code-city-cloud-kusionstack-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220826/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/kusionstack-in-practice-at-ant-group-first/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220819/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-php-semi-annual-planning/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-17/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofameetup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofameetup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220812/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-16/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220805/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/mosn-reverse-channel-explained/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220729/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/my-new-name-is-tongsuo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/dragonfly/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-29/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-in-practice-in-ant-international-banking/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E6%96%87%E4%BB%B6%E5%92%8C%E9%95%9C%E5%83%8F%E5%8A%A0%E9%80%9F%E7%B3%BB%E7%BB%9F/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220722/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-boot-context-isolation-mechanism-explained/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/exploration-of-kusion-model-library-and-toolchain-in-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-multi-programming-language-system-construction/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-component-protocol-binding/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220715/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/go-native-plug-in-use-problem-full-analysis/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220708/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220624/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/build-subset-optimization/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220617/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-multi-web-component-deploy/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-healthcheck-mechanism-explained/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/nydus-exploratory-practice-of-next-generation-container-images/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220610/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/sofaark/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-28/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E7%B1%BB%E9%9A%94%E7%A6%BB%E6%A1%86%E6%9E%B6/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/the-two-years-that-broke-the-kusionstack-open-source-dilemma/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/how-to-think-about-multiple-runtime-architectures-like-dapr-layotto/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/http/quic/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220527/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-27/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/deeperinto-http-3-2-the-not-so-boring-ssl/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220520/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/service-mesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/review-and-prospect-of-service-mesh-progress-in-antgroup-2022/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofa/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofa/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-15/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220513/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-registry-meta/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofaserverless-system-for-speedy-business-development/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-publish-subscription-push/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/open-source-summer-2022-welcome-to-the-sofastack-community-and-mosn-community-projects/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220506/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-non-destructive-o-and-m/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/mosn-1-0-released-starting-a-new-architectural-evolution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210422/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-switch/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofastack-four-years-of-open-source/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/%E5%91%A8%E5%B9%B4%E5%BA%86/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220408/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-slottable/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/community-article-mosn-community-performance-analysis-tool-holmes-principle-analysis/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220401/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-14/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-communication-data-compression/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/exploratory-practice-of-heterogeneous-registration-centre-mechanism-in-icbc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220329/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-push-delay-trace/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-inverted-index/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/nydus-mirror-acceleration-plugin-moves-to-containerd/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220318/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/code-analyza-data-table-listening/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-26/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/community-article-mosn-routing-framework-explained/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220311/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/babassl-support-for-semi-homomorphic-encryption-algorithm-ec-elgamal/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220304/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/occlum-named-to-2021-sci-tech-china-open-source-innovation-list/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/babassl-released-8-3-0-implementation-of-the-corresponding-privacy-computing-requirements/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/explore-sofaregistry-1-infrastructure/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/community-meeting-mosn-community-will-release-version-1-0-and-drive-the-next-generation-architecture-evolution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/2021sale-antmonitor-roundup-cloud-native-prometheus-monitoring-in-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220228/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-25/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220218/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/application-runtime-layotto-into-cncf-cloud-native-panorama/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220211/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220204/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/welcome-the-year-of-the-tiger-open-source-is-the-time/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220129/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220121/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-24/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ant-massive-sigma-cluster-etcd-splitting-in-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/tengine-babassl-making-state-secrets-easier-to-use/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220107/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211231/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/one-line-of-code-to-reduce-carbon-emissions-by-100000kg/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211224/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/the-practice-and-thinking-behind-sofastack/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofaark-committer-interview-if-you-dont-like-it-just-change-it/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/deeper-into-http/3-evolution-of-the-protocol-from-the-creation-and-closing-of-quic-links/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-13/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211217/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/online-business-double-eleven-servicemesh-technology-based-service-link-isolation-technology-and-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211210/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-23/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/exploration-and-practice-of-service-mesh-in-icbc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/the-next-five-years-of-cloud-native-runtime/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211203/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211126/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/reduce-costs-and-improve-efficiency-the-metamorphosis-of-the-registration-centre-at-ant-group/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211119/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/prometheus-on-ceresdb-evolutionary-path/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211112/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/http/3/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-22/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211105/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/how-to-troubleshoot-high-rust-memory-usage-in-a-production-environment/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211029/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/a-new-generation-of-log-based-systems-in-sofajraft/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-12/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofatracer-completes-its-link-visualisation-journey/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211015/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ant-group-technical-risk-coding-platform-in-practice-maas/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211008/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/next-kubernetes-frontier-multi-cluster-management/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20211001/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/climbing-to-the-top-of-scale-ant-groups-large-scale-sigma-cluster-apiserver-optimization-in-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210924/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofajraft-in-practice-in-the-same-tour/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210917/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/restricted-flow-on-the-technology-windfall/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-10/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210910/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ant-intelligent-monitoring/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210903/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-star-is-recruiting/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210820/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-21-1/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/2021-cloud-native-technology-development-status-and-future-trends/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210813/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ant-group-sofatracer-principles-and-practices/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210806/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/kcl-a-declarative-cloud-native-configuration-policy-language/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210730/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/we-made-a-distributed-registry/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ant-groups-10000-scale-k8s-cluster-etcd-high-availability-construction-road/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-8/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210723/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/still-worried-about-multi-cluster-management/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210716/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/rfc8998-babassllet-guomi-sail-to-a-farther-starry-sea/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210702/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/mosn-multi-protocol-extension-development-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210625/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/mosn-subproject-layotto-opening-a-new-chapter-in-service-grid-application-runtime/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210618/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/gopher-china-2021-interview-with-song-shun-the-application-and-practice-of-go-in-ant-group/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0611/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-7/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/the-secret-of-anolisos/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210604/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/helping-data-security-ant-and-intel-work-together-to-create-a-verified-ppml-solution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/protecting-critical-operations-with-secure-computing/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200528/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/exploration-and-practice-of-antcloud-native-application-runtime-archsummit-shanghai/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/summer-2021/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/summer-2021/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/summer-2021-of-open-source-promotion-plan/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/take-you-into-cloud-native-technology-cloud-native-open-operation-and-maintenance-system-exploration-and-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210521/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210514/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/occlum/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210507/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-20/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-6/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0430/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210423/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210416/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-5/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210409/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210402/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210326/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/service-mesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/service-mesh-%E8%90%BD%E5%9C%B0%E5%AE%9E%E8%B7%B5/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/mosn-meetup-4-deploy-automation-at-large-scale/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210319/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofagw-cross-domain-communication-solution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofagw/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210312/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-4/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210305/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/mosn/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/serverless/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/antgroup-serverless-task/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/serverlesstask/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E4%BB%BB%E5%8A%A1%E8%B0%83%E5%BA%A6/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E5%BC%B9%E6%80%A7%E4%BC%B8%E7%BC%A9/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly20210226/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210219/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-exploration-thinking-after-1111-1/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/%E4%BA%91%E5%8E%9F%E7%94%9F/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E4%BA%91%E5%8E%9F%E7%94%9F/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210212/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210205/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210129/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210122/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210115/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20220114/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20210108/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-grid-defines-a-new-path-for-enterprises-to-the-cloud-forrester-ant-group-releases-service-grid-white-paper/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201231/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201225/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201218/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201211/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201204/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201127/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201120/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201113/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201106/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201030/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201023/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201016/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201009/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20201002/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200925/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200918/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200911/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/cloud-native-network-proxy-mosn-evolutionary-path/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200828/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200821/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/occlum/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-18-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/kubernetes/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/kubernetes/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/antgroup-kubernetes-high-slo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200814/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/antgroup-k8s-security-protection-of-cluster-sensitive-information/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/antgroup-sofastack-rivers-and-lakes-on-the-cloud/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200807/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/five-years-to-ali-p8/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/%E6%99%BA%E8%83%BD%E7%9B%91%E6%8E%A7/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E6%99%BA%E8%83%BD%E7%9B%91%E6%8E%A7/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200731/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/kata-containers/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/kata-container-2.0-road-to-attack/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200724/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/mosn-istio-service-mesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200717/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/microkernel-distributed-operating-system-kubernetes/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/service-mesh-webinar/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/service-mesh-webinar-2/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/microservices-service-mesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sqlflow/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sqlflow/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/end-to-end-ai-system-sqlflow/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200710/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/%E5%88%86%E5%B8%83%E5%BC%8F%E6%9E%B6%E6%9E%84/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E5%88%86%E5%B8%83%E5%BC%8F%E6%9E%B6%E6%9E%84/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/antgroup-yinboxue-fully-distributed-unitized-technology-architecture/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200703/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/sofabolt/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-17-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E5%88%86%E5%B8%83%E5%BC%8F/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/categories/%E5%BE%AE%E6%9C%8D%E5%8A%A1/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E5%BE%AE%E6%9C%8D%E5%8A%A1/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/microservices-misunderstanding-avoid-monolith-to-distributed-monolith/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/%E9%95%9C%E5%83%8F/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E9%95%9C%E5%83%8F/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/twenty-years-of-image-format-from-knoppix-to-oci-image-v2/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200619/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/antfin-monitoring-cloud-native-observable-market-design-overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-the-road-ahead-long/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E6%BA%90%E5%88%9B%E4%BC%9A/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E6%99%BA%E8%83%BD%E8%BF%90%E7%BB%B4/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/antfin-service-mesh-monitor-landing-experience/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200612/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-17/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/forrester-daipeng-white-paper-cloud-native/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/mosn-dubbo-dubbo-go-hessian2-performance-optimization/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200605/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-webinar-duodian-istio-mosn-dubbo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/service-mesh-virtual-meetup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-service-mesh-observability-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200529/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-skywalking-observability-applications/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-virtual-meetup1-practice-in-enterprise-production/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200522/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-16-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/service-mesh-webinar-1/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/mosn-transparent-hijacking/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200515/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/mecha-carry-mesh-to-the-end/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/momo-service-mesh-exploration-and-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200508/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/kata-container/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/kata-container/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/kata-container-introduction-to-safe-containers/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofajraft/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofajraft/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofajraft-%E7%89%B9%E6%80%A7%E8%A7%A3%E6%9E%90/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-priority-election/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/api-gateway/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/service-mesh-api-gateway-in-depth-discussion-of-relationships/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofatracer/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofatracer/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-15-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-16/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200424/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-15/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200417/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200410/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-14-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/sofalab/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E5%89%96%E6%9E%90-sofaregistry-%E6%A1%86%E6%9E%B6/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-registry-dataserver-smooth-expansion-contraction/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200403/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-0327/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-14/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-13-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-api-udpa-follow-up/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200320/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofaark/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofaarklab/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-ark-maven-packaging-plugins/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-trcaer-disruptor-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-13/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200313/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-12-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200306/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/distributed-architecture-and-cloud-native/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-registry-data-consistency/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-boot-lab/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/sofaboot/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/categories/sofalab/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E5%89%96%E6%9E%90-sofaboot-%E6%A1%86%E6%9E%B6/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200228/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-11-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200221/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofaboot/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-boot-log-isolation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200214/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-end-user-survey-report/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-12/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-boot-overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200207/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/service-mesh-meetup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part8-quantity/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-9-retrospect-technical-risk-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-11/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200117/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/java-kubernetes-operator-kubecon-na2019/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-9-retrospect-api-gateway-mesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200110/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 - - https://sofastack.github.io/sofastack.tech/tags/seata/ - 2024-10-14T11:45:33+08:00 - 0 - - https://sofastack.github.io/sofastack.tech/blog/sofa-channel-10-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/seata/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 + 0 + + + + https://sofastack.github.io/sofastack.tech/tags/seata/ + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E5%89%96%E6%9E%90-sofaark-%E6%BA%90%E7%A0%81/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-ark-overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20200103/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-registry-service-offline-notification/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-10/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/knative-serverless-kubecon-na2019/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/knative/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191227/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part7-control-plane/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sidacar-kubecon-na2019/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/sidecar-%E5%AE%B9%E5%99%A8/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191220/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/antfin-zsearch-vector-search/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/zsearch/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part6-operator/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191213/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/meetup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/service-mesh-meetup-9/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/db-mesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/ant-financial-db-mesh-explore-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191206/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/kubernetes-practice-antfinal-shopping-festival/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-wushi/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191129/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part4-rpc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part5-gateway/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-9/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191122/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part2-mesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-antfinal-shopping-festival-big-exam/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191115/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part1-core/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/service-mesh-meetup-8/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191108/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/antfin-service-mesh-network-agents/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-antfin-deep-practice-qcon/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-saga-flexible-financial-applications/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191101/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-ark-lab/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191025/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/1024/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/1024/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/ant-financial-happy-1024/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191018/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-registry-session-storage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ant-financial-native-cloud-financial-architecture/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ant-financial-native-cloud-security-architecture/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191011/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-registry-data-fragmentation-synchronization-scheme/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofaenclave/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofaenclave/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-enclave-confidential-computing/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20191004/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sqlflow-ai-didi-antfin-open-source-construction/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190927/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-snapshot-principle-analysis/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E5%89%96%E6%9E%90-sofajraft-%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190920/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/elasticdl/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/elasticdl/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/alipay-deep-learning-tensorflow-elasticdl/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190913/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-registry-metaserver-function-introduction/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-activity-retrospect-collection/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190906/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-registry-lab/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-8-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190830/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-development-trend-2/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190823/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-3-cloud-original-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190816/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-8/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-3-seata-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-user-china-mobile/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190809/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-pipeline-principle/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190802/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190726/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-3/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv-multi-raft-group/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-weekly-20190719/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 - https://sofastack.github.io/sofastack.tech/tags/cafedeployment/ - 2024-10-14T11:45:33+08:00 + https://sofastack.github.io/sofastack.tech/categories/cafedeployment/ + 2024-10-14T11:48:04+08:00 0 - https://sofastack.github.io/sofastack.tech/categories/cafedeployment/ - 2024-10-14T11:45:33+08:00 + https://sofastack.github.io/sofastack.tech/tags/cafedeployment/ + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-7-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-registry-service-discovery-optimization/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/serverless-market-challenge/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/cncf/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E5%BC%80%E6%BA%90/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofastack-projects-joined-cncf-landscape/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-election-mechanism/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofastack-cloud-native-workshop-show/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-7/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofastack-cncf-cloud-native-landscape/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofastack-2019-oscar/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-linear-consistent-read-implementation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-distributed-transaction-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E5%AE%9E%E8%B7%B5/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/categories/sofalookout/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofalookout/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-6-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-giac-2019/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofastack-user-yimi/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-6/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-financial-cloud-native-exploration/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-lookout-server-open-source/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/cloud-native/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/kubecon/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofastack-cloud-native-workshop/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/workshop/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofadashboard/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-2-2-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-2-1-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-development-trend-1/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-rheakv/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofastack-linux-china/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-2/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofastack-independent-droup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sqlflow-open-source/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/sofaacts/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-5/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-algorithm-storage-module-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofadashboard/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-dashboard-open-source/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/antfin-middleware-open-source-key-figure-luzhi/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-registry-introduction/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofaacts/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-4-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-5-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofastack-anniversary-1/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-server-deep-analysis/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-4/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-seata/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-jraft/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/k8s-1.14-release-note/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E5%89%96%E6%9E%90-sofatracer-%E6%A1%86%E6%9E%B6/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-event-tracing-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-registry-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-meetup-1-registry/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-tcc-theory-design-realization/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-tcc-applicable-models-scenarios/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-ark-0.6.0/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-acts-automated-testing-framework/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-jraft-production-level-algorithm-library/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/financial-technology-meet-open-source/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-meetup-1/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofarpc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofarpc-5.5.x-nacos-hystrix/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-3/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-3-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/kubernetes-the-next-gen-os/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-2-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-2/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-response-mechanism/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-sampling-tracking-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-tracer-unvarnished-transmission-slf4j-mdc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-boot-extension-practice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-channel-1-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/sofa-channel-1/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/distributed-arch-in-the-enterprise/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-5-istio-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/serverless-knative-giac/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/serverless/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofastack-oschina-2018/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofabolt/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/%E5%89%96%E6%9E%90-sofabolt-%E6%A1%86%E6%9E%B6/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-framework-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-serialization-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-codec-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-bolt-timeout-and-heart-beat-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-blot-connection-management-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-giac-2018/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/service-mesh-meetup-5-retrospect/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/categories/sofamesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/tags/sofamesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-cnutcon-2018/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-serialization-comparison/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/%E5%89%96%E6%9E%90-sofarpc-%E6%A1%86%E6%9E%B6/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-cross-language-support/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-annotation-support/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-tcp-protocol-extension/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-rapid-decode-forward/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-graceful-exit/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-routing-implementation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-mesh-x-protocol-common-address-solution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-data-transmission/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-generalized-call-implementation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-single-machine-fault-culling/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-threading-model/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-synchronous-asynchronous-implementation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-connection-management-heartbeat-analysis/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-link-tracking/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-framework-overall-extension/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofastack-modular-isolation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-boot-modular-development/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-boot-class-isolation-deep-dive/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofastack-open-source-doubles/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/tags/springboot/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/blog/spring-boot-sofa-boot-class-isolation-integration/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/seata-distributed-transaction-open-source/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-boot-readiness-check-in-kubernetes/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/sofa-rpc-zookeeper-integriation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/announcing-sofastack-open-source/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/technical-financial-distributed-trading/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/blog/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/guides/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/concept/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 0 https://sofastack.github.io/sofastack.tech/search/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-biz/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-biz-lifecycle/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-event/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jar/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-startup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-plugin/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-classloader/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-log/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-service/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-jvm/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/awesome/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-benchmark/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/benchmark-performance/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/generic-invoke/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/invoke-type/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/bolt-timeout/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/counter-example/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-datasource/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-datasource/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/dubbo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/dubbo-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-dubbo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-dubbo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/faq/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/filter-chain/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/functional-interface-support/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/h2c/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/h2c-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/http-json/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-httpclient/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-httpclient/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault-hystrix/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jraft-rheakv-user-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jraft-user-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/module-service/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/java-sdk/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/jepson-test/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/reference-performance-report010/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/reference-performance-report021/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/concept/smooth-upgrade/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/maven-dependency/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/concept/nginx-envoy-mosn-hot-upgrade/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/node-and-java-communicate/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-okhttp/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-okhttp/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-openfeign/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-openfeign/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-readme/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-exception/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-filter/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-cors/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-basic/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration-common/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/application-rpc-config/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/raft-introduction/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-register-agent/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-resttemplate/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-resttemplate/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/road-map/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-acts/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-readme/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-public-presentation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/ark-console/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-config/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-migration-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-functions/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-contribution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/sofa-bolt-handbook/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-bolt/related-links/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_2_5_x/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_3_x/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/upgrade_4_x/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-profile/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/classloader-isolation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/guides/kc-sofastack-dynamic-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/extension/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started-with-sofa-boot/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-api/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/rpc-config-xml-explain/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-sofa-boot-annotation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-metrics-server/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/sofarpc-metrics/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/structure-intro/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started-with-rpc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-sofarpc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/guides/sofastack-demos/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/community/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/utils/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/configuration/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/sofatracer-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/server/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/concept/sidecar-pattern/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/skywalking-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/bean-async-init/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-spring-boot-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/usage-of-mvc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/log-format-springmvc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/concept/tls/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-telnet/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/traceid-generated-rule/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-x-protocol/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-zookeeper-adapter/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-zk-config/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/network-filter/connection-manager/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/listener/network-filter/proxy/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-ide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-model/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-script/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/report-to-zipkin/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/graceful-shutdown/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/guides/kc-cloud-mesh-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-consul/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-run-with-sofamesh/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-nacos/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-sofa/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/guides/sofastack-quick-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/guides/kc-seata-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-zookeeper/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-local/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/dependency-management/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/notice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/health-check/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/client-ext-metrics/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/consistency-raft-jraft/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-dynamic-deploy/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/test/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-acts/contributing/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-contribution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/contribution/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/contributing/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/contributing/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/plan/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/release-notes/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/release-notes/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-release/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/release-node/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/release-notes/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/speed-up-startup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-startup-process/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-quick-start-docker/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/sofa-mesh-setup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/guides/kc-serverless-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-terminology/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/terminology/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/explanation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/common-model/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/how-to-contribute-code-to-sofajraft/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-plugin-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-ark-demo/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/how-to-build/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-mesh/pilot-setup-zookeeper-installation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-api/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-registry/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/client-quick-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-client-boot/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/quick-start-client-java/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/client-invoke-flow/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/client-configuration/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-run-samples/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-samples/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-acts/faq/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/faq/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/faq/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/faq/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/serialization/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/print-traceid-spanid/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/dashboard-client/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/development-use-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-acts/developer-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/developer-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/async/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/quick-start-setup/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-acts/getting-started/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/quick-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/quick-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/getting-started/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/component-access/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/code-analyze/summary/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/flexible/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-build-package-plugin/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/scale/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-api/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/extension-loader/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/publish-and-reference/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-es/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-grafana/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-storage-ext/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-promql-feature-enhancement/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-lookout/use-guide-other-metrics-protocol-support/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/governance/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/server-quick-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/hr/campus/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/engine-architecture/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/concept/core-concept/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-acts/usage-ready/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/modular-development/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/parallel-start/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofaboot-module/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-extension-guide/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/registry-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/activities/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/concept/traffic-hijack/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/version-release/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/release-log/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/view-versions/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/version-rule/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/release-standard/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/notice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/notice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/notice/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-jraft/user-stories/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/peer-to-peer/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-boot/sofa-ark-class-loader-delegation/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programming/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/configuration-fault-tolerance/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/fault-tolerance/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/reporter-custom/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-threadpool/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-router/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/custom-filter/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/custom/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/hr/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/retry-invoke/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/load-balance/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-dashboard/roadmap/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/management-api/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/protocol/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-registry/deployment/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/mosn/configuration/overview/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-tracer/sampler/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/invoke-chain-pass-data/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/tracing-usage/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/restful-swagger/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/programing-rpc/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5 https://sofastack.github.io/sofastack.tech/projects/sofa-rpc/provider-warmup-weight/ - 2024-10-14T11:45:33+08:00 + 2024-10-14T11:48:04+08:00 monthly 0.5